On Saturday 02 June 2012 00:11:19 Brian Harring wrote:
> On Fri, Jun 01, 2012 at 06:41:22PM -0400, Mike Frysinger wrote:
> > and put it into a new multiprocessing.eclass. this way people can
> > generically utilize this in their own eclasses/ebuilds.
> >
> > it doesn't currently support nesting.
On Friday 01 June 2012 22:50:10 hasufell wrote:
> On 06/02/2012 12:49 AM, Mike Frysinger wrote:
> > On Wednesday 23 May 2012 21:04:42 hasufell wrote:
> >> # @FUNCTION: _iconins
> >> # @DESCRIPTION:
> >> # function for use in doicon and newicon
> >
> > mark it @INTERNAL
what i meant here was:
# @F
On Fri, Jun 01, 2012 at 06:41:22PM -0400, Mike Frysinger wrote:
> regenerating autotools in packages that have a lot of AC_CONFIG_SUBDIRS is
> really slow due to the serialization of all the dirs (which really isn't
> required). so i took some code that i merged into portage semi-recently
> (which
On Fri, Jun 01, 2012 at 08:52:42PM -0400, Rich Freeman wrote:
> On Fri, Jun 1, 2012 at 4:49 PM, Michael Weber wrote:
> > Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
> > 22 minutes of 3.4GHz cpus).
> As others have pointed out, probably the best way to bootstrap this is
>
The small typo in the comment section (fuqbar.svg -> fuqbar.png) has
been fixed :P
On 06/02/2012 12:49 AM, Mike Frysinger wrote:
> On Wednesday 23 May 2012 21:04:42 hasufell wrote:
>> # @FUNCTION: _iconins
>> # @DESCRIPTION:
>> # function for use in doicon and newicon
>
> mark it @INTERNAL
>
>> if [[ -z $size ]] ; then
>
> ${size}
>
>>
On Tuesday 29 May 2012 15:00:15 Sergei Trofimovich wrote:
> Nice to drop '|| die' and have REQUIRED_USE in games ebuilds
we've already got:
https://bugs.gentoo.org/336626
please collaborate there
-mike
signature.asc
Description: This is a digitally signed message part.
On Fri, Jun 1, 2012 at 4:49 PM, Michael Weber wrote:
>
> Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
> 22 minutes of 3.4GHz cpus).
>
As others have pointed out, probably the best way to bootstrap this is
to offer tarballs of a shallow repository and a full repository.
Pe
> "WH" == William Hubbs writes:
WH> My big complaint about merge commits is if you do a git show on
WH> a merge commit, you get nothing,
With current git and proper merge logs you get useful info.
The headers contain the hashes, so you can get the list of
commits pulled by that merge
example conversion of eatureconf
-mike
--- autotools.eclass
+++ autotools.eclass
@@ -16,7 +16,7 @@
if [[ ${___ECLASS_ONCE_AUTOTOOLS} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_AUTOTOOLS="recur -_+^+_- spank"
-inherit libtool
+inherit libtool multiprocessing
# @ECLASS-VARIABLE: WANT_A
On Wednesday 23 May 2012 21:04:42 hasufell wrote:
> # @FUNCTION: _iconins
> # @DESCRIPTION:
> # function for use in doicon and newicon
mark it @INTERNAL
> if [[ -z $size ]] ; then
${size}
> if [[ $function == doicon ]] ; then
${function}
> if
On Friday 01 June 2012 07:37:52 Dirkjan Ochtman wrote:
> It looks to me (from looking at eshowkw for python packages quite a
> bit) that a great many packages aren't being keyworded on m68k. Would
> it perhaps make sense to drop it from the set of stable arches (for
> example, in the bugzilla selec
regenerating autotools in packages that have a lot of AC_CONFIG_SUBDIRS is
really slow due to the serialization of all the dirs (which really isn't
required). so i took some code that i merged into portage semi-recently
(which is based on work by Brian, although i'm not sure he wants to admit it)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/31/2012 02:04 PM, Aaron W. Swenson wrote:
> The 6 hours it takes to clone the repo.
afaik it's 6 hours to transform the whole cvs history into a git repo.
Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
22 minutes of 3.4G
On Fri, Jun 01, 2012 at 04:33:35PM +, Robin H. Johnson wrote:
> On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
> > Overlays are completely separate repositories. There is nothing stopping
> > an overlay from using git right now even if the main tree isn't using
> > git. They jus
On Fri, Jun 1, 2012 at 12:33 PM, Robin H. Johnson wrote:
> What about overlay repositories that elect to be a branch of the main
> tree via git?
>
> Do we call that forbidden usage?
I think that branches off of the main tree are mainly going to be
useful for more eclass/profile/etc-related work.
On Sat, Jun 02, 2012 at 04:56:33AM +1200, Kent Fredric wrote:
> > Only in your local history. The push to the central repo would only send
> > the commits in the active chain to your branch HEAD.
> Any commits that are rebased, and then replicated somewhere after that
> rebase, will be stripped of
> Only in your local history. The push to the central repo would only send
> the commits in the active chain to your branch HEAD.
Any commits that are rebased, and then replicated somewhere after that
rebase, will be stripped of their signatures by the rebase process.
--
Kent
perl -e "print
On 2 June 2012 04:33, Robin H. Johnson wrote:
> On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
>> Overlays are completely separate repositories. There is nothing stopping
>> an overlay from using git right now even if the main tree isn't using
>> git. They just work in their git re
On Fri, Jun 01, 2012 at 11:53:52AM -0400, Rich Freeman wrote:
> However, Kent did point out the rebase function doesn't actually apply
> new signatures to the "new old" commits anyway, so you'd end up with
> unsigned commits in the history.
Only in your local history. The push to the central repo w
On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
> Overlays are completely separate repositories. There is nothing stopping
> an overlay from using git right now even if the main tree isn't using
> git. They just work in their git repositories until they are ready to
> commit somethin
On Sat, Jun 02, 2012 at 03:56:43AM +1200, Kent Fredric wrote:
> You can however merge dissimilar histories with no common parents if
> you know what you're doing. It does warn you, but it still lets you do
> it.
>
> …
>
> Yeah, selectively pulling in files with histories however is hard,
> I've o
On 2 June 2012 03:53, Rich Freeman wrote:
> git-rebase is just a shell script, that ultimately just calls
> git-commit as far as I can see, which means that implementing
> re-signing is just a matter of adding the appropriate parameters, or
> use default configuration (assuming it doesn't already
On Fri, Jun 1, 2012 at 5:53 PM, Rich Freeman wrote:
> If you want the tree to be traceable to Gentoo devs, then rewriting
> the signatures is probably a good thing.
I'd say that signing the merge commit is good enough. It says the
Gentoo dev who merged it has reviewed the changes and can be held
On 2 June 2012 03:39, Rich Freeman wrote:
> On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht wrote:
>> So, like explained before your concern is clearly out of the current
>> discussion. Importing commit history from Overlays is not supported and
>> will probably never be. Gentoo doesn't forces (
On Fri, Jun 1, 2012 at 11:36 AM, Andreas K. Huettel
wrote:
>> On 2 June 2012 03:12, Andreas K. Huettel wrote:
>> Yes. Which basically means, you *cannot* have both
>>
>> a) rebase only merges
>> and
>> b) every commit must be signed
>>
>> as policies.
>>
>
> I would say that this is a very strong
On Fri, Jun 01, 2012 at 12:57:10PM +, Duncan wrote:
> William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted:
> > Overlays aren't really part of this discussion; those are independent
> > trees which we have no control over, so commiting changes from overlays
> > to the main tree
On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht wrote:
> So, like explained before your concern is clearly out of the current
> discussion. Importing commit history from Overlays is not supported and
> will probably never be. Gentoo doesn't forces (and doesn't want to)
> overlays maintainers to u
On Sat, 2 Jun 2012 03:25:43 +1200
Kent Fredric wrote:
> On 2 June 2012 03:12, Andreas K. Huettel wrote:
> >> "git cat-file -p $sha" is as close as you can get to commit objects
> >> without needing to write your own decompressing wrapper. But it
> >> gives the same results.
> >
> > Now, does th
> On 2 June 2012 03:12, Andreas K. Huettel wrote:
> >> "git cat-file -p $sha" is as close as you can get to commit objects
> >> without needing to write your own decompressing wrapper. But it gives
> >> the same results.
> >
> > Now, does the "signed data" also contain the parent sha?
> >
> > I
On Fri, Jun 1, 2012 at 11:12 AM, Andreas K. Huettel
wrote:
> Now, does the "signed data" also contain the parent sha?
>
So, I was working on a lengthy email which now would be fairly
repetitive of what Kent posted.
Suffice it to say I managed to rip out a commit from the kde overlay,
deflate it,
On 2 June 2012 03:12, Andreas K. Huettel wrote:
>> "git cat-file -p $sha" is as close as you can get to commit objects
>> without needing to write your own decompressing wrapper. But it gives
>> the same results.
>
> Now, does the "signed data" also contain the parent sha?
>
> If yes, our discuss
> "git cat-file -p $sha" is as close as you can get to commit objects
> without needing to write your own decompressing wrapper. But it gives
> the same results.
Now, does the "signed data" also contain the parent sha?
If yes, our discussion about rebasing is moot, because a rebase will in every
> The purpose of overlays is to have ebuilds maintained outside of the
> official Gentoo portage. Importing a ebuild from an overlay whether it
> uses Git or not means importing the ebuild(s). In the Git context, it
> means the Gentoo maintainer has to make an import commit the same way
> it would
On 2 June 2012 00:42, Rich Freeman wrote:
> On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric wrote:
>>
>> Nope, at least not as far as I can tell, and I just implemented commit
>> signature verification >_>
>
> I've been trying to find an example of a signed commit, but can't find
> one anywhere, so
Hi,
I'm going to drop maintainership of app-misc/gcal due to lack of
interest. Does someone want to take it? Otherwise, it will fall back
to the shell-tools herd. Apart from one open stable request, there are
no open bugs.
Upstream situation for this package is a bit unclear: There's version
3.6*
The 01/06/12, Duncan wrote:
> But it seems to me that overlays are the primary use case for commits to
> public trees other than gentoo first. Otherwise, the whole rebase-vs-
> merge problem goes away, because the first public commit is to the gentoo
> tree. But especially with overlays (like
William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted:
> On Thu, May 31, 2012 at 08:26:58PM +, Duncan wrote:
>> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
>>
>> I don't know what's going to happen to all the overlays with the main
>> tree switch to gi
Hi!
Check kde overlay ;) we used signed commits here
Rich Freeman писал 2012-06-01 16:42:
On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric
wrote:
Nope, at least not as far as I can tell, and I just implemented
commit
signature verification >_>
I've been trying to find an example of a signed
On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric wrote:
>
> Nope, at least not as far as I can tell, and I just implemented commit
> signature verification >_>
I've been trying to find an example of a signed commit, but can't find
one anywhere, so it is hard to tell what it is doing without going
thr
On Fri, 1 Jun 2012 23:23:34 +1200
Kent Fredric wrote:
> On 1 June 2012 22:54, Rich Freeman wrote:
> > Rebasing re-applies the same diff to the new head to give you a new
> > set of commits. When you apply the same diff to a different parent
> > you end up with a different tree, so the tree sign
It looks to me (from looking at eshowkw for python packages quite a
bit) that a great many packages aren't being keyworded on m68k. Would
it perhaps make sense to drop it from the set of stable arches (for
example, in the bugzilla selection thing, or in eshowkw)?
Cheers,
Dirkjan
On 1 June 2012 22:54, Rich Freeman wrote:
> On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric wrote:
>>
>> Hmm, thats annoying. Almost makes me wish it was the trees that were
>> signed, not the commits.
>
> I think it is the tree that is signed, but that changes too.
Nope, at least not as far as I
On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric wrote:
>
> Hmm, thats annoying. Almost makes me wish it was the trees that were
> signed, not the commits.
I think it is the tree that is signed, but that changes too.
Rebasing re-applies the same diff to the new head to give you a new
set of commits
On Fri, Jun 1, 2012 at 12:05 AM, Michał Górny wrote:
> Yes, it isn't but such kind of work flow was presented in the message I
> replied to.
Yup, I wasn't aware that when rebasing you have the option to squash
commits or not. They all get rewritten as if they were applied to the
current head in
# Samuli Suominen (01 Jun 2012)
# Fails to run with font issues wrt bug 418259
# Last release was back in 2003
# Removal in 30 days
x11-terms/cxterm
On 1 June 2012 20:16, Dirkjan Ochtman wrote:
> Can you elaborate on why the cleaner history a no-merge policy
> enforces is a good thing? I actually think that seeing merge commits
> might clarify the history; it can be valuable to see that some mistake
> was made in a merge instead, but you can o
On Thu, May 31, 2012 at 6:49 PM, Robin H. Johnson wrote:
> Discussion on merge policy. Originally I thought we would disallow merge
> commits, so that we would get a cleaner history. However, it turns out that if
> the repo ends up being pushed to different places with slightly different
> histori
48 matches
Mail list logo
