Re: [gentoo-dev] new profile layout with flavors and mix-ins

On Wed, Jul 2, 2014 at 2:32 PM, Anthony G. Basile wrote: > Shallow profiles avoid this. Also "features" avoid this (the > closest thing we have to mix-ins) provided they operate on a set of > flags/packages orthogonal to the rest of the stack. You then have shallow > base and you can add as man

Re: [gentoo-dev] new profile layout with flavors and mix-ins

On Wed, Jul 2, 2014 at 3:19 PM, Rick "Zero_Chaos" Farina wrote: > > On 07/02/2014 03:07 PM, Anthony G. Basile wrote: >> >> I don't know how to get from here to there. The problem isn't just >> constructing an alternative profile tree. We could even have >> /usr/portage/profiles-r2 and switch bet

Re: [gentoo-dev] Making a common sub-profile for no-multilib

On Thu, Jul 3, 2014 at 8:07 AM, Peter Stuge wrote: > This can't work; abi/x86 can't be both a file and a subdir. Profiles ARE subdirs. Most of our existing profiles are stacked in this way. This would become less-so if we went with the mix-in approach, but it wouldn't be entirely flat in this p

Re: [gentoo-dev] new profile layout with flavors and mix-ins

On Thu, Jul 3, 2014 at 7:09 PM, Tom Wijsman wrote: > Did the Funtoo devs tell you that they don't run repoman because of the > explosive set of possible combinations that flavors & mix-ins introduce? > > Having it run over them should be easy; but having it run within a > reasonable time when scal

Re: [gentoo-dev] Is || ( Atom... ) broken?

On Mon, Jul 7, 2014 at 6:14 AM, Greg Turner wrote: > WTF is up with it? Why does it love the first Atom so much more than the > others? > > It could be such a useful feature, but, in practice, it just never seems to > do what I want it to. Is it a bug? Well, more like unspecified behavior. PMS

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller wrote: >> On Mon, 7 Jul 2014, Michał Górny wrote: > >> iii. that the games group along with the game-specific install tree >> should be deprecated and phased out. Games should be installed alike >> any other applications. > > The install locations

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 6:52 AM, Michael Palimaka wrote: > On 07/08/2014 07:45 AM, Michał Górny wrote: >> >> 1. that the games team has authority over the actual maintainers >> on every game ebuild, >> > > Why is Council intervention needed to abolish these policies? They're > not binding. > As far

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny wrote: > > The games team believes that they're binding. In fact, I recall one of > the team members remarking explicitly that they're going to alter > ebuilds that were committed without their approval. > > In fact, they did remove ebuilds from the tre

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 8:42 AM, Ulrich Mueller wrote: >> On Tue, 8 Jul 2014, Michał Górny wrote: > >> In fact, they did remove ebuilds from the tree in the past for this >> reason [1]. > > Given that this was a live ebuild that failed to compile [2] and was > dumped onto the games team few wee

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 12:17 PM, Michael Palimaka wrote: > On 07/09/2014 01:22 AM, Samuli Suominen wrote: >> And some personal thoughts about the initial proposal... >> I don't care about the suggestion 3. in mgorny's proposal at all, but 1. >> and 2. should definately >> stay as is. > What author

Re: [gentoo-dev] Re: The request to abolish games team policy

On Tue, Jul 8, 2014 at 11:55 PM, Samuli Suominen wrote: > > On 08/07/14 19:17, Michael Palimaka wrote: >> On 07/09/2014 01:22 AM, Samuli Suominen wrote: >>> And some personal thoughts about the initial proposal... >>> I don't care about the suggestion 3. in mgorny's proposal at all, but 1. >>> and

Re: [gentoo-dev] Re: The request to abolish games team policy

On Wed, Jul 9, 2014 at 2:06 AM, Samuli Suominen wrote: > > On 09/07/14 07:24, Tom Wijsman wrote: >>> [...] confusions with newer people... >> Ironically; my first Portage tree action "add a directory" got a "don't >> throw [expletive] into [games category]" reply, before adding the ebuild. >> >> O

