Bug#950001: Upgrade libxkbcommon to upstream 0.10.0
Package: src:libxkbcommon
Version: 0.9.1-1
Dear Maintainer,
The libxkbcommon has a new upstream release 0.10.0. It has several improvements
and fixes, like the capability of utilizing per-user configuration, and the use
of includes in the rule files.
Full changelog:
> libxkbcommon 0.10.0 - 2020-01-18
> ===
>
> - (security) Fix quadratic complexity in the XKB file parser. See commit
> message 7c42945e04a2107827a057245298dedc0475cc88 for details.
>
> - Add $XDG_CONFIG_HOME/xkb to the default search path. If $XDG_CONFIG_HOME
> is not set, $HOME/.config/xkb is used. If $HOME is not set, the path is not
> added.
>
> The XDG path is looked up before the existing default search path
> $HOME/.xkb.
>
> Contributed by Peter Hutterer <@who-t.net>.
>
> - Add support for include statements in XKB rules files.
>
> This is a step towards making local XKB customizations more tenable and
> convenient, without modifying system files.
>
> You can now include other rules files like this:
>
> ! include %S/evdev
>
> Two directives are supported, %H to $HOME and %S for the system-installed
> rules directory (usually /usr/share/X11/xkb/rules).
>
> See commit message ca033a29d2ca910fd17b1ae287cb420205bdddc8 and
> doc/rules-format.txt in the xkbcommon source code for more information.
>
> Contributed by Peter Hutterer <@who-t.net>.
>
> - Downgrade "Symbol added to modifier map for multiple modifiers" log to a
> warning.
>
> This error message was too annoying to be shown by default. When working on
> keymaps, set `XKB_LOG_LEVEL=debug XKB_LOG_VERBOSITY=10` to see all possible
> messages.
>
> - Support building on Windows using the meson MSVC backend.
>
> Contributed by Adrian Perez de Castro <@igalia.com>.
>
> - Fix bug where the merge mode only applied to the first vmod in a
> `virtual_modifiers` statement. Given
>
> augment virtual_modifiers NumLock,Alt,LevelThree
>
> Previously it was incorrectly treated as
>
> augment virtual_modifiers NumLock;
> virtual_modifiers Alt;
> virtual_modifiers LevelThree;
>
> Now it is treated as
>
> augment virtual_modifiers NumLock;
> augment virtual_modifiers Alt;
> augment virtual_modifiers LevelThree;
>
> - Reject interpret modifier predicate with more than one value. Given
>
> interpret ISO_Level3_Shift+AnyOf(all,extraneous) { ... };
>
> Previously, extraneous (and further) was ignored. Now it's rejected.
>
> - Correctly handle capitalization of the ssharp keysym.
>
> - Speed up and improve the internal `xkeyboard-config` tool. This tool
> compiles all layout/variant combinations in the xkeyboard-config dataset
> and reports any issues it finds.
>
> Contributed by Peter Hutterer <@who-t.net>.
>
> - Speed up "atoms" (string interning). This code goes back at least to X11R1
> (released 1987).
-- Iiro Laiho
Bug#941617: stretch-pu: package publicsuffix/20190925.1705-0+deb9u1
Control: tags -1 + confirmed On 2019-10-02 22:29, Daniel Kahn Gillmor wrote: Apologies for the delay in getting back to you on this, but please feel free to upload. Regards, Adam
Bug#950003: ITP: ppx-fields-conv -- generation of accessor and iteration functions for OCaml records
Package: wnpp Severity: wishlist Owner: Stéphane Glondu * Package name: ppx-fields-conv Version : 0.13.0 Upstream Author : Jane Street Group, LLC * URL : https://github.com/janestreet/ppx_fields_conv * License : MIT Programming Lang: OCaml Description : generation of accessor and iteration functions for OCaml records ppx_fields_conv is a ppx rewriter that can be used to define first class values representing record fields, and additional routines, to get and set record fields, iterate and fold over all fields of a record and create new record values. This package is a new dependency of sexplib310. Il will be maintained in the OCaml team.
Bug#944282: stretch-pu: monit 1:5.20.0-6+deb9u1
Control: tags -1 + confirmed On 2019-11-07 08:49, Sergey B Kirpichev wrote: I would like to make an upload to stable in order to fix bug #941895 (CSRF check) in the monit package. Please go ahead; sorry for the delay. Regards, Adam
Bug#940477: stretch-pu: package tmpreaper/1.6.13+nmu1+deb9u2
Control: tags -1 + confirmed On 2019-09-16 10:29, Thijs Kinkhorst wrote: tmpreaper will clean up PrivateTmp dirs of processes that systemd started, leading to those services periodically crashing (and it's usually hard to diagnose that tmpreaper was the culprit here). This update adds those dirs to tmpreapers' whitelist. Please go ahead; sorry for the delay. Regards, Adam
Bug#944228: stretch-pu: package phpmyadmin/4:4.6.6-4+deb9u1
Control: tags -1 + confirmed On 2019-11-12 01:24, Matthias Blümel wrote: phpmyadmin 4.9.1+dfsg1-2 is now in unstable which fixes these issues Thanks. Please go ahead. Regards, Adam
Bug#950002: ITP: ppx-custom-printf -- printf-style format-strings for user-defined string conversion
Package: wnpp Severity: wishlist Owner: Stéphane Glondu * Package name: ppx-custom-printf Version : 0.13.0 Upstream Author : Jane Street Group, LLC * URL : https://github.com/janestreet/ppx_custom_printf * License : MIT Programming Lang: OCaml Description : printf-style format-strings for user-defined string conversion ppx_custom_printf is a ppx rewriter that allows the use of user-defined string conversion functions in format strings (that is, strings passed to printf, sprintf, etc.). . No new syntax is introduced. Instead a previously ill-typed use of the ! operator is re-purposed. This package is a new dependency of sexplib310. Il will be maintained in the OCaml team.
Bug#948649: stretch-pu: package libjaxen-java/1.1.6-1+deb9u1
Control: tags -1 + confirmed On 2020-01-11 10:11, Adrian Bunk wrote: https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/libjaxen-java.html * Ignore the test failures (Closes: #909216) Backport of the workaround in buster. Please go ahead. Regards, Adam
Bug#948715: stretch-pu: package xml-security-c/1.7.3-4+deb9u1
Control: tags -1 + confirmed On 2020-01-12 14:39, Ferenc Wágner wrote: +xml-security-c (1.7.3-4+deb9u2) stretch; urgency=medium + + * [12dd825] New patches: DSA verification crashes OpenSSL on invalid +combinations of key content. +Particular KeyInfo combinations result in incomplete DSA key structures +that OpenSSL can't handle without crashing. In the case of Shibboleth +SP software this manifests as a crash in the shibd daemon. Exploitation +is believed to be possible only in deployments employing the PKIX trust +engine, which is generally recommended against. +The upstream patches backported from 2.0.2 apply analogous safeguards to +the RSA and ECDSA key handling as well. Please go ahead. Regards, Adam
Bug#949900: stretch-pu: package libperl4-corelibs-perl/0.003-2+deb9u1
Control: tags -1 + confirmed On 2020-01-26 20:40, Adrian Bunk wrote: * Add t/timelocal.t fix for Y2K20 problem in t/timelocal.t. (Closes: #948666) Please go ahead. Regards, Adam
Bug#948653: stretch-pu: package mod-gnutls/0.8.2-3+deb9u1
Control: tags -1 + confirmed On 2020-01-11 10:34, Adrian Bunk wrote: * Avoid deprecated ciphersuites in test suite (Closes: #907008) FTBFS, tests were broken by gnutls28 3.5.8-5+deb9u4. Please go ahead. Regards, Adam
Bug#950004: ITP: ppx-variants-conv -- generation of accessor and iteration functions for OCaml variant types
Package: wnpp Severity: wishlist Owner: Stéphane Glondu * Package name: ppx-variants-conv Version : 0.13.0 Upstream Author : Jane Street Group, LLC * URL : https://github.com/janestreet/ppx_variants_conv * License : MIT Programming Lang: OCaml Description : generation of accessor and iteration functions for OCaml variant types ppx_variants_conv is a ppx rewriter that can be used to define first class values representing variant constructors, and additional routines to fold, iterate and map over all constructors of a variant type. This package is a new dependency of sexplib310. It will be maintained in the OCaml team.
Bug#949909: stretch-pu: package libparse-win32registry-perl/1.0-2+deb9u1
Control: tags -1 + confirmed On 2020-01-26 21:40, Adrian Bunk wrote: * Add patch to fix Y2K20 problem. (Closes: #948682) Please go ahead. Regards, ADam
Bug#949907: stretch-pu: package libtimedate-perl/2.3000-2+deb9u1
Control: tags -1 + confirmed On 2020-01-26 21:22, Adrian Bunk wrote: * Add patch from upstream pull request to fix Y2K20 test failure. (Closes: #948680) Please go ahead. Regards, Adam
Bug#949905: stretch-pu: package libole-storage-lite-perl/0.19-1+deb9u1
Control: tags -1 + confirmed On 2020-01-26 21:09, Adrian Bunk wrote: * Backport upstream fix for years >= 2020 being misinterpreted. (Closes: #948668) Please go ahead. Regards, Adam
Bug#950005: qemu-system-ppc64: Program exception in Open Firmware
Package: qemu-system-ppc
Version: 1:4.2-1
Severity: important
Dear Maintainer,
It's currently impossible to boot a PPC64 image with QEMU 4.2 in Bullseye as
apparently Open Firmware crashes on launch:
$ qemu-system-ppc64 -serial stdio
qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-
cfpc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-
sbbc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-
ibs=workaround
SLOF **
QEMU Starting
Build Date = Dec 28 2018 13:55:34
FW Version = buildd@ release 20180702
Press "s" to enter Open Firmware.
Populating /vdevice methods
Populating /vdevice/vty@7100
Populating /vdevice/nvram@7101
Populating /vdevice/l-lan@7102
Populating /vdevice/v-scsi@7103
( 700 ) Program Exception [ 0 ]
R0 .. R7 R8 .. R15 R16 .. R23 R24 .. R31
1dbf0b34 1dc64028 0006
1e67ffe0 1e47c010 1e759592 1e680050
1dc26700 1dc64020 1dc64038 1dc1c500
1e758e20 1fbc0df0 1dbf4770 1dc20f58
1dc21398 0003
1dc21128 f001
8000 1e680060
1dc64030 1e743623 f003
CR / XER LR / CTR SRR0 / SRR1DAR / DSISR
8402 1dbf0b34
2004 8008
5 >
This also happens with qemu-system-ppc64le. The warnings can be avoided by
using "-M pseries-3.1" but this has no effect on the crash.
Best regards
Björn Herwig
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-3-amd64 (SMP w/48 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 qemu-system-ppc depends on:
ii libaio1 0.3.112-5
ii libasound2 1.2.1.2-2
ii libbluetooth3 5.50-1+b1
ii libbrlapi0.76.0+dfsg-4+b1
ii libc6 2.29-9
ii libcacard0 1:2.6.1-1
ii libcapstone34.0.1+really+3.0.5-1+b1
ii libepoxy0 1.5.4-1
ii libfdt1 1.5.1-1
ii libgbm1 19.3.2-1
ii libgcc1 1:9.2.1-22
ii libglib2.0-02.62.4-1
ii libgnutls30 3.6.11.1-2
ii libibverbs1 27.0-2
ii libjpeg62-turbo 1:1.5.2-2+b1
ii libncursesw66.1+20191019-1
ii libnettle7 3.5.1+really3.5.1-2
ii libnuma12.0.12-1+b1
ii libpixman-1-0 0.36.0-1
ii libpng16-16 1.6.37-1
ii librdmacm1 27.0-2
ii libsasl2-2 2.1.27+dfsg-2
ii libseccomp2 2.4.2-2
ii libslirp0 4.1.0-2
ii libspice-server10.14.2-4
ii libtinfo6 6.1+20191019-1
ii libusb-1.0-02:1.0.23-2
ii libusbredirparser1 0.8.0-1+b1
ii libvdeplug2 2.3.2+r586-2.2+b1
ii libvirglrenderer1 0.8.1-6
ii openbios-ppc1.1.git20181001-1
ii openhackware0.4.1+git-20140423.c559da7c-4.1
ii qemu-slof 20180702+dfsg-1
ii qemu-system-common 1:4.2-1
ii qemu-system-data1:4.2-1
ii zlib1g 1:1.2.11.dfsg-1+b1
Versions of packages qemu-system-ppc recommends:
ii ipxe-qemu1.0.0+git-20190125.36a4c85-4
ii qemu-system-gui 1:4.2-1
ii qemu-utils 1:4.2-1
ii seabios 1.13.0-1
Versions of packages qemu-system-ppc suggests:
pn qemu-block-extra
pn samba
pn vde2
-- no debconf information
---
Abonnieren Sie unseren Newsletter und bleiben Sie auf dem Laufenden:
https://www.gdsys.de/newsletter-anmeldung/
Subscribe to our newsletter and stay up to date:
https://www.gdsys.de/newsletter-subscription-int/
---
---
Messehighlights 2020: https://www.gdsys.de/events
Trade fair highlights 2020: https://www.gdsys.de/en/events
---
Besuchen Sie unseren Blog auf | Visit our corporate blog
https://blog.gdsys.de
oder folgen Sie uns auf | or join us at:
Linkedin: https://de.linkedin.com/company/guntermann-&-drunck-gmbh
Twitter: https://twitter.com/#!/gdsys
Facebook: https://www.facebook.com/pages/Guntermann-Drunck-GmbH/318396891518396
YouTube: https://www.yout
Bug#950006: gvfsd continuously tries to create /var/cache/samba
Package: gvfs-daemons Version: 1.38.1-5 Severity: normal According to my syslog, gvfsd keeps trying to mkdir /var/cache/samba, causing "Permission denied" errors. This seems to be a continuation of #831329, which should have been reassigned to gvfs-daemons. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gvfs-daemons depends on: ii gvfs-common 1.38.1-5 ii gvfs-libs 1.38.1-5 ii libbluray2 1:1.1.0-1 ii libc6 2.28-10 ii libglib2.0-02.58.3-2+deb10u2 ii libgudev-1.0-0 232-2 ii libsecret-1-0 0.18.7-1 ii libsystemd0 241-7~deb10u2 ii libudisks2-02.8.1-4 ii lsof4.91+dfsg-1 ii udisks2 2.8.1-4 ii x11-utils 7.7+4 Versions of packages gvfs-daemons recommends: ii dbus 1.12.16-1 ii gvfs 1.38.1-5 Versions of packages gvfs-daemons suggests: ii gvfs-backends 1.38.1-5 -- no debconf information
Bug#950005: Seeing the same as well
Hi,
I was experimenting with 9p last week and thought it was related to that.
But seeing your bug I realize I have seen the same issue:
ubuntu@dradis:~$ virsh start focal-t1 --console
Domain focal-t1 started
Connected to domain focal-t1
Escape character is ^]
Populating /vdevice methods
Populating /vdevice/vty@3000
Populating /vdevice/nvram@7100
Populating /pci@8002000
( 700 ) Program Exception [ 0 ]
R0 .. R7 R8 .. R15 R16 .. R23 R24 .. R31
0dbf0b14 0dc63030 8000
0e67eff0 0e47b010 0e7451bc f003
0dc25e00 0dc63028 0006
0e7592e8 0fbd00c8 0e771373 0dc1bc00
0dc63040 0dc20778
0dbf4750 0003
0dc20bb8 f001
0dc20948
CR / XER LR / CTR SRR0 / SRR1DAR / DSISR
8402 0dbf0b14
2004 80081000
Unless someone else here has an immediate idea IMHO this might be better
reported upstream. There are more PPC people and IBM itself reading the
report.
@Björn - would you mind doing so with a mail to [1]?
If you happen to do so updating this bug here with a link to the discussion
would be great.
[1]: https://lists.nongnu.org/mailman/listinfo/qemu-devel
P.S. similar old bugs with the same signature are [2][3] but those were due
to grub triggering an illegal instruction. I guess we can assume that we
run into an illegal instruction again here, but whyt/details I can't derive
out of the logs.
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1400476
[3]: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1459706
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Bug#950007: firejail-profiles: firefox cannot read standard Debian docs folder /usr/share/doc
Package: firejail-profiles
Version: 0.9.62-2~bpo10+1
Severity: normal
Dear Maintainer,
I regularly use offline docs, but a recent change to the firefox profile has
blocked access to all the docs provided by Debian in /usr/share/doc:
File not found
Firefox can’t find the file at /usr/share/doc/.
Check the file name for capitalization or other typing errors.
Check to see if the file was moved, renamed or deleted.
Or for a specific example:
file:///usr/share/doc/python3.7/html/library/collections.html#collections.OrderedDict
File not found
Firefox can’t find the file at
/usr/share/doc/python3.7/html/library/collections.html#collections.OrderedDict.
Check the file name for capitalization or other typing errors.
Check to see if the file was moved, renamed or deleted.
~ $ ls -ld /usr/share/doc
drwxr-xr-x 3396 root root 131072 Jän 27 18:09 /usr/share/doc
~ $ ls -ld /usr/share/doc/python3.7/html/library/collections.html
-rw-r--r-- 1 root root 165855 Apr 3 2019
/usr/share/doc/python3.7/html/library/collections.html
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (100,
'proposed-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 firejail-profiles depends on:
ii firejail 0.9.62-2~bpo10+1
firejail-profiles recommends no packages.
firejail-profiles suggests no packages.
-- Configuration Files:
/etc/firejail/firefox.profile changed:
include firefox.local
include globals.local
noblacklist ${HOME}/.cache/mozilla
noblacklist ${HOME}/.mozilla
mkdir ${HOME}/.cache/mozilla/firefox
mkdir ${HOME}/.mozilla
whitelist ${HOME}/.cache/mozilla/firefox
whitelist ${HOME}/.mozilla
whitelist /usr/share/mozilla
whitelist /usr/share/webext
include whitelist-usr-share-common.inc
include firefox-common.profile
/etc/firejail/transmission-daemon.profile changed:
quiet
include transmission-daemon.local
include globals.local
mkdir ${HOME}/.config/transmission-daemon
whitelist ${HOME}/.config/transmission-daemon
whitelist /var/lib/transmission
caps.keep ipc_lock,net_bind_service,setgid,setuid,sys_chroot
private-bin transmission-daemon
private-etc
alternatives,ca-certificates,crypto-policies,nsswitch.conf,pki,resolv.conf,ssl
read-write /var/lib/transmission
writable-var-log
writable-run-user
include transmission-common.profile
-- no debconf information
Bug#949895: buster-pu: package boost1.67/1.67.0-13+deb10u1
Control: tags -1 + confirmed On 2020-01-26 19:38, Adrian Bunk wrote: * Patch undefined behaviour leading to crashing libboost-numpy (closes: #945987). Please go ahead. Regards, Adam
Bug#949906: buster-pu: package libtimedate-perl/2.3000-2+deb10u1
Control: tags -1 + confirmed On 2020-01-26 21:21, Adrian Bunk wrote: * Add patch from upstream pull request to fix Y2K20 test failure. (Closes: #948680) Please go ahead. Regards, Adam
Bug#949899: buster-pu: package libperl4-corelibs-perl/0.004-1+deb10u1
Control: tags -1 + confirmed On 2020-01-26 20:36, Adrian Bunk wrote: * Add t/timelocal.t fix for Y2K20 problem in t/timelocal.t. (Closes: #948666) Please go ahead. Regards, Adam
Bug#949908: buster-pu: package libparse-win32registry-perl/1.0-2+deb10u1
Control: tags -1 + confirmed On 2020-01-26 21:39, Adrian Bunk wrote: * Add patch to fix Y2K20 problem. (Closes: #948682) Please go ahead. Regards, Adam
Bug#949898: buster-pu: package casacore-data-jplde/2007.07.05+ds.1-0+deb10u1
Control: tags -1 + confirmed On 2020-01-26 20:23, Adrian Bunk wrote: * Include tables up to 2040 in the upstream tarball. Closes: #949219 Please go ahead. Regards, Adam
Bug#949904: buster-pu: package libole-storage-lite-perl/0.19-2+deb10u1
Control: tags -1 + confirmed On 2020-01-26 21:04, Adrian Bunk wrote: * Backport upstream fix for years >= 2020 being misinterpreted. (Closes: #948668) Please go ahead. Regards, Adam
Bug#950008: gfan: assertion fails on riscv64
Source: gfan Version: 0.6.2-2 Severity: normal Hi, many of sagemath's doctests in the interface to gfan fail on riscv64 with the following error: gfan_*: src/application.cpp:42: char* tail(char*): Assertion `*p==*m' failed. It looks like the pointer arithmetic in the function tail() in application.cpp does not work like this on riscv64. Unfortunately there are no porterboxes for riscv64 yet, so I can't come up with a minimal example triggering the bug. Best, Tobias
Bug#949994: [debian-mysql] Bug#949994: mysql-5.7: Security fixes from the January 2020 CPU
Thanks. I'm waiting for maintainer access to the source package, and I should be able to finally get all these closed. -- Lars On 28.01.2020 08:20, Salvatore Bonaccorso wrote: Source: mysql-5.7 Version: 5.7.26-1 Severity: grave Tags: security upstream Justification: user security hole Hi See https://www.oracle.com/security-alerts/cpujan2020.html#AppendixMSQL for a list of CVEs affecting src:mysql-5.7. Regards, Salvatore ___ pkg-mysql-maint mailing list pkg-mysql-ma...@alioth-lists.debian.net https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=M-8dedO8w3Vlx9Nb3v_HN_eQTPKU36yJj5mmQmreYMQ&m=alqB5idfnDxLLAZZRzTyPF-_phj0QvZhm6Pp3-PiXx4&s=GnTMOde4S5uaLlMk05fv3wrC7xQppp--bnFjJiJ3vW0&e=
Bug#944282: stretch-pu: monit 1:5.20.0-6+deb9u1
On Tue, Jan 28, 2020 at 08:37:37AM +, Adam D. Barratt wrote: > On 2019-11-07 08:49, Sergey B Kirpichev wrote: > > I would like to make an upload to stable in order to fix bug > > #941895 (CSRF check) in the monit package. > > Please go ahead; sorry for the delay. Thanks, uploaded.
Bug#950010: linux-image-5.4.0-3-amd64: System fan doesn't spin up anymore after suspend/resume
Package: src:linux
Version: 5.4.13-1
Severity: important
After resuming from sleep, my laptop's system fan doesn't spin up
anymore, regardless of system load/temperature. It's capable of working
with passive cooling only, but the least bit of load immediately pushes
the CPU to 80°C and more.
Only solution is rebooting.
Can't say whether the same thing happens in 5.5-rc5 since suspend-to-ram
is broken in that kernel.
-- Package-specific info:
** Version:
Linux version 5.4.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1
20200117 (Debian 9.2.1-24)) #1 SMP Debian 5.4.13-1 (2020-01-19)
** Command line:
BOOT_IMAGE=/vmlinuz-5.4.0-3-amd64 root=/dev/mapper/NESBITT-ROOT ro quiet
** Tainted: OE (12288)
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[ 1979.596397] mce: CPU6: Package temperature/speed normal
[ 1979.596398] mce: CPU4: Core temperature/speed normal
[ 1979.596398] mce: CPU0: Core temperature/speed normal
[ 1979.596399] mce: CPU2: Package temperature/speed normal
[ 1979.596399] mce: CPU7: Package temperature/speed normal
[ 1979.596400] mce: CPU4: Package temperature/speed normal
[ 1979.596401] mce: CPU0: Package temperature/speed normal
[ 2279.602445] mce: CPU7: Core temperature above threshold, cpu clock throttled
(total events = 23581)
[ 2279.602446] mce: CPU3: Core temperature above threshold, cpu clock throttled
(total events = 23581)
[ 2279.602447] mce: CPU4: Package temperature above threshold, cpu clock
throttled (total events = 55099)
[ 2279.602448] mce: CPU5: Package temperature above threshold, cpu clock
throttled (total events = 55099)
[ 2279.602449] mce: CPU0: Package temperature above threshold, cpu clock
throttled (total events = 55099)
[ 2279.602450] mce: CPU1: Package temperature above threshold, cpu clock
throttled (total events = 55099)
[ 2279.602452] mce: CPU6: Package temperature above threshold, cpu clock
throttled (total events = 55099)
[ 2279.602453] mce: CPU2: Package temperature above threshold, cpu clock
throttled (total events = 55099)
[ 2279.602453] mce: CPU3: Package temperature above threshold, cpu clock
throttled (total events = 55099)
[ 2279.602455] mce: CPU7: Package temperature above threshold, cpu clock
throttled (total events = 55099)
[ 2279.610462] mce: CPU3: Core temperature/speed normal
[ 2279.610463] mce: CPU7: Core temperature/speed normal
[ 2279.610464] mce: CPU1: Package temperature/speed normal
[ 2279.610464] mce: CPU4: Package temperature/speed normal
[ 2279.610465] mce: CPU2: Package temperature/speed normal
[ 2279.610466] mce: CPU0: Package temperature/speed normal
[ 2279.610466] mce: CPU5: Package temperature/speed normal
[ 2279.610467] mce: CPU6: Package temperature/speed normal
[ 2279.610467] mce: CPU7: Package temperature/speed normal
[ 2279.610468] mce: CPU3: Package temperature/speed normal
[ 2330.044453] PM: suspend entry (s2idle)
[ 2330.058903] Filesystems sync: 0.014 seconds
[ 2330.059649] (NULL device *): firmware: direct-loading firmware
i915/icl_dmc_ver1_07.bin
[ 2330.059780] (NULL device *): firmware: direct-loading firmware
intel/ibt-19-32-4.ddc
[ 2330.059930] (NULL device *): firmware: direct-loading firmware
iwlwifi-Qu-c0-hr-b0-48.ucode
[ 2330.060126] (NULL device *): firmware: direct-loading firmware
intel/ibt-19-32-4.sfi
[ 2330.060135] (NULL device *): firmware: direct-loading firmware
iwlwifi-Qu-c0-hr-b0-50.ucode
[ 2330.060408] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 2330.062077] OOM killer disabled.
[ 2330.062077] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[ 2330.063460] printk: Suspending console(s) (use no_console_suspend to debug)
[ 2330.068369] wlan0: deauthenticating from aa:db:03:14:80:7c by local choice
(Reason: 3=DEAUTH_LEAVING)
[ 2331.423122] ACPI: EC: interrupt blocked
[ 2333.893013] ACPI: EC: interrupt unblocked
[ 2335.079220] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM
[ 2335.226967] iwlwifi :00:14.3: FW already configured (0) - re-configuring
[ 2335.234651] iwlwifi :00:14.3: BIOS contains WGDS but no WRDS
[ 2335.471736] OOM killer enabled.
[ 2335.471737] Restarting tasks ... done.
[ 2335.496153] PM: suspend exit
[ 2335.673379] userif-2: sent link down event.
[ 2335.673381] userif-2: sent link up event.
[ 2335.991316] PM: suspend entry (s2idle)
[ 2336.002299] Filesystems sync: 0.010 seconds
[ 2336.002742] Freezing user space processes ... (elapsed 0.821 seconds) done.
[ 2336.824365] OOM killer disabled.
[ 2336.824366] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[ 2336.825852] printk: Suspending console(s) (use no_console_suspend to debug)
[ 2337.477791] ACPI: EC: interrupt blocked
[58827.790024] ACPI: EC: interrupt unblocked
[58828.840539] ideapad_laptop: Unknown event: 10
[58828.998404] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM
[58829.646084] iwlwifi :00:14.3: FW already configured (0) - re-configuring
[58
Bug#937061: Python3 Port of ModelBuilder
On Mon, Jan 27, 2020 at 04:50:17PM -0500, Scott Talbert wrote: > On Tue, 3 Dec 2019, Andreas Tille wrote: > > > if someone will show interest by writing an autopkgtest (or would > > provide some test script to prove the functionality which I'd > > volunteer to turn into an autopkgtest) I'd feel slightly motivated > > to package BIP and try my luck with a Python3 port. > > Any objections to RM'ing model-builder? No objection, swamped with other Python3 ports myself. Kind regards Andreas. -- http://fam-tille.de
Bug#950011: RFP: rust-async-trait -- rust Async trait methods
Package: wnpp Severity: wishlist * Package name: rust-async-trait Version : 0.1.22 Upstream Author : David Tolnay * URL : https://github.com/dtolnay/async-trait * License : MIT OR Apache-2.0 Programming Lang: Rust Description : rust Async trait methods
Bug#950012: RFP: rust-procfs -- Rust library for reading the Linux procfs filesystem
Package: wnpp Severity: wishlist * Package name: rust-procfs Version : 0.7.7 Upstream Author : Andrew Chin * URL : https://github.com/eminence/procfs * License : MIT OR Apache-2.0 Programming Lang: Rust Description : Rust library for reading the Linux procfs filesystem
Bug#931255: Orphaning php-horde*
On Sun, 13 Oct 2019 23:32:56 +0200 Mathieu Parent wrote: > Hello, > > FYI, I'm orphaning php-horde-* packages. See: > > https://bugs.debian.org/942282 if nobody objects, i'm going to do a QA-upload to buster/proposed-updates. i've create a PR [2] for the relevant changes fgmasdf IOhannes [2] https://salsa.debian.org/horde-team/php-horde-text-filter/merge_requests/2 signature.asc Description: OpenPGP digital signature
Bug#950013: RFP: rust-tokio-sync -- rust synchronization utilities
Package: wnpp Severity: wishlist * Package name: rust-tokio-sync Version : 0.1.7 Upstream Author : Carl Lerche * URL : https://crates.io/crates/tokio-sync * License : MIT Programming Lang: Rust Description : rust synchronization utilities Maybe this is covered about the tokio+asnyc package? For bandwhich I explicit need tokio+sync.
Bug#950014: RFP: rust-trust-dns-resolver -- library which implements the DNS resolver using the Trust-DNS Proto library
Package: wnpp Severity: wishlist * Package name: rust-trust-dns-resolver Version : 0.19.2 Upstream Author : Benjamin Fry * URL : https://crates.io/crates/trust-dns-resolver * License : MIT/Apache-2.0 Programming Lang: Rust Description : library which implements the DNS resolver using the Trust-DNS Proto library
Bug#950005: This is in fact a src:slof issue/fix
Hi, I wa checking the same issue for Ubuntu and found that an update of slof to the version that is tagged for qemu 4.2 will fix this. Qemu 4.2 tagged slof 20191209 Booting with that fixes the issue. See also => https://bugs.launchpad.net/ubuntu/+source/slof/+bug/1861084 I'll prep an PR for slof on salsa to fix this ... -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#949992: Does not take subprocess down when killed
Le Tue, Jan 28, 2020 at 07:54:45PM +1300, martin f krafft a écrit : > > When run-mailcap is killed (e.g. SIGTERM), the subprocess it spawned > according to mailcap is left alive. This is due to the use of the > system(3perl) call. Quite frankly, I think exec() should be used > instead, as there is no purpose in leaving run-mailcap around. > However, if that is not possible, please make sure that the > subprocesses are killed when run-mailcap is killed. Hi Martin, would you have a chance to test this change on your system and submit a patch ? Have a nice day, -- Charles Plessy Akano, Uruma, Okinawa, Japan
Bug#950015: haskell-hledger-lib: FTBFS on s390x
Source: haskell-hledger-lib Version: 1.14.1-1 Severity: serious Tags: ftbfs Control: affects -1 + src:haskell-hledger Control: affects -1 + src:haskell-hledger-ui Control: affects -1 + src:haskell-hledger-web Hi Maintainer Since the upload of haskell-hledger-lib 1.14.1-1, it has FTBFS on s390x. Apparently timing out during the doctests. ✅ 189 tests passed, no failures! 👍 🎉 Test suite easytests: PASS Test suite logged to: dist-ghc/test/hledger-lib-1.14.1-easytests.log Test suite doctests: RUNNING... E: Build killed with signal TERM after 150 minutes of inactivity Regards Graham
Bug#950016: RFP: rust-pnet -- libpnet provides a cross-platform API for low level networking using Rust
Package: wnpp Severity: wishlist * Package name: rust-pnet Version : 0.25.0 Upstream Author : Robert Clipsham * URL : https://github.com/libpnet/libpnet * License : MIT/Apache-2.0 Programming Lang: Rust Description : libpnet provides a cross-platform API for low level networking using Rust
Bug#950005: This is in fact a src:slof issue/fix
28.01.2020 13:43, Christian Ehrhardt wrote: > Hi, > I wa checking the same issue for Ubuntu and found that an update of slof to > the version that is tagged for qemu 4.2 will fix this. > > Qemu 4.2 tagged slof 20191209 > Booting with that fixes the issue. > See also => https://bugs.launchpad.net/ubuntu/+source/slof/+bug/1861084 Uh. This is one more reason to build as much as possible from the qemu sources. Thank you very much for working on this Christian! /mjt
Bug#950005: Fix in slof MR
This MR contains a fix via the mentioned update to the newer slof version. => https://salsa.debian.org/qemu-team/slof/merge_requests/1 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#950011: [Pkg-rust-maintainers] Bug#950011: RFP: rust-async-trait -- rust Async trait methods
On January 28, 2020 11:30 am, Patrick Matthäi wrote: > Package: wnpp > Severity: wishlist > > * Package name: rust-async-trait > Version : 0.1.22 > Upstream Author : David Tolnay > * URL : https://github.com/dtolnay/async-trait > * License : MIT OR Apache-2.0 > Programming Lang: Rust > Description : rust Async trait methods pushed to debcargo-conf, needs DD upload (and trybuild for autopkgtest). usually we don't open RFP/ITP bugs for library crates. if the series of bugs you filed are to get dependencies of some binary crate packaged, it probably makes sense to open an RFP bug or issue in debcargo-conf for that binary crate. the Rust team will then package the dependencies in batches.
Bug#937061: Python3 Port of ModelBuilder
Fine with me. Em ter, 28 de jan de 2020 08:26, Andreas Tille escreveu: > On Mon, Jan 27, 2020 at 04:50:17PM -0500, Scott Talbert wrote: > > On Tue, 3 Dec 2019, Andreas Tille wrote: > > > > > if someone will show interest by writing an autopkgtest (or would > > > provide some test script to prove the functionality which I'd > > > volunteer to turn into an autopkgtest) I'd feel slightly motivated > > > to package BIP and try my luck with a Python3 port. > > > > Any objections to RM'ing model-builder? > > No objection, swamped with other Python3 ports myself. > > Kind regards > > Andreas. > > -- > http://fam-tille.de >
Bug#950013: [Pkg-rust-maintainers] Bug#950013: RFP: rust-tokio-sync -- rust synchronization utilities
On January 28, 2020 11:38 am, Patrick Matthäi wrote: > Package: wnpp > Severity: wishlist > > * Package name: rust-tokio-sync > Version : 0.1.7 > Upstream Author : Carl Lerche > * URL : https://crates.io/crates/tokio-sync > * License : MIT > Programming Lang: Rust > Description : rust synchronization utilities > > Maybe this is covered about the tokio+asnyc package? For bandwhich I explicit > need tokio+sync. tokio-sync is packaged already. if you need tokio+sync, you need to wait until the tokio transition to 0.2.x has happened[1], it will be provided by librust-tokio+fnv-dev. we'll likely attempt to finalize this MR on Friday at MiniDebCamp in Brussels, but it will take a while to go through NEW even then. 1: https://salsa.debian.org/rust-team/debcargo-conf/merge_requests/73
Bug#950018: buster-pu: package php-horde-text-filter/2.3.5-3
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu The 'php-horde-text-filter' contains a few regular expressions that are incompatible with the libpcre2 as shipped in Debian/buster. These buggy regexps make the popular groupware and webmail solution "horde" unable to render plain-text emails, which makes it pretty useless as a webmail solution. There have been two bug-reports describing the problem: https://bugs.debian.org/931255 (severity: Grave) https://bugs.debian.org/935816 (against php-horde-imp, that exposes the problem but is not the cause) The proposed update of the package fixes the regexps, so horde can again be used on Debian/stretch. horde and all it's packages (php-horde-*) have been orphaned a few months ago. the original maintainer (Mathieu Parent) uploaded a fixed version (new upstream) to unstable a year ago, but did not find the time to do an upload to buster before abandoning the package. the fix itself is pretty trivial, so backporting it was simple enough. i'm currently running a patched version of php-horde-text-filter on my production horde instance. you can find a debdiff attached to this bugreport. please consider this small fix for the next Debian/buster (sub)release. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru php-horde-text-filter-2.3.5/debian/changelog php-horde-text-filter-2.3.5/debian/changelog --- php-horde-text-filter-2.3.5/debian/changelog2018-05-15 09:22:54.0 +0200 +++ php-horde-text-filter-2.3.5/debian/changelog2020-01-28 10:41:46.0 +0100 @@ -1,3 +1,15 @@ +php-horde-text-filter (2.3.5-3+deb10u1) buster; urgency=medium + + * QA upload. + * Mark package as orphaned (See #942282) + + [ IOhannes m zmölnig ] + * Fixed regular-expressions (used e.g. for displaying plain-text mails) +(Closes: #931255, #935816) + * Switched upstream branch in the packaging git on salsa to 'debian-buster' + + -- IOhannes m zmölnig (Debian/GNU) Tue, 28 Jan 2020 10:41:46 +0100 + php-horde-text-filter (2.3.5-3) unstable; urgency=medium * Update Standards-Version to 4.1.4, no change diff -Nru php-horde-text-filter-2.3.5/debian/control php-horde-text-filter-2.3.5/debian/control --- php-horde-text-filter-2.3.5/debian/control 2018-05-15 09:22:54.0 +0200 +++ php-horde-text-filter-2.3.5/debian/control 2020-01-28 10:41:46.0 +0100 @@ -2,7 +2,7 @@ Section: php Priority: optional Maintainer: Horde Maintainers -Uploaders: Mathieu Parent +Uploaders: Debian QA Group Build-Depends: debhelper (>= 11), pkg-php-tools (>= 1.1), pear-horde-channel Standards-Version: 4.1.4 Homepage: http://www.horde.org/ diff -Nru php-horde-text-filter-2.3.5/debian/gbp.conf php-horde-text-filter-2.3.5/debian/gbp.conf --- php-horde-text-filter-2.3.5/debian/gbp.conf 2018-05-15 09:22:54.0 +0200 +++ php-horde-text-filter-2.3.5/debian/gbp.conf 2020-01-28 10:41:46.0 +0100 @@ -1,7 +1,7 @@ [DEFAULT] pristine-tar = True upstream-branch = upstream-sid -debian-branch = debian-sid +debian-branch = debian-buster [buildpackage] export-dir = ../build-area/ diff -Nru php-horde-text-filter-2.3.5/debian/patches/0001_protect_the_-_this_is_not_a_range.patch php-horde-text-filter-2.3.5/debian/patches/0001_protect_the_-_this_is_not_a_range.patch --- php-horde-text-filter-2.3.5/debian/patches/0001_protect_the_-_this_is_not_a_range.patch 1970-01-01 01:00:00.0 +0100 +++ php-horde-text-filter-2.3.5/debian/patches/0001_protect_the_-_this_is_not_a_range.patch 2020-01-28 10:41:46.0 +0100 @@ -0,0 +1,30 @@ +Description: protect the -, this is not a range + Makes regular expressions valid... +Author: Remi Collet +Origin: upstream +Applied-Upstream: https://github.com/horde/Text_Filter/commit/8d0de407dbb95626bc54eaba078191847be9c574 +Last-Update: 2020-01-28 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- php-horde-text-filter.orig/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php php-horde-text-filter/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php +@@ -61,7 +61,7 @@ + ((?(1)\s*\])) + | + # Version 2 Pattern 9 and 10: simple email addresses. +-(^|\s|<|<|\[)([\w-+.=]+@[-A-Z0-9.]*[A-Z0-9]) ++(^|\s|<|<|\[)([\w\-+.=]+@[-A-Z0-9.]*[A-Z0-9]) + # Pattern 11 to 13: Optional parameters + ((\?
Bug#950017: ITP: imx-code-signing-tool -- code signing tool for i.MX platform
Package: wnpp Severity: wishlist Owner: Andrej Shadura * Package name: imx-code-signing-tool Version : 3.3.0 Upstream Author : NXP * URL : https://www.nxp.com/pip/IMX_SW2 * License : BSD-3 Programming Lang: C Description : code signing tool for i.MX platform This package provides a code signing tool for signing images for i.MX-based NXP processors using High Assurance Boot (HABv4) library in the internal boot ROM or the Advanced High Assurance Boot (AHAB) subsystem. . This package also provides a variety of support scripts.
Bug#931255: Orphaning php-horde*
On Tue, 28 Jan 2020 11:15:56 +0100 =?UTF-8?Q?IOhannes_m_zm=c3=b6lnig?= wrote: > if nobody objects, i'm going to do a QA-upload to buster/proposed-updates. https://bugs.debian.org/950018 signature.asc Description: OpenPGP digital signature
Bug#933713: libgpg-error-dev: make package fit for cross development
Package: libgpg-error-dev
Version: 1.36-7
Followup-For: Bug #933713
libgcrypt is under consideration for use in Wine but Wine depends on
proper multiarch support since we need to support both 32 bit and 64 bit
Windows applications (even 64 bit Windows applications have 32 bit
installers).
This means a Wine developer needs to install both the i386 and amd64
variants of libgcrypt-dev which in turn depends on libgpg-error-dev.
Some libgpg-error-dev's lack of multiarch support prevents Wine from
using libgcrypt.
The only blocker for making libgpg-error-dev Multi-Arch: same is
gpg-error-config. However gpg-error-config is not needed on Debian
since there is no need for -I or -L directives; and it has been
superseded by gpgrt-config and pkgconfig anyway.
So I think it is reasonable to stop shipping gpg-error-config, just like
FreeType stopped shipping freetype-config to become multiarch-compatible.
The attached patch modifies libgpg-error-dev accordingly. Feel free to
incorporate it into a future release and to adjust the changelog as you
see fit.
In the meantime one can generate multiarch-ified packages as follows:
(you'll probably need to create a 32 bit chroot with debootstrap+schroot)
tar xfj libgpg-error_1.36.orig.tar.bz2
cd libgpg-error-1.36
tar xfJ ../libgpg-error_1.36-7.debian.tar.xz
patch -p1 <../libgpg-error.diff
dpkg-buildpackage -rfakeroot -uc -us
diff -ur '--exclude=*~' libgpg-error-1.36.orig/debian/changelog
libgpg-error-1.36/debian/changelog
--- libgpg-error-1.36.orig/debian/changelog 2019-07-16 19:32:03.0
+0200
+++ libgpg-error-1.36/debian/changelog 2020-01-28 12:19:50.920379927 +0100
@@ -1,3 +1,12 @@
+libgpg-error (1.36-7m) unstable; urgency=medium
+
+ * Don't ship gpg-error-config: it is not needed on Debian, has been
+superseeded by gpgrt-config and pkgconfig and is incompatible with
+multiarch support
+ * Mark the development package as multiarch (Closes: #933713)
+
+ -- Francois Gouget Tue, 28 Jan 2020 02:02:00 +0100
+
libgpg-error (1.36-7) unstable; urgency=medium
* d/tests/windows: specify WINESERVER
diff -ur '--exclude=*~' libgpg-error-1.36.orig/debian/control
libgpg-error-1.36/debian/control
--- libgpg-error-1.36.orig/debian/control 2019-07-14 18:59:16.0
+0200
+++ libgpg-error-1.36/debian/control2020-01-28 04:11:55.027998272 +0100
@@ -20,6 +20,7 @@
Package: libgpg-error-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends:
libgpg-error0 (= ${binary:Version}),
${misc:Depends},
diff -ur '--exclude=*~'
libgpg-error-1.36.orig/debian/libgpg-error-dev.install.in
libgpg-error-1.36/debian/libgpg-error-dev.install.in
--- libgpg-error-1.36.orig/debian/libgpg-error-dev.install.in 2018-12-15
02:54:26.0 +0100
+++ libgpg-error-1.36/debian/libgpg-error-dev.install.in2020-01-28
11:21:52.852522535 +0100
@@ -1,4 +1,3 @@
-usr/bin/gpg-error-config
usr/bin/gpgrt-config
usr/include/* usr/include/@DEB_HOST_MULTIARCH@/
usr/lib/*/libgpg-error.a
Bug#950005: Fix in slof MR
Hi Christian, Thanks a lot for your investigations. Your response was by far the quickest I ever got on the Debian BTS. :) Looking forward for the fix in Testing. Best Björn !!NOSIG!!
Bug#950020: meson autopkg tests failing on arm64
Package: src:meson
Version: 0.53.0-1
Severity: serious
Tags: sid bullseye
meson autopkg tests failing on arm64:
https://ci.debian.net/data/autopkgtest/testing/arm64/m/meson/4117906/log.gz
==
ERROR: test_ld_environment_variable_rust (__main__.LinuxlikeTests)
--
Traceback (most recent call last):
File "run_unittests.py", line 5897, in test_ld_environment_variable_rust
self._check_ld('ld.gold', 'gold', 'rust', 'GNU ld.gold')
File "run_unittests.py", line 5881, in _check_ld
comp = getattr(env, 'detect_{}_compiler'.format(lang))(MachineChoice.HOST)
File
"/tmp/autopkgtest-lxc.o9fv_b8h/downtmp/build.N45/src/mesonbuild/environment.py",
line 1411, in detect_rust_compiler
self._handle_exceptions(popen_exceptions, compilers)
File
"/tmp/autopkgtest-lxc.o9fv_b8h/downtmp/build.N45/src/mesonbuild/environment.py",
line 733, in _handle_exceptions
raise EnvironmentException(errmsg)
mesonbuild.mesonlib.EnvironmentException: Unknown compiler(s): ['rustc']
The follow exceptions were encountered:
Running "rustc --version" gave "[Errno 2] No such file or directory: 'rustc':
'rustc'"
--
Ran 301 tests in 357.825s
FAILED (errors=1, skipped=50)
pytest-xdist not found, using unittest instead
Bug#947847: please install systemd-sysusers using update-alternatives
Anthony DeRobertis
> It's different than awk because the decision the admin is making
> ("which init system do I want to run"?) isn't done through
> alternatives. So you can't use the alternatives system to coordinate
> swapping all the different bits together.
You are mixing things here. We are *not* talking about init systems, but
about sysusers, which can be used with any init systems.
> It seems retty reasonable to me that the systemd maintainers don't
> want to support systems which are running arbitrary combinations of
> systemd with alternatives to some parts.
Absolutely nobody is asking them to do that. I'm just asking for a
solution to easily replace /bin/systemd-sysusers. There are 2 solutions,
one is to have /bin/systemd-sysusers packaged separately, though this
would probably be micro-packaging, which I'm not a fan of. The other
solution is to use update-alternatives. I'm fine with both solution, I
just don't think it's fine to say "get away, my implementation is
better", and leave no reasonable solution to install something else.
> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on that.
This is exactly what should be avoided. It's perfectly fine to try to
use opensysusers with systemd if one wants. In fact, that's exactly the
best way we could do to be able to test it. Also, dpkg-divert is really
ugly, and something you use as the last resort, when all other options
have been exhausted.
> This wouldn't affect systemd-only machines (as opensysusers would not
> be installed at all), and would do the right thing if someone has
> installed two init systems to, e.g., consider switching.
Again, you are mixing things (ie: what type of init system and
re-implementation of an independent component of systemd). We should be
able to allow to run opensysusers if systemd is running (exactly, why
not?). This is desirable, at least for testing. It would also be
desirable to use systemd-sysusers with other init system if one wants
(also: why not?).
> It'd need to be a script that the systemd maintainers feel reasonably
> confident will always run systemd's implementation when systemd is
> running, to avoid the mixed implementations issue.
Not at all. Systemd maintainers have no say if someone wishes to
implement things in another way, the same way there's gawk and mawk,
implementing the same thing. If we don't allow such things, then really,
Debian is doomed.
I am not buying into the "we will have wrong bug reports" argument. We
constantly get many types of wrong reports in the BTS. We just shall do
sensible bug triaging in a correct way, that's it.
Cheers,
Thomas Goirand (zigo)
P.S: Note that this bug also concerns systemd-tmpfiles, the very exact
same way, though I believe one single bug is enough to address both
cases which are similar.
Bug#948570:
Verified working (with correct compiler version) -- tested with:
echo -e "#include \nTEST(foo, bar){}" | g++ -xc++ -
`pkg-config gtest_main --libs --cflags`
Bug#931255: Orphaning php-horde*
Hi Johannes, On Di 28 Jan 2020 11:15:56 CET, IOhannes m zmölnig wrote: On Sun, 13 Oct 2019 23:32:56 +0200 Mathieu Parent wrote: Hello, FYI, I'm orphaning php-horde-* packages. See: https://bugs.debian.org/942282 if nobody objects, i'm going to do a QA-upload to buster/proposed-updates. i've create a PR [2] for the relevant changes fgmasdf IOhannes [2] https://salsa.debian.org/horde-team/php-horde-text-filter/merge_requests/2 Please go ahead. I hopefully will be able to give some priority to picking up Horde in the next couple of weeks. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpQFg_qIj45M.pgp Description: Digitale PGP-Signatur
Bug#948774: Bug#948477: transition: openbabel
Hi Paul, On 2020-01-27 22:50, Paul Gevers wrote: > I see you went ahead *and* you added an autopkgtest to openbabel. > Obviously I love autopkgtests, however, the test fails and times out on > arm64. The tests seem to timeout during build on arm64 too, viz: The following tests FAILED: 75 - test_regressions_1 (Timeout) 76 - test_regressions_221 (Timeout) 178 - inchiSteffen_PubChem.smi_Test (Timeout) 180 - pytest_sym (Timeout) 188 - pybindtest_bindings (Timeout) However, during build the timeouts seem to be ignored. > In case you don't know how to fix the test for arm64, I suggest you mark > the test with the skippable restriction and exit 77 at the start of the > test if it detects it runs on arm64. Obviously, fixing the test is better. Many thanks for advice - I made the autopkgtest skippable on arm64 just as you have suggested. Uploaded 3.0.0+dfsg-3. Best wishes, Andrius signature.asc Description: OpenPGP digital signature
Bug#949388: zlib: build lib64z for x32 and mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el
On Tue, 21 Jan 2020 08:48:23 +0800 YunQiang Su wrote:
> John Paul Adrian Glaubitz
于2020年1月20日周一
> 下午11:50写道：
> >
> > Hi!
> >
> > On 1/20/20 4:27 PM, YunQiang Su wrote:
> > > @powerpc: does powerpc need it?
> >
> > Do you have an example package that fails to build because of
memory exhaustion
> > of the linker? Then we could check the build logs on powerpc to see
if any of
> > the packages are affected.
>
> see this thread:
> https://lists.debian.org/debian-arm/2019/08/msg9.html
>
> This is some problem we met on mips/mipsel:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879636
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849657
>
>
I NMUed zlib with the attached patch with 5-days delay.
Feel free to cut it if you think that it is not good.
>
> >
> > Adrian
> >
> > --
> > .''`. John Paul Adrian Glaubitz
> > : :' : Debian Developer - glaub...@debian.org
> > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
>
diff -Nru zlib-1.2.11.dfsg/debian/changelog zlib-1.2.11.dfsg/debian/changelog
--- zlib-1.2.11.dfsg/debian/changelog 2017-09-26 03:03:05.0 +0800
+++ zlib-1.2.11.dfsg/debian/changelog 2020-01-28 19:55:38.0 +0800
@@ -1,3 +1,12 @@
+zlib (1:1.2.11.dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Enable lib64 for mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el x32
+help to add binutils-host64 for 32bit architectures (Closes: 949388)
+ * Remove outdated binutils version requirement for mips/mipsel.
+
+ -- YunQiang Su Tue, 28 Jan 2020 19:55:38 +0800
+
zlib (1:1.2.11.dfsg-1) unstable; urgency=low
* New upstream release (closes: #883180).
diff -Nru zlib-1.2.11.dfsg/debian/control zlib-1.2.11.dfsg/debian/control
--- zlib-1.2.11.dfsg/debian/control 2017-09-26 03:03:03.0 +0800
+++ zlib-1.2.11.dfsg/debian/control 2020-01-28 19:55:38.0 +0800
@@ -4,7 +4,7 @@
Maintainer: Mark Brown
Standards-Version: 3.9.8
Homepage: http://zlib.net/
-Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) [mips mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x] , dpkg-dev (>= 1.16.1)
+Build-Depends: debhelper (>= 8.1.3~), gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el x32] , dpkg-dev (>= 1.16.1)
Package: zlib1g
Architecture: any
@@ -53,7 +53,7 @@
for use with the Debian installer.
Package: lib64z1
-Architecture: sparc s390 i386 powerpc mips mipsel
+Architecture: sparc s390 i386 powerpc mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el x32
Build-Profiles:
Depends: ${shlibs:Depends}, ${misc:Depends}
Replaces: amd64-libs (<< 1.4)
@@ -64,7 +64,7 @@
Package: lib64z1-dev
Section: libdevel
-Architecture: sparc s390 i386 powerpc mips mipsel
+Architecture: sparc s390 i386 powerpc mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el x32
Build-Profiles:
Depends: lib64z1 (= ${binary:Version}), zlib1g-dev (= ${binary:Version}), lib64c-dev, ${misc:Depends}
Replaces: amd64-libs-dev (<< 1.4)
diff -Nru zlib-1.2.11.dfsg/debian/rules zlib-1.2.11.dfsg/debian/rules
--- zlib-1.2.11.dfsg/debian/rules 2017-09-26 03:03:03.0 +0800
+++ zlib-1.2.11.dfsg/debian/rules 2020-01-28 19:53:38.0 +0800
@@ -36,8 +36,8 @@
ifeq (,$(filter stage1,$(DEB_BUILD_PROFILES)))
-32-ARCHS=amd64 ppc64 kfreebsd-amd64 s390x
-64-ARCHS=s390 sparc i386 powerpc mips mipsel
+32-ARCHS=amd64 ppc64 kfreebsd-amd64 s390x mips64 mips64el mips64r6 mips64r6el
+64-ARCHS=s390 sparc i386 powerpc mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el x32
ifneq (,$(findstring $(DEB_HOST_ARCH), $(32-ARCHS)))
EXTRA_INSTALL=install32
Bug#950021: linux-image-5.4.0-3-amd64: i915 Driver Problem: Resetting rcs0 for hang on rcs0 -> Fixed in linux 5.5
Package: src:linux
Version: 5.4.13-1
Severity: normal
Tags: upstream
Linux Kernel 5.4 has a problem with the i915 drm driver.
Problem is reported here:
https://gitlab.freedesktop.org/drm/intel/issues/161#note_363380 and
fixed in Linux 5.5.
When the problem occurs the system will hang for 5 to 20 seconds and
the
line "i915 :00:02.0: Resetting rcs0 for hang on rcs0" will be
logged
to kernel.log.
Software using graphic acceleration like games or some browsers have a
chance to crash due to the reset.
There are bug-reports for other distributions as well like:
- https://bugs.archlinux.org/task/64860
- https://bugzilla.redhat.com/show_bug.cgi?id=1727433
- ...
-- Package-specific info:
** Version:
Linux version 5.4.0-3-amd64 (debian-ker...@lists.debian.org) (gcc
version 9.2.1 20200117 (Debian 9.2.1-24)) #1 SMP Debian 5.4.13-1 (2020-
01-19)
** Command line:
BOOT_IMAGE=/vmlinuz-5.4.0-3-amd64 root=/dev/mapper/rootvg-rootlv ro
quiet
** Not tainted
** Kernel log:
[11852.271856] i915 :00:02.0: GPU HANG: ecode 9:1:0x, hang
on rcs0
[11852.271863] GPU hangs can indicate a bug anywhere in the entire gfx
stack, including userspace.
[11852.271866] Please file a _new_ bug report on bugs.freedesktop.org
against DRI -> DRM/Intel
[11852.271869] drm/i915 developers can then reassign to the right
component if it's not a kernel issue.
[11852.271872] The GPU crash dump is required to analyze GPU hangs, so
please always attach it.
[11852.271875] GPU crash dump saved to /sys/class/drm/card0/error
[11852.272901] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[11852.273788] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset
request timed out: {request: 0001, RESET_CTL: 0001}
[11852.274113] i915 :00:02.0: Resetting chip for hang on rcs0
[11852.275996] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset
request timed out: {request: 0001, RESET_CTL: 0001}
[11852.276883] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset
request timed out: {request: 0001, RESET_CTL: 0001}
[11860.272748] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[11862.288786] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[11870.288746] i915 :00:02.0: Resetting rcs0 for hang on rcs0
** Model information
sys_vendor: LENOVO
product_name: 20FNS0UB00
product_version: ThinkPad T460
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: R06ET66W (1.40 )
board_vendor: LENOVO
board_name: 20FNS0UB00
board_version: SDK0J40705 WIN
** Loaded modules:
xt_hl
xt_REDIRECT
rfcomm
cpufreq_conservative
cpufreq_powersave
cpufreq_userspace
xt_CHECKSUM
nft_chain_nat
xt_MASQUERADE
nf_nat
md4
bridge
nls_utf8
stp
cifs
llc
gcm
dns_resolver
fscache
libdes
snd_usb_audio
snd_usbmidi_lib
snd_rawmidi
snd_seq_device
cmac
bnep
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
btusb
btrtl
btbcm
btintel
videodev
mc
bluetooth
drbg
ansi_cprng
fuse
ecdh_generic
ecc
nft_counter
xt_tcpudp
xt_state
binfmt_misc
xt_conntrack
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
nft_compat
nf_tables
nfnetlink
snd_hda_codec_hdmi
msr
intel_rapl_msr
intel_rapl_common
snd_soc_skl
snd_soc_hdac_hda
x86_pkg_temp_thermal
snd_hda_ext_core
intel_powerclamp
snd_soc_sst_ipc
snd_soc_sst_dsp
coretemp
snd_soc_acpi_intel_match
snd_soc_acpi
mei_wdt
iwlmvm
snd_soc_core
kvm_intel
mac80211
snd_hda_codec_realtek
snd_hda_codec_generic
snd_compress
libarc4
kvm
iwlwifi
snd_hda_intel
irqbypass
intel_cstate
snd_intel_nhlt
intel_uncore
snd_hda_codec
cfg80211
pcspkr
intel_rapl_perf
snd_hda_core
snd_hwdep
iTCO_wdt
joydev
iTCO_vendor_support
snd_pcm
rtsx_pci_ms
memstick
wmi_bmof
snd_timer
serio_raw
watchdog
sg
intel_pch_thermal
tpm_tis
mei_me
tpm_tis_core
tpm
mei
rng_core
thinkpad_acpi
nvram
ledtrig_audio
snd
ac
soundcore
rfkill
evdev
parport_pc
ppdev
lp
parport
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
hid_logitech_hidpp
hid_logitech_dj
hid_generic
usbhid
hid
dm_crypt
dm_mod
sd_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
i915
rtsx_pci_sdmmc
mmc_core
e1000e
aesni_intel
crypto_simd
xhci_pci
xhci_hcd
ahci
psmouse
libahci
cryptd
glue_helper
libata
i2c_algo_bit
i2c_i801
drm_kms_helper
ptp
usbcore
scsi_mod
pps_core
drm
rtsx_pci
mfd_core
usb_common
wmi
battery
button
video
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500
v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:1904] (rev
08)
Subsystem: Lenovo Xeon E3-1200 v5/E3-1500 v5/6th Gen Core
Processor Host Bridge/DRAM Registers [17aa:5053]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-
Kernel driver in use: skl_uncore
00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2
[HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Lenovo Skylake GT2 [HD Graphics 520] [17aa:5053]
Bug#950008: gfan: assertion fails on riscv64
Control: forwarded -1 jen...@imf.au.dk Hello! I am forwarding the bug report below from the Debian package of gfan: On Tue, Jan 28, 2020 at 4:33 AM Tobias Hansen wrote: > Source: gfan > Version: 0.6.2-2 > Severity: normal > > Hi, > > many of sagemath's doctests in the interface to gfan fail on riscv64 with the > following error: > > gfan_*: src/application.cpp:42: char* tail(char*): Assertion `*p==*m' failed. > > It looks like the pointer arithmetic in the function tail() in > application.cpp does not work like this on riscv64. Unfortunately there are > no porterboxes for riscv64 yet, so I can't come up with a minimal example > triggering the bug. > > Best, > Tobias
Bug#949795: mime-support: x-pascal mime type misses an extension
Le Sat, Jan 25, 2020 at 09:06:43AM +0100, Michael Van Canneyt a écrit : > > Please consider changing the registration of text/x-pascal to > > text/x-pascal p pas pp Dear Michael, I can do this, but would you consider registering an official media type to the IANA ? https://www.iana.org/form/media-types Have a nice day, -- Charles Plessy Akano, Uruma, Okinawa, Japan
Bug#950008: Sv: Bug#950008: gfan: assertion fails on riscv64
Hi, Thanks for the bug report. Line 30 of application.cpp looks suspicious: while(p[l]!=0 && p[l]!='/'); Does it help to change it to while(l!=0 && p[l]!='/'); ? If not, I think I need to know what the char* argv[0] points to when main is called. Best regards, Anders Fra: Torrance, Douglas Sendt: 28. januar 2020 13:51 Til: Tobias Hansen ; 950...@bugs.debian.org <950...@bugs.debian.org>; Anders Nedergaard Jensen Emne: Re: Bug#950008: gfan: assertion fails on riscv64 Control: forwarded -1 jen...@imf.au.dk Hello! I am forwarding the bug report below from the Debian package of gfan: On Tue, Jan 28, 2020 at 4:33 AM Tobias Hansen wrote: > Source: gfan > Version: 0.6.2-2 > Severity: normal > > Hi, > > many of sagemath's doctests in the interface to gfan fail on riscv64 with the > following error: > > gfan_*: src/application.cpp:42: char* tail(char*): Assertion `*p==*m' failed. > > It looks like the pointer arithmetic in the function tail() in > application.cpp does not work like this on riscv64. Unfortunately there are > no porterboxes for riscv64 yet, so I can't come up with a minimal example > triggering the bug. > > Best, > Tobias
Bug#950022: ITP: python3-freezer-web-ui -- OpenStack Freezer dashboard plugin
Package: wnpp Severity: wishlist Owner: Michal Arbet * Package name: python3-freezer-web-ui Version : 7.2.0 Upstream Author : Openstack-Dev * URL : https://github.com/openstack/freezer-web-ui * License : Apache-2 Programming Lang: Python Description : OpenStack Freezer - dashboard plugin OpenStack Freezer - dashboard plugin - This package provides Horizon ( Django Dashboard ) plugin for Openstack Service [ Openstack Freezer ]. - I will maintain it inside a packaging team Debian Openstack
Bug#948316: MIA?
Hi Angel, Sorry for the late reply and I did not use the package a long time. How can I transfer the owner to you? br, yp On Tue, Jan 28, 2020, 01:00 Angel Abad wrote: > It seems that Yao-Po Wang is mia, so, could we adopt this package? > > Thanks! >
Bug#950023: locales: Collation rules for v/w in sv_SE produce very surprising results in grep
Package: locales Version: 2.28-10 Severity: normal Tags: l10n Dear maintainer! I'm not positive that this is a bug (the man page for grep does warn about character ranges in locales other than C) but it produces very surprising results in grep. Presumably this is realated to bugs #506784 and #511357. % echo -n abcdefghijklmnopqrstuvwxyz| sed 's/./&\n/g'| LC_COLLATE=C grep '[a-z]' a b c d e f g h i j k l m n o p q r s t u v w x y z % echo -n abcdefghijklmnopqrstuvwxyz| sed 's/./&\n/g'| LC_COLLATE=sv_SE grep '[a-z]' a b c d e f g h i j k l m n o p q r s t u v x y z % : Note the lack of 'w' above. % LC_COLLATE=sv_SE grep '[a-w]' grep: Invalid range end % : This time at least there was an error message to warn me about the problem. As i typically write "[a-z]" as shorthand for "[[:lower:]]" when i don't need to match any national characters this bothers me quite a bit. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.71 ii libc-bin 2.28-10 ii libc-l10n 2.28-10 locales recommends no packages. locales suggests no packages. -- debconf information excluded
Bug#950024: ruby-github-markdown: ships /usr/bin/gfm already provided by the gfm package
Package: ruby-github-markdown Version: 0.6.9-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Selecting previously unselected package ruby-github-markdown. Preparing to unpack .../18-ruby-github-markdown_0.6.9-4_amd64.deb ... Unpacking ruby-github-markdown (0.6.9-4) ... dpkg: error processing archive /tmp/apt-dpkg-install-YI7FMa/18-ruby-github-markdown_0.6.9-4_amd64.deb (--unpack): trying to overwrite '/usr/bin/gfm', which is also in package gfm 1.08-1+b1 Errors were encountered while processing: /tmp/apt-dpkg-install-YI7FMa/18-ruby-github-markdown_0.6.9-4_amd64.deb cheers, Andreas gfm=1.08-1+b1_ruby-github-markdown=0.6.9-4.log.gz Description: application/gzip
Bug#851747: sysvinit-utils: drop Essential flag
Hello, About a month ago (so I hope I remember all the details correctly) I got motivated to revisit looking into this issue again. My previous concern had been about how much work it would need because of how widely used pidof is. While actually looking closer at the users of pidof (using codesearch.debian.net to search for 'pidof ') I found that most callers where actually using 'if pidof ... ; then ; fi' and very few where calling pidof in a way that would actually fail if the command where not around. I also noticed that generally the (non-existant) "else" case where to be considered the correct code path for pidof not being installed in my opinion. The amount of packages actually needing pidof to be around thus was much lower than I first anticipated. Given that codesearch.debian.net would give source-code matches which could very well not be shipped at all in the resulting binary packages built from the source, I figured I'd set out to do some quick testing instead. I tried both 'debootstrap --variant=minbase' as well as a regular 'debootstrap' (including priority standard,important,required packages) both with the --exclude=sysvinit-utils. Both worked as a charm and as I see it proves that in theory the package being 'Essential: yes' is plain wrong. Additionally I tried booting (using systemd-nspawn) the regular chroot (with standard/important packages included) and could not spot anything problematic despite missing sysvinit-utils package. That probably points to the 'Priority: required' also being theoretically wrong. As I see it a possible plan for moving this forward could be to start off by dropping 'Essential: yes' (while still keeping 'Priority: required'). This would mean sysvinit-utils where still installed virtually everywhere (including 'debootstrap --variant=minbase'), while opening up for allowing packages to declare a dependency on sysvinit-utils where needed (without violating policy). (I bet someone will argue that this causes a theoretical correctness problem as some packages that should have a dependency lacks it. I would however like to point out that it's a theoretical problem, not a practical one as every installation will still have sysvinit-utils installed. I'd also like to point out that the current state of things already violates theoretical correctness as pointed out above. There's thus no theoretical regression, just one theoretical problem replaced with another - allowing to move forward and actually solving the theoretical issues.) This leads up to me wishing that people should tread carefully when introducing dependencies on sysvinit-utils, mainly as I think long-term we should switch to the procps implementation of pidof. Please urge anyone adding a dependency on sysvinit-utils not to just document they did so, but to clearly write down *why*. I haven't spend enough thought on if it would be simpler to move pidof from sysvinit-utils to procps at the same time or at a separate time. I know from personal experience that getting maintainers to drop pointless (build-)dependencies they've introduced in the past is close to impossible, even when you prove it's not needed (and even when the dep is on something that's going to get removed from the archive!). I think most uses of pidof can and should likely be fixed up instead of adding a dependency. For init scripts there's pidofproc in LSB for example. Likely you could go even deeper and question why using that is needed. You can likely get rid of that as well with a bigger refactoring/modernization of the init script. Once pidof is moved into procps, sysvinit should "obviously" gain a transitional dependency on procps. This however would make a 'Priority: required' package depend on a 'Priority: important' one (while no longer being a policy violation in itself, I think it's still suboptimal to make procps pseudo-required). This could be one reason why it would be better to postpone transitioning pidof until we're ready to consider downgrading sysvinit-utils to 'Priority: important' (or lower). (If anyone has concerns about the pidof implementations possibly not being 100% compatible, I'd just like to say that any such problem is already a portability problem as anything that only works with the sysvinit-utils pidof will not work on non-Debian distributions as basically everyone is already using procps pidof. It should thus in my opinion be fixed up in the caller.) Regards, Andreas Henriksson
Bug#946456: systemd: Provide systemd-sysusers as an independent package
Hi,
On Tue, 2020-01-28 at 02:43 +0100, Michael Biebl wrote:
> Last but not least, we'd have the option to link systemd-sysusers
> statically against libsystemd-shared. This would have the downside, that
> it significantly increases the size of the binary. So we'd hurt the
> overwhelming majority of the Debian users for questionable gain.
I tried linking systemd-{sysusers,tmpfiles} statically against
systemd's private library earlier this month. It increases the
binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
systemd that is just one percent).
If we want to use systemd-{sysusers,tmpfiles} in maintainer scripts to
create system users and/or directories under /var, then I think we
should split it off into a separate package, say systemd-utils, so that
package installation doesn't pull in the entire systemd init (for
containers or other uses that might not require an init).
As far as I understand such a systemd-utils package would currently be
compatible with elogind, but I wouldn't commit to systemd-utils not
switching to linking libsystemd0 in the future should this be easily
possible.
Ansgar
Bug#950025: libasound2: using module-echo-cancel in 1.2.1-1 results in no input devices
Package: libasound2 Version: 1.1.9-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgraded from 1.1.9-1 to 1.2.1-1 * What exactly did you do (or not do) that was effective (or ineffective)? Used the following snipped in /etc/pulse/default.pa .ifexists module-echo-cancel.so load-module module-echo-cancel aec_method=webrtc .endif * What was the outcome of this action? After upgrading, no input devices were available * What outcome did you expect instead? Downgrading back to 1.1.9-1 restored the microphones Removing the module-echo-cancel line allows 1.2.1-1 to work, but without echo cancellation. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 Versions of packages libasound2 depends on: hi libasound2-data 1.1.9-1 ii libc62.29-9 libasound2 recommends no packages. Versions of packages libasound2 suggests: hi libasound2-plugins 1.1.9-1 -- no debconf information
Bug#950026: ser2net: communiction may hang when RFC2217 is used
Package: ser2net Version: 3.5-2 Severity: normal Tags: upstream -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ser2net depends on: ii libc6 2.28-10 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 ser2net recommends no packages. Versions of packages ser2net suggests: ii telnet 0.17-41.2 -- no debconf information
Bug#950027: libvtk7-jni installs files into the wrong location
Package: libvtk7-jni Version: 7.1.1+dfsg2-1 Severity: serious Tags: sid bullseye see https://packages.debian.org/sid/amd64/libvtk7-jni/filelist These files are not looked for in /usr/lib/jni/jni. The directory should be /usr/lib/DEB_HOST_MULTIARCH/jni
Bug#950028: nmu: nageru_1.9.1-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu nageru_1.9.1-1.1 . armel armhf i386 mipsel . unstable . -m "rebuild against movit 1.6.3-5" Hi, I'm unsure if this should be a binNMU request or not, but please retry nageru 1.9.1-1.1 (currently in Build-Attempted) on 32-bit platforms armel, armhf, i386, mipsel; newer movit should work around some Mesa breakage on such platforms. -- System Information: Debian Release: 10.2 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.11 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#950029: ITP: python-gvm -- Greenbone Vulnerability Management Python Library
Package: wnpp Severity: wishlist Owner: Sophie Brun * Package name: python-gvm Version : 1.2.0 Upstream Author : Greenbone Networks GmbH * URL : https://github.com/greenbone/python-gvm * License : GPL-3+ Programming Lang: Python3 Description : Greenbone Vulnerability Management Python Library The Greenbone Vulnerability Management Python API library is a collection of APIs that help with remote controlling a Greenbone Security Manager (GSM) appliance and its underlying Greenbone Vulnerability Manager (GVM). The library essentially abstracts accessing the communication protocols Greenbone Management Protocol (GMP) and Open Scanner Protocol (OSP). It's required by the gvm-tools package (which replaces openvas-cli). I plan to maintain it within the pkg-security team with the other openvas/ greenbone packages.
Bug#950030: python-pyfaidx FTBFS: bgzip not found
Source: python-pyfaidx Version: 0.5.8-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=python-pyfaidx&arch=all&ver=0.5.8-1&stamp=157996&raw=0 ... debian/rules override_dh_auto_test make[1]: Entering directory '/<>' bgzip -c tests/data/genes.fasta > tests/data/genes.fasta.gz /bin/sh: 1: bgzip: not found make[1]: *** [debian/rules:14: override_dh_auto_test] Error 127
Bug#950032: libclc FTBFS: python not found
Source: libclc Version: 0.2.0+git20190827-3 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=libclc&arch=all&ver=0.2.0%2Bgit20190827-3&stamp=1580192025&raw=0 ... PYTHON_GEN generic/lib/convert.cl python < generic/lib/gen_convert.py > generic/lib/convert.cl /bin/sh: 1: python: not found make[1]: *** [Makefile:18: generic/lib/convert.cl] Error 127
Bug#950031: Please provide metapackage without 'python' in name
Package: python-diskimage-builder Version: 2.27.1-3 Diskimage builder is used as a command line utility, so it should have a package name without 'python' prefix. The need to specify python version during installation complicates everything (including migration from Py2 to Py3). The usual approach is to use metapackage or virtual package with no version (f.e. Provides: diskimage-builder for both python-diskimage-builder and python3-diskimage-builder). By using virtual package name user can install any version which fits into python environment on the host.
Bug#950033: missing dependencies on python3-healpy and python3-tk
Package: pymoctool Version: 0.5.0-4 Severity: normal pymoctool is missing dependencies on python3-healpy and python3-tk: $ pymoctool ../cepheiden.moc --plot Traceback (most recent call last): File "/usr/bin/pymoctool", line 40, in main() File "/usr/bin/pymoctool", line 33, in main tool.run(sys.argv[1:]) File "/usr/lib/python3/dist-packages/pymoc/util/tool.py", line 111, in run self.command[p](self) File "/usr/lib/python3/dist-packages/pymoc/util/tool.py", line 380, in plot from .plot import plot_moc File "/usr/lib/python3/dist-packages/pymoc/util/plot.py", line 16, in import healpy ModuleNotFoundError: No module named 'healpy' ... installing python3-healpy: $ pymoctool ../cepheiden.moc --plot Traceback (most recent call last): File "/usr/bin/pymoctool", line 40, in main() File "/usr/bin/pymoctool", line 33, in main tool.run(sys.argv[1:]) File "/usr/lib/python3/dist-packages/pymoc/util/tool.py", line 111, in run self.command[p](self) File "/usr/lib/python3/dist-packages/pymoc/util/tool.py", line 380, in plot from .plot import plot_moc File "/usr/lib/python3/dist-packages/pymoc/util/plot.py", line 18, in import matplotlib.pyplot as plt File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 2349, in switch_backend(rcParams["backend"]) File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 221, in switch_backend backend_mod = importlib.import_module(backend_name) File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_tkagg.py", line 1, in from . import _backend_tk File "/usr/lib/python3/dist-packages/matplotlib/backends/_backend_tk.py", line 6, in import tkinter as tk ModuleNotFoundError: No module named 'tkinter' ... after installing python3-tk, rendering works. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de:en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pymoctool depends on: ii python33.7.5-3 ii python3-pymoc 0.5.0-4 pymoctool recommends no packages. pymoctool suggests no packages. -- no debconf information Christoph
Bug#949388: zlib: build lib64z for x32 and mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el
On Tue, Jan 28, 2020 at 08:50:09PM +0800, YunQiang Su wrote: > On Tue, 21 Jan 2020 08:48:23 +0800 YunQiang Su wrote: > > This is some problem we met on mips/mipsel: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879636 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849657 > I NMUed zlib with the attached patch with 5-days delay. > Feel free to cut it if you think that it is not good. This is extremely short notice on what should be a wishlist bug that was only filed just over a week ago for a non-mainstream port with an unclear description of the issue, it seems quite hasty to be doing a NMU. I've hopefully cancelled the upload for now, though this is the first time I've had to use dcut. signature.asc Description: PGP signature
Bug#950034: ITP: fonts-compagnon -- typeface family composed of five distinctive styles
Package: wnpp Severity: wishlist * Package name: fonts-compagnon Version : 0.2 Upstream Authors: Juliette Duhé Léa Pradine Valentin Papon Sébastien Riollier Chloé Lozano * URL : https://gitlab.com/velvetyne/compagnon * License : OFL-1.1 Description : typeface family composed of five distinctive styles Font that finds its inspiration in the online archives of Typewriter Database specimens and combines different periods of the history of typewriter typefaces. Each weight is based on singular references relating to significant periods aiming to underline the evolution of typewriter characters as they are called. Package is available at http://phd-sid.ethz.ch/debian/fonts-compagnon/
Bug#937061: Python3 Port of ModelBuilder
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: model-builder -- RoQA; dead upstream; unmaintained; low popcon; blocking py2 removal
Bug#949795: mime-support: x-pascal mime type misses an extension
On Tue, 28 Jan 2020, Charles Plessy wrote: Le Sat, Jan 25, 2020 at 09:06:43AM +0100, Michael Van Canneyt a écrit : Please consider changing the registration of text/x-pascal to text/x-pascal p pas pp Dear Michael, I can do this, but would you consider registering an official media type to the IANA ? https://www.iana.org/form/media-types In fact, I tried to do that prior to posting a debian bugreport. But I found no way to get x-pascal modified: the only possibilities were registering vnd.freepascal or so. or text/pascal. I would think that text/pascal is an option, although maybe application/pascal (seeing that application/json exists) will be accepted easier. Also I'm not sure how the existing x-pascal and a vnd.pascal will cooperate if they register the same extension. (.pas, .pp, .inc are all valid extensions for the freepascal compiler.) I assume you have more knowledge about this than I do, so any advice you have on this is welcome ! Michael.
Bug#851747: sysvinit-utils: drop Essential flag
Hi Andreas, thanks for your interest in this topic. Aside from /bin/pidof, we also have /sbin/fstab-decode /sbin/killall5 I haven't checked codesearch if those binaries are used outside of sysvinit/initscripts. Have you investigated those recently? And there is also /lib/init/init-d-script /lib/init/vars.sh Those are the more tricky ones. A lot of init scripts use them. Not having those installed will render the init scripts of packages broken. It's less of an issue, if a package ships a native service file. (Do we know for how many this is the case, i.e. no .service file, SysV init script using init-d-script and/or vars.sh?) Also, we have /etc/init.d/foo → redirection to systemctl broken unless /lib/lsb/init-functions is the first thing that is sourced. Maybe that breakage is acceptable? Dunno. What are your thoughts here? Given the size of the sysvinit-utils package, last time I looked into this I concluded it's probably not worth the trouble. But maybe things have changed by now. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#946456: systemd: Provide systemd-sysusers as an independent package
Hi
Am 28.01.20 um 14:59 schrieb Ansgar:
> I tried linking systemd-{sysusers,tmpfiles} statically against
> systemd's private library earlier this month. It increases the
> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
> systemd that is just one percent).
Is that 100K per binary?
We also have the overhead from /usr/share/doc/, so another 100K+
More importantly, this requires a downstream patch, and I'm really
trying hard to reduce the number of those downstream patches.
> If we want to use systemd-{sysusers,tmpfiles} in maintainer scripts to
> create system users and/or directories under /var, then I think we
> should split it off into a separate package, say systemd-utils, so that
> package installation doesn't pull in the entire systemd init (for
> containers or other uses that might not require an init).
Given that open{sysusers,tmpfiles} are currently packaged, shouldn't we
wait how that plays out first?
Maybe they are sufficiently well maintained upstream/downstream that
they would be an alternative for such a use case.
What I'm currently missing, is an overall plan. If the sysusers
interface is something we want as distro, there should be a coordinated
effort, not every package doing this on its own.
Regards,
Michael
signature.asc
Description: OpenPGP digital signature
Bug#939181: cycle: should it be RM'd ?
Hi all, Is there any hope for a Python 3 port of cycle, or should it just be RM'd? Scott
Bug#851747: sysvinit-utils: drop Essential flag
Am 28.01.20 um 16:38 schrieb Michael Biebl: > And there is also > /lib/init/init-d-script > /lib/init/vars.sh > > Those are the more tricky ones. A lot of init scripts use them. > Not having those installed will render the init scripts of packages > broken. It's less of an issue, if a package ships a native service file. Assuming the .service isn't just a wrapper around the init script. Unfortunately, we do have quite a few packages which use this anti-pattern :-/ https://codesearch.debian.net/search?q=ExecStart%3D%2Fetc%2Finit.d%2F&literal=1&perpkg=1 Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#948123: svn-workbench: New version available
On Sat, 4 Jan 2020, Davide Prina wrote: Package: svn-workbench Version: 1.8.2-3 Severity: wishlist Dear Maintainer, I see that there is a new upstream version available[¹] and the project home page is changed [²]. This new version work also with Python3. Ciao Davide [¹] https://sourceforge.net/projects/pysvn/files/ [²] https://pysvn.sourceforge.io/ Actually, pysyn is already packaged in Debian: https://tracker.debian.org/pkg/pysvn However, I think SCM Workbench is the successor to SVN Workbench: http://scm-workbench.barrys-emacs.org/ So, probably svn-workbench should be RM'd and scm-workbench should be packaged as a new package. Scott
Bug#950035: bumpversion FTBFS with pytest 4.6
Source: bumpversion Version: 0.5.10-2 Severity: serious Tags: ftbfs bullseye sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/bumpversion.html ... = test session starts == platform linux -- Python 3.8.1, pytest-4.6.9, py-1.8.0, pluggy-0.13.0 rootdir: /build/1st/bumpversion-0.5.10, inifile: tox.ini collected 37 items / 1 errors / 36 selected ERRORS ERROR collecting .pybuild/cpython3_3.8/build/tests/test_cli.py /usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__ return self._hookexec(self, self.get_hookimpls(), kwargs) /usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec return self._inner_hookexec(hook, methods, kwargs) /usr/lib/python3/dist-packages/pluggy/manager.py:83: in self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall( /usr/lib/python3/dist-packages/_pytest/python.py:234: in pytest_pycollect_makeitem res = list(collector._genfunctions(name, obj)) /usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions self.ihook.pytest_generate_tests(metafunc=metafunc) /usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__ return self._hookexec(self, self.get_hookimpls(), kwargs) /usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec return self._inner_hookexec(hook, methods, kwargs) /usr/lib/python3/dist-packages/pluggy/manager.py:83: in self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall( /usr/lib/python3/dist-packages/_pytest/python.py:137: in pytest_generate_tests metafunc.parametrize(*marker.args, **marker.kwargs) /usr/lib/python3/dist-packages/_pytest/python.py:999: in parametrize argnames, parameters = ParameterSet._for_parametrize( /usr/lib/python3/dist-packages/_pytest/mark/structures.py:131: in _for_parametrize if len(param.values) != len(argnames): E TypeError: object of type 'MarkDecorator' has no len() --- Captured stderr ...
Bug#950036: python-bashate FTBFS: Can't exec "pyversions": No such file or directory
Source: python-bashate Version: 0.6.0-3 Severity: serious Tags: ftbfs https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-bashate.html ... dh_auto_install -O--buildsystem=python_distutils dh_auto_install: warning: Please use the third-party "pybuild" build system instead of python-distutils dh_auto_install: warning: This feature will be removed in compat 12. Can't exec "pyversions": No such file or directory at /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 124. dh_auto_install: error: failed to run pyversions make: *** [debian/rules:7: binary] Error 25
Bug#950037: python-proliantutils FTBFS: test failures
Source: python-proliantutils
Version: 2.8.2-2
Severity: serious
Tags: ftbfs
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-proliantutils.html
...
==
FAIL:
proliantutils.tests.hpssa.test_manager.ManagerTestCases.test_create_configuration_max_as_size_gb
proliantutils.tests.hpssa.test_manager.ManagerTestCases.test_create_configuration_max_as_size_gb
--
testtools.testresult.real._StringException: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1330, in patched
return func(*args, **keywargs)
File
"/build/1st/python-proliantutils-2.8.2/proliantutils/tests/hpssa/test_manager.py",
line 288, in test_create_configuration_max_as_size_gb
raid_info = manager.create_configuration(raid_info)
File "/build/1st/python-proliantutils-2.8.2/proliantutils/hpssa/manager.py",
line 130, in create_configuration
validate(raid_config)
File "/build/1st/python-proliantutils-2.8.2/proliantutils/hpssa/manager.py",
line 52, in validate
jsonschema.validate(raid_config, raid_config_schema)
File "/usr/lib/python3/dist-packages/jsonschema/validators.py", line 895, in
validate
cls.check_schema(schema)
File "/usr/lib/python3/dist-packages/jsonschema/validators.py", line 289, in
check_schema
raise exceptions.SchemaError.create_from(error)
jsonschema.exceptions.SchemaError: {'type': 'object', 'properties':
{'raid_level': {'type': 'string', 'enum': ['0', '1', '5', '6', '10', '50',
'60', '1+0', '5+0', '6+0'], 'description': 'RAID level for the logical disk.
Required.'}, 'size_gb': {'anyOf': [{'type': 'integer', 'minimum': 0,
'exclusiveMinimum': True}, {'type': 'string', 'enum': ['MAX']}], 'description':
"Size in GiB (Integer) for the logical disk. Use 'MAX' as size_gb if this
logical disk is supposed to use the rest of the space available. Required."},
'volume_name': {'type': 'string', 'description': 'Name of the volume to be
created. Optional.'}, 'is_root_volume': {'type': 'boolean', 'description':
'Specifies whether this disk is a root volume. Optional.'},
'share_physical_disks': {'type': 'boolean', 'description': 'Specifies whether
other logical disks can share physical disks with this logical disk.
Optional.'}, 'disk_type': {'type': 'string', 'enum': ['hdd', 'ssd'],
'description': "Specifies the type of disk preferred. Valid values are 'hdd'
and 'ssd'. Optional."}, 'interface_type': {'type': 'string', 'enum': ['sata',
'scsi', 'sas'], 'description': "Specifies the interface type of disk. Valid
values are 'sata', 'scsi' and 'sas'. Optional."}, 'number_of_physical_disks':
{'type': 'integer', 'minimum': 0, 'exclusiveMinimum': True, 'description':
'Number of physical disks to use for this logical disk. Optional.'},
'controller': {'type': 'string', 'description': 'Controller to use for this
logical disk. Optional.'}, 'physical_disks': {'type': 'array', 'items':
{'type': 'string'}, 'description': 'The physical disks to use for this logical
disk. Optional'}}, 'required': ['raid_level', 'size_gb'],
'additionalProperties': False} is not valid under any of the given schemas
Failed validating 'anyOf' in
metaschema['properties']['properties']['additionalProperties']['properties']['items']:
{'anyOf': [{'$ref': '#'}, {'$ref': '#/definitions/schemaArray'}],
'default': True}
On schema['properties']['logical_disks']['items']:
{'additionalProperties': False,
'properties': {'controller': {'description': 'Controller to use for '
'this logical disk. '
'Optional.',
'type': 'string'},
'disk_type': {'description': 'Specifies the type of '
'disk preferred. Valid '
"values are 'hdd' and "
"'ssd'. Optional.",
'enum': ['hdd', 'ssd'],
'type': 'string'},
'interface_type': {'description': 'Specifies the '
'interface type of '
'disk. Valid values '
"are 'sata', 'scsi' "
"and 'sas'. "
'Optional.',
'enum': ['sata', 'scsi', 'sas'],
'type': 'string'},
'is_root_volume': {'description': 'Specifies whether '
'this disk is a root '
'volume. Opti
Bug#946456: systemd: Provide systemd-sysusers as an independent package
On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> Am 28.01.20 um 14:59 schrieb Ansgar:
> > I tried linking systemd-{sysusers,tmpfiles} statically against
> > systemd's private library earlier this month. It increases the
> > binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
> > systemd that is just one percent).
>
> Is that 100K per binary?
I checked my notes at it was 100 kB per binary: they are 212 kB larger
(sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with
systemd 243-8.
It might be possible to make it a bit smaller if one was to somehow
link libsystemd0 for functions available there (libsystemd-shared
currently duplicates those).
> We also have the overhead from /usr/share/doc/, so another 100K+
I think not every package needs to ship the full changelog. There are
two options to reduce this a bit:
- ship truncated changelogs in binary packages (only last 2 years or
so)
- symlink changelog.Debian.gz -> ../other-package/changelog.Debian.gz
for packages with strong dependencies; for example:
systemd has Depends: libsystemd0 (= ${binary:version}).
It could just have a symlink as nothing is lost.
Of course neither of these points are specific to systemd.
> More importantly, this requires a downstream patch, and I'm really
> trying hard to reduce the number of those downstream patches.
Ack.
> > If we want to use systemd-{sysusers,tmpfiles} in maintainer scripts to
> > create system users and/or directories under /var, then I think we
> > should split it off into a separate package, say systemd-utils, so that
> > package installation doesn't pull in the entire systemd init (for
> > containers or other uses that might not require an init).
>
> Given that open{sysusers,tmpfiles} are currently packaged, shouldn't we
> wait how that plays out first?
> Maybe they are sufficiently well maintained upstream/downstream that
> they would be an alternative for such a use case.
I admit not being too enthusiastic about open{sysusers,tmpfiles} and
would prefer to always use systemd-*, even in minimal environments
created by debootstrap for buildds or other environments.
> What I'm currently missing, is an overall plan. If the sysusers
> interface is something we want as distro, there should be a coordinated
> effort, not every package doing this on its own.
The current state of shipping systemd-{tmpfiles,sysuser} in systemd is
probably good enough for experimentation in leaf packages (outside of
what debootstrap would install in minimal environments) or conditional
use.
If we agree to recommend use of systemd-{tmpfiles,sysuser} in Policy,
then I would prefer if it was possible to split these utilities off
into a separate binary package.
(I opened a bug about -tmpfiles in Policy some time ago, but probably
need to think a bit more about when to use .tmpfiles vs *Directory= in
.service files. Using RuntimeDirectory=, StateDirectory=, ... where
possible should maybe be preferred over .tmpfiles.)
Ansgar
Bug#950038: python-wsgi-intercept FTBFS: test failures
Source: python-wsgi-intercept
Version: 1.8.1-2
Severity: serious
Tags: ftbfs
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-wsgi-intercept.html
...
=== FAILURES ===
__ test_https __
def test_https():
with InstalledApp(wsgi_app.simple_app, host=HOST, port=443) as app:
http = httplib2.Http()
> resp, content = http.request(
'https://some_hopefully_nonexistant_domain:443/')
wsgi_intercept/tests/test_httplib2.py:65:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
uri = 'https://some_hopefully_nonexistant_domain:443/', method = 'GET'
body = None, headers = {'user-agent': 'Python-httplib2/0.14.0 (gzip)'}
redirections = 5
connection_type =
def request(
self,
uri,
method="GET",
body=None,
headers=None,
redirections=DEFAULT_MAX_REDIRECTS,
connection_type=None,
):
""" Performs a single HTTP request.
The 'uri' is the URI of the HTTP resource and can begin
with either 'http' or 'https'. The value of 'uri' must be an absolute URI.
The 'method' is the HTTP method to perform, such as GET, POST, DELETE, etc.
There is no restriction on the methods allowed.
The 'body' is the entity body to be sent with the request. It is a string
object.
Any extra headers that are to be sent with the request should be provided
in the
'headers' dictionary.
The maximum number of redirect to follow before raising an
exception is 'redirections. The default is 5.
The return value is a tuple of (response, content), the first
being and instance of the 'Response' class, the second being
a string that contains the response entity body.
"""
conn_key = ''
try:
if headers is None:
headers = {}
else:
headers = self._normalize_headers(headers)
if "user-agent" not in headers:
headers["user-agent"] = "Python-httplib2/%s (gzip)" %
__version__
uri = iri2uri(uri)
(scheme, authority, request_uri, defrag_uri) = urlnorm(uri)
conn_key = scheme + ":" + authority
conn = self.connections.get(conn_key)
if conn is None:
if not connection_type:
connection_type = SCHEME_TO_CONNECTION[scheme]
certs = list(self.certificates.iter(authority))
if issubclass(connection_type, HTTPSConnectionWithTimeout):
if certs:
conn = self.connections[conn_key] = connection_type(
authority,
key_file=certs[0][0],
cert_file=certs[0][1],
timeout=self.timeout,
proxy_info=self.proxy_info,
ca_certs=self.ca_certs,
disable_ssl_certificate_validation=self.disable_ssl_certificate_validation,
tls_maximum_version=self.tls_maximum_version,
tls_minimum_version=self.tls_minimum_version,
)
else:
> conn = self.connections[conn_key] = connection_type(
authority,
timeout=self.timeout,
proxy_info=self.proxy_info,
ca_certs=self.ca_certs,
disable_ssl_certificate_validation=self.disable_ssl_certificate_validation,
tls_maximum_version=self.tls_maximum_version,
tls_minimum_version=self.tls_minimum_version,
)
E TypeError: __init__() got an unexpected keyword
argument 'tls_maximum_version'
/usr/lib/python3/dist-packages/httplib2/__init__.py:1787: TypeError
___ test_https_default_port
def test_https_default_port():
with InstalledApp(wsgi_app.simple_app, host=HOST, port=443) as app:
http = httplib2.Http()
> resp, content = http.request(
'https://some_hopefully_nonexistant_domain/')
wsgi_intercept/tests/test_httplib2.py:73:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
uri = 'https://some_hopefully_nonexistant_domain/', method = 'GET', body = None
headers = {'user-agent': 'Python-httplib2/0.14.0 (gzip)'}, redirections = 5
co
Bug#851747: sysvinit-utils: drop Essential flag
Hi Michael, On Tue, Jan 28, 2020 at 04:38:36PM +0100, Michael Biebl wrote: > Hi Andreas, > > thanks for your interest in this topic. Thanks for your interest in my interest. :) Always nice with some feedback. > > Aside from /bin/pidof, we also have ... a bunch of niche tools that has been discussed before. I haven't really looked at these recently but I guess not much has changed, except maybe init-d-script has gotten a bit wider usage. Will try to give some kind of updated status for these below... > > /sbin/fstab-decode Still only 2 users found by codesearch: drbl, open-iscsi > /sbin/killall5 Still very few users. The following codesearch hits seemed somewhat relevant to investigate: util-vserver, apcupsd, lxc-templates (likely not shipped), drbl, rear > > I haven't checked codesearch if those binaries are used outside of > sysvinit/initscripts. Have you investigated those recently? > > > And there is also > /lib/init/init-d-script In the past this had few users. These days I'd say the better fix than adding sysvinit-utils dependency is to just require users of init-d-script to also ship a masking native systemd unit. There are 73 total hits for init-d-script on codesearch (including false positives like lintian), so certainly still manageable. > /lib/init/vars.sh >From random samples this seems exctusively used from init scripts (and examples of init scripts), so I'd say a masking native systemd unit would be my preferable fix (rather than a sysvinit-utils dependency). There are 280 codesearch hits. > > Those are the more tricky ones. A lot of init scripts use them. > Not having those installed will render the init scripts of packages > broken. It's less of an issue, if a package ships a native service file. > (Do we know for how many this is the case, i.e. no .service file, SysV > init script using init-d-script and/or vars.sh?) (I just have to start by saying, dropping 'Essential: yes' doesn't mean people will stop having sysvinit-utils installed. The literal definition of 'Priority: required' is that your system will break if you remove this package. I guess you're thinking ahead of potential future lowering the priority) I haven't investigated how many of the init-d-script and vars.sh issues are already solved. I'll however volunteer to look all of the affected packages over (and hopefully submit patches for them) once the 'Essential: yes' bit is dropped. (I'll *not* look them over before 'Essential: yes' is dropped, simply because that's alot of work that will rot and will have to be redone again and again and again. So just a waste of my time.) > Also, we have /etc/init.d/foo → redirection to systemctl broken unless > /lib/lsb/init-functions is the first thing that is sourced. > Maybe that breakage is acceptable? Dunno. > What are your thoughts here? I think at as time goes by assuming people being used to init scripts rather than systemctl/service commands becomes less and less true. I might be to progressive but I'd say we're now at a point where it's not very important to keep shielding the users from mistakes like directly invoking an init script. While many oldtimers could likely spell out the full /etc/init.d/foo path of a number of important services in their sleep, I also think there's a whole generation of people around now that administer systems without knowing what /etc/init.d does at all. > > Given the size of the sysvinit-utils package, last time I looked into > this I concluded it's probably not worth the trouble. But maybe things > have changed by now. I agree with this, but the reason I'm here again is because I've managed to tick off most of the issues which had higher payoff already. It's this one and #833256 (where I'd make the new packages non-essential in the same go) left from my old investigations then there are the "legendary" ideas that is as insane/unrealistic amount of work like getting bash or perl out of the base. (But the value is not very high there either, so I'd say it's even less worth to work on that than this.) Then there's things that might really painful (if at all possible) but more rewarding, like shrinking the largest packages in the base system: e.g. coreutils. While size is one factor, I think getting rid of essential where not needed has value in that dependencies can actually be properly declared/tracked. For all the normal reasons in debian why being able to track the dependencies is good, there's also likely value in bootstrapping as well as more easily being able to build custom minimal systems. Regards, Andreas Henriksson
Bug#950039: pyglet FTBFS with Python 3.8 as supported version
Source: pyglet
Version: 1.4.1-3
Severity: serious
Tags: ftbfs
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyglet.html
...
I: pybuild base:217: cd
/build/1st/pyglet-1.4.1/.pybuild/cpython3_3.8_pyglet/build; python3.8 -m pytest
>/dev/null 2>&1; cd /build/1st/pyglet-1.4.1/.pybuild/cpython3_3.8_pyglet/build;
xvfb-run --auto-servernum --server-num=20 -s "-screen 0 1024x768x24 -ac
+extension GLX +render -noreset" python3.8 -m pytest -v -k " not interactive
and not PulseAudio and not test_pulse and not test_player_play and not
test_player_play_multiple and not test_freetype_face and not test_fontconfig
and not test_linux_fontconfig and not test_driver and not test_openal and not
ClockTimingTestCase"
ImportError while loading conftest
'/build/1st/pyglet-1.4.1/.pybuild/cpython3_3.8_pyglet/build/tests/conftest.py'.
tests/conftest.py:18: in
from .base.event_loop import event_loop
tests/base/event_loop.py:10: in
from pyglet.graphics import Batch
pyglet/graphics/__init__.py:171: in
from pyglet.gl import *
pyglet/gl/__init__.py:222: in
from .xlib import XlibConfig as Config
pyglet/gl/xlib.py:40: in
from pyglet.canvas.xlib import XlibCanvas
pyglet/canvas/__init__.py:112: in
from pyglet.canvas.xlib import XlibDisplay as Display
pyglet/canvas/xlib.py:53: in
from . import xlib_vidmoderestore
pyglet/canvas/xlib_vidmoderestore.py:57: in
from pyglet.libs.x11 import xlib
pyglet/libs/x11/xlib.py:2962: in
XEHeadOfExtensionList.argtypes = [XEDataObject]
E TypeError: item 1 in _argtypes_ passes a union by value, which is
unsupported.
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=4: cd
/build/1st/pyglet-1.4.1/.pybuild/cpython3_3.8_pyglet/build; python3.8 -m pytest
>/dev/null 2>&1; cd {build_dir}; xvfb-run --auto-servernum --server-num=20 -s
"-screen 0 1024x768x24 -ac +extension GLX +render -noreset" python{version} -m
pytest -v -k " not interactive and not PulseAudio and not test_pulse and not
test_player_play and not test_player_play_multiple and not test_freetype_face
and not test_fontconfig and not test_linux_fontconfig and not test_driver and
not test_openal and not ClockTimingTestCase"
dh_auto_test: error: pybuild --test -i python{version} -p "3.8 3.7" returned
exit code 13
make: *** [debian/rules:32: build] Error 25
Bug#851747: sysvinit-utils: drop Essential flag
On Tue, Jan 28, 2020 at 05:02:38PM +0100, Michael Biebl wrote: [...] > Assuming the .service isn't just a wrapper around the init script. > Unfortunately, we do have quite a few packages which use this > anti-pattern :-/ > > https://codesearch.debian.net/search?q=ExecStart%3D%2Fetc%2Finit.d%2F&literal=1&perpkg=1 https://lintian.debian.org/tags/systemd-service-file-wraps-init-script.html It seems "Debian OpenStack" is the main offender so unless people use openstack the problem possibly isn't that widely spread. This however serves as a good reminder that it's not enough to just check that there's a masking native systemd unit. (I'll probably forget about that very soon again, but atleast there's now a note/warning about this case in this bugs history! :) (It might be time to ask lintian maintainers to consider raising severity or turning some warnings into errors for systemd-related lintian checks.) Regards, Andreas Henriksson
Bug#950040: pysdl2 FTBFS with libsdl2 2.0.10+dfsg1-1
Source: pysdl2
Version: 0.9.6+dfsg1-1
Severity: serious
Tags: ftbfs
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pysdl2.html
...
=== FAILURES ===
_ SDL2ExtFontTest.test_FontManager_add _
self =
def test_FontManager_add(self):
fm = sdl2ext.FontManager(RESOURCES.get_path("tuffy.ttf"))
self.assertIn("tuffy", fm.aliases)
self.assertIn("tuffy", fm.fonts)
self.assertIn(16, fm.fonts["tuffy"])
self.assertIsInstance(fm.fonts["tuffy"][16].contents, sdlttf.TTF_Font)
# Do some metrics tests
font = fm.fonts["tuffy"][16]
> self.assertEqual(16, sdlttf.TTF_FontAscent(font))
E AssertionError: 16 != 13
sdl2/test/sdl2ext_font_test.py:107: AssertionError
SDLSurfaceTest.test_SDL_ConvertSurface
self =
def test_SDL_ConvertSurface(self):
for idx in pixels.ALL_PIXELFORMATS:
if pixels.SDL_ISPIXELFORMAT_FOURCC(idx):
continue
pfmt = pixels.SDL_AllocFormat(idx)
for fmt in pixels.ALL_PIXELFORMATS:
if pixels.SDL_ISPIXELFORMAT_FOURCC(fmt):
continue
bpp = c_int()
rmask, gmask, bmask, amask = Uint32(), Uint32(), Uint32(),
Uint32()
ret = pixels.SDL_PixelFormatEnumToMasks(fmt, byref(bpp),
byref(rmask),
byref(gmask),
byref(bmask),
byref(amask))
self.assertEqual(ret, SDL_TRUE)
sf = surface.SDL_CreateRGBSurface(0, 10, 20, bpp, rmask, gmask,
bmask, amask)
self.assertIsInstance(sf.contents, surface.SDL_Surface)
csf = surface.SDL_ConvertSurface(sf, pfmt, 0)
> self.assertTrue(csf, error.SDL_GetError())
E AssertionError: is not true : b'Blit combination not supported'
sdl2/test/surface_test.py:103: AssertionError
_ SDLSurfaceTest.test_SDL_ConvertSurfaceFormat _
self =
def test_SDL_ConvertSurfaceFormat(self):
for pfmt in pixels.ALL_PIXELFORMATS:
if pixels.SDL_ISPIXELFORMAT_FOURCC(pfmt):
continue
for fmt in pixels.ALL_PIXELFORMATS:
if pixels.SDL_ISPIXELFORMAT_FOURCC(fmt):
continue
bpp = c_int()
rmask, gmask, bmask, amask = Uint32(), Uint32(), Uint32(),
Uint32()
ret = pixels.SDL_PixelFormatEnumToMasks(fmt, byref(bpp),
byref(rmask),
byref(gmask),
byref(bmask),
byref(amask))
self.assertEqual(ret, SDL_TRUE)
sf = surface.SDL_CreateRGBSurface(0, 10, 20, bpp, rmask, gmask,
bmask, amask)
self.assertIsInstance(sf.contents, surface.SDL_Surface)
csf = surface.SDL_ConvertSurfaceFormat(sf, pfmt, 0)
> self.assertTrue(csf, error.SDL_GetError())
E AssertionError: is not true : b'Blit combination not supported'
sdl2/test/surface_test.py:145: AssertionError
=== warnings summary ===
...
Bug#950009: DNS server marked as DNSSEC-incompatible after query for domain in NTA
Control: forwarded -1 https://github.com/systemd/systemd/issues/11171 Control: found -1 241-7 Am 28.01.20 um 10:56 schrieb Kevin Price: > Package: systemd > Version: 241-7~deb10u2 > Severity: normal > Tags: upstream > > The systemd-resolved keeps downgrading to non-DNSSEC mode every time I query a > local name that is in the NTA. See > https://github.com/systemd/systemd/issues/11171 for details. Thanks, marking accordingly. Since this appears to be unfixed in unstable as well, updating the version information. Michael signature.asc Description: OpenPGP digital signature
Bug#947148: Open MPI and libltdl
I just replied on the upstream Open MPI issue (https://github.com/open-mpi/ompi/issues/7331#issuecomment-579337035): I'm not sure about that test: if you get a valid handle value back from lt_dlopen(), is the value from lt_dlerror() relevant? I.e., is the "handle" value you're getting back from lt_dlopen() invalid? All we can tell from this test is that it's not NULL. Specifically: I'm not sure that calling lt_dlerror() will return anything meaningful if there has been no error. -- Jeff Squyres jsquy...@cisco.com
Bug#950041: python-keystoneauth1 FTBFS: test failures
Source: python-keystoneauth1
Version: 3.17.1-2
Severity: serious
Tags: ftbfs
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-keystoneauth1.html
...
==
FAIL:
keystoneauth1.tests.unit.identity.test_identity_v2.V2IdentityPlugin.test_invalidate_response
keystoneauth1.tests.unit.identity.test_identity_v2.V2IdentityPlugin.test_invalidate_response
--
testtools.testresult.real._StringException: pythonlogging:'': {{{
Making authentication request to http://127.0.0.1:5000/v2.0/tokens
Making authentication request to http://127.0.0.1:5000/v2.0/tokens
}}}
Traceback (most recent call last):
File
"/build/1st/python-keystoneauth1-3.17.1/keystoneauth1/tests/unit/identity/test_identity_v2.py",
line 285, in test_invalidate_response
self.assertEqual({'X-Auth-Token': 'token1'}, s.get_auth_headers())
File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in
assertEqual
self.assertThat(observed, matcher, message)
File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: {'X-Auth-Token': 'token1'} !=
{'X-Auth-Token': 'token2'}
==
FAIL:
keystoneauth1.tests.unit.identity.test_identity_v3.V3IdentityPlugin.test_invalidate_response
keystoneauth1.tests.unit.identity.test_identity_v3.V3IdentityPlugin.test_invalidate_response
--
testtools.testresult.real._StringException: pythonlogging:'': {{{
Making authentication request to http://127.0.0.1:5000/v3/auth/tokens
{"token": {"methods": ["token", "password"], "expires_at":
"2020-01-01T00:00:10.000123Z", "project": {"domain": {"id":
"4b8695d2a3bb47fd858dc2b03da5b605", "name":
"59c5f86834f640559f20e75cf524c8ee"}, "id": "5c4cf623562b46f7a06e41576f872dd7",
"name": "036b75a8fd394f06955c97b1e006cbd5"}, "user": {"domain": {"id":
"4b8695d2a3bb47fd858dc2b03da5b605", "name":
"59c5f86834f640559f20e75cf524c8ee"}, "id": "2292e3ad58ea44a6a9cdff82fd804ea8",
"name": "2292e3ad58ea44a6a9cdff82fd804ea8"}, "issued_at":
"2013-05-29T16:55:21.468960Z", "catalog": [{"endpoints": [{"url":
"http://cdn.admin-nets.local:8774/v1.0/";, "region": "RegionOne", "interface":
"public"}, {"url": "http://127.0.0.1:8774/v1.0";, "region": "RegionOne",
"interface": "internal"}, {"url": "http://cdn.admin-nets.local:8774/v1.0";,
"region": "RegionOne", "interface": "admin"}], "type": "nova_compat"},
{"endpoints": [{"url": "http://nova/novapi/public";, "region": "RegionOne",
"interface": "public"}, {"url": "http://nova/novapi/internal";, "region":
"RegionOne", "interface": "internal"}, {"url": "http://nova/novapi/admin";,
"region": "RegionOne", "interface": "admin"}], "type": "compute", "name":
"nova"}, {"endpoints": [{"url": "http://glance/glanceapi/public";, "region":
"RegionOne", "interface": "public"}, {"url":
"http://glance/glanceapi/internal";, "region": "RegionOne", "interface":
"internal"}, {"url": "http://glance/glanceapi/admin";, "region": "RegionOne",
"interface": "admin"}], "type": "image", "name": "glance"}, {"endpoints":
[{"url": "http://127.0.0.1:5000/v3";, "region": "RegionOne", "interface":
"public"}, {"url": "http://127.0.0.1:5000/v3";, "region": "RegionOne",
"interface": "internal"}, {"url": "http://127.0.0.1:35357/v3";, "region":
"RegionOne", "interface": "admin"}], "type": "identity"}, {"endpoints":
[{"url": "http://swift/swiftapi/public";, "region": "RegionOne", "interface":
"public"}, {"url": "http://swift/swiftapi/internal";, "region": "RegionOne",
"interface": "internal"}, {"url": "http://swift/swiftapi/admin";, "region":
"RegionOne", "interface": "admin"}], "type": "object-store"}],
"service_providers": [{"auth_url":
"https://sp1.com/v3/OS-FEDERATION/identity_providers/acme/protocols/saml2/auth";,
"id": "sp1", "sp_url": "https://sp1.com/Shibboleth.sso/SAML2/ECP"},
{"auth_url":
"https://sp2.com/v3/OS-FEDERATION/identity_providers/acme/protocols/saml2/auth";,
"id": "sp2", "sp_url": "https://sp2.com/Shibboleth.sso/SAML2/ECP"}]}}
Making authentication request to http://127.0.0.1:5000/v3/auth/tokens
{"token": {"methods": ["token", "password"], "expires_at":
"2020-01-01T00:00:10.000123Z", "project": {"domain": {"id":
"4b8695d2a3bb47fd858dc2b03da5b605", "name":
"59c5f86834f640559f20e75cf524c8ee"}, "id": "5c4cf623562b46f7a06e41576f872dd7",
"name": "036b75a8fd394f06955c97b1e006cbd5"}, "user": {"domain": {"id":
"4b8695d2a3bb47fd858dc2b03da5b605", "name":
"59c5f86834f640559f20e75cf524c8ee"}, "id": "2292e3ad58ea44a6a9cdff82fd804ea8",
"name": "2292e3ad58ea44a6a9cdff82fd804ea8"}, "issued_at":
"2013-05-29T16:55:21.468960Z", "catalog": [{"endpoints": [{"url":
"http://cdn.admin-nets.local:8774/v1.0/";, "region": "RegionOne", "interface":
"public"}, {"url":
Bug#950042: python-oslo.privsep FTBFS: test failures
Source: python-oslo.privsep
Version: 1.33.3-2
Severity: serious
Tags: ftbfs
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-oslo.privsep.html
...
==
FAIL: oslo_privsep.tests.test_daemon.LogTest.test_record_data
oslo_privsep.tests.test_daemon.LogTest.test_record_data
--
testtools.testresult.real._StringException: traceback-1: {{{
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 197, in setUp
self._setUp()
File "/usr/lib/python3/dist-packages/fixtures/_fixtures/logger.py", line 112,
in _setUp
handler.setFormatter(formatter(self._format, self._datefmt))
File
"/build/1st/python-oslo.privsep-1.33.3/oslo_privsep/tests/test_daemon.py", line
62, in __init__
super(LogRecorder, self).__init__(*args, **kwargs)
File "/usr/lib/python3.8/logging/__init__.py", line 576, in __init__
self._style.validate()
File "/usr/lib/python3.8/logging/__init__.py", line 429, in validate
raise ValueError("Invalid format '%s' for '%s' style" % (self._fmt,
self.default_format[0]))
ValueError: Invalid format 'dummy' for '%' style
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 208, in setUp
raise SetupError(details)
fixtures.fixture.SetupError: {"pythonlogging:''": }
}}}
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 197, in setUp
self._setUp()
File "/usr/lib/python3/dist-packages/fixtures/_fixtures/logger.py", line 112,
in _setUp
handler.setFormatter(formatter(self._format, self._datefmt))
File
"/build/1st/python-oslo.privsep-1.33.3/oslo_privsep/tests/test_daemon.py", line
62, in __init__
super(LogRecorder, self).__init__(*args, **kwargs)
File "/usr/lib/python3.8/logging/__init__.py", line 576, in __init__
self._style.validate()
File "/usr/lib/python3.8/logging/__init__.py", line 429, in validate
raise ValueError("Invalid format '%s' for '%s' style" % (self._fmt,
self.default_format[0]))
ValueError: Invalid format 'dummy' for '%' style
==
FAIL: oslo_privsep.tests.test_daemon.LogTest.test_format_record
oslo_privsep.tests.test_daemon.LogTest.test_format_record
--
testtools.testresult.real._StringException: traceback-1: {{{
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 197, in setUp
self._setUp()
File "/usr/lib/python3/dist-packages/fixtures/_fixtures/logger.py", line 112,
in _setUp
handler.setFormatter(formatter(self._format, self._datefmt))
File
"/build/1st/python-oslo.privsep-1.33.3/oslo_privsep/tests/test_daemon.py", line
62, in __init__
super(LogRecorder, self).__init__(*args, **kwargs)
File "/usr/lib/python3.8/logging/__init__.py", line 576, in __init__
self._style.validate()
File "/usr/lib/python3.8/logging/__init__.py", line 429, in validate
raise ValueError("Invalid format '%s' for '%s' style" % (self._fmt,
self.default_format[0]))
ValueError: Invalid format 'dummy' for '%' style
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 208, in setUp
raise SetupError(details)
fixtures.fixture.SetupError: {"pythonlogging:''": }
}}}
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 197, in setUp
self._setUp()
File "/usr/lib/python3/dist-packages/fixtures/_fixtures/logger.py", line 112,
in _setUp
handler.setFormatter(formatter(self._format, self._datefmt))
File
"/build/1st/python-oslo.privsep-1.33.3/oslo_privsep/tests/test_daemon.py", line
62, in __init__
super(LogRecorder, self).__init__(*args, **kwargs)
File "/usr/lib/python3.8/logging/__init__.py", line 576, in __init__
self._style.validate()
File "/usr/lib/python3.8/logging/__init__.py", line 429, in validate
raise ValueError("Invalid format '%s' for '%s' style" % (self._fmt,
self.default_format[0]))
ValueError: Invalid format 'dummy' for '%' style
--
Ran 35 tests in 111.913s
FAILED (failures=2)
make[1]: *** [debian/rules:20: override_dh_auto_install] Error 1
Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
On Sat, Jan 25, 2020 at 06:08:34PM +0100, Mattia Rizzolo wrote: > On Fri, Jan 24, 2020 at 09:28:29PM +, Adam D. Barratt wrote: > > I'm aware that you both called them trivialities and quoted > > "breakages", but is it worth documenting any of them somewhere in the > > package? > > I could probably add a NEWS item for the ACMEv2 default move, as that's > probably something interesting to many. I've no added this: diff --git a/debian/dehydrated.NEWS b/debian/dehydrated.NEWS new file mode 100644 index 000..1bc0fae --- /dev/null +++ b/debian/dehydrated.NEWS @@ -0,0 +1,12 @@ +dehydrated (0.6.2-2+deb10u1~deb9u1) stretch; urgency=medium + + This update changes the default API endpoint to use ACMEv2, as ACMEv1 is + in the process of being deprecated and Let's Encrypt will stop supporting it + in the upcoming months. + This change will, amongst others, bring new features like wildcard + certificates support; however, it also slightly changes the authorization + flow, which may impact a few users, especially those using DNS validation. + Another incompatible change, is the addition of a new --accept-terms command + line flag, required when registering a new account. + + -- Mattia Rizzolo Tue, 28 Jan 2020 17:33:15 +0100 Apart from that and an updated d/changelog, the thing is the same of the previously sent diff. With that, I've uploaed the package for convenience of your review. -- 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#950026:
The bug is already reported upstream: https://github.com/cminyard/ser2net/issues/17#event-2985783322. A fix commit is available under:. https://github.com/cminyard/ser2net/commit/69195f8e9b2ce866d2739663b8d6cab97a572023
Bug#950043: python-invocations FTBFS: test failures
Source: python-invocations Version: 0.6.2-3 Severity: serious Tags: ftbfs https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-invocations.html ... == ERROR: testing (unittest.loader._FailedTest) -- ImportError: Failed to import test module: testing Traceback (most recent call last): File "/usr/lib/python3.8/unittest/loader.py", line 154, in loadTestsFromName module = __import__(module_name) File "/build/1st/python-invocations-0.6.2/invocations/testing.py", line 1, in from invoke import ctask as task ImportError: cannot import name 'ctask' from 'invoke' (/usr/lib/python3/dist-packages/invoke/__init__.py) == ERROR: packaging (unittest.loader._FailedTest) -- ImportError: Failed to import test module: packaging Traceback (most recent call last): File "/usr/lib/python3.8/unittest/loader.py", line 154, in loadTestsFromName module = __import__(module_name) File "/build/1st/python-invocations-0.6.2/invocations/packaging.py", line 6, in from invoke import ctask as task, Collection ImportError: cannot import name 'ctask' from 'invoke' (/usr/lib/python3/dist-packages/invoke/__init__.py) == ERROR: docs (unittest.loader._FailedTest) -- ImportError: Failed to import test module: docs Traceback (most recent call last): File "/usr/lib/python3.8/unittest/loader.py", line 154, in loadTestsFromName module = __import__(module_name) File "/build/1st/python-invocations-0.6.2/invocations/docs.py", line 3, in from invoke import ctask as task, Collection ImportError: cannot import name 'ctask' from 'invoke' (/usr/lib/python3/dist-packages/invoke/__init__.py) == ERROR: invocations.testing (unittest.loader._FailedTest) -- ImportError: Failed to import test module: invocations.testing Traceback (most recent call last): File "/usr/lib/python3.8/unittest/loader.py", line 436, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib/python3.8/unittest/loader.py", line 377, in _get_module_from_name __import__(name) File "/build/1st/python-invocations-0.6.2/invocations/testing.py", line 1, in from invoke import ctask as task ImportError: cannot import name 'ctask' from 'invoke' (/usr/lib/python3/dist-packages/invoke/__init__.py) -- Ran 4 tests in 0.001s FAILED (errors=4) Test failed: error: Test failed: make[1]: *** [debian/rules:22: override_dh_auto_install] Error 1
Bug#950045: python-morph FTBFS: test failure
Source: python-morph
Version: 0.1.3-1
Severity: serious
Tags: ftbfs bullseye sid
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-morph.html
...
==
FAIL: test_xform_combined (morph.test.TestMorph)
--
Traceback (most recent call last):
File "/build/1st/python-morph-0.1.3/morph/test.py", line 307, in
test_xform_combined
self.assertEqual(stack, [
AssertionError: Lists differ: [('key', {'root': {'key': [8, {'k2': -2}]},[301
chars]2}})] != [(8, {'index': 0, 'seq': [8, {'k2': -2}], '[301 chars]]}})]
First differing element 0:
('key', {'root': {'key': [8, {'k2': -2}]},[61 chars]}]}})
(8, {'index': 0, 'seq': [8, {'k2': -2}], '[28 chars]}]}})
+ [(8, {'index': 0, 'root': {'key': [8, {'k2': -2}]}, 'seq': [8, {'k2': -2}]}),
+ (-2, {'dict': {'k2': -2}, 'item_key': 'k2', 'root': {'key': [8, {'k2':
-2}]}}),
+ ('k2',
+ {'dict': {'k2': -2}, 'item_value': -2, 'root': {'key': [8, {'k2': -2}]}}),
- [('key',
? ^
+ ('key',
? ^
{'dict': {'key': [8, {'k2': -2}]},
'item_value': [8, {'k2': -2}],
-'root': {'key': [8, {'k2': -2}]}}),
? ^
+'root': {'key': [8, {'k2': -2}]}})]
? ^
- (8, {'index': 0, 'root': {'key': [8, {'k2': -2}]}, 'seq': [8, {'k2': -2}]}),
- ('k2',
- {'dict': {'k2': -2}, 'item_value': -2, 'root': {'key': [8, {'k2': -2}]}}),
- (-2, {'dict': {'k2': -2}, 'item_key': 'k2', 'root': {'key': [8, {'k2':
-2}]}})]
--
Ran 17 tests in 0.007s
FAILED (failures=1)
Test failed:
error: Test failed:
make[1]: *** [debian/rules:20: override_dh_auto_install] Error 1
