Bug#916509: apt-listbugs: French po translation update
Package: apt-listbugs Version: 0.1.26 Severity: wishlist Tags: patch l10n Please find attached the French PO templates update, proofread by the debian-l10n-french mailing list contributors. Francesco: apologies for stepping over the deadline by a little bit. Regards, JB # Translation of apt-listbugs to French. # Copyright (C) 2002-2016 Masato Taruishi et al. # This file is distributed under the same license as the apt-listbugs package. # Translators: # Frédéric Bothamy , 2004-2007 # Jean-Baka Domelevo Entfellner , 2008-2018 # msgid "" msgstr "" "Project-Id-Version: apt-listbugs 0.1.20\n" "Report-Msgid-Bugs-To: invernom...@paranoici.org\n" "POT-Creation-Date: 2018-11-24 23:01+0100\n" "PO-Revision-Date: 2018-12-01 11:30+0100\n" "Last-Translator: Jean-Baka Domelevo Entfellner \n" "Language-Team: French \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n" "X-Generator: Poedit 2.2\n" #. TRANSLATORS: "E: " is a label for error messages; you may translate it with a suitable abbreviation of the word "error" #: ../bin/apt-listbugs:421 ../bin/apt-listbugs:454 ../bin/apt-listbugs:459 ../bin/apt-listbugs:465 ../bin/apt-listbugs:479 ../bin/apt-listbugs:509 ../bin/apt-listbugs:540 ../bin/apt-listbugs:589 #: ../bin/apt-listbugs:602 ../lib/aptlistbugs/aptcleanup:52 ../lib/aptlistbugs/aptcleanup:55 ../lib/aptlistbugs/logic.rb:292 ../lib/aptlistbugs/logic.rb:302 ../lib/aptlistbugs/logic.rb:986 #: ../lib/aptlistbugs/logic.rb:998 ../lib/aptlistbugs/logic.rb:1011 ../lib/aptlistbugs/migratepins:52 ../lib/aptlistbugs/migratepins:55 msgid "E: " msgstr "Err : " #: ../bin/apt-listbugs:422 msgid "This may be caused by a package lacking support for the ruby interpreter in use. Try to fix the situation with the following commands:" msgstr "Cela peut être dû à un paquet ne prenant pas en charge l'interpréteur Ruby en vigueur. Vous pouvez essayer de corriger cela à l'aide des commandes suivantes :" #: ../bin/apt-listbugs:454 msgid "APT_HOOK_INFO_FD is undefined.\n" msgstr "APT_HOOK_INFO_FD n'est pas défini.\n" #: ../bin/apt-listbugs:459 msgid "APT_HOOK_INFO_FD is not correctly defined.\n" msgstr "APT_HOOK_INFO_FD n'est pas correctement défini.\n" #: ../bin/apt-listbugs:465 msgid "Cannot read from file descriptor %d" msgstr "Impossible de lire depuis le descripteur de fichier %d" #: ../bin/apt-listbugs:479 msgid "APT Pre-Install-Pkgs is not giving me expected 'VERSION 3' string.\n" msgstr "Pre-Install-Pkgs d'apt ne renvoie pas la chaîne « VERSION 3 » attendue.\n" #: ../bin/apt-listbugs:509 msgid "APT Pre-Install-Pkgs is giving me fewer fields than expected.\n" msgstr "Pre-Install-Pkgs d'apt renvoie moins de champs qu'attendu.\n" #: ../bin/apt-listbugs:540 msgid "APT Pre-Install-Pkgs is giving me an invalid direction of version change.\n" msgstr "Pre-Install-Pkgs d'apt renvoie une indication de changement de version à contresens.\n" #: ../bin/apt-listbugs:619 msgid "** Exiting with an error in order to stop the installation. **" msgstr "** Sortie sur erreur pour interrompre l'installation. **" #: ../lib/aptlistbugs/aptcleanup:52 ../lib/aptlistbugs/logic.rb:390 ../lib/aptlistbugs/migratepins:52 msgid "Cannot read from %s" msgstr "Impossible de lire depuis %s" #: ../lib/aptlistbugs/aptcleanup:123 msgid "Fixed packages : " msgstr "Paquets corrigés : " #: ../lib/aptlistbugs/logic.rb:49 msgid "Usage: " msgstr "Usage : " #: ../lib/aptlistbugs/logic.rb:50 msgid " [options] [arguments]" msgstr " [options] [paramètres]" #: ../lib/aptlistbugs/logic.rb:52 msgid "Options:\n" msgstr "Options :\n" #. TRANSLATORS: the colons (:) in the following strings are vertically aligned, please keep their alignment consistent #. TRANSLATORS: the \"all\" between quotes should not be translated #: ../lib/aptlistbugs/logic.rb:55 msgid "" " -s : Filter bugs by severities you want to see\n" "(or \"all\" for all)\n" "[%s].\n" msgstr "" " -s : Restreindre l'affichage aux bogues avec ces gravités\n" "(ou \"all\" pour les voir tous)\n" "[%s].\n" #: ../lib/aptlistbugs/logic.rb:56 msgid " -T : Filter bugs by tags you want to see.\n" msgstr " -T <étiquettes> : Restreindre l'affichage aux bogues avec ces étiquettes.\n" #: ../lib/aptlistbugs/logic.rb:57 msgid "" " -S : Filter bugs by pending-state categories you want to see\n" "[%s].\n" msgstr "" " -S <états> : Restreindre l'affichage aux bogues correspondant à ces\n" "états\n" "[%s].\n" #: ../lib/aptlistbugs/logic.rb:58 msgid " -B : Filter bugs by number, showing only the specified bugs.\n" msgstr "" " -B <#bogue> : Ne rendre compte que du ou des bogue(s) désigné(s) par\n" "son/leur numéro.\n" #: ../lib/aptlistbugs/logic.rb:59 msgid " -D : Show downgraded
Bug#916508: netplan: Should not be included in buster
Package: netplan Severity: critical Version: 1.10.1-5 I plan to orphan this package and do not want to take responsibility for the network security support of netplan for the next stable release. Because of this, I register a RC bug on the package to ensure it stay out of buster until someone take over the package. -- Happy hacking Petter Reinholdtsen
Bug#872178: Status of debconf translation handling in nodm, help needed?
Hello Mike, hello Ondřej, On Wed, Nov 14, 2018 at 02:33:27PM +0100, Helge Kreutzmann wrote: > your package nodm has several unhandled debconf > translations, some of then available for several months. I see that > several uplaods have been made, is there a reason for not including > those translations? Do you need help handling? > > I'm currently trying (also in preparation for the freeze) to resolve > those pending translation. In December I will consider if a l10n NMU > is appropriate (which I would rather avoid, a MU is much better and of > course better integrated in your workflow). As I haven't got a reply, I will prepare a l10n NMU next week considering #872178, #906170 and the lintian warning priority-extra-is-replaced-by-priority-optional I also will look at #852125, the fix looks rather straightforward to integrate. If you want to do a MU (preferred) let me know. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Bug#916506: /usr/bin/logger: /usr/bin/logger allows anyone to write to /var/log/syslog
Package: bsdutils Version: 1:2.29.2-1+deb9u1 Severity: normal File: /usr/bin/logger Dear Maintainer, I was surprised to find that I can write anything I want to /var/log/syslog using the /usr/bin/logger program as a non-root user. My user account has no permissions on /var/log/syslog, it can't even read it. -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bsdutils depends on: ii libc62.24-11+deb9u3 ii libsystemd0 232-25+deb9u6 Versions of packages bsdutils recommends: ii bsdmainutils 9.0.12+nmu1 bsdutils suggests no packages. -- no debconf information
Bug#916507: O: plan -- X/Motif day planner
Package: wnpp Severity: normal I no longer use plan and netplan (I migrated my calendar to radicale and evolution), and this have no interest in maintaining the package in Debian. I have registered a RC bug on netplan to keep this package out of the next stable release, because I do not want to take responsibility for any security support for the next stable release duration. -- Happy hacking Petter Reinholdtsen
Bug#916505: tensorflow: Please package the Python interface for tensorflow
Source: tensorflow Severity: wishlist Dear Maintainer, I would really like to see the Python interface for tensorflow in Debian. Many thanks in advance. Best regards Ruben -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect
Bug#916121: array-info FTBFS with glibc 2.28
Control: tags -1 + patch Thank you for the heads up. I had a look at the code, and this patch get the code building. diff --git a/include/array_info.h b/include/array_info.h index 70d6458..2566ee7 100644 --- a/include/array_info.h +++ b/include/array_info.h @@ -44,6 +44,7 @@ #define _ARRAY_INFO_H_ #include +#include #include #include #include I currently lack the hardware required to verify the new code work, but am quite sure I found the correct header to include. -- Happy hacking Petter Reinholdtsen
Bug#915759: gitaly: depends on gitlab-common which is in contrib
On Thu, 06 Dec 2018 17:17:46 +0100 Andreas Beckmann wrote: > > during a test with piuparts I noticed your package failed to install. > gitaly is in main, but depends on gitlab-common which is in contrib. > One of the two packages needs to move ... gitlab-common is moved to main in 11.5.3+dfsg-1 (its in NEW) signature.asc Description: OpenPGP digital signature
Bug#916476: axel: autopkgtest regression
Hi Eriberto, On 15-12-2018 01:25, Eriberto Mota wrote: > Command 5: people.debian.org:80: Network is unreachable. Seems a > temporary issue in Debian infrastructure. > Command 6: people.debian.org:443: Network is unreachable. Ibdem. The > time diference from last command was 2 seconds only. > > I was waitting for a new try from CI server to confirm that commands 5 > and 6 are working. What you think about it? I thought the same, but all three runs that I looked at had the same three commands failing. Now there are four already. https://ci.debian.net/data/autopkgtest/testing/amd64/a/axel/1500517/log.gz https://ci.debian.net/data/autopkgtest/testing/amd64/a/axel/1504293/log.gz https://ci.debian.net/data/autopkgtest/testing/amd64/a/axel/1510369/log.gz https://ci.debian.net/data/autopkgtest/unstable/amd64/a/axel/1499169/log.gz Paul signature.asc Description: OpenPGP digital signature
Bug#916476: axel: autopkgtest regression
Forgot one thing. On 15-12-2018 01:25, Eriberto Mota wrote: > Seems a temporary issue in Debian infrastructure. By the way, try to be robust against that. On netwerk errros, retry at least a couple of times with some time in between. And consider marking your test as skippable and exit with exit code 77 if after several retries the network errors persist. Paul signature.asc Description: OpenPGP digital signature
Bug#913864: kicad: Backtraces on opening cvpcb
Control: tags -1 moreinfo unreproducible Hello Julien, Am 16.11.18 um 05:18 schrieb Julien Goodwin: > On opening cvpcb there's many (408) backtraces, bypassing them does allow > cvpcb to work, but closing it crashes kicad. I tried to reproduce this issue on several machines in preparation for 5.0.2. But I'm unable to get catched by your reported issue on any of my machines. Even if I forced the install the packages python-wxgtk3.0 and libwxgtk3.0-gtk3-0v5! > This seems similar to several other reported crashes, but this machine > is straight testing. > > A full log from one of the backtraces is below, all are the same basic > erorr just for different classes. No other user seems to be affected by the root of this report until now. I've not seen something similar in the KiCad user forum too. Also the backtrace shows to me that somehow functions called that should have been disabled (CMake option KICAD_SCRIPTING_WXPYTHON=OFF) for all versions since 5.0.0-1. Are you really sure you are using a binary from the Debian archive? Can you purge your current installation? If yes, did this happen too if you are work with fresh and clean config files for KiCad? Means all entries in ~/.config related to KiCad are created by the first time start of KiCad. -- Regards Carsten Schoenert
Bug#892654: duplicate of 857912?
Gjtzvrv On Sat, Dec 15, 2018, 03:21 Vincent McIntyre Thanks for your report. > It looks very like a duplicate of 857912. > If you agree, could you close this bug or merge it? > > Kind regards > Vince > >
Bug#916504: pulseaudio FTBFS on Alpha; return of the volume-test failure
Source: pulseaudio Version: 12.2-2 Severity: important Justification: fails to build from source but built in the past. User: debian-al...@lists.debian.org Usertags: alpha Tags: patch Pulseaudio FTBFS on alpha due to the volume-test test failing due to a floating-point exception which in turn is due to an infinity in floating-point calculations when volume-test is compiled with finite math options. This is bug #798248 reappearing but in a subtlely different guise. There the non-finite math was protected against by checking that the arguments are finite before performing floating point calculations, but it now seems that gcc takes the specification of finite math, being "[a]llow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs" so pedantically true, that it is fair game to optimise away any calls to isfinite() because the argument must be finite: it was said so on the command line! Whatever, examination of the object code shows that the calls to isfinite() are eliminated thus the floating-point arithmetic is no longer protected. Fortunately we can work out whether the arguments to the offending arithmetic are finite by other means and I attach a patch doing just that. With this patch pulseaudio builds to completion on Alpha. Cheers, Michael. Index: pulseaudio-12.2/src/tests/volume-test.c === --- pulseaudio-12.2.orig/src/tests/volume-test.c 2018-12-15 14:29:34.0 +1300 +++ pulseaudio-12.2/src/tests/volume-test.c 2018-12-15 16:24:38.303993387 +1300 @@ -114,7 +114,7 @@ double q, qq; p = pa_sw_volume_multiply(v, w); -if (isfinite(db) && isfinite(db2)) + if (v && w) qq = db + db2; else qq = -INFINITY;
Bug#916503: hwloc-contrib: autopkgtest is flaky
Source: hwloc-contrib Version: 1.11.12-1 User: debian...@lists.debian.org Usertags: flaky Hi Maintainer The hwloc-contrib autopkgtests often fail [1]. Examining one of the logs [2], I found the tests were being run against different versions of the packages from src:hwloc. Get:1 http://deb.debian.org/debian testing/contrib hwloc-contrib 1.11.11-1 (dsc) [2,361 B] Get:2 http://deb.debian.org/debian testing/contrib hwloc-contrib 1.11.11-1 (tar) [4,114 kB] Get:3 http://deb.debian.org/debian testing/contrib hwloc-contrib 1.11.11-1 (diff) [7,503 B] ... Get:3 http://deb.debian.org/debian unstable/main amd64 libhwloc5 amd64 1.11.12-1 [111 kB] Get:4 http://deb.debian.org/debian unstable/main amd64 hwloc-nox amd64 1.11.12-1 [159 kB] This results in the assembler, info, allowed and linux tests failing due to differing output similar to the following: --- /tmp/autopkgtest-lxc.g7wv0zcc/downtmp/build.QMW/src/utils/hwloc/test-hwloc-assembler.output 2015-06-02 09:12:40.0 + +++ /tmp/autopkgtest-lxc.g7wv0zcc/downtmp/autopkgtest_tmp/fooxsxO5e/test-hwloc-assembler.output 2018-12-14 23:05:52.556408825 + @@ -3,6 +3,7 @@ + In utils/hwloc.test-hwloc-assembler.sh.in there is a filter to remove hwlocVersion from the output, however it includes $HWLOC_VERSION and so is not removed when the versions differ, resulting in failure. If mixing versions of hwloc-contrib and hwloc is allowed, then I suggest adjusting the filters in the relevant tests, otherwise hwloc-contrib should have versioned dependencies on the packages from src:hwloc. Regards Graham [1] https://ci.debian.net/packages/h/hwloc-contrib/testing/amd64/ [2] https://ci.debian.net/data/autopkgtest/testing/amd64/h/hwloc-contrib/1508468/log.gz
Bug#916502: eboard: FTBFS with ld --as-needed
Package: eboard
Version: 1.1.3-0.2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch
Dear Maintainer,
eboard currently fails to build from source with ld --as-needed, which
is enabled by default in Ubuntu. This linker option requires that
libraries be placed after the files/objects that need them.
In Ubuntu, the attached patch was applied to achieve the following:
* d/p/ld-as-needed.patch: Add libraries to LIBS instead of LDFLAGS to fix
FTBFS with ld --as-needed.
Thanks for considering the patch.
Logan Rosen
-- System Information:
Debian Release: buster/sid
APT prefers cosmic-updates
APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500,
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru eboard-1.1.3/debian/patches/ld-as-needed.patch
eboard-1.1.3/debian/patches/ld-as-needed.patch
--- eboard-1.1.3/debian/patches/ld-as-needed.patch 1969-12-31
19:00:00.0 -0500
+++ eboard-1.1.3/debian/patches/ld-as-needed.patch 2018-12-15
00:16:45.0 -0500
@@ -0,0 +1,47 @@
+--- a/configure
b/configure
+@@ -9,8 +9,8 @@
+ my $cxx = "g++";
+ my @cxxflagsdbg = ("-ggdb");
+ my @cxxflags= map { split } join(" ",$ENV{CXXFLAGS}," ",$ENV{CPPFLAGS});
+-my @ldflags = map { split } join(" -lpthread "," -ldl ",$ENV{LDFLAGS});
+-my @libs= ();
++my @ldflags = map { split } join($ENV{LDFLAGS});
++my @libs= ("-lpthread -ldl");
+ my $configh = "config.h";
+ my $configmake = "config.make";
+ my $nls = 1;
+@@ -643,9 +643,8 @@
+ chomp($x);
+ @x = split(/ /,$x);
+ for(@x) {
+-push @ldflags, $_;
++push @libs, $_;
+ }
+-push @ldflags, @libs;
+
+ if (!header_check("gtk/gtk.h","gdk/gdkkeysyms.h"))
+ {
+@@ -701,6 +700,7 @@
+ print CONFIGMAKE "CXXFLAGS = @cxxflags\n";
+ print CONFIGMAKE "CXXFLAGS_DBG = @cxxflagsdbg\n";
+ print CONFIGMAKE "LDFLAGS = @ldflags\n";
++print CONFIGMAKE "LIBS = @libs\n";
+
+ print CONFIGMAKE "prefix= \${DESTDIR}$prefix\n";
+ print CONFIGMAKE "bindir= \${DESTDIR}$prefix/bin\n";
+--- a/elifekam
b/elifekam
+@@ -31,10 +31,10 @@
+ debug: eboard.dbg
+
+ eboard: $(OBJS)
+- $(CXX) $(LDFLAGS) -o eboard $(OBJS)
++ $(CXX) $(LDFLAGS) -o eboard $(OBJS) $(LIBS)
+
+ eboard.dbg: $(DBG_OBJS)
+- $(CXX) $(LDFLAGS) -o eboard.dbg $(DBG_OBJS)
++ $(CXX) $(LDFLAGS) -o eboard.dbg $(DBG_OBJS) $(LIBS)
+
+ dbg_%.o: %.cc $(HEADERS) $(XPMS)
+ $(CXX) $(CXXFLAGS_DBG) -c $< -o $@
diff -Nru eboard-1.1.3/debian/patches/series eboard-1.1.3/debian/patches/series
--- eboard-1.1.3/debian/patches/series 2018-11-06 07:05:34.0 -0500
+++ eboard-1.1.3/debian/patches/series 2018-12-15 00:16:09.0 -0500
@@ -1,3 +1,4 @@
french-translation.patch
hungarian-translation.patch
90_respect_deb_build_options.patch
+ld-as-needed.patch
Bug#916501: te923con: FTBFS with ld --as-needed
Package: te923con Version: 0.6.1-3 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco ubuntu-patch Dear Maintainer, te923con currently fails to build from source with ld --as-needed, which is enabled by default in Ubuntu. This linker option requires that libraries be placed in order after the files that need them. In Ubuntu, the attached patch was applied to achieve the following: * Merge from Debian unstable. Remaining changes: - debian/patches/ld-as-needed.patch: Put -lusb at end of linker flags to fix FTBFS with ld --as-needed. Thanks for considering the patch. Logan Rosen -- System Information: Debian Release: buster/sid APT prefers cosmic-updates APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru te923con-0.6.1/debian/patches/ld-as-needed.patch te923con-0.6.1/debian/patches/ld-as-needed.patch --- te923con-0.6.1/debian/patches/ld-as-needed.patch1969-12-31 19:00:00.0 -0500 +++ te923con-0.6.1/debian/patches/ld-as-needed.patch2017-08-03 02:17:14.0 -0400 @@ -0,0 +1,10 @@ +--- a/Makefile b/Makefile +@@ -6,6 +6,6 @@ + all: te923con + + te923con: te923con.c te923con.h te923usb.c te923usb.h te923com.c te923com.h +- gcc $(CPPFLAGS) $(CFLAGS) $(CXXFLAGS) $(LDFLAGS) -Wall -lusb -o te923con te923con.c te923usb.c te923com.c ++ gcc $(CPPFLAGS) $(CFLAGS) $(CXXFLAGS) $(LDFLAGS) -Wall -o te923con te923con.c te923usb.c te923com.c -lusb + + diff -Nru te923con-0.6.1/debian/patches/series te923con-0.6.1/debian/patches/series --- te923con-0.6.1/debian/patches/series2017-05-11 13:12:00.0 -0400 +++ te923con-0.6.1/debian/patches/series2018-12-13 17:55:06.0 -0500 @@ -1,2 +1,3 @@ spelling.patch hardening.patch +ld-as-needed.patch
Bug#891633: aolserver4: Should this package be removed?
On Wed, 05 Dec 2018 07:43 -0500 Scott Kitterman wrote: > On Tue, 4 Dec 2018 19:11:33 +0100 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= > wrote: > > severity nn normal > > reassign nn ftp.debian.org > > retitle nn RM: aolserver4 -- RoQA; unmaintained upstream, alternatives > exist, low popcon > > thanks > > > > > > So my question: Can we remove aolserver4 from the archive? > > > > > > debian/copyright points to http://aolserver.sf.net/ where the latest news > > > item is about it being copied to github in 2010. > > > https://github.com/aolserver/aolserver got its latest commit in 2009. > > > > > > This looks fairly dead to me, and unless its maintainer knows better, I > > > don't think there is going to be any upstream security support. > > > > > > It has also not been uploaded since an NMU that went into stretch, so > > > if it's removed from unstable, it will be trivial for prospective users > > > or maintainers to retrieve it from stretch. > > > > No objections were raised in almost a year, reassigning for removal now. > > There are rdepends that need to be addressed first: > > Checking reverse dependencies... > # Broken Depends: > aolserver4-nsldap: aolserver4-nsldap > aolserver4-nsmysql: aolserver4-nsmysql > aolserver4-nsopenssl: aolserver4-nsopenssl > aolserver4-nspostgres: aolserver4-nspostgres > aolserver4-nssha1: aolserver4-nssha1 > aolserver4-nssqlite3: aolserver4-nssqlite3 > dotlrn: dotlrn > openacs: openacs > xotcl: aolserver4-xotcl > > # Broken Build-Depends: > aolserver4-nsldap: aolserver4-dev (>= 4.5.1-5) > aolserver4-nsmysql: aolserver4-dev (>= 4.5.1-5) > aolserver4-nsopenssl: aolserver4-dev (>= 4.5.1-5) > aolserver4-nspostgres: aolserver4-dev (>= 4.5.1) > aolserver4-nssha1: aolserver4-dev (>= 4.5.1) > aolserver4-nssqlite3: aolserver4-dev (>= 4.5.1-5) > aolserver4-nsxml: aolserver4-dev (>= 4.5.1) > > Dependency problem found. > > Please either file rm bugs for them or remove the depenency. Once that's > done, please remove the moreinfo tag. It looks like it's all done except for xotcl. Scott K
Bug#916500: distcc: debian/watch should point to GitHub, not Google Code
Package: distcc Version: 3.1-6.3 Severity: normal Dear Maintainer, As Google Code is long gone, I've (hopefully) attached a patch to set debian/watch to the correct upstream. Thanks, Adam diff --git a/debian/control b/debian/control index 3a79b79..342eef3 100644 --- a/debian/control +++ b/debian/control @@ -4,7 +4,7 @@ Priority: optional Maintainer: Daniel Hartwig Build-Depends: debhelper (>= 9), libpopt-dev, linuxdoc-tools, autoconf, libgtk2.0-dev, libgnomeui-dev, po-debconf, python-dev, python-support (>= 0.90), autotools-dev Standards-Version: 3.9.3 -Homepage: http://code.google.com/p/distcc/ +Homepage: https://github.com/distcc/distcc Package: distcc Architecture: any diff --git a/debian/watch b/debian/watch index 4b348e8..82b466e 100644 --- a/debian/watch +++ b/debian/watch @@ -1,4 +1,3 @@ -version=3 -opts="uversionmangle=s/(\d)((rc|prerelease)\d*)$/$1~$2/" \ - http://code.google.com/p/distcc/downloads/list?can=1 \ - .*/distcc-(\d[\d.]*(?:(?:rc|prerelease)\d*)?)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) +version=4 +opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/distcc-$1\.tar\.gz/ \ + https://github.com/distcc/distcc/releases/ .*/v?([\d\.]+)\.tar\.gz
Bug#916499: autopkgtest: Something™ in autopkgtest 5.7 breaks something™ in at least libhtml-formfu-perl's autopkgtests
Package: autopkgtest Version: 5.7 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Sorry for this terrible bug report … I was in the process of updating libhtml-formfu-perl to the new upstream release. [0] And unfortunately the last of the three pkg-perl-autopkgtests (syntax.t) failed with: autopkgtest [03:29:08]: ERROR: "chmod -R go+rwX -- /tmp/autopkgtest.ES3bLl/autopkgtest-satdep.deb" failed with stderr "/bin/chmod: cannot access '/tmp/autopkgtest.ES3bLl/autopkgtest-satdep.deb': No such file or directory " A message I don't understand, and running autopkgtest with -ddd didn't help my understanding. Somewhat desparate, I downgraded autopkgtest to 5.6, and lo and behold, everything is working fine. (5.7 has worked before flawlessly for a few dozens of other packages.) So I have no idea what's going on here but some change between 5.6 and 5.7 breaks the tests for at least one package. I'm attaching the logs for the package for both the 5.6 and 5.7 autopkgtest runs. Hopefully someone can find out what's going on here … Cheers, gregor [0] https://salsa.debian.org/perl-team/modules/packages/libhtml-formfu-perl.git - -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 1.8.0~alpha2 ii libdpkg-perl1.19.2 ii procps 2:3.3.15-2 ii python3 3.7.1-2 ii python3-debian 0.1.33 Versions of packages autopkgtest recommends: ii autodep8 0.17 Versions of packages autopkgtest suggests: pn lxc pn lxd pn ovmf pn qemu-efi-aarch64 pn qemu-efi-arm ii qemu-system 1:3.1+dfsg-1 ii qemu-utils1:3.1+dfsg-1 ii schroot 1.6.10-6+b1 ii vmdb2 0.13.2-2 - -- no debconf information -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlwUbIpfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgaTIw//WlJloPgVh5SFAV2Ofnxd7dqY+TFrZcl43XfkkV2QvcyFjdJP8Fcjstbl vgS1oc05J0Bq60HmWmaiswlBGmRp2HXCi+Mknhshf0aUyM1n4lDd+JLzL5Xry5dF sf4GGZHS2iJj+ctRCqn/i9E0xggRTIsj5ePVExP6kLaXgr7paxZ4Za2k6jKG3PD8 eXp4A+IvOlSYsrLQSjd8BoDTPrwsjQKwhN6671Od1NF3l9R0frSpfiH2tnr1cf/H 1ZYLRZvihIfOEaMeHqKRaqFU/I0ZP+wPbiIWD20RsvaiLy0zAx1JfMGtsRwzN8gD BHInka2OmXGyKd7JmJkvPMJw5m7vVslTt5ezTNO2Zx9PHrqECzNuau/2mgnboXK9 PkcGMXZLXnKU2fBfSubI3dX3QATm2b0QrfxSEzPYzmjoVJZGDsYKWzAvVkpV6Gl9 u3vfCZZwhhHS6tpcRuHZfuUl0z3uY6tGAUG2PLLP5yF8kgNyAgKF4c0FeXTBRrB5 BajcFR7QphgKfjSp4QlrmunfY7IkRJjhBqrjGKWEpRHYBalt//dMHs2yqmruot8x +So9RUXy+sNQJLsh8A0YKlfZGvBzOvK6vnkxkQQ1f7hWVOspW6tc+ITLYv2YgQxX k36fACBuMonGXumFLSDLYo4Hclq3+/WvbBAdeSbaz3OYQidfwSA= =Ye7Y -END PGP SIGNATURE- libhtml-formfu-perl_autopkgtest.tar.gz Description: application/gzip
Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7
Am 15.12.18 um 02:05 schrieb Michael Biebl: > I'm having trouble with autopkgtest-virt-qemu as well. Unfortunately the > PR from Simon does not help here, I'm still getting timeouts like this: > > $ autopkgtest --debug fsarchiver*.dsc -- qemu > : failure: timed out waiting for "login prompt on ttyS0" Hm, this might be an unrelated issue caused by autopkgtest-build-qemu now using vmdb2 [1] I've re-run the test with and image which worked with python 3.7.1 and now fails: autopkgtest -o logs-vmdebootstrap-2 *.dsc *.deb -- qemu /apps/chroot/autopkgtest-sid.img autopkgtest [03:32:04]: version 5.7+nmu1 autopkgtest [03:32:04]: host pluto; command line: /usr/bin/autopkgtest -o logs-vmdebootstrap-2 systemd_239+upstream20181215-0.master.dsc libnss-myhostname_239+upstg qemu-system-x86_64: terminating on signal 15 from pid 32136 (/usr/bin/python3) Unexpected error: Traceback (most recent call last): File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 738, in mainloop command() File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 667, in command r = f(c, ce) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 258, in cmd_open caller.hook_open() File "/usr/bin/autopkgtest-virt-qemu", line 602, in hook_open setup_config(shareddir) File "/usr/bin/autopkgtest-virt-qemu", line 300, in setup_config VirtSubproc.expect(term, b'#', 30) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 239, in expect block = sock.recv(4096) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler raise Timeout() VirtSubproc.Timeout autopkgtest [03:32:53]: ERROR: testbed failure: cannot send to testbed: [Errno 32] Broken pipe This is with autopkgtest + the PR from Simon [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916493 -- 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#517018: no-root option in expert installer
Even with the Ubuntu patch dropped, if you don't set a password for root, you'll _rightly_ log in automatically if you boot with "single" or "emergency" at the kernel cmdline because they run "/sbin/sulogin --force".
Bug#916479: libtf2-dev has circular Depends on libtf2-geometry-msgs-dev
Hi Bill, On Fri, 14 Dec 2018 22:52:46 +0100 Bill Allombert wrote: > There is a circular dependency between libtf2-dev and > libtf2-geometry-msgs-dev: > > libtf2-dev:Depends: libtf2-geometry-msgs-dev > libtf2-geometry-msgs-dev :Depends: libtf2-dev > > Circular dependencies are known to cause problems > during upgrade between stable releases, so we should try to avoid them. > > See threads > http://lists.debian.org/debian-devel/2005/06/msg02111.html > http://lists.debian.org/debian-devel/2005/11/msg01101.html thank you for your bugreport and for working on these issues! Technically, we could indeed merge libtf2-geometry-msgs-dev into libtf2-dev. But I would still like to talk about some alternative solutions. Let me explain the situation. Upstream is the ROS project. They use a sort-of package-manager called catkin. As far as this package-manager is concerned, libtf2-dev and libtf2-geometry-msgs-dev are two distinct packages. This is also why we decided to make it two different binary packages: so that we mirror the granularity of the upstream catkin packages in Debian. If we would now merge libtf2-geometry-msgs-dev into libtf2-dev and let libtf2-dev provide libtf2-geometry-msgs-dev, then this would have the following disadvantage: For all our other ROS packages, users who need the foo_msgs catkin package would just install the libfoo_msgs-dev Debian package. This would no longer work in this specific case as libtf2-geometry-msgs-dev would only be a virtual package and would thus be a surprise to the user. We'd like to avoid such surprises. The only way to avoid this that I can currently imagine would be to provide an empty dummy package called libtf2-geometry-msgs-dev which would depend on libtf2-dev (but not the other way round). Do you see another way to solve this issue? Unfortunately, both packages are shipping header files that include the headers of the other and that's where the cycle is coming from. Thanks! cheers, josch signature.asc Description: signature
Bug#916497: package-contains-documentation-outside-usr-share-doc should ignore /usr/share/help
Source: lintian Version: 2.5.116 Please have the package-contains-documentation-outside-usr-share-doc check ignore /usr/share/help/ . https://lintian.debian.org/full/pkg-gnome-maintain...@lists.alioth.debian.org.html#deja-dup and some other GNOME packages are getting this tag emited for contribute pages. Many GNOME projects install user help to /usr/share/help/ (It was intended to be cross-desktop but KDE ended up not implementing it yet.) Since it is a widely used documentation directory, emitting this tag is wrong here. Thanks, Jeremy Bicha
Bug#916498: bumpversion: Maybe switch from unmaintained project to the maintained fork?
Package: bumpversion
Version: 0.5.3-3
Severity: wishlist
Dear Maintainer,
sadly the bumpversion project [1] seems to have stalled since 2015.
Its maintainer indicated that he should better mark it as unmaintained
[2], but failed to do so up to now.
Two attempts of asking the maintainer for transitioning the project to
an active maintainer failed ([3] and [4]).
The maintained fork published seven releases (as of 2018), including
support for signed git tags (certainly a good thing). The fork is a
drop-in replacement and keeps a compatibility link for the original
command ("bumpversion").
Maybe you want to consider packaging this fork in the future?
Thank you for your time!
Cheers,
Lars
[1] https://github.com/peritus/bumpversion
[2] https://github.com/peritus/bumpversion/issues/169#issuecomment-339023681
[3] https://github.com/peritus/bumpversion/issues/169
[4] https://github.com/peritus/bumpversion/issues/173
Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer
Package: game-data-packager Version: 61 Severity: normal Dear Maintainer, I bought X-Com: UFO Defense from GOG.com, and downloaded it with "lgogdownloader" (packaged by Debian), producing a file named setup_xcom_ufo_defense_2.0.0.4.exe, with MD5sum 2bf8035e375a2510807dcc27499d5f99. I ran "game-data-packager xcom-ufo /path/to/setup_xcom_ufo_defense_2.0.0.4.exe", the installer files were extracted, and it printed a whole lot of "identifying..." lines, then spat out some errors: [...] identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/SMALLSET.DAT identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/BIGLETS.DAT identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/GERMAN.DAT identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/ENGLISH.DAT identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/FRENCH.DAT [...] WARNING:game_data_packager.build:found possible "sound/roland.cat" but it is not one of the expected versions: file: /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/SOUND/ROLAND.CAT size: 143866 bytes md5:8421cdcbe91b1b3e4818d470f32ca859 sha1: 14a236be4e16b7040367dea87e25549d6ff290ba sha256: 6d98825b620eedb563f664161f86a391d60a0102c811400382ff1d9685913836 expected: SOUND/ROLAND.CAT: size: 93853 bytes md5:7194c1480e6ce2d3e188133ece4fdefb sha1: None sha256: None ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/BIGLETS.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/ENGLISH.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/FRENCH.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/GERMAN.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/SMALLSET.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided SOUND/ROLAND.CAT but did not ERROR:game_data_packager.build:Unable to complete any packages. I suspect that the GOG installer might already have the OpenXCOM data patch[1] installed, although I can't find any specific statements for or against it. [1]: https://openxcom.org/downloads-extras/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages game-data-packager depends on: ii dpkg1.19.2 ii fakeroot1.23-1 ii python3 3.6.7-1 ii python3-debian 0.1.33 ii python3-yaml3.13-1 Versions of packages game-data-packager recommends: ii game-data-packager-runtime 61 Versions of packages game-data-packager suggests: pn arj ii binutils 2.31.1-10 ii cabextract 1.9-1 pn cdparanoia pn dynamite ii gcc4:8.2.0-2 ii gdebi 0.9.5.7+nmu2 ii gir1.2-gdkpixbuf-2.0 2.38.0+dfsg-6 ii innoextract1.7-2+b1 pn lgc-pg ii lgogdownloader 3.4-1+b1 pn lhasa | jlha-utils | lzh-archiver ii make 4.2.1-1.2 ii p7zip-full 16.02+dfsg-6 ii python3-gi 3.30.2-1 ii steam 1.0.0.56-1 pn steamcmd pn unace-nonfree ii unar 1.10.1-2+b3 pn unrar pn unshield ii unzip 6.0-21 ii vorbis-tools 1.4.0-10.1 pn xdelta ii xdelta33.0.11-dfsg-1+b1 -- no debconf information
Bug#916495: python3-ws4py: New upstream release (0.5.1)
Package: python3-ws4py Version: python-ws4py Severity: wishlist Dear Maintainer, There is a new upstream release, would be nice if it was uploaded. https://pypi.org/project/ws4py/0.5.1/ -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-ws4py depends on: ii python3 3.7.1-2 python3-ws4py recommends no packages. Versions of packages python3-ws4py suggests: pn python-ws4py-doc pn python3-cherrypy3 | python3-tornado
Bug#916494: devscripts: [uscan] running uscan multiple times makes ../*.asc grow
Package: devscripts Version: 2.18.10 Severity: normal if i run uscan multiple times in a single source directory, each time the signature gets *appended* to the appropriate *.asc file, rather than replacing it. below is a transcript -- note that the *.asc grows each time uscan is run: 0 dkg@test:~/src/libgpg-error/libgpg-error$ rm ../*1.33*.asc rm: remove regular file '../libgpg-error_1.33.orig.tar.bz2.asc'? y 0 dkg@test:~/src/libgpg-error/libgpg-error$ uscan uscan: Newest version of libgpg-error on remote site is 1.33, local version is 1.32 uscan:=> Newer package available from https://gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.33.tar.bz2 gpgv: Signature made Fri 07 Dec 2018 11:17:18 AM EST gpgv:using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpgv: Good signature from "Werner Koch (dist sig)" Leaving ../libgpg-error_1.33.orig.tar.bz2 where it is. uupdate: ../libgpg-error-1.33 directory exists. uupdate: remove ../libgpg-error-1.33 directory. uupdate: -> Copy to libgpg-error_1.33-1.debian.tar.xz 0 dkg@test:~/src/libgpg-error/libgpg-error$ ls -la ../*1.33*.asc -rw-r--r-- 1 dkg dkg 534 Dec 14 20:50 ../libgpg-error_1.33.orig.tar.bz2.asc 0 dkg@test:~/src/libgpg-error/libgpg-error$ uscan uscan: Newest version of libgpg-error on remote site is 1.33, local version is 1.32 uscan:=> Newer package available from https://gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.33.tar.bz2 gpgv: Signature made Fri 07 Dec 2018 11:17:18 AM EST gpgv:using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpgv: Good signature from "Werner Koch (dist sig)" Leaving ../libgpg-error_1.33.orig.tar.bz2 where it is. uupdate: ../libgpg-error-1.33 directory exists. uupdate: remove ../libgpg-error-1.33 directory. uupdate: -> Copy to libgpg-error_1.33-1.debian.tar.xz 0 dkg@test:~/src/libgpg-error/libgpg-error$ ls -la ../*1.33*.asc -rw-r--r-- 1 dkg dkg 1068 Dec 14 20:50 ../libgpg-error_1.33.orig.tar.bz2.asc 0 dkg@test:~/src/libgpg-error/libgpg-error$ uscan uscan: Newest version of libgpg-error on remote site is 1.33, local version is 1.32 uscan:=> Newer package available from https://gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.33.tar.bz2 gpgv: Signature made Fri 07 Dec 2018 11:17:18 AM EST gpgv:using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpgv: Good signature from "Werner Koch (dist sig)" Leaving ../libgpg-error_1.33.orig.tar.bz2 where it is. uupdate: ../libgpg-error-1.33 directory exists. uupdate: remove ../libgpg-error-1.33 directory. uupdate: -> Copy to libgpg-error_1.33-1.debian.tar.xz 0 dkg@test:~/src/libgpg-error/libgpg-error$ ls -la ../*1.33*.asc -rw-r--r-- 1 dkg dkg 1602 Dec 14 20:50 ../libgpg-error_1.33.orig.tar.bz2.asc 0 dkg@test:~/src/libgpg-error/libgpg-error$ The result of the *.asc changing size/content is that a subsequent upload will be rejected by ftp-master because the *.asc referenced doesn't match the size/content of the previously uploaded *.asc. --dkg -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- DEBSIGN_KEYID=0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages devscripts depends on: ii dpkg-dev 1.19.2 ii fakeroot 1.23-1 ii file 1:5.34-2 ii gnupg 2.2.12-1 ii gnupg22.2.12-1 ii gpgv 2.2.12-1 ii gpgv2 2.2.12-1 ii libc6 2.27-8 ii libfile-homedir-perl 1.004-1 ii libfile-which-perl1.22-1 ii libipc-run-perl 20180523.0-1 ii libmoo-perl 2.003004-2 ii libwww-perl 6.36-1 ii patchutils0.3.4-2 ii perl 5.28.1-1 ii python3 3.6.7-1 ii sensible-utils0.0.12 ii wdiff 1.2.2-2+b1 Versions of packages devscripts recommends: ii apt 1.8.0~alpha2 ii at 3.1.23-1 ii curl7.62.0-1 ii dctrl-tools 2.24-3 ii debian-keyring 2018.11.25 ii dput-ng [dput] 1.21 ii dupload 2.9.2 ii equivs 2.2.0 ii libdistro-info-perl 0.20 ii libdpkg-perl1.19.2 ii libencode-locale-perl 1.05-1 pn libgit-wrapper-perl pn liblist-compare-perl ii liblwp-protocol-https-perl 6.07-2 pn libsoap-lite-perl ii libstring-shellquote-perl
Bug#895384: fixed in git?
This seems to have been addressed by Laurent recently (thanks!) https://salsa.debian.org/debian/nfs-utils/commit/cd79aec324fe58a240b29d53445de33147eb166b Laurent, perhaps the changelog line could have (Closes: #895384) appended? I'm not sure what the protocol is here. Kind regards Vince
Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout
Stefan Fritsch : > The rng should be initialized after the seed is loaded from disk. This is false according to systemd developers. Its state is changed, but it is still not initialized, because they think that the seed might come from a gold master image. -- Alexander E. Patrakov
Bug#916493: autopkgtest-build-qemu builds image which does not successfully boot
Package: autopkgtest
Version: 5.7
Severity: important
File: /usr/bin/autopkgtest-build-qemu
The latest version of autopkgtest-build-qemu using vmdb2 produces images
which do not work for here.
$ autopkgtest --debug fsarchiver*dsc -- qemu /apps/chroot/autopkgtest-sid-2.img
autopkgtest: DBG: autopkgtest options: Namespace(add_apt_releases=[],
add_apt_sources=[], apt_default_release=None, apt_pocket=[], auto_control=True,
build_parallel=None, built_binaries=True, copy=[], enable_apt_fallback=True,
env=[], gainroot=None, installed_click=None, logfile=None, output_dir=None,
override_control=None, packages=['fsarchiver_0.8.5-2.dsc'], pin_packages=[],
set_lang=None, setup_commands=[], setup_commands_boot=[], shell=False,
shell_fail=False, summary=None, testname=None, timeout_build=None,
timeout_copy=None, timeout_factor=1.0, timeout_install=None,
timeout_short=None, timeout_test=None, user=None, verbosity=2)
autopkgtest: DBG: virt-runner arguments: ['qemu',
'/apps/chroot/autopkgtest-sid-2.img']
autopkgtest: DBG: actions: [('source', 'fsarchiver_0.8.5-2.dsc', True)]
autopkgtest: DBG: build binaries: True
autopkgtest: DBG: testbed init
autopkgtest [02:18:02]: version 5.7
autopkgtest [02:18:02]: host pluto; command line: /usr/bin/autopkgtest --debug
fsarchiver_0.8.5-2.dsc -- qemu /apps/chroot/autopkgtest-sid-2.img
autopkgtest: DBG: got reply from testbed: ok
autopkgtest: DBG: testbed open, scratch=None
autopkgtest: DBG: sending command to testbed: open
qemu-system-x86_64: terminating on signal 15 from pid 30011 (/usr/bin/python3)
: failure: timed out waiting for "login prompt on ttyS0"
autopkgtest: DBG: TestbedFailure unexpected eof from the testbed
autopkgtest: DBG: testbed stop
autopkgtest: DBG: testbed close, scratch=None
autopkgtest: DBG: sending command to testbed: quit
autopkgtest: DBG: TestbedFailure cannot send to testbed: [Errno 32] Broken pipe
autopkgtest: DBG: testbed stop
autopkgtest [02:19:03]: ERROR: testbed failure: cannot send to testbed: [Errno
32] Broken pipe
autopkgtest: DBG: testbed stop
The image was created using
autopkgtest-build-qemu unstable /apps/chroot/autopkgtest-sid-2.img
An image built manually using vmdebootstrap works fine.
Regards,
Michael
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages autopkgtest depends on:
ii apt-utils 1.8.0~alpha2
ii libdpkg-perl1.19.2
ii procps 2:3.3.15-2
ii python3 3.7.1-2
ii python3-debian 0.1.33
Versions of packages autopkgtest recommends:
ii autodep8 0.17
Versions of packages autopkgtest suggests:
ii lxc 1:3.0.3-1
pn lxd
ii ovmf 0~20181115.85588389-2
pn qemu-efi-aarch64
pn qemu-efi-arm
ii qemu-system 1:3.1+dfsg-1
ii qemu-utils1:3.1+dfsg-1
pn schroot
ii vmdb2 0.13.2-2
-- no debconf information
Bug#892654: duplicate of 857912?
Thanks for your report. It looks very like a duplicate of 857912. If you agree, could you close this bug or merge it? Kind regards Vince
Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7
Am 15.12.18 um 02:05 schrieb Michael Biebl: > I'm having trouble with autopkgtest-virt-qemu as well. Unfortunately the > PR from Simon does not help here, I'm still getting timeouts like this: Downgrading python to 3.7.1-1 did fix this problem. Wonder if an RC bug against python 3.7.2~rc1-1 would make sense until this has been debugged and fixed. -- 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#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Control: close 643341 1.33-3 hi all-- libgpg-error 1.33 is now in unstable, and it ships a pkg-config file. Thanks to NIIBE for all his work on this! as of 1.33-3, i'vem also added an autopkgtest that uses the pkg-config file to ensure that a simple build works as expected. Could any of the folks who found older versions of gpg-error painful for cross-compiling take a crack at using this version for their cross-compilation? I'm closing this bug report because i think the pkg-config file solves the problem for cross-compilation to other debian architectures. If it doesn't solve the problem for you, then please reopen the bug and explain more. All the best, --dkg signature.asc Description: PGP signature
Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7
I'm having trouble with autopkgtest-virt-qemu as well. Unfortunately the
PR from Simon does not help here, I'm still getting timeouts like this:
$ autopkgtest --debug fsarchiver*.dsc -- qemu
/apps/chroot/autopkgtest-sid-2.img
autopkgtest: DBG: autopkgtest options: Namespace(add_apt_releases=[],
add_apt_sources=[], apt_default_release=None, apt_pocket=[],
auto_control=True, build_parallel=None, built_binaries=True, copy=[],
enable_apt_fallback=True, env=[], gainroot=None, installed_click=None,
logfile=None, output_dir=None, override_control=None,
packages=['fsarchiver_0.8.5-2.dsc'], pin_packages=[], set_lang=None,
setup_commands=[], setup_commands_boot=[], shell=False,
shell_fail=False, summary=None, testname=None, timeout_build=None,
timeout_copy=None, timeout_factor=1.0, timeout_install=None,
timeout_short=None, timeout_test=None, user=None, verbosity=2)
autopkgtest: DBG: virt-runner arguments: ['qemu',
'/apps/chroot/autopkgtest-sid-2.img']
autopkgtest: DBG: actions: [('source', 'fsarchiver_0.8.5-2.dsc', True)]
autopkgtest: DBG: build binaries: True
autopkgtest: DBG: testbed init
autopkgtest [02:04:35]: version 5.7+nmu1
autopkgtest [02:04:35]: host pluto; command line: /usr/bin/autopkgtest
--debug fsarchiver_0.8.5-2.dsc -- qemu /apps/chroot/autopkgtest-sid-2.img
autopkgtest: DBG: got reply from testbed: ok
autopkgtest: DBG: testbed open, scratch=None
autopkgtest: DBG: sending command to testbed: open
qemu-system-x86_64: terminating on signal 15 from pid 20325
(/usr/bin/python3)
: failure: timed out waiting for "login prompt on ttyS0"
autopkgtest: DBG: TestbedFailure unexpected eof from the testbed
autopkgtest: DBG: testbed stop
autopkgtest: DBG: testbed close, scratch=None
autopkgtest: DBG: sending command to testbed: quit
autopkgtest: DBG: TestbedFailure cannot send to testbed: [Errno 32]
Broken pipe
autopkgtest: DBG: testbed stop
autopkgtest [02:05:36]: ERROR: testbed failure: cannot send to testbed:
[Errno 32] Broken pipe
autopkgtest: DBG: testbed stop
--
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#916403: wordpress: Several security issues versions 3.8-5.0
On Fri, 14 Dec. 2018, 16:10 Salvatore Bonaccorso That would be appreciated if you can take care of it. > Request 614153 into MITRE. Still trying to work out what changeset fixes what bug, they don't exactly go into much details. I don't need it for the Sid release but for the others. - Craig
Bug#916492: ltris: Game doesn't really permit tucking pieces
Package: ltris Version: 1.0.19-3+b1 Severity: wishlist Tags: upstream Tetris and many of its clone permit the player to move a piece laterally to "tuck" it that way in a hole. It is sometimes possible in LTris, when you litterally spam the left or right button, but even doing that, it is not reliable. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ltris depends on: ii libc62.27-2 ii libsdl-mixer1.2 1.2.12-11+b3 ii libsdl1.2debian 1.2.15+dfsg1-4 ltris recommends no packages. ltris suggests no packages. -- no debconf information
Bug#916460: wpasupplicant 2.6 breaks WPA-Enterprise authentication
Il 2018-12-14 22:12 Andrej Shadura ha scritto: No, it doesn't. On Fri, 14 Dec 2018 at 18:51, Gabriel wrote: Package: wpasupplicant Version: 2:2.6-18 wpasupplicant 2.6 doesn't authenticate correctly with WPA Enteprise networks like eduroam. My distribution is Debian testing and my wireless card is an Intel Wireless 7260. I tried do downgrade both wpasupplicant and openssl and I discovered that using wpasupllicant 2.4 (available in the stable repository) the bug doesn't appear, openssl doesn't seem to be involved in the bug. But does the older libssl1.1 work with the new wpasupplicant? wpa_supplicant[1075]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/CN=eduradius-dr-2018' hash=86fdb85978a8d3c9ba28e40f1f10415d49c0a595b8752556906d37ac9d1884fc wpa_supplicant[1075]: wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
Bug#916476: axel: autopkgtest regression
Em sex, 14 de dez de 2018 às 18:57, Paul Gevers escreveu: > > Source: axel > Version: 2.16.1-3 > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainers, > > With a recent upload of axel the autopkgtest of axel fails in testing > when that autopkgtest is run with the binary packages of axel from > unstable. It passes when run with only packages from testing. In tabular > form: >passfail > axel from testing2.16.1-3 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is contributing to the delay of the migration > to testing [1]. Can you please investigate the situation and fix it? If > needed, please change the bug's severity. > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=axel > > https://ci.debian.net/data/autopkgtest/testing/amd64/a/axel/1504293/log.gz > > autopkgtest [09:28:06]: test command2: [--- > Initializing download: > http://people.debian.org/~eriberto/tests-axel/test.img > SSL error: certificate verify failed > > autopkgtest [09:28:08]: test command2: ---] > > > autopkgtest [09:28:39]: test command5: axel -6 -k -s 100 -o > $AUTOPKGTEST_TMP/test-new.img -U axel-test > http://people.debian.org/~eriberto/tests-axel/test.img > autopkgtest [09:28:39]: test command5: [--- > Initializing download: > http://people.debian.org/~eriberto/tests-axel/test.img > Unable to connect to server people.debian.org:80: Network is unreachable > > autopkgtest [09:28:39]: test command5: ---] > > autopkgtest [09:28:41]: test command6: axel -6 -k -s 100 -o > $AUTOPKGTEST_TMP/test-new.img -U axel-test > https://people.debian.org/~eriberto/tests-axel/test.img > autopkgtest [09:28:41]: test command6: [--- > Initializing download: > https://people.debian.org/~eriberto/tests-axel/test.img > Unable to connect to server people.debian.org:443: Network is unreachable > > autopkgtest [09:28:42]: test command6: ---] > Hi Paul, I saw the problem yesterday. I will try make an overview. Command 1: ok Command 2: SSL error: certificate verify failed. Seems there is a redirect from http to https here. So, we need 'axel -k' here. Command 3: ok Command 4: ok Command 5: people.debian.org:80: Network is unreachable. Seems a temporary issue in Debian infrastructure. Command 6: people.debian.org:443: Network is unreachable. Ibdem. The time diference from last command was 2 seconds only. I was waitting for a new try from CI server to confirm that commands 5 and 6 are working. What you think about it? Regards, Eriberto
Bug#916491: overgod FTCBFS: builds for the wrong architecture
Source: overgod Version: 1.0-5 Tags: patch User: helm...@debian.org Usertags: rebootstrap overgod fails to cross build from source, because it uses the build architecture compiler as a make default. Lettig dpkg's buildtools.mk supply the values fixes the cross build. Please consider applying the attached patch. Helmut diff --minimal -Nru overgod-1.0/debian/changelog overgod-1.0/debian/changelog --- overgod-1.0/debian/changelog2017-07-19 00:00:56.0 +0200 +++ overgod-1.0/debian/changelog2018-12-15 01:16:47.0 +0100 @@ -1,3 +1,10 @@ +overgod (1.0-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dpkg's buildtools.mk supply $(CC). (Closes: #-1) + + -- Helmut Grohne Sat, 15 Dec 2018 01:16:47 +0100 + overgod (1.0-5) unstable; urgency=medium * Team upload. diff --minimal -Nru overgod-1.0/debian/rules overgod-1.0/debian/rules --- overgod-1.0/debian/rules2017-07-19 00:00:56.0 +0200 +++ overgod-1.0/debian/rules2018-12-15 01:16:46.0 +0100 @@ -5,6 +5,8 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +-include /usr/share/dpkg/buildtools.mk + CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS) CFLAGS:=$(shell dpkg-buildflags --get CFLAGS) LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
Bug#916490: scanssh FTCBFS: builds for the wrong architecture
Source: scanssh
Version: 2.0-4.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
scanssh fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes scanssh cross buildable. Please consider
applying the attached patch.
Helmut
diff -u scanssh-2.0/debian/changelog scanssh-2.0/debian/changelog
--- scanssh-2.0/debian/changelog
+++ scanssh-2.0/debian/changelog
@@ -1,3 +1,10 @@
+scanssh (2.0-4.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne Sat, 15 Dec 2018 01:06:12 +0100
+
scanssh (2.0-4.1) unstable; urgency=medium
* Non-maintainer upload.
diff -u scanssh-2.0/debian/rules scanssh-2.0/debian/rules
--- scanssh-2.0/debian/rules
+++ scanssh-2.0/debian/rules
@@ -19,7 +19,7 @@
configure-stamp:
dh_testdir
# Add here commands to configure the package.
- ./configure --prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info
+ dh_auto_configure
touch configure-stamp
Bug#916489: aptitude: corrupted cache can cause segfault on start
Package: aptitude Version: 0.8.7-1 Severity: normal Tags: lfs Dear Maintainer, * What led up to the situation? disk failure caused corrupted files including /var/lib/aptitude/pkgstates * What exactly did you do (or not do) that was effective (or ineffective)? A complete reinstall of the relevant binary packages did nothing to stop segfaults on startup (including libc) but removal of the pkgstates package restored aptitude to a functional state. This is a very minor security issue. Sorry for the largefile flag (unrelated bug in reportbug-gtk). -- Package-specific info: Terminal: screen $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.7 Compiler: g++ 6.3.0 20170415 Compiled against: apt version 5.0.1 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20161126 cwidget version: 0.5.17 Apt version: 5.0.1 aptitude linkage: linux-gate.so.1 (0xb770d000) libapt-pkg.so.5.0 => /usr/lib/i386-linux-gnu/libapt-pkg.so.5.0 (0xb70e9000) libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb70b4000) libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb7091000) libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0 (0xb7089000) libcwidget.so.3 => /usr/lib/i386-linux-gnu/libcwidget.so.3 (0xb6f86000) libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xb6e6d000) libboost_iostreams.so.1.62.0 => /usr/lib/i386-linux-gnu/libboost_iostreams.so.1.62.0 (0xb6e55000) libboost_filesystem.so.1.62.0 => /usr/lib/i386-linux-gnu/libboost_filesystem.so.1.62.0 (0xb6e3a000) libboost_system.so.1.62.0 => /usr/lib/i386-linux-gnu/libboost_system.so.1.62.0 (0xb6e33000) libxapian.so.30 => /usr/lib/i386-linux-gnu/sse2/libxapian.so.30 (0xb6c09000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6bec000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb6a72000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6a1d000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb69ff000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6847000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6842000) libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb682a000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb680f000) libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xb67fd000) liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb67cf000) liblz4.so.1 => /usr/lib/i386-linux-gnu/liblz4.so.1 (0xb67bc000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb67b3000) libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb67ad000) /lib/ld-linux.so.2 (0xb770f000) -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-8-rt-686-pae (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages aptitude depends on: ii aptitude-common0.8.7-1 ii libapt-pkg5.0 1.4.8 ii libboost-filesystem1.62.0 1.62.0+dfsg-4 ii libboost-iostreams1.62.0 1.62.0+dfsg-4 ii libboost-system1.62.0 1.62.0+dfsg-4 ii libc6 2.24-11+deb9u1 ii libcwidget3v5 0.5.17-4+b1 ii libgcc11:6.3.0-18+deb9u1 ii libncursesw5 6.0+20161126-1+deb9u1 ii libsigc++-2.0-0v5 2.10.0-1 ii libsqlite3-0 3.16.2-5 ii libstdc++6 6.3.0-18+deb9u1 ii libtinfo5 6.0+20161126-1+deb9u1 ii libxapian301.4.3-2 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-12 ii sensible-utils 0.0.9+deb9u1 Versions of packages aptitude suggests: pn apt-xapian-index pn aptitude-doc-en | aptitude-doc pn debtags ii tasksel 3.39 -- no debconf information
Bug#915886: Additional Debug Data
I'm also hitting this bug so I've collected the data requested by Rich: b@mx17:~$ dpkg -l | egrep '^ii perl-' ii perl-base 5.24.1-3+deb9u5 amd64minimal Perl system ii perl-modules-5.24 5.24.1-3+deb9u5 all Core Perl modules ii perl-openssl-defaults:amd64 3 amd64version compatibility baseline for Perl OpenSSL packages b@mx17:~$ ls -l /usr/share/perl/5.24*/Getopt/Std.pm -rw-r--r-- 1 root root 8790 Nov 29 06:11 /usr/share/perl/5.24.1/Getopt/Std.pm -rw-r--r-- 1 root root 8790 Nov 29 06:11 /usr/share/perl/5.24/Getopt/Std.pm As you can see, my box has GetOpt and yet it has the same dkms error: checking global_page_state enums are sane... no NR_FILE_PAGES in either node_stat_item or zone_stat_item: NOT FOUND configure needs updating, see: config/kernel-global_page_state.m4 configure: error: in `/var/lib/dkms/zfs/0.7.12/build': configure: error: SHUT 'ER DOWN CLANCY, SHE'S PUMPIN' MUD! See `config.log' for more details -Ben McCann
Bug#916365: apt-listbugs: [INTL:nl] Dutch po file for the apt-listbugs package
Hi Francesco, Francesco Poli schreef op vr 14-12-2018 om 21:43 [+0100]: > On Thu, 13 Dec 2018 17:27:17 +0100 Frans Spiesschaert wrote: > > [...] > > Dear Maintainer, > > > > > > Please find attached the updated Dutch po file for the apt-listbugs > > package. > > Hello Frans, > thanks for the updated translation! > > I will soon push the new .po file to the public git repository; it > will > be included in the next upload. > > Your contribution is really appreciated! > > > Out of curiosity, why so many changes with respect to the previous > update (sent back on June 2018)? Fuzzy and untranslated strings were > much less abundant... > Have the Dutch l10n style guidelines changed in the meanwhile? > Or did you just change your mind about the best translation of a > number > of strings? It's indeed about Dutch l10n style guidelines. We try to be in line with the Dutch translation team at translationproject.org where most of GNU software translation is taken care of. As a guideline they use the infinitive for the translation of man pages and commands. I noticed that the old translation of apt-listbugs was using the imperative instead, so I switched to the infinitive. That explains why the translation got altered that much. > > > -- Regards, Frans Spiesschaert
Bug#900740: pcal failed to cross build at compile
On Mon, Jun 04, 2018 at 10:49:00AM +0700, vinh.nguyenc...@toshiba-tsdv.com wrote: > Attached file is the patch for this. The patch looks quite complex and subtly wrong to me: * It uses DEB_BUILD_GNU_TYPE without initializing it. * It uses OS without initializing it. * When a user sets CC, it gets overwritten. This is much easier solved with dh_auto_build, which doesn't use uninitialized variables and honours a CC environment variable. Helmut diff --minimal -Nru pcal-4.11.0/debian/changelog pcal-4.11.0/debian/changelog --- pcal-4.11.0/debian/changelog2012-05-09 22:32:10.0 +0200 +++ pcal-4.11.0/debian/changelog2018-12-15 00:39:01.0 +0100 @@ -1,3 +1,10 @@ +pcal (4.11.0-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Sat, 15 Dec 2018 00:39:01 +0100 + pcal (4.11.0-3) unstable; urgency=low * lintian fixes diff --minimal -Nru pcal-4.11.0/debian/rules pcal-4.11.0/debian/rules --- pcal-4.11.0/debian/rules2012-04-11 21:39:35.0 +0200 +++ pcal-4.11.0/debian/rules2018-12-15 00:38:55.0 +0100 @@ -15,7 +15,7 @@ build-stamp: dh_testdir - $(MAKE) CFLAGS="-O2 -Wall -DEPS" + dh_auto_build -- CFLAGS="-O2 -Wall -DEPS" touch build-stamp
Bug#898814: When I log in, it hangs until crng init done
On Fri, 14 Dec 2018 15:13:08 -0800 Xilin Sun wrote: > On Fri, 14 Dec 2018 11:04:40 +0100 Yves-Alexis Perez > wrote: > > I don't have good solutions right now. With 4.19 and if your CPU has an RNG > > you're willing to trust, you'll be able to pass random.trust_cpu=yes to the > > kernel command line, which should help seeding the RNG. > > Just took at look at the /boot/config-4.19.0-trunk-amd64 file from > Debian, and saw this: > > # CONFIG_RANDOM_TRUST_CPU is not set > > It seems that you have to compile your own kernel to enable > random.trust_cpu to try this option at this time. Just read the message on the patch by Ted Ts'o: https://lkml.org/lkml/2018/7/17/1279 It seems Debian will never ever enable this option by default. Unless you compile your own kernel, rng-tools5 or haveged is the solution to such bugs.
Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7
On Fri, 14 Dec 2018 at 20:19:00 +0100, Matthias Klose wrote: > On 14.12.18 12:48, Simon McVittie wrote: > > On Fri, 14 Dec 2018 at 11:31:02 +, Simon McVittie wrote: > >> tl;dr: autopkgtest-virt-qemu doesn't work with python3.7. > > > > This seems to be caused by using socket.send() (and assuming the entire > > buffer will be sent in one transaction) instead of socket.sendall(). > > This was always a bug, at least in theory. I don't know why Python 3.7 > > makes it significant in practice when it wasn't previously. > > if you already ran autopkg using 3.7, then that might point out to the recent > 3.7.2 release candidate 1. changes. At least the timing of the report > suggests this. Well spotted, you are correct. Looking at apt/history.log and the timing of my uploads, I must have run autopkgtest successfully with virt-qemu and python3.7 3.7.1-1 while I was preparing flatpak 1.1.1-1. The correlation with 3.7.2~rc1-1 seems very reliable, but I don't see anything in the Python 3.7 news that looks like a likely trigger. To be clear, I think this was always an autopkgtest-virt-qemu bug, and I don't know why autopkgtest-virt-qemu worked so reliably in the past, or why it still works with python3.6. smcv
Bug#916488: mbw FTCBFS: builds for the wrong architecture
Source: mbw Version: 1.2.2-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap mbw fails to cross build from source, because it does not pass cross tools to make. The easiest way of doing so - using dh_auto_build - makes mbw cross buildable. Please consider applying the attached patch. Helmut diff -u mbw-1.2.2/debian/rules mbw-1.2.2/debian/rules --- mbw-1.2.2/debian/rules +++ mbw-1.2.2/debian/rules @@ -24,7 +24,7 @@ dh_testdir # Add here commands to compile the package. - CFLAGS="$(CFLAGS)" $(MAKE) + CFLAGS="$(CFLAGS)" dh_auto_build #docbook-to-man debian/mbw.sgml > mbw.1 touch $@ diff -u mbw-1.2.2/debian/changelog mbw-1.2.2/debian/changelog --- mbw-1.2.2/debian/changelog +++ mbw-1.2.2/debian/changelog @@ -1,3 +1,10 @@ +mbw (1.2.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Sat, 15 Dec 2018 00:17:53 +0100 + mbw (1.2.2-1) unstable; urgency=low * New release correcting a bug.
Bug#898814: When I log in, it hangs until crng init done
On Fri, 14 Dec 2018 11:04:40 +0100 Yves-Alexis Perez wrote: > I don't have good solutions right now. With 4.19 and if your CPU has an RNG > you're willing to trust, you'll be able to pass random.trust_cpu=yes to the > kernel command line, which should help seeding the RNG. Just took at look at the /boot/config-4.19.0-trunk-amd64 file from Debian, and saw this: # CONFIG_RANDOM_TRUST_CPU is not set It seems that you have to compile your own kernel to enable random.trust_cpu to try this option at this time.
Bug#916487: cmake: Please add small workaround for m68k
Source: cmake Version: 3.13.2-1 Severity: normal User: debian-...@lists.debian.org Usertags: m68k Hello! We are currently having issues with cmake on m68k locking up, most likely related to a bug in libuv as the problem first showed up with cmake 3.11.0 which integrated more libuv code in cmake. After long debug sessions, I have come up with a temporary workaround which addresses the issue by using the embedded copy of libuv and dropping the Debian-specific build flags. This is considered a workaround and therefor esupposed to be used temporarily once we have hunted down the actual bug, most likely in libuv. Could you apply the attached patch for the next cmake upload so we can remove the "Not-for-us" flag for cmake on m68k? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2018-11-29 20:24:50.0 +0100 +++ debian/rules2018-12-14 23:47:04.932357164 +0100 @@ -2,6 +2,15 @@ include /usr/share/dpkg/pkg-info.mk +# Temporary workaround due to libuv issues on m68k +ifeq ($(DEB_HOST_ARCH), m68k) +export DEB_CFLAGS_MAINT_SET := +export DEB_CXXFLAGS_MAINT_SET := +SYSTEM_LIBS := --system-libs --no-system-libuv +else +SYSTEM_LIBS := --system-libs +endif + export DEB_CXXFLAGS_MAINT_APPEND := $(shell dpkg-buildflags --get CPPFLAGS) export DEB_CFLAGS_MAINT_APPEND := $(shell dpkg-buildflags --get CPPFLAGS) export DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed @@ -45,7 +54,7 @@ override_dh_auto_configure: $(BUILD_FLAGS_FILE) rm -rf Build && mkdir -p Build cd Build && ../bootstrap --prefix=/usr --docdir=/share/doc/cmake --mandir=/share/man \ ---init=../$(BUILD_FLAGS_FILE) --system-libs \ +--init=../$(BUILD_FLAGS_FILE) $(SYSTEM_LIBS) \ --sphinx-man --sphinx-html --sphinx-flags="-D today=\"$(BUILD_DATE)\"" \ $(BOOTSTRAP_PARALLEL) --verbose
Bug#916457: grub2-common: Grub refuses to re-enable IPv6 traffic
On Fri, Dec 14, 2018 at 05:23:35PM +, Alan Reding wrote: > To block IPv6 traffic, I do the following: > > 1. Add the following line to /etc/default/grub > > GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" > > 2. Run update-grub > > 3. In /etc/hosts, add # in front of all lines that mention IPv6 hosts > > 3. Reboot machine > > To re-enable IPv6 traffic, I do the following: [...] GRUB just passes the stuff in GRUB_CMDLINE_LINUX_DEFAULT straight through to the kernel; it has no other involvement in how the operating system's networking stack is set up. This could only possibly be a GRUB bug if you're finding that update-grub isn't correctly transferring GRUB_CMDLINE_LINUX_DEFAULT into /boot/grub/grub.cfg, or if the kernel parameters are somehow not actually being passed to the kernel (which you can check after boot by looking in /proc/cmdline). Otherwise, this cannot possibly be a GRUB bug, and I'd appreciate it if you could either close it or figure out some other suitable package to reassign it to, as appropriate. > Method A > > 4. Add # in front of the line that contains > GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" as in below: > > #GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" > > 5. Run update-grub > > 6. In /etc/hosts, remove # from all lines that mention IPv6 hosts > > 7. Reboot machine > > Result: IPv6 traffic is still blocked > > Method B > > 8. In /etc/default/grub, I delete the line > GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" > > 9. Run update-grub > > 10. In /etc/hosts, I ensure that # does not appear in front of lines that > mention IPv6 hosts > > 11. Reboot machine > > Result: IPv6 traffic is still blocked > > Method C > > 12. In /etc/default/grub, I change the value of ipv6.disable=0 as in: > > GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=0 quiet" > > 13. Run update-grub > > 14. In /etc/hosts, I ensure that # does not appear in front of lines that > mention IPv6 hosts > > 15. Reboot machine > > Result: IPv6 traffic is NOT blocked. IPv6 traffic is re-enabled These symptoms indicate to me that the equivalent of ipv6.disable=1 is being set somewhere else *as well*, which causes things to only work properly if you explicitly pass the kernel argument ipv6.disable=0. I'd suggest looking around in /etc/, perhaps /etc/modprobe.d/. -- Colin Watson [cjwat...@debian.org]
Bug#898814: When I log in, it hangs until crng init done
On Fri, 14 Dec 2018 11:04:40 +0100 Yves-Alexis Perez wrote: > On Fri, 2018-12-14 at 10:24 +0100, Yves-Alexis Perez wrote: > > Something puzzles me with all those issues: as far as I can tell, on most > > install, systemd-random-seed.service should save a seed at shutdown and > > restore it at startup, and this (I think) should be enough to properly init > > the RNG. > > > > Can you check if the service has been run in your case? > > Hi again, > > actually don't bother, I was pointed to [1] which has explanations. The random > seed load is done by just writing to /dev/urandom which doesn't credit > entropy [2]. Hi, That service appears to be running normal on the machine with this bug. As you said, it cannot be the cause. > I don't have good solutions right now. With 4.19 and if your CPU has an RNG > you're willing to trust, you'll be able to pass random.trust_cpu=yes to the > kernel command line, which should help seeding the RNG. The CPU on the machine with the bug does have an hardware RNG. I will test this option once I have linux-image-amd64 4.19 installed.
Bug#779416: dash: set -e breaks trap
On Tue, 16 Oct 2018 15:53:19 +0200 Antonio Ospite wrote: > Package: dash > Version: 0.5.10.2-1 > Followup-For: Bug #779416 > > Dear Maintainer, > [...] > I sent a tentative patch upstream which seems to fix the issue: > https://marc.info/?l=dash=153969445911884=2 > Upstream accepted the patch: https://marc.info/?l=dash=154476682007838=2 https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=06204f0c9f539fcb8cb532166656e80b81bd689a so this bug can be closed when a new upstream release becomes available. Ciao, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
Bug#913946: llvm*-dbgsym still missing
On 14/12/2018 21:21, Sylvestre Ledru wrote: Maybe it will be automatically fixed as doko told me that he backported the fix in binutils. The original form of this bug (i.e. "failed to find link section" when using GNU strip) should be fixed in binutils 2.31.1-11. To get back to that being our only problem, we need to revert at least the attempt to use LLVM strip (i.e. https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/d441237cacb871abfebec1353b4b64398a362b0b). Whether to also revert -fno-addrsig (which should no longer be needed with the new binutils) depends on how we value "still has -dbgsym with older binutils (e.g. if backported for mesa)" compared to "potential few% space saving when linked with ICF". (There's also #914021, where llvm*-dbgsym do exist but don't actually work; I don't know whether that will affect 7 after these changes)
Bug#885677: liblablgtksourceview2-ocaml: Depends on unmaintained gtksourceview2
Control: reopen -1 You can't drop liblablgtksourceview2-ocaml-dev as long as stuff still depends and build-depends on it. coq lablgtk-extra laby marionnet gtksourceview2 will be included in Debian 10 "Buster" but we will try to remove it early in the Bullseye series. [1] Therefore, I suggest bringing that package back, then you can lower the severity of this bug to Important. We'll have to figure something out for Bullseye. [1] https://lists.debian.org/debian-devel/2018/11/msg00570.html Thanks, Jeremy Bicha
Bug#916486: cl-ppcre has circular Depends on cl-unicode
The solution would be to separate the binary package for cl-ppcre in two or three: the base cl-ppcre (without unicode) and the cl-ppcre-unicode (with unicode) and perhaps a package cl-ppcre that "just" depends on the previous. —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org Communism doesn't work because people like to own stuff. ― Frank Zappa On Fri, Dec 14, 2018 at 5:15 PM Bill Allombert wrote: > > Package: cl-ppcre > Version: 20180805.git2115632-1 > Severity: important > > Hello Debian Common Lisp Team, > > There is a circular dependency between cl-ppcre and cl-unicode: > > cl-ppcre:Depends: cl-unicode > cl-unicode :Depends: cl-ppcre > > Circular dependencies are known to cause problems during upgrade between > stable releases, so we should try to avoid them. > > See threads > http://lists.debian.org/debian-devel/2005/06/msg02111.html > http://lists.debian.org/debian-devel/2005/11/msg01101.html > > Cheers, > -- > Bill. > > Imagine a large red swirl here. >
Bug#916297: reportbug: crash after using "Display modified configuration files"
Sandro, To reproduce the bug, one can modify /etc/reportbug.conf and run `reportbug --ui gtk2 reportbug`. Display the config file, press q. The exception is caught by the Gtk interface to display an error dialog. Therefore there is no better traceback. Nis
Bug#916486: cl-ppcre has circular Depends on cl-unicode
Package: cl-ppcre Version: 20180805.git2115632-1 Severity: important Hello Debian Common Lisp Team, There is a circular dependency between cl-ppcre and cl-unicode: cl-ppcre:Depends: cl-unicode cl-unicode :Depends: cl-ppcre Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here.
Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race
Am 14.12.2018 um 22:29 schrieb Rebecca N. Palmer: > On 14/12/2018 20:26, Michael Biebl wrote: >> https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/services/sddm.service.in/ >> > > That's not the one that gets installed - > https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/debian/sddm.service/ > is. That one looks indeed incorrect. While you are fixing debian/sddm.service, you might also drop # temporary safety check until all DMs are converted to correct # display-manager.service symlink handling ExecStartPre=/bin/sh -c '[ "$(basename $(cat /etc/X11/default-display-manager 2>/dev/null))" = "sddm" ]' That safe-check is not necessary anymore. -- 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#916485: ghdl has circular Depends on ghdl-gcc
Package: ghdl Version: 0.35+git20181129+dfsg-2 Severity: important Hello ghdl-llvm maintainers, There is a circular dependency between ghdl and ghdl-gcc: ghdl:Depends: ghdl-mcode | ghdl-gcc | ghdl-llvm ghdl-gcc:Depends: ghdl (= 0.35+git20181129+dfsg-2) Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here.
Bug#916484: python3-oslo.config has circular Depends on python3-oslo.log
Package: python3-oslo.config Version: 1:6.4.1-1 Severity: important Hello Debian OpenStack, There is a circular dependency between python3-oslo.config and python3-oslo.log: python3-oslo.config :Depends: python3-oslo.log (>= 3.36.0) python3-oslo.log:Depends: python3-oslo.config (>= 1:5.2.0) Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. Cheers, -- Bill. Imagine a large red swirl here.
Bug#916483: python3-networking-bagpipe has circular Depends on python3-networking-bgpvpn
Package: python3-networking-bagpipe Version: 9.0.0-1 Severity: important Hello Debian OpenStack Maintainers, There is a circular dependency between python3-networking-bagpipe and python3-networking-bgpvpn: python3-networking-bagpipe :Depends: python3-networking-bgpvpn python3-networking-bgpvpn :Depends: python3-networking-bagpipe Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. Cheers, -- Bill. Imagine a large red swirl here.
Bug#916482: python3-neutron-tempest-plugin has circular Depends on python3-tempest
Package: python3-neutron-tempest-plugin Version: 0.2.0-1 Severity: important Hello Debian OpenStack maintainers, There is a circular dependency between python3-neutron-tempest-plugin and python3-tempest: python3-neutron-tempest-plugin :Depends: python3-tempest (>= 17.1.0) python3-tempest :Depends: python3-neutron-tempest-plugin Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here.
Bug#916481: ceph-common has circular Depends on python-cephfs
Package: ceph-common Version: 12.2.8+dfsg1-5 Severity: important Hello Ceph maintainers, There is a circular dependency between ceph-common and python-cephfs: ceph-common :Depends: python-cephfs (= 12.2.8+dfsg1-5) python-cephfs :Depends: ceph-common Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here.
Bug#916236: golang-golang-x-net-dev: FTBFS on s390x - rawconn.go undefined: getsockopt
Am 14.12.2018 um 14:28 schrieb Martín Ferrari: > Tobias: I see you did the latest upload, but you did not follow the git > workflow I had started, and instead of following git commits, you merged > a snapshot.. I will need to rewrite git history now :( Hi Martín, I'm really sorry that I messed up your workflow and caused you extra work. That was certainly not my intention. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#916479: libtf2-dev has circular Depends on libtf2-geometry-msgs-dev
Package: libtf2-dev Version: 0.6.5-3 Severity: important Hello Debian Science Maintainers, There is a circular dependency between libtf2-dev and libtf2-geometry-msgs-dev: libtf2-dev :Depends: libtf2-geometry-msgs-dev libtf2-geometry-msgs-dev:Depends: libtf2-dev Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here.
Bug#916480: elpa-ghub has circular Depends on elpa-graphql
Package: elpa-ghub Version: 3.0.0-3 Severity: important Hello Debian Emacs addons team, There is a circular dependency between elpa-ghub and elpa-graphql: elpa-ghub :Depends: elpa-graphql (>= 0.1.1) elpa-graphql:Depends: elpa-ghub Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here.
Bug#916478: hamradio-maintguide: 'package template' link on page 5 is broken
Package: hamradio-maintguide Version: 0.4 Severity: normal Maintainer: Debian Hamradio Maintainers Clicking on subject link gives server not found error. Link on DebianHam web page is also broken. Garie Miller wb9awa -- Take back your privacy. Switch to www.StartMail.com
Bug#915103: Apache2 HTTP/2 connection problems with Safari clients
> Could you please shed light on where I can find commit > bee2facd9343beda10677b139cd9b2e49e986f01 for Debian Stretch? > I did not find apache2 sources on https://salsa.debian.org - Where is the > official Debian apache2 source git repo? > If it is not public, please attach the patch. > > We are struggling hard with this bug and will need to downgrade all of our > customers from HTTP/2 to HTTP/1.1 if we don't find a fix very soon. I am fine > compiling apache2 package by myself as long as this fix does not make it into > Stretch. > > Can you confirm that this bug was only introduced in Debian 9.6 point > release? That issue was not popping up before but since then, people started > complaining. OK, in the meantime I found official Debian apache2 git repo: https://salsa.debian.org/apache-team/apache2 But the patch from bee2facd9343beda10677b139cd9b2e49e986f01 (https://salsa.debian.org/apache-team/apache2/commit/bee2facd9343beda10677b139cd9b2e49e986f01) was already applied to latest apache2 package in Debian 9.6 (modules/http2/h2_bucket_beam.c). How come this should fix the problem? Or did you rather mean this patch is the source of these issues. Best, Philip
Bug#915103: Apache2 HTTP/2 connection problems with Safari clients
> i'm still wrong: > da1d372d0d58474f2f5a71b9acd301abf9b11bc0 is the commit on the master branch > > On the stretch branch, the commit > is bee2facd9343beda10677b139cd9b2e49e986f01 Hi Cyr Could you please shed light on where I can find commit bee2facd9343beda10677b139cd9b2e49e986f01 for Debian Stretch? I did not find apache2 sources on https://salsa.debian.org - Where is the official Debian apache2 source git repo? If it is not public, please attach the patch. We are struggling hard with this bug and will need to downgrade all of our customers from HTTP/2 to HTTP/1.1 if we don't find a fix very soon. I am fine compiling apache2 package by myself as long as this fix does not make it into Stretch. Can you confirm that this bug was only introduced in Debian 9.6 point release? That issue was not popping up before but since then, people started complaining. Thanks, Philip
Bug#916288: kea-dhcp4-server: Segfault after running for several minutes
Hello Bernhard, On 2018-12-14 12:38 p.m., Bernhard Übelacker wrote: Hello Anton, sorry, did completely miss the option that upstream could also provide dbgsym packages ... Just to be sure, the last backtrace was retrieved with upstream binaries of version 10.2.19+maria~stretch? And debug symbols are contained in libmariadb3-dbgsym? Well no. I've actually installed. apt install libmariadbclient18=10.1.26-0+deb9u1 libmariadbclient18-dbgsym I've tried libmariadb3 libmariadb3-dbgsym, but then the servers doesn't lease an IP at all. In the log I just see: 2018-12-14 21:29:28.325 INFO [kea-dhcp4.leases/2286] DHCP4_LEASE_ADVERT [hwtype=1 08:00:27:04:cc:0e], cid=[no info], tid=0xc3158b1a: lease 172.16.66.12 will be advertised 2018-12-14 21:29:28.327 ERROR [kea-dhcp4.alloc-engine/2286] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 08:00:27:04:cc:0e], cid=[no info], tid=0xc3158b1a: error during attempt to allocate an IPv4 address: unable to bind parameters for valid_lifetime, expire, subnet_id, fqdn_fwd, fqdn_rev, hostname, state) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)>, reason: (error code 0) Because your last backtrace shows mysql_stmt_bind_result from "./libmysql/libmysql.c:4134". But in [1] I just found a "./libmysqld/libmysql.c" (the directory is not equal). And in that line 4134 is the end of the expected function. But attaching a debugger to a live process and setting a breakpoint to mysql_stmt_bind_result shows ./libmariadb/libmariadb/mariadb_stmt.c:1210 in my test environment. And in that file is another implementation for mysql_stmt_bind_result ... Therefore you probably can supply another backtrace with the output of following additional commands? display/i $pc info share (gdb) display/i $pc 2: x/i $pc => 0x7479eccc : movzbl 0x451(%rax),%eax (gdb) info share From To Syms Read Shared Object Library 0x77dd9aa0 0x77df5070 Yes /lib64/ld-linux-x86-64.so.2 0x779c2330 0x77b0aad0 Yes /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6 0x7747fd00 0x774a3802 Yes /usr/lib/x86_64-linux-gnu/libkea-eval.so.4 0x77204d80 0x7722901c Yes /usr/lib/x86_64-linux-gnu/libkea-dhcp_ddns.so.1 0x76f9aa20 0x76fa8ab5 Yes /usr/lib/x86_64-linux-gnu/libkea-stats.so.1 0x76d49190 0x76d6316a Yes /usr/lib/x86_64-linux-gnu/libkea-cfgclient.so.2 0x76a184f0 0x76ab5b1b Yes /usr/lib/x86_64-linux-gnu/libkea-dhcp++.so.4 0x766b5fb0 0x766cd099 Yes /usr/lib/x86_64-linux-gnu/libkea-asiolink.so.3 0x76457c00 0x7646c56d Yes /usr/lib/x86_64-linux-gnu/libkea-cc.so.1 0x76229420 0x7622ce37 Yes /usr/lib/x86_64-linux-gnu/libkea-cryptolink.so.1 0x75ffb2d0 0x7600f8b6 Yes /usr/lib/x86_64-linux-gnu/libkea-hooks.so.2 0x75d95ce0 0x75daeca9 Yes /usr/lib/x86_64-linux-gnu/libkea-log.so.2 0x75b0ac90 0x75b3be06 Yes /usr/lib/x86_64-linux-gnu/libkea-util.so.2 0x758b2370 0x758b29f3 Yes /usr/lib/x86_64-linux-gnu/libkea-exceptions.so.0 0x756ae060 0x756aed06 Yes (*) /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 0x753b67e0 0x7545ed49 Yes (*) /usr/lib/x86_64-linux-gnu/libstdc++.so.6 0x75116a90 0x75126895 Yes (*) /lib/x86_64-linux-gnu/libgcc_s.so.1 0x74d94940 0x74ebe3d3 Yes /lib/x86_64-linux-gnu/libc.so.6 0x74799e00 0x7483ffec Yes /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 0x7454b8e0 0x74565ab4 Yes (*) /usr/lib/x86_64-linux-gnu/libpq.so.5 0x7432aab0 0x74337811 Yes /lib/x86_64-linux-gnu/libpthread.so.0 0x74017d70 0x740c3103 Yes /usr/lib/x86_64-linux-gnu/libkea-dns++.so.1 0x73d184c0 0x73d1b4f7 Yes /usr/lib/x86_64-linux-gnu/libkea-threads.so.1 0x73ac57f0 0x73af8e91 Yes (*) /usr/lib/x86_64-linux-gnu/liblog4cplus-1.1.so.9 0x73646000 0x737dca39 Yes (*) /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 0x733b8d80 0x733b994e Yes /lib/x86_64-linux-gnu/libdl.so.2 0x730b9680 0x731258da Yes /lib/x86_64-linux-gnu/libm.so.6 0x72eae0e0 0x72eb0ecf Yes /lib/x86_64-linux-gnu/librt.so.1 0x72c941c0 0x72ca4afe Yes (*) /lib/x86_64-linux-gnu/libz.so.1 0x72a21980 0x72a6b3e6 Yes (*) /usr/lib/x86_64-linux-gnu/libssl.so.1.1 0x727c4f80 0x727f46b9 Yes (*) /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 0x725763a0 0x725a5aa2 Yes (*) /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 0x722b3740 0x7230e1e5 Yes (*) /usr/lib/x86_64-linux-gnu/libkrb5.so.3 0x7205fa70 0x7207c790 Yes (*) /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 ---Type to continue, or q to quit--- 0x71e583c0 0x71e58f83 Yes (*)
Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race
On 14/12/2018 20:26, Michael Biebl wrote: https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/services/sddm.service.in/ That's not the one that gets installed - https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/debian/sddm.service/ is.
Bug#913946: llvm*-dbgsym still missing
Control: tags -1 help Le 14/12/2018 à 20:50, Rebecca N. Palmer a écrit : Control: reopen -1 Still no -dbgsym packages, and the build log contains dh_strip -p libomp5-7 --dbgsym-migration='libomp5-7-dbg (<< 1:7~svn327768-1~)' PATH=/<>/llvm-toolchain-7-7.0.1~+rc3/:$PATH LD_LIBRARY_PATH=/<>/llvm-toolchain-7-7.0.1~+rc3/debian/tmp//usr/lib/llvm-7/lib/ dh_strip -a -v -XlibFuzzer.a -Xlibc++.a -Xlibc++abi.a -Xlibc++experimental.a -XlibclangTidyModernizeModule.a ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. which again looks like breaking fakeroot by replacing (rather than adding to) LD_LIBRARY_PATH. (This time the package sizes are about normal, but at least libLLVM-7.so.1 has become executable again.) I suspect the cause is https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/d441237cacb871abfebec1353b4b64398a362b0b (and if the commit log is what you intended, the test is the wrong way round). If you still want to use llvm-strip I again suggest LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:[build dir] and calling dh_fixperms again after dh_strip, but I thought the point of -fno-addrsig was to be able to use GNU strip. I would appreciate the help of someone here as I spent enough time on that with important regressions (ex:https://bugs.llvm.org/show_bug.cgi?id=39951). Maybe it will be automatically fixed as doko told me that he backported the fix in binutils. S
Bug#916384: apt-listbugs: Updated Danish translation for version 1.26
On Thu, 13 Dec 2018 21:03:42 +0100 Morten Bo Johansen wrote: > Package: apt-listbugs > Version: 0.1.25 > Severity: wishlist > Tags: l10n patch > > Dear Maintainer, Hello Morten! > Please find attached an updated Danish translation. Thank you for sending it! I will soon push the new .po file to the public git repository; it will be included in the next upload. Your contribution is greatly appreciated! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpDPy9UHIntp.pgp Description: PGP signature
Bug#916460: wpasupplicant 2.6 breaks WPA-Enterprise authentication
On Fri, 14 Dec 2018 at 18:51, Gabriel wrote: > > Package: wpasupplicant > Version: 2:2.6-18 > > wpasupplicant 2.6 doesn't authenticate correctly with WPA Enteprise > networks like eduroam. > My distribution is Debian testing and my wireless card is an Intel > Wireless 7260. > I tried do downgrade both wpasupplicant and openssl and I discovered > that using wpasupllicant 2.4 (available in the stable repository) the > bug doesn't appear, openssl doesn't seem to be involved in the bug. But does the older libssl1.1 work with the new wpasupplicant? > wpa_supplicant[1075]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 > subject='/CN=eduradius-dr-2018' > hash=86fdb85978a8d3c9ba28e40f1f10415d49c0a595b8752556906d37ac9d1884fc > wpa_supplicant[1075]: wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication > failed -- Cheers, Andrej
Bug#916477: hovercraft: autopkgtest regression
Source: hovercraft
Version: 2.6-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Dear maintainers,
With a recent upload of hovercraft the autopkgtest of hovercraft fails
in testing when that autopkgtest is run with the binary packages of
hovercraft from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
hovercraft from testing2.6-1
all others from testingfrom testing
I copied some of the output at the bottom of this report. This seems to
indicate that you test against all the supported python3 versions, while
your package doesn't seem to support python3.6, which is a supported
version. I think you either need to make sure you build against all
supported python3 versions, or you shouldn't test against all supported
versions.
Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=hovercraft
https://ci.debian.net/data/autopkgtest/testing/amd64/h/hovercraft/1504150/log.gz
autopkgtest [04:24:08]: test hovercraft: [---
[*] testing python3.6:
= test session starts
==
platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.8.0 --
/usr/bin/python3.6
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.gcki_7qs/downtmp/build.ndV/src, inifile:
collecting ...
ERRORS
___ ERROR collecting tests/test_generator.py
___
tests/test_generator.py:4: in
from hovercraft.generate import rst2html
hovercraft/__init__.py:16: in
__version__ = pkg_resources.require("hovercraft")[0].version
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:898: in require
needed = self.resolve(parse_requirements(requirements))
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:784: in resolve
raise DistributionNotFound(req, requirers)
E pkg_resources.DistributionNotFound: The 'hovercraft' distribution
was not found and is required by the application
--- Captured stderr
/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't
resolve package from __spec__ or __package__, falling back on __name__
and __path__
return f(*args, **kwds)
=== 1 error in 0.34 seconds
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:6:
DeprecationWarning: the imp module is deprecated in favour of importlib;
see the module's documentation for alternative uses
import imp
autopkgtest [04:24:09]: test hovercraft: ---]
signature.asc
Description: OpenPGP digital signature
Bug#916476: axel: autopkgtest regression
Source: axel Version: 2.16.1-3 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of axel the autopkgtest of axel fails in testing when that autopkgtest is run with the binary packages of axel from unstable. It passes when run with only packages from testing. In tabular form: passfail axel from testing2.16.1-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is contributing to the delay of the migration to testing [1]. Can you please investigate the situation and fix it? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=axel https://ci.debian.net/data/autopkgtest/testing/amd64/a/axel/1504293/log.gz autopkgtest [09:28:06]: test command2: [--- Initializing download: http://people.debian.org/~eriberto/tests-axel/test.img SSL error: certificate verify failed autopkgtest [09:28:08]: test command2: ---] autopkgtest [09:28:39]: test command5: axel -6 -k -s 100 -o $AUTOPKGTEST_TMP/test-new.img -U axel-test http://people.debian.org/~eriberto/tests-axel/test.img autopkgtest [09:28:39]: test command5: [--- Initializing download: http://people.debian.org/~eriberto/tests-axel/test.img Unable to connect to server people.debian.org:80: Network is unreachable autopkgtest [09:28:39]: test command5: ---] autopkgtest [09:28:41]: test command6: axel -6 -k -s 100 -o $AUTOPKGTEST_TMP/test-new.img -U axel-test https://people.debian.org/~eriberto/tests-axel/test.img autopkgtest [09:28:41]: test command6: [--- Initializing download: https://people.debian.org/~eriberto/tests-axel/test.img Unable to connect to server people.debian.org:443: Network is unreachable autopkgtest [09:28:42]: test command6: ---] signature.asc Description: OpenPGP digital signature
Bug#755257: munin-node shouldn't suggest much at all
Hello, Am Fri, 14 Dec 2018 13:39:28 + schrieb Holger Levsen : > > gawk and procps are used by many plugins. I am not sure, whether it is worth > > the trouble to track the plugins (and their corresponding) packages using > > these > > common tools. > > I agree, those should be depends (or at least recommends). OK - I moved them to Recommends. > > Regarding libcrypt-ssleay-perl and libwww-perl: I do not see a reason for > > these > > suggestions. At least there is no direct "use" or "require" to be found in > > upstream's sources. Both suggestions are part of the packaging since it > > moved > > to git (around 2012). Should we keep them anyway? > > If we don't know (and can't figure out) why we have them, I guess it's ok to > drop them. Done. The resulting commits are available in my branch "debian-755257" in the repository g...@salsa.debian.org:debian/munin.git. Cheers, Lars
Bug#916475: ghdl: various suggestions to simplify the packaging
Source: ghdl Severity: wishlist Tags: patch Hello. The attachment contains various ideas to update or simplify the packaging. Last patch adapts #916412 to these changes (-e is not necessary anymore). Thanks for reviewing. ghdl-suggestions.tar.gz Description: application/gzip
Bug#916365: apt-listbugs: [INTL:nl] Dutch po file for the apt-listbugs package
On Thu, 13 Dec 2018 17:27:17 +0100 Frans Spiesschaert wrote: [...] > Dear Maintainer, > > > Please find attached the updated Dutch po file for the apt-listbugs > package. Hello Frans, thanks for the updated translation! I will soon push the new .po file to the public git repository; it will be included in the next upload. Your contribution is really appreciated! Out of curiosity, why so many changes with respect to the previous update (sent back on June 2018)? Fuzzy and untranslated strings were much less abundant... Have the Dutch l10n style guidelines changed in the meanwhile? Or did you just change your mind about the best translation of a number of strings? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpiVL_XsJqic.pgp Description: PGP signature
Bug#531722: dbconfig-common: allow to generate multiple files via dbc_generate_include
Hi On Fri, 2 Sep 2016 20:50:08 +0200 Paul Gevers wrote: > Control: tags -1 moreinfo > I assume you are aware that you can call dbc_generate_include yourself > after you called db_go, right? So you could easily generate the second > file you need (I mean, just a oneliner). Does this work for you? > > To be honest, I don't think I will implement native support for this > request any time soon, if at all, as I believe it is trivial to do > yourself. One thing I could easily do though, is make this more clear in > the documentation. Would you think that is appropriate to solve this bug? Please be aware that I may close this bug next time I look into it when the requested information isn't provided. Paul signature.asc Description: OpenPGP digital signature
Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race
On Fri, 14 Dec 2018 19:04:51 + "Rebecca N. Palmer" wrote: > Control: tags -1 patch > > That works (starts successfully with the desktop on tty1) - due to the > intermittent nature of the bug I can't be sure it's gone, but if we're > right about the cause it should be. > > Full sddm.service tested: > > [Unit] > Description=Simple Desktop Display Manager > Documentation=man:sddm(1) man:sddm.conf(5) > # Change this if you want to start sddm in a different tty > Conflicts=getty@tty7.service getty@tty1.service > After=getty@tty7.service getty@tty1.service > I'm a bit confused now. Looking at https://sources.debian.org/src/sddm/0.14.0-4+deb9u1/services/sddm.service.in/ it already has Conflicts=getty@tty1.service After=getty@tty1.service So what exactly does your patch change? If it is the addition of Conflicts=getty@tty7.service After=getty@tty7.service why would that be necessary? There is no getty by default on tty7, so this appears to be no-op change unless you explicitly configured your system to start a getty on tty7. 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#916474: emacs-gtk: does not render certain UTF-8 symbols that other applications (both GTK and Qt based) render without problems
Package: emacs-gtk Version: 1:25.2+1-11 Severity: normal Dear Maintainer, What led up to this situation is a correspondent sent me an e-mail containing a UTF-8 emoticon which rendered without problems under the konsole application for KDE, but when I edited my reply to him using emacs I noticed all my quotation of his emoticon was being rendered as a box with numbers inside indicating emacs understands the UTF-8 and transforms it into UCS4 (the numbers within the box) without issues, but somehow cannot access the correct system fonts to render those characters properly. I then checked in some detail with gucharmap (a GTK application) and I spot sampled from the emoticons block, e.g., "", and gucharmap renders those glyphs without issues, but they are all rendered in block form under emacs for the particular set of font packages I have loaded. And I found similar good rendering results for gucharmap and block-form rendering results for emacs for glyphs sampled from the "Miscellaneous Symbols and Pictographs" and "Playing Cards" unicode blocks. Anyhow, I don't understand why gucharmap (which depends on the suite of GTK libraries such as pango, cairo, and fontconfig) and emacs-gtk (which from its name presumably also depends on the suite of GTK libraries) are getting such different results for certain unicode blocks when they get the same (good) rendering results for many other unicode blocks. One possibility to explain this rendering difference between gucharmap and emacs-gtk is gucharmap is using fontconfig to find system fonts and emacs-gtk might be using some other method that does not match up to the quality of fontconfig. Or emacs-gtk may be using fontconfig with a specific list of font names to search rather than letting fontconfig do its job by specifying generic font names such as "sans", "serif", etc. In other words, it is possible I could work around this font-finding bug in emacs by installing particular system fonts that emacs-gtk happens to be able to find with its present font-finding algorithm. However, I would far prefer to see a fundamental solution such as emacs-gtk using generic font names and font-config to find unicode-aware system fonts since that method appears to give complete access to all such fonts and the present font-finding method emacs-gtk uses clearly does not do that for the set of Debian system fonts I have presently installed. I used the "dpkg --list |grep -i font" command to provide the following list of all currently installed packages that have anything to do with fonts: ii aglfn 1.7-3 all Adobe Glyph List For New Fonts ii console-setup 1.187 all console font and keymap setup program ii fontconfig2.13.1-2 amd64generic font configuration library - support binaries ii fontconfig-config 2.13.1-2 all generic font configuration library - configuration ii fonts-adf-oldania 0.20110505-3 all Oldania font of the Arkandis Digital Foundry ii fonts-dejavu 2.37-1 all metapackage to pull in fonts-dejavu-core and fonts-dejavu-extra ii fonts-dejavu-core 2.37-1 all Vera font family derivate with additional characters ii fonts-dejavu-extra2.37-1 all Vera font family derivate with additional characters (extra variants) ii fonts-droid-fallback 1:6.0.1r16-1.1 all handheld device font with extensive style and language support (fallback) ii fonts-font-awesome5.0.10+really4.7.0~dfsg-1 all iconic font designed for use with Twitter Bootstrap ii fonts-freefont-otf20120503-8 all Freefont Serif, Sans and Mono OpenType fonts ii fonts-freefont-ttf20120503-8 all Freefont Serif, Sans and Mono Truetype fonts ii fonts-gfs-baskerville 1.1-5 all ancient Greek font revival ii fonts-gfs-porson 1.1-6 all Greek font (Porson revival) ii fonts-hack3.003-1 all Typeface designed for source code ii fonts-lato2.0-2 all sans-serif typeface family font ii fonts-lmodern 2.004.5-5 all OpenType fonts based on Computer Modern ii fonts-noto20171026-2
Bug#916473: RM: xfce4-linelight-plugin -- ROM; unmaintained upstream
Package: ftp.debian.org Severity: normal Hi, another removal request for another Xfce panel plugin. Again it's not really maintained anymore upstream so I don't think we should carry it in Debian. We still have a suggests in xfce4-goodies but it'll be gone in the next upload (I'm doing all removal at once). Regards, -- Yves-Alexis
Bug#916472: bumblebee-nvidia: Bumblebee tries to load nouveau
Package: bumblebee-nvidia Version: 3.2.1-18 Severity: important Dear Maintainer, I tried to run glxgears using: primusrun glxgears. It fails with: primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) NOUVEAU(0): [drm] failed to set drm interface version. I'm using nvidia-legacy-390xx-driver and user is in grup bumblebee. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (700, 'testing'), (699, 'unstable'), (698, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=es_UY.UTF-8, LC_CTYPE=es_UY.UTF-8 (charmap=UTF-8), LANGUAGE=es_UY:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bumblebee-nvidia depends on: ii bumblebee3.2.1-18 ii glx-alternative-nvidia 0.8.8 ii nvidia-legacy-390xx-driver 390.87-3 ii nvidia-legacy-390xx-kernel-dkms 390.87-3 bumblebee-nvidia recommends no packages. bumblebee-nvidia suggests no packages. -- no debconf information
Bug#916413: libqt5serialbus5-plugins: socketcan plugin not included
I have just found out that the test that it's supposed to detect the right can headers are missing from the tarball provided by upstream. I'll need to do further checks.
Bug#916470: rasdaemon: wrong homepage
Package: rasdaemon Version: 0.6.0-1.2 Severity: normal Homepage: https://apps.fedorahosted.org/packages/rasdaemon is outdated. The new one is https://pagure.io/rasdaemon
Bug#916471: RM: oclgrind [mips s390x] -- ROM; FTBFS on big-endian architectures
Package: ftp.debian.org Severity: normal Hi, please remove the big-endian cruft of oclgrind. Upstream seems to be not interested in more exotic architectures. Andreas
Bug#916439: libboost-python1.67-dev: Linking issues, can't find reference to PySlice_New and other symbols
Hi,
Il 14/12/18 14:34, Witold Baryluk ha scritto:
> $ objdump -R -T /usr/lib/x86_64-linux-gnu/libboost_python.so | grep PySlice
> D *UND*
> PySlice_New
> 00045778 R_X86_64_JUMP_SLOT PySlice_New
> $
>
> Yet, it doesn't link to proper library:
>
> $ ldd /usr/lib/x86_64-linux-gnu/libboost_python.so
> linux-vdso.so.1 (0x7ffdc62cf000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f70cfa6e000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f70cfa69000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f70cfa48000)
> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f70cfa43000)
> libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f70cf8c)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f70cf72c000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f70cf71)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f70cf553000)
> /lib64/ld-linux-x86-64.so.2 (0x7f70cfb0)
> $
>
> (no *python* libs linked). Is it using libdl to open python libs dynamically?
> How would that even work?
>
> The libpython2{,7}-dev are installed, and the symbols are in proper places:
>
> $ objdump -T -R /usr/lib/x86_64-linux-gnu/libpython2.7.so | grep PySlice_New
> 00172820 gDF .text00ec Base
> PySlice_New
> $
>
> Why libbost_pythonX is not linked with -lpythonX ?
I think this is intended: see for example [1] (from the upstream
repository). I am not really sure of what is the rationale behind this,
but since it seems to be a conscious upstream decision, I would not
change it.
[1] https://github.com/boostorg/python/blob/develop/build/Jamfile#L80
In practice, I think that you can fix your build failure by manually
adding -lpythonXY to your linking flags.
All the best, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
signature.asc
Description: OpenPGP digital signature
Bug#916469: libfixbuf-{dev,doc}: missing Breaks+Replaces: libfixbuf3-dev (<< 2)
Package: libfixbuf-dev,libfixbuf-doc Version: 2.2.0+ds-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../libfixbuf-dev_2.2.0+ds-1_amd64.deb ... Unpacking libfixbuf-dev:amd64 (2.2.0+ds-1) ... dpkg: error processing archive /var/cache/apt/archives/libfixbuf-dev_2.2.0+ds-1_amd64.deb (--unpack): trying to overwrite '/usr/include/fixbuf/autoinc.h', which is also in package libfixbuf3-dev:amd64 1.7.1+ds-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libfixbuf-dev_2.2.0+ds-1_amd64.deb Preparing to unpack .../libfixbuf-doc_2.2.0+ds-1_all.deb ... Unpacking libfixbuf-doc (2.2.0+ds-1) ... dpkg: error processing archive /var/cache/apt/archives/libfixbuf-doc_2.2.0+ds-1_all.deb (--unpack): trying to overwrite '/usr/share/doc-base/libfixbuf', which is also in package libfixbuf3-doc 1.7.1+ds-1 Errors were encountered while processing: /var/cache/apt/archives/libfixbuf-doc_2.2.0+ds-1_all.deb cheers, Andreas PS: you should set the Maintainer to the QA group when doing another upload if you still intend to orphan the package libfixbuf3-dev=1.7.1+ds-1_libfixbuf-dev=2.2.0+ds-1.log.gz Description: application/gzip
Bug#913946: llvm*-dbgsym still missing
Control: reopen -1 Still no -dbgsym packages, and the build log contains dh_strip -p libomp5-7 --dbgsym-migration='libomp5-7-dbg (<< 1:7~svn327768-1~)' PATH=/<>/llvm-toolchain-7-7.0.1~+rc3/:$PATH LD_LIBRARY_PATH=/<>/llvm-toolchain-7-7.0.1~+rc3/debian/tmp//usr/lib/llvm-7/lib/ dh_strip -a -v -XlibFuzzer.a -Xlibc++.a -Xlibc++abi.a -Xlibc++experimental.a -XlibclangTidyModernizeModule.a ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. which again looks like breaking fakeroot by replacing (rather than adding to) LD_LIBRARY_PATH. (This time the package sizes are about normal, but at least libLLVM-7.so.1 has become executable again.) I suspect the cause is https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/d441237cacb871abfebec1353b4b64398a362b0b (and if the commit log is what you intended, the test is the wrong way round). If you still want to use llvm-strip I again suggest LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:[build dir] and calling dh_fixperms again after dh_strip, but I thought the point of -fno-addrsig was to be able to use GNU strip.
Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout
On Friday, 14 December 2018 12:43:29 CET Adrian Bunk wrote: > On Sun, Nov 25, 2018 at 11:35:37PM +0100, Stefan Fritsch wrote: > >... > > > > I don't see why it should take so > > long for the random number generator to initialize. > > > >... > > On embedded systems without hwrng "10 minutes" or "2 hours" are > real-life observations for the time it takes. > > Note that this became more problematic due to the CVE-2018-1108[1] > fix (reverted in stretch, but in buster/unstable). Is systemd-random-seed.service broken there? The rng should be initialized after the seed is loaded from disk. Adrian, please send the output of journalctl -b UNIT=apache2.service + UNIT=systemd-random-seed.service + _TRANSPORT=kernel|grep -i -e apache -e random if apache2 fails to start.
Bug#916468: dune: /usr/bin/dune is already provided by the whitedune package
Package: dune Version: 1.6.2-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Selecting previously unselected package dune. Preparing to unpack .../dune_1.6.2-1_amd64.deb ... Unpacking dune (1.6.2-1) ... dpkg: error processing archive /var/cache/apt/archives/dune_1.6.2-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/dune', which is also in package whitedune 0.30.10-2.1+b2 Errors were encountered while processing: /var/cache/apt/archives/dune_1.6.2-1_amd64.deb This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): usr/bin/dune usr/share/man/man1/dune.1.gz Cheers, Andreas PS: for more information about the detection of file overwrite errors of this kind see https://qa.debian.org/dose/file-overwrites.html whitedune=0.30.10-2.1+b2_dune=1.6.2-1.log.gz Description: application/gzip
Bug#916467: ifupdown: settle-dad.sh fails when interface is unplugged
Package: ifupdown Version: 0.8.19 Severity: normal * Steps to reproduce: 1. Configure interface with a static ipv6 address # cat /etc/network/interfaces.d/eth1 auto eth1 iface eth1 inet static 10.2.3.4 netmask 255.255.255.0 iface eth1 inet6 static address fd60:d925::: netmask 64 2. Restart networking service. Note that the address is assigned: # systemctl restart networking # ip -6 addr show dev eth1 inet6 fd60:d925:::/64 scope global valid_lft forever preferred_lft forever 3. Now unplug interface and restart networking service * Expected Results: - Networking service restarts successfully * Actual results - Networking service goes to failed state * Cause I think this line of code https://salsa.debian.org/debian/ifupdown/blob/master/inet6.defn#L98 causes ifup to fail if the interface is unplugged. In particular after unplug and restart, my ipv6 address is added as "tentative" and settle-dad.sh does not like it: # ip -6 addr show dev eth1 inet6 fd60:d925:::/64 scope global tentative valid_lft forever preferred_lft forever * Workaround: Put "dad-attempts 0" in the ipv6 stanza with static address. However, I would like to have the DAD capacbility. Would it be possible to set dad-attempts condionally i.e. add `nodad` also if the interface is unplugged https://salsa.debian.org/debian/ifupdown/blob/master/inet6.defn#L95 ? --- up and down scripts installed: /etc/network/if-down.d: total 4 -rwxr-xr-x 1 root root 332 Jun 2 2015 upstart lrwxrwxrwx 1 root root 32 Aug 9 00:23 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-post-down.d: total 0 lrwxrwxrwx 1 root root 23 Jan 23 2017 avahi-daemon -> ../if-up.d/avahi-daemon lrwxrwxrwx 1 root root 32 Aug 9 00:23 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-pre-up.d: total 0 lrwxrwxrwx 1 root root 32 Aug 9 00:23 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-up.d: total 12 -rwxr-xr-x 1 root root 484 Jan 23 2017 avahi-daemon -rwxr-xr-x 1 root root 972 Mar 1 2018 openssh-server -rwxr-xr-x 1 root root 1483 Jun 2 2015 upstart lrwxrwxrwx 1 root root 32 Aug 9 00:23 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.115 ii init-system-helpers 1.48 ii iproute2 4.9.0-1+deb9u1 ii libc62.24-11+deb9u3 ii lsb-base 9.20161125 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.3.5-3+deb9u1 Versions of packages ifupdown suggests: ii ppp 2.4.7-1+4 pn rdnssd -- no debconf information
Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7
On 14.12.18 12:48, Simon McVittie wrote: > Control: forwarded -1 > https://salsa.debian.org/ci-team/autopkgtest/merge_requests/42 > Control: tags -1 + patch > > On Fri, 14 Dec 2018 at 11:31:02 +, Simon McVittie wrote: >> tl;dr: autopkgtest-virt-qemu doesn't work with python3.7. > > This seems to be caused by using socket.send() (and assuming the entire > buffer will be sent in one transaction) instead of socket.sendall(). > This was always a bug, at least in theory. I don't know why Python 3.7 > makes it significant in practice when it wasn't previously. if you already ran autopkg using 3.7, then that might point out to the recent 3.7.2 release candidate 1. changes. At least the timing of the report suggests this. https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-2-release-candidate-1
Bug#916398: sddm: Wayland autologin sometimes fails - probable tty1 race
Control: tags -1 patch That works (starts successfully with the desktop on tty1) - due to the intermittent nature of the bug I can't be sure it's gone, but if we're right about the cause it should be. Full sddm.service tested: [Unit] Description=Simple Desktop Display Manager Documentation=man:sddm(1) man:sddm.conf(5) # Change this if you want to start sddm in a different tty Conflicts=getty@tty7.service getty@tty1.service After=getty@tty7.service getty@tty1.service After=systemd-user-sessions.service systemd-logind.service # If using tty1 and plymouth, sddm will fail till plymouth stops # consider using: ## After=plymouth-quit.service # or to forcefully stop plymouth and start earlier: ## Conflicts=plymouth-quit-wait.service ## After=plymouth-start.service plymouth-quit-wait.service ## OnFailure=plymouth-quit.service [Service] # temporary safety check until all DMs are converted to correct # display-manager.service symlink handling ExecStartPre=/bin/sh -c '[ "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/sddm" ]' ExecStart=/usr/bin/sddm Restart=always RestartSec=1s EnvironmentFile=-/etc/default/locale
Bug#910541: [rb-general] salsa is fine
On Fri, Dec 14, 2018 at 07:19:46PM +0100, Chris Lamb wrote: > My reading of this is that (ignoring Debian-specific issues as they > are an "easy" case IMHO) salsa becomes the single source of truth; ie. > we both encourage and at least aim to forward/refile all "upstream" > bugs to Salsa. absolutly. > I'm totally cool with that, I only insist on it not being undefined or > ambiguous. great! I just wanted to enable issues on diffoscope.git on salsa, but couldnt find the setting... so: could someone else please do that? :) Once this has been done, we also need to update CONTRIBUTING.rst to reflect this new reality. (I'm happy to do so, but don't want to do it before the feature is enabled...) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#916466: dokuwiki: failed dependency of php-bcmath for authad
Package: dokuwiki
Version: 0.0.20180422.a-2
Severity: minor
Dear Maintainer,
after enabling authad in config it was not possible to authenticate to
dokuwiki:
[Fri Dec 14 18:16:04.913610 2018] [php7:error] [pid 102906] [client
127.0.0.1:48292] PHP Fatal error: Uncaught adLDAPException: Missing function
support [bcmod] http://php.net/manual/en/book.bc.php in
/var/lib/dokuwiki/lib/plugins/authad/adLDAP/classes/adLDAPUsers.php:324\nStack
trace:\n#0 /var/lib/dokuwiki/lib/plugins/authad/auth.php(251):
adLDAPUsers->passwordExpiry('user1')\n#1
/var/lib/dokuwiki/lib/plugins/authchained/auth.php(253):
auth_plugin_authad->getUserData('user1')\n#2
/usr/share/dokuwiki/inc/auth.php(1233):
auth_plugin_authchained->getUserData('user1')\n#3
/usr/share/dokuwiki/inc/auth.php(229): auth_setCookie('user1',
'\\xAD?\\xFDE$\\xD4[\\xDE25`\\xCC\\x00v\\xFC...', false)\n#4
/usr/share/dokuwiki/inc/auth.php(177): auth_login('user1', 'pass', false,
false)\n#5 /usr/share/dokuwiki/inc/events.php(111):
auth_login_wrapper(Array)\n#6 /usr/share/dokuwiki/inc/events.php(256):
Doku_Event->trigger('auth_login_wrap...', true)\n#7
/usr/share/dokuwiki/inc/auth.php(109): trigger_event('AUTH_LOGIN_CHEC...',
Array, 'auth_login_wrap...')\n#8 /usr/share/dokuwiki/inc/init.php(215) in
/var/lib/dokuwiki/lib/plugins/authad/adLDAP/classes/adLDAPUsers.php on line
324, referer: https://127.0.0.1/dokuwiki/doku.php?id=start=login=
After installing php-bcmath it works.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.15.18-9-pve (SMP w/24 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dokuwiki depends on:
ii debconf [debconf-2.0] 1.5.69
ii javascript-common 11
ii libjs-jquery 3.2.1-1
ii libjs-jquery-cookie12-1.1
ii libjs-jquery-ui1.12.1+dfsg-5
ii libphp-simplepie 1.3.1+dfsg-3.1
ii php2:7.3+68
ii php-geshi 1.0.8.11-3
ii php-phpseclib 2.0.12-1
ii php-random-compat 2.0.17-1
ii php-xml2:7.3+68
ii php7.3 [php] 7.3.0~rc4-1
ii php7.3-xml [php-xml] 7.3.0~rc4-1
ii ucf3.0038
Versions of packages dokuwiki recommends:
ii imagemagick 8:6.9.10.14+dfsg-7
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.14+dfsg-7
ii php-ldap 2:7.3+68
ii php7.3-cli [php-cli] 7.3.0~rc4-1
ii php7.3-ldap [php-ldap] 7.3.0~rc4-1
ii wget 1.19.5-2
/etc/dokuwiki/plugins.local.php changed:
Bug#916465: prosody: Do not replace certificates on update
Package: prosody Version: 0.11.1-1 Severity: normal Dear Maintainer, I just updated to this version today. I was surprised to find my xmpp users all received certificate warnings, flagging old, expired, self-signed certificates offered by my system. On inspection, I found these two symlinks: /etc/prosody/certs/localhost.crt /etc/prosody/certs/localhost.key had been replaced and were (again) pointing to my crummy self-signed "snake oil" certificate instead of my current Let's Encrypt-issued certificate. If these symlinks exist, they should not be overwritten or modified (at least not without warning the administrator). Thanks, Scott sc...@cartasoft.com -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (900, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prosody depends on: ii adduser 3.118 ii libc6 2.27-8 ii libidn111.33-2.2 ii libssl1.1 1.1.1a-1 ii lsb-base10.2018112800 ii lua-bitop [lua5.2-bitop]1.0.2-5 ii lua-expat [lua5.2-expat]1.3.0-4 ii lua-filesystem [lua5.2-filesystem] 1.6.3-1 ii lua-sec [lua5.2-sec]0.7-1 ii lua-socket [lua5.2-socket] 3.0~rc1+git+ac3201d-4 ii lua5.2 5.2.4-1.1+b2 ii ssl-cert1.0.39 Versions of packages prosody recommends: ii lua-event [lua5.2-event] 0.4.5-1 Versions of packages prosody suggests: ii lua-dbi-mysql 0.7.1-1 pn lua-dbi-postgresql pn lua-dbi-sqlite3 ii lua-zlib0.2+git+1+9622739-2.1 -- Configuration Files: /etc/prosody/conf.avail/example.com.cfg.lua [Errno 13] Permission denied: '/etc/prosody/conf.avail/example.com.cfg.lua' /etc/prosody/conf.avail/localhost.cfg.lua [Errno 13] Permission denied: '/etc/prosody/conf.avail/localhost.cfg.lua' /etc/prosody/prosody.cfg.lua [Errno 13] Permission denied: '/etc/prosody/prosody.cfg.lua' -- no debconf information
Bug#821397: ITP: sway -- i3-compatible Wayland compositor
Hi folks, Thanks for the work already done to bring this package to debian. Any update of a possible upload of b2 to experimental? Cheers Mike Michele Cane, PhD.
Bug#916058: Widevine not working yet
I confirm widevine not working on any page, had to go back to 70.0.3538.110 to make it work. Why is taking so long to fix this simple bug?
