[gentoo-dev] Re: mbox -- looks sort of interesting

On 02/11/2014 11:36 AM, Jason A. Donenfeld wrote: > Hey folks, > > Late night clicking-while-drooling, I came across something a few > minutes ago that mildly piqued my interest -- mbox > . It's a sandbox that uses a > combination of ptrace and seccomp bpf; neither

Re: [gentoo-dev] mbox -- looks sort of interesting

On 02/11/14 01:36, Jason A. Donenfeld wrote: > Hey folks, > > Late night clicking-while-drooling, I came across something a few > minutes ago that mildly piqued my interest -- mbox > . It's a sandbox that uses a > combination of ptrace and seccomp bpf; neither our

Re: [gentoo-dev] dev-lang/go

On Mon, 30 Dec 2013 15:48:17 -0500 Emery Hemingway wrote: > I really like working with Go, and would like to see a means of > merging Go packages with Portage. In short I am asking if anyone else > is interested in a Go project. I might be. I have packaged something for private use but it just a

[gentoo-dev] mbox -- looks sort of interesting

Hey folks, Late night clicking-while-drooling, I came across something a few minutes ago that mildly piqued my interest -- mbox . It's a sandbox that uses a combination of ptrace and seccomp bpf; neither ours nor exherbo's uses both of these together. The killer fe

Re: [gentoo-dev] gentoo-x86 and git

On Mon, Feb 10, 2014 at 7:00 PM, yac wrote: > While you are it, it would be great if you could get some stats on > frequency of commits. Especially with reagrd to the planned cvs -> git > migration since this might cause some issues/inconvenience if the whole > portage will be one git repo. Oh, c

Re: [gentoo-dev] gentoo-x86 and git

On Mon, Feb 10, 2014 at 4:00 PM, yac wrote: > On Mon, 10 Feb 2014 20:33:27 +0800 > Patrick Lauer wrote: > > > Ahoi, > > > > I've been looking for a clean git-converted gentoo-x86 repo for ... > > well ... mostly data mining as cvs / anoncvs.g.o is too slow for some > > things. > > > > While you

Re: [gentoo-dev] gentoo-x86 and git

On Mon, 10 Feb 2014 20:33:27 +0800 Patrick Lauer wrote: > Ahoi, > > I've been looking for a clean git-converted gentoo-x86 repo for ... > well ... mostly data mining as cvs / anoncvs.g.o is too slow for some > things. > While you are it, it would be great if you could get some stats on frequen

Re: [gentoo-dev] gentoo-x86 and git

