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

2014-09-25 Thread Rich Freeman
On Wed, Sep 24, 2014 at 12:31 PM, W. Trevor King wk...@tremily.us wrote: On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote: 4. A mail alias that is not project :). For example, we have clang@ for easily aggregating all clang-related build failures and other bugs but it isn't a

Re: [gentoo-dev] Re: Gentoo git workflows and the stabilization/keywording process

2014-09-22 Thread Rich Freeman
On Mon, Sep 22, 2014 at 12:10 AM, Duncan 1i5t5.dun...@cox.net wrote: Devs doing gentoo all day could easily do one or two pushes a day, with many commits in each. Those with less time might do the same work over several days or a week and might push just once or twice that week, if none of

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog perl-module.eclass

2014-09-22 Thread Rich Freeman
On Mon, Sep 22, 2014 at 8:42 AM, Michał Górny mgo...@gentoo.org wrote: Also, CVS gets your name wrong. I wonder how it is possible with such an awesome modern piece of technology ;). CVS itself does support unicode in the commit messages. I have no idea where the name comes from in the

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-22 Thread Rich Freeman
On Mon, Sep 22, 2014 at 10:50 AM, Ulrich Mueller u...@gentoo.org wrote: On Mon, 22 Sep 2014, hasufell wrote: https://wiki.gentoo.org/wiki/Gentoo_git_workflow But so far, not many people have been particularly interested in the details of these things. I'm also not sure if the ML is the

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-22 Thread Rich Freeman
On Mon, Sep 22, 2014 at 12:52 PM, W. Trevor King wk...@tremily.us wrote: On Mon, Sep 22, 2014 at 11:29:52AM -0400, Rich Freeman wrote: On Mon, Sep 22, 2014 at 10:50 AM, Ulrich Mueller wrote: Another issue, should we require Signed-off-by: lines? At least for things that are contributed

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-22 Thread Rich Freeman
On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wk...@tremily.us wrote: On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote: Perhaps the c clause should be clarified that the source files themselves were not modified - not the commit message. The DCO text is verbatim copies only [1

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-22 Thread Rich Freeman
On Mon, Sep 22, 2014 at 3:27 PM, W. Trevor King wk...@tremily.us wrote: On Mon, Sep 22, 2014 at 03:13:35PM -0400, Rich Freeman wrote: On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wk...@tremily.us wrote: On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote: Perhaps the c clause

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-22 Thread Rich Freeman
On Mon, Sep 22, 2014 at 3:43 PM, W. Trevor King wk...@tremily.us wrote: There's no Signed-off-by on the commits adding the DCO to the Linux tree ;). The only information I can find claiming copyright and licensing by one of the DCO authors is at http://developercertificate.org/. I suppose

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-21 Thread Rich Freeman
On Sun, Sep 21, 2014 at 9:08 PM, Peter Stuge pe...@stuge.se wrote: hasufell wrote: A version bump plus cleaning up older ebuilds will be considered one logical change, I suppose? I'd consider it two logical changes .. But I don't have a strong opinion on that I do - I think this is

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-20 Thread Rich Freeman
On Sat, Sep 20, 2014 at 10:28 AM, hasufell hasuf...@gentoo.org wrote: Ian Stakenvicius: I wonder if it would make sense to set up a practice git tree somewhere so that people can try working together on workflows/etc. We can clone a migrated tree (I have one from a few days ago on github).

Re: [gentoo-dev] Re: git migration

2014-09-20 Thread Rich Freeman
On Sat, Sep 20, 2014 at 12:48 PM, hasufell hasuf...@gentoo.org wrote: Steven J. Long: Either way, I don't think the discussion about Changelogs should *at all* affect the move to git; Correct, because this wouldn't even be a regression to the current CVS workflow. That depends a great

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

2014-09-20 Thread Rich Freeman
On Sat, Sep 20, 2014 at 2:09 PM, Ulrich Mueller u...@gentoo.org wrote: On Wed, 17 Sep 2014, Aaron W. Swenson wrote: My argument is Git using SHA-1 for checksumming is not the weakest part of our security model. I had always assumed that robbat2's series of GLEPs (57 to 61) would be

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

2014-09-20 Thread Rich Freeman
On Sat, Sep 20, 2014 at 4:40 PM, Ulrich Mueller u...@gentoo.org wrote: On Sat, 20 Sep 2014, hasufell wrote: Have these plans been abandoned, and are we now planning to distribute the tree to users via Git, where everything goes through the bottleneck of a SHA-1 sum, which was never intended

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

2014-09-20 Thread Rich Freeman
On Sat, Sep 20, 2014 at 8:58 PM, Gordon Pettey petteyg...@gmail.com wrote: You're following the wrong train down the wrong tracks. Git [0-9a-f]{40} is to CVS 1[.][1-9][0-9]+. You're arguing that CVS is more secure because its commits are sequential numbers. Ulrich is well-aware of that. His

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

2014-09-20 Thread Rich Freeman
On Sat, Sep 20, 2014 at 9:27 PM, Peter Stuge pe...@stuge.se wrote: I've so far gotten zero feedback on my hosting offer, intended to help find some starting processes. hassufel's repository on github should be more than adequate: https://github.com/gentoo/gentoo-gitmig If we need history we

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-19 Thread Rich Freeman
On Fri, Sep 19, 2014 at 10:25 AM, hasufell hasuf...@gentoo.org wrote: That is pretty easy and takes you ~20s for a keyword merge. What's the problem? Agree. Also, there was a comment that git pull is much slower than cvs. While it is true that git does refresh the whole tree all the time,

Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

2014-09-18 Thread Rich Freeman
On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller u...@gentoo.org wrote: On Thu, 18 Sep 2014, Tobias Klausmann wrote: However, one aspect of how ebuilds are written these days will cause a non-trivial amount of merge commits that are not actually useful in that sense. Git can do merge

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

2014-09-18 Thread Rich Freeman
On Thu, Sep 18, 2014 at 3:33 PM, Diamond diam...@hi-net.ru wrote: Lets assume, that I don't want to scrap old ebuild yet. There's no git cp command. git mv is just git rm + git add. That's what does it look like (usual revbump with git add in reality):

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

2014-09-17 Thread Rich Freeman
On Tue, Sep 16, 2014 at 7:47 PM, Luca Barbato lu_z...@gentoo.org 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

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

2014-09-17 Thread Rich Freeman
On Wed, Sep 17, 2014 at 5:56 AM, Ulrich Mueller u...@gentoo.org 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

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

2014-09-17 Thread Rich Freeman
On Wed, Sep 17, 2014 at 9:29 AM, Alan McKinnon alan.mckin...@gmail.com 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

[gentoo-dev] Mix-in Support Tracker

2014-09-17 Thread Rich Freeman
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

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

2014-09-17 Thread Rich Freeman
On Wed, Sep 17, 2014 at 11:28 AM, hasufell hasuf...@gentoo.org 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

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

2014-09-17 Thread Rich Freeman
On Wed, Sep 17, 2014 at 3:25 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org 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

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

2014-09-17 Thread Rich Freeman
On Wed, Sep 17, 2014 at 4:02 PM, Diamond diam...@hi-net.ru wrote: On Mon, 15 Sep 2014 14:51:56 -0400 Rich Freeman ri...@gentoo.org wrote: In general you want each commit to represent a single change. That might be a revbump in a single package, or it might be a package move that involves

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

2014-09-16 Thread Rich Freeman
On Tue, Sep 16, 2014 at 6:18 AM, hasufell hasuf...@gentoo.org 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

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

2014-09-16 Thread Rich Freeman
On Mon, Sep 15, 2014 at 11:50 PM, Brian Harring ferri...@gmail.com wrote: On Sun, Sep 14, 2014 at 10:33 AM, Rich Freeman ri...@gentoo.org wrote: On Sun, Sep 14, 2014 at 8:03 AM, Michał Górny mgo...@gentoo.org wrote: Of course, that assumes infra is going to cooperate quickly or someone

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

2014-09-16 Thread Rich Freeman
On Tue, Sep 16, 2014 at 9:44 AM, Pacho Ramos pa...@gentoo.org 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

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

2014-09-16 Thread Rich Freeman
On Tue, Sep 16, 2014 at 9:44 AM, Ian Stakenvicius a...@gentoo.org 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

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

2014-09-16 Thread Rich Freeman
On Tue, Sep 16, 2014 at 1:07 PM, Luca Barbato lu_z...@gentoo.org 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

Re: [gentoo-dev] gentoo git workflow

2014-09-15 Thread Rich Freeman
On Mon, Sep 15, 2014 at 7:37 AM, hasufell hasuf...@gentoo.org 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

Re: [gentoo-dev] gentoo git workflow

2014-09-15 Thread Rich Freeman
On Mon, Sep 15, 2014 at 9:13 AM, hasufell hasuf...@gentoo.org 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

Re: [gentoo-dev] gentoo git workflow

2014-09-15 Thread Rich Freeman
On Mon, Sep 15, 2014 at 10:26 AM, Ian Stakenvicius a...@gentoo.org 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

Re: [gentoo-dev] gentoo git workflow

2014-09-15 Thread Rich Freeman
hasufell hasuf...@gentoo.org 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 were hourly

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

2014-09-15 Thread Rich Freeman
On Mon, Sep 15, 2014 at 1:42 PM, Ian Stakenvicius a...@gentoo.org 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 those sequentially easily enough

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

2014-09-15 Thread Rich Freeman
On Mon, Sep 15, 2014 at 3:55 PM, Anthony G. Basile bluen...@gentoo.org 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

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

2014-09-15 Thread Rich Freeman
On Mon, Sep 15, 2014 at 4:18 PM, Michał Górny mgo...@gentoo.org 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

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

2014-09-15 Thread Rich Freeman
On Mon, Sep 15, 2014 at 6:11 PM, Gordon Pettey petteyg...@gmail.com 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

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

2014-09-14 Thread Rich Freeman
On Sun, Sep 14, 2014 at 8:03 AM, Michał Górny mgo...@gentoo.org 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

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

2014-09-14 Thread Rich Freeman
On Sun, Sep 14, 2014 at 10:56 AM, Michał Górny mgo...@gentoo.org 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

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

2014-09-14 Thread Rich Freeman
On Sun, Sep 14, 2014 at 11:42 AM, hasufell hasuf...@gentoo.org 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

Re: [gentoo-dev] gentoo git workflow

2014-09-14 Thread Rich Freeman
On Sun, Sep 14, 2014 at 11:11 AM, hasufell hasuf...@gentoo.org 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

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

2014-09-14 Thread Rich Freeman
On Sun, Sep 14, 2014 at 6:56 PM, hasufell hasuf...@gentoo.org 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

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

2014-09-14 Thread Rich Freeman
On Sun, Sep 14, 2014 at 7:21 PM, Patrick Lauer patr...@gentoo.org 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

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

2014-09-10 Thread Rich Freeman
On Tue, Sep 9, 2014 at 6:54 PM, Kent Fredric kentfred...@gmail.com wrote: On 10 September 2014 10:23, Michał Górny mgo...@gentoo.org 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

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

2014-09-10 Thread Rich Freeman
On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote: Personally I would vote for simply have a maintainer 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

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

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

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

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

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

2014-09-09 Thread Rich Freeman
On Mon, Sep 8, 2014 at 2:59 AM, Ulrich Mueller u...@gentoo.org 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

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

2014-09-09 Thread Rich Freeman
On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny mgo...@gentoo.org 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

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

2014-09-07 Thread Rich Freeman
On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard ku...@gentoo.org 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

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

2014-09-07 Thread Rich Freeman
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

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

2014-09-06 Thread Rich Freeman
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 there if it is possible to run without

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

2014-09-06 Thread Rich Freeman
On Sat, Sep 6, 2014 at 8:41 AM, Patrick Lauer patr...@gentoo.org 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

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

2014-09-06 Thread Rich Freeman
On Sat, Sep 6, 2014 at 9:23 AM, Anthony G. Basile bluen...@gentoo.org 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

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

2014-09-05 Thread Rich Freeman
On Fri, Sep 5, 2014 at 5:20 PM, Michał Górny mgo...@gentoo.org 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

Re: [gentoo-dev] systemd profiles

2014-09-03 Thread Rich Freeman
On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs willi...@gentoo.org 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

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

2014-09-01 Thread Rich Freeman
On Mon, Sep 1, 2014 at 11:46 AM, Aaron W. Swenson titanof...@gentoo.org wrote: On 2014-08-22 14:07, Rich Freeman wrote: On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org wrote: On the whole, I'm displeased with the systemd alternative for controlling PostgreSQL. It's

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

2014-08-31 Thread Rich Freeman
On Sun, Aug 31, 2014 at 11:08 AM, Anthony G. Basile bluen...@gentoo.org 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

Re: [gentoo-dev] systemd profiles

2014-08-30 Thread Rich Freeman
On Sat, Aug 30, 2014 at 7:41 AM, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-08-30, o godz. 13:27:08 J. Roeleveld jo...@antarean.org 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

Re: [gentoo-dev] systemd profiles

2014-08-30 Thread Rich Freeman
On Sat, Aug 30, 2014 at 8:55 AM, Lars Wendler polynomia...@gentoo.org 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 mgo...@gentoo.org wrote: Dnia 2014-08-30, o godz. 13:27:08 J. Roeleveld jo...@antarean.org napisał(a): Not sure

Re: [gentoo-dev] systemd profiles

2014-08-29 Thread Rich Freeman
On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki jauh...@gentoo.org 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

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

2014-08-22 Thread Rich Freeman
On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org 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

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

2014-08-18 Thread Rich Freeman
On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov pinkb...@gentoo.org 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

Re: [gentoo-dev] rfc: eclass issues

2014-08-18 Thread Rich Freeman
On Mon, Aug 18, 2014 at 8:12 AM, hasufell hasuf...@gentoo.org 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

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

2014-08-18 Thread Rich Freeman
On Mon, Aug 18, 2014 at 8:21 AM, Sergey Popov pinkb...@gentoo.org wrote: 18.08.2014 14:44, Rich Freeman пишет: On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov pinkb...@gentoo.org wrote: 17.08.2014 01:54, William Hubbs пишет: # Foo and bar both have src_unpack and src_install functions. # we

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

2014-08-18 Thread Rich Freeman
On Mon, Aug 18, 2014 at 8:56 AM, hasufell hasuf...@gentoo.org 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

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

2014-08-17 Thread Rich Freeman
On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller u...@gentoo.org 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

Re: [gentoo-dev] rfc: eclass issues

2014-08-17 Thread Rich Freeman
On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs willi...@gentoo.org 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

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

2014-08-12 Thread Rich Freeman
On Tue, Aug 12, 2014 at 8:47 AM, hasufell hasuf...@gentoo.org 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

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

2014-08-12 Thread Rich Freeman
On Tue, Aug 12, 2014 at 10:04 AM, Ian Stakenvicius a...@gentoo.org 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

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

2014-08-12 Thread Rich Freeman
On Tue, Aug 12, 2014 at 1:13 PM, Ian Stakenvicius a...@gentoo.org 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

Re: [gentoo-dev] minimalistic emerge

2014-08-08 Thread Rich Freeman
On Fri, Aug 8, 2014 at 11:45 AM, Ian Stakenvicius a...@gentoo.org 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

Re: [gentoo-dev] minimalistic emerge

2014-08-08 Thread Rich Freeman
On Fri, Aug 8, 2014 at 4:16 PM, Ian Stakenvicius a...@gentoo.org 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

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

2014-07-30 Thread Rich Freeman
On Wed, Jul 30, 2014 at 3:38 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org 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

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

2014-07-29 Thread Rich Freeman
On Tue, Jul 29, 2014 at 3:33 AM, Peter Stuge pe...@stuge.se 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 your vdb which is going to lead

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

2014-07-28 Thread Rich Freeman
On Mon, Jul 28, 2014 at 12:29 PM, Ian Stakenvicius a...@gentoo.org 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

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

2014-07-28 Thread Rich Freeman
On Mon, Jul 28, 2014 at 2:27 PM, Ian Stakenvicius a...@gentoo.org 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

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

2014-07-28 Thread Rich Freeman
On Mon, Jul 28, 2014 at 2:50 PM, Martin Vaeth mar...@mvath.de 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

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric kentfred...@gmail.com 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

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 6:16 AM, Ulrich Mueller u...@gentoo.org 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.

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 8:31 AM, hasufell hasuf...@gentoo.org 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

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 10:05 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org 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] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 10:59 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 27 Jul 2014 16:56:17 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: It seems really tricky to correctly reason about dependency resolution. It's actually very easy if you do away with all

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 11:44 AM, Kent Fredric kentfred...@gmail.com wrote: On 28 July 2014 02:42, Rich Freeman ri...@gentoo.org wrote: One thing I would question in that table is applied immediately (but can break hard when dynamic-deps stop working)). How can dynamically removing

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 4:24 PM, Michał Górny mgo...@gentoo.org 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

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 5:17 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-07-27, o godz. 17:08:27 Rich Freeman ri...@gentoo.org 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 shouldn't

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 5:27 PM, Kent Fredric kentfred...@gmail.com wrote: On 28 July 2014 08:56, Ciaran McCreesh ciaran.mccre...@googlemail.com 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

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 5:33 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 27 Jul 2014 17:26:27 -0400 Rich Freeman ri...@gentoo.org wrote: But, in that case you can put the necessary ebuilds into your overlay and then portage can make everything right. Oh? Please explain

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 8:04 AM, Rich Freeman ri...@gentoo.org 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, perhaps

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

