Re: [gentoo-dev] Resolution - GTK Useflag Situation
Hello. On Пнд, 2005-09-19 at 20:24 +0900, Chris White wrote: I think the problem here isn't about choice, but support. Mainly deprication is the issue here. GTK2 was meant to be an upgrade of GTK1 interfaces. At some point upstream is going to have to giveup and say Sorry sam, use gtk2 or we can't support you (Who knows, maybe that's already happened). This already happened. I was forced to move from gtk+-1 when one day after xorg update all russian letters in program's interface became unreadable. I've searched mailing lists, forums but no solution there. Then I posted bug upstream [1]. The answer was that gtk+-1 is unsupported... Thus. The idea to keep linux small is very attractive, but gtk+-1 library is not the variant until somebody continues to support it. Links: [1] http://bugzilla.gnome.org/show_bug.cgi?id=169178 Peter. signature.asc Description: This is a digitally signed message part
[gentoo-dev] UK Linux Expo
All, This is a gentle reminder that the UK Linux Expo is on 5th-6th October at Olympia, London. Gentoo will have a (small) booth at the expo, so if you are interested in being in the booth (dev's only I'm afraid) please let me know. I will be drawing up a rota on Wednesday, so if you've not replied by email or IRC by then, you will struggle to get a time slot to strut your funky stuff in the booth. I will chase those people who have previously told me that they would be going. Hardware wise we will have a Dual Xeon on loan from a kind user, cryos's laptop and possible a mac-mini. That's probably all that will fit on the stand anyway so that should be plenty. If dev's would like to bring their own laptops to show off while on the stand, that's fine (good in fact, more variety). Please bear in mind that it will be your responsibility to look after them while you are not in the booth. There will not be anywhere for you to leave them at the booth. There will be no network connection to the booth. We will hopefully have a full distfiles mirror on the Dual Xeon though, so we can still demo emerge. Any questions/problems, let me know. Cheers, Rob -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 23:51, Mike Frysinger wrote: that's the problem, there's no way to flag which packages should be consulted and which ones are a non-issue This indeed kind of sums up my point. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpUE5zyvN9HR.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 22:24, Mark Loeser wrote: Mike Frysinger wrote: On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote: The reason for me adding that bit is the metadata from dev-cpp: The dev-cpp category contains libraries and utilities relevant to the c++ programming language. Now to me, that means I can find *all* relevant C++ stuff here. If we don't want that to be the case, maybe we should say miscellaneous, but why should something be in dev-libs, as compared with dev-cpp? net-libs, I could understand, and dev-games, as those could be argued to have a direct relation. for generic C++ packages (STLport/boost for example), i can see them being in the dev-cpp category ... but for packages which have specific uses already and arent in 'generic' categories, i dont think they should be moved I agree with this, but I think dev-libs and dev-util are generic categories, and moving these packages from there would help users in finding what they need. I think this is what you are saying atleast :) I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpzqRee7apvu.pgp Description: PGP signature
Re: [gentoo-dev] The tree is now utf-8 clean
On Saturday 17 September 2005 22:06, Mike Frysinger wrote: On Saturday 17 September 2005 01:15 pm, Ciaran McCreesh wrote: On Sat, 17 Sep 2005 12:56:37 +0200 Fernando J. Pereda [EMAIL PROTECTED] wrote: | On Sat, Sep 17, 2005 at 02:42:09AM +0100, Ciaran McCreesh wrote: | | Something strange I noticed... Some people are using funny quotes | | and non breaking spaces in ebuilds. Some people are using weird | | characters as substitution delimiters for sed. Don't! It will | | break on many systems. I'm going to go and purge all of those, | | UTF-8 or not, whenever my brain recovers. | | I hope ~ is not considered a weird character... if it is, tell me | and I'll fix all my ebuilds. No, ~ is fine. Anything with a value below 127 (don't use 127, it's weird) that sed accepts is ok. in other words, ASCII characters are OK. if in doubt, just run `man ascii` and see if your character is in the table You probably don't want to use the ascii control characters either (anything below 32), although they should not give issues with people they could cause havoc for terminals or annoy people (using the BELL character as sed separator). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgptLTrYB92Ee.pgp Description: PGP signature
Re: [gentoo-dev] The tree is now utf-8 clean
maillog: 19/09/2005-11:52:26(+0200): Paul de Vrieze types On Saturday 17 September 2005 22:06, Mike Frysinger wrote: On Saturday 17 September 2005 01:15 pm, Ciaran McCreesh wrote: On Sat, 17 Sep 2005 12:56:37 +0200 Fernando J. Pereda [EMAIL PROTECTED] wrote: | On Sat, Sep 17, 2005 at 02:42:09AM +0100, Ciaran McCreesh wrote: | | Something strange I noticed... Some people are using funny quotes | | and non breaking spaces in ebuilds. Some people are using weird | | characters as substitution delimiters for sed. Don't! It will | | break on many systems. I'm going to go and purge all of those, | | UTF-8 or not, whenever my brain recovers. | | I hope ~ is not considered a weird character... if it is, tell me | and I'll fix all my ebuilds. No, ~ is fine. Anything with a value below 127 (don't use 127, it's weird) that sed accepts is ok. in other words, ASCII characters are OK. if in doubt, just run `man ascii` and see if your character is in the table You probably don't want to use the ascii control characters either (anything below 32), although they should not give issues with people they could cause havoc for terminals or annoy people (using the BELL character as sed separator). Um, I guess everybody got the point. In fact, you probably shouldn't use alphanumerics either -- they work, but are as ugly as... echo herr | sed -e sorolog -- (* Georgi Georgiev (* They can always run stderr through uniq. :-) (* *)[EMAIL PROTECTED]*) -- Larry Wall in *) (* +81(90)2877-8845 (* [EMAIL PROTECTED] (* pgpg5sCWkN0mw.pgp Description: PGP signature
Re: [gentoo-dev] Resolution - GTK Useflag Situation
On Sun, Sep 18, 2005 at 03:48:43PM +, John N. Laliberte wrote: * but you are taking away choice! - If a program has both GTK2 and GTK3 interfaces, there are many ways to allow for testing of the experimental interface. For instance, package.mask with a revision number. package.mask isn't a perfect fit from where I sit; if it's already merged (say for development), but the developer has masked gtk-3, all pkgs that prefer gtk-3 will continue linking against it till gtk-3 is unmerged regardless of the masking. Part of the reason I prefer use flags here; aside from that, use flags aren't features, strictly conditionals (intentionally vague) :) * use the proper, built in methods for this: add =x11-libs/gtk+-1* to /etc/portage/package.mask. If merged, need to unmerge it to block any further linking to it if using || () deps. Issues above aren't blockers at all, just pointing it out since it does have a minor downside, one that should be mentioned in any documentation that tells people how to migrate from gtk(N-1) to gtkN. There are some downsides that should probably be made clear. ~harring pgpyaKMH69fBY.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resolution - GTK Useflag Situation
On Mon, 2005-09-19 at 07:28 -0500, Brian Harring wrote: On Sun, Sep 18, 2005 at 03:48:43PM +, John N. Laliberte wrote: * but you are taking away choice! - If a program has both GTK2 and GTK3 interfaces, there are many ways to allow for testing of the experimental interface. For instance, package.mask with a revision number. package.mask isn't a perfect fit from where I sit; if it's already merged (say for development), but the developer has masked gtk-3, all pkgs that prefer gtk-3 will continue linking against it till gtk-3 is unmerged regardless of the masking. For an example to illustrate what John meant by using package.mask, assuming gtk-3 is masked, and we have an appfoo with a default gtk-2 interface and an experimental gtk-3 interface. The un-package.masked ebuilds will always build against gtk-2, as that'd be the designated interface by the developer. By always build against, I mean gtk-2 would be the default interface - so it'd specify --enable-gtk2/--disable-gtk3 or explicitly not use automagic to detect gtk-3 and always use gtk-2. We could have a package.mask'ed appfoo-rX ebuild that builds with the gtk-3 interface as it becomes more mature. This is sort of an extension of developer knows best when choosing which gtk+ interface to make the default. Mike Gardiner (Obz) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords
Anthony Gorecki posted [EMAIL PROTECTED], excerpted below, on Mon, 12 Sep 2005 01:09:34 -0700: On Sunday, September 11, 2005 20:42, Daniel Ahlberg wrote: The page shows results from a number of tests that are run against the ebuilds. Why does this script no longer include the results in the actual message? It was helpful to have both as a reference source. Well, the idea was helpful, but (as an amd64 user) I'm not entirely sure the implementation was all that helpful. The problem was due to the non-x86 imlate tracking. Unfortunately, it didn't work right, with the result normally meaning the top-10 spots as listed in the message, were all ~amd64 entries where ~arch (for some arch, normally x86) had been added several hundred days earlier (before there /was/ a Gentoo amd64 arch, AFAIK), because it had no way of tracking when the ~amd64 keyword was added, and incorrectly assumed that the package had been ~amd64 since the package was keyworded ~arch for /one/ arch at that point. As one of the newer and more active archs, just then adding ~arch for the first time to many apps, this was particularly frustrating for amd64, since it left the impression the amd64 arch-team were a bunch of slackers (no offense to slackware folks) that left packages in ~arch for hundreds of days at a time, for little reason. So... if the script now ignores that factor, at least when calculating the top-10, or if it has been fixed to correct the issue (a non-trivial task, someone remarked at one point, because the info wasn't directly available), and assuming there are no other such spammer factors, it /could/ be /very/ useful. However, personally, at least, I'd /not/ like to see it return in the broken state it was in, as I can't imagine that being anything but frustration, to those responsible for the ebuilds wrongly listed, due to a broken script. (Not that my personal opinion means a lot as just a user, on a dev list, but FWIW, whatever /that/ may be.) -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] UK Linux Expo
On Monday 19 September 2005 10:14, Rob Holland wrote: This is a gentle reminder that the UK Linux Expo is on 5th-6th October at Olympia, London. Gentoo will have a (small) booth at the expo, so if you are interested in being in the booth (dev's only I'm afraid) please let me know. I just wanted to add that I am organising key signing at this years UK Linux Expo. This was quite successful at FOSDEM earlier this year, and I have quite a few signatures from European devs, as well as kingtaco's who came over for the conference from the States. I have shamelessly borrowed the page Marc Hildebrand prepared for FOSDEM, and would like to encourage all devs in attendance to take part. It would also be nice to sign keys with users if they would like to. The instructions are here, http://dev.gentoo.org/~cryos/keysigning_lwe_05.html I will be in London Tuesday night to Thursday night, travelling back up t' North that evening. Hope to see lots of you there - I am taking my new toys with my too as Rob mentioned. My Fuji F10 will be with me at all times to get a few photos of the event. Thanks, Marcus -- Gentoo Linux Developer Scientific Applications | AMD64 | KDE | net-proxy pgpIRlqGupGko.pgp Description: PGP signature
[gentoo-dev] cvs keywording.
Official policy states that CVS ebuilds should never be marked stable[1]. Yet many ebuilds that are based on cvs sources and are marked stable on arch's. I would like to know why this is so. ./net-misc/netcomics-cvs/netcomics-cvs-0.14.1.ebuild:KEYWORDS=x86 ~amd64 ./games-fps/blackshades-cvs/blackshades-cvs-20031110.ebuild:KEYWORDS=x86 ~ppc ~amd64 ./dev-embedded/sdcc-cvs/sdcc-cvs-2.4.0-r1.ebuild:KEYWORDS=x86 ~ppc amd64 ./games-fps/avp-cvs/avp-cvs-20031110.ebuild:KEYWORDS=x86 This was just a hacked up search I did on the tree while in class, and is no way inclusive of all packages breaking policy. If you want bugs for them, I 'll make them. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resolution - GTK Useflag Situation
On Sun, 18 Sep 2005 15:48:43 + (UTC) John N. Laliberte [EMAIL PROTECTED] wrote: How to keep gtk1 off of your system: * use the proper, built in methods for this: add =x11-libs/gtk+-1* to /etc/portage/package.mask. Since this may not be that easy for the end-user (lots of ebuilds to avoid or to package.use), i've put an attempt of more detailed instructions here: http://gentoo-wiki.com/HOWTO_Get_rid_of_GTK_1.x I would not be against a second look at it if someone has time to read it, just to check it makes sense. Thanks, -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cvs keywording.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: Official policy states that CVS ebuilds should never be marked stable[1]. Yet many ebuilds that are based on cvs sources and are marked stable on arch's. I would like to know why this is so. ./net-misc/netcomics-cvs/netcomics-cvs-0.14.1.ebuild:KEYWORDS=x86 ~amd64 ./games-fps/blackshades-cvs/blackshades-cvs-20031110.ebuild:KEYWORDS=x86 ~ppc ~amd64 ./dev-embedded/sdcc-cvs/sdcc-cvs-2.4.0-r1.ebuild:KEYWORDS=x86 ~ppc amd64 ./games-fps/avp-cvs/avp-cvs-20031110.ebuild:KEYWORDS=x86 This was just a hacked up search I did on the tree while in class, and is no way inclusive of all packages breaking policy. If you want bugs for them, I 'll make them. [1] http://devrel.gentoo.org/handbook/handbook.xml?part=2chap=3#doc_chap1_sect9 ;-) - -- Alin DOBRE Romanian Lead Translator Gentoo Documentation Project: http://www.gentoo.org/doc/en/ Gentoo.RO Community: http://www.gentoo.ro/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDLvesmG51ym6Hu9gRAhPdAKCrID8Dit2/XsitxYl9gWDZy2AqeQCeP0nd FRSrdBcQHAd2p32oMsqeCV0= =569V -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cvs keywording.
On Mon, 2005-09-19 at 20:38 +0300, Alin Dobre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: Official policy states that CVS ebuilds should never be marked stable[1]. Yet many ebuilds that are based on cvs sources and are marked stable on arch's. I would like to know why this is so. ./net-misc/netcomics-cvs/netcomics-cvs-0.14.1.ebuild:KEYWORDS=x86 ~amd64 ./games-fps/blackshades-cvs/blackshades-cvs-20031110.ebuild:KEYWORDS=x86 ~ppc ~amd64 ./dev-embedded/sdcc-cvs/sdcc-cvs-2.4.0-r1.ebuild:KEYWORDS=x86 ~ppc amd64 ./games-fps/avp-cvs/avp-cvs-20031110.ebuild:KEYWORDS=x86 This was just a hacked up search I did on the tree while in class, and is no way inclusive of all packages breaking policy. If you want bugs for them, I 'll make them. [1] http://devrel.gentoo.org/handbook/handbook.xml?part=2chap=3#doc_chap1_sect9 ;-) The two games listed are CVS snapshots, not live CVS builds. A live CVS build should never be stable. A snapshot is a known set of files, and can be marked stable. It is usually a known-good working set of files, taken from CVS, but not tied to an actual release version, and added to our mirrors by the package maintainers. -- Chris Gianelloni Release Engineering - Strategic Lead Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Pending removal of app-arch/gzip-x86
I'm masking app-arch/gzip-x86 as we speak. It seems to cause problems for people[1] and is based off of gzip-1.3.3. As such, it is vulnerable to a couple[2] exploits[3]. Upstream appears dead (last update was 2003-05-20) and no one is currently maintaining it for us. If you don't want to see it go, speak up, or it will be gone in 30 days. Mark [1] https://bugs.gentoo.org/show_bug.cgi?id=104355 [2] http://www.gentoo.org/security/en/glsa/glsa-200505-05.xml [3] http://www.gentoo.org/security/en/glsa/glsa-200406-18.xml signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Monday 19 September 2005 15:22, warnera6 wrote: Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. and what's *your* certain proposal then? pgpYUgBMZbynY.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types On Monday 19 September 2005 15:22, warnera6 wrote: Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. and what's *your* certain proposal then? That's been discussed a number of times already. The best idea is to leave the categories alone and forget that the category means anything. Or, to throw the ball back in your court, could *you* suggest alternatives that accomplish the following: (quoting [1]:) More precisely, what I'd like to see, in order of preference, is - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed - the net-wireless/gnome-phone-manager that I have in my overlay to work for as long as needed - my net-wireless/gnome-phone-manager binary packages to work without having to be fixpackaged - the location of the ebuilds for net-wireless/gnome-phone-manager to stay in the same physical path on my filesystem end quote I would grade the above features as vital, badly needed, happy to see it done, cosmetic. I.e., even solving only the first one is enough, though if you could get to number two it would be better. 1: http://groups.google.com/group/linux.gentoo.dev/tree/browse_frm/thread/26b3b93fe16de00c/3ffe93800adbc578?fwc=1#o3ffe93800adbc578 -- /\ Georgi Georgiev /\ Vulcans never bluff. -- Spock, The Doomsday /\ \/[EMAIL PROTECTED]\/ Machine, stardate 4202.1\/ /\ +81(90)2877-8845 /\ /\ pgpChTvi247OB.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object
On Saturday 17 September 2005 02:32, Alec Warner wrote: Jason Stubbs wrote: On Saturday 17 September 2005 01:59, Paul Varner wrote: http://bugs.gentoo.org/show_bug.cgi?id=90680 Author: Paul Varner The current implementation of gentoolkit creates a portage.config object for every package object that it creates. While this is the correct thing to do from an object-oriented programming point of view, this implementation consumes an excessive amount of memory and CPU. The proposed patch changes the portage.config object for each package object to point to a single global object. If no one sees any serious issues with the patch, I will be placing it into gentoolkit. I tried doing this once before locally, but found some issue with it. Unfortunately, I can't remember what that issue was. If you are calling setcpv() for every call to the package object that utilizes the config object and no utilizing packages (in gentoolkit or otherwise) are utilizing threading, it should theoretically be okay. Actually, I think it was the threading issue that delayed the fix. I can't remember the model for this, but there is some logic along the lines of intercepting config object writes with setattr and then cloning the config object. That way if the config is read-only only 1 is instantiated, but if you attempt to modify it, the config would clone itself, then proceed with the modification and return the cloned copy. Not sure how easy that would be to implement, perhaps some sort of wrapper class? To share such an object the right way from an OO perspective would require to pass the object along at package object instanciation. I doubt though that the config object should be modified. But if it must in some cases a lazy copy scheme is probably most efficient. You'd probably have the editing code do something like: this-editableConfig()-changeAttribute(...) Where the editableConfig function checks whether a copy has been made, if so, it will just use that copy, else it will make a copy and return it. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpDlxwohvwF2.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object
On Monday 19 September 2005 10:26, Jason Stubbs wrote: On Monday 19 September 2005 17:18, Paul de Vrieze wrote: I doubt though that the config object should be modified. The Package object needs to call setcpv() on the config object to get at the per-package USE flags after they have been stacked. But if it must in some cases a lazy copy scheme is probably most efficient. Unfortunately not in this case. There would either be one config instance (for processes that don't deal with USE flags) or as many config instances as there are packages (for processes that do). Should probably read the source a bit but you're completely right of course. The only thing that could be done for this is splitting up the object, or having it do internal sharing of shared things. Or to make it clear, it is not some cases, but almost all cases. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgplfCFHSRRMu.pgp Description: PGP signature
[gentoo-portage-dev] PATCH glep31 checking
Hola.
http://glep.gentoo.org/glep-0031.html-- the details
http://bugs.gentoo.org/106544-- the bug
http://bugs.gentoo.org/attachment.cgi?=68828 -- the patch
Attached the patch also; one additional tweak is that file.size is now
a fatal check, since the tree seem's to finally be clean.
~harring
Index: repoman
===
--- repoman (revision 1992)
+++ repoman (working copy)
@@ -13,6 +13,13 @@
sys.path = [/usr/lib/portage/pym]+sys.path
version=1.2
+allowed_filename_chars=a-zA-Z0-9._-+:
+allowed_filename_chars_set = {}
+map(allowed_filename_chars_set.setdefault, map(chr, range(ord('a'),
ord('z')+1)))
+map(allowed_filename_chars_set.setdefault, map(chr, range(ord('A'),
ord('Z')+1)))
+map(allowed_filename_chars_set.setdefault, map(chr, range(ord('0'),
ord('9')+1)))
+map(allowed_filename_chars_set.setdefault, map(chr, map(ord, [., -, _,
+, :])))
+
import string,signal,re,pickle,tempfile
import portage
@@ -21,6 +28,8 @@
import portage_dep
import cvstree
import time
+import codecs
+
from output import *
#bold, darkgreen, darkred, green, red, turquoise, yellow
@@ -85,6 +94,8 @@
filedir.missing:Package lacks a files directory,
file.executable:Ebuilds, digests, metadata.xml, Manifest, and
ChangeLog do note need the executable bit,
file.size:Files in the files directory must be under 20k,
+ file.name:File/dir name must be composed of only the following
chars: %s % allowed_filename_chars,
+ file.UTF8:File is not UTF8 compliant,
KEYWORDS.missing:Ebuilds that have a missing KEYWORDS variable,
LICENSE.missing:Ebuilds that have a missing LICENSE variable,
DESCRIPTION.missing:Ebuilds that have a missing DESCRIPTION
variable,
@@ -146,7 +157,6 @@
IUSE.invalid,
ebuild.minorsyn,
ebuild.badheader,
-file.size,
metadata.missing,
metadata.bad,
virtual.versioned
@@ -663,6 +673,29 @@
stats[file.executable] += 1
fails[file.executable].append(checkdir+/+y)
digestlist=[]
+
+ for y in checkdirlist:
+ for c in y.strip(os.path.sep):
+ if c not in allowed_filename_chars_set:
+ stats[file.name] += 1
+ fails[file.name].append(%s/%s: char '%s' %
(checkdir, y, c))
+ break
+
+ if not (y in (ChangeLog, metadata.xml) or
y.endswith(.ebuild)):
+ continue
+ try:
+ line = 1
+ for l in codecs.open(y, r, utf8):
+ line +=1
+ except UnicodeDecodeError, ue:
+ stats[file.UTF8] += 1
+ s = ue.object[:ue.start]
+ l2 = s.count(\n)
+ line += l2
+ if l2 != 0:
+ s = s[s.rfind(\n) + 1:]
+ fails[file.UTF8].append(%s/%s: line %i, just after:
'%s' % (checkdir, y, line, s))
+
if isCvs:
try:
mystat=os.stat(checkdir+/files)[0]
@@ -799,6 +832,13 @@
stats[file.size] += 1
fails[file.size].append((+
str(mystat.st_size/1024) + K) +x+/files/+y)
+ for c in y.strip(os.path.sep):
+ if c not in allowed_filename_chars_set:
+ stats[file.name] += 1
+ fails[file.name].append(%s/%s: char
'%s' % (checkdir, y, c))
+ break
+
+
if ChangeLog not in checkdirlist:
stats[changelog.missing]+=1
fails[changelog.missing].append(x+/ChangeLog)
pgpoxv44vqNjL.pgp
Description: PGP signature
Re: [gentoo-portage-dev] PATCH glep31 checking
On Mon, Sep 19, 2005 at 04:12:08PM -0500, Brian Harring wrote: Attached the patch also; one additional tweak is that file.size is now a fatal check, since the tree seem's to finally be clean. Dropped the file.size becoming fatal change on the bug, and intend to for the final version. Either tweak the patch yourself, or gank it from the bug... it's a one line reversion. :) Pls test, kthx. ~harring pgpSn9miVa1jT.pgp Description: PGP signature
