[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
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 warning should be added when an ebuild is using epatch without inheriting eutils directly, otherwise this problem could reappear if some other eclass no longer inherit it in the future :-/ Maybe we should make eutils inheritance implicit so all ebuilds get epatch and friends automatically. Is there really that much overhead? Or am I missing something obvious? -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 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. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
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 Maybe they should be checked and a repoman warning should be added when an ebuild is using epatch without inheriting eutils directly, otherwise this problem could reappear if some other eclass no longer inherit it in the future :-/ Maybe we should make eutils inheritance implicit so all ebuilds get epatch and friends automatically. Is there really that much overhead? Or am I missing something obvious? Do you mean in EAPI 5? We're already planning to include epatch, as part of the epatch_user thing. -- Thanks, Zac
[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
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: grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v eutils Maybe they should be checked and a repoman warning should be added when an ebuild is using epatch without inheriting eutils directly, otherwise this problem could reappear if some other eclass no longer inherit it in the future :-/ Maybe we should make eutils inheritance implicit so all ebuilds get epatch and friends automatically. Is there really that much overhead? Or am I missing something obvious? Do you mean in EAPI 5? We're already planning to include epatch, as part of the epatch_user thing. I did. That's awesome, thanks. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
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 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. -- 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
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 coupling. CVS was good enough for my grandfather, and it's good enough for you. Perhaps it would be instructive if you could tell us one advantage of cvs over git. (This is me exposing me to your terrible dev-flames, I was feeling too cold ;) I think Arun's comment was sarcastic ;) I guess that cvsserver bug can be dropped from blockers, no? Now, the other pending blockers... :( signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
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 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 signature.asc Description: This is a digitally signed message part.
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 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 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 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 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 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, 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 meta name=sarcasm value=on / 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 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 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 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, 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 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: '/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 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, 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 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 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.23view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/freebsd.eclass?rev=1.23content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/freebsd.eclass?r1=1.22r2=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òflamee...@gentoo.org
@@ -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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 *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 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 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 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 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 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 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 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 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 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 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 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. +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 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 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 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 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 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 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 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 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 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 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 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 - 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 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 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 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 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 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 signature
Re: [gentoo-portage-dev] [RFC/PATCH] repoman: unroll escaped lines so we can check the entirety of it
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 full content down to our checkers. This seems to work, but maybe someone can suggest something simpler. This code should come right after the line that says We're not in a here-document, because we only need it to trigger when we're not in a here-document. i was thinking this would handle wrapped lines and heredocs together better, but i'll ignore that until i can come up with a concrete case. I think it's going to be cleaner to detect an escaped newline with a regular expression, like r'(^|[^\\])\\$'. the reason i didn't go the regex route is because this fails with: echo foo \ cow whereas letting python take care of all the escaping works much better -mike signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH v2] repoman: add a mini framework for checking eclasses, and fill it out
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 missing based on the checks.
URL: https://bugs.gentoo.org/417159
URL: https://bugs.gentoo.org/417231
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v2
- fix optimization aspects
bin/repoman |6 +-
pym/repoman/checks.py | 161 ++---
pym/repoman/errors.py |1 -
3 files changed, 116 insertions(+), 52 deletions(-)
diff --git a/bin/repoman b/bin/repoman
index fd87847..779e651 100755
--- a/bin/repoman
+++ b/bin/repoman
@@ -315,8 +315,9 @@ qahelp={
file.size.fatal:Files in the files directory must be under 60 KiB,
file.name:File/dir name must be composed of only the following
chars: %s % allowed_filename_chars,
file.UTF8:File is not UTF8 compliant,
- inherit.autotools:Ebuild inherits autotools but does not call
eautomake, eautoconf or eautoreconf,
inherit.deprecated:Ebuild inherits a deprecated eclass,
+ inherit.missing:Ebuild uses functions from an eclass but does not
inherit it,
+ inherit.unused:Ebuild inherits an eclass but does not use it,
java.eclassesnotused:With virtual/jdk in DEPEND you must inherit a
java eclass,
wxwidgets.eclassnotused:Ebuild DEPENDs on x11-libs/wxGTK without
inheriting wxwidgets.eclass,
KEYWORDS.dropped:Ebuilds that appear to have dropped KEYWORDS for
some arch,
@@ -382,7 +383,6 @@ qahelp={
ebuild.majorsyn:This ebuild has a major syntax error that may cause
the ebuild to fail partially or fully,
ebuild.minorsyn:This ebuild has a minor syntax error that
contravenes gentoo coding style,
ebuild.badheader:This ebuild has a malformed header,
- eprefixify.defined:The ebuild uses eprefixify, but does not inherit
the prefix eclass,
manifest.bad:Manifest has missing or incorrect digests,
metadata.missing:Missing metadata.xml files,
metadata.bad:Bad metadata.xml files,
@@ -425,7 +425,7 @@ qawarnings = set((
ebuild.badheader,
ebuild.patches,
file.size,
-inherit.autotools,
+inherit.unused,
inherit.deprecated,
java.eclassesnotused,
wxwidgets.eclassnotused,
diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
index 77df603..c17a0bd 100644
--- a/pym/repoman/checks.py
+++ b/pym/repoman/checks.py
@@ -331,24 +331,6 @@ class EbuildQuotedA(LineCheck):
if match:
return Quoted \${A}\ on line: %d
-class EprefixifyDefined(LineCheck):
-Check that prefix.eclass is inherited if needed
-
- repoman_check_name = 'eprefixify.defined'
-
- _eprefixify_re = re.compile(r'\beprefixify\b')
- _inherit_prefix_re = re.compile(r'^\s*inherit\s(.*\s)?prefix\b')
-
- def new(self, pkg):
- self._prefix_inherited = False
-
- def check(self, num, line):
- if self._eprefixify_re.search(line) is not None:
- if not self._prefix_inherited:
- return errors.EPREFIXIFY_MISSING_INHERIT
- elif self._inherit_prefix_re.search(line) is not None:
- self._prefix_inherited = True
-
class NoOffsetWithHelpers(LineCheck):
Check that the image location, the alternate root offset, and the
offset prefix (D, ROOT, ED, EROOT and EPREFIX) are not used with
@@ -464,43 +446,124 @@ class InheritDeprecated(LineCheck):
(eclass, replacement)
del self._indirect_deprecated
-class InheritAutotools(LineCheck):
+class InheritEclass(LineCheck):
- Make sure appropriate functions are called in
- ebuilds that inherit autotools.eclass.
+ Base class for checking for missing inherits, as well as excess
inherits.
+
+ Args:
+ _eclass: Set to the name of your eclass.
+ _funcs: A tuple of functions that this eclass provides.
+ _comprehensive: Is the list of functions complete?
+ _exempt_eclasses: If these eclasses are inherited, disable the
missing
+ inherit check.
- repoman_check_name = 'inherit.autotools'
- _inherit_autotools_re =
re.compile(r'^\s*inherit\s(.*\s)?autotools(\s|$)')
- _autotools_funcs = (
- eaclocal, eautoconf, eautoheader,
- eautomake, eautoreconf, _elibtoolize)
- _autotools_func_re = re.compile(r'\b(' + \
- |.join(_autotools_funcs) + r')\b')
- # Exempt eclasses:
- # git - An EGIT_BOOTSTRAP variable may be used to call one of
- # the autotools functions.
- # subversion - An ESVN_BOOTSTRAP variable may be used to call one of
- # the
Re: [gentoo-portage-dev] [PATCH v2] repoman: unroll escaped lines so we can check the entirety of it
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
detect.
+ # Instead, strip the newline (which we know all lines
have), and
+ # append a 0. Then when python escapes it, if the
line ended
+ # in a \, we'll end up with a \0 marker to key off
of. This
+ # shouldn't be a problem with any valid ebuild ...
+ line_escaped = (line.rstrip('\n') +
'0').decode('string_escape')
That decode('string_escape') method won't work in python3, because the
str object doesn't have a decode method. I think something like this
will work with both python3 and python2:
import codecs
unicode_escape_codec = codecs.lookup('unicode_escape')
def unicode_escape(s):
return unicode_escape_codec(s)[0]
line_escaped = unicode_escape(line.rstrip('\n') + '0')
--
Thanks,
Zac
Re: [gentoo-portage-dev] [PATCH v2] repoman: add a mini framework for checking eclasses, and fill it out
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 eclass will change its category between unused and missing based on the checks. URL: https://bugs.gentoo.org/417159 URL: https://bugs.gentoo.org/417231 Signed-off-by: Mike Frysinger vap...@gentoo.org --- v2 - fix optimization aspects Looks good to me. -- Thanks, Zac
Re: [gentoo-portage-dev] [PATCH v2] repoman: unroll escaped lines so we can check the entirety of it
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 single \ which makes it hard for us to
detect.
+# Instead, strip the newline (which we know all lines
have), and
+# append a 0. Then when python escapes it, if the
line ended
+# in a \, we'll end up with a \0 marker to key off
of. This
+# shouldn't be a problem with any valid ebuild ...
+line_escaped = (line.rstrip('\n') +
'0').decode('string_escape')
That decode('string_escape') method won't work in python3, because the
str object doesn't have a decode method. I think something like this
will work with both python3 and python2:
import codecs
unicode_escape_codec = codecs.lookup('unicode_escape')
def unicode_escape(s):
return unicode_escape_codec(s)[0]
- return unicode_escape_codec(s)[0]
+ return unicode_escape_codec.decode(s)[0]
line_escaped = unicode_escape(line.rstrip('\n') + '0')
--
Thanks,
Zac
[gentoo-portage-dev] [PATCH v3] repoman: unroll escaped lines so we can check the entirety of it
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 import codecs for escaping strings
pym/repoman/checks.py | 63 +++-
1 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
index c17a0bd..402169e 100644
--- a/pym/repoman/checks.py
+++ b/pym/repoman/checks.py
@@ -5,6 +5,7 @@
This module contains functions used in Repoman to ascertain the quality
and correctness of an ebuild.
+import codecs
import re
import time
import repoman.errors as errors
@@ -757,8 +758,11 @@ _here_doc_re = re.compile(r'.*\s[-]?(\w+)$')
_ignore_comment_re = re.compile(r'^\s*#')
def run_checks(contents, pkg):
+ unicode_escape_codec = codecs.lookup('unicode_escape')
+ unicode_escape = lambda x: unicode_escape_codec.decode(x)[0]
checks = _constant_checks
here_doc_delim = None
+ multiline = None
for lc in checks:
lc.new(pkg)
@@ -772,19 +776,54 @@ def run_checks(contents, pkg):
here_doc = _here_doc_re.match(line)
if here_doc is not None:
here_doc_delim = re.compile(r'^\s*%s$' %
here_doc.group(1))
+ if here_doc_delim is not None:
+ continue
+
+ # Unroll multiline escaped strings so that we can check things:
+ # inherit foo bar \
+ # moo \
+ # cow
+ # This will merge these lines like so:
+ # inherit foo bar moo cow
+ try:
+ # 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
detect.
+ # Instead, strip the newline (which we know all lines
have), and
+ # append a 0. Then when python escapes it, if the
line ended
+ # in a \, we'll end up with a \0 marker to key off
of. This
+ # shouldn't be a problem with any valid ebuild ...
+ line_escaped = unicode_escape(line.rstrip('\n') + '0')
+ except:
+ # Who knows what kind of crazy crap an ebuild will have
+ # in it -- don't allow it to kill us.
+ line_escaped = line
+ if multiline:
+ # Chop off the \ and \n bytes from the previous line.
+ multiline = multiline[:-2] + line
+ if not line_escaped.endswith('\0'):
+ line = multiline
+ num = multinum
+ multiline = None
+ else:
+ continue
+ else:
+ if line_escaped.endswith('\0'):
+ multinum = num
+ multiline = line
+ continue
- if here_doc_delim is None:
- # We're not in a here-document.
- is_comment = _ignore_comment_re.match(line) is not None
- for lc in checks:
- if is_comment and lc.ignore_comment:
- continue
- if lc.check_eapi(pkg.metadata['EAPI']):
- ignore = lc.ignore_line
- if not ignore or not ignore.match(line):
- e = lc.check(num, line)
- if e:
- yield
lc.repoman_check_name, e % (num + 1)
+ # Finally we have a full line to parse.
+ is_comment = _ignore_comment_re.match(line) is not None
+ for lc in checks:
+ if is_comment and lc.ignore_comment:
+ continue
+ if lc.check_eapi(pkg.metadata['EAPI']):
+ ignore = lc.ignore_line
+ if not ignore or not ignore.match(line):
+ e = lc.check(num, line)
+ if e:
+ yield lc.repoman_check_name, e
% (num + 1)
for lc in checks:
i = lc.end()
--
1.7.8.6
