Re: [gentoo-dev] Changing policy about -Werror

On Wed, Sep 12, 2018 at 6:55 PM Thomas Deutschmann wrote: > > On 2018-09-12 16:50, Rich Freeman wrote: > > There is also the case where we want these warnings to block > > installation, because the risk of there being a problem is too great. > > I really disagree with

Re: [gentoo-dev] Changing policy about -Werror

On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn wrote: > > Alon Bar-Lev schrieb: > > We > > are unique as permutations and architectures that are used by Gentoo > > users are so diverse that we find issues that nobody else finds. > > This needs to be highlighted more, as it is why sug

Re: [gentoo-dev] Changing policy about -Werror

On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote: > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote: > > Now, I could buy that -Werror turns NEW warnings into fatal errors, > > due to the use of a newer toolchain, since upstream probably didn't > > test

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

On Wed, Sep 12, 2018 at 7:35 PM Chí-Thanh Christopher Nguyễn wrote: > > > Requirements: > > * Do not fail to build/install when a warning is encountered On a particularly critical package like a filesystem, wouldn't we want to still fail to install when a warning is encountered? > Also possible

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

On Wed, Sep 12, 2018 at 8:23 PM Chí-Thanh Christopher Nguyễn wrote: > > Rich Freeman schrieb: > >> Requirements: > >> > >> * Do not fail to build/install when a warning is encountered > > > > On a particularly critical package like a filesystem, would

Re: [gentoo-dev] Changing policy about -Werror

On Thu, Sep 13, 2018 at 9:29 AM Mike wrote: > > And I apologize for writing that commit rights were requested to be > removed. My mistake, bugzilla access rights were asked to be removed. >... > > I'm not a fan of more and more and more regulation that I see. Sorry if > you don't like that opini

Re: [gentoo-dev] Changing policy about -Werror

On Fri, Sep 14, 2018 at 1:22 PM Alon Bar-Lev wrote: > > Let's do this the other way around and be react based on facts and not > speculations. > Let's change the policy for a year for selected packages as I > outlined, monitor bugs and after a year see response times, affected > users and if downs

Re: [gentoo-dev] Changing policy about -Werror

On Fri, Sep 14, 2018 at 1:33 PM Michał Górny wrote: > > On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote: > > Let's do this the other way around and be react based on facts and not > > speculations. > > Let's change the policy for a year for selected packages as I > > outlined, monitor bugs a

Re: [gentoo-dev] Changing policy about -Werror

On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote: > > On 09/14/2018 03:58 PM, Richard Yao wrote: > >> > >> No one has answered the question: what do you do when a stable package > >> breaks because of a new warning? > >> > >> ...> > > Wouldn’t this be largely covered as part of GCC stabiliza

Re: [gentoo-dev] Signed-off-by verification incoming

On Sat, Sep 29, 2018 at 9:25 AM Dirkjan Ochtman wrote: > > Some kind of repoman support would make this much easier to handle. As > it is, doing this by hand for the trivial case (only my own changes) > is a PITA. repoman could grow some kind of --sign-off option that > appends this to the commit

Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

On Thu, Oct 11, 2018 at 1:14 PM Thomas Deutschmann wrote: > > But that's not the point here. The point was to get some attention that > again we have a lacking architecture (net-dns/dnssec-root is not the > only package where ARM arch team is lacking behind) which affects anyone > "trusting" someh

Re: [gentoo-dev] Is there any way I can help with pull requests?

On Sat, Oct 13, 2018 at 8:59 AM James Le Cuirot wrote: > > On Sat, 13 Oct 2018 13:28:02 +0200 > Ralph Seichter wrote: > > > Is there any way I could help the Gentoo team? Any vacancies that need > > to be filled, or work that needs to be done? > > Following what I said above, we need more actual

Re: [gentoo-dev] Is there any way I can help with pull requests?

