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

2018-11-27 Thread Rich Freeman
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

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

2018-11-27 Thread Rich Freeman
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

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

2018-11-27 Thread Rich Freeman
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

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

2018-11-27 Thread Rich Freeman
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

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

2018-11-27 Thread Rich Freeman
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

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

2018-11-27 Thread Rich Freeman
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

2018-11-27 Thread Rich Freeman
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

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

2018-11-27 Thread Rich Freeman
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

2018-11-27 Thread Rich Freeman
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

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

2018-11-19 Thread Rich Freeman
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] [pre-GLEP r1] Gentoo binary package container format

2018-11-19 Thread Rich Freeman
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

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

2018-11-18 Thread Rich Freeman
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: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gen...@jonesmz.com]

2018-11-18 Thread Rich Freeman
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

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

2018-11-17 Thread Rich Freeman
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

Re: [gentoo-portage-dev] Re: [RFC] Improving Gentoo package format

2018-11-11 Thread Rich Freeman
On Sun, Nov 11, 2018 at 1:02 PM M. J. Everitt wrote: > > If you can really present a decent argument for replicating the > functionality of other distros like Debian, Arch, Ubuntu etc then let's > here it. For now, the strength of Gentoo is being able to fully customise a > system to your own

Re: [gentoo-portage-dev] Re: [RFC] Improving Gentoo package format

2018-11-11 Thread Rich Freeman
On Sun, Nov 11, 2018 at 12:31 PM M. J. Everitt wrote: > > Binpkgs are also a popular component of a few downstream distro's based on > Gentoo (thinking pentoo right now as an easy example). > > So we don't want to break existing users of this format without considering > the ramifications for

Re: [gentoo-portage-dev] [RFC] Improving Gentoo package format

2018-11-11 Thread Rich Freeman
On Sun, Nov 11, 2018 at 3:29 AM Michał Górny wrote: > > On Sat, 2018-11-10 at 09:37 -0500, Alec Warner wrote: > > On Sat, Nov 10, 2018 at 8:09 AM Michał Górny wrote: > > > > > > > > + If we can maintain reasonable level of vdb compatibility, the user can > > > even emergency-install a package

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

2018-11-06 Thread Rich Freeman
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

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

2018-10-20 Thread Rich Freeman
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] Is there any way I can help with pull requests?

2018-10-16 Thread Rich Freeman
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

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

2018-10-13 Thread Rich Freeman
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] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

2018-10-12 Thread Rich Freeman
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"

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

2018-09-29 Thread Rich Freeman
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] Changing policy about -Werror

2018-09-14 Thread Rich Freeman
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

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

2018-09-14 Thread Rich Freeman
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

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

2018-09-14 Thread Rich Freeman
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

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

2018-09-13 Thread Rich Freeman
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

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

2018-09-12 Thread Rich Freeman
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] acceptable alternatives to -Werror, was: Changing policy about -Werror

2018-09-12 Thread Rich Freeman
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] Changing policy about -Werror

2018-09-12 Thread Rich Freeman
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 with

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

2018-09-12 Thread Rich Freeman
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

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

2018-09-12 Thread Rich Freeman
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

2018-09-12 Thread Rich Freeman
On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman wrote: > > Replying to a somewhat random post. There are two separate things here > that people are discussing here but are not the same thing. Three, really... > > 1) We want to know when a package has terrible warnings when installing > it so we can

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

2018-09-10 Thread Rich Freeman
On Mon, Sep 10, 2018 at 5:01 PM Mike Gilbert wrote: > > On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand wrote: > > > > On 9/10/18 10:51 PM, Matt Turner wrote: > > > Consider again the bug that started this. The maintainer had not built > > > this configuration. None of the arch teams had

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

2018-09-09 Thread Rich Freeman
On Sun, Sep 9, 2018 at 1:50 PM Michael Orlitzky wrote: > > So if you're using -Werror to prevent a > "vulnerable" package from being installed, it doesn't work, and can > actually be harmful if it prevents me from using a better compiler. > Whether or not the new compiler is better,

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

2018-08-31 Thread Rich Freeman
On Mon, Aug 27, 2018 at 6:46 PM Michael Mol wrote: > > I can say that if the licenses are habitually misidentified, I could not use > Gentoo's portage tree in my job without extensive and ongoing revalidation of > the license metadata. > Keep in mind that we're just talking about GPL-2 vs 2+ and

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

