> 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 necessaril
On 15-09-2014 15:58:00 -0400, Rich Freeman wrote:
> > If the argument is that there are no Changelogs in rsync, then let's write
> > git hooks to generate them when the repository is mirrored to the rsync
> > host. The only problem I see is with this is then adding ChangeLog to the
> > manifest an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/15/2014 12:19 PM, Davide Pesavento wrote:
> kde5-functions.eclass
>
>> local ver=${1:-${PV}} local major=$(get_major_version ${ver})
>> local minor=$(get_version_component_range 2 ${ver}) local
>> micro=$(get_version_component_range 3 ${ver})
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 propagate that
> to other repositories, since they'll just ignore it for having the same hash
> as an alr
On Tue, Sep 16, 2014 at 5:41 AM, Duy Nguyen 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 hash
>> as an alre
On Tue, Sep 16, 2014 at 5:11 AM, Gordon Pettey wrote:
> On Mon, Sep 15, 2014 at 7:02 AM, hasufell wrote:
>>
>> hasufell:
>> >
>> > * there is no known SHA-1 collision afais
>> > * calculating one isn't that hard. NSA might be able to do it in
>> > reasonable time
>> > * however, the algorithms to
On Mon, Sep 15, 2014 at 7:02 AM, hasufell wrote:
> hasufell:
> >
> > * there is no known SHA-1 collision afais
> > * calculating one isn't that hard. NSA might be able to do it in
> > reasonable time
> > * however, the algorithms to do that will come up with random garbage,
> > so it's a complete
On 09/15/14 16:49, Rich Freeman wrote:
On Mon, Sep 15, 2014 at 4:18 PM, Michał Górny 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 wo
Rich Freeman:
>
> I'm not sure ditching rsync entirely is necessary - it might be more
> trouble than it is worth as it is a very effective simple way to
> distribute the tree. However, I'm not really opposed to it either.
>
The few people I personally know who use gentoo never use rsync for
sy
Ian Stakenvicius:
>
> It's generally considered safe to push to origin/master a commit from
> a temporary local branch?
Why not?
Even if you have to rebase/merge, nothing will happen with your unstaged
local changes as long as no one has messed with the firefox ebuild in
the meantime... and then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/09/14 04:31 PM, hasufell wrote:
> hasufell:
>> Ian Stakenvicius:
>>>
>>> Repeating my example, say i'm working on a new release of
>>> firefox, it takes ~40 mins to compile and there's some stuff it
>>> needs to do with files in ${FILESDIR} du
On Mon, Sep 15, 2014 at 4:18 PM, Michał Górny 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 effective simpl
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
‘emerge sync’ that could handle either rsync or Git, stabilize that
Porta
hasufell:
> Ian Stakenvicius:
>>
>> Repeating my example, say i'm working on a new release of firefox, it
>> takes ~40 mins to compile and there's some stuff it needs to do with
>> files in ${FILESDIR} during src_install. So i'm 'ebuild ...
>> install'ing that. In the meantime, there's a high-pri
On Mon, Sep 15, 2014 at 10:18:39PM +0200, Michał Górny wrote:
> Dnia 2014-09-15, o godz. 15:55:35 Anthony G. Basile napisał(a):
> > If the argument is that there are no Changelogs in rsync, then
> > let's write git hooks to generate them when the repository is
> > mirrored to the rsync host. The o
Ian Stakenvicius:
>
> Repeating my example, say i'm working on a new release of firefox, it
> takes ~40 mins to compile and there's some stuff it needs to do with
> files in ${FILESDIR} during src_install. So i'm 'ebuild ...
> install'ing that. In the meantime, there's a high-priority fix that
>
Dnia 2014-09-15, o godz. 15:55:35
"Anthony G. Basile" napisał(a):
> On 09/15/14 15:30, William Hubbs wrote:
> > On Mon, Sep 15, 2014 at 09:53:43AM +0200, Fabian Groffen wrote:
> >> On 14-09-2014 16:56:24 +0200, Michał Górny wrote:
> >>> Rich Freeman napisał(a):
> So, I don't really have a p
On Mon, Sep 15, 2014 at 3:55 PM, Anthony G. Basile 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 git's logging f
On 09/15/14 15:30, William Hubbs wrote:
On Mon, Sep 15, 2014 at 09:53:43AM +0200, Fabian Groffen wrote:
On 14-09-2014 16:56:24 +0200, Michał Górny wrote:
Rich Freeman napisał(a):
So, I don't really have a problem with your design. I still question
whether we still need to be generating chang
On Mon, Sep 15, 2014 at 09:53:43AM +0200, Fabian Groffen wrote:
> On 14-09-2014 16:56:24 +0200, Michał Górny wrote:
> > Rich Freeman napisał(a):
> > > So, I don't really have a problem with your design. I still question
> > > whether we still need to be generating changelogs - they seem
> > > inc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/09/14 02:35 PM, hasufell wrote:
> Ian Stakenvicius:
>> 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. A branc
On Mon, Sep 15, 2014 at 1:42 PM, Ian Stakenvicius 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. A bran
Ian Stakenvicius:
> 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. A branch would be more
>>> appropriate for some kind of mini-project.
>> ..
>>> That is the beauty o
-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. A branch would be more
>> appropriate for some kind of mini-project.
> ..
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/09/14 08:57 PM, Rich Freeman wrote:
> On Sun, Sep 14, 2014 at 7:21 PM, Patrick Lauer
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/09/14 07:21 PM, 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"?
>>>
>>> I
kde5-functions.eclass
> inherit versionator
versionator doesn't export any phase functions so it can stay inside the
_KDE5_FUNCTIONS_ECLASS conditional block.
> case ${EAPI:-0} in
I believe :-0 is unnecessary here, "*)" will match anyway, but it doesn't
hurt either.
> *) die "EAPI=${EAPI} is n
Rich Freeman:
>
> I suggest we just get git working in a fashion that is "good enough."
Sure, that's what I've been saying. Otherwise I'd propose to remove
access for everyone and only grant project leads/reviewers direct push
access. But as said... we are not ready for something like that.
Howe
hasufell 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/daily/etc.
>>
Rich Freeman:
> It would make a lot more sense if we had a release-oriented strategy,
> even if releases were hourly/daily/etc.
>
If we are going that way, then we should think over the whole branching
model. I have a few things in mind, but I think we are already
fine-tuning stuff here that can
Ian Stakenvicius:
>
> 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 committing separate single-package commits at the
On Mon, Sep 15, 2014 at 10:26 AM, Ian Stakenvicius 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 committing
Hi,
Please find attached two new KDE eclasses for review, required to
support KDE Frameworks 5 and its consumers.
I will commit in a week or so in the absence of major issues, with the
masked packages to follow shortly after.
Best regards,
Michael
# Copyright 1999-2014 Gentoo Foundation
# Distri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/09/14 09:13 AM, hasufell wrote:
> Rich Freeman:
>> On Mon, Sep 15, 2014 at 7:37 AM, hasufell
>> wrote:
>>> * repoman must be run from all related directories (or the
>>> top-level directory) on the latest commit that is being pushed
>>
>> Thi
Rich Freeman:
> On Mon, Sep 15, 2014 at 9:13 AM, hasufell 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 yo
On Mon, Sep 15, 2014 at 9:13 AM, hasufell 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 changes are that b
Rich Freeman:
> On Mon, Sep 15, 2014 at 7:37 AM, hasufell 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,
On Mon, Sep 15, 2014 at 7:37 AM, hasufell 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 perhaps on a "parent
hasufell:
>
> * there is no known SHA-1 collision afais
> * calculating one isn't that hard. NSA might be able to do it in
> reasonable time
> * however, the algorithms to do that will come up with random garbage,
> so it's a completely different thing to hide a useful vulnerability
> behind a SHA
On Mon, Sep 15, 2014 at 11:26:47PM +1200, Kent Fredric wrote:
> None of these are impossible things, but they're much more complex than
> "just make a dodgy commit and get somebody to pull it".
Much more simple would be to make a dodgy commit by one of the devs. Why
use users for that, if "the bad
On Mon, Sep 15, 2014 at 12:35 PM, hasufell wrote:
> Jauhien Piatlicki:
>> Hi,
>>
>> On 09/15/2014 01:37 AM, Kent Fredric wrote:
>>> On 15 September 2014 11:25, hasufell wrote:
>>>
Robin said
> The Git commit-signing design explicitly signs the entire commit,
including blob contents,
Andreas K. Huettel:
>>
>> However, rebasing changes *on* master, before they are pushed, is a good
>> thing, because that kills non-fast-forward merges.
>>
>
> Nontrivial rebases *on* master can be problematic because you're changing
> history.
>
> Imagine you pull some nice commits from a user
On 15 September 2014 22:10, Jauhien Piatlicki wrote:
> So signing of git commits does not guarantee enough security (taking
> that SHA1 is weak and can be broken), right? Could we than just use
> usual (not thin) manifests?
>
However, the attackability of SHA1 may be entirely immaterial, because
Jauhien Piatlicki:
> Hi,
>
> On 09/15/2014 01:37 AM, Kent Fredric wrote:
>> On 15 September 2014 11:25, hasufell wrote:
>>
>>> Robin said
The Git commit-signing design explicitly signs the entire commit,
>>> including blob contents, to avoid this security problem.
>>>
>>> Is this correct or
Hi,
On 09/15/2014 01:37 AM, Kent Fredric wrote:
> On 15 September 2014 11:25, hasufell wrote:
>
>> Robin said
>>> The Git commit-signing design explicitly signs the entire commit,
>> including blob contents, to avoid this security problem.
>>
>> Is this correct or not?
>>
>
> I can verify a com
On Mon, 15 Sep 2014 10:28:16 +0100
Georg Rudoy <0xd34df...@gmail.com> wrote:
> Let's limit our sample to Gentoo tree then. How frequently arches list
> shrinked as a result of bumping the version (because the upstream has
> chosen so, not because of insufficient resources to keep testing all
> pr
2014-09-15 10:24 GMT+01:00 Tom Wijsman :
> On Mon, 15 Sep 2014 10:11:08 +0100
> Georg Rudoy <0xd34df...@gmail.com> wrote:
>
>> How frequently the list of supported arches does shrink? Is it
>> statistically significant?
>
> The amount of software that exists makes this impossible to determine.
>
L
On Mon, 15 Sep 2014 10:11:08 +0100
Georg Rudoy <0xd34df...@gmail.com> wrote:
> How frequently the list of supported arches does shrink? Is it
> statistically significant?
The amount of software that exists makes this impossible to determine.
2014-09-13 21:03 GMT+01:00 Peter Stuge :
> I would actually expect
> there to be a policy which forbids patches on live ebuilds. Make
> another live ebuild or maybe an overlay if you want to offer a
> different set of commits than the upstream repo.
>
> For me, the whole point of live ebuilds is th
2014-09-10 15:59 GMT+01:00 Tom Wijsman :
> On Wed, 10 Sep 2014 13:56:04 +
> hasufell wrote:
>
>> Tom Wijsman:
>> > On Tue, 09 Sep 2014 19:12:28 +
>> > hasufell wrote:
>> >
>> >> Jauhien Piatlicki:
>> >>>
>> >>> When I accept ~arch I expect that no live ebuilds will be built. I
>> >>> thin
On Thu, 11 Sep 2014 21:00:16 +0100
Markos Chandras wrote:
> please do not go offtopic discussing the recruitment process. I simply
> mentioned one of the designated ways we have to ask for help. If you
> don't like it, propose a better method.
Please do not go offtopic about your own "getting pe
On Sat, 13 Sep 2014 22:44:49 +
hasufell wrote:
> Jauhien Piatlicki:
>
> > In the ideal country of elves. In the real life it can be not
> > possible to build and install software in a given distribution
> > without downstream patches. You can find examples of such live
> > ebuilds in Gentoo
On Thu, 11 Sep 2014 23:40:32 +
hasufell wrote:
> I don't see [...]
It is hard to connect the dots if you don't know about the dots;
do your homework to find them, ask questions when you don't.
> [...] any sense in what you say. You sound confused.
Without those dots, your sound of confusio
On 14-09-2014 16:56:24 +0200, Michał Górny wrote:
> Rich Freeman napisał(a):
> > So, I don't really have a problem with your design. I still question
> > whether we still need to be generating changelogs - they seem
> > incredibly redundant. But, if people really want a redundant copy of
> > the
Dnia 2014-09-15, o godz. 07:21:35
Patrick Lauer napisał(a):
> 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 sa
Dnia 2014-09-14, o godz. 21:30:36
Tim Harder napisał(a):
> On 2014-09-14 10:46, Michał Górny wrote:
> > Dnia 2014-09-14, o godz. 15:40:06
> > Davide Pesavento napisał(a):
> > > How long does the md5-cache regeneration process take? Are you sure it
> > > will be able to keep up with the rate of p
56 matches
Mail list logo
