Bug#717492: libsvgsalamander-java: Does not fully support styles
Package: libsvgsalamander-java Version: 0~svn95-1 Severity: normal Dear Maintainer, The lib does not fully support styles leading to improperly rendered .svg file. Please have a look at: https://josm.openstreetmap.de/ticket/8889 The same happens when using the debian package josm which depends on salamander. Please fully support styles. Thanks colliar -- System Information: Debian Release: jessie/sid APT prefers stable APT policy: (991, 'stable'), (300, 'testing'), (200, 'unstable'), (90, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
Hi, Am 21.07.2013 14:20, schrieb Carsten Schoenert: Hello Karsten, Where i can see this? There is no line with something like sound. You found the related lines as you wrote in the other mail. No - i opened prefs.js directly with an editor. Found this two lines in prefs.js now: user_pref(mail.biff.play_sound.type, 1); user_pref(mail.biff.play_sound.url, file:///path/mysound.wav); This means the file would be found in '/path/mysound.wav' ? Is that true? And if so what about the access right of that file? Icedove is able access that file (in context of your user permissions)? A file location like this is very unconventional. Better select a file inside your home directory. Of course not - the file name was manually edited for the email from me. If this want work your sound system is configured wrong. My soundsystem is working perfect in all other cases. I have renamed my prefs.js and started Icedove again. Now i simply added the soundfile as shown in the screenshot. This does not work! The only thing i can do now is to try the original Thunderbird. Cheers Karsten attachment: soundconfig.png
Bug#712439: [Pkg-systemd-maintainers] Bug#712439: Bug#712439: systemd: encrypted swap not brought up, delays boot
On Sun, 2013-07-21 at 13:45 +0100, Sam Morris wrote: On Sun, 2013-07-21 at 13:42 +0200, Michael Stapelberg wrote: Hi Sam, Reading https://bugzilla.redhat.com/show_bug.cgi?id=759402 (especially comment #15) I suspect the issue is that systemd is not getting notified about the swap device properly. Can you please run udevadm info -q all -n /dev/mapper/swap0 P: /devices/virtual/block/dm-0 N: dm-0 L: 50 S: disk/by-id/dm-name-swap0 S: disk/by-id/dm-uuid-CRYPT-PLAIN-swap0 S: mapper/swap0 E: DEVLINKS=/dev/disk/by-id/dm-name-swap0 /dev/disk/by-id/dm-uuid-CRYPT-PLAIN-swap0 /dev/mapper/swap0 E: DEVNAME=/dev/dm-0 E: DEVPATH=/devices/virtual/block/dm-0 E: DEVTYPE=disk E: DM_NAME=swap0 E: DM_STATE=ACTIVE E: DM_SUSPENDED=0 E: DM_TABLE_STATE=LIVE E: DM_TYPE=raid E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES=1 E: DM_UUID=CRYPT-PLAIN-swap0 E: MAJOR=254 E: MINOR=0 E: SUBSYSTEM=block E: SYSTEMD_READY=0 E: TAGS=:systemd: E: USEC_INITIALIZED=945279 E: net.ifnames=1 cat /proc/sys/kernel/hotplug This is just an empty line. and provide the output here? I'm guessing SYSTEMD_READY=0 is the suspicious entry. FYI, my system originally only had udisks2 installed, not udisks. I installed udisks (so that both are now installed) and rebooted, and the swap device is now set up properly. udevadm info now says, P: /devices/virtual/block/dm-0 N: dm-0 L: 50 S: disk/by-id/dm-name-swap0 S: disk/by-id/dm-uuid-CRYPT-PLAIN-swap0 S: disk/by-uuid/02331091-93b9-46e3-827b-4d940df2159e S: mapper/swap0 E: DEVLINKS=/dev/disk/by-id/dm-name-swap0 /dev/disk/by-id/dm-uuid-CRYPT-PLAIN-swap0 /dev/disk/by-uuid/02331091-93b9-46e3-827b-4d940df2159e /dev/mapper/swap0 E: DEVNAME=/dev/dm-0 E: DEVPATH=/devices/virtual/block/dm-0 E: DEVTYPE=disk E: DM_NAME=swap0 E: DM_STATE=ACTIVE E: DM_SUSPENDED=0 E: DM_TABLE_STATE=LIVE E: DM_TYPE=raid E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES=1 E: DM_UUID=CRYPT-PLAIN-swap0 E: ID_FS_TYPE=swap E: ID_FS_USAGE=other E: ID_FS_UUID=02331091-93b9-46e3-827b-4d940df2159e E: ID_FS_UUID_ENC=02331091-93b9-46e3-827b-4d940df2159e E: ID_FS_VERSION=2 E: MAJOR=254 E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: UDISKS_DM_TARGETS_COUNT=1 E: UDISKS_DM_TARGETS_LENGTH=4192223 E: UDISKS_DM_TARGETS_START=0 E: UDISKS_DM_TARGETS_TYPE=crypt E: UDISKS_PRESENTATION_NOPOLICY=1 E: USEC_INITIALIZED=24880 E: net.ifnames=1 i.e., SYSTEMD_READY is no longer there, which I believe implicitly means that it's set to 1. -- Sam Morris https://robots.org.uk/ 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 signature.asc Description: This is a digitally signed message part
Bug#717152: jessie
Hi, On Sonntag, 21. Juli 2013, Julian Andres Klode wrote: Never saw this before. But, OK. thanks. (I do these double tags all the time...) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#717493: pu: package sympa/6.1.11~dfsg-5.1~deb7u1
Control: tags -1 + wheezy moreinfo On Sun, 2013-07-21 at 15:07 +0200, Andreas Beckmann wrote: Sympa fails to install if the ca-certificates trigger has never been run, yet. #717435 One solution is to add a Pre-Depends: ca-certificates to sympa (suggested patch attached). The other solution would be to fix this in ca-certificates and force a trigger run during postinst (not sure if that is really feasible due to the interaction needed with ca-certificates-java). Fixing this in ca-certificates would prevent similar bugs to happen in other packages, although I haven't seen any more in my piuparts tests. Whichever solution was chosen, it looks like this bug is not fixed in unstable yet? 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#705919: icedove does not play sounds (notifications when new messages arrive)
Hello Carsten, i tested now with the original Thunderbird and there is no sound notification also. So this should be a general problem or a sound misconfiguration. I attached a screenshot for the sound configuration of the Thunderbird. But how can i find the problem? All other sound is working! The file is playing perfect with any other soundplayer including aplay siehabenpost.wav. Best regards Karsten attachment: thunderbird.png
Bug#717494: coreutils: du -s error when displaying dir and subdir
Package: coreutils Version: 8.13-3.5 Severity: normal Dear Maintainer, Displaying du -s xxx xxx/yyy gives only result for xxx Displaying du -s xxx/yyy xxx gives result for xxx/yyy and xxx -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages coreutils depends on: ii dpkg 1.16.10 ii install-info 4.13a.dfsg.1-10 ii libacl1 2.2.51-8 ii libattr1 1:2.4.46-8 ii libc6 2.13-38 ii libselinux1 2.1.9-5 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716830: Wrong colors are printed on arm device using hpcups
Could you try to reprint we comparable package ? Bastien On Sun, Jul 21, 2013 at 2:52 PM, Adam Pigg pig...@gmail.com wrote: Ive done that, the files print-* are the data sent to the queue The files printout-* are the binary data sent to the printer. The arm box is running cups 1.5.3 with driver HP Photosmart 3200 Series, hpcups 3.13.4 my laptop is running 1.5.4 with driver HP Photosmart 3200 Series hpijs, 3.12.11 the data sent from the arm box is a lot smaller. On Sun, Jul 21, 2013 at 12:50 PM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: Could you try the step https://wiki.ubuntu.com/DebuggingPrintingProblems Particularly: Capturing print job data Getting the data which would go to the printer Both from an arm and from an i386/amd64 ? Run a diff on it is possible On Sat, Jul 20, 2013 at 5:51 PM, Adam Pigg pig...@gmail.com wrote: Any thoughts? On Sun, Jul 14, 2013 at 6:30 PM, Adam Pigg pig...@gmail.com wrote: Certainly On Sun, Jul 14, 2013 at 6:01 PM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Sat, Jul 13, 2013 at 12:52 PM, Adam Pigg pig...@gmail.com wrote: Package: printer-driver-hpcups Version: 3.13.4-1+b1 On a custom built NAS using the armv5tel architecture i have setup cups as a print server. The printer details/configuration are: Description:HP Photosmart 3200 series Driver: HP Photosmart 3200 Series, hpcups 3.13.4 (color, 2-sided printing) Connection: dnssd://Photosmart%203200%20series%20%5B42F8E4%5D._pdl-datastream._tcp.local/ Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided When a test page is printed from the cups administration page, all the details are there, but the colors on tux and the color-wheel are clearly wrong. Everything has a green tint. Perhaps there is an endian-ness problem in the printer driver? I am using a custom kernel and debian-sid: Linux lacie-nas 2.6.38-rc4-09713-ga6682f0-svn-dirty #13 PREEMPT Thu Feb 24 01:37:33 CET 2011 armv5tel GNU/Linux Could you post an photo or a scan of the bad file ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717492: libsvgsalamander-java: Does not fully support styles
Oh it has been already reported upstream: https://java.net/jira/browse/SVGSALAMANDER-27 Forgot to link to the .svg file: https://josm.openstreetmap.de/attachment/ticket/8849/aed.svg colliar signature.asc Description: OpenPGP digital signature
Bug#717445: pu: package ndiswrapper/1.57-1+deb7u1
On 2013-07-21 14:47, Julian Andres Klode wrote: On Sun, Jul 21, 2013 at 12:26:00AM +0200, Andreas Beckmann wrote: * dkms throws up during kernel upgrades (#690747) The second does not make sense. It would only add support for 3.4-3.7, [...] It works with 3.2 AFAICT, and that's the reason I did not workaroud this bug in stable. Good. I was afraid it would explode on kernel updates in stable, too. In general, I prefer git patches against tag/1.57-1 over branches, so I can review the individual commits. In this case, I'd like some further changes as mentioned above, so I came up with the attached patch (committed in a *local* branch). That's fine. But since everything is already integrated in your patch, there is no probably no need to resend my individual commits. This pu request is yours now :-) Thanks. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717484: akregator: Akregator does not update feeds, reports Networking is not available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/21/2013 02:33 PM, Pino Toscano wrote: Hm, it'd seem like the ntrack backend explicitly reports not connected somehow, not sure why (especially if you say that you are connected fine -- and the ntrack libraries do not provide utilities). Thanks, I know where to look then and will examine what ntrack is doing. In the meanwhile, you could try to manually set a connected state for the SolidNetwork network: $ qdbus org.kde.kded /modules/networkstatus setNetworkStatus \ SolidNetwork 4 Excellent, this workaround lets Akregator update feeds again. Thanks for the help! - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJR69m7AAoJENtLVMukgmoYumMP/2SjtbKFjAlPlMCx0plqiOtv OHkeTuj80rLLl97u0xKoIHRr7LFfI1FZFYXToU+hT19i3znj8lxVwBTjUtXXhxDj OwH6OewlcNud29xn7L/lcjYZILX71HqMM2N2WsjiLsGxZOlgz2DITVB4zZIjHzUM FokK8kwEgJ4ABHd4BrpUISazEQXoUmgdJuXoMAsKsAk7rHN8/eWNsGexlb5ZQ59D KyyIr+o9Whc2w+eeWHUjqr/NQSw4xsX5E/QdmgKnBsWsCits+pETnPvceWVfGt3D 4c77HJNYjBOkXcCQiph2wM72nMkNuYoa6tDnBv8woRirJMTcJ8LF/uve/PixRg8n gAsbRfzTyVCgT0Tf2Jr7UN4s1rFnXoO+LnUQqFQVwSHDzCySONWFx5fnsd/qZ47F vAfPzS77BHJgCnsrHObYAHxoemZMywh5KACXWxmW4Frfk4AykF9GAKQpk9h3tpIl /G8E9AuqV+3bfF2C8M+cCQqxnNLwSgLTiBzjE/W0yM6AL70Bqu/taiyIRx2LAccI jTh6WH0oE4nNT6EDLmk8/6UJsUknDFOpR7b6z1Bl5Z2Tp3dUqbaW8k9lhy7wx2zi FxxlS1JPzv47Sq7RzQfQHGP/uh+e08NqVUEgy7Unjsir0nVjo4lBjdizEVB7qngK esLcv4H51aOrHzt3f5+n =05TO - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJR69s7AAoJENtLVMukgmoYVY0QAMfA2cnQH4rlno6Vj6FrCUJk JuhJCmuUe587r4I9fqgXTeAF9cfBm4kzQcJmpBpjrPkR9+CmpapPXs42WOmR2dRr i2qHa+g5vyKbg5AUnZ0GF5VXtneVx+/UHVY0gOa1JRlbok2akJsz5ad+bjDCI+mn rqkZObUx4SVW4IUz3IaQEZXItuuTH3FfQtgekarVlRDGjJoQ8cLGXdRppYzLODZI O89A5/qq7F9bjWOUxY9DnkcFfMgqRqmLg6gm3bNRzPULduUbywXvNY0HSUhHkGYX 9cLP5dpd3TDIJob3YA63N2Q7v2t1+hLb4En7EtFYRpse6GfjLmfM/QtPGvBSP7Pf 5/ec0R0u+9Z91UFKrJAAPdFIko5PxtyfeC7oNMj/EqurSup6usHa7x9S8Eb9qFtq sN/U90mCoxcvpMm1O3v1hv74hfVUBgSazu7Qwnkb/391HF51UPoqvbN5QvlTdPlx 58zvW2XdBMIsogbKDYorggFJorSEtr0fy5rFgLjLzzdqFgTUh88iRilqTYzyAAWV lkjbqxCNHcSdn+PkpBlM/k2JIY02UmTn663SfuOAtPWnrYC8e9cWKS9Tg4hJniyW 1CBUg1qA3zaU+L+bw43VMMos15nLedpq+iIFalcbbfi5pMt/cl4kkt/C1sFGyhh/ EdgkzDs/YbQH4t1s2KtU =rnHU -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#717448: apache2: Invalid command 'AuthType'
Dear Arno, phpmyadmin does indeed use a conditional statement, just the wrong one. # Authorize for setup Directory /usr/share/phpmyadmin/setup IfModule mod_authn_file.c AuthType Basic AuthName phpMyAdmin Setup AuthUserFile /etc/phpmyadmin/htpasswd.setup /IfModule Require valid-user /Directory a2enmod authn_core does indeed fix the problem. Thanks. On 07/21/13 10:44, Arno Töll wrote: reassign 717448 phpmyadin thanks On 21.07.2013 03:59, Jean-Michel Vourgère wrote: Try $ a2enmod authn_core It fixes the same problem here. AuthType is provided by authn_core in httpd 2.4 and no longer provided by the core module. As such, it is not available unconditionally in a apache2 2.4 installation. Packags must not use such directives without protecting them with IfModule. Please see our packaging guidelines at [1]. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;hb=master#l194 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681374: Re: Bug #681374 cherry picked upstream patch
The fix is present in the current unstable version of rhythmbox(shell/rb-shell-player.c Line: 1409), probably because it is based on a more recent upstream snapshot. So this bug should probably be marked as fixed in unstable. What would be the next steps to get this fix into stable as well? Regards, Marcel Meißner signature.asc Description: This is a digitally signed message part
Bug#717493: pu: package sympa/6.1.11~dfsg-5.1~deb7u1
On 2013-07-21 15:13, Adam D. Barratt wrote: Whichever solution was chosen, it looks like this bug is not fixed in unstable yet? Yes, I wanted to write a sentence about this as well ... If the release team considers adding a pre-depends in stable as acceptable, I would first upload a NMU to sid (same patch, just omitting the wheezy changelog entry) and later on to wheezy. Instead of doing NMUs, maintainer uploads would be welcome of course! Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717436: pu: shutdown-at-night - avoid daily email from cron when enabled
On Sat, 2013-07-20 at 23:07 +0200, Petter Reinholdtsen wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please stop filing stable update requests as unblocks; they're not requests to move a package to testing. Here is a request to approve an upload of shutdown-at-night to wheezy, to fix a bug Debian Edu would like to have fixed in our Debian Edu Wheezy release. The same fix was uploaded as version 0.11 to unstable with this changelog entry: [...] This is the change I want to include: [...] Please let us know if this is OK before we upload, and tell us which version number to use for this upload. In general, we'd prefer to see a complete debdiff of the proposed package, including changelog stanza, rather than simply isolated patches. (reportbug would have prompted for that, along with setting the tags correctly.) However, if the diff is purely the addition of the patch, with a changelog entry similar to the unstable upload, then I guess you could go ahead; please use 0.10+deb7u1 (predictably) as the version number and wheezy as the changelog distribution. 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#717349: [Pkg-systemd-maintainers] Bug#717349: systemd: Leftover symlink to debian-enable-units.service
control: tag -1 + pending Am 19.07.2013 18:31, schrieb Daniel Schaal: Package: systemd Version: 204-1 Severity: minor Tags: patch There is a leftover symlink to the now removed debian-enable-units.service in /lib/systemd/system/basic.target.wants/ Tiny patch attached, Thanks for the patch, applied as 5c31508 -- 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#717434: RFA: socat -- multipurpose relay for bidirectional data transfer
On Sat, Jul 20, 2013 at 10:48 PM, Chris Taylor ctay...@debian.org wrote: Package: wnpp Severity: normal X-Debbugs-CC: debian-de...@lists.debian.org I intend to orphan socat in the next few weeks and would like someone to adopt the package as it is still useful to many. I no longer have the time nor motivation/need to continue to maintain it, therefore I am formally requesting its adoption. Do you intend to help mentoring ? Bastien Description-en: multipurpose relay for bidirectional data transfer Socat (for SOcket CAT) establishes two bidirectional byte streams and transfers data between them. Data channels may be files, pipes, devices (terminal or modem, etc.), or sockets (Unix, IPv4, IPv6, raw, UDP, TCP, SSL). It provides forking, logging and tracing, different modes for interprocess communication and many more options. . It can be used, for example, as a TCP relay (one-shot or daemon), as an external socksifier, as a shell interface to Unix sockets, as an IPv6 relay, as a netcat and rinetd replacement, to redirect TCP-oriented programs to a serial line, or to establish a relatively secure environment (su and chroot) for running client or server shell scripts inside network connections. Socat supports sctp as of 1.7.0. Thanks, Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705919: icedove does not play sounds (notifications when new messages arrive)
One new idea basing on this Link: http://forums.bodhilinux.com/index.php?/topic/5060-solved-thunderbird-stopped-playing-sound-when-new-messages-arrive/ The libs libesd0 libcanberra0 libstdc are installed. Esound is installed, but the pulseaudio layer was missed first. # dpkg -l | grep esound ii esound-common 0.2.41-10 all Enlightened Sound Daemon - Common files ii pulseaudio-esound-compat 2.0-6.1amd64PulseAudio ESD compatibility layer Sound is still not playing. I found out that the esound daemon is not runnning. But when i manually start esd this does not matter. # esd -v pulseaudio esd wrapper 2.0 I am not shure if this mus really run, because it is also a wrapper? Regards Karsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717436: pu: shutdown-at-night - avoid daily email from cron when enabled
[Adam D. Barratt]
Please stop filing stable update requests as unblocks; they're not
requests to move a package to testing.
Sorry, my mistake copying from the wrong bug. :)
Hope to do better if I have to do it again.
However, if the diff is purely the addition of the patch, with a
changelog entry similar to the unstable upload, then I guess you
could go ahead; please use 0.10+deb7u1 (predictably) as the version
number and wheezy as the changelog distribution.
Thank you. I have uploaded it. This is the complete debdiff.
diff -Nru shutdown-at-night-0.10/debian/changelog
shutdown-at-night-0.10+deb7u1/debian/changelog
--- shutdown-at-night-0.10/debian/changelog 2012-02-13 23:42:49.0
+0100
+++ shutdown-at-night-0.10+deb7u1/debian/changelog 2013-07-21
15:37:21.0 +0200
@@ -1,3 +1,10 @@
+shutdown-at-night (0.10+deb7u1) wheezy; urgency=low
+
+ * Quiet down cron job to wake up client to not complain when fping
+notice they are unavailable.
+
+ -- Petter Reinholdtsen p...@debian.org Sun, 21 Jul 2013 15:36:19 +0200
+
shutdown-at-night (0.10) unstable; urgency=low
* Do not shut down if uptime is less then an hour. Based on patch and
diff -Nru shutdown-at-night-0.10/wakeupclients
shutdown-at-night-0.10+deb7u1/wakeupclients
--- shutdown-at-night-0.10/wakeupclients2008-06-13 10:55:04.0
+0200
+++ shutdown-at-night-0.10+deb7u1/wakeupclients 2013-07-21 15:39:21.0
+0200
@@ -63,7 +63,7 @@
sub get_alive_list {
my @addresses = @_;
-return split(/\s+/, `fping -a @addresses`);
+return split(/\s+/, `fping -a @addresses 2/dev/null`);
}
sub logmsg {
--
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#717476: phpmyadmin: breaks apache starting with invalid config file
On Sun, July 21, 2013 10:46, Norbert Preining wrote: Package: phpmyadmin Version: 4:4.0.4.1-1 Severity: critical Justification: breaks unrelated software Hi, recently I realized that apache does not start anymore, doing the suggested configtest I get: $ env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin /usr/sbin/apache2ctl configtest AH00526: Syntax error on line 3 of /etc/apache2/conf-enabled/phpmyadmin.conf: Invalid command 'Alias', perhaps misspelled or defined by a module not included in the server configuration Action 'configtest' failed. The Apache error log may have more information. Apparently your installation does not have mod_alias enabled. Using mod_alias to configure web applications is the Debian webapps policy compliant way to do it. The Debian Apache maintainers describe that web applications can rely unconditionally on the presence of mod_alias: http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;hb=master#l194 Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717448: apache2: Invalid command 'AuthType'
Hi Arno, On Sun, July 21, 2013 14:54, Jon Westgate wrote: On 07/21/13 10:44, Arno Töll wrote: reassign 717448 phpmyadin thanks On 21.07.2013 03:59, Jean-Michel Vourgère wrote: Try $ a2enmod authn_core It fixes the same problem here. AuthType is provided by authn_core in httpd 2.4 and no longer provided by the core module. As such, it is not available unconditionally in a apache2 2.4 installation. Packags must not use such directives without protecting them with IfModule. Please see our packaging guidelines at [1]. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;hb=master#l194 Does it make sense to allow to use mod_authn_file unconditionally in config files, but not allow authn_core unconditionally? authn_core provides directives that are common to all authentication providers. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717435: sympa: fails to install if ca-certificates trigger has never been run
Dear ca-certificates maintainers, On 2013-07-20 23:05, Andreas Beckmann wrote: Installing sympa in a minimal system using apt-get install sympa fails, but changing this to apt-get install ca-certificates apt-get install sympa succeeds. This seems to indicate that sympa depends on a successful run of the ca-certificates trigger *before* configuring sympa ... While this can be fixed with a Pre-Depends, I'm not sure whether this is the correct approach. There might be more packages affected by similar bugs in the future. An alternative solution would be to have ca-certificates.postinst force a trigger run (if that is possible), so that at least ca-certificates.crt is available after ca-certificates has been configured, but the final trigger run has not been performed, yet. That should guarantee that a package may Depends: ca-certificates and can use /etc/ssl/certs/ca-certificates.crt in its postinst. (I assume that sympa tries to access this file, but have not verified this.) I'm not sure whether fixing this via the triggers is actually possible, IIRC the triggers are mainly for coordination with ca-certificates-java, and this should not get broken in stable ... Andreas PS: there is pu request #717493 for adding the pre-depends to sympa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694252: fixed in sysvinit 2.88dsf-41+deb7u1
clone 694252 -1 reassign -1 bootchart user debian...@lists.debian.org usertag -1 piuparts found -1 0.10~svn407-3.3 severity -1 serious tags -1 = thanks On Wednesday, 17. July 2013 23:02:21 Roger Leigh wrote: sysvinit (2.88dsf-41+deb7u1) stable-proposed-updates; urgency=low . [ Roger Leigh ] * Correct the Breaks on bootchart to ensure that all broken versions are removed on upgrade (Closes: #694252). Break bootchart 0.10~svn407-4 to ensure that 0.10~svn407-3.3 and earlier are removed. Dammit, that does not work. And now we have made bootchart uninstallable in stable and sid ... we need to make changes in bootchart to get this ancient upgrade path fixed ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717448: apache2: Invalid command 'AuthType'
clone 717448 -1 reassign -1 apache2 retitle -1 apache2: Please enable authn_core by default thanks On 21.07.2013 15:59, Thijs Kinkhorst wrote: Does it make sense to allow to use mod_authn_file unconditionally in config files, but not allow authn_core unconditionally? authn_core provides directives that are common to all authentication providers. We can of course discuss this. I'm making a separate issue out of it, as its not directly related to the problem in phpmyadmin. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717457: pu: package oss4/4.2-build2006-2+deb7u2
Andreas Beckmann (2013-07-21): Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Hi, oss4-dkms and oss4-source have insufficient dependencies and fail to build kernel modules in a minimal system. Since the module fails to build for the current kernel in sid, I cannot verify whether some of these dpendencies are missing is sid, too. Sigh @ out-of-tree kernel modules… + * Non-maintainer upload. + * oss4-dkms: Add missing Depends: dpkg-dev, libc6-dev. (Closes: #687086) At least ia64 has a non-libc6-dev package, libc6.1-dev instead. I guess the Provides is sufficient at the moment, but if that's turned into a versioned dependency at some point, that won't fly. + * oss4-source: Add missing Depends: gcc, libc6-dev. I'm not sure whether it might make sense to just pull build-essential, which would do the job on all architectures, without risking getting unsatisfiable dependencies. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717497: smb4k does not work on Version 7.1 (wheezy) 32 bits, can't open the network
Package: smb4k Version: 1.0.1-1 Severity: grave Tags: upstream Justification: renders package unusable Just installed the smb4K with synaptic After succesful installation ran smb2k, set up, the working tab and network and computers and printers in the main smb4k window does not appear. Nota bene : I can ping all of them on a terminal. outcome = Nothing i can't access to printers and files on my private network -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages smb4k depends on: ii cifs-utils2:6.0-1 ii kde-runtime 4:4.8.4-2 ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libkdecore5 4:4.8.4-4 ii libkdeui5 4:4.8.4-4 ii libkio5 4:4.8.4-4 ii libkparts44:4.8.4-4 ii libnepomuk4 4:4.8.4-4 ii libnepomukutils4 4:4.8.4-4 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-network4:4.8.2+dfsg-11 ii libqt4-svg4:4.8.2+dfsg-11 ii libqt4-xml4:4.8.2+dfsg-11 ii libqtcore44:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libsolid4 4:4.8.4-4 ii libsoprano4 2.7.6+dfsg.1-2wheezy1 ii libstdc++64.7.2-5 ii samba-common-bin 2:3.6.6-6 ii smbclient 2:3.6.6-6 Versions of packages smb4k recommends: ii sudo 1.8.5p2-1+nmu1 Versions of packages smb4k suggests: pn kwalletmanager none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#405888: patch from 2007 still useful today ?
Hi, #405888 customization-modules architecture for add-on udebs has a patch, can someone for sure say whether this patch is still useful today? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#717495: sysv-rc: migration to dependency based boot order fails if bootchart from lenny is still installed
Followup-For: Bug #717495 Control: tag -1 patch Hi, I'm attaching a patch with a proposed fix for the lenny-squeeze-upgrade patch, this patch needs to be applied in wheezy-pu to be effective. The idea is to rename the initscript from bootchart to stop-bootchart, so that the buggy script is no longer available while configuring sysv-rc, even if bootchart has not yet been configured and the new initscript is not yet in place. Note that the version to be uploaded to wheezy needs to have a version = 0.10~svn407-4 because of the Breaks in initscripts. The version uploaded to sid needs to be even larger. The NMU version pair (sid, wheezy) I suggest is (0.10~svn407-4.1, 0.10~svn407-4.1~deb7u1) A maintainer upload of (0.10~svn407-4, 0.10~svn407-4~deb7u1) *WONT WORK* (without changing sysvinit), probably bump to (0.10~svn407-5, 0.10~svn407-5~deb7u1) Andreas diff -u bootchart-0.10~svn407/debian/control bootchart-0.10~svn407/debian/control --- bootchart-0.10~svn407/debian/control +++ bootchart-0.10~svn407/debian/control @@ -12,6 +12,7 @@ Package: bootchart Architecture: all +Pre-Depends: dpkg (= 1.15.7.2) Depends: psmisc, lsb-base (= 3.0-6) Recommends: bootchart-view, acct Description: Boot process performance analyser diff -u bootchart-0.10~svn407/debian/rules bootchart-0.10~svn407/debian/rules --- bootchart-0.10~svn407/debian/rules +++ bootchart-0.10~svn407/debian/rules @@ -50,6 +50,7 @@ dh_installexamples dh_installman dh_installinit --no-restart-on-upgrade --no-start \ + --init-script=stop-bootchart \ --update-rcd-params=start 99 1 2 3 4 5 . dh_link dh_compress diff -u bootchart-0.10~svn407/debian/changelog bootchart-0.10~svn407/debian/changelog --- bootchart-0.10~svn407/debian/changelog +++ bootchart-0.10~svn407/debian/changelog @@ -1,3 +1,23 @@ +bootchart (0.10~svn407-4.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Fix the upgrade path lenny (bootchart 0.10~svn407-3) = squeeze (bootchart +0.10~svn407-3 from lenny because bootchart was not included in squeeze) = +wheezy. The initscript from 0.10~svn407-3 prevents migration to dependency +based boot sequencing causing a sysv-rc upgrade failure. Since it is not +possible to express a dependency/conflict like either bootchart is purged +or fully configured, it is possible for an updated bootchart being +unpacked but unconfigured, leaving the broken initscript still in place at +the time sysv-rc tries to switch to dependency-based sequencing. +Therefore rename the initscript from bootchart to stop-bootchart which +will move the buggy script out of the way early enough to make sysv-rc +succeed. Use Pre-Depends: dpkg (= 1.15.7.2) and dpkg-maintscript-helper +for the renaming. (Closes: #717495) + * Bump Debian revision to -4.1 to restore installability after recent +initscripts having Breaks: bootchart ( 0.10~svn407-4). + + -- Andreas Beckmann a...@debian.org Sat, 20 Jul 2013 16:44:05 +0200 + bootchart (0.10~svn407-3.3) unstable; urgency=low * Non-maintainer upload. diff -u bootchart-0.10~svn407/debian/bootchart.init bootchart-0.10~svn407/debian/bootchart.init --- bootchart-0.10~svn407/debian/bootchart.init +++ bootchart-0.10~svn407/debian/bootchart.init @@ -17,7 +17,7 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin NAME=bootchartd DAEMON=/sbin/$NAME -SCRIPTNAME=/etc/init.d/bootchart +SCRIPTNAME=/etc/init.d/stop-bootchart # Exit if the package is not installed [ -x $DAEMON ] || exit 0 diff -u bootchart-0.10~svn407/debian/bootchart.postrm bootchart-0.10~svn407/debian/bootchart.postrm --- bootchart-0.10~svn407/debian/bootchart.postrm +++ bootchart-0.10~svn407/debian/bootchart.postrm @@ -5,6 +5,8 @@ set -e +dpkg-maintscript-helper mv_conffile /etc/init.d/bootchart /etc/init.d/stop-bootchart 0.10~svn407-4~ bootchart -- $@ + case $1 in purge) rm -f /var/log/bootchart.tgz only in patch2: unchanged: --- bootchart-0.10~svn407.orig/debian/bootchart.preinst +++ bootchart-0.10~svn407/debian/bootchart.preinst @@ -0,0 +1,6 @@ +#!/bin/sh +set -e + +dpkg-maintscript-helper mv_conffile /etc/init.d/bootchart /etc/init.d/stop-bootchart 0.10~svn407-4~ bootchart -- $@ + +#DEBHELPER# only in patch2: unchanged: --- bootchart-0.10~svn407.orig/debian/bootchart.postinst +++ bootchart-0.10~svn407/debian/bootchart.postinst @@ -0,0 +1,6 @@ +#!/bin/sh +set -e + +dpkg-maintscript-helper mv_conffile /etc/init.d/bootchart /etc/init.d/stop-bootchart 0.10~svn407-4~ bootchart -- $@ + +#DEBHELPER#
Bug#653813: ITP: edgar -- The Legend of Edgar platform game
On Sat, Jul 13, 2013 at 08:44:53AM +, Richard Sweeney wrote: I have removed all the non-free sounds and music from the game now. The media I'm using, along with their licences and download origin, are in the file below (I won't paste the contents here, it's pretty long). http://sourceforge.net/p/legendofedgar/code/1110/tree/branches/dfsg/doc/music_and_sound_licences Rik just released version 1.10 with the new DFSG-compliant media. Joseph, are you still intending to package it? -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Bug#717040: kmail: Can't send mail since upgrading to 4:4.10.5-1
On Sun, 21 Jul 2013 11:10:06 +0200 Pino Toscano p...@debian.org wrote: Hi, Alle martedì 16 luglio 2013, Russell Coker ha scritto: Since upgrading to 4:4.10.5-1 from 4:4.4.11.1+l10n-3+b1 I have been unable to send mail. Mail stays in the Outbox folder forever and the Send Queued Messages option has no effect. I have tried deleting the sending accounts and creating a new entry (which sends mail to localhost port 587) and that makes no difference. Are you using the postgresql backend of akonadi? Can you please paste the result of `dpkg -l '*akonadi*' | grep ^ii`? I'm not using PostgreSQL at all. $ dpkg -l '*akonadi*' | grep ^ii|cut -c 1-60 ii akonadi-backend-mysql 1.9.2-2 ii akonadi-server 1.9.2-2 ii akonadiconsole 4:4.10.5-1 ii libakonadi-calendar4 4:4.10.5-1 ii libakonadi-contact4 4:4.10.5-1 ii libakonadi-dev 1.9.2-2 ii libakonadi-kabc4 4:4.10.5-1 ii libakonadi-kcal4 4:4.10.5-1 ii libakonadi-kde4 4:4.10.5-1 ii libakonadi-kmime4 4:4.10.5-1 ii libakonadi-notes4 4:4.10.5-1 ii libakonadi-socialutils4 4:4.10.5-1 ii libakonadiprotocolinternals1 1.9.2-2 -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717498: pu: package bootchart/0.10~svn407-4.1~deb7u1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Hi, the change I suggested for sysvinit (#694252) and got applied in sysvinit/2.88dsf-41+deb7u1 does not fix the bootchart upgrade path lenny-squeeze-wheezy, but instead renders bootchart uninstallable in stable (and sid as well): #717495. I'm attaching a suggested patch to fix this upgrade path along with the uninstallability. This will work by renaming /etc/init.d/bootchart to /etc/init.d/stop-bootchart. As a side effect, the buggy initscript will have been renamed to bootchart.dpkg-remove so that it is not considered by sysv-rc even if the new one is not yet installed. Or is there another possibility to force the new bootchart being configured before sysv-rc (without adding a Pre-Depends)? The fix has not been applied in sid, yet. If the release team considers this rename as a possible solution for wheezy, I'll first get this applied in sid. I can confirm that this patch fixes the lenny-squeeze-wheezy upgrade path if it gets applied to wheezy. The bootchart versioning is bumped in a way that requires no further changes to sysvinit to restore installability. Andreas diff -u bootchart-0.10~svn407/debian/control bootchart-0.10~svn407/debian/control --- bootchart-0.10~svn407/debian/control +++ bootchart-0.10~svn407/debian/control @@ -12,6 +12,7 @@ Package: bootchart Architecture: all +Pre-Depends: dpkg (= 1.15.7.2) Depends: psmisc, lsb-base (= 3.0-6) Recommends: bootchart-view, acct Description: Boot process performance analyser diff -u bootchart-0.10~svn407/debian/rules bootchart-0.10~svn407/debian/rules --- bootchart-0.10~svn407/debian/rules +++ bootchart-0.10~svn407/debian/rules @@ -50,6 +50,7 @@ dh_installexamples dh_installman dh_installinit --no-restart-on-upgrade --no-start \ + --init-script=stop-bootchart \ --update-rcd-params=start 99 1 2 3 4 5 . dh_link dh_compress diff -u bootchart-0.10~svn407/debian/changelog bootchart-0.10~svn407/debian/changelog --- bootchart-0.10~svn407/debian/changelog +++ bootchart-0.10~svn407/debian/changelog @@ -1,3 +1,29 @@ +bootchart (0.10~svn407-4.1~deb7u1) wheezy; urgency=low + + * Build for wheezy. + + -- Andreas Beckmann a...@debian.org Sat, 20 Jul 2013 20:21:17 +0200 + +bootchart (0.10~svn407-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix the upgrade path lenny (bootchart 0.10~svn407-3) = squeeze (bootchart +0.10~svn407-3 from lenny because bootchart was not included in squeeze) = +wheezy. The initscript from 0.10~svn407-3 prevents migration to dependency +based boot sequencing causing a sysv-rc upgrade failure. Since it is not +possible to express a dependency/conflict like either bootchart is purged +or fully configured, it is possible for an updated bootchart being +unpacked but unconfigured, leaving the broken initscript still in place at +the time sysv-rc tries to switch to dependency-based sequencing. +Therefore rename the initscript from bootchart to stop-bootchart which +will move the buggy script out of the way early enough to make sysv-rc +succeed. Use Pre-Depends: dpkg (= 1.15.7.2) and dpkg-maintscript-helper +for the renaming. (Closes: #717495) + * Bump Debian revision to -4.1 to restore installability after recent +initscripts having Breaks: bootchart ( 0.10~svn407-4). + + -- Andreas Beckmann a...@debian.org Sat, 20 Jul 2013 20:21:12 +0200 + bootchart (0.10~svn407-3.3) unstable; urgency=low * Non-maintainer upload. diff -u bootchart-0.10~svn407/debian/bootchart.init bootchart-0.10~svn407/debian/bootchart.init --- bootchart-0.10~svn407/debian/bootchart.init +++ bootchart-0.10~svn407/debian/bootchart.init @@ -17,7 +17,7 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin NAME=bootchartd DAEMON=/sbin/$NAME -SCRIPTNAME=/etc/init.d/bootchart +SCRIPTNAME=/etc/init.d/stop-bootchart # Exit if the package is not installed [ -x $DAEMON ] || exit 0 diff -u bootchart-0.10~svn407/debian/bootchart.postrm bootchart-0.10~svn407/debian/bootchart.postrm --- bootchart-0.10~svn407/debian/bootchart.postrm +++ bootchart-0.10~svn407/debian/bootchart.postrm @@ -5,6 +5,8 @@ set -e +dpkg-maintscript-helper mv_conffile /etc/init.d/bootchart /etc/init.d/stop-bootchart 0.10~svn407-4~ bootchart -- $@ + case $1 in purge) rm -f /var/log/bootchart.tgz only in patch2: unchanged: --- bootchart-0.10~svn407.orig/debian/bootchart.preinst +++ bootchart-0.10~svn407/debian/bootchart.preinst @@ -0,0 +1,6 @@ +#!/bin/sh +set -e + +dpkg-maintscript-helper mv_conffile /etc/init.d/bootchart /etc/init.d/stop-bootchart 0.10~svn407-4~ bootchart -- $@ + +#DEBHELPER# only in patch2: unchanged: --- bootchart-0.10~svn407.orig/debian/bootchart.postinst +++ bootchart-0.10~svn407/debian/bootchart.postinst @@ -0,0 +1,6 @@ +#!/bin/sh +set -e + +dpkg-maintscript-helper mv_conffile /etc/init.d/bootchart /etc/init.d/stop-bootchart 0.10~svn407-4~ bootchart -- $@ + +#DEBHELPER#
Bug#634917: ITA: mouseemu -- Emulate mouse buttons and mouse wheel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package wnpp owner 634917 pkg-mactel-de...@lists.alioth.debian.org retitle 634917 O: mouseemu -- Emulate mouse buttons and mouse wheel thanks Hi, I am re-orphaning mouseemu. I believe it is not useful anymore for recent hardware as the synaptics driver can do a better job at emulating three buttons. The benefit of keeping it in the archive to enable middle or right click on decade old laptops does not strike me. I have been using it for a while to trap the brightness up/down buttons on my laptop and send them to pommed, but this is fixed directly in pommed (in git) now. If someone wants to adopt this package, I suggest putting it in team maintenance in the pkg-mactel team. It would need to be updated. Look at the Ubuntu version, which fixes many of the bugs. It doesn't fix this one, though: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708389 If this package is not adopted in the near future, I'll ask for its removal later this year. Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJR6/ZUAAoJEJOUU0jg3ChA1UEP/1t9Ky9JIVZ41wqH3I+tjAwE /dETZWvGTzJxLA5fNzMHwB2GZdHV7n59lOGOy+PXnEu3k20Af1H0Et3VnY1eptNf 7iy+exeKDe0h4wVKltzUvWtqpzI0nLTVqaoyisZUvrOXjHx43qnuGnYAkiqgsChd 6jNlMGzwd/C3goagP9VO8c6xSRl7vMM5TImPM+14vsisvF9Bpshgima/FW0d5EMd 45glZGC4dlqFew1qq1BDfCZsjYWXHf5oT8XDiqzeLWhS08vn1bm4zUve6S/2KfCz C7RaM77kptua1yBNl3KGgymgARssVnaRrb+YyPEt2Rk6aR0choqPuL6BmAi7nArF glyB/LxIwaXFtYysx+GDWKAVua7EnauuxqtzUah5/waUeXV6KcBGt6XxWYmdBss7 mu9TrpeCSfaDrmy/CALGvJIaORaO7J8TdOfy50nyvjsZpVF748T6zBIK1+6K/Zi9 veJLGPeN31bxGONaiorYsfMud6aFPTmME+vhybokAm61k7/7JV06a3/596nEC+Jl U0+GuwfXMdHtMSTtojiXu9zFlejwzBsGTGs0xeBSA/vtOcz556bFlq6KpPVmZXXe fZO8Ep7OikrCX+/79eTDoPg/TLnkEn+bz7u9UXQ/ZEDY2ZhNJ8z1HXatzA24z1df wT4PGAc3OzXPV7acdXUT =qbs6 -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#717255: [Pkg-freeipmi-devel] Bug#717255: src:freeipmi: maintainer address rejects mail
On Thu, Jul 18, 2013 at 10:10:04PM +0200, Bernd Zeimetz wrote: the Debian policy says The email address given in the Maintainer control field must accept mail from those role accounts in Debian used to send automated mails regarding the package. This includes non-spam mail from the bug-tracking system, all mail from the Debian archive maintenance software, and other role accounts or automated processes that are commonly agreed on by the project. I could not verify whether it is also rejecting mail from role accounts and chose a non-rc severity accordingly. It does not require to accept mail from everybody. As you can see that the email address is a list, you are free to join the list on alioth, then you are allowed to post to it. Or contact the maintainers using the bug tracking system. as you can see, the BTS mails arrive just fine. To avoid having yet another list catching tons of spam, I don't think it will be opened for public postings. Your reasoning makes sense. Still it makes discovering the contact for a random package a little harder and that is unfortunate. This issue recently popped up on -devel during the Mayhem reports. If you have a suggestion on how to mechanically determine the (public/private) security contacts of a random package, that would be appreciated. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717499: Apache 2.4 changed remote_ip, use remote_host() instead
Package: netdisco-frontend /usr/share/netdisco/html/login.html line 50 will fail as Apache 2.4 does note have remote_ip anymore due to internal changes (hence 2.4 instead of 2.2). In that file instead of: my $userip= $r-connection-remote_ip; just have: my $userip= $r-connection-remote_host(); and everything will work again. This holds for netdisco 1.0 till the recently released 1.3. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717500: mesa: Please add support for OpenCL/GalliumCompute
Source: mesa Version: 9.1.4-1 Severity: wishlist Dear X Strike Force, Are there any plan to include support for OpenCL/GalliumCompute in the Debian build of Mesa ? There is some support for OpenCL on top of Gallium3D since Mesa 9.0, it would be nice to have it available in the Debian packages of Mesa. Regards, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717501: RM: libnet-amqp-perl -- ROM; uploaded to NEW queue using wrong (non-DFSG-stripped) tarball
Package: ftp.debian.org Severity: normal Hi ftpmasters, As subject says, I accidentally uploaded libnet-amqp-perl to NEW queue using the non-DSFG-stripped source tarball as intended :-/ Please drop it, so I can publish again with the correct DFSG-free tarball. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717502: provide a way to use new keyboard models
Package: pommed
Version: 1.39~dfsg-3.1
Severity: wishlist
Tags: upstream
Hi,
It took me a while to understand why I had to use mouseemu in conjunction with
pommed to make the latter work.
Pommed has a built-in list of product ids it will accept as keyboards. Whenever
a new model comes out, pommed will refuse to use it. One the other hand, it
will gladly use the Mouseemu Virtual Keyboard, which is much less fussy about
what devices it should open.
I see two (non-exclusive) solutions:
1- accept any keyboard;
2- provide a runtime configuration option in which the user can specify which
device to use. I suggest this option should concern directly the product id:
general {
# If pommed fails to detect your internal keyboard, put here the
product id listed by lsusb
product_id = 05ac:0253
}
If you agree on such a scheme, I can work on a patch.
Kind regards, Thibaut.
-- System Information:
Debian Release: 7.1
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.9-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages pommed depends on:
ii eject 2.1.5+deb1+cvs20081104-13
ii libasound2 1.0.25-4
ii libaudiofile1 0.3.4-2
ii libc6 2.13-38
ii libconfuse02.7-4
ii libdbus-1-31.6.8-1+deb7u1
ii libpci31:3.1.9-6
Versions of packages pommed recommends:
ii dbus 1.6.8-1+deb7u1
pommed suggests no packages.
-- Configuration Files:
/etc/pommed.conf changed [not included]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717479: Background-scanning for devices and options
also sprach Jeffrey Ratcliffe jeffrey.ratcli...@gmail.com [2013.07.21.1251 +0200]: The fact that scanimage seems to work fine but libsane-perl does not obviously indicates that there is a bug in libsane-perl. Would you mind trying scanimage-perl? This is a scanimage transliterated into perl, and therefore also uses libsane-perl. There is no noticeable difference in the delays over pure scanimage. Any ideas on how to debug the libsane-perl/saned combination without using multiple machines? I can use the local saned to talk to the device over IP directly if that helps. -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems if you are walking on thin ice, you might as well dance! digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#717503: Test for usb-db before using it / replaced by hwdb in newer udev releases
Package: colord
Version: 1.0.1-1
Severity: normal
Tags: patch
In newer udev versions, usb-db has been replaced by the hwdb builtin.
Instead of removing the import, test for the helper before running it.
This way we are compatible with both old and new udev.
Eventually we should switch to hwdb fully, but for now it is probably
safest to support older udev versions without hwdb, too.
Patch attached.
Would be great if you can prepare a new release soon, as we want to
upload udev 204-1 from experimental to unstable and this will generate a
warning/errror message on each boot.
Michael
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-1-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
Versions of packages colord depends on:
ii acl 2.2.52-1
ii adduser 3.113+nmu3
ii dconf-gsettings-backend [gsettings-backend] 0.16.1-1
ii libc62.17-7
ii libcolord1 1.0.1-1
ii libcolorhug1 1.0.1-1
ii libdbus-1-3 1.6.12-1
ii libglib2.0-0 2.36.3-3
ii libgudev-1.0-0 175-7.2
ii libgusb2 0.1.6-2
ii liblcms2-2 2.2+git20110628-2.2
ii libpolkit-gobject-1-00.105-3
ii libsane 1.0.23-3
ii libsqlite3-0 3.7.17-1
ii libsystemd-login0204-1
ii libusb-1.0-0 2:1.0.16-1
ii policykit-1 0.105-3
colord recommends no packages.
colord suggests no packages.
-- no debconf information
From 4c6bbd75f070ebd55a889868182891fa9adacc0e Mon Sep 17 00:00:00 2001
From: Michael Biebl bi...@debian.org
Date: Sun, 21 Jul 2013 17:26:58 +0200
Subject: [PATCH] Test for usb-db before running it
In newer udev versions, usb-db has been replaced by the hwdb builtin.
Instead of removing the import, test for the helper before running it.
This way we are compatible with both old and new udev.
---
rules/69-cd-sensors.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/69-cd-sensors.rules b/rules/69-cd-sensors.rules
index a955a63..5bc8cdb 100644
--- a/rules/69-cd-sensors.rules
+++ b/rules/69-cd-sensors.rules
@@ -87,7 +87,7 @@ ATTRS{idVendor}==273f, ATTRS{idProduct}==1002, ENV{COLORD_SENSOR_KIND}=colo
# color calibration device
ENV{COLORD_SENSOR_KIND}==*?, ENV{COLOR_MEASUREMENT_DEVICE}=1
ENV{COLORD_SENSOR_KIND}==*?, ENV{ID_MODEL}==, IMPORT{program}=usb_id --export %p
-ENV{COLORD_SENSOR_KIND}==*?, ENV{ID_MODEL_FROM_DATABASE}==, IMPORT{program}=usb-db %p
+ENV{COLORD_SENSOR_KIND}==*?, ENV{ID_MODEL_FROM_DATABASE}==, TEST==/lib/udev/usb-db, IMPORT{program}=usb-db %p
# Allow the daemon to access the color devices
ENV{COLORD_SENSOR_KIND}==*?, GROUP=root
--
1.8.3.2
Bug#711833:
Hello, I discover the postr package and i am interested to be an adopter for it. It's my first contribution for the debian community. Regards Yoann
Bug#619244: /etc/machine-id
On Sun, Jul 21, 2013 at 01:23:48PM +0200, Michael Stapelberg wrote: Josh Triplett j...@joshtriplett.org writes: On the other hand, I'm somewhat curious what upstream actually *uses* the machine-id for, and why a machine needs a unique identifier. The only use of the machine-id in Debian that I could find is within the journal: [...] Given that the file replaces the old DBus machine-id, if you consider that, we have a few more calls in the archive: [...] Also, http://www.freedesktop.org/software/systemd/man/machine-id.html explains: Thanks for the explanation. That mail from me is quite old, and I'd since found out a lot more about systemd and why it wants machine-id. :) - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717498: pu: package bootchart/0.10~svn407-4.1~deb7u1
Andreas Beckmann (2013-07-21): the change I suggested for sysvinit (#694252) and got applied in sysvinit/2.88dsf-41+deb7u1 does not fix the bootchart upgrade path lenny-squeeze-wheezy, but instead renders bootchart uninstallable in stable (and sid as well): #717495. I'm attaching a suggested patch to fix this upgrade path along with the uninstallability. This will work by renaming /etc/init.d/bootchart to /etc/init.d/stop-bootchart. As a side effect, the buggy initscript will have been renamed to bootchart.dpkg-remove so that it is not considered by sysv-rc even if the new one is not yet installed. Or is there another possibility to force the new bootchart being configured before sysv-rc (without adding a Pre-Depends)? Needless to say, I'm not impressed by the amount of changes and the whole lot of possible side effects. The fix has not been applied in sid, yet. If the release team considers this rename as a possible solution for wheezy, I'll first get this applied in sid. I can confirm that this patch fixes the lenny-squeeze-wheezy upgrade path if it gets applied to wheezy. Please stop filing pu requests for bugs that aren't even fixed in unstable; that's not amusing and wasting everyone's time. KiBi. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717504: Test for usb-db before using it / replaced by hwdb in newer udev releases
Package: argyll
Version: 1.4.0-8
Severity: normal
Tags: patch
In newer udev versions, usb-db has been replaced by the hwdb builtin.
Instead of removing the import, test for the helper before running it.
This way we are compatible with both old and new udev.
Eventually we should switch to hwdb fully, but for now it is probably
safest to support older udev versions without hwdb, too.
Patch attached.
Would be great if you can prepare a new release soon, as we want to
upload udev 204-1 from experimental to unstable and this will generate a
warning/errror message on each boot.
Michael
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-1-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
Versions of packages argyll depends on:
ii libc6 2.17-7
ii libicc2 2.12+argyll1.4.0-8
ii libimdi0 1.4.0-8
ii libjpeg8 8d-1
ii libtiff4 3.9.7-1
ii libusb-0.1-4 2:0.1.12-23.2
ii libx11-6 2:1.6.0-1
ii libxext6 2:1.3.2-1
ii libxinerama1 2:1.1.3-1
ii libxrandr22:1.4.1-1
ii libxss1 1:1.2.2-1
ii libxxf86vm1 1:1.1.2-1+deb7u1
Versions of packages argyll recommends:
ii consolekit 0.4.5-3.1
ii udev204-1
argyll suggests no packages.
-- no debconf information
Description: Test for usb-db helper before running it
In newer udev versions, the usb-db udev helper has been replaced by
the hwdb builtin. Instead of removing the import, test for the helper
before running it. This way we are compatible with both old and new
udev.
Author: Michael Biebl bi...@debian.org
--- argyll-1.4.0.orig/libusb1/55-Argyll.rules
+++ argyll-1.4.0/libusb1/55-Argyll.rules
@@ -59,6 +59,6 @@ TEST==/lib/udev/udev-acl, TEST==/var/
ENV{COLOR_MEASUREMENT_DEVICE}==*?, ENV{ACL_MANAGE}!=*?, MODE=660, GROUP=plugdev
# Set ID_VENDOR and ID_MODEL acording to VID and PID
-IMPORT{program}=usb-db %p
+TEST==/lib/udev/usb-db, IMPORT{program}=usb-db %p
LABEL=argyll_rules_end
Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80
Package: apache2.2-common Version: 2.2.22-13 Followup-For: Bug #663530 Dear Maintainer, I finally decided to work out why I was getting grumbles from apache about a NameVirtualHost *:80 directive. The only configuration I've actually got enabled (i.e. symlinked from sites-enabled/ to sites-available/) has an explicit IP address rather than a wildcard, so I was initially at a loss. It's based on an old default config, in which the NameVirtualHost line appeared immediately before the VirtualHost directive; and I'd ensured that the two gave the same host:port details, not the default's *:80 but 127.0.0.1:80 in both places. However, closer investigation revealed that /etc/apache2/ports.conf *also* contains a NameVirtualHost *:80 line, which is what the complaints relate to. Commenting it out fixed the warnings about this directive - and fixed several other things that had mysteriously broken some months ago. My configuration's ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ and Alias /doc/ /usr/share/doc/ directives weren't being honoured; I got 404 errors when accessing URLs that should have been resolved by these. These things are all now back to working normally - yay ! The problem is that the NameVirtualHost directive *must* exactly match the VirtualHost directive's parameter. Putting the two in separate files just ensures that the person configuring the server can't actually see that there's a second place that the address:port has to appear, identically, so won't naturally keep the two in sync. Even though I actually have a NameVirtualHost in my enabled sites-available file, matching exactly the same file's VirtualHost parameter, my configuration was broken by a NameVirtualHost *:80 elsewhere, that I knew nothing about. Given that the VirtualHost directive lives in a user-configurable file and *must* exactly match the NameVirtualHost directive, it strikes me that the old way, having the later also in the user-configurable file, was a better approach than the present, where the user must - in fact - edit a file that's not in sub-directory in which user-configuration normally takes place. If there's genuinely a compelling reason to put the NameVirtualHost somewhere other than *right next to* the VirtualHost directive (as I'm fairly sure it used to be), where it'll be obvious that they need to stay in sync, please add a comment to default, immediately before the VirtualHost directive, saying be sure to keep ports.conf's NameVirtualHost in sync; the host:port must match exactly. *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- Package-specific info: List of enabled modules from 'apache2 -M': actions alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi deflate dir env include mime negotiation python reqtimeout rewrite setenvif status userdir -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.22-13 ii apache2.2-bin 2.2.22-13 ii lsb-base 4.1+Debian12 ii mime-support 3.54 ii perl 5.14.2-21 ii procps 1:3.3.4-2 Versions of packages apache2.2-common recommends: ii ssl-cert 1.0.32 Versions of packages apache2.2-common suggests: ii apache2-doc 2.2.22-13 pn apache2-suexec | apache2-suexec-custom none ii chromium [www-browser] 28.0.1500.71-2 ii opera [www-browser] 12.16.1860 ii opera-next [www-browser]12.16.1860 ii w3m [www-browser] 0.5.3-8 Versions of packages apache2.2-common is related to: pn apache2-mpm-eventnone pn apache2-mpm-itk none ii apache2-mpm-prefork 2.2.22-13 pn apache2-mpm-worker none -- Configuration Files: /etc/apache2/mods-available/userdir.conf changed: IfModule mod_userdir.c UserDir web UserDir disabled root Directory /home/*/web AllowOverride FileInfo AuthConfig Limit Indexes Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec # Ignore default's allow/deny: over-ridden by server config. /Directory /IfModule /etc/apache2/ports.conf changed: Listen 80 IfModule mod_ssl.c # If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/apache2/sites-available/default-ssl # to VirtualHost *:443 # Server Name Indication for SSL named virtual hosts is
Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80
Hi, On 21.07.2013 17:32, Edward Welbourne wrote: Even though I actually have a NameVirtualHost in my enabled sites-available file, matching exactly the same file's VirtualHost parameter, my configuration was broken by a NameVirtualHost *:80 elsewhere, that I knew nothing about. ... Given that the VirtualHost directive lives in a user-configurable file and *must* exactly match the NameVirtualHost directive, it strikes me that the old way, having the later also in the user-configurable file, was a better approach than the present, where the user must - in fact - edit a file that's not in sub-directory in which user-configuration normally takes place. If there's genuinely a compelling reason to put the NameVirtualHost somewhere other than *right next to* the VirtualHost directive (as I'm fairly sure it used to be), where it'll be obvious that they need to stay in sync, please add a comment to default, immediately before the VirtualHost directive, saying be sure to keep ports.conf's NameVirtualHost in sync; the host:port must match exactly. First, let me point out that also ports.conf is a user-configurable file. You can safely edit and adapt it to your needs. That what it is meant for. Having NameVirtualHost in 000-default though is dangerous, at is a directive being _shared_ across virtual hosts. It is used by all sites, including but not limited to the default site. Assuming you deactivate the default site, this causes undefined and broken behavior if you have other name based virtual hosts. This is a major problem lots of Debian users stumbled upon over the years. Thus, we're more than glad and very happy NameVirtualHost is no more in 000-default.conf and we are definitely not going back that road. That being said please note, that NameVirtualHost itself is deprecated and not used anymore in Apache2 2.4. There is no chance to fix this in Debian Stable anyway due to our freezing policy, and the next Debian release will have Apache2 2.4 only, not using NameVirtualHost at all anymore. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#708536: transition: python3-defaults (add python3.3 to supported python3)
Followup-For: Bug #708536 A few NMUs for python3 packages are needed in experimental: nmu pygame_1.9.2~pre~r3189-2 . ALL . experimental . -m Rebuild to add support for python3.3 nmu matplotlib_1.2.0-1 . ALL . experimental . -m Rebuild to add support for python3.3 nmu pyopenssl_0.13-3 . ALL . experimental . -m Rebuild to add support for python3.3 nmu python-psutil_0.7.0-1 . ALL . experimental . -m Rebuild to add support for python3.3 nmu python-pyaudio_0.2.7-1 . ALL . experimental . -m Rebuild to add support for python3.3 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717255: [Pkg-freeipmi-devel] Bug#717255: Bug#717255: src:freeipmi: maintainer address rejects mail
On 07/21/2013 05:07 PM, Helmut Grohne wrote: To avoid having yet another list catching tons of spam, I don't think it will be opened for public postings. Your reasoning makes sense. Still it makes discovering the contact for a random package a little harder and that is unfortunate. This issue recently popped up on -devel during the Mayhem reports. If you have a suggestion on how to mechanically determine the (public/private) security contacts of a random package, that would be appreciated. Thats pretty easy: - contact the person who signed the upload ~% who-uploads gpsd Uploads for gpsd: 3.9-1 to unstable: Bernd Zeimetz b...@debian.org 3.6-4+deb7u1 to wheezy: Bernd Zeimetz b...@debian.org 3.6-5 to unstable: Bernd Zeimetz b...@debian.org or the person in the changelog, which should never be a machine account... % zcat /usr/share/doc/gpsd/changelog.Debian.gz | parsechangelog - | grep Maintainer Maintainer: Bernd Zeimetz b...@debian.org Most list addresses on alioth do not allow to post to the list without subscribing. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717498: pu: package bootchart/0.10~svn407-4.1~deb7u1
Control: tags -1 + moreinfo wheezy On Sun, 2013-07-21 at 16:51 +0200, Andreas Beckmann wrote: the change I suggested for sysvinit (#694252) and got applied in sysvinit/2.88dsf-41+deb7u1 does not fix the bootchart upgrade path lenny-squeeze-wheezy, but instead renders bootchart uninstallable in stable (and sid as well): #717495. Hmmm, I'd rather assumed that was the point, given that the Breaks matches the only version of bootchart in the archive. Is keeping bootchart around still useful? The last upload of any kind was in 2009, with the last maintainer upload in early 2008. Going back through the history of the sysvinit bug, I have to admit to being rather confused. You state that 0.10~svn407-3.3 was the last existing and therefore broken version in lenny (and on snapshots.d.o). However, the lenny packages files (as on archive.d.o) indicates that lenny contained -3; the fix for #491391 in bootchart was included in -3.1. Please clarify... :-| 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#717438: pdnsd RUINED
Control: tag -1 + moreinfo Control: severity -1 important Control: retitle -1 pdnsd: does not work anymore Hi Jidanni, jida...@jidanni.org wrote: Subject: Bug#717438: pdnsd RUINED Please refrain from using strong language or caps-lock in bug reports. Thanks. Severity: grave [...] Pdnsd is now ignored by anything on the system trying to get an IP address. Can you please explain more verbose what exactly is the issue? E.g. give examples for anything. Please also consider answering the questions reportbug asks you: * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? Downgrading the severity until it's clear if the issue is really of RC severity. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715568: RFH: Bug#715568: please help me resolve ibus (experimental 1.5.2-2) fails to start
Hi, Although we can get ibus 1.4.2 series package called 1.5.1.is.1.4.2-2/testing and 1.5.1.is.1.4.2-3/unstable get to work under GNOME 3.2, 3.4, and 3.8, ibus 1.5.2 has been not working (that is this bug is for). ibus-mozc will be patched to get icon back. But we want to have ibus 1.5 for GNOME 3.8. My uploaded packages to experimental was based on the official upstream VCS https://github.com/ibus/ibus it did not work. This Debian package source can be seen as master branch at: http://anonscm.debian.org/gitweb/?p=pkg-ime/ibus.git;a=summary I also tried to make package with the same patches as FC19 as: http://anonscm.debian.org/gitweb/?p=pkg-ime/ibus.git;a=shortlog;h=refs/heads/fc19base (Maybe checking out git://anonscm.debian.org/pkg-ime/ibus.git is easier to see.) This fc19base source did not work either. I am using chroot with experimental packages. So I am lost. Can someone help me to package functioning ibus? Funny thing is the Setting for GNOME 3.8 is funny: -- Click Keyboard -- Click to select Typing(TAB) -- Click bottom left text Input Sources -- Click active + sign on the Input Sources bar -- Crash Am I missing something. Any help is appreciated. Oh, I see Daiki said in other discussion: Maybe today's preferred way to find the setup executable is reading ibus-setup-engine.desktop, as gnome-control-center does. [1] https://git.gnome.org/browse/gnome-control-center/tree/panels/region/cc-region-panel.c#n739 Hmmm... but then why it shows nothing here. Regards, Osamu PS: SUPER-M may show icon for fcitx even if you do not start it from im-config since it uses different mechanism. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717491: [Pkg-systemd-maintainers] Bug#717491: documentation: file references all point to /usr/lib
On Sun, Jul 21, 2013 at 02:59:14PM +0200, Michael Biebl wrote: But since we already do XSL transformations, we can just use xslt to do the processing for us. There's a list of replacements called $(substitutions) in Makefile.am, which can be used to insert configure variables into the .c sources and also into .xml sources. The substitutions are then inserted using ENTITY; syntax. I think that currently the whole syntax is not being used, because Lennart removed the substitutions from systemd.unit.xml. But separate /usr is a supported configuration, so I think we should make the man pages follow configured paths. Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717497: smb4k
Hi I also tried to install the 1.0.7.1 it does not work either. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717506: htp: Inaccurate copyright information
Package: htp Version: 1.16-4 Severity: normal User: gnewsense-...@nongnu.org Usertags: gnewsense The license information in debian/copyright says that this package is released under the Artistic License. However, src/LICENSE.txt says that sprintf.* (probably should be snprintf.*) is licensed under the Frontier Artistic License 1.0. Also, homepage/ref/license.htp says that htp is released under the Clarified Artistic License. The latter is accepted as a free license by the FSF, while the 2 former are not. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages htp depends on: ii libc6 2.17-7 htp recommends no packages. htp suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717438: Confirmation
Control: tag -1 - moreinfo Control: retitle -1 pdnsd: does no more work in combination with resolvconf Hi Thomas, thanks for providing details about this bug(s) as the initial report was quite unclear about what's really the issue.. But in the future, please don't write to just -submitter@ as such mails are not sent to the maintainer of the package (just archived in the web) and hence may get lost if you are not the (only) maintainer i.e. know about that mail being sent. This especially counts if the maintainer address is set to a mailing list. Full quote below for the Debian QA mailing list. Thomas Hood wrote: I just tested pdnsd on Debian 7.1 and can confirm that at least the comination pdnsd + resolvconf does not work out of the box (even after setting START_DAEMON=yes in /etc/default/pdnsd). I found two apparent bugs. First, resolvconf -a is not called in the initscript on start. With set -x the initscript output is: + start_resolvconf + test -x /sbin/resolvconf + seq 1 60 + sleep 0.1 + pdnsd-ctl status + break + grep+ -q resolvconf pdnsd-ctl status + sed -ne /^Global:$/,/^Server.*:$/s/.*Server ip.*: \(.*\)$/\1/p + pdnsd-ctl status + server= + exit 0 Something seems to be wrong with the processing of the output from pdnsd-ctl status. The variable server has as value the null string and consequently resolvconf -a doesn't get run. If I subsequently run echo 'nameserver 127.0.0.1' | resolvconf -a lo.pdnsd on the command line then pdnsd starts working. The second bug is in pdnsd's resolvconf update hook script. After running echo 'nameserver 127.0.0.1' | resolvconf -a lo.pdnsd the output of pdnsd-ctl status is: [...] Server 0: -- label: resolvconf ip: 127.0.0.1 server assumed available: yes ip: 192.168.1.254 server assumed available: yes [...] It appears that 127.0.0.1 is now included as a forwarding address. Turning on set -x I can see that /etc/resolvconf/update.d/pdnsd passes both the real forwarding address and 127.0.0.1 as arguments to pdnsd-ctl server resolvconf up. The address 127.0.0.1 should of course be filtered out if it's an address that pdnsd itself is listening on. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717507: e17: updated watch file to track releases
Source: e17 Version: 0.17.1-2 Severity: wishlist Tags: patch Attached is a patch to update the watch file to track the releases directory instead of snapshots. Feel free to use or discard. -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash From 418a07fafbea193cdc70c434ac26062a182db432 Mon Sep 17 00:00:00 2001 From: David Bremner brem...@debian.org Date: Sun, 21 Jul 2013 12:23:19 -0300 Subject: [PATCH] debian/watch: track releases instead of snapshots. Also update the name mangling to avoid naming files .tar.gz.tar.gz --- debian/watch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/watch b/debian/watch index 47672df..48b8c1f 100644 --- a/debian/watch +++ b/debian/watch @@ -1,3 +1,3 @@ version=3 -opts=filenamemangle=s/enlightenment-(.*)/e17-$1\.tar\.gz/ \ -http://download.enlightenment.org/snapshots/LATEST/enlightenment-(.*)\.tar\.gz +opts=filenamemangle=s/enlightenment-(.*).tar.gz/e17-$1\.tar\.gz/ \ +http://download.enlightenment.org/releases/enlightenment-(.*)\.tar\.gz -- 1.8.3.2
Bug#713617: Bug #713617 presage: FTBFS: ld: ./.libs/libscintilla.a(libscintilla_la-PlatGTK.o): undefined reference to symbol 'lroundf@@GLIBC_2.2.5'
I think appending `-lm -lgmodule-2.0' to gprompter_LDADD would work this out. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717508: [krita] Does not support 16-bit float images.
Package: krita Version: 1:2.6.3-2 Severity: normal --- Please enter the report below this line. --- Several of the Texture templates provided with Krita are for 16-bit half float images, however, the Debian package does not support images with this bit depth. Using one of these templates produces an image that has been promoted to 32-bit float. Attempting to open a half float image created in another program fails with the error message Cannot create storage. --- System information. --- Architecture: amd64 Kernel: Linux 3.9-1-amd64 Debian Release: jessie/sid 990 testing www.deb-multimedia.org 990 testing security.debian.org 990 testing ftp.us.debian.org 500 stable dl.google.com 500 stable deb.opera.com --- Package information. --- Depends(Version) | Installed -+- calligra-libs (= 1:2.6.3-2) | 1:2.6.3-2 kde-runtime | 4:4.8.4-2+b1 libc6 (= 2.14) | libexiv2-12 | libfftw3-double3 | libgcc1 (= 1:4.1.1) | libgl1-mesa-glx | OR libgl1 | libglew1.7(= 1.7.0) | libglu1-mesa | OR libglu1 | libilmbase6 (= 1.0.1) | libjpeg8 (= 8c) | libkdcraw20 (= 4:4.7.1) | libkdecore5 (= 4:4.4.4-2~) | libkdeui5 (= 4:4.4.0) | libkfile4 (= 4:4.4.0) | libkio5 (= 4:4.4.0) | libknewstuff3-4 (= 4:4.4.0) | libkparts4 (= 4:4.5.85) | liblcms2-2 | libopenexr6 (= 1.6.1) | libopenjpeg2 | libpng12-0 (= 1.2.13-4) | libpoppler-qt4-3 (= 0.18) | libqt4-opengl (= 4:4.5.3) | libqt4-svg (= 4:4.5.3) | libqt4-xml (= 4:4.5.3) | libqtcore4 (= 4:4.8.0) | libqtgui4 (= 4:4.8.0) | libstdc++6(= 4.2.1) | libthreadweaver4(= 4:4.4.0) | libtiff4 ( 3.9.5-3~) | libx11-6 | krita-data(= 1:2.6.3-2) | Package's Recommends field is empty. Suggests (Version) | Installed ===-+-=== khelpcenter4| 4:4.8.4-2+b1 -- Jed Frechette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717496: Bug#717448: apache2: Invalid command 'AuthType'
On Sun, July 21, 2013 16:14, Arno Töll wrote: clone 717448 -1 reassign -1 apache2 retitle -1 apache2: Please enable authn_core by default thanks On 21.07.2013 15:59, Thijs Kinkhorst wrote: Does it make sense to allow to use mod_authn_file unconditionally in config files, but not allow authn_core unconditionally? authn_core provides directives that are common to all authentication providers. We can of course discuss this. I'm making a separate issue out of it, as its not directly related to the problem in phpmyadmin. So, let's discuss this. Why would we allow to use directives from the authn_file module without IfModules, but not those from authn_core, which provides facilities that authn_file needs? Or put differently, how does one use authn_file without specifying AuthType? Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717509: sheepdog: FTBFS on !x86 architectures
Package: sheepdog
Version: 0.6.0-1
Severity: serious
Tail of log for sheepdog on mipsel:
list_for_each_entry(f, log_formats, list) {
^
logger.c: In function 'sd_backtrace':
logger.c:732:17: error: invalid register name for 'current_sp'
register void *current_sp asm(rsp); \
^
logger.c:852:2: note: in expansion of macro 'dump_stack_frames'
dump_stack_frames();
^
make[2]: *** [logger.o] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [build-arch] Error 2
Full logs: https://buildd.debian.org/status/package.php?p=sheepdog
--
Regards,
Aron Xu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707018: Status of KDE 4.10 transition
On Sun, Jul 21, 2013 at 14:10:18 +0200, Pino Toscano wrote: That said, we are tackling few issues/regressions (mostly in the new pim stack), so could it be possible to hold the kde4libs migration with a block for now? (It should avoid all the rest to migrate too.) FWIW you could just keep a serious bug open against the sid version until you're ready for it to migrate. Cheers, Julien signature.asc Description: Digital signature
Bug#717493: pu: package sympa/6.1.11~dfsg-5.1~deb7u1
On Sun, Jul 21, 2013 at 15:27:17 +0200, Andreas Beckmann wrote: On 2013-07-21 15:13, Adam D. Barratt wrote: Whichever solution was chosen, it looks like this bug is not fixed in unstable yet? Yes, I wanted to write a sentence about this as well ... If the release team considers adding a pre-depends in stable as acceptable, I would first upload a NMU to sid (same patch, just omitting the wheezy changelog entry) and later on to wheezy. Instead of doing NMUs, maintainer uploads would be welcome of course! I think adding a pre-depends in stable would be worse than this bug. Cheers, Julien signature.asc Description: Digital signature
Bug#717498: pu: package bootchart/0.10~svn407-4.1~deb7u1
On 2013-07-21 18:11, Adam D. Barratt wrote: On Sun, 2013-07-21 at 16:51 +0200, Andreas Beckmann wrote: the change I suggested for sysvinit (#694252) and got applied in sysvinit/2.88dsf-41+deb7u1 does not fix the bootchart upgrade path lenny-squeeze-wheezy, but instead renders bootchart uninstallable in stable (and sid as well): #717495. Hmmm, I'd rather assumed that was the point, given that the Breaks matches the only version of bootchart in the archive. but it makes a package in stable uninstallable without planning to remove it from stable ... and that does not fix the upgrade issue in sysv-rc Is keeping bootchart around still useful? The last upload of any kind was in 2009, with the last maintainer upload in early 2008. If the package were removed entirely (or at least version -3.3+1 would be forced to rename the initscript), we could have sysv-rc use dpkg-maintscript-helper rm_conffile to get rid of that script ... that would even cover the case where bootchart lenny was installed, removed, the initscript remained and the system would be upgraded to squeeze and wheezy later on. Going back through the history of the sysvinit bug, I have to admit to being rather confused. You state that 0.10~svn407-3.3 was the last existing and therefore broken version in lenny (and on snapshots.d.o). However, the lenny packages files (as on archive.d.o) indicates that lenny contained -3; the fix for #491391 in bootchart was included in -3.1. Please clarify... :-| I think I have mixed up the versions -3 vs. -3.3 at some point, therefore suggesting to add the wrong Breaks against -4, after seeing that a Breaks against -3 was not sufficient to fix that upgrade path. That Breaks actually worked, but it was not sufficient to ensure -3.3 gets configured before sysv-rc, leaving the bad initscript still around. At the time I initially filed the bug I didn't have piuparts ready to easily do upgrade tests with the new --testdebs-repo option, otherwise I might have tried the Breaks approach myself (and seen that it does not work as planned). Entirely new approach to fix this much less intrusively: bootchart.preinst: on upgrade from -4 sed -i 's/rmnologin/$all/' /etc/init.d/bootchart # makes the initscript identical to the new shipped one, so no conffile prompts (unless there were other user modifications) bump version to -4.1 / -4.1~deb7u1 to satisfy initscripts Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717496: Bug#717448: apache2: Invalid command 'AuthType'
Am Sonntag, 21. Juli 2013, 18:46:49 schrieb Thijs Kinkhorst: So, let's discuss this. Why would we allow to use directives from the authn_file module without IfModules, but not those from authn_core, which provides facilities that authn_file needs? Or put differently, how does one use authn_file without specifying AuthType? AFAICS, the authn_* modules can be used by any of auth_basic, auth_session, auth_digest modules. But these three modules are not useful without authn_core, because there is no way to switch them on without AuthType. So I would suggest to add authn_core as dependency of auth_basic, auth_session, auth_digest. This would implicitly add authn_core to the list of modules that may be used without IfModule guard.
Bug#659762: lvm2: LVM commands freeze after snapshot delete fails
Same problem here. It mostly occurs if there was heavy IO load. It mostly occurs on machine with more than a few CPU's. Its so far only occurred for me on LSI RAID controllers (92xx), with dual quad core Xeon CPU's. Running 'sync before lvremove appears to make it occur less frequently. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717510: fonts-dejavu-core: too-close kerning with rr, rm, and rn
Package: fonts-dejavu-core Version: 2.33+svn2514-3 Severity: normal When I use the sans-serif font (as is used throughout XFCE), the kerning between rr, rm, and rn is too close. In fact, the rn combination looks like an m, which leads to misreading. I have attached a screenshot of this happening in Exaile with rm. If this is a bug in another package, please feel free to reassign this bug there. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 attachment: Screenshot-bad-kerning.png signature.asc Description: Digital signature
Bug#717454: lilo should register a namespace at the EFI System Partition Subdirectory Registry
Christoph Anton Mitterer wrote on 2013-07-21 01:41: AFAIU you're also upstream for LILO!? :) Yes, I am. I think it cannot harm (yes I know, right now you do not support EFI, but who knows what the future brings ... and even though the whole thing is anyway just voluntary), that lilo registers it's name at the EFI System Partition Subdirectory Registry: http://www.uefi.org/specs/esp_registry On this site I read: industry registry of vendor-specific subdirectory names in the EFI system partition. And as I see only companies which produces hardware. Until now I think there is no need to register lilo. --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715536: pygobject: FTBFS on all arches not excluded from tests
Some more information on this: if I fix debian/rules so that amd64 isn't
matched just because kfreebsd-amd64 is in the list, I can reproduce exactly
the same test failures on amd64:
export `/usr/bin/dbus-launch` \
PYTHONPATH=..:../tests:${PYTHONPATH:+:$PYTHONPATH}
LD_LIBRARY_PATH=./.libs:$LD_LIBRARY_PATH GI_TYPELIB_PATH=.:$GI_TYPELIB_PATH
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share MALLOC_PERTURB_=85 MALLOC_CHECK_=3
G_SLICE=debug-blocks TESTS_BUILDDIR=. /usr/bin/python2.7 -Wd
../../tests/runtests.py; rc=$?; \
[ $rc -ne 0 ] || [ -n $TEST_NAMES ] || { TEST_NAMES=compat_test_pygtk
PYTHONPATH=..:../tests:${PYTHONPATH:+:$PYTHONPATH}
LD_LIBRARY_PATH=./.libs:$LD_LIBRARY_PATH GI_TYPELIB_PATH=.:$GI_TYPELIB_PATH
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share MALLOC_PERTURB_=85 MALLOC_CHECK_=3
G_SLICE=debug-blocks TESTS_BUILDDIR=. /usr/bin/python2.7 -Wd
-Werror::PendingDeprecationWarning -Werror::DeprecationWarning
-Werror::RuntimeWarning ../../tests/runtests.py; rc=$?; }; \
kill $DBUS_SESSION_BUS_PID; \
exit $rc
** (runtests.py:7317): WARNING **: Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not
provided by any .service files
/bin/bash: line 4: 7317 Trace/breakpoint trap
PYTHONPATH=..:../tests:${PYTHONPATH:+:$PYTHONPATH}
LD_LIBRARY_PATH=./.libs:$LD_LIBRARY_PATH GI_TYPELIB_PATH=.:$GI_TYPELIB_PATH
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share MALLOC_PERTURB_=85 MALLOC_CHECK_=3
G_SLICE=debug-blocks TESTS_BUILDDIR=. /usr/bin/python2.7 -Wd
../../tests/runtests.py
make[4]: *** [check-local] Error 133
make[4]: Leaving directory `/tmp/pygobject/pygobject-3.8.3/build-2.7/tests'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/tmp/pygobject/pygobject-3.8.3/build-2.7/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/tmp/pygobject/pygobject-3.8.3/build-2.7'
dh_auto_test: make -j1 check returned exit code 2
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory `/tmp/pygobject/pygobject-3.8.3'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666794: subversion: diff for NMU version 1.6.17dfsg-4.1
Hi,
as the sid version of subversion doesn't look like it wants to migrate
soon, I'm going to upload the attached patch to tpu.
Cheers,
Julien
diff -u subversion-1.6.17dfsg/debian/control subversion-1.6.17dfsg/debian/control
--- subversion-1.6.17dfsg/debian/control
+++ subversion-1.6.17dfsg/debian/control
@@ -6,7 +6,7 @@
Guilherme de S. Pastore gpast...@debian.org
Build-Depends: debhelper, libneon27-gnutls-dev, zlib1g-dev,
libapr1-dev, libaprutil1-dev, libdb5.1-dev,
- libsasl2-dev, apache2-threaded-dev,
+ libsasl2-dev,
libsqlite3-dev (= 3.4), libgnome-keyring-dev, libdbus-1-dev, kdelibs5-dev,
quilt, doxygen, autotools-dev, autoconf, libtool, swig,
python-all-dev, python-support,
@@ -69,17 +69,6 @@
This package contains development (API) documentation for libsvn1, the
Subversion libraries. See the 'libsvn1' package for more information.
-Package: libapache2-svn
-Section: httpd
-Architecture: any
-Depends: apache2.2-common, ${shlibs:Depends}, ${misc:Depends}
-Suggests: db5.1-util
-Description: Subversion server modules for Apache
- This package provides the mod_dav_svn and mod_authz_svn modules for
- the Apache 2.2 web server. These modules provide Subversion's WebDAV
- server backend, to serve repositories over the http and https
- protocols. See the 'subversion' package for more information.
-
Package: python-subversion
Section: python
Architecture: any
diff -u subversion-1.6.17dfsg/debian/changelog subversion-1.6.17dfsg/debian/changelog
--- subversion-1.6.17dfsg/debian/changelog
+++ subversion-1.6.17dfsg/debian/changelog
@@ -1,3 +1,10 @@
+subversion (1.6.17dfsg-4.1) jessie; urgency=low
+
+ * Non-maintainer upload.
+ * Stop building libapache2-svn (closes: #712004, #666794).
+
+ -- Julien Cristau jcris...@debian.org Tue, 16 Jul 2013 19:51:34 +0200
+
subversion (1.6.17dfsg-4+deb7u3) wheezy-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -u subversion-1.6.17dfsg/debian/rules subversion-1.6.17dfsg/debian/rules
--- subversion-1.6.17dfsg/debian/rules
+++ subversion-1.6.17dfsg/debian/rules
@@ -29,7 +29,7 @@
endif
# We may need to disable libapache2-svn and/or libsvn-ruby*.
-ENABLE_APACHE:= yes
+ENABLE_APACHE:= no
ENABLE_RUBY := yes
DEB_BUILDDIR := BUILD
signature.asc
Description: Digital signature
Bug#717442: [Pkg-haskell-maintainers] Bug#717442: debian/rules binary fails to run build target
Hi, Am Samstag, den 20.07.2013, 18:01 -0400 schrieb Joey Hess: This probably affects many haskell packages, but the one I encountered it with is haskell-hinotify. Running debian/rules binary fails: debian/hlibrary.setup copy --builddir=dist-ghc --destdir=debian/tmp-inst-ghc Installing library in debian/tmp-inst-ghc/usr/lib/haskell-packages/ghc/lib/hinotify-0.3.2/ghc-7.4.1 hlibrary.setup: Error: Could not find module: System.INotify with any suffix: [hi] in the search path: [dist-ghc/build] strangely, repeatedly running debian/rules binary will eventually build it. The makefile target’s dependencies are seriously broken. I’ll see if I can fix this by adding more and more interdependencies between the make targets :-) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#717511: Kernel does not start up on Pegasos-2
Package: linux-image-3.2.0-4-powerpc Version: 3.2.46-1 Hello! I have just upgraded Linux installation on my Pegasos-II machine to Debian 7.1.0 Wheezy. The installer worked flawlessly, but the newly installed kernel refused to boot up. Attempt to boot up the kernel ends up in a text-mode screen filled up with garbage (randon characters and attributes). What's up ? Did you drop Pegasos support ? -- С уважением, Pavel mailto:pavel_fe...@mail.ru -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717273: printer-driver-postscript-hp: HP LaserJet 1200: User can choose between two identical PS drivers
Hi, I'm not sure… I don't get one DRV and one MFG/MDL pair; but there seems to be a small difference between the two PPDs regarding the MDL: /usr/lib/cups/driver/postscript-hp list | grep LaserJet 1200 postscript-hp:0/ppd/hplip/HP/hp-laserjet_1200n-ps.ppd en HP HP LaserJet 1200 Postscript (recommended) MFG:HP;MDL:HP LaserJet 1200; postscript-hp:1/ppd/hplip/HP/hp-laserjet_1200n-ps.ppd en HP HP LaserJet 1200 Postscript (recommended) MFG:HP;MDL:Hewlett-Packard HP LaserJet 1200; In one case MDL is HP LaserJet 1200, in the other case it is Hewlett-Packard HP LaserJet 1200… Cheers, Stefan. Am Donnerstag, den 18.07.2013, 21:40 +0200 schrieb Didier 'OdyX' Raboud: Le jeudi, 18 juillet 2013 19.21:28, Stefan Nagy a écrit : when I install printer-driver-postscript-hp I get two new drivers for my printer model HP LaserJet 1200 in CUPS (I use the web-based administration interface) to choose from: HP LaserJet 1200 Postscript (recommended) (en) HP LaserJet 1200 Postscript (recommended) (en) These two drivers don't just sound identical, as far as I can tell they are (I compared the PPD files). When I uninstall printer-driver-postscript-hp both entries are gone. I think this is https://github.com/vitorbaptista/pyppd/issues/1 What do you think? OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717512: pygobject: Build from source produces broken python3-gi not usable by python3.2
Source: pygobject
Version: 3.8.3-1
Severity: serious
If I build pygobject from source, the resulting python3-gi package has no file
/usr/lib/python3/dist-packages/gi/_gi.cpython-32mu.so, only _gi.cpython-33m.so
(and similarly for _glib and _gobject). As a result, if I try using the
resulting packages to build e.g. python-distutils-extra, I get errors like:
-- Running tests with python3.2
test_apport_hook (__main__.T)
Apport hooks ... ok
test_binary_files (__main__.T)
Binary files are ignored ... ok
test_data (__main__.T)
Auxiliary files in data/ ... ok
test_dbus (__main__.T)
D-BUS configuration and service files ... ok
test_desktop (__main__.T)
*.desktop.in files ... ok
test_empty (__main__.T)
empty source tree (just setup.py) ... ok
test_etc (__main__.T)
etc/* ... ok
test_gsettings (__main__.T)
GSettings schema files ... ok
test_help_docbook (__main__.T)
Docbook XML help ... ok
test_help_mallard (__main__.T)
Mallard XML help ... ok
test_icons (__main__.T)
data/icons/ ... ok
test_manpages (__main__.T)
manpages ... ok
test_modules (__main__.T)
Python modules ... ok
test_packages (__main__.T)
Python packages ... ok
test_po (__main__.T)
gettext *.po files ... ok
test_policykit (__main__.T)
*.policy.in PolicyKit files ... ok
test_pot_auto (__main__.T)
PO template creation with automatic POTFILES.in ... ok
test_pot_auto_explicit (__main__.T)
PO template creation with automatic POTFILES.in and explicit scripts ... ok
test_pot_manual (__main__.T)
PO template creation with manual POTFILES.in ... ok
test_requires_provides (__main__.T)
automatic requires/provides ... FAIL
test_scripts (__main__.T)
scripts ... ok
test_sdist (__main__.T)
default MANIFEST ... ok
test_standard_files (__main__.T)
Standard files (MANIFEST.in, COPYING, etc.) ... ok
test_ui (__main__.T)
GtkBuilder/Qt *.ui ... ok
test_utf8_filenames (__main__.T)
UTF-8 file names ... ok
test_vcs (__main__.T)
Ignores revision control files ... ok
==
FAIL: test_requires_provides (__main__.T)
automatic requires/provides
--
Traceback (most recent call last):
File test/auto.py, line 676, in test_requires_provides
__import__('gi.repository.GLib')
ImportError: No module named _gi
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File test/auto.py, line 678, in test_requires_provides
self.fail('You need to have pkg_resources, httplib2, and
gi.repository.GLib installed for this test suite to work')
AssertionError: You need to have pkg_resources, httplib2, and
gi.repository.GLib installed for this test suite to work
--
Ran 26 tests in 6.657s
FAILED (failures=1)
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory `/tmp/buildd/python-distutils-extra-2.37'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
(I originally saw this with a custom pbuilder setup dogfooding its own
produced debs, but I've also reproduced the missing file issue using pbuilder
with a vanilla chroot on amd64.)
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717454: lilo should register a namespace at the EFI System Partition Subdirectory Registry
On Sun, 2013-07-21 at 19:11 +0200, Joachim Wiedorn wrote: On this site I read: industry registry of vendor-specific subdirectory names in the EFI system partition. And as I see only companies which produces hardware. Na... there are folks like RedHat, Ubuntu, etc. Until now I think there is no need to register lilo. Well I guess the only benefit is, that should lilo ever support UEFI, than it probably wants to place it's files in /EFI/lilo ... and the registration would (voluntary) make clear, that this belongs to lilo, and noone else should interfere with it. Anyway... was just a suggestion. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#717495: sysv-rc: migration to dependency based boot order fails if bootchart from lenny is still installed
Followup-For: Bug #717495 Patch version 2 - much less intrusive. Andreas diff -u bootchart-0.10~svn407/debian/changelog bootchart-0.10~svn407/debian/changelog --- bootchart-0.10~svn407/debian/changelog +++ bootchart-0.10~svn407/debian/changelog @@ -1,3 +1,25 @@ +bootchart (0.10~svn407-4.1~deb7u1) wheezy; urgency=low + + * Rebuild for wheezy. + + -- Andreas Beckmann a...@debian.org Sun, 21 Jul 2013 19:17:44 +0200 + +bootchart (0.10~svn407-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix the upgrade path lenny (bootchart 0.10~svn407-3) = squeeze (bootchart +0.10~svn407-3 from lenny because bootchart was not included in squeeze) = +wheezy. The initscript from 0.10~svn407-3 prevents migration to dependency +based boot sequencing causing a sysv-rc upgrade failure. +Add bootchart.preinst to replace the problematic rmnologin use in the +ancient /etc/init.d/bootchart because it is impossible to ensure the new +bootchart is already configured (which would replace the old initscript) +at the time sysv-rc gets configured. (Closes: #717495) + * Bump Debian revision to -4.1 to restore installability after recent +initscripts having Breaks: bootchart ( 0.10~svn407-4). + + -- Andreas Beckmann a...@debian.org Sun, 21 Jul 2013 19:16:49 +0200 + bootchart (0.10~svn407-3.3) unstable; urgency=low * Non-maintainer upload. only in patch2: unchanged: --- bootchart-0.10~svn407.orig/debian/bootchart.preinst +++ bootchart-0.10~svn407/debian/bootchart.preinst @@ -0,0 +1,13 @@ +#!/bin/sh +set -e + +if [ $1 = install ] || [ $1 = upgrade ]; then + if dpkg --compare-versions $2 lt-nl 0.10~svn407-4 ; then + if [ -f /etc/init.d/bootchart ] grep -q rmnologin /etc/init.d/bootchart ; then + echo Fixing up old /etc/init.d/bootchart... + sed -i 's/rmnologin/$all/' /etc/init.d/bootchart + fi + fi +fi + +#DEBHELPER#
Bug#717498: pu: package bootchart/0.10~svn407-4.1~deb7u1 - PATCH v2
Followup-For: Bug #717498 New patch, much less intrusive, use preinst to fix up the old initscript. Andreas diff -u bootchart-0.10~svn407/debian/changelog bootchart-0.10~svn407/debian/changelog --- bootchart-0.10~svn407/debian/changelog +++ bootchart-0.10~svn407/debian/changelog @@ -1,3 +1,25 @@ +bootchart (0.10~svn407-4.1~deb7u1) wheezy; urgency=low + + * Rebuild for wheezy. + + -- Andreas Beckmann a...@debian.org Sun, 21 Jul 2013 19:17:44 +0200 + +bootchart (0.10~svn407-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix the upgrade path lenny (bootchart 0.10~svn407-3) = squeeze (bootchart +0.10~svn407-3 from lenny because bootchart was not included in squeeze) = +wheezy. The initscript from 0.10~svn407-3 prevents migration to dependency +based boot sequencing causing a sysv-rc upgrade failure. +Add bootchart.preinst to replace the problematic rmnologin use in the +ancient /etc/init.d/bootchart because it is impossible to ensure the new +bootchart is already configured (which would replace the old initscript) +at the time sysv-rc gets configured. (Closes: #717495) + * Bump Debian revision to -4.1 to restore installability after recent +initscripts having Breaks: bootchart ( 0.10~svn407-4). + + -- Andreas Beckmann a...@debian.org Sun, 21 Jul 2013 19:16:49 +0200 + bootchart (0.10~svn407-3.3) unstable; urgency=low * Non-maintainer upload. only in patch2: unchanged: --- bootchart-0.10~svn407.orig/debian/bootchart.preinst +++ bootchart-0.10~svn407/debian/bootchart.preinst @@ -0,0 +1,13 @@ +#!/bin/sh +set -e + +if [ $1 = install ] || [ $1 = upgrade ]; then + if dpkg --compare-versions $2 lt-nl 0.10~svn407-4 ; then + if [ -f /etc/init.d/bootchart ] grep -q rmnologin /etc/init.d/bootchart ; then + echo Fixing up old /etc/init.d/bootchart... + sed -i 's/rmnologin/$all/' /etc/init.d/bootchart + fi + fi +fi + +#DEBHELPER#
Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot
On Sun, 2013-07-21 at 09:54 +0100, Roger Leigh wrote:
If the bug is in amd64_edac_mod, there are only two possible commits
which could cause the problem:
1eef12825 amd64_edac: Correct DIMM sizes
94c1acf2c amd64_edac: Add Family 16h support
Which are the only commits between 3.8 and 3.9 (and none made since)
The crash is at this line:
csrow-channels[1]-dimm-nr_pages = row_dct1_pages;
with csrow-channels[1]-dimm == NULL.
This code was introduced by the first commit above. Does the patch
below fix this?
Ben.
---
[PATCH] amd64_edac: Fix crash in init_csrows() for memory controller in 64-bit
mode
init_csrows() assumes all processesors after K8 have 2 memory channels.
But these processors support a mode where only one channel is used.
It seems that csrow_enabled() may still return true for the second
channel (BIOS bug?).
Check pvt-channel_count before csrow_enabled(), and remove the family
number conditions.
Reported-by: Roger Leigh rle...@debian.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Cc: 717...@bugs.debian.org
---
drivers/edac/amd64_edac.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 8b6a034..be9c2fe 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2084,10 +2084,8 @@ static int init_csrows(struct mem_ctl_info *mci)
*/
for_each_chip_select(i, 0, pvt) {
bool row_dct0 = !!csrow_enabled(i, 0, pvt);
- bool row_dct1 = false;
-
- if (boot_cpu_data.x86 != 0xf)
- row_dct1 = !!csrow_enabled(i, 1, pvt);
+ bool row_dct1 = (pvt-channel_count == 2
+csrow_enabled(i, 1, pvt));
if (!row_dct0 !row_dct1)
continue;
@@ -2103,8 +2101,7 @@ static int init_csrows(struct mem_ctl_info *mci)
csrow-channels[0]-dimm-nr_pages = nr_pages;
}
- /* K8 has only one DCT */
- if (boot_cpu_data.x86 != 0xf row_dct1) {
+ if (row_dct1) {
int row_dct1_pages = amd64_csrow_nr_pages(pvt, 1, i);
csrow-channels[1]-dimm-nr_pages = row_dct1_pages;
--
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg
signature.asc
Description: This is a digitally signed message part
Bug#717511: Kernel does not start up on Pegasos-2
On Sun, 2013-07-21 at 21:28 +0400, Pavel Fedin wrote: Package: linux-image-3.2.0-4-powerpc Version: 3.2.46-1 Hello! I have just upgraded Linux installation on my Pegasos-II machine to Debian 7.1.0 Wheezy. The installer worked flawlessly, but the newly installed kernel refused to boot up. Attempt to boot up the kernel ends up in a text-mode screen filled up with garbage (randon characters and attributes). What's up ? Did you drop Pegasos support ? There was no decision not to support them, but no-one is actively working to support them either. This might be relevant: https://lists.debian.org/debian-powerpc/2013/07/msg8.html Michael, what are we supposed to do about radeon? I thought KMS still didn't work on PowerMac laptops. Can we make the default depend on the machine type? Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Bug#716799: More problems during startup
Here is a syslog of a start which ended up in that I could see the mouse pointer, but the desktop was not shown. Instead I saw this log. I needed to switch of the computer by pressing five seconds on the power switch. File: syslogCrashAtStartup syslogCrashAtStartup.tar.gz Description: GNU Zip compressed data
Bug#717500: mesa: Please add support for OpenCL/GalliumCompute
Hi kilobug, Gael Le Mignot (2013-07-21): Are there any plan to include support for OpenCL/GalliumCompute in the Debian build of Mesa? the odds of getting new stuff in are usually higher when a (tested) patch is attached. ;-) From a quick look, we'd need libclc, which doesn't appear to be packaged yet. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717511: Kernel does not start up on Pegasos-2
Hello, Ben. 21 июля 2013 г., 21:56:24, you wrote: This might be relevant: https://lists.debian.org/debian-powerpc/2013/07/msg8.html Unlikely. Looks like the kernel simply does not boot up. It does not say anything. Nor it switches video mode. I just enter boot command and see random flashing rectangles like on old good ZX Spectrum :) I have one suggestion about it. Looks like this kernel has rather big initrd attached. If so, technically it might occasionally overwrite firmware's code in RAM and kill itself even before the actual startup. I have another machine with a serial port here, i'll try to redirect the output to serial port and see what happens. Also i'm currently downloading i386 version in order to install on my AspireOne. Using it i will be able to cross-build PPC version of the kernel, and try to run it. This will also help me to either prove or reject my guess about initrd. However actually this guess comes from two facts: 1. Installed vmlinuz takes rather long time to load. 2. CD installer kernel takes much shorter time to load, and works fine. I don't believe there are many differences between CD version and working version. At least not in early startup code. -- Kind regards, Pavel mailto:pavel_fe...@mail.ru -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717488: Please always launch /etc/init.d/ups-monitor when halting the system
tags 717488 patch thanks Here is a patch to describe my bug report. Thanks. diff -urN a/etc/init.d/halt b/etc/init.d/halt --- a/etc/init.d/halt 2012-10-15 19:30:41.0 +0200 +++ b/etc/init.d/halt 2013-07-21 20:03:17.840931573 +0200 @@ -33,7 +33,7 @@ fi # See if we need to cut the power. - if [ $INIT_HALT = POWEROFF ] [ -x /etc/init.d/ups-monitor ] + if [ -x /etc/init.d/ups-monitor ] then /etc/init.d/ups-monitor poweroff fi
Bug#716720: billard-gl: Crashes when quitting the game
reassign 716720 freeglut3 forwarded 716720 https://sourceforge.net/p/freeglut/bugs/201/ thanks On 16.07.2013 22:12, Hans Joachim Desserud wrote: [...] I've done some testing since last time, and I think I've tracked down which change caused this issue. I have Ubuntu Saucy (the current development release) where the crash is occuring, and Ubuntu 13.04 aka Raring (the latest stable release) where it doesn't crash. Assuming whatever causing the crash had been introduced since Raring was released, I figured I'd try to install the newer packages on the old system and see what happened. First I upgraded billard-gl and -data to 1.17-13, but it closed as expected without any error messages. Ok, next stop dependencies. I pulled in the latest version of the freeglut3 package, and then I got the error messages and crash when attempting to quit billard-gl. I also verified it went away when I uninstalled the package and reinstalled the old one. In other words: with freeglut3 2.6.0-4ubuntu1 : exits cleanly with freeglut3 2.8.1-1 : error message and crash I don't have any older Debian releases to test with right now, otherwise I'd done so, though since I can reproduce crash in Sid I assume it was also introduced there with the new version of the library. I think this is most likely a bug and a regression in freeglut3, version 2.8.1. I have forwarded this bug report to freeglut's upstream bug tracker at sourceforge.net. https://sourceforge.net/p/freeglut/bugs/201/ I think the way how billard-gl calls exit is correct and there is not much what we can do here to improve the situation. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#717420: update reSIProcate in stable from 1.8.5 - 1.8.12
On Sat, 2013-07-20 at 20:26 +0200, Daniel Pocock wrote: Package: release.debian.org Severity: important Nope. Bugs in packages may have all kinds of severities, requests to update packages in stable are normal at best. (It would also be helpful if you used reportbug or otherwise normalised the usertags and titles when making such requests.) For the record, I had to dig the mail to which I'm replying out of a BTS mbox; it never reached the debian-release list, presumably due to the size of the diff. We've found that versions of reSIProcate 1.8.11-4 are not reliable on non-Intel platforms. Does anyone actually use the package on such architectures? In particular, essential code such as the MD5 implementation was not being compiled the right way for big endian systems. The code may appear to compile and run but as soon as a user tries to engage in a DIGEST authentication they will find that it fails to operate correctly. [...] A long list of other bug fixes is also included, several of them eliminate bugs that can cause a crash The cumulative effect of all bug fixes on the 1.8.x release branch brings a significant improvement in quality and convenience for end users. The _filtered_ diffstat is 189 files changed, 5819 insertions(+), 2235 deletions(-) and adds two new packages. We'd need a lot of convincing that the latter is worth doing, rather than just proving updates via backports (fwiw, I'm only aware of one occasion where a new package was introduced to a release once it was stable, and that was openssh-blacklist via security.d.o, which is a somewhat different situation). 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#677246: patch for goobox / musicbrainz5
Version: 3.1.1-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717513: goobox: Please drop gnome-doc-utils from Build-Depends
Source: goobox Version: 3.1.1-1 Severity: minor User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy Please drop gnome-doc-utils from Build-Depends. It's been replaced by yelp-tools/itstool. Thanks, Jeremy - -- System Information: Debian Release: wheezy/sid APT prefers saucy-updates APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'raring'), (100, 'saucy-backports') -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717435: sympa: fails to install if ca-certificates trigger has never been run
Hi Emmanuel, On 2013-07-21 20:09, Emmanuel Bouthenot wrote: This bug is already fixed in git repository[1]. I'm currently working on packaging Sympa 6.1.17, hence it will be fixed with the next upload. [1] http://anonscm.debian.org/gitweb/?p=collab-maint/sympa.git;a=commitdiff;h=7ab6b9b7de9ec7cd27ebf2d8046f7ea227b583a6 Nice. Much better than my suggestion of using pre-depends. Do you think you can cherry-pick this patch for wheezy-pu? Please reuse #717493 for the pu request. That might require uploading just this fix to sid first ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717511: Kernel does not start up on Pegasos-2
On Sun, 2013-07-21 at 22:07 +0400, Pavel Fedin wrote: Hello, Ben. 21 июля 2013 г., 21:56:24, you wrote: This might be relevant: https://lists.debian.org/debian-powerpc/2013/07/msg8.html Unlikely. Looks like the kernel simply does not boot up. It does not say anything. Nor it switches video mode. I just enter boot command and see random flashing rectangles like on old good ZX Spectrum :) I have one suggestion about it. Looks like this kernel has rather big initrd attached. If so, technically it might occasionally overwrite firmware's code in RAM and kill itself even before the actual startup. If you run the installer in expert mode you can choose to create a 'targeted' initramfs which should be much smaller. I have another machine with a serial port here, i'll try to redirect the output to serial port and see what happens. Also i'm currently downloading i386 version in order to install on my AspireOne. Using it i will be able to cross-build PPC version of the kernel, and try to run it. This will also help me to either prove or reject my guess about initrd. However actually this guess comes from two facts: 1. Installed vmlinuz takes rather long time to load. 2. CD installer kernel takes much shorter time to load, and works fine. I would expect the installer initramfs to be bigger than a normal generic initramfs, but maybe I'm wrong. Ben. I don't believe there are many differences between CD version and working version. At least not in early startup code. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Bug#717435: sympa: fails to install if ca-certificates trigger has never been run
forcemerge 706965 717435
thanks
Hi Andreas,
On Sat, Jul 20, 2013 at 11:05:01PM +0200, Andreas Beckmann wrote:
[...]
during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.
This bug is already fixed in git repository[1]. I'm currently working on
packaging Sympa 6.1.17, hence it will be fixed with the next upload.
Some work remains on the apache 2.4 transition (see #669803) before
uploading this new release in unstable.
[1]
http://anonscm.debian.org/gitweb/?p=collab-maint/sympa.git;a=commitdiff;h=7ab6b9b7de9ec7cd27ebf2d8046f7ea227b583a6
Regards,
M.
--
Emmanuel Bouthenot
mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
xmpp: kol...@im.openics.org irc: kolter@{freenode,oftc}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717513: goobox: Please drop gnome-doc-utils from Build-Depends
You'll need to explicitly add libxml2-utils though. Thanks, Jeremy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717514: nemiver: Please don't build-depend on gnome-doc-utils
Source: nemiver Version: 0.9.4-1 Severity: minor User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy Please drop gnome-doc-utils from Build-Depends and explicitly build-depend on libxml2-utils instead. gnome-doc-utils has been replaced by yelp-tools/itstool. Thanks, Jeremy - -- System Information: Debian Release: wheezy/sid APT prefers saucy-updates APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'raring'), (100, 'saucy-backports') -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717435: sympa: fails to install if ca-certificates trigger has never been run
On Sun, Jul 21, 2013 at 04:03:23PM +0200, Andreas Beckmann wrote:
[...]
While this can be fixed with a Pre-Depends, I'm not sure whether this is
the correct approach. There might be more packages affected by similar
bugs in the future.
I'd like to avoid as much as possible the usage of Pre-Depends if it is
possible to do otherwise.
I've already committed a 5 lines patch[1] which fix this issue. I'm not
very proud of this patch but it just works and I prefer to do it this
way than adding a Pre-Depends.
[...]
PS: there is pu request #717493 for adding the pre-depends to sympa
Backporting my patch for sympa in wheezy should be straight forward.
On side note, I wonder if this bug really needs to be fixed in wheezy by
a pu upload.
[1]
http://anonscm.debian.org/gitweb/?p=collab-maint/sympa.git;a=commitdiff;h=7ab6b9b7de9ec7cd27ebf2d8046f7ea227b583a6
Regards,
M.
--
Emmanuel Bouthenot
mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
xmpp: kol...@im.openics.org irc: kolter@{freenode,oftc}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717511: Kernel does not start up on Pegasos-2
Hi, Just for the record, I've installed Wheezy successfully on two Pegasos IIs, one is a rev 2B1 board, which was installed from scratch, and worked without major glitches, apart from the fact that the installer required an installation to MBR partitioned disks, because with RDB disks it said Fatal error: Out of memory, when it tried to create the main partition on an 80GB ATA disk. :) The other one is a rev 2B3 board, it was upgraded from Squeeze, required some manual fiddling, but worked in the end. Stock 3.2 kernel and initramfs in both cases, binary from the ISO (or from the net or what it builds by default anyway). Both Pegs have 1GB RAM and Radeon 9200. Everything worked, except the GBit eth controller. On Sun, 21 Jul 2013, Ben Hutchings wrote: Unlikely. Looks like the kernel simply does not boot up. It does not say anything. Nor it switches video mode. I just enter boot command and see random flashing rectangles like on old good ZX Spectrum :) I have one suggestion about it. Looks like this kernel has rather big initrd attached. If so, technically it might occasionally overwrite firmware's code in RAM and kill itself even before the actual startup. If you run the installer in expert mode you can choose to create a 'targeted' initramfs which should be much smaller. I've seen this. I can't recall if the problem was I've booted vmlinux instead of vmlinuz accidentally, or got the video= arguments wrong. (Ps: sorry I've not replied to the answer to my previous question, I had no chance to try the suggestion on the actual machine.) Regards, -- Karoly Balogh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717515: webalizer: man page states STDIN is default logfile, in reality it is /var/log/apache/access.log.1
Package: webalizer Version: 2.01.10-32.7 Severity: minor Contrary to the man page statement If no log file was given, STDIN is used for input. If the log filename '-' is specified, STDIN will be forced, webalizer defaults to /var/log/apache/access.log.1 (probably derived from debconf setting below) This is confusing for users who run webalizer on their logs specifying their own config with no mention of /var/log/apache/access.log.1 (ex: mergelog ~/var/log/apache2/*.log.1 | webalizer -c ~/etc/webalizer.conf), when they receive errors about /var/log/apache not existing. Forcing STDIN via - allows the above command to work as expected. -- System Information: Debian Release: 6.0.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages webalizer depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries [ ii libgd2-xpm2.0.36~rc1~dfsg-5 GD Graphics Library version 2 ii libgeoip1 1.4.7~beta6+dfsg-1 A non-DNS IP-to-country resolver l ii libpng12-01.2.44-1+squeeze4 PNG library - runtime ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime webalizer recommends no packages. Versions of packages webalizer suggests: ii apache2-mpm-prefork [ 2.2.16-6+squeeze11 Apache HTTP Server - traditional n ii nginx [httpd] 0.7.67-3+squeeze3 small, but very powerful and effic -- debconf information: webalizer/logfile: /var/log/apache/access.log.1 webalizer/doc_title: Usage statistics for webalizer/upgrading: webalizer/dnscache: false webalizer/directory: /var/www/webalizer webalizer/upgrade2011030: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522741: ieee-data: not actually including oui.txt
Hi. I'd like to ask if there was any progress on this. I'd like to package ipv6-toolkit but the licensing of oui.txt is unclear (to say the best). there's progress in the sense that licensing terms for ieee data are not still clear Some say that it is not copyrightable for being a list of facts [1], others say that databases are copyrightable in some places [2], and some claim to have written to the IEEE and received a negative permission on redistribution of the file [3]. [1] http://lists.debian.org/debian-legal/2006/02/msg00175.html [2] http://lists.debian.org/debian-legal/2006/02/msg00208.html [3] https://blog.flameeyes.eu/2012/04/who-said-that-ids-wouldn-t-have-license-issues What if this package downloaded the data live from the Internet like the flashplugin-nonfree does? -- Octavio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697627: RFS: gogglesmm/0.12.7-1
Hi Sebastian, thank you for your review. Those libraries are linked due to the pkg-config file generated during the build of gogglesmm. libfox-1.6-dev's fox.pc only says to link against liblFOX-1.6. So using the pkg-config file provided by libfox-1.6-dev gets rid of all the unnecessary dependencies. Removing the unecessary dependencies means that gogglesmm doesn't need to be taken care of if those libraries should ever be transitioned. At least for one of the libraries a transition is planned (libpng12 - libpng15). So that was my mistake. I assumed that fox-config and pkg-config do the same. Some time ago the package libfox-1.6 did not contain a pkg-config script. Hence it was necessary to generate one. But fortunately things have changed so I removed the generation of the pkg-config file. The corrected version can be obtained via dget -x http://mentors.debian.net/debian/pool/main/g/gogglesmm/gogglesmm_0.12.7-1.dsc Regards Hendrik signature.asc Description: This is a digitally signed message part
Bug#681088: watchquagga is a beast...
Hi, I second that bug and problem. Trying virtually anything I found out that strings like these: -s '/usr/sbin/service_quagga_start_%s' -k '/usr/sbin/service_quagga_stop_%s' do work flawless for watchquagga_options. Also this line gets fully handed over to the watchquagga script: watchquagga_options= -dz -R '/usr/sbin/service quagga restart' and results in a good looking processlist: ps xa | grep -i quagga 6983 ?Ss 0:00 /usr/lib/quagga/zebra --daemon -A 127.0.0.1 6987 ?Ss 0:00 /usr/lib/quagga/ospfd --daemon -A 127.0.0.1 6991 ?Ss 0:00 /usr/lib/quagga/ospf6d --daemon -A ::1 6995 ?Ss 0:00 /usr/lib/quagga/watchquagga -dz -R '/usr/sbin/service quagga restart' zebra ospfd ospf6d But this doesn't work anyway (tested by kililng ospf6d, the down-state gets noted, but the restart fails). Then killed watchquagga and started is as root from a shell: /usr/lib/quagga/watchquagga -dz -R '/usr/sbin/service quagga restart' zebra ospfd ospf6d It promptly detects the not-running ospf6d and does a clean restart. After everything is back to normal (watchquagga has been started by the full restart by the init-script) I kill ospf6d again and this is it. State down gets detected, but the background restart command fails with error-code 2. I'd appreciate any hints from here on, we're now at the following solution: /etc/quagga/debian.conf - watchquagga_enable=no And we start it separately in a script that does call itself if there is action to be done: /usr/lib/quagga/watchquagga -dz -R '/etc/init.d/quagga restart /etc/rc.watchquagga' ospf6d ospfd zebra I'm feeling dumb, but that seems to be the only way to get in running on debian using the package quagga 0.99.21-4+wheezy1 best regards, Harald Kapper / kapper.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717516: linux-image-3.2.0-4-amd64: Segmentation fault in ksoftirqd
Package: src:linux Version: 3.2.46-1 Severity: normal Dear Maintainer, I saw the segmentation fault in my logs today. Don't know what caused it or how to reproduce it. -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.46-1 ** Command line: root=/dev/xvda2 ro root=/dev/xvda2 ro ** Tainted: W (512) * Taint on warning. ** Kernel log: [0.029976] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) [0.030068] NET: Registered protocol family 1 [0.030076] PCI: CLS 0 bytes, default 64 [0.030104] Unpacking initramfs... [0.051542] Freeing initrd memory: 29644k freed [0.054922] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [0.054928] Placing 64MB software IO TLB between 8800f740 - 8800fb40 [0.054931] software IO TLB at phys 0xf740 - 0xfb40 [0.054996] platform rtc_cmos: registered platform RTC device (no PNP device found) [0.055233] audit: initializing netlink socket (disabled) [0.055242] type=2000 audit(1374363613.038:1): initialized [0.064686] HugeTLB registered 2 MB page size, pre-allocated 0 pages [0.064873] VFS: Disk quotas dquot_6.5.2 [0.064892] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [0.064933] msgmni has been set to 7896 [0.065040] alg: No test for stdrng (krng) [0.065062] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [0.197138] io scheduler noop registered [0.197144] io scheduler deadline registered [0.197185] io scheduler cfq registered (default) [0.197240] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [0.197254] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [0.197257] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [0.197549] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.380183] Linux agpgart interface v0.103 [0.380235] i8042: PNP: No PS/2 controller found. Probing ports directly. [1.381493] i8042: No controller found [1.381609] mousedev: PS/2 mouse device common for all mice [1.421427] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 [1.421475] rtc_cmos: probe of rtc_cmos failed with error -38 [1.421607] TCP cubic registered [1.421672] NET: Registered protocol family 10 [1.421925] Mobile IPv6 [1.421930] NET: Registered protocol family 17 [1.421935] Registering the dns_resolver key type [1.422060] PM: Hibernation image not present or could not be loaded. [1.422069] registered taskstats version 1 [1.422089] XENBUS: Device with no driver: device/console/0 [1.422094] XENBUS: Device with no driver: device/vbd/51714 [1.422097] XENBUS: Device with no driver: device/vbd/51713 [1.422101] XENBUS: Device with no driver: device/vif/0 [1.422113] /build/linux-s5x2oE/linux-3.2.46/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [1.422137] Initializing network drop monitor service [1.422428] Freeing unused kernel memory: 576k freed [1.422515] Write protecting the kernel read-only data: 6144k [1.424677] Freeing unused kernel memory: 652k freed [1.424979] Freeing unused kernel memory: 692k freed [1.441065] udevd[60]: starting version 175 [1.452731] Initialising Xen virtual ethernet driver. [1.464123] blkfront: xvda2: flush diskcache: enabled [1.465944] blkfront: xvda1: flush diskcache: enabled [1.466389] Setting capacity to 2097152 [1.466396] xvda1: detected capacity change from 0 to 1073741824 [1.967339] EXT4-fs (xvda2): INFO: recovery required on readonly filesystem [1.967349] EXT4-fs (xvda2): write access will be enabled during recovery [2.264914] EXT4-fs (xvda2): orphan cleanup on readonly fs [2.264925] EXT4-fs (xvda2): ext4_orphan_cleanup: deleting unreferenced inode 4849673 [2.264943] EXT4-fs (xvda2): ext4_orphan_cleanup: deleting unreferenced inode 4849671 [2.264946] EXT4-fs (xvda2): ext4_orphan_cleanup: deleting unreferenced inode 4849670 [2.264950] EXT4-fs (xvda2): ext4_orphan_cleanup: deleting unreferenced inode 4849669 [2.264957] EXT4-fs (xvda2): ext4_orphan_cleanup: deleting unreferenced inode 4849668 [2.264961] EXT4-fs (xvda2): ext4_orphan_cleanup: deleting unreferenced inode 4849667 [2.264980] EXT4-fs (xvda2): 6 orphan inodes deleted [2.264983] EXT4-fs (xvda2): recovery complete [2.505149] EXT4-fs (xvda2): mounted filesystem with ordered data mode. Opts: (null) [3.813915] udevd[254]: starting version 175 [3.955272] input: PC Speaker as /devices/platform/pcspkr/input/input0 [3.970151] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [4.019515] Error: Driver 'pcspkr' is already registered, aborting... [4.356384] Adding 1048572k swap on /dev/xvda1. Priority:-1 extents:1 across:1048572k SS [4.376210] EXT4-fs (xvda2): re-mounted. Opts: (null) [4.497794] EXT4-fs
Bug#582109: debian-policy: document triggers where appropriate
On Sat, 20 Jul 2013, Charles Plessy wrote: Can you explain what the bug is and what the correction will be ? Because I The bug is that triggers are run while the dependencies of the triggered package are not satisfied. The fix is not to do that and wait until those dependencies are satisfied (but guillem mentionned that it also needs some cycle breaking code). The misleading point is just like packages in installed. In my understanding, when a package is upgraded, the packages that depend on it stay in the Installed state while the new version of the upgraded package is unpacked and configured. Not just the triggers, but also any other command not related to the dpkg or apt session that would happen to run at that time can fail if they strictly require a function that is not available between unpack and configure. That's true but it's not really comparable. postinst triggered ought to work like postinst configure and there you have the guaranty that the dependencies are configured. I do not see any other solution than applying the same restrictions on postinst triggered as for postinst configure. (PS: after reading the thread again, I just noticed that this also what you wrote in #671711#68). I did not write that. On the contrary, re-read: “The problematic fix is to ensure the same requirements for postinst triggered as for postinst configure. But we could enforce some requirements that would probably solve the issues we saw without introducing cycles.” There are no restrictions for postinst configure (you can rely on dependencies — except if you have a dependency cycle) and there should be no restrictions for postinst triggered. But right now, dpkg doesn't ensure anything. And instead of nothing checked by dpkg, I suggested to ensure some requirements nevertheless but which are less demanding than those used by postinst configure. (PPS: By the way, apart from Manoj's excellent diagrams at http://people.debian.org/~srivasta/MaintainerScripts.html#sec-3.4.3, is there an extensive documentation on how package upgrades are handled by APT and Dpkg ?) I know https://wiki.debian.org/MaintainerScripts too but that's all. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot
On Sun, Jul 21, 2013 at 06:41:52PM +0100, Ben Hutchings wrote:
On Sun, 2013-07-21 at 09:54 +0100, Roger Leigh wrote:
If the bug is in amd64_edac_mod, there are only two possible commits
which could cause the problem:
1eef12825 amd64_edac: Correct DIMM sizes
94c1acf2c amd64_edac: Add Family 16h support
Which are the only commits between 3.8 and 3.9 (and none made since)
The crash is at this line:
csrow-channels[1]-dimm-nr_pages = row_dct1_pages;
Hmm.
If I can read it correctly above, 3.8 works for you Roger, correct?
If so, can you please enable CONFIG_EDAC_DEBUG, rebuild 3.8 and boot
your machine with it and send me the full dmesg of the boot?
with csrow-channels[1]-dimm == NULL.
This code was introduced by the first commit above. Does the patch
below fix this?
Ben.
---
[PATCH] amd64_edac: Fix crash in init_csrows() for memory controller in
64-bit mode
init_csrows() assumes all processesors after K8 have 2 memory channels.
But these processors support a mode where only one channel is used.
It seems that csrow_enabled() may still return true for the second
channel (BIOS bug?).
Ok, I think I know what the problem is:
[5.815246] EDAC amd64: DRAM ECC enabled.
[5.816328] EDAC amd64: F15h detected (node 0).
[5.817397] EDAC amd64: MC: 0: 0MB 1: 0MB
[5.818379] EDAC amd64: MC: 2: 0MB 3: 0MB
[5.819332] EDAC amd64: MC: 4: 0MB 5: 0MB
[5.820250] EDAC amd64: MC: 6: 0MB 7: 0MB
[5.821176] EDAC amd64: MC: 0: 4096MB 1: 4096MB
[5.822131] EDAC amd64: MC: 2: 4096MB 3: 4096MB
[5.823048] EDAC amd64: MC: 4: 0MB 5: 0MB
[5.823927] EDAC amd64: MC: 6: 0MB 7: 0MB
[5.824818] EDAC amd64: using x4 syndromes.
[5.825680] EDAC amd64: MCT channel count: 1
Roger's DIMMs are only on the one channel and the second one is empty.
Btw, Roger, you might want to move one of the DIMMs to a another DIMM
socket on the board so that you can use both channels for performance
reasons.
I'm saying one of the DIMMs because I'm assuming those 4G above are
dual-ranked DIMMs and you have two 8G DIMMs on the board.
If they're single-ranked i.e. 4G each, then you shouldn't have any
choice because your board has only 4 DIMM slots anyway, AFAICT from the
manual:
http://www.asus.com/Motherboards/SABERTOOTH_990FX_R20/#support_Download_10
Which would be buggy because you're still using only one DCT.
Btw if you have two DIMMs on there, please put them according to the
recommended memory configurations, i.e. one in A2 and the other in B2.
Here's my layout, for example:
[5.890887] EDAC MC: DCT0 chip selects:
[5.890888] EDAC amd64: MC: 0: 2048MB 1: 2048MB
[5.890889] EDAC amd64: MC: 2: 2048MB 3: 2048MB
[5.890890] EDAC amd64: MC: 4: 0MB 5: 0MB
[5.890891] EDAC amd64: MC: 6: 0MB 7: 0MB
[5.890893] EDAC MC: DCT1 chip selects:
[5.890894] EDAC amd64: MC: 0: 2048MB 1: 2048MB
[5.890894] EDAC amd64: MC: 2: 2048MB 3: 2048MB
[5.890895] EDAC amd64: MC: 4: 0MB 5: 0MB
[5.890896] EDAC amd64: MC: 6: 0MB 7: 0MB
[5.890897] EDAC amd64: using x4 syndromes.
[5.890901] EDAC amd64: MCT channel count: 2
And I have 4 DIMM slots occupied.
Check pvt-channel_count before csrow_enabled(), and remove the family
number conditions.
Reported-by: Roger Leigh rle...@debian.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Cc: 717...@bugs.debian.org
---
drivers/edac/amd64_edac.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 8b6a034..be9c2fe 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2084,10 +2084,8 @@ static int init_csrows(struct mem_ctl_info *mci)
*/
for_each_chip_select(i, 0, pvt) {
bool row_dct0 = !!csrow_enabled(i, 0, pvt);
- bool row_dct1 = false;
-
- if (boot_cpu_data.x86 != 0xf)
- row_dct1 = !!csrow_enabled(i, 1, pvt);
Ok, this shouldn't be set if DCT1 doesn't have enabled csrows. So yes,
Roger, that debugging output would be of great help.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717342: Nocheck when cross build
Hi Eleanor, Eleanor Chen wrote: When cross build xz-utils, nocheck should be enabled, or it will fail when running tests. I fear I'm missing some context. Is there any package with a testsuite that should be run when cross-building? Why doesn't the cross-build procedure enable nocheck automatically? I don't like the idea of changing all cross-buildable packages to special-case crossbuilding by overriding the nocheck flag in debian/rules. Besides, that would remove the benefit of tests when cross-building to another native arch (e.g., amd64-i386). I can imagine some setup for cross-testing being invented in the future (e.g., involving sending native binaries and their dependencies to another machine and testing them there), but I suspect this would be something different than the normal build-time tests that are disabled by the nocheck setting. For example, autopkgtest might be the way to go for that. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
