Bug#705492: Uses deprecated RUN+=socket:
I verified that this is a problem, and am working on a fix. -Geoff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705689: osmo: Osmo crashed and doesnt starts now.
Hello Sir Your remedy has solved the problem. Osmo now works. Strange this never occurred in Debian6/Squeeze, though I used it for a long time. Thank you Kind RegardsKhurram Date: Thu, 18 Apr 2013 20:10:04 +0200 From: a...@gambaru.de To: makh...@hotmail.com CC: 705...@bugs.debian.org Subject: Re: Bug#705689: osmo: Osmo crashed and doesnt starts now. On Thu, 18. Apr 17:35 KHURRAM MAHMOOD makh...@hotmail.com wrote: Hello Sir Executing: === $ osmo /home/myuser/.osmo/config.xml:1: parser error : Document is empty ^ /home/myuser/.osmo/config.xml:1: parser error : Start tag expected, '' not found ^ ** (osmo:4142): CRITICAL **: gui_calendar_set_frame_cursor_thickness: assertion `thickness 0 thickness 6' failed === The processor goes to 100% and osmo doesnt starts. I re-installed it and still the problem persists. The problem might have come due to light failure or some recent 4/5-days It seems you have a corrupt config.xml file. Please backup your hidden config directory and move it to .osmo.old for example, then purge osmo completely and reinstall the application. If osmo cannot find your hidden .osmo directory in $HOME, it will start with new settings and it should work again. Please report back if that solves your problem. Regards, Markus
Bug#699586: closed by vin...@gmail.com (Vincent W. Chen) (Bug#699586: fixed in fvwm 1:2.6.5.ds-2)
Hi, On Tue, Mar 5, 2013 at 11:11 AM, Harald Dunkel ha...@afaics.de wrote: BTW, I get the same problem using vnc4server instead of Tightvnc. Using xorg all 3 versions work. Sorry to say, but I'm now quite convinced that the problem lies with both tightvnc and vnc4server, rather than fvwm. The deprecated.patch only changes from the function XKeycodeToKeysym() to XkbKeycodeToKeysym(). Both of those functions are provided by the X server. If fvwm is really at fault here, then the problem that you're seeing should manifest itself no matter which X server you're using. Since it works under xorg (which probably has more user than any other X server), there's probably no way to fix it in fvwm. You should try contacting the maintainer of tightvnc and vnc4server about this. Good luck, Vincent
Bug#705725: sks maintainer scripts should avoid excessive chowns
Package: sks Version: 1.1.3-2+b1 Severity: normal The sks maintainer scripts have a number of chown operations, including some which are recursive chowns. When run under a kernel that does not implement linking restrictions at the filesystem level, this opens a path for privilege escalation from the sks user to the superuser. We should minimize the use of promiscuous chown operations in sks's maintainer scripts. --dkg -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.8-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696059: linux: PATCH required for server interrupt load balancing/irqbalance (tested)
Dear maintainer, I must agree with Henrique de Moraes Holschuh and Sebastian Kutsch. I've tried the patch from Henrique for two months in a 3.2.35 kernel and it runs smooth without any problems. I use irqbalance (1.0.3-3) with --powertresh option. Please insert this patch into the next wheezy-kernel. Kind regards Holger Lüdecke smime.p7s Description: S/MIME Kryptografische Unterschrift
Bug#699147: Please package newer upstream version
Has there been any progress with this bug? I'd also like to have a more recent upstream version :) Christoph
Bug#705599: finish-install: 07speakup needs to be updated for Wheezy and GNOME 3
Hi, On Fri, 19 Apr 2013, Samuel Thibault wrote: Raphael Hertzog, le Thu 18 Apr 2013 08:27:01 +0200, a écrit : 1/ you're setting up dbus within d-i instead of letting it happen during the first boot like on other installation scenarios ? I don't undesrstand this: it only sets up a temporary session just for setting the value. During my tries I got this error: error: Cannot spawn a message bus without a machine-id: Unable to load /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file '/var/lib/dbus/machine-id': No such file or directory Now you're calling dbus-launch and I expect that a side-effect of this is to create /var/lib/dbus/machine-id. So I'm saying that on normal install this would be created on first boot while in install with speech synthesis it's now created within d-i. (it might not be a big deal, but it's the kind of side effect that I prefer to avoid) 3/ you change directly the user configuration instead of adjusting the defaults (this one is debatable since supplementary users might not want a11y enabled by default but this is a minor inconvenience) Yes, thus Cc-ing debian-accessibility. I'm not sure what we really want. Most often, users (other than the person who installed the system with braille or speech) will not want accessibility being enabled. Yeah, but how common is the multiple users per machine scenario ? And whatever happens, all users will have gdm with a11y enabled. On the other hand, just changing the default could be less surprising than having a configured user. But on the other hand again, having a file in /usr/share/glib-2.0/schemas outside of dpkg's knowledge is not a good thing either, and people will wonder how this script ended up there, and not coming from a package. That's why I have put a clear comment on the top of the file that says what created this file. I agree it's not perfect but the same goes for having one user pre-configured and not the others... I would not expect to have files in my home directory that do not come from /etc/skel/ (except standard directories from xdg-user-dirs). The other positive point of changing the default is that you don't have to special case and hardcode the knowledge of the gdm user. 4/ if the system is reconfigured so that gsettings uses something else than dconf as backend, Urgl, so gsettings might be storing parameters another way, depending on the system preference? That, however is really a problem indeed. Yes. That said I don't know anyone who has done it in production. The only supported databases so far are dconf and gconf. Would it be possible to store a schema file somewhere in the user home? Not that I know. I tried to look up alternative places to put the schema override files (in /var, in /etc, etc.) but didn't find any (except if you're ready to change XDG_DATA_DIRS system-wide). See man glib-compile-schemas. Now, an issue is that while finish-install can be updated with a new patch without rebuilding debian-installer, brltty can not, and rc2, supposed to be used for 7.0.0, is already on its way. Ideally we'd use the same strategy for both the speakup and the brltty installations... Yes, I agree. That said it doesn't break anything to mix up the strategies. Thus we can always sync for 7.0.1. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693282: Fix for this?
On 04/17/2013 11:16 PM, Yves-Alexis Perez wrote: On jeu., 2013-04-04 at 07:40 +0200, Yves-Alexis Perez wrote: Hey, it seems that there's an upstream fix for this at https://trac.gajim.org/ticket/7252 / https://trac.gajim.org/changeset/1d8caae49a31 all those commits are needed to fix this issue: http://hg.gajim.org/gajim/rev/1d8caae49a31 http://hg.gajim.org/gajim/rev/6ab8ea2313aa http://hg.gajim.org/gajim/rev/d34a996f87b8 http://hg.gajim.org/gajim/rev/35a555c4a107 -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703341: firehol: Can't check error if tmp file is removed
On 2013-03-20 11:24, Jerome BENOIT wrote: | I think that 30 seconds is long enough to make a copy of the folder, | and then bash debugging techniques can be used. As a matter of | fact, it is not even necessary to make a copy if some basic | techniques are used: at the beginning of firehol.conf you can add | | set -x | set -v I think this is the best approach would be to add these to the manual page. See attached patch to be included in debian/patches directory. Thanks, Jari From 6846337332aa00fc6927ca405e3f1e384e5b4bea Mon Sep 17 00:00:00 2001 From: Jari Aalto jari.aa...@cante.net Date: Fri, 19 Apr 2013 10:19:46 +0300 Subject: [PATCH] man/firehol.1: (try command): Offer more debugging ideas (Closes: #703341) Organization: Private Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jari Aalto jari.aa...@cante.net --- man/firehol.1 |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/man/firehol.1 b/man/firehol.1 index c5e8bfb..0132641 100644 --- a/man/firehol.1 +++ b/man/firehol.1 @@ -64,7 +64,9 @@ to be found in \fI/etc/firehol/firehol.conf\fR. .IX Item try Activates the firewall, but waits until the user types the word commit. If this word is not typed within 30 seconds, the previous firewall is -restored. +restored. NOTE: to improve debugging, you can add standard shell commands +\fBset -x\fP and \fBset -v\fP at the beginning of +/etc/firehol/firehol.conf file. .IP stop 4 .IX Item stop Stops a running \fBiptables\fR firewall by running \f(CW\*(C`/etc/init.d/iptables stop\*(C'\fR. -- 1.7.10.4
Bug#704242: Driver for PL-2303 HX not working
Am 18.04.2013 11:35, schrieb Johan Hovold: I have used a little perl program that opens the port and send Test to the looped back device. The length of the log looks good. Great. Now I can see what's going on. The only problem (?) is that everything seems to be working. The write succeeds and the four bytes are read back as they should by the driver. But where the data has gone? With cutecom i can see that some of the first bytes are looped back. It must be possible to read any binary (streamed) data. The first thing that comes to mind that could prevent you from reading the received data would be if the tty device is configured for canonical input processing. Have you made sure this is not the case? Can you read the data back if you add a newline to your test string (e.g. test\n)? Hmmn - i don't know which method is used by programs like cutecom or putty? But i know everything works fine before. In this programs every data is terminated with newline, but it does not work. I use this script with a ch341 adapter and it works. Hmmm. Did you remember to initialise the device (e.g. set the termios flags)? Here you can see what's initialized in Perl: use Device::SerialPort 0.12; $port-baudrate(9600) || die failed setting baudrate; $port-parity(none)|| die failed setting parity; $port-databits(8) || die failed setting databits; $port-handshake(none) || die failed setting handshake; $port-write_settings|| die could not write settings; $port-lookclear || die could not empty buffer; $port-read_char_time(0);# don't wait for each character $port-read_const_time(1000);# 1 second per unfulfilled read call my $STALL_DEFAULT = 1;# how many seconds to wait for new input Cheers Karsten Johan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705586: linux-image-3.2.0-4-amd64: ath9k_htc fails to initialize with tl-wn722n; regression vs sqeeze backport
It does look like this is less an issue of regression, but rather an issue of the hardware combination used. I got another machine running Weezie and the wireless adapter seems to work just fine at first glance(not throwing an error immediately after loading firmware). If you (maintainer) want me to produce some debug logs, then go ahead and tell me how. Otherwise I don't know where to go from here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705425: asterisk: segmentation fault on start after upgrade from 1:1.8.13.1~dfsg-1 to 1:1.8.13.1~dfsg-3 (wheezy amd64)
Am Donnerstag, den 18.04.2013, 21:30 +0300 schrieb Tzafrir Cohen: One test if you don't mind: merely rebuilding it vs. Asterisk -3 does not fix the issue, right? Right, it does not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705726: /usr/sbin/vzdump: Non-existing homepage URL in vzdump package
Package: vzdump Version: 1.2.6-1 Severity: minor File: /usr/sbin/vzdump vzdump package homepage field contains an URL that does not exist: devil pts/1#dpkg --status vzdump [/etc/exim4] Package: vzdump Status: install ok installed Priority: extra Section: admin Installed-Size: 96 Maintainer: Ola Lundqvist o...@debian.org Architecture: all Version: 1.2.6-1 Depends: perl, vzctl, cstream, rsync, liblockfile-simple-perl, exim4 | mail-transport-agent Suggests: xdelta Description: OpenVZ backup scripts This package contains the vzdump script to backup and restore openvz images. Homepage: http://www.proxmox.com/cms_proxmox/en/virtualization/openvz/vzdump/ This URL reports 404 error. -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-openvz-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vzdump depends on: ii cstream2.7.6-1 general-purpose stream-handling to ii exim4 4.72-6+squeeze3 metapackage to ease Exim MTA (v4) ii exim4-daemon-light [ma 4.72-6+squeeze3 lightweight Exim MTA (v4) daemon ii liblockfile-simple-per 0.207-1 Simple advisory file locking ii perl 5.10.1-17squeeze6 Larry Wall's Practical Extraction ii rsync 3.0.7-2 fast remote file copy program (lik ii vzctl 3.0.24-12 server virtualization solution - c vzdump recommends no packages. Versions of packages vzdump suggests: pn xdeltanone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705727: /usr/sbin/vzdump: At some conditions vzdump does not return error code, breaking chain of commands in sh scripts
Package: vzdump Version: 1.2.6-1 Severity: normal File: /usr/sbin/vzdump If I log in into vz virtual machine via vzctl enter then vzdump can't backup that machine and that's normal: INFO: Can not suspend container: Resource temporarily unavailable INFO: Error: foreign process 7313/16471(vzctl) inside CT (e.g. vzctl enter or vzctl exec). However, vzdump does not return error code when this error happens, so the chain of shell commands like this /usr/sbin/vzdump --suspend --compress --dumpdir /mnt/ftp/vz-$1/ --all --stdexcludes --maxfiles $MAXF $EXCL echo OK will return OK even if vzdump fails to backup virtual machine. Thus forgotten/frozen vzctl exec blocks whole backup process silently and backup script does not backup without reporting any problems. vzdump should return some error code if it fails, or provide some other means to notify that backup did not succeed. -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-openvz-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vzdump depends on: ii cstream2.7.6-1 general-purpose stream-handling to ii exim4 4.72-6+squeeze3 metapackage to ease Exim MTA (v4) ii exim4-daemon-light [ma 4.72-6+squeeze3 lightweight Exim MTA (v4) daemon ii liblockfile-simple-per 0.207-1 Simple advisory file locking ii perl 5.10.1-17squeeze6 Larry Wall's Practical Extraction ii rsync 3.0.7-2 fast remote file copy program (lik ii vzctl 3.0.24-12 server virtualization solution - c vzdump recommends no packages. Versions of packages vzdump suggests: pn xdeltanone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703341: firehol: Can't check error if tmp file is removed
Hello Jari: Thanks for the patch, but I afraid it is now obsoleted: the Sanewall upstream maintainer exhausted your wish, and it was backported to the coming Debian firehol package. On 19/04/13 09:21, jari wrote: On 2013-03-20 11:24, Jerome BENOIT wrote: | I think that 30 seconds is long enough to make a copy of the folder, | and then bash debugging techniques can be used. As a matter of | fact, it is not even necessary to make a copy if some basic | techniques are used: at the beginning of firehol.conf you can add | | set -x | set -v I think this is the best approach would be to add these to the manual page. See attached patch to be included in debian/patches directory. Thanks, Jari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705601: libflac-dev conflicting with boost::shared_ptr
Hi,
well, that's an interesting bug, indeed. Especially, since `pkg-config
--cflags flac` does not add anything more than -I/usr/include/FLAC to
the command line.
Am Mittwoch, den 17.04.2013, 12:26 +0200 schrieb raphael:
# mv /usr/include/FLAC/assert.h{,.bak}
I come to the same conclusion. It turns out that boost/assert.hpp,
included from boost/smart_ptr/shared_ptr.hpp, includes assert.h at
one point and the compiler decides to prefer FLAC/assert.h
over /usr/include/assert.h when -I/usr/include/FLAC is passed to its
command line.
I have no idea, though, why the compiler does this. Maybe because the .c
header is explicitely included. Changing boost/assert.hpp to include
cassert instead of assert.h, as discussed in the code comment,
should fix the issue as well. I have yet not tried this out, though.
- Fabian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705596: libconfig-model-dpkg-perl: does not parse correctly License fields with commas
On Wednesday 17 April 2013 11:32:12 Cédric Boutillier wrote: $ cme check dpkg-copyright Warning: skipping value BSD-2-clause or Ruby, and PSF because of the following errors: license Ruby, is not declared in main License section. Expected BSD-2-clause LGPL-2.1 PSF Ruby Bummer, the parser is confused that the comma appended to Ruby :-( As a work-around you can try to add a space between 'Ruby' and the comma. I.e.: License: BSD-2-clause or Ruby , and PSF I'll fix the Parse::RecDescent grammar used to parse the license line. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#368297: About the libgcrypt and OpenLDAP issue
Werner Koch wrote: On Thu, 18 Apr 2013 20:40, clo...@igalia.com said: I see two options to get this fixed for Wheezy: [Option 1] -- Do the same that Ubuntu did. That is: 1.a) Patch libgcrypt to revert commit d769529a71ccda4e833f919f3c5693d25b005ff0 Urgs. That is a short sighted fix. [Option 2] -- Patch OpenLDAP to set the flag GCRYCTL_DISABLE_SECMEM if GCRYCTL_INITIALIZATION_FINISHED is false. This is the patch I previously proposed at http://bugs.debian.org/368297#135 That is the most correct solution. Excuse me? By what measure is this correct? Certainly not by any published official documentation. Any application (not library) which wants to use that mlock protected memory (aka secure memory) needs to make sure that libgcrypt has been initialized correctly. Thus if the application does not do that and a library wants to to its own thing, that library should do it in the above way. The OpenLDAP library doesn't want one thing or another at all. It simply is expected to use GnuTLS on Debian and it initializes it as documented. Frankly, speaking for the OpenLDAP Project, what we want is to delete all support for GnuTLS. It is, like Mozilla NSS, a poorly designed API with requirements that are impossible to satisfy in the real world, and more trouble than it's worth. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680856: offlineimap: NMU diff for 6.5.4-2.1
Dear maintainer, I have some free time and I'm offering help. Here is the NMU diff[1] to fix SERIOUS bug #680856 for the release. Please let me know if it is ok to proceed with the NMU. Feel free to contact if you have any questions. Thank you for maintaining the package, Jari Aalto [1] http://www.debian.org/doc/developers-reference/pkgs.html#nmu [2] http://dep.debian.net/deps/dep1.html lsdiff(1) of changes: offlineimap-6.5.4/debian/changelog offlineimap-6.5.4/debian/control diffstat for offlineimap-6.5.4 offlineimap-6.5.4 changelog |8 control |2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff -Nru offlineimap-6.5.4/debian/changelog offlineimap-6.5.4/debian/changelog --- offlineimap-6.5.4/debian/changelog 2012-06-05 06:21:48.0 +0300 +++ offlineimap-6.5.4/debian/changelog 2013-04-19 11:03:23.0 +0300 @@ -1,3 +1,11 @@ +offlineimap (6.5.4-2.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/control: Remove python3-sphinx (serious; Closes: #680856). +Patch thanks to Jakub Wilk jw...@debian.org. + + -- Jari Aalto jari.aa...@cante.net Sat, 02 Mar 2013 11:09:34 +0200 + offlineimap (6.5.4-2) unstable; urgency=low * Set myself as a maintainer diff -Nru offlineimap-6.5.4/debian/control offlineimap-6.5.4/debian/control --- offlineimap-6.5.4/debian/control 2012-06-05 03:49:18.0 +0300 +++ offlineimap-6.5.4/debian/control 2013-03-02 11:08:00.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Dmitrijs Ledkovs x...@debian.org Uploaders: John Francesco Ferlito jo...@inodes.org -Build-Depends: debhelper (= 7.0.50~), python, python-sphinx (= 1.0.7+dfsg) | python3-sphinx +Build-Depends: debhelper (= 7.0.50~), python, python-sphinx (= 1.0.7+dfsg) Standards-Version: 3.9.3 Homepage: http://offlineimap.org/
Bug#704729: unblock: alsa-base/1.0.25+3 (pre-approval)
Hello,
I'm aware it's probably too late, but I feel I need to try. Sorry for the
lack of reaction; I'm outstandingly busy lately. :(
On Fri, Apr 05, 2013 at 06:50:24AM +0200, Jordi Mallach wrote:
The rough story is: alsa-base, until +1, was doing Weird Shit™ with its
handling of /etc/default/alsa, which wasn't even a conffile. When I got
rid of all of that in +2, I accidentally got the new conffile renamed to
/e/d/alsa-base due to using debhelper to install it. The script that
sources it wasn't updated to look in the new location, and of course users
were left with the old conffile and the new one in the filesystem.
The updated package tries to fix this for people upgrading from squeeze
and also for current testing users which already have both files.
Additionally, it marks the package as MA: foreign. SVN also had two old
commits that add a missing pre-dependency on dpkg, and remove redundant
dirs from debian/alsa-base.dirs. If these two old commits are
unacceptable, I'll revert and rebuild, but I've checked that the package
contents are identical.
In order to make this easier, I've reverted the MA and debhelper change.
The only remaining changes are the Pre-Depends and the conffile dance.
I haven't had time to explore mbiebl's suggestion of going the other
route. I'm happy to accept a patch which should be fairly easy to write
based on what I'm attaching now. Needs to happen rsn though, if at all.
--
Jordi Mallach Pérez -- Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/
diff -Nru alsa-base-1.0.25+2+nmu2/debian/alsa alsa-base-1.0.25+3/debian/alsa
--- alsa-base-1.0.25+2+nmu2/debian/alsa 2012-05-20 01:20:03.0 +0200
+++ alsa-base-1.0.25+3/debian/alsa 2013-04-01 07:05:11.0 +0200
@@ -15,10 +15,10 @@
MYNAME=/usr/sbin/alsa
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
-# Default values of variables in /etc/default/alsa
+# Default values of variables in /etc/default/alsa-base
force_unload_modules_before_suspend=
-[ -f /etc/default/alsa ] . /etc/default/alsa
+[ -f /etc/default/alsa-base ] . /etc/default/alsa-base
# $* MESSAGE
warn() { echo ${MYNAME}: Warning: $* 2 ; }
diff -Nru alsa-base-1.0.25+2+nmu2/debian/alsa-base.postrm alsa-base-1.0.25+3/debian/alsa-base.postrm
--- alsa-base-1.0.25+2+nmu2/debian/alsa-base.postrm 2012-05-20 14:23:19.0 +0200
+++ alsa-base-1.0.25+3/debian/alsa-base.postrm 2013-04-04 06:50:44.0 +0200
@@ -5,6 +5,9 @@
if [ $1 = purge ]; then
# Remove run time files
rm -rf /var/run/alsa
+
+ # Remove stray file
+ rm -f /etc/default/alsa
fi
#DEBHELPER#
diff -Nru alsa-base-1.0.25+2+nmu2/debian/alsa-base.preinst alsa-base-1.0.25+3/debian/alsa-base.preinst
--- alsa-base-1.0.25+2+nmu2/debian/alsa-base.preinst 2012-07-08 23:49:56.0 +0200
+++ alsa-base-1.0.25+3/debian/alsa-base.preinst 2013-04-19 09:53:15.0 +0200
@@ -12,4 +12,28 @@
[ -d /etc/apm ]rmdir --ignore-fail-on-non-empty /etc/apm
fi
+case $1 in
+install|upgrade)
+ # Handle upgrade of /etc/default/alsa → /etc/default/alsa-base
+ if [ -f /etc/default/alsa ]; then
+ OLDMD5SUM=b0f9824c2d4288aa89df3777668f0d99
+ CURMD5SUM=$(md5sum /etc/default/alsa | sed -e 's/ .*//')
+ # Upgrades prior to the file rename
+ if dpkg --compare-versions $2 lt 1.0.25+2; then
+ if [ $OLDMD5SUM = $CURMD5SUM ]; then
+rm -f /etc/default/alsa
+ # Don't overwrite the file if it already existed
+ elif [ ! -f /etc/default/alsa-base ]; then
+mv /etc/default/alsa /etc/default/alsa-base
+ fi
+ # Upgrades from current testing: both files exist
+ # If the old file was modified, just leave it there
+ elif dpkg --compare-versions $2 lt 1.0.25+3; then
+ if [ $OLDMD5SUM = $CURMD5SUM ]; then
+rm -f /etc/default/alsa
+ fi
+ fi
+ fi
+esac
+
#DEBHELPER#
diff -Nru alsa-base-1.0.25+2+nmu2/debian/changelog alsa-base-1.0.25+3/debian/changelog
--- alsa-base-1.0.25+2+nmu2/debian/changelog 2012-08-26 17:57:22.0 +0200
+++ alsa-base-1.0.25+3/debian/changelog 2013-04-19 09:51:08.0 +0200
@@ -1,3 +1,20 @@
+alsa-base (1.0.25+3) unstable; urgency=low
+
+ * Add Pre-Depends dpkg (= 1.15.7.2~), for dpkg-maintscript-helper.
+ * In 1.0.25+2, we started using dh_installinit to install the
+default file as /etc/default/alsa-base, and make it a proper conffile.
+However, the alsa script still expected to read defaults from
+/etc/default/alsa. Update it to use the new path (closes: #680914).
+Additionally, make sure that if we're upgrading from versions prior to
+this change, and a /etc/default/alsa file already exists and its
+md5sum isn't known, it'll get renamed to alsa-base in order to
+preserve user changes.
+For testing users, the old file will be removed if it was pristine,
+and otherwise it'll stay unused in the filesystem.
+ * Try to remove /etc/default/alsa
Bug#638309: pcc status update
Hi, there’s currently a discussion on the pcc upstream mailing list about having a shippable version of pcc that actually works on GNU/Linux. There currently is none (except severely older versions that have known deficiencies on amd64), and the ETA is rather high. Since the M-A changes needed are intrusive, and the relevant parts of pcc changed a lot since the last version that was somewhat stably working, I’ve not yet been able to continue working on it. As pcc is only in experimental… let’s wait until upstream is no longer unusable, then update it. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680856: offlineimap: NMU diff for 6.5.4-2.1
On Fri, Apr 19, 2013 at 11:13:02 +0300, jari wrote: Dear maintainer, I have some free time and I'm offering help. Here is the NMU diff[1] to fix SERIOUS bug #680856 for the release. Please let me know if it is ok to proceed with the NMU. Feel free to contact if you have any questions. That wouldn't solve anything for the release. The release is not affected by this bug, which only affects sid. So no, it's not ok. Cheers, Julien signature.asc Description: Digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On Fri, 19 Apr 2013 02:52, mgilb...@debian.org said: 1.a) Patch libgcrypt to revert commit d769529a71ccda4e833f919f3c5693d25b005ff0 Urgs. That is a short sighted fix. That seems to be the solution the rest of the open source community is converging toward. Short sighted is an odd categorization since it seems to have taken 8 years to come to this conclusion. Misunderstanding? With a short sighted fix I mean 1.a; that is the proposal to _revert_ commit d769529. Anyway, this commit is there for a good reason; I can't remember any details but for sure Moritz had a valid reason to do this. Those who are interested may want to do dig the gnupg/gcrypt/poldi archives. The whole mess comes from the idea that a library is able to deduce what the application wants to do without the application telling it. Now if a library is used indirectly by the application and often also from several libraries and even from the application itself, conflicts will arise. Thus we have always told that an application must be aware of _all_ code it is using in its process. Thus libraries may need to expose an interface to the application even if they are used indirectly. Using shared libraries is not easy and sometimes it is impossible to get things right (in OSes where shared libraries have been added as an afterthought). And yes, Libgcrypt is not an exception: It also does guess working and assumes that complex application won't run suid. And it tries to be as failsafe as possible by trying hard to initialize itself if the application forgot to do that. It seems the main reason for all that hassle is the ad-hoc architecture of PAM being a set of libraries instead of a daemon and a library to access that daemon (like userv(1)). PAM's track record of security problems might be an indication of that architectural problem. Maybe some of the blogs on the issue and other comments in this bug log would be of useful to understand why. For example: http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html While we are in the business of refreshing our URL memories, let me follow up with: http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198 Florian Weimer comes to the same conclusion regarding the PAM architecture but also asked why we still need a suid for mlock. The simple reason is that some installations still use suid(e.g. gpg) and rely on Libgcrypt dropping the privileges. Thus we can't change that. A solution would be that the application explicitly tells us not to drop the privileges. libpam can't do that because it does not know anything about the application. But wait, the bug at hand is about a specific application and thus sudo would be able to tell libgcrypt what to do. Adding a global flag to Libgcrypt to skip privilege dropping will not be hard; let me know if this could be a way forward. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705728: release-notes: remove note about a11y and gdm3
Package: release-notes Severity: normal Tags: a11y Hi, In bug #694937, we asked to add a note that a11y wasn't working in the fallback (default) greeter in gdm3. In the meantime we have fixed that (bug #689559, unblock #704934), so the screen reader works again in the fallback greeter. We need to update the text to that effect -- zooming and visual keyboard still don't work afaik though. Thanks, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Am 18.04.2013 12:56, schrieb Johan Hovold: Can you generate a log where bytes are actually lost? Nothing seemed to get lost in the previous log you posted. This was a log with lost data. The logs seems to make politics. ;-) How can i enable the debugging in kernel 3.8.5? Make sure debugfs is mounted: mount -t debugfs none /sys/kernel/debug and then enable debugging: echo module usbserial +p/sys/kernel/debug/dynamic_debug/control echo module pl2303 +p/sys/kernel/debug/dynamic_debug/control Johan Sorry - this does not work for me? root@PC# mount -t debugfs none /sys/kernel/debug root@PC# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014924,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755) /dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) none on /sys/kernel/debug type debugfs (rw,relatime) root@PC# echo module usbserial +p /sys/kernel/debug/dynamic_debug/control bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht gefunden root@PC# ls -l /sys/kernel/debug insgesamt 0 drwx-- 14 root root 0 Apr 19 10:27 . drwxr-xr-x 6 root root 0 Apr 19 10:27 .. drwxr-xr-x 2 root root 0 Apr 19 10:27 acpi drwxr-xr-x 17 root root 0 Apr 19 10:27 bdi drwxr-xr-x 2 root root 0 Apr 19 10:27 extfrag -r--r--r-- 1 root root 0 Apr 19 10:27 gpio drwxr-xr-x 4 root root 0 Apr 19 10:27 hid drwxr-xr-x 2 root root 0 Apr 19 10:27 kprobes drwxr-xr-x 2 root root 0 Apr 19 10:27 kvm drwxr-xr-x 2 root root 0 Apr 19 10:27 mce drwxr-xr-x 2 root root 0 Apr 19 10:27 regmap drwxr-xr-x 3 root root 0 Apr 19 10:27 regulator -rw-r--r-- 1 root root 0 Apr 19 10:27 sched_features -r--r--r-- 1 root root 0 Apr 19 10:27 suspend_stats drwxr-xr-x 5 root root 0 Apr 19 10:27 tracing drwxr-xr-x 2 root root 0 Apr 19 10:27 usb -r--r--r-- 1 root root 0 Apr 19 10:27 wakeup_sources drwxr-xr-x 2 root root 0 Apr 19 10:27 x86 Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#368297: About the libgcrypt and OpenLDAP issue
On Fri, 19 Apr 2013 09:22, h...@symas.com said: Excuse me? By what measure is this correct? Certainly not by any published official documentation. The correct solution is to let the application handle this. But I don't want to repeat this now. most correct here means, it is not worse than what GNUTLS or any other library might do in case requirements (initialization of Libgcrypt) have not been met. As a historic note let me add that Nikos, the GNUTLS author, once approached me to find way to avoid passing an initialization hook up to the application. After a lot of discussion we finally came up with this INITIALIZATION_FINISHED_P hack. The OpenLDAP library doesn't want one thing or another at all. It simply is expected to use GnuTLS on Debian and it initializes it as documented. Well, it also needs to initialize Libgcrypt. But GNUTLS takes care of it and tries to do the Right Thing if that has not been done. Which works in most cases. Frankly, speaking for the OpenLDAP Project, what we want is to delete all support for GnuTLS. It is, like Mozilla NSS, a poorly designed API Split OpenLDAP into a daemon and a simple access library and things would be more robust. This also avoids the hard library dependencies and the need for applications to runtime link to several versions of the same library. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
On Fri, Apr 19, 2013 at 09:25:19AM +0200, Karsten Malcher wrote: Am 18.04.2013 11:35, schrieb Johan Hovold: I have used a little perl program that opens the port and send Test to the looped back device. The length of the log looks good. Great. Now I can see what's going on. The only problem (?) is that everything seems to be working. The write succeeds and the four bytes are read back as they should by the driver. But where the data has gone? With cutecom i can see that some of the first bytes are looped back. It must be possible to read any binary (streamed) data. Yes, but not in canonical mode as then the input is buffered by the kernel tty-layer until certain characters are encountered. The first thing that comes to mind that could prevent you from reading the received data would be if the tty device is configured for canonical input processing. Have you made sure this is not the case? Can you read the data back if you add a newline to your test string (e.g. test\n)? Hmmn - i don't know which method is used by programs like cutecom or putty? Unless it's configurable it should be non-canonical mode. But i know everything works fine before. In this programs every data is terminated with newline, but it does not work. You mean that you updated your test program so that it writes test\n but it still does not work? I use this script with a ch341 adapter and it works. Hmmm. Did you remember to initialise the device (e.g. set the termios flags)? Here you can see what's initialized in Perl: use Device::SerialPort 0.12; $port-baudrate(9600) || die failed setting baudrate; $port-parity(none)|| die failed setting parity; $port-databits(8) || die failed setting databits; $port-handshake(none) || die failed setting handshake; $port-write_settings|| die could not write settings; $port-lookclear || die could not empty buffer; $port-read_char_time(0);# don't wait for each character $port-read_const_time(1000);# 1 second per unfulfilled read call my $STALL_DEFAULT = 1;# how many seconds to wait for new input I don't use perl so can't help you there. Search for perl and icanon or something. You can use stty to determine if canonical-mode is enabled; the output of 'stty -aF /dev/ttyUSB0' contains icanon if enabled and -icanon otherwise. By default it is enabled. You should also make sure that VMIN and VTIME are initialised in non-canonical mode. Specifically, if VMIN is greater than the number of characters written by your test program over the loopback and VTIME is 0, read will block also in non-canonical mode. Johan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705729: gajim: hyperlink handling broken
Package: gajim Version: 0.15.1-4 Severity: normal Hi, when I write in a chat 「http://www.mirbsd.org/mksh.htm」 the link that is made clickable by Gajim is wrong, it makes http://www.mirbsd.org/mksh.htm」 which is invalid and does not match the URI spec. Any raw 8-bit is not part of the hyperlink, but a delimiter, so it must have ended after the “.htm”. Gajim 0.13.1 did that correctly IIRC (that was me using a backport before I upgraded from hardy to sid). -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh-static Versions of packages gajim depends on: ii dnsutils 1:9.8.4.dfsg.P1-6+nmu1 ii python 2.7.3-4 ii python-gtk2 2.24.0-3+b1 Versions of packages gajim recommends: ii dbus1.6.8-1 ii plasma-widgets-workspace [notification-daemon] 4:4.10.2-2 ii python-crypto 2.6-4 ii python-dbus 1.1.1-1 ii python-openssl 0.13-2 ii python-pyasn1 0.1.3-1 Versions of packages gajim suggests: ii aspell-en 7.1-0-1 pn avahi-daemonnone pn dvipng none pn gnome-keyring none pn gstreamer0.10-plugins-ugly none ii libgtkspell02.0.16-1 pn nautilus-sendto none pn network-manager none pn python-avahinone pn python-farstreamnone ii python-gconf2.28.1+dfsg-1 ii python-gnome2 2.28.1+dfsg-1 pn python-gnomekeyring none pn python-gupnp-igdnone pn python-kerberos none ii python-pycurl 7.19.0-5 ii texlive-latex-base 2012.20120611-5 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/gajim/data/other/cacerts.pem (from gajim package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705722: libxml2: CVE-2013-1969
Attaching the patch for convenience.
I'd be happy to step up and NMU this for Wheezy to get it fixed as soon
as possible. I will be preparing the NMU anyway and attach the debdiff
here for review.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From de0cc20c29cb3f056062925395e0f68d2250a46f Mon Sep 17 00:00:00 2001
From: Daniel Veillard veill...@redhat.com
Date: Tue, 12 Feb 2013 08:55:34 +
Subject: Fix some buffer conversion issues
https://bugzilla.gnome.org/show_bug.cgi?id=690202
Buffer overflow errors originating from xmlBufGetInputBase in 2.9.0
The pointers from the context input were not properly reset after
that call which can do reallocations.
---
diff --git a/HTMLparser.c b/HTMLparser.c
index a533f37..6b83654 100644
--- a/HTMLparser.c
+++ b/HTMLparser.c
@@ -6054,6 +6054,8 @@ htmlParseChunk(htmlParserCtxtPtr ctxt, const char *chunk, int size,
if ((in-encoder != NULL) (in-buffer != NULL)
(in-raw != NULL)) {
int nbchars;
+ size_t base = xmlBufGetInputBase(in-buffer, ctxt-input);
+ size_t current = ctxt-input-cur - ctxt-input-base;
nbchars = xmlCharEncInput(in);
if (nbchars 0) {
@@ -6061,6 +6063,7 @@ htmlParseChunk(htmlParserCtxtPtr ctxt, const char *chunk, int size,
encoder error\n, NULL, NULL);
return(XML_ERR_INVALID_ENCODING);
}
+ xmlBufSetInputBaseCur(in-buffer, ctxt-input, base, current);
}
}
}
diff --git a/parser.c b/parser.c
index 31f90d6..1c99051 100644
--- a/parser.c
+++ b/parser.c
@@ -12126,7 +12126,7 @@ xmldecl_done:
remain = 0;
}
}
- res =xmlParserInputBufferPush(ctxt-input-buf, size, chunk);
+ res = xmlParserInputBufferPush(ctxt-input-buf, size, chunk);
if (res 0) {
ctxt-errNo = XML_PARSER_EOF;
ctxt-disableSAX = 1;
@@ -12143,6 +12143,8 @@ xmldecl_done:
if ((in-encoder != NULL) (in-buffer != NULL)
(in-raw != NULL)) {
int nbchars;
+ size_t base = xmlBufGetInputBase(in-buffer, ctxt-input);
+ size_t current = ctxt-input-cur - ctxt-input-base;
nbchars = xmlCharEncInput(in);
if (nbchars 0) {
@@ -12151,6 +12153,7 @@ xmldecl_done:
xmlParseChunk: encoder error\n);
return(XML_ERR_INVALID_ENCODING);
}
+ xmlBufSetInputBaseCur(in-buffer, ctxt-input, base, current);
}
}
}
@@ -12190,7 +12193,14 @@ xmldecl_done:
}
if ((end_in_lf == 1) (ctxt-input != NULL)
(ctxt-input-buf != NULL)) {
+ size_t base = xmlBufGetInputBase(ctxt-input-buf-buffer,
+ ctxt-input);
+ size_t current = ctxt-input-cur - ctxt-input-base;
+
xmlParserInputBufferPush(ctxt-input-buf, 1, \r);
+
+ xmlBufSetInputBaseCur(ctxt-input-buf-buffer, ctxt-input,
+ base, current);
}
if (terminate) {
/*
--
cgit v0.9.1
Bug#704242: Driver for PL-2303 HX not working
On Fri, Apr 19, 2013 at 10:36:57AM +0200, Karsten Malcher wrote: Am 18.04.2013 12:56, schrieb Johan Hovold: Can you generate a log where bytes are actually lost? Nothing seemed to get lost in the previous log you posted. This was a log with lost data. The logs seems to make politics. ;-) Then the problem is most likely not in the driver as the characters are being read back in the log you provided. Now that you have compiled your own kernel, you could run a git bisect to learn if anything else has changed in the kernel (possibly interacting with your test setup) which can explain why things stopped working. I would suggest that you convince yourself that your minimal test setup is correct first, though. Perhaps using the same minimal program (init, write, read) on a working pl2303 device if you have one. How can i enable the debugging in kernel 3.8.5? Make sure debugfs is mounted: mount -t debugfs none /sys/kernel/debug and then enable debugging: echo module usbserial +p/sys/kernel/debug/dynamic_debug/control echo module pl2303 +p/sys/kernel/debug/dynamic_debug/control Johan Sorry - this does not work for me? root@PC# mount -t debugfs none /sys/kernel/debug root@PC# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014924,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755) /dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) none on /sys/kernel/debug type debugfs (rw,relatime) root@PC# echo module usbserial +p /sys/kernel/debug/dynamic_debug/control bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht gefunden Your kernel is not configured to use dynamic debugging. You need to enable CONFIG_DYNAMIC_DEBUG=y. Johan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705730: git-buildpackage: xz: unrecognized option --robot (SOLVED)
Due to PATH, it appears that the xz used was not the correct one: $ type xz /usr/local/bin/xz $ /usr/local/bin/xz --version xz 4.999.8beta liblzma 4.999.8beta $ /usr/bin/xz --version xz (XZ Utils) 5.1.0alpha liblzma 5.1.0alpha I've removed /usr/local/bin/xz And git-buildpackage works. Still, it might be a good idea to catch the xz(1) unrecognized option condition and act accordingly to display something like: ERROR: probably incorrect version of xz. Please check. Jari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#368297: About the libgcrypt and OpenLDAP issue
Werner Koch wrote: On Fri, 19 Apr 2013 09:22, h...@symas.com said: Frankly, speaking for the OpenLDAP Project, what we want is to delete all support for GnuTLS. It is, like Mozilla NSS, a poorly designed API Split OpenLDAP into a daemon and a simple access library and things would be more robust. This also avoids the hard library dependencies and the need for applications to runtime link to several versions of the same library. You're absolutely right. That's why nss-pam-ldapd exists, and why OpenLDAP has supported it (using either nssov or nslcd) since June 2008. We've spent enough time on this, it's past time to move on. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705452: docbook-xml: Fail to upgrade due to pre-depend problem
On 2013-04-18 09:24, Helmut Grohne wrote: Andreas, could you test those debdiffs with your piuparts setup? I have I'll be offline over the weekend and look at this on Monday a few more requests though: * Can you ensure to pass -o Debug::pkgPackageManager=true to apt? no problem * Can you get me the log for inspection of possible warnings or hidden failures? of course * Can you also try apt-get dist-upgrade *without* running apt-get upgrade beforehand? piuparts does only apt-get dist-upgrade. To insert apt-get upgrade beforehand I'd have to patch it first. Andreas PS: I started running piuparts squeeze2wheezy tests with --install-recommends, too, (piuparts until now only tested with recommends disabled) since this is a problem class that really needs recommends to show up ... let's see if we find more bad cases (and more immediate-configure problems) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617425: ITP: derby -- an open source relational database implemented entirely in Java
Hi, we also need an apache derby package. We also could support if you need help. Regards Sascha -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705731: firehol: use standards *.patch file names
Package: firehol
Version: 1.296-0
Severity: wishlist
Hi Jerome,
Here is patch against
http://mentors.debian.net/package/firehol 1.296-1
which chnages deprecated *.dpatch extension in favor of *.patch.
You can also clone the Git repository for full changes (on top of
1.296-1 sources).
git clone http://cante.net/~jaalto/vc/firehol.git
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages firehol depends on:
ii bash 4.2+dfsg-0.1
ii iproute20120521-3+b3
ii iptables 1.4.14-3.1
ii lsb-base 4.1+Debian8
ii net-tools 1.60-24.2
Versions of packages firehol recommends:
ii aggregate 1.6-7
ii curl 7.26.0-1+wheezy1
ii module-init-tools 9-2
ii wget 1.13.4-3
Versions of packages firehol suggests:
pn ulogd none
-- no debconf information
From 7ba3ca22fc7404bf9e46b1739dfd46ce04f1df35 Mon Sep 17 00:00:00 2001
From: Jari Aalto jari.aa...@cante.net
Date: Fri, 19 Apr 2013 11:46:27 +0300
Subject: [PATCH] debian/patches: Use standard *.patch name
Organization: Private
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Jari Aalto jari.aa...@cante.net
---
...ort_vlan.patch = 01-wizard-support-vlan.patch} |0
...ait_feature.patch = 02-add-wait-feature.patch} |0
...ebian_default.patch = 03-debian-default.patch} |0
.../{04_use_mawk.patch = 04-use-mawk.patch} |0
.../{05_fix_msnport.patch = 05-fix-msnport.patch} |0
.../{06_add_openvpn.patch = 06-add-openvpn.patch} |0
.../{09_use_mktemp.patch = 09-use-mktemp.patch} |0
...rd_nettools.patch = 10-discard-nettools.patch} |0
...ch = 11-temporary-folder-error-handling.patch} |0
...patch = 12-panic-option-rationalization.patch} |0
debian/patches/series | 20 ++--
11 files changed, 10 insertions(+), 10 deletions(-)
rename debian/patches/{01_wizard_support_vlan.patch =
01-wizard-support-vlan.patch} (100%)
rename debian/patches/{02_add_wait_feature.patch = 02-add-wait-feature.patch}
(100%)
rename debian/patches/{03_debian_default.patch = 03-debian-default.patch}
(100%)
rename debian/patches/{04_use_mawk.patch = 04-use-mawk.patch} (100%)
rename debian/patches/{05_fix_msnport.patch = 05-fix-msnport.patch} (100%)
rename debian/patches/{06_add_openvpn.patch = 06-add-openvpn.patch} (100%)
rename debian/patches/{09_use_mktemp.patch = 09-use-mktemp.patch} (100%)
rename debian/patches/{10_discard_nettools.patch = 10-discard-nettools.patch}
(100%)
rename debian/patches/{11_temporary_folder_error_handling.patch =
11-temporary-folder-error-handling.patch} (100%)
rename debian/patches/{12_panic_option_rationalization.patch =
12-panic-option-rationalization.patch} (100%)
diff --git a/debian/patches/01_wizard_support_vlan.patch
b/debian/patches/01-wizard-support-vlan.patch
similarity index 100%
rename from debian/patches/01_wizard_support_vlan.patch
rename to debian/patches/01-wizard-support-vlan.patch
diff --git a/debian/patches/02_add_wait_feature.patch
b/debian/patches/02-add-wait-feature.patch
similarity index 100%
rename from debian/patches/02_add_wait_feature.patch
rename to debian/patches/02-add-wait-feature.patch
diff --git a/debian/patches/03_debian_default.patch
b/debian/patches/03-debian-default.patch
similarity index 100%
rename from debian/patches/03_debian_default.patch
rename to debian/patches/03-debian-default.patch
diff --git a/debian/patches/04_use_mawk.patch b/debian/patches/04-use-mawk.patch
similarity index 100%
rename from debian/patches/04_use_mawk.patch
rename to debian/patches/04-use-mawk.patch
diff --git a/debian/patches/05_fix_msnport.patch
b/debian/patches/05-fix-msnport.patch
similarity index 100%
rename from debian/patches/05_fix_msnport.patch
rename to debian/patches/05-fix-msnport.patch
diff --git a/debian/patches/06_add_openvpn.patch
b/debian/patches/06-add-openvpn.patch
similarity index 100%
rename from debian/patches/06_add_openvpn.patch
rename to debian/patches/06-add-openvpn.patch
diff --git a/debian/patches/09_use_mktemp.patch
b/debian/patches/09-use-mktemp.patch
similarity index 100%
rename from debian/patches/09_use_mktemp.patch
rename to debian/patches/09-use-mktemp.patch
diff --git a/debian/patches/10_discard_nettools.patch
b/debian/patches/10-discard-nettools.patch
similarity index 100%
rename from debian/patches/10_discard_nettools.patch
rename to debian/patches/10-discard-nettools.patch
diff --git a/debian/patches/11_temporary_folder_error_handling.patch
b/debian/patches/11-temporary-folder-error-handling.patch
similarity index 100%
rename from debian/patches/11_temporary_folder_error_handling.patch
rename to debian/patches/11-temporary-folder-error-handling.patch
diff
Bug#705722: [xml/sgml-pkgs] Bug#705722: libxml2: CVE-2013-1969
found 705722 2.9.0+dfsg1-4 thanks I think this bug only exist from 2.9.0? xmlBufGetInputBase() does not exist before that. On Fri, Apr 19, 2013 at 12:51 PM, Salvatore Bonaccorso car...@debian.org wrote: Package: libxml2 Severity: grave Tags: security patch upstream Hi, the following vulnerability was published for libxml2. CVE-2013-1969[0]: se-after-free error in htmlParseChunk() and xmldecl_done() If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. A patch commited in git upstream repo is at [1]. For further information see: [0] http://security-tracker.debian.org/tracker/CVE-2013-1969 [1] https://git.gnome.org/browse/libxml2/commit/?id=de0cc20c29cb3f056062925395e0f68d2250a46f Please adjust the affected versions in the BTS as needed. Regards, Salvatore ___ debian-xml-sgml-pkgs mailing list debian-xml-sgml-p...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-xml-sgml-pkgs -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705732: php markdown extra definition lists support
Package: discount Version: 2.1.3-3 Hi, Currently, libmarkdown2 does not support php markdown extra definition lists. % echo -e key\n: value | markdown pkey : value/p I feel it would be better append --with-dl=both configure option. So we'll get following result. % echo -e key\n: value | markdown dl dtkey/dt ddvalue/dd /dl Thank you. -- HAMANO Tsukasa ham...@cuspy.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705733: release-notes: Ext4 is now default on Linux
Package: release-notes Severity: normal Since partman-base 148, ext4 is now default on Linux. See http://anonscm.debian.org/gitweb/?p=d-i/partman-base.git;a=commitdiff;h=b9c91be6c2638277b60fce14d6073746a97d6d57 Patch attached Regards -- Mathieu ext4.diff Description: Binary data
Bug#705452: docbook-xml: Fail to upgrade due to pre-depend problem
On Thu, Apr 18, 2013 at 09:24:30AM +0200, Helmut Grohne wrote:
I believe that we will need a deeper look at #482140. At the moment I do
not fully understand that issue and its implications. The root cause
appears to be lenny's update-xmlcatalog being in a temporarily
inconsistent state due to perl changes in etch-lenny. This should no
longer occur, because even squeeze's update-xmlcatalog no longer uses
File::Spec::Functions.
I *guess* that demoting those to depends could fix this issue, but I
cannot tell what other implications this may have. I attached .debdiffs
to test for this.
FWIW, from what I remember about #482140, the debdiff (briefly quoted
below) makes sense. Assuming squeeze was fixed, the pre-dependency
shouldn't be needed anymore.
I haven't looked at the squeeze version or actually tested anything though.
-Pre-Depends: xml-core (= 0.12)
-Depends: ${misc:Depends}, sgml-data (= 2.0.2), docbook-xml (= 4.2-7)
+Depends: ${misc:Depends}, sgml-data (= 2.0.2), docbook-xml (= 4.2-7),
xml-core (= 0.12)
+ * Demote Pre-Depends on xml-core to Depends. It was used to fix upgrades
+from etch to lenny, but this is no longer necessary.
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705734: Mention python3 version
Package: release-notes Severity: normal Python 3 version seems important to mention. Patch attached Regards -- Mathieu python3.diff Description: Binary data
Bug#680856: offlineimap: NMU diff for 6.5.4-2.1
On 19 April 2013 09:13, jari jaa...@picasso.cante.net wrote: Dear maintainer, I have some free time and I'm offering help. Here is the NMU diff[1] to fix SERIOUS bug #680856 for the release. If the fix is correct and you have tested it, and can take care of fixing fallout, then no need to NMU it. Just do a normal upload, with normal version number and use something like * Team upload As first entry. I'd encourage all debian developers to upload their offlineimap fixes and sponsor fixes from contributors that way. My mail setup is very simplistic compared with many other DDs = Please let me know if it is ok to proceed with the NMU. Feel free to contact if you have any questions. Just upload away ;-) but yeah, no need to spell out NMU and don't try to migrate it to wheezy =) Thank you for maintaining the package, Jari Aalto [1] http://www.debian.org/doc/developers-reference/pkgs.html#nmu [2] http://dep.debian.net/deps/dep1.html lsdiff(1) of changes: offlineimap-6.5.4/debian/changelog offlineimap-6.5.4/debian/control Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705601: libflac-dev conflicting with boost::shared_ptr
Hi, I have no idea, though, why the compiler does this. Maybe because the .c header is explicitely included. Changing boost/assert.hpp to include cassert instead of assert.h, as discussed in the code comment, should fix the issue as well. I have yet not tried this out, though. - Fabian I tried to change #include assert.h to #include cassert but it didn't work. I use FLAC++ in project and FLAC++ requires FLAC. So I think it is very necessary to add FLAC search directory path to gcc flags. But, if i would use only FLAC I could add only #include FLAC/decoder.h to source files, so additional search path would be not necessary. GCC first looking for header files in user specified search paths. raphael:~/programowanie/test/flac_bug $ g++ main.cpp `pkg-config --cflags flac` --verbose Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) COLLECT_GCC_OPTIONS='-I' '/usr/include/FLAC' '-v' '-shared-libgcc' '-mtune=generic' '-march=i586' /usr/lib/gcc/i486-linux-gnu/4.7/cc1plus -quiet -v -I /usr/include/FLAC -imultiarch i386-linux-gnu -D_GNU_SOURCE main.cpp -quiet -dumpbase main.cpp -mtune=generic -march=i586 -auxbase main -version -o /tmp/cca6M8oU.s GNU C++ (Debian 4.7.2-5) version 4.7.2 (i486-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /usr/local/include/i386-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.7/../../../../i486-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/include/FLAC /usr/include/c++/4.7 /usr/include/c++/4.7/i486-linux-gnu /usr/include/c++/4.7/backward /usr/lib/gcc/i486-linux-gnu/4.7/include /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.7/include-fixed /usr/include/i386-linux-gnu /usr/include End of search list. GNU C++ (Debian 4.7.2-5) version 4.7.2 (i486-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 62bfd556e00a93e3d7f66f6876d73826 In file included from /usr/include/boost/shared_ptr.hpp:17:0, from main.cpp:1: /usr/include/boost/smart_ptr/shared_ptr.hpp: In instantiation of ‘T* boost::shared_ptrT::operator-() const [with T = test]’: main.cpp:10:3: required from here /usr/include/boost/smart_ptr/shared_ptr.hpp:424:9: error: ‘assert’ was not declared in this scope Raphael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705601: libflac-dev conflicting with boost::shared_ptr
Am Freitag, den 19.04.2013, 11:57 +0200 schrieb raphael: GCC first looking for header files in user specified search paths. Then FLAC/assert.h should do #include_next assert.h to prevent it from including itself again: http://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705730: git-buildpackage: xz: unrecognized option --robot (SOLVED)
On Fri, Apr 19, 2013 at 12:09:53PM +0300, jari wrote: Due to PATH, it appears that the xz used was not the correct one: $ type xz /usr/local/bin/xz $ /usr/local/bin/xz --version xz 4.999.8beta liblzma 4.999.8beta $ /usr/bin/xz --version xz (XZ Utils) 5.1.0alpha liblzma 5.1.0alpha I've removed /usr/local/bin/xz And git-buildpackage works. Still, it might be a good idea to catch the xz(1) unrecognized option condition and act accordingly to display something like: ERROR: probably incorrect version of xz. Please check. But that would be pristine-tar's job then. Care to reassign? Cheers, -- Guido Jari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705730: reassign to package pristine-tar
reassign 705730 pristine-tar thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705735: ITP: python-scss -- a Scss compiler for Python
Package: wnpp Severity: wishlist Owner: python-modules-t...@lists.alioth.debian.org Package name: python-scss Version : 1.1.5 Upstream Author : German M. Bravo (Kronuz) german...@gmail.com URL : https://github.com/Kronuz/pyScss License : MIT Programming Lang: Python, optionally C Description : a Scss compiler for Python pyScss compiles Scss (Sass), a superset of CSS that is more powerful, elegant and easier to maintain than plain-vanilla CSS. The library acts as a CSS source code preprocesor which allows you to use variables, nested rules, mixins, and have inheritance of rules, all with a CSS-compatible syntax which the preprocessor then compiles to standard CSS. Note: There are some speedups written in C, but one can also do a pure Python package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705736: bozohttpd: please sent .html containing utf-8 with correct Content-Type header
Package: bozohttpd
Version: 2018-1
Tag: patch
Hi,
Out of the box, bozohttpd sents a HTTP header Content-Type: text/html when
offering .html files. When these files are encoded as utf-8, webbrowsers
display these wrongly. The webserver should sent them with a Content-Type:
text/html; charset=utf-8 HTTP header. Attached patch changes bozohttpd's
default.
A better way to support utf-8 would be to offer a commandline option to
override default content types (the -M-flag merely _adds_ to this list).
(For anybody reading this bugreport, who is interested in this utf-8
functionality: at http://mdcc.cx/tmp/bozohttpd/ prebuild .deb's are available.)
Thanks for maintaining bozohttpd!
Bye,
Joost
--
This particular group of cats is mostly self-herding. -- Bdale Garbee
--- content-bozo.c.dist 2011-11-18 10:21:15.0 +0100
+++ content-bozo.c 2013-04-19 11:28:23.901315639 +0200
@@ -45,16 +45,16 @@
*/
static bozo_content_map_t static_content_map[] = {
- { .html, 5, text/html, , ,
NULL },
- { .htm, 4, text/html, , ,
NULL },
+ { .html, 5, text/html; charset=utf-8, ,
, NULL },
+ { .htm, 4, text/html; charset=utf-8, ,
, NULL },
{ .gif, 4, image/gif, , ,
NULL },
{ .jpeg, 5, image/jpeg,, ,
NULL },
{ .jpg, 4, image/jpeg,, ,
NULL },
{ .jpe, 4, image/jpeg,, ,
NULL },
{ .png, 4, image/png, , ,
NULL },
{ .mp3, 4, audio/mpeg,, ,
NULL },
- { .css, 4, text/css, , ,
NULL },
- { .txt, 4, text/plain,, ,
NULL },
+ { .css, 4, text/css; charset=utf-8, ,
, NULL },
+ { .txt, 4, text/plain; charset=utf-8, ,
, NULL },
{ .swf, 4, application/x-shockwave-flash,, ,
NULL },
{ .dcr, 4, application/x-director,, ,
NULL },
{ .pac, 4, application/x-ns-proxy-autoconfig, , ,
NULL },
Bug#666139: This bug does not affect minetest anymore
Hello, minetest now uses vectorial fonts, and this bug cannot be reproduced here. Can some of the participant comment on this? Vincent, maybe, as irrlicht packager? If I knew how to remove the affects mention, I'd remove it :) Bye, Mt. -- Perl is the only language that looks the same before and after RSA encryption. -- Keith Bostic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703431: Annoying GPG error message
On 18/04/2013 14:15, Raphael Hertzog wrote: On Tue, 16 Apr 2013, Robert Spencer wrote: And have debian-cd extract the file and pass it around to APT and debootstrap. And then DEBOOTSTRAP_OPTS would default to --no-check-gpg and we would just unset it to activate the GPG check at the debootstrap level. Can you implement this ? Patch file attached. Again it's for debian-cd 3.1.12. Thanks, but there's a small misunderstanding left here: # By default we use debootstrap --no-check-gpg to find out the minimal set # of packages because there's no reason to not trust the local mirror. But # you can be paranoid and then you need to indicate the keyring to use to # validate the mirror. -#export DEBOOTSTRAP_OPTS=--keyring /usr/share/keyrings/debian-archive-keyring.gpg +#export DEBOOTSTRAP_OPTS=--keyring $ARCHIVE_KEYRING_FILE This still requires that the keyring be installed on the system whereas we're already extracting it from the binary package in debian-cd. I'm sorry, I didn't misunderstand you. I made a bad assumption. I hope the attached patch file is satisfactory. -- Robert Spencer --- CONF.sh~ 2013-03-20 13:32:16.0 + +++ CONF.sh 2013-04-19 09:24:11.0 + @@ -51,6 +51,8 @@ unset OMIT_DOC_TOOLS || true unset MAX_PKG_SIZE || true unset DEBOOTSTRAP_OPTS || true +unset ARCHIVE_KEYRING_PACKAGE || true +unset ARCHIVE_KEYRING_FILE|| true # The debian-cd dir # Where I am (hoping I'm in the debian-cd dir) @@ -179,11 +181,16 @@ #export amd64_MKISOFS=xorriso #export amd64_MKISOFS_OPTS=-as mkisofs -r -checksum_algorithm_iso md5,sha1 +# Keyring (defaults): +#ARCHIVE_KEYRING_PACKAGE=debian-archive-keyring +# The path to the keyring file relative to $TDIR/archive-keyring/ +#ARCHIVE_KEYRING_FILE=usr/share/keyrings/debian-archive-keyring.gpg + # By default we use debootstrap --no-check-gpg to find out the minimal set # of packages because there's no reason to not trust the local mirror. But # you can be paranoid and then you need to indicate the keyring to use to # validate the mirror. -#export DEBOOTSTRAP_OPTS=--keyring /usr/share/keyrings/debian-archive-keyring.gpg +#export DEBOOTSTRAP_OPTS=--keyring $TDIR/archive-keyring/$ARCHIVE_KEYRING_FILE # ISOLinux support for multiboot on CD1 for i386 export ISOLINUX=1 --- Makefile~ 2013-03-19 15:41:47.0 + +++ Makefile 2013-04-19 09:11:55.0 + @@ -37,6 +37,12 @@ ifndef HOOK HOOK=$(BASEDIR)/tools/$(CODENAME).hook endif +ifndef ARCHIVE_KEYRING_PACKAGE +ARCHIVE_KEYRING_PACKAGE=debian-archive-keyring +endif +ifndef ARCHIVE_KEYRING_FILE +ARCHIVE_KEYRING_FILE=usr/share/keyrings/debian-archive-keyring.gpg +endif export BUILD_DATE=$(shell date -u +%Y%m%d-%H:%M) export ARCHES_NOSRC=$(shell echo $(ARCHES) | sed 's/source//') @@ -227,12 +233,12 @@ : $(ADIR)/status # Set up keyring so apt doesn't complain - @echo Setting up debian-archive-keyring - $(Q)mkdir -p $(TDIR)/debian-archive-keyring - $(Q)dpkg -x $(MIRROR)/$(shell $(which_deb) $(MIRROR) $(CODENAME) debian-archive-keyring) $(TDIR)/debian-archive-keyring + @echo Setting up archive-keyring + $(Q)mkdir -p $(TDIR)/archive-keyring + $(Q)dpkg -x $(MIRROR)/$(shell $(which_deb) $(MIRROR) $(CODENAME) $(ARCHIVE_KEYRING_PACKAGE)) $(TDIR)/archive-keyring $(Q)for ARCH in $(ARCHES); do \ mkdir -p $(ADIR)/$(CODENAME)-$$ARCH/apt/trusted.gpg.d; \ - ln -s $(TDIR)/debian-archive-keyring/usr/share/keyrings/* $(ADIR)/$(CODENAME)-$$ARCH/apt/trusted.gpg.d; \ + ln -s $(TDIR)/archive-keyring/$(ARCHIVE_KEYRING_FILE) $(ADIR)/$(CODENAME)-$$ARCH/apt/trusted.gpg.d; \ done # Updating the apt database
Bug#674213: gpsdrive: not installable in sid
Hi, It's too late for wheezy, but I will cut a new upstream version from svn (just one.last.commit I'd like to get in), it's been pretty stable for a while, must be about time to do it. :) I believe the patches for 2.11 are too much, most of the recent development has been me putting out small fires / keeping up with API changes in dependency libs rather than new features.. The old version needs to be put to rest. for a reference vision of what the modern version looks like when firing on all cylinders, with live OpenStreetMap tile rendering from a PostGIS database and Mapnik rendering engine, see http:// live.osgeo.org (based on ubu 12.04, I just rebuilt the pkgs for that with all the latest fixes). regards, Hamish -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705168: Wheezy fails to boot linux/3.2.41-2 kernel
I'm also affected by this bug. lspci | grep VGA 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200] 02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 LE [Radeon HD 3450] Removing the discrete video card makes the KMS work again. -- Rafał Rutkowski -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705722: [xml/sgml-pkgs] Bug#705722: libxml2: CVE-2013-1969
Hi Aron On Fri, Apr 19, 2013 at 05:29:59PM +0800, Aron Xu wrote: found 705722 2.9.0+dfsg1-4 thanks I think this bug only exist from 2.9.0? xmlBufGetInputBase() does not exist before that. Thanks a lot for your quick checking and marking version accordingly. (I did not check the version in unstable good enough) Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680272: I would like this functionality too
Is there anything that would make mkudffs incompatible with symlinking to mkfs.udf? signature.asc Description: OpenPGP digital signature
Bug#705737: libxml-sax-expat-perl: should recommend libxml-sax-expatxs-perl
Package: libxml-sax-expat-perl Version: 0.40-2 Severity: normal Seems to me that this modules should recommend its XS extension. - Jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477461: grep: incorrect display with color and wrapping in some terminals
Control: retitle -1 grep: incorrect display with color and wrapping in some terminals I've reported the problem here: http://lists.gnu.org/archive/html/bug-grep/2013-04/msg1.html -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705738: pycocuma: vcard v3.0 format not standard
Package: pycocuma Version: 0.4.5-6-7 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** In wikipedia I see: vCard defines the following property types. VERSION The version of the vCard specification. In versions 3.0 and 4.0, this must come right after the BEGIN property. VERSION:3.0 pycocuma don't put VERSION right after hte BEGIN property. Mocilla icedove fails when import contacts. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (700, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pycocuma depends on: ii python 2.7.3-4 ii python-pmw 1.3.2-6 ii python-tk 2.7.3-1 ii python2.6 2.6.8-1.1 ii python2.7 2.7.3-6 Versions of packages pycocuma recommends: ii python-imaging-tk 1.1.7-4 Versions of packages pycocuma suggests: ii texlive-latex-extra 2012.20120611-2 pn xpdf-reader none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705711: linux-image-2.6.32-5-686: AMD A6-3500 APU with Radeon HD 6530D not supported
Hello Ben. JFYI with apt-get install -t squeeze-backports linux-image-686 firmware-linux xorg libdrm2 libdrm-radeon1 libgl1-mesa-glx it worked although with the FBDEV driver; the Radeon driver loads first but doesn't say anything about not supporting it, it just unloads and then VESA refuses to load because it detects KMS, so then is the FBDEV turn that uses the FBDev API exposed by the KMS driver and it works. Is good enough for office work so I am ok. Maybe this info could help someone else with the same problem on Squeeze. If you know or have some tip to try to load the Radeon driver let me know, but it isn't too important for me at least. Thanks a lot! El 18/04/13 20:12, Ben Hutchings escribió: Control: tag -1 wontfix On Thu, Apr 18, 2013 at 07:09:03PM -0300, Ivan Baldo wrote: Package: linux-2.6 Version: 2.6.32-46 Severity: wishlist Tags: squeeze This is just to let you know. I don't know if a backport to support that driver is worthwhile or not, complex or trivial, etc... The VESA driver is unstable, sometimes X starts, sometimes not, when it starts it doesn't support the monitors native resolution. Thanks for your consideration! Happy hacking! Sorry, it won't be possible to add any new graphics hardware support to 'squeeze'. The kernel and X packages in squeeze-backports might support this hardware properly; otherwise try Debian 7.0 'wheezy' which will be released very shortly. Ben. -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679806: scim-pinyin-0.5.92 uploaded to mentors
Dear Ximin, Thanks a lot for your inputs. I have version bumped scim-pinyin to 0.5.92, which includes tzhuan's patch upstream. Lintian warnings were killed. Please have another look: https://mentors.debian.net/package/scim-pinyin @Ming Hua, are you still interested in maintaining this package? @Aoki-san and Anthony, would you like to help upload the revised package? If it is okay, I'd like to produce a patch against git://git.debian.org/collab-maint/scim-pinyin.git Thanks a lot dudes. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703061: mongodb: Enable building on kfreebsd
I hope to spend some time looking into this matter this weekend. Thanks for the pointer to the source repository. Jeff signature.asc Description: Digital signature
Bug#705615: unattended-upgrades: Exception when combining --dry-run with --verbose or --debug
On Wed, Apr 17, 2013 at 04:06:30PM +0200, Bernhard Schmidt wrote: Package: unattended-upgrades Version: 0.80~exp2 Severity: normal Tags: patch Thanks for your bugreport. When combining the new --verbose option (or the already existing --debug) in experimental with --dry-run you get one (actually two) backtraces. [..] The uninitialized variable is already known and easily fixed by http://bazaar.launchpad.net/~unattended-upgrades-developers/unattended-upgrades/trunk/revision/267 Yeah, this should be ready and will be part of the next upload. However, the other error still exists and creates weird issues, like continuing output while unattended-upgrades has already exited. [..] I _think_ it is fixed by the attached patch, but I'm not really familiar with the code. Very nice! Thanks a bunch. I merged this (with a tiny tweak) and it will be part of the next upload. If you want/have time I would be keen to get feedback on the current version in trunk (bzr get lp:unattended-upgrades). It sports python3 compatibility (i.e. it can run under both py2 and py3). But that required some churn in the code so a bit of addtitional real-world testing would be great :) Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682413: you can recompile kernel with synaptic_usb disabled
I mailed Jan about that issue. One workaround is to recompile the kernel with synaptic_usb disabled (CONFIG_MOUSE_SYNAPTICS_USB). Then Trackpoint feeling is back to normal, even if the solution is ugly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705739: ruby-capybara: please enable Selenium::WebDriver support
Package: ruby-capybara Version: 2.0.2-1 Severity: wishlist Control: block -1 by 703492 The `:selenium` driver is currently disabled in the Debian package for Capybara. It should be enabled once the `selenium-webdriver` gem is packaged. -- Jérémy Bobbio.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#659318: gnome-shell: Can not open system setting from the option in the right-top corner popup
I had the same issue with opening the system settings. It turned out that the gnome-control-center had been uninstalled at some point and after installing it again everything is back to normal. I have no idea why the gnome-control-center got uninstalled, maybe some update caused it. Best regards, Emil Goode -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705740: gprolog: update to newer version
Package: gprolog Version: 1.3.0-6.1 Severity: wishlist Hello, Would it be possible to update gprolog to the newest version? The latest is 1.4.3 and has beside some bugfixes in clpfd also several new predicates like between/3, forall/2 and maplist/2 which I use in a compat module for it. I compiled it on amd64 and powerpc on which it runs without any problems. Thanks, Kind regards, Axel Scheepers -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.8.8 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages gprolog depends on: ii libc6 2.13-38 Versions of packages gprolog recommends: ii gprolog-doc 1.3.0-6.1 gprolog suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690934: closed by Thomas Hood jdth...@gmail.com (False positive)
Control: reopen -1 Hi, This is a false positive. /etc/default/dhcpcd is sourced from /sbin/dhcpcd3 which shebangs bash, not sh. Like I wrote in the original report: (yeah, incorrect reason, but still not acceptable) Quoting policy section 9.3.2[1]: It must contain only variable settings and comments in SUSv3 sh format. [1]http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init Cheers, -- Raphael Geissert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
Hi Johan, Am 19.04.2013 11:04, schrieb Johan Hovold: This was a log with lost data. The logs seems to make politics. ;-) Then the problem is most likely not in the driver as the characters are being read back in the log you provided. Stop - it's really possible that i send not enough bytes. Sometimes up to 6 Bytes will come back. This time i send this string (3.2.0): 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n I get back the first 3 Bytes of it. Log is attached. Before closing the connection Perl sends a 'stty -aF /dev/ttyUSB0' and prints the result: speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 16; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke canonical-mode is not enabled and I get back 3 bytes - so data is not lost complete. With cutecom it's -icanon also. So everything should be fine. There are 2 beasty questions left: 1. Why it works with PL2303H ? 2. Why i receive sometimes the first bytes? Now that you have compiled your own kernel, you could run a git bisect to learn if anything else has changed in the kernel (possibly interacting with your test setup) which can explain why things stopped working. I learned much in kernel testing the last time ... :-) Maybe there is a HowTo for the bisect testing? Your kernel is not configured to use dynamic debugging. You need to enable CONFIG_DYNAMIC_DEBUG=y. Oh - then i must compile again. I found # CONFIG_DYNAMIC_DEBUG is not set in .config. Johan Karsten [ 1443.104346] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_install [ 1443.104363] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_open - port 0 [ 1443.104366] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - port 0 [ 1443.104581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0 0 [ 1443.106606] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0 0 [ 1443.106619] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - port 0 [ 1443.108584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 1443.108594] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8 [ 1443.108603] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud requested = 9600 [ 1443.108611] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud set = 9600 [ 1443.108618] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1 [ 1443.108625] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none [ 1443.110595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x21:0x20:0:0 7 [ 1443.112584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 1443.114595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0 0 [ 1443.114605] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb [ 1443.114627] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb [ 1443.116581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0 [ 1443.116821] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1443.116832] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 1443.116841] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 1443.116903] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1443.116913] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
Bug#705741: libkhtml5: Cyrillic letter 'л' works like 'Esc' in google search line
Package: libkhtml5 Version: 4:4.8.4-4 Severity: minor Tags: upstream Dear Maintainer, open url http://www.google.com/search?q=test, click on search line, then switch to russian or ukrainian keyboard layout and press letter 'л' (on latin 'k' key; copy-pasting does not work). Expected Results: The software should write letter 'л', when I press it. Actual results: The cursor disappeers, it looks like 'л' acts as ESC key. This bug was instroduced in KDE 4.7 and affects current testing. This is upstream bug: https://bugs.kde.org/show_bug.cgi?id=294479 -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libkhtml5 depends on: ii libc62.13-38 ii libgcc1 1:4.7.2-5 ii libgif4 4.1.6-10 ii libjpeg8 8d-1 ii libkdecore5 4:4.8.4-4 ii libkdeui54:4.8.4-4 ii libkio5 4:4.8.4-4 ii libkjsapi4 4:4.8.4-4 ii libkparts4 4:4.8.4-4 ii libktexteditor4 4:4.8.4-4 ii libphonon4 4:4.6.0.0-3 ii libpng12-0 1.2.49-1 iu libqt4-dbus 4:4.8.2+dfsg-11 iu libqt4-network 4:4.8.2+dfsg-11 iu libqt4-xml 4:4.8.2+dfsg-11 iu libqtcore4 4:4.8.2+dfsg-11 iu libqtgui44:4.8.2+dfsg-11 ii libstdc++6 4.7.2-5 ii libx11-6 2:1.5.0-1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages libkhtml5 recommends: ii kdelibs5-plugins 4:4.8.4-4 libkhtml5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705742: libanyevent-perl: should recommend (not suggest) libev-perl and libguard-perl for seemless speed gain
Package: libanyevent-perl Version: 7.040-1 Severity: normal libanyevent-perl currently suggests libev-perl and libguard-perl. The RECOMMENDED/OPTIONAL MODULES section of AnyEvent pod seems to say that those modules are recommended rather than just suggested, as they provide speed gains for most situations. For other situations either libasync-interrupt-perl or libev-perl provides speed gain, so arguably the following is best: Recommends: libasync-interrupt-perl | libasync-interrupt-perl, libev-perl, libguard-perl - Jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705737: libxml-sax-expat-perl: should recommend libxml-sax-expatxs-perl
On Fri, 19 Apr 2013 13:37:56 +0200, Jonas Smedegaard wrote: Seems to me that this modules should recommend its XS extension. Recommend as in Recommends: in d/control (which won't make it used automagically) or as in recommended in the long description (which also doesn't actually do anything :))? Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Nick Drake: Hanging on a Star signature.asc Description: Digital signature
Bug#705744: libanyevent-perl: Please document Suggests in long description
Package: libanyevent-perl Version: 7.040-1 Severity: minor libanyevent-perl suggests a range of other Perl modules, which seems to correspond with the RECOMMENDED/OPTIONAL MODULES pod section. Please consider adding a paragraph briefly mentioning the reason for the suggested packages (as arguably a should in Debian Policy §3.4). - Jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705742: libanyevent-perl: should recommend (not suggest) libev-perl and libguard-perl for seemless speed gain
On Fri, 19 Apr 2013 14:29:58 +0200, Jonas Smedegaard wrote: libanyevent-perl currently suggests libev-perl and libguard-perl. The RECOMMENDED/OPTIONAL MODULES section of AnyEvent pod seems to say that those modules are recommended rather than just suggested, as they provide speed gains for most situations. Ok. For other situations either libasync-interrupt-perl or libev-perl provides speed gain, so arguably the following is best: Recommends: libasync-interrupt-perl | libasync-interrupt-perl, libev-perl, libguard-perl Hm? Did you mean Recommends: libasync-interrupt-perl | libev-perl, libasync-interrupt-perl | libguard-perl ? Alternatively we could also just add all three to Recommends without alternatives. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: The Doors: I Looked At You signature.asc Description: Digital signature
Bug#538067: Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
Hi Hamish, On Fri, Apr 19, 2013 at 03:10:20AM -0700, Hamish wrote: Do you need a sponsor for your work? if you have any spare time, I've been trying to get the finalized OpenCPN package sponsored by someone for almost a year.. (ITP# 538067) Uhmm! That's a real shame. My main point behind the Blends concept was to create teams inside Debian who work together in specific user interests. This fact proves somehow my suspicion that this idea is not fully implemented in Debian GIS. To stick to my word from regarding Sponsering of Blends I see that both criterions are fullfilled: a) http://svn.debian.org/viewsvn/pkg-grass/packages/opencpn/ b) http://blends.alioth.debian.org/gis/tasks/workstation#opencpn and so here I am having a look: $ uscan --verbose --force-download -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: opts=dversionmangle=s/\+dfsg// http://sf.net/opencpn/OpenCPN-([\d\.]+)-Source\.tar\.gz -- Found the following matching hrefs: OpenCPN-3.2.0-Source.tar.gz OpenCPN-3.0.0-Source.tar.gz OpenCPN-2.5.0-Source.tar.gz OpenCPN-2.3.1-Source.tar.gz OpenCPN-2.3.0-Source.tar.gz Newest version on remote site is 3.2.0, local version is 2.5.0+dfsg (mangled local version number 2.5.0) = Forcing download as requested -- Downloading updated package OpenCPN-3.2.0-Source.tar.gz I just want to know whether upstream has just moved forward over this longish (and admittedly frustrating time for you) or whether you intentionally decided to package 2.5.0. I would not question the later because I admit I'm not that deep into GIS to know the differences but before I go on sponsering I want to make sure I'll grab the right package. Moreover you have injected a +dfsg suffix that lets me assume you are repackaging upstream tarball for some reason. Usually this is accompanied by some get-orig-source target in debian/rules to enable others reproducing this step. If it is simply about removing some files you might like to follow the uscan enhancement I proposed[1] which does simplify this process for the developer and makes it more transparent. As far as I can see (at least from downloading 3.2.0 source) the binary without source in wxWidgets should be removed. Reading #538067 log it seems that the images without license issue might be solved - but I have not yet inspected the tarball deeply. I also noticed that you have put some MD5SUM files into the tarballs directory in SVN. Please note that it is close to impossible to have MD5SUM identical tarballs when changing anything in a tarball. (There was some relevant discussion on debian-devel@l.d.o.) In other words: Somebody who re-runs your (to be provided) get-orig-source target will get a different MD5SUM (even if the untared dirs are byte identical). In short: If you want your sponsor using the same tarball as you it is better to provide a link[2] or use mentors.debian.net. I for myself (and in Debian Med team in general - Debian GIS might be different) prefer a recipe who to recreate the tarball. Regarding your packaging: debian/rules: I have read in the log of #538067 you were advised to remove third party code in override_dh_auto_configure: Just for the record: I do not fully support this way because the package will fail to build twice in a row because of the removed files. So the cleanest way would be to move the files in override_dh_auto_configure: out of the way and restore them if needed in override_dh_auto_clean:. I will not insist on this nitpicking, just mentioning it. I noticed your commented flags to enable hardening. IMHO you could safe a lot of this stuff by using debhelper compat level 9 which cares for hardening automatically. I was able to build the package with no lintian issues (except hardening) and if you confirm the proper version you want me to sponser I would have a more detailed look. I'd pretty much given up trying until the release freeze was over, the fastest option was looking like me going through the DD process myself. I wished people would not have a reason to give up. Becoming a DM (first DM than DD) is a good idea anyway. Kind regards Andreas. [1] https://wiki.debian.org/UscanEnhancements [2] http://pkg-grass.alioth.debian.org/tarballs/opencpn_2.5.0+dfsg.orig.tar.gz -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705745: Please add resolvconf dpkg-event hook script
Package: dhcpcd
Severity: wishlist
Please add the hook script /usr/lib/resolvconf/dpkg-event.d/dhcpcd
The purpose this script is to cause dhcpcd to take notice of the
installation (or removal) of the resolvconf package. If resolvconf
has been installed then dhcpcd should register with resolvconf
IP addresses of nameservers that dhcpcd has obtained during
DHCP negotiation.
See below for an except from resolvconf's README file giving
general information about resolvconf dpkg-event hook scripts.
For a DHCP client the simplest way to implement this might be
for the dpkg-event hook script, on resolvconf install, to trigger
the client to renegotiate the lease.
Usage information for maintainers
~
[...] All suppliers of
nameserver information should supply their information to resolvconf after
resolvconf has been installed.
As of resolvconf release 1.55 this is supported via the following mechanism.
Any package, foo, that supports supplying information to resolvconf should
include a hook script /usr/lib/resolvconf/dpkg-event.d/foo which, when
called
with the argument install, takes whatever actions are necessary to cause
the program(s) in foo to supply their nameserver information to resolvconf;
and when called with the argument remove takes whatever actions are
appropriate given that the resolvconf package has been removed (and,
in being removed, may have removed foo's nameserver information).
The hook script thus has the following form.
#!/bin/sh
#
# /usr/lib/resolvconf/dpkg-event.d/foo
#
# The resolvconf dpkg-event hook script for the foo package
#
if foo_is_running ; then
if [ $1 = install ] ; then
foo-ctrl send-nameserver-info-to-resolvconf
elif [ $1 = remove ] ; then
...
fi
fi
If foo is controlled by an initscript whose methods take appropriate actions
conditional upon resolvconf's presence then something like the following
might be appropriate.
force_reload_foo() {
if which invoke-rc.d /dev/null 21 ; then
invoke-rc.d foo force-reload
elif [ -x /etc/init.d/foo ] ; then
/etc/init.d/foo force-reload
fi
}
case $1 in
install|remove) force_reload_foo ;;
esac
The hook script is called (with argument install) from resolvconf's
postinst
configure method and (with remove) from resolvconf's postrm remove
method.
Foo's hook script is called with argument install if and only if foo is
fully installed both when resolvconf's preinst install runs and when its
postinst configure runs. The hook script is called with argument remove
if and only if foo is fully installed when resolvconf's postrm remove runs.
The hook script must be owned by root and have its execute permission
bit set and must have the same name as the package that owns it.
Arguments other than install and remove are reserved for future use
and must be silently ignored.
Bug#705746: cp2k: wrong basis set definition for 6-31++G** basis sets
Package: cp2k Version: 2.2.426-1 Severity: serious Tags: patch A problem has been been found today with the 6-31++G** version of the standard EMSL basis sets, which will lead to wrong results. The problem has been fixed in upstream revision 12850: http://sourceforge.net/p/cp2k/code/12850/ Michael On Fri, Apr 19, 2013 at 10:49:14AM +0200, hut...@pci.uzh.ch wrote: Dear Frank thank you very much for pointing out this problem. All basis sets in EMSL_BASIS_SETS of the 6-31++G** type are missing the difuse set, meaning they are identical to 6-31G**. I think the 6-311++G** sets are correct. We will have to correct this. best regards Juerg -- Juerg Hutter Phone : ++41 44 635 4491 Physical Chemistry Institute FAX : ++41 44 635 6838 University of Zurich E-mail: hut...@pci.uzh.ch Winterthurerstrasse 190 CH-8057 Zurich, Switzerland --- -c...@googlegroups.com wrote: - To: c...@googlegroups.com From: Frank Uhlig Sent by: c...@googlegroups.com Date: 04/19/2013 09:56AM Subject: [CP2K:4380] Inconsistency in EMSL basis sets (missing basis function in oxygen 6-31++G** basis set) Dear CP2K'lers, I was performing a test calculation on a water dimer with CP2K/B3LYP/6-31++G** setup and observed a 40% relative error in the interaction energy compared to different traditional quantum chemistry package. After a long and tedious search for the inconsistency in my setup, I found that there is a basis function function missing in the CP2K provided basis set file (SP, exponent 0.0845000) compared to the one directly provided on the EMSL web page (see below). After including latter in the CP2K basis set definition, the relative error in the interaction energy for the water dimer is smaller than 1%, which is of course more than acceptable. Is there any specific reason for this inconsistency? I have not checked all the basis sets, but also for the fluorine 6-31++G** basis set one basis function is missing compared to EMSL. Cheers, Frank from EMSL_BASIS_SETS: O 6-31++Gxx 6-31++G** 4 1 0 0 6 1 5484.6717 0.00183110 825.23495000 0.01395010 188.04696000 0.06844510 52.9645 0.23271430 16.89757000 0.47019300 5.79963530 0.35852090 1 0 1 3 1 1 15.53961600 -0.11077750 0.07087430 3.59993360 -0.14802630 0.33975280 1.01376180 1.13076700 0.72715860 1 0 1 1 1 1 0.27000580 1. 1. 1 2 2 1 1 0.8000 1. directly from EMSL basis set exchange (NWChem format): BASIS ao basis PRINT #BASIS SET: (11s,5p,1d) - [4s,3p,1d] O S 5484.6717000 0.0018311 825.2349500 0.0139501 188.0469600 0.0684451 52.9645000 0.2327143 16.8975700 0.4701930 5.7996353 0.3585209 O SP 15.5396160 -0.1107775 0.0708743 3.5999336 -0.1480263 0.3397528 1.0137618 1.1307670 0.7271586 O SP 0.2700058 1.000 1.000 O SP 0.0845000 1.000 1.000 O D 0.800 1.000 END -- You received this message because you are subscribed to the Google Groups cp2k group. To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+unsubscr...@googlegroups.com. To post to this group, send email to c...@googlegroups.com. Visit this group at http://groups.google.com/group/cp2k?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups cp2k group. To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+unsubscr...@googlegroups.com. To post to this group, send email to c...@googlegroups.com. Visit this group at http://groups.google.com/group/cp2k?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705747: qutecom: QuteCom creates srtp.log file in $HOME
Package: qutecom Version: 2.2.1+dfsg1-3+b1 Severity: minor Dear Maintainer, whenever I perform a call with QuteCom, it creates an empty file called srtp.log in my $HOME. That's quite annoying, a program should not create visible files in my home directory unless it is asked to do so. I did not even find a way to configure this in the options. If the logfile is really useful, it should be put, for example, in the XDG data directory. Kind regards, Ralf -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.7 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qutecom depends on: ii libasound2 1.0.25-4 ii libavcodec-extra-53 6:0.8.6-1 ii libavutil51 6:0.8.6-1 ii libboost-program-options1.49.0 1.49.0-3.2 ii libboost-serialization1.49.01.49.0-3.2 ii libboost-signals1.49.0 1.49.0-3.2 ii libboost-thread1.49.0 1.49.0-3.2 ii libc6 2.13-38 ii libcurl37.26.0-1+wheezy2 ii libgcc1 1:4.7.2-5 ii libglib2.0-02.33.12+really2.32.4-5 ii libpurple0 2.10.6-3 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-network 4:4.8.2+dfsg-11 ii libqt4-svg 4:4.8.2+dfsg-11 ii libqt4-xml 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libqtwebkit42.2.1-5 ii libsamplerate0 0.1.8-5 ii libsndfile1 1.0.25-5 ii libspeex1 1.2~rc1-7 ii libssl1.0.0 1.0.1e-2 ii libstdc++6 4.7.2-5 ii libswscale2 6:0.8.6-1 ii libtinyxml2.6.2 2.6.2-1 ii libuuid12.20.1-5.3 ii libx11-62:1.5.0-1 ii qutecom-data2.2.1+dfsg1-3 qutecom recommends no packages. qutecom suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705748: missing CIFS support on install
Package: n/a Version: n/a When installing i.e. debian-live-6.0.6-i386-gnome-desktop.iso debian-live-6.0.6-amd64-gnome-desktop.iso etc... /live/initrd.img does not include CIFS support CIFS is very handy when PXE booting Debian live from Windows OSs as Serva does it here. http://vercot.com/~serva/an/NonWindowsPXE3.html Serva solves the problem by loading a complementary initrd containing/installing: des_generic.ko md4.ko cifs.ko mount.cif these files are all originally taken from the corresponding filesystem.squashfs Serva also patches /script/live adding support for the command line variable ipby,i.e. ipby=dhcp, ipby=bootp, solving some problems with some DHCP servers I hope you guys can add CIFS support on future Debian install systems then Windows users will not need complementary initrd files when PXE booting Debian. Please let me know if I wasn't clear enough on my description. Best, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703431: Annoying GPG error message
Hi, On Fri, 19 Apr 2013, Robert Spencer wrote: This still requires that the keyring be installed on the system whereas we're already extracting it from the binary package in debian-cd. I'm sorry, I didn't misunderstand you. I made a bad assumption. I hope the attached patch file is satisfactory. Yes, it's mostly OK. I committed it. +# Keyring (defaults): +#ARCHIVE_KEYRING_PACKAGE=debian-archive-keyring +# The path to the keyring file relative to $TDIR/archive-keyring/ +#ARCHIVE_KEYRING_FILE=usr/share/keyrings/debian-archive-keyring.gpg + # By default we use debootstrap --no-check-gpg to find out the minimal set # of packages because there's no reason to not trust the local mirror. But # you can be paranoid and then you need to indicate the keyring to use to # validate the mirror. -#export DEBOOTSTRAP_OPTS=--keyring /usr/share/keyrings/debian-archive-keyring.gpg +#export DEBOOTSTRAP_OPTS=--keyring $TDIR/archive-keyring/$ARCHIVE_KEYRING_FILE This hardcodes TDIR and ARCHIVE_KEYRING_FILE in a second parameter and makes it impossible to do stuff like this (assuming that you have uncommented DEBOOTSTRAP_OPTS): $ . CONF.sh $ export TDIR=/tmp/debian-cd But I guess it's not a big deal. At least it documents the value that you're expected to set if you want to use it. Thanks again! -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705731: firehol uploaded to mentors.debian.net
On 2013-04-19 12:18, Jerome BENOIT wrote: | Hello Jari, | | I have just uploaded my last version of the firehol debian package | which your recent bug report. Good. I went through all the closed bug reports and updated Debian BTS for missing patch tags. Here are couple of minor updates: 1. Patch: a small gesture to mention people that have helped. 2. Patch: clean up whitespaces Thanks, JariFrom 042d7ba3f193f65cf67b274d357bd5b305ea05dd Mon Sep 17 00:00:00 2001 From: Jari Aalto jari.aa...@cante.net Date: Fri, 19 Apr 2013 15:56:17 +0300 Subject: [PATCH 1/2] debian/changelog: Credit people that have helped by sending patches Organization: Private Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jari Aalto jari.aa...@cante.net --- debian/changelog | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/debian/changelog b/debian/changelog index 0fd5a26..7e912dd 100644 --- a/debian/changelog +++ b/debian/changelog @@ -3,11 +3,15 @@ firehol (1.296-1) unstable; urgency=low * New maintainer (Closes: #660524). * New upstream version (Closes: #607785). - Removed depedency to get-iana.sh and to RESERVED_IPS - (Closes: #583176, #565737, #574458, #598324, #455754, #536609, #558288) + (Closes: #583176, #565737, #574458, #598324, #455754, #536609, #558288). + For #536609 patch thanks to Cristian Ionescu-Idbohrn + cristian.ionescu-idbo...@axis.com. For #583176 patch thanks to + Adrian Bridgett adr...@smop.co.uk. - Updated documentations (Closes: #571727) - Improved kernel modules management (Closes: #610249) - Simplified quoting in log prefix (Closes: #443051) (LP: #253843) -- Minor improvements and fixes (Closes: #563655) +- Passive FTP fix (Closes: #563655). Patch thanks to + Toni Mueller supp...@oeko.net. * Update to source format 3.0 (quilt). * Bump debhelper build-dep to = 9. * Bump Standards Version to 3.9.4. @@ -30,9 +34,10 @@ firehol (1.296-1) unstable; urgency=low thanks to Phil Whineray for hardening the original RedHat patch. * Temporary files are now left behind in case of error (Closes: #703341), thanks to Phil Whineray who backported the sanewall patch to FireHOL. - * `panic' option has been rationalized (Closes: #536675), -thanks to Andrew Schulman and Phil Whineray. - * Standard patch naming (Closes: #705731). + * `panic' option has been rationalized (Closes: #536675). Patch +thanks to Andrew Schulman. Also thanks to Phil Whineray. + * Use standard *.patch naming suffix (Closes: #705731). Patch thanks to +Jari Aalto jari.aa...@cante.net. -- Jerome Benoit calcu...@rezozer.net Fri, 19 Apr 2013 10:01:21 + -- 1.7.10.4 From 4a7c6196ae337b9933fec96cb55fec391656b31d Mon Sep 17 00:00:00 2001 From: Jari Aalto jari.aa...@cante.net Date: Fri, 19 Apr 2013 16:03:51 +0300 Subject: [PATCH 2/2] Clean up whitespaces Organization: Private Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jari Aalto jari.aa...@cante.net --- debian/NEWS|2 +- debian/README.Debian |8 debian/README.Services |7 +++ debian/changelog | 28 ++-- debian/firehol.init|2 +- debian/get-iana.1 |6 +++--- debian/get-iana.1.txt | 12 ++-- 7 files changed, 32 insertions(+), 33 deletions(-) diff --git a/debian/NEWS b/debian/NEWS index 80afd77..de0f391 100644 --- a/debian/NEWS +++ b/debian/NEWS @@ -18,6 +18,6 @@ firehol (1.256-1) unstable; urgency=low the lib. That will make updates much easier in the future. get-iana (a script for updating the list of reserved ips) is now available you can run it regulary to update your ip list. Its recommended to install - the aggregate package to aggregate the ip ranges from the iana. + the aggregate package to aggregate the ip ranges from the iana. -- Alexander Wirt formo...@debian.org Thu, 30 Aug 2007 17:18:22 +0200 diff --git a/debian/README.Debian b/debian/README.Debian index 3349b1d..b78d6f4 100644 --- a/debian/README.Debian +++ b/debian/README.Debian @@ -1,13 +1,13 @@ firehol for Debian GNU/Linux -You have to enable firehol in /etc/default/firehol to +You have to enable firehol in /etc/default/firehol to get firehol starting. To enable it set START_FIREHOL to anything -else than NO/no. +else than NO/no. You should also give firehol-wizard a try for generating -a starting configuration. To launch firehol-wizard just start /sbin/firehol -with the wizard parameter (/sbin/firehol wizard). +a starting configuration. To launch firehol-wizard just start /sbin/firehol +with the wizard parameter (/sbin/firehol wizard). If you want to have firehol waiting until a device is up before it proceeds the firewall rules you can add it in WAIT_FOR_IFACE diff --git a/debian/README.Services b/debian/README.Services index ed224c3..b454eb4
Bug#705737: libxml-sax-expat-perl: should recommend libxml-sax-expatxs-perl
Quoting gregor herrmann (2013-04-19 14:34:41) On Fri, 19 Apr 2013 13:37:56 +0200, Jonas Smedegaard wrote: Seems to me that this modules should recommend its XS extension. Recommend as in Recommends: in d/control (which won't make it used automagically) or as in recommended in the long description (which also doesn't actually do anything :))? Recommends: in control file. As I understand its documented behaviour, AnyEvent _does_ automagically benefit from those modules being available. EV is a backend. AnyEvent tries to pick best one available if none is declared explicitly, and RECOMMENDED/OPTIONAL MODULES hints at EV being the best one available. Async::Interrupt is according to RECOMMENDED/OPTIONAL MODULES used if available, for backends without a native signal watchers, as a better alternative to the builtin polling-each-10-seconds. Guards is documented to be used when used - but I suspect that to be a typo and really it is used when available (like Async::Interrupt). I have not investigated the actual AnyEvent code, though, so you might be right and instead the documentation is IMO misleading. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705737: libxml-sax-expat-perl: should recommend libxml-sax-expatxs-perl
Quoting Jonas Smedegaard (2013-04-19 15:11:19) Quoting gregor herrmann (2013-04-19 14:34:41) On Fri, 19 Apr 2013 13:37:56 +0200, Jonas Smedegaard wrote: Seems to me that this modules should recommend its XS extension. Recommend as in Recommends: in d/control (which won't make it used automagically) or as in recommended in the long description (which also doesn't actually do anything :))? Recommends: in control file. Arrgh - silly me: I am talking about a different bugreport :-/ You are most probably right that there is no automagic speedup. Makes sense to then only suggest it, dont you think? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705742: libanyevent-perl: should recommend (not suggest) libev-perl and libguard-perl for seemless speed gain
Quoting gregor herrmann (2013-04-19 14:40:43) On Fri, 19 Apr 2013 14:29:58 +0200, Jonas Smedegaard wrote: For other situations either libasync-interrupt-perl or libev-perl provides speed gain, so arguably the following is best: Recommends: libasync-interrupt-perl | libasync-interrupt-perl, libev-perl, libguard-perl Hm? Did you mean Recommends: libasync-interrupt-perl | libev-perl, libasync-interrupt-perl | libguard-perl ? Yes, that's exactly what I meant. Thanks for reading my mind :-D Alternatively we could also just add all three to Recommends without alternatives. Only when EV is _not_ available and used is there a benefit of having Async::Interrupt available. ...but then again, that means for the cases of explicitly using a different backend it is beneficial to have Async::Interrupt available. So yes, I think it is best to plain recommend each of them - even if Async::Interrupt won't actually be _used_ in most cases. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705749: DHCP returns IP lease when wrong mask when the MAC is already registered in a different subnet
Package: isc-dhcp-server Version: 4.2.2.dfsg.1-5+deb70u3 When we place a computer in a different network with allows unknow clients, the IP comes right, however the netmask comes from the subnet where the MAC is registered. If we delete the MAC or different MAC which is not registered in any subnet, that doesn't happen. I am using Debian 7.0, 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux. Best regards, Rui Ribeiro -- Rui Ribeiro Linux Sysadmin Network administrator / SI ISCTE-IUL http://www.linkedin.com/profile/view?id=56478568 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705750: python-uniconvertor: Running uniconvertor fails (TypeError: integer argument expected, got float)
Package: python-uniconvertor
Version: 1.1.4-1+b2
Severity: normal
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
calling from command line:
$ uniconvertor in.cdr out.pdf
Also when trying to import a cdr file from inkscape,
uniconvertor gives an error message. According to this
forum entry, it is due to a broken packaging:
http://sk1project.org/forum/viewthread.php?thread_id=472pid=1108#post_1108
* What was the outcome of this action?
Cannot list directory /home/foo/.uniconvertor:[Errno 2] No such file or
directory: '/home/foo/.uniconvertor'
ignoring it in font_path
Cannot list directory /home/foo/.uniconvertor:[Errno 2] No such file or
directory: '/home/foo/.uniconvertor'
ignoring it in font_path
No plugin-type information in
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/__init__.py
Traceback (most recent call last):
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 683, in Load
self.info.process_properties()
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 260, in process_properties
self.process_paths(chunk)
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 342, in process_paths
self.loda_type_func[argtype](chunk,type,offset,cdr_version,trafo)
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 495, in loda_coords
self.extract_bmp(numbmp,width,height)
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 377, in extract_bmp
self.extracted_image = PIL.Image.fromstring('L', (width, height),
self.bmpbuf, 'raw', 'L', bytes, -1)
File /usr/lib/python2.7/dist-packages/PIL/Image.py, line 1797, in fromstring
im.fromstring(data, decoder_name, args)
File /usr/lib/python2.7/dist-packages/PIL/Image.py, line 589, in fromstring
d = _getdecoder(self.mode, decoder_name, args)
File /usr/lib/python2.7/dist-packages/PIL/Image.py, line 383, in _getdecoder
return apply(decoder, (mode,) + args + extra)
TypeError: integer argument expected, got float
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib/pymodules/python2.7/uniconvertor/__init__.py, line 82, in
uniconv
doc = load.load_drawing(input_file)
File /usr/lib/pymodules/python2.7/uniconvertor/app/io/load.py, line 364, in
load_drawing
return load_drawing_from_file(file, filename)
File /usr/lib/pymodules/python2.7/uniconvertor/app/io/load.py, line 337, in
load_drawing_from_file
doc = loader.Load()
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 683, in Load
self.info.process_properties()
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 260, in process_properties
self.process_paths(chunk)
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 342, in process_paths
self.loda_type_func[argtype](chunk,type,offset,cdr_version,trafo)
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 495, in loda_coords
self.extract_bmp(numbmp,width,height)
File
/usr/lib/pymodules/python2.7/uniconvertor/app/plugins/Filters/cdrloader.py,
line 377, in extract_bmp
self.extracted_image = PIL.Image.fromstring('L', (width, height),
self.bmpbuf, 'raw', 'L', bytes, -1)
File /usr/lib/python2.7/dist-packages/PIL/Image.py, line 1797, in fromstring
im.fromstring(data, decoder_name, args)
File /usr/lib/python2.7/dist-packages/PIL/Image.py, line 589, in fromstring
d = _getdecoder(self.mode, decoder_name, args)
File /usr/lib/python2.7/dist-packages/PIL/Image.py, line 383, in _getdecoder
return apply(decoder, (mode,) + args + extra)
TypeError: integer argument expected, got float
* What outcome did you expect instead?
Less warinings, no errors, and some output file.
*** End of the template - remove these lines ***
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.6-8.slh.3-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages python-uniconvertor depends on:
ii libc6 2.13-38
ii python2.7.3-4
ii python-imaging1.1.7-4
ii python-reportlab 2.5-1.1
ii python-support1.0.15
python-uniconvertor recommends no packages.
Versions of packages python-uniconvertor suggests:
pn python-uniconvertor-dbg none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680292: gnatmake: linker arguments order incompatible with --as-needed
tags 680292 + upstream patch forwarded 680292 http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01132.html thanks Am 04.07.2012 22:16, schrieb Nicolas Boulenguez: Package: gnat-4.6 Version: 4.6.3-4 Severity: minor Hello. Gnatmake calls gcc -shared in a way incompatible with --as-needed. Gprbuild uses a better ordering. checked in a patch for 4.6, 4.7 and 4.8. should be picked with the next merge to gnat-4.x. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703584: min-size causes squid3 to fail
The min-size= configuration option was introduced in squid-3.2 and does not exist in Squid-3.1. http://www.squid-cache.org/Doc/config/cache_dir/ You will get the same error from 3.1 whenever you try to configure it with not yet invented settings. Amos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538067: Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
Andreas: My main point behind the Blends concept was to create teams inside Debian who work together in specific user interests. This fact proves somehow my suspicion that this idea is not fully implemented in Debian GIS. I think the main issue is lack of manpower. Frankie can't do it all alone. Working on Blends seems like a bonus activity to me, but there are too many fires to put out and worry about right now so it doesn't get the attention it might otherwise. shrug and so here I am having a look: $ uscan --verbose --force-download ... Newest version on remote site is 3.2.0, local version is 2.5.0+dfsg (mangled local version number 2.5.0) = Forcing download as requested -- Downloading updated package OpenCPN-3.2.0-Source.tar.gz I just want to know whether upstream has just moved forward over this longish (and admittedly frustrating time for you) or whether you intentionally decided to package 2.5.0. 2.5.0 was the new stable version which Anton and me focused on packaging. OpenCPN has had crazy success (check the SourceForge download stats, it's not VLC but for a niche software it's doing 15k+ downloads a month) http://sourceforge.net/projects/opencpn/files/opencpn/stats/timeline?dates=2009-04-10+to+2013-04-19 AFAIK the 2.5.0 package we made is pretty much complete and ready to go. As mentioned in the last messages of the bug report, I'd like to get 2.5.0 in as the baseline, and then proceed from there. 2.5.0 was a really good solid release. In fact I'm still using it as my day-to-day since it 'just works' for everything I need to do with it. The newer versions add OpenGL support and other changes which mean more work, dependencies, etc. I'd like have 2.5.0 as a solid delta before destabalizing the packaging effort over that. The it's ready as-is now thinking also makes me a bit anxious to get it reviewed before sid starts moving quickly and there's external breakage to deal with, resetting the clock to zero, again. before I go on sponsering I want to make sure I'll grab the right package. In the ITP report I provide the link to the dfsg tarball dir (hosted on was-alioth) and a link to the debian/ packaging rules (hosted in DebianGIS's svn on was-alioth). I'm still aiming at the same version. Moreover you have injected a +dfsg suffix that lets me assume you are repackaging upstream tarball for some reason. as noted in the ticket, the original tarball had Microsoft's Visual C++ runtime redistributable DLLs in it. we don't use that but Debian can't host a source package containing it. So that and IIRC some Mac OSX specific stuff got removed. If it is simply about removing some files you might like to follow the uscan enhancement I proposed[1] which does simplify this process for the developer and makes it more transparent. ok, will look into it, but a job for tomorrow. :) (or next week, I'm just about to jump on a boat) As far as I can see (at least from downloading 3.2.0 source) (I'm still aiming for 2.5.0 for now) the binary without source in wxWidgets should be removed. I'm not sure if that's in the 2.5.0+dfsg tarball I prepared, I'd be rather surprised if it was. (a public script creates that the tarball (and the md5sum) the way, I think it's on the alioth site, somewhere. I'm all about the automation..) Reading #538067 log it seems that the images without license issue might be solved - but I have not yet inspected the tarball deeply. AFAIK all known issues were solved. IIRC the images were by the author and he was responsive in our copyright cleanup tasks, fixing many of the issues upstream for the then-next 3.0 release. I also noticed that you have put some MD5SUM files into the tarballs directory in SVN. Please note that it is close to impossible to have MD5SUM identical tarballs when changing anything in a tarball. IIRC, I did that to provide some sort of audit trail for edits to the md5sums, since the tarball downloads (not in svn) were in a dir which was writable by many more people, with just the filesystem stat to know who replaced the file there last. In short: If you want your sponsor using the same tarball as you it is better to provide a link[2] or use mentors.debian.net. We did upload it to mentors. Twice. It just sat there. Too complicated I guess.. I for myself (and in Debian Med team in general - Debian GIS might be different) prefer a recipe who to recreate the tarball. It's there somewhere hiding in plain sight, sorry I'm out of time now or I'd hunt down the link. Regarding your packaging: debian/rules: I have read in the log of #538067 you were advised to remove third party code in override_dh_auto_configure: Just for the record: I do not fully support this way because the package will fail to build twice in a row because of the removed files. I'm pretty sure the result was multi-entrant. (was doing many iterations of testing, and I'm pretty sure I would have made it so if it was a problem.
Bug#568452: Missing symbols during armel build tentative
Am 22.05.2012 21:28, schrieb xavier grave: Hi, During a build of polyorb 2.8~20110207 on the armel architecture I get following errors : ADA_PROJECT_PATH=/home/xavier/labo_polyorb/org.debian.polyorb/projects:/home/xavier/labo_polyorb/org.debian.polyorb/projects:$ADA_PROJECT_PATH gnatmake -P polyorb_tools_po_catref.gpr --create-missing-dirs -L/home/xavier/labo_polyorb/org.debian.polyorb/lib -XLibversion=3 -XLibtype=DYNAMIC -R -j1-cargs -bargs -E gnatbind -shared -E -I- -x /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/tools/po_catref/po_catref.ali gnatlink /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/tools/po_catref/po_catref.ali -shared-libgcc -Wl,--as-needed -L/home/xavier/labo_polyorb/org.debian.polyorb/lib -R -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-setup -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-cos-time -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-cos-notification -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-cos-naming -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-dsa -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-moma -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-portableinterceptor -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-dynamicany -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-giop-miop -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-giop-iiop -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-giop-diop -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-cos-event-impl -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-cos-ir-impl -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-messaging -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-iop -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-giop -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba-cos-event -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb-corba -L/home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib/ -lpolyorb -o /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/tools/po_catref/po_catref /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib//libpolyorb-giop.so: undefined reference to `pthread_create' /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib//libpolyorb-giop.so: undefined reference to `pthread_key_create' /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib//libpolyorb-giop.so: undefined reference to `pthread_getspecific' /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib//libpolyorb-giop.so: undefined reference to `pthread_attr_setstacksize' /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib//libpolyorb-giop.so: undefined reference to `pthread_kill' /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib//libpolyorb-giop.so: undefined reference to `pthread_sigmask' /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib//libpolyorb-giop.so: undefined reference to `pthread_setspecific' /home/xavier/labo_polyorb/org.debian.polyorb/DYNAMIC/lib//libpolyorb-giop.so: undefined reference to `pthread_mutexattr_init' collect2: ld returned 1 exit status gnatlink: error when calling /usr/bin/gcc-4.6 gnatmake: *** link failed. For example the symbol pthread_mutexattr_init is present in /usr/lib/arm-linux-gnueabi/libpthread.a (found using command : nm -A /usr/lib/arm-linux-gnueabi/libpthread.* | grep pthread_mutexattr_init | grep T) but I get the same error is I add a -largs /usr/lib/arm-linux-gnueabi/libpthread.a to the build. I dug a little the debian ada list without finding any reference to such problem already arising. Does anyone with Ada/gcc experience have an idea of the source problem ? Any help welcome :) try without the --as-needed? I just sent a fix for #680292 which should fix this soonish. it looks like libpolyorb-giop.so wants linking with -pthread. So maybe pass -pthread to the link command (don't pass -lpthread directly). Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495985: Taking over the tcpdf ITP
Control: owner -1 Raphael Hertzog hert...@debian.org Hi, given nobody reacted to my last mail, I'm taking over this ITP. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568452: polyorb: package is not built on armel
Am 10.02.2010 15:44, schrieb Ludovic Brenta: retitle 568452 polyorb: please add support for armel severity 568452 wishlist thanks Given the architecture-specific problems we've had with gnat and polyorb, adding support for a new architecture is not to be taken too lightly. Given the time it takes to compile polyorb on slow architectures (e.g. 6 hours 51 minutes on hppa), an important aspect to this is the availablility of armel buildd machines. Are you prepared to build polyorb manually on your own armel machine? (also, do you really want to develop distributed applications in Ada on armel?) Two small, leaf packages that build-depend only on gnat-4.4 recently and tentatively switched to Architecture: any. The results for armel are not encouraging: libxmlezout: FTBFS: Not-For-Us (is armel in any on that buildd?) liblog4ada: FTBFS: BD-Uninstallable (is gnat-4.4 on that buildd?) I suggest we wait until we have reassurances that the buildds are really available, with gnat-4.4, before we attempt to add support for armel in more complex Ada packages. how did this picture change with armel and armhf? I see more issues with mips and mipsel these days. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705751: Doesn't work with ruby 1.8
Package: lolcat Version: 42.0.99-1 Severity: serious When /usr/bin/ruby is ruby 1.8 the program fails: $ lolcat /proc/cpuinfo /usr/lib/ruby/vendor_ruby/paint/util.rb:37:in `detect_mode': uninitialized constant Module::RbConfig (NameError) from /usr/lib/ruby/vendor_ruby/paint.rb:164:in `mode' from /usr/lib/ruby/vendor_ruby/paint.rb:87:in `[]' from /usr/lib/ruby/vendor_ruby/lolcat/lol.rb:55:in `println_plain' from /usr/games/lolcat:22:in `each_with_index' from /usr/lib/ruby/vendor_ruby/lolcat/lol.rb:54:in `chars' from /usr/lib/ruby/vendor_ruby/lolcat/lol.rb:54:in `each_with_index' from /usr/lib/ruby/vendor_ruby/lolcat/lol.rb:54:in `println_plain' from /usr/lib/ruby/vendor_ruby/lolcat/lol.rb:46:in `println' from /usr/lib/ruby/vendor_ruby/lolcat/lol.rb:36:in `cat' from /usr/lib/ruby/vendor_ruby/lolcat/lol.rb:34:in `each' from /usr/lib/ruby/vendor_ruby/lolcat/lol.rb:34:in `cat' from /usr/lib/ruby/vendor_ruby/lolcat/cat.rb:113:in `cat!' from /usr/lib/ruby/vendor_ruby/lolcat/cat.rb:107:in `each' from /usr/lib/ruby/vendor_ruby/lolcat/cat.rb:107:in `cat!' from /usr/games/lolcat:24 If I install ruby1.9.1 so that /usr/bin/ruby becomes ruby 1.9 the program works. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.0-wrar-2 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lolcat depends on: ii ruby-paint 0.8.5-1 ii ruby-trollop1.16.2-3 ii ruby1.8 [ruby-interpreter] 1.8.7.358-7 lolcat recommends no packages. lolcat suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705752: dpkg-statoverride and non-existing groups
Package: dpkg Version: 1.16.10 Hi, I came accross the issue in a chroot, but it probably also maps to non-chroot setups, though perhaps less likely. | (sid_amd64-dchroot)root@barriere:~# grep postqueue /var/lib/dpkg/statoverride | root postdrop 2555 /usr/sbin/postqueue | (sid_amd64-dchroot)root@barriere:~# dpkg-statoverride --remove /usr/sbin/postqueue | dpkg-statoverride: unrecoverable fatal error, aborting: | syntax error: unknown group 'postdrop' in statoverride file | (sid_amd64-dchroot)root@barriere:~# grep postqueue /var/lib/dpkg/statoverride | root postdrop 2555 /usr/sbin/postqueue The problem is that when a group no longer exists, dpkg-statoverride in incapable of removing the entry. Furthermore, dpkg is incapable of doing anything at all from now on: | # apt-get install vim | Reading package lists... Done | Building dependency tree | Reading state information... Done | Suggested packages: | ctags vim-doc vim-scripts | The following NEW packages will be installed: | vim | 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. | Need to get 841 kB of archives. | After this operation, 1922 kB of additional disk space will be used. | Get:1 http://ftp.us.debian.org/debian/ sid/main vim amd64 2:7.3.547-7 [841 kB] | Fetched 841 kB in 1s (630 kB/s) | dpkg: unrecoverable fatal error, aborting: | syntax error: unknown group 'postdrop' in statoverride file | E: Sub-process /usr/bin/dpkg returned an error code (2) This problem showed up for me, because postfix was installed and then - for external reasons - the group database was restored to a pre-install version. Worse, it's not really possible to cleanly recover from this without manually editing dpkg's private files in /var/lib: - purging postfix would do the dpkg-statoverride --remove, but that doesn't help. - manually doing dpkg-statoverride --remove is likewise not successful (see above). Maybe the statoverride parser should be more forgiving? weasel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538067: Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
Hamish: (a public script creates that tarball (and the md5sum) the way, I think it's on the alioth site, somewhere. I'm all about the automation..) here'tis, pretty simple: http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/get_latest_from_git.sh?view=markup regards, Hamish -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705753: pocketsphinx: FTBFS: test_gst fails
Source: pocketsphinx Version: 0.8-1 Severity: serious Justification: fails to build from source Automated builds of pocketsphinx have been failing with test_gst errors: (test_gst:N): GStreamer-CRITICAL **: gst_element_link_pads_filtered: assertion `GST_IS_ELEMENT (dest)' failed (test_gst:N): GStreamer-CRITICAL **: gst_element_link_pads_full: assertion `GST_IS_ELEMENT (src)' failed Error: Internal data flow error. FAIL: fh = fopen(test_gst.out, r) FAIL: test_gst 1 of 32 tests failed make[4]: *** [check-TESTS] Error 1 Could you please take a look? If the test needs an X display, perhaps you can run it under xvfb-run or skip it altogether. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705754: postfix probably should not remove users/group on purge
Package: postfix Version: 2.9.6-2 Severity: wishlist Please stop removing unix system groups and accounts upon package purge. IIRC that also was the consensus the last time this discussion came up on -devel. Cheers, weasel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693588: evince: printing some modified pdf file leads to a file with only some letters
Hi, I missed that message. The link is now dead, but I tried to use evince again, and the bug seems solved. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
On Fri, Apr 19, 2013 at 02:26:48PM +0200, Karsten Malcher wrote: Hi Johan, Am 19.04.2013 11:04, schrieb Johan Hovold: This was a log with lost data. The logs seems to make politics. ;-) Then the problem is most likely not in the driver as the characters are being read back in the log you provided. Stop - it's really possible that i send not enough bytes. Sometimes up to 6 Bytes will come back. This time i send this string (3.2.0): 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n I get back the first 3 Bytes of it. Log is attached. Was it really the same log? In the log below there is an error reported but it looks like no data at all is returned: [ 1443.120415] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: usb_serial_generic_write - port 0 [ 1443.120430] pl2303 ttyUSB0: usb_serial_generic_write_start - length = 101, data = 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 0a [ 1443.122568] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback - nonzero read bulk status received: -84 Either way, the error is EILSEQ (-84) which usually indicates hardware problems. [...] There are 2 beasty questions left: 1. Why it works with PL2303H ? Different device, different hardware. 2. Why i receive sometimes the first bytes? Your particular device could be flakey and sometimes you're able to read a few bytes. Now that you have compiled your own kernel, you could run a git bisect to learn if anything else has changed in the kernel (possibly interacting with your test setup) which can explain why things stopped working. I learned much in kernel testing the last time ... :-) Maybe there is a HowTo for the bisect testing? I don't have any good pointers at hand except for the git documentation of git-bisect. But perhaps you don't need to do a bisect. If the hardware is broken then knowing which performance increase in the kernel pushed it over the edge isn't really gonna be of much use as the driver is still working with other HX-devices (I have one here). If you still want to pursue this, you should try to reproduce the error on a v3.8 kernel (look in the logs for errors from usb_serial_generic_read_bulk_callback). Then you could try to reduce the bulk-in and out buffer sizes in the driver (simply comment out those fields in the pl2303_device struct) and perhaps also to reduce the number of read and write urbs (I can tell you how later). Johan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704555: Info received (Bug#704555: RFS: quadrule/0~20121001-1 [ITP] -- C library of quadrature rules for numerical integration)
Package quadrule has been removed from mentors. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705755: rapicorn: FTBFS on non-Linux: needs eventfd and NPTL
Source: rapicorn Version: 13.03.0~ds0-1 Severity: serious Justification: fails to build from source Builds of rapicorn on kFreeBSD and the Hurd fail because they lack eventfd and (at least in the case of kFreeBSD) use a port of legacy Linuxthreads rather than NPTL. Depending on how fundamentally it needs eventfd and NPTL, you might have to restrict its Architecture setting to linux-any. Specifically, the hurd-i386 and kfreebsd-i386 builds both fail with aida.cc:17:57: fatal error: sys/eventfd.h: No such file or directory and the kfreebsd-amd64 build (which for some reason compiles sources in a different order) fails with thread.hh: In constructor 'constexpr Rapicorn1303::Cond::Cond()': thread.hh:155:65: error: no matching function for call to 'pthread_cond_t::pthread_cond_t(brace-enclosed initializer list)' and moreover thread.cc: In function 'int Rapicorn1303::ThisThread::affinity()': thread.cc:249:66: error: 'pthread_getaffinity_np' was not declared in this scope thread.cc: In function 'void Rapicorn1303::ThisThread::affinity(int)': thread.cc:275:70: error: 'pthread_setaffinity_np' was not declared in this scope Could you please take a look? Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705594: Add further support for missing win32-loader.ini
tags 705594 +pending thanks On Wed, Apr 17, 2013 at 11:17:19AM +0200, Robert Spencer wrote: Package: debian-cd Version: 3.1.12 In boot-x86 there is already two checks for the existence of win32-loader.ini, the attached patch file adds the missing third check. Without this patch the tail end of the build log for the multi-arch ISO shows: Using newer EFI support in xorriso 10206 (Optionally) making the image bootable for i386: Running tools/boot/wheezy/boot-i386 1 /home/idms/build.wheezy/tmp/wheezy/CD1 Using ISOLINUX boot-disks image on CD1 sed: can't read boot1/win32-loader.ini: No such file or directory FAILED: error 2 Failed to start disc 1, error 512 make: *** [image-trees] Error 9 I'm making a custom server netinstall ISO, so there are no MS Windows files and no need for them. Cool, patch applied in svn now. -- Steve McIntyre, Cambridge, UK.st...@einval.com Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705756: rapicorn: FTBFS on 32-bit systems: expects 64-bit size_t
Source: rapicorn Version: 13.03.0~ds0-1 Severity: serious Justification: fails to build from source Builds of rapicorn on 32-bit systems fail because it expects uint32_t and size_t to be distinct types: aida.hh:400:15: error: 'void Rapicorn1303::Aida::FieldBuffer::operator=(uint32_t)' cannot be overloaded aida.hh:397:15: error: with 'void Rapicorn1303::Aida::FieldBuffer::operator=(size_t)' aida.hh:456:15: error: 'void Rapicorn1303::Aida::FieldReader::operator=(uint32_t)' cannot be overloaded aida.hh:453:15: error: with 'void Rapicorn1303::Aida::FieldReader::operator=(size_t)' Could you please take a look and arrange to suppress the redundant definitions on 32-bit systems? Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
