Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Dienstag, 13. Juli 2010, Julien Cristau wrote: > > I would say that you should ask for adoption or help maintaining the > > package. > What is this supposed to mean? he missed all the X strike force requests for help, I'd say. signature.asc Description: This is a digitally signed message part.
Bug#589008: ITP: launchpad-integration -- Launchpad integration library
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: launchpad-integration Version : 0.1.36 Upstream Author : James Henstridge * URL : https://launchpad.net/launchpad-integration * License : GPL Programming Lang: C, C#, Python Description : Launchpad integration library The launchpad-integration tools provide an easy way to set menu items, for an application using GtkUIManager, pointing to the launchpad pages about a package. Users can get information about the used application here, translate it etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714075837.5264.96760.report...@alessio-laptop
Re: RFA: a lot of packages
Quoting Tobias Quathamer (to...@debian.org): > Am Sonntag, den 20.06.2010, 18:24 +0200 schrieb Christian PERRIER: > > Quoting Ola Lundqvist (o...@inguza.com): > > > Hi Christian > > > > > > Anyone who take this package over is free to complete this. :-) > > > > Other iso-codes maintainers, would you agree? > > Sure, we should take care of the countrycodes package. Do you think you can import the source in out git? You're much more comfortable with git than me, I think. signature.asc Description: Digital signature
Re: upcoming issues with python-hulahop, python-xpcom, xulrunner-1.9.2
On Tue, Jul 13, 2010 at 06:07:27PM +, Luke Kenneth Casson Leighton wrote: > hi folks, > > i don't know if you're aware of the ... issues shall we say ... > surrounding xulrunner 1.9.2 but there's a few changes going on. > python-xpcom is being *dropped* from xulrunner as a first class > citizen and is being turned into a third-rate one. this isn't a > problem right now because debian releases versions of firefox that use > xulrunner-1.9.1. > > the rdepends for python-xpcom include python-hulahop and > pyjamas-desktop, epiphany-gecko, sugar-web-activity and so on. > removal of python-xpcom basically screws these projects. epiphany-gecko is already gone. > to make matters slightly worse, the mozilla team have dicked with the > xpcom interface c-code as they focus all-out on speed-speed-speed to > the absolute pathological exclusion of all else, in an attempt to > catch up with webkit's increasing mindshare. this decision is > affecting all the language bindings (such as java-xpcom, python-xpcom > and so on). > > so, right now, the situation is as follows: > > * if you upgrade firefox to a version which uses xulrunner-1.9.2, > python-xpcom and its rdepends go out the window. > > * even if you happen to include the third party module > http://hg.mozilla.org/pyxpcom as it is now known, xulrunner's XPCOM > code has been been brain-damaged to the extent that several key > strategic things such as python bindings to XMLHttpRequest will no > longer work. todd whiteman has very kindly agreed to look at this, > and to keep up with the brain-damage. For people interested in more intelligible information than the above rant, some xpcom exposed interfaces in xulrunner have been "tweaked" such that they will only work when called from javascript. Such interfaces thus can't work from other xpcom bindings. > basically i wanted to appraise people of the situation, because, with > xulrunner-1.9 being in debian/testing since pyjamas-desktop was added, > any attempt to follow the mozilla foundation's headless-chicken > meltdown moments means goodbye epiphany-gecko, sugar-web-activity and > pyjamas-desktop. and... that would be bad :) I guess you mean xulrunner-1.9.1. xulrunner-1.9.2 is still in experimental and will stay there until squeeze is released. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714085259.gb3...@glandium.org
Re: upcoming issues with python-hulahop, python-xpcom, xulrunner-1.9.2
On Wed, Jul 14, 2010 at 10:52:59AM +0200, Mike Hommey wrote: > For people interested in more intelligible information than the above > rant, some xpcom exposed interfaces in xulrunner have been "tweaked" > such that they will only work when called from javascript. Such > interfaces thus can't work from other xpcom bindings. Actually, that's not true. It turns out the javascript xpcom has been tweaked to better handle optional arguments, but the other bindings haven't. And apparently, all Luke Kenneth Casson Leighton is able to do in upstream bugzilla is rant, so it doesn't help either. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714090924.ga5...@glandium.org
Upstream Tracker
Hello, Colleagues! The new service for tracking ABI changes in various C/C++ libraries is now available for Linux distribution maintainers and upstream developers - "Upstream Tracker". It may be helpful for analyzing risks of libraries updating in the Debian Linux. The service includes more than 100 libraries at the moment: OpenSSL, ALSA, glib, cairo, libssh, fontconfig etc. The service is freely available at: http://linuxtesting.org/upstream-tracker/ Suggestions for libraries inclusion and feature/bug requests are very welcome. Thanks! -- Andrey Ponomarenko Linux Verification Center, ISPRAS web:http://www.linuxtesting.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c3d9b07.1000...@ispras.ru
Re: upcoming issues with python-hulahop, python-xpcom, xulrunner-1.9.2
On Wed, Jul 14, 2010 at 8:52 AM, Mike Hommey wrote: > On Tue, Jul 13, 2010 at 06:07:27PM +, Luke Kenneth Casson Leighton wrote: >> hi folks, >> >> i don't know if you're aware of the ... issues shall we say ... >> surrounding xulrunner 1.9.2 but there's a few changes going on. >> python-xpcom is being *dropped* from xulrunner as a first class >> citizen and is being turned into a third-rate one. this isn't a >> problem right now because debian releases versions of firefox that use >> xulrunner-1.9.1. >> >> the rdepends for python-xpcom include python-hulahop and >> pyjamas-desktop, epiphany-gecko, sugar-web-activity and so on. >> removal of python-xpcom basically screws these projects. > > epiphany-gecko is already gone. > >> to make matters slightly worse, the mozilla team have dicked with the >> xpcom interface c-code as they focus all-out on speed-speed-speed to >> the absolute pathological exclusion of all else, in an attempt to >> catch up with webkit's increasing mindshare. this decision is >> affecting all the language bindings (such as java-xpcom, python-xpcom >> and so on). >> >> so, right now, the situation is as follows: >> >> * if you upgrade firefox to a version which uses xulrunner-1.9.2, >> python-xpcom and its rdepends go out the window. >> >> * even if you happen to include the third party module >> http://hg.mozilla.org/pyxpcom as it is now known, xulrunner's XPCOM >> code has been been brain-damaged to the extent that several key >> strategic things such as python bindings to XMLHttpRequest will no >> longer work. todd whiteman has very kindly agreed to look at this, >> and to keep up with the brain-damage. > > For people interested in more intelligible information than the above > rant, ( it's a good one, innit? :) > some xpcom exposed interfaces in xulrunner have been "tweaked" > such that they will only work when called from javascript. Such > interfaces thus can't work from other xpcom bindings. yup. appreciate the clarification, mike. basically, an interpretation of the decision from the mozilla foundation is that all languages but javascript can get lost. i do not understand why, after years of support thanks to xpcom, _just_ when there's a project which actually _uses_ alternative language bindings 100% and i meaaan 100%, the mozilla foundation slams the door in its face and in the face of every other project using xpcom. it's not like there's a chance of any non-mozilla-foundation-funded project having the money to maintain a parallel version of xulrunner with a non-broken version of xpcom or anything. >> basically i wanted to appraise people of the situation, because, with >> xulrunner-1.9 being in debian/testing since pyjamas-desktop was added, >> any attempt to follow the mozilla foundation's headless-chicken >> meltdown moments means goodbye epiphany-gecko, sugar-web-activity and >> pyjamas-desktop. and... that would be bad :) > > I guess you mean xulrunner-1.9.1. yes. again, thank you for clarifying. > xulrunner-1.9.2 is still in > experimental and will stay there until squeeze is released. ok. thank god. so unless the mozilla foundation see the light, basically all projects that use python-xpcom must stick with xulrunner-1.9.1. that means that all linux distributions must maintain two parallel versions of xulrunner, or that they must "bundle" a version of xulrunner specifically dedicated to firefox _in_ firefox (just like the stand-alone releases made by the mozilla foundation itself). or, all linux distributions must tell python-xpcom-dependent projects to go to hell in a handbasket. those are some the options, and i'm interested to know a) if anyone has any alternative ideas b) which way the debian project is going to jump. i _could_ create and maintain and even submit a series of packages "xulrunner-1.9.1-to-deal-with-shortsighted-mozilla-foundation-decision", "python-xpcom-1.9.1-to-deal-with-shortsighted-mozilla-foundation-decision" and would be happy to submit patches to python-hulahop, sugar-web-activity and pyjamas-desktop packages, if that would help, but i am not entiiirely sure that would go down well :) l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiki3m5rwoxe3kdlipsgjn9hv50ua_brhfw54...@mail.gmail.com
Bug#589037: ITP: seeks -- Social websearch application
Package: wnpp Severity: wishlist Owner: Julien Rabier * Package name: seeks Version : 0.2.3 Upstream Author : Emmanuel Benazera * URL : http://www.seeks-project.info * License : (AGPL, GPL, LGPL) Programming Lang: (C++) Description : Social websearch application Seeks is a free and open technical design and application for enabling social websearch. Its specific purpose is to regroup users whose queries are similar so they can share both the query results and their experience on these results. On this basis, Seeks allows for true real-time, decentralized, websearch to emerge. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714124825.ga23...@lappi
Bug#589042: ITP: debichem -- Set of Blends metapackages for DebiChem
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: debichem Version : 0.0.1 Upstream Author : Michael Banck , Andreas Tille * URL : Native package * License : GPL Description : Set of Blends metapackages for DebiChem The source package will create a set of metapackages for the different tasks defined by the DebiChem project to support people working with in the field of chemistry finding their stuff easily in the pool of Debian packages. The metapackages should help the DebiChem project to support their users better by simpler installation as well better documentation because the work of the project will be easily displayed by the Blends tools at http://blends.alioth.debian.org/debichem/tasks/ -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714133820.20270.24436.report...@mail.an3as.eu
packages being essential but having stuff in /usr/?!
Hi. I wonder why this never came up before,.. or did it an I'm just blind? I've just read parts of POSIX, where echo is more or less deprecated in favour of printf (http://www.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_16). Whether users will do this or not is a different question but I've seen that Debian/corutils ships echo in /bin, but printf in /usr/bin. The same for many other binaries part of coreutils. Now coreutils is marked as essential, right?! This means per policy section 3.8 (http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8): "Essential is defined as the minimal set of functionality that must be available and usable on the system at all times" As far as I understand,.. it's fully ok, to have /usr on a separate (i.e. non-root-) filesystem. That however would mean, that even outsite initramfs images (which are probably a special case and do not count) many of corutils' binaries are not _always_ available. People would again have to check for them in e.g. their initscripts, or basically everything before /usr is mounted, e.g. via NFS. The same might be a problem with other essential packages, too. Cheers, Chris. btw: Personally, I'd support to stop using echo,.. it's not really portable... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/42b814c7877048a8a86a2e9da34f7...@imap.dd24.net
Re: packages being essential but having stuff in /usr/?!
[Christoph Anton Mitterer] > Now coreutils is marked as essential, right?! > This means per policy section 3.8 > (http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8): > "Essential is defined as the minimal set of functionality that must be > available and usable on the system at all times" > > As far as I understand,.. it's fully ok, to have /usr on a separate > (i.e. non-root-) filesystem. > > That however would mean, that even outsite initramfs images (which are > probably a special case and do not count) many of corutils' binaries are > not _always_ available. I believe this is a misunderstanding. The quoted section do not mean that all files in a essential package need to be on the root partition, but that the package should always be installed. This is the first time I hear someone read the policy section the way you do it, and I believe it is not representative for the intention behind that part of the policy. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl630i3rmu@login1.uio.no
Re: packages being essential but having stuff in /usr/?!
On 2010-07-14 17:36 +0200, Christoph Anton Mitterer wrote: > I wonder why this never came up before,.. or did it an I'm just blind? It's been reported as bug #428189 already, but without any followup. See also #532324. > I've just read parts of POSIX, where echo is more or less deprecated in > favour of printf > (http://www.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_16). > Whether users will do this or not is a different question but I've seen > that Debian/corutils ships echo in /bin, but printf in /usr/bin. This is indeed a problem if /bin/sh has no printf builtin, but it does not affect people who use dash or bash. > The same for many other binaries part of coreutils. > > Now coreutils is marked as essential, right?! So is dpkg, and it lives almost completely under /usr, except for start-stop-daemon. > This means per policy section 3.8 > (http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8): > "Essential is defined as the minimal set of functionality that must be > available and usable on the system at all times" > > As far as I understand,.. it's fully ok, to have /usr on a separate > (i.e. non-root-) filesystem. > > That however would mean, that even outsite initramfs images (which are > probably a special case and do not count) many of corutils' binaries are > not _always_ available. Before /usr is mounted, yes. > People would again have to check for them in e.g. their initscripts, or > basically everything before /usr is mounted, e.g. via NFS. Only init scripts that do not depend on $remote_fs have to do this check. > The same might be a problem with other essential packages, too. I have /usr on a separate partition and did not have any problems in the last few years with that. Don't know how the situation is with /usr on NFS, though. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739vm3rh0@turtle.gmx.de
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Tue, 13 Jul 2010 11:36:10 -0400 (EDT), Cyril Brulebois wrote: > Cyril Brulebois wrote: >> ... I didn't ask for an UMS-related bug reference. For some reason I was under the impression that KMS drivers were limited to modes which can be set by the video BIOS. I stand corrected. A bug report will be forth-coming. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2044848160.193276.1279129700306.javamail.r...@md01.wow.synacor.com
Bug#589074: ITP: sugar-etoys-activity -- Sugar Etoys Activity
Package: wnpp Severity: wishlist Owner: Ankur khurana * Package name: sugar-etoys-activity Version : 115 Upstream Author : Bert Freudenberg * URL : http://wiki.laptop.org/go/Etoys * License : GPL v2+ Programming Lang: Python Description : Sugar Etoys Activity Etoys is * an educational tool for teaching children powerful ideas in compelling ways * a media-rich authoring environment and visual programming system * a free software program that works on almost all personal computers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714181009.1572.8853.report...@ankurkhurana-desktop
Re: Bug#589008: ITP: launchpad-integration -- Launchpad integration library
Le mercredi 14 juillet 2010 à 09:58 +0200, Alessio Treglia a écrit : > * Package name: launchpad-integration > The launchpad-integration tools provide an easy way to set > menu items, for an application using GtkUIManager, pointing > to the launchpad pages about a package. Users can get > information about the used application here, translate it etc. Correct me if I’m wrong, but LPI is mostly used to help users provide Ubuntu-specific translations for a package. What is the use case for this package in Debian? Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Bug#589098: ITP: python-dicom -- DICOM medical file reading and writing
Package: wnpp Severity: wishlist Owner: Yaroslav Halchenko Owner: Yaroslav Halchenko * Package name: python-dicom Version : 0.9.4.1 Upstream Author : Darcy Mason * URL : http://pydicom.googlecode.com * License : MIT/X Programming Lang: Python Description : DICOM medical file reading and writing pydicom is a pure python package for parsing DICOM files. DICOM is a standard (http://medical.nema.org) for communicating medical images and related information such as reports and radiotherapy objects. . pydicom makes it easy to read DICOM files into natural pythonic structures for easy manipulation. Modified datasets can be written again to DICOM format files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714214924.4988.71995.report...@novo.onerussian.com
