Bug#831886: firefox-esr: crashes with __libc_res_nquery: Assertion (hp != ((void *)0)) && (hp2 != ((void *)0))' failed.
control: forcemerge 816669 831886 On 2016-07-21 06:13, Mike Hommey wrote: > reassign 831886 libc6 > thanks > > On Wed, Jul 20, 2016 at 03:18:13PM +0200, Dominik George wrote: > > Package: firefox-esr > > Version: 45.2.0esr-1~deb8u1 > > Severity: normal > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Firefox ESR crashes upon loading some website: > > > > nik@50-e5-49-5b-f2-5d ~ % LC_ALL=C firefox > > :( > > (process:12202): GLib-CRITICAL **: g_path_get_basename: assertion > > 'file_name != NULL' failed > > firefox-esr: res_query.c:262: __libc_res_nquery: Assertion (hp != ((void > > *)0)) && (hp2 != ((void *)0))' failed. > > This is an assertion in glibc. > This is a regression introduced with fix from CVE-2015-7547. It has been fixed in stretch/sid already. For jessie, it has been fixed in version 2.19-18+deb8u5, which is currently in jessie-proposed-updates and will be released with the next jessie point release. Merging the bug with the existing one. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#831994: RFS: python-prompt-toolkit/1.0.3-1 (ITP)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-prompt-toolkit" * Package name: python-prompt-toolkit Version : 1.0.3-1 Upstream Author : Jonathan Slenders * URL : https://github.com/jonathanslenders/python-prompt-toolkit * License : BSD-3-clause Section : python It builds those binary packages: python-prompt-toolkit - Library to build powerful interactive command lines in Python 2 python3-prompt-toolkit - Library to build powerful interactive command lines in Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-prompt-toolkit Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-prompt-toolkit/python-prompt-toolkit_1.0.3-1.dsc It is packaged within the Debian Python Modules Team: Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/python-prompt-toolkit.git Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/python-prompt-toolkit.git Cheers, Snark on #debian-python
Bug#831993: libcommons-codec-java: accesses the internet during build
Source: libcommons-codec-java Version: 1.10-1 Severity: serious Justification: Policy 4.9 User: la...@debian.org Usertags: network-access Dear Maintainer, Whilst libcommons-codec-java builds successfully on unstable/amd64, according to Debian Policy 4.9 packages may not attempt network access during a build. 00:00:00.00 IP 927730abfc42.59882 > 192.168.43.1.domain: 28043+ A? download.oracle.com. (37) 00:00:00.57 IP 927730abfc42.59882 > 192.168.43.1.domain: 58907+ ? download.oracle.com. (37) 00:00:00.367740 IP 192.168.43.1.domain > 927730abfc42.59882: 28043 4/0/1 CNAME download.oracle.com.edgesuite.net., CNAME a1961.d.akamai.net., A 2.21.71.90, A 2.21.71.80 (156) 00:00:00.372237 IP 192.168.43.1.domain > 927730abfc42.59882: 58907 2/1/1 CNAME download.oracle.com.edgesuite.net., CNAME a1961.d.akamai.net. (182) 00:00:00.375308 IP 927730abfc42.58862 > 2.21.71.90.http: Flags [S], seq 807871607, win 29200, options [mss 1460,sackOK,TS val 5743965 ecr 0,nop,wscale 7], length 0 00:00:00.415639 IP 2.21.71.90.http > 927730abfc42.58862: Flags [S.], seq 1375254780, ack 807871608, win 13080, options [mss 1320,sackOK,TS val 3348374771 ecr 5743965,nop,wscale 9], length 0 [..] The full build log (including tcpdump output) is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- libcommons-codec-java.1.10-1.unstable.amd64.log.txt.gz Description: Binary data
Bug#831678: Fw: gtk2-engines-murrine: Text shadow misaligned for desktop icons on XFCE
On mer., 2016-07-20 at 20:34 -0700, James Lu wrote: > Hi everyone, forwarding this to pkg-xfce-devel so they're in the loop. Thanks (although “they” are the same people as the murrine maintainers :) -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#831995: ITP: parsnp -- rapid core genome multi-alignment
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: parsnp Version : 1.2 Upstream Author : Todd J Treangen * URL : https://github.com/marbl/parsnp * License : BSD Programming Lang: C, Python Description : rapid core genome multi-alignment Parsnp was designed to align the core genome of hundreds to thousands of bacterial genomes within a few minutes to few hours. Input can be both draft assemblies and finished genomes, and output includes variant (SNP) calls, core genome phylogeny and multi-alignments. Parsnp leverages contextual information provided by multi-alignments surrounding SNP sites for filtration/cleaning, in addition to existing tools for recombination detection/filtration and phylogenetic reconstruction. Remark: This package is maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/parsnp.git
Bug#831900: [Pkg-zsh-devel] Bug#831900: zsh-common: schroot completion misses -r flag
Control: tags -1 fixed-upstream Felipe Sateler wrote on Wed, Jul 20, 2016 at 12:49:56 -0400: > The schroot completion is missing the -r --run-session flag. The > following diff adds this: Thanks, applied upstream in workers/38901 (02f03a6aed73).
Bug#831899: kaddressbook crashes immediately on start
Control: tag -1 upstream Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=358696 ¡Hola Volker! El 2016-07-20 a las 18:46 +0200, Volker Groll escribió: Package: kaddressbook Version: 4:16.04.3-1 Severity: normal Wenn starting in a terminal kaddressbook, I get the following output: org.kde.akonadi.ETM: GEN true false true org.kde.akonadi.ETM: collection: QVector() KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kaddressbook path = /usr/bin pid = 10837 KCrash: Arguments: /usr/bin/kaddressbook KCrash: Attempting to start /usr/lib/i386-linux-gnu/libexec/drkonqi from kdeinit sock_file=/run/user/1000/kdeinit5__0 [1]+ Angehalten LANG=C kaddressbook Fetch to the foreground gives the output: LANG=C kaddressbook QSocketNotifier: Invalid socket 16 and type 'Read', disabling... QSocketNotifier: Invalid socket 11 and type 'Read', disabling... QSocketNotifier: Invalid socket 14 and type 'Read', disabling... QSocketNotifier: Invalid socket 9 and type 'Read', disabling... QSocketNotifier: Invalid socket 19 and type 'Read', disabling... QSocketNotifier: Invalid socket 17 and type 'Read', disabling... QSocketNotifier: Invalid socket 25 and type 'Read', disabling... QSocketNotifier: Invalid socket 27 and type 'Read', disabling... The I can dismiss the bug report window from kde. It seems to me that the bug is the same as: https://bugs.kde.org/show_bug.cgi?id=358696 Could you please provide additional information in the bug upstream? Currently it seems to require confirmation that this bug is only reproduceable in 32 bits systems. Also, a full backtrace would be useful, for that you would need to install the kaddressbook-dbgsym package (and probably the dbg/dbgsym packages from a couple of kaddressbook dependencies) from the debug archive (that needs to be added in the sources.list as: deb http://deb.debian.org/debian-debug unstable-debug main) Happy hacking, -- “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are–by definition–not smart enough to debug it.” -- Brian Kernighan Saludos /\/\ /\ >< `/ signature.asc Description: Digital signature
Bug#800890: [Pkg-xfce-devel] Bug#800890: xfce4-power-manager: If set to suspend on lid close when on battery, suspends on the event when on power cord, too.
On dim., 2015-10-04 at 19:25 +0300, Alexander Prokoshev wrote: > after an update the software changed its behavior. Hi, can you identify the update? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#831997: liferea-add-feed crashes reliably
Package: liferea Version: 1.10.19-2 Severity: normal Hi, I can reproducibly crash liferea-add-feed (not being able to add any feeds) via: $ liferea-add-feed http://googleresearch.blogspot.com/atom.xml Segmentation fault (core dumped). The backtrace is: #0 0x7fb7dca3a651 in g_application_impl_open (impl=0x0, files=, n_files=, hint=0x45f7f5 "feed-add", platform_data=0x23a1f30) at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gio/gapplicationimpl-dbus.c:631 631 /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gio/gapplicationimpl-dbus.c: No such file or directory. [Current thread is 1 (Thread 0x7fb7e1b95ac0 (LWP 5652))] (gdb) bt #0 0x7fb7dca3a651 in g_application_impl_open (impl=0x0, files=, n_files=, hint=0x45f7f5 "feed-add", platform_data=0x23a1f30) at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gio/gapplicationimpl-dbus.c:631 #1 0x0041b44d in main () Cheers, -- Guido -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-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) Versions of packages liferea depends on: ii dbus-x11 1.10.8-1 ii dconf-gsettings-backend [gsettings-backend] 0.26.0-1 ii gir1.2-gtk-3.0 3.20.6-2 ii gir1.2-peas-1.0 1.18.0-3 ii libatk1.0-0 2.20.0-1 ii libc62.23-1 ii libcairo21.14.6-1+b1 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libgirepository-1.0-11.48.0-3 ii libglib2.0-0 2.48.1-2 ii libgtk-3-0 3.20.6-2 ii libindicate5 0.6.92-3 ii libjson-glib-1.0-0 1.2.0-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.40.1-1 ii libpeas-1.0-01.18.0-3 ii libpeas-1.0-python2loader1.18.0-3 ii libsoup2.4-1 2.54.1-1 ii libsqlite3-0 3.13.0-1 ii libwebkitgtk-3.0-0 2.4.11-2 ii libxml2 2.9.3+dfsg1-1.2 ii libxslt1.1 1.1.28-4 ii liferea-data 1.10.19-2 ii python-gi3.20.1-1 pn python:any Versions of packages liferea recommends: ii gir1.2-gnomekeyring-1.0 3.12.0-1+b1 ii gnome-icon-theme 3.12.0-2 ii gnome-keyring3.20.0-1 Versions of packages liferea suggests: pn kget ii network-manager 1.2.2-2 -- no debconf information
Bug#830979: Bug#831984: zoneminder: modifies shipped file: /usr/share/zoneminder/www/api/app/Config/core.php
> Well, you don't edit shipped files. Neither conffiles nor normal files.
> Instead, you put these values into a new file (not a shipped file!,
> maybe ship a template in /usr/share/$pkg) in either /etc or /var (with a
> symlink in /usr pointing to it) that is solely managed by the maintainer
> scripts.
Something like the attached patch? (Untested)
> * upon initial installation only?
Yes, as otherwise you're invalidating all user sessions (or even all
passwords!)
> > I guess you guys can have an interesting discussion about clash between
> > #830979 and #831984.
This seems an odd.attitude to have as the maintainer.. :)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/debian/rules b/debian/rules
index f4a187f..f7a120c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,8 @@ ifeq ($(DEB_BUILD_ARCH_OS),hurd)
ARGS:= -DZM_NO_MMAP=ON
endif
+CORE_PHP =
$(CURDIR)/debian/tmp/usr/share/zoneminder/www/api/app/Config/core.php
+
%:
dh $@ --parallel --buildsystem=cmake --builddirectory=dbuild \
--with systemd,sphinxdoc,apache2,linktree
@@ -64,6 +66,10 @@ override_dh_auto_install:
dh_auto_install --arch --destdir=$(CURDIR)/debian/tmp
# remove empty directories:
-find $(CURDIR)/debian/tmp/usr -mindepth 1 -type d -empty -delete
-printf 'removed %p\n'
+
+ # Don't ship core.php as it contains pre-generated/static salts. We
+ # keep core.php.default as a template for the postinst.
+ rm -f $(CORE_PHP)
override_dh_install:
dh_install -XLICENSE -XLICENSE.txt -X.gitignore
diff --git a/debian/zoneminder.postinst b/debian/zoneminder.postinst
index b50b38a..ec33890 100644
--- a/debian/zoneminder.postinst
+++ b/debian/zoneminder.postinst
@@ -2,6 +2,9 @@
set -e
+TARGET="/etc/zm/core.php"
+SOURCE="/usr/share/zoneminder/www/api/app/Config/core.php.default"
+
Generate_random () {
tr -dc $1 < /dev/urandom | head -c $2
}
@@ -13,10 +16,13 @@ if [ "$1" = "configure" ]; then
chown www-data:www-data -R /var/cache/zoneminder
fi
- sed -i \
- -e "s@__ZM_API_SALT__@$(Generate_random A-Za-z0-9
29)@g" \
- -e "s@__ZM_API_SEED__@$(Generate_random 0-9 40)@g" \
- /usr/share/zoneminder/www/api/app/Config/core.php
+ if [ ! -e "${TARGET}" ]
+ then
+ sed \
+ -e "s@__ZM_API_SALT__@$(Generate_random
A-Za-z0-9 29)@g" \
+ -e "s@__ZM_API_SEED__@$(Generate_random 0-9
40)@g" \
+ ${SOURCE} > ${TARGET}
+ fi
fi
#DEBHELPER#
Bug#831918: bumping severity to serious
severity 831918 serious severity 831921 serious severity 831933 serious severity 831944 serious severity 831945 serious severity 831950 serious severity 831960 serious severity 831961 serious severity 831963 serious thanks Actually, after discussion on #830997, those bugs should really be severity:serious as they are about a missing build-indep target in debian/rules, which has been mandatory for some time. Lucas
Bug#830483: Fwd: [nat-users] Fwd: Bug#830483: natbraille: Please consider moving to Saxon-HE
[Forwarding this to BTS]
-- Forwarded message --
From: Vivien Guillet
Date: Thu, Jul 14, 2016 at 11:01 AM
Subject: Re: [nat-users] Fwd: Bug#830483: natbraille: Please consider
moving to Saxon-HE
To: Bruno Mascret , Samuel Thibault
, debian-accessibil...@lists.debian.org,
eug...@debian.org, Djidjo - Trio Led Crush
Hi
This is a known (and hopefully solved) problem : in short,
"saxon-iterate" extension was arbitrarily removed from the free saxon
version years ago. Please read this post about natbraille / saxon he :
http://saxon-xslt-and-xquery-processor.13853.n7.nabble.com/saxon-HE-and-xsl-iterate-td8720.html.
I thought that it had already been solved by writing an alternate and
iterate-free version of miseEnPage.xsl ("page layout") without
saxon-iterate. Seems this correction did not make it to the version you
compile.
-> *Djidjo*, did you port the miseenpage.xsl replacement in
Natbraille-Brailliti ?
Code of alternate and original :
https://svn.liris.cnrs.fr/nat/tags/2.2rc1-sra1.0/xsl/miseEnPage.xsl
https://svn.liris.cnrs.fr/nat/tags/2.2rc1-sra1.0/xsl/miseEnPage.xsl.iterate
Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
On 21/07/16 at 02:21 +0200, Santiago Vila wrote: > On Wed, Jul 20, 2016 at 09:47:52PM +0200, Lucas Nussbaum wrote: > > On 15/07/16 at 00:23 +0200, Santiago Vila wrote: > > > > I did some work to verify Santiago's list of affected packages, and > > identified more affected packages. The additional bugs I filed are at: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org > > > > (I didn't want to directly tag them using Santiago's tag in case some > > manual screening was wanted.) > > > > I only filed them as severity: important. Feel free to bump the severity > > to serious when you see fit. I already mentioned in the bug reports that > > severity will be set to serious at some point, and pointed to this bug. > > Thanks a lot for double-checking. > > > Some of the new bugs are like this: > > make: *** No rule to make target 'build-indep'. Stop. > > Targets build-arch and build-indep are mandatory, and this was already > decided by dpkg author. This is not new, so I would raise those bugs > to serious now. Hi, Those bugs are: • #831918 [i| | ] [src:bglibs] bglibs: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831921 [i| | ] [src:daemontools] daemontools: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831933 [i| | ] [src:mono] mono: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831944 [i| | ] [src:pyorbit] pyorbit: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831945 [i| | ] [src:pygtk] pygtk: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831950 [i| | ] [src:gnome-python] gnome-python: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831960 [i| | ] [src:pygobject-2] pygobject-2: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831961 [i| | ] [src:proftpd-dfsg] proftpd-dfsg: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. • #831963 [i| | ] [src:netqmail] netqmail: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop. I've just raised their severity to serious. > Also: Could you tag those bugs differently so that we can differentiate > them from the remaining ones? We certainly don't want the Release Managers > to think we want to add 61 more RC bugs for stretch when they are > really less than that. I'm not sure we should bother with that... they will all be RC soon anyway. Lucas
Bug#831993: libcommons-codec-java: accesses the internet during build
Le 21/07/2016 à 09:12, Chris Lamb a écrit : > Whilst libcommons-codec-java builds successfully on unstable/amd64, according > to > Debian Policy 4.9 packages may not attempt network access during > a build. Hi Chris, Thank you for reporting this issue. This happens because the Javadoc is linked to the JDK API hosted on download.oracle.com [1]. The connection isn't required for the build though, if it fails the javadoc generated won't contain links to the documentation of the standard API. My understanding of the "no network access" rule was that the build must not require a network connection to complete, nor pull into the package external elements not found in the source tarball at build time. I guess the intent is to ensure that the source packages are self contained. Here the javadoc tool merely checks the existence of the remote documentation to add href links in the generated files. This is optional and doesn't break the build if it doesn't work. So for these reasons I think this is a rather minor policy violation, the package is indeed self contained and doesn't fail to build without network access. I'm more concerned about the reproducibility issue induced though, because this means the package generated will be different when built with or without network access. libcommons-codec-java is still built with Ant. Switching to maven-debian-helper should fix this issue. Emmanuel Bourg [1] https://sources.debian.net/src/libcommons-codec-java/1.10-1/build.xml/#L93
Bug#698477: Do we really need mirror in AWS?
On 21/07/16 at 09:45 +0900, Charles Plessy wrote: > Le Wed, Jul 20, 2016 at 03:48:23PM +0100, Marcin Kulisz a écrit : > > > > do you think that there is still need for mirror on AWS once we have > > CloudFront > > CDN which is working quite nicely from within AWS? > > Hi Marcin, > > I think that http(s)://cloudfront.debian.net/ is exactly what we need. > > And I am not recommending to add it to the list of official geographic > mirrors, > because it is not a geographic service. > > Providers of geographic mirrors know that they will never bear the full cost > of > the whole Debian users downloading packages, given that - obvisouly - users at > a far distance from their mirror will use a different one. But CloudFront or > Azure (if open to the outside; I do not remember) are available worldwide. > If > presented together with the geographic mirrors, and in absence of the official > Debian CDN that is to come but is not ready for prime time yet, then there is > a > risk that through blogs, forums, mail lists, magazine articles etc, one of > these cloud-based mirrors start to become over-popular and attract a lot of > outside traffic, just because it works well from any geographic location. In > that situation we should be prepared to be told that the provided never > intended to pay for so much non-cloud traffic, and shuts down the service or > asks for financial contribution. For that reason, I think that we should > refrain from presenting these mirrors in a similar context as the geographical > official ones. > > Of course, if there are good plans to have cloudfront.debian.net served from > "debian.org" instead, there would be no reason to refrain from doing so. FWIW, I asked on #debian-admin about cloudfront.d.n and deb.debian.org (which is the new CDN setup from DSA, using Fastly at the moment -- see video from DC16 talk): 09:25 <@Mithrandir> lucas: it's not suitable for deb.d.o in its current configuration. 09:25 <@Mithrandir> as I said whenever somebody last asked about it. 09:25 < lucas> is this documented somewhere? if it's not suitable for deb.debian.org, it might not be suitable for the official EC2 images Debian provides 09:25 < lucas> but it's used there 09:27 <@Mithrandir> > curl -s -i http://cloudfront.debian.net/debian-security/ | head -n1 09:27 <@Mithrandir> HTTP/1.1 404 Not Found 09:28 <@Mithrandir> > curl -s -i http://cloudfront.debian.net/debian-debug/ | head -n1 09:28 <@Mithrandir> HTTP/1.1 404 Not Found 09:28 <@Mithrandir> > curl -s -i http://cloudfront.debian.net/debian-ports/ | head -n1 09:28 <@Mithrandir> HTTP/1.1 404 Not Found 09:28 <@Mithrandir> so, well, it's missing 3/4 of the top level "directories" that's supported by deb.d.o 09:28 <@Mithrandir> it's not documented outside of the configuration for deb.d.o atm, no. 09:30 < lucas> ok 09:30 <@Mithrandir> (which is in git) 09:34 <@pabs> uh, why is debian-security supported by deb.d.o? 09:35 <@Mithrandir> why shouldn't it be? 09:35 <@pabs> I thought we discourage use of it via anything other than security.d.o 09:35 <@Mithrandir> it's a one-stop shop for all things .deb (as distributed by Debian) 09:36 <@Mithrandir> we discourage random mirrors, which is slightly different. 09:39 <@weasel> pabs: deb.d.o is not a mirror. 09:40 <@Mithrandir> I wouldn't have a problem with folks using -security through cloudfront.d.n either, fwiw, but static mirrors are very different. 09:44 < lucas> is DSA interested in onboarding cloudfront.d.n as part of deb.d.o, actually? 09:44 <@weasel> I would welcome a second backend 09:46 <@Mithrandir> I'd be fine with it, as long as it's sanely configurable and it has the bits we want. 09:48 < lucas> ok, unless you tell me not to, I'll quote this IRC on debian-cloud@, so there's a trace of it 09:51 <@Mithrandir> I'm fine with my bits being quoted, but if people want DSA input, they should Cc debian-admin@lists.d.o 09:52 <@weasel> and we should at some point extract an overview of the config from our fastly settings. 09:52 <@weasel> but I agree, -cloud is not the place for this discussion for deb.d.o purposes 09:56 <@Mithrandir> I kinda feel like cloudfront should then be under DSA control so we can update its config if we add more bits to deb.d.o, but I'd be happy to have a discussion about how best to solve that. Lucas
Bug#831836: python-django: Add pymysql support
Hi Raphael, Thanks for putting me in the loop. Let me explain what happened in the OpenStack world, so you have a little bit of background here. OpenStack uses SQLAlechemy and Eventlet. This is the case for most daemons across all services. The issue is that, using multitask with Eventlet, Greenthreads + SQLAlechy, python-mysqldb doesn't work well at all and, if I remember well, with concurrency, some deadlock may happen (I don't remember the details, so don't take my words, and read the openstack-...@lists.openstack.org for more details). As SQLAlechemy can support any type of driver (ie: python-mysqldb or python-pymysql), it was decided that we would use pymysql, because it was super easy to do so: we only needed to use mysql+pymysql:// as DSN instead of just mysql://. As a consequence, Ubuntu people want to use pymysql for Django by default, which isn't surprising. Though this is only a direct consequence of them, choosing to *not* support (for security update and such) things that aren't in "main". This doesn't even impact Horizon (the OpenStack dashboard), which doesn't even need a database by default: it *can* use a db, but that's only as a a cache, and the preferred backend for that is Memcache. Memcache is even what Ubuntu configure by default in Horizon. IMO, Ubuntu main vs Ubuntu universe is the least of our concerns in Debian, and shouldn't influence us at all. However, having support for pymysql by default in Django would be a nice thing, so that users could choose. FYI, both drivers share the exact same API, so it is fully transparent, which is why it was so easy for Corey to write that patch. One patch which we could provide to upstream would be a *fallback* to pymysql if the mysqldb Python module isn't present. This would, IMO, make a lot of sense, and probably would be accepted upstream. In anyway, Raphael, I fully support your opinion that this type of things should be a decision from upstream *first*. We can of course attempt to influence this decision, but I don't really like the kind of patch Ubuntu people added, as it kind of hide things to our users. We should stay as close as upstream code as possible in this case. So I'd suggest closing this bug with no further action. Cheers, Thomas Goirand (zigo)
Bug#830979: Bug#831984: zoneminder: modifies shipped file: /usr/share/zoneminder/www/api/app/Config/core.php
> Something like the attached patch? (Untested)
Had more time than I thought; updated and (quickly) tested patch
attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/debian/rules b/debian/rules
index f4a187f..9bf025b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,6 +64,10 @@ override_dh_auto_install:
dh_auto_install --arch --destdir=$(CURDIR)/debian/tmp
# remove empty directories:
-find $(CURDIR)/debian/tmp/usr -mindepth 1 -type d -empty -delete
-printf 'removed %p\n'
+
+ # Don't ship core.php as it contains pre-generated/static salts. We
+ # keep core.php.default as a template for the postinst.
+ rm -f
$(CURDIR)/debian/tmp/usr/share/zoneminder/www/api/app/Config/core.php
override_dh_install:
dh_install -XLICENSE -XLICENSE.txt -X.gitignore
diff --git a/debian/zoneminder.links b/debian/zoneminder.links
index 06dd74e..b1e1e96 100644
--- a/debian/zoneminder.links
+++ b/debian/zoneminder.links
@@ -8,3 +8,5 @@
/usr/share/man/man8/zoneminder-zmf.8.gz
/usr/share/man/man8/zmf.8.gz
/usr/share/man/man8/zoneminder-zmstreamer.8.gz
/usr/share/man/man8/zmstreamer.8.gz
/usr/share/man/man8/zoneminder-zmu.8.gz
/usr/share/man/man8/zmu.8.gz
+
+/etc/zm/core.php /usr/share/zoneminder/www/api/app/Config/core.php
diff --git a/debian/zoneminder.postinst b/debian/zoneminder.postinst
index b50b38a..a5700e5 100644
--- a/debian/zoneminder.postinst
+++ b/debian/zoneminder.postinst
@@ -2,6 +2,9 @@
set -e
+TARGET="/etc/zm/core.php"
+SOURCE="/usr/share/zoneminder/www/api/app/Config/core.php.default"
+
Generate_random () {
tr -dc $1 < /dev/urandom | head -c $2
}
@@ -13,10 +16,15 @@ if [ "$1" = "configure" ]; then
chown www-data:www-data -R /var/cache/zoneminder
fi
- sed -i \
- -e "s@__ZM_API_SALT__@$(Generate_random A-Za-z0-9
29)@g" \
- -e "s@__ZM_API_SEED__@$(Generate_random 0-9 40)@g" \
- /usr/share/zoneminder/www/api/app/Config/core.php
+ if [ ! -e "${TARGET}" ]
+ then
+ echo "I: Generating ${TARGET} from ${SOURCE} ..." >&2
+
+ sed \
+ -e "s@__ZM_API_SALT__@$(Generate_random
A-Za-z0-9 29)@g" \
+ -e "s@__ZM_API_SEED__@$(Generate_random 0-9
40)@g" \
+ ${SOURCE} > ${TARGET}
+ fi
fi
#DEBHELPER#
Bug#830955: keepalived: Segfault - keepalived doesn't work without CONFIG_IP_VS
severity 830955 normal merge 830955 544700 thanks On Wed, 13 Jul 2016, Mathieu Ruellan wrote: > Package: keepalived > Version: 1.2.20-1 > Severity: critical > Justification: causes serious data loss > > Dear Maintainer, > > Could you please update the keepalived to fix this issue? > > > https://github.com/acassen/keepalived/issues/313 We never supported non-default kernels with strange options. However, I am currently preparing an update to 1.2.23. Whilst reading the issue above, I can't see where it relates to your bug. The issue talks about a segfault when there are not VIPs configured. You are talking about CONFIG_IP_VS. Keepalived never supported running it on kernels without CONFIG_IP_VS So, are you sure the above issue is about your bug? Alex
Bug#831993: libcommons-codec-java: accesses the internet during build
> the javadoc tool merely checks the existence of the remote > documentation to add href links in the generated files. Mm. This also happens with Python's "Sphinx" documentation framework. > This is optional and doesn't break the build if it doesn't work. Builds may not even _attempt_ access IMHO - whether it FTBFS or not is irrelevant from this point of view. This is for many reasons, including leaking the privacy of anyone rebuilding our packages and, as you mention, reproducibility. > I think this is a rather minor policy violation I'm afraid not. Policy actually explicitly agrees with my own opinion here for once (am not wielding it as a stick!). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#830572: Support x.y.z-2 UNRELEASED type of changelog opening commits
Hi Otto, On Wed, Jul 20, 2016 at 09:50:19PM +0300, Otto Kekäläinen wrote: > 2016-07-20 15:26 GMT+03:00 Guido Günther : > >> I'd wish there was a option like 'git-dch --unreleased' which simply > >> added to the changelog an empty entry with the Debian revision > >> incremented by one and target set to UNRELEASED. > >> > >> Then I could work as normally and not commit any snapshot commits, but > >> instead only generate snapshots at build time in my own build array or > >> as Launchpad does it. When all changes are done I'd like to run > >> 'git-dch --release' which would remove the temporary empty entry and > >> replace it with the normal git-buildpackage automatic changelog entry. > > > > As discussed offline this sound reasonable. What I currently dislike is > > that we have a -1 debian revision by default. This makes it hard to > > build several candidates with ever increasing version numbers (but > > smaller than the release). Can you explain how you generate "snapshots > > at build time" as said above to avoid this problem? > > Here you can see examples of what kind of build time revision strings > I currently do: > https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.0/+builds?build_text=&build_state=all > > eg. > mariadb-10.0 10.0.25-1~wily1~1462369045.5e6871b > mariadb-10.0 10.0.25-1~wily1~1462377937.cd44cde > mariadb-10.0 10.0.25-1~wily1~1462383653.d02b248 > > After I imported upstream 10.0.25, I had in the changelog 10.0.25-1 > UNRELEASED. > All builds add a tilde so that the extra part after the revision is > smaller than the final release, eg. 10.0.25-1~example on any test > machine will later upgrade to 10.0.25-1 when it is available via > official channels. > > In this example after the tilde I have the distro pocket name, Unix > epoch and git commit id. The distro pocket name is for convenience > when I make test builds for multiple distro series. The unix timestamp > makes sure any later release has a bigger revision number then a > previous one, and the final git commit makes it easy for me to > correlate potential failed builds to particular commits in my git log. > > My build system automatically adds the '~wily1~1462383653.d02b248' > part for every build. Only thing that git-buildpackage should do, is > support automatic or at least semi-automatic creation of a new empty > changelog entry with Debian revision +1 (or complete new version > number after import-orig) and distro series "UNRELEASED". O.k. so we would use a Debian revision of 1 and squash changelog entries under that revision until one makes a release. Snapshot builds would get a lower version number (e.g. as currently implemented). After the release of version 1 we then need to automatically add a section with 2 and UNRELEASED and so on. In case of a new upstream version we need to check if the last entry is unreleased and in this case rewrite the version number with upstream-version and Debian revision 1. If it is not unreleased we simply add a new section. I'm not making any promises when I will get around to work on this (before next Debconf) but is sounds reasonable since it makes it more obvious from the changelog what will be the next release version. Cheers, -- Guido
Bug#831998: debdelta: insufficient space in tmpfs
Package: debdelta
Version: 0.55
Severity: important
It turns out debdelta uses tmpfs for its temporary file operations.
While it has its benefits, it also has its side effects, like the
following:
Created,time 4.85sec, speed 1233kB/sec, libc6-dbg_2.23-2_amd64.deb
Created,time 122.05sec, speed 293kB/sec,
linux-image-4.6.0-1-amd64_4.6.4-1_amd64.deb
Created,time 77.41sec, speed 374kB/sec,
libreoffice-core_1%3a5.1.5~rc1-1_amd64.deb
Error: applying of delta for linux-image-4.6.0-1-amd64-dbg failed: : Sorry,
not enough disk space (3618192kB) in directory /tmp for applying delta (needs
3681844kB) (retriable)
Delta-upgrade statistics:
total resulting debs, size 271MB time 819sec virtual speed 338kB/sec
There were faulty deltas. Sending logs to server.
debdelta-upgrade : No module named poster
13:38 ♒♒♒☹ => 4
rrs@chutzpah:~$ df -h
Either debdelta should add a fallback location (non-tmpfs) or have it
user configurable.
This is what debdelta has:
TMPDIR = ( os.getenv('TMPDIR') or '/tmp' ).rstrip('/')
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (990, 'unstable'), (990, 'testing'), (500, 'unstable-debug'),
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.6.0-1-amd64 (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)
Versions of packages debdelta depends on:
ii binutils2.26.1-1
ii bzip2 1.0.6-8
ii libbz2-1.0 1.0.6-8
ii libc6 2.23-1
ii python 2.7.11-2
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages debdelta recommends:
ii bsdiff 4.3-15
ii gnupg-agent 2.1.11-7
ii gnupg2 2.1.11-7
ii python-apt 1.1.0~beta3
ii python-debian0.1.28
ii xdelta 1.1.3-9.1
ii xdelta3 3.0.11-dfsg-1
ii xz-utils [lzma] 5.1.1alpha+20120614-2.1
Versions of packages debdelta suggests:
pn debdelta-doc
-- no debconf information
Bug#829272: [openssl.org #4602] Missing accessors
ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT: > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote: > > > > I guess having a more restrictive accessor that only sets the > > EXFLAG_PROXY bit could work. I suggested the more general solution of > > having set/clear accessors for arbitrary flags since it was - well > > more > > general. > > So let me ask this in a different manner, does OpenSSL 1.1 still not set the > EXFLAG_PROXY flag correctly? In what situations does that happen? That may be > worth a bug report of its own. > > -- > Richard Levitte > levi...@openssl.org > The answer to this is related to Mischa's reply, which unfortunately was only sent to the Debian BTS and not the the OpenSSL RT. I quote it below. As indicated in the answer, setting the EXFLAG_PROXY allows handling non-RFC proxies in OpenSSL. mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle: > Hi Richard, Mattias, others, > > I agree with you that it would be nice if OpenSSL could figure out > itself whether a cert needs to be treated as a proxy, but currently that > doesn't work reliably as far as I know. > The flag is certainly needed in the case of non-RFC3820 proxies, also > known as legacy proxies. Unfortunately these are still very widely used > (majority of the proxies actually) and hence our code must be able to > handle them correctly. > > Best wishes, > Mischa Sallé > smime.p7s Description: S/MIME cryptographic signature
Bug#831836: python-django: Add pymysql support
> In anyway, Raphael, I fully support your opinion that this type of > things should be a decision from upstream *first*. > [..] > We should stay as close as upstream code as possible in this case. So > I'd suggest closing this bug with no further action. I agree with this. I really like how our Django packages don't mess with upstream, although most of this credit should go to upstream for being sensible in the first place.. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#830979: Bug#831984: zoneminder: modifies shipped file: /usr/share/zoneminder/www/api/app/Config/core.php
On 2016-07-21 10:05, Chris Lamb wrote: >> Something like the attached patch? (Untested) > > Had more time than I thought; updated and (quickly) tested patch > attached. postrm purge should delete /etc/zm/core.php, shouldn't it? What should happen if core.php.default changes its content? There are a lot of options, maybe a new one is added some day ... Andreas
Bug#830572: Support x.y.z-2 UNRELEASED type of changelog opening commits
2016-07-21 11:11 GMT+03:00 Guido Günther : > O.k. so we would use a Debian revision of 1 and squash changelog entries > under that revision until one makes a release. Snapshot builds would get > a lower version number (e.g. as currently implemented). After the > release of version 1 we then need to automatically add a section with 2 > and UNRELEASED and so on. Yes > In case of a new upstream version we need to check if the last entry is > unreleased and in this case rewrite the version number with > upstream-version and Debian revision 1. If it is not unreleased we > simply add a new section. Yes > I'm not making any promises when I will get around to work on this > (before next Debconf) but is sounds reasonable since it makes it more > obvious from the changelog what will be the next release version. OK. Now you at least have the spec done so you can implement it when you have time. Regards Otto, who uploaded today 3 packages that all use git-buildpackage
Bug#831983: kde-telepathy-contact-list: ktp-contactlist no longer able to log in to gtalk, sip
Dear Juha, Am Mittwoch, 20. Juli 2016, 23:40:41 CEST schrieb Juha Jäykkä: > Package: kde-telepathy-contact-list > Version: 15.08.3-1 > Severity: important > > Dear Maintainer, > > After upgrading to 15.08.3-1, ktp-contactlist (or the plasma applets) no > longer can log into gtalk or sip. These are possibly separate bugs as sip > auth handler segfaults whereas gtalk simply does not become "available". It > gives no error messages, warnings or any other indication that it is even > trying to do anything. In case you feel adventurous I suggest you try out whether upgrading kde- telepathy to the version in experimental fixes your issue. I see you have experimental added to your sources list anyway. > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 […] I used the following command to do just that on my sid system: apt -t experimental install kde-telepathy kde-telepathy-approver kde- telepathy-auth-handler kde-telepathy-contact-list kde-telepathy-data kde- telepathy-desktop-applets kde-telepathy-filetransfer-handler kde-telepathy- integration-module kde-telepathy-kaccounts kde-telepathy-kpeople kde- telepathy-minimal kde-telepathy-send-file kde-telepathy-text-ui qml-module- org-kde-telepathy If you try this and it fixes the issue for you, please let us now. Thank you, -- Martin
Bug#831999: installation-reports: non-free firmware: installer-Msg should mention: FAT-File System is needed on external media
Package: installation-reports Severity: minor Dear Maintainer, My installation needed non-free firmware. + i try to place it on a ext3-external HDD. + plugged it in as requested, but the installer didnt find anything, the mount-command fails with "invalid argumnts"(?) + but the installer did'nt told me this, i had to look at tty4. My suggestions: +! the installer should tell me that FAT FS is needed. + it also should tell where (which directory, which files ) and what file-format (deb and *fw). ( + or even better also handle extX FS. ) +! and/or report failed mount atempts more user-friendly. -- Package-specific info: Boot method: CD Image version: dvd-images 06/2016 Date: 10/07/2016 Comments/Problems: The Message from the Installer (in german): "Teile ihrer Hardware benötigen nicht-freie Firmware-Dateien, um zu funktionieren. Die Firmware kann von einem Wechseldatenträger, wie einem usb-stick oder einer diskette, geladen werden." I suggest the following Information to add: "external media must be FAT (32? 16?) -formated" "the Fw-Files could be in rtl_nic/rtl8168e-3.fw or in a .deb-archive or whatever" -- System Information: Debian Release: 8.5 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/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: OpenPGP digital signature
Bug#830979: Bug#831984: zoneminder: modifies shipped file: /usr/share/zoneminder/www/api/app/Config/core.php
> postrm purge should delete /etc/zm/core.php, shouldn't it? Probably. Patches are proof of concept, am not the maintainer/user here. :) > What should happen if core.php.default changes its content? There are a > lot of options, maybe a new one is added some day ... Good point. So maybe the maintainer should ship a patched core.php under /etc so it gets all the conffile upgrade/diff magic which includes another file with the generated security stuff.. Anyway, probably given you both enough rope for now :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#831993: libcommons-codec-java: accesses the internet during build
> PS1: I can't say that I'm 100% convinced by this policy change. This may not be the appropriate venue for a protracted discussion as it's liable to get hidden but can you briefly outline why? > PS2: I'm surprised that it took so long after the release of policy > 3.9.7 before someone started a mass bug filing :) Oh, I haven't started a systematic filing yet. Just filing them as I come across them. ;) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#829272: Missing accessors
ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT: > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote: > > > > I guess having a more restrictive accessor that only sets the > > EXFLAG_PROXY bit could work. I suggested the more general solution of > > having set/clear accessors for arbitrary flags since it was - well > > more > > general. > > So let me ask this in a different manner, does OpenSSL 1.1 still not set the > EXFLAG_PROXY flag correctly? In what situations does that happen? That may be > worth a bug report of its own. > > -- > Richard Levitte > levi...@openssl.org > The answer to this is related to Mischa's reply, which unfortunately was only sent to the Debian BTS and not the the OpenSSL RT. I quote it below. As indicated in the answer, setting the EXFLAG_PROXY allows handling non-RFC proxies in OpenSSL. mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle: > Hi Richard, Mattias, others, > > I agree with you that it would be nice if OpenSSL could figure out > itself whether a cert needs to be treated as a proxy, but currently that > doesn't work reliably as far as I know. > The flag is certainly needed in the case of non-RFC3820 proxies, also > known as legacy proxies. Unfortunately these are still very widely used > (majority of the proxies actually) and hence our code must be able to > handle them correctly. > > Best wishes, > Mischa Sallé > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted smime.p7s Description: S/MIME cryptographic signature
Bug#831993: libcommons-codec-java: accesses the internet during build
On Thu, 21 Jul 2016 10:00:06 +0200, Emmanuel Bourg wrote: > My understanding of the "no network access" rule was that the build must > not require a network connection to complete, nor pull into the package > external elements not found in the source tarball at build time. I guess > the intent is to ensure that the source packages are self contained. In my understanding, this has changed in 3.9.7 (emphasis mine): * Policy: [4.9] debian/rules: required targets _must not attempt_ network [..] Closes: #770016 > Here the javadoc tool merely checks the existence of the remote > documentation to add href links in the generated files. This is optional > and doesn't break the build if it doesn't work. So for these reasons I > think this is a rather minor policy violation, the package is indeed > self contained and doesn't fail to build without network access. As the discussion in #770016 shows, the new wording is not about "packages mustn't fail to build without network" but indeed "packages aren't even _allowed to try_ to reach beyond localhost during build." PS1: I can't say that I'm 100% convinced by this policy change. PS2: I'm surprised that it took so long after the release of policy 3.9.7 before someone started a mass bug filing :) Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #374: It's the InterNIC's fault.
Bug#831993: libcommons-codec-java: accesses the internet during build
> Interesting, thank you for the reference. libcommons-codec-java > currently declares a compliance to the version 3.9.6 of the policy. Does > it mean the new rule doesn't apply to it yet? :) Oh, now /that's/ a very cute argument :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#830955: keepalived: Segfault - keepalived doesn't work without CONFIG_IP_VS
Hi. Sorry i havn't any knownledge about keepalived conception. I just observe that it is a regression (the previous testing package was working fine) and stacktraces are the sames I'm using the debian default kernel. I have built a home deb from the github master branch, and now it is working like a charm. Mathieu On 07/21/2016 10:09 AM, Alexander Wirt wrote: severity 830955 normal merge 830955 544700 thanks On Wed, 13 Jul 2016, Mathieu Ruellan wrote: Package: keepalived Version: 1.2.20-1 Severity: critical Justification: causes serious data loss Dear Maintainer, Could you please update the keepalived to fix this issue? https://github.com/acassen/keepalived/issues/313 We never supported non-default kernels with strange options. However, I am currently preparing an update to 1.2.23. Whilst reading the issue above, I can't see where it relates to your bug. The issue talks about a segfault when there are not VIPs configured. You are talking about CONFIG_IP_VS. Keepalived never supported running it on kernels without CONFIG_IP_VS So, are you sure the above issue is about your bug? Alex
Bug#832000: grip: new upstream release (4.3.2)
Package: grip Severity: wishlist -- Jakub Wilk
Bug#831993: libcommons-codec-java: accesses the internet during build
Le 21/07/2016 à 10:24, gregor herrmann a écrit : > In my understanding, this has changed in 3.9.7 (emphasis mine): > > * Policy: [4.9] debian/rules: required targets _must not attempt_ network > [..] > Closes: #770016 Interesting, thank you for the reference. libcommons-codec-java currently declares a compliance to the version 3.9.6 of the policy. Does it mean the new rule doesn't apply to it yet? :) Emmanuel Bourg
Bug#830979: Bug#831984: zoneminder: modifies shipped file: /usr/share/zoneminder/www/api/app/Config/core.php
On Thursday, 21 July 2016 9:31:47 AM AEST Chris Lamb wrote: > This seems an odd.attitude to have as the maintainer.. :) Sorry if I didn't make it clear: I'm not blaming anyone, it was a oversight on my side which will be fixed. Chris, since I applied your patch I wanted you to get a feedback of its consequences. I hope it is not "odd.attitude". Do I have to recognize the problem as problem every time I respond to bug to avoid "odd.attitude" perception? You know, I'm not denying the problem (or I would have probably tagged it as "wontfix")... -- Regards, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#832001: pyenchant: new upstream release (1.6.7)
Source: pyenchant Severity: wishlist -- Jakub Wilk
Bug#832002: libjdns: please improve short and long package descriptions
Source: libjdns
Version: 2.0.3-1
Severity: wishlist
Tags: patch
Hi,
It's not immediately obvious from the description that this is
a DNS testing tool - one needs to infer it from the package name
which is a little sub-optimal IMHO.
Patch attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/debian/control b/debian/control
index 64e3d76..30f65a5 100644
--- a/debian/control
+++ b/debian/control
@@ -13,8 +13,8 @@ Package: jdns
Section: misc
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
-Description: command-line tool to test functionality
- Qt4-based command-line tool called âjdnsâ that can be used to test
+Description: command-line tool to test DNS functionality
+ Qt4-based command-line tool called âjdnsâ that can be used to test DNS
functionality.
Package: jdns-dbg
@@ -22,8 +22,8 @@ Section: debug
Priority: extra
Architecture: any
Depends: jdns (= ${binary:Version}), ${misc:Depends}
-Description: command-line tool to test functionality - debugging symbols
- Qt4-based command-line tool called âjdnsâ that can be used to test
+Description: command-line tool to test DNS functionality - debugging symbols
+ Qt4-based command-line tool called âjdnsâ that can be used to test DNS
functionality.
.
This package contains the debugging symbols for debugging crashes in the
Bug#830955: keepalived: Segfault - keepalived doesn't work without CONFIG_IP_VS
On Thu, 21 Jul 2016, Mathieu Ruellan wrote: > Hi. > > Sorry i havn't any knownledge about keepalived conception. I just observe > that it is a regression (the previous testing package was working fine) and > stacktraces are the sames > > I'm using the debian default kernel. > I have built a home deb from the github master branch, and now it is working > like a charm. the debian kernels have CONFIG_IP_VS since ages. You probably had a different problem then. I consider it fixed with my 1.2.23 upload. Please reopen if the problem still happens. Alex
Bug#832003: RFS: jupyter-core/4.1.0-2 (to experimental!)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "jupyter-core" * Package name: jupyter-core Version : 4.1.0-2 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/jupyter_core * License : BSD-3-clause Section : python It builds those binary packages: jupyter-core - Core common functionality of Jupyter projects (tools) python-jupyter-core - Core common functionality of Jupyter projects for Python 2 python-jupyter-core-doc - Core common functionality of Jupyter projects (documentation) python3-jupyter-core - Core common functionality of Jupyter projects for Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/jupyter-core Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/j/jupyter-core/jupyter-core_4.1.0-2.dsc It is maintained within the Debian Python Modules Team: Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/jupyter-core.git Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/jupyter-core.git Notice that experimental already has 4.1.0-1 ; this 4.1.0-2 brings in better packaging -- for experimental too! It's part of the effort to package jupyter in Debian (which is itself part of the effort to get sagemath into Debian...). Cheers, Snark on #debian-python
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I have prepared an upload fixing CVE-2016-4476 and CVE-2016-4477.
Please find the attached debdiff.
Sébastien Delafond advised me this upload is for the point release,
and isn't supposed to be handled by the Security Team.
--
Cheers,
Andrew
diff -Nru wpa-2.3/debian/changelog wpa-2.3/debian/changelog
--- wpa-2.3/debian/changelog 2015-11-07 16:07:28.0 +0100
+++ wpa-2.3/debian/changelog 2016-07-21 09:19:43.0 +0200
@@ -1,3 +1,17 @@
+wpa (2.3-1+deb8u4) jessie; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patches to address CVE-2016-4476 and CVE-2016-4477, thanks to
+Salvatore Bonaccorso (Closes: #823411):
+- WPS: Reject a Credential with invalid passphrase
+- Reject psk parameter set with invalid passphrase character
+- Remove newlines from wpa_supplicant config network output
+- Reject SET_CRED commands with newline characters in the string values
+- Reject SET commands with newline characters in the string values
+ * Refresh patches to apply cleanly.
+
+ -- Andrew Shadura Thu, 21 Jul 2016 09:19:42 +0200
+
wpa (2.3-1+deb8u3) jessie-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch
--- wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch 1970-01-01 01:00:00.0 +0100
+++ wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch 2016-07-21 08:49:03.0 +0200
@@ -0,0 +1,37 @@
+From 9ed4eee345f85e3025c33c6e20aa25696e341ccd Mon Sep 17 00:00:00 2001
+From: Jouni Malinen
+Date: Tue, 7 Apr 2015 11:32:11 +0300
+Subject: [PATCH] P2P: Validate SSID element length before copying it
+ (CVE-2015-1863)
+
+This fixes a possible memcpy overflow for P2P dev->oper_ssid in
+p2p_add_device(). The length provided by the peer device (0..255 bytes)
+was used without proper bounds checking and that could have resulted in
+arbitrary data of up to 223 bytes being written beyond the end of the
+dev->oper_ssid[] array (of which about 150 bytes would be beyond the
+heap allocation) when processing a corrupted management frame for P2P
+peer discovery purposes.
+
+This could result in corrupted state in heap, unexpected program
+behavior due to corrupted P2P peer device information, denial of service
+due to process crash, exposure of memory contents during GO Negotiation,
+and potentially arbitrary code execution.
+
+Thanks to Google security team for reporting this issue and smart
+hardware research group of Alibaba security team for discovering it.
+
+Signed-off-by: Jouni Malinen
+---
+ src/p2p/p2p.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/src/p2p/p2p.c
b/src/p2p/p2p.c
+@@ -736,6 +736,7 @@ int p2p_add_device(struct p2p_data *p2p,
+ if (os_memcmp(addr, p2p_dev_addr, ETH_ALEN) != 0)
+ os_memcpy(dev->interface_addr, addr, ETH_ALEN);
+ if (msg.ssid &&
++ msg.ssid[1] <= sizeof(dev->oper_ssid) &&
+ (msg.ssid[1] != P2P_WILDCARD_SSID_LEN ||
+ os_memcmp(msg.ssid + 2, P2P_WILDCARD_SSID, P2P_WILDCARD_SSID_LEN)
+ != 0)) {
diff -Nru wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt
--- wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt 1970-01-01 01:00:00.0 +0100
+++ wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt 2016-07-21 08:49:03.0 +0200
@@ -0,0 +1,68 @@
+wpa_supplicant P2P SSID processing vulnerability
+
+Published: April 22, 2015
+Identifier: CVE-2015-1863
+Latest version available from: http://w1.fi/security/2015-1/
+
+
+Vulnerability
+
+A vulnerability was found in how wpa_supplicant uses SSID information
+parsed from management frames that create or update P2P peer entries
+(e.g., Probe Response frame or number of P2P Public Action frames). SSID
+field has valid length range of 0-32 octets. However, it is transmitted
+in an element that has a 8-bit length field and potential maximum
+payload length of 255 octets. wpa_supplicant was not sufficiently
+verifying the payload length on one of the code paths using the SSID
+received from a peer device.
+
+This can result in copying arbitrary data from an attacker to a fixed
+length buffer of 32 bytes (i.e., a possible overflow of up to 223
+bytes). The SSID buffer is within struct p2p_device that is allocated
+from heap. The overflow can override couple of variables in the struct,
+including a pointer that gets freed. In addition about 150 bytes (the
+exact length depending on architecture) can be written beyond the end of
+the heap allocation.
+
+This could result in corrupted state in heap, unexpected program
+behavior due to corrupte
Bug#831993: libcommons-codec-java: accesses the internet during build
Le 21/07/2016 à 10:41, Chris Lamb a écrit : > Oh, now /that's/ a very cute argument :) I'm fine with fixing the package so I won't defend this argument too much, but I'd be curious to know. Because if the compliance level declared by the package doesn't matter, it would mean the Standards-Version field could be deprecated (and considering the time we spend bumping the value of this field twice a year for ~500 packages actively maintained by the Java team, such a simplification would be welcome). Emmanuel Bourg
Bug#831993: libcommons-codec-java: accesses the internet during build
> I won't defend this argument too much, but I'd be curious to know. Same here. Alas I'm not a Policy "wonk" (and try to avoid being one as it tends to devolve technical discussions into ones of intepretative legal-like arguments that focus on the minutae of language rather than on, well, what is best for Debian) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#831899: kaddressbook crashes immediately on start
Holla Maximiliano, thanks for your fast reply. Am Donnerstag, 21. Juli 2016, 09:30:59 CEST schrieb Maximiliano Curia: > Control: tag -1 upstream > Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=358696 > > ¡Hola Volker! > > El 2016-07-20 a las 18:46 +0200, Volker Groll escribió: > > Package: kaddressbook > > Version: 4:16.04.3-1 > > Severity: normal > > > > Wenn starting in a terminal kaddressbook, I get the following output: > > org.kde.akonadi.ETM: GEN true false true > > org.kde.akonadi.ETM: collection: QVector() > > KCrash: crashing... crashRecursionCounter = 2 > > KCrash: Application Name = kaddressbook path = /usr/bin pid = 10837 > > KCrash: Arguments: /usr/bin/kaddressbook > > KCrash: Attempting to start /usr/lib/i386-linux-gnu/libexec/drkonqi from > > kdeinit > > sock_file=/run/user/1000/kdeinit5__0 > > > > [1]+ Angehalten LANG=C kaddressbook > > > > Fetch to the foreground gives the output: > > LANG=C kaddressbook > > QSocketNotifier: Invalid socket 16 and type 'Read', disabling... > > QSocketNotifier: Invalid socket 11 and type 'Read', disabling... > > QSocketNotifier: Invalid socket 14 and type 'Read', disabling... > > QSocketNotifier: Invalid socket 9 and type 'Read', disabling... > > QSocketNotifier: Invalid socket 19 and type 'Read', disabling... > > QSocketNotifier: Invalid socket 17 and type 'Read', disabling... > > QSocketNotifier: Invalid socket 25 and type 'Read', disabling... > > QSocketNotifier: Invalid socket 27 and type 'Read', disabling... > > > > The I can dismiss the bug report window from kde. > > It seems to me that the bug is the same as: > https://bugs.kde.org/show_bug.cgi?id=358696 Hm, not sure, but there is mentioned the crash occurs, when the birthday calendar is enabled, mine is disabled. > Could you please provide additional information in the bug upstream? > Currently it seems to require confirmation that this bug is only > reproduceable in 32 bits systems. I have local address books and two on an owncloud server. Changing the owncloud resource to offline with akonadiconsole changes nothing (crash persists). I get also a crash from akonadiconsole when I try to switch to Browser tab. > Also, a full backtrace would be useful, for that you would need to install > the kaddressbook-dbgsym package (and probably the dbg/dbgsym packages from > a couple of kaddressbook dependencies) from the debug archive (that needs > to be added in the sources.list as: deb http://deb.debian.org/debian-debug > unstable-debug main) Most threads are in g_mutex_unlock (), __kernel_vsyscall () Installing libglib2.0-0-dbg will give only 0x in output, so I purged this debug package again. The output of the last thread is: Thread 1 (Thread 0xed0a6ac0 (LWP 5109)): [KCrash Handler] #7 0xf4ff1cb6 in Akonadi::Tag::isValid (this=0xff8b137c) at /build/akonadi- uzW5jU/akonadi-16.04.3/src/core/tag.cpp:239 #8 0xf5097577 in Akonadi::TagModel::data (this=0x9b1c098, index=..., role=258) at /build/akonadi-uzW5jU/akonadi-16.04.3/src/core/models/ tagmodel.cpp:95 #9 0xf76565b4 in CategorySelectWidgetPrivate::slotTagsInserted (this=0x9ad86f0, parent=..., start=0, end=0) at /build/kdepim-Py8sU_/ kdepim-16.04.3/kaddressbook/categoryselectwidget.cpp:174 #10 0xf7657d75 in QtPrivate::FunctorCall, QtPrivate::List, void, void (CategorySelectWidgetPrivate::*)(QModelIndex const&, int, int)>::call (arg=0xff8b15cc, o=0x9ad86f0, f=) at /usr/include/i386-linux- gnu/qt5/QtCore/qobjectdefs_impl.h:501 #11 QtPrivate::FunctionPointer::call, void> (arg=0xff8b15cc, o=0x9ad86f0, f=) at /usr/include/ i386-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:520 #12 QtPrivate::QSlotObject, void>::impl (which=1, this_=0x9b01638, r=0x9ad86f0, a=0xff8b15cc, ret=0x0) at /usr/ include/i386-linux-gnu/qt5/QtCore/qobject_impl.h:143 #13 0xf60feb13 in QMetaObject::activate(QObject*, int, int, void**) () from / usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5 #14 0xf60fefbd in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5 #15 0xf617af11 in QAbstractItemModel::rowsInserted(QModelIndex const&, int, int, QAbstractItemModel::QPrivateSignal) () from /usr/lib/i386-linux-gnu/sse2/ libQt5Core.so.5 #16 0xf6075909 in QAbstractItemModel::endInsertRows() () from /usr/lib/i386- linux-gnu/sse2/libQt5Core.so.5 #17 0xf5099601 in Akonadi::TagModelPrivate::monitoredTagAdded (this=0x9b75aa0, tag=...) at /build/akonadi-uzW5jU/akonadi-16.04.3/src/core/models/ tagmodel_p.cpp:127 #18 0xf5099d5a in Akonadi::TagModelPrivate::tagsFetched (this=0x9b75aa0, tags=...) at /build/akonadi-uzW5jU/akonadi-16.04.3/src/core/models/ tagmodel_p.cpp:224 #19 0xf509690e in Akonadi::TagModel::qt_static_metacall (_o=0x9b1c098, _c=QMetaObject::InvokeMetaMethod, _id=2, _a=0xff8b1874) at /build/akonadi- uzW5jU/akonadi-16.04.3/obj-i686-linux-gnu/src/core/moc_tagmodel.cpp:103 #20 0xf60fea86 in QMetaObject::activate(QObject*, int, int, void**) () from / usr/lib/i386-linux-gnu/sse2/libQt5
Bug#831779: python-docutils: please make the output of rst2man reproducible
> Can you please forward it upstream to [1], or do you want me to do that? Please go ahead and do that. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#832005: ITP: r-cran-tibble -- GNU R Simple Data Frames
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-tibble Version : 1.1 Upstream Author : Hadley Wickham, Romain Francois, Kirill Müller, RStudio * URL : https://cran.r-project.org/web/packages/tibble * License : MIT/X Programming Lang: GNU R Description : GNU R Simple Data Frames This GNU R package provides a 'tbl_df' class that offers better checking and printing capabilities than traditional data frames. Remark: This package is a new dependency of r-cran-dplyr and will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-tibble/trunk/
Bug#831993: libcommons-codec-java: accesses the internet during build
On Thu, 21 Jul 2016 10:33:35 +0200, Chris Lamb wrote: > > PS1: I can't say that I'm 100% convinced by this policy change. > This may not be the appropriate venue for a protracted discussion as > it's liable to get hidden but can you briefly outline why? My experience with perl packages shows that: - internet access doesn't happen during the build itself but in the test suite; - usually in modules whose purpose is to do something net-related; - by disabling them, even if they fail gracefully, in order to follow policy, we effectively castrate the tests, which doesn't seem right from a QA POV. In those cases the argument "builds differently/produces a different binary package/doesn't build reproducibly" with vs. without internet doesn't hold; still, the privacy/phoning-home aspect is true here as well, so I'm ambivalent. Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #315: The recent proliferation of Nuclear Testing
Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)
On 21/07/16 at 00:43 +0200, Emmanuel Bourg wrote: > Le 20/07/2016 à 21:47, Lucas Nussbaum a écrit : > > > Once the issue is fixed in maven-repo-helper, those packages should be > > build-tested again (I can do that if needed; please ping me). > > The 'mh_install -i' issue is fixed in maven-repo-helper 1.9.2. > > Could you test again the packages previously affected please? Hi, I can confirm that they all built fine. Thanks! Lucas
Bug#831993: libcommons-codec-java: accesses the internet during build
Thanks :) > - by disabling them, even if they fail gracefully, in order to follow > policy, we effectively castrate the tests, which doesn't seem right > from a QA POV. Mm, agreed. Moving these tests to the autopkgtest infrastructure is one fix but it's not "that" clean a solution.. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#832006: makedumpfile: [INTL:fr] French debconf translation
Package: makedumpfile Severity: wishlist Tags: patch l10n Hi! Please find attached the french translation, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. Kind Regards jipege fr.po.gz Description: application/gzip
Bug#832007: python-jenkins depends on python-pbr
Package: python-jenkins
Version: 0.4.11-1
Severity: normal
Hi,
python-jenkins depends on python-pbr which pulls python-pip and other
packages. This is quite a huge list of dependencies just for one line in
jenkins/version.py:
version_info = pbr.version.VersionInfo('jenkins')
Could the runtime dependency on python-pbr be made optional or removed
or the list of dependencies of python-pbr reduced?
I already reported this bug upstream: https://launchpad.net/bugs/1605149
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin
Email: benjamin.dr...@profitbricks.com
URL: http://www.profitbricks.com
Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)
Le 21/07/2016 à 11:09, Lucas Nussbaum a écrit : > I can confirm that they all built fine. Thanks! Excellent! Thank you for confirming. Emmanuel Bourg
Bug#831993: libcommons-codec-java: accesses the internet during build
On Thu, 21 Jul 2016 11:19:46 +0200, Chris Lamb wrote: > > - by disabling them, even if they fail gracefully, in order to follow > > policy, we effectively castrate the tests, which doesn't seem right > > from a QA POV. > Mm, agreed. Moving these tests to the autopkgtest infrastructure is one > fix but it's not "that" clean a solution.. Well, right, autopkgtest is the next question. If a test is forbidden to leak to external parties the fact that it's being run during build, the same is probably true by analogy for autopkgtests? (Recently I disabled the same tests for both build + autopkgtests.) Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #211: Lightning strikes.
Bug#831977: [libreoffice-calc] I can confirm bug831977 with Debian's own version but not upstream
Package: libreoffice-calc Version: 1:5.1.4~rc2-2 --- Please enter the report below this line. --- Hello @ll, as the one who did some further testing with my parallel installed versions of LO and recommended D. to report it here, I just want to add my system's information in case this is of any importance ... ;) For further information, please see my comment at https://bugs.documentfoundation.org/show_bug.cgi?id=100841#c10. HTH Thomas. --- System information. --- Architecture: amd64 Kernel: Linux 4.5.0-2-amd64 Debian Release: stretch/sid 500 xenial ppa.launchpad.net 500 unstabledownload.jitsi.org 500 testing www.deb-multimedia.org 500 testing ftp.de.debian.org 500 stable security.debian.org 500 stable deb.opera.com 500 sid linux.dropbox.com --- Package information. --- Depends (Version) | Installed ==-+-= libreoffice-base-core(= 1:5.1.4~rc2-2) | 1:5.1.4~rc2-2 libreoffice-core (= 1:5.1.4~rc2-2) | 1:5.1.4~rc2-2 lp-solve(>= 5.5.0.13-5+b1) | 5.5.0.15-4 coinor-libcbc3 | 2.8.12-1+b1 coinor-libcoinmp1v5| 1.7.6+dfsg1-2 libboost-filesystem1.58.0 | 1.58.0+dfsg-5.1 libboost-iostreams1.58.0 | 1.58.0+dfsg-5.1 libc6(>= 2.14) | libetonyek-0.1-1 | libgcc1 (>= 1:3.0) | libicu55 (>= 55.1-1~) | liblcms2-2(>= 2.2+git20110628) | libmwaw-0.3-3 | libodfgen-0.1-1| liborcus-0.11-0| librevenge-0.0-0 | libstdc++6(>= 5.2) | libwps-0.4-4 | libxml2 (>= 2.7.4) | uno-libs3 (>= 5.1.0~alpha) | ure| zlib1g(>= 1:1.1.4) | fontconfig | fonts-opensymbol | libreoffice-common(>> 1:5.1.4~rc2) | ure (>= 4.2~) | libboost-date-time1.58.0 | libc6(>= 2.16) | libcairo2 (>= 1.10.0) | libclucene-contribs1v5(>= 2.3.3.4) | libclucene-core1v5(>= 2.3.3.4) | libcmis-0.5-5v5| libcups2(>= 1.4.0) | libcurl3-gnutls(>= 7.16.2) | libdbus-1-3(>= 1.9.14) | libdbus-glib-1-2 (>= 0.78) | libdconf1 (>= 0.14.0) | libeot0| libexpat1 (>= 2.0.1) | libexttextcat-2.0-0 (>= 2.2-8) | libfontconfig1 (>= 2.11) | libfreetype6(>= 2.3.5) | libgcc1 (>= 1:3.0) | libgl1-mesa-glx| OR libgl1 | libglew1.13(>= 1.12.0) | libglib2.0-0 (>= 2.31.8) | libgltf-0.0-0v5| libglu1-mesa | OR libglu1| libgraphite2-3 (>= 1.2.2) | libharfbuzz-icu0 (>= 0.9.18) | libharfbuzz0b (>= 0.9.18) | libhunspell-1.4-0 | libhyphen0 (>= 2.7.1) | libice6 (>= 1:1.0.0) | libicu55 (>= 55.1-1~) | libjpeg62-turbo (>= 1.3.1) | liblangtag1 (>= 0.4.0) | liblcms2-2(>= 2.2+git20110628) | libldap-2.4-2 (>= 2.4.7) | libmythes-1.2-0| libneon27-gnutls | libnspr4(>= 2:4.9-2~) | OR libnspr4-0d (>= 1.8.0.10) | libnss3 (>= 2:3.13.4-2~) | OR libnss3-1d (>= 3.12.0~beta2) | libodfgen-0.1-1| libpcre3 | libpng16-16 (>= 1.6.2-1) | librevenge-0.0-0 | libsm6 | libssl1.0.
Bug#832001: pyenchant: new upstream release (1.6.7)
thanks for the info. pypi.python.org and homepage¹ still don't have it, though It looks like 1.6.7 was tagged on github only... [¹] https://pythonhosted.org/pyenchant/download.html
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Control: tags -1 + moreinfo On 2016-07-21 9:51, Andrew Shadura wrote: I have prepared an upload fixing CVE-2016-4476 and CVE-2016-4477. Please find the attached debdiff. I may be missing something, but what do these changes have to do with fixing either of the CVEs you mentioned? patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch | 37 + patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt | 68 + patches/2015-02/0001-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch | 44 + patches/2015-02/wps-upnp-http-chunked-transfer-encoding.txt | 73 + patches/2015-03/0001-AP-WMM-Fix-integer-underflow-in-WMM-Action-frame-par.patch | 36 patches/2015-04/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch | 68 + patches/2015-04/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch | 61 + patches/2015-04/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch | 47 + patches/2015-04/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch | 45 + patches/2015-04/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch | 27 patches/2015-04/eap-pwd-missing-payload-length-validation.txt | 64 + patches/2015-05/0001-NFC-Fix-payload-length-validation-in-NDEF-record-par.patch | 56 + patches/2015-05/incomplete-wps-and-p2p-nfc-ndef-record-payload-length-validation.txt | 87 ++ These look like they're fixes for security issues, but not either of the ones mentioned in the changelog. Hmmm, in fact they look like copies of already existing patches. For instance, this file: patches/2015-04/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch | 68 + appears to be a duplicate of: patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch |4 These don't appear to be security-related at all, nor mentioned in the changelog: patches/ap_config_c_fix-typo-for-capabilities.patch | 28 patches/fix-minor-issue-in-HT40-max-rate-determination.patch | 25 patches/fix-spelling-s-algorith-algorithm.patch | 25 patches/improve-BSS-selection-with-default-noise-floor-value.patch | 158 patches/select-AP-based-on-estimated-maximum-throughput.patch | 366 ++ patches/wpa_supplicant-Fix-a-typo-in-wpa_scan_result_compar.patch | 26 I realise that none of the above are actually enabled in debian/patches/series, but that makes it even more confusing that they're in the diff. Please prepare and test a package that contains only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and provide a debdiff of that. [ The current diff is 36 files changed, 1827 insertions(+), 14 deletions(-) As far as I can tell, the actual functional changes are: 8 files changed, 414 insertions(+) ] Regards, Adam
Bug#832001: pyenchant: new upstream release (1.6.7)
* Piotr Ożarowski , 2016-07-21, 11:28: thanks for the info. pypi.python.org and homepage¹ still don't have it, Good point. I'll ask upstream to upload to PyPI. -- Jakub Wilk
Bug#831991: The glossy shader displays reflections in black sometimes
I just downloaded and tried Blender version 2.77a from www.blender.org and can confirm that this bug affects the newest upstream version too. signature.asc Description: PGP signature
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 21/07/16 11:32, Adam D. Barratt wrote: > I realise that none of the above are actually enabled in > debian/patches/series, but that makes it even more confusing that > they're in the diff. Please prepare and test a package that contains > only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and > provide a debdiff of that. Oh, I'm very sorry, I think I have made a mistake while merging or diffing something. -- Cheers, Andrew signature.asc Description: OpenPGP digital signature
Bug#810890: caddy in Debian
Hello Nicolas, Zlatan, On Wed, Jul 20, 2016 at 10:12:06PM -0400, Nicolas Braud-Santoni wrote: Hi Zlatan, I'm taking the liberty to start packaging caddy and its dependencies, as part of the pkg-go team. I would be happy to see this package be co-maintained, though, whether it is by you or Iain. I am also interested in helping comaintaining caddy, I actually send a personal email to Zlatan earlier today about it. If we all agree that packaging caddy & co under pkg-go is the right thing to do, can you guys push your work to alioth pkg-go repositories?
Bug#820163: mh_resolve_dependencies exception when run with --non-interactive
Tags: patch
Patch as agreed with Emmanuel Bourg.
Test cases to be considered.
Christopher
diff --git a/maven-packager-utils/src/main/java/org/debian/maven/packager/util/IgnoreDependencyQuestions.java b/maven-packager-utils/src/main/java/org/debian/maven/packager/util/IgnoreDependencyQuestions.java
index e061a8d..33ab512 100644
--- a/maven-packager-utils/src/main/java/org/debian/maven/packager/util/IgnoreDependencyQuestions.java
+++ b/maven-packager-utils/src/main/java/org/debian/maven/packager/util/IgnoreDependencyQuestions.java
@@ -163,9 +163,12 @@ public class IgnoreDependencyQuestions {
}
private boolean askIgnoreDependency(String sourcePomLoc, Dependency dependency, String message, boolean defaultToIgnore) {
-if (!interactive || notIgnoredDependencies.contains(dependency)) {
+if (notIgnoredDependencies.contains(dependency)) {
return false;
}
+if (!interactive) {
+return defaultToIgnore;
+}
String question = "\n" + "In " + sourcePomLoc + ": " + message + " " + dependency;
boolean ignore = new YesNoQuestion(question, defaultToIgnore).ask();
if (!ignore) {
@@ -230,4 +233,4 @@ public class IgnoreDependencyQuestions {
return "";
}
}
-
\ No newline at end of file
+
Bug#831993: libcommons-codec-java: accesses the internet during build
I believe there is a control field for autopkgtest for this purpose. gregor herrmann wrote: > On Thu, 21 Jul 2016 11:19:46 +0200, Chris Lamb wrote: > > > > - by disabling them, even if they fail gracefully, in order to follow > > > policy, we effectively castrate the tests, which doesn't seem right > > > from a QA POV. > > Mm, agreed. Moving these tests to the autopkgtest infrastructure is one > > fix but it's not "that" clean a solution.. > > Well, right, autopkgtest is the next question. If a test is forbidden > to leak to external parties the fact that it's being run during > build, the same is probably true by analogy for autopkgtests? > > (Recently I disabled the same tests for both build + autopkgtests.) > > > Cheers, > gregor > > -- > .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 > : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ > `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe >`- BOFH excuse #211: Lightning strikes. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 21/07/16 11:37, Andrew Shadura wrote: > On 21/07/16 11:32, Adam D. Barratt wrote: >> > I realise that none of the above are actually enabled in >> > debian/patches/series, but that makes it even more confusing that >> > they're in the diff. Please prepare and test a package that contains >> > only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and >> > provide a debdiff of that. > Oh, I'm very sorry, I think I have made a mistake while merging or > diffing something. Right, those were left-overs from a previous cherry-picking attempt, untracked by Git. -- Cheers, Andrew signature.asc Description: OpenPGP digital signature
Bug#829272: Missing accessors
On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote: > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT: > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote: > > > > > > I guess having a more restrictive accessor that only sets the > > > EXFLAG_PROXY bit could work. I suggested the more general solution > > > of > > > having set/clear accessors for arbitrary flags since it was - well > > > more > > > general. > > > > So let me ask this in a different manner, does OpenSSL 1.1 still not > > set the > > EXFLAG_PROXY flag correctly? In what situations does that happen? > > That may be > > worth a bug report of its own. > > > > -- > > Richard Levitte > > levi...@openssl.org > > > > The answer to this is related to Mischa's reply, which unfortunately > was only sent to the Debian BTS and not the the OpenSSL RT. I quote it > below. As indicated in the answer, setting the EXFLAG_PROXY allows > handling non-RFC proxies in OpenSSL. > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle: > > Hi Richard, Mattias, others, > > > > I agree with you that it would be nice if OpenSSL could figure out > > itself whether a cert needs to be treated as a proxy, but currently > > that > > doesn't work reliably as far as I know. > > The flag is certainly needed in the case of non-RFC3820 proxies, also > > known as legacy proxies. Unfortunately these are still very widely > > used > > (majority of the proxies actually) and hence our code must be able to > > handle them correctly. > > > > Best wishes, > > Mischa Sallé > > Ok... From looking at the voms code that was linked to earlier, I can see that legacy proxy certs are recognised by an older OID (called PROXYCERTINFO_V3 in the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions in that version, whether they are critical or not and so on, that I can reach? Or is the OID the only actual difference? If it's easy enough (and it currently does look quite easy), I can certainly see adding some code in OpenSSL to recognise those... -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 21/07/16 11:42, Andrew Shadura wrote:
> On 21/07/16 11:37, Andrew Shadura wrote:
>> On 21/07/16 11:32, Adam D. Barratt wrote:
I realise that none of the above are actually enabled in
debian/patches/series, but that makes it even more confusing that
they're in the diff. Please prepare and test a package that contains
only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and
provide a debdiff of that.
I have redone the package, tested it and generated a debdiff.
--
Cheers,
Andrew
diff -Nru wpa-2.3/debian/changelog wpa-2.3/debian/changelog
--- wpa-2.3/debian/changelog2015-11-07 16:07:28.0 +0100
+++ wpa-2.3/debian/changelog2016-07-21 11:42:28.0 +0200
@@ -1,3 +1,17 @@
+wpa (2.3-1+deb8u4) jessie-security; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patches to address CVE-2016-4476 and CVE-2016-4477, thanks to
+Salvatore Bonaccorso (Closes: #823411):
+- WPS: Reject a Credential with invalid passphrase
+- Reject psk parameter set with invalid passphrase character
+- Remove newlines from wpa_supplicant config network output
+- Reject SET_CRED commands with newline characters in the string values
+- Reject SET commands with newline characters in the string values
+ * Refresh patches to apply cleanly.
+
+ -- Andrew Shadura Thu, 21 Jul 2016 09:01:51 +0200
+
wpa (2.3-1+deb8u3) jessie-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru
wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
---
wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
2015-11-07 16:07:28.0 +0100
+++
wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
2016-07-21 11:42:28.0 +0200
@@ -25,7 +25,7 @@
index f2b0926..a629437 100644
--- a/src/eap_peer/eap_pwd.c
+++ b/src/eap_peer/eap_pwd.c
-@@ -355,6 +355,23 @@ eap_pwd_perform_commit_exchange(struct eap_sm *sm, struct
eap_pwd_data *data,
+@@ -301,6 +301,23 @@
BIGNUM *mask = NULL, *x = NULL, *y = NULL, *cofactor = NULL;
u16 offset;
u8 *ptr, *scalar = NULL, *element = NULL;
@@ -49,7 +49,7 @@
if (((data->private_value = BN_new()) == NULL) ||
((data->my_element = EC_POINT_new(data->grp->group)) == NULL) ||
-@@ -554,6 +571,18 @@ eap_pwd_perform_confirm_exchange(struct eap_sm *sm,
struct eap_pwd_data *data,
+@@ -500,6 +517,18 @@
u8 conf[SHA256_MAC_LEN], *cruft = NULL, *ptr;
int offset;
diff -Nru
wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
---
wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
2015-11-07 16:07:28.0 +0100
+++
wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
2016-07-21 11:42:28.0 +0200
@@ -25,7 +25,7 @@
index 66bd5d2..3189105 100644
--- a/src/eap_server/eap_server_pwd.c
+++ b/src/eap_server/eap_server_pwd.c
-@@ -656,9 +656,21 @@ eap_pwd_process_commit_resp(struct eap_sm *sm, struct
eap_pwd_data *data,
+@@ -634,9 +634,21 @@
BIGNUM *x = NULL, *y = NULL, *cofactor = NULL;
EC_POINT *K = NULL, *point = NULL;
int res = 0;
@@ -47,7 +47,7 @@
if (((data->peer_scalar = BN_new()) == NULL) ||
((data->k = BN_new()) == NULL) ||
((cofactor = BN_new()) == NULL) ||
-@@ -774,6 +786,13 @@ eap_pwd_process_confirm_resp(struct eap_sm *sm, struct
eap_pwd_data *data,
+@@ -752,6 +764,13 @@
u8 conf[SHA256_MAC_LEN], *cruft = NULL, *ptr;
int offset;
diff -Nru
wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
---
wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
2015-11-07 16:07:28.0 +0100
+++
wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
2016-07-21 11:42:28.0 +0200
@@ -23,7 +23,7 @@
index a629437..1d2079b 100644
--- a/src/eap_peer/eap_pwd.c
+++ b/src/eap_peer/eap_pwd.c
-@@ -866,11 +866,23 @@ eap_pwd_process(struct eap_sm *sm, void *priv, struct
eap_method_ret *ret,
+@@ -812,11 +812,23 @@
* if it's the first fragment there'll be a length field
*/
if (EAP_PWD_GET_LENGTH_BIT(lm_exch)) {
diff -Nru
wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
---
wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-
Bug#832008: man page layout is broken
Package: opensmtpd Version: 5.9.2p1-1 The layout of smtpd.conf(5) appears to be broken, compared with the man page on openBSD. Sample: for [ !] domain domain [ alias < aliases >] This rule applies to mail destined for the specified domain. This parameter supports the Sq * wildcard, so that a single rule for all sub-domains can be used, for example: accept for domain "*.example.com" deliver to mbox If specified, the table aliases is used for looking up alternative destinations for addresses in this domain. On openBSD it looks like this for [!] domain domain [alias ] This rule applies to mail destined for the specified domain. This parameter supports the `*' wildcard, so that a single rule for all sub-domains can be used, for example: accept for domain "*.example.com" deliver to mbox If specified, the table aliases is used for looking up alternative destinations for addresses in this domain. Bold text is not shown here. Hopefully the samples are not too much corrupted by EMail. Please note the additional line breaks on Debian, macros showing up and the broken indentation at the end of the sample. OpenBSD's man page can be read on http://man.openbsd.org/OpenBSD-current/man5/smtpd.conf.5 as well. Regards Harri
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Control: tags -1 -moreinfo +confirmed [CCing -boot@ and kibi for reference, as wpa produces a udeb. The fixes look "obviously correct" enough to me] On 2016-07-21 10:51, Andrew Shadura wrote: On 21/07/16 11:42, Andrew Shadura wrote: On 21/07/16 11:37, Andrew Shadura wrote: On 21/07/16 11:32, Adam D. Barratt wrote: I realise that none of the above are actually enabled in debian/patches/series, but that makes it even more confusing that they're in the diff. Please prepare and test a package that contains only the changes relating to fixing CVE-2016-4476 and CVE-2016-4477 and provide a debdiff of that. I have redone the package, tested it and generated a debdiff. That looks much better, thanks. :-) +wpa (2.3-1+deb8u4) jessie-security; urgency=medium The distribution there should be "jessie" (and was in the earlier diff). With that changed, please feel free to go ahead. Regards, Adam
Bug#826430: maven-debian-helper: mh_make is always verbose, even when -v|--verbose is not specified
Tags: patch
Patch to remove mandatory --verbose option.
Christopher
diff --git a/bin/mh_make b/bin/mh_make
index 50596d4..cab6495 100755
--- a/bin/mh_make
+++ b/bin/mh_make
@@ -188,7 +188,7 @@ if [ -f debian/patches/series ]; then
fi
echo
-java -cp /usr/share/java/maven-project.jar:/usr/share/java/maven-repo-helper.jar:/usr/share/java/maven-packager-utils.jar:/usr/share/maven2/lib/maven-debian-uber.jar org.debian.maven.packager.DependenciesSolver --verbose --package="$BIN_PACKAGE" ${ANT:+--ant} ${GEN_JAVADOC:+--generate-javadoc} ${RUN_TESTS:+--run-tests} ${VERBOSE:+--verbose} --maven-repo=/usr/share/maven-repo
+java -cp /usr/share/java/maven-project.jar:/usr/share/java/maven-repo-helper.jar:/usr/share/java/maven-packager-utils.jar:/usr/share/maven2/lib/maven-debian-uber.jar org.debian.maven.packager.DependenciesSolver --package="$BIN_PACKAGE" ${ANT:+--ant} ${GEN_JAVADOC:+--generate-javadoc} ${RUN_TESTS:+--run-tests} ${VERBOSE:+--verbose} --maven-repo=/usr/share/maven-repo
if [ $? != 0 ]; then
if [ -f debian/patches/series ]; then
Bug#829272: Missing accessors
On Mon, Jul 11, 2016 at 02:53:05PM +0200, Mischa Salle wrote: > Hi Richard, Mattias, others, > > I agree with you that it would be nice if OpenSSL could figure out > itself whether a cert needs to be treated as a proxy, but currently that > doesn't work reliably as far as I know. > The flag is certainly needed in the case of non-RFC3820 proxies, also > known as legacy proxies. Unfortunately these are still very widely used > (majority of the proxies actually) and hence our code must be able to > handle them correctly. Is there a way to recoginize those non-RFC3820 proxies? Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted
Bug#829272: [Pkg-openssl-devel] Bug#829272: Fwd: [openssl.org #4602] Missing accessors
On Mon, Jul 11, 2016 at 02:53:05PM +0200, Mischa Salle wrote: > Hi Richard, Mattias, others, > > I agree with you that it would be nice if OpenSSL could figure out > itself whether a cert needs to be treated as a proxy, but currently that > doesn't work reliably as far as I know. > The flag is certainly needed in the case of non-RFC3820 proxies, also > known as legacy proxies. Unfortunately these are still very widely used > (majority of the proxies actually) and hence our code must be able to > handle them correctly. Is there a way to recoginize those non-RFC3820 proxies? Kurt
Bug#826430: maven-debian-helper: mh_make is always verbose, even when -v|--verbose is not specified
Package: maven-debian-helper Version: 2.1.1 Followup-For: Bug #826430 Tags: patch
Bug#831971: fortunes-es: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute
21 July 2016 at 01:21, Santiago Vila wrote: > This happens because debian/rules has its binary-indep and binary-arch > targets swapped: binary-indep does nothing (hence the error) and > binary-arch does what binary-indep should do. > > The fix is trivial. See attach. > Thanks for the patch, but I'm actually going to redo debian/rules and use debhelper instead. That is more maintenable in the long run. > While we are at it: Javier: The Maintainer field in debian/control has > been converted from latin1 to utf8 *twice*. Try this and you will see > what I mean: > Yes, noted. Will fix. Regards Javier
Bug#831240: google-perftools: FTBFS: Running death test 0 hangs
severity 831240 important reopen 831240 On Thu, 21 Jul 2016, Lucas Nussbaum wrote: > I recently discovered that the official Debian images on AWS EC2 include > some sysctl tunings (see > https://github.com/andsens/bootstrap-vz/pull/256/commits/06da309895f69573996a4c1ff027f999155b876b#diff-43081b58ccf1565f80325d26c36d7c57R18 > ) > > It seems that one of those caused that failure, because, now that I have > them disabled, it does not fail anymore. > > I'm closing this bug, sorry for the noise. Hmm. Failure to build from source is still a bug. Ok, some people do not consider a FTBFS to be serious if the failure does not happen in the official buildds, but this fact should only make the bug non-RC, not make it a non-bug. OTOH, if there is really a good reason to fail in this non-standard environment, then the bug should be reassigned to whatever package setups the non-standard environment (bootstrap-vz?), not just closed. Thanks.
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
Control: tags -1 +moreinfo -confirmed On 2016-07-21 11:01, Adam D. Barratt wrote: Control: tags -1 -moreinfo +confirmed [...] +wpa (2.3-1+deb8u4) jessie-security; urgency=medium The distribution there should be "jessie" (and was in the earlier diff). With that changed, please feel free to go ahead. Actually, hold on that. It was just pointed out to me that the patches aren't in unstable yet - that needs to happen first. Regards, Adam
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 21/07/16 12:19, Adam D. Barratt wrote: > > On 2016-07-21 11:01, Adam D. Barratt wrote: >> Control: tags -1 -moreinfo +confirmed > [...] >> +wpa (2.3-1+deb8u4) jessie-security; urgency=medium >> >> The distribution there should be "jessie" (and was in the earlier >> diff). With that changed, please feel free to go ahead. > > Actually, hold on that. It was just pointed out to me that the patches > aren't in unstable yet - that needs to happen first. Okay. The maintainer has done some work in the VCS, but it doesn't seem ready for upload yet, and he hasn't committed anything since May. Should I put an NMU with just these patches into DELAYED queue? (Stefan Cc-ed.) -- Cheers, Andrew signature.asc Description: OpenPGP digital signature
Bug#832009: pyew: new homepage
Package: pyew Version: 2.0-3 Severity: normal https://lintian.debian.org/maintainer/en...@debian.org.html#pyew Please update homepage from http://code.google.com/p/pyew to https://github.com/joxeankoret/pyew thank you. -- Henri Salo
Bug#832010: Please enable LZ4 compression
Package: systemd-coredump Version: 230-7 Severity: wishlist LZ4 compression makes a huge difference in terms of performance impact when compressing core files, but it's currently not enabled (I guess due to missing LZ4 dependency?). LZ4 is the default compression method according to upstream since systemd 229. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-coredump depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libc62.23-2 ii libdw1 0.165-3 ii libelf1 0.165-3 ii systemd 230-7 systemd-coredump recommends no packages. systemd-coredump suggests no packages.
Bug#832011: ncl: FTBFS with -fdebug-prefix-map
Source: ncl Version: 6.3.0-8 Severity: important User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear maintainer, your package FTBFS when dpkg enables the build flag -fdebug-prefix-map from the reproducible/fixdebugpath feature area: debian/rules build dh build dh_testdir dh_update_autotools_config debian/rules override_dh_auto_configure make[1]: Entering directory '/build/ncl-6.3.0' sed -e 's,@LIBDIR@,/usr/lib/x86_64-linux-gnu,' \ -e 's/@PREFIX@/\/usr/' \ -e 's/@VERSION@/6.3.0/' \ < debian/ncarg.pc.in > ncarg.pc sed -e 's/@CC@/cc/' \ -e 's/@FC@/gfortran/' \ -e 's/@LD@/cc/' \ -e 's:@CFLAGS@:-g -O2 -fdebug-prefix-map=/build/ncl-6.3.0=. -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/hdf5/serial:' \ -e 's/@FFLAGS@/-g -O2 -fdebug-prefix-map=/build/ncl-6.3.0=. -fstack-protector-strong/' \ -e 's/@CPPFLAGS@/-Wdate-time -D_FORTIFY_SOURCE=2/' \ -e 's/@LDFLAGS@//' \ -e 's%@DESTDIR@%/build/ncl-6.3.0/debian/tmp/%' \ < debian/Site.local.shared.in > config/Site.local.shared sed: -e expression #5, char 39: unknown option to `s' debian/rules:47: recipe for target 'override_dh_auto_configure' failed make[1]: *** [override_dh_auto_configure] Error 1 make[1]: Leaving directory '/build/ncl-6.3.0' debian/rules:7: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Please note that the intention is to enable this build flag RSN https://lists.debian.org/msgid-search/20160718085659.gi7...@chase.mapreri.org A quick workaround would be to disable the reproducible/fixdebugpath buildflags with export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixdebugpath A possibly more proper fix would be to use a different separator than /, like it's done with @CFLAGS@. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#832012: clonalframe: FTBFS with -fdebug-prefix-map
Source: clonalframe Version: 1.2-4 Severity: important User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear maintainer, your package FTBFS when dpkg enables the build flag -fdebug-prefix-map from the reproducible/fixdebugpath feature area: debian/rules build dh build dh_testdir dh_update_autotools_config dh_auto_configure qmake -makefile -nocache "QMAKE_CFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/build/clonalframe-1.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/build/clonalframe-1.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/build/clonalframe-1.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/build/clonalframe-1.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: PREFIX=/usr debian/rules override_dh_auto_build make[1]: Entering directory '/build/clonalframe-1.2' qmake # did not found a better way to push hardening flags into Makefile sed -i -e "s/CFLAGS *= .*/& -g -O2 -fdebug-prefix-map=/build/clonalframe-1.2=. -fstack-protector-strong -Wformat -Werror=format-security/" \ -e "s/CXXFLAGS *= .*/& -g -O2 -fdebug-prefix-map=/build/clonalframe-1.2=. -fstack-protector-strong -Wformat -Werror=format-security/" \ -e "s/LFLAGS *= .*/& -Wl,-z,relro/" Makefile sed: -e expression #1, char 45: unknown option to `s' debian/rules:17: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 1 make[1]: Leaving directory '/build/clonalframe-1.2' debian/rules:10: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Please note that the intention is to enable this build flag RSN https://lists.debian.org/msgid-search/20160718085659.gi7...@chase.mapreri.org A quick workaround would be to disable the reproducible/fixdebugpath buildflags with export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixdebugpath A possibly more proper fix would be to use a different separator than /, for example : or #. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#828069: icedove: random crashes after latest security update
Here is the backtrace with sigpipe ignored: Program received signal SIGSEGV, Segmentation fault. js::jit::BaselineScript::icEntryFromPCOffset (this=, pcOffset=32767) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jit/BaselineJIT.cpp:649 649 /build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/jit/BaselineJIT.cpp: No such file or directory. (gdb) thread apply all bt Thread 147 (Thread 0x7fffb46ff700 (LWP 30701)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 #1 0x764b12c8 in pt_TimedWait (cv=cv@entry=0x7fffe0c23148, ml=0x7fffe74f97f0, timeout=timeout@entry=3) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:264 #2 0x764b17de in PR_WaitCondVar (cvar=0x7fffe0c23140, timeout=3) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:398 #3 0x7094d6c5 in mozilla::CondVar::Wait (aInterval=aInterval@entry=3, this=0x7fffe7448ae0) at ../../dist/include/mozilla/CondVar.h:79 #4 0x7095296c in Wait (aInterval=3, this=0x7fffe7448ac8) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/xpcom/threads/nsEventQueue.h:104 #5 nsThreadPool::Run (this=0x7fffe7448aa0) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/xpcom/threads/nsThreadPool.cpp:217 #6 0x709542b0 in nsThread::ProcessNextEvent (this=0x7fffca7c7300, aMayWait=, aResult=0x7fffb46fedd7) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/xpcom/threads/nsThread.cpp:972 #7 0x7096e9e1 in NS_ProcessNextEvent (aThread=, aMayWait=aMayWait@entry=false) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/xpcom/glue/nsThreadUtils.cpp:297 #8 0x70b4ea73 in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0x7fffacbfc280, aDelegate=0x7fffc3d066e0) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/ipc/glue/MessagePump.cpp:326 #9 0x70b3ecdb in RunHandler (this=0x7fffc3d066e0) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/ipc/chromium/src/base/message_loop.cc:227 #10 MessageLoop::Run (this=this@entry=0x7fffc3d066e0) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/ipc/chromium/src/base/message_loop.cc:201 #11 0x709569e2 in nsThread::ThreadFunc (aArg=0x7fffca7c7300) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/xpcom/threads/nsThread.cpp:376 #12 0x764b7178 in _pt_root (arg=0x7fffc620f700) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/nsprpub/pr/src/pthreads/ptthread.c:216 #13 0x77bc70a4 in start_thread (arg=0x7fffb46ff700) at pthread_create.c:309 #14 0x76ed687d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 146 (Thread 0x7fffaa5fd700 (LWP 30698)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 #1 0x764b12c8 in pt_TimedWait (cv=cv@entry=0x7fffe74f78c8, ml=0x7fffe74f9060, timeout=timeout@entry=30) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:264 #2 0x764b17de in PR_WaitCondVar (cvar=0x7fffe74f78c0, timeout=30) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:398 #3 0x709e9730 in Wait (this=0x76b6d0b0, aInterval=30) at ../../dist/include/mozilla/CondVar.h:79 #4 nsHostResolver::GetHostToLookup (this=this@entry=0x76b6d090, result=result@entry=0x7fffaa5fce70) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/netwerk/dns/nsHostResolver.cpp:1163 #5 0x709e9c66 in nsHostResolver::ThreadFunc (arg=0x76b6d090) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/netwerk/dns/nsHostResolver.cpp:1391 #6 0x764b7178 in _pt_root (arg=0x7fffc620f5e0) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/nsprpub/pr/src/pthreads/ptthread.c:216 #7 0x77bc70a4 in start_thread (arg=0x7fffaa5fd700) at pthread_create.c:309 #8 0x76ed687d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 145 (Thread 0x7fffaadfe700 (LWP 30697)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 #1 0x764b12c8 in pt_TimedWait (cv=cv@entry=0x7fffe74f78c8, ml=0x7fffe74f9060, timeout=timeout@entry=30) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:264 #2 0x764b17de in PR_WaitCondVar (cvar=0x7fffe74f78c0, timeout=30) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:398 #3 0x709e9730 in Wait (this=0x76b6d0b0, aInterval=30) at ../../dist/include/mozilla/CondVar.h:79 #4 nsHostResolver::GetHostToLookup (this=this@entry=0x76b6d090, result=result@entry=0x7fffaadfde70) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/netwerk/dns/nsHostResolver.cpp:1163 #5 0x709e9c66 in nsHostResolver::ThreadFunc (arg=0x76b6d090) at /bui
Bug#832013: clustalx: FTBFS with -fdebug-prefix-map
Source: clustalx Version: 2.1+lgpl-4 Severity: important User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear maintainer, your package FTBFS when dpkg enables the build flag -fdebug-prefix-map from the reproducible/fixdebugpath feature area: debian/rules build dh build dh_testdir dh_update_autotools_config debian/rules override_dh_auto_configure make[1]: Entering directory '/build/clustalx-2.1+lgpl' qmake-qt4 # did not found a better way to push hardening flags into Makefile sed -i -e "s/CFLAGS *= .*/& -g -O2 -fdebug-prefix-map=/build/clustalx-2.1+lgpl=. -fstack-protector-strong -Wformat -Werror=format-security/" \ -e "s/CXXFLAGS *= .*/& -g -O2 -fdebug-prefix-map=/build/clustalx-2.1+lgpl=. -fstack-protector-strong -Wformat -Werror=format-security/" \ -e "s/LFLAGS *= .*/& -Wl,-z,relro/" Makefile sed: -e expression #1, char 45: unknown option to `s' debian/rules:6: recipe for target 'override_dh_auto_configure' failed make[1]: *** [override_dh_auto_configure] Error 1 make[1]: Leaving directory '/build/clustalx-2.1+lgpl' debian/rules:3: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 A quick workaround would be to disable the reproducible/fixdebugpath buildflags with export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixdebugpath A possibly more proper fix would be to use a different separator than /, like : or #. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4
On 2016-07-21 11:25, Andrew Shadura wrote: On 21/07/16 12:19, Adam D. Barratt wrote: On 2016-07-21 11:01, Adam D. Barratt wrote: Control: tags -1 -moreinfo +confirmed [...] +wpa (2.3-1+deb8u4) jessie-security; urgency=medium The distribution there should be "jessie" (and was in the earlier diff). With that changed, please feel free to go ahead. Actually, hold on that. It was just pointed out to me that the patches aren't in unstable yet - that needs to happen first. Okay. The maintainer has done some work in the VCS, but it doesn't seem ready for upload yet, and he hasn't committed anything since May. Should I put an NMU with just these patches into DELAYED queue? (Stefan Cc-ed.) No preference from the SRM side. When / how the patches get applied in unstable is mostly irrelevant for us, it just needs to happen before we'll accept them for stable. Regards, Adam
Bug#412185: Multiple RC issues identified in atftpd
Control: tags -1 + patch
[Ludovic Drolez]
> Yes proper auto-configuration of this package is a nightmare, maybe the
> better is to drop all auto-config and suggest people to manually
> configure it.
Probably not. Here is a draft patch (untested) which make sure the
atftpd.config script load the current settings from /etc/ before
asking during installation and upgrades, to ensure the current
settings on disk do not change.
I'm a but unsure how robust the inetd option loading is, but suspect it
should work. I disabled the rewrite of /etc/logrotate.d/atftpd, as I am not
quite sure how to do that best. It might be good to print a warning if the
log file name is changed.
--
Happy hacking
Petter Reinholdtsen
diff --git a/debian/atftpd.config b/debian/atftpd.config
index 46acf03..b19ae22 100644
--- a/debian/atftpd.config
+++ b/debian/atftpd.config
@@ -3,6 +3,46 @@
. /usr/share/debconf/confmodule
db_version 2.0
+opts2debconf() {
+while "$1" ; do
+ case "$opt" in
+ --daemon) ;;
+ --port) db_set atftpd/port "$2"; shift ;;
+ --tftpd-timeout) db_set atftpd/tftpd-timeout "$2"; shift ;;
+--retry-timeout) db_set atftpd/retry-timeout "$2"; shift ;;
+--maxthread) db_set atftpd/maxthread "$2"; shift ;;
+ --no-timeout)db_set atftpd/timeout "false"; shift ;;
+ --no-tsize) db_set atftpd/tsize "false"; shift ;;
+ --no-blksize)db_set atftpd/blksize "false"; shift ;;
+ --no-multicast) db_set atftpd/multicast "false"; shift ;;
+ --mcast-port)db_set atftpd/mcast_port "$2"; shift ;;
+ --mcast-addr)db_set atftpd/mcast_addr "$2"; shift ;;
+ --mcast-ttl) db_set atftpd/ttl "$2"; shift ;;
+ --verbose=*)
+ db_set atftpd/verbosity $(echo "$1" | cut -d= -f2-)
+ ;;
+ --logfile)
+ db_set atftpd/logtofile true
+ db_set atftpd/logfile "$2"
+ ;;
+ /*) db_set atftpd/basedir "$1" ;;
+ esac
+ shift
+done
+}
+
+# Load current settings from file
+if [ -f /etc/default/atftpd ]; then
+. /etc/default/atftpd
+db_set atftpd/use_inetd "$USE_INETD"
+if [ "$USE_INETD" = "false" ]; then
+ opts2debconf $OPTIONS
+else
+ # FIXME should work with xinetd too
+ INETOPTS="$(grep /usr/sbin/in.tftpd /etc/inetd.conf | sed 's%.*/usr/sbin/in.tftpd %%')"
+ opts2debconf $INETOPTS
+fi
+fi
# Do not ask if you need to configure atftp (Bug#266329)
#db_beginblock
diff --git a/debian/atftpd.postinst b/debian/atftpd.postinst
index 6a8d0cc..c07dbc6 100644
--- a/debian/atftpd.postinst
+++ b/debian/atftpd.postinst
@@ -94,8 +94,9 @@ db_version 2.0
chown nobody:nogroup $RET
chmod 640 $RET
fi
- # modify the logrotate file
- cat >/etc/logrotate.d/atftpd
Bug#832014: libclc: FTBFS with -fdebug-prefix-map
Source: libclc Version: 0.2.0+git20150813-2 Severity: important User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Control: block -1 by 819185 Dear maintainer, your package FTBFS when dpkg enables the build flag -fdebug-prefix-map from the reproducible/fixdebugpath feature area: dh binary --parallel dh_testdir -O--parallel dh_update_autotools_config -O--parallel debian/rules override_dh_auto_configure make[1]: Entering directory '/build/libclc-0.2.0+git20150813' ./configure.py --prefix=/usr --with-llvm-config=/usr/bin/llvm-config-3.7 make[1]: Leaving directory '/build/libclc-0.2.0+git20150813' dh_auto_build -O--parallel make -j18 make[1]: Entering directory '/build/libclc-0.2.0+git20150813' /usr/lib/llvm-3.7/bin/llvm-as -o generic--/lib/subnormal_disable.bc generic/lib/subnormal_disable.ll /usr/lib/llvm-3.7/bin/llvm-as -o generic--/lib/subnormal_use_default.bc generic/lib/subnormal_use_default.ll /usr/lib/llvm-3.7/bin/clang -MMD -MF nvptx--nvidiacl/lib/synchronization/barrier.cl.bc.d -target nvptx--nvidiacl -I`dirname ./ptx-nvidiacl/lib/synchronization/barrier.cl` -I./generic/include -fno-builtin -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 -D__CLC_INTERNAL -emit-llvm -g -O2 -fdebug-prefix-map=/build/libclc-0.2.0+git20150813=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -c -o nvptx--nvidiacl/lib/synchronization/barrier.cl.bc ./ptx-nvidiacl/lib/synchronization/barrier.cl /usr/lib/llvm-3.7/bin/clang -MMD -MF nvptx--nvidiacl/lib/workitem/get_group_id.cl.bc.d -target nvptx--nvidiacl -I`dirname ./ptx-nvidiacl/lib/workitem/get_group_id.cl` -I./generic/include -fno-builtin -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 -D__CLC_INTERNAL -emit-llvm -g -O2 -fdebug-prefix-map=/build/libclc-0.2.0+git20150813=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -c -o nvptx--nvidiacl/lib/workitem/get_group_id.cl.bc ./ptx-nvidiacl/lib/workitem/get_group_id.cl /usr/lib/llvm-3.7/bin/clang -MMD -MF nvptx--nvidiacl/lib/workitem/get_local_id.cl.bc.d -target nvptx--nvidiacl -I`dirname ./ptx-nvidiacl/lib/workitem/get_local_id.cl` -I./generic/include -fno-builtin -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 -D__CLC_INTERNAL -emit-llvm -g -O2 -fdebug-prefix-map=/build/libclc-0.2.0+git20150813=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -c -o nvptx--nvidiacl/lib/workitem/get_local_id.cl.bc ./ptx-nvidiacl/lib/workitem/get_local_id.cl /usr/lib/llvm-3.7/bin/clang -MMD -MF nvptx--nvidiacl/lib/workitem/get_local_size.cl.bc.d -target nvptx--nvidiacl -I`dirname ./ptx-nvidiacl/lib/workitem/get_local_size.cl` -I./generic/include -fno-builtin -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 -D__CLC_INTERNAL -emit-llvm -g -O2 -fdebug-prefix-map=/build/libclc-0.2.0+git20150813=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -c -o nvptx--nvidiacl/lib/workitem/get_local_size.cl.bc ./ptx-nvidiacl/lib/workitem/get_local_size.cl /usr/lib/llvm-3.7/bin/clang -MMD -MF nvptx--nvidiacl/lib/workitem/get_num_groups.cl.bc.d -target nvptx--nvidiacl -I`dirname ./ptx-nvidiacl/lib/workitem/get_num_groups.cl` -I./generic/include -fno-builtin -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 -D__CLC_INTERNAL -emit-llvm -g -O2 -fdebug-prefix-map=/build/libclc-0.2.0+git20150813=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -c -o nvptx--nvidiacl/lib/workitem/get_num_groups.cl.bc ./ptx-nvidiacl/lib/workitem/get_num_groups.cl /usr/lib/llvm-3.7/bin/llvm-as -o nvptx--nvidiacl/lib/integer/add_sat.ll.bc ./ptx/lib/integer/add_sat.ll /usr/lib/llvm-3.7/bin/llvm-as -o nvptx--nvidiacl/lib/integer/sub_sat.ll.bc ./ptx/lib/integer/sub_sat.ll /usr/lib/llvm-3.7/bin/clang -MMD -MF nvptx--nvidiacl/lib/subnormal_config.cl.bc.d -target nvptx--nvidiacl -I`dirname ./generic/lib/subnormal_config.cl` -I./generic/include -fno-builtin -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 -D__CLC_INTERNAL -emit-llvm -g -O2 -fdebug-prefix-map=/build/libclc-0.2.0+git20150813=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -c -o nvptx--nvidiacl/lib/subnormal_config.cl.bc ./generic/lib/subnormal_config.cl clang: error: unknown argument: '-fdebug-prefix-map=/build/libclc-0.2.0+git20150813=.' /usr/lib/llvm-3.7/bin/llvm-as -o nvptx--nvidiacl/lib/subnormal_helper_func.ll.bc ./generic/lib/subnormal_helper_func.ll clang: error: unknown argument: '-fdebug-prefix-map=/build/libclc-0.2.0+git20150813=.' clang: error: unknown argument: '-fdebug-prefix-map=/build/libclc-0.2.0+git20150813=.' clang: error: unknown argument: '-fdebug-prefix-map=/build/libclc-0.2.0+git20150813=.' clang: error: unknown argument: '-fdebug-prefix-map=/build/libclc-0.2.0+git20150813=.' /usr/lib/llvm-3.7/bin/clang -MMD -MF nvptx--nvidiacl/lib/async/async_work_g
Bug#810890: caddy in Debian
Hi Both, On 21/07/16 05:32, Zlatan Todoric wrote: >> I would be happy to see this package be co-maintained, though, >> whether it is by you or Iain. Thanks for working on this. I'll leave this to you, I don't think I would be adding anything to this effort if I were to be involved. Thanks, Iain.
Bug#786425: libupower-glib3: gnome fails with segfault error 4 in libupower-glib.so.3.0.0
Package: libupower-glib3 Version: 0.99.4-3 Followup-For: Bug #786425 I just upgraded from testing to unstable and I'm seeing this problem, it completely prevents me from configuring power management in the cinnamon desktop. dmesg shows segfaults: [ 5200.121092] python2[26522]: segfault at 0 ip 7f00cf9ca0d5 sp 7ffce5390bb8 error 4 in libupower-glib.so.3.0.1[7f00cf9be000+25000] [ 5327.606479] python2[26550]: segfault at 0 ip 7fb15316a0d5 sp 7ffcc4753238 error 4 in libupower-glib.so.3.0.1[7fb15315e000+25000] Regards, Stephen Quinney -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libupower-glib3 depends on: ii libc6 2.23-2 ii libglib2.0-0 2.48.1-2 Versions of packages libupower-glib3 recommends: ii upower 0.99.4-3 libupower-glib3 suggests no packages. -- no debconf information
Bug#832015: libblocksruntime: FTBFS with -fdebug-prefix-map
Source: libblocksruntime
Version: 0.4.1-1
Version: 1.302-1
Severity: important
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Control: block -1 by 819185
Dear maintainer, your package FTBFS when dpkg enables the build flag
-fdebug-prefix-map from the reproducible/fixdebugpath feature area:
debian/rules build
dh build
dh_testdir
dh_update_autotools_config
dh_auto_configure
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking for clang... clang
checking whether the C compiler works... no
configure: error: in `/build/libblocksruntime-0.4.1':
configure: error: C compiler cannot create executables
See `config.log' for more details
"tail -v -n +0 config.log"
[...]
configure:2264: checking whether the C compiler works
configure:2286: clang -g -O2 -fdebug-prefix-map=/build/libblocksruntime-0.4.1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c >&5
clang: error: unknown argument:
'-fdebug-prefix-map=/build/libblocksruntime-0.4.1=.'
configure:2290: $? = 1
configure:2328: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libBlocksRuntime"
| #define PACKAGE_TARNAME "libblocksruntime"
| #define PACKAGE_VERSION "0.4.1"
| #define PACKAGE_STRING "libBlocksRuntime 0.4.1"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2333: error: in `/build/libblocksruntime-0.4.1':
configure:2335: error: C compiler cannot create executables
Please note that the intention is to enable this build flag RSN
https://lists.debian.org/msgid-search/20160718085659.gi7...@chase.mapreri.org
A quick workaround would be to disable the reproducible/fixdebugpath
buildflags with
export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixdebugpath
The real problem here is that clang 3.7 doesn't support
-fdebug-prefix-map, whilst 3.8 does. See the blocking bug for more
information. You might either want to wait for clang to either switch
to 3.8 or backport the patch, or to workaround it by disabling the
buildflag.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#814905: liblog4cplus-1.1-9: C++11 methods missing from the binary
Control: severity -1 critical Control: block 831118 by -1 [Sorin Manolache] > Package: liblog4cplus-1.1-9 > Version: 1.1.2-3.1 > Severity: normal > > Dear Maintainer, > > The c++11-specific methods -- such as log4cplus::Logger(Logger&&) -- are not > compiled in the package. > > It suffices to rebuild the package with -std=c++11 appended to the CXXFLAGS. This causes a build failure with openalpr and GCC 6, see https://bugs.debian.org/831118 >. Setting the severity to critical, as it block openalpr from entering testing (ie make unrelated software fail to work). -- Happy hacking Petter Reinholdtsen
debian-bugs-dist@lists.debian.org
[Petter Reinholdtsen] > As far as I can see, this can not be fixed in openalpr, but must be fixed in > liblog4cplus. Perhaps this bug should be reassigned? No need, as it is already reported as bug #814905. -- Happy hacking Petter Reinholdtsen
Bug#832016: import-orig: merge into Debian branch instead of current branch
Package: git-buildpackage Version: 0.8.1 Severity: normal gbp import-orig would currently always merge into the current working copy instead of switching to the Debian branch first. This defeats proper rollback makes giving the branch to merge to impossible. This does not affect --merge-mode=replace -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-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) Versions of packages git-buildpackage depends on: ii devscripts2.16.6 ii git 1:2.8.1-1 ii man-db2.7.5-1 ii python-dateutil 2.4.2-1 ii python-pkg-resources 20.10.1-1.1 ii python-six1.10.0-3 pn python:any Versions of packages git-buildpackage recommends: ii cowbuilder 0.80 ii pbuilder 0.225.1 ii pristine-tar 1.34 ii python-requests 2.10.0-2 ii sbuild 0.69.0-2 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-4 ii sudo 1.8.17p1-2 ii unzip 6.0-20 -- no debconf information
Bug#805955: [pcp] Bug#805955: pcp: FTBFS when built with dpkg-buildpackage -A (no binary artifacts)
On Wed, 20 Jul 2016, Nathan Scott wrote: > > > Actually some advice would be great, having had an initial look into > > > this one now. Patch below shows the basic split we'll need to make > > > the architecture independent packages generated separately, but I'm > > > not sure how to fit that split into the rest of the rules file (I get > > > the same sort of errors with a change like this in place no matter > > > what I try - maybe its obvious to someone more deb knowledgeable?). > > > > I have not tested the patch but I see why it would not work. > > > > Try putting "dh_builddeb" somewhere in binary-indep, otherwise the > > actual .deb packages will not be created. > > > > Thanks. > > > > Taa. I see problems in the binary-indep target before the build reaches > that stage though. The debian/rules uses dh_install(1) - in particular, > it relies on this behaviour from the man page... > > On the other hand, maybe you have a large package that builds > multiple binary packages. You can use the upstream Makefile to > install it all into debian/tmp, and then use dh_install to copy > directories and files from there into the proper package build > directories. > > And dh_install fails when used by the binary-indep target - it requires > files from both binary-indep and binary-arch, I think. That should not happen unless you are creating packages that have to conflict at each other because they contain the same files. > Does that mean dh_install can no longer be used for these targets > as described above or does that stage need to done elsewhere? > (before dh_builddeb I'm sure) You can probably use dh_install here, but I see that you are using dh_install with --sourcedir. While this is supported, I would recommend that you do "make install" to debian/tmp first (not to debian/firstpackage) and use the already existing debian/*.install files to tell dh_install which files go to which packages. This usually makes debian/rules to be more simple and easier to understand, and it also makes the future switch to "dh" easier. Thanks.
Bug#832017: RFS: python-backports-shutil-get-terminal-size/1.0.0-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-backports-shutil-get-terminal-size" * Package name: python-backports-shutil-get-terminal-size Version : 1.0.0-2 Upstream Author : Christopher Rosell * URL : https://github.com/chrippa/backports.shutil_get_terminal_size * License : Expat Section : python It builds those binary packages: python-backports-shutil-get-terminal-size - Backport of the "shutil.get_terminal_size" function (Python 2) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-backports-shutil-get-terminal-size Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-backports-shutil-get-terminal-size/python-backports-shutil-get-terminal-size_1.0.0-2.dsc It is packaged within the DPMT: Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/python-backports-shutil-get-terminal-size.git Vcs-Browser: https://anonscm.debian.org/git/python-modules/packages/python-backports-shutil-get-terminal-size.git The main change in this version is closing a serious bug (file conflict). Cheers, Snark on #debian-python
Bug#832018: RFS: ipython/5.0.0-1 (to experimental!)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ipython" * Package name: ipython Version : 5.0.0-1 Upstream Author : The IPython Development Team * URL : http://ipython.org/ * License : BSD-3-clause Section : python It builds those binary packages: ipython- Enhanced interactive Python 2 shell ipython3 - Enhanced interactive Python 3 shell python-ipython - Enhanced interactive Python shell (Python 2 version) python-ipython-doc - Enhanced interactive Python shell (documentation) python3-ipython - Enhanced interactive Python shell (Python 3 version) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ipython Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ipython/ipython_5.0.0-1.dsc It is packaged within the Debian Python Modules Team: Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/ipython4.git Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/ipython4.git I want to update the version in experimental as part of the effort to package jupyter in Debian. Cheers, Snark on #debian-python
Bug#832016: [git-buildpackage/master] import-orig: Switch to Debian branch before merging in changes
tag 832016 pending thanks Date: Thu Jul 21 13:19:31 2016 +0200 Author: Guido Günther Commit ID: 1f0013caa9dae2fb6e8a033589d039b86ee1abc3 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=1f0013caa9dae2fb6e8a033589d039b86ee1abc3 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=1f0013caa9dae2fb6e8a033589d039b86ee1abc3 import-orig: Switch to Debian branch before merging in changes otherwise we'd always merge into the current working copy Closes: #832016 A snapshot build including this change will be available at http://honk.sigxcpu.org:8001/job/git-buildpackage/
Bug#832019: RFS: jupyter-client/4.3.0-1 (to experimental!)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "jupyter-client" * Package name: jupyter-client Version : 4.3.0-1 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/jupyter_client * License : BSD-3-clause Section : python It builds those binary packages: jupyter-client - Jupyter protocol client APIs (tools) python-jupyter-client - Jupyter protocol client APIs (Python 2) python-jupyter-client-doc - Jupyter protocol client APIs (documentation) python3-jupyter-client - Jupyter protocol client APIs (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/jupyter-client Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/j/jupyter-client/jupyter-client_4.3.0-1.dsc It is packaged within the Debian Python Modules Team: Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/jupyter-client.git Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/jupyter-client.git Cheers, Snark on #debian-python
Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade
On Wed, 20 Jul 2016 22:06:05 +0300 Faidon Liambotis wrote: > Stack trace of thread 4122: > #0 0x7fa47ae7f1c8 raise (libc.so.6) > #1 0x7fa47ae8064a abort (libc.so.6) > #2 0x7fa4719b8f5b n/a (libavcodec.so.57) > #3 0x7fa4719b9026 avcodec_alloc_context3 >(libavcodec.so.57) > #4 0x7fa473360540 n/a (libgstlibav.so) > #5 0x7fa473356e53 n/a (libgstlibav.so) > #6 0x7fa47b74b22d g_type_class_ref (libgobject-2.0.so.0) > #7 0x7fa47b9c8da4 gst_element_register >(libgstreamer-1.0.so.0) > #8 0x7fa4733575b3 n/a (libgstlibav.so) > #9 0x7fa473349e20 n/a (libgstlibav.so) > #10 0x7fa47b9ea537 n/a (libgstreamer-1.0.so.0) > #11 0x7fa47b9ec425 n/a (libgstreamer-1.0.so.0) > #12 0x7fa47b9ed12c gst_plugin_load_by_name >(libgstreamer-1.0.so.0) > #13 0x7fa47b9eda8d gst_plugin_feature_load >(libgstreamer-1.0.so.0) > #14 0x7fa47ba137e3 gst_type_find_factory_call_function >(libgstreamer-1.0.so.0) > #15 0x7fa479c48421 gst_type_find_helper_for_data >(libgstbase-1.0.so.0) > #16 0x7fa479c485a4 gst_type_find_helper_for_buffer >(libgstbase-1.0.so.0) > #17 0x7fa4799f446a n/a (libgstwavparse.so) > #18 0x7fa4799f4b47 n/a (libgstwavparse.so) > #19 0x7fa4799fabb1 n/a (libgstwavparse.so) > #20 0x7fa47ba0ee71 n/a (libgstreamer-1.0.so.0) > #21 0x7fa47b47b55e n/a (libglib-2.0.so.0) > #22 0x7fa47b47abc5 n/a (libglib-2.0.so.0) > #23 0x7fa47b1f4464 start_thread (libpthread.so.0) Thanks for the report. Can you install debug symbols for libavcodec57 and get another backtrace? Also what's the assertion you see on the terminal that causes the abort()? Do you have the same problem with gstreamer1.0-libav from experimental (version 1.9.1-1)? I can't reproduce this here with either 1.8.2-1 or 1.9.1-1 unfortunately. signature.asc Description: This is a digitally signed message part
Bug#576875: tomcat6: Allow running the init script as a normal user, not admin
I don't think any user can start Tomcat, because the init script has to switch to the tomcat user at some point and this requires root privileges. That said the 'status' option should be usable by anyone. Currently it's restricted to the administrator. Should the tomcat user be allowed to control the daemon? I'm not sure this is a good idea, because a simple malicious JSP could then stop the server. If this is really needed I think sudo should be used instead. Emmanuel Bourg
Bug#832020: ruby2.3: ruby2.3_2.3.1-5 does not build with latest gdbm
Source: ruby2.3 Version: 2.3.1-5 Severity: important Dear Maintainer, Latest version of libgdbm(1.12) in experimental have new SONAME and separates away dbm_* interface in libgdbm-compat4 binary package. As such, it is transition, and I have to make sure, that reverse dependencies are okay. Most of them was trivial to fix -- just build-depend on libgdbm-compat-dev, but ruby2.3 proved to be harder. Here is snippet from test suite, when building aganist gdbm/experimental: TestGDBM#test_s_open_nolock: GDBMError: Bad magic number /home/user/stuff/ruby2.3-2.3.1/test/gdbm/test_gdbm.rb:190:in `open' /home/user/stuff/ruby2.3-2.3.1/test/gdbm/test_gdbm.rb:190:in `block (2 levels) in test_s_open_nolock' /home/user/stuff/ruby2.3-2.3.1/test/lib/test/unit/assertions.rb:171:in `assert_nothing_raised' /home/user/stuff/ruby2.3-2.3.1/test/gdbm/test_gdbm.rb:189:in `block in test_s_open_nolock' /home/user/stuff/ruby2.3-2.3.1/test/gdbm/test_gdbm.rb:152:in `block in open_db_child' /home/user/stuff/ruby2.3-2.3.1/test/gdbm/test_gdbm.rb:149:in `popen' /home/user/stuff/ruby2.3-2.3.1/test/gdbm/test_gdbm.rb:149:in `open_db_child' /home/user/stuff/ruby2.3-2.3.1/test/gdbm/test_gdbm.rb:188:in `test_s_open_nolock' I barely read Ruby and it is hard for me to debug this issue, and, as ruby package maintainer, you are more competent than me at it. Would you be so kind to try build ruby aganist gdbm/experimental and see why this test fails?
Bug#831899: kaddressbook crashes immediately on start
¡Hola Volker! El 2016-07-21 a las 11:03 +0200, Volker Groll escribió: Holla Maximiliano, It seems to me that the bug is the same as: https://bugs.kde.org/show_bug.cgi?id=358696 Hm, not sure, but there is mentioned the crash occurs, when the birthday calendar is enabled, mine is disabled. Well, it seems to be the same underlying issue. Could you please provide additional information in the bug upstream? Currently it seems to require confirmation that this bug is only reproduceable in 32 bits systems. I have local address books and two on an owncloud server. Changing the owncloud resource to offline with akonadiconsole changes nothing (crash persists). I get also a crash from akonadiconsole when I try to switch to Browser tab. Also, a full backtrace would be useful, for that you would need to install the kaddressbook-dbgsym package (and probably the dbg/dbgsym packages from a couple of kaddressbook dependencies) from the debug archive (that needs to be added in the sources.list as: deb http://deb.debian.org/debian-debug unstable-debug main) Most threads are in g_mutex_unlock (), __kernel_vsyscall () Installing libglib2.0-0-dbg will give only 0x in output, so I purged this debug package again. If possible please keep the full backtrace. The output of the last thread is: Thread 1 (Thread 0xed0a6ac0 (LWP 5109)): [KCrash Handler] Shouldn't there be information of 6 more frames? #7 0xf4ff1cb6 in Akonadi::Tag::isValid (this=0xff8b137c) at /build/akonadi- uzW5jU/akonadi-16.04.3/src/core/tag.cpp:239 #8 0xf5097577 in Akonadi::TagModel::data (this=0x9b1c098, index=..., role=258) at /build/akonadi-uzW5jU/akonadi-16.04.3/src/core/models/ tagmodel.cpp:95 Looking at the code, my bet is that changing akonadi's src/core/models/tagmodel_p.cpp the function Tag TagModelPrivate::tagForIndex line 106: return children.at(index.row()); for: return children.value(index.row()); would make the issue to go away (by creating a new instance whenever an invalid index is accessed), but the real issue is to be hitting this function with invalid index values (the previous fix only takes care of negative values, btw). That would need someone that actually understands the code. Please, if possible, add the information to the upstream bug with the full backtrace. Happy hacking, -- "If you can't write it down in English, you can't code it." -- Peter Halpern Saludos /\/\ /\ >< `/ signature.asc Description: Digital signature
Bug#830971: a patch seems available for 4.7 kernels
https://bugzilla.kernel.org/show_bug.cgi?id=121671
