Bug#954445: RFS: fuse-posixovl/1.2.20120215+gitf5bfe35-2 -- FUSE file system that provides POSIX functionality

[Seunghun Han]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fuse-posixovl"

 * Package name: fuse-posixovl
   Version : 1.2.20120215+gitf5bfe35-2
   Upstream Author : Jan Engelhardt , <
jeng...@computergmbh.de>
 * URL : https://sourceforge.net/projects/posixovl
 * License : GPL-2+
 * Vcs : 
https://sourceforge.net/p/posixovl/posixovl/ci/master/tree/
   Section : misc

It builds those binary packages:

  fuse-posixovl - FUSE file system that provides POSIX functionality

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

  https://mentors.debian.net/package/fuse-posixovl

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fuse-posixovl/fuse-posixovl_1.2.20120215+gitf5bfe35-2.dsc

Changes since the last upload:

   * New maintainer (Closes: #920107)
   * debian/compat
 - Update to 12
   * debian/control
 - Change to secure VCS addresses
 - Change to Standards version 4.5.0
 - Update to debhelper 12
   * debian/copyright
 - Fix insecure copyright format URI
   * debian/watch
 - Add an extra file extension (xz)
   * debian/manpages
 - Move from 1 to 8
   * Add upstream/metadata

Regards,

Bug#954448: nextcloud-desktop: Nextcloud client behaves different if started from menu, ~/.config/autostart or from fresh login

[Erich Minderlein]

Package: nextcloud-desktop
Version: 2.5.1-3+deb10u1
Severity: important

Dear Maintainer,



   * What led up to the situation?
   a) Notebook cold start and user login : icon is there and syncs with 
operation
   b) user logout  (nextcloud  is terminated) && user login : process nextcloud 
is  up, but no Icon
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 c) pkill nextcloud ; start nextcloud from terminal or desktop menu : 
Icon shows up and syncs with operation
   * What was the outcome of this action?
ox:~$ pkill nextcloud 
xx:~$ pstree | grep -B 11 nextcloud
case b)
xx:~$ pstree | grep -B 11 nextcloud
|-dbus-daemon
|-dhclient
|-gnome-keyring-d---3*[{gnome-keyring-d}]
|-gpm
|-irqbalance---{irqbalance}
|-lightdm-+-Xorg---3*[{Xorg}]
| |-lightdm-+-x-session-manag-+-caja---4*[{caja}]
| | | |-marco---3*[{marco}]
| | | 
|-mate-panel-+-mate-terminal-+-bash-+-grep
| | | ||   |
  `-pstree
| | | ||   
`-3*[{mate-terminal}]
| | | |
|-nextcloud---10*[{nextcloud}]
nextcloud attaches to the wrong process , if started via $HOME/.config/autostart

   * What outcome did you expect instead?
