Re: [gentoo-dev] udev and /usr

2011-09-20 Thread Fabian Groffen
On 19-09-2011 19:19:12 -0400, Joshua Kinard wrote: Really, MacOS's filesystem layout is not something anyone in their right mind should deign to mimic/copy. I didn't get that from either of the links you posted. Seems to me the systemd developers are looking at the split as a

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Alex Alexander
On Mon, Sep 19, 2011 at 10:53:15PM +, Duncan wrote: Alex Alexander posted on Tue, 20 Sep 2011 01:14:38 +0300 as excerpted: At the moment, all systems have a SYNC line similar to this: SYNC=rsync://rsync.europe.gentoo.org/gentoo-portage My idea is simple. When incompatible

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Alex Alexander
On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote: On Mon, Sep 19, 2011 at 6:53 PM, Duncan 1i5t5.dun...@cox.net wrote: At least an initial read suggests that you just multiplied the mirror space requirements by however many times you use this trick.  I don't believe infra's going

Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

2011-09-20 Thread Corentin Chary
On Mon, Sep 19, 2011 at 9:23 PM, Hans de Graaff gra...@gentoo.org wrote: On Wed, 2011-08-31 at 15:41 +0200, Corentin Chary wrote: Hi, some news about euscan (still available at http://euscan.iksaif.net) - New design (yay !) - Atom feeds available for each herd/category/maintainer/package

Re: [gentoo-dev] [RFC] obs eclasses

2011-09-20 Thread Michał Górny
On Tue, 13 Sep 2011 13:11:28 +0200 Michal Hrusecky mi...@gentoo.org wrote: please take a look at attached eclasses. Purpose is to make installation of obs services (plugins for osc) easier. Comments and improvements are welcome. I don't get the concept of having two eclasses for this. The

Re: [gentoo-dev] [RFC] obs eclasses

2011-09-20 Thread Tomáš Chvátal
2011/9/20 Michał Górny mgo...@gentoo.org: On Tue, 13 Sep 2011 13:11:28 +0200 Michal Hrusecky mi...@gentoo.org wrote: please take a look at attached eclasses. Purpose is to make installation of obs services (plugins for osc) easier. Comments and improvements are welcome. I don't get the

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Brian Harring
On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote: On Mon, Sep 19, 2011 at 6:53 PM, Duncan 1i5t5.dun...@cox.net wrote: At least an initial read suggests that you just multiplied the mirror space requirements by however many times you use this trick. ?I don't believe infra's going

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Patrick Lauer
On 09/20/11 09:12, Alex Alexander wrote: The only real gotcha is if portage is so old that it can't handle the binary packages. However, to get around that we really just need a set of step-wise binary updates for portage itself so that you can sequence it up to something that can install the

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Ciaran McCreesh
On Tue, 20 Sep 2011 03:28:48 -0700 Brian Harring ferri...@gmail.com wrote: Paludis wise, it's eapi2 indirictely due to boost and eselect. Looking at the eapi depgraph for that, doesn't look particularly viable for upgrading from a EAPI2 manager for paludis. I'll leave it to Ciaran to

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Dirkjan Ochtman
On Tue, Sep 20, 2011 at 12:28, Brian Harring ferri...@gmail.com wrote: Intent is to restore it to EAPI0- frankly it really depends on what the python teams intentions are for EAPI0, currently that support is marked to be removed on 06/2011. We'd have to take a look at the complexity

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Brian Harring
On Tue, Sep 20, 2011 at 11:40:13AM +0100, Ciaran McCreesh wrote: On Tue, 20 Sep 2011 03:28:48 -0700 Brian Harring ferri...@gmail.com wrote: Paludis wise, it's eapi2 indirictely due to boost and eselect. Looking at the eapi depgraph for that, doesn't look particularly viable for

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Ciaran McCreesh
On Tue, 20 Sep 2011 04:07:44 -0700 Brian Harring ferri...@gmail.com wrote: You didn't answer the static question btw... Because the answer's complicated! The short version is, it could be made to work, if there's a need for it, and so long as you've got gcc 4.5 for static libstdc++ support, but

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Pacho Ramos
El mar, 20-09-2011 a las 01:14 +0300, Alex Alexander escribió: EAPI in profiles and the -live version suffix are some of the improvements many people would like to see in the tree. Unfortunately, the risk of breaking systems with old versions of portage has been too high, holding evolution

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Michał Górny
On Tue, 20 Sep 2011 15:09:01 +0200 Pacho Ramos pa...@gentoo.org wrote: I haven't ever tried it but, what would occur if that people with really updated systems simply unpack an updated stage3 tarball in their / and, later, try to update? Possibly at least few file collisions, if portage would

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Pacho Ramos
El mar, 20-09-2011 a las 15:09 +0200, Pacho Ramos escribió: El mar, 20-09-2011 a las 01:14 +0300, Alex Alexander escribió: EAPI in profiles and the -live version suffix are some of the improvements many people would like to see in the tree. Unfortunately, the risk of breaking systems

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Pacho Ramos
El mar, 20-09-2011 a las 15:16 +0200, Michał Górny escribió: On Tue, 20 Sep 2011 15:09:01 +0200 Pacho Ramos pa...@gentoo.org wrote: I haven't ever tried it but, what would occur if that people with really updated systems simply unpack an updated stage3 tarball in their / and, later, try

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Ulrich Mueller
On Tue, 20 Sep 2011, Ciaran McCreesh wrote: Paludis wise, it's eapi2 indirictely due to boost and eselect. The eselect dependency is hard, and can't easily be made optional, so ideally eselect should stick with older EAPIs. Eselect's maintainer is well aware of this. I intend to keep 1.2.15

[gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Duncan
Pacho Ramos posted on Tue, 20 Sep 2011 15:09:01 +0200 as excerpted: I haven't ever tried it but, what would occur if that people with really updated systems simply unpack an updated stage3 tarball in their / and, later, try to update? I believe it was Mike that pointed me at the error in

Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Pacho Ramos
El mar, 20-09-2011 a las 13:57 +, Duncan escribió: Pacho Ramos posted on Tue, 20 Sep 2011 15:09:01 +0200 as excerpted: I haven't ever tried it but, what would occur if that people with really updated systems simply unpack an updated stage3 tarball in their / and, later, try to update?

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Zac Medico
On 09/19/2011 03:14 PM, Alex Alexander wrote: My idea is simple. When incompatible changes have to be introduced to the tree, push a new version of portage that includes support for all the new features we want to provide. Then, freeze the tree and clone it into a revbumped rsync module,

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Zac Medico
On 09/20/2011 08:19 AM, Zac Medico wrote: On 09/19/2011 03:14 PM, Alex Alexander wrote: My idea is simple. When incompatible changes have to be introduced to the tree, push a new version of portage that includes support for all the new features we want to provide. Then, freeze the tree and

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Patrick Lauer
On 09/20/11 15:09, Pacho Ramos wrote: What do you guys think? I haven't ever tried it but, what would occur if that people with really updated systems simply unpack an updated stage3 tarball in their / and, later, try to update? Usually things turn ugly - used to be that portage saw that

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Patrick Lauer
On 09/20/11 17:19, Zac Medico wrote: On 09/19/2011 03:14 PM, Alex Alexander wrote: My idea is simple. When incompatible changes have to be introduced to the tree, push a new version of portage that includes support for all the new features we want to provide. Then, freeze the tree and clone it

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Rich Freeman
On Sep 20, 2011 1:05 PM, Patrick Lauer patr...@gentoo.org wrote: Good idea, but won't work retroactively out of the box. So you'd need a helper script to figure out your current state (using portage version and tree snapshot maybe), then prepare the environment to upgrade (and how do you handle

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Alec Warner
On Tue, Sep 20, 2011 at 10:14 AM, Rich Freeman ri...@gentoo.org wrote: On Sep 20, 2011 1:05 PM, Patrick Lauer patr...@gentoo.org wrote: Good idea, but won't work retroactively out of the box. So you'd need a helper script to figure out your current state (using portage version and tree

Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

2011-09-20 Thread Donnie Berkholz
On 10:00 Tue 20 Sep , Corentin Chary wrote: Could someone write ebuilds for euscan and euscanwww ? It should not take a lot of time, but my ebuilds skills are probably not good enought to do that. Sounds like good practice for when you become a Gentoo dev. =) -- Thanks, Donnie Donnie

Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Michał Górny
On Tue, 20 Sep 2011 10:48:37 -0700 Alec Warner anta...@gentoo.org wrote: On Tue, Sep 20, 2011 at 10:14 AM, Rich Freeman ri...@gentoo.org wrote: On Sep 20, 2011 1:05 PM, Patrick Lauer patr...@gentoo.org wrote: Good idea, but won't work retroactively out of the box. So you'd need a helper

[gentoo-dev] git-2: a bunch of patches to review

2011-09-20 Thread Michał Górny
Hello all, I've prepared a bunch of patches to git-2.eclass. 1-2 -- replacing scary unreadable parts of code with nicer ones. 3-4 -- basically just coding style changes. 5-7 -- little logic simplification. 8 -- eclassdoc fixes. 9 -- prevents environment injection of internal var. 10 --

Re: [gentoo-dev] git-2: a bunch of patches to review

2011-09-20 Thread Tomáš Chvátal
0001 - i had reason to put local definitions on the top, it is way more readable to see right away what local vars function has, so please stick to it. 0004 - Did you ever hear that executing another code in condition is damn annoying to trace? :) 0007 - I placed it into the conditionals to be

Re: [gentoo-dev] git-2: a bunch of patches to review

2011-09-20 Thread Stratos Psomadakis
On 09/20/2011 11:32 PM, Michał Górny wrote: Hello all, I've prepared a bunch of patches to git-2.eclass. Just a suggestion (and maybe a bit off-topic), but I think if you sent each patch separately, as replies to the original thread (git send-email can do that), it would make the review of each

Re: [gentoo-dev] git-2: a bunch of patches to review

2011-09-20 Thread Michał Górny
On Tue, 20 Sep 2011 23:48:36 +0300 Stratos Psomadakis pso...@gentoo.org wrote: On 09/20/2011 11:32 PM, Michał Górny wrote: Hello all, I've prepared a bunch of patches to git-2.eclass. Just a suggestion (and maybe a bit off-topic), but I think if you sent each patch separately, as replies

Re: [gentoo-dev] git-2: a bunch of patches to review

2011-09-20 Thread Michał Górny
On Tue, 20 Sep 2011 22:46:10 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: 0007 - I placed it into the conditionals to be clear what is happening, what if there will be added another if without the push... Well, that part is not important, I can rollback it. It was mostly for the

[gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

2011-09-20 Thread Tomáš Chvátal
Hi guys, as I am now messing around libreo I am meeting a lot packages that none bothered to stablereq since 2009 or so, the versions in ~ are cleaner, more up to date, and possibly contain less bugs. The issue here is that if some part of the tree looses lots of its maintainers we as devs

Re: [gentoo-dev] new `usex` helper

2011-09-20 Thread Brian Harring
On Sun, Sep 18, 2011 at 10:16:46PM -0500, Donnie Berkholz wrote: On 04:22 Sun 18 Sep , Brian Harring wrote: On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote: On 13:43 Fri 16 Sep , Brian Harring wrote: What I said from the getgo and you're missing is that pushing

Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

2011-09-20 Thread Tony Chainsaw Vroon
On Tue, 2011-09-20 at 23:18 +0200, Tomáš Chvátal wrote: Well it would be something like priority based queue with maximum 60 points value. Each update after the month in main tree would get 0 points for stabilisation, any-developer / maintainer would be able to add up to 40 points to any

Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

2011-09-20 Thread Tomáš Chvátal
2011/9/20 Tony Chainsaw Vroon chain...@gentoo.org: On Tue, 2011-09-20 at 23:18 +0200, Tomáš Chvátal wrote: Well it would be something like priority based queue with maximum 60 points value. Each update after the month in main tree would get 0 points for stabilisation, any-developer /

Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

2011-09-20 Thread Patrick Lauer
On 09/20/11 23:18, Tomáš Chvátal wrote: [snipped to bits] So, the issue is obvious, we have packages in testing that are in better shape than stable ones. I'm aware that some of my packages could use a stablereq, but since I don't run any stable machines at the moment it just never bothers me.

[gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

2011-09-20 Thread Duncan
Patrick Lauer posted on Tue, 20 Sep 2011 19:00:38 +0200 as excerpted: On 09/20/11 15:09, Pacho Ramos wrote: What do you guys think? I haven't ever tried it but, what would occur if that people with really updated systems simply unpack an updated stage3 tarball in their / and, later, try