Bug#995661: ITS: utfcpp

[Mathieu Malaterre]

Hi !

On Sun, Oct 3, 2021 at 8:27 PM Boyuan Yang  wrote:
>
> Source: utfcpp
> Version:  2.3.4-1.1
> Severity: important
> X-Debbugs-CC: ma...@debian.org
>
> Dear package utfcpp maintainers in Debian,
>
> After looking into the package you maintain (utfcpp,
> https://tracker.debian.org/pkg/utfcpp), I found that this package
> received no maintainer updates in the past 8 years with no activity on Debian
> BTS system. As a result, I am filing an ITS (Intent to Salvage) request
> against your package according to section 5.12 in Debian's Developers'
> Reference [1] with the intent to take over package maintenance in Debian.

Thanks for volunteering ! I must admit I have lost interest in this
package. There is no need to add me in the maintainer list, I am not
sure I'll be of great help.

> My current plan is to package the latest upstream release
> on https://github.com/nemtrif/utfcpp and set myself as package maintainer.
>
> Please let me know whether you are still willing to maintain this
> package. According to the criteria listed at [2], I will upload a Non-
> maintainer Upload (NMU) of this package onto Debian unstable with
> DELAYED/7 after 21 days (Oct. 24, 2021) to continue with the package
> salvaging. If you find it necessary to pause the ITS process at any time,
> please let me know immediately by replying this bug report.
>
> [1]
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> [2] https://wiki.debian.org/PackageSalvaging
>
> --
> Regards,
> Boyuan Yang


Thanks,

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Ryan Thoryk]

I posted this to the upstream bug report:

---

After debugging glib for a while, I might've found the issue.  According 
to the documentation of g_quark_from_static_string(), that function 
shouldn't be used to initialize a global variable, but that's how it's 
being used in the crash location in glibmm.


As part of doing symbol checks, Jack loads and unloads the firewire 
module a number of times, that has the glibmm dependency.  Then it loads 
the module normally.  Glibmm initializes each load, it shows the glib 
functions being called each time.  Since the glibmm initialization uses 
the static_string function, glib stores the pointer to the static string 
inside it's hash table and creates a new gquark (the doc says a gquark 
object creation at this stage is too early).  What should be happening, 
is that due to the module unloads, previously stored string references 
become invalid in the hash table, causing a segfault when doing an 
strcmp, the function doc says to not use that function if you're going 
to unload the module.  The hash table's address itself remains the same 
during all of the loads and unloads, showing that it's not being 
unloaded.  The g_quark_from_string() function works, because it creates 
copies of the strings instead, so it's unload-safe.


Unlike what we thought of before, the string that glibmm passes to the 
glib function remains valid all the way to the crash, the culprit is 
that strcmp compares against a pointer to invalid memory that comes from 
the glib hash table.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#995686: RFP: superset -- modern data exploration and visualization platform

[Joseph Nahmias]

Package: wnpp
Severity: wishlist

* Package name: superset
  Version : 1.3.1
  Upstream Author : d...@superset.apache.org
* URL : https://superset.apache.org/
* License : Apache-2.0
  Programming Lang: Python
  Description : modern data exploration and visualization platform

Superset is fast, lightweight, intuitive, and loaded with options that make it
easy for users of all skill sets to explore and visualize their data, from
simple line charts to highly detailed geospatial charts.

Bug#995685: dictionaries-common: Failed to upgrade from 1.28.7

[Nelson A. de Oliveira]

Package: dictionaries-common
Version: 1.28.10
Severity: important

Hi!

While upgrading dictionaries-common from 1.28.7 to 1.28.10:

=
Configurando dictionaries-common (1.28.10) ...
dmihd: No hunspell dir passed or available
dpkg: error processing package dictionaries-common (--configure):
 installed dictionaries-common package post-installation script subprocess 
returned error exit status 2
(…)
dpkg: dependency problems prevent configuration of aspell-pt-br:
 aspell-pt-br depende de dictionaries-common (>= 1.23~); porém:
  Pacote dictionaries-common não está configurado ainda.

dpkg: error processing package aspell-pt-br (--configure):
 problemas de dependência - deixando desconfigurado
(…)
Erros foram encontrados durante o processamento de:
 dictionaries-common
 aspell-pt-br
E: Sub-process /usr/bin/dpkg returned an error code (1)
=

Thank you!

Best regards,
Nelson

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dictionaries-common depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  emacsen-common 3.0.4
ii  libtext-iconv-perl 1.7-7+b1

dictionaries-common recommends no packages.

Versions of packages dictionaries-common suggests:
ii  aspell 0.60.8-4
ii  ispell 3.4.02-2
ii  wbrazilian [wordlist]  3.0~beta4-23

-- debconf information excluded

Bug#995684: llvm-11: missing man pages for most llvm tools

[Nick Gasson]

Package: llvm-11
Version: 1:11.0.1-2
Severity: normal

Dear Maintainer,

The llvm package no longer installs man pages for most LLVM tools like
"llc", "opt", "llvm-as", etc.

I checked manpages.debian.org and it seems these were present in the
llvm-10 package:

https://manpages.debian.org/experimental/llvm-10/index.html


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

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

Versions of packages llvm-11 depends on:
ii  libc62.32-4
ii  libgcc-s111.2.0-7
ii  libllvm111:11.0.1-2
ii  libpfm4  4.11.1+git32-gd0b85fb-1
ii  libstdc++6   11.2.0-7
ii  libtinfo66.2+20201114-4
ii  libz3-4  4.8.12-1+b1
ii  llvm-11-runtime  1:11.0.1-2
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages llvm-11 recommends:
ii  llvm-11-dev  1:11.0.1-2

Versions of packages llvm-11 suggests:
ii  llvm-11-doc  1:11.0.1-2

-- no debconf information

Bug#995683: ITS: latexmk

[Norbert Preining]

Package: latexmk
Version: 1:4.75-0.1
Severity: important
X-Debbugs-Cc: OHURA Makoto , 
debian-tex-ma...@lists.debian.org, m...@qa.debian.org

Dear Ohura-san,

I have tried to contact you over the last years asking for your
permission to take over latexmk into the Debian TeX Task Force.
Unfortunately, despite several attempts, I haven't received either
positive nor negative an answer.

Since the last upload of latexmk done by you has been in 2015 (1:4.41-1),
and since then all uploads have been done by me as NMU, I am now
intending to salvage latexmk according to the procedure laid out in the
developers reference:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

I hope I will here from you about your further intentions, otherwise I
will upload in 21 days to DELAYED/7 a package that puts latexmk into the
Debian TeX Team.

Thanks for your understanding

Norbert



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