as in case a and c)
xx:~$ pstree | grep -B 11 nextcloud
|-lightdm-+-Xorg---3*[{Xorg}]
| |-lightdm-+-x-session-manag-+-caja---3*[{caja}]
| | | |-marco---3*[{marco}]
| | | 
|-mate-panel-+-mate-terminal-+-bash-+-grep
| | | ||   |
  `-pstree
| | | ||   
`-3*[{mate-terminal}]
| | | |`-3*[{mate-panel}]
| | | 
|-mate-power-mana---3*[{mate-power-mana}]
| | | 
|-mate-screensave---3*[{mate-screensave}]
| | | 
|-mate-settings-d---4*[{mate-settings-d}]
| | | 
|-mate-volume-con---2*[{mate-volume-con}]
| | | |-nextcloud---9*[{nextcloud}]

nextcloud-desktop shall be triggered by mate-panel, nor by xsession
manager.

-- 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-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nextcloud-desktop depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libnextcloudsync0 2.5.1-3+deb10u1
ii  libqt5concurrent5 5.11.3+dfsg1-1+deb10u3
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u3
ii  libqt5gui55.11.3+dfsg1-1+deb10u3
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-1+deb10u3
ii  libqt5positioning55.11.3+dfsg-2
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u3
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u3
ii  libqt5webchannel5 5.11.3-2
ii  libqt5webenginecore5  5.11.3+dfsg-2+deb10u1
ii  libqt5webenginewidgets5   5.11.3+dfsg-2+deb10u1
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1+deb10u3
ii  libqt5xml55.11.3+dfsg1-1+deb10u3
ii  libsqlite3-0  3.27.2-3
ii  libssl1.1 1.1.1d-0+deb10u2
ii  libstdc++68.3.0-6
ii  nextcloud-desktop-common  2.5.1-3+deb10u1
ii  nextcloud-desktop-l10n2.5.1-3+deb10u1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages nextcloud-desktop recommends:
pn  nextcloud-desktop-doc  

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#948364: audacity leaks memory and crashes

[Antoine Amarilli]

Hi,

Other important points that I just found:

- The leak only occurs under Wayland (I'm using sway and XWayland), not
  with Xorg (tested with i3)

- The leak only occurs when the Audacity window is visible. If it is not
  onscreen, the memory usage doesn't seem to grow.

(I reiterate that the problem doesn't occur when compiling Audacity
myself from source, so it's not a general issue of Audacity not working
under Wayland -- the problem must be with the specific versions of
libraries that I used, or with the packaging, compilation options,
etc.)

Besides, looking at audacity's memory with pmap, what changes when
memory gets allocated is that lines of the following form get added:

> 7f806403864037403740 rw-s- /memfd:gdk-wayland (deleted)

Best,

-- 
Antoine Amarilli



On Sat, Mar 21, 2020 at 06:56:45PM +0100, Antoine Amarilli wrote:
> Hi,
> 
> I am still having this bug as of today, which makes Audacity unusable. I
> compiled Audacity 2.3.3 from source and it doesn't seem to have the same
> problem.
> 
> So the problem may be in the Debian packaging, or in the use of
> different library versions than what I did.
> 
> Here is some information about my build:
> 
> $ ldd ./audacity 
> linux-vdso.so.1 (0x7ffe2415d000)
> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7f234d943000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f234d922000)
> libwx_gtk2u_html-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0 (0x7f234d643000)
> libwx_gtk2u_qa-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0 
> (0x7f234d414000)
> libwx_gtk2u_adv-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0 (0x7f234d026000)
> libwx_gtk2u_core-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0 (0x7f234c78c000)
> libwx_baseu_net-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0 (0x7f234c53e000)
> libwx_baseu-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 
> (0x7f234c09f000)
> libavcodec.so.58 => /usr/lib/x86_64-linux-gnu/libavcodec.so.58 
> (0x7f234ab0d000)
> libavformat.so.58 => /usr/lib/x86_64-linux-gnu/libavformat.so.58 
> (0x7f234a899000)
> libavutil.so.56 => /usr/lib/x86_64-linux-gnu/libavutil.so.56 
> (0x7f234a774000)
> libid3tag.so.0 => /usr/lib/x86_64-linux-gnu/libid3tag.so.0 
> (0x7f234a755000)
> libmad.so.0 => /usr/lib/x86_64-linux-gnu/libmad.so.0 (0x7f234a733000)
> libSoundTouch.so.1 => /usr/lib/x86_64-linux-gnu/libSoundTouch.so.1 
> (0x7f234a71c000)
> libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 
> (0x7f234a671000)
> libvorbisfile.so.3 => /usr/lib/x86_64-linux-gnu/libvorbisfile.so.3 
> (0x7f234a666000)
> libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 
> (0x7f234a638000)
> libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x7f234a42d000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f234a428000)
> libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 
> (0x7f2349fdc000)
> libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 
> (0x7f2349f25000)
> libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 
> (0x7f2349efe000)
> libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 
> (0x7f2349ea2000)
> libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 
> (0x7f2349d7b000)
> libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 
> (0x7f2349c82000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f2349c77000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
> (0x7f2349aaa000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2349965000)
> libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1 (0x7f2349939000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f234991d000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f234975d000)
> /lib64/ld-linux-x86-64.so.2 (0x7f234ec09000)
> libwx_baseu_xml-3.0.so.0 => 
> /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0 (0x7f234954d000)
> libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 
> (0x7f2349503000)
> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f23493c1000)
> libnotify.so.4 => /usr/lib/x86_64-linux-gnu/libnotify.so.4 
> (0x7f23493b7000)
> libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 
> (0x7f23493a5000)
> libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x7f2349285000)
> libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 
> (0x7f234907f000)
> libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x7f2349074000)
> libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 
> (0x7f234903b000)
> libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x7f2348dd2000)
> libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x7f2348d4e000)
> libz.so.1 => 

Bug#954023: stretch-pu: package amd64-microcode/3.20181128.1~deb9u1

[Adam D. Barratt]

Hi Henrique,

On Sun, 2020-03-15 at 21:37 +0100, Anton Gladky wrote:
> I have prepared an update for amd64-microcode for Debian Stretch,
> which fixes CVE-2017-5715. Please see an attached debdiff.
> 
> This is the newer upstream version, which fixes CVE-2017-5715.
> Security team marked this CVE for Stretch as  [1].

Do you have any input / thoughts on this proposed update?

This would pull stretch's amd64-microcode to the version that's
currently in stretch-backports and buster. That's an update for stretch
from 2016 -> 2018, but still behind unstable and testing, which have a
2019 package.

The complete set of package versions is currently:

amd64-microcode | 2.20160316.1~deb8u1 | oldoldstable/non-free  | source, 
amd64, i386
amd64-microcode | 3.20160316.3| oldstable/non-free | source, 
amd64, i386
amd64-microcode | 3.20181128.1~bpo9+1 | stretch-backports/non-free | source, 
amd64, i386
amd64-microcode | 3.20181128.1~deb8u1 | oldoldstable/updates/non-free | source, 
amd64, i386
amd64-microcode | 3.20181128.1| stable/non-free| source, 
amd64, i386
amd64-microcode | 3.20191218.1| testing/non-free   | source, 
amd64, i386
amd64-microcode | 3.20191218.1| unstable/non-free  | source, 
amd64, i386

Regards,

Adam

Bug#954458: reclass: diff for NMU version 1.4.1-3.1

[Sandro Tosi]

Package: reclass
Version: 1.4.1-3
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for reclass (versioned as 1.4.1-3.1). The diff
is attached to this message.

Regards.

diff -Nru reclass-1.4.1/debian/changelog reclass-1.4.1/debian/changelog
--- reclass-1.4.1/debian/changelog	2017-03-11 04:14:58.0 -0500
+++ reclass-1.4.1/debian/changelog	2020-03-21 18:01:01.0 -0400
@@ -1,3 +1,10 @@
+reclass (1.4.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop reclass-doc, to reduce reverse dependencies of python-sphinx
+
+ -- Sandro Tosi   Sat, 21 Mar 2020 18:01:01 -0400
+
 reclass (1.4.1-3) unstable; urgency=medium
 
   * Revert d/compat and standards update to allow stretch migration
diff -Nru reclass-1.4.1/debian/control reclass-1.4.1/debian/control
--- reclass-1.4.1/debian/control	2017-03-11 04:14:21.0 -0500
+++ reclass-1.4.1/debian/control	2020-03-21 17:58:44.0 -0400
@@ -6,7 +6,6 @@
 Build-Depends: debhelper (>= 8.9.7),
python,
python-setuptools,
-   python-sphinx,
python-yaml
 Standards-Version: 3.9.6
 XS-Python-Version: all
@@ -63,14 +62,3 @@
  allowed, well-defined, and encouraged), and piece together your infrastructure
  from smaller bits, eliminating redundancy and exposing all important
  parameters to a single location, logically organised.
-
-Package: reclass-doc
-Architecture: all
-Section: doc
-Depends: ${misc:Depends}, ${sphinxdoc:Depends}
-Description: reclass documentation
- reclass is an "external node classifier" (ENC) as can be used with automation
- tools, such as Puppet, Salt, and Ansible. It is also a stand-alone tool for
- merging data sources recursively.
- .
- This package provides the documentation for reclass.
diff -Nru reclass-1.4.1/debian/reclass-doc.docs reclass-1.4.1/debian/reclass-doc.docs
--- reclass-1.4.1/debian/reclass-doc.docs	2017-03-10 02:47:18.0 -0500
+++ reclass-1.4.1/debian/reclass-doc.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-doc/build/html
diff -Nru reclass-1.4.1/debian/reclass.manpages reclass-1.4.1/debian/reclass.manpages
--- reclass-1.4.1/debian/reclass.manpages	2017-03-10 02:47:18.0 -0500
+++ reclass-1.4.1/debian/reclass.manpages	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-doc/build/man/reclass.1
diff -Nru reclass-1.4.1/debian/rules reclass-1.4.1/debian/rules
--- reclass-1.4.1/debian/rules	2017-03-10 05:26:15.0 -0500
+++ reclass-1.4.1/debian/rules	2020-03-21 17:59:19.0 -0400
@@ -4,17 +4,11 @@
 #export DH_VERBOSE=1
 
 DH_BUILDSYSTEM_OPTION=--buildsystem=python_distutils
-DH_OPTIONS=--with python2,sphinxdoc $(DH_BUILDSYSTEM_OPTION)
+DH_OPTIONS=--with python2 $(DH_BUILDSYSTEM_OPTION)
 
 %:
 	dh $@ $(DH_OPTIONS)
 
-override_dh_sphinxdoc:
-	dh_sphinxdoc || :
-
-override_dh_auto_build:
-	PYTHONPATH=.. $(MAKE) -C doc man html
-
 override_dh_install:
 	dh_install
 	mv debian/tmp/usr/bin/reclass-* debian/reclass/usr/share/reclass
@@ -24,4 +18,3 @@
 
 override_dh_clean:
 	dh_clean -O$(DH_BUILDSYSTEM_OPTION)
-	$(MAKE) docsclean

Bug#939483: Python2 use in krb5

[Sandro Tosi]

Hey Sam,

On Mon, 11 Nov 2019 13:14:28 -0500 Sam Hartman  wrote:
> control: user debian-pyt...@lists.debian.org
> control: usertag -1 +py2keep
>
> Hi.
> The current version of krb5 depends on python2 at least for sphinx and
> other items in doc building.
> This will be fixed for the next upstream of krb5, which will be released
> within a year.
> So, we should be able to close this well within the bullseye time frame,
> but I think it is valuable to be able to retain the ability to build
> docs for krb5 meanwhile.
> It's not as simple as changing to the python3 sphinx (and other)
> dependencies.
> There are some plugins in the doc building process that are krb5
> specific and do not work with python2 in this version.

krb5 1.8 has been released in mid-February and it looks like the
documentation build system has been migrated to python3. Could you
please have a look at packaging this new version and switch over to
python3-sphinx and friends?

we're finally in the single digit number of rdeps for python-sphinx
and we're trying to get rid of it (so that we can introduce a new,
py3k-only, version that some packages already require).

let me know if helps is needed

Thanks,
Sandro

Bug#954429: [Pkg-javascript-devel] Bug#954429: Bug#954429: Bug#954429: Bug#954429: node-acorn: Please rename binary to node-acorn

[Jonas Smedegaard]

Quoting Xavier (2020-03-21 17:06:36)
> 
> 
> Le 21/03/2020 à 16:55, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-03-21 15:53:14)
> >> Le 21/03/2020 à 15:47, Jonas Smedegaard a écrit :
> >>> Quoting Xavier Guimard (2020-03-21 15:20:47)
>  node-acorn bu=inary has been renamed to node-debbundle-acorn. 
>  Most of our packages depends on node-acorn which is now a virtual 
>  package provided by node-debbundle-acorn. Versionned dependencies 
>  on virtual packages are known to cause problems, that's why I'd 
>  to see node-debbundle-acorn renamed to node-acorn.
> >>>
> >>> Which problems more specifically are you referring to?
> > 
> >> I had such problems in node-hawk reverse dependencies
> > 
> > Thanks for sharing _where_ you experienced problems.
> > 
> > Can you share details of _what_ the problems you experienced were?
> > 
> > Also helpful if you can share _when_ (time or version number) you 
> > experienced problems with node-hawk.

[ snipped quite from aptitude manual not specific to node-hawk ]

Thanks for sharing some documention details of how aptitude works.

What concrete problems did you experience in node-hawk, when?


 - Jonas

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

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

signature.asc
Description: signature

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Holger Wansing]

Control: severity -1 normal
Control: retitle -1 [d-i bullseye alpha2 i386] Configuring 'grub-installer' 
failed with error code 134
Control: tags -1 + unreproducible


Steve McIntyre  wrote:
> Hey Holger!
> 
> On Fri, Mar 20, 2020 at 01:35:24PM +0100, Holger Wansing wrote:
> >Steve McIntyre  wrote:
> >> 
> >> Hmmm. Can you try wiping the partition table in between tests?
> >
> >I already tried that on wednesday, with no success.
> >
> >However, today it does the trick! Success!
> >Curious, but installation completed fine.
> >
> >Will see, if I can reproduce it again...
> 
> ACK. I'm struggling to understand this otherwise.

Hmm, this is getting annoying:
while doing several test installs, I thought I had a path how to reproduce
the issue, but then suddenly it looked completely different than before.
So, that's something between "some portion of coincidence involved" and
"wow, not it looks like a hardware failure".

And since I was never able to reproduce the issue on amd64, it seems at
least to be a i386-only issue, and thus could be considered as a corner 
case...

Therefore reducing severity to normal and tagging as unreproducible
+ renaming to include the exact error message: 
"Configuring 'grub-installer' failed with error code 134"
(leaving this bug open for a while, other people with the same problem may
find it, and probably shade some light on it.)


Holger

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

Bug#953485: binaries uploaded

[Ivo De Decker]

Hi,

On Sat, Mar 21, 2020 at 02:43:19PM +0100, Adam Borowski wrote:
> I've uploaded binaries for amd64 arm64 armhf i386 (ie, arch in testing), so
> it should be done.
> 
> Apparently the package can't be autobuilt, so it's up to me and tarzeau to
> remember to upload the binaries the next time as well.  Oh well.

You should remove the "XS-Autobuild: yes" from the control file. Not only is
it incorrect (as the package apparently cannot be autobuilt on debian
infrastructure), but doing so will also trigger the
'source-only-upload-to-non-free-without-autobuild' lintian tag, which will
cause a source-only upload to be autorejected by dak if you forget to include
the binaries.

Cheers,

Ivo

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Steve McIntyre]

On Sat, Mar 21, 2020 at 05:46:03PM +0100, Holger Wansing wrote:
>Control: severity -1 normal
>Control: retitle -1 [d-i bullseye alpha2 i386] Configuring 'grub-installer' 
>failed with error code 134
>Control: tags -1 + unreproducible
>
>Steve McIntyre  wrote:
>> Hey Holger!
>> 
>> On Fri, Mar 20, 2020 at 01:35:24PM +0100, Holger Wansing wrote:
>> >Steve McIntyre  wrote:
>> >> 
>> >> Hmmm. Can you try wiping the partition table in between tests?
>> >
>> >I already tried that on wednesday, with no success.
>> >
>> >However, today it does the trick! Success!
>> >Curious, but installation completed fine.
>> >
>> >Will see, if I can reproduce it again...
>> 
>> ACK. I'm struggling to understand this otherwise.
>
>Hmm, this is getting annoying:
>while doing several test installs, I thought I had a path how to reproduce
>the issue, but then suddenly it looked completely different than before.
>So, that's something between "some portion of coincidence involved" and
>"wow, not it looks like a hardware failure".
>
>And since I was never able to reproduce the issue on amd64, it seems at
>least to be a i386-only issue, and thus could be considered as a corner 
>case...
>
>Therefore reducing severity to normal and tagging as unreproducible
>+ renaming to include the exact error message: 
>"Configuring 'grub-installer' failed with error code 134"
>(leaving this bug open for a while, other people with the same problem may
>find it, and probably shade some light on it.)

ACK. Thanks for continuing on with this - unreproducible bugs are the
worst... :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#954429: [Pkg-javascript-devel] Bug#954429: Bug#954429: Bug#954429: Bug#954429: node-acorn: Please rename binary to node-acorn

[Xavier]

Le 21/03/2020 à 17:55, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-03-21 17:06:36)
>>
>>
>> Le 21/03/2020 à 16:55, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-03-21 15:53:14)
 Le 21/03/2020 à 15:47, Jonas Smedegaard a écrit :
> Quoting Xavier Guimard (2020-03-21 15:20:47)
>> node-acorn bu=inary has been renamed to node-debbundle-acorn. 
>> Most of our packages depends on node-acorn which is now a virtual 
>> package provided by node-debbundle-acorn. Versionned dependencies 
>> on virtual packages are known to cause problems, that's why I'd 
>> to see node-debbundle-acorn renamed to node-acorn.
>
> Which problems more specifically are you referring to?
>>>
 I had such problems in node-hawk reverse dependencies
>>>
>>> Thanks for sharing _where_ you experienced problems.
>>>
>>> Can you share details of _what_ the problems you experienced were?
>>>
>>> Also helpful if you can share _when_ (time or version number) you 
>>> experienced problems with node-hawk.
> 
> [ snipped quite from aptitude manual not specific to node-hawk ]
> 
> Thanks for sharing some documention details of how aptitude works.
> 
> What concrete problems did you experience in node-hawk, when?
> 
>  - Jonas

Some package dependended on "node-hawk-* (>= xx.x)" provided by
node-hawk and debci machines reported a breakage.
Sadly node-hawk is broken now (waiting for nodejs 12) and I can't show a
concrete example.

Bug#954441: automat: please call python2 in autopkgtests

[Gianfranco Costamagna]

Source: automat
Version: 0.8.0-1
Severity: important
Tags: patch

Hello, please call python2 instead of python in autopkgtests, the python binary 
will be removed in the future

--- automat-0.8.0/debian/tests/unit-tests-2 2020-03-18 22:47:32.0 
+0100
+++ automat-0.8.0/debian/tests/unit-tests-2 2020-03-19 04:12:52.0 
+0100
@@ -1,4 +1,4 @@
 #!/bin/sh -e
 
 cd $AUTOPKGTEST_TMP
-python -m twisted.trial automat
+python2 -m twisted.trial automat


G.

Bug#954449: nmu: proftpd-dfsg_1.3.6c-2

[Hilmar Preusse]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hello,

in libc6 (>= 2.30) the libc6 stopped declaring there would be a stream
feature.  Hence the include file stropts.h was dropped.  The proftpd-dev
package must get aware of that change, hence we have to rebuild w/ libc (>=
2.30) installed.  Currently at least one proftp module package fails to
build due to this API change.

nmu proftpd-dfsg_1.3.6c-2 . ANY . unstable . -m "Rebuild against libc6 (>= 
2.30) to get rid of #include "

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

Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#954451: src:tox: Please remove python2 autopkgtests that use virtualenv

[Scott Kitterman]

Package: src:tox
Version: 3.13.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using FTBFS to cover autopkgtest failure as it is a rough
equivalent (package can't migrate to testing).

The python-virtualenv package can no longer support creation of python2
virtualenvs without external downloads, which are not allowed for
packages in Main.  The ipaddr module is no longer in Testing and is
required for this.  As a result, tox python2 autopkgtests now fail:

py2 create: /tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2
ERROR: invocation failed (exit code 1), logfile: 
/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/log/py2-1.log
== log start ===
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
  File 
"/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/__main__.py",
 line 16, in 
from pip._internal.cli.main import main as _main  # isort:skip # noqa
  File 
"/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/cli/main.py",
 line 10, in 
from pip._internal.cli.autocompletion import autocomplete
  File 
"/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/cli/autocompletion.py",
 line 9, in 
from pip._internal.cli.main_parser import create_main_parser
  File 
"/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/cli/main_parser.py",
 line 7, in 
from pip._internal.cli import cmdoptions
  File 
"/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/cli/cmdoptions.py",
 line 25, in 
from pip._internal.locations import USER_CACHE_DIR, get_src_prefix
  File 
"/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/locations.py",
 line 20, in 
from pip._internal.utils.compat import WINDOWS
  File 
"/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/utils/compat.py",
 line 29, in 
import ipaddr as ipaddress  # type: ignore
ImportError: No module named ipaddr

I'm happy to do an NMU to simply drop the tests if you would like.
Please let me know if you plan to take care of it.  I will probably NMU
in a week (including the NMU diff in this bug once I have it ready) if I
don't.

Thanks,

Scott K

Bug#953851: pymissile: should this package be removed?

[Moritz Mühlenhoff]

On Sun, Mar 15, 2020 at 02:15:00PM -0400, Sandro Tosi wrote:
> > While these are all good arguments for removal, I still got the hardware
> > and thus enjoy having the software to use it in Debian. :)
> >
> > But I realise that it need some porting to keep working, and lack the
> > spare time required to do it myself. :(
> 
> are you ok with removing this package now, and maybe reintroduce it
> later when it's been ported to python3?

I've filed an RM bug now.

Cheers,
Moritz

Bug#954452: RM: pymissile -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pymissile. It's dead upstream, depends on Python 2
and blocks the Py2 migration for other packages (urwid, pyusb)

Cheers,
Moritz

Bug#954378: tcpdump: Support pcapng captures wiht snaplen 524288

[Marc Finet]

On Sat, Mar 21, 2020 at 10:25 PM Romain Francoise  wrote:
> Thanks for the report. Wireshark has its own implementation of the
> PcapNg format, so it's not unexpected that it behaves differently than
> tcpdump.
>
> The fix is a bit too intrusive for a stable update, especially for a
> minor bug like this. I will simply do a buster backport of libpcap
> 1.9.1-2 from bullseye.
Fair enough.

> Can you share your modified test file? Thanks.
Hum, sure, I thought I attached it. Sorry.

Marc.


long-snaplen.pcapng
Description: application/pcapng

Bug#954456: dictclient: intention to remove

[Sandro Tosi]

Source: dictclient
Severity: serious
Tags: sid, bullseye

Hello,
this bug is to mark my intention to remove dictclient from debian:

* python2-only
* no real development in ~3 years
* debian specific (why?)
* no rdeps
* very low popcon

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

Bug#945015: only-branch only takes exact branch names

[gregor herrmann]

On Thu, 19 Mar 2020 10:44:06 +, Iain Lane wrote:

> > > So, please, Iain, send that merge request. Thanks!
> > The merge request exists, thanks Iain!
> > https://salsa.debian.org/kgb-team/kgb/-/merge_requests/7
> Ah yeah, I should have updated the bug.

No worries.
 
> > To me it looks good, and I especially appreciate the added tests.
> > Iain, I guess you tested the changes also with a test installation,
> > as discussed on IRC?
> I did, yes - and it seems to work as designed. Thanks for the initial
> review!

Great, thanks for the real-life tests.
 
> Hopefully once this is merged the "production" instances can be updated
> to use it? Then I can fix pkg-gnome's webhooks to not spam #debian-gnome
> :-).

Right, that would indeed make a lot sense :)
 


On Thu, 19 Mar 2020 15:26:17 +0200, Damyan Ivanov wrote:

> > Dam, I hope you have a moment to look at the changes as well.
> Looks good to me.

Thanks!
 
> The only things missing for me are:
> 
>  * addition of Iain in the copyright notices and debian/copyright
>  * addition of the new (build) dependencies to Build.PL
> 
> But I guess these can be made at release time as well.

Alright, I merged the patch, updated the copyright notices and
Build.PL and did a round of packaging polishing.

Dam, could you take another look and maybe release the thing (or I
can do it as well if you don't have time)?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Don McLean: He's Got You


signature.asc
Description: Digital Signature

Bug#954429: [Pkg-javascript-devel] Bug#954429: Bug#954429: Bug#954429: Bug#954429: Bug#954429: node-acorn: Please rename binary to node-acorn

[Jonas Smedegaard]

Quoting Xavier (2020-03-21 17:59:39)
>  Le 21/03/2020 à 15:47, Jonas Smedegaard a écrit :
> > Quoting Xavier Guimard (2020-03-21 15:20:47)
> >> node-acorn bu=inary has been renamed to node-debbundle-acorn. 
> >> Most of our packages depends on node-acorn which is now a 
> >> virtual package provided by node-debbundle-acorn. Versionned 
> >> dependencies on virtual packages are known to cause problems, 
> >> that's why I'd to see node-debbundle-acorn renamed to 
> >> node-acorn.
> >
> > Which problems more specifically are you referring to?

> Some package dependended on "node-hawk-* (>= xx.x)" provided by 
> node-hawk and debci machines reported a breakage.
> Sadly node-hawk is broken now (waiting for nodejs 12) and I can't show 
> a concrete example.

Thanks for those details.  Helpful.  Getting closer to something useful.

Which package depended versioned at some point in time on node-hawk-*?


 - Jonas

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

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

signature.asc
Description: signature

Bug#954335: lintian confuses Fortran and Modula-2 modules

[Alastair McKinstry]

On 20/03/2020 13:21, Matthias Klose wrote:
> On 3/20/20 2:15 PM, Felix Lechner wrote:
>> Hi Matthias,
>>
>> On Fri, Mar 20, 2020 at 5:57 AM Matthias Klose  wrote:
>>> so please differentiate between Fortran and Modula-2 modules.
>> I have had some issues differentiating gfortran modules (#948033). In
>> which folders do they usually reside, please?
>>
>> Also, why are they not all named md.gz, as in libcoarrays-dev?
> CCing Alastair. He's behind the Fortran policies.
>
> Currently Modula-2 modules can only be found in the lib*gm2 packages. Nothing
> else is packaged using Modula-2.

Fortran modules should be in either:

/usr/lib/$ARCH/fortran/$compiler_version

with $compiler_version currently either gfortran-mod-15 or flang-mod-34

or, the traditional include directories /usr/include/* o

The files *.md.gz are docs, (markdown format), not modules.


-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Bug#954429: [Pkg-javascript-devel] Bug#954429: Bug#954429: Bug#954429: Bug#954429: Bug#954429: node-acorn: Please rename binary to node-acorn

[Xavier]

Le 21/03/2020 à 18:27, Jonas Smedegaard a écrit :
> Quoting Jonas Smedegaard (2020-03-21 18:13:32)
>> Quoting Xavier (2020-03-21 17:59:39)
>>> Le 21/03/2020 à 15:47, Jonas Smedegaard a écrit :
 Quoting Xavier Guimard (2020-03-21 15:20:47)
> node-acorn bu=inary has been renamed to node-debbundle-acorn. 
> Most of our packages depends on node-acorn which is now a 
> virtual package provided by node-debbundle-acorn. Versionned 
> dependencies on virtual packages are known to cause problems, 
> that's why I'd to see node-debbundle-acorn renamed to 
> node-acorn.

 Which problems more specifically are you referring to?
>>
>>> Some package dependended on "node-hawk-* (>= xx.x)" provided by 
>>> node-hawk and debci machines reported a breakage. Sadly node-hawk is 
>>> broken now (waiting for nodejs 12) and I can't show a concrete 
>>> example.
>>
>> Thanks for those details.  Helpful.  Getting closer to something 
>> useful.
>>
>> Which package depended versioned at some point in time on node-hawk-*?
> 
> In case that helps jog your memory, I now located that node-hawk has 
> only ever provided one virtual package and only since 2019-09-05, so my 
> question can be narrowed down to this:
> 
> Which package depended versioned on node-hapi-hawk within the past 6-7 
> months?
> 
> 
>  - Jonas

Sorry, I was talking about node-hoek. Broken example with node-sntp.
node-hawk isn't broken, node-hoek is (needs nodejs 12)

Bug#950425: gparted 1.1.0

[Amr Ibrahim]

https://gitlab.gnome.org/GNOME/gparted/-/blob/master/NEWS


GParted 1.1.0   (2020-01-20)


Release Notes
-
  This release of GParted includes enhancements, bug fixes and language 
translation updates.

### Key changes include:

  * Fix error when moving locked LUKS-encrypted partition
  * Switch to faster minfo and mdir to read FAT16/32 usage
  * Calculate JFS size accurately
  * Recognise ATARAID members and detect their busy status

Bug Fixes
-
  * Fix test (dentry->d_name is invalidated by closedir...) (!41)
  * Fix error when moving locked LUKS-encrypted partition (#48, !44)
  * Add missing window title to Help Contents dialog (!45)
  * Switch to faster minfo and mdir to read FAT16/32 usage (#569921)
  * Whole device FAT32 file system reports device busy warning from mlabel (!46)
  * Fix "invalid argument for seek()" error on very small (<=40KiB) drives (#16)
  * Remain with CentOS 7 for GitLab CI (!48)
  * Add file system interface tests (!49)
  * Calculate JFS size accurately (!50)
  * Recognise ATARAID members and detect their busy status (#75, !51)
  * Rename members and variables currently named 'filesystem' (!52)

Code Credits

  Code enhancements are courtesy of Félix Piédallu, Mike Fleetwood, and Curtis 
Gedak

Translations (new/updated)
--
  ca(Jordi Mas), cs(Marek Černocký), de(Wolfgang Stöggl, Mathias L. Baumann),
  en_GB(Bruce Cowan), es(Daniel Mustieles, Andre Klapper #80),
  eu(Alexander Gabilondo, Asier Sarasua Garmendia), fr(Claude Paroz),
  hr(Goran Vidović), hu(Balázs Úr), id(Kukuh Syafaat), is(Sveinn í Felli),
  lv(Rudolfs Mazurs), pa(A S Alam), pl(Piotr Drąg), pt_BR(Rafael Fontenelle),
  ro(Daniel Șerbănescu), sv(Anders Jonsson), vi(Trần Ngọc Quân)

Dependencies (new/updated)
--
  * xvfb-run command is required for 'make check' and 'make distcheck'

Bug#954192: exim4-config: prdr_enable = true breaks exim4+dkimproxy when using multiple recipients

[Niki Hammler]

On 2020-03-21 05:43, Marc Haber wrote:
> On Thu, Mar 19, 2020 at 02:41:34PM -0400, n...@nobaq.net wrote:
>> On 2020-03-19 08:44, Marc Haber wrote:
>>> On Wed, Mar 18, 2020 at 06:32:05AM +0100, Niki Hammler wrote:
 This worked flawlessly until jessie (for me, from 2008 until now). 
 However, with prdr_enable = true, exim4 hangs when looping back the 
 message when
 using multiple recipients. It hangs with message:

   353 PRDR content analysis beginning
>>>
>>> That happens when dkimproxy re-delivers the message back to exim? What's
>>> the SMTP dialog before? Does exim advertise PRDR? Does the client
>>> request it?
>>
>> Yes, it happens when dkimproxy redelivers it.
>> However, as I understand dkimproxy, don't think of it as a full-fledged
>> SMTP server. Once I connect to dkimproxy, it transparently opens back a
>> connection to exim. So the greeting message comes actually from exim:
> 
> I see. So we have an prdr-enabled exim talking to a prdr-enabled exim
> via a proxy that chokes on prdr.

Yes.

> I'd say that's the proxy's fault and
> issues like that are bound to re-happen with any other extension that
> interferes with the SMPT dialog.

Well, that's not quite clear to me because it's exim which stops sending
data (normally exim is supposed to send more data after "353 PRDR
content analysis beginning").

ANYWAY, I just got rid of dkimproxy and set up DKIM with exim. So much
easier ...

>From my side, this bug can be closed.

Niki

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

[Sandro Tosi]

> 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.

we're finally in the single digit number of reverse dependencies for
python-sphinx and i'd like to aggressively removing all the remaining
rdeps. could you please upload xapian-bindings with the python2
bindings documentation removed (including the b-d on python-sphinx)?
that would help a lot

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

Bug#954453: apache2-utils: apache-htcacheclean.service failed to determine user credentials

[Julian Gilbey]

Package: apache2-utils
Version: 2.4.41-5
Severity: normal

On doing an upgrade to something, apache-htcacheclean.service was
reloaded unsuccessfully; here is the systemctl status output:

● apache-htcacheclean.service - Disk Cache Cleaning Daemon for Apache HTTP 
Server
 Loaded: loaded (/lib/systemd/system/apache-htcacheclean.service; enabled; 
vendor preset: enabled)
 Active: failed (Result: exit-code) since Sat 2020-03-21 20:35:50 GMT; 1min 
23s ago
 Docs: https://httpd.apache.org/docs/2.4/programs/htcacheclean.html
 Process: 987374 ExecStart=/usr/bin/htcacheclean -d 
$HTCACHECLEAN_DAEMON_INTERVAL -p $HTCACHECLEAN_PATH -l $HTCACHECLEAN_SIZE 
$HTCACHECLEAN_OPTIONS (code=exited, status=217/USER)

Mar 21 20:35:50 erdos systemd[1]: Starting Disk Cache Cleaning Daemon for 
Apache HTTP Server...
Mar 21 20:35:50 erdos systemd[987374]: apache-htcacheclean.service: Failed to 
determine user credentials: No such process
Mar 21 20:35:50 erdos systemd[987374]: apache-htcacheclean.service: Failed at 
step USER spawning /usr/bin/htcacheclean: No such process
Mar 21 20:35:50 erdos systemd[1]: apache-htcacheclean.service: Control process 
exited, code=exited, status=217/USER
Mar 21 20:35:50 erdos systemd[1]: apache-htcacheclean.service: Failed with 
result 'exit-code'.
Mar 21 20:35:50 erdos systemd[1]: Failed to start Disk Cache Cleaning Daemon 
for Apache HTTP Server.

The aptitude run immediately leading up to this was:

Setting up apache2 (2.4.41-5) ...
Installing new version of config file /etc/apache2/mods-available/dav.load ...
info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
insserv: warning: current start runlevel(s) (empty) of script 
`apache-htcacheclean' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
`apache-htcacheclean' overrides LSB defaults (0 1 6).
Job for apache-htcacheclean.service failed because the control process exited 
with error code.
See "systemctl status apache-htcacheclean.service" and "journalctl -xe" for 
details.
invoke-rc.d: initscript apache-htcacheclean, action "restart" failed.


I've no clue why

Best wishes,

   Julian

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

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

Versions of packages apache2-utils depends on:
ii  libapr1  1.6.5-1+b1
ii  libaprutil1  1.6.1-4+b1
ii  libc62.30-2
ii  libcrypt11:4.4.15-1
ii  libssl1.11.1.1d-2

apache2-utils recommends no packages.

apache2-utils suggests no packages.

-- no debconf information

Bug#954454: Subject: ITP: tokei -- A blazingly fast CLOC (Count Lines Of Code) program

[Franklin Yu]

Package: wnpp
Version: N/A; reported 2020-03-21
Severity: wishlist

* Package name : tokei
  Version : 11.0.0
  Upstream Author : Erin Power 
* URL : https://github.com/XAMPPRocky/tokei
* License : MIT and Apache dual license
  Description : A blazingly fast CLOC (Count Lines Of Code) program

Bug#954455: RM: 4digits -- RoQA; Depends on Python 2 and pygtk2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove 4digits. The last upload was in 2014 and it depends on
python 2 and pygtk, which is going away. It can still be reintroduced
when ported to Python 3.

Cheers,
Moritz

Bug#954450: Fix bugs in the Wiki

[Tomas Pospisek]

Hi Stefan

You wrote:

The webpage https://wiki.debian.org/Modules has problems with some 
links.

[...]


Are you aware that *you* can fix that page, since it is a Wiki page? Go to 
Login, then create yourself a user, then fix the page.

*t

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

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Sun, 15 Mar 2020 at 03:57, Holger Wansing  wrote:
>
> 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.

If I remember correctly (I'm more with the Qt side of things) most of
the translations are part of the applications themselves since
Plasma/KF 5. libkf5i18n-data should clearly stay.

---
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#930137: ITA: nicotine -- graphical client for the SoulSeek peer-to-peer system

[Moritz Mühlenhoff]

On Thu, Jun 20, 2019 at 07:30:12PM -0600, Josue Ortega wrote:
> rename 930137 ITA: nicotine -- graphical client for the SoulSeek peer-to-peer

Hi Josue,
what's the status here? Are you still interested in adopting it and working on
it? Otherwise I'll file an RM bug soon, as nicotine isn't ported to Python 3
and one of the last dependencies on pygtk2 (which is also going away like Py2)

Cheers,
Moritz

Bug#954378: tcpdump: Support pcapng captures wiht snaplen 524288

[Romain Francoise]

Hi,

Thanks for the report. Wireshark has its own implementation of the
PcapNg format, so it's not unexpected that it behaves differently than
tcpdump.

The fix is a bit too intrusive for a stable update, especially for a
minor bug like this. I will simply do a buster backport of libpcap
1.9.1-2 from bullseye.

Can you share your modified test file? Thanks.

Bug#954254: RFA response

[Boyuan Yang]

X-Debbugs-CC: lm...@cs.uni-frankfurt.de

Hi Leon,

Uploaded with some modification. Comments:

* Please send a request for sponsorship (RFS) email to 
http://bugs.debian.org/sponsorship-requests to request others in uploading
your package in the future; otherwise people generally will be aware of your
work. I actually *accidentally* saw your email in #954254 and such lucky event
may not happen again :-/

* There is a typo in the Upstream-Contact field of debian/copyright file. I
have fixed it.

* There is an extra tab in the Build-Depends field. I have fixed it.

* Vcs-* fields should indicate the packaging git repo, not upstream git repo.
If you want to provide information about upstream git repo, please write it in
the debian/upstream/metadata file following 
https://wiki.debian.org/UpstreamMetadata . I have dropped those lines from
debian/control. If you need to create a git packaging repo like 
https://salsa.debian.org/debian/pixz , please let me know and I can help to
create such repo and grant you a GitLab "Maintainer" permission for this repo.

* Please consider indicating the origin of patches that you introduced in this
upload. You are welcome to use grammar indicated in DEP-3 (
https://dep-team.pages.debian.net/deps/dep3/). I walked through the upstream
git repo and found that it was cherry-picked from upstream trunk. It's better
if you can indicate it in the patch file so that I can find it easily :-)

Thanks for your work and package adoption!

-- 
Regards,
Boyuan Yang

On Fri, 20 Mar 2020 19:23:13 +0100 Leon Marz 
wrote:
> Hi,
> 
> I would like to adopt your package. I already made a new version with a 
> bunch of updates.
> 
> You can find it here: 
> https://mentors.debian.net/debian/pool/main/p/pixz/pixz_1.0.6-3.dsc
> 
> This will be my first package, that I will maintain. I hope this is not 
> a problem for you.
> 
> If you find any possible improvement, just write me and i will add it 
> in. Otherwise feel free to upload.
> 
> 
> Best Regards,
> 
> Leon Marz
> 
> 
> 


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

Bug#954457: [Pkg-utopia-maintainers] Bug#954457: network-manager: Problems with long wireless names [aborting authentication by local choice (Reason: 3=DEAUTH_LEAVING)]

[Michael Biebl]

Am 21.03.20 um 22:44 schrieb Agustin Martin:
> Package: network-manager
> Version: 1.22.10-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I have tried to use a wifi dongle in my laptop. Networks were detected, but
> connection fails with these messages in syslog
> 
> kernel: wlx0022b0e3c6b6: aborting authentication with
> 70:5a:9e:3a:30:18 by local choice (Reason: 3=DEAUTH_LEAVING)
> wpa_supplicant[671]: wlx0022b0e3c6b6: CTRL-EVENT-SSID-TEMP-DISABLED
> id=0 ssid="local_wifi" auth_failures=2 duration=20 reason=CONN_FAILED
> NetworkManager[657]:   [1584653959.9157] device
> (wlx0022b0e3c6b6): supplicant interface state: authenticating ->
> disconnected

Since this error message comes from wpa_supplicant, this might also be


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879484#25



signature.asc
Description: OpenPGP digital signature

Bug#954434: pulseaudio-module-bluetooth: Adds Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support to PulseAudio on Linux

[Stefano F.]

If we need a new alternative package the RFC is at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954442

Il giorno sab 21 mar 2020 alle ore 17:17 Felipe Sateler
 ha scritto:
>
> Control: tags -1 moreinfo
>
> On Sat, Mar 21, 2020 at 12:33 PM Stefano F.  wrote:
>>
>> Package: pulseaudio-module-bluetooth
>> Version: 13.99.1-1
>> Severity: wishlist
>> Tags: upstream
>>
>> Dear Maintainer,
>>
>> it would be nice to have non-free alternative package for A2DP codecs for
>> modern true wireless earbuds supporte codecs with the packaging of[1].
>>
>> See also[2][3][4]
>>
>> [1]https://github.com/EHfive/pulseaudio-modules-bt
>> [2]https://github.com/EHfive/pulseaudio-modules-bt/wiki#are-there-any-plans-to-
>> upstream-this-into-pulseaudio
>> [3]https://github.com/EHfive/pulseaudio-modules-bt/issues/3
>> [4]https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-
>> on-linux/
>
>
> I'm not sure what you are proposing. If you want these modules to be 
> packaged, please help with getting #794692 resolved and then file a RFP for 
> the modules.
>
> --
>
> Saludos,
> Felipe Sateler

Bug#954443: jp: name conflict of /usr/bin/jp with sat-xmpp-jp

[Martin]

Package: jp
Version: 0.1.3-1+b10

jp includes /usr/bin/jp, which is already "taken" since ~2013 by
something completely different, sat-xmpp-jp. Given that jp has
not yet been part of Debian release, it is probably easy to just
rename the binary, e.g. jp-cli, jp-jmespath, or jmespath. Thanks!

Bug#937066: monkeysign: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Mar 20, 2020 at 06:47:37PM -0400, Antoine Beaupr?? wrote:
> On 2020-03-20 23:41:59, Moritz M??hlenhoff wrote:
> > On Sat, Nov 09, 2019 at 06:11:46PM -0500, Antoine Beaupr?? wrote:
> >> There was a 3 year old "python 3" branch sitting around in the repo that
> >> I revived by merging in the latest code.
> >> 
> >> Tests still fail (the test suite hangs on py2 and fails on py3), but at
> >> least there's some work done. A large part of the porting was already
> >> done by converting `print` statements to the `logging` library (thanks
> >> to simonft).
> >> 
> >> Help on this front would be greatly appreciated. I was already
> >> considering abandoning monkeysign before I realized I had to port it to
> >> Python 3, so it is likely this software will simply die if no one steps
> >> up to help.
> >
> > Hi,
> > Has there been further development? Otherwise I'd suggest to remove 
> > monkeysign
> > for now, it's blocking the removal of pygtk (and in turn a few other 
> > libraries)
> > and it can still be re-introduced by bullseye release if it gets ported.
> 
> i'm sorry to say there has been no progress and must now admit this is
> the only short term solution.

Ack, there's still plenty of time to reintroduce it anyway.

I'm filing an RM bug now.

Cheers,
Moritz

Bug#954446: RM: monkeysign -- RoQA; Depends on pygtk/Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove monkeysign. It depends on Python 2 and pygtk, which
is going away. The maintainer (CCed) acked the removal in 937066.

Cheers,
Moritz

Bug#954450: Problems with links on https://wiki.debian.org/Modules

[Stefan Lithén]

Package: wiki.debian.org


The webpage https://wiki.debian.org/Modules has problems with some links.
1) The link to update-modules brings you to error page 
https://dyn.manpages.debian.org/man/8/update-modules?
2) The link to depmod.conf brings you to error page 
https://dyn.manpages.debian.org/man/5/depmod.conf?
3) The link to modprobe.conf brings you to japanise page 
https://manpages.debian.org/buster/manpages-ja/modprobe.conf.5.ja.html

Bug#954374: libc6: please make maintainerscript compatible with busybox

[Johannes Schauer]

Hi,

Quoting Aurelien Jarno (2020-03-21 00:00:18)
> On 2020-03-20 22:57, Johannes 'josch' Schauer wrote:
> > would it be possible to make the libc6 preinst maintainer script
> > compatible with busybox? Currently the preinst script calls "readlink
> > -m" which is not supported by busybox. Hence the following error will be
> > thrown:
> > 
> > BusyBox v1.30.1 (Debian 1:1.30.1-4) multi-call binary.
> > 
> > Usage: readlink [-fnv] FILE
> > 
> > Display the value of a symlink
> > 
> >   -f  Canonicalize by following all symlinks
> >   -n  Don't add newline
> >   -v  Verbose
> > 
> > I tried to prepare a patch for the preinst script but ran into a FTBFS:
> > 
> > x86_64-linux-gnu-gcc-9   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs 
> > -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2  
> > -B/<>/build-tree/amd64-libc/csu/  
> > -Wl,--version-script=/<>/build-tree/amd64-libc/libnss_files.map
> >  -Wl,-soname=libnss_files.so.2 -Wl,-z,combreloc -Wl,-z,relro 
> > -Wl,--hash-style=both   -L/<>/build-tree/amd64-libc 
> > -L/<>/build-tree/amd64-libc/math 
> > -L/<>/build-tree/amd64-libc/elf 
> > -L/<>/build-tree/amd64-libc/dlfcn 
> > -L/<>/build-tree/amd64-libc/nss 
> > -L/<>/build-tree/amd64-libc/nis 
> > -L/<>/build-tree/amd64-libc/rt 
> > -L/<>/build-tree/amd64-libc/resolv 
> > -L/<>/build-tree/amd64-libc/mathvec 
> > -L/<>/build-tree/amd64-libc/support 
> > -L/<>/build-tree/amd64-libc/nptl 
> > -Wl,-rpath-link=/<>/build-tree/amd64-libc:/<>/build-tree/amd64-libc/math:/<>/build-tree/amd64-libc/elf:/<>/build-tree/amd64-libc/dlfcn:/<>/build-tree/amd64-libc/nss:/<>/build-tree/amd64-libc/nis:/<>/build-tree/amd64-libc/rt:/<>/build-tree/amd64-libc/resolv:/<>/build-tree/amd64-libc/mathvec:/<>/build-tree/amd64-libc/support:/<>/build-tree/amd64-libc/nptl
> >  -o /<>/build-tree/amd64-libc/nss/libnss_files.so  
> > /<>/build-tree/amd64-libc/csu/abi-note.o -Wl,--whole-archive 
> > /<>/build-tree/amd64-libc/nss/libnss_files_pic.a 
> > -Wl,--no-whole-archive   -Wl,--start-group 
> > /<>/build-tree/amd64-libc/linkobj/libc.so 
> > /<>/build-tree/amd64-libc/libc_nonshared.a -Wl,--as-needed 
> > /<>/build-tree/amd64-libc/elf/ld.so -Wl,--no-as-needed 
> > -Wl,--end-group
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libselinux.so: 
> > undefined reference to `gettid@GLIBC_2.30'
> > collect2: error: ld returned 1 exit status
> 
> Strange. How did you try to build it?

