Bug#736782: roundcube: diff for NMU version 0.9.5+dfsg1-4.1
❦ 15 octobre 2014 13:10 +1000, Russell Stuart russell-deb...@stuart.id.au : I've prepared an NMU for roundcube (versioned as 0.9.5+dfsg1-4.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Feel free to upload it to a non-delayed queue. I am currently too swamped to do anything else. -- Don't stop at one bug. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Bug#763847: autopkgtest: package type detection heuristics override explicit Testsuite field
Control: reassign -1 autopkgtest 3.5 Hey Antonio, Antonio Terceiro [2014-10-14 15:58 -0300]: But since autodep8 already does that, the issue itself will only be fixed when an autopkgtest that uses autodep8 hits the archive. :-) Ah, great. Reassigning back then, and will close this bug with the move to autodep8 changelog. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#765320: debian-security-support: dpkg: cycle found while processing triggers
Jakub Wilk wrote... debian-security-support causes trigger loops, breaking other packages' upgrades. Ouch. Does the fix for #762031 help? Christoph signature.asc Description: Digital signature
Bug#765435: libvpx: Out-of-bounds write with WebM video [CVE-2014-1578]
Source: libvpx Version: 1.3.0-2.1 Severity: grave Tags: security patch Justification: user security hole Hi, an out of bound write vulnerability in libvpx has been fixed in a recent Mozilla advisory [1], and a patch is also provided [2]. Can you prepare an update for unstable and push it asap? Also, I'm unsure if the vulnerability affects stable, so it might be worth checking there too (and coordinate with us for an upload). If you fix the vulnerability, please add the CVE reference (CVE-2014-1578) to the changelog. [1]: https://www.mozilla.org/security/announce/2014/mfsa2014-77.html [2]: https://hg.mozilla.org/releases/mozilla-esr31/rev/6023f0b4f8ba Thanks in advance, -- Yves-Alexis Perez - Debian security team -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765436: GNOME-Shell wallpapers and suspend-to-ram/hibernation
Package: gnome-shell Version: 3.14.0 I'm on Debian/sid with all packages up-to-date. Since the switch to gnome-shell 3.14.0, when the computer is coming out of suspend-to-ram/hibernation the wallpapers are not properly refreshed. Both wallpapers (standard and the one used on lock screen) are affected they are displayed with random pixels as if using some non initialized memory. After some time (1 minute or 2 minutes) the standard wallpaper is back to normal. But the wallpaper on the lock screen seems to never be displayed properly. I have this issue on 2 computers and on Google+ some guys have the same issue. Thanks, -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762571: Patch for libvorbis (Was: Debdiff)
[Martin Steghöfer] I've tested the vorbis functionality of some programs that use libvorbis. So far everything looks fine to me. But as I said, I don't have a great testing environment for libvorbis set-up, so those were just very basic file reading and writing tests using different GUI multimedia programs based on libvorbis. Right. Luckily the library have its own test suite, so at least those tests work. They sure do, considering that all of their packages currently in unstable are NMUs (except one, which is still the same version as years ago, untouched). I don't mind helping out, but in this case I guess joining the team means being the team, which would be more effort than I am able to commit to, I'm sorry. I understand you all too well, as I am not part of the team and do not have time to become it either. I notice from URL: https://alioth.debian.org/projects/pkg-xiph/ that only a handful are listed as part of the team. But I know from other projects that if one person get started, others tend to follow, so helping out might not mean being the team. It might mean restarting the team too. :) -- 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#765434: man-db install-triggers broken
Control: severity -1 serious On Wed, Oct 15, 2014 at 08:24:13AM +0300, Antti Järvinen wrote: upgrade to man-db fails to install. According to error message it may be that the problem itself is in some other package or in dependencies between the packages. Output from apt-get dist-upgrade goes like this: Failure to install or upgrade is a serious issue. Processing triggers for man-db (2.7.0.2-2) ... dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: libgdk-pixbuf2.0-0:i386 - doc-base packages' pending triggers which are or may be unresolvable: doc-base: /usr/share/doc-base menu: /usr/share/menu libgdk-pixbuf2.0-0:i386: /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders hal: /usr/share/hal/fdi dpkg: error processing package doc-base (--unpack): triggers looping, abandoned .. and man-db is left unconfigured. I have doc-base 0.10.6, menu 2.1.47, libgdk-pixbuf2 2.31.1-2 and hal 0.5.14-8. I guess that the bug is not in man-db though, because the fix for similar packages was to switch from interest to interest-noawait, but man-db already uses the latter for a while. Thus I am inviting Guillem Jover to look at the issue and reassign the bug. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761503: arb: [INTL:pt] Portuguese translation for debconf messages
Quoting Américo Monteiro (a_monte...@gmx.com): Package: arb version: 6.0.2-2 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for arb's debconf messages. Translator: Américo Monteiro a_monte...@gmx.com Feel free to use it. This is the new version with templates reviewed by the i18n team, so use this new file instead of the previous one. Please never ever translate variable names in debconf templates (PORT, USER and NUMBER) Fixed file attached. pt.po Description: application/gettext signature.asc Description: Digital signature
Bug#765437: geeqie: Fullscreen is not managed by window manager
Package: geeqie Version: 1:1.2-3 Severity: normal Dear Maintainer, when Geeqie is in fullscreen mode and I switch workspace, Geeqie is still in front of me, but it has no focus. Some time ago, the fullscreen mode was window just like any other, only displayed over whole screen. I guess current behavior is because Geeqie does not let windowmanager to handle the window, so WM cannot hide it when moving to another desktop. Same situation is with switching to anoter window. Alt+tab used to show other window over Geeqie in fullscreen. My windowmanager: Icewm 1.3.8 Thank you! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (700, 'unstable'), (600, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16-3-686-pae (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages geeqie depends on: ii geeqie-common1:1.2-3 ii libatk1.0-0 2.14.0-1 ii libc62.19-11 ii libcairo21.12.16-5 ii libexiv2-13 0.24-4 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-2 ii libgcc1 1:4.9.1-16 ii libgdk-pixbuf2.0-0 2.31.1-2 ii libglib2.0-0 2.42.0-2 ii libgtk2.0-0 2.24.25-1 ii libjpeg621:1.3.1-6 ii liblcms2-2 2.6-3+b1 ii liblircclient0 0.9.0~pre1-1.1 ii liblua5.1-0 5.1.5-7 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-0 1.36.8-2 ii libpangoft2-1.0-01.36.8-2 ii libstdc++6 4.9.1-16 ii libtiff5 4.0.3-10+b1 Versions of packages geeqie recommends: ii cups-bsd [lpr] 1.7.5-4 ii exiftran 2.09-1 ii exiv20.24-4 ii imagemagick 8:6.8.9.6-4 ii librsvg2-common 2.40.4-1 ii ufraw-batch 0.19.2-3.1 ii zenity 3.14.0-1 Versions of packages geeqie suggests: pn geeqie-dbg none ii gimp 2.8.14-1 ii libjpeg-turbo-progs [libjpeg-progs] 1:1.3.1-6 ii ufraw0.19.2-3.1 pn xpaint 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#765434: Additional information
And it seems like running apt-get -f install after the failed upgrade fixes the problem. Might be something to do with order of configuration between the packages? -- Antti -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749991: both installer betas suffer from this
On Tue, 2014-10-14 at 17:22 +0200, Hermann Lauer wrote: On Thu, Oct 02, 2014 at 02:24:45PM +0200, Hermann Lauer wrote: both Jessie beta 1 amd64 images (20140316 and 20140802) suffer from this. fixed with Jessie beta 2 netboot here. And serial console works with: append initrd=debian-installer/amd64/initrd.gz auto priority=critical url=http://...preseed locale=en_US hostname=x domain=x console=ttyS0,19200n8 -- console=ttyS0,19200n8 The issues with serial consoles are probably/possibly: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 (hence the need to double up the console= bit) Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765438: buildd_amd64-ba...@buildd.debian.org bounces
Package: buildd.debian.org Severity: important Hi, buildd_amd64-ba...@buildd.debian.org bounces lots of mails from dak. Please take a look at it. Ansgar Mail Delivery System mailer-dae...@mailly.debian.org writes: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: buildd_amd64-ba...@buildd.debian.org SMTP error from remote mail server after RCPT TO:buildd_amd64-ba...@buildd.debian.org: host wuiet.debian.org [2001:41c8:1000:21::21:18]: 550 Unrouteable address -- This is a copy of the message, including all the headers. -- Return-path: envel...@ftp-master.debian.org Received: from franck.debian.org ([138.16.160.12]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=franck.debian.org,EMAIL=hostmas...@franck.debian.org (verified) by mailly.debian.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from envel...@ftp-master.debian.org) id 1XeCYj-AJ-Iz; Wed, 15 Oct 2014 00:35:21 + Received: from dak by franck.debian.org with local (Exim 4.80) (envelope-from envel...@ftp-master.debian.org) id 1XeCYi-0005g9-2a; Wed, 15 Oct 2014 00:35:20 + From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: amd64 / i386 Build Daemon (babin) buildd-ba...@buildd.debian.org, buildd_amd64-ba...@buildd.debian.org X-DAK: dak process-upload X-Debian: DAK X-Debian-Package: spamprobe (1.4d-12.1) Precedence: bulk Auto-Submitted: auto-generated MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: spamprobe_1.4d-12.1+b1_i386.changes ACCEPTED into unstable Message-Id: e1xecyi-0005g9...@franck.debian.org Date: Wed, 15 Oct 2014 00:35:20 + Mapping sid to unstable. Accepted: Format: 1.8 Date: Tue, 11 Feb 2014 15:50:03 +0100 Source: spamprobe (1.4d-12.1) Binary: spamprobe Binary-Only: yes Architecture: i386 Version: 1.4d-12.1+b1 Distribution: sid Urgency: low Maintainer: amd64 / i386 Build Daemon (babin) buildd-ba...@buildd.debian.org Changed-By: amd64 / i386 Build Daemon (babin) buildd-ba...@buildd.debian.org Description: spamprobe - Bayesian spam filter Changes: spamprobe (1.4d-12.1+b1) sid; urgency=low, binary-only=yes . * Binary-only non-maintainer upload for i386; no source changes. * Rebuild against libjpeg62-turbo Checksums-Sha1: c3861c2e3cb9b9bf8ba42a4632d2454fd902e69f 187086 spamprobe_1.4d-12.1+b1_i386.deb Checksums-Sha256: c8aaa151c2e7500502173004d9fe622dca83e4ee01289bb12d1b333bb3a96796 187086 spamprobe_1.4d-12.1+b1_i386.deb Files: ed3ba94ae003d6296a8084ebd5aa73b8 187086 mail optional spamprobe_1.4d-12.1+b1_i386.deb Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743774: NMU of gaupol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'd like to inform you that I've just uploaded Helge's NMU to DELAYED/2. Regards, Tobias -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJUPh7JAAoJEIP9HEaC0TjgXJQP/1kHylaH+130BQTV15ch4bSt 7rWLD1XxgPatv4Xp5V5cR4gsKCxVT55y1aCDuCC6Jo7KWwO7YOuhv9pVf4QefeqO YiG46y7QxC0CWKhnStnz1gOfsgjxWJZwAlRX2qr1Vsq+IXQCmD12TYaORuk1hQbb yuh9TDBKaK+dfPH8xq4XvcVCRq2IJw7vKY8UtJXbyyy4YpXhOfcVh1My7+cjOIHX uRjLjf77lm4fRkGlgueQf3RDgUhxNeJDUO1GUuItri68uVOdnkkkVe+uqUgbRYws v6cIw4oVEjkTh2negu+jHvXc7QVX92B0DEmotrTYbc/JNcgv1xgmJwsK+9CEJTyv hSeh8R87pfGk10iggr1IBf7RdSq//VpiJ5QaKki23/HifmVUcRVqD52IyQ0ZGcQw Z/Esa6b6gGgvr2aKdnYMGgQhfLkrcg3PqtLDkf9KEbvknvWulDBX8FiAJjKQ97my iZbZXshkfimPoMEod3AYlE6P77v2v2U/AZDpMgtDZIOS7vqpVA1KEhu7o5X6WLax 0nh/Lu+vCoD4Ic6Vs0lDvCkHgh4a4prhKfVh0C/woxR5NbckVLx4Bk+zFFfDt335 RMfoKKwXz22KpxO0H8UC9b6ZAyIFFCqrqEz7no1qHUnSSog2K+let9IgTX9lRnfy 01ppF39VI/dp8eMM9ztC =vAUU -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#764990: Update about DisplayPort MST displays
I just found out an interesting thing. The displays are indeed detected, but are not added by xorg, instead they are removed. This is a log from undocking: [ 840.894] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-5 (null) [ 840.897] (II) intel(0): EDID vendor LGD, prod id 1079 [ 840.897] (II) intel(0): Printing DDC gathered Modelines: [ 840.897] (II) intel(0): Modeline 1920x1080x0.0 138.46 1920 1968 2000 2106 1080 1083 1088 1095 +hsync -vsync (65.7 kHz eP) [ 840.928] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-4 (null) [ 840.928] (II) intel(0): EDID vendor LGD, prod id 1079 [ 840.928] (II) intel(0): Printing DDC gathered Modelines: [ 840.928] (II) intel(0): Modeline 1920x1080x0.0 138.46 1920 1968 2000 2106 1080 1083 1088 1095 +hsync -vsync (65.7 kHz eP) [ 840.965] (II) intel(0): EDID vendor LGD, prod id 1079 [ 840.965] (II) intel(0): Printing DDC gathered Modelines: [ 840.965] (II) intel(0): Modeline 1920x1080x0.0 138.46 1920 1968 2000 2106 1080 1083 1088 1095 +hsync -vsync (65.7 kHz eP) [ 840.996] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-3 (null) [ 840.996] (II) intel(0): EDID vendor LGD, prod id 1079 [ 840.996] (II) intel(0): Printing DDC gathered Modelines: [ 840.996] (II) intel(0): Modeline 1920x1080x0.0 138.46 1920 1968 2000 2106 1080 1083 1088 1095 +hsync -vsync (65.7 kHz eP) And this is from docking: [ 845.199] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-3 (null) [ 845.202] (II) intel(0): EDID vendor LGD, prod id 1079 [ 845.202] (II) intel(0): Printing DDC gathered Modelines: [ 845.202] (II) intel(0): Modeline 1920x1080x0.0 138.46 1920 1968 2000 2106 1080 1083 1088 1095 +hsync -vsync (65.7 kHz eP) [ 845.232] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-4 (null) [ 845.232] (II) intel(0): EDID vendor LGD, prod id 1079 [ 845.232] (II) intel(0): Printing DDC gathered Modelines: [ 845.232] (II) intel(0): Modeline 1920x1080x0.0 138.46 1920 1968 2000 2106 1080 1083 1088 1095 +hsync -vsync (65.7 kHz eP) [ 845.269] (II) intel(0): EDID vendor LGD, prod id 1079 [ 845.269] (II) intel(0): Printing DDC gathered Modelines: [ 845.269] (II) intel(0): Modeline 1920x1080x0.0 138.46 1920 1968 2000 2106 1080 1083 1088 1095 +hsync -vsync (65.7 kHz eP) [ 845.300] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-5 (null) [ 845.300] (II) intel(0): EDID vendor LGD, prod id 1079 [ 845.300] (II) intel(0): Printing DDC gathered Modelines: [ 845.300] (II) intel(0): Modeline 1920x1080x0.0 138.46 1920 1968 2000 2106 1080 1083 1088 1095 +hsync -vsync (65.7 kHz eP) In both cases the DP-[3-5] devices are removed. Why are they being removed when docking? A bug? Also, throughout all of that none of these displays are reported by xrandr and cannot be used unless the xserver is restarted. Only then are they added properly. Cheers, Jacob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765314: mrpt: FTBFS on all non-x86-based architectures
Hi Olly, In theory, these patches should fix sparc (I think) s390x: - https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f -https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19 But couldn't test it locally. Would you please try to attach them as patches for a new version 1.2.2-1.2?? Best, JL On Wed, Oct 15, 2014 at 7:31 AM, Jose Luis Blanco joseluisblan...@gmail.com wrote: Any recommendation about how to test it locally on s390x? qemu or alike? A partner got it tested in a physical mips device before submitting, so hopefully it will work there... Thanks. On Wed, Oct 15, 2014 at 7:00 AM, Olly Betts o...@survex.com wrote: Still not building everywhere: https://buildd.debian.org/status/package.php?p=mrpt It's never built on ppc64el, so that won't block testing migration (but it would be good to sort out). The failure on sparc isn't a big problem, as sparc isn't a release arch for jessie. And armel, mips, and mipsel are yet to attempt a build of this version. But the failure on s390x needs sorting out if mrpt is to make jessie - failure is in the testsuite: [ RUN ] Synch.CriticalSections_Multi *** stack smashing detected ***: ./test_mrpt_base terminated For backtrace, etc see the tail end of: https://buildd.debian.org/status/fetch.php?pkg=mrptarch=s390xver=1%3A1.2.2-1.1stamp=1413289418 Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765442: bcrelay:amd64 broken
Package: bcrelay Version: 1.3.4-5.2 Severity: normal Dear Maintainer, bcrelay:amd64 terminates immediatly with: # bcrelay -i vlan0108 -o vlan0104 *** buffer overflow detected ***: bcrelay terminated === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f16386c8697] /lib/x86_64-linux-gnu/libc.so.6(+0xef550)[0x7f16386c7550] /lib/x86_64-linux-gnu/libc.so.6(+0xee9a9)[0x7f16386c69a9] /lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0x85)[0x7f163864d1e5] /lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x1a12)[0x7f163861cdc2] /lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x9d)[0x7f16386c6a4d] /lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7f)[0x7f16386c698f] bcrelay(+0x1893)[0x7f1638b86893] bcrelay(+0x20f5)[0x7f1638b870f5] bcrelay(main+0x267)[0x7f1638b86527] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f16385f6eed] bcrelay(+0x1595)[0x7f1638b86595] === Memory map: 7f16383c2000-7f16383d7000 r-xp fd:00 89462 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f16383d7000-7f16385d7000 ---p 00015000 fd:00 89462 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f16385d7000-7f16385d8000 rw-p 00015000 fd:00 89462 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f16385d8000-7f1638759000 r-xp fd:00 89511 /lib/x86_64-linux-gnu/libc-2.13.so 7f1638759000-7f1638959000 ---p 00181000 fd:00 89511 /lib/x86_64-linux-gnu/libc-2.13.so 7f1638959000-7f163895d000 r--p 00181000 fd:00 89511 /lib/x86_64-linux-gnu/libc-2.13.so 7f163895d000-7f163895e000 rw-p 00185000 fd:00 89511 /lib/x86_64-linux-gnu/libc-2.13.so 7f163895e000-7f1638963000 rw-p 00:00 0 7f1638963000-7f1638983000 r-xp fd:00 89410 /lib/x86_64-linux-gnu/ld-2.13.so 7f1638b76000-7f1638b79000 rw-p 00:00 0 7f1638b8-7f1638b82000 rw-p 00:00 0 7f1638b82000-7f1638b83000 r--p 0001f000 fd:00 89410 /lib/x86_64-linux-gnu/ld-2.13.so 7f1638b83000-7f1638b84000 rw-p 0002 fd:00 89410 /lib/x86_64-linux-gnu/ld-2.13.so 7f1638b84000-7f1638b85000 rw-p 00:00 0 7f1638b85000-7f1638b89000 r-xp fd:00 594241 /usr/sbin/bcrelay 7f1638d88000-7f1638d89000 r--p 3000 fd:00 594241 /usr/sbin/bcrelay 7f1638d89000-7f1638d8a000 rw-p 4000 fd:00 594241 /usr/sbin/bcrelay 7f1638d8a000-7f1638d9 rw-p 00:00 0 7f1639e58000-7f1639e79000 rw-p 00:00 0 [heap] 7fffef8d3000-7fffef8f4000 rw-p 00:00 0 [stack] 7fffef99-7fffef991000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Aborted After exchanging the binary with its i386 counterpart the same commandline just works [tm]. Kind regards, Martin Sofaru -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages bcrelay depends on: ii libc6 2.13-38+deb7u4 bcrelay recommends no packages. bcrelay 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#758116: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Bas, On Tue, Oct 14, 2014 at 07:19:36PM +0200, Bas Wijnen wrote: On Tue, Oct 14, 2014 at 11:20:02AM +0200, Andreas Tille wrote: I admit I expected *you* to know about Blends for a while - but considering the video recorded quote I think I was not wrong using this chance to point this out for other readers of this mail as it is really a fact that I always meet DDs who mix up this concept with derivatives. I have heard about them for quite a while, indeed, but I must say that I never entirely understood what they are. I'm guessing I'm not alone in this. You belong to a majority if I might conclude from my experience. I have no idea whether I should feel responsible for this but I'm fighting on several fronts like the extensive documentation[1] and countless talks[2] as well as trying to push newcomers into the topic by sponsering their packages[3]. So let me write what I think they are, and then you can correct me. I've read the explanation on the wiki, but I'm still not sure if I understand it right. I think a blend is a system you can install, which after installing is a regular Debian system, set up for a particular task. Because it's a regualr Debian system, after installation packages can be installed and removed just like on any other Debian system, and any other system can be turned into a blend by installing the right packages. For the moment the way to install Blends is to use the plain Debian installer and afterwards install a bunch of metapackages. There is one exception Debian Edu / Skolelinux which uses dedicated installation medias with pre-feeded debconf data. There is a long standing discussion whether Debian Edu deserves the term pure but I will not dive into this can of worms since I do not want to spoil the general picture here with details caused by a single bug (Debian Edu people will know it by heart). The lack of a missing installer for all other Blends is a frequently criticised problem and I personally think this should be fixed by the integration into the official boot cds since this fits to the nature of Blends which are a subset of Debian. I'd like to add some informal ideas about Blends to perhaps give a better picture of the idea: - Several people entertain deriving from Debian and actually the never ending misconception about Blends is that they are derivatives. But Blends are derivatives done the right way - by not deriving Debian and rather do the adaptations inside Debian. The goal is to save time and prevent reinventing the wheel on the (non)derivers side and to bundle forces right into Debian. - Blends are a way to advertise Debian in specific fields of interest I personally started from a point where I wanted to reach a status, that if somebody wonders what distribution to use for biology and medical care the natural answer should be Use Debian We could easily reach this goal for other fields of interest if all our dedicated experts we had in Debian would work on this direction in their own field. - Blends is also about forming teams inside Debian to care for a certain topic to serve as glue between upstream and the end user and if you have watched[4] (as advised in my last mail) you not only get an idea about how we form teams but about the Blends concept in general. From the wiki, it seems that is just the Pure Blend, because other Blends may have extra apt sources. There might be additional apt sources but it is not only about apt sources. For instance (as far as I'm informed) all packages in Debian Edu are inside Debian and there was just a need to change some configuration change of some *other* packages which conflicts with Debian policy (I'm pretty sure Jonas will respond in detail to this mail - so I save my time here B-)). The whole pure / non-pure discussion is from my personal point of view a consequence of nitpicking about policy compliance which was born out of the problem that some package maintainers are not willing to accept some more flexible debconf configuration options. I agree that policy is something to be really picky about and will not argue against this but on the other hand it spoils a bit the simplicy to understand the whole concept. So a Debian Pure Blend (I use the shortcut Blend as a synonym) is fully integrated into Debian while non-pure Blends are trying to approach the full Debian integration but some minor pieces like a hand full of packages or some policy conflicting stuff remain on their todo list. Is this a good summary? I hope I added some more points to this summary. If so, I think it would be a very good idea to make this part of the installer. And turn the default system into just another blend. Sounds like a nice view on the Blends concept. :-) Regardless of whether my summary is good, I think the documentation can use some improvement. +1 That's always needed. Examples of the target audience would
Bug#765440: python-deap-doc and deap-doc: error when trying to install together
Package: deap-doc,python-deap-doc Version: deap-doc/1.0.1-3 Version: python-deap-doc/1.0.1-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2014-10-15 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Selecting previously unselected package libjs-jquery. (Reading database ... 10872 files and directories currently installed.) Preparing to unpack .../libjs-jquery_1.7.2+dfsg-3.2_all.deb ... Unpacking libjs-jquery (1.7.2+dfsg-3.2) ... Selecting previously unselected package libjs-underscore. Preparing to unpack .../libjs-underscore_1.4.4-2_all.deb ... Unpacking libjs-underscore (1.4.4-2) ... Selecting previously unselected package libjs-sphinxdoc. Preparing to unpack .../libjs-sphinxdoc_1.2.3+dfsg-1_all.deb ... Unpacking libjs-sphinxdoc (1.2.3+dfsg-1) ... Selecting previously unselected package deap-doc. Preparing to unpack .../deap-doc_1.0.1-3_all.deb ... Unpacking deap-doc (1.0.1-3) ... Selecting previously unselected package python-deap-doc. Preparing to unpack .../python-deap-doc_1.0.1-1_all.deb ... Unpacking python-deap-doc (1.0.1-1) ... dpkg: error processing archive /var/cache/apt/archives/python-deap-doc_1.0.1-1_all.deb (--unpack): trying to overwrite '/usr/share/doc-base/deap', which is also in package deap-doc 1.0.1-3 Errors were encountered while processing: /var/cache/apt/archives/python-deap-doc_1.0.1-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/share/doc-base/deap This bug has been filed against both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. You may then also register in the BTS that the other package is affected by the bug. -Ralf. PS: for more information about the detection of file overwrite errors of this kind see http://edos.debian.net/file-overwrites/. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765439: aspell-hi: failure during installation
Package: aspell-hi Version: 0.02-6 Severity: normal The package failed to upgrade during normal operation. Setting up libtext-unidecode-perl (1.22-1) ... Processing triggers for libc-bin (2.19-11) ... Processing triggers for dictionaries-common (1.23.12) ... aspell-autobuildhash: processing: hi [hi]. Error: The language hi is not known. This is probably because: the file /usr/lib/aspell/hi.dat can not be opened for reading. Undefined subroutine main::subst called at /usr/sbin/aspell-autobuildhash line 54. dpkg: error processing package dictionaries-common (--configure): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: dictionaries-common E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: Setting up dictionaries-common (1.23.12) ... Processing triggers for dictionaries-common (1.23.12) ... aspell-autobuildhash: processing: hi [hi]. Error: The language hi is not known. This is probably because: the file /usr/lib/aspell/hi.dat can not be opened for reading. Undefined subroutine main::subst called at /usr/sbin/aspell-autobuildhash line 54. dpkg: error processing package dictionaries-common (--configure): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: dictionaries-common Current status: 0 updates [-12]. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aspell-hi depends on: ii aspell 0.60.7~20110707-1.1 ih dictionaries-common 1.23.12 aspell-hi recommends no packages. aspell-hi 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#765441: [snapper] During install: check for /etc/sysconfig/snapper
Package: snapper Version: 0.2.4-1 Severity: wishlist --- Please enter the report below this line. --- Early 2014, since the official debian package wasn't up to date, I started with the OpenSuse repository; and did my config at this time. But the OpenSuse package uses /etc/sysconfig/snapper instead of /etc/default/snapper. So, now that I'm back with the official debian release, all my configs seemed lost and I started to heavily sweat. It would be nice if the install script could check for the presence of the sysconfig file and offer to copy/move it. Thanks Michel --- System information. --- Architecture: amd64 Kernel: Linux 3.16-1-amd64 Debian Release: jessie/sid 500 unstable www.deb-multimedia.org 500 unstable ftp.uk.debian.org 500 unstable ftp.fr.debian.org 500 stable dl.google.com 1 experimental ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed ===-+-== libacl1 (= 2.2.51-8) | 2.2.52-2 libboost-system1.49.0 (= 1.49.0-1) | 1.49.0-4+b3 libboost-thread1.49.0 (= 1.49.0-1) | 1.49.0-4+b3 libc6 (= 2.3.2) | libdbus-1-3 (= 1.1.1) | libgcc1 (= 1:4.1.1) | libsnapper | libstdc++6 (= 4.6) | libxml2 (= 2.6.27) | zlib1g (= 1:1.1.4) | Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686544: upstream response
On Wed, 2014-10-15 at 05:10 +0800, 積丹尼 Dan Jacobson wrote: Upstream closed https://bugzilla.kernel.org/show_bug.cgi?id=85471 Now what should I do? Thanks. Get on with your life. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#746003: [Pkg-electronics-devel] Bug#746003: Bug#760986: RM: guile-1.8 -- ROM; replaced by guile-2.0
On Sun, Oct 12, 2014 at 09:51:12PM -0500, Rob Browning wrote: g-wrap [1] Only response wrt 2.0 is a mention of an upload that's been in experimental for two years, but no response from the maintainer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761210 Last non-experimental upload: 2012-05 ---end quoted text--- Can't this be experimental version be NMU'ed for unstable ? Btw, there is a patch in Ubuntu against g-wrap upload that is in experimental: https://patches.ubuntu.com/g/g-wrap/g-wrap_1.9.14-2ubuntu1.patch -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Bug#765415: linux-image-3.17-rc5-amd64: mgag200drmfb driver fails on Supermicro X8DAH system
On Tue, 2014-10-14 at 13:20 -0700, Ralf-Peter Rohbeck wrote: running 3.17-rc5 on this Supermicro system causes the text console to fail. The last output is fb: switching to mgag200drmfb from simple and from then on the text console is dead. X (kdm) works though. kern.log shows Oct 14 12:52:12 Volante kernel: [ 21.739574] fb: switching to mgag200drmfb from simple Oct 14 12:52:12 Volante kernel: [ 21.763417] Console: switching to colour dummy device 80x25 Oct 14 12:52:12 Volante kernel: [ 21.763781] [drm:mga_vram_init] *ERROR* can't reserve VRAM Oct 14 12:52:12 Volante kernel: [ 21.763788] mgag200 :06:04.0: Fatal error during GPU init: -6 Some useful information about this system: [...] ** Model information sys_vendor: Supermicro product_name: X8DAH product_version: 1234567890 chassis_vendor: Supermicro chassis_version: 1234567890 bios_vendor: American Megatrends Inc. bios_version: 2.0a board_vendor: Supermicro board_name: X8DAH board_version: 1234567890 [...] 06:04.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 [102b:0532] (rev 0a) (prog-if 00 [VGA controller]) Subsystem: Super Micro Computer Inc Device [15d9:0100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 16 Region 0: Memory at f900 (32-bit, prefetchable) [size=16M] Region 1: Memory at faffc000 (32-bit, non-prefetchable) [size=16K] Region 2: Memory at fb00 (32-bit, non-prefetchable) [size=8M] Expansion ROM at unassigned [disabled] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- [...] -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#765415: linux-image-3.17-rc5-amd64: mgag200drmfb driver fails on Supermicro X8DAH system
Control: severity -1 important On Tue, 2014-10-14 at 13:20 -0700, Ralf-Peter Rohbeck wrote: Package: src:linux Version: 3.17~rc5-1~exp1 Severity: grave Justification: renders package unusable [...] Not in general. And you should be able to work around this using kernel parameter 'nomodeset'. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#765411: Was this package abandonned?
On Tue, Oct 14, 2014 at 15:51 -0400, Alexandre Viau wrote: Is there any plans to update leiningen? It's needed to compile Riemann, which I intend to package. There are definitely plans to update leiningen, but I am not sure when I (or anybody else) will get around to do that. AFAICT this won't happen in time for the freeze, but I would still very much like to get leiningen 2 into Debian, so that the remaining dependencies will have to be packaged and bugs fixed. I close this bug as there are better ways to communicate about this and I would also be very interested in seeing riemann in Debian. -- Wolodja deb...@babilen5.org 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Bug#689063: NMU of dhelp
Hi, I'd like to inform you that I've just uploaded Helge's NMU to DELAYED/2. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#765443: ltsp-server: Unset variables set by libpam-tmpdir in ltsp-chroot?
Package: ltsp-client-core Version: 5.5.3-1 Severity: normal User: debian-...@lists.debian.org Usertags: debian-edu When using libpam-tmpdir on the LTSP server and then calling 'ltsp-chroot' to do operations in the LTSP chroot, the temp directory variables are inherited and causing 'apt-get upgrade' (because of postinst scripts using the temp directory variables) etc. to fail because the temporary directory do not exist. Can ltsp-chroot be changed to unset the temp directory variables if they point to a non-existing directory? These are the variables set by libpam-tempdir: TMPDIR=/tmp/user/1000 TEMP=/tmp/user/1000 TEMPDIR=/tmp/user/1000 TMP=/tmp/user/1000 -- 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#738028: python-seqdiag: seqdiag fails to process diagram with UTF-8 encoded labels
On 15/10-2014 03:31, Kouhei Maeda wrote: seqdiag utf-8-failure.diag I can confirm that the submitted test case works correctly with python-seqdiag 0.9.3-1. Greetings, Jacob -- Only Hogwarts students really need spellcheckers -- An anonymous RISKS reader -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765444: RFP: mustache-java -- Mustache (templating language) implementation in Java
Package: wnpp Severity: wishlist * Package name: mustache-java Version : 0.8.17 Upstream Author : Sam Pullara spull...@yahoo.com * URL or Web page : http://github.com/spullara/mustache.java * License : Apache-2.0 Description : Mustache (templating language) implementation in Java -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765445: elasticsearch: New upstream version available
Source: elasticsearch Severity: wishlist The current version of elasticsearch in Debian/unstable is 1.0.3, upstream is at 1.3.4. It can't be packaged without some extra dependencies which will be tracked using this bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765446: debhelper build target status file packagename.debhelper.log is not documented
Package: debhelper Version: 9.20120909 Severity: minor Tags: patch Dear Maintainer, debhelper build status log file is not documented in manual pages. Common developer use cases involve modifying list of installed files and package install scripts, and for these use cases a complete re-compile of the packages in not necessary. Instead developers could modify the package status log to re-execute all steps after build target, for example. Here's the kind of documentation I had in mind (on top of debhelper git master): From 275c394597c9ab8dff3a5e8fe9de8bf49c66ba41 Mon Sep 17 00:00:00 2001 From: Mikko Rapeli mikko.rap...@iki.fi Date: Wed, 15 Oct 2014 10:36:56 +0300 Subject: [PATCH] Document build status file It is useful to change just the build status file when only some of the build steps need to be re-executed, e.g. after changes to .install files. Rename SEE ALSO to EXAMPLES because that's what they are. Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi --- debhelper.pod | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/debhelper.pod b/debhelper.pod index 659c4a3..0032892 100644 --- a/debhelper.pod +++ b/debhelper.pod @@ -689,7 +689,21 @@ BDH_ALWAYS_EXCLUDE=CVS:.svn =back -=head1 SEE ALSO +=head1 BUILD TARGET STATUS LOG + +debhelper maintains build state in Fdebian/packagename.debhelper.log file. +This file contains an entry for all successfully executed build targets +after package compilation. + +A common usecase for developers is to change list of installed files +via Fdebian/packagename.install or package install scripts. With these cases +it is not necessary to recompile the whole package but instead only build steps +after normal source tree compilation need to be re-executed. This is achieved +my removing all lines after dh_auto_build in Fdebian/packagename.debhelper.log +file and recompiling the package with 'fakeroot debian/rules binary' or +debuild. + +=head1 EXAMPLES =over 4 -- 1.7.10.4 -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.58-grbfs-kapsi (SMP w/24 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 debhelper depends on: ii binutils2.22-8 ii dpkg1.16.15 ii dpkg-dev1.16.15 ii file5.11-2+deb7u5 ii html2text 1.3.2a-15 ii man-db 2.6.2-1 ii perl5.14.2-21+deb7u1 ii po-debconf 1.0.16+nmu2 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 0.61 -- 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#765355: NMU debdiff for libbitcoin_2.0-2.1
Control: tags -1 + pending
Hello Jonas,
At Imagination Technologies (http://imgtec.com/) Jurica Stanojkovic has
found a solution to Debian bug #765355.
https://bugs.debian.org/765355
My NMU debdiff for libbitcoin_2.0-2.1 is below, at the end of this
message.
With the changes in the NMU debdiff, libbitcoin builds successfully on
mips, mipsel and amd64.
Regards,
Aníbal
--
Aníbal Monsalve Salazar anibal.monsalvesala...@imgtec.com
debdiff libbitcoin_2.0-2.dsc libbitcoin_2.0-2.1.dsc
diff -Nru libbitcoin-2.0/debian/changelog libbitcoin-2.0/debian/changelog
--- libbitcoin-2.0/debian/changelog 2014-08-15 12:48:38.0 +0100
+++ libbitcoin-2.0/debian/changelog 2014-10-15 08:49:01.0 +0100
@@ -1,3 +1,13 @@
+libbitcoin (2.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS on big endian architectures.
+Add big-endian.patch.
+Patch by Jurica Stanojkovic jurica.stanojko...@imgtec.com.
+Closes: #765355.
+
+ -- Anibal Monsalve Salazar ani...@debian.org Wed, 15 Oct 2014 08:48:57
+0100
+
libbitcoin (2.0-2) unstable; urgency=medium
* Add patch 1001 to fix include Boost endian include.
diff -Nru libbitcoin-2.0/debian/patches/big-endian.patch
libbitcoin-2.0/debian/patches/big-endian.patch
--- libbitcoin-2.0/debian/patches/big-endian.patch 1970-01-01
01:00:00.0 +0100
+++ libbitcoin-2.0/debian/patches/big-endian.patch 2014-10-15
08:48:54.0 +0100
@@ -0,0 +1,72 @@
+Date: Mon, 13 Oct 2014 13:16:08 +0100
+From: Jurica Stanojkovic jurica.stanojko...@imgtec.com
+Subject: package libbitcoin_2.0-2 FTBFS on big endian
+
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765355
+
+Package libbitcoin_2.0-2 FTBFS on big endian architectures.
+https://buildd.debian.org/status/package.php?p=libbitcoinsuite=sid
+
+with the following error:
+
+In file included from ./../include/bitcoin/satoshi_serialize.hpp:24:0,
+ from satoshi_serialize.cpp:20:
+./../include/bitcoin/format.hpp:49:27: error: #elif with no expression
+ #elif BOOST_BIG_ENDIAN
+ ^
+./../include/bitcoin/format.hpp:52:10: error: #error Endian isn't defined!
+ #error Endian isn't defined!
+ ^
+./../include/bitcoin/format.hpp:70:27: error: #elif with no expression
+ #elif BOOST_BIG_ENDIAN
+ ^
+./../include/bitcoin/format.hpp:73:10: error: #error Endian isn't defined!
+ #error Endian isn't defined!
+ ^
+In file included from ./../include/bitcoin/satoshi_serialize.hpp:29:0,
+ from satoshi_serialize.cpp:20:
+./../include/bitcoin/utility/serializer.hpp:348:27: error: #elif with no
expression
+ #elif BOOST_BIG_ENDIAN
+ ^
+./../include/bitcoin/utility/serializer.hpp:351:10: error: #error Endian
isn't defined!
+ #error Endian isn't defined!
+ ^
+make[2]: *** [satoshi_serialize.lo] Error 1
+
+This issue is resolved with the patch below.
+
+Index: libbitcoin-2.0/include/bitcoin/format.hpp
+===
+--- libbitcoin-2.0.orig/include/bitcoin/format.hpp
libbitcoin-2.0/include/bitcoin/format.hpp
+@@ -46,7 +46,7 @@ T cast_chunk(data_chunk chunk, bool reve
+ {
+ #ifdef BOOST_LITTLE_ENDIAN
+ // do nothing
+-#elif BOOST_BIG_ENDIAN
++#elif defined BOOST_BIG_ENDIAN
+ reverse = !reverse;
+ #else
+ #error Endian isn't defined!
+@@ -67,7 +67,7 @@ data_chunk uncast_type(T value, bool rev
+ // TODO Future versions of boost will have boost::native_to_little(value);
+ #ifdef BOOST_LITTLE_ENDIAN
+ // do nothing
+-#elif BOOST_BIG_ENDIAN
++#elif defined BOOST_BIG_ENDIAN
+ reverse = !reverse;
+ #else
+ #error Endian isn't defined!
+Index: libbitcoin-2.0/include/bitcoin/utility/serializer.hpp
+===
+--- libbitcoin-2.0.orig/include/bitcoin/utility/serializer.hpp
libbitcoin-2.0/include/bitcoin/utility/serializer.hpp
+@@ -345,7 +345,7 @@ private:
+ check_distance(begin, end, byte_array.size());
+ #ifdef BOOST_LITTLE_ENDIAN
+ // do nothing
+-#elif BOOST_BIG_ENDIAN
++#elif defined BOOST_BIG_ENDIAN
+ reverse = !reverse;
+ #else
+ #error Endian isn't defined!
diff -Nru libbitcoin-2.0/debian/patches/series
libbitcoin-2.0/debian/patches/series
--- libbitcoin-2.0/debian/patches/series2014-08-15 12:37:30.0
+0100
+++ libbitcoin-2.0/debian/patches/series2014-10-14 07:41:48.0
+0100
@@ -1 +1,2 @@
1001_fix_include_Boost_endian.patch
+big-endian.patch
signature.asc
Description: Digital signature
Bug#764990: xserver-xorg: crashes when undocking Thinkpad X240 from Ultradock
❦ 12 octobre 2014 21:29 +0200, Jakub Sokołowski ja...@codility.com : I installed the 3.17-rc5 linux kernel from experimental in order to use multiple screens with my new Ultradock for my Thinkpad X240 since it brings the DisplayPort Multi-Stream Transport (MST) support. Without it the system would not recognize any of the video outputs from the dock. With it the outputs are noticed ONLY after the xserver restart. Just docking the laptop doesn't do anything. Just to get you some input, I am using a Carbon X1 Gen2 with the Onelink Pro Dock. While its form factor is quite different of the classic Ultradock of other Thinkpads, it seems that the underlying technology is the same. So, I am also using a 3.17~rc5. Docking works fine. Undocking crash the whole X server like you. When plugging, I get this: [283984.289] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-3 (null) [283984.290] (II) intel(0): Enabled output DP3 [283984.290] (II) intel(0): Enabled output DP4 [283984.290] (II) intel(0): Enabled output DP5 [283984.323] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-4 (null) [283984.389] removing GPU device /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-5 (null) When using xrandr to use the two new screens, I get this: [283988.232] (II) intel(0): resizing framebuffer to 1920x1080 [283988.233] (II) intel(0): switch to mode 1920x1080@60.0 on DP3 using pipe 0, position (0, 0), rotation normal, reflection none [283989.026] (II) intel(0): resizing framebuffer to 3840x1080 [283989.051] (II) intel(0): switch to mode 1920x1080@60.0 on DP4 using pipe 1, position (1920, 0), rotation normal, reflection none I have to use two xrandr command, if I try to do everything in one command, it seems that xrandr (or X) is not able to order things correctly and it complains about being unable to configure some CRTC. When undocking, I get this kernel traceback: Sep 17 18:34:12 zoro kernel: [ 2458.992528] [ cut here ] Sep 17 18:34:12 zoro kernel: [ 2458.992554] WARNING: CPU: 2 PID: 1297 at /home/bernat/src/linux/drivers/gpu/drm/i915/i915_gem.c:5011 i915_gem_track_fb+0xf1/0x130 [i915]() Sep 17 18:34:12 zoro kernel: [ 2458.992571] Modules linked in: ccm bnep xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security iptable_raw iptable_filter ip_tables x_tables binfmt_misc cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave deflate ctr twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_aesni_avx2 camellia_aesni_avx_x86_64 camellia_x86_64 serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 xts serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_avx_x86_64 cast5_generic cast_common des_generic cbc cmac xcbc rmd160 sha512_ssse3 sha512_generic sha256_ssse3 sha256_generic hmac crypto_null af_key xfrm_algo snd_hda_codec_hdmi arc4 nls_utf8 nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp uvcvideo ecb kvm_intel iwlmvm kvm videobuf2_vmalloc videobuf2_memops mac80211 videobuf2_core v4l2_common cdc_mbim videodev cdc_wdm hid_multitouch joydev media snd_usb_audio cdc_ncm efi_pstore cdc_ether snd_usbmidi_lib psmouse evdev usbnet snd_rawmidi pcspkr mii snd_seq_device efivars serio_raw btusb iwlwifi bluetooth snd_hda_codec_realtek cfg80211 snd_hda_codec_generic i915 thinkpad_acpi nvram wmi snd_hda_intel snd_hda_controller snd_hda_codec rfkill ac tpm_tis snd_hwdep battery tpm snd_pcm snd_timer drm_kms_helper snd video lpc_ich drm intel_smartconnect soundcore mfd_core i2c_algo_bit shpchp mei_me button mei i2c_designware_platform i2c_i801 i2c_designware_core i2ccore processor fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 algif_skcipher af_alg hid_generic usbhid hid dm_crypt dm_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci libata scsi_mod ehci_pci ehci_hcd xhci_hcd e1000e ptp pps_core usbcore thermal usb_common thermal_sys Sep 17 18:34:12 zoro kernel: [ 2458.992617] CPU: 2 PID: 1297 Comm: Xorg Not tainted 3.17-rc4-amd64 #1 Debian 3.17~rc4-1~exp1 Sep 17 18:34:12 zoro kernel: [ 2458.992618] Hardware name: LENOVO 20A7005UMZ/20A7005UMZ, BIOS GRET39WW (1.16 ) 06/06/2014 Sep 17 18:34:12 zoro kernel: [ 2458.992620] 0009 8150e2a6 810668a7 Sep 17 18:34:12 zoro kernel: [ 2458.992621] 8800d7f8d900 8800d7f8d900 880214060f40 8800d7f8d900 Sep 17 18:34:12 zoro kernel: [ 2458.992623] 8800d7f8d900 a04cfcd1
Bug#765381: bijiben: crashes on startup
Control: tag -1 + moreinfo Hi, On Tue, Oct 14, 2014 at 8:46 AM, erusan eru...@gmail.com wrote: Package: bijiben Version: 3.14.1-1 Severity: important Dear Maintainer, Starting bijiben results (sometimes) in the window being visible for half a moment before disappearing, usually not showing up at all. Starting using command 'bijiben' in terminal yields the following:Unable to load location /home/myusername/.local/share/bijiben/.Trash: No such file or directory Segmentation fault System is mostly GNOME 3.12 from testing. Updated bijiben from 3.14.0 to 3.14.1 for the purpose of seeing if the bug remained (and it does). Thanks for your bug report! However, there are a few more steps required on your part for this report to be useful, i.e. please: - Generate a backtrace by rebuilding bijiben with debug symbols and running gdb (instructions at [1]), and then - Report this bug directly upstream at [2] By the way, bijiben 3.12.x didn't have this issue, correct? i.e. is this a regression? Regards, Vincent [1] https://wiki.debian.org/HowToGetABacktrace#Rebuilding_the_package_you.2BIBk-re_debugging [2] https://bugzilla.gnome.org/enter_bug.cgi?product=bijiben -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765447: does not build twice in a row
Package: openvpn Severity: wishlist Hi, at least on wheezy, I cannot build unstable's current openvpn package twice in a row. debian/rules clean leaves a modified config.log and a modified tests/t_client.sh in place. It might be helpful to zap config.log in debian/rules clean and to make a backup of tests/t_client.sh and restore it in the clean target. I must admit that I didn't test whether this issue applies to building on unstable as well. Greetings Marc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765448: libvirt-daemon-system is not installable on non-systemd system
Package: libvirt-daemon-system Version: 1.2.8-3 Severity: normal Dear Maintainer, attempts to do apt-get dist-upgrade recently started to report: The following packages will be REMOVED: libvirt-bin libvirt-daemon-system virt-goodies $ apt-cache policy libvirt-daemon-system libvirt-daemon-system: Installed: 1.2.8-3 Candidate: 1.2.9-3 Version table: 1.2.9-3 0 500 http://ftp.fi.debian.org/debian/ unstable/main amd64 Packages *** 1.2.8-3 0 500 http://ftp.fi.debian.org/debian/ jessie/main amd64 Packages 100 /var/lib/dpkg/status The reason is that the new libvirt-daemon-system version Depends of policykit-1, which depends of libpam-systemd which Depends of systemd which is blocked on my system. Since it's declared, that systemd is not mandatory in Debian, the package must be installable (or what I did wrong?). -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0kaliuta1+ (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 Versions of packages libvirt-daemon-system depends on: ii adduser 3.113+nmu3 ii gettext-base 0.19.2-3 ii init-system-helpers 1.21 ii libapparmor1 2.8.0-8 ii libaudit11:2.4-1 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libblkid12.25.1-4 ii libc62.19-11 ii libcap-ng0 0.7.4-2 ii libdbus-1-3 1.8.8-2 ii libdevmapper1.02.1 2:1.02.90-2 ii libgnutls-deb0-283.3.8-3 ii libnl-3-200 3.2.24-2 ii libnl-route-3-2003.2.24-2 ii libnuma1 2.0.10~rc2-3 ii librados20.80.6-1 ii librbd1 0.80.6-1 ii libsasl2-2 2.1.26.dfsg1-11 ii libselinux1 2.3-2 ii libssh2-11.4.3-4 ii libsystemd0 215-5+b1 ii libvirt-clients 1.2.8-3 ii libvirt-daemon 1.2.8-3 ii libvirt0 1.2.8-3 ii libxml2 2.9.1+dfsg1-4 ii libyajl2 2.1.0-2 ii logrotate3.8.7-1 Versions of packages libvirt-daemon-system recommends: pn bridge-utils none ii dmidecode 2.12-3 ii dnsmasq-base 2.72-2 ii ebtables 2.0.10.4-3 ii iproute2 3.16.0-2 ii iptables 1.4.21-2 ii parted3.2-6 ii pm-utils 1.4.1-15 Versions of packages libvirt-daemon-system suggests: pn apparmor none pn auditd none pn policykit-1 none pn radvdnone pn systemd none pn systemtapnone -- Configuration Files: /etc/libvirt/qemu.conf [Errno 13] Permission denied: u'/etc/libvirt/qemu.conf' -- no debconf information
Bug#765450: does not build with pkcs-helper 1.09 (backports)
Package: openvpn Severity: wishlist Hi, OpenVPN 2.3.4 does not build on wheezy because of a too old libpkcs11-helper1 package in wheezy. To be nice to backporters, the package should have a versioned build dependency. It builds fine with a backported pkcs11-helper 1.11 from unstable. Greetings Marc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765449: Two kworder processes takin up 30% CPU each after coming out of suspend
Package: src:linux Version: 3.16.3-2 Severity: normal I've now seen this a couple of times with this kernel after coming out of suspend. This is not something I have seen on this now two year old machine before. After coming out of suspend top shows this: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 19127 root 20 0 0 0 0 S 31.3 0.0 4:42.20 kworker/2:2 5448 root 20 0 0 0 0 S 31.3 0.0 0:25.94 kworker/0:0 84 root 20 0 0 0 0 S 18.8 0.0 6:21.82 khubd 3 root 20 0 0 0 0 S 12.5 0.0 4:51.46 ksoftirqd/0 18 root 20 0 0 0 0 S 6.3 0.0 3:43.13 ksoftirqd/2 The 'iotop -Pa' command shows almost zero I/O going on. Running perf suggests this is an issue with the xhci_hub_control: + 8.65% 8.65%swapper [kernel.kallsyms] [k] intel_idle ◆ + 7.92% 7.92%kworker/2:2 [kernel.kallsyms] [k] xhci_hub_control ▒ + 7.80% 7.80%kworker/0:1 [kernel.kallsyms] [k] xhci_hub_control ▒ + 1.08% 1.08%kworker/2:2 [kernel.kallsyms] [k] __switch_to ▒ + 0.99% 0.99%kworker/0:1 [kernel.kallsyms] [k] __switch_to ▒ + 0.84% 0.84% khubd [kernel.kallsyms] [k] _raw_spin_lock_i I'm going to try linux-image-3.17-rc5-amd64. -- Package-specific info: ** Version: Linux version 3.16-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-11) ) #1 SMP Debian 3.16.3-2 (2014-09-20) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16-2-amd64 root=UUID=5065a2f9-ec31-4a10-8992-ccda124f2d26 ro ** Not tainted ** Kernel log: [217163.906374] cfg80211: World regulatory domain updated: [217163.906377] cfg80211: DFS Master region: unset [217163.906378] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [217163.906380] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [217163.906382] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [217163.906383] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [217163.906384] cfg80211: (517 KHz - 525 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [217163.906385] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [217163.906386] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) [217164.084725] wlan0: send auth to 6c:99:89:99:1a:af (try 2/3) [217164.086361] wlan0: authenticated [217164.088728] wlan0: associate with 6c:99:89:99:1a:af (try 1/3) [217164.091941] wlan0: RX AssocResp from 6c:99:89:99:1a:af (capab=0x11 status=0 aid=1) [217164.092041] wlan0: associated [217164.092113] cfg80211: Calling CRDA for country: AU [217164.096299] ath: EEPROM regdomain: 0x8024 [217164.096304] ath: EEPROM indicates we should expect a country code [217164.096307] ath: doing EEPROM country-regdmn map search [217164.096309] ath: country maps to regdmn code: 0x21 [217164.096311] ath: Country alpha2 being used: AU [217164.096313] ath: Regpair used: 0x21 [217164.096316] ath: regdomain 0x8024 dynamically updated by country IE [217164.096352] cfg80211: Regulatory domain changed to country: AU [217164.096355] cfg80211: DFS Master region: unset [217164.096358] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [217164.096362] cfg80211: (2402000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [217164.096366] cfg80211: (517 KHz - 525 KHz @ 8 KHz), (N/A, 1700 mBm), (N/A) [217164.096369] cfg80211: (525 KHz - 533 KHz @ 8 KHz), (N/A, 2400 mBm), (0 s) [217164.096372] cfg80211: (549 KHz - 571 KHz @ 8 KHz), (N/A, 2400 mBm), (0 s) [217164.096375] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 3000 mBm), (N/A) [217387.136173] wlan0: authenticate with 6c:99:89:a7:93:40 [217387.142728] wlan0: send auth to 6c:99:89:a7:93:40 (try 1/3) [217387.142791] cfg80211: Calling CRDA to update world regulatory domain [217387.148750] wlan0: authenticated [217387.152178] wlan0: associate with 6c:99:89:a7:93:40 (try 1/3) [217387.157918] wlan0: RX AssocResp from 6c:99:89:a7:93:40 (capab=0x431 status=0 aid=4) [217387.158006] wlan0: associated [217387.158160] cfg80211: Calling CRDA to update world regulatory domain [217387.165481] cfg80211: World regulatory domain updated: [217387.165484] cfg80211: DFS Master region: unset [217387.165485] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [217387.165487] cfg80211: (2402000
Bug#765440: python-deap-doc and deap-doc: error when trying to install together
Thanks for reporting the bug, but the background is simply that the documentation package of Deap has been renamed. Therefore, please just remove python-deap-doc first and deap-doc should install w/o errors. The new package has been uploaded yesterday, today I'll take care that the old package gets removed out of the system. I leave this bug open for a couple of days for when other users face that problem, too, but I'll adjust it. Greetings, Daniel Stender -- http://qa.debian.org/developer.php?login=debian%40danielstender.com PGP key: 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765174: [PATCH] Don't call modperl_threaded_mpm() et al. from XS code
r594345 (and later r1241983 and r1245916, all merged into trunk with
r1602105) modified modperl_trace() to call functions that are provided
by mod_perl.c. However, the same code is compiled into the APR XS module
without mod_perl.o linkage, so we end up with missing symbols in APR.so.
% objdump -T blib/arch/auto/APR/APR.so|grep UND|grep modperl
D *UND* modperl_is_running
D *UND*
modperl_threaded_mpm
D *UND*
modperl_threads_started
For the most part these missing symbols don't matter when modperl_trace()
doesn't actually get called, but CPAN modules like Apache-Gallery that
use APR and run their suites with PERL_DL_NONLAZY=1 now fail their tests
because of this.
Guard the problematic invocations with #ifndef MP_IN_XS, which is
defined for the XS module builds.
Bug-Debian: https://bugs.debian.org/765174
---
src/modules/perl/modperl_common_log.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/modules/perl/modperl_common_log.c
b/src/modules/perl/modperl_common_log.c
index 3335257..3bdb359 100644
--- a/src/modules/perl/modperl_common_log.c
+++ b/src/modules/perl/modperl_common_log.c
@@ -53,6 +53,7 @@ void modperl_trace(const char *func, const char *fmt, ...)
http://apr.apache.org/docs/apr/1.4/group__apr__lib.html#gad2cd3594aeaafd45931d1034965f48c1
*/
+#ifndef MP_IN_XS
/* PERL_GET_CONTEXT yields nonsense until the first interpreter is
* created. Hence the modperl_is_running() question. */
if (modperl_threaded_mpm()) {
@@ -77,6 +78,7 @@ void modperl_trace(const char *func, const char *fmt, ...)
apr_file_printf(logfile, [pid=%lu] , (unsigned long)getpid());
#endif
}
+#endif
if (func *func) {
apr_file_printf(logfile, %s: , func);
--
2.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#765065: [Pkg-ltsp-devel] Bug#765065: Bug#765065: ltsp-client-core: fails to stop some unneeded services on thin clients anymore
[Petter Reinholdtsen]
I am currently testing a function like this in our
/usr/share/ltsp/init-ltsp.d/60-edu-client file, which might address
some of your questions:
That approach did not work, because /run/systemd/system is not yet
created when the init-ltsp.d scripts are executed. This on the other
hand do work:
if grep -q systemd /sbin/init ; then
BOOTSYSTEM=systemd
else
BOOTSYSTEM=sysvinit
fi
service_disable() {
service=$1
if [ systemd = $BOOTSYSTEM ] \
[ -f /lib/systemd/system/${service}.service ] ; then
systemctl disable ${service}.service
else
update-rc.d $service disable || true
fi
}
--
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#762706: i915: blank screen on resume, logs 'failed to enable link training'
Package: src:linux Followup-For: Bug #762706 I'm currently trying out version 3.17-rc5 from experimental, and the problem does not seem to occur there. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17-rc5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711966: X lockup on ThickPad T530
On Tue, Oct 14, 2014 at 08:36:54 -0500, Dustin wrote: Package: xorg Version: 1:7.7+3~deb7u1 Followup-For: Bug #711966 Dear Maintainer, * What led up to the situation? I can fairly easily reproduce the bug by playing minetest on my debian wheezy system (CPU intensive, some graphics). It's important to note that my issue occurred on an Acer Aspire laptop. * What exactly did you do (or not do) that was effective (or ineffective)? I have not determined a way to reduce the severity of the issue. Once Xorg has locked up in this way, I perform the SysRq trick to kill the system. The problem is that any unsaved changes would be lost when the issue is encountered. Please file your own bug for your own issue. Thanks, Julien signature.asc Description: Digital signature
Bug#765370: xutils-dev: fix CCOPTIONS/LDOPTIONS causing FTBFS on sciplot on ppc64el [PATCH]
Control: tag -1 moreinfo On Tue, Oct 14, 2014 at 11:13:53 -0300, Mauricio Faria de Oliveira wrote: Package: src:xutils-dev Version: 1:7.7+3 Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el The attached patch adds the ppc64el pieces and fixes a FTBFS on sciplot (and potentially others), avoiding to pass -mminimal-toc from CCOPTIONS to LDOPTIONS (because it's incorrect for 'ld -mvalue'). May you please consider it for an upload? The 'add ppc64el support' patch seems to make the other one unnecessary, since -mminimal-toc is only added for ppc64architecture, which wouldn't apply to ppc64el? Am I missing something? Also, have any of these patches been sent upstream? Cheers, Julien signature.asc Description: Digital signature
Bug#672847: ITP: python-nbxmpp -- Non blocking Jabber/XMPP module
package wnpp retitle 672847 ITP: python-nbxmpp -- Non blocking Jabber/XMPP module owner 672847 Tanguy Ortolo tanguy+deb...@ortolo.eu thanks This library was part of gajim and was separated from it, so it is now necessary for newer versions of gajim. Too bad I was not noticed of that earlier. Librement, -- ,--. : /` ) ن Tanguy Ortoloxmpp:tan...@ortolo.eu | `-'Debian Developer irc://irc.oftc.net/Tanguy \_ signature.asc Description: Digital signature
Bug#765451: New version 0.16 available
Package: gajim Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 (Just for tracking changes, since there are several packages involved) A new version of Gajim, 0.16, is available. Gajim used to come with its own XMPP library, which has now been made a distinct project, python-nbxmpp, and will have to be packaged, see ITP #672847. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJUPjSQAAoJEOryzVHFAGgZQb0P/A8VVQqHeNaiO7heW5IDVQdP ksGjaU1oC+R7cCbPTTWXDiDwf2c8PeOFHtYgq9sXpInfyNDxbr7C8HSyWEgrwvRj 7DrXxaXqg9lh4tsWKDRKZatEIb5uUblCGFbKY89ljIwi6rR8gmSrw5eG0hvhjpno fTu9IoggFR6tzDJSr43iKvy4Q2v4SvT+S8kfJwlY/Pb3SSDwoFX8+nn6SBL98oUW yYVL4FiGFM4Wos16/NzDCf7Fiiwlw2XqZrgeS6GxuqIUFCMIT5d1f2QgU+NOp1q9 OyMD00AiWqlfYHB9J/owk1XkK6ArYmLLzbm5f1IFHYjvf+tu7uT44COUm66fY/W0 xlVihtZ7k8on6dKNcnR4YmxeO+Euh7Cledh3bohtAKpjTjtcn110/DMOjskp75t3 8mGMepJ9BUAMx50ffJvu9ogI11OTB3gRewfFIO6nO+SWZQhpJOSp/xqfII9h00BZ nr5HxNE123OVVBF3uPTG0slOTCvG1lc9VYRuWRMLgDZbG8eKeWVF6XkkBZJb73rW VVY+YaNLeQmTDQdqW7FjrGW+eveCxSRgl3BT7csh0v916D+ElA2uI+mrLhkEVJfr A1Au8ju0hqgT63JRAEZzP/r2NUhNMOeKogadF1j66k12DEgS3bFGS3T690y7+sNN uGCkMO3kUkZXiRe3X5x1 =2CbC -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#765452: debian-security-support: implement possibility to exclude specific binary packages from security support
Package: debian-security-support Version: 2014.09.11~deb6u1 Severity: wishlist As we recently discussed on debian-lts, it would be nice if you could add the possibility to warn users that some specific binary packages have no security support (i.e. a given subset of a source package is not supported, but the other binary packages are supported). -- System Information: Debian Release: jessie/sid APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 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 debian-security-support depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii gettext-base 0.19.2-3 debian-security-support recommends no packages. debian-security-support suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757247: phatch: pillow (2.6.0~rc1-1) already contains the proposed patch
On Wed, Oct 15, 2014 at 10:59:24AM +0300, Martin-Éric Racine wrote: However, there's a catch: Phatch has already been removed from Testing as a result of this bug and would need to be re-introduced. That should happen automatically now there are no longer RC bugs open against it. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765410: [Pkg-zsh-devel] Bug#765410: ulimit broken if it fails once
Control: tag -1 + confirmed upstream Control: retitle -1 zsh: ulimit broken as root if it fails once Control: found -1 4.3.17-1 Control: found -1 5.0.6-3 Control: found -1 4.3.10-14 Hi Goswin, thanks for the report. Goswin von Brederlow wrote: Package: zsh Version: 5.0.5-2 JFTR: That version is no more anywhere in Debian. Testing has 5.0.6-3. root@frosties:~# ulimit -n 1000 root@frosties:~# ulimit -n 1000 limit: setrlimit failed: operation not permitted root@frosties:~# ulimit -n 1000 limit: setrlimit failed: operation not permitted Once setting a limit with ulimit fails all further attempts to set a limit will also fail. But only in zsh. Works fine in bash. Interestingly this only happens if zsh is used as root. It does not happen if zsh is used as non-root user. Retitling accordingly. I've found this behaviour in at least Squeeze, Wheezy and Testing/Sid. Will test Experimental later today, too. If I find it there, too, I'll forward it to upstream. 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#765453: [wide-dhcpv6-client] Does not have a cooldown period on retries
Package: wide-dhcpv6-client Severity: normal In some situations it will retry multiple times per second. One such case caused the upstream to block the client as a source of UDP flood. See the log attached. Oct 15 07:37:55 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:37:55 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:37:55 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:37:55 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:37:55 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15 07:37:55 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0 Oct 15 07:37:55 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=125, retrans=127152 Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:37:58 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:37:58 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15 07:37:58 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0 Oct 15 07:37:58 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=124, retrans=116796 Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:37:58 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:37:58 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15 07:37:58 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0 Oct 15 07:37:58 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=125, retrans=123816 Oct 15 07:38:01 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:38:01 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:38:01 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:38:01 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:38:01 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15 07:38:01 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0 Oct 15 07:38:01 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=125, retrans=108048 Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15 07:38:02 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0 Oct 15 07:38:02 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=125, retrans=109668 Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15 07:38:02 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0 Oct 15 07:38:02 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=124, retrans=131100 Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15 07:38:02 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0 Oct 15 07:38:02 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=125, retrans=112320 Oct 15 07:38:03 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:38:03 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:38:03 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:38:03 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:38:03 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15 07:38:03 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0 Oct 15 07:38:03 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, state=SOLICIT, timeo=125, retrans=117516 Oct 15 07:38:04 luka dhcp6c[2093]: copy_option: set client ID (len 10) Oct 15 07:38:04 luka dhcp6c[2093]: copyout_option: set identity association Oct 15 07:38:04 luka dhcp6c[2093]: copy_option: set rapid commit (len 0) Oct 15 07:38:04 luka dhcp6c[2093]: copy_option: set elapsed time (len 2) Oct 15 07:38:04 luka dhcp6c[2093]: copyout_option: set IA_PD Oct 15
Bug#765422: [pkg-cinnamon] Bug#765422: cinnamon-session: nm-applet started accidentally?
¡Hola Christoph! El 2014-10-15 a las 01:21 +0200, Christoph Anton Mitterer escribió: Not sure whether I got something wrong here,... cinnamon-session starts nm-applet: 4327 ?Ssl0:00 \_ cinnamon-session --session cinnamon 4364 ?Ss 0:00 \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session cinnamon-session-cinnamon 4385 ?Sl 0:16 \_ /usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/cinnamon-settings-daemon 4452 ?Sl 0:00 \_ /usr/bin/python /usr/bin/cinnamon-launcher 4460 ?Sl11:46 | \_ cinnamon --replace 4466 ?Sl 0:00 \_ /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 4467 ?Sl 0:05 \_ nm-applet ... but apparently, the NM applet in the panel works fine without the nm-applet process, so is this really needed? nm-applet is started in the cinnamon.session and in /etc/autostart/nm-applet.desktop, this last one is part of the network-manager-gnome package. The cinnamon network applet uses nm-connection-editor (and the provided polkit configuration), and as such it depends on the network-manager-gnome. Since we don't really need to launch nm-applet anymore we can remove it from the cinnamon session, but it will still be started by the desktop file. This last one can be overridden by a desktop file in the user's ~/.config/autostart/ that adds the line X-GNOME-Autostart-enabled=false (as it has the NoDisplay keyword it won't show in the Startup Programs cinnamon-settings). So, maybe we should request adding X-Cinnamon to the NotShowIn= entry of the /etc/xdg/autostart/nm-applet.desktop file. -- A computer scientist is someone who, when told to Go to Hell, sees the go to, rather than the destination, as harmful. Saludos /\/\ /\ `/ signature.asc Description: Digital signature
Bug#765454: debian-security-support: Please mark binary package glassfish-appserv as not supported in squeeze
Package: debian-security-support Version: 2014.09.11~deb6u1 Severity: normal Control: block -1 by 765452 As discussed in https://lists.debian.org/debian-lts/2014/09/msg00036.html and subsequent messages, please mark the binary package glassfish-appserv as not security supported in Squeeze. I'm ccing the security team to ask them if they want to same for Wheezy (I believe it would be honest to do the same). Cheers, -- System Information: Debian Release: jessie/sid APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 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 debian-security-support depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii gettext-base 0.19.2-3 debian-security-support recommends no packages. debian-security-support suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765230: [Debichem-devel] Bug#765230: libghemical: run dh-autoreconf to update for new architectures
Hi On 13 October 2014 23:20, Wookey woo...@debian.org wrote: The problem appears to be out of date autoconf files (config.sub and guess). It is one of many packages which need autoconf updates in order to build on new architectures (such as arm64, mips64el, ppc64el and or1k). 'Autoreconf'ing is the recommended way to deal with this problem in Debian, as it works now and in the future, and ensures packages remain buildable from source. This page ( https://wiki.debian.org/Autoreconf ) contains information on this issue, and details for maintainers on how to update your packages: I'm happy to prepare an upload to fix this and bug #722162, but I'll need someone to sponsor it. Regards Graham -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732035: [Pkg-xfce-devel] Bug#732035: (no subject)
El 14/10/14 a las 20:59, Yves-Alexis Perez escribió: On mar., 2014-10-14 at 17:04 +0200, jEsuSdA 8) wrote: I have same problem. Since glib update, Thunar (and SpaceFM) is not allowed to mount/unmount devices. Are you sure that's related to glib? What *exactly* did you upgrade? Also, could you use reportbug to follow up on this bug so we have an idea of what your system looks like? First I receive a message about org.freedesktop.udisk2 promt me to introduce the root pastword. I search and I found several articles talking about policykit and I update several related packages (mount, udisk2, policykit-1, gvfs, dbus, ...) and now Thunar only show me this message: Not authorized to perform operation. So, I don't know what happens. Something was working fine, suddently stop working. Imho, that's just another instance of #754850 but I might be wrong. What init system do you have? Regards, Here the solution I found: https://mail.xfce.org/pipermail/xfce/2014-October/033786.html It appears to be related with cgroups. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765451: Acknowledgement (New version 0.16 available)
package gajim block 765451 by 672847 thanks As indicated, this new version depends on a new package, for a library that used to be part of gajim. -- ,--. : /` ) ن Tanguy Ortoloxmpp:tan...@ortolo.eu | `-'Debian Developer irc://irc.oftc.net/Tanguy \_ signature.asc Description: Digital signature
Bug#732035: [Pkg-xfce-devel] Bug#732035: (no subject)
control: forcemerge -1 757348 On mer., 2014-10-15 at 11:06 +0200, jEsuSdA 8) wrote: El 14/10/14 a las 20:59, Yves-Alexis Perez escribió: Here the solution I found: https://mail.xfce.org/pipermail/xfce/2014-October/033786.html It appears to be related with cgroups. So that's definitely #754850 / #757348 Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#760227: fixed in librabbitmq 0.5.2-1
Hello! Same issue for 0.5.2-1 dh_install: librabbitmq-dev missing files (usr/lib/*/lib*.so), aborting On Wed, 17 Sep 2014 09:29:04 + Michael Fladischer fladischermich...@fladi.at fladischermich...@fladi.at wrote: Source: librabbitmq Source-Version: 0.5.2-1 We believe that the bug you reported is fixed in the latest version of librabbitmq, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 760...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Michael Fladischer fladischermich...@fladi.at fladischermich...@fladi.at (supplier of updated librabbitmq package)
Bug#765455: libmime-lite-perl: utf-8 encoded subject gains a space character on header line wrap
Package: libmime-lite-perl
Version: 3.030-2
Severity: normal
Hi,
i am seeing an interesting issue where a long utf-8 subject gains a
space at the wrap point - See the attached testcase:
Cluster: Gütersloh Route: Brockweg - Heidewaldstadion changed
Cluster: Gütersloh Route: Bielefelder Straße - Rheda - Bertelsmann
Hauptverwaltung changed
^
This space gets added - Here are the resulting Header lines from
libmime-lite-perl:
Subject: Cluster:=?UTF-8?B?IEfDvHRlcnNsb2ggUm91dGU=?=: Brockweg -
Heidewaldstadion changed
Subject: Cluster:=?UTF-8?B?IEfDvHRlcnNsb2ggUm91dGU=?=:
=?UTF-8?B?IEJpZWxlZmVsZGVyIFN0cmHDn2UgLSBSaGVkYSAt?=
Bertelsmann Hauptverwaltung changed
The display of the additional space is consistent in mutt and icedove so i
expect
it to be standard conform interpretation of the mime headers.
It seems when the line ends with a non encoded word (:) and starts with
an encoded word we take all except the very first space. RFC2047 has an
example of this only using a single space in front of the encoded word
(Page 10, Examples). Duplicate space suppression does only happen
between encoded words, not between unencoded and encoded words.
Flo
#!/usr/bin/perl -w
use strict;
use utf8;
use MIME::Lite;
use Encode;
my @subjects=(
'Cluster: Gütersloh Route: Brockweg - Heidewaldstadion changed',
'Cluster: Gütersloh Route: Bielefelder Straße - Rheda - Bertelsmann
Hauptverwaltung changed'
);
foreach my $subject ( @subjects ) {
my $msg = MIME::Lite-new(
From= 'testc...@zz.de',
To = 'flo',
Subject = encode('MIME-Header', $subject),
Type= 'multipart/mixed',
);
$msg-attach(
Type = text/plain; charset=UTF-8,
Data = Testcase,
);
$msg-send;
}
-- System Information:
Debian Release: 7.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-0.bpo.2-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
Versions of packages libmime-lite-perl depends on:
ii libemail-date-format-perl 1.002-1
ii libmailtools-perl 2.09-1
ii perl 5.14.2-21+deb7u1
Versions of packages libmime-lite-perl recommends:
ii libmime-types-perl 1.35-1
Versions of packages libmime-lite-perl suggests:
ii postfix [mail-transport-agent] 2.9.6-2
-- 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#765456: ogre-1.8: FTBFS on arm64
Source: ogre-1.8 Version: 1.8.0+dfsg1-7 It failed to build on arm64: http://buildd.debian.org/status/package.php?p=ogre-1.8suite=sid The error was: /«BUILDDIR»/ogre-1.8-1.8.0+dfsg1/OgreMain/include/OgreStringConverter.h: At global scope: /«BUILDDIR»/ogre-1.8-1.8.0+dfsg1/OgreMain/include/OgreStringConverter.h:116:23: error: 'static Ogre::String Ogre::StringConverter::toString(long unsigned int, short unsigned int, char, std::ios_base::fmtflags)' cannot be overloaded static String toString(unsigned long val, ^ /«BUILDDIR»/ogre-1.8-1.8.0+dfsg1/OgreMain/include/OgreStringConverter.h:112:23: error: with 'static Ogre::String Ogre::StringConverter::toString(size_t, short unsigned int, char, std::ios_base::fmtflags)' static String toString(size_t val, ^ This can be fixed by adding || defined(__aarch64__) to the end of line 136 in OgreMain/include/OgrePlatform.h. (There may also be a better way of recognising 64-bit platforms than listing all the ones we can think of!) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765440: deap-doc: please add Conflicts: python-deap-doc
Control: tags -1 pending The Conflicts which was missing is set up in 1.0.1-4 and python-deap-doc will be removed from Jessie. Greetings, Daniel Stender -- http://qa.debian.org/developer.php?login=debian%40danielstender.com PGP key: 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749485: Patch for #749485
It's rather trivial but the maintainer asked me to provide a patch
nonetheless since we got no reply from upstream. See attachment.
--
-- Andreas
:-)
--- postfwd-1.35/sbin/postfwd 2013-04-18 22:31:23.0 +0200
+++ postfwd-1.35-bug749485/sbin/postfwd 2014-10-15 11:25:21.712460389 +0200
@@ -1572,7 +1572,7 @@
my($index,$now,$mycmd,$myarg,$myline,%request) = @_;
my($myaction) = $default_action; my($stop) = 0;
my($ratetype,$ratecount,$ratetime,$ratecmd) = split /, $myarg, 4;
- my($rcount) = ( ($mycmd =~ /^size/) ? $request{size} : (($mycmd =~ /^rcpt/) ? $request{recipient_count} : 1 ) );
+ my($rcount) = ( ($mycmd =~ /^size/) ? ( $request{size} * ( $request{recipient_count} || 1 ) ) : (($mycmd =~ /^rcpt/) ? $request{recipient_count} : 1 ) );
if ($ratetype and $ratecount and $ratetime and $ratecmd and $rcount) {
my $crate = $Rules[$index]{$COMP_ID}.'+'.$ratecount.'_'.$ratetime;
if ( defined $request{$ratetype} ) {
Bug#765457: flashplugin-nonfree: update-flashplugin-nonfree downloads old version
Package: flashplugin-nonfree Version: 1:3.6 Severity: important Dear Maintainer, Running `update-flashplugin-nonfree --install` ends up fetching the old version of the plugin instead of an available new version. Currently, --status produces: Flash Player version installed on this system : 11.2.202.406 Flash Player version available on upstream site: 11.2.202.411 but running --install will happily fetch signatures for the .411 version, and afterwards (output with --verbose): downloading http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.406/install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum install_flash_player_11_linux.x86_64.tar.gz ... unpacking install_flash_player_11_linux.x86_64.tar.gz ... verifying checksum contents of install_flash_player_11_linux.x86_64.tar.gz ... moving libflashplayer.so to /usr/lib/flashplugin-nonfree ... setting permissions and ownership of /usr/lib/flashplugin-nonfree/libflashplayer.so ... Flash Player version: 11.2.202.406 This seems to have been going on for quite some time now. Manually putting the new version into the URI really leads to a viable download. -- Package-specific info: Debian version: jessie/sid Architecture: amd64 Package version: 1:3.6 Adobe Flash Player version: LNX 11,2,202,406 MD5 checksums: 87ccb674fbcf94739f82cc6089634623 /var/cache/flashplugin-nonfree/flashplayer11_b2_install_lin_64_080811.tar.gz 3d019a4f21fba27aa7309004ac77f81c /var/cache/flashplugin-nonfree/get-upstream-version.pl 72054dbbceabda51bce37137568e2a1b /var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz 4efd7f0a0041a26e6c148120bcc311bb /var/cache/flashplugin-nonfree/install_flash_player_11_linux_x86_64.tar.gz 9c0112403381e2f3080e9607f201dc31 /usr/lib/flashplugin-nonfree/libflashplayer.so Alternatives: flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. lrwxrwxrwx 1 root root 34 Sep 29 09:56 /usr/lib/mozilla/plugins/flash-mozilla.so - /etc/alternatives/flash-mozilla.so /usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to `/etc/alternatives/flash-mozilla.so' -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-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 Versions of packages flashplugin-nonfree depends on: ii binutils 2.24.90.20141014-1 ii ca-certificates20140927 ii debconf [debconf-2.0] 1.5.53 ii gnupg 1.4.18-4 ii libatk1.0-02.14.0-1 ii libcairo2 1.12.16-5 ii libcurl3-gnutls7.38.0-2 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-2 ii libgcc11:4.9.1-16 ii libglib2.0-0 2.42.0-2 ii libgtk2.0-02.24.25-1 ii libnspr4 2:4.10.7-1 ii libnss32:3.17.1-1 ii libpango1.0-0 1.36.8-2 ii libstdc++6 4.9.1-16 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxt6 1:1.1.4-1 ii wget 1.15-1+b1 flashplugin-nonfree recommends no packages. Versions of packages flashplugin-nonfree suggests: ii fonts-dejavu 2.34-1 pn halnone ii iceweasel 31.1.0esr-1 ii konqueror-nsplugins4:4.14.1-1 pn ttf-mscorefonts-installer none pn ttf-xfree86-nonfreenone -- 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#270890: [pkg-dhcp-devel] Bug#270890: bug status?
On Wed, Oct 15, 2014 at 04:03:05AM +, Mike wrote: Was there a resolution to this bug? Because the behavior still seems to be present according to the documentation in 4.2.2.dfsg.1-5+deb70u6, see Note well: in dhclient.conf(5). I don't see a public website of DHCP bugs where I could search for this. Yeah their RT instance isn't public. I just rummaged through my 2008 email and found the ISC bug number for the forwarded bug (I've now captured it in the BTS). They're usually pretty good about looping in our BTS on responses, so this one may have gone unresponded upstream. signature.asc Description: Digital signature
Bug#765458: apt: broken cdrom support, breaking installation from weekly ISO images
Package: apt Version: 1.0.9.2 Severity: serious Tags: d-i Justification: breaks d-i [ X-D-Cc: debian-boot@, please keep it in the loop when replying. ] Hi, we received several bug reports about weekly installation images being unable to find a kernel package to install on the freshly debootstrapped system. I've been able to replicate this issue with apt 1.9.0.2. Various checks performed within the /target chroot in the installer context include: - sources.list is containing a well-formed cdrom deb line; - moving this file away and running apt-cdrom add adds it back; - apt-get update fails to proceed, and no Packages file ends up under /var/lib/apt/lists/, which explains d-i's failure to find a kernel package to install. - downgrading apt, apt-utils, libapt-inst1.5, libapt-pkg4.12 to their 1.0.9.1 versions makes it possible to run apt-get update, even if its output isn't very encouraging (it's attached), and the expected Packages file pops up under /var/lib/apt/lists/; - since I don't want to screw up with apt's internal data under /var/lib/apt/, I can't confirm whether the output with downgraded *apt* packages is a result of various runs with the new and the old versions, or something else. I'll try to figure out whether 801745284905e7962aa77a9f37a6b4e7fcdc19d0 and/or d916e2a93b798e29d342e9498266767c5be8e2a5 are responsible for this, but the fact apt is pulled during debootstrap might make the debian-cd tweak for including local packages a bit less straightforward than usual. Mraw, KiBi. Ign cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie InRelease Ign cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie Release.gpg Ign cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie Release Ign cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie/main amd64 Packages/DiffIndex Err cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie/main amd64 Packages Err cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie/main amd64 Packages Err cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie/main amd64 Packages Err cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie/main amd64 Packages Ign cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie/main Translation-en Err cdrom://[Debian GNU/Linux 8.0 _Jessie_ - Unofficial amd64 NETINST Binary-1 20141015-09:12] jessie/main amd64 Packages Failed to stat - stat (2: No such file or directory) W: Failed to fetch copy:/var/lib/apt/lists/partial/Debian%20GNU_Linux%208.0%20%5fJessie%5f%20-%20Unofficial%20amd64%20NETINST%20Binary-1%2020141015-09:12_dists_jessie_main_binary-amd64_Packages Failed to stat - stat (2: No such file or directory) E: Some index files failed to download. They have been ignored, or old ones used instead.
Bug#765046: base-installer: Unable to find a kernel to install, installation not possible
Control: block -1 by 765458 Cyril Brulebois k...@debian.org (2014-10-13): Petter Reinholdtsen p...@hungry.com (2014-10-13): I was unable to find a bug about this already reported, so here we go. Not quite sure which package to report the bug against, so I start with base-installer. We see this problem in Debian Edu using our ISOs when trying to install Jessie, but it affect other ISOs too. Recent entries of apt's changelog contains bits about cdrom-related regressions. Might be worth investigating as a (not so) wild guess. See bug report mentioned above. Mraw, KiBi. signature.asc Description: Digital signature
Bug#765402: installation-reports: Incomplete testing images (kernel image missing)
Control: block -1 by 765458 Hello Helge! Helge Kreutzmann deb...@helgefjell.de (2014-10-14): Boot method: CD Image version: http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/, build date October 6th Date: Date and time of the install Machine: Lenovo Thinkpad G50 Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [ ] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[E] Install tasks: [ ] Install boot loader:[E] Overall install:[E] Comments/Problems: I first tried the netinst. It failed to log into my network (not a part of this bug; I have a restricted network setup and I did not take the time to investigate yet) but I continued the install, however, I was informed that no kernel could be installed. Therefore I aborted the installation. Then I downloaded the -kde version of the installer. It showed the following errors: a) Again, no kernel could be installed. I had to manually (via USB stick) transfer the kernel*deb onto the machine and install it by hand (interestingly, most of the dependencies were available on the CD). This is quite certainly #765458. b) I installed an fully encrypted system. However, neither the package cryptsetup nor the package lvm was installed, thus the installed system failed in the initrd with strange errors that the root file system could not be found. This might be the same issue, I'll try to test this setup if I manage to debug apt further. c) I had selected German during the installation, however, KDE is presenting itself in English. I'd suggest tracking this issue separately. While c) is a minor problem, I regard a) and b) as show stopper. ACK. Many thanks for the detailed report. Mraw, KiBi. signature.asc Description: Digital signature
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
I have uploaded a new version of the package to mentors incorporating the changes mentioned below. There is one remaining blocker for this package entering Debian: The libu2f-host0 package is not yet in Debian. I'd love for you two to put your review cycles into it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764262 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764460 Re icons, larger non-XPM ones (including SVG) should be installed in /usr/share/icons/hicolor/widthxheight/apps: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout Thanks -- we are trying to sort this out, either we do something in the Debian packaging or we do it upstream -- but the latter requires some thinking since the package is cross-platform (Windows, Mac, GNU). Some other things you might want to fix: I like to wrap debian/*.menu files at one attribute per line to make diffs more readable. Agreed, done. I like to run wrap-and-sort -sa to wrap the other debian/* files in the same way for the same reason. Didn't know about that tool, thanks for pointer. Ran it without -s though. I think the Priority should be optional rather than extra. Done. I would recommend debian/compat 9 and debhelper 9. Done. The license for neoman/libloader.py seems to be BSD-3-clause not BSD-2-clause? Done. The multiarch handling in neoman/libloader.py is incorrect, it should not hard-code the paths for amd64 and i386, Debian has other 64-bit and 32-bit ports plus the non-Linux ports. The neoman/libloader.py looks at /etc/ld.so.conf but that won't work on multi-arch systems becase /etc/ld.so.conf just includes /etc/ld.so.conf/*.conf and contains no dirs. No idea how to resolve this -- I suppose libloader.py is some external file we copie in, maybe there are Debian-ified versions of it. Dain? Not sure why this package have to hardcode or read ld.so.conf at all. The manual page, desktop file and icon(s) should be installed by the upstream build system. PNG might be a better choice for the icons since it provides 8-bit transparency instead of 1-bit transparency. They seem to be PNG's in 0.2.3. Dain, can you install them? These files look like they were generated from other files, I would suggest removing them from the VCS and tarballs and creating them at build time if possible: resources/installer_bg.png resources/neoman.icns resources/neoman.ico resources/neoman.xpm debian/neoman.xpm neoman/neoman.png It is common to ship generated files in tarballs, to avoid forcing users to have a lot of tools available. Agree with removing them from git though, Dain? DEFAULT_KEY does not look like something that should be included? Why not? Earlier NEOs had that key as the default (it is the common Visa/Mastercard standard key), although modern NEOs have randomized keys. Are the files listed in neoman/appletdb.json Free Software? Are they required for operation of yubikey-neo-manager? ykneo-oath and ykneo-openpgp are free software, but they are not required for operation and most people will not want or need them. The upstream signing key uses SHA1 for the self-sig, it should be re-signed with a SHA512 self-sig: https://help.riseup.net/en/security/message-security/openpgp/best-practices#self-signatures-should-not-use-sha1 Leave this to Dain :-) uscan doesn't like the upstream signing key unless I move it to debian/upstream/signing-key.asc (see below). Dain? The cowbuilder parts of debian/README.source do not look necessary, lots of folks use sbuild and the cowbuilder docs cover what is mentioned in debian/README.source. Yeah, it is mostly an example and reminder for the people working with the packaging. os.system (in release.py) should be replaced by use of the subprocess module (with shell=False). Upstream issue -- Dain? Automated checks: Nice, will take a further looks later. /Simon https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git $ lintian W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/icon-about.png W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/icon_installed.png W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/icon_not_installed.png W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/icon_some_installed.png W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/neoman.png E: yubikey-neo-manager: menu-icon-too-big usr/share/pixmaps/neoman.xpm: 128x128 32x32 $ uscan --download-current-version --verbose --destdir . ... -- Verifying OpenPGP signature yubikey-neo-manager-0.2.2.tar.gz.pgp for yubikey-neo-manager-0.2.2.tar.gz gpgv: Signature made Fri 26 Sep 2014 19:52:37 AWST using RSA key ID 6FBA95E8 gpgv: [don't know]: invalid
Bug#765068: w3m: Misleading Option String for Cookies
Hi Markus, On October 13, 2014 at 11:22AM +0200, markus.hiereth (at freenet.de) wrote: #define CMT_COOKIE_AVOID_WONG_NUMBER_OF_DOTS N_(Domains to avoid [wrong number of dots]) Therefore, please consider the following msgid #define CMT_COOKIE_AVOID_WONG_NUMBER_OF_DOTS N_(Do not reject cookies having the domain attributes) How about Domains to avoid error of [wrong number of dots]? I'd like to use the Domains to ... style like other options. Any ideas? Thanks, -- Tatsuya Kinoshita pgpaGMnAtEjzF.pgp Description: PGP signature
Bug#764683: Bugreport installation-reports
Control: block -1 by 765458 Hi Janek! janek.kroe...@landkreis.lueneburg.de janek.kroe...@landkreis.lueneburg.de (2014-10-10): Boot method: netinstall.iso on USB-Stick Image version: http://caesar.acc.umu.se/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso Comments/Problems: It's not possible to install the kernel. The installer says, that no linux kernel could found in the apt-sources. After these step the installer request me to choose my favorite apt-mirror. I think these step should be before the search for a compatible kernel. I've tracked this down to apt: https://bugs.debian.org/765458 In the meanwhile, the D-I Jessie Beta 2 release should just work, please file a new bug report if it doesn't! More information on our website: https://www.debian.org/devel/debian-installer/ Mraw, KiBi. signature.asc Description: Digital signature
Bug#760434: [Pkg-amule-devel] Bug#760434: amule: unusable GUI
Hello Olly, On Sat, Sep 13, 2014 at 5:10 PM, Olly Betts o...@survex.com wrote: There are two big changes between 2.3.1-11 and 2.3.1+git1a369e47-1 - one of them is indeed the switch to wx3.0, but the other is a switch to an upstream git snapshot of amule. the switch to the git snapshot was done because it seemed to include supports to wx3.0 in the unreleased code. I think it would be prudent to rebuild 2.3.1+git1a369e47-1 against wx2.8 and test if that has similar issues before blaming wx3.0 for these problems. While they could be related to wx3.0, I've not seen such issues in any other packages. Also, upstream's response to the forwarded ticket might be more useful if you could show it happens with wx2.8 too. I tried rebuilding 2.3.1+git1a369e47-1 with wx2.8 myself, but I couldn't trigger this behaviour from either the package in sid or my rebuilt version (I tried switching between tabs over and over as described above), so that's rather inconclusive. I wasn't connected to any networks though, so that's perhaps why it didn't manifest. I noticed wx upstream has applied a fix for the wxExecuteData issue (http://trac.wxwidgets.org/ticket/16325) - I can apply that to the wxwidgets3.0 package if you'd prefer to try updating 2.3.1-11 to work with wx3.0. Is there any chance you can give us a hand in fixing amule to support wx3.0? Upstream has only partially ported the code to it, and they are not actively working on it atm. IT would be a shame to ship Jessie without amule, but i dont have the resources to port amule to wx. I can consider getting back to 2.3.1-11 instead of the git snapshot if that makes the effort easier. Thanks Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764995: Package: installation-reports
Control: block -1 by 765458 Sergio Martinelli sem.ar...@gmail.com (2014-10-12): Package: installation-reports Boot method: USB 4GB key Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso Date: 12-october-2014 21:55 graphical installer works, loads and start configurating everything. When to install base system it blocks after downloading many files asking me if i want to install the system without kernel, I do not know how to install a kernel later, so i cannot complete the installation. […] Hi Sergio, and thanks for your report. I've managed to track this down to apt: https://bugs.debian.org/765458 In the meanwhile, the D-I Jessie Beta 2 release should just work. Please file a new bug report if it doesn't! More information on our website: https://www.debian.org/devel/debian-installer/ Mraw, KiBi. signature.asc Description: Digital signature
Bug#763426: installation-report: installed system not bootable by default
Andreas Glaeser bugs.andreas.glae...@freenet.de (2014-10-02): On Tue, 30 Sep 2014 12:17:52 +0200 Cyril Brulebois k...@debian.org wrote: Andreas Glaeser bugs.andreas.glae...@freenet.de (2014-09-30): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: installation-reports Version: 2.57 Severity: normal Dear Maintainer, The installed system was not bootable upon installation, but grub could be installed manually: […] Can you please share the installer syslog? (/var/log/installer) Thanks. I suspect this part isn't helping: | Sep 30 06:44:47 grub-installer: info: Installing grub on '' Unfortunately I'm lacking time to investigate this further (at least right now). Mraw, KiBi. signature.asc Description: Digital signature
Bug#765458: apt: broken cdrom support, breaking installation from weekly ISO images
On Wed, Oct 15, 2014 at 11:47:44AM +0200, Cyril Brulebois wrote: Package: apt Version: 1.0.9.2 Severity: serious Tags: d-i Justification: breaks d-i [ X-D-Cc: debian-boot@, please keep it in the loop when replying. ] Hi, we received several bug reports about weekly installation images being unable to find a kernel package to install on the freshly debootstrapped system. I've been able to replicate this issue with apt 1.9.0.2. Various checks performed within the /target chroot in the installer context include: (The following is just a comment about the state of cdrom support, it does not help with this specific issue) Bugs with the CD-ROM part of APT pop-up a lot because there is nobody in the team actually using it, and most users are not using it either. For most users, the only time they use the cdrom code is when installing, and then never again. It's a sad state to be in. It would be a good idea to improve the testing of optical media, but I'm not really sure if that's possible. Possibly with virtual machines? -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 Netiquette. - If you don't I might ignore you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765459: nfswatch: console app unusable because of nfs3_count debug output
Package: nfswatch Version: 4.99.11-3 Severity: important Hi. I tried to use nfswatch to get an overview of the NFS traffic, but the screen is filled with messages looking simliar to this: nfs3_count: length is 0024, proc s 1 01000701 02f00700 nfs3_count: length is ... and so on and so forth. This is scrolling over the screen so quickly that it is almost impossible to read the text. Is this some runaway debug message that could be supressed? Btw, running nfswatch under valgrind note that a call to the bind() system call is used with uninitialized bytes. Perhaps something to look at? Setting severity to important, as this make the program almost useless. -- 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#765460: gnome-shell-extensions: apps-menu extension not working after upgrade to 3.14
Package: gnome-shell-extensions Version: 3.14.0-2 Severity: normal Dear Maintainer, Some days ago my testing laptop was upgraded to gnome-shell 3.14 (and extensions package too) and the apps-menu extension appeared in error state. After restarting the shell with the replace argument: $ gnome-shell --replace I understood that the extension did not work because the GMenu package was missing. As soon as I installed the following package: # apt-get install gir1.2-gmenu-3.0 The shell loaded the extension correctly. I suppose that some dependency is broken (I do not know what was the status of this package before the upgrade). Thanks in advance! -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-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 Versions of packages gnome-shell-extensions depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii gir1.2-gtop-2.0 2.28.5-2 ii gnome-session3.14.0-2 ii gnome-shell 3.14.0-1 ii gvfs 1.22.0-1+b1 Versions of packages gnome-shell-extensions recommends: ii gnome-tweak-tool 3.14.0-1 gnome-shell-extensions 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#764357: non-free file in package
Hi, How about editdist.c in py-editdist (edit distance imlementation for Python but the core is implemented in C) as a replacement of non-free edit_dist.c? It looks this file (and py-editdist) is licensed under the ISC License (which is free) and looks okay. One thing to note is, it uses older version of license text (Permission to use, copy, modify, and; latest version uses and/or for the clarification of the license). I think there is an option to ask the author for license. Thanks, Tsukasa OI -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765461: RM: ygraph -- RoQA; orphaned, FTBFS, not in testing
Package: ftp.debian.org Severity: normal Hi, Please remove ygraph from sid. It was orphaned in 2012, is not in testing, and fails to build everywhere because of an old build-dependency on libtiff4-dev. jmw@franck:~$ dak rm -Rn ygraph Will remove the following packages from unstable: ygraph | 0.16~cvs20090218-1.2 | source ygraph | 0.16~cvs20090218-1.2+b1 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc Maintainer: Daniel Kobras kob...@debian.org --- Reason --- -- Checking reverse dependencies... No dependency problem found. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765458: apt: broken cdrom support, breaking installation from weekly ISO images
Julian Andres Klode j...@debian.org (2014-10-15):
(The following is just a comment about the state of cdrom support, it
does not help with this specific issue)
No worries, that's appreciated, even if I had already gathered that from
other issues earlier this {year,release cycle}.
Bugs with the CD-ROM part of APT pop-up a lot because there is nobody in
the team actually using it, and most users are not using it either. For
most users, the only time they use the cdrom code is when installing, and
then never again. It's a sad state to be in.
It would be a good idea to improve the testing of optical media, but I'm
not really sure if that's possible. Possibly with virtual machines?
There are some d-i tests running on jenkins.debian.net:
https://jenkins.debian.net/view/g-i-installation/
but problems aren't necessarily spotted or reported immediately.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#659810: udev-discover: uninstallable on kfreebsd-*
Control: tags -1 + patch
--- debian/control.orig 2012-01-16 17:23:51.0 +
+++ debian/control 2014-10-15 11:28:02.919734418 +0100
@@ -8,7 +8,7 @@
X-Python-Version: =2.7
Package: udev-discover
-Architecture: any
+Architecture: linux-any
Depends: ${misc:Depends}, ${python:Depends}, python-gconf, python-gudev,
python-gobject, gir1.2-gtk-3.0, gir1.2-gconf-2.0, gir1.2-gdkpixbuf-2.0,
gnome-icon-theme-full | gnome-icon-theme-extras
Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764943:
Dear Maintainer, I can confirm this bug and it is quite a blocker. Good thing this seems to be a duplicate of #762810 762...@bugs.debian.org where also a patch is attached. Best regards, Michael
Bug#765431: open-iscsi: umountiscsi.sh script does not properly check while traverse sysfs structure
Hello Dmitry, Thank you for the patch. Since I do not have an iscsi setup handy with me right now, I'm gonna depend on you for some questions. On Wednesday 15 October 2014 08:31 AM, Dmitry Danilov wrote: for BLOCK_FILE in $SESSION_DIR/target*/*\:*/block/*; do + if ! [ -d $BLOCK_FILE ]; then + continue + fi I named the variable BLOCK_FILE. From what I'm guessing, it'd give us the file names type block. No ?? -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Bug#765110: start-stop-daemon: no longer creates a PID file
Am 13.10.2014 um 20:28 schrieb Guillem Jover: This is certainly a regression in s-s-d. It does still create a pidfile when using --background. I do have to wonder why the init script is not using --background though, because otherwise any error from it will not be noticed at all by the shell, because it detaches the process itself. I'm fixing this for 1.17.19, but I'd advise to switch to use --background anyway. We had to change to not use --background because otherwise the error messages of sks would get redirected to /dev/null. (See bug #651843) Putting some garbage into /etc/sks/sksconf: # start-stop-daemon --start --oknodo --chuid debian-sks:debian-sks --exec /usr/sbin/sks -- db Fatal error: exception Not_found _mcleanup: gmon.out: Permission denied in contrast to # start-stop-daemon --start --oknodo --chuid debian-sks:debian-sks --background --exec /usr/sbin/sks -- db would ouput no message but fail to start. Christoph -- Christoph Martin, Zentrum für Datenverarbeitung, Uni-Mainz, Germany Anselm Franz von Bentzel-Weg 12, 55128 Mainz Telefon: +49(6131)3926337 Instant-Messaging: Jabber: mar...@uni-mainz.de (Siehe http://www.zdv.uni-mainz.de/4010.php) attachment: martin.vcf signature.asc Description: OpenPGP digital signature
Bug#765463: gdal-bin: GDAL and proj4 disagree on some co-ordinate transformations
Package: gdal-bin Version: 1.9.0-3.1 Severity: normal Hi, On stable Debian, with gdal-bin 1.9.0-3.1 and proj-bin 4.7.0-2, different results are returned for the same co-ordinate transformations: $ echo '-1.3893433684943819 52.7297093932173411' | cs2cs +init=epsg:4326 +to +init=epsg:27700 441335.00 314849.00 -48.92 $ testepsg -t epsg:4326 epsg:27700 -1.3893433684943819 52.7297093932173411 0 (-1.389343,52.729709,0.00) - (441334.824686,314851.829623,-47.495477) The results differ by a few metres. Looking at the internal definitions, we see the following (testepsg comes from gdal-bin, cs2cs from proj-bin): $ testepsg epsg:27700 ... +towgs84=375,-111,431,0,0,0,0 +units=m +no_defs ... $ cs2cs -v +init=epsg:27700 ... # +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894 ... The towgs84 parameters are different - a 7-parameter version with proj4, but a 3-parameter version with GDAL. I would have assumed that both packages both used the same underlying data (which I believe is libgeotiff) on the same system, but I assume different versions of the data are bundled inside one or both of these packages, leading to this issue. I tracked the libgeotiff change down to http://trac.osgeo.org/geotiff/changeset/2023/trunk/libgeotiff/csv/gcs.csv - though I would have thought the 7-parameter version was more accurate (not sure!)? Anyway, I'm not sure if this has a solution, but it took long enough to track down (PostgreSQL using proj4, Django using GDAL, so different results depending where the transformation takes place) that I thought I'd open a report for it in case anyone else came across the same issue. ATB, Matthew -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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/bash Versions of packages gdal-bin depends on: ii libarmadillo3 1:3.2.3+dfsg-1 ii libc6 2.13-38+deb7u4 ii libcurl3-gnutls7.26.0-1+wheezy10 ii libdap11 3.11.1-11 ii libdapclient3 3.11.1-11 ii libdapserver7 3.11.1-11 ii libepsilon00.9.1-2 ii libexpat1 2.1.0-1+deb7u1 ii libfreexl1 1.0.0b-1 ii libgcc11:4.7.2-5 ii libgdal1 1.9.0-3.1 ii libgeos-c1 3.3.3-1.1 ii libgif44.1.6-10 ii libhdf4-0-alt 4.2r4-13 ii libhdf5-7 [libhdf5-7] 1.8.8-9+b1 ii libjasper1 1.900.1-13 ii libjpeg8 8d-1+deb7u1 ii libkml01.3.0~r863-4.1 ii liblzma5 5.1.1alpha+20120614-2 ii libmysqlclient18 5.5.38-0+wheezy1 ii libnetcdfc71:4.1.3-6+b1 ii libodbc1 2.2.14p2-5 ii libogdi3.2 3.2.0~beta2-7 ii libpng12-0 1.2.49-1 ii libpoppler19 0.18.4-6 ii libpq5 9.1.13-0wheezy1 ii libproj0 4.7.0-2 ii libspatialite3 3.0.0~beta20110817-3+deb7u1 ii libsqlite3-0 3.7.13-1+deb7u1 ii libstdc++6 4.7.2-5 ii liburiparser1 0.7.5-1 ii libxerces-c28 2.8.0+deb1-3 ii odbcinst1debian2 2.2.14p2-5 ii unixodbc 2.2.14p2-5 ii zlib1g 1:1.2.7.dfsg-13 gdal-bin recommends no packages. Versions of packages gdal-bin suggests: ii python-gdal 1.9.0-3.1 -- 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#683848: bin-NMU support
Package: pbuilder
Followup-For: Bug #683848
Hi,
the patch lacks the binary-only=yes suffix in the changelog.
Also I think adding -m\$BINNMU_MAINTAINER\ to DEBBUILDOPTS is wrong -
-e\$BINNMU_MAINTAINER\ should be sufficient:
diff -Nru pbuilder-0.215+nmu3+0anbe0/pbuilder-modules
pbuilder-0.215+nmu3+0anbe1/pbuilder-modules
--- pbuilder-0.215+nmu3+0anbe0/pbuilder-modules 2014-10-15 07:16:02.0
+0200
+++ pbuilder-0.215+nmu3+0anbe1/pbuilder-modules 2014-10-15 12:02:27.0
+0200
@@ -637,8 +637,8 @@
echo No maintainer provided for binNMU entry, fall back to last
uploader.
BINNMU_MAINTAINER=$changedby
fi
-DEBBUILDOPTS=${DEBBUILDOPTS} -m\$BINNMU_MAINTAINER\
-e\$BINNMU_MAINTAINER\
-echo $package ($version+b$BINNMU_VERSION) $DISTRIBUTION; urgency=low
$cl
+DEBBUILDOPTS=${DEBBUILDOPTS} -e\$BINNMU_MAINTAINER\
+echo $package ($version+b$BINNMU_VERSION) $DISTRIBUTION; urgency=low,
binary-only=yes $cl
echo $cl
echo * Binary-only non-maintainer upload for $arch; no source changes.
$cl
echo * $BINNMU_MESSAGE $cl
That said, can't you use dch to generate the binary changelog?
This would simplify the changelog generation a lot ...
$CHROOTEXEC dch --bin-nmu -c $PATHTOCHANGELOG -D $DISTRIBUTION \
$MESSAGE
I have no idea how to pass a binnmu number != 1 to dch.
Also you cannot pass the maintainer as a command line option - need
environment variables instead, so maybe
$CHROOTEXEC env DEBEMAIL=$DEBEMAIL DEBFULLNAME=$DEBFULLNAME dch ...
which makes the --bin-nmu-maintainer option moot because I have to set
it to --bin-nmu-maintainer $DEBFULLNAME $DEBEMAIL anyway, so
pbuilder could just use the same variables as dch ...
I find the binnmu uploader = last uploader fallback not that useful ...
(experiences from preparing my very first binNMU (for a package not
uploaded by me before))
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765464: ftp.debian.org: Contact details and wiki page link to https://ftp-master.debian.org/
Package: ftp.debian.org Severity: wishlist Tags: patch Hi, Contact details and wiki links where not available on https://ftp-master.debian.org/ so I decided to add them. Patches attached. They are useful for casual users like me who are not so clear on internals workings of Debian and ftp master team. -Mikko From 00d226788dd978a6bc4eaf132d124412f529eecd Mon Sep 17 00:00:00 2001 From: Mikko Rapeli mikko.rap...@iki.fi Date: Wed, 15 Oct 2014 14:08:30 +0300 Subject: [PATCH 1/2] Added Contact details to web page Contact details copied from https://wiki.debian.org/Teams/FTPMaster Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi --- index.html |8 1 file changed, 8 insertions(+) diff --git a/index.html b/index.html index 75d3fbc..f03a4c6 100644 --- a/index.html +++ b/index.html @@ -55,6 +55,7 @@ lia href=#archivecriteriaArchive Criteria/a/li lia href=#talksTalks/a/li lia href=#patchesPatches/a/li + lia href=#contactContact/a/li /ul /div @@ -345,6 +346,13 @@ pregit clone https://ftp-master.debian.org/git/website.git//pre /div +div id=contact +h1Contact/h1 +pEmail contact: ftpmas...@debian.org/p +pRequest tracker: a href=http://bugs.debian.org/ftp.debian.org;http://bugs.debian.org/ftp.debian.org (pseudo package)/a/p +pPublic IRC channel: #debian-ftp on irc.debian.org (OFTC)/p +/div + /div /div /div -- 1.7.10.4 From 4db4b3c9f3b75c9f7ed3cb8afcd721dc415b484b Mon Sep 17 00:00:00 2001 From: Mikko Rapeli mikko.rap...@iki.fi Date: Wed, 15 Oct 2014 14:15:27 +0300 Subject: [PATCH 2/2] Add link to FTPMaster wiki page It has useful and maybe more up to date information so it's good to mention here too. Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi --- index.html |1 + 1 file changed, 1 insertion(+) diff --git a/index.html b/index.html index f03a4c6..5fdb09c 100644 --- a/index.html +++ b/index.html @@ -63,6 +63,7 @@ div id=intro pThis is the Debian project ftp-master server. Various informational pages are available here./p +pAdditional information is also available on a href=https://wiki.debian.org/Teams/FTPMaster;FTPMaster wiki page/a./p /div div id=archivekey -- 1.7.10.4
Bug#765465: encfs: FTBFS for mips/mipsel
Package: encfs
Version: 1.7.4-4
Tags: sid patch
Severity: important
User: debian-mips-dev-disc...@lists.alioth.debian.org
Usertags: mips-patch
Package encfs FTBFS for mips and mipsel with an error:
/bin/bash ../libtool --tag=CXX --mode=link g++ -DRLOG_COMPONENT=encfs
-I/usr/include -DLOCALEDIR=\/usr/share/locale\ -W -Wall -Wpointer-arith
-Wwrite-strings -g -O2 -Wformat -Werror=format-security -flto -flto -pthread
-version-info 6:1:0 -Wl,-z,relro -Wl,-z,now -flto -flto -o libencfs.la
-rpath /usr/lib readpassphrase.lo base64.lo ConfigReader.lo ConfigVar.lo
Context.lo Cipher.lo CipherKey.lo FileIO.lo RawFileIO.lo BlockFileIO.lo
CipherFileIO.lo MACFileIO.lo NameIO.lo StreamNameIO.lo BlockNameIO.lo
NullNameIO.lo Interface.lo MemoryPool.lo NullCipher.lo DirNode.lo FileNode.lo
FileUtils.lo openssl.lo autosprintf.lo SSL_Cipher.lo -lrlog -lssl -lcrypto
-lboost_serialization -lboost_filesystem -lboost_system
libtool: link: g++ -shared -nostdlib
/usr/lib/gcc/mipsel-linux-gnu/4.9/../../../mipsel-linux-gnu/crti.o
/usr/lib/gcc/mipsel-linux-gnu/4.9/crtbeginS.o .libs/readpassphrase.o
.libs/base64.o .libs/ConfigReader.o .libs/ConfigVar.o .libs/Context.o
.libs/Cipher.o .libs/CipherKey.o .libs/FileIO.o .libs/RawFileIO.o
.libs/BlockFileIO.o .libs/CipherFileIO.o .libs/MACFileIO.o .libs/NameIO.o
.libs/StreamNameIO.o .libs/BlockNameIO.o .libs/NullNameIO.o .libs/Interface.o
.libs/MemoryPool.o .libs/NullCipher.o .libs/DirNode.o .libs/FileNode.o
.libs/FileUtils.o .libs/openssl.o .libs/autosprintf.o .libs/SSL_Cipher.o
/usr/lib/librlog.so -lssl -lcrypto -lboost_serialization -lboost_filesystem
-lboost_system -L/usr/lib/gcc/mipsel-linux-gnu/4.9
-L/usr/lib/gcc/mipsel-linux-gnu/4.9/../../../mipsel-linux-gnu
-L/usr/lib/gcc/mipsel-linux-gnu/4.9/../../../../lib -L/lib/mipsel-linux-gnu
-L/lib/../lib -L/usr/lib/mipsel-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/mipsel-linux-gnu/4.9/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/mipsel-linux-gnu/4.9/crtendS.o
/usr/lib/gcc/mipsel-linux-gnu/4.9/../../../mipsel-linux-gnu/crtn.o -pthread
-Wl,-z -Wl,relro -Wl,-z -Wl,now -pthread -Wl,-soname -Wl,libencfs.so.6 -o
.libs/libencfs.so.6.0.1
/usr/bin/ld: /tmp/cck84z9f.ltrans0.ltrans.o: relocation R_MIPS_HI16 against
`__gnu_local_gp' can not be used when making a shared object; recompile with
-fPIC
/tmp/cck84z9f.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
The reason for this error is the fact that fPIC flag is used for compiling but
not for linking.
Patch that adds fPIC flag for linking is attached.
Whit this patch I was able to successfully build encfs
for mips, mipsel and amd64.
Could you please consider including this patch?
Best Regards,
Dejan
diff -uNr encfs-1.7.4.orig/configure encfs-1.7.4/configure
--- encfs-1.7.4.orig/configure 2010-11-18 08:11:06.0 +
+++ encfs-1.7.4/configure 2014-10-14 12:06:32.0 +
@@ -13584,8 +13584,8 @@
# Check if GNU C++ uses GNU ld as the underlying linker, since the
# archiving commands below assume that GNU ld is being used.
if test $with_gnu_ld = yes; then
-archive_cmds_CXX='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
-archive_expsym_cmds_CXX='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+archive_cmds_CXX='$CC -shared $pic_flag -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
+archive_expsym_cmds_CXX='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
hardcode_libdir_flag_spec_CXX='${wl}-rpath ${wl}$libdir'
export_dynamic_flag_spec_CXX='${wl}--export-dynamic'
diff -uNr encfs-1.7.4.orig/m4/libtool.m4 encfs-1.7.4/m4/libtool.m4
--- encfs-1.7.4.orig/m4/libtool.m4 2010-06-17 06:31:30.0 +
+++ encfs-1.7.4/m4/libtool.m4 2014-10-14 12:05:52.0 +
@@ -5523,8 +5523,8 @@
# Check if GNU C++ uses GNU ld as the underlying linker, since the
# archiving commands below assume that GNU ld is being used.
if test $with_gnu_ld = yes; then
-_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
-_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
+
Bug#765447: does not build twice in a row
On Wed, Oct 15, 2014 at 10:21:39AM +0200, Marc Haber wrote: Package: openvpn Severity: wishlist Hi, at least on wheezy, I cannot build unstable's current openvpn package twice in a row. debian/rules clean leaves a modified config.log and a modified tests/t_client.sh in place. It might be helpful to zap config.log in debian/rules clean and to make a backup of tests/t_client.sh and restore it in the clean target. I must admit that I didn't test whether this issue applies to building on unstable as well. Nope, it does not happen in unstable. What should we do with this bug then? -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765466: redmine: db:migrate fails on postinst wrong number of arguments (2 for 1)
Package: redmine Version: 3.0~20140825-1 Severity: important Hi Antonio, Ondrej, I'm running Redmine on a machine that has a default release of testing, but hadn't run dist-upgrade for some time (for instance the Apache 2.2 to 2.4 transition was in this). Redmine is running with Passenger, see http://foss.ulster.ac.uk/redmine/ It looks like, in retrospect, aspects of the dist-upgrade did not complete, but I upgraded from 1.4.4+dfsg1-3 to 3.0~20140825-1, but the problem has not resolved. In between this I was encountering errors out of gems missing, and used bundle install, having to install a number of libs (ruby-dev, libpg-dev, libmagick-dev) to do so. It is possible this has made a mess of something. All dist-upgrade stuff is now up to date, with the exception of a not-fully configured redmine package. Running rake db:migrate RAILS_ENV=production --trace provides the following output. root@foss:/usr/share/redmine# rake db:migrate RAILS_ENV=production --trace ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Invoke db:load_config (first_time) ** Execute db:load_config ** Execute db:migrate == 2013021541 PopulateIssuesClosedOn: migrating === rake aborted! StandardError: An error has occurred, this and all later migrations canceled: wrong number of arguments (2 for 1)/usr/lib/ruby/vendor_ruby/active_record/relation.rb:316:in `update_all' /usr/lib/ruby/vendor_ruby/active_record/querying.rb:8:in `update_all' /usr/share/redmine/db/migrate/2013021541_populate_issues_closed_on.rb:18:in `up' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:598:in `exec_migration' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:579:in `block (2 levels) in migrate' /usr/lib/ruby/2.1.0/benchmark.rb:279:in `measure' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:578:in `block in migrate' /usr/lib/ruby/vendor_ruby/active_record/connection_adapters/abstract/connection_pool.rb:294:in `with_connection' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:577:in `migrate' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:752:in `migrate' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:991:in `block in execute_migration_in_transaction' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:1037:in `block in ddl_transaction' /usr/lib/ruby/vendor_ruby/active_record/connection_adapters/abstract/database_statements.rb:201:in `block in transaction' /usr/lib/ruby/vendor_ruby/active_record/connection_adapters/abstract/database_statements.rb:209:in `within_new_transaction' /usr/lib/ruby/vendor_ruby/active_record/connection_adapters/abstract/database_statements.rb:201:in `transaction' /usr/lib/ruby/vendor_ruby/active_record/transactions.rb:208:in `transaction' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:1037:in `ddl_transaction' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:990:in `execute_migration_in_transaction' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:952:in `block in migrate' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:948:in `each' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:948:in `migrate' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:807:in `up' /usr/lib/ruby/vendor_ruby/active_record/migration.rb:785:in `migrate' /usr/lib/ruby/vendor_ruby/active_record/railties/databases.rake:34:in `block (2 levels) in top (required)' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/task.rb:240:in `call' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/task.rb:240:in `block in execute' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/task.rb:235:in `each' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/task.rb:235:in `execute' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain' /usr/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/task.rb:172:in `invoke_with_call_chain' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/task.rb:165:in `invoke' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:150:in `invoke_task' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:106:in `block (2 levels) in top_level' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:106:in `each' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:106:in `block in top_level' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:115:in `run_with_threads' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:100:in `top_level' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:78:in `block in run' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:176:in `standard_exception_handling' /var/lib/gems/2.1.0/gems/rake-10.3.2/lib/rake/application.rb:75:in `run' /var/lib/gems/2.1.0/gems/rake-10.3.2/bin/rake:33:in `top (required)' /usr/local/bin/rake:23:in `load' /usr/local/bin/rake:23:in `main' ArgumentError: wrong number of arguments (2 for 1)
Bug#765314: mrpt: FTBFS on all non-x86-based architectures
I would add a third patch to fix (avoid) errors in hurd. If you have the possibility of adding it it would be great! So, these are the 3 patches: https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19 https://github.com/jlblancoc/mrpt/commit/c81effd1228234e2ed17caf0ef22f0caee6b Can be downloaded as git diffs as well: https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f.diff https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19.diff https://github.com/jlblancoc/mrpt/commit/c81effd1228234e2ed17caf0ef22f0caee6b.diff Best, JL On Wed, Oct 15, 2014 at 9:14 AM, Jose Luis Blanco joseluisblan...@gmail.com wrote: Hi Olly, In theory, these patches should fix sparc (I think) s390x: - https://github.com/jlblancoc/mrpt/commit/693bebedac9234fa00304a26aa854f54dc4d674f -https://github.com/jlblancoc/mrpt/commit/bb294b9c7a9aef3b4bbbdc89811e7873805eba19 But couldn't test it locally. Would you please try to attach them as patches for a new version 1.2.2-1.2?? Best, JL On Wed, Oct 15, 2014 at 7:31 AM, Jose Luis Blanco joseluisblan...@gmail.com wrote: Any recommendation about how to test it locally on s390x? qemu or alike? A partner got it tested in a physical mips device before submitting, so hopefully it will work there... Thanks. On Wed, Oct 15, 2014 at 7:00 AM, Olly Betts o...@survex.com wrote: Still not building everywhere: https://buildd.debian.org/status/package.php?p=mrpt It's never built on ppc64el, so that won't block testing migration (but it would be good to sort out). The failure on sparc isn't a big problem, as sparc isn't a release arch for jessie. And armel, mips, and mipsel are yet to attempt a build of this version. But the failure on s390x needs sorting out if mrpt is to make jessie - failure is in the testsuite: [ RUN ] Synch.CriticalSections_Multi *** stack smashing detected ***: ./test_mrpt_base terminated For backtrace, etc see the tail end of: https://buildd.debian.org/status/fetch.php?pkg=mrptarch=s390xver=1%3A1.2.2-1.1stamp=1413289418 Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765467: asis-programs: Version mismatch between GNAT 4.9.1 vs. ASIS 4.9
Package: asis-programs Version: 2014-2 Severity: important Dear Maintainer, I have made the simplest possible test.ads containing package Test is pragma Pure; end Test; When invoking gnatpp test.ads I get GNAT 4.9.1 vs. ASIS 4.9: /home/software/truc/GNAT-MRiKOb/test.adt Possible installation problem When invoking gnatstub test.ads I get Unexpected bug in gnatsub - A4G.GNAT_INT.VERSION_MISMATCH was raised: GNAT 4.9.1 vs. ASIS 4.9: /home/software/truc/test.adt Please report to rep...@adacore.com When invoking gnatmetric test.ads I get GNAT 4.9.1 vs. ASIS 4.9: /home/software/truc/GNAT-hmap5x/test.adt Possible installation problem I suspect non of the ASIS programs can do anything usefull for the moment. It is probably not related to the problem but I am running a debootstrap version of jessie in a chroot environment. To have the most useful information in this bug report (see below). I have run reportbug in the same chroot environment. Best regards Henri GEIST -- 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/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages asis-programs depends on: ii gnat4.9 ii gnat-4.94.9.1-3 ii libasis2014 2014-2 ii libc6 2.19-11 ii libgcc1 1:4.9.1-16 ii libgnat-4.9 4.9.1-3 ii libgnatcoll1.6 1.6gpl2014-6 ii libgnatprj4.9 4.9.1-3 ii libgnatvsn4.9 4.9.1-3 Versions of packages asis-programs recommends: ii libaunit3.7.1-dev 3.7.1-1 asis-programs suggests no packages. -- debconf information: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = fr_FR.UTF-8 are supported and installed on your system. perl: warning: Falling back to the standard locale (C). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory signature.asc Description: This is a digitally signed message part
Bug#764692: dns-flood-detector: FTBFS on kfreebsd-*
clone 764692 -1 reassign -1 src:dns-flood-detector found -1 dns-flood-detector/1.20-2 tags -1 + patch thanks Hi, On 12/10/14 16:45, Steven Chamberlain wrote: glibc-provided features.h no longer defines a __FAVOR_BSD macro, so the BSD version of struct tcphdr in netinet/tcp.h cannot be used, [...] https://buildd.debian.org/status/fetch.php?pkg=dns-flood-detectorarch=kfreebsd-amd64ver=1.20-2stamp=1413149812 This problem with glibc 2.19 can be worked around in dns-flood-detector with the attached patch. (Although in the next release of glibc, it might no longer work, so maybe libbsd-dev could provide a suitable netinet/tcp.h someday) Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org --- debian/rules.orig 2014-10-12 20:01:04.0 +0100 +++ debian/rules 2014-10-15 12:35:53.128715139 +0100 @@ -11,7 +11,7 @@ CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) -CFLAGS += -D_BSD_SOURCE -Wall -g +CFLAGS += -D_BSD_SOURCE -D__FAVOR_BSD -Wall -g LDLIBS += -lpcap -lpthread -lm ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
Bug#765469: python3-tornado: get_secure_cookie get incorrect value by setting set_secure_cookie
Package: python3-tornado
Version: 3.2.2-1
Severity: critical
Justification: breaks unrelated software
Dear Maintainer,
class abc(tornado.web.RequestHandler):
def get(self):
(stat, user) = self.check_remember()
if stat:
do_action()
else:
self.clear_cookie('remember')
self.render('remember-post.html')
def post(self):
username = self.get_body_argument('username'):
if self.get_body_argument('remember'):
val = json.dumps({'username': username, 'time': time.time()})
self.set_secure_cookie('remember', value=val, expires_days=7)
def check_remember(self):
try:
remember_cookie = self.get_secure_cookie('remember', max_age_days=7)
except ValueError:
print('try get_cookie')
return False, ''
if remember_cookie is None:
return False, ''
try:
remember = json.loads(remember_cookie.decode())
except ValueError:
print('try json')
return False, ''
ret = (False, '')
if 'username' in remember and 'time' in remember:
if time.time() - remember['time'] 7 * 24 * 60 * 60:
self.clear_cookie('remember')
ret = (False, '')
else:
username = remember['username']
val = json.dumps({'username': username, 'time': time.time()})
self.set_secure_cookie('remember', value=val, expires_days=7)
ret = (True, username)
return ret
Always get an Exception ValueError in json.loads print try json and return
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages python3-tornado depends on:
ii ca-certificates 20140927
ii python3 3.4.2-1
python3-tornado recommends no packages.
python3-tornado 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#764357: non-free file in package
I can't directly contribute to ssdeep because I saw the non-free source code of edit_dist.c. So I decided to tweet this problem. After I tweeted this problem on Twitter (in Japanese), @kikairoya (who has not seen the source code of ssdeep and/or trn) wrote a program to compute ssdeep version of Levenshtein distance. He says he licenses the source code under the terms of Boost Software License, version 1.0 (compatible with GPLv2+). I didn't even tell him the interface for ssdeep so slight modification will be needed. https://gist.github.com/kikairoya/58f996c36210ffc31e79 Anyway, is there any reason to make replacement cost in the ssdeep version of edit_dist.c 3? I think a replacement will always have a cost of 2 (because this can be achieved by character removal and insertion). Thanks, Tsukasa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765470: ITP: fiona -- python api for reading/writing vector geospatial data
Package: wnpp Severity: wishlist Owner: Johan Van de Wauw johan.vandew...@gmail.com * Package name: fiona Version : 1.4.4 Upstream Author : Sean Gillies and others * URL : https://github.com/Toblerity/Fiona * License : MIT/X Programming Lang: Python Description : python api for reading/writing vector geospatial data Fiona is a python wrapper around the OGR vector data abstraction library. Fiona is designed to be simple and dependable. It focuses on reading and writing data in standard Python IO style and relies upon familiar Python types and protocols such as files, dictionaries, mappings, and iterators instead of classes specific to OGR. Fiona can read and write real-world data using multi-layered GIS formats and zipped virtual file systems and integrates readily with other Python GIS packages such as pyproj, Rtree, and Shapely. This program was already packaged for the OSGeo live dvd (ubuntu based) by Angelos Tzotsos. It will need fixes to be compliant with the debian file system hierarchy. Iintent to maintain this package in the Debian-GIS team. x-debug-cc: pkg-grass-de...@lists.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765465: debdiff for encfs_1.7.4-4.1
Control: severity -1 + serious
Control: tags -1 + pending
Hello Eduard,
At Imagination Technologies (http://imgtec.com/) Dejan Latinovic has
found a solution to Debian bug #765465.
https://bugs.debian.org/765465
My NMU debdiff for encfs_1.7.4-4.1 is below, at the end of this message.
With the changes in the NMU debdiff, encfs builds successfully on mips,
mipsel and amd64.
Regards,
Aníbal
--
Aníbal Monsalve Salazar anibal.monsalvesala...@imgtec.com
debdiff encfs_1.7.4-4.dsc encfs_1.7.4-4.1.dsc
diff -Nru encfs-1.7.4/debian/changelog encfs-1.7.4/debian/changelog
--- encfs-1.7.4/debian/changelog2014-10-07 19:30:56.0 +0100
+++ encfs-1.7.4/debian/changelog2014-10-15 12:49:46.0 +0100
@@ -1,3 +1,13 @@
+encfs (1.7.4-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS on mips and mipsel.
+Add use-pic-flag.patch.
+Patch by Dejan Latinovic dejan.latino...@imgtec.com.
+Closes: #765465.
+
+ -- Anibal Monsalve Salazar ani...@debian.org Wed, 15 Oct 2014 12:49:40
+0100
+
encfs (1.7.4-4) unstable; urgency=medium
* Switched packaging to dh(7) style
diff -Nru encfs-1.7.4/debian/patches/series encfs-1.7.4/debian/patches/series
--- encfs-1.7.4/debian/patches/series 2014-10-07 19:30:56.0 +0100
+++ encfs-1.7.4/debian/patches/series 2014-10-15 09:52:31.0 +0100
@@ -1,3 +1,4 @@
fix_bashisms
i18n_updates
pod2man_ignoreerr
+use-pic-flag.patch
diff -Nru encfs-1.7.4/debian/patches/use-pic-flag.patch
encfs-1.7.4/debian/patches/use-pic-flag.patch
--- encfs-1.7.4/debian/patches/use-pic-flag.patch 1970-01-01
01:00:00.0 +0100
+++ encfs-1.7.4/debian/patches/use-pic-flag.patch 2014-10-15
12:49:30.0 +0100
@@ -0,0 +1,48 @@
+Date: Tue, 14 Oct 2014 14:13:51 +0100
+From: Dejan Latinovic dejan.latino...@imgtec.com
+Subject: fix for encfs
+
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765465
+
+Package encfs FTBFS for mips and mipsel.
+
+https://buildd.debian.org/status/fetch.php?pkg=encfsarch=mipselver=1.7.4-4stamp=1412709053
+
+Here is discussion on debian-mips list:
+
+https://lists.debian.org/debian-mips/2014/10/msg1.html
+
+A patch that adds fpic flag for linking is attached.
+
+With this patch I was able to successfully build encfs for mips, mipsel and
amd64.
+
+Index: encfs-1.7.4/configure
+===
+--- encfs-1.7.4.orig/configure
encfs-1.7.4/configure
+@@ -13584,8 +13584,8 @@ with_gnu_ld=$lt_cv_prog_gnu_ld
+ # Check if GNU C++ uses GNU ld as the underlying linker, since the
+ # archiving commands below assume that GNU ld is being used.
+ if test $with_gnu_ld = yes; then
+-archive_cmds_CXX='$CC -shared -nostdlib $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
+-archive_expsym_cmds_CXX='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname
${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++archive_cmds_CXX='$CC -shared $pic_flag -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o
$lib'
++archive_expsym_cmds_CXX='$CC $pic_flag -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+
+ hardcode_libdir_flag_spec_CXX='${wl}-rpath ${wl}$libdir'
+ export_dynamic_flag_spec_CXX='${wl}--export-dynamic'
+Index: encfs-1.7.4/m4/libtool.m4
+===
+--- encfs-1.7.4.orig/m4/libtool.m4
encfs-1.7.4/m4/libtool.m4
+@@ -5523,8 +5523,8 @@ if test $_lt_caught_CXX_error != yes;
+ # Check if GNU C++ uses GNU ld as the underlying linker, since the
+ # archiving commands below assume that GNU ld is being used.
+ if test $with_gnu_ld = yes; then
+-_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o
$lib'
+-_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname -o $lib'
++_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
+ _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
signature.asc
Description: Digital signature
Bug#765471: openarena: crashes randomly
Package: openarena Version: 0.8.8-9 Severity: important Hi, Sorry my bad English With multiplayer, often falls in the log: === MetaVacroN^7 was gunned down by Yoric-RU^7 - Client Shutdown (Received signal 11) - *** Error in `/usr/lib/ioquake3': munmap_chunk(): invalid pointer: 0x04047620 *** ioq3 1.36+u20140802+gca9eebb-1+b1/Debian linux-x86_64 Sep 27 2014 === Or === ^1Lt.^2Joe^7 was melted by Yoric-RU^7's plasmagun jdubz^7 connected ^27^7 clients jdubz^7 disconnected ^26^7 clients - Client Shutdown (Received signal 11) - forcefully unloading cgame vm RE_Shutdown( 1 ) === Or other Thank you for your attention. -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openarena depends on: ii ioquake3 1.36+u20140802+gca9eebb-1+b1 ii libc6 2.19-11 ii openarena-081-maps0.8.5split-3 ii openarena-081-misc0.8.5split-3 ii openarena-081-players 0.8.5split-3 ii openarena-081-players-mature 0.8.5split-3 ii openarena-081-textures0.8.5split-3 ii openarena-085-data0.8.5split-3 ii openarena-088-data0.8.8-2 ii openarena-data0.8.5split-3 openarena recommends no packages. openarena suggests no packages. Versions of packages ioquake3 depends on: ii libc6 2.19-11 ii libcurl3-gnutls 7.38.0-2 ii libgl1-mesa-glx [libgl1] 10.2.6-1 ii libjpeg8 8d1-1 ii libogg0 1.3.2-1 ii libopenal11:1.15.1-5 ii libopus0 1.1-2 ii libopusfile0 0.6-1 ii libsdl1.2debian 1.2.15-10 ii libspeex1 1.2~rc1.2-1 ii libspeexdsp1 1.2~rc1.2-1 ii libvorbis0a 1.3.2-1.4 ii libvorbisfile31.3.2-1.4 ii zlib1g1:1.2.8.dfsg-2 Versions of packages ioquake3 recommends: ii x11-utils 7.7+2 -- 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#765472: nfs-common: idmapd doesn't map groups with names including (german) umlauts on nfs mounted volumes
Package: nfs-common Version: 1:1.2.6-4 Severity: normal Tags: l10n Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? situation: nfs server (wheezy) with winbind and MS Active Directory integration. nfs client (wheezy) with samba, winbind and MS Active Directory integration. the nfs server is exporting a directory via nfs and group ownership set to some AD groups. AD is installed in german, thus using umlauts in some default groups, e.g. domänen-benutzer. * What exactly did you do (or not do) that was effective (or ineffective)? chgrp some files/directories to such a group (tested with two groups containing umlauts) on the nfs server side. * What was the outcome of this action? stat on the directories on the nfs server shows GID and group name correctly. stat (or ls -l) on the client side sees GID 4294967294 (nogroup). switching groups on the server side from a working group to one with umlauts however doesn't ever change the GID on the client side, not even to nogroup. * What outcome did you expect instead? a correct mapping from the server side to the nfs client. -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 60854 status 1000241 tcp 38982 status -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD=yes NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 7 Pipefs-Directory = /var/lib/nfs/rpc_pipefs Domain = netto.lan Local-Realms = netto.lan [Mapping] Nobody-User = nobody Nobody-Group = nogroup [Translation] Method = nsswitch -- /etc/fstab -- 01nfs-01v.netto.lan:uportal/www /mnt/nfs/uportal/www nfs4 proto=tcp,sec=sys 0 0 -- /proc/mounts -- rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 01nfs-01v.netto.lan://uportal/www /mnt/nfs/uportal/www nfs4 rw,relatime,vers=4,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.161.220.249,minorversion=0,local_lock=none,addr=10.161.220.250 0 0 -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-41+deb7u1 ii libc6 2.13-38+deb7u4 ii libcap2 1:2.22-1.2 ii libcomerr2 1.42.5-1.1 ii libdevmapper1.02.1 2:1.02.74-8 ii libevent-2.0-5 2.0.19-stable-3 ii libgssglue1 0.4-2 ii libk5crypto31.10.1+dfsg-5+deb7u2 ii libkeyutils11.5.5-3 ii libkrb5-3 1.10.1+dfsg-5+deb7u2 ii libmount1 2.20.1-5.3 ii libnfsidmap20.25-4 ii libtirpc1 0.2.2-5 ii libwrap07.6.q-24 ii lsb-base4.1+Debian8+deb7u1 ii rpcbind 0.2.0-8 ii ucf 3.0025+nmu3 Versions of packages nfs-common recommends: ii python 2.7.3-4+deb7u1 Versions of packages nfs-common suggests: pn open-iscsi none pn watchdognone -- 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#765456: ogre-1.8: FTBFS on arm64
2014-10-15 10:26 GMT+01:00 Edmund Grimley Evans edmund.grimley.ev...@gmail.com: Source: ogre-1.8 Version: 1.8.0+dfsg1-7 It failed to build on arm64: Thanks for the report and the suggestion. I patched ogre-1.9 at the time (for arm64, mips64el and ppc64le), and submitted the patch upstream. I did not imagine that ogre-1.8 would survive for so long in unstable, ogre-1.9 has been out for a year now, and all development and bugfixes in 1.8 were stopped long before that. By the time that the next Debian stable is released, there would have been no support from upstream more than a year, so I don't even know if it's very wise to ship 1.8 in the next stable release. The packages depending on 1.8 at the moment are: - leaf packages (funguloids, and ember -- which is obsolete since long ago, 0.7 has been out for close to two years) - libogre-perl (I guess that these bindings to develop OGRE from Perl; which, if it does not target the most recent versions of OGRE, is of little use) - cegui, also needing an update for more than a year (a transition to newer versions has been ignored for a long time: #732763). cegui itself is not available neither in arm64 nor in ppc64el (unmet dependencies), and it also will fail to build from source once the deps are available (#758528). So, in summary, I don't think that any of these packages are particularly important to have in a stable port of a new architecture like arm64, because all of them are quite outdated and with very few installations. So, all in all, I think that it's better to not attempt to fix this bug, and possibly make it RC (once arm64 is accepted as release architecture) to try to nudge packages to move to the newer 1.9. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717228: t1utils: stackunderflow -17
Control: tags -1 moreinfo On Thu, 18 Jul 2013 10:28:17 +0200 Mathieu Malaterre ma...@debian.org wrote: Package: t1utils Version: 1.36-1 Severity: important While working on a copyrighted PS from Adobe, I tried following instructions from: http://wiki.debian.org/qa.debian.org/type1nondfsg Here is what I did: $ apt-get source pixelmed-java $ cd pixelmed-20130220 $ t1disasm ./com/pixelmed/web/favicon.ill /tmp/clean.ill $ md5sum /tmp/clean.ill c42cafae463de2205129a2f72caa1bad /tmp/clean.ill However I cannot open the output file. It seems like the output file got corrupted during the conversion. I am trying to solve the following issue: http://lists.debian.org/debian-mentors/2013/07/msg00150.html $ strings ./com/pixelmed/web/favicon.ill |grep Copyright [...] Thanks Hi, The output of t1disasm is used to review whether the code is subject to license issues. The output is a raw text format and is not suitable as a replacement of the original file (which you seem to suggest that you expect it to be)! I do not see any fault in t1disasm based on the information you provided so far (nor do I see the stackunderflow -17 anyway despite it being the title of the bug?). ~Niels [1] http://wiki.debian.org/qa.debian.org/type1nondfsg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
Chiming in on some of the issues below. *Dain Nilsson* Senior Software Developer, Yubico d...@yubico.com yubico.com On Wed, Oct 15, 2014 at 11:54 AM, Simon Josefsson si...@josefsson.org wrote: I have uploaded a new version of the package to mentors incorporating the changes mentioned below. There is one remaining blocker for this package entering Debian: The libu2f-host0 package is not yet in Debian. I'd love for you two to put your review cycles into it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764262 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764460 Re icons, larger non-XPM ones (including SVG) should be installed in /usr/share/icons/hicolor/widthxheight/apps: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout Thanks -- we are trying to sort this out, either we do something in the Debian packaging or we do it upstream -- but the latter requires some thinking since the package is cross-platform (Windows, Mac, GNU). This sounds fine, I think placing the files in the correct location for the Debian package is best. Some other things you might want to fix: I like to wrap debian/*.menu files at one attribute per line to make diffs more readable. Agreed, done. I like to run wrap-and-sort -sa to wrap the other debian/* files in the same way for the same reason. Didn't know about that tool, thanks for pointer. Ran it without -s though. I think the Priority should be optional rather than extra. Done. I would recommend debian/compat 9 and debhelper 9. Done. The license for neoman/libloader.py seems to be BSD-3-clause not BSD-2-clause? Done. The multiarch handling in neoman/libloader.py is incorrect, it should not hard-code the paths for amd64 and i386, Debian has other 64-bit and 32-bit ports plus the non-Linux ports. The neoman/libloader.py looks at /etc/ld.so.conf but that won't work on multi-arch systems becase /etc/ld.so.conf just includes /etc/ld.so.conf/*.conf and contains no dirs. No idea how to resolve this -- I suppose libloader.py is some external file we copie in, maybe there are Debian-ified versions of it. Dain? Not sure why this package have to hardcode or read ld.so.conf at all. Yes, this code is copied from an external source, I'm not entirely sure why it does some things it does, but it seems to work pretty well and I'm not sure we have the resources to be testing this on a vast number of different distros, so I've refrained from making any changes to this file. I'll open an issue for the upstream package regarding this. The manual page, desktop file and icon(s) should be installed by the upstream build system. PNG might be a better choice for the icons since it provides 8-bit transparency instead of 1-bit transparency. They seem to be PNG's in 0.2.3. Dain, can you install them? The menu icon is XPM now, I thought Debian required these to be XPM? If not then I agree that PNG is better. As for the upstream build system installing the man page, .desktop file and icons, I'm not sure the upstream build system has a good way of doing this. I'll open another issue for this nonetheless. These files look like they were generated from other files, I would suggest removing them from the VCS and tarballs and creating them at build time if possible: resources/installer_bg.png resources/neoman.icns resources/neoman.ico resources/neoman.xpm debian/neoman.xpm neoman/neoman.png It is common to ship generated files in tarballs, to avoid forcing users to have a lot of tools available. Agree with removing them from git though, Dain? debian/neoman.xpm and neoman/neoman.png have already been removed in 0.2.3. All of the resources/* files are manually created. DEFAULT_KEY does not look like something that should be included? Why not? Earlier NEOs had that key as the default (it is the common Visa/Mastercard standard key), although modern NEOs have randomized keys. Are the files listed in neoman/appletdb.json Free Software? Are they required for operation of yubikey-neo-manager? ykneo-oath and ykneo-openpgp are free software, but they are not required for operation and most people will not want or need them. The upstream signing key uses SHA1 for the self-sig, it should be re-signed with a SHA512 self-sig: https://help.riseup.net/en/security/message-security/openpgp/best-practices#self-signatures-should-not-use-sha1 Leave this to Dain :-) uscan doesn't like the upstream signing key unless I move it to debian/upstream/signing-key.asc (see below). Dain? The cowbuilder parts of debian/README.source do not look necessary, lots of folks use sbuild and the cowbuilder docs cover what is mentioned in debian/README.source. Yeah, it is mostly an example and reminder for the people working with the packaging. os.system (in release.py) should be replaced by use of the subprocess module
