Bug#949694: tasksel: Please drop all kde-l10n packages

[Holger Wansing]

Hi,

Wolfgang Schweer  wrote:
> Package: tasksel
> Version: 3.58
> Severity: normal
> 
> Hi,
> 
> all kde-l10n packages are no longer available. They have been removed 
> from unstable and testing some time ago, see: 
> https://tracker.debian.org/pkg/kde-l10n
> 
> See also the related bug: 
> https://bugs.debian.org/935665 
> 
> (As far as I can tell, translations are now contained in the 
> libkf5i18n-data package, which is installed as a kde dependency.)

Hmm, libkf5i18n-data was already existing in buster, and it has nearly the
same filesize in sid compared to buster, so it seems that it does not contain
additional translations which have been dropped from kde-l10n-*

kde-l10n-* packages contain masses of .mo files, which I cannot find
anymore in unstable. Where have all those translations gone?

CC'ing kde people for advise.


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#953965: how-can-i-help: option to hide specific issues for specific packages

[Paul Wise]

Package: how-can-i-help
Version: 16
Severity: wishlist

At $work we are automatically monitoring how-can-i-help output but we
sometimes come across the issue that a package like postgresql-11 has
been removed from testing because it was replaced by postgresql-12. It
would be nice to have an option to hide removals from testing (or other
issues) for specific packages, so we can ignore issues that we know are
not a problem.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#953538: run tests as autopkg test

