Bug#958075: crispy-doom: file conflict with chocolate-doom

[Sven Joachim]

Package: crispy-doom
Version: 5.8.0-1
Severity: serious

There was a problem installing your package (sorry for the German):

,
| Vorbereitung zum Entpacken von .../crispy-doom_5.8.0-1_amd64.deb ...
| Entpacken von crispy-doom (5.8.0-1) über (5.6.4-1) ...
| dpkg: Fehler beim Bearbeiten des Archivs 
/var/cache/apt/archives/crispy-doom_5.8.0-1_amd64.deb (--unpack):
|  Versuch, »/usr/share/man/man5/heretic.cfg.5.gz« zu überschreiben, welches 
auch in Paket chocolate-doom 3.0.0-6 ist
| Fehler traten auf beim Bearbeiten von:
|  /var/cache/apt/archives/crispy-doom_5.8.0-1_amd64.deb
`

Since chocolate-doom was there first to ship the offending file, I
assume it should be removed from crispy-doom.

Thanks for crispy-doom! :-)


-- 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.6.5-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 crispy-doom depends on:
ii  libc62.30-4
ii  libpng16-16  1.6.37-2
ii  libsamplerate0   0.1.9-2
ii  libsdl2-2.0-02.0.10+dfsg1-3
ii  libsdl2-mixer-2.0-0  2.0.4+dfsg1-2+b1
ii  libsdl2-net-2.0-02.0.1+dfsg1-4+b1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages crispy-doom recommends:
ii  game-data-packager  64

crispy-doom suggests no packages.

-- no debconf information

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

Hi Matthew,

thanks a lot for your detailed investigation.

On Fri, Apr 17, 2020 at 04:28:23PM -0700, Matthew Fernandez wrote:
> > Program received signal SIGBUS, Bus error.
> > 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30, 
> > pairdist_type=, bPercID=, istart=0, iend=3, 
> > jstart=0, jend=3, fdist_in=0x0, 
> >fdist_out=0x0) at pair_dist.c:346
> > 346 NewProgress(, LogGetFP(, LOG_INFO),
> 
> OK, let me try a little harder :)
> 
> $ # enable debugging symbols and Address Sanitizer
> $ CFLAGS="-g -fsanitize=address" CXXFLAGS="-g -fsanitize=address" 
> ./configure
> …
> $ make clean && make
> …
> $ ./src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
> temp_test.dnd -o temp_test.aln --outfmt clustal --force
> =
> ==30264==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on 
> address 0x7ffcfcbf5784 at pc 0x5620f0aa478c bp 0x7ffcfcbf56c0 sp 
> 0x7ffcfcbf56b8
> WRITE of size 4 at 0x7ffcfcbf5784 thread T0
> #0 0x5620f0aa478b in PairDistances 
> /home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336
> #1 0x5620f0a91d9f in AlignmentOrder 
> /home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:835
> #2 0x5620f0a95c04 in Align 
> /home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:1221
> #3 0x5620f0a90d76 in MyMain 
> /home/matthew/clustal-omega-1.2.4/src/mymain.c:1192
> #4 0x5620f0a88ca2 in main 
> /home/matthew/clustal-omega-1.2.4/src/main.cpp:469
> #5 0x7f3773d9009a in __libc_start_main ../csu/libc-start.c:308
> #6 0x5620f0a89ad9 in _start 
> (/home/matthew/clustal-omega-1.2.4/src/clustalo+0x2dad9)
> 
> Address 0x7ffcfcbf5784 is located in stack of thread T0
> SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow 
> /home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336 in PairDistances
> Shadow bytes around the buggy address:
>   0x10001f976aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x10001f976ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x10001f976ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x10001f976ad0: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca
>   0x10001f976ae0: 04 cb cb cb cb cb cb cb 00 00 00 00 ca ca ca ca
> =>0x10001f976af0:[04]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00
>   0x10001f976b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x10001f976b10: f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2
>   0x10001f976b20: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
>   0x10001f976b30: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>   0x10001f976b40: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
>   Left alloca redzone: ca
>   Right alloca redzone:cb
> ==30264==ABORTING
> 
> Looking at line 336 of pair_dist.c, it looks like the bound on the containing 
> loop is wrong. So let’s try adjusting that:
> 
> $ vim src/clustal/pair_dist.c
> $ git diff src/clustal/pair_dist.c
> diff --git a/src/clustal/pair_dist.c b/src/clustal/pair_dist.c
> index e6dbdc3..bb79e61 100644
> --- a/src/clustal/pair_dist.c
> +++ b/src/clustal/pair_dist.c
> @@ -321,7 +321,7 @@ PairDistances(symmatrix_t **distmat, mseq_t *mseq, 
> int pairdist_type, bool bPerc
> 
>  /* FIXME: can get rid of iChunkStart, iChunkEnd now that we're 
> using the arrays */
>  iChunkStart = iend;
> -for(iChunk = 0; iChunk <= iNumberOfThreads; iChunk++)
> +for(iChunk = 0; iChunk < iNumberOfThreads; iChunk++)
>  {
>  iChunkEnd = iChunkStart;
>  if (iChunk == iNumberOfThreads - 1){
> $ make
> …
> $ ./src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
> temp_test.dnd -o temp_test.aln --outfmt clustal --force
> =
> ==30601==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x561188847864 at pc 0x5611886da6e7 bp 0x7fffe6d77ef0 sp 0x7fffe6d77ee8
> READ of size 4 at 0x561188847864 thread T0
> #0 0x5611886da6e6 in FullAlignment::Build(HMM&, Hit&, char*) 
> 

Bug#948437: gnome-subtitles: diff for NMU version 1.6-2.1

[Boyuan Yang]

Control: tags -1 +patch  +pending

Dear maintainer,

I've prepared an NMU for gnome-subtitles (versioned as 1.6-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru gnome-subtitles-1.6/debian/changelog
gnome-subtitles-1.6/debian/changelog
--- gnome-subtitles-1.6/debian/changelog2020-03-14 20:08:38.0 +
+++ gnome-subtitles-1.6/debian/changelog2020-04-18 04:22:24.0 +
@@ -1,3 +1,17 @@
+gnome-subtitles (1.6-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/control:
++ Migrate build-dependency to enchant-2.
++ Update debhelper minimal version to 9+ for consistency
+  with debian/compat.
++ Replace obsolete build-dependency gnome-doc-utils with
+  yelp-tools. (Closes: #956725)
+  * debian/patches: Add patch to migrate the package to use
+enchant-2. (Closes: #948437)
+
+ -- Boyuan Yang   Sat, 18 Apr 2020 04:22:24 +
+
 gnome-subtitles (1.6-2) unstable; urgency=medium

   * Minor fixes on debian/copyright and debian/control files.
diff -Nru gnome-subtitles-1.6/debian/control gnome-subtitles-1.6/debian/control
--- gnome-subtitles-1.6/debian/control2020-03-14 20:07:18.0 +
+++ gnome-subtitles-1.6/debian/control2020-04-18 04:22:22.0 +
@@ -4,19 +4,19 @@
 Maintainer: Debian CLI Applications Team

 Uploaders: Tiago Bortoletto Vaz , Mirco Bauer

 Build-Depends: cli-common-dev (>= 0.8),
- debhelper (>= 7),
+ debhelper (>= 9),
  autotools-dev,
  mono-devel (>= 4.0),
  libgtk-3-dev (>= 3.12),
  gtk-sharp3 (>= 2.99.2),
- libenchant-dev,
+ libenchant-2-dev,
  libgtkspell3-3-dev,
  libgstreamer1.0-dev,
  libgstreamer-plugins-base1.0-dev,
  docbook-xml ,
- gnome-doc-utils (>= 0.3.2),
  itstool,
- intltool (>= 0.50)
+ intltool (>= 0.50),
+ yelp-tools,
 Standards-Version: 4.5.0
 Homepage: http://gnomesubtitles.org
 Vcs-Git: https://salsa.debian.org/dotnet-team/gnome-subtitles.git
@@ -36,7 +36,7 @@
  gstreamer1.0-plugins-good,
  gstreamer1.0-libav,
  libgtkspell3-3-0 (>= 3.0),
- enchant (>= 1.6)
+ enchant-2,
 Recommends: gstreamer0.10-ffmpeg
 Description: Subtitle editor for the GNOME Desktop environment
  Gnome Subtitles is a subtitle editor for the GNOME desktop.
diff -Nru gnome-subtitles-1.6/debian/patches/0001-Migrate-to-enchant-2.patch
gnome-subtitles-1.6/debian/patches/0001-Migrate-to-enchant-2.patch
--- gnome-subtitles-1.6/debian/patches/0001-Migrate-to-enchant-2.patch
   1970-01-01 00:00:00.0 +
+++ gnome-subtitles-1.6/debian/patches/0001-Migrate-to-enchant-2.patch
   2020-04-18 04:14:42.0 +
@@ -0,0 +1,23 @@
+From: Boyuan Yang 
+Date: Sat, 18 Apr 2020 04:13:07 +
+Subject: Migrate to enchant-2
+
+Patch picked from https://bugs.debian.org/953379 . This is
+provided by the upstream.
+
+Bug-Debian: https://bugs.debian.org/948437
+---
+ src/GnomeSubtitles/Execution/gnome-subtitles.exe.config | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/GnomeSubtitles/Execution/gnome-subtitles.exe.config
b/src/GnomeSubtitles/Execution/gnome-subtitles.exe.config
+index fa663ae..4777925 100644
+--- a/src/GnomeSubtitles/Execution/gnome-subtitles.exe.config
 b/src/GnomeSubtitles/Execution/gnome-subtitles.exe.config
+@@ -1,5 +1,5 @@
+ 
+ 
+-
++
+ 
+ 
diff -Nru gnome-subtitles-1.6/debian/patches/series
gnome-subtitles-1.6/debian/patches/series
--- gnome-subtitles-1.6/debian/patches/series1970-01-01
00:00:00.0 +
+++ gnome-subtitles-1.6/debian/patches/series2020-04-18
04:14:42.0 +
@@ -0,0 +1 @@
+0001-Migrate-to-enchant-2.patch

Bug#958071:

[Yangfl]

Already done here https://ftp-master.debian.org/new/libtpms_0.7.0-1.html

Bug#958074: sane-utils: saned cannot access scanner when no-one is logged in

[Olaf Meeuwissen]

Package: sane-utils
Version: 1.0.27-3.2
Severity: important

Dear Maintainer,

I've been looking into

  https://gitlab.com/sane-project/backends/-/issues/275

and have been able to reproduce the issue reported.  When accessing
saned from another machine when someone is logged in, it faithfully
reports the scanner that is available.  However, when that someone
logs out, saned looses access permissions to the device.

I would have expected a scan server to work even when no-one is logged
onto the server.  For the record, with Debian 9 (stretch) that was the
case, making this a regression.

BTW, it also seems decidedly odd that the saned *user* obtains device
access when some random user, not in the scanner and/or saned groups,
logs in.

-- System Information:
Architecture: x86_64

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

Versions of packages sane-utils depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libelogind0 [libsystemd0]  241.4-2
ii  libieee1284-3  0.2.11-13
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libpng16-161.6.36-6
ii  libsane1.0.27-3.2
ii  libusb-1.0-0   2:1.0.22-2
ii  lsb-base   10.2019051400
ii  update-inetd   4.49

sane-utils recommends no packages.

Versions of packages sane-utils suggests:
pn  avahi-daemon  
pn  unpaper   

-- Configuration Files:
/etc/sane.d/saned.conf changed:
192.168.11.24


-- debconf information:
  sane-utils/saned_scanner_group: true
  sane-utils/saned_run: false

--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

Bug#958073: forensics-extra: please remove dependency on flasm (FTBFS, unmaintained, obsolete ecosystem/version)

[Eriberto]

Thanks Paul. Doing it.

Bug#958035: libpango1.0-0 transitional package must be provided without tight version

[Drew Parsons]

On 2020-04-18 02:37, Simon McVittie wrote:
...

Minecraft is another proprietary package with the same issue: #956520
(which also mentions dropbox).


Interesting. Strange that these 3rd party providers provide a thing, but 
then fail to check if it's actually still working or up-to-date.


flashplugin-nonfree doesn't seem to have worked correctly since 2017, 
the
plugin it installs is full of known security vulnerabilities, and, 
again,

browsers have dropped NPAPI support, so I can't say I feel particularly
guilty about breaking that one.


True on its own, it no longer pulls latest versions from Adobe. But the 
update-flashplugin-nonfree script has been useful for applying latest 
versions downloaded manually from adobe.com, after hacking the script to 
handle a local tarball file (the patch from 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851066#69 ).  Maybe I 
should nmu flashplugin-nonfree to fix some things.




One possibility is to bring back the transitional package for one more
release cycle (ugh), give it (>=) rather than (=) dependencies on 
libraries
from the same source package like you suggested, but downgrade the 
Depends
on libpangox-1.0-0 to Recommends or Suggests? That's not *strictly* 
correct,

but maybe close enough?



Certainly good enough for me.  Your call on libpangox-1.0-0 :)

Drew

Bug#472477:

[Peter Matulis]

There may be other ways to disable the thing but try this:

echo 'Hidden=true' | sudo tee -a
/etc/xdg/autostart/gnome-keyring-ssh.desktop

Bug#957918: vor-0.5.8 upstream release

[Jason Woofenden]

Hi!

I'm psyched to have an active Debian package maintainer.

I've released vor-0.5.8!

This release builds with gcc-10 :)

I also made a few little cleanup things that might need to be updated in
the package as well:

I've updated the URLs:

The home page is now: https://sametwice.com/vor

Looks like you have that in debian/control, but please update the link in
debian/vor.6 to https.

You wrote a man page! Thanks! Here's a tweak for it:

It looks like it says `-l` for fullscreen, but the correct flag is `-f`.


I moved the canonical repo to github: https://github.com/JasonWoof/vor

I also renamed the README and README.font files (to README.md and
README_font.md respectively) and added a little markdown formatting.


Thanks for packaging!

- Jason

Bug#955432: gnome-shell-xrdesktop: FTBFS: dh_missing: warning: usr/share/bash-completion/completions/gnome-extensions exists in debian/tmp but is not installed to anywhere

[李健秋]

Package: gnome-shell-xrdesktop
Followup-For: Bug #955432


Hi Andreas,

gnome-shell-xrdekstop version 3.36.1-1 builds on buildd:
 https://buildd.debian.org/status/package.php?p=gnome-shell-xrdesktop

I'll close this.

Best regards,
-Andrew

Bug#958073: forensics-extra: please remove dependency on flasm (FTBFS, unmaintained, obsolete ecosystem/version)

[Paul Wise]

Source: forensics-extra
Severity: important
Control: block 958067 by -1

Please remove the dependency on flasm, I want to remove it from Debian
(#958067). It FTBFS with GCC 10, is no longer maintained upstream, is a
disassembler for the obsolete Flash platform and doesn't even support
the latest obsolete versions of the Flash platform.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#958072: ITP: xgboost -- Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: xgboost
* URL : https://github.com/dmlc/xgboost
* License : Apache-2
  Programming Lang: C++, Pyhton
  Description : Scalable, Portable and Distributed Gradient Boosting (GBDT, 
GBRT or GBM) Library


Useful for the data science community. Will be maintained under the
debian deeplearning team.

Bug#958071: ITP: libtpms -- Library for TPM 1.2 and 2.0 emulator

[Seunghun Han]

Package: wnpp
Severity: wishlist

* Package name: libtpms
  Version : 0.8.0~dev1
  Upstream Author : Stefan Berger 
* URL : https://github.com/stefanberger/libtpms/wiki
* License : 3-clause BSD license
  Programming Lang: C
  Description : Library for TPM 1.2 and 2.0 emulator

LIBTPMS provides TPM emulation for TPM 1.2 and TPM 2.0 without tying it to
a specific storage backend or an interface for receiving TPM commands.
One user of the LIBTPMS package is the SWTPM package.

The SWTPM package provides several tools and simulating the manufacturing
of a TPM by creating a TPM's EK and platform certificates, etc.

This package is needed by qemu and/or libvirt for their "emulated TPM"
feature. TPM has been widely used, so supporting TPM for a virtual machine
is important for users and developers.

Upstream already has a debian/ directory in git, so I revise it for the
recent Debian package format.

Bug#958070: RFP: meshroom -- 3D Reconstruction Software

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: meshroom
  Version : 2019.2.0
  Upstream Author : alicevision-t...@googlegroups.com
* URL : https://github.com/alicevision/meshroom
* License : MPL2
  Programming Lang: Python
  Description : 3D Reconstruction Software

Meshroom is a free, open-source 3D Reconstruction Software based
on the AliceVision Photogrammetric Computer Vision framework.

Photogrammetry is the science of making measurements from photographs.
It infers the geometry of a scene from a set of unordered photographs or
videos. Photography is the projection of a 3D scene onto a 2D plane,
losing depth information. The goal of photogrammetry is to reverse
this process.

Bug#956254: python3-pykdl: PyKDL crashes Python 3 interpretter (SIGABRT) if any API accepting a str is used

[Shane Loretz]

I tested the orocos-kdl 1.4.0-9 sources using debuild/dpkg -i in a Debian
Buster container and can confirm it works for my use case. Thanks again!

On Thu, Apr 9, 2020 at 10:01 AM Jochen Sprickerhof 
wrote:

> Hi Shane,
>
> * Shane Loretz  [2020-04-08 22:19]:
> >Would you be willing to apply that patch and release a new version to
> >Buster and Sid?
>
> I've uploaded a fixed version to sid and proposed an update to the
> release team in #956315. Thanks for opening the bug!
>
> Cheers Jochen
>

Bug#958069: lxc: newer upstream version 4.0.2 was released

[Ryutaroh Matsumoto]

Package: lxc
Version: 1:3.1.0+really3.0.4-3
Severity: wishlist
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: cgroupv2
Control: block 943981 by -1

Dear Maintainer,

A newer upstream version 4.0.2 was released at
https://github.com/lxc/lxc/releases

The version 4 should fix all cgroupv2 related LXC bugs in

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=cgroupv2

Best regards, Ryutaroh Matsumoto

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

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.30-4
ii  libgcc-s1  10-20200324-1
ii  liblxc11:3.1.0+really3.0.4-3
ii  lsb-base   11.1.0

Versions of packages lxc recommends:
ii  apparmor   2.13.3-7
pn  bridge-utils   
pn  debootstrap
pn  dirmngr
pn  dnsmasq-base   
pn  gnupg  
ii  iproute2   5.5.0-1
ii  iptables   1.8.4-3
pn  libpam-cgfs
pn  lxc-templates  
pn  lxcfs  
ii  openssl1.1.1d-2
pn  rsync  
pn  uidmap 

Versions of packages lxc suggests:
pn  btrfs-progs  
pn  lvm2 
pn  python3-lxc  

-- debconf information:
  lxc/auto_update_config:

Bug#958068: gnome-shell crashes during normal system use. Workspace related problem

[Marcelo Luiz de Laia]

Package: gnome-shell
Version: 3.36.1-5
Severity: important

Dear Maintainer,

After upgrade, today, the gnome-shell crashes. May be it was related to
workspace. Mouse and keyboard work normally, but any application was opened
inside first workspace window at the right side of primary monitor. Nothing is
opened in the visible area, except ALT+F2 command line. In this command line I
enter "r" followed ENTER and the gnome shell restart. I work window was
restored and the job can continue. I think nothing is lost. But, this is very
annoying and, before figure out how restart gnome-shell, I needed to reboot my
system a lot off. In a site, I read that this behavioris related to mutter
package, too. That's all.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  evolution-data-server3.36.1-1
ii  gir1.2-accountsservice-1.0   0.6.55-1
ii  gir1.2-atspi-2.0 2.36.0-2
ii  gir1.2-freedesktop   1.64.1-1
ii  gir1.2-gcr-3 3.36.0-2
ii  gir1.2-gdesktopenums-3.0 3.36.0-1
ii  gir1.2-gdm-1.0   3.34.1-3
ii  gir1.2-geoclue-2.0   2.5.6-1
ii  gir1.2-glib-2.0  1.64.1-1
ii  gir1.2-gnomebluetooth-1.03.34.1-1
ii  gir1.2-gnomedesktop-3.0  3.36.1-2
ii  gir1.2-gtk-3.0   3.24.18-1
ii  gir1.2-gweather-3.0  3.36.0-1
ii  gir1.2-ibus-1.0  1.5.22-4
ii  gir1.2-mutter-6  3.36.1-4
ii  gir1.2-nm-1.01.23.90-1
ii  gir1.2-nma-1.0   1.8.24-1
ii  gir1.2-pango-1.0 1.44.7-3
ii  gir1.2-polkit-1.00.105-26
ii  gir1.2-rsvg-2.0  2.48.2-1
ii  gir1.2-soup-2.4  2.70.0-1
ii  gir1.2-upowerglib-1.00.99.11-1
ii  gjs  1.64.1-3
ii  gnome-backgrounds3.36.0-1
ii  gnome-settings-daemon3.36.0-1+b1
ii  gnome-shell-common   3.36.1-5
ii  gsettings-desktop-schemas3.36.0-1
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libecal-2.0-13.36.1-1
ii  libedataserver-1.2-243.36.1-1
ii  libgcr-base-3-1  3.36.0-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libgirepository-1.0-11.64.1-1
ii  libgjs0g 1.64.1-3
ii  libgles2 1.3.1-1
ii  libglib2.0-0 2.64.1-1
ii  libglib2.0-bin   2.64.1-1
ii  libgnome-autoar-0-0  0.2.4-1
ii  libgnome-desktop-3-193.36.1-2
ii  libgraphene-1.0-01.10.0-1
ii  libgstreamer1.0-01.16.2-2
ii  libgtk-3-0   3.24.18-1
ii  libical3 3.0.8-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-6-03.36.1-4
ii  libnm0   1.23.90-1
ii  libpango-1.0-0   1.44.7-3
ii  libpangocairo-1.0-0  1.44.7-3
ii  libpolkit-agent-1-0  0.105-26
ii  libpolkit-gobject-1-00.105-26
ii  libpulse-mainloop-glib0  13.0-5
ii  libpulse013.0-5
ii  libsecret-1-00.20.2-1
ii  libsystemd0  245.4-3
ii  libwayland-server0   1.18.0-1
ii  libx11-6 2:1.6.9-2
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.36.1-4
ii  python3  3.8.2-3

Versions of 

Bug#955323: RFS: atomic-chrome-el/2.0.0-1 [ITP] -- edit a web-browser text entry area with Emacs

[Antoine Beaupré]

Hello Nicholas!

A few problems...

these commands:

git clone g...@salsa.debian.org:emacsen-team/atomic-chrome-el.git
cd atomic-chrome-el
uscan --download-current-version
git bp

give me this error:

anarcat@angela:atomic-chrome-el(master)$ git bp 
dh clean --with elpa
   dh_clean
gbp:info: Creating atomic-chrome_2.0.0.orig.tar.xz from 'v2.0.0'
gbp:info: Exporting 'HEAD' to 
'/home/anarcat/src/build-area/atomic-chrome-tmp'
gbp:info: Moving '/home/anarcat/src/build-area/atomic-chrome-tmp' to 
'/home/anarcat/src/build-area/atomic-chrome-2.0.0'
gbp:info: Performing the build
dpkg-source: error: source package has two conflicting values - 
atomic-chrome-el and atomic-chrome
E: Failed to run dpkg-source --before-build 
/home/anarcat/src/build-area/atomic-chrome-2.0.0

i am not sure, but i suspect it is a mismatch between the
debian/changelog and debian/control package names. indeed, with the
following patch:

From 419b3c708fbc41e727fc2dd880b7d90da8ada692 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Fri, 17 Apr 2020 20:52:07 -0400
Subject: [PATCH] fix package name to match debian/control

---
 debian/changelog | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index d11e6c7..98e3daa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-atomic-chrome (2.0.0-1) unstable; urgency=medium
+atomic-chrome-el (2.0.0-1) unstable; urgency=medium
 
   * Initial release. (Closes: #909336)
 
-- 
2.20.1

... the package compiles.

The other issue I found is what now seems to be a recurring disagreement
between us. :) This is the tarball that `uscan` gives me when I run the
above command:

anarcat@angela:src(master)$ sha256sum atomic-chrome-2.0.0.tar.gz 
f239fabd2438df8d947b333453534e6ab76f946c8879df2e3f1151baf76dac97  
atomic-chrome-2.0.0.tar.gz
anarcat@angela:src(master)$ file atomic-chrome-2.0.0.tar.gz
atomic-chrome-2.0.0.tar.gz: gzip compressed data, from Unix, original size 
296960

Yet, git-buildpackage will not use that tarball. Because it has the
following configuration:

compression = xz
compression-level = 9

It generates the following, different tarball:

anarcat@angela:atomic-chrome-el(master)$ sha256sum 
../build-area/atomic-chrome-el_2.0.0.orig.tar.xz 
2d55a3646307be8c4b1703e3f353a358987592d6523a8de0ffb7be1292e678ab  
../build-area/atomic-chrome-el_2.0.0.orig.tar.xz
anarcat@angela:atomic-chrome-el(master)$ file 
../build-area/atomic-chrome-el_2.0.0.orig.tar.xz
../build-area/atomic-chrome-el_2.0.0.orig.tar.xz: XZ compressed data

There are a few things wrong here:

 1. we should not needlessly differ from the upstream tarball

 2. if we really have to, `uscan` should allow us to reconstruct our
tarball reproducibly, or at least `README.source` should explain
how. at minimum, `README.source` should explain *why* we differ

 3. even if we insist on using `xz` (and I don't see why we do in this
case), we don't need the maximum compression level. this is a small
package and there's not reason to "crank it up to 11", so to speak :)

The following patch should fix the problem:

From a9dc9a10a4c1ea9024a70335232dd837d36738d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Fri, 17 Apr 2020 21:01:14 -0400
Subject: [PATCH] remove superfluous diff with upstream tarball

---
 debian/gbp.conf | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/debian/gbp.conf b/debian/gbp.conf
index 07b0329..839ffea 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -6,6 +6,3 @@ debian-tag = debian/%(version)s
 sign-tags = True
 pristine-tar = False
 pristine-tar-commit = False
-
-compression = xz
-compression-level = 9
-- 
2.20.1

I feel uncomfortable sponsoring a package if it doesn't use the upstream
tarballs. I hope you'll understand.

A.

-- 
Nature hides her secret because of her essential loftiness, but not by
means of ruse.
   - Albert Einstein


signature.asc
Description: PGP signature

Bug#958067: RM: flasm -- ROM; FTBFS, not maintained upstream, for obsolete Flash platform

[Paul Wise]

Package: ftp.debian.org
Severity: normal

Please remove flasm from unstable. It FTBFS with GCC 10, is no longer
maintained upstream, is a disassembler for the obsolete Flash platform
and doesn't even support the latest obsolete versions of the platform.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#958064: sphinxcontrib-httpdomain: Fails to register with sphinx

[Martina Ferrari]

Merge request created at

https://salsa.debian.org/openstack-team/third-party/sphinxcontrib-httpdomain/-/merge_requests/1

On 18/04/2020 01:29, Martina Ferrari wrote:
> Source: sphinxcontrib-httpdomain
> Version: 1.5.0-1
> Severity: grave
> Tags: patch
> Justification: renders package unusable
> 
> I have been unable to use this package for a few months, but could not find
> what I was doing wrong, and assumed that such a basic problem would be
> affecting other users, but there are no bugs reported. I guess this package 
> has
> no users :-)
> 
> Since version 1.5.0-1, the http domain is not registered with Sphinx when
> loading this plugin, and therefore, all :http:* directives are ignored and
> discarded when generating the documentation.
> 
> The problem is that this version included a patch that comes from this
> upstream commit[1], but it is missing the fix added a couple of days after in
> this other commit[2].
> 
> Just adding the commit at [2] as a patch fixes the problem. I am opening now 
> a merge
> request in salsa including it.
> 
> [1]: 
> https://github.com/sphinx-contrib/httpdomain/commit/50166fc7caedccf4ce1cd58a4d130a36f27eb739
> [2]: 
> https://github.com/sphinx-contrib/httpdomain/commit/8243bb6ec1ea0f3c96e0ed6177e743963fdd908b
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
> 

Bug#958066: devscripts: mk-origtargz fails silently with bad Files-Excluded line

[Nick Black]

Package: devscripts
Version: 2.20.2
Severity: normal
Tags: upstream

Dear Maintainer,

I'm packaging notcurses, and per my FTPMasters review, I've been attempting to
move to a uscan-based repack with a Files-Excluded line in debian/copyright. I
lost an hour or so to uscan failing in mk-origtargz, finally tracking it down
to a malformed wildcard in debian/copyright. mk-origtargz prints no diagnostic
in such a case, simply returning 1.

It would have been very useful if mk-origtargz, and ideally uscan atop it,
could have pointed me to the source of the problem. Eventually I worked it out
with perl -x d:Trace, but even then the issue was not obvious.

Thanks!



-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

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

Kernel: Linux 5.6.4nlb (SMP w/64 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: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.24-1
ii  file  1:5.38-4
ii  gnupg 2.2.20-1
ii  gpgv  2.2.20-1
ii  libc6 2.30-4
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-2
ii  libmoo-perl   2.004000-1
ii  libwww-perl   6.44-1
ii  patchutils0.3.4-2+b1
ii  perl  5.30.0-9
ii  python3   3.8.2-3
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.0.2
pn  at  
ii  curl7.68.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.03.24
ii  dput1.0.3
ii  dupload 2.9.5
ii  equivs  2.2.0
ii  libdistro-info-perl 0.23
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.25-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-2
ii  licensecheck3.0.46-1
ii  lintian 2.65.0
ii  man-db  2.9.1-1
ii  patch   2.7.6-6
ii  python3-apt 2.1.1
ii  python3-debian  0.1.37
ii  python3-magic   2:0.4.15-3
ii  python3-requests2.23.0+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.26-2
ii  strace  5.5-3
ii  unzip   6.0-25
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
ii  autopkgtest  5.13
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1+b1
ii  build-essential  12.8
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13
pn  devscripts-el
ii  diffoscope   141
ii  disorderfs   0.5.9-1
pn  dose-extra   
pn  duck 
ii  faketime 0.9.7-3
ii  gnuplot  5.2.8+dfsg1-2
ii  gnuplot-qt [gnuplot] 5.2.8+dfsg1-2
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
ii  libterm-size-perl0.209-1+b2
ii  libtimedate-perl 2.3200-1
ii  libyaml-syck-perl1.32-2
ii  mailutils [mailx]1:3.7-2.1
pn  mozilla-devscripts   
ii  mutt 1.13.2-1
ii  openssh-client [ssh-client]  1:8.2p1-4
ii  piuparts 1.1.1
pn  postgresql-client
ii  quilt0.66-1
pn  ratt 
pn  reprotest
ii  svn-buildpackage 0.8.7
ii  w3m  0.5.3-37+b1

-- no debconf information

Bug#472477: ssh-add -D does not remove SSH key from gnome-keyring-daemon memory

[Alex King]

This still appears to be a problem.

I can't log in to some remote machines because there are too many keys 
loaded, and gnome-keyring-daemon won't remove them.


I have been affected by this quite a few times over the years, it has 
wasted hours of my time.  It means I need to use workarounds which just 
cause unnecessary effort.


This prevents ssh working.  It is a potential security bug.  It would be 
great if the gnome maintainers could do something about it after 12 years.


Thanks,
Alex

On Wed, 05 Sep 2018 17:45:46 +0200 =?UTF-8?Q?J=C3=A9r=C3=B4me?= 
 wrote:


> I think I just got caught by this.
>
> I'm using Debian Stretch/Mate and I had SSH Gnome keyring launched at
> startup (install default, I guess).
>
> Indeed I do see gnome-keyring in ps ax:
>
> 1255 ? Sl 0:03 /usr/bin/gnome-keyring-daemon --daemonize
> --login
>
> While testing ssh keys, I created a key and added a .ssh/config file
> with this content:
>
> Host github.com
> IdentityFile ~/.ssh/github-test.key
>
> I checked I could connect.
>
> Then I removed the file and even the key itself. And I could still
> connect (!).
>
> I figured keys must be cached somehow and found out about ssh-agent.
>
> I tried to delete the key cache using
>
> ssh-add -D
>
> And althouth it says
>
> All identities removed.
>
> all the keys in the cache still appear when running
>
> ssh-add -l
>
> echo $SSH_AGENT_PID
> 1336
>
> ps ax:
>
> 1336 ? Ss 0:04 /usr/bin/ssh-agent x-session-manager
>
> gnome-keyring 3.20.0-3
> openssh-client 1:7.4p1-10+deb9u4
>
> I have no idea what more I could provide to turn this message into
> something helpful...
>
> --
> Jérôme
>
>
>

Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost

[Christoph Anton Mitterer]

Source: linux
Version: 5.5.17-1
Severity: important


Hi.

I've just switched from the linux-image-5.5.0-1-amd64-unsigned to 
linux-image-5.5.0-1-amd64
(which wasn't available as soon as the -unsigned version) in on go via apt.


The consequence was, that many modules were missing.


Looking at the apt/term.log:

Removing linux-image-5.5.0-1-amd64-unsigned
[then debconf asks whether I want to remove the running image]
Removing the running kernel
/etc/kernel/prerm.d/dkms:
dkms: removing: openafs 1.8.6pre1 (5.5.0-1-amd64) (x86_64)
[...]
depmod...

DKMS: uninstall completed.
[...]
Selecting previously unselected package linux-image-5.5.0-1-amd64.
Preparing to unpack .../linux-image-5.5.0-1-amd64_5.5.13-2_amd64.deb ...
Unpacking linux-image-5.5.0-1-amd64 (5.5.13-2) ...
Preparing to unpack .../linux-image-amd64_5.5.13-2_amd64.deb ...
Unpacking linux-image-amd64 (5.5.13-2) over (5.4.19-1) ...
[...]
Removing linux-image-5.4.0-4-amd64 (5.4.19-1) ...
/etc/kernel/prerm.d/dkms:
dkms: removing: openafs 1.8.6pre1 (5.4.0-4-amd64) (x86_64)
[...]
depmod...

DKMS: uninstall completed.
[...]
Setting up linux-image-5.5.0-1-amd64 (5.5.13-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.2.0-3-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.2.0-3-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.5.0-1-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.5.0-1-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.5.0-1-amd64:.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.5.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_09.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/skl_huc_2.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_2.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/glk_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/cml_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/cml_guc_33.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/icl_huc_9.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/ehl_huc_9.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_33.0.4.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.0.3.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_35.2.0.bin for module 
i915
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.5.0-1-amd64
Found initrd image: /boot/initrd.img-5.5.0-1-amd64
Found linux image: /boot/vmlinuz-5.2.0-3-amd64
Found initrd image: /boot/initrd.img-5.2.0-3-amd64
Configured General Secure System
Found memtest86+ image: /root/boot/memtest86+.bin
Found memtest86+ multiboot image: /root/boot/memtest86+_multiboot.bin
done
[...]
Setting up xtables-addons-dkms (3.9-1) ...
Loading new xtables-addons-3.9 DKMS files...
Building for 5.5.0-1-amd64
Building initial module for 5.5.0-1-amd64
Done.
[...]
depmod...

DKMS: install completed.
[...]


So far, so good...


Purging configuration files for linux-image-5.5.0-1-amd64-unsigned (5.5.13-2) 
...
I: /vmlinuz is now a symlink to boot/vmlinuz-5.2.0-3-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.2.0-3-amd64
rmdir: failed to remove '/lib/modules/5.5.0-1-amd64': Directory not empty
Purging configuration files for linux-image-5.4.0-4-amd64 (5.4.19-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.5.0-1-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.5.0-1-amd64
Processing triggers for tex-common (6.14) ...
[here apt ends after some further triggers]


Looking at the postrm:
if [ "$1" = purge ]; then
for extra_file in modules.dep modules.isapnpmap modules.pcimap \
  modules.usbmap modules.parportmap \
  modules.generic_string modules.ieee1394map \
  modules.ieee1394map modules.pnpbiosmap \
  modules.alias modules.ccwmap modules.inputmap \
  modules.symbols modules.ofmap \
  modules.seriomap modules.\*.bin \
  modules.softdep modules.devname; do
eval rm -f /lib/modules/$version/$extra_file
done
rmdir /lib/modules/$version || true
fi


It deletes all modules... which are however already belonging to the
signed version of the package.


Interestingly, and I don't quite understand this, not all modules were deleted.
Cause I spotted the failed rmdir right away and looked briefly at the dir
and modules were still there.

However, after reboot, e.g. iwlwifi was gone.

Bug#958064: sphinxcontrib-httpdomain: Fails to register with sphinx

[Martina Ferrari]

Source: sphinxcontrib-httpdomain
Version: 1.5.0-1
Severity: grave
Tags: patch
Justification: renders package unusable

I have been unable to use this package for a few months, but could not find
what I was doing wrong, and assumed that such a basic problem would be
affecting other users, but there are no bugs reported. I guess this package has
no users :-)

Since version 1.5.0-1, the http domain is not registered with Sphinx when
loading this plugin, and therefore, all :http:* directives are ignored and
discarded when generating the documentation.

The problem is that this version included a patch that comes from this
upstream commit[1], but it is missing the fix added a couple of days after in
this other commit[2].

Just adding the commit at [2] as a patch fixes the problem. I am opening now a 
merge
request in salsa including it.

[1]: 
https://github.com/sphinx-contrib/httpdomain/commit/50166fc7caedccf4ce1cd58a4d130a36f27eb739
[2]: 
https://github.com/sphinx-contrib/httpdomain/commit/8243bb6ec1ea0f3c96e0ed6177e743963fdd908b

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#850644: ITP: guix -- A functional package manager based on Scheme

[Vagrant Cascadian]

Control: retitle 850644 ITP: guix -- A functional package manager based on 
Scheme

All the build-depends are packaged and may as well call this an ITP now.
Would still very much welcome help maintaining this, though!

Packaging branch updated to 1.1.0:

  https://salsa.debian.org/vagrant/guix


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#956931: Fwd: Bug#956931: autopkgtest: Build profiles support for autopkgtest

[Antonio Terceiro]

On Fri, Apr 17, 2020 at 09:56:29AM +0200, Julian Andres Klode wrote:
> On Thu, Apr 16, 2020 at 11:04:02PM +0200, Jiri Palecek wrote:
> > 
> > 
> > 
> >  Forwarded Message 
> > Subject:Bug#956931: autopkgtest: Build profiles support for autopkgtest
> > Resent-Date:Thu, 16 Apr 2020 20:42:01 +
> > Resent-From:Jiri Palecek 
> > Resent-To:  debian-bugs-dist@lists.debian.org
> > Resent-CC:  jpale...@web.de, Debian CI team 
> > Date:   Thu, 16 Apr 2020 22:38:07 +0200
> > From:   Jiri Palecek 
> > Reply-To:   Jiri Palecek , 956...@bugs.debian.org
> > To: Debian Bug Tracking System 
> > 
> > 
> > 
> > Package: autopkgtest
> > Version: 5.12.2~6.gbp89ad39
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > with the latest and greatest changes in dpkg, I think it would be nice
> > if autopkgtest followed suit. Particularly, it would be advantageous to
> > support running and building tests in autopkgtest under build profiles
> > (esp. nodoc!). This would allow for smaller test footprint, less
> > packages to pull (ie. you don't need texlive on the testbed), and faster
> > building of the packages.
> > 
> > I prepared a patch implementing such a change here:
> > https://salsa.debian.org/jpalecek-guest/autopkgtest/-/commit/6275da59305d6e836cb3558f9f442479eb24fc95
> > 
> > The patch is functional, albeit incomplete due to missing documentation.
> > 
> > The real issue is the control file format. In my patch, I use an extra
> > stanza to specify build profiles, like this:
> > 
> > Build-Profiles: nodoc
> > 
> > Tests: run-some-tests
> > <<<
> > 
> > I chose this format, because adding the specification to some of the
> > tests would be IMHO misleading: the build profile applies to all of the
> > tests indiscriminately, not to any particular one. Also, I chose to
> > apply them to all @builddep@ dependencies as well.
> > 
> > However, there is a problem about this: it makes the control file format
> > non-backwards-compatible. Particularly, dpkg needs to be patched or it
> > will croak on packages with such d/t/control. Maybe, some artificial
> > Tests: line like
> > 
> > Tests: *
> > 
> > could be added? That would make the change backwards compatible. Dpkg
> > still needs to be patched, but the change would be rather minimal.
> > 
> > What do you think about this proposal? Please comment here or on
> > salsa. I'm also CC-ing the dpkg developers, since it concerns them.
> 
> I understand the motivation for testing in-archive, but this creates
> a problem for local testing of unbuilt packages. We want to test as
> close to the archive as possible, meaning that the packages we test
> should be built with the same build profile as in the archive.
> 
> I'm not sure how this is currently handled, but I'd really not
> want to go through the trouble of building twice, once without
> profiles to get the .debs, and then with build profiles for tests
> with build-needed.
> 
> And of course, I don't want to just build with those build profiles,
> because then it's different from the archive, and I don't get the
> guarantees I want (namely, I want to be reasonably certain that
> if I run autopkgtest on my .dsc, that it will built and test
> successfully in the archive as well; including docs, obviously).
> 
> So, in summary, I think it's not a good idea.

Agreed.

FWIW, I would like autopkgtest to be less involved, not more, with
building packages at all. I think build-needed tests are a terrible
idea, and I would not like to add any involved mechanism to control how
autopkgtest builds packages - I think it being able to build packages in
the simplest way possible is already too much.

If one wants to optimize testing time, they should fix their package so
that it can be tested without requiring another build.


signature.asc
Description: PGP signature

Bug#958027: CVE-2020-11868 affecting ntpsec?

[Richard Laager]

On 4/17/20 10:02 AM, Moritz Muehlenhoff wrote:
> CVE-2020-11868 was assigned for NTP, does this also affect ntpsec in some way?

Thanks for letting me know. I don't feel qualified to answer that. That
said, the code there is very similar, so NTPsec might very well be affected.

I've forwarded this to secur...@ntpsec.org. We'll see what they say.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Matthew Fernandez]

> On Apr 17, 2020, at 13:18, Andreas Tille  wrote:
> 
> Hi Matthew,
> 
> On Fri, Apr 17, 2020 at 08:18:29AM -0700, Matthew Fernandez wrote:
>>> Thanks for the patch which I applied to packaging Git.  I assume you
>>> want to express that while these fixes are definitely good coding
>>> practice the bus error problem is not fixed by it, right?
>> 
>> Thanks, Andreas. It may fix the bus error, but I don’t have a MIPS machine
>> to test on. Some of those logging calls had the potential to leave you with
>> a misaligned stack pointer. IIUC unaligned loads on MIPS could cause such a
>> bus error.
> 
> I tried with hope ... but failed:
> 
> (sid_mipsel-dchroot)tille@eller:~/clustalo$ gdb --args src/clustalo -i 
> debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
> temp_test.aln --outfmt clustal --force
> GNU gdb (Debian 9.1-3) 9.1
> ...
> Reading symbols from src/clustalo...
> (gdb) run
> Starting program: /home/tille/clustalo/src/clustalo -i 
> debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
> temp_test.aln --outfmt clustal --force
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGBUS, Bus error.
> 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30, 
> pairdist_type=, bPercID=, istart=0, iend=3, 
> jstart=0, jend=3, fdist_in=0x0, 
>fdist_out=0x0) at pair_dist.c:346
> 346 NewProgress(, LogGetFP(, LOG_INFO),

OK, let me try a little harder :)

$ # enable debugging symbols and Address Sanitizer
$ CFLAGS="-g -fsanitize=address" CXXFLAGS="-g -fsanitize=address" 
./configure
…
$ make clean && make
…
$ ./src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
temp_test.dnd -o temp_test.aln --outfmt clustal --force
=
==30264==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 
0x7ffcfcbf5784 at pc 0x5620f0aa478c bp 0x7ffcfcbf56c0 sp 0x7ffcfcbf56b8
WRITE of size 4 at 0x7ffcfcbf5784 thread T0
#0 0x5620f0aa478b in PairDistances 
/home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336
#1 0x5620f0a91d9f in AlignmentOrder 
/home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:835
#2 0x5620f0a95c04 in Align 
/home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:1221
#3 0x5620f0a90d76 in MyMain 
/home/matthew/clustal-omega-1.2.4/src/mymain.c:1192
#4 0x5620f0a88ca2 in main 
/home/matthew/clustal-omega-1.2.4/src/main.cpp:469
#5 0x7f3773d9009a in __libc_start_main ../csu/libc-start.c:308
#6 0x5620f0a89ad9 in _start 
(/home/matthew/clustal-omega-1.2.4/src/clustalo+0x2dad9)

Address 0x7ffcfcbf5784 is located in stack of thread T0
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow 
/home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336 in PairDistances
Shadow bytes around the buggy address:
  0x10001f976aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976ad0: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca
  0x10001f976ae0: 04 cb cb cb cb cb cb cb 00 00 00 00 ca ca ca ca
=>0x10001f976af0:[04]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00
  0x10001f976b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976b10: f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2
  0x10001f976b20: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
  0x10001f976b30: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001f976b40: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==30264==ABORTING

Looking at line 336 of pair_dist.c, it looks like the bound on the containing 
loop is wrong. So let’s try adjusting that:

$ vim src/clustal/pair_dist.c
$ git diff src/clustal/pair_dist.c
diff --git a/src/clustal/pair_dist.c b/src/clustal/pair_dist.c
index e6dbdc3..bb79e61 100644
--- a/src/clustal/pair_dist.c
+++ b/src/clustal/pair_dist.c
@@ -321,7 +321,7 @@ PairDistances(symmatrix_t **distmat, mseq_t *mseq, int 
pairdist_type, bool bPerc

 /* 

Bug#958063: torbrowser-launcher: Fails to build on Ubuntu

[Jeremy Bicha]

Source: torbrowser-launcher
Version: 0.3.2-6

torbrowser-launcher no longer builds on Ubuntu after this commit:

https://salsa.debian.org/pkg-privacy-team/torbrowser-launcher/-/commit/a0aead1

https://launchpad.net/ubuntu/+source/torbrowser-launcher/0.3.2-7
rm -r debian/*/etc/apparmor.d/local
rm: cannot remove 'debian/*/etc/apparmor.d/local': No such file or directory

A simple fix is to change "rm -r" to "rm -rf". That way the command
will still be treated as successful even if that directory doesn't
exist.

It might be worth looking into why that directory doesn't exist on Ubuntu.

Thanks,
Jeremy Bicha

Bug#957485: libusb: ftbfs with GCC-10

[Aurelien Jarno]

clone 957485 -1
reassign -1 gcc-10
retitle -1 gcc-10: bogus array-bounds error when using strncpy on strings 
embedded in a structure
block 957485 by -1
thanks

On 2020-04-17 11:05, Matthias Klose wrote:
> Package: src:libusb
> Version: 2:0.1.12-32
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-10
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
> severity of this report will be raised before the bullseye release,
> so nothing has to be done for the buster release.

[ snip ]

> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g 
> -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c ../usbpp.cpp  -fPIC -DPIC -o .libs/usbpp.o
> In file included from /usr/include/string.h:495,
>  from ../linux.c:11:
> In function ‘strncpy’,
> inlined from ‘usb_os_find_busses’ at ../linux.c:361:5:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: 
> ‘__builtin_strncpy’ offset [275, 4095] from the object at ‘entry’ is out of 
> the bounds of referenced subobject ‘d_name’ with type ‘char[256]’ at offset 
> 19 [-Werror=array-bounds]
>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
> (__dest));
>   |  
> ^~
> In file included from /usr/include/dirent.h:61,
>  from ../linux.c:16:
> ../linux.c: In function ‘usb_os_find_busses’:
> /usr/include/x86_64-linux-gnu/bits/dirent.h:33:10: note: subobject ‘d_name’ 
> declared here
>33 | char d_name[256];  /* We must not include limits.h! */
>   |  ^~

This is a bogus warning, assuming the string is not properly null
terminated. This is not an acceptable assumption, otherwise it would not
even be possible to call strlen() without a warning.

Please see the attached file for a simple reproducer.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
/* Compile with gcc-10 -O2 -c testcase.c -Wall -Wformat -Werror=format-security */

#include 

struct a
{
	int pad;
	char string[512];
};

struct b
{
	int pad;
	char string[256];
};

int f(struct a *d, struct b *s)
{
	int l;

	/* No warning here, so GCC 10 assumes that d->string is properly
	 * null terminated. */
	l = strlen(d->string);

	/* Warning here, GCC 10 assumes that d->string is *not* properly
	 * null terminated */
	strncpy(d->string, s->string, sizeof(d->string));

	return l;
}

Bug#858682: Issue created upstream.

[Isaac Connor]

https://github.com/ZoneMinder/zoneminder/issues/2915https://github.com/ZoneMinder/zoneminder/issues/2915

Bug#956848: ncbi-blast+-legacy: Please provide /usr/bin/blastpgp.pl (including .pl extension)

[Aaron M. Ucko]

Andreas Tille  writes:

> I'm aware that language extensions in Debian are not conform to
> policy.  However, as we discussed in
>
>   https://lists.debian.org/debian-med/2018/06/msg00043.html
>
> only stripping the extension is sometimes hard for rdepends of
> our packages.  In this case the lack of blastpgp.pl requires
> heavy patching of t-coffee which could be avoided if we would
> provide both versions - blastpgp.pl and blastpgp - one of both
> as symlink.

Hi, Andreas.

I'm open to making these changes if necessary, particularly given that
this directive is merely a "should" and that there's a fair bit of
precedent for violating it.  (Also, ncbi-blast+ will need a new upload
anyway to address a formal GCC 10 recognition issue, per #957581.)

However, on the t-coffee side, I'd like to offer some alternatives to
this heavy patching:
- Have debian/rules automatically make this formal change in
  a new override_dh_configure target and revert it in
  override_dh_clean.
- Ship a private directory (say, /usr/share/t-coffee/bin) containing
  symlinks or wrappers with .pl extensions and arrange to add it to PATH
  at launch.
- Better yet, bypass these scripts and run BLAST+ directly; they even
  offer a --print_only flag that helps with such porting.

Thanks for maintaining t-coffee (and so many other packages), and please
let me know if any of these suggestions works for you.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#954730: xterm: two press events sent for single press/release of mouse buttons 6 and 7

[Thomas Dickey]

On Fri, Apr 17, 2020 at 05:34:21PM -0400, Thomas Dickey wrote:
...
> Filtering consecutive duplicate events seems like a suitable workaround.
> I'll do that.

did that, found another problem (my bug this time).

it'll be in #354

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#958061: x2gothinclient: Allow browsers other than firefox-esr to satisfy browser requirement

[Jeremy Bicha]

Source: x2gothinclient
Version: 1.5.0.1-4

Please consider adding an alternate dependency to firefox-esr. I
suggest firefox. That would at least allow your packages to be
installable on Ubuntu.

Thanks,
Jeremy Bicha

Bug#937993: python-packaging: diff for NMU version 20.3-1.2

[Sandro Tosi]

Control: tags 937993 + patch


Dear maintainer,

I've prepared an NMU for python-packaging (versioned as 20.3-1.2). The diff
is attached to this message.

Regards.

diff -Nru python-packaging-20.3/debian/changelog python-packaging-20.3/debian/changelog
--- python-packaging-20.3/debian/changelog	2020-04-13 23:56:51.0 -0400
+++ python-packaging-20.3/debian/changelog	2020-04-17 18:38:33.0 -0400
@@ -1,3 +1,10 @@
+python-packaging (20.3-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937993
+
+ -- Sandro Tosi   Fri, 17 Apr 2020 18:38:33 -0400
+
 python-packaging (20.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-packaging-20.3/debian/control python-packaging-20.3/debian/control
--- python-packaging-20.3/debian/control	2020-04-13 23:56:26.0 -0400
+++ python-packaging-20.3/debian/control	2020-04-17 18:35:48.0 -0400
@@ -4,23 +4,15 @@
 Maintainer: Matthias Klose 
 Build-Depends: debhelper (>= 9),
   dh-python,
-  python-all, python3-all, pypy,
-  python-pretend, python3-pretend, pypy-pretend,
-  python-pyparsing, python3-pyparsing, pypy-pyparsing,
-  python-six, python3-six, pypy-six,
+  python3-all, pypy,
+  python3-pretend, pypy-pretend,
+  python3-pyparsing, pypy-pyparsing,
+  python3-six, pypy-six,
   python3-pytest,
-  python-setuptools, python3-setuptools, pypy-setuptools,
+  python3-setuptools, pypy-setuptools,
 Standards-Version: 4.5.0
 Homepage: https://pypi.python.org/pypi/packaging
 
-Package: python-packaging
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: core utilities for python packages
- These core utilities currently consist of:
-  - Version Handling (PEP 440)
-  - Dependency Specification (PEP 440)
-
 Package: python3-packaging
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru python-packaging-20.3/debian/python-packaging.install python-packaging-20.3/debian/python-packaging.install
--- python-packaging-20.3/debian/python-packaging.install	2015-10-28 09:28:22.0 -0400
+++ python-packaging-20.3/debian/python-packaging.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2.*/dist-packages/packaging*
diff -Nru python-packaging-20.3/debian/rules python-packaging-20.3/debian/rules
--- python-packaging-20.3/debian/rules	2020-04-13 23:56:38.0 -0400
+++ python-packaging-20.3/debian/rules	2020-04-17 18:35:57.0 -0400
@@ -5,7 +5,6 @@
 #export DH_VERBOSE=1
 
 export PYBUILD_DISABLE_pypy=test
-export PYBUILD_DISABLE_python2=test
 
 %:
-	dh $@ --with python2,python3,pypy --buildsystem=pybuild
+	dh $@ --with python3,pypy --buildsystem=pybuild

Bug#956405: [DRE-maint] Bug#956405: ruby-enumerable-statistics: FTBFS on amd64/unstable: find: [..] No such file or directory

[Daniel Leidert]

Am Samstag, den 18.04.2020, 03:13 +0530 schrieb Pirate Praveen:
> On Fri, 10 Apr 2020 19:04:30 +0100 "Chris Lamb" 
> wrote:> ruby-enumerable-statistics fails to build from source in
> unstable/amd64:
> 
> I can build it on an uptodate sid chroot and it built fine on the buildd
> from source (sbuild log attached). Any special settings on your system?

As explained in the IRC channel: If git is available on the system, spec.files
is empty and it will lead to the FTBFS described. The solution is as easy as
patching out the git usage from the .gemspec.

Regards, Daniel


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

Bug#958060: mdadm segfaults when run from cron.daily

[Martin Mares]

Package: mdadm
Version: 4.1-1
Severity: normal
Tags: patch upstream

Dear maintainers,

when mdadm is run from /etc/cron.daily/mdadm on one of my machines, it
deterministically segfaults.

The cron job runs:

mdadm --monitor --scan --oneshot

Surprisingly, when I run the same command from a normal root shell, it
finishes correctly. Strace reveals that the difference is that in the first
case, it is run with cwd set to "/", while in the second case cwd is "/root".
And in "/", I have a directory "big", which is also the name of one of my
arrays :) But why is mdadm looking this up in the current directory?

The culprit is the following piece of code in Monitor.c in function Monitor():

if (mdlist->devname[0] == '/')
st->devname = xstrdup(mdlist->devname);
else {
st->devname = xmalloc(8+strlen(mdlist->devname)+1);
strcpy(strcpy(st->devname, "/dev/md/"),
   mdlist->devname);
}

In my case, the first character of mdlist->devname[0] is not '/', so the
else branch is executed ... which copies "/dev/md" to st->devname and happily
overwrites it with mdlist->devname in a moment. Apparently, the outer strcpy
was meant to be a strcat. (This is fixed by the attached patch.)

However, this solves only one part of the puzzle. Even if mdadm accesses the
wrong name, it should not be a reason for a crash. It crashes on a NULL pointer
dereference in Monitor.c, function check_array():

fd = open(dev, O_RDONLY);
if (fd < 0)
goto disappeared;

if (st->devnm[0] == 0)
strcpy(st->devnm, fd2devnm(fd));

Here, open() succeeds on "big", so we call fd2devnm(fd) in lib.c:

char *fd2devnm(int fd)
{
struct stat stb;

if (fstat(fd, ) == 0)
return stat2devnm();

return NULL;
}

Of course fstat succeeds, so we go here:

char *stat2devnm(struct stat *st)
{
if ((S_IFMT & st->st_mode) != S_IFBLK)
return NULL;

return devid2devnm(st->st_rdev);
}

However "fd" refers to a directory, not to a block device, so we return NULL
to strcpy(). This is a separate bug which would also deserves fixing (at least
by a printing an error message instead of crash), even it is unlikely to be
triggered when the first bug is fixed. (However, it can be triggered for example
by running the command while another instance of mdadm is stopping the array.)

-- Package-specific info:

I believe that the details of arrays are not relevant.

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mdadm depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  lsb-base   10.2019051400
ii  udev   241-7~deb10u3

Versions of packages mdadm recommends:
ii  kmod26-1
ii  postfix [mail-transport-agent]  3.4.8-0+10debu1

Versions of packages mdadm suggests:
pn  dracut-core  

-- debconf information:
  mdadm/start_daemon: true
  mdadm/initrdstart_notinconf: false
  mdadm/initrdstart_msg_errconf:
  mdadm/initrdstart_msg_intro:
  mdadm/initrdstart_msg_errmd:
  mdadm/mail_to: root
* mdadm/initrdstart: all
  mdadm/initrdstart_msg_errexist:
  mdadm/autostart: true
  mdadm/autocheck: true
  mdadm/initrdstart_msg_errblock:
diff -ruN mdadm-4.1.orig/Monitor.c mdadm-4.1/Monitor.c
--- mdadm-4.1.orig/Monitor.c2018-10-01 20:26:06.0 +0200
+++ mdadm-4.1/Monitor.c 2020-04-18 00:08:26.342858997 +0200
@@ -176,7 +176,7 @@
st->devname = xstrdup(mdlist->devname);
else {
st->devname = 
xmalloc(8+strlen(mdlist->devname)+1);
-   strcpy(strcpy(st->devname, "/dev/md/"),
+   strcat(strcpy(st->devname, "/dev/md/"),
   mdlist->devname);
}
st->next = statelist;

Bug#822730: initramfs-tools: Should we migrate to a "interest-noawait" trigger for update-initramfs -u?

[Niels Thykier]

Control: reassign -1 debhelper

On Thu, 19 Jul 2018 02:03:21 +0100 Ben Hutchings 
wrote:
> On Sun, 2018-02-18 at 07:35 +, Niels Thykier wrote:
> > On Sun, 31 Dec 2017 16:29:00 + Niels Thykier  wrote:
> > > Control: block 491027 by -1
> > > 
> > > On Sun, 09 Jul 2017 12:51:00 + Niels Thykier  
> > > wrote:
> > > > On Tue, 26 Apr 2016 22:10:14 +0200 Niels Thykier  
> > > > wrote:
> > > > > Package: initramfs-tools
> > > > > Version: 0.125
> > > > > Severity: wishlist
> > > > > Usertags: declarative-packaging 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > 
> > > > [...]
> > > 
> > > Ping on this?
> > > 
> > 
> > Hi,
> > 
> > I have been pinging this bug for nearly two years (admittedly with quite
> > some time between some of the pings) without any replies.
> > 
> > @Ben: Given you appear to be the one doing the actual uploads (i.e. sign
> > + upload), could I ask you to review the bug and come with your take on
> > this?
> 
> I finally had a look at this while preparing a new version.  Sorry for
> taking so long, but I hope you understand that wishlist bugs asking a
> question are not a high priority.
> 
> The dpkg documentation isn't clear (#904060), but it appears to me that
> if we use "interest-noawait" then an activating package that really
> needs to await will not be able to do so.  If we carry on using
> "interest" (or "interest-await") then the activating package can choose
> whether to await the trigger or not.
> 
> A search for explicit triggers:
> https://codesearch.debian.net/search?q=activate.*update-initramfs
> shows that there are packages that use "activate-await", and I would
> not want to override that without consultation.
> 
> Ben.
> 
> -- 
> Ben Hutchings
> We get into the habit of living before acquiring the habit of thinking.
>  - Albert Camus

Bug#958059: mumble: push-to-talk not working with some media keys

[nfb]

Package: mumble
Version: 1.3.0~git20190125.440b173+dfsg-2
Severity: normal
Tags: upstream

Dear Maintainer,

some multimedia keys are not working when bound to the push-to-talk
shortcut, but some of them do work fine.

For example the ThinkVantage button on a Thinkpad x230 keyboard
generates XF86Launch1 keysym. Output from xev:

KeyPress event, serial 34, synthetic NO, window 0x161,
root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
XLookupString gives 0 bytes: 
XmbLookupString gives 0 bytes: 
XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x161,
root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
XLookupString gives 0 bytes: 
XFilterEvent returns: False

The key is correctly detected and saved (as XF86Launch1) by the
shortcut setting dialog in mumble, but when pushing it, the voice is
not activated.
Also, there should be no interference by the rest of the system, since
this button, but also all other media keys i chose for testing, are
not used by the window manager, nor by any running application.

The same for e.g. XF86Display. Other media keys such as XF86AudioPlay
instead, work as expected, as all other "standard" keys do, afaict.

I already reported on the #mumble irc channel and was told to file a
bug because it probably is, but i decided to open it here so we can
track it in Debian and also because i dont't know if the package in
the stable repo is a bit outdated and the issue has been recently
fixed somehow...

Let me know if you need more details.

Thanks for the support.



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

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

Versions of packages mumble depends on:
ii  libasound2 1.1.8-1
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libavahi-compat-libdnssd1  0.7-4+b1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libgl1 1.1.0-1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libopus0   1.3-1
ii  libprotobuf17  3.6.1.3-2
ii  libpulse0  12.2-4+deb10u1
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus55.11.3+dfsg1-1+deb10u3
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u3
ii  libqt5network5 5.11.3+dfsg1-1+deb10u3
ii  libqt5sql5 5.11.3+dfsg1-1+deb10u3
ii  libqt5sql5-sqlite  5.11.3+dfsg1-1+deb10u3
ii  libqt5svg5 5.11.3-2
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5 5.11.3+dfsg1-1+deb10u3
ii  libsndfile11.0.28-6
ii  libspeechd20.9.0-5
ii  libspeex1  1.2~rc1.2-1+b2
ii  libspeexdsp1   1.2~rc1.2-1+b2
ii  libssl1.1  1.1.1d-0+deb10u2
ii  libstdc++6 8.3.0-6
ii  libx11-6   2:1.6.7-1
ii  libxi6 2:1.7.9-1
ii  lsb-release10.2019051400

mumble recommends no packages.

Versions of packages mumble suggests:
pn  mumble-server  
pn  speech-dispatcher  

-- no debconf information

Bug#958058: flex: Maintainer address bounces

[Thorsten Glaser]

Source: flex
Version: 2.6.4-6.2
Severity: serious
Justification: Policy 3.3

Package: flex
Binary: flex, flex-doc, libfl2, libfl-dev
Version: 2.6.4-6.2
Maintainer: Manoj Srivastava 

vs.

From: Mail Delivery System 
Message-ID: 
Subject: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  sriva...@golden-gryphon.com
retry timeout exceeded

[ Part 2: "Delivery Status" ]

Reporting-MTA: dns; muffat.debian.org

Action: failed
Final-Recipient: rfc822;sriva...@golden-gryphon.com
Status: 5.0.0


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

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

-- no debconf information

Bug#958057: RM: pyvorbis -- ROM; python2-only; dead upstream; low popcon; no rdeps (fretsonfire is RC and not in testing)

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#958056: RFS: scanbd/1.5.1-6 [QA] -- Scanner button daemon

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: scanbd
   Version : 1.5.1-6
   Upstream Author : Wilhelm Meier 
 * URL : http://scanbd.sf.net/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/scanbd
   Section : misc

It builds those binary packages:

  scanbd - Scanner button daemon

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/scanbd/scanbd_1.5.1-6.dsc

Changes since the last upload:

   * QA upload.
   * Update Standards-Version to 4.5.0
   * Fix ftbfs with GCC-10. (Closes: #957779)


-- 
Regards
Sudip

Bug#956955: 0.21.0 causes FTBFS in Vault

[Dmitry Smirnov]

On Friday, 17 April 2020 10:53:05 PM AEST Shengjing Zhu wrote:
> So I checked upstream, the first version that includes the new
> golang-github-hashicorp-go-gcp-common-dev is v1.4.0
> via https://github.com/hashicorp/vault/pull/8371

Thanks for checking. Unfortunately I can not isolate the fix and packaging of 
the latest Vault version is not an option as requires an upgrade of Etcd...


> Given it's fixed in upstream, and vault is only in experimental, can
> we downgrade the severity?

Sure... :(


> The new version of golang-google-api is needed for fixing
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954532

Interesting, thanks.

-- 
All the best,
 Dmitry Smirnov.

---

Without doubt you are not sane.
-- Tage Danielsson


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

Bug#895686: My ancient installation is mis-dated again.

[Chris Lamb]

Hi,

> Is the --force doing something weird?  Where'd that "Installation date:" line 
> come from; it is very different from the not-forced version.

D'oh, of course it is. Blame 2017 lamby for a very silly way of
implementing the force argument. Uploading now...


Best wishes,

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

Bug#954730: xterm: two press events sent for single press/release of mouse buttons 6 and 7

[Thomas Dickey]

On Sun, Mar 22, 2020 at 07:58:39PM -0400, Thomas Dickey wrote:
> On Sun, Mar 22, 2020 at 11:38:00PM +0900, Bill Currie wrote:
> > Package: xterm
> > Version: 353-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > While developing a console based application using ncurses running under
> > an exterm, I noticed I was getting double events for the side-scrolling
> > buttons on my mouse (Elecom Huge: 12 buttons (including side-scrolling
> > on the wheel)). Upon investigation, I found that while X itself is
> > sending a press event followed immediately by a release event for
> > buttons 6 and 7, I found that my program was recieving two press events
> > for each press of either button 6 or 7
> 
> odd - in vttest (see attached log), I'm seeing only one event for each
> press (using the rather clumsy Logitech wheel mouse).
> 
> > \x27[<0;14;24M  <- button 1 pressed
> > \x27[<0;14;24m  <- button 1 preleased
> > \x27[<66;14;24M <- button 6 presssed ONCE
> > \x27[<66;14;24M
> > \x27[<67;14;24M <- button 7 presssed ONCE
> > \x27[<67;14;24M
> > \x27[<65;14;24M <- one click turning scroll one way
> > \x27[<64;14;24M <- one click turning scroll the other way way
> 
> With your program, I can see this - something to investigate...

Actually it's a bug in X (or whatever component is responsible for this).

I can see that in xterm's debug-trace.  Besides the duplicate event,
the serial number isn't being updated properly.

It's also reproducible with st.

None of the other terminal emulators in Debian gave usable results,
which is typical - no need to add to the FAQ :-)

Filtering consecutive duplicate events seems like a suitable workaround.
I'll do that.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#368577: unreproducible

[Paolo Greppi]

Hi,

I set up a small example to try to reproduce this problem:
https://salsa.debian.org/paolog-guest/hello-doxygen/-/commits/368577

Note: I set CALL_GRAPH = YES in Doxyfile.

Call graphs are generated fine for me on buster with doxygen 1.8.13-10
(see attachment).

I'll close this bug unless someone has any objections.

Paolo

Bug#375434: unreproducible

[Paolo Greppi]

Hi, I just tried using the current master from 
https://salsa.debian.org/debian/schroot and doxygen 1.8.13-10 from buster.

This is the log:

doxygen schroot.dox
warning: Tag `XML_SCHEMA' at line 1484 of file `schroot.dox' has become 
obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag `XML_DTD' at line 1490 of file `schroot.dox' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: doxygen no longer ships with the FreeSans font.
You may want to clear or change DOT_FONTNAME.
Otherwise you run the risk that the wrong font is being used for dot generated 
graphs.
Notice: Output directory `schroot' does not exist. I have created it for you.
Searching for include files...
Searching for example files...
Searching for images...
Searching for dot files...
Searching for msc files...
Searching for dia files...
Searching for files to exclude
Searching INPUT for files to process...
Searching for files in directory /tmp/schroot/bin/schroot-base
Searching for files in directory /tmp/schroot/bin/schroot
Searching for files in directory /tmp/schroot/bin/schroot-listmounts
Searching for files in directory /tmp/schroot/bin/schroot-mount
Searching for files in directory /tmp/schroot/bin/dchroot
Searching for files in directory /tmp/schroot/bin/dchroot-dsa
Reading and parsing tag files
Parsing files
Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-main.cc...
Parsing file /tmp/schroot/bin/schroot-base/schroot-base-main.cc...
Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-main.h...
Parsing file /tmp/schroot/bin/schroot-base/schroot-base-main.h...
Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-option-action.cc...
Parsing file /tmp/schroot/bin/schroot-base/schroot-base-option-action.cc...
Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-option-action.h...
Parsing file /tmp/schroot/bin/schroot-base/schroot-base-option-action.h...
Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-options.cc...
Parsing file /tmp/schroot/bin/schroot-base/schroot-base-options.cc...
Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-options.h...
Parsing file /tmp/schroot/bin/schroot-base/schroot-base-options.h...
Preprocessing /tmp/schroot/bin/schroot-base/schroot-base-run.h...
Parsing file /tmp/schroot/bin/schroot-base/schroot-base-run.h...
Preprocessing /tmp/schroot/bin/schroot/schroot-main-base.cc...
Parsing file /tmp/schroot/bin/schroot/schroot-main-base.cc...
Preprocessing /tmp/schroot/bin/schroot/schroot-main-base.h...
Parsing file /tmp/schroot/bin/schroot/schroot-main-base.h...
Preprocessing /tmp/schroot/bin/schroot/schroot-main.cc...
Parsing file /tmp/schroot/bin/schroot/schroot-main.cc...
Preprocessing /tmp/schroot/bin/schroot/schroot-main.h...
Parsing file /tmp/schroot/bin/schroot/schroot-main.h...
Preprocessing /tmp/schroot/bin/schroot/schroot-options-base.cc...
Parsing file /tmp/schroot/bin/schroot/schroot-options-base.cc...
Preprocessing /tmp/schroot/bin/schroot/schroot-options-base.h...
Parsing file /tmp/schroot/bin/schroot/schroot-options-base.h...
Preprocessing /tmp/schroot/bin/schroot/schroot-options.cc...
Parsing file /tmp/schroot/bin/schroot/schroot-options.cc...
Preprocessing /tmp/schroot/bin/schroot/schroot-options.h...
Parsing file /tmp/schroot/bin/schroot/schroot-options.h...
Preprocessing /tmp/schroot/bin/schroot/schroot.cc...
Parsing file /tmp/schroot/bin/schroot/schroot.cc...
Preprocessing /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-main.cc...
Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-main.cc...
Preprocessing /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-main.h...
Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-main.h...
Preprocessing 
/tmp/schroot/bin/schroot-listmounts/schroot-listmounts-options.cc...
Parsing file 
/tmp/schroot/bin/schroot-listmounts/schroot-listmounts-options.cc...
Preprocessing 
/tmp/schroot/bin/schroot-listmounts/schroot-listmounts-options.h...
Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts-options.h...
Preprocessing /tmp/schroot/bin/schroot-listmounts/schroot-listmounts.cc...
Parsing file /tmp/schroot/bin/schroot-listmounts/schroot-listmounts.cc...
Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount-main.cc...
Parsing file /tmp/schroot/bin/schroot-mount/schroot-mount-main.cc...
Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount-main.h...
Parsing file /tmp/schroot/bin/schroot-mount/schroot-mount-main.h...
Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount-options.cc...
Parsing file /tmp/schroot/bin/schroot-mount/schroot-mount-options.cc...
Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount-options.h...
Parsing file /tmp/schroot/bin/schroot-mount/schroot-mount-options.h...
Preprocessing /tmp/schroot/bin/schroot-mount/schroot-mount.cc...
Parsing file 

Bug#958037: linux-image-arm64: Please add CONFIG_CRYPTO_DEV_SUN8I_CE

[Philip Rinn]

Hm,

according to to this commit[1] (which is part of Linux 5.5) it should actually 
be
build as a module per default. But in my /boot/config-5.5.0-1-arm64 I have

CONFIG_CRYPTO_DEV_ALLWINNER=y
# CONFIG_CRYPTO_DEV_SUN4I_SS is not set
# CONFIG_CRYPTO_DEV_SUN8I_CE is not set
# CONFIG_CRYPTO_DEV_SUN8I_SS is not set

Best,
Philip

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2fabf6dd77014f19d45fc71c01f1b073c03df255

Bug#957539: mgp: ftbfs with GCC-10 (flex issue)

[Thorsten Glaser]

tags 957539 + help
thanks

Manoj, I’d like your input on this as this seems to be a flex issue.

Matthias Klose dixit:

>gcc -o mgp -g -O2 -fdebug-prefix-map=/<>=. 
>-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wformat 
>-Wno-unused-variable -Wno-unused-but-set-variable -Wno-pointer-sign 
>-Wno-unused-function -Wno-unused-result -Wl,-z,relro -Wl,-z,now 
>-Wl,--as-needed  mgp.o draw.o parse.o plist.o globals.o x11.o font.o 
>background.o scanner.o grammar.o postscript.o tfont.o embed.o unimap.o 
>mng.o m17n.o strlcpy.o strlcat.o -L./image -lmgpimage -lm  -lpng16 -lz 
>-lXft -lImlib2 -lgif  -lXext -lX11
>/usr/bin/ld: grammar.o:././grammar.y:78: multiple definition of `yylineno'; 
>scanner.o:(.data+0x0): first defined here

