On Mon, 4 Jun 2012 16:57:42 -0400
Rich Freeman wrote:
> If you go back and look at the tree you see a bunch of signed and
> unsigned commits. How do you easily detect how the unsigned ones got
> there (via a dev with a merge commit, or via other means)?
Well, that's not a very good solution but
v4
-mike
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: multiprocessing.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
# @AUTHOR:
# Brian Harring
# Mike Frysinger
# @BLURB: parallelization with bash (wtf?)
# @DE
On Sunday 03 June 2012 18:16:30 Zac Medico wrote:
> On 06/02/2012 10:08 PM, Mike Frysinger wrote:
> > # @FUNCTION: _multijob_fork # @INTERNAL # @DESCRIPTION: # Do the
> > actual book keeping. _multijob_fork() { [[ $# -eq 1 ]] || die
> > "incorrect number of arguments"
> >
> > local ret=0 [[ $1 ==
On Thursday 31 May 2012 08:55:25 Michał Górny wrote:
> +# Note: this function implicitly calls pkg-config. You should add it to
> +# your DEPEND when using it.
should clarify: implicitly calls pkg-config when your package provides a .pc.
> + if [[ ! ${removing_all} ]]; then
> + lo
On Mon, Jun 4, 2012 at 10:41 PM, Brian Harring wrote:
> The dev, prior to signing that, should be verifying what they're
> adding (moreso, what exists between last signed rev and theirs), they
> agree to and know of. Specifically, they're asserting their addition.
What Rich is arguing (and which
On Mon, 28 May 2012 09:58:56 +0200
Michał Górny wrote:
> As autotools-utils exports phase functions, it will be better if
> remove_libtool_files() functions would be somewhere else.
Thank you.
--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org
signature.asc
Description: PGP signature
Brian Harring wrote:
> rather deal w/ that problem when it arrises, rather than trying to
> optimize for it now.
I'm strongly in favor of ripping off the bandaid, fast and hard!
Some hooks to block problematic pushes, and let people learn as
they go. It will take weeks to months for everyone to m
On 06/04/2012 02:29 PM, Pacho Ramos wrote:
> - Looks like there is no consensus about what to do and, then, this
> could probably be implemented on eapi... 7? While former could probably
> be implemented much sooner (probably even in eapi5)
Ciaran has been advocating "SLOT operator" dependencies
On Sun, Jun 03, 2012 at 09:25:43AM +, Robin H. Johnson wrote:
> On Sun, Jun 03, 2012 at 08:31:43AM +, Duncan wrote:
> > Micha?? G??rny posted on Sun, 03 Jun 2012 09:22:04 +0200 as excerpted:
> >
> > >> Even if only the files metatdata changes, that still adds a significant
> > >> cost to a
On Tue, Jun 05, 2012 at 12:36:04AM +0200, Michael Weber wrote:
> On 06/04/2012 03:25 PM, Brian Harring wrote:
> > While I do grok the potential issue of someone being a hog
> > (specifically via blasting commit by commit rather than building up
> > work locally, then pushing it in chunks), frankl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/04/2012 03:25 PM, Brian Harring wrote:
> While I do grok the potential issue of someone being a hog
> (specifically via blasting commit by commit rather than building up
> work locally, then pushing it in chunks), frankly... I'm not that
> c
Hello, will send this to gentoo-dev mailing list per Zac's suggestion ;):
Probably Zac already remembers my suggestion of:
https://bugs.gentoo.org/show_bug.cgi?id=413619
Sorry for insisting a bit on it but this issue bites me periodically.
Months ago, I was able to administrate myself some of my
Hello, will send this to gentoo-dev mailing list per Zac's suggestion ;):
Probably Zac already remembers my suggestion of:
https://bugs.gentoo.org/show_bug.cgi?id=413619
Sorry for insisting a bit on it but this issue bites me periodically.
Months ago, I was able to administrate myself some of my
On Mon, 04 Jun 2012 22:52:25 +0200
"Andreas K. Huettel" wrote:
> No. What is signed is the "new data" plus the parent hash(es).
>
> No such thing as a "tree hash".
http://eagain.net/articles/git-for-computer-scientists/
Might clear things up a bit.
--
Ciaran McCreesh
signature.asc
Descripti
On Mon, Jun 4, 2012 at 4:41 PM, Brian Harring wrote:
>
> If that doesn't answer your question/concerns, be more explicit
> please.
How about a scenario:
1. Gentoo dev commits a bunch of stuff to the tree. Top of tree is signed.
2. Hacker commits something to the tree. Top of tree is not sign
> A signed commit is a signing of the git metadata; tree hash
> (literally, the state of the tree), committer, author, message, and
> parent sha1. Each git commit includes it's parent sha1 in it; this
> gives a locked history for a given commit sha1 (unless someone
> preimages sha1). What matters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/2012 10:06 PM, Michał Górny wrote:
> On Mon, 04 Jun 2012 21:26:00 +0200 hasufell
> wrote:
>
>> But minetest in sunrise for example which has two different
>> repos, one for the engine, one for the data. It's currently split
>> in two, but I
On Mon, Jun 04, 2012 at 03:27:03PM -0400, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring wrote:
> > One thing people need to keep in mind here is that when you sign the
> > commit, you're signing off on the history implicitly. ?Directly
> > addressing freeman's comment about "
On Mon, 04 Jun 2012 21:26:00 +0200
hasufell wrote:
> But minetest in sunrise for example which has two different repos, one
> for the engine, one for the data. It's currently split in two, but I
> guess I will merge those soon.
Why? Is there a good reason to merge two repos into one ebuild? Does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/2012 05:50 PM, Michał Górny wrote:
> On Mon, 04 Jun 2012 16:20:02 +0200 hasufell
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 06/04/2012 11:59 AM, Michał Górny wrote:
>>> One could set S to work on a subtree of the t
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring wrote:
> One thing people need to keep in mind here is that when you sign the
> commit, you're signing off on the history implicitly. Directly
> addressing freeman's comment about "people sign the manifest but don't
> look at what they're signing", wh
On Mon, Jun 04, 2012 at 08:45:42PM +0200, Dirkjan Ochtman wrote:
> On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman wrote:
> > Anything we do has to be automated to be of any real value. ??Ideally
> > if something goes wrong it should be as detectable as possible.
>
> Yeah, but you'd have to part of
On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman wrote:
> Anything we do has to be automated to be of any real value. Ideally
> if something goes wrong it should be as detectable as possible.
Yeah, but you'd have to part of that at every developer's box.
Can we just agree that having the tip of the
On Mon, Jun 4, 2012 at 12:19 PM, Dirkjan Ochtman wrote:
> So to prevent your scenario, we'd
> have to get everyone to check the signature of the tip of tree they
> pulled before committing/merging.
How can we be sure this has happened?
This is the problem with signed manifests today. I can sign
On Mon, Jun 4, 2012 at 6:06 PM, Rich Freeman wrote:
> Again, we don't need to be there 100% to go live. However, I think
> that was the whole point of signing commits. If we aren't going to
> add any assurance at all with our signing practices, then there isn't
> much point in having them.
True
On Mon, Jun 4, 2012 at 11:02 AM, Dirkjan Ochtman wrote:
> If the tree was bad before you pushed, then it's not your fault the
> tree is bad. You're only responsible for the commits you bring into
> the tree, so if you're merging contributor's unsigned changesets, you
> merge them with a signature
On Mon, 04 Jun 2012 16:20:02 +0200
hasufell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/04/2012 11:59 AM, Michał Górny wrote:
> > One could set S to work on a subtree of the tarball rather than the
> > whole tarball. Considering that, it's probably better to use
> > ${WOR
On Mon, Jun 4, 2012 at 4:48 PM, Rich Freeman wrote:
> When I do a cvs commit, I don't check the logs to make sure the last
> 25 commits all look valid. So, why would I expect others to do any
> differently in git. I make my changes, I run a git pull (bringing in
> the hacked commit on gentoo-x86
On Mon, Jun 4, 2012 at 10:26 AM, Dirkjan Ochtman wrote:
> On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman wrote:
>> How do you KNOW that the nearest signed descendant actually merged it?
>>
>> How do you know it wasn't added by a hacker?
>
> Because then the signature for the nearest signed descenda
On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman wrote:
> How do you KNOW that the nearest signed descendant actually merged it?
>
> How do you know it wasn't added by a hacker?
Because then the signature for the nearest signed descendant wouldn't
check out (unless it got hacked before he signed it,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/2012 11:59 AM, Michał Górny wrote:
> One could set S to work on a subtree of the tarball rather than the
> whole tarball. Considering that, it's probably better to use
> ${WORKDIR}/${P} rather than ${S}.
>
> Fixes: https://bugs.gentoo.org/sh
On Mon, Jun 4, 2012 at 9:48 AM, Dirkjan Ochtman wrote:
>
> You simply walk the tree from root to tip. When you encounter an
> unsigned changeset, the nearest signed descendant is responsible for
> merging that changeset.
>
How do you KNOW that the nearest signed descendant actually merged it?
Ho
On 06/04/2012 07:34 AM, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman wrote:
>> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel
>> wrote:
>>> However, then the "committer" of the contributed commits before the merge is
>>> then the user, I guess?
>>>
>>> (The rule mean
On Mon, Jun 4, 2012 at 3:40 PM, Rich Freeman wrote:
> The only thing the merge commit contains is a list of two parents, and
> a tree. It doesn't say which one is which, unless we can rely on
> their order.
You simply walk the tree from root to tip. When you encounter an
unsigned changeset, the
On Mon, Jun 4, 2012 at 8:45 AM, Dirkjan Ochtman wrote:
>
> Well, it doesn't seem like a big deal IF there's an explicit merge
> commit that's signed by a dev.
I'm not sure about that. If you were verifying a tree, how would you
identify which commits were merged in by what dev, using an automate
On Mon, Jun 04, 2012 at 03:49:31AM +, Kent Fredric wrote:
> On 3 June 2012 09:46, Robin H. Johnson wrote:
> If there are enough "Alice" developers, is it a possibility that Bob
> > will never have a chance to get his commit in?
> >
> > All this requires, is that in the time it takes Bob to do
On Mon, Jun 04, 2012 at 09:27:10AM +0200, Micha?? G??rny wrote:
> On Sun, 3 Jun 2012 09:48:26 +
> "Robin H. Johnson" wrote:
>
> > On Sun, Jun 03, 2012 at 11:34:07AM +0200, Micha?? G??rny wrote:
> > > I means using separate proto for metadata, not necesarrily git. In
> > > any case, if it come
Something went wrong here.
On 06/04/2012 03:39 PM, Alex Legler (a3li) wrote:
a3li12/06/04 12:39:01
Modified: ChangeLog
Log:
Drop maintainership
(Portage version: 2.2.0_alpha103/cvs/Linux x86_64)
Revision ChangesPath
1.6 x11-themes/gtk-engi
On Mon, Jun 4, 2012 at 2:34 PM, Rich Freeman wrote:
> Well, only Robin can explain exactly what he meant, but it sounds like
> we don't want the committer field to ever have a non-gentoo email in
> it, and signatures should be gentoo as well. So, if a dev just
> applies a patch to their tree/etc
On Mon, Jun 4, 2012 at 2:38 PM, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman wrote:
>> IMO we should try to be cutting down barriers from the git migration,
>> not throwing up more. The process has taken long enough already; the
>> desire to control everything about the m
On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman wrote:
> IMO we should try to be cutting down barriers from the git migration,
> not throwing up more. The process has taken long enough already; the
> desire to control everything about the migration is part of why it's
> taken so long.
Fair enough
On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman wrote:
> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel
> wrote:
>> However, then the "committer" of the contributed commits before the merge is
>> then the user, I guess?
>>
>> (The rule meaning as suggested by Robin
>>> - if you include a com
Both java-pkg_ensure-test and java-pkg_ensure-gcj will be removed from
java-utils-2.eclass after the 4 of July 2012. See attached patch.
java-pkg_ensure-test: [1]
Was used to enforce USE=test if FEATURES=test. For quite some time this
is handled by package managers. Relies on the env var FEATURES
One could set S to work on a subtree of the tarball rather than
the whole tarball. Considering that, it's probably better to use
${WORKDIR}/${P} rather than ${S}.
Fixes: https://bugs.gentoo.org/show_bug.cgi?id=419479
---
gx86/eclass/vcs-snapshot.eclass |5 +++--
1 file changed, 3 insertions(+
On Sat, Jun 2, 2012 at 7:30 PM, Michael Weber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Is there any way to verify the data?
>
> What programs/scripts use these fields btw?
euscan will soon, and I guess p.g.o will too.
> I could imagine a test like (i.e. type="sourceforge"
On Sun, 3 Jun 2012 09:48:26 +
"Robin H. Johnson" wrote:
> On Sun, Jun 03, 2012 at 11:34:07AM +0200, Micha?? G??rny wrote:
> > I means using separate proto for metadata, not necesarrily git. In
> > any case, if it comes to transferring a lot of frequently-changing
> > files, rsync is not that
46 matches
Mail list logo
