On Sun, Jun 3, 2012 at 9:07 PM, Rich Freeman ri...@gentoo.org wrote:
A test of some sort would cut down the risk of the unexpected when we
do the real migration.
I understand the desire for this, but I don't think it will work. The
first few hours/days after the git migration are going to be
On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel dilfri...@gentoo.org 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 commit from a user:
author := non-@gentoo
On Sun, 3 Jun 2012 09:48:26 +
Robin H. Johnson robb...@gentoo.org 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
On Sat, Jun 2, 2012 at 7:30 PM, Michael Weber x...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Is there any way to verify the remote-id 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.
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
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
On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel dilfri...@gentoo.org
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
-
On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman d...@gentoo.org 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.
On Mon, Jun 4, 2012 at 2:38 PM, Rich Freeman ri...@gentoo.org wrote:
On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman d...@gentoo.org 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
On Mon, Jun 4, 2012 at 2:34 PM, Rich Freeman ri...@gentoo.org 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
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
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 robb...@gentoo.org 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
On Mon, Jun 04, 2012 at 03:49:31AM +, Kent Fredric wrote:
On 3 June 2012 09:46, Robin H. Johnson robb...@gentoo.org 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
On Mon, Jun 4, 2012 at 8:45 AM, Dirkjan Ochtman d...@gentoo.org 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,
On Mon, Jun 4, 2012 at 3:40 PM, Rich Freeman ri...@gentoo.org 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
On 06/04/2012 07:34 AM, Rich Freeman wrote:
On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel dilfri...@gentoo.org
wrote:
However, then the committer of the contributed commits before the merge is
then the user, I guess?
On Mon, Jun 4, 2012 at 9:48 AM, Dirkjan Ochtman d...@gentoo.org 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
-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:
On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 10:26 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 4:48 PM, Rich Freeman ri...@gentoo.org 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 Mon, 04 Jun 2012 16:20:02 +0200
hasufell hasuf...@gentoo.org 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
On Mon, Jun 4, 2012 at 11:02 AM, Dirkjan Ochtman d...@gentoo.org 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
On Mon, Jun 4, 2012 at 6:06 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 12:19 PM, Dirkjan Ochtman d...@gentoo.org 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
On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 04, 2012 at 08:45:42PM +0200, Dirkjan Ochtman wrote:
On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring ferri...@gmail.com 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
-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 hasuf...@gentoo.org
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
On Mon, 04 Jun 2012 21:26:00 +0200
hasufell hasuf...@gentoo.org 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
On Mon, Jun 04, 2012 at 03:27:03PM -0400, Rich Freeman wrote:
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring ferri...@gmail.com 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
-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 hasuf...@gentoo.org
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
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 is
On Mon, Jun 4, 2012 at 4:41 PM, Brian Harring ferri...@gmail.com 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
On Mon, 04 Jun 2012 22:52:25 +0200
Andreas K. Huettel dilfri...@gentoo.org 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
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
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
-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
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), frankly...
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 an rsync.
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 for
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
On Mon, 28 May 2012 09:58:56 +0200
Michał Górny mgo...@gentoo.org 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:
On Mon, Jun 4, 2012 at 10:41 PM, Brian Harring ferri...@gmail.com 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
On 06/04/2012 04:57 AM, 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 for
El lun, 04-06-2012 a las 13:44 -0700, Zac Medico escribió:
On 06/04/2012 04:57 AM, 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
On 06/02/2012 04:54 PM, Mike Frysinger wrote:
On Saturday 02 June 2012 14:53:19 Zac Medico wrote:
On 05/11/2012 09:39 AM, Mike Frysinger wrote:
+ exec {mj_control_fd}${mj_control_pipe}
I've heard that this is new in bash 4.1 [1]. Hopefully it doesn't bother
anyone if portage relies on
47 matches
Mail list logo
