On Mon, 21 May 2012 21:04:44 +0200
Pacho Ramos pa...@gentoo.org wrote:
Looks like ebuilds not inheriting eutils directly even using epatch are
a lot as I have seen running:
grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
eutils
Maybe they should be checked and a repoman
On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
On Wed, 23 May 2012 16:14:53 -0500
Dan Douglas orm...@gmail.com wrote:
If not I will be leaving Gentoo for Funtoo in the near future, though
there are disadvantages to doing this I don't look forward to dealing
with.
Most of us
On 05/23/2012 11:11 PM, Ryan Hill wrote:
On Mon, 21 May 2012 21:04:44 +0200
Pacho Ramos pa...@gentoo.org wrote:
Looks like ebuilds not inheriting eutils directly even using epatch are
a lot as I have seen running:
grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
eutils
On Wed, 23 May 2012 23:09:14 -0700
Zac Medico zmed...@gentoo.org wrote:
On 05/23/2012 11:11 PM, Ryan Hill wrote:
On Mon, 21 May 2012 21:04:44 +0200
Pacho Ramos pa...@gentoo.org wrote:
Looks like ebuilds not inheriting eutils directly even using epatch are
a lot as I have seen running:
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 orm...@gmail.com wrote:
If not I will be leaving Gentoo for Funtoo in the near future, though
there are
El mié, 23-05-2012 a las 17:00 -0300, Ezequiel Garcia escribió:
On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan ford_pref...@gentoo.org
wrote:
I, for one, think we should stay with CVS and leave all this git
Linusware to the new-fangled Fedora kids with their fancy init systems
and tight
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 orm...@gmail.com wrote:
If not I will be leaving Gentoo for
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 not
2012/5/24 Dan Douglas orm...@gmail.com
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 orm...@gmail.com
On 24 May 2012 05:35, Alexey Shvetsov ale...@gentoo.org 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
On 24 May 2012 08:32, Rich Freeman ri...@gentoo.org 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,
Kent Fredric писал 2012-05-24 13:02:
On 24 May 2012 05:35, Alexey Shvetsov ale...@gentoo.org 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
On 24 May 2012 09:48, Michael Weber x...@gentoo.org 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,
On 24 May 2012 19:01, Grant emailgr...@gmail.com 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:
On 24 May 2012 19:01, Grant emailgr...@gmail.com 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,
# Kacper Kowalik xarthis...@gentoo.org (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
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 require
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 :
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 much
On 21 May 2012 04:26, Michał Górny mgo...@gentoo.org 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
On Thu, 24 May 2012 00:02:37 -0600
Ryan Hill dirtye...@gentoo.org 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
On Thu, 24 May 2012 14:05:50 +0200
Dirkjan Ochtman d...@gentoo.org 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
On 25 May 2012 00:05, Dirkjan Ochtman d...@gentoo.org 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
-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/
On Thu, 24 May 2012 22:17:20 +1200
Kent Fredric kentfred...@gmail.com wrote:
On 24 May 2012 09:48, Michael Weber x...@gentoo.org 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
On Thu, 24 May 2012 16:40:02 +0200
Michał Górny mgo...@gentoo.org 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
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.ebuild'
Why
On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser s...@gentoo.org 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
On Thu, 24 May 2012 17:02:24 +0200
Ralph Sennhauser s...@gentoo.org wrote:
On Thu, 24 May 2012 16:40:02 +0200
Michał Górny mgo...@gentoo.org 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
On 24/05/2012 03:19, Mark Wright wrote:
Michael Weber x...@gentoo.org 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
On 25 May 2012 03:02, Ralph Sennhauser s...@gentoo.org wrote:
On Thu, 24 May 2012 16:40:02 +0200
Michał Górny mgo...@gentoo.org 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
On 25 May 2012 03:05, Grant emailgr...@gmail.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24/05/12 01:13 PM, Kent Fredric wrote:
On 25 May 2012 03:02, Ralph Sennhauser s...@gentoo.org wrote:
On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
mgo...@gentoo.org wrote:
d) Talk with github folks to add our repo as 'mirror'.
Can we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 24 May 2012 13:52:32 -0400
Ian Stakenvicius a...@gentoo.org 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
...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 forks of
-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 s...@gentoo.org wrote:
On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
mgo...@gentoo.org wrote:
d) Talk with
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 s...@gentoo.org wrote:
On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
mgo...@gentoo.org wrote:
d) Talk with github folks to add our repo as
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
On 25 May 2012 07:22, Grant emailgr...@gmail.com 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
On Thu, May 24, 2012 at 3:22 PM, Grant emailgr...@gmail.com 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
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
Am Mittwoch, 23. Mai 2012, 18:33:41 schrieb Michał Górny:
On Wed, 23 May 2012 14:42:37 +0200
Michael Weber x...@gentoo.org 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
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 improvements,
On 25 May 2012 07:47, Mike Frysinger vap...@gentoo.org 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
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.
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 pickling
On 25 May 2012 08:28, Zac Medico zmed...@gentoo.org 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
On 05/24/2012 01:52 PM, Kent Fredric wrote:
On 25 May 2012 08:28, Zac Medico zmed...@gentoo.org 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
-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
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
On 25 May 2012 09:00, Aaron W. Swenson titanof...@gentoo.org 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.
On 25 May 2012 09:14, Alexey Shvetsov ale...@gentoo.org 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
Kent Fredric писал 2012-05-25 01:20:
On 25 May 2012 09:14, Alexey Shvetsov ale...@gentoo.org 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
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 Bugzilla.
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 eclasses
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
On Thu, May 24, 2012 at 6:01 PM, Dan Douglas orm...@gmail.com 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
On Thu, May 24, 2012 at 5:32 PM, Rich Freeman ri...@gentoo.org wrote:
On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser s...@gentoo.org 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
On 25 May 2012 13:21, Alec Warner anta...@gentoo.org 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
On Fri, May 25, 2012 at 1:01 AM, Dan Douglas orm...@gmail.com 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 -
On Thu, 24 May 2012 14:02:05 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Thu, 24 May 2012 00:02:37 -0600
Ryan Hill dirtye...@gentoo.org wrote:
I don't see how removing an inherit is breaking an eclass' API.
The way eclasses are defined, the eclasses it inherits are
On Thu, 24 May 2012 15:47:09 -0400
Mike Frysinger vap...@gentoo.org 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
On Thu, 24 May 2012 21:47:23 -0600
Ryan Hill dirtye...@gentoo.org 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
On Thursday 24 May 2012 00:19:45 Zac Medico wrote:
On 05/23/2012 09:06 PM, Mike Frysinger wrote:
Sometimes people wrap long lines in their ebuilds to make it easier to
read, but this causes us issues when doing line-by-line checking. So
automatically unroll those lines before passing the
Rather than copying pasting the same behavior for the different eclass
checks, add a common class for them to extend. This makes adding more
eclass checks trivial, and keeps down bitrot.
This does abuse the checking interface slightly -- the eclass will change
its category between unused and
On 05/24/2012 12:20 PM, Mike Frysinger wrote:
+ # A normal line will end in the two bytes: \ \n.
So decoding
+ # that will result in python thinking the \n is being
escaped
+ # and eat the single \ which makes it hard for us to
On 05/24/2012 12:20 PM, Mike Frysinger wrote:
Rather than copying pasting the same behavior for the different eclass
checks, add a common class for them to extend. This makes adding more
eclass checks trivial, and keeps down bitrot.
This does abuse the checking interface slightly -- the
On 05/24/2012 12:52 PM, Zac Medico wrote:
On 05/24/2012 12:20 PM, Mike Frysinger wrote:
+# A normal line will end in the two bytes: \ \n.
So decoding
+# that will result in python thinking the \n is being
escaped
+# and eat the
Sometimes people wrap long lines in their ebuilds to make it easier to
read, but this causes us issues when doing line-by-line checking. So
automatically unroll those lines before passing the full content down
to our checkers.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v3
- use
69 matches
Mail list logo
