[gentoo-portage-dev] [PATCH] Default disable autounmask package.keywords/mask changes (bug 658648)
Add emerge --autounmask-license and --autounmask-use options which are
enabled by default, and disable package.keywords/mask changes by
default. For backward compatibility, previous behavior of
--autounmask=y and --autounmask=n is entirely preserved. Users can
get the old behavior simply by adding --autounmask to the make.conf
EMERGE_DEFAULT_OPTS variable.
Bug: https://bugs.gentoo.org/658648
Signed-off-by: Zac Medico
---
lib/_emerge/create_depgraph_params.py | 35 +++
lib/_emerge/depgraph.py | 16 +
lib/_emerge/main.py | 10 ++
lib/portage/tests/resolver/test_autounmask.py | 35 ++-
man/emerge.1 | 21 +--
5 files changed, 107 insertions(+), 10 deletions(-)
diff --git a/lib/_emerge/create_depgraph_params.py
b/lib/_emerge/create_depgraph_params.py
index 08605baa1..7d8da9065 100644
--- a/lib/_emerge/create_depgraph_params.py
+++ b/lib/_emerge/create_depgraph_params.py
@@ -7,6 +7,11 @@ from portage.util import writemsg_level
def create_depgraph_params(myopts, myaction):
#configure emerge engine parameters
#
+ # autounmask: enable autounmask
+ # autounmask_keep_keywords: prevent autounmask changes to
package.accept_keywords
+ # autounmask_keep_license: prevent autounmask changes to
package.license
+ # autounmask_keep_masks:prevent autounmask changes to package.mask
+ # autounmask_keep_use: prevent autounmask changes to package.use
# self: include _this_ package regardless of if it is merged.
# selective: exclude the package if it is merged
# recurse: go into the dependencies
@@ -34,6 +39,36 @@ def create_depgraph_params(myopts, myaction):
# binpkg_changed_deps: reject binary packages with outdated deps
myparams = {"recurse" : True}
+ autounmask_keep_keywords = myopts.get("--autounmask-keep-keywords")
+ autounmask_keep_masks = myopts.get("--autounmask-keep-masks")
+
+ autounmask = myopts.get("--autounmask")
+ autounmask_license = myopts.get('--autounmask-license')
+ autounmask_use = myopts.get('--autounmask-use')
+ if autounmask == 'n':
+ autounmask = False
+ else:
+ if autounmask is None:
+ if autounmask_use in (None, 'y'):
+ autounmask = True
+ elif autounmask_license in (None, 'y'):
+ autounmask = True
+
+ # Do not enable package.accept_keywords or package.mask
+ # changes by default.
+ if autounmask_keep_keywords is None:
+ autounmask_keep_keywords = True
+ if autounmask_keep_masks is None:
+ autounmask_keep_masks = True
+ else:
+ autounmask = True
+
+ myparams['autounmask'] = autounmask
+ myparams['autounmask_keep_use'] = True if autounmask_use == 'n' else
False
+ myparams['autounmask_keep_license'] = True if autounmask_license == 'n'
else False
+ myparams['autounmask_keep_keywords'] = False if
autounmask_keep_keywords in (None, 'n') else True
+ myparams['autounmask_keep_masks'] = False if autounmask_keep_masks in
(None, 'n') else True
+
bdeps = myopts.get("--with-bdeps")
if bdeps is not None:
myparams["bdeps"] = bdeps
diff --git a/lib/_emerge/depgraph.py b/lib/_emerge/depgraph.py
index 51614fc14..3788cbe04 100644
--- a/lib/_emerge/depgraph.py
+++ b/lib/_emerge/depgraph.py
@@ -5907,15 +5907,19 @@ class depgraph(object):
if self._dynamic_config._autounmask is not True:
return
- autounmask_keep_keywords =
self._frozen_config.myopts.get("--autounmask-keep-keywords", "n") != "n"
- autounmask_keep_masks =
self._frozen_config.myopts.get("--autounmask-keep-masks", "n") != "n"
+ autounmask_keep_keywords =
self._dynamic_config.myparams['autounmask_keep_keywords']
+ autounmask_keep_license =
self._dynamic_config.myparams['autounmask_keep_license']
+ autounmask_keep_masks =
self._dynamic_config.myparams['autounmask_keep_masks']
+ autounmask_keep_use =
self._dynamic_config.myparams['autounmask_keep_use']
autounmask_level = self._AutounmaskLevel()
- autounmask_level.allow_use_changes = True
- yield autounmask_level
+ if not autounmask_keep_use:
+ autounmask_level.allow_use_changes = True
+ yield autounmask_level
- autounmask_level.allow_license_changes = True
- yield autounmask_level
+ if not autounmask_keep_license:
+
Re: [gentoo-dev] RFC: net-misc/curl: HTTP/3 support
On Thu, 2019-10-10 at 16:38 -0400, Mike Gilbert wrote: > On Thu, Oct 10, 2019 at 4:03 PM Craig Andrews wrote: > > I'm working on getting HTTP/3 support in place for curl: > > https://github.com/gentoo/gentoo/pull/12920 > > > > Yes, HTTP/3 isn't final yet. But we're Gentoo - that shouldn't stop us! > > > > My proposal involves: > > * A new USE_EXPAND, CURL_HTTP3, with two values: nghttp3 and quiche > > Why do we need a USE_EXPAND for this? Will more than one package ever use it? > > If it's only ever going to be referenced by net-misc/curl, just add > local USE flags. +1 to local. I know that curl mainainers have a history for adding redundant USE_EXPANDs for extra user complexity but that's not a reason to make things even worse. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: net-misc/curl: HTTP/3 support
On Thu, Oct 10, 2019 at 4:03 PM Craig Andrews wrote: > > I'm working on getting HTTP/3 support in place for curl: > https://github.com/gentoo/gentoo/pull/12920 > > Yes, HTTP/3 isn't final yet. But we're Gentoo - that shouldn't stop us! > > My proposal involves: > * A new USE_EXPAND, CURL_HTTP3, with two values: nghttp3 and quiche Why do we need a USE_EXPAND for this? Will more than one package ever use it? If it's only ever going to be referenced by net-misc/curl, just add local USE flags.
[gentoo-dev] Last rites: net-misc/ipsc
# Michał Górny (2019-10-10) # Upstream gone. Last bumped in 2006. EAPI 0. net-misc/sipcalc seems # like a good replacement. # Removal in 30 days. Bug #697236. net-misc/ipsc -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Mass keywording/stabilisation of ebuilds in app-emacs
On Thu, 10 Oct 2019 16:49:20 +0200 Ulrich Mueller wrote: > Most packages in the app-emacs category have stabilize-allarches in > their metadata because they are arch independent. However, their > keywords don't reflect this and differ from package to package, mostly > for historical reasons. > > So, I would like to mass keyword all ebuilds in app-emacs (as far as > stabilize-allarches applies to them) to the intersection of keywords > of their dependencies. Same applies to stabilisation; if an ebuild is > stable on amd64, I would stabilise it on all other arches, as far as > dependencies allow it. > > Also, any new package added to app-emacs in future would start out with > the complete set of keywords. (I am aware that this doesn't agree with > the policy as it is documented in the devmanual: > https://devmanual.gentoo.org/keywording/index.html#keywording-new-packages) > > Any objections? None. -- Sergei
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace
On 10.10.2019 13:04, Mike Pagano wrote: > On Wed, Oct 09, 2019 at 06:23:06PM -0700, Alec Warner wrote: >>On Wed, Oct 9, 2019 at 10:01 AM Mike Pagano <[1]mpag...@gentoo.org> >>wrote: >> >> This change will support moving the genpatches tarballs from >> /space/distfiles-local to >> the devspace ~developer/public_html/dist/genpatches >> >>I think it would help if you discussed why we were making this change. >>(I mean I can guess why, but it's not obvious.) >>-A >>Â > I was informed that use of /space/distfiles-local is deprecated in favor > of devspace. > > > https://devmanual.gentoo.org/general-concepts/mirrors/index.html > > This is not really true, (otherwise we would have to upload literally 8500 tarballs for texlive to my devspace). I'd say narrowing an eclass' URIs to the selected group of people is even worse for long-term usage. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mass keywording/stabilisation of ebuilds in app-emacs
> On Thu, 10 Oct 2019, Michał Górny wrote: > Wasn't ALLARCHES supposed to be applied only if a previous version had > a stable keyword on the arch in question? I.e. if it has been tested > by arch team at least once? Yes, but the same would apply to most of the elisp code that is shipped with app-editors/emacs itself, for which I doubt that it gets large coverage in arch testing. Either these things are arch independent, then I don't see why they couldn't have the same keywords as emacs itself. Or they are not, then they shouldn't have the allarches label in the first place. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Mass keywording/stabilisation of ebuilds in app-emacs
On Thu, 2019-10-10 at 16:49 +0200, Ulrich Mueller wrote: > Most packages in the app-emacs category have stabilize-allarches in > their metadata because they are arch independent. However, their > keywords don't reflect this and differ from package to package, mostly > for historical reasons. > > So, I would like to mass keyword all ebuilds in app-emacs (as far as > stabilize-allarches applies to them) to the intersection of keywords > of their dependencies. Same applies to stabilisation; if an ebuild is > stable on amd64, I would stabilise it on all other arches, as far as > dependencies allow it. > > Also, any new package added to app-emacs in future would start out with > the complete set of keywords. (I am aware that this doesn't agree with > the policy as it is documented in the devmanual: > https://devmanual.gentoo.org/keywording/index.html#keywording-new-packages) > > Any objections? > Wasn't ALLARCHES supposed to be applied only if a previous version had a stable keyword on the arch in question? I.e. if it has been tested by arch team at least once? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Mass keywording/stabilisation of ebuilds in app-emacs
Most packages in the app-emacs category have stabilize-allarches in their metadata because they are arch independent. However, their keywords don't reflect this and differ from package to package, mostly for historical reasons. So, I would like to mass keyword all ebuilds in app-emacs (as far as stabilize-allarches applies to them) to the intersection of keywords of their dependencies. Same applies to stabilisation; if an ebuild is stable on amd64, I would stabilise it on all other arches, as far as dependencies allow it. Also, any new package added to app-emacs in future would start out with the complete set of keywords. (I am aware that this doesn't agree with the policy as it is documented in the devmanual: https://devmanual.gentoo.org/keywording/index.html#keywording-new-packages) Any objections? Ulrich signature.asc Description: PGP signature
[gentoo-dev] Last rites: mail-mta/qmail-ldap
# Michał Górny (2019-10-10) # Unmaintained. Does not build. EAPI 0. # Removal in 30 days. Bug #696294. mail-mta/qmail-ldap -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] What is the source for https://dev.gentoo.org/~hollow/distfiles/genqmail-*
On Thu, 2019-10-10 at 14:48 +0200, Rolf Eike Beer wrote: > > > > > Please pick this up and move it somewhere into Gentoo git > > > > > infrastructure. I can transfer ownership to the Github Gentoo > > > > > organization if you would like. > > > > > Afterwards I just need someone to push the button and create a new > > > > > snapshot from that (preferably together with a git tag). > > > > > > > > Is there really a reason to do that? Since you're maintaining it, just > > > > keep > > > > it on your gh. > > > > > > I just want to prevent that the same thing happens again. > > > > I don't see a difference between a stale repo on your GitHub account > > and a stale repo on Gentoo Infra. Except the former is easy to fork, > > and the latter we have in dozens, and nobody knows what to do with them. > > Then let's at least move it into the Gentoo org on GitHub and give me push > access like it is for tatt. > We don't create any new repos on GitHub that aren't mirrors of git.g.o repos, and the remaining GitHub origins should be removed. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] What is the source for https://dev.gentoo.org/~hollow/distfiles/genqmail-*
> > > > Please pick this up and move it somewhere into Gentoo git > > > > infrastructure. I can transfer ownership to the Github Gentoo > > > > organization if you would like. > > > > Afterwards I just need someone to push the button and create a new > > > > snapshot from that (preferably together with a git tag). > > > > > > Is there really a reason to do that? Since you're maintaining it, just > > > keep > > > it on your gh. > > > > I just want to prevent that the same thing happens again. > > I don't see a difference between a stale repo on your GitHub account > and a stale repo on Gentoo Infra. Except the former is easy to fork, > and the latter we have in dozens, and nobody knows what to do with them. Then let's at least move it into the Gentoo org on GitHub and give me push access like it is for tatt. Eike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What is the source for https://dev.gentoo.org/~hollow/distfiles/genqmail-*
On Thu, 2019-10-10 at 12:31 +0200, Rolf Eike Beer wrote: > Am Donnerstag, 10. Oktober 2019, 12:15:09 CEST schrieb Michał Górny: > > Dnia October 10, 2019 9:39:38 AM UTC, Rolf Eike Beer > napisał(a): > > > Am Samstag, 21. September 2019, 10:50:07 CEST schrieb Rolf Eike Beer: > > > > Hi, > > > > > > > > I'm planning to do some cleanups to the qmail stuff. One thing s that > > > > the > > > > genqmail tarball is from 20080406 and needs to be patched itself, which > > > > makes things complicated. So, does anyone know what was the source of > > > > these tarballs? I can't look into the directory, maybe there are even > > > > older ones? > > > > Otherwise I would propose to just start a new git repo for that and do a > > > > new snapshot with the patches already incorporated. > > > > > > So I guess noone knows. Can someone assist me in creating a new upstream? > > > I > > > have created a new git repository with the original tarball and the 2 > > > existing patches, which can be found here: > > > https://github.com/DerDakon/genqmail > > > > > > Please pick this up and move it somewhere into Gentoo git infrastructure. > > > I > > > can transfer ownership to the Github Gentoo organization if you would > > > like. > > > Afterwards I just need someone to push the button and create a new > > > snapshot > > > from that (preferably together with a git tag). > > > > Is there really a reason to do that? Since you're maintaining it, just keep > > it on your gh. > > I just want to prevent that the same thing happens again. > I don't see a difference between a stale repo on your GitHub account and a stale repo on Gentoo Infra. Except the former is easy to fork, and the latter we have in dozens, and nobody knows what to do with them. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: EAPI 0 packages with no maintainer and no revdeps
04.10.2019 22:43:49, Michał Górny wrote: > # Michał Górny (2019-10-04) > # Unmaintained, EAPI 0 packages. No reverse dependencies. If you want > # them to stay, please port them to EAPI 7, and preferably become > # the maintainer. > # Removal in 30 days. Bug #696252. > net-mail/qmail-notify Hi, I would like to proxy-maint net-mail/qmail-notify. See the PR https://github.com/gentoo/gentoo/pull/13247 Petr
Re: [gentoo-dev] RFC: UID/GID assignment for deluge (545/545)
On 10.10.2019 04:59, Ulrich Mueller wrote: On Wed, 09 Oct 2019, Craig Andrews wrote: I would like to reserve UID/GID 545 for deluge (net-p2p/deluge). We currently use dynamic UID/GIDs. As far as I can tell, UID/GID 545 is free [1] [1] https://api.gentoo.org/uid-gid.txt No, there's this line: - 500..999 500..999 reserved I noticed that just after sending the email. Thank you for pointing it out. 454/454 is free, let's go with that. I've updated the PR as well. Thanks, ~Craig signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v4 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace
This change will support moving the genpatches tarballs from
/space/distfiles-local to
the devspace ~developer/public_html/dist/genpatches.
Additional modifications based on feedback.
Signed-off-by: Mike Pagano
---
eclass/kernel-2.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index c5f35cd3e..42307b963 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -295,7 +295,7 @@ handle_genpatches() {
UNIPATCH_LIST_GENPATCHES+=" ${DISTDIR}/${tarball}"
debug-print "genpatches tarball: $tarball"
fi
- GENPATCHES_URI+="
${use_cond_start}mirror://gentoo/${tarball}${use_cond_end}"
+ GENPATCHES_URI+=" ${use_cond_start}$(echo
https://dev.gentoo.org/\~{mpagano,whissi}/dist/genpatches/${tarball})${use_cond_end}"
done
}
--
2.21.0
--
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
Re: [gentoo-dev] What is the source for https://dev.gentoo.org/~hollow/distfiles/genqmail-*
Am Donnerstag, 10. Oktober 2019, 12:15:09 CEST schrieb Michał Górny: > Dnia October 10, 2019 9:39:38 AM UTC, Rolf Eike Beer napisał(a): > >Am Samstag, 21. September 2019, 10:50:07 CEST schrieb Rolf Eike Beer: > >> Hi, > >> > >> I'm planning to do some cleanups to the qmail stuff. One thing s that the > >> genqmail tarball is from 20080406 and needs to be patched itself, which > >> makes things complicated. So, does anyone know what was the source of > >> these tarballs? I can't look into the directory, maybe there are even > >> older ones? > > > >> Otherwise I would propose to just start a new git repo for that and do a > >> new snapshot with the patches already incorporated. > > > >So I guess noone knows. Can someone assist me in creating a new upstream? I > >have created a new git repository with the original tarball and the 2 > >existing patches, which can be found here: > >https://github.com/DerDakon/genqmail > > > >Please pick this up and move it somewhere into Gentoo git infrastructure. I > >can transfer ownership to the Github Gentoo organization if you would like. > >Afterwards I just need someone to push the button and create a new snapshot > >from that (preferably together with a git tag). > > Is there really a reason to do that? Since you're maintaining it, just keep > it on your gh. I just want to prevent that the same thing happens again. Eike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What is the source for https://dev.gentoo.org/~hollow/distfiles/genqmail-*
Dnia October 10, 2019 9:39:38 AM UTC, Rolf Eike Beer napisał(a): >Am Samstag, 21. September 2019, 10:50:07 CEST schrieb Rolf Eike Beer: >> Hi, >> >> I'm planning to do some cleanups to the qmail stuff. One thing is >that the >> genqmail tarball is from 20080406 and needs to be patched itself, >which >> makes things complicated. So, does anyone know what was the source of >these >> tarballs? I can't look into the directory, maybe there are even older >ones? >> Otherwise I would propose to just start a new git repo for that and >do a >> new snapshot with the patches already incorporated. > >So I guess noone knows. Can someone assist me in creating a new >upstream? I >have created a new git repository with the original tarball and the 2 >existing >patches, which can be found here: https://github.com/DerDakon/genqmail > >Please pick this up and move it somewhere into Gentoo git >infrastructure. I >can transfer ownership to the Github Gentoo organization if you would >like. >Afterwards I just need someone to push the button and create a new >snapshot >from that (preferably together with a git tag). Is there really a reason to do that? Since you're maintaining it, just keep it on your gh. > >If that is done I can switch over the netqmail ebuild to use the new >tarball >so we can start to phase out the old one. > >Eike > >P.S.: you can find me on Freenode as Dakon if that makes things go >faster -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace
On Wed, Oct 09, 2019 at 06:23:06PM -0700, Alec Warner wrote:
>On Wed, Oct 9, 2019 at 10:01 AM Mike Pagano <[1]mpag...@gentoo.org>
>wrote:
>
> This change will support moving the genpatches tarballs from
> /space/distfiles-local to
> the devspace ~developer/public_html/dist/genpatches
>
>I think it would help if you discussed why we were making this change.
>(I mean I can guess why, but it's not obvious.)
>-A
>Â
I was informed that use of /space/distfiles-local is deprecated in favor
of devspace.
https://devmanual.gentoo.org/general-concepts/mirrors/index.html
>
> Signed-off-by: Mike Pagano <[2]mpag...@gentoo.org>
> ---
> Â eclass/kernel-2.eclass | 4 +++-
> Â 1 file changed, 3 insertions(+), 1 deletion(-)
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index c5f35cd3e..0bc4f35de 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -295,7 +295,9 @@ handle_genpatches() {
> Â Â Â Â Â Â Â Â Â Â Â Â UNIPATCH_LIST_GENPATCHES+="
> ${DISTDIR}/${tarball}"
> Â Â Â Â Â Â Â Â Â Â Â Â debug-print "genpatches tarball:
> $tarball"
> Â Â Â Â Â Â Â Â fi
> -Â Â Â Â Â Â Â Â GENPATCHES_URI+="
> ${use_cond_start}mirror://gentoo/${tarball}${use_cond_end}"
> +Â Â Â Â Â Â Â Â GENPATCHES_URI+="
> ${use_cond_start}[3]https://dev.gentoo.org/~mpagano/dist/genpatches/
> ${tarball}${use_cond_end}
> +Â Â Â Â Â Â Â Â Â Â Â
> Â ${use_cond_start}[4]https://dev.gentoo.org/~whissi/dist/genpatches
> /${tarball}${use_cond_end}
> +Â Â Â Â Â Â Â Â Â Â Â
> Â ${use_cond_start}[5]https://dev.gentoo.org/~alicef/dist/genpatches
> /${tarball}${use_cond_end}"
> Â Â Â Â done
> Â }
> --
> 2.21.0
> --
> Mike Pagano
> Gentoo Developer - Kernel Project
> Gentoo Sources - Member
> E-Mail   : [6]mpag...@gentoo.org
> GnuPG FPÂ Â : EEE2 601D 0763 B60F 848CÂ 9E14 3C33 C650 B576 E4E3
> Public Key :
> [7]http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
>
> References
>
>1. mailto:mpag...@gentoo.org
>2. mailto:mpag...@gentoo.org
>3.
> https://dev.gentoo.org/~mpagano/dist/genpatches/${tarball}${use_cond_end}
>4. https://dev.gentoo.org/~whissi/dist/genpatches/${tarball}${use_cond_end}
>5. https://dev.gentoo.org/~alicef/dist/genpatches/${tarball}${use_cond_end}
>6. mailto:mpag...@gentoo.org
>7. http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
--
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
Re: [gentoo-dev] What is the source for https://dev.gentoo.org/~hollow/distfiles/genqmail-*
Am Samstag, 21. September 2019, 10:50:07 CEST schrieb Rolf Eike Beer: > Hi, > > I'm planning to do some cleanups to the qmail stuff. One thing is that the > genqmail tarball is from 20080406 and needs to be patched itself, which > makes things complicated. So, does anyone know what was the source of these > tarballs? I can't look into the directory, maybe there are even older ones? > Otherwise I would propose to just start a new git repo for that and do a > new snapshot with the patches already incorporated. So I guess noone knows. Can someone assist me in creating a new upstream? I have created a new git repository with the original tarball and the 2 existing patches, which can be found here: https://github.com/DerDakon/genqmail Please pick this up and move it somewhere into Gentoo git infrastructure. I can transfer ownership to the Github Gentoo organization if you would like. Afterwards I just need someone to push the button and create a new snapshot from that (preferably together with a git tag). If that is done I can switch over the netqmail ebuild to use the new tarball so we can start to phase out the old one. Eike P.S.: you can find me on Freenode as Dakon if that makes things go faster signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: UID/GID assignment for deluge (545/545)
> On Wed, 09 Oct 2019, Craig Andrews wrote: > I would like to reserve UID/GID 545 for deluge (net-p2p/deluge). > We currently use dynamic UID/GIDs. > As far as I can tell, UID/GID 545 is free [1] > [1] https://api.gentoo.org/uid-gid.txt No, there's this line: - 500..999 500..999 reserved signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v3 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace
> On Thu, 10 Oct 2019, Mike Pagano wrote:
> + GENPATCHES_URI+=" ${use_cond_start}$(echo
> https://dev.gentoo.org/~{mpagano,whissi}/dist/genpatches/${tarball})${use_cond_end}"
The ~ should be backslash-escaped or quoted, otherwise it will be
expanded if there's a user mpagano or whissi on the system. :-)
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Disable --autounmask auto-unmasking keywords / masks by default
On 10/9/19 7:57 PM, Kent Fredric wrote: > On Wed, 9 Oct 2019 19:45:34 -0700 > Zac Medico wrote: > >> I'd prefer to disable --autounmask by default and include warnings about >> harmful behavior in the documentation. > > I think autounmasks behaviour with regards to USE flags is useful, > (heh), its just everything else it does tends to violate stability > assumptions. > > For instance, I can see why automatically escalating "arch" to "~arch" > may be useful in some cases, but its a very dangerous default, > *especially* for perl. We can add --autounmask-use= option that's enabled by default when --autounmask is unspecified. When --autounmask=y is specified, we'll have full autounmask behavior. When --autounmask=n is specified, we'll have --autounmask-use=n behavior. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
