Bug#971683: postgresql-common: obsolete-conffile (apt.conf.d, createcluster.conf)

[Thorsten Glaser]

Dixi quod…

>Looking at these files, especially the first, I’m honestly not sure
>whether I want to delete them. If they are not in the binary package
>any more but used to be this is probably a bug?

Looking at past changelogs, I found this:

https://salsa.debian.org/postgresql/postgresql-common/-/commit/e87adade0349a757fd0827a80cc14814487a4d30.patch

I believe this is a genuine packaging (especially upgrade) bug
introduced with that commit: the commit removed the file
/etc/apt/apt.conf.d/01autoremove-postgresql from the package
but did not unregister it as conffile.

Fixing this is probably as simple as:

• change the filename
• postinst: rm -f /etc/apt/apt.conf.d/01autoremove-postgresql on upgrade

I’ve not looked at createcluster.conf but it will, most likely, also
be caused by a similar packaging fault.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#972136: davmail does not start when keystore is not used

[Joachim Zobel]

Package: davmail
Version: 5.5.1.3299-3
Severity: important

After upgrading to bullseye and migrating the configuration davmail failed to
start with the syslog message

Oct 13 05:42:48 pause service-prepare[3655]: /bin/rm: das Entfernen von
'/var/lib/davmail/keystoreFile' ist nicht möglich: Datei oder Verzeichnis nicht
gefunden

The reason is that in /usr/share/davmail/service-prepare rm is used without a
-f.



-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'oldoldstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages davmail depends on:
ii  adduser   3.118
ii  default-jre-headless [java9-runtime-headless] 2:1.11-72
ii  init-system-helpers   1.58
ii  jarwrapper0.77
ii  libcommons-codec-java 1.14-1
ii  libcommons-httpclient-java3.1-15
ii  libcommons-logging-java   1.2-2
ii  libhtmlcleaner-java   2.24-1
ii  libhttpclient-java4.5.12-1
ii  libjackrabbit-java2.18.0+r2.14.6-1
ii  libjcifs-java 1.3.19-2
ii  libjettison-java  1.4.0-1
ii  liblog4j1.2-java  1.2.17-9
ii  libmail-java  1.6.5-1
ii  libservlet-api-java   4.0.1-2
ii  libslf4j-java 1.7.25-3
ii  libstax2-api-java 4.1-1
ii  libwoodstox-java  1:6.2.1-1
ii  logrotate 3.16.0-3
ii  lsb-base  11.1.0
ii  openjdk-10-jre-headless [java9-runtime-headless]  10.0.2+13-2
ii  openjdk-11-jre-headless [java9-runtime-headless]  11.0.8+10-1
ii  openjdk-8-jre-headless [java8-runtime-headless]   8u265-b01-0+deb9u1

davmail recommends no packages.

Versions of packages davmail suggests:
ii  libopenjfx-java 11.0.7+0-2
pn  libswt-cairo-gtk-4-jni  
pn  libswt-gtk2-4-jni   

-- Configuration Files:
/etc/davmail.properties changed [not included]
/etc/davmail/davmail.properties changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/davmail/service-prepare (from davmail package)

Bug#969477: zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade

[Antonio Russo]

Hello Jordan,

Do you have the architecture-specific Linux headers installed?
I.e., please call

# uname -r

that should give you something like 5.8.0-2-amd64

Is the package linux-headers-5.8.0-2-amd64 installed (replaced for your 
specific kernel version)?

Or, just run

# apt-cache policy linux-headers-$(uname -r)

And send the output.

Best,
Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#972135: systemd: Fails to upgrade on NFS root filesystem (without ACL support)

[Pat Coulthard]

Package: systemd
Version: 246.6-1
Severity: normal

Systemd fails during an upgrade from buster to testing with an NFS mounted
root filesystem. The issue appears to be that this filesystem doesn't support
POSIX ACLs, which causes the postinst script to fail.

In this case, the NFS server is a Debian buster server running the standard
Debian kernel.




Setting up systemd-timesyncd (246.6-1) ...
Created symlink 
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.
Setting up systemd (246.6-1) ...
Installing new version of config file /etc/systemd/journald.conf ...
Installing new version of config file /etc/systemd/logind.conf ...
Installing new version of config file /etc/systemd/networkd.conf ...
Installing new version of config file /etc/systemd/resolved.conf ...
Installing new version of config file /etc/systemd/system.conf ...
Installing new version of config file /etc/systemd/user.conf ...
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-pstore.service 
→ /lib/systemd/system/systemd-pstore.service.
Setting access ACL "u::rwx,g::r-x,g:adm:r-x,m::r-x,o::r-x" on /var/log/journal 
failed: Operation not supported
dpkg: error processing package systemd (--configure):
 installed systemd package post-installation script subprocess returned error 
exit status 73
Setting up dmsetup (2:1.02.171-3) ...
update-initramfs: deferring update (trigger activated)
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)



-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-11-arm64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.4-3
ii  libaudit11:2.8.5-3+b1
ii  libblkid12.36-3+b1
ii  libc62.31-3
ii  libcap2  1:2.25-2
ii  libcrypt11:4.4.17-1
ii  libcryptsetup12  2:2.3.4-1
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.15-4
ii  libgpg-error01.35-1
ii  libidn2-02.3.0-1
ii  libip4tc21.8.5-3
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.36-3+b1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.4-1
ii  libselinux1  3.1-2
ii  libsystemd0  246.6-1
ii  libzstd1 1.4.5+dfsg-4
ii  mount2.33.1-0.1
ii  systemd-timesyncd [time-daemon]  246.6-1
ii  util-linux   2.36-3+b1

Versions of packages systemd recommends:
iu  dbus  1.12.20-1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
it  initramfs-tools  0.133+deb10u1
pn  libnss-systemd   
iu  libpam-systemd   246.6-1
iu  udev 246.6-1

-- no debconf information

Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it

[Rogério Brito]

Package: chromium
Version: 83.0.4103.116-3.1
Severity: wishlist

Currently, the way that chromium is being maintained is far from the
standards that we expect in Debian.

A considerable number of reasonable bug reports (like, for instance the one
for enabling sharing one's desktop in this age of pandemic and many people
having to work from home) are not answered or ignored.

Besides that, there is a skeleton of a version 84 in the repo, but the
package manager (and https://packages.debian.org/search?keywords=chromium)
doesn't know about it.

Going even further, Google Chrome (which I really, really don't want to
install on my systems) is already at version 86 according to both
https://en.wikipedia.org/wiki/Google_Chrome_version_history and
https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_12.html

Furthermore, https://tracker.debian.org/pkg/chromium lists, at this moment,
100 security issues in sid, buster and bullseye.

Honestly, if one can't keep up with updates to their packages, at least make
a call for a group of buddy developers to help (the package tracker doesn't
show any kind of RFH bug open) or find someone else that is willing to
maintain the package.


Thanks,

Rogério Brito.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  chromium-common  83.0.4103.116-3.1
ii  libasound2   1.2.3.2-1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.1-4
ii  libavformat587:4.3.1-4
ii  libavutil56  7:4.3.1-4
ii  libc62.31-3
ii  libcairo21.16.0-4
ii  libcups2 2.3.3-3
ii  libdbus-1-3  1.12.20-1
ii  libdrm2  2.4.102-1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-3
ii  libgbm1  20.1.9-1
ii  libgcc-s110.2.0-13
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.66.0-2
ii  libgtk-3-0   3.24.23-2
ii  libharfbuzz0b2.6.7-1
ii  libicu67 67.1-4
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libjsoncpp1  1.7.4-3.1
ii  liblcms2-2   2.9-4+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.28-1
ii  libnss3  2:3.56-1
ii  libopenjp2-7 2.3.1-1
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-1
ii  libpangocairo-1.0-0  1.46.2-1
ii  libpng16-16  1.6.37-3
ii  libpulse013.0-5
ii  libre2-8 20201001+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.0-13
ii  libvpx6  1.8.2-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.12-1
ii  libx11-xcb1  2:1.6.12-1
ii  libxcb-dri3-01.14-2
ii  libxcb1  1.14-2
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxml2  2.9.10+dfsg-6
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.34-4
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  83.0.4103.116-3.1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+5
ii  xdg-utils  1.1.3-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox83.0.4103.116-3.1
ii  fonts-liberation1:1.07.4-11
ii  libgl1-mesa-dri 20.1.9-1
pn  libu2f-udev 
ii  mate-notification-daemon [notification-daemon]  1.24.1-1
ii  system-config-printer   1.5.12-1
ii  upower  0.99.11-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.31-3

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#972087: python3-gnocchi: gnocchi-api fails due to bad parameters to /usr/bin/uwsgi

[Russell Coker]

On Tuesday, 13 October 2020 2:38:40 AM AEDT Thomas Goirand wrote:
> > # gnocchi-api
> > 2020-10-12 12:17:56,769 [7662] INFO gnocchi.service: Gnocchi version
> > 4.3.1 /usr/bin/uwsgi: option '--http' is ambiguous; possibilities:
> > '--http-socket' '--http-socket-modifier1' '--http-socket-modifier2'
> > '--http11-socket' '--https-socket' '--https-socket-modifier1'
> > '--https-socket-modifier2' getopt_long() error
> > 
> > Above is the result of running gnocchi-api at the command-line.  I realise
> > that this might not be the right way to run it, but I think it still
> > shouldn't abort due to using parameters that don't match the version of
> > uwsgi in Debian.
> > 
> > It seems that instead of --http it should use --http-socket.  Also after
> > that is fixed there's the issue that it uses the --http-keepalive option
> > which is not accepted by the uwsgi in Debian.
> 
> The gnocchi-api binary isn't meant to be started standalone, but it

https://gnocchi.xyz/operating.html

This page says it is.

> should be used by uwsgi, as per what the startup scripts are doing. If
> you do /etc/init.d/gnocchi-api show-args, it will show:
> 
> /usr/bin/uwsgi_python37 \
>   --https-socket
> [::]:8041,/etc/gnocchi/ssl/public/HOSTNAME.crt,/etc/gnocchi/ssl/private/HOST
> NAME.pem \
>   --ini /etc/gnocchi/gnocchi-api-uwsgi.ini
> 
> (that is, if you've put some SSL files in /etc/gnocchi/ssl, otherwise it
> wont use SSL).
> 
> Therefore, I wonder if this bug is still valid or not... Especially if
> you consider that the service isn't even using the --http option (where
> is this coming from then?).

It's coming from /usr/lib/python3/dist-packages/gnocchi/cli/api.py and I've 
supplied a patch.


-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#972132: [Pkg-zfsonlinux-devel] Bug#972132: zfs-initramfs: Fails to boot when / is on zfs encryption=on dataset

[Richard Laager]

On 10/12/20 9:29 PM, John Goerzen wrote:
> I have set up this system to use ZFS crypto rather than my more conventional 
> zfs-atop-LUKS.

Can you explain a little bit more about how you setup your system?

This (root-on-ZFS with native encryption) already works for me on Buster
(with ZFS from buster-backports) using the upstream HOWTO (that I maintain):
https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Bug#972133: m2crypto ftbfs with python3-defaults (python3.9) from experimental

[Emmanuel Arias]

Package: src:m2crypto
Version:  0.36.0-1
Severity: important
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.9

Control: forwarded -1 https://gitlab.com/m2crypto/m2crypto/-/issues/274

` base64.decodestring()` was removed on Python 3.9 [0]

[0] https://docs.python.org/3/whatsnew/3.9.html


[...]

=== FAILURES
===
_ X509StackTestCase.test_make_stack_check_num
__

self = 

def test_make_stack_check_num(self):
with open("tests/der_encoded_seq.b64", 'rb') as f:
b64 = f.read()

with warnings.catch_warnings():
warnings.simplefilter('ignore', DeprecationWarning)
>   seq = base64.decodestring(b64)
E   AttributeError: module 'base64' has no attribute 'decodestring'

tests/test_x509.py:615: AttributeError
__ X509StackTestCase.test_make_stack_from_der
__

self = 

def test_make_stack_from_der(self):
with open("tests/der_encoded_seq.b64", 'rb') as f:
b64 = f.read()

with warnings.catch_warnings():
warnings.simplefilter('ignore', DeprecationWarning)
>   seq = base64.decodestring(b64)
E   AttributeError: module 'base64' has no attribute 'decodestring'

tests/test_x509.py:595: AttributeError
=== warnings summary
===
M2Crypto/X509.py:44

/<>/.pybuild/cpython3_3.9_m2crypto/build/M2Crypto/X509.py:44:
SyntaxWarning: "is not" with a literal. Did you mean "!="?
value.strip('0123456789abcdefABCDEF:') is not '':

M2Crypto/SSL/Checker.py:67

/<>/.pybuild/cpython3_3.9_m2crypto/build/M2Crypto/SSL/Checker.py:67:
DeprecationWarning: invalid escape sequence \.
numericIpMatch = re.compile('^[0-9]+(\.[0-9]+)*$')

M2Crypto/SSL/Checker.py:257

/<>/.pybuild/cpython3_3.9_m2crypto/build/M2Crypto/SSL/Checker.py:257:
DeprecationWarning: invalid escape sequence \.
certHost = certHost.replace('.', '\.')

M2Crypto/SSL/Checker.py:258

/<>/.pybuild/cpython3_3.9_m2crypto/build/M2Crypto/SSL/Checker.py:258:
DeprecationWarning: invalid escape sequence \.
certHost = certHost.replace('*', '[^\.]*')

.pybuild/cpython3_3.9_m2crypto/build/tests/test_obj.py::ObjectsTestCase::test_detailed_error_message

