Bug 226616 - Update databases/clickhouse to 1.1.54362
Summary: Update databases/clickhouse to 1.1.54362
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Yuri Victorovich
Depends on:
Reported: 2018-03-14 19:46 UTC by proler
Modified: 2018-03-16 08:30 UTC (History)
2 users (show)

See Also:
proler: maintainer-feedback+

Patch (21.83 KB, patch)
2018-03-14 19:46 UTC, proler
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Yuri Victorovich freebsd_committer 2018-03-15 09:39:45 UTC
===>  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
Comment 2 Yuri Victorovich freebsd_committer 2018-03-15 09:42:37 UTC
Please rather attach the shar of the port directory.
Comment 3 proler 2018-03-15 19:50:03 UTC
can you use files from here https://github.com/proller/freebsd-ports/tree/master/databases/clickhouse  ?
or delete all unlisted patches ?
Comment 4 Yuri Victorovich freebsd_committer 2018-03-15 20:07:38 UTC
(In reply to proler from comment #3)

Ok, thanks.
Comment 5 commit-hook freebsd_committer 2018-03-15 21:22:10 UTC
A commit references this bug:

Author: vsevolod
Date: Thu Mar 15 21:21:43 UTC 2018
New revision: 464636
URL: https://svnweb.freebsd.org/changeset/ports/464636

  - Update to 1.1.54362 [1]
  - Fix plist issues

  PR:		226616 [1]
  Submitted by:	maintainer [1]

Comment 6 Yuri Victorovich freebsd_committer 2018-03-15 21:33:20 UTC
(In reply to commit-hook from comment #5)

It is assigned to me.
Comment 7 Yuri Victorovich freebsd_committer 2018-03-15 21:42:52 UTC
This port is still broken.
Comment 8 Vsevolod Stakhov freebsd_committer 2018-03-15 22:13:17 UTC
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?
Comment 9 Yuri Victorovich freebsd_committer 2018-03-15 22:18:28 UTC
It's broken:
====> 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?
Comment 10 Yuri Victorovich freebsd_committer 2018-03-15 22:21:47 UTC
You shouldn't commit patches that have somebody else assigned, unless a lot of time has passed. This has only been assigned yesterday.
Comment 11 Vsevolod Stakhov freebsd_committer 2018-03-15 22:23:16 UTC
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?
Comment 12 Vsevolod Stakhov freebsd_committer 2018-03-15 22:24:36 UTC
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.
Comment 13 Yuri Victorovich freebsd_committer 2018-03-15 22:35:20 UTC
(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.
Comment 14 Vsevolod Stakhov freebsd_committer 2018-03-15 22:39:53 UTC
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?
Comment 15 Vsevolod Stakhov freebsd_committer 2018-03-15 22:46:33 UTC
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?
Comment 16 Yuri Victorovich freebsd_committer 2018-03-15 22:47:42 UTC
(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. :)
Comment 17 Yuri Victorovich freebsd_committer 2018-03-15 22:50:25 UTC
(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! :)
Comment 18 Yuri Victorovich freebsd_committer 2018-03-16 07:36:38 UTC
Committed the patch unbreaking the port.
Comment 19 commit-hook freebsd_committer 2018-03-16 07:37:32 UTC
A commit references this bug:

Author: yuri
Date: Fri Mar 16 07:36:35 UTC 2018
New revision: 464659
URL: https://svnweb.freebsd.org/changeset/ports/464659

  databases/clickhouse: Unbreak

  Port changes:
  * Add USES=shebangfix and SHEBANG_FILES
  * Add USES=python (python is used)
  * Add stripping

  PR:		226616
  Approved by:	portmgr (port compliance, infrastructure)

Comment 20 Vsevolod Stakhov freebsd_committer 2018-03-16 08:30:58 UTC
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.