It turned out to be a problem on my side. Sorry for the false alarm.

> > Thus, I'm now reporting this wishlist bug here before further working on
> > a fix.
> > 
> > Would you be willing to accept a change that makes the preinst script of
> > libc6 compatible with readlink from busybox?
> 
> On the principle yes, but it means we need to have an equivalent to
> readlink -m. Do you have a way for doing that in busybox?

Indeed I have. There exists a version for bash with an extensive test suite:
https://github.com/bashup/realpaths I ported that one to POSIX shell while
keeping the test suite and comparing it with "realpath -m":
https://gitlab.mister-muffin.de/josch/realpath

The preinst script should probably continue using coreutils readlink when it
exists and only fall back to the re-implementation in POSIX shell if the
version of readlink on the system does not provide the -m option (as it is the
case with busybox).

Since I now was able to successfully rebuild glibc, I can confirm that this is
the last puzzlepiece needed to allow to create and configure a system
containing only the following packages (and their Depends) without errors:
base-files, base-passwd, busybox, debianutils, dpkg, libc-bin, mawk, tar

So it would be great if this could be solved somehow. What do you think? :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#950910: wcc ftbfs with glibc-2.30

[Gianfranco Costamagna]

control: tags -1 patch

removing that include helps

G.

diff -Nru wcc-0.0.2+dfsg/debian/changelog wcc-0.0.2+dfsg/debian/changelog
--- wcc-0.0.2+dfsg/debian/changelog 2020-02-06 09:11:20.0 +0100
+++ wcc-0.0.2+dfsg/debian/changelog 2020-03-21 18:02:12.0 +0100
@@ -1,3 +1,9 @@
+wcc (0.0.2+dfsg-4.1) unstable; urgency=medium
+
+  * Fix build (Closes: #950910)
+
+ -- Gianfranco Costamagna   Sat, 21 Mar 2020 
18:02:12 +0100
+
 wcc (0.0.2+dfsg-4) unstable; urgency=medium
 
   * Updated binutils usage, making libbfd linked staticaly (Closes: #949601)
diff -Nru wcc-0.0.2+dfsg/debian/patches/glibc.patch 
wcc-0.0.2+dfsg/debian/patches/glibc.patch
--- wcc-0.0.2+dfsg/debian/patches/glibc.patch   1970-01-01 01:00:00.0 
+0100
+++ wcc-0.0.2+dfsg/debian/patches/glibc.patch   2020-03-21 18:02:12.0 
+0100
@@ -0,0 +1,15 @@
+Description: stropts.h is removed in new glibc. (See: 
#https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950910)
+
+Author: Gianfranco Costamagna 
+Last-Update: 2020-03-21
+
+--- wcc-0.0.2+dfsg.orig/src/wsh/include/libwitch/wsh.h
 wcc-0.0.2+dfsg/src/wsh/include/libwitch/wsh.h
+@@ -66,7 +66,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ #include 
+ #include 
diff -Nru wcc-0.0.2+dfsg/debian/patches/series 
wcc-0.0.2+dfsg/debian/patches/series
--- wcc-0.0.2+dfsg/debian/patches/series2020-02-06 09:11:20.0 
+0100
+++ wcc-0.0.2+dfsg/debian/patches/series2020-03-21 18:02:02.0 
+0100
@@ -9,3 +9,4 @@
 changelog.patch
 spelling_in_src.patch
 latex_build.patch
+glibc.patch

On Sat, 8 Feb 2020 07:44:36 +0100 Matthias Klose  wrote:
> Package: src:wcc
> Version: 0.0.2+dfsg-4
> Severity: important
> Tags: sid bullseye
> 
> wcc ftbfs with glibc-2.30:
> 
> mkdir -p bin
> cd src && make CFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2 -W -Wall
> -Wno-discarded-qualifiers -Wno-int-conversion -Wno-unused-parameter
> -Wno-unused-function -Wno-unused-result -fpie -pie -fPIC -g3 -ggdb
> -I../../include  -I./include/sflib/ -I./include -I../../include/
> -Wno-incompatible-pointer-types  -fstack-protector-all -Wl,-z,relro,-z,now
> -DPACKAGE -DPACKAGE_VERSION -masm=intel -rdynamic -D_fORTIFY_SOURCE=2 -O2"
> make[2]: Entering directory '/<>/wcc-0.0.2+dfsg/src'
> make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> cd wcc && make CFLAGS=" -Wdate-time -D_FORTIFY_SOURCE=2 -W -Wall
> -Wno-discarded-qualifiers -Wno-int-conversion -Wno-unused-parameter
> -Wno-unused-function -Wno-unused-result -fpie -pie -fPIC -g3 -ggdb
> -I../../include  -I./include/sflib/ -I./include -I../../include/
> -Wno-incompatible-pointer-types  -fstack-protector-all -Wl,-z,relro,-z,now
> -DPACKAGE -DPACKAGE_VERSION -masm=intel -rdynamic -D_fORTIFY_SOURCE=2 -O2"
> make[3]: Entering directory '/<>/wcc-0.0.2+dfsg/src/wcc'
> cc -Wdate-time -D_FORTIFY_SOURCE=2 -W -Wall -Wno-discarded-qualifiers
> -Wno-int-conversion -Wno-unused-parameter -Wno-unused-function
> -Wno-unused-result -fpie -pie -fPIC -g3 -ggdb -I../../include
> -I./include/sflib/ -I./include -I../../include/  
> -Wno-incompatible-pointer-types
>  -fstack-protector-all -Wl,-z,relro,-z,now -DPACKAGE -DPACKAGE_VERSION
> -masm=intel -rdynamic -D_fORTIFY_SOURCE=2 -O2 wcc.c -o wcc -l:libbfd.a -lz 
> -ldl
> -liberty -lelf -lcapstone
> cp wcc ../../bin/
> make[3]: Leaving directory '/<>/wcc-0.0.2+dfsg/src/wcc'
> cd wld && make CFLAGS=" -Wdate-time -D_FORTIFY_SOURCE=2 -W -Wall
> -Wno-discarded-qualifiers -Wno-int-conversion -Wno-unused-parameter
> -Wno-unused-function -Wno-unused-result -fpie -pie -fPIC -g3 -ggdb
> -I../../include  -I./include/sflib/ -I./include -I../../include/
> -Wno-incompatible-pointer-types  -fstack-protector-all -Wl,-z,relro,-z,now
> -DPACKAGE -DPACKAGE_VERSION -masm=intel -rdynamic -D_fORTIFY_SOURCE=2 -O2"
> make[3]: Entering directory '/<>/wcc-0.0.2+dfsg/src/wld'
> cc -Wdate-time -D_FORTIFY_SOURCE=2 -W -Wall -Wno-discarded-qualifiers
> -Wno-int-conversion -Wno-unused-parameter -Wno-unused-function
> -Wno-unused-result -fpie -pie -fPIC -g3 -ggdb -I../../include
> -I./include/sflib/ -I./include -I../../include/  
> -Wno-incompatible-pointer-types
>  -fstack-protector-all -Wl,-z,relro,-z,now -DPACKAGE -DPACKAGE_VERSION
> -masm=intel -rdynamic -D_fORTIFY_SOURCE=2 -O2 wld.c -o wld -l:libbfd.a -lz 
> -ldl
> -liberty
> wld.c: In function ‘print_version’:
> wld.c:110:57: warning: macro "__TIME__" might prevent reproducible builds
> [-Wdate-time]
>   110 |   printf("%s version:%s(%s %s)\n", WNAME, WVERSION, WTIME, WDATE);
>   | ^
> wld.c:110:64: warning: macro "__DATE__" might prevent reproducible builds
> [-Wdate-time]
>   110 |   printf("%s version:%s(%s %s)\n", WNAME, WVERSION, WTIME, WDATE);
>   |^
> cp wld ../../bin/
> make[3]: Leaving directory '/<>/wcc-0.0.2+dfsg/src/wld'
> cd wsh && make CFLAGS=" -Wdate-time -D_FORTIFY_SOURCE=2 -W 

Bug#954444: new upstream release (2020-03-20)

[Ryan Kavanagh]

Package: neomutt
Version: 20191207+dfsg.1-1
Severity: wishlist

Please update to the latest upstream release. It features many bug
fixes: https://github.com/neomutt/neomutt/blob/master/ChangeLog.md

-- Package-specific info:
NeoMutt 20191207
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.4.0-4-amd64 (x86_64)
ncurses: ncurses 6.2.20200212 (compiled with 6.2.20200212)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
libnotmuch: 5.2.0
hcache backends: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-KUFXeJ/neomutt-20191207+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  -autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime 
  -sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: bullseye/sid
  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 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.29-6
ii  libgnutls30   3.6.12-2
ii  libgpg-error0 1.37-1
ii  libgpgme111.13.1-7
ii  libgssapi-krb5-2  1.17-6
ii  libidn11  1.33-2.2
ii  liblua5.3-0   5.3.3-1.1+b1
ii  libncursesw6  6.2-1
ii  libnotmuch5   0.29.3-1+b2
ii  libsasl2-22.1.27+dfsg-2
ii  libtinfo6 6.2-1
ii  libtokyocabinet9  1.4.48-12

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2
ii  locales   2.29-10
ii  mime-support  3.64

Versions of packages neomutt suggests:
ii  aspell0.60.8-1
ii  ca-certificates   20190110
ii  gnupg 2.2.19-3
ii  ispell3.4.00-8
pn  mixmaster 
ii  opensmtpd [mail-transport-agent]  6.6.4p1-1
ii  openssl   1.1.1e-1
pn  urlview   

Versions of packages neomutt is related to:
ii  neomutt  20191207+dfsg.1-1

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#953829: regression/crash: mtr: Probes exhausted

[Robert Woodcock]

On 3/17/20 4:02 AM, Marc Lehmann wrote:
> On Sun, Mar 15, 2020 at 03:43:09PM -0700, Robert Woodcock  
> wrote:
>> If you *do* need to differentiate, I would adjust the limit for the
>> number of outstanding probes in packet/probe.h, and then recompile:
>>
>> #define MAX_PROBES 1024
>>
>> However, that's not enough - I believe the intent of this limit is to
>> match the default Linux limit of 1024 open files per process, which you
>> will need to override in /etc/security/limits.conf to make effective use
>> of the new limit in your copy of mtr.
>>
>> Probably the best long-term fix would be to automatically free the
>> oldest probe when the newest one is requested, but I don't know how
>> practical that would be.
> Thanks a lot for this detailed analysis and tips. The strange thing,
> though, is that this is clearly a regression, i.e. these limits (other
> than the kernel limit) seem to either be new, or mtr silently handled this
> in the past.
>
> Anyway, if that's going to be it, I'll simply have to adapt, and this
> apparently works as designed and is not a bug.
>
MTR was pretty substantially redesigned about 3 years ago - the UI was
separated from the backend (which has to have special privileges to open
a raw socket - it used to need to be setuid, but now it uses setcap to
provide only the RAW socket privilege needed). That redesign made it
into the mtr 0.92 package in the current stable version of Debian -
Buster - released in 2019. This was done for security reasons, to limit
the possible attack surface for privilege escalation. I have not done a
similar analysis on the older versions (0.87 and below) but I suspect
that's what you were using before.

Bug#954457: network-manager: Problems with long wireless names [aborting authentication by local choice (Reason: 3=DEAUTH_LEAVING)]

[Agustin Martin]

Package: network-manager
Version: 1.22.10-1
Severity: normal

Dear Maintainer,

I have tried to use a wifi dongle in my laptop. Networks were detected, but
connection fails with these messages in syslog

kernel: wlx0022b0e3c6b6: aborting authentication with
70:5a:9e:3a:30:18 by local choice (Reason: 3=DEAUTH_LEAVING)
wpa_supplicant[671]: wlx0022b0e3c6b6: CTRL-EVENT-SSID-TEMP-DISABLED
id=0 ssid="local_wifi" auth_failures=2 duration=20 reason=CONN_FAILED
NetworkManager[657]:   [1584653959.9157] device
(wlx0022b0e3c6b6): supplicant interface state: authenticating ->
disconnected

Looking at

https://unix.stackexchange.com/questions/386925/aborting-authentication-by-local-choice-reason-3-deauth-leaving-when-trying

this problem seems to be attributed to network manager having problems with
long (e.g, wlx0022b0e3c6b6) wifi names (wicd seems not affected).
A workaround is suggested in that page, adding ad-hoc udev rules. e.g.

/etc/udev/rules.d/70_rename-wlan.rules:
SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan*", NAME="wlan0"

I have tested this and is working.

Not sure if problem is indeed with network-manager, but seems likely. I
think I even read somewhere that downgrading network-manager helped, but did
not keep track of the url and also I did not try the downgrade.

Regards,

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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  init-system-helpers1.57
ii  libaudit1  1:2.8.5-2+b1
ii  libbluetooth3  5.50-1.1
ii  libc6  2.30-2
ii  libcurl3-gnutls7.68.0-1
ii  libglib2.0-0   2.64.1-1
ii  libgnutls303.6.12-2
ii  libjansson42.12-1
ii  libmm-glib01.12.6-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.21-4
ii  libnm0 1.22.10-1
ii  libpam-systemd 245.2-1
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libpsl50.21.0-1
ii  libreadline8   8.0-4
ii  libselinux13.0-1+b2
ii  libsystemd0245.2-1
ii  libteamdctl0   1.30-1
ii  libudev1   245.2-1
ii  libuuid1   2.34-0.1
ii  policykit-10.105-26
ii  udev   245.2-1
ii  wpasupplicant  2:2.9.0-11

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1.1
ii  iptables 1.8.4-3
ii  modemmanager 1.12.6-1
ii  ppp  2.4.7-2+4.1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1+b1
pn  libteam-utils

-- no debconf information

Bug#938340: reclass: Python2 removal in sid/bullseye

[Sandro Tosi]

To give time to Jonas to complete the port away from reclass and the
py2removal effort, i'm gonna upload a 0-day nmu to drop reclass-doc
(reducing rdeps for python-sphinx).

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

Bug#954189: acmetool: Buster acmetool stops working in June 1, 2020

[Russell Ault]

For what it's worth, the version currently in Testing (which does support 
ACMEv2) will install on Buster with no additional dependencies and seems to be 
working. Hopefully this means a backport? If nothing else, this does present a 
work-around.

-Russ

Bug#952024: ruby-rspec-puppet: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

[Daniel Leidert]

Package: src:ruby-rspec-puppet
Followup-For: Bug #952024

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

After libfacter has been fixed, the package FTBFS with these errors:

Failures:

  1) boolean_test is expected to contain Notify[bool testing] with message =~ 
/bool is false/
 Failure/Error: string.gsub!(/\$/, "\\$")

 FrozenError:
   can't modify frozen String: "false"
 # ./lib/rspec-puppet/support.rb:443:in `gsub!'
 # ./lib/rspec-puppet/support.rb:443:in `escape_special_chars'
 # ./lib/rspec-puppet/support.rb:343:in `str_from_value'
 # ./lib/rspec-puppet/support.rb:351:in `block in param_str_from_hash'
 # ./lib/rspec-puppet/support.rb:350:in `each'
 # ./lib/rspec-puppet/support.rb:350:in `collect'
 # ./lib/rspec-puppet/support.rb:350:in `param_str_from_hash'
 # ./lib/rspec-puppet/support.rb:280:in `param_str'
 # ./lib/rspec-puppet/support.rb:155:in `test_manifest'
 # ./lib/rspec-puppet/support.rb:21:in `build_code'
 # ./lib/rspec-puppet/support.rb:91:in `block in load_catalogue'
 # ./lib/rspec-puppet/support.rb:376:in `with_vardir'
 # ./lib/rspec-puppet/support.rb:83:in `load_catalogue'
 # ./lib/rspec-puppet/example/class_example_group.rb:7:in `catalogue'
 # ./lib/rspec-puppet/support.rb:12:in `block in subject'
 # ./lib/rspec-puppet/matchers/create_generic.rb:84:in `matches?'
 # ./spec/classes/boolean_regexp_spec.rb:8:in `block (2 levels) in '

  2) boolean_test is expected not to contain Notify[bool testing] with message 