This is caused by multiple .c files containing 'int yylineno [= …];'.

The source has:

parse.c:extern int yylineno;
parse.c:yylineno = lineno;
parse.c:yylineno = lineno;
parse.c:yylineno = lineno;
grammar.y:int yylineno;
grammar.y:  fprintf(stderr, "%s:%d: error: ", yyfilename, yylineno);
grammar.y:  fprintf(stderr, "%s:%d: warning: ", yyfilename, yylineno);

The build tree on Debian additionally has:

scanner.c:extern int yylineno;
scanner.c:int yylineno = 1;
scanner.c:return yylineno;
scanner.c:yylineno = _line_number;

“scanner.c” is generated from: flex -t ./scanner.l > scanner.c

Running the same command on BSD does *NOT* add the yylineno definition,
and having both “extern” and an initialiser looks completely off to me,
so I’m loathe to just drop the first of the matched lines from grammar.y
and call it good. That would (probably…) break everywhere else…

Even more surprisingly, scanner.c on Debian looks like this:

329 typedef int yy_state_type;
330
331 extern int yylineno;
332 int yylineno = 1;
333
334 extern char *yytext;

Please do enlighten me about this construct. It seems to come from
flex-2.6.4/src/main.c:

   1668 if (!C_plus_plus && !reentrant) {
   1669 outn ("extern int yylineno;");
   1670 OUT_BEGIN_CODE ();
   1671 outn ("int yylineno = 1;");
   1672 OUT_END_CODE ();
   1673 }

