Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
On 20-12-2009 22:16:30 -0500, Mike Frysinger wrote: gmane is f-ed up already irregardless of what we do. it eats cross-posted e- mails for breakfast and doesnt tell anyone. as for archives.g.o, file a bug if it isnt handling threading within a list properly. i dont really see how your proposal here would break archives.g.o anyways. someone sends an e-mail to both dev and dev-announce, it has the same id. people respond and they all go to dev. either way, archives.g.o should be seeing a sane thread on dev. New devs are not announced to -dev, the mail is only sent to -dev-announce. The January 2010 meeting date mail was only sent to -dev-announce (and -council), not to -dev, hence replies (that have to go to -dev) are replies with the original mail missing. If all mail that would go to -dev-announce would guaranteed be sent to -dev as well, I didn't have to check -dev-announce, and archives.g.o would also have the original January 2010 meeting date mail in the thread on -dev. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Versioning of Python scripts
On Sat, Dec 19, 2009 at 04:24:49PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
Distutils/Setuptools/Distribute modify shebangs of installed Python scripts,
so that they
contain path of Python interpreter with version included (e.g.
#!/usr/bin/python3.2).
This behavior has both advantage and disadvantages:
- Scripts of packages supporting only e.g. Python 2 can be executed
(without necessity
of using of e.g. python2 /usr/bin/${script}) after activating of e.g.
Python 3.
- Scripts of packages supporting multiple Python versions ignore active
Python version.
- Scripts of packages supporting multiple Python versions cannot be easily
(without
necessity of using of e.g. python3.1 /usr/bin/${script}) executed with
a Python
version different than active Python version.
The best solution, which removes these 2 disadvantages and preserves the
advantage, seems
to be to rename Python scripts to include Python version [1] in filenames,
and create wrapper
scripts, which call appropriate target scripts [2]. Some files sometimes try
to execute
e.g. /usr/bin/python /usr/bin/${script}, so wrapper scripts must be
implemented in Python.
Wrapper scripts try to execute ${wrapper_script}-${PYTHON_ABI} files (e.g.
py.test will
execute py.test-3.1, when Python 3.1 is set as active Python version).
distutils.eclass will automatically rename some scripts [3] in ${D}usr/bin
and call
the function, which generates wrapper scripts. In case somebody is interested
in reading of
source code of python_generate_wrapper_scripts() function and potential
suggesting of
improvements, I'm attaching this function and 2 example wrapper scripts. I'm
planning to
commit addition of this function in next week.
Not really a huge fan of the EPYTHON var... can you clarify it's real
world usage? I can see that causing all sorts of mayhem as it passes
it's way down through python scripts invoking other scripts-
specifically thinking of a py3k only script being forced to 3.1, then
invoking a py2k script.
Beyond that, please provide a way to *disable* this for a pkg. At
least for pkgcore, I've already been looking at ways to deal with
this and would rather solve it at the pkg level (since EPYTHON let
alone eselect may not exist for certain target deployments of
pkgcore itself).
Basically, no point in having wrapper scripts if the target already
can do it's own version of this, hence wanting a way to disable it in
the ebuild- that's just for the script mangling, library installing
for multiple python abis is a seperate thing.
Aside from that, punting on the re import might be nice primarily for
speed reasons (no it's not a huge import in cost, but this is an extra
~.025 per python script invoked, ignoring the ~.3 to ~.02 for eselect
dependant on cache status).
~harring
pgpO4dhZ5T5bd.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
On 12/21/2009 02:54 AM, Fabian Groffen wrote: If all mail that would go to -dev-announce would guaranteed be sent to -dev as well, I didn't have to check -dev-announce, and archives.g.o would also have the original January 2010 meeting date mail in the thread on -dev. Or you could just subscribe to both and add this to your procmailrc: :0 Wh: msgid.lock | formail -D 8192 msgid.cache :0 a: .duplicates/new Cross-posting in general tends to mess up threads, but there isn't much that can be done about that unless we just ban it. However, most cross-posts are honest attempts to try to move list discussion to a place where it might better belong. Honestly, list traffic is a lot better than it used to be, and I'm not sure that this is really a big problem these days.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Election for the Gentoo Council empty seat
On 12/20/2009 01:04 PM, Jeremy Olexa wrote: Flattered, but I decline. I don't agree with the way the Council works and don't have motivation to attempt to change it. Out of curiosity, would you care to elaborate? I don't have much of a political axe to grind so I guess I tend to stay out of the politics...
Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
On 21-12-2009 06:30:23 -0500, Richard Freeman wrote: On 12/21/2009 02:54 AM, Fabian Groffen wrote: If all mail that would go to -dev-announce would guaranteed be sent to -dev as well, I didn't have to check -dev-announce, and archives.g.o would also have the original January 2010 meeting date mail in the thread on -dev. Or you could just subscribe to both and add this to your procmailrc: :0 Wh: msgid.lock | formail -D 8192 msgid.cache :0 a: .duplicates/new Does that fix archives.g.o? No. Cross-posting in general tends to mess up threads, but there isn't much that can be done about that unless we just ban it. However, most cross-posts are honest attempts to try to move list discussion to a place where it might better belong. For commits I can imagine, but for this, it's just pointless. -- Fabian Groffen Gentoo on a different level
[gentoo-dev] Anyone intrested in maintaining media-gfx/digikam?
media-gfx/digikam is rotting outdated in tree with copies of *dozen* internal libraries, like *five* copies of sqlite, including sqlite-2. Anyone intrested in maintaining it unbundling the libraries? -- Bundling internal copies of libraries, https://bugs.gentoo.org/show_bug.cgi?id=206934 https://bugs.gentoo.org/show_bug.cgi?id=258463 But above doesn't cover them all, it's coming also with copy of e.g. media-libs/jpeg-6b and several others. Version 1.0.0 final been released, https://bugs.gentoo.org/show_bug.cgi?id=295459 -- Thanks, Samuli
Re: [gentoo-dev] Re: [gentoo-dev-announce] Election for the Gentoo Council empty seat
On 12/21/2009 06:33 AM, Richard Freeman wrote: On 12/20/2009 01:04 PM, Jeremy Olexa wrote: Flattered, but I decline. I don't agree with the way the Council works and don't have motivation to attempt to change it. Out of curiosity, would you care to elaborate? I don't have much of a political axe to grind so I guess I tend to stay out of the politics... Sorry - that was not meant to go to the list, although list-replies in -project might be appropriate if they are constructive...
Re: [gentoo-dev] Re: News item for Paludis kdebuild-1 removal
On Wed, 16 Dec 2009 23:28:19 +0100 Christian Faulhammer fa...@gentoo.org wrote: Since kdebuild-1 is to be removed from PMS immediately, it's going to go from Paludis in the next release too. We need to warn users about this, since they'll no longer be able to uninstall kdebuild-1 packages they have installed. Please review the following GLEP 42 news item for this: As we cannot be sure that a former GenKDEsvn user still uses some of the KDE overlays, putting that news item in the main tree seems ok. Plus some of the overlays that were using kdebuild-1 don't exist any more... You have a committer for this? Probably. There're enough Gentoo developers using Paludis that getting things committed hasn't ever been an issue. The Gentoo Council has decided that all mention of the kdebuild-1 EAPI is to be removed from the Package Manager Specification immediately. How many users will care what the PMS is? And why is a cleaned up specification breaking your implementation? Tell them that kdebuild-1 has reached its end of life and support will phase out. It's the sort of thing Paludis users do tend to care about. PMS gets mentioned often enough in answers on the Paludis mailing list, bug tracker and IRC channels as answers to questions, so if there are any users who haven't heard of it, we're merely bringing forward their inevitable encounter slightly. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] openrc/baselayout2 stabilization update
All, we are still working toward stabilizing openrc and baselayout-2. The current status is that all of the bugs which have anything to do with openrc/baselayout are assigned to the baselayout component in bugzilla. Also, there is a tracker bug at http://bugs.gentoo.org/295613. It would be very helpful if others here could check the bugs and make bugs that should block stabilization block the tracker. Also, any solutions you have for blocking bugs would be very much appreciated. Thanks much, William pgpBL665SzbVW.pgp Description: PGP signature
[gentoo-dev] last rites: games-strategy/freelords
# Michael Sterrett mr_bon...@gentoo.org (21 Dec 2009) # Doesn't work anymore; the version in portage is no longer # supported by upstream and no newer version is yet available. # Planned removal on 20100120 games-strategy/freelords