=~ /true/
 Failure/Error: string.gsub!(/\$/, "\\$")

 FrozenError:
   can't modify frozen String: "false"
 # ./lib/rspec-puppet/support.rb:443:in `gsub!'
 # ./lib/rspec-puppet/support.rb:443:in `escape_special_chars'
 # ./lib/rspec-puppet/support.rb:343:in `str_from_value'
 # ./lib/rspec-puppet/support.rb:351:in `block in param_str_from_hash'
 # ./lib/rspec-puppet/support.rb:350:in `each'
 # ./lib/rspec-puppet/support.rb:350:in `collect'
 # ./lib/rspec-puppet/support.rb:350:in `param_str_from_hash'
 # ./lib/rspec-puppet/support.rb:280:in `param_str'
 # ./lib/rspec-puppet/support.rb:155:in `test_manifest'
 # ./lib/rspec-puppet/support.rb:21:in `build_code'
 # ./lib/rspec-puppet/support.rb:91:in `block in load_catalogue'
 # ./lib/rspec-puppet/support.rb:376:in `with_vardir'
 # ./lib/rspec-puppet/support.rb:83:in `load_catalogue'
 # ./lib/rspec-puppet/example/class_example_group.rb:7:in `catalogue'
 # ./lib/rspec-puppet/support.rb:12:in `block in subject'
 # ./lib/rspec-puppet/matchers/create_generic.rb:84:in `matches?'
 # ./spec/classes/boolean_regexp_spec.rb:11:in `block (2 levels) in '

  3) boolean_test is expected to contain Notify[bool testing] with message !~ 