2018-08-26 Thread Rich Freeman
On Sun, Aug 26, 2018 at 7:15 AM Michał Górny wrote: > > On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote: > > On 26/08/2018 12:53, Mart Raudsepp wrote: > > > The common issue here is that upstream COPYING files really do only > > > talk about one of the versions. And then you get to

Re: [gentoo-dev] Gentoo i486 support

2018-08-24 Thread Rich Freeman
On Fri, Aug 24, 2018 at 9:57 AM Mike Gilbert wrote: > > On Fri, Aug 24, 2018 at 9:19 AM Kent Fredric wrote: > > > > On Wed, 22 Aug 2018 07:26:24 -0500 > > Ben Kohler wrote: > > > > > Thoughts? > > > > Is there a good reason we can't have a legacy profile for this? > > > > Or perhaps, a new

Re: [gentoo-dev] Gentoo i486 support

2018-08-22 Thread Rich Freeman
On Wed, Aug 22, 2018 at 4:27 PM R0b0t1 wrote: > > Even newer embedded i586 and i686 hardware isn't cost effective > considering power consumption. When considering power it often does > not even make sense to run donated hardware ~5 years old. > I was referring to running the x86 arch on

Re: [gentoo-dev] Gentoo i486 support

2018-08-22 Thread Rich Freeman
On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler wrote: > > 1) Adjust x86 profile defaults to drop the problematic -march=i686. > This would be more in line with amd64 profiles (et al), which set no > -march value so it can run on any hardware for this arch. > My knee-jerk reaction was that this is a

Re: [gentoo-dev] Idea for a new project: gentoo-libs

2018-08-05 Thread Rich Freeman
On Sun, Aug 5, 2018 at 2:12 PM Richard Yao wrote: > > > Prestige is good. We have prestige from our (myself and a few others) work in > upstream ZFS and Gentoo is well respected there. Sure, but ZFS on Linux isn't a Gentoo project. I'm not saying people who are Gentoo devs can't also do other

Re: [gentoo-dev] Idea for a new project: gentoo-libs

2018-08-05 Thread Rich Freeman
On Sun, Aug 5, 2018 at 1:01 PM Alec Warner wrote: > > > Part of my frustration is that seemingly "anything open source related > can be held in Gentoo" and I'm somewhat against that as I feel it > dilutes the Gentoo mission. We are here to make a distribution, not > maintain random libraries. If

Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)

2018-07-29 Thread Rich Freeman
On Sun, Jul 29, 2018 at 3:56 PM Matt Turner wrote: > > On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote: > > > > So, considering all the feedback from mailing list and IRC: > > > >/usr/portage -> /var/db/repos/gentoo > >/usr/portage/distfiles ->

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-24 Thread Rich Freeman
On Tue, Jul 24, 2018 at 5:11 PM Dennis Schridde wrote: > > On Tuesday, 24 July 2018 20:57:09 CEST Rich Freeman wrote: > > On Tue, Jul 24, 2018 at 2:32 PM Ian Stakenvicius wrote: > > > I don't think the process needs to be simplified much more than this; > > > ea

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-24 Thread Rich Freeman
On Tue, Jul 24, 2018 at 2:32 PM Ian Stakenvicius wrote: > > I don't think the process needs to be simplified much more than this; > each layer above has its purpose. However I do very much want to > caution on making it more complicated, especially with the addition of > syntax that allows

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-24 Thread Rich Freeman
On Tue, Jul 24, 2018 at 12:49 PM Michael Orlitzky wrote: > > On 07/24/2018 12:37 PM, Rich Freeman wrote: > >> harder to customize, because you can't turn it off. > > > > This was already addressed in a previous comment - PMS can be modified > > to nullify flag

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-24 Thread Rich Freeman
On Tue, Jul 24, 2018 at 12:27 PM Michael Orlitzky wrote: > > On 07/24/2018 12:14 PM, Rich Freeman wrote: > > > > I don't believe anybody suggested making Gentoo harder to customize. > > This is just about setting reasonable defaults. > > For the (N+1)th time: Wel

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-24 Thread Rich Freeman
On Tue, Jul 24, 2018 at 12:06 PM Michael Orlitzky wrote: > > On 07/24/2018 11:39 AM, Mike Gilbert wrote: > > > > You can run any system without udev, but you need to be very careful > > about what Linux features you utilize and how you have the system > > configured. > > > > Most Linux servers

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-21 Thread Rich Freeman
On Sat, Jul 21, 2018 at 5:33 AM Zac Medico wrote: > > Sure, why not? So ^flag would mean that the flag state propagates from > the settings in IUSE. Presumably this could be overridden in subsequent profiles, or /etc/portage. That is, one profile might set a flag, and another profile could

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Rich Freeman
On Fri, Jul 20, 2018 at 9:47 AM Michael Orlitzky wrote: > > On 07/20/2018 07:55 AM, Rich Freeman wrote: > > > > While I agree that setting USE=-udev isn't the same as leaving it to > > package defaults, you further claim that setting this globally causes > > sever

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Rich Freeman
On Fri, Jul 20, 2018 at 9:17 AM M. J. Everitt wrote: > > The hierarchy method is indeed flawed, it would be better to have > something akin to USE flags for profiles (PROFLAGS?) .. so that you > could mingle different aspects without replicating sections of the > 'tree' to get the common

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Rich Freeman
On Fri, Jul 20, 2018 at 9:05 AM wrote: > > I’m not sure I was clear enough in what 13.0 would mean : basically, its > current content would be > delegated to common, and 13.0 would keep only things needed to have minimal > breakages/conflicts. > And we would keep the current directory-like

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Rich Freeman
On Fri, Jul 20, 2018 at 8:39 AM wrote: > > > Why not introducing a new level in the hierarchy ? Something like "common" > could be fit. > > default/linux/amd64/13.0 > default/linux/amd64/13.0/common > default/linux/amd64/13.0/common/desktop > default/linux/amd64/13.0/common/developer > ... > >

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Rich Freeman
On Fri, Jul 20, 2018 at 1:58 AM Michael Orlitzky wrote: > > On 07/20/2018 01:06 AM, Mart Raudsepp wrote: > >> > >> * They can't be undone. It's next to impossible for me to undo > >> USE=udev when set in a profile that is inherited by all others. > > > > You set USE=-udev in your make.conf.

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Rich Freeman
On Thu, Jul 19, 2018 at 9:42 PM Andrew Savchenko wrote: > > On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote: > > Hello, > > > > I'd like to propose adding USE=udev to our linux profiles (in > > profiles/default/linux/make.defaults probably). This flag is already > > enabled on desktop

Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)

2018-07-18 Thread Rich Freeman
On Wed, Jul 18, 2018 at 9:30 AM Ulrich Mueller wrote: > > >>>>> On Wed, 18 Jul 2018, Rich Freeman wrote: > > > On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller wrote: > >> Also, there is that strange requirement that the > >> file

Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)

2018-07-18 Thread Rich Freeman
On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller wrote: > > "Pertains to one specific host" doesn't seem to apply to the Gentoo > repository though. Sure it does. The state of the package repository on a Gentoo host doesn't affect any other host. Sure, that state is synced from someplace that

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-12 Thread Rich Freeman
On Thu, Jul 12, 2018 at 3:47 PM Brian Dolbec wrote: > > So, "portage" should not be a directory name in the new default path. > Well, in my examples I proposed it as that is the software that created the path, but then again in the spirit of PMS portage isn't the only PM. So:

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-12 Thread Rich Freeman
On Thu, Jul 12, 2018 at 3:34 PM konsolebox wrote: > > I have /var/lib/gentoo/portage defined in repos.conf/gentoo.conf. > Regardless of the base directory location, I might suggest a path dedicated to repositories, of which the main gentoo repo is just an initial one, and overlays could be

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-12 Thread Rich Freeman
On Wed, Jul 11, 2018 at 11:16 PM William Hubbs wrote: > > That is the other part of this debate, some are saying /var/lib, and > others are saying /var/db. > > It turns out that /var/db is much more common than I thought it was > (it exists in all *bsd variants at least), so that could be an

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-11 Thread Rich Freeman
On Wed, Jul 11, 2018 at 6:11 PM Richard Yao wrote: > > Is it a violation of the FHS? /usr is for readonly data and the portage tree > is generally readonly, except when being updated. The same is true of > everything else in /usr. > It is application metadata. It belongs in /var. No other

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-11 Thread Rich Freeman
On Wed, Jul 11, 2018 at 4:34 PM Richard Yao wrote: > > On my system, /usr/portage is a separate mountpoint. There is no need to have > on,h top level directories be separate mountpoints. It makes sense to follow FHS. Sure, I can work around poor designs by sticking mount points all over the

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-11 Thread Rich Freeman
On Wed, Jul 11, 2018 at 11:36 AM Raymond Jennings wrote: > > I do think it would be a wise idea to "grandfather" the current layout > for awhile. > I don't see why we would ever stop supporting it, at least in general. Maybe if some day somebody had a solution for a read-only /usr with signature

Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address

