Bug#389806: moodle: fails to install
Package: moodle Version: 1.6.2-1 Severity: serious Hello Isaac, There is an error when attempting to install moodle: Setting up moodle (1.6.2-1) ... Creating config file /etc/moodle/config.php with new version ln: creating symbolic link `/etc/apache/conf.d/moodle' to `/etc/moodle/apache.conf': No such file or directory dpkg: error processing moodle (--configure): subprocess post-installation script returned error exit status 1 Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389768: quagga: removing the package fails
On Wed, Sep 27, 2006 at 09:43:08PM +0200, Christian Hammers wrote: Not stopping the daemon does not imply failing to remove the package. Do you think that users expect Debian to be able to remove the package and thus the daemon's binary and maybe config files while it is still running? :) We are more or less doing that every time we upgrade a live box. Technically this would be a very bad idea at least :) Probably but you can remove openssh-server without breaking your ssh connection. Let's say I am spoiled. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389806: moodle: fails to install
On Wed, Sep 27, 2006 at 09:50:17PM +0100, Isaac Clerencia wrote:
On Wednesday, 27 September 2006 21:07, Bill Allombert wrote:
Package: moodle
Version: 1.6.2-1
Severity: serious
Hello Isaac,
There is an error when attempting to install moodle:
Setting up moodle (1.6.2-1) ...
Creating config file /etc/moodle/config.php with new version
ln: creating symbolic link `/etc/apache/conf.d/moodle' to
`/etc/moodle/apache.conf': No such file or directory dpkg: error processing
moodle (--configure):
subprocess post-installation script returned error exit status 1
Did you get the debconf dialog to ask you which server do you wanted to
configure?
It was non-interactive install, so no.
Did you choose apache 1? Do you have apache installed?
Neither. The offending code is there:
if [ ! -e /etc/${webserver}/conf.d/moodle ]
then
ln -s /etc/moodle/apache.conf /etc/${webserver}/conf.d/moodle
fi
Either check /etc/${webserver}/conf.d/ exist or mkdir it.
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389934: libg20-perl: include unsafe rpath to /build/buildd
Package: libg20-perl Version: 0.70-1.2 Severity: grave Tags: security Hello Eric, The file /usr/lib/perl5/auto/G2/G2.so include a rpath pointing to /build/buildd/g2-0.70/g2_perl/.. which is not a FHS approved location. % chrpath /usr/lib/perl5/auto/G2/G2.so /usr/lib/perl5/auto/G2/G2.so: RPATH=/build/buildd/g2-0.70/g2_perl/.. On some system, a user could have write access to /build and thus be able to set up a rogue library in that location that will get loaded by users of libg20-perl. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389806: moodle: fails to install
On Wed, Sep 27, 2006 at 03:18:51PM -0700, Steve Langasek wrote:
On Wed, Sep 27, 2006 at 11:02:32PM +0200, Bill Allombert wrote:
On Wed, Sep 27, 2006 at 09:50:17PM +0100, Isaac Clerencia wrote:
On Wednesday, 27 September 2006 21:07, Bill Allombert wrote:
Package: moodle
Version: 1.6.2-1
Severity: serious
Hello Isaac,
There is an error when attempting to install moodle:
Setting up moodle (1.6.2-1) ...
Creating config file /etc/moodle/config.php with new version
ln: creating symbolic link `/etc/apache/conf.d/moodle' to
`/etc/moodle/apache.conf': No such file or directory dpkg: error
processing
moodle (--configure):
subprocess post-installation script returned error exit status 1
Did you get the debconf dialog to ask you which server do you wanted to
configure?
It was non-interactive install, so no.
Priorities
[...]
high Questions that don't have a reasonable default.
debconf(7)
There is no release requirement that a package be installable when
high-priority debconf questions are skipped.
What if the question, while being priority high, does have a reasonable
default ? Gratuituous high-priority questions is a major issue for any
attempt to perform test upgrade between release.
Since there can be only one webserver installed, there is a reasonable default:
the webserver which is installed.
Did you choose apache 1? Do you have apache installed?
Neither. The offending code is there:
if [ ! -e /etc/${webserver}/conf.d/moodle ]
then
ln -s /etc/moodle/apache.conf /etc/${webserver}/conf.d/moodle
fi
Either check /etc/${webserver}/conf.d/ exist or mkdir it.
That would still result in an unusable package if the webserver chosen in
the debconf interface is not the one actually installed; so there's no
In that case the debconf question should be replaced by a script that
check what httpd is installed. There is no point asking trick questions
to the user.
reason that mkdir (postponing the failure) is inherently preferable to an
immediate failure in the maintainer script.
The user do not know they need to install a webserver prior
seeing the debconf question, so they should be given a chance to
complete the install and then install the webserver they specified,
else the debconf question is useless. Alternatively, if you assume the
user will not actually install the webserver he specified, then the
debconf question is still useless.
If you really have to fail if the webserver is not configured before the
package you should at least give a clear notice explaining the situation
and how to fix it, not just
ln: creating symbolic link `/etc/apache/conf.d/moodle' to
`/etc/moodle/apache.conf': No such file or directory dpkg: error
processing
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389968: mailscanner: purging the package fails (ucf unavailable)
Package: mailscanner Version: 4.51.5-1 Severity: serious Hello Matthias, There is an error when attempting to purge mailscanner: Removing mailscanner ... Purging configuration files for mailscanner ... /var/lib/dpkg/info/mailscanner.postrm: line 19: ucf: command not found dpkg: error processing mailscanner (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389969: hinfo: purging the package fails (ucf unavailable)
Package: hinfo Version: 1.02-2 Severity: serious Hello Blars, There is an error when attempting to purge hinfo: Removing hinfo ... Purging configuration files for hinfo ... /var/lib/dpkg/info/hinfo.postrm: line 28: ucf: command not found dpkg: error processing hinfo (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389967: bandwidthd: purging the package fails (ucf unavailable)
Package: bandwidthd Version: 2.0.1+cvs20050208-6 Severity: serious Hello Andreas, There is an error when attempting to purge bandwidthd: Removing bandwidthd ... Purging configuration files for bandwidthd ... /var/lib/dpkg/info/bandwidthd.postrm: line 11: ucf: command not found dpkg: error processing bandwidthd (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389962: noffle: purging the package fails (update-inetd unavailable)
Package: noffle Version: 1.1.5-9 Severity: serious Hello Martin, There is an error when attempting to purge noffle: Removing noffle ... Purging configuration files for noffle ... /var/lib/dpkg/info/noffle.postrm: line 12: update-inetd: command not found dpkg: error processing noffle (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on update-inetd to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389965: libapache-mod-ngobjweb: purging the package fails (ucf unavailable)
Package: libapache-mod-ngobjweb Version: 4.4rc.2-3 Severity: serious Hello Sebastian, There is an error when attempting to purge libapache-mod-ngobjweb: Removing libapache-mod-ngobjweb ... Purging configuration files for libapache-mod-ngobjweb ... /var/lib/dpkg/info/libapache-mod-ngobjweb.postrm: line 12: ucf: command not found dpkg: error processing libapache-mod-ngobjweb (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389966: vm: purging the package fails (ucf unavailable)
Package: vm Version: 7.19-10 Severity: serious Hello Manoj, There is an error when attempting to purge vm: Removing vm ... Purging configuration files for vm ... /var/lib/dpkg/info/vm.postrm: line 132: ucf: command not found dpkg: error processing vm (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389972: bcfg2: purging the package fails (ucf unavailable)
Package: bcfg2 Version: 0.8.3-1 Severity: serious Hello Sami, There is an error when attempting to purge bcfg2: Removing bcfg2 ... Purging configuration files for bcfg2 ... /var/lib/dpkg/info/bcfg2.postrm: line 24: ucf: command not found dpkg: error processing bcfg2 (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389806: moodle: fails to install
On Thu, Sep 28, 2006 at 05:12:44PM +0100, Isaac Clerencia wrote: If you really have to fail if the webserver is not configured before the package you should at least give a clear notice explaining the situation and how to fix it, not just ln: creating symbolic link `/etc/apache/conf.d/moodle' to `/etc/moodle/apache.conf': No such file or directory dpkg: error processing Yeah, I agree on this. Thanks and sorry for the previous mail. I have done so many failed upgrade that my head spins. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389979: pdns-server: purging the package fails (ucf and adduser unavailable)
Package: pdns-server Version: 2.9.20-5 Severity: serious Hello Debian PowerDNS Maintainers, There is an error when attempting to purge pdns-server: Removing pdns-server ... Purging configuration files for pdns-server ... /var/lib/dpkg/info/pdns-server.postrm: line 25: deluser: command not found /var/lib/dpkg/info/pdns-server.postrm: line 36: ucf: command not found dpkg: error processing pdns-server (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf and adduser to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389736: jffnms: fails to install
On Thu, Sep 28, 2006 at 09:32:37AM +1000, Craig Small wrote: On Wed, Sep 27, 2006 at 02:35:13PM +0200, Bill Allombert wrote: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) You've asked it to install the database. You have your debconf settings so it uses the default database location. You either do not have mysql running or it is not listening on the socket. So its not going to work! Either reconfigure it with a lower priority, start your database or don't say yes when it asks you if you want dbconfig to configure it. It's just doing what you asked it to do. You are right I got completly confused... Sorry for the trouble, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389973: nagios2-common: purging the package fails (ucf unavailable)
Package: nagios2-common Version: 2.5-1 Severity: serious Hello Debian Nagios Maintainer Group, There is an error when attempting to purge nagios2-common: Removing nagios2-common ... Purging configuration files for nagios2-common ... No override present. No override present. No override present. No override present. No override present. No override present. /var/lib/dpkg/info/nagios2-common.postrm: line 22: ucf: command not found dpkg: error processing nagios2-common (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389977: gnus: purging the package fails (ucf unavailable)
Package: gnus Version: 5.11+v0.5.dfsg-2 Severity: serious Hello James, There is an error when attempting to purge gnus: Removing gnus ... Purging configuration files for gnus ... /var/lib/dpkg/info/gnus.postrm: line 14: ucf: command not found dpkg: error processing gnus (--purge): subprocess post-removal script returned error exit status 127 The postrm script cannot rely on ucf to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390019: gtalk: purging the package fails (update-inetd unavailable)
Package: gtalk Version: 0.99.10-10.1 Severity: serious Hello Christoph, There is an error when attempting to purge gtalk: Removing gtalk ... Purging configuration files for gtalk ... /var/lib/dpkg/info/gtalk.postrm: line 22: update-inetd: command not found dpkg: error processing gtalk (--purge): subprocess post-removal script returned error exit status 127 Errors were encountered while processing: gtalk The postrm script cannot rely on update-inetd to be available when purging. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389932: Help with menu (Was: Bug#389932: wish: gnumed --debug should open terminal window)
On Thu, Sep 28, 2006 at 04:37:58PM +0200, Alexander Schmehl wrote: Hi! * Andreas Tille [EMAIL PROTECTED] [060928 16:09]: is there any relieable way to force opening a terminal from a menu entry and call a programm from this terminal to make sure that console output will be visible? I never succeeded to find this out. :-( Regarding Debians menu system: Yes, there is. According to file:///usr/share/doc/menu/html/ch3.html#s3.4 (from package menu) you just need to needs-field to the value text. Don't do that! that will break text mode menu managers like pdmenu. needs=x11 command=x-terminal-emulator -e foo should do the trick. Maybe Andreas is looking for xterm -hold ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389934: severity of 389934 is important
severity 389934 serious thanks On Sun, Nov 26, 2006 at 04:24:22AM -080O0, Steve Langasek wrote: Hi Bill, So my own opinion is that this class of bug should not be RC, at least when the embedded rpath doesn't lie in an obviously user-writable space such as /home or /tmp. If you feel strongly that these should be RC, please go ahead and re-upgrade them. But you may also want to look at [EMAIL PROTECTED], posted to debian-release by a member of the security team. Hello Steve, Thanks for the pointer. There is a difference though, between updating a stable release and fixing a new stable release. It seems to me that the security team is unwilling to fix the issue because it is too much work for little benefit for them and require to modify the package build system which is always something fragile that should not be done for stable update. However, the best course of action is to fix these bugs for Etch so that the release team does not have to make such compromise between stability and security. It is possible to achieve that thanks to lintian and indeed I have reported all such bugs already. If we do not fix them, we run the risk that a future upload of the packages introduce rpath pointing to more problematic locations and go unnoticed. Some of such bugs depends whether the package is installed when building itself. This might point to a larger problem with the packages that might link with the wrong version of libraries. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374834: menu: Patch to just fork and die, instead of waiting on a si
On Mon, Nov 20, 2006 at 02:15:20PM +0100, Tim Dijkstra (tdykstra) wrote: Package: menu Version: Patch to just fork and die, instead of waiting on a signal Followup-For: Bug #374834 Hi, I prepared a patch that removes the singal business. The logic used to be: - Parent forks, stays waiting for a signal to die, blocking dpkg. - child would see if it really needs to exist. Create the string for a stdout file. Tell the user, then tell the parent to die. Waits for dpkg to finish. Now: - Parent checks if fork is really needed. Forks. Creates string for stdout file, tells user about it. Dies. - Child waits for dpkg to finish. Would be nice if you could try to get this into etch (if indeed this looks harmless to you). Maybe Mario can check that it works for him too. Hello Tim, The issue is that this patch cause a regression in behaviour, by re-adding the race condition the signal code was added to prevent. The bug is much probably in the C library. It would really help if we had a test-case and know which kind of system are affected. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389934: severity of 389934 is important
On Mon, Nov 27, 2006 at 08:42:17AM +0100, Andreas Barth wrote: severity 389934 important thanks I upgraded the severity with permission from Steve. * Bill Allombert ([EMAIL PROTECTED]) [061126 07:27]: However, the best course of action is to fix these bugs for Etch so that the release team does not have to make such compromise between stability and security. It is possible to achieve that thanks to lintian and indeed I have reported all such bugs already. I fully agree to this statement. However, looking at the release policy I don't see how this bug is RC (though I really wish the bugs to disappear). Removal of all rpaths seem to be a typical release goal, and please feel free to attack them in future as such (i.e. severity important, 0-days-NMU policy applies). I reported the bugs in March, then again in September. Unfortunatey new rpath got added in between. This one bug was reported two month ago, not today. As far as I am concerned, this is not a release goal, just basic sanity of the distribution, much like checking packages actually build from source. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313020: LFS support broken
On Sat, Nov 18, 2006 at 01:01:18AM +0100, Eduard Bloch wrote: I could not find it here, and even if I could I doubt they would be easily applicable. Instead, I took the current version in sid and modified it again. The attached version is almost okay any still have some little glitches: - it was not tested on real data, only sparse file to /dev/null transfer - detection of LFS support is not added, I hardcoded good values into config.h.in - I have used off_t as the main type everywhere. On some places even for unsigned int where it looked like it would not hurt at the first glance Hello Eduard, It seems the ranges are still 32bit only with your patch. This causes some gcc warnings. I plan to upload a NMU without you patch applied because I don't trust myself to deal with the LFS stuff correctly, and the time for Etch is short. Sorry about that. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: I second this proposal
On Tue, Nov 28, 2006 at 10:27:46PM +0100, Moritz Muehlenhoff wrote: I second Neil's proposal. Which precise proposal ? Which wording ? There are several of them in the bug log. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398879: Change in package architectures list.
On Mon, Dec 04, 2006 at 07:46:55PM -0800, Rob Browning wrote: In the latest upload of stalin (a new version), I removed arm and m68k from the architecture list. However, I wanted to double-check and make sure that was appropriate. I believe compiling stalin with gcc now requires a bit over 1GB. i.e. gcc's VSS grows to a bit over 1GB. Ignoring any other concerns, it didn't look like the arm and m68k buildds would be likely to handle that very well. However, if the buildd admins are willing to make sure that the buildds have perhaps 1.5GB total (swap included) and are willing to let the build run long enough to finish, then it should be possible to restore m68k and arm support. It could be possible to build the package under aranym and/or distcc: If cc1 need 1Gb of RAM, setup distcc to a host with at least 1Gb of RAM. If ld need 1Gb of RAM, setup aranym with at least 1Gb of RAM. For arm qemu-system-arm might do the trick. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: dpkg-buildpackage: support for Build-Options: build-arch
Hello DPKG developers, I am attempting to fix a long standing issue in Debian, which is fully documented in bug #218893, namely the fact that dpkg-buildpackage will call 'debian/rules build' even when called with -B, thus making Build-Depends-Indep nearly useless. For the exact issue please read #218893. The patch in the bug #229357 implement the fourth proposal. One problem that plagued the resolution of this bug was the conflicting opinions of the various dpkg maintainers about how to fix this issue. So I would be very grateful f you could take a decision and implement it. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349064: ITP: flash-plugin -- installer for Macromedia Flash Plugin
On Fri, Jan 20, 2006 at 09:00:52PM +0100, Bart Martens wrote: The Debian package flash-plugin is meant as an alternative or as a replacement for flashplugin-nonfree. Similarities: Both Debian packages are GPL, and download the .tar.gz from the Macromedia website to comply to the Macromedia license. Some differences: - less bugs :-) - simple scripting in preinst and postinst, no ruby Well, but flashplugin-nonfree at least make the users feel how painful nonfree software are to deal with. Quite a usefule feature if you ask me! More seriously there are at least two free attempts at a flash-plugin, gnash and swfdec, so it might better to keep the name flash-plugin as a virtual package name. Maybe macromedia-flash-installer ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349238: circular dependency with libwww-perl
Package: libhtml-tree-perl Version: 3.19.01-1 Severity: important Hello Debian Catalyst maintainers, libhtml-tree-perl has a circular dependency with libwww-perl: Package: libhtml-tree-perl Depends: libwww-perl Package: libwww-perl Depends: libhtml-tree-perl (= 3.11) This particular circular dependency is known to have caused trouble during the sarge to etch update, see bug #310490 for detail, so we should strive to remove it for Etch. For example, it should be possible to merge libhtml-tree-perl and libwww-perl. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349248: circular dependency with libglu1-mesa
Package: mesag3 Version: 6.3.2-2 Severity: important Hello Debian MESA maintainers, There is a circular dependencies between mesag3 and libglu1-mesa: Package: mesag3 Depends: libglu1-mesa | libglu1 Package: libglu1-mesa Depends: mesag3 | libgl1 Circular dependencies between shared libraries are known to cause trouble during installation, upgrade and testing propagation so we should try to avoid them. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349271: popularity-contest: shell option errors
On Sat, Jan 21, 2006 at 04:25:31PM -0600, Ron Johnson wrote: On 14-Jan, cron.weekly started sending me emails with this in them: The issue is that 'su' has changed its syntax and /etc/cron.weekly/popularity-contest used su with the old syntax, so technically this is a bug in su. Please upgrade popularity-contest to 1.32, which should fix this issue. Thanks for using popularity-contest! Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502199: xteddy menu: please put entries back in Games/Toys/Teddies
Package: xteddy Version: 2.1-2 Severity: normal Hello Andreas, Please move back xteddy menu entries to Games/Toys/Teddies, as they were in Etch. This avoid missing xteddy entries with other entries in Games/Toys. Menu includes translations of Teddies specifically for that purpose. The menu policy does not mention Teddies because this subsection is specific to the xteddy package, and should not be used by other packages. Packages are allowed to create a subsection if they follow the same placement rules than entries (i.e. only in leaf subsections of policy), provides at least three entries in the subsection and are registered with the menu maintainer (so menu can provide translations). I would be very glad if it was fixed for Lenny. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502192: menu-xdg: invents own icon names instead of using existing
On Tue, Oct 14, 2008 at 01:06:39PM +0200, Sune Vuorela wrote: Package: menu-xdg Version: 0.3 Severity: normal Hello Sune, Apparantly, menu-xdg invents own icon names instead of using something existing. This makes at least KDE4 to just use folder icon for the folders/submenus. This is done on purpose. This allow desktop envirnonment to use separate icons for debian menu entries and other entries. Changing the names would break GNOME and KDE3. Furthermore there is no one-to-one mapping between debian sections and other sections, so the proposal is not feasible. for example, the debian-games.directory should reference Icon=applications-games and not Icon=debian-games Standardizing on the xdg icon spec is probably good. Table 5. Standard Category Icons, http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html as this is what's expected to be available in the icon themes in debian. and maybe from time to time look at other icons if there is something not covering completely. But the current debian-* is nowhere to be found. We use debian-* specifically to avoid a name clash with this specification. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502192: menu-xdg: invents own icon names instead of using existing
On Fri, Oct 17, 2008 at 03:13:46PM +0200, Sune Vuorela wrote: On Friday 17 October 2008 15:03:59 Bill Allombert wrote: This is done on purpose. This allow desktop envirnonment to use separate icons for debian menu entries and other entries. Changing the names would break GNOME and KDE3. Furthermore there is no one-to-one mapping between debian sections and other sections, so the proposal is not feasible. for example, the debian-games.directory should reference Icon=applications-games and not Icon=debian-games Standardizing on the xdg icon spec is probably good. Table 5. Standard Category Icons, http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest .html as this is what's expected to be available in the icon themes in debian. and maybe from time to time look at other icons if there is something not covering completely. But the current debian-* is nowhere to be found. We use debian-* specifically to avoid a name clash with this specification. But the main point is still: no one is actually *providing* the debian-* icons. and especially not amongst the fall back themes in the desktop environments. In my K menu, I either get questionmark icons or blue folders as the icon for these. Then KDE4 needs to be fixed. GNOME in etch provides icons for sections fine. Is your expectation that the artists magically should create these icons in their themes, or that the debian icon theme maintaitners should copy/symlink these icon names to something or that the debian icon theme maintainers should create the icons? I can't believe that it is expected to be shown with the default no icon icon. The point I try to get across is that this issue should not be fixed in menu-xdg but on the Desktop environment or themes. If KDE4 or a Debian theme want to alias Icon=debian-games to Icon=applications-games, I am fine with that, but this is independent of menu-xdg. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502285: first upgrade fails, xserver-xorg-video-ati is removed
On Sat, Oct 18, 2008 at 01:33:52PM +0200, Sven Joachim wrote: reassign 502285 aptitude 0.4.11.10-1lenny1 retitle 502285 aptitude: full-upgrade from etch wants to remove xserver-xorg-video-all thanks On 2008-10-18 11:23 +0200, Julien Cristau wrote: On Sat, Oct 18, 2008 at 09:33:00 +0200, Sven Joachim wrote: As you can see, I accepted the third solution which actually upgraded, not removed, xserver-xorg-video-all. The actual upgrade then ran through without a hitch. Should we reassign this to aptitude, or make sure the release notes recommend apt-get for the upgrade instead of aptitude? Removing a lot of packages that are perfectly installable doesn't seem like a good choice... I've reassigned the bug to aptitude for investigation why aptitude thinks that xserver-xorg-video-all is broken and the individual drivers are not installable. This seems to affect many systems, see also #501518 and #501546. Probably, part of the reason is bug #362313, x-server-xorg dependency hell. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486376: Bug#495756: ecl has rpath to insecure location (/tmp/buildd/ecl-0.9j-20080306/build/)
On Mon, Aug 25, 2008 at 11:54:26PM +0200, Luca Capello wrote: Hi Bill! For the ECL list: this is a 'serious' bug in the Debian BTS [1]. For the reason why rpath is considered harmful by Debian see [2] and [3]. Please don't Cc: me, I read the list. However, please keep the Debian bug cc:ed (no need to subscribe), I set the M-F-T and R-T to both the bug and the mailing list to facilitate the above :-) On Wed, 20 Aug 2008 10:55:51 +0200, Bill Allombert wrote: Hello Debian Common Lisp Team, ecl includes a ELF file /usr/lib/ecl/asdf.fas with a rpath pointing to /tmp/buildd/ecl-0.9j-20080306/build/. If I'm not wrong, this is a design decision, which seems to be officially documented at [4]. However, it's strange that the rpath is pointing to /tmp/... and not /usr/lib/ecl/. This is why I reported the bug: A rpath of /usr/lib/ecl/ is not a problem if it is intended. However a rpath of /tmp/buildd/ecl-0.9j-20080306/build/ is a security hole since /tmp is world-writable: an attacker can just 'mkdir -p /tmp/buildd/ecl-0.9j-20080306/build/' and then add trojaned shared library there, and wait for someone to load /usr/lib/ecl/asdf.fas and compromise their account. This allows an attacker with write access to that directory to add modified libraries which will be loaded when someone else run ecl. I've added the ECL list to cc:. While I can easily remove the rpath as explained at [3], I'll wait for upstream's voice :-) Instead of removing it, if /usr/lib/ecl/ was the intended rpath, you can just replace the rpath with /usr/lib/ecl/. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445049: gnucash: please update to new menu structure
On Tue, Oct 02, 2007 at 10:41:48PM +0200, Bill Allombert wrote: Package: gnucash Version: 2.2.1-1 Severity: normal Hello Thomas, The file /usr/share/menu/gnucash reads ?package(gnucash):needs=x11 section=Apps/Tools \ title=GnuCash \ longtitle=GnuCash personal finance tracking program\ command=gnucash\ icon=/usr/share/gnucash/pixmaps/gnucash-icon.xpm Please migrate to the new menu structure[1]. section=Apps/Tools should be changed to section=Applications/Office. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5 Hello Thomas, I reported this change nine month ago. Any reason why it is not fixed yet ? You made several upload of gnucash in this time frame. I like this to be fixed for Lenny. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496831: popularity-contest: Does not send votes for non-program packages
On Wed, Aug 27, 2008 at 10:35:30PM +0200, Noel David Torres Taño wrote: Package: popularity-contest Version: 1.45 Severity: important Actually popcon is unable to send votes for packages like kdemultimedia or libxcursor1 because they have no executables. Hello Noel, You are misunderstanding how popcon vote works. 1) popcon does not really send votes for individual packages. Votes are computed on the server from the report. The FAQ says: Q) What is considered a 'vote' for a package ? A) A computer 'vote' for a package if according to the data provided in the report, a program provided or depending on the package was used less than thirty days ago. This computation is performed by the popcon server. 2) Executables files are not treated specially. 3) libxcursor1 has actually 27015 votes: $ wget -O- -q http://popcon.debian.org/by_vote | grep libxcursor1 192 libxcursor155969 27015 9400 8189 11365 (Debian X Strike Force) 4) kdemultimedia does not have any real content so it does not deserve any votes, since it can be removed without ill effect. Here the file list of kdemultimedia: /usr/share/doc/kdemultimedia/changelog.Debian.gz /usr/share/doc/kdemultimedia/copyright Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437118: reassign + close ;-) (not fully sure if this is right)
On Thu, Aug 28, 2008 at 11:26:40AM +0200, Holger Levsen wrote:
Hi,
forwarded to the popcon-developers, just in case.
On Thursday 28 August 2008 01:15, Ian Jackson wrote:
Holger Levsen writes (Bug#437118: reassign + close ;-) (not fully sure if
this is right)):
I'm reassigning this to dpkg, even though I'm not sure if this is right.
Apologies for that.
I don't think it is, probably.
This is based on popcon data. How does popcon read the dpkg
database ? Does it just read /var/lib/dpkg/status ?
I assume not directly but with dpkg.
Precisely popularity contest use the output of
dpkg-query --show --showformat='${status} ${package}\n'
However may be it does not check if dpkg-query return an error status.
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496831: popularity-contest: Does not send votes for non-program packages
On Wed, Aug 27, 2008 at 11:47:30PM +0200, Noel David Torres Taño wrote: Hello Noel, You are misunderstanding how popcon vote works. 1) popcon does not really send votes for individual packages. Votes are computed on the server from the report. The FAQ says: Q) What is considered a 'vote' for a package ? A) A computer 'vote' for a package if according to the data provided in the report, a program provided or depending on the package was used less than thirty days ago. This computation is performed by the popcon server. 2) Executables files are not treated specially. 3) libxcursor1 has actually 27015 votes: $ wget -O- -q http://popcon.debian.org/by_vote | grep libxcursor1 192 libxcursor155969 27015 9400 8189 11365 (Debian X Strike Force) 4) kdemultimedia does not have any real content so it does not deserve any votes, since it can be removed without ill effect. Here the file list of kdemultimedia: /usr/share/doc/kdemultimedia/changelog.Debian.gz /usr/share/doc/kdemultimedia/copyright Cheers, Well, please let me explain where I saw it first time and you maybe can help me with that. I've popularity-contest installed, and wmaker with wmaker-data. But I saw this: 0 0 wmaker-data NOFILES What is happening there? I have lots of those 0 0 packages, mostly libs and data packages. wmaker-data only contains icons in TIFF format and has no reverse dependencies, so we cannot check whether this package was used recently. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497450: resume no more work after s2disk (regression from 2.6.25-2)
Package: linux-image-2.6.26-1-amd64 Version: 2.6.26-3 Severity: important Hello Kernel team, s2disk from uswsusp used to be very reliable with Debian kernel 2.6.25-2, but with 2.6.26-1, it fails consistently at resume. The relevant part of the log from the resume session: http://newpeople.debian.org/~ballombe/misc/log-2.6.26-1-amd64.txt Cheers, Bill. -- Package-specific info: -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (100, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.25-2-amd64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.26-1-amd64 depends on: ii debconf [debconf-2.0]1.5.11etch2 Debian configuration management sy ii initramfs-tools [linux-initr 0.85i tools for generating an initramfs ii module-init-tools3.3-pre4-2 tools for managing Linux kernel mo linux-image-2.6.26-1-amd64 recommends no packages. -- debconf information excluded -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500431: popularity-contest: cronned in daily instead of (announced on) weekly
On Sun, Sep 28, 2008 at 09:53:34AM +0200, William Dode wrote: Package: popularity-contest Version: 1.45 Severity: important The cron used for popularity-contest is now cron.daily On the man page it says weekly : Normally, popularity-contest is run from a cron(8) job, /etc/cron.weekly/popularity-contest The manpage is unfortunately outdated, popularity-contest now run from /etc/cron.daily/popularity-contest but still only once a week. This is done to spread the load on the popcon server. It affect popbugs on debian-goodies package when popbugs is run before popularity-contest (the data is missing). Then popbugs says : Try running /etc/cron.weekly/popularity-contest by hand to collect some data. running /etc/cron.daily/popularity-contest will not work, because it will only run one day per weeks. I don't know if i should report the bug on debian-goodies package... Probably yes. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489040: [EMAIL PROTECTED]: Re: Bug#489040: dpkg: handles (menu) triggers inconsistently]
On Fri, Jul 11, 2008 at 02:40:07PM -0400, Joey Hess wrote: Bill Allombert wrote: Could you tell me what means 'triggers-awaited' and how I should handle it ? The triggers.txt says: At a trigger activation, the interested packages(s) are added to the triggering package's list of triggers-awaited packages; the triggering package is said to await the trigger processing. A package which has pending triggers, or which awaits triggers, is not considered properly installed. There are two new dpkg status values, `triggers-pending' and `triggers-awaited', which lie between `config-failed' and `installed'. The purpose of the check in update-menus, AIUI, is to package(foo) test in a menu file not enable the menu if the package is removed. Which I suppose must only be needed in the uncommon case where a menu file needs a package other than the package containing it to be installed, or where the menu file is left behind after package removal as a conffile might be. So, it seems this check is still needed when --triggered. But, it should be safe, I think, to check for the triggers-awaited state and treat is as equivilant to installed. It should likewise do the same with the triggers-pending state; a package could have both triggered menu and been itself triggered, and then it would be in the latter state. Thanks, I agree with your analysis. PS, it looks to me like the handling of the installed_packages string, which just gets a list of installed packages shoved into it with no delimiters, is a bit problimatic. Specifically, if foobar is added to the string, a test is_pkg_installed(foo) will succeed, won't it? installed_packages is not a string but a set of string, so this should be fine: setstring installed_packages; Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492144: No new section for Apps/Tools
reassign 492144 debian-policy quit I reassign this bug to debian-policy since this is the group in charge of the menu subpolicy. On Fri, Jul 25, 2008 at 08:49:20AM +0200, Christian Perrier wrote: Quoting Russ Allbery ([EMAIL PROTECTED]): Thanks for your feedback! Hm, in that case, you shouldn't call it Time Tracking if you want gtimer Hmmm, is Tracking really needed ? Or would Applications/Time just be enoughbut maybe too vague and therefore attracting thigns that aren't really appropriate for it. Well, Applications/Time feel a bit vague and does not blend well with the other name. (Time is not something the program does). BTW, let me use this occasion to thank the lintian maintainer for the lintian test about incorrect menu entries being used. I fixed dozens of such bugs while doing l10n NMUs on poorly maintained packages. And this one to thank you for your contribution to menu QA. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492406: Package which require to download non-free content should be in contrib
On Fri, Jul 25, 2008 at 04:29:02PM -0400, Daniel Dickinson wrote: Package: debian-policy Subject: Packages which require to download non-free content should be in contrib Packages like msttcorefonts cannot be installed without downloading content that would be in non-free, or cannot be included in debian at all, if packaged and should therefore be in contrib. If they cannot be installed without downloading non-free content, then certainly they depends on non-free content and does not belong in main: This is covered by 2.2.1: In addition, the packages in _main_ * must not require a package outside of _main_ for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-_main_ package), Personnally, I would argue that if a package sole content is a script to download non-free content, then it should be in non-free. A package should contains some real DFSG-free content to belong in contrib. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493036: Additional Info
On Wed, Jul 30, 2008 at 11:51:19PM +0200, Justin Hartman wrote:
Further to my initial bug report here is the output of apt-get upgrade
running more detailed reporting:
apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
The following packages have been kept back:
wordpress
The following packages will be upgraded:
apache2 apache2-mpm-prefork apache2-utils apache2.2-common
debconf-utils initscripts libkrb53 linux-image-2.6.18-6-amd64 locales
sysv-rc
trac
11 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
Need to get 0B/23.6MB of archives.
After unpacking 4096B of additional disk space will be used.
Do you want to continue [Y/n]?
Preconfiguring packages ...
Setting up debconf (1.5.11etch2) ...
+ '[' -z '' ']'
+ '[' configure = configure ']'
+ '[' -n 1.5.11etch1 ']'
+ dpkg --compare-versions 1.5.11etch1 lt 1.1.0
+ . /usr/share/debconf/confmodule
++ '[' '!' '' ']'
++ PERL_DL_NONLAZY=1
++ export PERL_DL_NONLAZY
++ '[' '' ']'
++ exec /usr/share/debconf/frontend
/var/lib/dpkg/info/debconf.postinst configure 1.5.11etch1
+ '[' -z 1 ']'
+ . /usr/share/debconf/confmodule
++ '[' '!' 1 ']'
++ '[' -z '' ']'
++ exec
++ '[' '' ']'
++ exec
++ DEBCONF_REDIR=1
++ export DEBCONF_REDIR
+ '[' configure = configure ']'
+ '[' -n 1.5.11etch1 ']'
+ dpkg --compare-versions 1.5.11etch1 lt 1.3.11
+ PYTHON=python2.4
+ which python2.4
+ '[' -e /usr/lib/python2.4/compileall.py ']'
+ DIRLIST=' /usr/lib/python2.4/site-packages'
+ for i in '$DIRLIST'
+ python2.4 /usr/lib/python2.4/compileall.py -q
/usr/lib/python2.4/site-packages
Compiling
/usr/lib/python2.4/site-packages/Beaker-0.9.4-py2.4.egg/beaker/ext/google.py
...
SyntaxError: ('future feature absolute_import is not defined',)
Hello Justin,
this looks like an instance of bug #479484 against python-beaker.
This bug is supposed to be fixed in version 0.9.5, but you seem
to have 0.9.4.
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493036: Additional Info
On Thu, Jul 31, 2008 at 01:03:14PM +0200, Justin Hartman wrote: Hi Bill, On Thu, Jul 31, 2008 at 12:04 PM, Bill Allombert [EMAIL PROTECTED] wrote: this looks like an instance of bug #479484 against python-beaker. This bug is supposed to be fixed in version 0.9.5, but you seem to have 0.9.4. Do you have any idea how to upgrade to 0.9.5? I have tried everything but it continuously trys to upgrade debconf first and then I get the same error that prevents me from upgrading python-beaker. I would suggest to download python-beaker 0.9.5 and use dpkg -i, but it seems the severity of bug #479484 need to be raised to grave. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458543: Section menus to new policy
On Tue, Jan 01, 2008 at 03:31:28PM +, Marco Rodrigues wrote: Package: gap Severity: wishlist Hi! Hello Marco, Don't need to change these ones to new menu policy ? Applications ? $ grep -r Apps/Math * debian/gap-doc.doc-base.ref:Section: Apps/Math debian/gap-doc.doc-base.fullindex:Section: Apps/Math debian/gap-doc.doc-base.new:Section: Apps/Math debian/gap-doc.doc-base.tut:Section: Apps/Math debian/gap-doc.doc-base.prg:Section: Apps/Math debian/gap-doc.doc-base.ext:Section: Apps/Math Well actually, when you reported this bug, they were no clear policy on section name for doc-base files. Now things have been fixed and the correction is now 'Science/Mathematics', see /usr/share/doc/doc-base/doc-base.txt.gz I will fix that with the next upload. Thanks for your report, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494758: menu: Unexpected end of line
On Mon, Aug 11, 2008 at 07:37:09PM -0300, Saulo Soares de Toledo wrote: Package: menu Version: 2.1.40 Severity: normal I always receive this error: --- In file /usr/share/menu/mmex, at (or in the definition that ends at) line 4: icon=/usr/share/pixmaps/mmex.xpm ^ Unexpected end of line. Skipping file because of errors... --- Hello Saulo, The problem is not in menu but in the file /usr/share/menu/mmex which does noes not seems to be part of Debian. 1) can you run dpkg -S /usr/share/menu/mmex ? 2) Can you send me a copy of this file Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493007: debian-policy: Please recommend tracking translation status of l10n man pages
On Thu, Jul 31, 2008 at 07:37:15AM +0200, Christian Perrier wrote: Quoting Helge Kreutzmann ([EMAIL PROTECTED]): +If a loclized man page for a certain command is provided, it should s/loclized/localized +either be up to date or it should be clearly visible that this version +is outdated (either by a note in the beginning or by showing the +missing/changed parts in English instead of the target language). +Where the build system of the localized man page does not provide the +option to enable this Debian developers and maintainers are asked to +take this issue to their upstream to resolve. I'm not sure that the policy talks about Debian developers. It probably talks about package maintainers or so I would also recommend turning the should to must for native packages. It probably needs the following to be included in the Developer's Reference: + +If Debian developers themselves provide a framework to support +localized man pages this framework must fulfill the requirements of +the previous paragraphs. In this case it is recommended to use po4a +for localization. + That latter part probably belongs more to the Developer's Reference. Indeed, a section about po4a and a simple way to setup a framework for localized manpages would be a great addition to it. Frankly, I do not like po4a for manpages. I think we should provide a simpler solution that provide the warranty above. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495233: debian-policy: README.source content should be more detailed
On Fri, Aug 15, 2008 at 03:17:44PM -0300, Lucas Nussbaum wrote: On 15/08/08 at 11:01 -0700, Russ Allbery wrote: Giacomo Catenazzi [EMAIL PROTECTED] writes: Lucas Nussbaum wrote: First, section 4.14 should list things that one does not need to describe in debian/README.source. For example, the use of one of the standard patch systems (quilt, dpatch, simple-patchsys) doesn't need to be documented, since every NMUer should be able to work with them. I don't agree. This was one of the things that came up specifically in the original discussion that led to the README.source compromise. If nothing else, README.source tells people that yes, this is bog-standard quilt or dpatch, so they don't have to figure out which it is and they don't have to wonder whether there's something weird at work. I would like this file to continue to contain pointers to the standard documentation for quilt or dpatch if those patch systems are used. We allowed for a pointer specifically so that all you have to do is include a line or two of reference. For example, I use: | This package uses quilt to manage all modifications to the upstream | source. Changes are stored in the source package as diffs in | debian/patches and applied during the build. Please see: | | /usr/share/doc/quilt/README.source | | for more information on how to apply the patches, modify patches, or | remove a patch. quilt and dpatch could probably usefully recommend boilerplate text. Another example is build systems: cdbs is used by 20% of our packages, so I don't think that one need to document its use. I think the better way is do it similar to copyright: for common patch/build system we should include only a link to the relative document. Maybe on a common package (build essential or dpkg-dev) or on patch system package (but in this case we should push stronger the maintainer to include the relevant informations). Which is what Policy already says, and quilt, for example, provides such a document for README.source to link to. So I don't think Policy should be changed here. But that won't work if we want to include more info in README.source. What about moving to a machine-parseable format, such as: Patch-system: quilt Patch-system-doc: /usr/share/doc/quilt/README.source This does about the same as grepping the build-dep for quilt. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493036: Additional Info
On Fri, Aug 15, 2008 at 09:59:03AM +0200, Justin Hartman wrote: On Thu, Jul 31, 2008 at 3:01 PM, Justin Hartman [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 1:09 PM, Bill Allombert wrote: I would suggest to download python-beaker 0.9.5 and use dpkg -i, but it seems the severity of bug #479484 need to be raised to grave. It looks like I've only got beaker from the stable distribution which is version 0.6.1-1. Running dpkg -i get the following: dpkg -i python-beaker_0.9.5-1_all.deb (Reading database ... 46535 files and directories currently installed.) Preparing to replace python-beaker 0.6.1-1 (using python-beaker_0.9.5-1_all.deb) ... Unpacking replacement python-beaker ... dpkg: dependency problems prevent configuration of python-beaker: python-beaker depends on python (= 2.5); however: Version of python on system is 2.4.4-2. python-beaker depends on python-support (= 0.7.1); however: Version of python-support on system is 0.5.6. dpkg: error processing python-beaker (--install): dependency problems - leaving unconfigured Errors were encountered while processing: python-beaker This is particularly strange as the apt error references Beaker-0.9.4. Sorry to bump this again, but any ideas on this bug? I'm still not able to do anything. My guess is that you have installed python-beaker 0.9.4 from a non-Debian source. Try to run dpkg -S /usr/lib/python2.4/site-packages/Beaker-0.9.4-py2.4.egg/beaker/ext/google.py Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493036: Additional Info
On Tue, Aug 19, 2008 at 10:14:42PM +0200, Justin Hartman wrote: On Tue, Aug 19, 2008 at 5:24 PM, Bill Allombert [EMAIL PROTECTED] wrote: Try to run dpkg -S /usr/lib/python2.4/site-packages/Beaker-0.9.4-py2.4.egg/beaker/ext/google.py Here's what I get: ~# dpkg -S /usr/lib/python2.4/site-packages/Beaker-0.9.4-py2.4.egg/beaker/ext/google.py dpkg: /usr/lib/python2.4/site-packages/Beaker-0.9.4-py2.4.egg/beaker/ext/google.py not found. But if I ls the file then I can clearly see it's there: ~# ls -l /usr/lib/python2.4/site-packages/Beaker-0.9.4-py2.4.egg/beaker/ext/google.py -rw-r--r-- 1 root root 4234 2008-05-12 21:03 /usr/lib/python2.4/site-packages/Beaker-0.9.4-py2.4.egg/beaker/ext/google.py This suggest this file was not installed through a Debian package, in that case this is not a Debian bug. Try to move /usr/lib/python2.4/site-packages/Beaker-0.9.4-py2.4.egg elsewhere and see what happen. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495753: chicken-bin has rpath to insecure location (/home/evo/chicken-3.2.7/debian/tmp/usr/lib)
Package: chicken-bin Version: 3.2.7-1 Severity: serious Tags: security Hello Davide, chicken-bin includes a binary /usr/bin/chicken with a rpath pointing to /home/evo/chicken-3.2.7/debian/tmp/usr/lib This allows an attacker with write access to that directory to add modified libraries which will be loaded when someone else run chicken-bin. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495758: kwave has rpath to insecure location (/build/buildd/kwave-0.7.10/build/mt:/build/buildd/kwave-0.7.10/build/libgui:/build/buildd/kwave-0.7.10/build/libkwave)
Package: kwave Version: 0.7.10-1.1 Severity: serious Tags: security Hello Bertrand, kwave includes a binary /tmp/kwave//usr/share/apps/kwave/plugins/about with a rpath pointing to /build/buildd/kwave-0.7.10/build/mt:/build/buildd/kwave-0.7.10/build/libgui:/build/buildd/kwave-0.7.10/build/libkwave. This allows an attacker with write access to that directory to add modified libraries which will be loaded when someone else run kwave. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495756: ecl has rpath to insecure location (/tmp/buildd/ecl-0.9j-20080306/build/)
Package: ecl Version: 0.9j-20080306-4 Severity: serious Tags: security Hello Debian Common Lisp Team, ecl includes a ELF file /usr/lib/ecl/asdf.fas with a rpath pointing to /tmp/buildd/ecl-0.9j-20080306/build/. This allows an attacker with write access to that directory to add modified libraries which will be loaded when someone else run ecl. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495769: libpam-nufw has rpath to insecure location (/home/pollux/DEBIAN/NUFW/nufw-2.2.15/src/clients/lib/.libs)
Package: libpam-nufw Version: 2.2.15-1 Severity: serious Tags: security Hello Pierre, libpam-nufw includes a binary /lib/security/pam_nufw.so with a rpath pointing to /home/pollux/DEBIAN/NUFW/nufw-2.2.15/src/clients/lib/.libs. This allows an attacker with write access to that directory to add modified libraries which will be loaded when someone else run libpam-nufw. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495770: marble has rpath to insecure location (/tmp/buildd/marble-0.6+svn837399/debian/tmp/usr/)
Package: marble Version: 0.6+svn837399-1 Severity: serious Tags: security Hello Carsten, the amd64 marble package includes a ELF file /usr/lib/marble/plugins/libMarbleStarsPlugin.so with a rpath pointing to /tmp/buildd/marble-0.6+svn837399/debian/tmp/usr/. There are others: $chrpath /usr/lib/marble/plugins/* /usr/lib/marble/plugins/libCompassFloatItem.so: RPATH=/tmp/buildd/marble-0.6+svn837399/debian/tmp/usr/ /usr/lib/marble/plugins/libMapScaleFloatItem.so: RPATH=/tmp/buildd/marble-0.6+svn837399/debian/tmp/usr/ /usr/lib/marble/plugins/libMarbleOverviewMap.so: RPATH=/tmp/buildd/marble-0.6+svn837399/debian/tmp/usr/ /usr/lib/marble/plugins/libMarbleStarsPlugin.so: RPATH=/tmp/buildd/marble-0.6+svn837399/debian/tmp/usr/ This allows an attacker with write access to that directory to add modified libraries which will be loaded when someone else run marble. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495773: xfmail has rpath to insecure location (/tmp/buildd/xfmail-1.5.5.dfsg.1/debian/xfmail/usr/lib/xfmail:/usr/lib/xfmail)
Package: xfmail Version: 1.5.5.dfsg.1-0.1 Severity: serious Tags: security Hello Florian, xfmail includes a binary /usr/bin/xfmail with a rpath pointing to /tmp/buildd/xfmail-1.5.5.dfsg.1/debian/xfmail/usr/lib/xfmail. chrpath /usr/bin/xfmail /usr/bin/xfmail: RPATH=/tmp/buildd/xfmail-1.5.5.dfsg.1/debian/xfmail/usr/lib/xfmail:/usr/lib/xfmail This allows an attacker with write access to that directory to add modified libraries which will be loaded when someone else run xfmail. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495783: deborphan: orphaner does not work on sid
Package: deborphan Version: 1.7.26 Severity: normal Hello Carsten, orphaner does not work on sid on at least two systems. 1) Simulate just discard the selection. 2) OK fails with 'E: Couldn't find package' On the other hand, apt-get remove $(deborphan) works fine. The systems are sid chroot that were created before the release of etch. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495785: attal has rpath to insecure location (.:/usr/lib/attal)
Package: attal Version: 1.0~rc1+cvs20080318-2 Severity: serious Tags: security Hello Debian Games Team, attal includes a binary /usr/games/attal-theme-editor with a rpath pointing to .:/usr/lib/attal. chrpath /usr/games/* /usr/games/attal-ai: RPATH=.:/usr/lib/attal /usr/games/attal-campaign-editor: RPATH=.:/usr/lib/attal /usr/games/attal-client: RPATH=.:/usr/lib/attal /usr/games/attal-scenario-editor: RPATH=.:/usr/lib/attal /usr/games/attal-server: RPATH=.:/usr/lib/attal /usr/games/attal-theme-editor: RPATH=.:/usr/lib/attal This allows an attacker with write access to the current working directory where attal is launched to add modified libraries which will be loaded when someone else run attal. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495789: milter-greylist has rpath to insecure location (yes/lib)
Package: milter-greylist Version: 3.0-3+b1 Severity: serious Tags: security Hello Cord, milter-greylist includes a binary /usr/sbin/milter-greylist with a rpath pointing to yes/lib. chrpath /usr/sbin/milter-greylist /usr/sbin/milter-greylist: RPATH=yes/lib This allows an attacker with write access to the current working directory where /usr/sbin/milter-greylist is started to create a directory yes/lib and add modified libraries which will be loaded when someone else run milter-greylist. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496044: aladin: please update to the new menu structure
Package: aladin Version: 1.19-7.1 Severity: normal Hello Pascal, The file /usr/share/menu/aladin reads ?package(aladin):needs=text section=Apps/Tools \ title=aladin command=/usr/bin/aladin The section Apps/Tools no more exist. Please migrate to the new menu structure [1]. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5 Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496042: addressmanager.app: please update to the new menu structure
Package: addressmanager.app Version: 0.4.7-1+b1 Severity: normal Hello Eric, The file /usr/share/menu/addressmanager.app reads ?package(addressmanager.app):\ needs=X11\ section=Apps/Net\ hints=GNUstep,mail\ title=AddressManager\ longtitle=GNUstep Personal Address Manager\ description=AddressManager constitutes a personal\ address manager for the GNUstep software system.\ icon=/usr/share/pixmaps/AddressManager.xpm\ command=/usr/bin/AddressManager Please migrate to the new menu structure [1]. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5 The section should be Applications/Data Management Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496057: avida-qt-viewer: please update to the new menu structure
Package: avida-qt-viewer Version: 2.0b7-4.2 Severity: normal Hello Miriam, The file /usr/share/menu/avida-qt-viewer reads ?package(avida-qt-viewer):needs=x11 section=Apps/Science \ title=Avida Qt Viewer command=/usr/bin/avida-qt-viewer \ icon=/usr/share/pixmaps/avida.xpm Please migrate to the new menu structure [1]. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5 The section should be Applications/Science/Biology I suppose. Applications/Science is not valid. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496089: bclock: please update to the new menu structure
Package: bclock Version: 1.0-12 Severity: normal Hello Teemu, The file /usr/share/menu/bclock reads ?package(bclock):needs=X11 section=Apps/Tools\ hints=Clocks longtitle=Bezier Clock\ title=bclock command=/usr/bin/bclock Please migrate to the new menu structure [1]. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5 The section Apps/Tools no more exist. The consensus is that fancy clocks belong to Games/Toys. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496091: bmon: please update to the new menu structure
Package: bmon Version: 2.0.1-3 Severity: normal Hello Reto, The file /usr/lib/menu/bmon reads ?package(bmon):needs=text section=Apps/Net title=bmon command=/usr/bin/bmon Please migrate to the new menu structure [1]. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5 The section Apps/Net no more exist. I think it belong to Applications/Network/Monitoring. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496094: buici-clock: please update to the new menu structure
Package: buici-clock Version: 0.4.6.0.1 Severity: normal Hello Marc, The file /usr/share/menu/buici-clock reads ?package(buici-clock):\ needs=X11 \ section=Apps/Tools \ hints=Clocks \ title=buici clock \ command=buici-clock Please migrate to the new menu structure [1]. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5 The section Apps/Tools no more exist. The consensus is that fancy clocks belong to Games/Toys. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496092: bookview: please update to the new menu structure
Package: bookview Version: 3.2.1-1 Severity: normal Hello Goto, The file /usr/share/menu/bookview reads ?package(bookview):needs=X11 section=Apps/Tools\ title=BookView command=/usr/bin/bookview Please migrate to the new menu structure [1]. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5 The section Apps/Tools no more exist. Dictionnaries belong to Applications/Text Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote: Russ Allbery [EMAIL PROTECTED] writes: Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 10 Sep 2008, Bill Allombert wrote: I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. So they should set DEB_BUILD_OPTIONS in the environment. That's what it's for. I don't have any objections to that, or even to doing it via dpkg-buildpackage. Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. 2) is the right way to proceed for _Debian_. People in a hurry can use 1, but not us. 2) imply that packages will not have DEB_VENDOR support unless some check they support it. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote: On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). So it still call debian/rules directly in some case. (And I don't see why one way would be more Debianish than the other) Neither I do, but then I do not attempt to kill one way in favour of the other. I would object to a proposal policy making dpkg-buildpackage mandatory to build packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500310: popcon graphs missing
On Sat, Sep 27, 2008 at 07:45:45PM +1200, Amos Jeffries wrote: Package: popularity-contest Hello Amos, Since the Lenny freeze or move of people.debian.org. The popularity contest current ratings tables links are all dead (404 Not Found). Thanks for your report! The graphing previously happened under http://people.debian.org/~igloo/popcon-graphs/* and may have moved or died. Whichever it is, the table displays graph links at http://qa.debian.org/popcon.php need to be updated to reflect the change. These are not hosted by us on popcon.debian.org. I am CCing the relevant people. Maybe we need to move popcon.debian.org to raven, especially if gluck become restricted. Developers should be allowed to look at the raw results. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491722: pari-gp: /usr/bin/gp broken symlink or armel
On Mon, Jul 21, 2008 at 12:02:44PM -0400, Timothy G Abbott wrote: Package: pari-gp Version: 2.3.3-2 Severity: grave The armel build of pari-gp is apparently missing the /usr/bin/gp-2.3 binary, so that /usr/bin/gp is a broken symlink. Hello Tim, Where is the buildlog for the armel build ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491722: pari-gp: /usr/bin/gp broken symlink or armel
On Mon, Jul 21, 2008 at 12:51:29PM -0400, Timothy G Abbott wrote: I'm unable to find a build log for pari (they seem to be missing from buildd.debian.org). (I'm not involved in the armel team; I discovered this when investigating the build failure of one of my packages: http://buildd.debian.org/fetch.cgi?pkg=sympowver=1.019-2arch=armelstamp=1214627014file=log and confirmed that the armel pari-gp deb was missing /usr/bin/gp-2.3). I guess this isn't going to be very debuggable without help from the armel team. Well, I tried on agricola.debian.org and I found that agricola% dpkg-architecture -qDEB_HOST_GNU_SYSTEM linux-gnueabi I do not understand how this can be correct (it should be linux-gnu). Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492144: No new section for Apps/Tools
On Thu, Jul 24, 2008 at 02:08:45AM +0200, Frank Lichtenheld wrote: Package: menu Version: 2.1.39 Severity: normal I was just doing a QA upload for xdkcal which is currently in Apps/Tools. I was unable to find a new section for it. Hello Frank, As documented in the d-d-a announcement, Apps/Tools has been removed because it was a catch-all section. Packagers should try to find a more specific section or request for one. Looking at other calendar apps, they are still in Apps/Tools, with some of them in Applications/Office. Basically I see three options: -- Put calendars in Applications/Office. -- Put calendars in Applications/Project Management. -- Add a new section (named e.g. Applications/Time tracking) for calendar and clocks. I am CCing Debian-policy for comments. Thanks for raising the issue. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492144: No new section for Apps/Tools
On Thu, Jul 24, 2008 at 09:05:39AM -0700, Russ Allbery wrote: Bill Allombert [EMAIL PROTECTED] writes: Looking at other calendar apps, they are still in Apps/Tools, with some of them in Applications/Office. Basically I see three options: -- Put calendars in Applications/Office. -- Put calendars in Applications/Project Management. -- Add a new section (named e.g. Applications/Time tracking) for calendar and clocks. I am CCing Debian-policy for comments. I like the third idea. I had a similar problem with gtimer. Well, but we would have to draw the line between gtimer and gnotime (which belong to Applications/Project Management according the menu subpolicy). Thanks for your feedback! BTW we cannot change the menu subpolicy until lenny release because the translation would need to be updated as well. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498055: [Lokalizacija] menu 2.1.39: Please update the PO translation for the package menu
On Sat, Sep 06, 2008 at 07:28:54PM +0200, Josip Rodin wrote: Package: menu Severity: wishlist Tags: l10n On Sun, May 04, 2008 at 01:56:39PM +0200, Christian Perrier wrote: You are noted as the last translator of the translation for the Debian menu section names. The English template has been changed, and now some messages are marked \fuzzy\ in your translation or are missing. These section names are now frozen and this is a good moment to update them. Please send the updated file as a wishlist bug against menu. Please mention in the bug report that your translation applies to menu sections (po-sections). If this was in a version control system somewhere where I could just update, edit and commit, I would have made the deadline ages ago, this procedure is cumbersome... There is one: http://alioth.debian.org/projects/menu/ If you want, I can give you commit access. Thanks for your translation, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498055: [Lokalizacija] menu 2.1.39: Please update the PO translation for the package menu
On Sat, Sep 06, 2008 at 10:32:01PM +0200, Josip Rodin wrote: On Sat, Sep 06, 2008 at 09:35:01PM +0200, Bill Allombert wrote: There is one: http://alioth.debian.org/projects/menu/ If you want, I can give you commit access. Oh, good. I would be grateful. [EMAIL PROTECTED]:~/cvs/menu/po-sections]% cvs commit -m sync hr.po /cvsroot/menu/menu/po-sections/hr.po,v -- hr.po new revision: 1.5; previous revision: 1.4 cvs [commit aborted]: could not open lock file `/cvsroot/menu/menu/po-sections/,hr.po,': Permission denied Say when :) Now (hopefully)! Please add a line to debian/changelog when you update something. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463030: apt =0.7.7 break menu update mechanism
On Fri, Apr 11, 2008 at 12:01:44AM +0200, Robert Luberda wrote: found apt 0.7.11 thanks On Tue, 29 Jan 2008, Bill Allombert wrote: Hi, Version 0.7.7 (and above, but not below) of apt-get breaks the automatic update of the Debian menu system. It seems the postinst script inherit some signal handling from apt-get that break menu, but I do not have pinpointed it yet. The bug also affects dwww, which runs a background job in postinst. With current apt the job is killed with SIGHUP. I'm going to upload dwww 1.10.12 with work-aroud for this bug, however it still can be easily reproduced with previous version. Despite the work around, this bug will affect etch to lenny upgrade whenever apt is upgraded before menu or dwww. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489771: New Build-Options field and build-arch option, please review
On Mon, Jul 14, 2008 at 01:22:58PM -0700, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: I think we're already on that path for quite some time. If your package uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting them for you (with dpkg-architecture). I most certainly do not rely on dpkg-buildpackage setting anything. I call dpkg-architecture directly, which is also what's in our best practice documents. DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) I would consider packages that didn't do that and just assumed that those variables were already set to be buggy. The same is expected with default values of builder/linker flags now that dpkg-buildpackage provides reasonable defaults. Yeah, that bothered me too. I made a perhaps poor tactical decision to not fight about it since it seemed that it had a lot of momentum and I couldn't think of specific problems other than the one that we ran into. But this is going beyond setting some defaults that are already set in nearly all of our packages. So yes, I'm somehow building on this model where dpkg-buildpackage can simplify the work of packager by providing some distribution-wide reasonable defaults. People have noticed that and already requested that we can call arbitrary targets of debian/rules with all the proper initialization done precisely for test purpose during packaging work (see #477916). I must say, I really do not like this direction. debhelper and cdbs and similar sytsems are the places to provide this help where people want to use it, in my opinion. We have a lot of past experience with that and we have the compatibility level to handle smoothing transitions. (And to provide a way for people to never transition, I admit, and I see where that's the problem that you're solving, but I prefer that problem to the problems introduced by the instability of having the package build infrastructure change the input to the builds without coordination with the package.) I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498590: menu: documentation tailored to generate files in /etc
On Thu, Sep 11, 2008 at 06:40:31PM +0200, Bernhard R. Link wrote: I've looked at the documentation for things to suggest putting generated files to /etc instead of /var (which several WMs do) and found the following issues: Hello Bernhard, If they still do, it is not because I failed to report the issue to them. I suggest you report bugs to the relevant WMs. The description for examplercfile contains /etc/. Looking at it, it actually looks like menu could need some improvement here. Generating the files in the proper place seem to not only need multiple symlinks (on in the final place of the configuration file to the generated file and one back from the example file (which looks like it would then be the final place for the user make modifications to the window manager config, so a bit misnamed), but also end up with no configuration at all when menu is not installed. Would you care to provide a patch? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Mon, Jan 28, 2008 at 12:29:35PM +, 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. Christian Perrier seconded this here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440420#100 However, since later discussion indicated that we should drop the .UTF-8 business, I think we can also drop it from the policy proposal. (Manual pages still shouldn't lie about their encoding if they install files there, but since this will not be the recommended default there is no reason to bloat policy with it.) Here's another updated version. Christian, are you still OK with this? 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 sect Seconded. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. signature.asc Description: Digital signature
Bug#465136: su-to-root: Please support arguments for command
On Sun, Feb 10, 2008 at 11:06:29PM +0100, Daniel Hahler wrote: Package: menu Version: 2.1.37 Severity: wishlist Tags: patch It does not seem to be possible to call a command with arguments, using su-to-root, e.g. su-to-root -c apt-get install foo does not work (error: command apt-get install foo not found). Of course you can: the manual page say: -c command The command to execute as a string. This option is mandatory. so you should do su-to-root -c apt-get install foo which works fine. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465136: su-to-root: Please support arguments for command
On Mon, Feb 11, 2008 at 03:03:50AM +0100, Daniel Hahler wrote: The attached patch should fix this. Not that it matter much, but your patch is not against the upstream version: sudo is the default instead of su. I do not see why ubuntu make that change since they could just add a file /etc/su-to-rootrc with SU_TO_ROOT_SU=sudo to achieve the same effect without patching su-to-root and make it interface-incompatible with upstream. --- /tmp/menu-2.1.37ubuntu1/scripts/su-to-root2008-02-10 23:06:59.893067334 +0100 +++ /usr/sbin/su-to-root 2008-02-11 03:00:10.0 +0100 @@ -65,9 +65,9 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin SHELL=`eshell $PRIV` case $SU_TO_ROOT_SU in - sux) suname=sux; pwuser=$PRIV; cmd='sux -p $PRIV$COMMAND';; + sux) suname=sux; pwuser=$PRIV; cmd='sux -p $PRIV $COMMAND ';; su) suname=su; pwuser=$PRIV; cmd='su -p $PRIV -c $COMMAND';; - *)suname=sudo;pwuser=$USER; cmd='sudo -u $PRIV$COMMAND';; + *)suname=sudo;pwuser=$USER; cmd='sudo -u $PRIV $COMMAND ';; esac transl 'Using %s...\n' $suname transl 'Enter %s passwd at prompt.\n' $pwuser Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457432: popularity-contest: Please include /lib/.+/ in the search space
On Sat, Dec 22, 2007 at 12:32:35PM +0100, Johan Walles wrote: Package: popularity-contest Version: 1.42 Severity: wishlist Tags: patch Please include /lib/.+/ in the search space. This makes Gnome applets which put files only in /usr/lib/appletname/... get proper statistics, as well as kernel-module only packages which put files in /lib/modules/... . Since only /lib and /usr/lib themselves, but not their subdirectories are scanned by ldconfig, this doesn't add any false positives for libraries. This assume only ldconfig is playing with /usr/lib. Unfortunately this is not true, for example files under /usr/lib/locale/ are automatically generated, and so are some python files in /usr/share/, etc. The popularity-contest server use dependencies to get usage of package with NO FILES: they get as much usage as the packages that depend on them, so it is not necessary to have files for all packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460483: menu: support for kdesu from KDE 4
On Sun, Jan 13, 2008 at 03:13:52AM +0100, Armin Berres wrote: Package: menu Version: 2.1.36 Severity: normal Tags: patch Hi! Your package menu suggests kdebase-bin without a specific version. With KDE 4, kdesu will no longer be found in /usr/bin, but in `kde4-config --path libexec` which would be /usr/lib/kde4/libexec for Debian. The KDE 4 Package which contains kdesu is then kdebase-runtime. Please consider the appended patch to add support for kdesu from KDE 4 to su-to-root. Thanks for your patch. Is /usr/lib/kde4/libexec/kdesu going to be the long term path for kdesu ? Will kde4-config be available when su-to-root is running ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459910: [Popcon-developers] Bug#459910: please randomize the submission time (to prevent to DDoS popcon.debian.org)
On Wed, Jan 09, 2008 at 02:40:53PM +0100, Holger Levsen wrote: package: popularity-contest severity: important x-debbugs-cc: debian-publicity As discussed on irc this is because all clients hammer popcon.debian.org on the same day at the same time (in their local timezone at least) once a week, so many submissions get lost. Is it possible to get more data on this issue, like the relevant apache logs ? I suspect the issue is with the bandwidth rather than with the number of concurrent connection. Thanks in advance, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461440: libgtk2.0-0: Must not use a symlink for /usr/share/doc/libgtk2.0-0
On Fri, Jan 18, 2008 at 04:45:41PM +0100, Loïc Minier wrote: clone 461440 -1 reassign -1 debian-policy 3.7.3.0 stop On Fri, Jan 18, 2008, Sven Joachim wrote: In this version, libgtk2.0-0 no longer has a versioned dependency on libgtk2.0-common. That means that you must not symlink /usr/share/doc/libgtk2.0-0 to libgtk2.0-common, see policy section 12.3. Similarly, /usr/share/doc/libgtk2.0-bin must not link to libgtk2.0-0. When you close this bug, don't forget to delete existing symlinks in your preinst scripts. Indeed; this is made clear in file:///usr/share/doc/debian-policy/policy.html/footnotes.html#f83. I'd rather have this relaxed in policy; would it be possible to drop the strict versionning requirements for symlinks? No, this could cause the copyright file to be inaccurate, in the event the license change between versions and packages come from a different versions. Personnally I would rather mandate that every packages include the copyright file in the deb. There are better way to trim /usr/share/doc for system low on diskspace. Cheers, Bill.
Bug#361431: please consider PDF or HTML version of the docs
On Sat, Jan 19, 2008 at 11:51:36AM +0100, Vincent Lefevre wrote: On 2006-04-08 18:13:55 +0200, Yann Dirson wrote: The current doc is formatted to DVI, which is not a very friendly format. Eg, using pdftex or tex4ht, we could get hyperlinked versions of the docs, which would be much more useful. make docpdf can be used. See: http://pari.math.u-bordeaux.fr/archives/pari-dev-0801/msg8.html the issue is that make docpdf does not generated any kind of hyperlink, and DVI is much faster to display than PDF, so I am not usure it is a gain. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408387: might be something
On Tue, Oct 16, 2007 at 12:18:52AM +0300, Eddy Petrișor wrote: Package: menu Version: 2.1.35 Sorry for the delayed answer: And please accept my apology for my own delayed answer... Is the file ~/.local/share/menu-xdg/desktop-directories/menu-xdg/debian-apps.directory also properly localised ? cat /home/eddy/.local/share/desktop-directories/menu-xdg/debian-apps.directory Name[ro]=Aplicaţii It is. 1 [EMAIL PROTECTED] ~/usr/traduceri/po-debconf/di/packages/po $ cat /home/eddy/.local/share/desktop-directories/menu-xdg/debian-applications.directory [Desktop Entry] Type=Directory Encoding=UTF-8 Name=Applications Name[ro]=Applications Which is not localized. Yes, this is because there is a Debian menu transition and translation is not in sync yet. We are actually still missing a Romanian translation. Maybe you can take care of that ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Bug#361431: please consider PDF or HTML version of the docs
On Sat, Jan 19, 2008 at 06:02:29PM +0100, Vincent Lefevre wrote: On 2008-01-19 12:18:12 +0100, Bill Allombert wrote: the issue is that make docpdf does not generated any kind of hyperlink, and DVI is much faster to display than PDF, so I am not usure it is a gain. The Debian package could provide both, so that the user can choose. Moreover, the user may not be able to read dvi files if he doesn't have a dvi viewer (which isn't common and xdvi has many dependencies). Well maybe I should replace the .ps files by .pdf files. But I do not think this would resolve this particular wishlist item to Yann statisfaction. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450924: Bug #450924: menu: doc-base file should use section Debian
On Mon, Jan 14, 2008 at 02:43:22AM +1100, Drew Parsons wrote: Colin Watson wrote: Sorry for the late answer, I overlooked this report. I happened to notice that /usr/share/doc-base/menu still says Section: Apps/Programming; shouldn't this be Section: Applications/Programming now? I suppose the doc-base maintainer should take a stance on the consequence of the new menu hierachy on doc-base sections. More to the point, shouldn't this documentation be in Section: Debian rather than Applications/Programming? It's not a general programming tool, right? Actually 'Debian' does not exist if we strictly follow the doc-base specification. However you are correct that Apps/Programming is wrong, and that Debian seems the logical place in the current tree, better than Apps/System. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461602: libjpeg62-dev: Missing #include in jpeglib.h
On Sat, Jan 19, 2008 at 09:39:57PM +0100, Mike Hommey wrote: Package: libjpeg62-dev Version: 6b-14 Severity: normal When building WebKit with gcc 4.3, I got the following error: In file included from ../../WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp:45: /usr/include/jpeglib.h:914: error: 'FILE' has not been declared /usr/include/jpeglib.h:915: error: 'FILE' has not been declared jpeglib.h uses FILE without #include'ing stdio.h, which is required in C++ with gcc 4.3. Part of the issue is that upstream jpeglib.h is not designed to compile under C++. It is not entirely clear to me that it is the responsibility of /usr/include/jpeglib.h to #include stdio.h rather than the responsibility of WebKit. Actually since C programs have to #include stdio.h, it seems that WebKit should do it as well, and g++-4.3 is exhibiting a latent bug in WebKit. The libjpeg documentation says that: /* * Include file for users of JPEG library. * You will need to have included system headers that define at least * the typedefs FILE and size_t before you can include jpeglib.h. * (stdio.h is sufficient on ANSI-conforming systems.) * You may also wish to include jerror.h. */ Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445728: med-bio: Adding menu for user at suppression.
On Mon, Oct 08, 2007 at 11:21:41AM +0900, Charles Plessy wrote: Package: med-bio Version: 0.14 Severity: normal Hi Andreas, I purged med-bio on my system when making some tests, and I got the following in the output of aptitude: Suppression de med-bio ... Adding menu for user charles of med ... L'exécution de /usr/share/menu/cdd-menu n'a créé aucune donnée en sortie ni retourné aucune erreur. (for the English text Execution of /usr/share/menu/cdd-menu generated no output or returned an error. ) A secondary bug is that this translation is inaccurate, it should be: L'exécution de /usr/share/menu/cdd-menu n'a créé aucune donnée en sortie ou a retourné une erreur. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Bug#461746: vls manpage is sub-par
Package: vls Version: 0.5.4+cvs20031028-6 Severity: normal Hello Sam, the vls manpage is insufficient: SYNOPSIS vlc It should be vls. DESCRIPTION vls does not accept any arguments. However, it will look for its vls.cfg configuration file in the current directory when launched, or, when not found, in /etc/videolan/vls/. vls --help tell a different story: VideoLAN Server 0.5.4+cvs20031028 (May 14 2006) - (c) 1999-2003 VideoLAN vls [options] target options: -v --verbose verbosity (v, vv, vvv) -h --help display this help -d ip[:port] --destination ip and port destination -f file --file file configuration file -t number--ttl number ttl value -l --loop looping at end of program --log file log to file Furthermore the format of vls.cfg is not documented nor a pointer to the documentation is provided. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461764: alsaplayer-daemon: useless nees=X11 menu entry
Package: alsaplayer-daemon Version: 0.99.80-1 Severity: normal Hello Hubert, The file /usr/share/menu/alsaplayer-daemon reads ?package(x-terminal-emulator,alsaplayer-common,alsaplayer-daemon):needs=X11 section=Applications/Sound \ title=AlsaPlayer (daemon) \ longtitle=AlsaPlayer (daemon interface) \ command=/usr/bin/x-terminal-emulator -e /usr/bin/alsaplayer -i daemon ?package(alsaplayer-common,alsaplayer-daemon):needs=text section=Applications/Sound \ title=AlsaPlayer (daemon) \ longtitle=AlsaPlayer (daemon interface) \ command=/usr/bin/alsaplayer -i daemon The first entry is useless: ?package() does not recognize virtual packages, and x-terminal-emulator is one, so this will never be used. Secondly the menu system will automatically convert the needs=text if we are under X11 to 'x-terminal-emulator -e $command', so there is no need for an explicit call. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461805: vim-gui-common: Debian menu entry is never active
Package: vim-gui-common Version: 1:7.1-231+1 Severity: normal Hello Debian VIM Maintainers, The file /usr/share/menu/vim-gui-common reads ?package(vim-gui-common,gvim):needs=x11 \ section=Applications/Editors \ title=GVIM\ longtitle=GVIM, graphical Vi IMproved \ command=/usr/bin/gvim -f \ icon=/usr/share/pixmaps/vim-32.xpm\ icon32x32=/usr/share/pixmaps/vim-32.xpm \ icon16x16=/usr/share/pixmaps/vim-16.xpm However gvim is a virtual package. ?package only look at real package, so in effect this entry is never active. Furthermore, it is possible to install two packages providing gvim at once and it could be nice to have a menu entry for each instead of only one pointing to an unspecied incarnation of gvim. So I would suggest you remove this entry and add an entry for vim-gtk, vim-gnome and vim-lesstif with a different title each. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452801: menu: Does not consider virtual packages as installed
severity 452801 wishlist quit On Sun, Nov 25, 2007 at 11:11:43AM +0100, Robert Luberda wrote: Package: menu Version: 2.1.36 Severity: normal Hi, update-menus -v displays the following warnings: update-menus[4398]: Reading menu-entry files in /usr/share/menu/. update-menus[4398]: file /usr/share/menu/alsaplayer-daemon line 8: Discarding entry requiring missing package x-terminal-emulator. update-menus[4398]: file /usr/share/menu/vim-gui-common line 9: Discarding entry requiring missing package gvim. Both gvim and x-terminal-emulator are virtual packages, and I have at least one package providing them installed: Hello Robert, update-menus is not documented as handling virtual package. I have no idea how to implement that or even if it is a good idea. /usr/share/menu/alsaplayer-daemon is clear bogus. I report it as bug #461764 The situation of /usr/share/menu/vim-gui-common is more complex: There are several packages providing gvim and they can be installed together. There are no reason to provide a menu entry for only one of them, which is not even specified in the title. Thanks for reporting theses issues. In any case, I have no clue how to implement that feature. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447453: menu-xdg: debian-menu.menu does not contain an X-Debian-Wine category
On Sun, Oct 28, 2007 at 11:38:46PM +, Sam Morris wrote: On Sun, 2007-10-28 at 21:09 +0100, Bill Allombert wrote: Hello Sam, You will need to provide more data: how menu entries for programs installed from Wine look like ? How do you generate debian-menu.menu ? I would like to apologize for the long delay. I have been out of town for some times and I forgot about it. Wine seems to save menu entries in ~/.menu/wine like so: ?package(local.Wine):needs=x11 section=/Wine/. title=Gtk-demo longtitle= command=wine 'Z:homesamsrcsolarwin32bingtk-demo.exe' /etc/menu-methods/xdg-desktop-entry-spec-apps turns this into a file at ~/.local/share/applications/menu-xdg/X-Debian-Wine-gtk-demo.desktop: [Desktop Entry] Type=Application Encoding=UTF-8 Name=Gtk-demo GenericName= Comment= Icon= Exec=wine 'Z:\\home\\sam\\src\\solar\\win32\\bin\\gtk-demo.exe' Terminal=false Categories=X-Debian-Wine; The debian-menu.menu is generated in the normal way from /etc/menu-methods/menu- There should be two debian-menu.menu files: 1) the system-wide at /var/lib/menu-xdg/menus/debian-menu.menu 2) the user-wide at ~/.config/menus/debian-menu.menu The first one does not know about X-Debian-Wine because it does not exist in the system menu. The second one however should know about X-Debian-Wine. If it does then gnome-menus is picking the wrong debian-menu.menu file. My original bug report was not quite clear, BTW. Menu entries such as the one above actually don't appear in the Debian menu at all! gnome-menus notices this, and allocates them to the Other menu. So maybe this should actually be a bug against gnome-menus... I'm not sure. It seems like it would be better to fix it at the level of menu-xdg so that the additional menu category would be seen by all consumers of the fdo-menu-spec data files. It looks like a bug in gnome-menus or in the GNOME menu editors. The support for the XDG menu draft in GNOME has always been very weak. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462648: update-menu: example menufiles giving syntax errors
On Wed, Feb 06, 2008 at 04:43:06PM -0800, Nick Daly wrote: Followup-For: Bug #462648 Package: menu Version: 2.1.37 *** Please type your report below this line *** More ways update-menus doesn't work: Update-menus no longer understands custom (any?) menufiles. To reproduce: Make a custom menu file (such as the lyx menufile from the /usr/share/menu directory): ?package(lyx): needs=X11 section=Applications/Office \ title=LyX Document Processor command=lyx \ icon=/usr/share/icons/hicolor/32x32/apps/lyx.xpm\ hints=Word processors After making the file executable (chmod 755) so it produces output, and You should not make it executable since it is not a shell script or a program. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452105: debian-policy: Homepage field in debian/control undocumented
On Sun, Dec 30, 2007 at 09:45:06PM -0800, Russ Allbery wrote: --- orig/policy.sgml +++ mod/policy.sgml @@ -2182,6 +2182,7 @@ itemqref id=f-PriorityttPriority/tt/qref (recommended)/item itemqref id=sourcebinarydepsttBuild-Depends/tt et al/qref/item itemqref id=f-Standards-VersionttStandards-Version/tt/qref (recommended)/item + itemqref id=f-HomepagettHomepage/tt/qref/item /list /p @@ -2196,6 +2197,7 @@ itemqref id=f-EssentialttEssential/tt/qref/item itemqref id=binarydepsttDepends/tt et al/qref/item itemqref id=f-DescriptionttDescription/tt/qref (mandatory)/item + itemqref id=f-HomepagettHomepage/tt/qref/item /list /p Maybe I am confused, but it seems to me that Homepage is only recognized in the source section and this hunk imply otherwise. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