On Mon, Feb 10, 2014 at 1:17 PM, Robin H. Johnson wrote: > On Mon, Feb 10, 2014 at 08:33:27PM +0800, Patrick Lauer wrote: > > Ahoi, > > > > I've been looking for a clean git-converted gentoo-x86 repo for ... well > > ... mostly data mining as cvs / anoncvs.g.o is too slow for some things. > > > >

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 10/02/2014 22:56, Alec Warner wrote: > On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon > wrote: > > On 10/02/2014 18:05, Ulrich Mueller wrote: > >> Removing support for it from a package manager should of course > >> > happen much later (well after it

Re: [gentoo-dev] gentoo-x86 and git

On Mon, Feb 10, 2014 at 08:33:27PM +0800, Patrick Lauer wrote: > Ahoi, > > I've been looking for a clean git-converted gentoo-x86 repo for ... well > ... mostly data mining as cvs / anoncvs.g.o is too slow for some things. > > This has been needlessly challenging, which confuses me a bit. > > Fi

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon wrote: > On 10/02/2014 18:05, Ulrich Mueller wrote: > >> Removing support for it from a package manager should of course > >> > happen much later (well after it is banned). > > The package manager must be able to uninstall old packages, which > > esse

Re: [gentoo-dev] gentoo-x86 and git

On Mon, Feb 10, 2014 at 4:33 AM, Patrick Lauer wrote: > Ahoi, > > I've been looking for a clean git-converted gentoo-x86 repo for ... well > ... mostly data mining as cvs / anoncvs.g.o is too slow for some things. > > This has been needlessly challenging, which confuses me a bit. > > First, a lit

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 21:46:56 +0800 Patrick Lauer wrote: >On 02/10/2014 09:23 PM, Anthony G. Basile wrote: >> The statement "Deprecating an EAPI can mean breakage" depends on >> what we mean by "deprecating." I'm assuming here we mean something >> like repoman won't allow commits at EAPI=1,2,3 but

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 12:20 PM, Tom Wijsman wrote: > On Mon, 10 Feb 2014 17:05:22 +0100 > Ulrich Mueller wrote: >> The package manager must be able to uninstall old packages, which >> essentially means that support for old EAPIs cannot be removed. > > That's only a subset of the entire EAPI, wh

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 17:05:22 +0100 Ulrich Mueller wrote: > > On Mon, 10 Feb 2014, Rich Freeman wrote: > > > On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller > > wrote: > >> I'd rather argue in terms of time instead of version numbers, > >> because of the upgrade path for old systems. We gua

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 16:16:42 + Ciaran McCreesh wrote: > > From my limited look at the code I've done so far in the small bit > > of repoman work on the Portage team, as detailed in another mail I > > just sent to you on this ML, I wouldn't consider it as a problem > > just now. > > > > We fo

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 10/02/2014 18:05, Ulrich Mueller wrote: >> Removing support for it from a package manager should of course >> > happen much later (well after it is banned). > The package manager must be able to uninstall old packages, which > essentially means that support for old EAPIs cannot be removed. I f

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 15:58:23 +0100 Tom Wijsman wrote: > On Mon, 10 Feb 2014 09:41:13 -0500 > Rich Freeman wrote: > > On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman > > wrote: > > > Well, that package maintainers are called developers on Gentoo > > > isn't helping the interpretation here; regardles

Re: [gentoo-dev] [RFC] Tightening EAPI rules

> On Mon, 10 Feb 2014, Rich Freeman wrote: > On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller > wrote: >> I'd rather argue in terms of time instead of version numbers, >> because of the upgrade path for old systems. We guarantee one year >> for stable systems, but IMHO we should be more conse

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller wrote: > I'd rather argue in terms of time instead of version numbers, because > of the upgrade path for old systems. We guarantee one year for stable > systems, but IMHO we should be more conservative for EAPI deprecation > and go for two or three

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 02/10/2014 09:35 AM, Tom Wijsman wrote: one and possibly needed features. You will connect the question of >"are we ready to deprecate X" with the question "we need to introduce >Y for needed features a, b and c." It is hard to grasp for me for when features from a newer EAPI would delay the

Re: [gentoo-dev] [RFC] Tightening EAPI rules

> On Mon, 10 Feb 2014, Patrick Lauer wrote: > On 02/10/2014 09:23 PM, Anthony G. Basile wrote: >> I think we should look at the question of deprecating EAPI's on and >> ad hoc basis with discussion on the list and a vote in the council. +1 > I think it's safe to deprecate the antepenultimate

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 08:34:00 -0500 Rich Freeman wrote: > On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer > wrote: > > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) > > Does "adding" in this case include revbumps? Yes; though, we kind of expect rev bumps to include multiple fixes if

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 09:41:13 -0500 Rich Freeman wrote: > On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman > wrote: > > Well, that package maintainers are called developers on Gentoo isn't > > helping the interpretation here; regardless of how one defines > > those, both maintainers and PM implemente

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman wrote: > Well, that package maintainers are called developers on Gentoo isn't > helping the interpretation here; regardless of how one defines those, > both maintainers and PM implementers have to be taken into account here. > > From quick thoughts the

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 08:23:51 -0500 "Anthony G. Basile" wrote: > On 02/10/2014 07:43 AM, Patrick Lauer wrote: > > EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree > > (EAPI 6, most likely) > > I am concerned about making this a "rule". Maybe rather a rule with exceptions, or

