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

-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

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

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 "cle

[gentoo-dev] Add bc back to the stage3

The bc utility is part of the posix tools and it might be used to build linux among the other stuff. lu

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

Dnia 2014-09-16, o godz. 19:05:18 Luca Barbato 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 regenerating the cac

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

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 > changelog

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

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 be sane with ou

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

On Tue, 16 Sep 2014 10:52:13 -0700 "W. Trevor King" 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 benefit

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

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

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

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 f

[gentoo-dev] Re: RFC: kde5 and kde5-functions eclass

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 ha

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

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 5.25-i

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

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. > >

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

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

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] My masterplan for git migration (+ looking for infra to test it)

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? >>

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

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 p

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

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 th

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

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 sam

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

On 14/09/14 17:15, Kent Fredric wrote: > On 15 September 2014 02:40, Michał Górny 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). >> > > > Easy

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

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

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

El mar, 16-09-2014 a las 09:55 -0400, Rich Freeman escribió: > 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 wa

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/09/14 10:33 AM, Kent Fredric wrote: > > On 17 September 2014 01:44, Ian Stakenvicius > wrote: > >> bottom of the comment a clearsign on the contents of the commit? > > [...] the very best I think you could do is sign

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

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 hea

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

On 17 September 2014 01:44, Ian Stakenvicius 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: recursively compa

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

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 th

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] 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] Re: My masterplan for git migration (+ looking for infra to test it)

El mar, 16-09-2014 a las 07:26 -0400, Rich Freeman escribió: > 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

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

-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 > 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 pro

[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 quickly or someone else is willing to provide the >> > in

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

Rich Freeman: > 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 > workflo

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

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

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 happe

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

Ulrich Mueller: > > ChangeLogs are aimed at users Did any1 ask them if they care?