Bug#938676: tomahawk: diff for NMU version 0.7.1-2.1
Control: tags 938676 + patch
Dear maintainer,
I've prepared an NMU for tomahawk (versioned as 0.7.1-2.1). The diff
is attached to this message.
Regards.
diff -Nru tomahawk-0.7.1/debian/changelog tomahawk-0.7.1/debian/changelog
--- tomahawk-0.7.1/debian/changelog 2015-07-05 18:47:45.0 -0400
+++ tomahawk-0.7.1/debian/changelog 2020-01-01 02:04:09.0 -0500
@@ -1,3 +1,10 @@
+tomahawk (0.7.1-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python2 support; Closes: #938676
+
+ -- Sandro Tosi Wed, 01 Jan 2020 02:04:09 -0500
+
tomahawk (0.7.1-2) unstable; urgency=medium
* debian/control
diff -Nru tomahawk-0.7.1/debian/control tomahawk-0.7.1/debian/control
--- tomahawk-0.7.1/debian/control 2015-07-05 18:46:38.0 -0400
+++ tomahawk-0.7.1/debian/control 2020-01-01 02:03:14.0 -0500
@@ -4,14 +4,6 @@
Maintainer: Kouhei Maeda
Build-Depends: debhelper (>= 8.0.0),
dh-python,
- python-all,
- python-setuptools,
- python-coverage,
- python-flexmock,
- python-pytest,
- python-flexmock,
- python-pexpect,
- python-six,
python3-all,
python3-setuptools,
python3-coverage,
@@ -25,23 +17,8 @@
openssh-server,
openssh-client
Standards-Version: 3.9.6
-X-Python-Version: >= 2.7
Homepage: https://github.com/oinume/tomahawk
-Package: python-tomahawk
-Architecture: all
-Provides: ${python:Provides}
-Depends: ${misc:Depends},
- ${python:Depends},
- python-pexpect,
- python-six,
- rsync,
- openssh-client
-Description: simple ssh wrapper for executing commands into many hosts
- Enables following 3 things. Executing remote commands tool via ssh to multi
- remote hosts. Copy local files to many remote hosts. Copy files from remote
- hosts to local.
-
Package: python3-tomahawk
Architecture: all
Depends: ${misc:Depends},
diff -Nru tomahawk-0.7.1/debian/pydist-overrides tomahawk-0.7.1/debian/pydist-overrides
--- tomahawk-0.7.1/debian/pydist-overrides 2011-12-03 04:23:30.0 -0500
+++ tomahawk-0.7.1/debian/pydist-overrides 1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-argparse python-argparse
-pexpect python-pexpect
diff -Nru tomahawk-0.7.1/debian/python-tomahawk.manpages tomahawk-0.7.1/debian/python-tomahawk.manpages
--- tomahawk-0.7.1/debian/python-tomahawk.manpages 2012-06-24 22:36:53.0 -0400
+++ tomahawk-0.7.1/debian/python-tomahawk.manpages 1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-man/man1/tomahawk.1
-man/man1/tomahawk-rsync.1
diff -Nru tomahawk-0.7.1/debian/rules tomahawk-0.7.1/debian/rules
--- tomahawk-0.7.1/debian/rules 2014-09-03 22:27:44.0 -0400
+++ tomahawk-0.7.1/debian/rules 2020-01-01 02:03:45.0 -0500
@@ -9,7 +9,7 @@
export PYBUILD_TEST_ARGS={build_dir}/tests/internal
%:
- dh $@ --with python2,python3 --buildsystem=pybuild
+ dh $@ --with python3 --buildsystem=pybuild
override_dh_python3:
dh_python3
@@ -17,10 +17,6 @@
mv -f $(CURDIR)/debian/python3-tomahawk/usr/bin/tomahawk-rsync $(CURDIR)/debian/python3-tomahawk/usr/bin/tomahawk-rsync3
find $(CURDIR)/debian -name tests | xargs rm -rf
-override_dh_python2:
- dh_python2
- find $(CURDIR)/debian -name tests | xargs rm -rf
-
override_dh_clean:
dh_clean
rm -f $(CURDIR)/requirements*.txt
Bug#945652: i3lock-fancy: diff for NMU version 0.0~git20160228.0.0fcb933-2.1
Control: tags 945652 + patch
Dear maintainer,
I've prepared an NMU for i3lock-fancy (versioned as
0.0~git20160228.0.0fcb933-2.1). The diff
is attached to this message.
Regards.
diff -Nru i3lock-fancy-0.0~git20160228.0.0fcb933/debian/changelog i3lock-fancy-0.0~git20160228.0.0fcb933/debian/changelog
--- i3lock-fancy-0.0~git20160228.0.0fcb933/debian/changelog 2018-01-25 23:54:36.0 -0500
+++ i3lock-fancy-0.0~git20160228.0.0fcb933/debian/changelog 2020-01-01 02:00:53.0 -0500
@@ -1,3 +1,10 @@
+i3lock-fancy (0.0~git20160228.0.0fcb933-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python-tomahawk as alternative dependency; Closes: #945652
+
+ -- Sandro Tosi Wed, 01 Jan 2020 02:00:53 -0500
+
i3lock-fancy (0.0~git20160228.0.0fcb933-2) unstable; urgency=medium
* Move to salsa.debian.org.
diff -Nru i3lock-fancy-0.0~git20160228.0.0fcb933/debian/control i3lock-fancy-0.0~git20160228.0.0fcb933/debian/control
--- i3lock-fancy-0.0~git20160228.0.0fcb933/debian/control 2018-01-25 23:54:05.0 -0500
+++ i3lock-fancy-0.0~git20160228.0.0fcb933/debian/control 2020-01-01 02:00:42.0 -0500
@@ -11,7 +11,7 @@
Package: i3lock-fancy
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, i3lock, imagemagick, scrot, gawk | cpl-plugin-hawki-calib | cpl-plugin-hawki-doc | mawk | original-awk | python-tomahawk
+Depends: ${shlibs:Depends}, ${misc:Depends}, i3lock, imagemagick, scrot, gawk | cpl-plugin-hawki-calib | cpl-plugin-hawki-doc | mawk | original-awk
Suggests: wmctrl, maim
Description: i3lock custom wrapper script
i3lock bash script that takes a screenshot of the desktop, blurs the
Bug#945730: pyconfigure: diff for NMU version 0.2.3-2.1
Control: tags 945730 + patch Dear maintainer, I've prepared an NMU for pyconfigure (versioned as 0.2.3-2.1). The diff is attached to this message. Regards. diff -Nru pyconfigure-0.2.3/debian/changelog pyconfigure-0.2.3/debian/changelog --- pyconfigure-0.2.3/debian/changelog 2018-09-15 16:27:14.0 -0400 +++ pyconfigure-0.2.3/debian/changelog 2020-01-01 01:36:55.0 -0500 @@ -1,3 +1,10 @@ +pyconfigure (0.2.3-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Drop python-setuptools from Recommends; Closes: #945730 + + -- Sandro Tosi Wed, 01 Jan 2020 01:36:55 -0500 + pyconfigure (0.2.3-2) unstable; urgency=low * Bump Standards-Version to 4.2.1 diff -Nru pyconfigure-0.2.3/debian/control pyconfigure-0.2.3/debian/control --- pyconfigure-0.2.3/debian/control 2018-09-15 16:22:46.0 -0400 +++ pyconfigure-0.2.3/debian/control 2020-01-01 01:36:43.0 -0500 @@ -17,7 +17,7 @@ python3, autoconf, Recommends: - python3-setuptools | python-setuptools, + python3-setuptools, Description: automatic configure script builder for Python software GNU pyconfigure provides developers with file templates for implementing standard `configure' scripts and `Makefile' recipes for their Python packages.
Bug#947867: RM: src:libjs-i18next -- ROM; Duplicate of node-i18next
Package: ftp.debian.org Severity: normal Hi, binary libjs-i18next is provided by: * src: node-i18next * src: libjs-i18next The first is up-to-date and provide both browser and node libraries, not the second. So I propose to remove src:libjs-i18next from our archive. Cheers, Xavier
Bug#930774: any idea when guile-2.2 will be fixed ?
Hi all, Just saw this, any idea when this FTFBS will be fixed. Somebody even shared a patch, maybe that fixes the issue. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#938311: qbittorrent: Python2 removal in sid/bullseye
On Fri, 30 Aug 2019 07:49:25 + Matthias Klose wrote: > Package: src:qbittorrent > Version: 4.1.7-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal from a quick look at qbittorrent code, the binary is able to detect the installed version and pick the right one, so it looks to me the fix is simply to replace `python (>= 2.5)` with `python3`. (we can even go a step further and drop entirely py2 support, as in this commit https://github.com/qbittorrent/qBittorrent/commit/7d030b4cd9cc1d1b2af80b7fcbee3248885e6d55 , now reverted as part of https://github.com/qbittorrent/qBittorrent/issues/7005 ) Cristina/Andrew, this seems a very easy fix: do you want to go ahead and apply and upload or rather me do that? Cheers, Sandro
Bug#945193: O: libvigraimpex -- C++ computer vision library
Control: owner -1 ametz...@debian.org Control: retitle -1 ITA: libvigraimpex -- C++ computer vision library On 2019-12-30 Andreas Metzler wrote: [...] > I intend to keep this in shape to the best I can do with QA uploads. I > will not properly adopt since my C++ foo is weak. Since Daniel Haley has offered to help along with C++ issues I am going to adopt this. cu Andreas signature.asc Description: PGP signature
Bug#947754: [omv.dynamicpuzzle.ro] gitlab mattermost integration error
Package: gitlab
Version: 12.5.4-2+fto10+1
Followup-For: Bug #947754
Another case with the error, but in this case is not for use oauth directly,
nor for sentry server integration.
(Anyways, apparently Sentry it's trying to do an oauth authentication before
starting process, it's the same error apparently.
This case are only tested on 12.5.4
Started GET
"/oauth/authorize?scope=api&state=&redirect_uri=https%3A%2F%2F>sentry.fqdn>%2Fextensions%2Fgitlab%2Fsetup%2F&response_type=code&client_id="
for x.x.x.x at 2020-01-01 05:32:14 +0100
Processing by Oauth::AuthorizationsController#new as HTML
Parameters: {"scope"=>"api", "state"=>"",
"redirect_uri"=>"https:///extensions/gitlab/setup/",
"response_type"=>"code", "client_id"=>""}
Completed 500 Internal Server Error in 5ms (ActiveRecord: 0.5ms |
Elasticsearch: 0.0ms)
NoMethodError (undefined method `mapping' for Doorkeeper::Rails::Routes:Class):
lib/gitlab/request_profiler/middleware.rb:17:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:13:in `call'
lib/gitlab/middleware/correlation_id.rb:16:in `block in call'
lib/gitlab/middleware/correlation_id.rb:15:in `call'
lib/gitlab/middleware/multipart.rb:117:in `call'
lib/gitlab/middleware/read_only/controller.rb:48:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:32:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:49:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
Bug#918506: spamassassin: A year later the bug is still present
Package: spamassassin Version: 3.4.2-1+deb10u1 Followup-For: Bug #918506 It's been a year since the last update and the bug is still present. Is spamassassin still maintained? I see there's a package in testing but I am assuming it won't make it to stable, will it? Will this bug be fixed in the stable package? Is it fixed in the testing package? Thank you for your help! -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages spamassassin depends on: ii adduser 3.118 ii curl 7.64.0-4 ii init-system-helpers 1.56+nmu1 ii libhtml-parser-perl 3.72-3+b3 ii libhttp-date-perl6.02-1 ii libmail-dkim-perl0.54-1 ii libnet-dns-perl 1.19-1 ii libnetaddr-ip-perl 4.079+dfsg-1+b3 ii libsocket6-perl 0.29-1+b1 ii libsys-hostname-long-perl1.5-1 ii libwww-perl 6.36-2 ii lsb-base 10.2019051400 ii perl [libarchive-tar-perl] 5.28.1-6 ii perl-modules-5.24 [libarchive-tar-perl] 5.24.1-3+deb9u5 ii perl-modules-5.26 [libarchive-tar-perl] 5.26.1-3 ii w3m 0.5.3-37 Versions of packages spamassassin recommends: ii gnupg 2.2.12-1+deb10u1 ii libio-socket-inet6-perl2.72-2 ii libmail-spf-perl 2.9.0-4 ii perl [libsys-syslog-perl] 5.28.1-6 ii sa-compile 3.4.2-1+deb10u1 ii spamc 3.4.2-1+deb10u1 Versions of packages spamassassin suggests: ii libdbi-perl 1.642-1+b1 pn libencode-detect-perl pn libgeo-ip-perl ii libio-socket-ssl-perl 2.060-3 pn libnet-patricia-perl ii perl [libcompress-zlib-perl] 5.28.1-6 pn pyzor ii razor 1:2.85-4.2+b5 -- Configuration Files: /etc/cron.daily/spamassassin [Errno 13] Permission denied: '/etc/cron.daily/spamassassin' -- no debconf information
Bug#946327: khotkeys FTBFS: fixed upstream
Control: tags -1 fixed-upstream The package builds with the following two commits applied in order: https://cgit.kde.org/khotkeys.git/diff/?id=67fd8f06 https://cgit.kde.org/khotkeys.git/diff/?id=ae574373 The former one makes many changes, but appears to be related only due to removing a blank line in a file, so that change could probably be consolidated. A naive uscan and uupdate got me to 5.17.4. With no additional changes this builds fine in sbuild, so maybe a new release would be more convenient. signature.asc Description: This is a digitally signed message part.
Bug#947865: pyopencl: FTBFS in sid
Source: pyopencl Version: 2019.1.1-1 Severity: serious Tags: patch Justification: FTBFS Hello, pyopencl currently FTBFS in sid because apparently moved to libgl-dev. The attached patch fixes that. Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Samuel Linux, c'est simple : ça s'adresse à une machine qui est parfois un peu maraboutée mais qui d'habitude n'a pas d'états d'âme. Sur Usenet y'a plein d'humains et de primates, et ça devient vraiment gore par moment. -+- TP in : Guide du linuxien pervers - "Le linuxien a-t-il une âme ?" -+- --- debian/control.original 2020-01-01 02:25:30.482219682 +0100 +++ debian/control 2020-01-01 02:25:33.052221180 +0100 @@ -15,7 +15,7 @@ python3-setuptools, opencl-c-headers, ocl-icd-opencl-dev | opencl-dev, - mesa-common-dev, + mesa-common-dev, libgl-dev, python3-numpy, python3-sphinx (>= 1.0.7+dfsg) , python3-mako,
Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output
On Thu, Dec 05, 2019 at 11:03:57AM -0500, Dan Davison wrote: > I am looking for a sponsor for my package "git-delta": Hi! Last year, you started preparing this package. As it's something extremely useful, I'm anxious to see it in Debian. The alternatives suck. Alas, git-delta is written in some heathen language I don't know how to deal with (Rust's own package manager pollutes quite a bit of the system), thus it would be nice to have it properly packaged so doofuses like me can use it. Thus, a ping. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#947863: lxc: apparmor denied mount with unprivileged lxc
Package: lxc
Version: 1:3.1.0+really3.0.4-2
Severity: normal
Hi,
when booting into a system started with unprivileged lxc, I'm getting
the following errors:
[5.818300] audit: type=1400 audit(1577840118.455:15): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=388 comm="(md-udevd)"
flags="rw, rslave"
[5.842226] audit: type=1400 audit(1577840118.479:16): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=389 comm="(md-udevd)"
flags="rw, rslave"
[5.875326] audit: type=1400 audit(1577840118.511:17): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=390 comm="(md-udevd)"
flags="rw, rslave"
[5.894556] audit: type=1400 audit(1577840118.531:18): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=391 comm="(md-udevd)"
flags="rw, rslave"
[5.919489] audit: type=1400 audit(1577840118.555:19): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=392 comm="(md-udevd)"
flags="rw, rslave"
[6.368326] audit: type=1400 audit(1577840119.003:20): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=398 comm="(modprobe)"
flags="rw, rslave"
[6.390053] audit: type=1400 audit(1577840119.027:21): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=400 comm="(d-logind)"
flags="rw, rslave"
[6.400681] audit: type=1400 audit(1577840119.035:22): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=405 comm="(modprobe)"
flags="rw, rslave"
[6.406682] audit: type=1400 audit(1577840119.043:23): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=406 comm="(d-logind)"
flags="rw, rslave"
[6.416232] audit: type=1400 audit(1577840119.051:24): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=409 comm="(modprobe)"
flags="rw, rslave"
These errors keep repeating. The only way to silence them I found so far
is to disable apparmor. But maybe the default lxc apparmor profile could
be adjusted to prevent these errors?
To reproduce the problem, please see the attached shell script which you
can run without superuser privileges if you have
kernel.unprivileged_userns_clone set to 1. After running the script, the
errors above can be seen in qemu.log.
Thanks!
cheers, josch
#!/bin/sh
# Copyright 2019 Johannes 'josch' Schauer
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
set -exu
# Reasons to use qemu:
# - can also be run with autopkgtest backends that do not support
# - can be run without superuser privileges outside of autopkgtest
if [ -z ${AUTOPKGTEST_TMP+x} ]; then
# if AUTOPKGTEST_TMP is not set, then this script is probably not
# executed under autopkgtest, choose unshare mode for mmdebstrap so
# that this script can be run without superuser privileges
MODE="unshare"
else
# since AUTOPKGTEST_TMP is set, we assume that this script is executed
# under autopkgtest --> switch to the temporary directory
cd "$AUTOPKGTEST_TMP"
# We have to use root mode on salsa ci because:
# - unshare mode fails because /sys is mounted read-only
#and kernel.unprivileged_userns_clone is not set to 1
# - fakechroot mode fails because of #944929
# - proot mode produces wrong permissions
MODE="root"
fi
# setting up /etc/fstab, /etc/hostname and /etc/hosts is required to raise
# network interfaces
if [ ! -e debian-unstable-host.tar ]; then
mmdebstrap --mode=$MODE --variant=apt \
--include=openssh-server,systemd-sysv,ifupdown,netbase,isc-dhcp-client,udev,policykit-1,linux-image-amd64,lxc,uidmap,apparmor,bridge-utils,procps,iptables,iptables-persistent,psmisc
\
--customize-hook='echo host > "$1/etc/hostname"' \
--customize-hook='echo "127.0.0.1 localhost host" > "$1/etc/hosts"' \
--customize-hook='echo "/dev/vda1 / auto errors=remount-ro
Bug#947864: pyopencl: Please enable hurd-i386 build
Source: pyopencl
Version: 2019.1.1-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hello,
pyopencl builds fine on hurd-i386, could you enable its build as the
attached patch does?
Thanks,
Samuel
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500,
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500,
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'),
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
Samuel
je déteste import
parce que lorsque tu fais du python et que tu oublies le #!/bin/env python
et que tu mets le fichier exécutable
import est exécuté
-+- #ens-mim - pourquoi mon script python change le curseur de la souris ?! -+-
--- debian/control.original 2020-01-01 02:04:43.341476369 +0100
+++ debian/control 2020-01-01 02:04:56.411484338 +0100
@@ -27,7 +27,7 @@
Vcs-Browser: https://salsa.debian.org/opencl-team/python-pyopencl
Package: python3-pyopencl
-Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386 arm64 armhf
+Architecture: amd64 hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 arm64 armhf
Multi-Arch: no
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends},
ocl-icd-libopencl1 | libopencl1,
@@ -66,7 +66,7 @@
Package: python3-pyopencl-dbg
Section: debug
-Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386 arm64 armhf
+Architecture: amd64 hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 arm64 armhf
Multi-Arch: no
Depends: python3-pyopencl (= ${binary:Version}), python3-dbg,
${shlibs:Depends}, ${misc:Depends}, ${python3:Depends},
Bug#945390: androguard: autopkgtest failures
On Sun, 24 Nov 2019 08:31:33 +0100 Bas Couwenberg wrote: > Source: androguard > Version: 3.3.5-1 > Severity: serious > Justification: makes the package in question unusable or mostly so > > Dear Maintainer, > > The autopkgtest for your package are failing, which prevent the testing > migration of networkx. > > The logging shows many exceptions like this: > > AttributeError: 'DiGraph' object has no attribute 'node' please note these are _not_ the reason autopkgtests are failing (smoke-test is PASSing), but the real reason is: autopkgtest [17:12:48]: test command1: nosetests3 --with-timer --timer-top-n 50 autopkgtest [17:12:48]: test command1: [--- .S...F..S == FAIL: test_cg_basic (test_entry_points.EntryPointsTest) -- Traceback (most recent call last): File "/tmp/autopkgtest-lxc.muz8cxzo/downtmp/build.QhB/src/tests/test_entry_points.py", line 181, in test_cg_basic assert result.exit_code == 0 AssertionError: >> begin captured logging << androguard.analysis: INFO: End of creating cross references (XREF) androguard.analysis: INFO: run time: 0min 00s androcfg: INFO: Found The following entry points by search AndroidManifest.xml: ['Lorg/t0t0/androguard/test//TestActivity;'] androguard.analysis: INFO: Found Method --> LTest1;->()V [access_flags=public constructor] @ 0x400 - >> end captured logging << - FAILED (SKIP=2, failures=1) autopkgtest [17:16:10]: test command1: ---] autopkgtest [17:16:10]: test command1: - - - - - - - - - - results - - - - - - - - - - command1 FAIL non-zero exit status 1 autopkgtest [17:16:10]: summary smoke-test PASS command1 FAIL non-zero exit status 1
Bug#947759: Configuration optimizations for the cloud variant
On Tue, 31 Dec 2019 17:03:23 + Ben Hutchings wrote: > On Mon, 2019-12-30 at 00:03 -0800, Josh Triplett wrote: > > Source: linux > > Severity: wishlist > > > > A few requests for changes to the cloud configuration: > > Most of this looks reasonable, but: > > > - Please disable CONFIG_ACPI_BGRT; a cloud kernel doesn't need to spend > > time or code space looking for a boot logo that won't exist. > > > > - Please disable the CONFIG_CPU_SUP_* options for CPUs that no cloud > > provider uses. > > > > - Please disable CONFIG_GNSS_*, which won't be hooked up to a cloud > > server. > > > > - Please disable CONFIG_GTP for the same reason. > > > > - Please configure CONFIG_INPUT_MOUSEDEV as a module, not built-in, as > > most cloud servers won't have a mouse and probing for one takes time. > > > > - Please consider changing the default kernel compression to GZIP, which > > decompresses faster and thus boots faster. > > LZO or LZ4 could be even faster. It might. GZIP seemed like a more reasonable tradeoff to request, but I'd be all for LZ4 if that seems reasonable to you. That is indeed the fastest option (see https://smackerelofopinion.blogspot.com/2019/09/ for data to back that up). It might even be worth switching to LZ4 on the standard Debian kernels as well. > > - Please change CONFIG_NET_MPLS_GSO from y to m (and consider doing this > > for the non-cloud kernel too); it doesn't need to be built into the > > kernel. > > Unfortunately nothing will load it if it's a module. It's also a tiny > piece of code. This might still be justifiable on the basis of > reducing the default attack surface though. I didn't realize it didn't autoload. But yes, it seems quite unlikely to be needed. > > - Please change CONFIG_NF_NAT_* and CONFIG_NF_MASQUERADE_* from y to m, > > as many systems won't need those modules and shouldn't need to load > > their code. > > Some of those are boolean options, and I believe all of those that can > be modular already are. You'll have to be more specific. I'd forgotten that several options became booleans and their code got merged into parent modules that are already modularized; nevermind on this one. > > - Please compile in the NVME driver and the EXT4 filesystem; this will > > allow many cloud systems to avoid using an initramfs at all, which > > substantially improves boot time. > > > > - Please disable CONFIG_NUMA_EMU, only used to create fake-NUMA systems > > for debugging. > > > > - Please disable CONFIG_PCIPCWATCHDOG, CONFIG_PPS, and CONFIG_RMI4_*, > > which won't appear on a cloud server. > > Hyper-V and KVM both support PTP clocks, and PTP_1588_CLOCK selects > PPS. Ah, I didn't realize Hyper-V provided a PTP device; that makes sense. - Josh Triplett
Bug#937808: python-hglib: diff for NMU version 2.6.1-1.1
On Tue, Dec 31, 2019 at 6:11 PM Julien Cristau wrote: > > Nak. I don't want to drop python support at this stage. can you explain why? there is no package in debian depending on python-hglib, and in a week it will be auto-removed from testing because of this I've just asked to remove the upload, let's hope it's enough (it was with no delay) > > Julien > > On December 31, 2019 11:58:44 PM GMT+01:00, Sandro Tosi > wrote: >> >> Control: tags 937808 + patch >> >> >> Dear maintainer, >> >> I've prepared an NMU for python-hglib (versioned as 2.6.1-1.1). The diff >> is attached to this message. >> >> Regards. >> -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#944408: termtris: binary installed in /usr/games/bin which is not in PATH
I just released a minor update to termtris (v1.4) which should make it easy to fix this bug. I added a BINDIR variable in the makefile, to specify the binary installation directory (bin by default). If PREFIX is set to /usr and BINDIR set to games, it should do the right thing. This release also fixes a crashing bug in the joystick code, so it's worth updating. http://nuclear.mutantstargoat.com/sw/termtris/termtris-1.4.tar.gz or: https://github.com/jtsiomb/termtris/releases -- John Tsiombikas http://nuclear.mutantstargoat.com/
Bug#937808: python-hglib: diff for NMU version 2.6.1-1.1
Nak. I don't want to drop python support at this stage. Julien On December 31, 2019 11:58:44 PM GMT+01:00, Sandro Tosi wrote: >Control: tags 937808 + patch > > >Dear maintainer, > >I've prepared an NMU for python-hglib (versioned as 2.6.1-1.1). The >diff >is attached to this message. > >Regards.
Bug#937808: python-hglib: diff for NMU version 2.6.1-1.1
Control: tags 937808 + patch
Dear maintainer,
I've prepared an NMU for python-hglib (versioned as 2.6.1-1.1). The diff
is attached to this message.
Regards.
diff -Nru python-hglib-2.6.1/debian/changelog python-hglib-2.6.1/debian/changelog
--- python-hglib-2.6.1/debian/changelog 2019-12-31 17:58:41.0 -0500
+++ python-hglib-2.6.1/debian/changelog 2019-12-31 17:55:13.0 -0500
@@ -1,3 +1,13 @@
+python-hglib (2.6.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python2 support; Closes: #937808
+ * debian/patches
+- add upstream fixes for mercurial 5.2 compatibility (tests)
+- switch to 3.0 (quilt) source format
+
+ -- Sandro Tosi Tue, 31 Dec 2019 17:55:13 -0500
+
python-hglib (2.6.1-1) unstable; urgency=medium
* New upstream release
diff -Nru python-hglib-2.6.1/debian/control python-hglib-2.6.1/debian/control
--- python-hglib-2.6.1/debian/control 2019-12-31 17:58:41.0 -0500
+++ python-hglib-2.6.1/debian/control 2019-12-31 15:32:29.0 -0500
@@ -5,26 +5,12 @@
Build-Depends:
debhelper (>= 7.0.50),
dh-python,
- python-all,
- python-nose,
python3-all,
python3-nose,
mercurial (>= 1.9),
Standards-Version: 3.9.8
Homepage: https://www.mercurial-scm.org/wiki/PythonHglib
-Package: python-hglib
-Architecture: all
-Depends:
- mercurial (>= 1.9),
- ${python:Depends},
- ${misc:Depends},
-Description: Python library for interfacing with Mercurial's command server
- python-hglib is a library with a fast, convenient interface to Mercurial.
- It uses Mercurial's command server for communication with hg. This approach
- avoids relying on Mercurial's (unstable) internal Python API, and avoids
- licensing issues for non-GPL code.
-
Package: python3-hglib
Architecture: all
Depends:
diff -Nru python-hglib-2.6.1/debian/patches/12e6aaef0f6e.patch python-hglib-2.6.1/debian/patches/12e6aaef0f6e.patch
--- python-hglib-2.6.1/debian/patches/12e6aaef0f6e.patch 1969-12-31 19:00:00.0 -0500
+++ python-hglib-2.6.1/debian/patches/12e6aaef0f6e.patch 2019-12-31 17:49:41.0 -0500
@@ -0,0 +1,25 @@
+
+# HG changeset patch
+# User Matt Harbison
+# Date 1557281819 14400
+# Node ID 12e6aaef0f6ed289658ed2df3240e705fae3e029
+# Parent 33b512aa8dba0cbe523188fbb62d30ae2125a236
+tests: handle the removal of `obsolete._enabled` in Mercurial
+
+I'm not sure why we can't just set `experimental.evolution=all`, but it didn't
+work.
+
+diff -r 33b512aa8dba -r 12e6aaef0f6e tests/test-hidden.py
+--- a/tests/test-hidden.py Mon Apr 30 10:38:03 2018 -0400
b/tests/test-hidden.py Tue May 07 22:16:59 2019 -0400
+@@ -22,6 +22,9 @@
+ super(test_obsolete_baselib, self).setUp()
+ self.append('.hg/obs.py',
+ "import mercurial.obsolete\n"
++"# 3.2 and later\n"
++"mercurial.obsolete.isenabled = lambda r, opt: True\n"
++"# Dropped in 5.1\n"
+ "mercurial.obsolete._enabled = True")
+ self.append('.hg/hgrc','\n[extensions]\nobs=.hg/obs.py')
+
+
diff -Nru python-hglib-2.6.1/debian/patches/1a318162f06f.patch python-hglib-2.6.1/debian/patches/1a318162f06f.patch
--- python-hglib-2.6.1/debian/patches/1a318162f06f.patch 1969-12-31 19:00:00.0 -0500
+++ python-hglib-2.6.1/debian/patches/1a318162f06f.patch 2019-12-31 17:50:00.0 -0500
@@ -0,0 +1,79 @@
+
+# HG changeset patch
+# User Augie Fackler
+# Date 1576077658 18000
+# Node ID 1a318162f06f171f0fe1ebc26ff016ebbccc0dbd
+# Parent 513ebe91dc7228babfd1096617ba86dc172349d0
+grep: update tests to cope with behavior change in hg 5.2
+
+I wonder if we should make hglib's grep behave consistently across all
+hg versions somehow, but I'm not going to attempt that for now.
+
+diff -r 513ebe91dc72 -r 1a318162f06f tests/test-grep.py
+--- a/tests/test-grep.py Wed Dec 11 09:39:53 2019 -0500
b/tests/test-grep.py Wed Dec 11 10:20:58 2019 -0500
+@@ -10,13 +10,22 @@
+ # no match
+ self.assertEquals(list(self.client.grep(b('c'))), [])
+
+-self.assertEquals(list(self.client.grep(b('a'))),
+- [(b('a'), b('0'), b('a')), (b('b'), b('0'), b('ab'))])
+-self.assertEquals(list(self.client.grep(b('a'), b('a'))),
+- [(b('a'), b('0'), b('a'))])
++if self.client.version >= (5, 2):
++self.assertEquals(list(self.client.grep(b('a'))),
++ [(b('a'), b('a'), b('b'))])
++self.assertEquals(list(self.client.grep(b('a'), b('a'))),
++ [(b('a'), b('a'), b(''))])
+
+-self.assertEquals(list(self.client.grep(b('b'))),
+- [(b('b'), b('0'), b('ab'))])
++self.assertEquals(list(self.client.grep(b('b'))),
++ [(b('b'), b('ab'), b(''))])
++else:
++self.assertEquals(list(self.client.grep(b('a'))),
++ [(b('a'), b('0'), b('a')), (b('b'), b('0'), b
Bug#938854: RM xpilot-ng
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: xpilot-ng -- RoQA; dead upstream; unmaintained; low popcon; blocking py2 removal This package hasn't had a maintainer upload since 2013. It's dead upstream as well.
Bug#947862: RFS: rmlint/2.9.0-2 -- Extremely fast tool to remove filesystem lint
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rmlint" * Package name: rmlint Version : 2.9.0-2 Upstream Author : Christopher Pahl * URL : https://rmlint.readthedocs.io/ * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/rmlint Section : utils It builds these binary packages: rmlint - Extremely fast tool to remove filesystem lint rmlint-gui - GTK+ frontend to rmlint rmlint-doc - HTML documentation for rmlint To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rmlint Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rmlint/rmlint_2.9.0-2.dsc Changes since the last upload: * Replace glib-2_62.patch with upstream implementation, which provides a fallback and hopefully will allow an ia64 build. Regards, -- Carlos Maddela
Bug#947861: Debian Testing Bug: oidentd 2.4.0-1 - oidentd daemon shows as up sh[pid] in logs
Package: oidentd
Version: 2.4.0-1
ISSUE: oidentd is logged to syslog as 'sh[pid]:' after a recent apt-get
dist-upgrade:
Dec 31 15:38:36 machine sh[3469507]: Connection from xyz.xyz.com
(159.x.x.5):34050
FIX/WORKAROUND:
In /lib/systemd* these two files: oidentd.service oidentd@.service
1. /lib/systemd/system/oidentd.service
2. /lib/systemd/system/oidentd\@.service
I had to remove the -S otherwise I was no longer seeing oidentd in the logs,
instead it looked like this:
Dec 31 15:38:36 machine sh[3469507]: Connection from xyz.xyz.com
(159.x.x.5):34050
After removing the -S, logging works properly:
Dec 31 17:06:51 atom oidentd[3511343]: Connection from xyz.xyz.com
(159.x.x.5):34051
Kindly requesting if the -S can be removed from the oidentd setup package for
the systemd service, otherwise fail2ban and similar applications won't be able
to act on 'sh[pid]: Connection from' etc..
Fix/workaround:
+++ oidentd.service 2019-12-31 17:05:09.693101222 -0500
@@ -5,7 +5,7 @@
[Service]
Environment=OIDENT_USER=nobody OIDENT_GROUP=nogroup
EnvironmentFile=-/etc/default/oidentd
-ExecStart=/bin/sh -c "exec /usr/sbin/oidentd -S ${OIDENT_OPTIONS} -u
\"${OIDENT_USER}\" -g \"${OIDENT_GROUP}\" \
+ExecStart=/bin/sh -c "exec /usr/sbin/oidentd ${OIDENT_OPTIONS} -u
\"${OIDENT_USER}\" -g \"${OIDENT_GROUP}\" \
`[ \"${OIDENT_BEHIND_PROXY}\" = \"yes\" ] && ip route show to exact 0/0 | awk
'{print \"-P \" $3}'`"
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
Fix/workaround:
+++ oidentd@.service2019-12-31 17:05:25.731724279 -0500
@@ -4,7 +4,7 @@
[Service]
Environment=OIDENT_USER=nobody OIDENT_GROUP=nogroup
EnvironmentFile=-/etc/default/oidentd
-ExecStart=/bin/sh -c "exec /usr/sbin/oidentd -IS ${OIDENT_OPTIONS} -u
\"${OIDENT_USER}\" -g \"${OIDENT_GROUP}\" \
+ExecStart=/bin/sh -c "exec /usr/sbin/oidentd -I ${OIDENT_OPTIONS} -u
\"${OIDENT_USER}\" -g \"${OIDENT_GROUP}\" \
`[ \"${OIDENT_BEHIND_PROXY}\" = \"yes\" ] && ip route show to exact 0/0 | awk
'{print \"-P \" $3}'`"
StandardInput=socket
StandardError=syslog
Thanks,
Justin.
Bug#945055: linux: CPU runs at considerably higher temperatures)
Control: severity -1 grave Raising severity, since this current kernels are completely unusable on at least some hardware (i.e. the one I use here), since the temperature just explodes. I'd say grave is justified already by potential hardware damages of systems running even at little actual load at 100 °C not to talk about the fact that one can effectively not upgrade to >5.2 kernels and thus miss any security updates. I've just checked the 5.4 packages from sid and the described issue still occurs. It seems to me that it's likely somehow graphics related, cause if I do nothing (i.e. the screen also does nothing) the temperatures go down to acceptable ~60°C .. but if I just scroll up and down e.g. in my email client's mail list (which ist just the list of subject/from/etc. lines), the temperature goes up to 80°C And still, as previously described, even if I stop the actions that caused the temperatures going up (like no longer scrolling up/down) it takes quite a while till CPU temperatures go down again (eventually they do). Downgrading to 5.2 and everything's back to normal. Cheers, Chris.
Bug#947860: release-notes: Sec 4.3 preparing sources.list omits explicit statement of key change
Package: release-notes Severity: normal Dear Maintainer, When upgrading from Jessie to Stretch, I was confused about when I was supposed to actually edit the sources.list file. I found section 4.3 "Preparing APT source-list files" unclear on when to perform this critical step. I investigated the apt-get dist-upgrade command, but it does not edit sources.list for me. I also found earlier mention that I should be careful that all deb lines should mention "jessie" and later (in section 4.4 "Upgrading packages") the comment "double-check that the APT source entries [...] refer either to ''stretch'' or to ''stable''". Apparently, between these two I was supposed to edit the file to replace jessie with stretch. The corresponding text for Buster is about the same in this respect. I think adding a summary sentence to this effect at the beginning of section 4.3 would be sufficient. While I've used Debian, and Ubuntu before that, for years, my exposure to apt/aptitude has been sporadic and doubtless my mental model of its operation is askew. Making the obvious steps more explicit would help less experienced users with this upgrade process. Perhaps changing the first sentence of 4.3 to: Before starting the upgrade you must reconfigure APT's source-list files (/etc/apt/sources.list and files under /etc/apt/sources.list.d/) to add sources for stretch and remove sources for jessie . Thank you for your consideration. Ted Anderson -- System Information: Debian Release: 8.11 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#934264: Please update (4.6.2?) and provide/switch to python3
On Tue, Dec 31, 2019 at 04:22:09PM -0500, Scott Talbert wrote: > > > That's recorded as TODO item in d/changelog now. > > > > FYI, I just worked on converting envisage to python3: > > https://salsa.debian.org/python-team/modules/python-envisage > > > > I asked Dmitry S. to upload it. > > Hey all, I worked more on mayavi2 and I think is probably ready enough > for upload: > > - Removed wxPython as dependency - only PyQt is currently supported in > mayavi for Python3. This will be pulled in automatically by traitsui, > pyface, etc. > > - Cleaned up all lintian errors/warnings > > - Worked further at getting the tests working. They are a lot closer > but not completely functional. > > - The package builds, installs, and runs fine as best as I can tell, > although I don't know how to do much with it. > > Feel free to upload if you think it is ready. Uploaded. Thanks a lot for your work on this. > Happy New Year, Same to you, Andreas. -- http://fam-tille.de
Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4
Hi László, > File "/<>/tests/admin_inlines/tests.py", line 1, in > from selenium.common.exceptions import NoSuchElementException > ModuleNotFoundError: No module named 'selenium' > > Are you going to upload it fixed to Sid? Thanks for uploading sqlite. This exception was already fixed in #947549… > Happy New Year! … you too. :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#947859: RFS: csstidy/1.4-6 [QA] -- CSS parser and optimiser
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "csstidy" * Package name: csstidy Version : 1.4-6 Upstream Author : Florian Schmitz * URL : http://csstidy.sourceforge.net/ * License : GPL-2 * Vcs : https://salsa.debian.org/debian/csstidy Section : utils It builds those binary packages: csstidy - CSS parser and optimiser To access further information about this package, please visit the following URL: https://mentors.debian.net/package/csstidy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/csstidy/csstidy_1.4-6.dsc Changes since the last upload: * QA upload * In debian/control - Change to debhelper-compat - Bump debhelper to 12 - Update Standards-Version to 4.4.1 - Change Priority: from extra to optional - Add Vcs-Browser and Vcs-Git - Add Rules-Requires-Root: no * Create 005-support-python3.patch closes: #947557 - SConstruct and SConscript is python2 and python3 compatible. * Made debian/copyright dep5 compatible This package needs to be tested against SCons. In unstable it's still python2 while in experimental it's python3 Regards, Håvard
Bug#940570: gtk-layer-shell status
hi, I'm interested in helping to get this package into Debian. I'm maintaining the waybar [0] package, which is a Wayland status bar. In its newest release, one functionality of Waybar also depends on gtk-layer-shell. I started to work on the gtk-layer-shell package in https://salsa.debian.org/bisco-guest/gtk-layer-shell, because I only afterwards saw this ITP. Maybe we can work together on this package or you can use the stuff I already implemented (I haven't found a packaging repo in the mate team for gtk-layer-shell so I figured you might not have started yet). cheers, Birger (bisco) [0] https://github.com/Alexays/Waybar
Bug#934264: Please update (4.6.2?) and provide/switch to python3
> > > python-envisage has not yet been converted to Python3 and seems to be > > > required: > > > $ mayavi2 > > > Traceback (most recent call last): > > > File "/usr/bin/mayavi2", line 464, in > > > from mayavi.plugins.app import Mayavi, setup_logger > > > File "/usr/lib/python3/dist-packages/mayavi/plugins/app.py", line 19, > > > in > > > from .mayavi_workbench_application import MayaviWorkbenchApplication > > > File > > > "/usr/lib/python3/dist-packages/mayavi/plugins/mayavi_workbench_application.py", > > > line 13, in > > > from envisage.ui.workbench.api import WorkbenchApplication > > > ModuleNotFoundError: No module named 'envisage' > > > > That's recorded as TODO item in d/changelog now. > > FYI, I just worked on converting envisage to python3: > https://salsa.debian.org/python-team/modules/python-envisage > > I asked Dmitry S. to upload it. Hey all, I worked more on mayavi2 and I think is probably ready enough for upload: - Removed wxPython as dependency - only PyQt is currently supported in mayavi for Python3. This will be pulled in automatically by traitsui, pyface, etc. - Cleaned up all lintian errors/warnings - Worked further at getting the tests working. They are a lot closer but not completely functional. - The package builds, installs, and runs fine as best as I can tell, although I don't know how to do much with it. Feel free to upload if you think it is ready. Happy New Year, Scott
Bug#947858: ITP: wshowkeys -- Displays keypresses on screen on supported Wayland compositors
Package: wnpp Severity: wishlist Owner: Birger Schacht * Package name: wshowkeys Version : none yet Upstream Author : Drew DeVault * URL : https://git.sr.ht/~sircmpwn/wshowkeys * License : GPL-3 Programming Lang: C Description : Displays keypresses on screen on supported Wayland compositors wshowkeys displays keypresses on screen on supported Wayland compositors (requires wlr_layer_shell_v1 support). (comparable with xev)
Bug#916333: dav1d_0.5.2-1_amd64.changes REJECTED
Hi, On 27/12/2019 08:29, Dylan Aïssi wrote: > Hi Thorsten, > > Thanks for your work as ftpmaster! > > Le ven. 27 déc. 2019 à 00:00, Thorsten Alteholz > a écrit : >> >> the list of grants does not contain the right to modify and distribute the >> modifications of files under the Alliance-for-Open-Media-Patent-License-1.0. >> I am afraid that this is not compatible woth the DFSG. > > I have re-read the license and did not find the relevant part, could > you tag the problematic part of the > Alliance-for-Open-Media-Patent-License-1.0 ? > > In case of the Alliance-for-Open-Media-Patent-License-1.0 is not > compatible with the DFSG, what should we do for packages in the Debian > archive with the same license (aom) ? Similar question for packages > with embedded dav1d (firefox) ? The AOM patent license is not a copyright license but rather an "optional extra" which grants users patent rights under some extra conditions. You would usually use it along with an additional license to cover all the copyright related parts which the DFSG is more concerned about. In aom, I put the patent license in a "Comment" section at the top and don't mention it in any "License" clauses which I think makes this distinction between copyright and patent issues a bit clearer. James signature.asc Description: OpenPGP digital signature
Bug#947339: slingshot: should this package be removed?
Hi Sandro (and ftpmasters), On Tue, Dec 24, 2019 at 08:51:22PM -0500, Sandro Tosi wrote: > if I dont hear back within a week with a good reason to keep this > package in debian, i'll file for its removal. As the package's uploader (and upstream author), I support its removal. I have neither the time nor the interest to port it to python3. Thanks, Ryan -- |)|/ Ryan Kavanagh | GPG: 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust
On Tue, 2019-12-31 at 20:01 +, Ximin Luo wrote: > Ben Hutchings: > > On Tue, 2019-12-31 at 16:39 +, Ximin Luo wrote: > > > Ben Hutchings: > > > > On Tue, 2019-12-31 at 04:31 +, Ximin Luo wrote: > > > > > Package: wnpp > > > > > Severity: wishlist > > > > > Owner: Ximin Luo > > > > > > > > > > * Package name: rust-spotify-tui > > > > > Version : 0.11.0 > > > > > Upstream Author : Alexander Keliris > > > > > * URL : https://github.com/Rigellute/spotify-tui > > > > > * License : MIT or Apache-2.0 > > > > > Programming Lang: Rust > > > > > Description : Spotify for the terminal written in Rust > > > > > > > > Why is the implementation language relevant for an application > > > > package? > > > > > > > > > > I just copied upstream's github repo description. > > > > You also added "rust-" to the package name. > > > > This is just the convention we have for source-package names that are > automatically packaged by our "debcargo" packaging tool. The binary- > package name does not have the "rust-" prefix, so users would just > type "apt install spotify-tui". I still don't think it makes sense to include a language prefix/suffix in an application package name, but if it's only in the source package that doesn't matter. > I was under the impression that we should use source-package names in > wnpp bugs. That's correct. > > > > Also, including Spotify in the name might be a trademark > > > > violation. > > > > > > > > > > IANAL but there's lots of other similar examples of a tool that > > > interfaces with a service S being called "something-S-something", > > > e.g. "calendar-google-provider". The description is pretty clear > > > that > > > this is not an official spotify product. If the law actually has > > > a > > > problem with this, I'd be at a loss to think of how we could > > > possibly > > > name such a tool *without* referring to "S" verbatim in the name. > > > Prefix everything with "unofficial"? I've never seen that in any > > > other FOSS project. > > > > I am also NAL, but have seen a lot of trademark complaints in the > > software world. It is generally OK to use other companies' > > trademarks > > for "nominative use", e.g. to say that my product X works with Y. > > However, using another company's trademark at the beginning of a > > product name risks confusion and is more likely to result in, at > > least, > > legal threats. > > > > In this case, Spotify should definitely be mentioned in the package > > description, and maybe at the end of its name, but the package > > probably > > needs some distinct name. > > > > Well, this is more a matter for upstream - I can't just unilaterally > rename someone else's program. Yes, I realise that. > If you or others have some reasonable and detailed arguments on why > they should change their name, I would be happy to forward that or > you could do so yourself... You are welcome to send my previous comments upstream. > Then there is the question of all of the existing packages in Debian > that have this similar issue. That's not a good reason to add to a potential problem. > Also I'd expect that if Spotify were to complain, they would complain > to upstream rather than Debian, since we cannot reasonably be > expected to unilaterally rename someone else's tool. Adding the package to Debian increases its prominence and the likelihood that it will come to their attention. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4
On Sun, Dec 29, 2019 at 10:07 PM László Böszörményi (GCS) wrote: > On Sun, Dec 29, 2019 at 5:57 PM Chris Lamb wrote: > > I don't fully understand the ramifications or risks of uploading the > > current Fossil tree I'm afraid so I will have to leave that judgement > > to you. Can you let me know your intention either way so that we don't > > lose this down the cracks and delay Paul's work further? I would not > > want to disable the test and remember to re-enable it again, after all. > OK, I did some testing and couldn't find any immediate problem. Going > to upload the current Fossil tree soon, then follow what problem may > arise in Debian or in upstream issues. The upload is done and built on all architectures. As I see, your experimental upload now should be OK. At least the FTBFS reason is not SQLite3 related but: ERROR: admin_inlines.tests (unittest.loader._FailedTest) [...] File "/<>/tests/admin_inlines/tests.py", line 1, in from selenium.common.exceptions import NoSuchElementException ModuleNotFoundError: No module named 'selenium' Are you going to upload it fixed to Sid? Happy New Year! Laszlo/GCS
Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust
Ben Hutchings: > On Tue, 2019-12-31 at 16:39 +, Ximin Luo wrote: >> Ben Hutchings: >>> On Tue, 2019-12-31 at 04:31 +, Ximin Luo wrote: Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: rust-spotify-tui Version : 0.11.0 Upstream Author : Alexander Keliris * URL : https://github.com/Rigellute/spotify-tui * License : MIT or Apache-2.0 Programming Lang: Rust Description : Spotify for the terminal written in Rust >>> >>> Why is the implementation language relevant for an application package? >>> >> >> I just copied upstream's github repo description. > > You also added "rust-" to the package name. > This is just the convention we have for source-package names that are automatically packaged by our "debcargo" packaging tool. The binary-package name does not have the "rust-" prefix, so users would just type "apt install spotify-tui". I was under the impression that we should use source-package names in wnpp bugs. >>> Also, including Spotify in the name might be a trademark violation. >>> >> >> IANAL but there's lots of other similar examples of a tool that >> interfaces with a service S being called "something-S-something", >> e.g. "calendar-google-provider". The description is pretty clear that >> this is not an official spotify product. If the law actually has a >> problem with this, I'd be at a loss to think of how we could possibly >> name such a tool *without* referring to "S" verbatim in the name. >> Prefix everything with "unofficial"? I've never seen that in any >> other FOSS project. > > I am also NAL, but have seen a lot of trademark complaints in the > software world. It is generally OK to use other companies' trademarks > for "nominative use", e.g. to say that my product X works with Y. > However, using another company's trademark at the beginning of a > product name risks confusion and is more likely to result in, at least, > legal threats. > > In this case, Spotify should definitely be mentioned in the package > description, and maybe at the end of its name, but the package probably > needs some distinct name. > Well, this is more a matter for upstream - I can't just unilaterally rename someone else's program. If you or others have some reasonable and detailed arguments on why they should change their name, I would be happy to forward that or you could do so yourself... Then there is the question of all of the existing packages in Debian that have this similar issue. Also I'd expect that if Spotify were to complain, they would complain to upstream rather than Debian, since we cannot reasonably be expected to unilaterally rename someone else's tool. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#936433: docopt: diff for NMU version 0.6.2-2.2
Control: tags 936433 + patch
Dear maintainer,
I've prepared an NMU for docopt (versioned as 0.6.2-2.2). The diff
is attached to this message.
Regards.
diff -Nru docopt-0.6.2/debian/changelog docopt-0.6.2/debian/changelog
--- docopt-0.6.2/debian/changelog 2019-10-11 00:57:20.0 -0400
+++ docopt-0.6.2/debian/changelog 2019-12-31 14:44:57.0 -0500
@@ -1,3 +1,10 @@
+docopt (0.6.2-2.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python2 support; Closes: #936433
+
+ -- Sandro Tosi Tue, 31 Dec 2019 14:44:57 -0500
+
docopt (0.6.2-2.1) unstable; urgency=medium
[ Matthias Klose ]
diff -Nru docopt-0.6.2/debian/control docopt-0.6.2/debian/control
--- docopt-0.6.2/debian/control 2019-10-11 00:57:20.0 -0400
+++ docopt-0.6.2/debian/control 2019-12-31 14:44:07.0 -0500
@@ -3,8 +3,6 @@
Priority: optional
Maintainer: Agustin Henze
Build-Depends: debhelper (>= 11),
- python-all,
- python-setuptools,
python3-all,
python3-setuptools,
dh-python,
@@ -13,15 +11,6 @@
Vcs-Git: https://salsa.debian.org/debian/docopt.git
Vcs-Browser: https://salsa.debian.org/debian/docopt
-Package: python-docopt
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: command-line interface description language
- docopt helps you define an interface for your command-line app and
- automatically generate a parser for it. Its interface descriptions are
- based on a formalization of the standard conventions used in help
- messages and man pages.
-
Package: python3-docopt
Architecture: all
Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru docopt-0.6.2/debian/python-docopt.examples docopt-0.6.2/debian/python-docopt.examples
--- docopt-0.6.2/debian/python-docopt.examples 2019-10-11 00:57:20.0 -0400
+++ docopt-0.6.2/debian/python-docopt.examples 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-examples/*
diff -Nru docopt-0.6.2/debian/rules docopt-0.6.2/debian/rules
--- docopt-0.6.2/debian/rules 2019-10-11 00:57:20.0 -0400
+++ docopt-0.6.2/debian/rules 2019-12-31 14:44:31.0 -0500
@@ -9,7 +9,7 @@
export PYBUILD_NAME=$(DEB_SOURCE)
%:
- dh $@ --with python2,python3 --buildsystem=pybuild
+ dh $@ --with python3 --buildsystem=pybuild
override_dh_auto_clean:
dh_auto_clean
Bug#947338: cherrytree: should this package be removed?
On Fri, Dec 27, 2019 at 12:33 PM Simon McVittie wrote: > > On Tue, 24 Dec 2019 at 20:12:23 -0500, Sandro Tosi wrote: > > i believe there are several issues with cherrytree: > > > > - python2-only application > > - depends on pygtk, deprecated > > - depends on gtksourceview, deprecated > > - upstream is rewriting it in C++, so there's no hope for a py3k port > > > > i think it's time to remove it (and eventuall re-introduce it in Debian > > once the > > C++ port is completed); if i dont hear back within a week with a good > > reason to > > keep this package in Debian, i'll file for it's removal. > > cherrytree is also the last thing keeping orphaned GNOME 2 package > src:pygtksourceview in Debian, so please ask for that package to be > removed (RoQA) at the same time. reassigned this bug to ftp.d.o and opened #947854 for src:pygtksourceview -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#947854: RM: pygtksourceview -- RoQA; python2-only; deprecated; no rdeps (cherrytree just filed for RM)
Package: ftp.debian.org Severity: normal
Bug#947853: uninstallable due to wrong ure epoch in Breaks:
Package: libjuh-java,libjurt-java,libridl-java,libunoloader-java Version: 1:6.4.0~rc1-3 Severity: serious Tags: pending On Tue, Dec 31, 2019 at 12:54:16PM -0500, David Witbrodt wrote: > It looks like you introduced some "Breaks" in 1:6.4.0~rc1-3 that were not > present before, and now things like libjuh-java have a Breaks on > ure (< 1:6.4.0~beta1-1). The epoch "1" on ure is problematic: > > # apt-cache policy libreoffice ure > libreoffice: > Installed: 1:6.4.0~rc1-4 > [...] > ure: > Installed: 6.4.0~rc1-4 > > As you can see, ure is versioned without the epoch, while libreoffice*.deb > packages _are_ versioned with the epoch. In addition to my reply on-list: Making a proper bugreport out if this since ftp-master is currently broken and a upload will take even if done now... Will mark as reported by you once I have the number. > PS: if I have misdiagnosed anything above, sorry for the noise. It looked > to me like a versioning problem has been introduced, and (if that is so) I > wanted to make you aware of it ASAP. No, completely correct anaysis. Regards, Rene >
Bug#947446: Heads up: version 1:6.4.0~rc1-4 makes libreoffice-java-common uninstallable
Hi, On Tue, Dec 31, 2019 at 12:54:16PM -0500, David Witbrodt wrote: > It looks like you introduced some "Breaks" in 1:6.4.0~rc1-3 that were not > present before, and now things like libjuh-java have a Breaks on Jup. See #947446. > ure (< 1:6.4.0~beta1-1). The epoch "1" on ure is problematic: > > # apt-cache policy libreoffice ure > libreoffice: > Installed: 1:6.4.0~rc1-4 > [...] > ure: > Installed: 6.4.0~rc1-4 > > As you can see, ure is versioned without the epoch, while libreoffice*.deb > packages _are_ versioned with the epoch. *sigh*. Indeed. Will upload a new version ASAP. Regards, Rene
Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust
On Tue, 2019-12-31 at 16:39 +, Ximin Luo wrote: > Ben Hutchings: > > On Tue, 2019-12-31 at 04:31 +, Ximin Luo wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Ximin Luo > > > > > > * Package name: rust-spotify-tui > > > Version : 0.11.0 > > > Upstream Author : Alexander Keliris > > > * URL : https://github.com/Rigellute/spotify-tui > > > * License : MIT or Apache-2.0 > > > Programming Lang: Rust > > > Description : Spotify for the terminal written in Rust > > > > Why is the implementation language relevant for an application package? > > > > I just copied upstream's github repo description. You also added "rust-" to the package name. > > Also, including Spotify in the name might be a trademark violation. > > > > IANAL but there's lots of other similar examples of a tool that > interfaces with a service S being called "something-S-something", > e.g. "calendar-google-provider". The description is pretty clear that > this is not an official spotify product. If the law actually has a > problem with this, I'd be at a loss to think of how we could possibly > name such a tool *without* referring to "S" verbatim in the name. > Prefix everything with "unofficial"? I've never seen that in any > other FOSS project. I am also NAL, but have seen a lot of trademark complaints in the software world. It is generally OK to use other companies' trademarks for "nominative use", e.g. to say that my product X works with Y. However, using another company's trademark at the beginning of a product name risks confusion and is more likely to result in, at least, legal threats. In this case, Spotify should definitely be mentioned in the package description, and maybe at the end of its name, but the package probably needs some distinct name. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#947852: python3-networkx needs Breaks on packages in buster it breaks
Source: networkx Version: 2.4-2 Severity: serious Control: block -1 by 945390 945392 Control: affects -1 python3-networkx The autopkgtest have shown that python3-networkx breaks older versions of some packages, at least androguard and python3-django-hyperkitty. Breaks on the affected versions in buster are needed to prevent people from ending up with known-broken combinations of packages, e.g. during upgrades or when using backports.
Bug#947830: squashfs-tools-ng: please enable the build also on Hurd
Control: tags -1 +pending Hi Pino, On Tue, Dec 31, 2019 at 12:48 PM Pino Toscano wrote: > squashfs-tools-ng is not build on Hurd, most probably because its > packaging was derived from squashfs-tools. OTOH, squashfs-tools-ng is > a brand new implementation, and indeed it seems to build and work fine > also on Hurd. Indeed it's a brand new implementation. I think I've tried to build it on a Hurd porterbox but failed and didn't look further. But thanks for the patch. > The only issue I found was a missing include, and opened a PR [1] that > was just merged [2] -- fix attached. Even better. Thanks, Laszlo/GCS
Bug#889883: dh-lua: Please disable --silent in libtool calls
Re: Jean-Michel Vourgère 2018-02-08 <2927066.44csPzL39Z@deimos> > My rrdtool package uses dh-lua. I get a bunch of compiler-flags-hidden > warnings in build log scanner [1], from package blhc. Hi, I'm getting these warnings on hamlib. I'd appreciate if the dh-lua fix were uploaded to unstable as well! Christoph
Bug#946569: Request for CONFIG_EROFS_FS=m on 5.4+
Ping... Some hints about this request? On Wed, Dec 11, 2019 at 10:12:23AM +0800, Gao Xiang wrote: > Source: linux > Version: 5.4.2-1~exp1 > Severity: normal > > Hi Debian kernel maintainers, > > Could you consider enabling EROFS filesystem support as a module > from 5.4 for end users now? It has been out of staging. > > It has much better dynamic performance than squashfs for such > like LIVECD use. I'd suggest the following configuration: > > CONFIG_EROFS_FS=m > # CONFIG_EROFS_FS_DEBUG is not set > CONFIG_EROFS_FS_XATTR=y > CONFIG_EROFS_FS_POSIX_ACL=y > CONFIG_EROFS_FS_SECURITY=y > CONFIG_EROFS_FS_ZIP=y > CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 > > erofs-utils package has been available in testing branch as well, > https://packages.debian.org/source/bullseye/erofs-utils > > Thanks, > Gao Xiang
Bug#945920: Random Chromium crashes
On Mon, 30 Dec 2019 13:50:36 -0800 Eloston wrote: [...] $ ./debian/rules get-orig-source Hi, this fails for me: [...] test ! -e debian || rm -rf debian cp -r ../debian ./ cp: cannot stat '../debian': No such file or directory make: *** [debian/rules:212: get-orig-source] Error 1 ./debian/rules get-orig-source 441.08s user 24.95s system 92% cpu 8:25.08 total Files and directories: $ ll total 12K drwxr-sr-x 50 toto staff 4.0K Dec 31 14:40 chromium-79.0.3945.79 -rw-r--r-- 1 toto staff 2.9K Dec 31 14:30 chromium-build-deps_79.0.3945.79-1_all.deb -rw-r--r-- 1 toto staff 3.6K Dec 31 12:28 enable-tracing.patch $ pwd /usr/local/src/chromium/chromium-c88b97a6dc183a6a7f8a05aee9e99957285a9371 Regards, Toto -- Sent from my GNU Emacs running on GNU/Linux
Bug#947365: transition: libvigraimpex
On 2019-12-31 Sebastiaan Couwenberg wrote: > On 12/31/19 4:20 PM, Andreas Metzler wrote: >> as Bas correctly diagnoses I am not currently building for all supported >> versions but only for the default one because it is not trivial but >> requires some work. Looking at python policy I think that is acceptable >> but not perfect. >> Is my reading of polic correct? > AFAIK the python policy doesn't document the build dependencies. > doko filed bugs for at least one of my packages that had python3-all-dev > in B-D but only built for the default interpreter with the request to > change the B-D or build for all supported versions, so either option is > fine. Hello, Thanks for clearing this up. I was just unsure whether not building for all suppported versions was acceptable. >> Shall I make a timely upload fixing the >> build-dependency or can I wait for propagation of vigra packages to >> testing? > I would commit the change now, and upload it after the testing migration > unless there are other blockers that hold up the migration for more than > 5 days, then I would upload it now. Afaict the involved packages should propagate to testing in 3 days, when enblend-enfuse is old enough. I have commited the fix. [1] cu Andreas [1] https://salsa.debian.org/ametzler/libvigraimpex/commit/c5a8c27cc018c8968036b73c39d0d02d0f229320
Bug#947844: libservlet3.1-java: 8.5.50-0+deb9u1 breaks upgrades to Buster
Hello, Am 31.12.19 um 16:33 schrieb Colomban Wendling: [...] > The reason seems to be that files from this package migrated to other > packages in Buster, but at an earlier version than 8.5.50-0+deb9u1 > (looks like the move happenend in 8.5.35-3~, according to the Breaks > in the now-broken packages). > > I am not sure how this can be solved short of splitting the packages > the same way as in Buster, or possibly providing a newer version in > Buster with updated version in Breaks fields, if that works also for > people updating from earlier versions. thanks for reporting. I believe I have to update the Breaks relationship in libel-api-java, libjsp-api-java, libservlet-api-java and libwebsocket-api-java. Probably << 9 will save us from further trouble. I could also add a Conflicts field to libservlet3.1-java in Stretch but I don't know if apt will properly resolve the dependencies during the upgrade. This is something for a buster-pu. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#947851: upload wlroots to unstable
Source: wlroots Version: 0.8.1-1 Severity: normal Hi Guido, would you mind uploading wlroots to unstable? I'm aware of the fact that upstream doesn't consider the ABI interface stable yet, but since they nowadays bump the soname when releasing a new version[1], I don't see a reason to not have wlroots in unstable. A major advantage of having wlroots in unstable and testing would be that we could provide backports of sway window manager packages to buster-backports. I know of several people (including myself) who run sway on Buster by manually building backported packages (or by compiling manually) and those users would benefit from sway backports in my eyes. Kind regards jonas [1] I saw the related discussion at https://bugs.debian.org/921884 -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable')
Bug#947850: Backport fmtlib 5.3 to buster-backports
Source: fmtlib Version: 5.3.0+ds-2 Severity: wishlist Hello, thanks for maintaining fmtlib in Debian. In order to bring waybar to buster-backports, I'd like to upload a backport of fmtlib to buster-backports as well. Would you like to take care of this yourself or are you fine with me doing the backport? Cheers jonas
Bug#947759: Configuration optimizations for the cloud variant
On Mon, 2019-12-30 at 00:03 -0800, Josh Triplett wrote: > Source: linux > Severity: wishlist > > A few requests for changes to the cloud configuration: Most of this looks reasonable, but: > - Please disable CONFIG_ACPI_BGRT; a cloud kernel doesn't need to spend > time or code space looking for a boot logo that won't exist. > > - Please disable the CONFIG_CPU_SUP_* options for CPUs that no cloud > provider uses. > > - Please disable CONFIG_GNSS_*, which won't be hooked up to a cloud > server. > > - Please disable CONFIG_GTP for the same reason. > > - Please configure CONFIG_INPUT_MOUSEDEV as a module, not built-in, as > most cloud servers won't have a mouse and probing for one takes time. > > - Please consider changing the default kernel compression to GZIP, which > decompresses faster and thus boots faster. LZO or LZ4 could be even faster. > - Please change CONFIG_NET_MPLS_GSO from y to m (and consider doing this > for the non-cloud kernel too); it doesn't need to be built into the > kernel. Unfortunately nothing will load it if it's a module. It's also a tiny piece of code. This might still be justifiable on the basis of reducing the default attack surface though. > - Please change CONFIG_NF_NAT_* and CONFIG_NF_MASQUERADE_* from y to m, > as many systems won't need those modules and shouldn't need to load > their code. Some of those are boolean options, and I believe all of those that can be modular already are. You'll have to be more specific. > - Please compile in the NVME driver and the EXT4 filesystem; this will > allow many cloud systems to avoid using an initramfs at all, which > substantially improves boot time. > > - Please disable CONFIG_NUMA_EMU, only used to create fake-NUMA systems > for debugging. > > - Please disable CONFIG_PCIPCWATCHDOG, CONFIG_PPS, and CONFIG_RMI4_*, > which won't appear on a cloud server. Hyper-V and KVM both support PTP clocks, and PTP_1588_CLOCK selects PPS. > - Please enable CONFIG_SCHED_MC_PRIO (on both cloud and non-cloud > kernels). > > - Please disable CONFIG_VFIO_PCI_VGA and CONFIG_VGA_SWITCHEROO, which > won't appear on cloud. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images
Control: close 932971 0.7-1 On Thu, Jul 25, 2019 at 11:51 AM László Böszörményi (GCS) wrote: > * Package name: squashfs-tools-ng > Version : 0.4.2 > Upstream Author : David Oberhollenzer > * URL : https://github.com/AgentD/squashfs-tools-ng > * License : GPL-3+ > Programming Lang: C > Description : A new set of tools for working with SquashFS images This has been packaged, uploaded and accepted to the archives. Due to bad changelog generation on my side this ITP was not closed automatically.
Bug#947365: transition: libvigraimpex
On Tue, Dec 31, 2019 at 04:35:22PM +0100, Sebastiaan Couwenberg wrote: > On 12/31/19 4:20 PM, Andreas Metzler wrote: > > as Bas correctly diagnoses I am not currently building for all supported > > versions but only for the default one because it is not trivial but > > requires some work. Looking at python policy I think that is acceptable > > but not perfect. > > > > Is my reading of polic correct? > > AFAIK the python policy doesn't document the build dependencies. It does: https://www.debian.org/doc/packaging-manuals/python-policy/build_dependencies.html > doko filed bugs for at least one of my packages that had python3-all-dev > in B-D but only built for the default interpreter with the request to > change the B-D or build for all supported versions, so either option is > fine. Indeed. Building for all supported python versions makes these kind of transitions much easier, but either variant is fine. > > Shall I make a timely upload fixing the > > build-dependency or can I wait for propagation of vigra packages to > > testing? > > I would commit the change now, and upload it after the testing migration > unless there are other blockers that hold up the migration for more than > 5 days, then I would upload it now. ACK. I likewise recommend waiting those 2 more days and then upload the build-dep change. Either that or add an autopkgtest in the same upload now ;) -- 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#947849: ITP: pmtr -- Simple supervisory daemon for linux services
Package: wnpp Severity: wishlist Owner: Michael Moore * Package name: pmtr Version : 17.11.2 Upstream Author : Troy Hanson * URL : https://troydhanson.github.io/pmtr/ * License : MIT Programming Lang: C Description : Simple supervisory daemon for linux services pmtr is a simple supervisory daemon for linux services. Pmtr runs under systemd as well as other init mechanisms like sysvinit, etc. It can also run as process 1 inside a container. When installing on many flavors or Linux, it can detect the nost init and set itself up to start at boot appropriately. Pmtr has a few goals: * to have one configuration file listing all processes to run * to exist under (not to replace) the host init system * to run under various host init systems * to consume few resource * to have few features It is especially useful in container (Docker, etc.) contexts to manage servers and processes. Unlike other systems (systemd, supervisord), pmtr is very easy to configure and monitor. While easy to configure, it supports many useful features such as control via an optional UDP socket, allows for automatic restart of processes on a time interval or when exited, stderr/stdout log to arbitrary files, set nice priority. pmtr has been deployed on a wide variety of Linux platforms for many uses, including Arch, Alpine, Debian, Ubuntu, CentOS/RHEL, Amazon Linux, Raspberry Pi, Beaglebone, and Yocto. pmtr is under active development by Troy Hanson, and x42 Group will maintain the debian packaging (as well as RPM packaging for Fedora/CentOS/RHEL).
Bug#947816: GeoLite2 databases are now non-free
Nope; that’s what I get for filing bugs while sleep deprived. Sorry for the spam! On Tue, Dec 31, 2019 at 04:10 Faidon Liambotis wrote: > On Mon, Dec 30, 2019 at 11:37:52PM -0500, Harlan Lieberman-Berg wrote: > > > > > > Based on this license change, it seems to me that geoipupdate can no > > longer be in main. Contrib may be a suitable home, however? > > geoipupdate is already in contrib (it has always been that way). Did you > perhaps miss that, or did I misunderstood your question? > > Regards, > Faidon > -- Harlan Lieberman-Berg ~hlieberman
Bug#947848: Doesn't work with wayland compositors
Source: redshift Version: 1.12-2 Severity: important Tags: upstream Hello, Redshift upstream doesn't have wayland support yet. There's an upstream bug (https://github.com/jonls/redshift/issues/55) that tracks this shortcoming. Unfortunately, upstream seems to be rather inactive. minus7 at Github created a fork of jonls/redshift that implements wayland support and it's working well with the sway window manager at least: https://github.com/minus7/redshift/tree/wayland https://github.com/swaywm/sway/wiki#redshift Would you consider to patch wayland support from the fork into the redshift Debian package? Another option would be to package the fork as new, separate package (e.g. `redshift-wlr`). Cheers jonas
Bug#947834: stretch-pu: package cups/2.2.1-8+deb9u5
Le mardi, 31 décembre 2019, 14.33:54 h CET Didier 'OdyX' Raboud a écrit :
> CVE-2019-2228 affects oldstable's cups (see #946782); and I'd also like to
> fix another memory leak (#946941). (See #947832 for the stable/buster pu)
It turns out I can't easily backport the fix for #946941; so here's a reduced
proposal:
cups (2.2.1-8+deb9u5) stretch; urgency=medium
* Backport upstream security fix:
- CVE-2019-2228: The `ippSetValuetag` function did not validate the
default language value (Closes: #946782)
-- Didier Raboud Tue, 31 Dec 2019 17:02:30 +0100
debdiff attached.
Cheers,
OdyXdiff -Nru cups-2.2.1/debian/changelog cups-2.2.1/debian/changelog
--- cups-2.2.1/debian/changelog 2019-08-21 09:51:54.0 +0200
+++ cups-2.2.1/debian/changelog 2019-12-31 17:02:30.0 +0100
@@ -1,3 +1,11 @@
+cups (2.2.1-8+deb9u5) stretch; urgency=medium
+
+ * Backport upstream security fix:
+- CVE-2019-2228: The `ippSetValuetag` function did not validate the
+ default language value (Closes: #946782)
+
+ -- Didier Raboud Tue, 31 Dec 2019 17:02:30 +0100
+
cups (2.2.1-8+deb9u4) stretch; urgency=low
* Fix multiple security/disclosure issues (Closes: #934957)
diff -Nru cups-2.2.1/debian/.git-dpm cups-2.2.1/debian/.git-dpm
--- cups-2.2.1/debian/.git-dpm 2019-08-21 09:51:54.0 +0200
+++ cups-2.2.1/debian/.git-dpm 2019-12-31 17:02:18.0 +0100
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-8d6c8479d69d091ee83bbf7e10249f98cdaefa99
-8d6c8479d69d091ee83bbf7e10249f98cdaefa99
+44f7d84856de97443c6785cd9ab9c6915224b7a2
+44f7d84856de97443c6785cd9ab9c6915224b7a2
a3ed22ee480a278acc27433ecbc16eaa63cf2b2e
a3ed22ee480a278acc27433ecbc16eaa63cf2b2e
cups_2.2.1.orig.tar.gz
diff -Nru cups-2.2.1/debian/patches/0055-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch cups-2.2.1/debian/patches/0055-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
--- cups-2.2.1/debian/patches/0055-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch 1970-01-01 01:00:00.0 +0100
+++ cups-2.2.1/debian/patches/0055-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch 2019-12-31 17:02:18.0 +0100
@@ -0,0 +1,23 @@
+From 44f7d84856de97443c6785cd9ab9c6915224b7a2 Mon Sep 17 00:00:00 2001
+From: Michael R Sweet
+Date: Fri, 13 Dec 2019 09:30:46 -0500
+Subject: CVE-2019-2228: Fix ippSetValueTag validation of default language
+
+Closes: #946782
+---
+ cups/ipp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cups/ipp.c b/cups/ipp.c
+index 843b4d997..8840a1d09 100644
+--- a/cups/ipp.c
b/cups/ipp.c
+@@ -4721,7 +4721,7 @@ ippSetValueTag(
+ return (0);
+
+ if (ipp->attrs && ipp->attrs->next && ipp->attrs->next->name &&
+-!strcmp(ipp->attrs->next->name, "attributes-natural-language"))
++!strcmp(ipp->attrs->next->name, "attributes-natural-language") && (ipp->attrs->next->value_tag & IPP_TAG_CUPS_MASK) == IPP_TAG_LANGUAGE)
+ {
+ /*
+ * Use the language code from the IPP message...
diff -Nru cups-2.2.1/debian/patches/series cups-2.2.1/debian/patches/series
--- cups-2.2.1/debian/patches/series 2019-08-21 09:51:54.0 +0200
+++ cups-2.2.1/debian/patches/series 2019-12-31 17:02:18.0 +0100
@@ -52,3 +52,4 @@
0052-DBUS-notifications-could-crash-the-scheduler-Issue-5.patch
0053-CVE-2018-4700-Linux-session-cookies-used-a-predictab.patch
0054-Fix-multiple-security-disclosure-issues.patch
+0055-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
signature.asc
Description: This is a digitally signed message part.
Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust
Ben Hutchings: > On Tue, 2019-12-31 at 04:31 +, Ximin Luo wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Ximin Luo >> >> * Package name: rust-spotify-tui >> Version : 0.11.0 >> Upstream Author : Alexander Keliris >> * URL : https://github.com/Rigellute/spotify-tui >> * License : MIT or Apache-2.0 >> Programming Lang: Rust >> Description : Spotify for the terminal written in Rust > > Why is the implementation language relevant for an application package? > I just copied upstream's github repo description. > Also, including Spotify in the name might be a trademark violation. > IANAL but there's lots of other similar examples of a tool that interfaces with a service S being called "something-S-something", e.g. "calendar-google-provider". The description is pretty clear that this is not an official spotify product. If the law actually has a problem with this, I'd be at a loss to think of how we could possibly name such a tool *without* referring to "S" verbatim in the name. Prefix everything with "unofficial"? I've never seen that in any other FOSS project. > Ben. > >> spotify-tui needs to connect to Spotify’s API in order to find music by name, >> play tracks etc. Instructions on how to set this up will be shown when you >> first run the app. >> >> This app uses the Web API from Spotify, which doesn't handle streaming >> itself. >> So you'll need either an official Spotify client open or a lighter weight >> alternative such as spotifyd. >> >> If you want to play tracks, Spotify requires that you have a Premium account. -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#945592: New debdiff
Hi,
Please find the new debdiff for this change, which is already in
Sid/Testing. We still need to test this, I hope Kevko will be able to
the upgrade tests.
Cheers,
Thomas Goirand (zigo)
diff -Nru horizon-14.0.2/debian/changelog horizon-14.0.2/debian/changelog
--- horizon-14.0.2/debian/changelog 2019-03-25 21:44:52.0 +0100
+++ horizon-14.0.2/debian/changelog 2019-12-31 17:07:32.0 +0100
@@ -1,3 +1,15 @@
+horizon (3:14.0.2-3+deb10u1) buster; urgency=medium
+
+ [ Michal Arbet ]
+ * Fix change of WEBROOT in horizon
+
+ [ Thomas Goirand ]
+ * Do not have debian local_settings.d/*.py files as CONFFILEs, as we're
+editing them depending on the debconf answers (ie: we need to edit the
+WEBROOT variable).
+
+ -- Thomas Goirand Tue, 31 Dec 2019 17:07:32 +0100
+
horizon (3:14.0.2-3) unstable; urgency=medium
* openstack-dashboard: Add Breaks against obsolete packages from Stretch:
diff -Nru horizon-14.0.2/debian/local_settings.d/_0005_debian_webroot.py
horizon-14.0.2/debian/local_settings.d/_0005_debian_webroot.py
--- horizon-14.0.2/debian/local_settings.d/_0005_debian_webroot.py
1970-01-01 01:00:00.0 +0100
+++ horizon-14.0.2/debian/local_settings.d/_0005_debian_webroot.py
2019-12-31 17:07:32.0 +0100
@@ -0,0 +1,2 @@
+# To specify path for webroot, set WEBROOT = "/webroot"
+WEBROOT = "/"
diff -Nru horizon-14.0.2/debian/openstack-dashboard-apache.postinst
horizon-14.0.2/debian/openstack-dashboard-apache.postinst
--- horizon-14.0.2/debian/openstack-dashboard-apache.postinst 2019-03-25
21:44:52.0 +0100
+++ horizon-14.0.2/debian/openstack-dashboard-apache.postinst 2019-12-31
17:07:32.0 +0100
@@ -2,6 +2,32 @@
set -e
+OS_WEBROOT_CONF_PATH="/etc/openstack-dashboard/local_settings.d/_0005_debian_webroot.py"
+
+# We need to check if WEBROOT config will be changed
+# If yes, we need to exec compress,collect_static.
+# If no, it isn't needed.
+
+change_webroot (){
+ WEBROOT=$1
+ # If WEBROOT config exist, compare it
+ if [ -e ${OS_WEBROOT_CONF_PATH} ]; then
+
+ CURRENT_WEBROOT=$(cat ${OS_WEBROOT_CONF_PATH} | grep ^WEBROOT
| sed -e 's/"*'\''*\ *//g' | awk -F '=' '{print $2}')
+
+ if [ "${CURRENT_WEBROOT}" = "${WEBROOT}" ]; then
+ echo "===> openstack-dashboard-apache: Webroot already
set."
+ echo "===> openstack-dashboard-apache: Rebuild static
not needed."
+else
+ sed -i "s|^[ \t]*WEBROOT[ \t]=.*|WEBROOT =
\"${WEBROOT}\"|" ${OS_WEBROOT_CONF_PATH}
+ echo "===> openstack-dashboard-apache: Setting
Horizon's webroot to ${WEBROOT}"
+ echo "===> openstack-dashboard-apache: Horizon's
webroot was changed, rebuild static is needed."
+ dpkg-trigger --no-await
openstack-dashboard-rebuild-static
+ fi
+ fi
+
+}
+
dpkg-maintscript-helper dir_to_symlink \
/usr/share/openstack-dashboard/static
/var/lib/openstack-dashboard/static 2:9.0.0~rc1-2 openstack-dashboard-apache --
"$@"
@@ -26,9 +52,11 @@
db_get horizon/activate_vhost
if [ "${RET}" = "true" ] && [ -x /etc/init.d/apache2 ] ; then
sed -i 's#[
\t]*HORIZON_ACTIVATE_VHOSTS=.*#HORIZON_ACTIVATE_VHOSTS=yes#'
/etc/default/openstack-dashboard-apache
+ # Set webroot to / in openstack-dashboard settings
+ change_webroot "/"
a2dissite 000-default.conf || true
a2dissite default-ssl.conf || true
- sed -i "s|^[ \t]*WEBROOT[ \t]=.*|WEBROOT = '/'|"
/etc/openstack-dashboard/local_settings.py
+
db_get horizon/use_ssl
if [ "${RET}" = "true" ] ; then
sed -i 's#[
\t]*HORIZON_USE_SSL=.*#HORIZON_USE_SSL=yes#'
/etc/default/openstack-dashboard-apache
@@ -52,44 +80,17 @@
else
ln -fs /var/lib/openstack-dashboard/static
/usr/share/openstack-dashboard/static
fi
- # Not needed in openstack-dashboard-apache
- # This is done in openstack-dashboard
- #if [ -f /usr/share/openstack-dashboard/manage.py ]; then
- # /usr/share/openstack-dashboard/manage.py collectstatic
--clear --noinput
- # /usr/share/openstack-dashboard/manage.py compress
--force
- #fi
- #if [ -f
'/var/lib/openstack-dashboard/secret-key/.secret_key_store' ]; then
- # rm -f
/var/lib/openstack-dashboard/secret-key/.secret_key_store
- #fi
- #if [ -d /var/lib/openstack-dashboard/secret-key ]; then
- # chown -R www-data
/var/lib/openstack-dashboard/secret-key
- #fi
- #if [ -d /var/lib/openstack-dashboard/static ]; then
- # chown -R www-data /var/lib/openstack-dashboard/static
-
Bug#946616: [Pkg-rust-maintainers] Bug#946616: dh_auto_install should honor --destdir
Hi, this makes sense and I'll get around to it some time. OTOH, let me point out that we do also already have a similar mechanism (DEB_CARGO_INSTALL_PREFIX), which is not as general as destdir, but which should cover the most common cases of needing this for Debian rust packages. See dotenv in debcargo-conf for an example. This may or may not cover your use-case but I thought I'd mention it anyway. X Paride Legovini: > Package: dh-cargo > Version: 21 > Severity: normal > > After trying to use `dh_auto_install --destdir` as documented in > dh_auto_install(1) I noticed that the option doesn't produce any effect. > I had a quick look at [1] and it seems that the option is currently > being ignored. > > When packaging "binary" crates (= not libraries) it is sometimes very > useful to have the files installed in debian/tmp instead of to > debian/pkgname, as this allows more freedom to choose how to actually > install the files in the Debian package using e.g. dh_install and dh-exec. > > Paride > > [1] /usr/share/perl5/Debian/Debhelper/Buildsystem/cargo.pm > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), > LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages dh-cargo depends on: > ii cargo 0.40.0-2 > ii debhelper 12.7.2 > ii perl 5.30.0-9 > ii python33.7.5-3 > > dh-cargo recommends no packages. > > dh-cargo suggests no packages. > > -- no debconf information > > ___ > Pkg-rust-maintainers mailing list > pkg-rust-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers > -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#947847: please install systemd-sysusers using update-alternatives
Package: systemd Version: 244-3 Severity: important Hi, As I'm packaging opensysusers (see ITP: #947846), I would like my package to also provide /bin/systemd-sysusers. Please install this binary on another location, so that both systemd and opensysusers can implement it. I am very much fine to have systemd have the priority over opensysusers if you believe it should (I'm open to discussion about priorities). Cheers, Thomas Goirand (zigo)
Bug#947846: ITP: opensysusers -- implements systemd's sysusers.d, handling done with or without systemd installed
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: opensysusers Version : 0.4.8 Upstream Author : Chris Cromer * URL : https://github.com/artix-linux/opensysusers * License : BSD-2-clause Programming Lang: bash Description : processes sysusers.d files to create system users and groups This is a utility written to process sysusers.d files so that they can be handled on systems with or without systemd installed.
Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust
On Tue, 2019-12-31 at 04:31 +, Ximin Luo wrote: > Package: wnpp > Severity: wishlist > Owner: Ximin Luo > > * Package name: rust-spotify-tui > Version : 0.11.0 > Upstream Author : Alexander Keliris > * URL : https://github.com/Rigellute/spotify-tui > * License : MIT or Apache-2.0 > Programming Lang: Rust > Description : Spotify for the terminal written in Rust Why is the implementation language relevant for an application package? Also, including Spotify in the name might be a trademark violation. Ben. > spotify-tui needs to connect to Spotify’s API in order to find music by name, > play tracks etc. Instructions on how to set this up will be shown when you > first run the app. > > This app uses the Web API from Spotify, which doesn't handle streaming itself. > So you'll need either an official Spotify client open or a lighter weight > alternative such as spotifyd. > > If you want to play tracks, Spotify requires that you have a Premium account. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#947807: systemd: can't install systemd when /etc/machine-id is a symbolic link to /dev/null
# apt-get install systemd-sysv [lots of junk] Initializing machine ID from random generator. Failed to truncate /etc/machine-id: Invalid argument This is trivially verified by # dpkg-reconfigure systemd Initializing machine ID from random generator. Failed to truncate /etc/machine-id: Invalid argument #
Bug#931173: Configuring static networking via NoCloud with Network Config Version 2 does not work
On 12/31/19 1:13 PM, Christian Tramnitz wrote: > On Tue, 13 Aug 2019 10:04:03 +0200 Bastian Blank wrote: >> - cloud-init write the config file using a name that is ignored by >> ifupdown. The filename is "50-cloud-init.cfg" and everything with "-" >> or "_" in it is ignored. (wtf?) > > No, it's the other way around: > File names may *only* include alphanumeric and "-" + "_" but not a dot. > So the ".cfg" is the part that is causing the problem. > > This has already been addressed upstream, see > https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81#diff-6bf578623d31fa6e19b21138b2c41e8e > > So I'd suggest to backport this patch: > https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81.patch This is included in cloud-init 19.3 which is currently in Sid/Testing, and as our current plan is to backport 19.3 as the new version for buster-proposed-updates, this may be solved with this upgrade. Let's wait and see what the stable release team says. Cheers, Thomas Goirand (zigo)
Bug#947845: RM: balance -- ROM; low popcon, not needed anymore these days
Package: ftp.debian.org Severity: normal hi, balance is a nice and simple tcp loadbalancer, but with haproxy rocking the world I don't think we should keep a package with a popcon of 31 in Debian. Bernd
Bug#945265: [Pkg-clamav-devel] Bug#945265: new upstream version 0.102.1 to fix CVE-2019-15961
On 2019-12-28 21:55:46 [+0100], Hugo Lefeuvre wrote: > Hi Sebastian, Hi, > I see that your work migrated to testing, and wondered... are you still > intending to prepare updates for stretch and buster? Is there anything I > can do to help you? There are two pu bugs open. Based on the feedback from the release team I think it would be good to provide an initscript to provide kind of an upadate path for the ScanOnAccess option. > > cheers, > Hugo Sebastian
Bug#947365: transition: libvigraimpex
On 12/31/19 4:20 PM, Andreas Metzler wrote: > as Bas correctly diagnoses I am not currently building for all supported > versions but only for the default one because it is not trivial but > requires some work. Looking at python policy I think that is acceptable > but not perfect. > > Is my reading of polic correct? AFAIK the python policy doesn't document the build dependencies. doko filed bugs for at least one of my packages that had python3-all-dev in B-D but only built for the default interpreter with the request to change the B-D or build for all supported versions, so either option is fine. > Shall I make a timely upload fixing the > build-dependency or can I wait for propagation of vigra packages to > testing? I would commit the change now, and upload it after the testing migration unless there are other blockers that hold up the migration for more than 5 days, then I would upload it now. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#940778: please drop transitional package ruby-archive-tar-minitar from src:ruby-minitar
Hi Holger, On Thu, 19 Sep 2019 18:06:27 +0200 Holger Levsen wrote: > Please drop the transitional package ruby-archive-tar-minitar (from the > source > package ruby-minitar) for bullseye, as it has been released with stretch and > buster already. You are right, I've opened bugs with a usertag: https://bugs.debian.org/tag:ruby-minitar Regards Markus -- lazyfro...@debian.org https://lazyfrosch.de
Bug#947844: libservlet3.1-java: 8.5.50-0+deb9u1 breaks upgrades to Buster
Package: libservlet3.1-java Version: 8.5.50-0+deb9u1 Severity: important Dear Maintainer, Since upload of version 8.5.50-0+deb9u1, upgrades to Buster are broken: Unpacking libel-api-java (3.0.0-2) ... dpkg: error processing archive /tmp/apt-dpkg-install-pjjAYg/328-libel-api-java_3.0.0-2_all.deb (--unpack): trying to overwrite '/usr/share/maven-repo/javax/el/javax.el-api/3.0/javax.el-api-3.0.pom', which is also in package libservlet3.1-java 8.5.50-0+deb9u1 […] Unpacking libjsp-api-java (2.3.4-2) ... dpkg: error processing archive /tmp/apt-dpkg-install-pjjAYg/362-libjsp-api-java_2.3.4-2_all.deb (--unpack): trying to overwrite '/usr/share/maven-repo/javax/servlet/jsp/javax.servlet.jsp-api/2.3/javax.servlet.jsp-api-2.3.pom', which is also in package libservlet3.1-java 8.5.50-0+deb9u1 […] Unpacking libwebsocket-api-java (1.1-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-pjjAYg/388-libwebsocket-api-java_1.1-1_all.deb (--unpack): trying to overwrite '/usr/share/maven-repo/javax/websocket/javax.websocket-api/1.0/javax.websocket-api-1.0.pom', which is also in package libservlet3.1-java 8.5.50-0+deb9u1 The reason seems to be that files from this package migrated to other packages in Buster, but at an earlier version than 8.5.50-0+deb9u1 (looks like the move happenend in 8.5.35-3~, according to the Breaks in the now-broken packages). I am not sure how this can be solved short of splitting the packages the same way as in Buster, or possibly providing a newer version in Buster with updated version in Breaks fields, if that works also for people updating from earlier versions. Regards, Colomban -- System Information: Debian Release: 9.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-11-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#947754: gitlab: Gitlab oauth problem (Was: mattermost integration error)
Package: gitlab
Version: 12.5.4-2+fto10+1
Followup-For: Bug #947754
A try to connect sonarqube with gitlab via oAuth fails with the same error.
Apparently, the problem are the oauth itself.
Bug is present, at lest, since 12.2.9. I didn't remember if it's present on
12.0.9 or 12.1.14.
Started POST "/api/v4/jobs/request" for ::1 at 2019-12-31 16:09:33 +0100
Started GET
"/oauth/authorize?response_type=code&client_id=&redirect_uri=https%3A%2F%2F%2Foauth2%2Fcallback%2Fgitlab&state="
for x.x.x.x at 2019-12-31 16:09:34 +0100
Processing by Oauth::AuthorizationsController#new as HTML
Parameters: {"response_type"=>"code", "client_id"=>"",
"redirect_uri"=>"https:///oauth2/callback/gitlab",
"state"=>""}
Completed 500 Internal Server Error in 9ms (ActiveRecord: 0.4ms |
Elasticsearch: 0.0ms)
NoMethodError (undefined method `mapping' for Doorkeeper::Rails::Routes:Class):
lib/gitlab/request_profiler/middleware.rb:17:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:13:in `call'
lib/gitlab/middleware/correlation_id.rb:16:in `block in call'
lib/gitlab/middleware/correlation_id.rb:15:in `call'
lib/gitlab/middleware/multipart.rb:117:in `call'
lib/gitlab/middleware/read_only/controller.rb:48:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:32:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:49:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
Started POST "/api/v4/jobs/request" for ::1 at 2019-12-31 16:09:36 +0100
-- System Information:
Debian Release: bullseye/sid
APT prefers buster-fasttrack
APT policy: (500, 'buster-fasttrack'), (500, 'buster-backports'), (500,
'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.62-mod-std-ipv6-64-rescue (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gitlab depends on:
ii asciidoctor 2.0.10-2
ii bc 1.07.1-2+b2
ii bundler 1.17.3-3
ii bzip21.0.8-2
ii dbconfig-pgsql 2.0.13
ii debconf [debconf-2.0]1.5.73
ii exim4-daemon-light [mail-transport-agent]4.92.3-1
ii gitlab-common12.5.4-2+fto10+1
ii gitlab-workhorse 8.16.0+debian-1
ii libjs-bootstrap4 [node-bootstrap]4.4.1+dfsg1-1
ii libjs-pdf1.5.188+dfsg-1~bpo10+1
ii libjs-popper.js [node-popper.js] 1.16.0+ds2-1
ii libjs-uglify 2.8.29-6
ii lsb-base 11.1.0
ii nginx1.16.1-2
ii nginx-full [nginx] 1.16.1-2
ii node-autosize4.0.2~dfsg1-3
ii node-axios 0.19.0+dfsg-2
ii node-brace-expansion 1.1.8-1
ii node-cache-loader2.0.1-2
ii node-chart.js2.9.3+dfsg-2
ii node-core-js 2.4.1-2
ii node-css-loader 1.0.1-1
ii node-d3 5.12.0-1~bpo10+1
ii node-d3-array1.2.4-2
ii node-d3-axis 1.0.12-2
ii node-d3-brush1.1.5-1
ii node-d3-ease 1.0.5-2
ii node-d3-scale2.2.2-1~bpo10+1
ii node-d3-selection1.4.0-5
ii node-d3-shape1.3.5-2
ii node-d3-time 1.0.11-3
ii node-d3-time-format 2.1.3-2
ii node-d3-transition 1.2.0-4
ii node-dateformat 3.0.0-1
ii node-exports-loader 0.7.0-2
ii node-file-loader 3.0.1-1
ii node-fuzzaldrin-plus 0.5.0+dfsg-3
ii node-glob7.1.6-1
ii node-imports-loader 0.8.0-2
ii node-jed 1.1.1-1
ii node-jquery 3.4.0+dfsg-1
ii node-jquery-ujs
Bug#947842: Update dependency ruby-archive-tar-minitar to ruby-minitar
Source: subtle Version: 0.11.3224-xi-2.2 Severity: important Usertags: ruby-minitar Hi maintainer, I will remove the ruby-archive-tar-minitar transitional package from Debian unstable soon. Please update your dependency to ruby-minitar. This package is available in Debian since stretch. Best Regards Markus Frosch -- lazyfro...@debian.org https://lazyfrosch.de
Bug#947841: Update dependency ruby-archive-tar-minitar to ruby-minitar
Source: ruby-docker-api Version: 1.22.2-1 Severity: important Usertags: ruby-minitar Hi maintainer, I will remove the ruby-archive-tar-minitar transitional package from Debian unstable soon. Please update your dependency to ruby-minitar. This package is available in Debian since stretch. Best Regards Markus Frosch -- lazyfro...@debian.org https://lazyfrosch.de
Bug#947843: Update dependency ruby-archive-tar-minitar to ruby-minitar
Source: rhc Version: 1.38.7-2 Severity: important Usertags: ruby-minitar Hi maintainer, I will remove the ruby-archive-tar-minitar transitional package from Debian unstable soon. Please update your dependency to ruby-minitar. This package is available in Debian since stretch. Best Regards Markus Frosch -- lazyfro...@debian.org https://lazyfrosch.de
Bug#947365: transition: libvigraimpex
On 2019-12-31 Sebastiaan Couwenberg wrote: > On 12/30/19 9:48 PM, Paul Gevers wrote: [...] >> libvigraimpex is also part of the pseudo python3.8 transition [1], but >> it is still red. This probably means that you are not correctly building >> Python3 modules for all supported Python3 versions. Can you please check? > Looks like it shouldn't build depend on python3-all-dev since the build > systems only uses the default interpreter. > sed -i 's/python3-all-dev/python3-dev/g' debian/control Hello, as Bas correctly diagnoses I am not currently building for all supported versions but only for the default one because it is not trivial but requires some work. Looking at python policy I think that is acceptable but not perfect. Is my reading of polic correct? Shall I make a timely upload fixing the build-dependency or can I wait for propagation of vigra packages to testing? Sorry for the inconvenience. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#947840: xsecurelock: Should not build-depend on libc6
Package: xsecurelock Version: 1.5.1-1 Severity: important Hello, xsecurelock currently build-depends on libc6, thus making it unbuildable on all ports whose libc is not versioned 6 (alpha, hppa, etc.). There is no need to depend on "libc6" anyway since it's always installed. Could you drop that dependency? Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xsecurelock depends on: ii dash 0.5.10.2-6 ii libc6 2.29-3 ii libpam0g 1.3.1-5 ii libx11-6 2:1.6.8-1 ii libxcomposite1 1:0.4.4-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxft22.3.2-2 ii libxmuu1 2:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxss11:1.2.3-1 ii x11-xserver-utils 7.7+8 xsecurelock recommends no packages. Versions of packages xsecurelock suggests: ii mplayer 2:1.3.0-8+b5 pn mpv ii xscreensaver-data5.42+dfsg1-1 ii xscreensaver-data-extra 5.42+dfsg1-1 ii xscreensaver-gl 5.42+dfsg1-1 ii xscreensaver-gl-extra5.42+dfsg1-1 -- Samuel J'ai beaucoup de mal a lire fcola quand il y a toutes les annonces de howto : les annonces interessantes sont noyees dans les howto. Ca serait pas mal de degager toute cette pollution dans un autre groupe. JLM in Guide du linuxien pervers : "Cachez ces doc que je ne saurais voir"
Bug#868293: There is a better patch for buster
Hello, I don't know why but I didn't have a problem with vpnc-script-sshd on stretch. But it is broken on buster. There is a better patch for buster. See: Bug#947820 Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Bug#947760: [Pkg-javascript-devel] Bug#947760: Bug#947760: why ?
Il 30/12/19 11:36, Xavier ha scritto: > ... > I think that npm is needed when a package has to be build locally. > That's why a "recommends" should be enough > Xavier, I have enabled salsa CI on node-es6-iterator repo and fixed it to run tests with yarnpkg so that the dependency on npm can be dropped from debian/tests/control See this run: https://salsa.debian.org/js-team/node-es6-iterator/-/jobs/483337 If you think this fixes the issue, please go ahead and close this bug. Paolo P.S. Regarding node-es6-iterator autopkgtest, after "node ./node_modules/tad/bin/tad" it prints "No tests run". This is the same as before when tests were run with "npm run test": https://salsa.debian.org/js-team/node-es6-iterator/-/jobs/483318 But it does not seem right ! If I run the tests in the source tree with "yarnpkg install && yarnpkg test" this is what i see: yarn run v1.21.1 $ node ./node_modules/tad/bin/tad 15:56:30.392 ✓ #/chain.js ... 15:56:30.397 ✓ array.js ... 15:56:30.404 ✓ for-of.js ... 15:56:30.409 ✓ get.js ... 15:56:30.411 ✓ index.js .. 15:56:30.415 ✓ is-iterable.js . 15:56:30.417 ✓ string.js 15:56:30.419 ✓ valid-iterable.js .. .037 141 Ok [100.00%] Done in 0.83s.
Bug#947839: dak: Suboptimal .diff generation
Package: ftp.debian.org Severity: minor Hi, I spotted this suboptimal pattern in the Contents-amd64 diff called [2019-12-27-2015.57.gz]: (search for lintian overrides) """ . 5126721a usr/share/lintian/overrides/libboost-python1.71.0 libs/libboost-python1.71.0 . 5126720a usr/share/lintian/overrides/libboost-program-options1.71.0 libs/libboost-program-options1.71.0 . 5126719a usr/share/lintian/overrides/libboost-numpy1.71.0 libs/libboost-numpy1.71.0 . 5126718a usr/share/lintian/overrides/libboost-mpi1.71.0 libs/libboost-mpi1.71.0 . [...] 5126706a usr/share/lintian/overrides/libboost-contract1.71.0 libs/libboost-contract1.71.0 . """ It seems to me that it would be more effecient to emit a single append line and produce the lines in correct order. Thanks, ~Niels [2019-12-27-2015.57.gz]: https://snapshot.debian.org/archive/debian/20191231T093159Z/dists/sid/main/Contents-amd64.diff/2019-12-27-2015.57.gz
Bug#946420: kpat is spamming with error messages
Control: notfound -1 4:18.04.1-1 Control: found -1 4:19.08.1-1 Control: tags -1 unreproducible moreinfo Hello Hans, I tried to reproduce inside a minimal plasma testing VM. But I could not see a noticeable amount of messages in .xsession_errors while playing kpat. If this is still visible on your system then some more information could help. - Which game have you played inside kpat? - Some example lines of the messages in .xsession_errors Kind regards, Bernhard
Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
I was affected by the same bug (Freebox Revolution from Free (French ISP) here). I switched to isc-dhcp-client by creating a file /etc/NetworkManager/conf.d/dhcp-client.conf containing the 2 following lines: [main] dhcp=dhclient Then I restarted NetworkManager using this command: sudo service NetworkManager restart and IPv4 is working as expected again. The bug is therefore probably related to the internal dhcp client. Regards
Bug#946499: eog crashes with 'BadAlloc (insufficient resources for operation)' on large image
Dear Maintainer, I tried to reproduce this issue. And as far as I see eog/cairo tries to allocate a pixmap from the xserver in the size of the image file - in this case 44351x3013 pixel. Unfortunately the xserver has a hard limit for such pixmap sizes: Thread 1 "Xorg" hit Breakpoint 4, ProcShmCreatePixmap (client=0x55b5f312cc50) at ../../../../Xext/shm.c:1085 1085if (width > 32767 || height > 32767) 1086return BadAlloc; Would wayland behave better in that regard? Otherwise eog/cairo would need to allocate that pixmap some other way. This issue reported against gtkmm seems to match: https://gitlab.gnome.org/GNOME/gtkmm/issues/54 Complete backtraces with debug symbols in attached file of eog and xserver. Could remember I saw such a rejection from the xserver already in (not strictly related): https://bugs.debian.org/858045 Kind regards, Bernhard # Buster/testing amd64 qemu VM 2019-12-31 apt update apt dist-upgrade apt install systemd-coredump mc xserver-xorg sddm openbox xterm imagemagick graphicsmagick gimp gdb eog eog-dbgsym libglib2.0-0-dbgsym libgtk-3-0-dbgsym libcairo2-dbgsym libxext6-dbg libx11-6-dbgsym xserver-xorg-core-dbgsym apt build-dep xserver-xorg-core reboot mkdir /home/benutzer/source/xserver-xorg-core/orig -p cd/home/benutzer/source/xserver-xorg-core/orig apt source xserver-xorg-core cd benutzer@debian:~$ convert -size 44351x3013 xc:white white.jpg convert-im6.q16: width or height exceeds limit `white' @ error/cache.c/OpenPixelCache/3911. convert-im6.q16: no images defined `white.jpg' @ error/convert.c/ConvertImageCommand/3258. # Created with gimp benutzer@debian:~$ identify 44351x3013.jpg 44351x3013.jpg JPEG 44351x3013 44351x3013+0+0 8-bit sRGB 1.49679MiB 0.000u 0:00.000 benutzer@debian:~$ file 44351x3013.jpg 44351x3013.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 300x300, segment length 16, comment: "Created with GIMP", progressive, precision 8, 44351x3013, components 3 export DISPLAY=:0 benutzer@debian:~$ eog 44351x3013.jpg (eog:661): Gdk-ERROR **: 14:05:22.547: The program 'eog' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 1315 error_code 11 request_code 130 (MIT-SHM) minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/Breakpoint ausgelöst (Speicherabzug geschrieben) [ 43.663846] traps: eog[661] trap int3 ip:7fc4abeebdb5 sp:7ffc7facd730 error:0 in libglib-2.0.so.0.6200.3[7fc4abeb2000+8] Dez 31 14:05:22 debian systemd[1]: Started Process Core Dump (PID 687/UID 0). Dez 31 14:05:29 debian systemd-coredump[688]: Core file was truncated to 2147483648 bytes. Dez 31 14:05:35 debian systemd-coredump[688]: Process 661 (eog) of user 1000 dumped core. Stack trace of thread 661: #0 0x7fc4abeebdb5 n/a (n/a + 0x0) Dez 31 14:05:35 debian systemd[1]: systemd-coredump@0-687-0.service: Succeeded. benutzer@debian:~$ GDK_SYNCHRONIZE=1 gdb -q --args eog 44351x3013.jpg Reading symbols from eog... (No debugging symbols found in eog) (gdb) run Starting program: /usr/bin/eog 44351x3013.jpg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x72391700 (LWP 1012)] [New Thread 0x71b90700 (LWP 1013)] [New Thread 0x7138f700 (LWP 1014)] [New Thread 0x70b24700 (LWP 1015)] [New Thread 0x7fffe3fff700 (LWP 1016)] (eog:1008): Gdk-ERROR **: 14:10:12.498: The program 'eog' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 2438 error_code 11 request_code 130 (MIT-SHM) minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Thread 1 "eog" received signal SIGTRAP, Trace/breakpoint trap. 0x77c4bdb5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 (gdb) bt #0 0x77c4bdb5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x77c4e6bc in g_log_writer_default () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77c4c9e7 in g_log_structured_arra
Bug#947838: O: fbcat -- framebuffer grabber
Package: wnpp The current maintainer of fbcat, Piotr Lewandowski , has asked to orphan this package. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: fbcat Binary: fbcat Version: 0.3-1.1 Maintainer: Piotr Lewandowski Uploaders: Luca Bruno Build-Depends: debhelper-compat (= 12), docbook-xml (>= 4.5), docbook-xsl, xsltproc, libxml2-utils, linux-libc-dev, dpkg-dev (>= 1.16.1~) Architecture: any Standards-Version: 4.4.1 Format: 3.0 (quilt) Files: 3bbdf840be9518d3c522421ea20e44a7 1944 fbcat_0.3-1.1.dsc 85f6207459ecedd55b406a8c62249ba5 12035 fbcat_0.3.orig.tar.gz 801083b6f1b6100bcf305b5984375606 2332 fbcat_0.3-1.1.debian.tar.xz Vcs-Browser: http://git.debian.org/?p=collab-maint/fbcat.git Vcs-Git: git://git.debian.org/collab-maint/fbcat.git Checksums-Sha256: 512a840d16e4b05463255d7c0bc07cbfcfbd1b4eb226353182d0ee48a95be2a7 1944 fbcat_0.3-1.1.dsc b756e4cf2070337b85242203d6067b9ab486736238c0f4362302ac88dd6ceef1 12035 fbcat_0.3.orig.tar.gz f6da0160b1f5fce402ea515aa99c43ef18c99dd73baf4e9dfdc72feee28ce577 2332 fbcat_0.3-1.1.debian.tar.xz Homepage: https://jwilk.net/software/fbcat Package-List: fbcat deb graphics extra arch=any Directory: pool/main/f/fbcat Priority: source Section: graphics Package: fbcat Version: 0.3-1.1 Installed-Size: 37 Maintainer: Piotr Lewandowski Architecture: amd64 Replaces: fbgrab Provides: fbgrab Depends: libc6 (>= 2.4) Recommends: netpbm | graphicsmagick | imagemagick Conflicts: fbgrab Description: framebuffer grabber Description-md5: 37bef91d1c0a57141537400941ef2def Homepage: https://jwilk.net/software/fbcat Tag: implemented-in::c, interface::commandline, interface::framebuffer, role::program, scope::utility, works-with::image, works-with::image:raster Section: graphics Priority: optional Filename: pool/main/f/fbcat/fbcat_0.3-1.1_amd64.deb Size: 9732 MD5sum: 3bade1e9be4e76b7e6a5b2cfb1052e51 SHA256: 4c093e76390962f025b5d10fb9e326cd7bb9ff63b37e0a0cd78ba5380e982238 -- 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#947837: piuparts.debian.org: please upgrade python3-debianbts on pejacevic
Package: piuparts.debian.org Severity: normal Since 27 December the piuparts-analyze output is broken. E.g.: https://piuparts.debian.org/logs/2019/12/27/piuparts-analyze.txt The failure start date coincides with the date when the new code from the develop branch was deployed. I think the python3-debianbts package needs to be upgraded on the piuparts master host, since the new code now depends on at least version 2.10.0 of that package.
Bug#947836: lintian: missing-build-dependency-for-dh_-command ignores dh-sequence-
Package: lintian Version: 2.43.0 Severity: normal Hello. Please add dh-sequence-* exceptions to the missing-build-dependency-for-dh_-command tag, as in commit 34b939af. dh-ada-library Provides: dh-sequence-ada-library (in experimental) sphinx-common Provides: dh-sequence-sphinxdoc (pending upload) Thanks.
Bug#939552: libvirt: New upstream version (5.10)
Dear maintainer, please consider raising the severity of this wishlist bug. I have just updated a system to bullseye with libvirt 5.6.0-2, and I'm hitting upstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1732298 When I start a VM that is connected to an OVS portgroup then I get the following error message: error: unsupported configuration: an interface connecting to network 'ovs-network' is requesting a vlan tag, but that is not supported for this type of network Steps to reproduce: 1. create ovs-network with some portgroups 2. create VM connected to such portgroup on ovs-network 3. start domain This issue is fixed in version 5.7, the patch is linked in the upstream bug database: https://www.redhat.com/archives/libvir-list/2019-August/msg00201.html Thanks, Thomas
Bug#947835: uptimed: please don't ship .la files
Package: uptimed Version: 1:0.4.2-1 Severity: normal Tags: patch User: codeh...@debian.org Usertags: la-file-removal Hi, as per Policy §10.2, .la files should not be included in the Debian package. Patch attached for this. Thanks, -- Pino diff -Nru uptimed-0.4.2/debian/rules uptimed-0.4.2/debian/rules --- uptimed-0.4.2/debian/rules +++ uptimed-0.4.2/debian/rules @@ -17,6 +17,9 @@ dh_auto_install -Dlibuptimed + # remove libtool .la files + find $(U) -name '*.la' -delete + override_dh_auto_build: dh_auto_build cd debian && LC_ALL=C onsgmls uptimed.conf.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
Bug#947834: stretch-pu: package cups/2.2.1-8+deb9u5
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Oldstable Release Team,
CVE-2019-2228 affects oldstable's cups (see #946782); and I'd also like to fix
another memory leak (#946941). (See #947832 for the stable/buster pu)
My proposed changelog would be:
cups (2.2.1-8+deb9u5) stretch; urgency=medium
* Backport upstream security fixes:
- Fix memory leak in ppdOpen (Closes: #946941)
- CVE-2019-2228: The `ippSetValuetag` function did not validate the
default language value (Closes: #946782)
-- Didier Raboud Tue, 31 Dec 2019 14:25:30 +0100
… the proposed debdiff is attached.
Cheers,
OdyX
diff -Nru cups-2.2.1/debian/changelog cups-2.2.1/debian/changelog
--- cups-2.2.1/debian/changelog 2019-08-21 09:51:54.0 +0200
+++ cups-2.2.1/debian/changelog 2019-12-31 14:25:30.0 +0100
@@ -1,3 +1,12 @@
+cups (2.2.1-8+deb9u5) stretch; urgency=medium
+
+ * Backport upstream security fixes:
+- Fix memory leak in ppdOpen (Closes: #946941)
+- CVE-2019-2228: The `ippSetValuetag` function did not validate the
+ default language value (Closes: #946782)
+
+ -- Didier Raboud Tue, 31 Dec 2019 14:25:30 +0100
+
cups (2.2.1-8+deb9u4) stretch; urgency=low
* Fix multiple security/disclosure issues (Closes: #934957)
diff -Nru cups-2.2.1/debian/.git-dpm cups-2.2.1/debian/.git-dpm
--- cups-2.2.1/debian/.git-dpm 2019-08-21 09:51:54.0 +0200
+++ cups-2.2.1/debian/.git-dpm 2019-12-31 14:25:08.0 +0100
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-8d6c8479d69d091ee83bbf7e10249f98cdaefa99
-8d6c8479d69d091ee83bbf7e10249f98cdaefa99
+c60d0154b20313af2bdec051ab5473320a6de1e8
+c60d0154b20313af2bdec051ab5473320a6de1e8
a3ed22ee480a278acc27433ecbc16eaa63cf2b2e
a3ed22ee480a278acc27433ecbc16eaa63cf2b2e
cups_2.2.1.orig.tar.gz
diff -Nru cups-2.2.1/debian/patches/0055-Fix-memory-leak-in-ppdOpen.patch
cups-2.2.1/debian/patches/0055-Fix-memory-leak-in-ppdOpen.patch
--- cups-2.2.1/debian/patches/0055-Fix-memory-leak-in-ppdOpen.patch
1970-01-01 01:00:00.0 +0100
+++ cups-2.2.1/debian/patches/0055-Fix-memory-leak-in-ppdOpen.patch
2019-12-31 14:25:08.0 +0100
@@ -0,0 +1,32 @@
+From bf1d779750f63fd2519865ac5cd5656cbdd9e3e0 Mon Sep 17 00:00:00 2001
+From: Michael R Sweet
+Date: Thu, 1 Aug 2019 13:02:35 -0400
+Subject: Fix memory leak in ppdOpen
+
+Closes: #946941
+---
+ cups/ppd.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/cups/ppd.c b/cups/ppd.c
+index 44a22c5cb..42fff3509 100644
+--- a/cups/ppd.c
b/cups/ppd.c
+@@ -719,6 +719,8 @@ _ppdOpen(
+ strncmp(ll, keyword, ll_len)))
+ {
+ DEBUG_printf(("2_ppdOpen: Ignoring localization: \"%s\"\n", keyword));
++ free(string);
++ string = NULL;
+ continue;
+ }
+ else if (localization == _PPD_LOCALIZATION_ICC_PROFILES)
+@@ -738,6 +740,8 @@ _ppdOpen(
+ if (i >= (int)(sizeof(color_keywords) / sizeof(color_keywords[0])))
+ {
+ DEBUG_printf(("2_ppdOpen: Ignoring localization: \"%s\"\n", keyword));
++free(string);
++string = NULL;
+ continue;
+ }
+ }
diff -Nru
cups-2.2.1/debian/patches/0056-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
cups-2.2.1/debian/patches/0056-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
---
cups-2.2.1/debian/patches/0056-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
1970-01-01 01:00:00.0 +0100
+++
cups-2.2.1/debian/patches/0056-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
2019-12-31 14:25:08.0 +0100
@@ -0,0 +1,23 @@
+From c60d0154b20313af2bdec051ab5473320a6de1e8 Mon Sep 17 00:00:00 2001
+From: Michael R Sweet
+Date: Fri, 13 Dec 2019 09:30:46 -0500
+Subject: CVE-2019-2228: Fix ippSetValueTag validation of default language
+
+Closes: #946782
+---
+ cups/ipp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cups/ipp.c b/cups/ipp.c
+index 843b4d997..8840a1d09 100644
+--- a/cups/ipp.c
b/cups/ipp.c
+@@ -4721,7 +4721,7 @@ ippSetValueTag(
+ return (0);
+
+ if (ipp->attrs && ipp->attrs->next && ipp->attrs->next->name &&
+-!strcmp(ipp->attrs->next->name, "attributes-natural-language"))
++!strcmp(ipp->attrs->next->name, "attributes-natural-language") &&
(ipp->attrs->next->value_tag & IPP_TAG_CUPS_MASK) == IPP_TAG_LANGUAGE)
+ {
+ /*
+ * Use the language code from the IPP message...
diff -Nru cups-2.2.1/debian/patches/series cups-2.2.1/debian/patches/series
--- cups-2.2.1/debian/patches/series2019-08-21 09:51:54.0 +0200
+++ cups-2.2.1/debian/patches/series2019-12-31 14:25:08.0 +0100
@@ -52,3 +52,5 @@
0052-DBUS-notifications-could-crash-the-scheduler-Issue-5.patch
0053-CVE-2018-4700-Linux-session-cookies-used-a-predictab.patch
0054-Fix-multiple-security-disclosure-issues.patch
+0055-Fix-memo
Bug#947833: Emergency shell unusable with root login disabled
Package: debian-installer Version: Bullseye Alpha 1 Did an 'advanced graphical install' of Bullseye using alpha1 installer; I selected to disable root login for security reasons, so just had the one account (and because i was too lazy to type in another password again). I tried to do some advanced partitioning (crypt+lvm) during setup on disk 2+3. Upon reboot there was something wrong with the disk setup, it tried to dump me into the "Emergency shell", but i couldn't actually get a shell, something about root login disabled (forget the exact wording). I think it should be possible to have a working login to an emergency shell via sudo (sudo did configure itself properly). Or perhaps there could be a warning that the emergency shell wont work when logins are being configured in the installer. I bypassed the LVM problem and will manually do it, i believe there are other bug reports about that.
Bug#947832: buster-pu: package cups/2.2.10-6+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear Stable Release Team,
CVE-2019-2228 affects stable's cups (see #946782); and I'd also like to fix
another memory leak (#946941).
My proposed changelog would be:
cups (2.2.10-6+deb10u2) buster; urgency=medium
* Backport upstream security fixes:
- Fix memory leak in ppdOpen (Closes: #946941)
- CVE-2019-2228: The `ippSetValuetag` function did not validate the
default language value (Closes: #946782)
-- Didier Raboud Tue, 31 Dec 2019 14:16:46 +0100
… the proposed debdiff is attached.
Cheers,
OdyX
diff -Nru cups-2.2.10/debian/changelog cups-2.2.10/debian/changelog
--- cups-2.2.10/debian/changelog2019-08-21 09:43:13.0 +0200
+++ cups-2.2.10/debian/changelog2019-12-31 13:54:34.0 +0100
@@ -1,3 +1,12 @@
+cups (2.2.10-6+deb10u2) buster-security; urgency=high
+
+ * Backport upstream security fixes:
+- Fix memory leak in ppdOpen (Closes: #946941)
+- CVE-2019-2228: The `ippSetValuetag` function did not validate the
+ default language value (Closes: #946782)
+
+ -- Didier Raboud Tue, 31 Dec 2019 13:54:34 +0100
+
cups (2.2.10-6+deb10u1) buster; urgency=medium
* Fix multiple security/disclosure issues (Closes: #934957)
diff -Nru cups-2.2.10/debian/.git-dpm cups-2.2.10/debian/.git-dpm
--- cups-2.2.10/debian/.git-dpm 2019-08-21 09:43:13.0 +0200
+++ cups-2.2.10/debian/.git-dpm 2019-12-31 13:53:45.0 +0100
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-9af82602a9fe2523ceeef46f2d6e6378e2dc7eb7
-9af82602a9fe2523ceeef46f2d6e6378e2dc7eb7
+1b21a83376cee1f213faf7f4b4d89dd766c28975
+1b21a83376cee1f213faf7f4b4d89dd766c28975
25b2338346ef3abbb93ea88476887cba7b2b86f8
25b2338346ef3abbb93ea88476887cba7b2b86f8
cups_2.2.10.orig.tar.gz
diff -Nru cups-2.2.10/debian/patches/0048-Fix-memory-leak-in-ppdOpen.patch
cups-2.2.10/debian/patches/0048-Fix-memory-leak-in-ppdOpen.patch
--- cups-2.2.10/debian/patches/0048-Fix-memory-leak-in-ppdOpen.patch
1970-01-01 01:00:00.0 +0100
+++ cups-2.2.10/debian/patches/0048-Fix-memory-leak-in-ppdOpen.patch
2019-12-31 13:53:45.0 +0100
@@ -0,0 +1,32 @@
+From 545d46fb0bf1cd8414ab28148f3a3126c3cf75fe Mon Sep 17 00:00:00 2001
+From: Michael R Sweet
+Date: Thu, 1 Aug 2019 13:02:35 -0400
+Subject: Fix memory leak in ppdOpen
+
+Closes: #946941
+---
+ cups/ppd.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/cups/ppd.c b/cups/ppd.c
+index 435b992f4..b823d17b4 100644
+--- a/cups/ppd.c
b/cups/ppd.c
+@@ -716,6 +716,8 @@ _ppdOpen(
+ strncmp(ll, keyword, ll_len)))
+ {
+ DEBUG_printf(("2_ppdOpen: Ignoring localization: \"%s\"\n", keyword));
++ free(string);
++ string = NULL;
+ continue;
+ }
+ else if (localization == _PPD_LOCALIZATION_ICC_PROFILES)
+@@ -735,6 +737,8 @@ _ppdOpen(
+ if (i >= (int)(sizeof(color_keywords) / sizeof(color_keywords[0])))
+ {
+ DEBUG_printf(("2_ppdOpen: Ignoring localization: \"%s\"\n", keyword));
++free(string);
++string = NULL;
+ continue;
+ }
+ }
diff -Nru
cups-2.2.10/debian/patches/0049-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
cups-2.2.10/debian/patches/0049-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
---
cups-2.2.10/debian/patches/0049-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
1970-01-01 01:00:00.0 +0100
+++
cups-2.2.10/debian/patches/0049-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
2019-12-31 13:53:45.0 +0100
@@ -0,0 +1,23 @@
+From 1b21a83376cee1f213faf7f4b4d89dd766c28975 Mon Sep 17 00:00:00 2001
+From: Michael R Sweet
+Date: Fri, 13 Dec 2019 09:30:46 -0500
+Subject: CVE-2019-2228: Fix ippSetValueTag validation of default language
+
+Closes: #946782
+---
+ cups/ipp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cups/ipp.c b/cups/ipp.c
+index cc9c6af50..98b499716 100644
+--- a/cups/ipp.c
b/cups/ipp.c
+@@ -4563,7 +4563,7 @@ ippSetValueTag(
+ return (0);
+
+ if (ipp->attrs && ipp->attrs->next && ipp->attrs->next->name &&
+-!strcmp(ipp->attrs->next->name, "attributes-natural-language"))
++!strcmp(ipp->attrs->next->name, "attributes-natural-language") &&
(ipp->attrs->next->value_tag & IPP_TAG_CUPS_MASK) == IPP_TAG_LANGUAGE)
+ {
+ /*
+ * Use the language code from the IPP message...
diff -Nru cups-2.2.10/debian/patches/series cups-2.2.10/debian/patches/series
--- cups-2.2.10/debian/patches/series 2019-08-21 09:43:13.0 +0200
+++ cups-2.2.10/debian/patches/series 2019-12-31 13:53:45.0 +0100
@@ -45,3 +45,5 @@
0045-Fix-an-issue-with-PreserveJobHistory-and-time-values.patch
manpage-translations.patch
0047-Fix-multiple-security-disclosure-issues.patch
+0048-Fix-memory-leak-in-ppdOpen.patch
+0049-CVE-2019-22
Bug#947831: libsquashfs-dev: please don't ship .la files
Package: libsquashfs-dev
Version: 0.8-1
Severity: normal
Tags: patch
User: codeh...@debian.org
Usertags: la-file-removal
Hi,
as per Policy §10.2, .la files should not be included in the Debian
package. Patch attached for this.
Thanks,
--
Pino
--- a/debian/libsquashfs-dev.install
+++ b/debian/libsquashfs-dev.install
@@ -1,5 +1,4 @@
usr/include/
usr/lib/*/libsquashfs.a
-usr/lib/*/libsquashfs.la
usr/lib/*/libsquashfs.so
usr/lib/*/pkgconfig/
--- a/debian/rules
+++ b/debian/rules
@@ -6,9 +6,8 @@
override_dh_auto_install:
dh_auto_install
- # empty dependency libs
- sed -i "/dependency_libs/ s/'.*'/''/" \
- `find $(CURDIR)/debian/tmp/ -name '*.la'`
+ # remove libtool .la files
+ find $(CURDIR)/debian/tmp/ -name '*.la' -delete
%:
dh ${@}
Bug#942214: thunar/nautilus crash navigate directory "cifs mounted" containing opened libreoffice writer file
Hello, you can find the result i obtain with your last demand : Script démarré sur 2019-12-31 13:57:12+01:00 [TERM="xterm-256color" TTY="/dev/pts/3" COLUMNS="180" LINES="40"] Reading symbols from thunar...Reading symbols from /usr/lib/debug/.build-id/32/8d2b4f5e231fc71d690010ffba7d757c6487c6.debug...done. done. Starting program: /usr/bin/thunar [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x73ed8700 (LWP 25204)] [New Thread 0x736d7700 (LWP 25205)] [New Thread 0x72e5e700 (LWP 25206)] [New Thread 0x7265d700 (LWP 25207)] [Thread 0x7265d700 (LWP 25207) exited] Thread 1 "thunar" received signal SIGSEGV, Segmentation fault. 0x76ab8bbd in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #0 0x76ab8bbd in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #1 0x76ab90f4 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #2 0x76ab7fc2 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #3 0x76a497af in g_content_type_guess () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x76aae5d4 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #5 0x76ab0008 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #6 0x76aab40d in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #7 0x5559e56d in thunar_file_get_content_type (file=0x5859d140) at thunar-file.c:2493 #8 0x555afbad in thunar_list_model_get_value (model=0x56f0bd80, iter=, column=, value=0x7fffd8c0) at thunar-list-model.c:795 #9 0x7735f560 in ?? () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #10 0x76856b70 in g_hash_table_foreach () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7735f43b in ?? () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #12 0x77364c4b in ?? () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #13 0x775f74ba in ?? () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #14 0x76949ec6 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x7696638d in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x7696697f in g_signal_emit () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x77360f12 in gtk_cell_area_apply_attributes () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0x7757be57 in ?? () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #19 0x775825a5 in ?? () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #20 0x775888b5 in ?? () from /lib/x86_64-linux-gnu/libgtk-3.so.0 #21 0x77157c08 in ?? () from /lib/x86_64-linux-gnu/libgdk-3.so.0 #22 0x76867dd8 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x768681c8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x7686825c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x76a5aa2d in g_application_run () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #26 0x5557ba28 in main (argc=argc@entry=1, argv=argv@entry=0x7fffe228) at main.c:161 #27 0x7667b09b in __libc_start_main (main=0x5557b980 , argc=1, argv=0x7fffe228, init=, fini=, rtld_fini=, stack_end=0x7fffe218) at ../csu/libc-start.c:308 #28 0x5557bb5a in _start () at main.c:141 No symbol "range_start" in current context. No symbol "range_length" in current context. No symbol "data_length" in current context. No symbol "data_offset" in current context. No symbol "mask_offset" in current context. No symbol "i" in current context. No symbol "j" in current context. $1 = 0x0 There is no member named buffer. $2 = 0x0 No symbol "offset" in current context. No symbol "len" in current context. >From To Syms Read Shared Object Library 0x77fd6090 0x77ff3b20 Yes /lib64/ld-linux-x86-64.so.2 0x77fa88a0 0x77fad0fc Yes /lib/x86_64-linux-gnu/libthunarx-3.so.0 0x77f7a620 0x77f95736 Yes (*) /lib/x86_64-linux-gnu/libexo-2.so.0 0x77d62a00 0x77d65b72 Yes (*) /lib/x86_64-linux-gnu/libgudev-1.0.so.0 0x77d58550 0x77d5a8db Yes (*) /lib/x86_64-linux-gnu/libnotify.so.4 0x77d4c270 0x77d5015b Yes (*) /lib/x86_64-linux-gnu/libSM.so.6 0x77b31ef0 0x77b3f96a Yes (*) /lib/x86_64-linux-gnu/libICE.so.6 0x7791e520 0x779250ce Yes (*) /lib/x86_64-linux-gnu/libxfce4ui-2.so.0 0x772b2e30 0x775fbf61 Yes (*) /lib/x86_64-linux-gnu/libgtk-3.so.0 0x77157130 0x771cc277 Yes (*) /lib/x86_64-linux-gnu/libgdk-3.so.0 0x770eca20 0x7710e0e0 Yes (*) /lib/x86_64-linux-gnu/libpango-1.0.so.0 0x770c16b0 0x770cea0f Yes (*) /lib/x86_64-linux-gnu/libatk-1.0.so.0 0x76fa9680 0x77073d8e Yes (*) /lib/x86_64-linux-gnu/libcairo.so.2 0x76f74b30 0x76f88f83 Yes (*) /lib/x86_64-linux-gnu/libg
Bug#947813: SIGSEGV resulting from mesa dri2_add_config dealing poorly with invalid attrib
My issue appears to be largely due to a version mismatch, and I have been able to resolve this. I had tried to get a specific version from unstable to test a fix for a different bug, but apparently I misunderstood how pinning works and got updates to mesa packages from the unstable release even after the version for which I intended this. Once I downgraded mesa packages to testing version, I was able to start X again. I'll leave it to you whether you believe this kind of issue is worth addressing at the distro level (perhaps via more strict version dependencies?) or forwarding to the upstream maintainers (so that unexpected behavior from a module library gets detected in a nicer fashion than by crashing the X server). If you decide to just close this bug, that's fine with me, too. In that case sorry for the noise. $ cat /etc/apt/preferences.d/mesa.pref Explanation: test fix for #933906 Package: *mesa* Pin: release a=unstable Version: 19.1.4-1 Pin-Priority: 600 $ dpkg -l '*mesa*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---=> ii libegl-mesa0:amd64 19.2.6-1 amd64free implementation of the EGL API -- Mesa vendor library ii libegl-mesa0-dbgsym:amd64 19.2.6-1 amd64debug symbols for libegl-mesa0 ii libegl1-mesa:amd64 19.3.1-3 amd64 transitional dummy package ii libgl1-mesa-dri:amd64 19.3.1-3 amd64free implementation of the OpenGL API -- DRI modules ii libgl1-mesa-dri-dbgsym:amd6419.3.1-3 amd64debug symbols for libgl1-mesa-dri un libgl1-mesa-glx (no description available) un libgl1-mesa-swx11 (no description available) ii libglapi-mesa:amd64 19.3.1-3 amd64free implementation of the GL API -- shared library ii libglapi-mesa-dbgsym:amd64 19.3.1-3 amd64debug symbols for libglapi-mesa un libgles2-mesa (no description available) ii libglu1-mesa:amd64 9.0.1-1 amd64Mesa OpenGL utility library (GLU) ii libglx-mesa0:amd64 19.3.1-3 amd64free implementation of the OpenGL API -- GLX vendor libra> un libwayland-egl1-mesa (no description available) un mesa-opencl-icd (no description available) un mesa-utils(no description available) ii mesa-va-drivers:amd64 19.3.1-3 amd64Mesa VA-API video acceleration drivers ii mesa-vdpau-drivers:amd6419.3.1-3 amd64Mesa VDPAU video acceleration drivers ii mesa-vdpau-drivers-dbgsym:amd64 19.3.1-3 amd64debug symbols for mesa-vdpau-drivers ii mesa-vulkan-drivers:amd64 19.3.1-3 amd64Mesa Vulkan graphics drivers un mesag3(no description available) un xlibmesa3 (no description available)
Bug#946559: buster-pu: package proftpd-dfsg/1.3.6-4+deb10u3
On 2019-12-31 12:49, Hilmar Preuße wrote: Am 30.12.2019 um 22:23 teilte Adam D. Barratt mit: Control: tags -1 + confirmed + * Cherry pick patch from upstream: + - for upstream 861 (CVE-2019-19269) (Closes: #946345) + - for upstream 859 (CVE-2019-19270) (Closes: #946346) + upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269 Please go ahead. Has been uploaded and accepted. How to proceed? Now you just need to wait for an SRM to process the upload. Regards, Adam
Bug#946560: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u3
Am 30.12.2019 um 22:21 teilte Adam D. Barratt mit: > Control: tags -1 + confirmed > The distribution for a stretch-pu upload should simply be "stretch". > > + * Cherry pick patch from upstream: > + - for upstream 861 (CVE-2019-19269) (Closes: #946345) > + upstream_pull_861_CVE-2019-19269 > > I'm not sure whether that final line was intended to be included. > > Please go ahead. > Has been uploaded and accepted. How to proceed? Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#946559: buster-pu: package proftpd-dfsg/1.3.6-4+deb10u3
Am 30.12.2019 um 22:23 teilte Adam D. Barratt mit: > Control: tags -1 + confirmed > + * Cherry pick patch from upstream: > + - for upstream 861 (CVE-2019-19269) (Closes: #946345) > + - for upstream 859 (CVE-2019-19270) (Closes: #946346) > + upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269 > > Please go ahead. > Has been uploaded and accepted. How to proceed? Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#915473: civicrm build depends and depends on php-tcpdf that might be removed from buster
On Tuesday, 31 December 2019 9:39:13 PM AEDT Adrian Bunk wrote: > You likely missed that I submitted this bug in December *2018*. > Back then php-tcpdf and civicrm were both in testing. I did not miss that - I just had no capacity to respond at a time... -- Best wishes, Dmitry Smirnov. --- Happiness is when what you think, what you say, and what you do are in harmony. -- Mahatma Gandhi signature.asc Description: This is a digitally signed message part.
Bug#931173: Configuring static networking via NoCloud with Network Config Version 2 does not work
On Tue, 13 Aug 2019 10:04:03 +0200 Bastian Blank wrote: > - cloud-init write the config file using a name that is ignored by > ifupdown. The filename is "50-cloud-init.cfg" and everything with "-" > or "_" in it is ignored. (wtf?) No, it's the other way around: File names may *only* include alphanumeric and "-" + "_" but not a dot. So the ".cfg" is the part that is causing the problem. This has already been addressed upstream, see https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81#diff-6bf578623d31fa6e19b21138b2c41e8e So I'd suggest to backport this patch: https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81.patch Best regards, Christian
Bug#947790: openscenegraph-3.4: osgPlugins-3.4.1/osgdb_png.so not build on ARM
Hi, Gaetan: This seems like something in the toolchain or the 3.4 version of OSG. I have checked in the 3.6 version of the package (https://packages.debian.org/bullseye/armhf/libopenscenegraph160/filelist) and the plugin is there. I will try at least to make it build the plugin in stable as you did. Regards, Alberto