/true/
 Failure/Error: string.gsub!(/\$/, "\\$")

 FrozenError:
   can't modify frozen String: "false"
 # ./lib/rspec-puppet/support.rb:443:in `gsub!'
 # ./lib/rspec-puppet/support.rb:443:in `escape_special_chars'
 # ./lib/rspec-puppet/support.rb:343:in `str_from_value'
 # ./lib/rspec-puppet/support.rb:351:in `block in param_str_from_hash'
 # ./lib/rspec-puppet/support.rb:350:in `each'
 # ./lib/rspec-puppet/support.rb:350:in `collect'
 # ./lib/rspec-puppet/support.rb:350:in `param_str_from_hash'
 # ./lib/rspec-puppet/support.rb:280:in `param_str'
 # ./lib/rspec-puppet/support.rb:155:in `test_manifest'
 # ./lib/rspec-puppet/support.rb:21:in `build_code'
 # ./lib/rspec-puppet/support.rb:91:in `block in load_catalogue'
 # ./lib/rspec-puppet/support.rb:376:in `with_vardir'
 # ./lib/rspec-puppet/support.rb:83:in `load_catalogue'
 # ./lib/rspec-puppet/example/class_example_group.rb:7:in `catalogue'
 # ./lib/rspec-puppet/support.rb:12:in `block in subject'
 # ./lib/rspec-puppet/matchers/create_generic.rb:84:in `matches?'
 # ./spec/classes/boolean_regexp_spec.rb:12:in `block (2 levels) in '

  4) boolean_test is expected to contain Notify[bool testing] with message => 
