Bug#919561: Please display Debian CI status for contrib/non-free packages on DDPO

[M. Zhou]

Control: close -1

Hi Samuel,

Yes, it was fixed.

On Sun, 2021-01-03 at 02:16 +0100, Samuel Thibault wrote:
> Hello,
> 
> M. Zhou, le jeu. 17 janv. 2019 08:28:24 +, a ecrit:
> > For example, ci.d.o keeps running autopkgtest for zfs-linux and
> > intel-mkl on Debian testing, but the result is not displayed on my
> > DDPO
> > page[1].
> > 
> > https://ci.debian.net/packages/z/zfs-linux/testing/amd64/
> > https://ci.debian.net/packages/i/intel-mkl/testing/amd64/
> > 
> > [1] https://qa.debian.org/developer.php?login=lumin
> 
> This seems to have been fixed?
> 
> Samuel

Bug#953132: kodi-pvr-vdr-vnsi: 8.1.0 Status: Ok (from source)

[Vasyl Gello]

Hi Georg,

>Just wanted to let you know, because the freeze of bullseye is on the 
>doorstep. Maybe this addon can slip into bullseye.

Yes, we are working together with Mattia to review & upload all packages listed 
under

https://salsa.debian.org/multimedia-team/kodi-media-center

to bullseye before the freeze. Please test as many addons as you can - this 
greatly helps us!

Happy New Year!
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

3 січня 2021 р. 07:08:13 UTC, Georg Gast  написав(-ла):
>Dear Maintainers,
>
>The old plugin from stretch worked up until buster. The system was 
>originally installed with stretch, but he kodi-pvr-vdr-vnsi addon was 
>not upgraded nor purged at the dist upgrades. I hit this issue as i 
>tried to upgrade to bullseye on my VDR. because at buster->bullseye it 
>got purged.
>
>I just built kodi 19 Beta2 [1] and kodi-pvr-vdr-vnsi:8.1.0 [2] from 
>source and tested it on my VDR system.
>It works on bullseye/amd64 from source. I tried to get the package from 
>sid and kodi from bullseye. I could not install the plugin as it depends 
>on kodi-pvr-api=5.10.3. Also because the package in sid is still the old 
>version.
>
>https://tracker.debian.org/pkg/kodi-pvr-vdr-vnsi
>
>Then i tried to check the source on salsa. It has already the merge of 
>8.1.0 upstream in it. I built the package from the salsa source and 
>installed the resulting package on my VDR. It works as expected.
>
>Just wanted to let you know, because the freeze of bullseye is on the 
>doorstep. Maybe this addon can slip into bullseye.
>
>Bye
>
>Georg
>
>[1] https://github.com/xbmc/xbmc (branch master)
>[2] https://github.com/kodi-pvr/pvr.vdr.vnsi (branch Matrix)
>


signature.asc
Description: PGP signature

Bug#953132: kodi-pvr-vdr-vnsi: 8.1.0 Status: Ok (from source)

[Georg Gast]

Dear Maintainers,

The old plugin from stretch worked up until buster. The system was 
originally installed with stretch, but he kodi-pvr-vdr-vnsi addon was 
not upgraded nor purged at the dist upgrades. I hit this issue as i 
tried to upgrade to bullseye on my VDR. because at buster->bullseye it 
got purged.


I just built kodi 19 Beta2 [1] and kodi-pvr-vdr-vnsi:8.1.0 [2] from 
source and tested it on my VDR system.
It works on bullseye/amd64 from source. I tried to get the package from 
sid and kodi from bullseye. I could not install the plugin as it depends 
on kodi-pvr-api=5.10.3. Also because the package in sid is still the old 
version.


https://tracker.debian.org/pkg/kodi-pvr-vdr-vnsi

Then i tried to check the source on salsa. It has already the merge of 
8.1.0 upstream in it. I built the package from the salsa source and 
installed the resulting package on my VDR. It works as expected.


Just wanted to let you know, because the freeze of bullseye is on the 
doorstep. Maybe this addon can slip into bullseye.


Bye

Georg

[1] https://github.com/xbmc/xbmc (branch master)
[2] https://github.com/kodi-pvr/pvr.vdr.vnsi (branch Matrix)

Bug#979113: libpulse-dev: lib .so files in -dev package, cause other programs to fail

[Andreas Metzler]

On 2021-01-02 Federico Grau  wrote:
> Package: libpulse-dev
> Version: 12.2-4+deb10u1
> Severity: normal

> Dear Maintainer,

> * What led up to the situation?
> Other programs were failing, because they were unable to load
> libpulse-simple.so library file with only libpulse0 package installed.
> The xcwcp package is one such example.

> * What exactly did you do (or not do) that was effective (or ineffective)?
> A workaround is to install libpulse-dev in addition to libpulse0.
> However this also installs several additional other packages, and should
> not be required for standard library usage.

