Bug#783050: greekocr4gamera: timestamp in docs
Source: greekocr4gamera Version: 1.0.1-4 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps greekocr4gamera is not fit for reproducible building due to timestamps in the docs. I'm going to fix this soon. DS -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782960: closed by Jonathan Wiltshire j...@debian.org (Re: Bug#782960: unblock: mariadb-10.0/10.0.17-1)
On 2015-04-21 6:41, Otto Kekäläinen wrote: Hello! 2015-04-21 0:15 GMT+03:00 Debian Bug Tracking System ow...@bugs.debian.org: .. I don't see anything that's appropriate for a point release either, so I'm going to close this bug. [...] Could you please reconsider? For the MySQL and MariaDB packages point releases are very stable and the normal way to upgrade packages in production environments (and distributions). For this reason the MySQL and MariaDB packages have been granted the micro release exception in Ubuntu (https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions) as an example of distribution policy. It's got very little to do with how good upstream are at stable releases and very much more to do with the fact that, as you're no doubt aware, we're now less than a week away from release and in deep freeze. A point release will anyway be pushed via the security channel sooner or later. I think it would make sense to push unblock mariadb-10.017-1 now directly. A little earlier in the freeze, quite possibly. Personally, I'm unconvinced that the GCC5 fix would have been appropriate at /any/ stage of this freeze. Fixes for failures with the default compiler, sure. Fixes for non-default compilers, possibly with a good rationale. A compiler that's not even in unstable, much less in the release, otoh... I have CC'd the security team if they want to chip in and say that letting 10.0.17-1 in is OK. I'm going to assume there was something lost in translation in that statement. While the security team's input is always valuable and will often form part of our decision process, whether or not a package is suitable for unblock is ultimately the release team's decision. Salvatore's confirmed that this will most likely get resolved via a release through the security archive, and that's of course fine. Personally at least the GCC5 change would be even less appropriate under those circumstances, but that's not my decision. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783005: suricata: ships embedded libhtp and can conflict with a future libhtp update
Hi, On Mon, 20 Apr 2015, Hilko Bengen wrote: * Raphaël Hertzog: But libhtp is already packaged separately. Embedded copy are best avoided and to me it looks like #777040 got fixed the wrong way. libhtp should be fixed to have a saner SONAME and/or it should generate a strict dependency through its shlibs/symbols files. Is it your goal to get this fixed in jessie before the release or can this wait? Well, no, given that the release managers acked the embedded copy in jessie... but in the long term it's wrong to keep it that way. Right now, it's doubly wrong because the embedded library is on a public path and would conflict with the libhtp update to the same upstream version... I suppose that we can get rid of this shared library file by linking the (embedded copy) of libhtp statically into the suricata binary. Yes but that gets rid of the file conflict only, not of the embedded copy which is the real problem in term of security maintenance. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: 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#779974: josm: invalid certificate
aptitude update aptitude reinstall ca-certificates Tried this one, still same result in josm. Can you attach the output of the command to see which CAs are included? I had attached it already in the previous email. Now I'm attaching the new output after the reinstallation. -- Salvo Tomaselli Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno. -- Galileo Galilei http://ltworf.github.io/ltworf/ output.txt.gz Description: application/gzip
Bug#783049: libnss3: libsoftokn3.so: cannot open shared object file: No such file or directory
Package: libnss3 Version: 2:3.17.4-1 Severity: normal certutil fails to load libsoftokn3.so because it's trying to find it in /usr/lib/nss while on my system it's installed in /usr/lib/x86_64-linux-gnu/nss. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783014: s-s-d: use gettimeofday that is sensible to jumps in the system time
Hi! On Mon, 2015-04-20 at 17:22:37 +0100, Jose M Calhariz wrote: Package: dpkg Version: 1.17.25 Severity: minor start-stop-daemon use gettimeofday to wait for process to die. Where I work there are use cases of using the retry option with --retry=TERM/300/KILL/5. 5 minutes is time enough for a Sysadmin to set the system lock and by mistake to messing the waiting of start-stop-daemon. Shouldn't the call gettimeofday be replaced by clock_gettime? Indeed. I've added support locally to use the monotonic clock, and will be included in my next push targetting 1.18.x, once I've tested this a bit more. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783024: www.debian.org: Adding USB media as support for Vendors List
On Tue, Apr 21, 2015 at 3:22 AM, Alexandre Delanoë wrote: @@ -56,11 +58,12 @@ # Vendor allows donations - Yes or No tdcontribution get-var contribution //td -# Vendor offers CD, DVD or CD+DVD +# Vendor offers CD, DVD, CD+DVD or USB td\ ifeq get-var cd / yes CD\ ifeq get-var cd / yes ifeq get-var dvd / yes +\ ifeq get-var dvd / yes DVD\ + ifeq get-var usb / yes USB\ /td tdget-var architectures //td tdship get-var ship //td I think this part of the patch is going to produce incorrect results for combinations of USB with CD/DVD, for example: CDUSB CD+DVDUSB DVDUSB -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782960: closed by Jonathan Wiltshire j...@debian.org (Re: Bug#782960: unblock: mariadb-10.0/10.0.17-1)
Hi all, On Tue, Apr 21, 2015 at 08:41:16AM +0300, Otto Kekäläinen wrote: 2015-04-21 0:15 GMT+03:00 Debian Bug Tracking System ow...@bugs.debian.org: .. I don't see anything that's appropriate for a point release either, so I'm going to close this bug. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw Could you please reconsider? For the MySQL and MariaDB packages point releases are very stable and the normal way to upgrade packages in production environments (and distributions). For this reason the MySQL and MariaDB packages have been granted the micro release exception in Ubuntu (https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions) as an example of distribution policy. A point release will anyway be pushed via the security channel sooner or later. I think it would make sense to push unblock mariadb-10.017-1 now directly. I have CC'd the security team if they want to chip in and say that letting 10.0.17-1 in is OK. Yes, I can confirm that we most likely will need to use the same strategy as for the mysql-5.5 packages for mariadb-10.0 once updated through jessie-security. Regards, Salvatore signature.asc Description: Digital signature
Bug#782915: release-notes: please add news from Debian GIS to release notes
Hi, Thanks for the proposed text. On 2015-04-20 14:48, Andreas Tille wrote: On Mon, Apr 20, 2015 at 05:57:07PM +1200, Chris Bannister wrote: On Sun, Apr 19, 2015 at 08:44:33PM +0200, Andreas Tille wrote: During the jessie development cycle many changes from UbuntuGIS were incorporated (back) into Debian GIS. The collaboration with UbuntuGIS The '(back)' is redundant here. But it an important change to the situation at the last release. Can we perhaps do with a merged back into? CC'ing Justin for a 4th (?) opinion. :) The full (original) text is at [1]. and OSGeo-Live projects was improved, resulting in new packages and contributors. Visit Debian GIS tasks pages to see the full range of GIS software inside Debian. A link to the Debian GIS tasks pages (you mean there's more than one?) would be a nice touch. Sorry, the link is http://blends.debian.org/gis/tasks Kind regards Andreas. [1] News from Debian GIS Blend During the jessie development cycle many changes from UbuntuGIS were incorporated (back) into Debian GIS. The collaboration with UbuntuGIS and OSGeo-Live projects was improved, resulting in new packages and contributors. Visit Debian GIS tasks pages to see the full range of GIS software inside Debian. The original version including mark up is attached to the first mail of the bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783048: ocr4gamera: timestamp in docs
Package: ocr4gamera Version: 1.0.6-3 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps ocr4gamera is not fit for reproducible building due to timestamps in the docs. I'm going to fix this soon. DS -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782960: closed by Jonathan Wiltshire j...@debian.org (Re: Bug#782960: unblock: mariadb-10.0/10.0.17-1)
On 2015-04-21 7:39, Adam D. Barratt wrote: Salvatore's confirmed that this will most likely get resolved via a release through the security archive, and that's of course fine. Personally at least the GCC5 change would be even less appropriate under those circumstances, but that's not my decision. Salvatore clarified on IRC that his comment was specifically related to security updates affecting mariadb; apologies for any imprecision. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782915: release-notes: please add news from Debian GIS to release notes
Niels, On Tue, Apr 21, 2015 at 08:23:54AM +0200, Niels Thykier wrote: The '(back)' is redundant here. But it an important change to the situation at the last release. Can we perhaps do with a merged back into? CC'ing Justin for a 4th (?) opinion. :) The full (original) text is at [1]. ACk for merged back into. Thanks for the enhancement suggestion Andreas. -- 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#767858: Bug#782749: All browsers except Links2 crash constantly and iceweasel is broken
... Forwarding to the right bug ... Am Dienstag, den 21.04.2015, 20:15 +0200 schrieb Tobias Frost: Control: -1 tags fixed-upstream fixed-in-experimental Control: -1 fixed 1.14.2-1 Am Montag, den 20.04.2015, 14:00 +0100 schrieb Adam D. Barratt: Given that nothing about the patch appears to be sparc-specific, it should probably be applied in unstable first in case of regressions on other architectures (assuming that the bug meta-data is correct and the versions of cairo in unstable and experimental are affected). 1.14.2's changelog [1] says it has the patch... So experimental is fine already and hopefully the package is soon uploaded to sid, too. [1] http://cairographics.org/news/cairo-1.14.2/ -- toib -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779412: block devices loosing state after resume: trigger udev rules to re-apply settings
Many thanks for your help in solving this, Michael! (Unfortunately, I had only tried the imperfect unit file, and I had just luck (or not) so that I did not see it fail.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782672: patch
retitle 782672 [PATCH] sbuild: Extra command parsing is overly-complex and
broken
tags 782672 patch
thanks
I made a patch to address this. It's attached. The patch says that it's
2/3 in a series, but this is the only one relevant to this issue.
Notes:
when handling external commands (--starting-build-commands and others),
I now keep the input string as is, and pass it to the shell, instead of
splitting it on whitespace and then reassembling it. This reassembling
was being done improperly, with shell internals such as being
erroneously escaped (doing it right is way more work than simply keeping
the original string). Keeping the string as is allows the user to give
the command they want.
This is implemented by keeping the COMMAND and INTCOMMAND keys same as
they were (array-refs of strings), but adds additional COMMAND_STR and
INTCOMMAND_STR keys that have the string representation. The non-STR
versions are always populated, and the external command options populate
the _STR ones as well. When running the commands, we use the _STR
options if we have them, otherwise, we recombine as before.
Since the old array-ref-based code path is still there, old commandlines
and configurations remain working.
The big win so far is that I can get an interactive shell going. It's
not ideal yet since I have to manually redirect the pty, and there's
some stdout buffering thing I haven't tried to fix, but it's already
super useful:
$ ls -l /dev/stdin(:A)
crw--- 1 dkogan tty 136, 1 Apr 21 12:42 /dev/pts/1
$ sbuild --starting-build-commands 'sh -i /dev/pts/1
/dev/pts/1'
+--+
| Starting Timed Build Commands
|
+--+
sh -i /dev/pts/1 /dev/pts/1
---
pwd
/build/cross-gcc-4.9-i386-uMV_ms
From 9eeea9238147bce12e5544751b6e4106df24571c Mon Sep 17 00:00:00 2001
From: Dima Kogan d...@secretsauce.net
Date: Mon, 20 Apr 2015 22:12:56 -0700
Subject: [PATCH 2/3] external commands are now unparsed strings
when handling external commands (--starting-build-commands and others), I now
keep the input string as is, and pass it to the shell, instead of splitting it
on whitespace and then reassembling it. This reassembling was being done
improperly, with shell internals such as being erroneously escaped. Keeping
the string as is allows the user to give the command they want.
This is implemented by keeping the COMMAND and INTCOMMAND keys same as they were
(array-refs of strings), but adds additional COMMAND_STR and INTCOMMAND_STR keys
that have the string representation. The non-STR versions are always populated,
and the external command options populate the _STR ones as well. When running
the commands, we use the _STR options if we have them, otherwise, we recombine
as before.
Since the old array-ref-based code path is still there, old commandlines and
configurations remain working
---
lib/Sbuild/Build.pm | 71 +++--
lib/Sbuild/Chroot.pm| 4 +++
lib/Sbuild/ChrootPlain.pm | 41 +++---
lib/Sbuild/ChrootSchroot.pm | 14 ++---
lib/Sbuild/ChrootSudo.pm| 43 +++
lib/Sbuild/Conf.pm | 2 +-
lib/Sbuild/Options.pm | 21 +-
7 files changed, 119 insertions(+), 77 deletions(-)
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index b44ccb3..03e5522 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1081,23 +1081,37 @@ sub run_command {
$defaults = $self-get('Host')-{'Defaults'};
$out = $defaults-{'STREAMOUT'} if ($log_output);
$err = $defaults-{'STREAMERR'} if ($log_error);
- $self-get('Host')-run_command(
- { COMMAND = \@{$command},
- PRIORITY = 0,
- STREAMOUT = $out,
- STREAMERR = $err,
- });
+
+ my %args = (PRIORITY = 0,
+ STREAMOUT = $out,
+ STREAMERR = $err);
+ if(ref $command) {
+ $args{COMMAND} = \@{$command};
+ $args{COMMAND_STR} = @{$command};
+ } else {
+ $args{COMMAND} = [split('\s+', $command)];
+ $args{COMMAND_STR} = $command;
+ }
+
+ $self-get('Host')-run_command( \%args );
} else {
$defaults = $self-get('Session')-{'Defaults'};
$out = $defaults-{'STREAMOUT'} if ($log_output);
$err = $defaults-{'STREAMERR'} if ($log_error);
- $self-get('Session')-run_command(
- { COMMAND = \@{$command},
- USER = ($rootuser ? 'root' : $self-get_conf('BUILD_USER')),
- PRIORITY = 0,
- STREAMOUT = $out,
- STREAMERR = $err,
- });
+
+ my %args = (USER = ($rootuser ? 'root' : $self-get_conf('BUILD_USER')),
+ PRIORITY = 0,
+ STREAMOUT = $out,
+ STREAMERR = $err);
+ if(ref $command) {
+ $args{COMMAND} = \@{$command};
+ $args{COMMAND_STR} = @{$command};
+ } else {
+ $args{COMMAND} =
Bug#782487: sg3-utils: provide udev rules for multipath-tools
On Thursday 16 April 2015 07:56 PM, Serge Cohen wrote: Is it possible to raise the severity level of this bug to make it RC, and is there a chance that both bugs (782487 and 782488) are solved before the release so that the installation on systems relying on multipath would not require workaround to be functional ? Thank you very much for all the work already done. Thanks for reporting the issue. But at this time, this will not make into Jessie. This is one gripe I have with Debian Enterprise users. I always get bug reports at the very last minute. What most users don't realize is that many of us Debian Developers are really pure volunteers. :-) We aren't paid by anyone to work on it, thus the commitment and reaction to a bug report heavily depends on when I have the time. Anyways... I'll be looking into packaging 1.40 soon. I don't like the idea to introduce a new package, but then let me check first. @Mauricio: Again, thank you. Your reports and patches are really helpful to me. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#768968: RFP: pyuca -- Python implementation of the Unicode Collation Algorithm (UTS-10)
I've lost interest in this package and therefore putting it RFP and going to delete it from mentors. Anyway, the initial packaging remains at the group repo [1] and could be taken up be someone else for maintenance. I think this could be a beginner's project for people interested in getting up Python library packaging for Debian. Thank you, DS [1] http://anonscm.debian.org/viewvc/python-modules/packages/pyuca/trunk/ -- http://qa.debian.org/developer.php?login=debian%40danielstender.com 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782749: All browsers except Links2 crash constantly and iceweasel is broken
Control: -1 tags fixed-upstream fixed-in-experimental Control: -1 fixed 1.14.2-1 Am Montag, den 20.04.2015, 14:00 +0100 schrieb Adam D. Barratt: Given that nothing about the patch appears to be sparc-specific, it should probably be applied in unstable first in case of regressions on other architectures (assuming that the bug meta-data is correct and the versions of cairo in unstable and experimental are affected). 1.14.2's changelog [1] says it has the patch... So experimental is fine already and hopefully the package is soon uploaded to sid, too. [1] http://cairographics.org/news/cairo-1.14.2/ -- toib -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750135: Status of #750135 (Maintainer of aptitude package)
Didier == Didier 'OdyX' Raboud o...@debian.org writes: Didier Given the situation (an unresponsive Daniel, a proposal from Didier people with powers to push the situation forward), I'd be Didier more inclined to say yes to Christian, without a formal Didier resolution. Given that Christian has asked for additional support before moving forward, I'd prefer to give him that. I think the resolution should be non-binding. Something along the lines of We observed this fact. Christian asked for input on whether this would be a good way forward. The TC believes it would be. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783081: installation-reports: Jessie daily installer installs kernel in flash without any further confirmation (QNAP TS-212)
Package: installation-reports Severity: normal Tags: d-i -- Package-specific info: Boot method: network Image version: http://d-i.debian.org/daily-images/armel/20150415-00:19/kirkwood/network-console/qnap/ts-219/kernel Date: 2015-04-15 Machine: QNAP Turbo Station TS-212 Partitions: # fdisk -l Disk /dev/mtdblock0: 512 KiB, 524288 bytes, 1024 sectors Disk /dev/mtdblock1: 2 MiB, 2097152 bytes, 4096 sectors Disk /dev/mtdblock2: 9 MiB, 9437184 bytes, 18432 sectors Disk /dev/mtdblock3: 3 MiB, 3145728 bytes, 6144 sectors Disk /dev/mtdblock4: 256 KiB, 262144 bytes, 512 sectors Disk /dev/mtdblock5: 1,3 MiB, 1310720 bytes, 2560 sectors Disk /dev/md2: 517,6 MiB, 542769152 bytes, 1060096 sectors Disk /dev/md9: 517,6 MiB, 542769152 bytes, 1060096 sectors Disk /dev/md13: 448,1 MiB, 469893120 bytes, 917760 sectors Disk /dev/sda: 29,9 GiB, 32126271488 bytes, 62746624 sectors Disk /dev/sdb: 465,8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [ ] Install base system:[O] Install tasks: [O] Install boot loader:[ ] Overall install:[O] Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install: - As I have a serial cable connected to it I am able to intercept the automatic u-boot boot sequence. That way I entered to load kernel/initrd from a TFTP server. - Booting that way did not show any error to me. - On the serial line I got asked to setup a password for the install user. - Via SSH with this user and password I am able to login to the installer. - From there the installation went nearly like any other debian installation. - I installed to an USB stick. Before this I had a debootstrapped wheezy installation which neeeds also the kernel/initrd to be loaded via TFTP. That way I was still able to boot the original firmware (even when I did nearly never used it anymore). That way I tried to maintain the original firmware in a working state even when installing Jessie. But I was not aware that the Installer would overwrite the kernel in the internal flash without further asking. (Most probably because the internal flash holds for installations without serial console already the kernel/initrd of the debian installer.) As a comparision on x86 the user gets asked where or even if the bootloader should be installed. So that is not a big problem as I would have somewhere backups of the internal flash around (which I probably will never need) and also now I can just power up this device and can just upgrade the kernel without the hazzle :-) (Therefore I was not sure if I should file against debian-installer or give it another severity.) Thanks for maintaining this awesome Distribution. Kind regards, Bernhard -- on the initial u-boot prompt: # right after power on press enter to avoid the automatic timeout setenv serverip 192.168.178.199; setenv ipaddr 192.168.178.139; setenv bootargs console=ttyS0,115200 initrd=0xa0,0xa0 ramdisk=34816; tftpboot 0x40 /boot/linux/debian-installer-netboot/jessie-8rc2-daily-2015-04-15_kirkwood/kernel; tftpboot 0xa0 /boot/linux/debian-installer-netboot/jessie-8rc2-daily-2015-04-15_kirkwood/initrd.gz; bootm 0x40 -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build 20150415-00:11 X_INSTALLATION_MEDIUM=network-console == Installer hardware-summary: == uname -a: Linux nas3c3b5d 3.16.0-4-kirkwood #1 Debian 3.16.7-ckt9-2 (2015-04-13) armv5tel GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. 88F6281 [Kirkwood] ARM SoC [11ab:6281] (rev 03) lspci -knn: Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] usb-list: usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Manufacturer: Linux 3.16.0-4-kirkwood ehci_hcd usb-list:Interface 00: Class 09(hub
Bug#763966: end_request: critical target error
I stumbled across this when trying to backup to an encrypted USB 2.0 HDD. The device would unlock and mount fine (mount reports rw), but any attempt to modify or copy files to it caused an 'no space left on device' error, while 'df -h' reported 10GB free space. 'dd' to the raw device does not complain. 'badblocks -n /dev/sde 1048576' passes too. An attempt to newly cryptsetup the device failed: cryptsetup -c aes-xts-plain -y luksFormat /dev/sde snip... Cannot wipe header on device /dev/sde. dmesg: [ 4892.853217] sd 13:0:0:0: [sde] 195371568 512-byte logical blocks: (100 GB/93.1 GiB) [ 4892.853826] sd 13:0:0:0: [sde] Write Protect is off [ 4892.853835] sd 13:0:0:0: [sde] Mode Sense: 00 14 00 00 [ 4892.854446] sd 13:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 4892.878472] sde: unknown partition table [ 4892.880852] sd 13:0:0:0: [sde] Attached SCSI disk [ 4965.651005] end_request: critical target error, dev sde, sector 0 [ 4965.812869] sde: unknown partition table running linux-image-3.16.0-4-amd64 (3.16.7-ckt9-2) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783080: unblock: oldsys-preseed/3.16
Control: tag -1 confirmed Jonathan Wiltshire j...@debian.org (2015-04-21): On Tue, Apr 21, 2015 at 07:38:07PM +0100, Ian Campbell wrote: This fixes #783019 which is a failure to correctly function on many kirkwood and orion5x armel platforms. Since this package exists to aid with headless installs d-i is basically unusable on any affected system, since it will ask questions on the (non-existent) serial port before enabling the network install path. Needs d-i approval; my hunch would be that KiBi will defer until after release, but let's see. Nice try. ;) Looking at brltty is already on my to-do list, and is likely a reason for another debian-installer upload. oldsys-preseed looks small enough to have that merged for r0. Mraw, KiBi. signature.asc Description: Digital signature
Bug#782019: libdpkg-perl: Allow Dpkg::Control::Info-new to load nothing
Guillem Jover guil...@debian.org writes:
Hi!
Hello,
[...]
I agree that the -new interface for Dpkg::Control::Info is annoying
and inconsistent with the other classes in the library, and should be
fixed at least out of consistency.
So I'm going to fix this in two ways. One to add support to that
constructor (and the Dpkg::Substvar one) to take either a scalar or a
hash as argument. And if the hash has a filename = undef, then it will
not load the file. Probably deprecate the sclar form in the future.
And by changing Dpkg::Interface::Storable's load()/save() to allow
passing an IO handle to the method, so that one can do something like:
my $ci = Dpkg::Control::Info-new($fh);
$ci-load($fh);
Does this sound good?
Yes, but to be sure, let me summarise, with your proposition I could
either:
- pass an IO::Handle to the new constructor:
#+begin_src perl
use Git::Repository;
my $repo = Git::Repository-new(work_tree = '/some/where');
my $control_ref = $self-dist_branch . ':debian/control';
my $control_fh = $repo-command(show = $control_ref)-stdout;
my $control = Dpkg::Control::Info-new($control_fh);
#+end_src
- Pass “{filename = undef}” to the new constructor and then pass the
IO::Handle to “load()”:
#+begin_src perl
use Git::Repository;
my $control = Dpkg::Control::Info-new({filename = undef});
my $repo = Git::Repository-new(work_tree = '/some/where');
my $control_ref = $self-dist_branch . ':debian/control';
my $control_fh = $repo-command(show = $control_ref)-stdout;
$control-load($control_fh);
#+end_src
Maybe it miss the “pass a filename string” to the constructor and
“load()” for compatibility, since this method automatically use
Dpkg::Compression::FileHandle?
Thanks.
--
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF
signature.asc
Description: PGP signature
Bug#783082: linux-image-3.16.0-4-586: video players/browsers crash with 'illegal instruction' on i586
Package: src:linux
Version: 3.16.7-ckt9-2
Severity: critical
Justification: breaks unrelated software
Dear Maintainer,
in advance:
I'm aware that the kernel is most likely not the correct package for this
report. But with respect to the intended Jessie release date and because I
trust you are much more qualified to track this down than I am I file this as
some general 'architecture bug'.
Please feel free to re-assign, downgrade or ignore this matter alltogether if
you think 'video' is of no concern in i586 anyway.
I recently dist-upgraded a PC with an AMD K6-2 CPU and found that video players
(mplayer2, vlc) crash with an 'illegal instruction' message when trying to play
a video. Web browsers (midori (from Wheezy), qupzilla, xombrero) also crash
with the same message when trying to load a multimedia-heavy website (e.g.
youtube).
I also verified this on another computer with an Intel Pentium MMX CPU and with
a LinuxBBQ 'Popcorn Lite' Live CD, which is mostly a Sid Live CD from September
2014 running an i486 kernel. [1]
This problem might or might not be similar to bug #742154.
To reproduce this, install Jessie on any i586 hardware (note: installing the
i586 kernel on i686 hardware will not reveal this problem), install one of the
video players mentioned above and try to play a video. The player window will
appear and the program will crash once the first image should be displayed.
Example for vlc:
$ vlc bigbuckbunny240p.flv
VLC media player 2.2.0-rc2 Weatherwax (revision 2.2.0-rc1-118-g22fda39)
[08b4c1b8] pulse audio output error: PulseAudio server connection failure:
Connection refused
[08ab48f8] core libvlc: VLC wird mit dem Standard-Interface ausgeführt.
Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
Failed to open VDPAU backend libvdpau_r200.so: Kann die Shared-Object-Datei
nicht öffnen: Datei oder Verzeichnis nicht gefunden
Ungültiger Maschinenbefehl
Example for mplayer2 is here [2].
Alternatively install one of the browsers I mentioned and surf to youtube.com.
The browser window will start, large parts of the website will be loaded and
displayed and once video images are or should be displayed (depending on
browser), the brower will crash. No video has to actually be played (nor can
it).
Example for qupzilla:
$ qupzilla youtube.com
QupZilla: 0 extensions loaded
Ungültiger Maschinenbefehl
For completeness /proc/cpuinfo [3] for the AMD K6-2 and /proc/cpuinfo and lspci
-v for the Pentium MMX [4].
I opened a thread for this in the unofficial German Debianforum [5], up to now
to no avail.
[1] http://linuxbbq.org/
[2] https://debianforum.de/forum/pastebin.php?mode=views=38467
[3] https://debianforum.de/forum/pastebin.php?mode=views=38472
[4] https://debianforum.de/forum/pastebin.php?mode=views=38471
[5] https://debianforum.de/forum/viewtopic.php?f=13t=154969
-- Package-specific info:
** Version:
Linux version 3.16.0-4-586 (debian-ker...@lists.debian.org) (gcc version 4.8.4
(Debian 4.8.4-1) ) #1 Debian 3.16.7-ckt9-2 (2015-04-13)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-586
root=UUID=b936e1d7-6fb6-44ce-a4c5-9603100f15a1 ro quiet
** Not tainted
** Kernel log:
[6.212359] sd 1:0:0:0: [sdb] 16841664 512-byte logical blocks: (8.62
GB/8.03 GiB)
[6.213594] sd 1:0:0:0: [sdb] Write Protect is off
[6.213621] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[6.214106] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[6.223536] sr1: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
[6.225713] sr 1:0:1:0: Attached scsi CD-ROM sr1
[6.248276] sdb: sdb1
[6.261562] sd 0:0:0:0: Attached scsi generic sg0 type 0
[6.262232] sda: sda1 sda2
[6.266956] sd 0:0:0:0: [sda] Attached SCSI disk
[6.267071] sd 1:0:0:0: [sdb] Attached SCSI disk
[6.271222] sr 0:0:1:0: Attached scsi generic sg1 type 5
[6.274027] sd 1:0:0:0: Attached scsi generic sg2 type 0
[6.277511] sr 1:0:1:0: Attached scsi generic sg3 type 5
[6.509067] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[6.509166] ata1.00: BMDMA stat 0x65
[6.509232] ata1.00: failed command: READ DMA
[6.509315] ata1.00: cmd c8/00:08:28:d8:31/00:00:00:00:00/e1 tag 0 dma 4096
in
res d2/d2:d2:d2:d2:d2/00:00:00:00:00/d2 Emask 0x2 (HSM violation)
[6.509394] ata1.00: status: { Busy }
[6.509515] ata1.00: error: { ICRC UNC IDNF }
[6.565282] ata1: soft resetting link
[6.746273] ata1.00: configured for UDMA/33
[6.753824] ata1.01: configured for UDMA/33
[6.755128] ata1: EH complete
[6.898651] random: nonblocking pool is initialized
[7.472365] PM: Starting manual resume from disk
[7.472419] PM: Hibernation image partition 8:2 present
[7.472431] PM: Looking for hibernation image.
[7.473896] PM: Image not found (code -22)
[7.473914] PM: Hibernation image not present or could not be loaded.
[8.225576] EXT4-fs (sda1): mounted filesystem with ordered data
Bug#782019: libdpkg-perl: Allow Dpkg::Control::Info-new to load nothing
Hi! On Mon, 2015-04-06 at 16:51:42 +0200, Daniel Dehennin wrote: Package: libdpkg-perl Version: 1.17.24 Severity: wishlist File: /usr/share/perl5/Dpkg/Control/Info.pm I'm creating a little tool around Dpkg::* to check the status of packaging in a Git repository. My code actually need to change the current branch to read debian/changelog but it can not work on unclean working tree. I would like to use Dpkg::Control::Info-parse like the following: I agree that the -new interface for Dpkg::Control::Info is annoying and inconsistent with the other classes in the library, and should be fixed at least out of consistency. So I'm going to fix this in two ways. One to add support to that constructor (and the Dpkg::Substvar one) to take either a scalar or a hash as argument. And if the hash has a filename = undef, then it will not load the file. Probably deprecate the sclar form in the future. And by changing Dpkg::Interface::Storable's load()/save() to allow passing an IO handle to the method, so that one can do something like: my $ci = Dpkg::Control::Info-new($fh); $ci-load($fh); Does this sound good? Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782777: Cause for #782777 (recent aptitude forget-new issues) is likely the fix for #777760 in apt 1.0.9.8
Hi again, after discussing the issue with David on IRC, we've found some more indicators: Axel Beckert wrote: # dpkg --print-architecture amd64 # dpkg --print-foreign-architectures # All affected systems so far were single arch. Issuing dpkg --add-architecture i386 plus apt-get update on an affected amd64 system makes the symptoms vanish and aptitude works fine again, at least with regards to the new packages list and aptitude forget-new. Issuing dpkg --remove-architecture i386 (even without apt-get update afterwards) causes the packages to show up [With 1.0.9.8] # apt-get install -s libgnutls26:amd64 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libgnutls26 0 upgraded, 1 newly installed, 0 to remove and 6 not upgraded. Inst libgnutls26:i386 Conf libgnutls26:i386 [With 1.0.9.7 after an apt-get update] # apt-get install -s libgnutls26:amd64 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libgnutls26 0 upgraded, 1 newly installed, 0 to remove and 6 not upgraded. Inst libgnutls26 (2.12.23-18 Debian:experimental [amd64]) Conf libgnutls26 (2.12.23-18 Debian:experimental [amd64]) Here's the same again on a different system where different packages where keeping to show up in aptitude's new packages list: [Single-Arch, with 1.0.9.8] # apt-get install -s libgcc1-dbg Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libgcc1-dbg 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Inst libgcc1-dbg:arm64 Conf libgcc1-dbg:arm64 # So here it is arm64 and not i386 which shows up unexpectedly on a single-arch system. After enabling i386 with dpkg --add-architecture i386: # dpkg --add-architecture i386 # apt-get install -s libgcc1-dbg Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libgcc1-dbg 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Inst libgcc1-dbg (1:4.9.2-10 Debian:unstable [amd64]) Conf libgcc1-dbg (1:4.9.2-10 Debian:unstable [amd64]) # dpkg --remove-architecture i386 # apt-get install -s libgcc1-dbg Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libgcc1-dbg 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Inst libgcc1-dbg:arm64 Conf libgcc1-dbg:arm64 So it doesn't even need the apt-get update to make that issue vanish and come again. David already seems to on to something... Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783080: unblock: oldsys-preseed/3.16
Package: release.debian.org Severity: normal Tags: d-i User: release.debian@packages.debian.org Usertags: unblock Please unblock package oldsys-preseed This fixes #783019 which is a failure to correctly function on many kirkwood and orion5x armel platforms. Since this package exists to aid with headless installs d-i is basically unusable on any affected system, since it will ask questions on the (non-existent) serial port before enabling the network install path. This package only produces udebs. diff -Nru oldsys-preseed-3.15/debian/changelog oldsys-preseed-3.16/debian/changelog --- oldsys-preseed-3.15/debian/changelog2015-02-26 03:55:12.0 + +++ oldsys-preseed-3.16/debian/changelog2015-04-21 06:07:22.0 +0100 @@ -1,3 +1,11 @@ +oldsys-preseed (3.16) unstable; urgency=medium + + [ Ian Campbell ] + * Avoid exiting prematurely on arm*/orion5x or arm*/kirkwood platforms when +they do not use device tree. (Closes: #783019) + + -- Christian Perrier bubu...@debian.org Tue, 21 Apr 2015 07:07:22 +0200 + oldsys-preseed (3.15) unstable; urgency=medium [ Michael Walle ] diff -Nru oldsys-preseed-3.15/oldsys-preseed oldsys-preseed-3.16/oldsys-preseed --- oldsys-preseed-3.15/oldsys-preseed 2015-02-26 03:53:17.0 + +++ oldsys-preseed-3.16/oldsys-preseed 2015-04-21 04:01:47.0 +0100 @@ -115,7 +115,11 @@ arm*/orion5x | arm*/kirkwood) machine=$(grep ^Hardware /proc/cpuinfo | sed 's/Hardware\s*:\s*//') # /proc/device-tree may not exist on all architectures - dt_model=$(cat /proc/device-tree/model 2/dev/null) + if [ -e /proc/device-tree/model ] ; then + dt_model=$(cat /proc/device-tree/model 2/dev/null) + else + dt_model=UNKNOWN + fi if echo $machine | grep -q ^Buffalo/Revogear Kurobox Pro; then check_file /proc/mtd rootfs=$(get_mtdblock rootfs) unblock oldsys-preseed/3.16 -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665847: patch
There's a patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765886 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
Am Tue, 21 Apr 2015 14:53:36 +0200 schrieb Michael Biebl bi...@debian.org: This doesn't guarantee that the service is run on resume. Many thanks for your help in solving this, Michael! (Unfortunately, I had only tried the imperfect unit file, and I had just luck (or not) so that I did not see it fail.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783079: libexosip2-11: Non-existing NAPTR handled incorrectly
Package: libexosip2-11
Version: 4.1.0-2
Severity: important
Dear maintainers,
I experience problems calling certain SIP URIs with linphone. If the
callee's domain doesn't have a NAPTR entry, libexosip2-11 erroneously
uses the domain's A/ record with port 5060 instead of doing SRV
lookups as it should (RFC 3263, Section 4.1). I confirmed this by both
looking at both the packet capture and the output of `linphonec -d 6`:
ortp-message-eXosip_dnsutils_naptr_lookup: About to ask for 'example.com NAPTR'
ortp-error-eXosip_dnsutils_naptr_lookup: res_query failed ('example.com NAPTR')
ortp-message-DNS resolution with example.com:5060
(The packet capture confirms that after the NAPTR query no further DNS
queries are sent out.)
When trying to debug the problem I read in the README of the source tree
of the libexosip2-11 package: You should install c-ares before for much
better DNS management!
After installing libc-ares-dev and rebuilding the package linphone works
as expected. The debug output now shows:
ortp-error-_naptr_callback: example.com DNS server returned answer with no data
ortp-message-_naptr_callback: NO NAPTR DNS // SRV record created manually
-49/49/_sips._udp.example.com
ortp-message-eXosip_dnsutils_srv_lookup: About to ask for
'_sip._udp.example.com SRV'
ortp-message-eXosip_dnsutils_srv_lookup: About to ask for
'_sip._tcp.example.com SRV'
ortp-message-eXosip_dnsutils_srv_lookup: About to ask for
'_sips._tcp.example.com SRV'
ortp-message-eXosip_dnsutils_srv_lookup: About to ask for
'_sips._udp.example.com SRV
The packet capture also confirms that the SRV lookups are done after the
NAPTR lookup. So if using c-ares is an option, that would work around
the problem. I wasn't able to find the bug that's causing the wrong
behavior in libexosip when c-ares isn't used.
Thank you
Lukas Schwaighofer
pgpvzdG_saA7u.pgp
Description: OpenPGP digital signature
Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell
control: tags -1 moreinfo unreproducible Am 18.04.2015 um 02:02 schrieb Rick Thomas: On Apr 17, 2015, at 3:44 PM, Michael Biebl bi...@debian.org wrote: Thanks for the data. Looks like an lvm issue to me: root@cube:~# lvscan inactive '/dev/vg1/backup' [87.29 GiB] inherit and as a result, /dev/disk/by-label/BACKUP is missing. Yes, that’s true, of course. But the question is, what is keeping lvm from activating the volume? It works fine for a logical volume on a single physical disk. And /proc/mdstat shows that the RAID device, /dev/md127, _is_ active. Or, at least it is when we get to emergency mode… I don’t know if it’s active when the fsck times out, of course… If you know how to figure that out from the systemd journal I attached to the original bug report, or any other way that I can try, I’d appreciate any assistance you can give! fwiw, I tried to reproduce the problem in a VM with two additional disks attached and a setup like the following: ext4 on RAID1 (via mdadm) ext4 on LVM on RAID1 (mdadm) ext4 on LVM ext4 on dos partition. All partitions were correctly mounted during boot without any issues. Is this a fresh jessie installation or an upgraded system? Do you have any custom udev rules in /lib/udev/rules.d or /etc/udev/rules.d? If it's an upgraded system and you have the sysvinit package installed, you can try booting with sysvinit temporarily via init=/lib/sysvinit/init on the kernel command line. Does that work? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#708189: base: X keyboard configuration lost after upgrade
Package: xorg Version: 1:7.7+7 Followup-For: Bug #708189 Dear Maintainer, During recent upgrade to testing/jessie my X11 language configuration was totally lost. While configuration files are still there. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 17 2011 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2401376 Feb 11 03:35 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/libGLESv2.so.2.0.0 to
Bug#783080: unblock: oldsys-preseed/3.16
Control: tag -1 d-i On Tue, Apr 21, 2015 at 07:38:07PM +0100, Ian Campbell wrote: This fixes #783019 which is a failure to correctly function on many kirkwood and orion5x armel platforms. Since this package exists to aid with headless installs d-i is basically unusable on any affected system, since it will ask questions on the (non-existent) serial port before enabling the network install path. Needs d-i approval; my hunch would be that KiBi will defer until after release, but let's see. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Bug#782645: [debian-mysql] Bug#782645: and this broke my mariadb completely
Hello Otto, understood and thank you followed your suggestions and works kind regards and thank you Josef On Tue, 21 Apr 2015 08:48:00 +0300 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= o...@seravo.fi wrote: Hello Josef! 2015-04-20 21:44 GMT+03:00 Josef Moosbauer jo...@mail.moosbauer.net: # But packages for MariaDB take priority Package: * Pin: Origin http://tweedo.com/ Pin-Priority: 1000 Looking at your sources listing I can see that you are mixing repositories for both wheezy and jessie, and also have ubuntu repos enabled and 3rd party repos. Debian maintainers have no way of anticipating what can happen in these kind of mixed environments. I'd recommend you only enable Jessie repositories and install and upgrade everything from there. From Jessie you can install official MariaDB 10.0 packages and then stop using the old 3rd party MariaDB repos. -- kind regards / mit freundlichen Grüßen Moosbauer Josef jo...@moosbauer.net GPG Fingerprint 6748 9413 0EF1 5B23 D707 DBFA 570B 00E3 4689 8CC9 Of course I'm crazy, but that doesn't mean I'm wrong. I'm mad but not ill signature.asc Description: This is a digitally signed message part
Bug#152955: force-reload should not start the daemon if it is not running
Control: block 782993 by 152955 Hi, the meaning of the force-reload action comes up again with systemd: - systemctl implements force-reload as documented by LSB, that is a service not running does *not* get started, - the init script integration maps /etc/init.d/X force-reload to systemctl force-reload X, - but service X force-reload gets mapped to systemctl X reload-or-restart which *does* start a service not running before. As I understand the discussion, Policy currently documents that force-reload *should* start services not already running and is contradicting LSB here; on the other hand initscripts behave in both ways, at least back when the bug was discussed initially. So I would like to re-raise the issue and propose the change suggested by Sven Mueller[1] again: | Regarding this special case force-reload command to init.d scripts, | currently maintainers have the choice between two differen RC bugs: | 1) Implement force-reload as a restart alias if reload is not |available and violate LSB (which, according to the RMs means an RC |bug). | 2) Implement force-reload as a conditional restart alias only |executed when the service is already running. This violates current |policy wording and is therefor also an RC bug. | At the very least, I would suggest the following wording of the | force-reload description: | | | tagttforce-reload/tt/tag | itemcause the configuration to be reloaded if the service supports | this. If it doesn't support reloading, restart the service. Note that | the service should not get started if it wasn't already running./item | | | This would cause non-LSB compliant behaviour to be a non-RC bug and make | LSB-compliant behaviour (which, BTW, is already implemented by _many_ | init scripts) perfectly OK with policy. This makes the behaviour as defined by LSB and as implemented in systemd a should, making scripts behave consistent wheather systemd in used as init or not. Ansgar [1] https://bugs.debian.org/152955#35 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779548: Oops
I just realized 1.30-1 was never uploaded, but it looked that way from the git packaging repo. I'm going to upload it now. /Simon pgpW2QgAbLNEm.pgp Description: OpenPGP digital signatur
Bug#783017: nmu: libgltf_0.0.2-2
On Mon, Apr 20, 2015 at 07:19:33PM +0100, Adam D. Barratt wrote: On Mon, 2015-04-20 at 19:32 +0200, Rene Engelhard wrote: something broke in the glm uploaded today. A LibreOffice build, just preparing for experimental - sid for after the release thus fails now :/ So nmu libgltf_0.0.2-2 . ALL . -m rebuild against new glm maybe also other glm build-r-deps affected, didn't check.. Hmmm. AFAICS libgltf doesn't end up with a versioned dependency on glm, and as it's currently in sync between testing and unstable, if they were scheduled right now then the binNMUs would become candidates and most likely end up migrating to jessie, which doesn't seem like what we want. Indeed. We could hack britney to block the binNMUs, but it's a bit icky (as it either needs a code change or a hack to fudge the version for the packages back to the source version in the result file before asking dak to import it) and I'd prefer not to do so if we can avoid it. Sounds bad, yes. I'm not sure if we're planning to keep britney running up until the end of the week. If not then this wouldn't be an issue in any case. If you know whether you can do that - can you schedule it then? Or should I upload a new source upload to cause a rebuild and avoid this situation? Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783005: suricata: ships embedded libhtp and can conflict with a future libhtp update
On 21 April 2015 at 09:57, Pierre Chifflier pol...@debian.org wrote: Arturo: I thought the plan was to keep the current situation, and remove libhtp from Debian ? Yes, that was the plan so far. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725153: [Pkg-freeipa-devel] [Pkg-openldap-devel] Bug#725153: freeipa-server backport to Jessie?
On 17.04.2015 21:54, Ryan Tandy wrote: On Fri, Apr 17, 2015 at 07:45:24AM +0300, Timo Aaltonen wrote: Actually, I pushed a hacked up libldap to my openldap git on alioth yesterday, but forgot to update this bug, oops git://git.debian.org/git/users/tjaalton/openldap.git it doesn't build anything other than libldap ldap-utils, and includes the applicable Fedora patches (yes three of them were upstream already) minus autoconf one which gave me some pain. If it's ok for you, we could have a branch on the official pkg repo so folks that need to build their own packages could use that as the base. Something like a moznss branch parallel to master? I don't have any problem with that. Ok, I'll push something at some point. FWIW, the autoconf patch worked for me once I added Build-Depends: pkg-config. ha, stupid me then.. the error message I got wasn't too obvious That might still leave plain 389-ds-base multimaster replication in the dust though, but I'm not interested in that personally.. Building a second libldap against moznss might be possible, but looks icky.. Icky indeed. Based on what you wrote above, sounds like that probably won't be worth the effort, if it won't be needed in future. So as I understand it: this bug is basically wontfix in the official package at this point; you're (already?) providing an unofficial nss-libldap that freeipa users can drop in to replace the gnutls-libldap; and nothing has to be rebuilt to take advantage of that. Do I have that right? Well, my quick testing shows that a simple library swap isn't enough, but 389 probably needs a rebuild against the new lib. Or replication fails because of something unrelated to this.. don't have much time to test anything in the next couple of weeks. -- t -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780461: updates from #debian-systemd
On Mon, Apr 20, 2015 at 11:00:17PM +0200, Petter Reinholdtsen wrote: Could this be caused by dhclient running at a point during boot where /etc/ is read-only, causing /usr/sbin/update-hostname-from-ip to exit with an error code instead of updating the hostname? It is my best guess for why the hostname update wait for the first renewal. Seems to be /etc is writable at the time. Maybe the reason is that 'BOUND' isn't evaluated, only 'RENEWAL'? (2) For Profiles 'Workstation' and 'Minimal' the hook script is working like stated above. But LTSP-Servers may have PROFILE=Workstation, Thin-Client-Server set in /etc/debian/edu/config. The hook script IMO fails to update the hostname cause there's no matching case entry. I guess I'll file a separate bug about this issue to get it sorted. Also, why is the sethostname() function in the dhclient-exit-hooks.d/hostname script? It seem to be completely unused. Remove it? Yes, seems to be leftover cruft. And the log() function could be dropped as well; logging is done via the update-hostname-from-ip script. Wolfgang -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782915: release-notes: please add news from Debian GIS to release notes
On Tue, Apr 21, 2015 at 10:19:19AM +0100, Justin B Rye wrote: incorporated sounds fine to me as is. BTW, my toothcomb is not as fine as Justin's. :) Incorporated into Debian GIS and merged back into both look good to me. I was wondering if we needed to expand GIS at some point, but there's no obvious place to fit it in. Maybe OSGeo is enough of a hint... I agree that for not involved people Geographical Information Systems might be helpful to spell out. May be it is even better to link to the Debian GIS homepage https://wiki.debian.org/DebianGis ? Thanks for pointing this out Andreas. -- 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#749320: evince: selecting the print menu entry make evince segfault
samuel@jessie-desktop:~$ gdb evince GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from evince...Reading symbols from /usr/lib/debug//usr/bin/evince...done. done. (gdb) run Starting program: /usr/bin/evince [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7fffee04c700 (LWP 6010)] [New Thread 0x7fffe7fff700 (LWP 6011)] [New Thread 0x7fffe77fe700 (LWP 6012)] [New Thread 0x7fffe6ffd700 (LWP 6013)] [Thread 0x7fffe7fff700 (LWP 6011) exited] [New Thread 0x7fffe7fff700 (LWP 6019)] [New Thread 0x7fffe5d4c700 (LWP 6020)] [New Thread 0x7fffe554b700 (LWP 6021)] [New Thread 0x7fffe4d4a700 (LWP 6022)] [New Thread 0x7fffc700 (LWP 6023)] [New Thread 0x7fffcf7fe700 (LWP 6024)] [Thread 0x7fffe4d4a700 (LWP 6022) exited] [Thread 0x7fffcf7fe700 (LWP 6024) exited] [Thread 0x7fffe5d4c700 (LWP 6020) exited] [Thread 0x7fffc700 (LWP 6023) exited] [Thread 0x7fffe7fff700 (LWP 6019) exited] [New Thread 0x7fffe7fff700 (LWP 6031)] [New Thread 0x7fffc700 (LWP 6038)] [New Thread 0x7fffe5d4c700 (LWP 6039)] [New Thread 0x7fffcf7fe700 (LWP 6040)] [New Thread 0x7fffcde2f700 (LWP 6041)] [New Thread 0x7fffcd62e700 (LWP 6042)] [New Thread 0x7fffcce2d700 (LWP 6043)] [New Thread 0x7fffbdfff700 (LWP 6044)] [Thread 0x7fffcde2f700 (LWP 6041) exited] [Thread 0x7fffcce2d700 (LWP 6043) exited] [Thread 0x7fffc700 (LWP 6038) exited] [Thread 0x7fffe554b700 (LWP 6021) exited] [Thread 0x7fffcf7fe700 (LWP 6040) exited] [Thread 0x7fffe5d4c700 (LWP 6039) exited] [Thread 0x7fffbdfff700 (LWP 6044) exited] [Thread 0x7fffcd62e700 (LWP 6042) exited] [New Thread 0x7fffcd62e700 (LWP 6051)] [New Thread 0x7fffbdfff700 (LWP 6053)] [Thread 0x7fffbdfff700 (LWP 6053) exited] [Thread 0x7fffcd62e700 (LWP 6051) exited] Program received signal SIGSEGV, Segmentation fault. 0x77016c64 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (gdb) bt Python Exception class 'gdb.MemoryError' Cannot access memory at address 0x7fffdbc8: #0 0x77016c64 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 Cannot access memory at address 0x7fffdbc8 (gdb)
Bug#782996: smsd: 'reload' function of initscript broken if used by systemd
Am 2015-04-21 15:15, schrieb Jonas Meurer:
See the attached patch for a proper fix.
I attached an updated patch.
Argh, this time with the updated patch :)
Cheers,
jonasdiff -rNu smstools-3.1.15.orig/debian/changelog smstools-3.1.15/debian/changelog
--- smstools-3.1.15.orig/debian/changelog 2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/changelog 2015-04-21 15:13:32.668376587 +0200
@@ -1,3 +1,17 @@
+smstools (3.1.15-1.2) unstable; urgency=high
+
+ * NMU by Jonas Meurer to push the fix into Jessie.
+ * Fix initscript (debian/init.d):
+* drop action 'reload' as it does not what policy demands it to do. Use
+ 'force-reload' in logrotate post-rotate action. This fixes 'force-reload'
+ action when used through systemd tools and prevents the smsd daemon
+ process from being killed at every log rotation. (closes: #XX)
+* source /lib/lsb/init-functions in order to make systemd tools aware of
+ status changes to the daemon that have been caused by invoking the
+ initscript directly.
+
+ -- Jonas Meurer jo...@freesources.org Mon, 20 Apr 2015 11:46:53 +0200
+
smstools (3.1.15-1.1) unstable; urgency=low
* NMU - preventing smstools from entering jessie.
diff -rNu smstools-3.1.15.orig/debian/init.d smstools-3.1.15/debian/init.d
--- smstools-3.1.15.orig/debian/init.d 2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/init.d 2015-04-21 14:54:45.444351751 +0200
@@ -25,6 +25,8 @@
test -x $DAEMON || exit 0
+. /lib/lsb/init-functions
+
if [ ! -f /etc/default/$PACKAGE ]
then
exit 1
@@ -218,17 +220,6 @@
echo $NAME.
;;
- reload)
- echo -n Reloading $DESC:
- status
- if [ $? = 0 ]; then
- stop restart
- start
- else
- echo $NAME is not running.
- fi
-
- ;;
restart|force-reload)
echo -n Restarting $DESC:
@@ -237,7 +228,7 @@
;;
*)
- echo Usage: /etc/init.d/$NAME {start|stop|force-stop|reload|force-reload|restart|status}
+ echo Usage: /etc/init.d/$NAME {start|stop|force-stop|force-reload|restart|status}
exit 3
;;
esac
diff -rNu smstools-3.1.15.orig/debian/logrotate smstools-3.1.15/debian/logrotate
--- smstools-3.1.15.orig/debian/logrotate 2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/logrotate 2015-04-20 11:46:50.426199696 +0200
@@ -4,6 +4,6 @@
compress
missingok
postrotate
-invoke-rc.d smstools reload /dev/null
+invoke-rc.d smstools force-reload /dev/null
endscript
}
Bug#782371: thunar: Random sefaults GLib-CRITICAL **: g_sequence_get: assertion '!is_end (iter)' failed
Package: thunar Version: 1.6.3-2 Followup-For: Bug #782371 Try to enable coredumps (ulimit -c unlimited), then restart thunar from that shell (thunar -q; thunar). If it crashes, you should get a core dump which can be used with gdb. I've done all this now testing will report back in a week or when I get a coredump. Kitty -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780461: updates from #debian-systemd
[Wolfgang Schweer] Seems to be /etc is writable at the time. Maybe the reason is that 'BOUND' isn't evaluated, only 'RENEWAL'? I tought both were handled in the script? Is there something wrong with that part? I guess I'll file a separate bug about this issue to get it sorted. Yeah. Also, why is the sethostname() function in the dhclient-exit-hooks.d/hostname script? It seem to be completely unused. Remove it? Yes, seems to be leftover cruft. And the log() function could be dropped as well; logging is done via the update-hostname-from-ip script. Also a separate issue. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
On Monday 13 April 2015 05:52 AM, Mauricio Faria de Oliveira wrote: Oops, please use this version (-v2). When the forwarded patch is applied in the source package, the change ends up in cciss_sysfs_pathinfo() rather than scsi_sysfs_pathinfo(): Hunk #1 succeeded at 783 (offset -312 lines). This version has the change in the right place, plus quilt refresh. Hi Mauricio, Is this been merged upstream ? -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
On Wed, 25 Dec 2013 17:33:04 +0100 Ralf Jung p...@ralfj.de wrote: Dear maintainer, adding the attached systemd unit fixes restoring the hdparm configuration when systemd is used. I'd appreciate if you could add this (or a similar solution) to the package. This proposed patch doesn't work as-is, due to a misunderstanding how targets work: After=suspend.target After=hibernate.target After=hybrid-sleep.target This doesn't guarantee that the service is run on resume. Those targets are activated on suspend/hibernate, so there is a race and you might actually run /usr/lib/pm-utils/power.d/95hdparm-apm *before* the system is suspended. You'd have to order this service after the *service* which does the actual suspend. Even though upstream recommends against shipping a snippet in /lib/systemd/system-sleep/ and considers them hacks, I actually think this is the cleanest/simplest solution here $ cat /lib/systemd/system-sleep/hdparm #!/bin/sh case $1 in post) /usr/lib/pm-utils/power.d/95hdparm-apm resume ;; esac [1] man systemd-sleep -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#783064: Can't ssh into newly installed domU jessie instances
Package: xen-tools Version: 4.5-1 Severity: normal Hi Using a jessie dom0, after the creation of a domU instance running jessie, one get a message like: Installation Summary - Hostname: medusa Distribution: jessie MAC Address : 00:12:34:56:78:0A IP Address(es) : 192.168.1.10 RSA Fingerprint : 11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00 Root Password : passwordpasswordpasswor We have the IP address, the SSH RSA fingerprint and the password, so it looks natural to try to use ssh. However, since jessie, root login with just a password is disabled. We need a key. So this doesn't work. It would be nice to patch the new installed instance to allow ssh root@ logins. Or maybe copy the ssh key, if any, as an authorized_key? At the very least, a hint to use xl console rather than ssh would be nice. Thanks -- System Information: Debian Release: 8.0 signature.asc Description: OpenPGP digital signature
Bug#783063: Xen domU freeze with Guest Rx stalled
On Tue, 2015-04-21 at 13:31 +0200, Wolodja Wentland wrote: Package: src:linux Version: 3.16.7-ckt4-3~bpo70+1 Severity: important Hello, ever since upgrading some of our Xen dom0s to the kernel in backports at that time (3.16.7-ckt4-3~bpo70+1) we are seeing domU freezes with output such as: [2951591.712865] vif vif-1-0 vif1.0: Guest Rx stalled [2951591.713145] public: port 2(vif1.0) entered disabled state and a normal shutdown fails with: [2015-04-21 11:24:03 3895] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch [2015-04-21 11:27:02 3895] INFO (XendDomainInfo:2114) Domain shutdown timeout expired: name=foo-domU1 id=1 [2015-04-21 11:28:02 3895] DEBUG (XendDomainInfo:524) XendDomainInfo.shutdown(poweroff) OOI what is your dom0 environment/versions etc? so that we had to destroy it for it to (re-)boot. It should be noted that we have not yet seen this problem on PVHVM guests, but only on PV ones. The domains are shown as running (state r), but do not react to any commands. It seems like it has deadlocked, but I don't know if that is a Xen issue or some generic issue. A patch that *might* be related is xen-netback-reintroduce-guest-Rx-stall-detection.patch (cf. [0]), but we are not sure about that yet. This should be in the kernel you are running already, it was added in 3.16.7-ckt2. Anyway, bpo now contains 3.16.7-ckt7-1~bpo70+1 which includes quite a few stable updates over the version you are running. Please could you try that. There is a fair bit of stuff only in jessie in the 3.16.7-ckt9-2. Not sure when that is due to hit bpo though. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783065: ITP: python-guacamole -- library for command line applications for Python
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki zygmunt.kryni...@canonical.com * Package name: python-guacamole Version : 0.8 Upstream Author : Zygmunt Krynicki zygmunt.kryni...@canonical.com * URL : https://github.com/zyga/guacamole * License : LGPL, BSD Programming Lang: Python Description : library for command line applications for Python Guacamole is a flexible, modular system for creating command line applications. Guacamole comes with built-in support for writing command line applications that integrate well with the running system. A short list of supported features (ingredients) includes: .. - handling flat and hierarchical commands - hassle-free crash detection - hassle-free logging - internationalization and localization .. The guacamole ingredient system allows for third party add-ons. I want to maintain this library in DPMT, along with my other work. The package will be adopted as a new dependency of the plainbox and checkbox-ng packages in the next few releases. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782363: multipath-tools-boot: include dm-service-time in initramfs (new default path selector)
On Saturday 11 April 2015 04:29 AM, Mauricio Faria de Oliveira wrote: May you please consider the attached patch for an upload for jessie? # gzip -dc /boot/initrd.img | cpio -t | grep dm-service-time 118384 blocks lib/modules/.../kernel/drivers/md/dm-service-time.ko Thanks! Links: [1] http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=c015b128103e7a6426d124a38cd679a181573b88 Sorry. I haven't been on top of it. I'll push it for unstable for now. Later we'll do an s-p-u and propose it for jessie. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Bug#782996: smsd: 'reload' function of initscript broken if used by systemd
Hi again, Am 2015-04-20 11:55, schrieb Jonas MEURER: The bug can be fixed by renaming the 'reload' function to 'force-reload' and dropping the original 'force-reload' alias for 'restart'. Please note, that fixing the 'Usage:' line by dropping 'reload' from the list of supported actions is important as well. Otherwise, systemd tools try to invoke 'reload' even if 'force-reload' is given as argument. in some further discussion on IRC channel #debian-systemd, Michael Biebl made me aware that my fix was not policy-compliant. According to Debian Policy, 'force-reload' should reload the service if this function is available, and restart otherwise. Therefore I reverted the change to add a separate 'force-reload' action and kept 'force-reload' as an alias to 'restart'. Only the 'reload' option was dropped. Additionally, I added a line at the beginning of the initscript, sourcing '/lib/lsb/init-functions'. This is necessary to make systemd aware of status changes to the daemon that have been caused by running the initscript directly (i.e. not through systemd helper tools). This change is really non-intrusive and leads to a much better user experience. See the attached patch for a proper fix. I attached an updated patch. I consider this bug as release-critical for Jessie, as it renders smmstools unusable on Jessie installations whenever logrotate is installed. Thus I suggest to push the fix into Jessie within the next days. I'll gladly do an NMU if the maintainer(s) don't have the time to push this fix into Jessie in time. According to release managers, this update won't make it into Jessie, which is already in the quiet period (shortly before release). Instead, a fixed package should be uploaded to stable-proposed-updates in order to make it into the first point release of Jessie (8.1). If nobody speaks up, then I intend to upload the NMU to unstable next week, wait one or two weeks and upload to stable-proposed-updates afterwards. Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: Bug#779412: block devices loosing state after resume: trigger udev rules to re-apply settings
Am 28.02.2015 um 09:30 schrieb Chris: A draft for such a central systemd unit file: [Unit] Description=Trigger all block device udev rules on resume, to re-apply all non-permanent device settings (e.g. smartctl and hdparm rules). After=suspend.target After=hibernate.target After=hybrid-sleep.target This does not work. Ordering After=foo.target does *not* guarantee that the service is run on resume. I already mentioned that, when a similar file was added to anacron [1]. Unfortunately it was applied anyway and now this file is copied over and over again and posted to various bug reports. Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744753#124 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#783034: [Pkg-octave-devel] Bug#783034: octave-ltfat breaks Octave rcond. Yields segmentation fault
* Charlie Hagedorn charlie.haged...@gmail.com [2015-04-20 16:14]: I agree that there's no obvious way for a subcomponent package to affect a core-compiled function, but I see this effect on all three machines I have access to today, all running testing ( vanilla testing install, upgraded crouton install, upgraded Compute Engine instance) . For the machines where I initially discovered this crashing problem, uninstalling the ltfat package appears to have resolved the problem with rcond completely. The fact that I cannot replicate the bug does not mean that the problem does not exist. It only means that the problem cannot be confidently diagnosed. I am afraid we will be able to act on this bug report only after the root of the problem gets exposed. Thanks, Rafael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736879: subversion: svn seg faults checking out new working copy and kwallet is invoked for storing password
Package: subversion Version: 1.8.10-6 Followup-For: Bug #736879 Hi, this bug still exists in Debian Jennie RC2. I can also confirm that Bernhard's workaround using svn cleanup and svn update does work. Here's a backtrace (sorry, no debug symbols): (gdb) bt #0 0x7fffefb100a6 in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1 #1 0x77055622 in svn_auth.simple_creds_cache_set () from /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1 #2 0x7fffefb0fa5a in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1 #3 0x7702cdf5 in svn_auth_save_credentials () from /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1 #4 0x75711fbb in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1 #5 0x737cf45e in serf.process_connection () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1 #6 0x737cdcee in serf_event_trigger () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1 #7 0x737cde0c in serf_context_run () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1 #8 0x7571082a in svn_ra_serf.context_run_wait () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1 #9 0x757119b4 in svn_ra_serf.context_run_one () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1 #10 0x75704950 in svn_ra_serf.exchange_capabilities () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1 #11 0x7570a367 in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1 #12 0x776c0e7d in svn_ra_open4 () from /usr/lib/x86_64-linux-gnu/libsvn_ra-1.so.1 #13 0x77bbfc0a in svn_client.open_ra_session_internal () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1 #14 0x77bc5b08 in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1 #15 0x77bc645a in svn_client.update_internal () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1 #16 0x77b8d0f6 in svn_client.checkout_internal () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1 #17 0x77b8d253 in svn_client_checkout3 () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1 #18 0x00408023 in ?? () #19 0x0041ba1e in ?? () #20 0x00406b77 in ?? () #21 0x76837b45 in __libc_start_main (main=0x406b30, argc=5, argv=0x7fffe1b8, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffe1a8) at libc-start.c:287 #22 0x00406bb3 in ?? () -Jonni -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783052: mget * fails with %-encoded filenames
Package: cadaver Version: 0.23.3-2+b2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I’m trying to use cadaver to mirror a CalDAV directory (on an owncloud 7 server). After issueing mget *, it succeeds downloading some files, but fails downloading every file with a % sign in the filename: Progress: [=] 100,0% of 1010 bytes succeeded. Downloading `/remote.php/caldav/calendars/nomeata/kalender/libkcal-1057146098.315.ics' to libkcal-1057146098.315.ics: Progress: [=] 100,0% of 1217 bytes succeeded. Downloading `/remote.php/caldav/calendars/nomeata/kalender/fcf77b82-10cb-420e-ae9a-22f5bdee8b78.ics' to fcf77b82-10cb-420e-ae9a-22f5bdee8b78.ics: Progress: [=] 100,0% of 830 bytes succeeded. Downloading `/remote.php/caldav/calendars/nomeata/kalender/f9c68050-6ce1-4da8-afd9-1c4ec4a94965.ics' to f9c68050-6ce1-4da8-afd9-1c4ec4a94965.ics: Progress: [=] 100,0% of 375 bytes succeeded. Downloading `/remote.php/caldav/calendars/nomeata/kalender/event_bxwjglytjbwb%2540meetup.com.ics' to event_bxwjglytjbwb%40meetup.com.ics: Progress: [=] 100,0% of 267 bytes failed: 404 Not Found Downloading `/remote.php/caldav/calendars/nomeata/kalender/event_95958352%2540meetup.com.ics' to event_95958352%40meetup.com.ics: Progress: [=] 100,0% of 267 bytes failed: 404 Not Found Using firefox, I can get the file at the URL /remote.php/caldav/calendars/nomeata/kalender/event_bxwjglytjbwb%40meetup.com.ics but not at the URL /remote.php/caldav/calendars/nomeata/kalender/event_bxwjglytjbwb%2540meetup.com.ics tried by cadaver. It seems that cadaver does unnecessary additional URL encoding here. Greetings, Joachim - -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cadaver depends on: ii libc6 2.19-18 ii libgcrypt201.6.3-2 ii libgnutls-deb0-28 3.3.8-7 ii libncurses55.9+20140913-1+b1 ii libneon27-gnutls 0.30.1-1 ii libreadline6 6.3-8+b3 ii libtinfo5 5.9+20140913-1+b1 ii libxml22.9.2+dfsg1-3 cadaver recommends no packages. cadaver suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlU2EvUACgkQ9ijrk0dDIGw7lgCfYXPSHnNBbf27UQBl8+qvGe4G +eUAn18U2sAz6hRIZ/bEAkBCBT/AulIm =xGG/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749320: evince: selecting the print menu entry make evince segfault
... and once again with libgtk-3-0-dbg [...] Starting program: /usr/bin/evince [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7fffee04c700 (LWP 6627)] [New Thread 0x7fffe7fff700 (LWP 6628)] [New Thread 0x7fffe77fe700 (LWP 6629)] [New Thread 0x7fffe6ffd700 (LWP 6630)] [New Thread 0x7fffe5d4c700 (LWP 6633)] [New Thread 0x7fffe554b700 (LWP 6634)] [New Thread 0x7fffe4d4a700 (LWP 6635)] [New Thread 0x7fffc700 (LWP 6636)] [New Thread 0x7fffcf7fe700 (LWP 6637)] [Thread 0x7fffcf7fe700 (LWP 6637) exited] [Thread 0x7fffe4d4a700 (LWP 6635) exited] [Thread 0x7fffc700 (LWP 6636) exited] [Thread 0x7fffe554b700 (LWP 6634) exited] [Thread 0x7fffe5d4c700 (LWP 6633) exited] [New Thread 0x7fffe5d4c700 (LWP 6646)] [New Thread 0x7fffe554b700 (LWP 6649)] [New Thread 0x7fffc700 (LWP 6650)] [New Thread 0x7fffe4d4a700 (LWP 6651)] [New Thread 0x7fffcdeb5700 (LWP 6652)] [New Thread 0x7fffcd6b4700 (LWP 6653)] [New Thread 0x7fffcceb3700 (LWP 6654)] [New Thread 0x7fffc1fff700 (LWP 6655)] [Thread 0x7fffe4d4a700 (LWP 6651) exited] [Thread 0x7fffcd6b4700 (LWP 6653) exited] [Thread 0x7fffc1fff700 (LWP 6655) exited] [Thread 0x7fffe7fff700 (LWP 6628) exited] [Thread 0x7fffcdeb5700 (LWP 6652) exited] [Thread 0x7fffc700 (LWP 6650) exited] [Thread 0x7fffe554b700 (LWP 6649) exited] [Thread 0x7fffcceb3700 (LWP 6654) exited] Program received signal SIGSEGV, Segmentation fault. gtk_tree_model_filter_row_deleted (c_model=optimized out, c_path=0xea7e00, data=0xe6f170) at /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtktreemodelfilter.c:2580 2580/tmp/buildd/gtk+3.0-3.14.5/./gtk/gtktreemodelfilter.c: Datei oder Verzeichnis nicht gefunden. (gdb)
Bug#648208: os-prober: blockdev --setro affects running kvm instances
Package: os-prober Version: = 1.65 Since version 1.45, os-prober instead uses grub-mount when it's available -- and if grub is installed to use os-prober, it will pull it in. So unless another bootloader is also using os-prober, or someone installs and uses it by hand, this won't happen in unstable/testing. It's not really the case: Using grub-2.02_beta2 and os-prober-1.65 If there is a KVM virtual machine using an ext4 FS on LVM and writing on it, a simple grub-mkconfig on, the server(hypervisor) create disk I/O errors on the virtual machine. So this problem is a real one. You can reproduce it easily: - Inside a KVM virtual machine: - execute a dd that write on disk - display with tail -f the kernel log (/var/log/messages) - On the hypervisor/server: - execute a grub-mkconfig with os-prober activated = You got bunches of I/O error in the virtual machine. Inactivate os-prober is not a realistic solution because there is situation where you need OS prober: automatic grub configuration file creation that take in consideration an emergency system on another partition that need os-prober to be detect for example. Another example is cluster of servers using different partitions as system upgrade path for easy roll-back. Jean-François Maeyhieux (zentoo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782999: PDF-Rendering fails with textboxes and frames above
Hi, On Mon, Apr 20, 2015 at 02:10:02PM +0200, Rene Engelhard wrote: On Mon, Apr 20, 2015 at 12:53:20PM +0200, Joerg Schiermeier, Bielefeld/Germany wrote: Package: libreoffice-writer Version: 1:4.3.3-2 Severity: normal Hi! There is a problem with PDF export from ODT files generated with Libreoffice-Writer. The situation: I have two textboxes in a letter, one for my adress as sender and one with my complete adress and some more infos. Below this textboxes is one layer with a grey pattern. Exported to PDF this pattern is discontinued always where the textboxes are. I tried also with OpenOffice: no problems. please try with 4.4.2 (as in experimental). 4.3.3 will not receive fixes unless they are release-critical and/or security; neither of which this is. Oh, and if you want me to try myself please send a test document, I don't think your instructions are enough to make a document exactly looking like yours to reproduce. Not to say I fail to even create e text document with text boxes here ;) Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783005: suricata: ships embedded libhtp and can conflict with a future libhtp update
On Tue, Apr 21, 2015 at 08:39:16AM +0200, Raphael Hertzog wrote: Hi, On Mon, 20 Apr 2015, Hilko Bengen wrote: * Raphaël Hertzog: But libhtp is already packaged separately. Embedded copy are best avoided and to me it looks like #777040 got fixed the wrong way. libhtp should be fixed to have a saner SONAME and/or it should generate a strict dependency through its shlibs/symbols files. Is it your goal to get this fixed in jessie before the release or can this wait? Well, no, given that the release managers acked the embedded copy in jessie... but in the long term it's wrong to keep it that way. Hi, [adding Arturo to CC list] Bug #777540 has the history of why libhtp was embedded into the suricata package. In short, the SONAME are updated by every upstream release, forcing a rebuild of all rev-deps each time a new libhtp is uploaded (note that the only rev-dep is suricata). We asked the release team with different solutions, and the chosen was to embed libhtp. Now, I'm a bit confused about what to do now, since there are problems both ways. Arturo: I thought the plan was to keep the current situation, and remove libhtp from Debian ? BR, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782777: [Aptitude-devel] Bug#782889: aptitude: forget-new option doesn't work
On Sun, 19 Apr 2015 17:39:36 +0200 Axel Beckert a...@debian.org wrote: Domenico Cufalo wrote: 1) My sources list is pure: only jessie! That's an unexpected and interesting turn! Thanks for that information! Hi, Just wanted to let you know that experimental in sources list does not seem necessary to trigger the bug, but having newer versions of some (any?) packages installed does. The problem does not appear on my pure sid system, but does appear on a system with sid and some third-party repositories (mysql, deb-multimedia or opera, for example). That system does not have nor never have had experimental in sources list. On that system, the problem persits after disabling all the third-party repositories, leaving only sid sources list. Is there any other additional info you'd like me to provide? Michal K. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783058: rquantlib: Please make build reproducible
Package: rquantlib
Version: 0.4.0-2
Severity: wishlist
Tags: patch
Hi Dirk,
I guess you know what it's about.
Here just a patch for your d/rules to make rquantlib build reproducible.
Best,
Philip
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- rules.orig 2015-04-21 12:06:05.564822000 +0200
+++ rules 2015-04-21 12:07:03.037757165 +0200
@@ -9,6 +9,7 @@
ifneq $(makeFlags)
makeFlagsCall := MAKEFLAGS=$(makeFlags)
endif
+builttime := $(shell dpkg-parsechangelog | awk -F': ' '/Date/ {print $$2}')
## override R_any_arch here do pass CXXFLAGS
R_any_arch:
@@ -17,7 +18,7 @@
## call R to install the sources we're looking at
## dial down CXXFLAGS
$(makeFlagsCall) \
- R CMD INSTALL -l $(debRlib) --clean .
+ R CMD INSTALL -l $(debRlib) --clean --built-timestamp=${builttime} .
## remove extra files which are present in some packages
rm -vf $(debRlib)/R.css \
$(debRlib)/$(cranName)/COPYING \
Bug#782915: release-notes: please add news from Debian GIS to release notes
On Tue, Apr 21, 2015 at 08:23:54AM +0200, Niels Thykier wrote: Hi, Thanks for the proposed text. On 2015-04-20 14:48, Andreas Tille wrote: On Mon, Apr 20, 2015 at 05:57:07PM +1200, Chris Bannister wrote: On Sun, Apr 19, 2015 at 08:44:33PM +0200, Andreas Tille wrote: During the jessie development cycle many changes from UbuntuGIS were incorporated (back) into Debian GIS. The collaboration with UbuntuGIS The '(back)' is redundant here. But it an important change to the situation at the last release. Can we perhaps do with a merged back into? CC'ing Justin for a 4th incorporated sounds fine to me as is. BTW, my toothcomb is not as fine as Justin's. :) -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783053: hdav needs better docs and/or a manpage
Package: hdav Version: 1.0.2-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Clint, Haskell-unrelated bug :-) I am looking for a program that allows me to mirror my CalDAV and CardDAV data to the file system. Cadaver didn't cut it for me, so I stumbled over hdav. Unfortunately, the documentation is sparse, and I was neither able to tell whether hdav actually writes to files, and also what the precise syntax for URLs are. Granted, while writing this report I noticed that calling hdav command without options gives further hints; maybe that should be mentioned in the output of hdav. Greetings, Joachim - -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hdav depends on: ii libc6 2.19-18 ii libffi6 3.1-2+b2 ii libgmp10 2:6.0.0+dfsg-6 ii libicu52 52.1-8 ii zlib1g1:1.2.8.dfsg-2+b1 hdav recommends no packages. hdav suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlU2FIAACgkQ9ijrk0dDIGzRfgCfa49hZ+5eBxfEXsKPSxliGW2Z myUAn2nDzcNV3E6iR8/sbla9WGq0quu3 =Z1W0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783054: mklibs-readelf does not list symbols of GNU unique type as provided
Package: mklibs Version: 0.1.40 Severity: important Tags: patch Dear Maintainer, * What led up to the situation? GNU unique symbol bind type is introduced, and enabled by GCC 4.9 to address some certain binding problems. The Standard C++ library from GCC as a result, uses this binding type for some of the symbols. However, mklibs-readelf does not treat any symbol other than STB_WEAK or STB_GLOBAL as provided by library. The issue randers some symbols false 'unresolvable' when trying to generate minimal library set. * What exactly did you do (or not do) that was effective (or ineffective)? mklibs-readelf --print-symbols-provided /usr/lib/x86_64-linux-gnu/libstdc++.so.6 \ | grep empty_rep_storage * What was the outcome of this action? Nothing, so the symbol is `not provided'. * What outcome did you expect instead? _ZNSs4_Rep20_S_empty_rep_storageE False GLIBCXX_3.4 True _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE False GLIBCXX_3.4 True -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.19.2-1-ARCH (SMP w/8 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages mklibs depends on: ii binutils 2.25-6 ii dpkg-dev 1.17.25 ii gcc 4:4.9.2-2 ii mklibs-copy 0.1.40 ii python 2.7.9-1 Versions of packages mklibs recommends: ii libc6-pic 2.19-18 mklibs suggests no packages. -- no debconf information From eddf04c7f8312e9c29cdb24e431b7e4fb2cc70ed Mon Sep 17 00:00:00 2001 From: Yuanjie Huang yuanjie.hu...@windriver.com Date: Wed, 15 Apr 2015 14:00:06 +0800 Subject: [PATCH] Show GNU unique symbols as provided symbols GNU Unique symbol is a GNU extension employed by new version of GCC by default. Even Standard C++ library in GCC 4.9 provides some symbols, such as _ZNSs4_Rep20_S_empty_rep_storageE in this binding type instead of ELF standard weak binding. This patch adds support of this new binding type to mklibs-readelf. Signed-off-by: Yuanjie Huang yuanjie.hu...@windriver.com --- src/mklibs-readelf/main.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mklibs-readelf/main.cpp b/src/mklibs-readelf/main.cpp index 56d93f8..0134530 100644 --- a/src/mklibs-readelf/main.cpp +++ b/src/mklibs-readelf/main.cpp @@ -88,7 +88,7 @@ static void process_symbols_provided (const Elf::section_typeElf::section_type_ uint8_t type = symbol-get_type (); const std::string name = symbol-get_name_string (); -if (bind != STB_GLOBAL bind != STB_WEAK) +if (bind != STB_GLOBAL bind != STB_WEAK bind != STB_GNU_UNIQUE) continue; if (shndx == SHN_UNDEF || shndx == SHN_ABS) continue; -- 1.8.5.2.233.g932f7e4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783057: r-cran-readmzxmldata: Please make build reproducible
Package: r-cran-readmzxmldata
Version: 2.8-1
Severity: wishlist
Tags: patch
Hi,
with GNU R = 3.2.0 it's possible to have reproducible builds. See
https://bugs.debian.org/774031 and https://bugs.debian.org/782764 for
reference.
I attached a patch for your d/rules that adopts the proposed behavior form
#782764.
Best,
Philip
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- rules.orig 2015-04-21 11:59:44.590612000 +0200
+++ rules 2015-04-21 12:00:32.259391093 +0200
@@ -10,6 +10,7 @@
CRANVERSION ?= $(shell uscan --no-conf --dehs | sed -n 's/.*upstream-version\([0-9.]\+\)\/upstream-version.*/\1/p')
RVERSION := $(shell grep Depends: R DESCRIPTION | sed 's/.*(\([= 0-9.]\+\)).*/\1/')
RLIB := usr/lib/R/site-library
+builttime := $(shell dpkg-parsechangelog | awk -F': ' '/Date/ {print $$2}')
%:
dh $@
@@ -32,7 +33,7 @@
echo R:Depends=r-base-core (${RVERSION}) debian/${PACKAGE}.substvars
## install r package
- MAKEFLAGS=CFLAGS+=${CFLAGS} CPPFLAGS+=${CPPFLAGS} LDFLAGS+=${LDFLAGS} R CMD INSTALL --library=${CURDIR}/debian/${PACKAGE}/${RLIB} --clean .
+ MAKEFLAGS=CFLAGS+=${CFLAGS} CPPFLAGS+=${CPPFLAGS} LDFLAGS+=${LDFLAGS} R CMD INSTALL --library=${CURDIR}/debian/${PACKAGE}/${RLIB} --clean --built-timestamp=${builttime} .
get-orig-source:
## download newest ${PACKAGE} from CRAN
Bug#755551: will the fix ever end up to Debian jessie?
Yves-Alexis Perez wrote: We believe that the bug you reported is fixed in the latest version of xfce4-power-manager, which is due to be installed in the Debian FTP archive. I can confirm that the bug is fixed in xfce4-power-manager 1.4.4-1, which I installed from experimental archives. Will version 1.4.4 of xfce4-power-manager ever make it to Debian jessie or to jessie backports? -- Juha -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782777: [Aptitude-devel] Bug#782777: Bug#782889: aptitude: forget-new option doesn't work
Hi Michał, Michał Klichowicz wrote: On Sun, 19 Apr 2015 17:39:36 +0200 Axel Beckert a...@debian.org wrote: Domenico Cufalo wrote: 1) My sources list is pure: only jessie! That's an unexpected and interesting turn! Thanks for that information! Just wanted to let you know that experimental in sources list does not seem necessary to trigger the bug, but having newer versions of some (any?) packages installed does. Interesting thought. But I can't confirm it unfortunately: * I've got one machine (Testing preferred, but with Sid and Experimental in sources.list, too) where apt-show-versions | fgrep newer gives no output, but which has the symptoms. * And I've got one machine (pure Jessie) where apt-show-versions | fgrep newer shows one package (ballerburg FTR, where I tested a to be sponsored package) and it doesn't have the symptoms. The problem does not appear on my pure sid system, but does appear on a system with sid and some third-party repositories (mysql, deb-multimedia or opera, for example). On that system, the problem persits after disabling all the third-party repositories, leaving only sid sources list. Interesting, thanks for that fact. Did you do an apt-get update or equivalent after removing the 3rd party repos? I'll try the same with some of my machines. Is there any other additional info you'd like me to provide? Not at the moment, but thanks for the offer. I may get back to it. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783051: ipxe: ISO image appears to be empty
Package: ipxe Version: 1.0.0+git-20141004.86285d1-1 Severity: normal Hi! The ISO image shipped in ipxe seems to be empty. It doesn't boot in qemu. While building the package in pbuilder, I see: ISOLINUX_BIN=/usr/lib/syslinux/ VERSION=1.0.0+git-20141004.86285d1-1 bash util/geniso -o bin/ipxe.iso bin/ipxe.lkrn cp: omitting directory '/usr/lib/syslinux/' genisoimage: Uh oh, I cant find the boot image 'isolinux.bin' ! -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#783055: ITP: python-txaio -- compatibility API between asyncio/Twisted/Trollius
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-txaio Version : 1.0.0 Upstream Author : Tavendo GmbH autobah...@googlegroups.com * URL : https://github.com/tavendo/txaio * License : Expat Programming Lang: Python Description : compatibility API between asyncio/Twisted/Trollius Txaio is a helper library for writing code that runs unmodified on both Twisted and asyncio. . This is like six , but for wrapping over differences between Twisted and asyncio so one can write code that runs unmodified on both (aka source code compatibility). In other words: users can choose if they want asyncio or Twisted as a dependency. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782915: release-notes: please add news from Debian GIS to release notes
Chris Bannister wrote: On Tue, Apr 21, 2015 at 08:23:54AM +0200, Niels Thykier wrote: Hi, Thanks for the proposed text. On 2015-04-20 14:48, Andreas Tille wrote: On Mon, Apr 20, 2015 at 05:57:07PM +1200, Chris Bannister wrote: On Sun, Apr 19, 2015 at 08:44:33PM +0200, Andreas Tille wrote: During the jessie development cycle many changes from UbuntuGIS were incorporated (back) into Debian GIS. The collaboration with UbuntuGIS The '(back)' is redundant here. But it an important change to the situation at the last release. Can we perhaps do with a merged back into? CC'ing Justin for a 4th incorporated sounds fine to me as is. BTW, my toothcomb is not as fine as Justin's. :) Incorporated into Debian GIS and merged back into both look good to me. I was wondering if we needed to expand GIS at some point, but there's no obvious place to fit it in. Maybe OSGeo is enough of a hint... -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783056: r-cran-readbrukerflexdata: Please make build reproducible
Package: r-cran-readbrukerflexdata
Version: 1.8-1
Severity: wishlist
Tags: patch
Hi,
with GNU R = 3.2.0 it's possible to have reproducible builds. See
https://bugs.debian.org/774031 and https://bugs.debian.org/782764 for
reference.
I attached a patch for your d/rules that adopts the proposed behavior form
#782764.
Best,
Philip
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- rules.orig 2015-04-21 11:51:26.30642 +0200
+++ rules 2015-04-21 11:54:14.329196307 +0200
@@ -10,6 +10,7 @@
CRANVERSION ?= $(shell uscan --no-conf --dehs | sed -n 's/.*upstream-version\([0-9.]\+\)\/upstream-version.*/\1/p')
RVERSION := $(shell grep Depends: R DESCRIPTION | sed 's/.*(\([= 0-9.]\+\)).*/\1/')
RLIB := usr/lib/R/site-library
+builttime := $(shell dpkg-parsechangelog | awk -F': ' '/Date/ {print $$2}')
%:
dh $@
@@ -29,7 +30,7 @@
echo R:Depends=r-base-core (${RVERSION}) debian/${PACKAGE}.substvars
## install r package
- R CMD INSTALL --library=${CURDIR}/debian/${PACKAGE}/${RLIB} --clean .
+ R CMD INSTALL --library=${CURDIR}/debian/${PACKAGE}/${RLIB} --clean --built-timestamp=${builttime} .
get-orig-source:
## download newest ${PACKAGE} from CRAN
Bug#783070: Bug report against installation-reports
Package: installation-reports Boot method: USB Image version: firmware-jessie-DI-rc3-amd64-netinst.iso Date: 20-04-2015 Machine: Lenovo Thinkpad Edge Processor: Intel U7300 Memory: 2.8 GiB Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sda1 ext4 34474968 3476672 29224004 11% / udev devtmpfs 102400 10240 0% /dev tmpfs tmpfs 590980 8408582572 2% /run tmpfs tmpfs 1477444 88 1477356 1% /dev/shm tmpfs tmpfs 51204 5116 1% /run/lock tmpfs tmpfs 14774440 1477444 0% /sys/fs/cgroup /dev/sda3 ext4 269963368 97074376 159152572 38% /home tmpfs tmpfs 2954924295488 1% /run/user/118 tmpfs tmpfs 295492 16295476 1% /run/user/1000 Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Lenovo Device [17aa:21b4] 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: uhci_hcd 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: uhci_hcd 00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: uhci_hcd 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: ehci-pci 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03) Kernel driver in use: pcieport 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03) Kernel driver in use: pcieport 00:1c.5 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 [8086:294a] (rev 03) Kernel driver in use: pcieport 00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: uhci_hcd 00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: uhci_hcd 00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: uhci_hcd 00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: ehci-pci 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93) 00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: lpc_ich 00:1f.2 SATA controller [0106]: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] [8086:2929] (rev 03) Subsystem: Lenovo Device [17aa:21b4] Kernel driver in use: ahci 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03) Subsystem: Lenovo Device [17aa:21b4] 03:00.0 Network controller [0280]: Intel Corporation Centrino Wireless-N 1000 [Condor Peak] [8086:0084] Subsystem: Intel Corporation Centrino Wireless-N 1000 BGN [8086:1315] Kernel driver in use: iwlwifi 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 03) Subsystem: Lenovo Device [17aa:2131] Kernel driver in use: r8169 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O]
Bug#783071: kmail: configuration messes up with last and most recent
Package: kmail Version: 4:4.4.11.1+l10n-3+b1 Severity: minor Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Open kmail -- Settings - Configure KMail... Window Configure - KMail opened; on the left list choose Accounts; tab Receiving lists one incoming account; the one incoming account is highlighted; activate button Modify...; window Modify Account - KMail opened; activate tab POP Settings; have set these settings: activate: Leave fetched messages on the server de-activate: Leave messages on the server for acivate: Keep only the last; edit: 155 messages de-activate: Keep only the last; [MB] de-activate: Filter messages if they are greater than de-activate: Use pipelinig for faster mail download Destination folder: inbox Pre-command: keep empty Click on button OK. Window Configure - KMail: Click on button OK. * What exactly did you do (or not do) that was effective (or ineffective)? Click on Action Check Mail. * What was the outcome of this action? The very first time, when I did so, right after having installed kmail, kmail left the 155 oldest (instead of 155 most recent) on the mail server. Trying to verify this behaviour, one week later, now, kmail keeps the most recent mails on the mail server which is correct end expected. * What outcome did you expect instead? The very first time configuring kmail, after having installed kmail, to keep the 155 latest (most recent) mails on the mail server, the 155 most recent mails should have been left on the mail server; even in the case when there are many mails received within the last year, 2014, in the inbox of the mail server. Keep in mind, that I was unable to reproduce the observed behaviour described above. Possibly, for reproducing, it is necessary to uninstall kmail from the system, and install/configure kmail, again. Keep also in mind, that I use kmail within gnome (not KDE). Kmail seems to be mainly designed for working well within KDE. *** End of the template - remove these lines *** -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kmail depends on: ii kde-runtime 4:4.8.4-2 ii kdepim-runtime 4:4.4.11.1-6 ii kdepimlibs-kio-plugins 4:4.8.4-2 ii libakonadi-contact4 4:4.8.4-2 ii libakonadi-kde4 4:4.8.4-2 ii libc6 2.13-38+deb7u8 ii libgcc1 1:4.7.2-5 ii libgpgme++2 4:4.8.4-2 ii libkabc44:4.8.4-2 ii libkcal44:4.8.4-2 ii libkcmutils44:4.8.4-4+deb7u1 ii libkde3support4 4:4.8.4-4+deb7u1 ii libkdecore5 4:4.8.4-4+deb7u1 ii libkdepim4 4:4.4.11.1+l10n-3+b1 ii libkdeui5 4:4.8.4-4+deb7u1 ii libkhtml5 4:4.8.4-4+deb7u1 ii libkimap4 4:4.8.4-2 ii libkio5 4:4.8.4-4+deb7u1 ii libkldap4 4:4.8.4-2 ii libkleo44:4.4.11.1+l10n-3+b1 ii libkmime4 4:4.8.4-2 ii libknotifyconfig4 4:4.8.4-4+deb7u1 ii libkontactinterface44:4.8.4-2 ii libkparts4 4:4.8.4-4+deb7u1 ii libkpgp44:4.4.11.1+l10n-3+b1 ii libkpimidentities4 4:4.8.4-2 ii libkpimtextedit44:4.8.4-2 ii libkpimutils4 4:4.8.4-2 ii libkresources4 4:4.8.4-2 ii libksieve4 4:4.4.11.1+l10n-3+b1 ii libktnef4 4:4.8.4-2 ii libmailtransport4 4:4.8.4-2 ii libmessagecore4 4:4.4.11.1+l10n-3+b1 ii libmessagelist4 4:4.4.11.1+l10n-3+b1 ii libmimelib4 4:4.4.11.1+l10n-3+b1 ii libnepomuk4 4:4.8.4-4+deb7u1 ii libphonon4 4:4.6.0.0-3 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-network 4:4.8.2+dfsg-11 ii libqt4-qt3support 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 libstdc++6 4.7.2-5 ii libthreadweaver44:4.8.4-4+deb7u1 ii perl5.14.2-21+deb7u2 ii phonon 4:4.6.0.0-3 Versions of packages kmail recommends: ii gnupg-agent 2.0.19-2+deb7u2 ii gnupg22.0.19-2+deb7u2 ii pinentry-gtk2 [pinentry-x11] 0.8.1-1 Versions of packages kmail suggests: pn clamav | f-prot-installernone pn kaddressbook none pn kleopatranone ii procmail
Bug#782609: systemd-sysv,plymouth: user experience: plymouth animation hangs
On Dienstag, 21. April 2015, Simon Richter wrote: I think that is mainly a matter of overall system performance. As said, the system in question is a two years old netbook that simply takes that the system I tested on is a 6 year old thinkpad x200s, though it had an (rather old) ssd... signature.asc Description: This is a digitally signed message part.
Bug#782914: [PATCH] Document early termination of mediawiki support
On 2015-04-20 23:00, Miguel Figueiredo wrote: On 20-04-2015 22:13, Jonathan Wiltshire wrote: systemitemmediawiki/systemitem is included + in Jessie to satisfy dependencies in other packages. Not sure if I understand this sentence. It's a techical reason or is it included to provide mediawiki to users? Technical, although it's also still available to users who want it (but I suspect they are few). -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783067: ITP: mtpolicyd -- a modular policy daemon for postfix
Package: wnpp Severity: wishlist Owner: Markus Benning i...@markusbenning.de * Package name: mtpolicyd Version : 1.17 Upstream Author : Markus Benning i...@markusbenning.de * URL : https://www.mtpolicyd.org/ * License : GPL Programming Lang: Perl Description : a modular policy daemon for postfix mtpolicyd is a modular policy daemon for postfix written in perl. It has support for virtual hosts, session caching, per-user configuration and is easily extensible thru plugins. It already ships with a lot of plugins: RBL - query DNS IP black/whitelists DBL - query DNS domain black/whitelists SqlList - use SQL query as black/whitelist CtIpRep - use Commtouch IP reputation GeoIP - use location of sending IP Fail2ban - block spammers with fail2ban/iptables Greylist - greylisting SPF - Sender Policy Framework Accounting - collect SMTP-level accounting informations Quota - apply quota limits based on Accounting data and more... (see Documentation) -- I already provide Debian and RPM packages from the projects website. Debian packaging files are included in the source tree. I want my project to be included in Debian. Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769155: kde-workspace-bin: laptop does not go to sleep when critical battery level is reached
Hi, Since there are several years between the release dates of the two tested notebooks, it does not look like a hardware specific issue to me. Or the affected hardware base is really large. I'll tend to change the severity back to grave as I don't think that Jessie should be released with a non-working power management in KDE, but waiting for your feedback first. Confirmed. The workaround solved the problem in my Asus N46VJ. Thank you. Felipe
Bug#767798: bind9: ignores OPTIONS from /etc/default/bind9 w/ systemd
Hello! I've found this bug too... Is there any good workaround? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783068: smokeping init script status always return false
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: smokeping Version: 2.6.8-2 This affects the wheezy version of smokeping. We are running OpenVZ Kernel (might be relevant): 2.6.32-openvz-042stab106.4-amd64 The init script of smokeping doesn't correctly detect if smokeping is running. Although it is running, the status command always return 3. The problem is that the pid file of smokeping is not in the standard location and the pid of the binary /usr/bin/smokeping cannot be found. See the attached output. I propose the attached patch which correctly sets the pid file when checking the status. -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJVNl/zAAoJEK8Ii7qe/iAw7/AIAIunjiC+maDOnFUKj8miIPie IqaIurcBltt9WoSByIPfOfEkiBPh/qYYdsIDU5cakKNyeaIFLmMPuv0kEU/GgB3E arhfZMZ+MUGmtWzndQakguUgAHaNi0N/i0jJCala5veREIZC+DP4Xsx46uGUDB5e 3FPT3yjIsDm4Hb3Sc5A6J/56nM3uG1WEaaIaqswkvpM40jkiU98IuqF+Xiilhs+/ jhZBrs50bAu7zyI+jCAn7gAbh90fUxoOIVcRXnVQ1x71QaAYZT3NxP2b9zjVRw87 i/VFI+zHIkhePlNLKvBFopWPd5IqmwTuh77ogUMDjgBH9qwjhP/Im4odqHEBeT0= =qzpR -END PGP SIGNATURE- --- smokeping.1 2015-04-21 16:18:34.0 +0200 +++ smokeping 2015-04-21 16:18:25.0 +0200 @@ -177,7 +177,7 @@ # 5-199reserved (5-99 LSB, 100-149 distribution, 150-199 applications) set +e -pidofproc $DAEMON /dev/null +pidofproc -p $PIDFILE $DAEMON /dev/null STATUS=$? log_progress_msg (status $STATUS) log_end_msg 0 # ps aux|grep smokeping rpertl 855 0.0 0.0 7724 948 pts/0S+ 14:22 0:00 grep --color=auto smokeping 106 5307 0.1 0.6 156772 27260 ?Ss 10:33 0:25 /usr/sbin/smokeping [FPing] # /etc/init.d/smokeping start [] Starting latency logger daemon: smokepingERROR: I Quit! Another copy of /usr/sbin/smokeping (5307) seems to be running. Check /var/run/smokeping/smokeping.pid . ok # /etc/init.d/smokeping status [ ok ] Checking latency logger daemon status: smokeping (status 3). # echo $? 3
Bug#783069: rkhunter: Rkhunter dont start
Package: rkhunter Version: 1.4.2-0.4 Severity: normal Dear Maintainer, I installed rkhunter on Sid: root@main:/home/elch# rkhunter -c Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: /usr/bin/lwp-request root@main:/home/elch# rkhunter -V Rootkit Hunter 1.4.2 -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rkhunter depends on: ii binutils 2.25-6 ii debconf [debconf-2.0] 1.5.56 ii file 1:5.22+15-2 ii net-tools 1.60-26+b1 ii perl 5.20.2-3 ii ucf3.0030 Versions of packages rkhunter recommends: ii iproute 1:3.16.0-2 ii lsof4.86+dfsg-1 ii postfix [mail-transport-agent] 2.11.3-1 ii unhide.rb 22-1 ii wget1.16.3-2 Versions of packages rkhunter suggests: pn bsd-mailx | mailutils | heirloom-mailx | mailx none pn libdigest-whirlpool-perlnone pn liburi-perl none pn libwww-perl none pn powermgmt-base none pn tripwirenone -- debconf information: rkhunter/cron_db_update: rkhunter/cron_daily_run: rkhunter/apt_autogen: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783072: ITP: Popout3D -- Create a 3D picture from photographs taken with an ordinary camera.
Package: wnpp Severity:wishlist
Bug#783066: installation-reports: Jessie rc3 amd64 on HP ProLiant ML310e Gen8 v2
Package: installation-reports Severity: wishlist -- Package-specific info: Boot method: CD Image version: http://cdimage.debian.org/cdimage/jessie_di_rc3/amd64/iso-cd/debian-jessie-DI-rc3-amd64-netinst.iso Date: 2015-04-21 Machine: HP ProLiant ML310e Gen8 v2 Partitions: See below Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[O] Comments/Problems: After install, the machine couldn't boot. First I booted the CD in rescue mode and manually installed GRUB again, but no difference. Then I noticed [1] and went into BIOS to disable the Smart Array BS310i and enable SATA in AHCI mode. Then it booted fine (no reinstall). [1]: http://www.ubuntu.com/certification/hardware/201306-13789/ The only special about the install was that I used a btrfs root filesystem, and deselected all tasksel tasks (however reportbug and installation-report added a number of packages after that...). There are some warnings from the kernel on boot, but I haven't noticed any real problem. For example: [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32 (20140424/tbfadt-618) [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm2ControlBlock: 8/32 (20140424/tbfadt-618) [0.00] ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20140424/tbfadt-699) [0.00] ACPI BIOS Warning (bug): Invalid length for FADT/Pm2ControlBlock: 32, using default 8 (20140424/tbfadt-699) and [0.111786] PCI: Using host bridge windows from ACPI; if necessary, use pci=nocrs and report a bug [0.114173] ACPI: PCI Root Bridge [PCI0] (domain [bus 00-13]) [0.114177] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [0.114282] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug PME AER PCIeCapability] [0.114283] acpi PNP0A08:00: _OSC: not requesting control; platform does not support [PCIeCapability] [0.114284] acpi PNP0A08:00: _OSC: OS requested [PCIeHotplug PME AER PCIeCapability] [0.114285] acpi PNP0A08:00: _OSC: platform willing to grant [] [0.114286] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM and [0.011231] Queued invalidation will be enabled to support x2apic and Intr-remapping. [0.011231] Your BIOS is broken and requested that x2apic be disabled. This will slightly decrease performance. Use 'intremap=no_x2apic_optout' to override BIOS request. [0.011335] Enabled IRQ remapping in xapic mode [0.011335] x2apic not enabled, IRQ remapping is in xapic mode and [0.051418] Performance Events: PEBS fmt2+, 16-deep LBR, Haswell events, full-width counters, Broken BIOS detected, complain to your hardware vendor. [0.051431] [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 330) and [5.029757] power_meter ACPI000D:00: Found ACPI power meter. [5.029771] power_meter ACPI000D:00: Ignoring unsafe software power cap! there were also some systemd warnings: [3.998833] systemd[1]: Cannot add dependency job for unit dbus.socket, ignoring: Unit dbus.socket failed to load: No such file or directory. [3.998921] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. Thanks, Simon -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build 20150418 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux kanin 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller [8086:0c08] (rev 06) lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x8 Controller [8086:0c05] (rev 06) lspci -knn: Kernel
Bug#782096: QRQ: FTBFS on hurd-i386: PATH_MAX
Build using pulseaudio was omitted
Display corruption when using wgetc function.
Builds successfully using pulseaudio also.
see attached for patch--- qrq.c_original 2015-04-18 07:53:42.0 -0400
+++ qrq.c 2015-04-21 09:51:33.0 -0400
@@ -43,6 +43,8 @@
#include windows.h
#endif
+
+
#define PI M_PI
#define SILENCE 0 /* Waveforms for the tone generator */
@@ -63,17 +65,20 @@
typedef void *AUDIO_HANDLE;
#endif
-#ifdef OSS
+//#ifdef OSS
#include oss.h
#define write_audio(x, y, z) write(x, y, z)
#define close_audio(x) close(x)
typedef int AUDIO_HANDLE;
-#endif
+//#endif
-#ifdef PA
+/**
+ building with pulseaudio gives cookie error
+#ifdef PA
#include pulseaudio.h
typedef void *AUDIO_HANDLE;
#endif
+**/
/* callsign array will be dynamically allocated */
static char **calls = NULL;
@@ -86,10 +91,10 @@
/* List of available callbase files. Probably no need to do dynamic memory allocation for that list */
-static char cblist[100][PATH_MAX];
+static char cblist[100][4096]; // need editing original cblist[100][PATH_MAX]
static char mycall[15]=DJ1YFK; /* mycall. will be read from qrqrc */
-static char dspdevice[PATH_MAX]=/dev/dsp; /* will also be read from qrqrc */
+static char *dspdevice; /* will also be read from qrqrc */
static int score = 0; /* qrq score */
static int sending_complete; /* global lock for enter while sending */
static int callnr = 0; /* nr of actual call in attempt */
@@ -157,11 +162,11 @@
pthread_attr_t cwattr;
#endif
-char rcfilename[PATH_MAX]=; /* filename and path to qrqrc */
-char tlfilename[PATH_MAX]=; /* filename and path to toplist */
-char cbfilename[PATH_MAX]=; /* filename and path to callbase */
+char *rcfilename; /* filename and path to qrqrc */
+char *tlfilename; /* filename and path to toplist */
+char *cbfilename; /* filename and path to callbase */
-char destdir[PATH_MAX]=;
+char *destdir;
/* create windows */
@@ -172,18 +177,49 @@
WINDOW *inf_w; /* info window for param displ */
WINDOW *right_w;/* highscore list/settings */
-
+/*
+ PATH_MAX
+ 1. tempdir
+ 2. dspdevice
+ 3. tmp
+ 4. cbfilename
+ 5. tlfilename
+*/
int main (int argc, char *argv[]) {
/* if built as osx bundle set DESTDIR to Resources dir of bundle */
#ifdef OSX_BUNDLE
- char tempdir[PATH_MAX]=;
+ char *tempdir;
char* p_slash = strrchr(argv[0], '/');
+
+ tempdir = malloc( strlen(argv[0]));
+ if(tempdir==NULL){
+printf(Error! memory not allocated.);
+exit(0);
+ }
strncpy(tempdir, argv[0], p_slash - argv[0]);
+
p_slash = strrchr(tempdir, '/');
+
+
+ destdir = malloc( strlen(tempdir));
+ if(destdir==NULL){
+printf(Error! memory not allocated.);
+exit(0);
+ }
strncpy(destdir, tempdir, p_slash - tempdir);
+
+ //realloc(destdir, (strlen(destdir) + strlen(/Resources)) * sizeof(char));
strcat(destdir, /Resources);
+ free(tempdir)
+
#else
+ destdir = malloc( strlen(DESTDIR));
+ if(destdir==NULL){
+printf(Error! memory not allocated.);
+exit(0);
+ }
+
strcpy(destdir, DESTDIR);
#endif
@@ -209,13 +245,16 @@
printw(qrq v%s - Copyright (C) 2006-2013 Fabian Kurz, DJ1YFK\n, VERSION);
printw(This is free software, and you are welcome to redistribute it\n);
printw(under certain conditions (see COPYING).\n);
-
- refresh();
-
+
+ refresh();
+
/* search for 'toplist', 'qrqrc' and callbase.qcb and put their locations
* into tlfilename, rcfilename, cbfilename */
+
+
find_files();
-
+
+
/* check if the toplist is in the suitable format. as of 0.0.7, each line
* is 31 characters long, with the added time stamp */
check_toplist();
@@ -237,6 +276,7 @@
/** Reading configuration file **/
printw(\nReading configuration file qrqrc \n);
+
read_config();
attemptvalid = 1;
@@ -245,6 +285,8 @@
}
/** Reading callsign database **/
+
+
printw(\nReading callsign database... );
nrofcalls = read_callbase();
@@ -337,11 +379,11 @@
/* reset */
maxspeed = errornr = score = 0;
- speed = initialspeed;
+ speed = initialspeed;
- /* prompt for own callsign */
+ /* prompt for own callsign */
i = readline(bot_w, 1, 30, mycall, 1);
-
+
/* F5 - Configure sound */
if (i == 5) {
parameter_dialog();
@@ -544,6 +586,13 @@
delwin(mid_w);
delwin(right_w);
getch();
+
+
+ free(cbfilename);
+free(dspdevice);
+free(tlfilename);
+ free(rcfilename);
+
return 0;
}
@@ -635,6 +684,12 @@
break;
#ifdef OSS
case 'e':
+ dspdevice = malloc( 15 * sizeof(char)); // max used in config file
+ if(dspdevice==NULL){
+printf(Error! memory not allocated.);
+exit(0);
+ }
+
readline(conf_w, 12, 25, dspdevice, 0);
if (strlen(dspdevice) == 0) {
strcpy(dspdevice, /dev/dsp);
@@ -791,22 +846,12 @@
-
Bug#782609: systemd-sysv,plymouth: user experience: plymouth animation hangs
Hi, Am 17.04.2015 um 16:34 schrieb Holger Levsen: From a user experience point of view, this is clearly suboptimal: the animation presented during boot suddenly hangs for several seconds, and then suddenly the login screen is shown. I cannot reproduce this on a freshly installed jessie (using d-i rc2), choosing the gnome desktop during installation, neither with or without plymouth installed. 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) I think that is mainly a matter of overall system performance. As said, the system in question is a two years old netbook that simply takes that time to start, but because the services required by X are not started until required, this means that this part of the boot sequence is moved to after plymouth has been stopped. Since plymouth simply leaves the last animation frame on the screen in this case (so we have a seamless transition to X), it appears as if the animation hangs. The basic assumption starting the X server takes less than a second simply is not true anymore when we have socket-activated services, and required services take their time starting up, so on slower systems we might want to somehow poke systemd into starting the services required by X before the handover, or make the handover explicit (e.g. with a callback from X). I'm aware this is a nontrivial problem, and a lot of effort for what is not a hard technical problem, but a user experience issue. Simon signature.asc Description: OpenPGP digital signature
Bug#741448: grive: Exception when executing grive
Does this package still work for anyone? People at the grive github seem to think the API grive uses has been removed: https://github.com/Grive/grive/issues/310 Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624249: Facts. Facts. Facts.
Just an objective account of the usage of both word forms in AE and BE: https://books.google.com/ngrams/graph?content=writeable:eng_gb_2012,writable:eng_gb_2012,writeable:eng_us_2012,writable:eng_us_2012year_start=1800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783060: /etc/xen-tools/xen-tools.conf doesn't support # in comments
Control: tags -1 patch
Attached is a patch.
Description: Allow # within configuration file comments
Line 20 of /etc/xen-tools/xen-tools.conf says:
Anything following a '#' character is ignored as a comment.
.
That patch allow two hash characters in configuration files.
.
Everything after the *first* hash is now ignored.
Author: Jean-Michel Nirgal Vourgère jmv_...@nirgal.com
Bug-Debian: https://bugs.debian.org/732456
Forwarded: no
Last-Update: 2015-04-21
--- xen-tools-4.5.orig/lib/Xen/Tools/Common.pm
+++ xen-tools-4.5/lib/Xen/Tools/Common.pm
@@ -70,7 +70,7 @@ sub readConfigurationFile ($$)
next if ( length($line) 1 );
# Strip trailing comments.
-if ( $line =~ /(.*)\#(.*)/ )
+if ( $line =~ /([^#]*)\#(.*)/ )
{
$line = $1;
}
signature.asc
Description: OpenPGP digital signature
Bug#782777: Cause for #782777 (recent aptitude forget-new issues) is likely the fix for #777760 in apt 1.0.9.8 (was: Re: Bug#782777: aptitude: forget-new option doesn't work)
Hi, TL;DR: I think I found the source of the issue for #782777 and friends in aptitude: I believe it's the fix for #60 included in apt 1.0.9.8. I at least can prove that downgrading apt to 1.0.9.7 plus running apt-get update makes the issue(s) vanish. Scroll down to So the architecture looks fine here and read from there on if you're only interested in the (pure apt) evidence, but not the way how I found it. The middle part of the mail shows how I came to this conclusion. Axel Beckert wrote: On that system, the problem persits after disabling all the third-party repositories, leaving only sid sources list. Interesting, thanks for that fact. Did you do an apt-get update or equivalent after removing the 3rd party repos? I'll try the same with some of my machines. I tried that one of my machines (with apt-get update after editing the sources.list) and it did indeed make a difference and make the symptom vanish. Reenabling these other repositoroies, and running apt-get update made them re-appear. Another thing I noticed is that yet another property of these packages gets lost: scheduled actions for these packages. I.e. if I select libgnutls26 in aptitude's TUI for installation and then just quit aptitude instead of pressing g twice, and reenter aptitude's TUI, the scheduled action install is no more scheduled, either. But trying to reproduce the above example purely on the commandline interestingly failed with the following error message -- and that may give a hint what goes wrong: # dpkg --print-architecture amd64 # dpkg --print-foreign-architectures # aptitude search '?new' p libgnutls26 - GNU TLS library - runtime library # aptitude forget-new # aptitude search '?new' p libgnutls26 - GNU TLS library - runtime library # apt-cache policy libgnutls26 libgnutls26: Installed: (none) Candidate: 2.12.23-18 Version table: 2.12.23-18 0 210 http://ftp.ch.debian.org/debian/ experimental/main amd64 Packages # aptitude install --schedule-only libgnutls26 No candidate version found for libgnutls26:i386 No candidate version found for libgnutls26:i386 # So why the heck does libgnutls26:i386 suddenly appear on a non-multi-arch system? (It may have had i386 enabled as foreign architecture in the past, though. No more sure.) Ok, so let's make clear that we want the amd64 version: # aptitude install --schedule-only libgnutls26:amd64 No candidate version found for libgnutls26:i386 No candidate version found for libgnutls26:i386 # (Removing the --schedule-only doesn't make a difference with regards to the architecture messages.) Ok, let's ignore aptitude's features and lets try with apt-get: # apt-get install -s libgnutls26 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libgnutls26 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Inst libgnutls26:i386 Conf libgnutls26:i386 # apt-get install -s libgnutls26:amd64 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libgnutls26 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Inst libgnutls26:i386 Conf libgnutls26:i386 # WTF? Let's check the downloaded Packages lists: grep-aptavail 'Package: libgnutls26' Package: libgnutls26 Source: gnutls26 Version: 2.12.23-18 Installed-Size: 1385 Maintainer: Debian GnuTLS Maintainers pkg-gnutls-ma...@lists.alioth.debian.org Architecture: amd64 Replaces: gnutls0, gnutls0.4, gnutls3 Depends: libc6 (= 2.14), libgcrypt20 (= 1.6.1), libp11-kit0 (= 0.11), libtasn1-6 (= 4.1-0), zlib1g (= 1:1.1.4) Pre-Depends: multiarch-support Conflicts: gnutls0, gnutls0.4 Breaks: ccbuild (= 2.0.1-1), csync2 (= 1.34-2.2), freewheeling (= 0.6-1.1), gkrellm (= 2.3.4-1), libsoup2.4-1 (= 2.31.2-1), libsoup2.4-1 (= 2.30.1-1), macopix-gtk2 (= 1.7.4-3), pokerth (= 0.8.3-3+b1), pokerth-server (= 0.8.3-3+b1), sipsak (= 0.9.6-2.1), slrn (= 1.0.0~pre18-1.1), slrnpull (= 1.0.0~pre18-1.1), snowdrop (= 0.02b-9), ssmtp (= 2.64-4), tf5 (= 5.0beta8-4), wput (= 0.6.2-2), zoneminder (= 1.24.4-1) Description: GNU TLS library - runtime library Multi-Arch: same Homepage: http://www.gnutls.org/ Description-md5: 07e0914117156d2b3fcf0d63e9ef8ac2 Tag: implemented-in::c, implemented-in::c++, role::shared-lib Section: libs Priority: standard Filename: pool/main/g/gnutls26/libgnutls26_2.12.23-18_amd64.deb Size: 534362 MD5sum: 781c367990e74fb756611748a2ef4a0b SHA1: 07b17ff88734cc2dce0b33496d1aaf30caec1b4c SHA256: ab272158ae2d841e5f9b8450d41897b846ecd7eaed2664248a66e315ea2d3359 Package: libgnutls26-dbg Source: gnutls26 Version: 2.12.23-18 Installed-Size: 3027 Maintainer: Debian GnuTLS Maintainers pkg-gnutls-ma...@lists.alioth.debian.org Architecture: amd64 Depends: libgnutls26 (= 2.12.23-18), libc6 (= 2.15), libgcrypt20 (= 1.6.0), libp11-kit0 (= 0.11), libtasn1-6 (= 4.1-0), zlib1g (= 1:1.1.4) Description: GNU TLS
Bug#755551: [Pkg-xfce-devel] Bug#755551: will the fix ever end up to Debian jessie?
On mar., 2015-04-21 at 11:40 +0300, Juha Heinanen wrote: Will version 1.4.4 of xfce4-power-manager ever make it to Debian jessie or to jessie backports? jessie definitely not. jessie backport maybe, if someone from the team actually cares to do the work. I'm honestly not too much focused on backports myself. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#731317: qemu-kvm: KVM does not start and uses 100% CPU of nested hypervisor using kvm-intel
I have the same bug - on kernel from wheezy-backports: [4310755.043509] vmwrite error: reg 2800 value (err 711786560) [4310755.043554] CPU: 0 PID: 111239 Comm: kvm Not tainted 3.16.0-0.bpo.4-amd64 #1 Debian 3.16.7-ckt4-3~bpo70+1 [4310755.043556] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 11/17/2014 [4310755.043557] 81543593 88022a6d0040 [4310755.043561] a03ffb9e 8805135bc200 88022a6d0040 [4310755.043564] 8805135bc200 8805135bc200 a03ffcdf 8805135bc000 [4310755.043568] Call Trace: [4310755.043572] [81543593] ? dump_stack+0x41/0x51 [4310755.043577] [a03ffb9e] ? free_nested.part.79+0x6e/0x180 [kvm_intel] [4310755.043581] [a03ffcdf] ? vmx_free_vcpu+0x2f/0x90 [kvm_intel] [4310755.043591] [a06ee6bb] ? kvm_arch_destroy_vm+0xeb/0x1e0 [kvm] [4310755.043599] [a06d5e7c] ? kvm_put_kvm+0xfc/0x1f0 [kvm] [4310755.043606] [a06d6c78] ? kvm_vcpu_release+0x18/0x20 [kvm] [4310755.043610] [811bea53] ? __fput+0xb3/0x210 [4310755.043613] [8108d204] ? task_work_run+0xc4/0xe0 [4310755.043618] [810703a0] ? do_exit+0x2c0/0xa80 [4310755.043622] [81070be6] ? do_group_exit+0x46/0xb0 [4310755.043626] [8107fd93] ? get_signal_to_deliver+0x233/0x610 [4310755.043630] [81014527] ? do_signal+0x67/0xad0 [4310755.043635] [811bc7db] ? new_sync_write+0x7b/0xb0 [4310755.043640] [810e0150] ? SyS_futex+0x150/0x1c0 [4310755.043644] [8101503b] ? do_notify_resume+0xab/0xc0 [4310755.043648] [81549d2a] ? int_signal+0x12/0x17 on host, and then system hangs. When i downgraded kernel on guest to 3.2 - it works fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783060: /etc/xen-tools/xen-tools.conf doesn't support # in comments
Package: xen-tools Version: 4.5-1 Severity: normal Hi On a fresh jessie installation, I changed line 134 of /etc/xen-tools/xen-tools.conf fs = ext3 # Default file system for any disk by fs = ext4 # Default file system for any disk # default was ext3 Then when I create an image I get this error: -- # xen-create-image --hostname medusa --ip 192.168.1.10 --gateway 192.168.1.1 --netmask 255.255.255.0 --size=20G --memory=512MB General Information Hostname : medusa Distribution : jessie Mirror : http://http.debian.net/debian Partitions : swap128M (swap) / 20G (ext4 # Default file system for any disk) Image type : full Memory size: 512MB Kernel path: /boot/vmlinuz-3.16.0-4-amd64 Initrd path: /boot/initrd.img-3.16.0-4-amd64 Networking Information -- IP Address 1 : 192.168.1.10 [MAC: 00:16:3E:C7:A2:6C] Netmask: 255.255.255.0 Gateway: 192.168.1.1 Creating swap on /dev/debian_vg/medusa-swap Done Use of uninitialized value $command in split at /usr/bin/xen-create-image line 3242. Use of uninitialized value $binary in concatenation (.) or string at /usr/bin/xen-create-image line 3246. The binary '' required to create the filesystem ext3 # Default file system for any disk is missing Logfile produced at: /var/log/xen-tools/medusa.log -- The wanted file system ext4 # Default file system for any disk is invalid. If I remove the second # in the comment, it works. I expected to be able to put # in a comment. At the very least, the top of the file should NOT say: Anything following a '#' character is ignored as a comment. Thank you for taking care of xen. :) -- System Information: Debian Release: 8.0 signature.asc Description: OpenPGP digital signature
Bug#783038: libguestfs-tools: virt-filesystems output is incorrect
The output of virt-filesystems isn't wrong. virt-resize can't resize extended partitions (like /dev/sda5). See the section LOGICAL PARTITIONS in the virt-resize man page. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783027: gnome-control-center: When battery power is critical don't offer hibernate without package laptop-mode-tools
Am 21.04.2015 um 13:51 schrieb Michael Biebl: Am 21.04.2015 um 13:30 schrieb Michael Biebl: If you set the action to poweroff when battery is critical in gnome-control-center, is the laptop powered off? If not, it looks like this condition is not properly triggered. For that, I'd log into GNOME, open a terminal and then run gnome-settings-daemon --replace --debug. When your battery reaches a critical level, check if gnome-settings-daemon reacts to that. This will output a lot of data. You might consider dumping that into a file and filtering it via grep. # Run gnome-settings-daemon in debug mode to get full log $ gnome-settings-daemon --replace --debug 21 | tee /tmp/log On another terminal # Filter log for power messages $ tail -n 1000 -f /tmp/log | grep power -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#782371: thunar: Random sefaults GLib-CRITICAL **: g_sequence_get: assertion '!is_end (iter)' failed
Package: thunar Followup-For: Bug #782371 Hi, I've had Thunar on gdb for 9 days at least and couldn't get this crash to happen. I then re-ran gdb with a tmpfs mount for the log just in case I was hitting a timing issue with the log file slowing execution. Still can't reproduce, really annoying! I'm going to go back to running Thunar normally and see if this reoccurs if it does or doesn't I'll post an update as to whether or not to close this bug. Any suggestions welcome as to how to further debug and try to reproduce this crash. Kitty -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782371: [Pkg-xfce-devel] Bug#782371: thunar: Random sefaults GLib-CRITICAL **: g_sequence_get: assertion '!is_end (iter)' failed
On mar., 2015-04-21 at 22:00 +1000, kittyofthebox wrote: Package: thunar Followup-For: Bug #782371 Hi, I've had Thunar on gdb for 9 days at least and couldn't get this crash to happen. I then re-ran gdb with a tmpfs mount for the log just in case I was hitting a timing issue with the log file slowing execution. Still can't reproduce, really annoying! I'm going to go back to running Thunar normally and see if this reoccurs if it does or doesn't I'll post an update as to whether or not to close this bug. Any suggestions welcome as to how to further debug and try to reproduce this crash. Try to enable coredumps (ulimit -c unlimited), then restart thunar from that shell (thunar -q; thunar). If it crashes, you should get a core dump which can be used with gdb. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#781896: baloo4: Baloo needs to depend on libqt4-sql-sqlite to start indexing
Control: tags -1 pending patch
Hi,
On Sat, 04 Apr 2015 16:48:17 +0200 =?utf-8?q?Roberth_Sjon=C3=B8y?=
roberth.sjo...@gmail.com wrote:
Package: baloo4
Version: 4:4.14.2-1
Severity: serious
Justification: Policy 3.5
Dear Maintainer,
* What led up to the situation? Installing the package plasma-desktop and
then installing baloo4.
* What exactly did you do (or not do) that was effective (or
ineffective)? Installing libqt4-sql-sqlite was effective since it made
baloo4 start indexing files as it should do when it is enabled.
* What outcome did you expect instead? That the installation of baloo4
installed libqt4-sql-sqlite as dependency, so it started indexing
automatically.
I have just uploaded a fixed version to DELAYED/1
Cheers,
Balint
diff -Nru baloo-4.14.2/debian/changelog baloo-4.14.2/debian/changelog
--- baloo-4.14.2/debian/changelog 2014-10-20 18:54:00.0 +0200
+++ baloo-4.14.2/debian/changelog 2015-04-21 17:27:05.0 +0200
@@ -1,3 +1,10 @@
+baloo (4:4.14.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Depend on libqt4-sql-sqlite (Closes: #781896, #765084)
+
+ -- Balint Reczey bal...@balintreczey.hu Tue, 21 Apr 2015 17:23:58 +0200
+
baloo (4:4.14.2-1) unstable; urgency=medium
[ Pino Toscano ]
diff -Nru baloo-4.14.2/debian/control baloo-4.14.2/debian/control
--- baloo-4.14.2/debian/control 2014-10-20 18:54:00.0 +0200
+++ baloo-4.14.2/debian/control 2015-04-21 17:36:07.0 +0200
@@ -29,7 +29,9 @@
Package: baloo4
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, baloo-utils
+Depends: ${misc:Depends}, ${shlibs:Depends},
+ baloo-utils,
+ libqt4-sql-sqlite
Replaces: baloo ( 4:4.13.2-0ubuntu3),
kde-runtime ( 4:4.12.80),
kde-runtime-data ( 4:4.12.80)
Bug#783073: bootscripts: Support using fdtfile variable passed from u-boot
Package: flash-kernel
Version: 3.35
Severity: wishlist
Tags: patch
The following patch prefers the use of the dtb file identified by the
u-boot variable ${fdtfile}, which makes it easier to support installs
where a single u-boot image can support multiple boards, but need to
load different fdt files at boot.
It essentially makes a second copy of the .dtb file in
/boot/dtbs-${kver}/${fdtfile}. Ideally, it would copy all of the .dtb
files (to support the widest number of boards), but that should be
made conditional for resource-constrained systems, so I started off
with simply making a second copy.
The various boot scripts which may include ${fdtfile} are patched to
prefer ${fdtfile}, falling back to the old behavior of the hard-coded
fdt file path.
I don't expect to see this in jessie, but hopefully something like this
could be considered for jessie+1.
diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index 1d079f8..3e16974 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
@@ -20,7 +20,8 @@ kvers='@@KERNEL_VERSION@@'
for pathprefix in ${image_locations}
do
load ${device} ${partition} ${loadaddr} ${pathprefix}vmlinuz-${kvers} \
- load ${device} ${partition} ${fdtaddr} ${pathprefix}dtb-${kvers} \
+ load ${device} ${partition} ${fdtaddr}
${pathprefix}dtbs-${kvers}/${fdtfile} \
+ || load ${device} ${partition} ${fdtaddr} ${pathprefix}dtb-${kvers} \
load ${device} ${partition} ${rdaddr} ${pathprefix}initrd.img-${kvers} \
echo Booting Debian ${kvers} from ${device} ${partition}... \
bootz ${loadaddr} ${rdaddr}:${filesize} ${fdtaddr}
diff --git a/bootscript/bootscr.cubox-i b/bootscript/bootscr.cubox-i
index adeb0d2..62e5c5d 100644
--- a/bootscript/bootscr.cubox-i
+++ b/bootscript/bootscr.cubox-i
@@ -19,7 +19,8 @@ kvers='@@KERNEL_VERSION@@'
for pathprefix in ${image_locations}
do
load ${device} ${partition} ${loadaddr} ${pathprefix}vmlinuz-${kvers} \
- load ${device} ${partition} ${fdt_addr} ${pathprefix}dtb-${kvers} \
+ load ${device} ${partition} ${fdt_addr}
${pathprefix}dtbs-${kvers}/${fdtfile} \
+ || load ${device} ${partition} ${fdt_addr} ${pathprefix}dtb-${kvers} \
load ${device} ${partition} ${ramdiskaddr}
${pathprefix}initrd.img-${kvers} \
echo Booting Debian ${kvers} from ${device} ${partition}... \
bootz ${loadaddr} ${ramdiskaddr}:${filesize} ${fdt_addr}
diff --git a/bootscript/bootscr.sunxi b/bootscript/bootscr.sunxi
index e64010f..004ff64 100644
--- a/bootscript/bootscr.sunxi
+++ b/bootscript/bootscr.sunxi
@@ -45,10 +45,10 @@ do
if test -e ${device} ${partition} ${pathprefix}vmlinuz-${kvers}
then
load ${device} ${partition} ${kernel_addr_r} ${pathprefix}vmlinuz-${kvers}
\
- load ${device} ${partition} ${fdt_addr_r} ${pathprefix}dtb-${kvers} \
+ load ${device} ${partition} ${fdt_addr_r}
${pathprefix}dtbs-${kvers}/${fdtfile} \
+|| load ${device} ${partition} ${fdt_addr_r} ${pathprefix}dtb-${kvers} \
load ${device} ${partition} ${ramdisk_addr_r}
${pathprefix}initrd.img-${kvers} \
echo Booting Debian ${kvers} from ${device} ${partition}... \
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
fi
done
-
diff --git a/bootscript/bootscr.uboot-generic b/bootscript/bootscr.uboot-generic
index 7451112..7342377 100644
--- a/bootscript/bootscr.uboot-generic
+++ b/bootscript/bootscr.uboot-generic
@@ -17,7 +17,8 @@ setenv bootargs ${bootargs} @@LINUX_KERNEL_CMDLINE@@
@@UBOOT_ENV_EXTRA@@
load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} ${prefix}vmlinuz \
- load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} ${prefix}dtb \
+ load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r}
${prefix}dtbs/${fdtfile} \
+|| load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} ${prefix}dtb \
load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} ${prefix}initrd.img
\
echo Booting Debian... \
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
diff --git a/bootscript/bootscr.wandboard b/bootscript/bootscr.wandboard
index cd04a90..39bd25e 100644
--- a/bootscript/bootscr.wandboard
+++ b/bootscript/bootscr.wandboard
@@ -22,7 +22,8 @@ kvers='@@KERNEL_VERSION@@'
for pathprefix in ${image_locations}
do
load ${device} ${partition} ${loadaddr} ${pathprefix}vmlinuz-${kvers} \
- load ${device} ${partition} ${fdt_addr} ${pathprefix}dtb-${kvers} \
+ load ${device} ${partition} ${fdt_addr}
${pathprefix}dtbs-${kvers}/${fdtfile} \
+ || load ${device} ${partition} ${fdt_addr} ${pathprefix}dtb-${kvers} \
load ${device} ${partition} ${ramdiskaddr}
${pathprefix}initrd.img-${kvers} \
echo Booting Debian ${kvers} from ${device} ${partition}... \
bootz ${loadaddr} ${ramdiskaddr}:${filesize} ${fdt_addr}
diff --git a/functions b/functions
index a7ff6de..fc2c21b 100644
--- a/functions
+++ b/functions
@@ -420,13 +420,18 @@ handle_dtb() {
local dtb=/usr/lib/linux-image-$kvers/$dtb_id
if [ x$FK_KERNEL_HOOK_SCRIPT =
Bug#747646: netcat-openbsd: UDP connections start with XXXXX junk
Hello,
I ran into this as well, and after some investigation I found out this
only happens when using the verbose flag -v:
netcat.c, lines 609-616:
%-
if (vflag) {
/* For UDP, make sure we are connected. */
if (uflag) {
if (udptest(s) == -1) {
ret = 1;
continue;
}
}
%-
netcat.c, lines 1207-1229:
%-
/*
* udptest()
* Do a few writes to see if the UDP port is there.
* Fails once PF state table is full.
*/
int
udptest(int s)
{
int i, t;
if ((write(s, X, 1) != 1) ||
((write(s, X, 1) != 1) (errno == ECONNREFUSED)))
return -1;
/* Give the remote host some time to reply. */
for (i = 0, t = (timeout == -1) ? UDP_SCAN_TIMEOUT : (timeout / 1000);
i t; i++) {
sleep(1);
if ((write(s, X, 1) != 1) (errno == ECONNREFUSED))
return -1;
}
return 1;
}
%-
So I believe it can be cured with a simple don't do it![1] :-)
-Christian
[1] - Doctor, doctor, when I touch my arm here, it hurts!
- Well, don't touch it then!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782817: pyfits-utils: Please consider removing pyfits-utils
On 2015-04-18 12:34, Ole Streicher wrote: Package: pyfits-utils Version: 1:3.3-2 Severity: wishlist Dear Aurelien, the package pyfits-utils contains the binaries fitscheck and fitsdiff. I am just preparing a new package astropy-utils [1], which will contain the same binaries, but based on the astropy package. Since pyfits is going to be deprecated, it would be useful to remove the pyfits-utils (since the new ones are almost identical), or to lower the package priority to extra. Usually, Debian handles conflicts on a first-comes base; however since astropy is the successor of pyfits, I would ask that I can take priority in this case. I am not sure how to make a smooth transition here. Since you have more experience: could you please give me an advise? If you want to provide a smooth transition to users, the best is to add breaks and replaces in astropy-utils: Breaks: pyfits-utils ( 1:3.3-2) Replaces: pyfits-utils ( 1:3.3-2) As soon as it is done, I'll upload a new pyfits version with an empty pyfits-utils depending on astropy-utils. That way users of pyfits-utils will automatically get astropy-utils installed and nothing will break on their systems. The pyfits-utils package will be marked as transitional so it can be automatically removed from users's installation once astropy-utils is installed. The pyfits-utils package can then be removed from the archive in Buster. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
