Bug#781497: musl: CVE-2015-1817: stack-based buffer overflow in ipv6 literal parsing
Source: musl Version: 1.1.5-1 Severity: grave Tags: security upstream patch fixed-upstream Hi, the following vulnerability was published for musl. CVE-2015-1817[0]: stack-based buffer overflow in ipv6 literal parsing If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2015-1817 [1] http://www.openwall.com/lists/oss-security/2015/03/30/3 Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781490: ITP: node-shelljs -- Portable Unix shell commands for Node.js
Package: wnpp Severity: wishlist Owner: Marcelo Jorge Vieira me...@debian.org X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-shelljs Version : 0.4.0 Upstream Author : Artur Adib aa...@mozilla.com * URL : http://github.com/arturadib/shelljs * License : BSD* Programming Lang: JavaScript Description : Portable Unix shell commands for Node.js ShellJS is a portable (Windows/Linux/OS X) implementation of Unix shell commands on top of the Node.js API. You can use it to eliminate your shell script's dependency on Unix while still keeping its familiar and powerful commands. Cheers, -- Marcelo Jorge Vieira xmpp:me...@jabber-br.org http://metaldot.alucinados.com signature.asc Description: This is a digitally signed message part
Bug#781491: RFP: wiringx -- Modular GPIO interface
Package: wnpp Severity: wishlist * Package name: wiringx Version : Git Upstream Author : CurlyMo curlym...@gmail.com * URL : http://wiringx.org/ * License : GPL Programming Lang: C Description : Modular GPIO interface wiringX is a modular approach to several GPIO interfaces. wiringX will export all common GPIO functions also found libraries such as wiringPi and wiringHB, but when using wiringX it will automatically determine what device your program is running on and use the appropriate GPIO functions. So when using wiringX, your program will just work in regard of GPIO functionality. The wiringPi and wiringHB are almost a direct copy of their initial library. However, wiringX currently does not yet support all features of the Hummingboard and Raspberry Pi I/O. Therefore, wiringPi has been stripped so it only supports those features also supported by wiringX. Those features currently are: * GPIO reading, writing, and interrupts. * IC2 reading and writing. The supported devices are: * Raspberry Pi * Hummingboard * BananaPi * Radxa Rock * MIPS CI20 Creator -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778913: openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success
Hi Michael. Your proposal seems to be a good solution for now. Maybe Colin can merge it and it will find it's way into jessie. As for sd_notify,... a simply google query didn't turn up any existing patches for that and it may be hard to convince upstream to do it ;) Since this problem may affect other services as well... is there some concentrated effort in Debian to identify these? While systemd is great (in theory) I still feel that we (and others either) don't use even a fraction of the goodness it could do. Just look at the other bug that you've just closed before, and the issues about services depending on facilities like firewall rules loaded (network-pre.target is really a very unfortunate solution for this... how regrettable that upstream went that way, even though better ideas were in place :( ). As you said, it's up to the respective package's maintainers, which effectively means that either nothing of the new nice stuff gets used or at least not homogeneously over all services. So in the end, having a powerful framework where the admin can easily control which facilites are mandatory for which services, as I've proposed, would be up to the user. Best wishes, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#765577: netboot install writes duplicates to 70-persistent-net.rules
Control: tags -1 confirmed Am 18.03.2015 um 19:50 schrieb Michael Biebl: Am 18.03.2015 um 18:52 schrieb Michael Biebl: Am 18.03.2015 um 18:15 schrieb Faidon Liambotis: Another less arbitrary/racy workaround I suggesed was a grep near the top of write_net_rules' write_rule() function. Since write_rule() operates under a lock, this would completely eliminate any kind of race here. I pitched this to Marco but he wasn't thrilled with the idea -- he said he'd prefer finding the root cause. I've done the change and tested it anyway, though, and it successfully aleviates this issue: I'm with Marco here. Before adding any workarounds, we need to understand what the underlying problem is. Otherwise we are adding cruft which nobody understands anymore a few years from now. Since I can't reproduce the issue and already have trouble keeping up with other bug reports, further investigation needs to be done by someone else. Btw, thanks for looking into this. Would be awesome if you can dig further and get to the bottom of this. Looks like a found a simple reproducer (this is on my work laptop) done during normal runtime of the system: $ rm /etc/udev/rules.d/70-persistent-net.rules $ while true ; do echo add /sys/class/net/eth0/uevent ; done I let this run for one or two seconds and had over 100 entries in 70-persistent-net.rules. udevd went totally nuts and consumed almost 100% CPU, but a simple systemctl restart systemd-udevd.service fixed that. So, while I don't have a solution yet, at least I have now a simple way to reproduce it reliably. Therefor marking the bug accordingly. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#781496: gzip: --rsyncable option works poorly on wheezy
Package: gzip Version: 1.5-1.1 Severity: normal Dear Maintainer, I have a backup system that performed well when running on squeeze using rdiff-backup, but on wheezy the daily diffs of gzipped mysqldump files are commonly almost as large as the original dump files. On inspection, it seems that gzip's --rsyncable option on wheezy is of benefit, but quite variable nothing near what is achieved when running on squeeze or on jessie. I've been testing this using docker with a Dockerfile as follows, which makes it relatively easy to compare performance on different OS versions. ~~ FROM debian:wheezy RUN apt-get update apt-get install -y --no-install-recommends \ rdiff-backup RUN apt-get install -y --no-install-recommends wget RUN mkdir -p /tmp/testdir/src /tmp/testdir/dst WORKDIR /tmp/testdir RUN wget http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3.18.5.orig.tar.xz RUN unxz linux_3.18.5.orig.tar.xz RUN ( cat linux_3.18.5.orig.tar) | gzip src/standard.gz RUN ( cat linux_3.18.5.orig.tar) | gzip --rsyncable src/rsyncable.gz RUN rdiff-backup -b src dst RUN rm src/* RUN (echo difference; cat linux_3.18.5.orig.tar) | gzip src/standard.gz RUN (echo difference; cat linux_3.18.5.orig.tar) | gzip --rsyncable src/rsyncable.gz RUN rdiff-backup -b src dst RUN ls -l dst/rdiff-backup-data/increments ~~ The diffs for wheezy are usually, but seemingly not always many orders of magnitude larger than for other versions. It's content dependent. I had a go at making a backport myself based on sources from jessie (and sid), and the configure stage fails to find a macro which is defined within the downloaded source. My knowledge of autoconf is both basic and rusty. Could someone help by providing a backport please? -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gzip depends on: ii dpkg 1.16.15 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38+deb7u8 gzip recommends no packages. Versions of packages gzip suggests: ii less 444-4 -- 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#750135: Status of #750135 (Maintainer of aptitude package)
Quoting Tollef Fog Heen (tfh...@err.no): It can't indeed be worse than the current situation anyway. I see where the proposal is coming from, but I'd like to ask you to hold off on it a little bit. I've mailed Daniel and asked him to comment on the bug, so hopefully we can have his input soon and get this resolved. No problem. I was indeed waiting to see comments to my proposal without doing anything, anyway. I'll follow the issue as well to see where it goes and help where I can. signature.asc Description: Digital signature
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On 03/29/2015 08:01 PM, Niko Tyni wrote: Glad to see progress on this! On Sun, Mar 29, 2015 at 05:46:44PM +0200, Kasper Loopstra wrote: However, I am quite sure that I removed /usr/local/share before starting off with the upgrade, so perhaps there is something wrong with the upgrade path between wheezy and jessie. So below is what's in the /usr/local/share after an upgrade. Is there anything wrong here? Or shouldn't I have removed /usr/local/share without recreating it with correct permissions? I think whatever recreated /usr/local/share without world read+execute bits is buggy and should be fixed before the release. Now we just need to find it. What's your umask setting during the upgrade? 0022 root@chloromethane:/usr/local# ls -la share/ total 20 drwxr-x--x+ 5 root root 4096 Mar 29 13:35 . drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 .. drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 ca-certificates drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 emacs drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 texmf The time stamps seem to suggest that the package that created /usr/local/share/texmf is to blame. However, that would be tex-common AFAICS, but its post-installation script doesn't seem to do this. In fact, it will not create /usr/local/share/texmf at all if /usr/local/share is missing. if you are able to recreate this, would it be possible for you to first remove /usr/local/share and then upgrade piecemeal, maybe starting with the tex* packages you have installed? Perhaps that would pinpoint the guilty package. I'll try, but piecemeal upgrades are kind of difficult (I tried for spamassassin), and I see things pull in so much dependencies it's almost the entire upgrade anyway. Is there some apt-get magic I am missing? Thanks, Kasper. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781493: Acknowledgement (libreoffice-writer: Page number field does not increment)
Er, so I closed the document and reopened it, and now the numbers are fine. I do have some additional information that might help diagnose it. I opened writer by itself to start this new document, and while it was open, I opened some other documents for reference (all ODT by the way). This was all done before I ever saved the original document. This might be hard to reproduce, but this is an issue that should be looked into. Happy Hacking, David E. McMackins II Associate, Free Software Foundation (#12889) www.mcmackins.org www.delwink.com www.gnu.org www.fsf.org On 03/29/2015 09:06 PM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian LibreOffice Maintainers debian-openoff...@lists.debian.org If you wish to submit further information on this problem, please send it to 781...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781493: libreoffice-writer: Page number field does not increment
Package: libreoffice-writer Version: 1:4.3.3-2 Severity: normal Dear Maintainer, Adding the page number field from the Insert menu into the document's header does not increment when advancing pages. I always see page 1 on any page. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-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 Init: systemd (via /run/systemd/system) Versions of packages libreoffice-writer depends on: ii libabw-0.1-1 0.1.0-2 ii libc6 2.19-17 ii libe-book-0.1-10.1.1-2 ii libgcc11:4.9.2-10 ii libicu52 52.1-8 ii libmwaw-0.3-3 0.3.1-2 ii libodfgen-0.1-10.1.1-2 ii libreoffice-base-core 1:4.3.3-2 ii libreoffice-core 1:4.3.3-2 ii librevenge-0.0-0 0.0.1-3 ii libstdc++6 4.9.2-10 ii libwpd-0.10-10 0.10.0-2+b1 ii libwpg-0.3-3 0.3.0-3 ii libwps-0.3-3 0.3.0-2 ii libxml22.9.2+dfsg1-3 ii uno-libs3 4.3.3-2 ii ure4.3.3-2 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages libreoffice-writer recommends: ii libreoffice-math 1:4.3.3-2 Versions of packages libreoffice-writer suggests: pn fonts-crosextra-caladeanone pn fonts-crosextra-carlitonone ii libreoffice-base 1:4.3.3-2 pn libreoffice-gcjnone ii libreoffice-java-common1:4.3.3-2 ii openjdk-7-jre [java5-runtime] 7u75-2.5.4-3 ii openjdk-8-jre [java5-runtime] 8u40-b27-1 Versions of packages libreoffice-core depends on: ii fontconfig2.11.0-6.3 ii fonts-opensymbol 2:102.6+LibO4.3.3-2 ii libatk1.0-0 2.14.0-1 ii libboost-date-time1.55.0 1.55.0+dfsg-3 ii libc6 2.19-17 ii libcairo2 1.14.0-2.1 ii libclucene-contribs1 2.3.3.4-4 ii libclucene-core1 2.3.3.4-4 ii libcmis-0.4-4 0.4.1-7 ii libcups2 1.7.5-11 ii libcurl3-gnutls 7.38.0-4 ii libdbus-1-3 1.8.16-1 ii libdbus-glib-1-2 0.102-1 ii libeot0 0.01-3 ii libexpat1 2.1.0-6+b3 ii libexttextcat-2.0-0 3.4.4-1 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-4 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libgl1-mesa-glx [libgl1] 10.4.2-2 ii libglew1.10 1.10.0-3 ii libglib2.0-0 2.42.1-1 ii libgltf-0.0-0 0.0.2-2 ii libglu1-mesa [libglu1]9.0.0-2 ii libgraphite2-31.2.4-3 ii libgtk2.0-0 2.24.25-3 ii libharfbuzz-icu0 0.9.35-2 ii libharfbuzz0b 0.9.35-2 ii libhunspell-1.3-0 1.3.3-3 ii libhyphen02.8.8-2 ii libice6 2:1.0.9-1+b1 ii libicu52 52.1-8 ii libjpeg62-turbo 1:1.3.1-12 ii liblangtag1 0.5.1-3 ii liblcms2-22.6-3+b3 ii libldap-2.4-2 2.4.40-4 ii libmythes-1.2-0 2:1.2.4-1 ii libneon27-gnutls 0.30.1-1 ii libnspr4 2:4.10.7-1 ii libnss3 2:3.17.2-1.1 ii libodfgen-0.1-1 0.1.1-2 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpng12-01.2.50-2+b2 ii librdf0 1.0.17-1+b1 ii libreoffice-common1:4.3.3-2 ii librevenge-0.0-0 0.0.1-3 ii libsm62:1.2.2-1+b1 ii libssl1.0.0 1.0.1k-3 ii libstdc++64.9.2-10 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxinerama1 2:1.1.3-1+b1 ii libxml2 2.9.2+dfsg1-3 ii libxrandr22:1.4.2-1+b1 ii libxrender1 1:0.9.8-1+b1 ii libxslt1.11.1.28-2+b2 ii libxt61:1.1.4-1+b1 ii uno-libs3 4.3.3-2 ii ure 4.3.3-2 ii zlib1g1:1.2.8.dfsg-2+b1 -- no debconf information Happy Hacking, David E. McMackins II Associate, Free Software Foundation (#12889) www.mcmackins.org www.delwink.com www.gnu.org www.fsf.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781487: conkeror does not start, fails with JavaScript strict mode errors
On 30.03.2015 00:53, Axel Beckert wrote: If you're curious, try the conkeror snapshots from http://noone.org/conkeror-nightly-debs/. If that solves the issue for you, it may be worth to do a conkeror upload to Experimental before the Jessie release. Thanks, 1.0~~pre-1+git150318+2307-~nightly1 works for me. - Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781233: unblock: parted/3.2-7
Control: tag -1 confirmed Niels Thykier ni...@thykier.net (2015-03-28): On 2015-03-26 11:21, Colin Watson wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package parted; this fixes a crash when trying to resize fat16 filesystems. CCing debian-boot since this would need a d-i ack too. Ack from here, just needs a d-i from here. (Quoting in full for KiBi's convenience) No objections, thanks. Mraw, KiBi. signature.asc Description: Digital signature
Bug#781489: criu: links against libprotobuf-c0 which it doesn't depend on
Control: tags -1 + moreinfo unreproducible Hi This does not look correct at first glance. criu/1.3.1-1 in jessie/unstable depends on libprotobuf-c1 (as well criu/1.4-1 in experimental). What does apt-cache policy criu shows? Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780902: unblock: openssl/1.0.1k-2
Control: tag -1 confirmed Adam D. Barratt a...@adam-barratt.org.uk (2015-03-21): On Sat, 2015-03-21 at 10:40 +0100, Kurt Roeckx wrote: 1.0.1k-2 contains security fixes. Could you please unblock it? Unblocked but needs a d-i ack as usual. No objections, thanks. Mraw, KiBi. signature.asc Description: Digital signature
Bug#781465: RFS: darkhttpd/1.11-1
On Mon, Mar 30, 2015 at 12:43 AM, Mateusz Łukasik wrote: darkhttpd - secure, lightweight, fast HTTP server There are already lots and lots of HTTP servers in Debian for all sorts of use-cases. What use-case is supported by darkhttpd but not by any other existing HTTP server in Debian? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781492: RFP: python-wiringx -- Python binding for wiringX
Package: wnpp Severity: wishlist * Package name: python-wiringx Version : 0.6 Upstream Author : CurlyMo curlym...@gmail.com * URL : https://github.com/wiringX/wiringX/tree/master/python * License : GPL Programming Lang: C, Python Description : Python binding for wiringX This package export all wiringX function to Python. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781494: ITP: gopass -- pass implementation in Go
Package: wnpp Severity: wishlist * Package name: gopass Version : 0.1.0 Upstream Author : Alexandre Viau alexan...@alexandreviau.net * URL : https://github.com/ReAzem/gopass * License : GPLv3 Programming Lang: Go Description : Pass implementation in Go signature.asc Description: OpenPGP digital signature
Bug#781475: Jessie Installation-reports
On Sun, Mar 29, 2015 at 08:42:41PM +0100, A. J. Trim wrote: Package: installation-reports Boot method: DVD-RW Image version: https://www.debian.org/devel/debian-installer/News/2015/20150126 (This was Jessie, RC1.) Date: Some time last week. (It is now Sun 29-Mar-2015.) Machine: Dell Inspiron 3000 (i.e. the current model) but with a second 1 TByte hard disk added. Installation attempt was onto this second disk. Processor: Intel Core i5-4460 CPU @ 3.20 GHz x 4. Memory: 7.8 GiByte Partitions: As set up automatically by the installer, using the encrypted LVM option. Output of lspci -knn (or lspci -nn): ??? Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] but not sure where. This is a UEFI boot system. Secure Boot had been disabled. Overall install:[O] Comments/Problems: System booted to a graphical grub menu. Windows 8.1 booted from here OK ( /dev/sda ). Linux started to boot ( /dev/sdb ). It asked for the LVM encryption password using command-line interface. The USB keyboard and USB mouse are dead at this point, so I was unable to enter the password. No progress was possible. I installed Linux Mint 17.1 at this point. This asks for the LVM encryption password via Plymouth GUI with keyboard and mouse live. This works OK. This works with Secure Boot switched on. I recommend holding the release of Jessie until live keyboard and mouse can be provided at the time of the encryption password request. Well I have no issue with USB keyboard input for the disk encryption password with the jessie install I did a few weeks ago using the daily build of the installer. So it is not broken for USB in general, perhaps just in some specific cases. Perhaps RC1 being so old had some bugs that are not present anymore (my installer image was much newer than RC1). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765577: netboot install writes duplicates to 70-persistent-net.rules
Am 30.03.2015 um 04:56 schrieb Michael Biebl: Looks like a found a simple reproducer (this is on my work laptop) done during normal runtime of the system: $ rm /etc/udev/rules.d/70-persistent-net.rules $ while true ; do echo add /sys/class/net/eth0/uevent ; done I let this run for one or two seconds and had over 100 entries in 70-persistent-net.rules. udevd went totally nuts and consumed almost 100% CPU, but a simple systemctl restart systemd-udevd.service fixed that. So, while I don't have a solution yet, at least I have now a simple way to reproduce it reliably. Therefor marking the bug accordingly. I think I have a pretty good explanation now, why this happens and why the lock_rules_file() function does not really prevent this: Say we have multiple add events. NAME is not yet set for the interface. So we we call write_net_rules for all of them and they spin in lock_rules_file() and when they get their turn, they pick the next free name i.e. increase the counter. The problem happens if you have multiple add events *before* the rules file is written and NAME is not yet set. Those multiple add events could be the result of something calling udevadm trigger multiple times for example, as you rightfully pointed out Faidon. Talked to Marco via IRC and this seemed plausible to him. He also mentioned, that he might have a simple fix for it. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#781488: mate-netspeed: incorrect unit when show bits is selected
Package: mate-netspeed Version: 1.8.0+dfsg1-2 Severity: minor Tags: newcomer upstream Dear Maintainer, When showing bits the unit is mb/s (which means milli bit per second) and is wrong: should be Mb/s (mega bit per second) I have italian localization. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (500, 'testing-updates'), (500, 'testing-proposed-updates'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mate-netspeed depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii libatk1.0-0 2.14.0-1 ii libc62.19-15 ii libcairo21.14.0-2.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-3 ii libgtop2-7 2.28.5-2+b1 ii libmate-panel-applet-4-1 1.8.1+dfsg1-3 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 mate-netspeed recommends no packages. mate-netspeed 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#751892: udev: external media belong to disk group
Am 30.03.2015 um 02:25 schrieb Dmitry Alexandrov: On 30/03/15 02:41, Michael Biebl wrote: Am 30.03.2015 um 01:21 schrieb Dmitry Alexandrov: On 30/03/15 01:01, Michael Biebl wrote: The default policy shipped in Debian allows local desktop users to mount/umount/format etc removable media. ‘Format’? How? udisksctl(1) does mot provide such a possibility, as far as I see. Also, to my mind, an average desktop user is much less concerned about formating removable drives than *labeling* them. Could it be done without raw access to block devices? You can, indeed. gnome-disks [1] is a GUI frontend for udisks. Among others, it let's change the file system labels. I'm sure, other desktop environments provide similar functionality. If not, you should poke them. OK, thanks, it’s good that desktop environments took up this problem, but that is (or would be) both too complex and too local solutions. What about basics: a non-interactive utility like e2label(8) / fatlabel(8), that would allow one to make re-labelling easy by, for example, configuring a ‘user action’ for his favourite file manager? (By the way, it might worth noting how to re-label partition with gnome-disks(1) since it’s not quite obvious and does not explained in ‘GNOME Help’: select a device and select a partition → click a gear icon next to remove partition button (minus sign icon) → ‘Edit Filesystem’. I could not manage to do it with keyboard.) At least mounting/unmount/formatting/writing of ISO-Images are all integrated nicely into nautilus. It's true, that relabelling is not and that you need to resort to gnome-disks here. But that's a rather special case imho. As for using the command line tools: No-one prevents you from using those e.g. using sudo or pkexec. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#540990: Bug#780591: ltsp-client-builder fails when installing Debian Edu combined server in virtualbox environment
Control: tag -1 patch On 2015-03-24, Wolfgang Schweer wrote: On Mon, Mar 23, 2015 at 12:02:05PM -0700, Vagrant Cascadian wrote: On Tue, Mar 17, 2015 at 10:00:08PM +0100, Wolfgang Schweer wrote: Confirmed after having started an USB stick installation on real (and very old) hardware; something like /dev/sdXY is mounted on /cdrom inside d-i environment. Inspired by this observation I tried this patch in the virtualbox environment (booting from 'cd') and as well on bare metal w/ USB stick: Here's an alternate patch that worked for me with both CD and USB installs, and has a fallback to the old behavior if none of the mounts contain .disk/info. Please try it and let me know if it solves your issue: diff --git a/ltsp-client-builder.postinst b/ltsp-client-builder.postinst index 4b9c057..6b9dd59 100644 --- a/ltsp-client-builder.postinst +++ b/ltsp-client-builder.postinst @@ -64,8 +64,20 @@ done db_progress STEP 1 if [ $USE_CDROM != false ] [ ! -f /target/media/cdrom/.disk/info ]; then -chroot /target mount /media/cdrom -log mounting /media/cdrom +# Read mountpoints of cdrom devices from /proc/mounts, and mount +# at /target/media/cdrom/ +while [ ! -f /target/media/cdrom/.disk/info ] read device mountpoint otherstuff ; do +case $mountpoint in +*cdrom*) log mounting $device on /target/media/cdrom + mount $device /target/media/cdrom + ;; +esac +done /proc/mounts +if [ ! -f /target/media/cdrom/.disk/info ]; then + # Last-ditch failsafe... + log Mounting /media/cdrom in the chroot. + in-target mount /media/cdrom +fi fi # workaround for: http://bugs.debian.org/390647 As an added bonus, I think it will also fix: https://bugs.debian.org/540990 live well, vagrant signature.asc Description: PGP signature
Bug#751892: udev: external media belong to disk group
On 30/03/15 03:34, Michael Biebl wrote:
Am 30.03.2015 um 02:25 schrieb Dmitry Alexandrov:
On 30/03/15 02:41, Michael Biebl wrote:
Am 30.03.2015 um 01:21 schrieb Dmitry Alexandrov:
On 30/03/15 01:01, Michael Biebl wrote:
The default policy shipped in Debian allows local desktop users to
mount/umount/format etc removable media.
‘Format’? How? udisksctl(1) does mot provide such a possibility, as far
as I see. Also, to my mind, an average desktop user is much less
concerned about formating removable drives than *labeling* them. Could
it be done without raw access to block devices?
You can, indeed. gnome-disks [1] is a GUI frontend for udisks.
Among others, it let's change the file system labels.
I'm sure, other desktop environments provide similar functionality.
OK, thanks, it’s good that desktop environments took up this problem,
but that is (or would be) both too complex and too local solutions. What
about basics: a non-interactive utility like e2label(8) / fatlabel(8),
that would allow one to make re-labelling easy by, for example,
configuring a ‘user action’ for his favourite file manager?
At least mounting/unmount/formatting/writing of ISO-Images are all
integrated nicely into nautilus.
It's true, that relabelling is not and that you need to resort to
gnome-disks here. But that's a rather special case imho.
As for using the command line tools: No-one prevents you from using
those e.g. using sudo or pkexec.
sudo(8)? How? By writing a script that would analyse whether the
argument is pointing to removable device or not? Thanks, no.
Moreover, if I have to do some manipulation with superuser rights, then
why I would ever need *this*: no-one prevents me from restoring expected
behaviour by putting removed udev rules (‘91-permissions.rules’ in
attachment to this message) back to /etc/udev/rules.d/
But thank you, I did not realised that UDisks (as a library) have an
ability to label and format. I think, I have at least to file a feature
request against udisksctl(1). Here it is: https://bugs.debian.org/781495
ACTION==remove, GOTO=permissions_end
# default permissions for block devices
SUBSYSTEM==block, GROUP=disk
SUBSYSTEM==block, ATTRS{removable}==1, GROUP=floppy
# the aacraid driver is broken and reports the disks as removable (see #404927)
SUBSYSTEM==block, DRIVERS==aacraid, GROUP=disk
# all block devices on these buses are removable
SUBSYSTEM==block, SUBSYSTEMS==usb|ieee1394|mmc|pcmcia, GROUP=floppy
KERNEL==cbm, GROUP=floppy
# IDE devices
ENV{ID_CDROM}==?*,GROUP=cdrom
KERNEL==ht[0-9]*, GROUP=tape
KERNEL==nht[0-9]*,GROUP=tape
# SCSI devices
SUBSYSTEM==scsi_generic|scsi_tape, \
SUBSYSTEMS==scsi, ATTRS{type}==1|8, GROUP=tape
SUBSYSTEM==scsi_generic, \
SUBSYSTEMS==scsi, ATTRS{type}==4|5, GROUP=cdrom
# USB devices
KERNEL==legousbtower*,MODE=0666
KERNEL==lp[0-9]*, SUBSYSTEMS==usb, GROUP=lp
# hplip and cups 1.4+ use raw USB devices, so permissions should be similar to
# the ones from the old usblp kernel module
SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, \
ENV{ID_USB_INTERFACES}==, IMPORT{builtin}=usb_id
SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, \
ENV{ID_USB_INTERFACES}==*:0701??:*, GROUP=lp
# usbfs-like devices
SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, \
MODE=0664
# serial devices
SUBSYSTEM==tty, GROUP=dialout
SUBSYSTEM==capi, GROUP=dialout
SUBSYSTEM==slamr, GROUP=dialout
SUBSYSTEM==zaptel,GROUP=dialout
KERNEL==mISDNtimer, GROUP=dialout
KERNEL==mwave,GROUP=dialout
KERNEL==hvc*|hvsi*, GROUP=dialout
# vc devices (all members of the tty subsystem)
KERNEL==ptmx, MODE=0666,GROUP=root
KERNEL==console, MODE=0600,GROUP=root
KERNEL==tty, MODE=0666,GROUP=root
KERNEL==tty[0-9]*,GROUP=root
KERNEL==pty*, MODE=0666,GROUP=tty
# video devices
SUBSYSTEM==video4linux, GROUP=video
SUBSYSTEM==drm, GROUP=video
SUBSYSTEM==dvb, GROUP=video
SUBSYSTEM==em8300,GROUP=video
SUBSYSTEM==graphics, GROUP=video
SUBSYSTEM==nvidia,GROUP=video
# misc devices
KERNEL==random, MODE=0666
KERNEL==urandom, MODE=0666
KERNEL==mem, MODE=0640,GROUP=kmem
KERNEL==kmem, MODE=0640,GROUP=kmem
KERNEL==port, MODE=0640,GROUP=kmem
KERNEL==nvram,MODE=0640,GROUP=kmem
KERNEL==full, MODE=0666
KERNEL==null,
Bug#781495: [Pkg-utopia-maintainers] Bug#781495: udisksctl lacks commands for labelling and formatting
Control: severity -1 wishlist Control: tags -1 upstream Am 30.03.2015 um 05:00 schrieb Dmitry Alexandrov: Package: udisks2 Version: 2.1.3-5 Severity: normal While UDisks implements functions for labelling [0] and formatting [1] partitions and drives and, judging by gnome-disks(1), they are pretty working, udisksctl(1) does not provide a user interface for them. Not being something important by itself, in a couple with revoking raw access to removable block devices from users (bug #751892 [2]) this lack of feature presents a regression in Jessie for a user that wants re-label or re-format an USB-drive using a non-interactive utility: using e2label(8) / fatlabel(8) / mkfs(8) requires superuser rights now. Hi Dmitry, since this a feature request and not a Debian specific integration issue, it would be great if you can file this bug report upstream and report back with the bug number. It's unlikely that we develop such features downstream. Thanks, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#765577: (no subject)
On Mar 18, Faidon Liambotis parav...@debian.org wrote:
Well, the root cause IMO is that 75-persistent-net-generator.rules is
inherently susceptible to races. It's my understanding that it's valid
for events to be triggered multiple times -- there are multiple places
in d-i that udevadm trigger is called, including start-udev (as
shipped by udev-udeb) which would trigger another set of add events
beyond the original hotplug one.
I do not think that this is valid in the sense that the kernel could
generate multiple add events, but removing all misuses of udevadm
trigger requires some work and may not even be possible at this time.
I see that we have independently devised the same fix, I am attaching
a test case and a more refined version of your patch.
--
ciao,
Marco
#!/bin/sh -e
rm -f /etc/udev/rules.d/70-persistent-net.rules
rmmod e1000e || true
modprobe e1000e
sleep 1
rm -f /etc/udev/rules.d/70-persistent-net.rules
iteration=0
while : ; do
iteration=$((iteration + 1))
if ! echo add /sys/class/net/eth0/uevent; then
echo Failed at iteration $iteration!
exit
fi
# do not send too many events to udev because they will all be queued
# and eventually processed
if [ $iteration -eq 2500 ]; then
echo Aborting at iteration $iteration!
exit
fi
done
--- /lib/udev/write_net_rules.orig 2015-03-30 05:18:43.228147201 +0200
+++ /lib/udev/write_net_rules 2015-03-30 06:00:39.181085432 +0200
@@ -117,6 +117,18 @@
basename=${INTERFACE%%[0-9]*}
match=$match, KERNEL==\$basename*\
+# build a regular expression that matches the new rule that we want to write
+new_rule_pattern=$(echo ^SUBSYSTEM==\net\, ACTION==\add\$match | sed -re 's/([\?\*])/\\\1/g')
+
+# Double check if the new rule has already been written. This happens if
+# multiple add events are generated before the script returns and udevd
+# renames the interfaces. See #765577 for details.
+if egrep -q $new_rule_pattern \
+$RO_RULES_FILE $([ -e $RULES_FILE ] echo $RULES_FILE); then
+ unlock_rules_file
+ exit 0
+fi
+
if [ $INTERFACE_NAME ]; then
# external tools may request a custom name
COMMENT=$COMMENT (custom name provided by external tool)
pgp099UwXLv9Q.pgp
Description: PGP signature
Bug#761658: Please reopen this bug report
Hi, I agree: no nameserver → no resolution. Please reopen this bug report. Thank you! Carlo
Bug#778492: unblock: ndisc6/1.0.1-2
Control: tag -1 moreinfo Michael Gilbert mgilb...@debian.org (2015-03-29): I couldn't get netcfg to trigger rdnssd installation with my set up, so here is what I did to mimic the process: boot from jessie RC2 nothing special up through pkgsel before pkgsel, manually install rdnssd 1.0.1-2 from sid proceed with pkgsel (making sure to select gnome in tasksel) To resolve the rdnssd/nm conflict, apt concludes that nm should be installed and rdnssd removed, which then happens. Afterwards: $ dpkg -l | grep -e network-manager -e rdnssd | cut -d' ' -f1,2,3 ii network-manager ii network-manager-gnome rc rdnssd On reboot, networking with nm works correctly. This effectively mimics the configurations where netcfg automatically adds in rdnssd. Is this sufficient? Thanks for trying, but no, that's not sufficient. I really would like having a real use case where the bug gets reproduced without “cheating” (for the lack of a better wording), so that we can actually check that the change isn't worse than the bug it's supposed to fix. Mraw, KiBi. signature.asc Description: Digital signature
Bug#780121: unblock: libgcrypt20/1.6.3-2
Control: tag -1 confirmed Niels Thykier ni...@thykier.net (2015-03-14): On 2015-03-09 15:22, Andreas Metzler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, Please unblock package libgcrypt20. This is bugfix only stable release, taking care of two side-channel vulnerabilities (CVE-2015-0837 and CVE-2014-3591): Noteworthy changes in version 1.6.3 (2015-02-27) [C20/A0/R3] * Use ciphertext blinding for Elgamal decryption [CVE-2014-3591]. See http://www.cs.tau.ac.il/~tromer/radioexp/ for details. * Fixed data-dependent timing variations in modular exponentiation [related to CVE-2015-0837, Last-Level Cache Side-Channel Attacks are Practical]. * Improved asm support for older toolchains. Find attached the filtered debdiff (| filterdiff -x '*/build-aux/*' -x '*/Makefile.in' -x '*/configure' -x '*/gcrypt.info*' -x '*/aclocal.m4') versus testing. thanks, cu Andreas unblock libgcrypt20/1.6.3-2 It is a bit noiser than I liked (especially without your filterdiff), Indeed (and thanks for the said filterdiff)… but ack from RT, CC'ing KiBi for a d-i ack. No objections, thanks. Mraw, KiBi. signature.asc Description: Digital signature
Bug#761658: Please do not default to using Google nameservers
also sprach Christoph Anton Mitterer cales...@scientia.net [2015-03-29 07:18 +0200]: So if resolved is used - and I'd guess that's the long term goal - then people would automatically get resolving - always. Even when they have /etc/resolv.conf (possibly intentionally) left empty and AFAIU the manpage, one cannot unset it. I imagine that in a few years, /etc/resolv.conf will be obsolete and no longer used in most cases (cf. xorg.conf, and others). While this is a good development in terms of ease of use, it does put a whole lot more weight on default choices made by upstream and Debian. At the moment, systemd upstream and Debian basically embrace Google and require people who don't want that to do extra work. If that's a direction to go, then shouldn't postfix also be configured by default to relay mail via GMail? -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#781381: Does not build
Hi Andreas, Fred, I'll address your issues in a later commit and report back. @Fred Indeed, I did not test the reproducibility of the build, and wrongfully assumed that switching to pybuild whilst keeping the former d/rules targets would be enough. @Andreas You need numpy, because setup.py makes an unconditional import of it regardless of the target. This is a problem shared by a number of other scientific packages and it will take time before our upstream adjust to proper practices (like do I need numpy when I invoke python setup.py clean). These are nicely summarized at the end of the following blog post [1]. Best I can do is file a bug upstream and suggest pointers. [1] https://caremad.io/2014/11/distributing-a-cffi-project/ Thanks for your help guys, we will have a working package soon. Ghis 2015-03-29 9:12 GMT+01:00 PICCA Frederic-Emmanuel frederic-emmanuel.pi...@synchrotron-soleil.fr: Hello Andreas, It seems that you do not have numpy installed on your machine. can you try after apt-get install python-numpy python3-numpy cheers fred
Bug#761658: Please do not default to using Google nameservers
Am Sonntag, 29. März 2015, 07:18:43 schrieb Christoph Anton Mitterer: On Sun, 2015-03-29 at 06:55 +0200, Michael Biebl wrote: Am 29.03.2015 um 06:35 schrieb Christoph Anton Mitterer: I'm really not inclined to start another security discussion, since that's already lost cause in Debian... but the appropriate way would be to reopen this bug, solve it so that no data/privacy leakage happen... or perhaps to retitle Debian Windows, I don't really appreciate this tone. You're not really convincing anyone this way only putting people off. The tone wasn't impolite or offensive to anyone,... and that security is just amongst further goals in Debian is simply a matter of fact. And AFAIU the problem of data/privacy leakage isn't just made up, is it? If the system falls back to google nameservers they will now anything one tries to resolve. And $ geoiplookup 8.8.8.8 GeoIP Country Edition: US, United States shows that it won't be only Google who knows ;-) So what exactly is it that you don't like, cause I don't understand it. Seriously, Michael, just because someone didn't start a message with hugs and cookies doesn't mean he meant anything offensive or unfriendly. Or are there already Code of Conflict cases running against me now or Marco because he used the word lunacy on someone else's work o.O I highly appreciate if the default of using google name server if nothing else is configured is removed from Debian´s systemd. I had a similar issue with Debian packaged Wordpress which appears to try to download fonts from Google unless I install a plugin to disable this, which I didn´t yet report. But really, if there is no DNS server configured I expect name resolution to *fail*, instead of the system asking any DNS server of choice by some who was not me. At least unless there is a DNS service that provably doesn´t track and save queries of users of it. As thats near to impossible to prove. And no, I do not want to have to configure the system for basic privacy. I do want this to be the default. This is Debian, no Google Play enabled Android device. So I kindly ask you to remove configuring some DNS server in systemd if the unlikely case none is configured elsewise. User desktops often use DHCP. Then they usually have DNS. And if someone configured network manually, for example for a server VM, please pretty please require that he gives a DNS server by itself. There are even cases where one may not want to have DNS resolution at all. If you want, add a dialog on desktop enviroment no dns server configured with choices like choose one from a list and enter one manually, but don´t do it implicetely. Users are not in control otherwise cause frankly, who would notice that the system would use Google name servers if none a configured? I bet most won´t even notice it. So they are *not* in control. Cause you can only be in control of what you *know*. I didn´t notice Wordpress accessing Google servers unless I installed Iceweasel request policy plugin. Thus I didn´t just sacrifice the privacy of myself, but also of my users *without* knowing so. I was very angry as I found out which remembers me to report a bug. I didn´t at that time as I even feared a harsh respone. If a systemd based system is used on a misconfigured router it may leak the privacy of any users behind it. I hope this gives a clear reasoning. Frankly I do not understand why this default has not already been removed long ago. Whats the case for *having* this as a default? Some minor convenience in the case someone messes up network configuration by not providing a DNS server? Just that it is in systemd upstream does not mean that it is good to have. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#781437: unblock: prosody/0.9.7-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package prosody
(explain the reason for the unblock here)
Security fix related to libidn (CVE-2015-2059)
(include/attach the debdiff against the package in testing)
gares@birba:~$ cat /tmp/debdiff
diff -Nru prosody-0.9.7/debian/changelog prosody-0.9.7/debian/changelog
--- prosody-0.9.7/debian/changelog 2014-10-25 10:42:47.0 +0200
+++ prosody-0.9.7/debian/changelog 2015-03-28 16:20:59.0 +0100
@@ -1,3 +1,10 @@
+prosody (0.9.7-2) unstable; urgency=high
+
+ * Apply upstream patch to validate UTF-8 strings before calling libidn
+(related to CVE-2015-2059)
+
+ -- Enrico Tassi gareuselesi...@debian.org Sat, 28 Mar 2015 16:20:07 +0100
+
prosody (0.9.7-1) unstable; urgency=medium
* New upstream release, really a minor fix over 0.9.6
diff -Nru prosody-0.9.7/debian/patches/0005-Validate-UTF-8-strings-before-
calling-libidn.patch prosody-0.9.7/debian/patches/0005-Validate-UTF-8-strings-
before-calling-libidn.patch
--- prosody-0.9.7/debian/patches/0005-Validate-UTF-8-strings-before-calling-
libidn.patch1970-01-01 01:00:00.0 +0100
+++ prosody-0.9.7/debian/patches/0005-Validate-UTF-8-strings-before-calling-
libidn.patch2015-03-28 16:20:59.0 +0100
@@ -0,0 +1,110 @@
+From: Enrico Tassi ga...@fettunta.org
+Date: Sat, 28 Mar 2015 16:17:35 +0100
+Subject: Validate UTF-8 strings before calling libidn
+
+---
+ util-src/encodings.c | 70
+---
+ 1 file changed, 67 insertions(+), 3 deletions(-)
+
+diff --git a/util-src/encodings.c b/util-src/encodings.c
+index b9b6160..898add1 100644
+--- a/util-src/encodings.c
b/util-src/encodings.c
+@@ -1,6 +1,7 @@
+ /* Prosody IM
+ -- Copyright (C) 2008-2010 Matthew Wild
+ -- Copyright (C) 2008-2010 Waqas Hussain
++-- Copyright (C) 1994-2015 Lua.org, PUC-Rio.
+ --
+ -- This project is MIT/X11 licensed. Please see the
+ -- COPYING file in the source package for more information.
+@@ -116,6 +117,65 @@ static const luaL_Reg Reg_base64[] =
+ { NULL, NULL}
+ };
+
++/*** UTF-8 /
++
++/*
++ * Adapted from Lua 5.3
++ * Needed because libidn does not validate that input is valid UTF-8
++ */
++
++#define MAXUNICODE0x10
++
++/*
++ * Decode one UTF-8 sequence, returning NULL if byte sequence is invalid.
++ */
++static const char *utf8_decode (const char *o, int *val) {
++ static unsigned int limits[] = {0xFF, 0x7F, 0x7FF, 0x};
++ const unsigned char *s = (const unsigned char *)o;
++ unsigned int c = s[0];
++ unsigned int res = 0; /* final result */
++ if (c 0x80) /* ascii? */
++ res = c;
++ else {
++ int count = 0; /* to count number of continuation bytes */
++ while (c 0x40) { /* still have continuation bytes? */
++ int cc = s[++count]; /* read next byte */
++ if ((cc 0xC0) != 0x80) /* not a continuation byte?
*/
++ return NULL; /* invalid byte sequence */
++ res = (res 6) | (cc 0x3F); /* add lower 6 bits
from cont. byte */
++ c = 1; /* to test next bit */
++ }
++ res |= ((c 0x7F) (count * 5)); /* add first byte */
++ if (count 3 || res MAXUNICODE || res = limits[count] ||
(0xd800 = res res = 0xdfff) )
++ return NULL; /* invalid byte sequence */
++ s += count; /* skip continuation bytes read */
++ }
++ if (val) *val = res;
++ return (const char *)s + 1; /* +1 to include first byte */
++}
++
++/*
++ * Check that a string is valid UTF-8
++ * Returns NULL if not
++ */
++const char* check_utf8 (lua_State *L, int idx, size_t *l) {
++ size_t pos, len;
++ const char *s = luaL_checklstring(L, 1, len);
++ pos = 0;
++ while (pos = len) {
++ const char *s1 = utf8_decode(s + pos, NULL);
++ if (s1 == NULL) { /* conversion error? */
++ return NULL;
++ }
++ pos = s1 - s;
++ }
++ if(l != NULL) {
++ *l = len;
++ }
++ return s;
++}
++
++
+ /* STRINGPREP */
+ #ifdef USE_STRINGPREP_ICU
+
+@@ -212,8 +272,8 @@ static int stringprep_prep(lua_State *L, const
Stringprep_profile *profile)
+ lua_pushnil(L);
+ return 1;
+ }
+- s = lua_tolstring(L, 1, len);
+- if (len = 1024) {
++ s = check_utf8(L, 1, len);
++ if (s == NULL || len = 1024 || len != strlen(s)) {
+ lua_pushnil(L);
+ return 1; /* TODO return error message */
+ }
+@@ -320,7 +380,11 @@ static int Lidna_to_unicode(lua_State *L) /**
idna.to_unicode(s) */
+ static int Lidna_to_ascii(lua_State *L) /**
Bug#761658: Please do not default to using Google nameservers
Am Sonntag, 29. März 2015, 08:28:20 schrieb martin f krafft: also sprach Christoph Anton Mitterer cales...@scientia.net [2015-03-29 07:18 +0200]: So if resolved is used - and I'd guess that's the long term goal - then people would automatically get resolving - always. Even when they have /etc/resolv.conf (possibly intentionally) left empty and AFAIU the manpage, one cannot unset it. I imagine that in a few years, /etc/resolv.conf will be obsolete and no longer used in most cases (cf. xorg.conf, and others). While this is a good development in terms of ease of use, it does put a whole lot more weight on default choices made by upstream and Debian. At the moment, systemd upstream and Debian basically embrace Google and require people who don't want that to do extra work. If that's a direction to go, then shouldn't postfix also be configured by default to relay mail via GMail? Frankly, nope. For the reasons I explained in my other post to this bug report. I understand better and better why I deleted my Google account some time ago. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#155835: libc6-dev: scanf a flag conflicts with C99
On Sat, Mar 28, 2015 at 07:46:37PM +, Jean-Michel Nirgal Vourgère wrote: I suppose it has been fixed. scanf(3) now includes a note about specific '%a' behaviour when -std=c99 is used. Yes, it looks like it's fixed (though your attached log does not show it); I cannot reproduce the issue either. Also, there's a long change log entry in /usr/share/doc/glibc-doc/ChangeLog.17.gz indicating changes that likely fixed this: 2007-09-17 Jakub Jelinek ja...@redhat.com * include/stdio.h (__isoc99_fscanf, __isoc99_scanf, __isoc99_sscanf, __isoc99_vscanf): New prototypes. (__isoc99_vsscanf, __isoc99_vfscanf): New prototypes, add libc_hidden_proto. * include/wchar.h (__isoc99_fwscanf, __isoc99_wscanf, __isoc99_swscanf, __isoc99_vwscanf): New prototypes. (__isoc99_vswscanf, __isoc99_vfwscanf): New prototypes, add libc_hidden_proto. * libio/stdio.h (fscanf, scanf, sscanf, vfscanf, vscanf, vsscanf): Redirect to __isoc99_* if strict ISO C99 or POSIX conformance requested. [...] Can we now close this bug? It looks like it can be closed. If you can figure out what version the above changelog entry attaches to, you can also deduce an appropriate fixed version. -- Antti-Juhani Kaijanaho signature.asc Description: Digital signature
Bug#779259: gnunet: Bug in gnunet.postinst causes gnunet to remain unconfigured by dpkg
Dear user, Thank you for submitting this bug. I will need more info to understand the issue. The line 26 is indeed about setting the value of GNUNET_HOME based on the conf file settings, in case you changed it. Could you send me your version of /etc/gnunet.conf (at the bottom of your message, it is written if was changed) and the output of: grep GNUNET_HOME /etc/gnunet.conf | tr -d [:blank:] Thank you for your help, Bertrand signature.asc Description: OpenPGP digital signature
Bug#781455: RFS: util-linux/2.25.2-5.1 (fixing `unshare -r` regression) [NMU]
Package: sponsorship-requests
Severity: important
Tags: upstream patch
Hello up there,
Recently I've discovered that `unshare -r`, though it used to work in
2014, stopped working for Jessie:
https://bugs.debian.org/780841
The fix was pre-ack'ed by util-linux maintainer (Andreas Henriksson)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780841#10
and pre-approved by RT member Niels Thykier on debian-release@l.d.o:
https://lists.debian.org/debian-release/2015/03/msg00661.html
and then a proper unblock request filed:
https://bugs.debian.org/781163
Since I have no upload rights, in unblock request I've only presented a diff
for source package, and this way Niels suggested I should upload package with
the fix to mentors.debian.net and seek for a sponsor:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781163#22
which I do here.
Please, someone could you please sponsor this upload with important (imho) fix
to make `unshare -r` work again for Jessie? The fix was pre-approved by Andreas,
but somehow it turned out it is me who should care about actual upload being
done.
Thanks beforehand,
Kirill
P.S. proposed debdiff to util-linux/2.25.2-5 (current sid/jessie version)
follows:
8
diff --git a/debian/changelog b/debian/changelog
index 7850238..0d80c1b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+util-linux (2.25.2-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Cherry-pick `unshare -r` fix from upstream. (Closes: #780841)
+
+ -- Kirill Smelkov k...@nexedi.com Wed, 25 Mar 2015 16:23:34 +0300
+
util-linux (2.25.2-5) unstable; urgency=medium
* Revert Trigger update of initramfs on upgrades (Closes: #773354)
diff --git a/debian/patches/series b/debian/patches/series
index 6428b26..577ad52 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -17,3 +17,4 @@ Update-Japanese-translation.patch
Update-Russian-translation.patch
Trivial-unfuzzy.patch
libblkid-care-about-unsafe-chars-in-cache.patch
+unshare-Fix-map-root-user-to-work-on-new-kernels.patch
diff --git
a/debian/patches/unshare-Fix-map-root-user-to-work-on-new-kernels.patch
b/debian/patches/unshare-Fix-map-root-user-to-work-on-new-kernels.patch
new file mode 100644
index 000..9a469c1
--- /dev/null
+++ b/debian/patches/unshare-Fix-map-root-user-to-work-on-new-kernels.patch
@@ -0,0 +1,71 @@
+From: Eric W. Biederman ebied...@xmission.com
+Date: Wed, 17 Dec 2014 17:06:03 -0600
+Subject: [PATCH] unshare: Fix --map-root-user to work on new kernels
+Origin:
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit?id=0bf159413bdb9e324864a422b7aecb081e739119
+
+In rare cases droping groups with setgroups(0, NULL) is an operation
+that can grant a user additional privileges. User namespaces were
+allwoing that operation to unprivileged users and that had to be
+fixed.
+
+Update unshare --map-root-user to disable the setgroups operation
+before setting the gid_map.
+
+This is needed as after the security fix gid_map is restricted to
+privileged users unless setgroups has been disabled.
+
+Signed-off-by: Eric W. Biederman ebied...@xmission.com
+---
+ include/pathnames.h | 1 +
+ sys-utils/unshare.c | 19 +++
+ 2 files changed, 20 insertions(+)
+
+diff --git a/include/pathnames.h b/include/pathnames.h
+index 0d21b98..cbc93b7 100644
+--- a/include/pathnames.h
b/include/pathnames.h
+@@ -93,6 +93,7 @@
+
+ #define _PATH_PROC_UIDMAP /proc/self/uid_map
+ #define _PATH_PROC_GIDMAP /proc/self/gid_map
++#define _PATH_PROC_SETGROUPS /proc/self/setgroups
+
+ #define _PATH_PROC_ATTR_CURRENT /proc/self/attr/current
+ #define _PATH_PROC_ATTR_EXEC /proc/self/attr/exec
+diff --git a/sys-utils/unshare.c b/sys-utils/unshare.c
+index fccdba2..9fdce93 100644
+--- a/sys-utils/unshare.c
b/sys-utils/unshare.c
+@@ -39,6 +39,24 @@
+ #include pathnames.h
+ #include all-io.h
+
++static void disable_setgroups(void)
++{
++ const char *file = _PATH_PROC_SETGROUPS;
++ const char *deny = deny;
++ int fd;
++
++ fd = open(file, O_WRONLY);
++ if (fd 0) {
++ if (errno == ENOENT)
++ return;
++ err(EXIT_FAILURE, _(cannot open %s), file);
++ }
++
++ if (write_all(fd, deny, strlen(deny)))
++ err(EXIT_FAILURE, _(write failed %s), file);
++ close(fd);
++}
++
+ static void map_id(const char *file, uint32_t from, uint32_t to)
+ {
+ char *buf;
+@@ -181,6 +199,7 @@ int main(int argc, char *argv[])
+ }
+
+ if (maproot) {
++ disable_setgroups();
+ map_id(_PATH_PROC_UIDMAP, 0, real_euid);
+ map_id(_PATH_PROC_GIDMAP, 0, real_egid);
+ }
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781456: udisks2: udisksd eats 100% cpu while looping through all devices on md0
Package: udisks2
Version: 2.1.5-1
Severity: important
ps shows udisksd eating 100% cpu:
15849 root 20 0 378856 9084 6752 R 99,3 0,1 134:13.88 udisksd
strace shows that it's just looping throug all devices that are part of md0
array:
readlink(/sys/devices/virtual/block/md0/md/dev-sdd1/block,
../../../../../pci:00/:0..., 4095) = 84
lstat(/sys, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat(/sys/devices, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/virtual, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/virtual/block, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/virtual/block/md0, {st_mode=S_IFDIR|0755, st_size=0, ...})
= 0
lstat(/sys/devices/virtual/block/md0/md, {st_mode=S_IFDIR|0755, st_size=0,
...}) = 0
lstat(/sys/devices/virtual/block/md0/md/dev-sdd1, {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat(/sys/devices/pci:00, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2, {st_mode=S_IFDIR|0755, st_size=0,
...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata4, {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata4/host3, {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdd,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdd/sdd1,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open(/sys/devices/virtual/block/md0/md/dev-sdd1/state, O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, in_sync\n, 4096) = 8
read(16, , 4088) = 0
close(16) = 0
open(/sys/devices/virtual/block/md0/md/dev-sdd1/slot, O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, 0\n, 4096) = 2
read(16, , 4094) = 0
close(16) = 0
open(/sys/devices/virtual/block/md0/md/dev-sdd1/errors, O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, 0\n, 4096) = 2
read(16, , 4094) = 0
close(16) = 0
readlink(/sys/devices/virtual/block/md0/md/dev-sde1/block,
../../../../../pci:00/:0..., 4095) = 84
lstat(/sys, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat(/sys/devices, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/virtual, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/virtual/block, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/virtual/block/md0, {st_mode=S_IFDIR|0755, st_size=0, ...})
= 0
lstat(/sys/devices/virtual/block/md0/md, {st_mode=S_IFDIR|0755, st_size=0,
...}) = 0
lstat(/sys/devices/virtual/block/md0/md/dev-sde1, {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat(/sys/devices/pci:00, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2, {st_mode=S_IFDIR|0755, st_size=0,
...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata5, {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata5/host4, {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0/4:0:0:0,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sde,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat(/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sde/sde1,
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open(/sys/devices/virtual/block/md0/md/dev-sde1/state, O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, in_sync\n, 4096) = 8
read(16, , 4088) = 0
close(16) = 0
open(/sys/devices/virtual/block/md0/md/dev-sde1/slot, O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, 2\n, 4096) = 2
read(16, , 4094) = 0
close(16) = 0
open(/sys/devices/virtual/block/md0/md/dev-sde1/errors, O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, 0\n, 4096) = 2
read(16, , 4094) = 0
close(16)
and
Bug#781305: unblock: flash-kernel/3.34
On Sat, 2015-03-28 at 19:04 +, Adam D. Barratt wrote: On Fri, 2015-03-27 at 10:01 +, Ian Campbell wrote: Please unblock package flash-kernel both deb and udeb. flash-kernel-installer will automatically install u-boot-tools as needed, so installation via the installer works fine, however users who do things manually (i.e. with debootstrap) are frequently caught out by the lack of u-boot-tools. Since u-boot-tools is needed on the majority of systems these days and in any case is quite small bump the Suggests into a Recommends. Unblocked, Thanks. CCing for a KiBiack. Seems my X-debbugs-cc failed somehow, so thanks! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781458: ITP: node-engine.io-parser -- JavaScript parser for the engine.io protocol encoding
Package: wnpp Severity: wishlist Owner: Bas Couwenberg sebas...@debian.org * Package name: node-engine.io-parser Version : 1.2.1 Upstream Author : Automattic d...@cloudup.com * URL : https://github.com/Automattic/engine.io-parser * License : MIT Programming Lang: JavaScript Description : JavaScript parser for the engine.io protocol encoding engine.io-parser is the JavaScript parser for the engine.io protocol encoding, shared by both engine.io-client and engine.io. engine.io is the realtime engine behind Socket.IO. It provides the foundation of a bidirectional connection between client and server in Node.js. node-engine.io-parser is required for node-engine.io (#781426), which in turn is required for node-socket.io (#707166). The node-engine.io-parser package will be maintained in the JavaScript team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781221: opensc: New beid card not working anymore
tag 781221 + patch thanks Hello, A patch that fix this issue has been merged upstream, see https://github.com/OpenSC/OpenSC/commit/5149dd3e62594eb2477f699d834584991ab54d5f.patch Could this patch be applied before the jessie release? Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On 03/29/2015 05:02 PM, gregor herrmann wrote:
On Sun, 29 Mar 2015 16:44:07 +0200, Kasper Loopstra wrote:
I'm not sure where to go from here? Should I wait until #781120 is
resolved in jessie, or continue trying to figure out what's wrong?
The fix will only print a better error message, i.e. _which_ file
emits the Permission denied message.
But you should be able to find this out by something like:
# su -l debian-spamd
$ perl -MList::Util -e 'print $INC{strict.pm}'
/usr/share/perl/5.20/strict.pm$
I tried, but apparently there's more wrong than just strict.pm.
root@chloromethane:~# su -l debian-spamd
$ perl -MList::Util -e 'print $INC{strict.pm}'
Can't locate List/Util.pm: Permission denied.
BEGIN failed--compilation aborted.
No luck with perl -V either:
$ perl -V
Can't locate Config.pm: Permission denied.
BEGIN failed--compilation aborted.
$ perl -e print \@INC\
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
/usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20
/usr/share/perl/5.20 /usr/local/lib/site_perl .$
for i in $(perl -e print \@INC\); do find $i -type d -not -perm
-o=rx; done$
find: `/usr/local/lib/x86_64-linux-gnu/perl/5.20.2': No such file or
directory
find: `/usr/local/share/perl/5.20.2': Permission denied
find: `/usr/local/lib/site_perl': No such file or directory
./sa-update-keys
./.spamassassin
$
root@chloromethane:~# cd /usr/local/
root@chloromethane:/usr/local# ls -la
total 20
drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 .
drwxr-xr-x 12 root root 4096 Mar 29 12:50 ..
drwxr-xr-x+ 4 root root 4096 Mar 29 13:40 lib
drwxr-x---+ 2 root root 4096 Mar 29 12:31 sbin
drwxr-x---+ 5 root root 4096 Mar 29 13:35 share
chmod o+x share
And everything works after apt-get install -f.
Thank you very much!
However, I am quite sure that I removed /usr/local/share before starting
off with the upgrade, so perhaps there is something wrong with the
upgrade path between wheezy and jessie. So below is what's in the
/usr/local/share after an upgrade. Is there anything wrong here? Or
shouldn't I have removed /usr/local/share without recreating it with
correct permissions?
root@chloromethane:/usr/local# ls -la share/
total 20
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 .
drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 ..
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 ca-certificates
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 emacs
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 texmf
root@chloromethane:/usr/local# ls -laR share/
share/:
total 20
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 .
drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 ..
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 ca-certificates
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 emacs
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 texmf
share/ca-certificates:
total 8
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 .
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 ..
share/emacs:
total 16
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 .
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 ..
drwxrwsr-x+ 3 root staff 4096 Mar 29 13:35 24.4
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:35 site-lisp
share/emacs/24.4:
total 12
drwxrwsr-x+ 3 root staff 4096 Mar 29 13:35 .
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 ..
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:35 site-lisp
share/emacs/24.4/site-lisp:
total 8
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:35 .
drwxrwsr-x+ 3 root staff 4096 Mar 29 13:35 ..
share/emacs/site-lisp:
total 8
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:35 .
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 ..
share/texmf:
total 8
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 .
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 ..
root@chloromethane:/usr/local#
Thanks again to all,
Kasper Loopstra.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781459: udd: please provide dumps more often
package: qa.debian.org user: qa.debian@packages.debian.org usertag: udd From #debian-qa@OFTC mapreri lucas: might I ask you to provide udd dumps more often than daily? like, every 6 hours? this would greatly help the public udd mirror to stay in sync (and I guess it could also help others, to avoid doing things like what formorer complained the other day) lucas mapreri: yes, but it would also be useful to switch to another dump format lucas mapreri: could you ask by mail? that way I could Cc the other users of the UDD dumps, and see if we can come up with something that works for everyone So, here it is. Other than more frequent dumps I'd also welcome a different dump format, maybe smaller, to avoid downloading nearly 900MB every time I have to test something. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: Digital signature
Bug#781461: xul-ext-zotero: Zotero is unable to store any citation
Package: xul-ext-zotero Version: 4.0.22-1 Severity: normal Hi, when trying Zotero the first time I get the following error message in German locale (if you tell me how I could switch to English locale I'd happily provide the English version but LANG=en_EN.utf8 LC_ALL=en_EN iceweasel did not help): Eintrag konnte nicht gespeichert werden Ein Fehler ist aufgetreten beim Versuch diesen Artikel zu speichern. Überprüfen Sie Probleme mit derm Übersetzer beheben [links to https://www.zotero.org/support/troubleshooting_translator_issues] für weiter Informationen. Please note that I tried *several* citation cites of different publications and had not a single successful entry added. Kind regards and thanks for maintaining Zotero Andreas. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (501, 'testing'), (500, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-zotero depends on: ii iceweasel 36.0.4-1 xul-ext-zotero recommends no packages. xul-ext-zotero 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#626033: [gwenview] Export shortcuts do not work when menu is hidden
forwarded 626033 https://bugs.kde.org/show_bug.cgi?id=345664 thanks Hi, I am able to reproduce your bug, so I just forward it upsteam. You can follow the progress on the KDE bug tracker : https://bugs.kde.org/show_bug.cgi?id=345664 Regards, Adrien signature.asc Description: This is a digitally signed message part.
Bug#781451: gcc-5 uninstallable: /usr/share/doc/gcc-5-base/changelog.gz conflicts with gcc-5-base
Control: severity -1 serious Control: tags -1 + pending -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781460: trying to overwrite '/usr/share/doc/gcc-5-base/changelog.gz', which is also in package gcc-5 5-20150327-1
please check the bug tracker before filing duplicate bug reports. On 03/29/2015 05:52 PM, 積丹尼 Dan Jacobson wrote: Package: gcc-5-base Version: 5-20150327-1 Unpacking gcc-5-base:i386 (5-20150327-1) over (5-20150321-1) ... dpkg: error processing archive /var/cache/apt/archives/gcc-5-base_5-20150327-1_i386.deb (--unpack): trying to overwrite '/usr/share/doc/gcc-5-base/changelog.gz', which is also in package gcc-5 5-20150327-1 Processing triggers for man-db (2.7.1-2) ... Errors were encountered while processing: /var/cache/apt/archives/gcc-5-base_5-20150327-1_i386.deb etc. etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781462: unblock: debian-med/2.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-med According to previous discussion about Blends metapackages[1] I'd like you to unblock debian-med 2.0. I hereby comment the changelog to add some explanation to the debdiff that contains some larger autogenerated changes: * Fixed syntax of med-cloud and rerender dependencies -- there was a syntax issue in one task which rendered one metapackage unusable (serious) * Versioned Build-Depends: blends-dev (= 0.6.92.2) to ensure no packages from non-free or unstable will be included by accident -- Make sure package does not build with broken blends-dev where bug #768011 is fixed * Since last metapackage creation (and before freeze) the following packages made it into testing: fastaq, relion-bin + librelion-dev These were adde to the list of Recommends -- As the changelog entry says two relevant packages made their way into testing which results in autogenerated changes (moving the packages from Suggests to Recommends) * After the freeze the package psychopy was removed from testing and thus it is removed from Recommends -- Due to the removal of psychopy from testing the current debian-med packages (1.99) contain an invalid Recommends from this package. This upload moved the package from Recommends to Suggests. (This is exactly the issue discussed in [1]). A complete debdiff is attached. Thanks for working on the Debian release Andreas. [1] https://lists.debian.org/debian-release/2014/11/msg01092.html unblock debian-med/2.0 -- System Information: Debian Release: 7.8 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=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781163: unblock (pre-approved): util-linux/2.25.2-5.1
On Sat, Mar 28, 2015 at 07:41:40PM +0100, Niels Thykier wrote: On 2015-03-26 07:54, Kirill Smelkov wrote: [...] Hi Niels. Thanks for replying and yes, I do need some kind of sponsorship/help with upload as I do not have upload rights (I'm not a Debian developer nor Debian member - currently just a person from outside). I would be glad if you, or someone else, sponsor me with this upload, and this way I'll also start to slowly becoming a bit more involved with Debian which I was thinking about for a long time, but had no occasion to start. Thanks again, Kirill Hi Kirill, Ok, you probably want to file an RFS bug against sponsorship-requests[1] (and maybe also ask on #debian-mentors if you use IRC) if you have not already done so. Hi Niels, Thanks for suggesting this. I just did: https://bugs.debian.org/781455 https://mentors.debian.net/package/util-linux Hope it is ok, and thanks beforehand for probably reviewing/sponsoring it, Kirill -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781455: Acknowledgement (RFS: util-linux/2.25.2-5.1 (fixing `unshare -r` regression) [NMU])
P.S. uploaded package is here: http://mentors.debian.net/package/util-linux http://mentors.debian.net/debian/pool/main/u/util-linux/util-linux_2.25.2-5.1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769718: tp-smapi-dkms: tp-smapi.ko does not load
The attachment. Alberto On Sun, Mar 29, 2015 at 05:00:24PM +0200, alberto maurizi wrote: Hi Evgeni, I realized only now that my bugreport got a reply from you (I haven't received any email from the bug tracking system: probably a misconfiguration from my part). Well, you are right, I used to add tp_smapi to my /etc/modules, however this does not work: if I put tp_smapi in /etc/modules I get an error during boot. I'm sorry I cannot find the boot log anywhere (even if I installed bootlogd, the /var/log/boot is empty). In any case, the process through the /etc/modules should be equivalent to issuing as root modprobe tp_smapi but I get the following: modprobe: ERROR: could not insert 'tp_smapi': No such device or address The same if I try with thinkpad_ec that, I remember, I also used before reinstalling everything. And hdaps behaves exactly the same. I got nothing strange during the package install process (see attached file). I'm available for any test you may want me to run. Alberto -- Alberto Maurizi a.maur...@isac.cnr.it ISAC-CNR Phone n. +39 051 639 9615 via Gobetti 101 Fax n. +39 051 639 9658 40129 Bologna, Italy home page:http://bolchem.isac.cnr.it/staff:alberto_maurizi.do bolchem project: http://bolchem.isac.cnr.it -- Alberto Maurizi a.maur...@isac.cnr.it ISAC-CNR Phone n. +39 051 639 9615 via Gobetti 101 Fax n. +39 051 639 9658 40129 Bologna, Italy home page: http://bolchem.isac.cnr.it/staff:alberto_maurizi.do bolchem project:http://bolchem.isac.cnr.it Selecting previously unselected package tp-smapi-dkms. (Reading database ... 586977 files and directories currently installed.) Preparing to unpack .../tp-smapi-dkms_0.41-1_all.deb ... Unpacking tp-smapi-dkms (0.41-1) ... Setting up tp-smapi-dkms (0.41-1) ... Creating symlink /var/lib/dkms/tp-smapi/0.41/source - /usr/src/tp-smapi-0.41 DKMS: add completed. Kernel preparation unnecessary for this kernel. Skipping... Building module: cleaning build area make KERNELRELEASE=3.16.0-4-amd64 -C /lib/modules/3.16.0-4-amd64/build M=/var/lib/dkms/tp-smapi/0.41/build. cleaning build area DKMS: build completed. thinkpad_ec: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/3.16.0-4-amd64/updates/dkms/ tp_smapi.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/3.16.0-4-amd64/updates/dkms/ hdaps.ko: Running module version sanity check. - Original module - Installation - Installing to /lib/modules/3.16.0-4-amd64/updates/dkms/ depmod DKMS: install completed.
Bug#769718: tp-smapi-dkms: tp-smapi.ko does not load
Hi Evgeni, I realized only now that my bugreport got a reply from you (I haven't received any email from the bug tracking system: probably a misconfiguration from my part). Well, you are right, I used to add tp_smapi to my /etc/modules, however this does not work: if I put tp_smapi in /etc/modules I get an error during boot. I'm sorry I cannot find the boot log anywhere (even if I installed bootlogd, the /var/log/boot is empty). In any case, the process through the /etc/modules should be equivalent to issuing as root modprobe tp_smapi but I get the following: modprobe: ERROR: could not insert 'tp_smapi': No such device or address The same if I try with thinkpad_ec that, I remember, I also used before reinstalling everything. And hdaps behaves exactly the same. I got nothing strange during the package install process (see attached file). I'm available for any test you may want me to run. Alberto -- Alberto Maurizi a.maur...@isac.cnr.it ISAC-CNR Phone n. +39 051 639 9615 via Gobetti 101 Fax n. +39 051 639 9658 40129 Bologna, Italy home page: http://bolchem.isac.cnr.it/staff:alberto_maurizi.do bolchem project:http://bolchem.isac.cnr.it -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781460: trying to overwrite '/usr/share/doc/gcc-5-base/changelog.gz', which is also in package gcc-5 5-20150327-1
Package: gcc-5-base Version: 5-20150327-1 Unpacking gcc-5-base:i386 (5-20150327-1) over (5-20150321-1) ... dpkg: error processing archive /var/cache/apt/archives/gcc-5-base_5-20150327-1_i386.deb (--unpack): trying to overwrite '/usr/share/doc/gcc-5-base/changelog.gz', which is also in package gcc-5 5-20150327-1 Processing triggers for man-db (2.7.1-2) ... Errors were encountered while processing: /var/cache/apt/archives/gcc-5-base_5-20150327-1_i386.deb etc. etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781198: pidgin: Pidgin crashes after some time
2015-03-29 17:53 GMT+02:00 Ari Pollak a...@debian.org: On 03/29/2015 05:23 AM, Mosè Giordano wrote: I checked Pulseaudio settings with pavucontrol, there is no reference to JACK in output devices. How can I check gstreamer configuration without gstreamer-properties, so without pulling down gnome-media package and its 138 MiB of dependencies (I'm running KDE)? Try this: gconftool -R /system/gstreamer/0.10/default % gconftool -R /system/gstreamer/0.10/default videosink = autovideosink chataudiosink = autoaudiosink audiosink = autoaudiosink videosrc = v4l2src visualization = goom audiosink_description = Default musicaudiosink = autoaudiosink chataudiosink_description = Default audiosrc_description = Default audiosrc = autoaudiosrc musicaudiosink_description = Default Also install libglib2.0-bin and then run this: gsettings list-recursively org.freedesktop.gstreamer-0.10.default-elements % gsettings list-recursively org.freedesktop.gstreamer-0.10.default-elements org.freedesktop.gstreamer-0.10.default-elements music-audiosink 'autoaudiosink' org.freedesktop.gstreamer-0.10.default-elements music-audiosink-description 'Default' org.freedesktop.gstreamer-0.10.default-elements sounds-audiosink 'autoaudiosink' org.freedesktop.gstreamer-0.10.default-elements videosink-description 'Default' org.freedesktop.gstreamer-0.10.default-elements videosink 'autovideosink' org.freedesktop.gstreamer-0.10.default-elements videosrc-description 'Default' org.freedesktop.gstreamer-0.10.default-elements videosrc 'v4l2src' org.freedesktop.gstreamer-0.10.default-elements visualization-description 'Default' org.freedesktop.gstreamer-0.10.default-elements visualization 'goom' org.freedesktop.gstreamer-0.10.default-elements chat-audiosink 'autoaudiosink' org.freedesktop.gstreamer-0.10.default-elements audiosrc 'alsasrc' org.freedesktop.gstreamer-0.10.default-elements chat-audiosink-description 'Default' org.freedesktop.gstreamer-0.10.default-elements audiosrc-description 'Default' org.freedesktop.gstreamer-0.10.default-elements sounds-audiosink-description 'Default' There are also some sound output settings within Pidgin. Sound method is set to Automatic here. I should mention I have this issue since no more than a couple of weeks or so, before that Pidgin never crashed. I didn't changed anything in Pidgin recently. Bye, Mosè -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
Dear Niko, I recently did a new upgrade on a copy of the same system, but before the upgrade I moved everything in /usr/local to a backup location, and only replaced some scripts in /usr/local/sbin we use to restart our LDAP server and such. On 03/24/2015 08:35 PM, Niko Tyni wrote: Also, just /usr/local/lib/site_perl doesn't explain your problem as strict.pm should be earlier on the search path. Is /etc/perl, /usr/local/share/perl, /usr/local/lib, or something like that non-readable too? Does /usr/share/perl/5.20/strict.pm exist? root@chloromethane:/usr/local# stat /usr/share/perl/5.20/strict.pm File: ‘/usr/share/perl/5.20/strict.pm’ Size: 1006Blocks: 8 IO Block: 4096 regular file Device: 807h/2055d Inode: 272273 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2015-03-29 13:00:59.525885644 +0200 Modify: 2015-03-01 23:35:21.0 +0100 Change: 2015-03-29 13:00:32.550411188 +0200 Birth: - After some chmod o+r and +x on directories listed in perl -V, I'm getting new errors: Setting up spamassassin (3.4.0-6) /usr/bin/perl: error while loading shared libraries: libperl.so.5.20: cannot open shared object file: No such file or directory This is worse than it was when you started. It looks like you either removed permissions somewhere instead of adding them, or your file system is getting corrupted somehow. The file libperl.so.5.20 should be in /usr/lib/x86_64-linux-gnu and world readable. It's there, and a symlink to libperl.so.5.20.2, which is 644. Additionally, this is a fresh clone, so I'm not getting the .so error anymore, now it's just the permission denied. I am not exactly sure what permissions should be on what files. Any ideas on how to recover this systems Perl back to a usable state? Generally the directories should me root:root, mode 755. For reference, this is how the @INC permissions and symlinks look on my system: drwxr-xr-x 5 root root 4096 Oct 5 2013 /etc/perl lrwxrwxrwx 1 root root 6 Feb 27 20:14 /usr/lib/x86_64-linux-gnu/perl/5.20 - 5.20.2 drwxr-xr-x 32 root root 4096 Mar 1 20:47 /usr/lib/x86_64-linux-gnu/perl/5.20.2 drwxr-xr-x 93 root root 4096 Mar 21 21:16 /usr/lib/x86_64-linux-gnu/perl5/5.20 drwxr-xr-x 189 root root 12288 Feb 28 00:22 /usr/share/perl5 lrwxrwxrwx 1 root root 6 Feb 27 20:14 /usr/share/perl/5.20 - 5.20.2 drwxr-xr-x 58 root root 12288 Mar 1 20:47 /usr/share/perl/5.20.2 but if you've changed other permissions as well, it becomes rather hard to help. Possibly the best start is to reinstall perl, perl-base, perl-modules, and libperl5.20 with dpkg. apt-get --reinstall install perl perl-base perl-modules lib perl5.20 [...] Preparing to unpack .../perl-modules_5.20.2-2_all.deb ... Unpacking perl-modules (5.20.2-2) over (5.20.2-2) ... Preparing to unpack .../perl_5.20.2-2_amd64.deb ... Unpacking perl (5.20.2-2) over (5.20.2-2) ... Preparing to unpack .../libperl5.20_5.20.2-2_amd64.deb ... Unpacking libperl5.20 (5.20.2-2) over (5.20.2-2) ... Processing triggers for man-db (2.7.0.2-5) ... Setting up libperl5.20 (5.20.2-2) ... Setting up perl-modules (5.20.2-2) ... Setting up perl (5.20.2-2) ... [...] Setting up spamassassin (3.4.0-6) ... Can't locate strict.pm: Permission denied at /usr/bin/sa-update line 23. BEGIN failed--compilation aborted at /usr/bin/sa-update line 23. dpkg: error processing package spamassassin (--configure): subprocess installed post-installation script returned error exit status 13 dpkg: dependency problems prevent configuration of sa-compile: sa-compile depends on spamassassin (= 3.3.2-8); however: Package spamassassin is not configured yet. dpkg: error processing package sa-compile (--configure): dependency problems - leaving unconfigured Additionally, following the advice in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781120 I've ran the following, believing that this should find any files or directories with incorrect permissions: for i in $(perl -e print \@INC\); do find $i -type d -not -perm -o=rx; done for i in $(perl -e print \@INC\); do find $i -type f -not -perm -o=x; done Neither command finds anything, and only complains about /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/local/lib/site_perl not existing. I'm not sure where to go from here? Should I wait until #781120 is resolved in jessie, or continue trying to figure out what's wrong? As far as I know, the system we're using never had any special Perl stuff happening to it, but it has been upgraded from squeeze (or maybe etch) over the last years. Should I raise a bug with the perl package? I'm not yet convinced this is a perl bug rather than a local problem. Thank you very much for the help with a local configuration issue :) Thanks again, Kasper Loopstra. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#780640: gcc-5: merge gnat back to gcc
On Thu, Mar 26, 2015 at 10:10 PM, YunQiang Su wzss...@gmail.com wrote: On Tue, Mar 24, 2015 at 11:24 PM, Matthias Klose d...@debian.org wrote: some comments: - please add appropriate changelog entries Added * Rewrite patches for libgnat build, and add mips64el support. * Use the same scheme as gcc etc for gnat commands: aka gnat-5 - triplet-gnat-5. - don't rely on autogen during the build. I was just happy to get rid off it. I think it's fine to keep the auto generated toplevel Makefile. It doesn't change that often. OK, add a patch named: src-Makefile-autogen.diff I think it makes sense to build gnat out of the gcc-5 source package. I talked to Ludovic about this at Fosdem, and he didn't have major concerns. And probably he'll update Ada only once during the next release cycle, and that likely will be for GCC 6. I switch gnat off in gcc by default. So we can still use gnat-5 packages. I tested it on amd64, it build well. I saw you merged gnat back to gcc, then why are you still use the old flavor? aka, the command is gnat not gnat-5. This way will make cross build impossible. Any consideration? -- YunQiang Su -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
Control: tags -1 pending On 2014-12-15 17:00, Svante Signell wrote: [...] Hi I trimmed the patch, less text now. However, the LILO comment is still there. Do you want me to remove that one too? Hi, I have applied a minor patch to day based on your patch submitted here (See attached). First hunk was accepted as-is (modulo whitespace). From the rest, I extracted some minor pieces if not already documented else where. In particular: * I documented that installing systemd-shim and sysvinit-core manually might help APT and aptitude when the pin is in place. * The part of keeping sysvinit for having a fallback init was dropped as it (meanwhile) got covered in 4.1.4.2[4.1.4]. As the removal of sysvinit does not happen automatically, I asserted this was sufficient. * The [4.1.4.2] section also covers how to reboot using sysvinit as long as the bootloader supports changing the kernel command line prior to booting. I know grub supports this and [1] suggests LILO is also capable of doing this. A review is welcome - in particular please let me know if there are things I left out that you believe should be included regardless. Thanks, ~Niels [4.1.4] https://www.debian.org/releases/jessie/amd64/release-notes/ch-upgrading.en.html#recovery (The closest I could get to a direct link to 4.1.4.2) [1] http://docstore.mik.ua/orelly/linux/lnut/ch04_05.htm From f7b12fd75b034b3da8868b944e247fd7b1c72f51 Mon Sep 17 00:00:00 2001 From: nthykier nthykier@313b444b-1b9f-4f58-a734-7bb04f332e8d Date: Sun, 29 Mar 2015 14:40:44 + Subject: [PATCH] issues: Improve the systemd section a bit Signed-off-by: Niels Thykier ni...@thykier.net git-svn-id: svn+ssh://svn.debian.org/svn/ddp/manuals/trunk/release-notes@10678 313b444b-1b9f-4f58-a734-7bb04f332e8d --- en/issues.dbk | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/en/issues.dbk b/en/issues.dbk index c74cb38..cb69026 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -316,8 +316,11 @@ $ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf- para Jessie ships with systemitem role=packagesystemd-sysv/systemitem as -emphasisdefault/emphasis init system. If you have a -preference for another init such as systemitem +emphasisdefault/emphasis init system. This package is +installed automatically on upgrades. + /para + para +If you have a preference for another init such as systemitem role=packagesysvinit-core/systemitem or systemitem role=packageupstart/systemitem, it is recommended to setup APT pinning prior to the upgrade. This may also be required if @@ -325,7 +328,7 @@ $ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf- please refer to xref linkend=issues-lxc-wheezy-host /. /para paraAs an example, to prevent systemitem -role=packagesystemd/systemitem from being installed during the +role=packagesystemd-sysv/systemitem from being installed during the upgrade, you can create a file called filename/etc/apt/preferences.d/local-pin-init/filename with the following contents: @@ -349,6 +352,12 @@ Pin-Priority: -1 role=packagesystemd-sysv/systemitem package must be installed first. /para + para +If APT or aptitude issues computing an upgrade path with the pin +in place, you may be able to help it by manually installing both +systemitem role=packagesysvinit-core/systemitem and +systemitem role=packagesystemd-shim/systemitem. + /para section id=systemd-auto-mounts-incompat !-- Wheezy to Jessie -- titleStricter handling of failing mounts during boot under systemd/title -- 2.1.4
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On Sun, 29 Mar 2015 16:44:07 +0200, Kasper Loopstra wrote:
Setting up spamassassin (3.4.0-6) ...
Can't locate strict.pm: Permission denied at /usr/bin/sa-update line 23.
BEGIN failed--compilation aborted at /usr/bin/sa-update line 23.
dpkg: error processing package spamassassin (--configure):
subprocess installed post-installation script returned error exit
status 13
dpkg: dependency problems prevent configuration of sa-compile:
sa-compile depends on spamassassin (= 3.3.2-8); however:
Package spamassassin is not configured yet.
dpkg: error processing package sa-compile (--configure):
dependency problems - leaving unconfigured
Now it would be interesting to know where debian-spamd / sa-update
looks for perl modules ...
I'm not sure where to go from here? Should I wait until #781120 is
resolved in jessie, or continue trying to figure out what's wrong?
The fix will only print a better error message, i.e. _which_ file
emits the Permission denied message.
But you should be able to find this out by something like:
# su -l debian-spamd
$ perl -MList::Util -e 'print $INC{strict.pm}'
/usr/share/perl/5.20/strict.pm$
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/
`. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe
`- NP: Dire Straits: Tunnel Of Love
signature.asc
Description: Digital Signature
Bug#781457: ada bootstrap failure on mips and mipsel
Package: src:gcc-5 Version: 5-20150327-1 Severity: important Tags: sid stretch Forwarded: https://gcc.gnu.org/PR65618 seen building trunk 20150328. I'm not entirely sure if this is a regression. Apparently all distro builds for mips and mipsel set STAGE3_CFLAGS += -gtoggle (same as in stage2) in the past, and maybe were papering over the problem. If this workaround is really needed, we should limit the comparision failure to exactly the one failing file. Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/ada/a-except.o differs Makefile:22697: recipe for target 'compare' failed make[4]: *** [compare] Error 1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781406: pu: package tomcat7/7.0.28-4+deb7u1
Control: tags -1 + pending On Sat, 2015-03-28 at 16:12 -0300, Miguel Landaeta wrote: On Sat, Mar 28, 2015 at 06:58:33PM +, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sat, 2015-03-28 at 15:23 -0300, Miguel Landaeta wrote: Currently, tomcat7 can't be built in wheezy as it was reported on #780519. So, I'm proposing this upload for stable to fix that FTBFS bug. Please go ahead, thanks. Thanks for the prompt answer. I just uploaded it. Flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751892: udev: external media belong to disk group
On 30/03/15 02:41, Michael Biebl wrote: Am 30.03.2015 um 01:21 schrieb Dmitry Alexandrov: On 30/03/15 01:01, Michael Biebl wrote: The default policy shipped in Debian allows local desktop users to mount/umount/format etc removable media. ‘Format’? How? udisksctl(1) does mot provide such a possibility, as far as I see. Also, to my mind, an average desktop user is much less concerned about formating removable drives than *labeling* them. Could it be done without raw access to block devices? You can, indeed. gnome-disks [1] is a GUI frontend for udisks. Among others, it let's change the file system labels. I'm sure, other desktop environments provide similar functionality. If not, you should poke them. OK, thanks, it’s good that desktop environments took up this problem, but that is (or would be) both too complex and too local solutions. What about basics: a non-interactive utility like e2label(8) / fatlabel(8), that would allow one to make re-labelling easy by, for example, configuring a ‘user action’ for his favourite file manager? (By the way, it might worth noting how to re-label partition with gnome-disks(1) since it’s not quite obvious and does not explained in ‘GNOME Help’: select a device and select a partition → click a gear icon next to remove partition button (minus sign icon) → ‘Edit Filesystem’. I could not manage to do it with keyboard.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781410: Reply
Okay. I found a copy of it, and supplied it there. If it's not a bug, please close this. Thank you! John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
Hey Niels, Understood. Hard to see exactly what's going on here because we seem to be falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html. Do you happen to know if there's another way to get access to test-suite.log from these builds? The suggested work-around in that mailing list thread appears to require a change to the packaging, which I imagine we want to try and avoid. Cheers, Tom On Sun, Mar 29, 2015 at 4:45 AM, Niels Thykier ni...@thykier.net wrote: Source: capnproto Version: 0.4.1-3 Severity: serious Hi, It seems that the current version of capnproto FTBFS on armel and armhf due to a segmentation fault in one of the tests. This prevents the new version of migrating to testing as it is a regression compared to the version in testing. Thanks, ~Niels -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#781495: udisksctl lacks commands for labelling and formatting
Package: udisks2 Version: 2.1.3-5 Severity: normal While UDisks implements functions for labelling [0] and formatting [1] partitions and drives and, judging by gnome-disks(1), they are pretty working, udisksctl(1) does not provide a user interface for them. Not being something important by itself, in a couple with revoking raw access to removable block devices from users (bug #751892 [2]) this lack of feature presents a regression in Jessie for a user that wants re-label or re-format an USB-drive using a non-interactive utility: using e2label(8) / fatlabel(8) / mkfs(8) requires superuser rights now. [0]: http://udisks.freedesktop.org/docs/latest/UDisksFilesystem.html#udisks-filesystem-call-set-label [1]: http://udisks.freedesktop.org/docs/latest/UDisksBlock.html#udisks-block-call-format [2]: https://bugs.debian.org/751892 --- System information. --- Architecture: amd64 Kernel: Linux 3.16.0-4-amd64 Debian Release: 8.0 --- Package information. --- Depends (Version) | Installed ===-+-== libacl1 (= 2.2.51-8) | 2.2.52-2 libatasmart4 (= 0.13) | 0.19-3 libc6 (= 2.7) | libglib2.0-0 (= 2.31.18) | libgudev-1.0-0 (= 165) | libpolkit-agent-1-0 (= 0.99) | libpolkit-gobject-1-0(= 0.101) | libudisks2-0(= 2.0.91) | udev| dbus| parted | Recommends (Version) | Installed ==-+-=== policykit-1| 0.105-8 dosfstools | 3.0.27-1 ntfs-3g| 1:2014.2.15AR.2-1 eject | 2.1.5+deb1+cvs20081104-13.1 gdisk | 0.8.10-2 Suggests(Version) | Installed =-+-=== xfsprogs | reiserfsprogs | exfat-utils | 1.1.0-2 btrfs-tools | 3.17-1.1 mdadm | cryptsetup-bin| 2:1.6.6-5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781432: installation-reports: reformating of partition stalls at 33% with existent ext4 file system
Hi, and thanks for your report. Rolandas Naujikas rol...@gmail.com (2015-03-29): Package: installation-reports Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Reinstall to the same partition. * What exactly did you do (or not do) that was effective (or ineffective)? Choose the same partition to (re)format and install into. * What was the outcome of this action? I have to Alt+F2 and do mkfs.ext4 /dev/sda6. It gives me question about existent file system and I answered Y to format it. Killed hang mkfs.ext4 process and continued successfully installation without reformating this partition. * What outcome did you expect instead? Should debian installer confirm reformating of existent file system (destroying its data) ? Should it pass and answer automatically, because I already accepted that ? We've had some bug reports about this topic. The last time it popped up, I mention I'd test a fix for this (adding the force flag to the mkfs calls), but I didn't find time to do so before RC2. I've added a note about this topic on my RC3 to-do list. Mraw, KiBi. signature.asc Description: Digital signature
Bug#781498: Support syslog
Package: unattended-upgrades Version: 0.83.3 Severity: wishlist unattended-upgrades outputs some lines to a logfile like this: 2015-03-30 16:04:26,758 INFO Initial blacklisted packages: 2015-03-30 16:04:26,759 INFO Starting unattended upgrades script 2015-03-30 16:04:26,759 INFO Allowed origins are: ['origin=Debian,archive=jessie,label=Debian-Security'] 2015-03-30 16:04:29,871 INFO No packages found that can be upgraded unattended I can configure it to write to a different logfile, but I can't configure it to write to syslog. AFAICT that requires code change to use logging.SysLogHandler instead of / as well as logging.StreamHandler. offby1 of #python linked to some example code: https://gist.githubusercontent.com/offby1/a6132065dafac2a57451/raw/051650f492ac8fd6fc1a62aa57bb18daad48173e/logging_helpers.py (I want logs in syslog so logcheck can see them. Just pointing logcheck/syslog-summary at the existing file will result in weirdness because the timestamp formats are different.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781305: unblock: flash-kernel/3.34
Control: tag -1 confirmed
Ian Campbell i...@debian.org (2015-03-29):
On Sat, 2015-03-28 at 19:04 +, Adam D. Barratt wrote:
On Fri, 2015-03-27 at 10:01 +, Ian Campbell wrote:
Please unblock package flash-kernel both deb and udeb.
flash-kernel-installer will automatically install u-boot-tools as needed,
so
installation via the installer works fine, however users who do things
manually
(i.e. with debootstrap) are frequently caught out by the lack of
u-boot-tools.
Since u-boot-tools is needed on the majority of systems these days and in
any
case is quite small bump the Suggests into a Recommends.
Unblocked,
Thanks.
Yep, this change looks like a good idea, even if slightly too late for
RC2. ;)
CCing for a KiBiack.
Seems my X-debbugs-cc failed somehow, so thanks!
Nope, it didn't fail; the header is munged when the incoming bug
report is processed and only the recipient knows about it (at least
AFAI{R,CT} at this pre-coffee hour).
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#780426: svtplay-dl: --verbose option is undocumented
On 2015-03-22 00:29 +0100, Olof Johansson wrote: I've also written a script that will make sure the options available are all documented in the manpage, and will propose it to upstream for inclusion in the release process. My patches to the release process of svtplay-dl was integrated, and is included in the 10.2015.03.25 release of svtplay-dl. So from now on, not accounting for any bugs in my script :-), the manual page and the help text should now be in sync --- that is, you should not be able to do a release that introduce new options, without also documenting them in the manual. https://github.com/spaam/svtplay-dl/pull/221 (and some additional changes, after the pull request was merged) -- --- | Olof Johansson http://stdlib.se/ | | irc: zibri https://github.com/olof | --- signature.asc Description: Digital signature
Bug#781454: steam: Steam does not show up
Package: steam Version: 1.0.0.49-2 Severity: important Starting steam does correctly checking and if necessary downloading updates (download window appears). Afterwards nothing happens. No Window is showing up. The background updater seems to run as it is checking for updates from time to time as viewable on the terminal. If i manually return with gdb from the mutex stuff in Thread 1 it shows up an Error Window in grey steam look saying Fatal Error: Failed to load steamui.so I have a I5-2500K CPU with Intel HD 3000. Backtrace: Thread 3 (Thread 0xf58ffb40 (LWP 14832)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at .../nptl/sysdeps/unix/sysv/linux/i386/i586/../i486/pthread_cond_timedwait.S:246 #1 0x5666d932 in ?? () #2 0x5666e548 in ?? () #3 0x566550b4 in CWorkThread::Run() () #4 0x5666d7e6 in SteamThreadTools::CThread::ThreadExceptionWrapper(void*) () #5 0x5666bfc3 in ?? () #6 0x5666cba0 in ?? () #7 0x5666e7d6 in SteamThreadTools::CThread::ThreadProc(void*) () #8 0xf7d0cd97 in start_thread (arg=0xf58ffb40) at pthread_create.c:309 #9 0xf7c69dfe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 2 (Thread 0xf5b62b40 (LWP 14831)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at .../nptl/sysdeps/unix/sysv/linux/i386/i586/../i486/pthread_cond_timedwait.S:246 #1 0x5666d932 in ?? () #2 0x5666e548 in ?? () #3 0x565a210b in CSteamUpdater::DoBackgroundUpdateLoop() () #4 0x565a82c5 in CSteamUpdater::Run() () #5 0x5666d7e6 in SteamThreadTools::CThread::ThreadExceptionWrapper(void*) () #6 0x5666bfc3 in ?? () #7 0x5666cba0 in ?? () #8 0x5666e7d6 in SteamThreadTools::CThread::ThreadProc(void*) () #9 0xf7d0cd97 in start_thread (arg=0xf5b62b40) at pthread_create.c:309 #10 0xf7c69dfe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Thread 1 (Thread 0xf7b45700 (LWP 14827)): #0 __lll_lock_wait () at .../nptl/sysdeps/unix/sysv/linux/i386/i586/../i486/lowlevellock.S:146 #1 0xf7d0f009 in _L_lock_842 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf7d0ee40 in __GI___pthread_mutex_lock (mutex=0x56962d40) at .../nptl/pthread_mutex_lock.c:79 #3 0xf7e8ed8a in ?? () from /usr/lib/i386-linux-gnu/libX11.so.6 #4 0xf753f21f in ?? () from /usr/lib/libGL.so.1 #5 0xf75604e0 in ?? () from /usr/lib/libGL.so.1 #6 0xf7563ca9 in ?? () from /usr/lib/libGL.so.1 #7 0xf753e6e8 in ?? () from /usr/lib/libGL.so.1 #8 0xf753e757 in ?? () from /usr/lib/libGL.so.1 #9 0xf7e7d591 in XCloseDisplay () from /usr/lib/i386-linux-gnu/libX11.so.6 #10 0x565ad0f9 in CXWindowsUpdateUI::DestroyWindow() () #11 0x5657df3a in ?? () #12 0xf7bae723 in __libc_start_main (main=0x5657d1a0, argc=1, argv=0xd3a4, init=0x56844ba0 __libc_csu_init, fini=0x56844c10 __libc_csu_fini, rtld_fini=0xf7febc90 _dl_fini, stack_end=0xd39c) at libc-start.c:287 #13 0x56580ca5 in _start () -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.9 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages steam depends on: ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-15 ii libgl1-mesa-dri 10.3.2-1 ii libgl1-mesa-glx 10.3.2-1 ii libstdc++64.9.2-10 ii libtxc-dxtn-s2tc0 [libtxc-dxtn0] 0~git20131104-1.1 ii libudev1 215-12 ii libx11-6 2:1.6.2-3 ii libxinerama1 2:1.1.3-1+b1 ii xfce4-terminal [x-terminal-emulator] 0.6.3-1+b1 ii xterm [x-terminal-emulator] 312-2 ii xz-utils 5.1.1alpha+20120614-2+b3 Versions of packages steam recommends: ii fonts-liberation 1.07.4-1 ii zenity3.14.0-1 steam suggests no packages. -- debconf information: * steam/license: steam/purge: * steam/question: I AGREE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697643: workaround
OK, but i think this is bug and it may be solved. When ntpd -S says adjusting local clock by 3601.017312s adjtime failed: Invalid argument What about to call something like: int ntpd_adjtime(double d) tv=max(tv,ADJTIME_MAX); if (adjtime(max(tv), olddelta) == -1) log_warn(adjtime failed); return (synced); } Or report it as bug in adjtime? On Mon, 17 Jun 2013 10:40:58 +0200 Mario Frasca ma...@anche.no wrote: the main problem with this bug is that you can't start 'ntpd' if the time is not set approximatively correct from the start. take for example a computer without memory of the outside time (for example because its battery is faulty), then you somehow need bootstrap the procedure and chances are that you do not want to do this by hand. if you install 'ntpdate' and run it before 'ntpd' starts, things should go fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780925: DBD-Firebird: Buffer Overflow in dbdimp.c
-=| Damyan Ivanov, 21.03.2015 21:23:06 + |=- Package: libdbd-firebird-perl Version: 0.91-2 Severity: grave Tags: security upstream patch I have committed the patch in packaging Git¹. I have also committed another patch that replaces all sprintf() usage with snprintf(). Both patches were applied and released upstream (by me). ¹ https://anonscm.debian.org/cgit/pkg-perl/packages/libdbd-firebird-perl.git/log/ To avoid some mistake doe to too much self-confidence, I'd appreciate if others could take a look and state their opinion on whether this is suitable for jessie (and perhaps wheezy). TIA, dam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781449: wordpress-theme-twentyfifteen: privacy leak due to accessing Google servers for font/CSS download
Package: wordpress-theme-twentyfifteen Version: 4.1.1+dfsg-1 Severity: normal Dear maintainer, the themes references Google servers for downloading fonts or CSS: /usr/share/wordpress/wp-content/themes find -name *php* -or -name *.js | xargs egrep -ir googleapis ./twentyfourteen/functions.php: $font_url = add_query_arg( $query_args, '//fonts.googleapis.com/css' ); ./twentyfifteen/functions.php: ), '//fonts.googleapis.com/css' ); I only got aware of it after I installed Iceweasel Request Policy addon. I think this will give Google informations on the URLs the visitors of the wordpress site visit. And was quite angry as I found this out weeks after initially installing wordpress. I installed https://github.com/dimadin/disable-google-fonts to protect the privacy of the visitors of my wordpress site. According to Request Policy plugin this appears to work. I know that patching the theme to avoid accessing Google servers is extra maintenance work and may alter the appearence of the theme. For me wordpress looks well enough that way, I didn´t notice any big difference. An alternative idea would be to package that addon and add a clear hint about it on installing wordpress package. I am concerned about it, cause it introduces a privacy leak that someone who installs wordpress can only notice by installing a privacy protection plugin, or analysing the network traffic or source code. I know lots of websites do it the same way meanwhile. But I really would prefer when CSS and fonts are embedded into the package. I see no need to push dialing to Google onto the client machines of the users who visit a wordpress site. In my eyes it is a silent leak of privacy, instead of having privacy as the default. Here Debian packaging of wordpress can stand out by caring about privacy. I only report this for the most recent theme package, but the twentyfourteen is also affected. I also think that the main wordpress package may contain additional leaks, at least from the grep output I got. Thank you for your consideration, Martin -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (150, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781448: unblock (pre-approval): libcap2/1:2.24-8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, in #780432 we had: On 2015-03-13 22:13, Niels Thykier wrote: On 2015-03-13 21:44, Christian Kastner wrote: Furthermore, would you perhaps be willing to also accept a fix for #768229 (obsolete conffile removal)? If so, I'll provide an updated debdiff. Ack, please go ahead. Assuming the conffile removal is done by debhelper's maintscript file, please consider it pre-approved as well and include it. Well, even though this changed passed all my local tests safely [1], there are scenarios where this change leads to conffile breakage, see RC bug #781050. I researched this a bit and my impression is that there is yet no safe and trivial way to remove a conffile from a package A (where is has become obsolete) after it has been moved to another package B (but B might not be installed). See [2] and [3], for example. The attached debdiff drops debian/libcap2-bin.maintscript. This means that #768229 will have to be reopened, but I'd rather accept this wart than attempt any non-trivial solution this late in the freeze. The debdiff also contains a trivial and obvious fix for debian/watch, would that be OK? Regards, Christian [1] https://bugs.debian.org/780411#44 [2] https://bugs.debian.org/595112 [3] https://lists.debian.org/debian-devel/2012/02/thrd2.html#00249 diff -Nru libcap2-2.24/debian/changelog libcap2-2.24/debian/changelog --- libcap2-2.24/debian/changelog 2015-03-14 02:36:27.0 +0100 +++ libcap2-2.24/debian/changelog 2015-03-29 15:10:08.0 +0200 @@ -1,3 +1,13 @@ +libcap2 (1:2.24-8) unstable; urgency=medium + + * debian/libcap2-bin.maintscript: +- Drop, because using rm_conffile to clean up an obsolete conffile that + was moved to another package can lead to breakage, see: Closes: #781050 + * debian/watch: +- Drop stray empty opts= (invalid syntax breaks uscan checks) + + -- Christian Kastner deb...@kvr.at Sun, 29 Mar 2015 15:00:39 +0200 + libcap2 (1:2.24-7) unstable; urgency=medium * debian/libcap2-bin.maintscript: diff -Nru libcap2-2.24/debian/libcap2-bin.maintscript libcap2-2.24/debian/libcap2-bin.maintscript --- libcap2-2.24/debian/libcap2-bin.maintscript 2015-03-14 02:36:27.0 +0100 +++ libcap2-2.24/debian/libcap2-bin.maintscript 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -rm_conffile /etc/security/capability.conf 1:2.24-7~ libcap2-bin diff -Nru libcap2-2.24/debian/watch libcap2-2.24/debian/watch --- libcap2-2.24/debian/watch 2015-03-14 02:36:27.0 +0100 +++ libcap2-2.24/debian/watch 2015-03-29 15:10:08.0 +0200 @@ -4,5 +4,4 @@ # uncompressed tarball, and uscan currently does not have a mechanism to # implement this -opts=\ https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-(.+).tar.xz
Bug#781450: grpn: dpkg-source refuses to unpack the source (wrong strip plus fuzz)
Package: grpn Version: 1.1.2-3.1 Severity: serious Hi, Attempting to download and unpack the grpn source leads to the following error: $ dpkg-source -x grpn_1.1.2-3.1.dsc gpgv: Signature made 2012-05-14T15:40:11 CEST using DSA key ID C9B55DAC gpgv: Can't check signature: public key not found dpkg-source: warning: failed to verify signature on ./grpn_1.1.2-3.1.dsc dpkg-source: info: extracting grpn in grpn-1.1.2 dpkg-source: info: unpacking grpn_1.1.2.orig.tar.gz dpkg-source: info: unpacking grpn_1.1.2-3.1.debian.tar.gz dpkg-source: info: applying 01_fix_locale.patch dpkg-source: info: applying 02_add_includes.patch dpkg-source: info: applying 03_gtk2.patch patching file Makefile can't find file to patch at input line 45 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff --git a/debian/patches/03_gtk2.dpatch b/debian/patches/03_gtk2.dpatch |old mode 100755 |new mode 100644 -- No file to patch. Skipping patch. patching file lcd.c Hunk #1 succeeded at 679 (offset 2 lines). patching file main.c Hunk #1 succeeded at 159 (offset 3 lines). dpkg-source: info: the patch has fuzz which is not allowed, or is malformed dpkg-source: info: if patch '03_gtk2.patch' is correctly applied by quilt, use 'quilt refresh' to update it dpkg-source: info: restoring quilt backup files for 03_gtk2.patch dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/03_gtk2.patch/ --reject-file=- grpn-1.1.2/debian/patches/03_gtk2.patch gave error exit status 1 Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781448: unblock (pre-approval): libcap2/1:2.24-8
Control: tags -1 confirmed moreinfo On 2015-03-29 15:28, Christian Kastner wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, in #780432 we had: [...] Well, even though this changed passed all my local tests safely [1], there are scenarios where this change leads to conffile breakage, see RC bug #781050. I researched this a bit and my impression is that there is yet no safe and trivial way to remove a conffile from a package A (where is has become obsolete) after it has been moved to another package B (but B might not be installed). See [2] and [3], for example. The attached debdiff drops debian/libcap2-bin.maintscript. This means that #768229 will have to be reopened, but I'd rather accept this wart than attempt any non-trivial solution this late in the freeze. The debdiff also contains a trivial and obvious fix for debian/watch, would that be OK? Regards, Christian [...] Hi Christian, Thanks for looking into it. Indeed, I would also rather have an obsolete conffile than ending up with the #781050 in a released Jessie. Please go ahead with this solution - feel free to include the watch-file change as well. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781050: libcap2-bin: removes confile it doesnt own
Hi again, sorry for the delay. On 2015-03-24 00:02, Holger Levsen wrote: I think it's also a question of ordering: if libpam-cap is updated first and and libcap2-bin is removed second, things go well. If libcap2-bin is removed first and libpam-cap second, you will encounter the problem. I intend to revert that specific change for jessie, and reopen #768229 (obsolete conffile). The unblock pre-approval request #781448 has all the details. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781371: flash-kernel: Update machine entry for OpenRD boards
On 03/28/2015 11:07 AM, Ian Campbell wrote: On Sat, 2015-03-28 at 08:33 +, Marc Kleine-Budde wrote: since linux kernel version 3.16 the OpenRD boards have been converted to device tree. Indeed it's v3.17-rc1 not v3.16. Exclusively? My understanding was that while DT support became available earlier the board file support was not removed for most kirkwood platforms until 3.17-rc1 and so the version of flash-kernel in experimental enables DT mode from 3.17-rc1 onwards. Unless there is some sort of problem with using board file with 3.16 on a given platform I'd prefer to keep it that way for Jessie at this point in the freeze, since board files are the known quantity which everyone has(/should have) been testing until now. Of course if OpenRD systems are actively broken with v3.16 board file support then we should switch, please confirm if this is the case. If you are running a newer kernel than what is in Jessie then I would recommend the experimental version of f-k. Doh! When doing it right, suddenly everything works. sorry for the noise, Marc signature.asc Description: OpenPGP digital signature
Bug#781446: qtwebkit: FTBFS: The MacroAssembler is not supported on this platform.
Source: qtwebkit Version: 2.3.4.dfsg-3 Severity: important Justification: fails to build from source (but built successfully in the past) on non-release arch /tmp/buildd/qtwebkit-2.3.4.dfsg/Source/JavaScriptCore/assembler/MacroAssembler.h:62:2: error: #error The MacroAssembler is not supported on this platform. #error The MacroAssembler is not supported on this platform. Since qtwebkit used to build, this must be new. I think you really want a *white*list of architectures for which to enable the assembler in debian/rules, and disable it for all others. -- System Information: Debian Release: 8.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 3.16.0-4-m68k Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781452: gnome-web-photo: Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries
Package: gnome-web-photo Version: 0.10.6-1 Severity: normal Dear Maintainer, I get the following output whenever I try the package :- (gnome-web-photo:14074): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries The command I used to get a photo downloaded to my hdd are :- [$] gnome-web-photo -t 0 --mode=photo http://www.turkcealtyazi.org/mov/4003046/incir-receli-2.html incir.png This is just a sample download link. Looking forward to know more. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (600, 'testing'), (500, 'testing-updates'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-web-photo depends on: ii libatk1.0-0 2.14.0-1 ii libc6 2.19-15 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.1-1 ii libgtk-3-0 3.14.5-1 ii libjavascriptcoregtk-3.0-0 2.4.8-1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libsoup2.4-12.48.0-1 ii libwebkitgtk-3.0-0 2.4.8-1 gnome-web-photo recommends no packages. gnome-web-photo suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781451: gcc-5 uninstallable: /usr/share/doc/gcc-5-base/changelog.gz conflicts with gcc-5-base
Package: gcc-5 Version: 5-20150327-1 Severity: grave Justification: renders package unusable Dear Maintainer, when trying to install gcc-5, I get the following error: Retrieving bug reports... Done Parsing Found/Fixed information... Done (Reading database ... 337056 files and directories currently installed.) Preparing to unpack .../gcc-5_5-20150327-1_amd64.deb ... Unpacking gcc-5 (5-20150327-1) ... dpkg: error processing archive /var/cache/apt/archives/gcc-5_5-20150327-1_amd64.deb (--unpack): trying to overwrite '/usr/share/doc/gcc-5-base/changelog.gz', which is also in package gcc-5-base:amd64 5-20150327-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for distcc (3.2~rc1-2) ... Updating symlinks in /usr/lib/distcc ... Processing triggers for ccache (3.1.10-1) ... Updating symlinks in /usr/lib/ccache ... Processing triggers for man-db (2.7.1-2) ... Errors were encountered while processing: /var/cache/apt/archives/gcc-5_5-20150327-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: dpkg: dependency problems prevent configuration of g++-5: g++-5 depends on gcc-5 (= 5-20150327-1); however: Package gcc-5 is not installed. dpkg: error processing package g++-5 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of gcc-5-multilib: gcc-5-multilib depends on gcc-5 (= 5-20150327-1); however: Package gcc-5 is not installed. dpkg: error processing package gcc-5-multilib (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: g++-5 gcc-5-multilib -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (800, 'unstable'), (800, 'testing'), (780, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: PGP signature
Bug#781447: [l10n] Updated Czech translation of apt-cacher-ng debconf messages
Package: apt-cacher-ng Severity: wishlist Tags: l10n, patch Hi, in attachement there is updated Czech (cs.po) translation of apt-cacher-ng debconf messages. Please include it with the package. Thank you -- Miroslav Kure # Czech translation of apt-cacher-ng debconf messages. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the apt-cacher-ng package. # Miroslav Kure ku...@debian.cz, 2009--2015 # msgid msgstr Project-Id-Version: apt-cacher-ng\n Report-Msgid-Bugs-To: apt-cacher...@packages.debian.org\n POT-Creation-Date: 2015-03-17 19:19+0100\n PO-Revision-Date: 2015-03-29 14:39+0200\n Last-Translator: Miroslav Kure ku...@debian.cz\n Language-Team: Czech debian-l10n-cz...@lists.debian.org\n Language: cs\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #. Type: select #. Choices #: ../apt-cacher-ng.templates:2001 msgid Set up once msgstr Nastavit jednou #. Type: select #. Choices #: ../apt-cacher-ng.templates:2001 msgid Set up now and update later msgstr Nastavit nyní a průběžně aktualizovat #. Type: select #. Choices #: ../apt-cacher-ng.templates:2001 msgid No automated setup msgstr Nenastavovat automaticky #. Type: select #. Description #: ../apt-cacher-ng.templates:2002 msgid Automatic remapping of client requests: msgstr Automatické přesměrování klientských požadavků: #. Type: select #. Description #: ../apt-cacher-ng.templates:2002 msgid Apt-Cacher NG can download packages from repositories other than those requested by the clients. This allows it to cache content effectively, and makes it easy for an administrator to switch to another mirror later. The URL remapping can be set up automatically, using a configuration based on the current state of /etc/apt/sources.list. msgstr Apt-Cacher NG umí stahovat balíky i z jiných repositářů, než které si vyžádali klienti. To umožňuje efektivní používání lokální mezipaměti a také to správcům umožňuje jednoduše měnit používané zrcadlo. Přepisování URL je možné nastavit automaticky na základě aktuálního obsahu /etc/apt/sources. list. #. Type: select #. Description #: ../apt-cacher-ng.templates:2002 msgid Please specify whether the remapping should be configured once now, or reconfigured on every update of Apt-Cacher NG (modifying the configuration files each time), or left unconfigured. msgstr Vyberte si, zda se má přesměrování nastavit pouze jednou (nyní), při každé aktualizaci Apt-Cacher NG, nebo ponechat nenastavené. #. Type: select #. Description #: ../apt-cacher-ng.templates:2002 msgid Selecting \No automated setup\ will leave the existing configuration unchanged. It will need to be updated manually. msgstr Možnost „Nenastavovat automaticky“ ponechá stávající nastavení nedotčeno a budete je muset upravit ručně. #. Type: string #. Description #: ../apt-cacher-ng.templates:3001 msgid Listening address(es) for Apt-Cacher NG: msgstr Adresy, na kterých má Apt-Cacher NG naslouchat: #. Type: string #. Description #: ../apt-cacher-ng.templates:3001 msgid Please specify the local addresses that Apt-Cacher NG should listen on (multiple entries must be separated by spaces). msgstr Zadejte lokální adresy, na kterých má Apt-Cacher NG naslouchat (adresy musí být odděleny mezerami). #. Type: string #. Description #: ../apt-cacher-ng.templates:3001 msgid Each entry must be an IP address or hostname associated with a local network interface. Generic protocol-specific addresses are also supported, such as 0.0.0.0 for listening on all IPv4-enabled interfaces. msgstr Každý záznam musí být IP adresou nebo jménem počítače svázaným s lokálním síťovým rozhraním. Podporovány jsou i obecné adresy jako např. 0.0.0.0 pro naslouchání na všech rozhraních s IPv4. #. Type: string #. Description #: ../apt-cacher-ng.templates:3001 msgid If this field is left empty, Apt-Cacher NG will listen on all interfaces, with all supported protocols. msgstr Ponecháte-li prázdné, bude Apt-Cacher NG naslouchat na všech rozhraních všemi podporovanými protokoly. #. Type: string #. Description #. Type: string #. Description #: ../apt-cacher-ng.templates:3001 ../apt-cacher-ng.templates:6001 msgid The special word \keep\ keeps the value from the current (or default) configuration unchanged. msgstr Speciální slovo „keep“ ponechá hodnotu ze současného (nebo výchozího) nastavení. #. Type: string #. Description #: ../apt-cacher-ng.templates:4001 msgid Listening TCP port: msgstr TCP port: #. Type: string #. Description #: ../apt-cacher-ng.templates:4001 msgid Please specify the TCP port that Apt-Cacher NG should listen on for incoming HTTP (proxy) requests. The default value is port 3142, but it can be set to to emulate apt-proxy. msgstr Zadejte TCP port, na kterém má Apt-Cacher NG naslouchat příchozím HTTP požadavkům. Výchozí port je 3142, ale pro emulaci apt-proxy můžete použít hodnotu . #. Type: string #. Description #:
Bug#781453: [firebird-dev] Typo in control file
Package: firebird-dev Version: 3.0.0~svn+53030.ds3-1 Severity: normal --- Please enter the report below this line. --- Package firebird-dev depends on libib-utili instead of libib-util. So it can not be installed. --- System information. --- Architecture: amd64 Kernel: Linux 3.19.2-towo.1-siduction-amd64 Debian Release: 8.0 500 xbmc-ffmpeg-unstable people.debian.org 500 utopic ppa.launchpad.net 500 unstable http.debian.net 500 testing http.debian.net 500 stable repository-origin.spotify.com 500 stable download.videolan.org 500 stable dl.google.com 500 jessie linux.dropbox.com 500 buildd-unstable incoming.debian.org 1 experimental http.debian.net 1 buildd-experimental incoming.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
Bug#781460: trying to overwrite '/usr/share/doc/gcc-5-base/changelog.gz', which is also in package gcc-5 5-20150327-1
Yes there probably are some duplicates in other places than http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=gcc-5-base . -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781470: acpi: does acpi talk to Intel RAPL
Package: acpi Version: 1.7-1 Severity: normal On my Lenovo Yoga 2 13, the acpi temperature outputs are bogus. rrs@learner:~$ acpi -V Battery 0: Discharging, 79%, 06:09:10 remaining Battery 0: design capacity 4225 mAh, last full capacity 4156 mAh = 98% Adapter 0: off-line Thermal 0: ok, 29.8 degrees C Thermal 0: trip point 0 switches to mode critical at temperature 105.0 degrees C Thermal 0: trip point 1 switches to mode passive at temperature 108.0 degrees C Thermal 1: ok, 27.8 degrees C Thermal 1: trip point 0 switches to mode critical at temperature 105.0 degrees C Thermal 1: trip point 1 switches to mode active at temperature 100.0 degrees C Thermal 1: trip point 2 switches to mode active at temperature 55.0 degrees C Cooling 0: x86_pkg_temp no state information available Cooling 1: intel_powerclamp no state information available Cooling 2: Processor 0 of 10 Cooling 3: Processor 0 of 10 Cooling 4: Processor 0 of 10 Cooling 5: Processor 0 of 10 Cooling 6: Fan 1 of 1 Cooling 7: Fan 1 of 1 Cooling 8: Fan 1 of 1 Cooling 9: Fan 1 of 1 Cooling 10: Fan 1 of 1 23:39 ♒♒♒ ☺ While reading up on Intel RAPL I wonder if acpi supports it ? Because from its description, it looks like the current consumers are TurboStat, PowerTop and Linux thermal daemon only. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.3-rc5 (SMP w/4 CPU cores) Locale: LANG=en_IN.utf8, LC_CTYPE=en_IN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages acpi depends on: ii libc6 2.19-15 acpi recommends no packages. acpi 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#781473: virt-manager: Cannot create VM on localhost because AppArmor profile cannot, be loaded
Package: virt-manager
Version: 1:1.0.1-3
Severity: normal
Hi,
* What led up to the situation?
When I create a VM on localhost, with a simple ISO image, without a
harddisk,
this VM cannot be created.
* What was the outcome of this action?
I get an error message:
Installation could not be completed: «internal error: cannot load AppArmor
profile 'libvirt-e00238fb-5451-449a-b896-46e5b7842925'»
Traceback (most recent call last):
File /usr/share/virt-manager/virtManager/asyncjob.py, line 91, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File /usr/share/virt-manager/virtManager/create.py, line 1787, in
do_install
guest.start_install(meter=meter)
File /usr/share/virt-manager/virtinst/guest.py, line 403, in
start_install
noboot)
File /usr/share/virt-manager/virtinst/guest.py, line 467, in
_create_guest
dom = self.conn.createLinux(start_xml or final_xml, 0)
File /usr/lib/python2.7/dist-packages/libvirt.py, line 3440, in
createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: internal error: cannot load AppArmor profile 'libvirt-
e00238fb-5451-449a-b896-46e5b7842925'
I can run remote VMs without any problem.
I have AppArmor enabled on my machine.
This libvirt profile is in enforce mode: /usr/lib/libvirt/virt-aa-helper
Here is the output of /var/log/auditd/audit.log:
type=AVC msg=audit(1427652769.444:4659): apparmor=DENIED operation=open
profile=/usr/lib/libvirt/virt-aa-helper name=/etc/libnl-3/classid
pid=12115
comm=virt-aa-helper requested_mask=r denied_mask=r fsuid=0 ouid=0
type=SYSCALL msg=audit(1427652769.444:4659): arch=c03e syscall=2
success=no
exit=-13 a0=7f2155c1e930 a1=0 a2=1b6 a3=7f21538b0d5d items=0 ppid=1529
pid=12115 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm=virt-aa-helper
exe=/usr/lib/libvirt
/virt-aa-helper key=(null)
type=PROCTITLE msg=audit(1427652769.444:4659):
proctitle=2F7573722F6C69622F6C6962766972742F766972742D61612D68656C706572002D700030002D63002D75006C6962766972742D65303032333866622D353435312D343439612D623839362D343665356237383432393235
type=VIRT_RESOURCE msg=audit(1427652769.460:4660): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm resrc=disk reason=start
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 old-disk=?
new-
disk=/home/user/ISO/latest.iso exe=/usr/sbin/libvirtd hostname=? addr=?
terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1427652769.460:4661): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=start
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 old-net=? new-
net=52:54:00:5c:b3:1c exe=/usr/sbin/libvirtd hostname=? addr=?
terminal=?
res=success'
type=VIRT_RESOURCE msg=audit(1427652769.460:4662): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 bus=usb
device=555342207265646972646576 exe=/usr/sbin/libvirtd hostname=? addr=?
terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1427652769.460:4663): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 bus=usb
device=555342207265646972646576 exe=/usr/sbin/libvirtd hostname=? addr=?
terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1427652769.460:4664): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 bus=usb
device=555342207265646972646576 exe=/usr/sbin/libvirtd hostname=? addr=?
terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1427652769.460:4665): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 bus=usb
device=555342207265646972646576 exe=/usr/sbin/libvirtd hostname=? addr=?
terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1427652769.460:4666): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm resrc=mem reason=start
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 old-mem=0 new-
mem=1048576 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=?
res=success'
type=VIRT_RESOURCE msg=audit(1427652769.460:4667): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm resrc=vcpu reason=start
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 old-vcpu=0 new-
vcpu=1 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? res=success'
type=VIRT_CONTROL msg=audit(1427652769.460:4668): pid=1529 uid=0
auid=4294967295 ses=4294967295 msg='virt=kvm op=start reason=booted
vm=debianwheezy uuid=e00238fb-5451-449a-b896-46e5b7842925 vm-pid=-1
exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? res=failed'
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8
Bug#781472: ITP: node-base64-arraybuffer -- Encode/decode base64 data into ArrayBuffers
Package: wnpp Severity: wishlist Owner: Bas Couwenberg sebas...@debian.org * Package name: node-base64-arraybuffer Version : 0.1.2 Upstream Author : Niklas von Hertzen nikla...@gmail.com (http://hertzen.com) * URL : https://github.com/niklasvh/base64-arraybuffer * License : Expat Programming Lang: JavaScript Description : Encode/decode base64 data into ArrayBuffers base64-arraybuffer is a Node.js module to encode/decode base64 data into ArrayBuffers. node-base64-arraybuffer is required for node-engine.io-parser (#781458), which in turn is required for node-socket.io (#707166). The node-base64-arraybuffer package will be maintained in the JavaScript team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778483: [Pkg-xfce-devel] Bug#778483: xfce4: Screen tearing in XFCE
Even though this bug is not specific to hardware, i am providing info about the hardware that this bug is reproduced. Acer Aspire One HAPPY2: http://www.cnet.com/products/acer-aspire-one-happy2-13445-10-1-atom-n570-windows-7-starter-1-gb-ram-250-gb-hdd/specs/ Acer Aspire 3810TZ: http://www.cnet.com/products/acer-aspire-timeline/specs/ Intel DG965WH mobo with nVidia 9800GT: http://www.intel.com/support/motherboards/desktop/dg965wh/sb/CS-029372.htm There is more hardware which i can't provide at the moment OS: Debian official stable release 7.4, 7.5, 7.6, 7.7, 7.8 (7.8 testing) With the nVidia card i tested both open-source driver and proprietary. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781464: ITP: node-after -- Flow control for Node.js
Package: wnpp Severity: wishlist Owner: Bas Couwenberg sebas...@debian.org * Package name: node-after Version : 0.8.1 Upstream Author : Raynos rayn...@gmail.com * URL : https://github.com/Raynos/after * License : MIT Programming Lang: JavaScript Description : Flow control for Node.js after is a Node.js module to invoke a callback after N calls. node-after is required for node-engine.io-parser (#781458), which in turn is required for node-socket.io (#707166). The node-after package will be maintained in the JavaScript team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781209: postinst execution order bug confuses systemd
Hi Romain, Am 29.03.2015 um 12:56 schrieb Romain Francoise: On Thu, Mar 26, 2015 at 09:36:32PM +0100, Michael Biebl wrote: You could also ship the alias/symlink in the package, and not create it via Alias= Actually, that's what I would suggest to do anyway to align the old and new name. Thanks for the suggestion, that would probably be more reliable indeed. Can you confirm that systemd is smart enough to recognize the two units as the same service, even if only the second one is enabled? Can you be more specific, what you have in mind here? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#595787: squeak-vm: This is still a problem, and getting worse
Package: squeak-vm Version: 1:4.10.2.2614-1 Followup-For: Bug #595787 The problem exists exactly as originally described. It is getting worse in the sense that the Debian etoys package is now seriously out of date (see #636577), and therefore it’s natural to install it from source, only that doesn’t work, as it expects to call the normal squeak script. The natural workaround is to deinstall Debian’s squeak-vm and install that from upstream too, which is a pity. -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports'), (90, 'vivid-updates'), (90, 'vivid') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-33-generic (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages squeak-vm depends on: ii gettext-base 0.18.3.1-1ubuntu3 ii gnome-terminal [x-terminal-emulator] 3.10.2-0ubuntu1~trusty1 ii libc6 2.19-0ubuntu6.6 ii libfreetype6 2.5.2-1ubuntu2.4 ii libjpeg8 8c-2ubuntu8 ii libpcre3 1:8.31-2ubuntu2 ii mlterm [x-terminal-emulator] 3.3.2-1 ii whiptail 0.52.15-2ubuntu5 ii xterm [x-terminal-emulator] 297-1ubuntu1 Versions of packages squeak-vm recommends: ii zenity 3.8.0-1ubuntu1 Versions of packages squeak-vm suggests: pn etoys 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#772174: Patch for missing icons
As of Racket 6.x, the icons live in /usr/share/racket/pkgs/icons instead of /usr/share/racket/collects/icons. The attached patch adjusts the icon locations. Cheers, Chris. From 7b08d8a78c857214164d3072151a3555abb15187 Mon Sep 17 00:00:00 2001 From: Chris Jester-Young c...@cky.nz Date: Sun, 29 Mar 2015 12:22:29 -0400 Subject: [PATCH] Icons now live in /usr/share/racket/pkgs/icons. --- debian/copyright | 2 +- debian/drscheme.menu | 2 +- debian/racket.links | 8 debian/racket.menu | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/debian/copyright b/debian/copyright index 98f6e92..1f02624 100644 --- a/debian/copyright +++ b/debian/copyright @@ -40,7 +40,7 @@ Files: src/racket/src/lightning/i386/fp-sse.h Copyright: © 2006, 2010 Free Software Foundation, Inc. License: LGPL3+ -File: collects/gui-debugger/icons/clanbomber-*.png, collects/icons/stop*.png +File: share/pkgs/drracket/gui-debugger/icons/clanbomber-*.png, share/pkgs/icons/stop*.png Copyright: © 2008 Everaldo Coelho License: LGPL2.1+ diff --git a/debian/drscheme.menu b/debian/drscheme.menu index 3eb42a4..6af582f 100644 --- a/debian/drscheme.menu +++ b/debian/drscheme.menu @@ -2,4 +2,4 @@ section=Applications/Programming title=DrScheme \ command=/usr/bin/drscheme \ hints=Development Environment\ - icon=/usr/lib/plt/collects/icons/plt.xpm + icon=/usr/share/racket/pkgs/icons/plt.xpm diff --git a/debian/racket.links b/debian/racket.links index 479f4d4..fc2b4ae 100644 --- a/debian/racket.links +++ b/debian/racket.links @@ -1,4 +1,4 @@ -/usr/share/racket/collects/icons/plt.xpm /usr/share/pixmaps/plt.xpm -/usr/share/racket/collects/icons/plt-16x16.png /usr/share/pixmaps/plt-16x16.png -/usr/share/racket/collects/icons/plt-32x32.png /usr/share/pixmaps/plt-32x32.png -/usr/share/racket/collects/icons/plt-48x48.png /usr/share/pixmaps/plt-48x48.png +/usr/share/racket/pkgs/icons/plt.xpm /usr/share/pixmaps/plt.xpm +/usr/share/racket/pkgs/icons/plt-16x16.png /usr/share/pixmaps/plt-16x16.png +/usr/share/racket/pkgs/icons/plt-32x32.png /usr/share/pixmaps/plt-32x32.png +/usr/share/racket/pkgs/icons/plt-48x48.png /usr/share/pixmaps/plt-48x48.png diff --git a/debian/racket.menu b/debian/racket.menu index f8bd371..7bc97f0 100644 --- a/debian/racket.menu +++ b/debian/racket.menu @@ -2,4 +2,4 @@ section=Applications/Programming title=DrRacket \ command=/usr/bin/drracket \ hints=Development Environment \ -icon=/usr/share/racket/collects/icons/mini-plt.xpm +icon=/usr/share/racket/pkgs/icons/mini-plt.xpm -- 2.1.4
Bug#780411: libcap2-bin: missing Breaks+Replaces: libcap-bin
Hi Andreas,
On 2015-03-14 01:56, Andreas Beckmann wrote:
On 2015-03-13 23:49, Christian Kastner wrote:
Would you by chance be available for sponsoring? (No problem if not, but
if yes, please wait for an updated debdiff as the RT approved another
one-line fix.)
I'm not sure that this is the correct approach for capability.conf -
it's not an obsolete conffile, it has moved to libpam-cap instead (which
it Recommends)
The rm_conffile is fine as long as libpam-cap is not installed, but I'm
not sure whether this runs smoothly if libpam-cap is upgraded at the
same time ...
It turns out you were right, again.
While the above indeed worked fine in all of my local tests (which, as
stated in #44, I did for all possible combinations), apparently there
are constellations possible where the rm_conffile leads to a removal
when it shouldn't.
Such a case was reported as #781050. I prepared a package which reverts
the rm_conffile, so the obsolete conffile will just be accepted for now.
The unblock bug #781448 has a longer rationale for this decision.
I even added some workarounds in piuparts for a related issue (a
conffile was disappearing sometimes, but never from the reference
chroot) - since I didn't really see a fault in your packages:
case ${PIUPARTS_OBJECTS%%=*} in
kismet|\
tshark|\
wireshark|\
wireshark-common|\
wireshark-dbg|\
libcap2-bin)
# libcap2-bin/wheezy is part of the minimal
chroot and recommends libpam-cap
# a conffile moved from libcap2-bin/squeeze to
libpam-cap/wheezy
log_debug
apt-get install -yf libpam-cap
;;
Please consideres this as a heads-up that once the above change enters
unstable with 1:2.24-8, you may or may not need to re-introduce the
work-around above.
Regards,
Christian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781459: udd: please provide dumps more often
Hi, On Sun, Mar 29, 2015 at 06:42:20PM +0200, Lucas Nussbaum wrote: lucas mapreri: yes, but it would also be useful to switch to another dump format +1 (as abre minimum enhancement xz compression would be sensible) - udd-bugs.sql.xz, with only the bugs data (both archived and unarchived -- Andreas Tille was the main user of that -- is this still needed?) While I'm using it in a daily cron job I have the impression that this method is a bit weak and bugs get lost (for whatever reason - I had no time to track this down). Since I'm using it on a testing host anyway a monthly (may be weekly) sync with full UDD might be more sensible than sticking to this method. So if it helps we could drop udd-bugs.sql.xz. Please ping me before you remove it, thanks. 1) what is the rationale for the public UDD mirror. Is there a way this could be provided from Debian infrastructure, for example by whitelisting specific hosts that need UDD access? Is there something here that could be acceptable for DSA (Cced)? My mirror is to develop and test new features. 2) what is the rationale for the more frequent dumps. It's currently being dumped once a day. It's never going to be in sync with the live instance, unfortunately. I could live with a daily dump 3) Would dumps in custom format (pg_dump -Fc) work for you? they allow parallel restore with pg_restore. I see no reason why this should not work. 4) Could some tables be excluded from the dumps? Hmmm, I'd prefer a full dump (except of the data you consider private). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781466: ITP: node-arraybuffer.slice -- Exports a function for slicing ArrayBuffer without polyfilling
Package: wnpp Severity: wishlist Owner: Bas Couwenberg sebas...@debian.org * Package name: node-arraybuffer.slice Version : 0.0.5 Upstream Author : Tony Kovanen tony.kova...@gmail.com * URL : https://github.com/rase-/arraybuffer.slice * License : MIT Programming Lang: JavaScript Description : Exports a function for slicing ArrayBuffer without polyfilling arraybuffer.slice is a Node.js module that exports a function for slicing ArrayBuffer without polyfilling. node-arraybuffer.slice is required for node-engine.io-parser (#781458), which in turn is required for node-socket.io (#707166). The node-arraybuffer.slice package will be maintained in the JavaScript team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781444: qemu: unable to install Win10 Developer Preview (i386)
Control: tag -1 + moreinfo 29.03.2015 14:38, David Lee Lambert wrote: Package: qemu Version: 1.1.2+dfsg-6a+deb7u6 Severity: normal Attempting to install the WIndows 10 Devleoper Preview, file Windows10_TechnicalPreview_x32_ES-MX_10041.iso (MD5:4c5699ab4f2d54b8a4c9e7062f3aa297), the boot process displays the windows logo for a few seconds then stops with the following error... Ok. Since I don't have win10 I can't do anything byself. Please check if this problem exists when you run more up-to-date qemu, such as version 2.2 available in wheezy-backports. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781467: Here's the patch
Index: en/whats-new.dbk === --- en/whats-new.dbk (revision 10679) +++ en/whats-new.dbk (working copy) @@ -480,6 +480,15 @@ systemitem role=packagehardening-wrapper/systemitem can provide a systemitemgcc/systemitem with these flags enabled. /para + + paraNew in this release is the + systemitem role=packageneedrestartsystemitem package. When installed, + it will check after each APT upgrade session for any services running on + the system that require a restart to take advantage of the changes in the + upgraded packages and offers to perform that restart. It's recommended to + install systemitem role=packageneedrestartsystemitem to ensure that + security updates in libraries are propagated to running services. + /para /section section id=mariadb titleMariaDB next to MySQL/title
Bug#781468: cryptsetup depends on udev in shutdown initramfs
Package: cryptsetup Version: 2:1.6.6-5 Using Debian's cryptsetup binary works just fine in my initramfs during boot. However, it doesn't work well during shutdown, when systemd hands over to the initramfs again[*], and udev is no longer running: $ cryptsetup luksClose VOLUME ... # Deactivating volume VOLUME # dm status VOLUME ... # Udev cookie ... created # Udev cookie ... incremeted to 1 # Udev cookie ... incremeted to 2 # Udev cookie ... assigned to REMOVE task(2) with flags # dm remove VOLUME # VOLUME: Stacking NODE_DEL (verify_udev) # Udev cookie ... decremented to 1 # Udev cookie ... waiting for zero Then cryptsetup hangs, and does not return to the shell / shutdown script. As the same issue also appears in upstream cryptsetup (1.7.0-git - 046e0e52), I see two options to resolve this for future revisions of cryptsetup: - Disable UDEV in the device mapper backend, same as it is done when running cryptsetup from the initramfs during boot. - Provide a command line option similar to LVM's vgchange --noudevsync Many thanks for taking a look at this issue. Best, Dominik [*] http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ signature.asc Description: Digital signature
Bug#775813: Acknowledgement (iceweasel: not using German localized search plugins)
Same here, using iceweasel from wheezy. $ apt-show-versions | grep icewe iceweasel/wheezy uptodate 31.5.3esr-1~deb7u1 iceweasel-l10n-fr/wheezy uptodate 1:31.5.3esr-1~deb7u1 $ locale LANG=fr_FR.utf8 LANGUAGE= LC_CTYPE=fr_FR.utf8 LC_NUMERIC=fr_FR.utf8 LC_TIME=fr_FR.utf8 LC_COLLATE=fr_FR.utf8 LC_MONETARY=fr_FR.utf8 LC_MESSAGES=fr_FR.utf8 LC_PAPER=fr_FR.utf8 LC_NAME=fr_FR.utf8 LC_ADDRESS=fr_FR.utf8 LC_TELEPHONE=fr_FR.utf8 LC_MEASUREMENT=fr_FR.utf8 LC_IDENTIFICATION=fr_FR.utf8 LC_ALL= $ strace iceweasel 21 | grep searchplugins/locale access(/etc/iceweasel/searchplugins/locale/en-US, F_OK) = 0 $ find /etc/iceweasel/searchplugins/ /etc/iceweasel/searchplugins/ /etc/iceweasel/searchplugins/common /etc/iceweasel/searchplugins/common/duckduckgo.xml /etc/iceweasel/searchplugins/common/debsearch.xml /etc/iceweasel/searchplugins/locale /etc/iceweasel/searchplugins/locale/fr /etc/iceweasel/searchplugins/locale/fr/eBay-france.xml /etc/iceweasel/searchplugins/locale/fr/cnrtl-tlfi-fr.xml /etc/iceweasel/searchplugins/locale/fr/amazon-france.xml /etc/iceweasel/searchplugins/locale/fr/google.xml /etc/iceweasel/searchplugins/locale/fr/yahoo-france.xml /etc/iceweasel/searchplugins/locale/fr/wikipedia-fr.xml /etc/iceweasel/searchplugins/locale/fr/bing.xml /etc/iceweasel/searchplugins/locale/en-US /etc/iceweasel/searchplugins/locale/en-US/wikipedia.xml /etc/iceweasel/searchplugins/locale/en-US/amazondotcom.xml /etc/iceweasel/searchplugins/locale/en-US/yahoo.xml /etc/iceweasel/searchplugins/locale/en-US/google.xml /etc/iceweasel/searchplugins/locale/en-US/eBay.xml /etc/iceweasel/searchplugins/locale/en-US/twitter.xml /etc/iceweasel/searchplugins/locale/en-US/bing.xml Olivier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779708: Client for updating dynamic hostname mappings for dy.fi
Eugene Zhukov jevgeni...@gmail.com writes: I refactored the daemon so that it runs as dyfi user now with systemd-as-init. With SysV as init it still runs as root. It looks like too much hassle/effort to me since I'm not familiar with init scripting. If you think it's a must, I can implement privileges-drop for SysV, otherwise could you please upload it to NEW? At least currently I lack the time to sponsor uploads, sorry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781469: openssh-client: ssh.1 manpage does not document changed ForwardX11Trusted default
Package: openssh-client Version: 1:6.7p1-3 Severity: normal Debian has changed the ForwardX11Trusted default to yes, and this change is documented in ssh_config.5. However, ssh.1 still says: For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.6jann (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-client depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.24 ii libc6 2.19-15 ii libedit2 3.1-20140620-2 ii libgssapi-krb5-2 1.12.1+dfsg-18 ii libselinux1 2.3-2 ii libssl1.0.0 1.0.1k-1 ii passwd1:4.2-3 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages openssh-client recommends: ii xauth 1:1.0.9-1 Versions of packages openssh-client suggests: pn keychain none pn libpam-sshnone pn monkeysphere none pn ssh-askpass none -- Configuration Files: /etc/ssh/ssh_config changed [not included] -- 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#781471: Annual ping for Sergey Suslov
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: debian-maintainers Severity: normal Hi, This is my annual ping. - -- With best regards, Sergey Suslov. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJVGEETAAoJEICHjlmDK+wVFeEP+wTRvFHZTCqc6byaAfYe1lV+ izDuymV7Al5VCzjTlpXMP8BfgziOYRCBUaD7s2V159kotlh+p0oiXOcITKTVpWZi HJ18WUhWzYFUNt2GmtZPiBJn9zKZwLog0OSCdRBMfhVi9FUZK4SmhuCtkueMuAIX eRbNIu3xYBv5vZ4u1Kqzb0OjehHpJIc0bv8Z+BlB/0OLkpZ56C54pERRixFgbW7k GE/9vUiwr6/z4sUMr/fnbN6dBuj02fZuydmeCexPpFk3L8JIDGQ2UYU7sTjIv3NZ VuE4qjuK/6Yj30Vlvy63X1xRkqo6e68ajljiygTO1Waz4LpE+2S/8MnOWupC8zG0 tzOW6DkY+lpg0ZL4CzRca4L5V1BEaiFjsPqT9+mOpzit1ZJTeKAGbdGc95/I9F1y sFSuf3LlXDQj0wMRdRfN6nkrEjxGhowmFA/NVRA0gatlLnjmWEj6O5pUKGed12Ki sokA20Ohvd+SBJ/MqFa7rRuEsdLWc4yvhuexYLsbjF+aD+2x70vxjn5BZq4jUn4+ ThrgX9+6jqw7zJMsI8qbE/oLwsvqvbgFuJfmer0GJGazKmFflaqYWL4050zL/SwU gYwyYrylEqgdlRQn6KesJYtbFL2p+fSRLWUlPPqOZTbgOU4nQSO3zRXcCXpnjFT9 i/ax84NysfisS4BoLMSY =AOf6 -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