> Attached is a patch against current salsa.debian.org git, to alter the
> debian file packaging associating library .so files with the library
> package.
[...]
> diff --git a/debian/libpulse0.install b/debian/libpulse0.install
> index cf55606f..cf3d95ed 100644
> --- a/debian/libpulse0.install
> +++ b/debian/libpulse0.install
> @@ -1,4 +1,6 @@
>  etc/pulse/client.conf
> +usr/lib/*/libpulse.so
[...]

Hello,

that change is in direct opposition to to Debian's way of handling
shared libraries. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

If xcwcp requires the unversioned .so it will need a dependency on the
development package.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#976401: uftp: autopkgtest regression in testing: rm: cannot remove '/tmp/uftp-test-data': Operation not permitted

[Paul Gevers]

Hi Adrian,

On 02-01-2021 13:01, Adrian Bunk wrote:
> On Fri, Dec 04, 2020 at 06:10:11PM +0100, Paul Gevers wrote:
>> Source: uftp
>> Version: 4.10.2-1
>> ...
>> I diffed the installed package between the last successful run on amd64
>> and the first the failed. It's:
>> ...
>> uftp: Finishing at Sun Nov 29 11:29:19 2020
>> + cmp ./uftp-test-data /tmp/uftp-test-data
>> + cleanup
>> + rv=0
>> + rm -f ./uftp-test-data /tmp/uftp-test-data
>> rm: cannot remove '/tmp/uftp-test-data': Operation not permitted
>> autopkgtest [11:29:19]: test basic: ---]
> 
> Have there been any configuration changes to the autopkgtest environment
> of packages running with the isolation-container restriction?

We didn't change anything on the ci.d.n side of things, we run
autopkgtest with default settings.

Because of your question, I quickly checked, but also the autopkgtest
version is the same.

We run our infrastructure on stable (except for s390x), with only a
couple of packages from unstable, including lxc [1, 2]. I am not aware
of recent changes there except Antonios lxc for ppc64el and debci in
unstable/testing, both from mid-December.

Paul

[1]
https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/cookbooks/debci/files/default/debci-pinning
[2] https://people.debian.org/~terceiro/debci/



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979124: pandoc: new upstream version

[Jonas Smedegaard]

Hi Kenshi,

Quoting Kenshi Muto (2021-01-03 06:09:29)
> Package: pandoc
> Version: 2.9.2.1-1+b1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Upstream released pandoc 2.11.3.2. Could you consider to update
> the package?

I would love to upgrade pandoc, but unfortunately it requires doing in 
lockstep with a slew of Haskell libraries.

 - Jonas

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

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

signature.asc
Description: signature

Bug#976678: I actually hit it yesterday -

[shirish शिरीष]

Hi all,

I ran into the same bug/issue yesterday -

Setting up python3 (3.9.1-1) ...
running python rtupdate hooks for python3.9...
/usr/share/dstat/dstat_mysql_keys.py:41: SyntaxWarning: 'str' object
is not callable; perhaps you missed a comma?
  if op.debug > 1: print('%s: exception' (self.filename, e))
/usr/share/dstat/dstat_squid.py:48: SyntaxWarning: 'str' object is not
callable; perhaps you missed a comma?
  if op.debug > 1: print('%s: exception' (self.filename, e))
running python post-rtupdate hooks for python3.9...

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#978953: wsjtx: Does not exit cleanly

[Hilary Snaden]

On 02/01/2021 18:45, Christoph Berg wrote:

Control: tags -1 unreproducible

Re: Hilary Snaden

On using the GUI to quit the program, two processes are left ruuning with high 
CPU load, still reading sound input. These processes remain until killed.


Hi,

I don't think this is a general problem, wsjtx exits normally here.

You didn't include any description of these processes, btw.

Christoph



After both wsjtx windows have disappeared:

$ ps -eo pid,%mem,%cpu,comm | grep wsjtx
3199122  2.5 97.1 wsjtx

%cpu is constantly around 100. Pavu shows a sound thread still reading 
input.


htop lists 15 processes called wsjtx (I only noticed two the first time 
around).


Hilary

Bug#979124: pandoc: new upstream version

[Kenshi Muto]

Package: pandoc
Version: 2.9.2.1-1+b1
Severity: wishlist

Dear Maintainer,

Upstream released pandoc 2.11.3.2. Could you consider to update
the package?

Regards,
--
Kenshi Muto

Bug#979123: Image still presents "Select your location" prompt in Automated install

[Daniel Leidert]

Package: simple-cdd
Version: 0.6.7
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've created a custom Buster image. But in Automated install mode I was always
presented the "Select your location" prompt. I checked some search results bot
nothing did resolve the issue. IMHO it is missing a switch like --language but
to set the country and add "debian-installer/country={country}" to the kernel
command line. I workaround this by defining KERNEL_PARAMS in my conf file like
this:

KERNEL_PARAMS="auto=true language=en country=SE locale=en_US.UTF-8"

(auto=true is not really necessary here). Then the automated installation skips
the prompt.



- -- 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.10.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.31
ii  lsb-release 11.1.0
ii  python3 3.9.1-1
ii  python3-simple-cdd  0.6.7
ii  reprepro5.3.0-1.1
ii  rsync   3.2.3-3
ii  wget1.21-1

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-15+b3

Versions of packages simple-cdd suggests:
ii  qemu-system 1:5.2+dfsg-3
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl/xUy4ACgkQS80FZ8KW
0F0KhhAAxmdHnvLEOnPGy4vJappoSgw7HctIDvEMRXWp0baFAu13EXh+O23mjasJ
n87kZuc8tlLrXSQ3eQkkd8ahzy3Gw7n6knSZL0tGP56RgtymwarkzHZho5AOR82s
2bCOXbZ2ek9160aE9OCW/dGvtH9Q0kMoVyd8NazC4jmEp4HZ7kzcy+iFGzdl4a2J
WzwN8l2cgL27MEvjzIGH3VXZZdhYpGEG8Bn5/ytdO/DtPDsxeAkaRy9v4jvi4K5S
79oBvvab1oRIviIYNxDdfGNIqq5PtRkO/Ktr/kTaO2623oYCGeDMCEHfVQ4jIvez
8tFki2E37g2eN6whC+fCNAo/mnSqk61Pfae7zkhmgwMd1EZBNRSNmu8r5kmcruJt
Lh5gFKonCJcCV8xU5XvJOrRAHylwfwqF5UkGaPHTizUmPA4GUxB5A1lyBKduvrVP
u3TnfOWVtI/ylnq+MKvnGv/2sICf7qzVXeptZAPMpkZrCSahjeJvPG6QvMcqW/17
jQ7NwaI0mjwXzZ7W6TdJGmI8CVO4MapFroDxyUrlKmsmrXkv8opOUbsS9txawTlQ
bE8gY+QwaPQEarIX5jOFP0cnx6E6d9wt8GR1SEqcV8NOxWSKOJPTCL+29B/wMbw0
HSKM/svi5PUzDFMOMS6RdOiZUV4JwGCw1AOKKRc2d3t5MZmc/Kk=
=Tpwo
-END PGP SIGNATURE-

Bug#979122: signing-party: keyart fails if -f argument supplied

[Steven Baltakatei Sandoval]

Package: signing-party
Version: 2.11-1
Severity: normal
X-Debbugs-Cc: baltaka...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

## What led up to the situation?

I wanted to make ASCII art fingerprints from cryptographic digest
hexadecimal strings. I installed `signing-party` since it had `keyart`
from [Aaron Toponce](https://github.com/atoponce/keyart).

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

I ran this command:

baltakatei@mycomputer:~$ keyart -f 1122334455667788

## What was the outcome of this action?

I received the following error message.

Traceback (most recent call last):
  File "/usr/bin/keyart", line 255, in 
print(draw_art(None, None, fpr))

## What outcome did you expect instead?

I expected this to see an ASCII art fingerprint like that produced by
the `keyart` executable at the [upstream
repo](https://github.com/atoponce/keyart).

baltakatei@mycomputer:~$ ./keyart -f 1122334455667788
+---+
|^^...: |
| : .^E...  |
|  : . .|
| . |
|  .|
| S |
|   |
|   |
|   |
|   |
|   |
+---+

## Comment

It looks like the `draw_art` function was modified from atoponce's
version to require 4 arguments instead of 3. The code that acts when
the `-f` option is provided still only provides `draw_art` with 3
arguments.

Steven Baltakatei Sandoval
reboil.com
PGP:0xa0a295abdc3469c9


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

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

Versions of packages signing-party depends on:
ii  gnupg  2.2.20-1
ii  libc6  2.31-6
ii  libclass-methodmaker-perl  2.24-2+b1
ii  libgnupg-interface-perl1.00-2
ii  libmailtools-perl  2.21-1
ii  libmd0 1.0.1-3
ii  libmime-tools-perl 5.509-1
ii  libnet-idn-encode-perl 2.500-1+b2
ii  libterm-readkey-perl   2.38-1+b2
ii  libtext-template-perl  1.59-1
ii  perl   5.32.0-6
ii  python33.9.1-1
ii  qprint 1.1.dfsg.2-2+b1

Versions of packages signing-party recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.94-9+b1
ii  libgd-perl [libgd-gd2-perl]2.73-1+b1
ii  libpaper-utils 1.1.28+b1
ii  whiptail   0.52.21-4+b3

Versions of packages signing-party suggests:
ii  fonts-noto-cjk   1:20190410+repack1-2
ii  fonts-noto-mono  20201109-1
ii  imagemagick  8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.24+dfsg-1+b2
ii  mutt 2.0.2-1
ii  qrencode 4.0.2-2
ii  texlive-font-utils   2020.20201129-2
ii  texlive-latex-extra  2020.20201129-2
ii  texlive-latex-recommended2020.20201203-2
ii  texlive-xetex2020.20201203-2
ii  wipe 0.24-7

- -- no debconf information
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOPlkN8g6yI4ot6lSV9pX2VF+b4YFAl/xUCEACgkQV9pX2VF+
b4ZEfQ//WxpNACf0J5DZ/lVnsP3civMbL4tjkvfi56YoLjSTEimvAURYjWO+3rmh
WDhFWUsBkl5Acb9ZlFvgvyKxvXNfLHur18O+L9lXXLR+h3iCoponrRDIKlucW3t0
yo6C1HfmEFt3KGAWF1OQT6Tv1siDuPT5PkmQo/NDvshhqTPvQKzJWKRK8ObeYISK
9Ch+5uSdying5qnHXDO1Hb661TWo3bo/2BqWeUDT6+15jULcp5XFVwfjNi+AQqga
yQqxTtgrwNmOU9J5sHH1bzdQFhSSDZ8HOtO5ONwacoWzSglPr6ToHdfy2JrTruRi
t4COTtynL/Vwlj+UN3NcHIGYSsTXonMu81j+sc/i7zAL2q1/aNarrWJuat+Rsw37
pbgoMGQ+d+wPIVHx4NM/jlojzQMKRKUY85JdPGnNJLPMFiiUMn8+dJ4h4eWu+dFp
D/NgZcO3rKBz1+oCiBBRwjOPyvX5+udcvPDCcrZjixL+ENui0isjKSQJyrA13wVc
NberO8cnIFXKhwfXbYHU16ElZSNMMfi+qj1P6/TfL6oQnjmCNsFKjy389YiVXaN4
tz032PCgAhahuReNqyjquHifq+Tt/NoufZ/RsYTYrrIyf6HUagGRCeexe+hm62I5
mVDs4EhMO9oLTQmSd72Dpv4olxpErZx2zgkOvvXaF7bJtPqZt3M=
=ppNM
-END PGP SIGNATURE-

Bug#979121: steam depend on none available 32-bit NVIDIA libraries

[Mina Morcose Farage]

Package: steam
Version: 1.0.0.67-3

Dear Maintainer
I am not sure if i should post this here but if i am wrong i hope yu
reassign the but
steam package depends nvidia-driver-libs-i386 which is not available on
debian this package is metapackage for nvidia-driver-libs for 32-bit
enables systems  i don't have nvidia card myself but i think this may be
make issues for users using Nvidia cards so i thought to report it

Mina M farage

Bug#979085: FTBFS on mips64el

[YunQiang Su]

On Sun, 03 Jan 2021 00:08:34 +0800 Shengjing Zhu  wrote:
> Source: sopt
> Version: 3.0.1-11
> Severity: serious
> X-Debbugs-Cc: z...@debian.org
> 
> 
> When binNMU sopt, it FTBFS on mips64el, please check log at
> https://buildd.debian.org/status/fetch.php?pkg=sopt=mips64el=3.0.1-11%2Bb1=1609594267=0
> 
> The following tests FAILED:
>19 - communicator (Bus error)

It seems like a “aligned” problem.
I guess it is due to a problem of spdlog.

Let’s have a debug.

>20 - serial_vs_parallel_padmm (Bus error)
>21 - mpi_wavelets (Bus error)
>22 - mpi_session (Bus error)
> 
> The failed tests seem all related mpi, so I think it's not related to spdlog
> or fmtlib. openmpi bumped its version from 4.0.5 to 4.1.0 on 2020-12-21. I
> guess it's related to this change of openmpi.
> 
> 

Bug#979117: RFS: wand/0.6.5-1 [RC] -- Python interface for ImageMagick library (documentation)

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: wand
   Version : 0.6.5-1
   Upstream Author : E. McConville 
 * URL : https://github.com/emcconville/wand
 * License : Expat, BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/wand
   Section : python

It builds those binary packages:

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

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

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

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

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

Changes since the last upload:

 wand (0.6.5-1) unstable; urgency=medium
 .
   * New upstream version 0.6.5
   * d/source/options: Exclude *.egg-info files
   * d/rules, autopkgtest: Change arguments for pytest regarding
 the '-k' flag Closes: #977100

Regards,
Håvard

Bug#977413:

[Richsrd Manwell]

@

Bug#979116: xfwm4: reliable crash on various window states (BadWindow (invalid Window parameter))

[Peter Gervai]

Package: xfwm4
Version: 4.16.0-1
Severity: normal
Tags: upstream

(xfwm4:24127): Gdk-ERROR **: 22:58:21.636: The program 'xfwm4' received an X 
Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 92823 error_code 3 request_code 20 (core protocol) 
minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap


Probably fixed in https://gitlab.xfce.org/xfce/xfwm4/-/merge_requests/18


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

Kernel: Linux 5.8.6 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages xfwm4 depends on:
ii  libc6 2.31-5
ii  libcairo2 1.16.0-4
ii  libepoxy0 1.5.4-1
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.4-1
ii  libgtk-3-03.24.23-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libstartup-notification0  0.12-6
ii  libwnck-3-0   3.36.0-1
ii  libx11-6  2:1.6.12-1
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfce4ui-2-04.16.0-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.14.3-1
ii  libxfixes31:5.0.3-2
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxres1  2:1.2.0-4

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.50.2+dfsg-1

Versions of packages xfwm4 suggests:
ii  xfce4  4.16

-- no debconf information

Bug#978219: libfm-qt: FTBFS: gioptrs.h:75:26: error: ‘QString::QString(const char*)’ is private within this context

[plugwash]

tags 978219 +fixed-upstream
thanks

The immediate cause of this bug, is the addition of 
-DQT_NO_CAST_FROM_ASCII to the compiler flags.
Doing some grepping, this appears like it was caused by the update of 
lxqt-buildtools, and appears

to be intentional rather than a leak.

Doing some digging in the upstream source, it looks like this was fixed 
upstream in

https://github.com/lxqt/libfm-qt/commit/1baee3ed83b94aaf2f811e76a9fe789dc1695b3d
I have not checked if the fix can be applied to the version currently in 
Debian though.

Bug#919561: Please display Debian CI status for contrib/non-free packages on DDPO

[Samuel Thibault]

Hello,

M. Zhou, le jeu. 17 janv. 2019 08:28:24 +, a ecrit:
> For example, ci.d.o keeps running autopkgtest for zfs-linux and
> intel-mkl on Debian testing, but the result is not displayed on my DDPO
> page[1].
> 
> https://ci.debian.net/packages/z/zfs-linux/testing/amd64/
> https://ci.debian.net/packages/i/intel-mkl/testing/amd64/
> 
> [1] https://qa.debian.org/developer.php?login=lumin

This seems to have been fixed?

Samuel

Bug#979120: qa.debian.org: Salsa CI results oddly up to date?

[Samuel Thibault]

Package: qa.debian.org
Severity: normal

Hello,

The VCS CI tick is super useful, but it seems it's not always correctly up
to date. As of now, on line ccsm of

https://qa.debian.org/developer.php?email=sthibault%40debian.org

there is a "failed" word in the VCS column, while 

https://salsa.debian.org/compiz-team/ccsm/-/pipelines

shows that this has been fixed 3 days ago already.

Samuel

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

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

-- 
Samuel
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)."
(By Matt Welsh)

Bug#190725: README's highly confused and wrong configurations

[Markus Wanner]

Control: tags -1 +pending

Hi,

sorry, I mixed this one up with #341205, should have gone here.  Please 
do not cross post to multiple bugs, thank you.


On 12/30/20 7:24 PM, PICCORO McKAY Lenz wrote:
> bug report #126735 and #341205 : in same topic: default installation 
is not explained (respect the courier documented) and there's no Debian 
document that points the difference.. neither a document of debian way 
and the differences..


..I'd argue that the error message provided is sub-optimal.  First of 
all, it should arguably be a 403 Forbidden HTTP response code and not 
assume it's the admin actually reading this.


Second, pointing to INSTALL is a bit blunt, given it's a whopping 4k 
lines to read.  (Some of) your additions to README.Debian are good. I'll 
adjust the error message to point to that file as well.  And given it's 
the www, actually **link** the appropriate section in the installation 
documentation online.


Regards

Markus

Bug#341205: README's highly confused and wrong configurations

[Markus Wanner]

Control: tags -1 +pending

Hi,

On 12/30/20 7:24 PM, PICCORO McKAY Lenz wrote:
bug report #126735 and #341205 : in same topic: default installation is 
not explained (respect the courier documented) and there's no Debian 
document that points the difference.. neither a document of debian way 
and the differences..


..I'd argue that the error message provided is sub-optimal.  First of 
all, it should arguably be a 403 Forbidden HTTP response code and not 
assume it's the admin actually reading this.


Second, pointing to INSTALL is a bit blunt, given it's a whopping 4k 
lines to read.  (Some of) your additions to README.Debian are good. 
I'll adjust the error message to point to that file as well.  And given 
it's the www, actually **link** the appropriate section in the 
installation documentation online.


Regards

Markus

Bug#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever

[Jonas Smedegaard]

Quoting Pino Toscano (2021-01-03 01:43:04)
> In data domenica 27 dicembre 2020 03:53:01 CET, Jonas Smedegaard ha scritto:
> > Version: 9.53.3~dfsg-6
> > 
> > Quoting Pino Toscano (2020-12-22 10:08:12)
> > > In data lunedì 21 dicembre 2020 18:23:12 CET, Simon McVittie ha scritto:
> > > > > On my side, rebuilding libspectre1 solved this on my system.
> > > > 
> > > > If a simple rebuild with no source changes fixes the symptoms of 
> > > > a bug, that might indicate an unintended ABI break in libgs9, or 
> > > > perhaps a bug in the old libgs9 headers (but fixed in the new 
> > > > headers) in code that gets inlined into libspectre at compile 
> > > > time.
> > > 
> > > Both of them are issues in ghostscript anyway.
> > 
> > This was fixed in Ghostscript since release 9.53.3~dfsg-6 - I just 
> > forgot to mention it in changelog (that will be corrected in next 
> > release).
> 
> Oh nice, I did not notice it. I can confirm that using
> - libgs9 9.53.3~dfsg-6
> - libspectre1 0.2.9-1
> - evince 3.38.0-3
> there are no problems opening PS files in evince.

Thanks for the confirmation!

Happy new (gregorian) year,

 - Jonas

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

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

signature.asc
Description: signature

Bug#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever

[Pino Toscano]

In data domenica 27 dicembre 2020 03:53:01 CET, Jonas Smedegaard ha scritto:
> Version: 9.53.3~dfsg-6
> 
> Quoting Pino Toscano (2020-12-22 10:08:12)
> > In data lunedì 21 dicembre 2020 18:23:12 CET, Simon McVittie ha scritto:
> > > > On my side, rebuilding libspectre1 solved this on my system.
> > > 
> > > If a simple rebuild with no source changes fixes the symptoms of a 
> > > bug, that might indicate an unintended ABI break in libgs9, or 
> > > perhaps a bug in the old libgs9 headers (but fixed in the new 
> > > headers) in code that gets inlined into libspectre at compile time.
> > 
> > Both of them are issues in ghostscript anyway.
> 
> This was fixed in Ghostscript since release 9.53.3~dfsg-6 - I just 
> forgot to mention it in changelog (that will be corrected in next 
> release).

Oh nice, I did not notice it. I can confirm that using
- libgs9 9.53.3~dfsg-6
- libspectre1 0.2.9-1
- evince 3.38.0-3
there are no problems opening PS files in evince.

Thanks!
-- 
Pino Toscano

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

Bug#966405: libopenbabel-dev: CMake files do not reflect installation paths

[Pino Toscano]

Hi Andrius,

In data martedì 28 luglio 2020 07:33:15 CET, mer...@debian.org ha scritto:
> Package: libopenbabel-dev
> Control: forwarded -1 https://github.com/openbabel/openbabel/issues/2264
> Control: block 951674 by -1
> 
> Paths in OpenBabel3Config.cmake do not reflect real installation paths
> in Debian systems, at least OpenBabel3_EXPORTS_FILE, which is set to
> 
> ${OpenBabel3_INSTALL_PREFIX}/lib/cmake/openbabel3/OpenBabel3_EXPORTS.cmake
> 
> while it should be
> 
> /usr/lib//cmake/openbabel3/OpenBabel3_EXPORTS.cmake

I took a bit of time to investigate and hopefully fix this issue. The
results are:
- https://github.com/openbabel/openbabel/pull/2315 for fixing the CMake
  configuration files upstream (they needed a bit of massaging)
- https://salsa.debian.org/debichem-team/openbabel/-/merge_requests/5
  to fix the library directory in Debian builds

-- 
Pino Toscano

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

Bug#966988: uftrace: FTBFS: test failed

[Logan Rosen]

Package: uftrace
Version: 0.9.4-0.2
Followup-For: Bug #966988
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/0001-test-Robustify-mcount_wrap_dlopen-test.patch: Import patch from
upstream Git to fix a failing test.

Thanks for considering the patch.

Logan

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

Kernel: Linux 5.8.0-33-generic (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
uftrace-0.9.4/debian/patches/0001-test-Robustify-mcount_wrap_dlopen-test.patch 
uftrace-0.9.4/debian/patches/0001-test-Robustify-mcount_wrap_dlopen-test.patch
--- 
uftrace-0.9.4/debian/patches/0001-test-Robustify-mcount_wrap_dlopen-test.patch  
1969-12-31 19:00:00.0 -0500
+++ 
uftrace-0.9.4/debian/patches/0001-test-Robustify-mcount_wrap_dlopen-test.patch  
2021-01-02 18:47:36.0 -0500
@@ -0,0 +1,28 @@
+From 6483d9ac46bd6ed65bb4ad7ba5788fbe4533d414 Mon Sep 17 00:00:00 2001
+From: Namhyung Kim 
+Date: Fri, 20 Nov 2020 22:36:03 +0900
+Subject: [PATCH] test: Robustify mcount_wrap_dlopen test
+
+I found that it fails in some environment, which seems to call dlopen
+internally somewhere.  As its purpose is to check whether the hookup
+code is called, we can reset the real_dlopen pointer to NULL and check
+the value after the call.
+
+Signed-off-by: Namhyung Kim 
+---
+ libmcount/wrap.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/libmcount/wrap.c
 b/libmcount/wrap.c
+@@ -535,7 +535,9 @@
+ {
+   void *handle;
+ 
+-  TEST_EQ(real_dlopen, NULL);
++  /* In some environment, dlopen() is called already */
++  if (unlikely(real_dlopen != NULL))
++  real_dlopen = NULL;
+ 
+   handle= dlopen(NULL, RTLD_LAZY);
+ 
diff -Nru uftrace-0.9.4/debian/patches/series 
uftrace-0.9.4/debian/patches/series
--- uftrace-0.9.4/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ uftrace-0.9.4/debian/patches/series 2021-01-02 18:47:36.0 -0500
@@ -0,0 +1 @@
+0001-test-Robustify-mcount_wrap_dlopen-test.patch