Re: [gentoo-dev] [RFC] Tightening EAPI rules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/02/14 08:46 AM, Patrick Lauer wrote: > On 02/10/2014 09:23 PM, Anthony G. Basile wrote: >> The statement "Deprecating an EAPI can mean breakage" depends on >> what we mean by "deprecating." I'm assuming here we mean >> something like repoman w

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 14:24:39 +0100 Dirkjan Ochtman wrote: > On Mon, Feb 10, 2014 at 2:21 PM, Tom Wijsman > wrote: > > Apart from that, they however sit in the way of deprecating support > > for that EAPI; at one point it becomes tedious to have to support > > 10 EAPIs in our code (eg. Portage),

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 8:46 AM, Patrick Lauer wrote: > I think it's safe to deprecate the antepenultimate EAPI, and then do the > banning on a more delayed and controlled basis. Yeah, I don't think we need to overly debate deprecation, other than in corner cases like the toolchain (just that min

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 02/10/2014 09:23 PM, Anthony G. Basile wrote: > The statement "Deprecating an EAPI can mean breakage" depends on what we > mean by "deprecating." I'm assuming here we mean something like repoman > won't allow commits at EAPI=1,2,3 but that ebuilds in the tree at those > EAPI's will continue wor

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 02/10/2014 09:34 PM, Rich Freeman wrote: > On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer wrote: >> Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) > > Does "adding" in this case include revbumps? By the design of our repo structure and repoman, yes. (I don't see a clean way around

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer wrote: > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) Does "adding" in this case include revbumps? > More than two supported EAPIs is an unneeded burden on developers. Is this really a generally held belief? I don't find it a burden t

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 2:21 PM, Tom Wijsman wrote: > Apart from that, they however sit in the way of deprecating support for > that EAPI; at one point it becomes tedious to have to support 10 EAPIs > in our code (eg. Portage), hence we should aim to deprecate versions of > a few years old. Keepin

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On 02/10/2014 07:43 AM, Patrick Lauer wrote: EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree (EAPI 6, most likely) I am concerned about making this a "rule". While I think its okay for the 4/5/6 move, I'm not sure if it will always be a good idea. 1) "Deprecating" an EAP

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, 10 Feb 2014 14:03:49 +0100 Dirkjan Ochtman wrote: > On Mon, Feb 10, 2014 at 1:43 PM, Patrick Lauer > wrote: > > The daily updated stats [2] show a slow general trend down. > > There's historical data (well, just a few days right now at [3] > > What are you looking at here? .ebuild files

Re: [gentoo-dev] [RFC] Tightening EAPI rules

On Mon, Feb 10, 2014 at 1:43 PM, Patrick Lauer wrote: > The daily updated stats [2] show a slow general trend down. > There's historical data (well, just a few days right now at [3] What are you looking at here? .ebuild files in the tree? Or latest version per-package? Old EAPI versions are obvi

Re: [gentoo-dev] gentoo-x86 and git

On Mon, 10 Feb 2014 20:33:27 +0800 Patrick Lauer wrote: > and it'd be really useful to have the work-in-progress converted repo > online so that people can experiment with it. +1; have seen this come up a few times, would love to experiment some statistics over it myself to see if anything inter

[gentoo-dev] [RFC] Tightening EAPI rules

As previously discussed I would like to suggest that the number of tolerated EAPIs be reduced. There's been some discussion over the last 2+ years, with a weak consensus towards deprecating some EAPIs. What, when and how still isn't decided. So let's add some data so we have a better idea: EAPI St

[gentoo-dev] gentoo-x86 and git

Ahoi, I've been looking for a clean git-converted gentoo-x86 repo for ... well ... mostly data mining as cvs / anoncvs.g.o is too slow for some things. This has been needlessly challenging, which confuses me a bit. First, a little complaint: There used to be some data at git-exp.overlays.gentoo

Re: [gentoo-dev] Thank you

On 02/06/2014 07:30 AM, Canek Peláez Valdés wrote: Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs, so you can go on your daily business if you don't want to read the rest of it. No biggie. Thank you for all the work you guys do and have done. Thank you for not penalize progress