Created attachment 191504 [details]
Also here https://github.com/proller/freebsd-ports/tree/master/databases/clickhouse
===> Applying FreeBSD patches for clickhouse-1.1.54362
Ignoring previously applied (or reversed) patch.
1 out of 1 hunks ignored--saving rejects to libs/libcommon/cmake/find_cctz.cmake.rej
=> FreeBSD patch patch-libs_libcommon_cmake_find__cctz.cmake failed to apply cleanly.
=> Patch(es) patch-dbms_tests_CMakeLists.txt applied cleanly.
*** Error code 1
Please rather attach the shar of the port directory.
can you use files from here https://github.com/proller/freebsd-ports/tree/master/databases/clickhouse ?
or delete all unlisted patches ?
(In reply to proler from comment #3)
A commit references this bug:
Date: Thu Mar 15 21:21:43 UTC 2018
New revision: 464636
- Update to 1.1.54362 
- Fix plist issues
PR: 226616 
Submitted by: maintainer 
(In reply to commit-hook from comment #5)
It is assigned to me.
This port is still broken.
We have contacted with the reporter using IRC with regard to your invalid request about SHAR for an maintainer update request. I have built, tested and committed the original patch with the necessary modifications. Now, you claim that the "port is broken" with no argumentation. Do you want to escalate this to the portmgr level?
====> Running Q/A tests (stage-qa)
Error: '/usr/bin/env python' is an invalid shebang you need USES=shebangfix for 'bin/clickhouse-test'
Error: '/usr/bin/env python' is an invalid shebang you need USES=shebangfix for 'share/clickhouse-test/performance/create_benchmark_page.py'
Error: '/usr/bin/env python' is an invalid shebang you need USES=shebangfix for 'share/clickhouse-test/external_dictionaries/generate_and_test.py'
Error: '/usr/bin/env python' is an invalid shebang you need USES=shebangfix for 'share/clickhouse-test/external_dictionaries/http_server.py'
*** Error code 1
Plus there are also stripping issues.
The original patch failed, so I asked for shar, and he provided the equivalent.
What's wrong? What do you want portmgr to decide?
You shouldn't commit patches that have somebody else assigned, unless a lot of time has passed. This has only been assigned yesterday.
What is invalid in `/usr/bin/env python`? Shar is *usually* requested for the new ports only, not for a maintainer update. Otherwise, what would you expect from `shar` that is not provided by `patch`? Cleaning of the obsolete files in your working dir, or what? If you want to fix something then please go and fix it, why do you want to make a flame where there is no need to do it at all?
If you think that I *shouldn't* do something, then you have an authority to make a claim: portmgr@FreeBSD.org. Otherwise, your arguments are invalid I'm afraid.
(In reply to Vsevolod Stakhov from comment #11)
> What is invalid in `/usr/bin/env python`?
If you don't understand this, then you shouldn't be committing such changes, because this is what broke the build. stage-qa requires explicit python version set in scripts. This is to prevent the situation when both python2 and python3 are installed, but they have diffrent sets of modules installed. 'python' will pick one of pythons, and if it is wrong than the package will likely break. Please do not ignore any stage-qa errors and warnings because they are all valid AFAIK.
Regarding SHAR, I asked for it because the original patch didn't apply. This happened like 3 times recently. People either forget to update, or diff with some git version that isn't up-to-date. The easiest way to resolve this is to ask for SHAR, IMO.
FYI, here is the broken build log: http://package21.nyi.freebsd.org/data/111amd64-default-qat/464327/logs/errors/clickhouse-1.1.54342_1.log
(In reply to Vsevolod Stakhov from comment #12)
You shouldn't get involved when somebody else is currently working on this, unless a lot of time has passed. This is common sense, and is also unethical.
Again, you are trying to assume a lot of 'you should' and 'you shouldn't'. As I've said, if you have some concrete claims, then please resolve them with portmgr@. I have explained why I have committed this change. If you want to do something about it you can propose your changes to the port's maintainer. Maintainer is the person who maintains the port, isn't it clear to you?
I also would like to mention that your request about shar was completely invalid in this case: the patch could be applied with no problems.
Furthermore, your claims about python version are merely related to the tests. Are we doing porting of software to FreeBSD or just stupidly following some instructions without real understanding of what's needed to build healthy packages?
(In reply to Vsevolod Stakhov from comment #14)
Maintainer only has a prerogative when the port is in a good working condition. If the port fails, like in this case, I can either correct the failure myself, or modify maintainer's update if it doesn't correct the failure, like in this case. I don't have to wait for maintainer's approval for stripping/shebang fixes at all. :) Same goes for LICENSE corrections, and for obviously missing things, like USES=python in this case. :)
(In reply to Vsevolod Stakhov from comment #15)
portmgr@ will most definitely disagree. His general opinion is that USES=python needs to be present every time python is in use, and the correct python shebang is required.
If you disagree with the stage-qa test, submit a patch to improve it! :)
Committed the patch unbreaking the port.
A commit references this bug:
Date: Fri Mar 16 07:36:35 UTC 2018
New revision: 464659
* Add USES=shebangfix and SHEBANG_FILES
* Add USES=python (python is used)
* Add stripping
Approved by: portmgr (port compliance, infrastructure)
Cool, thank you for collaboration, Yuri. I'd like to say sorry about intruding to this PR yesterday.
However, my main reason was that I'm sure that the ports should be as open to external contributors as possible. It is quite obvious that there are very few people outside of our Ports Developers community who has ever seen shar. It is quite discouraging for people to use those exotic tools. We should accept any contributions: Github pull requests, raw patches and so on. Form doesn't matter the content does.
I've seen that in many other communities when policies start to prevail over rational approach. It is ridiculously hard to create or update packages, for instance in Debian. And what we see now is that security fixes come to the ports faster than to Debian because we are more open to the external contributors. I'd love to see this being kept in future.