Re: [gentoo-dev] Re: The request to abolish games team policy

On Wed, Jul 9, 2014 at 11:28 AM, Sergey Popov wrote: > But, honesly, i can not see problem in this. We have similar problem in > ARM team, which was fixed by electing new leads by those, who really did > most of ARM stuff AND actively responds on e-mails. Doing this and giving the games team a ch

Re: [gentoo-dev] Re: The request to abolish games team policy

On Fri, Jul 11, 2014 at 12:24 PM, hasufell wrote: > > However, basically having only a single person that actively does such > reviews + no official overlay makes it hard for contributors. > Is there still anybody left who wants to actually join the games team? I suggested that somebody step up

Re: [gentoo-dev] The request to abolish games team policy

On Sat, Jul 12, 2014 at 6:26 PM, Denis Dupeyron wrote: > Rich, if I may have a suggestion, it would be that instead of meddling > with projects that have been doing their best with what they have for > years, and which need praise rather than hindrance, you instead start > a project to get people

Re: [gentoo-dev] Re: last rites: games-fps/postal2mp-demo

On Wed, Jul 16, 2014 at 10:50 AM, Ulrich Mueller wrote: > IANAL, but there is no such concept as "abandonware" in copyright law. > Copyright can expire, at which point the work enters into the public > domain. However, the time for that is generally too long to play any > practical role for softwa

Re: [gentoo-dev] Re: last rites: games-fps/postal2mp-demo

On Wed, Jul 16, 2014 at 3:44 PM, Denis Dupeyron wrote: > > Let me try and be clearer. The packages I'm concerned with have had > their distfiles backed up. We're not yet in that situation but the day > the publisher stops distributing these distfiles, I'll be ready to > send the right email to the

Re: [gentoo-dev] Prevent to need to change all keywords at the same time

On Thu, Jul 17, 2014 at 10:09 AM, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 17/07/14 08:28 AM, Pacho Ramos wrote: >> I recently noticed this: >> https://bugs.gentoo.org/show_bug.cgi?id=502836 >> >> imlib2 ebuild can only be stabilized in one round for all a

Re: [gentoo-dev] Prevent to need to change all keywords at the same time

On Thu, Jul 17, 2014 at 2:56 PM, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 17/07/14 02:28 PM, Pacho Ramos wrote: >> El jue, 17-07-2014 a las 17:03 +0100, Ciaran McCreesh escribió: >>> On Thu, 17 Jul 2014 10:23:20 -0400 Rich Freem

Re: [gentoo-dev] Prevent to need to change all keywords at the same time

On Thu, Jul 17, 2014 at 4:44 PM, Ciaran McCreesh wrote: > On Thu, 17 Jul 2014 16:40:02 -0400 > Rich Freeman wrote: >> I agree that it isn't a PMS issue - it is a tree quality issue. PMS >> doesn't prohibit introducing packages straight to stable, dropping >> st

Re: [gentoo-dev] don't rely on dynamic deps

On Wed, Jul 23, 2014 at 9:33 AM, Ciaran McCreesh wrote: > On Mon, 21 Jul 2014 23:06:07 +0200 > Pacho Ramos wrote: >> Maybe this could be solved by having two kinds of revisions: >> - One would rebuild all as usually (for example, -r1...) >> - The other one would only regenerate VDB and wouldn't c

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth wrote: > ...but by introducing all the additional complications Ian > has mentioned. More precisely: What happens if new dependencies > are introduced which are not satisfied? > One has to face it: Portage must not just silently "update" the > database

Re: [gentoo-dev] don't rely on dynamic deps

On Fri, Jul 25, 2014 at 11:01 AM, Ciaran McCreesh wrote: > On Thu, 24 Jul 2014 21:45:58 -0400 > Rich Freeman wrote: >> Just a general comment not aimed at this particular part of the thread >> - a solution doesn't have to be perfect to be useful. > > Wrong. The rea

Re: [gentoo-dev] About current ppc/ppc64 status

