Bug#495868: debbugs: Missing bug number on cloned web control references
Hi, On Thu, 2008-08-21 at 11:37:02 -0700, Don Armstrong wrote: On Thu, 21 Aug 2008, Guillem Jover wrote: On the web interface, when there's been a clone on a bug, the control message shown is missing the bug number target of that clone. As an example, near this message: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=143307#143 There was a bug with this that I thought I fixed. Can you check to see if it's happened with a more recent revision? That clone is from 'Thu, 14 Aug 2008 14:04:45 GMT', if that's not recent enough, I've fished http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481134#27, which is from 'Wed, 20 Aug 2008 14:09:06 GMT'. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496005: donkey-bolonkey: Creates file in current working directory
Package: donkey-bolonkey Version: 2001-5.1 Severity: important Tags: security Hi, This game creates the file dkbk.hi on the current working dir every time the game level has finished. It should probably create it under a dot dir on the home dir (preferably following the XDG base dir spec). Setting as important as this might be a security problem, allowing for a symlink attack on certain conditions. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496237: opencity: split arch indepenendet files into a -data package
Source: opencity Source-Version: 0.0.5.1stable-1 Severity: normal Hi, This packages takes 10.5 MiB on i386, for which 9.8 MiB are arch independent data files. As in: $ du -sh /usr/share/games/opencity/ Those seems to contain textures, 3d models and similar. It'd be really nice for the mirrors if it could be split into an opencity-data package. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499070: dpkg leaves system in unusable state after running out of diskspace
forcemerge 499070 497041 thanks On Tue, 2008-09-16 at 01:06:05 +0200, Alexander Prinsier wrote: Package: dpkg Version: 1.14.22 Severity: serious I was installing php5 while my system ran out of disk space. dpkg breaks, and leaves the system in a state where I can no longer use dpkg. To find out the version number of dpkg I used /var/log/dpkg.log, as I couldn't use dpkg to find it's own version number... Hope it's the correct one. This is what happened: [...] Selecting previously deselected package libjpeg62. Unpacking libjpeg62 (from .../libjpeg62_6b-14_i386.deb) ... dpkg: error processing /var/cache/apt/archives/libjpeg62_6b-14_i386.deb (--unpack): failed in buffer_write(fd) (10, ret=-1): backend dpkg-deb during `./usr/share/doc/libjpeg62/copyright': Disk quota exceeded Selecting previously deselected package libdjvulibre21. Unpacking libdjvulibre21 (from .../libdjvulibre21_3.5.20-8_i386.deb) ... dpkg: error processing /var/cache/apt/archives/libdjvulibre21_3.5.20-8_i386.deb (--unpack): failed in buffer_write(fd) (10, ret=-1): backend dpkg-deb during `./usr/lib/libdjvulibre.so.21.0.0': Disk quota exceeded dpkg-deb: subprocess paste killed by signal (Broken pipe) Selecting previously deselected package libxpm4. Unpacking libxpm4 (from .../libxpm4_1%3a3.5.7-1_i386.deb) ... Selecting previously deselected package libgd2-xpm. Unpacking libgd2-xpm (from .../libgd2-xpm_2.0.36~rc1~dfsg-3_i386.deb) ... dpkg: error processing /var/cache/apt/archives/libgd2-xpm_2.0.36~rc1~dfsg-3_i386.deb (--unpack): unable to flush /var/lib/dpkg/updates/tmp.i after padding: Disk quota exceeded Here's where the problem starts. That «tmp.i» file is the one that has been filled with '#padding' lines, the fflush() in createimptmp() fails, and it ohshite()s, but just before it has been able to rewind the file to the beginning. Processing triggers for man-db ... /usr/bin/mandb: can't write to /var/cache/man/19933: Disk quota exceeded gdbm fatal: read error dpkg: failed to write status record about `libcairo2' to `/var/lib/dpkg/status': Disk quota exceeded E: Sub-process /usr/bin/dpkg returned an error code (2) A package failed to install. Trying to recover: dpkg: parse error, in file `/var/lib/dpkg/updates/0119' near line 1: newline in field name `#padding' Press return to continue. The second problem is that even if the ohshite() called from createimptmp() is protected inside an onerr_abort section, the execution continues in archivefiles(), out of process_archive() but into process_queue(), which at some point calls a modstatdb_note(), moving the «tmp.i» file into the «0119» one, then another ohshite() is called and the onerr_abort is sensed again, making process_queue() terminate its loop. # dpkg --configure -a dpkg: parse error, in file `/var/lib/dpkg/updates/0119' near line 1: newline in field name `#padding' # But at the point that modstat_note() was called the function wrote at the end of it, preserving all the '#padding' lines, and making dpkg barf subsequently. So I think there's two things to fix here, one is that the fseek() in createimptmp() should be done just before the fwrite() in modstatdb_note_core() to guarantee that we are going to be always at the beginning, and we make proper use of the reserved space allocated previously with those '#padding' lines to avoid the out of space condition. That's a 4-liner patch, which should be fine for lenny, and prevents this bogus condition were the user most probably is going to remove that file to be able to continue, which might produce an inconsistent state in the dpkg db. And the real problem is that there might not be an easy manual fix by the users if the status data could not be completely written to the update file. The other is that when onerr_abort is signaled dpkg should not continue processing anything anymore, it should just do whatever cleanup is required and exit. But that can wait probably post-lenny. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499070: dpkg leaves system in unusable state after running out of diskspace
Hey, On Tue, 2008-09-16 at 23:14:04 +0300, Guillem Jover wrote: So I think there's two things to fix here, one is that the fseek() in createimptmp() should be done just before the fwrite() in modstatdb_note_core() to guarantee that we are going to be always at the beginning, and we make proper use of the reserved space allocated previously with those '#padding' lines to avoid the out of space condition. That's a 4-liner patch, which should be fine for lenny, and prevents this bogus condition were the user most probably is going to remove that file to be able to continue, which might produce an inconsistent state in the dpkg db. And the real problem is that there might not be an easy manual fix by the users if the status data could not be completely written to the update file. I take this back, the fseek() needs to be there to guarantee that the data has been written. So moving it would only help partially, as we would always be writting at the beginning but the fwrite() might not have enough space from the reserved padding, and the data might get truncated. The other is that when onerr_abort is signaled dpkg should not continue processing anything anymore, it should just do whatever cleanup is required and exit. But that can wait probably post-lenny. So this is the proper fix, and it should not be that big, probably less than 10 lines? Will cook something today or tomorrow... regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497893: marked as done (dpkg: [INTL:vi] Vietnamese program translation update)
notfixed apt/0.7.15~exp1 thanks Hi Michael, On Tue, 2008-09-16 at 22:10:16 +, Debian Bug Tracking System wrote: [...] Package: dpkg Tags: l10n patch Severity: wishlist The updated Vietnamese translation for the program file: dpkg translated and submitted by: Clytie Siddall Vietnamese Free-Software Translation Team http://vnoss.net/dokuwiki/doku.php?id=projects:l10n Date: Tue, 16 Sep 2008 21:32:06 + From: Michael Vogt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug#497893: fixed in apt 0.7.15~exp1 X-Spam-Status: No, score=-14.7 required=4.0 tests=BAYES_00,FROMDEVELOPER, FVGT_m_MULTI_ODD,HAS_BUG_NUMBER,HEADER_X_KATIE,IMPRONONCABLE_2, MURPHY_DRUGS_REL8,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2,PGPSIGNATURE autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Source: apt Source-Version: 0.7.15~exp1 We believe that the bug you reported is fixed in the latest version of apt, which is due to be installed in the Debian FTP archive: [...] Changes: apt (0.7.15~exp1) experimental; urgency=low [...] [ Program translations ] * Vietnamese updated. Closes: #497893 Seems you closed the wrong bug, no big deal though as this was already closed, but you might want to correct the changelog and close the relevant bug in apt. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490758: giggle: automatically modifies .gitconfig
Hi, Please remember to mail the bug submitter either directly or via the [EMAIL PROTECTED] alias, otherwise the BTS will not do that for you. I just happend to check this bug report on the web interface and saw that you replied. On Thu, 2008-08-07 at 15:20:01 +0200, Lash wrote: giggle keeps its configuration in the .gitconfig file and if it doesn't find its section, this will be added there. So if you commit the initial change and doesn't modify giggle option later, you won't have any more problem with it. That's kind of true for the compat-mode setting, which is a real configuration variable, and you have to change it explicitly, but not for the main-window-* ones, which are just state variables, and change every time the window state is changed, which is the really annoying part. Otherwise, What could be in you opinion a comfortable solution? For compat-mode, the program should have an internal default setting, and only write the configuration value when it's changes from that default by the user through the program UI. For the main-window-* state values, they should go probably somewhere else, into a state file. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499941: debbugs: received a help message from request@ on error in control@
Package: debbugs Severity: minor Hi, Sent a message to a bug report with control@ BCCed, the only command included had a syntax error on the argument, and received two help messages, one from contorl@ which makes sense, and another one from request@ which does not seem to. Attached the sent mails and received ones with complete headers. regards, guillem From [EMAIL PROTECTED] Thu Sep 18 20:07:37 2008 Date: Thu, 18 Sep 2008 20:07:37 +0300 From: Guillem Jover [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Michael Vogt [EMAIL PROTECTED] Bcc: [EMAIL PROTECTED] Subject: Re: Bug#497893: marked as done (dpkg: [INTL:vi] Vietnamese program translation update) Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.18 (2008-05-17) Status: RO Content-Length: 1340 notfixed apt/0.7.15~exp1 thanks Hi Michael, On Tue, 2008-09-16 at 22:10:16 +, Debian Bug Tracking System wrote: [...] Package: dpkg Tags: l10n patch Severity: wishlist The updated Vietnamese translation for the program file: dpkg translated and submitted by: Clytie Siddall Vietnamese Free-Software Translation Team http://vnoss.net/dokuwiki/doku.php?id=projects:l10n Date: Tue, 16 Sep 2008 21:32:06 + From: Michael Vogt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug#497893: fixed in apt 0.7.15~exp1 X-Spam-Status: No, score=-14.7 required=4.0 tests=BAYES_00,FROMDEVELOPER, FVGT_m_MULTI_ODD,HAS_BUG_NUMBER,HEADER_X_KATIE,IMPRONONCABLE_2, MURPHY_DRUGS_REL8,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2,PGPSIGNATURE autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Source: apt Source-Version: 0.7.15~exp1 We believe that the bug you reported is fixed in the latest version of apt, which is due to be installed in the Debian FTP archive: [...] Changes: apt (0.7.15~exp1) experimental; urgency=low [...] [ Program translations ] * Vietnamese updated. Closes: #497893 Seems you closed the wrong bug, no big deal though as this was already closed, but you might want to correct the changelog and close the relevant bug in apt. regards, guillem From [EMAIL PROTECTED] Thu Sep 18 20:14:48 2008 Return-path: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on pulsar.hadrons.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.3 Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 18 Sep 2008 19:14:48 +0200 Received: from master.debian.org ([70.103.162.29]) by pulsar.hadrons.org with esmtp (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1KgN5b-00040P-VD for [EMAIL PROTECTED]; Thu, 18 Sep 2008 19:14:48 +0200 Received: from guillem by master.debian.org with local (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1KgN7Y-ym-Iw for [EMAIL PROTECTED]; Thu, 18 Sep 2008 17:16:48 + Received: from rietz.debian.org ([140.211.166.43]) by master.debian.org with esmtp (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1KgN7Y-ye-5N for [EMAIL PROTECTED]; Thu, 18 Sep 2008 17:16:48 + Received: from debbugs by rietz.debian.org with local (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1KgN37-0006dG-UT for [EMAIL PROTECTED]; Thu, 18 Sep 2008 17:12:14 + X-Loop: [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Debian Bug Tracking System) To: Guillem Jover [EMAIL PROTECTED] Subject: Debian Bug help: instructions for [EMAIL PROTECTED] References: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Precedence: bulk X-Debian-PR-Message: doc-text bug-log-mailserver.txt Date: Thu, 18 Sep 2008 17:12:13 + Delivered-To: [EMAIL PROTECTED] Sender: Guillem Jover [EMAIL PROTECTED] Status: RO Content-Length: 5554 Lines: 142 Introduction to the bug system request server There is a mailserver which can send the bug reports and indices as plain text on request. To use it you send a mail message to [EMAIL PROTECTED] The Subject of the message is ignored, except for generating the Subject of the reply. The body you send should be a series of commands, one per line. You'll receive a reply which looks like a transcript of your message being interpreted, with a response to each command. No notifications are sent to anyone for the commands listed here and the mail isn't logged anywhere publicly available. Any text on a line starting with a hash sign # is ignored; the server will stop processing when it finds a line with a control terminator ( quit, thank you, or two hyphens are common examples). It will also stop if it encounters too many unrecognised or badly-formatted commands. If no commands are successfully handled it will send the help text for the server. Commands
Bug#490905: setting package to dselect dpkg-dev dpkg, tagging 490076, tagging 490905
# Automatically generated email from bts, devscripts version 2.10.34 # via tagpending # # dpkg (1.14.21) UNRELEASED; urgency=low # # * Russian (Yuri Kozlov) . Closes: #490076 # * Basque (Piarres Beobide). Closes: #490905 # package dselect dpkg-dev dpkg tags 490076 + pending tags 490905 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492099: xserver-xorg-video-glide: glide2 only available on i386.
Hi, On Wed, 2008-07-23 at 22:38:41 +0200, Brice Goglin wrote: Kurt Roeckx wrote: Package: xserver-xorg-video-glide Version: 1.0.1-1 You're build depending on libglide2-dev which is only availableon i386, and have marked the packages as arch any. Can't you use libglide3-dev instead which is available on i386 alpha ia64 amd64? The Glide hardware can work in a non-x86 host, right? That's right. The problem though, is that the libglide3 package in Debian does not support Voodoo 2 boards, which libglide2 does. We have support for Voodoo 2 now in glide3x upstream, but I've not yet packaged that for Debian, and I don't think I'm going to do this close to the freeze. But for lenny+1 though, I'd like to get rid of libglide2 by switching the few remaining packages to ligblide3. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332782: Your contribution to the Debian release notes
Hi, “I allow that my contribution to the Debian GNU/Linux release notes can be distributed under the terms of the GNU General Public License, version 2.” That or “version 2 or later” would be fine as well. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495866: hwinfo: library packages are needlessly not co-installable
Hi, I didn't receive this mail originally as you didn't send a copy to me. Because the bts does not send mails to the seubmitter, please remember to keep the submitter address in the To or Cc when replying. You can also use the [EMAIL PROTECTED] alias instead, thanks! On Tue, 2008-08-26 at 20:48:47 -0500, William Vera wrote: 2008/8/20 Guillem Jover [EMAIL PROTECTED]: Source: hwinfo Source-Version: 15.3-1 Severity: important The shared libraries contained in this package are not co-installable for no good reason. For example from libhd14 and libhd15 I see no file overlap: [file lists...] I also see this has been going on starting at libhd12. I've not checked libhd13 nor libhd12, but my guess would be that those didn't have overlapping files. So please remove those wrong Conflicts, Provides and Replaces from the library. For any reason you think must be co-installable? As I know, that libraries are used only for hwinfo. Please let me know if I'm wrong. Yes, first there's nothing technically preventing them to be co-installable, and second even if in Debian right now there's nothing using the library except for hwinfo it makes it difficult in general for future packages or current private developers, which would not be able to keep a working copy of a privately built app against the old library and try to port it to the new library at the same time. For the -doc package, please rename the doc-base file (matching the library name be good) so that they can be co-installed. And for the -dev packages the best option would be to rename the package to libhd-dev. Yes I agree, I'm working in the new revision Good! regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465028: libqt3-mt: Missing weak symbols for stat64 functions
Package: libqt3-mt Version: 3:3.3.8b-1 Severity: serious Hi, The Qt shared libraries were providing weak symbols for stat64, lstat64 and fstat64 until version 3:3.3.7-9, but not anymore, other Qt/KDE apps depend on those symbols, so they get terminated when the symbols cannot be resolved during runtime (as the linking is done lazyly). Affected applications I've seen terminate during runtime or just when starting: gwenview and k3b. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465178: khelpcenter: Please demote htdig to Recommends
Package: khelpcenter Version: 4:4.0.0.really.3.5.8.dfsg.1-7 Severity: wishlist Hi, On version 4:4.0.0-2, the htdig relationship was a Recommends, could the same be done on the current version, now that those are installed by default? thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465280: pbuilder fails to install libdirectfb-1.0-0: Depends: libts0 (= 1.0-1) which is a virtual package.
forcemerge 464222 465280 thanks On Mon, 2008-02-11 at 17:23:55 +0100, Alexander Schmehl wrote: Package: libdirectfb-1.0-0 Version: 1.0.1-6 Severity: important During building a package using pbuilder (with an uptodate build.tar.gz), I noticed, that your package could not be installed (and therefore my package failed to build). The relevent part of the pbuilder log is: = The following packages have unmet dependencies: libdirectfb-1.0-0: Depends: libts0 (= 1.0-1) which is a virtual package. = Don't know, if it's the fault of libdirectfb-1.0-0 or tslib, but I would like to see this bug fixed soon; since most of my packages build depend on libsdl1.2-dev and fail to build for that reason :) Yes, tslib. Should be uploading today or so... regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465195: nexuiz: Hardcoded dependencies on shared libraries
Package: nexuiz Version: 2.3-4 Severity: important Hi, The nexuiz and nexuiz-server packages, have hardcoded dependencies on libvorbisfile3 and libcurl3. The code is dlopening the shared libraries by full soname, in snd_ogg.c (OGG_OpenLibrary) and libcurl.c (CURL_OpenLibrary). This is quite wrong, and defeats the purpose of different sonames to denote ABI changes, it also makes it rather difficult in case there's a transition involving those libs, as binNMUs are not helpful there. The proper solution would be either link directly with those libraries, instead of dlopening them. Or if the dependencies are not desired in the main programs, to create nexuiz modules for curl and ogg that would link against those libraries, and those modules would be dlopened by the main programs. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465192: lintian: Please warn on documentation referring to /usr/doc
Package: lintian Version: 1.23.45 Severity: wishlist Hi, Even if we've completed the /usr/doc to /usr/share/doc transition some time ago, there's still documentation in Debian referring to /usr/doc. Those should probably be fixed. On my system, this crude check: $ find /usr/share/doc -type f| grep -v [Cc]hangelog | xargs zgrep /usr/doc gives some hundred hits. There's few false positives though, like the policy upgrade-checklist.txt, I guess those could be excluded. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461653: echo foobar 2 is not a bashism!
reopen 461653 thanks On Sun, 2008-02-03 at 22:13:38 +0100, Sven Joachim wrote: after the fix for bug #461653 I get tons of errors in my scripts for redirecting messages to stderr: , | possible bashism in baz line 13 (should be word 21): | echo foobar 2 ` According to http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html, sections 2.7.5 and 2.7.6, the constructions word and word are perfectly valid /bin/sh syntax. Please don't complain about them. Hmm, actually no, I was wrong in [0], and had forgotten how I tripped into this. My original bug report was correct, maybe not clear enough, though. In the original mail I referred to redirecting to the same file, and not file descriptor. Anyway the problem comes with something like: echo foo /dev/null echo foo /dev/null Those will fail in dash (for example), and as can bee seen from SUSv3 the only supported tokens after [n] are digits or '-'. Anything else gets an unspecified behaviour. I guess the biggest problem is that word can be anything which at the end expands to those valid tokens. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465188: libgammu3-dbg: Should be in section libdevel
Package: libgammu3-dbg Version: 1.18.0-1 Severity: minor Hi, I think it would be more correct to change the section for this package from libs to libdevel. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465181: xf86-input-tslib: Please rename to xserver-xorg-input-tslib
Package: xf86-input-tslib Version: 0.0.4-3 Severity: wishlist [ XSF CCed ] Hi, Could you please rename the packages (source and binary I guess, to avoid confusion; that will also imply requesting the removal of the old packages from the archive) to xserver-xorg-input-tslib or similar, to follow the current XSF naming scheme? This would be clearer for the users. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465402: O: directfb -- direct frame buffer graphics
Package: wnpp Severity: normal Now that the library transition is over, and all major bugs should be fixed, I've been able to finally orphan the directfb suite of packages. It might make sense for whoever takes over, to adopt the whole suite (directfb, dfb++ and fusionsound), they have been maintained in the pkg-directfb alioth project, which I can hand over to the new maintainer(s). All patches have been sent and merged upstream, except for one, which I'm taking care of. There's intructions in that patch header on how to proceed for next upstream release. The package description is: DirectFB is a graphics library which was designed with embedded systems in mind. It offers maximum hardware accelerated performance at a minimum of resource usage and overhead. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24.1-zulo (PREEMPT) Locale: LANG=C, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465403: O: fusionsound -- audio sub system for multiple applications
Package: wnpp Severity: normal I've just orphaned the directfb suite of packages, which includes the fusionsound package. It might make sense to maintain the whole suite by the same maintainer(s). Check the other O: bugs. I can hand over the pkg-directfb alioth project to whoever takes over. The package description is: FusionSound supports multiple applications using Fusion IPC. It provides streams, static sound buffers and control over any number of concurrent playbacks. Sample data is always stored in shared memory, starting a playback simply adds an entry to the playlist of the mixer thread in the master application. . FusionSound currently is a module of DirectFB. The current API is fully implemented. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24.1-zulo (PREEMPT) Locale: LANG=C, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465184: libdebian-package-make-perl: Dpkg modules are not yet a public API
Package: libdebian-package-make-perl Version: 0.01 Severity: important Hi, This package is using some Dpkg perl modules, but those are private to dpkg-dev. We expect to make them a public API in the future but that's not the case yet. So we don't guarantee any kind of stability in the API. Please check /usr/share/doc/dpkg-dev/README.api. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465186: ocp: Should not use PAGESIZE in the source code
Package: ocp Version: 1:0.1.15-1 Severity: normal Hi, The source code uses PAGESIZE from the system or fallsback to hardcoding it to 4096 (which is what will happen on currently). This is wrong as the size is not static and is only known at runtime. The Linux kernel headers were fixed recently to stop exporting this variable as this should not have been exported ever. The code should switch to use 'sysconf(_SC_PAGESIZE)' instead. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465189: libgts-0.7-5: Unneeded dependency on libc6-dev
Package: libgts-0.7-5 Version: 0.7.6-1.1 Severity: normal Hi, This package Depends on libc6-dev, being it a shared library package, it seems wrong to pull all those development packages. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465190: libgts-0.7-5: Shipped programs make it not co-installable
Package: libgts-0.7-5 Version: 0.7.6-1.1 Severity: important Hi, This package ships several programs under /usr/bin, this makes co-installing this shared library with newer ones with different sonames not possible. Please split the binaries into a separate package. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465196: newt: cross and kfreebsd build support
Package: newt Version: 0.52.2-11.1 Severity: normal Tags: patch Hi, Here's a patch to make this package able to be properly cross built, and adds support for kfreebsd (for the libc-dev dependency). regards, guillem diff --git a/debian/rules b/debian/rules index 7dd7c5d..ecdc863 100755 --- a/debian/rules +++ b/debian/rules @@ -9,9 +9,6 @@ # Uncomment this to turn on verbose mode. # export DH_VERBOSE=1 -DEB_BUILD_GNU_SYSTEM = $(shell dpkg-architecture -qDEB_BUILD_GNU_SYSTEM) -DEB_BUILD_GNU_CPU = $(shell dpkg-architecture -qDEB_BUILD_GNU_CPU) - VERSION=0.52.2 SONAME=0.52 PYVERS=$(shell pyversions -vr debian/control) @@ -30,10 +27,12 @@ export DH_COMPAT=5 TAR_DIR=newt-$(VERSION) include /usr/share/dbs/dbs-build.mk -ifeq (,$(DEB_BUILD_GNU_TYPE)) +ifeq (,$(DEB_HOST_ARCH_OS)) include /usr/share/dbs/dpkg-arch.mk endif -ARCH=$(shell dpkg --print-architecture) + +DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) +DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU) # get the items created here. binarytarget=binary-devel binary-shared binary-runtime binary-tcl \ @@ -43,21 +42,25 @@ binarytarget=binary-devel binary-shared binary-runtime binary-tcl \ LIBCDEV=libc-dev GPMSUPPORT= -ifneq (,$(findstring linux,$(DEB_BUILD_GNU_SYSTEM))) +ifeq ($(DEB_HOST_ARCH_OS),linux) GPMSUPPORT= --with-gpm-support LIBCDEV=libc6-dev -ifeq ($(DEB_BUILD_GNU_CPU),alpha) +ifeq ($(DEB_HOST_ARCH_CPU),alpha) LIBCDEV=libc6.1-dev endif -ifeq ($(DEB_BUILD_GNU_CPU),ia64) +ifeq ($(DEB_HOST_ARCH_CPU),ia64) LIBCDEV=libc6.1-dev endif endif -ifeq ($(DEB_BUILD_GNU_SYSTEM),gnu) +ifeq ($(DEB_HOST_ARCH_OS),hurd) LIBCDEV=libc0.3-dev endif +ifeq ($(DEB_HOST_ARCH_OS),kfreebsd) +LIBCDEV=libc0.1-dev +endif + ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) NOSTRIP=--with-nostrip=no else
Bug#461653: echo foobar 2 is not a bashism!
On Mon, 2008-02-11 at 11:46:49 -, Adam D. Barratt wrote: Guillem Jover wrote: [...] In the original mail I referred to redirecting to the same file, and not file descriptor. Anyway the problem comes with something like: echo foo /dev/null echo foo /dev/null Those will fail in dash (for example), and as can bee seen from SUSv3 the only supported tokens after [n] are digits or '-'. Anything else gets an unspecified behaviour. I guess the biggest problem is that word can be anything which at the end expands to those valid tokens. Yeah, you're right; I should have read the relevant section of SUS more closely. No problem! I've now implemented a check for or followed by anything other than - or a string of digits. I've left the check for bare in place, as that's a bashism regardless of the surrounding context. For the case of expansion, I suppose it should be enough to ignore the cases there's a variable, like in: $ a=2 $ echo foo $a as to handle that properly, would imply parsing most of the shell script. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465404: O: dfb++ -- c++ bindings for DirectFB
Package: wnpp Severity: normal I've just orphaned the directfb suite of packages, which includes the dfb++ package. It might make sense to maintain the whole suite by the same maintainer(s). Check the other O: bugs. I can hand over the pkg-directfb alioth project to whoever takes over. The package description is: DFB++ is a C++ binding library for DirectFB, which is a graphics library designed with embedded systems in mind. It offers maximum hardware accelerated performance at a minimum of resource usage and overhead. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24.1-zulo (PREEMPT) Locale: LANG=C, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462677: rm assert error on arm: ((status) == RM_OK || (status) == RM_USER_DECLINED || (status) == RM_ERROR)
reassign 462677 linux-2.6 found 462677 2.6.22-6 thanks On Mon, 2008-01-28 at 08:06:56 +0200, Guillem Jover wrote: On Sun, 2008-01-27 at 13:20:38 +0100, Matthias Klose wrote: Guillem Jover writes: On Sat, 2008-01-26 at 23:11:32 +0100, Frank Lichtenheld wrote: On Sat, Jan 26, 2008 at 10:03:18PM +0100, Matthias Klose wrote: On Sat, 2008-01-26 at 20:59:15 +0100, Matthias Klose wrote: $ sudo dpkg -i /var/cache/apt/archives/dpkg_1.14.16.5_arm.deb (Reading database ... 31489 files and directories currently installed.) Preparing to replace dpkg 1.14.16.5 (using .../dpkg_1.14.16.5_arm.deb) ... Unpacking replacement dpkg ... rm: rm.c:371: main: Assertion `((status) == RM_OK || (status) == RM_USER_DECLINED || (status) == RM_ERROR)' failed. dpkg: error while cleaning up: subprocess rm cleanup killed by signal (Aborted) This assert is coming from the rm binary, and seems quite fishy. Is that system ok otherwise, fs, kernel, memory etc? yes, a thecus running armel, with an arm chroot. Can't reproduce this on my slug. It could be related to the OABI compat layer. Which kernel version are you guys using? linux-image-2.6.22-3-iop32x 2.6.22-6 Did you upgrade that recently? And would be possible to try with a non-EABI (normal arm) kernel, in case you have that chroot in a different partition, or maybe transfering it beforehand? Anyway, I don't think this is a problem related to dpkg in any way. I'm just reassigning accordingly. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466181: wine: Ships and uses embedded giflib sources
Package: wine Version: 0.9.54-1 Severity: important Tags: security Hi, This packages includes an embedded (partial) copy of giflib sources, this might be a problem for security updates or normal enhancements to the library. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466379: bochs: missing build dependency somewhere in openjade
tags 466379 unreproducible moreinfo thanks On Mon, 2008-02-18 at 13:35:35 +0100, Wilfried Goesgens wrote: Package: bochs Version: 2.3.6 Severity: serious Justification: no longer builds from source Working on: /root/bochs-2.3.6/doc/docbook/./documentation/documentation.dbk openjade:/root/bochs-2.3.6/doc/docbook/./documentation/documentation.dbk:10:55:W: cannot generate system identifier for public text -//OASIS//DTD DocBook V4.1//EN openjade:/root/bochs-2.3.6/doc/docbook/./documentation/documentation.dbk:16:0:E: reference to entity BOOK for which no system identifier could be generated . some dozends of lines later: openjade:/root/bochs-2.3.6/doc/docbook/./documentation/documentation.dbk:330:6:E: element SECT2 undefined openjade:I: maximum number of errors (200) reached; change with -E option openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/html/../common/dbtable.dsl:224:13:E: 2nd argument for primitive ancestor of wrong type: #node-list() not a singleton node list make[2]: *** [documentation/index.html] Error 8 make[2]: Leaving directory `/root/bochs-2.3.6/doc/docbook' make[1]: *** [build_docbook] Error 2 make[1]: Leaving directory `/root/bochs-2.3.6' make: *** [build-arch] Error 2 The only place in the source code that any jade command is called is in doc/docbook/Makefile.jade, which is not used by defualt (Makefile.in is), so I don't see how this could possibly fail. Are you using that Makefile.jade instead? I cannot reproduce this, and will probably close this report in few days. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451954: gettext: Package will not configure
retitle 451954 /usr/share/info switched from a directory to a file severity 451954 important tags 451954 moreinfo thanks [ Replying to the bug log, as you only replyed to myself. ] On Tue, 2007-11-20 at 03:40:35 -0500, Avalith wrote: Guillem Jover wrote: On Mon, 2007-11-19 at 08:02:20 -0500, Avalith wrote: Package: gettext Version: 0.16.1-2 Severity: grave Justification: renders package unusable gettext will not configure because it claims to need access to /usr/share/info/dir when /usr/share/info is a file, so the directory cannot exist. How did you end up with /usr/share/info being a file? Did you create it? I didn't create it. I think it was created during the installation of another package, but I'm not positive. Well, I don't think this is a problem in dpkg, but given the lack of information I don't know where this could be reassigned. If you still have the logs from that time around, could you send to the bug report /var/log/dpkg.log /var/log/apt/term.log and /var/log/aptitude, or whatever rotated log might be appropriate? thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#253265: [S-S-D] Please add '--pid' option
tag 253265 moreinfo thanks On Tue, 2004-06-08 at 11:27:37 +0200, Thomas Hood wrote: Package: dpkg Version: 1.10.22 Severity: wishlist For some purposes it would be useful to be able to give the PID to start-stop-daemon directly, using a --pid=12345 option, rather than via a pidfile and --pidfile=/path/to/file. Of course one can use kill, but then one can't make use of s-s-d's --retry feature. Can you give a bit more information when you would use that option? thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461247: dpkg: update-alternatives --test doesn't work as advertised
forcemerge 392432 461247 thanks On Fri, 2008-01-18 at 00:28:34 +0100, Raphael Hertzog wrote: On Thu, 17 Jan 2008, Toby Speight wrote: Package: dpkg Version: 1.14.7 Severity: important File: /usr/sbin/update-alternatives /[ update-alternatives --help ] | Options: | --test don't do anything, just demonstrate. \ But when I tried using --test to check my --remove-all command, I got no output, and I discovered that the remove-all had actually been performed. Luckily, I had got my command right... Confirmed: $ grep testmode scripts/update-alternatives.pl my $testmode = 0; $testmode= 1; So it looks like this never got implemented... this was already the case in dpkg 1.1.4 in 1996 (this is as far as I can go in the history). Thus I suggest to simply remove that option altogether from the script and the manual page. I was about to add 'not yet implemented' in the --help output to sync it with the manpage, but thinking how this could be implemented I've to say I agree we better just remove the option. The whole script depends on the files it has changed/removed/symlinked during the whole execution. So I'll just do that. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444341: update-alternatives doesn't describe the generic names
forcemerge 323009 444341 thanks Hi, On Thu, 2007-09-27 at 21:55:01 +0100, [EMAIL PROTECTED] wrote: Package: dpkg Version: 1.13.25 There seems to me to be a gaping hole in the update-alternatives program in that there's all this talk about generic names but no mention of what they actually are, so it is hard to use the program. The only way it seems to me to find them is to use 'ls /etc/alternatives'. For now, the man and info pages should at least advise using 'ls /etc/alternatives'; better still would be to list the generic names in the man and info pages. The generic names are not predefined, so I don't think that listing them in the man page is a possibility. In the longer, term a switch to list the generic names would be great. I guess the requested --list-all would accomplish that, so merging the bug reports. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#24514: 3 diff's to compile dpkg-1.4.0.24 on HP-UX
tag 24514 pending thanks Hi, On Mon, 1998-07-13 at 15:59:34 +0100, [EMAIL PROTECTED] wrote: Package: dpkg Following patches are included below: 1) dpkg1.diff This patch suppesses error output from configure if dpkg is not present in $PATH This should not be suppressed, I've on my TODO supporting bootstrapping dpkg on new architectures, though. 2) dpkg2.diff This is a workaround for old shells, such as /bin/sh from HP-UX 10.20 and ksh from the same system. Double quotes are not needed around reversed single quotes, but they can prevent $target_cpu from expansion on some old shells. This didn't apply anymore, but I've fixed some instances of this problem in the code. Fixed in git and will be included in next release. 3) dpkg3.diff #include stddef.h is necessary, because dpkg/enquiry.c uses ptrdiff_t which is defined there. It may be included from other files on other OS'es but not on HP-UX. Anyway, either stddef.h is included, directly or indirectly, or gcc reports an error. And this is not needed anymore, stddef.h is now included from dpkg.h. Unfortunately, above patches are not sufficient to compile dpkg on HP-UX. I simply don't have enough time to fix everything. If you or anyone else happen to port it to other Unix system, feel free to provide patches. By the way, it would be a good idea to provide a script which generates all necessary scripts. I mean something like following: #!/bin/sh aclocal -I automake libtoolize --automake --copy --force gettextize --copy --force autoheader automake --add-missing autoconf This can be replaced now by «autoreconf -f -i». thanks, guillem
Bug#461327: important priority too high for dselect
On Sat, 2008-01-19 at 13:20:42 -0500, Joey Hess wrote: Raphael Hertzog wrote: We have changed that to optional in the git repo. Did you also open a bug on ftpmaster's side? No, it seemed better to let the dpkg maintainers decide if I was right and handle replying to the override messages as usual. Yes, that's what I was planning to do. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354999: setting package to dpkg dpkg-dev dselect, tagging 354999
On Fri, 2008-01-18 at 14:01:17 -0500, Justin Pryzby wrote: On Fri, Jan 18, 2008 at 07:46:52PM +0100, Raphael Hertzog wrote: On Fri, 18 Jan 2008, Justin Pryzby wrote: On Fri, Jan 18, 2008 at 08:38:03AM +0200, Guillem Jover wrote: tags 354999 + pending What change are you making? I just checked (after realizing that my http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=925bf488839ed0442700d80c0df681c34bf2ec87 It's the --help output that has been clarified. That was actually what the bug report was about (at least one of the parts) . :) Oh. Might I suggest calling those matching options instead of mandatory options? Also they could be segregated in the manpage, too. Sure, mandatory + required seemed redundant but didn't come with anything better. I'll fix both. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461650: ski: switch to use binfmt-support
Package: ski Version: 1.1.3+dfsg-2 Hi, This package ships an init script to setup the binfmt_misc support. Please don't reinvent the wheel and switch to use the package binfmt-support. (As a side effect, dropping the init script would fix the function bashism in it). thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461653: [checkbashisms] Should check for and
Package: devscripts Version: 2.10.13 Hi, Redirecting both stdout and stderr to the same file with 'word' and 'word' is a bashism. It should be replaced by 'word 21'. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461653: echo foobar 2 is not a bashism!
Hi, On Sun, 2008-02-03 at 23:24:06 +, Adam D. Barratt wrote: On Sun, 2008-02-03 at 22:13 +0100, Sven Joachim wrote: [...] after the fix for bug #461653 I get tons of errors in my scripts for redirecting messages to stderr: , | possible bashism in baz line 13 (should be word 21): | echo foobar 2 ` According to http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html, sections 2.7.5 and 2.7.6, the constructions word and word are perfectly valid /bin/sh syntax. Please don't complain about them. Indeed (although the bash manpage doesn't exactly help the impression of being bash-specific). So far as I can see, however, /is/ a bashism, so I'll amend the test to just check for that. Uh, right, sorry about that. I tripped over in dash and checked the bash man page, and mentioned both in the bug report, should have checked SUS though. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464222: directfb: FTBFS: Obsolete Build-Depends
Hi, On Tue, 2008-02-05 at 16:17:07 -0500, Daniel Schepler wrote: Package: directfb Version: 1.0.1-6 Severity: serious directfb has Build-Depends on libts0-dev. However, that is no longer available and has been replaced by libts-dev, so directfb's Build-Depends cannot be satisfied. Yes, I know, Neil notified me few days ago that this change would be happening, but was waiting for directfb to migrate to testing first, as it fixes an annoying problem for splashy users. Thanks for the bug report anyway. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379150: Documentation for Breaks in dpkg
Hi, On Tue, 2008-01-01 at 13:46:58 -0800, Russ Allbery wrote: Ian Jackson [EMAIL PROTECTED] writes: Package: debian-policy Version: 3.7.2.1 Severity: wishlist Tags: patch As I report in #379140 (against dpkg), I have implemented Breaks in dpkg. The attached patch is the corresponding change to the manual. It would probably not be wise to apply this patch until we have settled on a deployment plan for Breaks in Debian; as I say in #379140, I hope to get around to that this weekend. Here is an updated patch. The changes from Ian's original patch are: * Add a statement saying that Breaks should not be used until support is present in Debian stable, which I think was the consensus of recent discussion on the policy list, and also note this near the mention of Breaks in the Conflicts section. * Just remove the entire paragraph about suidmanager from the dpkg-statoverride section rather than changing it to use Breaks. suidmanager predates oldstable at this point; I don't think there's any reason to mention it ever existed at this point. dpkg folks, could you please review this patch as a final double-check that it matches the dpkg implementation as was committed and released? I want to be sure that nothing changed from the original patch so that we don't document the wrong thing in Policy. The patch seems fine. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458994: fsvs: typo in package description
Package: fsvs Version: 1.1.11-1 Severity: minor Hi, This package has a typo in the long package description: «It it a complete ...» should be «It is a complete ...». regards, guillem
Bug#458995: abcde: typos in --help output
Package: abcde Version: 2.3.99.6-1 Severity: minor Hey! The --help output has two typos: -s field Show dielfs from the CDDB info (year,genre) s/dielfs/fields/ -W # Contatenate CDs: -T #01 -w CD # s/Contate/Concate/ regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430649: New proposed wording for DEB_BUILD_OPTIONS
Hi, On Sun, 2007-12-30 at 19:23:58 -0800, Russ Allbery wrote: Okay, here's a revised proposal to address both Bug#209008 (parallel) and Bug#430649 (DEB_BUILD_OPTIONS parsing). This proposal does the following: --- orig/policy.sgml +++ mod/policy.sgml + sect id=debianrules-options + headingfiledebian/rules/file and + ttDEB_BUILD_OPTIONS/tt/heading + + p + Supporting the standardized environment variable + ttDEB_BUILD_OPTIONS/tt is recommended. This variable can + contain several flags to change how a package is compiled and + built. Each flag must be in the form varflag/var or + varflag/var=varoptions/var. If multiple flags are + given, they must be separated by whitespace.footnote + Some packages support any delimiter, but whitespace is the + easiest to parse inside a makefile and avoids ambiguity with + flag values that contain commas. + /footnote + varflag/var must consist only of lowercase letters + (tta-z/tt), numbers (tt0-9/tt), and the characters + tt-/tt and tt_/tt (hyphen and underscore). + varoptions/var must not contain whitespace. The same + tag should not be given multiple times with conflicting + values. Package maintainers may assume that + ttDEB_BUILD_OPTIONS/tt will not contain conflicting tags. + /p Could this be changed to say that flags start with «[a-z]» optionally followed by 0 or more «[a-z][0-9]-_»? regards, guillem
Bug#452105: debian-policy: Homepage field in debian/control undocumented
Hi, On Mon, 2008-01-07 at 12:37:14 -0800, Russ Allbery wrote: Bill Allombert [EMAIL PROTECTED] writes: When I try that, I get: dpkg-source: warning: unknown information field 'Homepage' in input data in package's section of control info file ... dpkg-genchanges: warning: unknown information field 'Homepage' in input data in package's section of control info file Huh. Okay, fixed in my version to only list it for the source stanza (and the binary and source control files). Those are harmless warnings, those two programs were just failing to recognize and ignore the field. But this does not affect the functionallity. I've fixed the bogus warnings now in dpkg's git commit 2006f64. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459815: dpkg-source -x: compression is not defined in %Dpkg::EXPORT_TAGS
Hi,
On Tue, 2008-01-08 at 22:21:28 +0100, martin f krafft wrote:
Package: dpkg-dev
Version: 1.14.14
Severity: important
File: /usr/bin/dpkg-source
piper:/tmp/cdt.mEl10063 dpkg-source -x libarchive_1.2.53-2etch1.dsc
compression is not defined in %Dpkg::EXPORT_TAGS at /usr/bin/dpkg-source
line 6
main::BEGIN() called at /usr/share/perl5/Dpkg.pm line 6
eval {...} called at /usr/share/perl5/Dpkg.pm line 6
Can't continue after import errors at /usr/bin/dpkg-source line 6
BEGIN failed--compilation aborted at /usr/bin/dpkg-source line 6.
ouch.
ii dpkg1.14.15 package maintenance system for
Deb
Your dpkg-dev is outdated. But yes, I forgot to add the proper
Conflicts against 1.14.14 and 1.14.13. Will do that later.
thanks,
guillem
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457741: Bug#460158: zsh-doc would not install
reassign 457741 texinfo thanks On Fri, 2008-01-11 at 08:58:18 +0100, Raphael Hertzog wrote: On Thu, 10 Jan 2008, Clint Adams wrote: On Fri, Jan 11, 2008 at 12:35:57AM +0100, arno renevier wrote: zsh-doc upgrade did not work today. I tried to uninstall, and reinstall, and it looks like package is uninstallable. Here is the output I get with aptitude install zsh-doc: This is bug #457741 on dpkg. I haven't investigated at all and I'm in no way an expert concerning info files. But from what I've read, I must say that I'm not yet sure that it's a bug in dpkg... Is there a real standard on what an info file should look like ? Or are we at the mercy of every output change of the info file generator ? I'd gladly fix install-info (until we manage to get rid of it that is :)) if someone could point me to relevant information. I don't think we should fix this in dpkg. I don't think it's a bug in install-info, otherwise installing any package from testing/unstable on etch will fail, like on a partial upgrade. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Fri, 2008-01-11 at 01:24:33 +0100, Frans Pop wrote: On Friday 11 January 2008, you wrote: Joey, I don't think that that the Package-Type field ending up in the binary package can be qualified as bloat given that except the filename and the origin of the file, udeb can't be identified as such. I'm sorry, but I agree with Joey. There is absolutely no reason why we need the package type in the control file for udebs. They are already 100% identifyable by both section and extention. Well then there's also the argument that there's no point in having it in the source control either, it could be inferred from the section. But those seem quite weak and specific ways to do so. Anyway, I don't think that'd be clean, and we might want to use that field for other package types in the future (translation debs, or debugging debs come to mind). The way this was implemented basically just ignores the only current official user of the package type field, I mentioned I'd implement it that way one year ago (or so) on #d-b, and no one seemed to oppose, and I requested comments on the patch implementing this again on #d-b few days before committing. That does not mean that decision could not be changed, but I don't see a good reason to do so, the current implementation seems cleaner anyway. and is thus not policy compliant. The initial udeb support seems to have been implemented and deployed in an ad-hoc way, overriding[0] dpkg, which is perfectly fine, as that's how a lot of things are implemented and deployed in Debian. But I'd not go as far as calling that policy. regards, guillem [0] I'm not sure this strictly expresses the meaning I've in mind, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Fri, 2008-01-11 at 12:29:40 -0500, Joey Hess wrote: Your continual closusre of this bug report Sorry, but the closure was not intentional, just what was on the Reply-To, and didn't see Frans reopen until later. Also notice you also replyed with the -done CCed. and refusal to listen to us is becoming very annoying. I don't think I'm refusing to listen, but it seems that to listen implies doing as you guys please. I just wanted a convincing argument. But this is getting non-constructive, and at some point I might just give up and not care at all. :/ regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460309: dpkg: debian/control doesn't allow one homepage per binary package
severity 460309 minor retitle 460309 Fix warnings when using Homepage on binary package stanzas thanks Hi, On Sat, 2008-01-12 at 00:12:13 +0100, Armin Berres wrote: Package: dpkg Version: 1.14.15 Severity: normal Lot's of the KDE source packages have a different upstream homepage for every binary package, because all the different projects are released together in one tarball. Right now it is not possible to express this in the Control file, because the homepage must be set per source package. Otherwise dpkg-source tells you the following: dpkg-source: warning: unknown information field 'Homepage' in input data in package's section of control info file Please implement the possibility to specify a different homepage per binary packages than specified for the source package. This has been supported from the beginning, the only problem is those missleading warnings. Next release fixes the warnings problem, though. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Hi, On Wed, 2007-11-21 at 17:10:39 +0100, Frans Pop wrote: The actual problem seems to be that XC-Package-Type is not included in %f. Maybe because of the XC- prefix? From a debugging session: %f = ( 'Architecture' = 'all' 'Depends' = 'cdebconf-udeb, di-utils (= 1.18)' 'Description' = 'Execute a shell' 'Installer-Menu-Item' = 95000 'Maintainer' = 'Debian Install System Team [EMAIL PROTECTED]' 'Package' = 'di-utils-shell' 'Priority' = 'standard' 'Section' = 'debian-installer' 'Version' = 1.50 ) Note that almost all udebs currently have XC-Package-Type as header instead of Package-Type, so supporting that would be very much appreciated. It's not included and has never been, because only the ones with B are. But now it's explicit given that dpkg-gencontrol supports the field. Package-Type should have been XB- from the beginning. That information is pertinent to the binary package and not to the changes file. Also this way dpkg-deb will be able to automatically select the correct extension, for example. So if there's no other argument I'll close the bug report tomorrow or so. Note that apart from the warning the current udebs should build as before. Should we start converting to use Package-Type? Sure. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436473: arj: not handling nostrip build option (policy 10.1) sid/i386
Hi, On Tue, 2007-08-07 at 20:41:07 +0200, Julien Danjou wrote: Package: arj Version: 3.10.22-3 Severity: wishlist User: [EMAIL PROTECTED] Usertags: nostrip There was a problem while autobuilding your package with DEB_BUILD_OPTIONS=nostrip. Final binaries are still stripped. If you call dh_strip correctly in debian/rules, this may mean that upstream is stripping anyway. Automatic build of arj_3.10.22-3 on octave for sid/i386 by rebuildd 0.2.1 Build started at 2007-08-07 18:25:23.971402 ** [...] dh_link # NOTE: Do not strip, it is currently done in the linker stage. # Otherwise when stripping the self-extracting modules and the # help text are removed. dh_compress [...] Checking arj_3.10.22-3_i386.deb for stripped binaries... --- /tmp/arj_3.10.22-3_i386.deb/usr/bin/arj-register: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped /tmp/arj_3.10.22-3_i386.deb/usr/bin/arjdisp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped /tmp/arj_3.10.22-3_i386.deb/usr/bin/arj: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped /tmp/arj_3.10.22-3_i386.deb/usr/bin/rearj: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped /tmp/arj_3.10.22-3_i386.deb/usr/lib/arj/arjcrypt.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped The problem is that the help text, translations and other documentation is appended to the binary, and it opens itself when called with print -?, for example. So stripping cannot be done later on, because then the messages get stripped as well. Ideally arj should be switched to a sane system like gettext, and then this would get fixed automatically, but I've not had the time to do this. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452608: gnash: unused Build-Depends on libdirectfb-dev
Source: gnash Source-Version: 0.8.1~rc.070818-2 Hi, This package Build-Depends on libdirectfb-dev, although it does not seem to link against any of its libraries. Please remove this dependency. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452607: pigment: unused Build-Depends on libdirectfb-dev
Source: pigment Source-Version: 0.3.1-2 Hi, This package is Build-Depending on libdirectfb-dev, although it does not seem to be linking against its libraries. Please remove the dependency. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Hi, On Mon, 2007-12-10 at 15:46:01 +0200, Jussi Hakala wrote: Package: dpkg Version: 1.13.25 Etch's dpkg does not recognize arm-none-linux-uclibcgnueabi as a valid architecture. Just to clarify, the version in etch is not going to be updated for this anyway, that's Debian release policy. Don't know if this architecture string is exactly a proper one to begin with, but at compile time it seemed like the most reasonable one from all the options... It seems like a valid GNU triplet. Although for dpkg purposes the -none- is unneeded. Anyway, we need a separate architecture for armel+uclibc. Given other conversations, I take this is for Maemo. And my same concerns apply, why do you need a new architecture? And do you realize this would imply having two different dpkg db (there's no multiarch support yet anyway)? Meanwhile, made this horrid patch to get the architecture recognized as armel, as with the ordinary arm+glibc equivalent. This is the completely wrong approach, I'd recommend you don't do that in Maemo either. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455841: dpkg: [INTL:ja] updated Japanese program translation
Hi, On Wed, 2007-12-12 at 12:02:56 +0900, Kenshi Muto wrote: Package: dpkg Version: 1.14.12 Severity: wishlist Tags: l10n patch I updated Japanese translation of program messages (ja.po), taking from current git head version. The string scripts/update-alternatives.pl:74 has a missing format specification, could you fix it? You can check for this kind of errors with: «msgfmt --statistics -o /dev/null --check ja.po» I think I can do it by myself if you add my account (kmuto) to the Alioth dpkg project. I'll add you later. thanks, guillem
Bug#456847: gpm: FTBFS: error: 'OPEN_MAX' undeclared (first use in this function)
merge 455427 456847 thanks On Tue, 2007-12-18 at 09:01:47 +0100, Lucas Nussbaum wrote: Package: gpm version: 1.19.6-25 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20071217 qa-ftbfs Justification: FTBFS on i386 During a rebuild of all packages in sid, your package failed to build on i386. Relevant part: special.c: In function 'processSpecial': special.c:158: error: 'OPEN_MAX' undeclared (first use in this function) special.c:158: error: (Each undeclared identifier is reported only once special.c:158: error: for each function it appears in.) This has already been filed and fixed in svn just pending an upload. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456948: irda-utils: Please loosen the dependency to setserial
Package: irda-utils Version: 0.9.18-6 Severity: wishlist Hi! Could the setserial dependency be moved from Depends to Suggests (or at least Recommends). Currently one has to manually enable setserial usage in /etc/default/irda-utils anyway, and that file points to the README.Debian file which could tell the user to install the relevant package. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457022: O: ofbis -- simple Linux framebuffer graphical library
Package: wnpp Severity: normal I orphaned the ofbis package some days ago. I packaged this library as a requisite for zen (a modular web browser), but both projects stalled upstream, and never ended up uploading zen. Someone might be interested in taking over this package, and its related alioth project [0], ask me and I'll transfer it. If the package has not been taken over in several months I might ask for its removal. The package description is: It is intended to be fast and easy to both use and support, with respect of adding support for other graphical types and machines. It supports 8-bit static pseudocolor mode (chunky) and 16-bit truecolor. . This package contains the libofbis development files (headers and static libraries). It is only needed if you want to compile programs that use oFBis. regards, guillem [0] http://alioth.debian.org/projects/pkg-ofbis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220044: Can anybody *please* fix #220044 - broken slave files (link)
Hi Daniel, On Wed, 2007-12-19 at 00:39:00 +0100, Daniel Leidert wrote: Am Dienstag, den 18.12.2007, 20:40 + schrieb Ian Jackson: If there were a well-tested and sensible fix, with a clear explanation of what the bug was and how the patch corrects it, which hadn't been merged, then you might well wonder whether the maintainers were properly performing their most critical and un-delegateable role, which is to be gatekeeper. But that's not the case here. The problem is caused in config_alternatives() near line 680. There simply the link in /etc/alternatives is created, but it is not checked, if $slavelinks[$slnum] exists. Now there is some code at line 597 for the auto action, that does, what we need in config_alternatives() too. The question: Should this code be put into a new function? If we need it twice, it IMHO makes sense. A patch is attached using this idea. Yes, that's good. Thanks for the patch, I've just skimmed over it and seems reasonable will check before commiting. Please check it and tell me your opinion (e.g. if the coding style is ok). I would simply adjust the patch, if you have concerns or improvements. But then this bug can be closed. I think there's a problem with the indentation, but don't worry I'll fix before commit. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457673: dpkg: man/Makefile.am should respect the nls configure flag
tag 457673 pending thanks On Mon, 2007-12-24 at 06:41:22 -0500, Mike Frysinger wrote: Package: dpkg Version: 1.14.12 Severity: wishlist the man/Makefile.am file explicitly checks for all LINGUAS. it should take $(USE_NLS) into consideration so that you can build dpkg on a system without nls support. the patch is quite trivial: # Extract the list of languages from the po4a config file. +ifeq ($(USE_NLS),yes) LINGUAS = $(shell sed -ne 's/^.*\[po4a_langs\] \(.*\)$$/\1/p' $(srcdir)/po/po4a.cfg) +else +LINGUAS = +endif I've committed a different fix for this, will be included in next release. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457863: does not install
Hi, On Wed, 2007-12-26 at 17:54:56 +0100, David Andel wrote: Package: aterm Version: 1.0.1-3 Severity: important Setting up aterm (1.0.1-3) ... Use of uninitialized value in length at /usr/sbin/update-alternatives line 735. I've fixed this now in git, but it should not be fatal. update-alternatives: error or eof reading /var/lib/dpkg/alternatives/x-terminal-emulator for update_mode () dpkg: error processing aterm (--configure): subprocess post-installation script returned error exit status 2 Could you send your '/var/lib/dpkg/alternatives/x-terminal-emulator' to this bug report? thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458152: libcomplearn-mod-ppmd: Embedded duplicate ppmd source
Package: libcomplearn-mod-ppmd Version: 1.0.6-1 Severity: important Tags: security Hi, This package contains an embedded copy of the ppmd source. It should be using the external program instead for security reasons and to get the benefits of the portability patches (also most probably the binaries for the 64 bit arches are going to segfault, as the upstream code is not 64 bit clean). regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458153: libcomplearn-mod-lzmax: Missing lzma dependency
Package: libcomplearn-mod-lzmax Version: 1.0.6-1 Severity: serious Hi, This package uses the external lzma command to perform the (de)compression operations, but the dependency is missing, thus making the package quite useless without it. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383448: reopen
tags 383448 - pending thanks On Thu, 2007-09-06 at 03:53:39 +0300, Guillem Jover wrote: On Fri, 2006-10-13 at 16:36:56 +0200, Jordi Mallach wrote: On Thu, Oct 12, 2006 at 10:31:56PM +0200, Robert Millan wrote: I applied it, but when talking with jordi on irc, which at the time you were present, he complained about the changes you were doing, and I asked him to review them and act as needed. He eventually reverted them. Ok. Looking forward to Jordi's response. Wow, Robert, I must have reverted them by mistake on my last update. I'm out until Sunday, but am taking with me a few po's that bubulle has been sending to try to get the final bits of the installer process in place. Let me update dpkg first, and later we can reapply the bits that are good in the updated file. Jordi could you take a look at this, it seems this got forgotten by all of us at some point, and I'd like to close this bug which has been marked as pending for long time. Removing the pending tag as this does not seem to be going to be resolved soon? :) thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458108: qa.debian.org: Package's arch list repeated multiple times
Hi, On Fri, 2007-12-28 at 13:26:44 -0500, Roberto C. Sánchez wrote: On Fri, Dec 28, 2007 at 07:16:06PM +0100, Stefano Zacchiroli wrote: $ apt-cache showsrc ddccontrol|grep Architecture Architecture: i386 amd64 ia64 alpha arm i386 amd64 ia64 alpha arm i386 amd64 ia64 alpha arm i386 amd64 ia64 alpha arm I can fix the PTS to avoid showing duplicates, but I must say I'm inclined to delay the fix and let you check whether the apt-cache behaviour is correct or we have a bug in something more important than the PTS here ... What do you think? I agree that the data should not be reaching the PTS in that form to begin with. This was due to a bug from an old dpkg-source, just rebuilding the source package will fix this. regards, guillem
Bug#458152: libcomplearn-mod-ppmd: Embedded duplicate ppmd source
Hi, On Fri, 2007-12-28 at 20:02:01 -0800, Rudi Cilibrasi wrote: On Dec 28, 2007 7:37 PM, Guillem Jover [EMAIL PROTECTED] wrote: Package: libcomplearn-mod-ppmd Version: 1.0.6-1 Severity: important Tags: security This package contains an embedded copy of the ppmd source. It should be using the external program instead for security reasons and to get the benefits of the portability patches (also most probably the binaries for the 64 bit arches are going to segfault, as the upstream code is not 64 bit clean). Thanks for the heads-up. As it turns out, this package is not duplicate source. It is a derived work made by Maarten Keijzer. The librification was done by him for the purpose of this module. Coder.hpp|0 Model.cpp| 13 + PPMd.h |3 +-- PPMdType.h | 44 +++- SubAlloc.hpp |0 3 files changed, 13 insertions(+), 47 deletions(-) This is a total of 60 KiB of duped source code except for those lines changed as shown in the diffstat. If it is broken on 64-bit machines then I think I will need to remove it from the build. But that has yet to be demonstrated on this version. I am closing this bug until evidence to that effect comes to me. Just check the ppmd package. The patches should apply mostly cleanly, and there's no significant differences that would fix any 64 bit clean issue, there's also unaligned access fixes in the ppmd package not present in this one. The segfaults was one of the reasons I added a build time check for the binary, so that it would fail early and not provide broken packages. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458108: qa.debian.org: Package's arch list repeated multiple times
On Sat, 2007-12-29 at 00:11:20 -0500, Roberto C. Sánchez wrote: On Sat, Dec 29, 2007 at 07:06:37AM +0200, Guillem Jover wrote: This was due to a bug from an old dpkg-source, just rebuilding the source package will fix this. That package was built over six months ago, so the bug was probably fixed long ago. Right? Yep, in dpkg 1.14.5 (2007-07-03). regards, guillem
Bug#461985: ITP: libbsd -- BSD compatibility library
Package: wnpp Severity: wishlist Owner: Guillem Jover [EMAIL PROTECTED] * Package name: libbsd Version : 0.0 Upstream Author : The FreeBSD project * URL : http://www.freebsd.org/ * License : BSD Programming Lang: C Description : BSD compatibility library This library provides some functions available on FreeBSD's libc but not on glibc. This devel package also includes some queue macro definitions not present on includes from glibc. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23.12-zulo (PREEMPT) Locale: LANG=C, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462225: start-stop-deamon: select() failed for pause: Invalid argument
Hi, On Thu, 2008-01-24 at 10:32:40 +0100, Andreas Påhlsson wrote: I've reworked the patch to apply to 1.14.16.4. There are some subtle changes. Thanks for the initial patch and this one! * tsub is removed in favour of timersub (sys/time.h). Thought about that just after upload. Will merge. * tmul is reimplemented as it was broken. Ooops, that's right, shame on me, I was really tired that evening and I don't know what I was thinking about (probably timer addition). Will merge as well. * interval is checked right before select. There was a corner case if maxinterval was negative. This one is actually not needed. maxinterval should never be negative, that should be catched already by the previous timercmp. thanks, guillem
Bug#462405: ppmd: FTBFS: tests segfaults [alpha, amd64, ia64]
forcemerge 178840 462405 370419 thanks On Thu, 2008-01-24 at 18:22:10 +0100, Philipp Kern wrote: Package: ppmd Severity: serious Version: 9.1-14 Your package failed to autobuild because the test suite segfaults.[0] This affects at least alpha, amd64 and ia64[1]. I know, that's because the code is not 64 bit clean. There's several bug reports about this already in the BTS, and this is not RC as there's no binaries for those architectures. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456332: dpkg could use an elevated pre-depends or depends on lzma
[ CCed Mohammed for the lzma package size reduction part. ] Hi, On Fri, 25 Jan 2008, Ian Jackson wrote: Raphael Hertzog writes (Bug#456332: dpkg could use an elevated pre-depends or depends on lzma): The debian/control field is the only viable option IMO. It would be somewhat similar to the Package-Type: header which has no real use except influencing the behaviour of another tool during the build. Having slept on it I think this is the right answer. Compression-Type: gzip|bzip2|lzma|... converted into Pre-Depends: deb-decompressor-lzma by dpkg-gencontrol The problem with that is when unpacking and repacking a .deb with a different compression, dpkg-deb would have to munge the Pre-Depends. Even if that should be safe with such virtual package, I don't feel comfortable doing that. The other problem is that all current packages using bzip2 or lzma would have to gain such dependency (supposedly gzip ones as well?!), there should not be many using bzip2 or lzma, though. On Fri, 2008-01-25 at 18:54:10 +, Ian Jackson wrote: Raphael Hertzog writes (Re: Bug#456332: dpkg could use an elevated pre-depends or depends on lzma): I'm still not convinced that this is the right approach, Pre-Depends are supposed to not be used lightly. Does the package need to be configured, isn't a simple dependency enough ? Yes, I'm not convinced either that using a dependency is the way to go (although yes, I agree that if we'd have to use one, that should be a Pre-Depends). And we're speaking of: $ dpkg -s lzma | grep Installed Installed-Size: 292 $ dpkg -s bzip2 | grep Installed Installed-Size: 124 Between them that's nearly half a megabyte. (That's not to mention the couple more we're bound to acquire if we make this actually work well.) Probably lzma_alone (104 KiB) could be removed at some point from the lzma package, and few docs moved to lzma-dev where they belong (20 KiB). Also probably only that one package in base switched to lzma we'd recover that space anyway. The downsides of a Pre-Depends is that it makes installation ordering much more tricky - but this Pre-Depends is in fact an accurate reflection of the situation. If the Pre-Depends is absent and installation operations are done that it would have prevented, those operations will fail. Ian, I can see your point, about the correctness (depends on demand), and not encoding the archive state in the metadata of all .deb (virtual package). But on the other hand it's dpkg who is calling the lzma binary, it's an implementation detail as Chris said. Also dpkg either supports it or it does not, regardless of any Pre-Depends any package might have. And we do something similar with Essential packages. The only concern I can see with dpkg having the Pre-Depends is that if we have a .deb with an unsupported compression, installation will fail too late. But I don't think that's that important as this should not happen on the archive anyway (those would get rejected). Also just for reference, the main reason I didn't add the Pre-Depends to dpkg in etch was because it was near a freeze (or already frozen, don't remember now) and didn't want to destabilize d-i at that time. That was probably a mistake, but I don't regret having played safe, there's always time in the future to fix things. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462677: dpkg fails to install on arm
Hi, On Sat, 2008-01-26 at 20:59:15 +0100, Matthias Klose wrote: Package: dpkg Version: 1.14.16.5 Severity: important $ sudo dpkg -i /var/cache/apt/archives/dpkg_1.14.16.5_arm.deb (Reading database ... 31489 files and directories currently installed.) Preparing to replace dpkg 1.14.16.5 (using .../dpkg_1.14.16.5_arm.deb) ... Unpacking replacement dpkg ... rm: rm.c:371: main: Assertion `((status) == RM_OK || (status) == RM_USER_DECLINED || (status) == RM_ERROR)' failed. dpkg: error while cleaning up: subprocess rm cleanup killed by signal (Aborted) This assert is comin from the rm binary, and seems quite fishy. Is that system ok otherwise, fs, kernel, memory etc? Setting up dpkg (1.14.16.5) ... chown: changing ownership of `0\323\022': No such file or directory dpkg: error processing dpkg (--install): subprocess post-installation script returned error exit status 1 And I guess this one is coming from the chown called from dpkg.postinst, which seems quite fishy as well. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462677: dpkg fails to install on arm
On Sat, 2008-01-26 at 23:11:32 +0100, Frank Lichtenheld wrote: On Sat, Jan 26, 2008 at 10:03:18PM +0100, Matthias Klose wrote: On Sat, 2008-01-26 at 20:59:15 +0100, Matthias Klose wrote: $ sudo dpkg -i /var/cache/apt/archives/dpkg_1.14.16.5_arm.deb (Reading database ... 31489 files and directories currently installed.) Preparing to replace dpkg 1.14.16.5 (using .../dpkg_1.14.16.5_arm.deb) ... Unpacking replacement dpkg ... rm: rm.c:371: main: Assertion `((status) == RM_OK || (status) == RM_USER_DECLINED || (status) == RM_ERROR)' failed. dpkg: error while cleaning up: subprocess rm cleanup killed by signal (Aborted) This assert is comin from the rm binary, and seems quite fishy. Is that system ok otherwise, fs, kernel, memory etc? yes, a thecus running armel, with an arm chroot. Can't reproduce this on my slug. It could be related to the OABI compat layer. Which kernel version are you guys using? regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370349: we dont use inetutils-syslogd
Hi, On Mon, 2008-01-28 at 00:20:04 +0100, Holger Levsen wrote: as we dont use inetutils-syslogd (anymore?), we don't care about this anymore. Who is we? :) And why would the fact that that we is not using it anymore make this bug invalid? Holger (who thinks that this bug might actually have been a bogus duplicate of #370399...) I don't see why, could you explain? regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462909: O: bmv -- PostScript viewer for SVGAlib
Package: wnpp Severity: normal I just orphaned the bmv package. I can transfer the ownership of the alioth project to the next maintainer, just ask for it. The package description is: BMV is a frontend for GhostScript. Using BMV you can now preview your PostScript files comfortably. You can also use it for viewing rawPBM image files. It uses SVGAlib and it is intended for Linux users who cannot run X. It is particularly suitable for previewing PS files from dvips. It is small and fast. . The Debian version of bmv is patched to include a rotate option and further keybindings. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462677: dpkg fails to install on arm
On Sun, 2008-01-27 at 13:20:38 +0100, Matthias Klose wrote: Guillem Jover writes: On Sat, 2008-01-26 at 23:11:32 +0100, Frank Lichtenheld wrote: On Sat, Jan 26, 2008 at 10:03:18PM +0100, Matthias Klose wrote: On Sat, 2008-01-26 at 20:59:15 +0100, Matthias Klose wrote: $ sudo dpkg -i /var/cache/apt/archives/dpkg_1.14.16.5_arm.deb (Reading database ... 31489 files and directories currently installed.) Preparing to replace dpkg 1.14.16.5 (using .../dpkg_1.14.16.5_arm.deb) ... Unpacking replacement dpkg ... rm: rm.c:371: main: Assertion `((status) == RM_OK || (status) == RM_USER_DECLINED || (status) == RM_ERROR)' failed. dpkg: error while cleaning up: subprocess rm cleanup killed by signal (Aborted) This assert is comin from the rm binary, and seems quite fishy. Is that system ok otherwise, fs, kernel, memory etc? yes, a thecus running armel, with an arm chroot. Can't reproduce this on my slug. It could be related to the OABI compat layer. Which kernel version are you guys using? linux-image-2.6.22-3-iop32x 2.6.22-6 Did you upgrade that recently? And would be possible to try with a non-EABI (normal arm) kernel, in case you have that chroot in a different partition, or maybe transfering it beforehand? Anyway, I don't think this is a problem related to dpkg in any way. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
Hi, On Mon, 2008-01-28 at 12:29:35 +, Colin Watson wrote: On Mon, Dec 31, 2007 at 02:37:48PM +, Colin Watson wrote: On Sun, Dec 30, 2007 at 10:28:12PM -0800, Russ Allbery wrote: Colin Watson [EMAIL PROTECTED] writes: I propose that policy should standardise that we move to using UTF-8 as the source encoding for all manual pages since it clearly makes sense to do so. [...] Right. Here's an update; I think I've captured most of the discussion in the thread so far. The following patch could in principle be applied now, given seconds. Wordsmithing welcome, as I'm aware that this is a rather dense recommendation; I'm also looking for seconds for this proposal. I'm also looking for at least one more second for this proposal. --- orig/policy.sgml +++ mod/policy.sgml @@ -8521,6 +8521,37 @@ be present in the future. /footnote /p + + p + Manual pages in locale-specific subdirectories of + file/usr/share/man/file should use either UTF-8 or the usual + legacy encoding for that language (normally the one corresponding + to the shortest relevant locale name in + file/usr/share/i18n/SUPPORTED/file). For example, pages under + file/usr/share/man/fr/file should use either UTF-8 or + ISO-8859-1.footnoteprgnman/prgn will automatically detect + whether UTF-8 is in use. In future, all manual pages will be + required to use UTF-8./footnote + /p + + p + A country name (e.g. filede_DE/file) should not be included in + the subdirectory name unless it indicates a significant difference + in the language, as this excludes speakers of the language in + other countries.footnoteAt the time of writing, Chinese and + Portuguese are the main languages with such differences, so + filept_BR/file, filezh_CN/file, and filezh_TW/file are + all allowed./footnote + /p + + p + Due to limitations in current implementations, all characters + in the manual page source should be representable in the usual + legacy encoding for that language, even if the file is + actually encoded in UTF-8. Safe alternative ways to write many + characters outside that range may be found in + manref name=groff_char section=7. + /p /sect Seconded. regards, guillem signature.asc Description: Digital signature
Bug#450817: qemu: Segmentation fault immediately after giving valid arguments
severity 450817 important thanks Hi, On Sun, 2007-11-11 at 20:21:53 +1100, Shaddy Baddah wrote: Package: qemu Version: 0.9.0+20070816-1 Severity: grave Justification: renders package unusable The package should work on X, just try without the -nographic argument. qemu is exiting with a Segmentation fault error immediately after passing it valid invokation arguments. Please find a cut and paste of the problem below: # qemu -m 128 -cdrom KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -boot d -nographic Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal error, but for better emulation accuracy either use a 2.6 host Linux kernel or type 'echo 1024 /proc/sys/dev/rtc/max-user-freq' as root. Segmentation fault Note, I have not as yet tried to invoke to display on an X display thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339870: Wrong Architecture for openhackware
tags 339870 wontfix thanks Hi, On Sat, 2008-01-12 at 18:47:53 +0100, Roland Stigge wrote: Debian Bug Tracking System wrote: * Error out if the toolchain used to build is not powerpc-linux-gnu. (Closes: #322300, #339870) Again, I don't agree here (backed by p2): The package is wrong if it asserts that it's Architecture: all. It contains powerpc specific stuff and can only be built on (i.e. for) that architecture. Therefore, it should be Architecture: powerpc. The only relevant part here is that it provides ppc binaries, the fact that it needs a ppc toolchain is not, I'd say, it's an arch:all package after all. Take vgabios as a similar example, it can be built anywhere (because it uses bcc and bin86), it's an arch:all package that provides i386 binaries, but yet it cannot be used on real i386 hardware, so making it arch:any would make it a bit useless, you could only use it under i386 to emulate i386 systems. Also those are firmwares, you will not be able to run them directly on your host system anyway, they either might need to be installed in a BIOS/PROM/whatever or used inside an emulator, so I don't think they are in the same situation as normal binaries. Yes, ideally, to be pedantically correct, we would either have powerpc (or other) cross-toolchains on the archive, or we'd have Multiarch support and the package could be arch:powerpc and would be possible to install on other arches. But this is not possible right now, so consider this wontfix. Other packages in a similar situation are proll, openbios-sparc, bochsbios and vgabios (there might be others). Workarounds like an error on wrong toolchain architecture are wrong (there is an error anyway if you try to build on !powerpc). That error is too late, and this one at least explains why it's failing. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451409: bochs: FTBFS on amd64
severity 451409 normal retitle 451409 bochs: binary-indep target FTBFS on non-i386 systems thanks Hi, On Thu, 2007-11-15 at 13:41:13 -0500, Daniel Schepler wrote: Package: bochs Version: 2.3+20070705-2 Severity: serious From my pbuilder build log: ... ld -o rombios32.out -T rombios32.ld rombios32start.o rombios32.o ld: i386:x86-64 architecture of input file `rombios32start.o' is incompatible with i386 output ld: i386:x86-64 architecture of input file `rombios32.o' is incompatible with i386 output make[1]: *** [rombios32.out] Error 1 make[1]: Leaving directory `/tmp/buildd/bochs-2.3+20070705/bios' make: *** [build-indep] Error 2 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 This is part of the binary independent target, which recently switched partially from bcc+bin86 to gcc+binutils to generate the new bios images. So now the arch:all packages have to be built on i386. I can add an error message in the rules file, so that it'd be easier to spot, but I'm not going to change the bochsbios package from arch:all to arch:i386. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451954: gettext: Package will not configure
Hi, On Mon, 2007-11-19 at 08:02:20 -0500, Avalith wrote: Package: gettext Version: 0.16.1-2 Severity: grave Justification: renders package unusable gettext will not configure because it claims to need access to /usr/share/info/dir when /usr/share/info is a file, so the directory cannot exist. How did you end up with /usr/share/info being a file? Did you create it? [EMAIL PROTECTED]:~$ sudo dpkg -r --force-remove-reinstreq gettext Password: (Reading database ... 96157 files and directories currently installed.) Removing gettext ... install-info(/usr/share/info/gettext.info): no file /usr/share/info/dir, retrieving backup file /var/backups/infodir.bak. cp: accessing `/usr/share/info/dir': Not a directory install-info(/usr/share/info/gettext.info): copying /var/backups/infodir.bak to /usr/share/info/dir failed, giving up: Not a directory dpkg: error processing gettext (--remove): subprocess pre-removal script returned error exit status 1 install-info(/usr/share/info/gettext.info): dpkg: error while cleaning up: subprocess post-installation script returned error exit status 20 Errors were encountered while processing: gettext regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453871: ocp: Please enable ALSA support
Source: ocp Source-Version: 1:0.1.14-1 Severity: wishlist Please add 'libasound2-dev' to Build-Depends on linux systems to enable the ALSA driver. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453875: opencubicplayer: missplaced doc files
Package: opencubicplayer Version: 1:0.1.14-1 Severity: minor Hi, This package contains documentation files under /usr/share/ocp/, which are duplicates of the ones under /usr/share/doc/opencubicplayer/. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453877: opencubicplayer: up key does not go to previous link in hypertext help
Package: opencubicplayer Version: 1:0.1.14-1 Hi, When inside the hypertext help window (either under X or console), the up key does not go back to the previous link, the down key works fine. It's quite annoying trying to navigate this way. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454057: please move dpkg-architecture
Hi, On Wed, 2007-12-05 at 20:02:34 +0100, Aurelien Jarno wrote: Raphael Hertzog a écrit : On Wed, 05 Dec 2007, Julien Cristau wrote: Maybe type-handling could be split with an empty package whose sole purpose is to Provides some virtual packages while type-handling stays the program with its dpkg-dev dependency. I think this solution would be my first preference. I've been meaning to discuss this with the XSF but at some point forgot about it. I'd really like if you guys could switch that package to arch:any (reasons given below). My preference would be for dpkg to allow 'Depends: foo [arch]' in arch:all packages, but failing that, I agree. Right now the support for the [arch] syntax is only in the perl code and not at all in the C part that concerns dpkg. Adding it there is a non-trivial effort and would probably also require changes in apt-based software. The '[arch]' is supported in the perl code but the dependencies are reduced at package build time. The C code is not the problem with this solution (implementing this is not that difficult, although the arch wildcard support would have to be reimplemented in C), the main problem is breaking all programs around that might be parsing the dependency fields, like sbuild, pbuilder, apt-based, etc. Aurélien, what do you think of the idea of change concerning type-handling ? From my point of view, we should get rid of type-handling as soon as possible. This is actually a big and buggy hack to workaround dpkg/apt lacks. Agreed, and that was our main goal when we (although it has been Aurélien who has done all the work) took over that package. Part of the failure is probably on me for not having pushed enough for the arch wildcards... The first think I would like to see, is [os] or [cpu] support in dpkg-dev *enabled* and *allowed* for arch-any packages. This would replace type-handling in 90% of the cases. I suppose you mean the arch wildcards like '[os-any]' and '[any-cpu]', this has been supported since latest part of the etch release which is the most annoying part type-handling is working around and that's the reason it got added then, to be able to easily get rid of type-handling. The only reason we cannnot use it now is sbuild, I sent a mail to Ryan some time ago but he didn't reply. For the [arch] support in binary-all packages, I guess the main use case (if not all) is for metapackages depending on various packages. I don't really see the problem (except the policy, but that can be changed) of using binary-any packages for those metapackages, even if there is no binary files insude them. They are by definition very small, so that won't bloat the archive. I agree. There's probably really few cases where an arch:all needs to Depend on a package only present in a specific architecture. I'm not sure it's worth the effort, also ideally we should have less arch specific packages. If there are still some cases not solved by this approach, I guess the package that should provide the not+sparc package is dpkg. It is always installed on systems, so strange behaviours of apt with virtual packages is avoided. Right, but I'm a bit uneasy on this solution of abusing the dependencies for that purpose. I'll be closing this bug report and the one on type-handling about splitting the package in few days. regards, guillem
Bug#454689: packages.debian.org: Switch from gnuab.org to debian-ports.org
Package: www.debian.org
Severity: normal
Hi,
Last weekend [0] the main server for the kfreebsd-* and armel ports
was switched from gnuab.org to debian-ports.org. The new server should
behave better on the hardware and connectivity fronts.
Attached is a patch against latest git master. I've not tested it so
please review. Initially I called the repo 'ports' but changed to
'debports' to avoid confusion with the www.debian.org/ports stuff.
regards,
guillem
[0] http://lists.debian.org/debian-arm/2007/12/msg4.html
From 86fd531c1d808ee46b6f7d8512c629ab64d1d4f9 Mon Sep 17 00:00:00 2001
From: Guillem Jover [EMAIL PROTECTED]
Date: Fri, 7 Dec 2007 05:30:31 +0200
Subject: [PATCH] Switch from gnuab.org to debian-ports.org
---
README |3 ++-
bin/parse-packages |4 ++--
config.sh.sed.in |4 ++--
cron.d/100syncarchive_debports | 33 +
cron.d/100syncarchive_gnuab| 33 -
templates/config/mirrors.tmpl | 14 +++---
6 files changed, 46 insertions(+), 45 deletions(-)
create mode 100755 cron.d/100syncarchive_debports
delete mode 100755 cron.d/100syncarchive_gnuab
diff --git a/README b/README
index f55856e..5d7067b 100644
--- a/README
+++ b/README
@@ -45,7 +45,8 @@ Cron
100syncarchive -- retrieve data from main Debian archive
100syncarchive_amd64 -- retrieve data from sarge amd64 archive
100syncarchive_backports -- retrieve data from backports.org
-100syncarchive_gnuab -- retrieve data from gnuab (kfreebsd-*, armel)
+100syncarchive_debports-- retrieve data from debian-ports.org
+ (kfreebsd-*, armel)
100syncarchive_installer -- retrieve d-i data
100syncarchive_m68k-- retrieve data for etch-m68k
100syncarchive_maintainers -- retrieve maintainer index
diff --git a/bin/parse-packages b/bin/parse-packages
index 61d6b84..2e713c6 100755
--- a/bin/parse-packages
+++ b/bin/parse-packages
@@ -87,9 +87,9 @@ for my $suite (@SUITES) {
}
# Skip double package
next if exists($packages_all_db{$data{'package'} $data{'architecture'} $data{'version'}});
- # Skip arch:all for amd64 gnuab, any non-redundancy is
+ # Skip arch:all for amd64 debports, any non-redundancy is
# usually a bug anyway
- next if ($archive eq 'amd64' or $archive eq 'gnuab')
+ next if ($archive eq 'amd64' or $archive eq 'debports')
and $data{architecture} eq 'all';
if ($data{'provides'}) {
diff --git a/config.sh.sed.in b/config.sh.sed.in
index 7481446..9a95654 100644
--- a/config.sh.sed.in
+++ b/config.sh.sed.in
@@ -29,7 +29,7 @@ security_ftpsite=http://security.debian.org/debian-security
volatile_ftpsite=http://volatile.debian.org/debian-volatile
backports_ftpsite=http://backports.org/debian
amd64_ftpsite=http://amd64.debian.net/debian
-gnuab_ftpsite=http://kfreebsd-gnu.debian.net/debian
+debports_ftpsite=http://ftp.debian-ports.org/debian
ddtp_ftpsite=http://ddtp.debian.net/debian
root=
@@ -38,7 +38,7 @@ root=
#
polangs=de fi fr hu ja nl ru sv uk zh-cn
ddtplangs=ca cs da de eo es fi fr hu it ja km-kh ko nl pl pt pt-br ru sk sv uk zh-cn zh-tw
-archives=us security amd64 gnuab backports volatile
+archives=us security amd64 debports backports volatile
sections=main contrib non-free
parts=$sections
suites=sarge sarge-volatile sarge-backports etch etch-m68k etch-volatile etch-backports lenny sid experimental
diff --git a/cron.d/100syncarchive_debports b/cron.d/100syncarchive_debports
new file mode 100755
index 000..897d1dd
--- /dev/null
+++ b/cron.d/100syncarchive_debports
@@ -0,0 +1,33 @@
+#! /bin/bash
+
+. `dirname $0`/../config.sh
+
+test -d ${archivedir} || mkdir -p ${archivedir}
+cd ${archivedir}
+
+# Main archive
+#
+architectures=armel kfreebsd-i386 kfreebsd-amd64
+
+for dist in sid experimental
+ do
+ echo retrieve Release(.gpg) $dist
+ test -d debports/${dist} || mkdir -p debports/${dist}
+ (cd debports/${dist}
+ wget -q -N ${debports_ftpsite}/dists/${dist}/Release
+ wget -q -N ${debports_ftpsite}/dists/${dist}/Release.gpg )
+
+ for arch in $architectures
+do
+for part in ${parts} main/debian-installer
+ do
+ echo retrieve Packages $dist/$part/$arch
+ test -d debports/${dist}/${part}/binary-${arch} || mkdir -p debports/${dist}/${part}/binary-${arch}
+ (cd debports/${dist}/${part}/binary-${arch}
+ wget -q -N ${debports_ftpsite}/dists/${dist}/${part}/binary-${arch}/Packages.gz)
+done
+echo retrieve Contents $dist/$arch
+(cd debports/${dist}
+ wget -q -N ${debports_ftpsite}/dists/${dist}/Contents-${arch}.gz)
+ done
+done
diff --git a/cron.d/100syncarchive_gnuab b/cron.d/100syncarchive_gnuab
deleted file mode 100755
index b42d165..000
--- a/cron.d/100syncarchive_gnuab
+++ /dev/null
@@ -1,33 +0,0 @@
-#! /bin/bash
-
-. `dirname $0`/../config.sh
-
-test -d ${archivedir} || mkdir -p ${archivedir}
-cd ${archivedir}
-
-# Main archive
Bug#451478: openbsd-inetd instead of inetutils-inetd = fix
severity 451478 wishlist
thanks
Hi,
On Fri, 2007-11-23 at 09:52:59 +0100, Steffen Grunewald wrote:
Some additional information:
the nowait.${number} expression, with inetutils-inetd, results in
a syslog line
/etc/inetd.conf:25: bad wait type
Replacing inetutils-inetd with openbsd-inetd, and reloading //etc/inetd.conf,
seems to fix the message (and perhaps the issue which I have never seen
with Sarge which uses netkit-inetd 0.10-10)
This is not supported by inetutils-inetd at all. I'll take a look at
adding this, but I'm a bit busy right now.
regards,
guillem
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453267: tested patch
Hi, [ I don't have a real opinion yet on the initial patch and this changes proposed, will try to get to this on Sunday. ] On Sat, 2007-12-08 at 19:01:14 +, Neil Williams wrote: Raphael Hertzog wrote: On Wed, 05 Dec 2007, Neil Williams wrote: My first patch did exactly that - and failed on building a cross compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the preparation of libgcc1-$arch-cross and other libraries used in the complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE at other stages of the build. If that's the case, I'd like to know if this is deliberate and really required... can't the gcc package be consistent and always have both DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ? Even if gcc changes that behaviour in 4.2 (or 4.3), lots of people still need to be able to build cross compilers from older versions of gcc, especially 4.1 and some even need 3.3 or 3.4. Why can't 4.1 and 3.4 be fixed (if that's really needed) as well? 3.3 might be a problem, but even then you have to build them locally to support cross-compiling, why can't they be patched locally as well? regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454689: packages.debian.org: Switch from gnuab.org to debian-ports.org
Hi, On Fri, 2007-12-07 at 16:01:39 +0100, Frank Lichtenheld wrote: Some small comments, but none that require a resending of the patch. Will try applying this at the weekend. cron.d/100syncarchive_debports | 33 + cron.d/100syncarchive_gnuab| 33 - git format-patch -M would probably have formatted that nicer. (doesn't change anything for applying though, only for review) Hmm was annoyed by that but completely forgot about that option. Will remember for next time. europa = [ - # master site, aka ftp.gnuab.org - kfreebsd-gnu.debian.net/debian, + ftp.debian-ports/debian, .org missing here I presume? Ooops. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454944: directfb: FTBFS: conflicting types for 's64'
Hi, On Sat, 2007-12-08 at 14:12:26 +0100, Kurt Roeckx wrote: Package: directfb Version: 1.0.1-3 Severity: serious Your package is failing to build (on amd64) with the following error: In file included from /usr/include/asm/types.h:5, from /usr/include/asm-x86_64/sigcontext.h:4, from /usr/include/asm/sigcontext.h:5, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:333, from /usr/include/sys/signal.h:1, from ../../../lib/direct/conf.h:36, from ../../../lib/direct/debug.h:37, from ../../../lib/direct/clock.c:35: /usr/include/asm-x86_64/types.h:22: error: conflicting types for 's64' ../../../include/dfb_types.h:59: error: previous declaration of 's64' was here /usr/include/asm-x86_64/types.h:23: error: conflicting types for 'u64' ../../../include/dfb_types.h:54: error: previous declaration of 'u64' was here make[4]: *** [clock.lo] Error 1 Hmm it seems directfb is defining compat macros from __type to type. I'll disable them for next upload. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304983: Bug #304983 - Provide static library
Hi, On Sat, May 28, 2005 at 04:17:28PM +0200, [EMAIL PROTECTED] wrote: Splashy is a replacment in user land for the kernel graphic boot embellishments. We use directfb though an issue arises : directfb is in /usr which some user have in a separate partition not available until half the boot is done. Thus the need for a full static build of directfb . Nice! Please give us your point of view : would you include the static build in your packages or should we ship with our own build of them ? I wanted to upload a newer release to experimental this weekend and when I tried to enable the static build it broke so I just decided to upload and incrementally fix the package. At least now 0.9.22 is packaged. I'll include static libs on next upload, most probably. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293426: viewcvs: split log info from file content so it can be distinguished
Package: viewcvs Version: 0.9.2+cvs.1.0.dev.2004.07.28-1.4 Severity: wishlist Tags: patch Hi, This trivial patch inserts a line so the log info and the file content are separated and thus cannot be confused. regards, guillem diff -Naur viewcvs-0.9.2+cvs.1.0.dev.2004.07.28.orig/templates/markup.ezt viewcvs-0.9.2+cvs.1.0.dev.2004.07.28/templates/markup.ezt --- viewcvs-0.9.2+cvs.1.0.dev.2004.07.28.orig/templates/markup.ezt 2004-07-19 10:49:39.0 +0200 +++ viewcvs-0.9.2+cvs.1.0.dev.2004.07.28/templates/markup.ezt 2005-02-03 09:49:01.0 +0100 @@ -47,6 +47,8 @@ [end] /div +hr noshade + [markup] [include include/footer.ezt]
Bug#293950: typo error for natsemi driver in debian/rules
tags 293950 pending thanks Hi, On Mon, Feb 07, 2005 at 12:40:27AM +, Regis Boudin wrote: Package: gnumach Version: 20040915.dfsg.1-1 I installed a Hurd system yesterday on my laptop, and everything went smoothly appart from a lack of support for my ethernet card, based on a natsemi controller. It comes from a typo error in the debian/rules file. Line 72 contains --enable-natsami, which needs to be replaced by --enable-natsemi. I tried the modification locally and the support was present. The fix is now ont the subversion repo, will be in next upload. Thanks for the report! regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294320: xfree86: fsListFontsWithXInfo lacks sanity check for FS_Error
Package: xfree86
Version: 4.3.0.dfsg.1-10+SVN
Severity: important
Tags: patch
Hi,
This patch fixes an X server segfault when a font server returns a
FS_Error for a fsListFontsWithXInfo request.
This is the case of xfstt, that currently returns a FS_Error for this
request.
This can be tested easily by installing xfstt and then running
xlsfonts -l.
Patch tested and attached.
regards,
guillem
diff -Naurp xc.orig/lib/font/fc/fserve.c xc/lib/font/fc/fserve.c
--- xc.orig/lib/font/fc/fserve.c2005-02-02 08:03:13.0 +0100
+++ xc/lib/font/fc/fserve.c 2005-02-02 08:28:14.0 +0100
@@ -2332,7 +2332,7 @@ fs_read_list_info(FontPathElementPtr fpe
_fs_free_props (binfo-info);
rep = (fsListFontsWithXInfoReply *) fs_get_reply (conn, ret);
-if (rep == 0)
+if (!rep || rep-type == FS_Error)
{
if (ret == FSIO_BLOCK)
return StillWorking;
Bug#269563: Re: FTBFS on kfreebsd-gnu
Hi, On Thu, Sep 02, 2004 at 09:54:19AM +0200, Robert Millan wrote: Package: gtkgl2 Severity: wishlist Tags: patch This package attempts to link C programs with C++ library using gcc instead of g++, and fails to build on kfreebsd-gnu. No, that's wrong. The program is correct C, and does not directly use any C++ constructs, the problem comes from libGLU lacking a dynamic dependency on libstdc++ on the GNU/Hurd and GNU/kFreeBSD, at least the one coming from XFree86. So you can close this bug report. Patch attached, please could you forward it upstream? Please don't. reagrds, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#269294: FTBFS on hurd - same problem as on kfreebsd-gnu
Hi, On Sat, Dec 25, 2004 at 02:47:41AM +0100, Robert Millan wrote: I found Adding empty.cc is a gruik gruik solution. Consider the following patch instead : [...] - CFLAGS=$(CFLAGS) ./configure \ + CFLAGS=$(CFLAGS) LDFLAGS=-lstdc++ ./configure \ No, that's wrong. No, both patches are wrong. There's really no bug on freeglut. First of all, because linking with libstdc++ doesn't ever garantee that C++ code will be buildable. But freeglut does not have any C++ code. And second, because this is an upstream bug, and working around it in debian/rules is not the best solution. No. The real problem here is that libGLU is buggy on GNU/Hurd and GNU/kFreeBSD and does not link against libstdc++. Fix that instead of applications/libs that link against it. Btw, Jamie, are you going to address this bug soon? Please don't. You can close the bug report instead. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