"This will print when $bool is false."
 Failure/Error: string.gsub!(/\$/, "\\$")

 FrozenError:
   can't modify frozen String: "false"
 # ./lib/rspec-puppet/support.rb:443:in `gsub!'
 # ./lib/rspec-puppet/support.rb:443:in `escape_special_chars'
 # ./lib/rspec-puppet/support.rb:343:in `str_from_value'
 # ./lib/rspec-puppet/support.rb:351:in `block in param_str_from_hash'
 # ./lib/rspec-puppet/support.rb:350:in `each'
 # ./lib/rspec-puppet/support.rb:350:in `collect'
 # ./lib/rspec-puppet/support.rb:350:in `param_str_from_hash'
 # ./lib/rspec-puppet/support.rb:280:in `param_str'
 # ./lib/rspec-puppet/support.rb:155:in `test_manifest'
 # ./lib/rspec-puppet/support.rb:21:in `build_code'
 # ./lib/rspec-puppet/support.rb:91:in `block in load_catalogue'
 # ./lib/rspec-puppet/support.rb:376:in `with_vardir'
 # ./lib/rspec-puppet/support.rb:83:in `load_catalogue'
 # 

Bug#954459: lintian: maintainer-shell-script-fails-syntax-check requires /bin/sh → !/bin/bash?

[Chris Lamb]

Package: lintian
Version: 2.58.0
Severity: normal

Hi,

The scripts-bashisms and legacy-maintainer-scripts and tests fail
when /bin/sh is set to /bin/bash. This occurs in, for example, the
Reproducible Builds framework:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lintian.html

Click the build2 link in the left-hand navigation. The cause is that
whilst:

  ./t/tags/checks/scripts/scripts-bashisms/build-spec/debian/postinst

… contains bashisms, it has a /bin/sh shebang so the script is tested
against Bash which, of course, supports Bashisms.

  $ bash -n t/tags/checks/scripts/scripts-bashisms/build-spec/debian/postinst
  $ dash -n t/tags/checks/scripts/scripts-bashisms/build-spec/debian/postinst
  ./t/tags/checks/scripts/scripts-bashisms/build-spec/debian/postinst: 66: 
Syntax error: "do" unexpected
  $


Regards,

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

Bug#935706: lintian: Make tag certainty a programmatic assessment

[Chris Lamb]

Hi Axel,

> With removing the Certainty you basically removed the possibility to
> write Lintian checks which are known to not be or in some cases even
> never can be 100% perfect.

I don't see how the removal of Certainty requires checks to be
100% perfect. There is no change of thought here, just the removal of
metadata that was highly dubious to begin with. :)

If a check is wildly inaccurate we still have many options available
to us, including improving it (patches always welcome!), removing it,
moving it to the "experimental" pile, or even adding an explicit
remark to the tag's description, and so on. Indeed, this last idea
will be much more useful than some implied subtle distinction between
certainty levels.

In practice, each particular new "certainty" value was not well-
calibrated when added and essentially never adjusted … except in cases
where the Lintian maintainers received bug reports that had an
antagonistic quality to them fueled by an overly-optimistic appraisal
of a check's reliability. Flames wrapped in the plausibly-deniable
wrapper of a legitimate bug report aren't any more fun to receive than
regular flames tbh.

In other words, removal of the field simply reflects the reality and
status quo that this field was misleading at best and inflammatory at
worst.


Best wishes,

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

Bug#954463: override: gir1.2-nemo-3.0:introspection/optional

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Please change the section from libdevel to introspection

Bug#954466: acmetool: Cannot Bind to IPv4 port 80

[Russell Ault]

Package: acmetool
Version: 0.2.1-2
Severity: normal

Dear Maintainer,

-- Steps to reproduce problem:

1. Install acmetool 0.2.1-2 on Debian Buster
2. # netstat -pa | grep ':http' # ensure there are no results
3. # acmetool quickstart # select either live or staging and "Listener"
4. # acmetool --xlog.severity=debug want example.com


-- Expected results (on the console):

[DEBUG] acmetool.reshttp: listening on [::]:80
...
[DEBUG] acmetool.reshttp: listening on :80


-- Actual results (on the console):

[DEBUG] acmetool.reshttp: listening on [::]:80
...
[DEBUG] acmetool.reshttp: failed to listen on :80: listen tcp :80: bind: 
address already in use


-- Further troubleshooting steps taken:

- specifically defining port 80 or 0.0.0.0:80 in
  /var/lib/acme/conf/target produces the same failure
- # nc -l -p 80 # binds sucessfully


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

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

Versions of packages acmetool depends on:
ii  libc62.28-10
ii  libcap2  1:2.25-2

Versions of packages acmetool recommends:
ii  dialog  1.3-20190211-1

acmetool suggests no packages.

-- no debconf information

Bug#954481: src:python3-proselint: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:python3-proselint
Version: 0.10.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954480: src:python-tinyrpc: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:python-tinyrpc
Version: 0.6-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954402: m2crypto: FTBFS since openssl 1.1.1e

[Sandro Tosi]

> > The package FTBFS since openssl has been updated to 1.1.1e because the
> > testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > which introduced the changed behaviour.
> >
> > [0] https://github.com/openssl/openssl/pull/10882
> > [1] https://github.com/openssl/openssl/issues/10880
>
> what should i do about it on the m2crypto side?

is this the failure you're referring to?

=== FAILURES ===
___ MiscSSLClientTestCase.test_makefile_err 

self = 

   def test_makefile_err(self):
   pid = self.start_server(self.args)
   try:
   ctx = SSL.Context()
   s = SSL.Connection(ctx)
   try:
   s.connect(self.srv_addr)
   except SSL.SSLError as e:
   self.fail(e)
   f = s.makefile()
   data = self.http_get(s)
   s.close()
   del f
   del s
   err_code = Err.peek_error_code()
   self.assertEqual(err_code, 0,
>'Unexpected error: %s' % err_code)
EAssertionError: 336154918 != 0 :
Unexpected error: 336154918

tests/test_ssl.py:858: AssertionError


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

Bug#896165: ITP: bpftool -- utility for querying and updating BPF objects

[Christian Barcenas]

Control: reassign -1 wnpp
Control: notfound -1 linux/4.16.5-1
Control: affects -1 src:linux
Control: retitle ITP: bpftool -- utility for querying and updating BPF objects
Control: owner -1 !

Hi all, I'm restructuring this as an ITP.

I'm very keen to get bpftool in Debian as well, now that the copyright
concerns are resolved.

I'll work with the kernel team to get it packaged. Thanks Noah for all the
work so far.

Christian

--

* Package name: bpftool
  Version : 5.5.8
  Upstream Author : Various Linux kernel developers
* URL : https://www.kernel.org/
* License : GPL-2.0-only OR BSD-2-Clause
  Programming Lang: C
  Description : utility for querying and updating BPF objects

bpftool is a utility for querying and updating BPF objects on the system.

Packaging bpftool will improve the experience of developing and deploying
BPF-backed software on Debian systems.

bpftool is actively developed and is maintained as part of the upstream kernel.

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool

Therefore, the Debian kernel source package (src:linux) is a natural place for
the bpftool binary package.

Bug#916594: [Pkg-mozext-maintainers] Bug#919557: Bug#919557: webext-umatrix: garbled display of toolbar menu in Firefox 64.0-1

[Ximin Luo]

Antoine Beaupré:
> On 2019-10-25 11:58:37, Antoine Beaupré wrote:
>> On 2019-09-04 23:05:19, Paul Wise wrote:
>>> On Fri, 22 Feb 2019 07:47:00 + Ximin Luo wrote:
>>>
 For the time being you can work around the issue either by using
 firefox-esr instead of firefox (65) which is why I myself had not yet
 noticed this issue, it was working perfectly fine for me.
>>>
>>> Unfortunately Firefox ESR 68 has now reached Debian unstable.
>>>
 If you cannot run firefox-esr and must run firefox 65, you can also
 work around the issue by running:

 $ sudo rm /usr/share/webext/umatrix/lib/punycode.js
 $ sudo cp /usr/share/javascript/punycode/punycode.js 
 /usr/share/webext/umatrix/lib/punycode.js
>>>
>>> This workaround is no longer sufficient to fix the issue. I also tried
>>> removing other symlinks and replacing them with the equivalent files
>>> but this didn't help either.
>>
>> I also see this problem, on Debian 10 buster, after upgrading to FF 68.
>>
>> But what I found strange is that I did the upgrade on two different
>> machines, and one survived: my laptop doesn't have problems with
>> uMatrix, as far as I can tell.
>>
>> Note that this bug also triggers #916594 which means it's impossible to
>> restore from backups.
>>
>> That said, the above "rm + cp" workaround *did* work here,
>> strangely. Not sure what I have different from pabs...
> 
> ... ah. but the bug described in #916594 *does* still happen now: the
> display is correct, but the "My rules" dialog is blank:
> 
> https://paste.anarc.at/publish/2019-10-25-otplYB53oFI/screenshot.png
> 
> The nice thing is that while the "My rules" dialog looks blank, the
> rules *are* actually still there, [..]

This is because codemirror is also symlinked, and that dialog uses codemirror. 
To work-around locally, do the same thing as for punycode:

$ sudo rm /usr/share/webext/umatrix/lib/codemirror
$ sudo cp -a /usr/share/javascript/codemirror 
/usr/share/webext/umatrix/lib/codemirror

(Note that due to limitations in dpkg, this workaround persists even if you 
reinstall webext-umatrix. To undo the workaround, rm -rf the directory *then* 
reinstall webext-umatrix.)

I've just uploaded a new version of umatrix 1.4.0, and confirmed these 
workarounds still work with firefox 74. If it doesn't work for you, please try 
it on a fresh profile.

I've also enabled chromium support and the workaround isn't needed there, 
chromium traverses these symlinks fine. It really is a firefox bug and the 
firefox devs refusing to allow this behaviour for "security" reasons don't know 
what they are talking about.

I would imagine one simply has to find the relevant "if" condition in firefox 
source code and patch it out of Debian's packaged firefox.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#953485: binaries uploaded

[Adam Borowski]

On Sat, Mar 21, 2020 at 05:47:25PM +0100, Ivo De Decker wrote:
> On Sat, Mar 21, 2020 at 02:43:19PM +0100, Adam Borowski wrote:
> > I've uploaded binaries for amd64 arm64 armhf i386 (ie, arch in testing), so
> > it should be done.
> > 
> > Apparently the package can't be autobuilt, so it's up to me and tarzeau to
> > remember to upload the binaries the next time as well.  Oh well.
> 
> You should remove the "XS-Autobuild: yes" from the control file. Not only is
> it incorrect (as the package apparently cannot be autobuilt on debian
> infrastructure), but doing so will also trigger the
> 'source-only-upload-to-non-free-without-autobuild' lintian tag, which will
> cause a source-only upload to be autorejected by dak if you forget to include
> the binaries.

Thanks, that autoreject sounds useful.

Forwarding to the actual maintainer...


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

Bug#953325: transition: kodi and kodiplatform

[Bálint Réczey]

Hi Emilio,

Emilio Pozuelo Monfort  ezt írta (időpont: 2020.
márc. 21., Szo, 12:23):
>
> Control: tags -1 = confirmed
>
> On 07/03/2020 20:51, Emilio Pozuelo Monfort wrote:
> > On 07/03/2020 20:40, Bálint Réczey wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian@packages.debian.org
> >> Usertags: transition
> >>
> >> Dear Release Team,
> >>
> >> I would like to update kodi in unstable to the 18.x branch and this 
> >> involves
> >> updating reverse dependencies, too.
> >>
> >> The following source packages need source updates:
> >> kodi-pvr-argustv
> >> kodi-pvr-dvbviewer
> >> kodi-pvr-hdhomerun
> >> kodi-pvr-iptvsimple
> >> kodi-pvr-mediaportal-tvserver
> >> kodi-pvr-mythtv
> >> kodi-pvr-nextpvr
> >> kodi-pvr-njoy
> >> kodi-pvr-vdr-vnsi
> >> kodi-pvr-vuplus
> >> kodi-pvr-wmc
> >> kodi-visualization-spectrum
> >> kodiplatform
> >>
> >> Most of the packages are maintained by me under Multimedia Team's umbrella.
> >> I have already uploaded kodi to experimental and prepared most of the 
> >> source
> >> packages for uploading them to unstable.
> >
> > Looks like kodi failed to build on a bunch of release architectures. That 
> > should
> > get looked at before we start the transition in unstable.
>
> This has happened and the situation is much better. Let's go ahead with this 
> and
> fix the flatbuffers mips64el problem to allow that architecture to build too.