2018-07-10 Thread Rich Freeman
On Tue, Jul 10, 2018 at 10:14 AM kuzetsa wrote: > > Authorship was brought up by: [ Mart Raudsepp ] > > It's germane, and wanting clarity doesn't hurt: Sure, and it was answered by mgorny 17 hours before your post, pointing to the original email which did in fact specifically reference the

Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address

2018-07-10 Thread Rich Freeman
On Tue, Jul 10, 2018 at 9:38 AM kuzetsa wrote: > > I think authorship is a good point / distinction, Mart. > > Authorship was never shown in dev-timeline for addresses > which aren't @gentoo.org anyway. That's a separate issue, > so this policy change shouldn't affect proxy-maint? > Might I

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-09 Thread Rich Freeman
On Mon, Jul 9, 2018 at 5:34 PM Kristian Fiskerstrand wrote: > > I'd mostly argue any such change should only affect new systems > ++ If a user wants to migrate it is pretty easy to do. Update the setting and do an mv, or don't do an mv in which case it will just regenerate. I think

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-09 Thread Rich Freeman
On Mon, Jul 9, 2018 at 4:13 PM Michał Górny wrote: > > W dniu pon, 09.07.2018 o godzinie 15∶11 -0500, użytkownik William Hubbs > napisał: > > On Mon, Jul 09, 2018 at 08:43:31PM +0200, Michał Górny wrote: > > > sys-apps/portage-mgorny has already done that. The defaults locations > > > have been

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-09 Thread Rich Freeman
On Mon, Jul 9, 2018 at 2:11 PM Johannes Huber wrote: > > Am 09.07.2018 um 20:05 schrieb Rich Freeman: > > On Mon, Jul 9, 2018 at 1:40 PM Ulrich Mueller wrote: > >> > >>>>>>> On Mon, 9 Jul 2018, William Hubbs wrote: > >> > >>

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-09 Thread Rich Freeman
On Mon, Jul 9, 2018 at 1:40 PM Ulrich Mueller wrote: > > > On Mon, 9 Jul 2018, William Hubbs wrote: > > > is there a tracker for when the portage tree can be moved out of > > /usr/portage by default? > > > If not, what is the status of us being able to do this? > > Please remind me, what was

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-09 Thread Rich Freeman
On Mon, Jul 9, 2018 at 1:26 PM Alec Warner wrote: > > The former is probably 3 times easier than the latter. > - Get testers to move their tree and report issues[0]. > - Change the stage3 defaults to be the new location. > - Explicitly do nothing else. > > New installs will get the new

Re: [gentoo-dev] News Item: Portage rsync hardlink support

2018-07-08 Thread Rich Freeman
On Sun, Jul 8, 2018 at 5:50 PM Aaron W. Swenson wrote: > > Does Portage not call attention to critical updates? > > It used to make a special statement for a new stable Portage and strongly > recommended that it be emerged first. It should probably do the same for > openpgp-keys-gentoo-release.

Re: [gentoo-dev] News Item: Portage rsync hardlink support

2018-07-08 Thread Rich Freeman
On Sun, Jul 8, 2018 at 2:31 PM Kristian Fiskerstrand wrote: > > On 07/08/2018 08:10 PM, Rich Freeman wrote: > > Again, the current portage support for git verification doesn't check > > any developer keys. > > right, so why would it be material for a news item improving th

Re: [gentoo-dev] News Item: Portage rsync hardlink support

2018-07-08 Thread Rich Freeman
On Sun, Jul 8, 2018 at 1:50 PM Kristian Fiskerstrand wrote: > > On 07/08/2018 07:34 PM, Rich Freeman wrote: > > The patch is to do the verification before > > checking it out so that if it fails the tree is left in a > > last-known-good state (at least as seen by

Re: [gentoo-dev] News Item: Portage rsync hardlink support

2018-07-08 Thread Rich Freeman
On Sun, Jul 8, 2018 at 9:02 AM Kristian Fiskerstrand wrote: > > On 07/08/2018 08:53 AM, Michał Górny wrote: > > Is safe git syncing implemented already? If not, maybe finish it first and > > cover both with a single news item. Git is going to be more efficient here, > > so people may want to

Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?

2018-07-03 Thread Rich Freeman
On Tue, Jul 3, 2018 at 12:41 PM Kristian Fiskerstrand wrote: > > I would expect as much. But my primary argument would be key management > related, it is simply impossible to present a raw copy of our repo to > end-users and have them verify each commit > While related, I think that the

Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?

2018-07-03 Thread Rich Freeman
On Tue, Jul 3, 2018 at 12:34 PM William Hubbs wrote: > > On Tue, Jul 03, 2018 at 11:40:53AM -0400, Rich Freeman wrote: > > On Tue, Jul 3, 2018 at 11:32 AM Brian Dolbec wrote: > > > 2) we have a large infrastructure of rsync mirrors, which we do not for > > > git.

Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?