Kernel: Linux 5.13.19+futex+ (SMP w/8 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=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages latexmk depends on:
ii  perl5.32.1-6
ii  texlive-latex-base  2021.20210921-1

Versions of packages latexmk recommends:
ii  atril [postscript-viewer]   1.24.0-1+b1
ii  evince [postscript-viewer]  40.4-2
ii  ghostscript [postscript-viewer] 9.54.0~dfsg-5
ii  gv [postscript-viewer]  1:3.7.4-2+b1
ii  mupdf [pdf-viewer]  1.17.0+ds1-2
ii  okular [postscript-viewer]  4:21.08.1-1+b1
ii  qpdfview [pdf-viewer]   0.4.18-5
ii  qpdfview-ps-plugin [postscript-viewer]  0.4.18-5
ii  zathura-pdf-poppler [pdf-viewer]0.3.0-1

Versions of packages latexmk suggests:
ii  ghostscript  9.54.0~dfsg-5

-- no debconf information

Bug#995682: segfaults / fails to find filesystem, when passed full disk

[Trent W. Buck]

Package: fatresize
Version: 1.1.0-1
Severity: normal
File: /sbin/fatresize

This script reliably produces segfaults on Debian 11.
It works fine on Debian 10.




-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
#!/bin/sh -ex
wget -nv 'https://www.freedos.org/download/download/FD12LITE.zip'
unzip FD12LITE.zip
/sbin/parted FD12LITE.img print
truncate --size=64M FD12LITE.img
/usr/sbin/fatresize --info FD12LITE.img || :
/usr/sbin/fatresize --size=max FD12LITE.img || :
/usr/sbin/fatresize --size=64M FD12LITE.img || :
/sbin/parted FD12LITE.img print
coredumpctl info
bash5$ with-temp-dir
with-temp-dir: entering directory `/tmp/with-temp-dir.HWnWLv'
This directory will be deleted when you exit.
bash5$ ~/Desktop/kb/fatresize-problem.sh
+ wget -nv https://www.freedos.org/download/download/FD12LITE.zip
2021-10-04 13:49:46 
URL:http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/FD12LITE.zip
 [30493975/30493975] -> "FD12LITE.zip" [1]
+ unzip FD12LITE.zip
Archive:  FD12LITE.zip
  inflating: FD12LITE.img
  inflating: FD12LITE.vmdk   
  inflating: README.md   
+ /sbin/parted FD12LITE.img print
WARNING: You are not superuser.  Watch out for permissions.
Model:  (file)
Disk /tmp/with-temp-dir.HWnWLv/FD12LITE.img: 32.5MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End SizeType File system  Flags
 1  32.3kB  32.4MB  32.4MB  primary  fat16boot

+ truncate --size=64M FD12LITE.img
+ /usr/sbin/fatresize --info FD12LITE.img
fatresize 1.1.0 (20201114)
part(start=0, end=131071, length=131072)
Error: Could not detect file system.
+ :
+ /usr/sbin/fatresize --size=max FD12LITE.img
fatresize 1.1.0 (20201114)
part(start=0, end=131071, length=131072)
Error: Could not detect file system.
+ :
+ /usr/sbin/fatresize --size=64M FD12LITE.img
fatresize 1.1.0 (20201114)
part(start=0, end=131071, length=131072)
Segmentation fault (core dumped)
+ :
+ /sbin/parted FD12LITE.img print
WARNING: You are not superuser.  Watch out for permissions.
Model:  (file)
Disk /tmp/with-temp-dir.HWnWLv/FD12LITE.img: 67.1MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End SizeType File system  Flags
 1  32.3kB  32.4MB  32.4MB  primary  fat16boot

+ coredumpctl info
   PID: 3878651 (fatresize)
   UID: 1000 (twb)
   GID: 1000 (twb)
Signal: 11 (SEGV)
 Timestamp: Mon 2021-10-04 13:49:46 AEDT (820ms ago)
  Command Line: /usr/sbin/fatresize --size=64M FD12LITE.img
Executable: /usr/sbin/fatresize
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-decd9040-9743-4d37-8dc7-24ab214ad59f.scope
  Unit: user@1000.service
 User Unit: vte-spawn-decd9040-9743-4d37-8dc7-24ab214ad59f.scope
 Slice: user-1000.slice
 Owner UID: 1000 (twb)
   Boot ID: a604735c949746bcb36ab91b0fca536f
Machine ID: 029d2e3fb4ee4d5eaa67c315db3ba66d
  Hostname: hera
   Storage: 
/var/lib/systemd/coredump/core.fatresize.1000.a604735c949746bcb36ab91b0fca536f.3878651.163331578600.zst
   Message: Process 3878651 (fatresize) of user 1000 dumped core.

Stack trace of thread 3878651:
#0  0x7fc81eb9d419 ped_disk_get_partition_by_sector 
(libparted.so.2 + 0x13419)
#1  0x55ce2c7a9c8a n/a (fatresize + 0x2c8a)
#2  0x7fc81e9ece4a __libc_start_main (libc.so.6 + 0x27e4a)
#3  0x55ce2c7aa15a n/a (fatresize + 0x315a)
bash5$ mmdebstrap  --aptopt='Acquire::http::Proxy "http://odin:3142;' 
--dpkgopt=force-unsafe-io --variant=apt buster /dev/null 
--include=parted,fatresize,wget,ca-certificates,unzip --customize-hook='copy-in 
fatresize-problem.sh /' --customize-hook='chroot $1 ./fatresize-problem.sh'
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.toKs23Dbpl as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: installing remaining packages inside the chroot...
done
done
done
I: running special hook: copy-in fatresize-problem.sh /
I: running --customize-hook in shell: sh -c 'chroot $1 ./fatresize-problem.sh' 
exec 

Bug#995672: cockpit-machines: 253-1 fails to build via apt-src

[Friedemann Schorer]

Package: cockpit-machines
Version: 253-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Dear Maintainer,

Got the latest source packages for cockpit-machines 253-1, unpacked them
locally via 'dpkg-source -x', made the source known to apt-src ('apt-src
import cockpit-machines --location cockpit-machines-253') and tried to
build it.
Here's the output:

 ~/build: apt-src list  
   
i   cockpit-machin 253-1  /home/frschorer/build/cockpit-machines-253   
 ~/build: apt-src build cockpit-machines
  
E: Not installed

When I import the sourcetree of cockpit 254-1 from unstable sources,
too,  and then try to build cockpit-machines apt-src builds the other cockpit 
packages instead.

I build a few packages through apt-src and never had this problem with any 
source package before, neither cockpit related packages nor others.

Pls let me know if you need additional info - I'd be happy to provide it
if possible.

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

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

Versions of packages cockpit-machines depends on:
ii  cockpit-bridge 254-1
ii  libvirt-clients5.0.0-4+deb10u1
ii  libvirt-daemon-system  5.0.0-4+deb10u1
ii  libvirt-dbus   1.3.0-1

Versions of packages cockpit-machines recommends:
ii  gir1.2-libosinfo-1.0  1.2.0-1
ii  python3-gi3.30.4-1
pn  qemu-block-extra  
pn  virtinst  

cockpit-machines suggests no packages.

-- no debconf information

Bug#995601: additional data

[Mike Gabriel]

On  So 03 Okt 2021 00:58:33 CEST, Mike Kupfer wrote:


I just realized that Bullseye also has mate-panel 1.24.1-1.  But I don't
see the compression problem with my Bullseye VM, just with the systems
that are running Bookworm.

Also, on my Bookwork VM, if I tell the applet to display the workspaces
in 2 rows, they have the correct dimensions.  If I go back to displaying
the workspaces in 1 row, they go back to being taller than wide.

regards,
mike


It would be ideal, if you could send some screenshots...

Thanks,
Mike
--

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

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



pgpcapqG0W3zn.pgp
Description: Digitale PGP-Signatur

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

[Christoph Anton Mitterer]

On Mon, 2021-10-04 at 02:21 +0200, Guilhem Moulin wrote:
> I don't recall why I used mawk in
> b0b8e3e88fecf2f8f5f5a3ad39b68e56a9e53427,
> but it might be simply because it was advertized as “smaller and much
> faster than gawk” in addition of being ‘Priority: required’.  Fair
> enough, exectution speed is probably irrelevant for an interactive
> completion script :-)

Hmm I wonder then, why gawk has higher priority than makw in the
alternatives system.
Maybe one should suggest them to change that if it's really faster.


Cheers,
Chris.

Bug#995681: poppler-utils: pdftocairo generates incorrect png with -antialias best

[Erik Saule]

Package: poppler-utils
Version: 20.09.0-3.1
Severity: normal
X-Debbugs-Cc: esa...@uncc.edu

Dear Maintainer,

When running pdftocairo using :

pdftocairo -png -antialias best beamer.pdf

the output is "weird". Shapes appear to be correct, but fonts are
messed up in a way I don't quite understand. I tried it with multiple
pdfs coming from latex beamer and from latex article.

Not specifying -antialias gives a result that looks correct.

(Attaching the pdf file and the obtained PNG output for reference.)

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

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

Versions of packages poppler-utils depends on:
ii  libc6  2.31-13
ii  libcairo2  1.16.0-5
ii  libfreetype6   2.10.4+dfsg-1
ii  liblcms2-2 2.12~rc1-2
ii  libpoppler102  20.09.0-3.1
ii  libstdc++6 10.2.1-6

poppler-utils recommends no packages.

poppler-utils suggests no packages.

-- no debconf information


beamer.pdf
Description: Adobe PDF document

Bug#995680: base-files /etc/profile PATH snafu

[Don Scott]

Package: base-files
Version: 11.1
Severity: normal
Tags: d-i
X-Debbugs-Cc: borealcoy...@gmail.com

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


*** /home/don/bug_reports/bug_base
likely package: base-files

Recently, I had the pleasure of installing Debian 11.0.0 AMD64 on an older 
Celeron 1800 desktop system.

Initially, the vast majority of the console executables would not run, 
either as a user or as root, and generated only a "command not found" message. 
Fortunately, there was a (perhaps too) easy fix, documented below.

In the /etc/profile file, the following changes were made, and these fixed 
the problem by reconfiguring the PATH environment variable. Admittedly, 
this simple solution might be a bad hack in a more complex installation. 
But, at least, this hatchet job might prove slightly instructive.

This section was removed:

if [ "$(id -u)" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

This section was created by cutting it down, and used to replace it:

 PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
/usr/local/games:/usr/games" 
export PATH

Once this was done, every console executable worked.







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

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

Versions of packages base-files depends on:
ii  gawk [awk]  1:5.1.0-1
ii  mawk [awk]  1.3.4.20200120-2

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Ryan Thoryk]

I found that my edits were affecting the wrong file (I was working on a 
cached file instead, there were multiple copies of the code), and so my 
string modification doesn't actually work, it results in the same segfault.


Changing the function to q_quark_from_string() works.

--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

[Guilhem Moulin]

On Mon, 04 Oct 2021 at 01:17:36 +0200, Christoph Anton Mitterer wrote:
> And as you said, since we only use the POSIX subset, I thought it would
> be an improvement to use awk, and not fail in even the above situation.

I don't recall why I used mawk in b0b8e3e88fecf2f8f5f5a3ad39b68e56a9e53427,
but it might be simply because it was advertized as “smaller and much
faster than gawk” in addition of being ‘Priority: required’.  Fair
enough, exectution speed is probably irrelevant for an interactive
completion script :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#995679: exim4: FTBFS on sparc64 due to bad alignment (Bus Error)

[John Paul Adrian Glaubitz]

Source: exim4
Version: 4.95-1
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello!

The testsuite fails on sparc64 with a Bus Error which indicates improper
alignment [1]:

Debian-exim user found, running minimal testsuite

running minimal functionality test for binary 
b-exim4-daemon-heavy/build-Linux-sparc64/exim in directory /<>/test
Bus error
testsuite error

I have not debugged this issue yet but usually these are trivial to fix.

Since the sparc64 porterbox kyoto is currently looking for a new hosting
location, it's offline. In the mean time, the sparc64 porterboxes from
the GCC compile farm can be used for debugging the issue [2].

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=exim4=sparc64=4.95-1=1633268716=0
> [2] https://gcc.gnu.org/wiki/CompileFarm

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Sean Whitton]

Hello,

On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote:

> On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote:
>> You write:
>>
>> >> - Because Debian 11 installations with the non-merged-/usr layout already
>> >>   exist, all packages in Debian 12 should be installable onto a 
>> >> non-merged-/usr
>> >>   system along with their dependencies, and work correctly on the 
>> >> resulting
>> >>   system.
>>
>> (1) The reason for this, to put it a bit simplistically, is that we
>> don't require apt to perform the upgrade between stable releases in any
>> particular order, right?  Or are there other reasons distinct from this
>> one that I'm missing?  I think it would be good to state the thing about
>> apt (in better language than mine) in the text.
>
> I think that's the main reason. We have not traditionally mandated
> the use of a special upgrade tool like Ubuntu's do-release-upgrade(8),
> so the upgrade happens in whatever order apt chooses, which can vary
> between machines.
>
> Another reason why I think we want Debian 12 packages to be installable
> onto non-merged-/usr systems is that to be able to do our development work,
> they need to be installable onto testing/unstable systems, which (again)
> means that the upgrade order is undefined.

Right, we're on the same page then, but would you agree with me that the
resolution should state this justification explicitly?

> We also have best-effort support for partial upgrades, either
> oldstable -> stable or stable -> testing/unstable: upgrading only a
> subset of the available packages, plus their mandatory dependencies,
> but without also upgrading apparently-unrelated packages. This can
> only ever be partially supported, because it leads to a combinatorial
> explosion of possible partially-upgraded systems, and realistically we
> can never test them all; but I think it's best if we try to avoid
> knowingly making this worse.

I'd suggest we don't mention this as it's much more obscure and the
above is sufficient justification.

>> (2) Some people on -devel would seem to think that we can have smooth
>> upgrades from bullseye to bookworm without requiring support for
>> non-merged-/usr in every single package in bookworm, i.e., without
>> supporting non-merged-/usr for testing/unstable installations during the
>> current release cycle.
>
> Some people on -devel have argued that it would be OK to require use of
> a special upgrade tool analogous to Ubuntu's do-release-upgrade just this
> once, or that it would be OK to require a particular upgrade sequence. For
> example, we could ask users to install the usrmerge package first, and
> then upgrade; or if dpkg is modified to special-case the merged-/usr
> aliasing symlinks, then we might ask users to upgrade dpkg first, and
> then upgrade the rest of the system.
>
> I think there is considerable anecdotal evidence that many Debian users
> do not read the release notes, and if we ask them to carry out an upgrade
> procedure more complicated than
>
> $editor /etc/apt/sources.list && apt update && apt full-upgrade
>
> they will often ignore that request and still expect their upgrade to
> work (because in practice it often does, and we've been training users
> to expect that for years). That makes me reluctant to require a special
> upgrade procedure if it is not strictly necessary.

This is persuasive.  What do you think about including it in the text?
Specifically, mentioning that we are deciding, for the project, that
we are not going to do this using something like do-release-upgrade(8).

>> What smcv has been arguing for is the most conservative option.  But
>> which of the following is it the TC wants to say:
>>
>> - we are sure that this is the only way to ensure smooth upgrades, such
>>   that it pretty much follows from our previous decision on merged-/usr
>>
>> - we think there might be viable alternatives to requiring every package
>>   in bookworm to work on both layouts, but we aren't sure they are safe
>>   enough, so we're recommending a simple and conservative approach
>>
>> - we think that ensuring non-merged-/usr testing/unstable installations
>>   work during this release cycle is reason enough to take this highly
>>   conservative approach
>
> I'm honestly not sure which of these is "the" reason why I'm recommending
> the conservative approach. Some combination of your second and third
> points, I suppose?

Based on what you say above I think it's the second and third, indeed.
If we add to the text the things I'm suggesting we add, I think this
sort of query about our motivations will not arise in the minds of
readers.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#995677: zephyr: Maintainer field gives syntax errors in DDPO & BLS cron jobs

[Paul Wise]

Source: zephyr
Version: 3.1.2-2
Severity: normal

The new Maintainer field for zephyr 3.1.2-2 in experimental
gives syntax warnings in the DDPO and BLS cron jobs:

   /srv/qa.debian.org/data/cronjobs/ddpo
  /srv/qa.debian.org/ftp/debian/dists/experimental/main/source/Sources.xz:0:
  syntax error in team+zephyr...@tracker.debian.org at 
../extract_archive.pl line 101.
   
   /srv/qa.debian.org/data/cronjobs/bls
  Cannot parse uploader «team+zephyr...@tracker.debian.org
  » from package ('zephyr', 0, 1, 0, 0)

Looking at other packages using tracker.d.o, this should fix it:

   Maintainer: Zephyr Packaging Team 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#995676: kmymoney FTBFS in bookworm.

[peter green]

Package: kmymoney
Version: 5.1.2-1
Severity: serious

While working on completing the kde transition in Raspbian bookworm I ran into 
a build
failure of kmymoney.

http://buildd.raspbian.org/status/fetch.php?pkg=kmymoney=armhf=5.1.2-1=1633154962


In file included from 
/<>/kmymoney/plugins/kbanking/dialogs/kbmapaccount.cpp:18:
/<>/kmymoney/plugins/kbanking/dialogs/../kbanking.h:161:49: error: 
expected ';' at end of member declaration
  161 | bool updateAccount(const MyMoneyAccount& acc) DEPRECATED;
  | ^
  |  ;
/<>/kmymoney/plugins/kbanking/dialogs/../kbanking.h:161:51: error: 
'DEPRECATED' does not name a type; did you mean 'QT_DEPRECATED'?
  161 | bool updateAccount(const MyMoneyAccount& acc) DEPRECATED;
  |   ^~
  |   QT_DEPRECATED


This is also happening on the reproducible builds tests for bookworm, on
all architectures tested by reproducible builds (amd64, i386, arm64 and armhf)
so it's not a raspbian specific issue.

I do not know if this also affects sid, the reproducible builds tests for sid 
are
showing a pass, but they were last run about a month ago, so something may have
changed in the meantime.

To get the package building in raspbian, I simply removed the DEPRECATED, I
don't know whether that is the best fix though.

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

[Christoph Anton Mitterer]

On Mon, 2021-10-04 at 00:47 +0200, Guilhem Moulin wrote:
> So?  I fail to see how that's relevant.  See §2.5 of the Debian
> Policy.

Well it means that the average user wouldn't get a warning if he
replaces e.g. mawk by gawk or original awk.

And as you said, since we only use the POSIX subset, I thought it would
be an improvement to use awk, and not fail in even the above situation.


Cheers,
Chris.

Bug#995675: python3-rdflib: new upstream release 6.0.0 (and 6.0.1)

[Jonas Smedegaard]

Package: python3-rdflib
Version: 5.0.0-1.1
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

New major upstream release is out since a few months: 6.0.0.
A minor followup bugfix release is aout as well: 6.0.1.

Please package either of these, both for their numerous bugfixes
and since it is a requirement of recent releases of ontospy.

Raised severity due to the need by ontospy.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFaNzgACgkQLHwxRsGg
ASH9AhAAoCuH3u2pjNz3Uv7VFrUzV48fEaD9VQylo/T7sV7g56N1IWHZ0eaItOpI
9MLTutcM34ysORVJLTRZpfWMFICFJkD8HKT9fdOWMv8a1K6086zVa3noyn0F1gJ1
Nj4bPtAm1C1CRE01tR8EBwsfio3rLOewO0H9h9adzwUIGhMHTyFuT2llSHqiot76
IHJJxjZoIb5lX7n5+yPBq0dzXz4Yp7eSHpGX/x7QfhtwaAMfGDp7Ly4OE0BDDjZU
PuUMXsFuNO1xJEp7+F9B2qoi8nPhqru45AxpK3F6JDWj6QOeW/LuXRrHkkDnma1E
1Zg9pt/ZJPEgmavj1Odwh6s07oyNBFkpEt3RT1kN8wts+hJWdVtCUaJBoAWqhdhT
gYyn83dDYUmTob03OSxKqcQNy+AvF6ubY84zI5aCU30Gc+c5rmoE1vzB1iZcGDDm
raxlmZnXdQY/i7ITg+jXyxqLzGOdcz9z05DQuk29zbb0HTVozKJYMswjw4koxCTk
IjQFVh08+esfvdQ13fcruK7K9IZRt4bgHP0g7j6bk+wywxL/7RnVmmy//BbCsWFV
CdKmHGkjcMuHWgauXhC1duju03yw43yzHEw/SgstlLj+Av3TsrEbluCSTIZamwbc
SC7vlvhv8Ztt/fQdcAlIH5dg5cCjjnA2uA0OKTOOZd2HntOoPXE=
=zTBU
-END PGP SIGNATURE-

Bug#995673: linux-image-5.10.0-8-amd64: Iomega Zip ppa and imm modules not compiled

[Alejandro Sánchez]

Package: src:linux
Version: 5.10.46-4
Severity: wishlist
X-Debbugs-Cc: w...@cuadernoinformatica.com

Dear Maintainer,

There are still working Iomega ZIP drives that may need to be used to retrieve 
information on disks or move information to other older systems using Iomega 
ZIP drives.

-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=8581ab16-9154-40b9-ad83-462170e3737c ro

** Not tainted

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

** Model information
sys_vendor: Acer
product_name: AOD270
product_version: V1.10
chassis_vendor: Chassis Manufacturer
chassis_version: Chassis Version
bios_vendor: Insyde Corp.
bios_version: V1.10
board_vendor: Acer
board_name: JE01_CT 
board_version: Base Board Version

** Loaded modules:
ctr
aes_generic
libaes
crypto_simd
cryptd
glue_helper
ccm
cpufreq_powersave
cpufreq_conservative
cpufreq_userspace
cpufreq_ondemand
binfmt_misc
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
ath9k
snd_hda_codec_hdmi
ath9k_common
snd_hda_intel
ath9k_hw
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
ath
uvcvideo
videobuf2_vmalloc
videobuf2_memops
mac80211
snd_compress
videobuf2_v4l2
soundwire_cadence
videobuf2_common
snd_hda_codec
intel_powerclamp
cfg80211
videodev
coretemp
snd_hda_core
joydev
mc
evdev
snd_hwdep
pcspkr
acer_wmi
gma500_gfx
serio_raw
soundwire_bus
sparse_keymap
wmi_bmof
snd_pcm
at24
snd_timer
drm_kms_helper
sg
rfkill
snd
libarc4
cec
soundcore
i2c_algo_bit
ac
button
acpi_cpufreq
parport_pc
ppdev
lp
parport
drm
fuse
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
rtsx_pci_sdmmc
ahci
mmc_core
libahci
ehci_pci
uhci_hcd
libata
ehci_hcd
usbcore
scsi_mod
psmouse
r8169
realtek
mdio_devres
libphy
i2c_i801
rtsx_pci
i2c_smbus
lpc_ich
usb_common
battery
wmi
video

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Atom Processor D2xxx/N2xxx DRAM 
Controller [8086:0bf1] (rev 03)
Subsystem: Acer Incorporated [ALI] Atom Processor D2xxx/N2xxx DRAM 
Controller [1025:061f]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: gma500
Kernel modules: gma500_gfx

00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition 
Audio Controller [8086:27d8] (rev 02)
Subsystem: Acer Incorporated [ALI] NM10/ICH7 Family High Definition 
Audio Controller [1025:061f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
2 [8086:27d2] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.2 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
3 [8086:27d4] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI 
Controller #1 [8086:27c8] (rev 02) (prog-if 00 [UHCI])
Subsystem: Acer Incorporated [ALI] NM10/ICH7 Family USB UHCI Controller 
[1025:061f]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 

Bug#995674: libvips-doc: unable to open '/usr/share/gtk-doc/html/libvips/index.html.dpkg-new'

[Jérémy Lal]

Package: libvips-doc
Version: 8.10.5-2
Severity: important

Hi,

i got this error:

Preparing to unpack .../libvips-doc_8.11.4-1_all.deb ...
Unpacking libvips-doc (8.11.4-1) over (8.10.5-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/libvips-doc_8.11.4-1_all.deb (--unpack):
 unable to open '/usr/share/gtk-doc/html/libvips/index.html.dpkg-new': No such 
file or directory
Errors were encountered while processing:
 /var/cache/apt/archives/libvips-doc_8.11.4-1_all.deb


Cheers,
Jérémy

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

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

-- no debconf information

-- debsums errors found:
debsums: missing file /usr/share/gtk-doc/html/libvips/index.html (from 
libvips-doc package)

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

[Guilhem Moulin]

Control: tag -1 = pending

On Mon, 04 Oct 2021 at 00:09:41 +0200, Christoph Anton Mitterer wrote:
> On Sun, 2021-10-03 at 22:14 +0200, Guilhem Moulin wrote:
>> mawk has ‘Priority: required’ and is expressive enough for this
>> use-case.  Why should we use something else?
> 
> Well, at least it's not Essential.

So?  I fail to see how that's relevant.  See §2.5 of the Debian Policy.

> E.g. base-files (Pre-)Depends simply on the virtual Package awk, which
> is provided by all three implementations.
> 
> There also seem to be much more packages which depend on e.g. gawk (66)
> than on mawk (16).

There might be reasons to depend on gawk, but that seems irrelevant for
the case at hand.  Also these numbers are skewed since ‘Priority:
required’ packages don't need explicit unversioned Depends.

Anyway, did s/mawk/awk/ if that makes you happy…  We are only using
functions from the POSIX subset so any implementation should work,
including busybox's.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#995417: bug is RC

[Dominik George]

Control: severity -1 grave

This is actually an RC bug as the requests-oauthlib version currently
in Debian does not work with the oauthlib version currently in Debian.


signature.asc
Description: PGP signature

Bug#994750: RFS: mazeofgalious/0.63-1 [ITA] -- The Maze of Galious

[Bastian Germann]

Control: tags -1 moreinfo

On Mon, 20 Sep 2021 15:24:23 +0200 Parodper  wrote:

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: mazeofgalious
Version : 0.63-1
Upstream Author : Pablo 
  * URL : http://www.braingames.getput.com/mog/
  * License : GPL-2
Section : games

It builds those binary packages:

   mazeofgalious-data - The Maze of Galious (data)
   mazeofgalious - The Maze of Galious

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


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

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

   dget -x 
https://mentors.debian.net/debian/pool/main/m/mazeofgalious/mazeofgalious_0.63-1.dsc


Changes since the last upload:

  mazeofgalious (0.63-1) unstable; urgency=medium
  .
* Updated files from upstream (Closes: #661454, #503500, #737971, 
#923263).

* Also modified start.pcx images, as specified in #341501


Please have a look at the package repacking history. There are graphics, sounds, 
and konami.pcx excluded. You must not reintroduce them without any good reason 
(like license change).

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Sat, Sep 25, 2021 at 11:31:41AM +0100, Simon McVittie wrote:
> This seems a good opportunity to ask what I think is a key question here:
> what do you consider debianutils' mission to be?

The package description uses the phrases "specific to Debian" and
"installation scripts of Debian packages".  The fact that
debianutils is used on non-deb operating systems suggests a failure
at the former.  The fact that 95% of my inbox consists of hatemail
about the interactive usage of `which` suggests a failure at the
latter.

debianutils should consist solely of utilities that are actually
deserving of Essential status, that are maintained by debianutils
upstream, and do not needlessly duplicate functionality provided by
other sources.

Divestiture of mktemp, readlink, sensible-editor, sensible-pager,
sensible-browser, tempfile, and possibly mkboot were adjustments
toward a better debianutils.

mktemp and readlink have been replaced by superior versions.
sensible-* live in a non-Essential package in which presumably
someone cares about them.  tempfile and mkboot are no longer
around to confuse people.  Did people see these things as
progress when they happened?  I would imagine that the people
who were verbally abusing me and flinging stop energy around
at the time did not.  Does anyone really miss the old debianutils
mktemp now?

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

[Christoph Anton Mitterer]

On Sun, 2021-10-03 at 22:14 +0200, Guilhem Moulin wrote:
> mawk has ‘Priority: required’ and is expressive enough for this
> use-case.  Why should we use something else?

Well, at least it's not Essential.

E.g. base-files (Pre-)Depends simply on the virtual Package awk, which
is provided by all three implementations.

There also seem to be much more packages which depend on e.g. gawk (66)
than on mawk (16).


So if your awk snippet runs with all implementations, why not simply
depending on awk... and use the /usr/bin/awk alternative?


Cheers,
Chris.

Bug#995625: httping FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[Abhijith PA]

Thank you folkert. I will be very happy to take the patch, if you have 
committed in upstream repo. :)


--abhijith 


On 03/10/21 07:49 PM, folkert wrote:
> replace it by:
> 
> wprintw(w, "%s", what);
> 
> On Sun, Oct 03, 2021 at 07:48:19AM +0200, Helmut Grohne wrote:
> > Source: httping
> > Version: 2.5-5.1
> > Severity: serious
> > Tags: ftbfs
> > 
> > httping fails to build from source in unstable on amd64. A non-parallel
> > build ends as follows:
> > 
> > | x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wextra 
> > -pedantic -D_FORTIFY_SOURCE=2  -DVERSION=\"2.5\" 
> > -DLOCALEDIR=\"/usr/share/locale\" -DTCP_TFO -DNC -DFW -D_DEBUG -ggdb 
> > -Wdate-time -D_FORTIFY_SOURCE=2  -c -o nc.o nc.c
> > | nc.c: In function ???myprint???:
> > | nc.c:238:3: error: format not a string literal and no format arguments 
> > [-Werror=format-security]
> > |   238 |   wprintw(w, what);
> > |   |   ^~~
> > | nc.c: In function ???draw_graph???:
> > | nc.c:611:24: warning: unused parameter ???val??? [-Wunused-parameter]
> > |   611 | void draw_graph(double val)
> > |   | ~~~^~~
> > | nc.c: In function ???status_line???:
> > | nc.c:389:2: warning: ignoring return value of ???vasprintf??? declared 
> > with attribute ???warn_unused_result??? [-Wunused-result]
> > |   389 |  vasprintf(, fmt, ap);
> > |   |  ^
> > | cc1: some warnings being treated as errors
> > | make[1]: *** [: nc.o] Error 1
> > | make[1]: Leaving directory '/<>'
> > | dh_auto_build: error: make -j1 returned exit code 2
> > | make: *** [debian/rules:10: build] Error 25
> > | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> > status 2
> > 
> > This is likely caused by ncurses adding format string annotations.
> > 
> > Helmut
> 
> 
> Folkert van Heusden
> 
> -- 
> MultiTail ist eine flexible Applikation um Logfiles und Kommando
> Eingaben zu überprüfen. Inkl. Filter, Farben, Zusammenführen,
> Ansichten etc. http://www.vanheusden.com/multitail/
> --
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Bug#693230: ITA: multimail -- Offline reader for BW, QWK,OMEN and SOUP

[Bastian Germann]

On Tue, 7 Jan 2020 19:38:21 -0300 Fernando Toledo  
wrote:

FYI:

I just upload to mentors with some fixes again:

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


Hi Fernando,

Are you still willing to maintain the package?
If not so, please reset to orphan state.

As your mentors upload is gone, this short review addresses your GitHub version.

d/changelog
===
Please merge all three changelog entries that have not appeared in Debian yet 
into one. Especially drop "Non-maintainer upload", "New snapshot from upstream" 
and one of the "New maintainer" entries in the process.


d/upstream/metadata
===
I do not see that you are the upstream maintainer, so please do not claim that.

d/compat

Do not use the deprecated v11 debhelper compat.

d/control
=
Please use debhelper-compat so that you can drop the compat file.

d/copyright
===
I think the licenses are complete. But please add missing copyright statements 
from University of Washington and Peter Krefting.


Thanks,
Bastian

Bug#995125: linux: Realtek ethernet driver r8169 lacks support for chip chip XID 54b

[Wright, Randy (HPE Servers Linux)]

I am pleased to report that commit e6d6ca6e12049dfbff6ac8b029678d2d2c55c34f 
does provide the
support for chip XID 54b.   However, I had to apply two other patches, and 
temporarily revert and
then re-apply a third patch to apply to the linux-source-5.10 kernel version  
5.10.46-5.

Attached is the bash script I used to apply the patches, which are the 
following:

389cb1ecc86e6c6f210424017cf930a81ddfbf2d..e6d6ca6e12049dfbff6ac8b029678d2d2c55c34f.patch
e6e918d4eb93f43e770fbc2a0881686e350e1a1f..c6cff9dfebb3387fa72570af70c9ea34b9e24550.patch
0a7e0c3b5702a6a76cf7e5b8cc10a73e51dc221e..abbf9a0ef8848dca58c5b97750c1c59bbee45637.patch
206a75e003e17aad4fd60047deee2252fdc3df38..e0d38b5880758432f74fe17fea8281691d1eb3c0.patch

With the patch built in, success is seen in dmesg logs, and NetworkManager uses 
the nic with no problems.
[0.00] Linux version 5.10.46-rfw (rfw@pd400) (gcc (Debian 10.2.1-6) 
10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Sat Oct 2 
10:35:02 MDT 2021
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.46-rfw 
root=UUID=85ed9906-0d36-41ca-bfdf-9434fe5ecd2c ro loglevel=9 efi=debug 
nohibernate noresume panic=30 systemd.unit=multi-user.target
[0.015860] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.10.46-rfw 
root=UUID=85ed9906-0d36-41ca-bfdf-9434fe5ecd2c ro loglevel=9 efi=debug 
nohibernate noresume panic=30 systemd.unit=multi-user.target
[2.056883] BOOT_IMAGE=/boot/vmlinuz-5.10.46-rfw
[2.464025] usb usb1: Manufacturer: Linux 5.10.46-rfw ehci_hcd
[6.670346] r8169 :04:00.1: can't disable ASPM; OS doesn't have ASPM 
control
[6.690573] libphy: r8169: probed
[6.695550] r8169 :04:00.1 eth0: RTL8168fp/RTL8117, b0:22:7a:22:c7:e7, 
XID 54b, IRQ 85
[6.698093] r8169 :04:00.1 eth0: jumbo features [frames: 9194 bytes, tx 
checksumming: ko]
[7.056330] r8169 :04:00.1 eno1: renamed from eth0
[7.912710] Generic FE-GE Realtek PHY r8169-401:00: attached PHY driver 
[Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-401:00, irq=IGNORE)
[8.042714] r8169 :04:00.1 eno1: Link is Down
[   10.467835] r8169 :04:00.1 eno1: Link is Up - 1Gbps/Full - flow control 
rx/tx

- Randy Wright   rwri...@hpe.com



patchit.sh
Description: patchit.sh

Bug#995671: python3-dnspython: There is a new version, 2.1, since January 2021

[Paul Hoffman]

Package: python3-dnspython
Version: 2.0
Severity: normal


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

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

Versions of packages python3-dnspython depends on:
ii  python3  3.7.3-1

python3-dnspython recommends no packages.

python3-dnspython suggests no packages.

Bug#995670: ITP: zig -- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software

[Jason Ernst]

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

* Package name: ziglang
  Version : 0.8.1
  Upstream Author : Andrew Kelley and...@ziglang.org
* URL : https://ziglang.org
* License : MIT
  Programming Lang: Zig
  Description : General-purpose programming language and toolchain for 
maintaining robust, optimal, and reusable software

Zig is quickly become a new hot language, and there is growing demand for it
to be available in mainline repositories.

There is a ticket on the Zig repo: https://github.com/ziglang/zig/issues/7340
which requests for mainline packages to be available, and the upstream
maintainer replied that it is out of scope of their repository. I would like to
volunteer to package this and maintain it so it is available easily. Others are
making similar efforts in other distributions such as Fedora.

I also have a package which pulls the release and packs it using checkinstall
at https://github.com/compscidr/zig-deb which is currently hosted from a 
3rd party gemfury repository.

For now I am happy to maintain myself, but would more than welcome anyone who
would like to form a pkg-zig team (unless people feel there is a more 
appropriate team this could fit into. Co-maintainers are also welcome. I do
need a sponsor, this is my first time participating.

Bug#995341: Highly inappropriate behavior which the RT should be aware of

[Holger Levsen]

On Fri, Oct 01, 2021 at 11:48:48AM +0200, Diederik de Haas wrote:
> I want to make sure that you're aware of what I consider HIGHLY inappropriate 
> behavior by Chuck where he is trying to sidestep/override the Xen maintainers 
> by filing this bug directly to the release.debian.org pseudo package.

why don't you give Chuck more slack and assume he filed this bug the way he did
with the best intentions? really.

and even if that would be wrong, treating it this way would not be wrong. :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Fischers Fritz fischt Plastik.


signature.asc
Description: PGP signature

Bug#995669: ofono: New upstream version available

[Boyuan Yang]

Package: ofono
Severity: normal
Version: 1.31-3
Tags: sid booksworm
X-Debbugs-CC: zu...@debian.org bi...@debian.org

Dear Debian ofono package maintainers,

A new upstream release for package ofono is available at
https://www.kernel.org/pub/linux/network/ofono/ofono-1.33.tar.xz . Please
consider packaging it in Debian.

Thanks,
Boyuan Yang


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

Bug#995657: clevis: FTBFS with OpenSSL 3.0

[Christoph Biedl]

Control: tags 995657 fixed-upstream

Kurt Roeckx wrote...

> Your package is failing to build using OpenSSL 3.0 with the
> following error:
(...)

Without having checked, I'm fairly confident upstream commit

https://github.com/latchset/clevis/commit/ee1dfedb9baca107e66a0fec76693c9d479dcfd9
("sss: use BN_set_word(x, 0) instead of BN_zero()")

resolves this. If this is a pressing issue, I can cherry-pick that one.
In that case, let me know or raise the severity to RC (which I assume
will happen some day anyway).

Else I'd just wait until next upstream release which I expect to happen
somewhen in the next months at most.

Regards,
Christoph


signature.asc
Description: PGP signature

Bug#995034: Only single dash completions shown

[積丹尼 Dan Jacobson]

Well OK. But e.g., if a user e.g., reports to all

perltidy debian
perltidy upstream
bash-completion debian
bash-completion upstream

then that would require a total of 4 x 4 = 16 cross references,
(as users have no hint of where to report.)

Bug#995341: Highly inappropriate behavior which the RT should be aware of

[Chuck Zmudzinski]

On 10/3/2021 11:21 AM, Chuck Zmudzinski wrote:

On 10/1/2021 5:48 AM, Diederik de Haas wrote:
We've already identified a possible fix, which I can point to if so 
desired,


I think the fix referred to is here:

https://salsa.debian.org/xen-team/debian-xen/-/tree/knorrie/for-diederik-3-fixes 



AFAICT, this fix involves adding three more commits


Slight correction - it actually looks like this proposal involves 3 fixes
for diederik, but it actually involves five new commits from the upstream
unstable Xen 4.16 branch, as indicated by the five new patches in the
debian/patches directory.


from the
unstable upstream Xen 4.16 branch in addition to the nine
commits already added from unstable upstream Xen 4.16
to provide better support for the Raspberry Pi 4 but with
the unintended side effect of #994899.

I do not object to this fix for Debian's current unstable
distribution. However, this bug concerns Debian's
current stable version, bullseye, not sid/unstable.

I would respectfully disagree with the Release Team's
decision to migrate the aforementioned fix from the
unstable release to bullseye unless the fix is accepted
by the upstream Xen project in its stable 4.14 branch and
its future stable point releases 4.14.x.

IMO, the debdiff attached to message #30:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995341#30

is a better suited fix more in accordance with the stability/security
requirements of a typical Debian stable release.

Regards,

Chuck Zmudzinski

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

[Guilhem Moulin]

Control: tag -1 moreinfo

On Tue, 31 Aug 2021 at 16:05:27 +0200, Christoph Anton Mitterer wrote:
> The cryptdisks_* completion scripts seems to depend on mawk.
> 
> Would it be possible to make this compatible with the other awk 
> implementations
> in Debian (gawk/original-awk)?

mawk has ‘Priority: required’ and is expressive enough for this
use-case.  Why should we use something else?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#995495: Description change

[Salvatore Bonaccorso]

Hi,

On Sun, Oct 03, 2021 at 10:33:10PM +0800, deb...@s.muenzel.net wrote:
> Looks like the bug title was changed to say "laptop" this is a desktop
> computer.
> 
> Also, the kernel does not hang -- it continues booting, and it is possible
> to log in via ssh.

Yes the subject could be better indeed, I wanted to higlight the
common set for all of 994453, 994949, 995120, 995234, 995608 and
995495.

We will in any case change in the next upload that AMD Secure Memory
Encryption is not activated by default, though enabled, as the
impacted users were defintively more than the benefit of haging it
activated by default.

Will be either in 5.14.9-2 or with a later further import of the
5.14.y series.

Salvatore

Bug#995608: linux-image-5.14.0-1-amd64: Boot immediately hangs.

[Salvatore Bonaccorso]

Hi Vincent!

On Sun, Oct 03, 2021 at 09:36:10PM +0200, Vincent Blut wrote:
> Le 2021-10-03 20:58, Salvatore Bonaccorso a écrit :
> > Hi Vincent,
> > 
> > On Sun, Oct 03, 2021 at 03:55:21PM +0200, Vincent Blut wrote:
> > > Hi,
> > > 
> > > Le 2021-10-03 11:40, Nathanael Schweers a écrit :
> > > > 
> > > > Salvatore Bonaccorso  writes:
> > > > 
> > > > > Control: tags -1 + moreinfo
> > > > >
> > > > > Hi Nathanael,
> > > > >
> > > > > On Sun, Oct 03, 2021 at 10:02:35AM +0200, Nathanael Schweers wrote:
> > > > >> Package: src:linux
> > > > >> Version: 5.14.6-3
> > > > >> Severity: grave
> > > > >> Justification: renders package unusable
> > > > >>
> > > > >> Dear Maintainer,
> > > > >>
> > > > >> using this kernel, my machine no longer boots.  Instead of showing a 
> > > > >> prompt to
> > > > >> enter the LUKS passphrase (as is done in version 
> > > > >> linux-image-5.10.0-7-amd64) a
> > > > >> non-blinking cursor is shown.  Nothing happens afterwards.
> > > > >>
> > > > >> Version linux-image-5.10.0-7-amd64 still works, but newer versions
> > > > >> (linux-image-5.10.0-8-amd64 and the version this report is for) 
> > > > >> produce the
> > > > >> behaviour mentioned above.
> > > > >>
> > > > >> I’m afraid that I don’t have a decent idea on what extra information 
> > > > >> to provide.
> > > > >
> > > > > Could you please confirm that booting with the 'mem_encrypt=off'
> > > > > kernel command line heps?
> > > > 
> > > > With this option the kernel does indeed boot.  Thanks for the tip!
> > > 
> > > Salvatore, given the increase in bug reports that this feature generates,
> > > I think it would be sensible to unset AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT 
> > > until
> > > those incompatibilities are fixed, like I proposed in [1]. One would have 
> > > to
> > > use the "mem_encrypt=on" command line option to enable the AMD Secure 
> > > Memory
> > > Encryption. If it sounds reasonable to you and the rest of the kernel 
> > > team,
> > > I can send a merge request.
> > 
> > Yes I think at this point is reasonable, as people wanting the feature
> > still can enable it, but we do not break usual setups as it has hit
> > severral people arleady. Can you post the reference [1], it was not
> > included.  No need for a merge request, as I have the change already
> > in debian/config/kernelarch-x86/config .
> 
> Oops, sorry about that. [1] was supposed to point to 
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/322/diffs

Ah thanks! We should have done that probably already at that time.

Pushed now the change to sid branch, so will be included in next
upload for unstable.

Regards,
Salvatore

Bug#995613: guile-2.2: Please build with --without-threads on alpha to fix FTBFS

[Michael Cree]

On Sun, Oct 03, 2021 at 09:14:04PM +0200, John Paul Adrian Glaubitz wrote:
> On 10/3/21 20:29, Michael Cree wrote:
> > On Sun, Oct 03, 2021 at 11:33:31AM +0200, John Paul Adrian Glaubitz wrote:
> >> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
> >> support. Passing --without-threads to configure disables thread
> >> support and fixes the build.
> > 
> > The issue only appears on SMP systems.  They build correctly on UP
> > systems.  This issue affects a number of package builds including
> > gnutls and autogen.  I often just manually build them on a UP system
> > and upload to the archive, and I could do that with guile-2.2.  As
> > to where the issue really is ... I am not sure.
> 
> The problem is that even the built guile package will crash on SMP systems
> without "--without-threads". So, currently, we have no other choice than
> disabling threads if we want guile and others to not FTBFS on imago and
> electro and other SMP buildds in the future.

Well, we do have choices, and one is to find the actual problem in the
toolchain.  That would be a far better solution!

Cheers
Michael.

Bug#993824: transition: libqalculate

[Sebastian Ramacher]

Hi Norbert, Phil

On 2021-09-27 10:22:31 +0900, Norbert Preining wrote:
> Hi Phil,
> 
> I pushed a commit with initial changes for libqalculate20-data dummy
> package. Please take a look.

Any news regarding libqalculate20-data?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#972570: [Pkg-javascript-devel] Bug#972570: node-lightgallery is built using minified files

[Joe Nahmias]

Hello,

Now that bullseye has been released, would it be possible to upload a fix
for this to unstable? That would allow node-lightgallery and rainloop to
migrate to testing (bookworm) and then be backported to bullseye.

If you are not able to do this at the moment, due to time constraints, I'm
happy to prepare the upload based on what's in Salsa, as long as it's okay
with the JS team.

Thanks,
--Joe

On Sat, Apr 24, 2021 at 04:12:06PM -0700, Daniel Ring wrote:
> It looks like this RC bug also caused the next version of Rainloop to be
> removed from bullseye before the freeze. That version contains an relatively
> important security fix (bug #962629), so both Rainloop and node-lightgallery
> will need to be uploaded to bullseye-backports (when available) as well as
> unstable.
> 
> Sincerely,
> Daniel Ring
> 
> On 4/23/2021 9:35 PM, Daniel Ring wrote:
> > The warnings are already overridden in the current version on Salsa,
> > since the Youtube/Vimeo/etc. embeds are only loaded when Lightgallery is
> > used to display a video from that source (e.g. by passing it a Youtube
> > link).
> > 
> > Sincerely,
> > Daniel Ring
> > 
> > On 4/23/2021 12:31 PM, Yadd wrote:
> > > Le 23/04/2021 à 19:03, Jonas Smedegaard a écrit :
> > > > Quoting Yadd (2021-04-23 17:47:23)
> > > > > Control: tags -1 + pending
> > > > > 
> > > > > Le 23/04/2021 à 09:44, Daniel Ring a écrit :
> > > > > > Hello Xavier,
> > > > > > 
> > > > > > It looks like the build process was minifying the source files to 
> > > > > > the
> > > > > > destination *.js files and copying the pre-minified
> > > > > > files to *.min.js. I
> > > > > > corrected it to copy the unminified files directly and minify them 
> > > > > > to
> > > > > > *.min.js.
> > > > > > 
> > > > > > I also updated the package on Salsa to exclude the minified
> > > > > > modules/*.min.js files via Files-Excluded in
> > > > > > d/copyright, so they're no
> > > > > > longer in the source package at all.
> > > > > > 
> > > > > > Sincerely,
> > > > > > Daniel Ring
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > looks good to me, thanks! Could you also ignore these warnings in a
> > > > > debain/lintian-overrides? It looks like false positive
> > > > > 
> > > > > Cheers,
> > > > > Yadd
> > > > > 
> > > > >   W: node-lightgallery: privacy-breach-generic
> > > > > usr/share/nodejs/lightgallery/dist/js/lg-video.min.min.js [ > > > > class="lg-video-object lg-dailymotion '+o+'" '+l+' width="560"
> > > > > height="315"
> > > > [...]
> > > > Those warnings look real to me.
> > > > 
> > > > What makes you consider them false positives, Xavier?
> > > 
> > > Hi Jonas,
> > > 
> > > yes but the relevant lines are in if/then/else blocks:
> > > 
> > >    if (isVideo.youtube) {
> > >  ...  video = 

Bug#995667: util-linux: remove /usr/bin/write alternate support

[Chris Hofstaedtler]

Package: util-linux
Priority: wishlist

nwrite dropped the alternate support in 1.9.2-21 (hopefully in
bookworm). util-linux could also drop the alternate support now,
with Breaks/Conflicts/Replaces etc.

Bug#995341: release.debian.org: Xen dom0 does not power off on bullseye (stable)

[Chuck Zmudzinski]

The original submitter has proposed a fix (see messages #30 and #35). 
Another contributor to this report has indicated the package maintainer 
does not endorse the submitter of the bug's proposed fix and is working 
on another fix (see messages #40 and #65). The original submitter of the 
bug thinks the possible solution proposed in messages #40 and #65 does 
not meet the typical stability/security requirements for a typical 
Debian stable release.

Bug#995608: linux-image-5.14.0-1-amd64: Boot immediately hangs.

[Vincent Blut]

Le 2021-10-03 20:58, Salvatore Bonaccorso a écrit :
> Hi Vincent,
> 
> On Sun, Oct 03, 2021 at 03:55:21PM +0200, Vincent Blut wrote:
> > Hi,
> > 
> > Le 2021-10-03 11:40, Nathanael Schweers a écrit :
> > > 
> > > Salvatore Bonaccorso  writes:
> > > 
> > > > Control: tags -1 + moreinfo
> > > >
> > > > Hi Nathanael,
> > > >
> > > > On Sun, Oct 03, 2021 at 10:02:35AM +0200, Nathanael Schweers wrote:
> > > >> Package: src:linux
> > > >> Version: 5.14.6-3
> > > >> Severity: grave
> > > >> Justification: renders package unusable
> > > >>
> > > >> Dear Maintainer,
> > > >>
> > > >> using this kernel, my machine no longer boots.  Instead of showing a 
> > > >> prompt to
> > > >> enter the LUKS passphrase (as is done in version 
> > > >> linux-image-5.10.0-7-amd64) a
> > > >> non-blinking cursor is shown.  Nothing happens afterwards.
> > > >>
> > > >> Version linux-image-5.10.0-7-amd64 still works, but newer versions
> > > >> (linux-image-5.10.0-8-amd64 and the version this report is for) 
> > > >> produce the
> > > >> behaviour mentioned above.
> > > >>
> > > >> I’m afraid that I don’t have a decent idea on what extra information 
> > > >> to provide.
> > > >
> > > > Could you please confirm that booting with the 'mem_encrypt=off'
> > > > kernel command line heps?
> > > 
> > > With this option the kernel does indeed boot.  Thanks for the tip!
> > 
> > Salvatore, given the increase in bug reports that this feature generates,
> > I think it would be sensible to unset AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT 
> > until
> > those incompatibilities are fixed, like I proposed in [1]. One would have to
> > use the "mem_encrypt=on" command line option to enable the AMD Secure Memory
> > Encryption. If it sounds reasonable to you and the rest of the kernel team,
> > I can send a merge request.
> 
> Yes I think at this point is reasonable, as people wanting the feature
> still can enable it, but we do not break usual setups as it has hit
> severral people arleady. Can you post the reference [1], it was not
> included.  No need for a merge request, as I have the change already
> in debian/config/kernelarch-x86/config .

Oops, sorry about that. [1] was supposed to point to 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/322/diffs

> Vincent, thanks for your huge amount of contributions, that is awesome
> :)

You're welcome!

> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995655: dnsmasq breaks systemd autopkgtest: b'megasearch.net: 192.168.42.1' not found in b'megasearch.net: 207.148.248.143

[Michael Biebl]

Control: reassign -1 dnsmasq/2.86-1

It's a (known) regression in dnsmasq 2.86-1

CCing what I sent Simon privately a couple of days ago


Hi Simon,

as you probably know, the recent update of dnsmasq 2.86 to unstable broke the 
systemd autopkgtests, namely test-networkd.py, and more specifically

==
ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
resolved: domain-restricted DNS servers
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.knebmh6r/downtmp/build.00t/src/test/networkd-test.py", 
line 659, in test_resolved_domain_restricted_dns
out = subprocess.check_output(['resolvectl', 'query', 'search.example.com'])
  File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.9/subprocess.py", line 528, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['resolvectl', 'query', 
'search.example.com']' returned non-zero exit status 1.

--
Ran 35 tests in 143.025s

FAILED (errors=1, skipped=2)


Afaics, this is a regression introduced by
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=12a9aa7c628e2d7dcd34949603848a3fb53fce9c

and should be fixed by
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=26bbf5a314d833beaf0f147d24409969f05f3dba




Am 03.10.21 um 19:23 schrieb Paul Gevers:

Source: dnsmasq, systemd
Control: found -1 dnsmasq/2.86-1
Control: found -1 systemd/247.9-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of dnsmasq the autopkgtest of systemd fails in
testing when that autopkgtest is run with the binary packages of dnsmasq
from unstable. It passes when run with only packages from testing. In
tabular form:

passfail
dnsmasqfrom testing2.86-1
systemdfrom testing247.9-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of dnsmasq to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
dnsmasq/2.86-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=dnsmasq

https://ci.debian.net/data/autopkgtest/testing/amd64/s/systemd/15711756/log.gz


==
FAIL: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
resolved: domain-restricted DNS servers
--
Traceback (most recent call last):
   File
"/tmp/autopkgtest-lxc.re_u3b37/downtmp/build.aCg/src/test/networkd-test.py",
line 660, in test_resolved_domain_restricted_dns
 self.assertIn(b'megasearch.net: 192.168.42.1', out)
AssertionError: b'megasearch.net: 192.168.42.1' not found in
b'megasearch.net: 207.148.248.143 -- link:
eth0\n\n-- Information acquired via protocol DNS in 123.2ms.\n-- Data is
authenticated: no\n'

--






OpenPGP_signature
Description: OpenPGP digital signature

Bug#995444: bsdutils: "script" no longer prints output file name at the end

[Chris Hofstaedtler]

Hello Sascha Silbe,

* Sascha Silbe  [211001 
13:33]:
> Dear Maintainer,
> 
> since Bullseye, probably caused by upstream commit
> d805688afc0c709154c9c6f29383b175c05ffc92 ("script: report also timing
> file, do it only once"), "script" no longer outputs the file name at
> the end.

I never use script myself, so I do not know very much about it. You
have pointed out that this is an upstream change. I could not find
much upstream discussion about the change, but supposedly upstream
had some thoughts why this was changed.

Please talk to upstream directly [1], maybe ask if they can reinstate
the script name logging. Probably makes sense to explain your
usecase exactly.

Would be great if you could follow up with a link to the resulting
upstream discussion.

Best,
Chris

[1] util-li...@vger.kernel.org

Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon

[S Egbert]

There is still a Mismatched SOCK filespec implemented by chronyd and chronyc.

The saving grace was that loopback network interface hid this bug very well and 
saved the day for nearly everyone (who is not an expert Chronyd configurer)...

That is, until the directive 'cmddeny 127.0.0.1' is configured: then one finds 
out the hard way that there is no consistent way to open the UNIX socket.  


Workaround:

Don't use 'cmddeny 127.0.0.1' setting for now until the filenaming convention
for its socket file specification becomes synchronized between Chrony client 
and server.



STRACES
---
In all straces below, the config directive is:

  cmddeny 127.0.0.1


Client CLI Fallback method (default)

This following strace details the default operation of ordinary chronyc CLI 
client operation, specifically to send a 'sources' CLI command with hope to 
receive a list of NTP servers.

This shell invocation did NOT use an '-h' option, fallback mechanism to other 
communcation channel methods werre done:  
* Socket failed,  (this bug report)
* IPv4 loopback failed (due to 'cmddeny 127.0.0.1')
* IPv6 loopback failed (not sure how, but it shouldn't have happened)

#Shell Invocation
# strace -f chrony -d -d -d sources

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
write(2, "Resolved 127.0.0.1 to 127.0.0.1", 31Resolved 127.0.0.1 to 127.0.0.1) 
= 31
write(2, "\n", 1
write(2, "Resolved ::1 to ::1", 19Resolved ::1 to ::1) = 19
write(2, "\n", 1
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
unlink("/var/run/chrony/chronyc.21014.sock") = -1 ENOENT (No such file or 
directory)
write(2, "Could not remove /var/run/chrony"..., 79Could not remove 
/var/run/chrony/chronyc.21014.sock : No such file or directory) = 79
write(2, "\n", 1
bind(3, {sa_family=AF_UNIX, sun_path="/var/run/chrony/chronyc.21014.sock"}, 
110) = -1 EACCES (Permission denied)
write(2, "Could not bind Unix socket to /v"..., 84Could not bind Unix socket to 
/var/run/chrony/chronyc.21014.sock : Permission denied) = 84
write(2, "\n", 1
getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
write(2, "Opened UDPv4 socket fd=3 remote="..., 45Opened UDPv4 socket fd=3 
remote=127.0.0.1:323) = 45
write(2, "Could not receive message fd=3 :"..., 51Could not receive message 
fd=3 : Connection refused) = 51
write(2, "\n", 1
getsockname(3, {sa_family=AF_INET, sin_port=htons(34899), 
sin_addr=inet_addr("127.0.0.1")}, [112->16]) = 0
socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
read(4, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 542
read(4, "", 4096)   = 0
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0003\0\0\0\0\0\0"..., 
832) = 832
read(4, "# Internet (IP) protocols\n#\n# Up"..., 4096) = 2932
setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
write(2, "Opened UDPv6 socket fd=3 remote="..., 41Opened UDPv6 socket fd=3 
remote=[::1]:323) = 41
write(2, "\n", 1
write(2, "Sent data fd=3 len=32", 21Sent data fd=3 len=32)   = 21
write(2, "\n", 1
write(2, "Timeout 1.00 seconds", 24Timeout 1.00 seconds) = 24
write(2, "\n", 1
write(2, "Could not receive message fd=3 :"..., 51Could not receive message 
fd=3 : Connection refused) = 51
write(2, "\n", 1
write(2, "Sent data fd=3 len=32", 21Sent data fd=3 len=32)   = 21
write(2, "\n", 1
write(2, "Timeout 2.00 seconds", 24Timeout 2.00 seconds) = 24
write(2, "\n", 1
write(2, "Could not receive message fd=3 :"..., 51Could not receive message 
fd=3 : Connection refused) = 51
write(2, "\n", 1
write(2, "Sent data fd=3 len=32", 21Sent data fd=3 len=32)   = 21
write(2, "\n", 1
write(2, "Timeout 4.00 seconds", 24Timeout 4.00 seconds) = 24
write(2, "\n", 1
write(2, "Could not receive message fd=3 :"..., 51Could not receive message 
fd=3 : Connection refused) = 51
write(2, "\n", 1
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(56416), 
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", _addr), 
sin6_scope_id=0}, [112->28]) = 0


Client CLI Direct Loopback method
-
The following strace uses '-h' command line option to specify the desired 
sockets, network-based, but we know that daemon has already been directed by 
'cmddeny 127.0.0.1', so no go here.

Since the CLI command line explicitly asked for '-h 127.0.0.1' there were no 
fallback mechanism to try other channel methods (UNIX socket or a non-loopback 
remote network)  

That too failed (correctly) due to 'cmddeny 127.0.0.1' directive.

#Shell Invocation
# strace -f chronyc -h 127.0.0.1 sources

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
write(2, "Resolved 127.0.0.1 to 127.0.0.1", 31Resolved 127.0.0.1 to 127.0.0.1) 
= 31
write(2, "\n", 1
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
write(2, "Opened UDPv4 socket fd=3 

Bug#995007: gnustep-base ftbfs with updated autoconf/automake

[Yavor Doganov]

On Sat, 02 Oct 2021 16:01:45 +0300,
Peter Green wrote:
> I see a fix for this issue has been uploaded to mentors, do you want
> me to sponsor it?

I'd be very grateful, thanks in advance!
My usual sponsor is not answering...

Bug#995346: ruby-chef-utils: depends on the Internet during build

[Graham Inggs]

Control: severity -1 serious

Per Debian Policy 4.9, packages in main must not attempt network
access during the build.

Bug#995666: pymol: diff for NMU version 2.4.0+dfsg-2.1

[Sebastian Ramacher]

Package: pymol
Version: 2.4.0+dfsg-2
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for pymol (versioned as 2.4.0+dfsg-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru pymol-2.4.0+dfsg/debian/changelog pymol-2.4.0+dfsg/debian/changelog
--- pymol-2.4.0+dfsg/debian/changelog	2021-05-22 13:26:27.0 +0200
+++ pymol-2.4.0+dfsg/debian/changelog	2021-10-03 21:27:14.0 +0200
@@ -1,3 +1,10 @@
+pymol (2.4.0+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace libglew1.5-dev with libglew-dev
+
+ -- Sebastian Ramacher   Sun, 03 Oct 2021 21:27:14 +0200
+
 pymol (2.4.0+dfsg-2) unstable; urgency=medium
 
   * debian/tests/control: Add scenes2movie to list of skipped scripts (Closes:
diff -Nru pymol-2.4.0+dfsg/debian/control pymol-2.4.0+dfsg/debian/control
--- pymol-2.4.0+dfsg/debian/control	2021-01-10 19:26:16.0 +0100
+++ pymol-2.4.0+dfsg/debian/control	2021-10-03 21:27:01.0 +0200
@@ -7,7 +7,7 @@
dh-python,
freeglut3-dev,
libfreetype6-dev,
-   libglew1.5-dev,
+   libglew-dev,
libglm-dev,
libnetcdf-dev,
libpng-dev,


signature.asc
Description: PGP signature

Bug#974678: OpenH264 in Debian

[Adam Cecile]

Hello everyone,

Is it possible to have an update regarding this issue ?
I do not really understand what the problem with patent is, but I'd like know 
if this is still under consideration !

Regards, Adam.

Bug#995341: Highly inappropriate behavior which the RT should be aware of

[Chuck Zmudzinski]

On 10/1/2021 5:48 AM, Diederik de Haas wrote:

We've already identified a possible fix, which I can point to if so desired,


I think the fix referred to is here:

https://salsa.debian.org/xen-team/debian-xen/-/tree/knorrie/for-diederik-3-fixes

AFAICT, this fix involves adding three more commits from the
unstable upstream Xen 4.16 branch in addition to the nine
commits already added from unstable upstream Xen 4.16
to provide better support for the Raspberry Pi 4 but with
the unintended side effect of #994899.

I do not object to this fix for Debian's current unstable
distribution. However, this bug concerns Debian's
current stable version, bullseye, not sid/unstable.

I would respectfully disagree with the Release Team's
decision to migrate the aforementioned fix from the
unstable release to bullseye unless the fix is accepted
by the upstream Xen project in its stable 4.14 branch and
its future stable point releases 4.14.x.

IMO, the debdiff attached to message #30:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995341#30

is a better suited fix more in accordance with the stability/security
requirements of a typical Debian stable release.

Regards,

Chuck Zmudzinski

Bug#995665: rss-glx: diff for NMU version 0.9.1-6.2

[Sebastian Ramacher]

Package: rss-glx
Version: 0.9.1-6.1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for rss-glx (versioned as 0.9.1-6.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru rss-glx-0.9.1/debian/changelog rss-glx-0.9.1/debian/changelog
--- rss-glx-0.9.1/debian/changelog	2017-01-02 00:50:24.0 +0100
+++ rss-glx-0.9.1/debian/changelog	2021-10-03 21:22:22.0 +0200
@@ -1,3 +1,10 @@
+rss-glx (0.9.1-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop libglew1.5-dev from Build-Depends
+
+ -- Sebastian Ramacher   Sun, 03 Oct 2021 21:22:22 +0200
+
 rss-glx (0.9.1-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rss-glx-0.9.1/debian/control rss-glx-0.9.1/debian/control
--- rss-glx-0.9.1/debian/control	2017-01-02 00:50:24.0 +0100
+++ rss-glx-0.9.1/debian/control	2021-10-03 21:21:39.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Ari Pollak 
 Build-Depends: debhelper (>= 7.0.50~), libx11-dev, libxt-dev,
  libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev,
- libglew1.5-dev | libglew-dev, libopenal-dev, libalut-dev,
+ libglew-dev, libopenal-dev, libalut-dev,
  libmagickwand-dev (>= 7:6.4.0), libtool, pkg-config,
  libglc-dev, dh-autoreconf
 Standards-Version: 3.9.1


signature.asc
Description: PGP signature

Bug#995664: rlvm: diff for NMU version 0.14-5.1

[Sebastian Ramacher]

Package: rlvm
Version: 0.14-5
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for rlvm (versioned as 0.14-5.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru rlvm-0.14/debian/changelog rlvm-0.14/debian/changelog
--- rlvm-0.14/debian/changelog	2020-06-08 19:18:33.0 +0200
+++ rlvm-0.14/debian/changelog	2021-10-03 21:16:33.0 +0200
@@ -1,3 +1,10 @@
+rlvm (0.14-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace libglew1.5-dev with libglew-dev
+
+ -- Sebastian Ramacher   Sun, 03 Oct 2021 21:16:33 +0200
+
 rlvm (0.14-5) unstable; urgency=low
 
   [ Giovanni Mascellani  ]
diff -Nru rlvm-0.14/debian/control rlvm-0.14/debian/control
--- rlvm-0.14/debian/control	2020-06-08 19:18:33.0 +0200
+++ rlvm-0.14/debian/control	2021-10-03 21:16:13.0 +0200
@@ -14,7 +14,7 @@
libboost-thread-dev,
libfreetype6-dev,
libgl1-mesa-dev,
-   libglew1.5-dev,
+   libglew-dev,
libgtest-dev,
libgtk2.0-dev,
libguichan-dev,


signature.asc
Description: PGP signature

Bug#995663: phlipple: diff for NMU version 0.8.5-5.1

[Sebastian Ramacher]

Package: phlipple
Version: 0.8.5-5
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for phlipple (versioned as 0.8.5-5.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru phlipple-0.8.5/debian/changelog phlipple-0.8.5/debian/changelog
--- phlipple-0.8.5/debian/changelog	2020-07-26 16:30:10.0 +0200
+++ phlipple-0.8.5/debian/changelog	2021-10-03 21:12:06.0 +0200
@@ -1,3 +1,10 @@
+phlipple (0.8.5-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace libglew1.X-dev with libglew-dev
+
+ -- Sebastian Ramacher   Sun, 03 Oct 2021 21:12:06 +0200
+
 phlipple (0.8.5-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru phlipple-0.8.5/debian/control phlipple-0.8.5/debian/control
--- phlipple-0.8.5/debian/control	2020-07-26 16:30:10.0 +0200
+++ phlipple-0.8.5/debian/control	2021-10-03 21:11:53.0 +0200
@@ -7,7 +7,7 @@
  Peter Pentchev 
 Build-Depends:
  debhelper-compat (= 13),
- libglew1.6-dev | libglew1.5-dev,
+ libglew-dev,
  libsdl-image1.2-dev,
  libsdl-mixer1.2-dev,
  libsdl1.2-dev


signature.asc
Description: PGP signature

Bug#995613: guile-2.2: Please build with --without-threads on alpha to fix FTBFS

[John Paul Adrian Glaubitz]

Hi Michael!

On 10/3/21 20:29, Michael Cree wrote:
> On Sun, Oct 03, 2021 at 11:33:31AM +0200, John Paul Adrian Glaubitz wrote:
>> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
>> support. Passing --without-threads to configure disables thread
>> support and fixes the build.
> 
> The issue only appears on SMP systems.  They build correctly on UP
> systems.  This issue affects a number of package builds including
> gnutls and autogen.  I often just manually build them on a UP system
> and upload to the archive, and I could do that with guile-2.2.  As
> to where the issue really is ... I am not sure.

The problem is that even the built guile package will crash on SMP systems
without "--without-threads". So, currently, we have no other choice than
disabling threads if we want guile and others to not FTBFS on imago and
electro and other SMP buildds in the future.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995662: info-beamer: diff for NMU version 1.0~pre3+dfsg-0.2

[Sebastian Ramacher]

Package: info-beamer
Version: 1.0~pre3+dfsg-0.1
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for info-beamer (versioned as 1.0~pre3+dfsg-0.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru info-beamer-1.0~pre3+dfsg/debian/changelog info-beamer-1.0~pre3+dfsg/debian/changelog
--- info-beamer-1.0~pre3+dfsg/debian/changelog	2016-06-29 02:48:16.0 +0200
+++ info-beamer-1.0~pre3+dfsg/debian/changelog	2021-10-03 21:07:47.0 +0200
@@ -1,3 +1,10 @@
+info-beamer (1.0~pre3+dfsg-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Replace libglew1.5-dev with libglew-dev
+
+ -- Sebastian Ramacher   Sun, 03 Oct 2021 21:07:47 +0200
+
 info-beamer (1.0~pre3+dfsg-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru info-beamer-1.0~pre3+dfsg/debian/control info-beamer-1.0~pre3+dfsg/debian/control
--- info-beamer-1.0~pre3+dfsg/debian/control	2016-06-29 01:39:23.0 +0200
+++ info-beamer-1.0~pre3+dfsg/debian/control	2021-10-03 21:04:51.0 +0200
@@ -2,7 +2,7 @@
 Section: misc
 Priority: optional
 Maintainer: Noël Köthe 
-Build-Depends: debhelper (>= 9), liblua5.1-dev, libevent-dev, libglfw3-dev, libglew1.5-dev, libftgl-dev, libavcodec-dev, libswscale-dev, libavformat-dev, libdevil-dev, lua5.1
+Build-Depends: debhelper (>= 9), liblua5.1-dev, libevent-dev, libglfw3-dev, libglew-dev, libftgl-dev, libavcodec-dev, libswscale-dev, libavformat-dev, libdevil-dev, lua5.1
 Standards-Version: 3.9.5
 Homepage: https://info-beamer.com/opensource
 


signature.asc
Description: PGP signature

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

[John Paul Adrian Glaubitz]

Hi Rob!

On 10/3/21 20:27, Rob Browning wrote:
> John Paul Adrian Glaubitz  writes:
> 
>> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
>> support. Passing --without-threads to configure disables thread
>> support and fixes the build.
> 
> Hmm, I'm not certain we can do this unless we've never had a successful
> build on the relevant platforms.  At least in the past, disabling
> threads changed the library ABI in a backward incompatible way.

Without --without-threads, guile would not build on SMP systems and even
the built package would crash on SMP systems.

If disabling threads would break the ABI, we could just rebuild the affected
reverse dependencies on the builds using the normal binNMU method.

I don't think we have any other choice at the moment.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995608: linux-image-5.14.0-1-amd64: Boot immediately hangs.

[Salvatore Bonaccorso]

Hi Vincent,

On Sun, Oct 03, 2021 at 03:55:21PM +0200, Vincent Blut wrote:
> Hi,
> 
> Le 2021-10-03 11:40, Nathanael Schweers a écrit :
> > 
> > Salvatore Bonaccorso  writes:
> > 
> > > Control: tags -1 + moreinfo
> > >
> > > Hi Nathanael,
> > >
> > > On Sun, Oct 03, 2021 at 10:02:35AM +0200, Nathanael Schweers wrote:
> > >> Package: src:linux
> > >> Version: 5.14.6-3
> > >> Severity: grave
> > >> Justification: renders package unusable
> > >>
> > >> Dear Maintainer,
> > >>
> > >> using this kernel, my machine no longer boots.  Instead of showing a 
> > >> prompt to
> > >> enter the LUKS passphrase (as is done in version 
> > >> linux-image-5.10.0-7-amd64) a
> > >> non-blinking cursor is shown.  Nothing happens afterwards.
> > >>
> > >> Version linux-image-5.10.0-7-amd64 still works, but newer versions
> > >> (linux-image-5.10.0-8-amd64 and the version this report is for) produce 
> > >> the
> > >> behaviour mentioned above.
> > >>
> > >> I’m afraid that I don’t have a decent idea on what extra information to 
> > >> provide.
> > >
> > > Could you please confirm that booting with the 'mem_encrypt=off'
> > > kernel command line heps?
> > 
> > With this option the kernel does indeed boot.  Thanks for the tip!
> 
> Salvatore, given the increase in bug reports that this feature generates,
> I think it would be sensible to unset AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT until
> those incompatibilities are fixed, like I proposed in [1]. One would have to
> use the "mem_encrypt=on" command line option to enable the AMD Secure Memory
> Encryption. If it sounds reasonable to you and the rest of the kernel team,
> I can send a merge request.

Yes I think at this point is reasonable, as people wanting the feature
still can enable it, but we do not break usual setups as it has hit
severral people arleady. Can you post the reference [1], it was not
included.  No need for a merge request, as I have the change already
in debian/config/kernelarch-x86/config .

Vincent, thanks for your huge amount of contributions, that is awesome
:)

Regards,
Salvatore

Bug#995613: guile-2.2: Please build with --without-threads on alpha to fix FTBFS

[Michael Cree]

On Sun, Oct 03, 2021 at 11:33:31AM +0200, John Paul Adrian Glaubitz wrote:
> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
> support. Passing --without-threads to configure disables thread
> support and fixes the build.

The issue only appears on SMP systems.  They build correctly on UP
systems.  This issue affects a number of package builds including
gnutls and autogen.  I often just manually build them on a UP system
and upload to the archive, and I could do that with guile-2.2.  As
to where the issue really is ... I am not sure.

Cheers
Michael.

Bug#995622: qemu FTCBFS: sphinx dependencies not satisfiable

[Michael Tokarev]

On Sat, 2 Oct 2021 12:42:00 +0200 Helmut Grohne  wrote:

Source: qemu
Version: 1:6.1+dfsg-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

qemu cannot satisfy its cross Build-Depends, because its dependencies on
sphinx are not satisfiable. Unfortunately, sphinx can be used in
architecture-dependent ways, so it cannot be annotated M-A:foreign. I
think that qemu uses sphinx in an architecture-independent way (as most
architecture-dependent use cases import python extensions and qemu uses
it to generate manual pages instead). As such, we can address the issue
by annotating the relevant dependencies with :native. Please consider
applying the attached patch.


Please count me confused.  I don't understand what you're talking about.
What does this: "unfortunately, sphinx can be used in architecture-dependent
ways" means, and why this is unfortunate?

Maybe it's better to annotate it with :any, as we don't really care which
arch it is, as long as it works?

Also, what does this :native annotation do within build-depends, to start
with? Is there any documentation about this?

Thanks,

/mjt

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:

[...]

> - Because a long time has passed by since the last overhaul of this chapter,
>   maybe there is some more, that could be changed, for example because of
>   changed/new technology or experience?

Regarding 4.3.2. at

  
https://people.debian.org/~holgerw/installation-guide_2021-10-02/amd64/ch04s03.html


 > An alternative way to set up your USB stick is to manually copy
 > the installer files,...

This section has been about since the dawn of time :). It predates the
advent of isohybrid technology and could be said to have served its
purpose and be retired. An alternative would be to leave it there and
introduce it as follows:

 Prior to isohybrid technology being used for all Debian ISOs, this way
 was the method used to boot from a USB device. It has been superseded
 by the technique in Section 4.3.1 [LINK] but has been left here for
 educational and  historical purposes and in case it proves of use to a
 user.



 > ...(smaller setups are possible if you follow Section 4.3.3,...

I wonder about this. The Debian 11 netinst ISO is 480M. GRUB plus the
boot files are 33M. Would they fit on a 512M USB stick (which is not
really 512M)? Partially tested to say "no". My rule of thumb is 1G.



The link beginning

  http://http.us.debian.org/

should be

  http://deb.debian.org/

or

  https://deb.debian.org/



The Note exercised my mind. It has nothing to do with the being able to
use this method but refers to an after effect. "major disadvantage"
refers to this after effect. An alarming term.

 > Note that, although convenient and successful, this method does have a
 > drawback affecting how the size of the USB device is seen because it
 > sets its logical size to 1 GB, even if the capacity of the USB stick is
 > larger. You will need to repartition the USB stick and create new file
 > systems to get its full capacity back if you ever want to use it for
 > some different purpose.



Regards,

Brian.
 

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

[Rob Browning]

John Paul Adrian Glaubitz  writes:

> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
> support. Passing --without-threads to configure disables thread
> support and fixes the build.

Hmm, I'm not certain we can do this unless we've never had a successful
build on the relevant platforms.  At least in the past, disabling
threads changed the library ABI in a backward incompatible way.

I'll see if I can find out if that's still the case.

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

Bug#995625: httping FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[folkert]

4ea9d5b78540c972e3fe1bf44db9f7b3f87c0ad0

On Sun, Oct 03, 2021 at 11:36:12PM +0530, Abhijith PA wrote:
> Thank you folkert. I will be very happy to take the patch, if you have 
> committed in upstream repo. :)
> 
> 
> --abhijith 
> 
> 
> On 03/10/21 07:49 PM, folkert wrote:
> > replace it by:
> > 
> > wprintw(w, "%s", what);
> > 
> > On Sun, Oct 03, 2021 at 07:48:19AM +0200, Helmut Grohne wrote:
> > > Source: httping
> > > Version: 2.5-5.1
> > > Severity: serious
> > > Tags: ftbfs
> > > 
> > > httping fails to build from source in unstable on amd64. A non-parallel
> > > build ends as follows:
> > > 
> > > | x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. 
> > > -fstack-protector-strong -Wformat -Werror=format-security -Wall -W 
> > > -Wextra -pedantic -D_FORTIFY_SOURCE=2  -DVERSION=\"2.5\" 
> > > -DLOCALEDIR=\"/usr/share/locale\" -DTCP_TFO -DNC -DFW -D_DEBUG -ggdb 
> > > -Wdate-time -D_FORTIFY_SOURCE=2  -c -o nc.o nc.c
> > > | nc.c: In function ???myprint???:
> > > | nc.c:238:3: error: format not a string literal and no format arguments 
> > > [-Werror=format-security]
> > > |   238 |   wprintw(w, what);
> > > |   |   ^~~
> > > | nc.c: In function ???draw_graph???:
> > > | nc.c:611:24: warning: unused parameter ???val??? [-Wunused-parameter]
> > > |   611 | void draw_graph(double val)
> > > |   | ~~~^~~
> > > | nc.c: In function ???status_line???:
> > > | nc.c:389:2: warning: ignoring return value of ???vasprintf??? declared 
> > > with attribute ???warn_unused_result??? [-Wunused-result]
> > > |   389 |  vasprintf(, fmt, ap);
> > > |   |  ^
> > > | cc1: some warnings being treated as errors
> > > | make[1]: *** [: nc.o] Error 1
> > > | make[1]: Leaving directory '/<>'
> > > | dh_auto_build: error: make -j1 returned exit code 2
> > > | make: *** [debian/rules:10: build] Error 25
> > > | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> > > status 2
> > > 
> > > This is likely caused by ncurses adding format string annotations.
> > > 
> > > Helmut
> > 
> > 
> > Folkert van Heusden
> > 
> > -- 
> > MultiTail ist eine flexible Applikation um Logfiles und Kommando
> > Eingaben zu überprüfen. Inkl. Filter, Farben, Zusammenführen,
> > Ansichten etc. http://www.vanheusden.com/multitail/
> > --
> > Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com


Folkert van Heusden

-- 
Nagios user? Check out CoffeeSaint - the versatile Nagios status
viewer! http://www.vanheusden.com/java/CoffeeSaint/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Bug#995661: ITS: utfcpp

[Boyuan Yang]

Source: utfcpp
Version:  2.3.4-1.1
Severity: important
X-Debbugs-CC: ma...@debian.org

Dear package utfcpp maintainers in Debian,

After looking into the package you maintain (utfcpp, 
https://tracker.debian.org/pkg/utfcpp), I found that this package
received no maintainer updates in the past 8 years with no activity on Debian
BTS system. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1] with the intent to take over package maintenance in Debian.

My current plan is to package the latest upstream release
on https://github.com/nemtrif/utfcpp and set myself as package maintainer.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto Debian unstable with
DELAYED/7 after 21 days (Oct. 24, 2021) to continue with the package
salvaging. If you find it necessary to pause the ITS process at any time,
please let me know immediately by replying this bug report.

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Regards,
Boyuan Yang


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

Bug#995660: clickhouse: FTBFS with OpenSSL 3.0

[Kurt Roeckx]

Source: clickhouse
Version: 18.16.1+ds-7.2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
11: + openssl dhparam -out /tmp/clickhouse.test..wbgfY/etc/dhparam.pem 256
11: Generating DH parameters, 256 bit long safe prime
11: dhparam: Generating DH key parameters failed
11: 40A7B5ED9C7F:error:0280007E:Diffie-Hellman 
routines:dh_builtin_genparams:modulus too small:../crypto/dh/dh_gen.c:168:
11/11 Test #11: with_server ***Failed0.06 sec

The minimum size that it now allows you to generate is 512 bit,
which might be good for a test suite, but is too short for real
parameters.


Kurt

Bug#995659: coturn: FTBFS with OpenSSL 3.0

[Kurt Roeckx]

Source: coturn
Version: 4.5.2-3
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
src/client/ns_turn_msg.c: In function stun_produce_integrity_key_str:
src/client/ns_turn_msg.c:260:7: warning: implicit declaration of function 
FIPS_mode [-Wimplicit-function-declaration]
  260 |   if (FIPS_mode()) {
  |   ^
[...]
/usr/bin/ld: lib/libturnclient.a(ns_turn_msg.o): in function 
`stun_produce_integrity_key_str':
./src/client/ns_turn_msg.c:260: undefined reference to `FIPS_mode'
collect2: error: ld returned 1 exit status

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt

Bug#995658: assimp: autopkgtest regression since ci.d.n hosts run bullseye

[Paul Gevers]

Source: assimp
Version: 5.0.1~ds0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer(s),

Your package has an autopkgtest, great! However, since the release of
bullseye the autopkgtest fails on all architectures (most of the time).
It always failed on armhf and i386, but it now also fails on ppc64el,
arm64 and most of the time on amd64. The difference of course is that
the hosts on which the lxc based tests run are running bullseye instead
of buster (except ci-worker13, on which the test indeed still passes).
Can you please investigate?

Paul

https://ci.debian.net/packages/a/assimp/




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995657: clevis: FTBFS with OpenSSL 3.0

[Kurt Roeckx]

Source: clevis
Version: 18-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
In file included from ../src/pins/sss/sss.c:41:
../src/pins/sss/sss.c: In function ‘sss_point’:
../src/pins/sss/sss.c:217:9: error: void value not ignored as it ought to be
  217 | if (BN_zero(yy) <= 0)
  | ^~~
../src/pins/sss/sss.c: In function ‘sss_recover’:
../src/pins/sss/sss.c:275:9: error: void value not ignored as it ought to be
  275 | if (BN_zero(k) <= 0)
  | ^~~
../src/pins/sss/sss.c:306:17: error: void value not ignored as it ought to be
  306 | if (BN_zero(tmp) <= 0)
  | ^~~
ninja: build stopped: subcommand failed.

The manpage says:
In OpenSSL 0.9.8, BN_zero() was changed to not return a value; previous 
versions returned an int.


Kurt

Bug#995625: httping FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[folkert]

replace it by:

wprintw(w, "%s", what);

On Sun, Oct 03, 2021 at 07:48:19AM +0200, Helmut Grohne wrote:
> Source: httping
> Version: 2.5-5.1
> Severity: serious
> Tags: ftbfs
> 
> httping fails to build from source in unstable on amd64. A non-parallel
> build ends as follows:
> 
> | x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wextra 
> -pedantic -D_FORTIFY_SOURCE=2  -DVERSION=\"2.5\" 
> -DLOCALEDIR=\"/usr/share/locale\" -DTCP_TFO -DNC -DFW -D_DEBUG -ggdb 
> -Wdate-time -D_FORTIFY_SOURCE=2  -c -o nc.o nc.c
> | nc.c: In function ???myprint???:
> | nc.c:238:3: error: format not a string literal and no format arguments 
> [-Werror=format-security]
> |   238 |   wprintw(w, what);
> |   |   ^~~
> | nc.c: In function ???draw_graph???:
> | nc.c:611:24: warning: unused parameter ???val??? [-Wunused-parameter]
> |   611 | void draw_graph(double val)
> |   | ~~~^~~
> | nc.c: In function ???status_line???:
> | nc.c:389:2: warning: ignoring return value of ???vasprintf??? declared with 
> attribute ???warn_unused_result??? [-Wunused-result]
> |   389 |  vasprintf(, fmt, ap);
> |   |  ^
> | cc1: some warnings being treated as errors
> | make[1]: *** [: nc.o] Error 1
> | make[1]: Leaving directory '/<>'
> | dh_auto_build: error: make -j1 returned exit code 2
> | make: *** [debian/rules:10: build] Error 25
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2
> 
> This is likely caused by ncurses adding format string annotations.
> 
> Helmut


Folkert van Heusden

-- 
MultiTail ist eine flexible Applikation um Logfiles und Kommando
Eingaben zu überprüfen. Inkl. Filter, Farben, Zusammenführen,
Ansichten etc. http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Bug#995591: RFS: minidb/2.0.5-2 -- simple SQLite3-based store for Python objects

[Jeroen Ploemen]

Control: tags -1 moreinfo

On Sat, 02 Oct 2021 20:41:32 +0200
Maxime Werlen  wrote:

> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "minidb":

hi Maxime,

The package is not lintian clean:
  E: minidb source: missing-build-dependency-for-dh-addon python3 => 
python3:any | python3-all:any | python3-dev:any | python3-all-dev:any | 
dh-sequence-python3

Control:
  The ancient version requirement on the python3 build-dep is always
  satisfied, please remove.

Tests:
  Consider using the upstream testsuite (currently only run during
  build) as autopkgtest. Be sure to copy the tests out of the source
  dir and to loop over all supported python3 versions; there's plenty
  of packages on the python team repo that can serve as examples,
  including [1].
  The current 'import.py' is rather basic in comparison, doesn't test
  against all supported versions and should probably be marked
  "superficial" - if at all retained.


Please remove the moreinfo tag (and CC me directly) once you have an
updated package ready.


[1] 
https://salsa.debian.org/python-team/packages/puremagic/-/tree/master/debian/tests


pgpQ9J9JfKhz5.pgp
Description: OpenPGP digital signature

Bug#994173: completion broken on "apt-get u"

[Gabriel F. T. Gomes]

Control: tags -1 + unreproducible

Hi,

I could not reproduce this bug, even though I tried every version all
the way down to 1:2.10-2. Here's what I get:

  $ apt-get u
  $ apt-get up
  update   upgrade  

  $ apt-get a
  $ apt-get auto
  autoclean   autoremove  

If you have more information, I'd be happy to look again.

Cheers,
Gabriel


On Mon, 13 Sep 2021 10:17:12 +0200
Philipp Marek  wrote:

> Package: bash-completion
> Version: 1:2.11-3
> Severity: normal
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> With this new bash-completion (and the associated bash=5.1-3+b1),
> the completion is broken.
> 
> $ apt-get u
> 
> now puts all three possibilities on the CLI (instead of letting me 
> choose); with "a" nothing is allowed (although there is "autoclean" 
> and "autoremove").
> 
> With the older versions it works fine again.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_AT:de
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Bug#994990: bash-completion: Missing support for Python 3.9

[Gabriel F. T. Gomes]

Hi,

thanks for reporting...

A fix is on its way to the Debian Archive and already in VCS [1].

Cheers,
Gabriel

[1] 
https://salsa.debian.org/debian/bash-completion/-/commit/65534d18c5b0c5bf496af7a921ada56aa2a4375c

Bug#995656: edk2: autopkgtest arm64 regression: test_aavmf_ms_secure_boot_signed: Access Denied

[Paul Gevers]

Source: edk2
Version: 2021.08-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of edk2 the autopkgtest of edk2 fails in testing on
arm64 when that autopkgtest is run with the binary packages of edk2 from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
edk2   from testing2021.08-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1] https://qa.debian.org/excuses.php?package=edk2

https://ci.debian.net/data/autopkgtest/testing/arm64/e/edk2/15713990/log.gz

test_aavmf_ms_secure_boot_signed (__main__.BootToShellTest) ... mkfs.fat
4.2 (2021-01-31)
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:/tmp/tmprtuo53fa'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 16.2g free
Added to ISO image: directory '/'='/tmp/tmpvt36p18q'
xorriso : UPDATE :   2 files added in 1 seconds
xorriso : UPDATE :   2 files added in 1 seconds
xorriso : UPDATE :  48.36% done
ISO image produced: 65741 sectors
Written to medium : 65741 sectors at LBA 0
Writing to 'stdio:/tmp/tmprtuo53fa' completed successfully.

[=3hBdsDxe: failed to load Boot0001 "UEFI Misc
Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found

BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x1,0x0)

BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from
PciRoot(0x0)/Pci(0x1,0x0): Access Denied

BdsDxe: loading Boot0003 "EFI Internal Shell" from
Fv(64074AFE-340A-4BE6-94BA-91B5B4D0F71E)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)

BdsDxe: starting Boot0003 "EFI Internal Shell" from
Fv(64074AFE-340A-4BE6-94BA-91B5B4D0F71E)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)

UEFI Interactive Shell v2.2

EDK II

UEFI v2.70 (EDK II, 0x0001)

Mapping table

  FS0:
Alias(s):CD0a:;BLK1:

  PciRoot(0x0)/Pci(0x1,0x0)/CDROM(0x0)

 BLK2: Alias(s):

  VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)

 BLK0: Alias(s):

  PciRoot(0x0)/Pci(0x1,0x0)

Press ESC in 5 seconds
to skip startup.nsh or any other key to
continue.


Shell> fs0:
fs0:

FS0:\> \efi\boot\bootaa64.efi
\efi\boot\bootaa64.efi

Command Error Status: Access Denied

FS0:\> reset -s
reset
-s

FAIL



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995655: dnsmasq breaks systemd autopkgtest: b'megasearch.net: 192.168.42.1' not found in b'megasearch.net: 207.148.248.143

[Paul Gevers]

Source: dnsmasq, systemd
Control: found -1 dnsmasq/2.86-1
Control: found -1 systemd/247.9-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of dnsmasq the autopkgtest of systemd fails in
testing when that autopkgtest is run with the binary packages of dnsmasq
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
dnsmasqfrom testing2.86-1
systemdfrom testing247.9-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of dnsmasq to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
dnsmasq/2.86-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=dnsmasq

https://ci.debian.net/data/autopkgtest/testing/amd64/s/systemd/15711756/log.gz


==
FAIL: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
resolved: domain-restricted DNS servers
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.re_u3b37/downtmp/build.aCg/src/test/networkd-test.py",
line 660, in test_resolved_domain_restricted_dns
self.assertIn(b'megasearch.net: 192.168.42.1', out)
AssertionError: b'megasearch.net: 192.168.42.1' not found in
b'megasearch.net: 207.148.248.143 -- link:
eth0\n\n-- Information acquired via protocol DNS in 123.2ms.\n-- Data is
authenticated: no\n'

--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

[Adrian Bunk]

On Sun, Oct 03, 2021 at 10:21:16AM -0400, Reinhard Tartler wrote:
>...
> The consistent OOM is surprising given that you state that the worker has
> 250GB of RAM. Looking at the logs,
> I note that the tests are being passed the option -p 160 by the dh-golang
> helper, so it will build
> and run test executables concurrently. That confirms to me that we are
> indeed running on these 250GB/160 core workers.
>...

No matter the amount of RAM, you will always have the limitation of
<= 4 GB address space for a process on 32bit.[1]

Starting one process per core is not a problem even if each process
uses takes 1 GB of RAM.[2]

Starting one thread per core in the same process would not be suprising
to fail, 20 MB per thread would suffice for running out of address space.

> regards,
> Reinhard

cu
Adrian

[1] 32bit arm has 3 GB address space
[2] 160 g++ processes might be a problem with only 1.5 GB RAM per core

Bug#988346: RFS: fpart/1.3.0-1

[Ganael Laplanche]

On Sunday, May 16, 2021 5:21:11 PM CEST Ganael Laplanche wrote:

Hello Tobias,

> Oh, right, thanks. I'll probably fix the remaining issues and come back
> with a fresh update once the freeze is over.
> 
> Thanks *a lot* for your detailed review ! (I'll take time to have a look
> at each point and come back to you).

Debian being un-frozen, I have addressed remaining issues and updated the 
package to the latest version (1.4.0).

Here are the changes since version 1.2.0 :

fpart (1.4.0-1) unstable; urgency=low

  * New upstream release
  * Include README.md instead of symlink (closes: #988871)
  * debian/control
- Bump Standards-Version to 4.6.0 (no changes required)
- Add mailx to Depends
- Refine description
  * debian/copyright
- Fpart is BSD-2-Clause, not BSD-3-Clause
- Add missing copyright for src/fts.{h,c}
  * debian/watch
- Add PGP signature check

Could you have a look at the package ?

Thank you very much for your help,
Best regards,

-- 
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.FreeBSD.org

Bug#995654: malaga: reproducible builds: Embedded timestamps in .dvi, .pdf and .ps files

[Vagrant Cascadian]

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

The build timestamp is embedded in various .dvi, .pdf and .ps files:

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

  /usr/share/doc/malaga-doc/malaga.pdf.gz

  Creator:·'·TeX·output·2021.08.25:1625'
vs.
  Creator:·'·TeX·output·2022.09.29:0054'

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

With this patch applied, malaga should build reproducibly on
tests.reproducible-builds.org

Thanks for maintaining malaga!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#995653: django-mailman3 breaks hyperkitty autopkgtest: 'str' object has no attribute 'display_name'

[Paul Gevers]

Source: django-mailman3, hyperkitty
Control: found -1 django-mailman3/1.3.7-1
Control: found -1 hyperkitty/1.3.4-4
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of django-mailman3 the autopkgtest of hyperkitty
fails in testing when that autopkgtest is run with the binary packages
of django-mailman3 from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
django-mailman3from testing1.3.7-1
hyperkitty from testing1.3.4-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of django-mailman3
to testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/h/hyperkitty/15711755/log.gz

==
ERROR: test_basic_reply (hyperkitty.tests.lib.test_posting.PostingTestCase)
--
Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/hyperkitty/tests/lib/test_posting.py",
line 69, in test_basic_reply
self.user.save()
  File
"/usr/lib/python3/dist-packages/django/contrib/auth/base_user.py", line
66, in save
super().save(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line
743, in save
self.save_base(using=using, force_insert=force_insert,
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line
791, in save_base
post_save.send(
  File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py",
line 173, in send
return [
  File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py",
line 174, in 
(receiver, receiver(signal=self, sender=sender, **named))
  File "/usr/lib/python3/dist-packages/django_mailman3/signals.py", line
101, in create_profile
address.display_name = new_display_name
AttributeError: 'str' object has no attribute 'display_name'

==
ERROR: test_reply_different_sender
(hyperkitty.tests.lib.test_posting.PostingTestCase)
--
Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/hyperkitty/tests/lib/test_posting.py",
line 102, in test_reply_different_sender
self.user.save()
  File
"/usr/lib/python3/dist-packages/django/contrib/auth/base_user.py", line
66, in save
super().save(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line
743, in save
self.save_base(using=using, force_insert=force_insert,
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line
791, in save_base
post_save.send(
  File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py",
line 173, in send
return [
  File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py",
line 174, in 
(receiver, receiver(signal=self, sender=sender, **named))
  File "/usr/lib/python3/dist-packages/django_mailman3/signals.py", line
101, in create_profile
address.display_name = new_display_name
AttributeError: 'str' object has no attribute 'display_name'

==
ERROR: test_smtp_error_raises_postingfailed
(hyperkitty.tests.lib.test_posting.PostingTestCase)
--
Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/hyperkitty/tests/lib/test_posting.py",
line 89, in test_smtp_error_raises_postingfailed
self.user.save()
  File
"/usr/lib/python3/dist-packages/django/contrib/auth/base_user.py", line
66, in save
super().save(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line
743, in save
self.save_base(using=using, force_insert=force_insert,
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line
791, in save_base
post_save.send(
  File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py",
line 173, in send
return [
  File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py",
line 174, in 
(receiver, receiver(signal=self, sender=sender, **named))
  File "/usr/lib/python3/dist-packages/django_mailman3/signals.py", line
101, in create_profile
address.display_name = new_display_name
AttributeError: 'str' object has no 

Bug#995652: gnu-standards: reproducible builds: Embedded timestamps in .dvi file

[Vagrant Cascadian]

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

The build timestamp is embedded in various .dvi files:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/gnu-standards.html

  /usr/share/doc/gnu-standards/maintain.dvi.gz

  ··TeX·output·2022.
vs.
  ··TeX·output·2021.

  ··09.23:2204..
vs.
  ··08.22:1745..

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

With this patch applied, gnu-standards should build reproducibly on
tests.reproducible-builds.org

Thanks for maintaining gnu-standards!

live well,
  vagrant
From bf0d87b0b24f1372eedb1fcb885488acb7a3acc6 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 3 Oct 2021 17:05:34 +
Subject: [PATCH] debian/rules: Export FORCE_SOURCE_DATE=1 in order for texlive
 to respect SOURCE_DATE_EPOCH when generating .dvi file.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index a8f6c74..2181658 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,9 @@
 
 DOCUMENTS = standards.texi maintain.texi
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 build: build-stamp
 build-stamp:
 	dh_testdir
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#994266: pyjwt breaks azure-cli autopkgtest: Could not deserialize key data. The data may be in an incorrect format or it may be encrypted with an unsupported algorithm.

[Diego M. Rodriguez]

On Tue, 14 Sep 2021 22:30:24 +0200 Paul Gevers  wrote:
> Currently this regression is blocking the migration of pyjwt to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?

As part of the "investigate" part - this might be related to a hotfix
introduced in azure-cli 2.26.1 [1], which includes a change on how the
"jwt.decode()" call related to the "verify" parameter [2]. pyjwt seems
to have deprecated it in its 2.0 release [3] (and a number of similar in
its upstream repo also point to that parameter).

[1]
https://github.com/MicrosoftDocs/azure-docs-cli/blob/master/docs-ref-conceptual/release-notes-azure-cli.md#storage-2
[2] https://github.com/Azure/azure-cli/pull/18811
[3]
https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst#dropped-deprecated-verify_expiration-param-in-jwtdecode
-- 
Diego M. Rodriguez

Bug#995651: fdutils: reproducible builds: Embedded timestamps in .dvi file

[Vagrant Cascadian]

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

The build timestamp is embedded in various .dvi files:

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

  /usr/share/doc/fdutils/Fdutils.dvi.gz

  ··TeX·output·2021.
vs.
  ··TeX·output·2022.

  ··09.21:0514..
vs.
  ··10.24:1139..

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

With this patch applied, fdutils should build reproducibly on
tests.reproducible-builds.org

Thanks for maintaining fdutils!

live well,
  vagrant
From 240f44a97bec6af8271560526c0ca5f629ee6a3b Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 3 Oct 2021 17:00:13 +
Subject: [PATCH] debian/rules: Export FORCE_SOURCE_DATE=1 in order for texlive
 to respect SOURCE_DATE_EPOCH when generating .dvi file.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 090d7a4..bee225b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,9 @@ export DH_OPTIONS=-v
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@ --no-parallel
 
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#995650: chktex: reproducible builds: Embedded timestamps in .dvi file

[Vagrant Cascadian]

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

The build timestamp is embedded in various .dvi files:

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

  /usr/share/doc/chktex/ChkTeX.dvi.gz

  ··TeX·output·2021.
vs.
  ··TeX·output·2022.
  
  ··08.23:1518
vs.
  ··09.26:2344..

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

It also removes what appears to be some code attempting to adjust the
timestamsp in the tex.in files, which was only partially effective, and
is no longer needed.

With this patch applied, chktex should build reproducibly on
tests.reproducible-builds.org

Thanks for maintaining chktex!

live well,
  vagrant
From 951e1cc037a1eb8623f8e6a45d8619881eae7fb3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 3 Oct 2021 16:50:16 +
Subject: [PATCH] debian/rules: Export FORCE_SOURCE_DATE to ensure texlive
 respects SOURCE_DATE_EPOCH.

https://reproducible-builds.org/docs/source-date-epoch/

Remove tweaks to tex.in files, which seemed only partially effective.
---
 debian/rules | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/debian/rules b/debian/rules
index bbb3b9d..f193a6b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,7 +17,8 @@ TMPCFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
 LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
 
-DEBDATE:=\\\date{$(shell TZ=UTC LC_ALL=C date -d "$$(dpkg-parsechangelog -SDate)" +'%m\/%d\/%Y')}
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
 
 CFLAGS = -Wall -fstack-protector --param=ssp-buffer-size=4 -Wformat $(CPPFLAGS)
 INSTALL = install
@@ -51,14 +52,9 @@ build-stamp:  config.status
 
 	# Add here commands to compile the package.
 	# build source
-	cp -p ChkTeX.tex.in ChkTeX.tex.in.backup
-	echo $(DEBDATE)
-	echo $(LIBS)
-	sed -ri "s/.date..today./$(DEBDATE)/g" ChkTeX.tex.in
 	$(MAKE) CFLAGS="$(CFLAGS) $(CXXFLAGS)" LDFLAGS="$(LDFLAGS)" LIBS="$(LIBS) -lpcreposix -lpcre -ltermcap" chktex ChkTeX.dvi
 	# build html documentation
 	$(MAKE) html
-	mv ChkTeX.tex.in.backup ChkTeX.tex.in
 
 	touch build-stamp
 
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#995649: therion: autopkgtest regression on at least arm64 and i386

[Paul Gevers]

Source: therion
Version: 6.0.2ds1-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Control: affects -1 src:texlive-base src:texlive-lang

Dear maintainer(s),

With a recent upload of therion the autopkgtest of therion fails in
testing on at least arm64 and i386 when that autopkgtest is run with the
binary packages of therion from unstable. It passes when run with only
packages from testing. In tabular form:

   passfail
therionfrom testing6.0.2ds1-4
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
therion/6.0.2ds1-4. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=therion

https://ci.debian.net/data/autopkgtest/testing/arm64/t/therion/15744313/log.gz

writing samples/survex/cave1.pdf ...
This is MetaPost, version 2.01 (TeX Live 2022/dev/Debian) (kpathsea
version 6.3.4/dev)
(/usr/share/texlive/texmf-dist/metapost/base/mpost.mp
(/usr/share/texlive/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) ) (./data.mp [1] [2] [3] [4]
[5] [6] [7] [8] [9] [10] [11] [12] [13] [14]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
(./mptextmp.mp) [18] (./mptextmp.mp) (./mptextmp.mp) (./mptextmp.mp)
(./mptextmp.mp) (./mptextmp.mp) (./mptextmp.mp) [19] )
33 output files written: data-patt.1 .. data.19
Transcript written on data.log.
converting scraps ... done
making map ... done
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live
2022/dev/Debian) (preloaded format=pdftex)
 restricted \write18 enabled.
entering extended mode
(./data.tex (./th_enc.tex) (./th_texts.tex) (./th_resources.tex
(/usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex))
(./th_fontdef.tex{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}<><><><>)
(./th_formdef.tex) (./th_pagedef.tex) (./th_pages.tex) [1]
)
Output written on data.pdf (1 page, 34360 bytes).
Transcript written on data.log.
done
checking CRC32 of all output files ...
samples/survex/cave1.pdf ... CRC32 error: was e974864e, expected a344ba1f
done.
therion: error -- CRC32 checks not passed.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995648: cffi: reproducible builds: Embedded timestamps in .dvi and .ps files

[Vagrant Cascadian]

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

The build timestamp is embedded in various .dvi and .ps files:

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

  /usr/share/doc/cl-cffi/cffi-manual.ps.gz

  %DVIPSSource:··TeX·output·2021.09.26:1909 16
vs.
  %DVIPSSource:··TeX·output·2022.10.31:0334

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

With this patch applied, cffi should build reproducibly on
tests.reproducible-builds.org

Thanks for maintaining cffi!

live well,
  vagrant
From 7e977d37e721efc87831804dde4ce030cddb308c Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 3 Oct 2021 16:42:20 +
Subject: [PATCH] debian/rules: Export FORCE_SOURCE_DATE=1 in order for texlive
 to respect SOURCE_DATE_EPOCH when generating .dvi and .ps files.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 71e6d87..110daa8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@
 
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#995569: debhelper: act on service files placed in usr/lib/systemd/system

[Niels Thykier]

Control: blocked -1 by 994388

(@Tech-ctte in BCC: Consider this email as an FYI that this bug is
waiting for your resolution of #994388.  I do not expect follow up from
you in any official capacity, but I would strongly appreciate if you
would explicitly clarify how this request will fit into your advice for
the transition plan once you have that.)

Ferenc Wágner:
> Package: debhelper
> Version: 13.5.2
> Severity: normal
> 
> Dear Maintainer,
> 
> If some upstream install procedure places service files under
> /usr/lib/systemd/system, dh_installsystemd won't notice those in
> debian/tmp during package build, thus such units won't be enabled and
> started on the installation of the resulting package.
> 
> I think this could (and should) be done irrespective of the usrmerge
> transition and whether maintainer-provided unit files are installed into
> /usr/lib or /lib, because this has little chance to change anything
> automatically (unless some packages have been shipping unit files under
> /usr/lib with the very purpose of not activating and starting them).
> 

Hi Ferenc,

Thanks for your bug report and I appreciate why you want this feature.

Unfortunately, I have no intention of acting on this request until the
tech-ctte has resolved their advice on how they want the /usr-merge
transition to be resolved (per #995569).

Some might argue that this request is independent of the /usr-merge
transition.  However, adding support for this feature will enable
maintainers to move files from / to /usr much easier than previously and
a key point here is whether that would be seen as supporting/enabling
maintainers in going against the (likely) advice of the tech-ctte to not
do "per package/path" transitions.
  Obviously, a maintainer *can* do this manually without debhelper - but
they would do so at their own peril. Whereas if I add this support
someone will definitely leverage that feature to move from / to /usr
even if that would contradict the recommendation from the tech-ctte.

Sadly, it does leave you hanging if you have an upstream package that
uses /usr/lib where you would manually have to move that to /lib or not
use debhelper at all. And if you move it to /lib, you would eventually
have to "undo" that at a later stage.
  I wish I could provide you with something better, but I am personally
not ready to invest in implementing this feature while there is a
considerably risk that I would need to revert it again or it would be
interpreted as "promoting dissent" against the upcoming /usr-merge
transition[1].


~Niels

PS: The tech-ctte have not officially clarified their resolution on the
/usr-merged migration, but so far I have yet to see a draft / suggestion
that include "migrate paths manually in packages before $FLAG_DAY" as a
proposed solution.  Instead the drafts point to quite the opposite.

[1] I have raised objections in public about some of the /usr-merge
transition plans. I feel this is not an entirely theoretical concern
that other project members would see it as a statement from me if I was
to implement this feature without the explicit approval of the tech-ctte
at this point in time.

Bug#995647: cfi: reproducible builds: Embedded timestamps in .dvi file

[Vagrant Cascadian]

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

The build timestamp is embedded in various .dvi files:

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

  ./usr/share/doc/cfi-sv/cfi.dvi.gz

  ··TeX·output·2022.
vs.
  ··TeX·output·2021.
0020:·3039·2e32·373a·3139·3439·8b00··0100

  ··09.27:1949..
vs.
  ··08.26:1527..

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

With this patch applied, cfi should build reproducibly on
tests.reproducible-builds.org

Thanks for maintaining cfi!

live well,
  vagrant
From 476f5bb1a67ae26eb6f5658c5cb53ea7a112e196 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 3 Oct 2021 16:33:02 +
Subject: [PATCH] debian/rules: Export FORCE_SOURCE_DATE=1 in order for texlive
 to respect SOURCE_DATE_EPOCH when generating .dvi file.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index bacf9a0..0cc7651 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,6 +3,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 build: build-arch build-indep
 build-arch: build-stamp
 build-indep: build-stamp
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

[Paul Gevers]

Hi Reinhard,

On 03-10-2021 16:21, Reinhard Tartler wrote:
> Note that the test doesn't do xz, but zstd compression,
> cf. https://github.com/klauspost/compress/blob/master/zstd/README.md
> 
> so your comment regarding --threads=0 does not seem to apply? -- not
> sure, please let me know what you think.

I was just using $(xz --threads=0) as an example, not claiming that that
was what's happening. Just that large amounts of cores and/or memory can
trigger weird "bugs".

> The consistent OOM is surprising given that you state that the worker
> has 250GB of RAM. Looking at the logs,
> I note that the tests are being passed the option -p 160 by the
> dh-golang helper, so it will build
> and run test executables concurrently. That confirms to me that we are
> indeed running on these 250GB/160 core workers.

We only have one armhf host, so *all* armhf tests are run there. I'm
also not seeing this problem back in the logs:
https://ci.debian.net/munin/ci-worker-armel-01/ci-worker-armel-01/memory.html.
But maybe the incident is too short to be caught by the once per 5
minutes poll.

> Is it possible that armhf is setting up ulimits that limits the amount
> of memory the test may allocate?

root@ci-worker-armel-01:~# ulimit
unlimited

> As far as I understand, all golang packages use autodep8 to declare the
> tests,
> which doesn't support adding the Architecture field.

I think you're right, but maybe we should fix autodep8 to enable the
change like the other overwrites in section `PACKAGE-SPECIFIC
CONFIGURATION` of $(man autodep8).

> In order to get
> around this,
> I guess I could remove the Testsuite field from debian/control and add a
> debian/tests/control that looks similar to what autodep8 generates, but adds
> the Architecture: !armhf  restriction.

Maybe until autodep8 is fixed? I fear that this may cause future trouble
if/when autodep8 support for golang gets updated.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995592: RFS: urlwatch/2.23-2 -- monitors webpages for you

[Maxime Werlen]

Hi Adam,

I've tried to fix my build dependencies. I was indeed not depending on
python3, only build-dependency-indep.

I uploaded a new version.

Regards,

Maxime


Le dim. 3 oct. 2021 à 01:39, Adam Borowski  a écrit :

> On Sat, Oct 02, 2021 at 08:41:54PM +0200, Maxime Werlen wrote:
> >  * Package name: urlwatch
> >Version : 2.23-2
>
> >  urlwatch (2.23-2) unstable; urgency=medium
> >  .
> >* Updated Standards-Version to 4.6.0
> >* Upload to unstable after Bullseye release
>
> E: urlwatch source: missing-build-dependency-for-dh-addon python3 =>
> python3:any | python3-all:any | python3-dev:any | python3-all-dev:any |
> dh-sequence-python3
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ “Exegi monumentum aere perennius” -- “I made a monument more
> ⢿⡄⠘⠷⠚⠋⠀ durable than bronze”.
> ⠈⠳⣄   -- Horace (65-8 BC), leaving the loo, constipated
>
> --
> To unsubscribe, send mail to 995592-unsubscr...@bugs.debian.org.
>

Bug#995646: abntex: reproducible builds: Embedded timestamps in .dvi file

[Vagrant Cascadian]

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

The build timestamp is embedded in various .dvi files:

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

  /usr/share/doc/abntex/abnt-bibtex-alf-doc.dvi.gz

  ...TeX·output·2021
vs.
  ...TeX·output·2022

  ...08.14:0757
vs.
  ...09.17:1623

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

With this patch applied, abntex should build reproducibly on
tests.reproducible-builds.org

Thanks for maintaining abntex!

live well,
  vagrant
From d9f085c50a8eb9979d12f56de6d72300a6f279c4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 3 Oct 2021 16:24:22 +
Subject: [PATCH] debian/rules: Export FORCE_SOURCE_DATE=1 in order for texlive
 to respect SOURCE_DATE_EPOCH when generating .dvi file.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 3d1944c..420a7cf 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,9 @@
 
 #export DH_VERBOSE=1
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@
 
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#993605: lxml.etree.tostring() trailing junk

[Maxime Werlen]

I confirm, all tests are OK with new version.

Thanks,

Maxime


Le ven. 1 oct. 2021 à 13:48, Jakub Wilk  a écrit :

> * Jakub Wilk , 2021-09-03, 17:35:
> >After upgrading libxml2 to 2.9.12+dfsg-3, the tostring() function
> >started returning strings with some trailing junk:
> >
> >  >>> import lxml.etree
> >  >>> html = lxml.etree.fromstring('P')
> >  >>> lxml.etree.tostring(html[0])
> >  b'P'
>
> This is no longer reproducible with libxml2 2.9.12+dfsg-5, presumably
> because this commit was cherry-picked:
> https://gitlab.gnome.org/GNOME/libxml2/-/commit/85b1792e37b131e7
> ("Work around lxml API abuse")
>
> --
> Jakub Wilk
>
> --
> To unsubscribe, send mail to 993605-unsubscr...@bugs.debian.org.
>

Bug#995588: RFS: rumur/2021.09.29-1 -- model checker for the Murphi language

[Matthew Fernandez]

> On Oct 2, 2021, at 16:37, Adam Borowski  wrote:
> 
> On Sat, Oct 02, 2021 at 11:26:19AM -0700, Matthew Fernandez wrote:
>> * Package name: rumur
>>   Version : 2021.09.29-1
> 
>> rumur (2021.09.29-1) unstable; urgency=medium
> 
> 
> E: rumur: python3-script-but-no-python3-dep usr/bin/rumur-run python3

Indeed. From the extended description of that error I had thought this package 
perhaps qualified for the exemption described, but wasn’t sure how to indicate 
this. The script lintian is complaining about is rumur-run, a wrapper that 
orchestrates some common options to one of the binaries. This script is not 
necessary for using the package. That is, someone without Python can directly 
run the binary, spelling out all their options.

With the above in mind, do you think it’s acceptable to retain only a Suggests 
for python3? OTOH maybe this package has been wrong from its first release and 
should have always declared a Depends on python3?

Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error

[S Egbert]

.
> 
> After having stopped chronyd, please run the command below when using the
> 'bindacqdevice' directive and attach the chronyd_debug.txt file.
> 
> # strace -o chronyd_debug.txt chronyd -d -F -1

OK, I did some more testing on my so-called fix:  SO_BINDTOADDRESS define 
statement made no impact toward resolving this problem.


Once I put in the '#define SO_BINDTOADDRESS 1' statement into the 'config.h' 
that was generated by 'configure' setup tool, all the -F settings are now 
working.

'chrony -d -Fx -L-1' F0  F1  F2  F-1
* apt install chrony-4.0 OK   -   -   -
* apt source chrony-4.0  OK   -   -  OK
* git main branch HEAD   OK   -  OK   -
* development + MY FIX   OK   -  OK   - 

My fix made no difference in gitdev HEAD: Please disregard my claim that the 
SO_BINDTOADDRESS C macro we’re not being defined. 

Back to the issue on hand, I like the -F2 setting.

At this point so far, I'm open to further suggestion.

1.  Go ahead and put 4.1 into debian-unstable with -F2 default
2.  Give me more things to try.
3.  ???

Bug#995628: qemu-system-data: desktop file is incomplete, remove it?

[Laurent Bonnaud]

Package: qemu-system-data
Version: 1:6.1+dfsg-6
Severity: normal


Dear Maintainer,

when I start a KDE program I see the following error messages:

kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has 
Type= "Application" but no Exec line
kf.service.sycoca: Invalid Service :  "/usr/share/applications/qemu.desktop"

The qemu.desktop file lacks a shell command, indeed.

In fact I do not see what command could be added there.  Qemu needs at least 
some options to do something useful.  The best solution would perhaps be to 
remove the qemu.desktop completely.


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

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

-- no debconf information

--
Laurent.

Bug#987938: librm: diff for NMU version 2.2.2+really2.1.4-0.1

[Adrian Bunk]

Control: tags 987938 + patch
Control: tags 987938 + pending

Dear maintainer,

I've prepared an NMU for librm (versioned as 2.2.2+really2.1.4-0.1) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it.

Note that the attached debdiff is against the version 2.1.4-1 in 
bullseye/bookworm, not the version in unstable.

A proper fix can be done afterwards, and upgrading to the already 
released upstream version 2.2.3 would then also get rid of the +really
in the version.

cu
Adrian
diff -Nru librm-2.1.4/debian/changelog librm-2.2.2+really2.1.4/debian/changelog
--- librm-2.1.4/debian/changelog2021-01-25 11:39:25.0 +0200
+++ librm-2.2.2+really2.1.4/debian/changelog2021-10-03 18:30:23.0 
+0300
@@ -1,3 +1,17 @@
+librm (2.2.2+really2.1.4-0.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Revert back to 2.1.4 to avoid ABI breakage. (Closes: #987938)
+
+ -- Adrian Bunk   Sun, 03 Oct 2021 18:30:23 +0300
+
+librm (2.2.2-1) unstable; urgency=medium
+
+  * Update/fix debian/watch
+  * New upstream version 2.2.2
+
+ -- Hilko Bengen   Sat, 27 Mar 2021 12:44:31 +0100
+
 librm (2.1.4-1) unstable; urgency=medium
 
   * New upstream version 2.1.4
diff -Nru librm-2.1.4/debian/watch librm-2.2.2+really2.1.4/debian/watch
--- librm-2.1.4/debian/watch2021-01-25 10:30:48.0 +0200
+++ librm-2.2.2+really2.1.4/debian/watch2021-10-03 18:30:22.0 
+0300
@@ -1,4 +1,4 @@
 version=4
 
-https://gitlab.com/tabos/librm/-/tags \
-.*/archive/v(?:\d.*)/librm-v(\d.*).tar.bz2
+https://gitlab.com/tabos/librm/-/tags?sort=updated_desc \
+.*/archive/(?:\d.\S+)/librm-(\d\S+)\.tar\.bz2

Bug#995645: RFS: python-certbot-dns-standalone/1.0.3-1 [ITP] -- Standalone DNS plugin for Certbot with an integrated DSN server

[Linus Vanas]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: team+letsencr...@tracker.debian.org

Dear mentors,

I am looking for a sponsor for my package "python-certbot-dns-standalone":

 * Package name: python-certbot-dns-standalone
   Version : 1.0.3-1
   Upstream Author : Lauri Keel 
 * URL : https://github.com/siilike/certbot-dns-standalone
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/Huitsi/certbot-dns-standalone
   Section : python

It builds those binary packages:

  python3-certbot-dns-standalone - Standalone DNS plugin for Certbot 
with an integrated DSN server


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


  https://mentors.debian.net/package/python-certbot-dns-standalone/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-certbot-dns-standalone/python-certbot-dns-standalone_1.0.3-1.dsc


Changes for the initial release:

 python-certbot-dns-standalone (1.0.3-1) unstable; urgency=medium
 .
   * Initial release. Closes: #993066

Regards,
--
  Linus Vanas

Bug#808867: reportbug: Bug against snappy (src:snappy-player) reported against src:snappy

[Nis Martensen]

On 23 Dec 2015 Julian Andres Klode wrote:
> Package: reportbug
> Version: 6.6.5
> Severity: normal
> 
> This is somewhat strange:
> 
> The snappy package comes from the source package snappy-player, whereas
> there also is a snappy source package that builds some development
> libraries.
> 
> reportbug snappy fails, it will report the bug against Source: snappy
> instead of Package: snappy.

Are you sure? The output you pasted below only shows which package was
used when looking for existing bugs, not which package the new bug will
be reported against.

When retrieving existing bugs reportbug uses a somewhat wider query to
increase the likelyhood of finding all relevant bugs.

I intend to close this bug when the next version of reportbug is uploaded.


> -- Output
> 
> $ reportbug snappy
> Detected character set: UTF-8
> Please change your locale if this is incorrect.
> 
> Using 'Julian Andres Klode ' as your from address.
> Getting status for snappy...
> Which of the following packages is the bug in?
> 
> 1 libsnappy-dev  fast compression/decompression library (development files)
> 
> 2 libsnappy1 fast compression/decompression library
> 
> 3 libsnappy1v5   fast compression/decompression library
> 
> 4 snappy Powerful media player with a minimalistic interface
> 
> Select one of these packages: 4
> Please enter the version of the package this report applies to (blank OK)
> > 
> Will send report to Debian (per lsb_release).
> Querying Debian BTS for reports on snappy (source)...
> 1 bug report found:
> 
> Bugs with severity wishlist
>   1) #748627  libsnappy-dev: Static archive unsuitable for linking into 
> dynamic object
> (1-1/1) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? n

Bug#995194: libopenal1: i386 baseline violation

[Nicholas Guriev]

On Ср, 2021-09-29 at 22:41 +0200, bret curtis wrote:
> Does anyone actually run or want to run openal-soft on a Pentium Pro?

Frankly, I have no so old hardware. My bug report was primarily about an
inconsistency. Wiki says i386 packages cannot use streaming extensions.
We should either avoid SIMD or raise minimal hardware requirements.

Debian Installation Guide[1] in paragraph 2.1.2.1 states that bullseye
will not run on Intel Pentium or earlier processor, however in section
3.4 the document mentions Pentium 4 as the minimal recommended CPU.
(I don't get is this a minimal or just a recommended requirement?)

I personally believe such a decision should be adopted globally for
every package in the archive by a compiler maintainer or a port
maintainer if this post exists.

On the flip side, there are middle solutions. OpenAL Soft may use
function multiversioning, GCC feature. Though, it requires support in
source code. Or the library can be compiled twice, first time with SSE2
and second time without the extension. Then a postinst script will
choose a correct shared object at configure time via dpkg-divert(1) or a
similar technique. But at this stage, a question arises about available
HDD space. Ancient hardware can face a shortage.

But if someone uses i386 for embedded systems with no extensions, it may
be better to split the port into two, the first one for compatibility
layer and the second one for unusual hardware.

 [1]: https://www.debian.org/releases/stable/i386/index.en.html



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