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
> >
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 configura
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 inher
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
> ...
>
> By
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.
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 profile
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 hierarch
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 man
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:
/var/lib/repos/gent
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 placed
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 arg
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 pac
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 pla
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
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 commi
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 sugge
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 /var/db/pkg
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 c
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:
> >>
> >>>
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 t
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 location
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.
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 improvi
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
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 lea
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 questio
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.
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 du
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 ma
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 away
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 didn't
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
> >
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 se
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
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
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
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
copied,
> renamed with t
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 see this getting out of ha
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 not in the system set,
On Wed, Mar 28, 2018 at 2:33 AM, Martin Vaeth wrote:
> Rich Freeman wrote:
>>
>> Fred is a community member. Fred consistently harasses and trolls new
>> contributors in private.
>
> Sure, it's a problem. But not a problem which can be solved by
> closing
On Tue, Mar 27, 2018 at 10:55 PM, R0b0t1 wrote:
>
> On Tue, Mar 27, 2018 at 11:39 AM, Rich Freeman wrote:
>
>> Ultimately the leaders just want Fred gone so that new contributors
>> aren't getting driven away. They can't explain that because then they
>> cre
On Tue, Mar 27, 2018 at 12:12 PM, Martin Vaeth wrote:
> Rich Freeman wrote:
>> On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth wrote:
>>>
>>> It is about openness vs. isolation.
>>
>> I'm pretty sure most developers, myself included, want to welcome
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 welcome
contributio
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 from a moderator.
> I'
On Mon, Mar 26, 2018 at 9:19 PM, kuzetsa 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
>> all they need to do
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. Well,
>> I mean the default configuration
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 manage it. Its just u
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 good idea in the first pl
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 those actions are cor
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 but not wholly. Yo
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 with them individually and not put a
>> rest
On Tue, Mar 20, 2018 at 9:41 AM, Gregory Woodbury wrote:
> On gentoo-dev list: k_f
> points out that this should have been talked about during previous
> discussion periods...
>
> It was discussed "to death" over and over, and many argued against it
> till they were blue in the face.
Indeed, it w
On Fri, Mar 16, 2018 at 1:21 PM, William Hubbs wrote:
>
> I am in the same camp as Martin and James. I would rather see the issues
> fixed for the specific packages involved than us try to host tarballs
> for every package that doesn't create them.
>
++
If github didn't already provide a solutio
On Fri, Mar 9, 2018 at 3:11 PM, R0b0t1 wrote:
> On Fri, Mar 9, 2018 at 10:17 AM, Alec Warner wrote:
>> The containers are nominally stateless, so there is less chance of 'gunk'
>> building up and surprising me later. It also makes the lifecycle simpler.
>>
>> Obviously its somewhat harder for sta
On Fri, Mar 9, 2018 at 11:17 AM, Alec Warner wrote:
>
> In contrast with disposable containers:
>
> Automated build process for my containers.
>
> If there is a bug in the build, I can throw my buggy containers away and
> build new ones.
>
> Containers are encouraged to be stateless, so logging in
On Thu, Mar 8, 2018 at 9:11 PM, R0b0t1 wrote:
>
> Sadly interest in the patches seems to have waned. The functionality
> is not exactly duplicated in containers, but they do make it easier to
> find changes.
>
Well, the idea with containers wouldn't be to monitor anything, but
instead to ensure t
On Thu, Mar 8, 2018 at 7:46 PM, Benda Xu wrote:
> Rich Freeman writes:
>
>> If you have util-linux installed then try running (as any user - you
>> don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U
>> -r /bin/bash
>>
>> Congrats. Yo
On Thu, Mar 8, 2018 at 4:00 PM, R0b0t1 wrote:
> On Thu, Mar 8, 2018 at 11:50 AM, Rich Freeman wrote:
>> If you have util-linux installed then try running (as any user - you
>> don't have to be root):
>> unshare -i -m -n -p -u -C -f --mount-proc -U -r /bin/bash
>>
On Thu, Mar 8, 2018 at 11:44 AM, R0b0t1 wrote:
>
> I think I was equating containers to Docker as well. My point was
> instead of trying to manage dependencies, containers allow people to
> shove everything into an empty root with no conflicts. The
> enthusiastic blog post seems to restate this.
>
On Thu, Mar 8, 2018 at 10:40 AM, Michał Górny wrote:
>
> So, developers, please *stop adding USE=static-libs* to random libraries
> that have no reason whatever to be statically linked to. And by that I
> mean a good reason, not creeping featurism, not 'user asked for it', not
> 'this broken packa
On Wed, Mar 7, 2018 at 3:55 PM, R0b0t1 wrote:
> On Wed, Mar 7, 2018 at 1:15 PM, Alec Warner wrote:
>>
>> Because containers are awesome and are way easier to use.
>>
>
> I think you missed my point: Why are they easier to use?
>
I suspect that he was equating "containers" with "Docker," which bo
On Wed, Mar 7, 2018 at 12:52 PM, Alec Warner wrote:
>
> https://wiki.gentoo.org/wiki/Project:Perl/g-cpan is a project is in a
> similar space and basically reads perl CPAN metadata to generate stub
> ebuilds.
> Portage tracks these stub ebuilds (and so for example, it tracks what these
> cpan pack
On Tue, Mar 6, 2018 at 6:39 PM, Matt Turner wrote:
> On Tue, Mar 6, 2018 at 2:27 PM, Alec Warner wrote:
>> On Tue, Mar 6, 2018 at 5:22 PM, Matt Turner wrote:
>>> On Tue, Mar 6, 2018 at 1:35 PM, Rich Freeman wrote:
>>> > On Tue, Mar 6, 2018 at 4:17 PM, A
On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel wrote:
>
> Is it worth the effort? Yes, see below.
> Is it a high priority task? No.
>
It sounds like all that has been done is to log a tracker and create
some bugs. That is hardly a major burden on anybody. If it nudges
people to bump the EAP
On Tue, Feb 13, 2018 at 5:44 PM, Ulrich Mueller wrote:
>
> At least for QA this is quite an oversimplified description of the
> team's role. Quoting GLEP 48, first bullet point of the specification:
> "The QA team's purpose is to provide cross-team assistance in keeping
> the tree in a good state.
On Tue, Feb 13, 2018 at 3:53 PM, Chí-Thanh Christopher Nguyễn
wrote:
> Dean Stephens schrieb:
>
>>> Suppose that the council decides to accept an appeal from comrel. Is it
>>> a conflict of interest for a member of the council who is also a member
>>> of comrel to vote in the appeal? If it isn't,
On Sun, Feb 11, 2018 at 6:46 PM, Georgy Yakovlev wrote:
>
> What I'm asking for is your opinion if it's something that should be used in
> gentoo or should I try to avoid it if possible, especially if a static user is
> alredy present in the system.
>
If the systemd behavior is to just fall back
On Thu, Feb 8, 2018 at 6:25 PM, Michael Orlitzky wrote:
> On 02/08/2018 06:12 PM, William Hubbs wrote:
>>
>> There is no bug here. The problem, as I said before in this thread, is
>> that what goes in *sbin is arbitrary, and as Rich said, if you are
>> relying on the path to prevent a non-root use
On Thu, Feb 8, 2018 at 5:17 PM, M. J. Everitt wrote:
>
>
> On 08/02/18 22:13, William Hubbs wrote:
>> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
>>> However, there are plenty of examples of commands that normal users
>>> may run from sbin. Moving these commands often causes prob
On Tue, Jan 23, 2018 at 8:40 AM, Michael Palimaka wrote:
> On 01/24/2018 12:15 AM, Michael Orlitzky wrote:
>> On 01/23/2018 07:40 AM, Michael Palimaka wrote:
Did you come up with a solution how to handle eclass-generated dependency
changes then?
>>>
>>> No.
>>>
>>> Bug #641346 was f
On Tue, Jan 23, 2018 at 7:40 AM, Michael Palimaka wrote:
> On 01/22/2018 09:28 PM, Andreas K. Huettel wrote:
>> Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico:
>>>
>>> According to Gentoo policy, future ebuild dependency changes need to be
>>> accompanied by a revision bump in order t
On Mon, Jan 22, 2018 at 11:57 AM, Michał Górny wrote:
> W dniu nie, 21.01.2018 o godzinie 20∶24 -0800, użytkownik Zac Medico
>
>> Should we tell users to use the emerge --changed-deps=y option? Maybe
>> make --changed-deps=y a default setting?
>
> No. The idea is that not all dependency changes ne
On Mon, Jan 15, 2018 at 8:26 AM, Tom H wrote:
>
> Gentoo's singling itself itself out as less receptive to its users
> simply because some its developers are too Trumpian to resist arguing
> with people who criticize their work or Gentoo.
>
Wouldn't it be a bit exclusionary to require prospective
On Thu, Jan 11, 2018 at 12:07 PM, Peter Stuge wrote:
> Maybe this is a discussion for -project, then?
>
Getting these kinds of non-technical discussions off of -dev is most
of the point of this. The purpose of this list is discussion of
things like eclass changes, fixing bugs, and so on. It is
On Wed, Jan 10, 2018 at 6:27 PM, M. J. Everitt wrote:
> On 10/01/18 23:20, Rich Freeman wrote:
>> On Wed, Jan 10, 2018 at 5:28 PM, Roy Bamford wrote:
>>> Being somwhat old and cynical, I'm seeing signs of history
>>> repeating itself.
>>>
>>> Doe
On Wed, Jan 10, 2018 at 5:28 PM, Roy Bamford wrote:
>
> Being somwhat old and cynical, I'm seeing signs of history
> repeating itself.
>
> Does being 'struck off' the list in this way apply to devs, including
> Council and comrel members?
>
It would seem that this question is already answered:
ht
On Sat, Dec 30, 2017 at 3:49 AM, Toralf Förster wrote:
> On 12/30/2017 07:52 AM, Alice Ferrazzi wrote:
>> Hello,
>>
>> We recently dropped the stable keywords for 4.14,
>> but 4.12 (the next stable in gentoo-sources) is no more
>> maintained from upstream.
>>
>> The last update that 4.12 got from
On Tue, Dec 26, 2017 at 5:22 PM, Jason A. Donenfeld wrote:
> You might want to mention that alternatively, uninstalling
> openrc&sysvinit&netifrc on a systemd profile system is fine to do
> these days, despite the warning.
>
Does this still cause a warning? I thought that openrc/sysvinit were
no
On Thu, Dec 21, 2017 at 6:01 AM, Thomas Deutschmann wrote:
> On 2017-12-21 01:35, William Hubbs wrote:
>> ~arch *will* have breakages from time to time, sometimes major
>> breakages, until they are masked or fixed. We are not supposed to leave
>> major breakages there, but ~arch is definitely not
On Wed, Dec 20, 2017 at 4:42 AM, Alexis Ballier wrote:
> On Tue, 19 Dec 2017 16:00:16 -0500
> "Aaron W. Swenson" wrote:
>
>> However, what alternative do we have to throwing the patches up in a
>> devspace?
>
> mirror://gentoo, aka /space/distfiles-local/
>
That isn't a great option. This has b
On Mon, Dec 18, 2017 at 8:33 AM, Francesco Riosa wrote:
>
> On 12/18/17 14:01, Rich Freeman wrote:
>>
>> Whether we remove all files/ or the entire package dir from the repo,
>> I'd suggest that this become more standardized if we wanted to go down
>> one o
On Mon, Dec 18, 2017 at 7:45 AM, Francesco Riosa wrote:
>
> It would be interesting instead to evaluate ways to remove _all_ files/ dirs
> from the tree, keeping ebuilds separated from data.
Arguably you could go a step further and not distribute even the
ebuilds except on demand. Just have an i
On Thu, Dec 14, 2017 at 7:07 AM, Aaron W. Swenson wrote:
> On 2017-12-14 13:58, Kent Fredric wrote:
>> On Wed, 13 Dec 2017 21:58:05 +0100
>> Slightly modified suggestion:
>>
>> Add a flag called "autostabilize" with [unset], [y], [n]
>>
>> Default is 'unset', and if found unset after a given time,
On Thu, Dec 14, 2017 at 5:39 AM, Thomas Deutschmann wrote:
>
> But well, for the beginning we don't need the perfect solution. We can
> start with an easy mode and blacklist most packages. So devs interested
> can remove their packages from blacklist. And like said, build bot would
> still handle
On Tue, Dec 12, 2017 at 1:15 PM, Michał Górny wrote:
>
> It seems that we've started lacking arch testers for AMD64 architecture.
> At this moment, there are already 159 bugs in amd64 backlog, and there
> is no noticeable progress. New stabilization requests are usually
> handled much faster by x8
On Sat, Dec 9, 2017 at 11:31 PM, Daniel Campbell wrote:
>
> Well, let's consider the order of events here:
> ...
> This looks awfully clear to me.
>...
> I'm not focused on the ban, or whether it was deserved.
That's exactly what you've done here. You've connected a bunch of
dots that you can se
On Sat, Dec 9, 2017 at 7:29 PM, Daniel Campbell wrote:
>
> Other developers are required to subscribe to -dev, and are
> expected to follow it so they stay informed.
Developers are not required to subscribe to -dev.
> If they missed something covered on the list, they are directed to the
> archi
On Wed, Dec 6, 2017 at 2:22 AM, R0b0t1 wrote:
> On Tue, Dec 5, 2017 at 4:12 PM, Rich Freeman wrote:
>>
>> And what would you do when somebody repeatedly sexually harasses other
>> members of the community in private after being told to stop, and then
>> acts as i
On Tue, Dec 5, 2017 at 6:01 PM, Kristian Fiskerstrand wrote:
> On 12/05/2017 11:41 PM, Kristian Fiskerstrand wrote:
>> On 12/05/2017 11:37 PM, Rich Freeman wrote:
>>> Honestly, I'm not really a big fan of even on-topic posts from people
>>> who have caused a lot of
On Tue, Dec 5, 2017 at 5:41 PM, Kristian Fiskerstrand wrote:
> On 12/05/2017 11:37 PM, Rich Freeman wrote:
>> Honestly, I'm not really a big fan of even on-topic posts from people
>> who have caused a lot of harm to others in private. I'm not sure
>> which is t
On Tue, Dec 5, 2017 at 5:46 PM, William L. Thomson Jr.
wrote:
> On Tue, 5 Dec 2017 17:25:21 -0500
> Rich Freeman wrote:
>
>> On Tue, Dec 5, 2017 at 5:19 PM, Kristian Fiskerstrand
>> wrote:
>> > On 12/05/2017 11:12 PM, Rich Freeman wrote:
>> >
>> >
On Tue, Dec 5, 2017 at 5:27 PM, Kristian Fiskerstrand wrote:
>
> The difference would be that you, in your first example, can demonstrate
> some actual abuse. In the latter case you're talking about differences
> of opinions of how things are run, which quickly turns into censorship.
>
I don't se
On Tue, Dec 5, 2017 at 5:19 PM, Kristian Fiskerstrand wrote:
> On 12/05/2017 11:12 PM, Rich Freeman wrote:
>> On Tue, Dec 5, 2017 at 4:16 PM, Daniel Campbell wrote:
>>> I think the plan to split mailing lists serves as a way to insulate
>>> developers from the effects
On Tue, Dec 5, 2017 at 4:16 PM, Daniel Campbell wrote:
>
> I think the plan to split mailing lists serves as a way to insulate
> developers from the effects of their decisions. Anyone with an
> incongenial tone will have their voice bit revoked and their mail will
> be dropped or rejected.
And wh
On Mon, Dec 4, 2017 at 5:43 PM, Matt Turner wrote:
> On Mon, Dec 4, 2017 at 1:46 PM, William L. Thomson Jr.
> wrote:
>> On Mon, 4 Dec 2017 13:26:26 -0800
>> Matt Turner wrote:
>>
>>> On Mon, Dec 4, 2017 at 10:52 AM, William L. Thomson Jr.
>>> wrote:
>>> > That being said, that people find it ac
On Sun, Dec 3, 2017 at 7:37 PM, Matt Turner wrote:
>
> With gentoo being a non-profit organization, an alternative way to
> view it could be the trade-off of seeing developers / maintainers /
> staff leave
It isn't just the risk of leaving, but the risk of them never joining
in the first place.
On Mon, Nov 27, 2017 at 3:15 PM, M. J. Everitt wrote:
> On 27/11/17 18:44, Christopher Head wrote:
>> For those of us who run mostly stable systems, there is one question I don’t
>> know a good answer to.
>>
>> If I add a specific version of a game to package.accept_keywords, I will get
>> that
On Sun, Nov 19, 2017 at 1:42 PM, Sergei Trofimovich wrote:
> On Sun, 19 Nov 2017 15:46:02 +0100
> David Seifert wrote:
>
>> games in Gentoo are not part of crucial Tier 1 packages.
>
> It's the first time I hear the term. How "crucial Tier 1 packages" are
> defined? Is there a link explaining
On Wed, Nov 15, 2017 at 3:21 PM, William L. Thomson Jr.
wrote:
>
> The council has no power
> over Trustees, and Trustees do have legal power over all of Gentoo.
Sure, just keep in mind that legally Gentoo is basically nothing but a
name and a logo.
The Trustees could ask the community to stop u
On Tue, Oct 24, 2017 at 4:21 AM, Paweł Hajdan, Jr.
wrote:
> On 24/10/2017 06:11, Michał Górny wrote:
>> W dniu wto, 24.10.2017 o godzinie 06∶04 +0200, użytkownik Michał Górny
>> napisał:
>>> Three hashes don't give any noticeable advantage. If we want a diverse
>>> construct, we take SHA3. SHA3 is
201 - 300 of 2195 matches
Mail list logo
