Re: [gentoo-dev] RFC: Eclasses and EAPI

2016-09-06 Thread Rich Freeman
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

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

2016-08-31 Thread Rich Freeman
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

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

2016-08-31 Thread Rich Freeman
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

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Rich Freeman
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

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Rich Freeman
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

Re: [gentoo-dev] Re: rfc: /etc/hostname on gentoo

2016-08-25 Thread Rich Freeman
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

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Rich Freeman
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

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Rich Freeman
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). >

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Rich Freeman
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 >

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Rich Freeman
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

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Rich Freeman
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 >

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Rich Freeman
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

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Rich Freeman
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

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Rich Freeman
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

Re: [gentoo-dev] Developers, please work on underlinking issues!

2016-08-19 Thread Rich Freeman
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: >> >&

Re: [gentoo-dev] Developers, please work on underlinking issues!

2016-08-18 Thread Rich Freeman
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

Re: [gentoo-dev] Developers, please work on underlinking issues!

2016-08-18 Thread Rich Freeman
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

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

2016-08-17 Thread Rich Freeman
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

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

2016-08-15 Thread Rich Freeman
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

Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

2016-08-15 Thread Rich Freeman
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

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

2016-08-15 Thread Rich Freeman
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

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

2016-08-15 Thread Rich Freeman
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 >

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

2016-08-15 Thread Rich Freeman
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 >

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

2016-08-12 Thread Rich Freeman
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 >

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

2016-08-11 Thread Rich Freeman
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

Re: [gentoo-dev] Re: Packages up for grabs

2016-08-07 Thread Rich Freeman
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

Re: [gentoo-dev] Re: Packages up for grabs

2016-08-07 Thread Rich Freeman
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,

Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Rich Freeman
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

Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Rich Freeman
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

Re: [gentoo-dev] Signed push & clock drift rejection

2016-07-18 Thread Rich Freeman
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

Re: [gentoo-dev] the graveyard overlay

2016-07-08 Thread Rich Freeman
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

Re: [gentoo-dev] the graveyard overlay

2016-07-08 Thread Rich Freeman
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

Re: [gentoo-dev] the graveyard overlay

2016-07-08 Thread Rich Freeman
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 >

Re: Re: [gentoo-dev] masking and removing *coin packages

2016-07-08 Thread Rich Freeman
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 >

Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Rich Freeman
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 >

Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Rich Freeman
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

Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Rich Freeman
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

Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-05 Thread Rich Freeman
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

Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-05 Thread Rich Freeman
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

Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-04 Thread Rich Freeman
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

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

2016-07-01 Thread Rich Freeman
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 >

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

2016-06-30 Thread Rich Freeman
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

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

2016-06-30 Thread Rich Freeman
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

Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

2016-06-29 Thread Rich Freeman
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 >

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

2016-06-17 Thread Rich Freeman
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

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

2016-06-17 Thread Rich Freeman
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

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

2016-06-17 Thread Rich Freeman
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

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

2016-06-17 Thread Rich Freeman
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

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

2016-06-17 Thread Rich Freeman
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

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

2016-06-17 Thread Rich Freeman
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 >>

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

2016-06-17 Thread Rich Freeman
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 >

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Rich Freeman
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

Re: [gentoo-dev] Council Council: call for agenda items for June 12 meeting

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

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Rich Freeman
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

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Rich Freeman
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

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Rich Freeman
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

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Rich Freeman
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

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Rich Freeman
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

Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-07 Thread Rich Freeman
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

Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-02 Thread Rich Freeman
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 >

Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-02 Thread Rich Freeman
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

Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-02 Thread Rich Freeman
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

Re: [gentoo-dev] What are eblits?

2016-05-29 Thread Rich Freeman
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

Re: [gentoo-dev] What are eblits?

2016-05-29 Thread Rich Freeman
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

Re: [gentoo-dev] Proposal for changes for the next EAPI version

2016-05-17 Thread Rich Freeman
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 >>

Re: [gentoo-dev] Proposal for changes for the next EAPI version

2016-05-17 Thread Rich Freeman
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

Re: [gentoo-dev] Proposal for changes for the next EAPI version

2016-05-17 Thread Rich Freeman
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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-15 Thread Rich Freeman
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,

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Rich Freeman
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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Rich Freeman
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"

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Rich Freeman
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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Rich Freeman
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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Rich Freeman
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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Rich Freeman
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

Re: [gentoo-dev] On banning merge commits

2016-05-11 Thread Rich Freeman
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

Re: [gentoo-dev] amd64 and x32 systemd stages should be ready

2016-05-09 Thread Rich Freeman
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

Re: [gentoo-dev] On banning merge commits

2016-05-09 Thread Rich Freeman
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

Re: [gentoo-dev] amd64 and x32 systemd stages should be ready

2016-05-09 Thread Rich Freeman
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

Re: [gentoo-dev] On banning merge commits

2016-05-09 Thread Rich Freeman
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

Re: [gentoo-dev] On banning merge commits

2016-05-08 Thread Rich Freeman
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

Re: [gentoo-dev] On banning merge commits

2016-05-08 Thread Rich Freeman
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

Re: [gentoo-dev] Reminder: ALLARCHES

2016-05-01 Thread Rich Freeman
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

Re: [gentoo-dev] Reminder: ALLARCHES

2016-04-30 Thread Rich Freeman
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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-04-16 Thread Rich Freeman
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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-04-16 Thread Rich Freeman
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

Re: [gentoo-dev] usr merge

2016-04-10 Thread Rich Freeman
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

Re: [gentoo-dev] Re: usr merge

2016-04-10 Thread Rich Freeman
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 >

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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 >

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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, >

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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 >

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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 / >

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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.

Re: [gentoo-dev] usr merge

2016-04-09 Thread Rich Freeman
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

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
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

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
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

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
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"

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