Bug#765567: xsltproc: bus error on some architectures
See later comments in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471029 The depth of recursion is not excessive, but the kernel is laying out the memory in a way that squishes the stack into the heap. This (from memory of tests I don't have right now) was fixed between 4.0 and 4.1. Douglas On Wed, 4 Jun 2014 22:27:03 +0200 Ivo De Decker ivo.dedec...@ugent.be wrote: package: xsltproc version: 1.1.28-2 severity: important Hi, On some architectures (like i386), xsltproc fails with Bus error when running /usr/bin/xsltproc --nonet -o smb.conf.5 man.xsl smb.conf.5.tmp.xml with the attached version of man.xsl and smb.conf.5.tmp.xml. This is done during the samba build. It fails on armel, armhf and i386, but doesn't fail on other architectures. fail: https://buildd.debian.org/status/fetch.php?pkg=sambaarch=armelver=2%3A4.1.7%2Bdfsg-2%2Bb1stamp=1401742626 https://buildd.debian.org/status/fetch.php?pkg=sambaarch=armhfver=2%3A4.1.7%2Bdfsg-2%2Bb1stamp=1401738640 https://buildd.debian.org/status/fetch.php?pkg=sambaarch=i386ver=2%3A4.1.7%2Bdfsg-2%2Bb1stamp=1401787651 ok: https://buildd.debian.org/status/fetch.php?pkg=sambaarch=amd64ver=2%3A4.1.7%2Bdfsg-2%2Bb1stamp=1401735339 The failure happened for a binnmu. The previous build went fine: https://buildd.debian.org/status/fetch.php?pkg=sambaarch=i386ver=2%3A4.1.7%2Bdfsg-2stamp=1397997714 I wasn't able to find a clear change between these builds which could explain why the failure happens now but didn't in the past (but there could be a change I overlooked). Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793939: [RFR] templates://publicfile-installer/{templates}
Quoting Justin B Rye (justin.byam@gmail.com): But why does it need a special script to install a package? (Goes and looks...) Yipe! It just checks I'm root and then runs dpkg -i /tmp/publicfile-installer/publicfile*_*.deb Does the build really leave its output in a predictable location in a world-writable directory? (Checks) Yes, so if my evil kid brother has created a /tmp/publicfile-installer/publicfile_0.52-0_amd64.deb, the build-script will happily dump its .deb alongside it. Then when I run sudo install-publicfile it'll install the bogus package first, executing its install-scripts as root. That seems correct and probably deserves another bug report, in my opinion. Thanks for pointing this, Justin... signature.asc Description: Digital signature
Bug#794994: graphite2: FTBFS on !linux archs
Source: graphite2
Version: 1.3.0-1
Severity: important
Tags: patch
Hi,
graphite2 1.3.0-1 fails to build on kFreeBSD [1][2] and Hurd [3].
The problem is that tests/graphite.py does not have any library item
for these platforms registered in the grfiles dictionary, so the script
will fail with a KeyError exception.
The fix, which is suitable for upstream (so please do forward it),
is to slightly rework the logic for knowing the library name on the
current platform: since there will be far more platforms with the name
libgraphite2.so (Linux, kFreeBSD, Hurd, and any other BSD platform for
sure), then fallback to that name for missing items in the grfiles
dictionary. Hence, that dictionary contains now only platforms where
the library name is not libgraphite2.so, and the linux2 mapping is no
more needed.
Patch attached for this.
[1]
https://buildd.debian.org/status/fetch.php?pkg=graphite2arch=kfreebsd-amd64ver=1.3.0-1stamp=1439034142
[2]
https://buildd.debian.org/status/fetch.php?pkg=graphite2arch=kfreebsd-i386ver=1.3.0-1stamp=1439034476
[3]
https://buildd.debian.org/status/fetch.php?pkg=graphite2arch=hurd-i386ver=1.3.0-1stamp=1439070777
Thanks,
--
Pino
--- a/tests/graphite.py
+++ b/tests/graphite.py
@@ -30,9 +30,9 @@ else :
#basedir = os.path.join(os.path.dirname(__file__), '..', '..', 'build', 'src')
basedirs = [os.path.join('..', '..'), os.path.join('..'), os.path.join('..','build')]
+# systems with a library filename different than libgraphite2.so
grfiles = {
'darwin' : 'libgraphite2.dylib',
-'linux2' : 'libgraphite2.so',
'win32' : 'graphite2.dll',
'win64' : 'graphite2-x64.dll'
}
@@ -40,7 +40,10 @@ gr2 = None
if sys.platform == 'win32' and sys.maxsize (1 32) :
grfile = grfiles['win64']
else :
-grfile = grfiles[sys.platform]
+try :
+grfile = grfiles[sys.platform]
+except KeyError :
+grfile = 'libgraphite2.so'
for b in (os.path.join(b,'src',c) for b in basedirs for c in ('', 'Debug', 'Release', 'DebWithRelInfo', 'MinSizeRel')):
testfile = os.path.join(b, grfile)
print Trying + testfile
Bug#794995: lintian: false positive in non-consecutive-debian-revision
Package: lintian Version: 2.5.35 Severity: normal Dear Maintainer, After rename a binary inside a package (in debian/control), I received a message from lintian saying about non-consecutive-debian-revision. The package is afflib and the binary libafflib0 was renamed to libafflib0v5. This package will be uploaded to unstable soon (I think that today). The lintian messages are: X: afflib-dbg: non-consecutive-debian-revision X: libafflib-dev: non-consecutive-debian-revision X: libafflib0v5: non-consecutive-debian-revision X: afflib-tools: non-consecutive-debian-revision X: libafflib0: non-consecutive-debian-revision My current changelog sequence is: afflib (3.7.6-5) unstable; urgency=medium [...] afflib (3.7.6-4) unstable; urgency=medium This bug is relative to #789820. (thanks for implement it) Thanks in advance. Regards, Eriberto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791150: liborigin: diff for NMU version 20080225-2.2
Hi Johathan Sorry for my silence. Dear maintainer, I've prepared an NMU for liborigin (versioned as 20080225-2.2) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks a lot for the patch. Do you use the library? When I packaged it I used it for QtiPlot but since then QtiPlot has started using its own version of liborigin and now it seems like no package is depending on it. I am wondering if it is time to remove the package from Debian. Regards Gudjon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: Fwd: Fwd: Re: multiarch = same and different date-entries in generated man page of i32/i64
help2man 1.47.1 IS used. Next I will try as a workaround setting export SOURCE_DATE_EPOCH = $(shell date -d $$(dpkg-parsechangelog --count 1 -SDate) +%s) manually in debian/rules.
Bug#758044: man page confusion has been fixed in both upstream and Sid
Package: youtube-dl Followup-For: Bug #758044 Hi 積丹尼, I am not the maintainer of youtube-dl, I find my way into this bug report when I am about to report a man-page-related issue. I believe the bug you reported has already been fixed. The confusing section now looks like this: --ignore-config Do not read configuration files. When given in the global configuration file /etc/youtube-dl.conf: Do not read the user configu ration in ~/.config/youtube-dl/config (% APPDATA%/youtube-dl/config.txt on Windows) and: mtime) into /etc/youtube-dl.conf and/or ~/.config/youtube-dl/config. OnWindows,theconfiguration file locations are %APP‐ DATA%\youtube-dl\config.txt and C:\Users\user name\youtube-dl.conf. So, it appears the correct user-specific configuration file is `~/.config/youtube-dl/config'. The `--prefer-free-format' section now looks like: --prefer-free-formatsPrefer free video formats unless a specific one is requested These bugs also appear to be fixed in upstream's README.md: https://github.com/rg3/youtube-dl/blob/master/README.md. I will mark the bug as `fixed', please close the bug report by sending email to 758044-d...@bugs.debian.org since https://www.debian.org/Bugs/Developer#closing suggests only submitter or maintainer should close the bug. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_TW.utf8, LC_CTYPE=zh_TW.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages youtube-dl depends on: ii python2.7.9-1 ii python-pkg-resources 18.0.1-2 pn python:anynone Versions of packages youtube-dl recommends: ii libav-tools 6:11.4-2 ii mplayer2 [mplayer] 2.0-728-g2c378c7-4+b2 ii rtmpdump2.4+20150115.gita107cef-1+b2 ii wget1.16.3-3 youtube-dl 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#794997: openldap: missing manual page for lastbind module
Package: openldap Version: 2.4.41+dfsg-1 Severity: normal Tags: upstream patch Hi, although the lastbind module contains a manual page upstream, thismanual page isn't included together with the module in Debian's packaging. The attached patch, that I use in my private packaging, solves this issue. This patch is derived from a patch that I sent upstream as part of ITS#8205. Please incldue this patch into Debian's openldap packaging to document the lastbind module. Best Peter PS: support for getting the patch series from ITS#8205 incorporated upstream is very welcome too. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) From b8491b2cf9b7101f78f233bfe75366505d95b5b7 Mon Sep 17 00:00:00 2001 From: Peter Marschall pe...@adpm.de Date: Sun, 26 Jul 2015 11:58:02 +0200 Subject: [PATCH] lastbind-makefile-manpage: install slapo-lastbind.5 man page --- debian/patches/lastbind-makefile-manpage | 46 debian/patches/series| 1 + 2 files changed, 47 insertions(+) create mode 100644 debian/patches/lastbind-makefile-manpage diff --git a/debian/patches/lastbind-makefile-manpage b/debian/patches/lastbind-makefile-manpage new file mode 100644 index 000..900d051 --- /dev/null +++ b/debian/patches/lastbind-makefile-manpage @@ -0,0 +1,46 @@ +--- a/contrib/slapd-modules/lastbind/Makefile b/contrib/slapd-modules/lastbind/Makefile +@@ -17,6 +17,7 @@ + $(LDAP_BUILD)/debian/build/libraries/liblber/liblber.la + + LIBTOOL = $(LDAP_BUILD)/debian/build/libtool ++INSTALL = /usr/bin/install + CC = gcc + OPT = -g -O2 -Wall + DEFS = -DSLAPD_OVER_LASTBIND=SLAPD_MOD_DYNAMIC +@@ -25,6 +26,7 @@ + + PROGRAMS = lastbind.la + LTVER = 0:0:0 ++MANPAGES = slapo-lastbind.5 + + prefix=/usr + exec_prefix=$(prefix) +@@ -33,6 +35,8 @@ + libdir=$(exec_prefix)/lib + libexecdir=$(exec_prefix)/libexec + moduledir = $(libdir)$(ldap_subdir) ++mandir = $(exec_prefix)/share/man ++man5dir = $(mandir)/man5 + + .SUFFIXES: .c .o .lo + +@@ -48,9 +52,17 @@ + clean: + rm -rf *.o *.lo *.la .libs + +-install: $(PROGRAMS) ++install: install-lib install-man FORCE ++ ++install-lib: $(PROGRAMS) + mkdir -p $(DESTDIR)$(moduledir) + for p in $(PROGRAMS) ; do \ + $(LIBTOOL) --mode=install cp $$p $(DESTDIR)$(moduledir) ; \ + done + ++install-man: $(MANPAGES) ++ mkdir -p $(DESTDIR)$(man5dir) ++ $(INSTALL) -m 644 $(MANPAGES) $(DESTDIR)$(man5dir) ++ ++FORCE: ++ diff --git a/debian/patches/series b/debian/patches/series index 260c701..eda3a18 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -12,6 +12,7 @@ contrib-modules-use-dpkg-buildflags smbk5pwd-makefile autogroup-makefile lastbind-makefile +lastbind-makefile-manpage pw-sha2-makefile ldap-conf-tls-cacertdir add-tlscacert-option-to-ldap-conf -- 2.5.0
Bug#792624: Fwd: Fwd: Re: multiarch = same and different date-entries in generated man page of i32/i64
Roelof Berg rb...@berg-solutions.de writes: help2man 1.47.1 IS used. Next I will try as a workaround setting export SOURCE_DATE_EPOCH = $(shell date -d $$(dpkg-parsechangelog --count 1 -SDate) +%s) manually in debian/rules. Not everyone agrees with me, but I think using help2man at build time should be generally avoided. It's fragile (as you see) and the quality of the resulting man pages is generally low. By the time you go through all the trouble of getting it work right, you could have committed (and improved by editing) a static man page originally generated with help2man. The tradeoff is then somebody has to keep that man page up to date. And nroff is initially daunting to edit, although really man pages are pretty simple documents. Just an alternative path to think about for fixing the bug(s). d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794998: openldap: no manual page for smbk5pwd module
Source: openldap Version: 2.4.41+dfsg-1 Severity: normal Tags: upstream patch Hi, the smbk5pwd module in the slapd-smbk5pwd binary package does not have a manual page. The attached patches try to solve the issue: * 0001-smbk5pwd-makefile-manpage-install-slapo-smbk5pwd.5-m.patch Create a manual page for smbk5pwd and make sure it gets installed too. This patch is derived from a patch I sent upstream as part of ITS#8205 * 0002-debian-slapd-.manpages-separate-man-pages-between-t.patch Make sure the slapo-smbk5pwd.5 manual page does not end up in the slapd binary package. I'd appreciate if these patches make it into the next release of Debian's openldap packages. Thanks for packaging openldap for Debian! Best Peter PS: support in getting ITS#8205 included upstream is very welcome ;-)) -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) From b3c6acad00eefe300e0e96ae78e36394ba3766e4 Mon Sep 17 00:00:00 2001 From: Peter Marschall pe...@adpm.de Date: Sat, 8 Aug 2015 12:02:12 +0200 Subject: [PATCH 1/2] smbk5pwd-makefile-manpage: install slapo-smbk5pwd.5 man page The patch for creating the smbk5pwd manual page is upstreamed as ITS#8205 --- debian/patches/series| 1 + debian/patches/smbk5pwd-makefile-manpage | 251 +++ 2 files changed, 252 insertions(+) create mode 100644 debian/patches/smbk5pwd-makefile-manpage diff --git a/debian/patches/series b/debian/patches/series index eda3a18..87dda63 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -10,6 +10,7 @@ getaddrinfo-is-threadsafe do-not-second-guess-sonames contrib-modules-use-dpkg-buildflags smbk5pwd-makefile +smbk5pwd-makefile-manpage autogroup-makefile lastbind-makefile lastbind-makefile-manpage diff --git a/debian/patches/smbk5pwd-makefile-manpage b/debian/patches/smbk5pwd-makefile-manpage new file mode 100644 index 000..a0ed83b --- /dev/null +++ b/debian/patches/smbk5pwd-makefile-manpage @@ -0,0 +1,251 @@ +From: Peter Marschall pe...@adpm.de +Date: Sun, 26 Jul 2015 15:04:26 +0200 +Subject: [PATCH] contrib/smbk5pwd: add man page, install it too + +Add a manual page slapo-smbk5pwd.5 and update smbk5pwd's Makefile to +install the new manual page. + +This patch is derived from the corresponding patch upstreamed in ITS#8205 + +--- + contrib/slapd-modules/smbk5pwd/Makefile | 14 +- + contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 | 179 + 2 files changed, 192 insertions(+), 1 deletion(-) + create mode 100644 contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 + +diff --git a/contrib/slapd-modules/smbk5pwd/Makefile b/contrib/slapd-modules/smbk5pwd/Makefile +index 676d914..0042a49 100644 +--- a/contrib/slapd-modules/smbk5pwd/Makefile b/contrib/slapd-modules/smbk5pwd/Makefile +@@ -25,6 +25,7 @@ + HEIMDAL_LIB = $(shell krb5-config.heimdal --libs kadm-server) + + LIBTOOL = $(LDAP_BUILD)/debian/build/libtool ++INSTALL = /usr/bin/install + CC = gcc + OPT = -g -O2 -Wall + # Omit DO_KRB5, DO_SAMBA or DO_SHADOW if you don't want to support it. +@@ -34,6 +35,7 @@ + LIBS = $(HEIMDAL_LIB) $(LDAP_LIB) $(SSL_LIB) + + PROGRAMS = smbk5pwd.la ++MANPAGES = slapo-smbk5pwd.5 + LTVER = 0:0:0 + + prefix=/usr +@@ -43,6 +45,8 @@ + libdir=$(exec_prefix)/lib + libexecdir=$(exec_prefix)/libexec + moduledir = $(libdir)$(ldap_subdir) ++mandir = $(exec_prefix)/share/man ++man5dir = $(mandir)/man5 + + .SUFFIXES: .c .o .lo + +@@ -58,9 +62,17 @@ + clean: + $(LIBTOOL) --mode=clean rm -f + +-install: $(PROGRAMS) ++install: install-lib install-man FORCE ++ ++install-lib: $(PROGRAMS) + mkdir -p $(DESTDIR)$(moduledir) + for p in $(PROGRAMS) ; do \ + $(LIBTOOL) --mode=install cp $$p $(DESTDIR)$(moduledir) ; \ + done + ++install-man: $(MANPAGES) ++ mkdir -p $(DESTDIR)$(man5dir) ++ $(INSTALL) -m 644 $(MANPAGES) $(DESTDIR)$(man5dir) ++ ++FORCE: ++ +diff --git a/contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 b/contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 +new file mode 100644 +index 000..431a765 +--- /dev/null b/contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 +@@ -0,0 +1,179 @@ ++.TH SLAPO-SMBK5PWD 5 RELEASEDATE OpenLDAP LDVERSION ++.\ Copyright 2015 The OpenLDAP Foundation All Rights Reserved. ++.\ Copying restrictions apply. See COPYRIGHT/LICENSE. ++.\ $OpenLDAP$ ++.SH NAME ++slapo-smbk5pwd \- Samba Kerberos password sync overlay to slapd ++.SH SYNOPSIS ++ETCDIR/slapd.conf ++.RS ++.LP ++include ++.B path to/krb5-kdc.schema ++.LP ++include ++.B path to/samba.schema ++.LP ++moduleload ++.B smbk5pwd.so ++.LP ++ ... ++.LP ++database mdb ++.LP ++ ... ++.LP ++overlay ++.B smbk5pwd ++.RE ++ ++.SH DESCRIPTION ++.LP ++The ++.B
Bug#781927: RFS: qemuctl/0.3.1-4 [ITA] -- control gui for qemu
Gianfranco Costamagna writes: 1) there is no need to call the files under debian directory qemuctl.manpages as long as you have only one binary package manpages is good enough. (note: I'm not asking to change that) Not changed. 2) you might find useful to remove the debian/dirs file, because it should be useless since you already have your install file. d/dirs is gone, package still seems to install all right and lintian is quiet. 3) the license of the package seems to be wrong: accoding to licensecheck and manual checks I did, the files have a license GPL-3+, not GPL-2+ (and thanks for promptly replying to the feedbacks) Uh, oh, that was a real issue. The copyright of the .orig.tar.gz from upsteam is indeed gpl-3+ so the d/copyright file has been wrong all the time. The debian packaging files have been distributed with gpl-2+ license and that I did not change now as I'd need to ask the previous copyright holders too about that - leaving that part of license as it is. Corrected version is now available at mentors.d.n, the version uploaded with timestamp 2015-08-09 07:57 as they all have same name. -- Antti -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794995: lintian: false positive in non-consecutive-debian-revision
Control: tags -1 + patch
* Joao Eriberto Mota Filho eribe...@debian.org, 2015-08-09, 03:33:
After rename a binary inside a package (in debian/control), I received
a message from lintian saying about non-consecutive-debian-revision.
That's unrelated to the package rename, of course.
Implementation of this tag is completely broken. Lintian will emit this
tag for most packages in the archive.
Here's a patch fix it...
--
Jakub Wilk
diff --git a/checks/changelog-file.pm b/checks/changelog-file.pm
--- a/checks/changelog-file.pm
+++ b/checks/changelog-file.pm
@@ -330,7 +330,7 @@
tag 'possible-new-upstream-release-without-new-version';
}
if ($first_debian =~ /^\d+$/ and $second_debian =~ /^\d+$/) {
-unless ($second_debian == $first_debian + 1) {
+unless ($first_debian == $second_debian + 1) {
tag 'non-consecutive-debian-revision';
}
}
Bug#794931: MongoDB FTBFS due to new GCC + snappy transition
Control: block 794931 with 794993 Control: tags 794931 + pending zigo, at least write the package name right please. The fix is pending, but it needs a GCC5 transitioned snappy version. Hope it will happen soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794999: openldap: include pbkdf2 contrib module into Debian's openldap packages
Source: openldap
Version: 2.4.41+dfsg-1
Severity: wishlist
Tags: upstream patch
Hi,
please include the pbkdf2 contrib module in Debian's openldap packages.
The attacked patch does this:
* It starts by preparing contrib/password/pbkdf2/pw-pdkdf2.c to work with nettle
* debian/patches/TS8198-0001-fix-an-always-true-check.patch
patch is taken from upstream ITS#8198
* ITS8198-0002-optionally-use-libnettle-instead-of-openssl-for-crypto.patch
* Then it adapts contrib/password/pbkdf2/Makefile to follow Debian's rules
* pbkdf2-makefile-use-dpkg-buildflags
* pbkdf2-makefile
* Of course it doesn't forget to add a manual page
(derived from a patch I sent upstream as a part of ITS#8205)
* pbkdf2-makefile-manpage
* Finally it updates debian/rules to make sure the module's files get compiled
and installed
I have this patch included in my private packaging of openldap.
When creating the patch, I tried to
* avoid changing existing patches
That's the reason for the 'pbkdf2-makefile-use-dpkg-buildflags' patch file.
Feel free to merge it into 'contrib-modules-use-dpkg-buildflags'
* adhere to existing patch naming logic
e.g. 'pbkdf2-makefile'
Thanks for your work on openldap in Debian!
Best
Peter
PS: support for getting ITS#8198 and ITS#8205 included upstream is very welcome
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
From 755e6302f3f095919eed04d1849172cc61d42d8d Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sat, 8 Aug 2015 12:26:57 +0200
Subject: [PATCH] build and install pw-pbkdf2
Start by preparing contrib/password/pbkdf2/pw-pdkdf2.c to work with nettle
* debian/patches/TS8198-0001-fix-an-always-true-check.patch
patch is taken from upstream ITS#8198
* ITS8198-0002-optionally-use-libnettle-instead-of-openssl-for-crypto.patch
Then adapt contrib/password/pbkdf2/Makefile to follow Debian's rules
* pbkdf2-makefile-use-dpkg-buildflags
* pbkdf2-makefile
Don't forget to add a manual page (taken from a patch upstreamed in ITS#8205)
* pbkdf2-makefile-manpage
Finally compile install it by adapting debian/rules
---
.../ITS8198-0001-fix-an-always-true-check.patch| 48 +
...e-libnettle-instead-of-openssl-for-crypto.patch | 196 +
debian/patches/pbkdf2-makefile | 43 +
debian/patches/pbkdf2-makefile-manpage | 184 +++
debian/patches/pbkdf2-makefile-use-dpkg-buildflags | 19 ++
debian/patches/series | 5 +
debian/rules | 2 +
7 files changed, 497 insertions(+)
create mode 100644 debian/patches/ITS8198-0001-fix-an-always-true-check.patch
create mode 100644 debian/patches/ITS8198-0002-optionally-use-libnettle-instead-of-openssl-for-crypto.patch
create mode 100644 debian/patches/pbkdf2-makefile
create mode 100644 debian/patches/pbkdf2-makefile-manpage
create mode 100644 debian/patches/pbkdf2-makefile-use-dpkg-buildflags
diff --git a/debian/patches/ITS8198-0001-fix-an-always-true-check.patch b/debian/patches/ITS8198-0001-fix-an-always-true-check.patch
new file mode 100644
index 000..f67297e
--- /dev/null
+++ b/debian/patches/ITS8198-0001-fix-an-always-true-check.patch
@@ -0,0 +1,48 @@
+From f9e42bc1ce85a8c2bc7f3daa06a553b0f79ea6d8 Mon Sep 17 00:00:00 2001
+From: Luca Bruno luca.br...@rocket-internet.de
+Date: Wed, 5 Nov 2014 16:15:55 +0100
+Subject: [PATCH] Fix an always-true check
+
+Fixed asprintf return value check, in order to properly catch
+error conditions. This has been caught by clang -Wtautological-compare:
+
+pw-pbkdf2.c:132:17: warning: comparison of unsigned expression 0 is always false
+if(msg-bv_len 0){
+ ~~~ ^ ~
+
+Signed-off-by: Luca Bruno luca.br...@rocket-internet.de
+---
+ contrib/slapd-modules/passwd/pbkdf2/pw-pbkdf2.c | 8 +---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/contrib/slapd-modules/passwd/pbkdf2/pw-pbkdf2.c b/contrib/slapd-modules/passwd/pbkdf2/pw-pbkdf2.c
+index e7c300e..e0f5dfd 100644
+--- a/contrib/slapd-modules/passwd/pbkdf2/pw-pbkdf2.c
b/contrib/slapd-modules/passwd/pbkdf2/pw-pbkdf2.c
+@@ -99,7 +99,7 @@ static int pbkdf2_format(
+ struct berval *msg)
+ {
+
+- int rc;
++ int rc, msg_len;
+ char salt_b64[LUTIL_BASE64_ENCODE_LEN(PBKDF2_SALT_SIZE) + 1];
+ char dk_b64[LUTIL_BASE64_ENCODE_LEN(PBKDF2_MAX_DK_SIZE) + 1];
+
+@@ -115,13 +115,15 @@ static int pbkdf2_format(
+ return LUTIL_PASSWD_ERR;
+ }
+ b64_to_ab64(dk_b64);
+- msg-bv_len = asprintf(msg-bv_val, %s%d$%s$%s,
++ msg_len = asprintf(msg-bv_val, %s%d$%s$%s,
+ sc-bv_val, iteration,
+ salt_b64, dk_b64);
+-
Bug#795000: deb/control: Homepage points to pylint-plugins-utils
Source: pylint-django Version: 0.6-1 Severity: minor Very minor bug, Homepage: points to https://github.com/landscapeio/pylint-plugin-utils. Thanks for packaging this, helped a lot. Prospector is just around the corner. Cheers, DS -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794967: zsh: please enhance /etc/zshrc
Hi! Carsten Hey wrote: * Frank Terbeck [2015-08-08 23:46 +0200]: [...] I firmly believe, that a vendor's *global* setup file should be as minimal as possible, which is why I really don't want to add anything that's more than making the zsh defaults behave more robustly across multiple terminals or deal with stuff specific to Debian. It looks like you changed your opinion since you wrote https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622933#10 Heh. I honestly don't even remember sending those mails. I do remember the issue (ie. the fact that Ubuntu does compinit in the global zshrc), but I thought my reaction had matched my reaction right now. For the record, let it be known that the statement from my previous mail in *this* thread is indeed my actual position in the matter. And it has been for a while. I'm sure there is evidence of that in threads of other bug reports that would show that. Today I wouldn't take that code snippet from my own mail to enter our setup. It's the wrong thing to do. I think they still do that in Ubuntu, which is another reason why setopt no_global_rcs is part of my personal zsh setup in my ~/.zshenv file. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794972: Additional information
See also https://bugzilla.redhat.com/show_bug.cgi?id=753882. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783428: RE: Bug#783428: Could not load wine-gecko. HTML rendering will be disabled.
Hi, ok, I lied and had another look. patches/disable/downloading.patch doesn't disable downloading really rather than not trying at all to install either gecko or mono. If disabling downloading is all that's really desired it seems like that patch doesn't even need to be there, rather removing the get_url bit (or everything but install_from_default_dir) in install_addon in addons.c should work. So, did anyone manage to install the current Gecko manually? I wouldn't mind downloading Gecko and installing it without help from apt, but not having a working browser at all makes problems with some programs. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794994: graphite2: FTBFS on !linux archs
Hi, On Sun, Aug 09, 2015 at 08:18:11AM +0200, Pino Toscano wrote: graphite2 1.3.0-1 fails to build on kFreeBSD [1][2] and Hurd [3]. Yeah, noticed already, but thanks. The problem is that tests/graphite.py does not have any library item for these platforms registered in the grfiles dictionary, so the script will fail with a KeyError exception. Got that and my nasty patch was just to add a new line for gnukfreebsd9 :) The fix, which is suitable for upstream (so please do forward it), is to slightly rework the logic for knowing the library name on the current platform: since there will be far more platforms with the name libgraphite2.so (Linux, kFreeBSD, Hurd, and any other BSD platform for sure), then fallback to that name for missing items in the grfiles dictionary. Hence, that dictionary contains now only platforms where the library name is not libgraphite2.so, and the linux2 mapping is no more needed. Patch attached for this. Will do. Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795001: FTBFS: Permission denied: '/usr/bin/easy_install-2.7'
Package: python-pytest-timeout Version: 0.4-1 Severity: important This seems to be fine when building against Jessie, but fails when building against sid. New python executable in py27/bin/python2.7 Also creating executable in py27/bin/python Please make sure you remove any previous custom paths from your /«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/.pydistutils.cfg file. Installing setuptools, pip... Complete output from command /build/python-pytest...x/py27/bin/python2.7 -c import sys, pip; sys...d\] + sys.argv[1:])) setuptools pip: Ignoring indexes: https://pypi.python.org/simple/ Downloading/unpacking setuptools Downloading/unpacking pip Installing collected packages: setuptools, pip Cleaning up... Exception: Traceback (most recent call last): File /usr/share/python-wheels/pip-1.5.6-py2.py3-none-any.whl/pip/basecommand.py, line 122, in main status = self.run(options, args) File /usr/share/python-wheels/pip-1.5.6-py2.py3-none-any.whl/pip/commands/install.py, line 295, in run requirement_set.install(install_options, global_options, root=options.root_path) File /usr/share/python-wheels/pip-1.5.6-py2.py3-none-any.whl/pip/req.py, line 1436, in install requirement.install(install_options, global_options, *args, **kwargs) File /usr/share/python-wheels/pip-1.5.6-py2.py3-none-any.whl/pip/req.py, line 672, in install self.move_wheel_files(self.source_dir, root=root) File /usr/share/python-wheels/pip-1.5.6-py2.py3-none-any.whl/pip/req.py, line 902, in move_wheel_files pycompile=self.pycompile, File /usr/share/python-wheels/pip-1.5.6-py2.py3-none-any.whl/pip/wheel.py, line 339, in move_wheel_files generated.extend(maker.make(spec)) File /«PKGBUILDDIR»/.tox/py27/lib/python-wheels/distlib-0.2.1-py2.py3-none-any.whl/distlib/scripts.py, line 353, in make self._make_script(entry, filenames, options=options) File /«PKGBUILDDIR»/.tox/py27/lib/python-wheels/distlib-0.2.1-py2.py3-none-any.whl/distlib/scripts.py, line 257, in _make_script self._write_script(scriptnames, shebang, script, filenames, ext) File /«PKGBUILDDIR»/.tox/py27/lib/python-wheels/distlib-0.2.1-py2.py3-none-any.whl/distlib/scripts.py, line 231, in _write_script self._fileop.write_binary_file(outname, script_bytes) File /«PKGBUILDDIR»/.tox/py27/lib/python-wheels/distlib-0.2.1-py2.py3-none-any.whl/distlib/util.py, line 388, in write_binary_file with open(path, 'wb') as f: IOError: [Errno 13] Permission denied: '/usr/bin/easy_install-2.7' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794975: mixxx: will FTBFS with unsatisfiable dependencies due to libstdc++ transition
On 2015-08-08 22:30:17, Simon McVittie wrote: Package: mixxx Version: 1.11.0~dfsg-4 Severity: serious Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: libstdc++-cxx11 Tags: patch A binNMU of mixxx failed to build from source prior to the transition from libvamp-hostsdk3 to libvamp-hostsdk3v5. It has not yet been retried, but when it is, it will likely stop at BD-Uninstallable or continue to fail, because it specifically build-depends on the old libvamp-hostsdk3. It is unusual to build-depend on library packages, because the corresponding -dev usually pulls them in, but I assume there is some special reason in this case. The package actually B-D on the corresponding -dev package (vamp-plugins-sdk). So let's just drop the extra libvamp-hostsdk3. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#795002: nmu: motion
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Motion seems to be built in an outdated chroot for the upload. Please rebuild it to use the latest version of libav.*-dev packages which are now built from ffmpeg. nmu motion_3.2.12+git20140228-6 . amd64 . unstable . -m Rebuild against ffmpeg Cheers, Balint signature.asc Description: OpenPGP digital signature
Bug#794993: libsnappy1: library transition may be needed when GCC 5 is the default
On Sun, Aug 9, 2015 at 11:41 AM, Steinar H. Gunderson sgunder...@bigfoot.com wrote: On Sun, Aug 09, 2015 at 07:52:37AM +0200, László Böszörményi wrote: I can upload the patch given there now if you want. Please do. It would be nice if you switch to the 3.0 (quilt) source format as well. --- debian/libsnappy1.symbols 2015-08-08 23:54:52.415075073 + +++ debian/libsnappy1/DEBIAN/symbols 2015-08-08 23:59:25.046660564 + @@ -1,5 +1,5 @@ libsnappy.so.1 libsnappy1 #MINVER# - _ZN6snappy10UncompressEPKcmPSs@Base 1.1.3 + _ZN6snappy10UncompressEPKcmPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.1.3 _ZN6snappy10UncompressEPNS_6SourceEPNS_4SinkE@Base 1.1.3 _ZN6snappy11RawCompressEPKcmPcPm@Base 1.1.3 _ZN6snappy13RawUncompressEPKcmPc@Base 1.1.3 Surely you cannot patch things in DEBIAN/. Please read my mail again: see the attached symbols change, it's not a thing you need to apply - it's the evidence it needs the transition. The proposed NMU is in the other file, in snappy_1.1.3-1_to_1.1.3-1.1.patch (debdiff). Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795002: nmu: motion
On 2015-08-09 10:57:23, Balint Reczey wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Motion seems to be built in an outdated chroot for the upload. Please rebuild it to use the latest version of libav.*-dev packages which are now built from ffmpeg. nmu motion_3.2.12+git20140228-6 . amd64 . unstable . -m Rebuild against ffmpeg This will produce a build without any ffmpeg support at all. All the binaries from the buildds lack dependencies on the libraries from ffmpeg. motion needs a source upload fixing the ffmpeg detection. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#794993: libsnappy1: library transition may be needed when GCC 5 is the default
forcemerge 791289 794993 thanks On Sun, Aug 09, 2015 at 07:52:37AM +0200, László Böszörményi wrote: It seems Matthias missed this C++ library transition. He did not; see #791289. I can upload the patch given there now if you want. --- debian/libsnappy1.symbols 2015-08-08 23:54:52.415075073 + +++ debian/libsnappy1/DEBIAN/symbols 2015-08-08 23:59:25.046660564 + @@ -1,5 +1,5 @@ libsnappy.so.1 libsnappy1 #MINVER# - _ZN6snappy10UncompressEPKcmPSs@Base 1.1.3 + _ZN6snappy10UncompressEPKcmPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.1.3 _ZN6snappy10UncompressEPNS_6SourceEPNS_4SinkE@Base 1.1.3 _ZN6snappy11RawCompressEPKcmPcPm@Base 1.1.3 _ZN6snappy13RawUncompressEPKcmPc@Base 1.1.3 Surely you cannot patch things in DEBIAN/. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795005: ejabberd: [INTL:pt] Updated Portuguese translation for debconf messages
Package: ejabberd version: 15.03-2 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for ejabberd's debconf messages. Translator: Américo Monteiro a_monte...@gmx.com Feel free to use it. For translation updates please contact 'Last Translator' or the Portuguese Translation Team traduz at debianpt.org. -- Melhores cumprimentos/Best regards, Américo Monteiro ejabberd_15.03-2_pt.po.gz Description: GNU Zip compressed data
Bug#795006: sddm should provide x-display-manager
Package: sddm Version: 0.11.0-3 The package should have a Provides: x-display-manager field. Because of this if I look into the list of x-display-manager, sddm is missing. A Tag: field in the description would be nice, too. Suggestion (adapted from kdm): Tag: implemented-in::c++, interface::daemon, interface::x11, network::server, role::program, uitoolkit::qt, use::login, x11::application, x11::display-manager -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794986: Does not scale up fonts on a high-DPI display (Xft.dpi)
On a high-DPI display, with Xft.dpi set to a large value, stellarium does not scale up the fonts in its rendering window to match, making them unreadably small. Please scale these fonts up based on Xft.dpi. Hi! I disagree - it's not a bug, because Stellarium has option in config.ini file for setting size of font. -- With best regards, Alexander
Bug#794961: Hard-codes 'firefox' as system browser
control: tags -1 newcomer On Sat, Aug 08, 2015 at 02:22:38PM -0400, Benjamin Barenblat wrote: Package: lilyterm Version: 0.9.9.4-3 Severity: minor Upstream’s default configuration file hard-codes 'firefox' and 'thunderbird' as URL handlers. Debian should patch this configuration file to invoke 'sensible-browser' or 'xdg-open' as appropriate. Upstream seems uninterested in changing this behaviour https://github.com/Tetralet/LilyTerm/issues/38. Thanks for the report. I will left this issue for anyone who are interested in contributing to Debian. -- ChangZhuo Chen (陳昌倬) czc...@gmail.com http://czchen.info/ Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: Digital signature
Bug#795008: italc-master: please install higher resolution icons
Package: italc-master Version: 1:2.0.2+dfsg1-2+b1 Severity: minor Tags: patch The italc icon looks very blurry on desktops with larger icons (e.g. GNOME). I noticed that there are higher resolution icons available in the source package and also on Wikipedia, see: https://commons.wikimedia.org/wiki/File:Italc_logo.png I included the icon from Wikipedia in the debian source package and changed the rules file (see attached patch). Now the italc icon looks brilliant. -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.1.0-trunk-686-pae (SMP w/5 CPU cores) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages italc-master depends on: ii dpkg 1.17.25 ii italc-client 1:2.0.2+dfsg1-2+b1 ii libc62.19-18 ii libgcc1 1:4.9.2-10 ii libitalccore 1:2.0.2+dfsg1-2+b1 ii libjpeg62-turbo 1:1.3.1-12 ii libpng12-0 1.2.50-2+b2 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqtgui44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libssl1.0.0 1.0.1k-3 ii libstdc++6 4.9.2-10 ii python 2.7.9-1 ii zlib1g 1:1.2.8.dfsg-2+b1 italc-master recommends no packages. italc-master suggests no packages. -- no debconf information --- Programme/italc-2.0.2+dfsg1.orig/debian/rules 2014-08-18 14:42:47.0 +0200 +++ lernstick/backports/jessie/src/italc-2.0.2+dfsg1/debian/rules 2015-08-09 12:42:46.688693038 +0200 @@ -38,6 +38,11 @@ common-install-arch:: debian/italc.xpm install -D -m 644 debian/italc.xpm debian/italc-master/usr/share/pixmaps/italc.xpm + install -D -m 644 debian/Italc_logo.png debian/italc-master/usr/share/icons/hicolor/256x256/apps/italc.png + install -D -m 644 lib/resources/icon64.png debian/italc-master/usr/share/icons/hicolor/64x64/apps/italc.png + install -D -m 644 lib/resources/icon32.png debian/italc-master/usr/share/icons/hicolor/32x32/apps/italc.png + install -D -m 644 lib/resources/icon22.png debian/italc-master/usr/share/icons/hicolor/22x22/apps/italc.png + install -D -m 644 lib/resources/icon16.png debian/italc-master/usr/share/icons/hicolor/16x16/apps/italc.png install -D -m 644 debian/config/iTALC.conf.in debian/italc-client/etc/xdg/iTALC\ Solutions/iTALC.conf ln -s ../xdg/iTALC\ Solutions/iTALC.conf debian/italc-client/etc/italc/italc.conf
Bug#794987: mercurial-git: failed to import extension hgext.git: No module named ignore
Control: forwarded -1 https://bitbucket.org/durin42/hg-git/issues/157/hg-git-081-doesnt-work-under-mercurial-35 On Sat, Aug 08, 2015 at 10:04:18PM -0400, James McCoy wrote: Package: mercurial-git Version: 0.8.1-2 Severity: important In a repository using hg-git: $ hg status *** failed to import extension hgext.git: No module named ignore ** unknown exception encountered, please report by visiting ** http://mercurial.selenic.com/wiki/BugTracker ** Python 2.7.10 (default, Jul 1 2015, 10:54:53) [GCC 4.9.2] ** Mercurial Distributed SCM (version 3.5) ** Extensions loaded: color, graphlog, hgk, strip, mq, pager, purge, record, rebase, histedit, gpg Traceback (most recent call last): File /usr/bin/hg, line 43, in module mercurial.dispatch.run() File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 30, in run sys.exit((dispatch(request(sys.argv[1:])) or 0) 255) File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 92, in dispatch ret = _runcatch(req) File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 163, in _runcatch return _dispatch(req) File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 862, in _dispatch repo = hg.repository(ui, path=path) File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 136, in repository peer = _peerorrepo(ui, path, create) File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 123, in _peerorrepo obj = _peerlookup(path).instance(ui, path, create) File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 93, in _peerlookup return thing(path) File /usr/lib/python2.7/dist-packages/hgext/git/__init__.py, line 84, in _local p = urlcls(path).localpath() TypeError: 'NoneType' object is not callable Argh, yes, mercurial-git 0.8.1 doesn't work with hg 3.5. When I uploaded mercurial-git 0.8.1-2, I thought the breaks in mercurial would still be valid (but I didn't check it, and I should have). Sorry for that. I was waiting for a new version of mercurial-git to be released, but given that I've already broken it, I may backport the fix and release a 0.8.1-3 that is compatible with mercurial 3.5. Cheers, Javi signature.asc Description: Digital signature
Bug#795002: nmu: motion
Hi Sebastian, 2015-08-09 11:59 GMT+02:00 Sebastian Ramacher sramac...@debian.org: On 2015-08-09 10:57:23, Balint Reczey wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Motion seems to be built in an outdated chroot for the upload. Please rebuild it to use the latest version of libav.*-dev packages which are now built from ffmpeg. nmu motion_3.2.12+git20140228-6 . amd64 . unstable . -m Rebuild against ffmpeg This will produce a build without any ffmpeg support at all. All the binaries from the buildds lack dependencies on the libraries from ffmpeg. motion needs a source upload fixing the ffmpeg detection. Thanks for pointing that out. I have added this bug to the ffmpeg transition wiki [1]. Are there similar issues? I'm preparing a delayed NMU for taoframework to help the transition finish. Ximin, thanks for fixing the motion issue. Cheers, Balint [1] https://wiki.debian.org/Debate/libav-provider/ffmpeg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795007: [mopidy-youtube] needs python-pafy from stable (not in sid...)
Package: mopidy-youtube Version: 2.0.0-2 Severity: normal Installed mopidy-youtube package from sid in testing. Not problem. Started mopidy (is the same as user or with the init script as root), this message is show in the mopidy start log: Disabled extension youtube: Dependency The 'pafy=0.3.35' distribution was not found and is required by the application not found I have installed the python3-pafy package from testing: 0.3.74-1. This package Replaces and Breaks python-pafy. If I uninstall python3-pafy and install python-pafy from stable (0.3.62-1), now the error dissapear, and I am running mopify with youtube support. Many thanks for the work. Greetings. Martintxo. --- System information. --- Architecture: i386 Kernel: Linux 4.0.2 Debian Release: stretch/sid 500 testing-updates ftp.debian.org 500 testing security.debian.org 500 testing ftp.de.debian.org 10 testing www.deb-multimedia.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. Sustrai Erakuntza: respuesta jurídico-técnica a proyectos insostenibles. proiektu jasangaitzei erantzun juridiko-teknikoa. http://www.fundacionsustrai.org http://www.sustraierakuntza.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774505: bouncy: Window is 4:3 on 16:9 display and not fullscreen or windowed
On Sun, 04 Jan 2015 17:46:49 +0100 Markus Koschany a...@gambaru.de wrote: That gave me a normal fullscreen view. I don't know why the FULLSCREEN option was disabled. It doesn't seem to be a decorated window controlled by the window manager, before the change. bouncy does not provide an option to toggle fullscreen and window mode. I think this might be the reason why the upstream author decided to deactivate FULLSCREEN at that time. I get a fixed window with a viewport of 1024x768 pixel which I can move around. What kind of window manager do you use? Perhaps this bug report should be retitled to please support fullscreen mode. (I am not the original reporter, but) I am running KDE on a laptop with max height 768. The problem of the non-fullscreen mode is that the bottom of the screen is covered by my task bar in the non-decorated mode and is dropping even off my streen in the decorated mode. Having the option to move to FULLSCREEN (via the window manager options) is probably an improvement. Paul signature.asc Description: OpenPGP digital signature
Bug#778039: Patch for GCC 5 build issue
Hello The following commit should fix the build warnings https://github.com/OoliteProject/oolite/commit/80835961e0d0fad8c9dd1bfbd26706808360c66f The commit is to 1.82's version of the files but other than which lines are being patched there shouldn't be any difference to what's needed for 1.77.1 I don't believe this to actually be a security issue - in all five lines the format string is an NSString literal which should be just as safe as a C-string literal. Thanks -- Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794686: nslcd start script does not report starting failure
Control: tags -1 + pending On Wed, 2015-08-05 at 20:02 +0300, Nikolay Shaplov wrote: Package: nslcd Version: 0.9.4-3 Severity: serious Justification: fails to build from source Justification is not right but the init script return code is not according to policy so I'll leave it at serious. # /etc/init.d/nslcd stop [ ok ] Stopping nslcd (via systemctl): nslcd.service. # /etc/init.d/nslcd start [ ok ] Starting nslcd (via systemctl): nslcd.service. It does not report any problem, not to the console, not to the syslog It does report a problem to stderr but systemd seems to hide it when the return code is 0 (that was incorrect). The fix is to remove the last exit 0 from /etc/init.d/nslcd. Thanks for reporting this. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#795004: FTBFS: rspec3: undefined method `color_enabled=' for #RSpec::Core::Config.. (NoMethodError)
Source: ruby-bogus Version: 0.1.5-3 Severity: serious Tags: sid stretch Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs Dear Maintainer, The package fails to build, probably due to incompataility with rspec3: /tmp/buildd/ruby-bogus-0.1.5/spec/spec_helper.rb:12:in `block in top (required)': undefined method `color_enabled=' for #RSpec::Core::Configuration:0x0001637698 (NoMethodError) from /usr/lib/ruby/vendor_ruby/rspec/core.rb:97:in `configure' from /tmp/buildd/ruby-bogus-0.1.5/spec/spec_helper.rb:11:in `top (required)' from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /tmp/buildd/ruby-bogus-0.1.5/spec/bogus/clean_ruby_spec.rb:1:in `top (required)' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1327:in `load' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1327:in `block in load_spec_files' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1325:in `each' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1325:in `load_spec_files' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:103:in `setup' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:89:in `run' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:74:in `run' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:42:in `invoke' from /usr/bin/rspec:4:in `main' Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/ruby-bogus.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791168: libsidplay: diff for NMU version 1.36.59-7.1
Hi Jonathan, On Sat, Aug 8, 2015 at 4:54 PM, Jonathan Wiltshire j...@debian.org wrote: I've prepared an NMU for libsidplay (versioned as 1.36.59-7.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks! But I had other things to apply and -8 is uploaded and just accepted. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795002: nmu: motion
Control: reassign -1 motion Control: retitle -1 motion fails to detects newer ffmpeg and silently disables all ffmpeg features Control: severity -1 serious Hi, Please don't do a binNMU, the package fails to detect ffmpeg and will silently disable everything. This is already affecting all non-amd64 packages (i.e. the ones I didn't build myself). I will fix this shortly. X On 09/08/15 10:57, Balint Reczey wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Motion seems to be built in an outdated chroot for the upload. Please rebuild it to use the latest version of libav.*-dev packages which are now built from ffmpeg. nmu motion_3.2.12+git20140228-6 . amd64 . unstable . -m Rebuild against ffmpeg Cheers, Balint -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794963: libnet-xmpp-perl: Insecure dependency in eval (...) at /usr/share/perl5/Net/XMPP/Protocol.pm line 1007.
Axel Beckert wrote... Can you give me some example code which triggers this issue so that I can test if it's fixed with the new upstream release? It's rather simple: Use Net::XMPP while running setuid. So execute the following code as root after adjusting the server information and credentials, login must succeed to trigger the error. Discussion follows. == #!/usr/bin/perl use 5.010; use strict; use warnings; use Net::XMPP; $ = 65534; my $Connection = Net::XMPP::Client-new (); my $status = $Connection-Connect ( 'hostname' = 'server.example.com', 'port' = 5222, ) or die; my @result = $Connection-AuthSend ( 'username' = 'user', 'password' = 'pass', 'resource' = 'whatever', ); == This might raise the question why somebody would want to do run such a script setuid. The proper answer however was to question why anyone of upstream, packagers and otherwise Perl related folks would want to bar them from doing so. This is a political question, and it's not limited to libnet-xmpp-perl in any way: Are Perl modules expected to work in stricter environments, where the runtime enforces rules it usually does not, like taint mode or when running setuid like here? In my opinion yes but it's a tough job to identify all the places in the code, and sometimes fixing them isn't easy either. So this should be decided on a big scale, as a release goal, at debian-devel and/or DebConf, and libnet-xmpp-perl might not be the right place to exercise this beforehand. However, in my case the answer is a bit different. The client code is a daemon that relays messages received via XMPP. It gets started using start-stop-daemon, then drops privileges. Instead of using POSIX::setuid this was done manually by setting $ but not $, and things went downhill from there. In other words, running setuid was not intended anyway and that code has been fixed now. Long story short: Feel free to lower severity. Using code in eval ... is evil. Upstream's recent change did not remove the error. Christoph signature.asc Description: Digital signature
Bug#718476: minitube: Minitube can not play any video
Package: minitube Version: 2.2-1 Followup-For: Bug #718476 Dear Maintainer, I can confirm the problem, but I have the following error message: QPainter::begin: Paint device returned engine == 0, type: 3 QPainter::setCompositionMode: Painter not active QPainter::end: Painter not active, aborted 410 Error downloading http://gdata.youtube.com/feeds/api/videos/?v=2max-results=10start-index=1q=la%20citt%C3%A0%20vecchia - server replied: Gone 299 Thanks for your kind efforts pkz -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') 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 minitube depends on: ii dbus-x11 1.8.18-0+deb8u1 ii libc62.19-18 ii libgcc1 1:4.9.2-10 ii libphonon4 4:4.8.0-4 ii libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-script4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-sql 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqtgui44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libstdc++6 4.9.2-10 ii phonon 4:4.8.0-4 ii phonon-backend-vlc [phonon-backend] 0.8.0-2 minitube recommends no packages. minitube 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#570226: squid: please rebuild with --enable-ssl
Package: squid3 Version: 3.4.8-5 Followup-For: Bug #570226 Dear Maintainer, I'v looked a bit at this bug report, being also interested in SSL support, I saw your reference to bug 180886. This bug, in turn, refers to [0], which, if you look at the bottom of the report page, suggest using options like: --with-gnutls --without-openssl So, it seems that some progress have been made and that it would now be possible to build squid without linking on OpenSSL. Note that the bug report on Squid BTS is not close but it looks like it exists for other reasons (ie: building something more neutral). However, it seems we can already build without openssl (and with ssl support of couse ;-)). If this is indeed the case, could you please build Squid with the following options: --enable-ssl and --enable-ssl-crtd --with-gnutls --without-openssl Thanks in advance and best regards, Nicolas [0] http://bugs.squid-cache.org/show_bug.cgi?id=2741 -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') 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 squid3 depends on: ii adduser 3.113+nmu3 ii libc62.19-18 ii libcap2 1:2.24-8 ii libcomerr2 1.42.12-1.1 ii libdb5.3 5.3.28-9 ii libecap2 0.2.0-3 ii libexpat12.1.0-6+deb8u1 ii libgcc1 1:4.9.2-10 ii libgssapi-krb5-2 1.12.1+dfsg-19 ii libk5crypto3 1.12.1+dfsg-19 ii libkrb5-31.12.1+dfsg-19 ii libldap-2.4-22.4.40+dfsg-1 ii libltdl7 2.4.2-1.11 ii libnetfilter-conntrack3 1.0.4-1 ii libnettle4 2.7.1-5 ii libpam0g 1.1.8-3.1 ii libsasl2-2 2.1.26.dfsg1-13 ii libssl1.0.0 1.0.1k-3+deb8u1 ii libstdc++6 4.9.2-10 ii libxml2 2.9.1+dfsg1-5 ii logrotate3.8.7-1+b1 ii lsb-base 4.1+Debian13+nmu1 ii netbase 5.3 pn squid3-commonnone squid3 recommends no packages. Versions of packages squid3 suggests: pn resolvconf none pn smbclientnone pn squid-cginone pn squid-purge none pn squidclient none pn ufw none pn winbindd none -- Configuration Files: /etc/logrotate.d/squid3 [Errno 2] No such file or directory: u'/etc/logrotate.d/squid3' /etc/squid3/squid.conf 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#793939: [RFR] templates://publicfile-installer/{templates}
Christian PERRIER wrote: Quoting Justin B Rye (justin.byam@gmail.com): But why does it need a special script to install a package? (Goes and looks...) Yipe! It just checks I'm root and then runs dpkg -i /tmp/publicfile-installer/publicfile*_*.deb Does the build really leave its output in a predictable location in a world-writable directory? (Checks) Yes, so if my evil kid brother has created a /tmp/publicfile-installer/publicfile_0.52-0_amd64.deb, the build-script will happily dump its .deb alongside it. Then when I run sudo install-publicfile it'll install the bogus package first, executing its install-scripts as root. That seems correct and probably deserves another bug report, in my opinion. Thanks for pointing this, Justin... Unfortunately, fixing it probably requires changes to the visible behaviour of the scripts that would mean changes to these debconf prompts, so we'll need to put this review on hold. I'm sending the bug to the security team (CCing the maintainer) rather than the BTS in the hope that nobody reads d-l-e and we can call this an undisclosed exploit. Meanwhile, when I look for a fix I keep banging my head on further bugs. For a start, how are manual unprivileged fakeroot builds supposed to happen in /usr/src/publicfile-installer/, where I don't have write access? Yes, it'll use $HOME/.publicfile-installer/ if I've created it, but the instructions don't mention that stage. This looks like more work to do in the debconf prompts. And if the current $BUILDDIR might not be the same as the previous $BUILDDIR, before it launches the build it really ought to ask dpkg whether publicfile is already installed, and if so, at what version. Just looking for a .deb lying around nearby isn't enough. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793599: Bug 792599: dbconfig-common must be more robust during removal against packages not depending on command-line client
Control: tags -1 moreinfo Hi Andreas (and other interested parties) On Sat, 25 Jul 2015 13:08:32 +0200 Andreas Beckmann a...@debian.org wrote: Severity: serious User: debian...@lists.debian.org Usertags: piuparts during a test with piuparts I noticed your package fails to remove. Can you please elaborate on your test (and what you think is reasonable to expect)? I may be wrong, but it seems you are preseeding answers to the debconf questions of pdns/dbconfig-common which may be a little weird in this case. You are removing the mysql-server and still request the package in question to purge the database first. Also I believe you are using the non-interactive frontend (is that correct?) Anyways, we may have a difficult choice to make (please help). First the background ideas. 1) The idea of having the possibility of having the clients as a recommend instead of a depends is that the system admin may opt-out of dbconfig-common assistance and configure the package manually that depends on dbconfig-common to do the db configuration. Most packages don't need the client to operate, only dbconfig-common needs it for configuration (which may be skipped). But dbconfig-common shouldn't depend on all the different db clients that it supports, while that also pollutes the system. Unfortunately, once dbconfig-common is running, there is no way to install the required client on demand until bug 421055 [1] is fixed. 2) The idea of failing during removal/purge stems from the idea that you want the package that is removed to clean up e.g. any credentials still laying around and possibly also the database. If I would opt-in for this, I would want to be notified rather noisily when this fails; in dbconfig-common you currently get an error with accompanying question if you want to abort/retry/retry with questions/ignore. Also, if the package is configured with dbconfig-common, I would expect it to be possible to clean up with dbconfig-common. Remember that the database may not be on the same system as where the client should be running. Now, what you are requesting here is that we either break the first idea or the second and I am not sure which one to choose. An idea however, for installations (as in, during install) with the non-interactive frontend, dbconfig-common already defaults to ignore. I am not sure if it is a good work around for this case, but would it actually be acceptable for you and do you believe it solves your reported problem? Paul [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421055 signature.asc Description: OpenPGP digital signature
Bug#795009: i3: crashes after suspend when using only external monitor
Package: i3 Version: 4.10.3-1 Severity: normal Dear Maintainer, I've connected an external monitor to my laptop and use `xrandr --output HDMI1 --primary --auto --output LVDS1 --off` to only use the external monitor and not the laptop screen. I use `i3lock systemctl suspend` to lock and suspend. Until recently this worked just fine. Now, when I wake my laptop from suspend, my i3 session has crashed and I'm back at my display manager. Relevant lines from ~/.xsession-errors: i3: No usable outputs available. Exiting due to signal. i3lock: X11 connection broke, did your server terminate? i3 also crashes when I disconnect the external monitor (and the laptop screen is disabled). To confirm that it really seems to be i3 that's at fault: openbox works fine. For now, I'm re-enabling the external monitor before suspend and re-disabling it again afterwards as a workaround. But of course it'd be preferable if i3 did not crash. Please let me know if there's anything I can do to help. Thanks. - Felix -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages i3 depends on: ii i3-wm 4.10.3-1 Versions of packages i3 recommends: ii dunst 1.1.0-2 ii i3lock 2.7-1 ii i3status2.9-2 ii suckless-tools 40-1 i3 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#790975: fixed in afflib 3.7.6-4
The whole point of this transition is that the rebuilt library is not compatible. So it can't provide the old name and there can't be a transitional package. Cheers Julien On August 9, 2015 8:25:46 AM CEST, Eriberto Mota eribe...@debian.org wrote: Hi Julien, I applied your patch and I updated some symbols. However, I added a binary libafflib0 as transitional package to avoid break some packages. Is there any problem in doing that? I attached a debdiff between afflib-3.7.6-4 and 3.7.6-5. Thanks a lot in advance. Regards, Eriberto 2015-08-06 19:14 GMT-03:00 Eriberto eribe...@eriberto.pro.br: Hi Julien, Thanks a lot for your quick reply. I will wait 2 days to fix some symbols for ports. Regards, Eriberto 2015-08-06 18:08 GMT-03:00 Julien Cristau jcris...@debian.org: On Thu, Aug 6, 2015 at 22:55:32 +0200, Julien Cristau wrote: On Thu, Aug 6, 2015 at 17:44:32 -0300, Eriberto wrote: Hum... Sorry, can you detail for me how to proceed? Need I use v5? Yes, something like the patch below. ... except with the .symbols files fixed to refer to libafflib0v5 instead of libafflib0; sorry about that. Cheers, Julien -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#789757: ejabberd: General update after the debconf review process
Am 08.08.2015 um 19:54 schrieb Christian PERRIER: Quoting Philipp Huebner (debala...@debian.org): Hi again, I just realized/remembered that I switched ejabberd's admin interface to https for the next upload, but the template and all the translation still have the http url in them. Can I simply replace http with https in the template and all the translations? Or would that somehow invalidate them? If so, what else is necessary? You can search/replace s/http/https certainly. I'd recommend to do this first on PO files, then on the templates files. The most important thing is that you should NOT make the change to templates files and run debconf-updatepo as all translations would have strings marked as fuzzy. Okay, I've done so and also added the pt and pt_BR updates that arrived after your deadline. I'll wait a few more days, do some testing and then upload ejabberd 15.03-2. Regards, -- .''`. Philipp Huebner debala...@debian.org : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#794466: Virtualbox might not be suitable for Stretch
On Sat, 2015-08-08 at 20:11 +0200, Markus Frosch wrote: Hi Gianfranco, thanks for your summary. Although I'm not involved in maintaining virtualbox, still a few thoughts: * What would that mean for Jessie updates? * Isn't that basically the same problem we have with MySQL, or even Iceweasel? So I think the question is either drop, or work with upstream releases, from which I'd personally prefer. Not sure about MySQL, but for Iceweasel, is it really like that ? From what I've known, there were trademark issues which led to the rebranding. I'm not sure how they handle vulnerabilities. But their release strategy is: ESR and Regular releases. Every security fix goes into the next Regular release, and also the ESR release. ESR is supported until the next ESR (31 = 38). So usually the Debian Mozilla team prefers the ESR branch for Debian stable. With VBox, they don't have an ESR model. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#794955: gperf: Embedded code copy with missing copyright
Hi, On 08/08/2015 08:52 PM, Hilko Bengen wrote: Can you tell me a reliable source for that copyright information? I found that information on the debian/copyright of the Debian texi2html which I expect should be a reliable source. Thanks for the quick reply! akira signature.asc Description: OpenPGP digital signature
Bug#701518: lm-sensors unable to detect/control fan of HP Compaq 6730s laptop
On 2013-06-29 15:25, Aurelien Jarno wrote: On Mon, Feb 25, 2013 at 01:55:40AM +1100, Tim Long wrote: Package: lm-sensors Version: 1:3.3.2-2 Severity: normal Dear Maintainer, Updating my (HP Compaq 6730s) laptop to wheezy I can't get fancontrol to run properly. Was it working correctly before upgrading to wheezy? Note also that on a laptop the fan speed is supposed to already be controlled by the BIOS, at the fan is usually common to the CPU and the GPU. I think lm-sensors is unable to find/configure the fan control system. After the install I get the following message on boot up: === [warn] Not starting fancontrol; run pwmconfig first. ... (warning). === Running pwmconfig I get the following error message: === /usr/sbin/pwmconfig: There are no pwm-capable sensor modules installed === Running the 'sensors' command I turn up the following: === acpitz-virtual-0 Adapter: Virtual device temp1:+53.0°C (crit = +110.0°C) temp2:+49.0°C (crit = +256.0°C) temp3:+49.0°C (crit = +112.0°C) temp4:+51.0°C (crit = +105.0°C) temp5:+30.6°C (crit = +112.0°C) temp6:+50.0°C (crit = +110.0°C) coretemp-isa- Adapter: ISA adapter Core 0: +45.0°C (high = +105.0°C, crit = +105.0°C) Core 1: +49.0°C (high = +105.0°C, crit = +105.0°C) === Running sensors-detect I get the following: === # sensors-detect # sensors-detect revision 6031 (2012-03-07 17:14:01 +0100) # System: Hewlett-Packard HP Compaq 6730s [F.07] (laptop) # Board: Hewlett-Packard 30E9 This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): ^C walter:/var/log# sensors-detect | tee /tmp/sensors-detect.log ^Cwalter:/var/log# clear walter:/var/log# sensors-detect # sensors-detect revision 6031 (2012-03-07 17:14:01 +0100) # System: Hewlett-Packard HP Compaq 6730s [F.07] (laptop) # Board: Hewlett-Packard 30E9 This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): y Module cpuid loaded successfully. Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors...No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 15h power sensors... No Intel digital thermal sensor... Success! (driver `coretemp') Intel AMB FB-DIMM thermal sensor... No VIA C7 thermal sensor...No VIA Nano thermal sensor... No Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): y Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... Yes Found unknown chip with ID 0x4501 Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Some hardware monitoring chips are accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): y Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Lastly, we can probe the I2C/SMBus adapters for connected hardware monitoring devices. This is the most risky part, and while it works reasonably well on most
Bug#795003: circuslinux: Can't open old options file/scorefile for writing
Package: circuslinux Version: 1.0.3-31 Severity: normal Dear Maintainer, running circuslinux from the command line produces the following error messages: -- Warning: I could not open old options file : /home/username/.circuslinux The error that occured was: No such file or directory -- and -- Warning: I could not open the score file for write: /var/games/circuslinux/scorefile The error that occured was: Permission denied -- This means that both options and scores are not saved. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=sl_SI.UTF-8, LC_CTYPE=sl_SI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages circuslinux depends on: ii circuslinux-data 1.0.3-31 ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18 ii libsdl-image1.21.2.12-5+b5 ii libsdl-mixer1.21.2.12-11+b1 ii libsdl1.2debian1.2.15-10+b1 circuslinux recommends no packages. circuslinux suggests no packages. -- debconf information: circuslinux/merge_score_files: circuslinux/score_file_exists: circuslinux/shared_score_file: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732723: cegui-mk2: Please upgrade OGRE dependency to 1.9 when upstream ready
Hi, On Sun, Aug 9, 2015 at 1:55 AM, Corey Hickey bugfoo...@fatooh.org wrote: Hi, This package is apparently not installable on sid now. 1. libcegui-mk2-0.7.6 requires libogre-1.8.0 2. libstdc++6 Breaks libogre-1.8.0 = 1.8.0+dfsg1-7+b1 Updating libogre-1.8.0 is apparently a wontfix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791222 Can you please prepare a new upload as mentioned? I have prepared an upload¹, I am waiting it passes the NEW process. Hopefully in a couple of weeks it should be done. If it does not pass, I will upload a revision of 0.7.6. Regards, 1. https://ftp-master.debian.org/new/cegui-mk2_0.8.4-2.html -- Muammar El Khatib. Linux user: 403107. GPG Key = 71246E4A. http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794790: gnome-shell: unmet dependencies against evolution-data-server (= 3.7.90) and gnome-contacts
On Thu, 6 Aug 2015 23:08:12 +0200 Michael Biebl bi...@debian.org wrote: Am 06.08.2015 um 17:58 schrieb Roy Sindre Norangshol: Source: gnome-shell Severity: important Dear Maintainer, After a apt-get dist-upgrade I was too quickly disposing of gnome-shell when upgrading my system. After trying apt-get install gnome-shell afterwards it tells me that it has unmet dependencies. The following packages have unmet dependencies: gnome-shell : Depends: evolution-data-server (= 3.7.90) but it is not going to be installed Recommends: gnome-contacts but it is not going to be installed It might be a problem with libphonenumber6 which is one of it's transitive dependencies which requires liboost-date-time.155.0 apt-get install gnome-shell libphonenumber6 libboost-date-time1.55.0 libstdc++6 norangshol@bluebox:~$ sudo apt-get install gnome-shell libphonenumber6 libboost-date-time1.55.0 libstdc++6 Reading package lists... Done Building dependency tree Reading state information... Done libstdc++6 is already the newest version. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libstdc++6 : Breaks: libboost-date-time1.55.0 but 1.55.0+dfsg-4 is to be installed E: Unable to correct problems, you have held broken packages. Those broken dependencies are due to the ongoing GCC 5 transition. This will be sorted out once the transition is complete. When it will be ready, is there any temperary solution for it? Thanks! Closing as not-a-bug. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Bin Li (bin...@canonical.com) OEM team in Beijing signature.asc Description: Digital signature
Bug#791053: gmp: library transition may be needed when GCC 5 is the default
On 2015-07-03 Matthias Klose d...@debian.org wrote: Package: src:gmp Version: 6.0.0+dfsg-6 Severity: important Tags: sid stretch User: debian-...@lists.debian.org Usertags: libstdc++-cxx11 [...] What is needed: - Rebuild the library using g++/g++-5 from experimental. Note that most likely all C++ libraries within the build dependencies need a rebuild too. You can find the log for a rebuild in https://people.debian.org/~doko/logs/gcc5-20150701/ Search for BEGIN GCC CXX11 in the log. Hello, I have rebuilt gmp with both gcc-4.9 and gcc-5 on i386, used dpkg-gensymbols to generate a symbol file for libgmpxx4ldbl and have compared the results: ametzler@argenau:/tmp/GMP$ diff -NrBbpu */gmp-6.0.0+dfsg/debian/libgmpxx4ldbl/DEBIAN/symbols --- gcc49/gmp-6.0.0+dfsg/debian/libgmpxx4ldbl/DEBIAN/symbols2015-08-09 11:16:10.676611618 +0200 +++ gcc5/gmp-6.0.0+dfsg/debian/libgmpxx4ldbl/DEBIAN/symbols 2015-08-09 11:06:44.661672208 +0200 @@ -1,6 +1,6 @@ libgmpxx.so.4 libgmpxx4ldbl #MINVER# _Z22__gmp_istream_set_baseRSiRcRbS1_@Base 2:6.0.0+dfsg-7 - _Z24__gmp_istream_set_digitsRSsRSiRcRbi@Base 2:6.0.0+dfsg-7 + _Z24__gmp_istream_set_digitsRNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSiRcRbi@Base 2:6.0.0+dfsg-7 _Z26__gmpz_operator_in_nowhiteRSiP12__mpz_structc@Base 2:6.0.0+dfsg-7 _Z28__gmp_doprnt_integer_ostreamRSoP15doprnt_params_tPc@Base 2:6.0.0+dfsg-7 _Z28__gmp_doprnt_params_from_iosP15doprnt_params_tRSt9basic_iosIcSt11char_traitsIcEE@Base 2:6.0.0+dfsg-7 Which shows that only a single symbol changed, c++-filt translates this to - __gmp_istream_set_digits(std::basic_stringchar, std::char_traitschar, std::allocatorchar , std::basic_istreamchar, std::char_traitschar , char, bool, int) + __gmp_istream_set_digits(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar , std::basic_istreamchar, std::char_traitschar , char, bool, int) Afaiui __gmp_istream_set_digits() is an internal symbol and not part of the public API. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794974:
It seem the shortcut on the K menu don't point on the right place. It should be /usr/game/steam. On 09/08/2015 00:28, Michael Gilbert wrote: control: tag -1 moreinfo, unreproducible This isn't enough information to debug the problem. Please attach your ~/.steam/error.log file. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704160: kpartx says it will create /dev/loop0p1 but uses other names
On Fri, 2013-03-29 at 20:53 -0400, Stefan Monnier wrote: I suggested to fix it by adding a /dev/loop0p1 symlink, Why? That part is anyways taken care by partx. So maybe the problem is in partx. I must say I don't know what's the relationship between partx and kpartx. All I know is that the loop0p1 mentioned in the output of kpartx -l (made a lot of sense and) created for me the expectation to find a /dev/loop0p1. Instead I had to look by hand for some symlink in /dev/disk to figure out which name can be used. Hello Stefan, How are you ? Time flies. I did not realize that this bug report is from 2013. :-) I was doing the periodical refresh of multipath-tools and dug up on your bug report. While I agree that the output of `kpartx -l` makes it look obvious that the device mentioned resides in /dev/. But I think this is well covered in the man page. Quoting it... EXAMPLE To mount all the partitions in a raw disk image: kpartx -av disk.img This will output lines such as: loop3p1 : 0 20964762 /dev/loop3 63 The loop3p1 is the name of a device file under /dev/mapper which you can use to access the partition, for example to fsck it: fsck /dev/mapper/loop3p1 When you're done, you need to remove the devices: kpartx -d disk.img -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#794892: autogen: please make the build reproducible (cpu, locale, timestamps)
Bruce Korb: Obviously, I can make no changes to Debian rules, but I have now added a working --enable-timeout=$WHATEVER configure option: http://autogen.sourceforge.net/data/autogen-5.18.6pre11.tar.xz Thanks Bruce. I believe this is going to be of interest to all binary distributions. Most of them use automated builders that are far more powerful than some machines then used by users. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#711332: RM: w3c-dtd-xhtml -- RoQA; superseded by w3c-sgml-lib
On 2015-07-26 20:41, Mathieu Malaterre wrote: Indeed something went wrong in #787178. Andreas, I am starring at the debdiff for wdg-html-validator in between 1.6.2-7 1.6.2-8. Here is what I see here: I very much appreciate your time for this QA upload but I believe something went wrong. Thanks again for your time. d/changelog being the only file changed ... that looks weird. I don't really remember what happened here, that changelog message does not really fit the bug, most probably I uploaded a (completely different and unrelated) source package from the wrong directory while I tried to fix some FTBFS or similar bug. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus
Control: forwarded -1 https://gcc.gnu.org/PR67165 On 08/03/2015 10:26 AM, Aurelien Jarno wrote: On 2015-08-03 09:57, Basile Starynkevitch wrote: I would believe that is not easily possible. I don't know the detailed behavior of libbacktrace, but it is using parsing the DWARF debug information of the binaries (cc1, cc1plus, ...), so I guess you'll need to patch (significantly) libbacktrace to compress the debug sections. compressed debug sections is kind of standard these days, so libbacktrace should support that. no. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791226: add patch
Control: tags -1 + patch
this depends on the openexr transition.
* Rename library packages for g++5 ABI transition.
diff -Nru opencv-2.4.9+dfsg/debian/control opencv-2.4.9+dfsg/debian/control
--- opencv-2.4.9+dfsg/debian/control2014-09-08 10:10:39.0 +
+++ opencv-2.4.9+dfsg/debian/control2015-08-06 07:19:43.0 +
@@ -92,15 +92,15 @@
Package: libcv2.4
Architecture: all
Depends: ${misc:Depends},
- libopencv-core2.4,
- libopencv-imgproc2.4,
- libopencv-flann2.4,
- libopencv-features2d2.4,
- libopencv-calib3d2.4,
- libopencv-objdetect2.4,
- libopencv-legacy2.4,
- libopencv-video2.4,
- libopencv-ml2.4
+ libopencv-core2.4v5,
+ libopencv-imgproc2.4v5,
+ libopencv-flann2.4v5,
+ libopencv-features2d2.4v5,
+ libopencv-calib3d2.4v5,
+ libopencv-objdetect2.4v5,
+ libopencv-legacy2.4v5,
+ libopencv-video2.4v5,
+ libopencv-ml2.4v5
Description: computer vision library - libcv* translation package
This package provide files for translation from libcv2.1 to libcv2.4.
.
@@ -141,7 +141,7 @@
Package: libhighgui2.4
Architecture: all
Depends: ${misc:Depends},
- libopencv-highgui2.4
+ libopencv-highgui2.4v5
Description: computer vision library - libhighgui translation package
This package provide files for translation from libhighgui2.1 to
libhighgui2.4.
.
@@ -186,14 +186,14 @@
Package: libcvaux2.4
Architecture: all
Depends: ${misc:Depends},
- libopencv-core2.4,
- libopencv-imgproc2.4,
- libopencv-features2d2.4,
- libopencv-calib3d2.4,
- libopencv-objdetect2.4,
- libopencv-legacy2.4,
- libopencv-video2.4,
- libopencv-contrib2.4
+ libopencv-core2.4v5,
+ libopencv-imgproc2.4v5,
+ libopencv-features2d2.4v5,
+ libopencv-calib3d2.4v5,
+ libopencv-objdetect2.4v5,
+ libopencv-legacy2.4v5,
+ libopencv-video2.4v5,
+ libopencv-contrib2.4v5
Description: computer vision library - libcvaux translation package
This package provide files for translation from libcvaux2.1 to libcvaux2.4.
.
@@ -274,7 +274,7 @@
Section: libdevel
Architecture: any
Multi-Arch: same
-Depends: ${misc:Depends}, libopencv-core2.4 (= ${binary:Version}),
+Depends: ${misc:Depends}, libopencv-core2.4v5 (= ${binary:Version}),
zlib1g-dev
Description: development files for libopencv-core
This package contains the header files and static library needed to compile
@@ -290,12 +290,14 @@
analysis, structural analysis, motion analysis and object tracking, object
recognition, camera calibration and 3D reconstruction.
-Package: libopencv-core2.4
+Package: libopencv-core2.4v5
Section: libs
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${shlibs:Depends}
+Conflicts: libopencv-core2.4
+Replaces: libopencv-core2.4
Description: computer vision core library
This package contains the OpenCV (Open Computer Vision) core runtime
libraries.
.
@@ -315,7 +317,7 @@
Multi-Arch: same
Depends: ${misc:Depends},
libopencv-core-dev (= ${binary:Version}),
- libopencv-ml2.4 (= ${binary:Version})
+ libopencv-ml2.4v5 (= ${binary:Version})
Description: development files for libopencv-ml
This package contains the header files and static library needed to compile
applications that use OpenCV (Open Computer Vision) Machine Learning library.
@@ -330,13 +332,15 @@
analysis, structural analysis, motion analysis and object tracking, object
recognition, camera calibration and 3D reconstruction.
-Package: libopencv-ml2.4
+Package: libopencv-ml2.4v5
Section: libs
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends},
- libopencv-core2.4 (= ${binary:Version})
+ libopencv-core2.4v5 (= ${binary:Version})
+Conflicts: libopencv-ml2.4
+Replaces: libopencv-ml2.4
Description: computer vision Machine Learning library
This package contains the OpenCV (Open Computer Vision) Machine Learning
runtime libraries.
@@ -357,7 +361,7 @@
Multi-Arch: same
Depends: ${misc:Depends},
libopencv-core-dev (= ${binary:Version}),
- libopencv-imgproc2.4 (= ${binary:Version})
+ libopencv-imgproc2.4v5 (= ${binary:Version})
Description: development files for libopencv-imgproc
This package contains the header files and static library needed to compile
applications that use OpenCV (Open Computer Vision) Image Processing library.
@@ -372,13 +376,15 @@
analysis, structural analysis, motion analysis and object tracking, object
recognition, camera calibration and 3D reconstruction.
-Package: libopencv-imgproc2.4
+Package: libopencv-imgproc2.4v5
Section: libs
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends},
- libopencv-core2.4 (= ${binary:Version})
+ libopencv-core2.4v5 (=
Bug#755359:
do you need financial help? contact us today
Bug#795022: icedove: 'ssl_error_weak_server_ephemeral_dh_key' connection to IMAP server broken
Package: icedove Version: 31.8.0-1~deb8u1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgrade of cryptography standard of my hoster's mail server from SSL 3.0 to TLS 1.2. Before implementation of TLS 1.2 I used the workaround of setting the security.tls.version.min to 0 in the registry. Strangely, the config had to be altered every time on startup. * What exactly did you do (or not do) that was effective (or ineffective)? Proposed workaround of Bugzilla Bug 1184488 was not effective: security.ssl3.dhe_dss_aes_128_sha;false security.ssl3.dhe_rsa_aes_128_sha;false security.ssl3.dhe_rsa_aes_256_sha;false security.ssl3.dhe_rsa_des_ede3_sha;false * What was the outcome of this action? Issue still exists, error console still reports two errors when trying to connect: 1) 'ssl_error_bad_cert_domain' - certificate appears to be valid only for my hoster. mail.example.at:143 uses an invalid security certificate. Certificate only valid for *.hoststar.at, hoststar.at 2) 'ssl_error_weak_server_ephemeral_dh_key' - according to ssllabs.com, the mailserver provides 1024 bit DH keys. Two tests were performed in the commandline, both returning errors: $ openssl s_client -connect mail.jazzco.at:143 -cipher EDH | grep Server Temp Key $ openssl s_client -connect mail.jazzco.at:143 -cipher ECDHE * Please anonymize relevant parts of this bugreport. Is this a proper bug or just a safety issue concerning my hoster? Cheers! *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages icedove depends on: ii debianutils 4.4+b1 ii fontconfig2.11.0-6.3 ii libasound21.0.28-1 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-18 ii libcairo2 1.14.0-2.1 ii libdbus-1-3 1.8.18-0+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-2 ii libffi6 3.1-2+b2 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-3 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-3 ii libhunspell-1.3-0 1.3.3-3 ii libnspr4 2:4.10.7-1 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 libpixman-1-0 0.32.6-3 ii libsqlite3-0 3.8.7.1-1+deb8u1 ii libstartup-notification0 0.12-4 ii libstdc++64.9.2-10 ii libvpx1 1.3.0-3 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxrender1 1:0.9.8-1+b1 ii libxt61:1.1.4-1+b1 ii psmisc22.21-2 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages icedove recommends: ii hunspell-de-at [hunspell-dictionary] 20131206-5 ii hunspell-de-ch [hunspell-dictionary] 20131206-5 ii hunspell-de-de [hunspell-dictionary] 20131206-5 ii hunspell-en-us [hunspell-dictionary] 20070829-6 Versions of packages icedove suggests: ii fonts-lyx 2.1.2-2 ii libgssapi-krb5-2 1.12.1+dfsg-19 -- 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#794658: Debian Sid: unresolved dependencies (libphonenumber)
On Thu, 6 Aug 2015 17:33:27 +0200 Jordi Pujol Palomer jordipuj...@gmail.com wrote: Hello, dependencies have not been a problem for me, version 1.58 of that libraries was already installed. the real problem is on maven tests, the package compiled after modifying the file debian/maven.properties uncomment the line: #maven.test.skip=true I can confirm that the package builds fine against boost 1.58 and have fixed the issue with the tests. I will upload one more version of 6 with these fixes (essentially a binNMU + a one-liner patch for the tests), and then return to working on the upload of 7.0.8 that Matthias has suggested. Cheers, tony signature.asc Description: OpenPGP digital signature
Bug#791478: [Openexr-devel] testOptimizedInterleavePatterns.cpp
On 2015-07-06 Ed Hanway ehan...@ilm.com wrote:
Mathieu Malaterre wrote on Sunday, July 05, 2015
[...]
when the test suite runs, here is what I get (debian jessie x86/32bits):
[...]
Running testOptimizedInterleavePatterns
Testing SSE optimisation with different interleave patterns (large images)
[...]
error reading back channel B pixel 96,-62 got -nan expected -nan
lt-IlmImfTest: testOptimizedInterleavePatterns.cpp:238: bool
{anonymous}::compare(const Imf_2_2::FrameBuffer, const
Imf_2_2::FrameBuffer, const Box2i, bool): Assertion
`writtenHalf.bits()==readHalf.bits()' failed.
/bin/bash: line 5: 25131 Aborted ${dir}$tst
FAIL: IlmImfTest
==
1 of 1 test failed
==
[...]
This is a hard-failure based on an assert(). Is there an actual
issue in openexr 2.2.0 ?
It is noted in the comments for this issue:
https://github.com/openexr/openexr/issues/67 Per the latest comment
on the issue thread, the problem is in the test rather than in the
library itself. Sorry that it hasn't been addressed since the issue
was filed in 2013 -- it doesn't show up on the platforms we use
regularly build for, which are mainly 64-bit, or we would have
cleaned it up long ago.
Hello,
Pulling patch-IlmImfTest_testOptimizedInterleavePatterns.cpp from
FreeBSD lets the testsuite succeed on linux/i386.
@OpenEXR: FreeBSD is applying a couple of patches, it probably makes
sense to review each of these.
https://svnweb.freebsd.org/ports/head/graphics/OpenEXR/files/
extra-patch-IlmImfExamples__Makefile.in
patch-exrenvmap__main.cpp
patch-exrmaketiled__main.cpp
patch-IlmImf_ImfFastHuf.cpp
patch-IlmImf__ImfSystemSpecific.cpp
patch-IlmImf__Makefile.in
patch-IlmImfTest__main.cpp
patch-IlmImfTest_testOptimizedInterleavePatterns.cpp
patch-IlmImfUtil__Makefile.in
patch-IlmImfUtilTest_main.cpp
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--- IlmImfTest/testOptimizedInterleavePatterns.cpp.orig 2014-08-10 02:03:49 UTC
+++ IlmImfTest/testOptimizedInterleavePatterns.cpp
@@ -226,7 +226,8 @@ bool compare(const FrameBuffer asRead,
writtenHalf=half(i.slice().fillValue);
}
-if (writtenHalf.bits()!=readHalf.bits())
+if (writtenHalf.bits()!=readHalf.bits()
+ !(writtenHalf.isNan() readHalf.isNan()))
{
if (nonfatal)
{
@@ -235,7 +236,8 @@ bool compare(const FrameBuffer asRead,
else
{
cout \n\nerror reading back channel i.name() pixel x ',' y got readHalf expected writtenHalf endl;
-assert(writtenHalf.bits()==readHalf.bits());
+assert(writtenHalf.bits()==readHalf.bits() ||
+ (writtenHalf.isNan() readHalf.isNan()));
exit(1);
}
}
Bug#794430: [Cupt-devel] Bug#794430: Bug#794430: Bug#794430: cupt: Trying to install a uninstallable package, and not error is show
Hi! On 04.08.2015 17:22, Javier Barroso wrote: Yes, I'm attaching bt full (from cupt install sl) Many thanks, it revealed that certain data inconsistency happens which leads to a crash. I however still cannot reproduce it without more data. Would it be possible for you to send me (perhaps privately) the output of 'cupt tar-metadata | xz -c y.tar.xz' command? With some luck it might fit the mail attachment limits. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790975: fixed in afflib 3.7.6-4
Sorry. You are right. I looked at each dependant package and no need notify the maintainers. Upload to unstable, closing the bug. Regards, Eriberto 2015-08-09 15:43 GMT-03:00 Eriberto eribe...@eriberto.pro.br: Hum... I understand but I prefer notify the maintainers. Thanks Julien! Regards, Eriberto 2015-08-09 14:01 GMT-03:00 Julien Cristau jcris...@debian.org: On Sun, Aug 9, 2015 at 10:42:29 -0300, Eriberto wrote: Hi Julien, Ok. I will do it: 1. Upload to experimental, without close the bug. 2. Notify all maintainers of dependent packages, allowing changes up to next Saturday. 3. In next Saturday, upload to unstable, closing the bug. 4. Notify all maintainers that uploaded their packages to experimental. 5. File bugs (FTBFS) against all dependent packages not updated in experimental. Thanks a lot for your help. I don't think that delay is necessary, uploading to sid right away should be just fine, we'll rebuild reverse dependencies as needed. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794937: Applications crash with phonon-backend-vlc
Am 09.08.2015 um 02:27 schrieb Lisandro Damián Nicanor Pérez Meyer: tag 794937 moreinfo thanks Hi Michael! I have just uploaded a new version, can you check it works for you? (and yes, you might need to wait for the gcc5 transition to be in a more advanced state :-/ ) Upgraded phonon to 4:4.8.3-1, crash still happens with phonon-backend-vlc -- 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#786247: pyvtk: deprecation of python-support
On August 8, 2015 10:13:04 AM Piotr Ożarowski wrote: [Steve M. Robbins, 2015-08-08] I went looking for the most recent sources and found out that you can easily get pyvtk via pip. `sudo pip install ...` is the same as `rm -rf /` to me. I see. Please don't suggest it! In my defense: I did not say you need to use sudo. All you need (at least for pyvtk) is privilege to write into /usr/local, so it is more like rm -rf /usr/local ... still damaging but not as dramatic. :-) If you don't want to maintain it, report RFA or O bug or simply remove it from the archive, but never ever suggest users to use pip for installing system libs/apps. I had to clean after these tools way too many times! pip is great when used inside virtualenv or tools like this, but should return please use rpm/dpkg whenever invoked as root, period! Thanks. I had read Paul Tagliamonte's essay [1] and wondered whether I'd get this kind of response. :-) I won't wade into the debate. [1] http://notes.pault.ag/debian-python/ Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#794528: libmount1: fuse user option: can mount but not umount
Hello again. Forgot to mention that you might also want to test applying https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=41e554e303e63c7051fda5783af2462066c43e4d just in case it's any way related to your issue. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795019: RM: insighttoolkit -- ROM; Obsoleted by insighttoolkit4
Package: ftp.debian.org Severity: normal The package is already scheduled for autoremoval due to GCC 5 issues. But there is no need to wait: the code is several years old and will not be maintained. Successor package is insighttoolkit4. -Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773165: pciutils: new 3.3.0 upstream release
Hi, On Mon, 15 Dec 2014, Matt Taggart wrote: Package: pciutils Version: 3.2.1-3 Severity: wishlist Hi Anibal! pciutils 3.3.0 was released on 2014-11-10. Here's the changelog entry: Ping? Anibal, when do you plan to update pciutils? The currently shipped pci.ids is a bit old in Debian by now... Matt, you're also listed as Uploaders on this package. :) Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795025: systemd-udevd: Process '/lib/udev/hdparm' failed with exit code 5
Package: hdparm Version: 9.43-2 Severity: normal Message appears in systemd journal (journalctl) after startup. I think systemd-udevd processes '85-hdparm.rules' it runs '/lib/udev/hdparm', which produces the message. It's odd because previously the hdparm startup script (/etc/init.d/hdparm) runs and outputs 'Setting parameters of disc (none).' is no parameter blocks are in '/etc/hdparm.conf'. I am wondering why the udev/hdparm script is run at all, since it just parses hdparm.conf again and runs hdparm a second time. This bug was filed in ubuntu launchpad here: http://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1470014 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.0.8-1-inter01-686-pae (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hdparm depends on: ii libc6 2.19-19 ii lsb-base 4.1+Debian13+nmu1 Versions of packages hdparm recommends: ii powermgmt-base 1.31+nmu1 Versions of packages hdparm suggests: pn apmd 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#794913: libphonenumber6: please use libboost-date-time 1.57 or 1.58 ASAP
Control: severity -1 normal Control: retitle -1 libphonenumber6: please use libboost-date-time 1.57 or 1.58 Simon McVittie was so kind to disable libphonenumber6 in evolution for now and rebuild the package with that. So I guess the severity of this can be lowered again, as this doesn't block updating anymore :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#794806: jhead: jhead refuses to rename read-only files
Hello, Le 06/08/2015 21:08, Toby Speight a écrit : Package: jhead Version: 1:3.00-1 Severity: normal I have a writable directory containing some JPEG files that are non-writable for me. I want to rename them by their timestamps (but not to inadvertently change their content). But jhead -n refuses, saying Skipping readonly file. The -n option doesn't write the file at all, only the directory, and mv has no objections to that. But jhead doesn't check the directory's permissions in the same way, so it's completely inconsistent. I tried an experiment with a read-only directory containing writable files, and it tried to rename them, reporting the error: Error: Couldn't rename ... Instead of skipping readonly files, it makes sense to continue as normal until/unless a system call gives us a failure, then report it - like every other Unix utility. That's more reliable that doing access() checks, or whatever it is that jhead does. Great idea! Can you propose a patch? That would help a lot. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794727: mesg n exits with error, even if the command is successful
On Sun, Aug 09, 2015 at 03:58:27PM +0200, Andreas Henriksson wrote: Please note: 0 Messages are allowed. 1 Messages are not allowed. 1 An error has occurred. Small clarification: The error codes are not really the problem. The problem is that those error codes are in effect not only when mesg is invoked alone, but also when it's invoked with an argument: mesg y|n. For the case where an argument is used, we don't really want an error telling us the state after the mesg command, as in 99% of cases we already know the final state: It's given by the argument itself! I think it's very unlikely that util-linux wants to break their compatibility in favour of being compatible with the odd implementation previously used in Debian. Well. In this case, the only compatibility that will break is that those who write mesg n || true will finally be able to remove the || true part. Constructs like this: if mesg 2 /dev/null; then echo mesg is y else echo mesg is n fi would not be affected by the proposed behaviour change. If you feel like arguing your opinions on the upstream mailing list then please go ahead. (I think it's much better if you talk directly instead of passing discussion via me as a messenger.) Ok, If you think that's better, I will do. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794625: /sbin/hwclock: hwclock: not saves time to hardware clock during halt/reboot
Control: tags -1 + moreinfo Hello YK. Thanks for your bug report. On Wed, Aug 05, 2015 at 10:47:19AM +0600, YK wrote: Package: util-linux Version: 2.25.2-6 Severity: normal File: /sbin/hwclock Hello, Sorry my bad English. No problem. Subj Please explain what your actual problem is. What did you do? What happened? What did you expect to happen? Please feel free to fully fill out the template presented by reportbug. The hwclock program is not a daemon. Someone needs to invoke it. It needs to be invoked with the right set of arguments to get it to do what you want it to do. If you're using the current default init system in Debian, then hwclock is not used at all since systemd handles storing time internally. cf. $ systemctl cat hwclock # /dev/null If you're still running sysvinit, then /etc/init.d/hwclock.sh should invoke hwclock with the right set of arguments. There are way too many variables here for me to be able to guess what your problem is. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795016: libgee2: Package description unindented
Package: libgee2 Severity: minor Please fix the bullet list's indentation in the package's long description Or is it intentianally listed that way ? Description: GObject based collection library libgee is a collection library providing GObject-based interfaces and classes for commonly used data structures. . libgee provides the following interfaces: * Iterable * Collection * List * Set * Iterator * Map . The ArrayList, HashSet, and HashMap classes provide a reasonable sample implementation of the List, Set, and Map interfaces. ReadOnlyCollection, ReadOnlyList, ReadOnlySet, and ReadOnlyMap are read-only wrapper classes that prevent modification of the underlying collection. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.4+ (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795015: xfce4-volumed: Play sound when volume set with FN keys
Package: xfce4-volumed Version: 0.1.13-5 Severity: wishlist Dear Maintainer, * What led up to the situation? Setting the volume up * What exactly did you do (or not do) that was effective (or ineffective)? Use FN keys to increase/decrease volume * What was the outcome of this action? No sound * What outcome did you expect instead? A brief sound at the volume level -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-volumed depends on: ii gstreamer0.10-alsa [gstreamer0.10-audiosink] 0.10.36-2 ii gstreamer0.10-plugins-bad [gstreamer0.10-audiosink] 0.10.23-7.4 ii gstreamer0.10-plugins-good [gstreamer0.10-audiosink] 0.10.31-3+nmu4+b1 ii gstreamer0.10-pulseaudio [gstreamer0.10-audiosink]0.10.31-3+nmu4+b1 ii libc6 2.19-18 ii libglib2.0-0 2.42.1-1 ii libgstreamer-plugins-base0.10-0 0.10.36-2 ii libgstreamer0.10-00.10.36-1.5 ii libgtk2.0-0 2.24.25-3 ii libkeybinder0 0.3.0-3 ii libnotify40.7.6-2 ii libxfconf-0-2 4.10.0-3 xfce4-volumed recommends no packages. xfce4-volumed 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#791289: marked as done (snappy: library transition may be needed when GCC 5 is the default)
Control: reopen -1 On Sun, Aug 09, 2015 at 04:03:09PM +, Debian Bug Tracking System wrote: Closes: 791289 794993 Changes: snappy (1.1.3-2) unstable; urgency=medium . * Change package name to libsnappy1v5 for rebuild with g++-5.0 with the C++11 ABI; conflict with libsnappy1. (Closes: #791289, #794993) * Switch Debian packaging to the 3.0 (quilt) format. No, that does not complete this transition. The release team will close this bug at the correct time. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Bug#793401: cacti: loadavg_multi.pl is not returning values
Hi, Paul. Sorry for the delay in replying. On 31/07/15 12:17, Paul Gevers wrote: Locale information: # locale LC_ALL=es_AR.UTF-8 Why do you have LC_ALL set? That overrules all the other changes. I believe it is not meant to be set like that generally, only for overloading for specific cases. I may be wrong... I could confirm that with LC_ALL empty, the applied patch on #704057 works for me. I think this (having LC_ALL configured) is a legacy configuration I've used in a while and that has spread in every update of Debian stable I've done. Do you think this is not recommended? If so, why? I see you've closed the ticket. In what state has remained? Thanks for your time. Best regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795024: mate-desktop: everything gets doubled
On 08/09/2015 07:17 PM, richard jasmin wrote: everything gets doubled after logout of mate and there is no fix. What is everything and to what does doubling refer to in this context? You cannot drop to a vterm(getty) with fglrx installed. I don't think this is related to fglrx. Please test with the free radeon driver first. fglrx is infamous to be broken in many regards. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794727: mesg n exits with error, even if the command is successful
On 9 August 2015 at 18:19, Santiago Vila sanv...@unex.es wrote: On Sun, Aug 09, 2015 at 07:14:30PM +0200, Reuti wrote: The profile is usually sourced. How does the error show up at the login prompt on Debian? The problem only happens in Debian testing and unstable, which I am not using yet. This is the original report which I received against base-files: https://bugs.debian.org/794727 Please notice the mesg(1) exit behavior is defined in POSIX http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mesg.html Unfortunately the standard does not appear to be explicit whether the exit value should be set only when requesting write permissions (running without arguments), or if also when setting the permissions. IMHO the reasonable thing to do is to leave the return codes as they are to avoid breakage in existing usage. If someone needs messaging setting not to report exit codes then this functionality is safest to introduce with new option, such as --no-exit-code-status -- Sami Kerola http://www.iki.fi/kerolasa/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794644: xorg-server: FTBFS on hurd-i386
Svante Signell, le Wed 05 Aug 2015 12:12:58 +0200, a écrit : Source: xorg-server Version: 1.17.2-1 Severity: important As additional information, it's particularly important because the version currently available on hurd-i386 (2:1.17.1-2) misses the fix 0a78b599b34cc8b5fe6fe82f90e90234e8ab7a56, thus breaking the vesa driver. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791191: log4cpp: diff for NMU version 1.0-4.1
Control: tag -1 patch pending
Dear maintainer,
I've prepared an NMU for log4cpp (versioned as 1.0-4.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
diff -u log4cpp-1.0/debian/changelog log4cpp-1.0/debian/changelog
--- log4cpp-1.0/debian/changelog
+++ log4cpp-1.0/debian/changelog
@@ -1,3 +1,11 @@
+log4cpp (1.0-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename library packages for g++ 5 transition, patch
+from Ubuntu (see #791191)
+
+ -- Jonathan Wiltshire j...@debian.org Sun, 09 Aug 2015 19:34:17 +0100
+
log4cpp (1.0-4) unstable; urgency=low
* Add patch to fix FTBFS with gcc 4.3. Thanks to Barry deFreeze.
diff -u log4cpp-1.0/debian/control log4cpp-1.0/debian/control
--- log4cpp-1.0/debian/control
+++ log4cpp-1.0/debian/control
@@ -9,7 +9,7 @@
Package: liblog4cpp5-dev
Section: libdevel
Architecture: any
-Depends: liblog4cpp5 (= ${binary:Version})
+Depends: liblog4cpp5v5 (= ${binary:Version})
Conflicts: liblog4cpp4-dev, liblog4cpp3-dev, liblog4cpp1-dev, liblog4cpp-dev
Replaces: liblog4cpp4-dev, liblog4cpp3-dev, liblog4cpp1-dev, liblog4cpp-dev
Description: C++ library for flexible logging (development)
@@ -20,12 +20,12 @@
.
This package contains the log4cpp development files.
-Package: liblog4cpp5
+Package: liblog4cpp5v5
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: liblog4cpp4, liblog4cpp3, liblog4cpp1c102
-Replaces: liblog4cpp4, liblog4cpp3, liblog4cpp0, liblog4cpp1c102
+Conflicts: liblog4cpp4, liblog4cpp3, liblog4cpp1c102, liblog4cpp5
+Replaces: liblog4cpp4, liblog4cpp3, liblog4cpp0, liblog4cpp1c102, liblog4cpp5
Description: C++ library for flexible logging (runtime)
Log for C++ is a library of C++ classes for flexible logging to files,
syslog and other destinations. It is modeled after the Log for
reverted:
--- log4cpp-1.0/debian/liblog4cpp5.install
+++ log4cpp-1.0.orig/debian/liblog4cpp5.install
@@ -1 +0,0 @@
-usr/lib/lib*.so.*
diff -u log4cpp-1.0/debian/rules log4cpp-1.0/debian/rules
--- log4cpp-1.0/debian/rules
+++ log4cpp-1.0/debian/rules
@@ -8,7 +8,7 @@
DEB_CONFIGURE_SCRIPT_ENV += LDFLAGS=-Wl,-z,defs -Wl,--as-needed -lpthread
DEB_DH_INSTALL_SOURCEDIR := debian/tmp
-configure/liblog4cpp5::
+configure/liblog4cpp5v5::
aclocal -I m4
autoconf
autoheader
only in patch2:
unchanged:
--- log4cpp-1.0.orig/debian/liblog4cpp5v5.install
+++ log4cpp-1.0/debian/liblog4cpp5v5.install
@@ -0,0 +1 @@
+usr/lib/lib*.so.*
signature.asc
Description: Digital signature
Bug#793991: [Pkg-pascal-devel] Bug#793991: lazarus: armel and armhf builds stall
Hi All, On Fri, 2015-07-31 at 12:07 +0200, Graham Inggs wrote: I tried a simpler package, ddrescueview [1], and instead of building the Debian package, I simply ran: lazbuild source/ddrescueview.lpi --bm=GNU/Linux Release As before, the build appeared to stall, and after hitting ctrl-c I noticed that in the background the build had actually completed successfully and there was a working 'ddrescueview' executable. I'll file a bug upstream. I tried this on porterbox abel and reproduced the issue. However I failed to completely understand it. It looks like it hangs when running ld.bfd. Indeed when pressing ctrl+z I got: (sid_armel-dchroot)abou@abel:~/ddrescueview-0.4~alpha2/source$ ps -elf | grep ddrescueview 0 T abou32221 27954 0 80 0 - 5412 signal 18:25 pts/100:00:00 lazbuild ddrescueview.lpi 0 T abou32232 32221 0 80 0 - 178 signal 18:25 pts/100:00:00 /usr/bin/fpc -B -MObjFPC -Schi -CX -Cirot -g -gl -XX -l -vewnhibq -Fl/opt/gnome/lib -Fu/usr/lib/lazarus/1.4.0/lcl/units/arm-linux/gtk2 -Fu/usr/lib/lazarus/1.4.0/lcl/units/arm-linux -Fu/usr/lib/lazarus/1.4.0/components/lazutils/lib/arm-linux -Fu/usr/lib/lazarus/1.4.0/packager/units/arm-linux -Fu/home/abou/ddrescueview-0.4~alpha2/source/ -dLCL -dLCLgtk2 ddrescueview.lpr 0 T abou32233 32232 4 80 0 - 4031 signal 18:25 pts/100:00:03 /usr/bin/ppcarm -B -MObjFPC -Schi -CX -Cirot -g -gl -XX -l -vewnhibq -Fl/opt/gnome/lib -Fu/usr/lib/lazarus/1.4.0/lcl/units/arm-linux/gtk2 -Fu/usr/lib/lazarus/1.4.0/lcl/units/arm-linux -Fu/usr/lib/lazarus/1.4.0/components/lazutils/lib/arm-linux -Fu/usr/lib/lazarus/1.4.0/packager/units/arm-linux -Fu/home/abou/ddrescueview-0.4~alpha2/source/ -dLCL -dLCLgtk2 ddrescueview.lpr 0 T abou32243 32233 5 80 0 - 17728 signal 18:25 pts/100:00:03 /usr/bin/ld.bfd --dynamic-linker=/lib/ld-linux.so.3 --gc-sections -L. -o ddrescueview link.res 0 S abou32249 27954 0 80 0 - 637 pipe_w 18:26 pts/100:00:00 grep ddrescueview when fg and then ctrl+c it seems to resume. I also recompiled lazbuild to get debug symbols, but then I do not have the issue anymore. I even stripped the newly build binary and did not have the issue. So maybe we need just to rebuild again? -- Cheers, Abou Al Montacir -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: Fwd: Fwd: Re: multiarch = same and different date-entries in generated man page of i32/i64
Hmm, good point, David. Because I'm also upstream this would easily be possible. It had to stay in sync then to the application/api behavior, which is, however, only a matter of discipline. Maybe I can use some familiar tool like LaTeX for writing. Thanks for the impulse, I hadn't considered it before :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793543: xserver-xorg segmentation fault at startup on testing
Hello, Matthias, could you send the output of lspci -vv Thanks, Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794727: mesg n exits with error, even if the command is successful
On Sun, Aug 09, 2015 at 06:58:15PM +0100, Sami Kerola wrote: On 9 August 2015 at 18:19, Santiago Vila sanv...@unex.es wrote: On Sun, Aug 09, 2015 at 07:14:30PM +0200, Reuti wrote: The profile is usually sourced. How does the error show up at the login prompt on Debian? The problem only happens in Debian testing and unstable, which I am not using yet. This is the original report which I received against base-files: https://bugs.debian.org/794727 Please notice the mesg(1) exit behavior is defined in POSIX http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mesg.html Unfortunately the standard does not appear to be explicit whether the exit value should be set only when requesting write permissions (running without arguments), or if also when setting the permissions. So if the standard is not explicit about this, there is some room for interpretation. Would not be possible to interpret the standard in a sensible way? Moreover: Would not be possible to ask for the standard to be clarified? IMHO the reasonable thing to do is to leave the return codes as they are to avoid breakage in existing usage. If someone needs messaging setting not to report exit codes [...] Hmm, but who does really need message *setting* to report exit codes? They make more harm than help. As explained before, if I do mesg y I can reasonably think that messages will be enabled after that, and if I do mesg n I can reasonably think that messages will be disabled after that. I don't need an exit code for that, unless I don't trust the program to do its job, and this is why I think there is no need to interpret the standard so strictly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794983: vlc does weird things with the .lock file
Le samedi 8 août 2015, 20:30:32 sacrificial-spam-addr...@horizon.com a écrit : Package: vlc Version: 2.2.1-2+b2 Architecture: i386 Severity: minor Somehow (it may have been a transient error caused by C++ ABI upgrades), I ended up with: $ ls ~/.config/vlc/ vlc-qt-interface.conf vlc-qt-interface.conf.lock vlc-qt-interface.conf.lock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock ... vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock. rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock .rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmloc k.rmlock.rmlock.rmlock and ended up with vlc stuck looping retrying VLC is not accessing the file directly, and definitely not taking care of locking for it. It is the back-end to Qt's QSettings class. This should probably be reassigned... -- Rémi Denis-Courmont http://www.remlab.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711332: RM: w3c-dtd-xhtml -- RoQA; superseded by w3c-sgml-lib
Control: tag -1 - jessie Control: clone -1 -2 Control: tag -2 - moreinfo Control: reassign -2 w3c-dtd-xhtml 1.2-4 Control: retitle -2 w3c-dtd-xhtml: should not be released with stretch - superseded by w3c-sgml-lib Control: severity -2 serious With wdg-html-validator not being trivially fixable (#787178), we should at least ensure w3c-dtd-xhtml gets (auto-)removed from stretch. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758990: DPI issue
❦ 8 août 2015 12:24 +0200, Daniel Pocock dan...@pocock.pro : Did you find a solution or did anybody reply to you about this bug? I observe similar problems trying to use a 4K UHD monitor that has 131 x 137 DPI X will lie about the screen dimensions. Only xrandr will report the appropriate dimensions. What does xrandr says? -- And do you think (fop that I am) that I could be the Scarlet Pumpernickel? signature.asc Description: PGP signature
Bug#794468: general: no watchdog support in installer kernel
Ben Hutchings dixit: Which watchdog device is this, that is enabled by the BIOS? Normally I expect them to be enabled only by the kernel driver. It’s a 19″ server from Supermicro; Dominik would’ve to provide details. install time since the watchdog devices are not enabled by the system firmware. Oh well… apparently, the firmware setup screens don’t signal the watchdog either, so you can’t use that one for five minutes while the watchdog is enabled. This all points to buggy firmware. Again, details would have to come from Nik. bye, //mirabilos -- Thorsten Glaser Teckids e.V. – Erkunden, Entdecken, Erfinden. https://www.teckids.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795018: [oinkmaster] oinkmaster fails to disable SID 2240001
Package: oinkmaster Version: 2.0-4 Severity: normal suricata on my firewall machine (uptodate Debian Testing) continues to spam the syslog with 2240001 events even though oinkmaster is explicitly told to disable them via: = disablesid 2240001 # SURICATA DNS Unsollicited response = My understanding is with 'oinkmaster -o /etc/suricata/rules', oinkmaster downloads the Emerging Threats rules (http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz), unpacks, and outputs into '/etc/suricata/rules' commenting out any SIDs it has been told to disable. Its clearly not commenting out the 'DNS Unsollicited response' rule (top one) in 'dns-events.rules' here, when I do it manually a further oinkmaster run detects no change. I've just installed suricata/oinkmaster in a VM, configured the Emerging Threats source and set the single relevant disable SID line, it still fails to do its job (config attached). # $Id: oinkmaster.conf,v 1.134 2008/02/18 19:33:45 andreas_o Exp $ # # This file is pretty big by default, but don't worry. # Everything in here is completely optional and the defaults # should work for most people. The download URL of the rules # archive must be set either in here or on the command line. # Remember not to let untrusted users edit Oinkmaster configuration # files, as things like the PATH to use during execution is defined # in here. # Use url = url to specify the location of the rules archive to # download. The url must begin with http://, https://, ftp://, file:// # or scp:// and end with .tar.gz or .tgz, and the file must be a # gzipped tarball what contains a directory named rules. # You can also point to a local directory with dir://directory. # Multiple url = url lines can be specified to grab multiple rules # archives from different locations. # # Note: if URL is specified on the command line, it overrides all # possible URLs specified in the configuration file(s). # # The location of the official Snort rules you should use depends # on which Snort version you run. Basically, you should go to # http://www.snort.org/rules/ and follow the instructions # there to pick the right URL for your version of Snort # (and remember to update the URL when upgrading Snort in the # future!). You can of course also specify locations to third party # rules. You may specify multiple URLs. # # As of March 2005, you must register on the Snort site to get access # to the official Snort rules. This will get you an oinkcode. # You then specify the URL as # http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/filename # For example, if your code is 5a081649c06a277e1022e1284b and # you use Snort 2.7, the url to use would be: # http://www.snort.org/pub-bin/oinkmaster.cgi/5a081649c06a277e1022e1284bdc8fabda70e2a4/snortrules-snapshot-2.7.tar.gz # See the Oinkmaster FAQ Q1 and http://www.snort.org/rules/ for # more information. # Emerging Threats suricata rules url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz # URL examples follows. Replace oinkcode with the code you get on the # Snort site in your registered user profile. # VRT certified rules for registered users, Snort 2.9. # url = http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/snortrules-snapshot-2.9.tar.gz # VRT certified rules for registered users, Snort 2.7. # url = http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/snortrules-snapshot-2.7.tar.gz # VRT certified rules for registered users, Snort 2.8. # url = http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/snortrules-snapshot-2.8.tar.gz # VRT certified rules for registered users, Snort-CURRENT # (CURRENT here means experimental snapshots!). # url = http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/snortrules-snapshot-CURRENT.tar.gz # Community rules and Snort 2.4. # url = http://www.snort.org/pub-bin/downloads.cgi/Download/comm_rules/Community-Rules-2.4.tar.gz # Community rules for snort-CURRENT # url = http://www.snort.org/pub-bin/downloads.cgi/Download/comm_rules/Community-Rules-CURRENT.tar.gz # Example for rules from the Emerging Threats site (previously known as Bleeding Snort). # url = http://www.emergingthreats.net/rules/emerging.rules.tar.gz # Old url: # url = http://www.bleedingsnort.com/downloads/bleeding.rules.tar.gz # If you prefer to download the rules archive from outside Oinkmaster, # you can then point to the file on your local filesystem by using # file://filename, for example: # url = file:///tmp/snortrules.tar.gz # In rare cases you may want to grab the rules directly from a # local directory (don't confuse this with the output directory). # url = dir:///etc/snort/src/rules # Example to use scp to copy the rules archive from another host. # Only OpenSSH is tested. See the FAQ for more information. # url = scp://u...@somehost.example.com:/somedir/snortrules.tar.gz # If you use -u
Bug#794909: colpack: diff for NMU version 1.0.9-3.2
Control: tags 794909 + patch pending
Dear maintainer,
I've prepared an NMU for colpack (versioned as 1.0.9-3.2). The diff
is attached to this message; sorry about the breakage.
Regards.
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
diff -Nru colpack-1.0.9/debian/changelog colpack-1.0.9/debian/changelog
--- colpack-1.0.9/debian/changelog 2015-08-04 17:56:21.0 +0100
+++ colpack-1.0.9/debian/changelog 2015-08-09 17:51:38.0 +0100
@@ -1,3 +1,10 @@
+colpack (1.0.9-3.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add conflicts/replaces libcolpack0 (closes: #794909)
+
+ -- Jonathan Wiltshire j...@debian.org Sun, 09 Aug 2015 17:51:36 +0100
+
colpack (1.0.9-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru colpack-1.0.9/debian/control colpack-1.0.9/debian/control
--- colpack-1.0.9/debian/control 2015-08-04 17:55:09.0 +0100
+++ colpack-1.0.9/debian/control 2015-08-09 17:52:05.0 +0100
@@ -32,6 +32,8 @@
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libcolpack0
+Replaces: libcolpack0
Description: Specialized graph vertex coloring library, shared library
ColPack is a package comprising of implementation of algorithms for
specialized vertex coloring problems that arise in sparse derivative
signature.asc
Description: Digital signature
Bug#794727: mesg n exits with error, even if the command is successful
On Sun, Aug 09, 2015 at 07:14:30PM +0200, Reuti wrote: The profile is usually sourced. How does the error show up at the login prompt on Debian? The problem only happens in Debian testing and unstable, which I am not using yet. This is the original report which I received against base-files: https://bugs.debian.org/794727 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787178: wdg-html-validator: Remove w3c-dtd-xhtml reference from d/control
On Fri, 29 May 2015 14:04:28 +0200 Mathieu Malaterre ma...@debian.org wrote: Please remove reference to w3c-dtd-xhtml from debian/control. This package will be removed for stretch (see #711332), it has been superseded by w3c-sgml-lib. I just had a look again at wdg-html-validator, this time for real :-) The validate and cgi-bin/validate.pl scripts (perhaps even more bits) hardcode paths to /etc/sgml/sgml-data.cat, /etc/sgml/w3c-dtd-xhtml.cat as well as many .dcl/.decl files provided by the w3c-dtd-xhtml and sgml-data packages. These locations are already patched in the Debian package since upstream assumes a different layout. w3c-sgml-lib ships files with (hopefully) the same functionality but in different locations and named differently. The proper way to locate the needed files is probably via /etc/sgml/catalog and not hardcoding them ... that might even add support for new standards automatically. At least for the validate script a new upstream release is available (1.2.3 from 2011 vs 1.2.2 in the package). That's too much work for a quick QA upload. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794895: chromium: Segmentation fault for some website
Hi, On Sat, Aug 08, 2015 at 07:01:35PM -0400, Michael Gilbert wrote: control: tag -1 unreproducible, moreinfo control: severity -1 minor The current release crashes regularly. For example the following link reproducibly crashes the browser: ftp://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-monitor.html I'm not able to reproduce this with a clean install (i.e. no plugins, apps, or extensions). Have you tried disabling or removing the flash plugin, other apps, and extensions? Actually I didn't. It seems the crash only happens with this extension being enabled: https://github.com/henices/Chrome-proxy-helper ( https://chrome.google.com/webstore/detail/proxy-helper/mnloefcpaepkpmhaoipjkpikbnkmbnic ) -- Sebastian signature.asc Description: Digital signature
Bug#795011: virtualenv does not work with a path containing special characters
Package: virtualenv Version: 1.11.6+ds-1 Severity: normal Hello, virtualenv does not work when the path contains special characters: Running virtualenv with interpreter /usr/bin/python2 New python executable in venv/bin/python2 Not overwriting existing python script venv/bin/python (you must use venv/bin/python2) Traceback (most recent call last): File string, line 1, in module UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 14: ordinal not in range(128) ERROR: The executable venv/bin/python2 is not functioning ERROR: It thinks sys.prefix is u'/home/pierre/T\xe9l\xe9chargements/letsencrypt' (should be u'/home/pierre/T\xe9l\xe9chargements/letsencrypt/venv') ERROR: virtualenv is not compatible with this system or executable It does work correctly with a path containing only ascii characters. Regards, -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages virtualenv depends on: ii python3 3.4.2-2 ii python3-virtualenv 1.11.6+ds-1 virtualenv recommends no packages. virtualenv 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#794983: vlc does weird things with the .lock file
Control: reassign -1 libqt5core5a 5.4.2+dfsg-5 On 2015-08-09 15:46:00, Rémi Denis-Courmont wrote: Le samedi 8 août 2015, 20:30:32 sacrificial-spam-addr...@horizon.com a écrit : Package: vlc Version: 2.2.1-2+b2 Architecture: i386 Severity: minor Somehow (it may have been a transient error caused by C++ ABI upgrades), I ended up with: $ ls ~/.config/vlc/ vlc-qt-interface.conf vlc-qt-interface.conf.lock vlc-qt-interface.conf.lock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock ... vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock. rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock .rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmloc k.rmlock.rmlock.rmlock and ended up with vlc stuck looping retrying VLC is not accessing the file directly, and definitely not taking care of locking for it. It is the back-end to Qt's QSettings class. This should probably be reassigned... So let's reassign it. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#794727: mesg n exits with error, even if the command is successful
Hello. [ Apologies if this is a FAQ ]. Debian has recently switched the mesg implementation from the one in sysvinit to the one in util-linux. We have found a subtle issue: The old mesg didn't have any error codes at all. The new mesg (from util-linux) has the following error codes: 0 Messages are allowed. 1 Messages are not allowed. 1 An error has occurred. The problem is that those error codes are in effect not only when the mesg command is invoked alone: mesg but also when it's used with an argument: mesg y mesg n This breaks the default /root/.profile which has a simple mesg n at the end, so we will probably have to hide the error like this: mesg n || true but this is a little bit weird and I wonder how much people will have to do this as well. In Unix, usually, whenever I tell a command to do something, there is only an error when the command is not able to do what I ask it to do. In this case, however, the mesg n is succesful, as it is actually able to disable write to the terminal, and yet it exits with an error. I think this does not make much sense and would humbly propose that the behaviour is changed so that error codes are only used when the mesg is used alone, without any arguments. Surely that a change like this might in theory break some scripts, but let's see what kind of breakage we could expect: * People who write this: mesg y will not need to change anything. * People who write this: mesg n || true will finally be able to remove the || true part. If they don't remove the || true part, nothing really bad will happen. In fact, this could even improve things a little bit, as mesg alone will fail if the mesg does not exist. * People writing things like this: if mesg 2 /dev/null; then echo mesg is y else echo mesg is n fi which is where exit codes are actually useful, will not be affected at all. Of course one can always create a complex use case where a change in exit codes would break the script, but I think those would be a very small minority. So: Would you please consider a change in mesg behaviour regarding exit codes, so that mesg n does not gratuitously fail? Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