Bug#383377: ignore Xresources and window at +0+0

[Adam Sampson]

> In fact, I'd say that xpdf-reader always opens with top-left corner at
> +0+0 and thus completely ignores any window hints from the window
> manager.

This bug seems to have been fixed -- I've tested it with Debian xpdf
3.04-4, upstream xpdf 3.04 and xpopple, and -geometry now sets the
correct WM hint for position. (It does so via Motif, so this might have
been a Lesstif/Motif problem.)

-- 
Adam Sampson  

Bug#979119: debhelper: dh_auto_configure does not fail on perl Makefile.PL "exit 0"

[Jonas Smedegaard]

Package: debhelper
Version: 13.3.1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Newly released package liblmdb-file-perl has an odd build script which
refuses to build on i386 platform: it checks and then calls "exit 0" -
its Makefile.PL contains this:

if($Config{archname} =~ /686/) {
warn "liblmdb isn't supported in your platform, sorry.\n";
exit 0;
}


To my surprise, debhelper does not fail, but silently continues to build
an empty package:
https://buildd.debian.org/status/fetch.php?pkg=liblmdb-file-perl=i386=0.12-3=1609092696=0

Seems to me this is a bug in debhelper - possibly even more severe than
"important".


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/xC/AACgkQLHwxRsGg
ASE2UQ/+MUMHYSKcLstT3pOdq54XkQ7WAx/eM1QFHHEp3+KA8pGWulaPtrw1n53s
ZN3XfzQ5wl7xQqVxq+/M6rhXQ4EqB5oUtlgKiI5iSsIG0l4y0OwOc7hZNXJL4DtC
CtCrjf+Pgtfui99POXk5ePHRZNO3ty7rf/HVkioNK4+CXzmiCQlA0J3w3KGkxqjE
nHklADvyzPDIaKubiV2C7KHpvjmpX2a3Yv+anbXHifyUb3nRiLMu6nT59ojBjcOH
Ap1KFU0Yq4FYO/hG4D6hqFeR6edDbp+Bc+NDYLkiG/LfBeg0xi7qtkoK5zVls2Fi
FnZF0/V/neyP5io86DB9UvJoPSoJV8sVuiNbictDgzcih+4P8mC7Hfon9ZQYrxTf
OWfuDOZkL7swvLgtmH3EEoX2oTuPTTilaPbPKm6BB/lH5RRnjroYmWIPg6bh/9H9
D02eIyUOM8fCffUVYDKuYTOpfSIa9Wv9yBKTOCMMfdn62vyV8iBU6APLfTCpKNtI
g13LaZlJWQuoJIeuR9mKqG/h1dINaUvHtiVKgVboO2EkbHzYl+pUtWu49pn3dlZ2
4rhzlbRQNXCmt3UWXefArRavqZoEhfIX+TBVSTWZSSaKUck2+ltRKeVuQbsnIyh0
lUDCHZM87JKx0yV7CCQhFkwNRck4U1vA/CvVqtpjxIl+ErrRu5s=
=TYXH
-END PGP SIGNATURE-

Bug#979118: python3-sgp4: Please update sgp4 to its latest release

[Josue Ortega]

Package: python3-sgp4
Version: 1.4-1.1
Severity: wishlist

Dear Maintainer,

Please update sgp4 to its latest upstream release (2.14)

This version is needed for packaging the latest release of orbit-predictor. 

Cheers,

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

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

Versions of packages python3-sgp4 depends on:
ii  python3  3.9.1-1

python3-sgp4 recommends no packages.

python3-sgp4 suggests no packages.

-- no debconf information

Bug#977413:

[Richsrd Manwell]

@

On Sun, Dec 27, 2020, 8:13 PM Richsrd Manwell 
wrote:

> Updates & upgrades.
>

Bug#930773: dialog: args provided using --file behave differently when provided directly in CLI

[Santiago Vila]

Version: 1.3-20190211-1

[ Sorry for the late reply ]

On Fri, Mar 20, 2020 at 05:40:54PM -0400, Thomas Dickey wrote:
> On Thu, Jun 20, 2019 at 01:02:03PM +0300, Alex Tsitsimpis wrote:
> > Package: dialog
> > Version: 1.3-20160828-2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > There are cases where providing arguments to dialog using `--file'
> > results in failure but providing them directly in CLI works. It seems to
> > me that there is a string escaping problem.
> > 
> > I bumped into this because I use python-dialog, which invokes dialog
> > with arguments passed using the `--file' argument. I started seeing 
> > backslashes
> > in titles when colorizing them, and even in some cases dialog failed to
> > display widgets.
> > 
> > The easiest way to reproduce it is the following:
> > 
> > 1) Invoke dialog passing args to CLI:
> > $ dialog "--msgbox" "\"test\"" "0" "0"
> > * A message box is displayed with the string `"test"` in it. *
> > 
> > 2) Invoke dialog using the --file argument:
> > $ cat args
> > "--msgbox" "\"test\"" "0" "0"
> > $ dialog --file args
> > Error: Expected at least 3 tokens for --msgbox, have 1.
> > Use --help to list options.
> 
> This is probably due to
>  
> 2018/06/21
>   + modify dlg_string_to_argv() to change the quoting behavior to be
> more consistent with shell behavior (patch by Denilson Sa Maia).
> 
> > It seems that version `1.3-20190211-1' from Buster works as expected in
> > this matter, so perhaps it should be backported to Stretch.
> 
> Santiago's free to disagree, but reading the guidelines for bug severity
> and backports, it seems that the level of effort for a backport makes it
> unlikely to do except for really urgent bugs:
> 
> https://www.debian.org/Bugs/Developer#severities
> 
> https://backports.debian.org/Contribute/
> 
> (and the bug reporting guidelines don't seem to be geared toward requesting
> a backport...).

I have the same feeling, this issue was not important enough to make a backport.

However, this is not the same as saying that a backport would have
been unthinkable. It would have been just a matter of finding somebody
willing to make the backport, which could be any Debian maintainer,
not necessarily me.

(I hope that you found a way to workaround this bug, either by making
a backport for private use, or by just upgrading to Debian 10).

Thanks a lot.

Bug#957045: bird: ftbfs with GCC-10

[Benjamin Drung]

Hi,

thanks. I pushed the changes to both repositories. We use bird in our
company. So from that perspective I care about having it working in
Debian, but I already maintain too many package to add myself as co-
maintainer. But I can contribute from now and then.

Cheers,
Benjamin

Am Samstag, den 02.01.2021, 19:50 +0100 schrieb Ondřej Surý:
> Benjamin,
> 
> I pushed both repos, please push your changes directly. Also feel free
> to add yourself to co-maintainers if you use bird and care about it.
> Thanks for the NMU
> 
> Ondrej
> --
> Ondřej Surý  (He/Him)
> 
> > On 2. 1. 2021, at 18:09, Benjamin Drung  wrote:
> > 
> > Hi Ondřej,
> > 
> > > On Fri, 17 Apr 2020 10:57:13 + Matthias Klose
> > >  wrote:
> > > Package: src:bird
> > > Version: 1.6.8-1
> > > 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.
> > > 
> > > The full build log can be found at:
> > > http://people.debian.org/~doko/logs/gcc10-20200225/bird_1.6.8-1_unstable_gcc10.log
> > > The last lines of the build log are at the end of this report.
> > 
> > In consideration of the nearing freeze and the fix being applied
> > upstream, I took the opportunity to prepare a NMU and upload it
> > without
> > delay. I also couldn't resist to address the lintian warning about
> > upstart. The debdiff is attached.
> > 
> > Since https://salsa.debian.org/debian/bird lacks the commits for the
> > last upload (1.6.8-2) I did not commit my changes to the repository,
> > but
> > attach them as patches to this mail. Then you can apply them with
> > "git am" once you pushed the changes for 1.6.8-2.
> > 
> > -- 
> > Benjamin Drung
> > Debian & Ubuntu Developer
> > 
> > <0001-Unix-fix-compilation-with-GCC-10.patch>
> > <0002-Remove-obsolete-upstart-files.patch>
> > <0003-Release-bird-1.6.8-2.1.patch>

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#978984: media-types: /etc/mime.types reported as oldconfig

[Charles Plessy]

Control: reassign -1 mime-support

Le Sat, Jan 02, 2021 at 12:17:58PM +0200, Martin-Éric Racine a écrit :
> 
> $ dpkg-query -W -f='${Conffiles}\n'  mime-support
>  /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35 obsolete
>  /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
> $ dpkg-query -W -f='${Conffiles}\n' media-types
>  /etc/mime.types 43fa90aa9a5e009997f451be169ac530
> $ dpkg-query -W -f='${Conffiles}\n'  mailcap
>  /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e

Hi Martin,

thanks for the checks,

the above commands show that the obsolete conffiles belong to
mime-support, not to media-types as you reported initially.

I am checking on debian-mentors if the fact that mime-support still
declares obsolete conffiles is a bug or not, and will update the package
or close the bug accordingly.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#976235: enlightenment: e switches off screen|monitor

[enno]

> "Ross" == Ross Vandegrift  writes:
>> BTW what do you mean by backlight keys?
>
> Most laptops have some keys for adjusting the brightness of the
> screen backlight.  Try pressing the key to increase the
> brightness.

OK, I would have thought so, just asked to be sure.  No, the `backlight keys' 
don't make any difference at all.

> [...]
>
> You could also try shining a fairly bright light on the screen.
> If everything is running with the backlight off, you might be
> able to see some screen elements.  At least on my laptop, I'm
> barely able to make things out if I shine my phone's light on
> it.

Well I couldn't make anything show up with my really strong LED headlight (BTW 
I'm a surgeon).

BUT...

I'm still or evermore puzzled.  I just tried .e again, and after waiting about 
20 seconds the black screen switches to life and shows an e screen with the 
usual icons root home and thingummyjig as well as the whatsitcalled e-Bar on 
the bottom of the window--with a clock and several click launch icons.  Soon as 
I click mouse or type a key--screen turns black again.  VT1-6 black, after 
waiting about 20 seconds the black screen switches to life and thereis gpm and 
keyboard working perfectly normal--I switch back to VT7, see e for a 
second--then screen turns black.

I did a few updates on suspected potentially involved packages and the like:
[INSTALL] xorg-docs:i386 1:1.7.1-1.2
[INSTALL] xserver-xorg-input-evdev:i386 1:2.10.6-2
[REMOVE (PURGE)] xserver-xorg-input-all:i386 1:7.7+19
[REMOVE (PURGE)] xserver-xorg-video-vmware:i386 1:13.3.0-2
[UPGRADE] xorg-docs-core:i386 1:1.7.1-1 -> 1:1.7.1-1.2
[UPGRADE] xterm:i386 361-1 -> 362-1

and now the screen[s] do[es] not come back to life within...  uh ah one minute?

And BTW I've tried to present my problem on the phabricator, but there is no 
reaction within 10 days or so by now.

Isn't there anybody who knows what these ~/.xsession-errors log lines say:
BL: set 
[/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0]
 -> 320
BL: set 
[/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0]
 -> 312
BL: set 
[/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0]
 -> 306
BL: set 
[/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0]
 -> 302
BL: set 
[/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0]
 -> 300
BL: set 
[/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0]
 -> 299
# end citation

