On 25 May 2012 18:16, Grant wrote:
>
> That did it, but there's more trouble. g-cpan strikes again?
>
Configuring source in
/var/tmp/portage/dev-perl/local-lib-1.008004/work/local-lib-1.008004 ...
For local-lib, you're best trying using the copy in the
perl-experimental overlay. If
On 25 May 2012 18:12, Ulrich Mueller wrote:
>
> Actually, Alec's question is not so far-fetched. The Gentoo Social
> Contract says that Gentoo will never depend upon a piece of software
> unless it is open source.
>
Though in the case of github, gentoo is not "depending upon it".
Github could die
> add this:
>
> MODULE_VERSION="v${PV}"
>
> just before the inherit line and that *should* do the trick.
That did it, but there's more trouble. g-cpan strikes again?
>>> Configuring source in
>>> /var/tmp/portage/dev-perl/local-lib-1.008004/work/local-lib-1.008004 ...
* Using ExtUtils::MakeMak
> On Fri, 25 May 2012, Kent Fredric wrote:
> On 25 May 2012 13:21, Alec Warner wrote:
>>
>> So I'm a bit confused. Is GitHub open source?
> Your confusion begets more confusion:
> Whether or not Github is open-source seems orthogonal to whether or
> not we use it, as github is a website, a
On Thu, 24 May 2012 21:47:23 -0600
Ryan Hill wrote:
> Is there any sane way to handle sub-eclasses? eg. foo-base inherits
> foo-functions.
Oh and even if there isn't, big +1 from me.
--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org
signature.asc
Description: PGP signature
On Thu, 24 May 2012 15:47:09 -0400
Mike Frysinger wrote:
> i implemented eclass checking for some of the most common ones in the tree,
> but Zac didn't particularly care for the maintaining of lists of functions
> used by eclasses directly in repoman (due to the concern of them getting out
> o
On Thu, 24 May 2012 14:02:05 +0100
Ciaran McCreesh wrote:
> On Thu, 24 May 2012 00:02:37 -0600
> Ryan Hill wrote:
> > I don't see how removing an inherit is breaking an eclass' API.
>
> The way eclasses are defined, the eclasses it inherits are itself part
> of its API. You can think of it usin
On Fri, May 25, 2012 at 1:01 AM, Dan Douglas wrote:
> This reminds me of Linus' old Google talk on Git in which He said something
I have to ask: was the pronoun capitalization intentional?
> along the lines of: "Many companies using Git internally don't know they're
> using git - they're using i
On 25 May 2012 13:21, Alec Warner wrote:
>
> So I'm a bit confused. Is GitHub open source?
>
Your confusion begets more confusion:
Whether or not Github is open-source seems orthogonal to whether or
not we use it, as github is a website, a service, and there are a few
such websites, of which, git
On Thu, May 24, 2012 at 5:32 PM, Rich Freeman wrote:
> On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser wrote:
>> Can we keep the master on Gentoo hardware please.
>>
>> Also, there still should be a bug at b.g.o and git format-patch works
>> just fine for that. Maybe it's only github now but h
On Thu, May 24, 2012 at 6:01 PM, Dan Douglas wrote:
> But ok it's a good point. Github isn't a good central point of contact. People
> have to use their discression. It's just uncommon these days for a project as
> big as Gentoo to have ultra-centralized corporate-style procedures where
> everythi
On Thursday 24 May 2012 18:16:23 Steven J Long wrote:
> You could maybe tighten the false-negative side by scanning all functions
> defined in an eclass, and warning if they're undocumented.
that happens now when you emerge eclass-manpages, but i suspect no one cares.
if you run the script by ha
Mike Frysinger wrote:
> ..the proposal is to utilize the existing eclass documentation markers
> ..the metadata stays current, and we can scale better to all eclasses
> if people don't properly document their eclasses, repoman might throw
> false positives (warnings, not errors) about unused eclas
On Thursday, May 24, 2012 05:00:49 PM Aaron W. Swenson wrote:
> This gets us into another topic altogether.
>
> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzi
Kent Fredric писал 2012-05-25 01:20:
On 25 May 2012 09:14, Alexey Shvetsov wrote:
In gentoo git tree all git commits will be signed by commiter gpg
keys (and
this will be requerd!)
Aaron W. Swenson писал 2012-05-25 00:00:
Something that still confuses me about commit signing that I haven't
On 25 May 2012 09:14, Alexey Shvetsov wrote:
> In gentoo git tree all git commits will be signed by commiter gpg keys (and
> this will be requerd!)
>
> Aaron W. Swenson писал 2012-05-25 00:00:
Something that still confuses me about commit signing that I haven't
seen answered: How does a signed co
On 25 May 2012 09:00, Aaron W. Swenson wrote:
> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.
+1
>
> If they hap
In gentoo git tree all git commits will be signed by commiter gpg keys
(and this will be requerd!)
Aaron W. Swenson писал 2012-05-25 00:00:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/24/2012 03:57 PM, Dan Douglas wrote:
Git is about decentralized version control. When you clone a r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/24/2012 03:57 PM, Dan Douglas wrote:
> Git is about decentralized version control. When you clone a repo,
> you have your own "fork". When everyone has their own branch,
> everyone is effectively equal. So yes you can expect much much
> more f
On 05/24/2012 01:52 PM, Kent Fredric wrote:
> On 25 May 2012 08:28, Zac Medico wrote:
>>
>> I expect that reading and validating the cache is probably not going to
>> be much faster than just parsing the eclasses over again.
>> --
>
> Unless, you don't care if the cache is out-dated because the c
On 25 May 2012 08:28, Zac Medico wrote:
>
> I expect that reading and validating the cache is probably not going to
> be much faster than just parsing the eclasses over again.
> --
Unless, you don't care if the cache is out-dated because the cache is
optional / the syntax checking is optional, an
On 05/24/2012 01:19 PM, Mike Frysinger wrote:
> On Thursday 24 May 2012 16:12:35 Kent Fredric wrote:
>> Were it me, I'd have a tool that scrapes the eclass files's
>> documentation and emits a .json file which repoman can then optionally
>> use for consistency checks.
>
> python provides its own p
On Thursday 24 May 2012 16:12:35 Kent Fredric wrote:
> Were it me, I'd have a tool that scrapes the eclass files's
> documentation and emits a .json file which repoman can then optionally
> use for consistency checks.
python provides its own pickling system. no need to add yet another layer.
> M
On 25 May 2012 07:47, Mike Frysinger wrote:
> -mike
Were it me, I'd have a tool that scrapes the eclass files's
documentation and emits a .json file which repoman can then optionally
use for consistency checks.
Mostly because I don't like the idea of repoman re-probing all the
eclasses every tim
> On 24/05/12 02:37 PM, Dan Douglas wrote:
> > On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote:
> >
> > Of course it's read only - just like all other public
> > repositories. You don't want to accept improvments? I don't
> > understand this.
>
> I have no problem with accepting imp
Am Mittwoch, 23. Mai 2012, 18:33:41 schrieb Michał Górny:
> On Wed, 23 May 2012 14:42:37 +0200
>
> Michael Weber wrote:
> > *if you still read this* *wow*
> >
> > Please discuss my arguments and come to the conclusions to
> > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> >
i implemented eclass checking for some of the most common ones in the tree,
but Zac didn't particularly care for the maintaining of lists of functions
used by eclasses directly in repoman (due to the concern of them getting out
of sync).
so the proposal is to utilize the existing eclass documen
On Thu, May 24, 2012 at 3:22 PM, Grant wrote:
>>> DateTime-Format-RFC3339
>>
>> Ah. The dreaded v-strings.
>>
>> You'll note: http://cpan.metacpan.org/authors/id/I/IK/IKEGAMI/
>>
>> That there is a "v" before the version specifier in the problem dist,
>> and the portage ebuild has not factored thi
On 25 May 2012 07:22, Grant wrote:
>
> EAPI="2"
>
> MODULE_AUTHOR="IKEGAMI"
>
> inherit perl-module
>
> DESCRIPTION="Parse and format RFC3339 datetime strings"
>
> LICENSE="|| ( Artistic GPL-1 GPL-2 GPL-3 )"
> SLOT="0"
add this:
MODULE_VERSION="v${PV}"
just before the inherit line and that *sho
>> DateTime-Format-RFC3339
>
> Ah. The dreaded v-strings.
>
> You'll note: http://cpan.metacpan.org/authors/id/I/IK/IKEGAMI/
>
> That there is a "v" before the version specifier in the problem dist,
> and the portage ebuild has not factored this into the equation, and is
> looking for DateTime-Form
On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote:
> On 24/05/12 01:13 PM, Kent Fredric wrote:
> > On 25 May 2012 03:02, Ralph Sennhauser wrote:
> >> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
> >>
> >> wrote:
> >>> d) Talk with github folks to add our repo as 'mirror'.
> >>
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/24/2012 06:52 PM, Ian Stakenvicius wrote:
> On 24/05/12 01:13 PM, Kent Fredric wrote:
>> On 25 May 2012 03:02, Ralph Sennhauser wrote:
>>> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
>>> wrote:
>>>
d) Talk with github folks to add
>
>
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do?? I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,
> otherwise we're going to have a rather large mess on our hands
> (multiple fork
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 24 May 2012 13:52:32 -0400
Ian Stakenvicius wrote:
> > When the user has their tree up to how they want it, they can
> > either send a pull request to another gentoo dev who also has a
> > fork on github, or send a link to the commit via some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24/05/12 01:13 PM, Kent Fredric wrote:
> On 25 May 2012 03:02, Ralph Sennhauser wrote:
>> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
>> wrote:
>>
>>> d) Talk with github folks to add our repo as 'mirror'.
>>
>> Can we keep the master on G
On 25 May 2012 03:05, Grant wrote:
> DateTime-Format-RFC3339
Ah. The dreaded v-strings.
You'll note: http://cpan.metacpan.org/authors/id/I/IK/IKEGAMI/
That there is a "v" before the version specifier in the problem dist,
and the portage ebuild has not factored this into the equation, and is
loo
On 25 May 2012 03:02, Ralph Sennhauser wrote:
> On Thu, 24 May 2012 16:40:02 +0200
> Michał Górny wrote:
>
>> d) Talk with github folks to add our repo as 'mirror'.
>
> Can we keep the master on Gentoo hardware please.
Definitely. But having a mirror on github will increase forkability,
and wil
On 24/05/2012 03:19, Mark Wright wrote:
> Michael Weber writes:
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all
On Thu, 24 May 2012 17:02:24 +0200
Ralph Sennhauser wrote:
> On Thu, 24 May 2012 16:40:02 +0200
> Michał Górny wrote:
>
> > d) Talk with github folks to add our repo as 'mirror'.
>
> Can we keep the master on Gentoo hardware please.
Yes, that's the intent. I'm just saying that github seems to
On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser wrote:
> Can we keep the master on Gentoo hardware please.
>
> Also, there still should be a bug at b.g.o and git format-patch works
> just fine for that. Maybe it's only github now but how many places is a
> developer supposed to monitor?
I'm ac
> Verifying ebuild manifests
>> !!! A file is not listed in the Manifest:
>> '/usr/local/portage/dev-perl/DateTime-Format-RFC3339/DateTime-Format-RFC3339-1.0.5.ebuild'
>> !!! A file is not listed in the Manifest:
>> '/usr/local/portage/dev-perl/DateTime-Format-Atom/DateTime-Format-Atom-1.0.2.eb
On Thu, 24 May 2012 16:40:02 +0200
Michał Górny wrote:
> d) Talk with github folks to add our repo as 'mirror'.
Can we keep the master on Gentoo hardware please.
Also, there still should be a bug at b.g.o and git format-patch works
just fine for that. Maybe it's only github now but how many pla
On Thu, 24 May 2012 22:17:20 +1200
Kent Fredric wrote:
> On 24 May 2012 09:48, Michael Weber wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On 05/23/2012 11:14 PM, Dan Douglas wrote:
> >> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
> >>> 2. rsync genera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/24/2012 03:37 PM, Kent Fredric wrote:
Kent, this is of topic, stop it.
- --
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4E
On 25 May 2012 00:05, Dirkjan Ochtman wrote:
> On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> In that regard, git is nothing like for instance svn, where branches come
>> at a much higher cost, as does merging between them.
>
> That's wrong. SVN branches are just about as
On Thu, 24 May 2012 14:05:50 +0200
Dirkjan Ochtman wrote:
> On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> > In that regard, git is nothing like for instance svn, where
> > branches come at a much higher cost, as does merging between them.
>
> That's wrong. SVN branches a
On Thu, 24 May 2012 00:02:37 -0600
Ryan Hill wrote:
> I don't see how removing an inherit is breaking an eclass' API.
The way eclasses are defined, the eclasses it inherits are itself part
of its API. You can think of it using the lousy OO analogy that gave
eclasses their name: the (public) super
On 21 May 2012 04:26, Michał Górny wrote:
> Hello,
>
> In today's MythBusters™: do we actually need the whole ugly-awful
> mangling games.eclass does for games? By that I mean:
> - installing games in random pre-/postfixes rather than standard FHS-y
> locations,
> - changing ownership and permiss
On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> In that regard, git is nothing like for instance svn, where branches come
> at a much higher cost, as does merging between them.
That's wrong. SVN branches are just about as cheap as git branches,
although merges used to be mu
cvs remove -f eclass/ChangeLog? :-)
On 05/24/2012 02:19 PM, Alexis Ballier (aballier) wrote:
aballier12/05/24 11:19:53
Modified: freebsd.eclass
Log:
Typo in comment
Revision ChangesPath
1.23 eclass/freebsd.eclass
file :
http://sources.gentoo.org/
Dan Douglas posted on Thu, 24 May 2012 01:51:28 -0500 as excerpted:
> I don't think doing a branch of the entire tree is a good idea (well
> maybe...). I was thinking more along the lines of subtree merges into a
> local overlay, or perhaps submodules. To do that currently (I think)
> would requir
# Kacper Kowalik (24 May 2012)
# Masked for removal in 30 days (#324415), Doesn't build with
# libtool-2.2 (#276194), bundles vulnerable copy of libtool (#297648),
# fails to install with new coreutils and automake-1.11 (#328549),
# last release 2007-02-14, doesn't provide MPI-2
# Superseeded by s
On 24 May 2012 19:01, Grant wrote:
> I've never had very good luck with g-cpan. I thought there were a lot
> of dev-perl ebuilds in portage for CPAN modules and that g-cpan was
> for those that hadn't been added to portage yet?
Yes, to an extent. Also, if you haven't already, check out the
perl-
On 24 May 2012 19:01, Grant wrote:
Verifying ebuild manifests
> !!! A file is not listed in the Manifest:
> '/usr/local/portage/dev-perl/DateTime-Format-RFC3339/DateTime-Format-RFC3339-1.0.5.ebuild'
> !!! A file is not listed in the Manifest:
> '/usr/local/portage/dev-perl/DateTime-Format-Ato
On 24 May 2012 09:48, Michael Weber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/23/2012 11:14 PM, Dan Douglas wrote:
>> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
>>> 2. rsync generation is NOT going away. Users will still be using
>>> it.
>
> First, I'
Kent Fredric писал 2012-05-24 13:02:
On 24 May 2012 05:35, Alexey Shvetsov wrote:
Full clone will be about 1G or so but no more then 2. If we will
drop
changelog it will be much smaller
And if you use git commit signing instead of ebuild manifests,
intra-commit churn will almost be negligib
On 24 May 2012 08:32, Rich Freeman wrote:
>
> Sure. The slow commit rate encourages careful deliberation before
> hitting the enter key, which therefore improves quality.
>
> Then, if you do make a mistake the slow commit rate means that fixing
> that mistake can take a long time, which increases
On 24 May 2012 05:35, Alexey Shvetsov wrote:
> Full clone will be about 1G or so but no more then 2. If we will drop
> changelog it will be much smaller
>
And if you use git commit signing instead of ebuild manifests,
intra-commit churn will almost be negligible. :D
--
Kent
perl -e "print su
2012/5/24 Dan Douglas
> On Thursday, May 24, 2012 06:33:53 AM Duncan wrote:
> > Dan Douglas posted on Thu, 24 May 2012 01:04:48 -0500 as excerpted:
> > > On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
> > >> On Wed, 23 May 2012 16:14:53 -0500
> > >>
> > >> Dan Douglas wrote:
> > >> >
>> Thanks, I gave that a try and it did a bunch of stuff but when I try
>> to emerge Net-Braintree I get:
> that's weird. it did generate all of them fine here
> which version of g-cpan?
I've tried with g-cpan-0.16.2 and 0.16.4 with the same results:
>>> Verifying ebuild manifests
!!! A file is n
60 matches
Mail list logo
