On Tue, Sep 6, 2016 at 9:02 PM, Erik Mackdanz wrote:
> Kristian Fiskerstrand writes:
>> inherited eclasses. having a whitelist in place and die if eclass is not
>> updated to handle it solves it.
>>
>> Thoughts? comments? cookies? threats?
>
> Wouldn't a
On Wed, Aug 31, 2016 at 1:03 PM, Alexis Ballier <aball...@gentoo.org> wrote:
> On Wed, 31 Aug 2016 08:28:14 -0400
> Rich Freeman <ri...@gentoo.org> wrote:
>> Sure, but we're talking about a major version here, and a web browser
>> where future security updates nee
On Wed, Aug 31, 2016 at 8:06 AM, Alexis Ballier wrote:
>
> For years we've been patching packages to work with >= our latest stable
> version of ffmpeg/libav and unbundle it. Even mplayer. Chromium shouldnt
> be any exception.
>
> Patching consumer packages that way has some
On Sun, Aug 28, 2016 at 11:29 AM, Patrick Lauer wrote:
>
> (and what abuse? it did exactly what it was supposed to do quite nicely,
> until it stopped doing that. Now you need to track state and hope you
> don't have race conditions ... )
>
You were tracking state before; in
On Sun, Aug 28, 2016 at 8:34 AM, Patrick Lauer wrote:
>
> Then tools forgot to properly update mtab because hurr why u no symlink
> to /proc/mounts (oh wait, /proc/self/mounts )
>
> So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
> everyone does it)
>
I
On Thu, Aug 25, 2016 at 8:50 AM, Mike Gilbert wrote:
>
> I never said /etc/hostname was necessary for operation of systemd.
>
> It *is* the way that normal people set their hostname for a system
> that doesn't get configured via DHCP or some dynamic method.
>
Correct, this is
On Wed, Aug 24, 2016 at 7:42 AM, Michael Orlitzky wrote:
> On 08/24/2016 07:37 AM, Daniel Campbell wrote:
>>
>> I imagine _someone_ out there wants it, otherwise we wouldn't be
>> discussing it.
>
> The thread started out proposing it as a solution to a docker problem
> that, it
On Wed, Aug 24, 2016 at 2:52 AM, Christian Kniep wrote:
> Hey there,
>
> as for the /etc/hostname when sharing /etc/ as a volume… This ain’t a
> problem as /etc/hostname is taken care of by the docker-engine (in previous
> versions they used it to discover other hosts).
>
On Tue, Aug 23, 2016 at 3:57 PM, William Hubbs wrote:
>
> I am planning to change the logic in /etc/init.d/hostname so that if
> /etc/hostname exists, the first word out of that file will be used as
> the hostname rather than any setting in /etc/conf.d/hostname. If you
>
On Tue, Aug 23, 2016 at 8:26 AM, Christian Kniep wrote:
> Hey Rich,
>
> nice idea, but unfortunately this provides the hostname of the container
> itself.
>
As it should. /etc/hostname inside a container should contain the
hostname of the container. It shouldn't actually be
On Tue, Aug 23, 2016 at 2:39 AM, Daniel Campbell wrote:
>
> It makes a bit more sense to rely on previous configuration
> (/etc/conf.d/hostname) and write a tiny 'script' that populates
> /etc/hostname. bash could do it (naively) in two lines:
>
> source /etc/conf.d/hostname
>
On Mon, Aug 22, 2016 at 1:51 PM, Sven Vermeulen wrote:
>
> Yes, wouldn't the Docker project be happy to take on a patch that uses
> gethostname() or so?
>
This might be another option: symlink to /proc/sys/kernel/hostname
I'm not sure if somebody can find a flaw in this. It
On Mon, Aug 22, 2016 at 1:03 PM, William Hubbs wrote:
>
> I'm not sure about putting this in /run for a couple of reasons:
>
> The contents of this file is a setting, like /etc/conf.d/hostname, which
> will be set by the user.
There is no reason a script can't populate /run
On Mon, Aug 22, 2016 at 12:11 PM, M. J. Everitt wrote:
> On 22/08/16 16:58, William Hubbs wrote:
>>
>> it looks like app-emulation/docker expects /etc/hostname to exist.
>>
>> On Gentoo, this file does not exist, so I'm wondering how we can make it
>> exist?
>>
>> I know in
On Fri, Aug 19, 2016 at 12:58 AM, Michał Górny <mgo...@gentoo.org> wrote:
> On Thu, 18 Aug 2016 15:21:16 +0200
> Alexis Ballier <aball...@gentoo.org> wrote:
>
>> On Thu, 18 Aug 2016 08:13:14 -0400
>> Rich Freeman <ri...@gentoo.org> wrote:
>>
>&
On Thu, Aug 18, 2016 at 7:47 AM, Lars Wendler wrote:
>
> And as long as I keep reading such statements I won't use ld.gold
> anywhere on my (dev-)systems. A linker IMHO is a far too crucial
> toolchain component to blindly play around with.
>
There really isn't any need
On Thu, Aug 18, 2016 at 1:39 AM, Daniel Campbell wrote:
>
> Is it as simple as switching the linker and re-merging packages that one
> maintains? Is gold supposed to be a big deal? Does it do the job of
> linking better? I read the blog post and all but nobody's explaining
> what
On Wed, Aug 17, 2016 at 4:50 AM, Pacho Ramos <pa...@gentoo.org> wrote:
>
> El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
> > [...]
> > Well, I wasn't suggesting that breaking the depgraph is great. Just
> > that I think it is better than call
On Mon, Aug 15, 2016 at 4:01 PM, William Hubbs wrote:
> This works unless you are talking about packages in @system.
> I do see core packages on these arches also languish in ~ for months
> with open stable requests.
>
> The only way to handle one of those would be to remove
On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel wrote:
> 1) Stabilization is a simpler and much more formalized process compared to
> normal bug resolution.
> * There is one version to be stabilized.
> * One precise package version
Can you clarify what this means? Do
On Mon, Aug 15, 2016 at 3:12 PM, William Hubbs <willi...@gentoo.org> wrote:
> On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote:
>> I'd rather see maintainers just yank the last stable package and break
>> the depgraph and let the arch teams deal with the cleanup t
On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec wrote:
>
> I have some trouble with not being able to close bugs as resolved when
> the fixes have been released. But I do see that the majority of what is
> being discussed relates to pkg ebuilds more than it does to coding
>
On Mon, Aug 15, 2016 at 8:24 AM, Michael Orlitzky wrote:
>
> If we have to wait for a fix to hit stable before I can close a bug, who
> should I assign it to? I don't want 200 bugs, that I can do literally
> nothing about, assigned to me for years while I wait for them to get
>
On Fri, Aug 12, 2016 at 1:48 PM, M. J. Everitt wrote:
>
> I regret to say, although it's a well-known problem .. that the Gentoo
> bike-shed is never ever going to fall down - as the layers of paint
> applied will grossly outlive the materials it might once have been built
>
On Thu, Aug 11, 2016 at 8:04 AM, Ulrich Mueller wrote:
>> On Thu, 11 Aug 2016, James Le Cuirot wrote:
>
>> That makes it slightly more awkward for binaries you may have
>> installed manually.
>
> It is impossible to support all third-party binaries, especially if
> they link
On Sun, Aug 7, 2016 at 1:47 PM, james <gar...@verizon.net> wrote:
> On 08/07/2016 09:47 AM, Rich Freeman wrote:
>>
>> Sounds great. What's stopping you?
>>
>
> Why Rich, thanks for the triple compliments; is that a vote that the basic
> idea(s) have merit
On Sun, Aug 7, 2016 at 9:24 AM, james wrote:
>
> As a team, we could have a simple default program for a simple default
> disk format, and a variety of 'stage-4' images, maybe updated every 3
> months, to get a gentoo system up, quickly. Not an anything you want it to
> be,
On Sat, Aug 6, 2016 at 4:55 PM, Michał Górny wrote:
>
> GitHub works for us. GitHub works for our contributors. GitHub boosts
> our productivity, unlike those vain discussions. We don't have time for
> all this tin foil hat nonsense.
>
Then just ignore it. If somebody wants
On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge wrote:
> Michał Górny wrote:
>> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
>> That's the most convenient solution for most of proxy-maint team members.
>
> How can I help improve that problematic situation?
>
> It's
On Sat, Jul 16, 2016 at 5:33 AM, Andrew Savchenko wrote:
>
> On Fri, 15 Jul 2016 18:03:30 + Robin H. Johnson wrote:
>>
>> The tolerances are presently set to:
>> - 5 seconds of clock drift.
>
> Set it for a minute or two. This will protect from commits from
> really
On Fri, Jul 8, 2016 at 2:51 PM, Chí-Thanh Christopher Nguyễn
wrote:
>
> I'm sorry for harping on that topic again, but if we had used grobian's
> initial proposal for git migration[0] - one repository per package, and the
> portage tree would be an aggregation of those - then
On Fri, Jul 8, 2016 at 2:22 PM, Chí-Thanh Christopher Nguyễn
wrote:
> I think the point of a graveyard repository is that discovering and
> extracting deleted ebuilds from git is more cumbersome than from CVS attic.
>
> It would be even better if the graveyard repository
On Fri, Jul 8, 2016 at 12:51 PM, Michał Górny wrote:
>
> Now, there's a significant difference between lastriting unmaintained
> packages at treecleaner's leisure and having a clean tree to work on,
> and having to figure out how many of the packages blocking some global
>
On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile wrote:
>
> Also there's some debate in IRC about whether or not these packages
> should be lastrited or dropped to maintainer-needed. These forks are
> not in good shape upstream, so I think it makes better sense to
>
On Wed, Jul 6, 2016 at 10:02 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 07/06/2016 03:49 PM, Rich Freeman wrote:
>
>> I understand that. However, I just sometimes wonder whether that
>> approach makes sense. The result of the current system is that we
>
On Wed, Jul 6, 2016 at 8:19 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 07/06/2016 02:11 PM, Rich Freeman wrote:
>
>> announcement (which is something we lack - we issue GLSAs sometimes
>> ages after something is fixed on x86/amd64). Granted, that should be
&g
On Wed, Jul 6, 2016 at 7:48 AM, Anthony G. Basile wrote:
>
> It doesn't matter, there is a problem here which needs to be addressed.
> I'm complaining because we need to fix a problem in our workflow. It
> sounds like K_F is working on a glep for that, which I applaud.
>
Is
On Tue, Jul 5, 2016 at 12:53 PM, james wrote:
>
> OK, but with the attic, you can browse by category, read descriptions to get
> an idea of what is available. Correct me if I'm wrong, but with github, you
> have to know the name of the packages and that is a limitation when
On Tue, Jul 5, 2016 at 8:58 AM, Alan McKinnon wrote:
> Big difference. Gentoo's tree is not hosted on github, and infra isn't
> going to put an attic equivalent there.
>
Either way admittedly git makes finding deleted files a bit of a pain.
However, it is certainly
On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko wrote:
>
> The same applies for the tree-cleaners team. While their job is
> very important, sometimes they are too hasty, like in commit
> 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and
> works fine, have no
On Fri, Jul 1, 2016 at 5:10 AM, Daniel Campbell wrote:
>
> I'm not sure the SSD-for-games-only is the most effective solution
> either, but there are plenty of use cases that I disagree with that tend
> to get by without issue. Are / or /usr on SSD the proposed solution for
>
On Thu, Jun 30, 2016 at 7:19 PM, Daniel Campbell wrote:
> Our ebuilds are maintained by developers, with the occasional
> proxy-maintainer or contributor. Your previous statement combined with
> this amounts to "QA owns and manages the Gentoo repository." You just
> said teams
On Thu, Jun 30, 2016 at 12:54 AM, Daniel Campbell wrote:
>
> Do teams hold any authority (or veto power, whatever you want to call
> it) over their own ebuilds? Is it reasonable to rip functionality out
> from under a group of developers and tell them to deal with it?
Generally
On Wed, Jun 29, 2016 at 6:47 PM, Daniel Campbell wrote:
> I'm glad to see some reach-out here and taking responsibility for
> decisions. However, what does the QA team have to say about systems that
> want games on other media (such as an SSD or separate HDD), or wish to
>
On Fri, Jun 17, 2016 at 1:26 PM, Kristian Fiskerstrand wrote:
> On 06/17/2016 07:05 PM, Brian Dolbec wrote:
>>
>> Then everyone PLEASE stop referring to the Gentoo ebuild tree as
>> portage. Reserve portage for the upstream PACKAGE MANAGER.
>
> indeed
>
Agree, though this
On Fri, Jun 17, 2016 at 11:33 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 06/17/2016 03:48 PM, Rich Freeman wrote:
>>
>> Also, in the case of STABLEREQs would we treat them more like security
>> bugs - the last arch would just post a comment that all ar
On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 06/17/2016 03:58 PM, Rich Freeman wrote:
>>
>> That could actually be generalized. I could see many types of bugs
>> where the issue is with upstream, and we might want to track
On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny wrote:
> On Thu, 16 Jun 2016 15:14:44 +0200
> Kristian Fiskerstrand wrote:
>
>> On 06/16/2016 03:02 PM, Michał Górny wrote:
>> > Hello, everyone.
>> >
>>
>>
>>
>> >
>> > What I'd like to introduce instead is a new
On Fri, Jun 17, 2016 at 9:02 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 06/17/2016 02:18 PM, Rich Freeman wrote:
>
>> If I'm a maintainer and I resolve a bug, how do I know if I should
>> mark it resolved or not before it is stable?
>
> If package is in
On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 06/17/2016 01:50 PM, Rich Freeman wrote:
>> It might be better to just close the original bug, and then open a new
>> STABLEREQ bug on the tracker whenever we're interested in tracking
>>
On Fri, Jun 17, 2016 at 3:37 AM, Alexander Berntsen wrote:
>
> I would not want to tie our choosing RESOLVED to be tied to whether
> there is a stabilised package in the tree or not, because there are
> other Portage users than Gentoo. But I would not oppose such an
>
On Tue, Jun 14, 2016 at 6:30 PM, Ciaran McCreesh
wrote:
> On Wed, 15 Jun 2016 00:21:45 +0200
> "Andreas K. Huettel" wrote:
>> Am Montag, 13. Juni 2016, 09:50:15 schrieb Alexander Berntsen:
>> > > I still think you're underestimating the need
On Sat, Jun 11, 2016 at 8:09 AM, Pacho Ramos wrote:
>
> Yeah, I also fail to see what is wrong with suggesting the items for
> the agenda... is not that the purpose of this call? Or maybe I am
> missing some replies to the thread :|
>
I'm not entirely sure I've caught
On Fri, Jun 10, 2016 at 12:16 PM, james wrote:
> On 06/10/2016 08:00 AM, Ciaran McCreesh wrote:
>>
>>
>> The Exherbo model is not "packages are all over the place and there is
>> no coordination whatsoever". The model is "packages that lots of people
>> use are in a small
On Fri, Jun 10, 2016 at 3:45 AM, Alexander Berntsen wrote:
>
> On 09/06/16 22:15, Michał Górny wrote:
>> Didn't you just contradict yourself? First you tell that everyone
>> should have their own public repo... then you tell that we should
>> merge stuff from those repos. So
On Thu, Jun 9, 2016 at 6:22 AM, Alexander Berntsen wrote:
>
> On 09/06/16 12:14, Johannes Huber wrote:
>> This statement is not feeded with numbers. Distrowatch tells
>> something else.
> I don't know what "feeded" means. Distrowatch is useless for anything
> but figuring out
On Thu, Jun 9, 2016 at 5:41 AM, Alexander Berntsen <berna...@gentoo.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 08/06/16 16:53, Rich Freeman wrote:
>> Do you propose that you can have cross-repo dependencies?
> Sure. This works well in Exherbo
On Wed, Jun 8, 2016 at 9:16 AM, Alexander Berntsen wrote:
>
> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just
On Tue, Jun 7, 2016 at 3:03 PM, Brian Dolbec wrote:
>
> an ordered list of the gui toolkits in their preferred order of
> desirability. This should be an all inclusive list. Note: these are
> subject to package.use setting overrides.
>
This has been my thought as well. This
On Thu, Jun 2, 2016 at 5:27 PM, Daniel Campbell wrote:
> To play devil's advocate, can we get a citation on "users don't want to
> care"? Which users? Does Gentoo have a lot of users who don't care, or
> does it attract a more passionate audience that enjoys the control that
>
On Thu, Jun 2, 2016 at 5:20 PM, Igor Savlook wrote:
> Ok if i want just disable gtk i use USE="-gtk -gtk2 -gtk3".
>
And that is fine if your goal is to disable gtk. Most people don't
have goals like this - their goal is probably to prefer qt, not to
disable gtk, and so
On Thu, Jun 2, 2016 at 4:46 PM, Michał Górny wrote:
>
> We understand that some people have goals like 'I want Qt everywhere,
> I hate GTK+ so much I'd rather not be able to do anything than have
> GTK+ on my system'. We respect them. But we're no longer going to
> optimize
On Sun, May 29, 2016 at 4:25 AM, Ulrich Mueller <u...@gentoo.org> wrote:
>>>>>> On Sun, 29 May 2016, Rich Freeman wrote:
>
>> What I would love to see is this be standardized. An eclass or a
>> GLEP seems like the logical approach.
>
> If there really i
On Sat, May 28, 2016 at 9:11 PM, Joshua Kinard wrote:
>
> Whether the idea is useful in the present day and age, eh, who knows. For the
> mips-sources ebuilds, eblits let me centralize the per-machine notes and
> unpacking logic, which reduced each ebuild's size from ~18KB a
On Tue, May 17, 2016 at 12:05 PM, Sébastien Fabbro wrote:
> On 17 May 2016 at 08:34, Luis Ressel wrote:
>
>>
>> Automated post-merge tests sound kinda dangerous to me. And I don't
>> think there's any stipulation about src_test() only running
>>
On Tue, May 17, 2016 at 7:25 AM, Pallav Agarwal
wrote:
> Because we are already expecting an arch tester to conduct tests for the
> package. And knowing what to test is something I expect to come more
> easily from the maintainer.
>
It would come even more easily from
On Tue, May 17, 2016 at 5:15 AM, Kent Fredric wrote:
> On 17 May 2016 at 20:46, Tobias Klausmann wrote:
>> And as for my pet peeve, tests that are known to fail, can we
>> also annotate that somehow so I don't waste hours running a test
>> suite that
On Sun, May 15, 2016 at 6:46 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Committing without testing, as long as you don't push, is fine, even
> meritorious. It's the push that uploads those commits to the gentoo
> reference repo, however, and testing should *definitely* be done before
> pushing,
On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman wrote:
> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
>> On Sun, 15 May 2016 08:40:39 +0900
>>
>> Aaron Bauman wrote:
>> > Please enlighten me as to what was impolite here? The strong
>> > language
On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman wrote:
>
> Please enlighten me as to what was impolite here? The strong language of
> "seriously" or definitively stating that the individual did not perform the
> necessary QA actions before committing?
He actually didn't "state"
On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt <m.j.ever...@iee.org> wrote:
> On 14/05/16 18:52, Rich Freeman wrote:
>> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>> <blackwelllan...@gmail.com> wrote:
>>> No fun allowed
>>>
>> Are you sayin
On Sat, May 14, 2016 at 1:07 PM, landis blackwell
wrote:
> No fun allowed
>
Are you saying that you don't want people to have fun developing
Gentoo? Or are you trying to say that it is impossible to have fun
developing Gentoo without insulting strangers? I don't
On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt wrote:
> On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
>> Gordon Pettey schrieb:
>>
>>> So, it's perfectly okay to make direct commits of obviously broken
>>> code that
>>> has no chance of working, because community
On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman wrote:
> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
>> On Sat, 7 May 2016 23:25:58 +0200
>> Michał Górny wrote:
>> >
>> > Do you seriously expect this code to work? How about testing? Or
>> > reading
On Wed, May 11, 2016 at 10:34 AM, Kent Fredric wrote:
>
> There's an added security measure that exists /outside/ the gentoo
> source control.
>
It also fails differently.
If I find out that somebody compromised ssh in some way, doubt is cast
on any commit during the
On Mon, May 9, 2016 at 6:34 PM, Anthony G. Basile
wrote:
>
> oh okay. sorry if i misunderstood. nonetheless, doesn't the fedora
> installation cd double as a rescue cd? i think that uses systemd.
>
It might - no idea. I'm not sure if it is as loaded with useful
On Mon, May 9, 2016 at 8:36 AM, Kent Fredric wrote:
>
> While you can in theory rebase merge commits with rebase --preserve,
> my experience has shown me that its very difficult to get right, and
> the presence of merge collisions in the "preserved" rebase risks
> getting
On Mon, May 9, 2016 at 1:21 AM, Matthew Marchese wrote:
> Looks good. Nice work, fellas.
++
>
> I'll do some testing of my own on those stage tarballs so that I can write
> some docs, unless you'd like to write them, blueness. This should ease the
> path on the systemd
On Mon, May 9, 2016 at 7:27 AM, Kristian Fiskerstrand wrote:
> On 05/08/2016 07:07 PM, Kent Fredric wrote:
>> On 9 May 2016 at 05:03, Alexis Ballier wrote:
>>> I was under the impression that merging is needed in order to preserve
>>> commit signatures when
On Sun, May 8, 2016 at 8:18 AM, Kent Fredric wrote:
> On 9 May 2016 at 00:09, Anthony G. Basile wrote:
>> 1. announce to gentoo-dev@ the intention to start a branch intending to
>> merge
>>
>> 2. hack hack hack
>>
>> 3. test the merge for any conflicts
On Sun, May 8, 2016 at 7:25 AM, Andreas K. Hüttel wrote:
>
> * However... as the past months have shown, when using merges it is much
> easier to accidentally mess up the entire tree than using rebases alone.
>
How does a merge make it any easier/harder to mess up the
On Sun, May 1, 2016 at 9:32 AM, Jeroen Roovers wrote:
> And it means we're missing opportunities where "pure" interpreted
> packages may test corner cases of the language implementation and find
> bugs in (JIT or previously) "compiled" code. And that means we're
> calling things
On Sat, Apr 30, 2016 at 8:53 PM, Daniel Campbell wrote:
>
> As you said, however, it's a choice of the maintainer. Things like Perl
> and Python may be less prone to this issue since they're meant to be
> portable.
>
The concept is that the maintainer will only use this when
On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert wrote:
>
> And I don't really see the point in the libressl USE flag in this
> case; I think that was only needed so the slot-operator would resolve
> correctly.
>
Somebody else may be better informed, but I thought that there was
On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny wrote:
>
> Congratulations! ... But why would anyone...
Not really picking on you in particular, but this is not the first
snarky comment on a commit we've seen today.
If somebody makes a mistake, just point it out. I think we
On Sun, Apr 10, 2016 at 7:55 AM, Joshua Kinard wrote:
>
> Create like, a table on the Wiki or some kind of metadata property per-package
> that can contain a boolean or tri-state flag indicating whether it works or
> doesn't work (or kinda works) on split-usr. Or a tracker on
On Sun, Apr 10, 2016 at 5:37 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Tho with the initr*, I did go the dracut route myself. But I'm still not
> entirely convinced that I wouldn't have been better off rolling my own,
> as I'm still not entirely comfortable with the level to which I
>
On Sat, Apr 9, 2016 at 11:28 PM, M. J. Everitt wrote:
> Ok I'm gonna push the Big Red Button here, and assume you may not have
> met 'genkernel' ..
Genkernel has been around for a LONG time. I'm well aware of it.
> ok its not a package, but its the nearest thing to
>
On Sat, Apr 9, 2016 at 10:17 PM, M. J. Everitt wrote:
> I take your point, but I would argue that the kernel and boot subsystem
> really are special cases .. you don't go hacking around the chromium
> sources to fundamentally alter the way/order it works, right?! Likewise,
>
On Sat, Apr 9, 2016 at 9:35 PM, M. J. Everitt wrote:
> I think that is the potential for a stage4-style install. I think
> previous list discussions have maintained that the flexibility of gentoo
> is maintained by having a very basic install image, and a stage3 to
>
On Sat, Apr 9, 2016 at 8:37 PM, M. J. Everitt wrote:
> I may have contributed to the latter point, but addressing the former
> specifically, I, like others, have /usr mounted on an NFS server for
> thin clients (not in the full-true sense, but with a very minimal /
>
On Sat, Apr 9, 2016 at 8:09 PM, J. Roeleveld wrote:
>
> I actually write my own initramfs because neither dracut not genkernel end up
> with a convenient boot system.
>
> I have 2 disks, both encrypted.
> I prefer only to enter the decryption password once. Both Dracut and
On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb wrote:
> I've always used Lilo, which is simple + reliable :
> I never see questions re it here, but there are many re Grub.
> I do use recent hardware, a cutting-edge machine I built 6 mth ago .
> When setting it up, I suppressed
On Sat, Apr 9, 2016 at 8:27 AM, Luca Barbato <lu_z...@gentoo.org> wrote:
> On 09/04/16 13:53, Rich Freeman wrote:
>> Put the very same stuff in the initramfs? Most initramfs creation
>> scripts should already do this automatically, and with compat symlinks
>> eve
On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato wrote:
> On 05/04/16 03:19, William Hubbs wrote:
>> Thoughts on any of this?
>
> The whole usr-merge moves the problem of putting stuff in / to putting
> the very same stuff in the initrd when something different from busybox
> (or
On Sat, Apr 9, 2016 at 1:32 AM, wrote:
>
> now - an arbitrary decree comes down that *EVERYBODY* who wants a
> separate /usr needs to have initramfs.
>
The "decree" wasn't some kind of law that the Gentoo police will come
out to your house and arrest you for violating.
On Sat, Apr 9, 2016 at 12:06 AM, Anthony G. Basile <bluen...@gentoo.org> wrote:
> On 4/8/16 11:03 PM, Rich Freeman wrote:
>>
>> What problems are you anticipating, especially in light of the fact
>> that many distros actually do it this way already?
>
> RBAC polic
On Fri, Apr 8, 2016 at 9:51 PM, Anthony G. Basile wrote:
>
> Alternatively, this may introduce problems. So it seems like we're
> fixing something that isn't broken.
>
What problems are you anticipating, especially in light of the fact
that many distros actually do it this
On Fri, Apr 8, 2016 at 4:18 PM, Joseph Booker wrote:
> The difference between "system software" and "regular applications" isn't
> clear-cut.
>
This.
Half the reason we don't officially support running without /usr
mounted during early boot is that if we actually put
On Fri, Apr 8, 2016 at 11:14 AM, M. J. Everitt wrote:
> Being serious though, and playing Devil's Advocate of course, assuming
> you have no use for a desktop manager, etc, hence no need for dbus or
> it's 'friends' and policykit or it's pals, and you're not a "systemd
> fan"
501 - 600 of 2140 matches
Mail list logo