Thanks in advance,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#956820: gccgo does not implement syscall in hurd-i386

[Pirate Praveen]

On 2020, ഏപ്രിൽ 18 12:21:34 AM IST, Svante Signell  
wrote:
>Hi Praveen,
>
>Which packages in Debian GNU/Hurd did you install to build golang-
>github-nsf-termbox-go? I can maybe try out the build to find out where
>it fials.

I just installed its build dependencies like a normal build.

apt build-dep or just looking at Build-Depends in control.

I used sid from debian-ports mirror.

>Thanks!
>
>On Wed, 2020-04-15 at 22:34 +0530, Pirate Praveen wrote:
>> Package: gccgo-9
>> Version: 9.3.0-9
>> Severity: important
>> X-debbugs-cc: debian-h...@lists.debian.org
>> 
>> golang-github-nsf-termbox-go is failing to build with gcc-go
>> (changed 
>> Build-Depends to golang-any and built on hurd-i386 latest sid).
>> 
>> There are many failures like this,
>> 
>> src/github.com/nsf/termbox-go/termbox.go:507:37: error: reference to 
>> undefined identifier ‘syscall.SYS_FCNTL’ 507 | r, _, e := 
>> syscall.Syscall(syscall.SYS_FCNTL, uintptr(fd), uintptr(cmd),
>>  | ^
>> src/github.com/nsf/termbox-go/termbox.go:50:17: error: use of
>> undefined 
>> type ‘syscall_Termios’
>>   50 | orig_tios syscall_Termios
>> 
>> $ go version
>> go version go1.12.2 gccgo (Debian 9.3.0-9) 9.3.0 hurd/386
>> 
>> Discussion with hurd maintainers 
>> https://lists.debian.org/debian-hurd/2020/04/msg00026.html
>> 
>> Full build log attached. I think gccgo needs to implement these
>> syscall 
>> interfaces for hurd.
>> 
>> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#884824: etckeeper: daily autocommit is run even though AVOID_DAILY_AUTOCOMMITS=1

[Timo Sigurdsson]

Hi,

as mentioned in my last email, here is a patch that make etckeepker/daily honor 
the setting AVOID_DAILY_AUTOCOMMITS=1 in the configuration file and doesn't 
fail if the variable is unset. I also went ahead and removed the check from 
cron.daily/etckeeper so it's not performed twice when the cronjob is run. 
Please note, that this patch only applies cleanly if my patch sent for bug 
#883263 is applied first. But technically it's not required as it's just the 
context that is different.

Regards,

Timo>From 36864b49b56b20198ee01f302ebdedd3e15c9d58 Mon Sep 17 00:00:00 2001
From: Timo Sigurdsson 
Date: Fri, 17 Apr 2020 19:23:19 +0200
Subject: [PATCH] Fix Debian etckeeper bug #884824.

---
 cron.daily/etckeeper | 8 +++-
 etckeeper/daily  | 6 ++
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/cron.daily/etckeeper b/cron.daily/etckeeper
index 3266faa..ade2a2a 100755
--- a/cron.daily/etckeeper
+++ b/cron.daily/etckeeper
@@ -5,9 +5,7 @@ if [ -d /run/systemd/system ] && [ -x /bin/systemctl ] && /bin/systemctl -q is-active etckeeper.timer; then
 	exit 0
 fi
 
-if [ -e /etc/etckeeper/daily ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
-	. /etc/etckeeper/etckeeper.conf
-	if [ "$AVOID_DAILY_AUTOCOMMITS" != "1" ]; then
-		/etc/etckeeper/daily
-	fi
+# The etckeeper/daily script checks if daily autocommits are disabled.
+if [ -x /etc/etckeeper/daily ]; then
+	/etc/etckeeper/daily
 fi
diff --git a/etckeeper/daily b/etckeeper/daily
index f98c6ad..276c84e 100755
--- a/etckeeper/daily
+++ b/etckeeper/daily
@@ -2,6 +2,12 @@
 # Script that can be run daily to autocommit /etc changes.
 set -e
 if [ -x /usr/bin/etckeeper ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
+	# check if daily autocommits are disabled (Debian bug #884824)
+	. /etc/etckeeper/etckeeper.conf
+	if [ "$AVOID_DAILY_AUTOCOMMITS" = "1" ]; then
+		exit 0
+	fi
+
 	# avoid autocommit if an install run is in progress
 	lockfile=/var/cache/etckeeper/packagelist.pre-install
 	if [ -e "$lockfile" ] && [ -n "$(find "$lockfile" -mtime +1)" ]; then
-- 
2.20.1

Bug#958055: dom4j: CVE-2020-10683: XML External Entity vulnerability in default SAX parser

[Salvatore Bonaccorso]

Source: dom4j
Version: 2.1.1-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for dom4j.

CVE-2020-10683[0]:
XML External Entity vulnerability in default SAX parser

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-10683
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10683
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1694235
[2] https://github.com/dom4j/dom4j/commit/a822852 (Patch)

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#883263: Please don't start both cron job and systemd.timer

[Timo Sigurdsson]

Hi,

as mentioned in my last email, here is a patch that will cause the 
cron.daily/etckeeper to be skipped if etckeeper.timer is active. I went for the 
approach to actually check whether the timer is active rather than merely 
checking if /run/systemd/system exists which is what other cron.daily scritps 
do when they want to bail out in favor of a timer unit. The reason is simply 
that I wasn't sure whether it's safe to assume that the timer is enabled or if 
a user may have disabled it but expects the cron.daily script to run. But feel 
free to change that to whatever behavior you prefer.

Regards,

Timo


>From 16966e16c7d79148dbe8676b38ff24f050b3 Mon Sep 17 00:00:00 2001
From: Timo Sigurdsson 
Date: Fri, 17 Apr 2020 19:05:33 +0200
Subject: [PATCH] Fix Debian etckeeper bug #883263.

---
 cron.daily/etckeeper | 5 +
 1 file changed, 5 insertions(+)

diff --git a/cron.daily/etckeeper b/cron.daily/etckeeper
index eb74401..3266faa 100755
--- a/cron.daily/etckeeper
+++ b/cron.daily/etckeeper
@@ -1,5 +1,10 @@
 #!/bin/sh
 set -e
+# Don't run on systemd systems with an active etckeeper.timer unit.
+if [ -d /run/systemd/system ] && [ -x /bin/systemctl ] && /bin/systemctl -q is-active etckeeper.timer; then
+	exit 0
+fi
+
 if [ -e /etc/etckeeper/daily ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
 	. /etc/etckeeper/etckeeper.conf
 	if [ "$AVOID_DAILY_AUTOCOMMITS" != "1" ]; then
-- 
2.20.1

Bug#496459: forward upstream ?

[Paolo Greppi]

Hi.

this bug has been sitting idle for a long time.

Do you still have this problem ?

No one else in Debian project considered this issue worth bumping.
Can you please forward it upstream to:
https://github.com/doxygen/doxygen/issues
and tag this one as forwarded upstream ?

Thanks,

Paolo

Bug#514229: more info required

[Paolo Greppi]

Hi


this bug has been sitting idle for a long time.

Do you still have this problem ?

No one else in Debian project considered this issue worth bumping.
Can you please forward it upstream to:
https://github.com/doxygen/doxygen/issues?q=is%3Aissue+buffer+log+is%3Aclosed
and tag this one as forwarded upstream ?

Thanks,

Paolo

Bug#958054: kmail: CVE-2020-11880

[Salvatore Bonaccorso]

Source: kmail
Version: 4:19.08.3-1
Severity: important
Tags: security upstream fixed-upstream

Hi,

The following vulnerability was published for kmail, it was fixed in
v19.12.3 upstream.

CVE-2020-11880[0]:
| An issue was discovered in KDE KMail before 19.12.3. By using the
| proprietary (non-RFC6068) "mailto?attach=..." parameter, a website (or
| other source of mailto links) can make KMail attach local files to a
| composed email message without showing a warning to the user, as
| demonstrated by an attach=.bash_history value.


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-11880
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11880
[1] 
https://cgit.kde.org/kmail.git/commit/?id=2a348eccd352260f192d9b449492071bbf2b34b1

Regards,
Salvatore

Bug#948321: postfix: tls_ca_cert_file not copied to chroot

[Vincent Danjean]

Le 17/04/2020 à 16:58, Scott Kitterman a écrit :
> On Tue, 7 Jan 2020 12:19:48 +0100 Vincent Danjean  wrote:
>>>   I'm not sure what should be done:
>>> - nothing (let the administrator handle the situation as currently)
>>> - add support for tls_ca_cert_file/tls_ca_cert_dir in
>>>   /usr/lib/postfix/configure-instance.sh (as for
>>>   smtp_tls_CApath/smtp_tls_CAfile)
>>>   ok, but you have to handle every situation. And I'm pretty sure that 
> lots
>>>   of other use of ldaps do not need to copy theses files in chroot (because
>>>   ldaps wont be used in chroot process) else this bug would have been fixed
>>>   long before
>>
>>   => this is more difficult: it requires to find all ldap:XXX maps and
>> parse them...
> 
> I don't personally use the LDAP support, so my ability to come up with a 
> solution to the problem and test it is limited.  If you can send me (direct 
> is 
> fine if you don't want it in the bug) a copy of the maps file, I'll see if I 
> can 
> come up with something.

No problem to copy the information in the bug report.

In main.cf, I've:
=
[...]
canonical_maps =
  hash:/etc/postfix/canonical
  ldap:/etc/postfix/canonical-ldap.cf
=

In /etc/postfix/canonical-ldap.cf, I've (with anonymization):
=
debug_level = 1

version = 3
server_host =
ldaps://serv-ad.domain.fr:636
ldaps://serv-ad-rep.domain.fr:636
search_base = cn=Users,dc=domain,dc=fr
query_filter = 
(&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*)(sAMAccountName=%u))
result_attribute = mail

timeout = 10

bind = yes
bind_dn = cn=ldap-connect-user,cn=Users,dc=domain,dc=fr
bind_pw = password

#start_tls = yes
tls_ca_cert_file = /etc/ssl/certs/local-certificate.pem
tls_require_cert = yes

# only do ldap request for local name
domain = machine.domain.fr
=

In my case, I need /etc/ssl/certs/local-certificate.pem to be installed
in the chroot (and recopied when it changes)

But, according to ldap_table(5), you would have to handle
tls_ca_cert_dir, tls_ca_cert_file, tls_cert, and tls_key if used
(and the first is a directory, not a file)

  Regards,
Vincent


> We already manage dynamicmaps.cf via shell in postinst/prerm.  Doing 
> something 
> similar in configure-instance.sh should be possible.

If it is too complex to handle all possible configurations,
a hook in configure-instance.sh to be used by the local admin
would be very convenient.

  Regards,
Vincent

> Scott K
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#958053: buster-pu: package schleuder/3.4.0-2+deb10u3

[Georg Faerber]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear SRMs,

Schleuder in buster is affected by various problems, which I would like
to fix:

  - Unfortunately, the encoding fix introduced in the previous version,
3.4.0-2+deb10u2, had shortcomings if dealing with unencrypted, but
signed UTF-8 mails or mail parts without a charset. The parsing
failed and lead to further errors. This problem was discussed
upstream and with downstreams, providers running Schleuder: the new
approach switches the default external encoding to UTF-8 and tries
to convert all non-UTF-8 mails. In case this fails, the invalid
characters are dropped and a note is added to the mail that this
happened. To aid in encoding detection, a new dependency is added,
ruby-charlock-holmes.

While I admit that this change seems invasive for a Debian stable
update, this approach received extensive testing in production for
the last three weeks, with promising results. It handled all the
former problematic mails in a graceful manner. In fact, up until
now, we weren't able to produce mails which would lead to dropped
invalid characters as described above. Personally, I would be
grateful if this would get accepted, as I believe that's the right
thing to do; it'll lead to more happy users.

For details, see the following upstream commits: [1] [2] [3]

This got fixed in unstable via 3.5.0-1. (Closes: #948982)

  - Let x-add-key handle mails with attached, quoted-printable encoded
keys. Such mails might be produced by Thunderbird. Before, such
mails were not recognized and Schleuder yielded 'no key could be
found'.

This got fixed in unstable via 3.5.1-1. (Closes: #956827)

  - Fix x-attach-listkey with mails created by Thunderbird that include
protected headers. Before, the output was garbled and unusable.

This got fixed in unstable via 3.5.0-1. (Closes: #956964)

The diff is increased as different patches partially target the same
(spec) files. However, most of it comes down to updated timestamps or
fuzz introduced by these new patches in already existing ones. I'll
improve my tooling to reduce the diff size in the future.

Please find the debdiff between schleuder/3.4.0-2+deb10u2 and
schleuder/3.4.0-2+deb10u3 attached.

Thanks for your work!

Cheers,
Georg


[1] 
https://0xacab.org/schleuder/schleuder/-/commit/39ca2227fb6e7da03bf26f4f36ea157ce3b62bed
[2] 
https://0xacab.org/schleuder/schleuder/-/commit/275d778b7f27b6625c17adb2a63df91e856c50be
[3] 
https://0xacab.org/schleuder/schleuder/-/commit/badad300d0784f88d7602dab89e8c9ad166f4e32
diff -Nru schleuder-3.4.0/debian/changelog schleuder-3.4.0/debian/changelog
--- schleuder-3.4.0/debian/changelog	2020-01-27 10:28:36.0 +
+++ schleuder-3.4.0/debian/changelog	2020-04-17 20:17:07.0 +
@@ -1,3 +1,28 @@
+schleuder (3.4.0-2+deb10u3) buster; urgency=medium
+
+  * debian/control:
+- (Build)-Depend on ruby-charlock-holmes to aid in encoding detection.
+  * debian/patches:
+- Improve patch to handle encoding errors introduced in the previous
+  version, 3.4.0-2+deb10u2. The former approach had shortcomings if
+  parsing unencrypted, but signed UTF-8 mails or mail parts without a
+  charset. The parsing failed and lead to further errors.
+  The new approach switches to UTF-8 as the default input, and tries to
+  convert non-UTF-8 mails. In case this fails, the invalid characters are
+  dropped and a note is added to the mail that this happened.
+  To aid in encoding detection, a new dependency is added,
+  ruby-charlock-holmes.
+  (Closes: #948982)
+- Add patch to let x-add-key handle mails with attached, quoted-printable
+  encoded keys. Such mails might be produced by Thunderbird. Before, such
+  mails were not recognized.
+  (Closes: #956827)
+- Add patch to fix x-attach-listkey with mails created by Thunderbird that
+  include protected headers. Before, the output was garbled and unusable.
+  (Closes: #956964)
+
+ -- Georg Faerber   Fri, 17 Apr 2020 20:17:07 +
+
 schleuder (3.4.0-2+deb10u2) buster; urgency=medium
 
   * debian/patches:
diff -Nru schleuder-3.4.0/debian/control schleuder-3.4.0/debian/control
--- schleuder-3.4.0/debian/control	2020-01-27 10:28:36.0 +
+++ schleuder-3.4.0/debian/control	2020-04-17 20:17:07.0 +
@@ -9,6 +9,7 @@
procps,
rake (>= 10.5.0~),
ruby-activerecord (>= 5.2~),
+   ruby-charlock-holmes,
ruby-database-cleaner (>= 1.7.0~),
ruby-factory-bot,
ruby-gpgme (>= 2.0.13~),
@@ -39,6 +40,7 @@
  rake (>= 10.5.0~),
  ruby | ruby-interpreter,
  ruby-activerecord (>= 5.2~),
+ ruby-charlock-holmes,
  ruby-gpgme (>= 2.0.13~),
  ruby-mail (>= 

Bug#958052: src:recon-ng: fails to migrate to testing for too long

[Paul Gevers]

Source: recon-ng
Version: 5.0.1-1
Severity: serious
Control: close -1 5.1.1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:recon-ng in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=recon-ng




signature.asc
Description: OpenPGP digital signature

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

Hi Matthew,

On Fri, Apr 17, 2020 at 08:18:29AM -0700, Matthew Fernandez wrote:
> > Thanks for the patch which I applied to packaging Git.  I assume you
> > want to express that while these fixes are definitely good coding
> > practice the bus error problem is not fixed by it, right?
> 
> Thanks, Andreas. It may fix the bus error, but I don’t have a MIPS machine
> to test on. Some of those logging calls had the potential to leave you with
> a misaligned stack pointer. IIUC unaligned loads on MIPS could cause such a
> bus error.

I tried with hope ... but failed:

(sid_mipsel-dchroot)tille@eller:~/clustalo$ gdb --args src/clustalo -i 
debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
temp_test.aln --outfmt clustal --force
GNU gdb (Debian 9.1-3) 9.1
...
Reading symbols from src/clustalo...
(gdb) run
Starting program: /home/tille/clustalo/src/clustalo -i 
debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
temp_test.aln --outfmt clustal --force
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30, 
pairdist_type=, bPercID=, istart=0, iend=3, 
jstart=0, jend=3, fdist_in=0x0, 
fdist_out=0x0) at pair_dist.c:346
346 NewProgress(, LogGetFP(, LOG_INFO),


Thank you for the fixes anyway

 Andreas.

-- 
http://fam-tille.de

Bug#958043: Acknowledgement (python3-gmpy2: import gmpy2 fails)

[Luke Kenneth Casson Leighton]

unfortunately, because of the way that python3-gmpy2 has been
compiled, attempting to install an older version FORCE removes (or
conflicts with) an existing installation of python 3.8.

therefore if, as many people will have, they are transitioning from
python 3.5 to 3.6, 3.6 to 3.7, 3.7 to 3.8, the way that python3-gmpy2
has been installed will cause serious problems, particularly if there
are other dependencies... which there are:

$ apt-cache rdepends python3-gmpy2
python3-gmpy2
Reverse Depends:
  python-gmpy2-doc
  python-gmpy2-common
  pyecm
  python3-ppl
  python3-mpmath
  python-gmpy2-common
  python3-mpmath
  python-gmpy2-common
  python3-mpmath
  python3-mpmath
  python-gmpy2-doc
  python-gmpy2-common

i'd therefore recommend upgrading the severity of this bugreport.

martin, can i suggest taking a look at this:
http://deb.debian.org/debian/pool/main/n/numpy/numpy_1.17.4-5.debian.tar.xz

and look at the debian/rules file.  it deliberately depends on *both*
python3.7 and python3.7, followed by auto-detecting the versions
installed.  it has heavy dependence on c compilation so should work
absolutely fine



# apt-get install python3-gmpy2=2.1.0~a4-1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-gmpy2 : Depends: python3 (< 3.8) but 3.8.2-3 is to be installed
E: Unable to correct problems, you have held broken packages.


rules
Description: Binary data

Bug#958051: src:homebank: fails to migrate to testing for too long

[Paul Gevers]

Source: homebank
Version: 5.2.2-1
Severity: serious
Control: close -1 5.3.2-1
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:homebank in
its current version in unstable has been trying to migrate for 61 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

Your package is only blocked because the binary package(s) aren't built
on a buildd. Unfortunately the Debian infrastructure doesn't allow
arch:all packages to be properly binNMU'ed. Hence, I will shortly do a
no-changes source-only upload to DELAYED/15, closing this bug. Please
let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=homebank




signature.asc
Description: OpenPGP digital signature

Bug#781636: more info required

[Paolo Greppi]

Hi,

do you still have this problem ?
Can you provide a minimal example to reproduce the problem ?

Maybe something based on this small project:
https://salsa.debian.org/paolog-guest/hello-doxygen

Thanks,

Paolo

Bug#820853: not relevant anymore ?

[Paolo Greppi]

Hi,

currently we depend on qtbase5-dev (>= 5.12.5+dfsg-3):
https://salsa.debian.org/debian/doxygen/-/blob/master/debian/control#L7

This bug report is probably not relevant anymore.

If you agree please close this bug.

Thanks,

Paolo

Bug#958050: hd-idle: -a parameter behaviour not consistent with -t and with the manpage

[Bruno Gravato]

Package: hd-idle
Version: 1.05+ds-2~bpo10+1
Severity: minor

Dear Maintainer,

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

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

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

This is a minor issue and probably coming from upstream, though I didn't
test for that.

hd-idle man page suggests that device names should be refered to without
the leading /dev/ in the name, which holds true for option -t, but not
for -a.

To test if hd-idle would successfuly spindown my disks I first tried to
run it with -t disk/by-id/ata-... which worked, when I added similar
option with -a to /etc/default/hd-idle it did not work, but it does if I
use -a /dev/disk/by-id/ata-...

If I add /dev/ to -t option it complains that device
/dev//dev/disk/by-id/ata-... does not exist.


By the way, I'm also using option -l /var/log/hd-idle.log, but no log is
being written to that file. The file isn't even created.
Some logs appear in /var/log/syslog, but only about the daemon
starting/stopping. There was no error/warning about non-existing devices
with option -a as it happens with -t if the device is invalid.


This is a minor issue, probably upstream, but made me waste some time
trying to figure out why -a in the conf file wasn't working as supposed
(and no clue in the logs regarding that). So I thought I'd report this
in case someone else bumps into the same issue.


Best regards,
Bruno Gravato


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

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt:pt_BR:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hd-idle depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  lsb-base 10.2019051400

hd-idle recommends no packages.

hd-idle suggests no packages.


-- no debconf information

Bug#958049: nagvis: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: nagvis
Version: 1:1.9.18-1
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for nagvis
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# GERMAN TRANSLATION OF THE NAGVIS PO FILE.
# Copyright (C) 2012 Erik Pfannenstein
# This file is distributed under the same license as the nagvis package.
# Erik Pfannenstein , 2012.
#
msgid ""
msgstr ""
"Project-Id-Version: nagvis 1:1.9.18-1\n"
"Report-Msgid-Bugs-To: nag...@packages.debian.org\n"
"POT-Creation-Date: 2020-01-21 20:05+0100\n"
"PO-Revision-Date: 2020-04-17 21:55+0200\n"
"Last-Translator: Erik Pfannenstein \n"
"Language-Team: de \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#: ../nagvis.templates:2001
msgid "shinken"
msgstr "shinken"

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid "Monitoring suite used with NagVis:"
msgstr "Monitoring-Suite zur Verwendung mit NagVis:"

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid ""
"The NagVis package supports Icinga as well as Nagios, using the check-mk-"
"live broker backend."
msgstr ""
"Das NagVis-Paket unterstützt sowohl Icinga als auch Nagios und benutzt das "
"check-mk-live-Vermittlungs-Backend."

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid ""
"If you would like to use NagVis with a different backend or a different "
"monitoring suite, please choose \"other\". You'll have to configure it "
"manually."
msgstr ""
"Wenn Sie NagVis mit einem anderen Backend oder einer anderen Monitoring-"
"Suite verwenden wollen, wählen Sie bitte »Andere«. Sie werden es allerdings "
"per Hand konfigurieren müssen."

#. Type: boolean
#. Description
#: ../nagvis.templates:3001
msgid "Delete NagVis data when purging the package?"
msgstr ""
"NagVis-Daten beim vollständigen Entfernen des Pakets ebenfalls löschen?"

#. Type: boolean
#. Description
#: ../nagvis.templates:3001
msgid ""
"NagVis creates files in /var/{cache,lib}/nagvis and /etc/nagvis (for "
"instance background images and map files), including a small database for "
"authentification. If you don't need any of these files, they can be removed "
"now, or you may want to keep them and clean up by hand later."
msgstr ""
"NagVis erstellt Dateien in /var/{cache,lib}/nagvis und /etc/nagvis "
"(beispielsweise für Hintergründe und Kartendateien), einschließlich einer "
"kleinen Datenbank für die Authentifizierung. Wenn Sie keine dieser Dateien "
"benötigen, können sie jetzt gelöscht werden. Sie können sie auch behalten "
"und später selbst per Hand entfernen."

#~ msgid "other"
#~ msgstr "Andere"

Bug#869998: unreproducible

[Paolo Greppi]

Hi !

I tried to reproduce your report with doxygen 1.8.13-10 on buster, see this 
repo/branch:
https://salsa.debian.org/paolog-guest/hello-doxygen/-/commits/%23869998

But doxygen runs fine.

The generated documentation page for hello.cc is like in the screenshot, the 
two example links point to:
https://www.debian.org/security/#contact
https://www.debian.org/security//#contact

Can we consider this fixed ?

Paolo

Bug#931930: Workaround ? [Re: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin]

[mlnl]

Hi,

> I follow testing, and I have the same problem :
> 
> charpent@zen-book-flip:~/Kernel-SOS/firmware-nonfree-20190717/i915$
> dpkg -l "*firmware*" | grep ii| sed -re "s/[ \t]+/ /g" | cut -d " " -f
> 2 | xargs sudo apt-get install --reinstall -y
> 
> [ Snip... ]
> 
> Traitement des actions différées (« triggers ») pour initramfs-tools
> (0.136) ...
> update-initramfs: Generating /boot/initrd.img-5.5.0-1-amd64
> W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_09.bin
> for module i915

> Does someone has a woraround ? The Debian source package doesn't have
> the right version of the files.

Download latest archive from

and add missing files in /lib/firmware/i915


-- 
mlnl

Bug#403451: Debian bug #403451 - please package the doxygen vim modes

[Paolo Greppi]

Hi,

this bug has been sitting idle for a long time.

Clicking on the links you posted 14 years ago now redirects to vim homepage.

I have found here a repository of vim scripts but there seems to be several
doxygen plugins: https://github.com/vim-scripts?tab=repositories=doxygen

In any case all these have a different source than doxygen itself, so they
would need an ITP bug and a separate package.

If you agree please close this bug.

Thanks,

Paolo

Bug#945055: great CPU temperature increase from 5.2 to 5.5 ... and when using intel_pstate

[Christoph Anton Mitterer]

Control: tags -1 - patch
Control: notfound -1 3.16.81-1
Control: notfound -1 4.19.87-1
Control: notfound -1 5.4-1~exp1
Control: forwarded -1 
https://bugzilla.kernel.org/show_bug.cgi?id=207245


Hey Ben.


On Fri, 2020-04-17 at 18:02 +0100, Ben Hutchings wrote:
> This is now neither "fixed" nor "found" in any 5.5 version.  Please
> update the versions properly.

Took a while till I got the mail that the bug was unarchived so I
didn't update everything immediately.


> This is also tagged "patch" but without a direct link to the
> patch(es)
> that are supposed to fix it.  (Linking to the upstream bug report is
> not specific enough.)

Sorry for the confusion I might have caused. The patch tag and also
found-in-version was based on my guess that the problems I see since
versions > 5.2 were caused by 
https://gitlab.freedesktop.org/drm/intel/issues/614

That bug was a regression introduced by a security fix that prevented
the GPU from entering RC6 sleep states.

perf showed me that I was affected by it, so I assumed the fix (which
was introduced in 5.5rc-something) would solve everything.

It didn't, as my fruther test series, which I've just sent to this
Debian as well, showed.


Even with 5.5 I see a tremendous temperature increase.



Unfortunately I'm by far not an expert enough to really tell where the
problem comes from (I'd say there may be even different problems
involved)... and I'd also need guiding what to actually test, to better
nail it down.


When I saw the problem still occurs with 5.5, I've made another test
series and reported it first at lkml:
https://lore.kernel.org/lkml/ce8097694ddfab616616f8f81521495d99c74416.ca...@scientia.net/T/#u

When I got no response I've updated my older ticket at intel-drm:
https://gitlab.freedesktop.org/drm/intel/-/issues/953


My tests would indicate that there are a number of temperature
problems, in short:

- GPU intensive stuff (like playing videos)
- GPU stuff which shouldn't be intensive at all (e.g. moving around
windows)

but also:
- supposedly non-GPU intensive stuff like Alt-Tab-ing between windows,
scrolling up/down in lists in the GUI)
- stuff which doesn't even do graphics at all (see the unhide-brute and
(SHA)-verify tests I've made.



For the GPU-intensive stuff (specifically that I hit 100°C when I play
any videos) there is:
https://gitlab.freedesktop.org/drm/intel/issues/956
(intel-drm folks had asked me to put it in a separate issue)


For the general stuff (e.g. unhide brute or SHA512 verification running
much hotter), there is:
- the post to lkml
- https://bugzilla.kernel.org/show_bug.cgi?id=207245
- and since intel_pstate being enabled there's also:
  https://bugzilla.kernel.org/show_bug.cgi?id=207247


The different tickets contain also descriptions of symptoms I've see,
e.g. where temperatures go through the roof even when just moving
windows, Alt-Tab-switching between them, scrolling up/down in a window,
and so on.


See especially the plots in the git repo I've provided, which shows how
much higher the temperature is from 5.2 to 5.5 (and for each of them
for intel_pstate  being on or off).



Any help on what to test would be highly appreciated.


I did some preliminary tests with perf record, while then e.g.
scrolling up/down in a GUI window (used the mail list in Evolution)
while the temperatures go up to ~80°C ...
This would have indicated that during that, the number of events as
recorded by perf record, grows by a magnitude.

I haven't had time yet to make more systematic tests.


Thanks,
Chris.

Bug#956146: lintian: check for rules enabling --as-needed

[Andreas Beckmann]

Control: tag -1 - moreinfo

On 09/04/2020 01.01, Chris Lamb wrote:
> Any input on whether a brute grep for "-Wl,--as-needed" in debian/
> rules would be sufficient to catch most instances of these? (Feel free

I think you can just grep for '--as-needed', that will catch 
  -Wl,--as-needed (2579 matches)
  dh_autoreconf.* --as-needed (238 matches)
  -Wl,.*,--as-needed (9 matches)

The only 'legitimate' use of --as-needed seems to be in combination
with --no-as-needed. Therefore you should exclude matches that also
have --no-as-needed on the same (logical) line (but include them if
the matches are on different lines), e.g.
nethack:
LIB_x11 = -lncurses -lXaw -Wl,--as-needed -lXmu -lXext -Wl,--no-as-needed -lXt 
-lXpm -lX11 -Wl,--as-needed -lm -Wl,--no-as-needed
haproxy:
MAKEARGS+= ADDLIB="-Wl,--no-as-needed -lgcc_s -Wl,--as-needed"
grep:
LIBS=-Wl,--no-as-needed -ldl -Wl,--as-needed
graphviz:
CONFIGURE_LIBS= LIBS="-Wl,--no-as-needed -Wl,-lpthread -Wl,--as-needed"
pnetcdf:
LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) -Wl,--no-as-needed -lgfortran 
-Wl,--as-needed
clazy:
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -latomic -Wl,--as-needed

(there are ~26 matches for --no-as-needed, ~2865 for --as-needed
and ~6 for both on one line)


Andreas

Bug#954132: wine build depends on unicode-data (< 13) but 13.0.0-2 is to be installed

[Graham Inggs]

Hi

Looking at the upstream commit from the 5.5 branch [1], the following
seems to be the only part relevant to the 5.0 branch:

--- a/tools/make_unicode
+++ b/tools/make_unicode
@@ -193,7 +193,8 @@
 "Top_And_Bottom_And_Right"  => 0x0c,
 "Overstruck"  => 0x0d,
 "Invisible"  => 0x0e,
-"Bottom_And_Left"  => 0x0f
+"Bottom_And_Left"  => 0x0f,
+"Top_And_Bottom_And_Left"  => 0x10,
 );

 my %nameprep_flags =

and with this change I could build wine 5.0-3 with unicode-data 13.0.0-2.

Regards
Graham


[1] 
https://salsa.debian.org/wine-team/wine/-/commit/b83af7c763b40280650990d4ca6385ad35143b00

Bug#957398: kbd gcc-10 / version.h fixed upstream

[Andreas Henriksson]

Control: tags -1 + fixed-upstream

Hi,

This problem should be fixed upstream in commit 12c4be5d
(which apart from renaming the header file also adds include
guards to avoid including the same code multiple times).

In other words simply updating to >= v2.0.90 should solve
this problem.

Regards,
Andreas Henriksson

Bug#651884: still an issue for you ?

[Paolo Greppi]

Hi,

this bug has been sitting idle for a long time.

doxygen-latex is a pure dependency package.
It installs pretty much nothing, it just pulls in the right dependencies,
among them is doxygen itself, which it makes sure is on par or more recent than
its own version.

So it is similar to python3.7 or python3.8.

Its build dependencies can choose to request a specific version like this:
doxygen-latex (=1.8.15).

Of the 66 packages that mention doxygen-latex in debian/control that I could
find:
https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+doxygen-latex
only avr-libc versions it: doxygen-latex (>=1.8.7).

Currently doxygen builds fine on most archs:
https://buildd.debian.org/status/package.php?p=doxygen
Can you name a case where doxygen-latex has caused trouble recently ?
If not, please close this bug.

Thanks,

Paolo

Bug#945055: great CPU temperature increase from 5.2 to 5.5 ... and when using intel_pstate

[Christoph Anton Mitterer]

Hey.


For several months now, I've been chasing a tremendous heat increase
(CPU/GPU) respectively power usage on my notebook.

It basically started after upgrading from 5.2 to 5.3, at least I
haven't explicitly noted any grave changes from before 5.2 to 5.2.
The issue (actually there might be several) persists until at least 5.4
and 5.5.

Things are so bad, that when just type this mail,... that I can hear
the fan go up considerably (and temps up to 90°C) just by typing the
mail in the mail client (while it goes back to - still insane - 65°C
idle, when not typing... ok idle here(!) is with firefox running).
Similar things when I scroll through a terminal window, Alt-Tab cycle
between windows, and so on.


Testing is a bit difficult for me, as I couldn't come up with an easy
way to reproducibly generate real world load (like this typing, or
scrolling terminal windows), yet I tried to do an extensive test
series, which I think will illustrate some things.


Not really sure what the normal average or idle temps of that CPU are,
but I guess getting at average >80°C by just typing shouldn't be the
case.




1) Previous tests
*
When first searching for the reason of the temperature increase, I've
had opened several tickets:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945055
https://lore.kernel.org/lkml/d05aba2742ae42783788c954e2a380e7fcb10830.ca...@scientia.net/

Finally to find (by coincidence):
https://gitlab.freedesktop.org/drm/intel/issues/614
when reporting:
https://gitlab.freedesktop.org/drm/intel/-/issues/953
myself.

At first I thought #614 would be the bug, but the fix for that went
into 5.5-rc, and in fact, with 5.5.x I do see the GPU entering RC6
sleep states again, yet the temperature of my system is still crazy.




2) Testing Environment
**
(for these new tests here)
- Fujitsu Lifebook U757
- most recent BIOS version (1.25) in the tests below (I've had used an
  older one in previous tests from the links)
- 32GB memory, some Sandisk SSD
- Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
- microcode: sig=0x806e9, pf=0x80, revision=0xca
- Debian sid, all packages (unless some totally unrelated stuff at
  their newest versions in unstable)
- all used kernels are stock kernels from Debian
- I do use full dm-crypt encryption of the system, but that shouldn't
  be a cause for the problems, I guess.
- in my /etc/sysfs.conf I have:
  devices/system/cpu/intel_pstate/no_turbo = 1
  basically since I have that laptop... with turbo enabled I always
got 
  these:
  Apr  5 18:27:07 heisenberg kernel: [ 9884.510420] mce: CPU3: Package
temperature above threshold, cpu clock throttled (total events = 2609)
  Apr  5 18:27:07 heisenberg kernel: [ 9884.510422] mce: CPU1: Package
temperature above threshold, cpu clock throttled (total events = 2609)
  Apr  5 18:27:07 heisenberg kernel: [ 9884.510465] mce: CPU0: Package
temperature above threshold, cpu clock throttled (total events = 2609)
  Apr  5 18:27:07 heisenberg kernel: [ 9884.510467] mce: CPU2: Package
temperature above threshold, cpu clock throttled (total events = 2609)
  Apr  5 18:27:07 heisenberg kernel: [ 9884.511427] mce: CPU3: Package
temperature/speed normal
  Apr  5 18:27:07 heisenberg kernel: [ 9884.511430] mce: CPU0: Package
temperature/speed normal
  Apr  5 18:27:07 heisenberg kernel: [ 9884.511431] mce: CPU1: Package
temperature/speed normal
  Apr  5 18:27:07 heisenberg kernel: [ 9884.511436] mce: CPU2: Package
temperature/speed normal
  => so for the tests with ipntel_pstate not being disabled, turbo mode
 was always disabled




3) How tests were made
**
I've tested with the following combinations:
- kernels 5.2.17 and 5.5.13
- with and without intel_pstate=disable
- with Cinnamon and GNOME Shell in classic mode

For all tests the notebook was placed in the same position and ran with
the same commands for tests, no other major processes (like firefox or
so) were running, just the respective bare desktop environment
(cinnamon or gnome shell classic), cron/anacron were stopped.

I always took temperature measurements with the output from sensors and
CSV output from powertop (which contains all the sleep states and high
energy users).

Temperature and powertop measurements were started at basically the
same time. powertop running for n iterations each 20s.
But since powertop takes a while to start the temperature measurements
are effectively shorter.


a) deep-idle
For these tests I've waited very long (like 5 minutes or more) for the
system to cool down.
Measurements with, e.g.:
export NAME="5.2.17/ipstate-disable/thermald-no/gnome-shell-
classic/deep-idle" ; timeout 80 sh -c "while true; do sleep 1; sensors;
done | grep °C > ${NAME}.temp"
and
export NAME="5.2.17/ipstate-disable/thermald-no/cinnamon/deep-idle" ;
powertop -i 4  --csv=${NAME}.powertop.csv


b) idle
Basically the same as (a), just not waiting so long to cool down.
Effectively I've always produced some load (with the fan and CPU 

Bug#945055: great CPU temperature increase from 5.2 to 5.5 ... and when using intel_pstate

[Christoph Anton Mitterer]

I've made some further very extensive tests in the meantime, but these
were mostly for clearly GPU related stuff, i.e. the problem that the
temperatures go through the roof when playing back any video.
These were reported here:
https://gitlab.freedesktop.org/drm/intel/-/issues/953#note_463451

But I haven't made any plots/conclusions for that new set of tests, yet
(will keep this ticket updated once I've done).



As for the general (I mean even when doing non-graphics intensive stuff
like the unhide-brute or sha512 sum verify tests that I've described
above) extreme temperature increase since >5.2 that I see, ... what I
would try next is whether
mitigations=off changes anything (it didn't for video playback).


Also I found out about the nice features of perf record respectively
perf report.
I've played a bit with that already and the first "results" showed that
when I do anyting (like just typing at the keyboard, quickly moving
up/down in e.g. Evolutions mail list, or just Alt-Tab-ing between
windows, the number of events recorded there increases by
magnitudes(!!).


I'd be thankful for any guide in what to actually test to better nail
down that problem I see.

Thanks!

Bug#957889: u-boot: ftbfs with GCC-10

[Vagrant Cascadian]

Control: fixed 957889 2020.04+dfsg-1

On 2020-04-17, Matthias Klose wrote:
> Package: src:u-boot
> Version: 2020.01+dfsg-2
...
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.

Not exactly sure what you mean by do not close; hopefully marking as
"fixed" in the newer version 2020.04+dfsg-1 from unstable is ok?

I was unable to reproduce the issue building with gcc-10 with the new
u-boot version, and there are some fixes mentioning gcc 10 in the
upstream git log.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#958048: RM: python-gcm-client -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove python-gcm-client. It depends on Python 2, is dead upstream (last 
commit
in 2013), there are no reverse deps and the last (and only) maintainer upload 
was in
2013.

Cheers,
Moritz

Bug#956820: gccgo does not implement syscall in hurd-i386

[Svante Signell]

Hi Praveen,

Which packages in Debian GNU/Hurd did you install to build golang-
github-nsf-termbox-go? I can maybe try out the build to find out where
it fials.

Thanks!

On Wed, 2020-04-15 at 22:34 +0530, Pirate Praveen wrote:
> Package: gccgo-9
> Version: 9.3.0-9
> Severity: important
> X-debbugs-cc: debian-h...@lists.debian.org
> 
> golang-github-nsf-termbox-go is failing to build with gcc-go
> (changed 
> Build-Depends to golang-any and built on hurd-i386 latest sid).
> 
> There are many failures like this,
> 
> src/github.com/nsf/termbox-go/termbox.go:507:37: error: reference to 
> undefined identifier ‘syscall.SYS_FCNTL’ 507 | r, _, e := 
> syscall.Syscall(syscall.SYS_FCNTL, uintptr(fd), uintptr(cmd),
>  | ^
> src/github.com/nsf/termbox-go/termbox.go:50:17: error: use of
> undefined 
> type ‘syscall_Termios’
>   50 | orig_tios syscall_Termios
> 
> $ go version
> go version go1.12.2 gccgo (Debian 9.3.0-9) 9.3.0 hurd/386
> 
> Discussion with hurd maintainers 
> https://lists.debian.org/debian-hurd/2020/04/msg00026.html
> 
> Full build log attached. I think gccgo needs to implement these
> syscall 
> interfaces for hurd.
> 
> 

Bug#958035: libpango1.0-0 transitional package must be provided without tight version

[Simon McVittie]

On Sat, 18 Apr 2020 at 00:10:16 +0800, Drew Parsons wrote:
> The problem arises from some 3rd party sources providing deb packages
> that users might reasonably want to use,
> - google-talkplugin for accessing Google Hangouts on firefox
> - flashplugin-nonfree for managing Adobe flash plugin.
> (admittedly the latter is in Debian contrib, we can fix it ourselves)
> There's also dropbox, not that I'd recommend people to use dropbox but
> sometimes they don't have a choice.

Minecraft is another proprietary package with the same issue: #956520
(which also mentions dropbox).

For context, libpango1.0-0 became transitional in 2013. The maintainers of
these packages have had just over 7 years to update them: even for Debian,
that's 3½ release cycles, and we normally remove transitional packages
after a single release cycle. (#940744 was the bug report pointing out
that this one was overdue for removal.)

google-talkplugin didn't seem to be necessary last time I used Hangouts;
browsers have dropped NPAPI support and Google seem to be increasingly
pushing users towards Chrome/Chromium, so I suspect its days are numbered.

flashplugin-nonfree doesn't seem to have worked correctly since 2017, the
plugin it installs is full of known security vulnerabilities, and, again,
browsers have dropped NPAPI support, so I can't say I feel particularly
guilty about breaking that one.

> The problem is the tight version dependency in libpango1.0-0,
> Depends: libpango-1.0-0 (= 1.42.4-8)

It's certainly part of the problem, and if we bring back libpango1.0-0,
relaxing the lockstep dependencies to be (>=) is a good idea: that will
allow users of the last release that has it (presumably Debian 11 and
Ubuntu 20.04) to keep it installed even after they upgrade to the next
stable release (let's assume Debian 12 and Ubuntu 22.04).

However, users of Debian 12 and Ubuntu 22.04 who did not already have
those third-party packages installed will not be able to install them,
unless they add by-then-obsolete releases to sources.list in order to
exhume an old version of libpango1.0-0. So my concern is that on the
next attempt to remove libpango1.0-0, we'll get bug reports demanding
that we bring it back again for the benefit of proprietary third-party
packages, and so on, forever.

Carrying around historical baggage forever wouldn't be *so* bad, except
for the existence of libpangox...

>  libpangox-1.0-0  (>= 1.44.7-3)

Actually, that version number needs to be 0.0.2.

The more major problem with libpango1.0-0 is that it pulls in the Core
X backend, libpangox-1.0-0, which was historically part of pango1.0
but is now built from a separate source package (hence the much lower
version number). It's unmaintained upstream, no longer exists in Ubuntu's
second-class-citizen i386 architecture (#948462), is currently RC-buggy
because it fails to build from source against pango 1.44, and should
really get removed from Debian at some point soon.

But, libpango1.0-0 historically provided the Core X backend, so not having
a hard dependency on libpangox-1.0-0 is a functional regression... and
the proprietary packages that still depend on libpango1.0-0 might be
sufficiently ancient to be using the Core X backend? (I have no idea,
to be honest.)

One possibility is to bring back the transitional package for one more
release cycle (ugh), give it (>=) rather than (=) dependencies on libraries
from the same source package like you suggested, but downgrade the Depends
on libpangox-1.0-0 to Recommends or Suggests? That's not *strictly* correct,
but maybe close enough?

I'm fairly sure that what Ubuntu have done for now (libpango-1.0-0 Provides
libpango1.0-0) is not correct, because third-party proprietary binaries
might not be using the ancient Core X backend, but they probably *are*
using libpangocairo, libpangoxft or libpangoft2.

smcv

Bug#895686: My ancient installation is mis-dated again.

[Boyd Stephen Smith Jr.]

On Thursday, April 16, 2020 4:43:37 AM CDT Chris Lamb wrote:
> Can you provide the output of:
> 
>   $ ./installation-birthday --verbosity 2

---8<---
bss@monster % installation-birthday --verbosity 2
D: Determining block device for /
D: Failed to get mtime of /var/log/installer
D: Failed to get mtime of /var/log/bootstrap.log
D: Found mtime of /var/lib/vim -> 2007-12-18 03:08:03
D: Preferring 2007-12-18 03:08:03 over None
D: Failed to get mtime of /lost+found
D: Found mtime of /root -> 2019-09-25 02:15:38
D: Found mtime of /etc/machine-id -> 2015-05-03 00:25:39
D: Today's date: 2020-04-17
I: Installation date: 2007-12-18
D: Dates do not match
--->8---

(Looks right!)

> ... as well as explicitly confirming which version you are using.

---8<---
bss@monster % apt-cache policy installation-birthday
installation-birthday:
  Installed: 12
  Candidate: 12
  Version table:
 14 700
700 http://deb.debian.org/debian testing/main amd64 Packages
700 http://deb.debian.org/debian testing/main i386 Packages
500 http://deb.debian.org/debian sid/main amd64 Packages
500 http://deb.debian.org/debian sid/main i386 Packages
 *** 12 900
900 http://deb.debian.org/debian stable/main amd64 Packages
900 http://deb.debian.org/debian stable/main i386 Packages
100 /var/lib/dpkg/status
--->8---

I also thought this might be helpful:
---8<---
bss@monster % installation-birthday --force --verbosity 2
D: Determining block device for /
D: Failed to get mtime of /var/log/installer
D: Failed to get mtime of /var/log/bootstrap.log
D: Found mtime of /var/lib/vim -> 2007-12-18 03:08:03
D: Preferring 2007-12-18 03:08:03 over None
D: Failed to get mtime of /lost+found
D: Found mtime of /root -> 2019-09-25 02:15:38
D: Found mtime of /etc/machine-id -> 2015-05-03 00:25:39
D: Today's date: 2020-04-17
I: Installation date: 2018-04-17
/usr/bin/installation-birthday:92: DeprecationWarning: dist() and 
linux_distribution() functions are deprecated in Python 3.5
  distname=platform.linux_distribution()[0].title(),

  0   0
  |   |
  |___|
   0  |~ ~ ~ ~ ~ ~|   0
   |  |   |   |
___|__|___|___|__
|/\/\/\/\/\/\/\/\/\/\/\/|
0   |   H a p p y   |   0
|   |/\/\/\/\/\/\/\/\/\/\/\/|   |
   _|___|___|___|__
  |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
  |   |
  | B i r t h d a y! ! !  |
  | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
  |___|


Congratulations, your Debian system "monster" was installed
2 year(s) ago today!


Best wishes,

Your local system administrator
--->8---

Is the --force doing something weird?  Where'd that "Installation date:" line 
come from; it is very different from the not-forced version.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Bug#958047: RFS: mercantile/1.0-1 [ITP] -- python3-mercantile - Web mercator XYZ tile utilities

[Joachim Langenbach]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: mercantile
   Version : 1.1.3-1
   Upstream Author : Sean Gillies 
 * URL : https://github.com/mapbox/mercantile
 * License : BSD-3-clause
 * Vcs : None
   Section : utils

It builds those binary packages:

  python3-mercantile - Web mercator XYZ tile utilities

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/m/mercantile/
mercantile_1.1.3-1.dsc

Changes since the last upload:

   * Initial release (Closes: #956911)

Regards,
Joachim

Bug#958046: RFS: connexion/1.0-1 [ITP] -- python3-connexion - API first applications with OpenAPI/Swagger and Flask

[Joachim Langenbach]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: connexion
   Version : 2.6.0-1
   Upstream Author : Zalando SE
 * URL : https://github.com/zalando/connexion
 * License : Apache
 * Vcs : None
   Section : python

It builds those binary packages:

  python3-connexion - API first applications with OpenAPI/Swagger and Flask

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/connexion/connexion_2.6.0-1.dsc

Changes since the last upload:

   * Initial release (Closes: #958042)


This package requires additional packages, which are not yet uploaded to 
debian. But I 
packaged those dependencies already and also uploaded them to 
mentors.debian.net:
- https://mentors.debian.net/package/openapi-spec-validator[1] 
- https://mentors.debian.net/package/swagger-ui-bundle[2] 
- https://mentors.debian.net/package/clickclick[3] 
- https://mentors.debian.net/package/pytest-flake8[4] 

So I'm lokking for a sponsor for those packaging as well. If you like to 
sponsor them too, I 
wold be very glad. Otherwise I place an RFS for those packages to.

Regards,

Joachim


[1] https://mentors.debian.net/package/openapi-spec-validator
[2] https://mentors.debian.net/package/swagger-ui-bundle
[3] https://mentors.debian.net/package/clickclick
[4] https://mentors.debian.net/package/pytest-flake8

Bug#958045: Support trust-ad option from glibc 2.31

[Florian Weimer]

Package: resolvconf
Version: 1.79

glibc 2.31 has support for recognizing that the name servers listed in
/etc/resolv.conf are reached over a trusted network path and implement
DNSSEC correctly (but do not necessarily perform validation):

* The DNS stub resolver will optionally send the AD (authenticated data) bit
  in queries if the trust-ad option is set via the options directive in
  /etc/resolv.conf (or if RES_TRUSTAD is set in _res.options).  In this
  mode, the AD bit, as provided by the name server, is available to
  applications which call res_search and related functions.  In the default
  mode, the AD bit is not set in queries, and it is automatically cleared in
  responses, indicating a lack of DNSSEC validation.  (Therefore, the name
  servers and the network path to them are treated as untrusted.)

If resolvconf is used to set up a local caching resolver on 127.0.0.1
and that solver handles the AD bit properly (merely reflecting it in
the response would be wrong—but actual DNSSEC validation is not
required), then the generated /etc/resolv.conf contents should include:

options trust-ad

I expect that needs some interface (or documented approach) in
resolvconf.

Thoughts?

Bug#957675: perl: ftbfs with GCC-10

[Niko Tyni]

Control: tag -1 fixed-upstream

On Fri, Apr 17, 2020 at 08:50:02PM +0300, Niko Tyni wrote:
> On Fri, Apr 17, 2020 at 06:26:17PM +0300, Niko Tyni wrote:
> > On Fri, Apr 17, 2020 at 11:08:35AM +, Matthias Klose wrote:
> > > Package: src:perl
> > > Version: 5.30.0-9
> > > Severity: normal
> > > Tags: sid bullseye
> > > User: debian-...@lists.debian.org
> > > Usertags: ftbfs-gcc-10
> 
> > > Failed 6 tests out of 2533, 99.76% okay.
> > >   ../cpan/Memoize/t/tie_gdbm.t
> > >   ../cpan/Memoize/t/tie_ndbm.t
> > >   ../ext/GDBM_File/t/gdbm.t
> > >   ../ext/NDBM_File/t/ndbm.t
> > >   ../ext/ODBM_File/t/odbm.t
> > >   ../lib/AnyDBM_File.t

> So the perl Configure script adds -fpcc-struct-return to the compiler
> flags if the GCC version starts with number 1. This changes the ABI,
> causing a segmentation fault when calling external code in libgdbm.

Bah, should have checked upstream first as this was already tracked
down there. Oh well.

Fixed upstream by

 
https://github.com/Perl/metaconfig/commit/96178a6a5c056c9ae44cd81d6d2c5d99311c763a

 https://github.com/Perl/perl5/commit/9f4e6307232229875331a55e44e1245b0b91e219

-- 
Niko

Bug#958044: support not adding trailing dots to commit messages/changelog entries

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.60
Severity: minor

Some packages (e.g. python-apt) do not use trailing dots in commit messages
and changelog entries.

lintian-brush should support not adding trailing dots, and possibly
autodetect when the style of the package is not to use trailing dots.


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

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.2
ii  python3  3.8.2-3
ii  python3-breezy   3.0.2-5+b1
ii  python3-debian   0.1.37
ii  python3-distro-info  0.23
ii  python3-dulwich  0.19.15-1+b1
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5+b1
ii  python3-pkginfo  1.4.2-3
ii  python3-ruamel.yaml  0.15.89-3+b2

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.20-1
ii  libdebhelper-perl  13
ii  lintian2.65.0
ii  python3-asyncpg0.20.1-1+b1
ii  python3-pyinotify  0.9.6-1.3

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  214

-- no debconf information

Bug#956922: ITP: fsverity -- Userspace utilities for fs-verity

[Romain Perier]

Bastien : why not , I am opened to suggestions.

Lucas: thanks for your proposal and your feedbacks. I will fix this and I
will keep you in touch.

Regards,
Romain

Le ven. 17 avr. 2020 à 13:29, Bastien ROUCARIES 
a écrit :

> On Thu, Apr 16, 2020 at 9:18 PM Romain Perier 
> wrote:
> >
> > Package: wnpp
> > Severity: wishlist
> > Owner: Romain Perier 
> >
> > * Package name: fsverity
> >   Version : 1.0
> >   Upstream Author : Eric Biggers 
> > * URL :
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git
> > * License : GPL
> >   Programming Lang: C
> >   Description : Userspace utilities for fs-verity
> >
> > This is fsverity, a userspace utility for fs-verity. fs-verity is a
> Linux kernel
> > feature that does transparent on-demand integrity/authenticity
> verification of
> > the contents of read-only files, using a hidden Merkle tree (hash tree)
> associated
> > with the file. The mechanism is similar to dm-verity, but implemented at
> the file
> > level rather than at the block device level. The fsverity utility allows
> you to
> > set up fs-verity protected files.
> >
> > This package will be helpful for handling the fsverity feature on a file
> from
> > userspace.
> >
> > I want to maintain this package. As DM, I need someone for the initial
> upload.
> > Packaging is currently hosted here
> https://salsa.debian.org/rperier-guest/fsverity,
> > and will be developed at https://salsa.debian.org/debian/fsverity
>
> I can. Do you plan also to support it under debian install (maybe also
> dm-verify/dm-integrity)
>
> Bastien
>

Bug#949361: r-cran-ranger: autopkgtest regression on some architectures

[Andreas Tille]

On Fri, Apr 17, 2020 at 05:26:04PM +0200, Dylan Aïssi wrote:
> > I wonder whether it might make sense to exclude this single test and
> > reduce severity of the bug from serious to important.
> 
> Yes, this is my plan.

Good!  So I just wait. :-)

My main concern is that we are free of RC bugs before the transition
will start.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#957675: perl: ftbfs with GCC-10

[Niko Tyni]

Control: tag -1 upstream

On Fri, Apr 17, 2020 at 06:26:17PM +0300, Niko Tyni wrote:
> On Fri, Apr 17, 2020 at 11:08:35AM +, Matthias Klose wrote:
> > Package: src:perl
> > Version: 5.30.0-9
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-...@lists.debian.org
> > Usertags: ftbfs-gcc-10

> > Failed 6 tests out of 2533, 99.76% okay.
> > ../cpan/Memoize/t/tie_gdbm.t
> > ../cpan/Memoize/t/tie_ndbm.t
> > ../ext/GDBM_File/t/gdbm.t
> > ../ext/NDBM_File/t/ndbm.t
> > ../ext/ODBM_File/t/odbm.t
> > ../lib/AnyDBM_File.t
> 
> I can reproduce this. It happens at both -O2 and -O0, but goes away when
> building with -DDEBUGGING (so our /usr/bin/debugperl).

This is a 26 years old bug.

>From regen-configure/U/compline/ccflags.U :

  ?RCS: Revision 3.0.1.4  1994/05/06  14:28:45  ram
  ?RCS: patch23: -fpcc-struct-return only needed in gcc 1.x (ADO)

  [...]
  case "$gccversion" in
1*) dflt="$dflt -fpcc-struct-return" ;;
esac

So the perl Configure script adds -fpcc-struct-return to the compiler
flags if the GCC version starts with number 1. This changes the ABI,
causing a segmentation fault when calling external code in libgdbm.

Should be easy to fix.
-- 
Niko

Bug#958043: python3-gmpy2: import gmpy2 fails

[lkcl]

Package: python3-gmpy2
Version: 2.1.0~b4-1+b1
Severity: important

(please ignore debian release information below, a rolling release
is used)

python3.7 is being used, here (not python3.8)

however python3-gmpy2 has *only* been compiled for python3.8.
this is severely exclusionary, forces people to hard-upgrade to a
set and specific version of python, and very bad practice.

this bugreport's severity might need to be upgraded.

most "good" python packages compile multiple versions not just
for python2 and python3, they compile for multiple versions *of*
python2 (or, used to) and python3.

this package should cookie-cut such other packages, there are plenty
that do this.


>>> import gmpy2
# /usr/lib/python3/dist-packages/gmpy2/__pycache__/__init__.cpython-37.pyc 
matches /usr/lib/python3/dist-packages/gmpy2/__init__.py
# code object from 
'/usr/lib/python3/dist-packages/gmpy2/__pycache__/__init__.cpython-37.pyc'
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 983, in _find_and_load
  File "", line 967, in _find_and_load_unlocked
  File "", line 677, in _load_unlocked
  File "", line 728, in exec_module
  File "", line 219, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/gmpy2/__init__.py", line 1, in 
from .gmpy2 import *
  File "", line 983, in _find_and_load
  File "", line 965, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'gmpy2.gmpy2'




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

Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python3-gmpy2 depends on:
ii  libc62.29-9
ii  libgmp10 2:6.1.2+dfsg-4
ii  libmpc3  1.1.0-1
ii  libmpfr6 4.0.1-1
ii  python-gmpy2-common  2.1.0~b4-1
ii  python3  3.8.2-2
pn  python3:any  

python3-gmpy2 recommends no packages.

Versions of packages python3-gmpy2 suggests:
pn  python-gmpy2-doc  

-- no debconf information

Bug#956965: RFS: sipxtapi/3.3.0~test18+dfsg.1-1.1 [NMU] -- SIP stack, RTP media framework and codecs

[Sudip Mukherjee]

Thanks Tobi.

On Fri, Apr 17, 2020 at 4:51 PM Tobias Frost  wrote:
>
> Control: tags -1 moreinfo
>
> Hi Sudip,
>
> thanks for the updated package!
>
> Some remarks:
>
> The only thing that really needs fixing is that:
>
> - the version should be 3.3.0~test18+dfsg.1-0.1  (NMUing upstream versions 
> have
> debian revision 0)

sorry, missed this is in developers-reference. :(

>

I think all are done now.

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1-0.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Update to new upstream 3.3.0_test18. (Closes: #956686)
 - Add Files-Excluded to repack source.
 - Add patch to skip building examples.
 - Remove patches applied upstream.
 - Remove lintian overrides not needed.
 - Update Standards-Version to 4.5.0
 - Use debhelper-compat.
 - Update compat level to 12.
 - Update priority to optional.
 - Remove dependency on autotools-dev, dh-autoreconf.
 - Remove copyright information of file removed by update.
 - Fix copyright information for a header file.
 - Use secure copyright format uri.
   * Point Vcs to salsa. (Closes: #956685)
   * Add watch file. (Closes: #956687)


-- 
Regards
Sudip

Bug#956717: ITP: Mystiq -- Powerful FFmpeg GUI front-end based on Qt5 and writed in C++

[Pablo Mestre]

Adding more information about the package:

Package: wnpp
Version: 20.03.23-1; reported 2020-04-14
Severity: wishlist

* Package name: mystiq
Version: 20.03.23
Upstream Author: Maikel Llamaret Heredia 
* URL: https://mystiqapp.com/
* License:  GPL,
Description: Powerful media converter. FFmpeg can read audio and video
files in various
 formats and convert them into other formats. MystiQ features an intuitive
 graphical interface and a rich set of presets to help you convert media
 files within a few clicks. Advanced users can also adjust conversion
 parameters in detail.

--

Currently the packaging process is being carried out in:

https://salsa.debian.org/elMor3no-guest/mystiq

The upstream source code is in:

https://github.com/swl-x/MystiQ


Regards

Pablo

Bug#958042: ITP: connexion -- API first applications with OpenAPI/Swagger and Flask

[Joachim Langenbach]

Package: wnpp
Severity: wishlist
Owner: Joachim Langenbach 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: connexion
  Version : 2.6.0
  Upstream Author : Zalando SE
* URL : https://github.com/zalando/connexion
* License : Apache 2.0
  Programming Lang: Python
  Description : API first applications with OpenAPI/Swagger and Flask


Connexion is a framework that automagically handles HTTP requests based on
`OpenAPI Specification` (formerly known as Swagger Spec) of your API described
in `YAML format`. Connexion allows you to write an OpenAPI specification, then
maps the endpoints to your Python functions; this makes it unique, as many
tools generate the specification based on your Python code. You can describe
your REST API in as much detail as you want; then Connexion guarantees that it
will work as you specified.

Connexion Features:
  - Validates requests and endpoint parameters automatically, based on
your specification
  - Provides a Web Swagger Console UI so that the users of your API can
have live documentation and even call your API's endpoints
through it
  - Handles OAuth 2 token-based authentication
  - Supports API versioning
  - Supports automatic serialization of payloads. If your
specification defines that an endpoint returns JSON, Connexion will
automatically serialize the return value for you and set the right
content type in the HTTP header.

The following packages are needed on top of the ones already listed in debian:
 * python3-connexion
 * python3-clickclick (s. Bug #958030)
 * python3-openapi-spec-validator (s. Bug #958024)
 * python3-pytest-aiohttp (rejected by ftpmasters because of size s. Bug 
#951711 --> will be omitted with patch)
 * python3-swagger-ui-bundle (s. Bug #958026)
 * python3-pytest-flake8 (s. Bug #894786)
I already packaged all of this packages and will upload them one after another.

I think connexion will be very helpful for many developers and webservice 
providers.
Therefore it will be good to have a version of this application in debian. 
Especially
as I developed a webservice using it, which I want to deploy on a debian 
server, without
installing code not from the official repositories.

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE8M5SQByE659VY/pttfswyGF4AoIFAl6Z6jMACgkQtfswyGF4
AoJ2iwv/dDIAkuqsOz5icmhgvTgPRBM+QadqG9sFpkeC8nOiv+1vhBPzQTAh7Q+5
ZA42oaaGhcwleje+Js/QR3RfOOYVCWWefI5lF8UuAwgY5SuGpErPjf8vlbgiMzHE
tIrHuIVUK4dBecO90GEHa66fh/XRA4PAeMzXnL5t3SAzJdD75trcfVYKnAH1H8A6
KSKqm2hgyv2IHBNLuBY7Ffd067FvdApgTkOzc7yv0qnLefL7L1S7F1v9YVvSrrUW
1YbfuJKjqH8lhUC6JqghiCzgl7ynZYnSxSqM8AtvFFiHUpsvcUk6EZMLesOXm/Eh
JxgCq4Pea5aaUT2fHRCuFHPQbgcsS0R7FVNnUDs1DH5A8vKwbLB3dJLI7ExE8VKx
J8nrEG3BnXnr4JocKWI5VMD+kNhtXa/3iMdAwHgk11tkQPX8xx9KB8uXZ6qXV1DS
xxVCdjXm57RzxsEZMy9+LAsD9Z9IKH9CMyAiysO5rEzTz69AJY9spA1PVVPmJ1JU
wjuqdSyb
=VuNI
-END PGP SIGNATURE-

Bug#958039: ITP: golang-github-emersion-go-maildir -- A maildir library for Go

[Suman]

Package: wnpp
Severity: wishlist
Owner: suman 

* Package name: golang-github-emersion-go-maildir
  Version : 0.2.0-1
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/go-maildir
* License : Expat
  Programming Lang: Go
  Description : A maildir library for Go

 go-maildir GoDoc (https://godoc.org/github.com/emersion/go-maildir)
 .
 A Go library for maildir (http://cr.yp.to/proto/maildir.html).

Bug#958041: linux-image-5.5.0-1-amd64: OLED brightness control not working on Lenovo P1G2 and X1 extreme

[Mark Pearson]

Package: src:linux
Version: 5.5.13-2
Severity: normal
Tags: upstream

Dear Maintainer,

Raising bug for tracking issue with OLED brightness control not working on some
Lenovo platforms (and I believe some Dell platforms too)
The patches are upstream here:
https://patchwork.freedesktop.org/series/69914/
https://patchwork.freedesktop.org/series/72991/

and I'm working on a merge request to bring them into Debian:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/231

I was told a bug was preferred so am raising this for tracking.

Let me know if any questions or concerns.
Mark Pearson
mpear...@lenovo.com



-- Package-specific info:
** Version:
Linux version 5.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.5.0-1-amd64 
root=UUID=fa0b3088-7fd9-47a8-9306-8cd2d4c0d3a6 ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20QUZ4QSUS
product_version: ThinkPad P1 Gen 2
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N2OET41W (1.28 )
board_vendor: LENOVO
board_name: 20QUZ4QSUS
board_version: SDK0Q40104 WIN

** Loaded modules:
sd_mod
sg
uas
usb_storage
scsi_mod
fuse
x86_pkg_temp_thermal
intel_powerclamp
coretemp
bnep
kvm_intel
kvm
irqbypass
crct10dif_pclmul
ghash_clmulni_intel
aesni_intel
crypto_simd
cryptd
snd_hda_codec_hdmi
glue_helper
mei_wdt
intel_cstate
intel_rapl_msr
intel_uncore
intel_rapl_perf
efi_pstore
serio_raw
intel_wmi_thunderbolt
wmi_bmof
snd_sof_pci
snd_sof_intel_hda_common
snd_sof_intel_hda
efivars
pcspkr
snd_sof_intel_byt
snd_sof_intel_ipc
snd_sof
iTCO_wdt
snd_sof_xtensa_dsp
iTCO_vendor_support
watchdog
snd_soc_skl
iwlwifi
snd_hda_codec_conexant
snd_soc_hdac_hda
snd_hda_codec_generic
snd_hda_ext_core
snd_soc_sst_ipc
snd_soc_sst_dsp
snd_soc_acpi_intel_match
snd_soc_acpi
snd_soc_core
btusb
nls_ascii
btrtl
snd_compress
btbcm
nls_cp437
btintel
snd_hda_intel
vfat
snd_intel_dspcfg
bluetooth
fat
uvcvideo
cfg80211
videobuf2_vmalloc
tpm_crb
mei_me
videobuf2_memops
videobuf2_v4l2
mei
snd_hda_codec
videobuf2_common
snd_hda_core
videodev
drbg
thinkpad_acpi
snd_hwdep
snd_pcm
nvram
mc
ansi_cprng
processor_thermal_device
snd_timer
tpm_tis
ledtrig_audio
intel_rapl_common
tpm_tis_core
ucsi_acpi
snd
ecdh_generic
ecc
typec_ucsi
tpm
joydev
rfkill
soundcore
intel_soc_dts_iosf
intel_pch_thermal
typec
rng_core
ac
int3403_thermal
int340x_thermal_zone
int3400_thermal
acpi_pad
evdev
acpi_thermal_rel
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
wacom
hid_generic
usbhid
hid
i915
rtsx_pci_sdmmc
mmc_core
i2c_designware_platform
i2c_designware_core
e1000e
i2c_algo_bit
psmouse
crc32_pclmul
drm_kms_helper
crc32c_intel
xhci_pci
ptp
xhci_hcd
pps_core
drm
usbcore
nvme
thunderbolt
nvme_core
rtsx_pci
i2c_i801
intel_lpss_pci
intel_lpss
idma64
usb_common
mfd_core
wmi
battery
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host 
Bridge/DRAM Registers [8086:3ec4] (rev 0d)
Subsystem: Lenovo 8th Gen Core Processor Host Bridge/DRAM Registers 
[17aa:22a8]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor PCIe Controller (x16) [8086:1901] (rev 0d) (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 630 
(Mobile) [8086:3e9b] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Lenovo UHD Graphics 630 (Mobile) [17aa:22a8]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0d)
Subsystem: Lenovo Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor 
Thermal Subsystem [17aa:22a8]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device

Bug#957475: libreoffice: ftbfs with GCC-10

[Rene Engelhard]

# not sure. close if appropriate.
clone 957475 -1
reassign -1 src:boost1.71
notforwarded -1
block 957475 by -1
retitle 957475 boost1.71 needs fixes for gcc 10
thanks

Hi,

On Fri, Apr 17, 2020 at 04:32:33PM +0200, Rene Engelhard wrote:
> This complains about stuff inside a boost header i(which is header-only
> here)...
> 
> And indeed, building with boost 1.71 does NOT give the error. So Debians

But it gives an other :(:
https://www.rene-engelhard.de/~rene/libreoffice/boost-gcc10.log
Also reassigning a clone to boost 1.71.

But thankfully upstream fixed it in master:
17:05 <@sberg> _rene_, see 55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61, or 
alternatively another case where dropping support for -std=c++20/-std=c++2a 
from 
   configure.ac should help
17:05 < IZBot> core - replace boost::bimap in sdext pdfimport - 
https://git.libreoffice.org/core/commit/55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61
17:05 <@thorsten> cloph_away samuel_m timar: no strong take how to fix that on 
the builder, fallback to from-source poco again?
17:06 <@sberg> I'd pondered hiding that -std=c++20/2a behind some 
--with-latest-c++; should probably introduce that
17:05 <@sberg> _rene_, see 55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61, or 
alternatively another case where dropping support for -std=c++20/-std=c++2a 
from 
   configure.ac should help
17:05 < IZBot> core - replace boost::bimap in sdext pdfimport - 
https://git.libreoffice.org/core/commit/55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61
17:05 <@thorsten> cloph_away samuel_m timar: no strong take how to fix that on 
the builder, fallback to from-source poco again?
17:06 <@sberg> I'd pondered hiding that -std=c++20/2a behind some 
--with-latest-c++; should probably introduce that

-> 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61

Will backport.

Regards,

Rene

Bug#958040: galera-3 FTBFS on armel: test failure

[Adrian Bunk]

Source: galera-3
Version: 25.3.29-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=galera-3=armel=25.3.29-2=1587128672=0

...
builder_unit_test(["gcs/src/unit_tests/gcs_tests.passed"], 
["gcs/src/unit_tests/gcs_tests"])
Running suite(s): GCS component message
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): GCS send monitor
100%: Checks: 5, Failures: 0, Errors: 0
Running suite(s): GCS state message
100%: Checks: 5, Failures: 0, Errors: 0
Running suite(s): GCS FIFO functions
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): GCS core protocol
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): GCS defragmenter
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): GCS node context
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): GCS membership changes
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): GCS group context
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): GCS backend interface
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): GCS state transfer FC
100%: Checks: 3, Failures: 0, Errors: 0
Total test failed: 0
g++ -o libgalera_smm.so -Wl,-z,relro -shared 
-Wl,--version-script=/<>/galera-sym.map 
galerautils/src/gu_abort.os galerautils/src/gu_dbug.os 
galerautils/src/gu_fifo.os galerautils/src/gu_lock_step.os 
galerautils/src/gu_log.os galerautils/src/gu_mem.os galerautils/src/gu_mmh3.os 
galerautils/src/gu_spooky.os galerautils/src/gu_crc32c.os 
galerautils/src/gu_rand.os galerautils/src/gu_threads.os 
galerautils/src/gu_hexdump.os galerautils/src/gu_to.os 
galerautils/src/gu_utils.os galerautils/src/gu_uuid.os 
galerautils/src/gu_backtrace.os galerautils/src/gu_limits.os 
galerautils/src/gu_time.os galerautils/src/gu_init.os 
www.evanjones.ca/crc32c.os galerautils/src/gu_vlq.os 
galerautils/src/gu_datetime.os galerautils/src/gu_exception.os 
galerautils/src/gu_serialize.os galerautils/src/gu_logger.os 
galerautils/src/gu_regex.os galerautils/src/gu_string_utils.os 
galerautils/src/gu_uri.os galerautils/src/gu_buffer.os 
galerautils/src/gu_utils++.os galerautils/src/gu_config.os 
galerautils/src/gu_fdesc.os galerautils/src/gu_mmap.os 
galerautils/src/gu_alloc.os galerautils/src/gu_rset.os 
galerautils/src/gu_resolver.os galerautils/src/gu_histogram.os 
galerautils/src/gu_stats.os galerautils/src/gu_asio.os 
galerautils/src/gu_debug_sync.os galerautils/src/gu_thread.os 
galerautils/src/gu_hexdump++.os galerautils/src/gu_uuid++.os 
gcache/src/GCache_seqno.os gcache/src/gcache_params.os 
gcache/src/gcache_page.os gcache/src/gcache_page_store.os 
gcache/src/gcache_rb_store.os gcache/src/gcache_mem_store.os 
gcache/src/GCache_memops.os gcache/src/GCache.os gcomm/src/conf.os 
gcomm/src/defaults.os gcomm/src/datagram.os gcomm/src/evs_consensus.os 
gcomm/src/evs_input_map2.os gcomm/src/evs_message2.os gcomm/src/evs_node.os 
gcomm/src/evs_proto.os gcomm/src/gmcast.os gcomm/src/gmcast_proto.os 
gcomm/src/pc.os gcomm/src/pc_proto.os gcomm/src/protonet.os 
gcomm/src/protostack.os gcomm/src/transport.os gcomm/src/uuid.os 
gcomm/src/view.os gcomm/src/socket.os gcomm/src/asio_tcp.os 
gcomm/src/asio_udp.os gcomm/src/asio_protonet.os gcs/src/gcs_params.os 
gcs/src/gcs_conf.os gcs/src/gcs_fifo_lite.os gcs/src/gcs_msg_type.os 
gcs/src/gcs_comp_msg.os gcs/src/gcs_sm.os gcs/src/gcs_backend.os 
gcs/src/gcs_dummy.os gcs/src/gcs_act_proto.os gcs/src/gcs_defrag.os 
gcs/src/gcs_state_msg.os gcs/src/gcs_node.os gcs/src/gcs_group.os 
gcs/src/gcs_core.os gcs/src/gcs_fc.os gcs/src/gcs.os gcs/src/gcs_gcomm.os 
galera/src/mapped_buffer.os galera/src/write_set.os galera/src/data_set.os 
galera/src/key_set.os galera/src/write_set_ng.os galera/src/trx_handle.os 
galera/src/key_entry_os.os galera/src/wsdb.os galera/src/certification.os 
galera/src/galera_service_thd.os galera/src/wsrep_params.os 
galera/src/replicator_smm_params.os galera/src/gcs_action_source.os 
galera/src/galera_info.os galera/src/replicator.os galera/src/ist.os 
galera/src/gcs_dummy.os galera/src/saved_state.os 
galera/src/libmmgalera++-replicator_smm.os 
galera/src/libmmgalera++-replicator_str.os 
galera/src/libmmgalera++-replicator_smm_stats.os 
galera/src/libmmgalera++-wsrep_provider.os -lpthread -latomic -lrt -lssl 
-lcrypto
Checking dynamic symbols for 'libgalera_smm.so'...
g++ -o gcomm/test/check_gcomm -Wl,-z,relro gcomm/test/check_fair_send_queue.o 
gcomm/test/check_gcomm.o gcomm/test/check_trace.o gcomm/test/check_types.o 
gcomm/test/check_util.o gcomm/test/check_evs2.o gcomm/test/check_pc.o 
gcomm/src/libgcomm.a galerautils/src/libgalerautils++.a 
galerautils/src/libgalerautils.a -lpthread -latomic -lrt -lssl -lcrypto -lcheck 
-lm -lsubunit -lrt
builder_unit_test(["gcomm/test/gcomm_check.passed"], ["gcomm/test/check_gcomm"])
Running suite(s): fair_send_queue
 util
 types
 gcomm::evs
 gcomm::pc
98%: Checks: 87, Failures: 0, Errors: 1
gcomm/test/check_evs2.cpp:1259:E:test_proto_split_merge:test_proto_split_merge:0:
 (after this point) Test timeout expired
scons: *** 

Bug#958038: (no subject)

[xiscu]

Package: python3-keras
Version: 2.3.1+dfsg-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Updating the package

   * What was the outcome of this action?

Setting up python3-keras (2.3.1+dfsg-1) ...
/usr/lib/python3/dist-packages/keras/backend/numpy_backend.py:252: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if training is 1 or training is True:
/usr/lib/python3/dist-packages/keras/backend/tensorflow_backend.py:3201: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if training is 1 or training is True:
/usr/lib/python3/dist-packages/keras/backend/tensorflow_backend.py:3207: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif training is 0 or training is False:
/usr/lib/python3/dist-packages/keras/backend/theano_backend.py:1734: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if training is 1 or training is True:
/usr/lib/python3/dist-packages/keras/backend/theano_backend.py:1740: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif training is 0 or training is False:
/usr/lib/python3/dist-packages/keras/losses.py:683: SyntaxWarning: "is not" 
with a literal. Did you mean "!="?
  if label_smoothing is not 0:
/usr/lib/python3/dist-packages/keras/losses.py:702: SyntaxWarning: "is not" 
with a literal. Did you mean "!="?
  if label_smoothing is not 0:

   * What outcome did you expect instead?
No warnings

Thanks in advance,
xiscu


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

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

Versions of packages python3-keras depends on:
ii  python3  3.8.2-3
ii  python3-h5py 2.10.0-2+b1
ii  python3-keras-applications   1.0.8+ds-1
ii  python3-keras-preprocessing  1.1.0+ds-1
ii  python3-numpy1:1.17.4-5
ii  python3-scipy1.3.3-3+b1
ii  python3-six  1.14.0-2
ii  python3-theano   1.0.4+dfsg-2
ii  python3-yaml 5.3.1-1+b1

python3-keras recommends no packages.

python3-keras suggests no packages.

-- no debconf information

Bug#945055:

[Ben Hutchings]

On Fri, 17 Apr 2020 17:49:35 +0200 Christoph Anton Mitterer 
 wrote:
> unarchive 945055
> reopen 945055
> retitle 945055 great CPU temperature increase from 5.2 to 5.5 ... and when 
> using intel_pstate

This is now neither "fixed" nor "found" in any 5.5 version.  Please
update the versions properly.

This is also tagged "patch" but without a direct link to the patch(es)
that are supposed to fix it.  (Linking to the upstream bug report is
not specific enough.)

Ben.

-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.




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

Bug#958037: linux-image-arm64: Please add CONFIG_CRYPTO_DEV_SUN8I_CE

[Philip Rinn]

Source: linux
Version: 5.5.13-2
Severity: wishlist

Hi,

the Crypto engine for Allwinner sun8i was recently added to the kernel[1].
Could you please enable it?

Adding a "CRYPTO_DEV_SUN8I_CE=m" should do the trick.

Thanks & happy hacking
Philip


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06f751b613296cc34b86fc83fccaf30d646eb8bc



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

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