On Tue, Oct 16, 2018 at 3:14 PM Ralph Seichter wrote: > > I followed the PHP team's recommendation, as can be seen from the PR > conversation and from the underlying Bugzilla report. While I respect > Michał Górny's opinion, I understand that he does not have a deciding > vote in this case. He sa

Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

On Sat, Oct 20, 2018 at 8:19 AM Andreas Sturmlechner wrote: > > On Freitag, 12. Oktober 2018 14:50:55 CEST Rich Freeman wrote: > > ARM is not a Gentoo security supported arch. > > > > If the ARM maintainers feel that stable keywords make the lives of > > their user

Re: [gentoo-dev] Unmasking >=media-video/ffmpeg-4.0

On Tue, Nov 6, 2018 at 10:57 AM Alexis Ballier wrote: > > On Tue, 06 Nov 2018 17:08:22 +0200 > Mart Raudsepp wrote: > > > It is not GStreamer fault that ffmpeg breaks API and ABI without > > parallel installability, much less so the distro maintainers of it. > > If you/upstream don't make it para

Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format

On Sat, Nov 17, 2018 at 9:05 AM Roy Bamford wrote: > > Does this proposal allow for installing the payload without > the use of the Gentoo package manager from some random > distro being used as a rescue media? > Yes, it is a tarball of tarballs. There would be an extra step, but a vanilla tarba

Re: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gen...@jonesmz.com]

On Sun, Nov 18, 2018 at 4:10 PM Roy Bamford wrote: > > Replying off list because I am not on the whitelist. That seems odd. > 1) append a uuid to each filename. Generated when the bin package file is > generated. > 2) encode the hostname of the machine that generated the file > 3) encode the us

Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gen...@jonesmz.com]

On Sun, Nov 18, 2018 at 5:40 PM Zac Medico wrote: > > On 11/18/18 1:55 PM, Rich Freeman wrote: > > > > My idea is to basically have portage generate a tag with all the info > > needed to identify the "right" package, take a hash of it, and then > > stick

Re: [gentoo-dev] [pre-GLEP r1] Gentoo binary package container format

On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford wrote: > > "The archive members support optional OpenPGP signatures. > The implementations must allow the user to specify whether OpenPGP > signatures are to be expected in remotely fetched packages." > > Or can the user specify that only some elements n

Re: [gentoo-dev] [pre-GLEP r1] Gentoo binary package container format

On Mon, Nov 19, 2018 at 2:40 PM Zac Medico wrote: > > On 11/19/18 11:33 AM, Rich Freeman wrote: > > On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford wrote: > >> > >> "The archive members support optional OpenPGP signatures. > >> The implementations mu

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 10:16 AM Michał Górny wrote: > > Will that actually solve any problem, or just add another half-baked > solution with no benefit to the resulting status? In other words, would > SIE suddenly stop requiring you to alter copyright in ebuilds? ++ It makes sense to ensure th

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 11:59 AM Matt Turner wrote: > > On Tue, Nov 27, 2018 at 7:41 AM Rich Freeman wrote: > > It makes sense to ensure that the solution actually solves the problem > > before we simply implement it. > > > > If we really need such a file it would

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 12:31 PM William Hubbs wrote: > > Agreed, we should not add every developer to this file by default. > Isn't this basically giving the most credit to the most difficult-to-work-with entities by default? As others have pointed out, it seems like other projects are moving a

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 2:58 PM Matt Turner wrote: > > What Copyright-owner header are you talking about? We would create one, just as we've created bugzilla tags in git for closing bugs/etc. Surely putting one line in a commit is no more difficult than putting one file in a repository? Indeed

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 3:15 PM Michał Górny wrote: > > On Tue, 2018-11-27 at 14:07 -0600, William Hubbs wrote: > > All, > > I just picked a random msg to reply to on the thread. > > > > Here is the updated AUTHORS file I would like to commit. > > > > You should include at least all current develo

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 3:23 PM William Hubbs wrote: > > On Tue, Nov 27, 2018 at 09:15:08PM +0100, Michał Górny wrote: > > On Tue, 2018-11-27 at 14:07 -0600, William Hubbs wrote: > > > All, > > > I just picked a random msg to reply to on the thread. > > > > > > Here is the updated AUTHORS file I w

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 3:34 PM Michał Górny wrote: > > Please don't forget we're talking about Gentoo, so brace for 2 weeks of > bikeshedding over whether first or last name should come first. > Thank goodness there isn't a Mike Gordon on the rolls or we could discuss the intricacies of UTF-8 or

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 3:42 PM Kent Fredric wrote: > > That git manages not to die every day based on what we throw at it is > frankly a miracle of engineering. Our repo is a linked list being constantly manipulated from the head backed by a hashed object store for the contents. For that use ca

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 4:50 PM Matt Turner wrote: > > Or, I don't know. Come up with something better and continue > bikeshedding. I won't. > I think antarus already came up with something better - let Sony explain its thinking, rather than trying to guess at what they're trying to accomplish an

