Bug#951304: dh-make-golang: Manage MIT (Expat) license

[Alois Micard]

Package: dh-make-golang
Version: 0.3.1-1
Severity: normal

Hello there!

I have used your tool to package some libraries, and I have noticed that the 
MIT license was not recognized.
As you can view on the MIT wikipedia page that "MIT License" may refer to the 
Expat License (used for the XML parsing library Expat). 
It was an historical naming.

I have submitted a pull request to fix it upstream: 
https://github.com/Debian/dh-make-golang/pull/133

Have a good day !

-
Aloïs Micard 

GPG: rsa4096/A5999EBDFC063F1F

Bug#951303: blender: Measure tool fails to snap with control key pressed

[Will C.]

Here's something that I found out:

While using the measuring tool, press Ctrl + Shift and drag around.
This will spawn some weird teleporting behavior to the measuring line.
After that, release the Shift key and then the measuring tool will
start snapping; however, the end result is still unusable since the
other end of the measure line has teleported to some random position.

Bug#951303: blender: Measure tool fails to snap with control key pressed

[William Chung]

Package: blender
Version: 2.81.a+dfsg-5
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Nothing. Just launch blender and start working.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Open blender. Press tab at the default scene with the cube. Then press Shift +
Spacebar, then M. Click and drag to start measuring while pressing the control
key. (Any control key will do).

   * What was the outcome of this action?

The measure line did not snap to edges nor verticies.

   * What outcome did you expect instead?

Measure tool to snap to verticies or edges as mentioned in the blender forums
here: https://devtalk.blender.org/t/measurement-tool-snapping/6342



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

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

Versions of packages blender depends on:
ii  blender-data  2.81.a+dfsg-5
ii  fonts-dejavu  2.37-1
ii  libavcodec58  7:4.2.2-1
ii  libavdevice58 7:4.2.2-1
ii  libavformat58 7:4.2.2-1
ii  libavutil56   7:4.2.2-1
ii  libboost-locale1.67.0 1.67.0-17
ii  libc6 2.29-10
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 [libgcc1]   10-20200204-1
ii  libgcc1   1:10-20200204-1
ii  libgl11.3.0-7
ii  libglew2.12.1.0-4+b1
ii  libgomp1  10-20200204-1
ii  libilmbase24  2.3.0-6
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libopenal11:1.19.1-1+b1
ii  libopencolorio1v5 1.1.1~dfsg0-5+b1
ii  libopenexr24  2.3.0-6
ii  libopenimageio2.1 2.1.10.1~dfsg0-5+b1
ii  libopenjp2-7  2.3.1-1
ii  libopenvdb5.2 5.2.0-7+b1
ii  libosdcpu3.4.03.4.0-6
ii  libosdgpu3.4.03.4.0-6
ii  libpcre3  2:8.39-12+b1
ii  libpng16-16   1.6.37-2
ii  libpython3.7  3.7.6-1+b1
ii  libsndfile1   1.0.28-6
ii  libspnav0 0.2.3-1+b2
ii  libstdc++610-20200204-1
ii  libswscale5   7:4.2.2-1
ii  libtbb2   2020.1-2
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.8-1
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxml2   2.9.4+dfsg1-8
ii  libxrender1   1:0.9.10-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-1.2

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#951302: timeshift: /mnt is used programmatically

[Nicholas Guriev]

Package: timeshift
Version: 19.01+ds-2
Severity: serious

Dear maintainer,

Please modify the timeshift program so that it does not use /mnt/timeshift or
any sub-directories under /mnt. FHS 3.0 says no package allowed to access this
directory directly. It is intended to use as a temporally mount point by a
system administrator[1]. Please switch to /run/timeshift instead.

On first run, if a user has a Btrfs root file system on an encrypted device by
LUKS and choose the BTRFS option in the Setup Wizard, the program automatically
creates the /mnt/timeshift/backup directory and mount there the device with the
root FS. On quit, this is not rolled back.

Such behavior violates the Debian Policy and potentially may cause to data loss
if there is something mounted by the user on their own.

 [1]: 
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#mntMountPointForATemporarilyMount

mymedia@barberry:~$ LANG=C sudo timeshift-gtk
First run mode (config file not found)
Selected default snapshot type: BTRFS
App config loaded: /etc/timeshift.json
Selected default snapshot device: /dev/sdb2

/dev/dm-2 is mounted at: /mnt/timeshift/backup, options: 
rw,relatime,ssd,space_cache,subvolid=5,subvol=/
/dev/dm-2 is mounted at: /mnt/timeshift/backup, options: 
rw,relatime,ssd,space_cache,subvolid=5,subvol=/
App config saved: /etc/timeshift.json
App config saved: /etc/timeshift.json
mymedia@barberry:~$ sudo rm /etc/timeshift.json 


-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages timeshift depends on:
ii  libc6   2.30-0ubuntu2
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-1build1
ii  libgee-0.8-20.20.2-1
ii  libglib2.0-02.62.1-1
ii  libgtk-3-0  3.24.12-1ubuntu1
ii  libjson-glib-1.0-0  1.4.4-2
ii  libvte-2.91-0   0.58.2-1ubuntu2
ii  psmisc  23.2-1
ii  rsync   3.1.3-6

timeshift recommends no packages.

timeshift suggests no packages.

-- no debconf information

Bug#951301: mark libaiksaurus-1.2-data Multi-Arch: foreign

[Helmut Grohne]

Package: libaiksaurus-1.2-data
Version: 1.2.1+dev-0.12-6.3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:abiword

abiword fails to satisfy its cross Build-Depends, because its transitive
dependency on libaiksaurus-1.2-data is not satisfiable. In general,
Architecture: all packages can never satisfy cross build dependncies
unless marked Multi-Arch: foreign or annotated :native. In this case,
the former is correct, because libaiksaurus-1.2-data does not have any
maintainer scripts nor dependencies that could induce
architecture-specific interfaces. Please consider applying the attached
patch. While at it, it also adds a few Multi-Arch: same annotations to
the library packages.

Helmut
diff --minimal -Nru aiksaurus-1.2.1+dev-0.12/debian/changelog 
aiksaurus-1.2.1+dev-0.12/debian/changelog
--- aiksaurus-1.2.1+dev-0.12/debian/changelog   2016-05-11 10:35:20.0 
+0200
+++ aiksaurus-1.2.1+dev-0.12/debian/changelog   2020-02-14 06:09:26.0 
+0100
@@ -1,3 +1,11 @@
+aiksaurus (1.2.1+dev-0.12-6.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark the -data package Multi-Arch: foreign. (Closes: #-1)
+  * Mark the libraries Multi-Arch: same.
+
+ -- Helmut Grohne   Fri, 14 Feb 2020 06:09:26 +0100
+
 aiksaurus (1.2.1+dev-0.12-6.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru aiksaurus-1.2.1+dev-0.12/debian/control 
aiksaurus-1.2.1+dev-0.12/debian/control
--- aiksaurus-1.2.1+dev-0.12/debian/control 2016-05-10 23:29:25.0 
+0200
+++ aiksaurus-1.2.1+dev-0.12/debian/control 2020-02-14 06:09:23.0 
+0100
@@ -10,6 +10,7 @@
 
 Package: libaiksaurus-1.2-dev
 Architecture: any
+Multi-Arch: same
 Section: libdevel
 Depends: libaiksaurus-1.2-0c2a (= ${binary:Version}),
  ${misc:Depends}
@@ -23,6 +24,7 @@
 
 Package: libaiksaurus-1.2-0c2a
 Architecture: any
+Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends},
@@ -55,6 +57,7 @@
 
 Package: libaiksaurus-1.2-data
 Architecture: all
+Multi-Arch: foreign
 Section: libs
 Depends: ${misc:Depends}
 Conflicts: libaiksaurus-data
@@ -67,6 +70,7 @@
 
 Package: libaiksaurusgtk-1.2-dev
 Architecture: any
+Multi-Arch: same
 Section: libdevel
 Depends: libaiksaurusgtk-1.2-0c2a (= ${binary:Version}),
  ${misc:Depends}
@@ -82,6 +86,7 @@
 
 Package: libaiksaurusgtk-1.2-0c2a
 Architecture: any
+Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}

Bug#951250: rtl-sdr package lacks example udev rules, readme file

[A. Maitland Bottoms]

On Wed, 12 Feb 2020 22:12:42 -0700
Eric Jorgensen  wrote:

> Package: rtl-sdr
> Version: 0.6-2
> Severity: minor
> 
> The osmocom rtl-sdr source includes an example udev rules file that
> is of some importance to the end user but is not included
> in /usr/share/doc/rtl-sdr/examples/

I feel that I need to point out that rtl-sdr depends upon the library
package librtlsdr0 which ships /lib/udev/rules.d/60-librtlsdr0.rules
ready to provide instant gratification to Debian users.

The debian package configures rtl-sdr with

 -DDETACH_KERNEL_DRIVER=ON
 -DENABLE_ZEROCOPY=ON
 -DINSTALL_UDEV_RULES=ON

And yes, I did not feel that the README was useful enough to ship.

But Debian policy likes man pages, so the man page I prepared for
rtl-sdr does refer to the wiki URL in the SEE ALSO section.

Thanks for your interest in rtl-sdr. It can be a lot of fun.
And Debian is a good way to use such devices. Other Debian packages
might be of interest...

 $ apt-cache rdepends librtlsdr0
librtlsdr0
Reverse Depends:
  rtl-433
  welle.io
  svxlink-server
  svxlink-calibration-tools
  remotetrx
  soapysdr0.7-module-rtlsdr
  sdrangelove
  rtl-sdr
  librtlsdr-dev
  libgnuradio-osmosdr0.1.4

... that last providing rtl-sdr blocks for gnuradio
and, gqrx-sdr can use rtl-sdr via gnuradio or soapy modules.

I hope you find it actually just works for you.
(If not, then there is a real bug.)

-Maitland

Bug#951300: python3-vtk7: can python extensions be built for all python versions?

[Drew Parsons]

Package: python3-vtk7
Version: 7.1.1+dfsg2-2
Severity: normal

Currently python3-vtk7 only builds .so extensions for python3.7.
So `import vtk` fails on python3.8.

Is it feasible to expand the build to cover all available python
versions?


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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (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 python3-vtk7 depends on:
ii  libc6   2.29-10
ii  libstdc++6  10-20200211-1
ii  libvtk7.1p  7.1.1+dfsg2-2
ii  libvtk7.1p-qt   7.1.1+dfsg2-2
ii  python3 3.7.5-3
ii  python3-autobahn17.10.1+dfsg1-6
ii  python3-mpi4py  3.0.3-4
ii  python3-six 1.14.0-2
ii  python3-twisted 18.9.0-6
ii  python3-zope.interface  4.6.0-4

python3-vtk7 recommends no packages.

Versions of packages python3-vtk7 suggests:
pn  mayavi2
pn  vtk7-doc   
pn  vtk7-examples  

-- no debconf information

Bug#936806: koji: Python2 removal in sid/bullseye

[Marek Marczykowski-Górecki]

On Fri, Feb 14, 2020 at 01:30:29AM +, Holger Levsen wrote:
> On Thu, Feb 13, 2020 at 08:14:11PM -0500, Sandro Tosi wrote:
> > thanks! I'm gonna go ahead and file an RM bug for the following pkgs
> > too: yum createrepo python-lzma yum-metadata-parser mock yum-utils
> > dtc-xen deltarpm
> > 
> > they are a closed set
> 
> thank you for cleaning up after all of us, now that we reached containers.
> (which used to be called virtualisation mainframes before... ;) 
> 
> I mean, rpm is definitly still useful to have on Debian, but yum and 
> friends???

They are also useful in some cases. For example if you want to use
Debian-based VM to download updates for your Qubes dom0...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature

Bug#947298: ipython-py2: Python2 removal in sid/bullseye

[Sandro Tosi]

> > (source:ipython-py2)Build-Depends->python-matplotlib
> ...
>
> Do you think it would be possible to remove that build-depends (my

I've actually tried to rebuild ipython-py2 without mpl and it builds
fine: are you ok with me making an upload with that b-d removed?

Bug#947298: ipython-py2: Python2 removal in sid/bullseye

[Sandro Tosi]

On Mon, 23 Dec 2019 22:43:00 -0500 Sandro Tosi  wrote:
> Source: ipython-py2
> Version: 5.8.0-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
...
> (source:ipython-py2)Build-Depends->python-matplotlib
...

Hey Gordon,
ipython-py2 is the last reverse dependency (in testing, non RC-buggy)
of matplotlib.

It looks like the package only declares a build-depend on mpl, while
the binary packages dont.

Do you think it would be possible to remove that build-depends (my
impression is that it wouldnt diminish much the functionalities, as
the bin packages are not depending on it, so it's probably a matter of
documentation or tests?) so that i can remove the python2 version of
matplotlib from Debian?

that in turn would allow many other packages to be removed as well.

Thanks,
Sandro

Bug#936806: koji: Python2 removal in sid/bullseye

[Holger Levsen]

On Thu, Feb 13, 2020 at 08:14:11PM -0500, Sandro Tosi wrote:
> thanks! I'm gonna go ahead and file an RM bug for the following pkgs
> too: yum createrepo python-lzma yum-metadata-parser mock yum-utils
> dtc-xen deltarpm
> 
> they are a closed set

thank you for cleaning up after all of us, now that we reached containers.
(which used to be called virtualisation mainframes before... ;) 

I mean, rpm is definitly still useful to have on Debian, but yum and friends???


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


signature.asc
Description: PGP signature

Bug#951299: RM: yum createrepo python-lzma yum-metadata-parser mock yum-utils dtc-xen deltarpm -- RoQA; old RH software; python2; better alternatives exist (not in debian yet)

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
the following packages list is a closed set of packages (no external
dependencies outside of the set):

yum createrepo python-lzma yum-metadata-parser mock yum-utils dtc-xen deltarpm

they are part of what it used to be the redhat packages set in Debian. they have
been long abandoned upstream (replaced by dnf, still not packaged for Debian
yet) and they are all still python2 only with no upstream support (so also no
hope to get them ported to py3k).

dak confirms there are no issues removing them, and you can read additional
discussion about them (and other packages) in #936806

```
$ dak rm -Rn yum createrepo python-lzma yum-metadata-parser mock yum-utils 
dtc-xen deltarpm
Will remove the following packages from unstable:

createrepo |   0.10.3-1 | source, all
  deltarpm | 3.6+dfsg-1.1 | source
  deltarpm | 3.6+dfsg-1.2 | source, amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
   dtc-xen | 0.5.17-1.2 | source, all
dtc-xen-firewall | 0.5.17-1.2 | all
  mock |1.3.2-2 | source, all
python-deltarpm | 3.6+dfsg-1.1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
python-lzma |0.5.3-4 | source, amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
python-sqlitecachec | 1.1.4-1+b2 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
python3-deltarpm | 3.6+dfsg-1.2 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
   yum |3.4.3-3 | source, all
yum-metadata-parser |1.1.4-1 | source
 yum-utils |   1.1.31-4 | source, all

Maintainer: Thomas Goirand , RPM packaging team 
, Mike Miller , Debian 
Python Modules Team , Tzafrir 
Cohen , Mike Miller 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.
```

please remove these packages from Debian.

Thanks,
Sandro

Bug#936806: koji: Python2 removal in sid/bullseye

[Sandro Tosi]

On Sat, Feb 8, 2020 at 1:51 PM Moritz Mühlenhoff  wrote:
>
> On Thu, Jan 30, 2020 at 01:36:33AM -0500, Sandro Tosi wrote:
> > > > koji is keeping createrepo in the archive, which keeps python-lzma in
> > > > the archive.
> > >
> > > there's also mock, yum, rpm, deltarpm and yum-metadata-parser affected by 
> > > this.
> >
> > yep i came across all of them starting from python-lzma -- do you know
> > what's the status of the "RedHat infrastructure" in debian? many (if
> > not all) of those tools are relatively old, not maintained (or just in
> > life support mode) and most of all, python2 with no port to python3
> > available
> >
> > > > upgrading koji will help getting rid of some old python2 packages.
> > >
> > > dropping it, at least for now, seems to be the best way foreward here :/
> >
> > Allright then, i'll just wait a week for allowing people to comment
> > and then i'll file for koji removal.
>
> Since there were no further objections I've just filed a removal bug.

thanks! I'm gonna go ahead and file an RM bug for the following pkgs
too: yum createrepo python-lzma yum-metadata-parser mock yum-utils
dtc-xen deltarpm

they are a closed set (no external dependencies outside that set,
tested via `dak rm -Rn list_of_pkgs`) of obsolete "redhat-related",
python2, packages.

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

Bug#951298: RM: u1db -- ROM; No longer used or maintained

[Micah Anderson]

Package: ftp.debian.org
Severity: normal

Hello, World

As the original packager for u1db, I'd like to request removal, as it is no 
longer maintained upstream, nor is it needed.

Thank you!
Micah

Bug#938737: u1db: Python2 removal in sid/bullseye

[micah anderson]

Moritz Mühlenhoff  writes:

> On Fri, Aug 30, 2019 at 07:57:06AM +, Matthias Klose wrote:
>> Package: src:u1db
>> Version: 13.10-6.4
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
>> 
>> Python2 becomes end-of-live upstream, and Debian aims to remove
>> Python2 from the distribution, as discussed in
>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>> 
>> Your package either build-depends, depends on Python2, or uses Python2
>> in the autopkg tests.  Please stop using Python2, and fix this issue
>> by one of the following actions.
>
> Hi Micah,
> per Wikipedia the Ubuntu One cloud storage has been shut down many years
> ago, should this simply be removed?

We were not using it for Ubuntu One cloud storage, but instead as its
more generic use case as "a cross-platform, cross-device, syncable
database API", which we modified to have client-side encrypted database
replicas and documents.

However, it is not being used any longer, and should simply be removed.

-- 
micah

Bug#951297: ITP: gofeed -- Parse RSS and Atom feeds in Go

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: gofeed
  Version : 1.0.0-beta2-1
  Upstream Author :
* URL : https://github.com/mmcdole/gofeed
* License : MIT
  Programming Lang: Go
  Description : Parse RSS and Atom feeds in Go

This package is needed for goland-terminews.

Thanks in advance.

-
Aloïs Micard 

GPG: rsa4096/A5999EBDFC063F1F

Bug#951296: apt: please "apt-key is-trusted" command

[Johannes 'josch' Schauer]

Package: apt
Version: 1.8.4
Severity: wishlist

Hi,

this bug is a follow up of

https://lists.debian.org/20200207000348.neeqjzu3qx6zwnul@crossbow

mmdebstrap wants to have an answer to the question "does apt trust this
key" and it would be nice if the answer would come from apt directly
because what I'm currently doing, is to manually invoke gpg on whatever
I find in /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/, list the
fingerprints and check whether the fingerprint I am looking for is in
the result or not.

DonKult proposed the following patch:

 diff --git a/cmdline/apt-key.in b/cmdline/apt-key.in
 @@ -781,6 +781,16 @@ case "$command" in
 warn_on_script_usage
 foreach_keyring_do 'list_keys_in_keyring' --fingerprint "$@"
 ;;
 +is-trusted)
 +   merge_all_trusted_keyrings_into_pubring
 +   if [ "$#" = '0' -o "$(aptkey_execute "$GPG_SH" --keyring 
"${GPGHOMEDIR}/pubring.gpg" --with-colons --list-keys "$@"
 2>/dev/null | grep -c '^pub:')" != "$#" ]; then
 +  exit 1
 +   fi
 +   ;;
 +list-fingerprints)
 +   setup_merged_keyring
 +   aptkey_execute "$GPG" --with-colons --list-keys 2>/dev/null | grep 