Done. I've committed the fix to flatbuffers' packaging repo a month
ago and now I've NMUd it.

> btw s390x only has three test failures that seem to be related to each other.
> Did you look at those?

Yes, I took a quick look. Zip file reading seems to be broken and
since kodi is not used on s390x I don't plan triaging that further.
Anyone interested can pick that up, but IMO building s390x binaries
for kodi does not benefit our users.

Cheers,
Balint

>
> Cheers,
> Emilio

Bug#954442: RFP: pulseaudio-module-bluetooth-nonfree -- Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support to PulseAudio on Linux

[Stefano F.]

Package: wnpp
Severity: wishlist

* Package name: pulseaudio-module-bluetooth-nonfree
  Version : x.y.z
  Upstream Author : Bao H.H. 
* URL : https://github.com/EHfive/pulseaudio-modules-bt
* License : GPL3
  Programming Lang: C
  Description : Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support
to PulseAudio on Linux

Pulseaudio bluetooth modules forks that adds LDAC, APTX, APTX-HD, AAC support,
extended configuration for SBC

It is very useful to support codecs for modern true wireless earbuds

Some interesting links:
[1]https://github.com/EHfive/pulseaudio-modules-bt
[2]https://github.com/EHfive/pulseaudio-modules-bt/wiki#are-there-any-plans-to-
upstream-this-into-pulseaudio
[3]https://github.com/EHfive/pulseaudio-modules-bt/issues/3
[4]https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-
on-linux/

Bug#948364: audacity leaks memory and crashes

[Antoine Amarilli]

Hi,

I am still having this bug as of today, which makes Audacity unusable. I
compiled Audacity 2.3.3 from source and it doesn't seem to have the same
problem.

So the problem may be in the Debian packaging, or in the use of
different library versions than what I did.

Here is some information about my build:

$ ldd ./audacity 
linux-vdso.so.1 (0x7ffe2415d000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7f234d943000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f234d922000)
libwx_gtk2u_html-3.0.so.0 => 
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0 (0x7f234d643000)
libwx_gtk2u_qa-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0 
(0x7f234d414000)
libwx_gtk2u_adv-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0 
(0x7f234d026000)
libwx_gtk2u_core-3.0.so.0 => 
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0 (0x7f234c78c000)
libwx_baseu_net-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0 
(0x7f234c53e000)
libwx_baseu-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 
(0x7f234c09f000)
libavcodec.so.58 => /usr/lib/x86_64-linux-gnu/libavcodec.so.58 
(0x7f234ab0d000)
libavformat.so.58 => /usr/lib/x86_64-linux-gnu/libavformat.so.58 
(0x7f234a899000)
libavutil.so.56 => /usr/lib/x86_64-linux-gnu/libavutil.so.56 
(0x7f234a774000)
libid3tag.so.0 => /usr/lib/x86_64-linux-gnu/libid3tag.so.0 (0x7f234a755000)
libmad.so.0 => /usr/lib/x86_64-linux-gnu/libmad.so.0 (0x7f234a733000)
libSoundTouch.so.1 => /usr/lib/x86_64-linux-gnu/libSoundTouch.so.1 
(0x7f234a71c000)
libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 
(0x7f234a671000)
libvorbisfile.so.3 => /usr/lib/x86_64-linux-gnu/libvorbisfile.so.3 
(0x7f234a666000)
libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x7f234a638000)
libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x7f234a42d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f234a428000)
libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 
(0x7f2349fdc000)
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 
(0x7f2349f25000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 
(0x7f2349efe000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 
(0x7f2349ea2000)
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 
(0x7f2349d7b000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f2349c82000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f2349c77000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f2349aaa000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2349965000)
libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1 (0x7f2349939000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f234991d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f234975d000)
/lib64/ld-linux-x86-64.so.2 (0x7f234ec09000)
libwx_baseu_xml-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0 
(0x7f234954d000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 
(0x7f2349503000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f23493c1000)
libnotify.so.4 => /usr/lib/x86_64-linux-gnu/libnotify.so.4 (0x7f23493b7000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 
(0x7f23493a5000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x7f2349285000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 
(0x7f234907f000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x7f2349074000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x7f234903b000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x7f2348dd2000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x7f2348d4e000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2348d31000)
libswresample.so.3 => /usr/lib/x86_64-linux-gnu/libswresample.so.3 
(0x7f2348d0f000)
libvpx.so.6 => /usr/lib/x86_64-linux-gnu/libvpx.so.6 (0x7f2348ad8000)
libwebpmux.so.3 => /usr/lib/x86_64-linux-gnu/libwebpmux.so.3 
(0x7f2348acc000)
libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6 (0x7f2348a5f000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f2348a36000)
librsvg-2.so.2 => /usr/lib/x86_64-linux-gnu/librsvg-2.so.2 (0x7f2348606000)
libzvbi.so.0 => /usr/lib/x86_64-linux-gnu/libzvbi.so.0 (0x7f2348576000)
libsnappy.so.1 => /usr/lib/x86_64-linux-gnu/libsnappy.so.1 (0x7f234856b000)
libaom.so.0 => /usr/lib/x86_64-linux-gnu/libaom.so.0 (0x7f23480d3000)
libcodec2.so.0.9 => /usr/lib/x86_64-linux-gnu/libcodec2.so.0.9 
(0x7f23472ec000)
libgsm.so.1 => /usr/lib/x86_64-linux-gnu/libgsm.so.1 (0x7f23472dc000)
libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 
(0x7f2347264000)
libopenjp2.so.7 => 

Bug#954447: RFS: wand/0.5.9-2 -- Python interface for ImageMagick library (Python 3 build)

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "wand"

 * Package name: wand
   Version : 0.5.9-2
   Upstream Author : E. McConville 
 * URL : https://github.com/emcconville/wand
 * License : Expat
 * Vcs : https://salsa.debian.org/debian/wand
   Section : python

It builds those binary packages:

  python3-wand - Python interface for ImageMagick library (Python 3 build)
  pypy-wand - Python interface for ImageMagick library (PyPy build)
  wand-doc - Python interface for ImageMagick library - documentation

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wand/wand_0.5.9-2.dsc

Changes since the last upload:

   * Minor tweak for autopkgtest.
 - Update dependencies
 - Change to test supported Python3 versions
   * Add libmagickcore-6.q16-6-extra as Suggests in d/control


I got a lintian error when i built the package. The tag has bug reports
filed against it so it shouldn't be any problem. #954341 #954424

Regards,
Håvard

Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e

[gregor herrmann]

On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:

> The package FTBFS since openssl has been updated to 1.1.1e because the
> testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> while reading in libssl") [0] in openssl. There an issue ticket [1]
> which introduced the changed behaviour.

There's a patch at
https://github.com/noxxi/p5-io-socket-ssl/issues/93
This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Beatles


signature.asc
Description: Digital Signature

Bug#954451: PAPT Team upload, not NMU

[Scott Kitterman]

Now that I see PAPT is the maintainer, I guess it would be a team upload, not 
an NMU.  In any case if someone has a plan other than dropping the tests, 
please say so in the bug.

Scott K

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

Bug#954464: mate-control-center-common: mate-control-center does not show the apperance window

[Miguel de Dios Matias]

Package: mate-control-center-common
Version: 1.24.0-1
Severity: normal

I have this configuration in my laptop:

$ dpkg -l | grep mate-control-center
ii  mate-control-center 1.20.4-2
amd64utilities to configure the MATE desktop
ii  mate-control-center-common  1.24.0-1
all  utilities to configure the MATE desktop (common files)

$ uname -a
Linux speccy-laptop 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64
GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bullseye/sid
Release:testing
Codename:   bullseye


And when I run mate-control-center and click in the apperance icon (the stderr
shows):
$ mate-control-center

** (mate-control-center:7131): WARNING **: 02:01:34.174:
error raised: [load_xbel_store: couldn't load bookmark file [NULL]
]


(mate-appearance-properties:7136): appearance-properties-WARNING **:
02:01:40.866: Could not load user interface file: Failed to open file
“/usr/share/mate-control-center/ui/appearance.ui”: No such file or directory



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

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

Versions of packages mate-control-center-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1

mate-control-center-common recommends no packages.

mate-control-center-common suggests no packages.

-- no debconf information

Bug#954468: src:pyethash: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:pyethash
Version: 0.1.27-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag since that's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954469: src:pyrlp: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:pyrlp
Version: 0.5.1-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag since it's the closes we have

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954483: src:wand: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:wand
Version: 0.5.9-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954482: src:pyx3: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:pyx3
Version: 0.15-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954485: RFS: bittwist/1.0-3 [QA] -- libpcap based Ethernet packet generator

[Thiago]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "bittwist"
My VCS is here: https://salsa.debian.org/thiago-guest/bittwist
Please, after review give me rights to push to 
https://salsa.debian.org/debian/bittwist

 * Package name: bittwist
   Version : 2.0-14
   Upstream Author : Addy Yeow Chin Heng 
 * URL : http://bittwist.sf.net
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/bittwist
   Section : net

It builds those binary packages:

  bittwist - libpcap based Ethernet packet generator

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bittwist/bittwist_2.0-14.dsc

Changes since the last upload:

   * QA upload.
   * debian/copyright:
   - Added packaging rights for me.
   - Using a secure copyright format in URI.
   * debian/patches/10_fix-gcc-warning.patch: updated to fix a build warning.

Regards,

Thiago Andrade

-- 
...
⢀⣴⠾⠻⢶⣦⠀ Thiago Andrade Marques
⣾⠁⢰⠒⠀⣿⡁ GPG: 4096R/F8CDB08B
⢿⡄⠘⠷⠚⠋⠀ GPG Fingerprint: 1D38 EE3C 624F 955C E1FA  3C85 5A30 3591 F8CD B08B
⠈⠳⣄ 

Bug#954484: lintian: should warn when changelog entry contains `Closes;` instead of `Closes:`

[Sandro Tosi]

Package: lintian
Version: 2.41.0
Severity: normal

Hello,
it just happened at 
https://packages.qa.debian.org/p/python-pysnmp4/news/20200321T024507Z.html
and maybe it's just me, but ; and : are on the same key in the english keyboard
and typing quickly it could lead to enter one instead of the other.

Maybe the dh tools in charge of generating the .changes file should be smart
enough to detect `closes;` and still close the bug, but for now lintian seems a
good first step to help avoiding to close a bug becase of a typo.

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

Versions of packages lintian depends on:
ii  binutils  2.32.51.20190821-2
ii  bzip2 1.0.6-9.1
ii  diffstat  1.63-1
ii  dpkg  1.19.7
ii  dpkg-dev  1.19.7
ii  file  1:5.35-4
ii  gettext   0.19.8.1-9
ii  gpg   2.2.13-2
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b2
ii  libarchive-zip-perl   1.64-1
ii  libberkeleydb-perl0.62-1+b1
ii  libcapture-tiny-perl  0.48-1
ii  libcgi-pm-perl4.40-1
ii  libclass-accessor-perl0.51-1
ii  libclass-xsaccessor-perl  1.19-3+b3
ii  libclone-perl 0.41-1+b2
ii  libdpkg-perl  1.19.7
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libio-async-loop-epoll-perl   0.20-1
ii  libio-async-perl  0.72-1
ii  libipc-run-perl   20180523.0-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  libmldbm-perl 2.05-2
ii  libmoo-perl   2.003004-2
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.108-1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u2
ii  libperl5.26 [libdigest-sha-perl]  5.26.2-2
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.004004-1
ii  liburi-perl   1.76-1
ii  libxml-libxml-perl2.0134+dfsg-1+b1
ii  libyaml-libyaml-perl  0.80+repack-2+b1
ii  man-db2.8.5-2
ii  patchutils0.3.4-2
ii  perl [libdigest-sha-perl] 5.30.0-8
ii  t1utils   1.41-3
ii  xz-utils  5.2.4-1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b4
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#936957: llvm-toolchain-6.0: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:25:01 + Matthias Klose  wrote:
> Package: src:llvm-toolchain-6.0
> Version: 1:6.0.1-11
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

as part of this effort, during tomorrow US daytime i'll likely upload
a NMU to drop the -doc packages (this package already has a RM bug
opened): this will help reducing the number of reverse-dependencies of
python-sphinx, so that we can remove that package and upgrade
src:sphinx in unstable to a more recent version (which is now
python3-only).

if you can add me to the llvm team on salsa.d.o i can commit my
changes there and do a team upload (with whatever other changes are
currently pending in git since last upload)

thanks,
Sandro

Bug#936958: llvm-toolchain-7: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:25:02 + Matthias Klose  wrote:
> Package: src:llvm-toolchain-7
> Version: 1:7.0.1-9
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

as part of this effort, during tomorrow US daytime i'll likely upload
a NMU to drop the -doc packages (this package already has a RM bug
opened): this will help reducing the number of reverse-dependencies of
python-sphinx, so that we can remove that package and upgrade
src:sphinx in unstable to a more recent version (which is now
python3-only).

if you can add me to the llvm team on salsa.d.o i can commit my
changes there and do a team upload (with whatever other changes are
currently pending in git since last upload)

thanks,
Sandro

Bug#954402: m2crypto: FTBFS since openssl 1.1.1e

[Sandro Tosi]

> The package FTBFS since openssl has been updated to 1.1.1e because the
> testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> while reading in libssl") [0] in openssl. There an issue ticket [1]
> which introduced the changed behaviour.
>
> [0] https://github.com/openssl/openssl/pull/10882
> [1] https://github.com/openssl/openssl/issues/10880

what should i do about it on the m2crypto side?

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

Bug#954426: send-unmatched fail

[황병희]

soyeo...@doraji.xyz (황병희) writes:

> Package: bugs.debian.org
>
> Hello,
>
> For test, i did send mail to requ...@bugs.debian.org.
> With command "send-unmatched last|-1" in body exactly.
>
> Then i did get replying mail from BTS:
>
>  Unknown command or malformed arguments to command.
>
> I guess BTS have some problem.
>
> Full log: https://gitlab.com/soyeomul/Gnus/-/raw/master/ss/1506

That is deprecated command?

Sincerely, Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Bug#954467: src:pydbus: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:pydbus
Version: 0.6.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest one we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954477: src:python-jsonext: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:python-jsonext
Version: 0.4.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954479: src:python-pynvim: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:python-pynvim
Version: 0.4.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954478: src:python-pbkdf2: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:python-pbkdf2
Version: 1.3+20110613.git2a0fb15~ds0-3.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954476: src:python-jsbeautifier: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:python-jsbeautifier
Version: 1.10.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954460: remove mentions of "volatile" repo from sources.list

[Samuel Henrique]

Package: apt-setup
Severity: wishlist
Tags: patch

Forwarding MR from salsa here:

I just found out that volatile is still mentioned in sources.list,
which I consider outdated and confusing for the end user. This MR
changes the wording of the comment in the sources.list to address
that.

Please feel free to change the wording as you find appropriate.

https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/3

patch:
https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/3/diffs?commit_id=8de2bfd444c383867f31680de2b9dadbf61e601b

--
Samuel Henrique 

Bug#951944: src:ariba: Autopkgtest failure aused by use of py3versions -i

[Scott Kitterman]

Package: src:ariba
Version: 2.14.4+ds-2
Followup-For: Bug #951944

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#937658: python-concurrent.futures: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:37:39 + Matthias Klose  wrote:
> Package: src:python-concurrent.futures
> Version: 3.3.0-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

we're still not ready to drop this package, but i'll remove its
documentation, in order to reduce python-sphinx rdeps

Bug#954470: src:pysha3: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:pysha3
Version: 1.0.2-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag since that's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#953963: closed by Debian FTP Masters (reply to Ximin Luo ) (Bug#953963: fixed in tree-style-tab 3.4.7-1)

[Yuya Nishihara]

It works with the existing profile, thanks.

Regards,

Bug#954486: mirror submission for mirrors.ptisp.pt

[Eduardo Silvestre]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.ptisp.pt
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Eduardo Silvestre 
Country: PT Portugal
Location: Lisbon
Sponsor: PTISP https://ptisp.pt/




Trace Url: http://mirrors.ptisp.pt/debian/project/trace/
Trace Url: http://mirrors.ptisp.pt/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.ptisp.pt/debian/project/trace/mirrors.ptisp.pt

Bug#916594: [Pkg-mozext-maintainers] Bug#919557: webext-umatrix: garbled display of toolbar menu in Firefox 64.0-1

[Paul Wise]

On Sat, 2020-03-21 at 16:44 +, Ximin Luo wrote:

> This is because codemirror is also symlinked, and that dialog uses
> codemirror. To work-around locally, do the same thing as for
> punycode:
> 
> $ sudo rm /usr/share/webext/umatrix/lib/codemirror
> $ sudo cp -a /usr/share/javascript/codemirror
> /usr/share/webext/umatrix/lib/codemirror

I've purged webext-umatrix and removed all of the workarounds I had
before. Then I installed webext-umatrix 1.4.0+dfsg-1.

These symlinks were present after that:

   $ find /usr/share/webext/umatrix/ -type l -ls
27034549  0 lrwxrwxrwx   1 root root   30 Mar 22 00:34 
/usr/share/webext/umatrix/lib/codemirror -> ../../../javascript/codemirror
27034550  0 lrwxrwxrwx   1 root root   40 Mar 22 00:34 
/usr/share/webext/umatrix/lib/punycode.js -> 
../../../javascript/punycode/punycode.js
27034547  0 lrwxrwxrwx   1 root root   42 Mar 22 00:34 
/usr/share/webext/umatrix/css/fonts/Roboto_Condensed -> 
../../../../fonts/truetype/roboto/unhinted
27034548  4 lrwxrwxrwx   1 root root   63 Mar 22 00:34 
/usr/share/webext/umatrix/css/fonts/fontawesome-webfont.ttf -> 
../../../../fonts/truetype/font-awesome/fontawesome-webfont.ttf
27034546  0 lrwxrwxrwx   1 root root   27 Mar 22 00:34 
/usr/share/webext/umatrix/assets/thirdparties/publicsuffix.org/list -> 
../../../../../publicsuffix

For the following tests I used a temporary profile script:

   #!/bin/sh
   set -e
   dir="$(mktemp --tmpdir --directory firefox-esr-tmp-profile-)"
   cleanup () { rm --recursive --force "$dir"; }
   trap cleanup EXIT
   firefox-esr -no-remote -profile "$dir" "$@" || true

I noticed firefox-esr 68.6.0esr-1 still loads webext-* addons.

I noticed firefox 74.0-1 does not load any Debian addons at all.
Other Debian folks don't seem to have this issue, not sure why.

I noticed firefox-esr still has the problems with webext-umatrix.

Then I did the following workarounds:

$ sudo rm -f /usr/share/webext/umatrix/lib/codemirror ; sudo cp -a 
/usr/share/javascript/codemirror/ /usr/share/webext/umatrix/lib/codemirror
$ sudo rm -f /usr/share/webext/umatrix/lib/punycode.js ; sudo cp 
/usr/share/javascript/punycode/punycode.js 
/usr/share/webext/umatrix/lib/punycode.js
$ sudo rm -f /usr/share/webext/umatrix/lib/codemirror/codemirror.* ; sudo cp -a 
/usr/share/javascript/codemirror/lib/codemirror.* 
/usr/share/webext/umatrix/lib/codemirror/
$ sudo rm -f /usr/share/webext/umatrix/css/fonts/Roboto_Condensed ; sudo cp -a 
/usr/share/fonts/truetype/roboto/unhinted 
/usr/share/webext/umatrix/css/fonts/Roboto_Condensed
$ sudo rm -f /usr/share/webext/umatrix/css/fonts/fontawesome-webfont.ttf ; sudo 
cp -a /usr/share/fonts/truetype/font-awesome/fontawesome-webfont.ttf 
/usr/share/webext/umatrix/css/fonts/fontawesome-webfont.ttf
$ sudo rm -f 
/usr/share/webext/umatrix/assets/thirdparties/publicsuffix.org/list ; sudo cp 
-a /usr/share/publicsuffix 
/usr/share/webext/umatrix/assets/thirdparties/publicsuffix.org/list 
$ sudo rm -f 
/usr/share/webext/umatrix/assets/thirdparties/publicsuffix.org/list/effective_tld_names.dat
 ; sudo cp -a 
/usr/share/webext/umatrix/assets/thirdparties/publicsuffix.org/list/public_suffix_list.dat
 
/usr/share/webext/umatrix/assets/thirdparties/publicsuffix.org/list/effective_tld_names.dat

The result was the following:

The My Rules page shows up sensibly.

I cannot load any sites, it just seems to spin around trying to load
and making no progress. If I have the network panel open in developer
tools it doesn't list any requests. When I disable the umatrix addon
then it immediately loads the site I was trying to load. It appears the
default rules have a block everything rule but even if I remove that
rule and reload the same thing happens. In my main profile I don't have
this issue for some reason.

The toolbar menu has some issues:

 * the size is wrong so the Revert all button is missing
 * I cannot select the global/domain scopes properly
 * the list of sites loaded by the page is not displayed, just the
   "all" line is present in the toolbar menu thing.
* I observed this in my main profile since the temp profile didn't
  load any sites successfully.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#954462: src:m2crypto: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:m2crypto
Version: 0.31.0-9
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using FTBFS as a tag since it is the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954461: src:editorconfig-core-py: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:editorconfig-core-py
Version: 0.12.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Used FTBFS as a tag, since it's the closes we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#943097: 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)

All it would take to fix #943097 in unstable is to just replace
python-sphinx with python3-sphinx: i just finished a test rebuild and
the documentation builds just fine.

I dont know what your plans are to upload the ghc version in
experimental (with this fix) to unstable is, but if you want i can
upload a really simple NMU to make the change above; this will allow
to decrease the reverse dependencies of python-sphinx, so that we can
remove it.

Regards,
Sandro

Bug#954465: O: xstarfish -- X wallpaper generator

[Adam Borowski]

Package: wnpp
Severity: normal

Hi!
As this package's source causes notorious QA woe (source fails to unpack on
some filesystems, there are invalid tarballs inside, lots of binary junk
from a proprietary MacOS (not even OSX) tool, compiled binaries, etc)
-- and, the package hasn't seen a maintainer upload in ten years, I'm
orphaning it now.

The package description is:
 XStarfish generates colourful, tiled images for your background using random
 numbers fed through mathematical functions. It does not use source image
 files, so it can generate its images nearly forever without running out of
 material.

Bug#952541: patch proposed

[Glenn Strauss]

lighttpd ssl.* directives can be inherited from the global scope
(without needing to be repeated in each condition) if the only ssl.*
directive in a socket condition is
  $SERVER["socket"] == "..." { ssl.engine = "enable" }

conf-available/10-ssl.conf and use-ipv6.pl can be modifed to achieve
the behavior requested in this bug.

Proposed patch:
https://salsa.debian.org/debian/lighttpd/-/commit/3487cb5dbf39a588af2134822c64fdcae197a523

Bug#954471: src:pystemd: Autopkgtest failure due to use of py3versions -iwq

[Scott Kitterman]

Package: src:pystemd
Version: 0.7.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954475: Mangled mail with dkim_feature on

[David Prévot]

Package: sympa
Version: 6.2.40~dfsg-1
Severity: normal

Hi,

Once dkim_feature is activated on a list, the messages received from
sympa get mangled: the following headers are added *after* the messages
body (at the end of the message):

Message-Id: <…[random string from the server]…>
From: Sympa mailing list manager <…[list address]…>
Date: [date]

Because of that, the messages appear empty in any MUA (but are properly
added and visible in the web archive).

Please note that the DKIM-Signature header properly gets added on the
messages.

I’ve added the following options in robot.conf: dkim_private_key_path
and dkim_selector, and then activated dkim_feature for one list
(actually, I initially noticed the issue with “dkim_feature on” in
robot.conf, and removed it to not break all hosted lists). The server is
running on Buster.

Regards

David


signature.asc
Description: PGP signature

Bug#954474: src:python-h2: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:python-h2
Version: 3.2.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954473: src:python-daemon: Autopkgtest failure due to use of py3versions -i

[Scott Kitterman]

Package: src:python-daemon
Version: 2.2.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using the FTBFS tag because it's the closest we have.

This package failed a recent autopkgtest and this is one of the blockers for
python3-defaults migration.  It failed because python3.7 was installed in the
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so
there's a small chance the root cause is different), the autopkgtest uses the
output of py3versions -i to iterate over available python3 versions.  The -i
flag indicates all installed versions.  In many cases python3.7 is still
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in
debian/tests/control and change the py3versions call to py3versions -s.  These
two steps will ensure all supported python3 interpreters are fully installed
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye,
please address this soon.  I'm open to doing NMUs if anyone would like the
support.  Please let me know if you would like for me to do that.

Scott K

Bug#954472: firefox: regression: webext-* packaged addons are not loaded in new profiles

[Paul Wise]

Package: firefox
Version: 74.0-1
Severity: important

Recently (I'm not sure when but probably 74.0) for new profiles Firefox
no longer loads any of the webext-* /usr/share/webext/ packaged addons
and they do not show up in the Extensions item in the about:addons
page. For existing profiles the Debian-packaged addons are still
working fine. I cannot see any warnings about this in the Firefox debug
output in a terminal. This issue does not happen with Firefox ESR 68.
I'm using this script to use a temporary profile:

   #!/bin/sh
   set -e
   dir="$(mktemp --tmpdir --directory firefox-tmp-profile-)"
   cleanup () { rm --recursive --force "$dir"; }
   trap cleanup EXIT
   firefox -no-remote -profile "$dir" "$@" || true

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(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.1-1
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   0.30-7
ii  libgssapi-krb5-2   1.17-6
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#954450: Problems with links on https://wiki.debian.org/Modules

[Paul Wise]

On Sat, Mar 21, 2020 at 8:06 PM Stefan Lithén wrote:

> The webpage https://wiki.debian.org/Modules has problems with some links.

The wiki is open for editing, please register an account and fix these
issues. In case you already tried to register an account and were
blocked, I have marked your email for auto-accept so you should be
able to register now.

> 1) The link to update-modules brings you to error page 
> https://dyn.manpages.debian.org/man/8/update-modules?

This doesn't appear to exist any more so the link can be deleted.

> 2) The link to depmod.conf brings you to error page 
> https://dyn.manpages.debian.org/man/5/depmod.conf?
> 3) The link to modprobe.conf brings you to japanise page 
> https://manpages.debian.org/buster/manpages-ja/modprobe.conf.5.ja.html

These should be updated to .d instead of .conf:

https://manpages.debian.org/buster/kmod/depmod.d.5.en.html
https://manpages.debian.org/buster/kmod/modprobe.d.5.en.html

PS: it might be a good idea to report a bug against kmod asking for
compatibility symlinks to be re-added to the package.

https://www.debian.org/Bugs/Reporting

-- 
bye,
pabs

https://wiki.debian.org/PaulWise