Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
>> 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 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' I've tried several times with some config variations but always with the above error when trying to emerge. >> I noticed that g-cpan put all of the ebuilds it generated in: >> /var/lib/layman/moonrise/perl-gcpan >> Is that the right place for them? > the default is the last overlay in your config. i suggest looking at the > docs and forcing it to your own overlay, and forcing category to > dev-perl. I've done that but with the above results: GCPAN_OVERLAY="/usr/local/portage" GCPAN_CAT="dev-perl" 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? - Grant
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
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: > > >> > 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 will probably be doing that :P. > > > > > > Eh sorry that wasn't meant to be antagonistic. I'll still have Gentoo > > > boxen to deal with. I just need to be able to use git on the tree (even > > > without the full history is perfectly fine) to ease the difficulty of > > > local overlay management. Glad to hear that will be possible, or at > > > least somewhat easier. > > > > FWIW, I as a user would sure like a git-based tree. Doing git > whatchanged > > searches on individual files and being able to track my last checkout and > > roll back to it, or to a point between it and current HEAD, are extremely > > useful. I haven't thought of it much until now, but I think maintaining > > overlays as simple branches would be great, as well. > > 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 > taking the rsync tree and putting that into a repo, and trying to keep it > synchronized. Plus in the process you lose all correspondance with upstream > commits so that logs and diffs become meaningless. > -- > Dan Douglas git++ -- Vítor Brandão (noisebleed)
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 the amount of pain > our end-users run into due to the mistake, which leads to lots of > flame wars on -dev. That means that the guy who made the mistake is > subjected to more public ridicule, and is less likely to do it again, > That improves quality too. > > Since cvs doesn't tie together tree-wide changes in a nice way or > allow them to be transactionally completed, individual package > maintainers don't need to be as concerned with the big picture view. > Now as the maintainer of libfoo the fact that somebody changed my > ebuild without making a corresponding change in some profile is > completely hidden from me, and I can go to sleep peacefully without > realizing that my users are all going to have horribly broken systems > in the morning. Blissful ignorance of end-user suffering improves > developer morale, and helps get rid of pesky users at the same time. > > cvs also makes more more aware of what is going on around me. Anytime > I want to work on something in parallel with the main development > branch I get to manually merge changes in, which keeps me aware of my > place in the world. That means that I'm less likely to build nice new > features, which means fewer bugs, which improves quality, and may even > drive away users as an added bonus! > > See, cvs is really the wave of the future! > > Rich > This CVS stuff sounds a bit too uppity and unstable to me, sounds like we should go back to the tried and true code collaboration by date-stamped tarballs of the tree which are centralised once a week to a master tarball. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 negligible. :D Yep. Each signature to manifest adds ~512B of echanged data. And this will be added every commit. Also Manifest contain checksumms for all filesincluding ebuild, patches, metadata and so on. thin-manifests will contain only DIST data so they will be much smaller -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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'd stick with the current rsync to spread the tree (mirror > work and mirrors+regular rsync users shouldn't notice any backend > switch at all). > > >> Would users have a way of gaining read-only access? This would be >> EXTREMELY helpful. > Sure, this would be possible like any other git checkout > (layman-git-overlays, github.com, etc.). > > Please compare (browsing source and access description) > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ > http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git > > > - -- > Gentoo Dev > http://xmw.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW > xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh > =dvFZ > -END PGP SIGNATURE- > I think there should most definitely be an official github mirror of the main tree, just a "read-only" mirror from githubs perspective. Just how to best do the mirroring is the question a) Replicate to github when a user does 'push' with a server-side push hook? ( Downside: if github goes down, gentoo devs will see it when they push, and pushing takes longer because the output from the replicated push is delivered to the original dev ) b) Daemonized hook that monitors for changes in the master repo, and replicates commits to github after each push c) Tie it with the rsync tree building system so every time the tree is built for rsync clients, the master is replicated to github. Also, this should obviously be force-pushed, so any branch rebases on the master repo are replicated to the github mirror properly. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
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-Atom/DateTime-Format-Atom-1.0.2.ebuild' Why this is occuring is strange. For each module it complains is "not in the manifest", cd $packagedir repoman manifest ie: cd /usr/local/portage/dev-perl/DateTime-Format-RFC3339/ repoman manifest This should a ) Re-attempt downloading the source tar.gz from cpan if its not already downloaded b ) update the Manifest file for both the source tar.gz and the problematic ebuild. if something goes wrong while doing repoman manifest, then please report that error. ( g-cpan should do this any-way, but seeing why repoman manifest fails, if it fails, should help diagnose the issue ) -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
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-experiemental overlay, which has a much, much larger collection of Perl Module ebuilds. Its not as well maintained as the main tree, but its not bad IMO* you might get lucky and somebody might put it in the tree for you if g-cpan doesn't want to work. * biased, I do a large amount of that =p -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
[gentoo-dev] Lastrites: sys-cluster/lam-mpi
# 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 sys-cluster/{openmpi,mpich2}
sys-cluster/lam-mpi
Took long enough to kill that one...
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
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 taking the rsync tree and putting that into a repo, and > trying to keep it synchronized. Plus in the process you lose all > correspondance with upstream commits so that logs and diffs become > meaningless. The thing about git branches is that they cost almost nothing. If the whole main tree is a single git tree, and you already have that available, maintaining a branch consisting of what we now call an overlay is trivial, compared to simply maintaining the separate files, as is normally done now. In that regard, git is nothing like for instance svn, where branches come at a much higher cost, as does merging between them. (CVS... I don't actually know enough about to make an informed comparison. It'd be a real shame not to expose the read-only git tree to the users who want it. Git was /designed/ to be distributed in that manner. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: freebsd.eclass
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/viewvc.cgi/gentoo-x86/eclass/freebsd.eclass?rev=1.23&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/freebsd.eclass?rev=1.23&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/freebsd.eclass?r1=1.22&r2=1.23
Index: freebsd.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/freebsd.eclass,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- freebsd.eclass 24 May 2012 11:18:46 - 1.22
+++ freebsd.eclass 24 May 2012 11:19:53 - 1.23
@@ -1,6 +1,6 @@
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/freebsd.eclass,v 1.22 2012/05/24
11:18:46 aballier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/freebsd.eclass,v 1.23 2012/05/24
11:19:53 aballier Exp $
#
# Diego Pettenò
@@ -111,7 +111,7 @@
[[ -z "${BMAKE}" ]]&& BMAKE="$(freebsd_get_bmake)"
# Create objdir if MAKEOBJDIRPREFIX is defined, so that we can make out
of
- # tree buils easily.
+ # tree builds easily.
if [[ -n "${MAKEOBJDIRPREFIX}" ]] ; then
mkmake obj || die
fi
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
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 more painful. I'm not sure how good merging in recent SVN is. Let's please stay a little on-topic? The migration will get there much faster if we don't succumb to feature creep. Cheers, Dirkjan
Re: [gentoo-dev] Do we need games group and all that game prefixes?
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 permissions of all the files. > > Do we really need all of this poor man's 'you shall not play our > games'? I don't think we're using anything like /usr/office & office > group, or /usr/random-programs-i-dont-like. > > Random obscurity only makes things harder. And proves no point unless > we're going to ensure that all web browsers, ssh clients and other > applications in danger of being used to play games. And while we're at > it, why don't we just take the computer away and work on paper sheets? > Oh wait, someone could play tic-tac-toe on it... > > So, my proposition is: finally drop that. Install games in regular > prefixes, like all other apps. Don't pollute systems with unnecessary > security perimeters which don't provide any real benefit. > > Any comments? > It wouldn't be so bad if it was done once, in one module, perhaps "games-env" or similar and all games depended on that, instead of the current scenario, where each and every games package does magic to set up the right env bits. ( including creating profiles/groups if they don't already exist, and stuffing paths in $PATH for all users even if they're not in the games group, which causes bugs with git ... ) https://bugs.gentoo.org/show_bug.cgi?id=408615 -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
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) superclasses of a class are part of its API. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
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 are just about as cheap as git branches, [citation needed] -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
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 cheap as git branches, > although merges used to be much more painful. I'm not sure how good > merging in recent SVN is. Cheapness ... maybe in binary disk utilization ( need an actual comparison here I think ), but in cognitive overheads, I'd argue git's branching system is definitely cheaper. Going from Git back to SVN, the mentality of "copy a directory and you have a new branch!!!" seems a bit crazy. And switching between branches in-place at a fixed disk location is definitely cheaper ( mentally at least ) than SVN. I hope I never have to use svn switch again :/ -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
-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/ iF4EAREIAAYFAk++PO8ACgkQknrdDGLu8JC2cAD/WknV6DJEzYEsuXJD0TuDU99I arDTkrBHNXydYVdaxGoBAJmmVm3o7YWlMAvFBz2Eu4ma/VXEHdqocFwl0NK+FEAh =Esu3 -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 generation is NOT going away. Users will still be using > >>> it. > > > > First, I'd stick with the current rsync to spread the tree (mirror > > work and mirrors+regular rsync users shouldn't notice any backend > > switch at all). > > > > > >> Would users have a way of gaining read-only access? This would be > >> EXTREMELY helpful. > > Sure, this would be possible like any other git checkout > > (layman-git-overlays, github.com, etc.). > > > > Please compare (browsing source and access description) > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ > > http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git > > > > > > - -- > > Gentoo Dev > > http://xmw.de/ > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2.0.17 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW > > xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh > > =dvFZ > > -END PGP SIGNATURE- > > > > > I think there should most definitely be an official github mirror of > the main tree, just a "read-only" mirror from githubs perspective. > > Just how to best do the mirroring is the question > > a) Replicate to github when a user does 'push' with a server-side > push hook? ( Downside: if github goes down, gentoo devs will see it > when they push, and pushing takes longer because the output from the > replicated push is delivered to the original dev ) > > b) Daemonized hook that monitors for changes in the master repo, and > replicates commits to github after each push > > c) Tie it with the rsync tree building system so every time the tree > is built for rsync clients, the master is replicated to github. d) Talk with github folks to add our repo as 'mirror'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 places is a developer supposed to monitor? signature.asc Description: PGP signature
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
> 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 this is occuring is strange. > > For each module it complains is "not in the manifest", > > cd $packagedir > repoman manifest > > ie: > > cd /usr/local/portage/dev-perl/DateTime-Format-RFC3339/ > repoman manifest > > This should > > a ) Re-attempt downloading the source tar.gz from cpan if its not > already downloaded > b ) update the Manifest file for both the source tar.gz and the > problematic ebuild. > > if something goes wrong while doing repoman manifest, then please > report that error. > > ( g-cpan should do this any-way, but seeing why repoman manifest > fails, if it fails, should help diagnose the issue ) Here is the repoman failure and DateTime-Format-Atom does the same thing: # repoman manifest >>> Downloading >>> 'http://distfiles.gentoo.org/distfiles/DateTime-Format-RFC3339-1.0.5.tar.gz' --2012-05-24 08:01:06-- http://distfiles.gentoo.org/distfiles/DateTime-Format-RFC3339-1.0.5.tar.gz Resolving distfiles.gentoo.org... 156.56.247.195, 216.165.129.135, 64.50.233.100, ... Connecting to distfiles.gentoo.org|156.56.247.195|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2012-05-24 08:01:06 ERROR 404: Not Found. >>> Downloading >>> 'http://www.cpan.org/authors/id/I/IK/IKEGAMI/DateTime-Format-RFC3339-1.0.5.tar.gz' --2012-05-24 08:01:06-- http://www.cpan.org/authors/id/I/IK/IKEGAMI/DateTime-Format-RFC3339-1.0.5.tar.gz Resolving www.cpan.org... 207.171.7.177, 199.15.176.140 Connecting to www.cpan.org|207.171.7.177|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2012-05-24 08:01:06 ERROR 404: Not Found. >>> Downloading >>> 'http://search.cpan.org/CPAN/authors/id/I/IK/IKEGAMI/DateTime-Format-RFC3339-1.0.5.tar.gz' --2012-05-24 08:01:06-- http://search.cpan.org/CPAN/authors/id/I/IK/IKEGAMI/DateTime-Format-RFC3339-1.0.5.tar.gz Resolving search.cpan.org... 199.15.176.161 Connecting to search.cpan.org|199.15.176.161|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://cpan.knowledgematters.net/authors/id/I/IK/IKEGAMI/DateTime-Format-RFC3339-1.0.5.tar.gz [following] --2012-05-24 08:01:06-- http://cpan.knowledgematters.net/authors/id/I/IK/IKEGAMI/DateTime-Format-RFC3339-1.0.5.tar.gz Resolving cpan.knowledgematters.net... 67.205.61.104 Connecting to cpan.knowledgematters.net|67.205.61.104|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2012-05-24 08:01:06 ERROR 404: Not Found. !!! Couldn't download 'DateTime-Format-RFC3339-1.0.5.tar.gz'. Aborting. * QA Notice: ECLASS 'perl-module' inherited illegally in dev-perl/DateTime-Format-RFC3339-1.0.5 nofetch * QA Notice: ECLASS 'eutils' inherited illegally in dev-perl/DateTime-Format-RFC3339-1.0.5 nofetch * QA Notice: ECLASS 'multilib' inherited illegally in dev-perl/DateTime-Format-RFC3339-1.0.5 nofetch * QA Notice: ECLASS 'toolchain-funcs' inherited illegally in dev-perl/DateTime-Format-RFC3339-1.0.5 nofetch * QA Notice: ECLASS 'multilib' inherited illegally in dev-perl/DateTime-Format-RFC3339-1.0.5 nofetch * QA Notice: ECLASS 'user' inherited illegally in dev-perl/DateTime-Format-RFC3339-1.0.5 nofetch * QA Notice: ECLASS 'base' inherited illegally in dev-perl/DateTime-Format-RFC3339-1.0.5 nofetch * The following are listed in SRC_URI for DateTime-Format-RFC3339: *mirror://cpan/authors/id/I/IK/IKEGAMI/DateTime-Format-RFC3339-1.0.5.tar.gz !!! Fetch failed for DateTime-Format-RFC3339-1.0.5.tar.gz, can't update Manifest Unable to generate manifest. - Grant
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 actually a little torn on this one. I'm fine with keeping the "master" on Gentoo in the sense that this is where the rsync tree gets generated. However, gitbub has a lot of tools like pull requests that could potentially improve workflow, especially for things like proxy maintainers. So, letting those teams work more outside of Gentoo and just push their changes into Gentoo might make sense. Perhaps github should be viewed as a widely-shared overlay that gets automatic updates from the main tree in the master branch (or whatever we call it). You can work on a branch in github, get it where you want it to be, and then push it to Gentoo pretty easily. When I don't have access to an upstream repository I often just push a copy to a fork on Github just to make my own life easier. Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 have a hidden feature of mirroring external repos. https://github.com/mirrors -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 checkout the tree (might be some funny massive load). > > +1 for clean cut to git > clean cut +1
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 will make it much faster for people to get started on contribution. 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 medium ( bug tracker ? ) , and some dev can just add that as a remote, and merge/cherry-pick the commits they want.. In my books, github is mostly a marketing and ease of access platform that streamlines the ability for people to get started contributing and facilitate easy distribution of changes back to upstream. But this is mostly side topic. CLEAN CUT++ If there are problems with it, we can address those when we know what they are, not when we're inventing problems that might not actually exist due to conjecture. I haven't encountered any "real" problems yet in size or performance constraints with perl-experimental . Sure, its not portage, its only ~800 packages vs portages 15000 , but it should be a somewhat reasonable synthetic workload. Side note: I assume, that there is, a way, if you *really* need it, to copy all the new git commits back to the cvs tree if something critically broken in git turns up so bad it has to be dropped. I think it unlikely, but knowing there is a way to "go back" would give much reassurance. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
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
looking for DateTime-Format-RFC3339-1.0.5.tar.gz when it should be
looking for DateTime-Format-RFC3339-v1.0.5.tar.gz
If you can edit the ebuild source to solve this issue, and then re-run
repoman manifest, that might help. But at least we now know what is
happening wrong with g-cpan.
In editing, you'll be wanting to look for varibles ( mostly in SRC_URI
and I think S ) which use "${PV}" and change it to use "v${PV}"
instead.
--
Kent
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-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 Gentoo hardware please. > > Definitely. But having a mirror on github will increase > forkability, and will make it much faster for people to get started > on contribution. > > 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 medium ( bug > tracker ? ) , and some dev can just add that as a remote, and > merge/cherry-pick the commits they want.. > ...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 the main tree != a uniform main tree + overlays, the way it does now) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk++dWAACgkQ2ugaI38ACPBBpAD9EaJsSNXMS6bDbttJStVqghlO Q46xkgPIgunriOLJhDoA/06HH/kgXd/Qrq/Ex0X3kV9nDmYqE0OmiFM1kVTfdVCD =dcOs -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-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 medium ( bug > > tracker ? ) , and some dev can just add that as a remote, and > > merge/cherry-pick the commits they want.. > > ...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 the main tree != a uniform main tree + overlays, > the way it does now) That's only a problem if you don't merge things quickly. Encouraging users to submit git format-patches or merge requests is a great way of reducing developer workload. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk++eQMACgkQ96zL6DUtXhF4kgCfZkdR7RTvUUlFdTgdNkyDHwGK NlgAoKgSUKEWN6WnrihawHkhhrPbJlv2 =8RdD -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
> > > ...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 the main tree != a uniform main tree + overlays, > the way it does now) Yes, we want them to. There is still going to be a "master" authoritative tree, forks of that tree will exist for the purpose of adding new ebuilds to the master tree / bumping existing packages. If your worry is "There are copies of gentoo /usr/portage out there that aren't GIT HEAD" , then stop worrying, as thats already the case. As soon as somebody modifies a file in their local /usr/portage, that happens, and as soon as a users portage tree gets older than 1 hour, that happens. And if your worry is "But they could be replicating it in that form", then don't worry, they could already be doing that, nothing is stopping people from re-providing their full (tweaked) /usr/portage via rsync to others. In fact, if you're running in a network with a network master, you're doing that to an extent. But those sources are not official, and have no utility outside development/private use scenarios, and thus, don't compete with overlays directly. Sure, you *could* make something like an overlay by forking gentoo master and then maintaining that, but it would be impractical, and you'd be better off using a plain overlay ( less noise ), or using that fork for the purpose of getting things in master. You /could/ do a long-lived public maintained fork, and then you'd be Sabyon / Funtoo. Doing this has its own difficulties, but I think long term, enabling this is good: Sabyon/Funtoo can fork gentoo on github, and then any improvements made on their forks, gentoo can easily steal back, and its easier to track the differences between them. Win/Win in my books. Summarised: Yes, its a good idea. No, we shouldn't try stopping them. Actually, really can't stop them, its already happening, Git will just make the workflow better on top of it. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-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 our repo as 'mirror'. >>> >>> Can we keep the master on Gentoo hardware please. > >> Definitely. But having a mirror on github will increase >> forkability, and will make it much faster for people to get >> started on contribution. > >> 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 medium ( >> bug tracker ? ) , and some dev can just add that as a remote, >> and merge/cherry-pick the commits they want.. > > > > ...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 the main tree != a uniform main tree + > overlays, the way it does now) > > Why do you care? If someone uses a forked tree then he and his users are on their own. However, I would like to have the ability to accept pull requests from users and then push my local tree back to the "official" one. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPvn8KAAoJEPqDWhW0r/LCjVMP/jdZ+f96hx3zF25XIfn5xKdg jsPO1kQ7KLMLFg+ZxhDMYo/ORbbOuuqtyBA9pnoDYgSB9xSQ5ETIemsyoL6MHMmj 7DGyUkd0HUFIROjaEDCD0BipPyY5Cpj/D2Ep9br0o4mfXTi2qVg5sE8qVsjguVf5 3tZ1GEm8w4k8UIj39pICX5o9X35nTlG6gkQh2cy6ZO3+MHBmyt3WOzmRczrW4bgX kcMprYYdqoHd/VcC4LJoKMO8ALlX7UdsU2Yoe68ImKvdSdhxdqla9qPqUmf2kqqE DYZoYnu1+NI5CtN2d30Ut0ewUqP/9/kKb0Gx/QKZkD9DR+jAv75O0M/PM3MpVP/P wxUVRzmv48WNXJmahqiv1fiBbWR4Al5KXIfk8g49oPxNjDFb00ij0G0YSxfbvbih kEZl24hiqumO+oLdJOGhQTbeFDDDtnJuT8Ft9914FW77dWt9M/B61udlaS5B4E41 rgP5kHVb3wmbPcS8uc8YklceJfog3FVUzghTzH9swz9umSSmO1B6JGOVKFBuyTCY MNGn9Oz+n/Vklbg63br4AIsyokpTbGx3coeTJzQ3Jry97l5L3+TlJFqk9I644cIs cqsh575aAlHyakvZfWdIgbBschcsRWTRuzaZAeTW4qnMMVhMn19nTkgoSCyu2PEp Qq32ezdYxEpv4a3X40M6 =m1ok -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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'. > >> > >> Can we keep the master on Gentoo hardware please. > > > > Definitely. But having a mirror on github will increase > > forkability, and will make it much faster for people to get started > > on contribution. > > > > 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 medium ( bug > > tracker ? ) , and some dev can just add that as a remote, and > > merge/cherry-pick the commits they want.. > > ...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, Of course it's read only - just like all other public repositories. You don't want to accept improvments? I don't understand this. > otherwise we're going to have a rather large mess on our hands > (multiple forks of the main tree != a uniform main tree + overlays, > the way it does now) Forking happens when it's hard to contribute. You even want to make overlays difficult? The only real mechanism Gentoo provides for user extensibility? -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
>> 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-Format-RFC3339-1.0.5.tar.gz when it should be
> looking for DateTime-Format-RFC3339-v1.0.5.tar.gz
>
> If you can edit the ebuild source to solve this issue, and then re-run
> repoman manifest, that might help. But at least we now know what is
> happening wrong with g-cpan.
>
> In editing, you'll be wanting to look for varibles ( mostly in SRC_URI
> and I think S ) which use "${PV}" and change it to use "v${PV}"
> instead.
These ebuilds don't seem to have any of those variables:
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# This ebuild generated by g-cpan 0.16.4
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"
KEYWORDS="alpha amd64 amd64-fbsd arm hppa ia64 m68k mips ppc ppc64
s390 sh sparc sparc-fbsd x86 x86-fbsd ppc-aix x86-freebsd
x64-freebsd sparc64-freebsd hppa-hpux ia64-hpux x86-interix
amd64-linux arm-linux ia64-linux ppc64-linux x86-linux ppc-macos
x86-macos x64-macos m68k-mint x86-netbsd ppc-openbsd x86-openbsd
x64-openbsd sparc-solaris sparc64-solaris x64-solaris x86-solaris
x86-winnt x86-cygwin"
IUSE=""
DEPEND="dev-perl/DateTime
dev-lang/perl"
- Grant
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
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 *should* do the trick.
--
Kent
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
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 this into the equation, and is
>> looking for DateTime-Format-RFC3339-1.0.5.tar.gz when it should be
>> looking for DateTime-Format-RFC3339-v1.0.5.tar.gz
>>
>> If you can edit the ebuild source to solve this issue, and then re-run
>> repoman manifest, that might help. But at least we now know what is
>> happening wrong with g-cpan.
>>
>> In editing, you'll be wanting to look for varibles ( mostly in SRC_URI
>> and I think S ) which use "${PV}" and change it to use "v${PV}"
>> instead.
>
> These ebuilds don't seem to have any of those variables:
>
> # Copyright 1999-2010 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # This ebuild generated by g-cpan 0.16.4
>
> 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"
> KEYWORDS="alpha amd64 amd64-fbsd arm hppa ia64 m68k mips ppc ppc64
> s390 sh sparc sparc-fbsd x86 x86-fbsd ppc-aix x86-freebsd
> x64-freebsd sparc64-freebsd hppa-hpux ia64-hpux x86-interix
> amd64-linux arm-linux ia64-linux ppc64-linux x86-linux ppc-macos
> x86-macos x64-macos m68k-mint x86-netbsd ppc-openbsd x86-openbsd
> x64-openbsd sparc-solaris sparc64-solaris x64-solaris x86-solaris
> x86-winnt x86-cygwin"
> IUSE=""
>
> DEPEND="dev-perl/DateTime
> dev-lang/perl"
>
> - Grant
>
Hi Grant,
See "inherit perl-module" take a look at /usr/portage/eclass/perl-module.eclass
Regards,
David
[gentoo-dev] comprehensive eclass checking in repoman
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 documentation markers to extract the complete list of functions provided by an eclass. the upside is the metadata stays current, and we can scale better to all eclasses w/out requiring manual intervention. the downside is that if people don't properly document their eclasses, repoman might throw false positives (warnings, not errors) about unused eclasses being inherited, and will miss throwing errors when functions are used but the respective eclasses aren't inherited. however, i think that's a good hammer to throw at eclass maintainers to keep their documentation up-to-date and accurate. any other opinions/feedback ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 > > this bug from the blockers of "[TRACKER] portage migration to git". > > Kill it! And while we're at it, kill ChangeLogs as well! > > /me hides... with "git log some-cat/foo" we will have it automagically. -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
> 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, i'm just leary of > semi-official copies of the tree that could be checked out and checked > into by non-dev's (this said, I don't know that much about git but I > assume that github users could commit to the github copy yes? that > being the way users would contribute?) > >> otherwise we're going to have a rather large mess on our hands > >> (multiple forks of the main tree != a uniform main tree + > >> overlays, the way it does now) > > > > Forking happens when it's hard to contribute. You even want to > > make overlays difficult? The only real mechanism Gentoo provides > > for user extensibility? > > Nono, I was comparing the (from my perspective) mess of multiple forks > of the main tree that hosting on github/other services could > potentially enable, with a single uniform source of the main tree plus > overlays for extended contribution (which is the system we have now). 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 forking. In Git land, forks are good. There's no way to enforce that people only pull from some "official" source. It works out in practice so that 99% of the time people only care about a couple branches of one repository. Counterintuitively, this comes as a side- effect of git actually doing distribution properly and making it easier for everybody's workflow. The overlay model by contrast is quite broken on its own and virtually forces creation of new overlays in order to make changes without the benifits of version control (with regards to the rsync tree at least). What Github does is facilitate making it easy to fork/branch and provide a central way to push changes back into a remote through pull requests. Pull requests and other web services around git hosting are pretty much the thing that makes github worth using. From the standpoint of accepting patches, the differenc e to you is rather than (or in addition to) accepting patches through bugzilla, you can choose to accept a push directly from someone else's copy of the repo. It isn't like a wiki - everybody commits to their own repositories and pushing to a remote is on a whitelist basis just like in centralized version control. Anyway, others are better at "selling" Git than I and there are no shortage of resources out there describing distributed development models. I think this thread is supposed to be about the technical hurdles and it looks like whether or not it's feasible to support github. I can't really comment on the latter. Aside from whatever hoops the Gentoo devs have to jump through in trying to maintain multiple repos, it's hard to see the downsides to using github in and of itself. Talk to the Gentoo Haskell guys, they've been using Github for some time. And if memory serves, KDE used to be on Github or Gitorious before moving to o.g.o -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] comprehensive eclass checking in repoman
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 time you check an ebuild, and would like a way of consistency checking an ebuild and seeing what metadata it produced without needing to see it through the eyes of "repoman full" on a consuming ebuild. My 2c -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] comprehensive eclass checking in repoman
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. > Mostly because I don't like the idea of repoman re-probing all the > eclasses every time you check an ebuild caching of data most likely will be done (the decision will be data driven), but that's independent of the underlying behavioral question. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] comprehensive eclass checking in repoman
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 system. no need to add yet another layer. Python's json module is similar to the pickly module, so you might just use that instead. For example, I've converted /var/cache/edb/mtimedb from pickle to json: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=848da97a64b2d3d13c3fbc794c57dae714009854 >> Mostly because I don't like the idea of repoman re-probing all the >> eclasses every time you check an ebuild > > caching of data most likely will be done (the decision will be data driven), > but that's independent of the underlying behavioral question. I expect that reading and validating the cache is probably not going to be much faster than just parsing the eclasses over again. -- Thanks, Zac
Re: [gentoo-dev] comprehensive eclass checking in repoman
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, and its only made available when you generate it manually. And considering how fast eclasses change, I doubt you'd need to regenerate it often. Though how much time it takes to parse and stuff really needs to be properly benched, its more that there is an intermediate state that can be inspected by human eyes instead of a lot of magic going on -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] comprehensive eclass checking in repoman
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 cache is > optional / the syntax checking is optional, and its only made > available when you generate it manually. Putting the responsibility of cache validation on the user is not really an option here, because it's just going to lead to bug reports of the form "repoman is using stale eclass info in its checks". -- Thanks, Zac
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
-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 forking. In Git land, forks are good. There's no way to > enforce that people only pull from some "official" source. > > It works out in practice so that 99% of the time people only care > about a couple branches of one repository. Counterintuitively, this > comes as a side- effect of git actually doing distribution properly > and making it easier for everybody's workflow. The overlay model by > contrast is quite broken on its own and virtually forces creation > of new overlays in order to make changes without the benifits of > version control (with regards to the rsync tree at least). > > What Github does is facilitate making it easy to fork/branch and > provide a central way to push changes back into a remote through > pull requests. Pull requests and other web services around git > hosting are pretty much the thing that makes github worth using. > From the standpoint of accepting patches, the differenc e to you is > rather than (or in addition to) accepting patches through bugzilla, > you can choose to accept a push directly from someone else's copy > of the repo. It isn't like a wiki - everybody commits to their own > repositories and pushing to a remote is on a whitelist basis just > like in centralized version control. 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. Bugzilla also contains our history. If they happen to be needing to be pulled from github, that's fine. Definitely convenient for the contributor. We'll also need to clearly document how the pull-request is to be generated. (I vote for requiring signed pull-requests. [1]) github should not be our central point of contact. We have b.g.o for that. github should be on the fringes as a tool that we can use if we want to. [1] http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html - - Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ =MVyV -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
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 repo, you have your own "fork". When everyone has their own branch, everyone is effectively equal. So yes you can expect much much more forking. In Git land, forks are good. There's no way to enforce that people only pull from some "official" source. It works out in practice so that 99% of the time people only care about a couple branches of one repository. Counterintuitively, this comes as a side- effect of git actually doing distribution properly and making it easier for everybody's workflow. The overlay model by contrast is quite broken on its own and virtually forces creation of new overlays in order to make changes without the benifits of version control (with regards to the rsync tree at least). What Github does is facilitate making it easy to fork/branch and provide a central way to push changes back into a remote through pull requests. Pull requests and other web services around git hosting are pretty much the thing that makes github worth using. From the standpoint of accepting patches, the differenc e to you is rather than (or in addition to) accepting patches through bugzilla, you can choose to accept a push directly from someone else's copy of the repo. It isn't like a wiki - everybody commits to their own repositories and pushing to a remote is on a whitelist basis just like in centralized version control. 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. Bugzilla also contains our history. If they happen to be needing to be pulled from github, that's fine. Definitely convenient for the contributor. We'll also need to clearly document how the pull-request is to be generated. (I vote for requiring signed pull-requests. [1]) github should not be our central point of contact. We have b.g.o for that. github should be on the fringes as a tool that we can use if we want to. [1] http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html - - Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ =MVyV -END PGP SIGNATURE- -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
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 happen to be needing to be pulled from github, that's fine. > Definitely convenient for the contributor. > > We'll also need to clearly document how the pull-request is to be > generated. (I vote for requiring signed pull-requests. [1]) > > github should not be our central point of contact. We have b.g.o for > that. github should be on the fringes as a tool that we can use if we > want to. > +/-1 : Not sure, for new people, it should definitely be the go-to way to do things. But people who are regular contributors ( which we want to encourage ) will feel slowed down if they have to open a bug report for every change. And I can see github facilitating "proxy maintainers" much better. If a proxy maintainer has another gentoo person who all their changes get proxied through, the proxy maintainer and the gentoo dev could both have forks on github, and the proxy maintainer could send their pull requests to their proxy to vet and merge, somewhat like Linus'es Generals model. > [1] > http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html > > - - Aaron > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d > IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ > =MVyV > -END PGP SIGNATURE- > -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
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 commit work with rebasing? I don't see any flag to allow rebase to sign commits rebased, and rebasing *does* change the commit fundementally in ways I'd expect to void any signature. Sure, you may not want rebasing in the master, but I sure as hell want to use it in a branch. People who maintain a long-parallel-merge history instead of rebasing their branches are on my personal shitlist =p. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
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 seen answered: How does a signed commit work with rebasing? I don't see any flag to allow rebase to sign commits rebased, and rebasing *does* change the commit fundementally in ways I'd expect to void any signature. Sure, you may not want rebasing in the master, but I sure as hell want to use it in a branch. People who maintain a long-parallel-merge history instead of rebasing their branches are on my personal shitlist =p. You can rebase signed commit untill you dont push it to master But yes i'm not sure how it works with signed commits -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
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. Bugzilla also > contains our history. This discussion was sort of in the context of proxy-maintainers. A pull request isn't equivalent to a bump request or entirely overlapping with most bugs that go through bugzilla. A pull request is just "here take my code", or is useful for code revewing just because it integrates with the git workflow. I suppose you would have to define the sorts of things that should go through Bugzilla. I can't imagine it being reasonable to use github for most types of bump requests. > If they happen to be needing to be pulled from github, that's fine. > Definitely convenient for the contributor. > > We'll also need to clearly document how the pull-request is to be > generated. (I vote for requiring signed pull-requests. [1]) > > github should not be our central point of contact. We have b.g.o for > that. github should be on the fringes as a tool that we can use if we > want to. This reminds me of Linus' old Google talk on Git in which He said something along the lines of: "Many companies using Git internally don't know they're using git - they're using it whether they like it or not". There are ALREADY Gentoo projects using github and even pull requests. It doesn't really matter because everything more or less comes back to one point in the end. It's the repo that's the history of the project, not bugzilla. I've "filed" more bugs over IRC and had them fixed in the tree within 60 seconds than I have gone through bugzilla formalisms. FWIW, I think having the entire tree in one big repo is a bad idea to begin with. 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 everything happens exclusively though official channels. And anyway you couldn't "enforce" that sort of thing if you tried. > [1] > http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.h > tml -- Dan Douglas signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: comprehensive eclass checking in repoman
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 > will miss throwing errors when functions are used but the respective > eclasses aren't inherited. > however, i think that's a good hammer to throw at eclass maintainers to > keep their documentation up-to-date and accurate. > any other opinions/feedback? I think it's an excellent idea to give this kind of QA early, to avoid issues like recent eutils inheritance changes in the future; it's not a hammer so much as a helpful reminder, that improves things for everyone. You could maybe tighten the false-negative side by scanning all functions defined in an eclass, and warning if they're undocumented. Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: comprehensive eclass checking in repoman
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 hand on your eclass, it'll tell you the same thing. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
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 > everything happens exclusively though official channels. And anyway you > couldn't > "enforce" that sort of thing if you tried. > ++ There is no policy that every commit in cvs needs to be referenced to a bug, and I doubt we're going to change that. So, if I call up another dev on the phone and tell them they have a typo in an ebuild, and they fix it and commit it, nothing has gone wrong. That isn't the most efficient way to work usually, but there is no policy against it. In general users should file bugs and not contact devs directly, but if somebody has a private arrangement otherwise, no harm no foul. Github is just another overlay. If in the course of working on the next kde release the kde team makes 385 changes to their overlay, we don't make them log and close 385 bugs on b.g.o before they merge in the files from the overlay. So, if a team wants to use non-official tools, by all means go ahead. The QA standards apply to anything hitting the main tree, and must be followed at that point in time. We should keep our tools working well, but if in some case there is a better way of working, or a small team has some other preference, well, have at it! Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 how many places is a >> developer supposed to monitor? > > I'm actually a little torn on this one. I'm fine with keeping the > "master" on Gentoo in the sense that this is where the rsync tree gets > generated. However, gitbub has a lot of tools like pull requests that > could potentially improve workflow, especially for things like proxy > maintainers. So, letting those teams work more outside of Gentoo and > just push their changes into Gentoo might make sense. So I'm a bit confused. Is GitHub open source? > > Perhaps github should be viewed as a widely-shared overlay that gets > automatic updates from the main tree in the master branch (or whatever > we call it). You can work on a branch in github, get it where you > want it to be, and then push it to Gentoo pretty easily. When I don't > have access to an upstream repository I often just push a copy to a > fork on Github just to make my own life easier. > > Rich >
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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, github appears to be the defacto most-popular one. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
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 it whether they like it or not". IIRC, it was about git-svn specifically, although I think you are right: developers will use git and GitHub because they fulfill a need, regardless of policies. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
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 using the lousy OO analogy that gave > eclasses their name: the (public) superclasses of a class are part of > its API. Like I said, technically it is. And that's terrible. Let's ignore it. :D -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: comprehensive eclass checking in repoman
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 > of sync). > > so the proposal is to utilize the existing eclass documentation markers to > extract the complete list of functions provided by an eclass. the upside is > the metadata stays current, and we can scale better to all eclasses w/out > requiring manual intervention. the downside is that if people don't properly > document their eclasses, repoman might throw false positives (warnings, not > errors) about unused eclasses being inherited, and will miss throwing errors > when functions are used but the respective eclasses aren't inherited. > > however, i think that's a good hammer to throw at eclass maintainers to keep > their documentation up-to-date and accurate. any other opinions/feedback ? Is there any sane way to handle sub-eclasses? eg. foo-base inherits foo-functions. I have some crazy ideas on how to do eclass versioning I may one day threaten the world with if they ever let me out of my padded cell. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: comprehensive eclass checking in repoman
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
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
> 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 service, and there are a > few such websites, of which, github appears to be the defacto > most-popular one. 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. Ulrich
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
> 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::MakeMaker
* perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none
DESTDIR=/var/tmp/portage/dev-perl/local-lib-1.008004/image/
ACCESS DENIED open_wr: /usr/lib64/perl5/5.12.4/CPAN/Config.pm
Cannot open >/usr/lib64/perl5/5.12.4/CPAN/Config.pm at
/usr/lib64/perl5/5.12.4/CPAN/HandleConfig.pm line 470
CPAN::HandleConfig::_configpmtest('/usr/lib64/perl5/5.12.4/CPAN',
'/usr/lib64/perl5/5.12.4/CPAN/Config.pm') called at
/usr/lib64/perl5/5.12.4/CPAN/HandleConfig.pm line 551
CPAN::HandleConfig::load('CPAN::HandleConfig') called at
/usr/lib64/perl5/5.12.4/CPAN/Shell.pm line 1517
CPAN::Shell::optprint('CPAN::Shell', 'load_module', 'CPAN:
File::HomeDir loaded ok (v0.98)\x{a}') called at
/usr/lib64/perl5/5.12.4/CPAN.pm line 1101
CPAN::has_inst('CPAN=HASH(0x1e0d4114e8)', 'File::HomeDir', undef)
called at /usr/lib64/perl5/5.12.4/CPAN.pm line 982
CPAN::has_usable('CPAN=HASH(0x1e0d4114e8)', 'File::HomeDir') called
at /usr/lib64/perl5/5.12.4/CPAN/HandleConfig.pm line 506
CPAN::HandleConfig::home() called at
/usr/lib64/perl5/5.12.4/CPAN/HandleConfig.pm line 478
CPAN::HandleConfig::require_myconfig_or_config('CPAN::HandleConfig')
called at Makefile.PL line 212
* ERROR: dev-perl/local-lib-1.008004 failed (configure phase):
* Unable to build!
*
* Call stack:
* ebuild.sh, line 85: Called src_configure
* environment, line 2220: Called perl-module_src_configure
* environment, line 1936: Called perl-module_src_prep
* environment, line 2008: Called die
* The specific snippet of code:
* perl Makefile.PL "$@" <<< "${pm_echovar}" || die
"Unable to build!";
*
* If you need support, post the output of 'emerge --info
=dev-perl/local-lib-1.008004',
* the complete build log and the output of 'emerge -pqv
=dev-perl/local-lib-1.008004'.
* This ebuild is from an overlay named 'x-portage': '/usr/local/portage/'
* The complete build log is located at
'/var/log/portage/dev-perl:local-lib-1.008004:20120525-061124.log'.
* The ebuild environment file is located at
'/var/tmp/portage/dev-perl/local-lib-1.008004/temp/environment'.
* S: '/var/tmp/portage/dev-perl/local-lib-1.008004/work/local-lib-1.008004'
--- ACCESS VIOLATION SUMMARY ---
LOG FILE "/var/log/sandbox/sandbox-10934.log"
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line
F: open_wr
S: deny
P: /usr/lib64/perl5/5.12.4/CPAN/Config.pm
A: /usr/lib64/perl5/5.12.4/CPAN/Config.pm
R: /usr/lib64/perl5/5.12.4/CPAN/Config.pm
C: perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none
DESTDIR=/var/tmp/portage/dev-perl/local-lib-1.008004/image/
>>> Failed to emerge dev-perl/local-lib-1.008004
- Grant
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 in a ball of fire, and it wouldn't change the core development, it would only change the development for the people who elected to use github. Anyone can use any git platform that competes with github, be it bitbucket, gitorious, or a private git server they created. Github is just a convenient go-to service for many. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
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 that doesn't work either, then why the sandbox violation is occurring needs looked at. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
