Bug#948041: impossible to update libbpf without updating the kernel
On Sat, Jan 18, 2020 at 7:48 AM Bastian Blank wrote: > > On Wed, Jan 15, 2020 at 12:50:16PM +, Sudip Mukherjee wrote: > > On Wed, Jan 15, 2020 at 06:12:05AM +, Jonathan Nieder wrote: > > > I agree --- if upstream development were happening in > > > https://github.com/libbpf/libbpf then this would be a no-brainer. It > > > appears to instead be a mirror of the source that's in the kernel > > > repo, though. > > That will be difficult as all of them are dependent on the ftrace hooks > > that are in the kernel. > > What will be difficult? > > > > > Why should we switch from kernel sources to GH is a frequently asked > > > > question so the reason was explained in libbpf README [1]. > > Let's go through it one by one. > > "Consistent versioning across distributions." > > Maybe, but the kernel is also versioned consistently. Libbpf releases are only loosely synchronized with kernel releases, and it's only due to current convention we established within community. There is nothing preventing multiple releases of libbpf between two releases of kernel. So having Linux distributions use Github's release tags ensures that all of them are building from exactly the same source code version. > "No ties to any specific kernel, transparent handling of older kernels." > > What? Either they are upstream for it or patch the source. But this > point means it can't be a direct mirror. So what is it? It is mostly a direct mirror, with some extra Github-specific stuff beside (like Travis CI testing, etc). All the libbpf source code fixes do go through bpf-next tree, though. But the point here was that libbpf itself is not built with any particular kernel version in mind. It is by design possible to use the very latest libbpf against a pretty old kernel version and this will work: libbpf will degrade some of the features (e.g, BTF type info associations), but everything will keep working otherwise (unless user requests feature that requires latest kernel version, of course: in that case BPF program will fail to load and libbpf will return corresponding error code). > > "Continuous integration testing via TravisCI." > "Static code analysis via LGTM and Coverity." > > Both are not restricted to this repo. Not sure what you mean by this. We can't have Travis CI integration w/ bpf-next source tree. But we can and we have it for Github mirror, which runs tests and static analysis for every sync pull request. We already have and are enhancing at the moment our testing set up to test multiple kernels in multiple environments. > > > > If I'm reading that correctly, the intent appears to be that it would > > > allow faster libbpf upgrades. > > Yes, one of my intent. Faster and independent. > > And how does it do that, without being upstream of the source? > > Sorry, but I intend to end this discussion here. > > Bastian > > -- > It would be illogical to assume that all conditions remain stable. > -- Spock, "The Enterprise Incident", stardate 5027.3 > > -- > To unsubscribe, send mail to 948041-unsubscr...@bugs.debian.org.
Bug#949358: ITP: ulauncher --Universal launcher
Package: wnpp Severity: wishlist * Package name: ulauncher Version: 5.6.1 Upstream Author: Aleksandr Gornostal * URL: https://github.com/Ulauncher/Ulauncher * License: GPLv3 Description: A universal launcher. Ulauncher is a universal launcher for applications and URL searches using various search engines.
Bug#949359: Wish for space-separated --include="foo bar"
Package: mmdebstrap
Version: 0.5.1-4
Severity: wishlist
Currently --components allows separation by commas OR spaces.
Currently --include allows separation by commas BUT NOT spaces:
$ mmdebstrap sid delete-me --components='main contrib non-free'
--include='amd64-microcode,intel-microcode,iucode-tool'# works
$ mmdebstrap sid delete-me --components='main contrib non-free'
--include='amd64-microcode intel-microcode iucode-tool'# fails
[...]
E: Unable to locate package amd64-microcode intel-microcode iucode-tool
[...]
Please make --include behave like --components.
This will make it easier for me to create --include from a great big
bash array with inline comments:
includes+=(
baz # for chromium
quux
quuux # because of international terrorism
# [...]
)
Because then I can simply say
"--include=${includes[*]}"
instead of having to mess around e.g.
OLDIFS=$IFS IFS=,
"--include=${includes[*]}"
IFS=$OLDIFS
My perl-fu is pretty stale, but based on
my @comps = split /[,\s]+/, $comp;
I think this patch is "good enough":
--- /rsync:root@not-omega:/tmp/bootstrap/mmdebstrap
+++ #
@@ -1196,7 +1196,7 @@
my %pkgs_to_install;
if (defined $options->{include}) {
- for my $pkg (split /,/, $options->{include}) {
+ for my $pkg (split /[,\s]+/, $options->{include}) {
$pkgs_to_install{$pkg} = ();
}
}
Bug#949359: Wish for space-separated --include="foo bar"
On Mon, 20 Jan 2020 17:39:32 +1100 "Trent W. Buck" wrote: > Please make --include behave like --components. Yesterday I uploaded version 0.6.0 of mmdebstrap. This should already work. :) Please confirm by closing this bug. Thanks! cheers, josch signature.asc Description: signature
Bug#949360: w cuts IPv6 addres
Package: procps Version: 2:3.3.15-2+b1 Severity: normal File: /usr/bin/w Tags: ipv6 Hi, [1/1520]mh@roll:~ $ w 07:48:37 up 12:09, 1 user, load average: 0,00, 0,01, 0,01 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT mh pts/22a01:238:4071:32 07:484.00s 0.05s 0.00s w [2/1521]mh@roll:~ $ dpkg --list procps The IP address cut off at the interesting point makes the information useless. The formatting looks like w invokes last, which has an option -w to give the full address. Maybe it is a good idea to give that option here as well. Greetings Marc
Bug#948611: Progress
Hi We are working on fixing this issue in this upstream PR: https://github.com/mesonbuild/meson/pull/6457 The PR requires some fixes still, but if someone could test and verify that it fixes the issue in this bug it would be useful. We'll make the 0.53.1 release immediately after that PR has been merged to master.
Bug#949361: r-cran-ranger: autopkgtest regression on some architectures
Source: r-cran-ranger
Version: 0.12.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of r-cran-ranger 0.12.1-1, its own autopkgtests have
been failing [1] on at least arm64, ppc64el and s390x.
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1]
https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-ranger/4034091/log.gz
> library(testthat)
> library(ranger)
>
> test_check("ranger")
── 1. Failure: maxstat corrected impurity importance is positive (on average) (@
mean(rf$variable.importance) is not strictly more than 0. Difference: NaN
Error: testthat unit tests failed
══ testthat results ═══
[ OK: 647 | SKIPPED: 10 | WARNINGS: 0 | FAILED: 1 ]
1. Failure: maxstat corrected impurity importance is positive (on
average) (@test_maxstat.R#41)
Execution halted
autopkgtest [11:39:55]: test run-unit-test: ---]
run-unit-testFAIL non-zero exit status 1
Bug#948372: Please push your changes to nibabel
Hi Yaroslav, can you please push your latest changes to nibabel? I'd volunteer to fix #948372 and when doing so move the repository to Debian Med if you do not mind. Kind regards Andreas. -- http://fam-tille.de
Bug#938743: ufo-core: Python2 removal in sid/bullseye - reopen 938743
Hello Sandro this is strange because, I have this in the control file
Package: libufo-bin
Architecture: any
Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
Suggests: ufo-core-doc
Description: Library for high-performance, GPU-based computing - tools
The UFO data processing framework is a C library suited to build
general purpose streams data processing on heterogeneous
architectures such as CPUs, GPUs or clusters. It is extensively used
at the Karlsruhe Institute of Technology for Ultra-fast X-ray Imaging
(radiography, tomography and laminography).
.
A gobject-instrospection binding is also provided to write scripts or
user interfaces.
.
This package contains binaries to run JSON descriptions of task graphs.
Package: libufo-data
So it seems that this python dependency comes from
python3:Depends.
is it normal ?
Cheers
Fred
Bug#801084: Bluez-firmware package on Buster does not fix this.
Hi, I'd like to add to this that installing the bluez-firmware on an up to date Buster installation (10.2) does not fix it, just like Malvin points out. My hardware is looking for A1 instead of A0, but the issue is the same. Dmesg: $ sudo dmesg |grep BCM20702A1 [4.457749] Bluetooth: hci0: BCM20702A1 (001.002.014) build [4.458102] bluetooth hci0: firmware: failed to load brcm/BCM20702A1-0a5c-21e8.hcd (-2) [4.458192] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-21e8.hcd failed with error -2 [4.458194] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-21e8.hcd not found bluez-firmware package contents: $ dpkg -L bluez-firmware /lib /lib/firmware /lib/firmware/BCM2033-FW.bin /lib/firmware/BCM2033-MD.hex /lib/firmware/STLC2500_R4_00_03.ptc /lib/firmware/STLC2500_R4_00_06.ssf /lib/firmware/STLC2500_R4_02_02_WLAN.ssf /lib/firmware/STLC2500_R4_02_04.ptc /usr /usr/share /usr/share/doc /usr/share/doc/bluez-firmware /usr/share/doc/bluez-firmware/BCM-LEGAL.txt /usr/share/doc/bluez-firmware/README.Debian /usr/share/doc/bluez-firmware/changelog.Debian.gz /usr/share/doc/bluez-firmware/changelog.gz /usr/share/doc/bluez-firmware/copyright For me as well, following the instructions on http://plugable.com/2014/06/23/plugable-usb-bluetooth-adapter-solving-hfphsp-profile-issues-on-linux fixed this issue. Thank you Stijn
Bug#949277: Provide an option to specify build-needed restriction to autopkgtest
Package: pkg-js-tools Version: 0.9.23 severity: important For example lode-levn autopkgtest require build to generate package.json itself and currently fails in salsa.
Bug#947832: buster-pu: package cups/2.2.10-6+deb10u2
Le samedi, 18 janvier 2020, 21.05:53 h CET Adam D. Barratt a écrit : > Control: tags -1 + confirmed > > On Tue, 2019-12-31 at 14:22 +0100, Didier 'OdyX' Raboud wrote: > > CVE-2019-2228 affects stable's cups (see #946782); and I'd also like > > to fix another memory leak (#946941). > > > > My proposed changelog would be: > > cups (2.2.10-6+deb10u2) buster; urgency=medium > > The attached debdiff, otoh, had > > +cups (2.2.10-6+deb10u2) buster-security; urgency=high > > Please feel free to go ahead, with the non-security version. :-) Uploaded, thanks for the authorization! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#949134: oasis3: FTBFS (Assigning non-zero to $[ is no longer possible at ../../protex/protex line 87.)
On 1/17/20 11:05 AM, Bas Couwenberg wrote:
> In preparation of the netcdf-fortran transition as test rebuild of your
> package was done which FTBFS:
>
> make doc
> make[4]: Entering directory
> '/build/oasis3-3.mct+dfsg.121022/lib/mct/doc/texsrc'
> perl ../../protex/protex -b m_Accumulator.F90 > m_Accumulator.tex
> Assigning non-zero to $[ is no longer possible at ../../protex/protex line
> 87.
> make[4]: *** [Makefile:27: m_Accumulator.tex] Error 255
It helps to update protex to a version that works with Perl 5.30 as per
the attached patch, but the package still FTBFS further on, see the
attached log.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
diff -Nru oasis3-3.mct+dfsg.121022/debian/patches/protex.patch oasis3-3.mct+dfsg.121022/debian/patches/protex.patch
--- oasis3-3.mct+dfsg.121022/debian/patches/protex.patch 1970-01-01 01:00:00.0 +0100
+++ oasis3-3.mct+dfsg.121022/debian/patches/protex.patch 2020-01-19 09:43:34.0 +0100
@@ -0,0 +1,656 @@
+Description: Fix 'Assigning non-zero to $[ is no longer possible' error with Perl 5.30.
+Origin: https://sourceforge.net/p/elk/discussion/897822/thread/37afb1f97d/#4ecb
+
+--- a/lib/mct/protex/protex
b/lib/mct/protex/protex
+@@ -1,4 +1,7 @@
+ #!/usr/bin/perl
++#
++# $Id: protex,v 1.15 2004/06/03 23:49:46 eschwab Exp $
++#
+ #BOP
+ #
+ # !ROUTINE: ProTeX v. 2.00 - Translates DAO Prologues to LaTeX
+@@ -19,6 +22,7 @@
+ # \begin{tabular}{|c|l|} \hline \hline
+ # -h & Help mode: list command line options \\ \hline
+ # -b & Bare mode, meaning no preamble, etc. \\ \hline
++# -i & internal mode: omit prologues marked !BOPI \\ \hline
+ # +/-n & New Page for each subsection (wastes paper) \\ \hline
+ # +/-l & Listing mode, default is prologues only \\ \hline
+ # +/-s & Shut-up mode, i.e., ignore any code from BOC to EOC \\ \hline
+@@ -77,14 +81,18 @@
+ # and hangcaption.
+ # 10May2000 C. Redder Revised LaTeX command "\label{sec:prologues}"
+ # to "\label{app:ProLogues}"
+-# 24May2001 da Silva Added !PARAMETERS/!REURN VALUE: keywords for CAM.
++# 10/10/2002 da Silva Introduced ARGUMENTS keyword, touch ups.
++#
++# 15Jan2003 R. Staufer Modified table of contents to print only section headers - no descriptions
++#
++# 25Feb2003 R. Staufer Added BOPI/EOPI and -i (internal) switch to provide the option of omitting prologue information from output files.
+ #
+ #EOP
+ #
+
+ # Keep this if you don't know what it does...
+ # ---
+- $[ = 1; # set array base to 1
++### $[ = 1; # set array base to 1 (removed to maintain Perl 5.30 compatibility)
+ $, = ' '; # set output field separator
+ $\ = "\n"; # set output record separator
+
+@@ -92,7 +100,7 @@
+ # ---
+ $GlobOptions = 'hb';# Global options (i.e for all files)
+ $LangOptions = 'ACFS'; # Options for setting programming languages
+- $SwOptions = 'flnsx'; # Options that can change for each input
++ $SwOptions = 'flinsx'; # Options that can change for each input
+ # file
+ $RegOptions = "$GlobOptions$LangOptions";
+ # Scan for global options until first first
+@@ -112,7 +120,7 @@ Arg:
+ }# end if
+ }# end foreach
+
+-# If all inut arguments are options, then assume the
++# If all input arguments are options, then assume the
+ # filename, "-", for the standard input
+ # --
+ if ( $NFiles == 0 ) { push (@ARGV, "-"); }
+@@ -129,10 +137,13 @@ Arg:
+ @keys = ( "!INTERFACE:",
+ "!USES:",
+ "!PUBLIC TYPES:",
++"!PRIVATE TYPES:",
+ "!PUBLIC MEMBER FUNCTIONS:",
++"!PRIVATE MEMBER FUNCTIONS:",
+ "!PUBLIC DATA MEMBERS:",
+-"!DEFINED PARAMETERS:",
+ "!PARAMETERS:",
++"!ARGUMENTS:",
++"!DEFINED PARAMETERS:",
+ "!INPUT PARAMETERS:",
+ "!INPUT/OUTPUT PARAMETERS:",
+ "!OUTPUT PARAMETERS:",
+@@ -188,8 +199,12 @@ ARG:
+ $eoi_string = '!EOI';
+ $bop_string = '!BOP';
+ $eop_string = '!EOP';
++$bopi_string = '!BOPI';
++$eopi_string = '!EOPI';
+ $boc_string = '!BOC';
+ $eoc_string = '!EOC';
++$boe_string = '!BOE';
++$eoe_string = '!EOE';
+ #}# end if
+
+ if ( $opt_A ) {# ADA
+@@ -198,8 +213,12 @@ ARG:
+ $eoi_string = '--EOI';
+ $bop_string = '--BOP';
+ $eop_string = '--EOP';
++$bopi_string = '--BOPI';
++$eopi_string = '--EOPI';
+ $boc_string = '--BOC';
+ $eoc_string = '--EOC';
++$boe_string = '--BOE';
++$eoe_string = '--EOE';
+
Bug#936924: libsvm: Python2 removal in sid/bullseye - reopen 936924
Hello, if it is like for my ufo-core package, this could be due to a script file with a shebang using python instead of python3 Cheers Fred
Bug#949260: security-tracker: add cvedetails.com to Source?
Control: tags -1 + moreinfo Hi Dmitry, hi Paul, On Sun, Jan 19, 2020 at 03:45:53AM +, Paul Wise wrote: > On Sun, Jan 19, 2020 at 3:05 AM Dmitry Smirnov wrote: > > > It might be nice to add "cvedetails.com" to CVE Source links. > > https://www.cvedetails.com/cve/CVE-2019-13072/ > > This doesn't appear to add any details that aren't on Mitre: > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13072 Tend to agree in the above, but Dmitry, what value would you see in having cvedetails listed as well for additional sources? Is there more information available which would additionally help in tracking CVEs? Any pointers? Regards, Salvatore
Bug#949285: src:dh-python: should parse DH_OPTIONS
Package: src:dh-python Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, dh-python* does not currently parse DH_OPTIONS. debhelper(7) somewhat confusingly states: DH_OPTIONS Anything in this variable will be prepended to the command line arguments of all debhelper commands. When using dh(1), it can be passed options that will be passed on to each debhelper command, which is generally better than using DH_OPTIONS. What it *actually* means is that dh_* tools need to parse DH_OPTION and treat it *as if* it were prepended to the command line arguments. This means dh_python* need to parse them too to be fully compatible with other debhelper workflows. P.S. I may have some patches pending for this. - -- Cheers, Andrej -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl4kMh4UHGFuZHJld3No QGRlYmlhbi5vcmcACgkQXkCM2RzYOdLvVAf6AmdKYgqiJU9omypccxYuskl8BU6j U8NDgFcw85A1ilszd8aakdICA7clmFkHLeeTLhmQXLVgGGNVJHuGA78Lq3sxG9a8 mltBF7RaRMzwS7uCj9mYmGDxOKEcUJO8UfakM3Hn1bsFlUamkdUtTEkXU9zrjJ0k mqAt2qIF+16UiTJlwrmLq/RJr47T8GiBAyrH5TogFgXZD9RwW5071wxsosAxEZPY XCPPbG6guMp0n7pNJ0fkEFgbSuQJz3IlIw50UqJm0OAR6s1EgylXMlZq4xT4TF7/ QkgC5iPz0DVEZhI4njcUTRo0LMy4ttlTD5WnCHXZ7KPFo1Y/xJbCF4CaDA== =l+lL -END PGP SIGNATURE-
Bug#949287: sagemath-common: Fail to start because of missing unicode_to_str from IPython.utils.py3compat
Package: sagemath-common Version: 8.9-3 Severity: important Dear Maintainer, Sagemath is unusable (both in command line or through jupyter) because of an import error. Specifically, trying to run sage or load a notebook throws the following backtrace: Traceback (most recent call last): File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/lib/python3/dist-packages/sage/repl/ipython_kernel/__main__.py", line 3, in IPKernelApp.launch_instance(kernel_class=SageKernel) File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 663, in launch_instance app.initialize(argv) File "", line 2, in initialize File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 87, in catch_config_error return method(app, *args, **kwargs) File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 542, in initialize self.init_kernel() File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 447, in init_kernel user_ns=self.user_ns, File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line 412, in instance inst = cls(*args, **kwargs) File "/usr/lib/python3/dist-packages/sage/repl/ipython_kernel/kernel.py", line 51, in __init__ super(SageKernel, self).__init__(**kwds) File "/usr/lib/python3/dist-packages/ipykernel/ipkernel.py", line 68, in __init__ kernel = self, File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line 412, in instance inst = cls(*args, **kwargs) File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line 683, in __init__ self.init_display_formatter() File "/usr/lib/python3/dist-packages/sage/repl/interpreter.py", line 231, in init_display_formatter backend.get_display_manager().switch_backend(backend, shell=self) File "/usr/lib/python3/dist-packages/sage/repl/rich_output/display_manager.py", line 322, in switch_backend self._backend.install(**kwds) File "/usr/lib/python3/dist-packages/sage/repl/rich_output/backend_ipython.py", line 59, in install from sage.repl.display.formatter import SageDisplayFormatter File "/usr/lib/python3/dist-packages/sage/repl/display/formatter.py", line 64, in from IPython.utils.py3compat import unicode_to_str ImportError: cannot import name 'unicode_to_str' from 'IPython.utils.py3compat' (/usr/lib/python3/dist-packages/IPython/utils/py3compat.py) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.2-amdmp2 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sagemath-common depends on: ii python3 3.7.5-3 sagemath-common recommends no packages. sagemath-common suggests no packages. -- no debconf information
Bug#936924: libsvm: Python2 removal in sid/bullseye - reopen 936924
On 19.01.20 11:06, PICCA Frederic-Emmanuel wrote: > Hello, if it is like for my ufo-core package, this could be due to a script > file with a shebang using python instead of python3 I just tested this and indeed, there were scripts with said python in the shebang. Changing this to python3 fixed the build. Thank you very much for this hint!
Bug#949185: transition: libffi
Control: tags -1 - moreinfo Control: tags -1 + confirmed Control: block -1 by 949288 949290 On Sun, 19 Jan 2020 at 13:12, Matthias Klose wrote: > these are now filed, with patches. Thanks! Please go ahead.
Bug#944315: telegram-desktop: No preview for images in file selection dialog
Hello! В Чт, 07/11/2019 в 18:48 +0100, Andreas Tille пишет: > in telegram-desktop 1.7.x the file selection dialog presented a preview > of the image under the cursor when trying to attach an image. This does > not work any more in 1.8.x (several versions x). So I need to find the > correct image to attach in a separate program to find the correct file > name and pick this in the text only dialogue. I think I have found the root of the problem. In v1.7.2 the TDESKTOP_FORCE_GTK_FILE_DIALOG switch was added[1], but I did not define the macro in build scripts of the package. Because of this, the latest version s of Telegram Desktop use a file chooser dialog from Qt which does not render image previews in the right panel. [1]: https://github.com/telegramdesktop/tdesktop/commit/45a6985df54f7884b78a2c8f0da5b53ba6e13b2d signature.asc Description: This is a digitally signed message part
Bug#939224: last cuts IPv6 addres
Hello, On Mon, Sep 02, 2019 at 01:21:43PM +0200, Marc Haber wrote: > Package: util-linux > Version: 2.33.1-0.1 > Severity: normal > File: /usr/bin/last > Tags: ipv6 > > Hi, > > [2/4990]mh@torres:~ $ last | head -n 1 > mh pts/52a01:238:4071:32 Mon Sep 2 13:19 still logged in > [3/4991]mh@torres:~ $ > > The IP address cut off at the interesting point makes the information > useless. I know that I can use last -d, but maybe I'd want the complete > IP address. FWIW you can use the '-w' flag which will switch from the default "domain_len'[1][2] to using the utmpx ut_host size as documented in man utmpx[3] (UT_HOSTSIZE). (Which is bigger, but also has no guarantee of not being truncated. or even completely false! See 'man utmp'.) While outputting misleading information (which is worse than "obviously/identifyably wrong") the last command is documented as deprecated and only preserved for legacy reasons. It's becoming increasingly rare for utmp / wtmp information to be updated at all, so noone should really rely on this information in this day and age. With this said, I think unless the previously given information is considered a solution in itself the alternative is that this is to be considered a wontfix issue. [1]: https://sources.debian.org/src/util-linux/2.34-0.1/login-utils/last.c/#L64 [2]: https://sources.debian.org/src/util-linux/2.34-0.1/login-utils/last.c/#L905 [3]: https://manpages.debian.org/buster/manpages/utmpx.5.en.html#DESCRIPTION Regards, Andreas Henriksson
Bug#949293: gnutls28: [buster] Fails to parse certs with RegisteredID
Source: gnutls28 Version: 3.5.10-1 Severity: important Tags: patch buster Control: forwared -1 https://gitlab.com/gnutls/gnutls/issues/905 GnuTLS 3.5.10 to 3.6.8 fails to parse certificates using RegisteredID which is a regression. - certtool --verify-chain --verify-hostname=node.acme.com --infile=/tmp/chain.pem error parsing CRTs: Unknown Subject Alternative name in X.509 certificate. - cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -BEGIN CERTIFICATE- MIIFhzCCA2+gAwIBAgIIVRr27nlGS/4wDQYJKoZIhvcNAQELBQAwgYsxCzAJBgNV BAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ4wDAYDVQQHEwVHbG9ubjEWMBQGA1UE ChMNSERMLVN5bmVyZ2llczEPMA0GA1UECxMGRG9pdExMMRAwDgYDVQQDEwdlY3Mx LUNBMR8wHQYJKoZIhvcNAQkBFhBjZXJ0c0Bkb2l0bGwuY29tMB4XDTIwMDExMzAw MDAwMFoXDTIxMDExMjIzNTk1OVowZDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0Jh dmFyaWExDjAMBgNVBAcTBUdsb25uMQ0wCwYDVQQKEwRhY21lMQwwCgYDVQQLEwNF Q1MxFjAUBgNVBAMTDW5vZGUuYWNtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMkJJqHU7N7qOrZ2CaBbiAlVuo/OmgLDdJqSiIOSSTM5CgChj0 nZ2A/K5sY4cAmqdc10SxC8Gf3I/wMQcBLRXwUckpRJcauOCQOAf4KBu5S2ZddXf0 2mB4i/Oj5lRPri3CRQZjPeB/AXUaM73efLT94uHjnxNnoGsE5gMrfLcGGZGbwPxq 7wXL42UjS+svKblnhs32jjAr+5480KqU/ln5j7wZFpZ7gh8rfdv4Ye/D7lZeZWmM w521oD62yn5F4dlv6X6qO6XA8xubU11rw6BJB+9qPU1nyRr+RTpksj5/2kX7zxik oamizIviJd2cHuUMDFvUQl7rD046sMi1gFiNAgMBAAGjggETMIIBDzAMBgNVHRMB Af8EAjAAMB0GA1UdDgQWBBSPwl4fSMJ0Stb0X6FFJnMPSic1pTALBgNVHQ8EBAMC BeAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMDkGA1UdEQQyMDCIBSoD BAUFgg1ub2RlLmFjbWUuY29thwR/AAABghJjbHVzdGVyLmRvaXRsbC5jb20wQAYD VR0fBDkwNzA1oDOgMYYvaHR0cDovL3d3dy5hY21lLmNvbS9jZXJ0cy9lbGFzdGlj c2VhcmNoLWNybC5wZW0wEQYJYIZIAYb4QgEBBAQDAgbAMCQGCWCGSAGG+EIBDQQX FhVEb2l0TEwgSW5mcmFzdHJ1Y3R1cmUwDQYJKoZIhvcNAQELBQADggIBAB1ezzld haFOqtftCjDeX6h3LogqVdUx12X313ysOKThBS3b9zOnhJY5OSMwyMfXS+p8LYNV XYILX23/MmLwYFVOIwLt9ii+FBonCIVUPSeR1sZcNPUoOExEpbPK1gWyPlW6J7B9 K95Xme0hUUVGaLxUvkjpi8XeLnqMz18V5DIh/tVZ+ssvSjeOc6tE80imFxyKYF4h LNN9i7c2pg0vwBvUEIg8sdGLT8m4JCzhgejv8DY6QlOpzvXihXp3MPmtRmgVrIw5 LLMCsoz+JtsjIrEcwlYG6q5/84tCHyF/dZ/m73LR+o61aRX3Y6TlS2vodUX2dwrO 7VbMeQsrc5xrYpJrcm+an5RLoP5WwVPGmc0HKnAsc3lp40FYodnMLiWnvvbsUoOc Y8lRqOeD3EZtNQHwOEQ5K/O0gH9nulP9PFG9+KMiGQHcTmrubVkKmy/q0ev1wjgN 2C72UZj1ZGhJEyJDB/iGOKtHwCkiO0fJzcfMk22leG8BSIuqWfT9iaA/x9iQuRP8 8o18zN/3jjQxm7ramI+UH/paosyOAZG00ssEfcwbs3c5LR3YJdRAGelh3wNqED7/ C8pRU4J5KEmj/mdqm8g/WyJNhvy24JLSceF3mu7TPfxJ1yV8d27SOoMPo+yZzJEt MSE41z6ZaVuQe0Kkh85sI1YbBNM7UGCxLnHn -END CERTIFICATE- -BEGIN CERTIFICATE- MIIGUjCCBDqgAwIBAgIIa9Kynm+Yny8wDQYJKoZIhvcNAQELBQAwgYsxCzAJBgNV BAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ4wDAYDVQQHEwVHbG9ubjEWMBQGA1UE ChMNSERMLVN5bmVyZ2llczEPMA0GA1UECxMGRG9pdExMMRAwDgYDVQQDEwdlY3Mx LUNBMR8wHQYJKoZIhvcNAQkBFhBjZXJ0c0Bkb2l0bGwuY29tMB4XDTE4MTIyMzAw MDAwMFoXDTM4MTIyMjIzNTk1OVowgYsxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdC YXZhcmlhMQ4wDAYDVQQHEwVHbG9ubjEWMBQGA1UEChMNSERMLVN5bmVyZ2llczEP MA0GA1UECxMGRG9pdExMMRAwDgYDVQQDEwdlY3MxLUNBMR8wHQYJKoZIhvcNAQkB FhBjZXJ0c0Bkb2l0bGwuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAuMXaYQVVoBxazAkDbwed/+H6CbaD7Mb93mT+Nm6mTG1DnMTuUQaV7NdsvH3U giafEpBwZTU/HEfSTyvktQEvuziRNRfrdBSzmXzrFMRA/8LBZNuRGWQtX4WjpeIH nOrjyt9NCxkcV0cyJWba8jq899XAEV7aEBjLis2lWxoRpsepRr8MqyUfyYzxOeVw iJs8K5jQcLW/SBCgs0WgGhlGtZ7/PBzuEfVEsRjdIquGdEcQyAiSOAdYkjv4k1h3 2CMmONnmddMzDsdLISng6sE0FKeqPbfejxTcKoRyxgqFk/YiOjSV/u+0nfxnhrIi MgTqRxa6f0fIG+YVjm/xnFZuo0u95Hic+0SM8UWLVzzJJYL8dN86QplqxrTKV+sU flf9lYkU36M838Lu8EdTeSKO159ppTQpBCzTlCsS+0Ks8gg9rP1LdVLCZNgXOApB PxkriKp95Cr1UuBmke+f0vKz0HOMCDFaGQFAZC+w8A0sJSpaxKfuyvlimRV7Y9i/ 21UyFh9hmRzQQf1niqLDeX1S31XugcchwnWmyxl5zQvjRpT6W43pWnDzSbkQFf+G q/ZaSOq/ZzeEM3oFqXmIlmLiYV4RrzvkN5ji/MwUTLqjHLMeRS6ovc542jbmg4fD 7pU+gGx8Ligjj0CAAdX65ZqFo3BHr0a86aCAim0fWhX6M00CAwEAAaOBtzCBtDAS BgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQd70/FyrK+D7lRvb+7YME9sn2L ZjALBgNVHQ8EBAMCAQYwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5kb2l0 bGwuY29tL2NlcnRzL2VjczEtY3JsLnBlbTARBglghkgBhvhCAQEEBAMCAAcwJAYJ YIZIAYb4QgENBBcWFURvaXRMTCBJbmZyYXN0cnVjdHVyZTANBgkqhkiG9w0BAQsF AAOCAgEAambWvcF0+9IttVcLPLmrv5WLnkV6A6KVEFbZZ5uzebZ2xQcXyX7Qo7Vw eCufjuPa9mmUxxQFBCM0ePB1zdy7KG61plr1rRmN64MttR1q9JZvP/ZfkmDYntnY m0JIkghadtEJdaH6K9ZpCpGvLvdnLwIw7rUM7QWuTWbwgv+i5CmBILLdwPW7r88X caD8m+KZW8mlx0+oNp9zwpQLXSZBSDemdEwS5VSuER7W20Q8dVQak9QyQgVdOiPP 0upuSGRhXyt+K21o4kTws5R0t8ymwPVUhW14KWaC+1t3r4c0Fd22VL1anKHueZml bVDDWAXWRV3e6xIq2qvK/mob+VJ7Nn8BLciazlO4YHK8RAOsgNIKNPerTgpYDSoy 9hbtjlQFVdGqenjFGAE0fKR7jgEWfAIlqNhCJLF/lVIYJtNvRHJkrmR+1kZShUkU H7BcFpgjOKyNLNbs5b7bVaIajul+ADwkO3pskD3O18zw4STqPtNlnKzgKWTDw3c4 vC5de44aORdn17leMIeu+7NZsKKkd+A9b8LrEgYlMmA3GQLFMDATK+0YbB0oHcMs bEvho4jRuPdc6e81JZmB9UHVtfvxXV7T3Oc21hrzIPjQ4S7XPah07PafIPgbimqy UgFLiwJKnFwSGm86f8VcPblitza79WEJ+S60lWcRTN2wjMN9CZg= -END CERTIFICATE-
Bug#893206: CPL not usable with Python on armhf and ppc64el
On 2018-03-17 10:50, Ole Streicher wrote: > Package: libcpl-dev > Version: 7.1-1 > Severity: normal > > On some platforms, notably armhf and ppc64el, one test fails: > > [ ERROR ] Test 292 failed at esorex_json-test.c:808: > |cpl_parameter_get_default_double(param8) - > cpl_parameter_get_default_double(parsed_param8)| = |4.4 - 6.36599e-314| > = |4.4| <= 2.22045e-16 = DBL_EPSILON. > [ ERROR ] No error(s) to dump > [ ERROR ] Test 293 failed at esorex_json-test.c:808: > (cpl_parameter_get_enum_size(param8)) = 3; > (cpl_parameter_get_enum_size(parsed_param8)) = 1. > [ ERROR ] No error(s) to dump > [ ERROR ] Test 294 failed at esorex_json-test.c:808: > |cpl_parameter_get_enum_double(param8, n) - > cpl_parameter_get_enum_double(parsed_param8, n)| = |1.1 - 1.97626e-323| > = |1.1| <= 2.22045e-16 = DBL_EPSILON. > [ ERROR ] No error(s) to dump > [ ERROR ] Test 295 failed at esorex_json-test.c:808: > |cpl_parameter_get_enum_double(param8, n) - > cpl_parameter_get_enum_double(parsed_param8, n)| = |2.2 - 2.73737e-312| > = |2.2| <= 2.22045e-16 = DBL_EPSILON. > [ ERROR ] No error(s) to dump > [ ERROR ] Test 296 failed at esorex_json-test.c:808: > |cpl_parameter_get_enum_double(param8, n) - > cpl_parameter_get_enum_double(parsed_param8, n)| = |4.4 - 1.25873e+93| = > |-1.25873e+93| <= 2.22045e-16 = DBL_EPSILON. > [ ERROR ] No error(s) to dump > [ ERROR ] 5 of 617 test(s) failed > > This happens with libffi as well as with libavcall. I will disable those > tests, but they basically mean that Python recipes cannot be used with > CPL on those platforms. This is actually the same issue than the riscv64 one (#934081). Now that the patch has been applied, these tests can be re-enabled on armhf and ppc64el. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#936129: Bug #936129: apr-util: Python2 removal in sid/bullseye
It looks that src:apr-util does not have python code itself, while it makes use of gen-build.py from libapr1-dev (src:apr). So that once #936128 is closed, apr-util can move to python3 by changing the build-dep. Regards, Aron
Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7
Hello Jamie Heilman, I just tried to retrieve some line information from the backtrace. Unfortunately I could not match the addresses with the binary from the debian repository. Was this backtrace by any chance built with a local rebuild of the xserver-xorg-core package? Kind regards, Bernhard
Bug#948841: openpyxl fails almost all its tests
Control: tags -1 + patch fixed by the new upstream, and the removal of Python2, example packaging at https://launchpad.net/ubuntu/+source/openpyxl/3.0.3-0ubuntu2
Bug#936817: Processed: lasso: Python2 removal in sid/bullseye - reopen 936817
> > reopen -1
> Bug #936817 {Done: Frederic Peters } [src:lasso] lasso:
> Python2 removal in sid/bullseye
Indeed it still build depends on python; upstream has patches, I'll
ask for a new release.
Frederic
Bug#949284: RFS: dmagnetic/0.21-1 -- Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dmagnetic" * Package name : dmagnetic Version : 0.21-1 Upstream Author : Thomas Dettbarn det...@dettus.net * URL : https://www.dettus.net/dMagnetic/ * License : BSD-2-Clause * Vcs : None Section : games It builds those binary packages: dmagnetic - Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dmagnetic Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.21-1.dsc Changes since the last upload: * Update to release 0.21. * Some lintian warnings have been removed. * Leftover debugging code was creating files * dMagnetic is capable of reading MS DOS binaries from more games. Regards, Thomas Dettbarn
Bug#949278: libreoffice hangs at startup if ~/.libreoffice folder does not exist
tag 949278 + moreinfo tag 949278 + unreproducible thanks On Sun, Jan 19, 2020 at 10:00:37AM +0100, Pierre Bernhardt wrote: > after removing my .libreoffice directory it will not startup fully any more. > The splash screen is shown ever and than it hangs as long I press Ctrl-C to > abort. > > I found a workaround by manually recreating simply the .libreoffice folder. > > I can reproduce the problem each time I remove or rename the .libreoffice > folder. That's impossible. That would mean that it always hanged on a new install where .libreoffice (actually that one doesn't exist, you mean .config/libreoffice) doesn't exist. Which does not happen. Do you have some broken network config? I.e. a broken "lo" (loopback) interface? Regards, Rene
Bug#949290: fix build with libffi 3.3
Package: src:polyml
Version: 5.7.1-2
Severity: important
Tags: sid bullseye patch
The following patch is needed to build with libffi 3.3 in experimental.
* Fix build with libffi 3.3.
diff -Nru polyml-5.7.1/debian/patches/libffi33.diff polyml-5.7.1/debian/patches/libffi33.diff
--- polyml-5.7.1/debian/patches/libffi33.diff 1970-01-01 01:00:00.0 +0100
+++ polyml-5.7.1/debian/patches/libffi33.diff 2020-01-13 10:28:21.0 +0100
@@ -0,0 +1,12 @@
+--- a/libpolyml/polyffi.cpp
b/libpolyml/polyffi.cpp
+@@ -108,6 +108,9 @@ static struct _abiTable { const char *ab
+ {"ms_cdecl", FFI_MS_CDECL},
+ #elif defined(X86_WIN64)
+ {"win64", FFI_WIN64},
++#elif defined (X86_64) || (defined (__x86_64__) && defined (X86_DARWIN))
++{"sysv", FFI_UNIX64},
++{"unix64", FFI_UNIX64},
+ #elif defined(X86_ANY)
+ {"sysv", FFI_SYSV},
+ {"unix64", FFI_UNIX64},
diff -Nru polyml-5.7.1/debian/patches/series polyml-5.7.1/debian/patches/series
--- polyml-5.7.1/debian/patches/series 2018-06-30 15:31:25.0 +0200
+++ polyml-5.7.1/debian/patches/series 2020-01-13 10:27:23.0 +0100
@@ -1,3 +1,4 @@
modules-non-executable.patch
riscv-support.patch
riscv-libffi.patch
+libffi33.diff
Bug#949289: bugs.debian.org: No wifi and no sound after suspend
Package: bugs.debian.org Severity: normal Dear Maintainer, Since a recent update in january WiFi and sound do no longer recover from suspend (after closing and opening laptop lid). Keyboard, touchpad and screen seem to be ok, but shutdown and restart (gnomeshell) are broken as well. No reaction. The laptop has to be restarted by hard power off. This never happened before. Hardware: HP Elitebook G 840 I haven't found a workaroud yet. Looks like the resume from suspend is broken, as more than a single function is affected. Wolf-Dieter -- System Information: Debian Release: 9.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-11-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)
Bug#949288: fix to build with libffi 3.3
Package: src:ecl
Version: 16.1.3+ds-2
Severity: important
Tags: sid bullseye patch
The following patch is needed to build with libffi 3.3 in experimental.
* Fix build with libffi 3.3.
diff -Nru ecl-16.1.3+ds/debian/patches/libffi-fix.diff ecl-16.1.3+ds/debian/patches/libffi-fix.diff
--- ecl-16.1.3+ds/debian/patches/libffi-fix.diff 1970-01-01 01:00:00.0 +0100
+++ ecl-16.1.3+ds/debian/patches/libffi-fix.diff 2020-01-13 10:49:30.0 +0100
@@ -0,0 +1,18 @@
+--- a/src/c/ffi.d
b/src/c/ffi.d
+@@ -132,10 +132,13 @@ static struct {
+ {@':stdcall', FFI_STDCALL},
+ #elif defined(X86_WIN64)
+ {@':win64', FFI_WIN64},
+-#elif defined(X86_ANY) || defined(X86) || defined(X86_64)
++#elif defined(X86_64)
++ {@':unix64', FFI_UNIX64},
++ {@':cdecl', FFI_UNIX64},
++ {@':sysv', FFI_UNIX64},
++#elif defined(X86_ANY) || defined(X86)
+ {@':cdecl', FFI_SYSV},
+ {@':sysv', FFI_SYSV},
+- {@':unix64', FFI_UNIX64},
+ #endif
+ };
+
diff -Nru ecl-16.1.3+ds/debian/patches/series ecl-16.1.3+ds/debian/patches/series
--- ecl-16.1.3+ds/debian/patches/series 2019-01-16 12:19:19.0 +0100
+++ ecl-16.1.3+ds/debian/patches/series 2019-11-27 18:25:06.0 +0100
@@ -2,3 +2,4 @@
patch-hurd.patch
format-security.patch
no-embedded-copies.patch
+libffi-fix.diff
Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2
Well, libxcrypt1 is not installed on my system. Only libcrypt1 is. Le 18/01/2020 à 23:55, Marco d'Itri a écrit : On Jan 07, Guillaume Brocker wrote: janv. 06 11:10:46 sigismund sshd[27148]: /usr/sbin/sshd: /lib/i386-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/sbin/sshd) Does purging libxcrypt1 make it work? If you can confirm this then I will make the next libcrypt1 conflict with it. I did not expect for libxcrypt1 to be still around since it was not shipped in buster and nobody really ever used it.
Bug#938743: ufo-core: Python2 removal in sid/bullseye - reopen 938743
Maybe this is due to this picca@cush:~/Debian/ufo-core/ufo-core/bin$ rgrep python * ufo-mkfilter.in:#!/usr/bin/python ufo-prof:#!/usr/bin/env python I will replace python -> python3 and see what is going on
Bug#949185: transition: libffi
Control: forwarded -1 https://release.debian.org/transitions/html/auto-libffi.html Control: tags -1 + moreinfo On Fri, 17 Jan 2020 at 23:33, Matthias Klose wrote: > libffi is finally released. There are two packages needing patches: > > ecl > polyml Please file bugs for these.
Bug#949278: libreoffice hangs at startup if ~/.libreoffice folder does not exist
Package: libreoffice Version: 1:6.1.5-3+deb10u5 Severity: important Dear Maintainer, after removing my .libreoffice directory it will not startup fully any more. The splash screen is shown ever and than it hangs as long I press Ctrl-C to abort. I found a workaround by manually recreating simply the .libreoffice folder. I can reproduce the problem each time I remove or rename the .libreoffice folder. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libreoffice depends on: ii libreoffice-avmedia-backend-gstreamer 1:6.1.5-3+deb10u5 ii libreoffice-base 1:6.1.5-3+deb10u5 ii libreoffice-calc 1:6.1.5-3+deb10u5 ii libreoffice-core 1:6.1.5-3+deb10u5 ii libreoffice-draw 1:6.1.5-3+deb10u5 ii libreoffice-impress1:6.1.5-3+deb10u5 ii libreoffice-math 1:6.1.5-3+deb10u5 ii libreoffice-report-builder-bin 1:6.1.5-3+deb10u5 ii libreoffice-writer 1:6.1.5-3+deb10u5 ii python3-uno1:6.1.5-3+deb10u5 Versions of packages libreoffice recommends: pn fonts-crosextra-caladea pn fonts-crosextra-carlito ii fonts-dejavu2.37-1 ii fonts-liberation1:1.07.4-9 pn fonts-liberation2 pn fonts-linuxlibertine ii fonts-noto-core 20181227-1 pn fonts-noto-mono ii fonts-noto-ui-core 20181227-1 ii fonts-sil-gentium-basic 1.102-1 ii libreoffice-java-common 1:6.1.5-3+deb10u5 pn libreoffice-librelogo pn libreoffice-nlpsolver ii libreoffice-report-builder 1:6.1.5-3+deb10u5 ii libreoffice-script-provider-bsh 1:6.1.5-3+deb10u5 ii libreoffice-script-provider-js 1:6.1.5-3+deb10u5 ii libreoffice-script-provider-python 1:6.1.5-3+deb10u5 ii libreoffice-sdbc-postgresql 1:6.1.5-3+deb10u5 pn libreoffice-wiki-publisher Versions of packages libreoffice suggests: ii cups-bsd2.2.10-6+deb10u1 ii default-jre [java6-runtime] 2:1.11-71 ii firefox-esr 68.4.1esr-1~deb10u1 ii ghostscript 9.27~dfsg-2+deb10u3 ii gnupg 2.2.12-1+deb10u1 ii gpa 0.10.0-1 ii gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2 ii gstreamer1.0-plugins-bad1.14.4-1+b1 ii gstreamer1.0-plugins-base 1.14.4-2 ii gstreamer1.0-plugins-good 1.14.4-1 ii gstreamer1.0-plugins-ugly 1.14.4-1 ii hunspell-de-de-frami [hunspell-dictionary] 1:6.2.0-1 ii hyphen-de [hyphen-hyphenation-patterns] 1:6.2.0-1 ii imagemagick 8:6.9.10.23+dfsg-2.1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1 ii libgl1 1.1.0-1 pn libreoffice-gnome | libreoffice-kde5 pn libreoffice-grammarcheck ii libreoffice-help-de [libreoffice-help] 1:6.1.5-3+deb10u5 ii libreoffice-l10n-de [libreoffice-l10n] 1:6.1.5-3+deb10u5 ii libreoffice-officebean 1:6.1.5-3+deb10u5 ii libsane 1.0.27-3.2 ii libxrender1 1:0.9.10-1 ii myspell-en-us [myspell-dictionary] 1:3.3.0-4+deb8u1 ii mythes-de [mythes-thesaurus]20160424-3 ii openclipart-libreoffice 1:0.18+dfsg-15 ii openjdk-11-jre [java6-runtime] 11.0.5+10-1~deb10u1 ii openjdk-8-jre [java6-runtime] 8u232-b09-1~deb9u1 ii pstoedit3.73-1+b1 ii sun-java6-jre [java6-runtime] 6.26-0squeeze1 ii thunderbird 1:68.4.1-1~deb10u1 ii unixodbc2.3.6-0.1 Versions of packages libreoffice-core depends on: ii fontconfig2.13.1-2 ii fonts-opensymbol 2:102.10+LibO6.1.5-3+deb10u5 ii libboost-date-time1.67.0 1.67.0-13 ii libboost-locale1.67.0 1.67.0-13 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libclucene-contribs1v52.3.3.4+dfsg-1 ii libclucene-core1v52.3.3.4+dfsg-1 ii libcmis-0.5-5v5 0.5.2-1 ii libcups2 2.2.10-6+deb10u1 ii
Bug#943096: libreoffice-dictionaries: Python2 removal in sid/bullseye - reopen 943096
Control: severity -1 minor On Sat, Jan 18, 2020 at 09:58:15PM -0500, Sandro Tosi wrote: > This bug was closed, but the package has still some dependencies towards > Python2 packages, in details: > > (binary:libreoffice-lightproof-pt-br)Depends->python-uno That's an alternate dependency: Depends: python3-uno (>= 4.0) | python-uno does it really matter? Going to remove anyway, but... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#947834: stretch-pu: package cups/2.2.1-8+deb9u5
Le samedi, 18 janvier 2020, 21.06:29 h CET Adam D. Barratt a écrit : > Control: tags -1 + confirmed > > On Tue, 2019-12-31 at 14:33 +0100, Didier 'OdyX' Raboud wrote: > > cups (2.2.1-8+deb9u5) stretch; urgency=medium > > > > * Backport upstream security fixes: > > - Fix memory leak in ppdOpen (Closes: #946941) > > - CVE-2019-2228: The `ippSetValuetag` function did not validate > > > > the > > > > default language value (Closes: #946782) > > Please go ahead. Uploaded too! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#941557: gri: FTBFS (Malformed UTF-8 character)
On 1/17/20 3:04 PM, Bas Couwenberg wrote: > In preparation of the netcdf transition as test rebuild of your package was > done which FTBFS: > > makeinfo -I. gri.texi > utf8 "\xF3" does not map to Unicode at > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 1796, line 19280. > Malformed UTF-8 character: \xf3\x70\x65\x7a (unexpected non-continuation > byte 0x70, immediately after start byte 0xf3; need 4 bytes, got 1) in pattern > match (m//) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364. > Malformed UTF-8 character (fatal) at > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364. > make[1]: *** [Makefile:975: html] Error 25 The attached patch fixes the issue. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 diff -Nru gri-2.12.26/debian/patches/documentencoding,patch gri-2.12.26/debian/patches/documentencoding,patch --- gri-2.12.26/debian/patches/documentencoding,patch 1970-01-01 01:00:00.0 +0100 +++ gri-2.12.26/debian/patches/documentencoding,patch 2020-01-17 14:56:07.0 +0100 @@ -0,0 +1,13 @@ +Description: Set encoding to ISO-8859-1. + Fixes 'Malformed UTF-8 character' error. +Author: Bas Couwenberg +Bug-Debian: https://bugs.debian.org/941557 + +--- a/doc/gri.texi b/doc/gri.texi +@@ -1,4 +1,5 @@ + \input texinfo ++@documentencoding ISO-8859-1 + + @c + @comment *** Start of HTML stuff *** diff -Nru gri-2.12.26/debian/patches/series gri-2.12.26/debian/patches/series --- gri-2.12.26/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ gri-2.12.26/debian/patches/series 2020-01-17 14:56:07.0 +0100 @@ -0,0 +1 @@ +documentencoding,patch
Bug#949280: breezy fails it's autopkg tests on arm64
Package: src:breezy Version: 3.0.2-1 Severity: serious Tags: sid bullseye See https://ci.debian.net/data/autopkgtest/testing/arm64/b/breezy/4019389/log.gz Tests on Ubuntu are also not passing on armhf, ppc64el and s390x.
Bug#949281: r-bioc-tximport: autopkgtest regression
Source: r-bioc-tximport Version: 1.14.0+dfsg-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Hi Maintainer Since the upload of r-bioc-tximport 1.14.0+dfsg-1, it has been failing its own autopkgtests [1]. I've copied what I hope is the relevant part of the log below. Regards Graham [1] https://ci.debian.net/packages/r/r-bioc-tximport/unstable/amd64/ > library(testthat) > library(tximport) > library(tximportData) Error in library(tximportData) : there is no package called ‘tximportData’ Execution halted autopkgtest [20:51:45]: test run-unit-test: ---] autopkgtest [20:51:45]: test run-unit-test: - - - - - - - - - - results - - - - - - - - - - run-unit-testFAIL non-zero exit status 1
Bug#936924: libsvm: Python2 removal in sid/bullseye - reopen 936924
On 19.01.20 03:23, Sandro Tosi wrote:
> This bug was closed, but the package has still some dependencies towards
> Python2 packages, in details:
>
> (binary:libsvm-tools)Depends->python:any
>
> Re-opening, so that they can be taken care of.
I believe I am missing something; could you expand on this?
I can't find any remnants of Python2 in the package.
In the control file, the binary package only depends on
${python3:Depends}, and this is substituded with
$ grep python3 debian/libsvm-tools.substvars
python3:Depends=python:any
Bug#949264: nageru: FTBFS on arm/i386/mipsel architectures
On Sun, Jan 19, 2020 at 12:50:43AM -0500, Boyuan Yang wrote: > Recent source-only rebuild for nageru has mulitple FTBFS architectures on > buildd: https://buildd.debian.org/status/package.php?p=nageru > > The tail log all reads like this: It looks like the definition of GLsizeiptr is different between the movit and nageru builds: > ./obj-mipsel-linux-gnu/../nageru/timecode_renderer.cpp:51: undefined reference > to `movit::generate_vbo(int, unsigned int, long, void const*)' > /usr/bin/ld: ./obj-mipsel-linux-gnu/../nageru/timecode_renderer.cpp:51: > undefined reference to `movit::generate_vbo(int, unsigned int, long, void > const*)' klump:~/dev/movit> nm --dynamic --demangle /usr/lib/i386-linux-gnu/libmovit.so.8 | grep vbo 0001b9a0 T movit::generate_vbo(int, unsigned int, int, void const*) Is this an ABI break caused by some recent Mesa change, perhaps? I guess one could always rebuild Movit... Seemingly it changed upstream from ptrdiff_t to khronos_ssize_t in Nov 2018, but I don't know if that was the actual break. krhonos_ssize_t is defined as: typedef signed long int khronos_ssize_t; /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#949286: src:dh-python: consider (re-)parsing -O options
Package: src:dh-python Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, It may sometimes be useful to pass options to dh_* tools centrally, in one place, be in the dh invocation in the catch-all "%: dh ..." rule or DH_OPTIONS. dh prepends -O to such options before passing them to dh_* tools it invokes. dh_python* currently ignores such options as they are internally being caught by the "-O" option. Please consider re-parsing the -O options and using those of them dh_python* supports and ignoring the rest. This way it would be possible to pass additional options to dh_python* without adding an override rule. - -- Cheers, Andrej -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl4kMzUUHGFuZHJld3No QGRlYmlhbi5vcmcACgkQXkCM2RzYOdJrPQf/bDf4R/blfuIylVDJi8xxdCQrp0tq KC1UUHM7G1B+9H+QeTnkyNAOBw+HsjixV0bjogaOOhmCUFN1TUbeB8rOT9SVHuhH hOz118x5Wm1JCBqxItBNIu/0KMwSqmBD7JOoqzSwjiIFrqlG4whfVK+dBfgItJjK 31Sk4Ls37z9c/K2phNndKXvTOf9q1Kj6Ercjii06NBkyn4B9elw1hdiO4RMDNVO3 AhWIpp7oa6u2hud0OryBGrF4ylh/In56kChOWdUYShbf/NVBpkrRazOkQyGqk87o jZEc1LXCrllxQBRCmz4YbCq3WWeQ2vh0B0DXlp6NLgf07Ym7C20oIULU/Q== =TLd7 -END PGP SIGNATURE-
Bug#949185: transition: libffi
On 19.01.20 09:40, Graham Inggs wrote: > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-libffi.html > Control: tags -1 + moreinfo > > On Fri, 17 Jan 2020 at 23:33, Matthias Klose wrote: >> libffi is finally released. There are two packages needing patches: >> >> ecl >> polyml > > Please file bugs for these. these are now filed, with patches.
Bug#949132: cdftools: FTBFS (LaTeX Error: File 'infwarerr.sty' not found.)
Source: cdftools Version: 3.0.2-3 Tags: patch Followup-For: Bug #949132 Dear Maintainer, infwarerr.sty is now provided by texlive-latex-recommended. The attached patch fixes the issue. Kind Regards, Bas --- a/debian/control +++ b/debian/control @@ -5,6 +5,7 @@ Build-Depends: debhelper (>= 10), gfortran, texlive-latex-base, + texlive-latex-recommended, libnetcdf-dev, libnetcdff-dev Standards-Version: 4.1.3 Homepage: https://servforge.legi.grenoble-inp.fr/projects/CDFTOOLS
Bug#949276: python-limits: autopkgtest needs update
Source: python-limits Version: 1.3-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: needs-update Hi Maintainer The autopkgtests of python-limits started to fail some time around 2018-10-20 [1]. I've copied what I hope is the relevant part of the log below. Regards Graham [1] https://ci.debian.net/packages/p/python-limits/unstable/amd64/ WARNING: redis-trib.rb is not longer available! You should use redis-cli instead. All commands and features belonging to redis-trib.rb have been moved to redis-cli. In order to use them you should call redis-cli with the --cluster option followed by the subcommand name, arguments and options.
Bug#949279: r-cran-devtools: autopkgtest regression
Source: r-cran-devtools
Version: 2.2.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of r-cran-devtools 2.2.1-1, it has been failing its
own autopkgtests [1].
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/packages/r/r-cran-devtools/unstable/amd64/
> test_check("devtools")
-- 1. Error: reload works (@test-reload.R#4) --
Can't find `tests/testthat` in current directory.
1: as.package(test_path("testTest")) at testthat/test-reload.R:4
2: is.package(x)
3: test_path("testTest")
4: stop("Can't find `tests/testthat` in current directory.", call. = FALSE)
--- re-building 'test.Rmd' using knitr
--- finished re-building 'test.Rmd'
Bug#949283: RM: ppx-core -- ROM; deprecated by upstream
Package: ftp.debian.org Severity: normal Dear FTP Masters, Please remove ppx-core from unstable. It is deprecated upstream [1] (in favour of ppxlib) and no longer has reverse-dependencies. [1] https://github.com/janestreet-deprecated/ppx_core Cheers, -- Stéphane
Bug#926637: util-linux: rename.ul is not installed as a possible alternative for the "rename" command
Control: tags -1 + wontfix Control: tags -1 - a11y On Mon, Apr 08, 2019 at 12:14:24PM +0200, Patrick Zanon wrote: > Package: util-linux > Version: 2.33.1-0.1 > Severity: normal > Tags: patch a11y > > Dear Maintainer, > > the rename.ul, which is into the package, is not listed among the possible > alternatives for the "rename" command, like - for example - prename or > file-rename. Thus the command is reacheable only by calling it with its > real name (rename.ul) rather than calling it through the "rename" command. The util-linux rename command does not implement the same (command line) interface as the alternative(s) does, so it is not policy compliant to add it as an alternative. The expression part is different in the util-linux implementation from other implementations. There's thus no use trying to claim the implementations can be used interchangably (even though it might happen work for some trivial usage). > > The situation could be solved by adding the following line in the script > called during the configuration step: > > update-alternatives --install /usr/bin/rename rename /usr/bin/rename.ul 100 \ > --slave /usr/share/man/man1/rename.1.gz rename.1.gz > /usr/share/man/man1/rename.ul.1.gz Things might be more complicated than this because util-linux is an 'Essential: yes' package. More details in debian-policy. Regards, Andreas Henriksson
Bug#949291: psi4: Missing dependency to python3-qcelemental
Package: psi4 Version: 1:1.3.2-2 Severity: grave Justification: renders package unusable Dear Maintainer, when importing psi4 from ipython after installing the package, I am greated with the output ``` --- ModuleNotFoundError Traceback (most recent call last) in () > 1 import psi4 /usr/lib/x86_64-linux-gnu/psi4/__init__.py in () 80 81 # Make official plugins accessible in input ---> 82 from .driver import endorsed_plugins 83 84 # Manage threads. Must be after endorsed plugins, honestly. /usr/lib/x86_64-linux-gnu/psi4/driver/__init__.py in () 31 from . import dependency_check 32 ---> 33 from qcelemental import constants 34 from psi4.driver import psifiles as psif 35 ModuleNotFoundError: No module named 'qcelemental' ``` indicating that a dependency of `psi4` to `python3-qcelemental` is missing in in unstable. Best Michael Herbst -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages psi4 depends on: ii libatlas3-base [liblapack.so.3]3.10.3-9 ii libblas3 [libblas.so.3]3.9.0-1 ii libc6 2.29-7 ii libchemps2-3 1.8.9-1+b2 ii libgcc11:9.2.1-22 ii libgg2 2.0.4-1 ii libgomp1 9.2.1-22 ii libint11.2.1-2 ii liblapack3 [liblapack.so.3]3.9.0-1 ii libopenblas0-pthread [liblapack.so.3] 0.3.7+ds-7 ii libstdc++6 9.2.1-22 ii libxc5 4.3.4-1 ii psi4-data 1:1.3.2-2 ii python33.7.5-3 ii python3-deepdiff 3.3.0-1 ii python3-networkx 2.4-3 ii python3-numpy 1:1.17.4-5 ii python3-pybind11 2.4.3-2 psi4 recommends no packages. psi4 suggests no packages. -- no debconf information
Bug#949292: RM: ruby-aws-sdk-core -- ROM; duplicated source packages in unstable
Package: ftp.debian.org Severity: normal Hi, As a member of ruby team I request the removal of ruby-aws-sdk-core. Please remove src:ruby-aws-sdk-core:3.67.0-1 from "unstable" (ant their binary package). Is a duplicate of src:ruby-aws-sdk:1.67.0-2, and src:ruby-aws-sdk:2.9.32-2 that will enter experimental and latter testing, updated and providing the correct update path. The package is maintained by Debian Ruby Extras Maintainers. Regards -- David
Bug#862101: RM: fontmatrix -- RoQA; RC-buggy, uninstallable in sid/stretch, orphaned, mostly dead upstream
On May 8, 2017, at 15:54, David Bremner wrote: > > Package: ftp.debian.org > Severity: normal > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > - - The package is currently uninstallable most places because it needs > a rebuild against newer libicu > > - - Gurkan tried a quick rebuild and it fails. just wanted to comment here reopen was wrong unarchive right meanwhile it was ported to qt5. my plan is to reintroduce the package > > - - There seems to be no committed upstream; I talked to Alexander > Prokoudine, and he said "I apply PRs about once a year"; the > original developer is MIA. > > - - The package has several other RC bugs. no more > > - - The listed maintainer is inactive > > - - I chatted with Gurkan (the remaining uploader) on IRC and we agreed > the best course is to remove the package for now. > > Of course if someone wants to step up to maintain the package, feel > free to close this bug. me > > -BEGIN PGP SIGNATURE- > > iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlkQd+gACgkQ8gKXHaSn > nixDoQwAhQC4Cr+2CflTu3dqiV6Vz53EvZMuLh8a17Wpi6hD4kv8lmT+DyJBmwaT > kUC/vbk5dgAQyIv/M3yq3SXrlucVvg3x2K6X//s8qRITBeBgNKfqZjC8VXbvbkUY > 2Zx8nylT6jpCGU4VSfdXzLgFZGn1EJNoWJt+3KqouAMSTIzab4H90jZKl/xH6gfW > KTweYrUeMymWfiwdVJ68JOBdMo81EZBs74XMSlkvmYjSpFngE4JJvprPIuRCJOgD > sDybxl9wDnml4SBW5KqzdS9vvB88O780JCHnEAXAP56wNzB5y5Vbessf43o13qyx > p0A1QxgWRTL6ehrGRz+9NWX9/7BDdh//CFCmgppzLiF+QZv1r70hgOrZ4NfB7/Zg > bdI3gwhIyJZ/dlgOHpNztG9gqIhLvVi5LbY7Jcqi+eNSscz2KxWC04tfjFKNoerD > 5YI8a1zPbJRqOOeO2r0PFaWR0tabv9hf+gWrPSdd+BwrFLfH8f/EsQ0WbsyEdKVC > lLmBpVeY > =bPdQ > -END PGP SIGNATURE- >
Bug#949260: security-tracker: add cvedetails.com to Source?
On Sunday, 19 January 2020 9:38:39 PM AEDT Salvatore Bonaccorso wrote: > Tend to agree in the above, but Dmitry, what value would you see in > having cvedetails listed as well for additional sources? Is there more > information available which would additionally help in tracking CVEs? Nothing major really... It is just the layout looks readable to me and I've thought that since we have multiple (more or less) redundant sources of information, adding one more link won't hurt... I would be happy to withdraw my suggestion unless somebody seconds it... Thanks. -- Regards, Dmitry Smirnov. --- "For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.
Bug#948953: RM: ruby-aws-partitions -- ROM; duplicated source packages in unstable
Control: tags -1 - moreinfo Control: block -1 by 949292 thanks Hi, Blocked by #948953. As soon as #948953 is closed, the RM could be done. Thanks, On 19/1/20 0:58, Scott Kitterman wrote: On Wed, 15 Jan 2020 10:09:04 +0100 David Suarez wrote: Package: ftp.debian.org Severity: normal Hi, As a member of ruby team I request the removal of ruby-aws-partitions. Please remove src:ruby-aws-partitions:1.211.0-1 from "unstable" (ant their binary package). Is a duplicate of src:ruby-aws-sdk:1.67.0-2, and src:ruby-aws-sdk:2.9.32-2 that will enter experimental and latter testing, updated and providing the correct update path. The package is maintained by Debian Ruby Extras Maintainers. There is a dependency issue that needs to be addressed first: Checking reverse dependencies... # Broken Depends: ruby-aws-sdk-core: ruby-aws-sdk-core # Broken Build-Depends: ruby-aws-sdk-core: ruby-aws-partitions (>= 1.0) Dependency problem found. Please remove the moreinfo tag once that has been addressed. Scott K
Bug#949160: netbase: removal of isakmp/udp has some bad effects
On Jan 17, Christoph Anton Mitterer wrote: > It's rather the TCP version which should be removed (but this should be > thoroughly checked Indeed, this was my mistake. > People may actually use these and since they likely don't read the changelog > and there is > no NEWS.Debian which would mention it (and which one can users expect to > read) pretty bad > things can happen. Then they will open a bug and I will fix it. No big deal, we call this "unstable" for a reason. -- ciao, Marco signature.asc Description: PGP signature
Bug#881175: src:debhelper: overrides are not run in parallel
Control: tags -1 wontfix On Wed, 08 Nov 2017 15:14:15 +0100 Ximin Luo wrote: > Package: src:debhelper > Version: 10.10.5 > Severity: normal > > Dear Maintainer, > > override rules are not run in parallel: > > $ cat debian/rules > #!/usr/bin/make -f > %: > dh $@ --parallel > override_dh_auto_configure: s1 s2 s3 s4 > s1 s2 s3 s4: > sleep 4 > .PHONY: s1 s2 s3 s4 > > [...] > > X > > [...] Hi, This is correct - unfortunately, some early internal design choices in debhelper does not support running arbitrary dh_* commands in parallel. A concrete example would be two dh_* commands that both add autoscript snippets (e.g. postinst); like so: dh_installinit & dh_installsystemd & This sequence is open to a race condition where the two commands may step on each other's work when they add autoscript snippets. As mentioned, this is a fundamental design issue and it affects more operations than the example listed here. Therefore, solving this would involve a complete redesign of debhelper and the entire debhelper ecosystem (including third-party dh tools and add-ons). I do not think this is a good trade-off at the moment and I am tagging it wontfix as I will not have time to work on it. That said, debhelper could do with a co-maintainer and I open to helping an aspiring co-maintainer fix this bug (caveat emptor: it is a major undertaking). Thanks, ~Niels
Bug#948372: Please push your changes to nibabel
On Sun, 19 Jan 2020, Andreas Tille wrote: > Hi Yaroslav, > can you please push your latest changes to nibabel? I'd volunteer > to fix #948372 and when doing so move the repository to Debian Med > if you do not mind. actually as far as I see it Sando has pushed everything for 2.5.1-2 https://salsa.debian.org/neurodebian-team/nibabel/blob/dist/debian/proper/debian/changelog which is the latest AFAIK PS I have changed the default branch on salsa to dist/debian/proper to match the one we used as one of our utopian plans to stay organized for different distributions/releases ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#943683: RM: hgsvn/0.1.8-1.1
retitle -1 RM: hgsvn -- ROM; not maintained upstream, not usable with current mercurial and subversion On Mon, 28 Oct 2019 00:22:29 +0100 Vincent Danjean wrote: > Hi, > > Can you remove this package from unstable ? It is > completly buggy in oldstable (see #907494), not > present in stable and testing, not maintained > upstream anymore and not usable with current > versions of mercurial and subversion (see last > message in #907494). > > Regards, > Vincent Hi, Somehow this removal request has not progressed even though the FTP team are otherwise keeping up with the influx of "RM" bugs (kudos to the FTP masters for doing that!). I'll retitle according to directions at https://ftp-master.debian.org/removals.html. -- Juhani
Bug#949317: plasma-workspace should Replace (or Conflict) plasma-desktop and plasma-desktop-data << 5.17
tag 949317 + pending thanks Hi, In data domenica 19 gennaio 2020 20:26:55 CET, Antonio Russo ha scritto: > Package: plasma-workspace > Version: 4:5.17.5-1 > Severity: normal > > During an upgrade from testing (4:5.14.5.1-5+b1) to experimental, > plasma-workspace > tries to overwrite files in plasma-desktop and plasma-desktop data. Thanks, fixed in the packaging repository, and it will be part of the next upload. PS: considering there will be more issues like this, please report them to the debian-kde mailing list for now. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#949323: fwknop-server: does not wait for network-online so fails to start in pcap mode
Package: fwknop-server Version: 2.6.10-2 Severity: important Dear Maintainer, Thank you for packaging fwknop for Debian. The systemd service file for fwknop-server is missing a Wants directive: Wants=network-online.target <-- missing After=network-online.target Per the systemd documentation[1], both Wants and After are required when using the network-online.target. Without the Wants directive, fwknop-server, in PCAP mode, fails to start because the interface is not ready. Thanks, Luca [1]: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-7-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwknop-server depends on: ii init-system-helpers 1.56+nmu1 ii iptables 1.8.2-4 ii libc62.28-10 ii libfko3 2.6.10-2 ii libpcap0.8 1.8.1-6 ii lsb-base 10.2019051400 fwknop-server recommends no packages. Versions of packages fwknop-server suggests: ii fwknop-apparmor-profile 2.6.10-2
Bug#949322: python-pysaml2: CVE-2020-5390
Source: python-pysaml2 Version: 4.5.0-5 Severity: grave Tags: security upstream Justification: user security hole Control: found -1 4.5.0-4 Hi, The following vulnerability was published for python-pysaml2. CVE-2020-5390[0]: | PySAML2 before 5.0.0 does not check that the signature in a SAML | document is enveloped and thus signature wrapping is effective, i.e., | it is affected by XML Signature Wrapping (XSW). The signature | information and the node/object that is signed can be in different | places and thus the signature verification will succeed, but the wrong | data will be used. This specifically affects the verification of | assertion that have been signed. 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-2020-5390 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5390 [1] https://github.com/IdentityPython/pysaml2/commit/5e9d5acbcd8ae45c4e736ac521fd2df5b1c62e25 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#949318: systemsettings should Replace (or Conflict) kde-config-systemd << 5.17
In data domenica 19 gennaio 2020 20:30:18 CET, Antonio Russo ha scritto: > Package: systemsettings > Version: 4:5.17.5-1 > Severity: normal > > During an upgrade from testing (4:5.14.5.1-5+b1) to experimental, > systemsettings > tries to overwrite files in kde-config-systemd. The conflict is due to the following file: /usr/share/kservices5/settings-system-administration.desktop (hint: please mention all the conflicting files when reporting this kind of bugs, or at least paste an English output of apt/aptitude/etc) Basically System Settings "adopted" the System Administration category that so far was introduced only with kde-config-systemd. The fix will be removing that file in kde-config-systemd, and adding proper breaks/replaces in systemsettings with the right version of kde-config-systemd that removes the file. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#945722: pinot: Python2 removal in sid/bullseye - reopen 945722
On Sat, Jan 18, 2020 at 09:58:15PM -0500, Sandro Tosi wrote: > This bug was closed, but the package has still some dependencies towards > Python2 packages, in details: > > (binary:pinot)Recommends->python-docutils > > Re-opening, so that they can be taken care of. The dependency is actually: Recommends: [...] python3-docutils | python-docutils [...] This really doesn't seem to justify RC severity to me. Cheers, Olly
Bug#949227: This was fixed
Hi, I tried rebuilding the package, and it looks like the latest upload fixed the issue (I could build the package without any problem). If you believe I'm wrong, please reopen and let me know. Cheers, Thomas Goirand (zigo)
Bug#948207: Fixed in 19.12.2...
On 19/01/2020 21:25, Eric Valette wrote: The Google block will be fixed with kaccounts-providers 19.12.2. --eric Fix is here: https://cgit.kde.org/kaccounts-providers.git/patch/?id=f26e97cfc9308bcc70a3b0b29a5fd9a4b9c42da2 --eric
Bug#945722: pinot: Python2 removal in sid/bullseye - reopen 945722
On Sun, Jan 19, 2020 at 3:19 PM Olly Betts wrote: > > On Sat, Jan 18, 2020 at 09:58:15PM -0500, Sandro Tosi wrote: > > This bug was closed, but the package has still some dependencies towards > > Python2 packages, in details: > > > > (binary:pinot)Recommends->python-docutils > > > > Re-opening, so that they can be taken care of. > > The dependency is actually: > > Recommends: [...] python3-docutils | python-docutils [...] > > This really doesn't seem to justify RC severity to me. nor there's any reason, technical or otherwise, to have such a dependencies; my script isnt perfect, and didnt properly detect the alternative dependencies not in primary position, but let's all look at the bigger picture of the py2removal effort and avoid useless packages relationships. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#949324: groff: embeds path to grep and bash when built on usrmerge system
On Sun, Jan 19, 2020 at 12:10:51PM -0800, Vagrant Cascadian wrote: > When groff is built on a system with /usr merged, the paths to bash and > grep get embedded in various files (/usr/bin/gdiffmk and some example > documentation), resulting in an unreproducible build. > > The attached patch passes BASH_PROG=/bin/bash and GREP=/bin/grep, which > is compatible with both a usrmerge and non-usrmerge system. Thanks; I committed a slight variant of this. -- Colin Watson [cjwat...@debian.org]
Bug#949329: flatbuffers: Needs rebuild to migrate to testing
Source: flatbuffers Version: 1.11.0+dfsg1-1 Severity: serious Hi, The package needs a source-only upload to let it be rebuilt and only then can it migrate to testing. I've already added the fixes needed [1] for the rebuild to the packaging repository on Salsa. Cheers, Balint [1] https://salsa.debian.org/debian/flatbuffers/commits/debian/master
Bug#743650: Pssible fix
I added: XTerm*VT100.color3: #707000 to ~/.Xresources to try to fix this. The result is a horrible olive colour on my screen, but at least it's now visible. (The default yellow colour for X is #00 which is fine against a dark background, but almost invisible against white). -- Dr Peter Chubb Tel: +61 2 9490 5852 http://ts.data61.csiro.au/ Trustworthy Systems GroupCSIRO's Data61
Bug#948207: Fixed in 19.12.2...
Hi Eric, Eric Valette writes: > On 19/01/2020 21:25, Eric Valette wrote: >> The Google block will be fixed with kaccounts-providers 19.12.2. >> >> >> --eric > Fix is here: > > https://cgit.kde.org/kaccounts-providers.git/patch/?id=f26e97cfc9308bcc70a3b0b29a5fd9a4b9c42da2 > > --eric This is documented at Bug #948853, against kaccounts-providers. To any team members reading this: please do not close this kio-gdrive bug unless a buster update for kaccounts-providers is uploaded and resolves the issue in stable. I expect that buster is affected and anticipate that a user with a new buster installation will file a "me too" update to this bug sometime in the next six months. Thanks, Nicholas signature.asc Description: PGP signature
Bug#940660: elpa-elpy: add Suggests: python3-rope to refactor code
P.S. I recently read that `elpy-refactor` will use Black if it's installed, but this is currently undocumented, and our upstream contact is currently very busy so it might be a while. I'm also occupied with meeting an end-of-month deadline. signature.asc Description: PGP signature
Bug#949299: coinor-vol misses source for configure
Looks like I misread the bug report and thought it to be the same as missing source for NEW upload. I will check about the source for the configure script. -- Regards Sudip
Bug#949317: plasma-workspace should Replace (or Conflict) plasma-desktop and plasma-desktop-data << 5.17
Package: plasma-workspace Version: 4:5.17.5-1 Severity: normal During an upgrade from testing (4:5.14.5.1-5+b1) to experimental, plasma-workspace tries to overwrite files in plasma-desktop and plasma-desktop data.
Bug#949321: RFS: coinor-vol/1.5.4-2 [QA] -- Coin-or linear programming solver (libraries)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "coinor-vol" * Package name: coinor-vol Version : 1.5.4-2 Upstream Author : Francisco Barahona, Laszlo Ladanyi. * URL : https://projects.coin-or.org/Vol * License : EPL-1 * Vcs : https://salsa.debian.org/debian/coinor-vol Section : science It builds those binary packages: coinor-libvol1 - Coin-or linear programming solver (libraries) coinor-libvol-dev - Coin-or linear programming solver (development files) coinor-libvol-doc - Coin-or linear programming solver To access further information about this package, please visit the following URL: https://mentors.debian.net/package/coinor-vol Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/coinor-vol/coinor-vol_1.5.4-2.dsc Changes since the last upload: * QA upload. * make separate short desciption. * Upload source. (Closes: #949299) -- Regards Sudip
Bug#949321: RFS: coinor-vol/1.5.4-2 [QA] -- Coin-or linear programming solver (libraries)
On Sun, Jan 19, 2020 at 08:00:28PM +, Sudip Mukherjee wrote: > * Package name: coinor-vol >Version : 1.5.4-2 > Changes since the last upload: > >* QA upload. >* make separate short desciption. >* Upload source. (Closes: #949299) Hi! The debdiff from 1.5.4-1 shows only short desc changes, with nothing related to configure sources. Have you perhaps forgotten to add that? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#949294: solfege: help file not found
Hello Charles, thanks for your bug report! You should install the solfege-doc package to get the html files that are referenced by the help link. I agree that if the documentation package is not installed then the 404 html error is not informative. A better behavior would be to display a nice error pop-up to indicate what to do. In addition, the solfege package does not Recommends the solfege-doc package, which violates the debian policy [1]. I'll try to upload a new package to fix these errors. In the meantime you should install the solfege-doc package to resume your work. Have a nice day, François [1] https://www.debian.org/doc/debian-policy/ch-docs.html#additional-documentation signature.asc Description: This is a digitally signed message part
Bug#949328: ITP: fcitx5-chinese-addons -- Pinyin and table input method for fcitx5
Package: wnpp Severity: wishlist Owner: Boyuan Yang X-Debbugs-CC: debian-de...@lists.debian.org * Package name: fcitx5-chinese-addons Version : 0.0~git20200117.4261e23 Upstream Author : Weng Xuetian * URL : https://github.com/fcitx/fcitx5-chinese-addons * License : LGPL-2.1+ Programming Lang: C++ Description : Pinyin and table input method for fcitx5 Fcitx5 is the next generation of fcitx input method framework. It provides plasant and modern input experience with intuitive graphical configuration tools. The framework is highly extensible with support for GTK+ and Qt toolkits, DBus interfaces, a large variety of desktop environments and a developer-friendly API. . This package provides Chinese-related addons for fcitx5, including builtin pinyin and table input methods. It will be maintained under Debian Input Method Team. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#949330: evolution: Google OAuth forces use of internal browser without way to change URL
Source: evolution Version: 3.34.1-2+b1 Severity: important At work, I use a Google Apps service with a single sign-on provider. As a result, I need to use a browser to authenticate to Google so I can use OAuth2. In addition, our company uses Duo Mobile, which restricts access to users with up-to-date software. The version of WebKit which is used is viewed as a too-old version of Safari on macOS[0], and therefore authentication is not permitted. I can actually work around this issue by copying and pasting the URL into Firefox, but I cannot then paste the URL from the sign-in flow back into the URL bar in the internal browser, so I'm stuck and cannot log in. The Google OAuth2 flow, when run in Firefox, does provide me a token I can paste back in, but Evolution cannot accept that token in place of the login flow. In order to be able to use Evolution with Google's OAuth2 flow, I need one of the following to happen: 1. Evolution reports itself as a recent, modern (e.g., patched macOS Catalina-equivalent) version of Safari and continues to update this value. 2. Evolution allows using an external browser, such as Firefox, to log in for OAuth2 flows. 3. Evolution allows pasting into the URL bar so I can paste the proper URL in from Firefox (assuming it otherwise supports doing that). 4. Evolution allows pasting in the token from Google I can use in Firefox instead. [0] Not updating the user-agent appears to be a deliberate decision in WebKit2GTK because "User Agent sniffing is…terrible…." I agree, but I don't make the decisions here. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#949331: fwknop-server: consider building with nfq support
Package: fwknop-server Version: 2.6.10-2 Severity: wishlist Dear Maintainer, Please consider building fwknopd with both pcap and nfq support so that system administrators may elect to use nfq over pcap if their kernel supports it (which Debian stock kernels do). Thanks, Luca -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-7-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwknop-server depends on: ii init-system-helpers 1.56+nmu1 ii iptables 1.8.2-4 ii libc62.28-10 ii libfko3 2.6.10-2 ii libpcap0.8 1.8.1-6 ii lsb-base 10.2019051400 fwknop-server recommends no packages. Versions of packages fwknop-server suggests: ii fwknop-apparmor-profile 2.6.10-2
Bug#909740: libsdl2-dev: No longer multi-arch co-installable
Hi Hugh, On 10.12.19 23:18, Hugh McMaster wrote: At this point, I don’t see anything preventing us from adding the extra include path, although I’m going to do some tests builds of various SDL2-based programs to be certain. Neverball could also be patched to call pkg-config with SDL2_ttf, which, IIRC, has both include paths already (since SDL2_ttf requires SDL2). Unfortunately, this won’t resolve the broader problem. I've pushed this change to the git repo: https://salsa.debian.org/sdl-team/libsdl2/commit/6f58f10282cf9b9af567ec520f0d2c4dc368dbea Did you have time to test-build some reverse-dependencies of SDL2? Cheers, Felix
Bug#949332: fwknop-apparmor-profile: consider adding ipset to apparmor profile
Package: fwknop-apparmor-profile
Version: 2.6.10-2
Severity: wishlist
Dear Maintainer,
One of the interesting modes of operation of fwknop-server is the use of
CMD_CYCLE_OPEN / CMD_CYCLE_CLOSE to call ipset to add entries to a set.
Pedantic sytem administrators may find that automatic insertion of
chains to be irksome and prefer to create/use an ipset in their firewall
configurations.
Since the documented[1][2] mode of operation provides an example that
uses ipset, please consider adding ipset to the apparmor profile.
Thanks,
Luca
[1]: https://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#spa-with-ipset
[2]:
https://www.cipherdyne.org/blog/2015/12/single-packet-authorization-and-third-party-devices.html
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable'), (90, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-7-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fwknop-apparmor-profile depends on:
ii fwknop-server 2.6.10-2
fwknop-apparmor-profile recommends no packages.
fwknop-apparmor-profile suggests no packages.
-- Configuration Files:
/etc/apparmor.d/usr.sbin.fwknopd changed:
/usr/sbin/fwknopd {
#include
capability ipc_lock,
capability net_admin,
capability net_raw,
network inet raw,
network inet dgram,
network inet6 dgram,
network packet raw,
network packet dgram,
/bin/dash rix,
/bin/bash rix,
/etc/fwknop/access.conf r,
/etc/fwknop/fwknopd.conf r,
/etc/nsswitch.conf r,
/etc/passwd r,
/etc/protocols r,
@{PROC}/@{pid}/net/ip_tables_names r,
/root/.gnupg/* rwkl,
/run/fwknop/ rw,
/run/fwknop/* rwk,
/run/xtables.lock rwk,
/sbin/ipset rix,
/sbin/xtables-multi rix,
/usr/bin/gpg rix,
/usr/sbin/fwknopd mr,
/usr/sbin/ipset rix,
/usr/sbin/xtables-nft-multi rix,
/var/cache/nscd/passwd r,
}
-- no debconf information
Bug#949100: [Pkg-clamav-devel] Bug#949100: clamav: loses link against libxml2 with 2.9.10 (uses xml2-config)
On 2020-01-16 23:03:21 [+0100], Mattia Rizzolo wrote: > your package is using `xml2-config` to detect and use libxml2. I'm > removing that script, so please update your build system to use > pkg-config instead. Thanks for the report. I switched to pkg-config but dunno when I'm going to upload. Please let me know if I should hurry up. Sebastian
Bug#949100: [Pkg-clamav-devel] Bug#949100: clamav: loses link against libxml2 with 2.9.10 (uses xml2-config)
On Sun, Jan 19, 2020 at 11:23:57PM +0100, Sebastian Andrzej Siewior wrote: > On 2020-01-16 23:03:21 [+0100], Mattia Rizzolo wrote: > > your package is using `xml2-config` to detect and use libxml2. I'm > > removing that script, so please update your build system to use > > pkg-config instead. > > Thanks for the report. I switched to pkg-config but dunno when I'm going > to upload. Please let me know if I should hurry up. I'm probably considering to do that upload sometime early februrary, so not too soon. I'll also bump all non-closed bugs to RC around a week before, so that should also give people some kind of notice. Having said that, I'm causing so many bugs that it might even get later, but I definitely want to come back home from SnowCamp[0] with the package in sid already :) Is that alright for you? [0] https://wiki.debian.org/DebianEvents/it/2020/SnowCamp -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#949137: [Python-modules-team] Bug#949137: Please package ipython 7.11.1
Control: block 949287 by 949137 Thanks, I already used it for my tests with sagemath 9.0. The need for ipython 7.11.1 was now also reported as sagemath bug #949287. Thanks for that. Best, Tobias On 1/17/20 3:58 PM, Emmanuel Arias wrote: > Source: ipython > Version: 7.11.0-2 > > Hi Tobias, > > I've just push to salsa the new upstream release. I will need sponsorship. > > Cheers, > Arias Emmanuel > @eamanu > http://eamanu.com > > El vie., 17 de ene. de 2020 a la(s) 07:51, Tobias Hansen > (than...@debian.org) escribió: >> >> Source: ipython >> Version: 7.11.0-2 >> Severity: wishlist >> >> Hi, >> >> ipython 7.11.1 brought back some compatibility functions that are needed for >> sagemath 9.0: >> >> https://github.com/ipython/ipython/commit/9a8d1a345f48b7aa85e6a6da5841b65ee1f8de63#diff-230d8a7c9440fa2ab8c6a3ebe9a9f279 >> >> Could you please update the package? >> >> Best, >> Tobias >> >> ___ >> Python-modules-team mailing list >> python-modules-t...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
Bug#949305: Build system selection is not deterministic
Package: dh-python Version: 4.20191017 Severity: normal Hi, the order in which /usr/bin/pybuild tests the build system plugins depends on the order of files in the directory /usr/share/dh-python/dhpython/build. If two plugins have the same certainty, the first one wins. This non-determinism should be eliminated. See bug 946233 for an example where this shows up. Best regards, Joachim
Bug#949299: coinor-vol misses source for configure
Control: owner -1 ! On Sun, Jan 19, 2020 at 04:26:25PM +0100, Helmut Grohne wrote: > Source: coinor-vol > Version: 1.5.4-1 > Severity: severity > Justification: missing source > > coinor-vol includes a configure script generated using autoconf. The > relevant configure.ac file is included in the source. In Debian, we > generally don't require that things are built from source during package > build, but we do require that everything can be rebuilt using components > from Debian main. Unfortunately, the configure script for coinor-vol > needs to be generated using autoconf2.59 and that version of autoconf > was removed from unstable more than one year ago. I also tried > rebuilding configure with different versions of autoconf without > success. As such, I conclude that coinor-vol lacks the required source > components for regenerating the configure script. Yes, source is still missing. As there was a SONAME version change, so the package name changed and had to go through the NEW queue. I am preparing another upload so that source can be uploaded with it. -- Regards Sudip
Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7
Bernhard Übelacker wrote: > Hello Jamie Heilman, > I just tried to retrieve some line information from the backtrace. > Unfortunately I could not match the addresses with the > binary from the debian repository. > Was this backtrace by any chance built with a local > rebuild of the xserver-xorg-core package? Nope, vanilla amd64 package from the repo, not a rebuild. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#949310: buster-pu: package gnutls28/3.6.7-4+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hello,
there is a regression in gnutls/buster compared to stretch. It fails to
parse certificates using Registered ID in Subject Alternative Name.
See upstream report https://gitlab.com/gnutls/gnutls/issues/905 for more
details.
I would like to fix this in pu, by pulling the fix from GnuTLS 3.6.9.
The respective upstream change also adds a testcase and therefore
adds/modifies binaries. The proposed Debian changes are not
representable as debdiff, I am attaching git-format-patch diff instead.
cu Andreas
From de3d573242195eddab914709584242610b2e2762 Mon Sep 17 00:00:00 2001
From: Andreas Metzler
Date: Sun, 19 Jan 2020 18:00:12 +0100
Subject: [PATCH] Fix parsing of certificates using RegisteredID Closes:
#949293
---
debian/binary/cert10.der | Bin 0 -> 571 bytes
debian/binary/cert5.der | Bin 0 -> 414 bytes
debian/changelog | 6 +
...ralname-registeredID-from-RFC-5280-i.patch | 242 ++
debian/patches/series | 1 +
debian/rules | 8 +
debian/source/include-binaries| 2 +
7 files changed, 259 insertions(+)
create mode 100644 debian/binary/cert10.der
create mode 100644 debian/binary/cert5.der
create mode 100644 debian/patches/41_rel3.6.9_01-Support-for-Generalname-registeredID-from-RFC-5280-i.patch
diff --git a/debian/binary/cert10.der b/debian/binary/cert10.der
new file mode 100644
index ..07ab16d3eec034bd14cd94dd0174a2a76c768918
GIT binary patch
literal 571
zcmXqLVlp>qV!XS6nTe5!i7~~1i;Y98~}r=h5UFdK6y3o{Rod$6ygLP%`WXB7yE<
z2fL4n5$aH8Ms{W=1{U9cSH5JrPuwpy_1pr3D$^|zjMJuCRBw;2RdL_8Rbf7h>pH)<
zAeoC69oOR@)U-AzX+7fIwMMr5Y?*=QWGCtCmWvy28Z=%rkOx{StIQ%{Al4xA)v;*r
Bug#946100: [Python-modules-team] Bug#946100: close 946100
Ooops, you are right, sorry. I modified d/changelog accordingly. Cheers! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#949315: cups-filters: driverless generates wrong InputSlots
Package: cups-filters Version: 1.21.6-5 Severity: important When I use "driverless" to generate a PPD for my Xerox B215 printer, I get definition of InputSlot which does not work. In particular, the printer reports that it supports media source "tray-1". This is translated to "Tray-1" by driverless, so the PPD contains: *InputSlot Tray-1/Tray 1: "" When I submit a print job, CUPS's IPP backend translates this to IPP media source "tray--1", which is later rejected by the printer (the printer replies by a malformed IPP message, but that's another story). The problem lies in the mismatch between name mangling rules in cups-filters-1.21.6/cupsfilters/ppdgenerator.c (the pwg_ppdize_name function) and cups-2.2.10/cups/ppd-cache.c (the pwg_unppdize_name function). It is hard to tell which one is wrong as the name mangling rules seem arbitrary. However, at least one of them needs fixing. I checked cups-filters 1.26.2 and CUPS 2.3.1 and the name mangling functions stay the same, so the problem is probably still present. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-filters depends on: ii bc 1.07.1-2+b1 ii cups-filters-core-drivers 1.21.6-5 ii ghostscript9.27~dfsg-2+deb10u3 ii libc6 2.28-10 ii libcups2 2.2.10-6+deb10u1 ii libcupsfilters11.21.6-5 ii libcupsimage2 2.2.10-6+deb10u1 ii libfontconfig1 2.13.1-2 ii libfontembed1 1.21.6-5 ii libgcc11:8.3.0-6 ii libqpdf21 8.4.0-2 ii libstdc++6 8.3.0-6 ii poppler-utils 0.71.0-5 Versions of packages cups-filters recommends: ii colord 1.4.3-4 ii liblouisutdml-bin 2.7.0-5+b1 Versions of packages cups-filters suggests: ii antiword 0.37-14 pn docx2txt ii foomatic-db 20181217-2 ii imagemagick 8:6.9.10.23+dfsg-2.1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1 -- Configuration Files: /etc/modules-load.d/cups-filters.conf changed [not included] -- no debconf information
Bug#949316: parted: please cherry-pick ChromeOS Kernel partition flag
Source: parted Version: 3.3-1 Severity: wishlist Tags: fixed-upstream d-i Dear Maintainer, The firmware/bootloader in ChromeOS machines only attempts to boot from partitions of a certain GPT partition type. Please cherry-pick my commit 08256913c307e0313ee014e0f292fa335cc18f1d from upstream [1], which adds support for it. I've managed to get debian-installer working on my chromebook and I'm trying to upstream my changes. Part of that work is enabling partman to create these partitions (see my partman-cros [2]), which requires libparted2-udeb to understand this flag, so I've added the 'd-i' tag. [1] https://git.savannah.gnu.org/cgit/parted.git/commit/?id=08256913c307e0313ee014e0f292fa335cc18f1d [2] https://salsa.debian.org/alpernebbi-guest/partman-cros -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.4.0-2-arm64 (SMP w/6 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#949318: systemsettings should Replace (or Conflict) kde-config-systemd << 5.17
Package: systemsettings Version: 4:5.17.5-1 Severity: normal During an upgrade from testing (4:5.14.5.1-5+b1) to experimental, systemsettings tries to overwrite files in kde-config-systemd.
Bug#949319: ITS: tolua++
Source: tolua++ Severity: important Version: 1.0.93-3 X-Debbugs-CC: vch...@debian.org Hi Vincent, After looking into a package you maintain in Debian (tolua++, https://tracker.debian.org/pkg/tolua++), I found that this package received no update since 2012 and is not in good shape. As a result, I am filing an ITS (Intent to Salvage) request against your package according to section 5.12 in Debian Developers' Reference. [1] Please let me know if you are still willing to maintain this package. According to the criteria listed at [2], I will upload a Non-maintainer Upload (NMU) of tolua++ onto DELAYED/7 after 21 days (Feb. 09, 2020) to continue with the package salvaging. If it's necessary to pause the ITS process, please let me know immediately by replying this bug report. Thank you for your previous work on tolua++ and looking forward to your reply. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://wiki.debian.org/PackageSalvaging -- Best Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#946169: acpi-override: diff for NMU version 0.1+nmu1
Control: tags 946169 + patch Control: tags 946169 + pending Dear maintainer, I've prepared an NMU for acpi-override (versioned as 0.1+nmu1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards. diff -Nru acpi-override-0.1/debian/changelog acpi-override- 0.1+nmu1/debian/changelog --- acpi-override-0.1/debian/changelog 2019-10-31 15:32:35.0 -0400 +++ acpi-override-0.1+nmu1/debian/changelog 2020-01-19 14:27:02.0 -0500 @@ -1,3 +1,11 @@ +acpi-override (0.1+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * No-change source-only upload to allow testing migration. +(Closes: #946169) + + -- Boyuan Yang Sun, 19 Jan 2020 14:27:02 -0500 + acpi-override (0.1) unstable; urgency=medium * Upload to debian. signature.asc Description: This is a digitally signed message part
Bug#945722: pinot: diff for NMU version 1.05-4.1
Control: tags 945722 + patch
Dear maintainer,
I've prepared an NMU for pinot (versioned as 1.05-4.1). The diff
is attached to this message.
Regards.
diff -Nru pinot-1.05/debian/changelog pinot-1.05/debian/changelog
--- pinot-1.05/debian/changelog 2019-11-27 20:16:46.0 -0500
+++ pinot-1.05/debian/changelog 2020-01-19 14:45:31.0 -0500
@@ -1,3 +1,10 @@
+pinot (1.05-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop unnecessary alternative Recommends on python-docutils; Closes: #945722
+
+ -- Sandro Tosi Sun, 19 Jan 2020 14:45:31 -0500
+
pinot (1.05-4) unstable; urgency=medium
* debian/control: Update to recommending python3-docutils | python-docutils
diff -Nru pinot-1.05/debian/control pinot-1.05/debian/control
--- pinot-1.05/debian/control 2019-11-27 20:16:43.0 -0500
+++ pinot-1.05/debian/control 2020-01-19 14:45:04.0 -0500
@@ -37,7 +37,7 @@
Depends: default-dbus-session-bus | dbus-session-bus,
${misc:Depends},
${shlibs:Depends}
-Recommends: antiword, catdoc, catdvi, djvulibre-bin, poppler-utils, unrtf, unzip, python3-docutils | python-docutils, bzip2
+Recommends: antiword, catdoc, catdvi, djvulibre-bin, poppler-utils, unrtf, unzip, python3-docutils, bzip2
Suggests: file, rpm
Description: meta-search engine for local files and web queries
Pinot provides a D-Bus service that crawls, indexes your documents and
Bug#949320: man-db: produces kernel warnings attempting to write a file in /tmp
Package: man-db Version: 2.9.0-2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, * What led up to the situation? Attempting to convert nroff source to HTML using 'man -Thtml' invocation. * What was the outcome of this action? The following message was written to the kernel log. Output of dmesg follows: [Jan18 13:00] audit: type=1400 audit(1579461095.803:24): apparmor="DENIED" operation="file_inherit" profile="man_groff" name="/tmp/groff-regions-NiehKf" pid=58336 comm="troff" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 * What outcome did you expect instead? No such message. On my Buster Gnome desktop I kept getting pop-ups from App Armor and found bug 945909 and resolved the issue of reading /etc/papersize by manually applying the included patc. However, these messages are also being generated on the Buster desktop as well as this laptop running Bullseye. - - Nate - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages man-db depends on: ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.73 ii dpkg 1.19.7 ii groff-base 1.22.4-4 ii libc6 2.29-7 ii libgdbm6 1.18.1-5 ii libpipeline1 1.5.2-2 ii libseccomp22.4.2-2 ii zlib1g 1:1.2.11.dfsg-1+b1 man-db recommends no packages. Versions of packages man-db suggests: ii apparmor2.13.3-7 ii chromium [www-browser] 76.0.3809.100-1 ii epiphany-browser [www-browser] 3.34.1-1+b1 ii firefox-esr [www-browser] 68.4.1esr-1 ii groff 1.22.4-4 ii less551-1 ii lynx [www-browser] 2.9.0dev.4-1 - -- debconf information: man-db/auto-update: true man-db/install-setuid: false -BEGIN PGP SIGNATURE- iGsEARECACsWIQSC1k9rDmfNQfaJu6b7LFEw1VqIGQUCXiSuow0cbjBuYkBuMG5i LnVzAAoJEPssUTDVWogZV0sAn07hvI2Wg4eKpewuXY6oU+oRMM5CAJ418HkPPWpP NUxeo0a8zWUjEnFBQw== =rKIm -END PGP SIGNATURE-
Bug#949324: groff: embeds path to grep and bash when built on usrmerge system
Source: groff Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: usrmerge environment X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org When groff is built on a system with /usr merged, the paths to bash and grep get embedded in various files (/usr/bin/gdiffmk and some example documentation), resulting in an unreproducible build. The attached patch passes BASH_PROG=/bin/bash and GREP=/bin/grep, which is compatible with both a usrmerge and non-usrmerge system. live well, vagrant From 3daefd47779ff0c1bdaf23a023f313127cc19f84 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 19 Jan 2020 11:37:53 -0800 Subject: [PATCH] debian/rules: Pass BASH_PROG and GREP to configure to ensure reproducible builds regardless of weather system is a usrmerge or non-usrmerge system. --- debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 4562bd67..27d4be2a 100755 --- a/debian/rules +++ b/debian/rules @@ -47,7 +47,7 @@ override_dh_autoreconf: override_dh_auto_configure: -rm -f config.log config.cache - $(buildflags) dh_auto_configure -- $(confflags) + $(buildflags) dh_auto_configure -- $(confflags) BASH_PROG=/bin/bash GREP=/bin/grep ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) $(buildflags_native) dh_auto_configure \ --builddirectory=debian/build-native -- \ -- 2.20.1 signature.asc Description: PGP signature
Bug#949325: libmysofa: CVE-2020-6860
Source: libmysofa Version: 0.9.1~dfsg0-1 Severity: important Tags: security upstream Forwarded: https://github.com/hoene/libmysofa/issues/96 Hi, The following vulnerability was published for libmysofa. CVE-2020-6860[0]: | libmysofa 0.9.1 has a stack-based buffer overflow in readDataVar in | hdf/dataobject.c during the reading of a header message attribute. 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-2020-6860 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6860 [1] https://github.com/hoene/libmysofa/issues/96 [2] https://github.com/hoene/libmysofa/commit/c31120a4ddfe3fc705cfdd74da7e884e1866da85 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#933631: Looks like fixed
On 1/17/20 6:35 PM, Gianfranco Costamagna wrote: > control: reopen -1 > > On Wed, 8 Jan 2020 10:17:23 +0100 Thomas Goirand wrote: >> I'm closing this bug. Feel free to reopen if there's still a problem. >> > > sorry for the late answer! > > https://ci.debian.net/packages/k/kazoo/unstable/amd64/ > > looks like something is missing or not working properly on autopkgtests > environments. > It might be a restriction that sbuild doesn't have, or something different in > your testing and the autopkgtest testing. > > I'm not talking about a "build" issue but an "autopkgtest" issue. (something > related to "debian/tests" directory). > > Trying to launch the test on a pbuilder environment shows the issue, as well > as sbuild. > > Please let me know if something is still not clear, > > Gianfranco Hi, I believe I fixed this with the latest upload. Please check. Cheers, Thomas Goirand (zigo)
