Re: [gentoo-dev] Re: Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request
On Sat, 11 Mar 2017 22:25:45 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Alexis Ballier posted on Sat, 11 Mar 2017 20:59:56 +0100 as excerpted: > > > On Sat, 11 Mar 2017 20:45:07 +0100 "Andreas K. Huettel" > > wrote: > >> This keywording bug 597822 is now open since 2016-10-22. > > > > > > Man, it's been only 5 months :) > > ... which will make it six months after the announced 30-day clock > expires. (Make it 45-days and it'll be a full calendar six months, > half a year.) > Note: this was meant as a joke / sarcasm :) I'm still waiting for texlive 2013 keywords on 2 of these arches. And yes, 2013 is the year of the release :) jer is usually dilligent for hppa, when he's not it usually means he found an issue that he'll report when he'll have time to investigate it properly As for the 2 others, I think it would make more sense to demote their profiles to dev these days.
Re: [gentoo-dev] How to deal with package forks?
W dniu 11.03.2017, sob o godzinie 21∶49 -0500, użytkownik Rich Freeman napisał: > On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric wrote: > > On Thu, 09 Mar 2017 16:34:20 +0100 > > Michał Górny wrote: > > > > > 1. classic forks -- package B is forked out of A, and the development of > > > both continue independently (eudev/systemd, ffmpeg/libav); > > > > > > 2. large patch sets / continuously rebased forks -- where the particular > > > set of changes is usually applied to mainline or regularly rebased > > > against mainline but without full separation (kernel patchsets, bitcoin > > > patches); > > > > > > 3. abandoned package forks -- package A stops being maintained upstream, > > > someone forks it and starts working on top of that (xarchiver). > > > > I think any formal guideline needs to be clear that these statements are > > with regards > > to *mutually exclusive* forks, where dual-installation is not viable and/or > > auto-linking > > magic would do bad things if they were co-installed. > > > > Partly because not all forks are done by 3rd parties. Some projects "Self > > fork". > > > > But here, the distinction between "fork" and "major version" blurs, because > > often > > the reason for a "self fork" is to explicitly allow cohabitation with the > > "old fork", > > in a manner very akin to "new major version in new slot". > > > > So with that said, in all of those cases, if the "new" fork and the "old" > > fork don't > > directly compete at a physical level, even though they share logical > > ancestry, they can be considered > > new independent software. > > So, I have to ask. All this theorizing is interesting and I think it > can make for guidelines, but do we really have any cases where it > isn't working out under maintainer discretion, other than the one case > that started this discussion? > > My sense is that everybody has already figured out the best way to > handle these kinds of patches and is already using discretion to sort > out these cases. I don't think we need a generic policy over a > dispute about how bitcoin is packaged. Actually, what started this is me wondering whether I did the right thing by switching app-arch/xarchiver to the fork. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
- Typo... Additional Security Project bugzilla notes * The Security Project is except (should that read "exempt"?) - An intermediate level before masking might be issuing a warning if some simple, specific remediation measure can protect against a vulnerability. E.g. forcing cups to only listen to 127.0.0.1 or :1 - If you want to absolutely ensure that people are warned of a severe, but remediable vulnerability, is it acceptable to "break the build" by requiring a new local USE flag for the ebuild? I'm thinking of something like "glep_0001234", "glep_0001235", "glep_0001236", etc, and have the ebuild die if the flag is not set, and print out a URL for a security problem. This could be abstracted to make.conf with a new variable... GLEP="0001234 0001235 0001236 etc etc" This would probably be the last stage before masking. It would deliberately break the build, and require the user/admin to take manual action (add the flag for the GLEP) before proceeding further. This is a heavy-handed method, but masking is more final. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand wrote: > On 03/11/2017 11:23 PM, Andrew Savchenko wrote: >> >> My point is that users must be informed about security problem, but >> they still should have a choice. So it should be either a rule >> "mask without removal" or clear guidelines when to remove a >> package and when to not. > > At some point, of a package does not belong in the main tree due to > security vulnerabilities, they can still be kept in an overlay by a > respective project without it impacting other users. I'm not convinced > that impacts the overall user experience of other Gentoo users. > Is there any reason that this can't be left to maintainer discretion? The package is masked and clearly advertises its security issue. The user can make an informed choice. Do we really need to force the issue further? What is the benefit to Gentoo in doing so? -- Rich
Re: [gentoo-dev] How to deal with package forks?
On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric wrote: > On Thu, 09 Mar 2017 16:34:20 +0100 > Michał Górny wrote: > >> 1. classic forks -- package B is forked out of A, and the development of >> both continue independently (eudev/systemd, ffmpeg/libav); >> >> 2. large patch sets / continuously rebased forks -- where the particular >> set of changes is usually applied to mainline or regularly rebased >> against mainline but without full separation (kernel patchsets, bitcoin >> patches); >> >> 3. abandoned package forks -- package A stops being maintained upstream, >> someone forks it and starts working on top of that (xarchiver). > > I think any formal guideline needs to be clear that these statements are with > regards > to *mutually exclusive* forks, where dual-installation is not viable and/or > auto-linking > magic would do bad things if they were co-installed. > > Partly because not all forks are done by 3rd parties. Some projects "Self > fork". > > But here, the distinction between "fork" and "major version" blurs, because > often > the reason for a "self fork" is to explicitly allow cohabitation with the > "old fork", > in a manner very akin to "new major version in new slot". > > So with that said, in all of those cases, if the "new" fork and the "old" > fork don't > directly compete at a physical level, even though they share logical > ancestry, they can be considered > new independent software. > So, I have to ask. All this theorizing is interesting and I think it can make for guidelines, but do we really have any cases where it isn't working out under maintainer discretion, other than the one case that started this discussion? My sense is that everybody has already figured out the best way to handle these kinds of patches and is already using discretion to sort out these cases. I don't think we need a generic policy over a dispute about how bitcoin is packaged. -- Rich
Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies
On Thu, 09 Mar 2017 18:16:51 -0500 "William L. Thomson Jr." wrote: > That would likely be an incorrect ebuild and should not have been committed > to > tree. If people didn't accidentally overlook problems where variables contained the wrong contents and tried to access files they shouldn't, we wouldn't have a need for Gentoo Maintainers. More over, we wouldn't need a lot of security we have these days, and PHP features like register_globals would have never been considered a bad thing. But the reality is, sometimes you write bugs in your code where you're not looking at it carefully enough. Sometimes said bugs sneak through code review, tests, and about 100 people installing it without issue. Hence a defensive approach of "Look, I don't think I've done anything really bad here, but just in case reality starts bending in on itself, lets put in some sensible BANG points to catch that". You're not going to remember every time you aught to put such BANG points in place, but the hope is that having *2* mental toolkits: "Don't make mistakes" and "Put things in place to go bang when I make mistakes", With a bit of luck, both won't fail a the same time. But that's just me I guess. || die "Error sending clear message by email" pgpTDurvdTHEu.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] How to deal with package forks?
On Thu, 09 Mar 2017 16:34:20 +0100 Michał Górny wrote: > 1. classic forks -- package B is forked out of A, and the development of > both continue independently (eudev/systemd, ffmpeg/libav); > > 2. large patch sets / continuously rebased forks -- where the particular > set of changes is usually applied to mainline or regularly rebased > against mainline but without full separation (kernel patchsets, bitcoin > patches); > > 3. abandoned package forks -- package A stops being maintained upstream, > someone forks it and starts working on top of that (xarchiver). I think any formal guideline needs to be clear that these statements are with regards to *mutually exclusive* forks, where dual-installation is not viable and/or auto-linking magic would do bad things if they were co-installed. Partly because not all forks are done by 3rd parties. Some projects "Self fork". But here, the distinction between "fork" and "major version" blurs, because often the reason for a "self fork" is to explicitly allow cohabitation with the "old fork", in a manner very akin to "new major version in new slot". So with that said, in all of those cases, if the "new" fork and the "old" fork don't directly compete at a physical level, even though they share logical ancestry, they can be considered new independent software. pgpfAAErH4s1P.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 03/11/2017 11:23 PM, Andrew Savchenko wrote: > Hi Kristian, > > On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: >> A draft of a Pre-GLEP for the Security project is available for reading >> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security >> >> The GLEP follows a line of GLEPs for special projects that have >> tree-wide access in order to ensure proper accountability (c.f GLEP 48 >> for QA and still non-produced GLEP for ComRel (I've started working on >> this and will be presenting this one later as current ComRel Lead)) >> >> Comments, patches, threats, etc welcome > > First of all, thank you for this Pre-GLEP, since we really need some > public and established policy for the Security project. > > 1. From this proposal it looks like the Security Project Lead > obtains a lot of power and a lot of responsibility, maybe too much > for a single person to handle. > > While the Deputy may be assigned, this still gives all power to > single hands. Maybe it will be better to establish something like > the Security Project Council (SPC)? E.g. three project members may > be elected to this SPC, so that all serious decisions will require > some team agreement from at least 2 SPC members. This way the > Deputy will not be needed as well. > The thinking here is that the project lead is the responsible party. Any ambiguity can still be escalated to the Gentoo Council, but someone needs to be responsible from the side of the Gentoo Security Project. > 2. "If a vulnerability is unlikely to be fixed by upstream or the > package's maintainer it might require a package mask." — I'd like > to see this expanded to more detail, because it is possible to mask > for removal and to simply mask without scheduled removal. > > Sometimes an application is desirable even if it is vulnerable, > e.g. if there are no alternatives. Sometimes a vulnerability is > minor or affect a very rare use case. Sometimes users need a > specific software version for their workflow and they don't really > care about security — this affects many scientific packages being > used at isolated HPC setups. > > My point is that users must be informed about security problem, but > they still should have a choice. So it should be either a rule > "mask without removal" or clear guidelines when to remove a > package and when to not. At some point, of a package does not belong in the main tree due to security vulnerabilities, they can still be kept in an overlay by a respective project without it impacting other users. I'm not convinced that impacts the overall user experience of other Gentoo users. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-scheme/schoca
# Michael Palimaka (11 Mar 2017) # Fails to build. Dead upstream. # Masked for removal in 30 days. Bug #592184. dev-scheme/schoca
[gentoo-dev] Re: Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request
Alexis Ballier posted on Sat, 11 Mar 2017 20:59:56 +0100 as excerpted: > On Sat, 11 Mar 2017 20:45:07 +0100 "Andreas K. Huettel" > wrote: >> This keywording bug 597822 is now open since 2016-10-22. > > > Man, it's been only 5 months :) ... which will make it six months after the announced 30-day clock expires. (Make it 45-days and it'll be a full calendar six months, half a year.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
Hi Kristian, On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: > A draft of a Pre-GLEP for the Security project is available for reading > at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide access in order to ensure proper accountability (c.f GLEP 48 > for QA and still non-produced GLEP for ComRel (I've started working on > this and will be presenting this one later as current ComRel Lead)) > > Comments, patches, threats, etc welcome First of all, thank you for this Pre-GLEP, since we really need some public and established policy for the Security project. 1. From this proposal it looks like the Security Project Lead obtains a lot of power and a lot of responsibility, maybe too much for a single person to handle. While the Deputy may be assigned, this still gives all power to single hands. Maybe it will be better to establish something like the Security Project Council (SPC)? E.g. three project members may be elected to this SPC, so that all serious decisions will require some team agreement from at least 2 SPC members. This way the Deputy will not be needed as well. 2. "If a vulnerability is unlikely to be fixed by upstream or the package's maintainer it might require a package mask." — I'd like to see this expanded to more detail, because it is possible to mask for removal and to simply mask without scheduled removal. Sometimes an application is desirable even if it is vulnerable, e.g. if there are no alternatives. Sometimes a vulnerability is minor or affect a very rare use case. Sometimes users need a specific software version for their workflow and they don't really care about security — this affects many scientific packages being used at isolated HPC setups. My point is that users must be informed about security problem, but they still should have a choice. So it should be either a rule "mask without removal" or clear guidelines when to remove a package and when to not. Best regards, Andrew Savchenko pgpg_bm2zlxSw.pgp Description: PGP signature
[gentoo-dev] last rites: dev-perl/Net-Google-SafeBrowsing-UpdateRequest dev-perl/Mail-SpamAssassin-Plugin-GoogleSafeBrowsing
# Andreas K. Hüttel (11 Mar 2017) # Fails since upgrade to dev-lang/perl-5.12 (!). # Removal in 30 days. Bug 336898. dev-perl/Net-Google-SafeBrowsing-UpdateRequest dev-perl/Mail-SpamAssassin-Plugin-GoogleSafeBrowsing -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-libs/btparse
(side notes, * the original dev-libs/btparse library has not seen any updates since 2007 * the Perl version removed the separate (autoconf) build system, so only Makefile.PL really works now...) # Andreas K. Hüttel (11 Mar 2017) # Dead upstream; the library has been picked up by # dev-perl/Text-BibTeX and is further developed there. # Please uninstall dev-libs/btparse and re-build your # application against >=dev-perl/Text-BibTeX-0.780.0-r1 # (this should happen automatically with tellico, the # only reverse dependency in the main tree). # Removal in 30 days. dev-libs/btparse -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-java/jusb
# Patrice Clement (11 Mar 2017) # Upstream dead: no update since 2003. Ebuild is outdated and buggy. # Removal in 30 days. Bug #279088 dev-java/jusb -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] RFC: Pre-GLEP: Security Project
A draft of a Pre-GLEP for the Security project is available for reading at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security The GLEP follows a line of GLEPs for special projects that have tree-wide access in order to ensure proper accountability (c.f GLEP 48 for QA and still non-produced GLEP for ComRel (I've started working on this and will be presenting this one later as current ComRel Lead)) Comments, patches, threats, etc welcome -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
On 3/11/17 3:13 PM, Peter Stuge wrote: > > All lines containing +knots should say knots instead. > Done. I'm getting increasingly unsatisfied with where bitcoins* is going. I think I'd like to take full ownership of it and remove all unnecessary patches. If there's anyone that wants to co-maintain it with me, I'd welcome the help. I'm busy until summer at which time I revisit the issue and try to clean up the eclass and ebuilds. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request
On Sat, 11 Mar 2017 20:45:07 +0100 "Andreas K. Huettel" wrote: > This keywording bug 597822 is now open since > 2016-10-22. Man, it's been only 5 months :)
[gentoo-dev] Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request
Forwarded message: https://bugs.gentoo.org/show_bug.cgi?id=597822 --- Comment #5 from Andreas K. Hüttel --- @@@ IMPORTANT MESSAGE TO ARCH TEAMS @@ I'll drop keywords for mod_perl and all of its reverse dependencies for any arch that has not even restored the KEYWORD yet in this bug, 30 days from today. This keywording bug 597822 is now open since 2016-10-22. This means in particular, if you're still interested in running mod_perl on hppa, ia64 or sparc, get your backside moving now! @@@ IMPORTANT MESSAGE TO ARCH TEAMS @@ -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
Anthony G. Basile wrote: > >> I proxy maintain bitcoins for luke-jr. He wants to propose a patch > >> against the bitcoin eclass. The following is his proposed change. > >> I'll commit it after review. > > > > Please do not do that, Anthony. > > I don't have time nor the familiarity to properly maintain bitcoins > myself. Understood, and no problem. I think it's especially important to be a bit conservative under those circumstances. > I will ignore all negative advice regarding this package unless it is > balanced with positive advice. That's cool. I tried to also be constructive in my mail - sorry if that didn't get through. I was saying that the patched version should probably be a separate ebuild. But Mathy's (sorry for the mistype in my last mail Mathy) suggestion to go ahead with renaming the USE flag but *not* flipping it to default on is also a good step. > Please point out what lines of the patch should be changed and what > they should be changed to, else I will commit the patch as > provided. All lines containing +knots should say knots instead. Thanks! //Peter
[gentoo-dev] [PATCH] eutils.eclass: Kill multilib inherit for EAPI 7
The multilib.eclass seems not to be used by any eutils function. Therefore, disable the inherit for EAPI 7. It is being preserved for older EAPIs not to break ebuilds inheriting this eclass and using multilib.eclass functions implicitly. --- eclass/eutils.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass index 724a310b3000..e036001dc5e1 100644 --- a/eclass/eutils.eclass +++ b/eclass/eutils.eclass @@ -17,12 +17,12 @@ if [[ -z ${_EUTILS_ECLASS} ]]; then _EUTILS_ECLASS=1 -inherit multilib toolchain-funcs +inherit toolchain-funcs # implicitly inherited (now split) eclasses case ${EAPI:-0} in 0|1|2|3|4|5|6) - inherit epatch estack + inherit epatch estack multilib ;; esac -- 2.12.0
[gentoo-dev] [PATCH v2] epatch.eclass: Split epatch* logic from eutils
Move epatch and epatch_user (along with the descriptions for all their variables) into a dedicated epatch.eclass. This function is very complex, therefore it benefits from separate eclass and a dedicated maintainer. Furthermore, it is mostly obsoleted by eapply* in EAPI 6. The new eclass is implicitly inherited by eutils to preserve compatibility. However, the inherit will be removed in EAPI 7, and the ebuilds should switch to inheriting epatch directly or using eapply*. Thanks to Ulrich Müller for doing the necessary research. --- eclass/epatch.eclass | 458 +++ eclass/eutils.eclass | 440 + 2 files changed, 459 insertions(+), 439 deletions(-) create mode 100644 eclass/epatch.eclass diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass new file mode 100644 index ..fb0a10b53583 --- /dev/null +++ b/eclass/epatch.eclass @@ -0,0 +1,458 @@ +# Copyright 1999-2017 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +# @ECLASS: epatch.eclass +# @MAINTAINER: +# base-sys...@gentoo.org +# @BLURB: easy patch application functions +# @DESCRIPTION: +# An eclass providing epatch and epatch_user functions to easily apply +# patches to ebuilds. Mostly superseded by eapply* in EAPI 6. + +if [[ -z ${_EPATCH_ECLASS} ]]; then + +# @VARIABLE: EPATCH_SOURCE +# @DESCRIPTION: +# Default directory to search for patches. +EPATCH_SOURCE="${WORKDIR}/patch" +# @VARIABLE: EPATCH_SUFFIX +# @DESCRIPTION: +# Default extension for patches (do not prefix the period yourself). +EPATCH_SUFFIX="patch.bz2" +# @VARIABLE: EPATCH_OPTS +# @DESCRIPTION: +# Options to pass to patch. Meant for ebuild/package-specific tweaking +# such as forcing the patch level (-p#) or fuzz (-F#) factor. Note that +# for single patch tweaking, you can also pass flags directly to epatch. +EPATCH_OPTS="" +# @VARIABLE: EPATCH_COMMON_OPTS +# @DESCRIPTION: +# Common options to pass to `patch`. You probably should never need to +# change these. If you do, please discuss it with base-system first to +# be sure. +# @CODE +# -g0 - keep RCS, ClearCase, Perforce and SCCS happy #24571 +# --no-backup-if-mismatch - do not leave .orig files behind +# -E - automatically remove empty files +# @CODE +EPATCH_COMMON_OPTS="-g0 -E --no-backup-if-mismatch" +# @VARIABLE: EPATCH_EXCLUDE +# @DESCRIPTION: +# List of patches not to apply. Note this is only file names, +# and not the full path. Globs accepted. +EPATCH_EXCLUDE="" +# @VARIABLE: EPATCH_SINGLE_MSG +# @DESCRIPTION: +# Change the printed message for a single patch. +EPATCH_SINGLE_MSG="" +# @VARIABLE: EPATCH_MULTI_MSG +# @DESCRIPTION: +# Change the printed message for multiple patches. +EPATCH_MULTI_MSG="Applying various patches (bugfixes/updates) ..." +# @VARIABLE: EPATCH_FORCE +# @DESCRIPTION: +# Only require patches to match EPATCH_SUFFIX rather than the extended +# arch naming style. +EPATCH_FORCE="no" +# @VARIABLE: EPATCH_USER_EXCLUDE +# @DEFAULT_UNSET +# @DESCRIPTION: +# List of patches not to apply. Note this is only file names, +# and not the full path. Globs accepted. + +# @FUNCTION: epatch +# @USAGE: [options] [patches] [dirs of patches] +# @DESCRIPTION: +# epatch is designed to greatly simplify the application of patches. It can +# process patch files directly, or directories of patches. The patches may be +# compressed (bzip/gzip/etc...) or plain text. You generally need not specify +# the -p option as epatch will automatically attempt -p0 to -p4 until things +# apply successfully. +# +# If you do not specify any patches/dirs, then epatch will default to the +# directory specified by EPATCH_SOURCE. +# +# Any options specified that start with a dash will be passed down to patch +# for this specific invocation. As soon as an arg w/out a dash is found, then +# arg processing stops. +# +# When processing directories, epatch will apply all patches that match: +# @CODE +# if ${EPATCH_FORCE} != "yes" +# ??_${ARCH}_foo.${EPATCH_SUFFIX} +# else +# *.${EPATCH_SUFFIX} +# @CODE +# The leading ?? are typically numbers used to force consistent patch ordering. +# The arch field is used to apply patches only for the host architecture with +# the special value of "all" means apply for everyone. Note that using values +# other than "all" is highly discouraged -- you should apply patches all the +# time and let architecture details be detected at configure/compile time. +# +# If EPATCH_SUFFIX is empty, then no period before it is implied when searching +# for patches to apply. +# +# Refer to the other EPATCH_xxx variables for more customization of behavior. +epatch() { + _epatch_draw_line() { + # create a line of same length as input string + [[ -z $1 ]] && set "$(printf "%65s" '')" + echo "${1//?/=}" + } + + unset P4CONFIG P4PORT P4USER # keep perforce at ba
[gentoo-dev] [PATCH v2] estack.eclass: Split estack* logic from eutils
Split the estack_* and related functions from eutils into a dedicated estack.eclass. Those functions have significant complexity and are not used frequently, therefore they benefit from having a separate file and an explicit dedicated maintainer. The new eclass is implicitly inherited by eutils to preserve compatibility. However, the inherit will be removed in EAPI 7, and the ebuilds should switch to using estack directly. Thanks to Ulrich Müller for doing the research on this. --- eclass/estack.eclass | 217 +++ eclass/eutils.eclass | 210 ++--- 2 files changed, 224 insertions(+), 203 deletions(-) create mode 100644 eclass/estack.eclass diff --git a/eclass/estack.eclass b/eclass/estack.eclass new file mode 100644 index ..19c388f3d8d2 --- /dev/null +++ b/eclass/estack.eclass @@ -0,0 +1,217 @@ +# Copyright 1999-2017 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +# @ECLASS: estack.eclass +# @MAINTAINER: +# base-sys...@gentoo.org +# @BLURB: stack-like value storage support +# @DESCRIPTION: +# Support for storing values on stack-like variables. + +if [[ -z ${_ESTACK_ECLASS} ]]; then + +# @FUNCTION: estack_push +# @USAGE: [items to push] +# @DESCRIPTION: +# Push any number of items onto the specified stack. Pick a name that +# is a valid variable (i.e. stick to alphanumerics), and push as many +# items as you like onto the stack at once. +# +# The following code snippet will echo 5, then 4, then 3, then ... +# @CODE +# estack_push mystack 1 2 3 4 5 +# while estack_pop mystack i ; do +# echo "${i}" +# done +# @CODE +estack_push() { + [[ $# -eq 0 ]] && die "estack_push: incorrect # of arguments" + local stack_name="_ESTACK_$1_" ; shift + eval ${stack_name}+=\( \"\$@\" \) +} + +# @FUNCTION: estack_pop +# @USAGE: [variable] +# @DESCRIPTION: +# Pop a single item off the specified stack. If a variable is specified, +# the popped item is stored there. If no more items are available, return +# 1, else return 0. See estack_push for more info. +estack_pop() { + [[ $# -eq 0 || $# -gt 2 ]] && die "estack_pop: incorrect # of arguments" + + # We use the fugly _estack_xxx var names to avoid collision with + # passing back the return value. If we used "local i" and the + # caller ran `estack_pop ... i`, we'd end up setting the local + # copy of "i" rather than the caller's copy. The _estack_xxx + # garbage is preferable to using $1/$2 everywhere as that is a + # bit harder to read. + local _estack_name="_ESTACK_$1_" ; shift + local _estack_retvar=$1 ; shift + eval local _estack_i=\${#${_estack_name}\[@\]} + # Don't warn -- let the caller interpret this as a failure + # or as normal behavior (akin to `shift`) + [[ $(( --_estack_i )) -eq -1 ]] && return 1 + + if [[ -n ${_estack_retvar} ]] ; then + eval ${_estack_retvar}=\"\${${_estack_name}\[${_estack_i}\]}\" + fi + eval unset \"${_estack_name}\[${_estack_i}\]\" +} + +# @FUNCTION: evar_push +# @USAGE: [more vars to save] +# @DESCRIPTION: +# This let's you temporarily modify a variable and then restore it (including +# set vs unset semantics). Arrays are not supported at this time. +# +# This is meant for variables where using `local` does not work (such as +# exported variables, or only temporarily changing things in a func). +# +# For example: +# @CODE +# evar_push LC_ALL +# export LC_ALL=C +# ... do some stuff that needs LC_ALL=C set ... +# evar_pop +# +# # You can also save/restore more than one var at a time +# evar_push BUTTERFLY IN THE SKY +# ... do stuff with the vars ... +# evar_pop # This restores just one var, SKY +# ... do more stuff ... +# evar_pop 3 # This pops the remaining 3 vars +# @CODE +evar_push() { + local var val + for var ; do + [[ ${!var+set} == "set" ]] \ + && val=${!var} \ + || val="unset_76fc3c462065bb4ca959f939e6793f94" + estack_push evar "${var}" "${val}" + done +} + +# @FUNCTION: evar_push_set +# @USAGE: [new value to store] +# @DESCRIPTION: +# This is a handy shortcut to save and temporarily set a variable. If a value +# is not specified, the var will be unset. +evar_push_set() { + local var=$1 + evar_push ${var} + case $# in + 1) unset ${var} ;; + 2) printf -v "${var}" '%s' "$2" ;; + *) die "${FUNCNAME}: incorrect # of args: $*" ;; + esac +} + +# @FUNCTION: evar_pop +# @USAGE: [number of vars to restore] +# @DESCRIPTION: +# Restore the variables to the state saved with the corresponding +# evar_push call. See that function for more details.
Re: [gentoo-dev] [PATCH] estack.eclass: Split estack* logic from eutils
> On Sat, 11 Mar 2017, Michał Górny wrote: > Split the estack_* and related functions from eutils into a > dedicated estack.eclass. Those functions have significant complexity > and are not used frequently, therefore they benefit from having a > separate file and an explicit dedicated maintainer. This (and the other new eclass as well) might benefit from protection against inheriting it multiple times: if [[ -z ${_ESTACK_ECLASS} ]]; then _ESTACK_ECLASS=1 # main eclass code here fi pgpH1YJ1N99P6.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils
W dniu 11.03.2017, sob o godzinie 09∶04 -0500, użytkownik Michael Orlitzky napisał: > On 03/11/2017 08:51 AM, Michał Górny wrote: > > > > However, the inherit will be removed in EAPI 7 > > > > ... > > > > -inherit estack multilib toolchain-funcs > > +inherit epatch estack multilib toolchain-funcs > > > > Would it hurt to do that now, so that we don't forget when EAPI 7 comes? > For EAPI=0 to 6, inherit them all; otherwise, inherit the old set of > eclasses (without estack or epatch). Sure, I think we can do that. However, I'd also like to check whether multilib is currently used at all as that is also a candidate for removal. So maybe I'll do that in a single followup commit? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils
On 03/11/2017 08:51 AM, Michał Górny wrote: > > However, the inherit will be removed in EAPI 7 > > ... > > -inherit estack multilib toolchain-funcs > +inherit epatch estack multilib toolchain-funcs > Would it hurt to do that now, so that we don't forget when EAPI 7 comes? For EAPI=0 to 6, inherit them all; otherwise, inherit the old set of eclasses (without estack or epatch).
[gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils
Move epatch and epatch_user (along with the descriptions for all their variables) into a dedicated epatch.eclass. This function is very complex, therefore it benefits from separate eclass and a dedicated maintainer. Furthermore, it is mostly obsoleted by eapply* in EAPI 6. The new eclass is implicitly inherited by eutils to preserve compatibility. However, the inherit will be removed in EAPI 7, and the ebuilds should switch to inheriting epatch directly or using eapply*. - [Review note: this is 1:1 code move, no changes between the code] -- eclass/epatch.eclass | 453 +++ eclass/eutils.eclass | 440 + 2 files changed, 454 insertions(+), 439 deletions(-) create mode 100644 eclass/epatch.eclass diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass new file mode 100644 index ..9727dae6bee7 --- /dev/null +++ b/eclass/epatch.eclass @@ -0,0 +1,453 @@ +# Copyright 1999-2017 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +# @ECLASS: epatch.eclass +# @MAINTAINER: +# base-sys...@gentoo.org +# @BLURB: easy patch application functions +# @DESCRIPTION: +# An eclass providing epatch and epatch_user functions to easily apply +# patches to ebuilds. Mostly superseded by eapply* in EAPI 6. + +# @VARIABLE: EPATCH_SOURCE +# @DESCRIPTION: +# Default directory to search for patches. +EPATCH_SOURCE="${WORKDIR}/patch" +# @VARIABLE: EPATCH_SUFFIX +# @DESCRIPTION: +# Default extension for patches (do not prefix the period yourself). +EPATCH_SUFFIX="patch.bz2" +# @VARIABLE: EPATCH_OPTS +# @DESCRIPTION: +# Options to pass to patch. Meant for ebuild/package-specific tweaking +# such as forcing the patch level (-p#) or fuzz (-F#) factor. Note that +# for single patch tweaking, you can also pass flags directly to epatch. +EPATCH_OPTS="" +# @VARIABLE: EPATCH_COMMON_OPTS +# @DESCRIPTION: +# Common options to pass to `patch`. You probably should never need to +# change these. If you do, please discuss it with base-system first to +# be sure. +# @CODE +# -g0 - keep RCS, ClearCase, Perforce and SCCS happy #24571 +# --no-backup-if-mismatch - do not leave .orig files behind +# -E - automatically remove empty files +# @CODE +EPATCH_COMMON_OPTS="-g0 -E --no-backup-if-mismatch" +# @VARIABLE: EPATCH_EXCLUDE +# @DESCRIPTION: +# List of patches not to apply. Note this is only file names, +# and not the full path. Globs accepted. +EPATCH_EXCLUDE="" +# @VARIABLE: EPATCH_SINGLE_MSG +# @DESCRIPTION: +# Change the printed message for a single patch. +EPATCH_SINGLE_MSG="" +# @VARIABLE: EPATCH_MULTI_MSG +# @DESCRIPTION: +# Change the printed message for multiple patches. +EPATCH_MULTI_MSG="Applying various patches (bugfixes/updates) ..." +# @VARIABLE: EPATCH_FORCE +# @DESCRIPTION: +# Only require patches to match EPATCH_SUFFIX rather than the extended +# arch naming style. +EPATCH_FORCE="no" +# @VARIABLE: EPATCH_USER_EXCLUDE +# @DEFAULT_UNSET +# @DESCRIPTION: +# List of patches not to apply. Note this is only file names, +# and not the full path. Globs accepted. + +# @FUNCTION: epatch +# @USAGE: [options] [patches] [dirs of patches] +# @DESCRIPTION: +# epatch is designed to greatly simplify the application of patches. It can +# process patch files directly, or directories of patches. The patches may be +# compressed (bzip/gzip/etc...) or plain text. You generally need not specify +# the -p option as epatch will automatically attempt -p0 to -p4 until things +# apply successfully. +# +# If you do not specify any patches/dirs, then epatch will default to the +# directory specified by EPATCH_SOURCE. +# +# Any options specified that start with a dash will be passed down to patch +# for this specific invocation. As soon as an arg w/out a dash is found, then +# arg processing stops. +# +# When processing directories, epatch will apply all patches that match: +# @CODE +# if ${EPATCH_FORCE} != "yes" +# ??_${ARCH}_foo.${EPATCH_SUFFIX} +# else +# *.${EPATCH_SUFFIX} +# @CODE +# The leading ?? are typically numbers used to force consistent patch ordering. +# The arch field is used to apply patches only for the host architecture with +# the special value of "all" means apply for everyone. Note that using values +# other than "all" is highly discouraged -- you should apply patches all the +# time and let architecture details be detected at configure/compile time. +# +# If EPATCH_SUFFIX is empty, then no period before it is implied when searching +# for patches to apply. +# +# Refer to the other EPATCH_xxx variables for more customization of behavior. +epatch() { + _epatch_draw_line() { + # create a line of same length as input string + [[ -z $1 ]] && set "$(printf "%65s" '')" + echo "${1//?/=}" + } + + unset P4CONFIG P4PORT P4USER # keep perforce at bay #56402 + + # First proc
[gentoo-dev] [PATCH] estack.eclass: Split estack* logic from eutils
Split the estack_* and related functions from eutils into a dedicated estack.eclass. Those functions have significant complexity and are not used frequently, therefore they benefit from having a separate file and an explicit dedicated maintainer. The new eclass is implicitly inherited by eutils to preserve compatibility. However, the inherit will be removed in EAPI 7, and the ebuilds should switch to using estack directly. [Review note: this is 1:1 code move, no changes between the code] --- eclass/estack.eclass | 212 +++ eclass/eutils.eclass | 205 + 2 files changed, 213 insertions(+), 204 deletions(-) create mode 100644 eclass/estack.eclass diff --git a/eclass/estack.eclass b/eclass/estack.eclass new file mode 100644 index ..f07f8e5882dc --- /dev/null +++ b/eclass/estack.eclass @@ -0,0 +1,212 @@ +# Copyright 1999-2017 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +# @ECLASS: estack.eclass +# @MAINTAINER: +# base-sys...@gentoo.org +# @BLURB: stack-like value storage support +# @DESCRIPTION: +# Support for storing values on stack-like variables. + +# @FUNCTION: estack_push +# @USAGE: [items to push] +# @DESCRIPTION: +# Push any number of items onto the specified stack. Pick a name that +# is a valid variable (i.e. stick to alphanumerics), and push as many +# items as you like onto the stack at once. +# +# The following code snippet will echo 5, then 4, then 3, then ... +# @CODE +# estack_push mystack 1 2 3 4 5 +# while estack_pop mystack i ; do +# echo "${i}" +# done +# @CODE +estack_push() { + [[ $# -eq 0 ]] && die "estack_push: incorrect # of arguments" + local stack_name="_ESTACK_$1_" ; shift + eval ${stack_name}+=\( \"\$@\" \) +} + +# @FUNCTION: estack_pop +# @USAGE: [variable] +# @DESCRIPTION: +# Pop a single item off the specified stack. If a variable is specified, +# the popped item is stored there. If no more items are available, return +# 1, else return 0. See estack_push for more info. +estack_pop() { + [[ $# -eq 0 || $# -gt 2 ]] && die "estack_pop: incorrect # of arguments" + + # We use the fugly _estack_xxx var names to avoid collision with + # passing back the return value. If we used "local i" and the + # caller ran `estack_pop ... i`, we'd end up setting the local + # copy of "i" rather than the caller's copy. The _estack_xxx + # garbage is preferable to using $1/$2 everywhere as that is a + # bit harder to read. + local _estack_name="_ESTACK_$1_" ; shift + local _estack_retvar=$1 ; shift + eval local _estack_i=\${#${_estack_name}\[@\]} + # Don't warn -- let the caller interpret this as a failure + # or as normal behavior (akin to `shift`) + [[ $(( --_estack_i )) -eq -1 ]] && return 1 + + if [[ -n ${_estack_retvar} ]] ; then + eval ${_estack_retvar}=\"\${${_estack_name}\[${_estack_i}\]}\" + fi + eval unset \"${_estack_name}\[${_estack_i}\]\" +} + +# @FUNCTION: evar_push +# @USAGE: [more vars to save] +# @DESCRIPTION: +# This let's you temporarily modify a variable and then restore it (including +# set vs unset semantics). Arrays are not supported at this time. +# +# This is meant for variables where using `local` does not work (such as +# exported variables, or only temporarily changing things in a func). +# +# For example: +# @CODE +# evar_push LC_ALL +# export LC_ALL=C +# ... do some stuff that needs LC_ALL=C set ... +# evar_pop +# +# # You can also save/restore more than one var at a time +# evar_push BUTTERFLY IN THE SKY +# ... do stuff with the vars ... +# evar_pop # This restores just one var, SKY +# ... do more stuff ... +# evar_pop 3 # This pops the remaining 3 vars +# @CODE +evar_push() { + local var val + for var ; do + [[ ${!var+set} == "set" ]] \ + && val=${!var} \ + || val="unset_76fc3c462065bb4ca959f939e6793f94" + estack_push evar "${var}" "${val}" + done +} + +# @FUNCTION: evar_push_set +# @USAGE: [new value to store] +# @DESCRIPTION: +# This is a handy shortcut to save and temporarily set a variable. If a value +# is not specified, the var will be unset. +evar_push_set() { + local var=$1 + evar_push ${var} + case $# in + 1) unset ${var} ;; + 2) printf -v "${var}" '%s' "$2" ;; + *) die "${FUNCNAME}: incorrect # of args: $*" ;; + esac +} + +# @FUNCTION: evar_pop +# @USAGE: [number of vars to restore] +# @DESCRIPTION: +# Restore the variables to the state saved with the corresponding +# evar_push call. See that function for more details. +evar_pop() { + local
[gentoo-dev] [PATCH] eutils.eclass: Deprecate validate_desktop_entries
The validate_desktop_entries function is redundant to the built-in .desktop file checks done by Portage directly. It is used in total by two packages for both of which bugs have been filed. --- eclass/eutils.eclass | 3 +++ 1 file changed, 3 insertions(+) diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass index e398aafc464a..d91245495caa 100644 --- a/eclass/eutils.eclass +++ b/eclass/eutils.eclass @@ -883,6 +883,9 @@ _eutils_eprefix_init() { # @DESCRIPTION: # Validate desktop entries using desktop-file-utils validate_desktop_entries() { + eqawarn "validate_desktop_entries is deprecated and should be not be used." + eqawarn ".desktop file validation is done implicitly by Portage now." + _eutils_eprefix_init if [[ -x "${EPREFIX}"/usr/bin/desktop-file-validate ]] ; then einfo "Checking desktop entry validity" -- 2.12.0