2018-07-03 Thread Rich Freeman
On Tue, Jul 3, 2018 at 12:22 PM Matt Turner wrote: > > On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman wrote: > > 4. by default git tends to accumulate history, which can eat up disk > > space. I imagine this could be automatically trimmed if users wanted, > > though

Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?

2018-07-03 Thread Rich Freeman
On Tue, Jul 3, 2018 at 11:32 AM Brian Dolbec wrote: > > 1) it is still the most bandwidth economical means of distributing the > tree Is this true? If I do two syncs 10min apart, I have to imagine that less data will get transferred for git. Certianly there will be less disk IO. I think the

Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?

2018-07-03 Thread Rich Freeman
On Tue, Jul 3, 2018 at 11:22 AM William Hubbs wrote: > > Mostly because of the recent "trustless infrastructure" thread, I am > wondering why we are still distributing the portage tree primarily > via rsync instead of git? > > Can someone educate me on that, and is it worth considering moving

Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Rich Freeman
On Mon, Jul 2, 2018 at 2:23 PM Alec Warner wrote: > > We might reduce the complexity here by saying things like: > > "We have N trust levels" > I snipped most of your text because I didn't really see a natural way to include only some of it, though this really pertains to most of it, and I

Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Rich Freeman
On Mon, Jul 2, 2018 at 1:50 PM Jason A. Donenfeld wrote: > > On Mon, Jul 2, 2018 at 7:41 PM Rich Freeman wrote: > > To be fair, this is relying quite a bit on the last dev doing a commit > > to be checking his own tree, though that would certainly be helped if > >

Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Rich Freeman
On Mon, Jul 2, 2018 at 1:23 PM Matthias Maier wrote: > > > On Mon, Jul 2, 2018, at 12:01 CDT, "Jason A. Donenfeld" > wrote: > > > Aren't git signatures done over the full commit objects? Meaning you'd > > need the entire tree of metadata and thus all commits in order to > > verify? Or do you

Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Rich Freeman
On Mon, Jul 2, 2018 at 12:43 PM Jason A. Donenfeld wrote: > > There's a lot of text there, and rather than trying to parse all of > that, I'll just reiterate a primary important design goal that might > be overlooked: > > - End to end signatures from the developer to the user. > > This means that

Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Rich Freeman
Overall I very much like the concept, but I might propose a few tweaks (just quoting the stuff that might benefit from adjustment): On Mon, Jul 2, 2018 at 11:36 AM Jason A. Donenfeld wrote: > > - Sign every file in the portage tree so that it has a corresponding > .asc. Repoman will need support

Re: [gentoo-dev] Fw: "Please let's talk if spamming everyone pointlessly is really needed."

2018-06-09 Thread Rich Freeman
On Sat, Jun 9, 2018 at 5:55 PM R0b0t1 wrote: > > Unless Mr. Roovers has admitted to some sort of conspiracy I don't > think it wise to accuse him of participating in one. > Uh, nobody has accused anybody of participating in a conspiracy here. -- Rich

Re: [gentoo-dev] [RFC] multiversion ebuilds

2018-05-17 Thread Rich Freeman
On Thu, May 17, 2018 at 11:44 AM Gerion Entrup wrote: > The VERSIONS approach does not break the old mechanism. So if a patch > needs to be applied, the multiversion ebuild (that contains other versions > as well, say foobar.ebuild with VERSIONS="1.0 1.1 1.2") can just be

Re: [gentoo-dev] [RFC] multiversion ebuilds

2018-05-12 Thread Rich Freeman
On Sat, May 12, 2018 at 8:20 AM Gerion Entrup wrote: > Different version keywording can be done as before: > ``` > if [[ ${PV} == "3.1" ]] ; then > KEYWORDS="~amd64 ~x86" > else > KEYWORDS="amd64 x86" > fi > ``` From a readability standpoint I could

Re: [gentoo-dev] rfc: virtual/init for init process