2014-07-27 Thread Rich Freeman
On Sun, Jul 27, 2014 at 5:50 PM, Kent Fredric kentfred...@gmail.com wrote: On 28 July 2014 09:34, Rich Freeman ri...@gentoo.org 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, in the case the package gets

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

2014-07-26 Thread Rich Freeman
On Sat, Jul 26, 2014 at 7:56 AM, Pacho Ramos pa...@gentoo.org 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

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

2014-07-26 Thread Rich Freeman
On Sat, Jul 26, 2014 at 12:14 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 26 Jul 2014 16:05:58 + (UTC) Martin Vaeth mar...@mvath.de wrote: Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Your solution fails spectacularly in the following ways: * Introduction

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

2014-07-26 Thread Rich Freeman
On Sat, Jul 26, 2014 at 12:02 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 26 Jul 2014 15:59:58 + (UTC) Martin Vaeth mar...@mvath.de wrote: And what if the match for :=3D is incompatible with new dependency atom? Like when you replace 'dev-foo/bar:=3D' with

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

2014-07-25 Thread Rich Freeman
On Fri, Jul 25, 2014 at 11:01 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 24 Jul 2014 21:45:58 -0400 Rich Freeman ri...@gentoo.org 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

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

2014-07-24 Thread Rich Freeman
On Wed, Jul 23, 2014 at 9:33 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 21 Jul 2014 23:06:07 +0200 Pacho Ramos pa...@gentoo.org wrote: Maybe this could be solved by having two kinds of revisions: - One would rebuild all as usually (for example, -r1...) - The other one

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

2014-07-24 Thread Rich Freeman
On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth mar...@mvath.de 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

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

2014-07-17 Thread Rich Freeman
On Thu, Jul 17, 2014 at 10:09 AM, Ian Stakenvicius a...@gentoo.org 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

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

2014-07-17 Thread Rich Freeman
On Thu, Jul 17, 2014 at 2:56 PM, Ian Stakenvicius a...@gentoo.org 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 Freeman ri...@gentoo.org

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

2014-07-17 Thread Rich Freeman
On Thu, Jul 17, 2014 at 4:44 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 17 Jul 2014 16:40:02 -0400 Rich Freeman ri...@gentoo.org 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

<    6   7   8   9   10   11   12   13   14   15   >