On Sat, Jul 26, 2014 at 7:56 AM, Pacho Ramos wrote: > > I guess we will need to wait for the next Council to officially decide > to do this as it will be a big change for ppc* users :/ (I remember > their action was needed for the move to testing of some arches and the > "package-by-package" propo

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sat, Jul 26, 2014 at 12:14 PM, Ciaran McCreesh wrote: > On Sat, 26 Jul 2014 16:05:58 + (UTC) > Martin Vaeth wrote: >> Ciaran McCreesh wrote: >> > Your solution fails spectacularly in the following ways: > >> > * Introduction of :=3D dependencies >> >> This is not a "minor update" in depen

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sat, Jul 26, 2014 at 12:02 PM, Ciaran McCreesh wrote: > On Sat, 26 Jul 2014 15:59:58 + (UTC) > Martin Vaeth wrote: >> > And what if the match for :=3D is >> > incompatible with new dependency atom? Like when you replace >> > 'dev-foo/bar:=3D' with '>=3Ddev-foo/bar-2:=3D' but bar-1 is >> >

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric wrote: > > In a "no dynamic deps, period" scenario, this just strikes me as 2 flavours > of the same weirdness, -r2 and -r1.1 are just equally weird choices to make > if the ebuild itself doesn't change at all. You have a good point here. With this p

Re: [gentoo-dev] Avoiding rebuilds (was: don't rely on dynamic deps)

On Sun, Jul 27, 2014 at 6:16 AM, Ulrich Mueller wrote: > I wonder if it wouldn't be saner to leave our revision syntax > untouched. > > Instead, one could introduce a variable INSTALL_VERSION that would > default to ${PVR} but could be set to the version of a previous ebuild > instead. The PM coul

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sun, Jul 27, 2014 at 8:31 AM, hasufell wrote: > > I'm eager to hear how you want to make subslots work with dynamic deps. > > := gets converted to :${SLOT}/${SUBSLOT} in vardb and this is used to > trigger the rebuilds. > > How do you record the subslot a package was built against in the live t

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 10:05 AM, "Paweł Hajdan, Jr." wrote: > On 7/21/14, 11:52 PM, Alexander Berntsen wrote: >> Michał has documented the shortcomings of dynamic deps in our wiki[0]. >> (Thank you!) [...] >> [0] > > There's one

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 10:59 AM, Ciaran McCreesh wrote: > On Sun, 27 Jul 2014 16:56:17 +0200 > ""Paweł Hajdan, Jr."" wrote: >> It seems really tricky to correctly reason about dependency >> resolution. > > It's actually very easy if you do away with all the things that are > making it unnecessar

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 11:44 AM, Kent Fredric wrote: > > On 28 July 2014 02:42, Rich Freeman wrote: >> >> One thing I would question in that table is "applied immediately (but >> can break hard when dynamic-deps stop working))." How can dynamically >&g

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 4:24 PM, Michał Górny wrote: > Dnia 2014-07-27, o godz. 10:42:19 > > Consider the following: > > 1. A depends on B, both are installed, > > 2. dependency on B is removed, emerge --depclean uninstalls B thanks > to dynamic-deps, > > 3. B is treecleaned (nothing depends on it

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 5:17 PM, Michał Górny wrote: > Dnia 2014-07-27, o godz. 17:08:27 > Rich Freeman napisał(a): >> >> I'd think that portage should update vdb as soon as it detects the >> dependency change. Then B would no longer depend on A in vdb. It &g

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 5:27 PM, Kent Fredric wrote: > > On 28 July 2014 08:56, Ciaran McCreesh > wrote: >> >> > To me it seems like a simple data model bug that vdb does not get >> > updated to reflect the new situation after step 2 above. >> >> Rewriting VDB won't help if the user doesn't sync

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 5:33 PM, Ciaran McCreesh wrote: > On Sun, 27 Jul 2014 17:26:27 -0400 > Rich Freeman wrote: >> But, in that case you can put the necessary ebuilds into your overlay >> and then portage can make everything right. > > Oh? Please explain to us a) how

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sun, Jul 27, 2014 at 8:04 AM, Rich Freeman wrote: > > Doing this would require having portage cache a hash of whatever > ebuild it last parsed, and perhaps its eclasses as well if we permit > revbump-less eclass changes. Then it would have to check for when > these change, per

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 5:50 PM, Kent Fredric wrote: > > On 28 July 2014 09:34, Rich Freeman wrote: >> >> and if it doesn't work for them, >> they'll sync in the updates one way or another (using an overlay if >> necessary). > > > However, i

Re: [gentoo-dev] don't rely on dynamic deps

On Mon, Jul 28, 2014 at 12:29 PM, Ian Stakenvicius wrote: > As has been mentioned or alluded to before, this is fine as long as > end-users --sync when the dependency change is still in the tree. > However, if that doesn't happen then we still end up with the issue. > > Of course, if that is the c

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Mon, Jul 28, 2014 at 2:27 PM, Ian Stakenvicius wrote: > > The primary underlying problem I see about this is that it doesn't > force devs to start doing something to the tree that will suddenly > help make all of the static-deps-only PMs (ie, those that aren't going > to implement this new hash

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Mon, Jul 28, 2014 at 2:50 PM, Martin Vaeth wrote: > > In both cases of 6., the user is not even aware that he uses > long obsolete packages unless portage prints a big fat warning > for orphaned packages (which currently is not the case. > Well, at least eix -t will be print a message.) > This

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Tue, Jul 29, 2014 at 3:33 AM, Peter Stuge wrote: > > Rich Freeman wrote: >> This is really the crux of these sorts of issues. It doesn't matter >> if dependencies are static or dynamic - if you hang onto orphans then >> you're going to have cruft in

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Wed, Jul 30, 2014 at 3:38 AM, "Paweł Hajdan, Jr." wrote: > On 7/30/14, 7:36 AM, Samuli Suominen wrote: >> If it's 2-3 packages out of ~300, I'd rather pick them out than >> revision bump all ~300 for the 2-3. Or not pick them out at all >> and let users do the rebuild (which is the obvious answ

Re: [gentoo-dev] minimalistic emerge

On Fri, Aug 8, 2014 at 11:45 AM, Ian Stakenvicius wrote: > However, if you don't want to do this, just "emerge -u > @world" -- that will only update packages in your world file, and will > only force dependency updates when the new version is required (based > on minimum versions in package depend

Re: [gentoo-dev] minimalistic emerge

On Fri, Aug 8, 2014 at 4:16 PM, Ian Stakenvicius wrote: > I don't think we have any sort of tree-wide policy on this either, do > we? Although I believe common sense says it's a good idea (and i hope > most devs do this) to put a minver on a dependency atom if there was > any ebuild with an older

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

On Tue, Aug 12, 2014 at 8:47 AM, hasufell wrote: > > First, a sentence does not need to have a predicate. I know that for 99% > sure in german and the english wikipedia article seems to suggest the > same. Correct me if I am wrong. > In English your typical English class would teach that every se

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

On Tue, Aug 12, 2014 at 10:04 AM, Ian Stakenvicius wrote: > > I'm wondering what everyone thinks of having a --nonag option to > repoman and shoving some of the more trivial/style-related repoman > 'warnings' into a 'nag' level warning? IIRC at least one of the QA > team members is so tired of th

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

On Tue, Aug 12, 2014 at 1:13 PM, Ian Stakenvicius wrote: > > I don't consider a recommended style message to be 'broken' just > because it's not listed in the devmanual/PMS/etc as a requirement. > The implementation of it, on the other hand, yes that could be broken > and in this case should be fi

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller wrote: >> On Sat, 16 Aug 2014, William Hubbs wrote: > >> My counter proposal to this is that we stop calling eclass phase >> functions automatically, and to minimize the amount of boilerplating >> we would have to do, we use a variable, such as E

Re: [gentoo-dev] rfc: eclass issues

On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs wrote: > > The other concern he mentioned was indirectly inherited eclasses being > able to override phase functions. > So, while I'm not sure whether getting rid of the ability to inherit phase functions is practical/good/etc, I do think we need to

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov wrote: > 17.08.2014 01:54, William Hubbs пишет: >> >> # Foo and bar both have src_unpack and src_install functions. >> # we want foo's src_unpack and bar's src_install: >> >> ECLASS_PHASES="foo_src_unpack >> bar_src_install" > > You have my stron

Re: [gentoo-dev] rfc: eclass issues

On Mon, Aug 18, 2014 at 8:12 AM, hasufell wrote: > > I think the first thing to do and which already happened with e.g. > qmake-utils.eclass is to make a very strong distinction between utility > eclasses and those that export phase functions. > Discussion on IRC the other day was moving in this

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On Mon, Aug 18, 2014 at 8:21 AM, Sergey Popov wrote: > 18.08.2014 14:44, Rich Freeman пишет: >> On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov wrote: >>> 17.08.2014 01:54, William Hubbs пишет: >>>> >>>> # Foo and bar both have src_unpack and src_install

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On Mon, Aug 18, 2014 at 8:56 AM, hasufell wrote: > > So in the end 3 eclasses all tell you "inherit me last! really!". Good > luck with figuring out how to make a gnome game with python and multilib > support work together. I can predict the days such a review would take > in #gentoo-sunrise. Not

Re: [gentoo-dev] systemd + postgresql is non-obvious to me

On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson wrote: > On the whole, I'm displeased with the systemd alternative for > controlling PostgreSQL. It's significantly hampered and doesn't allow > as much flexibility as the initscript. The major issue being trying to > nicely shut down the server in

Re: [gentoo-dev] systemd profiles

On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki wrote: > Hi all, > > I have a simple question: why do we have systemd subprofiles only in gnome > and kde profiles? > > Could we add systemd subprofiles also to default/linux/$arch/13.0/ and > desktop (and any other profiles where it makes sense

Re: [gentoo-dev] systemd profiles

On Sat, Aug 30, 2014 at 7:41 AM, Michał Górny wrote: > Dnia 2014-08-30, o godz. 13:27:08 > "J. Roeleveld" napisał(a): >> >> Not sure if this idea has been discussed before, but: >> Wouldn't it be an idea to have a "virtual/init" which depends on 1 of: > > You mean our virtual/service-manager? >

Re: [gentoo-dev] systemd profiles

On Sat, Aug 30, 2014 at 8:55 AM, Lars Wendler wrote: > On Sat, 30 Aug 2014 08:03:10 -0400 Rich Freeman wrote: > >>On Sat, Aug 30, 2014 at 7:41 AM, Michał Górny >>wrote: >>> Dnia 2014-08-30, o godz. 13:27:08 >>> "J. Roeleveld" napisał(a): >>>

Re: [gentoo-dev] RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.

On Sun, Aug 31, 2014 at 11:08 AM, Anthony G. Basile wrote: > > I do not understand why you oppose the standardization of VDB? > I think it would make sense to take a step back. What is it that you're actually after here? You want to be able to determine information about packages that are insta

Re: [gentoo-dev] systemd + postgresql is non-obvious to me

On Mon, Sep 1, 2014 at 11:46 AM, Aaron W. Swenson wrote: > On 2014-08-22 14:07, Rich Freeman wrote: >> On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson >> wrote: >> > On the whole, I'm displeased with the systemd alternative for >> > controlling Postg

Re: [gentoo-dev] systemd profiles

On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs wrote: > > I can deprecate it. To do so, I would need to have it print out a > deprecation warning that would be wrong for Gentoo in the next release. > > That warning would have to tell users to source > /lib*/rc/sh/functions.sh. I don't have a probl

Re: [gentoo-dev] rfc: adding sys-apps/iproute2 to the @system set

On Fri, Sep 5, 2014 at 5:20 PM, Michał Górny wrote: > Even better, @system is basically stuff you don't want to depend > explicitly on or on which it is hard to depend on. As I see it, it > should be just the most basic stuff, like baselayout, shell, some basic > POSIX-defined utilities, some rand

Re: [gentoo-dev] Re: rfc: adding sys-apps/iproute2 to the @system set

On Sat, Sep 6, 2014 at 2:44 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Fri, 05 Sep 2014 20:10:02 -0400 as excerpted: > >> The purpose of the system set is to deal with circular deps and the need >> to bootstrap. We shouldn't have stuff in t

Re: [gentoo-dev] rfc: adding sys-apps/iproute2 to the @system set

On Sat, Sep 6, 2014 at 8:41 AM, Patrick Lauer wrote: > > And by the same reasoning of "bloat" we should remove openssh ( and maybe even > rsync ;) ) because it's not strictly needed - so maybe we want a "minimal" and > a "useful" stage3 ? I could care less what is in the stage3, which only affect

Re: [gentoo-dev] rfc: adding sys-apps/iproute2 to the @system set

On Sat, Sep 6, 2014 at 9:23 AM, Anthony G. Basile wrote: > > I'm not sure we can get rid of python2 and have only python3, but if that's > possible, absolutely punt it! The bloat I'm talking about includes size, > but more importantly, I'm concerned about cpu time. When building on a minor > arch

Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]

On Sun, Sep 7, 2014 at 3:49 PM, Joshua Kinard wrote: > IMHO, I think @system should maintain at least one editor and include some > kind of networking diagnostic package. Why is it important that we not be able to parallel build an editor? Is it such a frequent build-time dependency that we woul

Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]

On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard wrote: > And thus, I was referring only to @system, not a stage3. I think an editor > should be in @system, but as much as I like nano, I know the ncurses > dependency won't sit well with everyone. If @system is supposed to be a > minimal-working sys

[gentoo-dev] Does the scm ebuild masking policy make sense for git?

Right now the general policy is that we don't allow unmasked (hard or via keywords) ebuilds in the tree if they use an scm to fetch their sources. There are a bunch of reasons for this, and for the most part they make sense. I was wondering if this policy still made sense in the case of scm ebuil

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

>>> >> >>> On 08/09/14 06:47, Rick "Zero_Chaos" Farina wrote: >> >>>> On 09/07/2014 09:03 PM, Rich Freeman wrote: >> >>>>> Right now the general policy is that we don't allow unmasked (hard or >> >>>>> via key

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

On Mon, Sep 8, 2014 at 2:59 AM, Ulrich Mueller wrote: > > What is the problem with making snapshot of some git commit and > placing it on mirrors? > To be clear, there isn't one. The more typical approach for fixes is to use the upstream main release tarball and continue to provide patches again

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny wrote: > > Let's keep it short: I think herds don't serve any special purpose > nowadays. Their existence is mostly resulting in lack of consistency > and inconveniences. > The original design was that packages belong to herds, and developers belong to

Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]