Re: [gentoo-dev] AUTHORS file for portage repository

On Tue, Nov 27, 2018 at 5:49 PM Michał Górny wrote: > > On Tue, 2018-11-27 at 16:01 -0500, Rich Freeman wrote: > > On Tue, Nov 27, 2018 at 3:42 PM Kent Fredric wrote: > > > > > > That git manages not to die every day based on what we throw at it is > >

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

On Fri, Feb 22, 2019 at 9:58 PM Matthew Thode wrote: > > Ok, after setting that up portage wants to update pgp keys, which fail > because keyservers suck. It doesn't look like we can change the > keyservers or disable the update entirely but we can set the retries to > 0 (which better disable it.

Re: [gentoo-dev] rfc: cron.* and modern cron implementations

On Sat, Mar 2, 2019 at 7:05 PM William Hubbs wrote: > > someone brought this up on the chat channel today, so I'm bringing it > here to ask for information. > > Is there a reason we still use run-parts and the > /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs? > > From

Re: [gentoo-dev] rfc: cron.* and modern cron implementations

On Sat, Mar 2, 2019 at 7:26 PM Michael Orlitzky wrote: > > On 3/2/19 7:05 PM, William Hubbs wrote: > > > > Is there a reason we still use run-parts and the > > /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron > > jobs? > > > > From what I read in the chat earlier, it sounds

Re: [gentoo-dev] rfc: cron.* and modern cron implementations

On Sat, Mar 2, 2019 at 8:25 PM Michael Orlitzky wrote: > > Using run-parts in /etc/crontab also has its problems, but I don't have > a solution handy for that one. Using run-parts runs those daily, weekly, > etc. jobs as root, which may not be what you want if you're operating on > user-controlled

Re: [gentoo-dev] [PATCH] glep-0063: Require encryption subkey, and make primary certify-only

On Sun, Feb 24, 2019 at 3:35 AM Michał Górny wrote: > > Following the recent mailing list discussion indicating that developers > are taking GLEP 63 as only source of truth about OpenPGP keys, and can > make assumption that if encryption key is not listed there they should > not have one. Amend t

[gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

I just generated a gpg key on my nitrocard using the default options, as I could not find any other official recommendations for how to create a key. However, it appears that the default config uses the same signing and primary key, and thus generates a warning when pushing to the main repo. What

[gentoo-dev] Last rites: games-rpg/eternal-lands

Removing this one as the maintainer, but would be happy to work with a proxy maintainer if somebody wants to take over. I suspect it isn't actually in-use... # Richard Freeman (24 Apr 2019) # Masked for removal in 30 days. Likely does not work # and is essentially unmainted. Please comment in

[gentoo-dev] Last rites: games-rpg/eternal-lands

Removing this one as the maintainer, but would be happy to work with a proxy maintainer if somebody wants to take over. I suspect it isn't actually in-use... # Richard Freeman (24 Apr 2019) # Masked for removal in 30 days. Likely does not work # and is essentially unmainted. Please comment in

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

On Wed, Apr 24, 2019 at 10:01 AM Marek Szuba wrote: > > On 2019-04-24 13:41, Rich Freeman wrote: > > > What is the recommended way to create an on-card key? > > I haven't got my NitroKey yet but between the specifications (which say > NK2 can hold up to 3 private RSA

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

On Wed, Apr 24, 2019 at 10:25 AM Alon Bar-Lev wrote: > > On Wed, Apr 24, 2019 at 5:19 PM Rich Freeman wrote: > > Well, in that case recommendations for how to generate a key that > > complies in software would be helpful. There used to be a wiki > > article on it, but i

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

On Wed, Apr 24, 2019 at 11:57 AM Kristian Fiskerstrand wrote: > > On 4/24/19 4:19 PM, Rich Freeman wrote: > > If it is the case that Nitrokeys can't support a separate primary key, > > I'd suggest modifying the GLEP to remove that requirement when a > > smartca

[gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that are being distributed to Gentoo developers, do not support having a separate primary/signing key for keys that are generated on the cards. As a result they can only be used in accordance with our current requirements if the keys a

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

On Thu, Apr 25, 2019 at 7:57 AM Marek Szuba wrote: > > On 2019-04-24 20:34, Rich Freeman wrote: > > > The only reason to have a separate primary key is to have an offline > > copy, > > Not quite. First and foremost, you don not want to have an offline copy > of the

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

On Thu, Apr 25, 2019 at 4:34 PM James Le Cuirot wrote: > > On Thu, 25 Apr 2019 11:30:27 -0400 > Alec Warner wrote: > > > > Seeing as separating the primary and the signing key has been part of > > > OpenPGP best practices for a long, long time, I have got highly mixed > > > feelings about this st

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

On Thu, Apr 25, 2019 at 4:55 PM Kristian Fiskerstrand wrote: > > Quite frankly I'd expect a Gentoo Developer to be able to manage the gpg > interface. > Being able to is not the same as caring enough to be bothered with it... I don't want to custom-tailor my Gentoo key. I just want to generate

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

On Thu, Apr 25, 2019 at 5:54 PM James Le Cuirot wrote: > > if I understood it correctly, it only removes the primary private key > from the online copy and not the entire primary key. The --list-keys > option shows an [SC] primary with an [E] subkey and an [S] subkey and I > gathered from a conver

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

On Thu, Apr 25, 2019 at 6:29 PM Kristian Fiskerstrand wrote: > > On 4/26/19 12:26 AM, Rich Freeman wrote: > > I mean, I'd expect any Gentoo dev to be able to figure out how to use > > git as well, but git also has a terrible command line interface, > > Not really, i

Re: [gentoo-dev] Gentoo on Discord

On Tue, Apr 30, 2019 at 1:22 PM Kristian Fiskerstrand wrote: > > It matters if things are perceived as official Gentoo and causing a > negative reputation as in the article in this thread. One some level > that actually goes to trademark infringement that should be of interest > to the foundation,

Re: [gentoo-dev] rfc: making sysvinit optional

On Wed, Jul 10, 2019 at 8:03 PM William Hubbs wrote: > > On Wed, Jul 10, 2019 at 07:30:57PM -0400, Michael Orlitzky wrote: > > On 7/10/19 7:16 PM, William Hubbs wrote: > > > 3. add a sysvinit use flag to openrc, which will be off by default. When > > > it is on, openrc will block sysvinit since it

Re: [gentoo-dev] rfc: making sysvinit optional

On Wed, Jul 10, 2019 at 11:02 PM William Hubbs wrote: > > > RDEPEND="sysv-utils? ( !sys-apps/sysvinit ) > > !sysv-utils? ( sys-apps/sysvinit )" > > I like this, but the second branch (!sysv-utils) is not really needed, > because if we put sysvinit as the first RDEPEND of virtual/init, w

Re: [gentoo-dev] rfc: making sysvinit optional

On Thu, Jul 11, 2019 at 11:56 AM William Hubbs wrote: > > On Thu, Jul 11, 2019 at 09:42:02AM -0400, Rich Freeman wrote: > > On Wed, Jul 10, 2019 at 11:02 PM William Hubbs wrote: > > > > > > > RDEPEND="sysv-utils? ( !sys-apps/sysvinit ) > > &

Re: [gentoo-dev] rfc: making sysvinit optional

On Thu, Jul 11, 2019 at 1:22 PM William Hubbs wrote: > > On Thu, Jul 11, 2019 at 12:46:02PM -0400, Rich Freeman wrote: > > On Thu, Jul 11, 2019 at 11:56 AM William Hubbs wrote: > > > > > > On Thu, Jul 11, 2019 at 09:42:02AM -0400, Rich Freeman wrote: > >

Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

On Sat, Jul 20, 2019 at 2:28 PM Michał Górny wrote: > > Could you please read the proposed policy? It explicitly says you are > *not* supposed to force extra deps on users but build manpages for them. > This seems like a significant increase in maintainer effort compared to just leaving things a

Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

On Sat, Jul 20, 2019 at 4:22 PM Michał Górny wrote: > > > Yes, I get it. User experience is not important if it would mean > developers would actually do anything but the bare minimum to get > from one paycheck to another. The usual Gentoo attitude. > Not sure where I go to sign up for those pa

Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

On Mon, Jul 22, 2019 at 8:35 AM Kent Fredric wrote: > > Though I suspect *literally* using USE flags for this as-is might be > the wrong approach, as that just causes user-side pollution :/ > Maybe in some other situations this might be true, but as I mentioned in my previous email, users who DO

Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

On Tue, Oct 8, 2019 at 7:57 AM Michael Palimaka wrote: > > On 10/8/19 7:21 AM, Andreas K. Huettel wrote: > > In any case, since many people *do* rely on it, maybe we should declare it > > official? [+] > > > > And, if that's OK with both of you, move it onto infra hardware? > > > > Happy to sponso

Re: [gentoo-dev] New distfile mirror layout

On Mon, Oct 21, 2019 at 12:42 PM Richard Yao wrote: > > Also, another idea is to use a cheap hash function (e.g. fletcher) and just > have the mirrors do the hashing behind the scenes. Then we would have the > best of both worlds. I think something that is getting missed in this discussion is t

[gentoo-dev] Re: [RFC] News Item: Desktop profile switching USE default to elogind

On Sun, Oct 27, 2019 at 10:19 PM Andreas Sturmlechner wrote: > > Enter the elogind project [2], which is a standalone logind implementation > based on systemd code, currently maintained by a fellow Gentoo user. A few minor comments: 1. While it is somewhat implicit in the headers, you might wan

Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

On Fri, Nov 1, 2019 at 4:36 PM Matt Turner wrote: > > On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt > wrote: > > > > > > Therefore, it would be much /more/ useful to have the package-version > > tagged in the commit message, so that you could easily grep logs for when a > > given ver

Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

On Fri, Nov 1, 2019 at 5:34 PM Michael 'veremitz' Everitt wrote: > > > git log --format=oneline glibc-2.29-r2.ebuild | grep stable > > > How well does git handle that when the ebuild is deleted from the tree? > git log --format=oneline -- glibc-2.29-r4.ebuild 23d1c015230d9ff44bcdd7b72e00ca3533815

Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

On Fri, Nov 15, 2019 at 3:05 AM Michał Górny wrote: > > On Wed, 2019-11-13 at 22:16 +0100, Michał Górny wrote: > > I'd like to share my frustration at the state of Python in general, > > and Python packages in Gentoo. So I'd like to 'bootstrap' python3_8 -- > > that is, add it to the most common

Re: [gentoo-dev] unsanctioned python 2.7 crusade

On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld wrote: > > Hi, > > Aaron has marked tons of important and useful Python 2.7 packages for removal: > > Can we not do this prematurely? I've revered this commit until such a > thing an be appropriately agreed upon. Might make sense to wait to mask t

Re: [gentoo-dev] unsanctioned python 2.7 crusade

On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld wrote: > > It's quite another to mask random packages that have USE flags to > optionally support whatever python 2.7 library. If you're going to > last rites these, talk with the maintainer first, and only then, send > emails one at a time. Doing

Re: [gentoo-dev] unsanctioned python 2.7 crusade

On Thu, Dec 5, 2019 at 5:23 PM David Seifert wrote: > > And that's exactly the straw-man argument I've been making. You can > always come up with an excuse to delay action on python 2, because > "someone, somewhere, will maintain it". Hey, if somebody actually does want to maintain it I don't see

Re: [gentoo-dev] unsanctioned python 2.7 crusade

On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann wrote: > > Sure, if packages don't work anymore or are blocking something, we will > start last-rite process. But for the sabnzbd example (I haven't looked > closely on any other package from that list) there isn't anything > blocking and it's a wo

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

On Tue, Dec 10, 2019 at 12:44 AM Joonas Niilola wrote: > > Honestly I'd say just put -1 on all acct- packages then let sys admins > modify them locally to whatever they need. I feel like this whole GLEP > just serves the minority while making many other contributors uneasy. > I think we're worryi

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

On Tue, Dec 10, 2019 at 7:26 AM Thomas Deutschmann wrote: > > On 2019-12-10 12:47, Rich Freeman wrote: > > Having UIDs chosen completely at random seems fairly non-optimal. > > Suppose you're building containers/etc and then bind-mounting in > > persistent stor

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

On Tue, Dec 10, 2019 at 8:25 AM Thomas Deutschmann wrote: > > On 2019-12-10 13:44, Rich Freeman wrote: > > I'm not talking about container-host mapping. I'm talking about > > building the same container 100 times and having the container end up > > w

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

On Tue, Dec 10, 2019 at 9:50 AM Michael Orlitzky wrote: > > For esoteric packages with a dedicated user, though, you're probably > right. The main benefit of the mailing list posts so far is that they > let me track down pull requests and suggest that people ignore the > example in the devmanual.

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

Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

On Fri, Dec 20, 2019 at 8:41 AM Gerion Entrup wrote: > > Am Donnerstag, 19. Dezember 2019, 19:43:37 CET schrieb Sebastian Pipping: > > On 19.12.19 18:37, Michał Górny wrote: > > > We have a better alternative that lets us limit the impact on the users. > > > Why not use it? > > > > Which one? The

Re: [gentoo-dev] Vanilla sources

On Fri, Jan 3, 2020 at 9:41 AM Michael Orlitzky wrote: > > On 1/3/20 9:40 AM, Toralf Förster wrote: > > On 1/3/20 3:37 PM, Michael Orlitzky wrote: > >> The gentoo-sources aren't 100% safe either, but the exploitable scenario > >> is less common thanks to fs.protected_{hardlinks,symlinks}=1. > > >

Re: [gentoo-dev] Vanilla sources

On Fri, Jan 3, 2020 at 11:28 AM Aaron Bauman wrote: > On January 3, 2020 9:55:31 AM EST, Michael Orlitzky wrote: > >On 1/3/20 9:52 AM, Michael Orlitzky wrote: > >> > >> But here we are. Do we make OpenRC Linux-only and steal the fix from > >> systemd? Or pretend to support other operating systems

Re: [gentoo-dev] Vanilla sources

On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford wrote: > > On 2020.01.04 11:01, Rich Freeman wrote: > > > > Is there some reason that we should keep vanilla sources despite not > > getting security handling? > > > > Gentoo had this discussion before. The outcome w

Re: [gentoo-dev] Vanilla sources

On Sat, Jan 4, 2020 at 3:13 PM Christopher Head wrote: > > > Of course this would be a bad argument if V-S were lagging behind upstream > significantly, and it’s a much better argument for packages that come with > expectations of security team support than those that don’t, but it is > somethi

Re: [gentoo-dev] GLEP81 and /home

On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote: > > But now users have to follow one more step (create /home/amavis) when > setting up amavisd-new. Is the QA check really assuring a quality user > experience here? > Lots of daemons need a home directory for their users, and usually they m

Re: [gentoo-dev] GLEP81 and /home

On Sat, Jan 18, 2020 at 9:50 PM Michael Orlitzky wrote: > > On 1/18/20 7:21 PM, Rich Freeman wrote: > > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote: > >> > >> But now users have to follow one more step (create /home/amavis) when > >> setting

Re: [gentoo-dev] New QA Policy Guide

On Sun, Jan 19, 2020 at 6:46 AM Ulrich Mueller wrote: > > > On Sun, 19 Jan 2020, Michał Górny wrote: > > > The sources are stored in proj/policy-guide.git [3]. If you wish to > > submit your own changes, you can either use the 'Policy Guide' bugzilla > > component [4] and/or GitHub mirror [5]

Re: [gentoo-dev] GLEP81 and /home

On Sun, Jan 19, 2020 at 10:49 AM Michael Orlitzky wrote: > > On 1/19/20 6:29 AM, Rich Freeman wrote: > > > > Daemons are local users. There is no guarantee that /home is a local > > filesystem. Heck, there is no guarantee that /home is even mounted > > whe

Re: [gentoo-dev] New QA Policy Guide

On Sun, Jan 19, 2020 at 1:45 PM Kent Fredric wrote: > > On Sun, 19 Jan 2020 07:08:30 -0500 > Rich Freeman wrote: > > > The official sources aren't in github. A bugzilla component is > > available, so if github goes away there is no problem and we aren't >

Re: [gentoo-dev] GLEP81 and /home

On Sun, Jan 19, 2020 at 1:37 PM Michael Orlitzky wrote: > > On 1/19/20 12:42 PM, Rich Freeman wrote: > > > > Typically you wouldn't share service accounts across multiple hosts. > > I'd think that something like amavisd is going to go on a mail server. > >

Re: [gentoo-dev] New QA Policy Guide

On Sun, Jan 19, 2020 at 2:32 PM Kent Fredric wrote: > > Having a discussion at a bar, and you making a commit as a result is > one thing, but if I discovered a bug, and then only told you about it > at the bar, that would be possibly bad, because there's no guarantee > that the bug is communicated

Re: [gentoo-dev] GLEP81 and /home

On Sun, Jan 19, 2020 at 2:27 PM Michael Orlitzky wrote: > > On 1/19/20 2:02 PM, Rich Freeman wrote: > > > >> If you're sharing /home, you also have to be sharing user accounts, > >> unless you want everyone to be assigned a random set of files. > >

Re: [gentoo-dev] GLEP81 and /home

On Sun, Jan 19, 2020 at 4:00 PM Michael Orlitzky wrote: > > On 1/19/20 2:47 PM, Rich Freeman wrote: > > > > Obviously the UIDs associated with the shared /home need to be > > identical. Simplest solution is to sync anything > 1000 in > > /etc/passwd, and then n

Re: [gentoo-dev] GLEP81 and /home

On Sun, Jan 19, 2020 at 8:51 PM Michael Orlitzky wrote: > > On 1/19/20 8:20 PM, Rich Freeman wrote: > > It would be far simpler for the sysadmin to simply ensure that no > > unsynced user owns a file or appears in an ACL. That would be pretty > > trivial to achieve. W

Re: [gentoo-dev] GLEP81 and /home

On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote: > > This is retarded, stop wasting my time. > There is nothing retarded about shared /home directories. They're pretty common in the real world. > >> I've already got responses from two QA members. This thread is pretty > >> hard to miss.

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

On Mon, Jan 27, 2020 at 6:41 AM Ulrich Mueller wrote: > > Historically, all ebuilds in the Gentoo repository were licensed under > GPL-2+. At a later point they were relicensed [1] to GPL-2. See [2] for > a rationale (or absence of it, YMMV). I think the historical policy made sense in its contex

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

On Thu, Jan 30, 2020 at 6:20 AM Haelwenn (lanodan) Monnier wrote: > > [2020-01-27 12:41:26+0100] Ulrich Mueller: > > So, the question is, should we allow ebuilds > > # Distributed under the terms of the GNU General Public License, v2 or later > > in the repository, or should we even encourage it f

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

On Thu, Jan 30, 2020 at 8:39 AM Hanno Böck wrote: > > *If* Gentoo decides to go this relicensing way I'd recommend to only do > that if it's coordinated with organizations that have deep legal > knowledge of these issues (e.g. like software freedom conservancy) and > if some lawyers that know this

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

On Tue, Feb 11, 2020 at 10:05 AM Haelwenn (lanodan) Monnier wrote: > > Maybe it could for now be a simple agreement on putting your code to > the Gentoo Foundation under the GPL-2+ but it would be published under > the GPL-{2,3,…}? > Well, if we were going to get people to start signing things I

Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

On Fri, Mar 13, 2020 at 1:29 AM Chí-Thanh Christopher Nguyễn wrote: > > Alec Warner schrieb: > > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel > > wrote: > > > > Someone needs to grow up here. > > > > > > Meh, to me (someone who can't commit to ::gentoo) I ha

Re: [gentoo-dev] rfc: openrc service script dependency checker

On Thu, Dec 4, 2014 at 7:54 AM, Andrew Savchenko wrote: > > 1. There are multiple services having "after $all" statement (an > analog in Gentoo is "after *", which is currently used only by > local init.d script). > Seems to me that the solution to this is to ban this sort of syntax entirely, and

Re: [gentoo-dev] rfc: openrc service script dependency checker

On Thu, Dec 4, 2014 at 11:12 AM, Andrew Savchenko wrote: > On Thu, 4 Dec 2014 08:59:22 -0500 Rich Freeman wrote: >> On Thu, Dec 4, 2014 at 7:54 AM, Andrew Savchenko wrote: >> > >> > 1. There are multiple services having "after $all" statement (an >>

Re: [gentoo-dev] rfc: openrc service script dependency checker

erybody, including non-Gentoo users. I just think we need to be careful about tolerating incorrect input, simply because some users don't want to correctly provide input. > > On 12/04/2014 04:59 PM, Rich Freeman wrote: >> I think that on a boot phase in case of parallel boot rc shou

Re: [gentoo-dev] rfc: openrc service script dependency checker

On Fri, Dec 5, 2014 at 3:25 AM, Andrew Savchenko wrote: > >> I didn't ask why we need local.d. I asked why we need to run it LAST, >> and why we need to run all of that other stuff LAST? Of course, the >> reality is that we aren't running all of that stuff last since exactly >> one script can RE

Re: [gentoo-dev] About reversion of last pulseaudio ebuild change

On Fri, Dec 5, 2014 at 2:02 PM, Ulrich Mueller wrote: >> On Fri, 5 Dec 2014, Andrew Savchenko wrote: > >> If GLEP doesn't reflect current best practices maybe this is a good >> time to supersede it with a new one? > > Not this again, please. :( The GLEP outlines the framework under which > QA

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile wrote: > On 12/07/14 05:37, Michał Górny wrote: >> >> If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd >> appreciate any bug reports, except for those covering things i've >> already listed as missing :). Any further comments w

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile wrote: > On 12/07/14 08:18, Michał Górny wrote: I will also be happy to work on replacing the new versions of original sys-devel/gcc completely. With QA process against toolchain.eclass if necessary. >>> Let's get the list

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

On Mon, Dec 8, 2014 at 9:00 AM, Anthony G. Basile wrote: > > Forking code does not address the QA issues currently against > toolchain.eclass. The two issues are orthogonal and I don't think I > connected them in my emails. I disagree with forking but have no right to > obstruct it and would not

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

On Mon, Dec 8, 2014 at 12:08 PM, Matt Turner wrote: > eclasses are pretty great for sharing code akin to a library, but when > *all* of your ebuild's logic is in the eclass, well, that's not really > the intended use case as far as I can tell. It works well in cases like KDE where you have 300 eb

<    13   14   15   16   17   18   19   20   21   22   >