Re: [gentoo-dev] Regarding "consolekit" meaning in some ebuilds

El lun, 19-08-2013 a las 10:30 -0400, Ian Stakenvicius escribió: > On 19/08/13 08:49 AM, Pacho Ramos wrote: > > I have seen some ebuilds (just seen bluez one) that are using > > "consolekit" USE flag to not force plugdev group usage (as it's not > > used on consolekit/logind setups). The problem i

[gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

Hello, fellow developers. I've added a few new fancy features for Gentoo developers to portage git. Sadly, since Zac isn't planning another release until 2.2.0 goes stable, you need to switch to - to use them. But I say to you, it's worth the hassle. The features are off by default since they

[gentoo-dev] Staging 'einstalldocs' for EAPI 6

Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. When it's mostly defined, we'd like to backport it to eutils.eclass so that we could use it to fix t

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

On 20 August 2013 11:26, Michał Górny wrote: > Hello, fellow developers. > > I've added a few new fancy features for Gentoo developers to portage > git. Sadly, since Zac isn't planning another release until 2.2.0 goes > stable, you need to switch to - to use them. But I say to you, it's > wort

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

20.08.2013 14:26, Michał Górny пишет: > Hello, fellow developers. > > I've added a few new fancy features for Gentoo developers to portage > git. Sadly, since Zac isn't planning another release until 2.2.0 goes > stable, you need to switch to - to use them. But I say to you, it's > worth the h

[gentoo-dev] Re: [gentoo-dev-announce] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

El mar, 20-08-2013 a las 12:26 +0200, Michał Górny escribió: > Hello, fellow developers. > > I've added a few new fancy features for Gentoo developers to portage > git. Sadly, since Zac isn't planning another release until 2.2.0 goes > stable, you need to switch to - to use them. But I say to

Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6

> On Tue, 20 Aug 2013, Michał Górny wrote: > 1. Name > - einstalldocs > -- probably the least confusing one, consistent with emake Go for it. > 2. Support for HTML_DOCS I've no strong opinion about this one. But if you are going to add it, then please support both array and whitespace

Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6

On 08/20/2013 01:54 PM, Ulrich Mueller wrote: >> For example, hasufell has suggested checking ${DOCS// /} to support >> DOCS=' ' as well. > > Looks like over-engineering to me. Are there any use cases for it? > No, just caution, so we don't have to realize that our default src_install is broke

Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6

20.08.2013 16:08, hasufell пишет: > I don't see how defining phases explicitly improves readability which > even increases chances of overwriting phases by accident and having > further complications especially in multilib eclasses. > > DOCS=( foo* ) > > looks pretty readable to me > I am not f

Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6

Dnia 2013-08-20, o godz. 16:26:10 Sergey Popov napisał(a): > 20.08.2013 16:08, hasufell пишет: > > I don't see how defining phases explicitly improves readability which > > even increases chances of overwriting phases by accident and having > > further complications especially in multilib eclasse

Re: [gentoo-dev] Re: [gentoo-dev-announce] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

Dnia 2013-08-20, o godz. 13:42:38 Pacho Ramos napisał(a): > El mar, 20-08-2013 a las 12:26 +0200, Michał Górny escribió: > [...] > > 2. FEATURES=network-sandbox > [...] > > This one's going to trigger a lot of breakage in ebuilds. Therefore, > > I'd appreciate if developers started using it early

Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6

Dnia 2013-08-20, o godz. 14:08:51 hasufell napisał(a): > On 08/20/2013 01:54 PM, Ulrich Mueller wrote: > >> 4. Globbing support in DOCS array > >> 5. Appending to DOCS > > > > Creeping featurism. Define an explicit src_install if you need any of > > these, and I'm sure it will improve readabilit

Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6

20.08.2013 17:02, Michał Górny пишет: > Is there a future-eapi bug open for it? If not, please open one. I will, thanks > I myself don't have anything against plain 'dodoc -r'. But I wonder if > this isn't going to end up with people considering 'what if my > directory has .svn/CVS in it?' > {e

Re: [gentoo-dev] gtk2/gtk3 use flags

16.08.2013 21:15, hasufell пишет: > https://bugs.gentoo.org/show_bug.cgi?id=420493 > > gtk2 and gtk3 useflags are discouraged and should only be used in > special cases > > file a bug for those if there is not one already What's about maintainer wish to support both of toolkits? I have dropped G

Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/08/13 08:08 AM, hasufell wrote: > On 08/20/2013 01:54 PM, Ulrich Mueller wrote: >>> 4. Globbing support in DOCS array 5. Appending to DOCS >> >> Creeping featurism. Define an explicit src_install if you need >> any of these, and I'm sure it wi

Re: [gentoo-dev] gtk2/gtk3 use flags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/08/13 09:31 AM, Sergey Popov wrote: > 16.08.2013 21:15, hasufell пишет: >> https://bugs.gentoo.org/show_bug.cgi?id=420493 >> >> gtk2 and gtk3 useflags are discouraged and should only be used >> in special cases >> >> file a bug for those if t

Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6

On Tue, 20 Aug 2013 13:01:34 +0200 Michał Górny wrote: > 3. Support DOCS=() / DOCS='' to disable dodoc > >https://bugs.gentoo.org/show_bug.cgi?id=463736 > > Well, this one is mostly what the bug is about. I think we should just > do it. Implementation could be discussed a bit though. > > F

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2013 06:26 AM, Michał Górny wrote: > Hello, fellow developers. > > I've added a few new fancy features for Gentoo developers to portage > git. Sadly, since Zac isn't planning another release until 2.2.0 goes > stable, you need to switch to -9

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

On Tue, 20 Aug 2013 12:26:03 +0200 Michał Górny wrote: > > 2. FEATURES=network-sandbox > does distcc work with this ? Alexis.

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

On Aug 20, 2013 10:58 AM, "Rick "Zero_Chaos" Farina" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/20/2013 06:26 AM, Michał Górny wrote: > > Hello, fellow developers. > > > > I've added a few new fancy features for Gentoo developers to portage > > git. Sadly, since Zac isn't

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

Dnia 2013-08-20, o godz. 11:04:35 Alexis Ballier napisał(a): > On Tue, 20 Aug 2013 12:26:03 +0200 > Michał Górny wrote: > > > > 2. FEATURES=network-sandbox > > > > does distcc work with this ? You could say that. It just can't connect to any other host :). We may try to handle this somehow

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

On Aug 20, 2013 11:20 AM, "Michał Górny" wrote: > > Dnia 2013-08-20, o godz. 11:04:35 > Alexis Ballier napisał(a): > > > On Tue, 20 Aug 2013 12:26:03 +0200 > > Michał Górny wrote: > > > > > > 2. FEATURES=network-sandbox > > > > > > > does distcc work with this ? > > You could say that. It just c

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/08/13 11:30 AM, Douglas Freed wrote: > On Aug 20, 2013 11:20 AM, "Michał Górny" > wrote: >> >> Dnia 2013-08-20, o godz. 11:04:35 Alexis Ballier >> mailto:aball...@gentoo.org>> > napisał(a): >> >>> On Tue, 20 Aug 201

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

On 20/08/13 11:42 AM, Ian Stakenvicius wrote: > It's a feature; all features are optional. It's just not going to be > able to be enabled along with FEATURES="distcc" is all. I'm sure we > have other features that collide with one-another too, so i don't see > this being a big issue. FEATURES="n

Re: [gentoo-dev] Re: [gentoo-dev-announce] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

El mar, 20-08-2013 a las 14:58 +0200, Michał Górny escribió: > Dnia 2013-08-20, o godz. 13:42:38 > Pacho Ramos napisał(a): > > > El mar, 20-08-2013 a las 12:26 +0200, Michał Górny escribió: > > [...] > > > 2. FEATURES=network-sandbox > > [...] > > > This one's going to trigger a lot of breakage i

[gentoo-dev] rfc: stabilization policies

All, I'm not really sure what the answer to this problem is, so I want to know what the group thinks about how we can handle it. During the last release of OpenRC, I learned that people *do* run production servers on ~arch. I asked about it and was told that the reason for this is bitrot in the s

Re: [gentoo-dev] rfc: stabilization policies

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/08/13 02:19 PM, William Hubbs wrote: > All, > > I'm not really sure what the answer to this problem is, so I want > to know what the group thinks about how we can handle it. > > During the last release of OpenRC, I learned that people *do* ru

Re: [gentoo-dev] rfc: stabilization policies

On Tue, Aug 20, 2013 at 2:19 PM, William Hubbs wrote: > > During the last release of OpenRC, I learned that people *do* run > production servers on ~arch. I asked about it and was told that the > reason for this is bitrot in the stable tree. > This right here seems strange to me. What things in s

Re: [gentoo-dev] rfc: stabilization policies

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/08/13 02:29 PM, Wyatt Epp wrote: > On Tue, Aug 20, 2013 at 2:19 PM, William Hubbs > wrote: >> >> During the last release of OpenRC, I learned that people *do* >> run production servers on ~arch. I asked about it and was told >> that the reaso

Re: [gentoo-dev] rfc: stabilization policies

On Tue, Aug 20, 2013 at 8:29 PM, Wyatt Epp wrote: > This right here seems strange to me. What things in stable are > undergoing bitrot? What manner of bitrot? On what architectures? Yeah, something slightly more specific would be useful here. I run my servers with stable with just a few packa

Re: [gentoo-dev] rfc: stabilization policies

On Tue, 20 Aug 2013 13:19:10 -0500 William Hubbs wrote: > All, > > I'm not really sure what the answer to this problem is, so I want to > know what the group thinks about how we can handle it. > > During the last release of OpenRC, I learned that people *do* run > production servers on ~arch.

Re: [gentoo-dev] rfc: stabilization policies

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius wrote: > I see a few issues with ~arch -> table migrations: > #1 - things just sit in ~arch. The auto-stablereq script should help > with this one I think; we should give it some time to see if it

Re: [gentoo-dev] rfc: stabilization policies

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius wrote: > #1 - things just sit in ~arch. The auto-stablereq script should help > with this one I think; we should give it some time to see if it works > out. As an alternative, how about a new keywo

Re: [gentoo-dev] rfc: stabilization policies

On Tue, Aug 20, 2013 at 3:24 PM, Tom Wijsman wrote: > While I don't, and asked it just because of the large amount; it > appears from some things lately, and not just OpenRC, that there is a > certain group that regards ~arch as some kind of new stable. People have been talking about that for yea

Re: [gentoo-dev] rfc: stabilization policies

On Tue, 20 Aug 2013 14:29:09 -0400 Wyatt Epp wrote: > On Tue, Aug 20, 2013 at 2:19 PM, William Hubbs > wrote: > What things in stable are undergoing bitrot? Things that are too old; see 'imlate' from app-portage/gentoolkit-dev, this can be handy to indicate stabilization candidates. You can try

Re: [gentoo-dev] rfc: stabilization policies

On Tue, 20 Aug 2013 20:45:05 +0200 Dirkjan Ochtman wrote: > On Tue, Aug 20, 2013 at 8:29 PM, Wyatt Epp > wrote: > > This right here seems strange to me. What things in stable are > > undergoing bitrot? What manner of bitrot? On what architectures? > > Yeah, something slightly more specific w

Re: [gentoo-dev] rfc: stabilization policies

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 20:37:17 +0100 Ciaran McCreesh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tue, 20 Aug 2013 14:28:15 -0400 > Ian Stakenvicius wrote: > > #1 - things just sit in ~arch. The auto-stablereq script should > > he

Re: [gentoo-dev] rfc: stabilization policies

On 20/08/2013 21:24, Tom Wijsman wrote: > On Tue, 20 Aug 2013 13:19:10 -0500 > William Hubbs wrote: > >> All, >> >> I'm not really sure what the answer to this problem is, so I want to >> know what the group thinks about how we can handle it. >> >> During the last release of OpenRC, I learned tha

Re: [gentoo-dev] rfc: stabilization policies

On Tue, 20 Aug 2013 15:41:42 -0400 Rich Freeman wrote: > > Let me dig up an example... > > > > Our last sys-kernel/gentoo-sources stabilization was 3 months ago: > > I don't really see a problem with stable package being all of 3 months > old. Contrast that with youtube-dl which pull from ~arch

Re: [gentoo-dev] rfc: stabilization policies

On 08/20/2013 02:19 PM, William Hubbs wrote: > My question is, how can we improve our stabilization procedures/policies > so we can convince people not to run production servers on ~arch and > keep the stable tree more up to date? Just delete /etc/conf.d/net with an ~arch update every once in a wh

Re: [gentoo-dev] rfc: stabilization policies

On 08/20/2013 08:19 PM, William Hubbs wrote: > > My question is, how can we improve our stabilization procedures/policies > so we can convince people not to run production servers on ~arch and > keep the stable tree more up to date? > Why convince them? They have been warned and it's their own p

Re: [gentoo-dev] rfc: stabilization policies

On Tue, 20 Aug 2013 22:00:52 +0200 Alan McKinnon wrote: > As a long time user and citizen of -user I can tell you what the > general feeling of arch vs ~arch there is: Thanks for jumping into the discussion. > arch has plenty old stuff in it Yes, it keeps me from using it; I would have to unma

Re: [gentoo-dev] rfc: stabilization policies

Am Dienstag, 20. August 2013, 20:19:10 schrieb William Hubbs: > > I'm not really sure what the answer to this problem is, so I want to > know what the group thinks about how we can handle it. > > During the last release of OpenRC, I learned that people *do* run > production servers on ~arch. I as

Re: [gentoo-dev] rfc: stabilization policies

On Tue, 20 Aug 2013 22:16:34 +0200 hasufell wrote: > On 08/20/2013 08:19 PM, William Hubbs wrote: > > > > My question is, how can we improve our stabilization > > procedures/policies so we can convince people not to run production > > servers on ~arch and keep the stable tree more up to date? >

Re: [gentoo-dev] rfc: stabilization policies

On Tue, Aug 20, 2013 at 04:12:45PM -0400, Michael Orlitzky wrote > On 08/20/2013 02:19 PM, William Hubbs wrote: > > My question is, how can we improve our stabilization > > procedures/policies so we can convince people not to run production > > servers on ~arch and keep the stable tree more up to d

Re: [gentoo-dev] rfc: stabilization policies

On Tue, Aug 20, 2013 at 5:05 PM, Tom Wijsman wrote: > > At least the numbers for the year sound like something we will want to > deal with; from there, we could try to keep half a year low. And after > a while, we might end up ensuring stabilization within 3 months. > > That's still three times mo

Re: [gentoo-dev] gtk2/gtk3 use flags

Le samedi 17 août 2013 à 15:33 +0300, Samuli Suominen a écrit : > On 16/08/13 20:12, Michael Weber wrote: > > Hello, > > > > gtk is a global use flag [1], gtk2 and gtk3 are used in metadata.xml [2]. > > > > Is there a consensus how to use these flags if an app provides gtk2 > > and gtk3 gui in para

Re: [gentoo-dev] gtk2/gtk3 use flags

Le mardi 20 août 2013 à 17:31 +0400, Sergey Popov a écrit : > 16.08.2013 21:15, hasufell пишет: > > https://bugs.gentoo.org/show_bug.cgi?id=420493 > > > > gtk2 and gtk3 useflags are discouraged and should only be used in > > special cases > > > > file a bug for those if there is not one already >

Re: [gentoo-dev] rfc: stabilization policies

On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel wrote: > > Stable implies "not so often changing". If you really need newer packages on a > system that has to be rock-solid, then keyword what you need and nothing else. ++ 30 days is too long? How can something new be stable? Stable doesn't

Re: [gentoo-dev] rfc: stabilization policies

On Tue, Aug 20, 2013 at 7:42 PM, Rich Freeman wrote: > On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel > wrote: > > > > Stable implies "not so often changing". If you really need newer > packages on a > > system that has to be rock-solid, then keyword what you need and nothing > else. > > ++

Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

On 8/20/13 3:26 AM, Michał Górny wrote: > I've added a few new fancy features for Gentoo developers to portage > git. Sadly, since Zac isn't planning another release until 2.2.0 goes > stable, you need to switch to - to use them. But I say to you, it's > worth the hassle. > > I'd really apprec

Re: [gentoo-dev] rfc: stabilization policies

On 8/20/13 11:19 AM, William Hubbs wrote: > During the last release of OpenRC, I learned that people *do* run > production servers on ~arch. I asked about it and was told that the > reason for this is bitrot in the stable tree. People frequently point to lack of manpower as reason for this, but I

Re: [gentoo-dev] gtk2/gtk3 use flags

On 21 August 2013 07:36, Gilles Dartiguelongue wrote: > Le mardi 20 août 2013 à 17:31 +0400, Sergey Popov a écrit : >> 16.08.2013 21:15, hasufell пишет: >> > https://bugs.gentoo.org/show_bug.cgi?id=420493 >> > >> > gtk2 and gtk3 useflags are discouraged and should only be used in >> > special case

Re: [gentoo-dev] rfc: stabilization policies

On 21 August 2013 04:12, Michael Orlitzky wrote: > [snip] > Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and > 3.0 was released almost exactly three years ago. Every time rails-3.x > gets bumped, I have to manually update the entire list above. I need > to do it on an x86 ser

[gentoo-dev] Re: rfc: stabilization policies

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/20/2013 04:12 PM, Michael Orlitzky wrote: >> # Redmine =dev-ruby/builder-3.1.4 ~amd64 =dev-ruby/rails-3.2.13 ~amd64 >> =dev-ruby/railties-3.2.13 ~amd64 =dev-ruby/actionmailer-3.2.13 ~amd64 >> =dev-ruby/builder-3.0.4 >> ~amd64 =dev-ruby/arel-3

Re: [gentoo-dev] rfc: stabilization policies

On 20/08/2013 22:25, Tom Wijsman wrote: > On Tue, 20 Aug 2013 22:00:52 +0200 > Alan McKinnon wrote: > >> As a long time user and citizen of -user I can tell you what the >> general feeling of arch vs ~arch there is: > > Thanks for jumping into the discussion. > >> arch has plenty old stuff in i

[gentoo-dev] Re: rfc: stabilization policies

On 21/08/2013 05:31, Tom Wijsman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius wrote: I see a few issues with ~arch -> table migrations: #1 - things just sit in ~arch. The auto-stablereq script should help with this one I think; w

Re: [gentoo-dev] rfc: stabilization policies

On Aug 20, 2013, at 11:19 AM, William Hubbs wrote: > > My question is, how can we improve our stabilization procedures/policies > so we can convince people not to run production servers on ~arch and > keep the stable tree more up to date? do the Arch Linux thing…keep just one version of a packag

Re: [gentoo-dev] rfc: stabilization policies

On 21/08/2013 03:54, Doug Goldstein wrote: > Its also precisely that mix and match that might cause instability due > to people not testing things. Case in point QEMU 1.6.0 just came out and > it went through a number of release candidates but no one ever saw that > it depends only on Python 2.4 bu