[Marco d'Itri]

On Mar 10, Matthias Klose  wrote:

> run tests as autopkg test. I didn't investigate yet, why the one test fails
> using this approach.
Because it tests a feature which is not enabled in Debian builds: maybe 
your script should be modified to ignore all tests which return errno=77 
(unsupported)?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#953964: ITP: python-strictyaml -- Strict, typed YAML parser for Python

[James Tocknell]

Package: wnpp
Severity: wishlist
Owner: James Tocknell 

* Package name: python-strictyaml
  Version : 1.0.6
  Upstream Author : Colm O'Connor 
* URL : https://hitchdev.com/strictyaml/
* License : MIT
  Programming Lang: Python
  Description : Strict, typed YAML parser for Python

StrictYAML is a type-safe YAML parser that parses and validates a restricted
subset of the YAML specification.

Priorities:
 - Beautiful API
 - Refusing to parse the ugly, hard to read and insecure features of YAML like
   the Norway problem.
 - Strict validation of markup and straightforward type casting.
 - Clear, readable exceptions with code snippets and line numbers.
 - Acting as a near-drop in replacement for pyyaml, ruamel.yaml or poyo.
 - Ability to read in YAML, make changes and write it out again with comments
   preserved.
 - Not speed, currently.

---

This is needed for devpi-server, and I plan on maintaining within DMPT (assuming
they accept me).

Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc

[Sandro Tosi]

> And maybe we'll be ready to remove the python2 bindings before then
> anyway (there weren't very many rdeps left last time I looked).

i'm afraid that wont happen that easily: python-xapian is keep in
transitively by python-moinmoin (which we use for wiki.d.o) and its
port to python3 is no where near being completed :(

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc

[Olly Betts]

On Sat, Mar 14, 2020 at 05:35:14PM -0400, Sandro Tosi wrote:
> This will help us in reducing the reverse dependencies of
> bin:python-sphinx, so that we can introduce a python3-only sphinx
> version in unstable.

Having pondered, I'd suggest we just leave xapian-bindings as-is
until you're at the point of dropping python2 support from sphinx and
then I'll drop the sphinx-generated docs for the python2 bindings
from the Debian package entirely.  If anyone still wants to look at them
they are at least available online.

And maybe we'll be ready to remove the python2 bindings before then
anyway (there weren't very many rdeps left last time I looked).

Cheers,
 Olly

Bug#953926: e2fsprogs: Build-Depends on unused libattr1-dev

[Theodore Y. Ts'o]

tags 953926 +pending
thanks

On Sat, Mar 14, 2020 at 07:46:18PM +0100, Guillem Jover wrote:
> 
> This package used to use libattr for its xattr support, but got
> switched to use the native support from glibc, but the Build-Depends
> got left behind.

Thanks for the report.  The following will be in the next release of
e2fsprogs.

- Ted

commit b3f9df9f1ba5ded7031566c94a7a9dfdcbd38aa6
Author: Theodore Ts'o 
Date:   Sun Mar 15 00:56:01 2020 -0400

debian: drop libattr1-dev from the build dependencies list

The libattr has stopped providing attr/xattr.h; we now use
sys/xattr.h.  So there is no longer any reason to require that the
libattr1-dev package be present when building e2fsprogs, so drop it.

Addresses-Debian-Bug: #953926
Signed-off-by: Theodore Ts'o 

diff --git a/debian/control b/debian/control
index 71613e11..69471f45 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: e2fsprogs
 Section: admin
 Priority: required
 Maintainer: Theodore Y. Ts'o 
-Build-Depends: gettext, texinfo, pkg-config, libfuse-dev [linux-any 
kfreebsd-any] , libattr1-dev, debhelper (>= 12.0), 
dh-exec, libblkid-dev, uuid-dev, m4, udev [linux-any], systemd [linux-any], 
cron [linux-any]
+Build-Depends: gettext, texinfo, pkg-config, libfuse-dev [linux-any 
kfreebsd-any] , debhelper (>= 12.0), dh-exec, 
libblkid-dev, uuid-dev, m4, udev [linux-any], systemd [linux-any], cron 
[linux-any]
 Standards-Version: 4.4.1
 Homepage: http://e2fsprogs.sourceforge.net
 Vcs-Browser: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

Bug#953872: ITP: fonts-jf-openhuninn -- Chinese (Taiwan) font based on Kosugi Maru

[Yao Wei]

On Sun, Mar 15, 2020 at 08:27:29AM +0800, Yao Wei wrote:
> On Sat, Mar 14, 2020 at 06:56:49PM +0800, Yao Wei wrote:
> > * License : OFL-1.1, without Reserved Font Names
> 
> The license should come with Reserved Font Names "Varela" and "Varela
> Round" since the latin part of the fonts are replaced with it.

And the author was mistaken that they think they added RFN, but they
didn't use OFL's "With Reserved Font Names" texts in the copyright
claim.

The future version will have RFN on it.


signature.asc
Description: PGP signature

Bug#953857: lintian: t/tags/odd-inputs/strings-elf-detection/eval/literal fails on ubuntu

[Dimitri John Ledkov]

There is a typpo!

Changing all patterns I could find did *not* make the test pass. Thus I
don't have a patch that makes this work.

I could not find/trace how/where/why .changes is parsed and things are
decided to be executed.

Also I am confused about types of things used. I.e. I see that "binary,
udeb" are often used, where sometimes binary means like anything a binary
build produces, yet sometimes udebs are special cases. Did not see explicit
"deb" upload types. Thus tried things like calling "ddebs" to be "binary"
or "deb" and it didn't work either.

I am confused in reading Perl & understanding the data model here 😔 thus
went with removing assertions, as I'd rather have newer lintian in ubuntu,
even if it doesn't parse .ddebs on Ubuntu.

On Sat, 14 Mar 2020, 21:16 Chris Lamb,  wrote:

> Hi Dimitri,
>
> > I've tried to find a few places where Package-Type is used, and regexp
> > hardcodes .deb pattern, but tweaking all of those to dd?eb did make
> > the test case pass.
>
> Can you provide a patch of these changes? I note your other patch in a
> later mail that removes the assertions from the testsuite but this
> would always be a Ubuntu-specific change and having a minimal delta
> between the two projects would always be prefered.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
>`-
>

Bug#953963: firefox: treestyletab sidebar page no longer loaded after upgrading to firefox 74

[Yuya Nishihara]

Package: firefox
Version: 74.0-1
Severity: normal

Hi,

After upgrading to firefox 74, the sidebar of webext-treestyletab is no
loger loaded. It only shows the progress bar indicating that treestyletab
is still loading.

With clean profile (i.e. rm -R ~/.mozilla ~/.cache/mozilla), no system-wide
extension appears to be loaded. With existing profile, the other extensions
(such as webext-ublock-origin) seems working.

The problem went away if I downgraded to firefox 73.0.1-1+b1, restored
~/.mozilla from backup, and rm -R ~/.cache/mozilla.

Regards,
Yuya

-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Default theme
Location: /usr/lib/firefox/omni.ja
Package: firefox
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: HTTPS Everywhere
Location: /usr/share/webext/https-everywhere
Package: webext-https-everywhere
Status: enabled

Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Privacy Badger
Location: /usr/share/webext/privacy-badger
Package: webext-privacy-badger
Status: enabled

Name: Tree Style Tab
Location: /usr/share/webext/tree-style-tab
Package: webext-treestyletab
Status: enabled

Name: Twitter
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: uBlock Origin
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net
Package: webext-ublock-origin
Status: enabled

Name: Web Compat
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox 74.0-1amd64Mozilla Firefox web 
browser
ii  webext-https-everywhere 2019.11.7-1   all  Extension to force the 
use of HTTPS on many sites
ii  webext-privacy-badger   2020.2.19-1   all  Privacy Badger 
automatically learns to block invisible trackers
ii  webext-treestyletab 3.1.7-1   all  Show browser tabs like a 
tree
ii  webext-ublock-origin1.22.2+dfsg-1 all  general-purpose 
lightweight ads, malware, trackers blocker (Web Extension)

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

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

Versions of packages firefox depends on:
ii  debianutils 4.9.1
ii  fontconfig  2.13.1-2+b1
ii  libatk1.0-0 2.34.1-1
ii  libc6   2.30-2
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.16-2
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.11-stable-1
ii  libffi7 3.3-3
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.10.1-2
ii  libgcc-s1   10-20200312-2
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-3
ii  libglib2.0-02.64.0-2
ii  libgtk-3-0  3.24.14-1
ii  libnspr42:4.25-1
ii  libnss3 2:3.50-1
ii  libpango-1.0-0  1.42.4-8
ii  libsqlite3-03.31.1-4
ii  libstdc++6  10-20200312-2
ii  libx11-62:1.6.9-2
ii  libx11-xcb1 2:1.6.9-2
ii  libxcb-shm0 1.13.1-5
ii  libxcb1 1.13.1-5
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.5-1
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-1
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.1.5-1+b3
ii  procps  2:3.3.16-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec58  7:4.2.2-1+b1

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-6
pn  fonts-stix | otf-stix  
ii  libcanberra0 

Bug#779006: Request to join DPMT and PAPT to package devpi

[James Tocknell]

Hi Python Team

Can I join both the DPMT and PAPT to help maintain devpi (and its
associated subprojects)?
I've read both the DPMT and PAPT policies and accept them.
My salsa login is aragilar-guest.

My plan for devpi is to update devpi-common to the latest release, then
work down the list of devpi projects.
I plan on putting the projects under PAPT (apart from devpi-common), unless
there are other suggestions?

James

P.S. I've CC'd in the current ITP bugs for devpi, there will probably be
more as I package further projects.

Bug#935173: audacity graphical windows fail to update properly

[Anthony DeRobertis]

On 3/13/20 1:16 AM, Daniel Kahn Gillmor wrote:

Control: retitle 935173 audacity graphical windows fail to update properly when 
GTK_IM_MODULE=xim
Control: forwarded 935173 
https://developer.gnome.org/gtk3/stable/gtk-running.html


Err, are you sure that's the right URL? I tried to find the forwarded 
bug at both https://bugzilla.audacityteam.org/ and 
https://gitlab.gnome.org/GNOME/gtk/issues/ but I couldn't find it on 
either. So alas I can't just fix the URL myself.

Bug#924516: Not fixed

[w4t-w4t]

Package: geoclue-2.0
Version: 2.5.2-1
Followup-For: Bug #924516

Dear Maintainer,

This is not fixed. Upstream said it was intentional to not be able to disable 
location sharing. This is problematic. There needs to be a way to ensure ones 
privacy (not relying on the workaround).

Excuse me; maybe this is not the place to continue this discussion, but I don't 
know which is.

Any help would be appreciated.

TX

Bug#953875: new maintainer

[Adam Borowski]

Just so there's a public record: I've sponsored the version of runit that
was rotting on mentors as-is; it included a bunch of fixes and transfer of
maintainership to Lorenzo.

This means, we now have a proper maintainer.


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#924516: Not fixed

[w4t-w4t]

Dear Maintainer,

This is not fixed. Upstream said it was intentional to not be able to disable 
location sharing. This is problematic. There needs to be a way to ensure ones 
privacy (not relying on the workaround).

Excuse me; maybe this is not the place to continue this discussion, but I don't 
know which is.

Any help would be appreciated.

TX

Bug#953962: upgrade-reports: kprop uses a new default kerberos filename for propogating to replica kdcs

[Diane Trout]

Package: upgrade-reports
Severity: normal

After upgrading from stretch to buster on a kerberos domain controler that I
had configured a replication script.

/etc/cron.hourly/krb5-prop:
/usr/sbin/kprop: No such file or directory while trying to open
/var/lib/krb5kdc/replica_datatrans
Propagation of database to host 
failed with exit code 1.


The script I was using that was installed into /etc/cron.hourly looked like the
following:

#+BEGIN_SRC bash
#!/bin/sh

# Distribute KDC database to slave servers
# Created by Jason Garman for use with MIT Kerberos 5
# Modified by Jaap Winius 

slavekdcs=

/usr/sbin/kdb5_util dump /var/lib/krb5kdc/slave_datatrans
error=$?

if [ $error -ne 0 ]; then

echo "Kerberos database dump failed"
echo "with exit code $error. Exciting."
exit 1
fi

for kdc in $slavekdcs; do

/usr/sbin/kprop $kdc > /dev/null
error=$?

if [ $error -ne 0 ]; then

echo "Propagation of database to host $kdc"
echo "failed with exit code $error."
fi
done

exit 0
#+END_SRC


I patched it with this:

#+BEGIN_SRC diff
--- krb5-prop.orig  2020-03-14 21:05:08.429907209 -0700
+++ krb5-prop.new   2020-03-14 21:05:35.946011884 -0700
@@ -5,7 +5,7 @@
 # Modified by Jaap Winius 

-slavekdcs=
+replicakdcs=

-/usr/sbin/kdb5_util dump /var/lib/krb5kdc/slave_datatrans
+/usr/sbin/kdb5_util dump /var/lib/krb5kdc/replica_datatrans
 error=$?

@@ -17,5 +17,5 @@
 fi

-for kdc in $slavekdcs; do
+for kdc in $replicakdcs; do

/usr/sbin/kprop $kdc > /dev/null
#+ENC_SRC

It might be nice to mention that kprop's default replica file name changed
between stretch and buster.

Diane



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

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

Bug#938547: sphinx-testing: diff for NMU version 0.8.1-1.2

[Sandro Tosi]

Dear maintainer,

I've prepared an NMU for sphinx-testing (versioned as 0.8.1-1.2). The diff
is attached to this message.

please consider maintaining this package under DPMT umbrella

Regards.

diff -Nru sphinx-testing-0.8.1/debian/changelog sphinx-testing-0.8.1/debian/changelog
--- sphinx-testing-0.8.1/debian/changelog	2019-10-13 00:07:12.0 -0400
+++ sphinx-testing-0.8.1/debian/changelog	2020-03-14 23:55:05.0 -0400
@@ -1,3 +1,10 @@
+sphinx-testing (0.8.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Further drop remaining python2 packages; Closes: #938547
+
+ -- Sandro Tosi   Sat, 14 Mar 2020 23:55:05 -0400
+
 sphinx-testing (0.8.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sphinx-testing-0.8.1/debian/tests/control sphinx-testing-0.8.1/debian/tests/control
--- sphinx-testing-0.8.1/debian/tests/control	2019-01-04 19:04:36.0 -0500
+++ sphinx-testing-0.8.1/debian/tests/control	2020-03-14 23:54:59.0 -0400
@@ -1,8 +1,3 @@
-Tests: python-sphinx-testing
-Depends: python-sphinx,
- python-six,
- python-nose
-
 Tests: python3-sphinx-testing
 Depends: python3-sphinx,
  python3-six,
diff -Nru sphinx-testing-0.8.1/debian/tests/python-sphinx-testing sphinx-testing-0.8.1/debian/tests/python-sphinx-testing
--- sphinx-testing-0.8.1/debian/tests/python-sphinx-testing	2019-01-04 19:04:36.0 -0500
+++ sphinx-testing-0.8.1/debian/tests/python-sphinx-testing	1969-12-31 19:00:00.0 -0500
@@ -1,8 +0,0 @@
-#!/bin/sh
-set -e -u
-cp -r tests "$AUTOPKGTEST_TMP/"
-cd "$AUTOPKGTEST_TMP"
-pyversions -i \
-| tr ' ' '\n' \
-| xargs -I {} env PYTHONWARNINGS=d PYTHONHASHSEED=random {} \
-  -m nosetests -vv 2>&1

Bug#947295: cyrus-imapd: Python2 removal in sid/bullseye

[Sandro Tosi]

Hey folks,

> (source:cyrus-imapd)Testsuite-Triggers->python-docutils
> (source:cyrus-imapd)Testsuite-Triggers->python-pygments
> (source:cyrus-imapd)Testsuite-Triggers->python-sphinx

I dont really understand this: why the autopkgtests have sphinx (and
its related packages) in the control file, while the main source
package doesnt build-depend on it? from the build log we can even see:

checking for sphinx-build... no
configure: WARNING: No sphinx-build, won't be able to regenerate docs

so maybe the autopkgtests dependencies could be adjusted to remove
python-sphinx (and the other packages)? this will help reduce the
number of reverse dependencies for python-sphinx and help possibly
dropping that package.

Regards,
Sandro

Bug#953952: kmod: libkmod2-udeb contains binary instead of libraries

[Marco d'Itri]

On Mar 14, Aurelien Jarno  wrote:

> The binaries should probably be moved to a different package like
> kmod-udeb, as they conflict with busybox-udeb. Right now the kmod ones
> are used, but it depends on the unpack order.
Good to know after 8 years! Should I bother at all building a kmod-udeb 
if it is not actually used?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#953961: a workaround

[Konstantinos Draziotis]

Dear maintainer

adding to my previous email, I solved the problem by following the steps.
1. Application-->settings-->keyboard-->Layout-->ctrl+alt [or something]
2. Application-->settings-->Ibus preferences and untick *show icon in
systems tray*
3. Right click on system tray Panel-->add new items-->keyboard settings
4. Reboot

It seems that Ibus has a bug.

Costas

Bug#923387: [Pkg-utopia-maintainers] Bug#923387: udisks2: Please support new logind virtual packages

[nito]

On Sat, 1 Feb 2020 21:29:05 +0100 Michael Biebl  wrote:> Am 
31.01.20 um 05:40 schrieb Benda Xu:
 > The seat detection is acquired via libsystemd, not the D-Bus interface
> afaics. The virtual package logind only provides guarantees regarding
> the D-Bus interface. From
> /usr/share/doc/debian-policy/virtual-package-names-list.yaml.gz
> 
>  - name: logind
>description: an org.freedesktop.login1 D-Bus API implementation
> (versioned)
> 
> Can you provide more information if the C-API of logind is fully
> implemented in elogind? Should debian-policy be updated then?
> 
> That is my concern number one.
> 
> Second, I don't think the logind virtual package gives any guarantees
> regarding the systemd inhibit API.
> 
> How does elogind enforce an inhibition lock? Say udisks currently
> executed a destructive operation operation. How does it prevent
> (accidental) shutdowns in this case, which would render your system broken?

I was led to this bug when trying to replace systemd with the MATE-DE, which 
currently has indirect systemd dependencies via policykit-1 and usdisks2. 
(similar #909192)

As far as I can tell, looking at elogind release notes and documentation,
elogind does implement inhibition locks and is fully ABI compatible to 
libsystemd though a few functionalities (not inhibitors) are only provided as
dummys or redirected to something else.
See: https://github.com/elogind/elogind/releases/tag/v241.1
But by glancing over elogind's docs and elogind/src/login/logind-inhibtit.c
it seems as if inhibitors are properly (as in: not just a dummy) implemented.

Also udisks 2.6.5 upstream release notes mention it now supports elogind
See: https://github.com/storaged-project/udisks/blob/master/NEWS

Regards,
Nils

Bug#933129: apache2: OCSP stapling poorly handled, yielding trylater errors in the client

[Vincent Lefevre]

I eventually had to disable OCSP stapling on my server: errors occur
too frequently, even just after restarting apache.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#953961: ibus: fails to change languages

[K.D.]

Package: ibus
Version: 1.5.19-4+deb10u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Maybe an update.
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   When $sudo udevadm trigger --subsystem-match=input --action=change 
   was executed, I can use ctrl+alt to change the language.
   If I do not execute the previous I have to manually change the language 
   [i.e. by clicking to the language icon in the systems tray]

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
default-display-manager: /usr/sbin/lightdm
ibus is /usr/bin/ibus
ibus-setup is /usr/bin/ibus-setup
im-config -l =>  ibus xim
im-config -m => 'default' 'missing' 'ibus' '' 'ibus'
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
LANG=LANG$
LANGUAGE=en_US:en
== locale ==

XMODIFIERS=@im=ibus
GTK_IM_MODULE=ibus
QT4_IM_MODULE=ibus
QT_IM_MODULE=ibus
WAYLAND_DISPLAY=
XDG_CURRENT_DESKTOP=XFCE
XDG_MENU_PREFIX=xfce-
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=xfce
XDG_SESSION_ID=3
XDG_SESSION_TYPE=x11

== ls -l /usr/lib/ibus/ ==
total 804
-rwxr-xr-x 1 root root  22752 Sep 11  2019 ibus-dconf
-rwxr-xr-x 1 root root  14560 Sep 11  2019 ibus-engine-simple
-rwxr-xr-x 1 root root 157920 Sep 11  2019 ibus-extension-gtk3
-rwxr-xr-x 1 root root  88288 Sep 11  2019 ibus-portal
-rwxr-xr-x 1 root root 116968 Sep 11  2019 ibus-ui-emojier
-rwxr-xr-x 1 root root 309536 Sep 11  2019 ibus-ui-gtk3
-rwxr-xr-x 1 root root 100192 Sep 11  2019 ibus-x11

== dpkg-query -l 'ibus*' ==
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture Description
+++-==-===--===
ii  ibus   1.5.19-4+deb10u1amd64Intelligent 
Input Bus - core
un  ibus-anthy  (no 
description available)
ii  ibus-clutter:amd64 0.0+git20090728.a936bacf-5.1+b2 amd64ibus input 
method framework for clutter
un  ibus-doc(no 
description available)
un  ibus-el (no 
description available)
un  ibus-googlepinyin   (no 
description available)
ii  ibus-gtk:amd64 1.5.19-4+deb10u1amd64Intelligent 
Input Bus - GTK+2 support
ii  ibus-gtk3:amd641.5.19-4+deb10u1amd64Intelligent 
Input Bus - GTK+3 support
un  ibus-qt4(no 
description available)

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ibus depends on:
ii  adwaita-icon-theme   3.30.1-1
ii  dconf-cli0.30.1-2
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-ibus-1.0  1.5.19-4+deb10u1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdconf10.30.1-2
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libibus-1.0-51.5.19-4+deb10u1
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  librsvg2-common  2.44.10-2.1
ii  libx11-6 2:1.6.7-1
ii  libxi6   2:1.7.9-1
ii  python3  3.7.3-1
ii  python3-gi   3.30.4-1

Versions of packages ibus recommends:
ii  ibus-clutter  0.0+git20090728.a936bacf-5.1+b2
ii  ibus-gtk  1.5.19-4+deb10u1
ii  ibus-gtk3 1.5.19-4+deb10u1
pn  ibus-qt4  
ii  im-config 0.43-1
ii  libqt5gui55.11.3+dfsg1-1+deb10u3

Versions of packages ibus suggests:
pn  ibus-

Bug#951709: /boot should get a bigger share of disk in default installation

[Steve McIntyre]

On Fri, Mar 13, 2020 at 06:03:38AM +0100, Cyril Brulebois wrote:
>Steve McIntyre  (2020-03-12):
>> I'm torn - that's a good plan for large systems, but people on smaller
>> platforms (e.g. small SD on rpi) that's a lot of space.
>
>Don't people usually flash ready to use images on such devices, instead
>of going through d-i? Meaning acepting whatever (hopefully appropriate)
>choices were made by recipe authors?

Some do, some don't IME. To be honest, let's just go with the biggser
size anyway. People can always tweak if they need to.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer

Bug#953958: Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless

[Marco d'Itri]

On Mar 15, John Paul Adrian Glaubitz  wrote:

> Do you have a patch handy, then I'll fix the package manually for the time
> being for ia64 only?
Just edit debian/patch_libtool.
Let me know if it works and I will apply the change.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless

[John Paul Adrian Glaubitz]

On 3/14/20 5:19 PM, James Clarke wrote:
> This is just the opposite of #947606; ia64 is meant to have libcrypt.so.1, not
> libcrypt.so.1.1 like alpha, and so that change needs to be reverted. See [1]
> for an old glibc build log to demonstrate the correct name (and note that,
> unlike alpha, sysdeps/unix/sysv/linux/ia64/shlib-versions does not override
> libcrypt's version).

Do you have a patch handy, then I'll fix the package manually for the time
being for ia64 only?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#953852: ardentryst: should this package be removed?

[Sandro Tosi]

> please don't remove it yet.
> I started porting it to Python 3 some time ago and plan to finish
> that in the next weeks.

please keep in mind there's nothing wrong in removing the package
as-is now and re-introduce it later on when it's been ported to
python3.

but anyways, ok we'll wait, but i'm gonna keep this bug as RC so that
it can be removed from Testing and allow for the removal of its
dependencies (if necessary/possible).

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#882584: Found the salsa package

[Martin Quinson]

On Sat, Mar 14, 2020 at 09:02:49PM +, Mike Gabriel wrote:
> On  Sa 14 Mär 2020 00:36:21 CET, Martin Quinson wrote:
> 
> > https://salsa.debian.org/debian-edu-pkg-team/openboard/
> > 
> > could we however modify this git repository to use git-buildpackage?
> > It makes things so much easier to maintain...
> > 
> > Thanks for your work,
> > Mt
> 
> Sorry, no. I see myself in a constant process of removing more and more
> files from the upstream Git tag/tarball, because files are non-DFSG for this
> or that reason. I am not willing to pollute the salsa repo with these
> changes.

Ok, you know that better than I do.

> To get openboard on salsa built, these steps should work:
> 
>   $ git clone https://salsa.debian.org/debian-edu-pkg-team/openboard.git
>   $ cd openboard
>   $ debian/rules get-orig-source
>   $ debuild -uc -us -S -Zxz -d
>   $ dpkg-source -x openboard_.dsc
>   $ cd openboard-
>   $ debuild -uc -us

I just tried, and it fails on the last step because of missing
dependencies. Maybe we could add a .gitlab-ci attempting these steps
so that we see where we currently stand?

> IIRC, the current version on the repo's master branch only works / builds
> well on Debian testing/unstable.

Do you have a list of tasks to be completed? I'm willing to help if I
can (given my scarce spare time), but I feel a bit helpless here. You
are clearly in the middle of something, and I'd really appreciate if
you could save some time to explain what remains to be done and how
one could help with this packaging.

Anyway, thanks for this work.
Mt

-- 
So the question is not whether we will be extremists, but what kind of
extremists we will be. [..] Perhaps the world [is] in dire need of
creative extremists.--- Martin Luther King, Jr


signature.asc
Description: PGP signature

Bug#953960: pkg-kde-tools: Uses obsolete Dpkg module variable

[Guillem Jover]

Source: pkg-kde-tools
Source-Version: 0.15.31
Severity: important

Hi!

This package uses at least one obsolete Dpkg module variable
($Dpkg::version), which has been removed in dpkg 1.20.0, currently
in experimental. Public variables have been renamed to be uppercase
($Dpkg::VERSION).

Please update the code. Once dpkg gets uploaded to sid this might
break this package.

Thanks,
Guillem

Bug#912788: fixed in ghc 8.8.3-1~exp1

[Sandro Tosi]

> Format: 1.8
> Date: Fri, 28 Feb 2020 10:56:27 +0200
> Source: ghc
> Architecture: source
> Version: 8.8.3-1~exp1
> Distribution: experimental
> Urgency: medium
> Maintainer: Debian Haskell Group 
> 
> Changed-By: Ilias Tsitsimpis 
> Closes: 912788 943097
> Changes:
>  ghc (8.8.3-1~exp1) experimental; urgency=medium
>  .
>* New upstream release
>* Do not pass ggc-min-expand=10 on mips64el
>* Remove unnecessary build-dependency on alex
>* Replace python-sphinx build-dependency with python3-sphinx
>  (Closes: #943097)
>* Allow unregisterised ghc-8.6 to build newer GHC
>* Fix wrong installation of ghc- manpages
>* Bump compat level to 12
>* Use the debhelper-compat build-dependency and remove d/compat
>* Update to llvm-9 (Closes: #912788)

looks like ~exp2 built on all release archs, so ss there any chance
this version can be uploaded to unstable? ghc is currently the last
reverse dependency for llvm-toolchain-6.0, which could be removed as
soon as the version of ghc reaches sid. bonus points, this version
will also reduce by 1 the number of reverse dependencies of
python-sphinx, making it closer to be removed.

Thanks for considering.
Sandro

Bug#947437: flang: Please update to llvm-9

[Sandro Tosi]

> I tried a test build with llvm-8 and -9 and it failed. There have been
> no releases since March 2019,
>
> but there is very active development as flang is being merged into the
> official llvm project.
>
> There have been no tags since, but I will see if I can build/test head
> of tree against llvm-9

has there any progress been achieved in getting flang to build with
llvm-9? currently flang is the last reverse dependency of llvm-7,
which could be removed if flang is ported to llvm-9.

Regards,
Sandro

Bug#953872: ITP: fonts-jf-openhuninn -- Chinese (Taiwan) font based on Kosugi Maru

[Yao Wei]

On Sat, Mar 14, 2020 at 06:56:49PM +0800, Yao Wei wrote:
> * License : OFL-1.1, without Reserved Font Names

The license should come with Reserved Font Names "Varela" and "Varela
Round" since the latin part of the fonts are replaced with it.


signature.asc
Description: PGP signature

Bug#953957: [live-build] W: Download is performed unsandboxed as root as file '.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

[jnqnfe]

Package: live-build
Version: 1:20191221

744141c60f55144b4d8944ba0d745adcc4b34116 (from MR #97) tried to fix the
bug of the source stage generating permissions related warnings when
downloading source packages.

the original fix submitted in the MR was to set the permissions of the
download directory to 777. the reviewer requested that instead
ownership be set to _apt:root, which was the version of the commit that
then got merged.

unfortunately this modified solution does not work. i do not know why
this was not caught at the time, whether i did not bother to test since
it seemed so obvious that it should work, or whether something went
wrong with conducting a fresh test, but re-running the source stage now
i see that the problem still exists.

i have been playing around with trying to figure out a suitable
alternative to properly solve this but not been successful so far.

submitting this as a bug report to ensure that a record is made in case
i don't find a solution / i end up forgetting about this / someone else
can find a solution in the meantime.

Bug#953954: python-greenlet: diff for NMU version 0.4.15-4.1

[GCS]

On Sun, Mar 15, 2020 at 1:02 AM Sandro Tosi  wrote:
> On Sat, Mar 14, 2020 at 7:59 PM László Böszörményi (GCS)  
> wrote:
> > On Sat, Mar 14, 2020 at 11:42 PM Sandro Tosi  wrote:
> > > I've prepared an NMU for python-greenlet (versioned as 0.4.15-4.1). The 
> > > diff
> > > is attached to this message.
> >  I don't know what made it target for immediate NMU, but thanks for your 
> > help.
>
> just working thru the list of python-sphinx rdeps, sorry if that was a
> bit too aggressive
 It was. Most of the time I can act very quickly and would have let me
include other changes as well.

Laszlo/GCS

Bug#943150: liblognorm: diff for NMU version 2.0.5-1.1

[Sandro Tosi]

Control: tags 943150 + patch


Dear maintainer,

I've prepared an NMU for liblognorm (versioned as 2.0.5-1.1). The diff
is attached to this message.

Regards.

diff -Nru liblognorm-2.0.5/debian/changelog liblognorm-2.0.5/debian/changelog
--- liblognorm-2.0.5/debian/changelog	2018-04-29 05:52:22.0 -0400
+++ liblognorm-2.0.5/debian/changelog	2020-03-14 20:04:16.0 -0400
@@ -1,3 +1,10 @@
+liblognorm (2.0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build documentation with python3-sphinx; Closes: #943150
+
+ -- Sandro Tosi   Sat, 14 Mar 2020 20:04:16 -0400
+
 liblognorm (2.0.5-1) unstable; urgency=medium
 
   * New upstream version 2.0.5
diff -Nru liblognorm-2.0.5/debian/control liblognorm-2.0.5/debian/control
--- liblognorm-2.0.5/debian/control	2018-04-29 05:49:30.0 -0400
+++ liblognorm-2.0.5/debian/control	2020-03-14 20:03:37.0 -0400
@@ -8,7 +8,7 @@
 libxml2-dev,
 libestr-dev,
 libfastjson-dev,
-python-sphinx (>= 1.0.7+dfsg) | python3-sphinx
+python3-sphinx
 Standards-Version: 3.9.8
 Section: libs
 Homepage: http://www.liblognorm.com/

Bug#953956: python-gevent-doc: should install doc in /usr/share/doc/python-gevent-doc/

[GCS]

On Sun, Mar 15, 2020 at 12:42 AM Sandro Tosi  wrote:
> as of now, python-gevent-doc installs the documentation under
> /usr/share/doc/python-gevent/ which is shared by python-gevent. Since the
> documentation is both for python-gevent and python3-gevent, it should be
> installed under /usr/share/doc/python-gevent-doc/ instead (so that's 
> independend
> of the python version used).
 I'll consider this, even as the Python 2 variant is going to be removed.

Thanks for the note,
Laszlo/GCS

Bug#953954: python-greenlet: diff for NMU version 0.4.15-4.1

[Sandro Tosi]

On Sat, Mar 14, 2020 at 7:59 PM László Böszörményi (GCS)  
wrote:
>
> On Sat, Mar 14, 2020 at 11:42 PM Sandro Tosi  wrote:
> > Package: python-greenlet
> > Version: 0.4.15-4
> > Severity: normal
> > Tags: patch  pending
> [...]
> > I've prepared an NMU for python-greenlet (versioned as 0.4.15-4.1). The diff
> > is attached to this message.
>  I don't know what made it target for immediate NMU, but thanks for your help.

just working thru the list of python-sphinx rdeps, sorry if that was a
bit too aggressive

>
> Regards,
> Laszlo/GCS



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#953954: python-greenlet: diff for NMU version 0.4.15-4.1

[GCS]

On Sat, Mar 14, 2020 at 11:42 PM Sandro Tosi  wrote:
> Package: python-greenlet
> Version: 0.4.15-4
> Severity: normal
> Tags: patch  pending
[...]
> I've prepared an NMU for python-greenlet (versioned as 0.4.15-4.1). The diff
> is attached to this message.
 I don't know what made it target for immediate NMU, but thanks for your help.

Regards,
Laszlo/GCS

Bug#953956: python-gevent-doc: should install doc in /usr/share/doc/python-gevent-doc/

[Sandro Tosi]

Package: python-gevent-doc
Severity: important

Hello,
as of now, python-gevent-doc installs the documentation under
/usr/share/doc/python-gevent/ which is shared by python-gevent. Since the
documentation is both for python-gevent and python3-gevent, it should be
installed under /usr/share/doc/python-gevent-doc/ instead (so that's independend
of the python version used).

Regards,
Sandro

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#953955: python-gevent: diff for NMU version 1.4.0-1.1

[Sandro Tosi]

Package: python-gevent
Version: 1.4.0-1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for python-gevent (versioned as 1.4.0-1.1). The diff
is attached to this message.

Please consider maintaining this package under DPMT umbrella

Regards.

diff -Nru python-gevent-1.4.0/debian/changelog python-gevent-1.4.0/debian/changelog
--- python-gevent-1.4.0/debian/changelog	2019-10-27 03:45:10.0 -0400
+++ python-gevent-1.4.0/debian/changelog	2020-03-14 18:47:23.0 -0400
@@ -1,3 +1,10 @@
+python-gevent (1.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build documentation using python3-sphinx
+
+ -- Sandro Tosi   Sat, 14 Mar 2020 18:47:23 -0400
+
 python-gevent (1.4.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-gevent-1.4.0/debian/control python-gevent-1.4.0/debian/control
--- python-gevent-1.4.0/debian/control	2019-10-27 03:24:01.0 -0400
+++ python-gevent-1.4.0/debian/control	2020-03-14 18:46:50.0 -0400
@@ -4,7 +4,7 @@
 Build-Depends: debhelper (>= 11), dh-python, python-all-dev,
  dh-exec,
  libevent-dev (>= 1.4), python-greenlet (>= 0.4.15) | python-codespeak-lib (<< 1.0),
- python-sphinx (>= 1.0.7+dfsg), python-all-dbg,
+ python-all-dbg,
  python-greenlet-dbg, python3-greenlet-dbg,
  python-setuptools, python3-setuptools,
  python-cffi,  python-cffi-backend-dbg,
diff -Nru python-gevent-1.4.0/debian/rules python-gevent-1.4.0/debian/rules
--- python-gevent-1.4.0/debian/rules	2019-10-27 03:45:10.0 -0400
+++ python-gevent-1.4.0/debian/rules	2020-03-14 18:47:20.0 -0400
@@ -13,7 +13,7 @@
 
 override_dh_auto_build:
 	dh_auto_build
-	PYTHONPATH=../src/ make --directory doc/ html
+	PYTHONPATH=../src/ make --directory doc/ html SPHINXBUILD=/usr/share/sphinx/scripts/python3/sphinx-build
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#952513: mfoc: update the tool with other upstream

[Samuel Henrique]

Hello Sophie,

Thanks for reporting this,

Looking at what the creator of that fork wrote:
"I'm more interested in integrate the mod into official project
instead of forking a new one." [0]

I believe it's better to wait a little bit to see if upstream replies
on the PR[1], it
looks like there were some issues initially, they were solved on last
December and
so I pinged upstream on that PR to try to get a review.

[0] https://github.com/aczid/crypto1_bs/issues/35#issuecomment-468337659
[1] https://github.com/nfc-tools/mfoc/pull/60
-- 
Samuel Henrique 

Bug#947069: pip does not handle manylinux2010 tag (PEP571)

[Scott Kitterman]

On Fri, 20 Dec 2019 13:27:54 +0100 Gabriel Corona  wrote:
> Package: python3-pip
> Version: 18.1-5
> Severity: normal
> 
> Dear Maintainer,
> 
> The pip package as installed by python3-pip refuses to install
> manylinux2010 wheels (see PEP 571).

This needs a newer pip version to properly support.  As a result, I'm going to 
merge this with another bug that requests the newer version.

Scott K

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

Bug#952954: ITP: fonts-jetbrains-mono -- free and open-source typeface for developers

[Romain Porte]

Hello,

> Version 1.0.3-2 has been uploaded to mentors with this change, and also
> adding a little bit metadata:
>
> https://mentors.debian.net/package/fonts-jetbrains-mono
>
> I have marked previous 1.0.3-1 as "UNRELEASED" in the changelog, I hope
> it makes sense to do that.

Any review on this 1.0.3-2 release on mentors?

I think the package looks pretty good by now, at least from Lintian
perspective. I still do not know how to modify (if required) the package
to be in the "contrib" section instead of "main" section because we
cannot rebuild the *.ttf files from source, as mentioned in previous
discussion.

Kind regards,

Romain.


signature.asc
Description: PGP signature

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Guillem Jover wrote on Sat, 14 Mar 2020 22:51 +00:00:
> Hi!
> 
> On Sat, 2020-03-14 at 21:49:12 +, Daniel Shahaf wrote:
> > Sean Whitton wrote on Sat, 14 Mar 2020 20:39 +00:00:
> > > On Sat 14 Mar 2020 at 08:09PM +00, Daniel Shahaf wrote:
> > > > Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> > > >> -   ::
> > > >> -
> > > >> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> > > >> -
> > > >> +   All of the bug numbers listed must be given on the same physical 
> > > >> line
> > > >> +   as the word ``closes:``.
> > > >
> > > > Is this newly-added sentence correct?
> > > >
> > > > Whether it correctly states the semantics of the regexp depends on
> > > > whether the regexp is matched against the changelog entry as a single
> > > > multiline string or line-by-line.  In the former case, the list of bug
> > > > numbers would be allowed to span multiple lines, but in the latter case
> > > > it wouldn't.
> > > >
> > > > Currently, the patch assumes all bug numbers should be on the same line,
> > > > but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
> > > > span multiple lines.  I'm guessing the syntax file is right and the 
> > > > patch should
> > > > be changed?
> > > 
> > > In PCREs \s matches the newline character so I believe your text is
> > > incorrect.
> > 
> > I agree that it is probably incorrect, but that doesn't follow from the
> > semantics of /\s/.  Even if /\s/ matched any single byte/character, the
> > semantics would still depend on what haystack the regexp is matched
> > against: the entire changelog entry, or one line thereof at a time.
> 
> It is definitely incorrect. The canonical implementation is currently
> in libdpkg-perl's Dpkg::Changelog::Entry::Debian::find_closes(), where
> the entire changelog entry is passed as a single string, so something
> like this is perfectly fine:
> 
> Closes:
>   #12345,
>   #67890,
>   #5
> 

Thanks for the review and the pointer to the source of truth!

> AFAIK, DAK only operates based on the Closes field in the .changes
> file. I'll clarify the regex also in the deb-changelog(5) man page.
> 
> Thanks,
> Guillem

Cheers,

Daniel

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Guillem Jover]

Hi!

On Sat, 2020-03-14 at 21:49:12 +, Daniel Shahaf wrote:
> Sean Whitton wrote on Sat, 14 Mar 2020 20:39 +00:00:
> > On Sat 14 Mar 2020 at 08:09PM +00, Daniel Shahaf wrote:
> > > Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> > >> -   ::
> > >> -
> > >> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> > >> -
> > >> +   All of the bug numbers listed must be given on the same physical line
> > >> +   as the word ``closes:``.
> > >
> > > Is this newly-added sentence correct?
> > >
> > > Whether it correctly states the semantics of the regexp depends on
> > > whether the regexp is matched against the changelog entry as a single
> > > multiline string or line-by-line.  In the former case, the list of bug
> > > numbers would be allowed to span multiple lines, but in the latter case
> > > it wouldn't.
> > >
> > > Currently, the patch assumes all bug numbers should be on the same line,
> > > but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
> > > span multiple lines.  I'm guessing the syntax file is right and the patch 
> > > should
> > > be changed?
> > 
> > In PCREs \s matches the newline character so I believe your text is
> > incorrect.
> 
> I agree that it is probably incorrect, but that doesn't follow from the
> semantics of /\s/.  Even if /\s/ matched any single byte/character, the
> semantics would still depend on what haystack the regexp is matched
> against: the entire changelog entry, or one line thereof at a time.

It is definitely incorrect. The canonical implementation is currently
in libdpkg-perl's Dpkg::Changelog::Entry::Debian::find_closes(), where
the entire changelog entry is passed as a single string, so something
like this is perfectly fine:

Closes:
  #12345,
  #67890,
  #5

AFAIK, DAK only operates based on the Closes field in the .changes
file. I'll clarify the regex also in the deb-changelog(5) man page.

Thanks,
Guillem

Bug#953953: [collectd-core] Python plugin is missing correct linking

[Adrien CLERC]

Package: collectd-core
Version: 5.10.0-1+b1
Severity: important

--- Please enter the report below this line. ---

After upgrading from 5.9.2.g-1, I have the following error:

ERROR: dlopen("/usr/lib/collectd/python.so") failed:
/usr/lib/collectd/python.so: undefined symbol: PyFloat_Type. The most
common cause for this problem is missing dependencies. Use ldd(1) to
check the dependencies of the plugin / shared object.

And indeed, it seems something is not going well:

# ldd /usr/lib/collectd/python.so
    linux-vdso.so.1 (0x03d3671df000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x03d36719c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x03d366fdc000)
    /lib64/ld-linux-x86-64.so.2 (0x03d3671e1000)

For information, the same output with collectd-core 5.9.2.g-1:

# ldd /usr/lib/collectd/python.so
    linux-vdso.so.1 (0x037928c2f000)
    libpython3.7m.so.1.0 =>
/usr/lib/x86_64-linux-gnu/libpython3.7m.so.1.0 (0x03792871d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x0379286fc000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x03792853c000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
(0x03792850f000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x0379284f2000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0379284ed000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x0379284e6000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0379283a1000)
    /lib64/ld-linux-x86-64.so.2 (0x037928c31000)

Something is missing somewhere :)

I'm available for more testing,

Adrien

Bug#953954: python-greenlet: diff for NMU version 0.4.15-4.1

[Sandro Tosi]

Package: python-greenlet
Version: 0.4.15-4
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for python-greenlet (versioned as 0.4.15-4.1). The diff
is attached to this message.

Please consider maintaining this package under DPMT umbrella.

Regards.

diff -Nru python-greenlet-0.4.15/debian/changelog python-greenlet-0.4.15/debian/changelog
--- python-greenlet-0.4.15/debian/changelog	2019-11-20 12:13:29.0 -0500
+++ python-greenlet-0.4.15/debian/changelog	2020-03-14 18:37:04.0 -0400
@@ -1,3 +1,10 @@
+python-greenlet (0.4.15-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build documentation with python3-sphinx
+
+ -- Sandro Tosi   Sat, 14 Mar 2020 18:37:04 -0400
+
 python-greenlet (0.4.15-4) unstable; urgency=medium
 
   * Fix dh-python build dependency (closes: #945135).
diff -Nru python-greenlet-0.4.15/debian/control python-greenlet-0.4.15/debian/control
--- python-greenlet-0.4.15/debian/control	2019-11-20 12:13:29.0 -0500
+++ python-greenlet-0.4.15/debian/control	2020-03-14 18:33:51.0 -0400
@@ -5,7 +5,7 @@
  python-all-dev, python-all-dbg,
  python3-all-dev, python3-all-dbg,
  python-setuptools, python3-setuptools,
- python-sphinx, python3-sphinx
+ python3-sphinx
 Standards-Version: 4.4.1
 Section: python
 Homepage: https://pypi.python.org/pypi/greenlet
diff -Nru python-greenlet-0.4.15/debian/rules python-greenlet-0.4.15/debian/rules
--- python-greenlet-0.4.15/debian/rules	2019-11-20 12:13:22.0 -0500
+++ python-greenlet-0.4.15/debian/rules	2020-03-14 18:34:51.0 -0400
@@ -26,7 +26,7 @@
 
 override_dh_auto_build: $(PYTHON3:%=build-python%)
 	dh_auto_build
-	cd doc && PYTHONPATH=.. make html
+	cd doc && PYTHONPATH=.. make html SPHINXBUILD=/usr/share/sphinx/scripts/python3/sphinx-build
 
 install-python%:
 	python$* setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb

Bug#953284: RM: dosemu -- ROM; abandoned upstream

[Scott Kitterman]

On March 14, 2020 9:37:01 PM UTC, Guillem Jover  wrote:
>Hi!
>
>On Sat, 2020-03-14 at 14:07:34 -0700, Kees Cook wrote:
>> On Sat, Mar 14, 2020 at 06:56:30PM +, Scott Kitterman wrote:
>> > On March 14, 2020 12:14:48 PM UTC, Guillem Jover
> wrote:
>> > >On Fri, 2020-03-06 at 20:43:05 -0800, Kees Cook wrote:
>> > >> Package: ftp.debian.org
>> > >> Severity: normal
>> > >
>> > >This seems to have continued by upstream, at least, in spirit at
>> > >, which seems rather active.
>> > 
>> > It describes itself as an entirely new project with the same goals,
>> > so my assumption is that it's existence shouldn't block this rm.
>> > If someone wants to package it, it should be a new package anyway.
>> 
>> That was my thinking as well. And dosemu isn't even present in the
>last
>> stable...
>
>Sorry, I didn't mean that note as an objection. I just noticed the
>removal on aptitude and used deb-why-removed to get more details. Once
>I found the continuation project, I wanted to note it down in case
>someone else stumbles on this too.
>
>Thanks,
>Guillem

Thanks for the clarification.  I think that's entirely sensible.

Scott K

Bug#953952: kmod: libkmod2-udeb contains binary instead of libraries

[Aurelien Jarno]

Package: kmod
Version: 26+20191223-1
Severity: serious
Tags: d-i
Justification: Policy 8.6.4

The libkmod2 shlibs file contains the following entry:

| libkmod 2 libkmod2 (>= 26+20191223)
| udeb: libkmod 2 libkmod2-udeb (>= 26+20191223)

It means that libkmod.so.2 is supposed to be provided by libkmod2-udeb.
In practice it only contains the kmod binaries:

| $ dpkg -c libkmod2-udeb_27-2_amd64.udeb
| drwxr-xr-x root/root 0 2020-03-13 22:53 ./
| drwxr-xr-x root/root 0 2020-03-13 22:53 ./bin/
| -rwxr-xr-x root/root121656 2020-03-13 22:53 ./bin/kmod
| drwxr-xr-x root/root 0 2020-03-13 22:53 ./etc/
| drwxr-xr-x root/root 0 2020-03-13 22:53 ./etc/modprobe.d/
| -rw-r--r-- root/root   246 2020-03-13 22:53 ./etc/modprobe.d/aliases.conf
| drwxr-xr-x root/root 0 2020-03-13 22:53 ./sbin/
| lrwxrwxrwx root/root 0 2020-03-13 22:53 ./bin/lsmod -> kmod
| lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/depmod -> /bin/kmod
| lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/insmod -> /bin/kmod
| lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/lsmod -> /bin/kmod
| lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/modinfo -> /bin/kmod
| lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/modprobe -> /bin/kmod
| lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/rmmod -> /bin/kmod

udev-udeb depends on libkmod2-udeb as /lib/systemd/systemd-udevd
requires libkmod.so.2.

The binaries should probably be moved to a different package like
kmod-udeb, as they conflict with busybox-udeb. Right now the kmod ones
are used, but it depends on the unpack order.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc

[Olly Betts]

On Sat, Mar 14, 2020 at 05:59:42PM -0400, Sandro Tosi wrote:
> > The Python2 and Python3 bindings don't have exactly the same API (mostly
> > due to Unicode handling differences, but also the Python3 bindings don't
> > include various backward-compatibility features with older versions of
> > the Python2 bindings)
> 
> does the documentation access the bindings source code at build time?
> if not, you can still use only python3-sphinx to build both doc
> versions (and still ship them separately).

It does - that's why it requires both versions of sphinx rather than
just running allowing one to be specified.

Cheers,
Olly

Bug#953853: musl-tools: should it be Multi-Arch: foreign?

[Johannes Schauer]

Hi Thorsten & Reiner,

Quoting Thorsten Glaser (2020-03-14 18:26:24)
> >Enabling M-A:foreign for musl-tools is unfortunately currently not
> >possible. It's not arch:all, as it ships a few arch-dependent files.
> 
> That’s true for other packages as well.
> 
> A package can, generally, be made Multi-Arch: foreign, if it, and
> all of its dependencies, can be used on a foreign system which has
> the capability to execute its code (e.g. i386 on an amd64 system,
> or anything with qemu-user-static).

you are right. Even arch:any packages are allowed to have a m-a:foreign
annotation. Unfortunately, there are more conditions than the one you name
before it is correct to mark a given package as m-a:foreign.

> >E.g. the spec file, /usr/bin/musl-gcc (which hardcodes the arch-dependent
> >path to the spec file), and /usr/bin/musl-ldd, which is a symlink to
> >libc.so.
> 
> Yes, but that’d be deliberate. Installing a foreign-architecture
> musl-tools would then enable one to cross-compile. At least that’s
> the idea. I’m not completely sure it’s the right way or even a good
> way, or whether it’ll break $things, which is why I added the two “cross”
> guys in Cc.

I only had a very quick look at what musl-tools does but I do not think that it
is correct to mark it as m-a:foreign. /usr/bin/musl-ldd is a direct symlink to
/lib/x86_64-linux-musl/libc.so and /usr/bin/musl-gcc just calls /usr/bin/cc
with /usr/lib/x86_64-linux-musl/musl-gcc.specs as a spec file. Both of these
things make the interface provided by the package musl-tools architecture
dependent. This means that a package that musl-tools:amd64 will give you
different functionality compared to musl-tools:i386.

For more context, read this handy write-up by Helmut:

https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#953944: crmsh: flaky autopkgtest that times out regularly: missing isolation-machine restriction?

[Paul Gevers]

Hi Valentin,

On 14-03-2020 23:02, Valentin Vidić wrote:
> On Sat, Mar 14, 2020 at 10:55:29PM +0100, Paul Gevers wrote:
>> Can you rephrase your question, I don't understand what you're asking.
>> Everything I can provide you is already available from ci.debian.net.
> 
> Right, so when the test timeouts it hangs on something but this is not
> visible in the logs or anywhere. You mentioned that it causes problems
> for the whole host when this happens so I was thinking you chould send
> some more info like the 'ps aufx' so I can get an idea what it is doing
> when it hangs? If not I can just disable the last test and it should be
> fine again.

We are having issues with the infrastructure and the end of the log
hints that this test may be one of the tests that cause it. If I catch
such a failure in real life, I'll send you the $(ps auxf), but I'm not
inspecting every issue at the moment and regularly just restart *all*
the workers when many hang. E.g. here [1] you can see the amount of
running lxc containers per worker. It should toggle between 0 and 1 for
the amd64 workers (ci-worker-[0-9]*), but they are ramping up because
the lxc doesn't close always. Some workers remain longer at one level,
while others jump multiple times per day. All workers are identical from
the provisioning point of view.

[1] https://ci.debian.net/munin/debci-day.html

Paul



signature.asc
Description: OpenPGP digital signature

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Sean Whitton]

Hello,

On Sat 14 Mar 2020 at 09:49PM +00, Daniel Shahaf wrote:

> I agree that it is probably incorrect, but that doesn't follow from the
> semantics of /\s/.  Even if /\s/ matched any single byte/character, the
> semantics would still depend on what haystack the regexp is matched
> against: the entire changelog entry, or one line thereof at a time.

I see what you mean.

> Here's a revision of the patch incorporating the feedback so far:

I'm happy to go ahead and apply this though it would be useful for
someone else to verify the text does indeed agree with the regexp.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#953944: crmsh: flaky autopkgtest that times out regularly: missing isolation-machine restriction?

[Valentin Vidić]

On Sat, Mar 14, 2020 at 10:55:29PM +0100, Paul Gevers wrote:
> Can you rephrase your question, I don't understand what you're asking.
> Everything I can provide you is already available from ci.debian.net.

Right, so when the test timeouts it hangs on something but this is not
visible in the logs or anywhere. You mentioned that it causes problems
for the whole host when this happens so I was thinking you chould send
some more info like the 'ps aufx' so I can get an idea what it is doing
when it hangs? If not I can just disable the last test and it should be
fine again.

-- 
Valentin

Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc

[Sandro Tosi]

> The Python2 and Python3 bindings don't have exactly the same API (mostly
> due to Unicode handling differences, but also the Python3 bindings don't
> include various backward-compatibility features with older versions of
> the Python2 bindings)

does the documentation access the bindings source code at build time?
if not, you can still use only python3-sphinx to build both doc
versions (and still ship them separately).

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#953951: remmina: Raspberry PI Dual Monitor to Window RDP Server Stretchin over 2 screens

[Duncan Hare]

Package: remmina
Version: 1.4.1+dfsg-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?Dual Monitoes on Raspberry PI 4, Windows RDP 
stretched over 2 screens, 
results in LHS of windows window nocing halftway accress LHS physical screen

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Ifnstalled latest Remmina build from github.
   * What was the outcome of this action?
No change in behaviour from prior bug report 932062
   * What outcome did you expect instead?
Full screen of windoes over 2 monitors

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


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.19.97-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages remmina depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavahi-ui-gtk3-00.7-4+b1
ii  libayatana-appindicator3-10.5.3-4
ii  libc6 2.28-10+rpi1
ii  libcairo2 1.16.0-4+rpt1
ii  libgcrypt20   1.8.4-5
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1+rpt2
ii  libjson-glib-1.0-01.4.4-2
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libsodium23   1.0.17-1
ii  libsoup2.4-1  2.64.2-2
ii  libssh-4  0.8.7-1
ii  libssl1.1 1.1.1d-0+deb10u2+rpt1
ii  libvte-2.91-0 0.54.2-2
ii  remmina-common1.4.1+dfsg-1

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.4.1+dfsg-1
ii  remmina-plugin-secret  1.4.1+dfsg-1
ii  remmina-plugin-vnc 1.4.1+dfsg-1

Versions of packages remmina suggests:
pn  remmina-plugin-exec 
pn  remmina-plugin-kwallet  
pn  remmina-plugin-nx   
pn  remmina-plugin-spice
pn  remmina-plugin-www  
pn  remmina-plugin-xdmcp

-- no debconf information

Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc

[Olly Betts]

Control: tags -1 wontfix

On Sat, Mar 14, 2020 at 05:35:14PM -0400, Sandro Tosi wrote:
> from what i can see, xapian-bindings builds its documentation twice, one for 
> the
> python2 bindings (and install that in bin:python-xapian) and one for the 
> python3
> bindings (and install that in bin:python3-xapian).
> 
> this is usually un-necessary, and the convention is to create a separate 
> package
> to contain the documentation, in this case python-xapian-doc. So please split
> out such a package to contain the documentation for the python bindings in a
> single place, and that the same time, please only use python3-sphinx to build
> the documentation.

The Python2 and Python3 bindings don't have exactly the same API (mostly
due to Unicode handling differences, but also the Python3 bindings don't
include various backward-compatibility features with older versions of
the Python2 bindings)

A single set of docs doesn't really work as the Python3 bindings docs
aren't a good replacement for the Python2 bindings docs.  It this seems
to fall outside your "usually un-necessary" hence tagging as wontfix.

Cheers,
Olly

Bug#953942: jack: should this package be removed?

[Andreas Beckmann]

Control: found -1 3.1.1+cvs20050801-31
Control: tag -1 sid bullseye

Hi Sandro,

On Sat, 14 Mar 2020 15:33:34 -0400 Sandro Tosi  wrote:
> I believe this package should be removed:

please file the "should this package be removed?" bugs tagged
sid+bullseye (unless you want them removed from (old)stable, too).

Thanks

Andreas

Bug#953950: twisted: CVE-2020-10108 CVE-2020-10109

[Salvatore Bonaccorso]

Source: twisted
Version: 18.9.0-6
Severity: important
Tags: security upstream
Control: found -1 19.10.0~rc1-1
Control: found -1 18.9.0-3
Control: found -1 16.6.0-2

Hi,

The following vulnerabilities were published for twisted.

CVE-2020-10108[0]:
| In Twisted Web through 19.10.0, there was an HTTP request splitting
| vulnerability. When presented with two content-length headers, it
| ignored the first header. When the second content-length value was set
| to zero, the request body was interpreted as a pipelined request.


CVE-2020-10109[1]:
| In Twisted Web through 19.10.0, there was an HTTP request splitting
| vulnerability. When presented with a content-length and a chunked
| encoding header, the content-length took precedence and the remainder
| of the request body was interpreted as a pipelined request.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-10108
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10108
[1] https://security-tracker.debian.org/tracker/CVE-2020-10109
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10109
[2] https://know.bishopfox.com/advisories/twisted-version-19.10.0#INOR

Regards,
Salvatore

Bug#953944: crmsh: flaky autopkgtest that times out regularly: missing isolation-machine restriction?

[Paul Gevers]

Hi Valentin,

On 14-03-2020 21:59, Valentin Vidić wrote:
> On Sat, Mar 14, 2020 at 09:25:33PM +0100, Paul Gevers wrote:
>> I copied the output at the bottom of this report. All the failing tests
>> that I inspected look like it.
>>
>> I'll put your package on the ci.d.n ignore list until this bug is fixed.
> 
> Ok, but would it be possible to get a process list when the test
> timeouts as I can't reproduce the problem locally using lxc?

Can you rephrase your question, I don't understand what you're asking.
Everything I can provide you is already available from ci.debian.net.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Sean Whitton wrote on Sat, 14 Mar 2020 20:39 +00:00:
> Hello,
> 
> On Sat 14 Mar 2020 at 08:09PM +00, Daniel Shahaf wrote:
> 
> > Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> >> -   ::
> >> -
> >> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> >> -
> >> +   All of the bug numbers listed must be given on the same physical line
> >> +   as the word ``closes:``.
> >
> > Is this newly-added sentence correct?
> >
> > Whether it correctly states the semantics of the regexp depends on
> > whether the regexp is matched against the changelog entry as a single
> > multiline string or line-by-line.  In the former case, the list of bug
> > numbers would be allowed to span multiple lines, but in the latter case
> > it wouldn't.
> >
> > Currently, the patch assumes all bug numbers should be on the same line,
> > but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
> > span multiple lines.  I'm guessing the syntax file is right and the patch 
> > should
> > be changed?
> 
> In PCREs \s matches the newline character so I believe your text is
> incorrect.

I agree that it is probably incorrect, but that doesn't follow from the
semantics of /\s/.  Even if /\s/ matched any single byte/character, the
semantics would still depend on what haystack the regexp is matched
against: the entire changelog entry, or one line thereof at a time.

Here's a revision of the patch incorporating the feedback so far:

[[[
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 1d870d9..1c71525 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -151,9 +151,9 @@ used here to separate groups of changes, if desired.
 If this upload resolves bugs recorded in the Bug Tracking System (BTS),
 they may be automatically closed on the inclusion of this package into
 the Debian archive by including the string: ``closes:  Bug#n`` in
-the change details.  [#]_ This information is conveyed via the
-``Closes`` field in the ``.changes`` file (see
-:ref:`s-f-Closes`).
+the change details, where ``#n`` is the bug number.  [#]_ This
+information is conveyed via the ``Closes`` field in the ``.changes``
+file (see :ref:`s-f-Closes`).
 
 The maintainer name and email address used in the changelog should be
 the details of the person who prepared this release of the package. They
@@ -860,10 +860,19 @@ should not exist a file ``debian/patches/foo.series`` for 
any ``foo``.
 
/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
 
-   Then all of the bug numbers listed will be closed by the archive
+   That is: The string should consist of the word ``closes:`` followed by
+   a comma-separated list of bug numbers. Bug numbers may be preceded by
+   the word ``bug`` and/or a ``#`` sign, as in
+   ``Closes: 42, bug#43, #44, bug 45``.
+   
+   The list of bug numbers may span multiple lines.
+
+   All of the bug numbers listed will be closed by the archive
maintenance software (``dak``) using the version of the changelog
entry.
 
+   The words ``closes:`` and ``bug`` are not case sensitive.
+
 .. [#]
In the case of a sponsored upload, the uploader signs the files, but
the changelog maintainer name and address are those of the person who
]]]

Cheers,

Daniel

Bug#953915: samba: Build-Depends on unused libattr1-dev

[Guillem Jover]

Hi!

On Sun, 2020-03-15 at 08:40:10 +1300, Andrew Bartlett wrote:
> On Sat, 2020-03-14 at 19:26 +0100, Guillem Jover wrote:
> > Source: samba
> > Source-Version: 2:4.11.5+dfsg-1
> > Severity: minor

> > This package used to use libattr for its xattr support, but got
> > switched to use the native support from glibc, but the Build-Depends
> > got left behind.
> 
> If so, upstream's bootstrap package list also needs to be updated, see
> bootstrap/config.py
> 
> Do you know at what Samba or OS version libattr stopped being needed?
> 
> It would be incredibly awesome if someday we could tie these together.

It looks like glibc started providing these syscalls in version 2.3.
I'm not sure when samba added support for these native calls.

Thanks,
Guillem

Bug#953284: RM: dosemu -- ROM; abandoned upstream

[Guillem Jover]

Hi!

On Sat, 2020-03-14 at 14:07:34 -0700, Kees Cook wrote:
> On Sat, Mar 14, 2020 at 06:56:30PM +, Scott Kitterman wrote:
> > On March 14, 2020 12:14:48 PM UTC, Guillem Jover  wrote:
> > >On Fri, 2020-03-06 at 20:43:05 -0800, Kees Cook wrote:
> > >> Package: ftp.debian.org
> > >> Severity: normal
> > >
> > >This seems to have continued by upstream, at least, in spirit at
> > >, which seems rather active.
> > 
> > It describes itself as an entirely new project with the same goals,
> > so my assumption is that it's existence shouldn't block this rm.
> > If someone wants to package it, it should be a new package anyway.
> 
> That was my thinking as well. And dosemu isn't even present in the last
> stable...

Sorry, I didn't mean that note as an objection. I just noticed the
removal on aptitude and used deb-why-removed to get more details. Once
I found the continuation project, I wanted to note it down in case
someone else stumbles on this too.

Thanks,
Guillem

Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc

[Sandro Tosi]

Source: xapian-bindings
Severity: important

Hello,
from what i can see, xapian-bindings builds its documentation twice, one for the
python2 bindings (and install that in bin:python-xapian) and one for the python3
bindings (and install that in bin:python3-xapian).

this is usually un-necessary, and the convention is to create a separate package
to contain the documentation, in this case python-xapian-doc. So please split
out such a package to contain the documentation for the python bindings in a
single place, and that the same time, please only use python3-sphinx to build
the documentation.

This will help us in reducing the reverse dependencies of bin:python-sphinx, so
that we can introduce a python3-only sphinx version in unstable.

Thanks,
Sandro

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#953880: Issue confirmed and possible workaround

[Stefano Gatti]

I have the same problem too.

Anyway I found the following report:

https://gitlab.gnome.org/GNOME/gimp/issues/4490

I tried to delete the file:

/usr/lib/gimp/2.0/plug-ins/pagecurl/pagecurl

and Gimp seems to work correctly.

Regards,
Stefano

Bug#953284: RM: dosemu -- ROM; abandoned upstream

[Kees Cook]

On Sat, Mar 14, 2020 at 06:56:30PM +, Scott Kitterman wrote:
> 
> 
> On March 14, 2020 12:14:48 PM UTC, Guillem Jover  wrote:
> >Hi!
> >
> >On Fri, 2020-03-06 at 20:43:05 -0800, Kees Cook wrote:
> >> Package: ftp.debian.org
> >> Severity: normal
> >
> >This seems to have continued by upstream, at least, in spirit at
> >, which seems rather active.
> >
> >Thanks,
> >Guillem
> 
> It describes itself as an entirely new project with the same goals,
> so my assumption is that it's existence shouldn't block this rm.
> If someone wants to package it, it should be a new package anyway.

That was my thinking as well. And dosemu isn't even present in the last
stable...

-- 
Kees Cook@debian.org

Bug#953832: cannot allocate memory in static TLS block

[Sergio Durigan Junior]

On Saturday, March 14 2020, Andreas Tille wrote:

> On Fri, Mar 13, 2020 at 11:09:31PM +0100, Paul Gevers wrote:
>> 
>> raise RuntimeError(('Could not find drmaa library.  Please specify
>> its ' +
>> RuntimeError: Could not find drmaa library.  Please specify its full
>> path using the environment variable DRMAA_LIBRARY_PATH
>
> I've fixed this in Git.  Unfortunately I get a new issue when importing
> drmaa
>
> $ python3
> Python 3.7.6 (default, Jan 19 2020, 22:34:52) 
> [GCC 9.2.1 20200117] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import drmaa
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py",
>  line 65, in 
> from .session import JobInfo, JobTemplate, Session
>   File 
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py", 
> line 39, in 
> from drmaa.helpers import (adapt_rusage, Attribute, 
> attribute_names_iterator,
>   File 
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py", 
> line 36, in 
> from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
>   File 
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py",
>  line 58, in 
> _lib = CDLL(libpath, mode=RTLD_GLOBAL)
>   File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__
> self._handle = _dlopen(self._name, mode)
> OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory 
> in static TLS block
>
>
> Any help would be welcome

This is an issue with jemalloc's handling of the TLS model when being
dlopened..  See:

  https://github.com/jemalloc/jemalloc/issues/1237

The recommended way to build a libjemalloc that is suitable for being
dlopened is to use '--disable-initial-exec-tls' when building it.  Take
a look at the INSTALL.md file, and look for this option:

  https://github.com/jemalloc/jemalloc/blob/dev/INSTALL.md

There is a way to workaround this bug by doing an LD_PRELOAD of
libjemalloc when invoking python, but this will only mask the problem
and we can't expect users to do/know this.

The way I see it, you can try to convince jemalloc's maintainer to
enable that flag.

BTW, the reason 'find_library' can't find drmaa's library is because the
.so is being installed in a non-standard directory.  I don't know why
the package was made like this, though.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#953857: lintian: t/tags/odd-inputs/strings-elf-detection/eval/literal fails on ubuntu

[Chris Lamb]

Hi Dimitri,

> I've tried to find a few places where Package-Type is used, and regexp
> hardcodes .deb pattern, but tweaking all of those to dd?eb did make
> the test case pass.

Can you provide a patch of these changes? I note your other patch in a
later mail that removes the assertions from the testsuite but this
would always be a Ubuntu-specific change and having a minimal delta
between the two projects would always be prefered.


Regards,

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

Bug#882584: Found the salsa package

[Mike Gabriel]

On  Sa 14 Mär 2020 00:36:21 CET, Martin Quinson wrote:


https://salsa.debian.org/debian-edu-pkg-team/openboard/

could we however modify this git repository to use git-buildpackage?
It makes things so much easier to maintain...

Thanks for your work,
Mt


Sorry, no. I see myself in a constant process of removing more and  
more files from the upstream Git tag/tarball, because files are  
non-DFSG for this or that reason. I am not willing to pollute the  
salsa repo with these changes.


To get openboard on salsa built, these steps should work:

  $ git clone https://salsa.debian.org/debian-edu-pkg-team/openboard.git
  $ cd openboard
  $ debian/rules get-orig-source
  $ debuild -uc -us -S -Zxz -d
  $ dpkg-source -x openboard_.dsc
  $ cd openboard-
  $ debuild -uc -us

IIRC, the current version on the repo's master branch only works /  
builds well on Debian testing/unstable.


Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp_AMQuGfZrm.pgp
Description: Digitale PGP-Signatur

Bug#882584: Any progress on packaging openboard?

[Mike Gabriel]

Hi Martin,

On  Fr 13 Mär 2020 23:53:56 CET, Martin Quinson wrote:


Hello,

is there any progress in this packaging? Is the current package
somewhere on salsa where we could help?

I will need such a software with my students (due to the covid
outbreak), so I'm highly interested.

Thanks, Mt.


When packaging OpenBoard, I regularly find myself in non-DFSG hell.  
That's the main reason for regular stalls on the packaging progress  
(and lack of time for non-paid work).


Please take a look at package builds I provide to my customers:
http://packages.it-zukunft-schule.de/debian/pool/main/o/openboard/
http://packages.it-zukunft-schule.de/debian/pool/non-free/o/openboard/

I have provided Debian 9 + 10 builds there that stem from the salsa  
repo I maintain.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpKOV_s6dUaA.pgp
Description: Digitale PGP-Signatur

Bug#953948: libsnmp30: Dependency on libmariadb3

[Jan Novak]

Package: libsnmp30
Severity: normal

Dear Maintainer,

I have noticed during installation of libsnmp30 it depends on libmariadb3. This 
dependency is not present
neither in former release (stretch) nor following (sid). Can be this dependency 
removed to avoid installation
of unnecessary packages (only if it is really not necessary, of course)?

BR



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

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

Versions of packages libsnmp30 depends on:
ii  libc6 2.28-10
pn  libmariadb3   
ii  libpci3   1:3.5.2-1
ii  libperl5.28   5.28.1-6
ii  libsensors5   1:3.5.0-3
ii  libsnmp-base  5.7.3+dfsg-5
ii  libssl1.1 1.1.1d-0+deb10u2
ii  libwrap0  7.6.q-28
ii  zlib1g1:1.2.11.dfsg-1

libsnmp30 recommends no packages.

libsnmp30 suggests no packages.

Bug#918375: panic: runtime error: invalid memory address or nil pointer dereference

[Jan Šmíd]

Hi,

I am experiencing the same problem (I believe not only) on my virtual 
Test Server. Im using fully updated Debian Buster and Docker 18.09.1 in 
swarm mode with one node.


Im running portainer stack and sentry stack. Dockerd is experiencing 
segfault once every hour, contents of the syslog and daemon.log during 
the events looks like this:


Mar 14 19:34:27 test dockerd[4919]: 
time="2020-03-14T19:34:27.508519337+01:00" level=info msg="NetworkDB 
stats test(1ec3864d57d5) - netID:ti6u5zwusxi9k8oj1zgvf7ip9 
leaving:false ne

tPeers:1 entries:6 Queue qLen:0 netMsg/s:0"
Mar 14 19:34:27 test dockerd[4919]: 
time="2020-03-14T19:34:27.510138528+01:00" level=info msg="NetworkDB 
stats test(1ec3864d57d5) - netID:35o2po0o7ocb67lpuspp4z43z 
leaving:false ne

tPeers:1 entries:20 Queue qLen:0 netMsg/s:0"
Mar 14 19:34:27 test dockerd[4919]: 
time="2020-03-14T19:34:27.510539944+01:00" level=info msg="NetworkDB 
stats test(1ec3864d57d5) - netID:b78tw29emwufgr176bfnjpxb4 
leaving:false ne

tPeers:1 entries:6 Queue qLen:0 netMsg/s:0"
Mar 14 19:34:31 test dockerd[4919]: panic: runtime error: invalid 
memory address or nil pointer dereference
Mar 14 19:34:31 test dockerd[4919]: [signal SIGSEGV: segmentation 
violation code=0x1 addr=0x0 pc=0x558bf2785388]

Mar 14 19:34:31 test dockerd[4919]: goroutine 828 [running]:
Mar 14 19:34:31 test dockerd[4919]: 
github.com/armon/go-radix.recursiveWalk(0x0, 0xc00160ee08, 
0x558bf3929900)
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:519 
+0x28
Mar 14 19:34:31 test dockerd[4919]: 
github.com/armon/go-radix.recursiveWalk(0xc002b5d860, 0xc00160ee08, 
0xc00160ec00)
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525 
+0x7a
Mar 14 19:34:31 test dockerd[4919]: 
github.com/armon/go-radix.recursiveWalk(0xc001145320, 0xc00160ee08, 
0xc00160ec00)
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525 
+0x7a
Mar 14 19:34:31 test dockerd[4919]: 
github.com/armon/go-radix.recursiveWalk(0xc000a81380, 0xc00160ee08, 
0x19)
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525 
+0x7a
Mar 14 19:34:31 test dockerd[4919]: 
github.com/armon/go-radix.(*Tree).WalkPrefix(0xc000ab4e50, 
0xc003b6c6a0, 0x1a, 0xc00160ee08)
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:473 
+0xdb
Mar 14 19:34:31 test dockerd[4919]: 
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapTableEntries(0xc0041979e0)
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:396 
+0x3c5
Mar 14 19:34:31 test dockerd[4919]: 
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapState(0xc0041979e0)
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:362 
+0x2d
Mar 14 19:34:31 test dockerd[4919]: 
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapState-fm()
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:170 
+0x2c
Mar 14 19:34:31 test dockerd[4919]: 
github.com/docker/libnetwork/networkdb.(*NetworkDB).triggerFunc(0xc0041979e0, 
0x12a05f200, 0xc001123e60, 0xc000ab52a0)
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:256 
+0x10a
Mar 14 19:34:31 test dockerd[4919]: created by 
github.com/docker/libnetwork/networkdb.(*NetworkDB).clusterInit
Mar 14 19:34:31 test dockerd[4919]: 
#011/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:178 
+0x830

It's Johny

Bug#953947: debci: arm64 autopkgtest regularly times out

[Paul Gevers]

Source: debci
Version: 2.6
User: debian...@lists.debian.org
Usertags: timeout

Dear Antonio, myself and all,

Debci fails its own autopkgtest on arm64. Moreover, it regularly times out.

Can we please investigate the situation?

To avoid wasting lots of time on the ci.debian.net infrastructure, I
have add our own package to the ignore list for arm64.

Paul

https://ci.debian.net/data/autopkgtest/testing/arm64/d/debci/4053173/log.gz

autopkgtest [23:45:55]: test test-suite: [---
/tmp/autopkgtest-lxc.vflp3dij/downtmp/build.YMO/src/test/test_migration_tests.sh
autopkgtest [02:32:37]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.vflp3dij/downtmp/build.YMO/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.vflp3dij/downtmp/test-suite-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.vflp3dij/downtmp/test-suite-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.vflp3dij/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.vflp3dij/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=32; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.vflp3dij/downtmp/build.YMO/src/debian/tests/test-suite;
touch /tmp/autopkgtest-lxc.vflp3dij/downtmp/test-suite-stdout
/tmp/autopkgtest-lxc.vflp3dij/downtmp/test-suite-stderr;
/tmp/autopkgtest-lxc.vflp3dij/downtmp/build.YMO/src/debian/tests/test-suite
2> >(tee -a /tmp/autopkgtest-lxc.vflp3dij/downtmp/test-suite-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc.vflp3dij/downtmp/test-suite-stdout);"
(kind: test)
autopkgtest [02:32:37]: test test-suite: ---]



signature.asc
Description: OpenPGP digital signature

Bug#953944: crmsh: flaky autopkgtest that times out regularly: missing isolation-machine restriction?

[Valentin Vidić]

On Sat, Mar 14, 2020 at 09:25:33PM +0100, Paul Gevers wrote:
> I copied the output at the bottom of this report. All the failing tests
> that I inspected look like it.
> 
> I'll put your package on the ci.d.n ignore list until this bug is fixed.

Ok, but would it be possible to get a process list when the test
timeouts as I can't reproduce the problem locally using lxc?

-- 
Valentin

Bug#952347: Processed: reassign 952347 to libreoffice-dev, affects 952347

[Andreas Beckmann]

On 14/03/2020 12.52, Rene Engelhard wrote:
>> Which wouldn't really help here as stuff will still "FTBFS" if they only used
>> -core-nogui, but yeah, one can add this nevertheless.
> 
> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/f16f367fcee34e6036053d85e68fc2f53a07732f

Thanks. That should be sufficient to point someone encountering the
error into the right direction, and not blame libreoffice-dev ;-)

devscripts also does not depend on half the archive to satisfy the needs
of this plethora of scripts, but the few scripts you are interested in
will tell you what they are missing.


Andreas

PS: openclipart was just fixed by a QA upload ;-)

Bug#953946: rabbitmq-server fails to install on arm64 (in lxc)

[Paul Gevers]

Control: severity -1 important

Hi,

Hmm, it seems it was slightly too quick. There are runs where the
package installs correctly, so it seems this is related to the environment.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#953946: rabbitmq-server fails to install on arm64 (in lxc)

[Paul Gevers]

Package: rabbitmq-server
Version: 3.7.18-1
Severity: serious
X-Debbugs-CC: de...@packages.debian.org
Control: affects -1 debci
Justification: fails to install

Dear maintainer,

As part of the autopkgtest of debci, rabbitmq-server is installed.
However, the test fails on arm64 because the installation of
rabbitmq-server fails structurally.

E.g. from
https://ci.debian.net/data/autopkgtest/testing/arm64/d/debci/4413224/log.gz

Setting up rabbitmq-server (3.7.18-1) ...
Adding group `rabbitmq' (GID 109) ...
Done.
Adding system user `rabbitmq' (UID 107) ...
Adding new user `rabbitmq' (UID 107) with group `rabbitmq' ...
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
Not creating home directory `/var/lib/rabbitmq'.
Created symlink
/etc/systemd/system/multi-user.target.wants/rabbitmq-server.service →
/lib/systemd/system/rabbitmq-server.service.
Job for rabbitmq-server.service failed because the control process
exited with error code.
See "systemctl status rabbitmq-server.service" and "journalctl -xe" for
details.
invoke-rc.d: initscript rabbitmq-server, action "start" failed.
● rabbitmq-server.service - RabbitMQ Messaging Server
 Loaded: loaded (/lib/systemd/system/rabbitmq-server.service;
enabled; vendor preset: enabled)
 Active: activating (auto-restart) (Result: exit-code) since Sun
2020-03-01 15:21:33 UTC; 7ms ago
Process: 4504 ExecStart=/usr/sbin/rabbitmq-server (code=exited,
status=1/FAILURE)
   Main PID: 4504 (code=exited, status=1/FAILURE)
dpkg: error processing package rabbitmq-server (--configure):
 installed rabbitmq-server package post-installation script subprocess
returned error exit status 1
dpkg: dependency problems prevent configuration of autopkgtest-satdep:
 autopkgtest-satdep depends on rabbitmq-server; however:
  Package rabbitmq-server is not configured yet.

dpkg: error processing package autopkgtest-satdep (--configure):
 dependency problems - leaving unconfigured


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

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

Versions of packages rabbitmq-server depends on:
ii  adduser   3.118
ii  erlang-base   1:22.2.8+dfsg-1
ii  erlang-crypto 1:22.2.8+dfsg-1
ii  erlang-eldap  1:22.2.8+dfsg-1
ii  erlang-inets  1:22.2.8+dfsg-1
ii  erlang-mnesia 1:22.2.8+dfsg-1
ii  erlang-os-mon 1:22.2.8+dfsg-1
ii  erlang-parsetools 1:22.2.8+dfsg-1
ii  erlang-public-key 1:22.2.8+dfsg-1
ii  erlang-runtime-tools  1:22.2.8+dfsg-1
ii  erlang-ssl1:22.2.8+dfsg-1
ii  erlang-syntax-tools   1:22.2.8+dfsg-1
ii  erlang-tools  1:22.2.8+dfsg-1
ii  erlang-xmerl  1:22.2.8+dfsg-1
ii  locales-all   2.29-10
ii  logrotate 3.15.1-2
ii  lsb-base  11.1.0
ii  python3   3.7.5-3
ii  socat 1.7.3.3-2

rabbitmq-server recommends no packages.

rabbitmq-server suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#953098: xscreensaver: Crashes with XIO: fatal IO error

[Jamie Zawinski]

As far as I know, an XIO error means the X server dropped the connection to the 
xscreensaver client. So either the X server itself crashed, or it decided to 
disconnect xscreensaver for some unknown reason. 

If the client had done something wrong, X11-protocol-wise, this would have been 
a more verbose "X" error, not an "XIO" error.

Maybe this is the kernel OOM-killer shooting down random long-running 
processes, as it sometimes likes to do?

"Resource temporarily unavailable" sure sounds like it could be the X11 server 
trying to say that it ran out of memory.

Bug#951513: lintian: test failures in Ubuntu

[Gianfranco Costamagna]

Hello,

this seems to be the Ubuntu patch...

http://launchpadlibrarian.net/468998013/lintian_2.56.0_2.56.0ubuntu1.diff.gz

G.

On Mon, 17 Feb 2020 09:24:15 -0800 Felix Lechner  
wrote:
> Hi Gianfranco,
> 
> On Mon, Feb 17, 2020 at 8:57 AM Gianfranco Costamagna
>  wrote:
> >
> > Hello, looks like we are getting strange failures since some releases
> 
> Classification tags are now enabled for all tests. Details are in
> 
> 
> https://salsa.debian.org/lintian/lintian/commit/0a5668a89c3381bd9495c03cd2636175aec7997a
> 
> and many surrounding commits. The tags are not triggering (or not
> being shown). The ubuntu profile can suppress tags, but that does not
> seem to be the case here. I'll have to update my Ubuntu chroot and
> take a look.
> 
> > Do you know why we are hitting those?
> 
> At this point, no. It would be unusual, however, for such a
> malfunction to present only in a general false-positive test
> ('odd-inputs'). Most tests are specific to a particular check (and
> only run that check). They should show more specific failures. The
> affected checks are deb-format, control-files, and fields/vcs. Do you
> see any other test failures in
> debian/test-out/eval/tags/checks/$check?
> 
> The missing tag no-ctrl-scripts from the control-files check, in
> particular, looks like it could have been caused by the more recent
> 
> 
> https://salsa.debian.org/lintian/lintian/commit/767d86920c6213a255d0025d07dcdf34bdede6e5
> 
> Are you sure the tag no-ctrl-scripts did in fact disappear prior to
> version 2.53 (which is when that commit was released)?
> 
> > This happened since 2.49.0
> 
> Thank you for the information. It will be helpful when tracking down
> the issues raised.
> 
> Kind regards
> Felix Lechner
> 
> 

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Sean Whitton]

Hello,

On Sat 14 Mar 2020 at 08:09PM +00, Daniel Shahaf wrote:

> Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
>> -   ::
>> -
>> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
>> -
>> +   All of the bug numbers listed must be given on the same physical line
>> +   as the word ``closes:``.
>
> Is this newly-added sentence correct?
>
> Whether it correctly states the semantics of the regexp depends on
> whether the regexp is matched against the changelog entry as a single
> multiline string or line-by-line.  In the former case, the list of bug
> numbers would be allowed to span multiple lines, but in the latter case
> it wouldn't.
>
> Currently, the patch assumes all bug numbers should be on the same line,
> but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
> span multiple lines.  I'm guessing the syntax file is right and the patch 
> should
> be changed?

In PCREs \s matches the newline character so I believe your text is
incorrect.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Sean Whitton]

Hello,

On Sat 14 Mar 2020 at 07:50PM +00, Daniel Shahaf wrote:

> What shape would this take?  Would the Perl definition be authoritative
> and the English one informative, or vice versa?  (Or something else
> altogether?)

Well, firstly, we're talking about the contents of a footnote here, so
the text is not normative.  Thus I guess the authoritative version is
the implementation in dak.

In terms of preparing your patch, I would like to suggest that you give
the perl first and then maybe say "which is roughly equivalent to ..."
and then include your English.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#953945: phppgadmin: CVE-2019-10784

[Salvatore Bonaccorso]

Source: phppgadmin
Version: 7.12.1+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/phppgadmin/phppgadmin/issues/94

Hi,

The following vulnerability was published for phppgadmin. For tracking
this issue Emilio did report it to [1]. So far there is no upstream
solution.

CVE-2019-10784[0]:
| phppgadmin through 7.12.1 allows sensitive actions to be performed
| without validating that the request originated from the application.
| One such area, "database.php" does not verify the source of an HTTP
| request. This can be leveraged by a remote attacker to trick a logged-
| in administrator to visit a malicious page with a CSRF exploit and
| execute arbitrary system commands on the server.


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-2019-10784
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10784
[1] https://github.com/phppgadmin/phppgadmin/issues/94
[2] https://snyk.io/vuln/SNYK-PHP-PHPPGADMINPHPPGADMIN-543885

Regards,
Salvatore

Bug#953379: gnome-subtitles: Please make another source-only upload to allow testing migration

[Tiago Bortoletto Vaz]

Hi Boyuan,

I've uploaded a 1.6-2 source-only version, thanks for reporting.

Pedro, can you consider this issue for next gnomesubititles release?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948437

Let me know if you open an issue for that on gnomesubititles gitlab, then I add
a proper tag at Debian BTS.

Bests,

On Sun, Mar 08, 2020 at 02:54:10PM -0400, Boyuan Yang wrote:
> Source: gnome-subtitles
> Version: 1.6-1
> Severity: important
> X-Debbugs-CC: ti...@debian.org
> 
> Hi Tiago,
> 
> Thanks for updating gnome-subtitles to the new release. However, the latest
> upload of gnome-subtitles was not a source-only upload; this means that the
> new version will not be able to migrate to Testing.
> 
> Please make another source-only upload to allow testing migration. For
> details, please see https://wiki.debian.org/SourceOnlyUpload .
> 
> Also I would be very much appreciated if https://bugs.debian.org/948437 can be
> solved soon.
> 
> -- 
> Best Regards,
> Boyuan Yang

Bug#953944: crmsh: flaky autopkgtest that times out regularly: missing isolation-machine restriction?

[Paul Gevers]

Source: crmsh
Version: 4.1.0-4
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky timeout

Dear maintainer(s),

I am currently going through the list [1] of packages that time out on
our ci.debian.net infrastructure. crmsh is listed so I checked its
history. The autopkgtest of your package seems flaky as it sometimes
passes (in several minutes) but regularly fails due to a timeout of the
autopkgtest. On top of that, it seems your doing something inside the
test that regularly breaks our infrastructure (which of course shouldn't
be possible, but there are bugs everywhere). I am wondering if the test
should declare the isolation-machine restriction.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests. Please fix the test to be more robust, or if I'm correct about
the isolation requirement, please add the appropriate restriction.

I copied the output at the bottom of this report. All the failing tests
that I inspected look like it.

I'll put your package on the ci.d.n ignore list until this bug is fixed.

Paul

[1] https://ci.debian.net/status/slow/

https://ci.debian.net/data/autopkgtest/unstable/amd64/c/crmsh/4554615/log.gz

autopkgtest [10:21:26]: test pacemaker-cluster-init.sh:
[---
+ ulimit -H -l unlimited
+ ufw status
Status: inactive
+ service corosync stop
+ crm cluster init --yes --name=autopkgtest --unicast
autopkgtest [13:08:06]: ERROR: timed out on command "su -s /bin/bash
root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.5xjzqfle/downtmp/build.IhJ/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.5xjzqfle/downtmp/pacemaker-cluster-init.sh-artifacts";
export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.5xjzqfle/downtmp/pacemaker-cluster-init.sh-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.5xjzqfle/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.5xjzqfle/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export
AUTOPKGTEST_NORMAL_USER=debci; export ADT_NORMAL_USER=debci; chmod +x
/tmp/autopkgtest-lxc.5xjzqfle/downtmp/build.IhJ/src/debian/tests/pacemaker-cluster-init.sh;
touch
/tmp/autopkgtest-lxc.5xjzqfle/downtmp/pacemaker-cluster-init.sh-stdout
/tmp/autopkgtest-lxc.5xjzqfle/downtmp/pacemaker-cluster-init.sh-stderr;
/tmp/autopkgtest-lxc.5xjzqfle/downtmp/build.IhJ/src/debian/tests/pacemaker-cluster-init.sh
2> >(tee -a
/tmp/autopkgtest-lxc.5xjzqfle/downtmp/pacemaker-cluster-init.sh-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.5xjzqfle/downtmp/pacemaker-cluster-init.sh-stdout);" (kind:
test)
autopkgtest [13:08:06]: test pacemaker-cluster-init.sh:
---]
autopkgtest [13:08:06]: test pacemaker-cluster-init.sh:  - - - - - - - -
- - results - - - - - - - - - -
pacemaker-cluster-init.sh FAIL timed out
autopkgtest [13:08:06]:  summary
command1 PASS
command2 PASS
command3 PASS
utils.sh PASS
testsuite.sh FAIL non-zero exit status 1
pacemaker-basic-resource.sh PASS
pacemaker-node-status.sh PASS
pacemaker-cluster-init.sh FAIL timed out
: failure: ['sudo', 'timeout', '600', 'lxc-stop',
'--quiet', '--kill', '--name', 'ci-074-725c475b'] failed (exit status
124, stderr '')
autopkgtest [13:18:06]: ERROR: autopkgtest
: error cleaning up:

autopkgtest [13:18:06]: ERROR: testbed failure: unexpected eof from the
testbed



signature.asc
Description: OpenPGP digital signature

Bug#943190: mydumper: diff for NMU version 0.9.5-1.1

[Sandro Tosi]

Control: tags 943190 + patch


Dear maintainer,

I've prepared an NMU for mydumper (versioned as 0.9.5-1.1). The diff
is attached to this message.

Regards.

diff -Nru mydumper-0.9.5/debian/changelog mydumper-0.9.5/debian/changelog
--- mydumper-0.9.5/debian/changelog	2018-12-19 04:17:53.0 -0500
+++ mydumper-0.9.5/debian/changelog	2020-03-14 16:15:00.0 -0400
@@ -1,3 +1,10 @@
+mydumper (0.9.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build doc with python3-sphinx; Closes: #943190
+
+ -- Sandro Tosi   Sat, 14 Mar 2020 16:15:00 -0400
+
 mydumper (0.9.5-1) unstable; urgency=medium
 
   * New upstream release (Closes: #897913)
diff -Nru mydumper-0.9.5/debian/control mydumper-0.9.5/debian/control
--- mydumper-0.9.5/debian/control	2017-01-17 19:05:46.0 -0500
+++ mydumper-0.9.5/debian/control	2020-03-14 16:08:02.0 -0400
@@ -2,7 +2,7 @@
 Section: database
 Priority: extra
 Maintainer: Mateusz Kijowski 
-Build-Depends: debhelper (>= 9.0.0), cmake, quilt, default-libmysqlclient-dev, libglib2.0-dev, libpcre3-dev, zlib1g-dev, python-sphinx (>= 1.0.7+dfsg), python-docutils, libatomic1
+Build-Depends: debhelper (>= 9.0.0), cmake, quilt, default-libmysqlclient-dev, libglib2.0-dev, libpcre3-dev, zlib1g-dev, python3-sphinx, python3-docutils, libatomic1
 Standards-Version: 3.9.8
 Homepage: https://github.com/maxbube/mydumper
 #Vcs-Git: git://git.debian.org/collab-maint/mydumper.git

Bug#951911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, 14 Mar 2020 19:57 +00:00:
> ...

Sorry for the noise!  I typo'd the bug number in the To: header ☹

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> -   ::
> -
> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> -
> +   All of the bug numbers listed must be given on the same physical line
> +   as the word ``closes:``.

Is this newly-added sentence correct?

Whether it correctly states the semantics of the regexp depends on
whether the regexp is matched against the changelog entry as a single
multiline string or line-by-line.  In the former case, the list of bug
numbers would be allowed to span multiple lines, but in the latter case
it wouldn't.

Currently, the patch assumes all bug numbers should be on the same line,
but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
span multiple lines.  I'm guessing the syntax file is right and the patch should
be changed?

Cheers,

Daniel

Bug#908845: debhelper: Remove dh_gconf in bullseye

[Thorsten Glaser]

Niels Thykier dixit:

>You can work around this in rs by using "--buildsystem=none" instead of
>"-Snone".

Oh, okay. Thanks!

Have a nice weekend,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Bug#953943: chake: autopkgtest failure: times out infinite loop: Depends: chef-zero (>= 13) but it is not going to be installed

[Paul Gevers]

Source: chake
Version: 0.20-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression timeout

Dear maintainers,

The autopkgtest of your package recently started to time out after 2:47
hours. I copied some of the output at the bottom of this report. Your
test fails to install a package and tries over and over and over and
over and over . again.

Please fix your test to stop trying at some point.

These kind of timeouts are bad for our infrastructure. I'll add your
package to our ignore-list.

Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/c/chake/4466622/log.gz

autopkgtest [15:50:18]: test smoke-test: [---
+ cd /tmp/autopkgtest-lxc.tnrru_g4/downtmp/autopkgtest_tmp
+ mkdir config
+ cd config
+ chake init
[create] nodes.yaml
[ mkdir] nodes.d/
[create] config.rb
[ mkdir] config/roles
[ mkdir] cookbooks/basics/recipes/
[create] cookbooks/basics/recipes/default.rb
[create] Rakefile
+ set +x
+ rake nodes
autopkgtest-unstable-amd64   local
+ rc=0
+ [ 0 -lt 10 ]
+ rake
mkdir -p tmp/chake
chmod 755 tmp/chake/bootstrap-autopkgtest-unstable-amd64
scp tmp/chake/bootstrap-autopkgtest-unstable-amd64
/tmp/.chake-bootstrap.root
autopkgtest-unstable-amd64: $ sudo /tmp/.chake-bootstrap.root
autopkgtest-unstable-amd64
E: Unable to correct problems, you have held broken packages.
rake aborted!
Chake::Backend::CommandFailed: autopkgtest-unstable-amd64: FAILED with
exit status 100

Tasks: TOP => default => converge => converge:autopkgtest-unstable-amd64
=> bootstrap:autopkgtest-unstable-amd64
(See full trace by running task with --trace)
autopkgtest-unstable-amd64: Hit:1 http://deb.debian.org/debian unstable
InRelease
autopkgtest-unstable-amd64: Hit:2 http://deb.debian.org/debian-debug
unstable-debug InRelease
autopkgtest-unstable-amd64: Hit:3
http://incoming.debian.org/debian-buildd buildd-unstable InRelease
autopkgtest-unstable-amd64: Reading package lists...
autopkgtest-unstable-amd64: Reading package lists...
autopkgtest-unstable-amd64: Building dependency tree...
autopkgtest-unstable-amd64: Reading state information...
autopkgtest-unstable-amd64: Some packages could not be installed. This
may mean that you have
autopkgtest-unstable-amd64: requested an impossible situation or if you
are using the unstable
autopkgtest-unstable-amd64: distribution that some required packages
have not yet been created
autopkgtest-unstable-amd64: or been moved out of Incoming.
autopkgtest-unstable-amd64: The following information may help to
resolve the situation:
autopkgtest-unstable-amd64:
autopkgtest-unstable-amd64: The following packages have unmet dependencies:
autopkgtest-unstable-amd64: chef : Depends: chef-zero (>= 13) but it is
not going to be installed
autopkgtest-unstable-amd64: Depends: ohai (>= 13) but it is not going to
be installed
+ echo Retrying in 10 seconds



signature.asc
Description: OpenPGP digital signature

Bug#951911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00:
> -   ::
> -
> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
> -
> +   All of the bug numbers listed must be given on the same physical line
> +   as the word ``closes:``.

Is this newly-added sentence correct?

Whether it correctly states the semantics of the regexp depends on
whether the regexp is matched against the changelog entry as a single
multiline string or line-by-line.  In the former case, the list of bug
numbers would be allowed to span multiple lines, but in the latter case
it wouldn't.

Currently, the patch assumes all bug numbers should be on the same line,
but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to
span multiple lines.  I'm guessing the syntax file is right and the patch should
be changed?

Cheers,

Daniel

Bug#953915: samba: Build-Depends on unused libattr1-dev

[Andrew Bartlett]

On Sat, 2020-03-14 at 19:26 +0100, Guillem Jover wrote:
> Source: samba
> Source-Version: 2:4.11.5+dfsg-1
> Severity: minor
> 
> Hi!
> 
> This package used to use libattr for its xattr support, but got
> switched to use the native support from glibc, but the Build-Depends
> got left behind.

If so, upstream's bootstrap package list also needs to be updated, see
bootstrap/config.py

Do you know at what Samba or OS version libattr stopped being needed?

It would be incredibly awesome if someday we could tie these together.

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Daniel Shahaf]

Sean Whitton wrote on Sat, 14 Mar 2020 19:06 +00:00:
> Hello Daniel,
> 
> On Sat 14 Mar 2020 at 06:14PM +00, Daniel Shahaf wrote:
> 
> > The documentation of the "Closes: #NN" changelog syntax describes
> > the syntax in terms of a Perl regular expression.  However, not all
> > readers know Perl.  I suggest to describe the semantics in English,
> > in addition to or instead of the description in Perl.
> 
> How about including both the Perl and the English, to make things easier
> for the maximum number of people?

Sure, we could do that.

What shape would this take?  Would the Perl definition be authoritative
and the English one informative, or vice versa?  (Or something else
altogether?)

I think both options are workable, and I have no preference between them.

Cheers,

Daniel

> Removing the Perl strikes me as deleting something which could be very
> useful to someone (e.g. if they're writing a script of some kind).

Bug#908845: debhelper: Remove dh_gconf in bullseye

[Niels Thykier]

Thorsten Glaser:
> Package: debhelper
> Version: 12.9
> Followup-For: Bug #908845
> 
> I’m getting this warning during a package build:
> 
> dh_gconf: warning: Please migrate to dh_installgsettings; gconf + dh_gconf is 
> scheduled for removal.
> 
> It’s clearly dh7-caused as I don’t use gconf at all…
> 
> 
> [...]

Hi Thorsten,

You can work around this in rs by using "--buildsystem=none" instead of
"-Snone".


The root of the issue is that the optimization in dh to skip helpers is
disabled when short options are used (notably due bundling being allowed
but not identifiable).
  In the concrete case, dh should have been able to skip dh_gconf but I
have not bothered implemented in it given the trivial work around.

~Niels

Bug#949766: task-sinhala-desktop: Please replace obsolete metapackage fonts-noto-hinted with real packages

[Holger Wansing]

Control: tags -1 + pending


Boyuan Yang  wrote:
> Package: task-sinhala-desktop
> Version: 3.58
> Severity: normal
> 
> Dear tasksel maintainers,
> 
> Currently package task-sinhala-desktop depends on fonts-noto-hinted, which is
> an obsolete metapackage of Noto Fonts. Please replace it with fonts-noto-core
> and fonts-noto-ui-core. Thanks!

Committed in git.
Tagging this bug as pending


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#953942: jack: should this package be removed?

[Sandro Tosi]

Package: jack
Severity: serious

Hello,
I believe this package should be removed:

* python2-only
* no upstream release since 2004 (!) or svn update since  2005 (!)
* it's keeping several python2 modules in debian that could be dropped if jack
  is removed too
* several alternatives exist that are much more populare than jack

if i dont hear back within a week with a good reason to keep this package, i'll
file for its removal.

Regards,
Sandro

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages jack depends on:
pn  cdparanoia | cdda2wav   
ii  python  2.7.16-1
pn  python-cddb 
pn  python-eyed3
ii  python-mutagen  1.40.0-2
ii  python-pyvorbis 1.5-5
ii  sensible-utils  0.0.12
pn  vorbis-tools | flac | lame  

jack recommends no packages.

jack suggests no packages.

Bug#755267: [heimdall-flash] Debian build not work

[Nicholas D Steeves]

Hi Roman,

On Sat, Jul 19, 2014 at 04:21:30PM +0400, Roman V. Nikolaev wrote:
> Package: heimdall-flash
> Version: 1.4.0-2
> Severity: normal
> 
> --- Please enter the report below this line. ---
> 
> I install package from repo and get error:
> 
> sudo heimdall flash --RECOVERY recovery-clockwork-6.0.4.4-jfltexx.img
> --no-reboot
> Heimdall v1.4.0
>
[snip]
> Initialising connection...
> Detecting device...
> ERROR: Failed to detect compatible download-mode device.
> 
> Then I get from upstream:
> 
> https://bitbucket.org/benjamin_dobell/heimdall/downloads/debian7-heimdall_1.4.0-0_amd64.deb
> 
> Upstream version work good:
> 
> sudo heimdall flash --RECOVERY recovery-clockwork-6.0.4.4-jfltexx.img
> --no-reboot
> Heimdall v1.4.0
> 
[snip]
> PIT file download successful.
> 
> Uploading RECOVERY
> 100%
> RECOVERY upload successful
> 
> Ending session...
> Releasing device interface...
> Re-attaching kernel driver...
> 
> Please fix bug
> 

I have salvaged heimdall-flash and have uploaded 1.4.2+dfsg-1, which
hopefully fixed this bug.  Are you able to confirm that it works,
and/or would you like to close this bug at this time?

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#880107: heimdall-flash: cannot flash RECOVERY on Samsung Note 3 (SM-N9005, hlte)

[Nicholas D Steeves]

Hi Thorsten,

On Sun, Oct 29, 2017 at 02:52:34PM +, Thorsten Glaser wrote:
> Package: heimdall-flash
> Version: 1.4.1-2+b1
> Severity: normal
> Tags: fixed-upstream
> 
> I get the dreaded “ERROR: Protocol initialisation failed!”
> and “libusb error -7” when trying to update TWRP Recovery
> on a used Note 3 device.
> 
> A self-compiled git snapshot cloned from upstream works,
> at commit 9bcc42da350bd2e1766980bcb77d806a82d56a1d, so
> updating the package should fix this.
> 

I have salvaged heimdall-flash and have uploaded 1.4.2+dfsg-1, which
presumably contains this commit.  Are you able to confirm that it
works, and/or would you like to close this bug at this time?

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#953941: igraph - Incomplete debian/copyright

[Bastian Blank]

Source: igraph
Version: 0.8.0-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: ftpmas...@debian.org

debian/copyright on igraph is incomplete.  Examples:
- src/drl_layout_3d.cpp (BSD-3)
- src/CHOLMOD/Modify/cholmod_rowdel.c (Timothy A. Davis)

Please verify the whole copyright status.

Bastian

-- 
Bones: "The man's DEAD, Jim!"

Bug#953939: bamtools: autopkgtest failure: times out on arm64

[Paul Gevers]

Source: bamtools
Version: 2.5.1+dfsg-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: fails-always timeout

Dear maintainers,

We recently started running autopkgtests on arm64 . Your package
bamtools has an autopkgtest, which is great, however, it fails on arm64
due to timeout after 2:47 hours. I copied some of the output at the
bottom of this report.

These kind of timeouts are bad for our infrastructure. I'll add your
package to our ignore-list on arm64. Please be aware that the release
team may soon consider failures on arm64 as RC as well.

Paul

https://ci.debian.net/data/autopkgtest/testing/arm64/b/bamtools/4521353/log.gz

utopkgtest [21:20:52]: test run-unit-test: [---
6
autopkgtest [00:07:33]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.i35a7vhj/downtmp/build.N9A/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.i35a7vhj/downtmp/run-unit-test-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.i35a7vhj/downtmp/run-unit-test-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.i35a7vhj/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.i35a7vhj/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=32; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.i35a7vhj/downtmp/build.N9A/src/debian/tests/run-unit-test;
touch /tmp/autopkgtest-lxc.i35a7vhj/downtmp/run-unit-test-stdout
/tmp/autopkgtest-lxc.i35a7vhj/downtmp/run-unit-test-stderr;
/tmp/autopkgtest-lxc.i35a7vhj/downtmp/build.N9A/src/debian/tests/run-unit-test
2> >(tee -a /tmp/autopkgtest-lxc.i35a7vhj/downtmp/run-unit-test-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.i35a7vhj/downtmp/run-unit-test-stdout);" (kind: test)
autopkgtest [00:07:33]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#953940: breezy: FTBFS with Python 3.8

[Graham Inggs]

Source: breezy
Version: 3.0.2-4
Severity: serious
Tags: ftbfs bullseye sid

Hi Maintainer

Your package FTBFS when built with Python 3.8 [1].
Please find what I hope is the relevant part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/history/amd64/breezy.html


FAIL: breezy.tests.test_export_pot.TestParseSource.test_strings_multiline
--
Traceback (most recent call last):
testtools.testresult.real._StringException: Empty attachments:
  log

Traceback (most recent call last):
  File "/build/1st/breezy-3.0.2/breezy/tests/test_export_pot.py", line
138, in test_strings_multiline
self.assertEqual(str_lines,
  File "/build/1st/breezy-3.0.2/breezy/tests/__init__.py", line 1315,
in assertEqual
raise AssertionError("%snot equal:\na = %s\nb = %s\n"
AssertionError: not equal:
a = {'ABC': 6, 'Start\n\nEnd\n': -2}
b = {'ABC': 6, 'Start\n\nEnd\n': 1}

--