The only thing google finds (even if cutting off the rather unspecific ` -> 
iii' line terminations, is Bug#976235 on www.mail-archive.com.

I can't believe it.  I have tried ldd to see if there are any missed 
libs--nothing.  I'm uh puzzled.

Anyway brgds all best wishes and--we'll carry on.

--
  //   enno@gmx.net
/\\\   Mag. Enno Deimel
  .\o
 \\  \ _  \Wisely and slow; they stumble that run fast.
\\\ \_/
gpg-fp: eefe b049 6fe6 fc0b 0ec4  f39e af6a c178 eb98 909a

Bug#960304: avoiding and recovering from snapshot.d.o rate-limiting

[Johannes Schauer Marin Rodrigues]

Hi,

as the author of metasnap, debrebuild and debbisect (all using snapshot.d.o) I
thought that maybe it makes sense to post to these bugs what I learned about
how to reliably pull data from snapshot.d.o.

For the most reliable and stable solution (has been able to download stuff for
over three months without unrecoverable errors) I recommend to look at the
function download() in the metasnap source code:

https://salsa.debian.org/josch/metasnap/-/blob/master/run.py#L129

To run stable the code:

 - throttles the number of requests such that each request takes a minimum of
   1.5 seconds which allows about 2200 connections per hour
 - is able to recover from infinite timeouts
 - is able to handle HTTP errors 500
 - recovers after E_COULDNT_CONNECT errors
 - backs off for four seconds (less do not work) to the power of number of 
retries

The second-best solution is implemented by debbisect. Since the same packages
are required multiple times, it builds a local cache of the packages and then
apt only sees that cache. The caching code borrows some of the things I learned
from writing metasnap and seems to run reasonably well. See the _download_new()
function in the Proxy class:

https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/debbisect#L159

Thirdly, debrebuild only needs packages once, so a cache doesn't make sense.
Instead we try to do the best we can just using apt options. The following
options seem to work okay. If it still fails, retrying works most of the time.

   Acquire::Check-Valid-Until "false";
   Acquire::http::Dl-Limit "1000";
   Acquire::https::Dl-Limit "1000";
   Acquire::Retries "5";

https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/debrebuild

Maybe my next project will be an overlay for snapshot.d.o which provides a sane
rate limiting and throttles the bandwidth instead of cutting connections,
refusing new connections or throwing HTTP 500 errors...

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#976050: mailutils: FTBFS on amd64 with current unstable

[Rob Browning]

Andreas Henriksson  writes:

> Thanks for this info, it made it much easier to know where to look for
> the problem which is caused by having emacs installed in the build
> environment (which it isn't in a clean buildd chroot).

Ahh, sorry, clearly forgot to mention that I'd also run "apt install
emacs-nox" to do some editing.  Glad you figured it out.

> I see these potential theoretical solutions:

No strong opinion, fwiw -- I was originally just concerned about the
build failure.

> 2. just `rm -rf debian/tmp/usr/share/emacs` before dh_missing is ran.

...or maybe a dh_missing debian/not-installed override or -X if that'll
work.

> 4. Try to convince configure to enable emacs/lispdir without having
>emacs necessarily installed (possibly by passing --with-lispdir)
>and install the emacs/site-lisp files.
>(Probably a better idea than 3 if possible.)

Seems like in the short run, we didn't have those bits before, so
perhaps fine to leave it that way for now.  And in the longer run, if we
decide we do want those files, and if there's much elisp code, it might
ought to be compiled at install time as with dh-elpa or other
emacsen-related packages, which might or might not suggest a
mailutils-el package or something.

If you do decide to head that route, I'd highly recommend #debian-emacs
on oftc.  Plenty of expertise there.

Thanks again
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#977049: Please drop restriction on pytest << 5.4.0

[Jonas Smedegaard]

Quoting Christian Kastner (2021-01-02 18:40:30)
> Hi Jonas,
> 
> On 10.12.20 18:01, Jonas Smedegaard wrote:
> > Upstream pytest-asyncio 0.14.0 indeed supports pytest 6, but not pytest 
> > 4.6.11 currently in Debian unstable.
> > 
> > Debian package python-pytest-asyncio includes a patch to restore support 
> > for pytest 4.6.11, but unfortunately that makes it incompatible with 
> > pytest 6.
> > 
> > I guess the way forward is to first release pytest 6 to unstable and 
> > only then drop the patch in python-pytest-asyncio.
> 
> pytest 6.0.2 was uploaded to unstable today, so you can co ahead and
> drop the patch whenever it is convenient for you.

Thanks for the notice - excellent service!

 - Jonas

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

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

signature.asc
Description: signature

Bug#978962: certbot: Certbot needs python-cryptography to work

[Harlan Lieberman-Berg]

Hi Nicolas,

Your installation of python3-cryptography is very broken.  You appear
to be missing about half of the files for some reason.  Try
reinstalling python3-cryptography and see if that fixes the problem:

apt reinstall python3-cryptography

On Sat, Jan 2, 2021 at 3:09 AM Nicolas Grandjean  wrote:
>
>
>
> Le 01/01/2021 à 22:16, Harlan Lieberman-Berg a écrit :
> > […]
> > Can you also attach the output of this new script?
>
> You can find it in the attached files.
>
> $ ./import2.py > import2.out1 2> import2.out2
>
>
> --
> Nicolas



-- 
Harlan Lieberman-Berg
~hlieberman

Bug#979115: snapshot.debian.org: please only update the list of available timestamps after the sync is complete

[Johannes 'josch' Schauer]

Package: snapshot.debian.org
Severity: normal

Hi,

for the newest timestamp that one can find via
http://snapshot.debian.org/archive/debian/ it can happen that some of
the files in it return a 404. Maybe new timestamps are added to the web
interface before the download of all content is complete?

The webinterface should only show new timestamps once all their content
is completely available for download.

Thanks!

cheers, josch

Bug#978553: pam_unix should default to yescrypt

[Marco d'Itri]

On Jan 02, Steve Langasek  wrote:

> So, can you provide more rationale why you think this should be the default?
Because yescrypt is the best password hashing algorithm available in 
libxcrypt and its default.

https://www.openwall.com/yescrypt/ explains its design tradeoffs.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#977993: ITP: sfizz -- SFZ parser and synth c++ library

[Olivier Humbert]

Control: retitle -1 ITP: sfizz -- SFZ parser and synth c++ library

Bug#978553: pam_unix should default to yescrypt

[Steve Langasek]

Control: tags -1 moreinfo

On Mon, Dec 28, 2020 at 03:56:10PM +0100, Marco d'Itri wrote:
> Package: libpam-modules
> Version: 1.4.0-1
> Severity: normal

> Now that a newer release has been packaged, "sha512" in 
> /etc/pam.d/common-password should be replaced by "yescrypt".

My immediate reaction to being asked to change the default hash algorithm to
one that I've never heard of is "hell no".

So, can you provide more rationale why you think this should be the default?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#976050: mailutils: FTBFS on amd64 with current unstable

[Andreas Henriksson]

Control: tags -1 - unreproducible moreinfo
Control: retitle -1 mailutils: FTBFS with emacs installed in build environment

Hello again,

On Sat, Jan 02, 2021 at 03:12:07PM -0600, Rob Browning wrote:
[...]
>  dh_missing
>   dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.el exists in 
> debian/tmp but is not installed to anywhere (related file: 
> "debian/tmp/usr/share/mailutils/mh/mailutils-mh.el")
>   dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.elc exists in 
> debian/tmp but is not installed to anywhere
[...]
>   dh_missing: error: missing files, aborting
>   make: *** [debian/rules:4: binary] Error 255
>   dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2
[...]

Thanks for this info, it made it much easier to know where to look for
the problem which is caused by having emacs installed in the build
environment (which it isn't in a clean buildd chroot).

The AM_PATH_LISPDIR macro will check for emacs xemacs and set the EMACS
variable (which defaults to 'no' if not found). This in turn will cause
the mailutils-mh.el to (also) be installed in the `lispdir` (in addition
to the `mhlibdir`).

I see these potential theoretical solutions:
1. Declare Build-Conflicts against any package that has emacs or xemacs.
   (... which seems like a really bad idea to me.)
2. just `rm -rf debian/tmp/usr/share/emacs` before dh_missing is ran.
3. Build-depend on (some variant of) emacs and install the
   emacs/site-lisp files.
4. Try to convince configure to enable emacs/lispdir without having
   emacs necessarily installed (possibly by passing --with-lispdir)
   and install the emacs/site-lisp files.
   (Probably a better idea than 3 if possible.)

I'm don't know emacs stuff well enough to know if and why installing
the same file in both paths would be a useful thing to do, maybe
someone else can help shine some light on that?

Doing 2/ is easy, fixes the problem, and gets the same content in
the built package as the currently existing package in the archive,
however it might be useful to understand what purpose having it in
the emacs/site-lisp path serves and if that's actually preferred over
just maintaining the status quo.

Regards,
Andreas Henriksson

Bug#948384: abandoning elasticsearch

[Kartik Kulkarni]

Due to lack of time and other constraints last year I was unable to
look into the package at all and I think it's better for someone else
to package it.
I do not know if I should just put it back as RFP but for now I have
retitled it as O.
I apologize for holding it for so long and not giving it back sooner.

Regards,
Kartik Kulkarni

Bug#979114: opendht: FTBFS in sid

[Gianfranco Costamagna]

Source: opendht
Version: 2.1.10-1
Severity: serious
tags: ftbfs

Hello, looks like opendht fails because of new boost.
Unfortunately I can't provide a patch since my boost::asio knowledge is limited 
and I failed to find upstream patches for this...

example of failure is here:
https://buildd.debian.org/status/fetch.php?pkg=opendht=amd64=2.1.10-1=1609530454=0

[ 67%] Building CXX object 
CMakeFiles/opendht-static.dir/src/compat/os_cert.cpp.o
/usr/bin/c++ -DASIO_STANDALONE -DOPENDHT_JSONCPP -DOPENDHT_LOG=true 
-DOPENDHT_PEER_DISCOVERY -DOPENDHT_PROXY_CLIENT -DOPENDHT_PROXY_SERVER 
-DOPENDHT_PUSH_NOTIFICATIONS -DPACKAGE_VERSION=\"2.1.9\" -I/<>/. 
-I/<>/include -I/<>/include/opendht 
-I/<>/obj-x86_64-linux-gnu/include -isystem /usr/include/jsoncpp 
-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-return-type -Wall 
-Wextra -Wnon-virtual-dtor -pedantic-errors -fvisibility=hidden 
-DMSGPACK_DISABLE_LEGACY_NIL -DMSGPACK_DISABLE_LEGACY_CONVERT -fPIC 
-std=gnu++14 -o CMakeFiles/opendht-static.dir/src/compat/os_cert.cpp.o -c 
/<>/src/compat/os_cert.cpp
/<>/src/http.cpp: In lambda function:
/<>/src/http.cpp:1418:46: warning: unused parameter ‘resp’ 
[-Wunused-parameter]
 1418 | add_on_done_callback([&](const Response& resp){
  |  ^~~~
In file included from /usr/include/asio/executor.hpp:340,
 from /usr/include/asio.hpp:85,
 from /usr/include/restinio/asio_include.hpp:14,
 from /usr/include/restinio/impl/include_fmtlib.hpp:18,
 from /usr/include/restinio/http_headers.hpp:11,
 from /<>/include/opendht/http.h:33,
 from /<>/include/opendht/dht_proxy_server.h:30,
 from /<>/src/dht_proxy_server.cpp:25:
/usr/include/asio/impl/executor.hpp: In instantiation of ‘void 
asio::executor::impl< ,  
>::on_work_started() [with Executor = 
asio::execution::any_executor,
 asio::execution::detail::blocking::never_t<0>, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 > >; Allocator = std::allocator]’:
/usr/include/asio/impl/executor.hpp:76:8:   required from here
/usr/include/asio/impl/executor.hpp:78:15: error: ‘class 
asio::execution::any_executor,
 asio::execution::detail::blocking::never_t<0>, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 > >’ has no member named ‘on_work_started’
   78 | executor_.on_work_started();
  | ~~^~~
/usr/include/asio/impl/executor.hpp: In instantiation of ‘void 
asio::executor::impl< ,  
>::on_work_finished() [with Executor = 
asio::execution::any_executor,
 asio::execution::detail::blocking::never_t<0>, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 > >; Allocator = std::allocator]’:
/usr/include/asio/impl/executor.hpp:81:8:   required from here
/usr/include/asio/impl/executor.hpp:83:15: error: ‘class 
asio::execution::any_executor,
 asio::execution::detail::blocking::never_t<0>, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 > >’ has no member named ‘on_work_finished’
   83 | executor_.on_work_finished();
  | ~~^~~~
/usr/include/asio/impl/executor.hpp: In instantiation of ‘void 
asio::executor::impl< ,  
>::dispatch(asio::executor::function&&) [with Executor = 
asio::execution::any_executor,
 asio::execution::detail::blocking::never_t<0>, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 > >; Allocator = std::allocator; asio::executor::function = 
asio::detail::executor_function]’:
/usr/include/asio/impl/executor.hpp:91:8:   required from here
/usr/include/asio/impl/executor.hpp:93:15: error: ‘class 
asio::execution::any_executor,
 asio::execution::detail::blocking::never_t<0>, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 > >’ has no member named ‘dispatch’
   93 | executor_.dispatch(ASIO_MOVE_CAST(function)(f), allocator_);
  | ~~^~~~
/usr/include/asio/impl/executor.hpp: In instantiation of ‘void 
asio::executor::impl< ,  
>::post(asio::executor::function&&) [with Executor = 
asio::execution::any_executor,
 asio::execution::detail::blocking::never_t<0>, 
asio::execution::prefer_only 
>, 
asio::execution::prefer_only
 >, 
asio::execution::prefer_only
 >, 

Bug#979112: qdbm: reproducible builds: Embeds build time in qdbm.jar

[Vagrant Cascadian]

Control: tags 979122 pending

On 2021-01-02, Vagrant Cascadian wrote:
> From c47ed6a5fd02b99f090b4615bc81283020a7a3b9 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Sat, 2 Jan 2021 21:20:37 +
> Subject: [PATCH] debian/rules: Add calls to dh_strip_nonderminism.
>
> dh_strip_nondeterminism sets appropriate timestamps in the shipped
> .jar files.
>
> https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_jar_issue.html
> ---
>  debian/rules | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/debian/rules b/debian/rules
> index 4278b70..8545b04 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -176,6 +176,7 @@ binary-indep: build install
>  #dh_installman -i
>   dh_link -i
>   dh_strip -i
> + dh_strip_nondeterminism -i
>   dh_compress -i
>   dh_fixperms -i
>   dh_perl -i
> @@ -197,6 +198,7 @@ binary-arch: build install
>   rm -f $(CURDIR)/debian/qdbm-util/usr/share/man/man1/*test
>   dh_link -a
>   dh_strip -a
> + dh_strip_nondeterminism -a
>   dh_compress -a
>   dh_fixperms -a
>   dh_perl -plibqdbm-perl
> -- 
> 2.30.0

Pushed to git:

  
https://salsa.debian.org/debian/qdbm/-/commit/c3fb3559a468624df1c67cbc63d5bf2b66818bd1

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#979113: libpulse-dev: lib .so files in -dev package, cause other programs to fail

[Federico Grau]

Package: libpulse-dev
Version: 12.2-4+deb10u1
Severity: normal

Dear Maintainer,

* What led up to the situation?
Other programs were failing, because they were unable to load
libpulse-simple.so library file with only libpulse0 package installed.
The xcwcp package is one such example.

* What exactly did you do (or not do) that was effective (or ineffective)?
A workaround is to install libpulse-dev in addition to libpulse0.
However this also installs several additional other packages, and should
not be required for standard library usage.

Attached is a patch against current salsa.debian.org git, to alter the
debian file packaging associating library .so files with the library
package.


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

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

Versions of packages libpulse-dev depends on:
ii  libglib2.0-dev   2.58.3-2+deb10u2
ii  libpulse-mainloop-glib0  12.2-4+deb10u1
ii  libpulse012.2-4+deb10u1

libpulse-dev recommends no packages.

libpulse-dev suggests no packages.

-- no debconf information

Control: tag -1 +patch
diff --git a/debian/libpulse-dev.install b/debian/libpulse-dev.install
index a1bcccb8..23df19cc 100644
--- a/debian/libpulse-dev.install
+++ b/debian/libpulse-dev.install
@@ -1,7 +1,4 @@
 usr/lib/*/cmake
-usr/lib/*/libpulse.so
-usr/lib/*/libpulse-simple.so
-usr/lib/*/libpulse-mainloop-glib.so
 usr/lib/*/pkgconfig/*
 usr/include/pulse/*
 usr/share/vala/vapi
diff --git a/debian/libpulse-mainloop-glib0.install 
b/debian/libpulse-mainloop-glib0.install
index d2af2063..f0103839 100644
--- a/debian/libpulse-mainloop-glib0.install
+++ b/debian/libpulse-mainloop-glib0.install
@@ -1 +1,2 @@
+usr/lib/*/libpulse-mainloop-glib.so
 usr/lib/*/libpulse-mainloop-glib.so.*
diff --git a/debian/libpulse0.install b/debian/libpulse0.install
index cf55606f..cf3d95ed 100644
--- a/debian/libpulse0.install
+++ b/debian/libpulse0.install
@@ -1,4 +1,6 @@
 etc/pulse/client.conf
+usr/lib/*/libpulse.so
 usr/lib/*/libpulse.so.*
+usr/lib/*/libpulse-simple.so
 usr/lib/*/libpulse-simple.so.*
 usr/lib/*/pulseaudio/libpulsecommon-*.so


signature.asc
Description: PGP signature

Bug#978701: wireshark: Please package version 2.6.20 with GTK support

[Dmitry Katsubo]

On 01/01/2021 15:33, Bálint Réczey wrote:
> I've pushed the new packaged upstream to the debian/buster branch on Salsa.
> 
> If you are (or anyone else is) interested please test the package on
> Buster get an approval for the upload, to follow:
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 
> (I don't have Buster setups now.)
> 
> Cheers,
> Balint

Many thanks, I was able to compile and install Wireshark v2.6.20 from that Git 
repository.

Great!

-- 
With best regards,
Dmitry

Bug#979112: qdbm: reproducible builds: Embeds build time in qdbm.jar

[Vagrant Cascadian]

Source: qdbm
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The file ./usr/share/qdbm/lib/qdbm.jar embeds the build time:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/qdbm.html

  -rw·2.0·fat0·bX·defN·22-Jan-08·04:40·META-INF/
  vs.
  -rw·2.0·fat0·bX·defN·20-Dec-07·00:20·META-INF/


The attached patch fixes this by adding calls to dh_strip_nondeterminism
in debian/rules.


This patch should be sufficient to make qdbm reproducible in the
bullseye suite.


Thanks for maintaining qdbm!


live well,
  vagrant
From c47ed6a5fd02b99f090b4615bc81283020a7a3b9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 2 Jan 2021 21:20:37 +
Subject: [PATCH] debian/rules: Add calls to dh_strip_nonderminism.

dh_strip_nondeterminism sets appropriate timestamps in the shipped
.jar files.

https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_jar_issue.html
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 4278b70..8545b04 100755
--- a/debian/rules
+++ b/debian/rules
@@ -176,6 +176,7 @@ binary-indep: build install
 #	dh_installman -i
 	dh_link -i
 	dh_strip -i
+	dh_strip_nondeterminism -i
 	dh_compress -i
 	dh_fixperms -i
 	dh_perl -i
@@ -197,6 +198,7 @@ binary-arch: build install
 	rm -f $(CURDIR)/debian/qdbm-util/usr/share/man/man1/*test
 	dh_link -a
 	dh_strip -a
+	dh_strip_nondeterminism -a
 	dh_compress -a
 	dh_fixperms -a
 	dh_perl -plibqdbm-perl
-- 
2.30.0



signature.asc
Description: PGP signature

Bug#979111: rocksndiamonds: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: rocksndiamonds 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of rocksndiamonds
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#974979: make courier configuration by default on directories.. event files

[PICCORO McKAY Lenz]

El sáb, 2 de ene. de 2021 a la(s) 09:54, Markus Wanner
(mar...@bluegap.ch) escribió:
> just a matter of defaults.  I agree the directories should be created by
> default.
>
> > First setp to solve this is in courier-base package, must be changed
> > to true, this will create the minimal set of directories.
> If you're speaking of the `courier-base/webadmin-configmode` template
> question, I'm with you.  This needs to vanish.
the question is made in courier-base .. cos webadmin depends on

> > Later in a new revision remove the question and migrate to use
> > only directories (that can co-exist with normal files), manpages
> > of the courier suite points so many times about those directories..
> Manpages should be adjusted to clarify both is possible, IMO.
manpages already point that! the html and web of courier is also
almost same as manpages!

> should be possible.  However, I think it already *is* possible now.  It
> clearly works for me (tm).  Anything in specific that doesn't work when
> configuring using multiple files in a directory?
as i said, manpages said it works for both! so directories must be default,
webadmin does not touch single files unless are need!. just need
directory structure be present..
>
> Regards
>
> Markus

i alreay include some of those direction in the !9 pull request!

dont worry about lot of commits.. merge rewuest will be squash wen
merged in one only message!

Bug#976050: mailutils: FTBFS on amd64 with current unstable

[Rob Browning]

Andreas Henriksson  writes:

> Could you please try using `dpkg-buildpackage -uc -us`, rather than
> directly invoking debian/rules, and see if it helps you detect any
> misconfigurations in your build environment?

Just tried again in a new debian/testing64 VM (via vagrant).  It still
fails in the same way with "debian/rules binary", and fails in a new way
(dh_missing error) with "dpkg-buildpackage -uc -us".

Exact commands (suspect a current testing schroot would behave
similarly, but haven't tested that yet):

  $ mkdir tmp-mailutils-test
  $ cd tmp-mailutils-test
  $ vagrant init debian/testing64
  $ vagrant up
  $ vagrant ssh
  $ sudo -i
  # apt update
  # apt dist-upgrade
  # apt build-dep mailutils
  # apt source mailutils
  # cd mailutils-3.10
  # dpkg-buildpackage -uc -us
...
  make[1]: Entering directory '/root/mailutils-3.10'
  dh_fixperms -Xdotlock.mailutils
  make[1]: Leaving directory '/root/mailutils-3.10'
 dh_missing
  dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.el exists in 
debian/tmp but is not installed to anywhere (related file: 
"debian/tmp/usr/share/mailutils/mh/mailutils-mh.el")
  dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.elc exists in 
debian/tmp but is not installed to anywhere

  While detecting missing files, dh_missing noted some files with a 
similar name to those
  that were missing.  This error /might/ be resolved by replacing 
references to the
  missing files with the similarly named ones that dh_missing found - 
assuming the content
  is identical.

  As an example, you might want to replace:
   * debian/tmp/usr/share/mailutils/mh/mailutils-mh.el
  with:
   * usr/share/emacs/site-lisp/mailutils-mh.el
  in a file in debian/ or as argument to one of the dh_* tools called 
from debian/rules.
  (Note it is possible the paths are not used verbatim but instead 
directories
  containing or globs matching them are used instead)

  Alternatively, add the missing file to debian/not-installed if it 
cannot and should not
  be used.

  The following debhelper tools have reported what they installed (with 
files per package)
   * dh_install: libmailutils-dev (115), libmailutils7 (36), libmu-dbm7 
(2), mailutils (10), mailutils-common (14), mailutils-comsatd (1), 
mailutils-doc (1), mailutils-guile (2), mailutils-imap4d
  (1), mailutils-mda (3), mailutils-mh (46), mailutils-pop3d (2), 
python3-mailutils (23)
   * dh_installdocs: libmailutils-dev (0), libmailutils7 (0), 
libmu-dbm7 (0), mailutils (0), mailutils-common (0), mailutils-comsatd (0), 
mailutils-doc (6), mailutils-guile (0), mailutils-imap4d (0), mailutils-mda 
(0), mailutils-mh (1), mailutils-pop3d (0), python3-mailutils (0)
   * dh_installexamples: libmailutils-dev (0), libmailutils7 (0), 
libmu-dbm7 (0), mailutils (1), mailutils-common (0), mailutils-comsatd (1), 
mailutils-doc (0), mailutils-guile (1), mailutils-imap4d (1), mailutils-mda 
(0), mailutils-mh (0), mailutils-pop3d (1), python3-mailutils (0)
   * dh_installman: libmailutils-dev (2), libmailutils7 (0), libmu-dbm7 
(0), mailutils (10), mailutils-common (0), mailutils-comsatd (1), mailutils-doc 
(0), mailutils-guile (0), mailutils-imap4d (1), mailutils-mda (3), mailutils-mh 
(0), mailutils-pop3d (2), python3-mailutils (0)
  If the missing files are installed by another tool, please file a bug 
against it.
  When filing the report, if the tool is not part of debhelper itself, 
please reference the
  "Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
(in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
  Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
  If the omission is intentional or no other helper can take care of 
this consider adding the
  paths to debian/not-installed.
  dh_missing: error: missing files, aborting
  make: *** [debian/rules:4: binary] Error 255
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

It's trivial to reproduce with those commands, so happy to gather any
addiitonal information you might like.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#978088: HELP needed for uploading a new debianisation 7.1-3 of the Rheolef package

[Pierre Saramito]

Hi Anton, 

> From Anton Gladky: 
> sure, I will! Please push your changes in master-branch. It looks 
> only the tags were pushed. 

Sorry ! Its done now. 

Many thanks for your help, 

Pierre 
-- 
pierre.saram...@imag.fr 
Directeur de Recherche CNRS 
Laboratoire Jean Kuntzmann, Grenoble, France 
http://ljk.imag.fr/membres/Pierre.Saramito 

Bug#979110: python3-ipykernel: DeprecationWarning so should declare dependency on python3-ipyparallel

[Julian Gilbey]

Package: python3-ipykernel
Version: 5.4.2-1
Severity: normal

I am seeing warnings like the following from python3-ipykernel:

/usr/lib/python3/dist-packages/ipykernel/zmqshell.py:57
  /usr/lib/python3/dist-packages/ipykernel/zmqshell.py:57: DeprecationWarning: 
ipykernel.datapub is deprecated. It has moved to ipyparallel.datapub
from ipykernel.datapub import ZMQDataPublisher

/usr/lib/python3/dist-packages/ipykernel/datapub.py:21
  /usr/lib/python3/dist-packages/ipykernel/datapub.py:21: DeprecationWarning: 
ipykernel.serialize is deprecated. It has moved to ipyparallel.serialize
from ipykernel.serialize import serialize_object

/usr/lib/python3/dist-packages/ipykernel/serialize.py:25
  /usr/lib/python3/dist-packages/ipykernel/serialize.py:25: DeprecationWarning: 
ipykernel.pickleutil is deprecated. It has moved to ipyparallel.
from ipykernel.pickleutil import (

/usr/lib/python3/dist-packages/ipykernel/pickleutil.py:26
  /usr/lib/python3/dist-packages/ipykernel/pickleutil.py:26: 
DeprecationWarning: ipykernel.codeutil is deprecated since IPykernel 4.3.1. It 
has moved to ipyparallel.serialize
from ipykernel import codeutil

Looking at the code for ipykernel, it is attempting to load these
functions from ipyparallel and only falling back on the ipykernel
versions if ipyparallel is not available or is version < 5.0.0.  So
this package should Depends: python3-ipyparallel.

Best wishes,

   Julian

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

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

Versions of packages python3-ipykernel depends on:
ii  python3 3.9.0-4
ii  python3-ipython 7.19.0-1
ii  python3-jupyter-client  6.1.6-1
ii  python3-tornado 6.1.0-1+b1
ii  python3-traitlets   5.0.5-1

python3-ipykernel recommends no packages.

python3-ipykernel suggests no packages.

-- no debconf information

Bug#979109: ITP: loggedfs -- Logging file system

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: loggedfs
  Version : 0.9
  Upstream Author : Rémi Flament
* URL : http://rflament.github.io/loggedfs/
* License : Apache-2.0
  Programming Lang: C++
  Description : Logging file system

 LoggedFS is a logging file system which can log every operation
 happening in it. It mounts transparently over any directory and logs
 operations inside that directory (and its children).
 .
 The amount of logging is configurable, and since LoggedFS uses FUSE,
 it can be controlled by users without system administrator
 involvement.

Bug#976892: autoconf 2.70

[Barak A. Pearlmutter]

Other bugs, in other packages, pretty much.
I'm not spun up enough on autoconf to help.

autoconf 2.70 *is* in experimental, and autobuilders are building
packages with it and reporting bugs. Seems like a very reasonable path
to me.

Bug#978088: HELP needed for uploading a new debianisation 7.1-3 of the Rheolef package

[Anton Gladky]

Hi Pierre,

sure, I will! Please push your changes in master-branch. It looks
only the tags were pushed.

Regards

Anton

Am Sa., 2. Jan. 2021 um 19:41 Uhr schrieb Pierre Saramito
:
>
> Hi Anton, hi all,
>
> I just commit with git a new release 7.1-3 of the debianisation
> of the rheolef package: it fixes bug #978088 (see d/changelog)
> thanks to a patch by Vagrant Cascadian 
>
> The upstream version is unchanged (7.1).
>
> Could you please upload it in debian ?
>
> Many thanks for your help.
>
> Best regards,
>
> Pierre
> --
> pierre.saram...@imag.fr
> Directeur de Recherche CNRS
> Laboratoire Jean Kuntzmann, Grenoble, France
> http://ljk.imag.fr/membres/Pierre.Saramito

Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

[Brian Smith]

Hi Francesco,

On Sat, Jan 2, 2021 at 4:34 AM Francesco Poli  wrote:
>
> Hello Brian,
> I wonder what's the status of the work in progress packaging of
> warewulf.
>
> I would be very happy to see it properly packaged and included in the
> official Debian main archive.
>
> Please let me know.
> Thank you for what you have done so far and for what you are doing!
>
>

This fell by the wayside due to the reasons discussed in this bug.
Changing to RFP.

> --
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE



-- 
Brian T. Smith
System Fabric Works
Senior Principal Engineer
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#963477: ruby-rack: CVE-2020-8184

[Salvatore Bonaccorso]

Hi Utkarsh,

On Sat, Jan 02, 2021 at 06:38:37PM +0530, Utkarsh Gupta wrote:
> Hi Salvatore,
> 
> On Sat, Jan 2, 2021 at 5:55 PM Salvatore Bonaccorso  wrote:
> > > Of course. Uploaded a fix! :)
> > > (thanks for the explicit CC, please do it next time as well if you
> > > want me to take care of something which falls under the Ruby team).
> >
> > Thanks! About the explicit CC, well actually I was a bit "vary",
> > because if it's team maintained one should not start explicitly ping
> > some of the uploaders. But I'm glad if this was possible.
> 
> It's not a problem, I am happy to help the security team as much as I
> possibly can (though you'd hopefully know that by now ;)).

Yes :)

> 
> > Indeed there would be more ruby team maintained packages which
> > are currently no-dsa marked but maybe would be good to fix for
> > and in bullseye. There are issues for instance in ruby-faye and
> > ruby-faye-websocket as well: 967061, 959392, 967063.
> 
> Eeks, sorry for not noticing them earlier. But I've uploaded a fix for all
> three of them^ :)
> 
> Let me know if there are more that needs immediate fixing or so! \o/

Not any right now. Well there is CVE-2020-26247 but that one might be
too risky at this stage (AFAIU it is a breaking change, and thus ws
moved to the 1.11.x version).

Regards,
Salvatore

Bug#979082: RFS: transcalc/0.14-7 [QA] [RC] -- microwave and RF transmission line calculator

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: transcalc
   Version : 0.14-7
   Upstream Author :
 * URL : http://transcalc.sourceforge.net/
 * License :
 * Vcs :
   Section : science

It builds those binary packages:

  transcalc - microwave and RF transmission line calculator

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/t/transcalc/transcalc_0.14-7.dsc

Changes since the last upload:

 transcalc (0.14-7) unstable; urgency=medium
 .
   * QA upload.
   * Add patch to fix ftbfs with gcc10 (Closes: #957880)
   * Add patch to fix segfault when closing windows (Closes: #763125)
   * Add patch which fixes a deprecation warning regarding autoconf
   * d/clean: Remove some embedded code copies (Closes: #947972)
   * d/rules:
 - Change to dh sequencer
 - Change hardening rules to +all
 - Override dh_auto_test, we don't have any tests
 - Move example files to the recommended path
   * d/compat: Drop file, use debhelper-compat in d/control
   * d/control:
 - Bump debhelper to 12
 - Update Standards-Version to 3.9.7
 - Add Rules-Requires-Root
   * d/changelog: Remove whitespace
   * d/watch: Update to version 4
   * d/copyright: Change license file link to GPL-2
   * Add Debian source format 3.0 (quilt)

Regards,
Håvard

Bug#979108: memtool: 64 bit memory reads may be split on 32 bit systems

[Gergely Peli]

Package: memtool
Severity: normal
Tags: upstream patch

Hello,

I tried memtool on a 32 bit ARM system, and the supposedly 64 bit reads
with the "-q" option are done by 2 separate 32 bit "ldr" instructions.
Adding a volatile qualifier to the pointers accessing the memory could
convince gcc to generate a single "ldrd" instruction instead, which uses
a 64 bit memory transfer. See below a proposed patch. Adding volatile to all
4 cases may be an overkill, but can't hurt. Cheers,

Gergely Peli



--- memtool-2016.10.0.orig/memtool.c
+++ memtool-2016.10.0/memtool.c
@@ -152,24 +152,24 @@ static int memory_display(const void *ad
for (i = 0; i < linebytes; i += width) {
if (width == 8) {
uint64_t res;
-   res = (*uqp++ = *((uint64_t *)addr));
+   res = (*uqp++ = *((volatile uint64_t *)addr));
if (swab)
res = swab64(res);
count -= printf(" %016" PRIx64, res);
} else if (width == 4) {
uint32_t res;
-   res = (*uip++ = *((uint *)addr));
+   res = (*uip++ = *((volatile uint *)addr));
if (swab)
res = swab32(res);
count -= printf(" %08" PRIx32, res);
} else if (width == 2) {
uint16_t res;
-   res = (*usp++ = *((ushort *)addr));
+   res = (*usp++ = *((volatile ushort *)addr));
if (swab)
res = swab16(res);
count -= printf(" %04" PRIx16, res);
} else {
-   count -= printf(" %02x", (*ucp++ = *((u_char 
*)addr)));
+   count -= printf(" %02x", (*ucp++ = *((volatile 
u_char *)addr)));
}
addr += width;
offs += width;



PS: the below specs are not for the tested system.


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

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

Bug#979107: Wrong file shipped for qemu-x86/qemu-x86_64

[Faidon Liambotis]

Package: u-boot-qemu
Version: 2020.10+dfsg-1
Severity: important

u-boot-qemu currently ships:
  /usr/lib/u-boot/qemu-x86/u-boot.bin
  /usr/lib/u-boot/qemu-x86/uboot.elf
  /usr/lib/u-boot/qemu-x86_64/u-boot.bin
  /usr/lib/u-boot/qemu-x86_64/uboot.elf

However, these do not seem to be functional. e.g.
  qemu-system-i386 -nographic -bios /usr/lib/u-boot/qemu-x86/u-boot.bin
  qemu-system-x86_64 -nographic -bios /usr/lib/u-boot/qemu-x86_64/u-boot.bin
fails with:
  qemu: could not load PC BIOS '/usr/lib/u-boot/qemu-x86/u-boot.bin'

I believe that the correct file to use here is "u-boot.rom" which is
what u-boot's documentation refers to as well. I've confirmed with a
local build that it indeed boots with the invocation above.

The rom file is generated by u-boot's build system without any changes;
it's just currently not shipped by the Debian package. I think the fix
here may be as simple as:
  sed -i '/x86/s/bin/rom/' debian/targets

Thanks!
Faidon

Bug#979083: i3-wm: config file error. $mod+d is in the file twice

[Jakob Haufe]

Control: tags 979083 + upstream
Control: tags 979083 + pending
Control: forwarded 979083 https://github.com/i3/i3/issues/4304

Thanks for the report!

The problem was introduced in [1].

I reported it upstream in [2] and will include a bugfix in the next
upload.

Cheers,
sur5r

[1] https://github.com/i3/i3/pull/4055
[2] https://github.com/i3/i3/issues/4304

-- 
ceterum censeo microsoftem esse delendam.


pgpybefaaUf0_.pgp
Description: OpenPGP digital signature

Bug#979105: dwarves: embeds libbpf

[Luca Boccassi]

Package: dwarves
Version: 1.17-1
Severity: important
Tags: bullseye patch

Dear Maintainer(s),

dwarves vendors and statically links against libbpf, which is now
available in the Debian archive as a fully maintained shared library.

This is a problem in the upstream CMake files, I've sent a patch to fix it:

https://www.spinics.net/lists/dwarves/msg00732.html

I have also prepared a backport and tested it, and opened a MR on Salsa:

https://salsa.debian.org/debian/dwarves/-/merge_requests/2

Please consider applying it before the bullseye freeze.

Thank you!

Kind regards,
Luca Boccassi

Bug#979106: transition: limesuite

[Christoph Berg]

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

There is a new version of limesuite in experimental, the driver for
the Limesdr software defined radios.

There are only 2 rdepends external to the source package, gr-limesdr
and osmo-trx. Both build fine with the new version, and I also tested
with sdrangel (an ITP which should finally upload).

Ben file:

title = "limesuite";
is_affected = .depends ~ "liblimesuite20.01-1" | .depends ~ 
"liblimesuite20.10-1";
is_good = .depends ~ "liblimesuite20.10-1";
is_bad = .depends ~ "liblimesuite20.01-1";

Are we ok to upload to unstable?

Thanks,
Christoph

Bug#957045: bird: ftbfs with GCC-10

[Ondřej Surý]

Benjamin,

I pushed both repos, please push your changes directly. Also feel free to add 
yourself to co-maintainers if you use bird and care about it. Thanks for the NMU

Ondrej
--
Ondřej Surý  (He/Him)

> On 2. 1. 2021, at 18:09, Benjamin Drung  wrote:
> 
> Hi Ondřej,
> 
>> On Fri, 17 Apr 2020 10:57:13 + Matthias Klose  wrote:
>> Package: src:bird
>> Version: 1.6.8-1
>> 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.
>> 
>> The full build log can be found at:
>> http://people.debian.org/~doko/logs/gcc10-20200225/bird_1.6.8-1_unstable_gcc10.log
>> The last lines of the build log are at the end of this report.
> 
> In consideration of the nearing freeze and the fix being applied
> upstream, I took the opportunity to prepare a NMU and upload it without
> delay. I also couldn't resist to address the lintian warning about
> upstart. The debdiff is attached.
> 
> Since https://salsa.debian.org/debian/bird lacks the commits for the
> last upload (1.6.8-2) I did not commit my changes to the repository, but
> attach them as patches to this mail. Then you can apply them with
> "git am" once you pushed the changes for 1.6.8-2.
> 
> -- 
> Benjamin Drung
> Debian & Ubuntu Developer
> 
> <0001-Unix-fix-compilation-with-GCC-10.patch>
> <0002-Remove-obsolete-upstart-files.patch>
> <0003-Release-bird-1.6.8-2.1.patch>

Bug#978088: HELP needed for uploading a new debianisation 7.1-3 of the Rheolef package

[Pierre Saramito]

Hi Anton, hi all, 

I just commit with git a new release 7.1-3 of the debianisation 
of the rheolef package: it fixes bug #978088 (see d/changelog) 
thanks to a patch by Vagrant Cascadian  

The upstream version is unchanged (7.1). 

Could you please upload it in debian ? 

Many thanks for your help. 

Best regards, 

Pierre 
-- 
pierre.saram...@imag.fr 
Directeur de Recherche CNRS 
Laboratoire Jean Kuntzmann, Grenoble, France 
http://ljk.imag.fr/membres/Pierre.Saramito 

Bug#978953: wsjtx: Does not exit cleanly

[Christoph Berg]

Control: tags -1 unreproducible

Re: Hilary Snaden
> On using the GUI to quit the program, two processes are left ruuning with 
> high CPU load, still reading sound input. These processes remain until 
> killed. 

Hi,

I don't think this is a general problem, wsjtx exits normally here.

You didn't include any description of these processes, btw.

Christoph

Bug#978088: rheolef: reproducible builds: date in various .pdf files

[Pierre Saramito]

Dear Vagrant, 

Many thanks for your patch: it has just been integrated in a new 
release 7.1-3 of the debianization of the Rheolef package. 
It has also been integrated for the next upstream version. 

Best wishes, 

Pierre 
-- 
pierre.saram...@imag.fr 
Directeur de Recherche CNRS 
Laboratoire Jean Kuntzmann, Grenoble, France 
http://ljk.imag.fr/membres/Pierre.Saramito 

Bug#731769: Still works?

[Vincent Lefevre]

On 2021-01-02 22:10:55 +0800, 積丹尼 Dan Jacobson wrote:
> Useful?
> $ du -hs .svn/pristine/
> 22M .svn/pristine/
> $ svn cleanup --vacuum-pristines
> $ du -hs .svn/pristine/
> 22M .svn/pristine/

$ du -hs .svn/pristine/
24G .svn/pristine/
$ svn cleanup --vacuum-pristines
$ du -hs .svn/pristine/
967M.svn/pristine/

Perhaps you had an already "clean" pristine directory.

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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Matthew Vernon]

Hi,

I see that network-manager 1.28.0-2 has been uploaded, with (inter alia) 
the following changelog entry:


* Demote libpam-systemd to Recommends.
 This allows users to use and experiment with other init systems. Such a
 setup is neither tested nor fully supported and users need to be aware
 that some functionality might be broken. (Closes: #921012)

I don't know if Michael has discussed this with you in private, and that 
you thus know why this change was made (rather than adjusting the 
dependency as requested).


While this does address the co-installability of network-manager with 
elogind, I would like you to still say something officially about the 
issue, please, since this is not the only affected package.


As an example, bug 923387 (which Michael is also maintainer of) for 
udisks2, where the dependency must be a Depends not a Recommends (so the 
workaround used for network-manager won't help). Like 921012, Michael 
closed it on 2020-03-15 and Mark re-opened it (since the bug wasn't 
resolved) on 2020-07-02, and there has been no input from him since. I 
submit that this is technically substantially the same issue, and that 
you might usefully rule on it unless Michael has told you he plans to 
fix that already. I don't think (especially given the incoming freeze) 
that it does anyone any good to have to re-hash the same arguments about 
that bug.


Regards,

Matthew

Bug#973746: binutils-powerpc-linux-gnu: Segfault in st_other

[Christian Marillat]

973746 tags + fixed-upstream
973746 tags + patch
thanks

On 04 nov. 2020 13:15, Christian Marillat  wrote:

> Package: binutils-powerpc-linux-gnu
> Version: 2.35.1-2
> Severity: normal

This bug has been fixed upstream here :

https://sourceware.org/bugzilla/show_bug.cgi?id=27140

Christian

Bug#213733: nis: Testing upgrade breaks NIS

[Francesco P. Lovergine]

Hi, 


I'm currently housekeeping long standing bug reports about NIS, aѕ I adopted
recently the package.

In this report, the behavior of ypbind appears as a feature, not a bug. I mean
its behavior is expected.

Ypbind needs to know a list of NIS servers (in /etc/yp.conf) or
issues a broadcast (iif run with -broadcast or broacast is added to 
/etc/yp.conf) and wait for an answerṡ. Even in case of a NIS server, ypbind 
expects an IP address (possibly 127.0.0.1) in /etc/yp.conf.


So I don't see in this report 


On Thu, Oct 02, 2003 at 08:36:56PM +0930, Paul Schulz wrote:

Package: nis
Version: 3.9-6.3
Severity: normal

Upgrade NIS in testing distribution and NIS fails to restart.

The usual messages is reported.
 Starting NIS services: ypbind [binding to YP server .. 
 backgrounded]


NIS can be stopped and restarted several times with the same result.
(It was running previously without a problem.)

If 'ypbind' is started manually,

 # /usr/sbin/ypbind -f /etc/defaultdomain



Note that the right cmd is /usr/sbin/ypbind -f /etc/yp.conf, the 
/etc/defaultdomain is not intended as a configuration file.


The follwoing error is reported.. 


 io:~# /usr/sbin/ypbind -f /etc/defaultdomain
 No NIS server and no -broadcast option specified.
 Add a NIS server to the /etc/defaultdomain configuration file,
 or start ypbind with the -broadcast option.

BUT
If this option is put in, then ypbind starts properly
and then (surprisingly) NIS works again as expected.




This works only if at least one server is configured for
broadcasting. Which is not even the case since the buster release...

I don't remember about the woody days, but a possibility is
that it did revert to broadcast per default in case of a missing list of
servers, and that changed in sarge. For sure upstream applied a patch
for -local-only around that time, which could have changed the behavior.

For sure, nowdays and in the future broadcast is an explicit choice
of the admin, there is not a default for that and the admin must
specify an address for a working server or even -local-only for loopback.

--
Francesco P. Lovergine

Bug#976892: autoconf 2.70

[Matthias Klose]

> They seem pessimistic about getting it in as the default in bullseye,
> which seems like a shame.

it's a shame that you're writing that, without offering any way forward towards
this goal, whether that goal is realistic or not.  There are 160 issues to fix
until the freeze. How many are you planning to fix?

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-ac270;users=d...@debian.org

Bug#979103: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: nftables
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.

Bug#979102: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: maxima
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.

Bug#977956: Bug#977870: fixed in chromium 87.0.4280.88-0.4

[Stefan Lange]

On Sat, 02 Jan 2021 13:46:46 +0100 Michel Le Bihan  
wrote:

> Hello,
>
> I also have an IvyBridge laptop with the i5-3210M and can't reproduce
> your issue. Could you please list the graphic related packages that you
> have installed and any config changes you have made?
>
> Michel Le Bihan
>

Hello, thanks for your support.

First of all as a disclaimer: my system is quite the opposite of a 
"clean" install, rather an old system dist-upgraded continuously from 
debian/unstable over several years, so there may well be something wrong 
somewhere. I would fully understand if you can't be bothered with this 
kind of report, no hard feelings at all in that case.


I did some more tests:

First I removed /etc/chromium.d/default-flags to make sure that there 
are now entries that might interfere. Also, I started chromium with 
--temp-profile


Then tried again:

1) using intel driver (custom config 
/usr/share/X11/xorg.conf.d/20-intel.conf; file attached)


starting "chromium --temp-profile" -> seems to work OK, but pressing 
"F11" causes blinking/unresponsiveness


output of "chrome://gpu" is attached

starting "chromium --temp-profile --use-gl=desktop" -> becomes 
unresponsive, even directly or after short use


2) using modesetting driver

starting "chromium --temp-profile" -> seems to work OK, pressing "F11" 
works as expected


output of "chrome://gpu" is attached


I hope this will be helpful, if you decide to follow up and need more 
info, please let me know and I'll try to look deeper.


Thanks, Stefan

Below please find some additional info, as requested:

cat /proc/cpuinfo | grep i5
model name    : Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz

output gathered using "reportbug --template -T none -s none -S normal -b 
--list-cc none -q chromium" see below


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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages chromium depends on:
ii  chromium-common  87.0.4280.88-0.4
ii  libasound2   1.2.4-1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-3
ii  libatspi2.0-0    2.38.0-2
ii  libavcodec58 7:4.3.1-5
ii  libavformat58    7:4.3.1-5
ii  libavutil56  7:4.3.1-5
ii  libc6    2.31-6
ii  libcairo2    1.16.0-5
ii  libcups2 2.3.3op1-4
ii  libdbus-1-3  1.12.20-1
ii  libdrm2  2.4.103-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat1    2.2.10-1
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.2.6-1
ii  libgcc-s1    10.2.1-3
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk-3-0   3.24.24-1
ii  libharfbuzz0b    2.6.7-1
ii  libicu67 67.1-5
ii  libjpeg62-turbo  1:2.0.5-2
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.9-4+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.60-1
ii  libopenjp2-7 2.3.1-1
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse0    13.0-5
ii  libre2-9 20201101+dfsg-2
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-3
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux2    0.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.12-1
ii  libx11-xcb1  2:1.6.12-1
ii  libxcb1  1.14-2.1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  libxslt1.1   1.1.34-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  87.0.4280.88-0.4

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

Versions of packages chromium-common depends on:
ii  libc6   2.31-6
ii  libstdc++6  10.2.1-3
ii  libx11-6    2:1.6.12-1
ii  libxext6    2:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox    87.0.4280.88-0.4
ii  fonts-liberation    1:1.07.4-11
ii  gnome-flashback [notification-daemon]   3.38.0-1
ii  gnome-shell [notification-daemon]   3.38.2-1
ii  libgl1-mesa-dri 

Bug#979101: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: devtodo
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.

Bug#979100: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: connman
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.

Bug#979099: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: bluez
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.

Bug#979098: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: abook
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libreadline-gplv2-dev links with the GPL-2+ 
licensed older version. However, that is orphaned in Debian, so 
libeditreadline-dev should be preferred, which does not compile with 
your package without any patch. It links with the BSD-licensed libedit 
library which is a readline replacement.

Bug#977049: Please drop restriction on pytest << 5.4.0

[Christian Kastner]

Hi Jonas,

On 10.12.20 18:01, Jonas Smedegaard wrote:
> Upstream pytest-asyncio 0.14.0 indeed supports pytest 6, but not pytest 
> 4.6.11 currently in Debian unstable.
> 
> Debian package python-pytest-asyncio includes a patch to restore support 
> for pytest 4.6.11, but unfortunately that makes it incompatible with 
> pytest 6.
> 
> I guess the way forward is to first release pytest 6 to unstable and 
> only then drop the patch in python-pytest-asyncio.

pytest 6.0.2 was uploaded to unstable today, so you can co ahead and
drop the patch whenever it is convenient for you.

Best,
Christian

Bug#966906: bird2: FTBFS: collect2: error: ld returned 1 exit status

[Benjamin Drung]

On Tue, 20 Oct 2020 12:01:41 +0200 "=?UTF-8?Q?Stefan_B=c3=bchler?=" 
 wrote:
> Hi Ondrej,
> 
> On Mon, 3 Aug 2020 10:00:07 +0200 Lucas Nussbaum  wrote:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> > 
> > Relevant part (hopefully):
> > > /usr/bin/ld: obj/sysdep/unix/main.o:././nest/route.h:461: multiple 
> > > definition of `rta_dest_names'; 
> > > obj/conf/cf-parse.tab.o:././nest/route.h:461: first defined here
> > > LD -Wl,-z,relro -Wl,-z,now -g -O2 -fno-strict-aliasing 
> > > -fno-strict-overflow -fPIC -Wl,-z,defs -Wl,--as-needed -pthread -o birdcl 
> > > obj/client/commands.o obj/client/util.o obj/client/client.o 
> > > obj/client/birdcl.o
> > > LD -Wl,-z,relro -Wl,-z,now -g -O2 -fno-strict-aliasing 
> > > -fno-strict-overflow -fPIC -Wl,-z,defs -Wl,--as-needed -pthread -o birdc 
> > > obj/client/commands.o obj/client/util.o obj/client/client.o 
> > > obj/client/birdc.o -lreadline -ltinfo
> > > collect2: error: ld returned 1 exit status
> 
> this got fixed upstream in:
> 
> https://gitlab.nic.cz/labs/bird/-/commit/4bbc1061
> 
> With this patch bird2 compiles in my sbuild chroot.
> 
> Please also keep https://salsa.debian.org/debian/bird2 synchronized; it
> is missing the 2.0.7-4 upload.

In consideration of the nearing freeze and the fix being applied
upstream, I took the opportunity to prepare a NMU and upload it without
delay. The debdiff is attached.

Since https://salsa.debian.org/debian/bird2 lacks the commits for the
last upload (2.0.7-4) I did not commit my changes to the repository, but
attach them as patches to this mail. Then you can apply them with
"git am" once you pushed the changes for 2.0.7-4.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru bird2-2.0.7/debian/changelog bird2-2.0.7/debian/changelog
--- bird2-2.0.7/debian/changelog	2020-05-11 10:29:24.0 +0200
+++ bird2-2.0.7/debian/changelog	2021-01-02 18:12:44.0 +0100
@@ -1,3 +1,10 @@
+bird2 (2.0.7-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix collect2: error: ld returned 1 exit status (Closes: #966906)
+
+ -- Benjamin Drung   Sat, 02 Jan 2021 18:12:44 +0100
+
 bird2 (2.0.7-4) unstable; urgency=medium
 
   * Sync the linuxdoc mangled files with linuxdoc-tools_0.9.73-2
diff -Nru bird2-2.0.7/debian/patches/0002-Added-missing-extern.patch bird2-2.0.7/debian/patches/0002-Added-missing-extern.patch
--- bird2-2.0.7/debian/patches/0002-Added-missing-extern.patch	1970-01-01 01:00:00.0 +0100
+++ bird2-2.0.7/debian/patches/0002-Added-missing-extern.patch	2021-01-02 18:12:14.0 +0100
@@ -0,0 +1,33 @@
+From 4bbc10614f3431c37e6352f5a6ea5c693c31021e Mon Sep 17 00:00:00 2001
+From: Maria Matejka 
+Date: Tue, 4 Feb 2020 10:11:16 +0100
+Subject: Added missing extern
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Thanks to Robert Scheck  who reported it
+and Toke Høiland-Jørgensen  who suggested this patch.
+
+Bug-Debian: https://bugs.debian.org/966906
+Origin: https://gitlab.nic.cz/labs/bird/-/commit/4bbc1061
+---
+ nest/route.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/nest/route.h b/nest/route.h
+index d2a07f09..b927db5f 100644
+--- a/nest/route.h
 b/nest/route.h
+@@ -458,7 +458,7 @@ typedef struct rta {
+ 	   protocol-specific metric is availabe */
+ 
+ 
+-const char * rta_dest_names[RTD_MAX];
++extern const char * rta_dest_names[RTD_MAX];
+ 
+ static inline const char *rta_dest_name(uint n)
+ { return (n < RTD_MAX) ? rta_dest_names[n] : "???"; }
+-- 
+2.27.0
+
diff -Nru bird2-2.0.7/debian/patches/series bird2-2.0.7/debian/patches/series
--- bird2-2.0.7/debian/patches/series	2020-05-11 10:29:24.0 +0200
+++ bird2-2.0.7/debian/patches/series	2021-01-02 18:11:46.0 +0100
@@ -1 +1,2 @@
 0001-Sync-the-linuxdoc-mangled-files-with-linuxdoc-tools_.patch
+0002-Added-missing-extern.patch
From 435a53bda9e4cda61da61362069ebb4e59042e07 Mon Sep 17 00:00:00 2001
From: Benjamin Drung 
Date: Sat, 2 Jan 2021 18:12:24 +0100
Subject: [PATCH 1/2] Added missing extern
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Thanks to Robert Scheck  who reported it
and Toke Høiland-Jørgensen  who suggested this patch.

Bug-Debian: https://bugs.debian.org/966906
Origin: https://gitlab.nic.cz/labs/bird/-/commit/4bbc1061
---
 .../patches/0002-Added-missing-extern.patch   | 33 +++
 debian/patches/series |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 debian/patches/0002-Added-missing-extern.patch

diff --git a/debian/patches/0002-Added-missing-extern.patch b/debian/patches/0002-Added-missing-extern.patch
new file mode 100644
index 000..1daaf43
--- /dev/null
+++ b/debian/patches/0002-Added-missing-extern.patch
@@ -0,0 +1,33 @@
+From 4bbc10614f3431c37e6352f5a6ea5c693c31021e Mon Sep 17 00:00:00 2001
+From: Maria Matejka 
+Date: Tue, 4 Feb 2020 10:11:16 +0100
+Subject: Added missing 

Bug#979097: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: teg
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libeditreadline-dev links with the BSD-licensed 
libedit library which is a readline replacement.

Bug#979096: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: omake
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libeditreadline-dev links with the BSD-licensed 
libedit library which is a readline replacement.

Bug#979095: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: multipath-tools
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libeditreadline-dev links with the BSD-licensed 
libedit library which is a readline replacement.

Bug#979094: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: jackd2
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libeditreadline-dev links with the BSD-licensed 
libedit library which is a readline replacement.

Bug#979093: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: grads
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libeditreadline-dev links with the BSD-licensed 
libedit library which is a readline replacement.

Bug#979091: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: ctsim
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libeditreadline-dev links with the BSD-licensed 
libedit library which is a readline replacement.

Bug#979092: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: ferret-vis
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libeditreadline-dev links with the BSD-licensed 
libedit library which is a readline replacement.

Bug#979090: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

Package: avrdude
Severity: important

This package depends on libreadline8 which is GPL-3+ licensed. According 
to debian/copyright parts of your package are GPL-2-only licensed. If 
that is also (transitively) the case for the binaries that link with 
libreadline.so.8 it might be legally problematic (see 
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).


There is an easy solution to the problem: Replacing the build dependency 
libreadline-dev with libeditreadline-dev links with the BSD-licensed 
libedit library which is a readline replacement.

Bug#979089: clevis-tpm2: The /dev/fd fix left clevis-decrypt-tpm2 broken

[Gábor Gombás]

Package: clevis-tpm2
Version: 15-2
Severity: important
Tags: patch

Hi,

Thanks for updating clevis to version 15. However, the patch which was
meant to fix the use of /dev/fd left clevis-decrypt-tpm2 broken, because
the workaround for "exec" not triggering the EXIT trap was left in
place, and the on_exit function is a bit too picky. This additional
patch makes TPM2 unlocking in the initramfs work:

--- clevis-decrypt-tpm2.orig2021-01-02 17:55:37.257186026 +0100
+++ clevis-decrypt-tpm2 2021-01-02 17:55:47.281266001 +0100
@@ -165,9 +165,5 @@
 exit 1
 fi
 
-# The on_exit() trap will not be fired after exec, so let's clean up the temp
-# directory at this point.
-[ -d "${TMP}" ] && rm -rf "${TMP}"
-
 (echo -n "$jwk$hdr."; /bin/cat) | jose jwe dec -k- -i-
 exit $?

Regards,
Gabor

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

Kernel: Linux 5.9.16 (SMP w/8 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clevis-tpm2 depends on:
pn  clevis  
ii  tpm2-tools  5.0-1

Versions of packages clevis-tpm2 recommends:
ii  cryptsetup-bin  2:2.3.4-1

clevis-tpm2 suggests no packages.

Bug#978932: sympa: webinterface broken after installing 6.2.40~dfsg-1+deb10u1

[Sylvain Beucler]

Hi,

This looks like a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972189
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972189#45

In the buster version though, CGI mode (which fcgiwrap emulates) was 
removed from Sympa hence why I didn't add the same NEWS note as in 
stretch. It looks like this was still working somehow.


For the record here is the NEWS note:

The fix for the CVE-2020-10936 security issue forced us to drop CGI
mode for wwsympa earlier than officially (6.2.24).

In particular, users of nginx+fcgiwrap are invited to switch to
nginx+spawn-fcgi:

https://sympa-community.github.io/manual/install/configure-http-server-spawnfcgi.html

See also:
https://bugs.debian.org/972189
https://github.com/sympa-community/sympa/issues/1020

Cheers!
Sylvain

On 31/12/2020 17:41, Tobias Frost wrote:

Package: sympa
Version: 6.2.40~dfsg-1+deb10u1
Severity: important

Dear Maintainer,

After installation of the security update the web isterface is defunct.
It still loads the "default" site (here: https://$DOMAIN/wws/) but that also
the site that will be loaded when selecting an menue entry, for example "Login".
(IOW, Login not possible as the login form is not presented)

Downgrading to 6.2.40~dfsg-1 makes it work again.

Webserver is an nginx instance.

The only hint I got (could be a red herring) is this in the nginx error log,
the sympa log is silent…

Heres a example of the  nginx one:
(There are many of those…)

2020/12/27 12:13:57 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun 
Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value in string ne at 
/usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M
[Sun Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value $remote_addr in string ne at 
/usr/share/sympa/lib/Sympa/WWW/Session.pm line 408" while reading upstream, client: 80.209.204.233, server: 
lists.regensburg-repariert.de, request: "GET /wws/reviewbouncing/info HTTP/2.0", upstream: 
"fastcgi://unix:/run/fcgiwrap.socket:", host: "lists.regensburg-repariert.de"
2020/12/27 12:14:21 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun 
Dec 27 12:14:21 2020] wwsympa.fcgi: Use of uninitialized value in string ne at 
/usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M

(Those started exactly on Dec 24, after unattende-upgrades pulled in the 
security update)

Let me know if I can provide more information…

Cheers,

Bug#957045: bird: ftbfs with GCC-10

[Benjamin Drung]

Hi Ondřej,

On Fri, 17 Apr 2020 10:57:13 + Matthias Klose  wrote:
> Package: src:bird
> Version: 1.6.8-1
> 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.
> 
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc10-20200225/bird_1.6.8-1_unstable_gcc10.log
> The last lines of the build log are at the end of this report.

In consideration of the nearing freeze and the fix being applied
upstream, I took the opportunity to prepare a NMU and upload it without
delay. I also couldn't resist to address the lintian warning about
upstart. The debdiff is attached.

Since https://salsa.debian.org/debian/bird lacks the commits for the
last upload (1.6.8-2) I did not commit my changes to the repository, but
attach them as patches to this mail. Then you can apply them with
"git am" once you pushed the changes for 1.6.8-2.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru bird-1.6.8/debian/bird.bird6.upstart bird-1.6.8/debian/bird.bird6.upstart
--- bird-1.6.8/debian/bird.bird6.upstart	2020-05-11 10:27:20.0 +0200
+++ bird-1.6.8/debian/bird.bird6.upstart	1970-01-01 01:00:00.0 +0100
@@ -1,18 +0,0 @@
-# bird - BIRD Internet Routing Daemon (IPv6)
-
-description "BIRD Internet Routing Daemon (IPv6)"
-author "Ondřej Surý "
-
-start on runlevel [2345]
-stop on runlevel [016]
-
-respawn
-pre-start script
-/usr/lib/bird/prepare-environment
-/usr/sbin/bird6 -p
-end script
-
-script
-. /etc/bird/envvars
-exec /usr/sbin/bird6 -f -u $BIRD_RUN_USER -g $BIRD_RUN_GROUP $BIRD_ARGS
-end script
diff -Nru bird-1.6.8/debian/bird.bird.upstart bird-1.6.8/debian/bird.bird.upstart
--- bird-1.6.8/debian/bird.bird.upstart	2020-05-11 10:27:20.0 +0200
+++ bird-1.6.8/debian/bird.bird.upstart	1970-01-01 01:00:00.0 +0100
@@ -1,18 +0,0 @@
-# bird - BIRD Internet Routing Daemon (IPv4)
-
-description "BIRD Internet Routing Daemon (IPv4)"
-author "Ondřej Surý "
-
-start on runlevel [2345]
-stop on runlevel [016]
-
-respawn
-pre-start script
-/usr/lib/bird/prepare-environment
-/usr/sbin/bird -p
-end script
-
-script
-. /etc/bird/envvars
-exec /usr/sbin/bird -f -u $BIRD_RUN_USER -g $BIRD_RUN_GROUP $BIRD_ARGS
-end script
diff -Nru bird-1.6.8/debian/changelog bird-1.6.8/debian/changelog
--- bird-1.6.8/debian/changelog	2020-05-11 10:27:20.0 +0200
+++ bird-1.6.8/debian/changelog	2021-01-02 17:40:39.0 +0100
@@ -1,3 +1,11 @@
+bird (1.6.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix compilation with GCC 10 (Closes: #957045)
+  * Remove obsolete upstart files
+
+ -- Benjamin Drung   Sat, 02 Jan 2021 17:40:39 +0100
+
 bird (1.6.8-2) unstable; urgency=medium
 
   * Sync the linuxdoc mangled files with linuxdoc-tools_0.9.73-2
diff -Nru bird-1.6.8/debian/patches/0004-Unix-fix-compilation-with-GCC-10.patch bird-1.6.8/debian/patches/0004-Unix-fix-compilation-with-GCC-10.patch
--- bird-1.6.8/debian/patches/0004-Unix-fix-compilation-with-GCC-10.patch	1970-01-01 01:00:00.0 +0100
+++ bird-1.6.8/debian/patches/0004-Unix-fix-compilation-with-GCC-10.patch	2021-01-02 17:33:44.0 +0100
@@ -0,0 +1,34 @@
+From e4f91ee4cb11a10df6a61ab4ffcdc8e2da3c3483 Mon Sep 17 00:00:00 2001
+From: Vincent Bernat 
+Date: Mon, 28 Sep 2020 16:30:56 +0200
+Subject: Unix: fix compilation with GCC 10
+
+GCC 10 will now error when declaring a global variable twice:
+
+  https://gcc.gnu.org/gcc-10/porting_to.html#common
+
+Fix this issue by declaring the variable as `extern' in `krt.h'.
+The variable is really declared in `krt.c'.
+
+Bug-Debian: https://bugs.debian.org/957045
+Origin: upstream, https://gitlab.nic.cz/labs/bird/-/commit/e4f91ee4cb11a10df6a61ab4ffcdc8e2da3c3483
+---
+ sysdep/unix/krt.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sysdep/unix/krt.h b/sysdep/unix/krt.h
+index d4a8717e..fe79efc3 100644
+--- a/sysdep/unix/krt.h
 b/sysdep/unix/krt.h
+@@ -112,7 +112,7 @@ struct kif_proto {
+   struct kif_state sys;		/* Sysdep state */
+ };
+ 
+-struct kif_proto *kif_proto;
++extern struct kif_proto *kif_proto;
+ 
+ #define KIF_CF ((struct kif_config *)p->p.cf)
+ 
+-- 
+2.27.0
+
diff -Nru bird-1.6.8/debian/patches/series bird-1.6.8/debian/patches/series
--- bird-1.6.8/debian/patches/series	2020-05-11 10:27:20.0 +0200
+++ bird-1.6.8/debian/patches/series	2021-01-02 17:33:57.0 +0100
@@ -1,3 +1,4 @@
 0001-Link-using-ld.patch
 

Bug#923198: would it work with elogind?

[Mark Hindley]

Sven,

Sorry about the slow reply with this.

On Mon, Sep 30, 2019 at 08:41:41PM +0200, Sven Joachim wrote:
> > But, instead of removing, you can change:
> > Recommends: libpam-systemd
> > to
> > Recommends: default-logind | logind
> >
> > which works nicely with elogind.
> 
> Makes sense.  Can you confirm that rootless X works with elogind?
> Use gdm3 as display manager, or startx and no display manager.

I can confirm that rootless X works with elogind using startx.

I hope that will enable you to make this change.

Thanks

Mark

Bug#881761: signon-plugin-oauth2 FTCBFS: does not pass cross tools to qmake and other issues

[Pino Toscano]

Hi Helmut,

In data martedì 14 novembre 2017 22:32:01 CET, Helmut Grohne ha scritto:
> Source: signon-plugin-oauth2
> Version: 0.22-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> signon-plugin-oauth2 fails to cross build from source for multiple
> reasons:
>  * It does not pass cross tools to qmake. This task can be easily
>deferred to dh_auto_configure these days, but it doesn't fully work,
>so in the best case dh_auto_build will fail until debhelper is fixed.

This was a bug, even more problematic than just for cross-building.
I included this part in my recent signon-plugin-oauth2 0.25-1 upload.

>  * It uses uname -m to discover the host cpu, but that returns the build
>cpu of course.
>  * It uses plain pkg-config, which is the build architecture pkg-config
>while the host architecture one was expected.

These two look like genuine bugs as well. Can you please send them as
merge requests to the upstream repository?
https://gitlab.com/accounts-sso/signon-plugin-oauth2
Upstream accepts MRs, so it should be easy to send them patches.
I'd rather not include patches downstream that are kept there forever,
adding more work to the already small enough attention that this package
(and other Accounts SSO packages) already gets...

Thanks in advance,
-- 
Pino Toscano

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

Bug#979088: plasma-applet-redshift-control: redshift

[Josef Kufner]

Package: plasma-applet-redshift-control
Version: 1.0.18+phabricator~2019080100-1
Severity: important

Dear Maintainer,

redshift package adds systemd user unit to start redshift in the session
automatically, which makes the redshift run twice using different
configuration.

This is related to #979075 and #979076.

I guess some kind of per-session shared configuration should be implemented to
make sure the redshift runs only once and with the desired configuration.

Workaround: systemctl stop redshift.service --user && systemctl disable
redshift.service --user



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=cs:en_US:en_GB
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-applet-redshift-control depends on:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4
ii  redshift1.12-4

plasma-applet-redshift-control recommends no packages.

plasma-applet-redshift-control suggests no packages.

-- no debconf information

Bug#978431: texlive-base: dist-upgrade buster->bullseye fails

[Hilmar Preuße]

Am 31.12.2020 um 08:46 teilte Rene Engelhard mit:

Hi,


Just by chance.

My normal buster system dist-upgrade to bullseye.

Just found [1] Seems to be the only conflict in TL. I'll try to look 
into this.


Hilmar

[1] https://piuparts.debian.org/stable2sid/source/t/texlive-extra.html
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#979074: buster-pu: package gnutls28/3.6.7-4+deb10u6

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-01-02 at 15:17 +0100, Andreas Metzler wrote:
> The gnutls28 test tests/testpkcs11.sh uses a test certificate that
> expired in December 2020, which now causes a testsuite error and
> FTBFS.
> If this is not approved the patch will need to be included in case of
> another DSA for GnuTLS or a stable update. I would rather fix this
> now
> to make debian-security's life easier.
> 

Please go ahead.

Regards,

Adam

Bug#979049: marco: debian/rules do not clean source tree

[Mike Gabriel]

Control: severity -1 minor

Hi Nicholas,

On  Sa 02 Jan 2021 12:29:53 CET, Nicholas Guriev wrote:


Source: marco
Version: 1.24.1-1
Severity: serious
Dear Maintainer,

After the following commands run in an package tree dpkg-source sees source
modifications.

export DEB_BUILD_OPTIONS="parallel=4"
debian/rules build
debian/rules clean

Full difference between unpacked directory and after built & clean  
is attached.

It was obtained with `diff -U3 -r`.

The bug has serious severity level because of volition "must" clause  
in §4.9 of

Debian Policy Manual.


clean (required)

This must undo any effects that the build and binary targets may  
have had ...


However, the bug has no impact on end users so I think in the future its
severity may be lowered to minor.


Currently, it is not release critical if packages don't build and  
clean up afterwards in an idempotent way. Although, it is something  
nice-to-have.


Thus, lowering severity immediately to minor.

Mike
--

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

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



pgpwGRQTFivPZ.pgp
Description: Digitale PGP-Signatur

Bug#979043: transition: dart

[Sebastian Ramacher]

Control: tags -1 + confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/auto-dart.html

On 2021-01-02 12:20:52 +0100, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I would like to transition the dart library. I've successfully rebuild
> and tested it's only reverse build dependency: gazebo.
> 
> The automatically generated ben file looks fine.

Please go ahead.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature