On Mon, 15 Sep 2014, Rich Freeman wrote:
I'll add this to the next Council agenda. I think this is ripe for
discussion. The last discussion of this really wasn't aimed at git
anyway.
Some of the arguments back then were that a) ChangeLogs are aimed at
users, so they don't necessarily
Ulrich Mueller:
ChangeLogs are aimed at users
Did any1 ask them if they care?
On 16/09/2014 12:18, hasufell wrote:
Ulrich Mueller:
ChangeLogs are aimed at users
Did any1 ask them if they care?
I'm a user and I don't care.
I use diff. I only go to the Changelog when I can't determine the
maintainers intent from diff and the ebuild content. That happens maybe
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/09/14 07:59 PM, Rich Freeman wrote:
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
El mar, 16-09-2014 a las 07:26 -0400, Rich Freeman escribió:
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
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
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
On 09/16/2014 10:03 AM, Rich Freeman wrote:
The gpg signature is on the entire contents of the commit. However,
the contents of the commit do not include the files that are being
committed - it includes hashes of the parent commit, the commit
message, other headers, and the hash of the tree
On 17 September 2014 01:44, Ian Stakenvicius a...@gentoo.org wrote:
bottom of the comment a clearsign on the contents of the commit?
I don't see that being useful as written, because that's presently exactly
what git does.
the very best I think you could do is sign the commit *diff*, ie:
Michael Orlitzky:
On 09/16/2014 10:03 AM, Rich Freeman wrote:
The gpg signature is on the entire contents of the commit. However,
the contents of the commit do not include the files that are being
committed - it includes hashes of the parent commit, the commit
message, other headers, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/09/14 10:33 AM, Kent Fredric wrote:
On 17 September 2014 01:44, Ian Stakenvicius a...@gentoo.org
mailto:a...@gentoo.org wrote:
bottom of the comment a clearsign on the contents of the commit?
[...] the very best I think you could do
El mar, 16-09-2014 a las 09:55 -0400, Rich Freeman escribió:
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,
Rich Freeman wrote:
If you want to satisfy yourself I believe you can get git to dump
the contents of any object without formatting/etc.
git ls-tree HEAD .
git show $blobhash
git show --pretty=raw HEAD
//Peter
On 14/09/14 17:15, Kent Fredric wrote:
On 15 September 2014 02:40, Michał Górny mgo...@gentoo.org wrote:
However, I'm wondering if it would be possible to restrict people from
accidentally committing straight into github (e.g. merging pull
requests there instead of to our main server).
On 14/09/14 16:46, Michał Górny wrote:
Of course, if we can't spare the resources to do intermediate updates,
we may as well switch to cron-based update method.
The mirror have a sync time, so basically regenerating the cache and
pushing the tree with further toward the user can happen the same
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 commit frequency? Worst case we can aggregate changes and
push them in
Anthony G. Basile posted on Mon, 15 Sep 2014 17:43:09 -0400 as excerpted:
We could just push out the word that ChangeLogs are going away and they
have to read the git repo. That might be the easiest solution. I do
have users that quote my ChangeLogs though.
As such a user...
Given the
On 15/09/14 01:21, Patrick Lauer wrote:
On Sunday 14 September 2014 15:42:15 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
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
W. Trevor King posted on Mon, 15 Sep 2014 13:33:46 -0700 as excerpted:
On Mon, Sep 15, 2014 at 01:29:44PM -0700, W. Trevor King wrote:
I don't see any benefit to using rsync vs. a shallow clone as the
transmission protocol.
Other than the fact that before you dropped it you'd need to push a
On Tue, Sep 16, 2014 at 05:35:08PM +, Duncan wrote:
W. Trevor King posted on Mon, 15 Sep 2014 13:33:46 -0700 as excerpted:
On Mon, Sep 15, 2014 at 01:29:44PM -0700, W. Trevor King wrote:
I don't see any benefit to using rsync vs. a shallow clone as the
transmission protocol.
Other
Rich Freeman posted on Tue, 16 Sep 2014 09:55:31 -0400 as excerpted:
Or they could just clone the git tree, and they can look at per-file
logs anytime they want to.
Give me ro access to a current git repo and I'll *VERY* happily leave
changelogs to history along with 8-track tapes and
On 09/16/2014 02:19 AM, Davide Pesavento wrote:
if [[ -a CMakeLists.txt ]]; then
Unnecessary quoting. Also, -e is more common than -a
I guess both the eclasses (and a lot of Gentoo stuff in general) has
quoting that's not strictly necessary.
Thanks for the review, everything else has
On Tue, Sep 16, 2014 at 10:52:13AM -0700, W. Trevor King wrote:
Oh, lovely :). Looks like that landed in 2.2.0 with 47e8d22d (Add
support for multiple repositories in `emerge --sync`, 2013-07-23).
Actually, ‘git pull’ support in one form or another dates back to
ba797c11 (Add --sync support
W. Trevor King posted on Tue, 16 Sep 2014 10:52:13 -0700 as excerpted:
Also, I don't see a way to say “use Git to sync, but keep a shallow
repository”.
Presumably at some point we'd get the PORTAGE_GIT* equivalent of the
PORTAGE_RSYNC* settings from make.conf, but settable in both make.conf
On Tue, 16 Sep 2014 10:52:13 -0700
W. Trevor King wk...@tremily.us wrote:
On Tue, Sep 16, 2014 at 05:35:08PM +, Duncan wrote:
W. Trevor King posted on Mon, 15 Sep 2014 13:33:46 -0700 as
excerpted:
On Mon, Sep 15, 2014 at 01:29:44PM -0700, W. Trevor King wrote:
I don't see any
Il 16/09/2014 20:02, Duncan ha scritto:
Rich Freeman posted on Tue, 16 Sep 2014 09:55:31 -0400 as excerpted:
Or they could just clone the git tree, and they can look at per-file
logs anytime they want to.
Give me ro access to a current git repo and I'll *VERY* happily leave
changelogs to
Dnia 2014-09-16, o godz. 19:05:18
Luca Barbato lu_z...@gentoo.org napisał(a):
On 14/09/14 16:46, Michał Górny wrote:
Of course, if we can't spare the resources to do intermediate updates,
we may as well switch to cron-based update method.
The mirror have a sync time, so basically
The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.
lu
On 09/16/2014 01:56 PM, hasufell wrote:
Luca Barbato:
On 15/09/14 01:21, Patrick Lauer wrote:
On Sunday 14 September 2014 15:42:15 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/16/2014 05:18 AM, hasufell wrote:
Ulrich Mueller:
ChangeLogs are aimed at users
Did any1 ask them if they care?
If the tree switches to git and there's an option within
Portage/emerge to fetch via git instead of rsync, then I'd rather
I moved the profile attributes detection logic into the python side as
suggested (much cleaner).
The updated patch is attached.
Thanks,
Bertrand
On Mon, Sep 15, 2014 at 1:40 PM, Zac Medico zmed...@gentoo.org wrote:
On 09/15/2014 11:42 AM, Bertrand Simonnet wrote:
I replaced the FEATURES
This fixes an IndexError in _solve_non_slot_operator_slot_conflicts
which occurs when none of the conflict packages matched a particular
atom. This typically means that autounmask broke a USE-dep, but it could
also be due to the slot not matching due to multislot (bug #220341).
Either way, don't
On 09/16/2014 11:17 AM, Bertrand Simonnet wrote:
I moved the profile attributes detection logic into the python side as
suggested (much cleaner).
Thanks, that's better. I've got a couple more issues though:
1) Like global functions, global variables should also be unset in
__save_ebuild_env.
On Tue, Sep 16, 2014 at 12:17 PM, Zac Medico zmed...@gentoo.org wrote:
On 09/16/2014 11:17 AM, Bertrand Simonnet wrote:
I moved the profile attributes detection logic into the python side as
suggested (much cleaner).
Thanks, that's better. I've got a couple more issues though:
1) Like
On 09/16/2014 02:37 PM, Bertrand Simonnet wrote:
On Tue, Sep 16, 2014 at 12:17 PM, Zac Medico zmed...@gentoo.org
mailto:zmed...@gentoo.org wrote:
On 09/16/2014 11:17 AM, Bertrand Simonnet wrote:
I moved the profile attributes detection logic into the python side as
39 matches
Mail list logo