2018-04-27 Thread Rich Freeman
On Fri, Apr 27, 2018 at 2:18 PM Zac Medico wrote: > Actually, if things like sys-apps/s6 or sys-process/runit remain as > choices for virtual/init, this isn't going to solve the problem of > sys-apps/sysvinit being removed by emerge --depclean. In fact, if > virtual/init is

Re: [gentoo-dev] Re: Mailing list moderation and community openness

2018-03-28 Thread Rich Freeman
On Wed, Mar 28, 2018 at 2:33 AM, Martin Vaeth <mar...@mvath.de> wrote: > Rich Freeman <ri...@gentoo.org> wrote: >> >> Fred is a community member. Fred consistently harasses and trolls new >> contributors in private. > > Sure, it's a problem. But not a p

Re: [gentoo-dev] Re: Mailing list moderation and community openness

2018-03-28 Thread Rich Freeman
On Tue, Mar 27, 2018 at 10:55 PM, R0b0t1 <r03...@gmail.com> wrote: > > On Tue, Mar 27, 2018 at 11:39 AM, Rich Freeman <ri...@gentoo.org> wrote: > >> Ultimately the leaders just want Fred gone so that new contributors >> aren't getting driven away.

Re: [gentoo-dev] Re: Mailing list moderation and community openness

2018-03-27 Thread Rich Freeman
On Tue, Mar 27, 2018 at 12:12 PM, Martin Vaeth <mar...@mvath.de> wrote: > Rich Freeman <ri...@gentoo.org> wrote: >> On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth <mar...@mvath.de> wrote: >>> >>> It is about openness vs. isolation. >> >&g

Re: [gentoo-dev] Re: Mailing list moderation and community openness

2018-03-27 Thread Rich Freeman
On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth wrote: > > It is the general attitude: Does Gentoo welcome contributions > or want to make their developers live in an ivory tower? > > It is about openness vs. isolation. > I'm pretty sure most developers, myself included, want to

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-27 Thread Rich Freeman
On Mon, Mar 26, 2018 at 10:38 PM, kuzetsa wrote: > > I think this may be a misunderstanding? no? there might be some mailing > list jargon term: "moderation" which I was unaware of: > Historically moderation meant having list traffic held prior to distribution for approval

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-26 Thread Rich Freeman
On Mon, Mar 26, 2018 at 9:19 PM, kuzetsa <kuze...@gmail.com> wrote: > On 03/20/2018 08:08 PM, Rich Freeman wrote: > >> >> Actually, I think it is more of a technical constraint. It is >> basically impossible to blacklist somebody on a mailing list, since >>

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

2018-03-24 Thread Rich Freeman
On Sat, Mar 24, 2018 at 5:01 AM, Kent Fredric wrote: > On Sat, 24 Mar 2018 09:02:20 +0100 > Michał Górny wrote: > >> ...except that it is also used to say 'this is experimental version, >> unmask at will' and Portage wants to unmask stuff for you anyway.

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

2018-03-23 Thread Rich Freeman
On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller wrote: >> On Fri, 23 Mar 2018, Roy Bamford wrote: > >> games-emulation/sdlmame is masked. I have a higher version in my >> overlay than the one in the tree and it gets masked too. >> Its not a problem to me as I know how to

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-22 Thread Rich Freeman
On Thu, Mar 22, 2018 at 4:30 AM, Alexander Berntsen wrote: > On 22/03/18 07:31, Benda Xu wrote: >> We might be able to require GPG signed email to make a post. > Almost definitely. > > But before bikeshedding that, it would be advisable to find out whether > it would be a

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Rich Freeman
On Wed, Mar 21, 2018 at 12:55 PM, R0b0t1 wrote: > > I can't tell, and I suspect other people can't either. > This is the crux of the issue. Decisions involving people issues are made behind closed doors, which means that others are not free to confirm for themselves whether

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-21 Thread Rich Freeman
On Wed, Mar 21, 2018 at 1:36 AM, Eray Aslan wrote: > On Tue, Mar 20, 2018 at 10:28:48AM -0500, Matthew Thode wrote: >> While I personally do no agree with mailing list moderation infra has >> been tasked with moving forward on it. > > That was a somewhat tongue-in-cheek comment

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-20 Thread Rich Freeman
On Tue, Mar 20, 2018 at 7:54 PM, Benda Xu wrote: > William Hubbs writes: > >> I do feel that this decision reflects badly on us as a community and >> should be reversed immediately. The proper way to deal with people who >> have bad behavior is to deal

<    1   2   3   4   5   6   7   8   9   10   >