alexxy has been doing lots of python-3.7 testing, it seems, and marking packages as such. While I don't mind that in itself as something the maintainer isn't consulted about - these commits also hide EAPI-7 revision bumps. And that enters a territory the maintainer has to be talked to. But not just that, these bumps are broken, and mostly involve just changing EAPI=6 to 7 - no BDEPEND, no care for ${ED} not having a trailing slash anymore, etc etc. As I don't really want to be involved with this mess further than reverting brokenness done to my packages, this bug is meant to pass it on to alexxy and QA team to sort out.
Whats the problem with commits? They are build tested. And now its possible to have system with kde build fuly with python3.7 (not waiting forever untill it will be added to all py packages)
It would be helpful if you provided a few commits proving your point. Since you have noticed them in the first place, it should be easier for you to provide them than us go looking for evidence to prove your point.
@leio and if you reverted commits that moves dev-libs/libpwquality to EAPI7 and adds python3.7 support, may be you will add it yourself in a way you think is right?
(In reply to Alexey Shvetsov from comment #3) > @leio and if you reverted commits that moves dev-libs/libpwquality to EAPI7 > and adds python3.7 support, may be you will add it yourself in a way you > think is right? 1. In general, touching others' packages require permissions. 2. If you do it without permission (which you shouldn't), you should damn well make sure that any EAPI 7 bumps are QA valid (like checking BDEPEND) 3. You don't need to bump packages to EAPI 7 to add py3.7.
(In reply to Michał Górny from comment #2) > It would be helpful if you provided a few commits proving your point. Since > you have noticed them in the first place, it should be easier for you to > provide them than us go looking for evidence to prove your point. As told in my original report - EAPI-7 revision bumps done to him. This should give a good idea: git log --author=alexxy --stat --since=2019-06-01 all commits that show a big row of +'s due to added revision are bad, and probably without consulting the maintainer (the list is too numerous for me to check if he happens to maintain a couple of these, but bad EAPI-7 port still). In case of packages maintained by me (libpwquality), this would be specifically https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=620c6c51b7a42968 for which he fixed up one problem in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cab31d67836 but others remained. None of this should have been done without maintainer knowing, other than the PYTHON_COMPAT tweak to existing revision - that I wouldn't have minded if it was properly tested, but again, the maintainer would know better how to fully test this (no, I have not tested it yet to know if that was a problem too or not, I assume it's fine in this case and wouldn't mind just a simple 3_7 addition to PYTHON_COMPAT without being consulted, except when it's to libpeas related stuff of ours).
(In reply to Alexey Shvetsov from comment #3) > @leio and if you reverted commits that moves dev-libs/libpwquality to EAPI7 > and adds python3.7 support, may be you will add it yourself in a way you > think is right? If you have properly tested this, I don't mind you adding python3.7 to PYTHON_COMPAT. But ONLY that to the existing revision without any revbumps.
As I remember revbumps required when functionality of packages changed or some of its mutual dependency changed. So adding py3.7 required revbamp, especialy for stable packages. Or its a new undocumented exception?
About BDEPEND and friends. Its not mandatory for eapi7 per its documentation. Can someone show me line when it said that its mandatory? All docs said that they can be splited to DEPEND and BDEPEND. https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html#build-time-dependencies-split-into-depend-and-bdepend https://devmanual.gentoo.org/ebuild-writing/eapi/
(In reply to Alexey Shvetsov from comment #7) > As I remember revbumps required when functionality of packages changed or > some of its mutual dependency changed. So adding py3.7 required revbamp, > especialy for stable packages. > > Or its a new undocumented exception? it is not, because not all people have python3.7 enabled but still may prefer using the latest version of a package, so you caused peple with python3.6 enabled needless rebuilds.
(In reply to Mikle Kolyada from comment #9) > (In reply to Alexey Shvetsov from comment #7) > > As I remember revbumps required when functionality of packages changed or > > some of its mutual dependency changed. So adding py3.7 required revbamp, > > especialy for stable packages. > > > > Or its a new undocumented exception? > > it is not, because not all people have python3.7 enabled but still may > prefer using the latest version of a package, so you caused peple with > python3.6 enabled needless rebuilds. If someone use --changed-use or -vauDN opts for portage when updating adding python3_7 to PYTHON_COMPAT will trigger package rebuild anyway with or without revbump
(In reply to Alexey Shvetsov from comment #10) > (In reply to Mikle Kolyada from comment #9) > > (In reply to Alexey Shvetsov from comment #7) > > > As I remember revbumps required when functionality of packages changed or > > > some of its mutual dependency changed. So adding py3.7 required revbamp, > > > especialy for stable packages. > > > > > > Or its a new undocumented exception? > > > > it is not, because not all people have python3.7 enabled but still may > > prefer using the latest version of a package, so you caused peple with > > python3.6 enabled needless rebuilds. > > > If someone use --changed-use or -vauDN opts for portage when updating adding > python3_7 to PYTHON_COMPAT will trigger package rebuild anyway with or > without revbump This is still pretty optional, that is the point.
FTR, py37 flags are stable-masked, so stable kw are irrelevant.
Don't hide EAPI-bumps under 'works with py3-7.' EAPI bumps are a major change so at least mention that in git summary; at least in one case ebuild was broken as a result.
So are all these touched packages still broken without maintainers knowing? What's the plan of attack on this without ignoring respective maintainers further?
I think we can agree that Alexey is in the wrong here, independently of technical details. Alexey, do you understand the problem? I'd like to ask you to look through your recent commits and either fix what is still broken, or revert your changes. I'd also like you to apologize to maintainers whom your changes caused extra work. At the same point, I'd like to point out that if you continue violating maintainer boundaries with significant changes to their packages, we will have to discuss further action. Adding python3_7 is fine *if you tested it*. EAPI bumps usually are not fine (even if they seem trivial to you). Honest mistakes are acceptable. Deliberate ignoring of maintainer status is not.
(In reply to Michał Górny from comment #15) > I think we can agree that Alexey is in the wrong here, independently of > technical details. Ok. I agree with this. > Alexey, do you understand the problem? I'd like to ask you to look through > your recent commits and either fix what is still broken, or revert your > changes. I'd also like you to apologize to maintainers whom your changes > caused extra work. I'll review changes (with compile tests) > At the same point, I'd like to point out that if you continue violating > maintainer boundaries with significant changes to their packages, we will > have to discuss further action. So in future i'll will fill bugs to maintainer for not my packages (e.g not mine directly or not belong to proj) > Adding python3_7 is fine *if you tested it*. EAPI bumps usually are not > fine (even if they seem trivial to you). Honest mistakes are acceptable. > Deliberate ignoring of maintainer status is not.
Just compile test isn't sufficient here at all, and isn't likely to find most of the potential problems. For example one breakage in your libpwquality commit would only become apparent (if even then if you don't check consumers against it) with USE=static-libs. Also the BDEPEND problem doesn't become apparent from natively compiling. Etc, etc...
Just stumbled on e.g. dev-python/pycups still having a broken EAPI-7 port from this (no BDEPEND)
When the Council approved BDEPEND as an EAPI 7 item, the understanding was (quoting from the 20171112 meeting log): "the relevant policy would be that developers are free to ignore BDEPEND and let people who care about cross fix it". Has this policy changed at some point? If so, then I must have missed it.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2f9cf2707633cd6b0745cc748c31f48d1058f096 commit 2f9cf2707633cd6b0745cc748c31f48d1058f096 Author: David Seifert <soap@gentoo.org> AuthorDate: 2020-04-18 08:46:54 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2020-04-18 08:46:54 +0000 dev-python/pycups: Clean up dependencies Bug: https://bugs.gentoo.org/691460 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: David Seifert <soap@gentoo.org> dev-python/pycups/pycups-1.9.73-r2.ebuild | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
I generally ask Alexey to refrain from doing EAPI 7 bumps on others' packages without their consent. I do agree with leio that these EAPI 7 ports weren't done with the necessary care. @leio, if there are more packages that weren't ported correctly, could you list them? If you like I will take a look at them (if you haven't reverted the changes yet).
I'm sorry but I didn't feel that it is my responsibility to spend time on cleaning up after it, hence the bug too, in the hope that someone else has the time, and assigning it to the team responsible for quality assurance was the logical thing to do for some progress on this. This feeling about responsibility and time usage has not changed - my own plate is more than full, including with eventually getting to dealing with QA check minor reported issues in my own maintained packages. Originally these weren't only BDEPEND issues, but more; though hopefully most of those have been found over time and fixed regardless, but some may be subtle and show only under some USE combinations or gentoo prefix usage. I believe it should be easy enough to get a list from git log --author=alexxy --stat --since="2019-07-15" or similar, up to the point this behaviour stopped.
(In reply to Mart Raudsepp from comment #22) > Originally these weren't only BDEPEND issues, but more; though hopefully > most of those have been found over time and fixed regardless, but some may > be subtle and show only under some USE combinations or gentoo prefix usage. No argument there. What I wanted to point out in comment #19 is that wrong (or missing) BDEPEND alone isn't sufficient reason to file a QA bug. Most developers aren't prepared to test things with cross, so all they can do is an educated guess on the DEPEND/BDEPEND split, which won't be correct in 100% of the cases.
(In reply to Ulrich Müller from comment #23) > What I wanted to point out in comment #19 is that wrong > (or missing) BDEPEND alone isn't sufficient reason to file a QA bug. Please read the bug title.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad29fd65eee549e9b325777f881fa7326d0f4ce2 commit ad29fd65eee549e9b325777f881fa7326d0f4ce2 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2020-04-19 07:47:21 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2020-04-19 08:15:16 +0000 app-accessibility/speech-dispatcher: Fix depends Bug: https://bugs.gentoo.org/691460 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Mart Raudsepp <leio@gentoo.org> .../speech-dispatcher/speech-dispatcher-0.8.7-r3.ebuild | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
