>>>>> On Tue, 28 Nov 2017, Ulrich Mueller wrote:
> It has a malformed signature [...]
Also, in News-Item-Format 2.0 there is no "Content-Type:" header.
Sorry for not having noticed this during the review phase.
Ulrich
pgpgOz1jLyiC3.pgp
Description: PGP signature
> On Tue, 28 Nov 2017, NP-Hardass wrote:
> Committed with recommended changes
It has a malformed signature:
$ gpg --verify 2017-11-21-old-wine-versions-moving-to-overlay.en.txt.asc
[...]
gpg: WARNING: not a detached signature; file
'2017-11-21-old-wine-versions-moving-to-overlay.en.txt' wa
> On Mon, 27 Nov 2017, Aaron W Swenson wrote:
> This was deemed no longer necessary…
Applied, thanks.
pgpUVuOaSVc3v.pgp
Description: PGP signature
> On Mon, 27 Nov 2017, Aaron W Swenson wrote:
> On 2017-11-27 10:54, Duncan wrote:
>> While there is no hard restriction on the length of short-name,
>> limiting it to 20 characters is strongly recommended.
>>
>> [...]
> Does it matter if people notice the recommendation? Should it be its
>
> On Mon, 27 Nov 2017, Duncan wrote:
> Arguably bikeshedding but changing up the last sentence to read a
> bit smoother (I skipped formatting)...
> While there is no hard restriction on the length of short-name,
> limiting it to 20 characters is strongly recommended.
> (s/for/on/, reversing
> On Wed, 22 Nov 2017, Michał Górny wrote:
> Path and filename encoding
> --
> The path fields in the Manifest file must consist of characters
> corresponding to valid UTF-8 code points excluding the NULL character
> (``U+``), the backwards slash (``\``) and charac
>>>>> On Wed, 22 Nov 2017, Michał Górny wrote:
> W dniu wto, 21.11.2017 o godzinie 22∶48 +0100, użytkownik Ulrich Mueller
> napisał:
>> > > > > > On Tue, 21 Nov 2017, Michał Górny wrote:
>> > > > > > It is an error for a single f
> On Tue, 21 Nov 2017, Michał Górny wrote:
>> > > > It is an error for a single file to be matched by multiple
>> > > > entries of different semantics, file size or checksum values.
>> > > > It is an error to specify another entry for a file matching
>> > > > ``IGNORE``, or one of its subdirec
> On Tue, 21 Nov 2017, Michał Górny wrote:
>> > It is an error for a single file to be matched by multiple entries
>> > of different semantics, file size or checksum values. It is an error
>> > to specify another entry for a file matching ``IGNORE``, or one of its
>> > subdirectories.
>>
>> W
> On Tue, 21 Nov 2017, Michał Górny wrote:
> All paths specified in the Manifest file must consist of characters
> corresponding to valid UTF-8 code points excluding the NULL character
> (``U+``), the backwards slash (``\``) and characters classified
> as whitespace in the current version
>>>>> On Mon, 20 Nov 2017, Ulrich Mueller wrote:
>>>>> On Mon, 20 Nov 2017, Michał Górny wrote:
>> All paths specified in the Manifest file must consist of characters
>> corresponding to valid UTF-8 code points excluding the NULL character
>> (``U
> On Mon, 20 Nov 2017, Michał Górny wrote:
> New changes:
> 9d819c9 glep-0074: Disallow filenames containing whitespace
> 4124b2f glep-0074: Explicitly specify UTF-8 encoding
> 7f9bd9f glep-0074: Include suggestions from Daniel Campbell
Here are a few comments (quoting below only the parts o
> On Sun, 12 Nov 2017, Michael Orlitzky wrote:
> Some day -- I'll add it to my list. For now I'll update the docs to
> explain why you should use keepdir, and do a QA warning for empty
> directories. Then how does this sound for EAPI=next?
> * Ban keepdir.
> * Have portage call its keepd
> On Sun, 5 Nov 2017, Patrice Clement wrote:
> ACK. This code has been there for ages and I also don't think it makes sense
> to
> keep it as it seems these operations are handled by Portage already. Mike
> (floppym) suggested to remove the whole if clause and call fperms instead:
> diff --g
> On Sat, 4 Nov 2017, Patrice Clement wrote:
> - if [[ "${f}" = *.html ]]; then
> - dohtml "${f}"
> - else
> - dodoc "${f}"
> - fi
> + dodoc "${f}"
That's not exactly equivalent, because *.html files won't
> On Sat, 4 Nov 2017, Patrice Clement wrote:
> - find "${S}" -user 'portage' -exec chown root '{}' \; || die
> "chown failed"
> + find "${S}" -user "${PORTAGE_USERNAME}" -exec chown root '{}'
> \; || die "chown failed"
> if use userland_BSD || [[ ${CHOS
>>>>> On Sat, 28 Oct 2017, Michał Górny wrote:
> W dniu sob, 28.10.2017 o godzinie 14∶49 +0200, użytkownik Ulrich Mueller
> napisał:
>> Other tools like "find" don't special-case dot-prefixed files
>> though (in fact, "ls" may well be t
> On Sat, 28 Oct 2017, Michał Górny wrote:
>> > The Manifest files can also specify ``IGNORE`` entries to skip
>> > Manifest verification of subdirectories and/or files. Files and
>> > directories starting with a dot are always implicitly ignored.
>> > All files that are not ignored must be co
> On Fri, 20 Oct 2017, Dirkjan Ochtman wrote:
> As Hanno was saying, we'll have decades of warning before a break
> becomes practical, so I don't think this is a real concern.
How can we be sure of that? I guess the same reasoning was applied
when MD5 and SHA1 hashes were used.
> I think the
> On Thu, 28 Sep 2017, Austin English wrote:
> Talking with Whubbs about it, I found that our service script only
> supports OpenRC, via rc-service. I looked around, and from what I
> can tell, most distros ship a service tool for all supported init
> systems. I.e., Debian/Ubuntu: supports sys
>>>>> On Thu, 21 Sep 2017, Ulrich Mueller wrote:
> Meanwhile the ver_test function has been added to the eclass in the
> eapi7-ver branch. Please review the patch included below.
Merged, with some updates.
Ulrich
pgp0W2jQp0Jp_.pgp
Description: PGP signature
> On Tue, 19 Sep 2017, Michał Górny wrote:
>> EAPI 7 is introducing new version manipulation and comparison functions
>> that aim to replace versionator.eclass. This eclass provides an 'early
>> adopter' versions of those routines.
>>
>> It serves two goals:
>>
>> a. getting wider review and s
> On Tue, 19 Sep 2017, Paul Varner wrote:
> set and uninstall gentoolkit-dev. This will then allow the installation of
> >=app-portage/gentoolkit-0.4.0
One tiny correction: There should be a full stop at the end of the
sentence.
Ulrich
pgp4HQJd5oUqS.pgp
Description: PGP signature
> On Tue, 12 Sep 2017, Matt Turner wrote:
> I suggested that when security bugs are complete, that if there are
> exp architectures still Cc'd, that security simply reassign to the
> maintainer and let the bug continue as a regular stabilization bug.
> Unfortunately Aaron says that this is fa
> On Sat, 9 Sep 2017, R0b0t1 wrote:
> I suspect the links in ebuilds are more like torrent files, in which
> case I think it makes sense to wait to be contacted to remove the
> links.
Ebuilds aren't hypertext, so by definition they don't contain any
"links". They merely contain lists of URIs
> On Fri, 8 Sep 2017, Ciaran McCreesh wrote:
> On Fri, 08 Sep 2017 14:54:10 +0200
> Michał Górny wrote:
>> It only explains how the functions parse stuff (except for ver_test
>> which uses PMS rules). They are by definition supposed to work with
>> random upstream versions.
> This sounds lik
> On Fri, 8 Sep 2017, Michał Górny wrote:
> +# A version component can either consist purely of digits ([0-9]+) or
> +# purely of uppercase and lowercase letters ([a-zA-Z]+). Any other
> +# character is treated as a version separator.
Minor documentation nitpick (sorry for not noticing this e
> On Thu, 7 Sep 2017, Rich Freeman wrote:
> On Thu, Sep 7, 2017 at 5:18 PM, Michał Górny wrote:
>> W dniu czw, 07.09.2017 o godzinie 16∶42 -0400, użytkownik Rich Freeman
>> napisał:
>>> Are you saying it is sufficient to just point the SRC_URI at the
>>> new URL and remove the mask? As far as
> On Thu, 7 Sep 2017, R0b0t1 wrote:
> Downloading does not imply committing a felony. As far as anyone can
> tell it is impossible to prosecute someone for downloading something
> they already own (regardless of what any EULA has claimed).
Sure, if the user already has rightfully obtained th
> On Thu, 7 Sep 2017, Rich Freeman wrote:
>>> Do we routinely confirm that any site we list in SRC_URI has
>>> permission to redistribute files? That seems like a slippery
>>> slope.
>>
>> We don't, and for a package that comes with a license (as the vast
>> majority of packages does) it norm
>>>>> On Wed, 6 Sep 2017, Rich Freeman wrote:
> On Wed, Sep 6, 2017 at 2:52 AM, Ulrich Mueller wrote:
>>>>>>> On Tue, 5 Sep 2017, Gordon Pettey wrote:
>>
>>> Can these package.mask notes stop saying "no alternative found"
>
> On Tue, 5 Sep 2017, Gordon Pettey wrote:
> Can these package.mask notes stop saying "no alternative found" when
> it's obvious five seconds of Google searching was not even performed
> to find an alternative?
> https://neverwintervault.org/project/nwn1/module/shadowlords-dreamcatcher-and-dem
> On Thu, 31 Aug 2017, Mike Pagano wrote:
> + declare -l LOOP_ARCH_L=${LOOP_ARCH}
> [...]
> + declare -u TC_ARCH_KERNEL=$(tc-arch-kernel);
This is not legal in EAPI 5 or earlier, because the -l and -u options
of declare did not exist in bash 3.2. So it is no improveme
> On Thu, 31 Aug 2017, Michał Górny wrote:
>> > @@ -1425,9 +1426,10 @@ detect_arch() {
>> > COMPAT_URI="${!COMPAT_URI}"
>> >
>> > [[ -n ${COMPAT_URI} ]] && \
>> > - ARCH_URI="${ARCH_URI} $(echo ${LOOP_ARCH} | tr '[:upper:]'
>> > '[:lower:]')? ( ${COMPAT_URI} )"
>> >
> On Wed, 30 Aug 2017, Ian Stakenvicius wrote:
> For adding this to FEATURES and RESTRICT, are we moving into PMS
> modification territory?
Not necessarily. Or rather, we could proceed without modifying it,
because "Package managers may recognise other tokens" [1].
FEATURES is Portage only.
> On Wed, 30 Aug 2017, Michael Orlitzky wrote:
>> This rather sounds like a case for package manager support with
>> some property like RESTRICT="uninstall".
> Would it still be possible to override with
> I_KNOW_WHAT_I_AM_DOING=yes then?
No. If this was to be implemented in Portage, I think
> On Wed, 30 Aug 2017, Michael Orlitzky wrote:
> I've been working on the user packages GLEP that I started and then
> forgot about sometime at the beginning of the year. I'm trying to finish
> up the reference implementation.
> When it comes to removing users, everyone's suggestions were alo
> On Mon, 28 Aug 2017, Duncan wrote:
> Michał Górny posted on Mon, 28 Aug 2017 20:25:54 +0200 as excerpted:
>> # Michał Górny (28 Aug 2017)
>> # Alike xfce4-mixer, relies on gstreamer:0.10 (gstreamer:1.0 removed
>> # mixer wrappers). Last commit upstream in 2014. PulseAudio users
>> # can sw
> On Sat, 26 Aug 2017, Matt Turner wrote:
> Isn't it just part of util-linux? The HOMEPAGE link makes me think
> so, and my system has /bin/more which is owned by util-linux, which
> is part of @system. Seems silly to have a separate package for it in
> the tree on those grounds alone.
It is/
> On Wed, 16 Aug 2017, Marek Szuba wrote:
> On 2017-08-14 23:46, William L. Thomson Jr. wrote:
>> pkgcore - does not support EAPI 6, only experimental EAPI 5
> Side note - according to
> https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification
> pkgcore has supported EAPI 6 since
> On Tue, 15 Aug 2017, Francisco Blas Izquierdo Riera (klondike) wrote:
> Updated the news item following comments from dilfridge, mrueg and
> floppym. Also made it display to users of hardened profiles.
Some very minor comments:
> Author: Francisco Blas Izquierdo Riera (klondike)
Format o
>>>>> On Thu, 3 Aug 2017, Michael Orlitzky wrote:
> On 08/03/2017 06:33 PM, Ulrich Mueller wrote:
>> It did, even back in 2004:
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1
> On Thu, 3 Aug 2017, Michael Orlitzky wrote:
> On 08/03/2017 03:39 PM, Mike Gilbert wrote:
>> The developer handbook was also a "policy" manual of sorts when it
>> existed.
> The developer handbook that I just said didn't mention variables in
> HOMEPAGE at all.
It did, even back in 2004:
ht
> On Thu, 3 Aug 2017, Michael Orlitzky wrote:
> [...] Portage Manager Specification [...]
D'oh!
pgp6Uct6pop5G.pgp
Description: PGP signature
> On Thu, 3 Aug 2017, Mike Gilbert wrote:
> I would like to remove the ban on variable references in the
> HOMEPAGE variable in ebuilds.
I think this is not a good idea. For example, it would break
browse-url-at-point (C-u u .) from within Emacs.
> [...]
> Allowing variables in HOMEPAGE wou
> On Tue, 25 Jul 2017, Michał Górny wrote:
> On wto, 2017-07-25 at 09:26 -0400, Rich Freeman wrote:
>> There would also be less variation. Bug: 123456 is pretty
>> unambiguous as a reference. When you start having http vs https and
>> maybe a few different ways of creating a URL to a bug it co
> On Mon, 24 Jul 2017, Mike Gilbert wrote:
>> The flag also pulls in additional dependencies for some ebuilds.
>> So I wonder how it could be made unconditional? For example,
>> app-admin/eselect[vim-syntax] depends on app-vim/eselect-syntax
>> which in turn will pull in vim or gvim. Certainly
> On Sat, 22 Jul 2017, Mike Gilbert wrote:
> Packages currently handle installation of vim syntax support files
> inconsistently. Some builds install the files if the "vim-syntax"
> USE flag is enabled, while others install them unconditionally.
> Do these files fall into the "small text file
> On Mon, 10 Jul 2017, William L Thomson wrote:
> Stop getting lost in the weeds
> You all are making this about -c vs -C. I am not talking about that!
> LET ME CLARIFY
> [...] SHOULD [...] PERIOD. NOTHING [...]
> So PLEASE stop with that!
Right. Please stop shouting in the gentoo-
>>>>> On Sun, 09 Jul 2017, Michał Górny wrote:
> On nie, 2017-07-09 at 09:22 +0200, Ulrich Mueller wrote:
>> Second, and more important, introduction of an automatic solver
>> would inevitably lead to proliferation of REQUIRED_USE in the tree.
>> However, noth
> On Sat, 08 Jul 2017, Michał Górny wrote:
> Nobody said anything about the next EAPI. The GLEP doesn't say a
> word about introducing it in a future EAPI.
> We're adding this as an optional (default off) FEATURE into Portage
> and we'll see how it works. As far as I'm concerned, we can enabl
> On Sat, 8 Jul 2017, Ciaran McCreesh wrote:
> On Sat, 8 Jul 2017 16:39:29 +0200
> Alexis Ballier wrote:
>> Indeed, makes sense. Would it also make sense to have some more
>> logical meaning in a future EAPI ? I mean, in every context I've ever
>> seen, applying a rule to the empty set is the
>>>>> On Sat, 08 Jul 2017, Michał Górny wrote:
> On sob, 2017-07-08 at 12:26 +0200, Ulrich Mueller wrote:
>> Section "Processing algorithm":
>>
>> > 2. Check whether the REQUIRED_USE constraint matches restrictions
>> > set in #Restrict
> On Sat, 08 Jul 2017, Michał Górny wrote:
> The pre-GLEP for review is here:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse
On first glance:
Section "Processing algorithm":
| 2. Check whether the REQUIRED_USE constraint matches restrictions
| set in #Restrictions on REQUIRED_USE f
> On Tue, 20 Jun 2017, Pacho Ramos wrote:
> This packages are now up for grabs:
> eclass/l10n.eclass
I can take this one.
Ulrich
pgpyjv3fExdLQ.pgp
Description: PGP signature
> On Tue, 30 May 2017, Alexis Ballier wrote:
> The way I see it, this boils down to spec'ing something that
> guarantees there's a unique solution given an input. The solution
> does not have to be good or bad (we don't have a good metric on that
> anyway), it just has to be deterministic so t
>>>>> On Tue, 30 May 2017, Alexis Ballier wrote:
> On Tue, 30 May 2017 00:01:16 +0200
> Ulrich Mueller wrote:
>> Also, can we find a better name? Sorry for the bikeshedding at this
>> early stage, but I believe that ENFORCED_USE can be easily confused
>>
> On Mon, 29 May 2017, Michał Górny wrote:
> On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote:
>> Can you provide an efficient algorithm for the above syntax? That
>> is, given a set of +/- useflags forced by user, output the set of
>> effective useflags (or a rant if it is inconsistent
> On Tue, 23 May 2017, William Hubbs wrote:
> On Tue, May 23, 2017 at 09:31:18PM +0200, Michał Górny wrote:
>> I'd like to request Infra to establish a new mailing list that would
>> fill in the gap between our public mailing lists and the gentoo-core
>> mailing list.
>>
>> Name: gentoo-dev-i
> On Fri, 12 May 2017, Matthias Maier wrote:
> I will post an RFC for a profile update (and a news item) for 17.0
We used to count from 1999 (namely, 10.0 introducing the counting
appeared on our 10th anniversary).
So shouldn't the above be 18.0?
Ulrich
pgpaE0ZYH2Lu2.pgp
Description: PGP
> On Thu, 4 May 2017, Jeroen Roovers wrote:
>Atom Prefix Operators [> >= = <= <]
> Sometimes you want to be able to depend on general
>versions rather than specifying exact versions all the time.
>Hence we provide standard boolean operators:
>
> On Wed, 3 May 2017, William Hubbs wrote:
> # @VARIABLE: mymesonargs
I guess this is modeled after cmake-utils.eclass, but should eclass
variables really use the "my" prefix? There seems to be no formal rule
for this, but numerous devmanual examples (like MY_PV) suggest that MY
is available
> On Tue, 2 May 2017, Chí-Thanh Christopher Nguyễn wrote:
> Also very common is that he changes fully qualified package names
> (which is the correct syntax per [1]) into fully qualified package
> atoms (which is the legacy syntax). Bug 616260 is one such example.
> [1] https://bugs.gentoo.or
> On Mon, 01 May 2017, Michał Górny wrote:
> You are confusing constructive criticism with meaningless style
> bikeshed which serves no purpose except creating more work on
> everyone.
What's creating more work for everybody is changing the name of the
token. All I was saying was that "hyphen
> On Mon, 1 May 2017, kentnl wrote:
> @@ -40,6 +40,7 @@
> # [@DEFAULT_UNSET]
> # [@INTERNAL]
> # [@REQUIRED]
> +# @DEFAULT-VALUE:
Please make this DEFAULT_VALUE, in oder to be consistent with the
existing DEFAULT_UNSET. Otherwise, nobody will be able to remember
when to use a hyphen and
> On Sun, 30 Apr 2017, Michał Górny wrote:
> From now on I'm not going to listen to any suggestions that do not
> come with a patch.
You have posted a patch for review. So IMHO, asking others to do the
work when you receive criticism isn't a reasonable request. All the
more since the suggeste
> On Fri, 28 Apr 2017, Michał Górny wrote:
> (and hyphens do not require holding shift).
So they are awkward to type inside a string that is all-caps?
Ulrich
pgpcPtuzpVLxT.pgp
Description: PGP signature
> On Mon, 17 Apr 2017, James Le Cuirot wrote:
> If you've been wondering why I've been quiet of late (you have,
> right?!) then this is partly why. I'm not sure why I spent so long
> on an eclass that hardly anyone uses but it's utilised by many of my
> old favourite games.
Wouldn't this be a
> On Mon, 3 Apr 2017, Dirkjan Ochtman wrote:
> This seems pretty hasty.
> First of all, SHA-256 should be safe for all intents and purposes,
> and for the foreseeable future. This is nothing like Git's usage of
> SHA-1, which was known to be on the way to brokenville for a long
> time. I don'
Does anyone mind if I remove empty assignments of optional variables
from virtual ebuilds? Especially: HOMEPAGE, SRC_URI, LICENSE, IUSE,
and DEPEND.
Ulrich
pgpYqVSXGIeY3.pgp
Description: PGP signature
> On Mon, 27 Mar 2017, NP-Hardass wrote:
> This is part of the usual for discussing new virtuals before
> addition. I'm reaching the final stages of prep for migrating from
> app-emulation/wine to several packages, one for each major patchset
> that we support. This will enable us to get rele
> On Mon, 27 Mar 2017, Mart Raudsepp wrote:
> Ühel kenal päeval, E, 27.03.2017 kell 11:07, kirjutas Fabian Groffen:
>> Back to the topic of the thread, is it possible to make the
>> difference between e.g. x86, x86-linux, x86-solaris and x86-macos
>> in this proposal?
> I believe the intentio
> On Mon, 27 Mar 2017, Fabian Groffen wrote:
>> > When you say "arch" you actually mean a keyword as per GLEP-53[1]
>> > right?
>>
>> Which doesn't agree with actual usage in the tree, though.
> That surprises me. Do you have an example of that?
The GLEP says about the OS suffix:
"The rig
> On Sun, 26 Mar 2017, Brian Dolbec wrote:
> I would much prefer for any new files to be created in a format that
> most languages have data input modules for and are easily read/edited
> by humans. While this can be read and split easily in python code. It
> is not future proof for addition
> On Sun, 26 Mar 2017, Fabian Groffen wrote:
> When you say "arch" you actually mean a keyword as per GLEP-53[1]
> right?
Which doesn't agree with actual usage in the tree, though.
Ulrich
> [1] https://wiki.gentoo.org/wiki/GLEP:53
pgp07XMca9oQW.pgp
Description: PGP signature
> On Fri, 24 Mar 2017, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 22:45:54 +0100
> David Seifert wrote:
>> https://bugs.gentoo.org/show_bug.cgi?id=586416
> yep, that's about tracking access to the dir not to the variable
> itself
Which is what is intended. As I have already explained twic
> On Mon, 20 Mar 2017, Alexis Ballier wrote:
> What makes me wonder more are the proposed solutions: So far the
> only proposals I've seen are either inlining *all* the code or
> moving *all* the code into an eclass. Having a quick look at
> autoconf, it seems to me an intermediate solution wo
> On Mon, 20 Mar 2017, Alexis Ballier wrote:
>> After the PMS change, we will have the same properties for DISTDIR,
>> FILESDIR, WORKDIR, and S. Namely:
>>
>> - All four variables will be valid in src_* phases and in global scope
>> - They will have a consistent value in the ebuild environmen
> On Mon, 20 Mar 2017, Mike Frysinger wrote:
> obvious NAK until you sort out the open questions already raised
> about the backwards breaking change you're trying to land in PMS.
There are indeed some PMS patches pending about DISTDIR, FILESDIR,
WORKDIR, and S, but I fail to see where they w
> On Thu, 16 Mar 2017, Alexis Ballier wrote:
> What do you consider demand ?
> A handful of packages that have to write a hundred lines of
> boilerplate code to make it work isn't representative of any demand
> at all. I've already written in some bug some usecases I foresee for
> even a triv
> On Thu, 16 Mar 2017, Alexis Ballier wrote:
> Indeed, but that eclass fails to follow devmanual eclass 101 [1]:
> An eclass is a collection of code which can be used by more than one
> ebuild.
Which is the case here:
sys-devel/autoconf/autoconf-2.13.ebuild| 10 +---
sys-devel/a
> On Thu, 16 Mar 2017, Michał Górny wrote:
> 100 insertions(+), 198 deletions(-)
This alone is rather convincing.
Ulrich
pgpEVcJFAZOur.pgp
Description: PGP signature
> On Sat, 11 Mar 2017, Michał Górny wrote:
> Split the estack_* and related functions from eutils into a
> dedicated estack.eclass. Those functions have significant complexity
> and are not used frequently, therefore they benefit from having a
> separate file and an explicit dedicated maintain
> On Thu, 09 Mar 2017, William L Thomson wrote:
> Along the lines of failures. What if a system has rm aliased to
> prompt before removal? In that case rm -r would fail, but rm -fr
> would not. That would cause failures for the user and not the
> developer. Assuming rm does not disable prompt
>>>>> On Sat, 4 Mar 2017, Matt Turner wrote:
> On Sat, Mar 4, 2017 at 12:03 PM, Ulrich Mueller wrote:
>> Isn't that rather pointless, given that in all non-deprecated EAPIs
>> econf will already pass --disable-silent-rules to configure?
> I don't kn
> On Sat, 4 Mar 2017, Matt Turner wrote:
> + # Check if package supports a verbose build
> + if grep -q -s "disable-silent-rules" ${ECONF_SOURCE:-.}/configure; then
> + local no_silent="--disable-silent-rules"
> + fi
> +
> local myeconfargs=(
> ${dep
>>>>> On Sun, 26 Feb 2017, Ulrich Mueller wrote:
> I will remove the headers on Tuesday, 2017-02-28, between 06:00
> and 07:00 UTC.
Cancelled for now.
Since there appear to be doubts how to interpret the previous Council
decision, I am going to ask for clarification
> On Mon, 27 Feb 2017, Robin H Johnson wrote:
> Why did Repoman not complain about either of these?
Repoman has been fixed in bug 579460, following the council decision.
Also app-emacs/ebuild-mode was changed for removal of the $Id$ header,
and I think a similar change was committed for Vim.
> On Sun, 26 Feb 2017, Lars Wendler wrote:
> There is no need to enable it by default. But it is a very nice way
> to verify ebuild changes if being enabled locally on a git clone of
> the tree. Ever since portage was migrated to git I had this line in
> my .git/info/attributes file on my dev
> On Sun, 26 Feb 2017, Robin H Johnson wrote:
> The 2014-10-14 meeting did NOT specify what CVS headers were in
> question, and it was later decided that this was $Header$, not $Id$.
When and by whom was that decided? The unanimous council decision was
to remove "CVS headers" and the obvious
>>>>> On Sat, 25 Feb 2017, Ulrich Mueller wrote:
> As the council has decided in its 2014-10-14 meeting (and confirmed
> again in the 2016-11-13 meeting), CVS headers should be removed after
> the migration to Git. Until recently, this was blocked by repoman
> still
> On Sat, 25 Feb 2017, Sergei Trofimovich wrote:
> Typical questions for tree-wide cleanups:
> - Are new ebuilds forbidden to have '$Id$' or just discouraged?
> - [same as above] Will new version of repoman complain about
> leftover '$Id$'?
Not sure. That would have to be controlled via la
As the council has decided in its 2014-10-14 meeting (and confirmed
again in the 2016-11-13 meeting), CVS headers should be removed after
the migration to Git. Until recently, this was blocked by repoman
still checking for the $Id$ line. The latter is now fixed in the
stable repoman version.
There
> On Thu, 23 Feb 2017, Andrew Savchenko wrote:
>> https://projects.gentoo.org/pms/6/pms.html#x1-180003.1.1 "Category Names"
> I don't see a requirement here, only note on most common pattern:
> ``Note: A hyphen is not required because of the virtual category.
> Usually, however, category nam
> On Tue, 21 Feb 2017, Gordon Pettey wrote:
> There is no requirement for category names to be x-y.
https://projects.gentoo.org/pms/6/pms.html#x1-180003.1.1 "Category Names"
pgpj2063_n6TN.pgp
Description: PGP signature
> On Tue, 21 Feb 2017, Lars Wendler wrote:
>> 1) Putting printer drivers into "net-print" is silly.
>>
>> Something that converts format a to device-specific format b has
>> absolutely nothing to do with network.
>> So, a new category "sys-print", emphasizing that it's hardware
>> drivers, (o
> On Sun, 12 Feb 2017, Alexis Ballier wrote:
>> Or do you have any concrete evidence that has_m64 is still used?
> Nope. It is just that it is part of an API that we export and, since
> we have easy means to drop it properly, why not doing so ? Esp. since
> dropping it "improperly" doesn't se
> On Sun, 12 Feb 2017, Alexis Ballier wrote:
> I think it'd be better to lock the removal with a new EAPI for
> overlays / downstreams.
That sounds like complete overkill here. There's a deprecation warning
in place since five years, so people had plenty of time to update
their ebuilds. Also
See patch below. The has_m64 function is no longer used in the tree.
Unfortunately, we cannot get rid of the eutils inherit because it is
still used for eqawarn.
Ulrich
From 84334ae8abd85c7880e5a357ff8f71bc8bdb1eee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
Date: Sat, 11 F
> On Tue, 7 Feb 2017, Ian Stakenvicius wrote:
> On 07/02/17 08:27 AM, Michael Orlitzky wrote:
>>
>> The thread wasn't about discouraging IUSE defaults, rather to
>> decide when they are appropriate. You cannot omit "pkginternal"
>> from USE_ORDER, because you will break all of the packages wh
901 - 1000 of 2160 matches
Mail list logo
