Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
On Sun, 13 Sep 2020 12:04:39 -0700 Alec Warner wrote: > Is openrc critical to Gentoo? it doesn't live on our infra. > Is pkgcore critical to Gentoo? it doesn't live on our infra. Both those things are "things employed by users for their systems". Neither of those things are integral to any workflow, and are entirely optional. But when you file a bug, you rely on bugzilla being maintained by Gentoo Infra, not some 3rd party. And when you file a keyword/stable request, you rely on a bugzilla-integrated functionality through nattka to check and verify keywords. Subsequently, whether or not you opted into this, nattka is now critical to the workflow of everyone doing keywording/stable requests. You can't really say that about pkgcore or openrc. But you can say that about the QA Automated Testing service, which mangles gentoo.git and creates sync/gentoo.git, and reports when people broke the tree. And that *uses* pkgcore. But I'm pretty sure that infrastructure lives on gentoo "somewhere", and if it doesn't, it should. pgpGWwZcOK06b.pgp Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-09-13 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-09-13 23:59 UTC. Removals: app-emacs/ghc-mod20200909-07:45 slyfox35008845c5a app-eselect/eselect-opencl 20200912-20:37 slashbeast09c9e4c4aea app-eselect/eselect-opengl 20200912-20:38 slashbeast89f9953622c app-text/vlna20200911-09:32 zlogene 085e322e0ad dev-haskell/blaze-builder-enumerator 20200912-08:37 slyfox5dc44c18f9e dev-haskell/cabal-helper 20200909-07:45 slyfox35008845c5a dev-haskell/chell-quickcheck 20200912-09:19 slyfox9cba813d70c dev-haskell/cmdlib 20200912-09:24 slyfox3138d0cbb62 dev-haskell/crypto-conduit 20200912-14:23 slyfox4019edee13a media-sound/jackbeat 20200907-06:13 mgorny77016787000 media-sound/specimen 20200907-06:14 mgornyf974ba0c4f5 media-sound/tapiir 20200907-06:15 mgorny8bf69c6ded0 net-misc/termpkg 20200912-20:43 sam 1e5c7251175 sys-apps/modutils20200907-06:15 mgorny7e69b0876ef virtual/emacs20200912-17:27 ulm df2507b4239 virtual/modutils 20200907-06:15 mgorny340f6f937c4 x11-libs/flowcanvas 20200912-10:03 fordfrog a505e144a26 Additions: acct-group/consul_exporter 20200913-05:14 williamh 7800656ec37 acct-group/mongodb_exporter 20200907-21:32 williamh a10d9e9094a acct-user/consul_exporter20200913-05:20 williamh 3dcdabe724c acct-user/mongodb_exporter 20200907-21:39 williamh fce980b4852 app-dicts/sword-VieStrongsGreek 20200911-00:40 marecki d04ed838d71 app-emulation/firecracker-bin20200613-13:03 juippis 69eb27243a3 dev-libs/date20200812-14:32 sam 57218032b02 dev-libs/vc-intrinsics 20200913-15:05 marecki cbe8bf889cd dev-perl/String-Util 20200910-17:39 kentnl222dda8e343 dev-perl/Test-Compile20200908-09:18 kentnl547d871d889 dev-python/asttokens 20200910-07:54 mgornyff5315fb668 dev-python/django-allauth20200911-10:52 hanno 750e66d4aaf dev-python/django-gravatar2 20200911-10:53 hanno 86b44b56480 dev-python/executing 20200910-08:12 mgorny5b3dc74582c dev-python/fakeredis 20200910-20:43 mgornyd687a5bea74 dev-python/flask-compress20200912-11:47 titanofold4a9a6820195 dev-python/junit-xml 20200907-09:05 mgornyce3699c84cd dev-python/jupyterlab_pygments 20200911-01:02 mgorny3ed131a17a9 dev-python/nbclient 20200911-00:51 mgornybd85d246154 dev-python/nest_asyncio 20200911-00:55 mgorny14bd227cf95 dev-python/python3-openid20200911-10:42 hanno 30ec5e66f4a dev-python/xxhash20200906-16:44 expeditioneer 25a20900778 dev-util/rustup 20200908-20:31 gyakovlev a7a2c1f6028 games-rpg/broken-age 20200908-20:12 chewi 67d73a73ea2 net-mail/django-mailman3 20200911-11:10 hanno 58fb50d36a9 net-mail/mailmanclient 20200911-11:07 hanno bc3a7d9116a net-mail/postorius 20200911-11:16 hanno 2db0edb7327 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-misc/termpkg,removed,sam,20200912-20:43,1e5c7251175 app-eselect/eselect-opengl,removed,slashbeast,20200912-20:38,89f9953622c app-eselect/eselect-opencl,removed,slashbeast,20200912-20:37,09c9e4c4aea virtual/emacs,removed,ulm,20200912-17:27,df2507b4239 dev-haskell/crypto-conduit,removed,slyfox,20200912-14:23,4019edee13a x11-libs/flowcanvas,removed,fordfrog,20200912-10:03,a505e144a26 dev-haskell/cmdlib,removed,slyfox,20200912-09:24,3138d0cbb62 dev-haskell/chell-quickcheck,removed,slyfox,20200912-09:19,9cba813d70c dev-haskell/blaze-builder-enumerator,removed,slyfox,20200912-08:37,5dc44c18f9e app-text/vlna,removed,zlogene,20200911-09:32,085e322e0ad app-emacs/ghc-mod,removed,slyfox,20200909-07:45,35008845c5a dev-haskell/cabal-helper,removed,slyfox,20200909-07:45,35008845c5a virtual/modutils,removed,mgorny,20200907-06:15,340f6f937c4 sys-apps/modutils,removed,mgorny,20200907-06:15,7e69b0876ef media-sound/tapiir,removed,mgorny,20200907-06:15,8bf69c6ded0 media-sound/specimen,removed,mgorny,20200907-06:14,f974ba0c4f5 media-sound/jackbeat,removed,mgorny,20200907-06:13,77016787000 Added Packages: dev-libs/vc-intrinsics,added,marecki,20200913-15:05,cbe8bf889cd dev-libs/date,added,sam,20200812-14:32,57218032b02 acct-user/consul_exporter,added
[gentoo-dev] rfc: kubernetes packaging
All, I would like to get some thoughts on kubernetes packaging. When I started maintaining it in Gentoo, it was packaged as 7 ebuilds (one per executable), and only one of them was marked stable. Since we normally do not split up monorepos into separate packages, I started moving everything over to one kubernetes ebuild. Now a bug has been opened which has a good case for kubeadm being a package on its own, so I have done that [1]. I need to know the best way to proceed, so I'll throw out a couple of questions: 1) should I bring back the split packages and lastrites sys-cluster/kubernetes? 2) should I just bring back other split packages that need to be split as I find them? What do folks think would be the best way for us to package Kubernetes? Thanks, William [1] https://bugs.gentoo.org/741572 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files
On Sun, Sep 13, 2020 at 7:21 AM Andrew Savchenko wrote:
>
> On Sat, 29 Aug 2020 21:53:45 +0200 Michał Górny wrote:
> > Thanks to David Michael for the initial patch and upstream fixes.
> >
> > Signed-off-by: Michał Górny
> > ---
> > eclass/acct-group.eclass | 16 +++-
> > eclass/acct-user.eclass | 16 +++-
> > 2 files changed, 30 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> > index 5550e4a2fb10..dc1562974870 100644
> > --- a/eclass/acct-group.eclass
> > +++ b/eclass/acct-group.eclass
> > @@ -80,7 +80,7 @@ S=${WORKDIR}
> >
> >
> > # << Phase functions >>
> > -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
> > +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
> >
> > # @FUNCTION: acct-group_pkg_pretend
> > # @DESCRIPTION:
> > @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
> > fi
> > }
> >
> > +# @FUNCTION: acct-group_src_install
> > +# @DESCRIPTION:
> > +# Installs sysusers.d file for the group.
> > +acct-group_src_install() {
> > + debug-print-function ${FUNCNAME} "${@}"
> > +
> > + insinto /usr/lib/sysusers.d
> > + newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
> > + printf "g\t%q\t%q\n" \
> > + "${ACCT_GROUP_NAME}" \
> > + "${ACCT_GROUP_ID/#-*/-}"
> > + )
> > +}
> > +
> > # @FUNCTION: acct-group_pkg_preinst
> > # @DESCRIPTION:
> > # Creates the group if it does not exist yet.
> > diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> > index e82f3c56dbbe..f9772c3cb111 100644
> > --- a/eclass/acct-user.eclass
> > +++ b/eclass/acct-user.eclass
> > @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
> > # @FUNCTION: acct-user_src_install
> > # @DESCRIPTION:
> > # Installs a keep-file into the user's home directory to ensure it is
> > -# owned by the package.
> > +# owned by the package, and sysusers.d file.
> > acct-user_src_install() {
> > debug-print-function ${FUNCNAME} "${@}"
> >
> > @@ -321,6 +321,20 @@ acct-user_src_install() {
> > # created yet
> > keepdir "${ACCT_USER_HOME}"
> > fi
> > +
> > + insinto /usr/lib/sysusers.d
> > + newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
> > + printf "u\t%q\t%q\t%q\t%q\t%q\n" \
> > + "${ACCT_USER_NAME}" \
> > + "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
> > + "${DESCRIPTION//[:,=]/;}" \
> > + "${ACCT_USER_HOME}" \
> > + "${ACCT_USER_SHELL/#-*/-}"
> > + if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
> > + printf "m\t${ACCT_USER_NAME}\t%q\n" \
> > + "${ACCT_USER_GROUPS[@]:1}"
> > + fi
> > + )
> > }
>
> Why these files are installed unconditionally?
>
> Of course we have a common "small files" policy that USE flags
> should not control small files in packages, such rule was designed
> for common packages where:
> 1) small files are insignificant disk usage compared to a whole
> package;
> 2) an average package takes significant time to rebuild and mass
> rebuild will cause problems during USE flip.
>
> While both arguments are valid for a common packages which provide
> real software, this is not true for very special acct-* packages:
> 1) They may (and usually do) have zero size of installed files,
> this makes sysusers.d stuff an infinite times larger than a
> whole typical acct-* package (it will still be much larger if one
> will consider size of new passw/group records).
> 2) acct-* packages are very fast to rebuild, so such price will
> be small compared to other changes necessary when USE="systemd" is
> being flipped.
>
> So it will be reasonable to add USE="systemd" to acct-* eclasses
> to control the changes proposed above.
If a USE flag is introduced for this, please use something other than
"systemd". While the only existing implementation is systemd-sysusers,
there is nothing stopping someone from developing a similar tool to
apply the same configuration data.
[gentoo-dev] Last rites: app-arch/unarj
# James Le Cuirot (2020-09-13) # License issues. app-arch/arj is a better alternative. Removal in 30 # days. See bug #694746. app-arch/unarj -- James Le Cuirot (chewi) Gentoo Linux Developer pgpz225rDDqkd.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Sun, 30 Aug 2020 11:19:51 +0300 Joonas Niilola wrote: > here's a list of few packages dropped to maintainer-needed due to > retirement of inactive maintainers. > > b = bugs open, > v = new version available. > > app-arch/lha Taken. Amiga forever! ;) > app-arch/unarj b This is going to be last-rited. See https://bugs.gentoo.org/694746. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpa_05luHXpS.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
On Sun, 2020-09-13 at 20:31 +0200, Thomas Deutschmann wrote: > You maybe all remember what happened to stable-bot: Years ago, > kensington created stable-bot on his own as PoC which revolutionized the > way how we do package stabilization in bugzilla. The service run on his > own infrastructure. Because of the benefit of the service the bot > provided, arch team’s workflow became dependent on stable-bot. We were > lucky that stable-bot just worked most of the time until the service was > down for a while. Nobody was able to help here: Kensigton himself was > unavailable, nobody had the sources… the end of the story: mgorny > created nattka which replaced stable-bot. > > However, we are still facing the same problem: No, we're not. Don't you see the huge difference between proprietary closed-source software and free software? > Only one person is involved in development How is that a problem? It is quite normal that simple tools are developed primarily by one person, and nattka is not exactly rocket science. That said, nobody is stopping others from working on it, there are surely some improvements to be done. > and knows how to run it. Everything is documented and fully contained in puppet. Deploying it to new server is as trivial as enabling it on host in question. > In case something will > break again and Michał will be unavailable, we can’t just push a fix and > watch a CI pipeline picking up and deploying new nattka. Who is 'we' here? Our Infra does not use 'CI pipelines', it uses Gentoo packages. Deploying a new version means bumping the package, waiting for rsync to distribute it (meh!) and telling puppet to upgrade. No buzz words involved, sorry. > Instead someone will have to fork repository from Michał’s private > repository at GitHub, make the changes It's not private, it's public. And to be honest, forking it on GitHub will certainly take less time and effort than dealing with git.gentoo.org (which needs to happen via Infra). > and hope that anyone within infrastructure team can > help to deploy fixed nattka. Are you suggesting there is a problem with Gentoo Infrastructure? I really don't see where this is going. You're concerned that Infra can't handle it, yet you actually ask to make it more reliant on Infra... > This is what the motion is about: This is not about that Gentoo depends > on single persons or things like that. It’s about the idea to > *formalize* the requirement that any service and software which is > critical for Gentoo (think about pkgcore) should live within Gentoo > namespace (https://gitweb.gentoo.org/), i.e. be accessible for *any* > Gentoo developer and deployments should be based on these repositories. You should weigh your words more carefully. Otherwise, we're going to end up forking the whole base-system, kernel... > Or in other words: Make sure that we adhere to social contract even for > critical software and services Gentoo depends on. So that we will never > ever face the situation that something we depend on doesn’t work > anymore. I fail to see how this is going to actually accomplish the goal. Having a different pipeline for committing does not make stuff not break, nor makes it more likely for people to fix it. In fact, I dare say having nattka on GitHub increases the chances of someone (esp. non-developer) submitting a fix, compared to obscure git.gentoo.org with no clear contribution pipeline. > Taking care of working pipelines before something is broken > should also help us in case something stops working so we don’t have to > figure out how to fix and re-deploy when house is already burning (like > portage: In case Zac can't do a release for some reason, in theory, > every Gentoo developer would be able to roll a new release). Please tell me how rolling a new release of nattka is exactly harder than rolling a release of Portage? I'm pretty sure most of Gentoo developers can figure out how to use GitHub, how to fork a repository, and if they use Python they can probably deal with pretty standard setup.py. Deployment can't be done without Infra's help anyway. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
On Sun, Sep 13, 2020 at 11:31 AM Thomas Deutschmann wrote: > Hi, > > TL;DR: jstein asked council [Bug 729062] for a motion that any service > and software which is critical for Gentoo should be developed/run in > Gentoo namespace. Because any request to council must be discussed I > volunteered to bring this topic to the mailing list (sorry for the huge > delay!). > > > Problem > === > You maybe all remember what happened to stable-bot: Years ago, > kensington created stable-bot on his own as PoC which revolutionized the > way how we do package stabilization in bugzilla. The service run on his > own infrastructure. Because of the benefit of the service the bot > provided, arch team’s workflow became dependent on stable-bot. We were > lucky that stable-bot just worked most of the time until the service was > down for a while. Nobody was able to help here: Kensigton himself was > unavailable, nobody had the sources… the end of the story: mgorny > created nattka which replaced stable-bot. > > However, we are still facing the same problem: Only one person is > involved in development and knows how to run it. In case something will > break again and Michał will be unavailable, we can’t just push a fix and > watch a CI pipeline picking up and deploying new nattka. Instead someone > will have to fork repository from Michał’s private repository at GitHub, > make the changes and hope that anyone within infrastructure team can > help to deploy fixed nattka. > > This is what the motion is about: This is not about that Gentoo depends > on single persons or things like that. It’s about the idea to > *formalize* the requirement that any service and software which is > critical for Gentoo (think about pkgcore) should live within Gentoo > namespace (https://gitweb.gentoo.org/), i.e. be accessible for *any* > Gentoo developer and deployments should be based on these repositories. > Or in other words: Make sure that we adhere to social contract even for > critical software and services Gentoo depends on. So that we will never > ever face the situation that something we depend on doesn’t work > anymore. Taking care of working pipelines before something is broken > should also help us in case something stops working so we don’t have to > figure out how to fix and re-deploy when house is already burning (like > portage: In case Zac can't do a release for some reason, in theory, > every Gentoo developer would be able to roll a new release). > I think your examples are a bit weird. Is openrc critical to Gentoo? it doesn't live on our infra. Is pkgcore critical to Gentoo? it doesn't live on our infra. Note that these are just packages, not services and the social contract just says """However, Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative.""" It says nothing about where things are hosted or how services are provided. I'd consider splitting the two here. For packages I don't think it matters as much where they are hosted. Most things can be mirrored into gentoo (if we want a copy of the src tree) and we also have tarballs of the source code much of the time on the mirror network. For services, I tend to agree more with your comments; we need need visibility and operational capability for services. When we rely on service components where the source is not available; its bad. But we rely on numerous services now. E.g. p.g.o relies on repology. Does that mean we need the source code to repology? I assume not. Does that mean we need to run our own repology? Also I assume not. -A > > See also: > = > Bug 729062: https://bugs.gentoo.org/729062 > > > -- > Regards, > Thomas Deutschmann / Gentoo Linux Developer > C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 > >
[gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
Hi, TL;DR: jstein asked council [Bug 729062] for a motion that any service and software which is critical for Gentoo should be developed/run in Gentoo namespace. Because any request to council must be discussed I volunteered to bring this topic to the mailing list (sorry for the huge delay!). Problem === You maybe all remember what happened to stable-bot: Years ago, kensington created stable-bot on his own as PoC which revolutionized the way how we do package stabilization in bugzilla. The service run on his own infrastructure. Because of the benefit of the service the bot provided, arch team’s workflow became dependent on stable-bot. We were lucky that stable-bot just worked most of the time until the service was down for a while. Nobody was able to help here: Kensigton himself was unavailable, nobody had the sources… the end of the story: mgorny created nattka which replaced stable-bot. However, we are still facing the same problem: Only one person is involved in development and knows how to run it. In case something will break again and Michał will be unavailable, we can’t just push a fix and watch a CI pipeline picking up and deploying new nattka. Instead someone will have to fork repository from Michał’s private repository at GitHub, make the changes and hope that anyone within infrastructure team can help to deploy fixed nattka. This is what the motion is about: This is not about that Gentoo depends on single persons or things like that. It’s about the idea to *formalize* the requirement that any service and software which is critical for Gentoo (think about pkgcore) should live within Gentoo namespace (https://gitweb.gentoo.org/), i.e. be accessible for *any* Gentoo developer and deployments should be based on these repositories. Or in other words: Make sure that we adhere to social contract even for critical software and services Gentoo depends on. So that we will never ever face the situation that something we depend on doesn’t work anymore. Taking care of working pipelines before something is broken should also help us in case something stops working so we don’t have to figure out how to fix and re-deploy when house is already burning (like portage: In case Zac can't do a release for some reason, in theory, every Gentoo developer would be able to roll a new release). See also: = Bug 729062: https://bugs.gentoo.org/729062 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/args
# Louis Sautier (2020-09-13) # Masked for removal in 30 days, unmaintained, no more revdeps. dev-python/args signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files
On 2020-09-13 13:21, Andrew Savchenko wrote: > So it will be reasonable to add USE="systemd" to acct-* eclasses > to control the changes proposed above. Having thought about this some more, another benefit of this approach would be - unless I am wrong of course - that all currently installed acct-* ebuilds will automatically pick up the eclass change of a world update with --newuse or --changed-use. In other words, I second making this conditional on USE=systemd. -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files
On Sat, 29 Aug 2020 21:53:45 +0200 Michał Górny wrote:
> Thanks to David Michael for the initial patch and upstream fixes.
>
> Signed-off-by: Michał Górny
> ---
> eclass/acct-group.eclass | 16 +++-
> eclass/acct-user.eclass | 16 +++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> index 5550e4a2fb10..dc1562974870 100644
> --- a/eclass/acct-group.eclass
> +++ b/eclass/acct-group.eclass
> @@ -80,7 +80,7 @@ S=${WORKDIR}
>
>
> # << Phase functions >>
> -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
> +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
>
> # @FUNCTION: acct-group_pkg_pretend
> # @DESCRIPTION:
> @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
> fi
> }
>
> +# @FUNCTION: acct-group_src_install
> +# @DESCRIPTION:
> +# Installs sysusers.d file for the group.
> +acct-group_src_install() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + insinto /usr/lib/sysusers.d
> + newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
> + printf "g\t%q\t%q\n" \
> + "${ACCT_GROUP_NAME}" \
> + "${ACCT_GROUP_ID/#-*/-}"
> + )
> +}
> +
> # @FUNCTION: acct-group_pkg_preinst
> # @DESCRIPTION:
> # Creates the group if it does not exist yet.
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index e82f3c56dbbe..f9772c3cb111 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
> # @FUNCTION: acct-user_src_install
> # @DESCRIPTION:
> # Installs a keep-file into the user's home directory to ensure it is
> -# owned by the package.
> +# owned by the package, and sysusers.d file.
> acct-user_src_install() {
> debug-print-function ${FUNCNAME} "${@}"
>
> @@ -321,6 +321,20 @@ acct-user_src_install() {
> # created yet
> keepdir "${ACCT_USER_HOME}"
> fi
> +
> + insinto /usr/lib/sysusers.d
> + newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
> + printf "u\t%q\t%q\t%q\t%q\t%q\n" \
> + "${ACCT_USER_NAME}" \
> + "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
> + "${DESCRIPTION//[:,=]/;}" \
> + "${ACCT_USER_HOME}" \
> + "${ACCT_USER_SHELL/#-*/-}"
> + if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
> + printf "m\t${ACCT_USER_NAME}\t%q\n" \
> + "${ACCT_USER_GROUPS[@]:1}"
> + fi
> + )
> }
Why these files are installed unconditionally?
Of course we have a common "small files" policy that USE flags
should not control small files in packages, such rule was designed
for common packages where:
1) small files are insignificant disk usage compared to a whole
package;
2) an average package takes significant time to rebuild and mass
rebuild will cause problems during USE flip.
While both arguments are valid for a common packages which provide
real software, this is not true for very special acct-* packages:
1) They may (and usually do) have zero size of installed files,
this makes sysusers.d stuff an infinite times larger than a
whole typical acct-* package (it will still be much larger if one
will consider size of new passw/group records).
2) acct-* packages are very fast to rebuild, so such price will
be small compared to other changes necessary when USE="systemd" is
being flipped.
So it will be reasonable to add USE="systemd" to acct-* eclasses
to control the changes proposed above.
Best regards,
Andrew Savchenko
pgps8XkbFsi5J.pgp
Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On 2020-04-14 10:36, Joonas Niilola wrote: > Hey, > > here's a list of packages recently dropped to maintainer-needed due to > retirement of multiple inactive proxied maintainers. > > (b) = open bugs, > (v) = new version is available. > app-backup/rear (b,v) > Hi, In the meantime I decided to take over "rear", too. Version bump PR is filed, but I cannot find other open bugs than "maintainer needed" ?!? Bye Martin 0xCE5F3E9B6DE05D12.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
