> 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_C
> 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
> 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}} != "${
> 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
> 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
> 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 "F
>>>>> 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
>>>>> 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
>&
> 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
> 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 w
> 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 ex
> 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 i
> 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)
> /u
> 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
D
> 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,
>
> 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 "Fix
> 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
> 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 th
> 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 b
But we know that it is in /usr/bin, so why add yet another indirection?
signature.asc
Description: PGP signature
> 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/portag
> 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
> 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
>>>
> 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
> 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].
Pr
> 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 Pre
> 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 t
> 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
>>>>> 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
> 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
> 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 i
> 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 doe
> 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.
> 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
> 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?=
> 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:0
> 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
> 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
> 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?
Ulr
> 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
> 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/license
> 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
> 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
> @
> 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
> 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 ob
> 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.
> 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 et
> 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
> 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
> 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 ge
> 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 set
> 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 s
> 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
> 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 in
> 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 appro
> 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 lo
> 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 no
> 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 count
>>>>> 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 shoul
> 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
pgp9WrL5
> 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 me
> 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.pn
> 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/onlinepub
> 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 wou
>>>>> 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,
>>>>> 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
> 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
> 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 mo
>>>>> 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) whi
> 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
>>
> 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
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
> 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.
> 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(-)
>
>
> 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
> 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 pha
> 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 happ
> 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 wa
> 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
> 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__tes
> 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 s
> 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
> 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 f
> 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 consi
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
pgpIpI5bmRZ
> 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 peo
> 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
> 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 suppo
>>>>> 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
>
> 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?
> 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 installe
> 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 supp
92 matches
Mail list logo