Bug#291370: ftp.debian.org: Please remove qce-ga source package and associated binary packages
Package: ftp.debian.org Severity: normal The package "qce-ga" and associated binary package "qce-source" should be removed from unstable & testing because it's superceded by the "qc-usb" package which is already in both distribs. (that fact is documented in the description of the qc-usb-source package) Ccing the maintainer so that he may react if I'm wrong. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#343194: Request for debian-edu-french mailing list
Package: lists.debian.org Severity: wishlist Hello, I was in Educatice (see http://lists.debian.org/debian-devel-announce/2005/11/msg00023.html) a few weeks ago and met many people from several projects all related to "free software and education". All projects are based on Debian but they have trouble integrating their work in Debian. I asked for help in that area and got several responses. Now I need a mailing list to put all people together and start working on it. Name : [EMAIL PROTECTED] Rationale : All projects mentionned above are well & healthy but they are doing their things in their corner. This list is meant to be a new central (and relatively neutral) list where : - they can speak in French together (to avoid double work) - they can be taught good Debian practices (by several Debianers who responded to my call for volunteers) - they can work together with us in integrating their work into Debian proper Short description : Discussion between french educational Debian-based projects Long description : Discussions in french between all educational Debian-based projects. This list should ease the collaboration between the projects themselves and between Debian and those projects. Category : Developers Subscription policy : open Post policy : open Web archives : yes Regards, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#336280: FTBFS: Unable to stat doc/dtd.html
reassign xsltproc 1.1.15-1
retitle 336280 xsltproc: doesn't recognize variables in some particular
situations
thanks
Le vendredi 28 octobre 2005 à 08:06 -0700, Matt Kraai a écrit :
> Package: logidee-tools
> Version: 1.2.4-2
> Severity: serious
>
> pbuilder fails to build logidee-tools in an unstable chroot on i386:
>
> > xsltproc --xinclude --stringparam selection "none" --stringparam cycle
> > "false" --stringparam charte "gfdl" --stringparam trainer "false"
> > --stringparam lang "en" --stringparam dir
> > "/tmp/buildd/logidee-tools-1.2.4/doc/tools.html" ../xsl/module-html.xsl
> > tools.xml > tools.html/index.html
> > XPath error : Undefined variable
> > not(@restriction='all' or contains(concat(' ',$selection,' '),concat('
> > ',@restriction,' '))or not(@restriction) or $selection='all')
> > ^
> > compilation error: file ../xsl/ignore.xsl line 23 element template
> > Failed to compile predicate
> > XPath error : Undefined variable
This is a bug in xsltproc ... because the variable exists and is even
defined in the command line (and also with inside the top
XSL stylesheet). I could reproduce the bug with xsltproc 1.1.15-1... and
this code has been working for 4 years already with xsltproc without any
problem.
Thus I'm reassigning the bug. I also attach "ignore.xsl" which can be
used as a minimal test case to reproduce the bug :
$ xsltproc --stringparam trainer false ignore.xsl
XPath error : Undefined variable
not(@trainer=$trainer or $trainer='true' or not(@trainer))
^
compilation error: file ignore.xsl line 9 element template
Failed to compile predicate
Regards,
--
Raphaël Hertzog -+- http://www.ouaza.com
Freexian : des développeurs Debian au service des entreprises
http://www.freexian.com
ignore.xsl
Description: application/xml
Bug#336280: [xml/sgml] Re: Bug#336280: FTBFS: Unable to stat doc/dtd.html
reassign 336280 logidee-tools retitle 336280 XSL files incorrectly use variables in match pattern thanks Le samedi 05 novembre 2005 à 18:06 +0100, Mike Hommey a écrit : > > Thus I'm reassigning the bug. I also attach "ignore.xsl" which can be > > used as a minimal test case to reproduce the bug : > > $ xsltproc --stringparam trainer false ignore.xsl > > XPath error : Undefined variable > > not(@trainer=$trainer or $trainer='true' or not(@trainer)) > > ^ > > compilation error: file ignore.xsl line 9 element template > > Failed to compile predicate > > I guess this is the same as #334784, but i don't have time to check > right now. If you have some time, would you test the patch and see if it > helps your problem ? I tried and it doesn't help. Actually it looks like #329678 because the variable is in a match pattern too ... but I don't understand your reasoning for closing the bug. If I check the Pattern grammar, it leads "Predicate" which is "[Expr]" and Expr can certainly include variables... so I checked the ChangeLog of libxslt and by recursion I found this : http://bugzilla.gnome.org/show_bug.cgi?id=303289 http://www.w3.org/TR/xslt#section-Defining-Template-Rules I hate when good features are removed because the standard says so without explaining why it makes sense ... in particular when I don't know any clean workaround to do the same thing. :-( Regards, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com
Bug#336280: [xml/sgml] Re: Bug#336280: FTBFS: Unable to stat doc/dtd.html
Le samedi 05 novembre 2005 à 20:02 +0100, Mike Hommey a écrit : > > I hate when good features are removed because the standard says so > > without explaining why it makes sense ... in particular when I don't > > know any clean workaround to do the same thing. :-( > > You can work around with xsl:choose or xsl:if clauses inside the > xsl:template. Yeah I know that, but in my case it's uglier than before. I have an ignore stylesheet which defines high priority templates to override some specific templates ... but the criteria to define "the specificity" includes this variable. This ignore stylesheet is used by several other stylesheet. I have to put dozens of xsl:if in several stylesheets when 3 generic templates did the work until now. > If you can tell which files are concerned and where i can find them, i > can help when i have some time for it (or if it's just trivial). Thanks for the offer, but I'm the upstream of logidee-tools so I know it well enough to be able to fix it myself ... It's just bothersome to do when it used to work. :-) Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com
Bug#314421: libdbd-pg-perl: Problem with placeholders in DBD::Pg
Le jeudi 16 juin 2005 à 08:21 +0200, Rico Barth a écrit :
> otrs creates an failure if PostMaster.pl calls
> through any other modules method
> DBD::Pg::db::prepare from /usr/lib/perl5/DBD/Pg.pm. The output is:
>
> #
>
> DBD::Pg::db::prepare('DBI::db=HASH(0x61d94930)',
> 'INSERT INTO article (ticket_id, article_type_id, article_s
> en...', 'HASH(0x623841b0)') called at
> /usr/lib/perl5/DBD/Pg.pm line 202
> DBD::Pg::db::do('DBI::db=HASH(0x61d94930)',
> 'INSERT INTO article (ticket_id, article_type_id,
> article_sen...
> ', 'undef', 'Test text', '2005/06/15') called at
> /usr/share/otrs/Kernel/System/DB.pm line 376
Truncated output doesn't help understand what's going on...
> It seems that's a problem of perl's dbd/pg.pm. Look at the following url:
>
>http://www.mail-archive.com/dbi-users@perl.org/msg06944.html
I doubt that you're still encountering a bug dating back to 2001 !
Please try libdbd-pg-perl 1.42-1 from unstable and see if it fixes you
bug. 1.41-3 is known to have some bugs...
Regards,
--
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org
Bug#311072: libgtkhtml1.1-3: Missing replaces in debian/control
Package: libgtkhtml1.1-3 Version: 1.1.10-4 Severity: serious Justification: Policy 7.5.1 During apt-get dist-upgrade in sarge I got : Unpacking libgtkhtml1.1-3 (from .../libgtkhtml1.1-3_1.1.10-4_i386.deb) ... dpkg: error processing /scratch/mirror/debian/pool/main/g/gtkhtml/libgtkhtml1.1-3_1.1.10-4_i386.deb (--unpack): trying to overwrite `/usr/lib/libgtkhtml-1.1.so.3', which is also in package libgtkhtml1.1-1 It looks like the package lacks an appropriate "Replaces" field. I tagged it serious as it makes a simple dist-upgrade fails but as a simple "-o dpkg::options::='--force-overwrite'" bypasses the problem you may want to downgrade it or to ignore it for sarge. Cheers, -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26-1-k7-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libgtkhtml1.1-3 depends on: ii bonobo 1.0.22-2.2 The GNOME Bonobo System. ii gdk-imlib1 1.9.14-16.2 imaging library for use with gtk ( ii libart2 1.4.2-19The GNOME canvas widget - runtime ii libaudiofile00.2.6-6 Open-source version of SGI's audio ii libbonobo2 1.0.22-2.2 The GNOME Bonobo library. ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii libdb3 3.2.9-22Berkeley v3 Database Libraries [ru ii libesd0 0.2.35-2Enlightened Sound Daemon - Shared pn libfreetype6 Not found. ii libgal23 0.24-1.4G App Libs (run time library) pn libgconf11 Not found. pn libgdk-pixbuf-gnome2 Not found. pn libgdk-pixbuf2 Not found. ii libglade-gnome0 1:0.17-3Library to load .glade files at ru ii libglade01:0.17-3Library to load .glade files at ru ii libglib1.2 1.2.10-9The GLib library of C routines ii libgnome32 1.4.2-19The GNOME libraries ii libgnomeprint15 0.37-5 The GNOME Print architecture - run ii libgnomesupport0 1.4.2-19The GNOME libraries (Support libra ii libgnomeui32 1.4.2-19The GNOME libraries (User Interfac ii libgtk1.21.2.10-17 The GIMP Toolkit set of widgets fo ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii liboaf0 0.6.10-3The GNOME Object Activation Framew pn liborbit0Not found. ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte ii libxi6 4.3.0.dfsg.1-12.0.1 X Window System Input extension li ii libxml1 1:1.8.17-10 GNOME XML library ii oaf 0.6.10-3The GNOME Object Activation Framew ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305468: libdbd-pg-perl leaks memory when using execute()
Le vendredi 22 avril 2005 à 02:07 -0700, Kevin Brown a écrit : > Okay, I've tracked this one down. The offending line is 1547, which > reads: > > currph->quoted = currph->bind_type->quote(currph->value, > currph->valuelen, &currph->quotedlen); > > This is never freed prior to re-assignment. The fix is to add: > > if (currph->quoted) Safefree(currph->quoted); > > right before it. Thank you for the patch, I sent it upstream. I hope it will be integrated soon otherwise I'll just include it as a Debian-specific patch in the mean time. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#268418: PTS: Please make latest news pages have static URLs
Le mardi 26 avril 2005 à 21:36 +0200, Filippo Giunchedi a écrit : > Thijs Kinkhorst wrote on 26-04-2005 11:55: > > > I'm willing to fix this sometime if someone can point me to the sources > > of the PTS. > > check http://cvs.debian.org/pts/?cvsroot=qa > > having MMDDhhmm as the filename for the news would be fine IMO Yes, but you still have to adapt the code to keep only the 30 latest items... Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#289690: This bug is release critical IMO
severity 289690 serious thanks This bug should really be fixed for sarge... releasing with broken Samba support isn't an option. I also encountered the bug on my side (with version 2.6.8-13 of the kernel). You must be able to find out the relevant change in the kernel bitkeeper history, isn't it ? As a starting point, you may contact the guy who posted that mail : http://lwn.net/Articles/112514/?format=printable Regards, Raphaël.
Bug#289690: This bug is release critical IMO
Le vendredi 18 mars 2005 à 18:15 +0900, Horms a écrit : > Can you please update to a more recent version of 2.6.8 and retest? Which one ? I don't know of anything newer than 2.6.8-13 ... (I was using -13 as I reported in my mail) Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#314421: libdbd-pg-perl: Problem with placeholders in DBD::Pg
Le jeudi 16 juin 2005 à 13:21 +0200, Rico Barth a écrit : > I tried libdbd-pg-perl 1.42-1 from testing and the problem is fixed. It's > possible that new version 1.42-1 from testing comes in stable as a bug fix > next time? I'll try but it's not certain. We have very strict guidelines for updates in stable. Regards, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#311361: libdbd-mysql-perl: manages insert sentences with latin1 charset incorrectly
Le mardi 31 mai 2005 à 15:37 +0200, Eduardo Garcia-Mádico Portabella a
écrit :
> There's a perl script that inserts data in mysql tables (charset latin1,
> both, tables and data for insertion). From last update to Sarge all
> non-ascii characters that we try to insert become as if the perl script
> would interpreted it as utf8. If we put a Ñ (ntilde) we get two chars
> like this Ã\u2018 into the database.
Perl 5.8 in sarge now has full UTF-8 support ... you may need to adjust
your script to make sure that you convert any UTF-8 input in something
else if needed.
> If we insert into de database with mysql command prompt it works right.
>
> The insertion SQL sentence is something like this:
>
> ###
> $query = "insert into kitz_serv_certif values (0,\'$cabecera{'cliente'}\',
> \'$cabecera{'orden'}\', \'$cabecera{'entrega'}\',\'$cabecera{'posicion'}\',
> \'$cabecera{'fecha'}\', null, \'$cabecera{'refclte'}\',
> \'$cabecera{'articulo'}\',\'$cabecera{'artclte'}\')";
Check if you don't feed UTF-8 to Mysql :
print "string is UTF8" if utf8::is_utf8($query);
You can also try adding a call to :
utf8::decode($query)
> We do not really know the exact momento that this code has stopped
> working, but we suspect it was when we updated libdbd-perl-mysql from
> woody to sarge.
You bug report doesn't look like a "bug". Your script stopped working
but it may well be that you have to enhance your script to handle UTF-8
support...
Please check the result of the various advice given above and come back
to me to tell me what happened.
Cheers,
--
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org
Bug#315385: svn-inject: fails to detect upstream version if .orig.tar.gz is a symlink
Package: svn-buildpackage Version: 0.6.7 Severity: normal I decided to use svn-buildpackage on my packages so I tried t svn-inject all my current sources. However until now I always used "uscan" (package devscripts) to download new upstream sources and this program keeps the old name to the archive but it creates a symlink with a proper name. Example: $ ls -l libxml-mini-perl_1.2.8.orig.tar.gz lrwxrwxrwx 1 rhertzog rhertzog 21 2004-11-07 09:42 libxml-mini-perl_1.2.8.orig.tar.gz -> XML-Mini-1.2.8.tar.gz This works fine with all common tools (dpkg-source, dput, etc.) Now I tried to svn-inject that package and I got this $ svn-inject libxml-mini-perl_1.2.8-2.dsc https://svn.freexian.org:8084/debian/pkg/ cp /home/rhertzog/partages/debian/paquets/XML-Mini-1.2.8.tar.gz /home/rhertzog/partages/debian/paquets/tarballs mkdir -p libxml-mini-perl/branches/upstream tar -z -x -f /home/rhertzog/partages/debian/paquets/XML-Mini-1.2.8.tar.gz mv XML-Mini-1.2.8 current svn -q import -m"[svn-inject] Installing original source of libxml-mini-perl" libxml-mini-perl https://svn.freexian.org:8084/debian/pkg/libxml-mini-perl svn -m [svn-inject] Tagging upstream source version of libxml-mini-perl copy https://svn.freexian.org:8084/debian/pkg/libxml-mini-perl/branches/upstream/current <2 more arguments> svn: Path 'current' already exists Command svn -m [svn-inject] Tagging upstream source version of libxml-mini-perl copy https://svn.freexian.org:8084/debian/pkg/libxml-mini-perl/branches/upstream/current <2 more arguments> failed, how to continue now? [Qri?]: [...] The log skips the useful arguments ... but I watches the process list and the command which fails is mostly: svn copy .../branches/upstream/current .../branches/upstream/ Checking quickly the source code, I see that $upsVersion was concatenated at the end of the last arguement. But it looks like $upsVersion is empty... so this means that svn-inject failed to guess the upstream version correctly. Furthermore, in 'tarballs' the program copied archives with the original name and not the Debian name: $ ls tarballs/ XML-Mini-1.2.8.tar.gz I'm pretty sure this will create problems later. Hope this helps. Feel free to ask questions if needed. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages svn-buildpackage depends on: ii devscripts2.8.14 Scripts to make the life of a Debi ii perl 5.8.4-8Larry Wall's Practical Extraction ii subversion1.1.4-2advanced version control system (a ii subversion-tools 1.1.4-2assorted tools related to Subversi -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315409: devscripts: Tools like debi, debc should be adapted to support svn-buildpackage
Package: devscripts Version: 2.8.14 Severity: wishlist svn-buildpackage works by default with a particular directory setup which makes tools like debi and debc fail. The generated package is not in the directory above the package tree because the current tree is not used to build the package... since the current tree is managed by subversion and an "export" is done in a completely different directory where the build really happens. That's why debi and debc should check for the presence of ".svn/deb-layout" and if that file exists they should look for the generated files under the directory "buildArea" mentionned by this file. Example of this file here : buildArea=/home/rhertzog/partages/debian/paquets/build-area origDir=/home/rhertzog/partages/debian/paquets/tarballs tagsUrl=https://svn.freexian.org:8084/debian/pkg/libdbd-pg-perl/tags trunkDir=/home/rhertzog/partages/debian/paquets/libdbd-pg-perl trunkUrl=https://svn.freexian.org:8084/debian/pkg/libdbd-pg-perl/trunk upsCurrentUrl=https://svn.freexian.org:8084/debian/pkg/libdbd-pg-perl/branches/upstream/current upsTagUrl=https://svn.freexian.org:8084/debian/pkg/libdbd-pg-perl/branches/upstream That's it. I'm sure we could find other similar improvements in the various tools provided by devscripts. For example, uscan could download new upstream tarballs in the "tarballs" directory managed by svn-buildpackage (variable origDir above). Cheers, -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages devscripts depends on: ii debianutils 2.8.4Miscellaneous utilities specific t ii dpkg-dev1.10.28 Package building tools for Debian ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii perl5.8.4-8 Larry Wall's Practical Extraction ii sed 4.1.2-8 The GNU sed stream editor -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315708: libdbd-pg-perl: execute fails with latest version
Le samedi 25 juin 2005 à 02:09 -0500, Manoj Srivastava a écrit : > Package: libdbd-pg-perl > Version: 1.42-2 > Severity: normal > > Jun 25 01:58:41 glaurung mimedefang-multiplexor[28764]: Slave 0 stderr: > DBD::Pg::st execute failed: ERROR: syntax error at or near "$1" at character > 80 > > Downgrading to libdbd-pg-perl_1.32-2_i386.deb fixes the > problem. Sorry for not debugging this more, but this is causing all > mail to be rejected, and I can't afford that here. Sorry Manoj, I can do nothing with that. Can you show me the corresponding perl script ? The version 1.42-2 is built with libpq4 and not libpq3 as indicated by your dependcies .. it is thus meant for postgresql-8.0. Which postgresql are you really using ? What about 1.42-1 or the testing version of the package ? Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#319020: reportbug: Could advertise the PTS for packages which are not very popular
Package: reportbug Version: 3.8 Severity: wishlist As member of the Debian QA Group I try to think of ways to improve the overall quality of Debian. One way is to have more contributors for each package... and to get external people involved I encourage them to subscribe to the PTS for the packages that they care about. People submitting bug reports are usually people caring about a package so I think we should try to catch their attention and to propose them to subscribe to the PTS of the package on which they're submitting a bug report. To avoid asking for contributors on packages which do not need help, reportbug could use the stats from the following file: http://master.debian.org/~hertzog/pts/count.txt Source packages not listed there have no PTS subscribers. The figures indicates how many people are subscribed to the PTS of each package. If the number is below 4, then the package needs more external contributors and reportbug should try to catch the attention of someone submitting a bug on the indicated package. Subscribing to the PTS can be done by mailing [EMAIL PROTECTED] with "subscribe " in the body. The user will then receive a confirmation mail. You could also point him to http://packages.qa.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289690: cannot access some files with samba
Le vendredi 08 avril 2005 à 19:22 -0700, Steve Langasek a écrit : > Does this bug also occur when using the cifs driver instead of the smbfs > driver? I couldn't reproduce the problem now... it looks like the bug only happens with a Windows (2000) SMB server because I tried to reproduce the problem with Samba as server and I couldn't manage it (I can't remember the name of the problematic file but I was able to md5sum all files below my directory which contained the problematic file). > It's my impression that the smbfs driver is no longer > well-maintained upstream in 2.6, and that the cifs driver is a better > choice. I'm not sure if we should consider this bug release-critical when > there are lots of other problematic smbfs bugs out there even if this one > gets fixed. Okay, then maybe a release note telling this would be welcome. Regards, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#354355: Accepted sympa 5.2.3-0.8 (source i386)
On Fri, 22 Dec 2006, Stefan Hornburg wrote: > -BEGIN PGP SIGNED MESSAGE- > Version: 5.2.3-0.8 > Distribution: experimental Jean-Charles, except #404140, do you see any other bug to be fixed before uploading this sympa package to unstable ? Any other tester ? Stefan, please upload new version with a fix for #404140 to unstable ASAP ! We need to get this version in etch soon. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#405230: ITP: python-coverage -- coverage testing tool for Python
On Tue, 02 Jan 2007, Lars Wirzenius wrote: >From the upstream web site: Coverage.py is a Python module that measures > code coverage during Python execution. It uses the code analysis tools > and tracing hooks provided in the Python standard library to determine > which lines are executable, and which have been executed. > > This is useful for developing test suites for Python software. > > (This is not really the long description, I'm not far enough yet to > formulate one.) > > I'll co-maintain the package with Wouter van Heyst. Within the python-modules team I hope ? :-) http://python-modules.alioth.debian.org/ Feel free to give me the alioth account names to be added to the project. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#354355: Please unblock sympa/5.2.3-1
Hello, Summary: in #354355, it has been reported that the current version in etch is the same than in sarge and it's so severly outdated that upstream can no longer support it security wise and that upstream developers would prefer having no sympa package at all instead of having this outdated version. After several rounds in experimental, the maintainer managed to get a working package of sympa 5.2.3 with the help of Jean-Charles Delepine. Please unblock sympa/5.2.3-1 (which is otherwise ready to go in) to solve this bug in etch. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#406935: [Pkg-sql-ledger-discussion] Re: Bug#406935: ITP: ledger-smb -- A web based double-entry accounting program
On Mon, 15 Jan 2007, Michael Schultheiss wrote: > > It would be cool if you could maintain this package within the > > "pkg-sql-ledger" team. Since ledger-smb derives from sql-ledger > > the package needs to offer a nice way to take over sql-ledger's data. > > I'd be glad to maintain ledger-smb as part of a team. Just don't hope too much from the team, we've not been doing much as a team. I just have enough time to package new upstream versions but not much more. :) > > http://alioth.debian.org/projects/pkg-sql-ledger/ > > > > Also Seneca Cunningham <[EMAIL PROTECTED]> started packaging ledger-smb, he > > gave an URL at one time but it doesn't work anymore. Seneca, maybe you can > > provide your first package to Michael ? > > I've spoken with Seneca on the ledger-smb lists and have offered to help > her get ledger-smb into Debian. Ideally we could merge our efforts so > there's no duplication of effort. Maybe Seneca should be added to the > Alioth team as well. Sure, if she gives me her alioth account name, I'll gladly add her as well. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#407521: Security fix for Django auth
On Fri, 19 Jan 2007, Marc Fargas wrote: > Hi Raphael, Hi Marc, > I just read at http://www.us.debian.org/Bugs/Developer.en.html#severities > and took the one that made more sense to me, there the only severity > that talks about "security" is "critical" so I took that. I'm not a > bug vodoo, I was just trying to give a hand marking bugs. Thanks for trying! However there's always some judgment to be made. The initial bug submitter didn't speak of security risk even though it's clear that it is a security risk in principle. So before being definitive on the issue, one always need to know how often we're exposed to the security risk. And while this information was not available, you shouldn't have increased the severity. Anyway, I've prepared updates that I'll upload to unstable and we'll see with further discussion if the package needs to go to etch or not. > Anyway, it's always good to learn a bit more on every matter, so > thanks for the lesson and accept my appologies for messing up your bug > reports. Accepted of course. :) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#407489: python-django: Should also Recommends: python-psycopg2
Hello Marc, On Thu, 18 Jan 2007, Marc Fargas wrote: > Package: python-django > Version: 0.95-2 > Severity: normal > > python-psycopg has given some trouble in the past with Django, and it's > often recommended to use python-psycopg2 instead. References ? pointers ? facts ? I never used postgresql with django so I have no idea. > The package could Recommend both and let the user decide. See #403761, people are complaining that we recommend too much already. I'd rather recommend only one python binding per database :-)) If the psycopg2 is the best one, then upstream should rename the db interface postgresql_psycopg2 to postgresql and postgresql to postgresql_psycopg1 ... :-) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#407521: Security fix for Django auth
severity 407521 important thanks On Fri, 19 Jan 2007, Marc Fargas wrote: > severity critical > tags +patch > thanks > > The current Django versión in Debian has a security hole, so this bug > should be critical, and the patch recommended by the submitter should be > applied and brought to etch, I think. Same story than before. Nobody has explained under which circumstances this bug constitutes a security risk. And you're inflating the severity without proper justification. The upstream ticket http://code.djangoproject.com/ticket/2702 doesn't mention the possible security risk. James has mentionned the problem to be that one could be granted rights that have been granted to a previous HTTP request. If such a behaviour was happening all the time, I bet it would be a very important bug... but since I see no mention of that in the upstream ticket, I believe it probably happens seldom. Has there been discussion of this problem somewhere else ? Can you tell us under which circumstances this can happen ? In the mean time, I'm downgrading. Depending on the answer to the question above, I may agree to change it back to serious. Opinions are welcome of course. Regards, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#407519: Security fix for Django i18n
severity 407519 important thanks On Fri, 19 Jan 2007, Marc Fargas wrote: > severity critical > tags +patch > thanks > > The current Django versión in Debian has a security hole, so this bug > should be critical, and the patch recommended by the submitter should be > applied and brought to etch, I think. If I understand the bug correctly, the filename of the .po must be modified to include commands with backticks... in other word, the malicious intent is easily recognisable. I expect that in 99,9% of the time, the person starting compile-messages just copied/installed the .po files where required... and he certainly would notice that the filename look very strange compared to the other files ! So I really don't agree with severity critical... which brings to the point that you shouldn't change the severity without justifying your statement. "has a security hole" is a bit short without explaining a likely case of security breach. In particular, when upstream has not considered the risk serious enough to warrant a point release... Of course, I'd like to hear opinions from others. Regards, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#407607: Minor fix for Django FastCGI handling
Hello, On Fri, 19 Jan 2007, James Bennett wrote: > package: python-django > version: 0.95-2 > > A minor problem was discovered with Django's use of flup for FastCGI > handling after the 0.95 release; flup was allowed to run in 'debug' mode > and show full tracebacks on uncaught exceptions, which could expose the > contents of application code or settings. > > This was fixed in revision 4170 of Django trunk, and a patch which > applies cleanly to stock Django 0.95 is in Django's "0.95-bugfixes" > branch (which tracks post-release updates and fixes for the 0.95 release): > > http://code.djangoproject.com/changeset/4363 Ok, following our private discussion, I'll wait for 0.95.1 to include all the bugfixes you're submitting us. :-) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#408150: bugs.debian.org: debian-admin pseudo-package.
Hello, On Wed, 24 Jan 2007, Philip Hands wrote: > I think this, or at least a dedicated request tracker for debian-admin, is > an eminently sensible idea. > > Perhaps rt would be better, since the problem with the bug tracking system > being open to all is that we're going to have to split the security > sensitive stuff out so that it's only sent to the mailing-list, and then > finding all the information for an issue later is going to be a bit of a > pain when some of it is missing from the bug report. The thing is that we're speaking of this request-tracker for years already. It takes time to setup it properly and nobody has done that yet. On the other hand it takes 5 minutes to create the entry in the BTS. I would suggest to start with that and see if it really helps. Later, we can still switch to r-t if needed. /me, as someone who'd like to help out with DSA tasks, is also in favor of this. And for Alioth administration, we also have a public tracker and it's really useful even if not really convenient to use (sucky web interface). Of course, security issues are always handled by direct mail to [EMAIL PROTECTED] I see no reason why it wouldn't be useful for DSA. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#372070: adjusting severity, flightgear package should not enter Etch like this, various bug handling
severity 371070 normal thanks On Fri, 08 Dec 2006, Eddy Petrișor wrote: > # the flightgear package is unusable on my machine, maintainer didn't > answer, > # somebody should at least confirm or infirm the bug > # breaks unrelated software > severity 372070 grave Given the comments in the bug report it looks like the game is working well (I just tested it) but it's just resource hungry and not usable on old hardware with not enough RAM. I would normally close the bug report but since I'm not the maintainer, I'm only downgrading it to normal. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#372070: adjusting severity, flightgear package should not enter Etch like this, various bug handling
# Fixing severities (typo on bug number) severity 372070 normal severity 371070 wishlist thanks Sorry for the mixup. On Fri, 15 Dec 2006, Raphael Hertzog wrote: > severity 371070 normal > thanks > > On Fri, 08 Dec 2006, Eddy Petrișor wrote: > > # the flightgear package is unusable on my machine, maintainer didn't > > answer, > > # somebody should at least confirm or infirm the bug > > # breaks unrelated software > > severity 372070 grave > > Given the comments in the bug report it looks like the game is working > well (I just tested it) but it's just resource hungry and not usable on > old hardware with not enough RAM. > > I would normally close the bug report but since I'm not the maintainer, > I'm only downgrading it to normal. > > Cheers, > -- > Raphaël Hertzog > > Premier livre français sur Debian GNU/Linux : > http://www.ouaza.com/livre/admin-debian/ > > -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#374834: menu: Patch to just fork and die, instead of waiting on a si
On Sun, 26 Nov 2006, Tim Dijkstra wrote: > No, it is not adding any race condition. If understand correctly from > the comments in the code, you are referring to the fact that the child > could print to stdout after the parent has already died, hence > cluttering other dpkg output, right? > > My patch does all the work that could print to stdout in the _parent_, > avoiding the 'race condition' altogether. All the child does is wait, > the same the original would version is supposed to do. I took a look at the patch and I understand the same. I agree it would have been nice to know exactly why the signal code doesn't work reliably but I don't see any drawback to use this new method. Please upload a fixed version ASAP. Or let us know if you need someone to do an NMU. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#387414: omniorb4: diff for NMU version 4.0.6-2.3
tags 387414 + patch
thanks
Hi,
Attached is the diff for my omniorb4 4.0.6-2.3 NMU.
To fix the bug I just used python-central instead of python-support
because python-central puts the files where omniidl expect them and
since a dependency of omniidl is also using python-central it just makes
sense.
Furthermore the dh_pysupport call was badly placed (after dh_installdeb)
so I moved my dh_pycentral further up.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -u omniorb4-4.0.6/debian/changelog omniorb4-4.0.6/debian/changelog
--- omniorb4-4.0.6/debian/changelog
+++ omniorb4-4.0.6/debian/changelog
@@ -1,3 +1,13 @@
+omniorb4 (4.0.6-2.3) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Use python-central instead of python-support because the dependency
+omniidl4-python also use that. And with that python-central uses the
+standard location which doesn't break the expectation of this package.
+Closes: #387414
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Fri, 15 Dec 2006 09:55:48 +0100
+
omniorb4 (4.0.6-2.2) unstable; urgency=low
* Non-maintainer upload.
diff -u omniorb4-4.0.6/debian/control omniorb4-4.0.6/debian/control
--- omniorb4-4.0.6/debian/control
+++ omniorb4-4.0.6/debian/control
@@ -2,7 +2,8 @@
Section: devel
Priority: optional
Maintainer: Bastian Blank <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4.1.67), python-dev, libssl-dev, autotools-dev, python-support (>= 0.4)
+Build-Depends: debhelper (>= 4.1.67), python-dev, libssl-dev, autotools-dev, python-central (>= 0.5.6)
+XS-Python-Version: current
Standards-Version: 3.7.2
Package: omniorb4
@@ -143,6 +144,7 @@
Package: omniidl4
Architecture: any
Depends: ${shlibs:Depends}, ${python:Depends}
+XB-Python-Version: ${python:Versions}
Recommends: omniidl4-python
Conflicts: omniidl
Description: omniORB4 - idl compiler
diff -u omniorb4-4.0.6/debian/rules omniorb4-4.0.6/debian/rules
--- omniorb4-4.0.6/debian/rules
+++ omniorb4-4.0.6/debian/rules
@@ -82,9 +82,9 @@
dh_link -i
dh_compress -i
dh_fixperms -i
+ dh_pycentral -i
dh_installdeb -i
# dh_perl -i
- dh_pysupport -i
dh_gencontrol -i
dh_md5sums -i
dh_builddeb -i
@@ -112,9 +112,9 @@
dh_compress -a
dh_fixperms -a
dh_makeshlibs -a -n -V
+ dh_pycentral -a
dh_installdeb -a
# dh_perl -a
- dh_pysupport -a
dh_shlibdeps -a
dh_gencontrol -a
dh_md5sums -a
Bug#397412: wmaker: Wmaker crash on creating desktop
On Tue, 05 Dec 2006, jamhed wrote: > > Well, it worked for me, and seemingly for most other people. I'm not sure > > what makes your configuration special, though :-) > > I was suspecting my 'special config', because of upgrade, so > I've installed fresh etch on another clean machine, it crashed there too. > > That makes me think there is something wrong. > > It was netinst from this mirror: http://ftp.kulnet.kuleuven.ac.be/debian I could reproduce the bug. It's locale-dependent. Using ru_RU.KOI8-R or ru_RU.UTF-8 allowed me to reproduce the bug. How to reproduce: - dpkg-reconfigure locales and activate ru_RU.KOI8-R - if you never used windowmaker start it in your current locale and create a second desktop (I don't understand russian) this is done with right click on the desktop and then follow the menu Workspace/Workspaces/New - kill wmaker and restart it with: $ export LC_ALL=ru_RU.KOI8-R $ wmaker (I also unset the various other LANG* env variables just for safety) Valgrind didn't give any useful information because /usr/bin/wmaker is just a shell script. Running it on WindowMaker gives something more interesting: $ LC_ALL=ru_RU.KOI8-R valgrind WindowMaker ==21367== Memcheck, a memory error detector. ==21367== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==21367== Using LibVEX rev 1658, a library for dynamic binary translation. ==21367== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==21367== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==21367== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==21367== For more details, rerun with: -v ==21367== ==21367== Invalid read of size 4 ==21367==at 0x4010E00: (within /lib/ld-2.3.6.so) ==21367==by 0x4004B78: (within /lib/ld-2.3.6.so) ==21367==by 0x4006792: (within /lib/ld-2.3.6.so) ==21367==by 0x428A2AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==21367==by 0x400B44E: (within /lib/ld-2.3.6.so) ==21367==by 0x4289D1E: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==21367==by 0x4186D8D: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x400B44E: (within /lib/ld-2.3.6.so) ==21367==by 0x418742C: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x4186D20: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x40B3448: (within /usr/lib/libX11.so.6.2.0) ==21367==by 0x40B3756: _XNoticeCreateBitmap (in /usr/lib/libX11.so.6.2.0) ==21367== Address 0x44D8780 is 24 bytes inside a block of size 25 alloc'd ==21367==at 0x401D38B: malloc (vg_replace_malloc.c:149) ==21367==by 0x4006B83: (within /lib/ld-2.3.6.so) ==21367==by 0x428A2AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==21367==by 0x400B44E: (within /lib/ld-2.3.6.so) ==21367==by 0x4289D1E: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==21367==by 0x4186D8D: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x400B44E: (within /lib/ld-2.3.6.so) ==21367==by 0x418742C: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x4186D20: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x40B3448: (within /usr/lib/libX11.so.6.2.0) ==21367==by 0x40B3756: _XNoticeCreateBitmap (in /usr/lib/libX11.so.6.2.0) ==21367==by 0x40B3B3C: XCreatePixmap (in /usr/lib/libX11.so.6.2.0) ==21367== ==21367== Conditional jump or move depends on uninitialised value(s) ==21367==at 0x4008ED5: (within /lib/ld-2.3.6.so) ==21367==by 0x428A704: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==21367==by 0x400B44E: (within /lib/ld-2.3.6.so) ==21367==by 0x4289D1E: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==21367==by 0x4186D8D: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x400B44E: (within /lib/ld-2.3.6.so) ==21367==by 0x418742C: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x4186D20: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x40B3448: (within /usr/lib/libX11.so.6.2.0) ==21367==by 0x40B3756: _XNoticeCreateBitmap (in /usr/lib/libX11.so.6.2.0) ==21367==by 0x40B3B3C: XCreatePixmap (in /usr/lib/libX11.so.6.2.0) ==21367==by 0x40B29BF: XCreateBitmapFromData (in /usr/lib/libX11.so.6.2.0) ==21367== ==21367== Conditional jump or move depends on uninitialised value(s) ==21367==at 0x4008B2E: (within /lib/ld-2.3.6.so) ==21367==by 0x428A704: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==21367==by 0x400B44E: (within /lib/ld-2.3.6.so) ==21367==by 0x4289D1E: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==21367==by 0x4186D8D: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x400B44E: (within /lib/ld-2.3.6.so) ==21367==by 0x418742C: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x4186D20: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==21367==by 0x40B3448: (within /usr/lib/libX11.so.6.2.0) ==21367==by 0x40B3756: _XNoticeCreateBitmap (in /usr/lib/libX11.so.6.2.0) ==21367==by 0x40B3B3C: XCreatePixmap (in /usr/lib/libX11.s
Bug#374834: menu: Patch to just fork and die, instead of waiting on a si
On Fri, 15 Dec 2006, Bill Allombert wrote: > On Fri, Dec 15, 2006 at 11:30:57AM +0100, Raphael Hertzog wrote: > > I took a look at the patch and I understand the same. > > > > I agree it would have been nice to know exactly why the signal code > > doesn't work reliably but I don't see any drawback to use this new > > method. > > Can you reproduce the problem and check the patch actually fix it ? No, I don't remember having encountered this problem, but the information provided by others looks convincing. I would apply the patch, check that update-menus still works according to your wishes and trust the others to verify that it fixed the problem. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#403088: Bug#403090: libemail-abstract-perl: FTBFS: Can't locate object method "_headers_as_string" via package "Email::MIME"
reassign 403088 libemail-mime-perl retitle 403088 libemail-mime-perl: backwards incompatible change leading to FTBFS in etch found 403088 1.851-1 close 403088 1.857-1 thanks Hi, On Thu, 14 Dec 2006, Lucas Nussbaum wrote: > During a rebuild of all packages in etch, I discovered that your package > failed to build on i386. > > Relevant parts: > /usr/bin/make test > make[1]: Entering directory `/build/root/libemail-abstract-perl-2.131' > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'blib/lib', 'blib/ar > ch')" t/*.t > t/abs-object..Can't locate object method "_headers_as_string" via package > "Email::MIME" at /usr/ > share/perl5/Email/MIME.pm line 20, line 1. This is the same error as in #403088. It was a bug in libemail-mime-perl which just got fixed. So closing this bug and fixing the version tracking info so that release managers make sure to include the proper libemail-mime-perl version. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#398371: xfingerd: installation fails: invoke-rc.d: unknown initscript, /etc/init.d/inetd not found.
tags 398371 - patch
thanks
On Sun, 26 Nov 2006, Alex de Oliveira Silva wrote:
> tags 398371 + patch
> thanks
>
> Even though this a simple fix, I provide anyhow a patch for it.
It's not a proper fix IMO because we now use openbsd-inetd by default.
And there's not good way to reliably restart the inetd superserver without
checking individually which one is currently used.
> diff -ur xfingerd-0.6.orig/debian/control xfingerd-0.6/debian/control
> --- xfingerd-0.6.orig/debian/control2006-11-26 20:42:38.0 -0300
> +++ xfingerd-0.6/debian/control 2006-11-26 20:45:24.0 -0300
> @@ -7,7 +7,7 @@
>
> Package: xfingerd
> Architecture: any
> -Depends: ${shlibs:Depends}, ${misc:Depends}, netbase
> +Depends: ${shlibs:Depends}, ${misc:Depends}, netbase, netkit-inetd
The depends needs to be on "inet-superserver" and the postinst needs to be
smarter... it must check for the availability of the various possible
startup script before trying to invoke it.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#397412: wmaker: Wmaker crash on creating desktop
On Fri, 17 Nov 2006, Steinar H. Gunderson wrote:
> Well, it's a step, at least, but it doesn't really help all that much. Lines
> 123 and 124 are
>
> 123 wWorkspaceMenuUpdate(scr, scr->workspace_menu);
> 124 wWorkspaceMenuUpdate(scr, scr->clip_ws_menu);
I've put a breakpoint on line 122 and checked the evolution of the various
variables here:
Breakpoint 1, wWorkspaceNew (scr=0x80f0530)
at
/home/rhertzog-deb/partages/debian/paquets/NMU/wmaker-0.92.0/src/workspace.c:123
123 wWorkspaceMenuUpdate(scr, scr->workspace_menu);
(gdb) print scr
$1 = (WScreen *) 0x80f0530
(gdb) print scr->clip_ws_menu
$2 = (struct WMenu *) 0x0
(gdb) print scr->workspace_menu
$3 = (struct WMenu *) 0x817da38
(gdb) n
121 scr->workspaces = list;
(gdb) n
123 wWorkspaceMenuUpdate(scr, scr->workspace_menu);
(gdb) print scr
$4 = (WScreen *) 0x80f0530
(gdb) print scr->clip_ws_menu
$5 = (struct WMenu *) 0x0
(gdb) print scr->workspace_menu
$6 = (struct WMenu *) 0x817da38
(gdb) n
124 wWorkspaceMenuUpdate(scr, scr->clip_ws_menu);
(gdb) print scr->clip_ws_menu
Cannot access memory at address 0x3220c0a0
(gdb) print scr
$7 = (WScreen *) 0x3220bed0
I tried to look in the code how "scr" could be modified but I didn't find
anything self-evident. :-/
> And the only way it could SIGSEGV in line 124, was if scr (that is, the
> pointer) was somehow invalid -- but if line 123 was run first (which I'd
> assume, even with -O2), scr would have to be valid (unless, of course,
> wWorkspaceMenuUpdate was inlined, but it's big and -O2 doesn't normally
> inline functions like that).
Stepping inside the function line 123 gives this:
Breakpoint 1, wWorkspaceNew (scr=0x80f0530)
at
/home/rhertzog-deb/partages/debian/paquets/NMU/wmaker-0.92.0/src/workspace.c:123
123 wWorkspaceMenuUpdate(scr, scr->workspace_menu);
(gdb) print scr
$1 = (WScreen *) 0x80f0530
(gdb) step
121 scr->workspaces = list;
(gdb) step
123 wWorkspaceMenuUpdate(scr, scr->workspace_menu);
(gdb) step
wWorkspaceMenuUpdate (scr=0x80f0530, menu=0x817da38)
at
/home/rhertzog-deb/partages/debian/paquets/NMU/wmaker-0.92.0/src/workspace.c:1410
1410if (!menu)
(gdb) step
1403{
(gdb) step
1410if (!menu)
(gdb) step
1413if (menu->entry_no < scr->workspace_count+2) {
(gdb) n
1415i = scr->workspace_count-(menu->entry_no-2);
(gdb) s
1417while (i>0) {
(gdb) s
1418strcpy(title, scr->workspaces[ws]->name);
(gdb) print title
$2 = "\000\002\000\000\000ô_Þ·ÀtÞ·\030%\026\bhsÚ¿ÂåÑ·ÀtÞ·\030%\026\b"
(gdb) n
1422entry->flags.editable = 1;
(gdb) print title
$3 = "\000\002\000\000\000ô_Þ·ÀtÞ·\030%\026\bhsÚ¿ÂåÑ·ÀtÞ·\030%\026\b"
(gdb) n
1418strcpy(title, scr->workspaces[ws]->name);
(gdb) n
1422entry->flags.editable = 1;
(gdb) n
1420entry = wMenuAddCallback(menu, title, switchWSCommand,
(void*)ws);
(gdb) n
1422entry->flags.editable = 1;
(gdb) n
1417while (i>0) {
(gdb) n
1433wMenuRealize(menu);
(gdb) n
1435for (i=0; iworkspace_count; i++) {
(gdb) n
1436menu->entries[i+2]->flags.indicator_on = 0;
(gdb) n
1435for (i=0; iworkspace_count; i++) {
(gdb) n
1436menu->entries[i+2]->flags.indicator_on = 0;
(gdb) n
1435for (i=0; iworkspace_count; i++) {
(gdb) n
1436menu->entries[i+2]->flags.indicator_on = 0;
(gdb) n
1435for (i=0; iworkspace_count; i++) {
(gdb) n
1436menu->entries[i+2]->flags.indicator_on = 0;
(gdb) n
1435for (i=0; iworkspace_count; i++) {
(gdb) n
1438menu->entries[scr->current_workspace+2]->flags.indicator_on = 1;
(gdb) n
1441if (scr->current_workspace == scr->workspace_count-1) {
(gdb) n
1444wMenuSetEnabled(menu, 1, True);
(gdb) print menu
$5 = (WMenu *) 0x817da38
(gdb) n
1447tmp = menu->frame->top_width + 5;
(gdb) n
1449if (menu->frame_x < tmp - (int)menu->frame->core->width)
(gdb) n
1447tmp = menu->frame->top_width + 5;
(gdb) n
1449if (menu->frame_x < tmp - (int)menu->frame->core->width)
(gdb) n
1452wMenuPaint(menu);
(gdb) n
1453}
(gdb) n
wWorkspaceNew (scr=0x3220bed0)
at
/home/rhertzog-deb/partages/debian/paquets/NMU/wmaker-0.92.0/src/workspace.c:124
124 wWorkspaceMenuUpdate(scr, scr->clip_ws_menu);
So the only solution is that something is overwriting the part of the
memory which contains the pointer "scr". But I don't know how to find out
what is responsible of that.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#354355: News up to date debian package for sympa
severity 354355 serious thanks On Fri, 15 Dec 2006, Christian Perrier wrote: > > As already said last year, I'm ready for comaintain or maintain this > > package. > > I'm following the sympa PTS for years and I'm afraid that I have to > confirm Jean-Charles statement. Agreed. And given the request of the upstream authors I believe we should consider this bug as release critical, thus raising the severity of this bug. I know we're pretty late in the cycle but sympa is an "external" package (ie no other packages depend on it) and it can be easily removed/updated without creating trouble to the rest of the distribution. So I'm all in favor to request the inclusion of a new upstream version... on the ground that the current version is unsupported (including security-wise) upstream. > I hereby confirm again that I'm ready to help Jean-Charles to keep an > up-to-date sympa, would he take the package over. That would mostly > include sponsoring as I can't really add more burden on my own > shoulders (and, anyway, my expertise on sympa is pretty low). Same for me. I'm also using it so I can test it. It's a pity Stefen never responded positively to co-maintenance offer. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#403089: RFS: libemail-find-perl update for FTBFS tests failed bug
Hi, On Fri, 15 Dec 2006, Francesco Cecconi wrote: > Hi Florian, > > > Looking good so far, but why do you edit in debian/changelog the date > > fields of 0.09-4 and 0.09-3? Removing the trailing space in > > 0.09-dfsg-1 is acceptable, but why the other changes? > > I have fixed this problem. And I uploaded the package. Please when you request a sponsor for an upload which fixes a RC bug please record that in the BTS so that people actively trying to reduce the number of RC bugs can sponsor you. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#403089: RFS: libemail-find-perl update for FTBFS tests failed bug
Hi, On Sat, 16 Dec 2006, Francesco Cecconi wrote: > > And I uploaded the package. > > Excuse me Raphael, have you a problems with upload the package? Right, sorry, I was about to upload it and got distracted by something else. :-) It's uploaded now. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#354355: News up to date debian package for sympa
On Fri, 15 Dec 2006, Raphael Hertzog wrote: > > I'm following the sympa PTS for years and I'm afraid that I have to > > confirm Jean-Charles statement. > > Agreed. And given the request of the upstream authors I believe we should > consider this bug as release critical, thus raising the severity of this > bug. > > I know we're pretty late in the cycle but sympa is an "external" package > (ie no other packages depend on it) and it can be easily removed/updated > without creating trouble to the rest of the distribution. So I'm all in > favor to request the inclusion of a new upstream version... on the ground > that the current version is unsupported (including security-wise) upstream. After some discussion with Andreas Barth, he indicated me that we need to move very fast to resolve this for etch or we'll end up with no sympa package at all. Stefen, please take position quickly or I'll upload the new package of Jean-Charles to unstable on monday/tuesday. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#354355: Accepted sympa 5.2.3-0.1 (source i386)
On Mon, 18 Dec 2006, Stefan Hornburg wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Format: 1.7 > Date: Mon, 18 Dec 2006 09:24:57 +0100 > Source: sympa > Binary: sympa > Architecture: source i386 > Version: 5.2.3-0.1 > Distribution: experimental Stefan, why are you ignoring all the comments in #354355 ? In response to #354355, you should at least upload that package in unstable. And replying to the various people who are writing to you would be nice. You can't continue doing your stuff in your corner without taking into account the remarks of the upstream authors, of fellow DD, etc., in particular given the backlog of bugs that you accumulated on sympa. (My deadline ends tomorrow, if you have not taken position at that time I will continue as announced) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#354355: Accepted sympa 5.2.3-0.1 (source i386)
Hello, thanks for your answer. On Mon, 18 Dec 2006, Stefan Hornburg (Racke) wrote: > I'm in the progress in merging the package offered by Jean Charles Delepine > into my sources. While it is definitely better than my last released > package, it still has rough edges. If you are not satisfied with the > result tomorrow, please let me know. Good news! I'll watch out for the next upload. What about the co-maintenance with Jean-Charles ? You could easily svn-inject your current version into the collab-maint SVN repository and then you could work together with Jean-Charles without troubles and mutually review the patches and so on. I can help setting that up if needed (and you can use something else than subversion if you prefer). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#354355: sympa: Please stop kidding
Hi, On Tue, 19 Dec 2006, Jean Charles Delepine wrote: > "Stefan Hornburg (Racke)" <[EMAIL PROTECTED]> écrivait (wrote) : > > > I'll take this out. It is more hassle than it is really worth. > > We need, now, a workable package for etch. 5.2.3-0.2 is not that > package, 5.2.3-0.3 will have bugs not in my 5.2.3-0.7. > > Please upload to unstable 5.2.3-0.8 which will be 5.2.3-0.7 + your > improvements on 5.2.1-0.1. Jean-Charles, can you prepare such a package and svn-inject it in svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/ ? Please inject at least the 0.7 version, even if you don't have time to incorporate Stefen's improvement. It's really time you both start working on the same infrastructure. We need an upload to unstable RSN ! Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#354355: sympa: Please stop kidding
On Wed, 20 Dec 2006, Jean Charles Delepine wrote: > I therefore choose to svn-inject Stefen's 5.2.3-0.5, and wish he will > use it. > > http://svn.debian.org/wsvn/collab-maint/deb-maint/sympa/?rev=2087&sc=1 Stefen, you have write access to this svn repository. Please use it to maintain the package. It will ease our work. I don't know if you're familiar with svn-buildpackage, if not please check out some related documentation: - man svn-buildpackage - http://pkg-perl.alioth.debian.org/subversion.html (some doc from the perl team which uses heavily svn with the same structure than in collab-maint) And if you have questions, feel free to ask. > We are loosing soap configuration. Mysql without root pass, dpatch > usage, not much else. Dpatch usage is not really problematic. The two others might be... can you add support for them without completely reworking Stefen's package ? I suggest sending a patch to Stefen for review, and if he finds the patch OK, either he applies it or he let you apply it directly. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#354355: sympa: Please stop kidding
Hi Stefan, On Wed, 20 Dec 2006, Stefan Hornburg (Racke) wrote: > >Stefen, you have write access to this svn repository. Please use it to > >maintain the package. It will ease our work. I don't know if you're > >familiar with svn-buildpackage, if not please check out some related > >documentation: > >- man svn-buildpackage > >- http://pkg-perl.alioth.debian.org/subversion.html (some doc from the > > perl team which uses heavily svn with the same structure than in > > collab-maint) > > > >And if you have questions, feel free to ask. > > How does the initial checkout command looks like ? Here's how to get it going with initial checkout, retrieval of the required tarball and first build: $ mkdir svn $ cd svn $ svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/sympa/trunk sympa Asympa/debian Asympa/debian/control [...] $ mkdir tarballs $ cd tarballs/ $ wget http://ftp.debian.org/debian/pool/main/s/sympa/sympa_5.2.3.orig.tar.gz $ cd ../sympa $ svn-buildpackage [...] $ ls ../build-area/ sympa_5.2.3-0.5.diff.gz sympa_5.2.3-0.5_i386.build sympa_5.2.3-0.5_i386.deb sympa_5.2.3-0.5.dsc sympa_5.2.3-0.5_i386.changes sympa_5.2.3.orig.tar.gz Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#404019: sympa doesn't like netapps
On Thu, 21 Dec 2006, Jean Charles Delepine wrote: > Package: sympa > Version: 5.2.3-0.5 > Severity: wishlist > Tags: patch > > While installing sympa with /var/lib/sympa/ imported from an netapp : > > Installing new version of config file /etc/logrotate.d/sympa ... > > chown: changing ownership of `/var/lib/sympa/.snapshot': Read-only > > file system > > > One solution is to ignore chown and chmod exit value : I don't think it's a good idea to ignore such failures! The installation rightfully fails if it can't set the proper modes/owners. Afte a failure you remount your netapp rw, and restart the install... What specific use case do you have ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#404019: sympa doesn't like netapps
On Thu, 21 Dec 2006, Jean Charles Delepine wrote: > > What specific use case do you have ? > > On an netapp .snapshot/ is read-only, but only .snapshot. And .snapshot is only at the root of the mount point or in all directories? > I can't think of a failure on chmod/chown which should'nt have make the > install crash before in the process. By not crashing here we let the > install finish, databese, web server, and the admin will have clear > error logs if sympa can't start. The nice solution is to exclude .snapshot from the recursive chmod/chown. But I don't like the idea to have to do that just because netapps put a special directory there... cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#396897: acpi-support: wrong order for video PCI state
Hi, On Fri, 03 Nov 2006, Kapil Hari Paranjape wrote: > Thanks for the tremendous job of sorting out these issues. Thanks but the credit really goes to Matthew Garrett and the other Ubuntu guys who created this package. > The IBM R51 (2887NQ9) laptop that I have does not suspend/resume > unless the video state of PCI is the *last* thing that is saved > and the first thing that is restored (w.r.t the video card). > > Once that is done, the suspend/resume works fine. So it looks like you managed to get it working. Can you provide the corresponding change in the form of a patch? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#397168: websvn: Default colors for diff are too dark
Package: websvn
Version: 1.61-13
Severity: minor
We're using Websvn on svn.debian.org and a user reported that the default
colors for diffs are too dark. He suggests replacing 3 CSS styles in the
various themes:
Original values:
TD.diffdeleted
{
font-size: 11px;
background-color: red;
}
TD.diffchanged
{
font-size: 11px;
background-color: yellow;
}
TD.diffadded
{
font-size: 11px;
background-color: green;
}
Suggested values are:
TD.diffdeleted
{
font-size: 11px;
background-color: #ffb0b0;
}
TD.diffchanged
{
font-size: 11px;
background-color: #b0;
}
TD.diffadded
{
font-size: 11px;
background-color: #b0ffb0;
}
And I agree with the submitter that text is difficult to read at least on the
"green" background.
For reference here's the gforge request that we received:
http://alioth.debian.org/tracker/index.php?func=detail&aid=302155&group_id=1&atid=21
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397147: About handling of bugs and changelog entries
Hello pkg-voip maintainers, I'm a bit astonished on how the bugs 375141 and 397147 have been handled. While recompiling the testing version of asterisk I discovered that I lost ogg support because of the lack of build-depends so I start looking on the bugs and find out #375141 which reports the problem. This bug has been closed with this sentence: - format_ogg_vorbis.so was present in i386, no longer in packages (Closes: #375141) Sorry this is NOT a changelog entry, we don't know why it's fixed and how you fixed it or if you simply decided that Ogg support was not worth having. In the mean time the real bug is still here: i386 is the only arch with OGG support because it's compiled by the maintainer on a system with libvorbis-dev installed but the other archs don't have it and any custom recompilation (like mine) may result in a binary without ogg support. The bug is reported again with #397147 and this time the submitter was skilled enough to point out to the real problem and the real fix got integrated but the changelog entry is still as bad: [ Mark Purcell ] * asterisk-classic, asterisk-bristuff: /usr/lib/asterisk/modules/format_ogg_vorbis.so gone missing when rebuilt (Closes: #397147 You describe the problem but a changelog is here to describe the change and in particular the fix made to correct the problem. This is very important if you want to have good feedback from users/testers/bug reporters. I need to know what changed by looking at the changelog so that I can check if the fix is the one that I expected. Please take some more care in the future, and many thanks for your work on asterisk! Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#389511: Please send patch upstream
On Sat, 11 Nov 2006, Paul Sladen wrote: > It would be useful if this fix could be filed and sent upstream: > > https://launchpad.net/distros/ubuntu/+source/acpi-support/+filebug Feel free to do so to help us. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#391023: XS-Vcs-field splitting into XS-Vcs-source & XS-Vcs-dpkg
On Sun, 12 Nov 2006, Geert Stappers wrote: > The text tells about the (upstream) source by using the generic name > "package", the example tells about the Debian directory. So fix the wording... and don't change everything when there has been some serious discussion on -devel and when lots of packages have started using this convention already. > So I propose to split into XS-Vcs-source-* & XS-Vcs-dpkg-* Please, no. The Debian source package is not meant as a source of generic meta-information of the upstream project. If you really want to make this kind of information available, you'd rather work on something useful for this like the collaborative repository of meta-information: http://wiki.debian.org/CRMI (which might be implemented within mole http://wiki.debian.org/mole) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#398288: baobab: Fails to handle (recursive) bind mounts
Package: baobab
Version: 2.4.2-1.1+b1
Severity: important
I store chroots of Debian Sid/Sarge within my home directory (in
/home/rhertzog/local/chroot/{sarge,unstable}). And since I often work in
those chroot I use "bind mount" to share the /home directory between the
chroots and the main system (/).
$ mount
/dev/hda6 on / type ext3 (rw,errors=remount-ro,commit=0)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,nodev)
/dev/hda7 on /home type ext3 (rw,commit=0)
/etc on /home/rhertzog/local/chroot/unstable/etc/.host type none (rw,bind)
/home on /home/rhertzog/local/chroot/unstable/home type none (rw,bind)
/tmp on /home/rhertzog/local/chroot/unstable/tmp type none (rw,bind)
/dev on /home/rhertzog/local/chroot/unstable/dev type none (rw,bind)
/etc on /home/rhertzog/local/chroot/sarge/etc/.host type none (rw,bind)
/home on /home/rhertzog/local/chroot/sarge/home type none (rw,bind)
/tmp on /home/rhertzog/local/chroot/sarge/tmp type none (rw,bind)
/dev on /home/rhertzog/local/chroot/sarge/dev type none (rw,bind)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
Now I'm a bit short on space and wanted to use baobab to see which
directories use the most space. But I stopped its scan once it
was scanning the content of "/home/rhertzog/local/chroot/unstable/home"
which is another way to access /home... and obviously the result would
have been wrong because it would have counted some files twice.
I asked baobab to scan the folder "/home/rhertzog" when I did this.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages baobab depends on:
ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi
ii libatk1.0-01.12.3-1 The ATK accessibility toolkit
ii libbonobo2-0 2.14.0-2 Bonobo CORBA interfaces library
ii libbonoboui2-0 2.14.0-5 The Bonobo UI library
ii libc6 2.3.6.ds1-7 GNU C Library: Shared libraries
ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra
ii libfontconfig1 2.4.1-2 generic font configuration library
ii libgconf2-42.16.0-2 GNOME configuration database syste
ii libglade2-01:2.6.0-2 library to load .glade files at ru
ii libglib2.0-0 2.12.4-1 The GLib library of C routines
ii libgnome-keyring0 0.6.0-2 GNOME keyring services library
ii libgnome2-02.16.0-2 The GNOME 2 library - runtime file
ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display
ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf
ii libgnomevfs2-0 2.14.2-2+b1 GNOME virtual file-system (runtime
ii libgtk2.0-02.8.20-3 The GTK+ graphical user interface
ii libgtop2-7 2.14.4-1 gtop system monitoring library
ii libice61:1.0.1-2 X11 Inter-Client Exchange library
ii liborbit2 1:2.14.3-0.1 libraries for ORBit2 - a CORBA ORB
ii libpango1.0-0 1.14.7-1 Layout and rendering of internatio
ii libpopt0 1.10-3lib for parsing cmdline parameters
ii libsm6 1:1.0.1-3 X11 Session Management library
ii libx11-6 2:1.0.3-2 X11 client-side library
ii libxcursor11.1.7-4 X cursor management library
ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar
ii libxfixes3 1:4.0.1-4 X11 miscellaneous 'fixes' extensio
ii libxi6 1:1.0.1-3 X11 Input extension library
ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library
ii libxml22.6.27.dfsg-1 GNOME XML library
ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library
ii libxrender11:0.9.1-3 X Rendering Extension client libra
baobab recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401694: dpkg from apt-get do not report which package have broken syntax
On Wed, 06 Dec 2006, Nicolas François wrote: > On Tue, Dec 05, 2006 at 01:13:08PM +0100, Rafal Maj wrote: > > Package: dpkg > > Version: 1.13.21 > > Severity: normal > > > > While doing apt-get update today (debian testing) I got: > > > > dpkg: version '>= 2.3' has bad syntax: version string has embedded spaces > > > > I suppose one of the packages have a bug in it's debian rules file, but > > which one? IMHO dpkg should print this in the error string. > > This string is displayed when versions are compared with dpkg > --compare-versions. > > dpkg cannot know which package may use wrong version numbers. > Thus reassigning to apt. Hey, apt probably doesn't use dpkg --compare-versions directly, it's most probably a (post|pre)(inst|rm) script which did it. The bug submitter should give some lines of context because the error certainly didn't happen "alone" just after having typed "apt-get upgrade". Rafal, please give us the log of the upgrade. Check out /var/log/dpkg.log if you don't have the log available to know which packages got upgraded the day where you reported the bug. If we don't know which packages is causing the problem your bug report will be useless and most probably closed. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#398899: Bug#399986: Bug#398899: reopen, still fails
Hello Changwoo, On Tue, 05 Dec 2006, Changwoo Ryu wrote: > Well, the problem is still on python-central, exactly dh_pycentral which > has been used during package build. Before these stupid binary-only > uploads, the packages had the correct Depends, "python (>= 2.3), python > (<< 2.4)". But the new rebuilt revisions have just "python (>= 2.3)". The binary NMU are not stupid... but your packaging is no more compliant with the latest python policy. python2.3 won't be shipped in etch and is removed from sid already (or is going to be removed soon). The old dependency "python (>= 2.3), python > (<< 2.4)" can't be met in etch/sid. So dh_pycentral is not going to generate a dependency which results in an uninstallable package. Please either change the package to work with python 2.4 (and any other new upstream version) or remove the package completely. And the same applies to python-cjkcodecs (#398039). Please take a decision and we could provide you some more help. We're speaking of RC bugs here, please act promptly. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#400192: debconf setting are not written into libnss-ldap.conf
severity 400192 serious thanks On Fri, 24 Nov 2006, Frederik Wagner wrote: > The libnss-ldap package does not evaluate preseeded debconf settings. As discussed with Olivier Berger and Steinar Gundersson, this bug is a regression introduced by a previous NMU. Steinar reviewed the latest patch of Olivier and it's sane according to him. Stefen, you have not commented that important bug dating back to 45 days. You deserve to be NMUed right away... I'm *only* bumping the severity to serious to make sure that the bug gets fixed before the release because many custom installations rely on this feature to provide an out-of-the box working LDAP configuration. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#400192: debconf setting are not written into libnss-ldap.conf
Hi, On Wed, 10 Jan 2007, Christian Perrier wrote: > Raphaël, > > I was also intending to NMU this package to fix its longstanding > ignored po-debconf translations (AND fix the translations). > > I notified Stephen 2/3 days ago and got no answer yet. > > Given the urgency of fixing that RC bug, do you think we could > coordinate? Sure. > libnss-ldap.patch: > > -incorporates all pending l10n bugs for po-debconf without any change > > libnss-ldap.patch2: > > -same as previous plus: > - rewrite debconf templates for DevRef compliance > - Add debconf-updatepo to the clean target > - Remove useless DH_COMPAT in debian/rules Changing the debhelper compatibility level is no more OK in the freeze so this would create problem transitioning to testing. > I would recommend using the first patch with an immediate RC fix > upload, get this transit to testing and then leave me working on the > second patch and upload another NMU (unless Stephen raises his hand at > some moment). Agreed. Feel free to use libnss-ldap.patch + Olivier's patch for a first NMU. :) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#406935: ITP: ledger-smb -- A web based double-entry accounting program
Hello, On Mon, 15 Jan 2007, Michael Schultheiss wrote: > Package: wnpp > Severity: wishlist > Owner: Michael C. Schultheiss <[EMAIL PROTECTED]> > > * Package name: ledger-smb > Version : 1.1.7 > Upstream Author : LedgerSMB Core Team > * URL : http://www.ledgersmb.org/ > * License : GPL > Programming Lang: Perl > Description : A web based double-entry accounting program > > LedgerSMB is a double-entry accounting system written in Perl. Data is > stored in a SQL database server and displayed through a web browser. > The system is linked by a chart of accounts. All transactions for AR, > AP, and GL are stored in a transaction table. Hyperlinks from the chart > of accounts let you view transactions posted through AR, AP, and GL. It would be cool if you could maintain this package within the "pkg-sql-ledger" team. Since ledger-smb derives from sql-ledger the package needs to offer a nice way to take over sql-ledger's data. I'll gladly add you to the team if you accept. Packaging ledger-smb is on my TODO list for quite some time and I'll happily review your work. http://alioth.debian.org/projects/pkg-sql-ledger/ Also Seneca Cunningham <[EMAIL PROTECTED]> started packaging ledger-smb, he gave an URL at one time but it doesn't work anymore. Seneca, maybe you can provide your first package to Michael ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#384094: python2.5: the same thing with 2.5-3
clone 384094 -1
reassign -1 python2.5-minimal 2.5-3
retitle -1 Python2.5 fails to install with python-minimal 2.4.3-11 from etch
severity 384094 important
retitle 384094 python-central: inconsistent handling of list of installed
runtimes
found 384094 0.5.10
thanks
On Wed, 15 Nov 2006, Igor Goryachev wrote:
> Setting up python2.5-minimal (2.5-3) ...
> Linking and byte-compiling packages for runtime python2.5...
> pycentral: pycentral rtinstall: installed runtime python2.5 not found
> pycentral rtinstall: installed runtime python2.5 not found
The problem is not with python-central itself but with the version of
python-minimal that is used in combination.
The problem can only be reproduced in etch which has python-minimal
2.4.3-11. The version 2.4.4-1 from sid has an updated
/usr/share/python/debian_defaults which knows python2.5:
$ cat /usr/share/python/debian_defaults
[DEFAULT]
# the default python version
default-version = python2.4
# all supported python versions
supported-versions = python2.4
# formerly supported python versions
old-versions = python2.3
# unsupported versions, including older versions
unsupported-versions = python2.3, python2.5
Whereas etch doesn't:
$ cat /usr/share/python/debian_defaults
[DEFAULT]
# the default python version
default-version = python2.4
# all supported python versions
supported-versions = python2.3, python2.4
# formerly supported python versions
#old-versions = python2.3
So the proper fix is to make sure that a good version of python-minimal is
setup before the install of python2.5. So the bug is in python2.5-minimal
and I'm reassigning it.
Apart from that, python-central still does very weird things in the way it
handles the list of supported runtimes.
The function get_supported_runtimes() has been modified to accept a
parameter "with_unsupported" which defaults to True and it's only used
with explicit assignation to "True". So I believe the default value should
have been false. However the action "RuntimeInstall" calls the function
without indicating with_unsupported=True which means that if the default
value is changed to False, this failure will happen again even if the
good version of python-minimal is installed.
for rt in get_installed_runtimes():
if rt.name == self.rtname:
self.runtime = rt
break
if not self.runtime:
self.error('installed runtime %s not found' % self.rtname)
I'll prepare an NMU of python 2.5 to fix the RC problem. And I'm downgrading
this bug so that this inconsistent handling of installed runtimes can be fixed
later.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#397006: python2.5: the same thing with 2.5-3
# Cleaning my mistakes unmerge 384094 reassign 384094 python-central 0.5.10 reassign 397006 python2.5-minimal 2.5-3 severity 397006 serious retitle 397006 python2.5-minimal: needs to depend on pyhton-minimal (>= 2.4.4-1) thanks My explanation below: On Wed, 22 Nov 2006, Raphael Hertzog wrote: > On Wed, 15 Nov 2006, Igor Goryachev wrote: > > Setting up python2.5-minimal (2.5-3) ... > > Linking and byte-compiling packages for runtime python2.5... > > pycentral: pycentral rtinstall: installed runtime python2.5 not found > > pycentral rtinstall: installed runtime python2.5 not found > > The problem is not with python-central itself but with the version of > python-minimal that is used in combination. > > The problem can only be reproduced in etch which has python-minimal > 2.4.3-11. The version 2.4.4-1 from sid has an updated > /usr/share/python/debian_defaults which knows python2.5: > $ cat /usr/share/python/debian_defaults > [DEFAULT] > # the default python version > default-version = python2.4 > # all supported python versions > supported-versions = python2.4 > # formerly supported python versions > old-versions = python2.3 > # unsupported versions, including older versions > unsupported-versions = python2.3, python2.5 > > Whereas etch doesn't: > $ cat /usr/share/python/debian_defaults > [DEFAULT] > # the default python version > default-version = python2.4 > # all supported python versions > supported-versions = python2.3, python2.4 > # formerly supported python versions > #old-versions = python2.3 > > So the proper fix is to make sure that a good version of python-minimal is > setup before the install of python2.5. So the bug is in python2.5-minimal > and I'm reassigning it. -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#397006: python2.5: diff for NMU version 2.5-3.1
tags 397006 + patch
thanks
Hi,
Attached is the diff for my python2.5 2.5-3.1 NMU.
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -u python2.5-2.5/debian/control python2.5-2.5/debian/control
--- python2.5-2.5/debian/control
+++ python2.5-2.5/debian/control
@@ -25,7 +25,7 @@
Package: python2.5-minimal
Architecture: any
Priority: optional
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, python-minimal (>= 2.4.4-1)
Replaces: python2.5 (<< 2.5~b3)
XB-Python-Runtime: python2.5
XB-Python-Version: 2.5
diff -u python2.5-2.5/debian/control.in python2.5-2.5/debian/control.in
--- python2.5-2.5/debian/control.in
+++ python2.5-2.5/debian/control.in
@@ -25,7 +25,7 @@
Package: @[EMAIL PROTECTED]
Architecture: any
Priority: @MINPRIO@
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, python-minimal (>= 2.4.4-1)
Replaces: @PVER@ (<< 2.5~b3)
XB-Python-Runtime: @PVER@
XB-Python-Version: @VER@
diff -u python2.5-2.5/debian/changelog python2.5-2.5/debian/changelog
--- python2.5-2.5/debian/changelog
+++ python2.5-2.5/debian/changelog
@@ -1,3 +1,14 @@
+python2.5 (2.5-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * python2.5-minimal depends on python-minimal (>= 2.4.4-1) because it's the
+first version which lists python2.5 as an unsupported runtime (ie a
+runtime that is available but for which modules are not auto-compiled).
+And being listed there is required for python-central to accept the
+installation of python2.5-minimal. Closes: #397006
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Wed, 22 Nov 2006 15:41:06 +0100
+
python2.5 (2.5-3) unstable; urgency=medium
* Update to 20061029 (2.4.4 was released on 20061019), taken from
Bug#395104: python-central: diff for NMU version 0.5.11
tags 395104 + patch
thanks
Hi,
Attached is the diff for my python-central 0.5.11 NMU.
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -Nru /tmp/xky798U0Bu/python-central-0.5.10/debian/changelog
/tmp/2nNeZo9Pe9/python-central-0.5.11/debian/changelog
--- /tmp/xky798U0Bu/python-central-0.5.10/debian/changelog 2006-11-11
02:35:38.0 +0100
+++ /tmp/2nNeZo9Pe9/python-central-0.5.11/debian/changelog 2006-11-22
12:35:39.0 +0100
@@ -1,3 +1,10 @@
+python-central (0.5.11) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Only remove empty dirs in /usr/lib/pythonX.Y. Closes: #395104
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Wed, 22 Nov 2006 12:33:55 +0100
+
python-central (0.5.10) unstable; urgency=low
* Depend on python (>= 2.3.5-7), providing /usr/share/python_defaults.
diff -Nru /tmp/xky798U0Bu/python-central-0.5.10/dh_pycentral.1
/tmp/2nNeZo9Pe9/python-central-0.5.11/dh_pycentral.1
--- /tmp/xky798U0Bu/python-central-0.5.10/dh_pycentral.12006-10-29
11:04:43.0 +0100
+++ /tmp/2nNeZo9Pe9/python-central-0.5.11/dh_pycentral.12006-11-22
17:59:37.0 +0100
@@ -129,7 +129,7 @@
.\"
.\"
.IX Title "DH_PYCENTRAL 1"
-.TH DH_PYCENTRAL 1 "2006-10-18" "" "Debhelper"
+.TH DH_PYCENTRAL 1 "2006-10-29" "" "Debhelper"
.SH "NAME"
dh_pycentral \- use the python\-central framework to handle Python modules and
extensions
.SH "SYNOPSIS"
diff -Nru /tmp/xky798U0Bu/python-central-0.5.10/pycentral.py
/tmp/2nNeZo9Pe9/python-central-0.5.11/pycentral.py
--- /tmp/xky798U0Bu/python-central-0.5.10/pycentral.py 2006-10-29
11:11:41.0 +0100
+++ /tmp/2nNeZo9Pe9/python-central-0.5.11/pycentral.py 2006-11-22
17:59:26.0 +0100
@@ -437,10 +437,11 @@
continue
# TODO: if dst already exists, make sure, src == dst
os.rename(src, dst)
-# remove empty dirs in /usr/lib
+# remove empty dirs in /usr/lib/pythonX.Y
for root, dirs, files in os.walk(self.pkgdir + '/usr/lib',
topdown=False):
try:
-os.rmdir(root)
+ if re.match("/usr/lib/python\d\.\d($|/)",
root.replace(self.pkgdir, "")):
+ os.rmdir(root)
except OSError:
pass
# remove empty dirs in /usr/share/pycentral
Bug#399697: python-numeric: Fails to build 2.3 version
reassign 399697 pygame 1.7.1release-4 retitle 399697 pygame shouldn't build-depend on pythonX.Y-numeric but on python-numeric thanks On Tue, 21 Nov 2006, Daniel Schepler wrote: > Package: python-numeric > Version: 24.2-7 > Severity: serious > > As the subject says, if I build python-numeric under pbuilder, the resulting > package has no contents for python2.3, nor any Provides of python2.3-numeric. > This is the normal behaviour of the package since in sid python2.3 is no more marked as supported in /usr/share/python/debian_defaults ... > Since pygame still Build-Depends on python2.3-numeric, I'm marking this as an > RC bug. So this is an RC bug on pygame: it should build-depend on python-pygame instead of python2.3-pygame, python2.4-pygame. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#399816: pygame: diff for NMU version 1.7.1release-4.1
tags 399697 + patch
tags 399816 + patch
thanks
Hi,
Attached is a patch that fixes the two bugs and that improves various
other things.
If you want me to upload this as NMU, just ask.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -u pygame-1.7.1release/debian/control pygame-1.7.1release/debian/control
--- pygame-1.7.1release/debian/control
+++ pygame-1.7.1release/debian/control
@@ -3,13 +3,13 @@
Priority: optional
Maintainer: Ed Boraas <[EMAIL PROTECTED]>
Uploaders: Joe Wreschnig <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 5.0.37.1), python2.3-dev, python2.4-dev,
libsdl1.2-dev (>= 1.2.2-3.1), libsdl-image1.2-dev (>= 1.2.0-1.1),
libsdl-mixer1.2-dev (>= 1.2.0-1.1), libsdl-ttf2.0-dev (>= 1.2.2-1.1),
libsmpeg-dev (>= 0.4.5+cvs20030824-1.3), sharutils, python2.4-numeric,
python2.3-numeric, python-central (>= 0.4.10), python (>= 2.3.5-7)
+Build-Depends: debhelper (>= 5.0.38), python-all-dev (>= 2.3.5-11),
libsdl1.2-dev (>= 1.2.2-3.1), libsdl-image1.2-dev (>= 1.2.0-1.1),
libsdl-mixer1.2-dev (>= 1.2.0-1.1), libsdl-ttf2.0-dev (>= 1.2.2-1.1),
libsmpeg-dev (>= 0.4.5+cvs20030824-1.3), sharutils, python-numeric (>= 24.2-3),
python-central (>= 0.5.6)
Standards-Version: 3.7.2
-XS-Python-Version: 2.3, 2.4
+XS-Python-Version: >= 2.3
Package: python-pygame
Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}
+Depends: ${python:Depends}, ${shlibs:Depends}, python-numeric (>= 24.2-3)
Provides: ${python:Provides}
Replaces: python2.3-pygame, python2.4-pygame
Conflicts: python2.3-pygame, python2.4-pygame
diff -u pygame-1.7.1release/debian/rules pygame-1.7.1release/debian/rules
--- pygame-1.7.1release/debian/rules
+++ pygame-1.7.1release/debian/rules
@@ -64,11 +64,12 @@
dh_fixperms -a
dh_pycentral -a
- dh_python -a
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
dh_md5sums -a
dh_builddeb -a
+binary-indep:
+
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure
diff -u pygame-1.7.1release/debian/changelog
pygame-1.7.1release/debian/changelog
--- pygame-1.7.1release/debian/changelog
+++ pygame-1.7.1release/debian/changelog
@@ -1,3 +1,22 @@
+pygame (1.7.1release-4.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Build-depend on python-numeric instead of python2.[34]-numeric.
+Closes: #399697
+ * Likewise build-depend on python-all-dev instead of python2.[34]-dev.
+ * Dropped useless build-dependency on python (it's granted with
+python-all-dev).
+ * Add missing dependency on python-numeric. Closes: #399816
+ * Changed XS-Python-Version to ">= 2.3" since pygame apparently supports
+python 2.5 and I couldn't find a rationale for "2.3, 2.4" in the
+changelog.
+ * Fix lintian errors/warnings:
+- Added empty binary-indep target in debian/rules.
+- Removed dh_python call and adjust python-central build-dependency
+ accordingly.
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Wed, 22 Nov 2006 21:42:59 +0100
+
pygame (1.7.1release-4) unstable; urgency=low
* control: Add ${shlibs:Depends} Depends:.
Bug#399933: Should only provide ${python:Provides}
Package: python-forgetsql
Version: 0.5.1-7
Severity: minor
Usertag: python-provides
This module provides python2.3-forgetsql but it should only provides
${python:Provides} to avoid providing versions of the module that it is no
more providing because we dropped them from the set of supported versions
(as is the case with python2.3 in unstable).
Only "severity: minor" because python-support in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399937: Should only provide ${python:Provides}
Package: python-pyrex
Version: 0.9.4.1-2
Severity: minor
Usertag: python-provides
This module provides python2.3-pyrex, python2.4-pyrex but it should only
provides ${python:Provides} to avoid providing versions of the module that it
is no more providing because we dropped them from the set of supported versions
(as is the case with python2.3 in unstable).
Only "severity: minor" because python-central in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399936: Should provide ${python:Provides} instead of pythonX.Y-pymacs
Package: pymacs
Version: 0.22-6
Severity: minor
Usertag: python-provides
This module provides python2.[1234]-pymacs but it should instead provide
${python:Provides} to avoid providing versions of the module that it is no
more providing because we dropped them from the set of supported versions (as
is the case with python2.3 in unstable).
Only "severity: minor" because python-support in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399932: Should only provide ${python:Provides}
Package: python-forgethtml
Version: 0.0.20031008-8
Severity: minor
Usertag: python-provides
This module provides python2.3-forgethtml, python2.4-forgethtml,
but it should only provides ${python:Provides} to avoid
providing versions of the module that it is no more providing because we
dropped them from the set of supported versions (as is the case with
python2.3 in unstable).
Only "severity: minor" because python-support in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399938: Should only provides ${python:Provides}
Package: python-spf
Version: 1.6-4
Severity: minor
Usertag: python-provides
This module provides python2.3-spf, python2.4-spf but it should only
provides ${python:Provides} to avoid providing versions of the module that
it is no more providing because we dropped them from the set of supported
versions (as is the case with python2.3 in unstable).
Only "severity: minor" because python-support in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399931: Should only provide ${python:Provides}
Package: python-beautifulsoup
Version: 3.0.1-2
Severity: minor
Usertag: python-provides
This module provides python2.3-beautifulsoup, python2.4-beautifulsoup,
${python:Provides} but it should only provides ${python:Provides} to avoid
providing versions of the module that it is no more providing because we
dropped them from the set of supported versions (as is the case with
python2.3 in unstable).
Only "severity: minor" because python-support in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399934: Should only provide ${python:Provides}
Package: python-ipy
Version: 1:0.5-1
Severity: minor
Usertag: python-provides
This module provides python2.3-ipy, python2.4-ipy but it should only
provides ${python:Provides} to avoid providing versions of the module that it
is no more providing because we dropped them from the set of supported versions
(as is the case with python2.3 in unstable).
Only "severity: minor" because python-support in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399941: Should only provide ${python:Provides}
Package: python-templayer
Version: 1.4-1
Severity: minor
Usertag: python-provides
This module provides python2.[1234]-templayer but it should only provides
${python:Provides} to avoid providing versions of the module that it is no more
providing because we dropped them from the set of supported versions (as is the
case with python2.3 in unstable).
Only "severity: minor" because python-support in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399940: Should only provides ${python:Provides}
Package: python-omniorb2-omg
Version: 2.6-3.1
Severity: minor
Usertag: python-provides
This module provides python2.3-corba-omg, python2.4-corba-omg and it shouldn't
provide packages with hardcoded python versions since a rebuild of the package
can theoretically drop support of some python versions. That's why
${python:Provides} should be used.
However ${python:Provides} would generate python2.X-omniorb2-omg in this case...
I don't know why you provide those packages but I suggest reconsidering the
choice.
Only "severity: minor" because python-central in fact provides the modules
for all installed versions that are supported and this is an arch: all
module.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#399948: python-numarray doesn't provide version-specific virtual packages
Package: python-numarray
Version: 1.5.2-2
Severity: normal
Tags: patch
... because you used ${Python:Provides} instead of ${python:Provides} in
the debian/control file.
Attached is the diff for my python-numarray 1.5.2-2.1 NMU.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -u python-numarray-1.5.2/debian/changelog
python-numarray-1.5.2/debian/changelog
--- python-numarray-1.5.2/debian/changelog
+++ python-numarray-1.5.2/debian/changelog
@@ -1,3 +1,11 @@
+python-numarray (1.5.2-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Change Provides fields to refer to ${python:Provides} instead of
+erroneous ${Python:Provides}.
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Wed, 22 Nov 2006 23:46:58 +0100
+
python-numarray (1.5.2-2) unstable; urgency=low
* Re-apply lost changes from 1.5.1-3 and 1.5.1-4.
diff -u python-numarray-1.5.2/debian/control
python-numarray-1.5.2/debian/control
--- python-numarray-1.5.2/debian/control
+++ python-numarray-1.5.2/debian/control
@@ -13,7 +13,7 @@
Suggests: python-numarray-doc
Conflicts: python2.3-numarray, python2.4-numarray, python-numarray-ext (<<
1.5.1-3)
Replaces: python2.3-numarray, python2.4-numarray, python-numarray-ext (<<
1.5.1-3)
-Provides: ${Python:Provides}
+Provides: ${python:Provides}
XB-Python-Version: ${python:Versions}
Description: An array processing package modelled after Python-Numeric
Numarray is a set of extensions to the Python programming language
@@ -31,7 +31,7 @@
Depends: ${python:Depends}, python-numarray (= ${Source-Version}),
${shlibs:Depends}
Conflicts: python2.3-numarray-ext, python2.4-numarray-ext
Replaces: python2.3-numarray-ext, python2.4-numarray-ext
-Provides: ${Python:Provides}
+Provides: ${python:Provides}
XB-Python-Version: ${python:Versions}
Description: Extension modules for Python array processing
Interfaces to existing numerical libraries:
Bug#398899: python-iconvcodec: Fails to upgrade
clone 398899 -1 reassign -1 python-central 0.5.10 retitle -1 python-central doesn't support packages providing only support for old/unsupported runtimes thanks On Thu, 16 Nov 2006, Yavor Doganov wrote: > Package: python-iconvcodec > Version: 1.1.2-3+b1 > Severity: serious > > The package fails to upgrade with the following error: > > Setting up python-iconvcodec (1.1.2-3+b1) ... > INFO: using old version '/usr/bin/python2.3' > pycentral: pycentral pkginstall: python-iconvcodec needs unavailable runtime > (2.3) > pycentral pkginstall: python-iconvcodec needs unavailable runtime (2.3) > dpkg: error processing python-iconvcodec (--configure): > subprocess post-installation script returned error exit status 1 This is a bug in python-central (thus the clone). But the real underlying problem is that the package should be removed because this module is no more useful with python2.4 and python2.4 is the default python both in etch and in sid. I suggest removing the package from etch as a start (I see no point in providing support for python2.3 in etch: not all modules will support python 2.3 and python2.3 itself might be removed). If the maintainer agrees, he can also reassign this bug to ftp.debian.org and request its removal. On the python-central side I must say that fixing this bug is not trivial. python-central uses the same function "requested_versions()" for deciding versions to support at build time and versions to support at runtime. Obviously at runtime we want to be more open-minded and support old/unsupported runtimes if that's possible according to the Python-Version field. There's lots of code duplication within python-central and the initial design suffered a lot from incremental bug fixes, which renders writing this patch a painful task. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#399986: python-central: diff for NMU version 0.5.12
tags 399986 + patch
thanks
Hi,
Attached is the diff for my python-central 0.5.12 NMU.
I changed python-central accept installing packages providing only support
of old python versions. I didn't add "unsupported" versions since we now
have 2.5 in sid and we have no experience in handling addition of new
upstream version from that point of view.
But I suggest enabling that post-etch of course.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -Nru /tmp/YU1MgPcx9o/python-central-0.5.11/debian/changelog
/tmp/sdAGhjKHsf/python-central-0.5.12/debian/changelog
--- /tmp/YU1MgPcx9o/python-central-0.5.11/debian/changelog 2006-11-22
12:35:39.0 +0100
+++ /tmp/sdAGhjKHsf/python-central-0.5.12/debian/changelog 2006-11-23
11:13:11.0 +0100
@@ -1,3 +1,11 @@
+python-central (0.5.12) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Accept packages providing support of only old python runtimes.
+Closes: #399986
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Thu, 23 Nov 2006 10:28:23 +0100
+
python-central (0.5.11) unstable; urgency=low
* Non-maintainer upload.
diff -Nru /tmp/YU1MgPcx9o/python-central-0.5.11/pycentral.py
/tmp/sdAGhjKHsf/python-central-0.5.12/pycentral.py
--- /tmp/YU1MgPcx9o/python-central-0.5.11/pycentral.py 2006-11-22
17:59:26.0 +0100
+++ /tmp/sdAGhjKHsf/python-central-0.5.12/pycentral.py 2006-11-23
11:01:54.0 +0100
@@ -867,14 +867,19 @@
bc_option = config.get('DEFAULT', 'byte-compile')
pkg = DebPackage('package', self.args[0], oldstyle=False)
pkg.read_version_info()
+requested =
pyversions.requested_versions_for_runtime(pkg.version_field, version_only=True)
+used_runtimes = [rt for rt in runtimes if rt.short_name in requested]
try:
pkg.set_default_runtime_from_version_info()
except ValueError:
-# package needs an unavailable runtime.
-self.error('%s needs unavailable runtime (%s)'
- % (self.pkgname, pkg.version_field))
-requested = pyversions.requested_versions(pkg.version_field,
version_only=True)
-used_runtimes = [rt for rt in runtimes if rt.short_name in requested]
+ # Package doesn't provide support for any supported runtime
+ if len(used_runtimes) == 0:
+ self.error('%s needs unavailable runtime (%s)'
+ % (self.pkgname, pkg.version_field))
+ else:
+ # Still byte compile for the available runtimes (with the
+ # first matching runtime)
+ pkg.default_runtime = get_runtime_for_version(used_runtimes[0])
logging.debug('\tavail=%s, pkg=%s, install=%s'
% ([rt.short_name for rt in runtimes],
pkg.version_field,
diff -Nru /tmp/YU1MgPcx9o/python-central-0.5.11/pyversions.py
/tmp/sdAGhjKHsf/python-central-0.5.12/pyversions.py
--- /tmp/YU1MgPcx9o/python-central-0.5.11/pyversions.py 2006-10-06
12:55:22.0 +0200
+++ /tmp/sdAGhjKHsf/python-central-0.5.12/pyversions.py 2006-11-23
11:05:42.0 +0100
@@ -152,6 +152,43 @@
else:
return ['python%s' % v for v in versions]
+# This function is used by python-central to decide which installed
+# runtimes must be supported. It's not nice, but it's designed to mimic
+# closely requested_versions in an attempt to avoid introducing bugs this
+# late in the release cycle. Some cleanup is in order post-etch though.
+def requested_versions_for_runtime(vstring, version_only=False):
+versions = None
+vinfo = parse_versions(vstring)
+old = old_versions(version_only=True)
+unsupported = unsupported_versions(version_only=True)
+supported = supported_versions(version_only=True)
+# You might want to add unsupported versions too... later.
+supported.extend(old)
+if len(vinfo) == 1:
+if 'all' in vinfo:
+versions = supported
+elif 'current' in vinfo:
+versions = [default_version(version_only=True)]
+else:
+versions = vinfo['versions'].intersection(supported)
+elif 'all' in vinfo and 'current' in vinfo:
+raise ValueError, "both `current' and `all' in version string"
+elif 'all' in vinfo:
+versions = versions = vinfo['versions'].intersection(supported)
+elif 'current' in vinfo:
+current = default_version(version_only=True)
+if not current in vinfo['versions']:
+raise ValueError, "`current' version not in supported versions"
+versions = [current]
+else:
+raise ValueError, 'error in version string'
+if not version
Bug#398636: sqlrelay: diff for NMU version 1:0.37.1-3.1
uggests: sqlrelay-doc
Provides: sqlrelay-api
Description: SQL Relay Tcl API
@@ -249,7 +250,7 @@
Package: php5-sqlrelay
Architecture: any
-Depends: ${php:Depends}, sqlrelay (= ${Source-Version}), ${shlibs:Depends}
+Depends: ${php:Depends}, sqlrelay (= ${binary:Version}), ${shlibs:Depends}
Suggests: sqlrelay-doc
Provides: sqlrelay-api
Description: SQL Relay PHP API
diff -u sqlrelay-0.37.1/debian/changelog sqlrelay-0.37.1/debian/changelog
--- sqlrelay-0.37.1/debian/changelog
+++ sqlrelay-0.37.1/debian/changelog
@@ -1,3 +1,16 @@
+sqlrelay (1:0.37.1-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Make various dependencies bin-NMU safe. But this implied loosening
+some dependencies (changed "=" into ">=") from "arch: all" packages
+depending on "arch: any" packages.
+ * Fix zope-sqlrelayda to include a Python-Version field. Closes: #398636
+ * Fix php5-sqlrelay to actually have some content (renamed
+debian/php4-sqlrelay.install to debian/php5-sqlrelay.install and update
+its content).
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Thu, 23 Nov 2006 11:30:27 +0100
+
sqlrelay (1:0.37.1-3) unstable; urgency=low
* Remove java-gcj-compat-dev build dependency for arm.
only in patch2:
unchanged:
--- sqlrelay-0.37.1.orig/debian/php5-sqlrelay.install
+++ sqlrelay-0.37.1/debian/php5-sqlrelay.install
@@ -0,0 +1,2 @@
+usr/lib/php5/*
+usr/share/pear/DB/sqlrelay.php usr/share/doc/php5-sqlrelay/
Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
clone 398771 -1 reassign -1 python-support 0.5.5 retitle -1 python-support should warn and not fail when some files can't be byte-compiled thanks On Thu, 16 Nov 2006, Lionel Elie Mamane wrote: > This bug, in my opinion, makes the package unsuitable for release with > etch. It breaks upgrades from sarge to etch, if I understand well. The bug is both in python-support and in mailman. Python-support shouldn't fail when some files can't be byte-compiled but just warn the user that something is not 100% normal. It looks like wrong to make the installation of python2.4 fail when just one module is kind of broken. Thus the clone and reassign. > That file usually is a symlink to /etc/mailman/mm_cfg.py, a > configuration file. I'm not terribly convinced it should be compiled > at all, actually. It is a bug for it to be compiled unless it is > *automatically* read from source when the source is newer than the > compiled version. Any python expert could tell me whether it is the > case? > > Alex, you did have the file /etc/mailman/mm_cfg.py, right? At least the file doesn't exist when python2.4 got installed. If the mailman upgrade make the file disappear then this is the RC bug. But since it's a configuration file, it might also be that the user removed it manually and it doesn't get reinstalled because of dpkg's conffile handling. Unless someone comes up with evidence that the file gets removed during a normal upgrade I don't think that this bug is RC. That said I haven't tried the upgrade myself and someone should do that since the bug reporter hasn't confirmed/denied yet. Alex ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#397895: Breaks software changing the Python path at runtime
On Fri, 10 Nov 2006, Loïc Minier wrote: > By design, python-support might break some applications. Two examples > lately were the GStreamer 0.10 Python bindings and the GNOME Deskbar > Applet. This is usually because these packages are ./configured with a > default Python path, such as /usr/lib/pythonX.Y/site-packages where the > upstream package expects to find it's *.py and *.pyc files after the > installation (IOW, at runtime), but dh_pysupport moves the *.py to > /usr/share/python-support and byte compiles them into *.pyc files below > /var/lib/python-support. But /var/lib/python-support contains both the *.pyc and the *.py (although as symlink to the real file). > 3) Not assuming 1), it's possible for python-support to symlink *.py > files to /var/lib/python-support and we could ./configure with this > python-path as in 2). This is already the case. I believe it has been added when we discovered problems due to *.so and *.py being in different directories. You might want to close this bug. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#400001: python-support: possible patch
tags 41 + patch
thanks
Hi,
Attached is a possible patch to fix this issue. I tested it here by
creating an error in a private module:
$ sudo /var/lib/dpkg/info/linda.postinst configure
WARNING: compile error while trying to byte-compile
/usr/share/linda/checks/shebang.py: File
"/usr/share/linda/checks/shebang.py", line 4
; + beur
^
SyntaxError: invalid syntax
(sid) [EMAIL PROTECTED]:~/local/debian$ echo $?
0
Note however that the problem only existed with private modules since the
public modules are byte-compiled by compile_all which is spawned as a
separate process and whose return value we don't check. However the process
displays similar warnings.
For consistency of output I decided to ask compile() to raise an exception but
in fact it's not really needed. I could have checked only the IOError
exception (or only the generic one).
Feel free to adapt to suit your needs.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -Nru /tmp/9tKXsR3naN/python-support-0.5.5/debian/changelog
/tmp/9DkRb9y0Lf/python-support-0.5.6/debian/changelog
--- /tmp/9tKXsR3naN/python-support-0.5.5/debian/changelog 2006-11-14
21:27:26.0 +0100
+++ /tmp/9DkRb9y0Lf/python-support-0.5.6/debian/changelog 2006-11-23
14:12:08.0 +0100
@@ -1,3 +1,11 @@
+python-support (0.5.6) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Don't raise IOError while trying to byte-compile an *.py file (for example,
+when the file is a symlink to a non-existent file). Closes: #400001
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Thu, 23 Nov 2006 14:10:25 +0100
+
python-support (0.5.5) unstable; urgency=high
* dh_pysupport, pysupport-movemodules, debian/rules,
diff -Nru /tmp/9tKXsR3naN/python-support-0.5.5/update-python-modules
/tmp/9DkRb9y0Lf/python-support-0.5.6/update-python-modules
--- /tmp/9tKXsR3naN/python-support-0.5.5/update-python-modules 2006-09-22
21:12:04.0 +0200
+++ /tmp/9DkRb9y0Lf/python-support-0.5.6/update-python-modules 2006-11-23
14:19:45.0 +0100
@@ -6,7 +6,7 @@
import sys,os,os.path
from optparse import OptionParser
-from py_compile import compile
+from py_compile import compile, PyCompileError
basepath='/var/lib/python-support'
sourcepath='/usr/share/python-support'
@@ -87,7 +87,15 @@
if file.endswith('.py'):
fullpath=os.path.join(basedir,dir,file)
debug("compile "+fullpath+'c')
-compile(fullpath)
+try:
+ # Not that compile doesn't raise PyCompileError by default
+ compile(fullpath, doraise=True)
+except IOError, (errno, strerror):
+ print >>sys.stderr, "WARNING: I/O error while trying to byte-compile %s
(%s): %s" % (fullpath, errno, strerror)
+except PyCompileError, inst:
+ print >>sys.stderr, "WARNING: compile error while trying to byte-compile
%s: %s" % (fullpath, inst.msg)
+except:
+ print >>sys.stderr, "WARNING: unexpected error while trying to
byte-compile %s: %s" % (fullpath, sys.exc_info()[0])
def clean_simple(basedir,dir,file):
if file.endswith('.py'):
Bug#399936: Should provide ${python:Provides} instead of pythonX.Y-pymacs
On Thu, 23 Nov 2006, Alexandre Fayolle wrote:
> > This module provides python2.[1234]-pymacs but it should instead provide
> > ${python:Provides} to avoid providing versions of the module that it is no
> > more providing because we dropped them from the set of supported versions
> > (as
> > is the case with python2.3 in unstable).
>
> Hi,
>
> I'm not sure about this one. The source package currently in unstable
> ships python2.1-pymacs, python2.2-pymacs and python2.3-pymacs, and
> subsequent changes lead to a single binary package called pymacs. The
> Provides is here to ensure a smooth upgrade for sarge -> etch. Am I
> missing something? Should I do this in a different way (e.g. shipping
> empty python2.X-pymacs packages depending on pymacs)?
Given that nobody uses python2.X-pymacs to depend on your package, I think
it's ok to leave it as is.
Post-etch though, you might want to drop some cruft in the Provides: header
as the Provides from the technical side is wrong: your package only
provides the modules for the current python-version and not for all the
versions listed.
Note that ${python:Provides} wouldn't help much in this case AFAIK since
the package is named pymacs and not python-pymacs and only the latter case
is supported by dh_pycentral.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
On Thu, 23 Nov 2006, Lionel Elie Mamane wrote: > > I just checked, it is not a conffile. > > ... and not shipped by the package, but created by the postinst. > > Which means this also breaks _new_ installs as far as I understand it > because if: > > - mailman gets unpacked _before_ > > - python2.4 gets configured _before_ > > - mailman gets configured > > That last bit _will_ tend to happen since dpkg tries to configure > dependencies before the package itself. The first bit may or may not > happen. > > That's also harder to fix from mailman's side, if possible at all. There's the possibility of not including the symlink in the package but creating it at the same time when you create /etc/mailman/mm_cfg.py. This should do the trick although you must double check what's happening during upgrade since the config file might temporary disappear and this might lead to errors in the init script. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#398771: installing mailman with python 2.3 causes loop condition during python upgrade
On Fri, 24 Nov 2006, Lionel Elie Mamane wrote: > Ah, I think I have it. We can remove the symlink in pre-rtupdate and > put it back in post-rtupdate. That takes care of python version > updates. Now, for new installs... Python will guaranteed be configured > before us, so indeed creating the symlink in postinst will be safe. This looks like really overkill for your need. Python-support has been fixed and will only warn about the failed byte-compilation, so mailman's installation shouldn't fail anymore. > > The file is small (just configuration), so having it not compiled is > > perfectly acceptable performance-wise... python-support doesn't allow you to do that. python-central IIRC has an exclusion mechanism but I don't think that you can leverage it with the standard debhelper substitution. > Not only that, but more often than not the compiled version will be > useless/outdated as the admin will have edited the config file. python is smart, it only uses the byte-compiled file it it's newer than the .py file. So it's not a problem. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#401017: Apt hangs for ever, complains about bzip2
Package: apt Version: 0.6.46.2 Severity: serious I'm filing this new bug following some discussion (attached) in debian-devel. I've also seen this behaviour a few time and it's very annoying. This should be fixed for etch... Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ --- Begin Message --- Hello, Is this a bug in apt? pbuilder update --override-config --configfile /tmp/pbuilder-local.SvMNy19452 W: /home/brian/.pbuilderrc does not exist Upgrading for distribution etch Building the build Environment -> extracting base tarball [/var/cache/pbuilder/base-etch.tgz] -> creating local configuration -> copying local configuration -> mounting /proc filesystem -> mounting /dev/pts filesystem -> policy-rc.d already exists -> Installing apt-lines Refreshing the base.tgz -> upgrading packages Get:1 http://ftp.au.debian.org etch Release.gpg [378B] Get:2 http://ftp.au.debian.org etch Release [74.4kB] Get:3 http://ftp.au.debian.org etch/main Packages/DiffIndex [2038B] Get:4 http://ftp.au.debian.org etch/main Packages [5579kB] Get:5 http://ftp.au.debian.org etch/main Packages [5579kB] 99% [5 Packages gzip 0] (hangs for ever) I have tried waiting for it to timeout, but it doesn't. I tried running it in strace, but then it works. Perfectly. Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii apt 0.6.46.2 Advanced front-end for dpkg The chroot in question doesn't yet have the latest Etch key, but I don't think that is significant. Doing a search for bugs, I see #358817, but this doesn't involve NFS so it looks different. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message --- --- Begin Message --- Hi, Brian May wrote: > Hello, > > Is this a bug in apt? > > pbuilder update --override-config --configfile /tmp/pbuilder-local.SvMNy19452 [...] > Get:5 http://ftp.au.debian.org etch/main Packages [5579kB] > 99% [5 Packages gzip 0] > > (hangs for ever) [...] I experienced the same some time ago and worked it around by temporarily switching to a different mirror. It then succeeded, and afterwards I could again switch to my usual mirror. But, yesterday I had the same issue in my i386 chroot, so the issue seems to persist Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message --- --- Begin Message --- On Mon, 27 Nov 2006, Andreas Fester wrote: > I experienced the same some time ago and worked it around > by temporarily switching to a different mirror. It then succeeded, > and afterwards I could again switch to my usual mirror. > > But, yesterday I had the same issue in my i386 chroot, so the issue > seems to persist Use --save-after-login and pbuilder login to open the chroot, add the new apt key, and only then run the update. I don't know where the bug is, but it is directly related to apt key management. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message --- --- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrique de Moraes Holschuh wrote: > On Mon, 27 Nov 2006, Andreas Fester wrote: >> I experienced the same some time ago and worked it around >> by temporarily switching to a different mirror. It then succeeded, >> and afterwards I could again switch to my usual mirror. >> >> But, yesterday I had the same issue in my i386 chroot, so the issue >> seems to persist > > Use --save-after-login and pbuilder login to open the chroot, add the new > apt key, and only then run the update. > > I don't know where the bug is, but it is directly related to apt key > management. I tried to track it down; I could reproduce it with non-stripped apt-binaries from a re-compiled apt source package. pstree showed the following processes while apt-get was hanging: apt-get(5027)???bzip2(5049) ??gpgv(5032) ??gzip(5038) ??http(5029) ??http(5030) ap
Bug#399986: reopen, still fails
On Thu, 30 Nov 2006, Rene Engelhard wrote: > reopen 399986 > thanks > > Still fails with 0.5.12. Sorry, you need to provide more info. How exactly have you encountered a failure ? When installing which package on which distribution with which version of python-minimal ? Testing still has a bad version of python-minimal which means that even with the fixed python-central, the problem won't be solved. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#398899: reopen, still fails
severity 398899 serious retitle 398899 python-iconvcodec: won't install without python2.3, either remove or depend explicitely on python2.3 thanks On Thu, 30 Nov 2006, Rene Engelhard wrote: > $ sudo dpkg --configure -a > [...] > Setting up python-iconvcodec (1.1.2-3+b1) ... > pycentral: pycentral pkginstall: python-iconvcodec needs unavailable runtime > (2.3) > pycentral pkginstall: python-iconvcodec needs unavailable runtime (2.3) > dpkg: error processing python-iconvcodec (--configure): > subprocess post-installation script returned error exit status 1 > Errors were encountered while processing: > netatalk > python-iconvcodec Do you have python2.3 installed ? I expect you don't have it installed. In that case, python-central complains rightly. IMO the bug is no more in python-central but in python-iconvcodec ... which should be removed or fixed to state that it provides something useful only for python2.3 (and thus depend on it instead of depending on python (>= 2.3)). Note that while I understand this rationale, I'm not sure that this python-central behaviour is the smartest possible. The bug concerning python-iconvcodec is #398899. I'm bumping the severity of the bug to serious to get it out of testing in the current state at least. > > When installing which package on which distribution with which version of > > python-minimal ? > > python-iconvcodec, obviously. Well given that the bug is reported against python-central, it's not so obvious. :) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#399697: pygame: diff for NMU version 1.7.1release-4.1
Hello, On Wed, 22 Nov 2006, Raphael Hertzog wrote: > Attached is a patch that fixes the two bugs and that improves various > other things. > > If you want me to upload this as NMU, just ask. It's been a week without news. I uploaded the NMU. Ed & Joe, I'd suggest to move the maintenance of this package in the python-modules team so that other people can easily fill the gaps when you don't have time. http://python-modules.alioth.debian.org/ I'll gladly add you to the team, just ask me. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#399697: python-numeric: Fails to build 2.3 version
Hi, On Thu, 30 Nov 2006, Daniel Schepler wrote: > > This is the normal behaviour of the package since in sid python2.3 is no > > more marked as supported in /usr/share/python/debian_defaults ... > > It seems to me that it's a bad idea to make this change in sid while the old > python packages are frozen in etch. The result will be: if anybody uploads > updated versions of their python packages, they will get autobuilt against > the sid packages and thus have no 2.3 contact, which is out of sync with what > would happen with people wanting to hand-build their packages locally using > etch. And how is this a problem ? It's not technical problem... it's at most a problem of consistency in the packages built, some will provide support for 2.3 and 2.4 while other will only support 2.4. I'm not the one who decided it, it's Matthias who manages solely the python packages (despite my numerous attemps to push collaborative maintenance on those packages). Given that the new python-defaults has been there for a full month already, it's a bit late to revert this change (although it should be easy since all affected packages should be bin-NMUable). > I think you should decide whether you want python2.3 to be supported in etch > or not. If you do, you should revert the changes in sid until after the etch > release; if you don't, you need to ask the release team to let the new python > packages into etch despite the freeze of "base toolchain" packages, and also > prepare a list of appropriate binNMU's needed to sync up the packages in sid > with this change. Matthias's goal has always been to get rid of python2.3 completely. It's likely doable. And I discussed on #debian-release their move to etch, it will likely happen soon (after my recent NMUs which fixed some issues related to that change). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#401040: python-setuptools: patch
tags 401040 + patch
thanks
Hi,
Attached is the diff that fixes this bug and does some more cleanup.
If you want me to upload this a NMU, just ask. Otherwise I might upload it
in a few days if I don't hear back from you.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff -u python-setuptools-0.6c3/debian/changelog
python-setuptools-0.6c3/debian/changelog
--- python-setuptools-0.6c3/debian/changelog
+++ python-setuptools-0.6c3/debian/changelog
@@ -1,3 +1,14 @@
+python-setuptools (0.6c3-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fortified the sed invocation (do not hardcode a python version) which fixes
+the python shebang line of easy_install-* scripts. Closes: #401040
+ * Clean up some build dependencies.
+ * Use again ${python:Depends} but ignore the easy_install-* scripts when
+generating the depends line (to avoid unwanted dependencies on pythonX.Y).
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Thu, 30 Nov 2006 16:35:43 +0100
+
python-setuptools (0.6c3-1) unstable; urgency=medium
* New upstream version (release candidate 3). Closes: #389780.
diff -u python-setuptools-0.6c3/debian/control
python-setuptools-0.6c3/debian/control
--- python-setuptools-0.6c3/debian/control
+++ python-setuptools-0.6c3/debian/control
@@ -2,13 +2,14 @@
Section: python
Priority: optional
Maintainer: Matthias Klose <[EMAIL PROTECTED]>
-Build-Depends-Indep: debhelper (>= 5.0.37.1), python-all, python-central (>=
0.4.10)
+Build-Depends: debhelper (>= 5.0.37.1)
+Build-Depends-Indep: python-all-dev, python-central (>= 0.5)
XS-Python-Version: all
Standards-Version: 3.7.2
Package: python-setuptools
Architecture: all
-Depends: python, python-central (>= 0.4.11)
+Depends: ${python:Depends}
Conflicts: python2.3-setuptools (<< 0.6b2), python2.4-setuptools (<< 0.6b2)
Replaces: python2.3-setuptools, python2.4-setuptools
Provides: ${python:Provides}
diff -u python-setuptools-0.6c3/debian/rules
python-setuptools-0.6c3/debian/rules
--- python-setuptools-0.6c3/debian/rules
+++ python-setuptools-0.6c3/debian/rules
@@ -83,10 +83,9 @@
echo "fixed interpreter: $$i"; \
fi; \
done
- sed -i -e 's/python2.4/python2.3/g' \
- debian/python-setuptools/usr/bin/easy_install-2.3
- dh_pycentral -i
- dh_python -i
+ sed -i -e "1s/python[0-9].[0-9]/python/g"
debian/python-setuptools/usr/bin/easy_install
+ for easy in debian/python-setuptools/usr/bin/easy_install-*; do
v=$${easy##debian/python-setuptools/usr/bin/easy_install-}; sed -i -e
"s/python[0-9].[0-9]/python$$v/g" $$easy; done;
+ dh_pycentral -i -Xusr/bin/easy_install-
echo 'python:Provides=$(foreach v,$(shell pyversions -r
debian/control),$(v)-setuptools)' \
| sed 's/ /, /g' >> $(d).substvars
dh_installdeb -i
Bug#396354: Removing locales after installation of locales-all result in no locales
Package: locales Version: 2.3.6.ds1-4 Severity: normal On alioth we provide all locales to our users and since I knew of locales-all in etch, I installed it and immediately after I removed the "locales" package since locales-all is providing it anyway. This resulted in no installed locales... in fact both locales-all and locales remove /usr/lib/locale/locale-archive on removal (see prerm). I suggest either that both packages conflict or that the prerm snippet be changed so that it effectively removes this file only when needed, ie when the last of the two packages is removed. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages locales depends on: ii debconf [debconf-2.0]1.5.6 Debian configuration management sy ii libc6 [glibc-2.3.6.ds1-1]2.3.6.ds1-4 GNU C Library: Shared libraries locales recommends no packages. -- debconf information: * locales/default_environment_locale: fr_FR.UTF-8 * locales/locales_to_be_generated: fr_FR.UTF-8 UTF-8, [EMAIL PROTECTED] ISO-8859-15, fr_FR ISO-8859-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396543: Recommends unavailable wims-extra
Hi Georges, On Wed, 01 Nov 2006, Georges Khaznadar wrote: > Luk Claes a écrit : > > Your package recommends wims-extra which is unavailable in unstable. > > Please Raphael, may you sponsor the package ? it is described at > http://debian.ofset.org/dists/etch/main/source/wims-extra_3.58-1.dsc Checked and uploaded. It has the same problems of organization than wims itself but otherwise the packaging looks sane. A detail: both wims-modules and wims-extra need the "wims" user to exist and this user is created in wims preinst. This means that you need to depend on wims itself... otherwise you can install wims-modules/wims-extra alone and they will fail to install. But doing so would create a dependency loop. Alternatively you can also simply check for the existence of the wims user before doing the chown... because installing wims will chown the whole directory including the files provided by wim-modules/wims-extra. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#398518: uscan: doesn't handle redirections when downloading a tarball
Package: devscripts Version: 2.9.25 Severity: normal Following the advice here: http://roland.entierement.nu/blog/2005/04/28/debianwatch-vs-sfnet.html I added this is debian/watch: version=3 http://qa.debian.org/watch/sf.php?project=gnomeicu gnomeicu-([\d.]*).tar.gz uscan --report works very well and detects the new upstream upstream version. But when I try to download the archive it fails because it tries to download the file from qa.debian.org/watch/ instead of the site where this URL redirects to. $ uscan gnomeicu: Newer version (0.99.12) available on remote site: http://qa.debian.org/watch/gnomeicu-0.99.12.tar.gz (local version is 0.99.10) uscan warning: In directory ., downloading http://qa.debian.org/watch/gnomeicu-0.99.12.tar.gz failed: 404 Not Found It would be nice to try to download from the redirected URL if it appears that the reference URL is a redirect. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages devscripts depends on: ii debianutils 2.17.3 Miscellaneous utilities specific t ii dpkg-dev 1.13.24 package building tools for Debian ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii perl 5.8.8-6.1 Larry Wall's Practical Extraction ii sed 4.1.5-1 The GNU sed stream editor Versions of packages devscripts recommends: ii fakeroot 1.5.10 Gives a fake root environment -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398735: ktouch: Many keyboard layouts missing
Package: ktouch Version: Many keyboard layouts missing Severity: important The latest upstream release, rather than fixing the allegedly broken keyboard layouts, simply removed them from the build process (see keyboard_DATA in ./kdeedu-3.5.5/ktouch/keyboards/Makefile.in and corresponding ChangeLog entry). As a result, ktouch is not usable on severak keyboard layout including french, which is not broken in Debian's kdeedu since you applied a specific patch (see #347850). I suggest sending this patch upstream so that it can be reenabled. Furthermore with etch to be released soon, I'd rather have a keyboard layout with some wrong colors rather than nothing. Of course, if they can be fixed in time it's even better. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290751: qa.debian.org: please list security updates in Latest News
Le dimanche 16 janvier 2005 à 14:24 +0100, Marc Haber a écrit : > Package: qa.debian.org > Severity: wishlist > > Hi, > > http://packages.qa.debian.org/e/exim.html does not seem to list the > security upload of 3.35-1woody4 in the Latest News section. I'd like > to see that information there as well. It will be difficult... the Latest News section receives mail from katie. But if the security uploads don't go through katie, then I will never see them. I'm tempted to tag this bug wontfix. Regards, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#290959: list2cds doesn't work with non-english locale
Le lundi 17 janvier 2005 à 23:49 +0100, Isaac Clerencia a écrit : > Package: debian-cd > Version: 2.2.20 > Severity: minor > > "make bin-list" fails when a non-english locale is set because the parser for > apt-cache depends output in list2cds just looks for the English words, i.e. > Depends, Recommends, ... FYI, this is already fixed in the CVS version of debian-cd. Tagging this bug as pending. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Bug#409026: wims: FTBFS: cp: cannot stat `/wims-3.60/wims/public_html/wims': No such file or directory
On Wed, 07 Feb 2007, Georges Khaznadar wrote: > > Otherwise, consider removing that check for the next upload. > > OK, I do that. Should we upload it shortly, or do we wait for a new > upstream release? We can safely wait. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#410402: isAnyWirelessPoweredOn in static-functions broken
Hi, On Sat, 10 Feb 2007, Nico Golde wrote: > P.S. are you going to maintain this package? Thought Raphael > is doing it :) As I told you, I have no big interest in this package but I've packaged it because we needed it to have good support of most laptops. Loïc offered his help so I'm quite happy when he's handling issues with it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#410918: acpi-support should not depend on toshset / radeontool
tag 410918 + wontfix thanks Hello, On Wed, 14 Feb 2007, Francois Gouget wrote: > I have a Sony laptop so the toshset package does absolutely nothing for > me and I should not have to install it.i > > So acpi-support should Recommend toshset rather than Depend on it. > > This way a default installation would install the package, but users who > have limited diskspace (e.g. my 6GB) would be able to remove irrelevant > dependencies without leaving the acpi-support package in a broken state. > > The same approach should be applied to readeontool too (I have a Neomagic > card), and possibly vbetool too. > > I checked the 0.90-4 release and it has the same set of dependencies. We're talking of 310kb here. No, I'm not going to remove the dependencies for this, in particular when acpi-support already takes more than twice this size. We have scripts that use those tools, so it's logical to depend on them. There's the case where you take your harddrive out and put it in a new laptop. There's also a potential problem with CD building, without the depends we might provide acpi-support without those important packages on some incomplete CD set. Thus tagging wontfix. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#409703: CVE-2007-0667: sql-ledger: Arbitrary Code Execution
On Wed, 28 Feb 2007, Moritz Muehlenhoff wrote: > We talked about this before in private mail. Please either > > a) Document clearly in README.Debian that sql-ledger is not suitable > for public installations w/o completely trusted users (which could even > in ordner for an accounting solution) and readjust to non-RC severity > afterwards I've done that but I closed the bug, so that its progression in etch can be properly tracked. We ought to reopen it once it's in etch. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
