Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types
> On Sat, 06 Dec 2014, Zac Medico wrote: > The PMS people should be *very* interested in any changes to unpack > behavior like this. It supports behavior that will lead to failures for > older versions of portage and other package managers. Some remarks: - The upstream deb2targz program supports only data.tar.gz. Only the Gentoo version has been patched up to support other file types. - There is only a single package in the tree with a dependency on app-arch/deb2targz, and this only on AIX [1]. So on most users' systems deb2targz will not be installed, and "ar x" will be used for unpacking. - Paludis and Pkgcore unconditionally use "ar x" for unpacking. - PMS says [2]: deb packages (*.deb). Ebuilds must ensure that the deb2targz program is installed on those platforms where the GNU binutils ar program is not available and the installed ar program is incompatible with GNU archives. Otherwise, ebuilds must ensure that GNU binutils is installed. One could conclude that GNU binutils ar should be used on platforms where it is available. deb2targz should be used only where ar is incompatible with the GNU version. So in any case, this is a problem of Portage only. I'd suggest to change the logic in unpack() as follows: if ; then ar x ... elif ; then deb2targz ... else ar x ... fi And then the deb2targz case could be patched as proposed. After all, it is only a fallback that should be compatible with "ar x" extraction. Ulrich [1] http://qa-reports.gentoo.org/output/genrdeps/dindex/app-arch/deb2targz [2] http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-14100011.3.3.13 pgph26utPMmUN.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types
> On Sun, 07 Dec 2014, Zac Medico wrote: > Anyway, Brian's patch for xz support with debt2targz appears to be > compatible with other package managers as well as AIX, so that seems > like a good way to go. I still think that ar should always be used on platforms where GNU binutils is installed. Currently unpack uses deb2targz when it finds the program, which is not a well defined behaviour. Ulrich pgppXonqP1VjG.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types
> On Sun, 07 Dec 2014, Zac Medico wrote: > Okay, I guess we can default to ar if [[ $(ar --version 2>&1) == "GNU > ar"* ]] and otherwise fall back to deb2targz. It's sort of trivial, but here is a patch: >From c53e7057f94728d6e0c7d16c675702ca831b9a5a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulrich=20M=C3=BCller?= Date: Sun, 7 Dec 2014 19:33:52 +0100 Subject: [PATCH] Prefer GNU ar when unpacking .deb packages. PMS reference: deb packages (*.deb). Ebuilds must ensure that the deb2targz program is installed on those platforms where the GNU binutils ar program is not available and the installed ar program is incompatible with GNU archives. Otherwise, ebuilds must ensure that GNU binutils is installed. --- bin/phase-helpers.sh | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh index 6e437da..afad2e9 100644 --- a/bin/phase-helpers.sh +++ b/bin/phase-helpers.sh @@ -448,11 +448,13 @@ unpack() { "with EAPI '${EAPI}'. Instead use 'deb'." fi # Unpacking .deb archives can not always be done with - # `ar`. For instance on AIX this doesn't work out. If - # we have `deb2targz` installed, prefer it over `ar` for - # that reason. We just make sure on AIX `deb2targz` is + # `ar`. For instance on AIX this doesn't work out. + # If `ar` is not the GNU binutils version and we have + # `deb2targz` installed, prefer it over `ar` for that + # reason. We just make sure on AIX `deb2targz` is # installed. - if type -P deb2targz > /dev/null; then + if [[ $(ar --version 2>/dev/null) != "GNU ar"* ]] && \ + type -P deb2targz > /dev/null; then y=${x##*/} local created_symlink=0 if [ ! "$srcdir$x" -ef "$y" ] ; then -- 2.2.0
Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types
>>>>> On Sun, 07 Dec 2014, Zac Medico wrote: > On 12/07/2014 10:37 AM, Ulrich Mueller wrote: >> It's sort of trivial, but here is a patch: >> >> From c53e7057f94728d6e0c7d16c675702ca831b9a5a Mon Sep 17 00:00:00 2001 >> From: Ulrich Müller >> Date: Sun, 7 Dec 2014 19:33:52 +0100 >> Subject: [PATCH] Prefer GNU ar when unpacking .deb packages. >> >> [...] > LGTM. So shall I push it? > In a separate patch we can also include Brian's deb2targz xz > handling for AIX, I guess. +1 Ulrich pgpBWrrK3N45J.pgp Description: PGP signature
Re: [gentoo-alt] Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types
> On Sun, 07 Dec 2014, Zac Medico wrote: > On 12/07/2014 11:23 AM, Fabian Groffen wrote: >> FYI: >> >> % portageq envvar CHOST >> x86_64-apple-darwin13 >> % ar --version >> ar: illegal option -- - >> usage: ar -d [-TLsv] archive file ... >> [...] > It's hard to whitelist it if doesn't support --version, so it seems > reasonable to require deb2targz whenever ar is not GNU ar. unpack will still use ar if deb2targz is not installed. So on Darwin, behaviour should be the same as before. Ulrich pgpPQEfcOLwSJ.pgp Description: PGP signature
Re: [gentoo-alt] Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types
> On Sun, 07 Dec 2014, Zac Medico wrote: > On 12/07/2014 07:06 PM, Christoph Junghans wrote: >> I know, I am late to the party, I just wanted to say that in >> unpacker.eclass I implemented a variant which uses neither deb2tags >> nor ar on prefix, but just bash's read and head. The code uses "head -c" which is a GNU extension: $ man 1p head HEAD(1P)POSIX Programmer's ManualHEAD(1P) [...] SYNOPSIS head [−n number] [file...] [...] For example, on OpenBSD and HPUX there is no -c option, or it is used differently. Also Busybox doesn't have it. Are we better off by requiring GNU head instead of GNU ar? > Very nice. We should borrow that code and use it to eliminate the > need for deb2targz in portage. In PMS, this would have to go into EAPI 6, I suppose? Ulrich pgpfesq0ME4CD.pgp Description: PGP signature
[gentoo-portage-dev] Re: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command
> On Thu, 29 Jan 2015, Zac Medico wrote: >> -print("Use " + colorize("GOOD", "eselect news") + " to read >> news items.") >> +print("Use " + colorize("GOOD", "eselect news read new") + " to >> read new items.") > I guess that's fine, but I have to wonder how many people are really > that lazy. To me, it actually seems like more effort to highlight the > span of characters with the mouse than it does to type them out. > Also, when the work "read" appears twice on a short line like that, it > gives a wordy/redundant feeling. Also "new" is the default for eselect's read action, therefore "eselect news read" would be enough. Ulrich pgpjeToyup0vH.pgp Description: PGP signature
Re: [gentoo-portage-dev] *eselect move trouble
Unfortunately, it is not possible to do a package move in an atomic way with CVS, so there was some time window where both old app-admin/eselect-* and new app-eselect/eselect-* packages were in the tree simultaneously. It should be all set now, so please resync and try again. Ulrich pgpIpI5bmRZf5.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] match_from_list: restrict =* to match only on version part boundaries (bug 560466)
> On Sun, 20 Sep 2015, Zac Medico wrote: > Make the =* glob match only on boundaries between version parts, in > order to eliminate ambiguity (so that 1* does not match version 10). > Only break compatibility in cases where dependencies have been > specified ambiguously. Does this patch consider suffix parts (including the integer if present) as a single component? That is, the following should match: =cat/foo-1_alpha* cat/foo-1_alpha_beta But these should *not*: =cat/foo-1_p* cat/foo-1_pre =cat/foo-1_alpha* cat/foo-1_alpha1 (The boundary of the version components is after _alpha and _alpha1, respectively.) Ulrich pgpTvvF7vWhW5.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] match_from_list: restrict =* to match only on version part boundaries (bug 560466)
> On Mon, 21 Sep 2015, Zac Medico wrote: >> Does this patch consider suffix parts (including the integer if >> present) as a single component? > No, it considers the integer parts as a separate components, in > order to maintain as much backward compatibility as possible. > So, it deviates from your test cases only because =cat/foo-1_alpha* > matches cat/foo-1_alpha1. Note that this case is not ambiguous like > the others, so we may not want to break compatibility here. In fact, PMS sections 3.2 and 3.3 don't define if a suffix is one or two components. I believe that we could clarify the wording in either way, both would be consistent. Function get_version_components() from versionator.eclass treats suffixes as single components, though. But maybe we can ignore this. Ulrich pgpsi9VEFI3pD.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels
> On Tue, 10 Nov 2015, Mike Frysinger wrote: > + # Set the compat level in case things change with newer ones. We must > not > + # export this into the env otherwise we might break other shell > scripts we > + # execute (e.g. ones in /usr/bin). > + BASH_COMPAT="${maj}.${min}" > + > + # The variable above is new to bash-4.3. For older versions, we have > to use > + # a compat knob. Further, the compat knob only exists with older > versions > + # (e.g. bash-4.3 has compat42 but not compat43). This means we only > need to > + # turn the knob with older EAPIs, and only when running newer bash > versions: > + # there is no bash-3.3 (it went 3.2 to 4.0), and when requiring > bash-4.2, the > + # var works with bash-4.3+, and you don't need to set compat to 4.2 > when you > + # are already running 4.2. > + if __eapi_bash_3_2 && [[ ${BASH_VERSINFO[0]} -gt 3 ]] ; then > + shopt -s compat32 > + fi Wouldn't this profit from an additional test for pgpvQqazU9WY6.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels
> On Wed, 11 Nov 2015, Michał Górny wrote: > I'm not convinced we ought to do this for EAPI < 6. It is a breaking > change after all, and as such changes the behavior of EAPI < 6 > ebuilds. Which according to PMS should assume bash version 3.2. Also, AFAICS the only feature where the compat settings could have any impact is this setting from compat42: If set, bash does not process the replacement string in the pattern substitution word expansion using quote removal. All other compat changes affect either only POSIX mode, or interactive mode, or string comparison (where the compat32 setting disables locale specific behaviour and uses strcmp instead, so effectively the compat setting should be saner). > There are some ebuilds/eclasses that have bash version checks, > and execute bash-4 code when bash-4 is available. As far as I > understand, this will effectively prohibit bash-4 code even though > BASH_VERSINFO will still indicate bash-4 is being used. The compat settings don't disable any new features. They only restore previous behaviour where there was an incompatible change. Ulrich pgpUvQguzzIMa.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels
> On Thu, 12 Nov 2015, Zac Medico wrote: > On 11/12/2015 04:06 PM, Mike Frysinger wrote: >> from ebuilds/eclasses that have already stopped using __: >> __do_sed_fix () >> ___ECLASS_RECUR_MULTILIB=yes >> ___ECLASS_RECUR_TOOLCHAIN_FUNCS=yes >> __versionator_shopt_toggle () >> __versionator__test_version_compare () >> __versionator__test_version_is_at_least () >> >> grepping the tree, i see like two packages and one eclass still using __. >> both of which are trivial to convert. > Sure, but do we really want to confuse people who might be ignorant of > this rule? Having functions disappear from the environment without > warning is very likely to cause confusion... Maybe repoman should make people aware of this rule then? Ulrich pgpzQwU1HBa1r.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels
> On Fri, 13 Nov 2015, Michał Górny wrote: > Ok, I recalled the issue I was particularly concerned about. > PV="1_beta2" > MY_PV="${PV/_/~}" > This triggers different behavior between bash<=4.2 and bash>=4.3, > with the latter requiring: > PV="1_beta2" > MY_PV="${PV/_/\~}" > (which in turns breaks older). Now, if someone put a conditional on > BASH_VERSINFO that worked around this discrepancy, introducing > BASH_COMPAT suddenly breaks it by forcing the old behavior when > BASH_VERSINFO indicates the new behavior is expected. > Not saying this is very likely to happen. Highly unlikely, IMHO. There are several workarounds that are simpler than making the code conditional on the bash version. For example: tilde="~"; MY_PV="${PV/_/${tilde}}" or: MY_PV="${PV/_/$'\x7e'}" > However, we are clearly violating the idea behind PMS by allowing it > to happen retroactively. Not sure. PMS is (and always was) quite clear about which bash version belongs to which EAPI, so ebuilds have no business of circumventing this by doing their own version checks. > However, enabling BASH_COMPAT in EAPI 6 is a good thing. For > example, because people in EAPI 6 no longer need to be concerned > about this discrepancy. Enabling it for EAPI 6 only will lead to the paradoxical situation that bash will be compatible to 4.2 in EAPI 6, as it should be. Whereas earlier EAPIs (which should use 3.2 really) will get the behaviour of bash 4.3 or later instead. Ulrich pgpXfica1utMs.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 1/2] Warn if LC_CTYPE does not transform ASCII chars like POSIX
> On Sat, 14 Nov 2015, Michał Górny wrote: > Output a warning if LC_CTYPE is set to a value that causes libc > toupper() and/or tolower() conversions not apply correctly to > printable ASCII characters. The wording of the spec is "The package manager must ensure [...]", therefore I think a warning is not enough here. Maybe add a fallback to en_US.UTF-8, then to POSIX? Ulrich pgpyUmCseVJxI.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] EAPI 6: Fail if eapply_user is not called in src_prepare()
> On Tue, 17 Nov 2015, Michał Górny wrote: > __ebuild_phase src_prepare > + > + # keep path in eapply_user in sync! > + if [[ ! -f ${T}/.portage_user_patches_applied ]]; then > + die "eapply_user (or default) must be called in src_prepare()!" > + fi > + What happens if an ebuild calls eapply_user in src_unpack but not in src_prepare? Ulrich pgp82vwaobi1U.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] EAPI 6: Fail if eapply_user is not called in src_prepare()
> On Tue, 17 Nov 2015, Zac Medico wrote: >> What happens if an ebuild calls eapply_user in src_unpack but not >> in src_prepare? > It will succeed in that case. It should die if it isn't called in src_prepare. > If necessary, we can make eapply_user die if it's called during the > wrong phase. That's not really mandated by the spec, but I think such extra strictness would be a good idea. Ulrich pgprOjJy0HKZs.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Print WORKDIR & D sizes in build logs
> On Sun, 27 Dec 2015, Michał Górny wrote: > --- > bin/phase-functions.sh | 9 + > 1 file changed, 9 insertions(+) > diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh > index 0b853bf..6a47fed 100644 > --- a/bin/phase-functions.sh > +++ b/bin/phase-functions.sh > @@ -593,6 +593,15 @@ __dyn_install() { > __vecho > __ebuild_phase post_src_install > + # record build & installed size in build log > + if type -P du &>/dev/null; then > + local sz=( $(du -ks "${WORKDIR}") ) > + einfo "Final size of build directory: ${sz[0]} KiB" > + sz=( $(du -ks "${D}") ) > + einfo "Final size of installed tree: ${sz[0]} KiB" > + __vecho > + fi > + > cd "${PORTAGE_BUILDDIR}"/build-info > set -f > local f x > -- > 2.6.4 Will this be called before or after prepcompress? Ulrich pgpcKy53y1gSh.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH] __eapi6_src_prepare: handle empty PATCHES array (bug 579626)
> On Wed, 20 Apr 2016, Zac Medico wrote: > Only call eapply with a non-empty PATCHES array, as specified by PMS. > X-Gentoo-bug: 579626 > X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=579626 > --- > bin/phase-helpers.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh > index 1a9ee7b..5af2784 100644 > --- a/bin/phase-helpers.sh > +++ b/bin/phase-helpers.sh > @@ -806,7 +806,7 @@ __eapi4_src_install() { > > __eapi6_src_prepare() { > if [[ $(declare -p PATCHES 2>/dev/null) == "declare -a"* ]]; then > - eapply "${PATCHES[@]}" > + [[ -n ${PATCHES[@]} ]] && eapply "${PATCHES[@]}" > elif [[ -n ${PATCHES} ]]; then > eapply ${PATCHES} > fi > -- > 2.7.4 Looks good to me. The spec explicitly checks for this condition too. Ulrich pgpfItbOWcxwN.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] news: Support News-Item-Format 2.0
> On Sat, 3 Sep 2016, Zac Medico wrote: > If we wanted to be more strict about the input that we accept, we > could limit the profile wildcard match to so that it only works if > the format is 2.* and only supports a terminal /* since that's all > that the spec says is supported. Please do. GLEP 42 says: "In news item format 2.0, a terminal asterisk immediately following a slash acts as a wildcard for any further path components, for example default/linux/*." Ulrich pgpmyroVujnKk.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH] repoman: Check for empty files in filesdir.
This checks for files with zero size in filesdir. The QA script at https://qa-reports.gentoo.org/output/find-binary-files.txt reports a couple of them which at least in part are blunders. Should be harmless enough not to need a discussion about policy in gentoo-dev. Patch included below. Ulrich From 871b92a32cf947d266d829dfe3e3095ba62c49b0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulrich=20M=C3=BCller?= Date: Sun, 12 Feb 2017 17:21:51 +0100 Subject: [PATCH] repoman: Check for empty files in filesdir. --- repoman/man/repoman.1 | 5 - repoman/pym/repoman/modules/scan/fetch/fetches.py | 3 +++ repoman/pym/repoman/qa_data.py| 3 +++ 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/repoman/man/repoman.1 b/repoman/man/repoman.1 index 3b3aec27e..9b106906f 100644 --- a/repoman/man/repoman.1 +++ b/repoman/man/repoman.1 @@ -1,4 +1,4 @@ -.TH "REPOMAN" "1" "Dec 2016" "Repoman VERSION" "Repoman" +.TH "REPOMAN" "1" "Feb 2017" "Repoman VERSION" "Repoman" .SH NAME repoman \- Gentoo's program to enforce a minimal level of quality assurance in packages added to the portage tree @@ -328,6 +328,9 @@ error or digest verification failure. .B file.UTF8 File is not UTF8 compliant .TP +.B file.empty +Empty file in the files directory +.TP .B file.executable Ebuilds, digests, metadata.xml, Manifest, and ChangeLog do not need the executable bit diff --git a/repoman/pym/repoman/modules/scan/fetch/fetches.py b/repoman/pym/repoman/modules/scan/fetch/fetches.py index 9ee3c652a..241cfaa7b 100644 --- a/repoman/pym/repoman/modules/scan/fetch/fetches.py +++ b/repoman/pym/repoman/modules/scan/fetch/fetches.py @@ -130,6 +130,9 @@ class FetchChecks(ScanBase): self.qatracker.add_error( "file.size", "(%d KiB) %s/files/%s" % ( mystat.st_size // 1024, xpkg, y)) + elif mystat.st_size == 0: + self.qatracker.add_error( + "file.empty", "%s/files/%s" % (xpkg, y)) index = self.repo_settings.repo_config.find_invalid_path_char(y) if index != -1: diff --git a/repoman/pym/repoman/qa_data.py b/repoman/pym/repoman/qa_data.py index 29a95abf6..0dc32789f 100644 --- a/repoman/pym/repoman/qa_data.py +++ b/repoman/pym/repoman/qa_data.py @@ -67,6 +67,8 @@ qahelp = { "Files in the files directory must be under 20 KiB"), "file.size.fatal": ( "Files in the files directory must be under 60 KiB"), + "file.empty": ( + "Empty file in the files directory"), "file.name": ( "File/dir name must be composed" " of only the following chars: %s " % allowed_filename_chars), @@ -262,6 +264,7 @@ qawarnings = set(( "ebuild.minorsyn", "ebuild.badheader", "ebuild.patches", + "file.empty", "file.size", "inherit.unused", "inherit.deprecated", -- 2.11.1 pgprqcddFggjd.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] portage.package.ebuild: Use a fake FILESDIR to catch invalid accesses
> On Thu, 16 Mar 2017, Michał Górny wrote: > + mysettings["FILESDIR"] = os.path.join(settings["PORTAGE_BUILDDIR"], > "files") I believe that this contradicts current PMS 11.1, which defines FILESDIR as follows: "The full path to the package's files directory, used for small support files or patches. See section 4.3." So maybe you should first propose a clarification of the PMS wording? Ulrich pgpmZkYwR2dxH.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] phase-helpers.sh: Loop over A rather than SRC_URI in __eapi0_pkg_nofetch.
> On Thu, 23 Mar 2017, Zac Medico wrote: > On Thu, Mar 23, 2017 at 2:55 AM, Ulrich Müller wrote: >> Looping over SRC_URI also outputs non-filename elements (e.g, use >> conditionals) which is avoided when looping over A. >> >> Gentoo-Bug: 613132 >> --- >> bin/phase-helpers.sh | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) > Looks good. Presumably we should wait for the ack (or rather the usual consensus timeout) of the corresponding PMS patch: https://archives.gentoo.org/gentoo-pms/message/6044537cd2cd36bc23307918a9afced9 Ulrich pgp1eMEcTz3O8.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] phase-helpers.sh: Loop over A rather than SRC_URI in __eapi0_pkg_nofetch.
>>>>> On Thu, 23 Mar 2017, Ulrich Mueller wrote: >>>>> On Thu, 23 Mar 2017, Zac Medico wrote: >> On Thu, Mar 23, 2017 at 2:55 AM, Ulrich Müller wrote: >>> Looping over SRC_URI also outputs non-filename elements (e.g, use >>> conditionals) which is avoided when looping over A. >>> >>> Gentoo-Bug: 613132 >>> --- >>> bin/phase-helpers.sh | 8 >>> 1 file changed, 4 insertions(+), 4 deletions(-) >> Looks good. > Presumably we should wait for the ack (or rather the usual consensus > timeout) of the corresponding PMS patch: > https://archives.gentoo.org/gentoo-pms/message/6044537cd2cd36bc23307918a9afced9 Pushed. pgpy3h8Z_85CP.pgp Description: PGP signature
Re: [gentoo-portage-dev] [RFC] eslurp helper
> On Sun, 26 Mar 2017, Michał Górny wrote: > I'm thinking of creating a new helper in Portage. The draft name is > eslurp. It would be used like: > eslurp [--dist|--binpkg] ... +1 The name will need some bikeshedding, though. :) I suggest "edrop" or "einsert". > i.e. it would have two modes: > 1. --dist would place all listed files in DISTDIR (respecting any > possible future DISTDIR split), > 2. --binpkg would place all listed packages in PKGDIR (respecting > subdirectories, updating index). > If neither of the options were specified, it would guess the > directory type by the filename suffix. I wonder how that could possibly work. Distfiles have no specific suffix, and binpkgs have a .tbz2 suffix which however can occur for distfiles too. Ulrich pgpxAExMXnxXE.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX
> On Wed, 19 Apr 2017, Michał Górny wrote: > Add an additional conditional to the dosym Prefix hack to ensure that > the symlink is not using double Prefix when the ebuild uses ${EPREFIX} > explicitly. This ensures that Portage on Prefix systems is both > compatible with the ebuilds relying on the hack, and using dosym > in the PMS-defined manner. > destdir=${2%/*} > [[ ! -d ${ED}${destdir} ]] && dodir "${destdir}" > -# when absolute, prefix with offset for Gentoo Prefix > target="${1}" > -[[ ${target:0:1} == "/" ]] && target="${EPREFIX}${target}" > +# DEPRECATED HACK: when absolute, prefix with offset for Gentoo Prefix > +# (but only if ${EPREFIX} is not there already) Maybe add a date (like 2018-04-30) to the comment after which the code can be removed? > +if [[ ${target:0:1} == "/" && ${target} != "${EPREFIX}"* ]]; then I think you want an additional slash in the second condition, in order to prevent /foo/barbaz from matching if EPREFIX is equal to /foo/bar: if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then > + target="${EPREFIX}${target}" > +fi > ln -snf "${target}" "${ED}${2}" > > ret=$? Ulrich pgpkQoluwZQnU.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX
>>>>> On Wed, 19 Apr 2017, Ulrich Mueller wrote: >> +if [[ ${target:0:1} == "/" && ${target} != "${EPREFIX}"* ]]; then > I think you want an additional slash in the second condition, in order > to prevent /foo/barbaz from matching if EPREFIX is equal to /foo/bar: > if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then >> +target="${EPREFIX}${target}" One more point, maybe output a QA warning here? >> +fi >> ln -snf "${target}" "${ED}${2}" >> >> ret=$? Ulrich pgpnbu32eKtEv.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX
>>>>> On Wed, 19 Apr 2017, Michał Górny wrote: > On śro, 2017-04-19 at 18:21 +0200, Ulrich Mueller wrote: >> One more point, maybe output a QA warning here? > Not convinced about that. Two points: > 1. It will warn only people actually running Prefix. Sure, so having it won't harm on non-prefix systems. > 2. It will also trigger for paths that aren't supposed to be > prefixed. If it does, then something is going wrong, because a path will be prefixed that isn't supposed to. Ulrich pgpE5T2ilSXCQ.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Explicitly ban get_libdir in global scope
> On Wed, 30 Aug 2017, Zac Medico wrote: > It's possible that there are working ebuilds that call get_libdir in > global scope. How could that be possible when get_libdir() is defined in phase-helpers.sh? > Have we done an analysis of the ebuilds in the gentoo repository? > Obviously, it would be safer to call eqawarn. Ulrich pgpY_GOdKdi2j.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Completely ban external commands in global scope
> On Fri, 8 Sep 2017, Robin H Johnson wrote: > On Thu, Aug 31, 2017 at 10:45:42PM +0200, Michał Górny wrote: >> +export PATH=/dev/null > Minor nitpick: The Single UNIX spec says that PATH is a set of > prefixes, and that they're treated as directories. > http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html > I think it might be good to use either a non-existing path, or a > known empty directory (/var/empty), rather than /dev/null which DOES > exist. Is /var/empty standard? On my system here, it belongs to net-misc/openssh. Also any /dev/null/foo is guaranteed not to exist, so I don't see how pathname resolution could possibly succeed when PATH is /dev/null. Ulrich pgpVY9QRev455.pgp Description: PGP signature
Re: [gentoo-portage-dev] [gentoolkit] eshowkw: Improve & reorder keywords for my Bugzie proposal
> On Tue, 23 Jan 2018, Michał Górny wrote: > Here's a short set of patches that reworks eshowkw keyword display > & ordering to match my Bugzilla proposal [1]. Also, it fixes the wrong > classification of *-fbsd as Prefix arch. > Example output: > - https://dev.gentoo.org/~mgorny/tmp/short.png (without -P) > - https://dev.gentoo.org/~mgorny/tmp/long.png (with -P) Two points: 1. For prefix, can you use the same ordering as in KEYWORDS? That is, sort by the part after the hyphen first (i.e. aix, cygwin, ..., winnt), then by the part before it. 2. sparc-fbsd is grouped with prefix. Is that intentional? Ulrich pgpOPUifhTrOS.pgp Description: PGP signature
Re: [gentoo-portage-dev] Re: [PATCH v2 3/3] _emerge.Ebuild*: delay creating DISTDIR shadow until src_unpack
> On Thu, 25 Jan 2018, Zac Medico wrote: > It seems to be a common assumption that it's allowed, this command > currently shows 163 results in the gentoo repo: > git grep -l pkg_nofetch | xargs grep 'e\(log\|info\).*DISTDIR' | wc -l There will be little breakage if it is only used in elog messages. > We should double check with the PMS maintainers to see if they think > it's worthy of an exception. Otherwise, we need to announce the > issue on the gentoo-dev mailing list. PMS had never defined DISTDIR in pkg_* phases. You can see this e.g. in the PMS version from 2010 [1]. In addition to this, the following clarification of variables' scope was approved by the council in 2017 [2]: | 6. Scope and consistency of FILESDIR and DISTDIR | | Old: src_* (not consistent across ebuild phases) | New: src_*, global scope (consistent). No access to the dir in | global scope. | | Rationale: These variables must be defined in global scope for | assignment of the PATCHES variable in EAPI 6. However, the actual | directories are not necessarily present in global scope (e.g., when | installing from a binary package) and therefore must not be accessed | there. Ulrich [1] https://projects.gentoo.org/pms/3/pms.html#x1-117002 [2] https://bugs.gentoo.org/616206 pgpudLoADGanK.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] repoman: Add commit message verification
> On Fri, 2 Feb 2018, Michał Górny wrote: > Add a check for common mistakes in commit messages. For now, it is > pretty rough and exits immediately but it should be integrated with > the editor in the future. Have you tested this against existing commits in the gentoo repo? Ulrich pgp9WrL5Q8VBT.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] repoman: Add commit message verification
>>>>> On Sun, 04 Feb 2018, Michał Górny wrote: > W dniu sob, 03.02.2018 o godzinie 09∶58 +0100, użytkownik Ulrich Mueller > napisał: >> > Add a check for common mistakes in commit messages. For now, it >> > is pretty rough and exits immediately but it should be integrated >> > with the editor in the future. >> >> Have you tested this against existing commits in the gentoo repo? > After checking the 1 most recent commits, I have the following > stats on invalid commit messages: > [...] > Most of the violations are uses of Gentoo-Bug and very long > single-line commit messages; most likely people using '-m "very long > message because I am lazy and can't use editor properly"'. > Full list of violations in the sample: > https://gist.github.com/mgorny/fa81ffe07ca9565198e4e44fb040bb19 IMHO this shows that some of the tests are too rigid. Especially, "body lines should be wrapped at 72 characters" often triggers in cases where rewrapping wouldn't improve readability. Since GLEP 66 says that "the body *should* be wrapped at 72 characters" (my emphasis), I would suggest to relax this test a bit and only flag body lines longer than 80 characters. Also, any lines containing long URIs should be excluded from the test. Ulrich pgpfHhBhi2Jyg.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default
> On Sat, 3 Mar 2018, Michał Górny wrote: > parser.add_argument( > '-d', '--include-dev-profiles', choices=('y', 'n'), > metavar='', > - default='n', > + default='y', > help='include dev profiles in dependency checks') It seems counter-intuitive for a simple binary option to require an argument. What is wrong with specifying -d to enable the option, and simply not specifying it to disable? Ulrich pgpXXL5a128zO.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default
> On Sat, 03 Mar 2018, Michał Górny wrote: >> It seems counter-intuitive for a simple binary option to require an >> argument. What is wrong with specifying -d to enable the option, >> and simply not specifying it to disable? > What is wrong is that a number of developers have historically not > specified the option and broke stuff. Plus, it's infinitely silly to > require people to explicitly specify the option to enable required > behavior. My remark was about syntax, not about semantics. "-d y" and "-d n" instead of "-d" and "(nothing)" is a crappy user interface. Maybe unify things into "--include-profiles=" (with a comma separated list of "stable", "dev", and "exp") or "--include-profile-level=" with n=0 for stable, n=1 for stable+dev, etc.? Ulrich pgpRefoLzQiiY.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default
> On Sat, 03 Mar 2018, Michał Górny wrote: > I don't really want to go into this. As far as I'm concerned, I can > leave defunct '-d' and just check dev profiles unconditionally. WFM. Or even better, leave defunct -d/--include-dev in place (in order not to break peoples' scripts) and add a long --no-include-dev option. Ulrich pgppFpmvLee_2.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] repoman: Warn on = dependencies without * or revision
> On Sat, 3 Mar 2018, Michał Górny wrote: > Warn if the '=' package dependency operator is used along with pure > version with no revision specified. This means to catch a common mistake > of developers copying '=' from upstream dependency specification while > '~' operator would be more appropriate. This causes unintended depgraph > breakage when the dependencies are revbumped e.g. due to dependency > changes, or prevents people from upgrading. > The developers are given two suggestions: either to use '~' if any > revision is acceptable, or to explicitly specify '-r0' when they really > do accept -r0 only. I won't be opposed against this, but there doesn't seem to be any policy that would require explicit -r0 in dependency specifications. So this is a policy change which should be discussed in gentoo-dev before it can be added to repoman. Also according to PMS, no revision and -r0 (and even -r00) are completely equivalent. so IMHO we should think twice before introducing behaviour that would treat them differently in some places. Ulrich pgpkTWCqrICrD.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH eapi6-pt2 v2 2/6] nonfatal: Implement fallback executable for EAPI 7
> On Fri, 9 Mar 2018, Michał Górny wrote: > +if ! ___eapi_has_nonfatal_as_executable; then > + die "${0##*/} not supported as fallback helper in this EAPI" > +fi Nothing wrong with this, but this test isn't strictly necessary. PMS says in [1]: "Except where otherwise noted, they may be internal (shell functions or aliases) or external commands available in PATH; where this is not specified, ebuilds may not rely upon either behaviour." So in EAPIs 0 to 6, Portage is free to implement it as shell function, or external command, or both. Ulrich [1] https://projects.gentoo.org/pms/6/pms.html#x1-13100011.3.3 pgpQj9Jrmn1pd.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH eapi6-pt2 v2 3/6] Add sandbox directory removal functions for EAPI 7
> On Fri, 9 Mar 2018, Michał Górny wrote: > @@ -154,6 +165,12 @@ addread(){ __sb_append_var READ"$@" ; } > addwrite() { __sb_append_var WRITE "$@" ; } > adddeny(){ __sb_append_var DENY"$@" ; } > addpredict() { __sb_append_var PREDICT "$@" ; } > +if ___eapi_has_sandbox_rm_functions; then > + rmread() { __sb_remove_var READ"$@" ; } > + rmwrite(){ __sb_remove_var WRITE "$@" ; } > + rmdeny() { __sb_remove_var DENY"$@" ; } > + rmpredict() { __sb_remove_var PREDICT "$@" ; } > +fi See my message to gentoo-pms [1], where I suggest to omit this feature from EAPI 7. We should rather rethink if this is the best possible interface. Ulrich [1] https://archives.gentoo.org/gentoo-pms/message/cf4bd0266f09245c02470e4fa3810947 pgpnhbMUIm3Z5.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
> On Sun, 29 Jul 2018, Michael Orlitzky wrote: > System executables that are not owned by root pose a security > risk. The owner of the executable is free to modify it at any time; > so, for example, he can change a daemon's behavior to make it > malicious before the next time the service is started (usually by > root). > On a "normal" system, there is no good reason why the superuser should > not own every system executable. This commit adds a new install-time > check that reports any such binaries with a QA warning. To avoid false > positives, non-"normal" systems (like prefix) are skipped at the moment. Shouldn't this check for setuid binaries like /usr/bin/mandb (which is owned by man:man)? I think these are legitimate usage case. Ulrich pgptqtrJo8E1U.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
> On Sun, 29 Jul 2018, Michael Orlitzky wrote: > After thinking about this for a while, I think we should ignore setgid > but not setuid executables. The problem with setuid and a non-root owner > is that the owner can always exploit the situation: > Suppose /bin/foo is owned by "foo" and setuid. If root (or any other > privileged user) is about to run /bin/foo, then the "foo" user can > simply strip away the setuid bit and fill /bin/foo with malicious code. Staying with the man:man example, how would anybody become the "man" user, in the first place? That user has /bin/false as a shell and no valid password. > The same situation with setgid is safe because (as far as I know) > members of the group can't strip off the setgid bit. Setgid executables shouldn't be group writable, so I believe that part of the test is fine as-is in v1 of your patch. Ulrich pgppMBCz_RDB1.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 2/2] Update /usr/portage references (bug 378603)
> On Sun, 5 Aug 2018, Zac Medico wrote: > --- a/cnf/make.conf.example > +++ b/cnf/make.conf.example > [...] > @@ -119,16 +119,16 @@ > # fetched on demand for a given build. If you would like to > # selectively prune obsolete files from this directory, see > # eclean from the gentoolkit package. Note that locations under > -# /usr/portage are not necessarily safe for data storage. See the > +# /var/db/repos/gentoo are not necessarily safe for data storage. See the > # PORTDIR documentation for more information. > -#DISTDIR=/usr/portage/distfiles > +#DISTDIR=/var/db/repos/gentoo/distfiles Shouldn't this be /var/cache/distfiles ... > # > # PKGDIR is the location of binary packages that you can have created > # with '--buildpkg' or '-b' while emerging a package. This can get > # up to several hundred megs, or even a few gigs. Note that > -# locations under /usr/portage are not necessarily safe for data > +# locations under /var/db/repos/gentoo are not necessarily safe for data > # storage. See the PORTDIR documentation for more information. > -#PKGDIR=/usr/portage/packages > +#PKGDIR=/var/db/repos/gentoo/packages ... and /var/cache/binpkgs? > --- a/lib/portage/cache/flat_hash.py > +++ b/lib/portage/cache/flat_hash.py > @@ -144,7 +144,7 @@ class database(fs_template.FsBased): > # Only recurse 1 deep, in order to > avoid iteration over > # entries from another nested cache > instance. This can > # happen if the user nests an overlay > inside > - # /usr/portage/local as in bug #302764. > + # /var/db/repos/gentoo/local as in bug > #302764. Shouldn't a local overlay be in /var/db/repos/local, but never inside of the gentoo repo? > --- a/man/make.conf.5 > +++ b/man/make.conf.5 > @@ -219,10 +219,10 @@ Use the \fBPORTAGE_RO_DISTDIRS\fR variable to specify > one or > more read-only directories containing distfiles. > > Note > -that locations under /usr/portage are not necessarily safe for data storage. > +that locations under /var/db/repos/gentoo are not necessarily safe for data > storage. IMHO this statement should be made much stronger. > See the \fBPORTDIR\fR documentation for more information. > .br > -Defaults to /usr/portage/distfiles. > +Defaults to /var/db/repos/gentoo/distfiles. /var/cache/distfiles > @@ -800,10 +800,10 @@ to it's category. However, for backward compatibility > with the layout > used by older versions of portage, if the \fI${PKGDIR}/All\fR directory > exists then all packages will be stored inside of it and symlinks to > the packages will be created in the category subdirectories. Note > -that locations under /usr/portage are not necessarily safe for data storage. > +that locations under /var/db/repos/gentoo are not necessarily safe for data > storage. See above. > See the \fBPORTDIR\fR documentation for more information. > .br > -Defaults to /usr/portage/packages. > +Defaults to /var/db/repos/gentoo/packages. /var/cache/binpkgs > --- a/man/quickpkg.1 > +++ b/man/quickpkg.1 > @@ -17,7 +17,7 @@ modified since they were first installed. > .br > The packages, after being created, will be placed in \fBPKGDIR\fR. > This variable is defined in \fBmake.conf\fR(5) and defaults to > -/usr/portage/packages. > +/var/db/repos/gentoo/packages. See above.
Re: [gentoo-portage-dev] [PATCH 2/2] Update /usr/portage references (bug 378603)
> On Mon, 6 Aug 2018, Brian Dolbec wrote: > But that too can be changed along with all the user install > documentation which will need to be updated as well. The new > recomended location should be /var/db/repos/local. I will be updating > layman for /var/db/repos/... as well. That is the intention of the > "repos/" subdir. What is the exact plan for layman? IIUC, only the storage dir should be changed to /var/db/repos, but the rest (cache, installed, make_conf) would stay under /var/lib/layman? > All these changes as well as the catlayst changes need to be > co-ordinated so that snapshots and portage and stages don't precede > the docs changes. +1 Ulrich
Re: [gentoo-portage-dev] [PATCH] install-qa-check.d/60pngfix: parallel support (bug 630292)
> On Thu, 09 Aug 2018, Michał Górny wrote: >> +if xargs --help | grep -q -- --max-procs=; then > '--help' is not a valid argument on FreeBSD, so this spews errors > to stderr: IIRC, GNU findutils is required by PMS? Ulrich
Re: [gentoo-portage-dev] [PATCH] install-qa-checks.d: Add a check for Gentoo path policies (FHS-y)
> On Tue, 04 Sep 2018, Michał Górny wrote: > + # toplevel directories which can be installed to by ebuilds > + # /home is not included as no ebuilds should install files there > + local allowed_paths_toplevel=( > + "${allowed_common_dirs[@]}" > + boot dev etc opt srv usr var > + # TODO: do we need it? gconf installs empty dir there but that's > + # all > + root > + ) Does any package actually install files in /srv? (GLEP 20 suggested that, but it wasn't accepted.) > + # directories in /usr which can be installed to by ebuilds > + local allowed_paths_usr=( > + "${allowed_common_dirs[@]}" > + include libexec share src > + # toolchain stuff > + "${CHOST}" "${CTARGET}" > + ) Maybe add a comment that you've deliberately omitted games? Ulrich signature.asc Description: PGP signature
[gentoo-portage-dev] Re: [RFC] gpkg format proposal v2
> On Mon, 12 Nov 2018, Michał Górny wrote: > On Mon, 2018-11-12 at 17:51 +0100, Fabian Groffen wrote: >> I'm wondering here, how much sense does it make to compress 2., 3. >> and/or 4. if you compress the whole gpkg? I have the impression >> compression on compression isn't beneficial here. Shouldn't just >> compressing of the gpkg tar be sufficient? > Please read the spec again. It explicitly says it's not compressed. Isn't that the wrong way around? The tar format contains a lot of padding, so using uncompressed tar for the outer archive would be somewhat wasteful. Why not leave the inner tar files uncompressed, but compress the whole binpkg instead? Also, what would be wrong with ar? It's a standard POSIX tool, and should be available everywhere. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: [RFC] gpkg format proposal v2
> On Mon, 12 Nov 2018, Michał Górny wrote: >> Also, what would be wrong with ar? It's a standard POSIX tool, and >> should be available everywhere. > The original post says what's wrong with ar. Please be more specific > if you disagree with it. AFAICS, the arguments are that ar would be obscure, and that the LSB considers it deprecated. I don't find either of them convincing. Since when do we care about the LSB? Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: [RFC] gpkg format proposal v2
> On Mon, 12 Nov 2018, Michał Górny wrote: > Once tar is used for inner archive format, it is also a natural choice > for the outer format. If you believe we should use another format, that > is introduce a second distinct archive format and depend on a second > tool, you need to have a good justification for it. Right, that's a better reason. :) > So yes, ar is an option, as well as cpio. In both cases the format is > simpler (yet obscure), and the files are smaller. But does that justify > using a second tool that serves the same purpose as tar, given that tar > works and we need to use it anyway? Even if we skip the fact that ar is > bundled as part of binutils rather than as stand-alone archiver, we're > introducing unnecessarily complexity of learning a second tool. > And both ar(1) and cpio(1) have weird CLI, compared to tar(1). cpio is not feasible because of file size limitations (4 GiB IIRC). Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] ecompress-file: Support decompressing .lz
> On Sat, 17 Nov 2018, Michał Górny wrote: > Signed-off-by: Michał Górny > --- > bin/ecompress-file | 3 +++ > 1 file changed, 3 insertions(+) > diff --git a/bin/ecompress-file b/bin/ecompress-file > index bc8fe5451..ccc2701c3 100755 > --- a/bin/ecompress-file > +++ b/bin/ecompress-file > @@ -29,6 +29,9 @@ compress_file() { > *.lzma|*.xz) > unxz -f "${x}" || __helpers_die "unxz failed" > x=${x%.*};; > + *.lz) > + lzip -df "${x}" || __helpers_die "lzip -d > failed" > + x=${x%.lz};; > esac > filtered_args+=( "$x" ) > -- > 2.19.1 Does that mean that portage will gain a dependency on lzip now? Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] collision_protect: use dynamic report interval
> On Tue, 08 Jan 2019, Fabian Groffen wrote: > Output before this patch: > * checking 6111 files for package collisions > [...] > After: > * checking 6158 files for package collisions > [...] Why does the total number of files change? Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 2/2 v3] Update /usr/portage references (bug 378603)
> On Thu, 18 Apr 2019, Zac Medico wrote: > --- a/man/ebuild.5 > +++ b/man/ebuild.5 > [...] > @@ -553,8 +554,8 @@ usage. > .B LICENSE > This should be a space delimited list of licenses that the package falls > under. This \fB_must_\fR be set to a matching license in > -/usr/portage/licenses/. If the license does not exist in portage yet, you > -must add it first. > +/var/db/repos/gentoo/licenses/. If the license does not exist in portage > +yet, you must add it first. s/in portage/in the repository/ > --- a/man/portage.5 > +++ b/man/portage.5 > @@ -13,7 +13,7 @@ https://wiki.gentoo.org/wiki/Profile_(Portage) > .IP Note: > If you are looking for information on how to emerge something, please see > .BR emerge (1). > -.SH "SYNOPSIS" > +.SH "SYNOPSIS"/var/db/repos/gentoo This change looks strange. > [...] > @@ -251,7 +251,7 @@ explaining how they can upgrade. > default-linux/x86/2005.0 > # emerge -n '>=sys-apps/portage-2.0.51' > # rm -f /etc/portage/make.profile > -# ln -s /usr/portage/profiles/default-linux/alpha/2005.0 \ > +# ln -s /var/db/repos/gentoo/profiles/default-linux/alpha/2005.0 \ > /etc/portage/make.profile Update the example? Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] repos.conf: default sync-webrsync-verify-signature
> On Tue, 09 Jul 2019, Zac Medico wrote: > --- a/man/make.conf.5 > +++ b/man/make.conf.5 > @@ -1,4 +1,4 @@ > -.TH "MAKE.CONF" "5" "Jun 2019" "Portage VERSION" "Portage" > +.TH "MAKE.CONF" "5" "Ju. 2019" "Portage VERSION" "Portage" Typo. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] repoman: add 'user.eclass' to deprecated eclasses
> On Tue, 23 Jul 2019, Michał Górny wrote: > Make repoman report user.eclass as deprecated by GLEP 81. I don't understand. user.eclass is inherited by both acct-user.eclass and acct-group.eclass, therefore in active use. Or are you planning to inline its code in the inheriting eclasses? Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Support PROPERTIES="live".
> On Fri, 26 Jul 2019, Zac Medico wrote: > Looks good. Please merge. Will do, as soon as the live eclasses set PROPERTIES="live". Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Support PROPERTIES="live".
> On Mon, 29 Jul 2019, Michał Górny wrote: > On Sun, 2019-07-28 at 17:21 -0700, Zac Medico wrote: >> There could be another subset of packages that aren't quite "live" but >> they need to fetch something that's immutable which can't be fetched via >> a protocol supported by SRC_URI. Maybe call it >> PROPERTIES="src-fetch-immutable" or something. > Could you name one of those packages, and explain how are they not > 'live' if they skip checksum verification? I'm really against adding > hundreds of weird-named items for the sake of potential use cases > without a real benefit to it. +1 signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Support PROPERTIES="live".
> On Sat, 27 Jul 2019, Michał Górny wrote: > While at it, could you look into making src_unpack() network-sandbox > override apply only to ebuilds with PROPERTIES=live? I believe the patch included below would do that. Ulrich From f4ebd25a04d5eb64504724b711b41141723afcd4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulrich=20M=C3=BCller?= Date: Mon, 29 Jul 2019 14:22:57 +0200 Subject: [PATCH] doebuild.py: Override network-sandbox only for live ebuilds. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Suggested-by: Michał Górny Signed-off-by: Ulrich Müller --- lib/portage/package/ebuild/doebuild.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/portage/package/ebuild/doebuild.py b/lib/portage/package/ebuild/doebuild.py index 67867d33e..cab838ead 100644 --- a/lib/portage/package/ebuild/doebuild.py +++ b/lib/portage/package/ebuild/doebuild.py @@ -156,7 +156,8 @@ def _doebuild_spawn(phase, settings, actionmap=None, **kwargs): phase in _ipc_phases kwargs['mountns'] = 'mount-sandbox' in settings.features kwargs['networked'] = 'network-sandbox' not in settings.features or \ - phase in _networked_phases or \ + (phase in _networked_phases and \ + 'live' in settings.configdict['pkg'].get('PROPERTIES', '').split()) or \ 'network-sandbox' in settings['PORTAGE_RESTRICT'].split() kwargs['pidns'] = ('pid-sandbox' in settings.features and phase not in _global_pid_phases) -- 2.22.0 signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH v2] doebuild.py: Override network-sandbox in unpack only for live ebuilds (was: Re: [PATCH] Support PROPERTIES="live")
> On Mon, 29 Jul 2019, Zac Medico wrote: > This will enable network-sandbox for all of _networked_phases, but > Michał only suggested to do it for src_unpack. Right. Patch v2 below. From 6e929fac0a3f5f0bcfe85152c0931cb20d579881 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulrich=20M=C3=BCller?= Date: Mon, 29 Jul 2019 14:22:57 +0200 Subject: [PATCH] doebuild.py: Override network-sandbox in unpack only for live ebuilds. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Suggested-by: Michał Górny Signed-off-by: Ulrich Müller --- lib/portage/package/ebuild/doebuild.py | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/lib/portage/package/ebuild/doebuild.py b/lib/portage/package/ebuild/doebuild.py index 67867d33e..6f980f87d 100644 --- a/lib/portage/package/ebuild/doebuild.py +++ b/lib/portage/package/ebuild/doebuild.py @@ -115,13 +115,6 @@ _ipc_phases = frozenset([ _global_pid_phases = frozenset([ 'config', 'depend', 'preinst', 'prerm', 'postinst', 'postrm']) -# phases in which networking access is allowed -_networked_phases = frozenset([ - # for VCS fetching - "unpack", - # + for network-bound IPC -] + list(_ipc_phases)) - _phase_func_map = { "config": "pkg_config", "setup": "pkg_setup", @@ -156,7 +149,9 @@ def _doebuild_spawn(phase, settings, actionmap=None, **kwargs): phase in _ipc_phases kwargs['mountns'] = 'mount-sandbox' in settings.features kwargs['networked'] = 'network-sandbox' not in settings.features or \ - phase in _networked_phases or \ + (phase == 'unpack' and \ + 'live' in settings.configdict['pkg'].get('PROPERTIES', '').split()) or \ + phase in _ipc_phases or \ 'network-sandbox' in settings['PORTAGE_RESTRICT'].split() kwargs['pidns'] = ('pid-sandbox' in settings.features and phase not in _global_pid_phases) -- 2.22.0 signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] make.globals: Change FETCHCOMMAND_RSYNC to --copy-links
> On Mon, 21 Oct 2019, Michał Górny wrote: > This also removes most of the other options that are irrelevant or even > undesirable to distfile fetching, that is: > - '-r' since we always fetch a single file, so recursive operation is > unnecessary > - '-p', '-o', '-g' since we want to apply our permissions and ownership > for distfiles rather than copying the one from mirrors, > - '-D' since we do not expect any devices or specials in distfiles. That certainly makes sense, but I don't see it in the actual patch? signature.asc Description: PGP signature
Re: [gentoo-portage-dev] SLOT move of sys-libs/ncurses-5.9-r5(0/5) to sys-libs/ncurses-compat-5.9-r5(5/5) ?
> On Thu, 14 Nov 2019, Joakim Tjernlund wrote: > And pkg move will move all pkgs within sys-libs/ncurses ? Yes, "move" only accepts (qualified) package names without versions. > Or could portage move only sys-libs/ncurses-5.9-r5 to > sys-libs/ncurses-compat-5.9-r5 ? No. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
> On Wed, 27 Nov 2019, Michael Orlitzky wrote: > This now disagrees with the PMS algorithm, doesn't it? The difference is that there is now a QA warning for something that is perfectly within the spec. Maybe the extra verboseness would be enough, but the eqawarn line should be omitted? It doesn't provide any info that isn't already present in the output of patch itself. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
> On Thu, 28 Nov 2019, Michał Górny wrote: >> The difference is that there is now a QA warning for something that >> is perfectly within the spec. Maybe the extra verboseness would be >> enough, but the eqawarn line should be omitted? It doesn't provide >> any info that isn't already present in the output of patch itself. > It helps people understand why some patches throw a wall of text while > others don't. WFM, but then omit the "please rebase" at least. (Also, with the filename added, the line tends to be very long. Maybe omit that leading whitespace to at least partially compensate?) Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
> On Thu, 12 Dec 2019, Mike Gilbert wrote: > I think this should be reverted. It causes too much noise, and > "solves" a problem only very rarely. Now, how many lines of output does this typically produce, compared to the total size of a typical build log? Especially with mgorny's subsequent modification, which suppresses the output unless the patch doesn't apply cleanly. It was also suggested that we add -F0 in EAPI 8, but that would break the build in those cases that are producing extra output now. I don't think that would be preferable. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
>>>>> On Thu, 12 Dec 2019, Mike Gilbert wrote: > On Wed, Nov 27, 2019 at 11:14 PM Michał Górny wrote: >> On Wed, 2019-11-27 at 23:49 +0100, Ulrich Mueller wrote: >> > The difference is that there is now a QA warning for something that >> > is perfectly within the spec. Maybe the extra verboseness would be >> > enough, but the eqawarn line should be omitted? It doesn't provide >> > any info that isn't already present in the output of patch itself. >> >> It helps people understand why some patches throw a wall of text >> while others don't. > It also triggers pointless bug reports. Please remove this. I don't like that eqawarn either (see above). OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES, so they won't see the warning? Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
> On Fri, 13 Dec 2019, Mike Gilbert wrote: >> > It also triggers pointless bug reports. Please remove this. >> >> I don't like that eqawarn either (see above). >> >> OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES, >> so they won't see the warning? > Here's a bug report filed by a user, which is what prompted me to > reply on this thread in the first place. > https://bugs.gentoo.org/702608 Well then, trivial patch included below. From 81000b32d330a1cc41a4541f7e4264918eb7e6c5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulrich=20M=C3=BCller?= Date: Fri, 13 Dec 2019 23:41:23 +0100 Subject: [PATCH] eapply: Drop QA warning for fuzz factor. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This didn't add any information beyond what is already present in the output of patch. Developers will know how to interpret its output, and users won't see the warning anyway with the standard configuration. Signed-off-by: Ulrich Müller --- bin/phase-helpers.sh | 2 -- 1 file changed, 2 deletions(-) diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh index b5691bd70..020862ba0 100644 --- a/bin/phase-helpers.sh +++ b/bin/phase-helpers.sh @@ -1004,8 +1004,6 @@ if ___eapi_has_eapply; then if ${patch_cmd} "${all_opts[@]}" --dry-run -s -F0 \ < "${f}" &>/dev/null; then all_opts+=( -s -F0 ) - else - eqawarn "${f}: patch failed to apply without a fuzz factor, please rebase" fi ${patch_cmd} "${all_opts[@]}" < "${f}" -- 2.24.0 signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
> On Sat, 14 Dec 2019, Michał Górny wrote: > Actually, I added that because of your comment that people should be > rebasing patches rather than removing context. Isn't rebasing easier than removing context, anyway? I'd trust the maintainer to do the right thing there. The main argument is that the warning is apparently seen by some users, who will then file unwanted bug reports. (Also, as I said before, we don't even have a policy that patches must apply without fuzz.) Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] dosym: revert deprecated prefix compat (bug 615594)
> On Sun, 19 Jan 2020, Zac Medico wrote: > --- a/bin/ebuild-helpers/dosym > +++ b/bin/ebuild-helpers/dosym > @@ -21,14 +21,6 @@ fi > destdir=${2%/*} > [[ ! -d ${ED%/}/${destdir#/} ]] && dodir "${destdir}" > target="${1}" > -# DEPRECATED HACK: when absolute, prefix with offset for Gentoo Prefix > -# (but only if ${EPREFIX} is not there already) > -# this will eventually be removed, #615594 > -if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then > - eqawarn "dosym: prepending EPREFIX to path implicitly. If this is > desired," > - eqawarn " please fix the ebuild to use \${EPREFIX} explicitly." > - target="${EPREFIX}${target}" > -fi > ln -snf "${target}" "${ED%/}/${2#/}" The intermediate "target" variable is no longer needed, you can simply say "$1" here. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] einstalldocs: Fix test for DOCS being unset.
> On Thu, 20 Feb 2020, Zac Medico wrote: > Looks good. Even though earlier EAPIs are deprecated, would there be a > problem with updating __eapi4_src_install for consistency? I'd rather not, because for EAPIs 4 and 5 PMS specifies that the return status of declare -p should be tested [1]. Presumably it wouldn't make much of a difference, because we don't account for the "assigned, but empty" case in these EAPIs. src_install format 4 will just fail for DOCS="" or DOCS=(). [1] https://projects.gentoo.org/pms/7/pms.html#x1-94001r7 signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Change BINPKG_COMPRESS default from bzip2 to xz
> On Sun, 26 Apr 2020, Michael Orlitzky wrote: > Fuel for the fire: > * https://www.nongnu.org/lzip/lzip_benchmark.html > * https://www.nongnu.org/lzip/xz_inadequate.html Yep. That's why lzip is the dominant compression format now, and nobody is using xz any more. SCNR, Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] config.environ: delay export of A and AA (bug 720180)
> On Tue, 26 May 2020, Zac Medico wrote: > On 5/26/20 12:48 AM, Michał Górny wrote: >> On Mon, 2020-05-25 at 21:31 -0700, Zac Medico wrote: >>> Since variables like A and AA can contain extremely large values which >>> may trigger E2BIG errors during attempts to execute subprocesses, delay >>> export until the last moment, and unexport when appropriate. >> >> Please don't. This will only hide the problem from developers who will >> unknowingly commit broken ebuilds and cause users of alternative package >> managers to suffer. > We've seen in https://bugs.gentoo.org/719202 that developers can already > do that with existing versions of portage, since the failure can be > dependent on USE configuration. We have seen in bug 719202 that A has exceeded _SC_ARG_MAX which is 128 KiB. However, your commit message mentions E2BIG which will trigger at a much larger value, namely 2 MiB. We are far away from reaching that limit in any ebuild. These are separate issues (although related), so I think we should make it very clear about which one we're talking. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Escape percent-signs in filename when fetching from mirrors
> On Sun, 31 May 2020, Zac Medico wrote: > In order to ensure that the filename will not have an extra level of quoting > in the mirror path, we'll have to do something like this wherever we > translate a uri in SRC_URI to a filename: > diff --git a/lib/portage/dbapi/porttree.py b/lib/portage/dbapi/porttree.py > index 08af17bcd..99d8ab720 100644 > --- a/lib/portage/dbapi/porttree.py > +++ b/lib/portage/dbapi/porttree.py > @@ -1547,7 +1547,7 @@ def _parse_uri_map(cpv, metadata, use=None): > myuris.pop() > distfile = myuris.pop() > else: > - distfile = os.path.basename(uri) > + distfile = unquote(os.path.basename(uri)) > if not distfile: > raise portage.exception.InvalidDependString( > ("getFetchMap(): '%s' SRC_URI has no > file " + \ I think that unescaping is correct, but you'll need a subsequent sanity check to make sure that the resulting filename doesn't contain any characters that aren't allowed in the Manifest. Namely, "excluding the backwards slash (\) and characters classified as control characters or as whitespace" (GLEP 74). Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Improve handling of percent-signs in SRC_URI
> On Sun, 31 May 2020, Zac Medico wrote: > We've also got these other basename calls in fetch.py: >> diff --git a/lib/portage/package/ebuild/fetch.py >> b/lib/portage/package/ebuild/fetch.py >> index 28e7caf53..56b375d58 100644 >> --- a/lib/portage/package/ebuild/fetch.py >> +++ b/lib/portage/package/ebuild/fetch.py >> @@ -730,9 +730,9 @@ def fetch(myuris, mysettings, listonly=0, fetchonly=0, >> else: >> for myuri in myuris: >> if urlparse(myuri).scheme: >> - >> file_uri_tuples.append((os.path.basename(myuri), myuri)) >> + >> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), myuri)) >> else: >> - >> file_uri_tuples.append((os.path.basename(myuri), None)) >> + >> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), None)) > The case with no scheme is not a URI, so we need to decide whether > or not to unquote, and we should make _parse_uri_map behavior > consistent for this case. I think that this follows from PMS, section 8.2 [1]: | The following elements are recognised in at least one class of | specification. All elements must be surrounded on both sides by | whitespace, except at the start and end of the string. | | [...] | - A URI, in the form proto://host/path. Permitted in SRC_URI and | HOMEPAGE. In EAPIs listed in table 8.4 as supporting SRC_URI arrows, | may optionally be followed by whitespace, then ->, then whitespace, | then a simple filename when in SRC_URI. For SRC_URI behaviour, see | section 8.2.10. | - A flat filename. Permitted in SRC_URI. So if it isn't an URI then it is a "flat filename" which IMHO is to be interpreted literally without any unquoting. Ulrich [1] https://projects.gentoo.org/pms/7/pms.html#x1-690008.2 signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Use env to find python
But we know that it is in /usr/bin, so why add yet another indirection? signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Use env to find python
> On Tue, 16 Jun 2020, Michał Górny wrote: > '/usr/bin/env python' (with no extra options) is the portable shebang. I still think this is a gross hack. You want your script to use the correct interpreter (which is in /usr/bin, or the path substituted for it at install time), not some random binary which happens to be found in the user's ${PATH}. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?
> On Wed, 17 Jun 2020, Michael Lienhardt wrote: > But maybe, "error" here in the PMS mean "the cpvs without the use flag > does not match that dependency and a warning should be raised to > improve compatibility in the future". In that case, it would be > clearer for me to change 'error' in the PMS into something like > "results in a no match, IMHO we cannot assume that. If the flag is not in the dependency's IUSE_EFFECTIVE then behaviour is undefined. > but should be avoided". That way, it is explicitly stated that missing > use flags for a 2-style USE dependency is accepted (which is the > current behavior of emerge) but frown upon, without forcing any > specific error handling, like Michał accurately pointed out. The real problem is that we don't have a good procedure for removing flags from ebuilds with reverse (2-style) use dependencies. (And even with 4-style use dependencies the problem remains that one cannot know in advance whether removal of the flag implies that the feature is now unconditionally enabled, or that it is disabled.) Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Add caching to use_reduce, vercmp, and catpkgsplit
> On Mon, 13 Jul 2020, Zac Medico wrote: > Merged: > https://gitweb.gentoo.org/proj/portage.git/commit/?id=d9ee5b09664ab2255b62c1d52d554721ef8b716a Looks like the author's copyright signoff is missing? signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Add caching to use_reduce, vercmp, and catpkgsplit
> On Mon, 13 Jul 2020, Chun-Yu Shei wrote: > Ah, I wasn't aware that I should have added that... I'm happy to say > "Signed-off-by: Chun-Yu Shei " somewhere if > necessary. Should be enough to say it here, because this mailing list is archived. We could of course add an empty commit with "Fixes" and "Signed-off-by", so we'd have the paper trail in the repo. > The patch has gone through Google's open source patching approval > process and I'm able to agree to any CLA required. We don't require a CLA. As long as you can signoff the copyright, things are fine. See https://www.gentoo.org/glep/glep-0076.html for all the details. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 2/3] Remove support code for Python < 3.3
> On Fri, 17 Jul 2020, Michał Górny wrote: > --- a/lib/portage/util/_dyn_libs/PreservedLibsRegistry.py > +++ b/lib/portage/util/_dyn_libs/PreservedLibsRegistry.py > @@ -34,12 +34,9 @@ class PreservedLibsRegistry(object): > > _json_write_opts = { > "ensure_ascii": False, > - "indent": "\t", > - "sort_keys": True > + "indent": 4, This is assigning 4 now unconditionally, while it was "\t" before for modern Python versions. Is this intentional? > + "sort_keys": True, Why the added comma? > } > - if sys.hexversion < 0x30200F0: > - # indent only supports int number of spaces > - _json_write_opts["indent"] = 4 > > def __init__(self, root, filename): > """ > --- a/lib/portage/util/mtimedb.py > +++ b/lib/portage/util/mtimedb.py > @@ -29,12 +29,9 @@ class MtimeDB(dict): > > _json_write_opts = { > "ensure_ascii": False, > - "indent": "\t", > + "indent": 4, Same here. > "sort_keys": True > } > - if sys.hexversion < 0x30200F0: > - # indent only supports int number of spaces > - _json_write_opts["indent"] = 4 > > def __init__(self, filename): > dict.__init__(self) Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 01/26] lib/portage/util/_desktop_entry.py: fix unused-import
> On Mon, 03 Aug 2020, Aaron Bauman wrote: > --- a/lib/portage/util/_desktop_entry.py > +++ b/lib/portage/util/_desktop_entry.py > @@ -1,16 +1,13 @@ > -# Copyright 2012-2013 Gentoo Foundation > +# Copyright 2020 Gentoo Authors Please don't drop existing years from the range. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] profile masking
> On Fri, 14 Aug 2020, Joakim Tjernlund wrote: > When pkgs are masked in the profile, it affects all variants of that > pkgs, even the ones that are in other overlays. > Example: > !!! The following installed packages are masked: > - sys-auth/sssd-::transmode (masked by: package.mask) > /usr/portage/profiles/package.mask: > # Matt Turner (2020-08-13) > # Masked for testing > My sssd- is now masked. > Could the profile syntax be extended to include syntax allowed in > /etc/portage ? Then one could use the ::gentoo syntax (or so I hope) The :: syntax is Portage specific and doesn't exist in EAPI 7. So there's no chance to get it into the profile dir anytime soon (because that would imply :: to be added to a future EAPI and the top-level profile dir to be bumped to that EAPI). You could override the mask in your overlay's profile/package.mask instead, using an entry with the "-" operator. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] profile masking
> On Fri, 14 Aug 2020, Zac Medico wrote: > On 8/14/20 8:42 AM, Joakim Tjernlund wrote: >> Yes, I know I can add that in profile/package.mask but I am looking >> for the bigger picture here. This has to stop somehow, there need to >> be something that limits the mask scope to the repo/overlay it is >> defined. > The scope is already limited, but this overlay inherits the mask because > it has the gentoo repo as its master (either implicitly or via a masters > setting in metadata/layout.conf). > I suppose we could add an option to prevent this inheritance. Like an option in repos.conf or layout.conf? The problem I see with this is that preventing inheritance would disable files like license_groups or thirdpartymirrors. So overlays would have to maintain their own versions. >> I think a good start would be to consider /etc/portage the top >> profile and other subprofiles should be able to use the same features >> as /etc/portage. >> >> Portage could start supporting that now, but there would be a while >> until one can use them in Gentoo profile. > We've got this bug open for the ::repo atom support: > https://bugs.gentoo.org/651208 I still believe that adding ::gentoo to every line in package.mask would be the wrong approach to the problem. Ulrich
Re: [gentoo-portage-dev] [PATCH v2] env-update: create systemd env configuration if required
> On Thu, 03 Sep 2020, Florian Schmaus wrote: > This commit changes env-update so that, after profile.env has was > generated, a systemd user session environment configuration file named > /usr/lib/environment.d/gentoo-profile-env.conf > is created, if the directory /usr/lib/environment.d exists. Maybe a stupid question, but can't this file just source /etc/profile? Maintaining the same information twice doesn't look like the right thing to do. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] env-update: create systemd env configuration if required
> On Thu, 03 Sep 2020, Florian Schmaus wrote: > It's not really maintaining the information twice. The information is > maintained at a single point: /etc/env.d > And from there is is transformed by env-update already into two > different formats: > - /etc/profile.env > - /etc/csh.env > And with that change additionally into > - /usr/lib/environment.d/gentoo-profile-env.conf Sorry for another nitpick, but it's changing a file in /usr at runtime? Also, does the file belong to any package, or is it an orphan? Maybe it would be cleaner to generate the file in /etc like the others, if necessary with a symlink in /usr/lib/environment.d? The symlink could belong to some package, maybe even sys-apps/systemd itself. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] In what phase are file "merged"?
> On Wed, 23 Jun 2021, Joakim Tjernlund wrote: > In PMS 9.2 is says: > The call order for upgrading, downgrading or reinstalling a package is: > pkg_pretend (only for EAPIs listed in table 9.2), which is called outside > of the normal call order process. > pkg_setup > src_unpack > src_prepare (only for EAPIs listed in table 9.3) > src_configure (only for EAPIs listed in table 9.4) > src_compile > src_test (except if RESTRICT=test) > src_install > pkg_preinst > pkg_prerm for the package being replaced > pkg_postrm for the package being replaced > pkg_postinst > It does not say where in this list new files merged and old files > unmerged, can anyone enlighten me? It's somewhat hidden, but it's there: https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10 9.1.10 pkg_preinst ... immediately before merging the package to the live filesystem. ... 9.1.11 pkg_postinst ... immediately after merging the package to the live filesystem. ... Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] In what phase are file "merged"?
>>>>> On Wed, 23 Jun 2021, Fabian Groffen wrote: > On 23-06-2021 08:47:58 +0200, Ulrich Mueller wrote: >> It's somewhat hidden, but it's there: >> https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10 >> >> 9.1.10 pkg_preinst >> ... immediately before merging the package to the live filesystem. ... >> >> 9.1.11 pkg_postinst >> ... immediately after merging the package to the live filesystem. ... > Aha, so does this mean pkg_prerm and pkg_postrm are run with replacing > package in place, e.g. if they refer to scripts installed by the > replaced package they may no longer exist or be the same? PMS has similar wording for pkg_prerm and pkg_postrm, so (at least according to the spec) the old package will still be present in pkg_prerm and will be gone in pkg_postrm. I don't think that the ebuild can rely on any particular status of the new package in pkg_*rm (of the old package), or the status of the old package in pkg_*inst (of the new package). Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] In what phase are file "merged"?
>>>>> On Fri, 06 Aug 2021, Joakim Tjernlund wrote: > On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote: >> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote: >> > I don't think that the ebuild can rely on any particular status of >> > the new package in pkg_*rm (of the old package), or the status of >> > the old package in pkg_*inst (of the new package). >> >> I would even say that it can't rely on the particular status of the >> old package in any case, if it's meant to be removed. In particular, >> its dependencies can be unmerged before the package itself. > Stubled ove this mail again and noticed "its dependencies can be > unmerged before the package itself" stmt. That does not make sense to > me. Deps should be unmerged after any pkg that depends on them? A popular workflow is "emerge -c -p" followed by "emerge -C" on entries of the list shown. IIUC emerge -C doesn't do any dependency resolution, therefore ebuilds cannot rely on any removal order. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 2/2] ebuild.sh: Update QA notice in inherit()
> On Sun, 29 Aug 2021, Michał Górny wrote: > On Sun, 2021-08-29 at 22:06 +0200, Ulrich Müller wrote: >> -eqawarn "For compatibility with <=portage-2.1.6.7, only >> call EXPORT_FUNCTIONS" >> -eqawarn "after inherit(s)." >> +eqawarn "For compatibility with PMS, only call >> EXPORT_FUNCTIONS after inherit(s)." > Could you add a sentence that the current Portage behavior is going to > change in the future? Sure, but do we actually know that? signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v3] Copy files/* into the work tree instead of symlinking it
> On Sun, 26 Sep 2021, Michał Górny wrote: > Symlinking FILESDIR into the work tree has the unintended consequence > of preserving all original file metadata, including system-specific ACLs > and so on. When these files are installed, this could lead to > unintentionally copying this metadata to the system and/or binary > packages. > Let's copy all files instead and drop metadata in the process. Since > FILESDIR is expected to be small by design, this shouldn't cause any > major trouble. It is also easier and less likely to cause regressions > than making sure stuff is not preserved when installing. > Unfortunately, a similar problem applies to DISTDIR. However, > installing files from DISTDIR is rarer than from FILESDIR, so I guess > we'll cross that bridge when we get to it. Sorry for the late reply, but this looks like the wrong solution to me. Looking at the installation helpers (doins, doexe, etc.), they don't preserve the normal permission bits, but reset them to a defined state. So why would they preserve xattrs? I don't see anything in PMS that would mandate that behaviour (on the contrary, in section 13.3.1 there is "Other file attributes may be discarded"). How do the other package managers handle this? Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] eend: Output QA notice when called without argument
> On Sat, 04 Sep 2021, Ulrich Müller wrote: > PMS says about eend: "Takes one fixed argument, which is a numeric > return code, and an optional message in all subsequent arguments." Pushed. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] doins: fix D check, add EPREFIX check
> On Mon, 25 Jul 2022, Fabian Groffen wrote: > @@ -50,6 +51,16 @@ if [[ ${_E_INSDESTTREE_#${ED}} != "${_E_INSDESTTREE_}" ]]; > then > __helpers_die "${helper} used with \${D} or \${ED}" > exit 1 > fi > +if [[ -n ${EPREFIX} && \ > + ${_E_INSDESTTREE_#${EPREFIX}} != "${_E_INSDESTTREE_}" ]]; The semicolon is redundant. > +then > + __vecho "---" 1>&2 > + __vecho "You should not use \${EPREFIX} with helpers." 1>&2 > + __vecho " --> ${_E_INSDESTTREE_}" 1>&2 > + __vecho "---" 1>&2 > + __helpers_die "${helper} used with \${EPREFIX}" > + exit 1 > +fi signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Fixing EAPI 8 --enable-static once and for all
> On Sat, 19 Nov 2022, David Seifert wrote: > With this extensive analysis, I believe this patch to be safe. Still looks like an incompatible change, so it will need an EAPI bump. EAPI 9 feature bug is here: https://bugs.gentoo.org/815169 signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Stop implicitly manipulating `NO_COLOR`/`NOCOLOR`
> On Sun, 26 Nov 2023, Michał Górny wrote: > 3. Forcing `NO_COLOR=1` turns out to cause random test failures, >and while fixing them is commendable, it is a pain for arch testing >and it is currently blocking stabilization requests. I'd argue that test suites that fail because of NO_COLOR are broken. IIUC, these failures will show up for users who set NO_COLOR=1 in their make.conf or in the environment? > With the new approach, the color output in programs is consistent > between using ``--jobs`` or ``--quiet-build``, and not. Therefore, > both cases generate uniform logs. In order to obtain logs free of color > codes, one can either filter them via `ansifilter(1)` (as the manpages > already recommend) or explicitly set `NO_COLOR`. Will this still guarantee that NO_COLOR=1 from the environment is always passed on to the build system? Otherwise, it would break ebuild-mode in some configurations. Ulrich signature.asc Description: PGP signature