On Wed, Sep 10, 2014 at 4:08 AM, J. Roeleveld wrote: > > But on slower machines, as I am used to fast ones, I tend to notice the lack > of parallellism during the emerge-phase. > Diego used to point out that lack of parallelism was always a challenge with running a tinderbox. You can have 32 cor

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

On Tue, Sep 9, 2014 at 6:54 PM, Kent Fredric wrote: > > On 10 September 2014 10:23, Michał Górny wrote: >> >> I don't understand your concern. I'm only saying we should stop relying >> on that stupid out-of-repository herds.xml file and put the e-mail >> address directly in metadata.xml. Bugzilla

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos wrote: > > Personally I would vote for simply have a tag pointing to > the alias but we would still need to keep a list of real maintainers for > that alias as usually not all people listed in the alias are willing to > maintain the packages. > I thin

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

On Wed, Sep 10, 2014 at 10:18 AM, Michał Górny wrote: > Dnia 2014-09-10, o godz. 07:53:31 > Rich Freeman napisał(a): > >> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos wrote: >> > >> > Personally I would vote for simply have a tag pointing to >> > t

[gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

On Sun, Sep 14, 2014 at 8:03 AM, Michał Górny wrote: > > I'm quite tired of promises and all that perfectionist non-sense which > locks us up with CVS for next 10 years of bikeshed. While I tend to agree with the sentiment, I don't think you're actually targeting the problems that aren't already

Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

On Sun, Sep 14, 2014 at 10:56 AM, Michał Górny wrote: > Dnia 2014-09-14, o godz. 10:33:03 > > With git, we can finally do stuff like preparing everything and pushing > in one go. Rebasing or merging will be much easier then, since > the effective push rate will be smaller than current commit rate.

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On Sun, Sep 14, 2014 at 11:42 AM, hasufell wrote: > Patrick Lauer: >>> Are we going to disallow merge commits and ask devs to rebase local >>> changes in order to keep the history "clean"? >> >> Is that going to be sane with our commit frequency? >> > > You have to merge or rebase anyway in case o

Re: [gentoo-dev] gentoo git workflow

On Sun, Sep 14, 2014 at 11:11 AM, hasufell wrote: > > The only hard part is that people have to know the differences between > merging/rebasing, fast-forward merges, non-fast-forward merges etc. and > when and when not to do them. > > 'git rebase' is a powerful thing, but also pretty good to mess

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On Sun, Sep 14, 2014 at 6:56 PM, hasufell wrote: > According to Robin, it's not about rebasing, it's about signing all > commits so that messing with the blob (even if it has the same sha-1) > will cause signature verification failure. > The only thing that gets signed is the commit message, and

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On Sun, Sep 14, 2014 at 7:21 PM, Patrick Lauer wrote: > > iow, git doesn't allow people to work on more than one item at a time? > > That'd mean I need half a dozen checkouts just to emulate cvs, which somehow > doesn't make much sense to me ... > Well, you can work on as many things as you like

Re: [gentoo-dev] gentoo git workflow

On Mon, Sep 15, 2014 at 7:37 AM, hasufell wrote: > * repoman must be run from all related directories (or the top-level > directory) on the latest commit that is being pushed This should be clarified. Does repoman need to be run on the exact commit that is being pushed, or perhaps on a "parent

Re: [gentoo-dev] gentoo git workflow

On Mon, Sep 15, 2014 at 9:13 AM, hasufell wrote: > Yes, you have to rerun repoman after a rebase or merge. On the tip of > the local master branch (as in: right before you try to push). > > Sure, this may lead to problems if repoman takes long... but that's on > purpose. If your changes are that b

Re: [gentoo-dev] gentoo git workflow

On Mon, Sep 15, 2014 at 10:26 AM, Ian Stakenvicius wrote: > I'm not that worried about the big (multi-package) commits, as it does > make sense we're going to have difficulty and lots of potential > conflicts there, but aren't we going to run into this issue just with > multiple people committing

Re: [gentoo-dev] gentoo git workflow

hasufell wrote: > * allow inconsistency and broken states as we do now with CVS (and rely > on QA to run a repoman tinderbox and reverse-fixing broken crap) ... > Rich Freeman: >> It would make a lot more sense if we had a release-oriented strategy, >> even if releases

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On Mon, Sep 15, 2014 at 1:42 PM, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 14/09/14 09:06 PM, Peter Stuge wrote: >> Rich Freeman wrote: >>> If you just want to do 15 standalone commits before you push you >>> can do

Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

On Mon, Sep 15, 2014 at 3:55 PM, Anthony G. Basile wrote: > On 09/15/14 15:30, William Hubbs wrote: >> I would have no problem with the council revisiting/changing this. >> >> I tend to agree that the ChangeLogs in the portage tree will be >> obsoleted when we switch to git because git's logging f

Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

On Mon, Sep 15, 2014 at 4:18 PM, Michał Górny wrote: > > Can't we just kill rsync then? The whole ChangeLog seems to take more > effort than the actual benefit it gives. > I'm not sure ditching rsync entirely is necessary - it might be more trouble than it is worth as it is a very effective simpl

Re: [gentoo-dev] git security (SHA-1)

On Mon, Sep 15, 2014 at 6:11 PM, Gordon Pettey wrote: > > Even if you wanted to burn the money to find that magical collision that > actually contains working code, you've still got to somehow propagate that > to other repositories, since they'll just ignore it for having the same hash > as an alr

Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

On Tue, Sep 16, 2014 at 6:18 AM, hasufell wrote: > Ulrich Mueller: >> >> ChangeLogs are aimed at users > > Did any1 ask them if they care? > I'm sure somebody will reply and say that they care. It still seems like a lot of overhead to me for a very one-off workflow. Maybe if portage automatical

[gentoo-dev] Re: [gentoo-scm] Re: My masterplan for git migration (+ looking for infra to test it)

On Mon, Sep 15, 2014 at 11:50 PM, Brian Harring wrote: > > On Sun, Sep 14, 2014 at 10:33 AM, Rich Freeman wrote: >> >> On Sun, Sep 14, 2014 at 8:03 AM, Michał Górny wrote: >> > >> > Of course, that assumes infra is >> > going to cooperate quic

Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

On Tue, Sep 16, 2014 at 9:44 AM, Pacho Ramos wrote: > > Maybe one option would be to kill Changelogs and provide a script to let > people get git messages and reformat them in a way similar as current > ChangeLog files, that way people will still be able to save this > information for the future (

Re: [gentoo-dev] git security (SHA-1)

On Tue, Sep 16, 2014 at 9:44 AM, Ian Stakenvicius wrote: > > If the issue preventing protection is that the gpg signature only > signs the hash, couldn't we just make repoman automatically add to the > bottom of the comment a clearsign on the contents of the commit? > The gpg signature is on the

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On Tue, Sep 16, 2014 at 1:07 PM, Luca Barbato wrote: > On 14/09/14 17:30, Patrick Lauer wrote: >>> Are we going to disallow merge commits and ask devs to rebase local >>> changes in order to keep the history "clean"? >> >> Is that going to be sane with our commit frequency? >> > > Which is our com

Re: [gentoo-dev] Add bc back to the stage3

On Tue, Sep 16, 2014 at 7:47 PM, Luca Barbato wrote: > The bc utility is part of the posix tools and it might be used to build > linux among the other stuff. > I'm fine with including useful utilities in the stage3s, as long as they don't go into the system set. We really need to get beyond equa

Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

On Wed, Sep 17, 2014 at 5:56 AM, Ulrich Mueller wrote: > > So the research that needs to be done first is to find out how often > our ChangeLog entries differ from the commit log. If it turns out that > they are identical in 99 % of all cases, then it obviously makes no > sense to maintain the sam

Re: [gentoo-dev] Add bc back to the stage3

On Wed, Sep 17, 2014 at 9:29 AM, Alan McKinnon wrote: > On 17/09/2014 14:49, Aaron W. Swenson wrote: > > Agreed. I've been on -user for 10+ years and only a very few fetch their > kernels directly from upstream. The vast majority of users who have > described how they do it simply emerge one of th

[gentoo-dev] Mix-in Support Tracker

There was a thread a while back about mix-in support and I think there was genuine interest. For the most part we just need to do the work, and the first step is identifying blockers. If some end up involving PMS/etc then we may need to get the Council involved. Rather than hijacking every @syst

Re: [gentoo-dev] gentoo git step by step guide

On Wed, Sep 17, 2014 at 11:28 AM, hasufell wrote: > NOTE: you may skip running repoman another time if you have manually > verified that the commits you are missing are totally unrelated to your > work (e.g. only affect a package that is not in the dependency chain of > yours). You can do so via:

Re: [gentoo-dev] Mix-in Support Tracker

On Wed, Sep 17, 2014 at 3:25 PM, Rick "Zero_Chaos" Farina wrote: > > The funtoo mixin system has absolutely nothing to do with adding > packages to stage3 that are not in @system. > > Primarily adding packages to stage3 (or stage4 if we choose to call it > that) would only need us to agree on the

<    9   10   11   12   13   14   15   16   17   18   >