'^fpr:' | cut -d':' -f 10
 +   ;;
  export|exportall)
 warn_on_script_usage
 merge_all_trusted_keyrings_into_pubring

For my purposes I basically don't care whether apt gives me the key
material itself or just a list of fingerprints as proposed above. The
only improvement would be, if I could also pass a keyring filename
because with the above I would still have to run gpg to extract the
fingerprint from the filename I have.

Something like this would be ideal:

$ apt-key is-trusted /usr/share/keyrings/debian-archive-keyring.gpg
$ echo $?
0

Thanks!

cheers, josch

Bug#951295: ITP: golang-github-mmcdole-goxpp -- Go XML Pull Parser

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-mmcdole-goxpp
  Version : 0.0~git20181012.0068e33-1
  Upstream Author :
* URL : https://github.com/mmcdole/goxpp
* License : MIT
  Programming Lang: Go
  Description : Go XML Pull Parser

This package is needed for gofeed library.

Thanks in advance.

-
Aloïs Micard 

GPG: rsa4096/A5999EBDFC063F1F

Bug#951294: parsec47: exits with an error immediately after starting

[Brian Vaughan]

Package: parsec47
Version: 0.2.dfsg1-9
Severity: grave
Justification: renders package unusable

The window opens and immediately closes. From the command line:

$ parsec47
parsec47: symbol lookup error: parsec47: undefined symbol:
_D3std5stdio24__T10makeGlobalS6stderrZ10makeGlobalFNbNcNdNiZS3std5stdio4File



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

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

Versions of packages parsec47 depends on:
ii  libbulletml0v5   0.0.6-7
ii  libc62.29-10
ii  libgcc-s1 [libgcc1]  10-20200211-1
ii  libgcc1  1:10-20200211-1
ii  libgl1   1.3.0-7
ii  libgphobos76 9.2.1-28
ii  libsdl-mixer1.2  1.2.12-16+b1
ii  libsdl1.2debian  1.2.15+dfsg2-5
ii  parsec47-data0.2.dfsg1-9

parsec47 recommends no packages.

parsec47 suggests no packages.

-- no debconf information

Bug#799632: Greetings

[Barr. Roy Gbesse]

Please, I have urgent information for you. kindly contact me back for
more details, I await your urgent response.

Yours sincerely
Barr.Roy Gbesse

Bug#948224: pillow: CVE-2020-5310 CVE-2020-5311 CVE-2020-5312 CVE-2020-5313

[Robert Scott]

FWIW I'm fairly convinced that the first vulnerable version for CVE-2020-5310 
is 6.0.0, which is the first release that included 
https://github.com/python-pillow/Pillow/commit/e91b851fdc1c914419543f485bdbaa010790719f
 which introduced 
the overflow when switching away from the safer TIFFTileSize & TIFFStripSize 
in the critical lines.

So you can probably mark 5.4.1 as safe for CVE-2020-5310


robert.

Bug#951241: ocamlweb: build dependencies are incomplete

[Norbert Preining]

Hi Ralf,

> It should be added to the Recommends of the binary package, and to
> the Dependencies of the test. Thanks for the hint! Will upload a
> fixed package quickly.

Thanks a lot!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951115: Bug opened

[Martin Quinson]

I just opened #951292:
RM: ns3 [mipsel] -- RoM, ANAIS; The package FTBFS on this architecture, because 
of the toolchain

Hopefully the package will be allowed to transition to testing before
18/2, the testing removal date. Or soon after.



signature.asc
Description: PGP signature

Bug#951237: glibc/mips: bpo patch: mips: Fix argument passing for inlined syscalls on Linux [BZ #25523]

[Aurelien Jarno]

On 2020-02-13 10:52, YunQiang Su wrote:
> Package: src:glibc
> Version: 2.29
> Severity: serious
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=25523
> https://sourceware.org/git/?p=glibc.git;a=commit;h=4fbba6fe904d0094ddc4284066b3860d119cbd4a
> 
> mips: Fix argument passing for inlined syscalls on Linux [BZ #25523]
> 

Note that Debian is currently not affected by the issue, at least for
that syscall, probably because we use a different baseline ISA (ie
MIPS64R2).

I have backported the issue upstream in version 2.31. Backporting it
into 2.30 requires a tiny bit more of work and testing, I'll do that in
the next days. Note that we are waiting for the green light from the
release team to upload 2.30 to unstable, so there is no need to fix
version 2.29.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#951292: RM: ns3 [mipsel] -- RoM, ANAIS; The package FTBFS on this architecture, because of the toolchain (see #951115)

[Martin Quinson]

Package: ftp.debian.org
Severity: normal

Hello all,

the linker dies with an OOM when trying to build ns3 on mipsel. As discussed in
#951115 with a mipsel porter (who happens to be a former maintainer of this
package), this architecture should be removed for that package for the time
being.

I uploaded a new version of the package, without mipsel, and I now need to get
that version transitionning to testing, please.

Please be patient if I'm not following the right procedure here. I'm
not asking for package removal every day...

Thanks for your work,
Mt.



Note: this was a request for a partial removal from testing, converted in one 
for unstable

-- 
Simplicity does not precede complexity, but follows it.
   -- "Epigrams in Programming", by Alan J. Perlis of Yale University.


signature.asc
Description: PGP signature

Bug#951293: procps: obsolete conffile left behind

[Sven Joachim]

Package: procps
Version: 2:3.3.16-1

This version of procps moved the file /etc/sysctl.d/protect-links.conf
to /usr/lib/sysctl.d/, but it remains on the system on upgrades as an
obsolete conffile.

Please refer to dpkg-maintscript-helper(1) and dh_installdeb(1) how to
properly clean up obsolete conffiles.


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

Kernel: Linux 5.5.3-nouveau (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)

Versions of packages procps depends on:
ii  init-system-helpers  1.57
ii  libc62.29-10
ii  libncurses6  6.1+20191019-1
ii  libncursesw6 6.1+20191019-1
ii  libprocps8   2:3.3.16-1
ii  libtinfo66.1+20191019-1
ii  lsb-base 11.1.0

Versions of packages procps recommends:
ii  psmisc  23.3-1

procps suggests no packages.

-- no debconf information

Bug#951115: New version uploaded

[Martin Quinson]

severity 951115 normal
thanks

Hello,

so I uploaded a version of this package without mipsel, and it built
nicely on all architectures where its dependencies are to be found
(all official architectures plus some others).

Thus downgrading this bug.

Thanks, Mt.


signature.asc
Description: PGP signature

Bug#938737: u1db: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:57:06AM +, Matthias Klose wrote:
> Package: src:u1db
> Version: 13.10-6.4
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

Hi Micah,
per Wikipedia the Ubuntu One cloud storage has been shut down many years
ago, should this simply be removed?

Cheers,
Moritz

Bug#951241: ocamlweb: build dependencies are incomplete

[Ralf Treinen]

Hallo Norbert,

On Thu, Feb 13, 2020 at 12:43:58PM +0900, Norbert Preining wrote:

> it seems that something in the autopkgtest or the build deps is
> incorrect:

> You need to add 
>   texlive-fonts-recommended
> to the build deps.

It should be added to the Recommends of the binary package, and to
the Dependencies of the test. Thanks for the hint! Will upload a
fixed package quickly.

Cheers -Ralf.

Bug#825781: libgit2: FTBFS on kfreebsd* and hurd-i386: testsuite problems

[Utkarsh Gupta]

Hi Andreas,

On Sun, 29 May 2016 21:17:56 +0200 Andreas Beckmann  wrote:


the current version of libgit2 FTBFS on !linux:
https://buildd.debian.org/status/fetch.php?pkg=libgit2=hurd-i386=0.24.1-2=1462259730
https://buildd.debian.org/status/fetch.php?pkg=libgit2=kfreebsd-amd64=0.24.1-2=1460548701
https://buildd.debian.org/status/fetch.php?pkg=libgit2=kfreebsd-i386=0.24.1-2=1460548603

If that is not trivially fixable, please request decrufting of the
outdated binary packages.


Is this bug still valid?
I intend to upload 0.28.4+dfsg.1-1 today; could you check against that 
and let me know if there's still a problem?


Though there have been many uploads after this bug report, I am not sure 
if this is still valid :)



Best,
Utkarsh

Bug#936521: flashproxy: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:17:13AM +, Matthias Klose wrote:
> Package: src:flashproxy
> Version: 1.7-4
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Hi,
https://crypto.stanford.edu/flashproxy/ states

| Status
|
| As of 2017, the flash proxy project is deprecated. It was deployed in Tor 
Browser
| between 2013 and 2016, but has since been superseded by newer and more 
effective
| pluggable transports. If you want to help support a newer circumvention system
| designed along the same principles as flash proxy, please see Snowflake.

Let's remove? Or is there any reason to keep it in Debian?

