[gentoo-dev] Last rites: =dev-lang/python-2.3*
# Ali Polatel [EMAIL PROTECTED] (07 Jan 2008) # Old, unmaintained version. Will be removed in 30 days. =dev-lang/python-2.3* Python-2.3 is old and unmaintained. Python-2.4 has been in the tree for quite a long time and is stable. P.S: I plan to add a junk overlay like java's to put old python stuff. I'll keep you posted. pgpNW7UrBMLFt.pgp Description: PGP signature
[gentoo-dev] Re: Last rites: =dev-lang/python-2.3*
Markus Ullmann yazmış: Ali Polatel schrieb: P.S: I plan to add a junk overlay like java's to put old python stuff. I'll keep you posted. Just make sure to copy anything that has mirror://gentoo as it would be gone automatically 14 after you remove the ebuild from gentoo-x86 (and thus the reference to it). Thanks for the reminder ;) Greetz -Jokey -ali pgpyb7EzR4nID.pgp Description: PGP signature
[gentoo-dev] Re: Last rites: =dev-lang/python-2.3*
Ali Polatel schrieb: P.S: I plan to add a junk overlay like java's to put old python stuff. I'll keep you posted. Just make sure to copy anything that has mirror://gentoo as it would be gone automatically 14 after you remove the ebuild from gentoo-x86 (and thus the reference to it). Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Last rites: =dev-lang/python-2.3*
Ali Polatel yazmış: # Ali Polatel [EMAIL PROTECTED] (07 Jan 2008) # Old, unmaintained version. Will be removed in 30 days. =dev-lang/python-2.3* Python-2.3 is old and unmaintained. Python-2.4 has been in the tree for quite a long time and is stable. Appearently there are some packages which I missed are broken due to masking this, unmasked for now. Sorry for the inconvenience and thanks again to mr_bones_. -ali pgpBx6fhfdmJn.pgp Description: PGP signature
[gentoo-dev] Re: Projects and subproject status
Luca Barbato schrieb: Are we fine? lcd : G15 in good shape, no major issues anywhere ldap: openldap works good, nss_ldap has some issues here and there net-irc : some minor issues with dead-upstream apps or apps breaking their own configs but nothing too serious net-mon : behind on some packages due to only 3 people taking care, could use more hands to help maintaining What are we going to do: lcd : nothing major atm ldap: openldap 2.4 in the queue, yet needs more work to be safe net-irc : nothing big, just some minor bumps here and there net-mon : just working through bugs, some are hard to reproduce so may take a bit to be resolved finally Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Projects and subproject status
Luca Barbato [EMAIL PROTECTED] writes: - video: Hopefully nothing much beside trying to give the best and freshest snapshots from the repository you started to know (mplayer, ffmpeg, xine, vlc...Hi Diego =)) I'm involved just in one and a half of those ;) As for me, I mostly handle PAM (solo as usual). Current status: PAM 0.99 is stable on all architectures beside one, which means that PAM maintenance should be quite easier. It has been a few months till last release so the water is also quite calm. The upgrade was smooth for most people up to now, hopefully the documentation on that will suffice. Future plans: I hope to be able to complete the developers' documentation, it's mostly a matter of finding time to work on it again, probably I won't be able to make it before February, but I count on writing something starting mid-february. And for what concerns PulseAudio: Current status: 0.9.8 is in tree for a while but contains a few new features that should be tested well before marking it stable, so 0.9.7 is the current candidate. The new init script using Baselayout 2/OpenRC functionalities is well tested at this point and mostly waiting for OpenRC to enter ~arch. Future plans: again not before mid-february I'll see to write some user documentation about PulseAudio, like a Gentoo-specific Perfect Setup, to integrate the generic documentation available on PulseAudio's wiki. As for other misc stuff I maintain, I don't know exactly what's left, but you can easily see what I'm doing on the blog :P -- Diego Flameeyes Pettenò http://farragut.flameeyes.is-a-geek.org/ pgpYdZPjU9Epq.pgp Description: PGP signature
[gentoo-dev] [RFC] Reducing the size of the system package set
Here comes the official proposal, copy and paste from my blog with an extra post scriptum at the end. I already ranted about the fact that the dependency tree of our ebuilds is vastly incomplete, as many lack dependency on zlib; trying to get this fixed was impossible, as Donnie and other insisted that as zlib was in system, we shouldn’t depend on it at all. I disagree, and I would like to know why we can’t depend on a system package, but whatever. Anyway, as having a complete dependency tree is almost impossible because of that, I have an alternative proposal: reducing the size of the system package set. Right now system contains stuff like ncurses, readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so on. Those are packages that certainly would be part of any base Gentoo system, but are those actual part of the system set of packages? I sincerely doubt it. The reason of the existence of the system package set is related first and foremost to breaking circular dependencies: for instance if any package that used the C compiler would depend on gcc, then the packages that gcc depends upon would create a circular dependency between gcc and itself. Also, specifying libc in almost any ebuild would be quite pointless, as well as coreutils (or freebsd-bin/ubin) for cp, mv, install, … But why autoconf and automake? Well the easy answer is that those are often used without making sure they are depended upon explicitly… or at least this was the case till me and Martin added autotools.eclass to the tree; nowadays all the ebuilds using autotools should have proper autoconf/automake dependency already, and if they don’t they are broken anyway. So why leaving them in system? And what about m4? m4 is not part of a common Unix system, it’s just an autoconf dependency, why isn’t it just an autoconf dependency? For what concern the three main libraries, there aren’t that many packages using zlib directly nowadays, this is especially easy to spot on a system built with --as-needed, as without that you actually do see zlib used in every other binary, for indirect dependencies. Nor there aren’t tons and tons of packages using readline, or ncurses. Actually in my own vserver’s chroot I only found four packages using readline, none of them part of system: ruby with the readline extension (uhm I wonder if I should ask for this to become an USE flag, I certainly don’t need it and I’d rather get rid of it), psql from postgresql (which maybe it’s still good to have with readline compiled in, but I could easily get rid of), bc (which is just an e2fsprogs build-dep, and I could build without readline just fine), and mysql. A little bit different the status of ncurses, which is used by screen, gettext (only a build-dep, not needed for runtime on Linux anyway), procps, psmisc and util-linux (and I wonder why we don’t have a switch to turn it off), texinfo (wonder why we can’t remove it entirely actually) and yet again ruby. Still, I wonder why ncurses is in system rather than being properly on the dependencies list of those packages. As for perl, that’s probably a bit more justified, there are tons of packages using perl directly or indirectly, especially in build systems. But I would like those to depend on perl properly rather than having perl in system, as there are cases where perl is not really needed at runtime at least. And the only users of gnuconfig are the packages making use of the old and deprecated gnuconfig.eclass, or portage’s econf. Why can’t it be a dependency of portage then? There are probably other packages that should, in my opinion, be removed From system, but these are certainly some of the most common. Unfortunately there’s a recursive problem here: to remove the packages from system without breaking stuff you’d need a proper deptree, and to get a proper deptree you need to remove the packages from system. This is what actually stops me from proposing this right away… P.S.: So there are more things that were brought to my attention, like ssh, flex, bison, e2fsprogs, and so on. We should probably look into what to keep, rather than what to remove. Also, rocket proposed me to try building a stage with a slimmed down system. I could try, but it would be a waste of time if we then decide not to go this route, and that's _a lot_ of time that would go to waste, so I'd rather first see what the other devs think, before going to do the actual tests. -- Diego Flameeyes Pettenò http://farragut.flameeyes.is-a-geek.org/ pgpj6JMlVTszU.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh kirjoitti: On Sat, 05 Jan 2008 20:52:49 -0600 Martin Jackson [EMAIL PROTECTED] wrote: That's making the assumption that anyone looked at it, of course. Please note comment #9 on http://bugs.gentoo.org/show_bug.cgi?id=198346. It was still ~8 days from then that the setuptools keyword was added. So, we have examples of impact due to delay in keywords/etc. Shall we proceed with the discussion of what to do about it? http://www.gentoo.org/security/en/vulnerability-policy.xml The target for that GLSA was 20 days. 8 days is well within target. What are you moaning about? Well sqlite has been security vulrenable for two months now http://bugs.gentoo.org/show_bug.cgi?id=194812 Here is the comment from security for remaining arch teams to speed things up: http://bugs.gentoo.org/show_bug.cgi?id=194812#c8 Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Reducing the size of the system package set
Diego 'Flameeyes' Pettenò kirjoitti: Here comes the official proposal, copy and paste from my blog with an extra post scriptum at the end. I already ranted about the fact that the dependency tree of our ebuilds is vastly incomplete, as many lack dependency on zlib; trying to get this fixed was impossible, as Donnie and other insisted that as zlib was in system, we shouldn’t depend on it at all. I disagree, and I would like to know why we can’t depend on a system package, but whatever. At least one reason is that otherwise lots of ebuild submissions would have coreutils/gcc/libc/whatever in DEPEND/RDEPEND. But why autoconf and automake? Well the easy answer is that those are often used without making sure they are depended upon explicitly… or at least this was the case till me and Martin added autotools.eclass to the tree; nowadays all the ebuilds using autotools should have proper autoconf/automake dependency already, and if they don’t they are broken anyway. So why leaving them in system? And what about m4? m4 is not part of a common Unix system, it’s just an autoconf dependency, why isn’t it just an autoconf dependency? IMHO these could be removed from the system set. But likely the packages left in there would pull it to the stages any way. P.S.: So there are more things that were brought to my attention, like ssh, flex, bison, e2fsprogs, and so on. We should probably look into what to keep, rather than what to remove. Well e2fsprogs provides fsck so it's a dep of baselayout. But it wouldn't hurt to cleanup the list even if it doesn't get them removed from stages. I don't know about other system packages but at least baselayout is not really depending on much atm. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Reducing the size of the system package set
On Tuesday 08 of January 2008 02:02:56 Petteri Räty wrote: Diego 'Flameeyes' Pettenò kirjoitti: Here comes the official proposal, copy and paste from my blog with an extra post scriptum at the end. I already ranted about the fact that the dependency tree of our ebuilds is vastly incomplete, as many lack dependency on zlib; trying to get this fixed was impossible, as Donnie and other insisted that as zlib was in system, we shouldn’t depend on it at all. I disagree, and I would like to know why we can’t depend on a system package, but whatever. At least one reason is that otherwise lots of ebuild submissions would have coreutils/gcc/libc/whatever in DEPEND/RDEPEND. We could probably introduce some fancy virtuals like c-toolchain to reduce the bloat, but the transition would be somehow tricky... would probably need a list of already converted packages. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@lists.gentoo.org mailing list
