Re: [gentoo-dev] Crypto/GPG-related packages up for grabs
On Mon, Sep 07, 2020 at 07:44:33PM +0200, Michał Górny wrote: > Hi, > > The following packages are up for grabs due to their maintainer being > MIA. > > acct-group/monkeysphere > acct-user/monkeysphere > app-crypt/ekeyd > app-crypt/monkeysphere > app-crypt/nasty > app-crypt/pinentry > app-eselect/eselect-pinentry > dev-libs/libgcrypt > dev-libs/npth > net-misc/sks > www-apps/ampache Note that ampache is currency masked for removal: # Sam James (2020-08-30) # Serious security vulns, outdated. # bug 699834. Removal in 30 days. www-apps/ampache https://bugs.gentoo.org/699834 > > -- > Best regards, > Michał Górny > signature.asc Description: PGP signature
[gentoo-dev] www-servers/lighttpd is up for grabs
I have switched to nginx for the most of my services. There are no critical bugs open, but some may require additional investigation.
Re: [gentoo-dev] Crypto/GPG-related packages up for grabs
On 07.09.2020 20:44, Michał Górny wrote: Hi, The following packages are up for grabs due to their maintainer being MIA. acct-group/monkeysphere acct-user/monkeysphere app-crypt/ekeyd app-crypt/monkeysphere app-crypt/nasty app-crypt/pinentry app-eselect/eselect-pinentry dev-libs/libgcrypt dev-libs/npth net-misc/sks www-apps/ampache I will take pinentry as I took gnupg in anyway.
[gentoo-dev] Crypto/GPG-related packages up for grabs
Hi, The following packages are up for grabs due to their maintainer being MIA. acct-group/monkeysphere acct-user/monkeysphere app-crypt/ekeyd app-crypt/monkeysphere app-crypt/nasty app-crypt/pinentry app-eselect/eselect-pinentry dev-libs/libgcrypt dev-libs/npth net-misc/sks www-apps/ampache -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last-rites: dev-python/mini-amf
# Nothing in the tree uses this lib anymore. Removing as redundant. # Removal in ~30 days. Bug #740868. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
On 2020-09-06 17:46, David Seifert wrote: > Unfortunately we won't get around a single-r1-style eclass too. What > about all those programs embedding a specific lua version as plugin > architecture? This is still very much on my to-do list, I simply figured it would make it easier for everyone reviewing this to leave it until the next iteration. > But the basic principles underlying your eclass > are finally correct, unlike the previous lua.eclass attempt. Thank you! Of course it would have been much more difficult to achieve were it not for Michał's work on python-r1. On 2020-09-06 19:13, Azamat Hackimov wrote: >> +# @ECLASS-VARIABLE: LUA >> +# @DEFAULT_UNSET >> +# @DESCRIPTION: >> +# The absolute path to the current Lua interpreter. This variable is set >> +# automatically in functions called by lua_foreach_impl(). >> +# >> +# Example value: >> +# @CODE >> +# /usr/bin/lua5.1 > > I think there also needs a LUAC variable that points to the current > Lua compiler. Possibly, then again I have begun to wonder if we even need LUA itself... Moreover, there would be no LUAC were the eclass made to support luajit. I guess we'll see how many ebuilds actually need these once we have begun porting them to lua.eclass. > There needs a LUA_MAJOR_VERSION (V variable in lua.pc, i.e. 5.1, 5.2, > 5.3) instead of full version (R variable in lua.pc, i.e 5.1.5, 5.2.4). > Some obscure Lua packages are required to define V variable to work > properly. Nah, one can easily go from the full version to the ABI version (LUA_MAJOR_VERSION would just be 5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Michael Orlitzky wrote: > You're missing some context. In October of last year, a QA team member > broke dependency resolution on a lot of systems by making the same sort > of change that this patch proposes: > https://archives.gentoo.org/gentoo-dev/message/64c42804eb4cf4bc7d1161a2e9222c6a Which is very different from what this patch suggests. For example, virtual/pam had been package masked at the time, while mgorny's patch explicitly says that a virtual should _not_ be masked prior to its removal. > Last month, someone brought up that example and named the QA team as > partly responsible for the --changed-deps requirement, which goes > against the PMS and a council decision: > https://archives.gentoo.org/gentoo-dev/message/dcebabbd6f13aed6622424d439f7becc Again, very different case which had nothing to do with removal of a virtual. > Shortly thereafter, another QA member opened a pull request that would > retroactively make what the first QA member did OK: > https://github.com/gentoo/devmanual/pull/177 See my first paragraph above. > And now, we are having a third QA team member in charge of approving > that change to the devmanual, which will later be cited as "policy." > Your problem is that you're not a member of the right gang. Ad-hominem attacks won't help us here. Ulrich
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On 2020-09-07 08:47, Alessandro Barbieri wrote: > Being consistent in decision is hard I see. You're missing some context. In October of last year, a QA team member broke dependency resolution on a lot of systems by making the same sort of change that this patch proposes: https://archives.gentoo.org/gentoo-dev/message/64c42804eb4cf4bc7d1161a2e9222c6a Last month, someone brought up that example and named the QA team as partly responsible for the --changed-deps requirement, which goes against the PMS and a council decision: https://archives.gentoo.org/gentoo-dev/message/dcebabbd6f13aed6622424d439f7becc Shortly thereafter, another QA member opened a pull request that would retroactively make what the first QA member did OK: https://github.com/gentoo/devmanual/pull/177 And now, we are having a third QA team member in charge of approving that change to the devmanual, which will later be cited as "policy." Your problem is that you're not a member of the right gang.
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Alessandro Barbieri wrote: > Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha > scritto: >> We are talking about the second case here, because the dependency on the >> virtual is being removed, while the dependency on its provider remains >> in place (it only changes from an indirect to a direct dependency). > That what's I've done here > https://github.com/gentoo/gentoo/pull/13443#issuecomment-553764133 but > you decided to make me do a revbump. > Being consistent in decision is hard I see. I still stand by what I said there: | Exceptions are packages that take a long time to build, where you may | want to use common sense and weigh the negative impact of not doing a | revbump against build time on users' systems (and in those cases, it | can sometimes be avoided, e.g., by delaying the change until the next | version bump). Also I don't see how this would be a contradiction. In your case it was a revbump of a single ebuild with negligible build time. Here, we're talking about removal of a virtual, which may require a rebuild of many packages on users' systems if everything was revbumped. Ulrich
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha scritto: > The devmanual [1] says that a revbump should be done when a new runtime > dependency is added to an ebuild, but it doesn't say that for removal of > a dependency. > > We are talking about the second case here, because the dependency on the > virtual is being removed, while the dependency on its provider remains > in place (it only changes from an indirect to a direct dependency). > > Ulrich > > [1] > https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html > > That what's I've done here https://github.com/gentoo/gentoo/pull/13443#issuecomment-553764133 but you decided to make me do a revbump. Being consistent in decision is hard I see.
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Michael Orlitzky wrote: > On 2020-09-07 08:10, Ulrich Mueller wrote: >> The devmanual [1] says that a revbump should be done when a new >> runtime dependency is added to an ebuild, but it doesn't say that for >> removal of a dependency. > One dependency is removed, and another is added. All completely > besides the point that this breaks things. Except that it doesn't, in this special case. Ulrich
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On 2020-09-07 08:10, Ulrich Mueller wrote: >> This has caused dependency resolution problems in the past. The PMS >> implies a new revision, > > PMS says nothing about new revisions or revision bumps: > That is indeed what the word "implies" implies. > The devmanual [1] says that a revbump should be done when a new runtime > dependency is added to an ebuild, but it doesn't say that for removal of > a dependency. > One dependency is removed, and another is added. All completely besides the point that this breaks things.
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Michael Orlitzky wrote: > On 2020-09-07 02:14, Michał Górny wrote: >> + >> +Update all ebuilds not to reference the virtual. Since there is >> +no urgent need to remove the virtual from user systems >> +and the resulting rebuilds would be unnecessary, do not bump ebuilds >> +when replacing the dependency. >> + > This has caused dependency resolution problems in the past. The PMS > implies a new revision, PMS says nothing about new revisions or revision bumps: $ grep -i "new revision" pms/*.tex $ grep -i bump pms/*.tex $ > the council said make a new revision, and the devmanual already says > make a new revision. [...] The devmanual [1] says that a revbump should be done when a new runtime dependency is added to an ebuild, but it doesn't say that for removal of a dependency. We are talking about the second case here, because the dependency on the virtual is being removed, while the dependency on its provider remains in place (it only changes from an indirect to a direct dependency). Ulrich [1] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On 2020-09-07 02:14, Michał Górny wrote: > + > +Update all ebuilds not to reference the virtual. Since there is > +no urgent need to remove the virtual from user systems > +and the resulting rebuilds would be unnecessary, do not bump ebuilds > +when replacing the dependency. > + This has caused dependency resolution problems in the past. The PMS implies a new revision, the council said make a new revision, and the devmanual already says make a new revision. Documenting this behavior might make people feel better about ignoring all of that, but your lack of guilt doesn't do me any good when portage starts crashing.
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 7 Sep 2020 21:39:54 +1200 Kent Fredric wrote: > On Mon, 7 Sep 2020 08:14:52 +0200 > Michał Górny wrote: > > > However, please > > +do not include it in the package.mask entry as users do > > not need > > +to be forced to proactively unmerge it. > > I can think of a utilitarian value of doing this anyway. > > Namely, it gives a window during `emerge -uD @world` where portage > tells you that they have a masked package installed, and the reason. I think portage also warns for installed packages with no corresponding ebuild; the reason is somewhat generic though (sth like 'it is gone') IMHO last rites windows have only one purpose: give time to people to step up and fix the reason why it is going away -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCX1YK/gAKCRAOJUi7xgfl rrooAQCBK/WXgwMl1wm8jQh+e2oyD8WIAzSrzFFBCE7xWL1WGgEAgWSGBmG9ug8/ ZNfrHnOhBL2o6hZupzMy/84dX7DFBvk= =pwzN -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On Mon, 7 Sep 2020 08:14:52 +0200 Michał Górny wrote: > However, please > +do not include it in the package.mask entry as users do not need > +to be forced to proactively unmerge it. I can think of a utilitarian value of doing this anyway. Namely, it gives a window during `emerge -uD @world` where portage tells you that they have a masked package installed, and the reason. Ideally, people don't have virtuals in their world file, but they do anyway, which means you can't guarantee the lack of dependents resulting in a depclean directed purge. And this can matter, as if its in your world file, or sometimes, if its even still installed, portage can trip up during upgrades with a more confusing error about the virtual not being installable. Outdated overlays add to this problem somewhat. :/ pgpsytvtxUHNq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On Mon, 2020-09-07 at 09:46 +0200, Ulrich Mueller wrote: > > > > > > On Mon, 07 Sep 2020, Michał Górny wrote: > > + > > +If the virtual is being removed along with its second to last > > +provider, include the virtual in the last-rites mail. However, please > > Maybe write "any of its providers" instead of "its second to last > provider"? It is simpler and still has the same meaning. Done. > > > +do not include it in the package.mask entry as users do not need > > +to be forced to proactively unmerge it. Instead, add it > > +to package.deprecated to warn developers not to depend on it. > > +Wait the time appropriate for the last rites. > > + -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Michał Górny wrote: > + > +If the virtual is being removed along with its second to last > +provider, include the virtual in the last-rites mail. However, please Maybe write "any of its providers" instead of "its second to last provider"? It is simpler and still has the same meaning. > +do not include it in the package.mask entry as users do not need > +to be forced to proactively unmerge it. Instead, add it > +to package.deprecated to warn developers not to depend on it. > +Wait the time appropriate for the last rites. > + signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/2] eutils.eclass: Use optfeature() from optfeature.eclass
> On Sun, 06 Sep 2020, David Seifert wrote: > On Sun, 2020-09-06 at 21:49 +0200, Ulrich Mueller wrote: >> Maybe just commit the new eclass, update ebuilds, then remove the >> function from eutils? > I'll get a lot of heat for breaking EAPI 2 ebuilds in some random > abandoned overlay because we guarantee eclass API backwards > compatibility for 20 years! optfeature affects only elog output, so there won't be any real breakage. And of course, there should be some grace period (I'd suggest 30 days) between steps 2 and 3. Ulrich signature.asc Description: PGP signature
