Re: [gentoo-dev] NEWS item for games destabling
On Mon, 20 Nov 2017 21:53:52 -0800 Daniel Campbell wrote: > On Mon, Nov 20, 2017 at 11:36:33AM +0100, Róbert Čerňanský wrote: > > On Mon, 20 Nov 2017 10:26:29 +0100 > > David Seifert wrote: > > > > > Round 2 (with correct whitespace this time): > > > > > > Title: No stable KEYWORDS for Gentoo Games > > > Author: David Seifert > > > Content-Type: text/plain > > > Posted: 2017-11-20 > > > Revision: 1 > > > News-Item-Format: 1.0 > > > Display-If-Keyword: amd64 x86 > > > > > > As the Games team does not have enough manpower to keep tabs on > > > all games packages, we have dropped all ebuilds maintained by the > > > games project to unstable KEYWORDS (without those required by > > > other stable packages). If you have any of these stable games > > > packages installed, you will have to add them > > > to /etc/portage/package.accept_keywords/ manually. Failures > > > related to missing stable KEYWORDS will show up as > > > > > > The following keyword changes are necessary to proceed: > > >(see "package.accept_keywords" in the portage(5) man page for > > > more details) > > > # required by @selected > > > # required by @world (argument) > > > =games-action/0verkill-0.16-r4 ~amd64 > > > > > > While we accept that this will cause some irritation for the > > > community, pretending we have a well supported games collection by > > > having a wealth of stable games packages is misleading at best. We > > > welcome contributions from outsiders willing to polish up the > > > games landscape in Gentoo via the Proxy Maintainers. > > > > What does it mean for the future? Should not users bother to test & > > write stabilization request bugs for games anymore? Or stabi > > requests will still be accepted? > > If I may take a stab at this (correct me if I'm wrong, soap): > > It only means games are being dropped to ~arch (testing) until other > maintainers (proxy or otherwise) step up to make sure the games really > are stable. Packages that rarely get attention but are still marked > "stable" dilutes the meaning of "stable", especially if you get > installation or runtime problems that a proper testing of the package > would have caught. > > This results in bugs that should've been caught in the testing phase, > confuses users (and developers), and redundant or obvious bugs being > reported. > > This reads like a "fresh slate" for games, allowing them to start from > ~arch and ensure that stabilization procedures are correctly followed > by those who step up. While this will create more stabilization bugs, > it should, in theory, result in better ebuilds (which makes Gentoo > maintenance better/easier) and games that have *actually* been tested. > > I hope this explanation is both accurate and helpful. It make sense to me. Although the original news reads more like "games will not go to stable unless they are proxy maintained" but -- in light of your explanation -- that's probably me reading it wrong. It is certainly better if package keywords reflect the reality. I only hope this will not be happening very often, more like - never again. ;-) ...and thanks games team and everyone who provides & maintains games in Gentoo or did so in the past. Availability of top-class games was one of the things which attracted me to Gentoo (lots of years ago ;-) ). Portage being able chew original commercial CD-s blown my mind back then. I think this is unique to Gentoo and no other distro had ever possibility to install those games via package manager. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged
On 11/20/17 05:09, hero...@gentoo.org wrote:
[...]
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index 86bcd282479..76a622df698 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -103,6 +103,10 @@ egetent() {
> # Default uid is (pass -1 for this) next available, default shell is
> # /bin/false, default homedir is /dev/null, and there are no default groups.
> enewuser() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
maybe ewarn() is more appropriate than einfo()?
Just in case it's executed outside the scope of prefix
[...]
[gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged
Francesco Riosa writes: > maybe ewarn() is more appropriate than einfo()? > Just in case it's executed outside the scope of prefix I can't remember any use case when portage (or, paludis, etc.) is executed as a normal user but not a from Prefix. This message will only affect Prefix users, who won't be surprised that they cannot create new groups or users. Therefore I think einfo is more appropriate. Furthermore, we do have Prefix that runs as a root, mostly usable on NAS or smartphones, when we do ultimately like portage to manage groups and users. Benda
[gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged
Francesco Riosa writes: > maybe ewarn() is more appropriate than einfo()? > Just in case it's executed outside the scope of prefix I can't remember any use case when portage (or, paludis, etc.) is executed as a normal user but not a from Prefix. This message will only affect Prefix users, who won't be surprised that they cannot create new groups or users. Therefore I think einfo is more appropriate. Furthermore, we do have Prefix that runs as root, mostly usable on NAS or smartphones, when we do ultimately like portage to manage groups and users. Benda
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]
W dniu pon, 20.11.2017 o godzinie 22∶37 +0100, użytkownik Ulrich Mueller napisał: > > > > > > 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 of the text > referenced by them): > > > The Manifest files use UTF-8 encoding. > > I don't understand the purpose of that requirement. The only place > where bytes outside of the ASCII range can occur are names of > distfiles, and these should simply be passed transparently. Otherwise, > you would have to reject any sequence of non-ASCII bytes that doesn't > form a valid UTF-8 sequence, which looks like an arbitrary restriction > to me. Let me reply in parts. Why not plain ASCII? Because the spec tries to avoid entirely arbitrary restrictions, and forcing everyone to use just ASCII entirely counts as such. Why not plain bytestring? Mostly because it's really PITA to work on them in Python. Besides, you can't allow arbitrary bytestring since you still need to apply restrictions making it safe to parse in text context, i.e. forbid 0x20, 0x0A, possibly more. Which makes the definition kinda silly in the end. Not to mention transferring files over systems which can recode filenames but will not recode Manifest contents. Why UTF-8 then? Because it's quite reliable and widely established. It works for most of the people out of the box. Those who use other encodings can usually transcode reliably. It's what we're using in ebuilds and everywhere else wrt GLEP 31, so I don't think we should make Manifests any different. > > 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. > > What about regular files in a directory (or subdirectory) matched by > IGNORE? Looks like this case is not covered (?). Ignored regular files must not have any other (e.g. DATA) entries. Otherwise the expected behavior is unclear -- are we supposed to verify the file or ignore it? > > All paths specified in the Manifest file must consist of characters > > corresponding to valid UTF-8 code points excluding the NULL character > > (``U+``) and characters classified as whitespace in the current > > version of the Unicode standard [#UNICODE]_. It is an error to use > > Manifest files in directories containing files whose names contain > > the disallowed characters. > > See above. I believe that NUL and ASCII whitespace (i.e. characters 09 > 0a 0b 0c 0d 20) should be excluded, but excluding byte sequences like > "e1 9a 80" (which is the UTF-8 encoding for U+1680 "OGHAM SPACE MARK") > doesn't make sense. The restriction is meant to be intentionally wider to prevent problems with implementations which e.g. use Python's str.split() or '\S' regular expression character (Portage). When working in Unicode-compliant mode, those can match additional whitespace characters, and I'm rejecting them to be on the safe side. > > During the verification process, the client should compare the timestamp > > against the update time obtained from a local clock or a trusted time > > source. If the comparison result indicates that the Manifest at the time > > of receiving was already significantly outdated, the client should > > either fail the verification or require manual confirmation from user. > > s/from user./from the user./ > > > ``TIMESTAMP `` > > Specifies a timestamp of when the Manifest file was last updated. > > The timestamp must be a valid second-precision ISO8601 extended format > > s/ISO8601/ISO 8601/ Both done. > > > ``IGNORE `` > > Ignores a subdirectory or file from Manifest checks. If the specified > > path is present, it and its contents are omitted from the Manifest > > verification (always pass). *Path* must be a plain file or directory > > path without a trailing slash, and must not contain wildcards. > > What does that mean? Wildcards are not special (so "foo*" will match > literally), or wildcard characters like "*" are not allowed at all? Not special. Will reword to: | Wildcards are not supported and wildcard characters are interpreted | literally. > > > ``AUX ...`` > > Equivalent to the ``DATA`` type, except that the filename is relative > > to ``files/`` subdirectory. > > s/to/to the/ > > > 3. Process all ``MANIFEST`` entries, recursively. Verify the Manifest > >files according to `file verification`_ section, and include their > > s/according to/according to the/ > > > 6. Verify the entries in *covered* set for incompatible duplicates > > s/in *covered* set/in the *covered* set/ > > > 7. Verify all the files in the union of the *present* and *covered* > >sets, according to `file verification`_ section. > > s/t
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v3]
W dniu czw, 16.11.2017 o godzinie 11∶19 +0100, użytkownik Michał Górny napisał: > Hi, everyone. > > Here's the updated version of GLEP 74 taking into consideration > the points made during the Council pre-review. > > ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst > HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html > > Changes: > 5ba0654 glep-0074: Specify slash as path separator, disallow backwards slash d3b65ba glep-0074: Mention that newline needs to be restricted too in rationale 54cc3ef glep-0074: Apply suggestions from Ulrich Müller --- GLEP: 74 Title: Full-tree verification using Manifest files Author: Michał Górny , Robin Hugh Johnson , Ulrich Müller Type: Standards Track Status: Draft Version: 1 Created: 2017-10-21 Last-Modified: 2017-11-16 Post-History: 2017-10-26, 2017-11-16 Content-Type: text/x-rst Requires: 59, 61 Replaces: 44, 58, 60 --- Abstract This GLEP extends the Manifest file format to cover full-tree file integrity and authenticity checks. The format aims to be future-proof, efficient and provide means of backwards compatibility. Motivation == The Manifest files as defined by GLEP 44 [#GLEP44]_ provide the current means of verifying the integrity of distfiles and package files in Gentoo. Combined with OpenPGP signatures, they provide means to ensure the authenticity of the covered files. However, as noted in GLEP 57 [#GLEP57]_ they lack the ability to provide full-tree authenticity verification as they do not cover any files outside the package directory. In particular, they provide multiple ways for a third party to inject malicious code into the ebuild environment. Historically, the topic of providing authenticity coverage for the whole repository has been mentioned multiple times. The most noteworthy effort are GLEPs 58 [#GLEP58]_ and 60 [#GLEP60]_ by Robin H. Johnson from 2008. They were accepted by the Council in 2010 but have never been implemented. When potential implementation work started in 2017, a new discussion about the specification arose. It prompted the creation of a competing GLEP that would provide a redesigned alternative to the old GLEPs. This specification is designed with the following goals in mind: 1. It should provide means to ensure the authenticity of the complete repository, including preventing the injection of additional files. 2. The format should be universal enough to work both for the Gentoo repository and third-party repositories of different characteristics. 3. The Manifest files should be verifiable stand-alone, that is without knowing any details about the underlying repository format. Specification = Manifest file format This specification reuses and extends the Manifest file format defined in GLEP 44 [#GLEP44]_. For the purpose of it, the *file type* field is repurposed as a generic *tag* that could also indicate additional (non-checksum) metadata. Appropriately, those tags can be followed by other space-separated values. Unless specified otherwise, the paths used in the Manifest files are relative to the directory containing the Manifest file. The paths must not reference the parent directory (``..``). The Manifest files use UTF-8 encoding. Manifest file locations and nesting --- The ``Manifest`` file located in the root directory of the repository is called top-level Manifest, and it is used to perform the full-tree verification. In order to verify the authenticity, it must be signed using OpenPGP, using the armored cleartext format. The top-level Manifest may reference sub-Manifests contained in subdirectories of the repository. The sub-Manifests are traditionally named ``Manifest``; however, the implementation must support arbitrary names, including the possibility of multiple (split) Manifests for a single directory. The sub-Manifest can only cover the files inside the directory tree where it resides. The sub-Manifest can also be signed using OpenPGP armored cleartext format. However, the signature verification can be omitted since it already is covered by the signed top-level Manifest. Directory tree coverage --- The specification provides three ways of skipping Manifest verification of specific files and directories (recursively): 1. explicit ``IGNORE`` entries in Manifest files, 2. injected ignore paths via package manager configuration, 3. using names starting with a dot (``.``) which are always skipped. All files that are not ignored must be covered by at least one of the Manifests. A single file may be matched by multiple identical or equivalent Manifest entries, if and only if the entries have the same semantics, specify the same size and the checksums common to both entries match. 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 `
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v3]
> 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 of the Unicode standard > [#UNICODE]_. It is an error to use Manifest files in directories > containing files whose names contain the disallowed characters. > The forward slash (``/``) must be used as path separator. In addition to whitespace, you should also exclude C0 controls (U+ to U+001F), DEL (U+007F), and C1 controls (U+0080 to U+009F). Rationale, these control characters can leave the user's terminal in an unusable state when a package manager tries to output such a filename in a message. As you reserve the backslash for a future escape mechanism, this shouldn't be a too severe restriction. Ulrich pgpzrgA93CWHZ.pgp Description: PGP signature
Re: [gentoo-dev] manifest-hashes changing to 'BLAKE2B SHA512' on 2017-11-21
W dniu śro, 15.11.2017 o godzinie 17∶28 +0100, użytkownik Michał Górny napisał: > Hi, everyone. > > The Council has approved the manifest-hashes switch on 2017-11-12 > meeting [1]. The transition will occur to the initial plan, with small > changes. The updated plan is included at the end of this mail. > > According to this plan, BLAKE2B will be enabled on 2017-11-21. This > means that starting at this time, all new and updated DIST entries will > use BLAKE2B+SHA512. Old DIST entries will still use the current hash set > until updated. > > The developers are required to upgrade to a package manager supporting > this hash. That is: > > a. Portage 2.3.5 when using py3.6+, > > b. Portage 2.3.13 + pyblake2 installed manually, > > c. Portage 2.3.13-r1 that includes the pyblake2 dep. > > Modern (and old) Portage will refuse to update Manifests if it does not > support the necessary hashes. However, Portage versions between 2.3.5 > and 2.3.13 inclusively will create Manifests missing BLAKE2B hash rather > than failing when no hash provider is present. Those Manifests will be > rejected by the git hook. > > Users will not be affected noticeably as the SHA512 hash continues being > used for compatibility. > > > That said, I'd like to request developers not to start proactively > converting all old Manifest entries to the new set immediately, > and instead give some time for things to settle down. > > > > The updated plan > > > Already done: > > - revbumped Portage with pyblake2 dep and started stabilizing it, > > - added git update hook to reject invalid Manifest entries. > > 2017-11-21 (T+7d): > > - manifest-hashes = BLAKE2B SHA512 FYI, this is now online. Please ping me if you have any issues. > > 2018-02-14 (T+3m): > > - manifest-required-hashes = BLAKE2B > > 2018-05-14 (T+6m): > > - last rite fetch-restricted packages that do not use BLAKE2B. > > The final removal of SHA512 will be decided by the Council separately. > > -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v3]
W dniu wto, 21.11.2017 o godzinie 19∶20 +0100, użytkownik Ulrich Mueller napisał: > > > > > > 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 of the Unicode standard > > [#UNICODE]_. It is an error to use Manifest files in directories > > containing files whose names contain the disallowed characters. > > The forward slash (``/``) must be used as path separator. > > In addition to whitespace, you should also exclude C0 controls (U+ > to U+001F), DEL (U+007F), and C1 controls (U+0080 to U+009F). > > Rationale, these control characters can leave the user's terminal > in an unusable state when a package manager tries to output such a > filename in a message. As you reserve the backslash for a future > escape mechanism, this shouldn't be a too severe restriction. > Works for me. I'll update the spec later. Can you think of any other sequences that should be explicitly forbidden? -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]
> 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. >> >> What about regular files in a directory (or subdirectory) matched >> by IGNORE? Looks like this case is not covered (?). > Ignored regular files must not have any other (e.g. DATA) entries. > Otherwise the expected behavior is unclear -- are we supposed to > verify the file or ignore it? I still believe that the wording doesn't convey that. Maybe an example will clarify what I mean. There is a directory foo/bar and a regular file foo/bar/quux in it. Now in Manifest there are these entries: IGNORE foo/bar DATA foo/bar/quux The spec says: "It is an error to specify another entry for a file matching ``IGNORE``, or one of its subdirectories." However, file foo/bar/quux neither matches IGNORE nor is a subdirectory of it. Ulrich pgpXTymAHtpjt.pgp Description: PGP signature
[gentoo-dev] Packages up for grabs
Packages up for grabs: * app-crypt/yubikey-manager-qt * sys-apps/etckeeper * sys-auth/yubico-piv-tool * dev-libs/libsodium * app-editors/retext * sys-apps/rkflashtool * dev-embedded/esptool * app-shells/thefuck * app-crypt/paperkey * dev-util/bumpversion * dev-python/python-afl * dev-python/pyotherside * dev-util/docker-distribution-pruner signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]
W dniu wto, 21.11.2017 o godzinie 21∶28 +0100, użytkownik Ulrich Mueller napisał: > > > > > > 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. > > > > > > What about regular files in a directory (or subdirectory) matched > > > by IGNORE? Looks like this case is not covered (?). > > Ignored regular files must not have any other (e.g. DATA) entries. > > Otherwise the expected behavior is unclear -- are we supposed to > > verify the file or ignore it? > > I still believe that the wording doesn't convey that. Maybe an example > will clarify what I mean. > > There is a directory foo/bar and a regular file foo/bar/quux in it. > Now in Manifest there are these entries: > >IGNORE foo/bar >DATA foo/bar/quux > > The spec says: "It is an error to specify another entry for a file > matching ``IGNORE``, or one of its subdirectories." However, file > foo/bar/quux neither matches IGNORE nor is a subdirectory of it. Indeed, the second part of that sentence needs to change. Do you have a suggestion how to word it best? -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]
> 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. >> [...] > Indeed, the second part of that sentence needs to change. Do you > have a suggestion how to word it best? "It is an error to specify another entry for a file that matches ``IGNORE`` or that is covered by an ignored directory." Ulrich pgpaRRJ0Ujxpx.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]
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 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. > > > [...] > > Indeed, the second part of that sentence needs to change. Do you > > have a suggestion how to word it best? > > "It is an error to specify another entry for a file that matches > ``IGNORE`` or that is covered by an ignored directory." > I'm not sure if 'covered' wouldn't be confusing here. Maybe: | It is an error to specify another entry for a file that matches | ``IGNORE``, or that is located inside an ignored directory. ? -- Best regards, Michał Górny
Re: [gentoo-dev] Packages up for grabs
> On Nov 21, 2017, at 1:01 PM, Manuel Rüger wrote: > > Packages up for grabs: > > ... > * dev-libs/libsodium I’d take this one, since I’m proxy-maintaining net-dns/dnscrypt-proxy by the same upstream and libsodium is a direct dependency of net-dns/dnscrypt-proxy. Regards, Georgy.
Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged
On 2017-11-21 03:19 AM, Benda Xu wrote: > Francesco Riosa writes: > >> maybe ewarn() is more appropriate than einfo()? >> Just in case it's executed outside the scope of prefix > > I can't remember any use case when portage (or, paludis, etc.) is > executed as a normal user but not a from Prefix. > > This message will only affect Prefix users, who won't be surprised that > they cannot create new groups or users. Therefore I think einfo is more > appropriate. > > > Furthermore, we do have Prefix that runs as a root, mostly usable on NAS > or smartphones, when we do ultimately like portage to manage groups and > users. I use portage as non-root all the time when developing and testing ebuilds, via the "ebuild" command.
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]
On Mon, Nov 20, 2017 at 12:42 PM, Michał Górny wrote: > W dniu czw, 16.11.2017 o godzinie 11∶19 +0100, użytkownik Michał Górny > napisał: >> Hi, everyone. >> >> Here's the updated version of GLEP 74 taking into consideration >> the points made during the Council pre-review. >> >> ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst >> HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html >> > > New changes: > > 9d819c9 glep-0074: Disallow filenames containing whitespace This seems like a bad idea. I apologize if this is covered in more detail somewhere, but the only justification I can see is that the current grammar does not permit quoting or some other method of specifying whitespace as part of a field value. Is there any way to assure that this won't break things in a non-obvious way? I'm having a hard time imagining how it would be an inflexible requirement to use a space in a filename, but it could come up if it was necessary to use Portage on a non-Gentoo distribution. It seems very arbitrary. I think the better solution is to use a better parser. Cheers, R0b0t1
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]
> 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 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. >> > > [...] >> > Indeed, the second part of that sentence needs to change. Do you >> > have a suggestion how to word it best? >> >> "It is an error to specify another entry for a file that matches >> ``IGNORE`` or that is covered by an ignored directory." > I'm not sure if 'covered' wouldn't be confusing here. Indeed, that verb can have many meanings. > Maybe: > | It is an error to specify another entry for a file that matches > | ``IGNORE``, or that is located inside an ignored directory. > ? Works for me. Ulrich pgpTdGqgXiMnT.pgp Description: PGP signature
[gentoo-dev] News Item: Old Wine Versions Moving to Wine Overlay
Would like to get this out within the next day if no-one sees any issues. Thanks! Title: Old Wine versions moving to wine-overlay Author: NP-Hardass Content-Type: text/plain Posted: 2017-11-21 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-emulation/wine:0 Display-If-Installed: app-emulation/wine-vanilla Display-If-Installed: app-emulation/wine-staging Display-If-Installed: app-emulation/wine-d3d9 Display-If-Installed: app-emulation/wine-any To reduce the burden on main Gentoo repository, older versions of Wine will be available only in the wine overlay. These ebuilds will still be fully supported by the Gentoo Wine Project. This will result in upstream stable releases and the several most recent upstream devel releases being the only versions in ::gentoo; all versions meeting the criteria for support within Gentoo [1] will be available in ::wine. To install the overlay you can either add the repos.conf file to your portage configuration directory or add the repository via layman. * To add the repos.conf file: # wget https://gitweb.gentoo.org/repo/proj/wine.git/plain/wine.conf -O \ /etc/portage/repos.conf/wine.conf Edit the /etc/portage/repos.conf/wine.conf file so that "location" points to your desired folder to install the overlay. # emaint sync --repo wine * To install the overlay via layman: # layman -a wine [1] https://wiki.gentoo.org/wiki/Project:Wine/Policies_and_Procedures#Supported_versions -- NP-Hardass signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: Old Wine Versions Moving to Wine Overlay
W dniu śro, 22.11.2017 o godzinie 01∶55 -0500, użytkownik NP-Hardass napisał: > Would like to get this out within the next day if no-one sees any issues. > > Thanks! > Title: Old Wine versions moving to wine-overlay > Author: NP-Hardass > Content-Type: text/plain > Posted: 2017-11-21 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: app-emulation/wine:0 > Display-If-Installed: app-emulation/wine-vanilla > Display-If-Installed: app-emulation/wine-staging > Display-If-Installed: app-emulation/wine-d3d9 > Display-If-Installed: app-emulation/wine-any > > To reduce the burden on main Gentoo repository, older versions of Wine > will be available only in the wine overlay. These ebuilds will still be > fully supported by the Gentoo Wine Project. This will result in > upstream stable releases and the several most recent upstream devel > releases being the only versions in ::gentoo; all versions meeting the > criteria for support within Gentoo [1] will be available in ::wine. > > To install the overlay you can either add the repos.conf file to your > portage configuration directory or add the repository via layman. What about eselect-repository? ;-P > * To add the repos.conf file: > # wget https://gitweb.gentoo.org/repo/proj/wine.git/plain/wine.conf -O \ Infra strongly discourages fetching straight from cgit. This is not guaranteed to be stable. > /etc/portage/repos.conf/wine.conf > > Edit the /etc/portage/repos.conf/wine.conf file so that "location" > points to your desired folder to install the overlay. > # emaint sync --repo wine > > * To install the overlay via layman: > # layman -a wine It's kinda surprising to see this after the repos.conf solution since it was mentioned first. > > [1] > https://wiki.gentoo.org/wiki/Project:Wine/Policies_and_Procedures#Supported_versions -- Best regards, Michał Górny
