[gentoo-dev] anybody interested in writing a Perl ebuild?
Hello, is anyone interested in writing a Perl ebuild for this payment module: http://search.cpan.org/dist/Net-Braintree/ Thanks, Grant P.S. Braintree is a stellar payment company: https://www.braintreepayments.com/developers
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
On Wed, May 23, 2012 at 12:31:59AM -0700, Grant wrote: Hello, is anyone interested in writing a Perl ebuild for this payment module: http://search.cpan.org/dist/Net-Braintree/ Use g-cpan. g-cpan -g Net::Braintree It will generate packages for the module and all needed deps (DateTime-Format-RFC3339, DateTime-Format-Atom, Module-Install-TestTarget, Hash-Inflator, local-lib, URI-Query). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
On May 20, autools.eclass was changed to no longer inherit eutils, see
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Relying on autotools.eclass for your eutils needs was always a terrible
idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
since they can no longer use epatch. See bug #416847 for an example.
Check your ebuilds to make sure you inherit eutils in anything that uses
epatch!
-Alexandre Rostovtsev.
Since eutils inherits multilib and user, the breakage extends beyond epatch.
For example, I just saw bug #417153, where a user reported failed calls
to enew{user,group}.
The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Remove eclass/ChangeLog
On 05/23/2012 05:36 AM, Ryan Hill wrote: On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominenssuomi...@gentoo.org wrote: ChangeLog entries missing for every autotools.eclass modification today. On 05/20/2012 03:31 PM, Mike Frysinger (vapier) wrote: vapier 12/05/20 12:31:33 One person doesn't do entries. OMG let's remove it! absolutely because inconsitency renderess the file useless
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
Hello, is anyone interested in writing a Perl ebuild for this payment module: http://search.cpan.org/dist/Net-Braintree/ Use g-cpan. g-cpan -g Net::Braintree It will generate packages for the module and all needed deps (DateTime-Format-RFC3339, DateTime-Format-Atom, Module-Install-TestTarget, Hash-Inflator, local-lib, URI-Query). Thanks, I gave that a try and it did a bunch of stuff but when I try to emerge Net-Braintree I get: Verifying ebuild manifests !!! A file is not listed in the Manifest: '/var/lib/layman/moonrise/perl-gcpan/DateTime-Format-RFC3339/DateTime-Format-RFC3339-1.0.5.ebuild' !!! A file is not listed in the Manifest: '/var/lib/layman/moonrise/perl-gcpan/DateTime-Format-Atom/DateTime-Format-Atom-1.0.2.ebuild' 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? - Grant
Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!
On 22.5.2012 8.53, Michał Górny wrote: Excuse me but the way this change was handled is a bit depressing. First, the ebuilds should have been fixed to inherit eutils and then remove eutils from autotools. Now, a bunch of ebuilds are broken out of nowhere. I don't believe this issue was that urgent in order to justify the significant breakage of portage tree. First of all, to quote devmanual: | Before updating eutils or a similar widely used eclass, it is best to | email the gentoo-dev list. It may be that your proposed change is | broken in a way you had not anticipated [...]. If you don't email | gentoo-dev first, and end up breaking something, expect to be in a | lot of trouble. Not that this disrespect for this rule is something new... Even more important is the next chapter: When removing a function or changing the API of an eclass, make sure that it doesn't break any ebuilds in the tree, and post a notice to gentoo-dev at least 30 days in advance, preferably with a patch included. This qualifies as changing the API of an eclass. This chapter comes from a council decision: http://www.gentoo.org/proj/en/council/meeting-logs/2008-summary.txt Regards, Petteri
[gentoo-dev] Help required with getting new media-gfx/graphviz in tree.
We are behind with graphviz and 2.28.x series has been out for quite a while. However working on the ebuild will require quite a work and then backtracking the bugs that come after it as a result (believe me, there will be ones) It seems graphics@ is currently a bit understaffed and I really don't see anyone working on this anytime soon without sending this mail. Thanks ahead - Samuli
[gentoo-dev] dev-libs/libusb - virtual/libusb, please, check your overlays
Whole gentoo-x86 is using the virtuals now. Please check your overlays to avoid dev-libs/libusb from creeping back in to the tree. http://qa-reports.gentoo.org/output/genrdeps/dindex/dev-libs/libusb http://qa-reports.gentoo.org/output/genrdeps/rindex/dev-libs/libusb If you have packages in overlays using dev-libs/libusb please fix them now to avoid them creeping into Portage. There is a repoman bug open but still without a patch: http://bugs.gentoo.org/417123 This is important now because of the dev-libs/libusb-compat stabilization: http://bugs.gentoo.org/417135 Otherwise you'd be introducing conflicting dependencies for /stable/ users. Futhermore some of the virtual/libusb dependencies in tree are missing usage of correct SLOT, and should be fixed, that involves checking the package sources (of course). If you want to help with this, please do. Thanks, Samuli
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos pa...@gentoo.org wrote:
El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
On May 20, autools.eclass was changed to no longer inherit eutils, see
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Relying on autotools.eclass for your eutils needs was always a terrible
idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
since they can no longer use epatch. See bug #416847 for an example.
Check your ebuilds to make sure you inherit eutils in anything that uses
epatch!
-Alexandre Rostovtsev.
Since eutils inherits multilib and user, the breakage extends beyond epatch.
For example, I just saw bug #417153, where a user reported failed calls
to enew{user,group}.
The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)
It is far too late to do that. What is done is done. Let try and fix
what is still broken
Regards,
Markos
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:
On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos pa...@gentoo.org wrote:
El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
On May 20, autools.eclass was changed to no longer inherit eutils, see
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Relying on autotools.eclass for your eutils needs was always a terrible
idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
since they can no longer use epatch. See bug #416847 for an example.
Check your ebuilds to make sure you inherit eutils in anything that uses
epatch!
-Alexandre Rostovtsev.
Since eutils inherits multilib and user, the breakage extends beyond
epatch.
For example, I just saw bug #417153, where a user reported failed calls
to enew{user,group}.
The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)
It is far too late to do that. What is done is done. Let try and fix
what is still broken
Regards,
Markos
But we still have no idea what kind of commands provided by eutils and
eclasses inheritted by it are now missing, epatch usage was fixes,
enewgroup/user will probably be done but... other missing commands could
still appear in the tree :|
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 01:00 PM, Pacho Ramos wrote:
El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:
On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos pa...@gentoo.org wrote:
El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
On May 20, autools.eclass was changed to no longer inherit eutils, see
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133r2=1.134
Relying on autotools.eclass for your eutils needs was always a terrible
idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
since they can no longer use epatch. See bug #416847 for an example.
Check your ebuilds to make sure you inherit eutils in anything that uses
epatch!
-Alexandre Rostovtsev.
Since eutils inherits multilib and user, the breakage extends beyond
epatch.
For example, I just saw bug #417153, where a user reported failed calls
to enew{user,group}.
The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)
It is far too late to do that. What is done is done. Let try and fix
what is still broken
Regards,
Markos
But we still have no idea what kind of commands provided by eutils and
eclasses inheritted by it are now missing, epatch usage was fixes,
enewgroup/user will probably be done but... other missing commands could
still appear in the tree :|
I wrote a simple, stupid script just a moment ago. Please don't show it
to anybody who knows how to write in Python :D
It shows all missing inherits, not just the ones causing failures, but
it could prolly be adjusted to do that instead.
Cheers,
Kacper
#!/usr/bin/env python
import re
import os
import argparse
class DirectoryWalker:
# a forward iterator that traverses a directory tree
def __init__(self, directory):
self.stack = [directory]
self.files = []
self.index = 0
def __getitem__(self, index):
while 1:
try:
file = self.files[self.index]
self.index = self.index + 1
except IndexError:
# pop next directory from stack
self.directory = self.stack.pop()
self.files = os.listdir(self.directory)
self.index = 0
else:
# got a filename
fullname = os.path.join(self.directory, file)
if os.path.isdir(fullname) and not os.path.islink(fullname):
self.stack.append(fullname)
return fullname
usage = usage: %prog [options] DIRECTORY
parser = argparse.ArgumentParser()
parser.add_argument(-e, nargs=1, default=[user],
help=Name of the eclass to test, e.g. 'user')
parser.add_argument(-p, nargs=1, default=[/usr/portage],
help=Directory where eclass resides, e.g. PORTDIR)
parser.add_argument(directory, nargs=1,
help=Directory with ebuilds to run tests )
args = parser.parse_args()
is_ebuild = re.compile('\.ebuild$')
ebuilds = filter(is_ebuild.search, DirectoryWalker(args.directory[0]))
re_func = re.compile(FUNCTION).search # TODO: improve me
fname = open('%s/eclass/%s.eclass'% (args.p[0], args.e[0]))
funcs = [func.split()[-1].strip()
for func in filter(re_func, fname.readlines())]
fname.close()
# Listen carefully, I shall speak it only once
regexps = {func: re.compile(func).search for func in funcs}
re_inher = re.compile(^inherit.*%s% args.e[0]).match
for ebuild in ebuilds:
fname = open(ebuild,'r')
lines = fname.readlines()
fname.close()
uses_function = any([len(filter(regexps[key], lines))
for key in regexps.keys()])
uses_eclass = len(filter(re_inher, lines))
if uses_function and not uses_eclass:
print(%s should inherit %s.eclass % (ebuild, args.e[0]))
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] So...
... since the bugs seem to be stalled and noone has recently posted on gentoo- scm, what's the real status of the infamous git migration? :) Cheers, A -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. 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). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *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. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- 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+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. 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). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *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. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- 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+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE- I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On May 23, 2012 1:55 PM, Johannes Huber j...@gentoo.org wrote: Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. 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). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *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. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- 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+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE- I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD Another vote for clean cut from me.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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. +1 Please cut cvs support once and for all. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 09:25 AM, Andreas K. Huettel wrote: 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. +1 Please cut cvs support once and for all. +1 for clean cut -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+85e4ACgkQVxOqA9G7/aDWpgD/SYfC3aOlOP2kAwK3qt81smH8 YWs60Kl77Xx+wIM1jx8A/0PkisxPTsLE5jR59GhaDmC+epoodW1GOak//pAvCmCG =F8Rw -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 05/23/2012 07:54 AM, Johannes Huber wrote: Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. 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). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *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. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers clean-cut++ -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Please kill CVS with fire! I've been waiting for this since 2009. -- Fabio Erculiani
[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
On 2012-05-23 22:42, Michael Weber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. 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). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *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. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- 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+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE- Another vote for clean cut.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
+1 for killing cvs Johannes Huber писал 2012-05-23 15:54: Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. 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). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *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. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- 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+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE- I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers -- 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 05/23/2012 10:39 AM, Alexey Shvetsov wrote: +1 for killing cvs Looks like the bloodbath begins. I too am in favor of killing cvs. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 23/05/12 14:42, Michael Weber wrote: Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. Clean cut turns of cvs access on a given and announced timestamp, I want to see to it gone. +1 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] anybody interested in writing a Perl ebuild?
On Wed, May 23, 2012 at 01:14:52AM -0700, Grant wrote: Thanks, I gave that a try and it did a bunch of stuff but when I try to emerge Net-Braintree I get: that's weird. it did generate all of them fine here which version of g-cpan? I 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. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 for git switch. git-cvsserver would make sense if it would be completely transparent for cvs client. and it's not. so why bother setuping fragile things? - -- Sergei -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk+9ETgACgkQcaHudmEf86pHTgCgh0lWhRz5VAf0N9xRPOE4gld3 IXIAn1Q9q7BSaIGZpiUHgATng2rBVBWZ =vbwK -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remove eclass/ChangeLog
On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 05/23/2012 05:36 AM, Ryan Hill wrote: One person doesn't do entries. OMG let's remove it! absolutely because inconsitency renderess the file useless Well, for now the solution is to enforce following policy. For the future, perhaps the policy's time has ended. Sure, Changelogs can be handy, but they are increasingly redundant and scm comments have the potential to be far more useful. By all means require meaningful scm commit comments, but if Changelog files are holding us back either auto-generate them or ditch them. And, to add my own to cents to this chain about the only thing worse than failing to directly inherit an eclass dependency is to break the tree fixing the problem on personal initiative. When a dev messes up the solution is to talk to them or if necessary talk to devrel/QA - not to break end-user systems. Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 10:43 AM, Anthony G. Basile bluen...@gentoo.org wrote: Looks like the bloodbath begins. I too am in favor of killing cvs. Please, let it die. I'll miss my scripts, but I'll gladly deal with that over whatever breakage comes along every time some cvs plugin messes up the tree, or we can't use some useful git feature because cvs amazingly enough behaves like an scm invented 20 years ago. Rich
Re: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, 23 May 2012 14:42:37 +0200 Kill it! And while we're at it, kill ChangeLogs as well! /me hides... +1 +1 +1 +1 ... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Remove eclass/ChangeLog
On Wed, 23 May 2012 12:29:34 -0400 Rich Freeman ri...@gentoo.org wrote: On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 05/23/2012 05:36 AM, Ryan Hill wrote: One person doesn't do entries. OMG let's remove it! absolutely because inconsitency renderess the file useless Well, for now the solution is to enforce following policy. For the future, perhaps the policy's time has ended. Sure, Changelogs can be handy, but they are increasingly redundant and scm comments have the potential to be far more useful. By all means require meaningful scm commit comments, but if Changelog files are holding us back either auto-generate them or ditch them. ChangeLogs could be fine for ebuilds. But for more broad cases like eclasses, one can usually have a set of changes prepared for commit. With CVS, it's PITA but with git it's already much better. Of course, it all fails if every commit has to update a randomly changed, shared file called ChangeLog... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Michał Górny писал 2012-05-23 19:33: 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... Well this can be done with *meaningfull* git commit messages =D so +1 -- 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 Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) If we can get rid of #2, we're willing to live with #1. 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. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Robin H. Johnson писал 2012-05-23 19:47: On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Isnt git works with shallow clone? like # git clone --depth 1 or any other desired value git+ssh://gitrepo.uri::repo So you can clone in this manner and push changes back Also for depth = 1 pack size will be similar to gzipped rsync snapshot (~40M) If we can get rid of #2, we're willing to live with #1. 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. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. -- 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 23.05.2012 18:47, Robin H. Johnson wrote: On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) If we can get rid of #2, we're willing to live with #1. 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. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. Was this a vote for or against a quick proceeding towards git? You are probably the one who can judge best if the infra side could be made ready soonish. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson robb...@gentoo.org wrote: 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Please don't go to this trouble for the ability to commit to portage on *really* slow systems.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Matt Turner писал 2012-05-23 19:59: On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson robb...@gentoo.org wrote: 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Please don't go to this trouble for the ability to commit to portage on *really* slow systems. Isnt cvs too sloow on mips? git is much more faster. Same for arm. About big repos, well why not use shallow cloned repo. It will work with plane history -- 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
Robin H. Johnson писал 2012-05-23 19:47: On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) If we can get rid of #2, we're willing to live with #1. 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. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. Another good point for repo size https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_use_git_for_large_projects.2C_where_the_repository_is_large.2C_say_approaching_1_TB.2C_but_a_checkout_is_only_a_few_hundred_MB.3F_Will_every_developer_need_1_TB_of_local_disk_space.3F -- 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 Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote: Isnt git works with shallow clone? like # git clone --depth 1 or any other desired value git+ssh://gitrepo.uri::repo So you can clone in this manner and push changes back Also for depth = 1 pack size will be similar to gzipped rsync snapshot (~40M) The shallow clone is still a shallow clone of the entire repo, and you get the subtree checkout as just part of that. Shallow clones are also read-only last I checked. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Robin H. Johnson писал 2012-05-23 20:19: On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote: Isnt git works with shallow clone? like # git clone --depth 1 or any other desired value git+ssh://gitrepo.uri::repo So you can clone in this manner and push changes back Also for depth = 1 pack size will be similar to gzipped rsync snapshot (~40M) The shallow clone is still a shallow clone of the entire repo, and you get the subtree checkout as just part of that. Shallow clones are also read-only last I checked. That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively -- 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 Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov ale...@gentoo.org wrote: That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively Is that going to be a practical condition to maintain? And how big will the repository actually be? Are we talking a GB or two, or something orders of magnitude larger? Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Rich Freeman писал 2012-05-23 20:32: On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov ale...@gentoo.org wrote: That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively Is that going to be a practical condition to maintain? And how big will the repository actually be? Are we talking a GB or two, or something orders of magnitude larger? Rich Full clone will be about 1G or so but no more then 2. If we will drop changelog it 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 Wed, May 23, 2012 at 01:32:45PM -0400, Rich Freeman wrote: On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov ale...@gentoo.org wrote: That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively Is that going to be a practical condition to maintain? We're going to have lots of branches and merges. And how big will the repository actually be? Are we talking a GB or two, or something orders of magnitude larger? In terms of repo size, we were going to be slicing the history into two parts: - fresh start - historical The 'fresh start' is what new commits will go on top of, and ranges 40-120MB depending on what git window compression is used. The historical is ~1.2GB, and if you want a continuous history, you just use graft to merge the two. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Alexey Shvetsov schrieb: Shallow clones are also read-only last I checked. That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively There can also be breakage when someone reverts a commit that it is not part of your shallow clone's history, and then you pull. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Remove eclass/ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/23/2012 05:46 PM, Michał Górny wrote: On Wed, 23 May 2012 12:29:34 -0400 Rich Freeman ri...@gentoo.org wrote: On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 05/23/2012 05:36 AM, Ryan Hill wrote: One person doesn't do entries. OMG let's remove it! absolutely because inconsitency renderess the file useless Well, for now the solution is to enforce following policy. For the future, perhaps the policy's time has ended. Sure, Changelogs can be handy, but they are increasingly redundant and scm comments have the potential to be far more useful. By all means require meaningful scm commit comments, but if Changelog files are holding us back either auto-generate them or ditch them. ChangeLogs could be fine for ebuilds. But for more broad cases like eclasses, one can usually have a set of changes prepared for commit. With CVS, it's PITA but with git it's already much better. Of course, it all fails if every commit has to update a randomly changed, shared file called ChangeLog... So we did we introduce changelogs for eclass/ in the first place if everyone is happy with getting rid of them? - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPvSyUAAoJEPqDWhW0r/LCrp0QAIwYhxeO5qeYaCrh3B7WCd3X pt8cMAquC38VOIjfd+Lz+iG2+8ftYb1s5xQu52F6zZEkbwxCLmYBKJrnpNljSm8T QAmB4xXg4vKxjpwAyc+fOev53HZdQyzav36m1DhOEXZKixI+OR1MplZ55VlEAT0+ wRPJj9+WsiTMONRkuukCCJtvnY1kDjJLtjNDzUA4QSxh+pgcgAPGoDMh5nL706h5 KW5/jBTW01+oEWyBosXxBUoX8p2/FvAG1Meib0BbEBdsyrYdQSDJK2xMjK0JJ7PH QhOeA2NameaFA1YzvebB7KDNSGB3zMm1TdnYmhfU1jmWImyB1BQvdFT37KcvZagQ WhErwHxDojz27lhiCHY95nPDATMxxiC61WdBLoByV93xRAqwnpeSva26hV1Nv552 n3nZ5DWCKRF+qSSEo1Oz3DCtDxV5ygyOw8iHOhqhZ5IcuNIchfYgss/dCFRRy3zy uN8l/wge7J0MjOVKBnpT9nWmmwhB4pD+o3Avq2OBwuDrqAW7iYKkTPzQwsIq7ZGI HTvtMhOrULIkm/2c77FGXdFwJWMPueroUe4LntY/0c2l30P2Fafe0sEp5yCjzCeA uXwWC0iWTPuVBYGFJQ5iZqB3X+LAVWz2HLpqZRJ9qW4X3QXSuXsrr5wdAukjAUCu 8qMUNncYeLeHvdeazWey =/lXi -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-1 -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Remove eclass/ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/20/2012 03:25 PM, Michał Górny wrote: On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: ChangeLog entries missing for every autotools.eclass modification today. I will repeat once again: autogenerate them. +1 I think it is nice to be able to use a different changelog entry than commit message, but autogenerated entries would be more consistent. Having ChangeLog files at all is just a convenience, but an important one imo. It's the quickest way to track down sudden breakage. scm comments are _not_ the same as a single file holding information on all changes to an entire directory. As for the given case I demand that the missing ChangeLog entries will be added now by vapier, cause it seems they have already caused breakage: #417265 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPvTkrAAoJEFpvPKfnPDWzG5UIAIKFaGAXYGiyLBwbeQ1QxdlD wndZJIXN9pWwDU/F3uyKqmHqNC1Aqf7U7g88ue/1FhSSyJeG+rEH1Qmym0Eb3fIe hECZKWHMV/CDe2VhgGZ+dKvq3Pxz/nGt994NurLbBRWPCY2md63M45+499gb32w0 5wpYcH8vXw/noHvfw4o77Pwzu+5yphDWycOFtrc/UWIK0NXQZLzalnYqwl2HjHKE vRWn/eAcTL+TzkS/pM7RI4BCROl3Rmk+jmkgeIOAlVlcpYEa41FB5wv7t3HdGM3i AWiQySQ8iKehH4Blr97czn30hqekI6ACD08hEhiFZeA7JJYRT4ziYS1lapBzGFk= =u07L -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, May 24, 2012 at 1:07 AM, 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. +1 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Remove eclass/ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/05/12 03:23 PM, hasufell wrote: On 05/20/2012 03:25 PM, Michał Górny wrote: On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: ChangeLog entries missing for every autotools.eclass modification today. I will repeat once again: autogenerate them. Isn't one of the reasons the changelog is there, is so that eclass changes can be committed with repoman and (with the newer repoman) the - -m comment will automatically be added to the ChangeLog ?? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk+9Pn0ACgkQ2ugaI38ACPCtogEAh1/FLYMho2HaSyg7e6JDtwcW UTAPNaD3WPFGyJbO/ZMA/0gh1Ale/msPdzlJyYBny6rDtCjkUNCAP2zwwk+KXV5R =tdxA -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 9: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. The difference is that while Git is much faster, comes with a very low WTF/secs rate and really forces you to do things the right way, other L*e software is not and I agree with you on this. my 0.02c ;-) -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME) -- Fabio Erculiani
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 for git I am more used to it, I find it easier to use regarding the utilities as well as the gui and it is more consistent. The fact alone that I can update a single directory in CVS without updating all others can cause breakage, cause repoman checks may be erroneous. On 05/23/2012 09:37 PM, Arun Raghavan 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. This sounds rather emotional to me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPvT/OAAoJEFpvPKfnPDWzgPIH/38QflM4GNiUNo3bC5/8tock FM03JE1Iln4ThvLl25opwGiO5R8akoD3koroUVPLoWV//QfYmcQIm7k7dJJCk4+m WSQ6H21fL9v2m6QX7PuJwaENFSFBxu3UFy6BE+39iFJAPBiigH1hbE0rad/twYdr xhnHZti1rGbaFBeXxlGmdhJYi7dtndyuZgTu0oQFfE0+sAAK2GPe5CGLoOFHdtxS WCMY3C3cB0R7XPoJwUvvt2KmIEXNWfq6rDW3o6so89VdRSNykwMLdK1eZ+MZidIE 61CAJiuIsT4cKX5pbqo72GtU4tUOkQ6jjaJhofAcrSMYKA0IsxYvFAYnKqO4lh4= =cdBk -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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 ;)
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Arun Raghavan писал 2012-05-23 22:37: 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. CVS is damn slow. On every cvs up it should stat *all* files and cvs entryes in current state its ~212k files in gentoo-x86. It will be sloow on every machine unless you put all this files in ram Actual number of usefull files is only about ~60k (ebuilds,eclasses,metadata.xml,patches) Its comparable to linux kernel git tree ~42k files And yes git is much more faster. PS if ibm s/360 was good for my grandfather why we all use modern intel pc? Lets stay under 1 MIPS machines like s/360 -- 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 Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan 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. I hope this is sarcasm or a joke? William pgp8HVeq1dZv3.pgp Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 4:00 PM, Ezequiel Garcia elezegar...@gmail.com wrote: 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. 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
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 06:58 PM, Justin wrote: Was this a vote for or against a quick proceeding towards git? No, just to decide if git-cvsserver (providing cvs access) should be part of an git master tree szenario. In bugzie: Should https://bugs.gentoo.org/333699 stay a blocker of https://bugs.gentoo.org/333531. No flame about git over cvs in general, whether or not sparse checkouts (i.e. w/o kde-*,gnome-* categories) make sense. Michael - -- 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+9SfMACgkQknrdDGLu8JCGtQEAiS3Wcsll94w2rqlMP2WpSypU fLdxa2wjstJ5Y/2iXCcA+wX/p+OwBzjLAxiwKnSl98XlLSIT/Qsxm5H1TvEEJ71w =k8j9 -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, 23 May 2012 15:25:54 -0500 William Hubbs willi...@gentoo.org wrote: On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan 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. I hope this is sarcasm or a joke? Obviously. His grandfather used SCCS. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 07:06 PM, Alexey Shvetsov wrote: Isnt cvs too sloow on mips? git is much more faster. Same for arm. About big repos, well why not use shallow cloned repo. It will work with plane history Can we please cut that out. I do/did arch testing on arm5, ppc, sparc on rsync trees and committed the changes from my shiny 2007s notebook. I did hesitate to spread my commit credentials over all these machines. Michael - -- - -- 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+9Sv8ACgkQknrdDGLu8JBFLAEAghjKAQwckMndZfO/gGQyVI3N butEASSJZYQetyNthUgA/3e5Sf9B93ED/wDSDflKP7YwTVwiFOe5c65Md4vdEsQs =FW7S -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 10:37:55PM +0200, Michał Górny wrote: On Wed, 23 May 2012 15:25:54 -0500 William Hubbs willi...@gentoo.org wrote: On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan 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. I hope this is sarcasm or a joke? Obviously. His grandfather used SCCS. Heh, that's possible, or maybe he even used prodos [1], which was pretty cool for its time. William [1] http://en.wikipedia.org/wiki/PRODOS pgp4O14kFI8pz.pgp Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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. Would users have a way of gaining read-only access? This would be EXTREMELY helpful. 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. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-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-
Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/22/2012 04:49 AM, Mike Frysinger wrote:
On Sunday 20 May 2012 19:24:13 hasufell wrote:
case ${2} in
please use $1/$2/etc... with positional variables when possible
16|22|24|32|36|48|64|72|96|128|192|256) size=${2}x${2};;
16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|128x128|
192x192|256x256)
size=${2};; scalable) size=scalable;; *) eqawarn ${2} is an
unsupported icon size! ((++ret));; esac
you can write this w/out having to duplicate two lists: size= if [[
$2 == scalable ]] ; then size=$2 elif [[ ${2:0:2}x${2:0:2} ==
$2 ]] ; then size=${2:0:2} case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256) ;; *) size= ;; esac fi if
[[ -z ${size} ]] ; then eqawarn ${2} is an unsupported icon
size! ((++ret)) fi shift 2
shift 2;; -t|--theme) theme=${2} shift 2;; -c|--context)
context=${2} shift 2;; *)
if [[ -z ${size} ]] ; then dir=/usr/share/pixmaps else
dir=/usr/share/icons/${theme}/${size}/${context} fi insinto
${dir}
considering you only use $dir once, you could just call `insinto`
directly on the path rather than using the dir variable at all
elif [[ -d ${1} ]] ; then for i in ${1}/*.{png,svg} ; do doins
${i} ((ret+=$?)) done
why loop ? `doins ${1}/*.{png,svg}` works just as well
you probably want to enable nullglobbing here, otherwise this will
cause problems if you try to doicon on a dir that contains just
svg.
also, what about other file types ? people install xpm, svgz, gif,
and other file types ...
exit ${ret}
bash masks error codes to [0..255], so all the ret updates should
probably be changed to just: ret=1
after all, i doubt anyone cares how many errors there were, just
that one occurred. and while you're here, might want to make it
auto die on failure like we've done with all our other helpers.
-mike
Thanks, I'v implemented most of that, but your proposal about
non-duplicated list in case) has multiple problems. The only cases
that actually work with that snippet are:
16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|scalable.
All others will fail (like 128x128 or just 48).
So it would end up like this:
case $1 in
-s|--size)
if [[ ${2:0:2}x${2:0:2} == $2 ]] ; then
size=${2:0:2}
elif [[ ${2:0:3}x${2:0:3} == $2 ]] ; then
size=${2:0:3}
else
size=${2}
fi
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256)
size=${size}x${size};;
scalable)
;;
*)
eerror ${size} is an unsupported icon size!
exit 1;;
esac
shift 2;;
-t|--theme)
This does not really look cleaner than just using two lists. I would
prefer the latter for readability.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPvX3MAAoJEFpvPKfnPDWzxvMH/16kN1Zkby6LHg2Ev7H2qNPh
ajbqVonTuuLnIVxEwXYXYABEkF+qwD5xnJPMEclvkn8FXAVerFeyaxJgBelldXnr
DJMHiPhz0umJaMfvAFrEsbIo5IrxKMTpMMj3fuu5ruQMrSboV4alPSM7l2haXZ5W
3TbfbFmWoQzft1DolDlFb38M0TtRko7viZ1KQJUZjxCEClh8tEiOrQVxR8xcoi33
MiwEVZlib4KnWetq3qGZdU+xRFi/yzUmtFVv0pfbYIV51w4KHoi8cD6OkpiVzLdI
bhWCmyDeKq6wOcfXfcfGKzYc+2M/hP8xkhiG3/KjDXe6FUzdG63+U1Wmu521VDM=
=Rn8t
-END PGP SIGNATURE-
Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass
On Wednesday 23 May 2012 20:16:12 hasufell wrote:
Thanks, I'v implemented most of that, but your proposal about
non-duplicated list in case) has multiple problems. The only cases
that actually work with that snippet are:
16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|scalable.
All others will fail (like 128x128 or just 48).
so do:
size=
if [[ $2 == scalable ]] ; then
size=$2
elif [[ ${2%%x*}x${2%%x*} == $2 ]] ; then
size=${2%%x*}
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256) ;;
*) size= ;;
esac
fi
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/2012 02:30 AM, Mike Frysinger wrote:
On Wednesday 23 May 2012 20:16:12 hasufell wrote:
Thanks, I'v implemented most of that, but your proposal about
non-duplicated list in case) has multiple problems. The only
cases that actually work with that snippet are:
16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|scalable.
All others will fail (like 128x128 or just 48).
so do: size= if [[ $2 == scalable ]] ; then size=$2 elif [[
${2%%x*}x${2%%x*} == $2 ]] ; then size=${2%%x*} case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256) ;; *) size= ;; esac fi
-mike
that will install
doicon -s 256x256 ${FILESDIR}/${PN}.svg
into
/usr/share/icons/hicolor/256/apps/${PN}.svg
and
doicon -s 256 ${FILESDIR}/${PN}.svg
into
/usr/share/pixmaps/${PN}.svg
I don't see the point in bothering with that.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPvYNeAAoJEFpvPKfnPDWzXeEIAKAK+c/+xkt4UIS2xLK9SGMQ
U1DwEqtiiytYvpB84QYrYjnoEMZrZN76uv6GsFtDYQC1nS5PDJt6F8yhGldF5CWr
UrD12iiIVIi3gLvkWVyfdhX3gA4wn/CL8Vq00R2oIMjy00uTBcYUmFV9X7xJzIxz
zyXhZBsXSpdnqZ1x9+nc9m9zy77Y7FIwA1dR9bWhBsiYMshUjTtGlIBE3uzm6v4Z
qKzhwKoG67jKFQuMyu495VSGGjXIJ0wuNofA2GRWLYZc5xP2nmeG5Q70vpM0CRiI
5Y2epr8thqbX53tsIxyJKqSwvqHGIKItChD0av9saIUa2D0KaUEiRrRN+m6cJuM=
=YxUg
-END PGP SIGNATURE-
Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/2012 02:30 AM, Mike Frysinger wrote:
On Wednesday 23 May 2012 20:16:12 hasufell wrote:
Thanks, I'v implemented most of that, but your proposal about
non-duplicated list in case) has multiple problems. The only
cases that actually work with that snippet are:
16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|scalable.
All others will fail (like 128x128 or just 48).
so do: size= if [[ $2 == scalable ]] ; then size=$2 elif [[
${2%%x*}x${2%%x*} == $2 ]] ; then size=${2%%x*} case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256) ;; *) size= ;; esac fi
-mike
alright
this would work
-s|--size)
if [[ ${2%%x*}x${2%%x*} == $2 ]] ; then
size=${2%%x*}
else
size=${2}
fi
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256)
size=${size}x${size};;
scalable)
;;
*)
eerror ${size} is an unsupported icon size!
exit 1;;
esac
shift 2;;
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPvYRDAAoJEFpvPKfnPDWz8DgIAIA3T7GLWeN1m+8vfyeaVMXj
7UWyBXEcCU5geYqi5KsuY8/0Mq0e47ER+EH3VU+CrbV+UlDxxbyzsF4cqMRq/Oe+
Zz5CmSv4vjAfOyVe9psChue9PnKQwe/w6sS+L9zBftIzCb8G48Eefiir7lp9p7HO
9M5KkLeJwThDkUfhNUKtbNdIf1clnT1GVNrvcPuuasARN/of4ClQVVRISXKKHZen
9yA4D876CxtyN0jBHn78pRg0kZwSPL3PqucIQjli+usvGONX+LWuc7uWFJk8hnHI
E9cJrbUvkSJZx07ajEK1maohJBkfZdVWWxCGtZk0T00Kd2Nyy7o9SFX1hXX3F4I=
=/kaW
-END PGP SIGNATURE-
[gentoo-dev] Re: enhancement for doicon/newicon in eutils.eclass
On 05/21/2012 01:24 AM, hasufell wrote:
I want support for installing icons into the appropriate directories
which are under /usr/share/icons/... and not just pixmaps.
proposal attached + diff
This should not break existing ebuilds. Tested a bit and open for review
now.
next version
# @FUNCTION: _iconins
# @DESCRIPTION:
# function for use in doicon and newicon
_iconins() {
(
# wrap the env here so that the 'insinto' call
# doesn't corrupt the env of the caller
local size dir
local context=apps
local theme=hicolor
while [[ $# -gt 0 ]] ; do
case $1 in
-s|--size)
if [[ ${2%%x*}x${2%%x*} == $2 ]] ; then
size=${2%%x*}
else
size=${2}
fi
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256)
size=${size}x${size};;
scalable)
;;
*)
eerror ${size} is an unsupported icon size!
exit 1;;
esac
shift 2;;
-t|--theme)
theme=${2}
shift 2;;
-c|--context)
context=${2}
shift 2;;
*)
if [[ -z $size ]] ; then
insinto /usr/share/pixmaps
else
insinto
/usr/share/icons/${theme}/${size}/${context}
fi
if [[ $function == doicon ]] ; then
if [[ -f $1 ]] ; then
doins ${1}
elif [[ -d $1 ]] ; then
shopt -s nullglob
doins ${1}/*.{png,svg}
shopt -u nullglob
else
eerror ${1} is not a valid
file/directory!
exit 1
fi
else
break
fi
shift 1;;
esac
done
if [[ $function == newicon ]] ; then
newins $@
fi
) || die
}
# @FUNCTION: doicon
# @USAGE: doicon [options] icons
# @DESCRIPTION:
# Install icon into the icon directory /usr/share/icons or into
# /usr/share/pixmaps if --size is not set.
# This is useful in conjunction with creating desktop/menu files.
#
# @CODE
# options:
# -s, --size
#!!! must specify to install into /usr/share/icons/... !!!
#size of the icon, like 48 or 48x48
#supported icon sizes are:
#16 22 24 32 36 48 64 72 96 128 192 256 scalable
# -c, --context
#defaults to apps
# -t, --theme
#defaults to hicolor
#
# icons: list of icons
# @CODE
#
# example 1:
#doicon foobar.png fuqbar.svg
#results in: insinto /usr/share/pixmaps ; doins foobar.png fuqbar.svg
#
# example 2:
#doicon -s 48 foobar.png fuqbar.png
#results in: insinto /usr/share/icons/hicolor/48x48/apps ; doins foobar.png
fuqbar.svg
#
doicon() {
local function=$FUNCNAME
_iconins $@
}
# @FUNCTION: newicon
# @USAGE: newicon [options] icon newname
# @DESCRIPTION:
# Like doicon, install the specified icon as newname.
#
# example 1:
#newicon foobar.png NEWNAME.png
#results in: insinto /usr/share/pixmaps ; newins foobar.png NEWNAME.png
#
# example 2:
#newicon -s 48 foobar.png NEWNAME.png
#results in: insinto /usr/share/icons/hicolor/48x48/apps ; newins
foobar.png NEWNAME.png
#
newicon() {
local function=$FUNCNAME
_iconins $@
}
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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
[gentoo-dev] Re: Remove eclass/ChangeLog
On Wed, 23 May 2012 11:02:58 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 05/23/2012 05:36 AM, Ryan Hill wrote: One person doesn't do entries. OMG let's remove it! absolutely because inconsitency renderess the file useless Perfect is the enemy of good enough. Stuck in a cabin for the weekend without cvs access, it was handy enough for me. When we switch to git 4-8 years from now, then yes, kill it. Until then, leave it alone please. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 3: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. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME) I seriously cannot tell this is serious, trolling, or sarcasm. If it's either of the latter two, can we please cut that out? Way too often sarcasm and inside jokes are misunderstood and we waste a lot of bandwidth figuring it out.
[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On Wed, 23 May 2012 11:28:13 +0300 Petteri Räty betelge...@gentoo.org wrote: On 22.5.2012 8.53, Michał Górny wrote: Excuse me but the way this change was handled is a bit depressing. First, the ebuilds should have been fixed to inherit eutils and then remove eutils from autotools. Now, a bunch of ebuilds are broken out of nowhere. I don't believe this issue was that urgent in order to justify the significant breakage of portage tree. First of all, to quote devmanual: | Before updating eutils or a similar widely used eclass, it is best to | email the gentoo-dev list. It may be that your proposed change is | broken in a way you had not anticipated [...]. If you don't email | gentoo-dev first, and end up breaking something, expect to be in a | lot of trouble. Not that this disrespect for this rule is something new... Even more important is the next chapter: When removing a function or changing the API of an eclass, make sure that it doesn't break any ebuilds in the tree, and post a notice to gentoo-dev at least 30 days in advance, preferably with a patch included. This qualifies as changing the API of an eclass. This chapter comes from a council decision: http://www.gentoo.org/proj/en/council/meeting-logs/2008-summary.txt I don't see how removing an inherit is breaking an eclass' API. The functionality of the eclass itself does not change. Yes if you want to get technical you previously had access to functions from other eclasses by reaching through it, but that's a side effect that shouldn't be relied upon. If we do, then making a change to an eclass not only requires an audit of all the ebuilds using that eclass, but also any eclasses that inherit it and all of their ebuilds and so on and so forth. Ebuilds should be inheriting what they need, not relying on other eclasses to do it for them (the exception of course is meta or base type eclasses like kde, gnome, or java (i think?) that are designed to work this way). The breakage here is a perfect example how a simple change can have consequences that even a senior developer can overlook when this practice isn't followed. That said, I do think adding the eutils inherit back until people can audit their ebuilds seems like the sanest thing to do. Normally I'd say just fix your ebuilds, but I hate it when stable breaks. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
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. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH] 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
---
bin/repoman |6 +-
pym/repoman/checks.py | 143 -
pym/repoman/errors.py |1 -
3 files changed, 97 insertions(+), 53 deletions(-)
diff --git a/bin/repoman b/bin/repoman
index 3697403..d7ffcdd 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..088a916 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,104 @@ class InheritDeprecated(LineCheck):
(eclass, replacement)
del self._indirect_deprecated
-class InheritAutotools(LineCheck):
-
- Make sure appropriate functions are called in
- ebuilds that inherit autotools.eclass.
+class InheritEclass(LineCheck):
+ Base class for checking for missing inherits, as well as excess
inherits.
- 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 autotools functions.
- _exempt_eclasses = frozenset([git, subversion])
+ 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
+
Re: [gentoo-portage-dev] [PATCH] repoman: add a mini framework for checking eclasses, and fill it out
On 05/23/2012 12:21 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
It's fragile to keep all of these eclass interface definitions hardcoded
in python. For example, the _comprehensive checks are going to start
triggering repoman warnings every time that we add a new function to an
eclass. If we keep the eclass interface definitions in the tree with the
eclasses, then it will solve this problem, and it will also be possible
for overlays to fork eclasses and tweak interfaces.
def new(self, pkg):
- self._inherit_autotools = None
- self._autotools_func_call = None
- self._disabled =
self._exempt_eclasses.intersection(pkg.inherited)
+ self.repoman_check_name = 'inherit.missing'
+ self._inherit_re = re.compile(r'^\s*inherit\s(.*\s)?%s(\s|$)' %
self._eclass)
+ self._func_re = re.compile(r'\b(' + '|'.join(self._funcs) +
r')\b')
The _inherit_re and _func_re regular expressions do not change from one
package to the next, so we can compile them inside the __init__
constructor instead, which is only called once in global scope.
+ # We can't use pkg.inherited because that tells us all the
eclass that
+ # have been inherited and not just the ones we inherit directly.
+ self._inherit = False
+ self._func_call = False
+ if '_exempt_eclasses' in dir(self):
+ self._disabled =
self._exempt_eclasses.intersection(pkg.inherited)
+ else:
+ self._disabled = False
It's more efficient to use hasattr(self, '_exempt_eclasses') than to use
'_exempt_eclasses' in dir(self).
--
Thanks,
Zac
Re: [gentoo-portage-dev] [PATCH] repoman: add a mini framework for checking eclasses, and fill it out
On Wednesday 23 May 2012 15:21:51 Mike Frysinger wrote:
+ self._inherit_re = re.compile(r'^\s*inherit\s(.*\s)?%s(\s|$)' %
in scanning the whole tree, this seems to cause some issues (not new) with
extended constructs and not detecting this ebuilds inherits an eclass
directly. some examples:
(1)
foo=autotools
...
inherit ${foo}
this seems pointless imo since we've already ruled that multiple `inherit`
calls are OK
(2)
inherit ... \
autotools
this is annoying. maybe we should adapt the core line code to unroll these
before passing to the individual checks ?
(3)
[[ ${PV} == ]] inherit autotools
this one would require tweaking the regex like so:
(^[[:space:]]*|[[:space:]])inherit
any opinions ?
-mike
signature.asc
Description: This is a digitally signed message part.
