Dnia 2014-09-14, o godz. 21:30:36
Tim Harder radher...@gentoo.org napisał(a):
On 2014-09-14 10:46, Michał Górny wrote:
Dnia 2014-09-14, o godz. 15:40:06
Davide Pesavento p...@gentoo.org napisał(a):
How long does the md5-cache regeneration process take? Are you sure it
will be able to
Dnia 2014-09-15, o godz. 07:21:35
Patrick Lauer patr...@gentoo.org 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
On 14-09-2014 16:56:24 +0200, Michał Górny wrote:
Rich Freeman ri...@gentoo.org 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
On Thu, 11 Sep 2014 23:40:32 +
hasufell hasuf...@gentoo.org 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
On Sat, 13 Sep 2014 22:44:49 +
hasufell hasuf...@gentoo.org 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
On Thu, 11 Sep 2014 21:00:16 +0100
Markos Chandras hwoar...@gentoo.org 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
2014-09-10 15:59 GMT+01:00 Tom Wijsman tom...@gentoo.org:
On Wed, 10 Sep 2014 13:56:04 +
hasufell hasuf...@gentoo.org wrote:
Tom Wijsman:
On Tue, 09 Sep 2014 19:12:28 +
hasufell hasuf...@gentoo.org wrote:
Jauhien Piatlicki:
When I accept ~arch I expect that no live ebuilds
2014-09-13 21:03 GMT+01:00 Peter Stuge pe...@stuge.se:
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
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-15 10:24 GMT+01:00 Tom Wijsman tom...@gentoo.org:
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
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
Hi,
On 09/15/2014 01:37 AM, Kent Fredric wrote:
On 15 September 2014 11:25, hasufell hasuf...@gentoo.org 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
Jauhien Piatlicki:
Hi,
On 09/15/2014 01:37 AM, Kent Fredric wrote:
On 15 September 2014 11:25, hasufell hasuf...@gentoo.org 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
On 15 September 2014 22:10, Jauhien Piatlicki jauh...@gentoo.org 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
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. Then at
On Mon, Sep 15, 2014 at 12:35 PM, hasufell hasuf...@gentoo.org wrote:
Jauhien Piatlicki:
Hi,
On 09/15/2014 01:37 AM, Kent Fredric wrote:
On 15 September 2014 11:25, hasufell hasuf...@gentoo.org wrote:
Robin said
The Git commit-signing design explicitly signs the entire commit,
including
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
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-1
On Mon, Sep 15, 2014 at 7:37 AM, hasufell hasuf...@gentoo.org 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
Rich Freeman:
On Mon, Sep 15, 2014 at 7:37 AM, hasufell hasuf...@gentoo.org 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
On Mon, Sep 15, 2014 at 9:13 AM, hasufell hasuf...@gentoo.org 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
Rich Freeman:
On Mon, Sep 15, 2014 at 9:13 AM, hasufell hasuf...@gentoo.org 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
-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 hasuf...@gentoo.org
wrote:
* repoman must be run from all related directories (or the
top-level directory) on the latest commit that is being pushed
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
#
On Mon, Sep 15, 2014 at 10:26 AM, Ian Stakenvicius a...@gentoo.org 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
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
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
hasufell hasuf...@gentoo.org 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
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.
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 not
-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?
Is that going to be
-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 patr...@gentoo.org
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
-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.
..
That
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 of git - branches
On Mon, Sep 15, 2014 at 1:42 PM, Ian Stakenvicius a...@gentoo.org 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
-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 branch would
be
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 ri...@gentoo.org 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
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 ri...@gentoo.org napisał(a):
So, I don't really have a problem with your design. I still question
whether we still need to be
On Mon, Sep 15, 2014 at 3:55 PM, Anthony G. Basile bluen...@gentoo.org 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
Dnia 2014-09-15, o godz. 15:55:35
Anthony G. Basile bluen...@gentoo.org 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 ri...@gentoo.org napisał(a):
So, I
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
came
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 only
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-priority fix
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
On Mon, Sep 15, 2014 at 4:18 PM, Michał Górny mgo...@gentoo.org 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
-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} during
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
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
On 09/15/14 16:49, Rich Freeman wrote:
On Mon, Sep 15, 2014 at 4:18 PM, Michał Górny mgo...@gentoo.org 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
On Mon, Sep 15, 2014 at 7:02 AM, hasufell hasuf...@gentoo.org 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
On Tue, Sep 16, 2014 at 5:11 AM, Gordon Pettey petteyg...@gmail.com wrote:
On Mon, Sep 15, 2014 at 7:02 AM, hasufell hasuf...@gentoo.org 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
*
On Tue, Sep 16, 2014 at 5:41 AM, Duy Nguyen pclo...@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 somehow propagate that
to other repositories, since they'll just ignore it for having the same hash
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 somehow propagate that
to other repositories, since they'll just ignore it for having the same
-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}) if [[
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 and gpg
From: Alexander Berntsen alexan...@plaimi.net
Signed-off-by: Alexander Berntsen berna...@gentoo.org
---
For Brian to review, and anyone else who feels like it.
man/emerge.1| 3 ++-
pym/_emerge/depgraph.py | 7 +--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git
Second patch containing only the ebuild.sh change.
Answers to suggestions inline.
On Thu, Sep 11, 2014 at 12:49 PM, Zac Medico zmed...@gentoo.org wrote:
On 09/11/2014 04:18 AM, Bertrand Simonnet wrote:
Hi guys,
I have been working on a patch to make package.env (and env/ files)
On 09/15/2014 11:42 AM, Bertrand Simonnet wrote:
I replaced the FEATURES gate by a profile-formats option.
I added some logic to find layout.conf for a given profile path. (find
the first
parent dir named profiles then check ../metadata/layout.conf)
Is there a corner case that I missed?
I
58 matches
Mail list logo
