Bug#906115: gnucash: Possible ibus interaction problem?
Package: gnucash Version: 1:3.2-1 Followup-For: Bug #906115 I was actually looking around for a possible solution to bug 839159 which I've started to experience, and ended up installing ibus. After installing ibus, I get the behaviour described in this bug - any key press on an account entry will cause gnucash to crash. Removing ibus, it all starts to work again (except for the issues I'm seeing from bug 839159, but that's a sepoerate thing). I'm wondering if this might be related to the problem that Michael is seeing in bug 906115, and whether there might be some kind of compatibility issue there? All the best, -DH. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable-updates'), (450, 'unstable'), (450, 'stable'), (445, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnucash depends on: ii gnucash-common 1:3.2-1 ii guile-2.22.2.4+1-1 ii guile-2.2-libs 2.2.4+1-1 ii libaqbanking35 5.7.8-2 ii libaqbanking35-plugins 5.7.8-2 ii libatk1.0-0 2.28.1-1 ii libboost-date-time1.62.0 1.62.0+dfsg-8 ii libboost-filesystem1.62.01.62.0+dfsg-8 ii libboost-locale1.62.01.62.0+dfsg-8 ii libboost-regex1.62.0 1.62.0+dfsg-8 ii libboost-system1.62.01.62.0+dfsg-8 ii libc62.27-5 ii libcairo-gobject21.15.12-1 ii libcairo21.15.12-1 ii libcrypt-ssleay-perl 0.73.06-1 ii libdate-manip-perl 6.72-1 ii libdbi1 0.9.0-5 ii libfinance-quote-perl1.47-1 ii libgc1c2 1:7.4.2-8.3 ii libgcc1 1:8.2.0-4 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libglib2.0-0 2.56.1-2 ii libgtk-3-0 3.22.30-2 ii libgwenhywfar60 4.20.0-1 ii libhtml-tableextract-perl2.15-1 ii libhtml-tree-perl5.07-1 ii libicu60 60.2-6 ii libjavascriptcoregtk-4.0-18 2.20.5-dmo1 ii libktoblzcheck1v51.49-4 ii libofx7 1:0.9.13-2 ii libpango-1.0-0 1.42.4-1 ii libpangocairo-1.0-0 1.42.4-1 ii libsecret-1-00.18.6-1 ii libsoup2.4-1 2.62.2-2 ii libstdc++6 8.2.0-4 ii libwebkit2gtk-4.0-37 2.20.5-dmo1 ii libwww-perl 6.35-2 ii libxml2 2.9.4+dfsg1-7+b1 ii libxslt1.1 1.1.32-2 ii perl 5.26.2-7 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gnucash recommends: ii gnucash-docs 3.2-1 ii python3-gnucash 1:3.2-1 ii yelp 3.28.1-1 Versions of packages gnucash suggests: ii libdbd-mysql0.9.0-6 pn libdbd-pgsql pn libdbd-sqlite3 -- Configuration Files: /etc/gnucash/environment changed [not included] -- no debconf information
Bug#907605: developers-reference: Alioth references in README-contrib
Package: src:developers-reference Severity: minor Tags: patch Dear developers-reference maintainers, there is still a reference to alioth in the file README-contrib. I've preaded this MR for it: https://salsa.debian.org/debian/developers-reference/merge_requests/2 Cheers, -- tobi
Bug#783307: ITP: fzf -- General-purpose command-line fuzzy finder
control: owner ! the two original ITP submitters are either missing, or not interested in fzf anymore. I'm taking over this ITP and this is not any kind of ITP hijack. -- Best,
Bug#907604: abi-compliance-checker: -fpic required on arm64 for gcc-8
Package: abi-compliance-checker Version: 2.3-0.1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu cosmic ubuntu-patch Hi Mathieu, In updating a-c-c in Ubuntu, I also found that it now fails its autopkgtests on arm64, due to toolchain updates which now require use of PIC for some of the relocations present in the C++ test code: [...] Total binary compatibility problems: 81, warnings: 57 Total source compatibility problems: 38, warnings: 57 Report: compat_reports/libsample_c/1.0_to_2.0/compat_report.html Test result: SUCCESS (119 problems found) Verifying detectable C++ library changes ERROR: can't compile libsample_cpp v.1: 'libsample_cpp/libsample.v1/build-log.txt' autopkgtest [05:12:02]: test self-test: ---] [...] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/arm64/a/abi-compliance-checker/20180830_051216_f4bd1@/log.gz After reproducing interactively: $ cat libsample_cpp/libsample.v1/build-log.txt /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS21UnsafeVirtualOverrideE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccEHuofR.o: in function `TestNS::UnsafeVirtualOverride::~UnsafeVirtualOverride()': /home/vorlon/abi-compliance-checker-2.3/libsample_cpp/libsample.v1/libsample.cpp:43:(.text+0x20): dangerous relocation: unsupported relocation /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS21UnsafeVirtualOverrideE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /home/vorlon/abi-compliance-checker-2.3/libsample_cpp/libsample.v1/libsample.cpp:43:(.text+0x2c): dangerous relocation: unsupported relocation /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS21UnsafeVirtualOverrideE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccEHuofR.o: in function `TestNS::UnsafeVirtualOverride::UnsafeVirtualOverride()': /home/vorlon/abi-compliance-checker-2.3/libsample_cpp/libsample.v1/libsample.cpp:42:(.text+0x2bc): dangerous relocation: unsupported relocation /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS21UnsafeVirtualOverrideE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /home/vorlon/abi-compliance-checker-2.3/libsample_cpp/libsample.v1/libsample.cpp:42:(.text+0x2c8): dangerous relocation: unsupported relocation /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS28RemovedInlineVirtualFunctionE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccEHuofR.o: in function `TestNS::RemovedInlineVirtualFunction::RemovedInlineVirtualFunction()': /home/vorlon/abi-compliance-checker-2.3/libsample_cpp/libsample.v1/libsample.cpp:54:(.text+0x308): dangerous relocation: unsupported relocation /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS23AddedVirtualMethodAtEndE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccEHuofR.o: in function `TestNS::AddedVirtualMethodAtEnd::AddedVirtualMethodAtEnd()': /home/vorlon/abi-compliance-checker-2.3/libsample_cpp/libsample.v1/libsample.cpp:69:(.text+0x35c): dangerous relocation: unsupported relocation /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS25AddedPrivateVirtualSymbolE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccEHuofR.o: in function `TestNS::AddedPrivateVirtualSymbol::AddedPrivateVirtualSymbol()': /home/vorlon/abi-compliance-checker-2.3/libsample_cpp/libsample.v1/libsample.cpp:87:(.text+0x394): dangerous relocation: unsupported relocation /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS23OverriddenVirtualMethodE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccEHuofR.o: in function `TestNS::OverriddenVirtualMethod::OverriddenVirtualMethod()': /home/vorlon/abi-compliance-checker-2.3/libsample_cpp/libsample.v1/libsample.cpp:110:(.text+0x3fc): dangerous relocation: unsupported relocation /usr/bin/ld: /tmp/ccEHuofR.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN6TestNS24OverriddenVirtualMethodBE' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccEHuofR.o: in function `TestNS::OverriddenVirtualMethodB::OverriddenVirtualMethodB()': /home/vorlon/abi-compliance-checker-2.3/libsample_cp
Bug#783307: ITP: fzf -- General-purpose command-line fuzzy finder
On Tue, 28 Aug 2018, at 2:55 PM, Mo Zhou wrote: > And are you still interested in maintaining it? I'm no longer interested in maintaining this. Anyone is free to use https://github.com/tomfitzhenry/pkg-fzf
Bug#907559: [j...@apache.org: [jira] [Commented] (BATIK-1239) Class XMLConstants vanished from Batik]
[Uploaders of batik package in CC as well.] Markus, this is kind of a response to your suggestion to communicate with upstream. I admit I do not know what conclusion to draw from it. Kind regards Andreas. - Forwarded message from "Glenn Adams (JIRA)" - Date: Thu, 30 Aug 2018 04:36:00 + (UTC) From: "Glenn Adams (JIRA)" To: ti...@debian.org Subject: [jira] [Commented] (BATIK-1239) Class XMLConstants vanished from Batik [ https://issues.apache.org/jira/browse/BATIK-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16597050#comment-16597050 ] Glenn Adams commented on BATIK-1239: I performed the modularization a few years back when converting to a maven build architecture. One of the problems being addressed in that process was eliminating circularities among the graph of batik artifact dependencies, which resulted in the current modularization choices. It is clear that other choices are possible as well, and it is only in the use of these artifacts in a particular application of batik that it can be determined whether the modularization is adequate or needs improvements. I am not (at present) working on batik, and I know of no member of the XML Graphics project that is planning to make changes, other than Simon's work to respond to occasional bug requests. In light of the volunteer nature of the project, I suggest you contribute one or more patches that addresses the issues you encounter. > Class XMLConstants vanished from Batik > -- > > Key: BATIK-1239 > URL: https://issues.apache.org/jira/browse/BATIK-1239 > Project: Batik > Issue Type: Bug > Components: Utilities >Affects Versions: 1.10 > Environment: Debian >Reporter: Andreas Tille >Priority: Major > > Hi, > I'm facing a problem in Debian with a package that is using Batik that does > not explicitly contain XMLConstants but fails to start anyway. The issue is > discussed in the according [bug report|https://bugs.debian.org/907559] and > the suggestion was to contact Batik authors whether there is a hint how to > deal with the issue. > Kind regards, Andreas. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - End forwarded message - -- http://fam-tille.de
Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1
-=| Kurt Roeckx, 24.08.2018 18:52:57 +0200 |=- > On Fri, Aug 24, 2018 at 10:27:16AM +, Damyan Ivanov wrote: > > -=| Kurt Roeckx, 23.08.2018 22:32:13 +0200 |=- > > > Note that the SIGPIPE issue is probably a known upstream issue > > > that still needs to be fixed, we're at least still working on a > > > SIGPIPE issue. > > > > > > But that does not mean that the other issues in libnet-ssleay-perl > > > should not get fixed. > > > > I tried applying all the patches from the fedora package of > > Net-SSLeay, and it didn't help much. > > > > It was mentioned in the upstream ticket that an additional fix is > > needed on libssl side, see > > https://bugzilla.redhat.com/show_bug.cgi?id=1615098 > > > > The reproducer from there fails with 1.1.1~~pre9-1 from unstable. > > > > Does this seem like something that needs to be fixed on the openssl > > side? > > This is something that should get fixed in whatever calls > TLSv1_method(). You should never call that function. It's also > been deprecated. > > The problem is that TLSv1_method() only supports TLS 1.0, and the > default config now says that TLS 1.2 is the minimum verison. You > should either use SSLv23_method() or TLS_method(), which support all > protocol versions that are enabled. I worked around this in Net::SSLeay by patching the routine that sets certificate and key to return an error condition only if any of the underlying routines return an error condition (https://salsa.debian.org/perl-team/modules/packages/libnet-ssleay-perl/blob/master/debian/patches/ok-result-is-no-error.patch). Previously it would check the error stack and ignore the return codes. On a more general note, the package seems ready for unstable to me. Reviews are welcome. If no obstacles appear, I plan to upload on late Sunday. -- dam
Bug#868525: guile-2.0: New upstream version available
Sebastien Bacher writes: > I don't know about guile-gnome-platform but the current version has > support for guile-2.2 so it might be only a rebuild changing the > build-depends is needed. Since the package has currently no maintainer > you could perhaps give it a try and upload the change yourself if that > seems to work? In any case it has only one rdepends (gwave) so I think > it should be doable to get those sort out one way or another beofre buster. Hmm, might not be trivial -- looks like building it might require guile-cairo-dev and libgwrap-runtime-dev, both of which might also have to be upgraded (or adapted) for guile-2.2. I suppose if we're to have any chance of removing guile-2.0 for buster, we don't have too much time left. I think we've finally gotten the guile-2.2 tests passing reliably on all the release architectures, at least. > Note that we switched aisleriot to guile-2.2 some days ago which is also > a step in the right direction to remove 2.0 > https://packages.qa.debian.org/a/aisleriot/news/20180823T170429Z.html Great, and thanks. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#906380: libtool: FTBFS in buster/sid
at bottom :- On 30/08/2018, Juhani Numminen wrote: > Hello, > > Looking at the log[1] at reproducible builds, it looks like a test failure: > >> Support for older libltdl interfaces. >> >> 102: Makefile.incFAILED >> (old-ltdl-iface.at:134) > > I had a look at Fedora's libtool repository, and there's an interesting > commit: > "ftbfs: caused by automake 1.16.1"[2]. > > It might be the same issue that we're seeing, because that commit patches > the file tests/old-ltdl-iface.at, and the first build failure at RB[3] > happened in 2018-08-13 in buster, while automake 1.16.1 had migrated to > buster > in 2018-08-10[4]. > > > With best regards, > Juhani > > [1] > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libtool_2.4.6-2.1.rbuild.log.gz > [2] > https://src.fedoraproject.org/rpms/libtool/c/20511dec725523a30496f1183322f8c6658acfdd > [3] https://tests.reproducible-builds.org/debian/history/libtool.html > [4] https://tracker.debian.org/pkg/automake-1.16 > > -- > To unsubscribe, send mail to 906380-unsubscr...@bugs.debian.org. > I, and I guess others would welcome a test build if it helps to see if the issue is resolved. See how to apply patch [1] and see if you can do the same thing - 1. https://unix.stackexchange.com/questions/324680/how-to-apply-a-patch-in-a-debian-package Look forward to seeing a new deb package and trying it out to see if it fixes the issue. Can't compile any packages due to the libtool issues :( -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#907602: abi-compliance-checker: reduce memory high water mark for a-c-c
Package: abi-compliance-checker
Version: 2.3-0.1
Followup-For: Bug #907602
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch
Sorry, with the previous patch a-c-c fails its own autopkgtest due to a
thinko. Revised patch attached.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
--- abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
1969-12-31 16:00:00.0 -0800
+++ abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
2018-08-29 16:27:49.0 -0700
@@ -0,0 +1,293 @@
+Description: Run packing commands in a subprocess
+ On low-memory VMs (such as autopkgtest runners at scale), a-c-c can OOM when
+ trying to launch a subprocess towards the end of the run due to the main
+ process's memory usage being >= 50% of available system memory. Since
+ freeing memory for no-longer-needed variables is non-trivial in perl, just
+ address this by creating a subprocess for handling any system() calls late
+ in the process.
+Author: Steve Langasek
+Last-Modified: 2018-08-29
+
+Index: abi-compliance-checker-2.3/abi-compliance-checker.pl
+===
+--- abi-compliance-checker-2.3.orig/abi-compliance-checker.pl
abi-compliance-checker-2.3/abi-compliance-checker.pl
+@@ -60,6 +60,9 @@
+ use Cwd qw(abs_path cwd);
+ use Data::Dumper;
+
++# stupid pipe tricks
++use IO::Handle;
++
+ my $TOOL_VERSION = "2.3";
+ my $ABI_DUMP_VERSION = "3.5";
+ my $ABI_DUMP_VERSION_MIN = "3.5";
+@@ -9340,9 +9343,9 @@
+ exitStatus("Not_Found", "can't find \"tar\" command");
+ }
+ chdir($UnpackDir);
+-system("$TarCmd -xvzf \"$Path\" >\"$TmpDir/null\"");
+-if($?) {
+-exitStatus("Error", "can't extract \'$Path\' ($?): $!");
++my @res = child_exec("$TarCmd -xvzf \"$Path\" >\"$TmpDir/null\"");
++if($res[0]) {
++exitStatus("Error", "can't extract \'$Path\' ($res[0]):
$res[1]");
+ }
+ chdir($In::Opt{"OrigDir"});
+ my @Contents = cmdFind($UnpackDir, "f");
+@@ -9371,11 +9374,11 @@
+ my $Pkg = $To."/".$Name.".zip";
+ unlink($Pkg);
+ chdir($To);
+-system("$ZipCmd -j \"$Name.zip\" \"$Path\"
>\"".$In::Opt{"Tmp"}."/null\"");
+-if($?)
++my @res = child_exec("$ZipCmd -j \"$Name.zip\" \"$Path\"
>\"".$In::Opt{"Tmp"}."/null\"");
++if($res[0])
+ { # cannot allocate memory (or other problems with "zip")
+ chdir($In::Opt{"OrigDir"});
+-exitStatus("Error", "can't pack the ABI dump: ".$!);
++exitStatus("Error", "can't pack the ABI dump: ".$res[1]);
+ }
+ chdir($In::Opt{"OrigDir"});
+ unlink($Path);
+@@ -9395,10 +9398,10 @@
+ if(-e $Pkg) {
+ unlink($Pkg);
+ }
+-system($TarCmd, "-C", $From, "-czf", $Pkg, $Name);
+-if($?)
++@res = child_exec($TarCmd, "-C", $From, "-czf", $Pkg, $Name);
++if($res[0])
+ { # cannot allocate memory (or other problems with "tar")
+-exitStatus("Error", "can't pack the ABI dump: ".$!);
++exitStatus("Error", "can't pack the ABI dump: ".$res[1]);
+ }
+ unlink($Path);
+ return $To."/".$Name.".tar.gz";
+@@ -10143,6 +10146,37 @@
+ initAliases_TypeAttr($LVer);
+ }
+
++sub child_exec(@)
++{
++# known failure to handle values that need shell escaping.
++print CHILD_WTR join(' ',@_) . "\n";
++chomp($line = );
++my @results = split(/ /,$line, 2);
++return (int($results[0]),$results[1]);
++}
++
++sub reap_child(@)
++{
++my ($handle, $pid) = @_;
++print $handle "exit\n";
++close $handle;
++waitpid($pid,0);
++}
++
++sub exec_helper(@)
++{
++my ($reader, $writer) = @_;
++do {
++chomp($line = <$reader>);
++ next if (!$line);
++if ($line eq 'exit') {
++exit(0);
++}
++system($line);
++print $writer "$? $!\n";
++} while(1);
++}
++
+ sub scenario()
+ {
+ setTarget("default");
+@@ -10395,6 +10429,22 @@
+ testTool();
+ exit(0);
+ }
++
++# stupid pipe tricks
++pipe(PARENT_RDR, CHILD_WTR);
++pipe(CHILD_RDR, PARENT_WTR);
++CHILD_WTR->autoflush(1);
++PARENT_WTR->autoflush(1);
++if ($helper_pid = fork()) {
++close PARENT_RDR;
++close PARENT_WTR;
++} else {
++die "cannot fork: $!" unless defined $helper_pid;
++close CHILD_RDR;
++close CHILD_WTR;
++exec_helper
Bug#826558: ubuntu-archive-keyring: Adds ubuntu-archive-keyring.gpg to /etc/apt/trusted.gpg.d/ without my consent
Hi, Thanks for working on this! - s/enebled/enabled/ - "use Ubuntu archive as same as Debian archive" is hard to understand for me; I'm not sure it's correct English; it might be useful to ask the debian-l10n-english team to review the new strings. More generally, regarding the phrasing of the new user-visible strings: the one I have proposed uses terminology found in the APT documentation, for consistency's sake. It seems to me that the one you're proposing here fits less well in the surrounding ecosystem, but YMMV :) Cheers!
Bug#564173: wmcalc: wrong result in simple calculation, then abort on _XSend:
This bug still persists in wmcalc 0.6, although a fix has been submitted upstream [1]. [1] https://groups.google.com/forum/#!topic/wmaker-dev/4uEVw8bm-cU
Bug#907603: taskwarrior: Task sync fails with "Aborted"
Package: taskwarrior Version: 2.5.1+dfsg-6 Severity: important Dear Maintainer, * What led up to the situation? A long-functioning taskwarrior installation fails to sync and crashes, perhaps after a recent update. * What exactly did you do (or not do) that was effective (or ineffective)? Ran 'task sync'. Running 'task list' works as usual. * What was the outcome of this action? $ task sync Aborted $ Or, with debugging output turned on: $ task rc.debug=1 rc.debug.tls=3 sync c: INFO Server certificate will be verified but hostname ignored. c: 3 ASSERT: extensions.c[_gnutls_get_extension]:65 c: 3 ASSERT: extensions.c[_gnutls_get_extension]:65 c: 3 ASSERT: mpi.c[_gnutls_x509_read_uint]:246 c: 3 ASSERT: extensions.c[_gnutls_get_extension]:65 c: 3 ASSERT: extensions.c[_gnutls_get_extension]:65 c: 3 ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 c: 3 ASSERT: x509.c[get_alt_name]:1701 c: 3 ASSERT: extensions.c[_gnutls_get_extension]:65 c: 3 ASSERT: constate.c[_gnutls_epoch_get]:600 c: 3 ASSERT: system/threads.c[gnutls_system_mutex_lock]:120 Aborted $ * What outcome did you expect instead? Proper syncing with the taskserver, as usual. The taskserver (inthe.am) is fine, as my Debian jessie box and Android clients sync correctly. As part of debugging this anomaly, I have tried cloning and compiling taskwarrior from the upstream source, using Debian's libgnutls, with the same error. Thank you for your time! Taskwarrior makes my life better :)! Charlie -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.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) LSM: AppArmor: enabled Versions of packages taskwarrior depends on: ii libc62.27-5 ii libgcc1 1:8.2.0-4 ii libgnutls30 3.5.19-1 ii libstdc++6 8.2.0-4 ii libuuid1 2.32.1-0.1 taskwarrior recommends no packages. taskwarrior suggests no packages. -- no debconf information
Bug#907602: abi-compliance-checker: reduce memory high water mark for a-c-c
Package: abi-compliance-checker
Version: 2.3-0.1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch
Dear Mathieu,
Recently, telepathy-logger-qt has started failing its autopkgtests on
ppc64el on Ubuntu infrastructure. We have tracked this down to the fact
that a-c-c's memory usage for this particular library on this architecture
now exceeds half of the free memory on the small VMs used for autopkgtests,
and late in the process a-c-c will call system("tar") to compress the
result, and this requires 2x memory in the moment.
Since freeing memory down to the kernel level is non-trivial in perl, I've
prepared a patch that addresses this by spawning a subprocess early to
handle the other system() calls. Feedback welcome.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
--- abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
1969-12-31 16:00:00.0 -0800
+++ abi-compliance-checker-2.3/debian/patches/oom-exec-helper.patch
2018-08-29 16:27:40.0 -0700
@@ -0,0 +1,294 @@
+Description: Run packing commands in a subprocess
+ On low-memory VMs (such as autopkgtest runners at scale), a-c-c can OOM when
+ trying to launch a subprocess towards the end of the run due to the main
+ process's memory usage being >= 50% of available system memory. Since
+ freeing memory for no-longer-needed variables is non-trivial in perl, just
+ address this by creating a subprocess for handling any system() calls late
+ in the process.
+Author: Steve Langasek
+Last-Modified: 2018-08-29
+
+Index: abi-compliance-checker-2.3/abi-compliance-checker.pl
+===
+--- abi-compliance-checker-2.3.orig/abi-compliance-checker.pl
abi-compliance-checker-2.3/abi-compliance-checker.pl
+@@ -60,6 +60,9 @@
+ use Cwd qw(abs_path cwd);
+ use Data::Dumper;
+
++# stupid pipe tricks
++use IO::Handle;
++
+ my $TOOL_VERSION = "2.3";
+ my $ABI_DUMP_VERSION = "3.5";
+ my $ABI_DUMP_VERSION_MIN = "3.5";
+@@ -9340,9 +9343,9 @@
+ exitStatus("Not_Found", "can't find \"tar\" command");
+ }
+ chdir($UnpackDir);
+-system("$TarCmd -xvzf \"$Path\" >\"$TmpDir/null\"");
+-if($?) {
+-exitStatus("Error", "can't extract \'$Path\' ($?): $!");
++my @res = child_exec("$TarCmd -xvzf \"$Path\" >\"$TmpDir/null\"");
++if($res[0]) {
++exitStatus("Error", "can't extract \'$Path\' ($res[0]):
$res[1]");
+ }
+ chdir($In::Opt{"OrigDir"});
+ my @Contents = cmdFind($UnpackDir, "f");
+@@ -9371,11 +9374,11 @@
+ my $Pkg = $To."/".$Name.".zip";
+ unlink($Pkg);
+ chdir($To);
+-system("$ZipCmd -j \"$Name.zip\" \"$Path\"
>\"".$In::Opt{"Tmp"}."/null\"");
+-if($?)
++my @res = child_exec("$ZipCmd -j \"$Name.zip\" \"$Path\"
>\"".$In::Opt{"Tmp"}."/null\"");
++if($res[0])
+ { # cannot allocate memory (or other problems with "zip")
+ chdir($In::Opt{"OrigDir"});
+-exitStatus("Error", "can't pack the ABI dump: ".$!);
++exitStatus("Error", "can't pack the ABI dump: ".$res[1]);
+ }
+ chdir($In::Opt{"OrigDir"});
+ unlink($Path);
+@@ -9395,10 +9398,10 @@
+ if(-e $Pkg) {
+ unlink($Pkg);
+ }
+-system($TarCmd, "-C", $From, "-czf", $Pkg, $Name);
+-if($?)
++@res = child_exec($TarCmd, "-C", $From, "-czf", $Pkg, $Name);
++if($res[0])
+ { # cannot allocate memory (or other problems with "tar")
+-exitStatus("Error", "can't pack the ABI dump: ".$!);
++exitStatus("Error", "can't pack the ABI dump: ".$res[1]);
+ }
+ unlink($Path);
+ return $To."/".$Name.".tar.gz";
+@@ -10143,6 +10146,38 @@
+ initAliases_TypeAttr($LVer);
+ }
+
++sub child_exec(@)
++{
++# known failure to handle values that need shell escaping.
++print CHILD_WTR join(' ',@_) . "\n";
++chomp($line = );
++my @results = split(/ /,$line, 2);
++return (int($results[0]),$results[1]);
++}
++
++sub reap_child(@)
++{
++my ($handle, $pid) = @_;
++print $handle "exit\n";
++close $handle;
++waitpid($pid,0);
++exit(0);
++}
++
++sub exec_helper(@)
++{
++my ($reader, $writer) = @_;
++do {
++chomp($line = <$reader>);
++ next if (!$line);
++if ($line eq 'exit') {
++exit(0);
++}
++system($line);
++print $writer "$? $!\n";
++
Bug#907601: RFS: groonga/8.0.6-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "groonga" When my key is imported into debian-maintainers, I'll request upload permission later. * Package name: groonga Version : 8.0.6-1 Upstream Author : Groonga Project * Url : http://groonga.org/ * Licenses: LGPL-2.1 Section : database It builds those binary packages: * groonga * groonga-server-common * groonga-server-gqtp * libgroonga-dev * libgroonga0 * groonga-tokenizer-mecab * groonga-token-filter-stem * groonga-plugin-suggest * groonga-bin * groonga-httpd * groonga-doc * groonga-examples * groonga-munin-plugins To access further information about this package, visit the following URL: https://mentors.debian.net/package/groonga Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/groonga/groonga_8.0.6-1.dsc More information about groonga can be obtained from http://groonga.org/ Changes since last upload: * New upstream version 8.0.6. * debian/changelog - Apply M-x wh-cl to remove trailing whitespace. * debian/control - Bump standard-version to 4.2.1. No other changes are required. Regards,
Bug#907600: diffoscope: add option to ignore timestamp differences in containers
Package: diffoscope Version: 99 Severity: wishlist Tags: upstream Hi, diffoscope has been a very useful tool for me, in comparing dumps of various sorts spit out by several systems. It would be great to have an option to ignore timestamps, in order to be able to check if two tarballs/zipballs/whateverballs have the same contents, even if the contents were generated on different dates. Thanks for considering -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-rc5-amd64 (SMP w/4 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: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages diffoscope depends on: ii libpython3.6-stdlib3.6.6-3 ii python33.6.6-1 ii python3-distro 1.3.0-1 ii python3-distutils 3.6.6-1 ii python3-libarchive-c 2.1-3.1 ii python3-magic 2:0.4.15-2 ii python3-pkg-resources 39.2.0-1 Versions of packages diffoscope recommends: pn abootimg ii acl 2.2.52-3+b1 pn apktool pn binutils-multiarch ii bzip21.0.6-9 pn caca-utils ii colord 1.3.3-2 pn db-util ii default-jdk [java-sdk] 2:1.10-68 ii default-jdk-headless 2:1.10-68 pn device-tree-compiler pn docx2txt ii e2fsprogs1.44.4-2 pn enjarify pn fontforge-extras pn fp-utils ii genisoimage 9:1.1.11-3+b2 ii gettext 0.19.8.1-7 pn ghc ii ghostscript 9.22~dfsg-3 pn giflib-tools pn gnumeric ii gnupg2.2.9-2 ii imagemagick 8:6.9.10.8+dfsg-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.8+dfsg-1 pn jsbeautifier pn libarchive-tools pn llvm ii lz4 1.8.2-1 ii mono-utils 4.6.2.7+dfsg-2 pn odt2txt pn oggvideotools ii openjdk-10-jdk [java-sdk]10.0.2+13-1 ii openjdk-8-jdk [java-sdk] 8u181-b13-1 ii openssh-client 1:7.7p1-4 pn pgpdump ii poppler-utils0.63.0-2 pn procyon-decompiler pn python3-argcomplete pn python3-binwalk ii python3-debian 0.1.33 pn python3-defusedxml pn python3-guestfs pn python3-jsondiff ii python3-progressbar 2.3-4 ii python3-pyxattr 0.6.0-2+b2 pn python3-tlsh pn r-base-core ii rpm2cpio 4.14.1+dfsg1-4 pn sng ii sqlite3 3.24.0-1 ii squashfs-tools 1:4.3-6 pn tcpdump ii unzip6.0-21 ii vim-common 2:8.1.0320-1 ii xmlbeans 2.6.0+dfsg-4 ii xxd 2:8.1.0320-1 ii xz-utils 5.2.2-1.3 Versions of packages diffoscope suggests: ii libjs-jquery 3.2.1-1 -- no debconf information
Bug#907599: node-parse-json: Please package new upstream version
Package: node-parse-json Severity: important Dear Maintainer, Several reverse-dependencies depend on node-parse-json being greater than or equal to 3.0.0, but Debian has 2.2.0. Please package this new release to unblock reverse-dependencies. Thanks. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#902220: Needs porting to LLVM 6.0.1
Control: retitle -1 Needs porting to LLVM 6.0.1 Well, I just checked, even the latest trunk does not support LLVM 6.0.1. Or rather, it builds (with some minor, obvious modifications), but doesn't work. I haven't tested LLVM 6.0.0, it may or may not work. This needs to be looked into more. -rt
Bug#907466: Package doesn't ship xml files anymore
Package: iso-codes Version: 4.0-1 Followup-For: Bug #907466 Dear Maintainer, This bug affects gnome-control-center (package version 1:3.28.2-1). It breaks the functionality of the Region & Language panel, where it's not possible to list or change languages or formats and causes a segmentation fault when trying to add keyboard layouts. Running gnome-control-center from a terminal produces the following output: *** BEGIN OUTPUT *** $ gnome-control-center region (gnome-control-center:2244): GnomeDesktop-WARNING **: 21:41:43.080: Failed to load '/usr/share/xml/iso-codes/iso_639.xml': Failed to open file “/usr/share/xml/iso-codes/iso_639.xml”: No such file or directory (gnome-control-center:2244): GnomeDesktop-WARNING **: 21:41:43.080: Failed to load '/usr/share/xml/iso-codes/iso_639_3.xml': Failed to open file “/usr/share/xml/iso-codes/iso_639_3.xml”: No such file or directory (gnome-control-center:2244): GnomeDesktop-WARNING **: 21:41:43.080: Failed to load '/usr/share/xml/iso-codes/iso_3166.xml': Failed to open file “/usr/share/xml/iso-codes/iso_3166.xml”: No such file or directory (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.080: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.089: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.089: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.089: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.143: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.143: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.214: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.214: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.214: g_string_insert_len: assertion 'len == 0 || val != NULL' failed (gnome-control-center:2244): GLib-CRITICAL **: 21:41:43.214: g_string_insert_len: assertion 'len == 0 || val != NULL' failed Segmentation fault *** END OUTPUT *** Regards, Leandro Perona -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.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:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled iso-codes depends on no packages. iso-codes recommends no packages. Versions of packages iso-codes suggests: pn isoquery -- no debconf information
Bug#907598: firmware-amd-graphics: Add AMD Vega M firmware
Package: firmware-amd-graphics Version: 20180825-1 Severity: wishlist Dear Maintainer, Please consider adding the AMD Vega M firmware blobs. Support for the Vega M chipset was added to the Linux kernel amdgpu driver in version 4.18, and the firmware blobs were incorporated into the repository at git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git with commit 153a51e438cafe07610b28db0304b1721b91d847. Cheers, Austin
Bug#907596: grub-arm-efi fails to boot kernel
Package: grub-arm-efi Version: 2.02+dfsg1-6 Severity: important Tags: patch Attempting to boot the current armmp-lpae kernel from GRUB in an armhf QEMU/KVM instance results in an infinite loop of: Undefined OpCode Exception PC at 0x0002 CPSR 0x2133 Undefined OpCode Exception PC at 0x0002 CPSR 0x2133 Undefined OpCode Exception PC at 0x0002 CPSR 0x2133 Upstream has recently merged patches that switch the arm loader over to use the arm64 loader code, which fixes this. I've prepared a backport of the necessary patches: https://salsa.debian.org/dannf/grub/tree/arm32-debian
Bug#907597: scite: test file tests anything
Package: scite Version: 4.1.0-1 Severity: normal Dear maintainer, The file debian/tests/control says: # Test installability Depends: @ Test-Command: /bin/true The test file should test the command provided by the package. Please fix or drop the debian/tests/control file. To get help, see: https://codesearch.debian.net/search?q=Test-Command https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html Regards, Eriberto -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64)
Bug#902220: Processed: reopening 902220
On Wed, Aug 29, 2018 at 05:31:08PM -0400, Reinhard Tartler wrote: > > > On 08/29/2018 08:24 AM, Adrian Bunk wrote: > > AspectC++ upstream code already seems to support LLVM 6 (untested). > > That's contradictory to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906972#10 It is not. The one year old code in unstable does not support LLVM 6 for obvious reasons. > This needs to be looked into more. > > Also, why do you need to have this bug at severity serious? If llvm-4.0 was > removed from testing, that would prevent packages such as aspectc++ from > migrating as well? This is a release critical bug in aspectc++. This makes it visible that there is a problem in aspectc++ that needs fixing. Bugs in other reverse dependencies were already made release critical by the release team earlier (and fixed by the maintainers). This bug was fixed and closed, so noone corrected the severity. > -rt cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#906380: libtool: FTBFS in buster/sid
Hello, Looking at the log[1] at reproducible builds, it looks like a test failure: > Support for older libltdl interfaces. > > 102: Makefile.incFAILED > (old-ltdl-iface.at:134) I had a look at Fedora's libtool repository, and there's an interesting commit: "ftbfs: caused by automake 1.16.1"[2]. It might be the same issue that we're seeing, because that commit patches the file tests/old-ltdl-iface.at, and the first build failure at RB[3] happened in 2018-08-13 in buster, while automake 1.16.1 had migrated to buster in 2018-08-10[4]. With best regards, Juhani [1] https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libtool_2.4.6-2.1.rbuild.log.gz [2] https://src.fedoraproject.org/rpms/libtool/c/20511dec725523a30496f1183322f8c6658acfdd [3] https://tests.reproducible-builds.org/debian/history/libtool.html [4] https://tracker.debian.org/pkg/automake-1.16
Bug#907595: debhelper: Support of terse flag in DEB_BUILD_OPTIONS
Package: debhelper Version: 11.3.5 Severity: wishlist The cmake build system always passes the -DCMAKE_VERBOSE_MAKEFILE=ON option even if the DEB_BUILD_OPTIONS contains the terse tag. The tag means that build process should produce less output than usual[1]. Also somehow the DH_QUIET environment variable does not affect verbosity of Makefile. [1]: Debian Policy Manual, P. 4.9.1
Bug#902220: Processed: reopening 902220
On 08/29/2018 08:24 AM, Adrian Bunk wrote: > AspectC++ upstream code already seems to support LLVM 6 (untested). That's contradictory to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906972#10 This needs to be looked into more. Also, why do you need to have this bug at severity serious? If llvm-4.0 was removed from testing, that would prevent packages such as aspectc++ from migrating as well? -rt
Bug#907594: ofpathname: warning: command substitution: ignored null byte in input
Package: powerpc-ibm-utils Version: 1.3.2-1 Severity: normal On this G4 powermac, when i run "ofpathname /dev/sda" as root, i get this warning: /usr/sbin/ofpathname: line 812: warning: command substitution: ignored null byte in input if i use "bash -x $(which ofpathname) /dev/sda" it shows me: ++ /bin/cat /sys/devices/pci0002:24/0002:24:0d.0/devspec + OF_PATH=/pci@f400/ata-6@d + [[ -z /pci@f400/ata-6@d ]] + local vdev=/pci@f400 + local fc=/pci@f400/ata-6 + fc=ata-6 + [[ -e /proc/device-tree/pci@f400/ata-6@d/device_type ]] ++ /bin/cat /proc/device-tree/pci@f400/ata-6@d/device_type /usr/sbin/ofpathname: line 812: warning: command substitution: ignored null byte in input + devtype=ata and indeed, there is a trailing NUL byte there: 0 root@host:~# hd < /proc/device-tree/pci@f400/ata-6@d/device_type 61 74 61 00 |ata.| 0004 0 root@host:~# ofpathname should probably be clever enough to deal with that without emitting the warning. --dkg -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 4.17.0-3-powerpc-smp (SMP w/1 CPU core) 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 powerpc-ibm-utils depends on: ii bash 4.4.18-3.1 ii bc 1.07.1-2+b1 ii libc6 2.27-3 ii librtas2 2.0.0-2 ii librtasevent2 2.0.0-2 ii zlib1g 1:1.2.11.dfsg-1 powerpc-ibm-utils recommends no packages. Versions of packages powerpc-ibm-utils suggests: pn ipmitool pn sysfsutils -- no debconf information
Bug#907593: Buster: LXQT: No feedback when an app is launched
Package: lxqt Version: 27 For some apps (e.g. firefox) it takes a couple of seconds between when the Quick Launch icon is pressed and when the app actually opens its window. Other apps may open relatively quick, in a fraction of a second. Currently LXQT gives no indication that an app is being launched and may lead to confusion, giving the impression that nothing is happening and thus confusing the user into pressing the quick launch icon again. Then, a couple of seconds later, two windows/instances of the same app will open. Generally, this is not what I want. LXQT should give an indication that an app is being launched, KDE does this by changing the mouse cursor during the launch phase and LXQT should probably do something similar. Thanks
Bug#907592: global: gtags doesn't generate tags for R sources
Package: global Version: 6.6.2-3 Severity: normal gtags supports integration with pygments via a plugin to generate tags of identifiers and references. R is one of the languages supported via pygments. The pygments integration doesn't seem to generate tags when used with R source repos. Although it creates the G* files, they don't contain any tags for the sources. The same mechanism (pygments plugins) works for Ruby (another language supported by pygments). This was verified by following the example provided in the "Usage" section at https://github.com/yoshizow/global-pygments-plugin.
Bug#907591: nautilus-python: new upstream version 1.2.2 available
Source: nautilus-python Severity: wishlist Control: block 898622 with -1 Earlier this year, upstream released nautilus-python 1.2.2. It would be great to have this in debian, as it is one of the remaining hold-ups for getting mat2 packaged for debian. (see https://bugs.debian.org/898622). Regards, --dkg -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-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)
Bug#904109: kwin-x11: kwin frequently terminates without showing crash dialog
After upgrade to kwin-x11 4:5.13.4-1 kwin doesn't crash anymore on my system, so this bug report can be closed. Best regards, Miroslav Maiksnar
Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up
I avoided trying early kernel-4.17.x versions, but yesterday I updated from kernel-4.16.x to kernel 4.17.17-1, but frankly that change has not helped this lockup problem at all. For example, after trying direct use (with a KDE desktop if that makes any difference) for the first time with that kernel, the kernel only lasted a half an hour before I got a lockup which could only be solved by hitting the reset button! And roughly 8 hours later after that reset I got another lockup which also required a reset to regain control. So it appears the substantial number of AMD graphics fixes in kernel-4.17.x are not sufficient to stabilize use of this AMD RX 550 graphics card that should no longer be considered cutting-edge hardware (i.e. it was first offered for sale at least 16 months ago). Because of these on-going issues with direct use of this card, I am going back to using the X-terminal method with this kernel which experience with kernel-4.16.x shows is much more stable since it avoids using this graphics card completely (except for the direct display of the Linux console login prompt). I will try again to use this card directly when kernel-4.18.x is promoted to Buster. Alan __ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Bug#905113: gnome-shell-extension-taskbar: global.screen is not available in GNOME Shell 3.29
Control: reopen -1 Control: reassign -1 gnome-shell-extension-taskbar 57.0-2 > Package: gnome-shell-extension-dashtodock Oops, I filed this against the wrong package; reopening and reassigning to the right place. Full bug report below. > Version: 57.0-2 > Severity: important > Tags: upstream experimental > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: shell-3.30 > > According to codesearch.debian.net, this extension uses the MetaScreen > via global.screen. MetaScreen no longer exists in GNOME 3.29, which is > starting to become available in experimental. This extension will need > code changes to use the MetaDisplay (global.display), > MetaWorkspaceManager (global.workspace_manager), MetaMonitorManager > (Meta.MonitorManager.get()) or MetaX11Display > (global.display.get_x11_display()). > > Because GNOME 3.29/3.30 is not a stable release yet and is not in > Debian unstable yet, you'll probably need to condition on the GNOME > Shell version. > > smcv
Bug#907590: grafana: CVE-2018-15727: authentication bypass flaw
Source: grafana Version: 2.6.0+dfsg-3 Severity: grave Tags: security upstream Hi, The following vulnerability was published for grafana. CVE-2018-15727[0]: | Grafana 2.x, 3.x, and 4.x before 4.6.4 and 5.x before 5.2.3 allows | authentication bypass because an attacker can generate a valid | "remember me" cookie knowing only a username of an LDAP or OAuth user. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-15727 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15727 [1] https://grafana.com/blog/2018/08/29/grafana-5.2.3-and-4.6.4-released-with-important-security-fix/ Regards, Salvatore
Bug#906789: missing python3-pkg-resources dependency
Control: tag -1 patch Hi Navaneeth and Ana, On Tue, Aug 21, 2018 at 06:08:04AM +0200, navaneeth wrote: > Package: yapf3 > Version: 0.22.0-2 > > yapf3 should depend on python3-pkg-resources. Without that module, it > fails with a module not found error. I have filed a PR here to fix this bug: https://salsa.debian.org/python-team/modules/yapf/merge_requests/1 Cheers, Nicholas signature.asc Description: PGP signature
Bug#904755: closed by Ana Custura (Bug#904755: fixed in yapf 0.22.0-2)
Control: tag -1 patch Hi Adrian and Ana, On Mon, Aug 27, 2018 at 01:22:25PM +0300, Adrian Bunk wrote: > Control: reopen -1 > > On Sun, Aug 12, 2018 at 03:39:08PM +, Debian Bug Tracking System wrote: > >... > > yapf (0.22.0-2) unstable; urgency=medium > > . > >* debian/control: > >- adds missing dependency on python-pkg-resources (Closes: #904755) > >... > > This isn't fixed: > > Package: yapf > Version: 0.22.0-5 > Depends: python:any, python-yapf (= 0.22.0-5) > > Package: yapf > Version: 0.22.0-2 > Depends: python:any, python-yapf (= 0.22.0-2) I have filed a PR here to fix this bug: https://salsa.debian.org/python-team/modules/yapf/merge_requests/1 Cheers, Nicholas signature.asc Description: PGP signature
Bug#906568: closed by Mathieu Parent (Bug#906562: fixed in samba 2:4.8.4+dfsg-2)
Control: reopen -1 Control: severity -1 grave The following packages have unmet dependencies: samba-dsdb-modules : Depends: libldb1 (< 2:1.4.0+really1.3.6~) but 2:1.4.0+really1.3.6-1 is to be installed E: Unable to correct problems, you have held broken packages. Elimar -- From The Collaborative International Dictionary of English v.0.48 [gcide]: . arsehole \arse"hole`\ ([aum]rs"h[=o]l`), n. 1. execretory opening at the end of the alimentary canal.
Bug#906536: RFS: cavestory-nx/1.2.0-1 [ITP] -- Nostalgic side action adventure game
With the unclear license, this cannot proceed at the moment. Tagging accordingly.
Bug#888073: glibc: Support amd64 systems without /lib64
El dc 24 de 01 de 2018 a les 23:18 +0100, Aurelien Jarno va escriure: > Just right a new ABI document for > the x86-64 CPU and create a new architecture from it. Then this > architecture can be supported by Debian. Someone thinks that was a serious reply, so... I would like to write an ABI document for the x86-64 CPU and create a new architecture from it. Obviously, this is not as simple as writing a document in my computer or starting a repository on GitHub. Could you explain what this creation process actually means? Thank you. smime.p7s Description: S/MIME cryptographic signature
Bug#907589: asterisk crashes when using PJSIP while processing registrations
Package: asterisk Version: 1:13.14.1~dfsg-2+deb9u3 Severity: important Tags: upstream Dear Maintainer, I'm using Asterisk with its PJSIP backend. Every few hours Asterisk segfaults in PJSIP library code. According to backtraces of coredumps the segfaults seem to be related to SIP registration handling. I cannot say where the root cause is, so I'm reporting this against asterisk and not the PJSIP library. To work around this problem I'm currently using a self-built version of upstream Asterisk (built-in PJSIP). From this experience I can say, that upstream version 13.15.0 does NOT have the described problem (not a single segfault over months). However I would really like to use standard Debian stable packages, without self-built stuff. Details: Over the course of roughly 24h hours I recently got 13 segfaults. 6 of these segfaults occured in a function called tx_data_destroy() in libpjsip: #0 tx_data_destroy (tdata=) at ../src/pjsip/sip_transport.c:485 485 pjsip_endpt_release_pool( tdata->mgr->endpt, tdata->pool ); (gdb) bt #0 tx_data_destroy (tdata=) at ../src/pjsip/sip_transport.c:485 #1 0x7f686cb59cc8 in pjsip_tx_data_dec_ref (tdata=0x7f6814005748) at ../src/pjsip/sip_transport.c:501 #2 0x7f67b22b5740 in registration_response_destroy (obj=0x7f685c000dc0) at res_pjsip_outbound_registration.c:741 #3 0x55ac1cbe7f39 in internal_ao2_ref (user_data=user_data@entry=0x7f685c000dc0, delta=delta@entry=-1, file=file@entry=0x55ac1cd4e066 "astobj2.c", line=line@entry=518, func=func@entry=0x55ac1cd4e158 <__FUNCTION__.9326> "__ao2_ref") at astobj2.c:451 #4 0x55ac1cbe8528 in __ao2_ref (user_data=user_data@entry=0x7f685c000dc0, delta=delta@entry=-1) at astobj2.c:518 #5 0x7f67b22b6ffa in handle_registration_response (data=0x7f685c000dc0) at res_pjsip_outbound_registration.c:825 #6 0x55ac1cd290e8 in ast_taskprocessor_execute (tps=tps@entry=0x55ac1e968ff0) at taskprocessor.c:965 #7 0x55ac1cd310a0 in execute_tasks (data=0x55ac1e968ff0) at threadpool.c:1322 #8 0x55ac1cd290e8 in ast_taskprocessor_execute (tps=0x55ac1e39b2c0) at taskprocessor.c:965 #9 0x55ac1cd30a74 in threadpool_execute (pool=0x55ac1e39ae80) at threadpool.c:351 #10 worker_active (worker=0x7f67e0001a30) at threadpool.c:1105 #11 worker_start (arg=arg@entry=0x7f67e0001a30) at threadpool.c:1024 #12 0x55ac1cd3908c in dummy_start (data=) at utils.c:1235 #13 0x7f687358a494 in start_thread (arg=0x7f686e2ae700) at pthread_create.c:333 #14 0x7f6872194acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 (gdb) list 480 pj_lock_release(tdata->mgr->lock); 481 #endif 482 483 pj_atomic_destroy( tdata->ref_cnt ); 484 pj_lock_destroy( tdata->lock ); 485 pjsip_endpt_release_pool( tdata->mgr->endpt, tdata->pool ); 486 } (gdb) disassemble Dump of assembler code for function tx_data_destroy: 0x7f686cb59c20 <+0>: push %rbx 0x7f686cb59c21 <+1>: mov%rdi,%rbx 0x7f686cb59c24 <+4>: callq 0x7f686cb482d0 0x7f686cb59c29 <+9>: cmp$0x4,%eax 0x7f686cb59c2c <+12>:jle0x7f686cb59c4b 0x7f686cb59c2e <+14>:mov%rbx,%rdi 0x7f686cb59c31 <+17>:callq 0x7f686cb48c70 0x7f686cb59c36 <+22>:lea0x18(%rbx),%rdi 0x7f686cb59c3a <+26>:lea0x16701(%rip),%rsi# 0x7f686cb70342 0x7f686cb59c41 <+33>:mov%rax,%rdx 0x7f686cb59c44 <+36>:xor%eax,%eax 0x7f686cb59c46 <+38>:callq 0x7f686cb48100 0x7f686cb59c4b <+43>:lea0x3a8(%rbx),%rdi 0x7f686cb59c52 <+50>:callq 0x7f686cb48b10 0x7f686cb59c57 <+55>:mov0x1b0(%rbx),%rdi 0x7f686cb59c5e <+62>:callq 0x7f686cb48400 0x7f686cb59c63 <+67>:mov0x180(%rbx),%rdi 0x7f686cb59c6a <+74>:callq 0x7f686cb48870 0x7f686cb59c6f <+79>:mov0x50(%rbx),%rax 0x7f686cb59c73 <+83>:mov0x10(%rbx),%rsi 0x7f686cb59c77 <+87>:pop%rbx => 0x7f686cb59c78 <+88>:mov0x10(%rax),%rdi 0x7f686cb59c7c <+92>:jmpq 0x7f686cb48be0 End of assembler dump. (gdb) up #1 0x7f686cb59cc8 in pjsip_tx_data_dec_ref (tdata=0x7f6814005748) at ../src/pjsip/sip_transport.c:501 501 tx_data_destroy(tdata); (gdb) print tdata $1 = (pjsip_tx_data *) 0x7f6814005748 (gdb) print tdata->pool $2 = (pj_pool_t *) 0x7f6814005645 (gdb) print tdata->mgr $3 = (pjsip_tpmgr *) 0x554b43415250 (gdb) print tdata->mgr->endpt Cannot access memory at address 0x554b43415260 It seems like the endpoint struct is gone? But why? Broken pointer? Already free'ed? Here are the other types of segfaults, which I haven't had a closer look at yet: 2 segfaults occured in function pj_atomic_inc_and_get() in libpj: (gdb) bt #0 0x7fce2dcd4999 in pj_atomic_inc_and_get () from /usr/lib/x86_64-linux-gnu/libpj.so.2 #1 0x7fcdb878e5a3 in sip_outbound_registration_response_cb
Bug#907588: miniupnpd: [INTL:de] Updated German debconf translation
Package: miniupnpd Version: 12.0.2-9 Severity: wishlist Tags: l10n patch Hi, please find attached the newest version of the German deconf translation. Kind regards, Chris de.po.gz Description: application/gzip
Bug#907559: cgview: Does not start
Control: forwarded -1 https://issues.apache.org/jira/browse/BATIK-1239 On Wed, Aug 29, 2018 at 08:23:38PM +0200, Markus Koschany wrote: > > Wouldn't it help more if I simply try to package batik-constants? > > I thought it would be more likely to get a more precise answer from them > because they certainly know their code best. I am not even sure if > batik-constants is a long term solution or if they want to change that > again in the future. Depending on the cgview code it may have been > possible to patch the sources and make them compatible with Batik 1.10 > without packaging batik-constants. If this all sounds too far-fetched, > then packaging batik-constants is the way to go. Thanks for your insight. I have opened an upstream bug report[1] (no idea how to contact upstream otherwise). Kind regards Andreas. [1] https://issues.apache.org/jira/browse/BATIK-1239 -- http://fam-tille.de
Bug#905986: cups-tea4cups: TEABILLING reports error
Hi Brian, simple answer, I'm traveling and I am away from the system. Will followup, when I am back home. Rainer Am 29. August 2018 20:34:43 MESZ schrieb Brian Potkin : >On Fri 24 Aug 2018 at 13:08:51 +0100, Brian Potkin wrote: > >> On Thu 23 Aug 2018 at 16:47:14 +0200, Rainer Dorsch wrote: > >> > can you post a link? >> >> I should have been a bit more helpful initially: >> >> >https://wiki.debian.org/DissectingandDebuggingtheCUPSPrintingSystem#The_CUPS_Error_Log >> >> Basically - empty the error_log and print. I suggest that you print >as I >> described in my previous mail to test the wrapping function. That is, >no >> hooks used. The data would still be useful to have. > >The reluctance to provide extra easily obtainable information to >advance >investigation of this bug is puzzling. Still awaiting. > >-- >Brian.
Bug#907451: libbiod FTBFS: Error: cannot implicitly convert expression
Am Mi., 29. Aug. 2018 um 19:56 Uhr schrieb Andreas Tille : > > Hi Matthias, > On Tue, Aug 28, 2018 at 03:39:56PM +0200, Matthias Klumpp wrote: > > > > ... > > > > [30/149] ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d > > > > -enable-color -O -g -release -wi -relocation-model=pic -of > > > > 'biod@sha/bio_maf_reader.d.o' -c ../bio/maf/reader.d > > > > FAILED: biod@sha/bio_maf_reader.d.o > > > > ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color -O -g > > > > -release -wi -relocation-model=pic -of 'biod@sha/bio_maf_reader.d.o' > > > > -c ../bio/maf/reader.d > > > > ../bio/maf/reader.d(40): Deprecation: struct > > > > `std.stdio.File.ByLine!(char, char).ByLine` is deprecated - Use .byLine > > > > ../bio/maf/reader.d(53): Error: cannot implicitly convert expression > > > > `this._f.byLine(cast(Flag)true, '\x0a')` of type `ByLineImpl!(char, > > > > char)` to `ByLine!(char, char)` > > > > ../bio/maf/reader.d(53):`this._lines = > > > > this._f.byLine(cast(Flag)true, '\x0a')` is the first assignment of > > > > `this._lines` therefore it represents its initialization > > > > ../bio/maf/reader.d(53):`opAssign` methods are not used for > > > > initialization, but for subsequent assignments > > > > [ > > > > Looks like an upstream issue - have you filed a bug there already? > > Upstream code das not changed since first release in Debian (Sat, 04 Mar > 2017) I have no idea what kind of bug I should file. :-( As I wrote before: Am Mi., 29. Aug. 2018 um 16:08 Uhr schrieb Matthias Klumpp : > [...] > You don't even need to file a bug - looks like upstream fixed this > already in > https://github.com/biod/BioD/commit/dd07f3497979b5d7f32ad32476da5108ffc5121e, > so all you need to do is take that patch.
Bug#907583: php7.0-json: The file /usr/share/php/Services/JSON.php triggers PHP deprecation warnings, file /usr/share/php/Services/JSON.php
Control: reassign -1 php-services-json The file belongs to php-services-json package. Ondrej -- Ondřej Surý ond...@sury.org > On 29 Aug 2018, at 20:49, Georges Khaznadar wrote: > > Package: php7.0-json > Version: 7.0.29-1+b2 > Severity: normal > > Dear Maintainer, > > When upgrading one server from PHP5 to PHP7.0, and fixing problems > which this could create, I found that one of the services throwed > lots of warnings like: > "Methods with the same name as their class will not be constructors in a > future > version of PHP" > > The fix (which I applied successfully by hand), is to use the functions > "__construct()" as per > the documentation of PHP: http://www.php.net/manual/en/language.oop5.decon.php > > The version of PHP7.0 on the server touched by the bug is currently the last > one, > 7.0.31-1 > > Unfortunately, I could not figure out easily how the faulty file, > /usr/share/php/Services/JSON.php > is created by the build process, so I do not know how to make a useful patch > to > fix this issue. > > Best regards, Georges. > > > > -- Package-specific info: > Additional PHP 7.0 information > > PHP @PHP_VERSION SAPI (php7.0query -S): > > PHP 7.0 Extensions (php7.0query -M -v): > > Configuration files: > /etc/php/7.0/mods-available/json.ini > extension=json.so > > > -- System Information: > Debian Release: buster/sid > APT prefers stable > APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.16.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) > LSM: AppArmor: enabled > > Versions of packages php7.0-json depends on: > ii libc6 2.27-5 > ii php-common 1:61 > ii php7.0-common 7.0.29-1+b2 > ii ucf3.0038 > > php7.0-json recommends no packages. > > php7.0-json suggests no packages. > > Versions of packages php7.0-common depends on: > ii libc6 2.27-5 > ii libssl1.1 1.1.0h-4 > ii php-common 1:61 > ii ucf 3.0038 > > Versions of packages php7.0-cli depends on: > ii libc62.27-5 > ii libedit2 3.1-20180525-1 > ii libmagic11:5.33-3 > ii libpcre3 2:8.39-9 > ii libssl1.11.1.0h-4 > ii libxml2 2.9.4+dfsg1-7+b1 > ii mime-support 3.61 > ii php7.0-common7.0.29-1+b2 > ii php7.0-opcache 7.0.29-1+b2 > ii php7.0-readline 7.0.29-1+b2 > ii tzdata 2018e-1 > ii ucf 3.0038 > ii zlib1g 1:1.2.11.dfsg-1 > > Versions of packages php7.0-cli suggests: > ii php-pear 1:1.10.5+submodules+notgz-1 > > Versions of packages php7.0-fpm depends on: > ii libapparmor12.13-8 > ii libc6 2.27-5 > ii libmagic1 1:5.33-3 > ii libpcre32:8.39-9 > ii libssl1.1 1.1.0h-4 > ii libsystemd0 239-7 > ii libxml2 2.9.4+dfsg1-7+b1 > ii mime-support3.61 > ii php7.0-cli 7.0.29-1+b2 > ii php7.0-common 7.0.29-1+b2 > ii php7.0-opcache 7.0.29-1+b2 > ii procps 2:3.3.15-2 > ii tzdata 2018e-1 > ii ucf 3.0038 > ii zlib1g 1:1.2.11.dfsg-1 > > Versions of packages php7.0-fpm suggests: > ii php-pear 1:1.10.5+submodules+notgz-1 > > -- no debconf information >
Bug#907581: linux-image-4.9.0-8-amd64: off-by-one bug in L1TF mitigation
This issue is further addressed by: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent&id=cc51e5428ea54f575d49cfcede1d4cb3a72b4ec4 by increasing the memory limit for the mitigation on pretty much all desktop, mobile and Xeon E3 systems since Nehalem. Best regards, Markus
Bug#907586: g++ compiler problem on hppa
Package: g++-8 Version: 8.2.0-4 Severity: important One of the packages I maintain have been failing in its test suite on hppa ever since it was first uploaded. I was never able to investigate the reason for this because there until recently were no hppa porter box. I recently discovered that there is now an hppa porter box and I have been able to reproduce the issue. I managed to take the failing part of the code and reduce it to a small test case that is attached to this bug report. The issue only happens on hppa, and only when linking using a shared library. If the test case is linked statically the issue does not appear. On all architectures except hppa the output of the test case is the following: $ make g++ -O2 -g -c -o main.o main.cpp g++ -O2 -g -fPIC -c -o S.o S.cpp g++ -shared -o libS.so S.o g++ -o main main.o -L. -lS g++ -o altmain main.o S.o -- Running using shared library LD_LIBRARY_PATH=. ./main OK -- Running using static build ./altmain OK On hppa the output is as follows: $ make g++ -O2 -g -c -o main.o main.cpp g++ -O2 -g -fPIC -c -o S.o S.cpp g++ -shared -o libS.so S.o g++ -o main main.o -L. -lS g++ -o altmain main.o S.o -- Running using shared library LD_LIBRARY_PATH=. ./main not OK -- Running using static build ./altmain OK Mattias test.tar.gz Description: application/compressed-tar smime.p7s Description: S/MIME cryptographic signature
Bug#907587: git breaks dulwich autopkgtest: ValueError: invalid literal for int() with base 16: 'Stat'
Source: git, dulwich
Control: found -1 git/1:2.19.0~rc1-1
Control: found -1 dulwich/0.19.6-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainers,
With a recent upload of git the autopkgtest of dulwich started to fail
in testing and unstable. I copied the output below.
Currently this regression is contributing to the delay of the migration
of git to testing [1]. Due to the nature of this issue, I filed this bug
against both packages. Could you please investigate the situation and
reassign the bug to the right package? If needed, please change the
bug's severity as appropriate.
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=git
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dulwich/900121/log.gz
autopkgtest [03:14:04]: test testsuite2: [---
...s..s.ss.s.s.s.s.s.s.sss..s..s..s.s..sss..ss.sss.sssss
==
ERROR: test_fetch_pack
(dulwich.tests.compat.test_client.DulwichHttpClientTest)
--
Traceback (most recent call last):
File "dulwich/tests/compat/test_client.py", line 208, in test_fetch_pack
result = c.fetch(self._build_path('/server_new.export'), dest)
File "dulwich/client.py", line 364, in fetch
progress)
File "dulwich/client.py", line 1544, in fetch_pack
b"git-upload-pack", url)
File "dulwich/client.py", line 1456, in _discover_references
return read_pkt_refs(proto) + (base_url, )
File "dulwich/client.py", line 196, in read_pkt_refs
for pkt in proto.read_pkt_seq():
File "dulwich/protocol.py", line 254, in read_pkt_seq
pkt = self.read_pkt_line()
File "dulwich/protocol.py", line 203, in read_pkt_line
size = int(sizestr, 16)
ValueError: invalid literal for int() with base 16: 'Stat'
==
ERROR: test_fetch_pack_no_side_band_64k
(dulwich.tests.compat.test_client.DulwichHttpClientTest)
--
Traceback (most recent call last):
File "dulwich/tests/compat/test_client.py", line 241, in
test_fetch_pack_no_side_band_64k
result = c.fetch(self._build_path('/server_new.export'), dest)
File "dulwich/client.py", line 364, in fetch
progress)
File "dulwich/client.py", line 1544, in fetch_pack
b"git-upload-pack", url)
File "dulwich/client.py", line 1456, in _discover_references
return read_pkt_refs(proto) + (base_url, )
File "dulwich/client.py", line 196, in read_pkt_refs
for pkt in proto.read_pkt_seq():
File "dulwich/protocol.py", line 254, in read_pkt_seq
pkt = self.read_pkt_line()
File "dulwich/protocol.py", line 203, in read_pkt_line
size = int(sizestr, 16)
ValueError: invalid literal for int() with base 16: 'Stat'
==
ERROR: test_fetch_pack_zero_sha
(dulwich.tests.compat.test_client.DulwichHttpClientTest)
--
Traceback (most recent call last):
File "dulwich/tests/compat/test_client.py", line 253, in
test_fetch_pack_zero_sha
lambda refs: [protocol.ZERO_SHA])
File "dulwich/client.py", line 364, in fetch
progress)
File "dulwich/client.py", line 1544, in fetch_pack
b"git-upload-pack", url)
File "dulwich/client.py", line 1456, in _discover_references
return read_pkt_refs(proto) + (base_url, )
File "dulwich/client.py", line 196, in read_pkt_refs
for pkt in proto.read_pkt_seq():
F
Bug#907489: sambamba FTBFS
Control: forwarded -1 https://github.com/biod/sambamba/issues/362 Control: tags -1 upstream On Wed, Aug 29, 2018 at 04:14:48PM +0200, Matthias Klumpp wrote: > > This appears to be a different issue to me - this one is a bit weirder > than the BioD one. You can either apply the BioD patch and see if that > fixes the problem, It does not unfortunately. > or directly report it upstream. This does not look > Debian-specific at all, it rather looks like a generic upstream issue > that happened because we are currently in a transition to a more > recent compiler in Debian. I reported issue #362. Thanks a lot for your help Andreas. -- http://fam-tille.de
Bug#907585: Contains Linux kernel iamge with source not provided
Package: firmware-cavium Version: 20180518-1 Severity: serious Tags: upstream It was reported upstream that the file liquidio/lio_23xx_vsw.bin contains a Linux kernel image, but without the proper licence text or source code accompanying it in this repository. Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-cavium depends on no packages. firmware-cavium recommends no packages. Versions of packages firmware-cavium suggests: ii initramfs-tools 0.133~1.gbp3490d3
Bug#907583: php7.0-json: The file /usr/share/php/Services/JSON.php triggers PHP deprecation warnings, file /usr/share/php/Services/JSON.php
Package: php7.0-json Version: 7.0.29-1+b2 Severity: normal Dear Maintainer, When upgrading one server from PHP5 to PHP7.0, and fixing problems which this could create, I found that one of the services throwed lots of warnings like: "Methods with the same name as their class will not be constructors in a future version of PHP" The fix (which I applied successfully by hand), is to use the functions "__construct()" as per the documentation of PHP: http://www.php.net/manual/en/language.oop5.decon.php The version of PHP7.0 on the server touched by the bug is currently the last one, 7.0.31-1 Unfortunately, I could not figure out easily how the faulty file, /usr/share/php/Services/JSON.php is created by the build process, so I do not know how to make a useful patch to fix this issue. Best regards, Georges. -- Package-specific info: Additional PHP 7.0 information PHP @PHP_VERSION SAPI (php7.0query -S): PHP 7.0 Extensions (php7.0query -M -v): Configuration files: /etc/php/7.0/mods-available/json.ini extension=json.so -- System Information: Debian Release: buster/sid APT prefers stable APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.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) LSM: AppArmor: enabled Versions of packages php7.0-json depends on: ii libc6 2.27-5 ii php-common 1:61 ii php7.0-common 7.0.29-1+b2 ii ucf3.0038 php7.0-json recommends no packages. php7.0-json suggests no packages. Versions of packages php7.0-common depends on: ii libc6 2.27-5 ii libssl1.1 1.1.0h-4 ii php-common 1:61 ii ucf 3.0038 Versions of packages php7.0-cli depends on: ii libc62.27-5 ii libedit2 3.1-20180525-1 ii libmagic11:5.33-3 ii libpcre3 2:8.39-9 ii libssl1.11.1.0h-4 ii libxml2 2.9.4+dfsg1-7+b1 ii mime-support 3.61 ii php7.0-common7.0.29-1+b2 ii php7.0-opcache 7.0.29-1+b2 ii php7.0-readline 7.0.29-1+b2 ii tzdata 2018e-1 ii ucf 3.0038 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages php7.0-cli suggests: ii php-pear 1:1.10.5+submodules+notgz-1 Versions of packages php7.0-fpm depends on: ii libapparmor12.13-8 ii libc6 2.27-5 ii libmagic1 1:5.33-3 ii libpcre32:8.39-9 ii libssl1.1 1.1.0h-4 ii libsystemd0 239-7 ii libxml2 2.9.4+dfsg1-7+b1 ii mime-support3.61 ii php7.0-cli 7.0.29-1+b2 ii php7.0-common 7.0.29-1+b2 ii php7.0-opcache 7.0.29-1+b2 ii procps 2:3.3.15-2 ii tzdata 2018e-1 ii ucf 3.0038 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages php7.0-fpm suggests: ii php-pear 1:1.10.5+submodules+notgz-1 -- no debconf information
Bug#907582: fontmake: please package a new upstream release
Package: fontmake Version: 1.4.0-2 Severity: normal Control: block 900778 by -1 Hi there, some days ago fontmake 1.7.2 has been released. As it seems, a recent fontmake version >= 1.5.1 is required to rebuilt fonts-comicneue from source, thus this package being outdated prevents the other package's migration from the contrib section to main. Please package a new fontmake version and its dependencies for Debian. Thanks! - Fabian -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-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 fontmake depends on: ii python3 3.6.5-3 ii python3-fontmake 1.4.0-2 fontmake recommends no packages. fontmake suggests no packages. -- no debconf information
Bug#903543: raspi3-firmware: [PATCH] add configuration options for cmdline.txt
tags 903543 + pending kthxbye Fixed in the working tree, will be part of the next firmware upload (which should be soonish, as a new version was recently made available)
Bug#907581: linux-image-4.9.0-8-amd64: off-by-one bug in L1TF mitigation
Package: src:linux Version: 4.9.110-3+deb9u4 Severity: important Tags: patch Dear Maintainer, due to an off-by-one bug in the L1TF patch, the "rare" case of systems still vulnerable is more frequent. Originally this was reported in OpenSUSE, but I can confirm this is also true with the latest Debian kernel. Please cherry-pick the following upstream patch to resolve this issue: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=b0a182f875689647b014bc01d36b340217792852 Best regards, Markus
Bug#698504: system-config-printer: permission problem
Dear Maintainer, While the wish for an upstream solution is understandable, we do not live in an ideal world and it would be desireable to take action now. Could you please carry the ubuntu patch as outlined in https://bugs.launchpad.net/ubuntu/+source/cups-pk-helper/+bug/934291 This package does not require much maintenance work anyway so imho it can't be justified to not carry a patch that fixes broken functionality. Thanks very much!
Bug#905986: cups-tea4cups: TEABILLING reports error
On Fri 24 Aug 2018 at 13:08:51 +0100, Brian Potkin wrote: > On Thu 23 Aug 2018 at 16:47:14 +0200, Rainer Dorsch wrote: > > can you post a link? > > I should have been a bit more helpful initially: > > https://wiki.debian.org/DissectingandDebuggingtheCUPSPrintingSystem#The_CUPS_Error_Log > > Basically - empty the error_log and print. I suggest that you print as I > described in my previous mail to test the wrapping function. That is, no > hooks used. The data would still be useful to have. The reluctance to provide extra easily obtainable information to advance investigation of this bug is puzzling. Still awaiting. -- Brian.
Bug#907400: kopano-server: Kopano server apparmor issues
Control: tags -1 pending Hello Teun, On Mon, Aug 27, 2018 at 02:58:28PM +, Teun Kloosterman wrote: > > When trying out kopano server, I saw errors for the following files in syslog. > Adding the following lines to /etc/apparmor.d/usr.sbin.kopano-server made it > work: > > /etc/kopano/ldap.cfg r, > /etc/kopano/ldap.openldap.cfg r, > /etc/kopano/ldap.propmap.cfg r, > /etc/ldap/ldap.conf r, > /etc/ssl/openssl.cnf r, good catch, I added your proposed lines into the preparations for the next upload. Regards Carsten
Bug#907580: aide: lintian warning autotools-pkg-config-macro-not-cross-compilation-safe
Package: aide Version: 0.16-4 Severity: wishlist Tags: upstream Hi, Lintian complains: N:The package appears to use AC_PATH_PROG to discover the location of N:pkg-config(1). This macro fails to select the correct version to support N:cross-compilation. N: N:A better way would be to use the PKG_PROG_PKG_CONFIG macro from pkg.m4 N:and then using the $PKG_CONFIG shell variable. N: N:Refer to https://bugs.debian.org/884798 for details. N: N:Severity: normal, Certainty: possible N: N:Check: cruft, Type: source The referenced #884798 explains how to fix this. This is an upstream issue, Hannes, your call ;-) Greetings Marc
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Control: tags -1 moreinfo Hi, On 29-08-18 20:20, Jonas Smedegaard wrote: > Thanks - that is indeed helpful, but provides only the _cups_ commands. > > Inside those are some Ghostscript command (and some data) which I would > need to check if/what fails with Ghostscript. Both of them are "ELF 64-bit LSB shared object" so it would help if the cups maintainers could help here. Paul signature.asc Description: OpenPGP digital signature
Bug#907578: lintian: vcs-deprecated-in-debian-infrastructure description outdated
tags 907578 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/8c2eb28c5913fc93d300a206d8d591c296a8bb98 checks/fields.desc | 8 checks/fields.pm | 2 +- debian/changelog | 4 t/tests/fields-malformed-vcs-fields/tags | 4 ++-- t/tests/fields-uncanonical-vcs-fields/tags | 10 +- t/tests/fields-vcs-deprecated-in-debian-infrastructure/tags| 3 --- t/tests/fields-vcs-fields/tags | 10 +- .../debian/debian/control.in | 0 .../desc | 4 ++-- .../tags | 0 .../debian/debian/control.in | 0 .../desc | 4 ++-- t/tests/fields-vcs-obsolete-in-debian-infrastructure/tags | 3 +++ 13 files changed, 28 insertions(+), 24 deletions(-) (I did not raise the severity as I'm not 100% sure it's warranted.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#907559: cgview: Does not start
Am 29.08.2018 um 19:31 schrieb Andreas Tille: [...] >> Maybe you should raise this issue with upstream (Batik and/or cgview) > > Well cgview is not actively maintained (but has quite a number of users) > and what exactly should I say to Batik upstream if they decided to move > it to a noew project? I admit I have no idea what to say and where to > report. > > Wouldn't it help more if I simply try to package batik-constants? I thought it would be more likely to get a more precise answer from them because they certainly know their code best. I am not even sure if batik-constants is a long term solution or if they want to change that again in the future. Depending on the cgview code it may have been possible to patch the sources and make them compatible with Batik 1.10 without packaging batik-constants. If this all sounds too far-fetched, then packaging batik-constants is the way to go. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Quoting Paul Gevers (2018-08-29 19:58:37) > Control: tags -1 - moreinfo > > On Wed, 29 Aug 2018 09:41:37 +0200 Jonas Smedegaard wrote: > > It would be most helpful if someone could dig out from that convoluted > > ci-in-cups test the actual ghostscript command causing cups to hang. > > Looking here: > https://sources.debian.org/src/cups/2.2.8-5/debian/tests/cups/ > > it runs: > /usr/share/cups/test-drivers > > As the log ends with: > * Driver drv:///sample.drv/dymo.ppd > - Create test printer: done. > - Print test job with /usr/share/cups/data/topsecret.pdf: > > I guess it successfully runs this command > /usr/sbin/lpadmin -p $DUMMY_PRINTER_NAME -E -m $driver -v > file:///dev/null > and fails with this command: > rid=$(/usr/bin/lp -d $DUMMY_PRINTER_NAME $file | sed -e > 's/^.*request id is \(.*\) (.*)$/\1/g') > > where > DUMMY_PRINTER_NAME=test-printer0 > driver=drv:///sample.drv/dymo.ppd > file=/usr/share/cups/data/topsecret.pdf > > Is that enough for you to continue? Thanks - that is indeed helpful, but provides only the _cups_ commands. Inside those are some Ghostscript command (and some data) which I would need to check if/what fails with Ghostscript. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#904428: linux-image-4.17.0-1-amd64: sound pops/clicks with snd_hda_intel unless power saving is disabled
Hi, See: 1. https://bugzilla.kernel.org/show_bug.cgi?id=200687 and 2. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/pci/hda/hda_intel.c?id=38d9c12c0a6d41a82fb6d1278d430bbf35301ce5 as Hans de Goede said, this does not seems to be fixed in 4.17.x but it is part of 4.18.x . Could you test with 4.18.5-1~exp1 present in experimental ? If you don't know how to do this, feel free to ask, I can provide feedback. Thanks, Romain On Tue, Jul 24, 2018 at 10:32:26AM +0200, Gard Spreemann wrote: > Package: src:linux > Version: 4.17.8-1 > Severity: important > Tags: upstream > > Dear Maintainer, > > After upgrading from linux-image-4.16.0-2-amd64 to > linux-image-4.17.0-1-amd64, my computer's sound card exhibits an > audible and annoying pop or click when an audio stream is about to > play or stop playing. The pop/click was not present with earlier > kernels. > > Turning off power saving with > > options snd_hda_intel power_save=0 power_save_controller=N > > as per Redhat bug 1525104 [1] works around the problem (no pop/click). > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1525104 > > > -- Package-specific info: > ** Version: > Linux version 4.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version > 7.3.0 (Debian 7.3.0-26)) #1 SMP Debian 4.17.8-1 (2018-07-20) > > ** Command line: > BOOT_IMAGE=/boot/vmlinuz-4.17.0-1-amd64 > root=UUID=546f4738-0d40-4e33-b17a-29b58fe436dd ro > > ** Not tainted
Bug#683957: aide: Squeeze rules update
tags #683957 patch confirmed pending thanks Hi, I have to apologize again and I do fully understand that you have lost interest in having your code in the package after I ignored your contribution for five years. To make at least limited use of it, I have committed a few of your fixes - the ones that I can be sure of that they don't introduce regressions and that still apply to today's Debian. This bug will be closed with the next upload, despite the majority of the contributions not being taken. This is entirely my fault, and I apologize again. Please consider filing your ideas again, maybe as gitlab pull requests in salsa? If you do, please consider filing multiple issues with smaller patches, this is considerably easier to process for the package maintainer, especially when there are comments and questions. Thanks for your contribution, and please accept my apologies. Greetings Marc
Bug#824712: RFH: smokeping
On 2018-08-29 11:06:52, Gabriel Filion wrote: > Hi there! > > I've been doing some work on the smokeping package in the past few > weeks/months with anarcat. Yeah, and thank you for that! :) > Namely, > > * a new upstream release was packaged and sent to experimental, and > we're trying to get it into sid very soon. Actually, it was uploaded to sid three days ago, so if all goes well it should be in buster by the end of week. > * I've written and submitted a patch upstream in response to a bug > report in the BTS to make smokeping work better with newer versions of > FPing (3.16+). It should make it so that the FPing probes doen't mix up > IPv4 and IPv6 anymore with the recent versions of fping. This should > land in a package real soon (it was merged upstream today) This is already in 2.7.2-2, if i recall correctly, see also #905752. > Future work that I intend to do is to get rid of as many lintian errors > as possible, and then start working on the currently present bug reports > in the BTS (from the easiest first). Awesome! Note that some of those bug reports cover rather special corner cases you might not have or might find difficult to deploy, namely master/slave setups or using Smokeping as a more generic monitoring system (à la Nagios, say). My approach, thus far, with the package, has been to fix the stuff I use and accept patches for the rest, but not necessarily go crazy in trying to fix the more exotic use cases. > It is an invaluable learning experience for me since I'm new to debian > packaging. I hope you find this useful! :) [...] Cheers! A. -- It is the greatest of all mistakes to do nothing because you can only do little. Do what you can. - Sydney Smith
Bug#907579: mlocate: Please update updatedb.conf with more network and special filesystems
Package: mlocate Version: 0.26-2 Severity: normal Tags: patch The current updatedb.conf lacks many network and special filesystems. Some of them can be very big or probably useless to index. My suggested and sorted list is: PRUNEFS="afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fusectl fuse.glusterfs fuse.gvfsd-fuse fuse.mfs fuse.rozofs fusesmb fuse.sshfs hugetlbfs iso9660 lustre lustre_lite mfs mqueue ncpfs nfs NFS nfs4 ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs sysfs tmpfs tracefs udev udf usbfs" Kind regards Jose M Calhariz -- System Information: Debian Release: 9.5 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/12 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: systemd (via /run/systemd/system) Versions of packages mlocate depends on: ii adduser 3.115 ii libc62.24-11+deb9u3 mlocate recommends no packages. mlocate suggests no packages. -- no debconf information
Bug#824712: RFH: smokeping
On 2016-05-19 13:27:00, Antoine Beaupré wrote: > On 2016-05-19 10:21:21, Iain R. Learmonth wrote: >> Hi, >> >> On 19/05/16 13:33, Antoine Beaupré wrote: >>> Hmm... I'm hesitant in joining yet another team here, too much mail. :) >> >> By joining the team, I mainly meant giving you VCS commit access. If >> you're not using the package much anymore then I probably wouldn't >> expect you to be tracking the package too closely, but as you've >> previously maintained it I might want to ask you questions and allow you >> the ability to commit fixes for anything I'm not understanding. > > I'm fine with that! > >>> But i'd be happy to share maintenance or even delegate responsability >>> completely if people are up to it. >> >> Does this sound acceptable? > > All of the above is, feel free to move to shared maintenance and give me > access, it sounds like a great solution. > > Thanks for the fast response! By the way, was there any followup on this? I haven't talked with LeLutin, but I'm sure the extra help wouldn't be refused. :) A. -- I believe that love is a better teacher than a sense of duty. - Albert Einstein
Bug#907578: lintian: vcs-deprecated-in-debian-infrastructure description outdated
package: lintian version: 2.5.98 Hi, The description for vcs-deprecated-in-debian-infrastructure says "...the Alioth service will become read-only in May 2018." This date has passed, so this info is outdated and should be updated. Maybe the tag should be renamed from 'deprecated' to 'obsolete' (or something like that), because the repositories are no longer available at the specified location. Also, the severity should probably be increased. Cheers, Ivo
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Control: tags -1 - moreinfo On Wed, 29 Aug 2018 09:41:37 +0200 Jonas Smedegaard wrote: > It would be most helpful if someone could dig out from that convoluted > ci-in-cups test the actual ghostscript command causing cups to hang. Looking here: https://sources.debian.org/src/cups/2.2.8-5/debian/tests/cups/ it runs: /usr/share/cups/test-drivers As the log ends with: * Driver drv:///sample.drv/dymo.ppd - Create test printer: done. - Print test job with /usr/share/cups/data/topsecret.pdf: I guess it successfully runs this command /usr/sbin/lpadmin -p $DUMMY_PRINTER_NAME -E -m $driver -v file:///dev/null and fails with this command: rid=$(/usr/bin/lp -d $DUMMY_PRINTER_NAME $file | sed -e 's/^.*request id is \(.*\) (.*)$/\1/g') where DUMMY_PRINTER_NAME=test-printer0 driver=drv:///sample.drv/dymo.ppd file=/usr/share/cups/data/topsecret.pdf Is that enough for you to continue? Paul signature.asc Description: OpenPGP digital signature
Bug#907577: RM: redisearch -- RoM; upstream relicensed to non-DFSG-free "Commons Clause" variant
Package: ftp.debian.org Severity: normal In: https://salsa.debian.org/lamby/pkg-redisearch/commit/63abb214df23ce9f78ea71b6186ac34cce0c3a12#8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_79_77 … redisearch was relicensed from AGPL to "Apache 2.0 with Commons Clause", which violates DFSG §6: https://lists.debian.org/debian-devel/2018/08/msg00319.html This is being tracked in: https://bugs.debian.org/906920 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#907576: ITP: dream --A Software Digital Radio Mondiale (DRM) receiver (RFP 691685)
Package: dream --A Software Digital Radio Mondiale (DRM) receiver (RFP 691685) ITP: dream --A Software Digital Radio Mondiale (DRM) receiver Request for ITP. I will attempt to to package Dream as requested by RFP 691685. This is my first Debian package. I lack the necessary radio receiver to test Dream on air. May someone volunteer to do so? We may need to extend Dream to PulseAudio. Garie Miller -- Take back your privacy. Switch to www.StartMail.com
Bug#883181: linux-image-4.9.0-4-amd64: Default stretch kernel raises cgroup strack traces under high load
Hi, The last linux kernel in stretch being 4.9.110, could you re-test with this kernel please ? Thanks, Regards, Romain On Thu, Nov 30, 2017 at 11:54:00AM +, Tom Stocker wrote: > Package: src:linux > Version: 4.9.51-1 > Severity: serious > Justification: Policy 2.2.1 > > > > -- Package-specific info: > ** Version: > Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version > 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28) > > ** Command line: > BOOT_IMAGE=/boot/vmlinuz-4.9.0-4-amd64 > root=/dev/mapper/de--bln--vm--017--vg-root ro quiet > > ** Not tainted > > ** Kernel log: > [1.533757] EXT4-fs (dm-1): mounted filesystem with ordered data mode. > Opts: (null) > [1.847797] ip_tables: (C) 2000-2006 Netfilter Core Team > [1.912833] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT > +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS > +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) > [1.912859] systemd[1]: Detected virtualization vmware. > [1.912863] systemd[1]: Detected architecture x86-64. > [1.914546] systemd[1]: Set hostname to . > [2.058639] random: crng init done > [2.131752] systemd[1]: Set up automount Arbitrary Executable File Formats > File System Automount Point. > [2.131812] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. > [2.131843] systemd[1]: Listening on Syslog Socket. > [2.131885] systemd[1]: Started Forward Password Requests to Wall > Directory Watch. > [2.131920] systemd[1]: Listening on udev Control Socket. > [2.131955] systemd[1]: Started Dispatch Password Requests to Console > Directory Watch. > [2.363268] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro > [2.516531] systemd-journald[833]: Received request to flush runtime > journal from PID 1 > [2.819683] input: Power Button as > /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4 > [2.819691] ACPI: Power Button [PWRF] > [2.819819] ACPI: AC Adapter [ACAD] (on-line) > [2.875315] input: PC Speaker as /devices/platform/pcspkr/input/input5 > [2.881700] vmw_vmci :00:07.7: Found VMCI PCI device at 0x11080, irq 16 > [2.881767] vmw_vmci :00:07.7: Using capabilities 0xc > [2.882410] Guest personality initialized and is active > [2.882410] VMCI host device registered (name=vmci, major=10, minor=58) > [2.882410] Initialized host personality > [2.930410] [drm] Initialized > [2.941291] sd 0:0:0:0: Attached scsi generic sg0 type 0 > [2.941374] sd 0:0:1:0: Attached scsi generic sg1 type 0 > [2.941446] sd 0:0:2:0: Attached scsi generic sg2 type 0 > [2.941516] sd 0:0:3:0: Attached scsi generic sg3 type 0 > [2.941562] sr 2:0:0:0: Attached scsi generic sg4 type 5 > [3.012775] [drm] DMA map mode: Using physical TTM page addresses. > [3.012868] [drm] Capabilities: > [3.012873] [drm] Rect copy. > [3.012874] [drm] Cursor. > [3.012875] [drm] Cursor bypass. > [3.012876] [drm] Cursor bypass 2. > [3.012877] [drm] 8bit emulation. > [3.012878] [drm] Alpha cursor. > [3.012879] [drm] Extended Fifo. > [3.012880] [drm] Multimon. > [3.012881] [drm] Pitchlock. > [3.012882] [drm] Irq mask. > [3.012883] [drm] Display Topology. > [3.012884] [drm] GMR. > [3.012885] [drm] Traces. > [3.012886] [drm] GMR2. > [3.012887] [drm] Screen Object 2. > [3.012888] [drm] Command Buffers. > [3.012889] [drm] Command Buffers 2. > [3.012890] [drm] Guest Backed Resources. > [3.012891] [drm] DX Features. > [3.012893] [drm] Max GMR ids is 64 > [3.012894] [drm] Max number of GMR pages is 65536 > [3.012895] [drm] Max dedicated hypervisor surface memory is 0 kiB > [3.012896] [drm] Maximum display memory size is 4096 kiB > [3.012898] [drm] VRAM at 0xe800 size is 4096 kiB > [3.012899] [drm] MMIO at 0xfe00 size is 256 kiB > [3.012901] [drm] global init. > [3.013022] [TTM] Zone kernel: Available graphics memory: 60855752 kiB > [3.013023] [TTM] Zone dma32: Available graphics memory: 2097152 kiB > [3.013024] [TTM] Initializing pool allocator > [3.013029] [TTM] Initializing DMA pool allocator > [3.013122] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [3.013127] [drm] No driver support for vblank timestamp query. > [3.013382] [drm] Screen Target Display device initialized > [3.013441] [drm] width 640 > [3.013453] [drm] height 480 > [3.013465] [drm] bpp 32 > [3.014570] [drm] Fifo max 0x0004 min 0x1000 cap 0x077f > [3.015450] [drm] Using command buffers with DMA pool. > [3.015460] [drm] DX: no. > [3.015695] fbcon: svgadrmfb (fb0) is primary device > [3.017598] Console: switching to colour frame buffer device 100x37 > [3.096662] ppdev: user-space parallel port driver > [3.112337] [drm] Initialized vmwgfx 2.12.0 2017
Bug#907451: libbiod FTBFS: Error: cannot implicitly convert expression
Hi Matthias, On Tue, Aug 28, 2018 at 03:39:56PM +0200, Matthias Klumpp wrote: > > > ... > > > [30/149] ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color > > > -O -g -release -wi -relocation-model=pic -of > > > 'biod@sha/bio_maf_reader.d.o' -c ../bio/maf/reader.d > > > FAILED: biod@sha/bio_maf_reader.d.o > > > ldc2 -Ibiod@sha -I. -I.. -I -I../ -I/usr/include/d -enable-color -O -g > > > -release -wi -relocation-model=pic -of 'biod@sha/bio_maf_reader.d.o' -c > > > ../bio/maf/reader.d > > > ../bio/maf/reader.d(40): Deprecation: struct > > > `std.stdio.File.ByLine!(char, char).ByLine` is deprecated - Use .byLine > > > ../bio/maf/reader.d(53): Error: cannot implicitly convert expression > > > `this._f.byLine(cast(Flag)true, '\x0a')` of type `ByLineImpl!(char, > > > char)` to `ByLine!(char, char)` > > > ../bio/maf/reader.d(53):`this._lines = > > > this._f.byLine(cast(Flag)true, '\x0a')` is the first assignment of > > > `this._lines` therefore it represents its initialization > > > ../bio/maf/reader.d(53):`opAssign` methods are not used for > > > initialization, but for subsequent assignments > > > [ > > Looks like an upstream issue - have you filed a bug there already? Upstream code das not changed since first release in Debian (Sat, 04 Mar 2017) I have no idea what kind of bug I should file. :-( Kind regards Andreas. -- http://fam-tille.de
Bug#907118: error:141a318a:ssl routines:tls_process_ske_dhe:dh key too small
On Tue, Aug 28, 2018 at 09:53:58AM -0300, Antonio Terceiro wrote:
> On Thu, Aug 23, 2018 at 03:24:52PM -0600, dann frazier wrote:
> > Package: bip
> > Version: 0.8.9-1.1
> > Severity: normal
> > Tags: patch
> >
> > I run bip on a stretch system, and connect to it from a hexchat client on
> > sid. After a recent upgrade of the client, which pulled in openssl 1.1,
> > hexchat began failing to connect to my server with the message:
> >
> > error:141a318a:ssl routines:tls_process_ske_dhe:dh key too small
> >
> > I found that backporting bip 0.9.0~rc3-1 to jessie worked. I further found
> > that just cherry-picking the following commit back to bip 0.8.9 seems to be
> > sufficient:
> >
> > 39414f8 Handle OpenSSL version 1.1
>
> I just tried backporting commit 39414f8 to the bip version in stretch,
> and it doesn't really fix the issue. There is probably some other commit
> that is needed.
I literally poked that patch into debian/patches{/series}, quilt
applied it and rebuilt, and it started working for me. Maybe there's
something different about our configs?
Bug#907575: Bug - je ne peux pas installer debian FR
Package: installation-reports Boot method: clef usb 8go (image copiée avec la commande dd if=image of=/dev/sdx bs=4M && sync, avant cela j'ai aussi essayé de copier avec le logiciel etcher) Image version: J'ai essayé plusieurs iso, d'abord debian-9.5.0-amd64-netinst.iso mais en début d'intallation un message qui annonçait qu'il manquait un "microcode" wifi. J'ai Donc ensuite essayé avec cette image : firmware-9.5.0-amd64-DVD-1.iso, puis celle ci : debian-live-9.5.0-amd64-gnome+nonfree.iso Date: les 28/29 aout 2018, toute la journée 😢 ^^ Machine: ordinateur ASUS serie 5RR6UJ-XX079T (2015) Processor: I5 je ne sais plus le modèle exact) Memory: 4g de ram / disque dur 1tera HDD Partitions:
Bug#906806: Bug #906806: Show artwork authorship in bits.debian.org posts
Hi all Ana did an initial implementation of this (thanks!): https://salsa.debian.org/publicity-team/bits/commit/207c45f01980d35f8b4cc6b9c6badb18e0a3f1fc https://salsa.debian.org/publicity-team/bits/commit/1c6d136cf36f5436ee21629fbed0d86cbace02a9 and then added the "Artist" field to 2 blog posts: https://salsa.debian.org/publicity-team/bits/commit/7af5e3c030897e95e9f6a64ea9fef2ce35790166 https://salsa.debian.org/publicity-team/bits/commit/bdf7e976655a29d9dbcd0cb7850be31e865c9464 Now I see there are 2 tasks about this issue: * Complete or refine the implementation (this is a coding task). * Add the field artist to the rest of the blog posts that include some artwork (edit the markdown files adding the line with the name of the artist, as in https://salsa.debian.org/publicity-team/bits/commit/bdf7e976655a29d9dbcd0cb7850be31e865c9464 ) Any volunteers? Cheers -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Bug#907574: firefox-esr: Incompatible WM_CLASS (StartupWMClass) between firefox-esr.desktop and firefox-esr running instance
Package: firefox-esr Version: 60.1.0esr-3 Severity: normal X-Debbugs-CC: gland...@debian.org Dear firefox-esr maintainers, I am reporting a problem about WM_CLASS; for its background, please take a look at obsoleted https://bugs.debian.org/682371 and freedesktop.org Startup Notification Specification [1]. TL;DR: * Current WM_CLASS for firefox-esr: WM_CLASS(STRING) = "Navigator", "Firefox" * StartupWMClass as written in firefox-esr.desktop: "Firefox-esr" * Buggy result: Multiple firefox-like icons will appear on modern desktop task lists (e.g., GNOME Shell) * Solution: Either patch firefox-esr src and set its WM_CLASS back to Firefox- esr, or modify firefox-esr.desktop and set StartupWMClass=Firefox (I personally dislike this since it will cause confusion when firefox and firefox-esr are coinstalled). P.S. I will close #682371 now since iceweasel has disappeared for ages. -- Regards, Boyuan Yang [1] https://www.freedesktop.org/wiki/Specifications/startup-notification-spec/ signature.asc Description: This is a digitally signed message part.
Bug#907559: cgview: Does not start
[Bug #907559 in CC which should collect information about this issue] Hi Markus, On Wed, Aug 29, 2018 at 05:16:38PM +0200, Markus Koschany wrote: > the newer Batik version in testing does not provide the XMLConstant > class anymore. They have split the functionality and moved it into a new > project called Batik Constants. > > https://mvnrepository.com/artifact/org.apache.xmlgraphics/batik-constants > > See also https://issues.apache.org/jira/browse/BATIK-1185 Ahhh, thanks for this helpful information. > Maybe you should raise this issue with upstream (Batik and/or cgview) Well cgview is not actively maintained (but has quite a number of users) and what exactly should I say to Batik upstream if they decided to move it to a noew project? I admit I have no idea what to say and where to report. Wouldn't it help more if I simply try to package batik-constants? Kind regards Andreas. -- http://fam-tille.de
Bug#907573: Please provide u-boot image for qemu
package: u-boot version: 2018.05+dfsg-1 severity: wishlist Hi, Upstream u-boot ships a config for qemu. It would be nice to have the u-boot package build this. I tested it on armhf and arm64. Qemu can be started with "-bios /path/to/u-boot.bin". All that is needed is a boot.src or extlinux.conf. On a clean install with d-i, running u-boot-update (from u-boot-menu) is enough. Flash-kernel could probably support this too, but it would need to be updated. If you think this is a good idea, I can write a patch (or create a merge request) that creates a u-boot-qemu package. I wonder if this would be usefull on other architectures (besided arm*). Cheers, Ivo
Bug#886239: librsvg: please make the build reproducible
Forwarded: https://gitlab.gnome.org/GNOME/librsvg/issues/259 Control: tags -1 + fixed-upstream pending On Wed, 03 Jan 2018 at 12:51:35 +, Simon McVittie wrote: > On Wed, 03 Jan 2018 at 12:25:42 +, Chris Lamb wrote: > > This is due to the binary including the absolute build path so that > > it can find test data. > > It should probably use g_test_build_filename() now that that exists > (relative to $G_TEST_SRCDIR or $G_TEST_BUILDDIR as appropriate, falling > back to dirname(argv[0]) for both if unspecified). This appears to have been done in the version that I'll be uploading to experimental soon. smcv
Bug#905630: SCardConnect sometimes hangs
Hi Ludovic, On Wed, Aug 29, 2018 at 04:11:14PM +0200, Ludovic Rousseau wrote: > Le 07/08/2018 à 13:24, Wouter Verhelst a écrit : > > I'm not sure where this is coming from, but would be happy to perform > > any required debugging steps. > > Thanks Wouter for the bug report. > > I have some questions: > - do you also have the problem if you use only 1 reader instead of 3 > (so if you do _not_ use vsmartcard) I haven't tried this in a while, but I'll try to do so tomorrow and will let you know. > - do you start the second instance of the program immediately after > the first run? or you can run the second instance 1 second after the > first and still get the problem? I started the two instances of that program in two different terminal windows, manually. I don't know *exactly* how much time there was between both instances, but typing "./test", move mouse to other terminal, and typing again "./test" does take more than a fraction of a second; so whatever the problem may be does not require that things are changed *immediately*. > I can reproduce the behaviour you get by removing/commenting the line > 288 at > https://salsa.debian.org/rousseau/PCSC/blob/master/src/winscard.c#L288 > I am suspecting a race condition issue somewhere. But I have no idea > how to reproduce it. I don't think it is a race. Instead, I suspect some internal state corruption. Once the problem occurs once, it is easy to reproduce, but only until I restart pcscd; then I have to play with stuff again until I somehow trigger the magic incantation which makes it reappear. > What could help is to get pcscd logs when the problem occurs. But I > understand it is not easy if you don't know how to reproduce the > problem. > https://pcsclite.apdu.fr/#support I'll try anyway. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#907416: since latest upgrade krunner does not find applications, and systemtray does not start
Le 08/28/18 à 01:25, Bernhard Übelacker a écrit : > Hello David Erwan, > this sounds like it could be a duplicate of bug #907301 [1]. > > Is your systray still visible? > If not you can check if this is really your > problem by starting this in a terminal: > > QT_LOGGING_RULES="*plasma*=true" plasmawindowed org.kde.plasma.systemtray > > And you receive output containing this: > > ... this plugin is compiled against incompatible Plasma version 340224 > This build is compatible ... > > > As a workaround you might try to rebuild plasma-workspace > locally and install the resulting plasma-workspace_*.deb > (Like reported in [2] should that package be enough.) > > Another user reported that he could work around the issue > by installing two packages from unstable [3]. > > Kind regards, > Bernhard > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907301 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907301#60 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907301#75 > Thanks, I used the packages from unstable and it works.
Bug#907572: RM: python-jsontest -- RoM, RoQA, low popcon
Package: ftp.debian.org Severity: normal Dear ftpmasters, Please remove python-jsontest, it has low-popcon and we do not intend to maintain it further on. Thank you, Christophe signature.asc Description: PGP signature
Bug#907571: RM: pyinfra -- RoM, RoQA, low popcon
Package: ftp.debian.org Severity: normal Dear ftpmasters, Please remove pyinfra, it has low-popcon and we do not intend to maintain it further on. Thank you, Christophe signature.asc Description: PGP signature
Bug#907547: anbox: Enable --use-rootfs-overlay in anbox-container-manager.service by default?
> I'm waiting upstream to merge the lxc2 patch... ah that was cause of the delay.. > Anyway I'll tag a new snapshot shortly. Thanks! : ) > But I don't think overlay should be default, since it's an advanced usage. I was pondering that, and I think you're right. > ExecStart=[…] --use-rootfs-overlay thanks yes that's what I have in there. Now looking forward to see if simple extracting parts of the supersu zip into the overlay will give me a functional Titanium Backup to transfer apps from phone to PC 🤠
Bug#907553: Acknowledgement (libminc: wrong cmake installation path)
control: tags -1 patch
diff -Nru libminc-2.4.03/debian/changelog libminc-2.4.03/debian/changelog
--- libminc-2.4.03/debian/changelog 2018-08-26 17:10:28.0 +
+++ libminc-2.4.03/debian/changelog 2018-08-29 15:57:15.0 +
@@ -1,3 +1,9 @@
+libminc (2.4.03-1ubuntu1) cosmic; urgency=medium
+
+ * Fixup installation path (Closes: #907553)
+
+ -- Gianfranco Costamagna Wed, 29 Aug 2018
17:57:15 +0200
+
libminc (2.4.03-1) unstable; urgency=medium
* re-upload to sid
diff -Nru libminc-2.4.03/debian/libminc-dev.install
libminc-2.4.03/debian/libminc-dev.install
--- libminc-2.4.03/debian/libminc-dev.install 2018-08-26 17:10:28.0
+
+++ libminc-2.4.03/debian/libminc-dev.install 2018-08-29 15:57:15.0
+
@@ -1,5 +1,5 @@
usr/lib/*/lib*.so
-usr/lib/*/cmake/*.cmake
+usr/lib/*/cmake
usr/include/*
diff -Nru libminc-2.4.03/debian/patches/installation-cmake-path
libminc-2.4.03/debian/patches/installation-cmake-path
--- libminc-2.4.03/debian/patches/installation-cmake-path 1970-01-01
00:00:00.0 +
+++ libminc-2.4.03/debian/patches/installation-cmake-path 2018-08-29
15:57:14.0 +
@@ -0,0 +1,11 @@
+--- libminc-2.4.03.orig/CMakeLists.txt
libminc-2.4.03/CMakeLists.txt
+@@ -534,7 +534,7 @@ IF(LIBMINC_INSTALL_LIB_DIR AND NOT LIBMI
+
${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/Use${LIBMINC_EXTERNAL_LIB_PREFIX}LIBMINC.cmake
+
${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/${LIBMINC_EXTERNAL_LIB_PREFIX}LIBMINCConfig.cmake
+ DESTINATION
+- ${LIBMINC_INSTALL_LIB_DIR}/cmake
++ ${LIBMINC_INSTALL_LIB_DIR}/cmake/LIBMINC
+ COMPONENT Development)
+
+ ENDIF(LIBMINC_INSTALL_LIB_DIR AND NOT LIBMINC_INSTALL_NO_DEVELOPMENT)
diff -Nru libminc-2.4.03/debian/patches/series
libminc-2.4.03/debian/patches/series
--- libminc-2.4.03/debian/patches/series2018-08-26 17:10:28.0
+
+++ libminc-2.4.03/debian/patches/series2018-08-29 15:57:15.0
+
@@ -4,3 +4,4 @@
remove-rpath.patch
initialize_arrays_in_tests.patch
disable-dimension-test.patch
+installation-cmake-path
G.
Il mercoledì 29 agosto 2018, 12:27:06 CEST, Debian Bug Tracking System
ha scritto:
Thank you for filing a new Bug report with Debian.
You can follow progress on this Bug here: 907553:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907553.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
Your message has been sent to the package maintainer(s):
Debian Med Packaging Team
If you wish to submit further information on this problem, please
send it to 907...@bugs.debian.org.
Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.
--
907553: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907553
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#907570: libmodule-install-perl: install_script shouldn't change the shebang to realpath
Package: libmodule-install-perl
Severity: important
Control: affects -1 dh-golang
Dear Maintainer,
Disclaim: I'm poor at perl.
When build dh-golang in a usrmerged chroot, the shebang of the bash script[1]
installed[2] by `install_script` is changed to /usr/bin/bash.
I think the `install_script` command is provided by
libmodule-install-perl.
It happens when I build dh-golang with sbuild.
By default, sbuild-createchroot calls debootstrap to create the chroot.
And the default behaviour of debootstrap is to create a chroot that
makes /{bin,sbin,lib}/ symlinks to /usr/. So in the chroot, /bin/bash
symlinks to /usr/bin/bash.
I'm not sure if the usrmerge is enabled by default in Debian or not.
But I find many Debian systems is not usrmerged.
As a result, the bash script installed by libmodule-install-perl failed
to run on my system.
I don't known why libmodule-install-perl wants to manipulate the shebang
when the origin shebang exists.
P.S. It seems the chroot on buildd is not usrmerged, so the dh-golang
package in the archive has the correct shebang.
[1] https://sources.debian.org/src/dh-golang/1.35/script/dh_golang_autopkgtest/
[2] https://sources.debian.org/src/dh-golang/1.35/Makefile.PL/#L7
--
Shengjing Zhu
Bug#860285: Any version update
On 08/29/2018 02:49 PM, Mathieu Parent (Debian) wrote: > Hi, > > Do you plan to update pyvmomi to 6.5? > > Otherwise, may I? > > Regards > > Mathieu Parent > > -- > Mathieu Parent Please instead, take over the package. It's not used by OpenStack anymore. Cheers, Thomas Goirand (zigo)
Bug#907569: ganeti: SHA256 certificate support should be backported to stretch to allow smooth upgrades
Source: ganeti Version: 2.15.2-7+deb9u2 Severity: important Tags: patch Following up on #907216, the patch to use SHA256 for certificate signing should be backported to Stretch to allow users to switch to SHA256 certificates before upgrading to Buster. Certificate renewal has to take place in a co-ordinated fashion across a ganeti cluster (using `gnt-cluster upgrade`) and cannot be done for each node separately in the package's maintainer scripts, which means that we cannot rely on APT's sequencing between ganeti and libssl1.1 to resolve the situation on dist-upgrade. Backporting the patch will allow users to prepare their clusters before upgrading to Buster and avoid the breakage caused by the installation of OpenSSL 1.1.1.
Bug#906816: thunderbird: Does not start
On 2018-08-28 20:48, Carsten Schoenert wrote: No, you don't have done anything wrong. For AppArmor it's mostly easy to see, Thunderbird is usable or not. For a more detailed answer the messages you have got would be needed. I guess these are not related to this bug report. Assuming that the "STATUS" messages aren't that interesting, but the "DENIED" message may be, these are the only kinds I've found: [563845.233482] audit: type=1400 audit(1535392635.227:205): apparmor="DENIED" operation="open" profile="thunderbird" name="/etc/mozpluggerrc" pid=22009 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [132527.305890] audit: type=1400 audit(1534961321.424:159): apparmor="DENIED" operation="open" profile="thunderbird" name="/etc/mozpluggerrc" pid=3013 comm="thunderbird-bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [563524.459758] audit: type=1400 audit(1535392314.458:196): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/d91tan/.cache/mesa_shader_cache/6d/9eb80ce0fb32d6002d6b832c3aef1ac98c25cd.tmp" pid=5524 comm="disk_cache:0" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000 But I don't know which version of Thunderbird caused them. I get the feeling they're not related to the problem at hand. Regards, Torbjörn
Bug#897284: close 897284
close 897284 thanks user configuration error
Bug#907568: dmesg: bad localization on --help
Package: util-linux Version: 2.32.1-0.1 Severity: normal Dear Maintainer, In non-english locales, the help appears to have been over-localized. For instance: # LC_ALL=es_US.utf8 dmesg --help | grep -- --color -L, --color[=] colorea los mensajes (auto, siempre o nunca) # but: # LC_ALL=es_US.utf8 dmesg --color=siempre dmesg: modo de color no implementado: 'siempre' # LC_ALL=es_US.utf8 dmesg --color=nunca dmesg: modo de color no implementado: 'nunca' # (which, in English, is "dmesg: unsupported color mode: 'nunca'"). Thanks! -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE=es_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 util-linux depends on: ii fdisk 2.32.1-0.1 ii libaudit1 1:2.8.3-1+b1 ii libblkid1 2.32.1-0.1 ii libc6 2.27-5 ii libmount1 2.32.1-0.1 ii libpam0g 1.1.8-3.8 ii libselinux12.8-1+b1 ii libsmartcols1 2.32.1-0.1 ii libsystemd0239-7 ii libtinfo6 6.1+20180714-1 ii libudev1 239-7 ii libuuid1 2.32.1-0.1 ii login 1:4.5-1.1 ii zlib1g 1:1.2.11.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-2 ii kbd 2.0.4-4 ii util-linux-locales 2.32.1-0.1 -- no debconf information
Bug#907567: CC=gcc and automake1.11
Package: gimp-plugin-registry I took gimp-plugin-registry from Debian Sid and tried to build it for Ubuntu 18.04 and 18.10 in my PPA https://gitlab.com/nixtux-packaging/gimp-ubuntu . I had to make several fixes to make it buildable: * export CC=gcc in debian/rules, otherwise fix-ca plugin tried to be built using missing /usr/bin/gcc-6 * switch from automake (1.15 and 1.16) to automake1.11 * add gibgegl-dev build dependency Maybe it will be useful for you. -- -- С уважением, Михаил Новоселов | mikhail...@dumalogiya.ru | https://nixtux.ru
Bug#824712: RFH: smokeping
Hi there! I've been doing some work on the smokeping package in the past few weeks/months with anarcat. Namely, * a new upstream release was packaged and sent to experimental, and we're trying to get it into sid very soon. * I've written and submitted a patch upstream in response to a bug report in the BTS to make smokeping work better with newer versions of FPing (3.16+). It should make it so that the FPing probes doen't mix up IPv4 and IPv6 anymore with the recent versions of fping. This should land in a package real soon (it was merged upstream today) Future work that I intend to do is to get rid of as many lintian errors as possible, and then start working on the currently present bug reports in the BTS (from the easiest first). It is an invaluable learning experience for me since I'm new to debian packaging. Anarcat has marked myself as package maintainer, and I intend to continue work on the package. However, I'm not closing the door to collaboration with the Internet Measurement Packaging Team as was suggested by Iain. For now, pull requests on the git repository in salsa would be great, until I can feel more confident about how the package is holding things together. Cheers! signature.asc Description: OpenPGP digital signature
Bug#907057: neverball: Constant fsync calls seriously degrade performance
On Wed, 2018-08-29 at 15:27 +0200, Markus Koschany wrote: > Am 29.08.2018 um 15:08 schrieb Uoti Urpala: > > If FPS stays sufficiently high that it's not a visible issue, you could > > try running the binary under strace for example and verify that there > > are lots of fsync calls while playing. (The calls probably aren't good > > for the SSD either, even if they don't prevent playing the game.) > > strace -e fsync -o /tmp/file neverball > > My point is that it isn't something most players would experience as a > serious performance penalty. The game hasn't changed in years, so either > it is not perceived as something really serious by many or there is a > recent regression in libphysfs. Then it should be fixed there. I'm pretty sure it is a regression - years ago SSDs were not that common. And even if "most players" use it on machines with an SSD storing the save directory, the constant fsyncs likely increase SSD wear, so it's not harmless there either. > > > Not using libphysfs would be a workaround and not a fix. Hence I am > > > > I'm not sure why you're saying this. Given that upstream Neverball has > > also stopped defaulting to libphysfs use, it seems like a quite > > reasonable solution. > > Sure, not using your car when the tires are flat and instead going to > work by train is a reasonable solution, if you don't want to be late. > Most people will still want to fix the tires though because that's the > issue at hand. That comparison seems wrong. It assumes there are reasons you'd want to go back to the car (physfs) eventually. Given that upstream has changed the default, it's not an appropriate comparison here. > > AFAIK the version currently in Debian can be built with libphysfs > > disabled too. "Not actionable" seems like an exaggeration, even without > > packaging a new non-release version. > > > > I just ran a quick test, and building without libphysfs-dev worked with > > "git checkout neverball-1.6.0; make -j 6 ENABLE_FS=stdio". > > By not actionable I meant that upstream should do a proper release. This > is not something Debian can do. When they did that, we and all other However, changing the Neverball build configuration should be well within what is actionable by Debian. > distributions would package the new release. It is absolutely not clear > whether they consider all there other changes as feature complete. In > the worst case, we fix this bug but open a can of worms for other users. > Yes, usually it is not as bad for games but surely for other software in > the archive. There is also a good reason for using fsync. It protects > you against data loss. Cases where fsync() is the right tool are actually pretty rare. And this absolutely isn't one of them (particularly the Neverball save file case, but more generally physfs doing fsync() calls when the application hasn't explicitly requested them is not right either).
Bug#859234:
-=| Pablo Sánchez[gmail], 29.08.2018 10:13:37 -0300 |=- > Found it ??? > > On x86/amd64 I usually have to config RemoteBindAddress with computer ip > number after install , as connections where rejected . This is normal. The default bind address is 'localhost'. An admin needs to knowingly allow remote access. > I realized I was also configuring the same on raspberry pi. After > commenting that line con firebird.conf, after restart and power off / power > on, service started on boot . Perhaps the Pi is slower to acquire its IP address and this leads to timeout in fbguard. Just commenting out the setting allows connection from everywhere — entering an IP is useful only if there are several network interfaces. Using a firewall for giving selective access is better anyway. -- dam
Bug#868806: Updated the upstream bug
Hi, I looked at that due to a similar Ubuntu Bug. It seemed as if handling of the report you opened has stalled. I updated the bug with a summary of changes in that context over the last 2.5 years and submitted to their mailing list. Hopefully that will help getting this resolved. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
Bug#897284: rss2email: barfs "sax parsing error: :2:0: syntax error:" even on debian rss feeds
Hi Olivier, * Olivier Berger [2018-08-29; 13:17]: > On Tue, May 01, 2018 at 11:48:37AM +0200, Gregor Zattler wrote: >> I configured r2e as described in the man page quick start and run >> it. It did not work but gave this info: >> >>* What exactly did you do (or not do) that was effective (or >> ineffective)? >> >> $ r2e -V -V -V -V -V -V -V -V -V -V -V run >> load feed configuration from ['/etc/xdg/rss2email.cfg', >> '/home/grfz/.config/rss2email.cfg'] >> loaded configuration from ['/home/grfz/.config/rss2email.cfg'] >> load feed data from /home/grfz/.local/share/rss2email.json >> fetch debian-news (url -> https://www.debian.org/News/news) >> process debian-news (url -> https://www.debian.org/News/news) > > May I suggest that you post an excerpt of r2e list ? > > I think you probably misconfigured the Debian feed. > > I think the trace should exhibit something like : > fetch debian-news (https://www.debian.org/News/news -> u...@example.com) > > which gives me the impression that you mistyped the arguments of the r2e > add, using "url" instead of the URL of the feed and the URL instead of > the optional recipient of the mails. > > Tell me if I'm guessing right. You are right. I configured r2e like: r2e add debian-news2 url http2://www.debian.org/News/news I don't know where I was getting the impression of having to add the "url" keyword. Without it it works like a charm. > Then this show-stopper bug could probably be closed. > > Hope this helps It really did. Thank you very much! Ciao; Gregor -- -... --- .-. . -.. ..--.. ...-.-
Bug#907566: New version 3.0.4 available
Package: libical3 Version: 3.0.3-1 hey, There is a new 3.0.4 version available https://github.com/libical/libical/releases/tag/v3.0.4 It fixes some bugs and include updated tzdata information, the update would be nice to get into Debian Cheers,
Bug#907226: cutesdr: FTBFS with Qt 5.11
Reiner Herrmann writes: > the attached patch fixes the FTBFS by including the missing header. ... > ++#include Hi, Thanks so much, but I see the upstream author Moe Wheatley has now also included this fix, so I have pulled a few more commits from upstreams work towards a version 1.21 onto a revised Debian packaging for version 1.20. I just want you to know that even though I did not apply your fix directly, I appreciate receiving it. -Maitland
