Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Drake wrote: Hi, The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? Additional testing of this change would be appreciated (just ensure that nothing breaks). To do it as a one off: # mount -o remount,nosuid,noexec /proc To make it more permanent, /etc/fstab has: proc/procprocdefaults0 0 Change to: proc/procprocnosuid,noexec0 0 Is there an open bug or security advisory for this exploit I missed? I tried the CLI solution; works just fine here. No wild behavior so far. Any suggestions on what to look for, or how to really hammer /proc? :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEufPcrsJQqN81j74RAjHhAJ9wbrRi/h8b603Ra8W6F5uk0biDVACcCy62 WX+lVNRJoJNTLAG2wxg9Mlc= =RVRq -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
On Sunday 16 July 2006 10:07, Josh Saddler wrote: Daniel Drake wrote: Hi, The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? Additional testing of this change would be appreciated (just ensure that nothing breaks). To do it as a one off: # mount -o remount,nosuid,noexec /proc To make it more permanent, /etc/fstab has: proc/procprocdefaults0 0 Change to: proc/procprocnosuid,noexec0 0 Is there an open bug or security advisory for this exploit I missed? I tried the CLI solution; works just fine here. No wild behavior so far. Any suggestions on what to look for, or how to really hammer /proc? :) There is bug #140444. -- Christian Heim [EMAIL PROTECTED] Gentoo Linux Developer You're friendly kernel/vserver/openvz monkey pgprzHAECSrPq.pgp Description: PGP signature
[gentoo-dev] Re: GCC 4.1.1 testing/stablization and glibc 2.4
Chris Gianelloni wrote: On Sat, 2006-07-01 at 12:18 -0600, Ryan Hill wrote: Should arch testers start working with 4.1.1 then? And do you want bugs to block #117482? Arch testers should contact their architecture's leads or Release Engineering Architecture Coordinator. As for bug reports, yes. Just an update - I've finished most major desktop stuff for x86 without any problems. I'm moving onto stuff that's already on the tracker and is fixed in testing but not stable. Rather than open and track a ton of new bugs, I'd like to reopen the original ~arch bugs and request a backport or stabilization at the maintainer's discretion. Is this okay, or would people rather get a shiny new bug? Keep in mind there are already 290 bugs on the tracker. Alternatively, would it be better to just start a new tracker bug for stabilization? https://bugs.gentoo.org/show_bug.cgi?id=117482 --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
Ned Ludd [EMAIL PROTECTED] wrote: Not 100% sure about the noexec part as that might break upx which calls /proc/self/exe as part of it's decompresser routines. /proc/self/exe is a symlink, and the permissions of symlinks aren't used for anything. It's less than trivial (and I think impossible) to set them to anything but 0777. In any case, the noexec option only affects regular files. Directories, for example, also keep their execute flags. -- Batou: Hey, Major... You ever hear of human rights? Kusanagi: I understand the concept, but I've never seen it in action. --Ghost in the Shell pgpcnpS4G3iIn.pgp Description: PGP signature
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
On Sat, 2006-07-15 at 15:20 -0400, Mike Frysinger wrote: On Saturday 15 July 2006 13:41, Ned Ludd wrote: On Sat, 2006-07-15 at 17:45 +0100, Daniel Drake wrote: The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? I mailed Mike about this very thing a month ago. Pretty sure it should be showing up in an upcoming baselayout. But yeah it's a good idea for the nosuid part anyway. Not 100% sure about the noexec part as that might break upx which calls /proc/self/exe as part of it's decompresser routines. this will be in baselayout-1.12.2+ Great. I'm guessing I should artificially bump 1.12.1 with a revision in my snapshot for 2006.1 or we'll end up not having fixed much. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: GCC 4.1.1 testing/stablization and glibc 2.4
(apologies in advance if this goes through twice) Chris Gianelloni wrote: On Sat, 2006-07-01 at 12:18 -0600, Ryan Hill wrote: Should arch testers start working with 4.1.1 then? And do you want bugs to block #117482? Arch testers should contact their architecture's leads or Release Engineering Architecture Coordinator. As for bug reports, yes. Just an update - I've finished most major desktop stuff for x86 without any problems. I'm moving onto stuff that's already on the tracker and is fixed in testing but not stable. Rather than open and track a ton of new bugs, I'd like to reopen the original ~arch bugs and request a backport or stabilization at the maintainer's discretion. Is this okay, or would people rather get a shiny new bug? Keep in mind there are already 290 bugs on the tracker. Alternatively, would it be better to just start a new tracker bug for stabilization? https://bugs.gentoo.org/show_bug.cgi?id=117482 --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] pybugz - python command line interface to bugzilla
Hi All, As a little weekend project, I wrote a command line interface to bugzilla in Python that is targetted to Gentoo's bugzilla (but also generalisable to other bugzillas with a little code modification). It can do the following: * search bugzilla and output a table of bugs: bugz search keyword * list bug details (incl comments and attachment): bugz get bugid * get attachments: bugz attachment attachid * post attachments: bugz attach bugid filename * modify bug: bugz modify bugid -c here is a new comment --fixed I know there's gentoo-bugger, which is great, but it's in perl and I couldn't figure out how to modify the output to suit my needs. Here's the README attached if you're interested in how it might work for you to become more efficient when dealing with Gentoo's Bugzilla. You can get it either via my portage overlay in: http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz or as a python distutils compat tarball in http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz Hope maybe some people might find it useful. Cheers, Alastair PyBugz - Python Bugzilla Interface -- Bugzilla has a very inefficient user interface, so I've written a command line utility to interact with it. This is mainly done to help me with closing bugs on Gentoo Bugzilla by grabbing patches, ebuilds and so on. Author -- Alastair Tse [EMAIL PROTECTED]. Copyright (c) 2006 under GPL-2. Features * Searching bugzilla * Listing details of a bug including comments and attachments * Downloading/viewing attachments from bugzilla * Posting comments, and making changes to an existing bug. * Adding attachments to a bug. Usage/Workflow -- PyBugz comes with a command line interface called bugz. It's operation is similar in style to cvs/svn where a subcommand is required for operation. To explain how it works, I will use a typical workflow for Gentoo development. 1) Searching bugzilla for bugs I can fix, I'll run the command: --- $ bugz search version bump --assigned [EMAIL PROTECTED] * Using http://bugs.gentoo.org/ .. * Searching for version bump ordered by number 101968 liquidx net-im/msnlib version bump 125468 liquidx version bump for dev-libs/g-wrap-1.9.6 130608 liquidx app-dicts/stardict version bump: 2.4.7 2) Narrow down on bug #101968, I can execute: - $ bugz get 101968 * Using http://bugs.gentoo.org/ .. * Getting bug 130608 .. Title : app-dicts/stardict version bump: 2.4.7 Assignee: [EMAIL PROTECTED] Reported: 2006-04-20 07:36 PST Updated : 2006-05-29 23:18:12 PST Status : NEW URL : http://stardict.sf.net Severity: enhancement Reporter: [EMAIL PROTECTED] Priority: P2 Comments: 3 Attachments : 1 [ATTACH] [87844] [stardict 2.4.7 ebuild] [Comment #1] [EMAIL PROTECTED] : 2006-04-20 07:36 PST ... 3) Now this bug has an attachment submitted by the user, so I can easily pull that attachment in: - $ bugz attachment 87844 * Using http://bugs.gentoo.org/ .. * Getting attachment 87844 * Saving attachment: stardict-2.4.7.ebuild 4) If the ebuild is suitable, we can commit it using our normal repoman tools, and close the bug. --- $ bugz modify 130608 --fixed -c Thanks for the ebuild. Committed to portage or if we find that the bug is invalid, we can close it by using: $ bugz modify 130608 --invalid -c Not reproducable Other options - There is extensive help in `bugz --help` and `bugz subcommand --help` for additional options. bugz.py can be easily adapted for other bugzillas by changing BugzConfig to match the configuration of your target bugzilla. However, I haven't spent much time on using it with other bugzillas out there. If you do have changes that will make it easier, please let me know.
Re: [gentoo-dev] pybugz - python command line interface to bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alastair Tse wrote: Hi All, As a little weekend project, I wrote a command line interface to bugzilla in Python that is targetted to Gentoo's bugzilla (but also generalisable to other bugzillas with a little code modification). It can do the following: * search bugzilla and output a table of bugs: bugz search keyword * list bug details (incl comments and attachment): bugz get bugid * get attachments: bugz attachment attachid * post attachments: bugz attach bugid filename * modify bug: bugz modify bugid -c here is a new comment --fixed I know there's gentoo-bugger, which is great, but it's in perl and I couldn't figure out how to modify the output to suit my needs. Here's the README attached if you're interested in how it might work for you to become more efficient when dealing with Gentoo's Bugzilla. You can get it either via my portage overlay in: http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz or as a python distutils compat tarball in http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz Hope maybe some people might find it useful. Cheers, Alastair Very cool. you might want to send it to the app-accessability group as well; I'm sure blind people would love to have a CLI interface. - -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iQCVAwUBRLpdtoBrouQZ9K4FAQIMdwQApY0NdHdQ23DGYopgrw9k9g+pETzvQi5A J0/BcDcxsvM6SJOawm/JL6WETZ9hnPbjPC9yHTHKlKXhKGdbSjcLmc6De0yCDaVD UwGbrbwy+iCtn04oUWgwUIAjYTcOgxhP+JSfp/+Az0Cs1L4vumx1mcMtlq1cpUem bBEipB6iGTs= =lFML -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Yet Another Victim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm happy to announce a new addition to the perl team (no, not that kind of addition - Dr. says that's in September folks;). You may know him from such bugzilla favorites as libeperl dies on `awk` and libwww-perl has incorrect RDEPEND, or under his old guise on irc as samhain1138. Yuval (now on irc as the quaint yuval) joins us from somewhere north of the antartic, has been working with perl for over 7 years both professionally (and not), and just finished up a beer drinking tour of belgium to help prepare him for the volume of mail on this list. So let's all give it up for yuval! - -- - -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E - -o()o-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEumyNq1ztTp5/Ti4RAt3uAJ97mHlygA4gmRscH/k9J5x0YWXdKACeKjJR yqYLz5HzWR+q3qJC/yWphdk= =Uqwv -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [gentoo dev]suggestion to distutils eclass
Some packages don't provide standard setup.py. Take a look at the attachment.This is a new ebuld.So my suggestion is to add a new variable to distutils.eclass, e.g. SETUP.PY, if it's set, then use it, otherwise let it defaults to setup.py.Looking forward to hear your feedback on this.-- Zhang Le, RobertLinux Engineer/Trainerhttp://zhllg.spaces.msn.com http://zh.gentoo-wiki.comhttp://savannah.nongnu.org/projects/pgubookhttp://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug jToolkit-0.7.8.ebuild Description: Binary data
Re: [gentoo-dev] Yet Another Victim
Welcome, Yuval! :D -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo dev]suggestion to distutils eclass
Zhang Le wrote: Some packages don't provide standard setup.py. Take a look at the attachment. This is a new ebuld. So my suggestion is to add a new variable to distutils.eclass, e.g. SETUP.PY, if it's set, then use it, otherwise let it defaults to setup.py. what about making a simple symlink then? This will avoid more code in a general eclass for only very few cases. You can also report this upstream and get them to rename the setup script. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pybugz - python command line interface to bugzilla
Alastair Tse wrote: You can get it either via my portage overlay in: http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz or as a python distutils compat tarball in http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz Cool! Any reason why not commit it - at least package.masked? ;) Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] pybugz - python command line interface to bugzilla
On Sun, 2006-07-16 at 20:33 +0200, Jakub Moc wrote: Alastair Tse wrote: You can get it either via my portage overlay in: http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz or as a python distutils compat tarball in http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz Cool! Any reason why not commit it - at least package.masked? ;) None really, except I don't like committing my own code to the tree. But I do plan to commit it to the tree once I iron out any bugs there are out of it. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Yet Another Victim
Welcome yuval. Regards, Roy bamford -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: pybugz - python command line interface to bugzilla
Alastair Tse wrote: I know there's gentoo-bugger, which is great, but it's in perl and I couldn't figure out how to modify the output to suit my needs. yeah gentoo-bugger was interactive, this one is better :) I really like it, thank you. Here's the README attached if you're interested in how it might work for you to become more efficient when dealing with Gentoo's Bugzilla. I am sure it will make us all more productive! You can get it either via my portage overlay in: http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz or as a python distutils compat tarball in http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz I would love to see this in the portage tree. If you need an ebuild maintainer just tell me :) Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
On Monday 10 July 2006 01:51, Ryan Hill wrote: No, that would be a major pain in the ass for anyone wanting to use -fast-math, which does have legitimate uses. I want to pose here that -ffast-math has NO LEGITIMATE use as a global CFLAG. In some apps it doesn't matter as they don't use math. For others it is fatal. If users want to use it on a particular app, they better use /etc/portage/bashrc. 2) If yes, are there any other flags that ebuilds should die on ? There's a million, and they're constantly changing. For example, -frename-registers is generally safe on GCC 3.4, broken in 4.0, and enabled by default on 4.1. The flags that would apply are those that break apps because their use is broken. Not because the particular compiler is broken in this instance. Users playing with CFLAGS get to keep the pieces. Trying to dummy-proof the system doesn't help anyone but the dummies. ;) I don't mind that much not doing anything with -ffast-math, but filtering it out should not be done. It is a broken flag. Filtering it out gives the message that it isn't unsafe to use. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjjfx3jbrN6.pgp Description: PGP signature
Re: [gentoo-dev] Yet Another Victim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Cummings wrote: I'm happy to announce a new addition to the perl team (no, not that kind of addition - Dr. says that's in September folks;). You may know him from such bugzilla favorites as libeperl dies on `awk` and libwww-perl has incorrect RDEPEND, or under his old guise on irc as samhain1138. Yuval (now on irc as the quaint yuval) joins us from somewhere north of the antartic, has been working with perl for over 7 years both professionally (and not), and just finished up a beer drinking tour of belgium to help prepare him for the volume of mail on this list. So let's all give it up for yuval! Beer certainly is a good introduction to working with perl ;). Welcome aboard! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEuplmrsJQqN81j74RAg3dAKCAROmP29/gc84W8hvP9J7h+/C1dACcDrFi 5og1r9OJUHhd+rTkTMfmfUo= =QFCD -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
On Tuesday 11 July 2006 04:32, Ryan Hill wrote: If yes, why ? And what is your better idea ? I prefer a filter-flags with a ewarn (or elog, haven't read that thread yet ;)) message. * The -ffast-math option is known to break this package and has been filtered from your CFLAGS. Link to Safe CFLAGS wiki page, blah blah blah. I like this better because it informs me of what I did wrong, what was done to correct it, and how I can correct it for myself in the future if I choose to. I don't like artificial barriers and things not working without immediate attention. Call me lazy but it's annoying when you know what you're doing yet you have to jump through hoops to get it done. The die would use the same message. Next, it would actually stop immediately instead of letting you continue further and break in the long run. Using -ffast-math globally is just broken. In some packages it may work. In others it doesn't. My argument is that we must not filter -ffast-math or any other dangerous cflags. The reason being that people will request more filters for all packages that don't work with it. Many users will either ignore or miss the warning messages. Filtering the flag basically tells them that even though the message says it is dangerous, their use of the flag is still more or less supported, while it is not. Okay, bad joke aside, there are always going to be users who tweak GCC flags. This has to be expected, as they're mysterious, and technical, and kinda cool. I like the tweaker crowd and I am a dummy, so no offense was intended to either groups. I meant that if you safety-proof a complex system, people never learn that they're doing anything wrong in the first place. Exactly, filtering the flags is safety-proofing. So just die, or not filter at all. Right, but how are people supposed to learn something is dangerous if all the sharp edges have been filed off? And how can you decide which flags are bad and good on a global level when for the most part compiler parameters are akin to black magic? In this case the compiler documentation itself says it is dangerous. That should be enough. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpZInD51vioS.pgp Description: PGP signature
Re: [gentoo-dev] Yet Another Victim
Michael Cummings wrote: I'm happy to announce a new addition to the perl team Welcome! Perl, huh? :P http://fastar.detonate.net/ftp/images/matrixse/18/6.jpg -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Paul de Vrieze wrote: My argument is that we must not filter -ffast-math or any other dangerous cflags. The reason being that people will request more filters for all packages that don't work with it. Many users will either ignore or miss the warning messages. Filtering the flag basically tells them that even though the message says it is dangerous, their use of the flag is still more or less supported, while it is not. Okay, I agree with this if it's considered acceptable to die during pkg_setup. I was under the impression it's not. Right, but how are people supposed to learn something is dangerous if all the sharp edges have been filed off? And how can you decide which flags are bad and good on a global level when for the most part compiler parameters are akin to black magic? In this case the compiler documentation itself says it is dangerous. That should be enough. Agreed. Anything but global filtering. --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [gentoo dev]suggestion to distutils eclass
On Mon, 2006-07-17 at 00:49 +0800, Zhang Le wrote: Some packages don't provide standard setup.py. Take a look at the attachment. This is a new ebuld. I agree with Stefan, just put a symlink in from whatever their distutils install script is to setup.py in src_unpack(). This seems to be such a rare corner case that it isn't worth adding extra complexity in. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GCC 4.1.1 testing/stablization and glibc 2.4
Ryan Hill wrote: Just an update - I've finished most major desktop stuff for x86 without any problems. I'm moving onto stuff that's already on the tracker and is fixed in testing but not stable. Rather than open and track a ton of new bugs, I'd like to reopen the original ~arch bugs and request a backport or stabilization at the maintainer's discretion. I changed my mind. Reopening these just creates too much random bugspam. --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Thursday 13 July 2006 18:53, Ciaran McCreesh wrote: On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | The dev manual is *wrong*. No, the devmanual reflects what's actually being done, rather than an impractical definition that was written years ago that no longer matches the development model. Then file a bug against the given definition. This only adds to the confusion. As I remember however there have been discussions on this topic and they never came to any conclusion. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpbrgQXmxFw6.pgp Description: PGP signature
Re: [gentoo-dev] Herds suck, fix them
On Thursday 15 June 2006 20:17, Marcus D. Hanwell wrote: I have to agree that I have never understood the need for the distinction between herd and team. It does not seem to add anything, I guess some people do not like being referred to as a herd may be? It really doesn't bother me. I think of a herd as a collection of developers working on a set of packages kept under the same umbrella due to them being related in some way. Basically a team may manage multiple herds, but still separte them because of organizing reasons. At the days, the kde team herded three herds: QT, kde-core, and kde-others. This allowed for example kde-others (random kde apps) to receive different attention than core kde applications. If people really do feel the need to distinguish these things then fine - document it. Otherwise I will continue operating the way I do. I don't see why it matters so much... I agree that in most cases team=herd and there is not formal project and it really doesn't matter if you say that a herd maintains something when it's the herd's maintainers that do so. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpsbU2gYwd9O.pgp Description: PGP signature
[gentoo-dev] [Treecleaners - More Cowbell]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MASKINGS: - --- media-gfx/gtksee - Mr. Bones requested this be removed; no update since Nov 2004. Plenty of other image viewers out there, only uses gtk1 package.mask: # Michael Sterrett [EMAIL PROTECTED] (17 Oct 2005) # Buggy and seemingly not maintained upstream # Using media-gfx/gqview is a much better choice. media-gfx/gtksee It's been masked for some time, but I'll stick to the 30 day policy. net-misc/bidwatcher [1],[2],[3],Tracker[4] The damn thing nearly lost me an auction last time I used it due to a segfault ;) It hasn't worked for some time. Pmasked, pending 30 day removal net-analyzer/tcpick - masked for security reasons, security wants it punted, see bug # 125491[5] net-im/gtalk, last release in 2001, doesn't compile[6] PMASKED, it has 30 days. media-video/mvideo -Removal request by ChrisWhite, pmasked for 4 months, dosn't compile[7], PMASKED 30 days app-news/rol - # Alec Warner [EMAIL PROTECTED] (16 Jul 2006) # app-news/rol Dead upstream, broken package bug 120920[9] net-misc/e1000 - Removal due to no maintainer, driver is in-kernel[10] app-misc/mirror - - - no maintainer - - bugs open for ages [11],[12] - - collides with net-misc/emirror (Bug 69698) - - abandoned upstream (last release in 1998) PMASKED - Tracker[13] app-emulation/pose - numerous bugs, no fixes for years, no maintainer, doesn't compile with gcc-4.1.1 nor gcc-3.4 [14][15][16][17][18] PMASKED - Tracker[19] net-wireless/gtkskan - already pmasked for bug 75674[20]; waiting on it's 30 days. Removals - app-text/bow - Was supposed to be punted July 30th, but I missed it, will punt it now[8] bugs :) [1]https://bugs.gentoo.org/show_bug.cgi?id=94781 [2]https://bugs.gentoo.org/show_bug.cgi?id=107169 [3]https://bugs.gentoo.org/show_bug.cgi?id=140630 [4]https://bugs.gentoo.org/show_bug.cgi?id=140635 [5]https://bugs.gentoo.org/show_bug.cgi?id=125491 [6]https://bugs.gentoo.org/show_bug.cgi?id=79986 [7]https://bugs.gentoo.org/show_bug.cgi?id=85763 [8]https://bugs.gentoo.org/show_bug.cgi?id=88302 [9]https://bugs.gentoo.org/show_bug.cgi?id=120920 [10]https://bugs.gentoo.org/show_bug.cgi?id=138471 [11]https://bugs.gentoo.org/show_bug.cgi?id=69698 [12]https://bugs.gentoo.org/show_bug.cgi?id=70656 [13]http://bugs.gentoo.org/show_bug.cgi?id=138404 [14]http://bugs.gentoo.org/show_bug.cgi?id=33028 [15]http://bugs.gentoo.org/show_bug.cgi?id=58800 [16]http://bugs.gentoo.org/show_bug.cgi?id=91501 [17]http://bugs.gentoo.org/show_bug.cgi?id=111432 [18]http://bugs.gentoo.org/show_bug.cgi?id=134672 [19]http://bugs.gentoo.org/show_bug.cgi?id=138399 [20]http://bugs.gentoo.org/show_bug.cgi?id=75674 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRLra+WzglR5RwbyYAQIWtg//fiLlznbgpGPMVu2NSOo06PkasGVRTSK9 RsqX6lhB4vS6xNj0sYp700FX01cLL70HR96pnI13CRL9buzRoThhb70pzesRRlej Ex7WpDHsEuwfNR1xoNAa2nBkoxSX8KvD3wpSMu5tKKWQ2e/x29dFUrpAbW2hvhbW VqNjOwIT/5xUCaTH58hZ+DZgj2AiNKCdD6ng4HQR/Yny2LSx8GdsXbmgJPrWv0wq oCtZT8JFJsZ233dscVZvUPULXDBgjhhYdDpQ/AoxZGB6/3QD1iqfducDOigaT/tK kidvci8qDQfmzf+bvcW6i44fzeo3mfF5MtAs7A+xsYXs+jI2Yk7Ea5VcytAtu8bL PkNcEJcToRKfBb2sB64LBvXpry2E8IoWEuT8AS2kTdpPh9hw10voNpUoMGNRI7Nk /IcN1Qq9HrA2IBWUYzb5j3U5hz4MpOBl0B/961z9PnQFgNcnY7z3ikrJvuxt3wQq +K1KNl4WEgUB/jZiF9qUUlOcWxqyjELlkl3UzfJu5/QYFpqD545OPjk2HCISW4I6 KK25F/99T8AYeH/A9io8ZZLyvmnFlgtW3Wug35BKtfR4TzFzFlOZQXquudKB5d38 DEU+Qkg0nAVp8Wll5fvG2bqFD/VkX5B2L/XixYkgrLc6ZdEGMQ+RRUEc/zfdJK2f uLDtswVYbpg= =RPq9 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [gentoo dev]suggestion to distutils eclass
On 7/17/06, Alastair Tse [EMAIL PROTECTED] wrote: On Mon, 2006-07-17 at 00:49 +0800, Zhang Le wrote: Some packages don't provide standard setup.py. Take a look at the attachment. This is a new ebuld.I agree with Stefan, just put a symlink in from whatever their distutils install script is to setup.py in src_unpack(). This seems to be such arare corner case that it isn't worth adding extra complexity in.Thanks for you and Stefan's advice. Cheers,Alastair--gentoo-dev@gentoo.org mailing list-- Zhang Le, RobertLinux Engineer/Trainer http://zhllg.spaces.msn.comhttp://zh.gentoo-wiki.comhttp://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-chinahttp://groups.google.com/group/szlug
[gentoo-portage-dev] Porage API Documentation Proposal
Hi all,
I had a discussion yesterday with the folks and #gentoo-portage
regarding API documentation using epydoc and inline custom doc
strings. Attached is a proposal of what I believe
encompasses a majority of the discussion. Suggestions, comments,
etc. are welcome. My standard gentoo account was doing weird
things with mailing list subscriptions, so I'll be using my gmail
account instead.
Chris White
Title: Portage Documentation Proposal
Date: Sun, 16 Jul 2006 05:47:32 UTC
Author: Chris White [EMAIL PROTECTED]
License: Public Domain
Abstract
==
This document is meant to serve as a proposal for the documentation of portage
code using epydoc[1] and custom doc blocks.
Motivation
=
The motivation behind this proposal was the current lack of standardized
documentation
for the portage API. This makes it difficult for developers that would like to
somehow
customize portage, or use the portage API for their own custom scripts.
Specification
Portage code will be documented using the epydoc documentation system. This
system was
choosen as both portage developers and those interested in portage API
documentation
were familiar with the tool. It was also choosen as the main implementor (the
author)
is comfortable with the system and how to use it.
The custom doc block format is as follows (vercmp is used as an example):
---
def pkgcmp(pkg1, pkg2):
Compare 2 package versions created using the L{pkgsplit function
pkgsplit}
Functions used:
- L{pkgsplit pkgsplit}
- L{example portage.example}
Example usage:
from portage_versions import *
pkgcmp(pkgsplit('test-1.0-r1'),pkgsplit('test-1.2-r3'))
-1
pkgcmp(pkgsplit('test-1.3'),pkgsplit('test-1.2-r3'))
1
@param pkg1: L{pkgsplit pkgsplit} result of a package to compare with.
@type pkg1: list (example: ['test', '1.0', 'r1'])
@param pkg2: L{pkgsplit pkgsplit} result of a package to compare
against.
@type pkg2: list (example: ['test', '1.0', 'r1'])
@rtype: None or integer
@return:
1. None if package names are not the same
2. 1 if pkg1 is greater than pkg2
3. -1 if pkg1 is less than pkg2
4. 0 if pkg1 equals pkg2
if pkg1[0] != pkg2[0]:
return None
mycmp=vercmp(pkg1[1],pkg2[1])
if mycmp0:
return 1
if mycmp0:
return -1
r1=string.atof(pkg1[2][1:])
r2=string.atof(pkg2[2][1:])
if r1r2:
return 1
if r2r1:
return -1
return 0
---
This is broken down into the following key pieces:
1. A short one sentence description of what the package does:
Compare 2 package versions created using the L{pkgsplit function
pkgsplit}
2. Other portage API functions used:
Functions used:
- L{pkgsplit pkgsplit}
- L{example portage.example}
3. Optional - Example usage
Example usage:
from portage_versions import *
pkgcmp(pkgsplit('test-1.0-r1'),pkgsplit('test-1.2-r3'))
-1
pkgcmp(pkgsplit('test-1.3'),pkgsplit('test-1.2-r3'))
1
4. Parameters:
a. Description of the parameter:
@param pkg1: L{pkgsplit pkgsplit} result of a package to compare with.
b. Type of the parameter. An example is required. If there are many
types that
can be given, please gave at most 2.
@type pkg1: list (example: ['test', '1.0', 'r1'])
5. Return Values:
a. The type of the return value. Please list all the possible types
@rtype: None or integer
b. More verbose description of the values returned. The numeric list
format
must be used for more than one return type.
@return:
1. None if package names are not the same
2. 1 if pkg1 is greater than pkg2
3. -1 if pkg1 is less than pkg2
4. 0 if pkg1 equals pkg2
Backwards Compatibility
=
Existing doc strings will be converted to the new format.
Known Issues
===
The following are known issues:
1. A large increase in the code size will occur becuase of this. Sugestions
were made to strip out the docstrings, but it was noted that this would make it
very difficult to work with tracebacks.
License
=
This document is placed under Public Domain
Re: [gentoo-portage-dev] Porage API Documentation Proposal
On Mon, Jul 17, 2006 at 03:12:25AM +0900, Chris White wrote:
This document is meant to serve as a proposal for the documentation of portage
code using epydoc[1] and custom doc blocks.
epytext actually- that's what relies on, and is supported by
other doc manglers.
2. Other portage API functions used:
Functions used:
- L{pkgsplit pkgsplit}
- L{example portage.example}
Bad idea. doc strings rules for doc manglers, the base docstring
bleeds through to derivative methods iff the prototype hasn't been
mangled. So... you state in the base method, I use blah. Now
you're requiring every derivative to either
1) rewrite the whole docstring
2) do replace tricks to slip in their func additions.
#1 sucks, #2 is a good way to wind up with whacky docstrings (rather
fragile).
Known Issues
===
The following are known issues:
1. A large increase in the code size will occur becuase of this. Sugestions
were made to strip out the docstrings, but it was noted that this would make
it very difficult to work with tracebacks.
No reason to strip it out- file size isn't going to make a difference
(the slow bits in terms of imports is forced execution in the module
loadup, import lookup, and loading chunks of stdlib).
~harring
pgp9rr97M2pUh.pgp
Description: PGP signature
Re: [gentoo-portage-dev] Porage API Documentation Proposal
epytext actually- that's what relies on, and is supported byother doc manglers.
Change noted in the attached proposal
Bad idea.doc strings rules for doc manglers, the base docstringbleeds through to derivative methods iff the prototype hasn't been
mangled.So... you state in the base method, I use blah.Nowyou're requiring every derivative to either
Agreed. This was taken out of the proposal. A piece was
added however use L{} to link to any custom objects used as
parameters/return values.
No reason to strip it out- file size isn't going to make a difference(the slow bits in terms of imports is forced execution in the module
loadup, import lookup, and loading chunks of stdlib).~harring
I think the discussion here was more on code readability as well.
Having such doc blocks would make the code larger and possibly harder
to navigate. Though, most IDE's should have the option to code
fold these away.
Chris White
Title: Portage Documentation Proposal
Date: Sun, 16 Jul 2006 05:47:32 UTC
Author: Chris White [EMAIL PROTECTED]
License: Public Domain
Abstract
==
This document is meant to serve as a proposal for the documentation of portage
code using epytext[1] and custom doc blocks.
Motivation
=
The motivation behind this proposal was the current lack of standardized
documentation
for the portage API. This makes it difficult for developers that would like to
somehow
customize portage, or use the portage API for their own custom scripts.
Specification
Portage code will be documented using the epydoc documentation system. This
system was
choosen as both portage developers and those interested in portage API
documentation
were familiar with the tool. It was also choosen as the main implementor (the
author)
is comfortable with the system and how to use it.
The custom doc block format is as follows (vercmp is used as an example):
---
def pkgcmp(pkg1, pkg2):
Compare 2 package versions created in pkgsplit format.
Example usage:
from portage_versions import *
pkgcmp(pkgsplit('test-1.0-r1'),pkgsplit('test-1.2-r3'))
-1
pkgcmp(pkgsplit('test-1.3'),pkgsplit('test-1.2-r3'))
1
@param pkg1: package to compare with
@type pkg1: list (example: ['test', '1.0', 'r1'])
@param pkg2: package to compare againts
@type pkg2: list (example: ['test', '1.0', 'r1'])
@rtype: None or integer
@return:
1. None if package names are not the same
2. 1 if pkg1 is greater than pkg2
3. -1 if pkg1 is less than pkg2
4. 0 if pkg1 equals pkg2
if pkg1[0] != pkg2[0]:
return None
mycmp=vercmp(pkg1[1],pkg2[1])
if mycmp0:
return 1
if mycmp0:
return -1
r1=string.atof(pkg1[2][1:])
r2=string.atof(pkg2[2][1:])
if r1r2:
return 1
if r2r1:
return -1
return 0
---
This is broken down into the following key pieces:
1. A short one sentence description of what the package does:
Compare 2 package versions created in L{pkgsplit pkgsplit} format.
2. Optional - Example usage
Example usage:
from portage_versions import *
pkgcmp(pkgsplit('test-1.0-r1'),pkgsplit('test-1.2-r3'))
-1
pkgcmp(pkgsplit('test-1.3'),pkgsplit('test-1.2-r3'))
1
3. Parameters:
a. Description of the parameter:
@param pkg1: package to compare with.
b. Type of the parameter. An example is required. If there are many
types that
can be given, please gave at most 2. If type is a custom object, it
must be
referenced to in the format L{name package.object}.
@type pkg1: list (example: ['test', '1.0', 'r1'])
4. Return Values:
a. The type of the return value. Please list all the possible types
@rtype: None or integer
b. More verbose description of the values returned. The numeric list
format
must be used for more than one return type.
@return:
1. None if package names are not the same
2. 1 if pkg1 is greater than pkg2
3. -1 if pkg1 is less than pkg2
4. 0 if pkg1 equals pkg2
Backwards Compatibility
=
Existing doc strings will be converted to the new format.
Known Issues
===
The following are known issues:
1. A large increase in the code size will occur becuase of this. Sugestions
were made to strip out the docstrings, but it was noted that this would make it
very
