Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
On Tue, 28 Mar 2017 00:00:30 +0100 "M. J. Everitt" wrote: > 'unstable' should surely be applied to masked packages, no? Everything > not-stable and not-unstable becomes therefore 'testing' ... Nah, he's trying to make the phrase "stable arch" mean something in a way tools can understand. Because we currently have stable arches as a concept, but as far as portage is concerned, we only have stable *profiles*, but we can only identify specific profiles with arches ... which means ... We can't have a value of ~arch that we can test without also implying the experimental profiles of that arch that don't matter. Hence, stable - what it currently means testing - for architectures where there will be no promises beyond "Somebody tested it once" and a 'stable' KEYWORD value does not mean anything more than a '~' KEYWORD value. Where the objective is to make sure at least for an architecture developers should spend effort to keep that keywording in place, but not ever bother with stabilizing. unstable - This architecture is so undermaintained that no encouragement is made of developers to keep keywords consistent, and they can be freely ignored. This is why I preferred alternative wording that was descriptive of what its doing instead of so obscure and generic and over-conflated. keyword-consistency=literal-match # 'stable' keyword-consistency=mixed # 'testing' keyword-consistency=none # 'unstable' Or something along those lines. pgp3zeIh_1EHJ.pgp Description: OpenPGP digital signature
[gentoo-dev] Virtuals cleanup
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
Re: [gentoo-dev] New Virtual: virtual/wine
On 03/27/2017 08:55 PM, Ulrich Mueller wrote: >> 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 releases out quicker. >> In addition, with the new packaging, we'll be supporting slotting, >> so users can choose to support specific apps with specific wine >> versions or patchsets simultaneously. More specifics on that to come >> in an email about a news item. > > The empty HOMEPAGE, SRC_URI, LICENSE, and DEPEND assignments should be > omitted. > > Ulrich > Updated on the wine-a-holics overlay where we are testing it all out. Thanks. -- NP-Hardass signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Virtual: virtual/wine
> 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 releases out quicker. > In addition, with the new packaging, we'll be supporting slotting, > so users can choose to support specific apps with specific wine > versions or patchsets simultaneously. More specifics on that to come > in an email about a news item. The empty HOMEPAGE, SRC_URI, LICENSE, and DEPEND assignments should be omitted. Ulrich pgpiWskWnYlJC.pgp Description: PGP signature
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
On 27/03/17 11:10, Mart Raudsepp wrote: > >> 3] Meaning of the three values "stable", "testing", "unstable" for >> repoman >> >> * stable: When a profile of arch is tested, then repoman checks >> consistency for >> "arch" and for "~arch" separately. >> Which profiles of the arch are tested is still controlled by >> profiles.desc (and >> -d / -e switches). >> This is the current behaviour and should be the default if nothing is >> specified >> for an arch. >> >> * testing: When a profile of arch is tested, then repoman treats >> "arch" as >> "~arch", and tests consistency only for "~arch". >> Which profiles of the arch are tested is still controlled by >> profiles.desc (and >> -d / -e switches). >> A new switch for repoman may be provided to temporarily upgrade an >> arch from >> "testing" to "stable" (for arch team work). >> >> * unstable: When a profile of arch is tested, then repoman treats >> "arch" as an >> error and aborts. Consistency is only tested for "~arch". >> Which profiles of the arch are tested is still controlled by >> profiles.desc (and >> -d / -e switches). > This sounds more like "testing" to me - architecture is only meant to > have "testing" keywords, which is what I tend to call ~arch because > it's in testing to become "stable" in ~30days or so, instead of calling > it "unstable" (which feels appropriate only for a package that doesn't > carry any stable keywords in older versions either). > While taken from another perspective, the meaning for "testing" as in > this proposal makes sense too - treat all as "testing" keywords. > This goes back to the overloaded terminology concerns that have been > echoed by others as well. > But I don't have any good suggestions for alternatives either right > now. stable/no_stable_check/testing_only? shrug. > > 'unstable' should surely be applied to masked packages, no? Everything not-stable and not-unstable becomes therefore 'testing' ... signature.asc Description: OpenPGP digital signature
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/swing-worker
# Patrice Clement (28 Mar 2017) # Part of the JRE since Java 6. Removal in 30 days. dev-java/swing-worker -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] New Virtual: virtual/wine
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 releases out quicker. In addition, with the new packaging, we'll be supporting slotting, so users can choose to support specific apps with specific wine versions or patchsets simultaneously. More specifics on that to come in an email about a news item. I'm not planning on immediately switching over, but rather masking for maybe a month or so before releasing to the public at large. -- NP-Hardass # Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 EAPI=6 DESCRIPTION="Virtual for WINE that supports multiple variants and slotting" HOMEPAGE="" SRC_URI="" LICENSE="" SLOT="0" KEYWORDS="~amd64 ~x86" IUSE="staging d3d9" DEPEND="" # Note, the ordering here is intentional, to take advantage of the short-circuit # logic of portage, to enforce wine-vanilla as default for new users. The idea # behind this is that some USE flags may pull in 3rd-party patchsets, so default # of vanilla prevents that. RDEPEND=" staging? ( || ( app-emulation/wine-staging[staging] app-emulation/wine-any[staging] ) ) d3d9? ( || ( app-emulation/wine-d3d9[d3d9] app-emulation/wine-any[d3d9] ) ) || ( app-emulation/wine-vanilla app-emulation/wine-staging app-emulation/wine-d3d9 app-emulation/wine-any ) !app-emulation/wine:0" signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: new package category: net-vpn
17.03.2017 19:05, Jason A. Donenfeld пишет: > On Fri, Mar 17, 2017 at 4:05 PM, Michał Górny wrote: >> On pią, 2017-03-17 at 14:57 +0100, Jason A. Donenfeld wrote: >>> Done. >> >> It's nice that you waited for people to actually wake up around >> the world to give you feedback. > > Yep, sorry. Already chastised and discussed at length on IRC. Duly noted. > Hm, i should probably move net-dialup/pptpd to this category... Not sure about net-dialup/accel-ppp, cause it has IPoE now, so it is more like generic NAS/ solution, rather than regular VPN Thanks for moving vtun, though ;-) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/edpwd
# Michał Górny (27 Mar 2017) # No revdeps or real use case. Uses ECB mode for encryption which is # a bad idea. Requires patching for dev-python/pycryptodome. Abandoned # upstream and downstream. Removal in 30 days. Bug #611592. dev-python/edpwd -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
This looks good overall, thanks. If we stay with the whitespace separated columns, the spec should be clear that implementations should be able to deal with future additional "columns" in their parsing code. Below some paint choices from me. > We introduce a new file "arches.desc" which essentially describes if > an arch > (not a profile) is stable or not. The meaning of profiles.desc is not > affected; Essentially the proposal extends profiles/arch.list but due to backwards compatibility can't just add details there. As such, in my opinion the file should be called arch.desc (not plural arches.desc) to go along with that. > 1] File location: > profiles/arches.descor metadata/arches.desc profiles/arch.desc or metadata/repoman/arch.desc > 3] Meaning of the three values "stable", "testing", "unstable" for > repoman > > * stable: When a profile of arch is tested, then repoman checks > consistency for > "arch" and for "~arch" separately. > Which profiles of the arch are tested is still controlled by > profiles.desc (and > -d / -e switches). > This is the current behaviour and should be the default if nothing is > specified > for an arch. > > * testing: When a profile of arch is tested, then repoman treats > "arch" as > "~arch", and tests consistency only for "~arch". > Which profiles of the arch are tested is still controlled by > profiles.desc (and > -d / -e switches). > A new switch for repoman may be provided to temporarily upgrade an > arch from > "testing" to "stable" (for arch team work). > > * unstable: When a profile of arch is tested, then repoman treats > "arch" as an > error and aborts. Consistency is only tested for "~arch". > Which profiles of the arch are tested is still controlled by > profiles.desc (and > -d / -e switches). This sounds more like "testing" to me - architecture is only meant to have "testing" keywords, which is what I tend to call ~arch because it's in testing to become "stable" in ~30days or so, instead of calling it "unstable" (which feels appropriate only for a package that doesn't carry any stable keywords in older versions either). While taken from another perspective, the meaning for "testing" as in this proposal makes sense too - treat all as "testing" keywords. This goes back to the overloaded terminology concerns that have been echoed by others as well. But I don't have any good suggestions for alternatives either right now. stable/no_stable_check/testing_only? shrug. > 4] Meaning for other tools > All arches set to "stable" are considered "stable arches", meaning > * they get listed first in eshowkw > * they require stabilization requests in bugzilla > * ... If other tools use this, then maybe the repoman specific metadata/repoman/ path isn't appropriate afterall. So then profiles/arch.desc or metadata/arch.desc Mart
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
> 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 intention here is for this file to declare stuff > about an "arch" in terms of what repoman names it as such > (--include-arches=, etc), and what profiles.desc has as the first > column value (in comments it also names that column "arch"). > The filename "arches.desc" just comes from that convention, while > indeed it really matches what you put in KEYWORDS in terms of ebuild > usage. I guess that filename is a shed to paint then too. It also agrees with the PMS usage of the term "architecture": https://projects.gentoo.org/pms/6/pms.html#x1-610005.3.2 https://projects.gentoo.org/pms/6/pms.html#x1-690007.3.2 Ulrich pgpGskU5IRJWz.pgp Description: PGP signature
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
Ühel kenal päeval, E, 27.03.2017 kell 11:07, kirjutas Fabian Groffen: > On 27-03-2017 09:56:50 +0200, Ulrich Mueller wrote: > > > > > > > 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 right hand part indicates the operating system or > > distribution, > > such as linux, macos, solaris or fbsd. If the right hand part is > > omitted, it implies the operating system/distribution type is > > GNU/Linux." > > > > So if I understand this correctly, x86-linux should be equivalent > > to > > x86. But in reality, the linux suffix denotes that it is a prefix > > arch. I'm not saying that this is bad, only it's not what the GLEP > > says. > > I see. The lack of explicit mentioning what the difference means > allows > for different interpretations. I always *assumed* it meant Gentoo (1 > part) vs Gentoo/Alt (2 parts). > > > Until recently there was also x64-freebsd vs amd64-fbsd, where both > > the arch and the OS part denoted the same, but used different > > tokens > > to distinguish between prefix and non-prefix. (And I don't > > understand > > why amd64 is called x64 on prefix. A different OS suffix should be > > sufficient.) > > It kind of proves the point that two fields in a keyword isn't > "enough > for everyone". > > 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 intention here is for this file to declare stuff about an "arch" in terms of what repoman names it as such (--include-arches=, etc), and what profiles.desc has as the first column value (in comments it also names that column "arch"). The filename "arches.desc" just comes from that convention, while indeed it really matches what you put in KEYWORDS in terms of ebuild usage. I guess that filename is a shed to paint then too. Mart
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
On 27-03-2017 09:56:50 +0200, Ulrich Mueller wrote: > > 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 right hand part indicates the operating system or distribution, > such as linux, macos, solaris or fbsd. If the right hand part is > omitted, it implies the operating system/distribution type is > GNU/Linux." > > So if I understand this correctly, x86-linux should be equivalent to > x86. But in reality, the linux suffix denotes that it is a prefix > arch. I'm not saying that this is bad, only it's not what the GLEP > says. I see. The lack of explicit mentioning what the difference means allows for different interpretations. I always *assumed* it meant Gentoo (1 part) vs Gentoo/Alt (2 parts). > Until recently there was also x64-freebsd vs amd64-fbsd, where both > the arch and the OS part denoted the same, but used different tokens > to distinguish between prefix and non-prefix. (And I don't understand > why amd64 is called x64 on prefix. A different OS suffix should be > sufficient.) It kind of proves the point that two fields in a keyword isn't "enough for everyone". 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? Thanks, Fabian > >> > [1] https://wiki.gentoo.org/wiki/GLEP:53 -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
[gentoo-dev] Re: Packages up for grabs
On 2017-03-26 21:50, aide...@gentoo.org wrote: > app-backup/burp I'll grab this one unless anyone minds. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
> 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 right hand part indicates the operating system or distribution, such as linux, macos, solaris or fbsd. If the right hand part is omitted, it implies the operating system/distribution type is GNU/Linux." So if I understand this correctly, x86-linux should be equivalent to x86. But in reality, the linux suffix denotes that it is a prefix arch. I'm not saying that this is bad, only it's not what the GLEP says. Until recently there was also x64-freebsd vs amd64-fbsd, where both the arch and the OS part denoted the same, but used different tokens to distinguish between prefix and non-prefix. (And I don't understand why amd64 is called x64 on prefix. A different OS suffix should be sufficient.) Ulrich >> > [1] https://wiki.gentoo.org/wiki/GLEP:53 pgpUBeeT06YYk.pgp Description: PGP signature
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
On Sun, 26 Mar 2017 22:10:23 -0400 "Walter Dnes" wrote: > Hopefully, there's no need to go JSON format (bleagh). To simplify > parsing, fields for one arch should be clustered together. "should be committed only after running it through sort with LC_ALL=C" pgpH0WtqWRRt_.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
On Sun, 26 Mar 2017 13:04:18 -0700
Brian Dolbec wrote:
> While this can be read and split easily in python code. It
> is not future proof for additional data being added and/or removed.
This is why in my earlier comments to this proposal, I asked for
a: more descriptive terms than 'stable', 'unstable', or 'testing', because
they're
all contextually ambiguous without inherently clear meaning
b: a format of \s where was a list of space-delimited
= pairs.
This at least means we stop relying on columns for data, and means that the data
is also trivially parseable with simple tools like grep/sed.
Whereas defining it as a multi-line YAML parser may seem great if you can
assume every tool at users disposal has YAML parsers and standard YAML parsing
libraries,
but in reality, some of the tools at our disposal are "bash" and "sed", and
decoding
and interpreting YAML from Bash is rather complicated.
( And there are other fun problems when you start talking about YAML )
Though, you could cheat and mandate a packed 1-line-per-arch YAML format.
This, iirc, is legal YAML:
amd64: {stability: "stable", bits: 64, description: "Includes CPU manufaturers
such as Intel, AMD, others...", comments: "The most common/popular arch in the
tree...", email: "amd64@..." }
But at that point ...
s/\b(([^=]+=(\S+)\b/{$1: "$2"}, / && parse_yaml ...
pgpdEA_DotYpR.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
On 26-03-2017 22:02:38 +0200, Ulrich Mueller wrote: > > 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. That surprises me. Do you have an example of that? Thanks, Fabian > > Ulrich > > > [1] https://wiki.gentoo.org/wiki/GLEP:53 -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
