[gentoo-dev] RFC: UID/GID assignment for mail-filter/spamassassin's spamd (337/337)
Per GLEP-81 I'm submitting a request to assign UID/GID 337 to an spamd user for mail-filter/spamassassin. Github PR: https://github.com/gentoo/gentoo/pull/13766 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-wireless/bcm43xx-fwcutter
profiles: Mask net-wireless/bcm43xx-fwcutter for removal Mask net-wireless/bcm43xx-fwcutter for removal. Upstream is dead and we have the successor in the tree. Bug: https://bugs.gentoo.org/537786 -- Best regards, Jonas Stein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC acct-{user,group} for jenkins
On 2019-11-26 19:43, Ulrich Mueller wrote: >> 500...999 is currently marked as "reserved" but this shouldn't block >> this assignment, should it? > > It does. ...could you please explain why? ;) For me, the 500...999 block looks arbitrary. Check Gentoo's /etc/login.defs, 101-999 is valid for us. Why is 500...999 marked as "reserved"?! Please tell me I am missing something and not that it was added because in the past, other distribution started with 500 for normal users... If we don't pick a number (which should be available) used somewhere else, why do we care at all about "others"? -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC acct-{user,group} for jenkins
> On Tue, 26 Nov 2019, Thomas Deutschmann wrote: > 500...999 is currently marked as "reserved" but this shouldn't block > this assignment, should it? It does. > Therefore I am requesting uid and gid 818, both named "jenkins", for > dev-util/jenkins-bin. signature.asc Description: PGP signature
[gentoo-dev] RFC acct-{user,group} for unbound
I am requesting uid and gid 59, both named "unbound", for net-dns/unbound. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC acct-{user,group} for collectd
I am requesting uid and gid 440, both named "collectd", for app-metrics/collectd. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC acct-{user,group} for jenkins
No distribution I checked (Arch, Debian, Fedora/RH) has a static UID/GID for dev-util/jenkins-bin. Upstream failed multiple times with chosen UID/GID in documentation: https://github.com/jenkinsci/docker/issues/112 https://github.com/jenkinsci/docker/pull/153 https://github.com/jenkinsci/docker/issues/154 https://github.com/jenkinsci/docker/issues/165 https://github.com/jenkinsci/docker/issues/177 https://github.com/jenkinsci/docker/issues/277 FreeBSD has picked UID/GID 818 which I also want to use. 500...999 is currently marked as "reserved" but this shouldn't block this assignment, should it? Therefore I am requesting uid and gid 818, both named "jenkins", for dev-util/jenkins-bin. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC acct-{user,group} for nginx
Most distributions are using www-data user and are sharing user between www-servers packages. However, Gentoo, for historical reason(?) is using apache for www-servers/apache and nginx for www-servers/nginx. Therefore I am requesting uid and gid 82, both named "nginx", for www-servers/nginx. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages
On Tue, Nov 26, 2019 at 04:29:28PM +0100, Michał Górny wrote: > On Tue, 2019-11-26 at 21:30 +0800, Jason Zaman wrote: > > On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote: > > > Hi, > > > > > > TL;DR: should we depend on setuptools by default? Alternatively, should > > > we add distutils_enable_setuptools API to provide at least partial > > > validity checks. > > > > > > > > > Variant 1: automatic dependency on setuptools > > > = > > > Basically, we add a new trinary pre-inherit variable: > > > > > > DISTUTILS_USE_SETUPTOOLS=no > > > -> no deps > > > DISTUTILS_USE_SETUPTOOLS=bdepend > > > -> add to BDEPEND (the default) > > > DISTUTILS_USE_SETUPTOOLS=rdepend > > > -> add to BDEPEND+RDEPEND > > > > > > This is roughly 'erring on the safe side'. The default will work for > > > the majority of packages. We will have to disable it for setuptools > > > bootstrap deps, and devs will be able to adjust it to correct values > > > as they update ebuilds. For the time being, existing *DEPEND > > > on setuptools will avoid breaking stuff. > > > > > > This will also enable me to add extra QA checks to esetup.py. It should > > > be able to reasonably detect incorrect value and report it. This will > > > imply some 'false positives' for packages that use the old method of > > > specifying setuptools in RDEPEND but that's a minor hassle. > > > > > > Pros: > > > - works out of the box for the majority of packages > > > - enables full-range QA checking > > > > > > Cons: > > > - pre-inherit variable > > > - some (harmless) false positives on existing packages > > > > > > > I like variant 1 most since in almost all cases it'll be less work in > > the ebuilds. What about distutils_optional tho? In tensorflow I have all > > the python support behind USE="python" and guard all the deps. In the > > optional case is there any way for this to work other than just setting > > it to no and doing it manually? > > I assume if i set it to no and make it optional then the esetup.py > > checks wouldnt happen which isnt as nice. > > That's a very good question, and I'm afraid I don't have a good answer. > To be honest, I don't see how we could solve this. > > Since you need to add the appropriate variables to BDEPEND and RDEPEND > yourself, there's little purpose in trying to introduce some kind of > indirection for this -- it may detect that you've declared the wrong > kind of dep but it won't detect if you used the helper variables > correctly, so we're back to square one. > > I guess the only reasonable thing to do is to ignore it entirely for > this use case, and rely on the developer doing things right. Hopefully, > FWICS it's just 43 packages at the moment, so this wouldn't be that bad. I suspected this would be the case. I think its fine to not do it in the optional case and just update the docs to be really clear exactly what and how the ebuild must do is good enough. 43 packages out of the many thousand that use distutils-r1 seems like worrying about it isnt worth it yeah. -- Jason > > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages
On Tue, 2019-11-26 at 21:30 +0800, Jason Zaman wrote: > On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote: > > Hi, > > > > TL;DR: should we depend on setuptools by default? Alternatively, should > > we add distutils_enable_setuptools API to provide at least partial > > validity checks. > > > > > > Variant 1: automatic dependency on setuptools > > = > > Basically, we add a new trinary pre-inherit variable: > > > > DISTUTILS_USE_SETUPTOOLS=no > > -> no deps > > DISTUTILS_USE_SETUPTOOLS=bdepend > > -> add to BDEPEND (the default) > > DISTUTILS_USE_SETUPTOOLS=rdepend > > -> add to BDEPEND+RDEPEND > > > > This is roughly 'erring on the safe side'. The default will work for > > the majority of packages. We will have to disable it for setuptools > > bootstrap deps, and devs will be able to adjust it to correct values > > as they update ebuilds. For the time being, existing *DEPEND > > on setuptools will avoid breaking stuff. > > > > This will also enable me to add extra QA checks to esetup.py. It should > > be able to reasonably detect incorrect value and report it. This will > > imply some 'false positives' for packages that use the old method of > > specifying setuptools in RDEPEND but that's a minor hassle. > > > > Pros: > > - works out of the box for the majority of packages > > - enables full-range QA checking > > > > Cons: > > - pre-inherit variable > > - some (harmless) false positives on existing packages > > > > I like variant 1 most since in almost all cases it'll be less work in > the ebuilds. What about distutils_optional tho? In tensorflow I have all > the python support behind USE="python" and guard all the deps. In the > optional case is there any way for this to work other than just setting > it to no and doing it manually? > I assume if i set it to no and make it optional then the esetup.py > checks wouldnt happen which isnt as nice. That's a very good question, and I'm afraid I don't have a good answer. To be honest, I don't see how we could solve this. Since you need to add the appropriate variables to BDEPEND and RDEPEND yourself, there's little purpose in trying to introduce some kind of indirection for this -- it may detect that you've declared the wrong kind of dep but it won't detect if you used the helper variables correctly, so we're back to square one. I guess the only reasonable thing to do is to ignore it entirely for this use case, and rely on the developer doing things right. Hopefully, FWICS it's just 43 packages at the moment, so this wouldn't be that bad. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages
On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote: > Hi, > > TL;DR: should we depend on setuptools by default? Alternatively, should > we add distutils_enable_setuptools API to provide at least partial > validity checks. > > > Variant 1: automatic dependency on setuptools > = > Basically, we add a new trinary pre-inherit variable: > > DISTUTILS_USE_SETUPTOOLS=no > -> no deps > DISTUTILS_USE_SETUPTOOLS=bdepend > -> add to BDEPEND (the default) > DISTUTILS_USE_SETUPTOOLS=rdepend > -> add to BDEPEND+RDEPEND > > This is roughly 'erring on the safe side'. The default will work for > the majority of packages. We will have to disable it for setuptools > bootstrap deps, and devs will be able to adjust it to correct values > as they update ebuilds. For the time being, existing *DEPEND > on setuptools will avoid breaking stuff. > > This will also enable me to add extra QA checks to esetup.py. It should > be able to reasonably detect incorrect value and report it. This will > imply some 'false positives' for packages that use the old method of > specifying setuptools in RDEPEND but that's a minor hassle. > > Pros: > - works out of the box for the majority of packages > - enables full-range QA checking > > Cons: > - pre-inherit variable > - some (harmless) false positives on existing packages > I like variant 1 most since in almost all cases it'll be less work in the ebuilds. What about distutils_optional tho? In tensorflow I have all the python support behind USE="python" and guard all the deps. In the optional case is there any way for this to work other than just setting it to no and doing it manually? I assume if i set it to no and make it optional then the esetup.py checks wouldnt happen which isnt as nice. -- Jason
[gentoo-dev] Last rites: app-emacs/elib
# Ulrich Müller (2019-11-26) # Upstream says: "Elib has been decommissioned as a separate package # since its useful functions have long since been included in Emacs." # Last release in 1995. Byte-compilation fails with Emacs 27. # Masked for removal in 30 days. Bug #701160. app-emacs/elib signature.asc Description: PGP signature