Cheers,
Moritz

Bug#951152: new archmage version breaks keepass2 documentation build

[Mikhail Gusarov]

fixed  951152  1:0.4.2.1-1
thanks

OK, 1:0.4.2.1-1 with the fix is in unstable.

On 11 Feb 2020, at 23:08, Julian Taylor wrote:


On 11.02.20 22:13, Mikhail Gusarov wrote:

Hi Julian,

On 11 Feb 2020, at 21:25, Julian Taylor wrote:


For keepass I only need to be able to build html files from the chm
source directory, the package has no compiled chm file one can use 
the

current cli functions on.


Please try
https://github.com/dottedmag/archmage/commit/c8f186dff0c8da56590e900cc2a32b39e19bf08b


- if it works, then I'll cut a new release and a package.



it is working great, thanks

Bug#951290: RM: reconf-inetd -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove reconf-inetd. It's orphaned RFAd (and thus dead upstream),
depends on Python 2 and there no reverse deps in the archive. The former
maintainer (CCed), acked the removal in #719792

Cheers,
Moritz

Bug#951289: weechat: CVE-2020-8955

[Salvatore Bonaccorso]

Source: weechat
Version: 2.6-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for weechat.

CVE-2020-8955[0]:
| irc_mode_channel_update in plugins/irc/irc-mode.c in WeeChat through
| 2.7 allows remote attackers to cause a denial of service (buffer
| overflow and application crash) or possibly have unspecified other
| impact via a malformed IRC message 324 (channel mode).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8955
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8955
[1] 
https://github.com/weechat/weechat/commit/6f4f147d8e86adf9ad34a8ffd7e7f1f23a7e74da

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#951288: recoverjpeg: Remove pandoc from Build-Depends

[Joao Eriberto Mota Filho]

Package: recoverjpeg
Severity: normal

The upstream maintain the same tarball version in GitHub[1] and in his
homepage[2]. The version in homepage already provides a manpage and is
the better version.

[1] https://github.com/samueltardieu/recoverjpeg
[2] https://rfc1149.net/devel/recoverjpeg.html

Please, use the version from homepage from now and drop pandoc.

Eriberto

Bug#951280: [duroux.patr...@orange.fr: Bug#951280: ncbi-blast+: runtime trap with at least blastn and makeblastdb]

[Aaron M. Ucko]

Hi, Andreas (and Olivier).

I saw this latest report, thanks, just wasn't able to comment
immediately.  Configuring ncbi-blast+ with the additional flag
--without-sse42 should address Patrice's error.

