[gentoo-dev] Last rites: xemacs-elisp{,-common}.eclass
# @DEAD # Ulrich Müller (2019-12-16) # No longer used by any ebuild in the Gentoo repository. # Removal in 30 days. signature.asc Description: PGP signature
[gentoo-dev] Last rites: git-2.eclass
# Almost all consumers gone, the remaining two are last-rited. # Removal in 14 days. git-2.eclass -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: x11-libs/fox:1.6, x11-misc/xfe
# Michał Górny (2019-12-16) # Old slot of unmaintained x11-libs/fox. Last touched in 2015, pending # bump since. x11-misc/xfe is the only revdep. # Removal in 30 days. Bug #703084. x11-libs/fox:1.6 x11-misc/xfe -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] Re: RFC: [QA] notice with 'failed' seds [was PATCH: eapply drop -s option]
On Sun, 2019-12-15 at 13:29 -0800, Zac Medico wrote:
> On 12/13/19 2:12 PM, Michael 'veremitz' Everitt wrote:
> > On 13/12/19 20:36, Michał Górny wrote [excerpted]:
> > > Is this really an argument for or *against* it? Developers are entirely
> > > capable of keeping seds that do nothing for years, as well as patches
> > > that -- while apparently applying correctly -- are entirely meaningless.
> >
> >
> > I think there is some merit in some kind of feedback when sed's are doing
> > nothing, although how feasible it is to generate any useful feedback I
> > can't say. I wouldn't say it needs to explicitly fail or make lots of
> > noise, just an info message that could prompt some further investigation.
> >
>
> It's possible to implement a sed wrapper that detects file arguments for
> -i/--in-place mode, and compares file content before and after the sed call.
>
> There are also ways to make sed exit with an error but that won't be as
> easy to use as a sed wrapper:
>
> https://stackoverflow.com/questions/15965073/return-code-of-sed-for-no-match/15966279
Don't forget that there could be valid cases for sed not changing
a file. Not to mention corner cases where a working replacement results
in no change, e.g.:
# yuck!
sed -i -e "s^-O2^${CFLAGS}^" ...
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-editors/adie, dev-util/reswrap, media-sound/gogglesmm, sci-calculators/calculator, x11-libs/fox, x11-misc/pathfinder, x11-misc/shutterbug
# Michał Górny (2019-12-16) # All of FOX Toolkit packages are unmaintained. The library was last # bumped in Jan 2016, and is pending bump since. Other packages are # even more behind. Including media-sound/gogglesmm as the only revdep. # Removal in 30 days. Bug #703088. app-editors/adie dev-util/reswrap media-sound/gogglesmm sci-calculators/calculator x11-libs/fox x11-misc/pathfinder x11-misc/shutterbug -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction
Il giorno lun 16 dic 2019 alle ore 13:39 Michał Górny ha scritto: > > > Comments > > WDYT? > > what about getting rid of RESTRICT="fetch" and manage everything inside SRC_URI? Would that be technically feasible? Ideally marking only the not re-distributable download and leaving untouched the others
[gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction
Hello, everyone. I'd like to start a series of mails dedicated to features proposed for including in EAPI 8. For a start, I'd like to discuss the topic of selective fetch restriction [1]. It has been discussed at least in 2013 [2], and since it's finally got chance to be included, I think it's worthwhile to rehash it. The problem === Fetch/mirror restriction as of now can only be applied to all distfiles at once. This causes problems in the (rather rare) case when we'd like to add some additional files to SRC_URI that do not require the big restriction. As a result, the user is forced to manually fetch all the files even if only one truly requires it. Proposed solution = The current proposal is based on extending the current URI syntax to permit excluding individual files from the restriction. The idea is to prepend 'fetch+' to protocol to undo fetch restriction, or to prepend 'mirror+' to undo fetch & mirror restrictions. Example 1: removing mirror restriction from files RESTRICT="mirror" SRC_URI="https://example.com/you-cant-mirror-this.tar.bz2 mirror+https://example.com/but-you-can-mirror-this.tar.gz; Example 2: removing fetch & mirror restriction from files RESTRICT="fetch" SRC_URI="https://example.com/you-cant-fetch-this.zip mirror+https://example.com/but-you-can-mirror-this.tar.gz; Example 3: removing fetch restriction while leaving mirror restriction RESTRICT="fetch" SRC_URI="https://example.com/you-cant-fetch-this.zip fetch+https://example.com/you-cant-mirror-this.tar.bz2; Comments WDYT? References == [1] https://bugs.gentoo.org/371413 [2] https://archives.gentoo.org/gentoo-dev/message/b0823618d5d3cc61bbed1e88dc2f144d -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction
> On Mon, 16 Dec 2019, Francesco Riosa wrote: > what about getting rid of RESTRICT="fetch" and manage everything > inside SRC_URI? Would that be technically feasible? Ideally marking > only the not re-distributable download and leaving untouched the > others That would have the disadvantage that mirror and bindist restrictions (which are strongly correlated) would be listed in different places. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)
* Michael Orlitzky: > I'm sure someone will object to the name acct-user/_milter-regex, but > that would be the easiest option, being the upstream default. Admittedly, _milter-regex makes me wince. It displeases my sense of aesthetics and affects sorting order in acct-*. I'd like to lose the underscore, and I'd be willing to tweak mail-filter/milter-regex to change Gentoo's default to milter-regex as well. "Everybody benefits!" (Markos, The Con of Kos) -Ralph
Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction
> On Mon, 16 Dec 2019, Michał Górny wrote: > Proposed solution > = > The current proposal is based on extending the current URI syntax to > permit excluding individual files from the restriction. The idea is to > prepend 'fetch+' to protocol to undo fetch restriction, or to prepend > 'mirror+' to undo fetch & mirror restrictions. > Example 1: removing mirror restriction from files > RESTRICT="mirror" > SRC_URI="https://example.com/you-cant-mirror-this.tar.bz2 > mirror+https://example.com/but-you-can-mirror-this.tar.gz; > Example 2: removing fetch & mirror restriction from files > RESTRICT="fetch" > SRC_URI="https://example.com/you-cant-fetch-this.zip > mirror+https://example.com/but-you-can-mirror-this.tar.gz; > Example 3: removing fetch restriction while leaving mirror restriction > RESTRICT="fetch" > SRC_URI="https://example.com/you-cant-fetch-this.zip >fetch+https://example.com/you-cant-mirror-this.tar.bz2; Looks good, but what is slightly confusing is that it doesn't map one-to-one to the RESTRICT tokens: - RESTRICT="mirror" enables mirror restriction, and it is undone by "mirror+", as expected. - RESTRICT="fetch" enables both fetch and mirror restriction, but it is undone by "mirror+" as well, not by "fetch+" (which disables only fetch restriction). I had already asked this in bug 371413 [1], but is there an actual usage case for example 3? Because if there isn't, we might get away with only supporting "mirror+", which should be less error prone. Ulrich > [1] https://bugs.gentoo.org/371413 signature.asc Description: PGP signature
Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction
On Mon, Dec 16, 2019 at 8:33 AM Ulrich Mueller wrote: > > > On Mon, 16 Dec 2019, Francesco Riosa wrote: > > > what about getting rid of RESTRICT="fetch" and manage everything > > inside SRC_URI? Would that be technically feasible? Ideally marking > > only the not re-distributable download and leaving untouched the > > others > > That would have the disadvantage that mirror and bindist restrictions > (which are strongly correlated) would be listed in different places. An obvious way to address that is to also move the mirror restriction into SRC_URI, so that they are both exclusively in this location as well. I believe those are the only two redistribution-oriented options for RESTRICT currently. -- Rich
[gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
Penny for your thoughts, guys: I am thinking about splitting the video_cards_i965 condition in virtual/opencl so that NEO is pulled in by video_cards_iris instead, and I wonder if there is anything I haven't thought about. The reason why I would like to do this is that there is clear correspondence between compatibility matrices of the Iris OpenGL driver and the NEO OpenCL driver - both only work on Broadwell and newer. There are differences of course, most notably that the old OpenCL driver (Beignet) is already considered deprecated for systems supported by NEO whereas the old OpenGL driver in Mesa (i965) is still the official one even for newer systems. Nb. to the best of my knowledge it is safe to set VIDEO_CARDS=iris even globally because if both i965 and iris are available, Mesa for now still prefers the former unless the environment variable MESA_LOADER_DRIVER_OVERRIDE has been set to 'iris'. There would of course have to be a news item advising the users of virtual/opencl + dev-libs/intel-neo to adjust their USE flags. What do you think, guys? -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: acct-user/... modifies existing user sometimes
On 12/15/19 5:31 PM, Michael Orlitzky wrote: Without more information, all I can say is that there's probably a better way to do whatever these users are doing that doesn't involve modifying a system user. But regardless, Michał's answer is the right one if you decide that you do want to modify it. Your observation is correct. This package I am working with "mythtv" has been around for years. Users customize it incorrectly and once working are reluctant to change it. They still want to upgrade to get features/bug fixes. I am guilty of improper use of the mythtv user myself. There is a lot of old documentation that uses it improperly. I am reluctant to introduce unexpected changes to old systems. This update will force consideration that maybe the mythtv user is being misused; while manually restoring (or creating a custom overlay) after acct-user/mythtv is emerged on the system. Once installed acct-user/mythtv is not usually reinstalled. It should not need manual restoration often.
