[gentoo-dev] Re: Confirm unsubscribe from gentoo-dev@lists.gentoo.org
On 7/5/23 22:58, gentoo-dev+h...@lists.gentoo.org wrote: Somebody (and we hope it was you) has requested that the email address be removed from the list. To confirm you want to do this, please send a message to which can usually be done simply by replying to this message. The subject and the body of the message can be anything. After doing so, you should receive a reply informing you that the operation succeeded. If you do not want to do this, simply ignore this message.
RE: [gentoo-dev] Re: EGO_SUM
> This way ridiculously large manifests are gone out of ::gentoo. But overlays > can > still use the EGO_SUM method for their go packages if a tarball is too much of > a hassle. And everyone is happy. It is then the responsibility of the overlay > maintainers to ensure that their manifests don't grow out of hand. A warning > from the eclass and/or pkgcheck should ensure that they are aware of the > potential problem. > > What am I missing? I truly do not understand why this matter is not resolved > already and why we continue to have this discussion again and again. The > solution just seems so simple. I agree with this as a viable solution, hosting vendor tarballs with the gentoo infrastructure is possible, though there would need to be a way to support proxy maintainers in uploading and hosting them, but to deprecate it and move on to removing it as an option for overlays is, in my view, a poor move. It adds a significant burden to overlay maintainers, who may have to move to paying for hosting of the vendor tarballs, forking repositories, or even not contributing at all. Chris
Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode?
I’d be inclined to agree with this take, seems sensible, although I’d also think the removal of freenode could be very reasonable given their actions have at best demonstrated extremely poor judgement to the detriment of users, or at worst maliciousness. The other thing could be a freenode use flag that would mean freenode isn’t included unless the user includes it in their use flag? Might be a bit too much work for marginal gains though Chris From: Ulrich Mueller Sent: Wednesday, June 16, 2021 10:21 am To: Michał Górny Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode? >>>>> On Wed, 16 Jun 2021, Michał Górny wrote: > We've moved our official support channels from Freenode to Libera.chat. > All that's happened afterwards pretty much proves that this was > the right decision. Maybe even to the point of saying that staying > on Freenode would be dangerous to our users (e.g. because of the late > NickServ impersonations, ops with bad reputation etc.). > However, there are still IRC clients in Gentoo that default to Freenode. > I think the next questions we need to answer are: > 1. Should we be proactively changing the default network in IRC clients > (provided they have one) from Freenode to Libera.chat? Yes. IMHO Freenode is no longer a reasonable default. > 1a. If yes, then should we also make a change if clients default to > network other than Freenode? No. > 2. Should we be proactively *removing* Freenode from the network list > in IRC clients (provided they have one)? No (but also don't re-add it if upstream decided to remove it). > 2a. Should we be adding Libera.chat to the list even if we do not remove > Freenode? Yes. We have our channels there, so it is reasonable to have the network in the list. Ulrich
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On Sat, 6 Jun, 2020 at 14:50, Aaron Bauman wrote: All, the graphics project has now been disbanded. All packages have been reassigned to maintainer-needed. Bugs will be reassigned soon. Here are a list of the packages that are now up for grabs: ... media-gfx/gnofract4d GitHub PR updated with proxy-maint metadata update: https://github.com/gentoo/gentoo/pull/15987 Chris
[gentoo-portage-dev] [PATCH] man/emerge.1: fix logrotate directory containing elog-save-summary
Signed-off-by: Chris Mayo --- man/emerge.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/emerge.1 b/man/emerge.1 index 2261a771b..28b7f79f5 100644 --- a/man/emerge.1 +++ b/man/emerge.1 @@ -1491,7 +1491,7 @@ Contains a log of all the fetches in the previous emerge invocation. .TP .B /var/log/portage/elog/summary.log -Contains the emerge summaries. Installs \fI/etc/logrotate/elog-save-summary\fR. +Contains the emerge summaries. Installs \fI/etc/logrotate.d/elog-save-summary\fR. .SH "SEE ALSO" .BR "emerge \-\-help", .BR quickpkg (1), -- 2.24.1
[gentoo-dev] [PATCH 1/2] waf-utils.eclass: Support --docdir and --htmldir
waf can optionally set the standard GNU directories [1]. Based on the code for econf in Portage's phase-helpers.sh. [1] https://waf.io/apidocs/tools/gnu_dirs.html Closes: https://bugs.gentoo.org/711612 Signed-off-by: Chris Mayo --- Fixes QA problem with media-video/mpv-0.32.0-r1 reported in the linked bug. eclass/waf-utils.eclass | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass index 2cb26bc8dfd..a944195b162 100644 --- a/eclass/waf-utils.eclass +++ b/eclass/waf-utils.eclass @@ -69,7 +69,7 @@ waf-utils_src_configure() { [[ ${fail} ]] && die "Invalid use of waf-utils.eclass" - local libdir=() + local conf_args=() # @ECLASS-VARIABLE: WAF_BINARY # @DESCRIPTION: @@ -81,7 +81,15 @@ waf-utils_src_configure() { # @DESCRIPTION: # Variable specifying that you don't want to set the libdir for waf script. # Some scripts does not allow setting it at all and die if they find it. - [[ -z ${NO_WAF_LIBDIR} ]] && libdir=(--libdir="${EPREFIX}/usr/$(get_libdir)") + [[ -z ${NO_WAF_LIBDIR} ]] && conf_args+=(--libdir="${EPREFIX}/usr/$(get_libdir)") + + local waf_help=$("${WAF_BINARY}" --help 2>/dev/null) + if [[ ${waf_help} == *--docdir* ]]; then + conf_args+=( --docdir="${EPREFIX}"/usr/share/doc/${PF} ) + fi + if [[ ${waf_help} == *--htmldir* ]]; then + conf_args+=( --htmldir="${EPREFIX}"/usr/share/doc/${PF}/html ) + fi tc-export AR CC CPP CXX RANLIB @@ -91,7 +99,7 @@ waf-utils_src_configure() { PKGCONFIG="$(tc-getPKG_CONFIG)" "${WAF_BINARY}" "--prefix=${EPREFIX}/usr" - "${libdir[@]}" + "${conf_args[@]}" "${@}" configure ) -- 2.24.1
[gentoo-dev] [PATCH 2/2] waf-utils.eclass: Replace NO_WAF_LIBDIR with an automatic check
Test `waf --help` for --libdir support instead. Signed-off-by: Chris Mayo --- NO_WAF_LIBDIR only used by dev-libs/tut. emerge's OK after this patch. eclass/waf-utils.eclass | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass index a944195b162..7a894f6bbb7 100644 --- a/eclass/waf-utils.eclass +++ b/eclass/waf-utils.eclass @@ -69,19 +69,12 @@ waf-utils_src_configure() { [[ ${fail} ]] && die "Invalid use of waf-utils.eclass" - local conf_args=() - # @ECLASS-VARIABLE: WAF_BINARY # @DESCRIPTION: # Eclass can use different waf executable. Usually it is located in "${S}/waf". : ${WAF_BINARY:="${S}/waf"} - # @ECLASS-VARIABLE: NO_WAF_LIBDIR - # @DEFAULT_UNSET - # @DESCRIPTION: - # Variable specifying that you don't want to set the libdir for waf script. - # Some scripts does not allow setting it at all and die if they find it. - [[ -z ${NO_WAF_LIBDIR} ]] && conf_args+=(--libdir="${EPREFIX}/usr/$(get_libdir)") + local conf_args=() local waf_help=$("${WAF_BINARY}" --help 2>/dev/null) if [[ ${waf_help} == *--docdir* ]]; then @@ -90,6 +83,9 @@ waf-utils_src_configure() { if [[ ${waf_help} == *--htmldir* ]]; then conf_args+=( --htmldir="${EPREFIX}"/usr/share/doc/${PF}/html ) fi + if [[ ${waf_help} == *--libdir* ]]; then + conf_args+=( --libdir="${EPREFIX}/usr/$(get_libdir)" ) + fi tc-export AR CC CPP CXX RANLIB -- 2.24.1
Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed
On 03/09/17 22:22, Michael Orlitzky wrote: > On 09/03/2017 11:56 AM, Chris Mayo wrote: >> # >> # The following snippet would suggest app-misc/foo for optional foo support, >> # app-misc/bar or app-misc/baz[bar] for optional bar support >> > > Would the @EXAMPLE tag[0] make sense here? > > > [0] https://devmanual.gentoo.org/eclass-writing/index.html > I believe @EXAMPLE is only for the first documentation block introducing the eclass. At least where it is used for functions the text doesn't show up in the man page. e.g. prefix.eclass hprefixify() and prefixify_ro() https://devmanual.gentoo.org/eclass-reference/prefix.eclass/index.html https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/prefix.eclass?id=61b861acd7b49083dab687e133f30f3331cb7480
[gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed
--- Please consider this clarification of optfeature. Chris eclass/eutils.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass index fe4339f6b89..f35fa5980d7 100644 --- a/eclass/eutils.eclass +++ b/eclass/eutils.eclass @@ -827,8 +827,8 @@ use_if_iuse() { # @FUNCTION: optfeature # @USAGE: [other atoms] # @DESCRIPTION: -# Print out a message suggesting an optional package (or packages) which -# provide the described functionality +# Print out a message suggesting an optional package (or packages) +# not currently installed which provides the described functionality. # # The following snippet would suggest app-misc/foo for optional foo support, # app-misc/bar or app-misc/baz[bar] for optional bar support -- 2.13.5
[gentoo-dev] [PATCH] systemd.eclass: Improve systemd_install_serviced documentation
Signed-off-by: Chris Mayo <aklh...@gmail.com> --- Nothing added, just suggesting how it could be made easier to understand. Chris eclass/systemd.eclass | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass index 7e46e80119c..49f7480228b 100644 --- a/eclass/systemd.eclass +++ b/eclass/systemd.eclass @@ -178,12 +178,12 @@ systemd_newuserunit() { } # @FUNCTION: systemd_install_serviced -# @USAGE: [] +# @USAGE: [] # @DESCRIPTION: -# Install the file as service.d/00gentoo.conf template. -# The argument specifies the configured service name. -# If not specified, the configuration file name will be used with .conf -# suffix stripped (e.g. foo.service.conf -> foo.service). +# Install as the template .d/00gentoo.conf. +# If is not specified +# with the .conf suffix stripped is used +# (e.g. foo.service.conf -> foo.service.d/00gentoo.conf). systemd_install_serviced() { debug-print-function ${FUNCNAME} "${@}" -- 2.13.0
[gentoo-dev] Last rites: app-office/openproj-bin
# Chris Reffett <creff...@gentoo.org> (08 Jan 2017) # Superseded by projectlibre-bin, please migrate to that. # Masked for removal in 30 days. app-office/openproj-bin signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] [PATCH] man/emaint.1: Add sync to synopsis and fix its in sync --auto
Signed-off-by: Chris Mayo <aklh...@gmail.com> --- man/emaint.1 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/emaint.1 b/man/emaint.1 index 24e4744..4617ef8 100644 --- a/man/emaint.1 +++ b/man/emaint.1 @@ -5,7 +5,7 @@ emaint \- performs package management related system health checks and maintenan .BR emaint [\fIoptions\fR] [\fBall\fR | \fBbinhost\fR | \fBcleanresume\fR | \ -\fBmerges\fR | \fBmovebin\fR | \fBmoveinst\fR | \fBworld\fR] +\fBmerges\fR | \fBmovebin\fR | \fBmoveinst\fR | \fBsync\fR | \fBworld\fR] .SH DESCRIPTION The emaint program provides a command line interface to package management health checks and maintenance. @@ -85,7 +85,7 @@ deleted. .SH OPTIONS sync command only .TP .B \-a, \-\-auto -Sync repositories which have its auto\-sync setting set yes, true. +Sync repositories which have their auto\-sync setting set yes, true. .TP .B \-A, \-\-allrepos Sync all repositories which have a sync\-uri specified. -- 2.10.2
[gentoo-dev] [PATCH] eutils.eclass: add 512 icon size to doicon documentation
Signed-off-by: Chris Mayo <aklh...@gmail.com> --- Sent as requested on https://github.com/gentoo/gentoo/pull/3298 eclass/eutils.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass index aaf195b..d868467 100644 --- a/eclass/eutils.eclass +++ b/eclass/eutils.eclass @@ -1062,7 +1062,7 @@ _iconins() { #!!! must specify to install into /usr/share/icons/... !!! #size of the icon, like 48 or 48x48 #supported icon sizes are: -#16 22 24 32 36 48 64 72 96 128 192 256 scalable +#16 22 24 32 36 48 64 72 96 128 192 256 512 scalable # -c, --context #defaults to "apps" # -t, --theme -- 2.10.2
Re: [gentoo-dev] New Working Group established to evaluate the stable tree
On August 14, 2016 5:49:48 PM EDT, Kent Fredricwrote: >On Sun, 14 Aug 2016 22:45:07 +0100 >Ciaran McCreesh wrote: > >> What's a Working Group, and how is it related to a Project? Shouldn't >> there be a GLEP to define what a Working Group is first? > >So if a group of people wanted to write such a GLEP ... would they have >to be part of a defined Project first, or would they form a Working >Group, and then be stuck in a recursive loop needing themselves >defined before they can define themselves? Friendly reminder that anyone may submit a GLEP, it doesn't need to be on behalf of an official group. If memory serves, there isn't even a requirement that the submitter/"champion" even be a Gentoo dev. So although there is a theoretical recursion issue, in practice it's a silly question. creffett -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] New project: Theology
A bit late, but official announcement of the herd->project conversion of theology to follow GLEP 67. https://wiki.gentoo.org/wiki/Project:Theology creffett signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: ban EAPI 1
On 6/10/2015 4:43 PM, Ulrich Mueller wrote: Hi, The number of EAPI 1 ebuilds in the Portage tree has decreased to a total of 60, corresponding to 0.16 %. We briefly discussed in the QA team if we should demote EAPI 1 in layout.conf from eapis-deprecated to eapis-banned. This would have the consequence that repoman would refuse to commit packages containing such ebuilds. AFAICS there would be no impact on users. What do you think? Ulrich Make it so.
[gentoo-dev] retiring
Hi all, I've been here for a couple years now, and I've lost interest to the point that I'm not doing a very good job of keeping my own system up to date, much less maintaining ebuilds. That isn't fair to anyone at all. It's time for me to move on. Gentoo is a great distro. I've met plenty of awesome, smart people around here, and I've learned a lot from my Gentoo experience. Thanks, and so long. Best wishes to the Gentoo community for 2015 and beyond. -- Chris
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
On 8/18/2014 8:56 AM, hasufell wrote: hasufell: Even more interesting... you can work around this by inheriting base.eclass explicitly before e.g. unpacker.eclass, something like inherit base unpacker games = unpacker_src_unpack() is carried out by default (and the ebuild breaks if someone thinks the base.eclass is useless and removes it) inherit unpacker games = unpacker_src_unpack is not carried out by default although games.eclass does not directly overwrite it If you think any of this is sensible... Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3. Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when. Chris Reffett
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-08-18, o godz. 09:22:46 Chris Reffett creff...@gentoo.org napisał(a): On 8/18/2014 8:56 AM, hasufell wrote: Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3. Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when. Right now, we have no kind of repoman for eclasses. If you have time to work on such a thing, please do. Otherwise, all we can do is put more checks in ebuilds but that triggers the warning for the wrong people... I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils and games eclasses, and I don't explicitly define src_compile, repoman full could pop up a warning like src_compile is ambiguous between cmake-utils_src_compile and games_src_compile, please explicitly define this phase and call the appropriate eclass function. I imagine that this would pop up a lot of warnings, but I feel like it would improve readability and make it explicit what should be going on where. I concede that it could make a lot more boilerplate code in ebuilds, so that's a potential issue, mostly just throwing out an idea here. Chris Reffett
Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/12/2014 9:26 AM, Rich Freeman wrote: [snip] I don't have a problem with QA recommending new tree policies, but if they're going to do this the QA team ought to first ensure that the team agrees (however they want to govern that), and then communicate the policy before implementing it. I'd also implement it in documentation before doing so in repoman, otherwise we're going to have a repoman full of 800 rules whose origin is a mystery. I'm fine with QA policies going into effect by default, but communicating them allows objections to be raised and an appeal made to Council if necessary before we get too far along. This isn't just about due process - it is hard for developers to even comply with a policy they are unaware of. Rich This isn't a QA policy, was not run by us as far as I can tell, and I don't know where it came from or why it was added. +1 for revert, if people want to run this by Council or QA later and actually get an official decision we can talk about putting it back, but for now it's generating a lot of noise for no real benefit. It's useless checks like this that make people ignore repoman warnings. Chris Reffett QA Team Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlPqXvAACgkQ23laikJhg1QvTQCffjAZYIzBGBRlp1l/y6iydzTQ 3d0An12lbTbzr7nWe37qtoay7ktWUAs6 =6c3E -END PGP SIGNATURE-
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote: [snip] Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't see any future of this system unless it's coded in portage. Today - portage support without server side - tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for Portage QOS or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying we should have (some feature) doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote: [snip] Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't see any future of this system unless it's coded in portage. Today - portage support without server side - tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for Portage QOS or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying we should have (some feature) doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote: [snip] Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't see any future of this system unless it's coded in portage. Today - portage support without server side - tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for Portage QOS or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying we should have (some feature) doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 11:46:54 AM EDT, Chris Reffett creff...@gentoo.org wrote: On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote: [snip] Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't see any future of this system unless it's coded in portage. Today - portage support without server side - tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for Portage QOS or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying we should have (some feature) doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett Apologies for multiple emails getting sent, on a mobile connection here and it reported a failure to send. My bad. Chris Reffett -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] Help with EAPI bumps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, It's been a QA team objective for some time to help get rid of older EAPI ebuilds in-tree. I personally will be spending some time in the next couple weeks working on this, but I we on the QA team would appreciate it if the developer community in general could contribute, especially with packages that are either maintainer-needed or in herds which have low activity. To play things safe, please revbump and file stable requests when doing the EAPI change (rather than directly bumping EAPI). Thanks in advance for the help! Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPhekUACgkQ23laikJhg1Q12ACfZgY5sei2KvpBbimA5QTaT85K etIAnA1AbRs2AsrqFKiaVWgvtxAERaxe =chii -END PGP SIGNATURE-
Re: [gentoo-dev] Making a common sub-profile for no-multilib
On June 25, 2014 2:44:57 PM EDT, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-06-25, o godz. 13:01:48 Ian Stakenvicius a...@gentoo.org napisał(a): At the moment there are two profiles in particular that do this, amd64/no-multilib and hardened/linux/uclibc/amd64 .. It's possible or likely there are others, too, on other arches perhaps. In general, it's good that repoman notices this because those profiles don't support having the 32bit deps installed. However, if one of those profiles ever moves from a dev profile to a stable one (and blueness mentioned he would like to make uclibc/amd64 stable), then those dependency.badindev warnings will suddenly turn into dependency.bad errors. The solution to this would seem to be to package.mask all of these 32-bit packages in the pure 64bit profiles. However, having to do this in multiple locations is annoying. I would like to propose adding 'no-multilib/[arch]/package.mask' sub-profile(s), to allow all of these masks to go in one place. Populating package.mask should be fairly easy for amd64 at least, since anything depending on an app-emulation/emul-* will need to be masked. However the merits of where the package.mask will go needs discussion. Perhaps, for instance, it's time to adjust the profile tree hierarchy more aggressively instead of piling on with yet another subdir. Forgive me for using such a words, but the profile tree is a well stacked pile of crap. We have a dozen random profiles for each arch then a dozen other profiles forked off them 'because the generic arch profiles have crap' and a lot of profiles that inherit others in a complex and semi-random manner. For example, abi_x86_64 and abi_x86_32 each need to be forced in 4 profiles. This proves that we have 4 distinct profiles for amd64 which need to be kept in sync. If I change something, I need to perform the change in 4 different profiles and make sure I didn't screw something up. Then there's the x32 profile that inherits amd64 profile and therefore requires reverting some of the stuff done on amd64. To do a complete common change to x86-family multilib (like adding IUSE_IMPLICIT) I have to modify 9 profiles. Now let's add to this circa 8 mips profiles, around 3 ppc profiles, 4 arm profiles and some more. Every arch organized in somewhat different and totally non-documented manner. Long story short, doing anything to Gentoo profiles is utter pain and comes with random breakage guarantee. Therefore, I'm asking -- nuke those damn profiles, and start over! The current situation is completely unmaintainable. +1, I'm all for replacing it with something more usable. I personally would favor the mix-in approach, but just about anything would be better than the weird setup we have right now. Chris
Re: [gentoo-dev] Making an overlay publicly available?
On 06/20/2014 04:05 PM, Jauhien Piatlicki wrote: Hi, I was not able to google instructions, but you need to file a bug, something like https://bugs.gentoo.org/show_bug.cgi?id=510028 Ask on gentoo-infra IRC channel for more information. I think we should add instructions to some place on our wiki, where one can easy google them. Regards, Jauhien Hi Jauhien, Tim, Having gone though this recently myself and finding the instructions linked at the bottom of this wiki page; https://www.gentoo.org/proj/en/overlays/userguide.xml I can say the process is fairly straight forward. Although, do give them some time to process your request. From start to finish you must be patient. Best Regards, -Christopher Camisa
Re: [gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2014-04-27 23h59 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/28/2014 9:41 AM, Sergey Popov wrote: 28.04.2014 17:30, Ciaran McCreesh пишет: On Mon, 28 Apr 2014 17:08:28 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 04/28/2014 04:56 PM, hasufell wrote: What is going on here? Doesn't look right. The commit messages don't give an understandable reason. It was added to the tree by someone outside the Qt team without permission. Since it's not ready for the tree yet, it was immediately removed again. So the Qt team is overriding the QA team now? Is it alphabetical? As a Qt team lead i want to say that there is no permission for me or pesa(as the main maintainer of Qt Framework packages) for importing Qt 5 in tree. So, i kindly asks zlogene to remove that stuff from main tree. As QA team member - there was no serious QA issue here - ebuilds, even semi-broken, was bringed with apropriate masks, so - no damage on users's systems. Saying that a Qt team member did something wrong because he reverted an action taken by someone who happens to be a member of the QA team is like saying that I can't revert something done by a council member to one of my packages just because they happen to be on the council. As Pinkbyte said, there was no QA issue here, just a developer being quick on the trigger, so the membership of any parties in QA is irrelevant to the discussion. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNeW8IACgkQ23laikJhg1RQ6wCbBVdKKUe0J9n74CPBOmOdWmvz JqEAmgM5PuT29aF5Djyp6X1thdo2z/WX =E9g0 -END PGP SIGNATURE-
Re: [gentoo-dev] can we get a clang herd/project?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 03:19 PM, Michał Górny wrote: Dnia 2014-03-03, o godz. 20:01:25 hasufell hasuf...@gentoo.org napisał(a): I'm tired of looking all the maintainers up manually and adding each one to CC list of bug reports. Why is there no herd or project? Not sure what gentoo-dev ml has to do with it... ...but I've filed bug 503354 [1] to create the alias. [1]:https://bugs.gentoo.org/show_bug.cgi?id=503354 Any dev may create a new project just by creating a new project page on the wiki.gentoo.org (see Gentoo_Wiki:Developer_Central/Project_pages) and sending a Request For Comments (RFC) e-mail to gentoo-dev. Note that this GLEP does not provide for a way for the community at large to block a new project, even if the comments are wholly negative. (GLEP39) If he wants there to be a herd/project, this is entirely the right place to say so :) Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlMU5thfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1S9DACeNLZGwG6XqsHwl3caNwOIEsKq 7g0AoJ7IQq2dcIM0qqVGur0sDLBh9sTT =sKf+ -END PGP SIGNATURE-
[gentoo-dev] February 2014 QA policy updates
Hello all, The following are the policy changes from this month's QA team meeting: -USE=multislot (and other USE-dependent SLOT values) need to be removed from the tree. Toolchain can keep it in an overlay if they want. We would consider it acceptable to remove USE=multislot from the tree but keep the eclasses as-is, so that toolchain doesn't need to maintain multiple eclasses. This does not affect sys-boot/grub's USE=multislot, as that does not mangle the SLOT value like the others (as I understand it). -Regarding the gtk/gtk2/gtk3 USE flag situation: we mandate that gtk move to versioned USE flags. For simplicity of migration, we will allow USE=gtk to mean depend on gtk2, since there are only a few USE=gtk2 remaining in tree. USE=gtk3 will mean depend on gtk3, and in the future, USE=gtk4 will mean depend on gtk4, and so on. USE=gtk may not be used to mean depend on some version of gtk. -More generally: we recommend that in future situations like this (a package can optionally depend on different versions of a library), we recommend the use of versioned USE flags. It should be discussed with the QA team either way. Also, on a non-policy note, we recommend that the Council deprecate EAPIs 0 and 3 (0 pending discussion with toolchain) and ban EAPI 1. As always, if you have questions, feel free to ping us in #gentoo-qa. The meeting summary and these policies will be available on the Quality Assurance page on the Gentoo Wiki tonight or tomorrow. Chris Reffett Gentoo QA Lead
Re: [gentoo-portage-dev] [PATCH v2] Add --output-style option to repoman
On 02/13/2014 10:42 AM, Brian Dolbec wrote: On Thu, 13 Feb 2014 03:19:35 -0500 Mike Frysinger vap...@gentoo.org wrote: On Monday, February 10, 2014 20:22:36 Chris Reffett wrote: This patch adds a --output-style option to repoman, which gives the user a choice of output formats for the repoman checks. Choices are default (current style) and column (a greppable format), but it should be easy to add more. Fixes bug 481584. i'd expect a proper structured output would make sense to include in the default set. like JSON. just create a dict and send it to json.dump(). He is working on more changes to repoman and the output. So, if you can, Chris, then do it, add a json option. Will do that after my next set of changes to repoman (to be emailed shortly) v2: Fix docstring to be complete and in the standard format, make use of default choices in --output-style wrt comments by antarus and dol-sen erm, i thought the previous docstring was correct. it followed PEP257 while this new one is like javadoc or something. It is the existing format that has been around in portage for years. There is even a page for it: http://www.gentoo.org/proj/en/portage/doc/policies/docstring-spec.xml It is also the style that epydoc recognizes. -utilities.format_qa_output(f, stats, fails, dofull, dofail, options, qawarnings) +if options.output_style == 'column': + utilities.format_qa_output_column(f, stats, fails, dofull, dofail, options, qawarnings) +else: + utilities.format_qa_output(f, stats, fails, dofull, dofail, options, qawarnings) use a func pointer instead. format_outputs = { 'column': utilities.format_qa_output_column, 'default': utilities.format_qa_output, } format_output = format_outputs.get(options.output_style, format_outputs['default']) format_output(f, stats, fails, dofull, dofail, options, qawarnings) yeah, make it so. Good spot, Mike Committed, thanks for the spot. Since Mike was too slow in replying, make another commit to change it. + formatter.add_literal_data(NumberOf + category + ) prefer to use % rather than + like so: 'NumberOf %s ' % category + formatter.add_literal_data(%s % number) well actually, for simple additions like that, string1 + string2, it is actually faster. But for multiple additions, %s is much better, faster. Also if the string is translated, then use %s regardless. That way the %s can be moved around for the translation. str(number) -mike
[gentoo-portage-dev] [PATCH 0/2] Refactor repoman QA handling
This series of patches alters repoman's QA output to be much more usable. The first patch changes all checks to output a list of either length 1 or 2, splitting the file with the error from the error itself. This will be helpful for making machine-parseable output in the future. The second both makes the variables used to build the output much more consistent and makes the output itself more consistent by removing a few instances where the full path was printed rather than the relative path. This will change the existing repoman output format and potentially break scripts which rely on the old and inconsistent behavior. Chris Reffett (2): Split output for repoman checks into file and message Repoman check code cleanup bin/repoman | 232 +++ pym/repoman/utilities.py | 18 +++- 2 files changed, 128 insertions(+), 122 deletions(-) -- 1.8.5.3
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On 2/12/2014 3:09 AM, Michał Górny wrote: Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages that may support either or both the toolkits. To handle this, a few developers have introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit versions are supported. At this point, the Gnome team highly recommends prefering gtk3 if possible, skipping the useflag altogether. [1] Wrong, as is written in policy whether to prefer gtk2 or 3 is up to the maintainer of the package. We point people to the fact that upstream says gtk2 is a dead end and support will stop (if not in fact already stopped) in the near future. We also recommend to have maintainers support slots for their libs where possible considering man-power and to only choose one toolkit for applications considering where upstream development is going and maturity of the port, and again, this is up to package maintainers. This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. Except when you end up rebuilding the huge thing twice. Or trying to live with binpackages -- the thing that most Gentoo developers don't care about at all. They just love their precious USE flags so much they'd shove them everywhere for the sake of it. You'll have to build it twice anyway, this just splits it into two separate packages, and I suspect that the times where you will have to rebuild are when a package needs webkit-gtk to support another toolkit (which should happen only once), and when you upgrade (in which case you would be updating them separately anyway). I also fail to see what this has to do with binpkgs: if something needs webkit-gtk[gtk2], you add a dep on webkit-gtk[gtk2]. The user adds USE=gtk2 to webkit-gtk if needed, webkit-gtk binpkg gets rebuilt. I see no breakage there. Chris Reffett
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: Thanks for attaching link to team's policy which tries to lift any kind of ambiguities people may have for what concerns gnome team's packages, I hope it proved useful in your discussions. Le mercredi 12 février 2014 à 00:39 +0200, Alex Alexander a écrit : Hello fellow developers, In the first meeting of the new QA team, we discussed the state of the gtk{,2,3} USE flags in the main tree. [0] In its current state, USE=gtk means gtk2. The Gnome team is trying to change this into the most recent gtk version (it is a work in progress). Wrong, gtk USE flag means enable gtk support, whether this is gtk 1, 2 or 3 depends on what the package (presumably library) supports and whether is can be slotted or not and whether current gentoo maintainer decides what can be reasonably supported. Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages that may support either or both the toolkits. To handle this, a few developers have introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit versions are supported. At this point, the Gnome team highly recommends prefering gtk3 if possible, skipping the useflag altogether. [1] Wrong, as is written in policy whether to prefer gtk2 or 3 is up to the maintainer of the package. We point people to the fact that upstream says gtk2 is a dead end and support will stop (if not in fact already stopped) in the near future. We also recommend to have maintainers support slots for their libs where possible considering man-power and to only choose one toolkit for applications considering where upstream development is going and maturity of the port, and again, this is up to package maintainers. This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. Some developers choose to follow the Gnome team's highlights, while others choose to go their own way. The QA team would like to establish a guideline that solves this problem in the best way possible. During our discussion, it was pointed out that keeping a generic USE=gtk is sub-optimal. The non-straightforward nature of new toolkit versions makes transitioning from one to the other a slow, tedius process and we think that a non-versioned USE flag makes things even worse. A few of our members recommended a move away from the unversioned USE=gtk to versioned-only USE flags. Qt managed to do this quite successfully when they transitioned from the unversioned USE=qt (that actually meant qt3) to USE=qt4. The benefits can be seen now that qt5 is around the corner. USE=qt5 is straightforward, does not mess with qt4 packages and was introduced to the tree without messing with current packages too much - other than adding a new use flag where appropriate. There is also no need for USE=qt anymore. To achieve this, version 3 of gtk should always be enabled by USE=gtk3. At some point in the future, when gtk2 consumers reach zero, we will retire gtk for good. Then, if some day gtk4 comes around, we will be able to introduce support for it in the tree by simply adding USE=gtk4, without having to re-structure half the tree. We are reaching out to the developer community to hear your thoughts and ideas on the matter. We would like to reach a decision that could possibly affect and direct the state of whole tree. This decision could then be turned into a policy, improving Gentoo's consistency across the tree. Imho the whole discussion stems for packages maintainers which, as you have written, did not follow our recommendation and tried to provided application with both gtk2 and gtk3 support. I agree that Gentoo is about choice... however as a maintainer of a lot of packages, it is unreasonable to try to support two configuration where one is dying slowly due to upstream (gtk) maintainer focus being elsewhere, hence why we wanted maintainers to choose. Instead, it occurs that some decided not to choose or to stop users from annoying them with 100 of duplicate bugs about not providing the alternative. Looking at the situation from a gnome team member perspective when Gnome 3 was introduced to the tree, only three packages (providing libs) needed exception to the rule to avoid
[gentoo-portage-dev] [PATCH v2] Add --output-style option to repoman
This patch adds a --output-style option to repoman, which gives the user a choice of output formats for the repoman checks. Choices are default (current style) and column (a greppable format), but it should be easy to add more. Fixes bug 481584. v2: Fix docstring to be complete and in the standard format, make use of default choices in --output-style wrt comments by antarus and dol-sen --- bin/repoman | 15 ++- pym/repoman/utilities.py | 44 2 files changed, 58 insertions(+), 1 deletion(-) diff --git a/bin/repoman b/bin/repoman index 3504b6b..c7a1c4c 100755 --- a/bin/repoman +++ b/bin/repoman @@ -144,9 +144,16 @@ def ParseArgs(argv, qahelp): 'scan' : 'Scan directory tree for QA issues' } + output_choices = { + 'default' : 'The normal output format', + 'column' : 'Columnar output suitable for use with grep' + } + mode_keys = list(modes) mode_keys.sort() + output_keys = sorted(output_choices) + parser = ArgumentParser(usage=repoman [options] [mode], description=Modes: %s % | .join(mode_keys), epilog=For more help consult the man page.) @@ -228,6 +235,9 @@ def ParseArgs(argv, qahelp): parser.add_argument('--without-mask', dest='without_mask', action='store_true', default=False, help='behave as if no package.mask entries exist (not allowed with commit mode)') + parser.add_argument('--output-style', dest='output_style', choices=output_keys, + help='select output type', default='default') + parser.add_argument('--mode', dest='mode', choices=mode_keys, help='specify which mode repoman will run in (default=full)') @@ -2422,7 +2432,10 @@ console_writer.style_listener = style_file.new_styles f = formatter.AbstractFormatter(console_writer) -utilities.format_qa_output(f, stats, fails, dofull, dofail, options, qawarnings) +if options.output_style == 'column': + utilities.format_qa_output_column(f, stats, fails, dofull, dofail, options, qawarnings) +else: + utilities.format_qa_output(f, stats, fails, dofull, dofail, options, qawarnings) style_file.flush() del console_writer, f, style_file diff --git a/pym/repoman/utilities.py b/pym/repoman/utilities.py index 3ec3a4a..aec61fe 100644 --- a/pym/repoman/utilities.py +++ b/pym/repoman/utilities.py @@ -330,6 +330,50 @@ def format_qa_output(formatter, stats, fails, dofull, dofail, options, qawarning formatter.add_line_break() +def format_qa_output_column(formatter, stats, fails, dofull, dofail, options, qawarnings): + Helper function that formats output in a machine-parseable column format + + @param formatter: an instance of Formatter + @type formatter: Formatter + @param path: dict of qa status items + @type path: dict + @param fails: dict of qa status failures + @type fails: dict + @param dofull: Whether to print full results or a summary + @type dofull: boolean + @param dofail: Whether failure was hard or soft + @type dofail: boolean + @param options: The command-line options provided to repoman + @type options: Namespace + @param qawarnings: the set of warning types + @type qawarnings: set + @return: None (modifies formatter) + + full = options.mode == 'full' + for category, number in stats.items(): + # we only want key value pairs where value 0 + if number 1: + continue + + formatter.add_literal_data(NumberOf + category + ) + if category in qawarnings: + formatter.push_style(WARN) + else: + formatter.push_style(BAD) + formatter.add_literal_data(%s % number) + formatter.pop_style() + formatter.add_line_break() + if not dofull: + if not full and dofail and category in qawarnings: + # warnings are considered noise when there are failures + continue + fails_list = fails[category] + if not full and len(fails_list) 12: + fails_list = fails_list[:12] + for failure in fails_list: + formatter.add_literal_data(category + + failure) + formatter.add_line_break() + def editor_is_executable(editor): Given an EDITOR string, validate that it refers to -- 1.8.5.3
[gentoo-dev] February 2014 KDE team meeting
Hello all, The next KDE team meeting will take place on Feb 20 at 1900 UTC in #gentoo-meetings. Our agenda (yet to be filled in) can be found at https://wiki.gentoo.org/wiki/Project:KDE/Meeting/2014-02. All are welcome to attend. Chris Reffett signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
trying to do so. We will have a meeting, argue it there, and vote. Right now, all this arguing just makes everyone more confused about what our opinion is. - -I realize that our policy was unclear and may conflict with existing policy on ebuild removal. I apologize for that, and will keep this episode in mind in the future. Chris Reffett Gentoo QA Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLzAFBfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T76QCeOCFk8ClakUmKMqD0ldJEFQE2 kxkAn1Zw/6sSOghbc43KC4QEVzolYIvn =+Pmi -END PGP SIGNATURE-
Re: [gentoo-dev] January 2014 QA Policy Updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2014 09:07 AM, Peter Stuge wrote: Alec Warner wrote: hmm? To be fair, I had a long discussion with this regarding when QA has the authority to temporarily ban a developer. Cool. In the case where policy is missing, QA does not have a clear case of authority there. It becomes a more murky area. I've tried to very much encourage QA to both publish the policies they want to enforce, and automate enforcement with better tooling (repoman or otherwise). Being transparent and consistent in enforcement of policy goes a long way for getting developers on your side. Absolutely. So in short, while one could read that passage as you did, I don't think that is their intention. To be clear, I don't think so either. Rich Freeman wrote: I was really happy to see a public notice of meeting and a published summary. Yes, me too! I still think it seems like QA could essentially introduce arbitrary new policies and 2 weeks later be expected to effect them. Fine when everyone agrees. Not so much at other times. The responsibility is with QA to build support among the developers, and I agree that the transparency goes a long way! //Peter Regarding the question in your first email: We will not create a policy then immeiately use the policy as justification to to go edit packages. The intention of the we may ask the developer to stop line is for cases where we suspect that what the developer is doing is causing a problem and would like to discuss it further. I feel that that is well within the bounds of GLEP 48. As for the when/how we make and communicate fixes, I think that just about any policy we make will fall into the middle ground you omitted of file a bug, wait 2 weeks, fix. So no, we will not be making arbitrary fixes just because we can. Regarding your concern about us introducing arbitrary policies: again, most will fall into the file a bug middle ground. We also are perfectly aware that you can't expect people to change overnight, and we will not be shouting at devs just because they didn't implement $(new-policy) right away. We will file bugs asking for changes, and we will try to offer suggestions or patches wherever possible to make it easier for maintainers. Chris Reffett Gentoo QA Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLrv0hfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QZ+wCeJre5n44E9BdZcUBgZdC5DjPe WR8AoJ1W9QuqVIFXxsVAWBO23yx+etak =5CIT -END PGP SIGNATURE-
Re: [gentoo-dev] January 2014 QA Policy Updates
On 01/30/2014 03:10 PM, William Hubbs wrote: On Thu, Jan 30, 2014 at 12:47:01AM -0500, Chris Reffett wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, The new QA team has completed its first meeting, and so I would like to announce policy changes agreed upon during the meeting which are relevant to the developer community. In the future, when a meeting results in changed or amended policy, we will notify the community via - -dev and -dev-announce, so there will probably be a summary email like this coming out about once a month. Changes to policy from this meeting: - -USE-controlled optional RDEPENDs policy clarified to say that those dependencies are not allowed, but QA will grant exceptions for certain circumstances (such as a package not working unless one of a set of optional deps is installed) - -The QA team policymaking workflow will look like the following: * User/dev/team member brings us an issue * Team investigates * Team discusses at the next meeting ** If the person is violating policy, we inform them of that and request that they stop violating policy ** If the existing policy is unclear, we update it ** If there is no existing policy, make one If we think a developer's actions are causing problems, we may ask them to stop/undo pending discussion by the QA team at the next meeting. - -Rules for the QA team editing peoples' packages: *For trivial fixes, such as repoman errors, we fix the issue and send the developer a friendly reminder *For large but non-critical fixes, we open a bug, wait 2 weeks, and if it is not fixed within that time frame we make the change. *For critical fixes, such as a problem that breaks the tree or a package, we fix the issue and send the developer a notice about our change - -The QA team will communicate changes to policy via emails to gentoo-dev and gentoo-dev-announce and by updating the QA policy page on the Gentoo Wiki. For anyone interested, the summary of the meeting can be found at https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries and the current set of QA policies can be found at https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies. If you have any questions or concerns about these policies, feel free to discuss them with us in #gentoo-qa or by emailing q...@gentoo.org. I have one. The way I read that email, we are saying that our only policies are on the wiki. Is that right, or is the DevManual stil relevant? If it is, I would suggest that on the wiki we make it clear that our technical policies are all in the devmanual. Along that line, I would suggest moving the stabilization policy to the devmanual. I'll look for a place for a patch. William That's my mistake, the devmanual is still relevant. My idea is to use the wiki page for smaller or more specific items which probably don't go in the devmanual (for example, policy which is about specific packages or USE flags, or policies which just affect the QA team). Stabilization should go to the devmanual, then. Chris Reffett signature.asc Description: OpenPGP digital signature
[gentoo-dev] January 2014 QA Policy Updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, The new QA team has completed its first meeting, and so I would like to announce policy changes agreed upon during the meeting which are relevant to the developer community. In the future, when a meeting results in changed or amended policy, we will notify the community via - -dev and -dev-announce, so there will probably be a summary email like this coming out about once a month. Changes to policy from this meeting: - -USE-controlled optional RDEPENDs policy clarified to say that those dependencies are not allowed, but QA will grant exceptions for certain circumstances (such as a package not working unless one of a set of optional deps is installed) - -The QA team policymaking workflow will look like the following: * User/dev/team member brings us an issue * Team investigates * Team discusses at the next meeting ** If the person is violating policy, we inform them of that and request that they stop violating policy ** If the existing policy is unclear, we update it ** If there is no existing policy, make one If we think a developer's actions are causing problems, we may ask them to stop/undo pending discussion by the QA team at the next meeting. - -Rules for the QA team editing peoples' packages: *For trivial fixes, such as repoman errors, we fix the issue and send the developer a friendly reminder *For large but non-critical fixes, we open a bug, wait 2 weeks, and if it is not fixed within that time frame we make the change. *For critical fixes, such as a problem that breaks the tree or a package, we fix the issue and send the developer a notice about our change - -The QA team will communicate changes to policy via emails to gentoo-dev and gentoo-dev-announce and by updating the QA policy page on the Gentoo Wiki. For anyone interested, the summary of the meeting can be found at https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries and the current set of QA policies can be found at https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies. If you have any questions or concerns about these policies, feel free to discuss them with us in #gentoo-qa or by emailing q...@gentoo.org. Chris Reffett Gentoo QA Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLp51VfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1R6zwCfXY0q7Ig3d40Xq2hScLcT4Hm6 zE8AoJfIWsuV9yAKdsuxwB6JSDr8KbZY =sheY -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2014 05:12 AM, Markos Chandras wrote: On 01/23/2014 04:48 PM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 11:28 AM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett creff...@gentoo.org napisał(a): After some discussion on good ways to communicate optional dependencies to users, I was shown the optfeature() function in net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with a cleaned up and expanded version of it, and I would like to add it to eutils.eclass to provide a standard way of notifying users of optional dependencies. The patch to eutils.eclass is attached. This was discussed already: http://thread.gmane.org/gmane.linux.gentoo.devel/72162 First of all, this is a short patch for a function, not a full eclass. Ah, sorry, this changes *a lot*. Let's start the bikeshed again then, whatever. I haven't looked at the implementation, but I wonder if we need a function for such trivial stuff. Most maintainers deal with this problem using pkg_postinst() einfo/elog messages. Why do we need a dedicated function for that? Just for consistency reasons...? Consistency, and because it removes the need for a bunch of if has_version lines, instead only displaying if you don't satisfy the deps (and supports both and and or groupings for packages satisfying the dep). This also stems from a complaint I've seen a lot about how optional dep messages should only display if the requisite package isn't installed, this makes that job a little simpler. But mostly consistency, this gives us one nice function that we can standardize on. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLjt6NfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1SAZACgqLjfMMmvPNa/6Nwxzlpm5sde kwQAniZMjvFkQ7H/1+wpYnDjyezplMud =6E+E -END PGP SIGNATURE-
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 01/25/2014 12:22 PM, Andrew Hamilton wrote: On 1/25/2014 9:24 AM, Markos Chandras wrote: On 11/10/2013 06:12 AM, Johann Schmitz wrote: - gpg control packet I already have too many packages to take care of but my company is using nagion on Gentoo so I take care of it. Although I wouldn't mind if somebody else helps with the packages as well. We use Nagios on many servers at work, so i can help out with these packages too. ... git overlay for easier nondev contributions? :) A git repo would be useful if there are many changes to the code (e.g. plugins). From what i see in the buglist, most of the bugs are ebuild related (bumps, compile and installation issues). (picking a random email from the thread) ping again. 3 months later, the list of bugs remain the same. Shall we consider dropping it to maintainer-needed? I would be happy to proxy-maintain these packages. Andrew Hamilton I will proxy for him, will update metadata shortly. Chris Reffett
[gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, After some discussion on good ways to communicate optional dependencies to users, I was shown the optfeature() function in net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with a cleaned up and expanded version of it, and I would like to add it to eutils.eclass to provide a standard way of notifying users of optional dependencies. The patch to eutils.eclass is attached. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLhQklfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TDkwCeJ7MQliIiI6ViSkZzD+eIYM/J 0F4AoIVMP32HenJcjOkTIJkd6vGniiSi =+oIe -END PGP SIGNATURE- --- eutils.eclass 2014-01-22 23:36:35.81900 -0500 +++ eutils.eclass.patched 2014-01-23 00:37:07.90700 -0500 @@ -1729,4 +1729,49 @@ check_license() { die you no longer need this as portage supports ACCEPT_LICENSE itself; } +# @FUNCTION: optfeature +# @USAGE: short description package atom to match [other atoms] +# @DESCRIPTION: +# Print out a message suggesting an optional package (or packages) which +# provide the described functionality +# +# The following snippet would suggest app-misc/foo for optional foo support, +# app-misc/bar or app-misc/baz[bar] for optional bar support +# and either both app-misc/a and app-misc/b or app-misc/c for alphabet support. +# @CODE: +# optfeature foo support app-misc/foo +# optfeature bar support app-misc/bar app-misc/baz[bar] +# optfeature alphabet support app-misc/a app-misc/b app-misc/c +# +optfeature() { + debug-print-function ${FUNCNAME} $@ + local i j msg + local desc=$1 + local flag=0 + shift + for i; do + for j in $i; do + if has_version $j; then +flag=1 + else +flag=0 +break + fi + done + if [[ $flag -eq 1 ]]; then + break + fi + done + if [[ $flag -eq 0 ]]; then + for i; do + msg= + for j in $i; do +msg=${msg} ${j} and + done + msg=${msg:0: -4} for ${desc} + elog ${msg} + done + fi +} + fi
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 11:28 AM, Michał Górny wrote: Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett creff...@gentoo.org napisał(a): After some discussion on good ways to communicate optional dependencies to users, I was shown the optfeature() function in net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with a cleaned up and expanded version of it, and I would like to add it to eutils.eclass to provide a standard way of notifying users of optional dependencies. The patch to eutils.eclass is attached. This was discussed already: http://thread.gmane.org/gmane.linux.gentoo.devel/72162 First of all, this is a short patch for a function, not a full eclass. Further, people are doing this sort of thing already (printing messages to say if you want support for x, install y, this is just making it easier to do so. Of course full support for an SDEPEND variable would be much better, but unless you have a patch for that ready to go for the next EAPI I don't see that happening anytime soon, so a short function in eutils seems like a reasonable choice to me. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLhRPZfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QaawCeM3GnYAc83Czei2r1l2XHFFB4 sAgAn21yARrui9E+ZsNnk75UCk0j0oEp =VTT0 -END PGP SIGNATURE-
[gentoo-portage-dev] [PATCH v6] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.
v2: Reformat, add a function to return an appropriate read-only checker for the operating system, so that this can be extended to other OSes. v3: minor formatting tweaks from bernalex, including use os.path.join() instead of string concatenation v4: Update copyright header, change the code in rochecker to open with io.open in order to not break on non-ascii characters as reported by Arfrever. Change get_ro_checker to use a dict as suggested by vapier. v5: Fix comment format as requested by vapier. v6: Change linux_ro_checker to use set.intersection instead of the longer check-and-append system as suggested by vapier. --- pym/portage/dbapi/vartree.py | 34 +- pym/portage/util/rochecker.py | 80 +++ 2 files changed, 113 insertions(+), 1 deletion(-) create mode 100644 pym/portage/util/rochecker.py diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py index ed62323..cf6781b 100644 --- a/pym/portage/dbapi/vartree.py +++ b/pym/portage/dbapi/vartree.py @@ -1,4 +1,4 @@ -# Copyright 1998-2013 Gentoo Foundation +# Copyright 1998-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 from __future__ import unicode_literals @@ -32,6 +32,7 @@ portage.proxy.lazyimport.lazyimport(globals(), 'portage.util.env_update:env_update', 'portage.util.listdir:dircache,listdir', 'portage.util.movefile:movefile', + 'portage.util.rochecker:get_ro_checker', 'portage.util._dyn_libs.PreservedLibsRegistry:PreservedLibsRegistry', 'portage.util._dyn_libs.LinkageMapELF:LinkageMapELF@LinkageMap', 'portage.util._async.SchedulerInterface:SchedulerInterface', @@ -3508,6 +3509,8 @@ class dblink(object): This function does the following: + calls get_ro_checker to retrieve a function for checking whether Portage + will write to a read-only filesystem, then runs it against the directory list calls self._preserve_libs if FEATURES=preserve-libs calls self._collision_protect if FEATURES=collision-protect calls doebuild(mydo=pkg_preinst) @@ -3685,6 +3688,7 @@ class dblink(object): eagain_error = False myfilelist = [] + mydirlist = [] mylinklist = [] paths_with_newlines = [] def onerror(e): @@ -3717,6 +3721,9 @@ class dblink(object): unicode_errors.append(new_parent[ed_len:]) break + relative_path = parent[srcroot_len:] + mydirlist.append(os.path.join(/, relative_path)) + for fname in files: try: fname = _unicode_decode(fname, @@ -3829,6 +3836,31 @@ class dblink(object): for other in others_in_slot]) prepare_build_dirs(settings=self.settings, cleanup=cleanup) + # Check for read-only filesystems. + ro_checker = get_ro_checker() + rofilesystems = ro_checker(mydirlist) + + if rofilesystems: + msg = _(One or more files installed to this package are + set to be installed to read-only filesystems. + Please mount the following filesystems as read-write + and retry.) + msg = textwrap.wrap(msg, 70) + msg.append() + for f in rofilesystems: + msg.append(\t%s % os.path.join(destroot, + f.lstrip(os.path.sep))) + msg.append() + self._elog(eerror, preinst, msg) + + msg = _(Package '%s' NOT merged due to read-only file systems.) % \ + self.settings.mycpv + msg += _( If necessary, refer to your elog + messages for the whole content of the above message.) + msg = textwrap.wrap(msg, 70) + eerror(msg) + return 1 + # check for package collisions blockers = self._blockers if blockers is None: diff --git a/pym/portage/util/rochecker.py b/pym/portage/util/rochecker.py new file mode 100644 index 000..c13bdfc --- /dev/null +++ b/pym/portage/util/rochecker.py @@ -0,0 +1,80 @@ +#-*- coding:utf-8 -*- +# Copyright 2014 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +Methods to check whether Portage is going to write to read-only
[gentoo-portage-dev] [PATCH v4] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.
v2: Reformat, add a function to return an appropriate read-only checker for the operating system, so that this can be extended to other OSes. v3: minor formatting tweaks from bernalex, including use os.path.join() instead of string concatenation v4: Update copyright header, change the code in rochecker to open with io.open in order to not break on non-ascii characters as reported by Arfrever. Change get_ro_checker to use a dict as suggested by vapier. --- pym/portage/dbapi/vartree.py | 34 - pym/portage/util/rochecker.py | 87 +++ 2 files changed, 120 insertions(+), 1 deletion(-) create mode 100644 pym/portage/util/rochecker.py diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py index ed62323..22cf222 100644 --- a/pym/portage/dbapi/vartree.py +++ b/pym/portage/dbapi/vartree.py @@ -1,4 +1,4 @@ -# Copyright 1998-2013 Gentoo Foundation +# Copyright 1998-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 from __future__ import unicode_literals @@ -32,6 +32,7 @@ portage.proxy.lazyimport.lazyimport(globals(), 'portage.util.env_update:env_update', 'portage.util.listdir:dircache,listdir', 'portage.util.movefile:movefile', + 'portage.util.rochecker:get_ro_checker', 'portage.util._dyn_libs.PreservedLibsRegistry:PreservedLibsRegistry', 'portage.util._dyn_libs.LinkageMapELF:LinkageMapELF@LinkageMap', 'portage.util._async.SchedulerInterface:SchedulerInterface', @@ -3508,6 +3509,8 @@ class dblink(object): This function does the following: + calls get_ro_checker to retrieve a function for checking whether Portage + will write to a read-only filesystem, then runs it against the directory list calls self._preserve_libs if FEATURES=preserve-libs calls self._collision_protect if FEATURES=collision-protect calls doebuild(mydo=pkg_preinst) @@ -3685,6 +3688,7 @@ class dblink(object): eagain_error = False myfilelist = [] + mydirlist = [] mylinklist = [] paths_with_newlines = [] def onerror(e): @@ -3717,6 +3721,9 @@ class dblink(object): unicode_errors.append(new_parent[ed_len:]) break + relative_path = parent[srcroot_len:] + mydirlist.append(os.path.join(/, relative_path)) + for fname in files: try: fname = _unicode_decode(fname, @@ -3829,6 +3836,31 @@ class dblink(object): for other in others_in_slot]) prepare_build_dirs(settings=self.settings, cleanup=cleanup) + # Check for read-only filesystems + ro_checker = get_ro_checker() + rofilesystems = ro_checker(mydirlist) + + if rofilesystems: + msg = _(One or more files installed to this package are + set to be installed to read-only filesystems. + Please mount the following filesystems as read-write + and retry.) + msg = textwrap.wrap(msg, 70) + msg.append() + for f in rofilesystems: + msg.append(\t%s % os.path.join(destroot, + f.lstrip(os.path.sep))) + msg.append() + self._elog(eerror, preinst, msg) + + msg = _(Package '%s' NOT merged due to read-only file systems.) % \ + self.settings.mycpv + msg += _( If necessary, refer to your elog + messages for the whole content of the above message.) + msg = textwrap.wrap(msg, 70) + eerror(msg) + return 1 + # check for package collisions blockers = self._blockers if blockers is None: diff --git a/pym/portage/util/rochecker.py b/pym/portage/util/rochecker.py new file mode 100644 index 000..2bbfe9d --- /dev/null +++ b/pym/portage/util/rochecker.py @@ -0,0 +1,87 @@ +#-*- coding:utf-8 -*- +# Copyright 2014 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +Methods to check whether Portage is going to write to read-only filesystems. +Since the methods are not portable across different OSes, each OS needs its +own method. To expand RO checking for different OSes, add a method which +accepts a list
[gentoo-portage-dev] [PATCH v5] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.
v2: Reformat, add a function to return an appropriate read-only checker for the operating system, so that this can be extended to other OSes. v3: minor formatting tweaks from bernalex, including use os.path.join() instead of string concatenation v4: Update copyright header, change the code in rochecker to open with io.open in order to not break on non-ascii characters as reported by Arfrever. Change get_ro_checker to use a dict as suggested by vapier. v5: Fix comment format as requested by vapier. --- pym/portage/dbapi/vartree.py | 34 - pym/portage/util/rochecker.py | 88 +++ 2 files changed, 121 insertions(+), 1 deletion(-) create mode 100644 pym/portage/util/rochecker.py diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py index ed62323..cf6781b 100644 --- a/pym/portage/dbapi/vartree.py +++ b/pym/portage/dbapi/vartree.py @@ -1,4 +1,4 @@ -# Copyright 1998-2013 Gentoo Foundation +# Copyright 1998-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 from __future__ import unicode_literals @@ -32,6 +32,7 @@ portage.proxy.lazyimport.lazyimport(globals(), 'portage.util.env_update:env_update', 'portage.util.listdir:dircache,listdir', 'portage.util.movefile:movefile', + 'portage.util.rochecker:get_ro_checker', 'portage.util._dyn_libs.PreservedLibsRegistry:PreservedLibsRegistry', 'portage.util._dyn_libs.LinkageMapELF:LinkageMapELF@LinkageMap', 'portage.util._async.SchedulerInterface:SchedulerInterface', @@ -3508,6 +3509,8 @@ class dblink(object): This function does the following: + calls get_ro_checker to retrieve a function for checking whether Portage + will write to a read-only filesystem, then runs it against the directory list calls self._preserve_libs if FEATURES=preserve-libs calls self._collision_protect if FEATURES=collision-protect calls doebuild(mydo=pkg_preinst) @@ -3685,6 +3688,7 @@ class dblink(object): eagain_error = False myfilelist = [] + mydirlist = [] mylinklist = [] paths_with_newlines = [] def onerror(e): @@ -3717,6 +3721,9 @@ class dblink(object): unicode_errors.append(new_parent[ed_len:]) break + relative_path = parent[srcroot_len:] + mydirlist.append(os.path.join(/, relative_path)) + for fname in files: try: fname = _unicode_decode(fname, @@ -3829,6 +3836,31 @@ class dblink(object): for other in others_in_slot]) prepare_build_dirs(settings=self.settings, cleanup=cleanup) + # Check for read-only filesystems. + ro_checker = get_ro_checker() + rofilesystems = ro_checker(mydirlist) + + if rofilesystems: + msg = _(One or more files installed to this package are + set to be installed to read-only filesystems. + Please mount the following filesystems as read-write + and retry.) + msg = textwrap.wrap(msg, 70) + msg.append() + for f in rofilesystems: + msg.append(\t%s % os.path.join(destroot, + f.lstrip(os.path.sep))) + msg.append() + self._elog(eerror, preinst, msg) + + msg = _(Package '%s' NOT merged due to read-only file systems.) % \ + self.settings.mycpv + msg += _( If necessary, refer to your elog + messages for the whole content of the above message.) + msg = textwrap.wrap(msg, 70) + eerror(msg) + return 1 + # check for package collisions blockers = self._blockers if blockers is None: diff --git a/pym/portage/util/rochecker.py b/pym/portage/util/rochecker.py new file mode 100644 index 000..2d3c89f --- /dev/null +++ b/pym/portage/util/rochecker.py @@ -0,0 +1,88 @@ +#-*- coding:utf-8 -*- +# Copyright 2014 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +Methods to check whether Portage is going to write to read-only filesystems. +Since the methods are not portable across different OSes, each OS needs its +own method. To expand RO checking for
Re: [gentoo-dev] Regarding long delays on GLSA generation
On Jan 18, 2014 1:35 PM, Pacho Ramos pa...@gentoo.org wrote: El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió: [...] So you observed correctly there's still plenty of delays. There are three parts to an advisory that take time: - Drafting: Collecting information, linking references, getting package versions done right (slots are a huge pain still). - Reviewing: Our current process asks for two independent positive reviews from other team members before an advisory can be sent. - Sending: The original author gets a .txt to email and have to check in the .xml to CVS. Going through these three steps requires at least three people, and the (group of) people whose action is required shifts twice. That overall process is spot #1 we are planning to improve. The current plan contains requiring only one review and the reviewer sends the advisory directly. So we go from author - reviewer 1 - reviewer 2 - author to just author - reviewer. This looks a nice improvement indeed :) Concerning the single steps here are other measures: - Drafting: Implement a new GLSA format to * reduce the amount of editorial text written by us * support slots (makes specifying vulnerable ranges in slotted package much easier) * (cleanup old stuff no longer needed) That looks interesting as doing all the draft manually is really a huge work (with leads to not so enhancement). I am unsure how will the cleanup be done, as soon as the portage tree doesn't break (due some other package requiring the old buggy version), why are not all devs allowed to drop (or, at least, hardmask if needed for some base-system package :/) the vulnerable versions? Looks like currently security team waits for maintainers to do that, I try to do it fast but maybe will take much more time in other situations. I think this could be improved if other people like security team members or the last one stabilizing the fixed version could do the cleanup too. We prefer that the maintainers do the drop in case there's some dependency situation we're not aware of, but we will drop if maintainers are unresponsive. Also, currently looks like, when we (maintainers) get asked to bump the package fixing it, we tend to wait for security team members to CC arches, maybe the maintainers could do that directly to gain a bit of time. By all means, maintainer should be the one to call for the stable. It's your package, I cannot think of any situation where security would not want the maintainer to do that. - Reviewing: Reduced editorial text means less to review. - Sending: We want to improve our tooling to automatically send advisories and push them to a git repository. The new GLSA format was up for review on -security last week. Next up will be getting it specified formally, implemented in our tooling, glsa-check and a new security.g.o frontend. [1] Then, we can adopt the new workflow. Then, instead of blaming on how should I have asked for clarification on this (well, looks like the main topic here is that I have asked about this in ML instead of the real problem :O), I think you should focus on explaining how are you fixing this problem. Your original email didn't reflect actual interest in the details. Now that we've established you do care, I hope my explanations helped you out there. They helped for sure :) and I appreciate them, I simply thought nothing was being worked out as I explained in previous mail (I was still saying long delays) I have been long time wondering about this because: 1. I usually get lots of bugs from alias I am a member whose we go fast bumping, calling for stabilization and dropping vulnerable versions and, the, the bugs get stalled. 2. Once of the machines I maintain would benefit from being able to use glsacheck to only update vulnerable packages as not always have enough time for updating the full world [1] Lots of code to be written here. .py+.rb, help wanted!
[gentoo-portage-dev] [PATCH v3] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.
v2: Reformat, add a function to return an appropriate read-only checker for the operating system, so that this can be extended to other OSes. v3: minor formatting tweaks from bernalex, including use os.path.join() instead of string concatenation --- pym/portage/dbapi/vartree.py | 32 + pym/portage/util/rochecker.py | 81 +++ 2 files changed, 113 insertions(+) create mode 100644 pym/portage/util/rochecker.py diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py index ed62323..917634f 100644 --- a/pym/portage/dbapi/vartree.py +++ b/pym/portage/dbapi/vartree.py @@ -32,6 +32,7 @@ portage.proxy.lazyimport.lazyimport(globals(), 'portage.util.env_update:env_update', 'portage.util.listdir:dircache,listdir', 'portage.util.movefile:movefile', + 'portage.util.rochecker:get_ro_checker', 'portage.util._dyn_libs.PreservedLibsRegistry:PreservedLibsRegistry', 'portage.util._dyn_libs.LinkageMapELF:LinkageMapELF@LinkageMap', 'portage.util._async.SchedulerInterface:SchedulerInterface', @@ -3508,6 +3509,8 @@ class dblink(object): This function does the following: + calls get_ro_checker to retrieve a function for checking whether Portage + will write to a read-only filesystem, then runs it against the directory list calls self._preserve_libs if FEATURES=preserve-libs calls self._collision_protect if FEATURES=collision-protect calls doebuild(mydo=pkg_preinst) @@ -3685,6 +3688,7 @@ class dblink(object): eagain_error = False myfilelist = [] + mydirlist = [] mylinklist = [] paths_with_newlines = [] def onerror(e): @@ -3717,6 +3721,9 @@ class dblink(object): unicode_errors.append(new_parent[ed_len:]) break + relative_path = parent[srcroot_len:] + mydirlist.append(os.path.join(/, relative_path)) + for fname in files: try: fname = _unicode_decode(fname, @@ -3829,6 +3836,31 @@ class dblink(object): for other in others_in_slot]) prepare_build_dirs(settings=self.settings, cleanup=cleanup) + # Check for read-only filesystems + ro_checker = get_ro_checker() + rofilesystems = ro_checker(mydirlist) + + if rofilesystems: + msg = _(One or more files installed to this package are + set to be installed to read-only filesystems. + Please mount the following filesystems as read-write + and retry.) + msg = textwrap.wrap(msg, 70) + msg.append() + for f in rofilesystems: + msg.append(\t%s % os.path.join(destroot, + f.lstrip(os.path.sep))) + msg.append() + self._elog(eerror, preinst, msg) + + msg = _(Package '%s' NOT merged due to read-only file systems.) % \ + self.settings.mycpv + msg += _( If necessary, refer to your elog + messages for the whole content of the above message.) + msg = textwrap.wrap(msg, 70) + eerror(msg) + return 1 + # check for package collisions blockers = self._blockers if blockers is None: diff --git a/pym/portage/util/rochecker.py b/pym/portage/util/rochecker.py new file mode 100644 index 000..67e8131 --- /dev/null +++ b/pym/portage/util/rochecker.py @@ -0,0 +1,81 @@ +#-*- coding:utf-8 -*- +# Copyright 2014 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +Methods to check whether Portage is going to write to read-only filesystems. +Since the methods are not portable across different OSes, each OS needs its +own method. To expand RO checking for different OSes, add a method which +accepts a list of directories and returns a list of mounts which need to be +remounted RW, then add elif ostype == (the ostype value for your OS) to +get_ro_checker() + +from __future__ import unicode_literals + +import logging +import re + +from portage.util import writemsg_level +from portage.localization import _ +from portage.data import ostype + + +def get_ro_checker(): + + Uses the system type to find an appropriate method for
[gentoo-portage-dev] [PATCH v2] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 and if pkg_pretend is used in EAPI 4. Fixes bug 379491.
--- pym/repoman/checks.py | 29 + 1 file changed, 29 insertions(+) diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py index 85aa065..5c55b0d 100644 --- a/pym/repoman/checks.py +++ b/pym/repoman/checks.py @@ -731,6 +731,21 @@ class DeprecatedHasq(LineCheck): re = re.compile(r'(^|.*\b)hasq\b') error = errors.HASQ_ERROR +# EAPI 2 checks +class Eapi01UndefinedPhases(LineCheck): + repoman_check_name = 'EAPI.incompatible' + src_configprepare_re = re.compile(r'\s*src_(configure|prepare)\s*\(\)') + + def check_eapi(self, eapi): + return eapi in ('0', '1') + + def check(self, num, line): + m = self.src_configprepare__re.match(line) + if m is not None: + return (%s % m.group(1)) + \ +phase is not defined in EAPI=0/1 on line: %d + + # EAPI-3 checks class Eapi3DeprecatedFuncs(LineCheck): repoman_check_name = 'EAPI.deprecated' @@ -745,6 +760,20 @@ class Eapi3DeprecatedFuncs(LineCheck): return ('%s' % m.group(1)) + \ has been deprecated in EAPI=3 on line: %d +# EAPI 4 checks +class Eapi0123UndefinedPhases(LineCheck): + repoman_check_name = 'EAPI.incompatible' + pkg_pretend_re = re.compile(r'\s*pkg_pretend\s*\(\)') + + def check_eapi(self, eapi): + return eapi in ('0', '1', '2', '3') + + def check(self, num, line): + m = self.pkg_pretend_re.match(line) + if m is not None: + return (%s % m.group(1)) + \ +phase is not defined in EAPI 4 on line: %d + # EAPI-4 checks class Eapi4IncompatibleFuncs(LineCheck): repoman_check_name = 'EAPI.incompatible' -- 1.8.5.1
[gentoo-portage-dev] [PATCH v3] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 and if pkg_pretend is used in EAPI 4. Fixes bug 379491.
--- pym/repoman/checks.py | 29 + 1 file changed, 29 insertions(+) Ignore v2, I apparently didn't commit all of my changes and so that patch won't work. Undid the compression of the src_prepare/src_configure regex, because the way that the regex is set up means that it would output prepare phase is not defined in EAPI... instead of src_prepare and I feel that it's more intuitive to match the full name of the function instead of tacking src_ in front of the output. diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py index 85aa065..c6860d8 100644 --- a/pym/repoman/checks.py +++ b/pym/repoman/checks.py @@ -731,6 +731,21 @@ class DeprecatedHasq(LineCheck): re = re.compile(r'(^|.*\b)hasq\b') error = errors.HASQ_ERROR +# EAPI 2 checks +class Eapi01UndefinedPhases(LineCheck): + repoman_check_name = 'EAPI.incompatible' + src_configprepare_re = re.compile(r'\s*(src_configure|src_prepare)\s*\(\)') + + def check_eapi(self, eapi): + return eapi in ('0', '1') + + def check(self, num, line): + m = self.src_configprepare_re.match(line) + if m is not None: + return ('%s' % m.group(1)) + \ +phase is not defined in EAPI 2 on line: %d + + # EAPI-3 checks class Eapi3DeprecatedFuncs(LineCheck): repoman_check_name = 'EAPI.deprecated' @@ -745,6 +760,20 @@ class Eapi3DeprecatedFuncs(LineCheck): return ('%s' % m.group(1)) + \ has been deprecated in EAPI=3 on line: %d +# EAPI 4 checks +class Eapi0123UndefinedPhases(LineCheck): + repoman_check_name = 'EAPI.incompatible' + pkg_pretend_re = re.compile(r'\s*(pkg_pretend)\s*\(\)') + + def check_eapi(self, eapi): + return eapi in ('0', '1', '2', '3') + + def check(self, num, line): + m = self.pkg_pretend_re.match(line) + if m is not None: + return ('%s' % m.group(1)) + \ +phase is not defined in EAPI 4 on line: %d + # EAPI-4 checks class Eapi4IncompatibleFuncs(LineCheck): repoman_check_name = 'EAPI.incompatible' -- 1.8.5.1
[gentoo-portage-dev] [PATCH v4] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 and if pkg_pretend is used in EAPI 4. Fixes bug 379491.
--- pym/repoman/checks.py | 31 ++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py index 85aa065..c814fa7 100644 --- a/pym/repoman/checks.py +++ b/pym/repoman/checks.py @@ -15,7 +15,7 @@ import repoman.errors as errors import portage from portage.eapi import eapi_supports_prefix, eapi_has_implicit_rdepend, \ eapi_has_src_prepare_and_src_configure, eapi_has_dosed_dohard, \ - eapi_exports_AA + eapi_exports_AA, eapi_has_pkg_pretend class LineCheck(object): Run a check on a line of an ebuild. @@ -731,6 +731,21 @@ class DeprecatedHasq(LineCheck): re = re.compile(r'(^|.*\b)hasq\b') error = errors.HASQ_ERROR +# EAPI 2 checks +class UndefinedSrcPrepareSrcConfigurePhases(LineCheck): + repoman_check_name = 'EAPI.incompatible' + src_configprepare_re = re.compile(r'\s*(src_configure|src_prepare)\s*\(\)') + + def check_eapi(self, eapi): + return not eapi_has_src_prepare_and_src_configure(eapi) + + def check(self, num, line): + m = self.src_configprepare_re.match(line) + if m is not None: + return ('%s' % m.group(1)) + \ +phase is not defined in EAPI 2 on line: %d + + # EAPI-3 checks class Eapi3DeprecatedFuncs(LineCheck): repoman_check_name = 'EAPI.deprecated' @@ -745,6 +760,20 @@ class Eapi3DeprecatedFuncs(LineCheck): return ('%s' % m.group(1)) + \ has been deprecated in EAPI=3 on line: %d +# EAPI 4 checks +class UndefinedPkgPretendPhase(LineCheck): + repoman_check_name = 'EAPI.incompatible' + pkg_pretend_re = re.compile(r'\s*(pkg_pretend)\s*\(\)') + + def check_eapi(self, eapi): + return not eapi_has_pkg_pretend(eapi) + + def check(self, num, line): + m = self.pkg_pretend_re.match(line) + if m is not None: + return ('%s' % m.group(1)) + \ +phase is not defined in EAPI 4 on line: %d + # EAPI-4 checks class Eapi4IncompatibleFuncs(LineCheck): repoman_check_name = 'EAPI.incompatible' -- 1.8.5.1
Re: [gentoo-portage-dev] [PATCH] Check for and report read-only filesystems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/11/2014 12:09 AM, Brian Dolbec wrote: On Fri, 2014-01-10 at 22:07 -0500, Chris Reffett wrote: Hi all, Attached is a patch to test if Portage is going to write to a read-only filesystem and print out the list of filesystems that need to be remounted RW. This leaves ${D} intact rather than having some files moved before hitting the RO filesystem. Fixes bug 378869. Since git.overlays.gentoo.org is down, I haven't had the chance to rebase this against latest, but I can resubmit if it doesn't cleanly apply. This is my first patch to the list, so I apologize if I didn't submit correctly. Chris Reffett yeah, patch looks good. Only thing I didn't like is the return 1 IS that suppose to be True or sys.exit() value? If that is what the module was using, then it's ok. Personally I'm not a fan of using 0, 1 for False, True. But that will come later... That was just following the style of the rest of the module, for example a collision will return 1. This can be added to the stuff to be fixed up in future patches list. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKUEARECAGYFAlLRU7VfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QLjQCfSJSpacHoI/IQPS/o+NFJvP6q d8YAmP+RmhoWwa3J1eRNk0BAxX1TtDg= =a7If -END PGP SIGNATURE-
[gentoo-portage-dev] [PATCH] Check for and report read-only filesystems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Attached is a patch to test if Portage is going to write to a read-only filesystem and print out the list of filesystems that need to be remounted RW. This leaves ${D} intact rather than having some files moved before hitting the RO filesystem. Fixes bug 378869. Since git.overlays.gentoo.org is down, I haven't had the chance to rebase this against latest, but I can resubmit if it doesn't cleanly apply. This is my first patch to the list, so I apologize if I didn't submit correctly. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLQtYhfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1SCCgCfZIo57KiijmACnDTa2vC9UMAb 9YwAoIhnc/nHDcIXBbzF9Tie3eTJyWpH =j/1A -END PGP SIGNATURE- From c464ac5e0007a087def9a96efea9653e508e57c1 Mon Sep 17 00:00:00 2001 From: Chris Reffett creff...@gentoo.org Date: Fri, 10 Jan 2014 09:03:26 -0500 Subject: [PATCH] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869. --- pym/portage/dbapi/vartree.py | 31 pym/portage/util/checkwriteable.py | 49 ++ 2 files changed, 80 insertions(+) create mode 100644 pym/portage/util/checkwriteable.py diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py index ed62323..8ae7014 100644 --- a/pym/portage/dbapi/vartree.py +++ b/pym/portage/dbapi/vartree.py @@ -28,6 +28,7 @@ portage.proxy.lazyimport.lazyimport(globals(), 'portage.util:apply_secpass_permissions,ConfigProtect,ensure_dirs,' + \ 'writemsg,writemsg_level,write_atomic,atomic_ofstream,writedict,' + \ 'grabdict,normalize_path,new_protect_filename', + 'portage.util.checkwriteable:check_dirs_writeable', 'portage.util.digraph:digraph', 'portage.util.env_update:env_update', 'portage.util.listdir:dircache,listdir', @@ -3508,6 +3509,8 @@ class dblink(object): This function does the following: + calls check_dirs_writeable to verify that no files will be + written to read-only filesystems calls self._preserve_libs if FEATURES=preserve-libs calls self._collision_protect if FEATURES=collision-protect calls doebuild(mydo=pkg_preinst) @@ -3685,6 +3688,7 @@ class dblink(object): eagain_error = False myfilelist = [] + mydirlist = [] mylinklist = [] paths_with_newlines = [] def onerror(e): @@ -3717,6 +3721,9 @@ class dblink(object): unicode_errors.append(new_parent[ed_len:]) break +relative_path = parent[srcroot_len:] +mydirlist.append(/ + relative_path) + for fname in files: try: fname = _unicode_decode(fname, @@ -3829,6 +3836,30 @@ class dblink(object): for other in others_in_slot]) prepare_build_dirs(settings=self.settings, cleanup=cleanup) + # Check for read-only filesystems + rofilesystems = check_dirs_writeable(mydirlist) + + if rofilesystems: + msg = _(One or more files installed to this package are +set to be installed to read-only filesystems. +Please mount the filesystems below read-write +and retry.) + msg = textwrap.wrap(msg, 70) + msg.append() + for f in rofilesystems: +msg.append(\t%s % os.path.join(destroot, + f.lstrip(os.path.sep))) + msg.append() + self._elog(eerror, preinst, msg) + + msg = _(Package '%s' NOT merged due to read-only file systems.) % \ +self.settings.mycpv + msg += _( If necessary, refer to your elog +messages for the whole content of the above message.) + msg = textwrap.wrap(msg, 70) + eerror(msg) + return 1 + # check for package collisions blockers = self._blockers if blockers is None: diff --git a/pym/portage/util/checkwriteable.py b/pym/portage/util/checkwriteable.py new file mode 100644 index 000..9bd9056 --- /dev/null +++ b/pym/portage/util/checkwriteable.py @@ -0,0 +1,49 @@ +#-*- coding:utf-8 -*- +# Copyright 2014 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +from __future__ import unicode_literals + +import re + +from portage.util import writemsg +from portage.localization import _ + + +def check_dirs_writeable(dir_list): + + Use /proc/mounts to check that no directories installed by the ebuild are set to + be installed to a read-only filesystem + + @param dir_list: Directories installed by the ebuild + @type dir_list: List + @return: + 1. A list of filesystems which are both set to be written to and are mounted + read-only, may be empty. + + ro_filesystems = set() + ro_filesystems_written = set() + + try: + with open(/proc/mounts) as procmounts: + roregex = re.compile(r'(\A|,)ro(\Z|,)') + for line in procmounts: +if roregex.search(line.split( )[3].strip()) is not None: + romount
Re: [gentoo-dev] Re: Portage QOS
On 01/09/2014 03:42 PM, Igor wrote: Hello Duncan, Thursday, January 9, 2014, 9:59:50 PM, you wrote: Thank you for the reply. I started to comment first... but it was more philosophy a mature and grown up, experienced man and I don't think I have right to comment it. Statistically if you have more users the probability of the system survival of any architecture, philosophy or type is higher. People learn, they're not fixed and if they at the beginning do not share the philosophy of the system but they can use it - they may like it, understand it and follow it and support later. Many people I asked are not minding to help Gentoo getting better by turning on feedback. If you remember - feedback worked well for Perl once and many used it and Perl is very traditional. It's like a chess game. You have the system in it's prime. There is already one fork from Gentoo. There will be more. It's inevitable. You have to understand that not all the developers share the same philosophy - and it OK. And they may fork Gentoo with time and pull half of the team to their side. When there is a competition between systems with equal philosophy the only thing that stands between who is going to live and who is going to die is the number of users. The fight will focus not around philosophy or system but around gaining user support. The competitor can build a better, more friendly system sharing basically the same design and he will win it over. To keep in power it's in your deepest interest to close the open gates that invite competition while the power is in your hands. This is a failure many grown up companies made they belive they're forever and gods. I could share with you privately with several examples that prove that concept wrong. Your competitors will build basically the same system targeting the same philosophy but more user oriented, friendly. User oriented - means each user opinion matters. There might be millions of users but each is treated like he is the only one. PortageQOS is small step, it's not everything or main part of the system, it's a just small contribution. But it will close the door and you'll have another peaceful 8 years to rule. Right here is the big problem: you're not looking at this from the perspective of the average Gentoo developer. We don't care about market share. We don't care whether we're on top for another few years. There are several forks of Gentoo. I doubt most devs care about them. I personally know that we're not going to compete with Debian, which has a huge contributor, or Ubuntu or Red Hat, which have whole companies behind them. You're selling this as if you're selling to a company which wants to be on the top of the market and beating out competitors, and that's not what we are. We are a source-based distro that requires some effort from users, and people want that or they don't want it. What we need is a vote YES or NO. If you against it - vote NO. It's perfectly normal, if there would be no NO there would be no need voting. Actually, in that regard it's very possible that gentoo's long planned and worked toward cvs-to-git conversion will help finally bust that barrier for gentoo as well. Time will tell I guess, but that's one more reason to try to help make it happen. Chris Reffett
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On 12/11/2013 3:41 PM, William Hubbs wrote: All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. My thought is to rename our rc to openrc, since that would be unique. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? I know that once OpenRC with this change is released, it will need to probably be p.masked until there is a new release of sysvinit that updates the inittab. I'm not sure what else will break. Does anyone have any ideas wrt other things to look for, or should I make the changes upstream and have people let us know what else breaks? William [1] https://bugs.gentoo.org/show_bug.cgi?id=493958 The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. Chris Reffett
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 11/8/2013 7:14 PM, Markos Chandras wrote: Hi, I see nobody seems to take care of nagios packages anymore. There are numerous bugs (and many of them are pending version bumps). Is the sysadmin@ herd still interested in this package? If not, could you please consider moving it to maintainer-needed@? Maybe users are interested in working with proxy-maintainers to bring this package up to date. https://bugs.gentoo.org/buglist.cgi?quicksearch=net-analyzer%2Fnagios If sysadmin@ doesn't want it, I know a user/potential dev who would be interested in maintaining it with me as a proxy. Just let me know. Chris reffett
[gentoo-dev] mobile-phone herd needs help
Hi folks, I'm currently the only dev in mobile-phone, and I don't actually use any of the packages in the herd (I added myself just to keep the packages from going into m-n, but I don't have the time to attend to the bugs lately). There aren't too many bugs assigned to the herd at this point. If nobody joins, I will be removing myself and we'll do the usual herd-removal procedure within the next couple weeks. Chris Reffett
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On Sun, Sep 22, 2013 at 5:17 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I'd like to get your feedback and opinion about removing shared v8 library package from Gentoo. The three inside the box options require hope: 1. Use share lib. Hope upstream package devs code to whichever V8 API is used by Gentoo. 2. Bundle. When security problems are fixed, hope upstream package devs update to the API used in the latest V8. 3. Use slots. Hope V8 security problems are back ported. When packages use V8 they put security conscious people in an awkward hope position. It would be nice if packages recognized this and added switches to disable V8. Then we could use option 1 or 2 and fail (disable v8 use flag) when upstream doesn't stay on top of things. An outside the box option might be to bundle... but somewhere tag insecure versions of V8. Packages that only work with insecure versions of V8 require the user to assert an insecure use flag or keyword. Chris
[gentoo-dev] Re: rfc: escape sequences in logs
William Hubbs willi...@gentoo.org writes: On Mon, Sep 02, 2013 at 09:41:28PM +0200, Michał Górny wrote: That is a bug in pybugz and not an argument, you know. I said things like pybugz. Bugzilla allowing control characters in the xml is the issue. The python xmlrpc library raises an exception for malformed xml because of it, so there isn't much pybugz, or anything that uses that library, can do about it. Right. The bug is in bugzilla itself, not pybugz. I did some research. Escape and all of the other non-whitespace ASCII control characters are illegal in XML. It is also not valid to escape them with entities, like #27;. However, Bugzilla's XML-RPC interface sends them anyway. This is only a problem for build logs included inline in bug comments. Attached logs are fine, with or without the color codes. Maybe the codes could be stripped by pybugz before processing the XML? -- Chris
[gentoo-dev] Last rites: dev-games/neotools, dev-games/neoengine
# Chris Reffett creff...@gentoo.org (03 Sep 2013) # Dead upstream, outstanding security bug #260956. # Masked for removal in 30 days. dev-games/neoengine dev-games/neotools signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Indeed I have. If you want to start such a project, I would certainly be interested in joining. Plasma Active is basically untested because I don't have a mobile device with Gentoo and installing it on a normal computer leads to display sizing issues, but I welcome any suggestions or bug reports you have for that. What I would really like to see come out of this is some pre-made Gentoo stage4s for different kinds of devices, which I think would be a big draw for users. Chris Reffett On 8/13/2013 1:09 PM, Andreas K. Huettel wrote: Benda, while I won't have the time to contribute much, I would like to tell you that this is definitely a very cool and worthwhile project! I think you should make a project page and sign yourself up as team lead immediately... :) Chris Reffett from KDE team has done already a lot of work on packaging Plasma Active, see http://plasma-active.org/ - it's in the KDE overlay but mostly untested so far. You might be interested! Best, Andreas Dear Fellows, Canonical is raising money by pushing their concept of Ubuntu for Android[1][2]. The idea is to put GNU environment (esp. Ubuntu userland) in parallel to Android to drive the external HDMI output with X11 protocal, so that desktop applications can run on the smartphone. The idea is cool, but not new. The idea is general to all android devices, while Canonical is binding the concept with its own new device. The project is developed underground by Canonical, so far nothing, not to say repository, is available except advertisements and the call for people to donate. As a natual consequence of the on-going Google Summer of Code project, Gentoo on Android[3], we can run native Gentoo on *all* the Android devices. Compiling out an Xorg and output to HDMI has no theoretical difficulty. Furthermore, sharing of graphic output with Android (instead of a separate HDMI output) can be explored with wayland x11[4]. I feel sorry to the behavior of Canonical. We, people from the Gentoo community, can show the general public what is the cooperative way to develop desktop/smartphone hybrid to benefit all. I would like to kick out a sub-project of Gentoo targeting smartphone and tablets. It would be nice to find out a solution based on Gentoo for desktop/smartphone hybrid *before* Canonical's release. Comments welcome. Cheers, Benda 1. http://www.ubuntu.com/phone/ubuntu-for-android 2. http://www.indiegogo.com/projects/ubuntu-edge 3. http://www.awa.tohoku.ac.jp/~benda/projects/android.html 4. http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29
Re: [gentoo-dev] Re: KDE/semantic-desktop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/08/2013 01:52 PM, Rich Freeman wrote: On Thu, Aug 8, 2013 at 1:44 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: Sorry for reposting: Somehow the first line got lost making the whole posting not understandable... Andreas K. Huettel dilfri...@gentoo.org wrote: answer is about 10 additional megs of ram at idle and about 2 extra seconds to boot. ..and two huge database servers which lots of disk and ram space and a huge waste of compile time (not so much for KDE but more for the databases), opening to all sort of possible attacks by bugs in these databases whose servers need to be running etc. Do those servers still run if you disable the features in the control panel? I already run MySQL so the only annoyance for me was getting it to use the existing instance rather than spawning a new one. If somebody is willing to join the KDE team to support keeping that option (even as a proxy maintainer) I think the team should work with them. I think that we should generally offer any choice as long as somebody steps up to support it properly (and I do mean properly). While I'm sure the KDE team has their faults they do announce their meetings/etc and I suspect it would be an easy team for an outsider to get involved with as a result. Rich Lies! Blatant lies! The KDE team has no faults! :) ...but seriously, if someone were willing to work with us and put in the effort, I'm sure we could work something out. I'll skip the usual part about explaining our motivations behind the original removal since that's been discussed ad nauseam in bugs and on the -desktop list. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlID4FpfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TlrQCfXM1Pmi1lwwBCsSEfwyC3E5MJ zQUAn2OZ8pvujwUnu+bLtCZ0e4lacuui =tus9 -END PGP SIGNATURE-
[gentoo-dev] Re: s/disk space/drive space
Jeroen Roovers j...@gentoo.org writes: Also, drive space would be dead wrong. A drive[1] is a device which holds a storage medium (often a disk, as in, you know, a disk drive). Solid-state drive is even more confusing than solid-state disk (and both are common parlance). In the interest of linguistic accuracy, maybe solid state drives should be referred to as solid state data depositories. That would overload one of my favorite acronyms. -- Chris
Re: [gentoo-dev] cmake-utils.eclass and bug 475502
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2013 04:57 PM, hasufell wrote: I know there was an announcement about the upcoming change to cmake-utils.eclass, however... it is not enough to give a deadline without caring if people actually fixed it by then. By doing that you risk breaking stable packages which is not trivial. You _must_ do a tinderbox run, test that stuff in an overlay or whatever. You are responsible for ALL reverse deps. The way it was done... was not appropriate. Please be more careful next time. There are still incoming bugs about broken base_src_* calls. (see the tracker) I discussed this with hasufell on IRC, but I'll lay out the response on the list too. Yes, this was my fault. We (KDE team) tested in our overlay, but none of the packages there use the base_src_* calls, which is why it didn't come up in testing, and I did not realize that there were packages that did rely on the implicit base inherit to call base_src_* directly. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlHnCfVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T6ZACcC5cDNBCODxrnzlPCTm+L4EgS wCkAniqjyBFXhIXeXyb0Wbvufkbw68yS =QM3o -END PGP SIGNATURE-
[gentoo-dev] Request for testing: plasma-active
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, The KDE team has added Plasma Active to the KDE overlay, under the (provisional) category name kde-active. Plasma Active is based on KDE and is designed for mobile devices. We are not able to test it at present as none of the KDE team has a mobile device running Gentoo, so we would be very appreciative if community members would help us by testing and reporting bugs to us. To install it, add the overlay (layman -a kde) and emerge all of the packages in the kde-active category. Thanks, Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlHE4LdfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1RYvwCgpqhdNy0VJJFPnpmQr46mCS77 mt4AnAi8c78k109hpsTPYqdcNFYpTC7j =EURc -END PGP SIGNATURE-
[gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, At the beginning of July, the KDE team will be removing EAPI 0/1 support from cmake-utils.eclass and inlining the functions from base.eclass in order to remove that inherit [1]. The modified eclass is currently available in the KDE overlay. There is one package [2] remaining in-tree which has EAPI2 which will be handled soon, but please update any overlay packages using the eclass. I have also added a deprecation warning to the in-tree cmake-utils.eclass for packages using EAPI 0/1. Chris Reffett [1] https://bugs.gentoo.org/show_bug.cgi?id=459678 [2] https://bugs.gentoo.org/show_bug.cgi?id=460572 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlG6PmRfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QIkgCfV+VLuCg3bC880EhaTiol4ggB jhQAoJaBwxZHwH9l4g48olShsnWDZBos =qeh9 -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/13/2013 06:37 PM, Alexis Ballier wrote: At the beginning of July, the KDE team will be removing EAPI 0/1 support from cmake-utils.eclass and inlining the functions from base.eclass in order to remove that inherit [1]. So, instead of fixing what you consider wrong in base.eclass, you inline it so that if someone improves base.eclass he has to do it for cmake-utils too? We did not actually inline most of the complicated logic from base.eclass, as to the best of my knowledge epatch itself will handle all of the corner cases that base_src_prepare covers. The new patching code essentially consists of [[ ${PATCHES[@]} ]] epatch ${PATCHES[@]}; epatch_user. As for the reason for the change, the request and rationale can be seen in the first bug that I linked in the email. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlG6TDVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1S3SACgitmH0FVRUNwmJE9e/4JmrwqV ucwAnj+/+V9ECy9OoCK6eDqSsuiiTgDU =5QKk -END PGP SIGNATURE-
Re: [gentoo-dev] theology herd is empty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2013 04:34 AM, Pacho Ramos wrote: If we agree on keeping this herd instead of trying to find one maintainer per package, somebody should join. Otherwise I will move their packages to maintainer-needed in a week Thanks I will join this herd, but anyone who wants to add themselves as a maintainer to a package is welcome to do so. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD8LQYACgkQ23laikJhg1SqkgCfbVyh/gK1lCwGJMkuP0I+HDPM VSwAn2rlVv6TCuvTP8EldDfXruWkHk8v =dWxs -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new qt category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/17/2013 08:57 AM, Ben de Groot wrote: Hi guys, Presently we already have a good number of split qt-* library packages in x11-libs. With the arrival of Qt5 upstream has gone a lot further in modularization, so we expect the number of packages to grow much more. We, the Gentoo Qt team, are of the opinion that the time has come to split all these out into their own category. This category is to be used for the various modules and applications that belong to the upstream Qt Framework only (these include e.g. assistant and linguist). Third-party applications should remain in the current categories. After some initial bikeshedding we came to the conclusion that naming the category simply qt is the most elegant solution. We will then also be dropping the qt- prefix in package names. This means x11-libs/qt-core will be moved to qt/core, and so on. Please let us know your thought on this. +1ish. I'm all for a new category (specific naming scheme to be bikeshedded, no preference there), but I think dropping the qt- prefix will lead to overly generic/already existing package names: gui declarative dbus core opengl etc. I don't see any value from dropping the prefix that would justify this. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlD4RbIACgkQ23laikJhg1SUngCfatp7/zOP4iGym3sitfH6xpA6 mPAAn2+4HWyOF5+qj2DNIn9IjflOXYc4 =TuOb -END PGP SIGNATURE-
[gentoo-portage-dev] egencache and dotfiles
When egencache attempts to parse cache files in a directory containing dotfiles, .gitignore for example, a failure occurs: Unable to parse cp for '.gitignore' The related code appears to be here (bin/egencache): for cpv in trg_cache: cp = cpv_getkey(cpv) if cp is None: self.returncode |= 1 writemsg_level( Unable to parse cp for '%s'\n % (cpv,), level=logging.ERROR, noiselevel=-1) else: dead_nodes.add(cpv) After diving deeper into the code I found the file pym/portage/cache/flat_hash.py. The __iter__ declared here uses os.listdir(), which from what I've read does not ignore dotfiles. I found a quick fix through adding an additional condition here: --- if l.endswith(.cpickle) or l.startswith(.): --- However I'm not 100% certain that this is the overall best solution with my knowledge of the portage code and wanted to get some insight. - Chris
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2012 08:52 AM, Tomáš Chvátal wrote: 2012/10/31 Dirkjan Ochtman d...@gentoo.org: That's rather unsurprising... If you're going to file bugs in a semi-automated manner, might as well try to assign to the correct maintainer? Yep he should've assign them, but anyway the annoying elog messages are an issue. And quite few packages suffer from it :-) Tom I disagree on most of them (and have marked the KDE-related bugs as WONTFIX appropriately). Messages that tell the user about config options, or for x functionality install y (at least until we get SDEPEND or something similar added to portage) should show up every time in my opinion. Only initial config and you just enabled (flag) really merits this. Basically, I would rather the user get too many elog messages than not enough, since I feel that a lot of people skip over them anyway and so the only display once method makes it far too easy for important messages to get lost in the shuffle. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCRQQAACgkQ23laikJhg1Q+aQCeLfXsAmbtXNGOcBzM/vJaMat2 ly0AoKFzB3tPLaSO2RK0p2rWd6CoKMXm =J+3S -END PGP SIGNATURE-
Re: [gentoo-dev] dev-embedded/tigcc needs an urgent bump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/12 07:48, Pacho Ramos wrote: El lun, 23-04-2012 a las 20:35 +0200, Pacho Ramos escribió: Our stable versions are broken for a long time, they even don't compile, but we cannot stable latest testing version because of a buffer overflow problem. A bump could help, but looks like embedded team doesn't have enough time for it. Is anybody interested in taking care of it? Its bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=tigcclist_id=978701 Thanks Or maybe we should simply treeclean it if nobody is willing to fix/maintain it and since nothing in the tree needs it... I've submitted what I hope is fix for the buffer overflow problem to bug 337059. Will that be sufficient to remove the block on stabilization? - --Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+dm5gACgkQ23laikJhg1Q2aQCeOOHS3tB0gVfCxQ79ldSBMV3N gEYAn3Ek1hpIhU/CSjsLxMEa13bx8R0t =0uOv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: /usr vs. initramfs redux
On 6 August 2011 20:22, Steven J Long sl...@rathaus.eclipse.co.uk wrote: I don't get why we can't allow udev to need localmount, as described in the bug, with CONFIG_DEVTMPFS creating nodes needed to mount /usr /var etc, especially as that setting is now being recommended by upstream. (And ofc we don't have to use it if it's not needed.) Personally, I need udev to start before localmount so that localmount can mount my LVM volumes. I have CONFIG_DEVTMPFS enabled too, and I like how it made my initramfs simpler, but it doesn't read rules from userspace. But udev does.
Re: [gentoo-dev] /usr vs. initramfs redux
On 6 August 2011 20:52, Michał Górny mgo...@gentoo.org wrote: Then yes, such minimal initramfs should propably be covered in the embedded's documentation, but otherwise trying to avoid dracut is reinventing the wheel... You may be right, but to my understanding such a minimalistic initrd would really do nothing special. Possibly a small shell script run You just transformed a minimalistic initrd into awfully complex command interpreter... The /init on the initramfs should be a shell script, shouldn't it? If this initramfs is going to be recommended in the handbook, we need to provide an initramfs that isn't going to be too difficult to understand. Like one that can be simply extracted, tweaked, and re-compressed.
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
On 30 July 2011 08:27, Samuli Suominen ssuomi...@gentoo.org wrote: Since running separate /usr without mounting it from initramfs on top of / before init is and has been broken with udev for a long time now[1][2][3] [1] http://bugs.gentoo.org/show_bug.cgi?id=364235 [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr [3] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Can we warn users about not doing the separate /usr mistake in the handbook? I reported this to bugzilla[1] in June. There was no resolution, but the discussion was interesting and worth reading. To summarize, changing the handbook would be a start, but it doesn't solve the larger problem, and separate /usr will be supported for as long as it is practical to do so. I don't know how to resolve the situation, but I'm relieved to hear that other people care. [1] https://bugs.gentoo.org/show_bug.cgi?id=372317
Re: [gentoo-dev] Automatic testing on Gentoo
On 05/10/2011 03:13 PM, Jorge Manuel B. S. Vicetto wrote: So, why more testing? For starters, more *automatic* testing. Then more testing as reports from testing can help greatly in identifying when things break and why they break. As someone that looks over the automatic stage building for amd64 and x86, and that has to talk to teams / developers when things break, having more, more in depth and regular automatic testing would help my (releng) job. While I agree whole-heartedly with the sentiment being expressed here, I just want to point out and remind everyone that automated testing is no substitute for real live people using (and breaking) things. People are remarkably inventive and creative when it comes to finding ways to break things in ways that the developers never even considered. All I'm trying to say is that I've seen (and worked on) far too many teams in the past that fell into the trap of thinking automated testing was sufficient. It isn't, but it certainly goes a long way towards helping make the manual tester's lives better, by letting them focus on finding those problems that aren't (for one reason or another) reproducible in an automated testing scenario. Later, Chris
Re: [gentoo-dev] RFC: Making largefile a global use
On 03/10/2011 02:35 AM, Mike Frysinger wrote: i cant see much value anymore in even making this an option. just drop the USE flag and always use LFS. -mike +1
Re: [gentoo-dev] Quantity of open bugs
On 03/10/2011 02:25 PM, Kevin F. Quinn wrote: Hi all, I was nosing through bugzilla, and noticed: * Number of open bugs is greater than 14,000 * Number of open bugs untouched for more than 2 years - well over 2000. * Number of open bugs untouched between 1 and 2 years - well over 2000. * Number of open bugs untouched between 6 months and 1 year - well over 2000. * Number of open bugs untouched between 3 months and 6 months - over 2000 The winner is bug #78406, which hasn't been touched for over 2240 days - over 6 years - at the time of writing. I would guess these old untouched bugs aren't actually going to be touched, ever - a lot simply won't be relevant any more for one reason or another. All they're doing is cluttering up bugzilla. I think Duncan has already covered the major points I was going to mention: particularly with respect to the fact that we are all volunteers and thus subject to resource constraints that other projects might not have. I realize that it is frustrating to a user to have a bug sit for a year (or more) without ever being resolved (or even looked at), but there is really only one way to resolve that: get someone who has the time and expertise to step in and fill the gap. Given that we can't exactly hold a gun to people's heads and MAKE them work on Gentoo stuff (nor would I personally be inclined to trust code produced using such methods), I really don't see another alternative. We closed a number of bugs related to SELinux recently; many of those bugs had been open for quite some time and things had changed sufficiently that we believed that the bug itself was no longer relevant, or we needed feedback from the user and didn't get any. Some of those bugs had been open for a couple of years. But we reviewed EACH of those bugs and made a decision on a case-by-case basis. I understand and appreciate the desire to close open bugs that are cluttering up the bugzilla. Not only do they create extra cruft for everyone to wade through, they also make Gentoo look bad (my GOD, they've got open bugs dating back to the founding of the Roman Empire!). However, I'm not convinced that blanket closing bugs that are over x days (weeks, months, years) is the best (or even desirable) approach. If a bug is related to a package that no longer exists, then it seems pretty obvious that there is no need to keep the bug around. If the bug is waiting on feedback from a user, and that user hasn't provided the requested feedback in, say, 60 days (after a bump to the bug) then I'd say that the bug is arguably no longer of importance to the user, or at least the email address we have on file for that user doesn't work any more. Beyond those two conditions, I'd really be loathe to close anything without good evidence to indicate that it either is no longer relevant, or it can't be fixed. Just my $0.02 (not adjusted for currency devaluation) Later, Gizmo
Re: [gentoo-dev] Re: Lastrite: lince and slmodem
On 02/04/2011 05:24 PM, Diego Elio Pettenò wrote: This said, I'd suggest users and developers alike to add themselves (or ask to be added) to the metadata.xml files for packages requiring specific hardware support, so that even if one maintainer ends up not being active, we have a list of people who can actually tell us whether a given package works or not. And don't simply avoid doing so because there is someone else on that list already; we don't have a limit of one, two or three people listed in metadata.xml. The more people we know are ready to test a given package on actual hardware, the better (and you can be listed as just a tester after all). What's true of developers is also true of users; a user may add themselves to the list, forget they are on it, and a year from now be asked to test something they no longer have hardware for. Not saying that this isn't worth doing, merely pointing out that we may discover that we don't have anyone to test even WITH the list of willing users. Later, Chris
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 12/31/2010 03:38 PM, Rich Freeman wrote: On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysingervap...@gentoo.org wrote: personally, i dont see a problem here. what actual burden is there for continuing supporting EAPI 0/1 ? i dont think we should go around deprecating things for the pure fun of it. -mike I tend to agree, unless of course the maintainers of the various package managers chime in and say that some aspect of some particular EAPI requires them to maintain a lot of legacy code. Then I'd be all for dropping some. I'm not a gentoo dev, but I tend to agree here. If it ain't broke, don't fix it. Later, Gizmo
Re: [gentoo-dev] selinux profiles as 'dev' instead of 'stable' in profiles.desc?
On Sat, 2009-08-15 at 15:28 +0300, Samuli Suominen wrote: I find it very hard to commit thesedays since tree is full of DEPEND.bad's from selinux profiles (existing ones that I didn't create). I vote for marking these profiles as dev, instead of stable since that's what they seem to be. Any thoughts? How about informing the SELinux team? I don't see any bugs nor have I received any emails about it. -- Chris PeBenito peben...@gentoo.org Developer, Hardened Gentoo Linux Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE6AF9243 Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
On Sat, 2008-06-07 at 14:46 +0100, Alex Howells wrote: I agree with both of these and also think both agaffney and wolf31o2 would serve us excellently on Council. Consider them nominated too :) Thanks, but I no longer have the time nor the desire to dedicate to the Council. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 11:14 +0100, Ciaran McCreesh wrote: But some EAPI-0 accepting Portage versions don't accept inline comments. Using inline comments in the tree will break those Portage versions. Yes, and EAPI=0 accepting Portage versions also didn't accept things like package.use and use.mask in the profiles, considering that EAPI=0 doesn't have a set definition and was based upon a particular portage version that did have the required support. So should we ban those from the tree, too? Oh yeah, PMS isn't approved, anyway, so there's no policy *at all* within Gentoo that denies a package manager from being used that doesn't conform to your idea of how things should work. This one's especially an issue when you consider how long it's been since Gentoo has released official stage tarballs... Wow. Your second stab at my team in 3 days, without me even responding. I should probably be blushing if it weren't for the fact that I really don't give a damn about you or anything that you say. Quite honestly, the same goes for pretty much anybody who works with you. You are a poisonous person to Gentoo and I sincerely wish that some day people around here will grow a pair and realize that your incessant self-absorbed bullshit simply isn't something we really want around here. I mean, we've already thrown out you and three of your cronies because your attitude sucks and you're all a pain in the ass to work with. What exactly do we need to do here? Ban you all? I find it massively amusing that most of the traffic on this list over the past 3 days has come from people that have been *FORCIBLY* removed from the Gentoo project. Oh yeah, don't bother responding to me. I've decided to put you and all of your little cohorts into my killfile so I no longer have to read your constant barrage of bullshit. Seriously, you're a complete fucking waste. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 11:22 +0100, David Leverton wrote: PS: An example of something in PMS that is different from Portage: inline comments are disallowed. The only reason I can think for doing this is to not make Paludis change it's behaviour. Fortunately you don't have to think, you can just read Ciaran's explanation. Yes, because we all should stop thinking for ourselves and let Ciaran tell us what to think. After all, we all want to be like the cool Paludis developers. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 12:22 +0200, Luca Barbato wrote: David Leverton wrote: On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote: Interesting to note, however, that Paludis doesn't accept inline comments, and this behaviour predates PMS. There's a reason for Paludis not accepting them, and the same reason applies to the question of allowing them in PMS or not, therefore PMS doesn't allow them. There's no evil conspiracy here, just pure logic. Care to share the logic and wise reasoning ? [ ${IDEA_ORIGIN} != Ciaran ] die -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 11:23 +0100, Ciaran McCreesh wrote: Did you check whether Portage that's included in current Gentoo releases supports inline comments in profiles? Yeah, the version in 2008.0_beta2 surely does. Perhaps you meant something else? Well, either that, or you're just posting more of your bullshit where you obscure or otherwise lie about the facts to suit yourself. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 11:27 +0100, Ciaran McCreesh wrote: Well, then it should be updated to match current Portage behaviour. PMS is not supposed to document How portage worked at one point of time or The intersection of the capabilities of Portage and Paludis. It should follow the current portage's behaviour as closely as possible. Do you really want to make it impossible to install Gentoo using the most recent official release? Because that's what will happen if we do what you're suggesting... Considering that the most recent official release is 2008.0_beta2, I don't see where you have a point, at all. Sure, you're going to mention something about being labeled a beta, to which my response will be that you're simply backpedaling and changing the facts to suit your needs. After all, looking at /releases on the mirrors, I see a nice and shiny 2008.0_beta2 on all of the officially-supported arches. Isn't it about time that you gave up on your little mission to consistently undermine the hard work put in by a community of volunteers? Of course not... You need to stroke your ego some more. Pfft... -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 12:44 +, Duncan wrote: Ciaran's right on this one. It may have been a bug in portage, now fixed, but at least until a stable current release media set, a working PMS can't change the EAPI-0 definition to fail with portage on the old release media, however stale it might be. If a current release happens before PMS EAPI-0 finalization, this could possibly be subject to debate, but until then, it just doesn't work, however much we might wish it could. No, he isn't. For one, we're talking make.conf, not the profiles. Second, there's a newer official (and stable) media set. Sorry if you don't like the beta moniker, which applies to the media set. After all, does a package suddenly become less stable because it is included in a tarball that has beta in the *FILE NAME* ? I don't think so. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Sun, 2008-06-15 at 15:50 +0100, Ciaran McCreesh wrote: Do you think that the differences between the proportion of patches from 'Paludis people' that are accepted or rejected and the proportion of patches from 'Portage people' or 'Pkgcore people' indicates a problem? Nope. What I see as a problem is that the primary author and current de facto maintainer is so much of an asshole that he was forcibly removed from the Gentoo project, which PMS is supposed to be written for, and has ostracized (at least) one of the package manager's development team with his constant not-so-subtle attacks. Quite frankly, I'd prefer see Gentoo take control over the specification that defines the most important single feature of Gentoo and remove the non-Gentoo developers from its development. No offense, but you're not a Gentoo developer any longer and you shouldn't have a say in how *we* manage ourselves. You're more than welcome to contribute code, fork, or whatever the hell you want. This is open source, after all, but that doesn't mean you should be allowed to hold the position of power over Gentoo that you've been granted. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Sun, 2008-06-15 at 16:04 +0100, David Leverton wrote: On Sunday 15 June 2008 15:42:28 Peter Volkov wrote: For example, currently, PMS team does not include anybody from portage team - official PM team and thus this team can't represent Gentoo interests. The Portage team is perfectly welcome to contribute if they wish. zmedico is on the alias, although he seems to have been focussing on working on Portage itself. genone, from what I've seen, seems to be indifferent at best to the idea of PMS. I'm curious as to why you think the actively contributing members of the PMS team aren't acting in Gentoo's interests, though. Maybe because they were booted from Gentoo for not acting in Gentoo's best interest? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages broken by phase ordering change
On Sat, 2008-06-14 at 15:09 +0100, Ciaran McCreesh wrote: On Fri, 13 Jun 2008 21:55:29 +0200 Santiago M. Mola [EMAIL PROTECTED] wrote: As discussed in bug #222721, portage has changed the execution order of phases. It seems the change was introduced in portage-2.1.5 and it makes that, when upgrading a package, pkg_postinst is run after the old version has been removed. This breaks packages which use has_version in pkg_postinst to detect upgrades/downgrades. It can also break packages in more subtle ways. Given that the number of affected ebuilds is so high, I'd say Portage should have to revert the changes... Of course, you would. What else would we expect from you? This is an EAPI scope change, if anything. Although even then the implications are a bit messy since you're talking the interaction of two different EAPIs. It seems that everything these days is an EAPI scope change. That's not very useful for Gentoo, considering it's been quite some time since PMS was proposed and we've not seen approval for either EAPI=0 or EAPI=1 (or PMS, for that matter). What we have gotten is a half-assed you can use EAPI=1 in the tree to get these enumerated features from the Council, but that's nothing like acceptance of a spec. Perhaps if you spent a little more time doing something more constructive than being an asshat on the lists, PMS would have been approved long ago. Of course, that doesn't mesh well with your apparent need to be a complete dick to people, so continue on with the status quo. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] OT Foundation - Council was - Nominations for council
Can you take this off-topic thread to the appropriate list? I'm pretty tired with hearing the Foundation's self-promotional comments on how important it is to development on this list. You guys have your own list for that crap, as it is. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] removal of old selinux masking from profiles
I still see that masking of SELinux packages that I made back in 2006 have propagated out to current profiles: arch/mips/package.mask arch/sparc/package.mask default/linux/package.mask default-linux/alpha/no-nptl/package.mask default-linux/mips/package.mask default-linux/sparc/sparc64/package.mask default-linux/x86/no-nptl/package.mask features/no-nptl/package.mask The masking is only required if the profile does not have a working/stable glibc = 2.4. Would the relevant herds please remove the masking from the profiles (assuming there is an appropriate glibc)? If there isn't an appropriate glibc, I'd ask that you make a comment in the file so you remember to remove the mask in the future :) Thanks -- Chris PeBenito [EMAIL PROTECTED] Developer, Hardened Gentoo Linux Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE6AF9243 Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: lzma tarball usage
On Wed, 2008-05-07 at 16:23 +0300, Mart Raudsepp wrote: I do realize one would remove build-time dependencies and the toolchain on an embedded system on deployment anyway, but this means gcc USE=nocxx USE flag is pretty much useless, while it would be nice to use it to ensure that nothing sneaks in during development that depends on the C++ standard library easily instead of finding things break later. It's a pain in the ass for Release Engineering, too. At this point, we're looking into how we need to modify the bootstrap sequence to accommodate people using lzma for system (and lower) packages. http://bugs.gentoo.org/show_bug.cgi?id=220074 We're already getting reports of this due to someone deciding that it'd be a good idea to use lzma for our daily portage snapshots without any discussion here. Luckily, we still have the other tarballs to use, too. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] config_eth0 deprecated - new name?
On Wed, 2008-04-23 at 16:21 +0100, Roy Marples wrote: address_eth0? addresses_eth0? I think one of these two is the most obvious to people. Since most people will likely only have one address per interface, I'd say that address_eth0 sounds good. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Tue, 2008-04-22 at 08:09 +0100, Ciaran McCreesh wrote: We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. If the alternatives are not being able to install from a binary at all due to circular dependencies, or being able to install from a binary using DEPEND to satisfy circular dependencies, which would you take? Given the trouble that we have every release with trying to cram everything our users want into a limited space, I'd rather the damned thing not install than pull in a bunch of packages we don't need, just to satisfy a dependency that isn't even used during execution of the package. I'd love to have some kind of functionality to allow some kind of optional dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Sort of like what kdebuild has for suggested dependencies, but less strong? Pretty much, yeah. The main difference that I would see from the current *DEPEND variables, besides what was said above, would be that a lack of visibility wouldn't stop the package merge. If sys-apps/foo had ODEPEND=dev-libs/bar and dev-libs/bar was masked, it simply wouldn't be installed. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 2008-04-19 at 06:33 +0100, Ciaran McCreesh wrote: On Fri, 18 Apr 2008 22:27:21 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: My interpretation is pkg_* counts as runtime (I can imagine a package wanting to run itself at this point), so packages in RDEPEND should be usable at that point. Which would be fine, except it makes the tree unusable. Really, it seems to be an additional type of dependency that neither DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't quite capturing it either. Yup, and for future EAPIs labels can fix this. But we have to have a sound solution for current EAPIs. I would agree that RDEPEND should likely be installed prior to pkg_preinst to satisfy the dependency. After all, PDEPEND is good enough for doing packages that aren't required at pkg_preinst/pkg_postinst. We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. I'd love to have some kind of functionality to allow some kind of optional dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Simple example: ODEPEND=video_cards_nvidia? ( x11-drivers/nvidia-drivers) would install x11-drivers/nvidia-drivers the first time it's ran with VIDEO_CARDS=nvidia, but if I removed x11-drivers/nvidia-drivers, it wouldn't get reinstalled. This would probably need some kind of --newuse like capability to allow for installing only *new* optional dependencies, but I think that the tracking would already allow that. The idea here would be to allow for installing recommended software along with others. We could even have --ask ask for the dependencies, since they are optional, after all. This way, we could ship a more robust configuration/setup for many popular applications without forcing software on people. It's an idea, anyway, and I hope that I didn't hijack the thread. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Early stabilisation
On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote: thirty days is the norm for the minimal period between an ebuilds last It is the norm. It is not a requirement. In fact, it is specifically a guideline rather than a hard rule. It is up to the maintainer's discretion when to ask for stabilization, just like it is up to the arch team's discretion when to actually *do* the stabilization. If you don't think that it's ready on your arch, say so, but be prepared to defend why you think so when the package maintainer, who should be much more familiar with the package, thinks that it is ready. On the other hand, maybe these early stabilisation bug reports are a sign of the times and we need to shorten the normal thirty day period, become even more of a cutting edge distro - or at least discuss the options. I'd say leave the current norm and smack the misbehaving maintainers :) Who says that they're misbehaving? Again, the maintainers probably know their packages better than anyone else, so why are we not trusting their judgement again? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] New profiles
Please remember to sync gentoo-x86/profiles before doing any further commits. The new profiles need as much checking as possible. There have been several commits made by people who have masked things and such but forgot the new profiles. Also, if you make changes to any of the new profiles, please let me know so I can sync the changes into the snapshot tree. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list