The other report (which I'd missed earlier, sorry) comes down to a
discrepancy between where different NCBI source bases look for
systemwide configuration files.  ncbi-data, which ships .ncbirc, places
it in /etc/ncbi per the expectations of the C Toolkit from which it
originates (ncbi-tools6), whereas C++ code (namely ncbi-blast+) looks
directly in /etc.  I suppose ncbi-data can and should gain /etc/.ncbirc
as a symlink to /etc/ncbi/.ncbirc.

I should be able to take care of both tweaks over the weekend.

-- Aaron

Andreas Tille  writes:

> Hi Aaron & Olivier,
>
> could you please have a look into this as well as
>
> https://lists.debian.org/debian-med/2020/01/msg00095.html
>
> (which probably should also be reported as bug).
>
> Both should be probably of higher severity since it affects usability
> of the program.
>
> Kind regards
>
>   Andreas.
>
> From: Patrice DUROUX 
> Subject: Bug#951280: ncbi-blast+: runtime trap with at least blastn and 
> makeblastdb
> To: Debian Bug Tracking System 
> Date: Thu, 13 Feb 2020 18:42:20 +0100 (55 minutes, 37 seconds ago)
> X-Debian-PR-Message: report 951280
> X-Debian-PR-Package: ncbi-blast+
> X-Debian-PR-Keywords: 
> X-Debian-PR-Source: ncbi-blast+
>
> Package: ncbi-blast+
> Version: 2.8.1-1
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> Running commands like one of the following:
>
> blastn -query test.fasta -subject test.fasta
>
> makeblastdb -dbtype nucl -in test.fasta
>
>* What was the outcome of this action?
>
> A runtime trap with a message 'Instruction non permise'
> (sorry for the french message, got the same in a LANG=C env)
>
> Here are extracts from dmesg:
>
> [16975777.040241] traps: blastn[16028] trap invalid opcode ip:7f5c96a4598c 
> sp:7ffece18a380 error:0 in libblast.so[7f5c96a04000+66000]
> [16976213.970602] traps: makeblastdb[17484] trap invalid opcode 
> ip:7fca6c0bfb02 sp:7ffe3fae78a0 error:0 in libxutil.so[7fca6c08c000+83000]
>
> and here is the output got using gdb and ncbi-blast+-dbgsym:
>
> gdb --args blastn -query test.fasta -subject test.fasta
> GNU gdb (Debian 8.2.1-2+b3) 8.2.1
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from blastn...Reading symbols from 
> /usr/lib/debug/.build-id/00/382f3290f9ed8c1cace9c6e03d714c031cbd3d.debug...done.
> done.
> (gdb) go
> Command requires an argument.
> (gdb) run
> Starting program: /usr/bin/blastn -query test.fasta -subject test.fasta
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> BLASTN 2.8.1+
>
> Program received signal SIGILL, Illegal instruction.
> 0x77afe98c in BLAST_ComputeLengthAdjustment (K=, 
> logK=-0.77652878949899629, alpha_d_lambda=1.171875, beta=-2, 
> query_length=query_length@entry=86, db_length=db_length@entry=86, 
> db_num_seqs=db_num_seqs@entry=1, 
> length_adjustment=length_adjustment@entry=0x7fffcf84)
> at ./c++/src/algo/blast/core/blast_stat.c:5093
> 5093  ./c++/src/algo/blast/core/blast_stat.c: No such file or directory.
> (gdb) 
>
> The CPU info of the hardware used to run the commands is:
>
> # lscpu
> Architecture:x86_64
> CPU op-mode(s):  32-bit, 64-bit
> Byte Order:  Little Endian
> Address sizes:   40 bits physical, 48 bits virtual
> CPU(s):  16
> On-line CPU(s) list: 0-15
> Thread(s) per core:  2
> Core(s) per socket:  2
> Socket(s):   4
> NUMA node(s):1
> Vendor ID:   GenuineIntel
> CPU family:  15
> Model:   6
> Model name:  Intel(R) Xeon(TM) CPU 3.40GHz
> Stepping:8
> CPU MHz: 3391.598
> BogoMIPS:6783.19
> Virtualization:  VT-x
> L1d cache:   16K
> L2 cache:1024K
> L3 cache:16384K
> NUMA node0 CPU(s):   0-15
> Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
> constant_tsc pebs bts nopl cpuid pni dtes64 monitor ds_cpl vmx est tm2 cid 
> cx16 xtpr pdcm lahf_lm pti 

Bug#951287: libgd2: CVE-2018-14553

[Salvatore Bonaccorso]

Source: libgd2
Version: 2.2.5-5.2
Severity: important
Tags: security upstream
Forwarded: https://github.com/libgd/libgd/pull/580
Control: found -1 2.2.4-2+deb9u5
Control: found -1 2.2.4-2

Hi,

The following vulnerability was published for libgd2.

CVE-2018-14553[0]:
| gdImageClone in gd.c in libgd 2.1.0-rc2 through 2.2.5 has a NULL
| pointer dereference allowing attackers to crash an application via a
| specific function call sequence. Only affects PHP when linked with an
| external libgd (not bundled).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-14553
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14553
[1] https://github.com/libgd/libgd/pull/580
[2] 
https://github.com/libgd/libgd/commit/a93eac0e843148dc2d631c3ba80af17e9c8c860f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#797965:

[Julius Willis]

Bug#642906: RFH: balsa -- An e-mail client for GNOME

[Daniel Kahn Gillmor]

Control: affects 642906 + src:balsa

On Mon 2011-09-26 10:24:34 +0200, Josselin Mouette wrote:
> Le lundi 26 septembre 2011 à 10:22 +0200, Maxime Chatelle a écrit :
>> Sorry for the late, I will take it over as we said earlier [1] if your
>> are ok again. With the holidays, I missed the time. (and a little bit
>> forgotten)
>
> Ah right, I forgot we already had someone interested /o\
>
> Please take it over when you have the time. We will remove it from the
> pkg-gnome repository when it’s done.

I haven't seen much activity on this RFH about balsa, and it looks like
it's been over a year since any version of balsa has been uploaded to
debian.

I've just NMUed balsa 2.5.9-0.1 to debian experimental, which fixes a
pretty severe bug (#911558).

I've also pushed a MR for these changes here:
https://salsa.debian.org/gnome-team/balsa/merge_requests/1, asking if i
can help out more directly (i don't have push access to the balsa repo
on salsa).

If you're ok with me helping out, it'd be most useful if i could have
access to push to the basla repo on salsa.

Also, if you want me to add myself to uploaders on the package, i'm
willing to do that.

A few notes about remaining packaging work i see ahead for balsa:

 - Change debian/changelog to DEP-5.

 - Split out the arch-independent stuff in /usr/share to a balsa-data
   package, to reduce the size of the archive (this requires a trip
   through NEW, sigh).

 - Add some sort of autopkgtest (maybe we need something like
   https://salsa.debian.org/debian/test-daemons to make a plausible test
   suite?)

 - Consider enabling newer upstream features like Autocrypt.

 - If we land 2.5.9 in unstable, consider importing upstream's gmime 3.0
   conversion work into debian/patches for unstable

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#951286: please split dovecot-lda in a separate binary package

[Antoine Beaupre]

Package: dovecot-core
Version: 1:2.3.4.1-5+deb10u1
Severity: wishlist

Dovecot does many things: filtering, IMAP, delivery, proxying - it's a
pretty powerful machine!

But sometimes all you want to do is deliver mail. It's kind of a
strange use case, but it does happen that you have this one node that
only takes email, and writes it to a (possibly shared) filesystem and
moves on, without ever allowing users to login through IMAP (or else)
to actually *read* that email.

In that environment, all that is needed is the `dovecot-lda`
binary. We don't need the IMAP server or any of the other fancy
stuff. We just want to deliver mail. In fact, having those services
running would be detrimental to the security of that component.

Of course it's possible to disable the service, but that requires some
wrangling with the init system (which can vary), while just installing
a "dovecot-lda" package would set clear expectations of what should
happen: only the LDA agent would be installed, and no service would be
running.

I'm looking for a replacement for procmail and maildrop, which do
provide that kind of minimalist functionality. Both of those programs
have problems: procmail is unmaintained and maildrop is limited in
functionality (e.g. no Sieve rules, not much support for
+extension). So I'm thinking of using dovecot for this instead, but
the prospect of deploying the full mail server is a little unnerving.

Could it be possible to have a package that *only* deploys dovecot-lda
and its associated configurations?

(The latter is of course the tricky bit: Dovecot is configured
globally, with config files affecting multiple binaries. It would
probably be difficult to split the config files in a way that would
make sense, but I'm wondering if dovecot-lda would work *without* any
configuration files at all, or maybe just with
/etc/dovecot/conf.d/15-lda.conf...)

Thank you for your time!

a.

-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.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 dovecot-core depends on:
ii  adduser  3.118
ii  libapparmor1 2.13.2-10
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libexttextcat-2.0-0  3.4.5-1
ii  libicu63 63.1-6
ii  liblua5.3-0  5.3.3-1.1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libpam-runtime   1.3.1-5
ii  libpam0g 1.3.1-5
ii  libsodium23  1.0.17-1
ii  libssl1.11.1.1d-0+deb10u2
ii  libstemmer0d 0+svn585-1+b2
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400
ii  openssl  1.1.1d-0+deb10u2
ii  ssl-cert 1.0.39
ii  ucf  3.0038+nmu1
ii  zlib1g   1:1.2.11.dfsg-1

dovecot-core recommends no packages.

Versions of packages dovecot-core suggests:
pn  dovecot-gssapi
pn  dovecot-imapd 
pn  dovecot-ldap  
pn  dovecot-lmtpd 
pn  dovecot-lucene
pn  dovecot-managesieved  
pn  dovecot-mysql 
pn  dovecot-pgsql 
pn  dovecot-pop3d 
pn  dovecot-sieve 
pn  dovecot-solr  
pn  dovecot-sqlite
pn  dovecot-submissiond   
ii  ntp   1:4.2.8p12+dfsg-4

Bug#948930: closed ... (Bug#948930: fixed in python-socksipychain 2.1.0-2)

[Paul Gevers]

Dear maintainers,

On 31-01-2020 11:54, Debian Bug Tracking System wrote:
>  python-socksipychain (2.1.0-2) unstable; urgency=medium

[...]

>* Migrate an autopkgtest to Python 3 from Python 2 (Closes: #948930)
>  (Closes: #938184).

Unfortunately the test now fails in a different way:

autopkgtest [15:55:40]: test command1: set -e ; for py in $(py3versions
-r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c
"import sockschain; print(sockschain)" ; done
autopkgtest [15:55:40]: test command1: [---
Testing with python3.8:
bash: python3.8: command not found
autopkgtest [15:55:40]: test command1: ---]

It seems you're missing a (test) dependency on python3-all (IIAC).

Also, please, for such superficial tests, mark them as superficial, see
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst.
The same applies for the other test.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#911558: balsa: Balsa can’t read some HTML mails

[Daniel Kahn Gillmor]

Control: tags 911558 + confirmed

On Tue 2019-11-12 21:36:05 +0100, G. Milde wrote:

> After updating to Buster, Balsa does no longer show HTML parts of mails.
>
> If the mail is mulitpart, text+mail, the text is visible.
> If the mail is just HTML, there is no text in the main window.
>
> Workaround: The text is visible in the editor window, when clicking "reply".

I used the attached message to replicate the behavior with the version
of balsa in buster (2.5.6-2).  However, it seems to be fixed with 2.5.9,
which i'm about to upload to experimental.

Attached is the sample e-mail i used for the test, and screenshots from
2.5.6 and 2.5.9.

Thanks,

--dkg

--- Begin Message ---
Title: Here is a title



This is a test HTML message
Can we do bold?



--- End Message ---


signature.asc
Description: PGP signature

Bug#947462: htslib: FTBFS on big-endian architectures

[Gianfranco Costamagna]

control: tags -1 patch

Hello Michael, upstream finally has a Big Endian fix!
(and probably it never worked before!)

https://github.com/samtools/htslib/pull/1023

On Thu, 9 Jan 2020 10:10:52 +0100 Michael Crusoe  
wrote:
> Control: severity -1 important
> Control: forwarded -1
> https://github.com/samtools/htslib/issues/355#issuecomment-566058829
> 
> Dear Graham,
> 
> Thank you for your report. This issues is already known by upstream. So as
> to not hold up multiple transitions, the s390x builds of htslib (and its
> reverse-dependencies) have been removed from the archive as per
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948092
> 
> Therefore I'm lowing the severity of this issue to important so htslib and
> the rest can all migrate to testing.
> 
> Hopefully upstream will find a solution soon.
> 
> Cheers,
> 
> -- 
> Michael R. Crusoe

Bug#944476: stable security support

[Patrick Schleizer]

Talked to upstream about stable security support.

To make Debian stable distribution support possible, upstream offered to
backport security patches from newer versions to whatever version is
frozen in Debian stable should that be required.

Mariusz Zaborski osho...@vexillium.org would do that.

Kind regards,
Patrick

Bug#942622: Would the Games Team adopt Lightyears (pygame based, Python 3 port available)?

[Steve Cotton]

Hi all in the Games Team,

One of the Debian games affected by the python3 transition is 2 Lightyears
Into Space, source package name "lightyears". I've ported it to python3-pygame,
and opened an upstream issue for merging it (sadly this doesn't have an
upstream response yet).

The Debian package isn't currently maintained by the Games Team, but one of the
serious bugs is "Maintainer email address not working". I'm wondering if the
Games Team would adopt it and apply my python3 port?

Debian bugs:
  #942622 src:lightyears: Maintainer email address not working
  #912488 lightyears: Please migrate to python3-pygame
  #936945 lightyears: Python2 removal in sid/bullseye

Upstream pull request:
  https://github.com/20kly/20kly/issues/2
  https://github.com/stevecotton/20kly/tree/version1.4/python3

The Debian package's "copyright" file cleans up some of the oddities of the
upstream README.md's licensing section, I'm sure it's distributable but expect
it to get some questions if it went through the NEW queue. Oddities such as
attributing an image as "copyright NASA" instead of saying that it's one of
NASA's public domain images. I'm happy to put some effort in to fixing that.

Thanks,
Steve

Bug#951251: RFS: ledmon/0.94-1 -- Enclosure LED Utilities

[Adam Borowski]

On Fri, Feb 14, 2020 at 12:52:55AM +0800, Woodrow Shen wrote:
> I don't why this bug needs to close, but anyway I will file a new bug after
> I fix all issues you mentioned.

It shouldn't have been closed, but apparently bartm's bot got confused.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Bug#951285: RM: html2canvas -- ROM; Unmaintained

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi,

I think that html2canvas could be removed:
 + looks orphaned here
   - last update 2016-12-11
   - blocked in unstable for a while
 + not easy to upgrade now (needs babel 7, some new typescript @types and
   many new modules)
 + unused:
   - popcon == 0 !
   - dak report shows no reverse build deps

Cheers,
Xavier

Bug#951070: debian-edu-config: make Debian-Edu_rootCA available via /etc/ssl/certs/ca-certificates.crt

[Wolfgang Schweer]

On Wed, Feb 12, 2020 at 08:20:08PM +0100, Wolfgang Schweer wrote:
> On Wed, Feb 12, 2020 at 07:09:21PM +, Mike Gabriel wrote:
> > The simpleness of the fetch-ldap-cert version you propose is 
> > tempting. But this version will only work against TJENERs that have 
> > a Debian-Edu_rootCA.crt exported via www.intern.

Considering...

[Mike]

> This assures that Debian-Edu_rootCA is available in the system-wide CA 
> bundle in /etc/ssl/certs/ca-certificates.crt.

> This issue relates to #926388 (let Firefox trust
> /etc/ssl/certs/ca-certificates.crt)

...let's me think, that this bug is only fixable for Debian Edu 10 and 
higher anyway.

Please correct me if I'm wrong.

Wolfgang


signature.asc
Description: PGP signature

Bug#947520: filemanager-actions: build-depends on deprecated gnome-doc-utils

[Boyuan Yang]

X-Debbugs-CC: e7ap...@gmail.com

Hi Carlos,

On Fri, 27 Dec 2019 22:19:10 + Simon McVittie  wrote:
> Source: filemanager-actions
> Version: 3.4-2
> Severity: important
> Control: block 936625 by -1
> Control: block 889019 by -1
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs gnome-doc-utils
> 
> This package Build-Depends on gnome-doc-utils. gnome-doc-utils is a
> deprecated package of documentation utilities. Its most recent upstream
> release was in 2012, with most changes in its git repository since then
> being translation updates. The GNOME team do not consider gnome-doc-utils
> to be suitable for release in Debian 11 'bullseye'.
> 
> The supported replacement is yelp.m4 in yelp-tools, as used
> in many GNOME 3 packages. A porting guide is available:

I saw that upstream seems to have migrated from gnome-doc-utils to yelp. Could
you please take a look into it?

Besides, the another RC bug currently lying in your package also really needs
a fix. Please let me know if I can help in some ways.

-- 
Thanks,
Boyuan Yang


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

Bug#951284: O: zvbi -- Vertical Blanking Interval (VBI) utilities

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the zvbi package.

The package description is:
 Television broadcasts use the VBI to transmit text such as closed captioning
 (NTSC), Teletext (PAL/SECAM), and now Intercast and the ATVEC Internet
 television encodings.  The zvbi library is used to capture and decode raw
 VBI data.
 .
 This package contains the following utilities:
  * zvbid, a proxy for VBI devices. It forwards VBI data streams to one or
more connected clients and manages channel change requests.
  * zvbi-atsc-cc, a command-line utility that captures  ATSC TV transmissions
using a Linux DVB device and decodes the enclosed Closed Caption data.
It can record both NTSC caption (EIA 608-B) and DTVCC caption (CEA 708-C).
  * zvbi-chains, a wrapper which executes the VBI application given on the
command line while overloading several C library calls so that the
application can be forced to access VBI devices via the VBI proxy instead
of device files directly.
  * zvbi-ntsc-cc, a command-line utility for decoding and capturing closed
captioning (CC) for NTSC and webtv.

Bug#947540: stardict: build-depends on deprecated gnome-doc-utils

[Boyuan Yang]

Control: forwarded -1 https://github.com/huzheng001/stardict-3/issues/86

On Fri, 27 Dec 2019 22:39:42 + Simon McVittie  wrote:
> Source: stardict
> Version: 3.0.6+dfsg-0.1
> Severity: important
> Control: block 936625 by -1
> Control: block 889019 by -1
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs gnome-doc-utils
> 
> This package Build-Depends on gnome-doc-utils. gnome-doc-utils is a
> deprecated package of documentation utilities.

I have forwarded the issue. However, the chance of getting fixed is still
unknown and we might have to have the package removed if no improvement is
seen.

-- 
Thanks,
Boyuan Yang


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

Bug#951283: RFS: ledmon/0.94-1 -- Enclosure LED Utilities

[Hsieh-Tseng Shen]

Package: sponsorship-requests
Severity: normal
Tags: upstream

Dear mentors,

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

 * Package name: ledmon
   Version : 0.94-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/intel/ledmon
 * License : GPL-2.0+
 * Vcs : https://salsa.debian.org/debian/ledmon
   Section : admin

It builds those binary packages:

  ledmon - Enclosure LED Utilities

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/l/ledmon/ledmon_0.94-1.dsc

Changes since the last upload:

   * New upstream release 0.94.
 - Support for AMD IPMI enclosure management.
 - Support for NPEM.
   * debian/control: add systemd, pkg-config and libpci-dev as build dependency.
   * debian/control: update Standards-Version to 4.5.0.
   * Add debian/ledmon.init.
   * debian/rules: fix typo and remove manual systemd installation.
   * Remove obsolete patch.

More details:
As previous bug I filed was close due to packaging issues need to be
fixed, the new sponsor request with fixes is proposed again. Basically,
most problems are fixed by debian/control and a new init script. Others
make package clean as much as possible. Clean build is also tested by
pbuilder.

Regards,

-- 
Woodrow Shen (Hsieh-Tseng Shen)
4FA0 D159 803F F8B6 34E9  5A38 3970 FE24 7CB6 9685
woodrow.s...@gmail.com


signature.asc
Description: PGP signature

Bug#934004: ITP: golang-starlark -- Interpreter for the Starlark configuration language

[Boyuan Yang]

X-Debbugs-CC: ekri...@gmail.com

Hi Emanuel,

On Mon, 5 Aug 2019 23:49:33 +0200 Emanuel Krivoy  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Emanuel Krivoy 
> 
> * Package name: golang-starlark
>   Version : 0.0~git20190717.fc7a7f4-1
>   Upstream Author : The Bazel Authors
> * URL : https://github.com/google/starlark-go

How is this packaging effort going? We have some other projects that is also
waiting for this package thus the progress can be important to us.

Please let me know if you have any difficulties in the packaging. If you have
any parital work output, it would also be great if you could past a URL here.

-- 
Thanks,
Boyuan Yang


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

Bug#951282: RFS: dmagnetic/0.22-1 -- Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art

[dettus]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : dmagnetic
Version : 0.22-1
Upstream Author : Thomas Dettbarn det...@dettus.net
* URL : https://www.dettus.net/dMagnetic/
* License : BSD-2-Clause
* Vcs : None
Section : games

It builds those binary packages:

dmagnetic - Interpreter to play textadventures from Magnetic Scrolls in 
glorious ANSI Art


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.22-1.dsc


Changes since the last upload:

* Update to release 0.22.
* Binaries from the Magnetic Windows system can be used for playing.
* Sixel mode allows for high resolution images in certain xterms.

Regards,

Bug#951281: FTBFS: /usr/bin/ld: cannot find -lpthreads

[Hans Joachim Desserud]

Source: widelands
Version: 1:20-1
Severity: serious
Justification: ftbfs
Tags: ftbfs

Dear Maintainer,

Widelands currently fails to build in Sid with the following error 
message:

...
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_893c8.dir/link.txt 
--verbose=1
/usr/bin/cc -g -O2 -fdebug-prefix-map=/build/widelands-20=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 
-DCHECK_FUNCTION_EXISTS=pthread_create  -Wl,-z,relro  -rdynamic 
CMakeFiles/cmTC_893c8.dir/CheckFunctionExists.c.o  -o cmTC_893c8  
-lpthreads

/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/cmTC_893c8.dir/build.make:87: cmTC_893c8] Error 
1
make[3]: Leaving directory 
'/build/widelands-20/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'

make[2]: *** [Makefile:121: cmTC_893c8/fast] Error 2
make[2]: Leaving directory 
'/build/widelands-20/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'




dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DWL_INSTALL_BASEDIR=/usr/share/games/widelands 
-DWL_INSTALL_BINDIR=games 
-DWL_INSTALL_DATADIR=/usr/share/games/widelands/data 
-DWL_INSTALL_PREFIX=/usr -DOPTION_BUILD_WEBSITE_TOOLS=OFF 
-DCMAKE_BUILD_TYPE=Release .. returned exit code 1

make[1]: *** [debian/rules:14: override_dh_auto_configure] Error 25
make[1]: Leaving directory '/build/widelands-20'
make: *** [debian/rules:10: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2




I suspect the important part is "/usr/bin/ld: cannot find -lpthreads", 
which I suppose
might be due to some underlying library change though I haven't figured 
it out. Saw the
same error message when the package was rebuilt in Ubuntu, and I guess 
other

packages using -lpthreads might suffer the same fate.

Tried rebuilding the current upstream development version to see if it 
had a fix,

but ran into a separate issue.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#951280: ncbi-blast+: runtime trap with at least blastn and makeblastdb

[Patrice DUROUX]

Package: ncbi-blast+
Version: 2.8.1-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Running commands like one of the following:

blastn -query test.fasta -subject test.fasta

makeblastdb -dbtype nucl -in test.fasta

   * What was the outcome of this action?

A runtime trap with a message 'Instruction non permise'
(sorry for the french message, got the same in a LANG=C env)

Here are extracts from dmesg:

[16975777.040241] traps: blastn[16028] trap invalid opcode ip:7f5c96a4598c 
sp:7ffece18a380 error:0 in libblast.so[7f5c96a04000+66000]
[16976213.970602] traps: makeblastdb[17484] trap invalid opcode ip:7fca6c0bfb02 
sp:7ffe3fae78a0 error:0 in libxutil.so[7fca6c08c000+83000]

and here is the output got using gdb and ncbi-blast+-dbgsym:

gdb --args blastn -query test.fasta -subject test.fasta
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from blastn...Reading symbols from 
/usr/lib/debug/.build-id/00/382f3290f9ed8c1cace9c6e03d714c031cbd3d.debug...done.
done.
(gdb) go
Command requires an argument.
(gdb) run
Starting program: /usr/bin/blastn -query test.fasta -subject test.fasta

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
BLASTN 2.8.1+



Program received signal SIGILL, Illegal instruction.
0x77afe98c in BLAST_ComputeLengthAdjustment (K=, 
logK=-0.77652878949899629, alpha_d_lambda=1.171875, beta=-2, 
query_length=query_length@entry=86, db_length=db_length@entry=86, 
db_num_seqs=db_num_seqs@entry=1, 
length_adjustment=length_adjustment@entry=0x7fffcf84)
at ./c++/src/algo/blast/core/blast_stat.c:5093
5093./c++/src/algo/blast/core/blast_stat.c: No such file or directory.
(gdb) 

The CPU info of the hardware used to run the commands is:

# lscpu
Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   40 bits physical, 48 bits virtual
CPU(s):  16
On-line CPU(s) list: 0-15
Thread(s) per core:  2
Core(s) per socket:  2
Socket(s):   4
NUMA node(s):1
Vendor ID:   GenuineIntel
CPU family:  15
Model:   6
Model name:  Intel(R) Xeon(TM) CPU 3.40GHz
Stepping:8
CPU MHz: 3391.598
BogoMIPS:6783.19
Virtualization:  VT-x
L1d cache:   16K
L2 cache:1024K
L3 cache:16384K
NUMA node0 CPU(s):   0-15
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc pebs bts nopl cpuid pni dtes64 monitor ds_cpl vmx est tm2 cid cx16 
xtpr pdcm lahf_lm pti tpr_shadow vnmi


I hope that is enough information to be helpful.

Thanks,
Patrice


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

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

Versions of packages ncbi-blast+ depends on:
ii  libbz2-1.0  1.0.6-9.2~deb10u1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgomp18.3.0-6
ii  liblmdb00.9.22-1
ii  libmbedcrypto3  2.16.0-1
ii  libmbedtls122.16.0-1
ii  libpcre32:8.39-12
ii  libstdc++6  8.3.0-6
ii  ncbi-data   6.1.20170106+dfsg1-0+deb10u2
ii  perl5.28.1-6
ii  python  2.7.16-1
ii  zlib1g  1:1.2.11.dfsg-1

ncbi-blast+ recommends no packages.

ncbi-blast+ suggests no packages.

-- no debconf information

Bug#950931: [bts-link] source package src:q2templates

[Andreas Tille]

Hi Liubov,

seems

  https://github.com/qiime2/q2templates/pull/42

fixes the issue and its included in version 2020.2.0.dev0.  I'm not
really sure whether to cherry-pick the pull request or simply package
2020.2.0.dev0.  Would you like to have a look?

Kind regards

Andreas.

On Thu, Feb 13, 2020 at 05:18:45PM +, debian-bts-l...@lists.debian.org 
wrote:
> #
> # bts-link upstream status pull for source package src:q2templates
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> 
> user debian-bts-l...@lists.debian.org
> 
> # remote status report for #950931 (http://bugs.debian.org/950931)
> # Bug title: q2templates: FTBFS with pandas 1.0: test failures
> #  * https://github.com/qiime2/q2templates/issues/41
> #  * remote status changed: (?) -> closed
> #  * closed upstream
> tags 950931 + fixed-upstream
> usertags 950931 + status-closed
> 
> thanks
> 

-- 
http://fam-tille.de

Bug#951279: firefox-esr: Already running Firefox broken after background apt upgrade

[Witold Baryluk]

Package: firefox-esr
Version: 68.4.2esr-1
Severity: normal

Dear Maintainer,

I had Firefox ESR 60.8.0esr installed and running, with few tabs.

Then I initiated the apt dist-upgrade which did upgrade firefox to 68.4.2esr-1.

Already running Firefox stopped working correctly. I can't open new tabs
or duplicate tabs, opening some websites is problematic. Eventually it
got into really bad state, and I can't even switch tabs now.

I see plenty of errors in the terminal from running Firefox, like:

###!!! [Parent][MessageChannel] Error: 
(msgtype=0x2D0008,name=PContent::Msg_InitProcessHangMonitor) Channel error: 
cannot send/recv

[Parent 4516, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed 
descriptors: file 
/build/firefox-esr-5uDrOt/firefox-esr-60.8.0esr/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc,
 line 19

###!!! [Parent][MessageChannel] Error: 
(msgtype=0x2D000A,name=PContent::Msg_InitProfiler) Channel error: cannot 
send/recv

[Parent 4516, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed 
descriptors: file 
/build/firefox-esr-5uDrOt/firefox-esr-60.8.0esr/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc,
 line 19
[Parent 4516, Gecko_IOThread] WARNING: pipe error (118): Connection reset by 
peer: file 
/build/firefox-esr-5uDrOt/firefox-esr-60.8.0esr/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 342

###!!! [Parent][MessageChannel] Error: 
(msgtype=0x2D0055,name=PContent::Msg_SetPermissionsWithKey) Channel error: 
cannot send/recv


###!!! [Parent][MessageChannel] Error: 
(msgtype=0x2D004E,name=PContent::Msg_GMPsChanged) Channel error: cannot 
send/recv


###!!! [Parent][MessageChannel] Error: 
(msgtype=0x2D0001,name=PContent::Msg_PBrowserConstructor) Channel error: cannot 
send/recv


Would be nice for the upgrade process to be more atomic maybe. I am not
sure it is fully solvable tho, i.e. if new tabs are started from scratch
using fork+execve, and they need to read old binaries and libraries again
from the file system, but they are either changed or gone.

Still, not nice from the user perspective.

Maybe some kind of warning in the Firefox UI would be good to have to
indicate that no new tabs can be opened, and the Firefox need to be
restarted immedietly due to upgrade of the binaries.

Regards,
Witold




-- Package-specific info:


-- Addons package information

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.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 firefox-esr depends on:
ii  debianutils   4.9.1
it  fontconfig2.13.1-2+b1
ii  libasound21.2.1.2-2
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-10
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-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-3
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc1   1:9.2.1-25
it  libgdk-pixbuf2.0-02.40.0+dfsg-2
ii  libglib2.0-0  2.62.4-1+b1
ii  libgtk-3-03.24.13-1
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.24-1
ii  libnss3   2:3.49.1-1
ii  libpango-1.0-01.42.4-7
ii  libsqlite3-0  3.31.1-1
ii  libstartup-notification0  0.12-6
ii  libstdc++69.2.1-25
ii  libx11-6  2:1.6.8-1
ii  libx11-xcb1   2:1.6.8-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2+b1
ii  zlib1g1:1.2.11.dfsg-1.2

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

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-6
it  libgtk2.0-02.24.32-4
iu  pulseaudio 13.0-4

-- no debconf information

Bug#951278: ITP: cargo-lock -- Self-contained Cargo.lock parser

[Fabian Grünbichler]

Package: wnpp
Severity: wishlist
Owner: Fabian Grünbichler 

* Package name: cargo-lock
  Version : 4.0.1
  Upstream Author : Tony Arcieri 
* URL : https://github.com/rustsec/cargo-lock
* License : Apache-2.0 or MIT
  Programming Lang: Rust
  Description : Self-contained Cargo.lock parser

Needed as dependency of cargo-deny, but also useful as a stand-alone
tool to parse, print and translate Cargo.lock file contents.

Will be maintained via debcargo-conf / by the Debian Rust team.

Bug#951275: gap: Install libgap following library conventions

[Tobias Hansen]

On 2/13/20 5:49 PM, Bill Allombert wrote:
> On Thu, Feb 13, 2020 at 05:28:10PM +0100, Tobias Hansen wrote:
>> Source: gap
>> Version: 4r10p2-2
>> Severity: normal
>>
>> Hi Bill,
>>
>> please keep in mind to create a library package for libgap and install it to 
>> /usr/lib/triplet.
>>
>> We still need to keep extra hacks in sagemath to find libgap and
>> library transitions for libgap can also not be handled properly
>> without a library package.
> Hello Tobias,
>
> Thanks for the reminder!
> However, for that I need the GAP team to provide a stable ABI across point
> release. This is not the case with GAP 4.10.
That's ok, I just wanted to create the bug as a reminder.
> Also once it is done, I will not be able to apply any patches that
> change the library ABI.

That's fine with me, all the sagemath related patches are merged upstream as 
far as I know.

Best,

Tobias

Bug#951275: gap: Install libgap following library conventions

[Bill Allombert]

On Thu, Feb 13, 2020 at 05:28:10PM +0100, Tobias Hansen wrote:
> Source: gap
> Version: 4r10p2-2
> Severity: normal
> 
> Hi Bill,
> 
> please keep in mind to create a library package for libgap and install it to 
> /usr/lib/triplet.
> 
> We still need to keep extra hacks in sagemath to find libgap and
> library transitions for libgap can also not be handled properly
> without a library package.

Hello Tobias,

Thanks for the reminder!
However, for that I need the GAP team to provide a stable ABI across point
release. This is not the case with GAP 4.10.

Also once it is done, I will not be able to apply any patches that
change the library ABI.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#951277: O: libofa -- library for acoustic fingerprinting

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the libofa package.

The package description is:
 LibOFA (Library Open Fingerprint Architecture) is a library for
 generating acoustic fingerprints that can be used to identify music
 files using the MusicDNS service.

Bug#951251: RFS: ledmon/0.94-1 -- Enclosure LED Utilities

[Woodrow Shen]

Hi Adam,

Thanks for the help! Very appreciated.

On Thu, Feb 13, 2020 at 9:17 PM Adam Borowski  wrote:

> On Thu, Feb 13, 2020 at 09:01:38AM +, Hsieh-Tseng Shen wrote:
> >  * Package name: ledmon
> >Version : 0.94-1
>
> > Changes since the last upload:
> >
> >* New upstream release 0.94.
> >  - Support for AMD IPMI enclosure management.
> >  - Support for NPEM.
> >* debian/control: add pkg-config and libpci-dev as build dependency.
> >* debian/control: update Standards-Version to 4.5.0.
> >* Remove obsolete patch.
>
> Hi!
> Besides things mentioned above, you also add installation of systemd
> .service file.  And, I see some problems there.
>
> +   dh $@ --wth systemd
> would look a bit nicer when spelt "--with".


I didn't think I made ridiculous mistake here... oops


> It would also make this section done automatically:
> +override_dh_auto_install:
> +   dh_auto_install
> +   mkdir -p debian/ledmon/lib/systemd/system
> +   install -c -m 644 systemd/ledmon.service
> debian/ledmon/lib/systemd/system
> +   dh_systemd_enable || true
> +   dh_systemd_start || true
>
>
> Another problem is that you enable the daemon only for systemd.  For any
> other init/rc combination there's a need for an init script (and, it would
> be enough for systemd too).  Here's one:
>
> .--==[ debian/ledmon.init ]
> #!/usr/bin/env /lib/init/init-d-script
> ### BEGIN INIT INFO
> # Provides: ledmon
> # Required-Start:   $syslog $time
> # Required-Stop:$syslog $time
> # Default-Start:2 3 4 5
> # Default-Stop: 0 1 6
> # Short-Description: enclosure LED monitor
> # Description: monitoring of storage enclosure LEDs
> ### END INIT INFO
> DAEMON=/usr/sbin/ledmon
> `
>
I will refer some examples (e.g. network-manager) to finish init script,
thanks.
I don't why this bug needs to close, but anyway I will file a new bug after
I fix all issues you mentioned.

Woodrow

>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ A white dwarf seeks a red giant for a binary relationship.
> ⠈⠳⣄
>

Bug#951275: gap: Install libgap following library conventions

[Tobias Hansen]

Source: gap
Version: 4r10p2-2
Severity: normal

Hi Bill,

please keep in mind to create a library package for libgap and install it to 
/usr/lib/triplet.

We still need to keep extra hacks in sagemath to find libgap and library 
transitions for libgap can also not be handled properly without a library 
package.

Best,
Tobias

On 12/16/18 10:24 PM, Bill Allombert wrote:
> On Sun, Dec 16, 2018 at 08:25:17PM +0100, Tobias Hansen wrote:
>> +  * Install libgap to /usr/lib/triplet.
> 
> Do you need this now ? When the interface to libgap has stabilized, then
> probably we will split libgap from gap-dev and move it to
> /usr/lib/triplet, but as long as it is an experimental feature it is
> best to keep it in a subdirectory.
> 

Bug#951268: wpasupplicant: NetworkManager reports unknown keys in configuration drop-in `no-mac-addr-change.conf`

[Paul Menzel]

[Adding pkg-utopia-maintain...@lists.alioth.debian.org]

Dear Debian folks,


NetworkManager includes a configuration example upstream [1].

```
# Certain drivers are known not to support changing the MAC address.
# Disable touching the MAC address on such devices.
#
# See man NetworkManager.conf
#
# https://bugzilla.gnome.org/show_bug.cgi?id=777523
[device-31-mac-addr-change]
match-device=driver:eagle_sdio,driver:wl
wifi.scan-rand-mac-address=no

[connection-31-mac-addr-change]
# These are defaults for the connection profile. Here we set only the default
# value. Note that the default value already should be "preserve", so this has
# no actual effect.
#
# Also note that this is only the default. Per-profile settings still take
# precedence.
match-device=driver:eagle_sdio,driver:wl
wifi.cloned-mac-address=preserve
```

This could be used as drop-in example.

The NetworkManager upstream developer Thomas Haller suggests, to
ship the configuration in the NetworkManager package though.

Also, he has no knowledge that the Realtek drivers need to be
fixed up.


Kind regards,

Paul


[1]: 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/nm-conf.d/31-mac-addr-change.conf



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#951273: RFP: etesync-server -- A basic EteSync service (so you can run your own)

[David Seaward]

Package: wnpp
Severity: wishlist

* Package name: etesync-server
  Version : 0.3.0
  Upstream Author : EteSync 
* URL : https://github.com/etesync/server
* License : AGPL-3.0-or-later
  Programming Lang: Python
  Description : A basic EteSync service (so you can run your own)

This is a complete Django site suitable for running your own
EteSync server and hosting end-to-end encrypted calendars and contacts
for multiple users.

Bug#951272: rt 4.4 and later spam owner on permission denied

[Antoine Beaupre]

Source: request-tracker4
Version: 4.4.1-3+deb9u3
Severity: normal
Tags: patch upstream

RT 4.4 and later (shipped in buster) change the behavior of the mail
gateway to noisily warn the owner when it fails to create a ticket or
add a corrspondance because of a permission denied error.

This change was introduced in 4.4.0rc1, in the following commit:

https://github.com/bestpractical/rt/commit/03d0af9a7dfe03ce0f2f86f831bcfe19bb29f5a9#diff-a49d7759c3d37e2923b56ea76a2c62ab

That functionality which the commit log refers to used to be an
*optional* plugin, which was removed in:

https://github.com/bestpractical/rt/commit/d6b673a6e606de4ff74e30a3823401940e2cd465

I think that's a mistake. Since the update, we have started seeing a
lot of spam needlessly bounced to the owner email. The reason behind
this is that our RT admins are allowed to block email addresses from
using RT by ticking off the `Let this user access RT` box in the
user's configuration.

Previously, this would make the user see a bounce when they try to
write RT, which is still the case now. But on top of that, the message
is *also* bounced to admins.

That triggered a copious 23 emails just last night, and I suspect much
more is coming to us.

So I sent a PR upstream to revert the change:

https://github.com/bestpractical/rt/pull/291

Could this be integrated in the Debian package?

Thanks!

-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: amd64 (x86_64)

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

Bug#951151: polymake: test failure on mips64el

[Benjamin Lorenz]

On 13/02/2020 13.18, David Bremner wrote:
> Benjamin Lorenz  writes:
> 
>>
>>> It looks like it's flint related?
>>
>> Yes, I think this is a bug in flint and for now I suggest disabling the
>> flint-interface of polymake with the configure option --without-flint on
>> mips64el. This has basically no functionality loss as polymake will use
>> its own generic polynomial arithmetic instead (it will be somewhat slower).
>> Currently rebuilding polymake to check the testsuite again but this will
>> take some time and I will report back tomorrow.
>>
> 
> The easy thing would be to disable it everywhere. It is also possible to
> do it on an architecture specific basis. Do you think the (small) added
> complexity of the latter is worth it?

It seems we might need some extra stuff for mips64el anyway as I see
some weird segfaults even without flint (at different testcases).

But I am still investigating those, backtrace seems to point to the
exception handling code of libgcc / libstdc++:
Program received signal SIGSEGV, Segmentation fault.
parse_lsda_header (context=0x4000b9d880, p=0x260ae60 ,
info=0x4000b9cb50) at
../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:58
58  ../../../../src/libstdc++-v3/libsupc++/eh_personality.cc: No
such file or directory.
(gdb) bt
#0  parse_lsda_header (context=0x4000b9d880,
p=0x260ae60 ,
info=0x4000b9cb50)
at ../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:58
#1  0x00400161005c in __cxxabiv1::__gxx_personality_v0
(version=,
actions=, exception_class=,
ue_header=0x400cfa8d50,
context=0x4000b9d880) at
../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:454
#2  0x0040017e33ac in _Unwind_RaiseException (exc=0x400cfa8d50) at
../../../src/libgcc/unwind.inc:118
#3  0x00400161126c in __cxxabiv1::__cxa_throw (obj=0x400cfa8d70,
tinfo=0x4005e7ccf8 , dest=)
at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:90
#4  0x0040056fdfb8 in pm::lin_solve (A=..., b=...)
at /usr/include/c++/9/ext/new_allocator.h:89
#5  0x00400c7a8408 in
polymake::fan::remove_redundancies (f=...)
at ./include/core/polymake/internal/shared_object.h:1097
...

Bug#951270: ITP: dmarcts-report-parser -- Perl based tool to parse DMARC reports

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: dmarcts-report-parser
  Version : 1.0+git20190809.1.bb5dd8b6
  Upstream Author : Techsneeze.com
* URL : https://github.com/techsneeze/dmarcts-report-parser/
* License : GPL-3+
  Programming Lang: Perl
  Description : Perl based tool to parse DMARC reports

 This DMARC reports parser is based on John Levine's rddmarc, extended by
 the following features:
 .
* Allows one to read messages from an IMAP server and not only from the
  local filesystem.
* Store much more XML values into the database (for example the missing SPF
  and DKIM results from the policy_evaluated section) and also the entire
  XML for later reference.
* Needed database tables and columns are created automatically, user only
  needs to provide a database. The database schema is compatible to the one
  used by rddmarc, but extends it by additional fields. Users can switch
  from rddmarc to dmarcts-report-parser without having to do any changes
  to the database by themselves.

Bug#949622: patch for 1.3.5

[Hilmar Preuße]

Am 13.02.2020 um 15:54 teilte Ghislain Adnet mit:

Hi Ghislain,

>  Tj was kind enough to make a patch for the 1.3.5 unsupported branch !
> =
> 
> This is for:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949622
> 
> See attached patch, generated against the 1.3.5 branch of ProFTPD in
> GitHub.
> 
Here are prebuilt packages. Please test them.

https://freeshell.de/~hille42/proftpd/949622/

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#951139: Can someone please have a look (Was: Bug#951139: toil fails it's autopkg tests)

[Andreas Tille]

Hi,

in case you might have missed this.  Seems to be serious to me.

Kind regards

  Andreas.

On Tue, Feb 11, 2020 at 05:10:10PM +0100, Matthias Klose wrote:
> Package: src:toil
> Version: 3.23.1-1
> Severity: serious
> Tags: sid bullseye
> 
> seen in https://ci.debian.net/packages/t/toil
> toil fails it's autopkg tests
> 
> [...]
> autopkgtest [19:11:47]: test smoke-test: [---
> Traceback (most recent call last):
>   File "/usr/bin/toil", line 11, in 
> load_entry_point('toil==3.18.0', 'console_scripts', 'toil')()
>   File "/usr/lib/python3/dist-packages/toil/utils/toilMain.py", line 13, in 
> main
> modules = loadModules()
>   File "/usr/lib/python3/dist-packages/toil/utils/toilMain.py", line 39, in
> loadModules
> from toil.utils import (toilKill,
>   File "/usr/lib/python3/dist-packages/toil/utils/toilStatus.py", line 34, in
> 
> from toil.jobStores.abstractJobStore import NoSuchJobStoreException,
> NoSuchFileException
>   File "/usr/lib/python3/dist-packages/toil/jobStores/abstractJobStore.py", 
> line
> 39, in 
> from toil.job import JobException
>   File "/usr/lib/python3/dist-packages/toil/job.py", line 51, in 
> from toil.deferred import DeferredFunction
>   File "/usr/lib/python3/dist-packages/toil/deferred.py", line 34, in 
> from toil.resource import ModuleDescriptor
>   File "/usr/lib/python3/dist-packages/toil/resource.py", line 43, in 
> from toil.version import exactPython
> ImportError: cannot import name 'exactPython' from 'toil.version'
> (/usr/lib/python3/dist-packages/toil/version.py)
> autopkgtest [19:11:48]: test smoke-test: ---]
> autopkgtest [19:11:48]: test smoke-test:  - - - - - - - - - - results - - - - 
> -
> - - - - -
> smoke-test   FAIL non-zero exit status 1
> autopkgtest [19:11:48]: test smoke-test:  - - - - - - - - - - stderr - - - - 
> - -
> - - - -
> Traceback (most recent call last):
>   File "/usr/bin/toil", line 11, in 
> load_entry_point('toil==3.18.0', 'console_scripts', 'toil')()
>   File "/usr/lib/python3/dist-packages/toil/utils/toilMain.py", line 13, in 
> main
> modules = loadModules()
>   File "/usr/lib/python3/dist-packages/toil/utils/toilMain.py", line 39, in
> loadModules
> from toil.utils import (toilKill,
>   File "/usr/lib/python3/dist-packages/toil/utils/toilStatus.py", line 34, in
> 
> from toil.jobStores.abstractJobStore import NoSuchJobStoreException,
> NoSuchFileException
>   File "/usr/lib/python3/dist-packages/toil/jobStores/abstractJobStore.py", 
> line
> 39, in 
> from toil.job import JobException
>   File "/usr/lib/python3/dist-packages/toil/job.py", line 51, in 
> from toil.deferred import DeferredFunction
>   File "/usr/lib/python3/dist-packages/toil/deferred.py", line 34, in 
> from toil.resource import ModuleDescriptor
>   File "/usr/lib/python3/dist-packages/toil/resource.py", line 43, in 
> from toil.version import exactPython
> ImportError: cannot import name 'exactPython' from 'toil.version'
> (/usr/lib/python3/dist-packages/toil/version.py)
> autopkgtest [19:11:48]:  summary
> smoke-test   FAIL non-zero exit status 1
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#951271: java-gnome: Please migration from enchant(1) to enchant-2

[Boyuan Yang]

Source: java-gnome
Version: 4.1.3-8
Severity: important
X-Debbugs-CC: onkarshi...@ubuntu.com respawne...@gmail.com m...@codepencil.com
Control: block 947979 by -1

Dear Debian Java maintainers,

As libenchant upstream has bumped its version and released enchant 2.x, the
old enchant 1.x is no longer maintained. Please consider switching from using
the old package "enchant" to the new "enchant-2".

If you need a patch, I believe the one currently in Arch Linux AUR can be used
as a reference: https://aur.archlinux.org/packages/java-gnome/

-- 
Thanks,
Boyuan Yang


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

Bug#951216: poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

[Chris Lamb]

user reproducible-bui...@lists.alioth.debian.org
usertag 951216 + toolchain timestamps
thanks

> poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

It's unclear to me whether this is a bug in Poppler or reprotest. When
I try and reproduce this outside of reprotest, for example with something
like:

  $ TZ="/usr/share/zoneinfo/Etc/GMT-14" pdfinfo foo.pdf

… and:

  $ TZ="/usr/share/zoneinfo/Etc/GMT+12" pdfinfo foo.pdf

… I get the expected results. Saying that, poppler has the following
"smoking gun"-like comment:

// TODO do something with the timezone info

… but that curiously is then followed by code that appears to do
something with the timezone info:

s = obj.getString()->c_str();
// TODO do something with the timezone info
if ( parseDateString( s, , , , , , , , 
_hour, _minute ) ) {
  tmStruct.tm_year = year - 1900;
  tmStruct.tm_mon = mon - 1;
  tmStruct.tm_mday = day;
  tmStruct.tm_hour = hour;
  tmStruct.tm_min = min;
  tmStruct.tm_sec = sec;
  tmStruct.tm_wday = -1;
  tmStruct.tm_yday = -1;
  tmStruct.tm_isdst = -1;
  // compute the tm_wday and tm_yday fields
  time = timegm();
  if (time != (time_t)-1) {
int offset = (tz_hour*60 + tz_minute)*60;
if (tz == '-')
  offset *= -1;
time -= offset;
localtime_r(, );
strftime(buf, sizeof(buf), "%c %Z", );
fputs(buf, stdout);

But I might be missing something.

Can I suggest two things at this point? First, could you attach your
generated test.pdf to this bug so that we are completely on the same
page and using the exactly the same file? Secondly, perhaps you could
systematically alter the settings of reprotest in order to identify
which is the variation employed that is causing this to happen?


Regards,

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

Bug#937405: pychess: Python2 removal in sid/bullseye

[Boyuan Yang]

X-Debbugs-CC: va...@debian.org

On Fri, 30 Aug 2019 11:04:24 +0200 =?UTF-8?Q?Tam=C3=A1s_Bajusz?= <
gbt...@gmail.com> wrote:
> PyChess was ported to Python3 years ago.
> Unfortunately the official .deb maintainer doesn't seem to follow new
> releases :(
> https://github.com/pychess/pychess/releases
> 
> Regards
> Bajusz Tamás

Hi Varun,

Are you updating pychess onto the python3 version anytime soon? Due to the
ongoing progress of py2removal, I believe the package in Debian really need to
be updated recently.

Please let me know if you have any schedule in making a update or need any
help in doing this. Thanks!

-- 
Best,
Boyuan Yang


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

Bug#951269: nextcloud-desktop don't work as expected since Debian 10.0.0

[Giancarlo Giesa]

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

Is really really rally slow on second boot (like 1 file / minute).
the bug was well know on Nextcloud-Bug-reporting-system and i found it
since Debian 10.0.0 was relased, apparently there is a internal crash:
[nextcloud/desktop] linux client crashes for no discernable reason (#1382)
link: https://github.com/nextcloud/desktop/issues/1382

i can see that the bug was not fixed in the last update of Debian 10 and
a workaround is to use owncloud-client package that is fast as expected
(100 file in some second), but is will show a warning message on boot
(something like... this is ownlcloud... use it with nextcloud at your risk)

i can test the package, also in a private way, with big load if it will
be necessary

i'm using Debian 10.3.0 with default GNU/Linux kernel - 64bit

sincerely Giancarlo Giesa



0x7FCBEDB96A9AAA40.asc
Description: application/pgp-keys

Bug#951268: wpasupplicant: NetworkManager reports unknown keys in configuration drop-in `no-mac-addr-change.conf`

[Paul Menzel]

Package: wpasupplicant
Version: 2:2.9-6

Dear Debian folks,


In Debian Sid/unstable NetworkManager 1.22.6-1 reports the unknown
keys below.

> NetworkManager[779]:   [1581582878.2345] config: unknown key 
> 'wifi.cloned-mac-address' in section [device-mac-addr-change-wifi] of file 
> '/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'
> NetworkManager[779]:   [1581582878.2345] config: unknown key 
> 'ethernet.cloned-mac-address' in section [device-mac-addr-change-wifi] of 
> file '/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'

```
$ more /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf
# Certain drivers are known not to support changing the MAC address.
# Disable touching the MAC address on such devices.
#
# See man NetworkManager.conf
#
# https://bugzilla.gnome.org/show_bug.cgi?id=777523

[device-mac-addr-change-wifi]
match-device=driver:rtl8723bs,driver:rtl8189es,driver:r8188eu,driver:8188eu,driver:eagle_sdio,driver:wl
wifi.scan-rand-mac-address=no
wifi.cloned-mac-address=preserve
ethernet.cloned-mac-address=preserve
```

Could you please remove the last two lines in the file?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#951267: openssl: pkcs12 -export cannot read .p12 file

[Thorsten Glaser]

Package: openssl
Version: 1.1.1d-2
Severity: wishlist
Tags: upstream

It isn’t possible to use openssl pkcs12 in a single call to,
say, remove the password on a .p12 file, because -export
forcibly requires PEM input.

Instead one has to:

openssl pkcs12 -in foo.p12 -out tmp
• enter p12 transport password, then twice a dummy pw (not
  just Enter twice either, it doesn’t work!)

openssl pkcs12 -in tmp -export -out foo-without-pw.p12
• enter dummy password, then twice Enter

This could be streamlined.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages openssl depends on:
ii  libc6  2.29-10
ii  libssl1.1  1.1.1d-2

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-bundle [ca-certificates]  20190604tarent1

-- Configuration Files:
/etc/ssl/openssl.cnf changed:
HOME= .
RANDFILE= $ENV::HOME/.rnd
oid_section = new_oids
openssl_conf = default_conf
[ new_oids ]
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
[ ca ]
default_ca  = CA_default# The default ca section
[ CA_default ]
dir = ./demoCA  # Where everything is kept
certs   = $dir/certs# Where the issued certs are kept
crl_dir = $dir/crl  # Where the issued crl are kept
database= $dir/index.txt# database index file.
# several certs with same subject.
new_certs_dir   = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem   # The CA certificate
serial  = $dir/serial   # The current serial number
crlnumber   = $dir/crlnumber# the current crl number
# must be commented out to leave a V1 
CRL
crl = $dir/crl.pem  # The current CRL
private_key = $dir/private/cakey.pem# The private key
x509_extensions = usr_cert  # The extensions to add to the cert
name_opt= ca_default# Subject Name options
cert_opt= ca_default# Certificate field options
default_days= 365   # how long to certify for
default_crl_days= 30# how long before next CRL
default_md  = default   # use public key default MD
preserve= no# keep passed DN ordering
policy  = policy_match
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName= match
organizationalUnitName  = optional
commonName  = supplied
emailAddress= optional
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName= optional
organizationName= optional
organizationalUnitName  = optional
commonName  = supplied
emailAddress= optional
[ req ]
default_bits= 2048
default_keyfile = privkey.pem
distinguished_name  = req_distinguished_name
attributes  = req_attributes
x509_extensions = v3_ca # The extensions to add to the self signed cert
string_mask = utf8only
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Some-State
localityName= Locality Name (eg, city)
0.organizationName  = Organization Name (eg, company)
0.organizationName_default  = Internet Widgits Pty Ltd
organizationalUnitName  = Organizational Unit Name (eg, section)
commonName  = Common Name (e.g. server FQDN or YOUR name)
commonName_max  = 64
emailAddress= Email Address
emailAddress_max= 64
[ req_attributes ]
challengePassword   = A challenge password
challengePassword_min   = 4
challengePassword_max   = 20
unstructuredName= An optional company name
[ usr_cert ]
basicConstraints=CA:FALSE
nsComment   = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = critical,CA:true
[ crl_ext ]
authorityKeyIdentifier=keyid:always
[ proxy_cert_ext ]

Bug#951111: libreoffice: it is impossible to saveas in a directory unless it is a leaf directory

[fulvio ciriaco]

Dear Rene,
just some more info:
1. it is not tied to icewm, the same happens with openbox
2. it has nothing to do with libreoffice configuration, libreoffice behaves the 
same after 
   removing .config/libreoffice
3. it has nothing to do with the graphic card, I have different graphic cards 
at home and
   at work and the same ill behaviour at both places.
I know each of these was rather improbable, but I wanted to rule them out.
If you have suggestions for further tests, please provide them.
Thank you,
best wishes
Fulvio  

On 2/12/20 6:43 PM, Rene Engelhard wrote:
> Hi,
> 
> On Wed, Feb 12, 2020 at 09:35:20AM +0100, fulvio ciriaco wrote:
>> I understood from the text shown by reportbug about libreoffice that 
>> comparing to the
>> native version was required or preferred, maybe I was not able to understand 
>> it, or maybe
>> it is written wrong or maybe more hints are needed.
> 
> Yeah, sorry, there have been "you broke it compared to upstream" bugs
> lately and telling it was a Debian bug whiereas it definitely was a
> upstream one...
> 
>>> What desktop are you on? Which UI setting? (See Tools->About, maybe, if
>>> you have no clue). Did you force gtk2 somehow and this is an other
>>> incarnation of #951060.
>>>
>>
>> I am on icewm from debian testing. There is no tools->about, but help->about 
>> recites:
> 
> Yeah, that was meant.
> 
>> CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: x11;
> 
> So LibreOffices open/save dialog..
> 
> Anyways: unreproducible
> 
> lowriter
> random writer document: here just entering "a".
> Save as
> [I am on /home/rene, which has gazillions of subdirs]
> enter abc.odt
> LO saves as abc.odt *in /home/rene*, which is what is expected.
> 
> Regards,
> 
> Rene
> 

Bug#951266: RM: python-feedvalidator -- RoQA; Dead Upstream; Affected by Python2 Removal

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: python-modules-t...@lists.alioth.debian.org nsla...@tumbolia.org

Dear FTP Masters,

Package python-feedvalidator has a dead upstream (googlecode), inactive
package maintainer and is python2-only. It has no reverse-dependencies or
build-rdeps. As a result, I believe it is reasonable to have it removed from
Debian archive.

For background information, please see https://bugs.debian.org/937750 .

-- 
Thanks,
Boyuan Yang


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

Bug#938608: RM svn-workbench

[Scott Talbert]

reassign -1 ftp.debian.org
retitle -1 RM: svn-workbench -- RoQA; dead upstream; low popcon; blocking py2 
removal

Bug#937750: python-feedvalidator: Python2 removal in sid/bullseye

[Boyuan Yang]

X-Debbugs-CC: nsla...@tumbolia.org python-modules-t...@lists.alioth.debian.org

On Fri, 30 Aug 2019 07:39:15 + Matthias Klose  wrote:
> Package: src:python-feedvalidator
> Version: 0~svn1022-3
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

Hi Noah and fellow DPMT members,

I found python-feedvalidator has a dead upstream, no maintainer activity in
recent years, no reverse-dependencies and no build-reverse-dependencies. As a
result, we should be removing it as part of the py2removal effort.

I will be filing a removal bug soon. If there's any doubt, please let me know
asap.

-- 
Thanks,
Boyuan Yang


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

Bug#949622: patch for 1.3.5

[Ghislain Adnet]

Hi,

 Tj was kind enough to make a patch for the 1.3.5 unsupported branch !
=

This is for:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949622

See attached patch, generated against the 1.3.5 branch of ProFTPD in GitHub.

Hope this helps,
TJ


proftpd-1.3.5-sftp-kbdint-packets-bug4385.patch
Description: Binary data

Bug#951265: ruby-vips: autopkgtest fails on arm64: expected Vips::Error but nothing was raised

[Paul Gevers]

Source: ruby-vips
Version: 2.0.13-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainers,

Your new package ruby-vips has an autopkgtest, great. However, it fails
on arm64. I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? (Also, please do an
additional source-only upload as we don't allow maintainer build
binaries to migrate to testing, but the infrastructure doesn't allow
binNMUs of arch:all packages).

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-vips

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-vips/3481891/log.gz

RUBYLIB=. GEM_PATH= ruby2.5 -S rake -f debian/ruby-tests.rake
/usr/bin/ruby2.5 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb
--backtrace -r ./spec/spec_helper.rb
...F

Failures:

  1) Vips#call can throw errors for failed operations
 Failure/Error: expect{black.resize(0.4)}.to
raise_exception(Vips::Error)
   expected Vips::Error but nothing was raised
 # /usr/lib/ruby/vendor_ruby/rspec/support.rb:97:in `block in
'
 # /usr/lib/ruby/vendor_ruby/rspec/support.rb:106:in `notify_failure'
 # /usr/lib/ruby/vendor_ruby/rspec/expectations/fail_with.rb:35:in
`fail_with'
 # /usr/lib/ruby/vendor_ruby/rspec/expectations/handler.rb:40:in
`handle_failure'
 # /usr/lib/ruby/vendor_ruby/rspec/expectations/handler.rb:50:in
`block in handle_matcher'
 # /usr/lib/ruby/vendor_ruby/rspec/expectations/handler.rb:27:in
`with_matcher'
 # /usr/lib/ruby/vendor_ruby/rspec/expectations/handler.rb:48:in
`handle_matcher'
 #
/usr/lib/ruby/vendor_ruby/rspec/expectations/expectation_target.rb:65:in
`to'
 #
/usr/lib/ruby/vendor_ruby/rspec/expectations/expectation_target.rb:101:in
`to'
 # ./spec/vips_spec.rb:106:in `block (3 levels) in '
 # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:254:in
`instance_exec'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:254:in `block in run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:500:in `block in
with_around_and_singleton_context_hooks'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:457:in `block in
with_around_example_hooks'
 # /usr/lib/ruby/vendor_ruby/rspec/core/hooks.rb:464:in `block in run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/hooks.rb:602:in
`run_around_example_hooks_for'
 # /usr/lib/ruby/vendor_ruby/rspec/core/hooks.rb:464:in `run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:457:in
`with_around_example_hooks'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:500:in
`with_around_and_singleton_context_hooks'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:251:in `run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:629:in
`block in run_examples'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:625:in `map'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:625:in
`run_examples'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:591:in `run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:592:in
`block in run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:592:in `map'
 # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:592:in `run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:116:in `block (3
levels) in run_specs'
 # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:116:in `map'
 # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:116:in `block (2
levels) in run_specs'
 # /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1989:in
`with_suite_hooks'
 # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:111:in `block in
run_specs'
 # /usr/lib/ruby/vendor_ruby/rspec/core/reporter.rb:74:in `report'
 # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:110:in `run_specs'
 # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:87:in `run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:71:in `run'
 # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:45:in `invoke'
 # /usr/bin/rspec:4:in `'



signature.asc
Description: OpenPGP digital signature

Bug#950889: debootstrap: chroot no longer builds with user-owned target dir

[Roberto C . Sánchez]

On Thu, Feb 13, 2020 at 05:31:56PM +0900, Hideki Yamane wrote:
> Hi,
> 
> On Fri, 7 Feb 2020 15:33:08 -0500
> "Roberto C. Sanchez"  wrote:
> > It seems that with the latest change to the systemd journaling
> > configuration, that chroots no longer build with a user-owned target
> > directory.
> 
>  Well, then how about making chroot's / as root:root and 0755
>  as sane default?
> 
Well...I did just that.

Was there something wrong with my request that debootstrap check the
ownership and permissions of an existing target directory and provide a
suitable warning or error if the conditions are not sane?

Regards,

-Roberto
-- 
Roberto C. Sánchez

Bug#951264: firewalld: dhcpv6 does not work when using a dhcp-relay

[Andreas Dobloug]

Package: firewalld
Version: 0.6.3-5
Severity: normal

Dear Maintainer,

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

  firewalld blocks replies from a dhcpv6 server when using a dhcp-relay

  This is caused by the limitation in 
/usr/lib/firewalld/services/dhcpv6-client.xml

   The DHCP reply will contain the from-address of the DHCP server,
   which may not be on the local subnet when using a DHCP-relay.


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 firewalld depends on:
ii  dbus 1.12.16-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  init-system-helpers  1.56+nmu1
ii  iptables 1.8.2-4
ii  policykit-1  0.105-25
ii  python3  3.7.3-1
ii  python3-dbus 1.2.8-3
ii  python3-gi   3.30.4-1
ii  python3-slip-dbus0.6.5-2

Versions of packages firewalld recommends:
ii  ipset  6.38-1.2

firewalld suggests no packages.

-- Configuration Files:
/etc/firewalld/firewalld.conf [Errno 13] Permission denied: 
'/etc/firewalld/firewalld.conf'
/etc/firewalld/lockdown-whitelist.xml [Errno 13] Permission denied: 
'/etc/firewalld/lockdown-whitelist.xml'

-- no debconf information

Bug#939181: RM cycle

[Scott Talbert]

reassign -1 ftp.debian.org
retitle -1 RM: cycle -- RoQA; dead upstream; unmaintained; low popcon; blocking 
py2 removal

Bug#951263: please do not change "=" to "+" on command line (regression)

[Marvin Renich]

Package: neomutt
Version: 2019+dfsg.1-1
Severity: minor

When typing a folder on the command line, certain keys cause the folder
name to be canonicalized, and if the user is accustomed to using "=", it
now changes that to "+".  This is new behavior; it used to leave "="
alone.  I don't know if it used to change "+" to "=", but I am guessing
that it didn't.

This change is disconcerting at best, and is completely unnecessary.  On
a US keyboard, both characters are on the same key, but "=" is unshifted
and easier to type.  The "+" may be easier to type on other keyboards.
Please respect the user's choice of "=" or "+".

Please don't try to canonicalize the command line when it loses
information or is contrary to the user's expectation.

-- Package-specific info:
NeoMutt 2019
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-3-amd64 (x86_64)
ncurses: ncurses 6.1.20191019 (compiled with 6.1.20191019)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-19' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191109 (Debian 9.2.1-19) 

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-jdVSn8/neomutt-2019+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 testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages neomutt depends on:

Bug#906026: Switch to Ayatana Indicators

[Mike Gabriel]

Hi Andreas,

thanks for following up on this.

On  Do 13 Feb 2020 13:11:50 CET, Andreas Henriksson wrote:


Control: severity -1 serious

Hello XFCE Maintainers,

I'm bumping the severity of this bug report because the libindicators
package in RC buggy and likely not going to make it for bullseye,
plus the fact that this bug report has been open with patch for >1.5
years now! Apparently it needs some extra visibility or likely an NMU.

Regards,
Andreas Henriksson


As a short update on this, let me add... The Ayatana Indicators will  
be a heavy dependency of the upcoming-to-Debian Unity8 desktop  
environment.


The Unity8 packaging is funded, so I will be able to work on Ayatana  
Indicators in Debian in general in the context of the Unity8  
packaging, as well. This said, porting over from libindicator to  
libayatana-indicator is the only way to go here.


Furthermore, applications built against libappindicator should be  
ported to libayatana-appindicator. However, this is OT here, just a  
general info.


For more info, see here:
https://wiki.debian.org/Ayatana/IndicatorsTransition

(I haven't updated this page for a while, but it is certainly on my  
(long) list).


Mike
--

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

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



pgpgipF2D3s7f.pgp
Description: Digitale PGP-Signatur

Bug#951260: wireshark: "File/Open" dialog doesn't stay in directory

[Philipp Marek]

Package: wireshark
Version: 3.2.1-1
Severity: minor

The "File/Open" dialog only gives me the bookmarks "Computer",
my home directory, and /tmp/.
The current directory that I started wireshark from is missing.

Furthermore, after opening a file (either by pasting the full path
or by selecting in the list), another "File/Open" in the same
Wireshark instance restarts from /tmp, meaning I have to re-select
the whole path to the next file.


I'm able to drag a directory into the sidebar; then it sticks
around as a bookmark, even across restarts of Wireshark.

This way I saved "/proc/self/cwd" as a bookmark, which gives
the wanted behaviour; while a neat workaround I believe that
most users won't like that way ;)


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

Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wireshark depends on:
ii  wireshark-qt  3.2.1-1

wireshark recommends no packages.

wireshark suggests no packages.

-- no debconf information

--

Bug#951262: Please set CGO_XFLAGS with dpkg-buildflags

[Shengjing Zhu]

Package: dh-golang
Version: 1.45
Severity: wishlist

Hi,

Currently the CGO_XFLAGS is set with:

$ go env|grep CGO_
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

I think the values should be same as dpkg-buildflags

$ dpkg-buildflags
CFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong -Wformat 
-Werror=format-security
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong -Wformat 
-Werror=format-security
FCFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong
FFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong
GCJFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong
LDFLAGS=-Wl,-z,relro
OBJCFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong -Wformat 
-Werror=format-security
OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong -Wformat 
-Werror=format-security

I'm not familiar with Perl. I hope someone can help with the patch.

Shengjing Zhu

Bug#951261: indication that command is operating on tagged messages disappears (regression)

[Marvin Renich]

Package: neomutt
Version: 2019+dfsg.1-1
Severity: normal

If you only have one message tagged, and type ;s to save tagged
messages, the command line used to say "Save tagged to...", but now the
word "tagged" is no longer there.  This is truely bad, as the message
that is highlighted is usually not the tagged message, so the message
that looks like it will be saved is neither the message that was
intended nor the message that actually will be saved.

Even if the tagged message is the one that is highlighted, please still
use the "Save tagged..." message; it tells the user not only what will
happen, but confirms what the user actually typed.

Please don't try to "canonicalize" the command line when it loses
information or is contrary to the user expectation.

...Marvin

-- Package-specific info:
NeoMutt 2019
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-3-amd64 (x86_64)
ncurses: ncurses 6.1.20191019 (compiled with 6.1.20191019)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-19' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191109 (Debian 9.2.1-19) 

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-jdVSn8/neomutt-2019+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 testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#951259: wireshark: "File/Open" dialog display corruption in "Start/elapsed"

[Philipp Marek]

Package: wireshark
Version: 3.2.1-1
Severity: normal

The "Start/elapsed" field that is displayed upon "File/Open" is garbled,
please see the attached screenshot.


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

Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wireshark depends on:
ii  wireshark-qt  3.2.1-1

wireshark recommends no packages.

wireshark suggests no packages.

-- no debconf information

--

Bug#951228: octave-image: some listed dependencies are no longer required

[Rafael Laboissière]

Dear David,

Thank you for this bug report, but the version of octave-image currently 
in unstable (2.12.0-1) does not depend on octave-signal and imagemagick:


https://packages.debian.org/buster/octave-image

I am hereby closing this bug report.

However, the description of the package still contains a reference to 
ImageMagick.  I will remove it and upload version 2.12.0-2 soon.


Best,

Rafael Laboissière

* David Miguel Susano Pinto  [2020-02-12 20:17]:


Package: octave-image
Version: 2.12.0-1
Severity: normal

Dear Maintainer,

The current version of the Octave image package in Debian, version 
2.12.0-1, lists octave-signal and imagemagick as dependencies but 
that's no longer true.


Upstream dropped the dependency on octave-signal in version 2.4.0 with 
the reimplementation of normxcorr2, and the dependency on imagemagick 
in version 2.8.0 when it removed the function imdither.


These two dependencies can therefore be dropped from the Debian 
package.


Thank you


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


Kernel: Linux 4.9.0-11-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages octave-image depends on: 
pn  imagemagick
ii  libc6 2.24-11+deb9u4 
ii  libgcc1   1:6.3.0-18+deb9u1 
pn  liboctave3v5   
ii  libstdc++66.3.0-18+deb9u1 
pn  octave


octave-image recommends no packages.

octave-image suggests no packages.

Bug#951247: [Pkg-javascript-devel] Bug#951247: html2canvas: build-depends on removed package libjs-mocha

[Ralf Treinen]

On Thu, Feb 13, 2020 at 11:07:01AM +0100, Xavier wrote:
> Le 13/02/2020 à 09:11, Ralf Treinen a écrit :
> > Source:  html2canvas
> > Version: 0.5.0~beta4+ds1-2
> > Severity: serious
> > User: trei...@debian.org
> > Usertags: edos-uninstallable
> > 
> > Hi,
> > 
> > html2canvas build-depends on libjs-mocha which only exists in
> > old{old}stable.
> > 
> > -Ralf.
> 
> Hi,
> 
> html2canvas is going to be removed from Debian. To you need it as a
> package dependency?

Hi, no I do not need it myself, I was just going through the issues found
by dose-builddebcheck.

Thanks for asking -Ralf.

Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted

[Michael Biebl]

Am 13.02.20 um 14:03 schrieb Trent W. Buck:
> Michael Biebl wrote:
>> Am 13.02.20 um 13:29 schrieb Trent W. Buck:
>>> Packages like udisks2 run "udevadm trigger" in their postinsts.
>>> When building a Debian Live image, if /proc is mounted in the chroot, all 
>>> is well.
>>> When building a Debian Live image, if /proc is NOT mounted in the chroot,
>>> udevadm gives annoying errors, and the whole build crashes.
>>>
>>> Without /proc:
>>>
>>> root@DESKTOP-P00TKMM:/# udevadm trigger
>>> Failed to scan devices: No such file or directory
>>
>> This means, /sys is missing, not proc afaics.
> 
> Thanks for the prompt reply.
> 
> My tests show /proc alone is enough to enable the existing "do nothing" code.
> Giving a longer excerpt from from boring-full-transcript.txt.xz:
> 
> 78root@DESKTOP-P00TKMM:/# udevadm trigger
> Failed to scan devices: No such file or directory

You should only get this error message if /sys is not mounted.
I assume your chroot has neither /sys nor /proc mounted.


systemd-udevd.service has
ConditionPathIsReadWrite=/sys

You could try to convince upstream to add a similar check to "udevadm
trigger"



signature.asc
Description: OpenPGP digital signature

Bug#951251: RFS: ledmon/0.94-1 -- Enclosure LED Utilities

[Adam Borowski]

On Thu, Feb 13, 2020 at 09:01:38AM +, Hsieh-Tseng Shen wrote:
>  * Package name: ledmon
>Version : 0.94-1

> Changes since the last upload:
> 
>* New upstream release 0.94.
>  - Support for AMD IPMI enclosure management.
>  - Support for NPEM.
>* debian/control: add pkg-config and libpci-dev as build dependency.
>* debian/control: update Standards-Version to 4.5.0.
>* Remove obsolete patch.

Hi!
Besides things mentioned above, you also add installation of systemd
.service file.  And, I see some problems there.

+   dh $@ --wth systemd
would look a bit nicer when spelt "--with".

It would also make this section done automatically:
+override_dh_auto_install:
+   dh_auto_install
+   mkdir -p debian/ledmon/lib/systemd/system
+   install -c -m 644 systemd/ledmon.service 
debian/ledmon/lib/systemd/system
+   dh_systemd_enable || true
+   dh_systemd_start || true


Another problem is that you enable the daemon only for systemd.  For any
other init/rc combination there's a need for an init script (and, it would
be enough for systemd too).  Here's one:

.--==[ debian/ledmon.init ]
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides: ledmon
# Required-Start:   $syslog $time
# Required-Stop:$syslog $time
# Default-Start:2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: enclosure LED monitor
# Description: monitoring of storage enclosure LEDs
### END INIT INFO
DAEMON=/usr/sbin/ledmon
`


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ A white dwarf seeks a red giant for a binary relationship.
⠈⠳⣄

Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted

[Trent W. Buck]

Michael Biebl wrote:
> Am 13.02.20 um 13:29 schrieb Trent W. Buck:
>> Packages like udisks2 run "udevadm trigger" in their postinsts.
>> When building a Debian Live image, if /proc is mounted in the chroot, all is 
>> well.
>> When building a Debian Live image, if /proc is NOT mounted in the chroot,
>> udevadm gives annoying errors, and the whole build crashes.
>>
>> Without /proc:
>>
>> root@DESKTOP-P00TKMM:/# udevadm trigger
>> Failed to scan devices: No such file or directory
>
> This means, /sys is missing, not proc afaics.

Thanks for the prompt reply.

My tests show /proc alone is enough to enable the existing "do nothing" code.
Giving a longer excerpt from from boring-full-transcript.txt.xz:

78root@DESKTOP-P00TKMM:/# udevadm trigger
Failed to scan devices: No such file or directory
root@DESKTOP-P00TKMM:/# mount -t proc none /proc
root@DESKTOP-P00TKMM:/# udevadm trigger
Running in chroot, ignoring request.
root@DESKTOP-P00TKMM:/# udevadm --version
241
root@DESKTOP-P00TKMM:/# udevadm control --help
Running in chroot, ignoring request.
root@DESKTOP-P00TKMM:/# umount /proc
root@DESKTOP-P00TKMM:/# udevadm control --help
udevadm control OPTION

Control the udev daemon.

  -h --helpShow this help
  -V --version Show package version
  -e --exitInstruct the daemon to cleanup and exit
  -l --log-priority=LEVEL  Set the udev log level for the daemon
  -s --stop-exec-queue Do not execute events, queue only
  -S --start-exec-queueExecute events, flush queue
  -R --reload  Reload rules and databases
  -p --property=KEY=VALUE  Set a global property for all events
  -m --children-max=N  Maximum number of children
 --pingWait for udev to respond to a ping message
  -t --timeout=SECONDS Maximum time to block for a reply
root@DESKTOP-P00TKMM:/# udevadm control --reload
root@DESKTOP-P00TKMM:/# echo $?
1
root@DESKTOP-P00TKMM:/#

>> It sounds like best current practice is for postinsts to ignore ALL
>> errors[0], which (I think) is worse, because udevadm can be smarter
>> than the postinst about what is a "real" error.
>
> I guess you'd have to convince upstream that this is a good idea to add
> such a check.
>
> Once upstream has such a patch, we can cherry-pick it.

Blergh, I guess I'll have to make a github account and install a GUI
browser so I can interact with upstream directly.


PS: I just dug into the error message from udevadm-trigger.c.
It looks like src/basic/virt.c running_in_chroot() checks $SYSTEMD_IGNORE_CHROOT
...so an easy workaround might be to simply "export SYSTEMD_IGNORE_CHROOT=true"?
Hrm, nope, that variable does the OPPOSITE, per

https://bugzilla.redhat.com/show_bug.cgi?id=1379852#co

PPS: making a regular file at /proc/1/root is sufficient:

(debootstrap chroot)root@not-omega:/# udevadm trigger
Failed to scan devices: No such file or directory
(debootstrap chroot)root@not-omega:/# SYSTEMD_IGNORE_CHROOT=true udevadm 
trigger
Failed to scan devices: No such file or directory
(debootstrap chroot)root@not-omega:/# mkdir /proc/1
(debootstrap chroot)root@not-omega:/# ln -s / /proc/1/root
(debootstrap chroot)root@not-omega:/# udevadm trigger
Failed to scan devices: No such file or directory
(debootstrap chroot)root@not-omega:/# rm /proc/1/root
(debootstrap chroot)root@not-omega:/# ln -s 
/definitely-not-the-root-filesystem /proc/1/root
(debootstrap chroot)root@not-omega:/# udevadm trigger
Failed to scan devices: No such file or directory
(debootstrap chroot)root@not-omega:/# rm /proc/1/root
(debootstrap chroot)root@not-omega:/# echo 'Honestly, this IS a chroot' 
>/proc/1/root
(debootstrap chroot)root@not-omega:/# udevadm trigger
Running in chroot, ignoring request.

Bug#951253: FTBFS with Boost 1.71

[Bas Couwenberg]

On 2020-02-13 13:50, Giovanni Mascellani wrote:

Il 13/02/20 12:11, Bas Couwenberg ha scritto:

  deb https://people.debian.org/~gio/reprepro gio main


Why isn't the new boost-defaults (also) in experimental?


Er, no actual reason. This setup works for me and nobody ever asked me
to upload to experimental. I can do that anyway, if that's better for 
you.


Yes, please.

Myself and others already have chroots with experimental available for 
these kinds of rebuild tests, no needs to create one with your repo for 
boost-defaults.


Kind Regards,

Bas

Bug#951258: phpunit: attempts writing to /usr/bin/.phpunit.result.cache

[merkys]

Package: phpunit
Version: 8.5.2-1

Hello,

phpunit attempts writing to /usr/bin (see for example [1]) as it is
phpunit's default location to store its result cache file. As in Debian
/usr/bin must not be written by non-core programs, I suggest patching
phpunit to choose a location in the current working directory.

Best,
Andrius

[1]
https://buildd.debian.org/status/fetch.php?pkg=php-text-password=all=1.2.1-3=1581586744=0

Bug#951253: FTBFS with Boost 1.71

[Giovanni Mascellani]

Hi,

Il 13/02/20 12:11, Bas Couwenberg ha scritto:
>>   deb https://people.debian.org/~gio/reprepro gio main
> 
> Why isn't the new boost-defaults (also) in experimental?

Er, no actual reason. This setup works for me and nobody ever asked me
to upload to experimental. I can do that anyway, if that's better for you.
> Thanks for looking into the upstream fix.
> 
> It seems Gentoo people already reported the issue for Boost 1.70:
> 
>  https://github.com/mapnik/mapnik/issues/4098
> 
> Which contains the comment:
> 
> "
>  Boost Spirit 1.71 has a small bug which is fixed on 1.72
> "
> 
> Can't we transition to 1.72 in Debian as well, or cherry-pick the spirit
> fix?

I won't start working on any newer Boost version until 1.71 is made
default. However there is still a lot of time for bullseye, so I'd say
it's quite probable that we will have Boost >= 1.72 in bullseye. In this
case I think it is reasonable to temporarily make mapnik depend on Boost
1.67 and fix it once 1.72+ is in.

At the same time I don't have any problem in backporting the fix
Boost.Spirit needs (if it's a reasonable patch), except that I don't
quite understand which one it is.

> Mapnik releases have become much more infrequent, there is not much
> demand for releases from Mapbox which uses development snapshots.

Right. Actually, artemp mentions in the upstream issue that he's
planning to release 3.0.23 asap, but I don't really know when this will
happen.

And, still, we would need to fix Boost 1.71. I asked for pointers on the
upstream issue.

> If we can't get mapnik to work with the default boost in bullseye, we'll
> just not ship it and its rdeps.

Hopefully this extreme solution won't be required. :-)

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles