Bug#982273: libbsd0-udeb: depends on libmd0

[Andrei POPESCU]

Control: reassign -1 src:libbsd 0.11.1-1

On Lu, 08 feb 21, 02:25:01, Samuel Thibault wrote:
> Source: libbsd0-udeb

The BTS interprets this as Package: src:libbsd0-udeb (which doesn't 
exist).

> Version: 0.11.1-1
> Severity: serious
> Justification: makes debian-installer FTBFS
> 
> Hello,
> 
> The "new upstream" upload of libbsd builds a udeb that depends on a
> non-udeb:
> 
> The following packages have unmet dependencies:
>  libbsd0-udeb : Depends: libmd0 (>= 1.0.3) but it is not installable
> 
> Please avoid linking against libmd0, or else add a libmd0-udeb package
> to libmd.
> 
> 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-1-amd64 (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 /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -- 
> Samuel
> c> ah (on trouve fluide glacial sur le net, ou il faut aller dans le monde 
> reel ?)
> s> dans le monde reel
> c> zut

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#982280: ssl-cert: buster needs latest version

[Francesco Potortì]

Package: ssl-cert
Version: 1.1.0
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

I just upgraded a stretch installation to buster and subvesion does not
work because of too short a snakeoil key

I solved teh problem by installing this version by hand

Please backport this version to buster

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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 ssl-cert depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  openssl1.1.1i-3

ssl-cert recommends no packages.

ssl-cert suggests no packages.

-- debconf information:
  make-ssl-cert/altname:
  make-ssl-cert/vulnerable_prng:
  make-ssl-cert/hostname: localhost
  make-ssl-cert/title:

Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change

[Rene Engelhard]

Hi,

Am 08.02.21 um 03:15 schrieb Paul Wise:

> Tags: patch

No, No patch.

patch does not  mean "add a ?" but if at all someting like this

$ git diff sysui/desktop/apparmor/program.soffice.bin
diff --git a/sysui/desktop/apparmor/program.soffice.bin
b/sysui/desktop/apparmor/program.soffice.bin
index 42053db2abef..83bd9d11f93c 100644
--- a/sysui/desktop/apparmor/program.soffice.bin
+++ b/sysui/desktop/apparmor/program.soffice.bin
@@ -101,7 +101,7 @@ profile libreoffice-soffice
INSTDIR-program/soffice.bin {
   owner @{libo_user_dirs}/**/   rw,  #allow creating
directories that we own
   owner @{libo_user_dirs}/**~lock.* rw,  #lock file support
   owner @{libo_user_dirs}/**.@{libreoffice_ext} rwk,  #Open files rw
with the right exts
-  owner @{libo_user_dirs}/{,**/}lu??{,?}.tmp rwk, #Temporary
file used when saving
+  owner @{libo_user_dirs}/{,**/}lu???{,?}.tmp rwk, #Temporary
file used when saving
   owner @{libo_user_dirs}/{,**/}.directory r, #Read directory settings
on KDE
 
   # Settings
(Which is even trivially to do in /etc/apparmor.d if you don't know the
source path. This won
t necessarily help since the path is there in the generated file but if
yoz're lucky and are far away "enough" from the profile path..)


Not removing the patch since it's now actually has one..

> When I open a document in my home directory in libreoffice I get this:
>
>Feb 08 08:08:48 audit[474619]: AVC apparmor="DENIED" operation="open" 
> profile="libreoffice-soffice" name="/home/pabs/lu474619vthyvt.tmp" pid=474619 
> comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000

Didn't you already ask on IRC some weeks ago about this?


Did you manually set it to enabled from the default complain-only mode
or how did the soffice.bin get into complain mode?

> The reason is that this rule allowing temporary files is too short:
>
>  owner @{libo_user_dirs}/{,**/}lu??{,?}.tmp rwk, #Temporary file 
> used when saving
>
> Adding one more possible temporary filename length fixes the denial:
>
>  owner @{libo_user_dirs}/{,**/}lu??{,?,??}.tmp rwk, #Temporary 
> file used when saving

Did you change it or do you mean upstream did?

Addendum: Yes, apprarently something changed and it got hidden due to it
being complain-only.

Indeed I get ALLOWED entries in the log.


Regards,


Rene

Bug#981804: yubioath-desktop: fails to read yubikey

[andrew]

Any chance this bug is the root cause of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982157 ?

Bug#982160: sudo does not honour "NOPASSWD" directive

[Bdale Garbee]

Wolfgang Sourdeau  writes:

> [myuser] ALL=(ALL) NOPASSWD: ALL

Try

  [myuser] ALL=(ALL:ALL) NOPASSWD: ALL

Bdale


signature.asc
Description: PGP signature

Bug#982279: texlive-latex-extra: hyperref and dinbrief are incompatible

[Joachim Zobel]

Package: texlive-latex-extra
Version: 2020.20210202-1
Severity: normal

Dear Maintainer,

I found it impossible to use \href inside of a dinbrief document. A MWE is
attached.



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1699 Feb  7 13:41 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jun  8  2020 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jan 13 22:27 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jan 13 22:27 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Sep  9 07:50 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jan 13 22:27 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jan 13 22:27 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3106 Feb  7 13:41 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 17  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Sep  9 07:50 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 texlive-latex-extra depends on:
ii  libcommons-logging-java1.2-2
ii  libpdfbox-java 1:1.8.16-2
ii  preview-latex-style12.2-1
ii  python33.9.1-1
ii  tex-common 6.15
ii  texlive-base   2020.20210113-1
ii  texlive-binaries   2020.20200327.54578-6
ii  texlive-latex-recommended  2020.20210113-1
ii  texlive-pictures   2020.20210113-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2020.20210113-1
ii  texlive-plain-generic  2020.20210202-1

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.23-1
pn  libspreadsheet-parseexcel-perl  
ii  python3-pygments2.7.1+dfsg-1
ii  texlive-latex-extra-doc 2020.20210202-1

Versions of packages tex-common depends on:
ii  dpkg  1.20.7.1
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.3.3

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.15
ii  texlive-binaries  2020.20200327.54578-6

-- no debconf information
%
% vim: set spell spelllang=de:
\documentclass[]{dinbrief}
% \documentclass[]{article}

\usepackage{hyperref}

\begin{document}

\href{http://qa.debian.org/}{Link}.

\end{document}

PWD /home/jo/Dokumente/Bewerbungen
INPUT /etc/texmf/web2c/texmf.cnf
INPUT 

Bug#982278: u-boot-install-sunxi risks overwriting files in current directory

[harry88]

Package: u-boot-sunxi
Version: 2021.01~rc4+dfsg-1
Severity: important
Tags: patch

Hi Vagrant,

Salsa commit 4f2f06b8 for the u-boot package introduced a bug in the
u-boot-install-sunxi script that could inadvertently overwrite the
user's own files.  By removing the "mktemp -d" and the "cd", it means
the "mbr-sign" and "gpt-sign" files now get created in the current
directory, which would be unfortunate if there happened to be any user
files with those names.

A patch to fix the problem is below.  It has previously appeared in
bug#979688 as part of a larger patch intended to continue the
simplifying work begun with commit 4f2f06b8.

Best wishes,
Harold.

diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index 4f80e01099..6840a62696 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -63,15 +63,13 @@ fi
 if [ -z "$FORCE" ]; then
 # A very simple sanity check.  GPT mandates a "protective MBR" so this 
works
 # even with GPT partitioning.
-printf '%b' '\0125\0252' >mbr-sign
-if ! cmp -s -i 0:510 -n 2 mbr-sign "$DEV"; then
+if ! printf '\125\252' | cmp -s -i 0:510 -n 2 - "$DEV"; then
echo >&2 "$0: device/image ($DEV) has no MBR partition table"
exit 1
 fi

 # But, on sunxi64, spl will trample upon GPT.
-printf "EFI PART" >gpt-sign
-if cmp -s -i 0:512 -n 8 gpt-sign "$DEV"; then
+if printf 'EFI PART' | cmp -s -i 0:512 -n 8 - "$DEV"; then
echo >&2 "$0: device/image ($DEV) uses GPT partition table, unusable on 
sunxi64"
exit 1
 fi

Bug#942988: Is there any forward movement on this bug?

[Charlie Hagedorn]

I've been a happy user of dispcalgui for years. I just rebooted my machine
(Debian testing, uptime > 140 days) and went to recalibrate, only to find
that displaycal had disappeared.

Looking at this thread upstream ( https://hub.displaycal.net/issue/17813/ )
it appears that the ETA for a port to Python3 is somewhere between 1/1/2020
and "when it's done".

As far as I am aware, displaycal is the premier display calibration gui for
linux. It works and works well. How can we help upstream bring it into
alignment with Debian requirements? Is a beta python3 port available for
community contributions/testing/debugging? Will donations help free up
upstream-maintainer's time to finish the port?

In the interim -- are there any workarounds for both generating new monitor
profiles and installing them?  Is calibration straightforward for a Spyder
5 via ArgyllCMS and the command line? A quick survey suggests I have a
bunch of unexpected learning to do.

Thanks!

Charlie

Bug#962844: mdadm: Assembling RAID using IMSM in initrd fails due to lack of module efivarfs

[Felix Lechner]

Hi Chris,

On Sun, Feb 7, 2021 at 9:22 AM Chris Hofstaedtler  wrote:
>
> friendly ping here, are you planning to fix this for bullseye?

Thanks for the reminder! I will probably include efivars in the next
couple of days.

Kind regards
Felix

Bug#982277: zfs-dkms: ZFS is not validating checksums on file read.

[Stefan Arnold]

Package: zfs-dkms
Version: 0.8.6-1~bpo10+1
Severity: important
Tags: upstream

ZFS seems to not recognize data errors without doing a scrub.

Steps to reproduce:
- create a small partition (1GB)
- "zpool create -m /zfs zfspool /dev/..."
- create a 800MB testfile "dd if=/dev/zero of=/zfs/testfile bs=1M count=800"
- "shasum /zfs/testfile" -> checksum A
- change a byte somwhere in /dev/...
- empty caches "sync; echo 3 > /proc/sys/vm/drop_caches"
- "shasum /zfs/testfile" -> checksum B
- "zpool status" shows no errors
- checksums A and B differ, the file is corrupted without being noticed
- do "zpool scrub zfspool"
- "zpool status" shows the error

Version 2.0.2 has the same issue. According to another guy version 0.8.4 from
Ubuntu is not affected.



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

Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  dkms   2.6.1-4
ii  file   1:5.35-4+deb10u2
ii  libc6-dev [libc-dev]   2.28-10
ii  libpython3-stdlib  3.7.3-1
ii  lsb-release10.2019051400
ii  perl   5.28.1-6+deb10u1
ii  python3-distutils  3.7.3-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  4.19.171-2
pn  zfs-zed 
pn  zfsutils-linux  

Versions of packages zfs-dkms suggests:
ii  debhelper  12.1.1

-- debconf information excluded

Bug#982276: htmldoc: please migrate to fltk1.3

[Aaron M. Ucko]

Source: htmldoc
Version: 1.9.11-1
Severity: normal

htmldoc still builds against FLTK 1.1, for which it is long past
time for Debian to drop support.  Please migrate to 1.3, which is
likely as simple as adjusting htmldoc's build dependencies and
ensuring that it uses UTF-8 rather than a legacy text encoding.

Also, please note that fltk-config (in both branches) differs from
typical *-config scripts in having --libs yield paths to *static*
libraries.  If your build has been making use of this syntax, please
substitute --ldflags to obtain proper dynamic linkage.  (FLTK does not
yet offer pkg-config metadata, sorry.)

For more details, please see the debian-devel thread starting at
https://lists.debian.org/msgid-search/udl1rh34720@ucko.debian.net.
(I'd omitted htmldoc from the initial crop of reports because it was
orphaned at the time and as such eligible for a QA upload.  Now that
you've adopted the package, this migration formally falls to you.)

Thanks!

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

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

-- no debconf information

Bug#982275: debianutils: add-shell depends on non-essential package

[Michael Gilbert]

package: src:debianutils
severity: serious
version: 4.11.2
tag: patch

debianutil's add-shell script uses awk, but awk is not an
Essential:yes package.  For systems where awk is not yet installed
(chroots), installation of dash will currently fail since it's
postinst calls add-shell from debianutils.

A simple fix seems possible, just change add-shell to use cat, which
is in coreutils (Essential:yes).  Proposed update attached.

Best wishes,
Mike
--- debianutils-4.11.2/add-shell	2020-05-22 20:00:40.0 -0400
+++ debianutils-4.11.3/add-shell	2021-02-07 21:47:27.0 -0500
@@ -17,7 +17,7 @@
 }
 trap cleanup EXIT
 
-if ! awk '{print}' "$file" > "$tmpfile"
+if ! cat "$file" > "$tmpfile"
 then
 cat 1>&2 <

Bug#982059: And another file conflict: /usr/share/man/de/man1/killall.1.gz

[Daniel Leidert]

And yet another file conflict with manpages-de:

[..]
dpkg: error processing archive /var/cache/apt/archives/psmisc_23.4-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/share/man/de/man1/killall.1.gz', which is also in 
package manpages-de 4.2.0-1
[..]

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change

[Paul Wise]

Package: libreoffice-common
Version: 1:7.0.4-3
Severity: important
File: /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin
Usertags: apparmor
Tags: patch

When I open a document in my home directory in libreoffice I get this:

   Feb 08 08:08:48 audit[474619]: AVC apparmor="DENIED" operation="open" 
profile="libreoffice-soffice" name="/home/pabs/lu474619vthyvt.tmp" pid=474619 
comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000

The reason is that this rule allowing temporary files is too short:

 owner @{libo_user_dirs}/{,**/}lu??{,?}.tmp rwk, #Temporary file 
used when saving

Adding one more possible temporary filename length fixes the denial:

 owner @{libo_user_dirs}/{,**/}lu??{,?,??}.tmp rwk, #Temporary file 
used when saving

I expect that just switching to a wildcard would work too and would be
much more likely to continue working if LibreOffice update the length.

 owner @{libo_user_dirs}/{,**/}lu??*.tmp rwk, #Temporary file used 
when saving

-- Package-specific info:

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-common depends on:
ii  libnumbertext-data 1.0.7-1
ii  libreoffice-style-colibre  1:7.0.4-3
ii  ucf3.0043
ii  ure1:7.0.4-3

Versions of packages libreoffice-common recommends:
ii  apparmor   2.13.6-7
pn  fonts-liberation2 | ttf-mscorefonts-installer  
ii  libexttextcat-data 3.4.5-1
ii  python3-uno1:7.0.4-3
ii  xdg-utils  1.1.3-2

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-colibre [libreoffice-style]  1:7.0.4-3

Versions of packages python3-uno depends on:
ii  libc62.31-9
ii  libgcc-s110.2.1-6
ii  libpython3.9 3.9.1-3
ii  libreoffice-core 1:7.0.4-3
ii  libstdc++6   10.2.1-6
ii  libuno-cppu3 1:7.0.4-3
ii  libuno-cppuhelpergcc3-3  1:7.0.4-3
ii  libuno-sal3  1:7.0.4-3
ii  libuno-salhelpergcc3-3   1:7.0.4-3
ii  python3  3.9.1-1
ii  python3.93.9.1-3
ii  ucf  3.0043
ii  uno-libs-private 1:7.0.4-3

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#982147: mgba: Please provide a libmgba-dev package

[Ryan Tandy]

On Mon, Feb 08, 2021 at 01:59:46AM +0100, Celelibi wrote:

I opened a github issue asking for an official stance.
https://github.com/mgba-emu/mgba/issues/2042


Great - I'm happy to go ahead with this based on endrift's response 
there. Thank you for driving this!


I'm afraid it's too late to have this for Debian 11 (bullseye), but I 
can work on the changes in a git branch during the freeze.


Ryan

Bug#980930: Triggers network access, not suitable to build manpages in Debian (policy 4.9)

[Matthew Peveler]

Hello Christoph,

I am the upstream maintainer of asciidoc, and trying to understand what
changes might be necessary there to comply with Debian if possible.

As part of a2x, there is already a way to specify non-default options to
xsltproc during execution, by using the "--xsltproc-opts" option. Usage
then for using --nonet for your example would be:

a2x -f manpage --no-xmllint --xsltproc-opts --nonet .adoc

Does this meet the needs of Debian, or is is that that a2x must specify
`--nonet` for xsltproc by default, and that using the network have to be
opt-in?

Regards,
Matthew Peveler

Bug#982273: libbsd0-udeb: depends on libmd0

[Samuel Thibault]

Source: libbsd0-udeb
Version: 0.11.1-1
Severity: serious
Justification: makes debian-installer FTBFS

Hello,

The "new upstream" upload of libbsd builds a udeb that depends on a
non-udeb:

The following packages have unmet dependencies:
 libbsd0-udeb : Depends: libmd0 (>= 1.0.3) but it is not installable

Please avoid linking against libmd0, or else add a libmd0-udeb package
to libmd.

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-1-amd64 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
c> ah (on trouve fluide glacial sur le net, ou il faut aller dans le monde reel 
?)
s> dans le monde reel
c> zut

Bug#982272: Grammar of "xx packages upgraded..."

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.13-2+b1
Severity: minor

If you think about it, the grammar of

   # aptitude install some_package
   ...
   0 packages upgraded, 22 newly installed, 0 to remove and 0 not upgraded.
AA  BBC   

is weird.

AA, BB, DD are past tense, CC is future tense, or something like that.
So to make them all agree, CC should be "removed".
Or even more accurate, instead, AA should be "to upgrade", BB "to newly
install", and DD "to upgrade".

Bug#982147: mgba: Please provide a libmgba-dev package

[Celelibi]

Le Sun, Feb 07, 2021 at 02:50:28PM -0800, Ryan Tandy a écrit :
> On Sun, Feb 07, 2021 at 10:05:38PM +0100, Celelibi wrote:
> > The program I'm writing would be an IRC bot a-la twitch-plays-pokemon. I
> > don't think it would be a good candidate for inclusion in Debian as I
> > intend it to be a quick-and-dirty program for my specific needs.
> 
> OK. Sounds fun. :)
> 
> > I have no idea of an ABI compatibility policy. I'm not sure there's one
> > right now.
> 
> OK.
> 
> > However, the CMakeLists.txt already contains everything needed to
> > install headers. So I guess there's an intent toward this usage even if
> > the support (especially regarding ABI stability) isn't well thought out.
> 
> Sure. I didn't mean to suggest that the library isn't meant to be used. In
> fact, It looks like upstream's own .deb packages also include mgba-dev as
> well as libmgba. However, for publishing it in Debian, it needs to meet the
> requirements set by Debian policy for shared libraries. (And I'm not even
> saying that it doesn't, only that I don't know whether it does or not.)

I opened a github issue asking for an official stance.
https://github.com/mgba-emu/mgba/issues/2042

In the mean time, I found out how was the SONAME generated. It looks
like the ABI version is managed explicitely and used to produce a SONAME.
https://github.com/mgba-emu/mgba/blob/32a8a47d/CMakeLists.txt#L880
https://github.com/mgba-emu/mgba/blob/32a8a47d/version.cmake#L7

So I would expect a positive outcome soon.

Regards,
Celelibi

Bug#980122: tagging 980122

[Chris Hofstaedtler]

* Adrian Bunk wrote:
> tags 980122 + moreinfo

* Moritz Muehlenhoff wrote:
> depends on legacy packages (Py2, GTK2),
> is dead upstream

These points haven't changed, even with Adrian's NMU, right?

Chris

Bug#982271: ITP: buildlog-consultant -- builg log parser and analyser

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: buildlog-consultant
  Version : 0.0.1
  Upstream Author : Jelmer Vernooij 
* URL : https://github.com/jelmer/buildlog-consultant
* License : GPL
  Programming Lang: Python
  Description : build log parser and analyser

buildlog-consultant can parse build logs and highlight and extract
the key error lines. This can be used to display a snippet from a build
log with the actual problem.

This functionality is factored out from debian-janitor, and a dependency
for ognibuild.

Bug#948346: [PATCH] Ensure graceful signal handling when the pid file exists

[Chris Hofstaedtler]

* Eduard Bloch  [210208 00:43]:
> > Could you make an upload to DELAYED instead of further waiting?
> 
> I am no longer waiting, today is timeout day. Will use 7-DAY DELAYED
> queue, should be appropriate.

That upload somehow did not make it into the archive?

Chris

Bug#982270: installation-reports: Installing Debian Bullseye on Cubox-i4 - installer finds no ethernet

[Rick Thomas]

Package: installation-reports
Severity: important

Dear Maintainer,

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

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

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


-- Package-specific info:

Boot method: Followed the instruction in the README file
Image version:
https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
dated 2021-01-30 (also tried 2021-02-06)
Date: 2021-02-06

Machine: Cubox-i4P
Partitions: Didn't get that far in the installation

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ok]
Detect network card:[failed] could not proceed
Overall install:[failed ]

Comments/Problems:

I downloaded the two-part image from [1] dated 2021-01-30 and tried to 
install it on my Cubox-i4.

It booted fine but when it got to the "Detect network hardware" phase, 
it failed and said:

> No Ethernet card was detected. If you know the name of the driver 
> needed by your Ethernet card, you can select it from the list. 
> Driver needed by your Ethernet card:  

and gave a long list of available ethernet drivers, none of which seemed to be 
relevant.

I tried it again, this time with the components dated 2021-02-06.
I was hoping that the problem was transient and might have been fixed in
the intervening week, but I still got the same result: "No Ethernet card was 
detected."

Vagrant says:
> Pretty sure it is a kernel bug, since I can make it go away on a similar
> system by downgrading to linux 5.9.x. Please CC me on the report and
> I'll try to contribute what I can!

-- 

Log files attached to this report are from a successful Buster installation on 
the same hardware,
in hopes they might be some help...

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u7"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux cube 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) 
armv7l GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.19.0-13-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.19.0-13-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: dm_mod122880  9
lsmod: md_mod143360  0
lsmod: jfs   184320  0
lsmod: btrfs1241088  0
lsmod: libcrc32c  16384  1 btrfs
lsmod: xor16384  1 btrfs
lsmod: zstd_decompress61440  1 btrfs
lsmod: zstd_compress 159744  1 btrfs
lsmod: xxhash 20480  2 zstd_compress,zstd_decompress
lsmod: zlib_deflate   28672  1 btrfs
lsmod: raid6_pq   98304  1 btrfs
lsmod: vfat   24576  0
lsmod: fat73728  1 vfat
lsmod: ext4  618496  3
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2  102400  1 ext4
lsmod: crc32c_generic 16384  6
lsmod: fscrypto   28672  1 ext4
lsmod: ecb16384  0
lsmod: brcmfmac  253952  0
lsmod: brcmutil   16384  1 brcmfmac
lsmod: cfg80211  548864  1 brcmfmac
lsmod: rfkill 28672  1 cfg80211
lsmod: usb_storage53248  0
lsmod: sd_mod 49152  3
lsmod: ahci_imx   20480  2
lsmod: libahci_platform   20480  1 ahci_imx
lsmod: libahci32768  2 libahci_platform,ahci_imx
lsmod: libata208896  3 libahci_platform,libahci,ahci_imx
lsmod: scsi_mod  196608  3 sd_mod,usb_storage,libata
lsmod: sdhci_esdhc_imx24576  0
lsmod: sdhci_pltfm16384  1 sdhci_esdhc_imx
lsmod: sdhci  53248  2 sdhci_pltfm,sdhci_esdhc_imx
lsmod: ci_hdrc_imx16384  0
lsmod: ci_hdrc45056  1 ci_hdrc_imx
lsmod: ulpi   16384  1 ci_hdrc
lsmod: ehci_hcd   77824  1 ci_hdrc
lsmod: udc_core   36864  

Bug#982269: gdm3: "man gdm3" displays the man page for gdm-screenshot

[Russell Stuart]

Package: gdm3
Version: 3.38.2.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

"man gdm3" displays the man page for gdm-screenshot.1(8).

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

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

Versions of packages gdm3 depends on:
ii  accountsservice  0.6.55-3
ii  adduser  3.118
ii  cinnamon [x-window-manager]  4.8.6-1
ii  cinnamon-session [x-session-manager] 4.8.0-2
ii  dbus 1.12.20-1
ii  dconf-cli0.38.0-1
ii  dconf-gsettings-backend  0.38.0-1
ii  debconf [debconf-2.0]1.5.74
ii  gir1.2-gdm-1.0   3.38.2.1-1
ii  gnome-session [x-session-manager]3.38.0-3
ii  gnome-session-bin3.38.0-3
ii  gnome-session-common 3.38.0-3
ii  gnome-session-flashback [x-session-manager]  3.38.0-1
ii  gnome-settings-daemon3.38.1-3
ii  gnome-shell  3.38.3-1
ii  gnome-terminal [x-terminal-emulator] 3.38.2-1
ii  gsettings-desktop-schemas3.38.0-2
ii  konsole [x-terminal-emulator]4:20.12.1-1
ii  libaccountsservice0  0.6.55-3
ii  libaudit11:3.0-2
ii  libc62.31-9
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgdm1  3.38.2.1-1
ii  libglib2.0-0 2.66.6-1
ii  libglib2.0-bin   2.66.6-1
ii  libgtk-3-0   3.24.24-1
ii  libkeyutils1 1.6.1-2
ii  libpam-modules   1.4.0-2
ii  libpam-runtime   1.4.0-2
ii  libpam-systemd   247.3-1
ii  libpam0g 1.4.0-2
ii  librsvg2-common  2.50.3+dfsg-1
ii  libselinux1  3.1-2+b2
ii  libsystemd0  247.3-1
ii  libx11-6 2:1.7.0-2
ii  libxau6  1:1.0.9-1
ii  libxcb1  1.14-3
ii  libxdmcp61:1.1.2-3
ii  lsb-base 11.1.0
ii  metacity [x-window-manager]  1:3.38.0-2
ii  muffin [x-window-manager]4.8.1-1
ii  plasma-workspace [x-session-manager] 4:5.20.5-3
ii  policykit-1  0.105-30
ii  procps   2:3.3.16-5
ii  termit [x-terminal-emulator] 3.1-1
ii  ucf  3.0043
ii  x11-common   1:7.7+21
ii  x11-xserver-utils7.7+8

Versions of packages gdm3 recommends:
ii  at-spi2-core2.38.0-2
ii  desktop-base10.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.10-2
ii  xserver-xorg1:7.7+21
ii  zenity  3.32.0-6

Versions of packages gdm3 suggests:
ii  gnome-orca3.38.2-1
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

- -- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAmAghrkACgkQrNSfiF5U
Um6f4g//RwcW2e/+T+jkrjMp6B25+Zc7MNoJ+9CSeuoPPq+xBFJreyD4KLV0Zbf1
M0Z3ic9zWNMh89h7EGPw/LdsgFY8HfkmYxwOj52mNRxQqPiMvpbOGYhRGlrzSvOX
cD5tkUZBNBcfGY0kx1im05QyM5a+5f2pK97QUtN538XBdaI/3/5lYuP+5jWTWUvG
kD7J6SjldvxnTyyTXJ/HXeh9bxIWGIlyzEf57jRKMhzarfo1iRF/GP70FO7MyHTJ
SYvi8mWHunCb6dC63S3O5E5XfS2aSuV8Wlt0X7n+8mb6sBQozYUUJqaLBuY59h9W
/SlW/uJaJ5j0UGNHfvRtwHcJ094xkUXzs80c7xiyyUJK+SU5vtn40PqpqkxXzTzc
7RFSauvQTupnjYZ2iuBUf5kGADm4E4cDBSzC3uyYDiMK2Bv6x+k5mXWKQEQheR0S
fnTfkDLayVpUCVplU5skKxH4POh4zNxtyA2kIohcu+2LPAN//971LNjgJFBC3NIp
pLUGESVrgdrZOCGESEHcWZUfai8NmDoSYKJ3JR9i5y5i8npu8QuvVW/tCpGLa+rW
NRf1u/CkWYYCDCCC1YqWRUtayiw/xq3DSasVq/NXqEtZxYAQ2tFNn/t2OrXwmBFv
ujUNeCESPstuh0B+zqxSFsMFOAupZzjxhDbC2wiI0hTmBxEF9I4=
=ie7G
-END PGP SIGNATURE-

Bug#972720: flameshot: `flameshot -h` does not work properly.

[Boyuan Yang]

Control: tags -1 +confirmed
Control: forwarded -1
https://github.com/flameshot-org/flameshot/issues/1286

On Fri, 23 Oct 2020 08:50:46 +0900 Yukiharu YABUKI
 wrote:
> Package: flameshot
> Version: 0.8.5-1
> Severity: minor
> 
> Dear Maintainer,
> 
> When I use `flameshot -h`, flameshot show me below:
> 
> > flameshot -h
> > QString::arg: Argument missing: ] flameshot
> >
> > , flameshot
> > QString::arg: Argument missing: ] flameshot
> >
> > , [arguments]
> > Usage: %1 [%2-options] flameshot
> >
> > Per default runs Flameshot in the background and   adds a tray icon
for
> configuration.
> >
> > Options:
> >   -h, --help Displays this help
> >   -v, --version  Displays version information
> >
> > Arguments:
> >   gui    Start a manual capture in GUI mode.
> >   screen Capture a single screen.
> >   full   Capture the entire desktop.
> >   launcher   Open the capture launcher.
> >   config Configure flameshot.
> 
> I believe that this issue, minor bug. flameshot does not work
properly.
> I believe in broken window theory. That is why I report this issue.

Confirmed and forwarded to upstream.

-- 
Thanks,
Boyuan Yang


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

Bug#982144: php-klogger: Useless in Bullseye

[James Valleroy]

Hi Paul,

On 2/7/21 2:56 PM, Paul Gevers wrote:
> Hi James,
> 
> On 07-02-2021 18:23, James Valleroy wrote:
>> It has no dependencies in Buster, so there is no reason for an end user to 
>> install it.
>>
>> A PHP developer could use the package though. But I think they are more 
>> likely to use composer to download/install what they need.
> 
> So, you're saying it was useless to ship in buster?
> 

Yes, it was useless to ship in buster.

Regards,
James



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982268: apt: Please add a action override suffix for purge

[Bohdan Horbeshko]

Package: apt
Version: 2.1.10
Severity: wishlist

Dear Maintainer,

the + and - suffixes are great, but some persons tend to purge packages
by default whenever possible, instead of removing them, and thus a
similar suffix for purge would be great to, to avoid a need to purge
removed packages after a complex operation. I suggest -- (double minus).


-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --



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

Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.20-1
ii  libapt-pkg6.0   2.1.10
ii  libc6   2.31-3
ii  libgcc-s1   10.2.0-9
ii  libgnutls30 3.7.0-5
ii  libseccomp2 2.4.3-1+b1
ii  libstdc++6  10.2.0-9
ii  libsystemd0 246.6-2

Versions of packages apt recommends:
ii  ca-certificates  20200601

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-2
ii  dpkg-dev1.20.5
ii  gnupg   2.2.20-1
ii  gnupg2  2.2.20-1
ii  powermgmt-base  1.36
ii  synaptic0.90+nmu1

-- no debconf information

Bug#982266: fltk1.1: ftbfs in sid

[Aaron M. Ucko]

Gianfranco Costamagna  writes:

> dh_missing: error: missing files, aborting

Oops!  Thanks for pointing it out; I'm surprised the autobuilders didn't.

> (this is probably due to compat=13 change)

Indeed.

I'm on it now, with a mixed approach of skipping fluid installation and
meanwhile listing uncompressed man (and cat!) pages in
debian/not-installed.

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

Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...

[Dominic Hargreaves]

[Adding Andrew as the person who has recently worked on the package]

On Sun, Feb 07, 2021 at 03:28:48PM -0500, Aaron M. Ucko wrote:
> Dominic Hargreaves  writes:
> 
> > As a hunch, I changed the default from 'gpg' to '/usr/bin/gpg'.
> > Could you install this on your system and confirm whether it fixes
> > the problem?

(the tentative fix was at
)

> I must confess that I haven't actually fully deployed MonkeySphere, so I
> can't test the change quite as thoroughly as it perhaps deserves, but
> AFAICT this tweak is sufficient: I can log in without incident, and both
> dh_auto_test calls to succeed (albeit noisily) with
> 
>   -- FULLPERL='/usr/bin/perl -t'
> 
> appended.  (Full -T appears to break the test harness, but -t suffices
> to trigger the PATH-clearing logic.)

In fact, I've just realised that this regression comes from reverting
a functionality equivalent (part of a) patch in the latest upload.
This looks like it might have been unintentional?

https://salsa.debian.org/perl-team/modules/packages/libgnupg-interface-perl/-/commit/a96ae3047570483e96da309008d4110f16824ed5#f37d120361709f5984c8a7d93302241dc341b4b3_1_1

Andrew, was this intentional? Maybe we should just restore that part
of the patch?

Dominic

Bug#982255: lutris: segfault after cancelling

[Stephan Lachnit]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/lutris/lutris/issues/3357

Thanks for reporting, but this is a known issue.
I don't have time to look into it, so this depends
on upstream fixing this.

Regards,
Stephan

Bug#982245: reportbug crashes during initial configuration

[Nis Martensen]

On 07.02.2021 19.46, Mikael Petersson wrote:
> Nope. No non-ascii characters for my user account entry in /etc/passwd.
> No non-ascii characters whatsoever as far as I can see. No e-mail
> address is specified in my user account entry.
> 
> Neither /etc/email-adresses nor /etc/email-addresses exist on my system.
> I don't have any MTA installed.

Thank you for checking.

> One thing that may stand out a bit in my /etc/passwd entry is my choice
> of default shell. I run fish, /usr/bin/fish. But I got the same error
> after changing to /bin/bash, running reportbug from a new login session

The shell should not matter.

The relevant code is here:
https://sources.debian.org/src/reportbug/7.9.0/reportbug/utils.py/#L301

With the information you have provided, line 308 must have been reached
without the bad 'ä' having been introduced into the emailaddr variable
yet. This leaves only /etc/mailname and socket.getfqdn() as remaining
possibilities?

Bug#975985: Your mail

[Kai-Martin Knaak]

I went ahead and adopted the package. I uploaded geda-gaf-1.10.2-1 to
debian-mentors. The package is currently waiting for a sponsor to upload
it into unstable. So this bug can be closed.

https://mentors.debian.net/package/geda-gaf/

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882


pgp7Oi7St7Vdi.pgp
Description: OpenPGP digital signature

Bug#981609: gnome-activity-journal: missing dependencies on git packages

[Sudip Mukherjee]

On Sun, Feb 7, 2021 at 10:29 PM crvi c  wrote:
>
> The issue is already fixed in git.
>
> Please refer to 
> https://gitlab.gnome.org/crvi/gnome-activity-journal/-/issues/1

Ohh, sorry, I misunderstood your previous email.
I have now pulled the HEAD from your repo and tested in the setup
where it was not working and can confirm that it is working properly
now.

Thanks @crvi

-- 
Regards
Sudip

Bug#982147: mgba: Please provide a libmgba-dev package

[Ryan Tandy]

On Sun, Feb 07, 2021 at 10:05:38PM +0100, Celelibi wrote:

The program I'm writing would be an IRC bot a-la twitch-plays-pokemon. I
don't think it would be a good candidate for inclusion in Debian as I
intend it to be a quick-and-dirty program for my specific needs.


OK. Sounds fun. :)


I have no idea of an ABI compatibility policy. I'm not sure there's one
right now.


OK.


However, the CMakeLists.txt already contains everything needed to
install headers. So I guess there's an intent toward this usage even if
the support (especially regarding ABI stability) isn't well thought out.


Sure. I didn't mean to suggest that the library isn't meant to be used. 
In fact, It looks like upstream's own .deb packages also include 
mgba-dev as well as libmgba. However, for publishing it in Debian, it 
needs to meet the requirements set by Debian policy for shared 
libraries. (And I'm not even saying that it doesn't, only that I don't 
know whether it does or not.)



All I can say for sure right now is that the ABI will likely break with
version 0.9 because of a new field in the struct Table.


That's fine, as long as the SONAME also changes.


What exactly would be needed from the author of libmgba to make it
suitable as a public library? Would it be enough if they set a rule
saying that the minor version would be bumped at least on every ABI
break?


Specifically, we would want a commitment that there will not be any 
incompatible ABI change without a corresponding SONAME change. If the 
SONAME is tied to the minor version, then yes, what you said achieves 
that. The SONAME change is our trigger to recompile applications; if it 
doesn't change, we (want to) assume they don't need to be rebuilt.


This may well be how it works already. I just haven't found a written 
statement about it.


thanks,
Ryan

Bug#982266: fltk1.1: ftbfs in sid

[Gianfranco Costamagna]

Source: fltk1.1
Version: 1.1.10-28
tags: patch
severity: serious

Hello, looks like the package fails because of:

   dh_missing
dh_missing: warning: usr/bin/fluid exists in debian/tmp but is not installed to 
anywhere 
dh_missing: warning: usr/share/man/cat1/fltk-config.1 exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: usr/share/man/cat1/fluid.1 exists in debian/tmp but is not 
installed to anywhere 
dh_missing: warning: usr/share/man/cat3/fltk.3 exists in debian/tmp but is not 
installed to anywhere 
dh_missing: warning: usr/share/man/man1/fltk-config.1 exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: usr/share/man/man1/fluid.1 exists in debian/tmp but is not 
installed to anywhere 
dh_missing: warning: usr/share/man/man3/fltk.3 exists in debian/tmp but is not 
installed to anywhere 
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: fltk1.1-doc (1), fltk1.1-games (11), libfltk1.1 (4), 
libfltk1.1-dev (11)
 * dh_installdocs: fltk1.1-doc (4), fltk1.1-games (2), libfltk1.1 (2), 
libfltk1.1-dev (2)
 * dh_installman: fltk1.1-doc (0), fltk1.1-games (0), libfltk1.1 (0), 
libfltk1.1-dev (2)
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.
make: *** [debian/rules:16: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


(this is probably due to compat=13 change)

I think, to fix we can just add
override_dh_missing:
dh_missing --list-missing

Or do something else, like removing files, start installing them, or something 
different (e.g. debian/not-installed).

Please have a look if possible!

thanks

Gianfranco

Bug#982202: ITP: libmodule-install-substitute-perl -- Module::Install::Substitute - substitute values into files before install

[Andrew Ruthven]

Hi Dominic,

I built this package and it was uploaded last year on bug 975956.

Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |

Bug#981609: gnome-activity-journal: missing dependencies on git packages

[crvi c]

The issue is already fixed in git.

Please refer to
https://gitlab.gnome.org/crvi/gnome-activity-journal/-/issues/1

Thanks!

On Mon, 8 Feb 2021 at 03:38, Sudip Mukherjee 
wrote:

> On Sun, Feb 7, 2021 at 9:39 PM crvi c  wrote:
> >
> > Gstreamer packages should be "Suggested" dependencies, not "Recommended".
>
> No, Jonas is correct. It is working in my setup but after his reply I
> started testing on other environments and I can confirm there is
> atleast one combination (with Mate + lightdm) where
> gnome-activity-journal will not even start if 'gir1.2-gstreamer-1.0'
> is not installed. Absence of  'gstreamer1.0-gtk3' has not affected it
> till now.
>
> @crvi I will open an upstream issue for you to fix this issue, and
> till then I will mark 'gir1.2-gstreamer-1.0' as a dependency.
>
>
> --
> Regards
> Sudip
>

Bug#981440: bsdmainutils: Please make it only suggest calendar

[Samuel Thibault]

Hello,

Any news on this? It would be good to avoid installing cpp by default on
all base Debian systems.

Samuel

Samuel Thibault, le dim. 31 janv. 2021 12:06:35 +0100, a ecrit:
> Package: bsdmainutils
> Version: 12.1.7
> Severity: important
> 
> Hello,
> 
> In 257885db82a3 ("Split calendar into its own package") the calendar
> package was split out from the bsdmainutils package into its own package
> to save some room since the bsdmainutils is priority important, the
> former suggesting the latter. But a898abc6e8e5 ("Make bsdmainutils a
> transitional package.") later turned the suggestion into a dependency,
> so that calender does get installed.
> 
> The problem is that calendar depends on cpp, and thus in the end the
> base install of Debian bullseye installs cpp, which uses 30MB, just for
> a calendar that was supposed not to be installed by default, I don't
> think we want this :)
> 
> Could you make bsdmainutils back to only suggesting calendar, like it
> used to?
> 
> 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-1-amd64 (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 /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages calendar depends on:
> ii  cpp  4:10.2.1-1
> ii  libbsd0  0.10.0-1
> ii  libc62.31-9
> 
> calendar recommends no packages.
> 
> calendar suggests no packages.
> 
> -- no debconf information

Bug#980592: clamav: FTBFS: check_jsnorm.c:250:57: error: format not a string literal and no format arguments [-Werror=format-security]

[John Scott]

Control: tags -1 patch fixed-upstream
Control: forwarded -1 https://github.com/Cisco-Talos/clamav-devel/commit/18306

I found that the build succeeds with the upstream patch. It seems like
ck_assert_msg() was missing an argument.

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

Bug#982245: reportbug crashes during initial configuration

[Nis Martensen]

(Please keep the bug in cc.)

On 07.02.2021 19.01, Mikael Petersson wrote:
> Den sön 7 feb. 2021 kl 18:49 skrev Nis Martensen
> Even if you did not type such a non-ascii address into reportbug, it may
> have picked it up from any of the REPORTBUGEMAIL, DEBEMAIL, or EMAIL
> environment variables, leading to the crash. Were any of these variables
> defined on your system when you invoked reportbug?
> 
> 
> No, none of these environment variables are defined.
> 
> And note that I didn't try to enter any e-mail address at all. I only
> selected that reportbug will have direct Internet access. The crash came
> directly after I answered this question.

The crash happened when reportbug tried to guess the email address
before asking you to confirm/enter it.

If none of these variables were set, do you have any non-ascii
characters in your /etc/passwd entry or in a corresponding entry in
/etc/email-adresses?

Bug#982265: ITP: libatomprobe -- Library for Atom Probe Tomography computations

[D Haley]

Package: wnpp
Severity: wishlist
Owner: D Haley 

* Package name: libatomprobe
  Version : 20210207
  Upstream Author : D Haley 
* URL : http://apttools.sourceforge.io/
* License : GPLv3
  Programming Lang: C++, Python
  Description : Library for processing Atom Probe Tomography (APT) data

 This provides a C++ library for the scientific analysis
 of real valued point data (x,y,z,value). This is primarily targeted
 towards Atom probe tomography applications, but may prove useful to
 other applications as well.
 .
 The package includes both its own C++ and SWIG based python interfaces

This package provide tools for processing mass spectra data from Atom
Probe systems, such as developed by Ametek. Functions in the library
include spectra processing algorithms, 3D point data computation, and
file IO routines for specific APT types.

It is anticipated that this will become a future dependency for the
existing 3Depict package. This is intended to be maintained as part of
the Debian Science team.

There are no other packages that provide the coverage of data processing
routines in APT, as this is specialised research equipment.

A sponsor is needed, to quality-check and ultimately for upload.

Bug#982264: adequate: incompatible-licenses: OpenSSL is now considered a System Library wrt. GPL

[Thorsten Glaser]

Package: adequate
Version: 0.15.4
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

performous-composer: incompatible-licenses /usr/games/performous-composer 
GPLv2+ + OpenSSL (libssl.so.1.1)

This is now permitted in Debian, as OpenSSL is now a System Library
(like in the BSDs).

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages adequate depends on:
ii  debconf  1.5.74
ii  perl 5.32.1-2

Versions of packages adequate recommends:
pn  pkg-config  

adequate suggests no packages.

-- Configuration Files:
/etc/apt/apt.conf.d/20adequate changed:
// If you set this to "true", adequate will run on every install, reporting the
// results via debconf.
Adequate::Enabled "true";
DPkg::Pre-Install-Pkgs {
"adequate --help >/dev/null 2>&1 || exit 0; exec adequate --user nobody 
--tags -bin-or-sbin-binary-requires-usr-lib-library --apt-preinst";
};
DPkg::Post-Invoke {
"adequate --help >/dev/null 2>&1 || exit 0; exec adequate --user nobody 
--tags -bin-or-sbin-binary-requires-usr-lib-library --pending";
};
DPkg::Tools::Options::adequate::Version "2";


-- no debconf information

Bug#981609: gnome-activity-journal: missing dependencies on git packages

[Sudip Mukherjee]

On Sun, Feb 7, 2021 at 9:39 PM crvi c  wrote:
>
> Gstreamer packages should be "Suggested" dependencies, not "Recommended".

No, Jonas is correct. It is working in my setup but after his reply I
started testing on other environments and I can confirm there is
atleast one combination (with Mate + lightdm) where
gnome-activity-journal will not even start if 'gir1.2-gstreamer-1.0'
is not installed. Absence of  'gstreamer1.0-gtk3' has not affected it
till now.

@crvi I will open an upstream issue for you to fix this issue, and
till then I will mark 'gir1.2-gstreamer-1.0' as a dependency.


-- 
Regards
Sudip

Bug#982263: RFS: gringotts/1.2.10-4 [RC] -- secure password and data storage manager

[Jose G. López]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: gringotts
   Version : 1.2.10-4
   Upstream Author : Shlomi Fish 
 * URL : http://gringotts.shlomifish.org
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/josgalo-guest/gringotts
   Section : utils

It builds those binary packages:

  gringotts - secure password and data storage manager

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gringotts/gringotts_1.2.10-4.dsc

Changes since the last upload:

 gringotts (1.2.10-4) unstable; urgency=medium
 .
* debian/patches:
 - fix-build-with-gcc-10.patch. Import patch to fix FTBFS with GCC 10.
   Thanks to Logan Rosen. (Closes: #957312)
   * debian/control:
 - Bump to Standards-Version 4.5.1. No changes required.
 - Change maintainer's e-mail and set Vcs* fields to Salsa.
   * debian/copyright:
 - Use HTTPS as format URI and update debian copyright year and e-mail.

Thanks and regards,


pgpM2vfts5P5V.pgp
Description: PGP signature

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

[Craig Small]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,
  I think you have the control lines wrong.  You have both the lines from
psmisc and manpages-de there.

Breaks: manpages-de (<= 2.16-1), psmisc (<< 23.4-2)
Replaces: manpages-de (<= 2.16-1)

Think of Breaks as "someone won't have the manpage or there will be two of
them if this happens"
Replaces is "we took the file from that package", its replacing files not
packages.

So, manpage-de should have "Breaks: psmisc ( << 23.4-2)"
This means:
  * If you install this new manpage-de and have psmisc below 23.4-2 you
won't have the German psmisc manpages.

The next psmisc release will have "Breaks: manpage-de (<< 4.9.1-1),
Replaces: manpages-de ( << 4.9.1-1)"
This means:
  * If you install a new psmisc and old manpage-de then there are TWO
manpages, so don't do that.
  * The new psmisc replaces files in the old manpage-de

manpages-de *only* needs the Breaks psmisc bit.

The Breaks line sort of force an update of the other package too.

 - Craig

On 2021-02-07 at 17:17, deb...@helgefjell.de wrote:
> tags 982059 + pending
> thanks
>
> Hello Craig,
> the manpage-l10n package is ready to go. You can either pick it up
> from git https://salsa.debian.org/debian/manpages-l10n.git and perfom
> "gbp buildpackage" or you can download the packages "ready to sign and
> upload" from my site:
> https://www.helgefjell.de/data/manpages-l10n_4.9.1-1.tar.xz
> https://www.helgefjell.de/data/manpages-l10n_4.9.1-1.tar.xz.sig
>
> Since the Freeze is rapidly approaching an upload at your earliest
> possiblity would be highly appreciated.
>
> In case of problems I'll respond within 24 hours.
>
> Thanks for your support.
>
> Greetings
>
>  Helge
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>Dipl.-Phys.
http://www.helgefjell.de/debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.0.2
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJgIGDQACEJEAIhZsD/PITjFiEEXT3w9TizJ8CqeneiAiFm
wP88hOPAcg/+K2tS6kBZWdimiP9o87j5hEjcnUGFJsfAE1I6lMLvQWYABY+b
PRodB42Hj9CRF7+iGxL/QyHdpyUEKiaA/sYmYZAfUkr6mg+NNfzcNG94EbU8
BRkvXm5IB0J4v9x4ORKU8NwJcLTvMC1jCQuX8SuDm3hFVnmTzTXI5wfJ1ObF
tWIiYbAydh7OUlpmMvydDlvilqazcQFWoZsJUglYHziio2/y1yUlxBTL+dAt
MPjwHKd4i030gIhG/EwlGMVVtlDobs0AZeUFemsEN67uq3Zb34wG+g8XKDQZ
bUIo2ZA0NcZrNQXpcmGUTBpswb1chU2bGW7cDBenJKB74HBGHODW70De8D2i
763yvHDlB6doZdJnulmBcfFkUDpLz2wY1t+6urthYjYPCGzHNjK7luqSEsmK
dwLgCb+V95flpyxWmS3ZAiceT6W20vXRsGaX03XPdkbQa4f0TbId6Q9FsYSy
c1lVvfLE2a3hh0oCdzDVBtAoWfShuWHsX8DL1C8SmEFSnz/sh54bPZ0UAwDq
2kif8jAvYjPegbHow6Px3m2fvRVUBacwO22QzM1p/QcJ8DZC3WEoNdeY6+ST
1oWGeP0DbARbGVocqmjCxNJtywTWf2Wl2QCyxRAJV68d+mMJMP4znXA3Ed5r
nysOB2gsttFpj63ZkxyG8kIN2tIHd4hMiuQ=
=gRs1
-END PGP SIGNATURE-


0x3938F96BDF50FEA5.asc
Description: application/pgp-keys

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Jonas Smedegaard]

Quoting Paul Gevers (2021-02-07 22:04:25)
> Hi Jonas,
> 
> On 07-02-2021 13:44, Jonas Smedegaard wrote:
> > Quoting Paul Gevers (2021-02-07 12:07:08)
> >> With "quite some work" I mean that there are > 20 packages in testing 
> >> that need to change (are bugs already filed?). I understand from your 
> >> explanation that we already have a "Provides" in the fontconfig ID, 
> >> how bad would it be if fonts-urw-base35 add the Debian Provides: 
> >> gsfonts too? If that happens, we can (technically at least) drop 
> >> gsfonts, but how bad would that look (for those that rely on the 
> >> additional features of gsfonts)?
> > 
> > I think you are asking the wrong question here:
> 
> ? I'm wearing my Release Team member hat here. Fixing > 20 packages
> isn't great at this stage of the release. So, *if* this bug is indeed so
> severe as you claim, them I'm looking for options. Adding the Provides
> to fonts-urw-base35 enables us to remove gsfonts, which is what you
> want. I now realize I didn't make that totally clear and I think you
> misread my intentions.

I know that you are wearing your Release Team member hat. I appreciate 
your looking into this issue - with or without that hat on.

I agree with your reasoning that changing 20 packages isn't great and 
that alternative options are more relevant.

I only dismissed the question - i.e. last half of your last sentence: 
"how bad would instead getting fonts-urw-base35 be for those that rely 
on additional features of gsfonts?"

I am sorry if I misunderstood that question.  If I _did_ understand it 
then I don't know how to sensibly answer it, because those that rely on 
additional features of gsfonts _already_ do not (reliably) use gsfonts.


> > Those that rely on the undocumented additional features of gsfonts 
> > already today cannot be certain that they have them!  Most systems 
> > have ghostscript installed and therefore not *only* gsfonts but 
> > *both* that and fonts-urw-base35.
> 
> I understood that from your earlier mail, thanks.

I thought you did, but got uncertain due to that question of yours.

Again, I am sorry if I missed the meaning of that question :-(


> >  a) ensure that 20+ packages declaring a dependency on "look-alike 
> > fonts of the Adobe PostScript fonts" get the most accurate 
> > look-alike for the Adobe PostScript fonts: Have the package 
> > fonts-urw-base35 declare "Provides: gsfonts"
> 
> This is what I had in mind. You forgot to add, and drop gsfonts the 
> binary.

Right, when a) is implemented, this bug can be solved because then this 
package should no longer be used by any packages.

NB! I have *not* closely examined each case e.g. for versioned 
dependencies, but I guess even that should be possible nowadays to 
address without messing directly with those packages, using versioned 
Provides.


> >  b) ensure that 20+ packages declaring a dependency on "look-alike 
> > fonts of the Adobe PostScript fonts" get a specific (known 
> > inaccurate!) look-alike for the Adobe PostScript fonts: Have 
> > each of those packages declare "Conflicts: fonts-urw-base35" 
> > (unless they do *not* use fontconfig but explicit file paths to 
> > load those fonts)
> 
> In my opinion, too late. And again, are the bug reports for those
> packages already there?

I have done no preparations for this option - I don't like this option. 
It's just part of my answering my own question - to clarify why as I see 
it the only sensible approach here does _not_ involve directy messing 
with 20+ packages.


> >  c) ensure that 20+ packages declaring a dependency on "look-alike 
> > fonts of the Adobe PostScript fonts" continue to only maybe get 
> > what they declared - depending on whether their system happens 
> > to provide them different fonts instead.
> 
> But you claim that this is RC worthy. What's more, you claim that very 
> late in the release cycle (I think the issue hasn't changed since 
> buster, jessie or even longer) when there is not much time to decide 
> what to do and gsfonts is *currently* a key package that can't just be 
> removed so we need to decide the path to continue, autoremoval won't 
> do the work for you. Is this font issue really worth all that *now*?

I think that this namespace clash is a real issue, regardless of it 
having existed a long time.

If the only options available to solve this issue involved messing 
directly with 20+ packages, then (if I had a Release Team member hat) I 
would probably judge it too late and flag it as ignore-for-this-release.


> > My own answer would be that b) is the most work, c) is the least work, 
> > but b) is reasonably little work while solving this bug.
>   ^^ I assume you meant a) here. So I think we agree?

Yes!  Arrgh, sorry for that crucial and confusing mistake.


> > ...which gets us back to the original question of filing this 
> > bugreport: Is this bug real, and if so is it worth fixing for 
> > bullseye?
> 
> That's 

Bug#982245: reportbug crashes during initial configuration

[Nis Martensen]

control: forcemerge 969209 982245

On 07.02.2021 17.14, Mikael Petersson wrote:
> 
> Reportbug fails during the initial configuration when I use the default
> Y answer (I press Enter) for direct Internet access. Console output
> during execution:
> [...]
> UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in
> position 23: ordinal not in range(128)

Thanks Mikael for the report. Unfortunately reportbug does not support
non-ascii characters in email addresses yet. I'm merging this report
with the existing bug. There is no problem with such characters in the
name, only in the email address.

Even if you did not type such a non-ascii address into reportbug, it may
have picked it up from any of the REPORTBUGEMAIL, DEBEMAIL, or EMAIL
environment variables, leading to the crash. Were any of these variables
defined on your system when you invoked reportbug?

Bug#982262: vrrender: fails to start, missing directory

[Andrea Borgia]

Package: vrrender
Version: 20.2.0-1
Severity: normal

Dear Maintainer,

installing with "sudo apt install vrrender", it fails to start with this error:

[3][00:00:00.001253][warning] [RuntimeException.cpp:42] '/usr/lib/share/sight': 
not a directory.
[4][00:00:00.001322][warning] [RuntimeException.cpp:42] Error while adding 
modules. '/usr/lib/share/sight': not a directory.
terminate called after throwing an instance of 'fwRuntime::RuntimeException'
  what():  Error while adding modules. '/usr/lib/share/sight': not a directory.

note: /usr/share/sight exists, though.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 vrrender depends on:
ii  libsight  20.2.0-1

vrrender recommends no packages.

vrrender suggests no packages.

-- no debconf information

Bug#982261: ITP: webgen -- CSS minification with YUI compressor, but as native Ruby port

[Klaumi Klingsporn]

Package: wnpp
Severity: wishlist
Owner: Klaumi Klingsporn 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: webgen
  Version : 1.7.1
  Upstream Author : Thomas Leitner 
* URL : http://webgen.gettalong.org
* License : GPL, LGPL, Expat
  Programming Lang: Ruby
  Description : fast, powerful, and extensible static website generator

Webgen is used to generate static websites from templates and content
files (which can be written in a markup language). It can generate
dynamic content like menus on the fly, knows partial website regeneration
(only modified items get re-generated) and comes with many powerful
extensions.

Webgen was in Debian nearly a decade ago but was removed because it was 
orphaned.
But I continued to maintain some websites with this program, therefore built my
personal packages of every new version of the program and would like to see it 
back in
Debian.

I would like to package and maintain this program under the umbrella of the 
ruby team.

Bug#982144: php-klogger: Useless in Bullseye

[Petter Reinholdtsen]

[James Valleroy]
> Yes, it was useless to ship in buster.

While I can not vouch for php-klogger, I do know as a Debian user that I
often are pleasently surprised to find libraries I need for software
packages not currently in Debian.  Such library might lack reverse
dependencies in the Debian archive, but still provide value to the users
that need it. :)

This make it very hard to verify if a package is truly useless to ship
in a stable release. :)

-- 
Vennlig hilsen
Petter Reinholdtsen

Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?

[John David Anglin]

On 2021-02-07 4:30 p.m., John David Anglin wrote:
> On 2021-02-07 2:37 p.m., Jonas Smedegaard wrote:
>> What I don't understand is why it is needed only on hppa.
> I'm not sure.  The test is linked against both libsrtp2.a and libsrtp2.so.1.
The same error occurs on sparc64.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#981609: gnome-activity-journal: missing dependencies on git packages

[crvi c]

Gstreamer packages should be "Suggested" dependencies, not "Recommended".

The issues have been addressed in git master.

https://gitlab.gnome.org/crvi/gnome-activity-journal/-/commits/master

Thanks!

On Mon, 8 Feb 2021 at 01:15, Jonas Smedegaard  wrote:

> Quoting Sudip Mukherjee (2021-02-07 19:41:03)
> > Hi Jonas,
> >
> > On Tue, Feb 02, 2021 at 12:56:52AM +0100, Jonas Smedegaard wrote:
> > > Package: gnome-activity-journal
> > > Version: 1.0.0-1
> > > Severity: important
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > >
> > > Package is missing dependencies on at least these packages:
> > >
> > > gir1.2-gstreamer-1.0
> > > gir1.2-gnomedesktop-3.0:amd64
> >
> > Thanks for spotting  this.
> > 'gir1.2-gnomedesktop-3.0' is indeed a dependency, but
> 'gir1.2-gstreamer-1.0'
> > is an optional audio preview feature and so I am marking it along with
> > 'gstreamer1.0-gtk3' (which is also an optional video preview feature) as
> > suggested packages. Please let me know if you think this is wrong.
>
> Did you (not only look at code, but) actually test how the application
> behaves when those optional modules are missing?
>
> As I recall, the application failed to run for me when they were
> missing, which indicates that a suggestion is too weak and they should
> at least be recommended. If there is no (exotic) way to make the
> application run without them, they should have a hard dependency.
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?

[John David Anglin]

On 2021-02-07 2:37 p.m., Jonas Smedegaard wrote:
> What I don't understand is why it is needed only on hppa.
I'm not sure.  The test is linked against both libsrtp2.a and libsrtp2.so.1.

gcc -DHAVE_CONFIG_H -Icrypto/include -I./include -I./crypto/include -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=.
-Wformat -Werror=format-security -D_REENTRANT -O4 -fexpensive-optimizations 
-funroll-loops -fPIC -I/usr/include/nss -I/usr/include/nspr -L.  -o
test/dtls_srtp_driver test/dtls_srtp_driver.c test/getopt_s.c test/util.c 
libsrtp2.a -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 
-lsrtp2

That's a bit unusual.  Some reference must be being pulled from libsrtp2.so.1 
as a result of the "-lsrtp2" in the command line.

Would have to debug to find what it is.

Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#982144: php-klogger: Useless in Bullseye

[James Valleroy]

On 2/7/21 2:54 AM, Paul Gevers wrote:
> Hi James,
> 
> On Sat, 06 Feb 2021 15:10:04 -0500 James Valleroy
>> This is a dependency only for shaarli, which will not be included in 
>> Bullseye.
> 
> We already shipped this package in buster. Do you really think it's
> useless for users there without shaarli? Is it enough useless to not
> ship it?

It has no dependencies in Buster, so there is no reason for an end user to 
install it.

A PHP developer could use the package though. But I think they are more likely 
to use composer to download/install what they need.

I opened bugs like this for all the dependencies of shaarli, after discussion 
in #980134.
Do you agree with this approach in general?

Regards,
James



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977067: Bug#977060: cwltool FTBFS with pytest 6

[Étienne Mollier]

Control: tag -1 unreproducible
Control: tag -1 moreinfo

Hi there,

I tried to reproduce the bug by building igdiscover 0.11-3 using
sbuild in a clean Sid chroot which did include pytest 6:

$ schroot -c unstable-amd64-sbuild -d / \
  -- apt-cache show python3-pytest  \
  | grep Version:
Version: 6.0.2-2

I haven't been able to reproduce the problem, the build went
through.  I'm not sure what I'm missing.  Can someone else
reproduce the issue ?

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#982260: ITP: ruby-cssminify -- CSS minification with YUI compressor, but as native Ruby port

[Klaumi Klingsporn]

Package: wnpp
Severity: wishlist
Owner: Klaumi Klingsporn 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruby-cssminify
  Version : 1.0.2
  Upstream Author : Matthias Siegel 
* URL : https://github.com/matthiassiegel/cssminify
* License : expat
  Programming Lang: Ruby
  Description : CSS minification with YUI compressor, but as native Ruby 
port

The CSSminify gem provides CSS compression using YUI compressor. Instead
 of wrapping around the Java or Javascript version of YUI compressor it uses a
 native Ruby port of the CSS engine.

The package is a dependency of webgen, a static website generator which I also
would like to get back into Debian.

I would like to package and maintain this program under the umbrella of the 
ruby team.

Bug#982147: mgba: Please provide a libmgba-dev package

[Celelibi]

Le Sat, Feb 06, 2021 at 01:41:04PM -0800, Ryan Tandy a écrit :
> What is the software that would like to use this? Is it (or would it
> eventually be) in Debian?

The program I'm writing would be an IRC bot a-la twitch-plays-pokemon. I
don't think it would be a good candidate for inclusion in Debian as I
intend it to be a quick-and-dirty program for my specific needs.


> What is libmgba's ABI policy? Currently we use libmgba as a "private"
> library; only the frontends built from the same source link it, with tight
> version constraints. I guess shipping a -dev package would require making
> the library package public, and versioning it appropriately. It looks like
> libmgba's SONAME is derived from its version (i.e.  "libmgba.so.0.8") and
> does not reflect libtool-style versioning? Does mgba's author commit to ABI
> compatibility within the scope of a release branch?
> 
> (If it is attached to the release version that way, I'd have thought it's
> more conventional to name it e.g. "libmgba-0.8.so.0", but that's upstream's
> decision of course...)
> 
> In short, it's easy to ship some headers and a .so symlink, but I'm somewhat
> more hesitant about making libmgba into a public library, when it's not
> obvious to me that it's meant to be used that way, so I'd appreciate any
> links to where I can read about upstream's intent.

I have no idea of an ABI compatibility policy. I'm not sure there's one
right now.

However, the CMakeLists.txt already contains everything needed to
install headers. So I guess there's an intent toward this usage even if
the support (especially regarding ABI stability) isn't well thought out.
All I can say for sure right now is that the ABI will likely break with
version 0.9 because of a new field in the struct Table.

What exactly would be needed from the author of libmgba to make it
suitable as a public library? Would it be enough if they set a rule
saying that the minor version would be bumped at least on every ABI
break?

Best regards,
Celelibi

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Paul Gevers]

Hi Jonas,

On 07-02-2021 13:44, Jonas Smedegaard wrote:
> Quoting Paul Gevers (2021-02-07 12:07:08)
>> With "quite some work" I mean that there are > 20 packages in testing 
>> that need to change (are bugs already filed?). I understand from your 
>> explanation that we already have a "Provides" in the fontconfig ID, 
>> how bad would it be if fonts-urw-base35 add the Debian Provides: 
>> gsfonts too? If that happens, we can (technically at least) drop 
>> gsfonts, but how bad would that look (for those that rely on the 
>> additional features of gsfonts)?
> 
> I think you are asking the wrong question here:

? I'm wearing my Release Team member hat here. Fixing > 20 packages
isn't great at this stage of the release. So, *if* this bug is indeed so
severe as you claim, them I'm looking for options. Adding the Provides
to fonts-urw-base35 enables us to remove gsfonts, which is what you
want. I now realize I didn't make that totally clear and I think you
misread my intentions.

> Those that rely on the undocumented additional features of gsfonts 
> already today cannot be certain that they have them!  Most systems have 
> ghostscript installed and therefore not *only* gsfonts but *both* that 
> and fonts-urw-base35.

I understood that from your earlier mail, thanks.

> For its documented purpose, gsfonts is *known* to be slightly broken - 
> and using fonts-urw-base35 is the solution to that bug.  But as long as 
> gsfonts is *also* installed, each and every user must *bypass* 
> fontconfig and explicitly use file paths to ensure that they get the 
> non-broken fonts.

Ack.

> Instead, I would ask which of these is more work:
> 
>  a) ensure that 20+ packages declaring a dependency on "look-alike fonts 
> of the Adobe PostScript fonts" get the most accurate look-alike for 
> the Adobe PostScript fonts: Have the package fonts-urw-base35 
> declare "Provides: gsfonts"

This is what I had in mind. You forgot to add, and drop gsfonts the binary.

>  b) ensure that 20+ packages declaring a dependency on "look-alike fonts 
> of the Adobe PostScript fonts" get a specific (known inaccurate!) 
> look-alike for the Adobe PostScript fonts: Have each of those 
> packages declare "Conflicts: fonts-urw-base35" (unless they do *not* 
> use fontconfig but explicit file paths to load those fonts)

In my opinion, too late. And again, are the bug reports for those
packages already there?

>  c) ensure that 20+ packages declaring a dependency on "look-alike fonts 
> of the Adobe PostScript fonts" continue to only maybe get what they
> declared - depending on whether their system happens to provide them
> different fonts instead.

But you claim that this is RC worthy. What's more, you claim that very
late in the release cycle (I think the issue hasn't changed since
buster, jessie or even longer) when there is not much time to decide
what to do and gsfonts is *currently* a key package that can't just be
removed so we need to decide the path to continue, autoremoval won't do
the work for you. Is this font issue really worth all that *now*?

> My own answer would be that b) is the most work, c) is the least work, 
> but b) is reasonably little work while solving this bug.
  ^^ I assume you meant a) here. So I think we agree?

> ...which gets us back to the original question of filing this bugreport: 
> Is this bug real, and if so is it worth fixing for bullseye?

That's exactly my question too. And I'm really leaning now to "not for
bullseye, it's too late". This is no regression from the last couple of
releases after all.

> Answering that question involves the maintainer of fonts-urw-base35, who 
> seems to agree that the issue is real, but seems to consider c) more 
> reasonably to preserve than to fix this bug (hence my comment that I can 
> choose to ignore this bug for 10 more years if need be).

So, is the maintainer in the loop? He replied once, but do you know if
he follows our conversation?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#957342: marked as done (hspell-gui: ftbfs with GCC-10)

[Willy nilly]

close  #957342

On Sun, Feb 7, 2021 at 8:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 07 Feb 2021 20:49:12 +
> with message-id 
> and subject line Bug#957342: fixed in hspell-gui 0.2.6-7
> has caused the Debian Bug report #957342,
> regarding hspell-gui: ftbfs with GCC-10
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 957342: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957342
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Matthias Klose 
> To: mainto...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 17 Apr 2020 11:02:32 +
> Subject: hspell-gui: ftbfs with GCC-10
> Package: src:hspell-gui
> Version: 0.2.6-6
> 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/hspell-gui_0.2.6-6_unstable_gcc10.log
> The last lines of the build log are at the end of this report.
>
> To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
>
>   apt-get -t=experimental install g++
>
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-10/porting_to.html
>
> [...]
> /usr/include/glib-2.0/glib/gtypes.h:551:8: note: declared here
>   551 | struct _GTimeVal
>   |^
> gcc -DHAVE_CONFIG_H -I. -I.. -DPACKAGE_DATA_DIR=\""/usr/share"\"
> -DPACKAGE_LOCALE_DIR=\""/usr/share/locale"\" -pthread
> -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
> -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
> -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/pango-1.0
> -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16-g
> -O2 -c -o callbacks.o callbacks.c
> In file included from /usr/include/gtk-2.0/gtk/gtkobject.h:37,
>  from /usr/include/gtk-2.0/gtk/gtkwidget.h:36,
>  from /usr/include/gtk-2.0/gtk/gtkcontainer.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkbin.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkwindow.h:36,
>  from /usr/include/gtk-2.0/gtk/gtkdialog.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkaboutdialog.h:32,
>  from /usr/include/gtk-2.0/gtk/gtk.h:33,
>  from callbacks.c:5:
> /usr/include/gtk-2.0/gtk/gtktypeutils.h:236:1: warning: ‘GTypeDebugFlags’
> is deprecated [-Wdeprecated-declarations]
>   236 | voidgtk_type_init   (GTypeDebugFlagsdebug_flags);
>   | ^~~~
> In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
>  from /usr/include/glib-2.0/gobject/gbinding.h:29,
>  from /usr/include/glib-2.0/glib-object.h:23,
>  from /usr/include/glib-2.0/gio/gioenums.h:28,
>  from /usr/include/glib-2.0/gio/giotypes.h:28,
>  from /usr/include/glib-2.0/gio/gio.h:26,
>  from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
>  from /usr/include/gtk-2.0/gdk/gdk.h:32,
>  from /usr/include/gtk-2.0/gtk/gtk.h:32,
>  from callbacks.c:5:
> /usr/include/glib-2.0/gobject/gtype.h:679:1: note: declared here
>   679 | {
>   | ^
> In file included from /usr/include/gtk-2.0/gtk/gtktoolitem.h:31,
>  from /usr/include/gtk-2.0/gtk/gtktoolbutton.h:30,
>  from /usr/include/gtk-2.0/gtk/gtkmenutoolbutton.h:30,
>  from /usr/include/gtk-2.0/gtk/gtk.h:126,
> 

Bug#981600: nghttp2: util_localtime_date test fails in arch-only build

[Helmut Grohne]

On Sun, Feb 07, 2021 at 08:51:36PM +0100, Chris Hofstaedtler wrote:
> I'm just passing by, but a local rebuild with `sbuild -d unstable
> -j8 --no-arch-all` did not show this problem (on amd64). There has
> to be more to it.

Thank you. I retried it to day (sbuild -d unstable --no-arch-all
nghttp2 on amd64) and it failed in the same way. I'm left puzzled what
could be different here. One aspect that certainly is not entirely usual
is that my chroot lives on a large tmpfs. Could that pose any problems?

Any other details I could add to help better understand the issue?

Helmut

Bug#980085: open-iscsi: initiator does not connect

[Heinrich Schuchardt]

On 2/7/21 8:36 PM, Chris Hofstaedtler wrote:

Hello Heinrich,

I'm going to upload upstream's fix. Maybe you can give it a try.

Best,
Chris


Debian release 2.1.3-2 added

+upstream/0001-iscsiadm-Fix-memory-leak-in-iscsiadm.patch
+upstream/0002-Fix-iscsiadm-segfault-when-exiting.patch
+upstream/0003-Fix-iscsistart-login-issue-when-target-is-delayed.patch

I have built the package from
https://salsa.debian.org/linux-blocks-team/open-iscsi
commit 7334ed475e26b8

This works for me but still shows the warning

iscsistart: initiator reported error (15 - session exists)

Tested-by: Heinrich Schuchardt 

Bug#982259: miniupnpd FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: miniupnpd
Version: 2.2.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

miniupnpd fails to cross build from source, because it does not use
cross tools. Please consider applying the attached patch to let dpkg's
buildtools.mk initialize the relevant environment variables and make
miniupnpd cross buildable again.

Helmut
diff --minimal -Nru miniupnpd-2.2.1/debian/changelog 
miniupnpd-2.2.1/debian/changelog
--- miniupnpd-2.2.1/debian/changelog2021-01-04 14:48:54.0 +0100
+++ miniupnpd-2.2.1/debian/changelog2021-02-07 14:34:24.0 +0100
@@ -1,3 +1,10 @@
+miniupnpd (2.2.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply cross tools. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 07 Feb 2021 14:34:24 +0100
+
 miniupnpd (2.2.1-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru miniupnpd-2.2.1/debian/rules miniupnpd-2.2.1/debian/rules
--- miniupnpd-2.2.1/debian/rules2021-01-04 14:48:54.0 +0100
+++ miniupnpd-2.2.1/debian/rules2021-02-07 14:34:23.0 +0100
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE = 1
 
+DPKG_EXPORT_BUILDTOOLS=1
+-include /usr/share/dpkg/buildtools.mk
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 

Bug#932582: marked as done (anbox: ignores mouse input)

[Willy nilly]

nnn-unsubscr...@bugs.debian.org

On Sun, Feb 7, 2021 at 8:36 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 7 Feb 2021 20:33:06 +
> with message-id <20210207203306.ga25...@mithrandir.lan.emorrp1.name>
> and subject line anbox no longer ignores mouse input
> has caused the Debian Bug report #932582,
> regarding anbox: ignores mouse input
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 932582: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932582
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Phil Morrell 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sat, 20 Jul 2019 22:06:02 +0100
> Subject: anbox: ignores mouse input
> Package: anbox
> Version: 0.0~git20190124-1
> Severity: grave
> Justification: renders package unusable
>
> I am able to launch the android apps from the desktop menu, but cannot
> interact other than moving the window around and fullscreening.
>
> I thought this was reported upstream as [#780], but the fix was merged
> in [bbf05d8f3] on 2019-01-06 and so included in the debian version.
>
> [#780]: https://github.com/anbox/anbox/issues/780
> [bbf05d8f3]:
> https://github.com/anbox/anbox/commit/bbf05d8f3267ef5fb102525c372183aaa83df830
> --
> Phil Morrell (emorrp1)
>
>
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable-debug
>   APT policy: (500, 'stable-debug'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages anbox depends on:
> ii  iptables1.8.2-4
> ii  libboost-atomic1.67.0   1.67.0-13
> ii  libboost-chrono1.67.0   1.67.0-13
> ii  libboost-date-time1.67.01.67.0-13
> ii  libboost-filesystem1.67.0   1.67.0-13
> ii  libboost-iostreams1.67.01.67.0-13
> ii  libboost-log1.67.0  1.67.0-13
> ii  libboost-program-options1.67.0  1.67.0-13
> ii  libboost-regex1.67.01.67.0-13
> ii  libboost-serialization1.67.01.67.0-13
> ii  libboost-system1.67.0   1.67.0-13
> ii  libboost-thread1.67.0   1.67.0-13
> ii  libc6   2.28-10
> ii  libegl1 1.1.0-1
> ii  libgcc1 1:8.3.0-6
> ii  libgles21.1.0-1
> ii  liblxc1 1:3.1.0+really3.0.3-8
> ii  libprotobuf-lite17  3.6.1.3-2
> ii  libsdl2-2.0-0   2.0.9+dfsg1-1
> ii  libsdl2-image-2.0-0 2.0.4+dfsg1-1
> ii  libstdc++6  8.3.0-6
> ii  libsystemd0 241-5
> ii  lxc 1:3.1.0+really3.0.3-8
>
> Versions of packages anbox recommends:
> ii  dbus-user-session  1.12.16-1
>
> anbox suggests no packages.
>
> -- no debconf information
> To: Debian Bug Tracking System 
> Subject: anbox: ignores mouse input
> X-Debbugs-Cc: deb...@emorrp1.name
>
> Package: anbox
> Version: 0.0~git20190124-1
> Severity: grave
> Justification: renders package unusable
>
> I am able to launch the android apps from the desktop menu, but cannot
> interact other than moving the window around and fullscreening.
>
> I thought this was reported upstream as [#780], but the fix was merged
> in [bbf05d8f3] on 2019-01-06 and so included in the debian version.
>
> [#780]: https://github.com/anbox/anbox/issues/780
> [bbf05d8f3]:
> https://github.com/anbox/anbox/commit/bbf05d8f3267ef5fb102525c372183aaa83df830
> --
> Phil Morrell (emorrp1)
>
>
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable-debug
>   APT policy: (500, 'stable-debug'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages anbox depends on:
> ii  iptables1.8.2-4
> ii  libboost-atomic1.67.0   1.67.0-13
> ii  libboost-chrono1.67.0   1.67.0-13
> ii  libboost-date-time1.67.01.67.0-13
> ii  libboost-filesystem1.67.0   1.67.0-13
> ii  

Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...

[Aaron M. Ucko]

Dominic Hargreaves  writes:

> As a hunch, I changed the default from 'gpg' to '/usr/bin/gpg'.
> Could you install this on your system and confirm whether it fixes
> the problem?

I must confess that I haven't actually fully deployed MonkeySphere, so I
can't test the change quite as thoroughly as it perhaps deserves, but
AFAICT this tweak is sufficient: I can log in without incident, and both
dh_auto_test calls to succeed (albeit noisily) with

  -- FULLPERL='/usr/bin/perl -t'

appended.  (Full -T appears to break the test harness, but -t suffices
to trigger the PATH-clearing logic.)

Thanks!

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

Bug#949876: marked as done (chromium: Chromium wants to update and reports it cannot)

[Willy nilly]

949...@bugs.debian.org


On Sun, Feb 7, 2021 at 8:24 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 7 Feb 2021 15:18:43 -0500
> with message-id  mo_wrv5pdbbd3jhnw8te91jd4zpditmzhwdalzncht...@mail.gmail.com>
> and subject line Re: Bug#949876: chromium: Chromium wants to update and
> reports it cannot
> has caused the Debian Bug report #949876,
> regarding chromium: Chromium wants to update and reports it cannot
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 949876: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949876
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Josef Kufner 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 26 Jan 2020 15:20:34 +0100
> Subject: chromium: Chromium wants to update and reports it cannot
> Package: chromium
> Version: 78.0.3904.97-1~deb10u1
> Severity: normal
>
> Dear Maintainer,
>
> from time to time, Chromium changes its menu button to a red circle with a
> white arrow and tells me to update. Then it tells me that it cannot update.
>
> This is wrong for two reasons:
>
> 1. Updates are managed by APT from distribution packages and Chromium has
> nothing to do with this.
>
> 2. It leaks information about my computer to who knows what 3rd-party
> service
> to check if there is a new version.
>
>
> Please remove this anti-feature completely.
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers stable
>   APT policy: (900, 'stable'), (800, 'testing'), (500, 'stable-updates'),
> (400, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8),
> LANGUAGE=cs:en_US:en_GB (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages chromium depends on:
> ii  chromium-common  78.0.3904.97-1~deb10u1
> ii  libasound2   1.1.8-1
> ii  libatk-bridge2.0-0   2.30.0-5
> ii  libatk1.0-0  2.30.0-2
> ii  libatomic1   9.2.1-22
> ii  libatspi2.0-02.30.0-7
> ii  libavcodec58 7:4.1.4-1~deb10u1
> ii  libavformat587:4.1.4-1~deb10u1
> ii  libavutil56  7:4.1.4-1~deb10u1
> ii  libc62.29-7
> ii  libcairo-gobject21.16.0-4
> ii  libcairo21.16.0-4
> ii  libcups2 2.2.10-6+deb10u1
> ii  libdbus-1-3  1.12.16-1
> ii  libdrm2  2.4.100-4
> ii  libevent-2.1-6   2.1.8-stable-4
> ii  libexpat12.2.6-2+deb10u1
> ii  libflac8 1.3.2-3
> ii  libfontconfig1   2.13.1-2
> ii  libfreetype6 2.10.1-2
> ii  libgcc1  1:9.2.1-22
> ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
> ii  libglib2.0-0 2.62.4-1
> ii  libgtk-3-0   3.24.5-1
> ii  libharfbuzz0b2.6.4-1
> ii  libicu63 63.2-2
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libjsoncpp1  1.7.4-3
> ii  liblcms2-2   2.9-3
> ii  libminizip1  1.1-8+b1
> ii  libnspr4 2:4.24-1
> ii  libnss3  2:3.48-1
> ii  libopenjp2-7 2.3.0-2
> ii  libopus0 1.3-1
> ii  libpango-1.0-0   1.42.4-7~deb10u1
> ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
> ii  libpci3  1:3.6.2-6
> ii  libpng16-16  1.6.37-1
> ii  libpulse013.0-3
> ii  libre2-5 20200101+dfsg-1
> ii  libsnappy1v5 1.1.7-1
> ii  libstdc++6   9.2.1-22
> ii  libvpx5  1.7.0-3
> ii  libwebp6 0.6.1-2
> ii  libwebpdemux20.6.1-2
> ii  libwebpmux3  0.6.1-2+b1
> ii  libx11-6 2:1.6.7-1
> ii  libx11-xcb1  2:1.6.7-1
> ii  libxcb1  1.13.1-2
> ii  libxcomposite1   1:0.4.4-2
> ii  libxcursor1  1:1.1.15-2
> ii  libxdamage1  1:1.1.5-1
> ii  libxext6 2:1.3.3-1+b2
> ii  libxfixes3   1:5.0.3-1
> ii  libxi6   2:1.7.9-1
> ii  libxml2  2.9.4+dfsg1-7+b3
> ii  libxrandr2   2:1.5.1-1
> ii  libxrender1  1:0.9.10-1
> ii  libxslt1.1   1.1.32-2.2~deb10u1
> ii  libxss1  1:1.2.3-1
> ii  libxtst6 2:1.2.3-1
> ii  zlib1g   1:1.2.11.dfsg-1
>
> Versions of packages chromium recommends:
> ii  chromium-sandbox  78.0.3904.97-1~deb10u1
>
> Versions of packages chromium suggests:
> pn  chromium-driver  
> ii  chromium-l10n78.0.3904.97-1~deb10u1
> ii  chromium-shell   78.0.3904.97-1~deb10u1

Bug#980103: smb4k no more starting

[Bernhard Übelacker]

Hello Hans,
great that it works.



So I suppose, we should and could safely close this bug.


This can be achieved by sending the
mail to 980103-d...@bugs.debian.org.
(I hope this is ok with smb4k maintainers.)



Best regards, thank you very much again and stay healthy!


Thank you, the same to you.

Kind regards,
Bernhard

Bug#982258: gpgv1: Consider removing parts of the tools which aren't recommended to be used

[Dominic Hargreaves]

Package: gpgv1
Version: 1.4.23-1.1
Severity: wishlist

In the discussion at [1] it was suggested that perhaps gnupg1 could be
updated to explicitly remove support for operations other than
decrypting old messages.

[1] 

Bug#982253: netkit telnetd: ship with bullseye with open security problems?

[Salvatore Bonaccorso]

Hi,

[Not a conclusive answer]

On Sun, Feb 07, 2021 at 06:49:25PM +0100, Chris Hofstaedtler wrote:
> 2) possibly unpatched exploit here: https://www.exploit-db.com/exploits/48170

JFTR, this one was CVE-2020-10188 and in Debian was fixed in earlier
times.

Replacing telnetd package with an empy package and depending on
inetutils-telnetd: is it possible to basically interchangably replace
those two? If so this might be an option but I'm not sure if at this
stage of the preparations for bullseye it might be too late.

> 1) open bug #974428, causes telnetd to crash, remotely triggerable

The first issue, if there a verified patch might be good to fix in
time for bullseye.

Regards,
Salvatore

Bug#977669: postfix: new upstream release 3.5.8

[Christian Göttsche]

Kindly Ping.

Can version 3.5.8 (3.5.9 is already released with DNSSEC support
improvements) please be package for Debian Bullseye?

Best regards,
   Christian Göttsche

Bug#982144: php-klogger: Useless in Bullseye

[Paul Gevers]

Hi James,

On 07-02-2021 18:23, James Valleroy wrote:
> It has no dependencies in Buster, so there is no reason for an end user to 
> install it.
>
> A PHP developer could use the package though. But I think they are more 
> likely to use composer to download/install what they need.

So, you're saying it was useless to ship in buster?

> I opened bugs like this for all the dependencies of shaarli, after discussion 
> in #980134.
> Do you agree with this approach in general?

You may have noticed (or may do so tomorrow ;)) that I already removed
all those packages. I refrained from this one because it's shipped with
buster.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979840: dns-root-data: autopkgtest regression in testing: failed to query server 127.0.0.1@53

[Chris Hofstaedtler]

Hello Paul,
Hello knot-resolver Maintainers,

* Paul Gevers  [210207 19:52]:
> With a not so recent change (beginning 2020) somewhere outside your
> package the autopkgtest of your package started to fail. I copied some
> of the output at the bottom of this report. Can you please investigate
> the situation and fix it?
[..]
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dns-root-data/9516338/log.gz
> 
> autopkgtest [17:42:10]: test baseline: [---
> ;; WARNING: response timeout for 127.0.0.1@53(UDP)
> ;; WARNING: response timeout for 127.0.0.1@53(UDP)
> ;; WARNING: response timeout for 127.0.0.1@53(UDP)
> ;; ERROR: failed to query server 127.0.0.1@53(UDP)
> autopkgtest [17:42:25]: test baseline: ---]

It would appear knot-resolver made changes and now kresd no longer
starts when the package gets installed.
I don't know if this is an intentional change at all?

Chris

Bug#981600: nghttp2: util_localtime_date test fails in arch-only build

[Chris Hofstaedtler]

Hi Helmut,

* Helmut Grohne  [210207 19:50]:
> An arch-only build (but not a full build) of nghttp2 seems to reliably
> fail at test util_localtime_date:
[..]
> Since reproducible only performs full builds, it doesn't see this issue.
> Likewise crossqa skips tests and does not see it either. I don't
> understand the cause here and just report it. I hope it reproduces
> reliably elsewhere as well.

I'm just passing by, but a local rebuild with `sbuild -d unstable
-j8 --no-arch-all` did not show this problem (on amd64). There has
to be more to it.

Chris

Bug#982062: chromium: Google is limiting private api availability for all chromium builds

[Michael Gilbert]

control: severity -1 minor

On Sat, Feb 6, 2021 at 3:09 AM jim_p wrote:
> This means that sync and some other features will stop working from that day 
> on
> and users that use them will complain and file bug reports.

None of this is relevant to running chromium as a web browser, which
is its intended purpose.

Best wishes,
Mike

Bug#969557: chromium: "clear browsing data" never completes

[Michael Gilbert]

On Fri, Sep 4, 2020 at 4:57 PM Rory Campbell-Lange wrote:
> Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE

Chromium on tainted kernels is not supported.

Best wishes,
Mike

Bug#982255: lutris: segfault after cancelling

[Phil Morrell]

Thanks for finding the upstream report, sorry for not checking there
first. I forgot to attach the stacktrace, here it is.
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...
Reading symbols from 
/usr/lib/debug/.build-id/23/979cd82e8104807e7a6f742c379e49e7c5d9bb.debug...
Starting program: /usr/bin/python3 /usr/games/lutris
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 11066]
[Detaching after fork from child process 11067]
[New Thread 0x7200d700 (LWP 11076)]
[New Thread 0x7180c700 (LWP 11077)]
[Detaching after fork from child process 11078]
[Detaching after fork from child process 11079]
[Detaching after fork from child process 11080]
[Detaching after fork from child process 11081]
it looks like wine32 is missing, you should install it.
multiarch needs to be enabled first.  as root, please
execute "dpkg --add-architecture i386 && apt-get update &&
apt-get install wine32"
[Detaching after fork from child process 11085]
[New Thread 0x7fffeb351700 (LWP 11086)]
2021-02-07 19:01:01,260: Initializing lutris
2021-02-07 19:01:01,857: Downloading DXVK releases to 
/home/emorrp1/.local/share/lutris/runtime/dxvk/dxvk_versions.json
2021-02-07 19:01:01,859: Runtime updated. Initialization complete.
2021-02-07 19:01:01,860: Lutris 0.5.8.3
2021-02-07 19:01:01,860: Running Mesa/X.org Mesa driver 20.3.4 on llvmpipe 
(LLVM 11.0.1, 256 bits) (0x)
2021-02-07 19:01:01,861: GPU: 1B36:0100 1AF4:1100 (qxl drivers)
2021-02-07 19:01:01,861: i386 libGL.so.1 missing (needed by opengl)
2021-02-07 19:01:01,861: i386 libvulkan.so.1 missing (needed by vulkan)
[Thread 0x7fffeb351700 (LWP 11086) exited]
[New Thread 0x7fffeb351700 (LWP 11087)]
[New Thread 0x7fffda8f1700 (LWP 11088)]
[New Thread 0x7fffda0f0700 (LWP 11089)]
[New Thread 0x7fffd98ef700 (LWP 11090)]
[New Thread 0x7fffd90ee700 (LWP 11091)]
[New Thread 0x7fffd88ed700 (LWP 11092)]
[New Thread 0x7fffcbfff700 (LWP 11093)]
[New Thread 0x7fffcb7fe700 (LWP 11094)]
[Thread 0x7fffd98ef700 (LWP 11090) exited]
[Thread 0x7fffda0f0700 (LWP 11089) exited]
[Thread 0x7fffda8f1700 (LWP 11088) exited]
[Thread 0x7fffeb351700 (LWP 11087) exited]
[Thread 0x7fffd88ed700 (LWP 11092) exited]
[Thread 0x7fffcb7fe700 (LWP 11094) exited]
[Thread 0x7fffd90ee700 (LWP 11091) exited]
[Thread 0x7fffcbfff700 (LWP 11093) exited]
[Detaching after fork from child process 11095]
[Detaching after fork from child process 11096]
[New Thread 0x7fffcb7fe700 (LWP 11097)]
[New Thread 0x7fffcbfff700 (LWP 11098)]
[Thread 0x7fffcbfff700 (LWP 11098) exited]
--Type  for more, q to quit, c to continue without paging--

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
g_menu_model_get_n_items (model=0x0) at ../../../gio/gmenumodel.c:498
498 ../../../gio/gmenumodel.c: No such file or directory.
(gdb) bt
#0  g_menu_model_get_n_items (model=0x0) at ../../../gio/gmenumodel.c:498
#1  0x754a690d in gtk_application_window_update_shell_shows_app_menu (
window=window@entry=0x16ba860, settings=settings@entry=0x11ea1c0)
at ../../../../gtk/gtkapplicationwindow.c:322
#2  0x754a6eeb in gtk_application_window_real_realize (widget=0x16ba860)
at ../../../../gtk/gtkapplicationwindow.c:683
#3  0x7730b2de in _g_closure_invoke_va (closure=closure@entry=0xbc2aa0, 
return_value=return_value@entry=0x0, instance=instance@entry=0x16ba860, 
args=args@entry=0x7fffad60, n_params=0, param_types=0x0) at 
../../../gobject/gclosure.c:873
#4  0x77323a18 in g_signal_emit_valist (instance=0x16ba860, 
signal_id=, 
detail=0, var_args=var_args@entry=0x7fffad60) at 
../../../gobject/gsignal.c:3403
#5  0x77323c0f in g_signal_emit (instance=instance@entry=0x16ba860, 
signal_id=, detail=detail@entry=0) at 
../../../gobject/gsignal.c:3550
#6  0x757313e7 in gtk_widget_realize (widget=0x16ba860) at 
../../../../gtk/gtkwidget.c:5519
#7  0x7573e89e in gtk_window_show (widget=0x16ba860) at 
../../../../gtk/gtkwindow.c:6181
#8  0x7730b092 in g_closure_invoke (closure=closure@entry=0xbcb8b0, 
return_value=return_value@entry=0x0, n_param_values=1, 
param_values=param_values@entry=0x7fffb0a0, 

Bug#982245: reportbug crashes during initial configuration

[Mikael Petersson]

Den sön 7 feb. 2021 kl 20:09 skrev Nis Martensen :

> On 07.02.2021 19.46, Mikael Petersson wrote:
> > Nope. No non-ascii characters for my user account entry in /etc/passwd.
> > No non-ascii characters whatsoever as far as I can see. No e-mail
> > address is specified in my user account entry.
> >
> > Neither /etc/email-adresses nor /etc/email-addresses exist on my system.
> > I don't have any MTA installed.
>
> Thank you for checking.
>
> > One thing that may stand out a bit in my /etc/passwd entry is my choice
> > of default shell. I run fish, /usr/bin/fish. But I got the same error
> > after changing to /bin/bash, running reportbug from a new login session
>
> The shell should not matter.
>
> The relevant code is here:
> https://sources.debian.org/src/reportbug/7.9.0/reportbug/utils.py/#L301
>
> With the information you have provided, line 308 must have been reached
> without the bad 'ä' having been introduced into the emailaddr variable
> yet. This leaves only /etc/mailname and socket.getfqdn() as remaining
> possibilities?
>

Problem solved! :-) domainname --fqdn revealed that I have actually
provided an 'ä' to the domain name. 'ä' is a common character in Swedish,
and it's certainly non-ASCII. With an ASCII-only FQDN, reportbug works fine.

Sorry for the inconvenience, and for your patience. This is most certainly
not an important bug. I wouldn't hardly recognize it as a bug at all.
FQDN:s should always be ASCII only.

/Micael

Bug#981609: gnome-activity-journal: missing dependencies on git packages

[Jonas Smedegaard]

Quoting Sudip Mukherjee (2021-02-07 19:41:03)
> Hi Jonas,
> 
> On Tue, Feb 02, 2021 at 12:56:52AM +0100, Jonas Smedegaard wrote:
> > Package: gnome-activity-journal
> > Version: 1.0.0-1
> > Severity: important
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Package is missing dependencies on at least these packages:
> > 
> > gir1.2-gstreamer-1.0
> > gir1.2-gnomedesktop-3.0:amd64
> 
> Thanks for spotting  this.
> 'gir1.2-gnomedesktop-3.0' is indeed a dependency, but 'gir1.2-gstreamer-1.0'
> is an optional audio preview feature and so I am marking it along with
> 'gstreamer1.0-gtk3' (which is also an optional video preview feature) as
> suggested packages. Please let me know if you think this is wrong.

Did you (not only look at code, but) actually test how the application 
behaves when those optional modules are missing?

As I recall, the application failed to run for me when they were 
missing, which indicates that a suggestion is too weak and they should 
at least be recommended. If there is no (exotic) way to make the 
application run without them, they should have a hard dependency.


 - 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#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?

[Jonas Smedegaard]

Quoting John David Anglin (2021-02-07 20:20:42)
> On 2021-02-07 2:02 p.m., John David Anglin wrote:
> > On 2021-02-07 1:49 p.m., Jonas Smedegaard wrote:
> >> My guess is that the hppa build daemon is setup differently than 
> >> other build daemons, or maybe the hppa hardware need some special 
> >> magic to register shared objects.
> > One way is to use the environment variable LD_LIBRARY_PATH.  Many 
> > packages use it so that ld.so finds libraries that haven't been 
> > installed in the standard system locations.  If you don't set it, it 
> > is possible that the installed system version is used.
> Oh, there's nothing special about the handling of shared libraries on 
> hppa-linux.  It uses the standard glibc dynamic linker.

I am aware of the LD_LIBRARY_PATH environment variable.

What I don't understand is why it is needed only on hppa.


 - 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#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...

[Dominic Hargreaves]

On Tue, Feb 02, 2021 at 10:09:45AM -0500, Aaron M. Ucko wrote:
> Package: libgnupg-interface-perl
> Version: 1.01-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: msva-p...@packages.debian.org
> Control: affects -1 msva-perl
> 
> [Copying msva-perl maintainers.]
> 
> My X session normally boils down to
> 
> exec /usr/bin/ssh-agent /usr/bin/monkeysphere-validation-agent 
> /usr/bin/im-launch x-session-manager
> 
> where /usr/bin/monkeysphere-validation-agent resolves (via the
> alternatives system) to /usr/bin/msva-perl.  With this setup,
> libgnupg-interface-perl 1.01 attempts to run gpg with no PATH and
> bails because it couldn't find an acceptable version of gpg, thereby
> immediately crashing msva-perl and my entire X session.
> 
> I'm not entirely sure what triggers the PATH-clearing here, perhaps
> the fact that ssh-agent is setgid ssh.  Regardless, I'd suggest
> setting a sane PATH that includes at minimum /bin and /usr/bin rather
> than clearing PATH entirely.  (Explicitly running /usr/bin/gpg might
> also work.)
> 
> Could you please take a look?

As a hunch, I changed the default from 'gpg' to '/usr/bin/gpg'.
Could you install this on your system and confirm whether it fixes
the problem?

https://salsa.debian.org/perl-team/modules/packages/libgnupg-interface-perl/-/tree/hardcode-gpg-path

Cheers
Dominic

Bug#980085: open-iscsi: initiator does not connect

[Chris Hofstaedtler]

Hello Heinrich,

I'm going to upload upstream's fix. Maybe you can give it a try.

Best,
Chris

Bug#982109: [ledgersmb-devel] Bug#982109: ledgersmb: new upstream releases

[Chris Hofstaedtler]

Hi Erik,

* Erik Huelsmann  [210206 19:39]:
> I'd like to learn how to properly maintain a package and develop it,
> so I can upload updated packages as part of the release cycle. I've
> not been able to go through any of the steps in the process or
> requirements for it. With the help of someone to show me the right
> first steps, I'm likely able to reach my goal of submitting new
> packages with upstream releases.
> 
> Can you provide me the right pointers on the first steps? I've been a
> long-time Debian user, but never developed any packages myself.

Thanks for wanting to step in!

I believe this is the document one's supposed to read on this:
https://www.debian.org/doc/manuals/maint-guide/

I saw you made some commits to the existing packaging Git
repository, so thats a good start.

"Mentors" is a great place to get help and get your package reviewed
by existing DDs. They also have additional introduction info:
https://mentors.debian.net

Maybe also check by #debian-mentors on IRC.

Given you also filed #981608, is the solution in there enough?
I don't use ledgersmb myself, but it'd be bad for it to fall out of
Debian.

Chris

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Antoine Le Gonidec]

With firefox 85.0.1-1, my extensions installed from Debian repositories are no 
longer disabled on launch.

I made sure to restart Firefox several times to not get tricked by the 
temporary normal behaviour right after a firefox update. I browsed a couple Web 
pages too, to check that the add-ons are actually working and not merely 
showing as active.

- firefox 85.0.1-1
- webext-ublock-origin-firefox 1.32.0+dfsg-1
- webext-umatrix 1.4.0+dfsg-1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?

[John David Anglin]

On 2021-02-07 2:02 p.m., John David Anglin wrote:
> On 2021-02-07 1:49 p.m., Jonas Smedegaard wrote:
>> My guess is that the hppa build daemon is setup differently than other 
>> build daemons, or maybe the hppa hardware need some special magic to 
>> register shared objects.
> One way is to use the environment variable LD_LIBRARY_PATH.  Many packages 
> use it so that ld.so finds libraries that
> haven't been installed in the standard system locations.  If you don't set 
> it, it is possible that the installed system version is used.
Oh, there's nothing special about the handling of shared libraries on 
hppa-linux.  It uses the standard glibc
dynamic linker.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?

[John David Anglin]

On 2021-02-07 1:49 p.m., Jonas Smedegaard wrote:
> My guess is that the hppa build daemon is setup differently than other 
> build daemons, or maybe the hppa hardware need some special magic to 
> register shared objects.
One way is to use the environment variable LD_LIBRARY_PATH.  Many packages use 
it so that ld.so finds libraries that
haven't been installed in the standard system locations.  If you don't set it, 
it is possible that the installed system version is used.

Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#982257: courier: binary-all FTBFS

[Adrian Bunk]

Source: courier
Version: 1.0.14-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=courier=all=1.0.14-1=1609168389=0

...
dh_install
dh_missing --fail-missing
dh_missing: warning: usr/bin/deliverquota exists in debian/tmp but is not 
installed to anywhere 
dh_missing: warning: usr/bin/lockmail exists in debian/tmp but is not installed 
to anywhere 
dh_missing: warning: usr/bin/maildirmake exists in debian/tmp but is not 
installed to anywhere 
dh_missing: warning: usr/bin/makedat exists in debian/tmp but is not installed 
to anywhere (related file: "debian/tmp/usr/lib/courier/makedat")
dh_missing: warning: usr/bin/preline exists in debian/tmp but is not installed 
to anywhere 
dh_missing: warning: usr/lib/courier/mkesmtpdcert exists in debian/tmp but is 
not installed to anywhere (related file: "debian/tmp/usr/sbin/mkesmtpdcert")
dh_missing: warning: usr/sbin/showconfig exists in debian/tmp but is not 
installed to anywhere 
dh_missing: warning: usr/share/man/man1/lockmail.1 exists in debian/tmp but is 
not installed to anywhere 
dh_missing: warning: usr/share/man/man1/maildirmake.1 exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: usr/share/man/man1/makedat.1 exists in debian/tmp but is 
not installed to anywhere 
dh_missing: warning: usr/share/man/man1/preline.1 exists in debian/tmp but is 
not installed to anywhere 
dh_missing: warning: usr/share/man/man5/maildir.5 exists in debian/tmp but is 
not installed to anywhere 
dh_missing: warning: usr/share/man/man7/maildirquota.7 exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: usr/share/man/man8/deliverquota.8 exists in debian/tmp but 
is not installed to anywhere 
dh_missing: error: missing files, aborting

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/lib/courier/makedat
with:
 * usr/bin/makedat
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: courier-base (33), courier-doc (84), courier-faxmail 
(17), courier-imap (15), courier-ldap (8), courier-mlm (8), courier-mta (112), 
courier-pcp (2), courier-pop (18), courier-webadmin (22), sqwebmail (65)
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.
make[1]: *** [debian/rules:155: override_dh_install] Error 25

Bug#982256: spyder-line-profiler FTBFS with Spyder 4.2.1

[Adrian Bunk]

Source: spyder-line-profiler
Version: 0.1.1-1.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=spyder-line-profiler=all=0.1.1-1.1=1612695817=0

...
 ERRORS 
_ ERROR collecting 
.pybuild/cpython3_3.9_spyder-line-profiler/build/spyder_line_profiler/widgets/tests/test_lineprofiler.py
 _
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.9_spyder-line-profiler/build/spyder_line_profiler/widgets/tests/test_lineprofiler.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
spyder_line_profiler/__init__.py:12: in 
from .lineprofiler import LineProfiler
spyder_line_profiler/lineprofiler.py:18: in 
from spyder.plugins import SpyderPluginWidget, runconfig
E   ImportError: cannot import name 'SpyderPluginWidget' from 'spyder.plugins' 
(/usr/lib/python3/dist-packages/spyder/plugins/__init__.py)
--- Captured stdout 
Update LANGUAGE_CODES (inside config/base.py) if a new translation has been 
added to Spyder
--- Captured stderr 
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-buildd'
=== short test summary info 
ERROR spyder_line_profiler/widgets/tests/test_lineprofiler.py
 Interrupted: 1 error during collection 
=== 1 error in 0.65s ===
E: pybuild pybuild:353: test: plugin distutils failed with: exit code=2: cd 
/<>/.pybuild/cpython3_3.9_spyder-line-profiler/build; python3.9 -m 
pytest 
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 
returned exit code 13
make: *** [debian/rules:12: build-indep] Error 25



Compatibility withg Spyder 4 seems to be in the latest upstream version.

Bug#982255: lutris: segfault after cancelling

[Phil Morrell]

Package: lutris
Version: 0.5.8.3-1
Severity: important


Hi Stephan, lutris reliably crashes when following this sequence:

Sources -> Lutris -> Search "epic games" -> Epic Games Store
-> Install -> Cancel -> Yes -> Install

I've attached the full stacktrace from debugging with:

$ sudo apt install python3.9-dbg python3-gi-dbg libglib2.0-0-dbgsym 
libgtk-3-0-dbgsym libffi7-dbgsym
$ gdb -ex r --args python3 /usr/games/lutris
...
Traceback (most recent call first):
  File "/usr/lib/python3/dist-packages/lutris/gui/widgets/window.py", line 
42, in present
super().present()
  File "/usr/lib/python3/dist-packages/lutris/gui/application.py", line 
237, in show_window
self.app_windows[window_key].present()
  File "/usr/lib/python3/dist-packages/lutris/gui/application.py", line 
504, in show_installer_window
"""Callback to remove the game from the running games"""
  File "/usr/lib/python3/dist-packages/lutris/services/lutris.py", line 
150, in install
application.show_installer_window(installers)
  File "/usr/lib/python3/dist-packages/lutris/gui/widgets/game_bar.py", 
line 224, in on_install_clicked
self.service.install(self.db_game)
  File "/usr/lib/python3/dist-packages/gi/overrides/Gio.py", line 43, in run
return Gio.Application.run(self, *args, **kwargs)
  File "/usr/games/lutris", line 567, in 




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

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

Versions of packages lutris depends on:
ii  cabextract   1.9-3
ii  curl 7.74.0-1
ii  fluid-soundfont-gs   3.1-5.2
ii  gir1.2-gnomedesktop-3.0  3.38.3-1
ii  gir1.2-gtk-3.0   3.24.24-1
ii  gir1.2-notify-0.70.7.9-3
ii  gir1.2-webkit2-4.0   2.30.4-1
ii  mesa-utils   8.4.0-1+b1
ii  p7zip16.02+dfsg-8
ii  psmisc   23.3-1
ii  python3  3.9.1-1
ii  python3-dbus 1.2.16-5
ii  python3-distro   1.5.0-1
ii  python3-gi   3.38.0-1+b2
ii  python3-lxml 4.6.2-1
ii  python3-magic2:0.4.20-3
ii  python3-pil  8.1.0-1
ii  python3-requests 2.25.1+dfsg-2
ii  python3-setproctitle 1.2.1-1+b1
ii  python3-yaml 5.3.1-3+b1
ii  unzip6.0-26
ii  x11-xserver-utils7.7+8

Versions of packages lutris recommends:
ii  gvfs-backends1.46.2-1
pn  libwine-development  
ii  python3-evdev1.4.0+dfsg-1
ii  winetricks   0.0+20200412-1

Versions of packages lutris suggests:
pn  gamemode  

-- no debconf information


signature.asc
Description: PGP signature

Bug#981063: offlineimap3: traceback when using "remotepassfile" option

[Sudip Mukherjee]

On Sun, Feb 7, 2021 at 1:15 AM Cyril Brulebois  wrote:
>
> Hi,
>
> Vagrant Cascadian  (2021-01-25):
> > This attached patch fixes the issue for me. I haven't done extensive
> > testing for other use-cases, though it only changes the remotepassfile
> > codepath.
>
> Thanks for the patch! I can confirm this fixes the issue for me as well
> after installing a fresh bullseye system and carrying over my local
> config (from the stretch era).

Thanks to both of you. I am just waiting for the upstream to confirm the fix.


-- 
Regards
Sudip

Bug#982254: O: mp3roaster -- Perl hack for burning audio CDs out of MP3/OGG/FLAC/WAV files

[Chris Hofstaedtler]

> Mp3roaster is a very easy to use and well thought out program to
> record compressed audio files in audio CD format. I maintained it for
> some time, but it didn't require any maintenance for a long
> time... Then it fell out of my radar :-(
>
> Nowadays, I don't own a CD recorder anymore, so I cannot test it. But
> #982232 was filed today, and I cannot commit to a properly tested
> process for it.

To anyone reading this, we also have a package called "mp3burn",
which I fear will share a similar fate. Maybe you, dear reader, are
interested in both.

Chris

Bug#957599: netpbm-free: ftbfs with GCC-10

[Chris Hofstaedtler]

Hi Logan,

* Logan Rosen  [210207 18:53]:
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * d/p/gcc-10.patch: Fix FTBFS with GCC 10.

Thanks for the patch. It appears _our_ GCC 10 also needs -fcommon in
CFLAGS. Not sure why it works for you without that.

Chris

Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?

[Jonas Smedegaard]

Control: tags -1 +help

Hi Dave,

Quoting John David Anglin (2021-02-07 18:03:09)
> Source: libsrtp2
> Version: 2.3.0-5
> Severity: normal
> 
> Dear Maintainer,
> 
> Build fails here:
> + ./rtpw -w /<>/test/words.txt -b 
> Ky7cUDT2GnI0XKWYbXv9AYmqbcLsqzL9mvdN9t/G -a -e 128 -r 0.0.0.0 
> ./rtpw: error while loading shared libraries: libsrtp2.so.1: cannot open 
> shared object file: No such file or directory
> 
> Full log is here:
> https://buildd.debian.org/status/fetch.php?pkg=libsrtp2=hppa=2.3.0-5=1612713361=0

Thans for reporting this.

Sorry, I am clueless as to why it fails - according to that build log, 
libsrtp2.so.1 _did_ get compiled (which to me indicates this is not an 
architecture-specific build failure) and testsuite succeeds on other 
architectures (which to me indicates this is not a failure in the the 
way the testsuite is executed).

My guess is that the hppa build daemon is setup differently than other 
build daemons, or maybe the hppa hardware need some special magic to 
register shared objects.


 - 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#982245: reportbug crashes during initial configuration

[Mikael Petersson]

Den sön 7 feb. 2021 kl 19:16 skrev Nis Martensen :

> (Please keep the bug in cc.)
>
> On 07.02.2021 19.01, Mikael Petersson wrote:
> > Den sön 7 feb. 2021 kl 18:49 skrev Nis Martensen
> > Even if you did not type such a non-ascii address into reportbug, it
> may
> > have picked it up from any of the REPORTBUGEMAIL, DEBEMAIL, or EMAIL
> > environment variables, leading to the crash. Were any of these
> variables
> > defined on your system when you invoked reportbug?
> >
> >
> > No, none of these environment variables are defined.
> >
> > And note that I didn't try to enter any e-mail address at all. I only
> > selected that reportbug will have direct Internet access. The crash came
> > directly after I answered this question.
>
> The crash happened when reportbug tried to guess the email address
> before asking you to confirm/enter it.
>
> If none of these variables were set, do you have any non-ascii
> characters in your /etc/passwd entry or in a corresponding entry in
> /etc/email-adresses?
>

Nope. No non-ascii characters for my user account entry in /etc/passwd. No
non-ascii characters whatsoever as far as I can see. No e-mail address is
specified in my user account entry.

Neither /etc/email-adresses nor /etc/email-addresses exist on my system. I
don't have any MTA installed.

One thing that may stand out a bit in my /etc/passwd entry is my choice of
default shell. I run fish, /usr/bin/fish. But I got the same error after
changing to /bin/bash, running reportbug from a new login session

/Micael

Bug#981609: gnome-activity-journal: missing dependencies on git packages

[Sudip Mukherjee]

Hi Jonas,

On Tue, Feb 02, 2021 at 12:56:52AM +0100, Jonas Smedegaard wrote:
> Package: gnome-activity-journal
> Version: 1.0.0-1
> Severity: important
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Package is missing dependencies on at least these packages:
> 
> gir1.2-gstreamer-1.0
> gir1.2-gnomedesktop-3.0:amd64

Thanks for spotting  this.
'gir1.2-gnomedesktop-3.0' is indeed a dependency, but 'gir1.2-gstreamer-1.0'
is an optional audio preview feature and so I am marking it along with
'gstreamer1.0-gtk3' (which is also an optional video preview feature) as
suggested packages. Please let me know if you think this is wrong.


--
Regards
Sudip

Bug#960153:

[Chris Hofstaedtler]

* Robert Nelson  [210207 18:23]:
> I fixed this locally in our BeagleBoard.org Debian Repo with this quick patch:

> -java -Xmx64m -jar $JAR -storepass "$storepass"
> +java -Xmx64m -XX:-AssumeMP -jar $JAR -storepass "$storepass"

If this helps, someone please explain why this is not a bug in the
used JRE/JDK?
I fail to see how this is a bug in ca-certificates-java.

Chris

Bug#981330: coturn: wrong logic for the dpkg-statoverride handling in coturn.postrm

[Michael Prokop]

* Salvatore Bonaccorso [Sun Feb 07, 2021 at 04:47:40PM +0100]:
> On Fri, Jan 29, 2021 at 01:52:15PM +0100, Michael Prokop wrote:

> > the coturn.postrm uses a wrong logic for the dpkg-statoverride handling,
> > causing to properly handle package (re)installation/removal, quoting from
> > a piuparts run:

> > | Fetched 36.8 MB in 0s (85.1 MB/s)
> > | dpkg: unrecoverable fatal error, aborting:
> > |  unknown system group 'turnserver' in statoverride file; the system group 
> > got removed
> > | before the override, which is most probably a packaging bug, to recover 
> > you
> > | can remove the override manually with dpkg-statoverride
> > | E: Sub-process /usr/bin/dpkg returned an error code (2)

> > I'll provide a PR as soon as I've a bug number from Debian's BTS.

> > FTR: I tend to call this a RC bug, but leaving this up to the
> > maintainer to decide (though it would be great if the package gets
> > fixed for bullseye).

> Not the maintainer here, but I think from policy point of view that
> indeed would be RC. I'm raising the severity with this message.

> Did you looked alreayd into a fix?

Yes, I prepared a PR already:

  https://github.com/coturn/coturn/pull/710

regards
-mika-


signature.asc
Description: Digital signature

Bug#979432: ruby-rack FTBFS on IPV6-only buildds

[Chris Hofstaedtler]

Control: found -1 2.1.4-1
Control: tags -1 - unreproducible

* Chris Hofstaedtler  [210207 18:19]:
> Thanks. However that info appears outdated, as on a current Debian
> unstable, I always get a `lo` interface with 127.0.0.1 and ::1
> bound. The tests want 127.0.0.1, so that works.
> 
> Without more info on how the buildd setup looks like, I cannot
> reproduce this. Or maybe the failure has gone anyway?

So, if I actually do this:
   ip a del 127.0.0.1/8 dev lo

Then the tests indeed crash.

But now that modern kernels apparently always hand one a working
"127.0.0.1", do we really want to bother with this?

I guess one can change all the tests to use ::1 instead of
127.0.0.1, but that will just introduce other failure modes.

Chris

Bug#982254: O: mp3roaster -- Perl hack for burning audio CDs out of MP3/OGG/FLAC/WAV files

[Gunnar Wolf]

Package: wnpp
Severity: normal

Mp3roaster is a very easy to use and well thought out program to
record compressed audio files in audio CD format. I maintained it for
some time, but it didn't require any maintenance for a long
time... Then it fell out of my radar :-(

Nowadays, I don't own a CD recorder anymore, so I cannot test it. But
#982232 was filed today, and I cannot commit to a properly tested
process for it.

So hereby, I am orphaning the mp3roaster package.

The package description is:
 Allows burning audio CDs out of MP3, Ogg Vorbis, FLAC and WAV files. The main
 highlights of this application are an easy to use command line syntax and
 automatic volume leveling support for best audio CD quality.
 .
 In order to normalize the audio level of all files which will be burned on CDs
 MP3roaster requires some free hard disk space.



signature.asc
Description: PGP signature

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

[Étienne Mollier]

Control: forwarded -1 ke...@rosenberg.net

Hi Kevin,

I believe you are both the upstream author and uploader of
ctsim.  Bastian Germann caught a licensing issue[1] in ctsim and
suggested to replace the build dependency on libreadline-dev by
libeditreadline-dev.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979091

I tried this option and only noticed that the configuration file
~/.inputrc didn't seem to be taken into account anymore; I use a
vi style input mode which is caught by libreadline but not by
the libedit.  ctsimtext worked otherwise fine when I proceeded
to my tests when built with libeditreadline-dev.

Would you be okay that further builds of ctsim(text) rely on
libeditreadline-dev, in spite of the minor issue I'm maybe the
only person in the world to notice ?

Alternatively, as upstream developper, would ctsim be suitable
for a later GPL versions than 2 ?

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#982002: buster-pu: package openafs/1.8.2-1

[Adam D. Barratt]

Hi,

On Sat, 2021-02-06 at 11:43 -0800, Benjamin Kaduk wrote:
> Hi Adam,
> 
> On Sat, Feb 06, 2021 at 02:40:02PM +, Adam D. Barratt wrote:
> > On Fri, 2021-02-05 at 09:17 -0800, Benjamin Kaduk wrote:
> > > On Fri, Feb 05, 2021 at 05:11:31PM +, Adam D. Barratt wrote:
> > > > Control: tags -1 + confirmed
> > > > 
> > > > On Fri, 2021-02-05 at 08:38 -0800, Benjamin Kaduk wrote:
> > > > > All upstream openafs releases from the 1.8.x series, prior to
> > > > > 1.8.7,
> > > > > contain a "time bomb" bug that activates when the unix epoch
> > > > > time
> > > > > passes 0x6000 (Thu 14 Jan 2021 08:25:36 AM UTC).
[...]
> > How does this sound as text for an announcement?
[...]
> > If you use OpenAFS, we strongly recommend that you install this
> > update.
> > ===
> 
> That should work well.  Anything I might try to change in order to be
> more precise would just add unnecessary detail, and this conveys the
> important point.

Thanks. That went out earlier today as 
https://lists.debian.org/debian-stable-announce/2021/02/msg1.html

Regards,

Adam

Bug#976462: Bug#631985: Compress debug

[Sean Whitton]

Hello,

On Thu 04 Feb 2021 at 03:20PM -08, Josh Triplett wrote:

> On Mon, 25 Jan 2021 12:01:02 -0700 Sean Whitton  
> wrote:
>> On Mon 07 Nov 2011 at 06:34PM +01, Bastien ROUCARIES wrote:
>> > I agree it could be done by default with compat 9. Will decrease the
>> > size of archive also. I need more than 10G in order to debug kde...
>>
>> Does this sort of thing still apply in 2021?
>
> Yes.
>
> Apart from the running joke that the persistent state of most disks is
> "full", this remains relevant because it can make the difference between
> "leave the debug symbols installed, keep them updated, and be able to
> debug quickly the next time" versus "install debug symbols, debug,
> remove debug symbols until they're next needed".

So, just to confirm, you're saying that you think that you or people you
know would end up doing the latter pretty regularly if we were to decide
to turn off compression?

-- 
Sean Whitton


signature.asc
Description: PGP signature