Bug#845598: guitarix: FTBFS on hppa - Please add -mlong-calls to hppa compile flags
Hi, Many thanks for the bug report. On Thu, 24 Nov 2016 20:39:11 -0500 John David Anglin wrote: > This error is caused by a stub table overflow resulting in a branch > not being able to reach its long branch stub. The error can be avoided > by adding the "-mlong-calls" option to CFLAGS and CXXFLAGS as necessary. May I ask in what machine has the build failed? I see in [1] that the build has succeeded for hppa. [1]: https://buildd.debian.org/status/package.php?p=guitarix Cheers. -- Víctor Cuadrado Juan m...@viccuad.me PGP key ID: 4096R: 0xA2591E231E251F36 Key fingerprint: E3C5 114C 0C5B 4C49 BA03 0991 A259 1E23 1E25 1F36 My signed E-Mails are trustworthy. signature.asc Description: OpenPGP digital signature
Bug#848188: python-coverage: jquery.hotkeys.js from upstream is not packaged
On 12/15/2016 06:11 AM, Ben Finney wrote: > Control: tags -1 + moreinfo > > On Thu, 2016-12-15 00:28 +0100, Loic Dachary wrote: > >> The python-coverage package recommends libjs-jquery-hotkeys and does not >> install the jquery.hotkeys.js. > > I'm not sure what you mean by “does not install”; the “Recommends” > dependency will install the library at the time this package is > installed. > >> However the file found in the coverage.py >> sources is different from the file found in libjs-jquery-hotkeys: > > This is often the case for libraries. Which version is later? > >> In order to avoid unintended behavior or regressions, the >> jquery.hotkeys.js file provided in the coverage.py sources must be >> installed. > > No, that's against Debian policy for security management. The library > should not be bundled, but instead should be installed once, where a > security upgrade will benefit all applications using that library. > >> Although it is desirable to avoid file duplication > > That is not the primary reason; rather, the primary reason is to prevent > divergent versions of code installed by different packages. > >> this can only be done >> if the files are indeed identical or if they are provided by an upstream >> that maintains an API of some kind. > > Agreed, the API should be reliable :-) In the case of this javascript dependency, there is no reliable API, no backward compatibility and no releases. Do you acknowledge that packaging coverage.py with dependencies that are different from those provided in the upstream source may introduce bugs ? Cheers -- Loïc Dachary, Artisan Logiciel Libre
Bug#848168: readline: Please drop the multilib packages
On 14.12.2016 21:05, Sven Joachim wrote: > Source: readline > Version: 7.0-1 > Tags: buster sid > Control: block 848163 by -1 > > I intend to remove the ncurses multilib packages after the stretch > release, see #848163. Since ncurses is required to build readline, this > means that the readline multilib packages can then no longer be built. > > There are no reverse dependencies of the readline multilib packages, so > removing them should not be a problem. Did we stop building gdb64 packages for 32bit architectures? I'd like to delay that change until the buildds can manage dependencies on foreign architectures.
Bug#842794: autopkgtests fail (since perl 5.24?): Failed test 'Testing vcf-fix-ploidy .. cat ...
On Thu, 15 Dec 2016 09:10:43 +0200, Niko Tyni wrote: > > What did happen around the time was the removal of '.' from @INC. > That's indeed what caused the regression. [..] > > The test call can be shortened to: > > # vcf-fix-ploidy -s fix-ploidy.samples < fix-ploidy.vcf | grep 61098 > You missed the '-p' parameter above, which makes all the difference. > It's loading Perl code from the specified file with 'do', which no longer > looks in cwd. The load fails silently and the program continues on with > wrong results. *sigh* I did see the "do $file", and I tried with and without -p ... and then must have had a "knot in my brain". Sorry & thanks! Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #173: Recursive traversal of loopback mount points
Bug#847791: python2.7: Fix for #5322 breaks SageMath
will be part of the the 2.7.13 release. On 14.12.2016 18:59, Tobias Hansen wrote: > Control: tags -1 + fixed-upstream > > The change was reverted upstream. I hope we can now revert it quickly in > Debian as well. > > Best, > Tobias > > On 12/11/2016 09:47 PM, Tobias Hansen wrote: >> Control: tags -1 + patch >> >> Hi, >> >> here is a patch reverting the change. >> >> BTW, when trying to build the package with sbuild I get (with or without >> the patch): >> >> END test shared >> cp -p /<>/build-static/test_results debian/ >> cp: cannot stat '/<>/build-static/test_results': No such >> file or directory >> debian/rules:522: recipe for target 'stamps/stamp-check' failed >> >> Best, >> Tobias >>
Bug#848105: [rt.cpan.org #119235] Bio/Coordinate/Pair.pm removed from BioPerl in version 1.00070001
Hi Chris, On Wed, Dec 14, 2016 at 11:57:50PM -0500, Chris Fields via RT wrote: > > I will work on a separate CPAN release of Bio::Coordinate modules. A key > issue may be that Bio::Graphics would need a release to add > Bio::Coordinate::Pair as a direct dependency, if it isn't already present. Thanks for your quick response. Would you mind giving us a notification once Bio::Coordinate would be available? This would help fixing the bug in the Debian bug tracking system. Do you have a rough estimation of the time you might need for this? Kind regards Andreas. -- http://fam-tille.de
Bug#842794: autopkgtests fail (since perl 5.24?): Failed test 'Testing vcf-fix-ploidy .. cat ...
On Wed, Dec 14, 2016 at 08:00:00PM +0100, gregor herrmann wrote:
> On Wed, 14 Dec 2016 08:58:30 +0100, Andreas Tille wrote:
>
> > On Tue, Nov 01, 2016 at 11:05:02AM +, Iain Lane wrote:
> > > I noticed in Ubuntu, where we run autopkgtests as part of britney
> > > migration, that vcftools fails now. You can see on ci.debian.net[0]
> > >
> > > > not ok 26 - Testing vcf-fix-ploidy .. cat fix-ploidy.vcf | perl -I../.
> > > > -MVcf /usr/bin/vcf-fix-ploidy -s fix-ploidy.samples -p fix-ploidy.txt
> > > > 2>/dev/null | vcf-query -f '%POS[\t%SAMPLE %GTR %PL]\n'
> > > > # Failed test 'Testing vcf-fix-ploidy .. cat fix-ploidy.vcf | perl
> > > > -I../. -MVcf /usr/bin/vcf-fix-ploidy -s fix-ploidy.samples -p
> > > > fix-ploidy.txt 2>/dev/null | vcf-query -f '%POS[\t%SAMPLE %GTR %PL]\n''
> > > > # at ./test.t line 452.
> > > > # Structures begin differing at:
> > > > # $got->[0] = '61098 M1 0/1 0,9,72,5,6,7 M2 0/0
> > > > 0,15,140,5,6,7 F3 1 147,0,5F4 0 0,131,5M5 0/0 0,9,83,5,6,7
> > > > M6 0/0 0,6,56,5,6,7
> > > > # '
> > > > # $expected->[0] = '61098 M1 0 0,9,72,5,6,7 M2 0
> > > > 0,15,140,5,6,7 F3 1/1 147,0,5 F4 0/0 0,131,5 M5 0 0,9,83,5,6,7
> > > >M6 0 0,6,56,5,6,7
> > > > # '
> The tests started failing on 2016-09-01.
> perl 5.24 entered unstable on 23 Sep 2016.
>
> What did happen around the time was the removal of '.' from @INC.
That's indeed what caused the regression.
> The test call can be shortened to:
>
> # vcf-fix-ploidy -s fix-ploidy.samples < fix-ploidy.vcf | grep 61098
> 20 61098 . C A,T 999 PASS
> AC1=41;AF1=0.2104;DP4=209,284,67,76;DP=658;FQ=999;MQ=45;PV4=0.39,4.4e-10,0.0034,0.2
> GT:PL:DP:SP:GQ 0/1:0,9,72,5,6,7:3:212:12 0/0:0,15,140,5,6,7:5:458752:18
> 1:147,0,5:7:384:24 0:0,131,5:5:208:18 0/0:0,9,83,5,6,7:3:392:12
> 0/0:0,6,56,5,6,7:2:204:9
>
> Which already has the 0/1:0,9,72,5,6,7 sequence which is not the
> expected "0 0,9,72,5,6,7". And I don't know what either of them mean
You missed the '-p' parameter above, which makes all the difference.
It's loading Perl code from the specified file with 'do', which no longer
looks in cwd. The load fails silently and the program continues on with
wrong results.
Patch attached.
--
Niko Tyni nt...@debian.org
>From 8435d883d7d514618c8dcd8b60a722e163a261f6 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Thu, 15 Dec 2016 01:39:16 +0200
Subject: [PATCH] vcf-fix-ploidy: make -p work without . on @INC
'do $file' only looks in @INC for unqualified file names, so
prefix those with './' in case '.' is not on @INC.
While at it, add diagnostics if sourcing the file fails altogether.
Bug-Debian: https://bugs.debian.org/842794
---
src/perl/vcf-fix-ploidy | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/perl/vcf-fix-ploidy b/src/perl/vcf-fix-ploidy
index 4fd380d..0140a21 100644
--- a/src/perl/vcf-fix-ploidy
+++ b/src/perl/vcf-fix-ploidy
@@ -75,7 +75,17 @@ sub parse_params
};
while (defined(my $arg=shift(@ARGV)))
{
-if ( $arg eq '-p' || $arg eq '--ploidy' ) { my $file=shift(@ARGV); my $x=do $file; $$opts{ploidy}=$x; next }
+if ( $arg eq '-p' || $arg eq '--ploidy' ) {
+my $file=shift(@ARGV);
+$file = "./$file" if $file !~ m{^/};
+my $x=do $file;
+if (!defined $x) {
+error("problem parsing \"$file\": $@") if $@;
+error("problem doing \"$file\": $!");
+}
+$$opts{ploidy}=$x;
+next
+}
if ( $arg eq '-s' || $arg eq '--samples' ) { $$opts{samples}=shift(@ARGV); next }
if ( $arg eq '-a' || $arg eq '--assumed-sex' ) { $$opts{assumed_sex}=shift(@ARGV); next }
if ( $arg eq '-l' || $arg eq '--fix-likelihoods' ) { $$opts{fix_likelihoods}=1; next }
--
2.10.2
Bug#848086: Apologies for error: please delete bug
On Wednesday, 14 December 2016 20:34:38 CET you wrote: > Sorry about this, with this kind of problem I normally completely wipe > and reinstall, and this time I only reinstalled. No worry. Thanks for keeping us up to date. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#826498: automake1.11: Unescaped left brace in regex is deprecated
Control: tags -1 + patch
On Sun, Jun 05, 2016 at 10:24:11PM +0300, Niko Tyni wrote:
> Building the muttprint package triggers deprecation warnings with Perl
> 5.24 (currently in experimental), and probably with Perl 5.22 (current
> sid) too.
>
> Unescaped left brace in regex is deprecated, passed through in regex;
> marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at
> /usr/bin/automake-1.11 line 4159.
This issue also affects e.g. src:jamin. The attached patch fixes the
problem. Please consider applying it.
Helmut
diff --minimal -Nru automake1.11-1.11.6/debian/changelog
automake1.11-1.11.6/debian/changelog
--- automake1.11-1.11.6/debian/changelog2014-10-20 02:14:05.0
+0200
+++ automake1.11-1.11.6/debian/changelog2016-12-14 17:07:50.0
+0100
@@ -1,3 +1,10 @@
+automake1.11 (1:1.11.6-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix usage of deprecated regular expression syntax (Closes: #826498)
+
+ -- Helmut Grohne Wed, 14 Dec 2016 17:07:50 +0100
+
automake1.11 (1:1.11.6-3) unstable; urgency=medium
* debian/copyright: New DEP-5 copyright file.
diff --minimal -Nru automake1.11-1.11.6/debian/patches/826498.diff
automake1.11-1.11.6/debian/patches/826498.diff
--- automake1.11-1.11.6/debian/patches/826498.diff 1970-01-01
01:00:00.0 +0100
+++ automake1.11-1.11.6/debian/patches/826498.diff 2016-12-14
17:07:50.0 +0100
@@ -0,0 +1,17 @@
+From: Helmut Grohne
+Subject: update deprecated regex syntax
+Bug-Debian: https://bugs.debian.org/826498
+
+Index: automake1.11-1.11.6/automake.in
+===
+--- automake1.11-1.11.6.orig/automake.in
automake1.11-1.11.6/automake.in
+@@ -4156,7 +4156,7 @@
+ sub substitute_ac_subst_variables ($)
+ {
+ my ($text) = @_;
+- $text =~ s/\${([^ \t=:+{}]+)}/&substitute_ac_subst_variables_worker ($1)/ge;
++ $text =~ s/\$\{([^ \t=:+{}]+)\}/&substitute_ac_subst_variables_worker
($1)/ge;
+ return $text;
+ }
+
diff --minimal -Nru automake1.11-1.11.6/debian/patches/series
automake1.11-1.11.6/debian/patches/series
--- automake1.11-1.11.6/debian/patches/series 2014-10-20 02:14:05.0
+0200
+++ automake1.11-1.11.6/debian/patches/series 2016-12-14 17:07:27.0
+0100
@@ -1,3 +1,4 @@
01-texi-rename.diff
02-compile_f90_c_cxx-fix.diff
03-texinfo-fix-itemx.diff
+826498.diff
Bug#847549: kernel bug dcache.c 2373 invalid opcode 0000 d_materialise_unique
On 15/12/16 00:49, Ben Hutchings wrote: > Control: tag -1 moreinfo > > On Fri, 9 Dec 2016 09:35:40 +0100 Daniel Pocock > wrote: >> Package: linux Version: 3.16.36-1+deb8u1 Severity: important >> >> The system is an NFS server running linux-image-3.16.0-4-amd64 >> >> At times of heavy load on NFS, such as "git checkout some-branch" >> in a large repository, the system crashes (dmesg output >> attached). It has been happening regularly since the upgrade to >> jessie and with every kernel released through stable updates. I >> don't recall seeing this in wheezy. >> >> I've installed kdump-tools. Sometimes it captures the dmesg >> output, a recent example from a crash on 2016-12-02 is attached. >> I'm not sure if the crashes without /var/crash logs are the same >> bug. >> >> The same crash was reported[1] on linux-fsdevel by another Debian >> user. > > Can you test the attached patches? The first is the one J. Bruce > Fields pointed to and the second is in the same area; both of them > went upstream in 3.17. > > Instructions for rebuilding the kernel with patches: > https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official > > Thanks for this feedback. If the backport kernel continues working for me I'm not going to have time to test this in the near future as there are a lot of other things that don't have such a workaround and need more urgent attention. If anybody else comes across this bug and really wants to stay on the stable kernel then I would encourage you to test this and give feedback.
Bug#848214: nfsdcltrack installed to wrong location
Package: nfs-kernel-server Version: 1:1.2.8-9.2 Severity: serious Fixed: 1:1.3.4-1 The kernel looks[1] for nfsdcltrack in /sbin The package released in jessie installs it to /usr/sbin Fixed in the 1.3.4-1 upload. This affects jessie users, a stable update may be necessary 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847681#145
Bug#784735: gpodder: wrong standard media player
On Mon, 18 May 2015 09:44:28 +0200 =?UTF-8?B?QmrDtnJuIFNpZWJrZQ==?= wrote: > my desktop environment is GNOME3. > I checked all the issued and filed a new bug for xdg-utils [1]. Sorry for the long delay - thank for the follow-up. I will reassign this bug to xdg-utils.
Bug#829180: appears to be failing because of fsck
On 15/12/16 00:29, Michael Biebl wrote: > Am 07.12.2016 um 17:36 schrieb Daniel Pocock: >> I've observed this problem again today >> >> Looking more closely, I noticed that it started to fsck the mount >> just before it tried to mount it. It didn't appear to wait for >> fsck to finish: > > Fwiw, the log you provided doesn't seem to confirm that. > > mount for /dev/mapper/vg00-foo_host1_bak is only done after the > fsck has completed > (systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service: main > process exited, code=exited, status=0/SUCCESS) > Please look more closely ... 3 lines after that it says the fsck has "Started" and then it gives another line about "cgroup is empty" Could that just be a fault with re-ordering the log entries in journald? Or maybe it is starting fsck twice? Regards, Daniel
Bug#845302: systemd: 232-6:Failed to boot, makes kernel panic when starting /sbin/init.
On Fri, 2016-12-09 at 17:50 +, Ben Hutchings wrote: > On Wed, 23 Nov 2016 14:30:36 +0100 Michael Biebl wrote: [...] > > We would also have to make sure to use mount --move in > > /usr/share/initramfs-tools/init for /run, /sys and /proc > > > > Ben, what's your take on this? > > I'd like to sort out the busybox and klibc-utils implementations of > mount, but I must admit there isn't much point in using them any more. ...except that a few other packages install scripts that use 'mount -o move', which doesn't work with the util-linux version of mount: https://codesearch.debian.net/search?q=mount+.*+-o+move I think that util-linux will need to get support for that. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#847961: gitweb: missing dependency to libcgi-pm-perl
Control: affects -1 1:2.10.2-3 The regression was introduced by Perl, not Git. CGI.pm used to live in Perl core but was dropped in Perl 5.22. I’ve confirmed that testing is also affected (and, based on the Perl changelog, has probably been affected all year). I’ll add the missing dependency to gitweb shortly. Anders
Bug#848213: apport: CVE-2016-9949 CVE-2016-9950 CVE-2016-9951
Source: apport Version: 2.16.2-1 Severity: grave Tags: security upstream patch Justification: user security hole Hi, the following vulnerabilities were published for apport. CVE-2016-9949[0], CVE-2016-9950[1], CVE-2016-9951[2]. Details are in the Launchpad bug[3]. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2016-9949 [1] https://security-tracker.debian.org/tracker/CVE-2016-9950 [2] https://security-tracker.debian.org/tracker/CVE-2016-9951 [3] https://bugs.launchpad.net/apport/+bug/1648806 Regards, Salvatore
Bug#848212: libssl-dev package missing ECDSA_SIG_st structure definition
Package: libssl-dev
Version: 1.1.0c-2
Severity: normal
Dear Maintainer,
I'm getting errors compiling a program that uses OpenSSL ECDSA
code:
libabi/src/ossl_ec.c: In function ‘OSSL_ECDSA_do_verify_rs’:
libabi/src/ossl_ec.c:204:15: error: storage size of ‘sig’ isn’t known
ECDSA_SIG sig;
^~~
libabi/src/ossl_ec.c: In function ‘OSSL_ecdsa_sig_get_r’:
libabi/src/ossl_ec.c:222:56: error: dereferencing pointer to incomplete type
‘ECDSA_SIG {aka const struct ECDSA_SIG_st}’
return (const OSSL_BIGNUM*) ((const ECDSA_SIG*)sig)->r;
^~
I notice that libssl-dev doesn't appear to define the ECDSA_SIG_st
structure:
$ dpkg -L libssl-dev | grep '\.h' | xargs -d\\n grep ECDSA_SIG_st
/usr/include/openssl/ec.h:typedef struct ECDSA_SIG_st ECDSA_SIG;
The structure *is* included in the openssl 1.1.0c source file
(openssl_1.1.0c.orig.tar.gz):
$ grep -r ECDSA_SIG_st openssl-1.1.0c
openssl-1.1.0c/include/openssl/ec.h:typedef struct ECDSA_SIG_st ECDSA_SIG;
openssl-1.1.0c/crypto/ec/ec_lcl.h:struct ECDSA_SIG_st {
When I paste the ECDSA_SIG_st structure definition into the code, it
compiles and runs ok. I think this code is accidentally missing from the
debian package. But I'm also not familar with this code, so perhaps I'm just
misunderstanding how it's all supposed to work.
-David
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.0-1-amd64 (SMP w/8 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 libssl-dev depends on:
ii libssl1.1 1.1.0c-2
Versions of packages libssl-dev recommends:
pn libssl-doc
libssl-dev suggests no packages.
-- no debconf information
Bug#848210: dpkg-buildpackage -tc option no longer works
Package: dpkg-dev Version: 1.18.15 Severity: normal The dpkg-buildpackage short option '-tc' doesn't work. It's now interpreted like '-t c', resulting in: dpkg-architecture: error: unknown GNU system type c, you must specify Debian architecture, too Please fix or remove this from the man page. Ben. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-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 dpkg-dev depends on: ii binutils 2.27.51.20161127-1 ii bzip2 1.0.6-8 ii libdpkg-perl 1.18.15 ii make 4.1-9 ii patch 2.7.5-1 pn perl:any ii tar 1.29b-1.1 ii xz-utils 5.2.2-1.2 Versions of packages dpkg-dev recommends: ii build-essential 12.2 ii fakeroot 1.21-2 ii gcc [c-compiler] 4:6.2.1-1 ii gcc-4.8 [c-compiler] 4.8.5-4 ii gcc-5 [c-compiler] 5.4.1-3 ii gcc-6 [c-compiler] 6.2.1-5 ii gnupg2.1.16-2 ii gnupg2 2.1.16-2 ii gpgv 2.1.16-2 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: ii debian-keyring 2016.09.04 -- no debconf information
Bug#848211: privoxy: adventofcode blocked by default
Package: privoxy
Version: 3.0.26-2
Severity: wishlist
Please add some substring of "adventofcode.com" to { -block }
Bug#848209: test
Package: network-manager Version: 1.4.2-3 Severity: normal test -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager depends on: ii adduser3.115 ii dbus 1.10.14-1 ii init-system-helpers1.46 ii libaudit1 1:2.6.7-1 ii libbluetooth3 5.43-1 ii libc6 2.24-8 ii libglib2.0-0 2.50.2-2 ii libgnutls303.5.7-2 ii libgudev-1.0-0 230-3 ii libmm-glib01.6.4-1 ii libndp01.6-1 ii libnewt0.520.52.19-1 ii libnl-3-2003.2.27-1 ii libnm0 1.4.2-3 ii libpam-systemd 232+upstream20161214-0.master ii libpolkit-agent-1-00.105-17 ii libpolkit-gobject-1-0 0.105-17 ii libreadline7 7.0-1 ii libselinux12.6-3 ii libsoup2.4-1 2.56.0-1 ii libsystemd0232+upstream20161214-0.master ii libteamdctl0 1.26-1 ii libuuid1 2.29-1 ii lsb-base 9.20161125 ii policykit-10.105-17 ii udev 232+upstream20161214-0.master ii wpasupplicant 2.5-2+v2.4-3+b1 Versions of packages network-manager recommends: ii crda 3.13-1+b2 ii dnsmasq-base 2.76-5 ii iptables 1.6.0+snapshot20161117-4 ii iputils-arping 3:20161105-1 pn isc-dhcp-client ii modemmanager 1.6.4-1 ii ppp 2.4.7-1+4 Versions of packages network-manager suggests: pn libteam-utils -- no debconf information
Bug#848208: GUI segfaults when trying to collect system information
Package: reportbug
Version: 7.1.0
Severity: important
I've just tried to file a bug report using the GTK based interface via
reportbug --exit-prompt --ui gtk2
The package I tried to file the bug report against was reportbug itself.
After entering the bug description and selection the severity, reportbug
segfaults trying to gather the system information:
$ LANG=en_US.UTF-8 reportbug --exit-prompt --ui gtk2
Traceback (most recent call last):
File "/usr/bin/reportbug", line 2233, in
main()
File "/usr/bin/reportbug", line 1107, in main
return iface.user_interface()
File "/usr/bin/reportbug", line 2149, in user_interface
package, severity, mode, charset=charset, tags=tags)
File "/usr/bin/reportbug", line 182, in handle_editing
editor, charset)
File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1561, in
func
op = klass(parent)
File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 539, in
__init__
self.widget = self.create_widget()
File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1173, in
create_widget
expander = Gtk.Expander("Other system information")
TypeError: GObject.__init__() takes exactly 0 arguments (1 given)
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages reportbug depends on:
ii apt1.4~beta2
ii python3-reportbug 7.1.0
pn python3:any
reportbug recommends no packages.
Versions of packages reportbug suggests:
pn claws-mail
pn debconf-utils
ii debsums2.1.3
pn dlocate
ii emacs24-bin-common 24.5+1-7
ii exim4 4.88~RC6-1
ii exim4-daemon-light [mail-transport-agent] 4.88~RC6-1
ii file 1:5.29-2
ii gir1.2-gtk-3.0 3.22.5-1
ii gir1.2-vte-2.910.46.1-1
ii gnupg 2.1.16-3
ii python3-gi 3.22.0-2
pn python3-gtkspellcheck
pn python3-urwid
ii xdg-utils 1.1.1-1
-- no debconf information
Bug#848188: python-coverage: jquery.hotkeys.js from upstream is not packaged
Control: tags -1 + moreinfo On Thu, 2016-12-15 00:28 +0100, Loic Dachary wrote: > The python-coverage package recommends libjs-jquery-hotkeys and does not > install the jquery.hotkeys.js. I'm not sure what you mean by “does not install”; the “Recommends” dependency will install the library at the time this package is installed. > However the file found in the coverage.py > sources is different from the file found in libjs-jquery-hotkeys: This is often the case for libraries. Which version is later? > In order to avoid unintended behavior or regressions, the > jquery.hotkeys.js file provided in the coverage.py sources must be > installed. No, that's against Debian policy for security management. The library should not be bundled, but instead should be installed once, where a security upgrade will benefit all applications using that library. > Although it is desirable to avoid file duplication That is not the primary reason; rather, the primary reason is to prevent divergent versions of code installed by different packages. > this can only be done > if the files are indeed identical or if they are provided by an upstream > that maintains an API of some kind. Agreed, the API should be reliable :-) -- \ `\ _o__) Ben Finney
Bug#848207: GUI is called gtk2 even though it's gtk3
Package: reportbug Version: 7.1.0 Severity: normal The graphical user unterface can be started via reportbug --ui gtk2 This is confusing because it actually starts a gtk3 based interface. Either gtk2_ui.py should be renamed to gtk3_ui.py or the version dropped altogether and named gtk_ui.py Regards, Michael -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages reportbug depends on: ii apt1.4~beta2 ii python3-reportbug 7.1.0 pn python3:any reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils ii debsums2.1.3 pn dlocate ii emacs24-bin-common 24.5+1-7 ii exim4 4.88~RC6-1 ii exim4-daemon-light [mail-transport-agent] 4.88~RC6-1 ii file 1:5.29-2 ii gir1.2-gtk-3.0 3.22.5-1 ii gir1.2-vte-2.910.46.1-1 ii gnupg 2.1.16-3 ii python3-gi 3.22.0-2 pn python3-gtkspellcheck pn python3-urwid ii xdg-utils 1.1.1-1 -- no debconf information
Bug#846993: vim-gtk3: vimdiff does not compare last lines if editing changes lines
Control: tag -1 upstream patch Control: forwarded -1 https://github.com/vim/vim/pull/1329 On Tue, Dec 06, 2016 at 09:53:43PM +0100, Helge Kreutzmann wrote: > Hello James, > On Sun, Dec 04, 2016 at 08:22:34PM -0500, James McCoy wrote: > > On Sun, Dec 04, 2016 at 09:25:41PM +0100, Helge Kreutzmann wrote: > > > The last two lines are now identical (they only contain the word > > > »rows«), but vimdiff (in the current version) does not show this. > > > > > > (This is an artifical case, ordinarily the last line contains many > > > words, so it is not easy to spot if they are actually identical). > > > > > > To really see the a proper diff, you need to save the changed file, > > > quit vim and rerun the vimdiff command from above. > > > > Can't you just run ":diffupdate" instead? > > Thanks for the hint, yes this works. > > However, with older versions of vim this is not necessary, so the > regression exists. Agreed. Tracked down the offending commit and sent a patch upstream. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#845034: initramfs-tools: please ensure initrd images are reproducible
I also have a coding style nit-pick - please use [ -n "..." ] rather than [ "..." != "" ] Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#845034: initramfs-tools: please ensure initrd images are reproducible
Control: block -1 with 804063 On Sun, 20 Nov 2016 22:35:13 +0100 Chris Lamb wrote: > Chris Lamb wrote: > > > Patch attached. > > Updated patch attached, which passes --reproducible to cpio (>= 2.12) > to ensure inode numbers are renumbered. I'd much prefer to add a versioned dependency on the new cpio (when available) than to probe for it ar run-time. (initramfs-tools already has dependencies and incompatibilities that prevent it from being backported to jessie, so this wouldn't make that any worse.) Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#848206: ITP: nototools -- Utilities for building and maintaining noto fonts
Package: wnpp Severity: wishlist Owner: "Ming-ting Yao Wei (魏銘廷)" * Package name: nototools Upstream Author : Google Inc. * URL : https://github.com/googlei18n/nototools * License : Apache License 2.0 Programming Lang: Python Description : Utilities for building and maintaining noto fonts This is the utility for Noto contributors to build and maintain Noto fonts, and is required if we need to build fonts-noto-color-emoji from source. After priminary build of Noto Color Emoji I found that due to the old version of fonttools it requires patching and disabling Python 3 support to make it work. As this utility is for building font from source, the "maintaining" function of this package becomes not so important. This package should be best maintained by Debian Fonts Task Force.
Bug#848205: ntpdc: can't talk to server
Package: ntp Version: 1:4.2.8p9+dfsg-2 Severity: normal Dear Maintainer, I do: ntpdc ntpdc> peers and ntpdc times out trying to talk to the server on localhost. Installing the ntp version from Jessie without changing /etc/ntp.conf fixes the problem. thus: apt-get install -t jessie ntp/jessie ntpq works with both versions. ntpdc no longer quits on control-D either. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 3.10.101-0-pine64-longsleep (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ntp depends on: ii adduser3.115 ii dpkg 1.18.15 ii libc6 2.24-8 ii libcap21:2.25-1 ii libedit2 3.1-20160903-2 ii libopts25 1:5.18.12-3 ii libssl1.1 1.1.0c-2 ii lsb-base 9.20161125 ii netbase5.3 Versions of packages ntp recommends: pn perl:any Versions of packages ntp suggests: pn ntp-doc -- Configuration Files: /etc/ntp.conf changed: driftfile /var/lib/ntp/ntp.drift statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable pool pool.ntp.csiro.au restrict -4 default kod notrap nomodify nopeer noquery limited restrict -6 default kod notrap nomodify nopeer noquery limited restrict 127.0.0.1 restrict ::1 restrict source notrap nomodify noquery -- no debconf information
Bug#848204: liblz4.so.1 is required for booting, but install in /usr/lib
Am 15.12.2016 um 05:11 schrieb Guo Yixuan: > Thank you for the reply. The reason might be that I have initramfs-tools at > 0.120 and the behaviour change was introduced at 0.121. That could be it, yes. It also looks like you are using a custom kernel (4.8.11-1-miz), so make sure to build that kernel with initramfs-tools support. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#848204: liblz4.so.1 is required for booting, but install in /usr/lib
Package: liblz4-1 Version: 0.0~r131-2 Severity: important Hello, In a recent reboot, I found that my system got stuck at cryptsetup part (I have encrypted / and /usr), with an error message from /bin/ps saying that liblz4.so.1 is not found. It appears that /bin/ps is linked to liblz4, and is required early during booting, but liblz4 is installed in /usr/lib/x86_64-linux-gnu/liblz4.so.1.7.1 thus unavailable before /usr is mounted. $ aptitude why procps liblz4-1:amd64 i procps Dependslibprocps6 i A libprocps6 Dependslibsystemd0 (>= 209) i A libsystemd0 PreDepends liblz4-1 (>= 0.0~r113) After booting to recovery mode and copying /usr/lib/x86_64-linux-gnu/liblz4.so.1.7.1 to /lib/x86_64-linux-gnu/liblz4.so.1, the system boots normally again. Therefore, please considering install the library to /lib instead of /usr/lib. Thanks, Yixuan -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.11-1-miz (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages liblz4-1:amd64 depends on: ii libc6 2.24-8 liblz4-1:amd64 recommends no packages. liblz4-1:amd64 suggests no packages. -- no debconf information
Bug#846704: waffle: diff for NMU version 1.5.2-2.1
On 2016-12-14 09:58:16, Andrey Rahmatullin wrote: > Control: tags 846704 + patch > Control: tags 846704 + pending > > Dear maintainer, > > I've prepared an NMU for waffle (versioned as 1.5.2-2.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. There's no need to delay the change.
Bug#848199: RFS: evil-el/1.2.12-2
control: severity -1 important control: tag -1 +moreinfo On Thu, Dec 15, 2016 at 05:12:31AM +0300, Dmitry Bogatov wrote: > Changes since last upload: > > [ Sean Whitton ] > * Team upload. > * Fix Vcs-* URIs. You should delete the "Team upload" line since the person who signed off the changelog is listed as an uploader. (You should leave the other line attributed to me.) > [ Dmitry Bogatov ] > * Run tests only if standards streams are terminals (Closes: #829299) > * Temporary skip test suite, which fails with emacs25 (Closes: #847040) You're skipping the whole test suite. Why not just add a patch to disable the tests that fail with emacs25? That way, we will be alerted to any further regressions. -- Sean Whitton signature.asc Description: PGP signature
Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES: reproducing issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Again,
On 14/12/16 23:19, Jerome BENOIT wrote:
> Thanks for the patch. I am on my way to build the involved package
> for the repository deb-sci-deb .
>
> Jerome
>
> On 14/12/16 19:46, Bill Allombert wrote:
>> On Mon, Dec 12, 2016 at 10:19:18PM +0100, Bill Allombert wrote:
>>> On Mon, Dec 12, 2016 at 06:06:37PM +0100, Bill Allombert wrote:
On Sun, Dec 11, 2016 at 11:15:00PM +, Ximin Luo wrote:
> Did you remove test.w before trying the tests? I think it is still
> somehow autpgrp-related. Also the "corrupted" messages seem to be
> separate from the actual failure of "no method found":
I agree with you. But the "corrupted" messages are still a bug even
if they do not affect Sage.
>>>
>>> I can reproduce this bug using a pristine gap installation without any
>>> Debian stuff:
>>>
>>> rm -f workspace file file.gz
>>> echo "abcdefgh" > file
>>> gzip file
>>> echo 'SaveWorkspace("workspace");' | bin/*/gap -q -b
>>> echo 'ReadLine(InputTextFile("file"));' | bin/*/gap -q -b
>>> echo 'ReadLine(InputTextFile("file"));' | bin/*/gap -q -b -L workspace
>>>
>>> I will report it upstream.
>
>> Upstream send me the attached patch which fix this problem.
>> Please confirm this address the original issue.
I deposited a patched version of GAP at deb-sci-sage (4r8p6-1+sage23).
The test
( cd sage; ./sage -t --long src/sage/interfaces/gap.py )
passes now. But, in a previous email, Ximin seems to speak about a work around.
So, for plain confirmation, Ximin will gives the final answer.
Thanks,
Jerome
>
>> Cheers,
>
>
>
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
>
- --
Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net
http://www.rezozer.net/
- --
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-
iQQcBAEBCgAGBQJYUg3jAAoJED+SGaZ/NsaLsOwf/jd6D84JbfDMg3klm5KBB20o
6XEbYV2IZCHKaLWQ7BeCIx6dT4qyJRsCTvbOSI2cBaBOubghZpAV6vAOk5d2fcCa
WdgN3dgJVjLdSL6MbKsMZunLHmhcAhAG1H0phq+51i4YfGRHsSvWvPDO4kqn+cGm
a7kjk5peUdW5GUtHEdia70SdYvbIeR9ddLlPPdNof6S9GfZTpxObdyPptG0ARH8L
BkYc7Gh7+84gr6WcxPB4QLRePp2zjOnWRbh4z9dPmfkuFmmCJ/jru7Z6FuaqpYjR
y/91syB0DTNVWnzklxqiDY6akd4Ty/XDhvCatJaxrGPbg9KANPeadsCvkwbXGeQ+
uBKmNT/6Y0edvJzmyYomuy3OY7QDhKjfCXAYfiGYt+w7KjlQdR8FNMUiqn2ackvr
pLAvhf0mk/33H7k8RVlnmk+VOsY7KOsY9kOBMlB9s7KKVaYNzBe6YvKut5pAbR4E
gypcr1EgC3uLb6Zbf7OeYySyTA3MCo0I3Hxwpe7kadPMYvfCbfqaESreEyU04eG5
gB+UojvCUpV8t1/ou+2D+x9WrpJ46I66GaHYujF0gwM1YYGAvwsolIXvnUrnxSIO
1HJHXBv6FzDZkQijkQkzX2J49mYvOFF7w2nKdKYf6TfibMRgBzP+PUJNrux0oW3i
PaGaFJdOGarYAMIcU/4PkSOG7ddFMwAbDlPv0Gb3/SHqGQvfNwnWFnsvVzoNnnz7
8/EqOC26oCMUAke9ER/NHQ8uaAhSXX09fUD4gR/VQORQmYEh/3FrqWe/Q9zLDRlO
4LQ1ophb39lJlUWuS4BWJS2UcyRlwQXPTXq9IMOSNUjQ4CQE/w1Xx7njfIJQ4uDA
K1hhCmXltQzgKkszlyqdZk+66hs526s7aXaxFfrlvkMozYk11erLBTm1GbQC//Pc
EYOEvPBjgjiaVSJvn9rGgOgaO4uzfziZyDrc7sVALqVSXJS/2U7/X3SAH3j70e8W
3aVByNnhKz/5vaLaYHC2PkFl6NXFZoTpRF1uTYLc7GxEPpjnpirUz7wnDbR+Kg9K
SsSkY/1rdgP3/13A3ysA5txxEOompEshZHtQGv0ub3LYcVFJNDZucP2okY6wdg7C
ODQNA15Ga/3bn2gxlJriDlBST1H7BgjLRHNYAzVAKWIDVcDbwrcjuLJZ3Mr5Ejly
12wSdN+9lDzTrCaUnq5DdfTc+SzH1sO8/caGpWeXg3RPYed8ZRBD1pPMZdPrxEuW
CUfQ6EGO9vdaNOUMKmtKOUqRQ4yqPI8Re6meLFc1uGLl6PV8CbG4S7WR72nA4s4O
GXbzGFE7va6yN6Tmh5thAj9qv3vBbPTYw7ONZneE/v9DdRvXBilYEYfzyphQSy8=
=v6+V
-END PGP SIGNATURE-
Bug#848193: Want "dgit clone RUNNING" or some such
On Thu, Dec 15, 2016 at 01:26:04AM +, Ian Jackson wrote: > I would like dgit clone to be able to give you `the source for the > package I am running'. (It gives you sid by default.) This involves > knowing the relevant suite, at the very least. Users who don't know how to quickly find the suite a package came from probably don't have a good grasp of Debian's distinction between source and binary packages, either. So it might be good if dgit resolved binary package names to source package names as a fallback. -- Sean Whitton signature.asc Description: PGP signature
Bug#848203: ITP: backports.functools-lru-cache -- backport of functools.lru_cache from Python 3.3
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: backports.functools-lru-cache Version : 1.3 Upstream Author : Jason R. Coombs * URL : https://github.com/jaraco/backports.functools_lru_cache * License : MIT Programming Lang: Python Description : backport of functools.lru_cache from Python 3.3 needed by pylint 1.6.4
Bug#846465: most: Add support for XZ-compressed files
> > Fortunately it seems very easy to do, so I'm attaching the patch. > > I pressed the 'send' button too fast. The previous patch was wrong, > here's the correct one. Thanks for this! I really appreciate the help. I've applied this patch to a version I've just uploaded to Debian unstable. It also fixes the other security you've mentioned and I've emailed the security team so we can begin fixing that issue in distributions other than testing/unstable. Thanks for your work on this! Later, Mako -- Benjamin Mako Hill http://mako.cc/ Creativity can be a social contribution, but only in so far as society is free to use the results. --GNU Manifesto signature.asc Description: PGP signature
Bug#848202: debian-edu-install: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: debian-edu-install Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. pt_BR.po.gz Description: application/gzip signature.asc Description: Digital signature
Bug#848132: most is vulnerable to a shell injection attack using LZMA-compressed files
Thanks for this. I'll upload a patch for the version in unstable right
away.
Later,
Mako
> Package: most
> Version: 5.0.0a-1
> Severity: grave
> Tags: security patch
> Justification: user security hole
>
> Hello,
>
> the most pager can automatically open files compressed with gzip,
> bzip2 and (in Debian) LZMA.
>
> This is done using popen() and, in earlier releases of most, it was
> vulnerable to a shell injection attack.
>
> most fixed this in v5.0.0 (released in 2007), but the Debian patch
> that added LZMA support (bug #466574) remains vulnerable.
>
> It is trivial to generate a file with a certain name and content that,
> when opened with most, runs arbitrary commands in the user's computer.
>
> most is also launched by other programs as a pager for text files
> (example: an e-mail client that needs to open an attachment). If any
> of those programs generates a temporary file name that can be set by
> an attacker, then that can be used to break into the user's machine.
> I don't have any example of such program, however.
>
> All versions of most >= 5.0.0a-1 including 5.0.0a-2.5 in Debian
> (and derivatives that include the LZMA patch) are vulnerable (older
> versions are vulnerable in all distros as I explained earlier).
>
>https://security-tracker.debian.org/tracker/CVE-2016-1253
>
> I'm attaching the debdiff with the patch. It simply replaces single
> quotes with double quotes in the command passed to popen(). Double
> quotes in the filename are escaped by most in order to prevent this
> kind of attacks, but this offers no protection if the file name is
> enclosed in single quotes.
>
> Regards,
>
> Berto
>
> -- System Information:
> Debian Release: stretch/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages most depends on:
> ii libc6 2.24-7
> ii libslang2 2.3.1-5
>
> most recommends no packages.
>
> most suggests no packages.
>
> -- no debconf information
> diff -Nru most-5.0.0a/debian/changelog most-5.0.0a/debian/changelog
> --- most-5.0.0a/debian/changelog 2016-08-05 02:55:52.0 +0300
> +++ most-5.0.0a/debian/changelog 2016-12-14 14:31:29.0 +0200
> @@ -1,3 +1,12 @@
> +most (5.0.0a-2.6) unstable; urgency=high
> +
> + * Non-maintainer upload.
> + * lzma-support.patch:
> +- Fix CVE-2016-1253 (shell injection attack when opening
> + lzma-compressed files).
> +
> + -- Alberto Garcia Wed, 14 Dec 2016 14:31:29 +0200
> +
> most (5.0.0a-2.5) unstable; urgency=medium
>
>* Non-maintainer upload.
> diff -Nru most-5.0.0a/debian/patches/lzma-support.patch
> most-5.0.0a/debian/patches/lzma-support.patch
> --- most-5.0.0a/debian/patches/lzma-support.patch 2016-07-22
> 01:50:23.0 +0300
> +++ most-5.0.0a/debian/patches/lzma-support.patch 2016-12-14
> 14:25:03.0 +0200
> @@ -1,3 +1,5 @@
> +Index: most-5.0.0a/src/file.c
> +===
> --- most-5.0.0a.orig/src/file.c
> +++ most-5.0.0a/src/file.c
> @@ -77,7 +77,7 @@ static int create_gunzip_cmd (char *cmd,
> @@ -32,13 +34,15 @@
>
> if (cmd != NULL)
> {
> +Index: most-5.0.0a/src/file.h
> +===
> --- most-5.0.0a.orig/src/file.h
> +++ most-5.0.0a/src/file.h
> @@ -22,6 +22,7 @@
> #define MOST_MAX_FILES 4096
> #define MOST_GUNZIP_POPEN_FORMAT "gzip -dc \"%s\""
> #define MOST_BZIP2_POPEN_FORMAT "bzip2 -dc \"%s\""
> -+#define MOST_LZMA_POPEN_FORMAT "lzma -dc '%s'"
> ++#define MOST_LZMA_POPEN_FORMAT "lzma -dc \"%s\""
>
> extern void most_reread_file (void);
> extern void most_read_to_line (int);
--
Benjamin Mako Hill
http://mako.cc/
Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto
signature.asc
Description: PGP signature
Bug#447981: libgdbm3: gdbm_open(... GDBM_NEWDB ...) keeps old entries
control: tag -1 +unreproducible
control: close -1
> In some software I'm using libgdbm=1.8.3-3. Some routine wants to use
> a gdbm file as a kind of non-memory-limited hash, so it tries to open
> some filename with GDBM_NEWDB.
>
> I wondered for some time why this routine gets old entries, until
> looking at an strace revealed that the open() call on the file has
> O_CREAT set, but not O_TRUNC - so no new database seems to be done!
I can't reproduce it. Here is my minimal working example:
#include
#include
#include
#include
int
main(void)
{
GDBM_FILE db = gdbm_open("store.db", 0, GDBM_NEWDB|GDBM_SYNC,
0644, NULL);
datum datum, key;
if (!db) {
fprintf(stderr, "Failed to open database: %s",
gdbm_strerror(gdbm_errno));
return 1;
}
datum.dptr = malloc(100);
datum.dsize = snprintf(datum.dptr, 1000, "%d", (int)
(time(NULL)));
gdbm_store(db, datum, datum, GDBM_REPLACE);
for (key = gdbm_firstkey(db); key.dptr; key = gdbm_nextkey(db,
key)) {
printf("%s\n", key.dptr);
}
return 0;
}
As I understand your report, this program every invokation would output
one more line then on previous. At least on my system, this program
outputs exacly one line -- current time. I linked this program with
libgdbm3_1.8.3-13.1. Same behaviour with libgdbm4.
Moreover, in gdbm-1.12 source there is following lines in src/gdbmopen.c:144
case GDBM_NEWDB:
dbf->desc = open (dbf->name, O_RDWR|O_CREAT|fbits, mode);
need_trunc = TRUE;
break;
I understand, that this bug is almost 10 years old. So with reasoning
above I close it instead of marking +moreinfo/+unreproducible. Feel free
to reopen if you still experience problems.
--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.
pgpAuDcBzca2x.pgp
Description: PGP signature
Bug#847690: dh-elpa: better handling of `deftheme' themes
[2016-12-13 11:23] Sean Whitton > > part 1 text/plain1709 > Hello Dmitry, > > You CCed your message to instead of > <847...@bugs.debian.org>. I've resent it for you. Please check To,Cc > carefully! Sorry. Will make some automatic check one day. > On Tue, Dec 13, 2016 at 01:53:00PM +0300, Dmitry Bogatov wrote: > > I see two actions we can perform to improve our situation. > > > > 1. Install README.Debian file by dh-elpa if we detect that package is > > theme and no README.Debian is already provided. If README.Debian is > > provided, we can grep it for 'package-initialize', to ensure that > > it mentions this issue. > > As I said in another thread, I don't think we should implement code to > merge a note into README.Debian when this is at best a temporary > solution. Too many edge cases. Fine. I agree, that fixing limitation is better then documenting it. > > 2. We can advice #'load-theme. Something like this: > > [...] > Thank you very much for this code snippet. dh_elpa could add it to the > emacsen-startup script for a theme package. I'll look into implementing > this towards the end of this month. Ok. -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff| is urgent, you have my phone number. pgpYx2wbn1uUc.pgp Description: PGP signature
Bug#829299: Bug#847040: evil-el: test suite fails under emacs25
[2016-12-13 11:02] Sean Whitton > On Wed, Dec 07, 2016 at 09:34:13AM +0300, Dmitry Bogatov wrote: > > I switched to emacs25 already (since this bug report). So far, no > > changes. > > > > > - Could you fix #829299 based on the private e-mails we exchanged a few > > > weeks ago, please? > > > > I already pushed (but not released) fix for #829299 (d057d2). > > It's been a week since we last discussed this. Have you been using > evil-el with emacs25 every day, without any problems? If so, it would > be great if you could make an upload fixing both of these bugs. I pushed change (1a1ee03a87f30718c488358cabd893e39daa3a79) and made RFS. > When you add a patch commenting out the tests, please annotate it so > that it is clear that this is a temporary fix that should eventually be > removed. I did. Feel free to adjust wording. -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff| is urgent, you have my phone number. pgpYAgnIRvcNf.pgp Description: PGP signature
Bug#374354: libgdbm3: gdbm_open continually reopens file in a loop until it runs out of file descriptors and fails.
control: close -1
> When I try yo invoke gdbm_open, the call appears to internally open and
> reopen the specified file until we run out of file descriptors, at which
> point gdbm_open fails with gdbm_errno 3(File open failure) and errno 24
> (Too many open files).
>
> This will officially be my first bug report, so be kind if I make any
> faux pauxes! Thanks. :)
Your first bug report is very good. Thank you.
But it is not real bug. Issue is that you call your function `write',
which is collision with normal write(2) function.
In this situation I would expect linker error, but what actually happens
is that your function shadows write(2) one. Problem is that `gdbm_open'
internally uses write(2), so here we have endless rescursion.
If you have little available descriptors, result will be as you described.
If you have many available described, result will be stack overflow and
segfault. It happens on my system.
Try renaming your `write' function into `my_own_write' and check again.
Closing bug for now. Feel free to reopen it, if `my_own_write' would still
misbehave.
> #include
> #include
> #include
>
> void write()
> {
> GDBM_FILE dbf;
>
> if( (dbf = gdbm_open("test.gdb", 0, GDBM_NEWDB, 0640, NULL)) == NULL)
> {
> printf("dat file open error (%d,%d): %s/%s\n", gdbm_errno, errno,
> gdbm_strerror(gdbm_errno), strerror(errno));
> exit(1);
> }
>
> gdbm_close(dbf);
> }
>
> int main()
> {
> write();
> }
BTW, main function must return something, otherwise exit code is
undefined.
--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.
pgpxQoWO9Tful.pgp
Description: PGP signature
Bug#848199: RFS: evil-el/1.2.12-2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "evil-el" * Package name: evil-el Version : 1.2.12-2 Upstream Author : Vegard Øye * Url : https://bitbucket.org/lyro/evil/wiki/Home * Licenses: GPL-3+,GFDL-1.3+,GPL-2+ Section : lisp It builds those binary packages: * elpa-evil To access further information about this package, visit the following URL: https://mentors.debian.net/package/evil-el Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/evil-el/evil-el_1.2.12-2.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el.git More information about evil-el can be obtained from https://bitbucket.org/lyro/evil/wiki/Home Changes since last upload: [ Sean Whitton ] * Team upload. * Fix Vcs-* URIs. [ Dmitry Bogatov ] * Run tests only if standards streams are terminals (Closes: #829299) * Temporary skip test suite, which fails with emacs25 (Closes: #847040) Regards, Dmitry Bogatov
Bug#211119: libgdbm3: ordered traversal option for firstkey/nextkey?
control: tag -1 +wontfix control: close -1 [2003-09-16 02:02] Colin Watson > It'd be nice to have a flag to gdbm_setopt() or similar which would > cause gdbm_firstkey() and gdbm_nextkey() to return entries in a > lexicographically sorted fashion, or I suppose even with an arbitrary > comparison function if somebody were feeling particularly industrious > (although I don't need that myself). When migrating man-db from Berkeley > DB to GDBM and brushing up the old support code, I just had to write a > hashtable of ordered hashtables in order to do the sort myself without > turning lots of code upside down, which is not the most pleasant data > structure in the world. > > I'm guessing that gdbm could also manage a more efficient sorted > traversal internally than I can in a wrapper. This bugreport asks for very significant change, so it is better to discuss it directly with upstream. -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff| is urgent, you have my phone number. pgpwbJdd20RYh.pgp Description: PGP signature
Bug#200799: libgdbm-dev: ndbm compatibility has gone missing
control: close -1 control: tag -1 +wontfix [2003-07-10 23:27] Wichert Akkerman > > part text/plain 825 > Package: libgdbm-dev > Version: 1.8.3-1 > Severity: normal > > On an unstable system: > > [typhoon;/usr/include]-18> objdump -t /usr/lib/libgdbm.a| grep > '\ > and on a stable system: > > [klecker;~]-1> objdump -t /usr/lib/libgdbm.a| grep '\ g F .text 015c dbm_open Now these interfaces (gdbm, gdbm-compat) are separated at binary package level. -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff| is urgent, you have my phone number. pgp7LalsOqGTN.pgp Description: PGP signature
Bug#848200: RFS: eoconv/1.4-2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "eoconv" * Package name: eoconv Version : 1.4-2 Upstream Author : Tristan Miller * Url : http://en.nothingisreal.com/wiki/Eoconv * Licenses: GPL-3+ Section : text It builds those binary packages: * eoconv To access further information about this package, visit the following URL: https://mentors.debian.net/package/eoconv Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/eoconv/eoconv_1.4-2.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/cgit/users/kaction-guest/eoconv.git More information about eoconv can be obtained from http://en.nothingisreal.com/wiki/Eoconv Changes since last upload: * Fix corrupting utf8 text (Closes: #824407) * Install upstream changelog * Bump standards version to 3.9.8 (No changes needed) Regards, Dmitry Bogatov
Bug#848198: ITP: fonts-noto-color-emoji -- Color emoji set from Android
Package: wnpp Severity: wishlist Owner: "Ming-ting Yao Wei (魏銘廷)" * Package name: fonts-noto-color-emoji * URL : https://www.google.com/get/noto/help/emoji/ * License : Apache 2.0 Description : Color emoji set from Android Noto color emoji is the emoji font set originated from the Android project. It currently supports Unicode 9.0 specs with emojis for different skin tones and family forms. A Debian user discovered that Jessie includes the fontconfig capable of rendering color emoji, but needs a workaround for a bug fixed in newer fontconfig that is not in Debian main yet: http://stdio.tumblr.com/post/114082931782 Currently this package should be best maintained with the supports from Debian Fonts Task Force.
Bug#848195: nvidia-graphics-drivers: CVE-2016-8826
Source: nvidia-graphics-drivers Severity: serious Tags: security Control: clone -1 -2 -3 Control: reassign -2 src:nvidia-graphics-drivers-legacy-340xx Control: retitle -2 nvidia-graphics-drivers-legacy-340xx: CVE-2016-8826 Control: reassign -3 src:nvidia-graphics-drivers-legacy-304xx Control: retitle -3 nvidia-graphics-drivers-legacy-304xx: CVE-2016-8826 http://nvidia.custhelp.com/app/answers/detail/a_id/4278 CVE-2016-8826 NVIDIA GPU Display Driver contains a vulnerability in the kernel mode layer (nvlddmkm.sys for Windows or nvidia.ko for Linux) where a user can cause a GPU interrupt storm, leading to a denial of service. Fixed versions: R375375.26 R340340.101 R304304.134
Bug#847681: packaging repository and sid diverging? Various fixes needed.
Sven Geggus writes: > Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 11:01 Uhr: > >> Would you consider uploading it or proposing it in mentors.debian.net? >> Please also send details on the gss-proxy ITP bug. > > Robbie is the one with the ITP bug, not me :) > > I just pushed my custom package data to github though: > https://github.com/giggls/gssproxy Hi, glad the github fork was useful. I have the bulk of my package done for the ITP, but haven't gotten init-related functionality working yet. Upstream (that's Simo and me, though this is Simo's decision) prefer the name "GSS-Proxy" for anything written in a sentence, and "gssproxy" for everything else. The package in Fedora and RHEL/CentOS is called "gssproxy", for instance. As for the NFS pieces: upstream, we package example configuration files for an NFS server, apache (mod_auth_gssapi), and an NFS client. We don't provide any additional scripting for NFS; NFS takes care of that. Hope that helps, --Robbie signature.asc Description: PGP signature
Bug#834800: Pending fixes for bugs in the libkavorka-perl package
tag 834800 + pending thanks Some bugs in the libkavorka-perl package are closed in revision a216d482b260c5bfa929e0bb86c887d5f4c9ca44 in branch 'master' by Jonas Smedegaard The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libkavorka-perl.git/commit/?id=a216d48 Commit message: Fix dependency on Data::Alias: Add patch 1001 to use recent Perl instead of Data::Alias. (Build-)depend on recent perl favored over libdata-alias-perl. Closes: Bug#834800. Thanks to Daniel Dehennin.
Bug#834800: Info received (libkavorka-perl: depends on libdata-alias-perl, broken with Perl 5.24)
Excerpts from Daniel Dehennin's message of December 14, 2016 11:49 pm: Jonas Smedegaard writes: Excerpts from Daniel Dehennin's message of December 14, 2016 2:41 pm: You can find the fix in the following pull request, the package build fine with all test passing. The Moops tests are fine too. Thanks a lot! I will hae a closer look and (most likely) apply to the Debian package in a moment... I may have forgotten the Makefile.PL and META.*, it looks like it does not prevent the package to build but as I'm not an expert of this part I prefer to warn you. Thanks for sharing your concern. We don't need to keep those files in sync for our Debian packaging (and upstream the packaging tool Dist::Inkt takes care of automating those files). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgp_HaKOY_G6J.pgp Description: PGP signature
Bug#847792: RFS: usbguard/0.6.2+ds1-1
Control: tag -1 + pending Hi, Muri Nicanor wrote: > I am looking for a sponsor for my package "usbguard" […] > https://mentors.debian.net/package/usbguard Looks fine to me. Will upload soon. Thanks for maintaining usbguard in Debian! Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#848194: Want way to get Release (or InRelease) file from cache
Control: severity -1 wishlist (Sorry, forgot that.) Ian.
Bug#848194: Want way to get Release (or InRelease) file from cache
Package: apt Version: 1.3.1 Control: block 848193 by -1 Dear apt maintainers: I would like a way to get the [In]Release file corresponding to the source from which apt got (or, I guess, would install) a particular package. I can use `apt-cache madison' to find the archive URL and the locations within that archive. The [In]Release file has a predictable filename (derived from the URL) in the apt cache. May I fish the [In]]Release file out of the apt cache ? Things I want to avoid include: * Breaking if apt changes the cache layout. How likely is this ? Relying on the cache url->filename mangling seems a bit rude. * Consuming a file whose signature has not been verified by apt. That would be a vulnerability. * Becoming confused if there are both Release and InRelease files. I guess I can just use InRelease if I find both ? * Implementing my own signature verification, resulting in the possibility that my set of approved public keys or my verification criteria might differ from apt's. Do you have advice for me ? If there is not currently a good way of getting this information (which there may not be) then please take this wishlist bug as a request for a way to get it. Also, in that case, please let me know whether it would be bad of me to implement my approach as described above, in the meantime. Thanks for any help you can provide. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#830208: dh_installinit tries to do dh_systemd_start's job
On 19 July 2016 at 13:28, Niels Thykier wrote:
> Hi Peter,
>
> Thanks for the report - at first glance it sounds like #830208 (Cc'ed
> accordingly).
>
> Peter's message quoted in full (for those not subscribed to
> debhelper-devel):
>
>> Hi,
>>
>> Now that dh_systemd_start and dh_systemd_enable are part of debhelper
>> proper, there's a bit of duplication of work between dh_installinit and
>> dh_systemd_start. Now don't get me wrong: I do agree that installing
>> and configuring systemd service files correctly is a Good Thing(tm);
>> it's just that I'm afraid that there are some more rough edges to
>> polish.
>>
>> So far I've only seen the problem in a package that provides both
>> a systemd service file and a SysV init script. If the service file is
>> named debian/package.service, dh_systemd_start and dh_systemd_enable
>> will pick it up and process it just fine... but then dh_installinit will
>> *also* pick it up. It's invoked because debian/package.init exists, but
>> it tries to process systemd and upstart files, too, if it finds them,
>> so it tries to do once again what dh_systemd_start just did, and, well,
>> it even gets it subtly wrong :)
>>
>> So, hm, I'm not sure what the proper resolution would be. Would it be
>> possible for dh_installinit to figure out that the systemd sequence is
>> enabled? If so, then this might be the best solution - in compat 10
>> with the systemd sequence enabled, ignore any systemd service files.
>>
>> Again, don't get me wrong, I *am* very happy with the way debhelper
>> development is progressing; thanks a lot for that!
>>
>> G'luck,
>> Peter
>>
>> [...]
>
> Michael/Martin: What is your take - should we just disable the service
> handling in dh_installinit for compat 10 or newer? AFAICT, it should
> "just work(tm)" and now would be the time to do it if we want it in
> compat 10.
I think that installinit should stop looking at .service and .tmpfiles.
Making dh_installinit ignore .service and .tmpfiles is a compat break
so I think this should only be enabled for compat >= 11. I think
something like the attached patch should do.
--
Saludos,
Felipe Sateler
From 47f5c88087f204431c7db6b873c10d69accf1572 Mon Sep 17 00:00:00 2001
From: Felipe Sateler
Date: Wed, 14 Dec 2016 22:31:27 -0300
Subject: [PATCH] installinit: do not process systemd files from compat 11
onwards
---
debhelper.pod | 6
dh_installinit | 12
t/dh_installinit/debian/changelog | 5
t/dh_installinit/debian/compat | 1 +
t/dh_installinit/debian/control | 20 +
t/dh_installinit/debian/foo.service | 5
t/dh_installinit/dh_installinit.t | 57 +
7 files changed, 101 insertions(+), 5 deletions(-)
create mode 100644 t/dh_installinit/debian/changelog
create mode 100644 t/dh_installinit/debian/compat
create mode 100644 t/dh_installinit/debian/control
create mode 100644 t/dh_installinit/debian/foo.service
create mode 100755 t/dh_installinit/dh_installinit.t
diff --git a/debhelper.pod b/debhelper.pod
index e7697ead..c9a3739e 100644
--- a/debhelper.pod
+++ b/debhelper.pod
@@ -586,6 +586,12 @@ F files are still installed.
=item -
+B no longer installs F or F files, nor
+generates maintainer scripts for those files. Use B and
+B instead.
+
+=item -
+
The B<-s> (B<--same-arch>) option is removed.
=item -
diff --git a/dh_installinit b/dh_installinit
index 087a3bd8..3f80d127 100755
--- a/dh_installinit
+++ b/dh_installinit
@@ -47,13 +47,13 @@ build directory.
=item debian/I.service
If this exists, it is installed into lib/systemd/system/I.service in
-the package build directory.
+the package build directory. Only compat levels 10 and below.
=item debian/I.tmpfile
If this exists, it is installed into usr/lib/tmpfiles.d/I.conf in the
package build directory. (The tmpfiles.d mechanism is currently only used
-by systemd.)
+by systemd.) Only compa levels 10 and below.
=back
@@ -216,14 +216,16 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
}
}
- my $service=pkgfile($package,"service");
+ my $service='';
+ $service=pkgfile($package,"service") if compat(10);
if ($service ne '' && ! $dh{ONLYSCRIPTS}) {
my $path="$tmp/lib/systemd/system";
install_dir($path);
install_file($service, "$path/$script.service");
}
- my $tmpfile=pkgfile($package,"tmpfile");
+ my $tmpfile='';
+ $tmpfile=pkgfile($package,"tmpfile") if compat(10);
if ($tmpfile ne '' && ! $dh{ONLYSCRIPTS}) {
my $path="$tmp/usr/lib/tmpfiles.d";
install_dir($path);
@@ -254,7 +256,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
error("Can't use --init-script with an upstart job");
}
- if (!$dh{NOSCRIPTS}) {
+ if (compat(10) && !$dh{NOSCRIPTS}) {
# Include postinst-init-tmpfiles if the package ships any files
# in /usr/lib/tmpfiles.d or /etc/tmpfiles.d
my @tmpfiles;
diff --git a/t/dh_installinit/debian/changelog b/t/dh_installinit/debian/changelog
new f
Bug#848193: Want "dgit clone RUNNING" or some such
Package: dgit Version: 1.21 Severity: wishlist I would like dgit clone to be able to give you `the source for the package I am running'. (It gives you sid by default.) This involves knowing the relevant suite, at the very least. AFAICT this can be done as follows: Run `apt-cache madison SOURCEPACKAGE'. Parse the output, discarding non-matching entries (since binary package entries may appear too). Perhaps check that the version number matches the installed version. Extract the URL. Look in the apt cache(!) to find the InRelease or Release file. Extract the `Suite' field. Extract the `Origin' field too, and look it up in the dgit config to map it to a dgit distro. A problem with this is how to know whether the InRelease file is accurate. It probably doesn't matter very much if it's not up to date (since it was at least up to date enough to get the package installed, if apt installed it). But what if it is broken somehow, or the signature didn't verify ? Also, going behind apt's back like this to look at the cache is pretty ugly. But if dgit downloads the file itself, this would still require dgit to verify the signature somehow. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#813754: [Pkg-mpd-maintainers] Bug#813754: Bug#813754: Bug#813754: Can't open port 6600 when run syste, -wide vis systemd
On martes, 13 de diciembre de 2016 21:23:46 ART Florian Schlichting wrote: > Hi Matthew, > > On Tue, Dec 13, 2016 at 05:34:28AM -0500, Matthew E. J. Draisey wrote: > > I just fixed a situation where I couldn't get mpd to work over my home > > network. I think it may be this same issue. > > > > On my system > > > > # sysctl net/ipv6/bindv6only > > net.ipv6.bindv6only = 1 > > > > netstat would show init listening on [::]:6600 but doesn't report the > > IPV6_V6ONLY socket state so I had missed there was no socket listening on > > ipv4. > > > > Adding > > > > [Socket] > > BindIPv6Only=both > > > > to the mpd.socket unit fixed my problem. > > that's an interesing observation. Lisandro could you check that? Yes, and while the mentioned workaround doesn't solves my issue it clearly has something to do. Remember my original bug where I stated that I needed to stop the systemd service and then start it by the init.d script? Well, thanks to this I've discovered that if I stop mpd.socket and then restart mpd.service I get both the IPV4 and IPV6 6600 port opened, whereas with mpd.socket I can only open the IPV6 one. Yes, my system also has net.ipv6.bindv6only = 1 (I don't remember changing it myself). If I stop mpd.socket/service and then: sysctl -w net.ipv6.bindv6only=0 and then restart mpd.socket I still only get the IPV6 behavior. Now I'm going to update this machine (it has been off for ~3 months) and try again. > AFAIK net.ipv6.bindv6only defaults to "both", so as a package maintainer > I wouldn't override a local configuration where the admin has decided to > deviate from the default. Well, I don't remember having changed this, but it's clearly ipv6only here :-/ -- No subestimes el ancho de banda de un camión cargado de cintas. Andrew S. Tanenbaum Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#848178: Close bug
Phillip, Thanks for your quick reply. It was as you had said, that libtesseract3 had not been updated. This must be a problem with apt- get as I had just updated using it before I sent the bug report in and libtesseract3 had not been updated as I wanted to make sure that the bug had not already been fixed. I've been using apt-get because aptitude has been failing me for at least a year and I'd just given up on using it. It would get to the point of checking which packages needed to be updated and then just run on for a half hour or so until it would finally stall and I've have to close it using Ctrl-C. Then, miracle of miracles today aptitude worked when I tried it after realizing apt-get wasn't updating all the packages. It updated over 300 packages that apt-get has been missing. Sorry to have sent you more work on such a stupid basis. Joe
Bug#651590: [reportbug/master] port GTK interface to GTK3; thanks to Simon McVittie for sending all the patches to implement this; Closes: #651590
tag 651590 pending tag 651590 pending thanks Date: Wed Dec 14 19:33:43 2016 -0500 Author: Sandro Tosi Commit ID: 8bf3b77a6fab9ea9d6a537e716ed0f3afbd2a81e Commit URL: http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=8bf3b77a6fab9ea9d6a537e716ed0f3afbd2a81e Patch URL: http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=8bf3b77a6fab9ea9d6a537e716ed0f3afbd2a81e port GTK interface to GTK3; thanks to Simon McVittie for sending all the patches to implement this; Closes: #651590
Bug#848192: /usr/bin/dh_systemd_start: dh_systemd_start needs to start .socket before .service
Package: debhelper Version: 10.2.2 Severity: normal File: /usr/bin/dh_systemd_start When I have both a service and a socket unit file, dh_systemd_start runs the service first. This is bad because the socket will refuse to run when the service has been started, while the service's configuration probably depends on the socket. deb-systemd-invoke $_dh_action knxd.service knxd.socket >/dev/null || true Please re-order to act on the socket first. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable'), (600, 'stable'), (550, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-rc5-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 debhelper depends on: ii autotools-dev20161112.1 ii binutils 2.27.51.20161127-1 ii dh-autoreconf12 ii dh-strip-nondeterminism 0.028-1 ii dpkg 1.18.15 ii dpkg-dev 1.18.15 ii file 1:5.29-1 ii libdpkg-perl 1.18.15 ii man-db 2.7.5-2 ii perl 5.24.1~rc3-3 ii po-debconf 1.0.20 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 2.201608 -- no debconf information
Bug#847681: packaging repository and sid diverging? Various fixes needed.
On Wed, 2016-12-14 at 09:38 +0100, Daniel Pocock wrote: > > On 14/12/16 08:24, Andreas Henriksson wrote: > > On Wed, Dec 14, 2016 at 08:11:52AM +0100, Daniel Pocock wrote: > > > I agree the loss of Debian packaging history is a concern, that is one > > > reason I didn't clobber the existing repository and I wrote that we can > > > blow this away if there isn't consensus about it. > > > > Yeah, but ever more importantly now is to not get stuck on details I guess. > > > > > It will not be too hard to switch back and forth between the two > approaches, so lets leave the final decision on that for another couple > of weeks. > > The bigger issues: > > - should it live in the kernel section on alioth (where only members of > that team can commit) or collab-maint (where any DD can commit)? I would suggest a new project. That gives you mailing lists and the ability to add your own repository hooks. (Hooks are restricted in collab-maint for hopefully obvious reasons.) rpcbind probably also belongs in that project. Maybe gssproxy too. (Even though neither is strictly specific to NFS.) > - should it continue to list the kernel packaging team as the > maintainer, or is there potentially another team suitable for it? Given > the server-side stuff is partly kernel code, there is a strong reason > for the kernel team to see all the bug reports Now I remember, that was one of my reasons for wanting to move nfs- utils to kernel team maintenance. At the time, many or even most of the open bugs against 'nfs-kernel-server' were kernel bugs, not bugs in that package. However, that hasn't been a big issue and it shouldn't be hard for nfs-utils maintainers to continue reassigning obvious kernel-side bugs. > - does it actually work for more people? I only did basic tests of the > new 1.3.4 package with NFS 3 and a single client in a jessie system the > latest kernel from jessie-backports. Somebody should probably test the > package on a system running stretch or sid and also try the NFSv4 stuff. Ideally you would have some sort of automated tests that spin up different configurations of NFS servers and clients in some containers or VMs. (Containers would be way quicker but VMs would let you control the kernel version too.) > - does anybody have time to fully review major upstream changes? These > are things I noticed: > > Upstream now installs nfsdcltrack to /sbin - does the Debian kernel look > for it in that location too or does it want /usr/sbin/nfsdcltrack or was > that just a bug in the jessie package putting it in the wrong place? [...] The kernel's default has always been /sbin/nfsdcltrack. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#651590: reportbug: Reportbug doesn't have a GTK3 interface yet
> Here are some patches that seem to basically work. They aren't > perfectly broken up to do one thing per commit, but they're as close to that > as I had the patience for. > > There are probably still bugs in this implementation, but it works a lot > better than failing to import completely (I'm sending this report using it). OMG thanks a lot Simon! I just merged all your patches and will release reportbug soon with them! will you be interested in keep having a look at the GTK+ interface in reportbug? if you are, here is a handy link to the current bugs in the bts for it: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=reportbug;dist=unstable#_0_22_3 Again, thanks a lot! -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#848191: clang-3.8: scan-view-3.8 can't find python module ScanView in its path
Package: clang-3.8 Version: 1:3.8.1-16 Severity: important Tags: patch Hi, When running scan-view-3.8 after a scan-build, it can't find the ScanView module: $ scan-view /tmp/scan-build-2016-12-14-152605-2260-1 /usr/bin/../share/clang/scan-view Traceback (most recent call last): File "/usr/bin/scan-view", line 144, in main() File "/usr/bin/scan-view", line 141, in main run(port, args, args.root) File "/usr/bin/scan-view", line 71, in run import ScanView ImportError: No module named ScanView Looking at scan-view-3.8, the way it adds the directory to its path is different depending on whether /usr/share/clang/scan-view-3.8/bin/scan-view is called or its symbolic link at /usr/bin/scan-view-3.8. Quick fix: --- /usr/share/clang/scan-view-3.8/bin/scan-view-3.8.old2016-12-14 15:54:11.107830663 -0800 +++ /usr/share/clang/scan-view-3.8/bin/scan-view2016-12-14 16:07:16.868125122 -0800 @@ -61,7 +61,7 @@ def run(port, options, root): # Prefer to look relative to the installed binary -share = os.path.dirname(__file__) + "/../share/" +share = os.path.dirname(os.path.realpath(__file__)) + "/../share/" if not os.path.isdir(share): # Otherwise look relative to the source share = os.path.dirname(__file__) + "/../../scan-view/share" Cheers, Jordi -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages clang-3.8 depends on: ii binutils 2.27.51.20161201-1 ii libc62.24-7 ii libc6-dev2.24-7 ii libclang-common-3.8-dev 1:3.8.1-16 ii libclang1-3.81:3.8.1-16 ii libgcc-6-dev 6.2.1-5 ii libgcc1 1:6.2.1-5 ii libllvm3.8 1:3.8.1-16 ii libobjc-6-dev6.2.1-5 ii libstdc++-6-dev 6.2.1-5 ii libstdc++6 6.2.1-5 Versions of packages clang-3.8 recommends: ii llvm-3.8-dev 1:3.8.1-16 ii python2.7.11-2 Versions of packages clang-3.8 suggests: pn clang-3.8-doc pn gnustep pn gnustep-devel -- no debconf information
Bug#848189: /usr/bin/dpkg-parsechangelog: dpkg-parsechangelog doesn't parse from stdin by default as claimed in the manpage
Package: dpkg-dev Version: 1.18.15 Severity: normal File: /usr/bin/dpkg-parsechangelog Dear Maintainer, The dpkg-parsechangelog manual page says: --file file Set the changelog filename to parse. Default is ‘-’ (standard input). That is, however, not the case. It actually reads the debian/changelog file, even when stdin is a pipe: $ git show esr45/master:debian/changelog | dpkg-parsechangelog --file - -S Version 45.6.0esr-1 $ git show esr45/master:debian/changelog | dpkg-parsechangelog -S Version 50.1.0-1 $ dpkg-parsechangelog --file debian/changelog -S Version 50.1.0-1 $ dpkg-parsechangelog -S Version 50.1.0-1 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg-dev depends on: ii binutils 2.27.51.20161212-1 ii bzip2 1.0.6-8 ii libdpkg-perl 1.18.15 ii make 4.1-9 ii patch 2.7.5-1 pn perl:any ii tar 1.29b-1.1 ii xz-utils 5.2.2-1.2 Versions of packages dpkg-dev recommends: ii build-essential 12.2 ii fakeroot 1.21-3 ii gcc [c-compiler] 4:6.2.1-1 ii gcc-6 [c-compiler] 6.2.1-6 ii gnupg2.1.16-3 ii gpgv 2.1.16-3 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: pn debian-keyring -- no debconf information
Bug#848185: [/master] Build-depend on bash-completion.
tag 848185 pending thanks Date: Thu Dec 15 00:50:28 2016 +0100 Author: Bernd Zeimetz Commit ID: c7545672b18ecdb9fc7570db7fc0ebc2c769a649 Commit URL: http://anonscm.debian.org/gitweb/?p=collab-maint/gmic.git;a=commitdiff;h=c7545672b18ecdb9fc7570db7fc0ebc2c769a649 Patch URL: http://anonscm.debian.org/gitweb/?p=collab-maint/gmic.git;a=commitdiff_plain;h=c7545672b18ecdb9fc7570db7fc0ebc2c769a649 Build-depend on bash-completion. Quick fix for FTBFS where /etc/bash_completion.d only exists on a few buildds. Closes: #848185 Thanks: Adrian Bunk
Bug#848121: [Pkg-sysvinit-devel] File conflict between manpages and initscripts
Michael Kerrisk (man-pages) writes ("Re: Bug#848121: [Pkg-sysvinit-devel] File
conflict between manpages and initscripts"):
> On 14 December 2016 at 16:45, Ian Jackson
> wrote:
> > - rename the manpage about /etc/default/tmpfs to tmnfs-config(5)
> >(or something, better name welcome).
>
> FWIW, I think this may be the best option.
I do see that the arguments against changing all the filesystem
manpages are pretty strong.
It's not quite clear to me quite who the maintainers of the sysvinit
package are - ie, who needs to agree. I have been following the
sysvinit package for a while now but have not had any time to do
anything particularly useful. The Alioth group lists a number of
people.
(Actually, I should ask to become a member of the team... done.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#795018:
Hello, I realise this bug report is one and a half years old, but since I've just experienced the same thing, it might be useful to share here what I found. I do not believe this is a bug. It is just how oinkmaster works. Oinkmaster is only going to process the rule files that are part of the archive to download as per the 'url' variable in 'oinkmaster.conf'. This means that the default suricata rules at '/etc/suricata/rules' are not going to be touched. The way I worked around this, and to allow the default suricata rules to be processed by oinkmaster and honor 'disablesid' directives was to supply an additional 'url' variable pointing to '/etc/suricata/rules' and have oinkmaster's 'outdir' be another directory, e.g. 'processed-rules'. oinkmaster.conf would have something like: url = dir:///etc/suricata/rules > > url = > https://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz So oinkmaster would be run like: oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/processed-rules Also make sure to update suricata.yml with 'default-rule-path' to point to the correct 'outdir' (processed-rules) so suricata loads the correct rules. Hope that helps someone. Cheers, José Santos
Bug#731998: Multiarchifying libcurl4-*-dev
First, note that this issue is more serious in jessie and stretch than
it was in wheezy, because in wheezy, libcurl4-*-dev Depended on a
bunch of packages that were not multiarch-compatible (and thus,
libcurl4-*-dev was not co-installable in practice.) In jessie,
however, those other packages are merely Suggested.
Here are patches that should fix the issue (for the jessie version;
the same changes ought to work for the stretch/sid versions but I
haven't tried.)
(When I actually tried building these packages, for amd64 and i386, I
found that the curl-config scripts still differed, which was
apparently because I had 'libnghttp2-dev' installed in the amd64 build
system for some reason - it seems curl will use that package if it's
available. I'm pretty sure that if both builds are done in clean
environments, the curl-config scripts will be identical. But that's
something to be aware of, and maybe the package should either support
and build-depend on libnghttp2-dev, or explicitly disable it.)
One side issue that I didn't address is that `pkg-config --cflags
libcurl` will now output -I/usr/include/, which is not ideal,
but acceptable (if you're using pkg-config and building for a
"foreign" architecture, you'll probably need to set appropriate
pkg-config environment variables anyway.)
In order to (partially) multi-arch-ify curl-config, remove all mention
of @includedir@ and @libdir@ from the script. On Debian, the actual
header and library directories are architecture-dependent, but will
always be in the C compiler's default search path, so -I and -L
options are not necessary (and may be harmful in multi-arch
environments.)
Index: curl-7.38.0/curl-config.in
===
--- curl-7.38.0.orig/curl-config.in
+++ curl-7.38.0/curl-config.in
@@ -23,7 +23,6 @@
prefix=@prefix@
exec_prefix=@exec_prefix@
-includedir=@includedir@
cppflag_curl_staticlib=@CPPFLAG_CURL_STATICLIB@
usage()
@@ -134,19 +133,11 @@ while test $# -gt 0; do
else
CPPFLAG_CURL_STATICLIB=""
fi
-if test "X@includedir@" = "X/usr/include"; then
- echo "$CPPFLAG_CURL_STATICLIB"
-else
- echo "${CPPFLAG_CURL_STATICLIB}-I@includedir@"
-fi
+echo "$CPPFLAG_CURL_STATICLIB"
;;
--libs)
-if test "X@libdir@" != "X/usr/lib" -a "X@libdir@" != "X/usr/lib64"; then
- CURLLIBDIR="-L@libdir@ "
-else
- CURLLIBDIR=""
-fi
+CURLLIBDIR=""
if test "X@REQUIRE_LIB_DEPS@" = "Xyes"; then
echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
else
@@ -156,7 +147,7 @@ while test $# -gt 0; do
--static-libs)
if test "X@ENABLE_STATIC@" != "Xno" ; then
- echo @libdir@/libcurl.@libext@ @LDFLAGS@ @LIBCURL_LIBS@
+ echo -Wl,-Bstatic -lcurl -Wl,-Bdynamic @LDFLAGS@ @LIBCURL_LIBS@
else
echo "curl was built with static libraries disabled" >&2
exit 1
--- curl-7.38.0.orig/debian/rules 2016-11-01 17:38:10.0 -0400
+++ curl-7.38.0/debian/rules 2016-12-14 16:15:53.85200 -0500
@@ -9,9 +9,13 @@
# enable all hardening options (see #763372)
export DEB_BUILD_MAINT_OPTIONS:=hardening=+all
+DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+
CONFIGURE_ARGS = -- --disable-dependency-tracking \
--disable-symbol-hiding --enable-versioned-symbols \
- --enable-threaded-resolver --with-lber-lib=lber --with-gssapi=/usr
+ --enable-threaded-resolver --with-lber-lib=lber --with-gssapi=/usr \
+ --includedir=/usr/include/$(DEB_HOST_MULTIARCH)
%:
dh $@
@@ -72,6 +76,27 @@
dh_install -pcurl -plibcurl3 -plibcurl4-openssl-dev -plibcurl4-doc \
--sourcedir=debian/tmp
sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'`
+# Modify curl-config to make it architecture-independent:
+# 1. In --static-libs output, replace the output of krb5-config (which
+#currently includes architecture-specific paths) with a call at
+#runtime to krb5-config. Of course, this will only work correctly
+#if the installed libkrb5-dev matches the architecture of the
+#program you're linking, or if libkrb5-dev is made
+#multiarch-compatible at some point in the future. For dynamic
+#linking this has no impact.
+# 2. In --configure output, replace the architecture-specific paths
+#used for --libdir and --libexecdir with a literal backquoted call
+#to dpkg-architecture. This is functionally equivalent to the way
+#debhelper actually invokes configure, and indicates to the user
+#(who runs curl-config --configure in order to learn about how the
+#library was compiled) that they are in fact using a multi-arch
+#package.
+# 3. Likewise, replace the architecture name used for --build (and
+#build_alias) with a literal backquoted call to dpkg-architecture.
+ sed -e "/-lcurl /s|`krb5-config --
Bug#848060: libx11-protocol-other-perl: FTBFS randomly (failing tests)
Sorry for the duplicate, mutt segfaults...
Bug#847549: kernel bug dcache.c 2373 invalid opcode 0000 d_materialise_unique
Control: tag -1 moreinfo
On Fri, 9 Dec 2016 09:35:40 +0100 Daniel Pocock wrote:
> Package: linux
> Version: 3.16.36-1+deb8u1
> Severity: important
>
> The system is an NFS server running linux-image-3.16.0-4-amd64
>
> At times of heavy load on NFS, such as "git checkout some-branch" in a
> large repository, the system crashes (dmesg output attached). It has
> been happening regularly since the upgrade to jessie and with every
> kernel released through stable updates. I don't recall seeing this in
> wheezy.
>
> I've installed kdump-tools. Sometimes it captures the dmesg output, a
> recent example from a crash on 2016-12-02 is attached. I'm not sure if
> the crashes without /var/crash logs are the same bug.
>
> The same crash was reported[1] on linux-fsdevel by another Debian user.
Can you test the attached patches? The first is the one J. Bruce
Fields pointed to and the second is in the same area; both of them went
upstream in 3.17.
Instructions for rebuilding the kernel with patches:
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
> I don't mind trying a backports kernel as a workaround, but can anybody
> comment on whether the backports kernel 4.7.8-1~bpo8+1 will match with
> the NFS user space packages in jessie, or do I need to update some of
> those packages too?
[...]
I don't believe that's necessary; no-one has asked for a backport of
nfs-utils.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
From: "J. Bruce Fields"
Date: Mon, 17 Feb 2014 17:45:56 -0500
Subject: dcache: close d_move race in d_splice_alias
Origin: https://git.kernel.org/linus/75a2352d0110960aeee1a28ddc09a55f97c99100
Bug-Debian: https://bugs.debian.org/847549
d_splice_alias will d_move an IS_ROOT() directory dentry into place if
one exists. This should be safe as long as the dentry remains IS_ROOT,
but I can't see what guarantees that: once we drop the i_lock all we
hold here is the i_mutex on an unrelated parent directory.
Instead copy the logic of d_materialise_unique.
Reviewed-by: Christoph Hellwig
Signed-off-by: J. Bruce Fields
Signed-off-by: Al Viro
---
fs/dcache.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 8bdae36a095f..8c09db9bb2a4 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1907,9 +1907,14 @@ struct dentry *d_splice_alias(struct inode *inode, struct dentry *dentry)
new = __d_find_alias(inode, 1);
if (new) {
BUG_ON(!(new->d_flags & DCACHE_DISCONNECTED));
+ write_seqlock(&rename_lock);
+ __d_materialise_dentry(dentry, new);
+ write_sequnlock(&rename_lock);
+ __d_drop(new);
+ _d_rehash(new);
+ spin_unlock(&new->d_lock);
spin_unlock(&inode->i_lock);
security_d_instantiate(new, inode);
- d_move(new, dentry);
iput(inode);
} else {
/* already taking inode->i_lock, so d_add() by hand */
From: Al Viro
Date: Thu, 11 Sep 2014 18:55:50 -0400
Subject: move the call of __d_drop(anon) into __d_materialise_unique(dentry,
anon)
Origin: https://git.kernel.org/linus/6f18493e541c690169c3b1479d47d95f624161cf
Bug-Debian: https://bugs.debian.org/847549
and lock the right list there
Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro
[bwh: Backported to 3.16: adjust hunk order]
---
fs/dcache.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index d30ce699ae4b..5c6e71dc23f5 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1910,7 +1910,6 @@ struct dentry *d_splice_alias(struct inode *inode, struct dentry *dentry)
write_seqlock(&rename_lock);
__d_materialise_dentry(dentry, new);
write_sequnlock(&rename_lock);
- __d_drop(new);
_d_rehash(new);
spin_unlock(&new->d_lock);
spin_unlock(&inode->i_lock);
@@ -2723,6 +2722,12 @@ static void __d_materialise_dentry(struct dentry *dentry, struct dentry *anon)
dentry->d_parent = dentry;
list_del_init(&dentry->d_child);
anon->d_parent = dparent;
+ if (likely(!d_unhashed(anon))) {
+ hlist_bl_lock(&anon->d_sb->s_anon);
+ __hlist_bl_del(&anon->d_hash);
+ anon->d_hash.pprev = NULL;
+ hlist_bl_unlock(&anon->d_sb->s_anon);
+ }
list_move(&anon->d_child, &dparent->d_subdirs);
write_seqcount_end(&dentry->d_seq);
@@ -2776,7 +2781,6 @@ struct dentry *d_materialise_unique(struct dentry *dentry, struct inode *inode)
* could splice into our tree? */
__d_materialise_dentry(dentry, alias);
write_sequnlock(&rename_lock);
-__d_drop(alias);
goto found;
} else {
/* Nope, but we must(!) avoid directory
signature.asc
Description: This is a digitally signed message part
Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES: reproducing issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/12/16 22:15, Ximin Luo wrote:
> Ximin Luo:
>> Ximin Luo:
>>> [..]
>>>
>>> To demonstrate this in slightly more detail, I have attached two files:
>>>
>>> - sagetest.g - this is directly from Sage, for Bill's reference
>>>
>>> - sagetest.py - this is my attempt to come up with a "minimal test
>>> example".
>>
>> Here is a minimal example, purely only with GAP, no Sage involved.
>>
>> You still need sagetest.g from my previous email, but you don't need to
>> download my compressed workspace, the following commands will generate it:
>>
>> $ rm -f test.w
>>
>> [..]
>
> Sorry, I should have waited for a bit longer before writing the previous
> email. Here is an even smaller example, involving no material from Sage, not
> even sagetest.g:
>
> $ rm -f test.w
> $ { echo 'SaveWorkspace("./test.w");'; } | gap -q -b
> true
>
> $ { echo '?FieldByMatricesNC;'; } | gap -q -b -L ./test.w
> #W corrupted 'manual.six': ##W (in stream:
> InputTextFile(/usr/share/gap/doc/t\
> ut/manual.six))
> #W corrupted 'manual.six': ##W (in stream:
> InputTextFile(/usr/share/gap/doc/c\
> hanges/manual.six))
> #W corrupted 'manual.six': intro.tex 1. Introduction
> #W (in stream: InputTextFile(/usr/share/gap/pkg/Alnuth/doc/manual.six))
> Error, no method found! For debugging hints type ?Recovery from NoMethodFound
> Error, no 1st choice method found for `+' on 2 arguments called from
> pos - 1 at /usr/share/gap/lib/helpdef.gi:168 called from
> HELP_BOOK_HANDLER.(handler).ReadSix( stream
> ) at /usr/share/gap/lib/helpbase.gi:679 called from
> func( C[i] ) at /usr/share/gap/lib/coll.gi:746 called from
> List( books, HELP_BOOK_INFO
> ) at /usr/share/gap/lib/helpbase.gi:934 called from
> HELP_GET_MATCHES( books, topic, frombegin
> ) at /usr/share/gap/lib/helpbase.gi:968 called from
> ... at line 1 of *stdin*
> you can 'quit;' to quit to outer loop, or
> you can 'return;' to continue
> brk>
I can reproduce this with gap from the current Sid.
>
> So it seems saving a workspace, even an "empty" one, then loading it again,
> causes GAP to be unable to parse the old-style manuals.
If the manual.six files are uncompressed, then
{ echo '?FieldByMatricesNC;'; } | gap -q -b -L ./test.w
works as expected.
And if the zlib patch is applied, the above command line works as expected.
Thanks,
Jerome
>
> X
>
- --
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-
iQQcBAEBCgAGBQJYUdl7AAoJED+SGaZ/NsaL8ZQf+wShpPitnIJIZsHwRFqqxeAE
+C70IkbspmALBPdImCr0BR5Zlew3m8n47Uz64DHsFlUu+91AA8+aYt2fr02iigDM
jjLlO1rFE/3Q2yClNleKMLdQ7PcHwr75wD/PbrcGKEWNxm+w20d0K/+RNO4Auu+W
/DlI2TJNW9zvZ6CnxYDo/U0EggO1riBSJUqgWrAGrT0g/qL3hGYZw/gRUqtvdlNX
6Lpm9/cGptQ6Mq/cCjTRleEVTFZwebmKUk5FJtqTw9lz1Yu94pUW3N5LqeJrtT5Z
TDR3sYxxuFnHBpHeKSrDoeKjUJIsEYsceo/dT+KD4JoE6/nfMRCas78NWAjbOP3/
AmtQgYRHhw50CKv8M9uV+LjJtCH5k3kQeQGldRt+ZBdKyiM66vog3EjWnNmoYTOR
r6iDm58cSxxVncPHuNe09X6Ge60Wo10uRjSndzbDyo91tTFK0P0K3vSZfe5JRao0
Wsrc80nCscezLIlSk0GwGH31NZDlzIkSXTqtZvpSw5VjxmnEOPs9ccJdx232O+GM
eD9Jk3tAH0agWoyxqUmTfKDYulvJxBZylEpLieth2v0DAjpjuYll9Ksi+QPxYx6G
c+tsKpAdyWWn2B4jYh5wjSnt6gmXMLE3GIFK8AzG55zaUjiz3hbV9l3vB0lWe4mD
wuNlb2TgZOr9166p2ETJD21nLOLNb8kIi+mFQBKH6xa0HaXlOa+j1JBJnwyRYqMW
r6CGNb0fl3oDvHBOEPLHVBHS9OAsbU4qLLG14q3soHi5dHiu7SXXMpn1x+NBsdBs
FozzQ+8Q6gkBXjrNQHP3rBB1FvpTtC7BAsvpj2cMfMnz3V9Q0Heu41W4mjmRVKoq
ogJa9ul6JtOx+c6kfva5ZMj/UnmiSvRj8719lSepsK+9A5EbKAYeCGa9Vapsbmcb
tHkKKMcfK2ibFuhKd2cQG8taz+qAjwE6V7SbLUHa9gRSNCELBYBW0n6rPxwrgf4Z
5Wz2brSOjrM7Q+w83l9CCoRxqBYCcmHJxpQYvM48JJJC4F4g/TnD2FXccv36cUFH
fAyRHYZskqZ3I8/2iQP/3/CRaTcEaLUrpclvOFiHdaDLXbRFOCN6OYpyHD4sstzA
n97JIeW7bqhIRxmfdc3Yw71fLE//fDPxmsby8BU30IIQO+xhyfdMTJ7PeuJ1tYzG
9ubNQGIxU3EJYgkknDaRcqO2qc/S2ecTKRm9uNv0IamdmfYdvKEpAFPqajlUOwzg
bCShfxcn5ZUsunqbCWqW0UzeauVIoR3Pu6uerbJLRFLer5jmhU+0Ia9mQdqyQpGe
7R8N6oGCgaB645N6YOFIn7hvbUe4vXeyj5uwOihvc7GhcZ+1b5MaxU/t1faYhbs=
=G7So
-END PGP SIGNATURE-
Bug#848060: libx11-protocol-other-perl: FTBFS randomly (failing tests)
On Wed, Dec 14, 2016 at 11:34:31PM +0100, gregor herrmann wrote: > Could you maybe test with 29-1 which I just uploaded? > It has changes in the tests but I'm not sure if they address the > issues you discovered. Thanks a lot for acting on this bug so quickly. Yes, I'll try to trigger a bunch of rebuilds tomorrow. But bear in mind that the failure rate for this one is about 90% on the single-CPU virtual machines I use. I would really love to see this failure to happen in your machine as well. What follows might look as a rant but it's not: Perhaps I need to describe my building environment more accurately so that people (in general) can reproduce more easily the FTBFS-randomly bugs I report? I ask because the number of bugs of this kind I've reported is already too high: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org and I should really not be the only person to reproduce them. If a package really FTBFS randomly, everybody should be able to "reproduce the randomness" (so to speak). Some weeks ago I naively believed that all the FTBFS-randomly bugs were already reported, but I was very wrong, people keep uploading NEW packages for unstable which suffer from this problem every day... I wish we had a "D" day in the Release Managers calendar for stretch: [D] Last day to upload packages that only build half of the time :-) Anyway, I am lucky that you and Niko really care about this kind of bugs (not everybody does, just see the list above). You are my personal heroes in this battle against build randomness. Thanks.
Bug#848060: libx11-protocol-other-perl: FTBFS randomly (failing tests)
On Wed, Dec 14, 2016 at 11:34:31PM +0100, gregor herrmann wrote: > On Tue, 13 Dec 2016 17:53:55 +0100, Santiago Vila wrote: > > > Package: src:libx11-protocol-other-perl > > Version: 28-1 > > Severity: serious > > > > I tried to build this package in stretch with "dpkg-buildpackage -A" > > (which is what the "Arch: all" autobuilder would do to build it) > > but it failed: > > > Test Summary Report > > --- > > t/XSetRoot.t (Wstat: 65280 Tests: 0 Failed: 0) > > Non-zero exit status: 255 > > Parse errors: Bad plan. You planned 7 tests but ran 0. > > Files=47, Tests=, 12 wallclock secs ( 0.13 usr 0.02 sys + 1.08 cusr > > 0.08 csys = 1.31 CPU) > > Result: FAIL > > > Thanks for your bug report. > > Could you maybe test with 29-1 which I just uploaded? > It has changes in the tests but I'm not sure if they address the > issues you discovered. Thanks a lot for acting on this bug so quickly. Yes, I'll try to trigger a bunch of rebuilds tomorrow. But bear in mind that the failure rate for this one is about 90% on the single-CPU virtual machines I use. I would really love to see this failure to happen in your machine as well. What follows might look as a rant but it's not: Perhaps I need to describe my building environment more accurately so that people (in general) can reproduce more easily the FTBFS-randomly bugs I report? I ask because the number of bugs of this kind I've reported is already too high: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org and I should really not be the only person to reproduce them. If a package really FTBFS randomly, everybody should be able to "reproduce the randomness" (so to speak). Some weeks ago I naively believed that all the FTBFS-randomly bugs were already reported, but I was very wrong, people keep uploading NEW packages for unstable which suffer from this problem every day... I wish we had a "D" day in the Release Managers calendar for stretch: [D] Last day to upload packages that only build half of the time :-) Anyway, I am lucky that you and Niko really care about this kind of bugs (not everybody does, just see the list above). You are my personal heroes in this battle against build randomness. Thanks.
Bug#847018: zfs-dkms: fails to build against kernel version 4.8.0-2-amd64i
Package: zfs-dkms Version: 0.6.5.8-1 Followup-For: Bug #847018 Dear Maintainer, there is an upstream fix for this: 3b0ba3ba99b8a3af0fb532bf264629436b1abd84 https://github.com/zfsonlinux/zfs/commit/3b0ba3ba99b8a3af0fb532bf264629436b1abd84?diff=unified Regards -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages zfs-dkms depends on: ii debconf [debconf-2.0] 1.5.59 ii dkms 2.3-1 ii lsb-release9.20161125 ii spl-dkms 0.6.5.8-2 Versions of packages zfs-dkms recommends: ii zfs-zed 0.6.5.8-1 ii zfsutils-linux 0.6.5.8-1 zfs-dkms suggests no packages. -- debconf information: * zfs-dkms/note-incompatible-licenses: zfs-dkms/stop-build-for-32bit-kernel: true zfs-dkms/stop-build-for-unknown-kernel: true
Bug#829180: appears to be failing because of fsck
Am 07.12.2016 um 17:36 schrieb Daniel Pocock: > I've observed this problem again today > > Looking more closely, I noticed that it started to fsck the mount just > before it tried to mount it. It didn't appear to wait for fsck to finish: Fwiw, the log you provided doesn't seem to confirm that. mount for /dev/mapper/vg00-foo_host1_bak is only done after the fsck has completed (systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service: main process exited, code=exited, status=0/SUCCESS) > > 2016-12-03-summary.log > > > Dec 03 10:51:32 systemd[1]: Installed new job backup-host1-foo.mount/start as > 58 > Dec 03 10:51:32 systemd[1]: Installed new job > dev-mapper-vg00\x2dfoo_host1_bak.device/start as 59 > Dec 03 10:51:32 systemd[1]: Installed new job > systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service/start as 60 > Dec 03 10:51:32 systemd[1]: Expecting device > dev-mapper-vg00\x2dfoo_host1_bak.device... > Dec 03 10:51:36 systemd[1]: dev-vg00-foo_host1_bak.device changed dead -> > plugged > Dec 03 10:51:36 systemd[1]: dev-mapper-vg00\x2dfoo_host1_bak.device changed > dead -> plugged > Dec 03 10:51:36 systemd[1]: Job dev-mapper-vg00\x2dfoo_host1_bak.device/start > finished, result=done > Dec 03 10:51:36 systemd[1]: Found device /dev/mapper/vg00-foo_host1_bak. > Dec 03 10:51:36 systemd[1]: > dev-disk-by\x2did-dm\x2dname\x2dvg00\x2dfoo_host1_bak.device changed dead -> > plugged > Dec 03 10:51:36 systemd[1]: Starting File System Check on > /dev/mapper/vg00-foo_host1_bak... > Dec 03 10:51:36 systemd[1]: About to execute: /lib/systemd/systemd-fsck > /dev/mapper/vg00-foo_host1_bak > Dec 03 10:51:36 systemd[1]: > systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service changed dead -> start > Dec 03 10:51:36 systemd[935]: Executing: /lib/systemd/systemd-fsck > /dev/mapper/vg00-foo_host1_bak > Dec 03 10:51:37 systemd-fsck[935]: /dev/mapper/vg00-foo_host1_bak: clean, > 269/2293760 files, 8636385/9175040 blocks > Dec 03 10:51:37 systemd[1]: Child 935 belongs to > systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service > Dec 03 10:51:37 systemd[1]: > systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service: main process exited, > code=exited, status=0/SUCCESS > Dec 03 10:51:37 systemd[1]: > systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service changed start -> exited > Dec 03 10:51:37 systemd[1]: Job > systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service/start finished, > result=done > Dec 03 10:51:37 systemd[1]: Started File System Check on > /dev/mapper/vg00-foo_host1_bak. > Dec 03 10:51:37 systemd[1]: > systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service: cgroup is empty > Dec 03 10:51:37 systemd[1]: Mounting /backup/host1/foo... > Dec 03 10:51:38 systemd[1]: About to execute: /bin/mount -n > /dev/mapper/vg00-foo_host1_bak /backup/host1/foo -t ext4 > Dec 03 10:51:38 systemd[1]: backup-host1-foo.mount changed dead -> mounting > Dec 03 10:51:38 systemd[1068]: Executing: /bin/mount -n > /dev/mapper/vg00-foo_host1_bak /backup/host1/foo -t ext4 > Dec 03 10:51:38 mount[1068]: mount: /dev/mapper/vg00-foo_host1_bak is already > mounted or /backup/host1/foo busy -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#848188: python-coverage: jquery.hotkeys.js from upstream is not packaged
Package: python-coverage
Severity: normal
Dear Maintainer,
The python-coverage package recommends libjs-jquery-hotkeys and does not
install the jquery.hotkeys.js. However the file found in the coverage.py
sources is different from the file found in libjs-jquery-hotkeys:
--- /tmp/libjs-jquery-hotkeys-0~20130707+git2d51e3a9+dfsg/jquery.hotkeys.js
2016-12-14 23:42:26.0 +0100
+++
/home/loic/software/coveragepy/issue-518/coverage.py/coverage/htmlfiles/jquery.hotkeys.js
2016-12-14 20:13:35.576077233 +0100
@@ -22,8 +22,7 @@
96: "0", 97: "1", 98: "2", 99: "3", 100: "4", 101: "5",
102: "6", 103: "7",
104: "8", 105: "9", 106: "*", 107: "+", 109: "-", 110:
".", 111 : "/",
112: "f1", 113: "f2", 114: "f3", 115: "f4", 116: "f5",
117: "f6", 118: "f7", 119: "f8",
- 120: "f9", 121: "f10", 122: "f11", 123: "f12", 144:
"numlock", 145: "scroll", 188: ",", 190: ".",
- 191: "/", 224: "meta"
+ 120: "f9", 121: "f10", 122: "f11", 123: "f12", 144:
"numlock", 145: "scroll", 191: "/", 224: "meta"
},
shiftNums: {
@@ -45,7 +44,7 @@
handleObj.handler = function( event ) {
// Don't fire in text-accepting inputs that we didn't
directly bind to
if ( this !== event.target && (/textarea|select/i.test(
event.target.nodeName ) ||
-event.target.type === "text" ||
$(event.target).prop('contenteditable') == 'true' )) {
+event.target.type === "text") ) {
return;
}
In order to avoid unintended behavior or regressions, the jquery.hotkeys.js
file provided in the coverage.py sources must be installed.
Although it is desirable to avoid file duplication, this can only be done if
the files are indeed identical or if they are provided by an upstream that
maintains an API of some kind. Although I've not checked, I suspect that other
python-coverage javascript dependencies suffer from the same problem. The bug
reported against coverage.py[1] regarding key bindings could originate from
untested javascript libraries substitution.
Cheers
[1]
https://bitbucket.org/ned/coveragepy/issues/474/javascript-in-html-captures-all-keys
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.0-47-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
--
Loïc Dachary, Artisan Logiciel Libre
Bug#829180: appears to be failing because of fsck
Am 07.12.2016 um 17:36 schrieb Daniel Pocock: > Control: tags -1 - moreinfo > > I've observed this problem again today > > Looking more closely, I noticed that it started to fsck the mount just > before it tried to mount it. It didn't appear to wait for fsck to finish: > > > > > Dec 03 10:51:37 systemd[1]: Started File System Check on > /dev/mapper/vg00-foo_host1_bak. > Dec 03 10:51:37 systemd[1]: > systemd-fsck@dev-mapper-vg00\x2dfoo_host1_bak.service: cgroup is empty > Dec 03 10:51:37 systemd[1]: Mounting /backup/host1/foo... > Dec 03 10:51:38 systemd[1]: About to execute: /bin/mount -n > /dev/mapper/vg00-foo_host1_bak /backup/host1/foo -t ext4 > Dec 03 10:51:38 systemd[1]: backup-host1-foo.mount changed dead -> mounting > Dec 03 10:51:38 systemd[1068]: Executing: /bin/mount -n > /dev/mapper/vg00-foo_host1_bak /backup/host1/foo -t ext4 > Dec 03 10:51:38 mount[1068]: mount: /dev/mapper/vg00-foo_host1_bak is > already mounted or /backup/host1/foo busy Could you attach a systemd-analyze dump when you get such a failed boot. This way we should be able to see, if the fsck job is properly ordered or not. Is it always the same partition which fails? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#848183: last.fm : 'XML not UTF-8 encoded!'
On 2016-12-14 18:10:46, James Cowgill wrote: > Control: fixed -1 0.14.1-2 > > On 14/12/16 22:53, Antoine Beaupré wrote: >> Package: mpd-sima >> Version: 0.10.0-2 >> Severity: grave >> Tags: patch >> >> This bug also affects Debian: >> >> https://bugs.launchpad.net/ubuntu/+source/mpd-sima/+bug/1492589 >> >> Basically, things changed on last.fm's side and mpd-sima can't deal >> with that anymore in jessie. >> >> I confirm the patch provided in the above bug reports works too. > > So this bug only affects jessie, not stretch? I have unfortunately not been able to verify that yet, but it does seems so according to the ubuntu bug report. A. -- Five out of four people have a problem with fractions
Bug#848187: xserver-xorg-video-freedreno: FTBFS with xserver 1.19
Source: xserver-xorg-video-freedreno Version: 1.4.0-1 Severity: serious xserver-xorg-video-freedreno fails to build with the xserver 1.19. It should be updated, or removed from Debian if it's dead / unmaintained / no longer useful... Emilio -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES: reproducing issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Thanks for the patch. I am on my way to build the involved package
for the repository deb-sci-deb .
Jerome
On 14/12/16 19:46, Bill Allombert wrote:
> On Mon, Dec 12, 2016 at 10:19:18PM +0100, Bill Allombert wrote:
>> On Mon, Dec 12, 2016 at 06:06:37PM +0100, Bill Allombert wrote:
>>> On Sun, Dec 11, 2016 at 11:15:00PM +, Ximin Luo wrote:
Did you remove test.w before trying the tests? I think it is still
somehow autpgrp-related. Also the "corrupted" messages seem to be
separate from the actual failure of "no method found":
>>>
>>> I agree with you. But the "corrupted" messages are still a bug even
>>> if they do not affect Sage.
>>
>> I can reproduce this bug using a pristine gap installation without any
>> Debian stuff:
>>
>> rm -f workspace file file.gz
>> echo "abcdefgh" > file
>> gzip file
>> echo 'SaveWorkspace("workspace");' | bin/*/gap -q -b
>> echo 'ReadLine(InputTextFile("file"));' | bin/*/gap -q -b
>> echo 'ReadLine(InputTextFile("file"));' | bin/*/gap -q -b -L workspace
>>
>> I will report it upstream.
>
> Upstream send me the attached patch which fix this problem.
> Please confirm this address the original issue.
>
> Cheers,
>
- --
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-
iQQcBAEBCgAGBQJYUdOWAAoJED+SGaZ/NsaLW+If/2hGRflVsoklIWt4P56D6iiG
qC+K+6wsJg1rmRcOrFLMiBfcRhQV7k7dMvPIGzatKkByvxba11MTvViJ0Dillk/O
B5eoefylQxnhsvRMM9YM9WY0i4vk8lHHKEFNx3K+EwOa+Mj4+8L+W8KhwxKMb5xY
jksfio/4C04mb3IYy8uGceQgA2m7TMl26YsAGXxR+JASZR6kYqqWe7kxlZfKZ45l
qdQlxjsCMS1ov43pyycIaZ4SHnzLPr1/jbOLT1qNYproTQDST7dH9YmgjSZ8Mwd3
MVvfqJC9Wfx/y3eIFceNSX2NloxScLrLN3/2AFfJAvVGVJo75nanvYxxtT6v0BsE
rGrvcv5TC90mlyg/dNHX0brq/01153vJG3ilaMoDQjH/rsod++sML5ao9tFuX0Xp
9NYcJ/z6P7rAbde5/h9WVAthhro+1rHCVHXwTJTdLf1EYg+vdfjDQijqOeditEEK
t8NsKhJGe8lTbabVXzqaSRJI8IJMVuWq5GLRIrk/RMKAJfGX92gGfAvnZEtf5nNG
DArWbsifP/7ZLcPWCMdsltgWxZu40afDDBVgOEzY50e8CAMWlR1ZY80MfM5IqiW4
X7jEuqjSHUjjLzrE/m3BHOqZ5VY0VE6ltF3xRzAVK5AO8227P8gdRyEYIRCTV8mk
qWRcrcUSjgkEmIFp2ah3MJ/9urTntwGy8wGQcFvAJjnFwI59TLX1VKTodoUyZkvX
DfHP+PjPCPKpISDtVD2I+puwRiXtsyjA+A1D880zYPny1+snuZuxF6ZK2NQxWmRn
Dy/M24nmQ1MEyRMb3FYrgndHooyPwKvIBZ2vCaVkJYk2eSJczBbDw1KRdBEK/5D6
3HFQAK0IqkH2m/RqcB8vZyyNesRbIfKNfOJAqdBYWKnOyAFN+3DFYfW0XS1yW3UQ
Oaf3SmP488t/KZPDWKujAx3zR3rYlGI1Gv1gKaAuoWSH8J7s1H9oerRnG+hx4Nmq
4zLtwC3U5wnoUZafTC4m+tknwo+r/PCGhlJwtdBYamN8egyA6K21ajs49deTn1Xq
U2sW6cCfSZh6axYPlwrDZSSTLV/tbJ+y5B+o09IJasS8eG0PkD0LMcbrWL3jSOW7
/pvirZVCojtzrILojW/00BYbYsQ/ugqTM47EqXaAuMtjeXt+h8ZKCER29UebZE+y
O6Q3/n3ZbR07VhBehncSoAn4pihEg0YprPaMcFOQU+zElKXrCt7GI/HKW/b4wXmI
RPFq6Y3iaZqkg9w5WD/OyUUFqWlCUBSxLaedjLrWziSWne62/80+6/8W9aGokxTX
z9216jJ5cNiozSTW5zpCPA5Ey8fPa22I8E1rNXTQv0FcsYNuPz1ZAY+gDS9GS7E=
=vL7c
-END PGP SIGNATURE-
Bug#848183: last.fm : 'XML not UTF-8 encoded!'
Control: fixed -1 0.14.1-2 On 14/12/16 22:53, Antoine Beaupré wrote: > Package: mpd-sima > Version: 0.10.0-2 > Severity: grave > Tags: patch > > This bug also affects Debian: > > https://bugs.launchpad.net/ubuntu/+source/mpd-sima/+bug/1492589 > > Basically, things changed on last.fm's side and mpd-sima can't deal > with that anymore in jessie. > > I confirm the patch provided in the above bug reports works too. So this bug only affects jessie, not stretch? Thanks, James signature.asc Description: OpenPGP digital signature
Bug#848185: gmic FTBFS: dh_install: Cannot find (any matches for) "etc/bash_completion.d/gmic" (tried in "." and "debian/tmp")
Source: gmic Version: 1.7.9+zart-1 Severity: serious https://buildd.debian.org/status/package.php?p=gmic ... make[1]: Entering directory '/«BUILDDIR»/gmic-1.7.9+zart' chmod 755 debian/libgmic*.install dh_install --fail-missing dh_install: Cannot find (any matches for) "etc/bash_completion.d/gmic" (tried in "." and "debian/tmp") dh_install: gmic missing files: etc/bash_completion.d/gmic dh_install: missing files, aborting debian/rules:51: recipe for target 'override_dh_install' failed make[1]: *** [override_dh_install] Error 2 make[1]: Leaving directory '/«BUILDDIR»/gmic-1.7.9+zart' debian/rules:25: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2
Bug#848186: piuparts: "FAIL: Package purging left files on system" for files under /srv might not be a bug
Source: piuparts Severity: normal Currently the testing migration of proftpd-dfsg is blocked by the following piuparts error (counted as "regression" since the package is not currently in testing): https://piuparts.debian.org/sid/fail/proftpd-basic_1.3.5b-1.log 0m32.6s ERROR: FAIL: Package purging left files on system: /srv/ftp/ not owned /srv/ftp/welcome.msg not owned 0m32.6s ERROR: FAIL: Installation and purging test. 0m32.9s DEBUG: Starting command: ['umount', '/srv/piuparts.debian.org/tmp/tmpVdZtzA/dev/shm'] /usr/share/doc/debian-policy/fhs/fhs-2.3.txt.gz says: /srv contains site-specific data which is served by this system. The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. Distributions must take care not to remove locally placed files in these directories without administrator permission. I'd tend to say that not removing the file on purge is correct, but the whole situation looks rather underspecified. Is there any rationale why not removing files under /srv would without a doubt be considered a bug? If not, please don't flag this as an error. Thanks
Bug#848178: gimagereader fails to start
Hi joe, true, it's the same problem again. But this time it's only revealed as you didn't update tesseract. The version you have install is neither part of testing nor unstable > ii libtesseract33.04.00-5 Current is: testing: 3.04.01-4.2 unstable: 3.04.01-5 Please check again after updating libtesseract3 and close the bug if it's fixed. Best, Philip signature.asc Description: OpenPGP digital signature
Bug#848183: last.fm : 'XML not UTF-8 encoded!'
Package: mpd-sima Version: 0.10.0-2 Severity: grave Tags: patch This bug also affects Debian: https://bugs.launchpad.net/ubuntu/+source/mpd-sima/+bug/1492589 Basically, things changed on last.fm's side and mpd-sima can't deal with that anymore in jessie. I confirm the patch provided in the above bug reports works too. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable'), (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#834800: Info received (libkavorka-perl: depends on libdata-alias-perl, broken with Perl 5.24)
Jonas Smedegaard writes: > Excerpts from Daniel Dehennin's message of December 14, 2016 2:41 pm: >> You can find the fix in the following pull request, the package build >> fine with all test passing. >> >> The Moops tests are fine too. > > Thanks a lot! I will hae a closer look and (most likely) apply to the > Debian package in a moment... I may have forgotten the Makefile.PL and META.*, it looks like it does not prevent the package to build but as I'm not an expert of this part I prefer to warn you. Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#848181: initramfs-tools-core: support mounting of more complex setups
Control: tag -1 wontfix This code is broken in several ways, and I don't want to add this sort of complexity anyway. Sorry. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Bug#847458: RFS: clues-emacs/0~2014.09.23.69d873c-1 ITP
On Wed, Dec 14, 2016 at 05:06:39AM +0300, Dmitry Bogatov wrote: > I received reply from upstream, so now version is oficially 1.0.0. One > more review, please. You need `dch -r`. Otherwise, cab58bc0530e73165bf01d66a37966d08ca26280 LGTM. > About d/watch -- seems I used old version of dh-make-elpa. Latest > version correctly creates d/watch with https:// links in both modes > (with and without --pkg-emacsen). Great! -- Sean Whitton signature.asc Description: PGP signature
Bug#847681: improving NFS stability in next Debian release
On Wed, 2016-12-14 at 20:27 +0100, Daniel Pocock wrote: > Brief update on this issue: nfs-utils 1.3.4 is now in Debian sid [...] But it's broken: https://bugs.debian.org/848145 This one looks stranger; may or may not be a regression: https://bugs.debian.org/848115 Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Bug#847681: packaging repository and sid diverging? Various fixes needed.
On Tue, 2016-12-13 at 20:55 +0100, Daniel Pocock wrote: [...] > Thanks for providing this feedback > > I've done the following: > - forked the upstream repository The existing packaging repos are also based on the upstream git repo. > - created a debian/sid branch > - copied debian/* from jessie into that branch and committed > - copied debian/* from sid into that branch and committed > - used "git format-patch" and "git am" to copy in changes from your repo > - merged upstream's 1.3.4 tag into debian/sid > - updated patches (many could be dropped) > - other small updates (home page, VCS fields) > - pushed my repo into a new location, collab-maint/nfs-utils This throws away all the packaging history, which I don't think is a good idea. > Please have a look at my repository structure and tell me if you feel it > is useful for this project. If not, my changes could be extracted > easily enough with git format-patch and applied into your repository > with git am and then we could start the collab-maint/nfs-utils > repository over again. > > Are you happy for this to live in collab-maint now? Maybe that will > encourage more collaborators. I've added a README.source inviting > contributions too. I'm happy for nfs-utils to move away from the kernel team, and that implies it should go in a different project on Alioth. I've never been very comfortable with collab-maint and I don't see the value in allowing everyone to push to a git repository (versus sending a pull request). However, as I'm not going to be maintaining it any more I don't claim a right to veto that. I think you should check whether Anibal and Steve want to continue being co-maintainers for nfs-utils and if so what their opinions are. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Bug#848052: monster-masher: Sounds are not working (Invalid argument)
Control: tags -1 confirmed Control: found -1 1.8.1-6 On 13.12.2016 17:30, Andrej Mernik wrote: > Package: monster-masher > Version: 1.8.1-7 > Severity: normal > > Dear Maintainer, > > the game sounds are not working. If the game is run via terminal, you get the > following output: > > (monster-masher:2241): Gnome-WARNING **: Failed to cache sample 'clinck.wav' > from '/usr/share/monster-masher/sounds/clinck.wav': Invalid argument > > (monster-masher:2241): Gnome-WARNING **: Failed to cache sample 'splat.wav' > from '/usr/share/monster-masher/sounds/splat.wav': Invalid argument > > > The sound files are installed at correct locations: > /usr/share/monster-masher/sounds$ ls -al > > -rw-r--r-- 1 root root 22710 okt 8 2015 clinck.wav > -rw-r--r-- 1 root root 3719 okt 8 2015 splat.wav > > Best Regards, > Andrej Mernik Hi, thanks for the report. I can confirm even on Jessie the sounds don't work. Looking at the source package in src/sound.cpp and [1] because of the error message, this is related somehow to Gnome's gnome_sound_sample_load function which should probably be replaced with gnome_sound_play(). But it might also be related to the use of the Enlightened Sound Daemon (ESD) which is rather old. Unfortunately I don't have an immediate solution for the problem but I'm quite sure this is the place to get started. Regards, Markus [1] https://github.com/GNOME/libgnome/blob/master/libgnome/gnome-sound.c#L124 signature.asc Description: OpenPGP digital signature
Bug#848060: libx11-protocol-other-perl: FTBFS randomly (failing tests)
On Tue, 13 Dec 2016 17:53:55 +0100, Santiago Vila wrote: > Package: src:libx11-protocol-other-perl > Version: 28-1 > Severity: serious > > I tried to build this package in stretch with "dpkg-buildpackage -A" > (which is what the "Arch: all" autobuilder would do to build it) > but it failed: > Test Summary Report > --- > t/XSetRoot.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 7 tests but ran 0. > Files=47, Tests=, 12 wallclock secs ( 0.13 usr 0.02 sys + 1.08 cusr > 0.08 csys = 1.31 CPU) > Result: FAIL Thanks for your bug report. Could you maybe test with 29-1 which I just uploaded? It has changes in the tests but I'm not sure if they address the issues you discovered. Thanks in advance, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Tom Waits: Sins Of My Father signature.asc Description: Digital Signature
Bug#846360: libcurl -dev multiarch compatibility
This is a duplicate of bug #731998.
Bug#700632: ftpquota --files-download=0 is incorrect
retitle -1 "quota for --bytes-upload, --files-upload etc. should support value zero." severity -1 wishlist stop On 15.02.13 Mathieu Malaterre (ma...@debian.org) wrote: Hi Mathieu, > As per documentation: > http://www.proftpd.org/docs/utils/ftpquota.html > > ... > --Fd Specifies the limit of the number of files that may be > --files-download downloaded. Defaults to -1 (unlimited). > ... > > $ sudo rm ftpquota.limittab > $ sudo ftpquota --create-table --type=limit > $ sudo ftpquota --add-record --type=limit --name=foobar --quota-type=user > --files-download=0 > $ sudo ftpquota --show-records --type=limit > --- > Name: foobar > Quota Type: User > Per Session: False > Limit Type: Hard > Uploaded bytes: unlimited > Downloaded bytes: unlimited > Transferred bytes: unlimited > Uploaded files: unlimited > Downloaded files: unlimited > Transferred files: unlimited > > It does not seems possible to state: no download of any file possible! > At least the command line output clearly states that this is the case: sid:/tmp# ftpquota --add-record --type=limit --name=foobar --quota-type=user --files-download=0 ftpquota: notice: download files value '0' means 'unlimited' sid:/tmp# ftpquota --add-record --type=limit --name=foobar1 --quota-type=user --files-upload=0 ftpquota: notice: upload files value '0' means 'unlimited' And yes, it is no not understandable why there are two methods to specify the value "unlimited" (0 and -1). I guess we have to forward to upstream. Anyway I assume this to be FAD and lower severity to wishlist. Hilmar -- sigfault signature.asc Description: Digital signature
Bug#848182: clinfo: CL_DEVICE_PRINTF_BUFFER_SIZE is size_t, not cl_ulong
Package: clinfo Version: 2.1.16.01.12-1 Severity: normal Hi, this is wrong in the other direction: the printf buffer lives on the host side, so the host's idea of buffer sizes is relevant. The size isn't verified in clinfo at all, leading to: printf() buffer size4503599627370496 (4096TiB) Simon -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.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 clinfo depends on: ii libc62.24-7 ii ocl-icd-libopencl1 [libopencl1] 2.2.9-2 clinfo recommends no packages. clinfo suggests no packages. -- no debconf information
Bug#576998: why not
I'd like to give this one a try, in the framework of the Debian Javascript Maintainers team. The new repo will be here (many thanks to Mike Gabriel for sharing his previous work): https://anonscm.debian.org/git/pkg-javascript/etherpad-lite.git My current count of missing node-* packages is 9: - require-kernel - socket.io - ueberdb - express-session - cheerio - tinycon - swagger-node-express - jsonminify - measured Paolo
Bug#848018: Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/log4j/Logger
On Tue, Dec 13, 2016 at 01:16:21PM +0100, Alexandre Rossi wrote: > > Fixed version awaiting sponsorship at mentors.d.n. > https://mentors.debian.net/package/davmail Uploaded > The respective dsc file can be found at: > https://mentors.debian.net/debian/pool/main/d/davmail/davmail_4.7.3.2438-2.dsc For What Is Worth after `tar xf ../davmail_4.7.3.2438-2.debian.tar.xz` I got something like $ git log -p HEAD~1..HEAD commit 5f271ab50c22c3f3b073cb62e4e8d891e96714d4 Author: Geert Stappers Date: Wed Dec 14 22:42:45 2016 +0100 Changelog for upload of 2016-12-14 diff --git a/debian/changelog b/debian/changelog index 0d91d6d..29a5197 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +davmail (4.7.3.2438-2) unstable; urgency=medium + + * add systemd service Documentation keys + * add missing log4j dependency (Closes: #848018) + * do not force swt dep in (which is in Suggests:) + + -- Alexandre Rossi Tue, 13 Dec 2016 13:05:24 +0100 + davmail (4.7.3.2438-1) unstable; urgency=medium [ Alexandre Rossi ] > (do not hesitate to contact me if you have suggestions that would > improve workflow between us) Seen. Will do. > Alex Groeten Geert Stappers -- Leven en laten leven signature.asc Description: Digital signature
Bug#740177: Prospective proftpd should replace inetd/xinetd with socket systemd
forwarded 740177 http://bugs.proftpd.org/show_bug.cgi?id=3661 stop On 26.02.14 Francesco Paolo Lovergine (fran...@debian.org) wrote: Hi, > This is just for a future possible enahancement. In the meantime the > inetd/xinetd use should be deprecated and avoided in order to not having > problems such as those pointed on RH bugzilla > (https://bugzilla.redhat.com/show_bug.cgi?id=708997) > > Unfortunately, the socket implementation has issues at upstream level: > http://bugs.proftpd.org/show_bug.cgi?id=3661 > It does not seem that it will be managed any time soon. > According to this bug report the requested feature seems to be in 1.3.6rc2. Marking that bug a forwarded for now. Hilmar -- sigfault signature.asc Description: Digital signature
Bug#848181: initramfs-tools-core: support mounting of more complex setups
Package: initramfs-tools-core
Version: 0.125
Severity: wishlist
Tags: patch
Hi,
I have the following antries in /etc/fstab:
/dev/mapper/tobias4-home /home ext3defaults0 2
/home/usr /usr none bind 0 0
Currently /usr is not mounted automatically. However, with the attached patches
the mountfs function is able mount everything read-only. Tested manually with
the “kernel parameter” break=bottom.
Currently this script mounts only /usr, but not /usr/lib (if necessary) but
this can be easily added.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, mingw64-amd64, mingw64-i386
Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages initramfs-tools-core depends on:
ii cpio 2.11+dfsg-6
ii klibc-utils 2.0.4-9
ii kmod 23-1
ii udev 232-7
Versions of packages initramfs-tools-core recommends:
ii busybox 1:1.22.0-19
Versions of packages initramfs-tools-core suggests:
ii bash-completion 1:2.1-4.3
-- Configuration Files:
/etc/initramfs-tools/initramfs.conf changed:
MODULES=most
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
DEVICE=
NFSROOT=auto
-- no debconf information
--- functions 2016-12-14 20:32:54.256138631 +0100
+++ functions.ts 2016-12-14 22:29:53.295389926 +0100
@@ -420,6 +420,55 @@
done
}
+# mount a directory in a subshell
+# this won't clobber the local variables
+# $1 mount point
+submountfs()
+{
+ echo submountfs "$*"
+ (
+ . ${rootmnt}/root/functions.ts
+ . ${rootmnt}/root/local.ts
+ mountfs "$1"
+ )
+}
+
+
+# find mountpoints for complicated setups.
+# this function tries to guess the mount point for directory
+# and recursively mounts the necessary super-dirs.
+# $1 mount point
+mountmount()
+{
+ echo mountmount "$*"
+ target="$1"
+ if [ -s "${target}" ]
+ then
+ newmount="$(readlink "${rootfs}${target}")"
+ else
+ newmount="${target}"
+ fi
+ for file in ${rootmnt}/etc/fstab; do
+ if [ -f "${file}" ]; then
+ while read fs dir garbage; do
+case "${fs}" in
+""|\#*)
+ continue;
+ ;;
+esac
+echo "checking ${newmount} in ${dir}"
+case "${newmount}" in
+${dir}/*)
+ mounting "${dir}"
+ submountfs "${dir}"
+ ;;
+esac
+ done < "${file}"
+ fi
+ done
+}
+
+
# Mount a file system. We parse the information from the fstab. This
# should be overridden by any boot script which can mount arbitrary
# filesystems such as /usr. This default implementation delegates to
@@ -429,9 +478,21 @@
{
type=local
read_fstab_entry "$1"
- if [ "${MNT_TYPE}" = "nfs" ] || [ "${MNT_TYPE}" = "nfs4" ]; then
+ echo "got fstab entry ${MNT_FSNAME} ${MNT_DIR} ${MNT_TYPE} ${MNT_OPTS}"
+ case "${MNT_TYPE}" in
+ nfs|nfs4)
+# if [ "${MNT_TYPE}" = "nfs" ] || [ "${MNT_TYPE}" = "nfs4" ]; then
type=nfs
- fi
+# fi
+ ;;
+ none)
+ mountmount "${MNT_FSNAME}"
+ MNT_FSNAME="${rootmnt}${MNT_FSNAME}"
+ mountmount "${MNT_DIR}"
+ ;;
+ "")
+ mountmount "$1"
+ esac
${type}_mount_fs "$1"
}
--- local 2016-12-14 20:32:41.156138419 +0100
+++ local.ts 2016-12-14 22:24:23.683384595 +0100
@@ -163,7 +163,12 @@
fi
# FIXME This has no error checking
- modprobe "${MNT_TYPE}"
+ if [ "${MNT_TYPE}" = "none" ]
+ then
+ MNT_FSNAME="${rootmnt}${MNT_FSNAME}"
+ else
+ modprobe "${MNT_TYPE}"
+ fi
if [ "$MNT_PASS" != 0 ]; then
checkfs "$MNT_FSNAME" "$MNT_DIR" "${MNT_TYPE}"
Bug#848164: cups-browsed: Please consider what HWResolution should be in an everywhere PPD
I saw that Mike has done the still missing fix now. I have tried it out and it works now. So it is fixed in the current GIT state of CUPS. To fix the package in experimental, you need to replace the file filter/raster.c by the current one from GIT. Till