/<>/.pybuild/cpython3_3.9_m2crypto/build/tests/test_obj.py:127:
DeprecationWarning: Please use assertRegex instead.
self.assertRegexpMatches(str(e),

.pybuild/cpython3_3.9_m2crypto/build/tests/test_ssl.py::TwistedSSLClientTestCase::test_twisted_wrapper

/<>/.pybuild/cpython3_3.9_m2crypto/build/tests/test_ssl.py:1143:
UserWarning: Skipping twisted wrapper test because twisted not found
warnings.warn(

-- Docs: https://docs.pytest.org/en/latest/warnings.html
= 2 failed, 297 passed, 2 skipped, 6 warnings in 78.32 seconds
=
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.9_m2crypto/build; python3.9 -m pytest
tests
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p
"3.9 3.8" returned exit code 13
make: *** [debian/rules:17: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

Bug#972131: ITP: gammastep -- Adjust display hue to outside lighting conditions on Wayland

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 
X-Debbugs-CC: debian-de...@lists.debian.org
X-Debbugs-CC: team+swa...@tracker.debian.org
X-Debbugs-CC: r...@debian.org
X-Debbugs-CC: rhal...@old-forest.org


* Package name: gammastep
  Version : 2.0.2
  Upstream Author : Jon Lund Steffensen 
* URL : https://gitlab.com/chinstrap/gammastep
* License : GPL-3+
  Programming Lang: C, and Python for an applet
  Description : Adjust display hue to outside lighting conditions

Gammastep automatically adjusts the color temperature of computer
displays to help reduce the eye strain that comes with working in
low-light conditions.

Based on the geographical location of the computer system, Gammastep
will keep the screen at the default bluish hue during daytime but
adjust to an orange or reddish color in the evening hours and
nighttime.

Gammastep is similar to the redshift package but works with some
Wayland compositors. (I am not sure about GNOME or KDE there.). The
maintainers of the redshift package were copied on this message, in
case they are interested.

Going forward, I would prefer if the Sway team (or another Wayland
team) assumed maintenance of this package. As a happy Sway user I
would also consider joining a team, if needed. Thanks!

Kind regards
Felix Lechner

Bug#475122: OSTRZEŻENIE!!!

[Edyta Szymanska]

Szanowny UCytkowniku,   
  Twoje konto przekroczy2o limit przydzia2u ustawiony przez 
administratora i moCesz nie by7 w stanie wysy2a7 ani odbiera7 nowej 
poczty, dop�ki nie zweryfikujesz swojego konta  
  
 
   

  Aby ponownie zweryfikowa7 swoje konto 
   
 
   KLIKNIJ TUTAJ, ABY ZWERYFIKOWA6

 
  kliknij powyCszy link, aby zweryfikowa7 
 Brak weryfikacji Twoje konto zostanie trwale wy25czone i usuni9te z naszej 
bazy danych.   Gor5ce pozdrowienia.
Helpdesk dla Administratora Poczty.
Copyright  All Right Reserved.

Bug#972130: vinagre: basically unmaintained upstream

[Simon McVittie]

Source: vinagre
Version: 3.22.0-7
Severity: important
Tags: wontfix

vinagre is no longer practically maintained upstream; it has not yet
been officially deprecated by being moved to the Archive group on GNOME's
Gitlab, but I suspect it's only a matter of time.

Maintained alternatives include remmina, which is also GTK-based.

smcv

Bug#972129: vino: unmaintained upstream

[Simon McVittie]

Source: vino
Version: 3.22.0-6
Severity: important

vino is no longer maintained upstream and has been moved to
. I don't think it's practically
usable with current GNOME Shell in its default (Wayland) mode either,
due to relying on X11.

smcv

Bug#972098: dgit assumes 'master' as main branch

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Bug#972098: dgit assumes 'master' as main 
branch"):
> Package: dgit
> Version: 9.12
> Severity: important
...
> on various packaging repositories I routinely use dgit on, it has started to
> fail on me with the following error:

This is odd.  dgit doesn't normally care much about branches.

> $ dgit pbuilder
> Format `3.0 (quilt)', need to check/update patch stack
> examining quilt state (multiple patches, linear mode)
> gzip: warning: GZIP environment variable is deprecated; use an alias or 
> script
> dgit: base trees orig=cfd69559157d8cae3e6d o+d/p=08391389eaf6c31ab9dc
> dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
> dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
> starting quiltify (multiple patches, linear mode)
> quiltify linearisation planning successful, executing...
> error: pathspec 'master' did not match any file(s) known to git
> dgit: failed command: git checkout -q master
> 
> dgit: error: subprocess failed with error exit status 1
> 
> Specifically, I'm running this dgit * command from a debian/master branch (I
> will move to debian/main or debian/sid soon), with only the other branches
> being upstream/latest and pristine-tar. I don't have a master branch in these
> repositories at all.

Can you please run the command again with (let's say) -DD ?

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#607969: sqlite: removal of sqlite 2 is really overdue

[Simon McVittie]

Control: retitle -1 sqlite: removal of sqlite 2 is really overdue

On Thu, 23 Jan 2020 at 10:05:40 +, Simon McVittie wrote:
> So I think the steps that would be necessary to remove sqlite 2 from
> bullseye [...] would go something like this:
...
> * for packages in group 1 (libdbi-drivers and similar), ask their
>   maintainers to remove the sqlite 2 binary package, with a migration path
>   if appropriate (for example, if a Perl app is configured to use the
>   sqlite 2 backend, and sqlite 3 can still read and write sqlite 2
>   databases, then DBI could select its sqlite 3 backend instead)

Unfortunately, according to , sqlite 3
cannot read sqlite 2 database files. They need to be migrated via a
dump/restore operation, where the dump is performed with sqlite(1)
from sqlite 2.

On Mon, 12 Oct 2020 at 23:08:09 +0200, Moritz Mühlenhoff wrote:
> I think the removal of sqlite 2 is really overdue. I've just filed an
> RM bug for qsf, shall we bump this bug to RC to drop remaining rdeps
> via auto removals if not fixed?

Remaining rdeps according to dak are:

cl-sql: cl-sql-sqlite
dbconfig-common: dbconfig-sqlite
golang-gosqlite-dev: golang-gosqlite-dev
kannel-sqlbox: kannel-sqlbox
libopendbx: libopendbx1-sqlite
qsf: qsf

(plus some Build-Depends that affect a subset of those packages)

I've reported bugs usertagged as debian...@lists.debian.org / libsqlite0.


cl-sql, dbconfig-common, libopendbx are all multiplexing layers for
various SQL backends. They should drop their sqlite backend and keep
only the sqlite3 backend. Users who have a sqlite 2 database will need
to keep the sqlite binary package installed for long enough to migrate.
cl-sql-tests appears to be the only reverse dependency of any of these
three binary packages. Of the source packages:
- dbconfig-common has *many* rdeps and cannot reasonably be removed, so
  it's the main blocker for this removal
- libopendbx is orphaned, but has one somewhat popular rdep, opendkim
- cl-sql has two rdeps in contrib

golang-gosqlite-dev depends on *both* libsqlite-dev and libsqlite3-dev.
Nothing in Debian depends on it. It could be removed.

kannel-sqlbox depends on *both* libsqlite-dev and libsqlite3-dev. If I'm
understanding configure.in correctly, I think it will automatically lose
the sqlite 2 option if binNMU'd against kannel (>= 1.4.5-8), but it needs
a sourceful upload *anyway* for an unrelated RC bug. It isn't in testing.

qsf is not RC-buggy, but has had removal requested already, and I already
reported an 'important' bug in January (because it was the only one whose
dependency did not have a sqlite3 alternative).

smcv

Bug#972128: kannel-sqlbox: Please remove support for long-unmaintained sqlite 2

[Simon McVittie]

Package: kannel-sqlbox
Version: 0.7.2-5
Severity: important
Tags: bullseye sid
User: debian...@lists.debian.org
Usertags: libsqlite0
Control: block 607969 by -1

kannel-sqlbox builds a binary package that Depends on libsqlite0. This
is sqlite 2, which was superseded in 2004 and is planned to be removed
(see #607969), and nothing in Debian seems to depend on it. Please remove
the sqlite 2 dependency, leaving only sqlite 3 support.

If I'm understanding the build system correctly, it might be possible
to fix this with a binNMU, since kannel dropped support for sqlite 2
in January, and kannel-sqlbox picks up its sqlite 2 and/or 3 support
from kannel. However, kannel-sqlbox needs source changes anyway to
address a FTBFS with gcc 10 (#957397).

This bug is currently non-RC, but is very likely to become RC soon.

Thanks,
smcv

Bug#972127: golang-gosqlite-dev: Please remove support for long-unmaintained sqlite 2

[Simon McVittie]

Package: golang-gosqlite-dev
Version: 0.0~hg20130601-1
Severity: important
Tags: bullseye sid
User: debian...@lists.debian.org
Usertags: libsqlite0
Control: block 607969 by -1

golang-gosqlite-dev Depends on libsqlite0-dev. This is sqlite 2, which was
superseded in 2004 and is planned to be removed (see #607969). Please
remove the sqlite 2 support, leaving only sqlite 3.

This bug is currently non-RC, but is very likely to become RC soon.
Because nothing in Debian appears to depend on golang-gosqlite-dev, this
is likely to result in the removal of this package from Debian if not fixed.

Thanks,
smcv

Bug#972126: libopendbx: Please remove support for long-unmaintained sqlite 2

[Simon McVittie]

Package: libopendbx1-sqlite
Version: 1.4.6-14
Severity: important
Tags: bullseye sid
User: debian...@lists.debian.org
Usertags: libsqlite0
Control: block 607969 by -1

libopendbx builds a libopendbx1-sqlite binary package. This is a wrapper
for sqlite 2, which was superseded in 2004 and is planned to be removed
(see #607969), and nothing in Debian seems to depend on it. Please remove
the libopendbx1-sqlite binary package.

This bug is currently non-RC, but is very likely to become RC soon.

Thanks,
smcv

Bug#972125: dbconfig-common: Please remove support for long-unmaintained sqlite 2

[Simon McVittie]

Package: dbconfig-sqlite
Version: 2.0.14
Severity: important
Tags: bullseye sid
User: debian...@lists.debian.org
Usertags: libsqlite0

dbconfig-common builds a dbconfig-sqlite binary package. This is a wrapper
for sqlite 2, which was superseded in 2004 and is planned to be removed
(see #607969). Please remove the dbconfig-sqlite binary package.

This bug is currently non-RC, but is very likely to become RC soon.

Thanks,
smcv

Bug#972124: cl-sql-sqlite: Please remove support for long-unmaintained sqlite 2

[Simon McVittie]

Package: cl-sql-sqlite
Version: 6.7.1-1
Severity: important
User: debian...@lists.debian.org
Usertags: libsqlite0

cl-sql builds a cl-sql-sqlite binary package, which is depended on by
cl-sql-tests, and apparently nothing else in Debian. This is a binding
for sqlite 2, which was superseded in 2004 and is planned to be removed
(see #607969).

Please remove the cl-sql-sqlite binary package and the libsqlite0-dev
build-dependency.

This bug is currently non-RC, but is very likely to become RC soon.

Thanks,
smcv

Bug#972123: Please enable CONFIG_VIDEO_SUNXI_CEDRUS for Allwinner/sunxi

[Damon Tarry]

Package: src:linux
Version: 5.8.10-1
Severity: wishlist

Dear Maintainer,

Please enable CONFIG_VIDEO_SUNXI_CEDRUS to enable video decoding
hardware on Allwinner/sunxi devices. This includes both arm64 and
armhf (armmp) kernels.


Thanks,
Damon

Bug#972122: cloud kernel 5.5.0-2 does not boot from grub-xen

[Aleksi Suhonen]

Package: grub-xen
Version: 2.04-9
Severity: important

Linux cloud image 5.5.0-2 refuses to boot in a Xen VM from grub-xen. 
Older versions up to and including 5.5.0-1 work, and all versions after 
5.5.0-2 fail to boot.


Here's the error message:

Loading Linux 5.6.0-1-cloud-amd64 ...
error: not xen image.
Loading initial ramdisk ...
error: you need to load the kernel first.

I ran a diff between the config files packaged with 5.5.0-1 and 5.5.0-2 
and couldn't find any significant differences other than:



< CONFIG_KERNEL_XZ=y
---
> # CONFIG_KERNEL_XZ is not set

< # CONFIG_KERNEL_LZ4 is not set
---
> CONFIG_KERNEL_LZ4=y


I don't really know how the grub works internally, but it seems to me 
that we're missing lz4io.mod? Is there a way to force grub-xen to load 
the image, even tho it's not recognized as a xen image?


Best Regards,

--
Aleksi Suhonen

() ascii ribbon campaign
/\ support plain text e-mail

Bug#972121: ImportError: cannot import name 'load_emacs_shift_selection_bindings' from...

[Kingsley G. Morse Jr.]

Package: xonsh
Version: 0.9.22+dfsg-1
Severity: important

TLDR; Add a dependency on at least version 3.0.7-1 of python3-prompt-toolkit.

Dear Maintainer,

Thank you very much for maintaining the cool
looking package named "xonsh".

I've often wanted to combine python's array math
with shell pipes, like APL and jsoftware.

So I tried installing the xonsh package, and
running it.

$ ~ xonsh
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 24554, 
in main
args = premain(argv)
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 24490, 
in premain
env = start_services(shell_kwargs, args)
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 24439, 
in start_services
builtins.__xonsh__.shell = Shell(execer=execer, **shell_kwargs)
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 16310, 
in __init__
from xonsh.ptk_shell.shell import PromptToolkitShell as shell_class
  File "/usr/lib/python3/dist-packages/xonsh/ptk_shell/shell.py", line 24, 
in 
from prompt_toolkit.key_binding.bindings.emacs import (
ImportError: cannot import name 'load_emacs_shift_selection_bindings' from 
'prompt_toolkit.key_binding.bindings.emacs' 
(/usr/lib/python3/dist-packages/prompt_toolkit/key_binding/bindings/emacs.py)
Xonsh encountered an issue during launch
Failback to /bin/bash

As you can see, it failed.

Next, I checked which package contains a file
xonsh complained about.

$ apt-file search 
/usr/lib/python3/dist-packages/prompt_toolkit/key_binding/bindings/emacs.py
python3-prompt-toolkit: 
/usr/lib/python3/dist-packages/prompt_toolkit/key_binding/bindings/emacs.py

Next, I checked if a newer version of the python3-prompt-toolkit was available.

$ apt-cache policy python3-prompt-toolkit
[...]
Installed: 2.0.10-2
Candidate: 3.0.7-1
[...]

Next, I upgraded python3-prompt-toolkit from
version 2.0.10-2 to 3.0.7-1.

root$ aptitude install python3-prompt-toolkit

Then I tried running xonsh again.

$ xonsh
~ Crustaceanly Yours ~

It worked!

So, it seems to me that Debian's fine xonsh
package might be improved by adding a dependency
for at least version 3.0.7-1 of the
python3-prompt-toolkit package.

So it is said.

So it is done.

Correct package dependencies, are

(wait for it...)

NUMBER ONE!

;-)

So,
Kingsley


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages xonsh depends on:
ii  python3-ply  3.11-4
pn  python3:any  

Versions of packages xonsh recommends:
ii  python3-prompt-toolkit  3.0.7-1
ii  python3-pygments2.3.1+dfsg-1
ii  python3-setproctitle1.1.10-2

Versions of packages xonsh suggests:
pn  xonsh-doc  

-- no debconf information

Bug#972120: medit: icon-theme.cache file conflict

[westlake]

Package: medit
Version: 1.2.0-3
Severity: important

dpkg -S /usr/share/icons/hicolor/icon-theme.cache
medit: /usr/share/icons/hicolor/icon-theme.cache

other packages such as terminator(1.92-1~bpo10+1) cannot install because 
icon-theme.cache is attached to package medit.

Bug#834129: pgadmin4 adopter wanted

[Christoph Berg]

Re: William Bonnet
> Dropping this package is a question that really makes sens. If the
> decision is to keep it, and as a postgresql and pgadmin user i would
> like to volunteer to  takeover.

Hi William,

do you have experience with Debian packaging? You'll likely have to
work on packaging or updating Python module packages in Debian as
well.

Plus debugging the whole stack on older Debian/Ubuntu releases.

Christoph

Bug#972119: terminator: conflicts with icon-theme.cache on install

[westlake]

Package: terminator
Version: 1.92-1~bpo10+1
Severity: important

apt-get install terminator refuses to install due to a file conflict 
from another package.


"Preparing to unpack .../terminator_1.92-1~bpo10+1_all.deb ...
Unpacking terminator (1.92-1~bpo10+1) ...
dpkg: error processing archive 
/var/cache/apt/archives/terminator_1.92-1~bpo10+1_all.deb (--unpack):
 trying to overwrite '/usr/share/icons/hicolor/icon-theme.cache', which 
is also in package medit 1.2.0-3

dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/terminator_1.92-1~bpo10+1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
"

Bug#972118: tpm2-abrmd: Daemon fails to start: needs to be rebuilt against newer libtss2-esys0

[Jan Medlock]

Package: tpm2-abrmd
Version: 2.3.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
tpm2-abrmd fails to start with the error

error while loading shared libraries: libtss2-sys.so.0: cannot open
shared object file: No such file or directory

I believe this is because the package libtss2-esys0 bumped the SONAME
of that library to libtss2-sys.so.1. I wonder if tpm2-abrmd simply
needs to be rebuilt against this newer library.

Thanks,
Jan Medlock

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tpm2-abrmd depends on:
ii  init-system-helpers  1.58
ii  libc62.31-4
ii  libglib2.0-0 2.66.1-1
ii  libtss2-esys03.0.1-1

tpm2-abrmd recommends no packages.

tpm2-abrmd suggests no packages.

-- no debconf information

Bug#972117: RM: dbacl -- RoQA; dead upstream, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove dbacl. It's dead upstream, RC-buggy, is orphaned since 3.5 years
without an adopter and the last maintainer upload was from 2008.

Cheers,
Moritz

Bug#834129: pgadmin4 adopter wanted

[William Bonnet]

Hi Christoph,


Dropping this package is a question that really makes sens. If the
decision is to keep it, and as a postgresql and pgadmin user i would
like to volunteer to  takeover.


Il will certainly have many question,including about the takerover
procedure since it is the first time i apply for this.


> are prone to happen. I'm not extensively using the package myself, so
> I'd be glad if someone else took over maintenance of it.
>
> Anyone interested? Otherwise I'd propose that we drop it.


king regards,

William

Bug#607969: sqlite: Still useful?

[Moritz Mühlenhoff]

On Thu, Jan 23, 2020 at 10:05:36AM +, Simon McVittie wrote:
> On Wed, 29 Oct 2014 at 10:33:32 +0100, Balint Reczey wrote:
> > Filing bugs against reverse dependencies to migrate to sqlite 3 would be
> > a better start IMO.
> 
> 5 years later, here is an updated status, using dak (the same tool the
> ftp team would use to remove packages) rather than apt-cache rdepends,
> so that all binary packages and all dependency types are considered:

> So I think the steps that would be necessary to remove sqlite 2 from
> bullseye (or any future release if bullseye is considered too soon)
> would go something like this:
> 
> * port or remove qsf (popcon inst:9, maintained via NMUs and FTBFS with
>   a future version of gdbm, so removal seems more likely)
> * make libapp-info-perl's unit test use sqlite 3 or a mock sqlite
>   (in fact it seems like it already does, so perhaps the dependency on
>   libsqlite0-dev is a mistake)
> * for packages in group 1 (libdbi-drivers and similar), ask their
>   maintainers to remove the sqlite 2 binary package, with a migration path
>   if appropriate (for example, if a Perl app is configured to use the
>   sqlite 2 backend, and sqlite 3 can still read and write sqlite 2
>   databases, then DBI could select its sqlite 3 backend instead)
> * for packages in group 2 (golang-gosqlite-dev and kannel-sqlbox), ask
>   their maintainers to drop the sqlite 2 part, leaving only the sqlite 3
>   part (possibly with a migration path, as above)

I think the removal of sqlite 2 is really overdue. I've just filed an
RM bug for qsf, shall we bump this bug to RC to drop remaining rdeps
via auto removals if not fixed?

Cheers,
Moritz

Bug#968001: tightvnc-java: Invalid module description, or, may java module be mixed with other JARs in /usr/share/java?

[Sven Geuer]

Hello Guiseppe,

I believe I solved the issue. I'll send you another unreleased version
of tighvnc-java in a separate email for you to test it.

Sven

Am Mittwoch, den 07.10.2020, 07:52 +0200 schrieb Giuseppe Sacco:
> Hello Sven,
> 
> Il giorno sab, 03/10/2020 alle 18.39 +0200, Sven Geuer ha scritto:
> > Hello Guiseppe,
> [...]
> > As I don't possess any specific java knowledge I cannot judge
> > whether
> > this will fix the issue you reported. I will send you the deb file
> > attached to a separate email and would like to ask you to test
> > whether
> > it fixes this bug for you. If it doesn't, I am afraid there is
> > little
> > what can be done, as upstream is dead.
> 
> them problem is still there. I'll try to get some more help from
> other
> java developers and, possibly, I'll gather a patch.
> 
> The current error is similar to the original one:
> 
> $ java --module-path /usr/share/java   \
>   --add-modules javafx.controls \
>   -Djavafx.preloader=lu.nowina.nexu.NexUPreLoader \
>   -Dglass.accessible.force=false -jar Neos.jar
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Unable to derive module descriptor
> for
> /usr/share/java/tightvncviewer.jar
> Caused by: java.lang.module.InvalidModuleDescriptorException:
> CapsContainer.class found in top-level directory (unnamed package not
> allowed in module)
> 
> Thank you,
> Giuseppe
> 
> 


signature.asc
Description: This is a digitally signed message part

Bug#972116: RM: qsf -- RoQA; Unmaintained, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove qsf. It's unmaintained (last maintainer upload in 2007,
only NMUs since then) and depends on legacy libs (one of the last
packages to use sqlite2 (#949662), FTBFS with the next gdbm (#904006)
and seems fairly buggy in general if it fails even with Chinese
characters in spam mails (#651881).

Cheers,
Moritz

Bug#972115: buster-pu: package sqlite3/3.27.2-3+deb10u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: g...@debian.org

A number of security fixes in sqlite, which don't warrant a DSA.
This has been tested on a Buster system (along with validating
included test cases that issues are correctly fixed).

Cheers,
Moritz
diff -Nru sqlite3-3.27.2/debian/changelog sqlite3-3.27.2/debian/changelog
--- sqlite3-3.27.2/debian/changelog 2019-06-01 17:38:52.0 +0200
+++ sqlite3-3.27.2/debian/changelog 2020-10-05 22:53:55.0 +0200
@@ -1,3 +1,18 @@
+sqlite3 (3.27.2-3+deb10u1) buster; urgency=medium
+
+  * CVE-2019-19923
+  * CVE-2019-19925
+  * CVE-2019-19959
+  * CVE-2019-20218
+  * CVE-2020-13434
+  * CVE-2020-13435
+  * CVE-2020-13630
+  * CVE-2020-13632
+  * CVE-2020-15358
+  * CVE-2019-16168
+
+ -- Moritz Mühlenhoff   Mon, 05 Oct 2020 22:53:55 +0200
+
 sqlite3 (3.27.2-3) unstable; urgency=high
 
   * Backport security related patches:
diff -Nru sqlite3-3.27.2/debian/patches/CVE-2019-16168.patch 
sqlite3-3.27.2/debian/patches/CVE-2019-16168.patch
--- sqlite3-3.27.2/debian/patches/CVE-2019-16168.patch  1970-01-01 
01:00:00.0 +0100
+++ sqlite3-3.27.2/debian/patches/CVE-2019-16168.patch  2020-10-05 
22:53:55.0 +0200
@@ -0,0 +1,66 @@
+From 725dd72400872da94dcfb6af48128905b93d57fe Mon Sep 17 00:00:00 2001
+From: drh 
+Date: Thu, 15 Aug 2019 14:35:45 +
+Subject: [PATCH] Ensure that the optional "sz=N" parameter that can be
+ manually added to the end of an sqlite_stat1 entry does not have an N value
+ that is too small. Ticket [e4598ecbdd18bd82]
+
+FossilOrigin-Name: 
98357d8c1263920b33a3648ef9214a63c99728bafa7a8d3dd6a1241b2303fd42
+---
+ src/analyze.c  |  4 +++-
+ src/where.c|  1 +
+ test/analyzeC.test | 14 ++
+ 5 files changed, 28 insertions(+), 11 deletions(-)
+
+diff --git a/src/analyze.c b/src/analyze.c
+index 31fb6f5b5..1904b9be0 100644
+--- a/src/analyze.c
 b/src/analyze.c
+@@ -1450,7 +1450,9 @@ static void decodeIntArray(
+   if( sqlite3_strglob("unordered*", z)==0 ){
+ pIndex->bUnordered = 1;
+   }else if( sqlite3_strglob("sz=[0-9]*", z)==0 ){
+-pIndex->szIdxRow = sqlite3LogEst(sqlite3Atoi(z+3));
++int sz = sqlite3Atoi(z+3);
++if( sz<2 ) sz = 2;
++pIndex->szIdxRow = sqlite3LogEst(sz);
+   }else if( sqlite3_strglob("noskipscan*", z)==0 ){
+ pIndex->noSkipScan = 1;
+   }
+diff --git a/src/where.c b/src/where.c
+index 65c92863a..a37a810a2 100644
+--- a/src/where.c
 b/src/where.c
+@@ -2670,6 +2670,7 @@ static int whereLoopAddBtreeIndex(
+ ** it to pNew->rRun, which is currently set to the cost of the index
+ ** seek only. Then, if this is a non-covering index, add the cost of
+ ** visiting the rows in the main table.  */
++assert( pSrc->pTab->szTabRow>0 );
+ rCostIdx = pNew->nOut + 1 + (15*pProbe->szIdxRow)/pSrc->pTab->szTabRow;
+ pNew->rRun = sqlite3LogEstAdd(rLogSize, rCostIdx);
+ if( (pNew->wsFlags & (WHERE_IDX_ONLY|WHERE_IPK))==0 ){
+diff --git a/test/analyzeC.test b/test/analyzeC.test
+index 02faa9c7e..2a0a89781 100644
+--- a/test/analyzeC.test
 b/test/analyzeC.test
+@@ -132,6 +132,20 @@ do_execsql_test 4.3 {
+   SELECT count(a) FROM t1;
+ } {/.*INDEX t1ca.*/}
+ 
++# 2019-08-15.
++# Ticket https://www.sqlite.org/src/tktview/e4598ecbdd18bd82945f602901
++# The sz=N parameter in the sqlite_stat1 table needs to have a value of
++# 2 or more to avoid a division by zero in the query planner.
++#
++do_execsql_test 4.4 {
++  DROP TABLE IF EXISTS t44;
++  CREATE TABLE t44(a PRIMARY KEY);
++  INSERT INTO sqlite_stat1 VALUES('t44',null,'sz=0');
++  ANALYZE sqlite_master;
++  SELECT 0 FROM t44 WHERE a IN(1,2,3);
++} {}
++
++
+ 
+ # The sz=NNN parameter works even if there is other extraneous text
+ # in the sqlite_stat1.stat column.
diff -Nru sqlite3-3.27.2/debian/patches/CVE-2019-19923.patch 
sqlite3-3.27.2/debian/patches/CVE-2019-19923.patch
--- sqlite3-3.27.2/debian/patches/CVE-2019-19923.patch  1970-01-01 
01:00:00.0 +0100
+++ sqlite3-3.27.2/debian/patches/CVE-2019-19923.patch  2020-10-02 
16:43:04.0 +0200
@@ -0,0 +1,62 @@
+From 396afe6f6aa90a31303c183e11b2b2d4b7956b35 Mon Sep 17 00:00:00 2001
+From: drh 
+Date: Wed, 18 Dec 2019 20:51:58 +
+Subject: [PATCH] Continue to back away from the LEFT JOIN optimization of
+ check-in [41c27bc0ff1d3135] by disallowing query flattening if the outer
+ query is DISTINCT.  Without this fix, if an index scan is run on the table
+ within the view on the right-hand side of the LEFT JOIN, stale result
+ registers might be accessed yielding incorrect results, and/or an
+ OP_IfNullRow opcode might be invoked on the un-opened table, resulting in a
+ NULL-pointer dereference.  This problem was found by the Yongheng and Rui
+ fuzzer.
+
+FossilOrigin-Name: 
862974312edf00e9d1068115d1a39b7235b7db68b6d86b81d38a12f025a4748e
+---
+ src/select.c   |  8 ++--
+ test/join.test | 

Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)

[Étienne Mollier]

Hi Andreas,

Andreas Tille, on 2020-10-12 17:56:38 +0200:
> third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
>   103 |   __asm__ ("cpuid\n\t" \
>   |   ^~~
> third_party/cpuid.h:162:3: note: in expansion of macro ‘__cpuid’
>   162 |   __cpuid (__ext, __eax, __ebx, __ecx, __edx);
>   |   ^~~
> third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
>   103 |   __asm__ ("cpuid\n\t" \
>   |   ^~~
> third_party/cpuid.h:185:3: note: in expansion of macro ‘__cpuid’
>   185 |   __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
>   |   ^~~
> In file included from ebwt_build.cpp:8:
> ...
> 
> Any idea how to deal with this?

I believe that cpuid.h is an architecture specific header, but
the upstream source code ships with a custom third_party/cpuid.h
which probably mainly targets amd64, hence issues on non amd64.

I ran an arm64 build a few minutes ago, after having excluded
third_party/.  This way, the source code gently failed back to
the system provided cpuid.h which should be always be
appropriate.  My build went through on arm64, as well as the
test suite.

> [1] 
> https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch

As a side note, I believe that the $(filter ...) statement added
in the patch to be able to list architectures reverted the
logic, so replaced the ifeq (...) statement to an ifneq (...).

Most changes are available on my machine.  I would have
suggested to push them, but my build targeting mips64el failed
and it seems that its because `uname -m` returns mips64 on that
architecture.  I'm not 100% sure of the name for the other
architectures, maybe listing CPUs handling popcnt might be
simpler ?

Anyway in hope any of these ideas helps...

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#971830: fonts-jetbrains-mono: please advertise which scripts are covered

[Jonas Smedegaard]

Quoting Romain Porte (2020-10-12 16:04:52)
> On Thu, 08 Oct 2020 11:50:47 +0200 Jonas Smedegaard  wrote:
> > Long description emphasizes script coverage as notable feature, yet 
> > does not tell _which_ scripts are covered.
> >
> > The purpose of package long description is to aid a user unfamiliar 
> > with a package to decide if relevant to install, and most users will 
> > likely want to know if their own script is covered rather than 
> > simply "many".
> >
> > Please therefore consider including in long description which 
> > scripts is covered by fonts-jetbrains-mono.
> >
> > I can recommend to look at how such information is automated in the 
> > source package fonts-noto.

> After looking the debian/control file of fonts-noto [1], I only was 
> able to find out that the "${fonts:scriptfonts}" variable was used in 
> the long description of the package to list how many scripts were 
> supported by the package.
> 
> I however failed to see how the full list of scripts was included in 
> the long description of the package — can you guide me to where this 
> is done, and how?

The data is resolved in rules file: 
https://salsa.debian.org/fonts-team/fonts-noto/-/blob/master/debian/rules#L91

Sorry, I had forgotten that fonts-noto still uses cdbs which is alien to 
many and not recommended for new packaging work.

Totally untested, it should look something like the following rewritten 
to instead use short-form dh sequencer:

override_dh_dh_gencontrol:
printf fonts:familylist= \
>> debian/fonts-jetbrains-mono.substvars
otfinfo -a $(wildcard src/*.ttf) | cut -d: -f2 \
| LC_ALL=C sort -u \
| $$(substvars-list-encode) \
>> debian/fonts-jetbrains-mono.substvars
dh_gencontrol -- -Vfonts:scriptcount="$(fonts-scriptcount)"


Hope that helps,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#972096: vice: Build does not work wirh real drives via opencbm

[Thomas Maaß]

Package: vice
Version: 3.4.0.dfsg-3
Severity: normal

Dear Maintainer,

The Debian Vice package does not support real drives via OpenCBM. It is enabled
in the rules file, but it is not available, until the Vice is built against the
OpenCBM development library. There are no official Debian Packages for opencbm,
but I built my own. I can confirm, when rebuilding Vice with the OpenCBM lib
installed, the real drives work as expected.
OpenCBM can be found here:
https://sourceforge.net/projects/opencbm

Regards
Thomas



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vice depends on:
ii  dpkg 1.20.5
ii  libasound2   1.2.3.2-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-3
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-4.2
ii  libgcc-s110.2.0-13
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libgl1   1.3.2-1
ii  libglew2.1   2.1.0-4+b1
ii  libglib2.0-0 2.66.0-2
ii  libgtk-3-0   3.24.23-2
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libpango-1.0-0   1.46.2-1
ii  libpangocairo-1.0-0  1.46.2-1
ii  libpng16-16  1.6.37-3
ii  libpulse013.0-5
ii  libreadline8 8.0-4
ii  libstdc++6   10.2.0-13
ii  zlib1g   1:1.2.11.dfsg-2

vice recommends no packages.

vice suggests no packages.

-- no debconf information

Bug#972114: sympa: CVE-2020-26880

[Salvatore Bonaccorso]

Source: sympa
Version: 6.2.40~dfsg-7
Severity: important
Tags: security upstream
Forwarded: https://github.com/sympa-community/sympa/issues/1009
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sympa, but this is
mainly for having a tracking bug in Debian.

CVE-2020-26880[0]:
| Sympa through 6.2.57b.2 allows a local privilege escalation from the
| sympa user account to full root access by modifying the sympa.conf
| configuration file (which is owned by sympa) and parsing it through
| the setuid sympa_newaliases-wrapper executable.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-26880
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26880
[1] https://github.com/sympa-community/sympa/issues/1009

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#971830: fonts-jetbrains-mono: please advertise which scripts are covered

[Romain Porte]

On Thu, 08 Oct 2020 11:50:47 +0200 Jonas Smedegaard  wrote:
> Package: fonts-jetbrains-mono
> Version: 1.0.4-1
> Severity: minor
>
> Hi,
>
> Long description emphasizes script coverage as notable feature,
> yet does not tell _which_ scripts are covered.
>
> The purpose of package long description is to aid a user
> unfamiliar with a package to decide if relevant to install,
> and most users will likely want to know if their own script is covered
> rather than simply "many".
>
> Please therefore consider including in long description which scripts
> is covered by fonts-jetbrains-mono.
>
> I can recommend to look at how such information is automated
> in the source package fonts-noto.
>
>
> - Jonas
>
Hi Jonas,

After looking the debian/control file of fonts-noto [1], I only was able
to find out that the "${fonts:scriptfonts}" variable was used in the
long description of the package to list how many scripts were supported
by the package.

I however failed to see how the full list of scripts was included in the
long description of the package — can you guide me to where this is
done, and how?

The current "supported languages" count (and other counts) are directly
extracted from upstream's website.

Best regards,

Romain.

[1]
https://salsa.debian.org/fonts-team/fonts-noto/-/blob/master/debian/control




signature.asc
Description: OpenPGP digital signature

Bug#972062: openjfx: Make OpenJFX visible to Java programs by default

[Leandro Doctors]

I see.
Thanks for your answer, Emmanuel!

BTW: I know there are lots of documents out there regarding this, but
I really would appreciate it if you could point me to "recommended
practices" regarding this procedure.

Best,
Leandro

Bug#972110: RFS: cbor2/5.2.0-1 [ITP] -- Python implementation of CBOR

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "cbor2":

 * Package name: cbor2
   Version : 5.2.0-1
   Upstream Author : Alex Grönholm 
 * URL : https://github.com/agronholm/cbor2
 * License : Expat
 * Vcs : https://salsa.debian.org/python-team/packages/cbor2
   Section : python

It builds those binary packages:

  python-cbor2-doc - Python implementation of CBOR (common documentation)
  python3-cbor2 - Implements Concise Binary Object Representation 
(Python 3)


To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/cbor2/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cbor2/cbor2_5.2.0-1.dsc


Changes for the initial release:

 cbor2 (5.2.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #972039)

Regards,
Bastian

Bug#972113: libonig: CVE-2020-26159

[Salvatore Bonaccorso]

Source: libonig
Version: 6.9.5-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/kkos/oniguruma/issues/207
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libonig.

CVE-2020-26159[0]:
| In Oniguruma 6.9.5_rev1, an attacker able to supply a regular
| expression for compilation may be able to overflow a buffer by one
| byte in concat_opt_exact_str in src/regcomp.c .


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-26159
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26159
[1] https://github.com/kkos/oniguruma/issues/207
[2] 
https://github.com/kkos/oniguruma/commit/cbe9f8bd9cfc6c3c87a60fbae58fa1a85db59df0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#972112: RFS: xmodem/0.4.6+dfsg-1 [ITP] -- xmodem file transfer protocol library (Python 3)

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "xmodem":

 * Package name: xmodem
   Version : 0.4.6+dfsg-1
   Upstream Author : Wijnand Modderman 
 * URL : https://github.com/tehmaze/xmodem
 * License : Expat
 * Vcs : https://salsa.debian.org/python-team/packages/xmodem
   Section : python

It builds those binary packages:

  python3-xmodem - xmodem file transfer protocol library (Python 3)

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/xmodem/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xmodem/xmodem_0.4.6+dfsg-1.dsc


Changes for the initial release:

 xmodem (0.4.6+dfsg-1) unstable; urgency=medium
 .
   * Initial release (Closes: #971959)

Regards,
Bastian

Bug#972111: RFS: python-onewire/0.2-1 [ITP] -- Wrapper for OWFS C-API (Python 3)

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-onewire":

 * Package name: python-onewire
   Version : 0.2-1
   Upstream Author : Kimmo Huoman 
 * URL : https://github.com/kipe/python-onewire
 * License : Expat
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-onewire

   Section : python

It builds those binary packages:

  python3-onewire - Wrapper for OWFS C-API (Python 3)

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/python-onewire/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-onewire/python-onewire_0.2-1.dsc


Changes for the initial release:

 python-onewire (0.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #971950)

Regards,
Bastian

Bug#972109: iperf3: opaque error message when attempting to connect to a non-running iperf3 server

[Celejar]

Package: iperf3
Version: 3.9-1
Severity: wishlist


Hi,

When running iperf3 and attempting to connect to a non-running iperf3
server (i.e., a closed TCP port), this error message is returned:

~$ iperf3 -c somehost
iperf3: error - unable to send control message: Bad file descriptor

iperf3's current message isn't a very clear description of the problem.
Earlier versions of iperf3 (such as 3.6-2, in Stable) print out the much
clearer:

~$ iperf3 -c somehost
iperf3: error - unable to connect to server: Connection refused

I suggest that the earlier message be reinstated.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iperf3 depends on:
ii  libc6  2.31-4
ii  libiperf0  3.9-1

iperf3 recommends no packages.

iperf3 suggests no packages.

-- no debconf information

Bug#972096: vice: Build does not work wirh real drives via opencbm

[Spiro Trikaliotis]

Hello,

I am Spiro, the current upstream OpenCBM main developer and a former
VICE developer.

* On Mon, Oct 12, 2020 at 06:17:27PM +0200 Thomas Maaß wrote:
> Package: vice
> Version: 3.4.0.dfsg-3
> Severity: normal
> 
> Dear Maintainer,
> 
> The Debian Vice package does not support real drives via OpenCBM. It is 
> enabled
> in the rules file, but it is not available, until the Vice is built against 
> the
> OpenCBM development library. There are no official Debian Packages for 
> opencbm,
> but I built my own. I can confirm, when rebuilding Vice with the OpenCBM lib
> installed, the real drives work as expected.
> OpenCBM can be found here:
> https://sourceforge.net/projects/opencbm

Please use the newest OpenCBM project homepage on GitHub:

https://github.com/OpenCBM

The one on SF is outdated. I am working on keeping both git repositories
in sync, but the github one is the one where development takes place (if
any).

While it might not be a good place to mention it here on the Debian BTS,
I already created DEB packages which can be downloaded on
https://software.opensuse.org//download.html?project=home%3Astrik=opencbm
(Devel homepage: https://build.opensuse.org/package/show/home:strik/opencbm)

I tried the best I could do, but I expect it will not comply to the
Debian policies. However, if someone wants to create an official
package, this might be a starting point.

Regards,
Spiro.

-- 
Spiro R. Trikaliotis
http://spiro.trikaliotis.net/

Bug#972089: Backport hplip 3.20.5 to buster-backports

[Didier 'OdyX' Raboud]

Hello Alex, and thanks for your bugreport,

Thankfully, now with driverless printing [0] and sane-airscan [1], printers 
such as yours shouldn't need hplip anymore. (Also, hplip's code quality isn't 
monotonously upwards, so printing without hplip is often a preferable option). 
That said, the situation in sid and bullseye (current testing) is likely much 
better in these respects than in buster. Could you maybe test driverless 
printing, and/or sane-airscan?

As for the backporting; thank you for the patch removal proposals. As I've 
just uploaded 3.20.9+dfsg0-3 to unstable; it should migrate to testing in 
about 5-10 days, so , if your testing isn't successful, I'll prepare a 3.20.9 
backport. I'm testing a build as I write this.

Please report the results of your tests if you have the occasion.

Best regards, and thanks for your work!

Cheers,
OdyX



[0] https://wiki.debian.org/DriverlessPrinting
[1] https://github.com/alexpevzner/sane-airscan

Le lundi, 12 octobre 2020, 15.10:35 h CEST Alex ARNAUD a écrit :
> Package: hplip
> Severity: wishlist patch
> Tags: ||buster||
> 
> Hello,
> 
> Why I'd like this to be backported to buster-backports ?
> My new printer, an HP 2700 series is only compatible with HP Lip
> 3.20.5+. This is based on my own tests where only half of printed pages
> are printed. This is also based on the upstream table
>  ndex> where it is indicated the "HP DeskJet 2700 All-in-One Printer series"
> is compatible with 3.20.5.
> 
> What did I already do to figure this out?
> With the help of Samuel Thibault, I was able to recompile HP Lip 3.20.5
> on a Buster virtual machine and I produced two patch for it. The patches
> are attached to this mail. One is to update the debian/patches/series
> file and the second one is to refresh the patch 0072 (just a quilt
> refresh on it). I initially would like to propose a pull request on
> Salsa but there is no branch to submit the changes.
> 
> What my patch does?
> It reverts all the python3.8 specific patches because Debian Buster is
> based on Python 3.7 and because python3.7 library is named "python3.7m",
> not only python3.7.
> 
> What I think HP Lip should be backported to buster-backports?
> I think it'd be really helpful for people would like to stay on stable
> with new HP printers which require new HP Lip to have a new version in
> backports.
> 
> How do I check if it works?
> 
> 1. I upgraded the compiled packages with the following command:
> > sudo dpkg -iO .../*.deb
> 
> 2) I rebooted my virtual machine to ensure the new HP Lip version is loaded
> 
> 3) I configured my HP Desktop 3630 printer (launched with
> system-config-printer)
> 
> 4) I tried a print test job launched with system-config-printer
> 
> 5) I tried a scan with simple-scan
> 
> Result:
> Everything seems to work correctly.
> 
> Thanks in advance,
> Alex.


-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#960742: RFS: lazpaint/7.1.3 ITP -- add LazPaint to Debian

[Johann ELSASS]

Hello,

I guess I have fixed the problem with the dependency. In fact "lazarus-project" 
is a package downloaded on Lazarus site to get latest version, but that's not 
the one in the Debian distribution. So I replaced it with "lcl" and it seems to 
compile.

I don't know if using pbuilder matters nor what pbuilder is. What I found when 
looking about packages was using debuild.
https://wiki.debian.org/Packaging/Intro

-- 
  Johann ELSASS
  circu...@operamail.com

On Wed, Sep 9, 2020, at 10:10 PM, Tobias Frost wrote:
> On Wed, Sep 09, 2020 at 11:23:17AM +0200, Johann ELSASS wrote:
> > Hello,
> > 
> > I have made a repository with everything in it. For now it is version 6.4.1.
> 
> (Robin also replied, please read the bug mentioned there… Though it has no
> solution it might help understanding mechanics)
> 
> 
>  
> > It is there: https://github.com/bgrabitmap/lazpaint-upstream
> 
> Thanks for that, I think that is a starting point, but still some way to go.
> 
> First you need your build env fixed… I could not build the package; 
> however
> I'm not using dpkg-buildpackage but pbuilder for the job. pbuilder is 
> closer to
> how the buildds are working. You should find guides how to setup 
> pbuilder with
> somre research. Then make sure to give it a spin using some known-good 
> source package:
> For example 
> apt source hello && cd hello-*/ && pdebuild
> 
> After that, try that with your package (you need to create an orig.tar. 
> before;
> easiest way (but not 100% correct for later -- this is just to bootstrap you)
> is just to tar up the cloned git repo as lazpaint_6.4.1.orig.tar.xz
> 
> You will then see that the package is not building with pbuilder…*
> So your next goal is then to fix that. I unfortunatly won't be able to help
> much with lazbuild/lazarus problems, so you likely need to figure out stuff
> yourself. ask here when you've got stuck. Taking a look at other (lazarus)
> packages might help too, of course.
> 
> pbuilder bails out with
>  The following packages have unmet dependencies:
>   pbuilder-satisfydepends-dummy : Depends: lazarus-project (>= 1.8.6) which 
> is a
>virtual package and is not provided by any available package
> 
> That means "lazarus-project" is as Build-Depends, there is no package 
> with that name.
> Not sure what it needed here. But I think I saw something in the bug 
> Robin referenced.
> 
> Once you've got your package compiling, let us know.
> 
> I wish you best of luck: The first package is always the hardest -- and I fear
> you did not choose the easiest one!
> 
> Cheers,
> -- 
> tobi
> 
>

Bug#972108: gdm3: some Xsession.d files fail with has_option: not found

[Dmitry Borodaenko]

Package: gdm3
Version: 3.38.0-2
Severity: important
Tags: patch

Changes in x11-common for #920778
(https://salsa.debian.org/xorg-team/xorg/-/merge_requests/5) moved
has_option function from Xsession.d/20x11-common_process-args to
Xsession, and now the Xsession.d files that depend on it fail to load.
For example, 30x11-common_xresources fails to load ~/.Xresources.

Adding the implementation of this function from /etc/X11/Xsession to
/etc/gdm3/Xsession before the Xsession.d files are sourced fixed the
problem. Patch attached.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-1
ii  dconf-cli 0.38.0-1
ii  dconf-gsettings-backend   0.38.0-1
ii  debconf [debconf-2.0] 1.5.74
ii  gir1.2-gdm-1.03.38.0-2
ii  gnome-session [x-session-manager] 3.38.0-2
ii  gnome-session-bin 3.38.0-2
ii  gnome-session-common  3.38.0-2
ii  gnome-settings-daemon 3.38.0-2
ii  gnome-shell   3.38.1-1
ii  gnome-terminal [x-terminal-emulator]  3.38.0-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:2.8.5-3+b1
ii  libc6 2.31-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libgdm1   3.38.0-2
ii  libglib2.0-0  2.66.1-1
ii  libglib2.0-bin2.66.1-1
ii  libgtk-3-03.24.23-2
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd246.6-1
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.50.1+dfsg-1
ii  libselinux1   3.1-2
ii  libsystemd0   246.6-1
ii  libx11-6  2:1.6.12-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.14-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  mutter [x-window-manager] 3.38.1-1
ii  policykit-1   0.105-29
ii  procps2:3.3.16-5
ii  ucf   3.0043
ii  x11-common1:7.7+21
ii  x11-xserver-utils 7.7+8
ii  xterm [x-terminal-emulator]   360-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.38.0-2
ii  desktop-base10.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.9-2
ii  xserver-xorg1:7.7+21
ii  zenity  3.32.0-6

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

-- Configuration Files:
/etc/gdm3/Xsession changed [not included]

-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3
>From 498f2570edaa193256b21378ef551b28a301ea4d Mon Sep 17 00:00:00 2001
From: Dmitry Borodaenko 
Date: Mon, 12 Oct 2020 11:11:26 -0700
Subject: [PATCH] Implement has_option in Xsession

Now that x11-common moved this function from 20x11-common_process-args
to Xsession (see #920778), gdm's version of Xsession also has to
implement it.
---
 debian/Xsession | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/debian/Xsession b/debian/Xsession
index 30132ef1..a10f106f 100644
--- a/debian/Xsession
+++ b/debian/Xsession
@@ -177,6 +177,24 @@ if [ "x$command" = "xcustom" ] ; then
   set default $*
 fi
 
+OPTIONS="$(
+  if [ -r "$OPTIONFILE" ]; then
+cat "$OPTIONFILE"
+  fi
+  if [ -d /etc/X11/Xsession.options.d ]; then
+run-parts --list --regex '\.conf$' /etc/X11/Xsession.options.d
+  fi
+)"
+
+has_option() {
+  # Ensure that a later no-foo overrides an earlier foo
+  if [ "$(echo "$OPTIONS" | grep -Eo "^(no-)?$1\>" | tail -n 1)" = "$1" ]; then
+return 0
+  else
+return 1
+  fi
+}
+
 # use run-parts to source every file in the session directory; we source
 # instead of executing so that the variables and functions defined above
 # are available to the scripts, and so that they can pass variables to each
-- 

Bug#972106: setzer: Never migrated to Debian Testing (non-source-only upload)

[Boyuan Yang]

Source: setzer
Severity: important
Version: 0.3.1-1
Tags: sid
X-Debbugs-CC: stephanlach...@protonmail.com gl...@debian.org

Hi Anton and Stephan,

I noticed that the package setzer in Debian ( 
https://tracker.debian.org/pkg/setzer ) never migrated to Debian Testing
because all uploads are not source-only upload. This prevents the package from
appearing in future Debian Stable releases (prospective Debian 11).

Please make another source-only upload to fix this problem. For detailed
instruction, please also check http://wiki.debian.org/SourceOnlyUpload for
more information.

Thanks and let me know if you have any questions.

Regards,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#970234: consider dropping "No hard links in source packages"

[Helmut Grohne]

Hi cate,

On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote:
> The rationale was probably similar so symlinks: they may fail across
> different filesystems, and we supported to have e.g. / /usr /usr/share
> /usr/local /var (and various /var/*) /home /tmp /boot etc on different file
> systems. Now we are more strict on where we can split filesystems (and disk
> are larger, and LVM simplified much of filesystem handling).

You appear to be talking about binary packages. This bug is about source
packages. When you unpack a source package, you are creating a directory
hiearchy rooted at the point where you start unpacking. There is not
possibly any reasonable way to split your source package into multiple
file systems. This is very different from binary packages where the
underlying hiearchy is shared with other packages and directories
frequently already exist.

> I think a hardlink on same directory should be fine, or within directories
> which must be on the same filesystem.

I argue that all files within a source package are always located on the
same filesystem, because the unpack step creates the source package root
directory on one file system and everything else resides on that very
filesystem.

For binary packages, restricting the use of symlinks makes a lot more
sense to me.

Helmut

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Hi,

On Sun, Oct 11, 2020 at 11:04:05PM +0200, Richard B. Kreckel wrote:
> > Before I dig into this, could you, please, try applying the attached patch
> and check if it works?

I strongly suggest that you do not proxy builds through me. The latency
is much higher than doing it yourself. The primary goal of cross builds
is that you can build for anything on your box instead of having to own
the target box. All you need to do is pass --host to sbuild or
--host-arch to pbuilder.

Nevertheless, I attempted applying your box and built for arm64 and
ppc64el. With the patch, it passes the build for arm64, but ppc64el
still hangs in configure.

Helmut

Bug#972107: xscreensaver: looking for new sponsor

[Tormod Volden]

Package: sponsorship-requests


Hi,

(Following the advice on http://mentors.debian.net/sponsor/rfs-howto
... No, that's a joke because it is a broken link, from
https://wiki.debian.org/DebianMentorsFaq#How_do_I_get_a_sponsor_for_my_package.3F)

My current sponsor for the xscreensaver package is very busy with more
important things so I am looking for someone to sponsor my
5.44+dfsg1-1 release from
https://salsa.debian.org/debian/xscreensaver

I also asked the previous sponsor, without luck.

Hopefully someone that is also using xscreensaver and is willing to
continue in the future. A co-maintainer would also be welcome.

But someone who just jumps in and uploads this release is also very
much welcome!

Usually there are not many issues with my packages, so it shouldn't be
a big task.

Best regards.
Tormod

Bug#972105: libeigen3-dev: Eigen::eigen_assert_exception missing from includes of src/Core/products/Parallelizer.h

[Jochen Sprickerhof]

Package: libeigen3-dev
Version: 3.3.8-2
Severity: serious
Tags: patch
Justification: breaks build of ceres-solver

Hi,

Eigen 3.3.8 has bug breaking the ceres-solver build. It was already
reported and fixed upstream:

https://gitlab.com/libeigen/eigen/-/issues/2011

Please include the patch into debian/patches:

https://gitlab.com/libeigen/eigen/-/commit/ef3cc72cb65e2d500459c178c63e349bacfa834f

I can do a team upload if you don't have time.

Cheers Jochen


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libeigen3-dev depends on:
ii  pkg-config  0.29.2-1

libeigen3-dev recommends no packages.

Versions of packages libeigen3-dev suggests:
pn  libeigen3-doc   
pn  libmpfrc++-dev  

-- no debconf information

Bug#971996: yes a bug

[Russell Coker]

reopen 971996
thanks

sqlite should work if it's going to be the default.  Really it should work in 
any case.

If it's not going to work then an error message that gives some clue as to why 
would be appropriate.

If it can't work then the code that sets up MySQL for the connection should 
also set it for the url.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#972103: RFS: fonts-cascadia-code/2009.14-1 -- monospaced font designed to enhance appearance of Windows Terminal

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fonts-cascadia-code":

 * Package name: fonts-cascadia-code
   Version : 2009.14-1
   Upstream Author : Aaron Bell  
http://sajatypeworks.com
 * URL : https://github.com/microsoft/cascadia-code
 * License : SIL-OFL-1.1, Expat
 * Vcs : https://salsa.debian.org/fonts-team/fonts-cascadia-code
   Section : fonts

It builds those binary packages:

  fonts-cascadia-code - monospaced font designed to enhance appearance of 
Windows Terminal

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/fonts-cascadia-code/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-cascadia-code/fonts-cascadia-code_2009.14-1.dsc

Changes since the last upload:

 fonts-cascadia-code (2009.14-1) unstable; urgency=medium
 .
   * New upstream version.
   * d/clean: added to clean up generated pyc files.
   * Bump debhelper version to 13.

Regards,
--
  Gürkan Myczko

Bug#972104: RFS: comic-neue/2.51-1 [Team] -- less horrible remake of Comic Sans

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "comic-neue":

 * Package name: comic-neue
   Version : 2.51-1
   Upstream Author : [fill in name and email of upstream]
 * URL : http://comicneue.com/
 * License : SIL-OFL-1.1
 * Vcs : https://salsa.debian.org/fonts-team/fonts-comic-neue
   Section : fonts

It builds those binary packages:

  fonts-comic-neue - less horrible remake of Comic Sans

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/comic-neue/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/comic-neue/comic-neue_2.51-1.dsc

Changes since the last upload:

 comic-neue (2.51-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream version.
   * Bump debhelper version to 13.
   * Bump standards version to 4.5.0.

Regards,
--
  Gürkan Myczko

Bug#972087: patch for this

[Russell Coker]

Here is a patch I wrote for this.

--- /root/api.py   2020-10-12 13:53:40.232782984 +
+++ /usr/lib/python3/dist-packages/gnocchi/cli/api.py   2020-10-12 
13:57:34.331311398 +
@@ -89,9 +89,12 @@
 # TODO(sileht): When uwsgi 2.1 will be release we should be able
 # to use --wsgi-manage-chunked-input
 # https://github.com/unbit/uwsgi/issues/1428
+mode = conf.api.uwsgi_mode
+if mode == "http":
+mode = "http-socket"
 args = [
 "--if-not-plugin", "python", "--plugin", "python", "--endif",
-"--%s" % conf.api.uwsgi_mode, "%s:%d" % (
+"--%s" % mode, "%s:%d" % (
 conf.host or conf.api.host,
 conf.port or conf.api.port),
 "--master",
@@ -109,7 +112,6 @@
 if conf.api.uwsgi_mode == "http":
 args.extend([
 "--so-keepalive",
-"--http-keepalive",
 "--add-header", "Connection: Keep-Alive"
 ])

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#972102: CVE-2020-11076 CVE-2020-11077

[Moritz Muehlenhoff]

Package: puma
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2020-11076:
https://github.com/puma/puma/security/advisories/GHSA-x7jg-6pwg-fx5h

CVE-2020-11077:
https://github.com/puma/puma/security/advisories/GHSA-w64w-qqph-5gxm

Cheers,
Moritz

 

Bug#972100: CVE-2019-15547 CVE-2019-15548

[Moritz Muehlenhoff]

Source: rust-ncurses
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2019-15547 and CVE-2019-15548:
https://rustsec.org/advisories/RUSTSEC-2019-0006.html

Cheers,
Moritz

Bug#972101: CVE-2020-15888

[Moritz Muehlenhoff]

Package: lua5.4
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

Please see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15888

Cheers,
Moritz

Bug#954272: Broken again

[Lars Veldscholte]

It's broken once again.

While previously this was fixed by installing `libpmix-dev` which 
symlinked `/usr/lib/x86_64-linux-gnu/pmix/lib/libpmix.so` to 
`libpmix.so.2`, the directory `/usr/lib/x86_64-linux-gnu/pmix/` does not 
exist anymore on my machine. Only `/usr/lib/x86_64-linux-gnu/pmix2/` 
exists, yet srun is still looking at 
`/usr/lib/x86_64-linux-gnu/pmix/lib/libpmix.so`.


I fixed it manually for now by creating the 
`/usr/lib/x86_64-linux-gnu/pmix/` directory again and symlinking 
`/usr/lib/x86_64-linux-gnu/pmix/lib/libpmix.so` to 
`/usr/lib/x86_64-linux-gnu/pmix2/lib/libpmix.so`.


Regards,

Lars




signature.asc
Description: OpenPGP digital signature

Bug#972092: gnocchi-common: Creation of default gnocchi.conf should set resource_id

[Russell Coker]

Package: gnocchi-common
Version: 4.3.1-3
Severity: normal

The resource_id setting has the UUID used for gnocchi-statsd, if you don't use 
the statsd then
I don't think setting it does any harm but if you do (which is probably the 
common case) then
not setting it automatically just causes more effort for installation and more 
confusion for
new users.  Please set it to a random UUID on install.

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages gnocchi-common depends on:
ii  adduser3.118
ii  dbconfig-common2.0.11+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  python3-gnocchi4.3.1-3

gnocchi-common recommends no packages.

gnocchi-common suggests no packages.

-- debconf information:
  gnocchi/ksat-service-password: (password omitted)
  gnocchi-common/mysql/app-pass: (password omitted)
  gnocchi-common/password-confirm: (password omitted)
  gnocchi-common/mysql/admin-pass: (password omitted)
  gnocchi-common/app-password-confirm: (password omitted)
  gnocchi/ksat-service-project-name: service
  gnocchi-common/remote/host: localhost
  gnocchi/ksat-region: regionOne
  gnocchi-common/dbconfig-reinstall: false
  gnocchi-common/db/dbname: gnocchidb
* gnocchi-common/dbconfig-install: true
  gnocchi-common/missing-db-package-error: abort
  gnocchi-common/internal/skip-preseed: false
* gnocchi/configure_db: true
  gnocchi/ksat-service-username:
  gnocchi-common/dbconfig-remove: true
  gnocchi-common/remove-error: abort
  gnocchi-common/upgrade-error: abort
  gnocchi/ksat-public-url: http://localhost:5000
  gnocchi-common/upgrade-backup: true
  gnocchi-common/dbconfig-upgrade: true
  gnocchi-common/passwords-do-not-match:
* gnocchi-common/mysql/admin-user: root
  gnocchi/ksat-admin-username: admin
  gnocchi-common/purge: false
  gnocchi-common/remote/newhost:
  gnocchi/ksat-admin-project-name: admin
  gnocchi/ksat-create-service-user: true
  gnocchi-common/remote/port:
  gnocchi-common/db/app-user: gnocchi-common@localhost
* gnocchi-common/database-type: mysql
  gnocchi-common/mysql/method: Unix socket
  gnocchi-common/internal/reconfiguring: false
  gnocchi-common/install-error: abort
  gnocchi/ksat-admin-url: http://localhost:35357

Bug#951678: adequate reports obsolete-conffile while it is upgraded

[Vlad Orlov]

Hi,
 
Indeed, in 1.24 org.mate.CPUFreqSelector.conf has been moved from /etc to 
/usr/share [1] (if using the default configure setting). As a consequence, it’s 
no longer in mate-applets but in mate-applets-common instead. I guess you’ll 
have to add debian/maintscript to actually remove it from /etc on the next 
package upgrade...
 
[1] 
https://github.com/mate-desktop/mate-applets/commit/4dab9eb906dad6b284381961c912cc8d56ff1c1a
 
 

Bug#972099: CVE-2019-12067

[Moritz Muehlenhoff]

Package: qemu
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2019-12067 (patch not merged yet, though):
https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg01358.html

Cheers,
Moritz

Bug#963059: x11-common: false linebreak in 20x11-common_process-args function has_option

[Dmitry Borodaenko]

AFAICT this was fixed in 1:7.7+21 with changes introduced in
https://salsa.debian.org/xorg-team/xorg/-/merge_requests/5

Bug#972098: dgit assumes 'master' as main branch

[Didier 'OdyX' Raboud]

Package: dgit
Version: 9.12
Severity: important

Hello,

on various packaging repositories I routinely use dgit on, it has started to
fail on me with the following error:

$ dgit pbuilder
Format `3.0 (quilt)', need to check/update patch stack
examining quilt state (multiple patches, linear mode)
gzip: warning: GZIP environment variable is deprecated; use an alias or 
script
dgit: base trees orig=cfd69559157d8cae3e6d o+d/p=08391389eaf6c31ab9dc
dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
starting quiltify (multiple patches, linear mode)
quiltify linearisation planning successful, executing...
error: pathspec 'master' did not match any file(s) known to git
dgit: failed command: git checkout -q master

dgit: error: subprocess failed with error exit status 1

Specifically, I'm running this dgit * command from a debian/master branch (I
will move to debian/main or debian/sid soon), with only the other branches
being upstream/latest and pristine-tar. I don't have a master branch in these
repositories at all.

My current workaround (but it's a risky one) is to run `dgit --quilt=nocheck
pbuilder` instead.

Regards,
OdyX

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt2.1.10
ii  ca-certificates20200601
ii  coreutils  8.32-4+b1
ii  curl   7.72.0-1
ii  devscripts 2.20.4
ii  dpkg-dev   1.20.5
ii  dput-ng [dput] 1.31
ii  git [git-core] 1:2.28.0-1
ii  git-buildpackage   0.9.20
ii  libdpkg-perl   1.20.5
ii  libjson-perl   4.02000-2
ii  liblist-moreutils-perl 0.416-1+b5
ii  liblocale-gettext-perl 1.07-4
ii  libtext-csv-perl   2.00-1
ii  libtext-glob-perl  0.11-1
ii  libtext-iconv-perl 1.7-7
ii  libwww-curl-perl   4.17-7
ii  perl [libdigest-sha-perl]  5.30.3-4

Versions of packages dgit recommends:
ii  distro-info-data 0.44
ii  liburi-perl  1.76-2
ii  openssh-client [ssh-client]  1:8.3p1-1

Versions of packages dgit suggests:
ii  cowbuilder  0.89
ii  pbuilder0.230.4
ii  sbuild  0.80.0

-- no debconf information

Bug#966426: (some kind of) transition: add python3.9 as a supported python3 version

[Matthias Klose]

status update:
https://lists.debian.org/debian-python/2020/10/msg00033.html

Bug#972076: tasksel suggests the use of mktemp instead of tempfile

[Sven Joachim]

Control: severity -1 minor
Control: tags -1 patch

Am 12.10.2020 um 10:45 schrieb Markus Steinko:

> Package: tasksel
> Version: 3.59
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where
> appropriate ***
>
>    * What led up to the situation?
>
>     Using tasksel to install some task, or with the --new-install
> option
>         ends successfully, but with a warning:
>     WARNING: tempfile is deprecated; consider using mktemp instead.

The warning comes from tempfile itself, added in debianutils 4.10.  The
obvious, but untested attached patch fixes that, although it might be
better to use File::Temp instead (in perl-base since version 5.20.1-3).

Cheers,
   Sven

From 198ec980d51c45e9fb8ea818c4380e15ddb039ad Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 12 Oct 2020 19:11:43 +0200
Subject: [PATCH] Avoid tempfile deprecation warning

Since debianutils 4.10, tempfile is deprecated in favor of mktemp.
---
 tasksel.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tasksel.pl b/tasksel.pl
index 356798fb..0adb6800 100755
--- a/tasksel.pl
+++ b/tasksel.pl
@@ -710,7 +710,7 @@ sub interactive {
 			$question="tasksel/first";
 		}
 		my @default = grep { $_->{_display} == 1 && ($_->{_install} == 1 || $_->{_installed} == 1) } @tasks;
-		my $tmpfile=`tempfile`;
+		my $tmpfile=`mktemp`;
 		chomp $tmpfile;
 		my $ret=system($debconf_helper, $tmpfile,
 			task_to_debconf_C(@list),
--
2.28.0

Bug#972097: Fwd: [conrads...@gmail.com: mlpack stuck in debian unstable]

[Barak A. Pearlmutter]

Package: mlpack
Version: 3.4.1-1

I'm forwarding this to the Debian bug tracking system, it will be
allocated a number which we should CC on further correspondence about
the issue. For posterity etc.

-- Forwarded message -
From: Ryan Curtin 
Date: Mon, 12 Oct 2020 at 16:19
Subject: Re: [conrads...@gmail.com: mlpack stuck in debian unstable]
To: Barak A. Pearlmutter 
Cc: 


On Mon, Oct 12, 2020 at 04:01:21PM +0100, Barak A. Pearlmutter wrote:
> The big issue is compilation issues on various architectures, rather
> than the Julia bindings.
> Have a look,
>
> - https://tracker.debian.org/pkg/mlpack
> - https://buildd.debian.org/status/package.php?p=mlpack
>
> Help welcome, absolutely!

Awesome, thanks for the links.  I can try 'debugging-from-afar' for some
of these.  Please do feel free to open bugs in the mlpack repository for
this, just like the ensmallen repository.  I actually had no idea there
were problems here.

Anyway, quick hits:

 - armel: maybe add `-latomic` to CMAKE_EXE_LINKER_FLAGS?  e.g. add this
   to the CMake configuration command:
   "-DCMAKE_EXE_LINKER_FLAGS='-latomic'"

 - mips64el: related to this bug?
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965247
   You could also disable LTO by adding -fno-lto to CMAKE_CXX_FLAGS
   or CMAKE_LINKER_FLAGS.  I'm not sure if that will fix it.

 - mipsel: "LLVM ERROR: out of memory"; is there anything we can do
   here?  `make -j1`, maybe remove '-pipe' from CMAKE_CXX_FLAGS (if
   it's set) and set --param ggc-min-heapsize=32768 --param
   ggc-min-expand=1?  That's what I do for underpowered arm7hl
   builders on Fedora.

 - alpha: ".got subsegment exceeds 64K".  I have no idea what could be
   wrong here.  Can we just disable alpha?  There's very little
   information I can find on this one, other than a suggestion
   somewhere that the linker table sizes need to be increased, plus
   what look like a bunch of debian packages where they disabled
   alpha because of this exact issue.

 - m68k: is the version of Doxygen here different?  A workaround could
   be to regex `WARN_AS_ERROR[ ]*= YES` to `WARN_AS_ERROR = NO` in
   `Doxyfile` before the build starts.

I'm not sure about the dependency installability problems, but in the
worst case, those are all related to Python, so you could for those
architectures just disable the Python bindings.

> Meantime I'll turn off the Julia bindings.

My experience with Debian-packaged Julia actually hasn't been great, but
perhaps it's improved over time.  I think once Julia is available in
stable, perhaps the situation will be better?

--
Ryan Curtin| "Get off my lawn!"
r...@ratml.org |   - Kowalski

Bug#972025: fixed by new upstream version

[Matthias Klose]

Control: tags -1 + patch

fixed by new upstream version.
example packaging:
https://launchpad.net/~pythoneers/+archive/ubuntu/python3.9-fixes/+sourcepub/11660642/+listing-archive-extra

Bug#857454: qtltools: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#971685: buster-pu: package fish/3.0.2-2+deb10u1

[Boyuan Yang]

Hi,

On Mon, 12 Oct 2020 18:36:04 +0800 Wang Shanker 
wrote:
> Control: tags -1 - moreinfo
> Control: fixed 970777 fish/3.1.0-1
> 
> As far as I know, this issue was fixed by upstream since 3.1.0

I can confirm that the bug has been fixed in v3.1.0. Current packages in
Testing/Sid are of version 3.1.2. The metadata for bug 970777 has been updated
to reflect this information.

Thanks,
Boyuan Yang


> On Sat, 10 Oct 2020 09:33:40 +0100 "Adam D. Barratt" <
a...@adam-barratt.org.uk> wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Sun, 2020-10-04 at 19:53 -0400, Boyuan Yang wrote:
> > > I am working on solving https://bugs.debian.org/970777 , a bug that
> > > made package fish in Debian 10 unusable with sudo in terminal. The
> > > patch comes from upstream trunk.
> > 
> > The metadata for that bug indicates that it is affects the package in
> > unstable and is not yet fixed there - is that correct? If so, then the
> > fix needs to be in unstable before we can consider it for a stable
> > update. If not, please update the metadata to indicate which package
> > version the fix was first included in.


signature.asc
Description: This is a digitally signed message part

Bug#777403: leave: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Gentle ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#942884: Bug#971395: RFS: zipios++/2.2.5.0-1 -- small C++ library for reading zip files (documents)

[Tobias Frost]

On Fri, Oct 09, 2020 at 10:43:09PM +0200, François Mazen wrote:
> Hello Tobias,
> 
> thanks a lot for this valuable review!
> 
> I did my best to update the packages. It's uploaded to mentors:
> https://mentors.debian.net/package/zipios++/
> 
> Please note that the upstream applied some of my patches and they
> released a new version (2.2.6). I've updated the package with this new
> release.
> 
> Comments inline below:
> 
> >   So, yes, sourceful upload of all r-depends it will be… And you
> > likely will need
> >   to provide patches. (Luckily, those r-depends are just two: freecad
> > and enigma)
> > 
> 
> I've forked freecad and enigma in my salsa account and I'm working on
> patches.
> 
> > - On the dev package:
> >   It should not Conflict/Replaces, It should be Breaks/Replaces. 
> 
> Done
> 
> > - On the library package:
> >   be a need for the Conflict/Replace, not even a Breaks/Replaces.
> 
> Done
> 
> >  - On the docs package:
> >This is a classic "package renaming" situation explained here:
> >https://wiki.debian.org/RenamingPackages.
> >So you will need a transistional package here as well.
> >Or not renaming the -doc package.
> 
> I've added a transitional package libzipios++-doc that depends on the
> new one.

> > d/docs:
> > - don't install README.md
> 
> > - NEWS should be installed as upstream changelog (see
> > dh_installchangelogs)
> 
> Done

Thanks for fixing all that ^^

> > d/rules + d/control:
> > - It looks like as your rules already supports building docs in
> > build-indep.
> >   Please see if you can move doxygen / graphviz B-D to Build-Depends-
> > Indep.
> 
> Done

I have problems building only the arch:all packages, but I will
need to investigate first if the problem is on my side.
(Running out of time right now)

> > - The docs package has references to the old package:
> 
> References removed.
> 
> >   BTW, it is _NOT_ recommended to replace the jsquery from doxygen.
> >   read /usr/share/doc/doxygen/README.jquery.
> 
> No more replace, thanks for the documentation pointer.

You can also drop the Depends on libjs-query ;-)

> > - The dev package has the following files, which shoudln't be there:
> > drwxr-xr-x root/root 0 2020-03-07 14:08
> > ./usr/share/doc/libzipios-doc/
> > -rw-r--r-- root/root  1654 2019-08-17 00:13
> > ./usr/share/doc/libzipios-doc/NEWS.gz
> > -rw-r--r-- root/root  2352 2019-08-17 00:13
> > ./usr/share/doc/libzipios-doc/README.md.gz
> 
> Files removed.
> 
> > - The dev package isntalls the man pages. Shouldn't they go to the
> > -doc package?
> 
> Moved manpages to libzipios-doc.manpages
> 
> > - d/rules:
> >  What was the problem with
> >  "# dh_installdocs does not detect the doc main package correctly."?
> 
> By default, dh_installdocs installs the html documentation under
> /usr/share/doc/libzipios-dev instead of /usr/share/doc/libzipios-doc
> inside the libzipios-doc package.
> 
> I can't figure out why. Any help is welcome!

> For the moment the only solution I get is to override dh_installdocs.

I think that is actually intended: The documentation should be installed
to the libzios-dev folder. (Policy 12.3 suggests that, the paragraph
saying:

Additional documentation included in the package should be installed
under /usr/share/doc/package. If the documentation is packaged separately, as
package-doc for example, it may be installed under either that path or into the
documentation directory for the separate documentation package
(/usr/share/doc/package-doc in this example).

> > - There is also dh_doxygen.
> 
> Perfect tool! It removes md5 and map files, but it does not solve the
> issue above.
> 
> > - As per Policy 12.3, the -dev package should Suggest: the -doc
> > package.
> 
> Done
> 
> Thanks,
> François

(Sorry for the incomplete review, ran out of time)

--
tobi

Bug#971806: python-hdf5storage's autopkg tests fail in unstable

[Drew Parsons]

On 2020-10-13 00:36, Drew Parsons wrote:

For instance a recent amd64 error is

ERROR:
test_write_readback.TestPythonMatlabFormat.test_dtype_structured_with_offsets_titles
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in 
runTest

self.test(*self.arg)
  File
"/tmp/autopkgtest-lxc.58_whuw2/downtmp/autopkgtest_tmp/tests/test_write_readback.py",
line 862, in test_dtype_structured_with_offsets_titles
np.dtype(desc).itemsize + random.randint(1, 100)
ValueError: title already used as a name or title.



But the indicated code line "np.dtype(desc).itemsize +
random.randint(1, 100)" is just a random value for the field
desc_with_itemsize['itemsize']. What does it have to do with names?
Not clear why the indicated ValueError is triggered by this.




Evidently it's not about filename clashes then.  That ValueError is 
triggered by numpy,
e.g. 
https://github.com/numpy/numpy/blob/a72b89c7c2e30f5df5cf27f68b6afd45361934fd/numpy/core/src/multiarray/descriptor.c#L1234

Bug#971806: python-hdf5storage's autopkg tests fail in unstable

[Drew Parsons]

On 2020-10-12 14:23, Graham Inggs wrote:

On Mon, 12 Oct 2020 at 05:18, Drew Parsons  wrote:

Must have been a temporary package inconsistency?

All tests are passing now.


The autopkgtest looks flaky to me [1].  I see successes and failures
with the same triggers.




Looks like they might be generating random file names using random 
numbers without guaranteeing uniqueness. So with random.randint(1, 100) 
in play, there's a "1%" probability of name clash.


The exact problem is hard to pin down, i.e. the error message doesn't 
clearly match a filename clash.

For instance a recent amd64 error is

ERROR: 
test_write_readback.TestPythonMatlabFormat.test_dtype_structured_with_offsets_titles

--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in 
runTest

self.test(*self.arg)
  File 
"/tmp/autopkgtest-lxc.58_whuw2/downtmp/autopkgtest_tmp/tests/test_write_readback.py", 
line 862, in test_dtype_structured_with_offsets_titles

np.dtype(desc).itemsize + random.randint(1, 100)
ValueError: title already used as a name or title.



But the indicated code line "np.dtype(desc).itemsize + random.randint(1, 
100)" is just a random value for the field 
desc_with_itemsize['itemsize']. What does it have to do with names?  Not 
clear why the indicated ValueError is triggered by this.


Drew

Bug#972087: python3-gnocchi: gnocchi-api fails due to bad parameters to /usr/bin/uwsgi

[Russell Coker]

Package: python3-gnocchi
Version: 4.3.1-3
Severity: normal

# gnocchi-api
2020-10-12 12:17:56,769 [7662] INFO gnocchi.service: Gnocchi version 4.3.1
/usr/bin/uwsgi: option '--http' is ambiguous; possibilities: '--http-socket' 
'--http-socket-modifier1' '--http-socket-modifier2' '--http11-socket' 
'--https-socket' '--https-socket-modifier1' '--https-socket-modifier2'
getopt_long() error

Above is the result of running gnocchi-api at the command-line.  I realise that 
this might not be
the right way to run it, but I think it still shouldn't abort due to using 
parameters that don't
match the version of uwsgi in Debian.

It seems that instead of --http it should use --http-socket.  Also after that 
is fixed there's
the issue that it uses the --http-keepalive option which is not accepted by the 
uwsgi in Debian.

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages python3-gnocchi depends on:
ii  alembic 1.0.0-3
ii  python3 3.7.3-1
ii  python3-boto3   1.9.86-1
ii  python3-botocore1.12.103+repack-1
ii  python3-cachetools  3.1.0-2
ii  python3-cotyledon   1.6.8-3
ii  python3-daiquiri1.5.0-1
ii  python3-future  0.16.0-1
ii  python3-iso8601 0.1.11-1
ii  python3-jsonpatch   1.21-1
ii  python3-keystoneclient  1:3.17.0-2
ii  python3-keystonemiddleware  5.2.0-2
ii  python3-lz4 1.1.0+dfsg-1
ii  python3-monotonic   1.1-2
ii  python3-numpy   1:1.16.2-1
ii  python3-oslo.config 1:6.4.1-1
ii  python3-oslo.db 4.40.0-3
ii  python3-oslo.middleware 3.36.0-2
ii  python3-oslo.policy 1.38.1-2
ii  python3-oslosphinx  4.18.0-2
ii  python3-paste   3.0.6+dfsg-1
ii  python3-pastedeploy 2.0.1-1
ii  python3-pbr 4.2.0-5
ii  python3-pecan   1.3.2-2
ii  python3-pkg-resources   40.8.0-1
ii  python3-prettytable 0.7.2-4
ii  python3-protobuf3.6.1.3-2
ii  python3-psycopg22.7.7-1
ii  python3-pymysql 0.9.3-1
ii  python3-pyparsing   2.2.0+dfsg1-2
ii  python3-pytimeparse 1.1.5-2
ii  python3-redis   3.2.1-2
ii  python3-six 1.12.0-1
ii  python3-snappy  0.5.3-1
ii  python3-sqlalchemy  1.2.18+ds1-2
ii  python3-sqlalchemy-utils0.32.21-1
ii  python3-stevedore   1.29.0-2
ii  python3-swiftclient 1:3.6.0-2
ii  python3-tenacity4.12.0-2
ii  python3-tooz1.62.0-3
ii  python3-ujson   1.35-3
ii  python3-voluptuous  0.11.1-1
ii  python3-webob   1:1.8.5-1
ii  python3-werkzeug0.14.1+dfsg1-4+deb10u1
ii  python3-yaml3.13-2

python3-gnocchi recommends no packages.

Versions of packages python3-gnocchi suggests:
pn  gnocchi-doc  

-- no debconf information

Bug#971976: libtraceevent-dev: please build from git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git

[Ben Hutchings]

On Sat, 2020-10-10 at 23:25 +0100, Sudip Mukherjee wrote:
> Source: linux
> Severity: wishlist
> X-Debbugs-Cc: b...@decadent.org.uk, debian-ker...@lists.debian.org
> 
> Hi,
> 
> This is similar to #948041 and libtraceevent now lives in its own repo
> at git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git.
> 
> The upstream maintainer hopes that this will now be the source of all
> updates to the libtraceevent library that can be used as a stand alone
> package that both perf and tracecmd can use.
> 
> Link to the announcement mail at:
> https://lore.kernel.org/lkml/20201007130750.49349...@gandalf.local.home/
> 
> If the kernel team agrees I can raise a MR to remove the build of
> libtraceevent from the kernel source and can also make it a separate
> package and maintain it.

I have no objection to this.  Thanks for taking this on, Sudip.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus




signature.asc
Description: This is a digitally signed message part

Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible

[dany_wilde]

Package: pulseaudio
Version: 13.0-5
Followup-For: Bug #904652
X-Debbugs-Cc: compte.perso.de-al...@bbox.fr

the solution described here , doesn't work for me .

aplay -l
 Liste des Périphériques Matériels PLAYBACK 
carte 0: HDMI [HDA ATI HDMI], périphérique 3: HDMI 0 [HDMI 0]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA ATI HDMI], périphérique 7: HDMI 1 [HDMI 1]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA ATI HDMI], périphérique 8: HDMI 2 [HDMI 2]
  Sous-périphériques: 0/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA ATI HDMI], périphérique 9: HDMI 3 [HDMI 3]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA ATI HDMI], périphérique 10: HDMI 4 [HDMI 4]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 0: HDMI [HDA ATI HDMI], périphérique 11: HDMI 5 [HDMI 5]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: Generic [HD-Audio Generic], périphérique 0: ALC1220 Analog [ALC1220
Analog]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: Generic [HD-Audio Generic], périphérique 1: ALC1220 Digital [ALC1220
Digital]
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0

~$ pacmd list-cards
3 card(s) available.
index: 0
name: 
driver: 
owner module: 7
properties:
alsa.card = "2"
alsa.card_name = "HP Webcam HD 4310"
alsa.long_card_name = "Hewlett Packard HP Webcam HD 4310 at
usb-:0a:00.3-1, high speed"
alsa.driver_name = "snd_usb_audio"
device.bus_path = "pci-:0a:00.3-usb-0:1:1.2"
sysfs.path =
"/devices/pci:00/:00:08.1/:0a:00.3/usb5/5-1/5-1:1.2/sound/card2"
udev.id = "usb-Hewlett_Packard_HP_Webcam_HD_4310-02"
device.bus = "usb"
device.vendor.id = "03f0"
device.vendor.name = "HP, Inc"
device.product.id = "e807"
device.product.name = "HP Webcam HD 4310"
device.serial = "Hewlett_Packard_HP_Webcam_HD_4310"
device.form_factor = "webcam"
device.string = "2"
device.description = "HP Webcam HD 4310"
module-udev-detect.discovered = "1"
device.icon_name = "camera-web-usb"
profiles:
input:analog-stereo: Entrée Stéréo analogique (priority 65,
available: unknown)
input:iec958-stereo: Entrée Stéréo numérique (IEC958) (priority
55, available: unknown)
off: Éteint (priority 0, available: unknown)
active profile: 
ports:
analog-input-mic: Microphone (priority 8700, latency offset 0
usec, available: unknown)
properties:
device.icon_name = "audio-input-microphone"
iec958-stereo-input: Entrée numérique (S/PDIF) (priority 0,
latency offset 0 usec, available: unknown)
properties:

index: 1
name: 
driver: 
owner module: 8
properties:
alsa.card = "1"
alsa.card_name = "HD-Audio Generic"
alsa.long_card_name = "HD-Audio Generic at 0xfcd0 irq 101"
alsa.driver_name = "snd_hda_intel"
device.bus_path = "pci-:0a:00.4"
sysfs.path =
"/devices/pci:00/:00:08.1/:0a:00.4/sound/card1"
device.bus = "pci"
device.vendor.id = "1022"
device.vendor.name = "Advanced Micro Devices, Inc. [AMD]"
device.product.id = "1487"
device.product.name = "Starship/Matisse HD Audio Controller"
device.string = "1"
device.description = "Starship/Matisse HD Audio Controller"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card-pci"
profiles:
input:analog-stereo: Entrée Stéréo analogique (priority 65,
available: no)
output:analog-stereo: Sortie Stéréo analogique (priority 6500,
available: no)
output:analog-stereo+input:analog-stereo: Duplex stéréo
analogique (priority 6565, available: no)
output:analog-surround-21: Sortie Surround analogique 2.1
(priority 1300, available: no)
output:analog-surround-21+input:analog-stereo: Sortie Surround
analogique 2.1 + Entrée Stéréo analogique (priority 1365, available: no)
output:analog-surround-40: Sortie Surround analogique 4.0
(priority 1200, available: no)
output:analog-surround-41: Sortie Surround analogique 4.1
(priority 1300, available: no)
output:analog-surround-41+input:analog-stereo: Sortie Surround
analogique 4.1 + Entrée Stéréo analogique (priority 1365, available: no)

Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)

[Andreas Tille]

Control: reopen -a
Control: tags -1 help

On Mon, Oct 12, 2020 at 02:50:41PM +0500, Andrey Rahmatullin wrote:
> > while I've fixed the issue for arm64 the new version of bowtie seems to
> > have some new assembly code where mips64el, ppc64el and others are
> > stumbling upon [1]:
> The reason it works on arm64 is 
> 
> ifeq (aarch64,$(shell uname -m))
> POPCNT_CAPABILITY=0
> endif
> 
> in Makefile. It's clearly not supposed to run on anything else non-Intel
> but you can try patching this to also disable popcnt on other non-Intel.

My patch [1] worked for ppc64el and s390x.  However for arm64 (and others)
a new build error occures:

...
In file included from ebwt_build.cpp:8:
ds.h: In function ‘void mkeyQSortSuf2(const T&, size_t, TIndexOffU*, size_t, 
TIndexOffU*, int, size_t, size_t, size_t, size_t, EList*) 
[with T = S2bDnaString]’:
ds.h:497:3: warning: ‘tmp2’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]
  497 |   list_[cur_++] = el;
  |   ^
ds.h:497:3: warning: ‘tmp3’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]
  497 |   list_[cur_++] = el;
  |   ^
ds.h:497:3: warning: ‘tmp4’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]
  497 |   list_[cur_++] = el;
  |   ^
In file included from processor_support.h:17,
 from ebwt.h:41,
 from ebwt_build.cpp:10:
third_party/cpuid.h: In constructor ‘Ebwt::Ebwt(TStr, bool, int32_t, int32_t, 
int32_t, int32_t, int32_t, int, const string&, bool, bool, TIndexOffU, 
TIndexOffU, TIndexOffU, int, EList&, EList&, 
EList&, TIndexOffU, const RefReadInParams&, uint32_t, int32_t, 
int32_t, bool, bool, bool, bool) [with TStr = S2bDnaString]’:
third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
  103 |   __asm__ ("cpuid\n\t" \
  |   ^~~
third_party/cpuid.h:162:3: note: in expansion of macro ‘__cpuid’
  162 |   __cpuid (__ext, __eax, __ebx, __ecx, __edx);
  |   ^~~
third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
  103 |   __asm__ ("cpuid\n\t" \
  |   ^~~
third_party/cpuid.h:185:3: note: in expansion of macro ‘__cpuid’
  185 |   __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
  |   ^~~
In file included from ebwt_build.cpp:8:
...

Any idea how to deal with this?

Kind regards

   Andreas.


[1] 
https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch

-- 
http://fam-tille.de

Bug#972095: missing test-dependency

[Brian Murray]

Package: python-fakeredis
Version: 1.4.3-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

The package python-fakeredis is failing it's autopkgtests in Ubuntu as
can be seen here:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/p/python-fakeredis/20200907_120238_a7fd0@/log.gz

The failure is:

 ERRORS

_ ERROR at setup of test_time[FakeStrictRedis]
_
file /tmp/autopkgtest.czefjb/build.rUT/src/test/test_fakeredis.py, line
3361
  @fake_only
  def test_time(r, mocker):
E   fixture 'mocker' not found
>   available fixtures: cache, capfd, capfdbinary, caplog, capsys,
>   capsysbinary, cov, create_redis, doctest_namespace, fake_server,
>   is_redis_running, monkeypatch, no_cover, pytestconfig, r,
>   record_property, record_testsuite_property,
>   record_xml_attribute, recwarn, tmp_path, tmp_path_factory,
>   tmpdir, tmpdir_factory
>   use 'pytest --fixtures [testpath]' for help on them.

/tmp/autopkgtest.czefjb/build.rUT/src/test/test_fakeredis.py:3361

This is because while a dependency was added to debian/control for
python3-pytest-mock it was not added to debian/tests/control. Attached
is a debdiff which fixes the issue.

--
Brian Murray @ubuntu.com
diff -Nru python-fakeredis-1.4.3/debian/changelog 
python-fakeredis-1.4.3/debian/changelog
--- python-fakeredis-1.4.3/debian/changelog 2020-08-20 00:30:29.0 
-0700
+++ python-fakeredis-1.4.3/debian/changelog 2020-10-09 12:25:46.0 
-0700
@@ -1,3 +1,9 @@
+python-fakeredis (1.4.3-2) unstable; urgency=medium
+
+  * debian/tests/control: add python3-pytest-mock.
+
+ -- Brian Murray   Fri, 09 Oct 2020 12:25:46 -0700
+
 python-fakeredis (1.4.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-fakeredis-1.4.3/debian/tests/control 
python-fakeredis-1.4.3/debian/tests/control
--- python-fakeredis-1.4.3/debian/tests/control 2020-06-15 23:34:45.0 
-0700
+++ python-fakeredis-1.4.3/debian/tests/control 2020-10-09 12:25:44.0 
-0700
@@ -8,6 +8,7 @@
  python3-lupa,
  python3-pytest (>= 4.6.4), python3-pytest (<< 5.0),
  python3-pytest-cov (>= 2.7.1), python3-pytest-cov (<< 3.0),
+ python3-pytest-mock,
  python3-redis,
  python3-setuptools,
  python3-six,

Bug#966941: libpsl: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Lukasz Zemczak]

Hello!

Since we also saw the same FTBFS in Ubuntu, I have looked into it briefly today.
It seems that the test-is-public-builtin data needs to be updated for
the test to work as expected. This was fixed in libpsl 0.21.1 per this
commit:

https://github.com/rockdaboot/libpsl/commit/f364cea73e351ce62e0b337fd1fbc21e70b52d56

Cherry-picking the above commit (or simply pulling in 0.21.1) should
fix this error.

Cheers!

-- 
Łukasz 'sil2100' Zemczak
 Foundations Team
 lukasz.zemc...@canonical.com
 www.canonical.com

Bug#972087: python3-gnocchi: gnocchi-api fails due to bad parameters to /usr/bin/uwsgi

[Thomas Goirand]

On 10/12/20 2:22 PM, Russell Coker wrote:
> Package: python3-gnocchi
> Version: 4.3.1-3
> Severity: normal
> 
> # gnocchi-api
> 2020-10-12 12:17:56,769 [7662] INFO gnocchi.service: Gnocchi version 4.3.1
> /usr/bin/uwsgi: option '--http' is ambiguous; possibilities: '--http-socket' 
> '--http-socket-modifier1' '--http-socket-modifier2' '--http11-socket' 
> '--https-socket' '--https-socket-modifier1' '--https-socket-modifier2'
> getopt_long() error
> 
> Above is the result of running gnocchi-api at the command-line.  I realise 
> that this might not be
> the right way to run it, but I think it still shouldn't abort due to using 
> parameters that don't
> match the version of uwsgi in Debian.
> 
> It seems that instead of --http it should use --http-socket.  Also after that 
> is fixed there's
> the issue that it uses the --http-keepalive option which is not accepted by 
> the uwsgi in Debian.

Hi,

The gnocchi-api binary isn't meant to be started standalone, but it
should be used by uwsgi, as per what the startup scripts are doing. If
you do /etc/init.d/gnocchi-api show-args, it will show:

/usr/bin/uwsgi_python37 \
--https-socket
[::]:8041,/etc/gnocchi/ssl/public/HOSTNAME.crt,/etc/gnocchi/ssl/private/HOSTNAME.pem
\
--ini /etc/gnocchi/gnocchi-api-uwsgi.ini

(that is, if you've put some SSL files in /etc/gnocchi/ssl, otherwise it
wont use SSL).

Therefore, I wonder if this bug is still valid or not... Especially if
you consider that the service isn't even using the --http option (where
is this coming from then?).

Please let me know your thoughts,
Cheers,

Thomas Goirand (zigo)

Bug#834129: pgadmin4 adopter wanted

[Christoph Berg]

Hi,

the pgadmin4 developers have started distributing their own .deb and
.rpm packages [*] which makes me wonder if we should continue shipping
our own pgadmin4.deb packages. As a GUI application, it is naturally
hard to test, so bugs like

https://redmine.postgresql.org/issues/5692

are prone to happen. I'm not extensively using the package myself, so
I'd be glad if someone else took over maintenance of it.

Anyone interested? Otherwise I'd propose that we drop it.

Christoph

[*] They never contacted me about it, and I was pretty much
disappointed when I found out. My motivation to continue working on
the package is quite low.

https://www.pgadmin.org/download/pgadmin-4-apt/

Bug#971996: a way to solve this

[Russell Coker]

Using sqlite for the indexer might be an ideal way of doing it.  I made the 
following change to gnocchi.conf which made it progress to the next stage.

I used the password from the "connection =" line.

# diff -u /etc/gnocchi/gnocchi.conf.orig /etc/gnocchi/gnocchi.conf
--- /etc/gnocchi/gnocchi.conf.orig  2020-10-12 11:12:47.81600 +
+++ /etc/gnocchi/gnocchi.conf   2020-10-12 11:14:33.43600 +
@@ -409,7 +409,7 @@
 #
 
 # Indexer driver to use (string value)
-url = sqlite:var/lib/gnocchi/gnocchidb
+url = mysql+pymysql://gnocchi-common:A@localhost:3306/gnocchidb
 
 
 [keystone_authtoken]

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#972094: RFP: theoraplay -- library used by games to play Ogg Theora+Vorbis videos

[Emmanuel Gil Peyrot]

Package: wnpp
Severity: wishlist

* Package name: libtheoraplay
  Version : hg
  Upstream author : Ryan C. Gordon 
* URL : https://icculus.org/theoraplay/
* License : zlib
  Programming lang: C
  Description : library used by games to play Ogg Theora+Vorbis videos

This library is used in quite a few Linux games, it would be useful to
be able to use the system version, for instance for portability reasons,
see https://forge.dotslashplay.it/play.it/scripts/-/issues/254

Thanks,

-- 
Emmanuel Gil Peyrot


signature.asc
Description: PGP signature

Bug#970234: consider dropping "No hard links in source packages"

[Andrey Rahmatullin]

On Mon, Oct 12, 2020 at 05:05:43PM +0200, Giacomo Catenazzi wrote:
> > > Now we are more strict on where we can split filesystems
> > What do you mean?
> 
> If I remember correctly, now we do not support / and /usr to be on a
> different filesystems
Not really, please read
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#935536: Fwd: Compiling Linux with "bdver2" gcc optimization option

[Franco Martelli]

The Objtools maintainer told me to ignore the warnings unless live
patching it's used. This probably it means "Won't Fix" status to this
bug report, however if some kernel hacker will want to fix it I would be
so glad to see those warnings go away.


 Messaggio Inoltrato 
Oggetto: Re: Compiling Linux with "bdver2" gcc optimization option
Data: Thu, 8 Oct 2020 11:24:01 -0500
Mittente: Josh Poimboeuf 
A: Franco Martelli 
CC: pet...@infradead.org

On Thu, Oct 08, 2020 at 06:00:41PM +0200, Franco Martelli wrote:
> Hello dear Objtools Maintainers,
> 
> I got your email address by running the command:
> 
> ~/linux-source-5.8$ perl scripts/get_maintainer.pl -f
> tools/objtool/objtool.c
> 
> from long time I optimize Linux kernel builds using the "bdver2" GCC
> optimization option but sadly it doesn't work anymore. I don't know from
> which Linux kernel version up to now the bug appeared.
> I submitted this bug report [1] to the Debian BTS. I would ask if you
> could pay yours attention and fix it.
> Should I submit the bug report also to https://bugzilla.kernel.org ?
> 
> Thank you very much for yours patience, best regards.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935536

Hi Franco,

It will be difficult for objtool to support all the tuning options,
especially since they're so rarely used.  If you don't use live
patching, it's probably safe to ignore the warnings.

-- 
Josh

Bug#970234: consider dropping "No hard links in source packages"

[Giacomo Catenazzi]

On 12.10.2020 16:22, Andrey Rahmatullin wrote:

On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote:

Now we are more strict on where we can split filesystems

What do you mean?


If I remember correctly, now we do not support / and /usr to be on a 
different filesystems, and I think there were few other corner cases 
which were forbidden.


ciao
cate

Bug#970234: consider dropping "No hard links in source packages"

[Andrey Rahmatullin]

On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote:
> Now we are more strict on where we can split filesystems
What do you mean?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#972093: RFP: mojoshader -- library to work with Direct3D shaders on alternate 3D APIs and non-Windows platforms

[Emmanuel Gil Peyrot]

Package: wnpp
Severity: wishlist

* Package name: libmojoshader
  Version : hg
  Upstream author : Ryan C. Gordon 
* URL : https://icculus.org/mojoshader/
* License : zlib
  Programming lang: C
  Description : library to work with Direct3D shaders on alternate 3D APIs 
and non-Windows platforms

This library is used in quite a lot of Linux games, it would be useful
to be able to use the system version, for instance for portability
reasons, see https://forge.dotslashplay.it/play.it/scripts/-/issues/255

This is my first RFP, I hope I did everything correctly, otherwise
please tell me so I can improve in the future!

Thanks,

-- 
Emmanuel Gil Peyrot


signature.asc
Description: PGP signature

Bug#972083: ITP: python-jupyterlab-pygments -- Syntax coloring scheme for pygments using JupyterLab

[Julien Puydt]

Le lundi 12 octobre 2020 à 12:50 +, Gordon Ball a écrit :
> On Mon, Oct 12, 2020 at 01:46:40PM +0200, Julien Puydt wrote:
> > I'm wondering if the source package shouldn't be named jupyterlab-
> > pygments instead of python-jupyterlab-pygments: there will be quite
> > a number of jupyterlab-related packages, all in the Python team, so
> > the python- prefix might not really be needed. What does the team
> > think about it?
> 
> Seems pretty reasonable - most of the existing jupyter libraries have
> source packages named ^jupyter (-core, -client, -console, -notebook),
> so it's hardly unprecedented.

Yes.

> From this comment, are you planning to package jupyterlab itself? I
> looked at doing so in the past and found the JS part daunting, but
> maybe after 3.0 is a good time to look again.

JS isn't daunting, it's brain-dead. I'm going to package as much as I
can -- we can also call for help within the JS team...

Cheers,

JP

Bug#970234: consider dropping "No hard links in source packages"

[Giacomo Catenazzi]

On 13.09.2020 12:52, Helmut Grohne wrote:

Package: debian-policy
Version: 4.5.0.3
Severity: wishlist

Jakub stumbled into the "No hard links in source packages" requirement
added around 1996 and couldn't make sense of it. Neither could Christoph
nor myself. tar does support hard links just fine. lintian does not
check this property. sugar-log-activity/38 is an example package
violating the property. It is shipped in buster and technically
rc-buggy though no bug is filed about it.

I believe that the requriement needs a rationale. Failing that, it
should be dropped.



The rationale was probably similar so symlinks: they may fail across 
different filesystems, and we supported to have e.g. / /usr /usr/share 
/usr/local /var (and various /var/*) /home /tmp /boot etc on different 
file systems. Now we are more strict on where we can split filesystems 
(and disk are larger, and LVM simplified much of filesystem handling).


I think a hardlink on same directory should be fine, or within 
directories which must be on the same filesystem.


ciao
cate


[for symlinks we have the problem with relative links (containing "../") 
passing filesystem boundaries]

Bug#933151: mariadb-10.3: FTBFS on riscv64

[Otto Kekäläinen]

Hello!

Just to follow up on this topic, the riscv64 build on Debian has
worked perfectly since last upload. The builds and test suites have
never run this well ever before for MariaDB 10.5 on so many platforms:
https://buildd.debian.org/status/package.php?p=mariadb-10.5

Thanks Aurelien!

PS. Please Aurelien submit your patches upstream as well.

Bug#972091: openssh-client: ssh -o KbdInteractiveAuthentication=no gets ignored

[Drexl Johannes]

Package: openssh-client
Version: 1:7.9p1-10+deb10u2
Severity: normal

Dear Maintainer,

connecting to a server disabling keyboard-interactive authentication
does not actually disable it; -vvv shows:

debug1: Authentications that can continue: publickey,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred:
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

This should not happen. Guess there's just a minor logic error
somewhere.

-- System Information:
Debian Release: 10.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-11-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.28-10
ii  libedit2  3.1-20181209-1
ii  libgssapi-krb5-2  1.17-3
ii  libselinux1   2.8-1+b1
ii  libssl1.1 1.1.1d-0+deb10u3
ii  passwd1:4.5-1.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- no debconf information

Bug#969622: gnome-shell-extension-log-out-button: fails to load: TypeError: System._createActionButton is not a function

[Paul Wise]

On Mon, 2020-10-12 at 15:35 +0200, Kyle Robbertze wrote:

> I'm going to consider requesting the removal of this package from
> unstable in the next while unless there is any other opinions.

That seems reasonable.

Personally I wanted an extension to move the "Power Off / Log Out" menu
items to the main menu, any idea if such an extension exists?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#969622: gnome-shell-extension-log-out-button: fails to load: TypeError: System._createActionButton is not a function

[Kyle Robbertze]

It seems that the extension isn't actually useful in GNOME 3.36 -
gnome-shell includes a log out button in the list of Power Off/Log Out
options and has removed the icons completely.

I'm going to consider requesting the removal of this package from
unstable in the next while unless there is any other opinions.

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#972089: Backport hplip 3.20.5 to buster-backports

[Alex ARNAUD]

I just re-generated the two patches with the option "-u" to diff to make 
them more readable.


Le 12/10/2020 à 15:10, Alex ARNAUD a écrit :

Package: hplip
Severity: wishlist patch
Tags: ||buster||

Hello,

Why I'd like this to be backported to buster-backports ?
My new printer, an HP 2700 series is only compatible with HP Lip 
3.20.5+. This is based on my own tests where only half of printed 
pages are printed. This is also based on the upstream table 
 
where it is indicated the "HP DeskJet 2700 All-in-One Printer series" 
is compatible with 3.20.5.


What did I already do to figure this out?
With the help of Samuel Thibault, I was able to recompile HP Lip 
3.20.5 on a Buster virtual machine and I produced two patch for it. 
The patches are attached to this mail. One is to update the 
debian/patches/series file and the second one is to refresh the patch 
0072 (just a quilt refresh on it). I initially would like to propose a 
pull request on Salsa but there is no branch to submit the changes.


What my patch does?
It reverts all the python3.8 specific patches because Debian Buster is 
based on Python 3.7 and because python3.7 library is named 
"python3.7m", not only python3.7.


What I think HP Lip should be backported to buster-backports?
I think it'd be really helpful for people would like to stay on stable 
with new HP printers which require new HP Lip to have a new version in 
backports.


How do I check if it works?
1. I upgraded the compiled packages with the following command:

sudo dpkg -iO .../*.deb


2) I rebooted my virtual machine to ensure the new HP Lip version is 
loaded


3) I configured my HP Desktop 3630 printer (launched with 
system-config-printer)


4) I tried a print test job launched with system-config-printer

5) I tried a scan with simple-scan

Result:
Everything seems to work correctly.

Thanks in advance,
Alex.



--- ../hplip-3.20.5+dfsg0.orig/debian/patches/series	2020-10-12 14:43:13.346892324 +0200
+++ debian/patches/series	2020-10-12 14:47:20.678512933 +0200
@@ -68,7 +68,4 @@
 0068-abrt-hplip-strlen-hp-killed-by-SIGSEGV.patch
 0069-abrt-hp-systray-BlockingIOError-Errno-11-Resource-te.patch
 0070-Missing-drivers.patch
-0071-Fix-building-with-Python-3.8.patch
 0072-Fix-upstream-CFLAGS-override.patch
-0073-py3.8-Fix-SyntaxWarning-is-is-not-with-a-literal.patch
-0074-py3.8-Assume-the-python3-distro-package-is-available.patch
--- ../hplip-3.20.5+dfsg0.orig/debian/patches/0072-Fix-upstream-CFLAGS-override.patch	2020-10-12 14:43:13.346892324 +0200
+++ debian/patches/0072-Fix-upstream-CFLAGS-override.patch	2020-10-12 14:44:03.893473185 +0200
@@ -10,11 +10,11 @@
  configure.in | 36 +++-
  1 file changed, 23 insertions(+), 13 deletions(-)
 
-diff --git a/configure.in b/configure.in
-index 7f6982c..ced1f47 100755
 a/configure.in
-+++ b/configure.in
-@@ -604,20 +604,31 @@ if test "$class_driver" = "no" && test "$hpijs_only_build" = "no" && test "$hpcu
+Index: hplip-3.20.5+dfsg0/configure.in
+===
+--- hplip-3.20.5+dfsg0.orig/configure.in
 hplip-3.20.5+dfsg0/configure.in
+@@ -604,20 +604,31 @@ if test "$class_driver" = "no" && test "
 fi
  fi
  
@@ -58,9 +58,9 @@
  if test "$class_driver" = "no" && test "$hpijs_only_build" = "no" && test "$lite_build" = "no" && test "$hpcups_only_build" = "no"; then
 AC_ARG_VAR([PYTHON], [Python interpreter/compiler command])
 AM_PATH_PYTHON([2.2])
-@@ -633,7 +644,6 @@ if test "$class_driver" = "no" && test "$hpijs_only_build" = "no" && test "$lite
+@@ -630,7 +641,6 @@ if test "$class_driver" = "no" && test "
+AS_IF([test "x$FOUND_HEADER" != "xyes"],
[AC_MSG_ERROR([cannot find python-devel support], 6)])
-CPPFLAGS=$save_CPPFLAGS
  fi
 -CFLAGS="$save_CFLAGS"
  

Bug#972090: RFS: opendkim/2.11.0~beta2-4 -- DomainKeys Identified Mail (DKIM) signing and verifying milter

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "opendkim":

 * Package name: opendkim
   Version : 2.11.0~beta2-4
   Upstream Author : The Trusted Domain Project
 * URL : http://www.opendkim.org/
 * License : BSD-3-clause and SOSL, ISC, GPL-3+ with AutoConf exception
 * Vcs : https://salsa.debian.org/debian/opendkim
   Section : mail

It builds those binary packages:

  opendkim - DomainKeys Identified Mail (DKIM) signing and verifying milter
  opendkim-tools - utilities for administering the OpenDKIM milter
  libopendkim11 - DomainKeys Identified Mail (DKIM) library
  libopendkim-dev - DomainKeys Identified Mail (DKIM) library (development 
files)
  libvbr2 - Vouch By Reference (VBR) library
  libvbr-dev - Vouch By Reference (VBR) library (development files)
  librbl1 - Real-time Blacklist (RBL) query library
  librbl-dev - Real-time Blacklist (RBL) query library (development files)
  miltertest - utility for testing milter applications

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/opendkim/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opendkim/opendkim_2.11.0~beta2-4.dsc

Changes since the last upload:

 opendkim (2.11.0~beta2-4) unstable; urgency=medium
 .
   * Update debhelper-compat to compatibility level 13.
 - Rename d/opendkim.tmpfile for new dh_installtmpfiles convention.
   * opendkim-tools: Reference "OpenDKIM" in synopsis.
   * miltertest: Drop patch moving the man page (rejected upstream).
   * Add missing DEP-3 headers tracking upstream bug in d/patches.

Cheers,
David

Bug#972080: routine-update: Sometimes deletes manually added python3 dependency

[Andreas Tille]

Control: reassign -1 dh-r
Control: merge -1 961492

Bug#972089: Backport hplip 3.20.5 to buster-backports

[Alex ARNAUD]

Package: hplip
Severity: wishlist patch
Tags: ||buster||

Hello,

Why I'd like this to be backported to buster-backports ?
My new printer, an HP 2700 series is only compatible with HP Lip 
3.20.5+. This is based on my own tests where only half of printed pages 
are printed. This is also based on the upstream table 
 
where it is indicated the "HP DeskJet 2700 All-in-One Printer series" is 
compatible with 3.20.5.


What did I already do to figure this out?
With the help of Samuel Thibault, I was able to recompile HP Lip 3.20.5 
on a Buster virtual machine and I produced two patch for it. The patches 
are attached to this mail. One is to update the debian/patches/series 
file and the second one is to refresh the patch 0072 (just a quilt 
refresh on it). I initially would like to propose a pull request on 
Salsa but there is no branch to submit the changes.


What my patch does?
It reverts all the python3.8 specific patches because Debian Buster is 
based on Python 3.7 and because python3.7 library is named "python3.7m", 
not only python3.7.


What I think HP Lip should be backported to buster-backports?
I think it'd be really helpful for people would like to stay on stable 
with new HP printers which require new HP Lip to have a new version in 
backports.


How do I check if it works?
1. I upgraded the compiled packages with the following command:

sudo dpkg -iO .../*.deb


2) I rebooted my virtual machine to ensure the new HP Lip version is loaded

3) I configured my HP Desktop 3630 printer (launched with 
system-config-printer)


4) I tried a print test job launched with system-config-printer

5) I tried a scan with simple-scan

Result:
Everything seems to work correctly.

Thanks in advance,
Alex.

71d70
< 0071-Fix-building-with-Python-3.8.patch
73,74d71
< 0073-py3.8-Fix-SyntaxWarning-is-is-not-with-a-literal.patch
< 0074-py3.8-Assume-the-python3-distro-package-is-available.patch
13,17c13,17
< diff --git a/configure.in b/configure.in
< index 7f6982c..ced1f47 100755
< --- a/configure.in
< +++ b/configure.in
< @@ -604,20 +604,31 @@ if test "$class_driver" = "no" && test "$hpijs_only_build" = "no" && test "$hpcu
---
> Index: hplip-3.20.5+dfsg0/configure.in
> ===
> --- hplip-3.20.5+dfsg0.orig/configure.in
> +++ hplip-3.20.5+dfsg0/configure.in
> @@ -604,20 +604,31 @@ if test "$class_driver" = "no" && test "
61c61,62
< @@ -633,7 +644,6 @@ if test "$class_driver" = "no" && test "$hpijs_only_build" = "no" && test "$lite
---
> @@ -630,7 +641,6 @@ if test "$class_driver" = "no" && test "
> AS_IF([test "x$FOUND_HEADER" != "xyes"],
63d63
< CPPFLAGS=$save_CPPFLAGS