Bug#1021420: clisp: problem with reserved ranges during startup on hurd-i386

[Flavio Cruz]

Package: clisp
Version: 1:2.49.20210628.gitde01f0f
Severity: important
Tags: patch
X-Debbugs-Cc: flavioc...@gmail.com

Building the package from source on hurd-i386 will make clisp throw the
following
message at startup:

Warning: reserving address range 0x1806...0xbfff that contains memory
mappings. clisp might crash later!

Attached patch updates MAPPABLE_ADDRESS_RANGE_START to reflect the new memory
layout set in 2021 [1]
[1]
http://patchwork.ozlabs.org/project/glibc/patch/20211231172645.1589461-1-samuel.thibault@ens-
lyon.org/

This was also submitted upstream at https://gitlab.com/gnu-
clisp/clisp/-/merge_requests/6


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
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 clisp depends on:
ii  libc6   2.34-8
ii  libffcall1b 2.4-2
ii  libreadline88.2~rc2-2
ii  libsigsegv2 2.14-1
ii  libtinfo6   6.3+20220423-2
ii  sensible-utils  0.0.17

clisp recommends no packages.

Versions of packages clisp suggests:
pn  clisp-doc 
pn  clisp-module-berkeley-db  
pn  clisp-module-clx  
pn  clisp-module-dbus 
pn  clisp-module-fastcgi  
pn  clisp-module-gdbm 
pn  clisp-module-libsvm   
pn  clisp-module-pari 
pn  clisp-module-pcre 
pn  clisp-module-postgresql   
pn  clisp-module-zlib 
pn  gdb   
pn  hyperspec 
pn  slime 

-- no debconf information
>From 03611d4544b98e0b09c7f07b2c253c61a018a5c6 Mon Sep 17 00:00:00 2001
From: Flavio Cruz 
Date: Sat, 8 Oct 2022 00:23:27 -0400
Subject: [PATCH] Bump MAPPABLE_ADDRESS_RANGE_START for Hurd

---
 src/lispbibl.d | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/lispbibl.d b/src/lispbibl.d
index 70d47d148..0961f167b 100644
--- a/src/lispbibl.d
+++ b/src/lispbibl.d
@@ -2378,13 +2378,13 @@ typedef enum {
 /* On Hurd/i386:
MMAP_FIXED_ADDRESS_HIGHEST_BIT = 30
CODE_ADDRESS_RANGE   = 0xUL or 0x0800UL
-   MALLOC_ADDRESS_RANGE = 0x0800UL
+   MALLOC_ADDRESS_RANGE = 0x2000UL
SHLIB_ADDRESS_RANGE  = 0x0100UL
STACK_ADDRESS_RANGE  = 0x0100UL
Addresses >= 0xC000UL are not mmapable.
There is room from 0x1100UL to 0xBFFFUL, but let's keep some
distance. */
-#define MAPPABLE_ADDRESS_RANGE_START 0x1800UL
+#define MAPPABLE_ADDRESS_RANGE_START 0x2800UL
 #define MAPPABLE_ADDRESS_RANGE_END   0xBFFFUL
   #endif
   #if (defined(__FreeBSD__) || defined(UNIX_GNU_FREEBSD)) && defined(I80386)
-- 
2.35.1

Bug#1021106: maint-guide: Typos in previous changelog entries

[Helge Kreutzmann]

Hello Osamu,
On Sat, Oct 08, 2022 at 12:51:12PM +0900, Osamu Aoki wrote:
> On Sun, 2022-10-02 at 10:40 +0200, Helge Kreutzmann wrote:
> >  * po: update de by Holger Wansing.
> > 
> > As I made the update between 1.2.48 and 1.2.49, please correct this to
> > 
> >  * po: update de by Helge Kreutzmann.
> > 
> 
> Corrected.  Sorry.

Thanks a lot!

> > And the next line seems to be another typo:
> > FTBR. → FTBFS.
> 
> This FTBR is for "fails to build reproducibly"
> 
> I see this marking at:
> https://qa.debian.org/developer.php?login=os...@debian.org
> for maint-guide
> by https://reproducible-builds.org/citests/
> 
> (Explained now.)

Ah, I did not know this acronym.

Thanks!

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1021106: maint-guide: Typos in previous changelog entries

[Osamu Aoki]

On Sun, 2022-10-02 at 10:40 +0200, Helge Kreutzmann wrote:
>  * po: update de by Holger Wansing.
> 
> As I made the update between 1.2.48 and 1.2.49, please correct this to
> 
>  * po: update de by Helge Kreutzmann.
> 

Corrected.  Sorry.


> And the next line seems to be another typo:
> FTBR. → FTBFS.

This FTBR is for "fails to build reproducibly"

I see this marking at:
https://qa.debian.org/developer.php?login=os...@debian.org
for maint-guide
by https://reproducible-builds.org/citests/

(Explained now.)


Thanks.

Bug#1020931: fixed in sord 0.16.14-2

[Paul Wise]

Control: tags -1 + fixed-upstream patch
Control: forwarded -1 
https://github.com/drobilla/sord/commit/67bcd63bda9d7b095489a09b9880aa730ddb5488
 https://github.com/drobilla/sord/issues/6

On Wed, 28 Sep 2022 21:05:52 + Dennis Braun wrote:

>* Drop optional Build-Depends libpcre++-dev (Closes: #1020931)

I contacted upstream about this and they have switched to PCRE2 in git,
I have asked upstream to make a new release, when it happens, please
update to it, add PCRE2 to build-deps so sordi_validate exists again.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1013554: golang-github-valyala-tcplisten: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/valyala/tcplisten returned exit code 1

[Marco d'Itri]

On Jul 30, Mathias Gibbens  wrote:

>   Feel free to apply it directly yourself. :) If this does fix the
> issue, it would probably be good to contact Lucas and see if we can
> figure out what in the rebuild setup needs to be tweaked to ensure that
> "ip6-localhost" is properly resolvable.
This bug has been inactive for over two months: do you need any help?
It is keeping cfrpki out of testing.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1021419: zxing-cpp: add tools and Python to unstable too

[Paul Wise]

Source: zxing-cpp
Version: 1.2.0-1
Severity: wishlist

I would like zxing-cpp-tools and python3-zxing-cpp in bookworm,
one option would be transitioning the package from experimental.

The transition looks fairly small and a rebuild would take care of the
only issue listed in the experimental manual migration pseudo-excuses.


https://release.debian.org/transitions/html/auto-zxing-cpp.html
https://qa.debian.org/excuses.php?package=zxing-cpp=1
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Then I read that there are major API/ABI issues upstream.

https://github.com/zxing-cpp/zxing-cpp/releases
https://github.com/zxing-cpp/zxing-cpp/issues/333

Since those issues might not be resolved for bookworm, please consider
adding the zxing-cpp-tools and python3-zxing-cpp packages to unstable,
so that they will transition and definitely be available in bookworm.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1021418: builtin: echo: Treat -n as a string

[Alejandro Colomar]

Package: dash
Version: 0.5.11+git20210903+057cd650a4ed-9
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi,

I'd like if dash(1)'s built-in echo(1) would treat -n as a string.
POSIX specifies the behavior as implementation-defined, but XSI
(see standards(7)) is stricter, and specifies that echo(1) has no
options (-n has to be treated as any other string).

Considering that dash(1) tends to be minimal, the minimal thing to
do is to not implement the option.

Cheers,

Alex


-- 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.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 dash depends on:
ii  debianutils  5.7-0.3
ii  dpkg 1.21.9
ii  libc62.35-1

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#1021417: apt-venv: deprecated list of Ubuntu releases

[Braulio Henrique Marques Souto]

Package: apt-venv
Version: 1.0.0-2
Severity: important
X-Debbugs-Cc: brau...@disroot.org

Dear Maintainer,

Apt-venv has a deprecated list of Ubuntu versions.

Therefore when we use apt-venv with one of the deactivated versions (lucid - 
precise - utopic) of Ubuntu, we get an error, see the examples below:

  # apt-venv lucid -c "apt-get update"
  Ign:1 http://archive.ubuntu.com/ubuntu lucid InRelease
  Ign:2 http://security.ubuntu.com/ubuntu lucid-security InRelease
  Ign:3 http://archive.ubuntu.com/ubuntu lucid-updates InRelease
  Err:4 http://security.ubuntu.com/ubuntu lucid-security Release
404  Not Found [IP: 185.125.190.39 80]
  Err:5 http://archive.ubuntu.com/ubuntu lucid Release
404  Not Found [IP: 185.125.190.39 80]
  Err:6 http://archive.ubuntu.com/ubuntu lucid-updates Release
404  Not Found [IP: 185.125.190.39 80]

  # apt-venv precise -c "apt-get update"
  Welcome to apt virtual environment for precise release.
  All the configuration is available in /root/.config/apt-venv/precise
  You may want run first "apt-get update"
  Ign:1 http://security.ubuntu.com/ubuntu precise-security InRelease
  Err:2 http://security.ubuntu.com/ubuntu precise-security Release
404  Not Found [IP: 91.189.91.38 80]
  Ign:3 http://archive.ubuntu.com/ubuntu precise InRelease
  Ign:4 http://archive.ubuntu.com/ubuntu precise-updates InRelease
  Err:5 http://archive.ubuntu.com/ubuntu precise Release
404  Not Found [IP: 185.125.190.36 80]
  Err:6 http://archive.ubuntu.com/ubuntu precise-updates Release
404  Not Found [IP: 185.125.190.36 80]

  # apt-venv utopic -c "apt-get update"
  Welcome to apt virtual environment for utopic release.
  All the configuration is available in /root/.config/apt-venv/utopic
  You may want run first "apt-get update" 
  Ign:1 http://archive.ubuntu.com/ubuntu utopic InRelease
  Ign:2 http://archive.ubuntu.com/ubuntu utopic-updates InRelease
  Ign:3 http://security.ubuntu.com/ubuntu utopic-security InRelease
  Err:4 http://archive.ubuntu.com/ubuntu utopic Release
404  Not Found [IP: 91.189.91.38 80]
  Err:5 http://security.ubuntu.com/ubuntu utopic-security Release
404  Not Found [IP: 185.125.190.36 80]
  Err:6 http://archive.ubuntu.com/ubuntu utopic-updates Release
404  Not Found [IP: 91.189.91.38 80]

Only the 'trusty' version is with the link that works, but soon it should be 
turned off too.

The fix is very simple, just change the name of the Ubuntu releases to the new 
ones and add their respective public keys, to be able to use apt-venv with the 
latest releases of Ubuntu.


Regards,

Braulio

Bug#1021416: RFS: units-cpp/3.0.0~alpha-3+ds-1 [ITP] -- unit conversion library for c++ (development files)

[matthias . geiger1024]

Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
 I am looking for a sponsor for my package "units-cpp":
 
 * Package name : units-cpp
 Version  : 3.0.0~alpha-3+ds-1
 Upstream contact : Nic Holthaus 
 * URL  : https://github.com/nholthaus/units
 * License  : MIT
 * Vcs  : https://salsa.debian.org/werdahias/units
 Section  : libdevel
 
 The source builds the following binary packages:
 
 libunits-cpp-dev - unit conversion library for c++ (development files)
 
 To access further information about this package, please visit the following 
URL:
 
 https://mentors.debian.net/package/units-cpp/
 
 Alternatively, you can download the package with 'dget' using this command:
 
 dget -x 
https://mentors.debian.net/debian/pool/main/u/units-cpp/units-cpp_3.0.0~alpha-3+ds-1.dsc
 
 Changes for the initial release:
 
 units-cpp (3.0.0~alpha-3+ds-1) unstable; urgency=medium
 .
 * Initial release. (Closes: #1019715)
 This is a small header-only library. It is needed for corectrl.
 Regards,

Matthias Geiger

Bug#1021415: Acknowledgement (SIGSEGV when attempting to enter chroot)

[Timothy Pearson]

affects chroot

After investigation, this appears to be the same bug as #1021109.  Installing 
the locales package and adding a default locale prior to upgrading to sid 
appears to work around the issue.

- Original Message -
> From: "Debian Bug Tracking System" 
> To: "Timothy Pearson" 
> Sent: Friday, October 7, 2022 6:00:04 PM
> Subject: Bug#1021415: Acknowledgement (SIGSEGV when attempting to enter 
> chroot)

> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1021415:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021415.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
> Matthias Klose 
> 
> If you wish to submit further information on this problem, please
> send it to 1021...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 1021415: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021415
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#1016279: libzypp: diff for NMU version 17.25.7-2.2

[Adrian Bunk]

On Fri, Oct 07, 2022 at 10:18:38PM +, Mike Gabriel wrote:
> Hi Adrian,

Hi Mike,

> On  Do 06 Okt 2022 22:42:47 CEST, Adrian Bunk wrote:
> 
> > Control: tags 1016279 + patch
> > Control: tags 1016279 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for libzypp (versioned as 17.25.7-2.2) and uploaded
> > it to DELAYED/15. Please feel free to tell me if I should cancel it.
> > 
> > cu
> > Adrian
> 
> Thanks for doing this NMU.

thanks, rescheduled for immediate upload.

> Mike

cu
Adrian

Bug#1001064: MR created in Salsa

[Soren Stoutner]

The MR can be seen at the following URL:

https://salsa.debian.org/cryptocoin-team/electrum/-/
merge_requests[1]

-- 
Soren Stoutner
so...@stoutner.com


[1] https://salsa.debian.org/cryptocoin-team/electrum/-/
merge_requests


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

Bug#1001064: MR created in Salsa

[Soren Stoutner]

tags 1001064 patch
thanks

I have created a MR in Salsa that should contain everything needed to release 
version 4.3.2.

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1021415: SIGSEGV when attempting to enter chroot

[Timothy Pearson]

Package: bash
Version: 5.2-1

When attempting to enter a sid chroot on ppc64el, bash causes a SIGSEGV.  
Confirmed to be in the bash package by successfully installing a bookworm 
chroot, then confirming the crash occurs after upgrading only bash to the 
version in sid.

Bug#1021410: dh-python: cannot handle alpha version in environment marker

[Stefano Rivera]

Hi Timo (2022.10.07_19:52:25_+)

> src:black declares a dependency on tomli with
>   "tomli>=1.1.0; python_full_version < '3.11.0a7'"

Thanks, clearly we need to support the full PEP 440 version syntax here.
I'll have a look this weekend.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1021414: debian-edu-config: Wrong DHCP configuration on separate LTSP server

[Wolfgang Schweer]

Source: debian-edu-config
Version: 2.11.56+deb11u4
Severity: normal

On a separate LTSP server the DHCP service fails to start after stopping 
it. This is caused by a wrong Requires statement in the systemd unit 
file. Instead of slapd.service, nslcd.service is required:

diff --git a/share/debian-edu-config/isc-dhcp-server.service.eth1_only 
b/share/debian-edu-config/isc-dhcp-server.service.eth1_only
index 46557e6b..f2b7fb58 100644
--- a/share/debian-edu-config/isc-dhcp-server.service.eth1_only
+++ b/share/debian-edu-config/isc-dhcp-server.service.eth1_only
@@ -1,7 +1,7 @@
 [Unit]
 Description=DHCP server
 After=network.target network-online.target
-Requires=slapd.service
+Requires=nslcd.service
 
 [Service]
 Type=forking

Wolfgang


signature.asc
Description: PGP signature

Bug#1016279: libzypp: diff for NMU version 17.25.7-2.2

[Mike Gabriel]

Hi Adrian,

On  Do 06 Okt 2022 22:42:47 CEST, Adrian Bunk wrote:


Control: tags 1016279 + patch
Control: tags 1016279 + pending

Dear maintainer,

I've prepared an NMU for libzypp (versioned as 17.25.7-2.2) and uploaded
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian


Thanks for doing this NMU.

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



pgpraYMJaP_vE.pgp
Description: Digitale PGP-Signatur

Bug#1021413: ITP: lomiri-calculator-app -- Calulcator App for Lomiri Operating Environment

[Mike Gabriel]

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

* Package name: lomiri-calculator-app
  Version : 3.3.7
  Upstream Author : UBports Developers 
* URL : 
https://gitlab.com/ubports/development/apps/lomiri-calculator-app
* License : GPL-3
  Programming Lang: QML
  Description : Calulcator App for Lomiri Operating Environment

 This app is a core app for Ubuntu Touch's shell Lomiri. Ubuntu Touch is
 a mobile OS developed by the UBports Foundation. Lomiri is its operating
 environment optimized for touch based human-machine interaction, but
 also support convergence (i.e. switching between tablet/phone and
 desktop mode).
 .
 This package provides Lomiri's Calulcator App.
 .
 This package will be maintained by Debian's UBports Packaging Team.

Bug#1021402: reproducible: Please force merged-/usr for build2

[Luca Boccassi]

On Fri, 7 Oct 2022, 21:45 Simon McVittie,  wrote:

> On Fri, 07 Oct 2022 at 18:07:45 +0100, Luca Boccassi wrote:
> > Wouldn't it be sufficient to create the build2 chroot as merged-usr
> > from the start?
>
> That would also be fine, but I think the way the reproducible-builds
> infrastructure works is that it caches a single (non-merged-/usr)
> pbuilder tarball per suite and converts it to merged-/usr on-demand
> for build2, to avoid having to cache essentially the same content twice.
> The important thing here is that one of the two builds should be
> merged-/usr, and the other should not.
>
> Having a merged-/usr pbuilder tarball and unmerging it with
> dpkg-fsys-usrunmess for one of the two builds would also work, but I
> suspect that would be less reliable than starting from non-merged-/usr and
> merging one of the builds but not the other.


In this particular case, it would seem to me that it would be best to
optimize for correctness and safety (and less engineering cost) rather than
disk space saving?

Kind regards,
Luca Boccassi

>
>

Bug#1021412: RM: golang-github-libgit2-git2go-v32 -- ROM; obsolete, superseded by golang-github-libgit2-git2go

[Timo Röhling]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Pirate Praveen 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear FTP team,

please remove the aforementioned package, which is no longer needed.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmNAmwMACgkQ+C8H+466
LVn61wwAl+jFv93wYfw7BT8fl3ttWmNrBzGr5gV52p4+ohyIsuf04xXgjoh9zTld
4uq561E+vdMgWNzzBjVHh6htuPV2V0l873VYve8UBgX2SOT41V0kWTr0AFbWQBOH
53mS+pQUOKCpzXj1ZGVAI/NvCCjgUCuWZWWe2RhuwUSZiXqLANWzdJN6aKeuMOZC
3LRrcZtwR/iUACHqlq7htfmlVUoXCNsLOBY22h1e7Fphf6Hrv+oawj/xR5i4m/D0
FVlUNvPUeX+JKhWsial97s+e0VbyBXtNccBSUFzdiH8dADFYiLRoQ+TP8EgrxlhB
p8hKdOc0oddrod/ltAQBvfIPQ9SnWD970im02eB9rOjimf2ufeHe8or4BERqqJK6
Wi8/10YI7z0oSNB8DuAugm5XXcmIlnS+cQNg9c93pxiKzEP/XQEIeB0L/rv5uHmp
wgArjlWC8tr/9Cv7U8jBCFVSc6iEeItyD199M5nITvHQZOBgqb0rSrxda9o+P8FO
j2WOuU06
=gkJ8
-END PGP SIGNATURE-

Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'

[Albert Nash]

Simon, thanks, this worked for me:
Workaround: also upgrade samba-libs to the version from testing …
It pulled, I think, also a new version of libc6. Now I finally have control 
:-). And also thanks for cleaning up the “Package:” mess I inadvertently 
created.
Cheers!
Albert

Bug#1021411: ITP: minetest-mod-basic-robot-csm -- Minetest mod - basic robot client side mod

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
Severity: wishlist
Owner: "Ying-Chun Liu (PaulLiu)" 


* Package name: minetest-mod-basic-robot-csm
  Version : 0.0~git20190703.e082c6a
  Upstream Author : rnd 
* URL : https://github.com/ac-minetest/basic_robot_csm
* License : GPL-3+
  Programming Lang: Lua
  Description : Minetest mod - basic robot client side mod
 basic-robot-csm is a light-weight robot module of client side of
 minetest. It provides a simple GUI with 8 tabs. Players can write
 programs in Lua in those tabs. And run the programs from client side.


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017419: inkscape-textext: Please package new upstream version (1.8.1)

[Antonio Russo]

I've pushed packaging for 1.8.2 to salsa [1].

I don't presently have a testing/unstable system to test this with,
(and I wasn't able to trivially backport 1.2.1), so I can only
confirm it works on 1.0.2-4 and 1.1.2-3~bpo11+1.

If anyone confirms this works on unstable, I'll push it out.
Otherwise it may be a while before I migrate any machines
to testing.

Antonio

[1] https://salsa.debian.org/aerusso-guest/textext

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021402: reproducible: Please force merged-/usr for build2

[Simon McVittie]

On Fri, 07 Oct 2022 at 18:07:45 +0100, Luca Boccassi wrote:
> Wouldn't it be sufficient to create the build2 chroot as merged-usr
> from the start?

That would also be fine, but I think the way the reproducible-builds
infrastructure works is that it caches a single (non-merged-/usr)
pbuilder tarball per suite and converts it to merged-/usr on-demand
for build2, to avoid having to cache essentially the same content twice.
The important thing here is that one of the two builds should be
merged-/usr, and the other should not.

Having a merged-/usr pbuilder tarball and unmerging it with
dpkg-fsys-usrunmess for one of the two builds would also work, but I
suspect that would be less reliable than starting from non-merged-/usr and
merging one of the builds but not the other.

smcv

Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress

[Santiago Garcia Mantinan]

> The kernel using the MAC of a real device, if none is specified, is
> precisely what we wanna avoid.  Systemd is not involed.

Like I said, if we don't specify the mac address systemd will set up a fake
one for us, so... systemd is involved and the kernel is not allowed to use a
real one, that's why I said that bridge-utils shouldn't do a thing about
this.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#1021403: [parted] /usr/sbin/parted: invalid token: swap

[Jean-Marc LACROIX]

Le 07/10/2022 à 18:29, Colin Watson a écrit :

Control: severity -1 normal
Control: fixed -1 3.5-1

On Fri, Oct 07, 2022 at 05:29:14PM +0200, Jean-Marc LACROIX wrote:

Severity: critical


"makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems where
you install the package"

A difficulty with using the CLI, or even a missing feature in the CLI,
doesn't fall into any of these categories.


According documentation available in man it seems possible to create one
partition of type "swap" by using "set" option on command line.

After many tests done with Linux "parted" command and Ansible module
"parted", it seems that it is not possible to set one logical partition as a
swap partition with the flag option available into parted tool.

My disk uses for test has following partitions...

ansible@thinkpad-410:~$ sudo fdisk -l /dev/sda
Disque /dev/sda : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : HGST HTS721010A9
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x483880d2

Périphérique AmorçageDébutFin   Secteurs Taille Id Type
/dev/sda1*2048   48828415   48826368  23,3G 83 Linux
/dev/sda2 48830462 1953523711 1904693250 908,2G  5 Étendue
/dev/sda5 48830464   68360191   19529728   9,3G 8e LVM Linux
/dev/sda6 68362240   703610871998848   976M 82 partition
d'échange Linux / Solaris


This says that it's already a swap partition, so I'm not sure why you
need to set it as one.  Can you explain further?


Yes,

Ansible is one tool which is able to manage idempotence feature.

Idempotence is originally  a concept from  Mathematics. As  defined by
Wikipedia,

idempotence is the property  of certain operations in mathematics  and
computer science whereby they can   be applied multiple times  without
changing the result beyond the initial application.

Therefore, the designer should  define only one variable (for example)
to  indicate that /dev/sda6is a logical   partition located  on an
extended partition with   type  swap. This  therefore  constitutes  an
element of choice (the   specification)  which must be considered   as
non-modifiable and therefore inviolable  (!). Of course, if  we modify
the specification, then the partition will have to change state.

On the first  run, of course,  because there is  nothing on  the disk,
then Ansible detect this feature and  then force a command (parted) to
create the partition with swap type. But on the second pass (and later
pass), because this partition is already set  to the exact type chosen
by designer, then no action is done (!)



(On an MBR partition table like this, all that setting the "swap" flag
does is set the partition type to 0x82.)


/dev/sda7 70363136   742666233903488   1,9G 8e LVM Linux
/dev/sda8 74268672  279068671  20480  97,7G 8e LVM Linux

and when i try to set one partition with swap, then ...

ansible@thinkpad-410:~$ sudo  /usr/sbin/parted -s -m -a optimal /dev/sda --
unit KiB set 6 swap on
/usr/sbin/parted: invalid token: swap

I have also tried, but without success...

ansible@thinkpad-410:~$ sudo  /usr/sbin/parted -s -m -a optimal /dev/sda --
unit KiB set 6 swap on set 6 lvm off
/usr/sbin/parted: invalid token: swap


This was fixed in parted 3.4.64.  From the NEWS file:

   Add use of the swap partition flag to msdos disk labeled disks.

But since it's already of the correct type, maybe you can just skip that
bit on older versions of parted?

(Or, if your automation is building the entire system from scratch, then
another option might be to use GPT instead of MBR.)



Dear Colin,

First of all, many thanks for the quickly answer and of course for the
good news for this bug available in Debian Bookworm Release.

Please find some trace to verify behaviour with your new package

ansible@thinkpad-410:~$ apt-cache policy parted
parted:
  Installé : 3.4-1
  Candidat : 3.4-1
 Table de version :
 3.5-2 80
 80 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
 *** 3.4-1 500
500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status
 3.2-25 90
 90 http://ftp.de.debian.org/debian oldstable/main amd64 Packages


ansible@thinkpad-410:~$ cat /etc/debian_version
11.5
ansible@thinkpad-410:~$ dpk -l |grep -v ii
-bash: dpk : commande introuvable
ansible@thinkpad-410:~$ dpkg -l |grep -v ii
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| 
État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements

|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom  Version 
  Architecture Description

Bug#1021410: dh-python: cannot handle alpha version in environment marker

[Timo Röhling]

Package: dh-python
Version: 5.20221001
Severity: normal
Control: affects -1 src:black

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

src:black declares a dependency on tomli with
  "tomli>=1.1.0; python_full_version < '3.11.0a7'"

However, this breaks dh_python3:

   dh_python3 -O--buildsystem=pybuild
Traceback (most recent call last):
  File "/usr/bin/dh_python3", line 284, in 
main()
  File "/usr/bin/dh_python3", line 214, in main
dependencies.parse(stats, options)
  File "/usr/share/dh-python/dhpython/depends.py", line 253, in parse
deps = parse_requires_dist(self.impl, fpath, bdep=self.bdep,
  File "/usr/share/dh-python/dhpython/pydist.py", line 557, in 
parse_requires_dist
dependency = guess_deps(req=req)
  File "/usr/share/dh-python/dhpython/pydist.py", line 193, in guess_dependency
action = check_environment_marker_restrictions(
  File "/usr/share/dh-python/dhpython/pydist.py", line 393, in 
check_environment_marker_restrictions
int_ver = [int(x) for x in int_ver]
  File "/usr/share/dh-python/dhpython/pydist.py", line 393, in 
int_ver = [int(x) for x in int_ver]
ValueError: invalid literal for int() with base 10: '0a7'
make: *** [debian/rules:7: binary] Error 1


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmNAg3UACgkQ+C8H+466
LVnzuwwA0GQIcatgZai+G3/cRL5dQLhOGHnHbY0a9wM4BjUveQeNzTeplqQbpaOs
wgr2rmCsAVgA6bhhDGv4R/t83GitoP+C1L88QUZ9HpvbaS1OAhV1xrwcH0NqT8hn
0Va8WAZ+vIoKIuarvKzIYspNjSb056e2VjcOuFQ+gzXd8yJLCLZ3+ghwye624qbK
UCJr7JCLyG1lQ4FMXnLDlWHrtJlY31GoUDI6QgcM5Tvc6uKkvK6fxE5OHQlu3uG5
f/pFS4iE6Qf4ou49lH0k5X33xwTuPDTH+VSvxttWLVkoZ4acdcFmtNUedw+/6R7M
Se+QD8zc8a9S92DQGTS5buXJ6HiXVcq1c18N8Mbx5cWfZGvsZufaudMh5ASowGjG
PlEF9riZ3sBpQ6KMdNQ6sIoTdUYKdJ6gxLhMvN6xa3ln8k3i8CYkuT3RGHBLT2cX
TZnw4mzFQCKgWb2ZFZ24oRzBJboF0oKkcfrEslLNkpMH3XnpXFxfFVJa4GVb55W0
GghW6pAB
=kTdz
-END PGP SIGNATURE-

Bug#1006945: please consider supporting wildcards

[Niels Thykier]

Control: tags -1 wontfix

Marc Haber:

Package: debhelper
Version: 13.6
Severity: wishlist
File: /usr/bin/dh_link

Hi,

this is my adduser.links:
[...]

I think you get the idea.

Would it not be nice to be able to write instead:
usr/share/man/*/man8/adduser.8.gz usr/share/man/*/man8/addgroup.8.gz
usr/share/man/*/man8/deluser.8.gz usr/share/man/*/man8/delgroup.8.gz

or even
usr/share/man/*/man8/adduser.8.gz usr/share/man/*/man8/
usr/share/man/*/man8/deluser.8.gz usr/share/man/*/man8/

Instead?

Greetings
Marc


Hi Marc,

I appreciate that it is unwieldly to maintain that links file.  However, 
I also feel like it is a special case that could just as easily be 
solved by having an executable debhelper config file.


Something like (note: untested):

"""
cat 

Bug#1021409: some findings

[Antoine Beaupré]

I needed to install libusb-1.0-0-dev and libftdi-dev to build the
thing. But then it doesn't start, I reported the issue here:

https://community.frame.work/t/exploring-the-embedded-controller/12846/91?u=anarcat

a.
-- 
On ne peut s'empêcher de vieillir, mais on peut s'empêcher de devenir
vieux.
- Henri Matisse

Bug#1021407: python-pretend: please drop pypy-pretend to support python2.7 removal

[Paul Gevers]

Hi,

[Hit send too fast]

On 07-10-2022 21:39, Paul Gevers wrote:

I'm about to upload an NMU with the attached changes.


I meant to say to DELAYED/5. Please let me know if I should cancel or delay.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021407: python-pretend: please drop pypy-pretend to support python2.7 removal

[Paul Gevers]

Control: tags -1 pending patch

Dear maintainers,

On Fri, 7 Oct 2022 20:48:42 +0200 Paul Gevers  wrote:

If I didn't make a mistake, python-pretend is keeping pypy in the key
package set because it (Build-)Depends on it. Again, if I didn't make a
mistake, there are no reverse Build-Depends or Depends anymore of
pypy-pretend (except python-packaging, which isn't built anymore), so I 
think the package can just be dropped. That would be another step in the 
python2.7 removal transition.


I'm about to upload an NMU with the attached changes. I have confirmed 
with diffoscope that the python3-pretend package is unchanged.


Paul

diff --git a/debian/changelog b/debian/changelog
index 8f9cd3e..47d10ea 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-pretend (1.0.9-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop building pypy-pretend (Closes: #1021407)
+
+ -- Paul Gevers   Fri, 07 Oct 2022 21:27:09 +0200
+
 python-pretend (1.0.9-2) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --git a/debian/control b/debian/control
index 987815a..9a65e9e 100644
--- a/debian/control
+++ b/debian/control
@@ -5,10 +5,7 @@ Section: python
 Priority: optional
 Build-Depends:
  debhelper-compat (= 13),
- dh-sequence-pypy,
  dh-sequence-python3,
- pypy,
- pypy-setuptools,
  python3-all,
  python3-setuptools,
 Standards-Version: 4.5.1
@@ -27,16 +24,3 @@ Description: Python library for stubbing (Python 3)
  Stubbing is a technique for writing tests. You may hear the term mixed up with
  mocks, fakes, or doubles. Basically a stub is an object that returns 
pre-canned
  responses, rather than doing any computation.
- .
-
-Package: pypy-pretend
-Architecture: all
-Depends: ${misc:Depends}, ${pypy:Depends}
-Description: Python library for stubbing (PyPy)
- Pretend is a library to make stubbing with Python easier.
- .
- Stubbing is a technique for writing tests. You may hear the term mixed up with
- mocks, fakes, or doubles. Basically a stub is an object that returns 
pre-canned
- responses, rather than doing any computation.
- .
- This package contains the PyPy version of pretend.
diff --git a/debian/pypy-pretend.docs b/debian/pypy-pretend.docs
deleted file mode 100644
index a1320b1..000
--- a/debian/pypy-pretend.docs
+++ /dev/null
@@ -1 +0,0 @@
-README.rst


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021409: RFP: fw-ectool -- Framework laptop embedded controller tool

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: fw-ectool
  Version : none
  Upstream Author : https://frame.work/
* URL : https://github.com/FrameworkComputer/EmbeddedController
* License : BSD-3 clause
  Programming Lang: C
  Description : Framework laptop embedded controller tool

The fw-ectool binary provides users with ways of interacting with
the embedded controller in their laptop. This could mean something as
fancy as changing LED colors:

ectool led left blue

or more critical as limiting charge percentages:

ectool fwchargelimit 80

The actual repository above contains the *entire* embedded controller
source code, but the actual binary I'm interested in is only inside
the `util` directory. Apparently:

https://www.howett.net/posts/2021-12-framework-ec/#using-fw-ectool

... the way to get the binary is with:

make utils

inside said repository.

I'm not sure we want to ship the entirety of this source code in
Debian, however, so I'm looking for advice on how to manage this. In
particular, I understand that the framework EC is based on the
Chromebook EC, so it's technically a fork. And therefore the ectool
here *could* be used (or not?) on a chromebook as well. I'm not sure.

Ideally, that tool would be split out in a different source repository
and could interoperate with different ECs out there, but this is not
the hand we have been given yet.

I am not aware of a similar tool in Debian, but would very welcome
other advice on this.

Thanks!

Bug#1021393: closed by Thomas Ward ()

[Thomas Ward]

Stuart,

With my Ubuntu Core Dev hat on and Ubuntu Server Team hat on, the Ubuntu 
team decided that disabling IPv6 on a server is an administrator 
decision that is "not the defaults" and the default installation 
configuration is designed as that - the 'default' that functions in a 
standard-expected installation.  Full disabling of IPv6 was considered 
"atypical default configuration".  This was discussed at length in 
multiple bugs on this nature.


With my Debian Maintainer hat on:

I've discussed this in the #debian-devel channel on IRC, and the 
responses I have are: "IPv6 is always enabled, you should use it in the 
default config", and "if you disable ipv[46] totaly, I don't think one 
can expect the system to work without bugs."


The consensus is identical among multiple users and Debian Developers, 
as the configuration you have chosen *diverges* from the defaults and is 
a "user/admin decision" that the user/admin will have to accept 
consequences for.


As such, this echoes the Ubuntu Server Team's decision but at the Debian 
level, and we're not changing this for Bullseye or any of the other 
supported Debian releases.


You need to configure your deployment scripts to ignore the first 
package installation failure, replace your configuration entirely, and 
*then* `apt install -f` or similar in your deploy script to *replace* 
the configuration.


---

(TL;DR, The default configuration file is made to adapt to *default* 
Debian environments, and it's non-standard to disable ipv[46] entirely 
at a sysctl and similar level, so you can *expect* multiple packages to 
have bugs when these nonstandard setups are being used.  ALTERNATIVELY, 
your deployment script should install nginx first, change the 
configuration, disable IPv6, then reboot.  That's how you *should* do 
things with an autodeploy script).




Thomas Ward

Ubuntu Core Developer (https://launchpad.net/~teward)

Debian Maintainer (for nginx package among others)

On 10/7/22 14:37, Stuart Culligan wrote:


Ok I guess I should have been more clear. This is a debian package 
issue in that the debian package is linking the default site default 
-> /etc/nginx/sites-available/default Which contains 2 listen lines as 
I listed before


listen 80 default_server; listen [::]:80 default_server; After digging 
further into this I discovered it was IPv6 line that was causing the 
issue. listen [::]:80 default_server; We disable IPv6 on our servers. 
I did not run into this on Ubuntu 18.04. It appears there was a lot of 
changes to how debian packaged nginx between the 2 OS releases. With 
these changes there appears to be a lot of changes to the default. I 
suggest not trying to link the default and not attempting to do a 
restart. Just a suggestion though.


Now I am trying to find a way to get passed this issue as we build an 
entire server via debian packages. I can not have a package error out 
in my build process.


On 10/7/2022 11:45 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the nginx-common package:

#1021393: error in package nginx-common_1.18.0-6ubuntu14.2_all.deb for ubuntu 
22.04 with default enabled site.

It has been closed by Thomas Ward.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Thomas 
Ward  by
replying to this email.

Bug#909541: .uuid files cause dpkg: warnings upon attempted package removal

[Alexandre Detiste]

The cruft-ng utility stumble on the
same tiny useless files.

Bug#1016800: libgit2: please package version 1.5.x

[Timo Röhling]

* Pirate Praveen  [2022-10-08 00:31]:

The table at
https://github.com/libgit2/git2go#readme says v34 corresponds to 
libgit2 1.5. They could have skipped v34 to avoid confusion, but they 
have not done it. v35 is libgit2 main/HEAD.


libgit2 git2go
main(will be v35)
1.5 v34
1.3 v33


go.mod also refers to v34, even in the v35 tree, so I will fetch
the v34 tag and make a release with that. Thanks for your help!


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1020500: glibc: flaky autopkgtest on armel: multiple different failures

[Paul Gevers]

Hi Aurelien,

Thanks for your thorough testing.

First off, we have recently changed our setup for armel and armhf 
testing. The real host is the same, but instead of one VM for armel 
where we ran 10 debci workers in parallel, we now have smaller VM's with 
only 4 parallel debci workers per VM. Maybe this changes some of the 
metrics.


On 07-10-2022 20:55, Aurelien Jarno wrote:

https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/23501044/log.gz

--
FAIL: elf/tst-debug1
original exit status 1
Didn't expect signal from child: got `Bus error'
--


I have not been able to reproducible this bug after 1M tests on
amdahl.d.o, an RPI3 (running an arm64 kernel) and a STM32MP1 board
(armhf). Would it be possible to give more details, like any
corresponding dmesg entry to have a better idea of the issue?


I'll try to have a look if I spot this again. The original dmesg is gone 
by now.



https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26218800/log.gz
https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26223226/log.gz
https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26322746/log.gz

--
FAIL: rt/tst-cpuclock2-time64
original exit status 1
live thread clock ffb6e90e resolution 0.1
live thread before sleep => 0.000254800
self thread before sleep => 0.000728320
live thread after sleep => 0.473986200
self thread after sleep => 0.001080840
clock_nanosleep on process slept 97739240 (outside reasonable range)
--


I also can't reproduce this one after 10 tests on amdahl.d.o, an
RPI3 (running an arm64 kernel) and a STM32MP1 board (armhf). According
to upstream it seems that this test is known to fail heavy loaded hosts
as it relies on wall time. Is it the case of the debci workers, do they
have dedicated CPUs to run their tests? Are the armel workers different
than the others?


Yes, and as mentioned above we changed it too. But as said, we ran a lot 
of parallel workers, so they could be heavy loaded. We also have an 
amd64 host that runs lots of parallel workers, and so does s390x, but 
maybe they are a bit better spec-ed than the armel VM was.



Nevertheless the part of the test that relies on wall time has been
removed from upstream so this should be considered as fixed in glibc
2.35 that is now in testing:
https://sourceware.org/git/?p=glibc.git;a=commit;h=f3c6c190388bb445568cfbf190a0942fc3c28553


That's good to hear.

So, lets see the coming time if thing changed (hopefully for the better)..

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016800: libgit2: please package version 1.5.x

[Pirate Praveen]

On വെ, ഒക്ടോ 7 2022 at 05:26:14 വൈകു +02:00:00 
+02:00:00, Timo Röhling  wrote:

* Pirate Praveen  [2022-10-07 20:22]:
I usually use salsa.debian.org/ruby-team/meta (build script from 
there) which runs autopkgtests for all reverse dependencies and 
rebuilds all reverse build dependencies.

Ah, nice, thank you for the tip!

did you mean v34? I can see upstream released 34.0 yesterday 
https://github.com/libgit2/git2go/releases/tag/v34.0.0

uscan fetched
https://github.com/libgit2/git2go/releases/tag/v35.0.0, although it
has not been marked as "Release" in Github


Looking at tags, they indeed have v35.0.0 there. Even v35.0.0 tag still 
has v34 in go.mod.


https://github.com/libgit2/git2go/blob/c1ec21d89caa0cdb0aefd6f6b8f95648418a3543/go.mod

See the value in the go.mod file of the tarball. May be we can report 
an issue upstream.


v34 is safer as if required we can still update to v35 later.

Bug#1016800: libgit2: please package version 1.5.x

[Pirate Praveen]

On വെ, ഒക്ടോ 7 2022 at 05:26:14 വൈകു +02:00:00 
+02:00:00, Timo Röhling  wrote:

* Pirate Praveen  [2022-10-07 20:22]:
I usually use salsa.debian.org/ruby-team/meta (build script from 
there) which runs autopkgtests for all reverse dependencies and 
rebuilds all reverse build dependencies.

Ah, nice, thank you for the tip!

did you mean v34? I can see upstream released 34.0 yesterday 
https://github.com/libgit2/git2go/releases/tag/v34.0.0

uscan fetched
https://github.com/libgit2/git2go/releases/tag/v35.0.0, although it
has not been marked as "Release" in Github


The table at
https://github.com/libgit2/git2go#readme says v34 corresponds to 
libgit2 1.5. They could have skipped v34 to avoid confusion, but they 
have not done it. v35 is libgit2 main/HEAD.


libgit2 git2go
main(will be v35)
1.5 v34
1.3 v33

Bug#1021406: nmu: * against debhelper 13.9.1

[Marc Haber]

On Fri, Oct 07, 2022 at 06:44:53PM +0200, Adam Borowski wrote:
> nmu sudo 1.9.11p3-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"

Sudo will do an upload this weekend, so you don't need to NMU. If it's
a fully automated process on your side, go ahead, but don't waste any of
your time.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1020500: glibc: flaky autopkgtest on armel: multiple different failures

[Aurelien Jarno]

Hi,

On 2022-09-22 11:19, Paul Gevers wrote:
> Source: glibc
> Version: 2.33-7
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: flaky
> 
> Dear maintainer(s),
> 
> I looked at the results of the autopkgtest of your package. I noticed that
> it regularly fails on armel while testing if other packages can migrate. A
> retry (or retry of retry) passes, so it doesn't seem related to those
> packages.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests. I now looked at it because both gcc-11 and gcc-12 showed up as
> regressing the glibc autopkgtest.
> 
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.

Please find my answer (and questions for each test below).


> https://ci.debian.net/packages/g/glibc/testing/armel/
> 
> https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/23501044/log.gz
> 
> --
> FAIL: elf/tst-debug1
> original exit status 1
> Didn't expect signal from child: got `Bus error'
> --

I have not been able to reproducible this bug after 1M tests on
amdahl.d.o, an RPI3 (running an arm64 kernel) and a STM32MP1 board
(armhf). Would it be possible to give more details, like any
corresponding dmesg entry to have a better idea of the issue?


> https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26322757/log.gz
> 
> nptl/tst-rwlock9
> [...]
> Timed out: killed the child process
> Termination time: 2022-09-22T07:41:04.502168635
> Last write to standard output: 2022-09-22T07:28:34.991525943

I have been able to reproduce that one, with a probability of around
1/2500 on average. I have tracked it down to this bug:

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

It appears to be fixed by this patch that didn't seem to attract a lot
of interest:
https://sourceware.org/pipermail/libc-alpha/2021-September/131546.html

I just reviewed and tested it, so let's see if it get merged soon:
https://sourceware.org/pipermail/libc-alpha/2021-September/131546.html


> https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26218800/log.gz
> https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26223226/log.gz
> https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26322746/log.gz
> 
> --
> FAIL: rt/tst-cpuclock2-time64
> original exit status 1
> live thread clock ffb6e90e resolution 0.1
> live thread before sleep => 0.000254800
> self thread before sleep => 0.000728320
> live thread after sleep => 0.473986200
> self thread after sleep => 0.001080840
> clock_nanosleep on process slept 97739240 (outside reasonable range)
> --

I also can't reproduce this one after 10 tests on amdahl.d.o, an
RPI3 (running an arm64 kernel) and a STM32MP1 board (armhf). According
to upstream it seems that this test is known to fail heavy loaded hosts
as it relies on wall time. Is it the case of the debci workers, do they
have dedicated CPUs to run their tests? Are the armel workers different
than the others?

Nevertheless the part of the test that relies on wall time has been
removed from upstream so this should be considered as fixed in glibc
2.35 that is now in testing:
https://sourceware.org/git/?p=glibc.git;a=commit;h=f3c6c190388bb445568cfbf190a0942fc3c28553

 
> https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/25779292/log.gz
> 
> /bin/bash testdata/gen-XT5.sh > 
> /tmp/autopkgtest-lxc.pjd0aipn/downtmp/build.Ui1/src/build-tree/armel-libc/timezone/testdata/XT5.tmp
> /bin/bash: line 1: 
> /tmp/autopkgtest-lxc.pjd0aipn/downtmp/build.Ui1/src/build-tree/armel-libc/timezone/testdata/XT5.tmp:
> No such file or directory

This has been fixed in glibc 2.35 that is now in testing:
https://sourceware.org/git/?p=glibc.git;a=commit;h=62db87ab24f9ca483f97f5e52ea92445f6a63c6f

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1021408: golang-github-anacrolix-missinggo: flaky autopkgtest on armhf: FAIL: TestAsCompletedDelayed

[Aurelien Jarno]

Source: golang-github-anacrolix-missinggo
Version: 2.1.0-6
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed
that it regularly fails on armhf while testing if other packages can
migrate. A retry (or retry of retry) passes, so it doesn't seem related
to those packages.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests. I now looked at it because both glibc showed up as regressing the
golang-github-anacrolix-missinggo autopkgtest.

Here are a few successful runs:
https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26710743/log.gz
https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853370/log.gz
https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853490/log.gz

Here are a few failed runs:
https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853369/log.gz
https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853371/log.gz
https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-anacrolix-missinggo/26853484/log.gz

Regards
Aurelien

Bug#1019428: Please, fix sudo to cope with libgcrypt changes (apparently)

[Marc Haber]

Control: tags -1 - unreproducible
thanks

On Mon, Sep 12, 2022 at 03:16:56PM +0200, Marc Haber wrote:
> For the time being, I don't see anything the sudo maintainers can do
> other than keeping eyes open and monitor this bug report for news.

I have applied the Upstream patch that Todd delivered.

Can you try building from
https://salsa.debian.org/sudo-team/sudo/-/tree/debian-bug-1019428 and
check whether the issue persists?

Let me know if an experimental upload would help.

Greetings
Marc

Bug#1021407: python-pretend: please drop pypy-pretend to support python2.7 removal

[Paul Gevers]

Source: python-pretend
Version: 1.0.9-2
Severity: serious
Justification: rt

Dear maintainers,

If I didn't make a mistake, python-pretend is keeping pypy in the key
package set because it (Build-)Depends on it. Again, if I didn't make a
mistake, there are no reverse Build-Depends or Depends anymore of
pypy-pretend (except python-packaging, which isn't built anymore), so I 
think the package can just be dropped. That would be another step in the 
python2.7 removal transition.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021393: closed by Thomas Ward ()

[Stuart Culligan]

Ok I guess I should have been more clear. This is a debian package issue 
in that the debian package is linking the default site default -> 
/etc/nginx/sites-available/default Which contains 2 listen lines as I 
listed before


listen 80 default_server; listen [::]:80 default_server; After digging 
further into this I discovered it was IPv6 line that was causing the 
issue. listen [::]:80 default_server; We disable IPv6 on our servers. I 
did not run into this on Ubuntu 18.04. It appears there was a lot of 
changes to how debian packaged nginx between the 2 OS releases. With 
these changes there appears to be a lot of changes to the default. I 
suggest not trying to link the default and not attempting to do a 
restart. Just a suggestion though.


Now I am trying to find a way to get passed this issue as we build an 
entire server via debian packages. I can not have a package error out in 
my build process.


On 10/7/2022 11:45 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the nginx-common package:

#1021393: error in package nginx-common_1.18.0-6ubuntu14.2_all.deb for ubuntu 
22.04 with default enabled site.

It has been closed by Thomas Ward.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Thomas 
Ward  by
replying to this email.

Bug#1009329: New upstream version 2.7.1 - Please package

[Jérôme Charaoui]

Control: tags -1 +patch

Dear maintainer,

Just a quick note that a merge request has been submitted on Salsa to 
build a new version of this package.


https://salsa.debian.org/debian/keepassxc/-/merge_requests/9

Please review it at your convenience.

Thank you!

-- Jerome

Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)

[Nicolas Schier]

Enable UTF-8 compatible processing of input and output to correctly output e.g.
timestamps containing non-latin letters (cp. [1]).

[1]: https://bugs.debian.org/848578

Signed-off-by: Nicolas Schier 
---
 ts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ts b/ts
index af23cf7..fbd5b1a 100755
--- a/ts
+++ b/ts
@@ -54,6 +54,11 @@ use strict;
 use POSIX q{strftime};
 no warnings 'utf8';
 
+# Ensure that text read or printed are converted from/to UTF-8.
+binmode STDIN, ':utf8';
+binmode STDOUT, ':utf8';
+binmode STDERR, ':utf8';
+
 $|=1;
 
 my $rel=0;
-- 
2.30.2


-- 
epost|xmpp: nico...@fjasle.eu  irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature

Bug#998105: backintime-qt: Fails to access the keyring with python3-keyring 23.2.0-1

[BiT]

> DEBUG: [common/tools.py:823 keyringSupported] No appropriate keyring found.
>'keyring.backends.chainer' can't be used with BackInTime
> ...
> Two Conclusion:
> 1) Backintime fails to access the keyring when keyring.backends.chainer is in 
> use.

Correct.

The keyring.backends.chainer.chainerBackend is not yet supported in BiT
and perhaps never will be because it iterates over all installed backends
and picks the "best one" by some internal logic.

The chosen backend my not be the one where the users saves the credentials 
anyhow.

So a decent fix for this would be to add a settings GUI to BiT so that
the user can choose which backend is the right one (containing the credentials).

I have documented future implementation options in this issue comment:

https://github.com/bit-team/backintime/issues/1321#issuecomment-1271689827


> With python3-keyring 22.0.1-1 backintime succeeds to read the ssh password
> However logs now say:
>   DEBUG: [common/tools.py:823 keyringSupported] No appropriate keyring found.
>  'keyring.backends.SecretService' can't be used with BackInTime
> ...
> Two Conclusion:
> ...
> 2) Backintime's test for keyring back ends does not work properly.
> It does not recognize a back end as functional it does work with later on.

Correct. I think this has the same reason as the bug #1321 linked in above 
issue.

I am preparing a fix for this bug (but NOT adding support for the 
ChainerBackend!)
and hopefully attach a patch for this if the package maintainer really wants
to backport this to BiT v1.2.1 (with no support from the BiT team I guess
since we are preparing a new stabilized release 1.3.x where many bugs are fixed
but no new features are added (therefore "stabilize" ;-)

So I'd prefer if the package maintainer waited for stabilized BiT version
and packages the new BiT version we are working on.

Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'

[Michael Tokarev]

07.10.2022 18:53, Simon McVittie wrote:

On Fri, 07 Oct 2022 at 18:08:41 +0300, Michael Tokarev wrote:

In debian samba package, there's a strict versioned dependency of libldb2
for samba package - actually samba-dsdb-modules - the only package which
actually *uses* libldb.


I'm not sure that's completely accurate? ldb-tools, python3-ldb,
python3-samba, samba, samba-libs, etc. also depend on libldb2 (perhaps
with more -Wl,--as-needed they wouldn't, I haven't looked at whether they
actually reference symbols from libldb2).


What I mean is that most of these only use a few common entry points of
libldb which does not change much and for which symvers mechanism provides
good results. Except of particular situation with this very version at hand.


Outside the samba source package, several binaries from src:sssd also
have dependencies on libldb2, although again I haven't checked whether
they actually reference individual symbols or whether they just have an
unnecessary DT_NEEDED entry.


sssd is one more package which uses libldb "heavily".

The problem here and with samba-dsdb-modules is that both provides *plugins*
for libldb, and we don't have a mechanism similar to symvers for plugins.


But it looks like other samba packages does have libldb2 dependency.
It looks like I need to take a look at how libldb2 is used by samba-libs,
maybe some libs should be moved between packages.





The reason I like using debian/shlibs.local for this, instead of
explicitly writing out "libldb2 (= ${binary:Version})" in d/control,
is that it's automatic: every time one of your binary packages picks up
a dependency on libldb2 from ${shlibs:Depends}, it will *automatically*
be a strictly versioned dependency. Even if you've split libraries between
binary packages in a way that didn't really match what you intended (like
if you didn't intend for samba-libs to depend on libldb2 at all), the
failure mode is that there's a strict dependency (possibly unnecessary,
but never wrong) rather than a loosely-versioned dependency (which can
result in making mismatches possible).


Only particular packages needs strict deps, there's no need to depend
on exact version for other packages.


I make as many mistakes as anyone else, so I like to use tools that will
prevent unintended situations from happening :-)


the dependency is

   libldb2 (<< 2:2.2.4~), libldb2 (>= 2:2.2.3-2~deb11u2~)

(so it conflicts even with next minor version of libldb2)


If both the packages are Architecture: any, then I don't think there's
a particularly good reason to use this version-range style with (>=)
and (<<) - you might as well just eliminate all flexibility by using
(= ${binary:Version}), since libldb2:amd64 (= x) is going to be available
if and only if samba-dsdb-modules:amd64 (= x) is also available. After all,
they both came out from the same sbuild run and got installed in the
archive by the same .changes file...

Or if you're doing tricky things with different versions for different
binary packages, as with libldb2, it seems better to represent that as
an exact dependency on "the version of libldb2 that was produced by this
exact build of src:samba".


This is only needed for samba-dsdb-modules (and in parts for sssd - it
uses only a subset of libldb plugins functionality which seems to be
mroe or less stable).

And once again, I just moved libldb to build from samba source, before
it used its own source package.


On Fri, 07 Oct 2022 at 18:19:34 +0300, Michael Tokarev wrote:

With debian bullseye version of samba things are even more interesting.
This is because ldb-2.2.4 has never ever been released to begin with.
It was a bugfix within 4.13 series of samba - backported to 4.13 samba
long after 4.13 has been end-of-lined.  The actual symbols in ldb are
present in 4.16 (ldb 2.5.x), but not 2.2.4 version.

And actually it brings a new question.  When we upgrade a library in a
stable debian release, and this upgrade brings new symbol version, but
already existing version of this library in testing does not have this
version.. what do do?  Should we omit the version bump in the stable
series?


This is quite a weird situation to be in, and I would tend to say that
upstreams that track their public ABIs this carefully (or their downstream
maintainers, if it was Debian that did this backport) should generally
not be backporting new ABI to stable-branches at all. Several of the
upstreams I follow have a fairly strict policy of stable-branches not
adding new ABI *at all*, not even for bug fixes. However, I realise that's
not necessarily always possible.


Existing ABI in the library did not let a significant security issue to
be fixed, - new symbol had to be introduced (actually several), and samba
switched to use these new symbols. And those new symbols has been backported
to old samba version by the upstream. Once again, in bullseye, libldb is
built by its own source package.

Maybe we did it wrong and we should not introduced 2.2.4 version (it is

Bug#1019610: ruby-ahoy-email: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: cannot load such file -- net/smtp (LoadError)

[Antonio Terceiro]

Hi,

On Fri, Oct 07, 2022 at 01:50:56AM +0300, Adrian Bunk wrote:
> On Mon, Sep 12, 2022 at 08:24:43PM -0300, Antonio Terceiro wrote:
> > Source: ruby-ahoy-email
> > Version: 1.1.1-2
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: debian-r...@lists.debian.org
> > Usertags: ruby3.1
> > 
> > Hi,
> > 
> > We are about to start the ruby3.1 transition in unstable. While trying to
> > rebuild ruby-ahoy-email with ruby3.1 enabled, the build failed.
> > 
> > Relevant part of the build log (hopefully):
> > > /usr/share/rubygems-integration/all/gems/activesupport-6.1.6.1/lib/active_support/dependencies.rb:332:in
> > >  `require': cannot load such file -- net/smtp (LoadError)
> 
> Do you have any ides where this dependency is required and why it isn't found?

$ dpkg -S net/smtp.rb
libruby3.0:amd64: /usr/lib/ruby/3.0.0/net/smtp.rb
libruby3.1:amd64: /usr/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.1/lib/net/smtp.rb

In ruby3.0, net/smtp was part of the standard library, and in ruby3.1,
it's now a "default gem", which is more or less a third-party library
that happens to be shipped together with the standard library.

And it seems that the test suite for this package loads bundler. bundler
prevents any library that is not part of the standard library and is not
explicitly declared the Gemfile from being loaded, therefore it looks
like the library is not installed.

But nothing in ruby-ahoy-email codebase uses net/smtp explicitly, so
this is a bit weird. Our version is also quite outated wrt upstream, so
my first attempt would be to just update the latest upstream (there are
no reverse dependencies in the archive).


signature.asc
Description: PGP signature

Bug#1021402: reproducible: Please force merged-/usr for build2

[Luca Boccassi]

On Fri, 7 Oct 2022 at 16:21, Simon McVittie  wrote:
>
> Package: jenkins.debian.org
> Severity: normal
> X-Debbugs-Cc: usrme...@packages.debian.org, debian...@lists.debian.org
>
> The reproducible builds infrastructure tries to vary the merged-/usr
> status of the build system, like this:
>
> - base tarball: explicitly disable merged-/usr
> - build1: leave merged-/usr disabled
> - build2: pass "--extrapackages usrmerge" to pbuilder, to convert the
>   system to merged-/usr
>
> This has been very useful for detecting bugs of the same class as
> .
>
> However, now that new chroots are merged-/usr by default, I don't think
> this is working as intended. Disabling merged-/usr during base chroot
> creation now creates a flag file /etc/unsupported-skip-usrmerge-conversion
> representing "please don't merge /usr, contrary to the default", and
> installing the usrmerge package is not sufficient to undo the effect of
> that flag file.
>
> I believe the procedure to convert a non-merged-/usr QA chroot to
> merged-/usr is now something like this:
>
> 1. ensure the usrmerge package is installed
> 2. rm /etc/unsupported-skip-usrmerge-conversion
> 3. dpkg-reconfigure usrmerge
>
> Please do that for reproducible builds in build2, reinstating the
> previous setup where build1 is not merged-/usr but build2 is. I think
> implementing this on reproducible builds will require adding a pbuilder
> hook that does steps 2 and 3?

Wouldn't it be sufficient to create the build2 chroot as merged-usr
from the start?

Kind regards,
Luca Boccassi

Bug#1021406: nmu: * against debhelper 13.9.1

[Adam Borowski]

Package: release.debian.org
Severity: normal

Hi!
The following packages in unstable still have binaries built against
debhelper 13.9, which adds spurious dependencies on "systemd |
systemd-tmpfiles".  This causes at least the following problems:
 * forced init switch with !systemd (with an obscure workaround)
 * makes small containers fatter
 * dependencies will unexpectedly change on a rebuild (incl. security)
The relevant bug is #1017441 -- but it'd be probably a waste of your time
to read it now that a resolution has been found; all we need is to rebuild
the stragglers.

I've verified "at home" that all of these currently build successfully on
amd64.

nmu connman 1.41-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu cyrus-imapd 3.6.0~beta2-5 . ANY . unstable . -m "Rebuild with debhelper 
13.9.1"
nmu drbd-utils 9.21.4-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu etbemon 1.3.6-3 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu json2file-go 1.15 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu krb5 1.20-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu libpod 3.4.7+ds1-3 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu lvm2 2.03.16-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu mpd 0.23.9-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu myproxy 6.2.14-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu nagios-nrpe 4.1.0-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu nsd 4.6.0-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu open-vm-tools 2:12.1.0-1 . ANY . unstable . -m "Rebuild with debhelper 
13.9.1"
nmu opendkim 2.11.0~beta2-7 . ANY . unstable . -m "Rebuild with debhelper 
13.9.1"
nmu opendmarc 1.4.2-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu openvpn 2.6.0~git20220818-1 . ANY . unstable . -m "Rebuild with debhelper 
13.9.1"
nmu php8.1 8.1.7-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu pushpin 1.35.0-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu rpcbind 1.2.6-6 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu screen 4.9.0-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu sudo 1.9.11p3-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu tirex 0.7.0-2 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"
nmu xrootd 5.5.0-1 . ANY . unstable . -m "Rebuild with debhelper 13.9.1"


Meow!

Bug#1004112:

[Vadim Zeitlin]

 Just for the record, this bug affects libunwind-14-dev too and is really,
really annoying as you basically can't use clang and GStreamer on the same
system. It would be really great if this could be fixed, especially if the
fix is really as simple as in the patch above.

 Thanks in advance,
VZ

pgpjV4kNx1RKK.pgp
Description: PGP signature

Bug#1021403: [parted] /usr/sbin/parted: invalid token: swap

[Colin Watson]

Control: severity -1 normal
Control: fixed -1 3.5-1

On Fri, Oct 07, 2022 at 05:29:14PM +0200, Jean-Marc LACROIX wrote:
> Severity: critical

"makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems where
you install the package"

A difficulty with using the CLI, or even a missing feature in the CLI,
doesn't fall into any of these categories.

> According documentation available in man it seems possible to create one
> partition of type "swap" by using "set" option on command line.
> 
> After many tests done with Linux "parted" command and Ansible module
> "parted", it seems that it is not possible to set one logical partition as a
> swap partition with the flag option available into parted tool.
> 
> My disk uses for test has following partitions...
> 
> ansible@thinkpad-410:~$ sudo fdisk -l /dev/sda
> Disque /dev/sda : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
> Modèle de disque : HGST HTS721010A9
> Unités : secteur de 1 × 512 = 512 octets
> Taille de secteur (logique / physique) : 512 octets / 4096 octets
> taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
> Type d'étiquette de disque : dos
> Identifiant de disque : 0x483880d2
> 
> Périphérique AmorçageDébutFin   Secteurs Taille Id Type
> /dev/sda1*2048   48828415   48826368  23,3G 83 Linux
> /dev/sda2 48830462 1953523711 1904693250 908,2G  5 Étendue
> /dev/sda5 48830464   68360191   19529728   9,3G 8e LVM Linux
> /dev/sda6 68362240   703610871998848   976M 82 partition
> d'échange Linux / Solaris

This says that it's already a swap partition, so I'm not sure why you
need to set it as one.  Can you explain further?

(On an MBR partition table like this, all that setting the "swap" flag
does is set the partition type to 0x82.)

> /dev/sda7 70363136   742666233903488   1,9G 8e LVM Linux
> /dev/sda8 74268672  279068671  20480  97,7G 8e LVM Linux
> 
> and when i try to set one partition with swap, then ...
> 
> ansible@thinkpad-410:~$ sudo  /usr/sbin/parted -s -m -a optimal /dev/sda --
> unit KiB set 6 swap on
> /usr/sbin/parted: invalid token: swap
> 
> I have also tried, but without success...
> 
> ansible@thinkpad-410:~$ sudo  /usr/sbin/parted -s -m -a optimal /dev/sda --
> unit KiB set 6 swap on set 6 lvm off
> /usr/sbin/parted: invalid token: swap

This was fixed in parted 3.4.64.  From the NEWS file:

  Add use of the swap partition flag to msdos disk labeled disks.

But since it's already of the correct type, maybe you can just skip that
bit on older versions of parted?

(Or, if your automation is building the entire system from scratch, then
another option might be to use GPT instead of MBR.)

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1004589: GNUnet service doesn't start correctly

[Sven Grewe]

The GNUnet service still doesn't start correctly in version 0.17.6-1.

Bug#1021404: qt6-base: FTBFS on hppa - Unknown Q_PROCESSOR_xxx macro

[John David Anglin]

Source: qt6-base
Version: 6.3.1+dfsg-10
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

The build fails here:

[357/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o -c 
/<>/src/corelib/text/qregularexpression.cpp
[358/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o -c 
/<>/src/corelib/io/qfilesystemwatcher.cpp
[359/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 

Bug#1021405: ITP: starjava-tfcat -- Time-Frequency Radio Catalogues parser

[Ole Streicher]

Package: wnpp
Owner: Ole Streicher 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org, 
debian-j...@lists.debian.org


 * Package name: starjava-tfcat
   Version : 1.0+
   Upstream Author : Mark Taylor
 * URL : https://github.com/Starlink/starjava/tree/master/tfcat
 * License : LGPL-3+
   Programming Lang: Java
   Description : Time-Frequency Radio Catalogues parser

This package contains a parser and validator for the Time-Frequency Radio
Catalogues standard, defined at https://doi.org/10.25935/6068-8528.
It currently implements v1.0 of the standard.

The package will be maintained by the Debian Astro team. It is a new
dependency of the "topcat" and "ttools" (STILTS) packages.

A git repository will be created at

https://salsa.debian.org/debian-astro-team/starjava-tfcat

Best regards

Ole

Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'

[Simon McVittie]

On Fri, 07 Oct 2022 at 18:08:41 +0300, Michael Tokarev wrote:
> In debian samba package, there's a strict versioned dependency of libldb2
> for samba package - actually samba-dsdb-modules - the only package which
> actually *uses* libldb.

I'm not sure that's completely accurate? ldb-tools, python3-ldb,
python3-samba, samba, samba-libs, etc. also depend on libldb2 (perhaps
with more -Wl,--as-needed they wouldn't, I haven't looked at whether they
actually reference symbols from libldb2).

Outside the samba source package, several binaries from src:sssd also
have dependencies on libldb2, although again I haven't checked whether
they actually reference individual symbols or whether they just have an
unnecessary DT_NEEDED entry.

> But it looks like other samba packages does have libldb2 dependency.
> It looks like I need to take a look at how libldb2 is used by samba-libs,
> maybe some libs should be moved between packages.

The reason I like using debian/shlibs.local for this, instead of
explicitly writing out "libldb2 (= ${binary:Version})" in d/control,
is that it's automatic: every time one of your binary packages picks up
a dependency on libldb2 from ${shlibs:Depends}, it will *automatically*
be a strictly versioned dependency. Even if you've split libraries between
binary packages in a way that didn't really match what you intended (like
if you didn't intend for samba-libs to depend on libldb2 at all), the
failure mode is that there's a strict dependency (possibly unnecessary,
but never wrong) rather than a loosely-versioned dependency (which can
result in making mismatches possible).

I make as many mistakes as anyone else, so I like to use tools that will
prevent unintended situations from happening :-)

> the dependency is
> 
>   libldb2 (<< 2:2.2.4~), libldb2 (>= 2:2.2.3-2~deb11u2~)
> 
> (so it conflicts even with next minor version of libldb2)

If both the packages are Architecture: any, then I don't think there's
a particularly good reason to use this version-range style with (>=)
and (<<) - you might as well just eliminate all flexibility by using
(= ${binary:Version}), since libldb2:amd64 (= x) is going to be available
if and only if samba-dsdb-modules:amd64 (= x) is also available. After all,
they both came out from the same sbuild run and got installed in the
archive by the same .changes file...

Or if you're doing tricky things with different versions for different
binary packages, as with libldb2, it seems better to represent that as
an exact dependency on "the version of libldb2 that was produced by this
exact build of src:samba".

I think the only times it's helpful to use (>=), (<<) is when you're doing
a dependency between Architecture: any and Architecture: all packages
(in which case you need to allow a bit of fuzz in order to accomodate
binNMUs), or when you're doing a dependency between different source
packages (for instance different GNOME modules wanting to be at a matching
GNOME major version, but willing to tolerate smaller differences between
different point releases).

One place where (= ${binary:Version}) can be a problem is if you have a
transitional package: for those, it's better to use (>= ${binary:Version})
with no upper bound, so that an old transitional package can remain
installed if necessary, even after it has been dropped from the latest
version of its source package.

On Fri, 07 Oct 2022 at 18:19:34 +0300, Michael Tokarev wrote:
> With debian bullseye version of samba things are even more interesting.
> This is because ldb-2.2.4 has never ever been released to begin with.
> It was a bugfix within 4.13 series of samba - backported to 4.13 samba
> long after 4.13 has been end-of-lined.  The actual symbols in ldb are
> present in 4.16 (ldb 2.5.x), but not 2.2.4 version.
> 
> And actually it brings a new question.  When we upgrade a library in a
> stable debian release, and this upgrade brings new symbol version, but
> already existing version of this library in testing does not have this
> version.. what do do?  Should we omit the version bump in the stable
> series?

This is quite a weird situation to be in, and I would tend to say that
upstreams that track their public ABIs this carefully (or their downstream
maintainers, if it was Debian that did this backport) should generally
not be backporting new ABI to stable-branches at all. Several of the
upstreams I follow have a fairly strict policy of stable-branches not
adding new ABI *at all*, not even for bug fixes. However, I realise that's
not necessarily always possible.

If samba upstream are effectively treating some new symbols as being
essentially private to the source package, then the other thing you
could do is to flag them as such in debian/*.symbols. This is a bit
annoying to do: the best way I've found is to have a .symbols.in file,
and preprocess it to create the actual symbols file to be consumed by
dpkg-shlibdeps and dpkg-makeshlibs.

For instance, take a look at debian/libdbus-1-3.symbols.in in 

Bug#1021403: [parted] /usr/sbin/parted: invalid token: swap

[Jean-Marc LACROIX]

Package: parted
Version: 3.4-1
Severity: critical

Dear maintainers,

According documentation available in man it seems possible to create one 
partition of type "swap" by using "set" option on command line.


After many tests done with Linux "parted" command and Ansible module 
"parted", it seems that it is not possible to set one logical partition 
as a swap partition with the flag option available into parted tool.


My disk uses for test has following partitions...

ansible@thinkpad-410:~$ sudo fdisk -l /dev/sda
Disque /dev/sda : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : HGST HTS721010A9
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x483880d2

Périphérique AmorçageDébutFin   Secteurs Taille Id Type
/dev/sda1*2048   48828415   48826368  23,3G 83 Linux
/dev/sda2 48830462 1953523711 1904693250 908,2G  5 Étendue
/dev/sda5 48830464   68360191   19529728   9,3G 8e LVM Linux
/dev/sda6 68362240   703610871998848   976M 82 partition 
d'échange Linux / Solaris

/dev/sda7 70363136   742666233903488   1,9G 8e LVM Linux
/dev/sda8 74268672  279068671  20480  97,7G 8e LVM Linux

and when i try to set one partition with swap, then ...

ansible@thinkpad-410:~$ sudo  /usr/sbin/parted -s -m -a optimal /dev/sda 
-- unit KiB set 6 swap on

/usr/sbin/parted: invalid token: swap

I have also tried, but without success...

ansible@thinkpad-410:~$ sudo  /usr/sbin/parted -s -m -a optimal /dev/sda 
-- unit KiB set 6 swap on set 6 lvm off

/usr/sbin/parted: invalid token: swap


Of course, it is possible to use fdisk , but my challenge is to use only 
some Ansible modules (if possible !)


Thanks in advance for your help

--
-- mailto : jeanmarc.lacr...@free.fr   --

Bug#1016800: libgit2: please package version 1.5.x

[Timo Röhling]

* Pirate Praveen  [2022-10-07 20:22]:
I usually use salsa.debian.org/ruby-team/meta (build script from 
there) which runs autopkgtests for all reverse dependencies and 
rebuilds all reverse build dependencies.

Ah, nice, thank you for the tip!

did you mean v34? I can see upstream released 34.0 yesterday 
https://github.com/libgit2/git2go/releases/tag/v34.0.0

uscan fetched
https://github.com/libgit2/git2go/releases/tag/v35.0.0, although it
has not been marked as "Release" in Github


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1021402: reproducible: Please force merged-/usr for build2

[Simon McVittie]

Package: jenkins.debian.org
Severity: normal
X-Debbugs-Cc: usrme...@packages.debian.org, debian...@lists.debian.org

The reproducible builds infrastructure tries to vary the merged-/usr
status of the build system, like this:

- base tarball: explicitly disable merged-/usr
- build1: leave merged-/usr disabled
- build2: pass "--extrapackages usrmerge" to pbuilder, to convert the
  system to merged-/usr

This has been very useful for detecting bugs of the same class as
.

However, now that new chroots are merged-/usr by default, I don't think
this is working as intended. Disabling merged-/usr during base chroot
creation now creates a flag file /etc/unsupported-skip-usrmerge-conversion
representing "please don't merge /usr, contrary to the default", and
installing the usrmerge package is not sufficient to undo the effect of
that flag file.

I believe the procedure to convert a non-merged-/usr QA chroot to
merged-/usr is now something like this:

1. ensure the usrmerge package is installed
2. rm /etc/unsupported-skip-usrmerge-conversion
3. dpkg-reconfigure usrmerge

Please do that for reproducible builds in build2, reinstating the
previous setup where build1 is not merged-/usr but build2 is. I think
implementing this on reproducible builds will require adding a pbuilder
hook that does steps 2 and 3?

Thanks,
smcv

Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'

[Michael Tokarev]

07.10.2022 18:08, Michael Tokarev wrote:
...

Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
should have versioned Breaks against dependent packages that use the old
symver. It looks as though only the samba and maybe sssd source packages
will be affected by this.


I talked about this with upstream samba. It is their decision to break old
stuff like this, by dropping intermediate library versions without actually
changing any functions/symbols. I don't know why this is done like that,
from my PoV it is plain wrong.


With debian bullseye version of samba things are even more interesting.
This is because ldb-2.2.4 has never ever been released to begin with.
It was a bugfix within 4.13 series of samba - backported to 4.13 samba
long after 4.13 has been end-of-lined.  The actual symbols in ldb are
present in 4.16 (ldb 2.5.x), but not 2.2.4 version.

And actually it brings a new question.  When we upgrade a library in a
stable debian release, and this upgrade brings new symbol version, but
already existing version of this library in testing does not have this
version.. what do do?  Should we omit the version bump in the stable
series?

/mjt

Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'

[Michael Tokarev]

Control: tag -1 + confirmed
07.10.2022 11:38, Simon McVittie wrote:
...

# smbclient --help
smbclient: /usr/lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found 
(required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)

Workaround: also upgrade samba-libs to the version from testing, or fully
upgrade to testing.

Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
should have versioned Breaks against dependent packages that use the old
symver. It looks as though only the samba and maybe sssd source packages
will be affected by this.


I talked about this with upstream samba. It is their decision to break old
stuff like this, by dropping intermediate library versions without actually
changing any functions/symbols. I don't know why this is done like that,
from my PoV it is plain wrong.

When I packaged 4.17 version (currently in experimental), I created a patch
which adds missing intermediate versions (added during maintenance of 4.16
series) to 4.17, but later on dropped it. It will be the same with 4.16->
4.17 upgrade.  See
https://salsa.debian.org/samba-team/samba/-/commit/363ec9c9cf107536b94bfd0d5bd623644413b165

In debian samba package, there's a strict versioned dependency of libldb2
for samba package - actually samba-dsdb-modules - the only package which
actually *uses* libldb.  For a bullseye version of samba-dsdb-modules
package, the dependency is

  libldb2 (<< 2:2.2.4~), libldb2 (>= 2:2.2.3-2~deb11u2~)

(so it conflicts even with next minor version of libldb2).

But it looks like other samba packages does have libldb2 dependency.
It looks like I need to take a look at how libldb2 is used by samba-libs,
maybe some libs should be moved between packages.


Also, when a single source package builds multiple libraries, it's usually
a lot more robust if the dependencies between those libraries are strict
(libfoo Depends: libbar (= ${binary:Version}) so that users are forced
to upgrade either everything or nothing from that source package. This


The only real user of libldb2 in samba is samba-dsdb-modules. And exactly
due to this reason I switched from the ugly "between" version like I
demonstrated above to exact version. libldb2 builds from samba package
since bookworm version (4.16), in bullseye libldb was in its own package.


is because the upstream developer will never have tested with mismatched
versions, and code in the same source package often uses private/internal
interfaces that are not formally part of the API/ABI, or relies on
internal implementation details that might change in a newer version.


I weren't aware that libldb2 is linked to from samba-libs. Now I do, and
ofc I'll take care of this. Either by adding countless patches adding
missing versions which upstream refuses to add for some unknown reason
like I initially did for 4.17 version, or by rearranging libraries into
different packages so that libldb isn't used by samba-libs, or maybe
upstream will do their part and add those versions itself, I dunno.

Thanks,

/mjt

Bug#1021320: isc-dhcp: diff for NMU version 4.4.3-2.1

[Salvatore Bonaccorso]

Dear Santiago,

Thanks for you prompt reply!

On Fri, Oct 07, 2022 at 04:50:02PM +0200, Santiago Ruano Rincón wrote:
> Dear Salvatore,
> 
> El 06/10/22 a las 22:57, Salvatore Bonaccorso escribió:
> > Control: tags 1021320 + patch
> > Control: tags 1021320 + pending
> > 
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for isc-dhcp (versioned as 4.4.3-2.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I
> > should delay it longer.
> > 
> > This follows for updates already done in bullseye, so we have not a
> > regression. Cf. DSA 5251-1.
> > 
> > Pushed as well to
> > 
> > https://salsa.debian.org/debian/isc-dhcp/-/tree/security-2022-10-05
> > https://salsa.debian.org/debian/isc-dhcp/-/tags/debian%2F4.4.3-2.1
> > 
> > (creating a proper merge request does not seem possible for the
> > project), but the tag can be merged into master branch once/if the NMU
> > is accepted in the archive.
> > 
> 
> Sorry. It should be fixed now (this project was moved to debian/ from
> the former maintainers' namespace).

Thanks, I have created the respective merge request as well:

https://salsa.debian.org/debian/isc-dhcp/-/merge_requests/2

> > Let me as well know if you would be fine with the NMU and have it
> > moved faster.
> 
> >
> Please, upload as soon as possible.

Perfect, thanks. So I have rescheduled it to enter the archive
earlier.

Regards,
Salvatore

Bug#1016800: libgit2: please package version 1.5.x

[Pirate Praveen]

On വെ, ഒക്ടോ 7 2022 at 01:29:50 വൈകു +02:00:00 
+02:00:00, Timo Röhling  wrote:

Hi,

* Pirate Praveen  [2022-10-03 12:06]:

Thanks for working on libgit2 update.

Next time, remember to file bugs against all reverse (build) 
dependencies. There was no bug filed against 
golang-github-libgit2-git2go (may be others too).


reverse-depends src:libgit2
reverse-depends -b src:libgit2

These two commands can get you the list of reverse (build) 
dependencies.

I'm sorry I missed that package; I relied on the transition tracker,
which doesn't really work that well for static linkage.



I usually use salsa.debian.org/ruby-team/meta (build script from there) 
which runs autopkgtests for all reverse dependencies and rebuilds all 
reverse build dependencies.



I'm not very proficient with Go and its packaging policies, but I
updated golang-github-libgti2-git2go locally to v35, which is
pretty straight-forward, and it builds and passes autopkgtests.


did you mean v34? I can see upstream released 34.0 yesterday 
https://github.com/libgit2/git2go/releases/tag/v34.0.0


Just verify the binary package name matches the import path in go.mod.

You can upload it to unstable.


How do you propose we should deal with the old API,
golang-github-libgit2-git2go-v32?


We can request removal of -v32 source package (which does not work 
anyway). Going forward, with a constant source package, the removals of 
binary packages will happen automatically.

Bug#1021320: isc-dhcp: diff for NMU version 4.4.3-2.1

[Santiago Ruano Rincón]

Dear Salvatore,

El 06/10/22 a las 22:57, Salvatore Bonaccorso escribió:
> Control: tags 1021320 + patch
> Control: tags 1021320 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for isc-dhcp (versioned as 4.4.3-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
> 
> This follows for updates already done in bullseye, so we have not a
> regression. Cf. DSA 5251-1.
> 
> Pushed as well to
> 
> https://salsa.debian.org/debian/isc-dhcp/-/tree/security-2022-10-05
> https://salsa.debian.org/debian/isc-dhcp/-/tags/debian%2F4.4.3-2.1
> 
> (creating a proper merge request does not seem possible for the
> project), but the tag can be merged into master branch once/if the NMU
> is accepted in the archive.
> 

Sorry. It should be fixed now (this project was moved to debian/ from
the former maintainers' namespace).

> Let me as well know if you would be fine with the NMU and have it
> moved faster.

>
Please, upload as soon as possible.

Thanks for your work!

 -- Santiago

 
> Regards,
> Salvatore

> diff -Nru isc-dhcp-4.4.3/debian/changelog isc-dhcp-4.4.3/debian/changelog
> --- isc-dhcp-4.4.3/debian/changelog   2022-05-26 21:31:55.0 +0200
> +++ isc-dhcp-4.4.3/debian/changelog   2022-10-06 22:20:47.0 +0200
> @@ -1,3 +1,12 @@
> +isc-dhcp (4.4.3-2.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * An option refcount overflow exists in dhcpd (CVE-2022-2928)
> +(Closes: #1021320)
> +  * DHCP memory leak (CVE-2022-2929) (Closes: #1021320)
> +
> + -- Salvatore Bonaccorso   Thu, 06 Oct 2022 22:20:47 +0200
> +
>  isc-dhcp (4.4.3-2) unstable; urgency=medium
>  
>* Explicitly link against -latomic to fix FTBFS on mipsel, m68k, powerpc 
> and
> diff -Nru isc-dhcp-4.4.3/debian/patches/CVE-2022-2928.patch 
> isc-dhcp-4.4.3/debian/patches/CVE-2022-2928.patch
> --- isc-dhcp-4.4.3/debian/patches/CVE-2022-2928.patch 1970-01-01 
> 01:00:00.0 +0100
> +++ isc-dhcp-4.4.3/debian/patches/CVE-2022-2928.patch 2022-10-06 
> 22:20:47.0 +0200
> @@ -0,0 +1,111 @@
> +Description: An option refcount overflow exists in dhcpd
> +Origin: upstream
> +Bug-Debian: https://bugs.debian.org/1021320
> +Bug-Debian-Security: 
> https://security-tracker.debian.org/tracker/CVE-2022-2928
> +Forwarded: not-needed
> +Last-Update: 2022-10-04
> +
> +diff --git a/common/options.c b/common/options.c
> +index 92c8fee6..f0959cb2 100644
> +--- a/common/options.c
>  b/common/options.c
> +@@ -4452,6 +4452,8 @@ add_option(struct option_state *options,
> + if (!option_cache_allocate(, MDL)) {
> + log_error("No memory for option cache adding %s (option %d).",
> +   option->name, option_num);
> ++/* Get rid of reference created during hash lookup. */
> ++option_dereference(, MDL);
> + return 0;
> + }
> + 
> +@@ -4463,6 +4465,8 @@ add_option(struct option_state *options,
> +  MDL)) {
> + log_error("No memory for constant data adding %s (option %d).",
> +   option->name, option_num);
> ++/* Get rid of reference created during hash lookup. */
> ++option_dereference(, MDL);
> + option_cache_dereference(, MDL);
> + return 0;
> + }
> +@@ -4471,6 +4475,9 @@ add_option(struct option_state *options,
> + save_option(_universe, options, oc);
> + option_cache_dereference(, MDL);
> + 
> ++/* Get rid of reference created during hash lookup. */
> ++option_dereference(, MDL);
> ++
> + return 1;
> + }
> + 
> +diff --git a/common/tests/option_unittest.c b/common/tests/option_unittest.c
> +index 600ebe60..963b5663 100644
> +--- a/common/tests/option_unittest.c
>  b/common/tests/option_unittest.c
> +@@ -213,6 +213,59 @@ ATF_TC_BODY(parse_X, tc)
> + }
> + }
> + 
> ++ATF_TC(add_option_ref_cnt);
> ++
> ++ATF_TC_HEAD(add_option_ref_cnt, tc)
> ++{
> ++atf_tc_set_md_var(tc, "descr",
> ++"Verify add_option() does not leak option ref counts.");
> ++}
> ++
> ++ATF_TC_BODY(add_option_ref_cnt, tc)
> ++{
> ++struct option_state *options = NULL;
> ++struct option *option = NULL;
> ++unsigned int cid_code = DHO_DHCP_CLIENT_IDENTIFIER;
> ++char *cid_str = "1234";
> ++int refcnt_before = 0;
> ++
> ++// Look up the option we're going to add.
> ++initialize_common_option_spaces();
> ++if (!option_code_hash_lookup(, dhcp_universe.code_hash,
> ++ _code, 0, MDL)) {
> ++atf_tc_fail("cannot find option definition?");
> ++}
> ++
> ++// Get the option's reference count before we call add_options.
> ++refcnt_before = option->refcnt;
> ++
> ++// Allocate a option_state to which to add an option.
> ++if (!option_state_allocate(, MDL)) {
> ++atf_tc_fail("cannot allocat options state");
> ++}
> ++
> ++// Call add_option() to add the option to the option state.
> ++if 

Bug#1021401: RFS: vulkan-loader/1.3.224.0-1~bpo11+1 -- Vulkan loader library -- development files

[Phil Morrell]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "vulkan-loader". It is a
trivial backport (dch --bpo) and does not need to go through NEW:

 * Package name : vulkan-loader
   Version  : 1.3.224.0-1~bpo11+1
 * URL  : https://github.com/KhronosGroup/Vulkan-Loader
 * License  : Apache-2.0, MIT
 * Vcs  : 
https://salsa.debian.org/emorrp1/vulkan-loader/-/tree/debian/bullseye-backports
   Section  : libs

The source builds the following binary packages:

  libvulkan1 - Vulkan loader library
  libvulkan-dev - Vulkan loader library -- development files

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

  https://mentors.debian.net/package/vulkan-loader/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vulkan-loader/vulkan-loader_1.3.224.0-1~bpo11+1.dsc

Changes since the last upload:

 vulkan-loader (1.3.224.0-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.
 .
 vulkan-loader (1.3.224.0-1) unstable; urgency=medium
 .
   * New upstream release.
 .
 vulkan-loader (1.3.216.0-1) unstable; urgency=medium
 .
   * New upstream release.
 .
 vulkan-loader (1.3.211.0-1) unstable; urgency=medium
 .
   [ Timo Aaltonen ]
   * New upstream release.
   * sync_headers.sh: Fix checking the version.
   * patches: Dropped, upstream.
 .
   [ Simon McVittie ]
   * tests: Exclude precompiled binary objects from .orig tarball
   * d/copyright: Update
   * Regenerate loader/generated/ during build.
 Thanks to Helmut Grohne (Closes: #981362)
   * d/rules: Delete another __pycache__ directory
   * d/libvulkan1.symbols: Expect i386 to be treated as an x86 architecture
 .
 vulkan-loader (1.3.204.1-2) unstable; urgency=medium
 .
   * symbols: Fix arch specific symbols.
 .
 vulkan-loader (1.3.204.1-1) unstable; urgency=medium
 .
   * New upstream release.
   * symbols: Fixed.
 .
 vulkan-loader (1.3.204.0-1) unstable; urgency=medium
 .
   * control: Drop python3-minimal dependency from libvulkan-dev.
   * New upstream release.
   * symbols: Updated.
   * symbols: Go back to a single symbols file, but skip some symbols on
 i386.
 .
 vulkan-loader (1.2.198.1-2) unstable; urgency=medium
 .
   * patches: Add patches to fix symbols for i386. (Closes: #1003219)
   * symbols: Add a symlink .aarch64 -> .amd64.
 .
 vulkan-loader (1.2.198.1-1) unstable; urgency=medium
 .
   * New upstream release.
   * sync_headers.sh: Updated to take sdk version as an argument, and use
 git checkout instead of force reset.
   * fix-ftbfs.diff: Dropped, upstream.
   * Drop prebuilt libdummy binaries from the source.
   * control: Add python dep to libvulkan-dev.
 .
 vulkan-loader (1.2.189.0-2) unstable; urgency=medium
 .
   * fix-ftbfs.diff: Fix a typo in a test.
 .
 vulkan-loader (1.2.189.0-1) unstable; urgency=medium
 .
   * New upstream release.

Regards,
--
  Phil Morrell


signature.asc
Description: PGP signature

Bug#1021268: should recommend/depend on libqt5multimedia5-plugins

[Christoph Berg]

Re: Ryan Kavanagh
> I have an Icom IC-7300 connected to my laptop via USB and am using
> pulseaudio. js8call did not list any audio devices (regardless of
> whether pulse was running) in its configuration menu until I installed
> libqt5multimedia5-plugins. It should be added as a dependency or at
> least as a recommends.

Oh, I would have thought I had carried over that dependency from wsjtx
when creating the package. I remember having had the exact same
problem in the beginning...

Upload is on the way, thanks!

Christoph DF7CB

Bug#1021205: transition: simdjson

[M. Zhou]

Thanks. It has been uploaded to unstable.

On Fri, 2022-10-07 at 10:23 +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 03/10/2022 19:22, M. Zhou wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hi release team,
> > 
> > I'd like to start the transition of simdjson. It has only two
> > reverse
> > dependencies in testing:
> > 
> >   cloudflare-ddns
> >   pcm
> > 
> > Both of them passed my local test with amd64 host.
> 
> Go ahead.
> 
> Cheers,
> Emilio
> 

Bug#1021394: src:libcereal: FTBFS on arm, ppc64le, s390x

[Scott Talbert]

On Fri, 7 Oct 2022, Andreas Tille wrote:


Control: tags -1 help
Control: tags -1 upstream
Control: tags -1 forwarded https://github.com/USCiLab/cereal/issues/744

Am Fri, Oct 07, 2022 at 09:37:03AM -0400 schrieb Scott Talbert:

Justification: fails to build from source (but built successfully in the past)


I guess it never has built in the past but the package was formerly
Architecture: all and thus it was somehow available on the said
architectures without really working there which was left unnoticed.


It seems, though, that it *has* been built in the past, e.g., on arm64:
https://buildd.debian.org/status/logs.php?pkg=libcereal=arm64

It looks like this package was not always Architecture: all, see:
https://salsa.debian.org/med-team/libcereal/-/commit/3e3f4a3b4e9bb068a87fd6fd118df01571b88448


libcereal 1.3.2+dfsg-3 FTBFS on arm, ppc64le, s390x.  This seems to be
the relevant error:

[ 22%] Building CXX object unittests/CMakeFiles/test_map.dir/map.cpp.o
cd /<>/obj-aarch64-linux-gnu/unittests && /usr/bin/c++  -I/<>/include -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wshadow -Wold-style-cast -Werror -std=gnu++11 -MD -MT 
unittests/CMakeFiles/test_map.dir/map.cpp.o -MF CMakeFiles/test_map.dir/map.cpp.o.d -o CMakeFiles/test_map.dir/map.cpp.o -c 
/<>/unittests/map.cpp
In file included from /<>/unittests/map.cpp:28:
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with 
IArchive = cereal::BinaryInputArchive; OArchive = cereal::BinaryOutputArchive]’:
/<>/unittests/map.cpp:34:68:   required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of 
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’} to ‘signed 
char’ [-Werror=narrowing]
   65 |   o_esplmap.insert({random_value(gen),  { random_value(gen), 
random_value(gen) }});
  | ~~^


This was reported by a Fedora user[1] - please see the build log
in the upstream issue.


See buildd logs for more information.


I'm tempted to reduce the severity of this bug to important since the
binary packages of the said architectures never were built and thus the
criterion for "serious" is not really fulfilled.  What do you think?

Another suggestion would be to exclude the two affected tests for the
said architectures for the moment - no idea how harmful this might be
in the end.


I'm not sure that we're seeing the same error as Fedora.  It looks like 
we're seeing a compile error while compiling the tests, rather than a test 
failure.


Regards,
Scott

Bug#1021400: RM: metaphlan2 -- ROM; Source package was renamed to metaphlan

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org

Hi,

as requested in bug #1016645 metaphlan2 was renamed to metaphlan (in
source and binary package).  Please remove metaphlan2 from unstable.

Kind regards and thank you for your work as ftpmaster
Andreas.

Bug#1021150: cryptsetup: please upload to bullseye-backports

[Luca Boccassi]

On Fri, 7 Oct 2022 at 13:47, Guilhem Moulin  wrote:
>
> Hi,
>
> On Sun, 02 Oct 2022 at 20:40:36 +0100, Luca Boccassi wrote:
> > Could you please consider an upload of the latest cryptsetup to
> > bullseye-backports?
>
> Bookworm/sid's cryptsetup-initramfs conflicts with Bullseye's lvm2.
> Could you please upload lvm2 to bullseye-backports, or ask the maintainer
> to do it?  I don't have the bandwidth for this, but will take care of
> the cryptsetup upload afterwards.

Thanks for checking, I'll add it to the to-do list and come back once
it's sorted.

Kind regards,
Luca Boccassi

Bug#1021399: RFS: unicode-data/15.0.0-1~bpo11+1 -- Property data for the Unicode character set

[Phil Morrell]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "unicode-data". It is a
trivial backport (dch --bpo) and does not need to go through NEW:

 * Package name : unicode-data
   Version  : 15.0.0-1~bpo11+1
 * URL  : https://www.unicode.org/
 * License  : Unicode-TOU
 * Vcs  : 
https://salsa.debian.org/debian/unicode-data/-/tree/debian/bullseye-backports
   Section  : misc

The source builds the following binary packages:

  unicode-data - Property data for the Unicode character set

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

  https://mentors.debian.net/package/unicode-data/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/unicode-data/unicode-data_15.0.0-1~bpo11+1.dsc

Changes since the last upload:

 unicode-data (15.0.0-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.
 .
 unicode-data (15.0.0-1) unstable; urgency=medium
 .
   * New upstream release. Closes: #1019852
   * Standards-Version: 4.6.1

Regards,
--
  Phil Morrell


signature.asc
Description: PGP signature

Bug#1019347: Similar bug still present in 1.7.2

[Sven Bartscher]

Hi,

I just noticed that the current upstream release 1.7.2 still has a bug 
very similar to this bug present. 
(https://projects.torsion.org/borgmatic-collective/borgmatic/issues/590)


It's basically the same bug, only with `patterns_from` instead of 
`patterns`.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021391: Kernel Exception at BananaPi M2 Ultra

[Bernhard]

Hello Diederik

Thank you for the fast answer.

For the log: there is nothing filtered.
This is the unfiltered output at the RS232 serial line at the BananaPi.
Attached, you can find also the output of journalctl.
You're right: here, there are a lot of more informations.

For another kernel, i can't say.
This is the first installation.

With testing version 2022.04, it looks the same.
Hopefully, i did it right with installing this version.

Best regards and thank you for the great support.
Bernhard



Am Freitag, dem 07.10.2022 um 15:26 +0200 schrieb Diederik de Haas:
> Control: tag -1 moreinfo
> 
> On vrijdag 7 oktober 2022 13:50:46 CEST Bernhard wrote:
> > The complete log from RS232 is attached.
> 
> > Starting kernel ...
> > 
> > [    0.003958] /cpus/cpu@0 missing clock-frequency property
> > [    0.003995] /cpus/cpu@1 missing clock-frequency property
> > [    0.004012] /cpus/cpu@2 missing clock-frequency property
> > [    0.004029] /cpus/cpu@3 missing clock-frequency property
> 
> That looks bad.
> It is that you already said that the *complete* log was attached, otherwise 
> I'd have asked whether you filtered it for errors as (pretty much) every line 
> looks troublesome :-O
> 
> > If i can do some other tests, please let me know.
> 
> Knowing if it worked before is rather useful and if so, with which kernel 
> version that would be. I don't know if installing a different kernel version 
> would automatically update the dtbs that are used, so please verify that.
> 
> And I think it would also be good to verify things with u-boot package from 
> testing (version 2022.04+dfsg-2)

Aug 27 23:39:05 Banana-Test kernel: Booting Linux on physical CPU 0x0
Aug 27 23:39:05 Banana-Test kernel: Linux version 5.19.0-2-armmp-lpae (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-6) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.11-1 (2022-09-24)
Aug 27 23:39:05 Banana-Test kernel: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
Aug 27 23:39:05 Banana-Test kernel: CPU: div instructions available: patching division code
Aug 27 23:39:05 Banana-Test kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Aug 27 23:39:05 Banana-Test kernel: OF: fdt: Machine model: Banana Pi BPI-M2-Ultra
Aug 27 23:39:05 Banana-Test kernel: Memory policy: Data cache writealloc
Aug 27 23:39:05 Banana-Test kernel: efi: UEFI not found.
Aug 27 23:39:05 Banana-Test kernel: cma: Reserved 16 MiB at 0xbee0
Aug 27 23:39:05 Banana-Test kernel: Zone ranges:
Aug 27 23:39:05 Banana-Test kernel:   DMA  [mem 0x4000-0x6fff]
Aug 27 23:39:05 Banana-Test kernel:   Normal   empty
Aug 27 23:39:05 Banana-Test kernel:   HighMem  [mem 0x7000-0xbfff]
Aug 27 23:39:05 Banana-Test kernel: Movable zone start for each node
Aug 27 23:39:05 Banana-Test kernel: Early memory node ranges
Aug 27 23:39:05 Banana-Test kernel:   node   0: [mem 0x4000-0xbfff]
Aug 27 23:39:05 Banana-Test kernel: Initmem setup node 0 [mem 0x4000-0xbfff]
Aug 27 23:39:05 Banana-Test kernel: psci: probing for conduit method from DT.
Aug 27 23:39:05 Banana-Test kernel: psci: Using PSCI v0.1 Function IDs from DT
Aug 27 23:39:05 Banana-Test kernel: percpu: Embedded 18 pages/cpu s40980 r8192 d24556 u73728
Aug 27 23:39:05 Banana-Test kernel: pcpu-alloc: s40980 r8192 d24556 u73728 alloc=18*4096
Aug 27 23:39:05 Banana-Test kernel: pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
Aug 27 23:39:05 Banana-Test kernel: Built 1 zonelists, mobility grouping on.  Total pages: 522560
Aug 27 23:39:05 Banana-Test kernel: Kernel command line: console=ttyS0,115200 quiet
Aug 27 23:39:05 Banana-Test kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
Aug 27 23:39:05 Banana-Test kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
Aug 27 23:39:05 Banana-Test kernel: mem auto-init: stack:off, heap alloc:on, heap free:off
Aug 27 23:39:05 Banana-Test kernel: Memory: 2018200K/2097152K available (10240K kernel code, 1669K rwdata, 3428K rodata, 2048K init, 379K bss, 62568K reserved, 16384K cma-reserved, 1294324K highmem)
Aug 27 23:39:05 Banana-Test kernel: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Aug 27 23:39:05 Banana-Test kernel: ftrace: allocating 39119 entries in 115 pages
Aug 27 23:39:05 Banana-Test kernel: ftrace: allocated 115 pages with 5 groups
Aug 27 23:39:05 Banana-Test kernel: trace event string verifier disabled
Aug 27 23:39:05 Banana-Test kernel: rcu: Hierarchical RCU implementation.
Aug 27 23:39:05 Banana-Test kernel: rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
Aug 27 23:39:05 Banana-Test kernel: Rude variant of Tasks RCU enabled.
Aug 27 23:39:05 Banana-Test kernel: Tracing variant of Tasks RCU enabled.
Aug 27 23:39:05 Banana-Test kernel: rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
Aug 27 23:39:05 

Bug#1021394: src:libcereal: FTBFS on arm, ppc64le, s390x

[Andreas Tille]

Control: tags -1 help
Control: tags -1 upstream
Control: tags -1 forwarded https://github.com/USCiLab/cereal/issues/744

Am Fri, Oct 07, 2022 at 09:37:03AM -0400 schrieb Scott Talbert:
> Justification: fails to build from source (but built successfully in the past)

I guess it never has built in the past but the package was formerly
Architecture: all and thus it was somehow available on the said
architectures without really working there which was left unnoticed.
 
> libcereal 1.3.2+dfsg-3 FTBFS on arm, ppc64le, s390x.  This seems to be
> the relevant error:
> 
> [ 22%] Building CXX object unittests/CMakeFiles/test_map.dir/map.cpp.o
> cd /<>/obj-aarch64-linux-gnu/unittests && /usr/bin/c++  
> -I/<>/include -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wshadow -Wold-style-cast -Werror 
> -std=gnu++11 -MD -MT unittests/CMakeFiles/test_map.dir/map.cpp.o -MF 
> CMakeFiles/test_map.dir/map.cpp.o.d -o CMakeFiles/test_map.dir/map.cpp.o -c 
> /<>/unittests/map.cpp
> In file included from /<>/unittests/map.cpp:28:
> /<>/unittests/map.hpp: In instantiation of ‘void test_map() 
> [with IArchive = cereal::BinaryInputArchive; OArchive = 
> cereal::BinaryOutputArchive]’:
> /<>/unittests/map.cpp:34:68:   required from here
> /<>/unittests/map.hpp:65:43: error: narrowing conversion of 
> ‘random_value(gen)’ from ‘std::enable_if::type’ {aka 
> ‘char’} to ‘signed char’ [-Werror=narrowing]
>65 |   o_esplmap.insert({random_value(gen),  { 
> random_value(gen), random_value(gen) }});
>   | ~~^

This was reported by a Fedora user[1] - please see the build log
in the upstream issue.

> See buildd logs for more information.

I'm tempted to reduce the severity of this bug to important since the
binary packages of the said architectures never were built and thus the
criterion for "serious" is not really fulfilled.  What do you think?

Another suggestion would be to exclude the two affected tests for the
said architectures for the moment - no idea how harmful this might be
in the end.
 
> Also, please push the 1.3.2+dfsg-3 changes to git.

Done.

Kind regards
Andreas.


[1] https://github.com/USCiLab/cereal/issues/744

-- 
http://fam-tille.de

Bug#1021398: ITP: golang-github-niemeyer-pretty -- Pretty printing for Go values

[sunmin]

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

* Package name: golang-github-niemeyer-pretty
  Version : 2011-12-22-1
  Upstream Author : Gustavo Niemeyer
* URL : https://github.com/niemeyer/pretty
* License : Expat
  Programming Lang: Go
  Description : Pretty printing for Go values

 package pretty
 .
 import "github.com/kr/pretty"
 .
 Package pretty provides pretty-printing for Go values.
 .
 Documentation
 .
 http://godoc.org/github.com/kr/pretty

This package is a dependency of sigs.k8s.io/kustomize/kyaml@v0.13.6

I'd like to package it to the official repo, thanks!!!

Bug#1021397: RM: python-model-mommy -- ROM; replaced by python-model-bakery

[Edward Betts]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: edw...@4angle.com

Dear FTP team,

Please can you remove the python-model-mommy package?

Upstream has renamed the package from model-mommy to model-bakery.

python-model-bakery is packaged in Debian.

More details here:  https://bugs.debian.org/1007952

Thanks,
-- 
Edward

Bug#1021396: ITP: batterylog -- laptop battery logging tool

[Antoine Beaupre]

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

* Package name: batterylog
  Version : none
  Upstream Author : Leonard Lin
* URL : https://github.com/lhl/batterylog
* License : GPLv3
  Programming Lang: Python
  Description : laptop battery logging tool

A simple Python app with few dependencies that reads your
sysfs-class-power numbers and records them to a local sqlite3 db with
an "event" tag.

It was built to track suspend power usage for Framework laptops, but
is flexible/easily extensible to do all kinds of other stuff.



This is similar to the already packaged battery-stats, but is a little
more explicit in its output. While battery-stats keeps a text and CSV
log, batterylog stores its entries in a SQLite database.

battery-stats stores new entries every minute, in cron, while
batterylog does it on systemd triggers (like sleep/resume). It could,
in theory, do exactly the same as battery-stats and run in a cron job,
but those are triggers installed by default upstream.

They both keep different records in each entry. battery-stats keep the
charge status (charging/discharging), manufacturer, battery type and
identifier, while batterylog keeps voltages.

both ship similarly-named binaries, battery-stats ships battery-log,
and batterylog ships... batterylog.

batterylog is a single script, ~130 lines of python, quite readable,
while battery-stats is a mix of shell and python, spread over multiple
files.

batterlog was started a few months ago, and is the work of a single
maintainer. batterystats has been around since 2013 and has seen half
a dozen contributors (including myself).

batterystats can generate graphs, and, really, all batterylog
currently does is this:

$ /opt/batterylog/batterylog
Slept for 8.72 hours
Used 6.10 Wh, an average rate of 0.70 W
For your 53.67 Wh battery this is 1.30%/hr or 31.29%/day

But it's surprisingly useful in trying to tune battery life,
especially during suspend.

Bug#1021395: ITP: jumbo -- Java library for processing CML

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: jumbo
  Version : 6.0
  Upstream Author : Peter Murray-Rust et al.
* URL : https://github.com/BlueObelisk/jumbo6
* License : Apache-2.0
  Programming Lang: Java
  Description : Java library for processing CML

JUMBO is a library which validates and supports CML Schema.

jumbo is needed by jumbo-converters, converter package to and from CML, 
Chemical Markup Language.


Remark: This package is to be maintained with Debian Java Maintainers at
   https://salsa.debian.org/java-team/jumbo

Bug#1021394: src:libcereal: FTBFS on arm, ppc64le, s390x

[Scott Talbert]

Package: src:libcereal
Version: 1.3.2+dfsg-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

libcereal 1.3.2+dfsg-3 FTBFS on arm, ppc64le, s390x.  This seems to be
the relevant error:

[ 22%] Building CXX object unittests/CMakeFiles/test_map.dir/map.cpp.o
cd /<>/obj-aarch64-linux-gnu/unittests && /usr/bin/c++  
-I/<>/include -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wshadow -Wold-style-cast -Werror 
-std=gnu++11 -MD -MT unittests/CMakeFiles/test_map.dir/map.cpp.o -MF 
CMakeFiles/test_map.dir/map.cpp.o.d -o CMakeFiles/test_map.dir/map.cpp.o -c 
/<>/unittests/map.cpp
In file included from /<>/unittests/map.cpp:28:
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with 
IArchive = cereal::BinaryInputArchive; OArchive = cereal::BinaryOutputArchive]’:
/<>/unittests/map.cpp:34:68:   required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of 
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’} 
to ‘signed char’ [-Werror=narrowing]
   65 |   o_esplmap.insert({random_value(gen),  { 
random_value(gen), random_value(gen) }});
  | ~~^
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with 
IArchive = cereal::PortableBinaryInputArchive; OArchive = 
cereal::PortableBinaryOutputArchive]’:
/<>/unittests/map.cpp:39:84:   required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of 
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’} 
to ‘signed char’ [-Werror=narrowing]
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with 
IArchive = cereal::XMLInputArchive; OArchive = cereal::XMLOutputArchive]’:
/<>/unittests/map.cpp:44:62:   required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of 
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’} 
to ‘signed char’ [-Werror=narrowing]
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with 
IArchive = cereal::JSONInputArchive; OArchive = cereal::JSONOutputArchive]’:
/<>/unittests/map.cpp:49:64:   required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of 
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’} 
to ‘signed char’ [-Werror=narrowing]

See buildd logs for more information.

Also, please push the 1.3.2+dfsg-3 changes to git.

Thanks,
Scott

Bug#1020938: khard: missing Python dependency python3-pkg-resources

[Félix Sipma]

Hi,

Could you provide logs? python3-pkg-resources does not seem to be 
required to run khard on a minimal sid. I don't get why it would be 
different for stable.


Regards,

--
Félix


signature.asc
Description: PGP signature

Bug#1021391: Kernel Exception at BananaPi M2 Ultra

[Diederik de Haas]

Control: tag -1 moreinfo

On vrijdag 7 oktober 2022 13:50:46 CEST Bernhard wrote:
> The complete log from RS232 is attached.

> Starting kernel ...
> 
> [0.003958] /cpus/cpu@0 missing clock-frequency property
> [0.003995] /cpus/cpu@1 missing clock-frequency property
> [0.004012] /cpus/cpu@2 missing clock-frequency property
> [0.004029] /cpus/cpu@3 missing clock-frequency property

That looks bad.
It is that you already said that the *complete* log was attached, otherwise 
I'd have asked whether you filtered it for errors as (pretty much) every line 
looks troublesome :-O

> If i can do some other tests, please let me know.

Knowing if it worked before is rather useful and if so, with which kernel 
version that would be. I don't know if installing a different kernel version 
would automatically update the dtbs that are used, so please verify that.

And I think it would also be good to verify things with u-boot package from 
testing (version 2022.04+dfsg-2)

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

Bug#1008263: plans to upload memtest86+ 6 to unstable?

[Antoine Beaupré]

On 2022-10-06 22:11:54, Fabio Fantoni wrote:
> Il 06/10/2022 17:44, Antoine Beaupré ha scritto:
>> Hello Fabio!
>>
>> Below is an excerpt of a discussion that happened in bug #1008263 about
>> removing pcmemtest from Debian, to remove the duplication of work with
>> memtest86+:
>>
>> On 2022-09-09 17:08:34, Felix Zielcke wrote:
>>> I wasn't sure if I should wait until the new memtest86+ gets out of
>>> beta and uploaded to unstable. But yeah, maybe it's better to just file
>>> the RM now
>> I am wondering if you had any plans to upload memtest86+ 6 to unstable
>> already? It looks like it could fix a *lot* of issues that currently
>> affect memtest86, which is basically unusable on modern platforms right
>> now.
>>
>> For example, on my Framework laptop -- which only boots from EFI --
>> memtest86 from testing/unstable just doesn't boot at all. I am just
>> testing the version from experimental and, so far so good, it seems to
>> work fine!
>>
>> Thanks for any update!
>>
> Hi, I was waiting the release of the definitive (stable) version before 
> upload to unstable, unfortunately the release scheduled for a month ago 
> was delayed, however x86fr said there is a last patch missing that he 
> needs to add shortly and then 6.00 will be released

I still think the current beta release is better than what we have in
unstable... But as long as it makes it to bookworm, I'm happy. :)

a.

-- 
Be conservative in what you send and liberal in what you accept.
- John Postel

Bug#1021393: error in package nginx-common_1.18.0-6ubuntu14.2_all.deb for ubuntu 22.04 with default enabled site.

[Stuart Culligan]

Package: nginx-common

Version: 1.18.0-6ubuntu14.2


This is for ubuntu 22.04.
The default site file contains :
listen 80 default_server;
listen [::]:80 default_server;

This is an error and causes the entire nginx install to fail.

Commenting out one of listen lines corrects the issue.

Bug#987953: more info

[Roderich Schupp]

On Wed, 5 Oct 2022 18:51:27 +0200 Roderich Schupp
 wrote:
> the problem is the compile command:
>
> /usr/bin/cc -I/<> -g -O2 ... -Wall -I
> -I/usr/include/vte-2.91 -I/usr/include/glib-2.0 ...
>
> The "-I" after "-Wall" gobbles up the following "-I/usr/include/vte-2.9" as
> option value. This adds a non-existent directory to the include search path,
> but gcc doesn't complain about this unless you run it with "-v".
>
> The lone "-I" is also present in a successful build (w/pkg-config), cf.

In fact, pkg-config and pkgconf return the same set of --cflags for
all modules involved here,
but in a different order (and pkgconf deduplicates flags). Neither
returns the lone "-I".

The "-I" is most likely the result of the following line in src/CMakeLists.txt:

SET(TERMIT_CFLAGS "-I${LUA_INCLUDE_DIR}")

LUA_INCLUDE_DIR is probably a typo - pkg_search_module(LUA ...) sets
LUA_INCLUDE_DIRS (note the trailing S). The SET is also superfluous as
later on LUA_CFLAGS (set by pkg_search_module(LUA ...) )
is appended to TERMIT_CFLAGS with

FOREACH(cflag ${VTE_CFLAGS} ${GTK_CFLAGS} ${LUA_CFLAGS})
  SET(TERMIT_CFLAGS "${TERMIT_CFLAGS} ${cflag}")
ENDFOREACH(cflag)

Cheers, Roderich

Bug#1019554: Stamp files are not updated

[Lance Lin]

Hello Helge,

> Do you have any idea what both anacron.service and anacron.timer are
> disabled?
>
> So somehow anacron -34 disabled both the service and the timer.
>
> Anything you want me to look at?
>
> Next step would be how to properly enable them again…
>
> Thanks!
>
> Greetings
>
> Helge

I believe I've found the issue! Sorry it has taken so long to get back to you 
but I believe I have an answer.

It seems to be related to an inadequate cleanup. I don't have a great 
explanation but I found something that works.

The -33 version that removed the symlinks *somehow* (I am not sure) corrupted 
the whole install. I've found that
uninstalling anacron, removing the files associated with anacron and then 
re-installing the package (-35) will 

yield a service that works.

Specifically, I removed:
/var/lib/systemd/deb-systemd-helper-*/ ... anacron files [might not be needed?]
/var/lib/dpkg/info/anacron.* files [might not be needed?]
/var/spool/anacron
/etc/anacrontab [I think this file is the problem!!]

Since you already have cron files, perhaps you could back them up, uninstall 
anacron, remove the files, and then
re-install anacron (-35), and then overlay your existing cron files? Would you 
be so kind to test this out on 

your machine and see if this fixes it?

If it does, I will need to ask mentors on the best solution for this problem as 
it seems to be introduced in -33 

but will only impact users who upgraded to -33 at some point. Going from -32 to 
-35, for instance, should not cause 

problems. I've even made a notional -36 version to verify that once the service 
is running, the upgrade works smoothly.

Thank you for your help in tracking this down!

Lance Lin 
GPG Fingerprint:  4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7

signature.asc
Description: OpenPGP digital signature

Bug#987544: RFP: envoyproxy -- high performance C++ distributed proxy designed for single services and applications

[ryan]

Hi,

Im a maintainer on the Envoy project, and currently have some 
reponsibility around our release process.


We have been working on packaging Envoy for Debian and Ubuntu and 
generally improving our release process.


Currently our efforts are around packaging the statically compiled 
binary which has no system dependencies other than glibc.


It would definitely be preferable to have Envoy added into the 
distribution, but i guess the complex part is figuring out how to 
compile non-statically and turn bazel dependencies into system ones.


If we can do anything to assist in this I would be more than happy to 
help.


cheers,

Ryan Northey (@phlax)

Bug#878599: [PATCH] Ship git-libsecret

[Vit Kabele]

Hello,

this thread seems to be stale, but I'd still like to have the libsecret
credential helper present in Debian repository.

I tested the submitted patch and did some adjustments so that the
package actually builds. I did it against 2.20 because I was not able to
find git branch for current stable 2.30.2, but when I tried on the
downloaded 2.30.2 sources, the patch applied with one minimal change.

I will be happy to modify to the last stable if you point me to it.
(The debian-stable branch points to 2.20).

I also tested the resulting 2.30 package on my Bullseye machine and it
installs and works fine (it's just not listed in `git help -a`, but I'm
not sure that it should be).

Can we ressurect the discussion and progress with this topic?

Best regards,
Vit Kabele

-- >8 --

Create a new package git-libsecret that builds the libsecret
compatible git credentials helper as a new package.

Signed-off-by: Ville Skyttä 
Co-authored-by: Vit Kabele 
---
 debian/control   | 22 +++---
 debian/git-libsecret.install |  1 +
 debian/rules |  5 +
 3 files changed, 25 insertions(+), 3 deletions(-)
 create mode 100644 debian/git-libsecret.install

diff --git a/debian/control b/debian/control
index e6be01c90a..716bda9e5f 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Gerrit Pape 
 Uploaders: Jonathan Nieder , Anders Kaseorg 

 Build-Depends: libz-dev, gettext,
  libpcre2-dev | libpcre3-dev,
- libcurl4-gnutls-dev, libexpat1-dev,
+ libcurl4-gnutls-dev, libexpat1-dev, libsecret-1-dev,
  subversion, libsvn-perl, libyaml-perl,
  tcl, python,
  libhttp-date-perl | libtime-parsedate-perl,
@@ -33,7 +33,7 @@ Pre-Depends: ${misc:Pre-Depends}
 Recommends: ca-certificates, patch, less, ssh-client
 Suggests: gettext-base, git-daemon-run | git-daemon-sysvinit,
  git-doc, git-el, git-email, git-gui, gitk, gitweb,
- git-cvs, git-mediawiki, git-svn
+ git-cvs, git-mediawiki, git-svn, git-libsecret
 Replaces: gitweb (<< 1:1.7.4~rc1),
  git-core (<< 1:1.7.0.4-1.)
 Breaks: bash-completion (<< 1:1.90-1), gitweb (<< 1:1.7.4~rc1),
@@ -323,12 +323,28 @@ Description: fast, scalable, distributed revision control 
system (web interface)
  If libcgi-fast-perl is installed, gitweb can also be run over FastCGI
  (and served by nginx, for example).
 
+Package: git-libsecret
+Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< 
${source:Upstream-Version}-.)
+Description: fast, scalable, distributed revision control system (libsecret 
credential helper)
+ Git is popular version control system designed to handle very large
+ projects with speed and efficiency; it is used for many high profile
+ open source projects, most notably the Linux kernel.
+ .
+ Git falls in the category of distributed source code management tools.
+ Every Git working directory is a full-fledged repository with full
+ revision tracking capabilities, not dependent on network access or a
+ central server.
+ .
+ This package provides a helper for storing credentials using libsecret.
+
 Package: git-all
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< 
${source:Upstream-Version}-.),
  git-doc, git-el, git-cvs, git-mediawiki, git-svn,
- git-email, git-gui, gitk, gitweb
+ git-email, git-gui, gitk, gitweb, git-libsecret
 Recommends: git-daemon-run | git-daemon-sysvinit
 Description: fast, scalable, distributed revision control system (all 
subpackages)
  Git is popular version control system designed to handle very large
diff --git a/debian/git-libsecret.install b/debian/git-libsecret.install
new file mode 100644
index 00..d61ca822bc
--- /dev/null
+++ b/debian/git-libsecret.install
@@ -0,0 +1 @@
+debian/tmp/usr/lib/git-core/git-credential-libsecret* usr/lib/git-core
diff --git a/debian/rules b/debian/rules
index d5d81608d8..5febe17ac0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,7 @@ build-stamp:
 override_dh_auto_build-arch: build-stamp
$(MAKE) -C contrib/subtree all $(OPTS)
ln -s contrib/subtree/git-subtree
+   $(MAKE) -C contrib/credential/libsecret all $(OPTS)
 
 override_dh_auto_test-arch:
test -z '$(TEST)' || \
@@ -90,6 +91,7 @@ override_dh_auto_clean:
$(MAKE) -C contrib/subtree clean $(OPTS)
$(MAKE) clean $(OPTS)
rm -f git-subtree
+   $(MAKE) -C contrib/credential/libsecret clean $(OPTS)
 
 override_dh_clean:
dh_clean -Xmailinfo.c.orig
@@ -98,6 +100,9 @@ override_dh_auto_install-arch:
# git
DESTDIR='$(GIT)' $(MAKE) install $(OPTS)
DESTDIR='$(GIT)' $(MAKE) -C contrib/subtree install $(OPTS)
+   install -d -m0755 '$(TMP)'/usr/lib/git-core/
+   install -m0755 contrib/credential/libsecret/git-credential-libsecret \
+'$(TMP)'/usr/lib/git-core/
install -d -m0755 '$(GIT)'/var/lib/git
rm -rf '$(GIT)'/usr/share/man
# don't include arch, cvs, p4, 

Bug#1021353: RFS: zvbi/0.2.37-1 -- Vertical Blanking Interval (VBI) utilities

[Adam Borowski]

On Thu, Oct 06, 2022 at 05:11:17PM +0300, Ileana Dumitrescu wrote:
>  * Package name : zvbi
>Version  : 0.2.37-1
>Upstream contact : Ileana Dumitrescu 

>  zvbi (0.2.37-1) unstable; urgency=medium
>  .
>[ Ileana Dumitrescu ]
>* New upstream release.
>* debian/control: updated maintainer email, project homepage
>  bumped Standards-Version to 4.6.1 (no changes)
>* debian/copyright: updated debian copyright year, upstream contact, source
>updated licensing
>* debian/patches: removed all patches (fixed in upstream)
>* debian/rules: README.md in override_dh_installdocs
>override_dh_autoreconf to run autogen.sh
>* debian/watch: switched to new upstream repo location
>  .
>[ Debian Janitor ]
>* debian/control: Use secure URI in Homepage field
>- Remove constraints unnecessary since buster (oldstable):
>  + libzvbi-dev: Drop versioned constraint on libzvbi0 in Replaces.
>  + libzvbi-doc: Drop versioned constraint on libzvbi-dev in Replaces.
>  + zvbi: Drop versioned constraint on lsb-base in Depends.

Hi!  The symbols look wrong:

dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: debian/libzvbi0/DEBIAN/symbols doesn't match 
completely debian/libzvbi0.symbols
--- debian/libzvbi0.symbols (libzvbi0_0.2.37_amd64)
+++ dpkg-gensymbolsRQLkMF   2022-10-07 10:00:48.055446695 +
@@ -12,13 +12,18 @@
  _vbi_strndup@Base 0.2.35
  _vbi_vasprintf@Base 0.2.35
  _zvbi_intl_domainname@Base 0.2.35
+ close@Base 0.2.37
  device_close@Base 0.2.35
  device_ioctl@Base 0.2.35
  device_mmap@Base 0.2.35
  device_munmap@Base 0.2.35
  device_open@Base 0.2.35
+ fcntl@Base 0.2.37
  fprint_symbolic@Base 0.2.35
  fprint_unknown_ioctl@Base 0.2.35
+ ioctl@Base 0.2.37
+ open@Base 0.2.37
+ read@Base 0.2.37
  vbi_capture_delete@Base 0.2.35
  vbi_capture_fd@Base 0.2.35
  vbi_capture_flush@Base 0.2.35
@@ -72,6 +77,7 @@
  vbi_proxy_msg_stop_listen@Base 0.2.35
  vbi_proxy_msg_write@Base 0.2.35
  vbi_proxy_msg_write_idle@Base 0.2.35
+ write@Base 0.2.37
 libzvbi.so.0 libzvbi0 #MINVER#
  __vbi_event_handler_list_send@Base 0.2.35
  _vbi3_bit_slicer_destroy@Base 0.2.35

Defining and leaking basic syscall wrappers suggests something is pretty
wrong.


Also: you may drop the lsb-base Depends altogether; lintian will complain
until its next release but if you know the future you can avoid changing the
same thing twice :)

An upstreamish issue but since you might have a way to contact upstream:
W: libzvbi-dev: national-encoding [usr/include/libzvbi.h]
As we don't even support ancient encodings anymore, everyone who reads the
header will get mojibake.  Could you please convert everything to UTF-8?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ You're alive.  But that's just a phase.
⠈⠳⣄

Bug#1021392: dput: Ambiguity when dput thinks package is already uploaded

[Moritz Schlarb]

Package: dput
Version: 1.1.2
Severity: normal
Tags: patch

This bit me recently, because I uploaded a package, which got rejected because
my uid wasnt in dm acl for the package and after that was fixed, I tried
uploading again and the current wording led me to believe that there is
something on the ftp-master side that needs to be resolved - but of course,
that wasn't the case ;-)

I've proposed adding a line about the logfile here:
https://salsa.debian.org/debian/dput/-/merge_requests/9

But maybe it would be even wiser to just advertise using the -f option in this
case?

Regards,
Moritz


-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /home/moschlar/.config/dput/dput.cf --

-- /home/moschlar/.dput.cf --
No package or host has been provided, see dput -h

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
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 dput depends on:
ii  python33.10.6-1
ii  python3-debian 0.1.48

Bug#1021390: nvda2speechd: downloads source from the network during build

[Samuel Thibault]

Control: severity -1 important

Andreas Beckmann, le ven. 07 oct. 2022 13:38:15 +0200, a ecrit:
> Justification: fails to build from source (but built successfully in the past)
> 
> During a local rebuild of contrib and non-free (w/o network access
> permitted), I noticed

It can build the source, just not without the network. That's why it's
in contrib, not main.

Samuel

Bug#1021391: Kernel Exception at BananaPi M2 Ultra

[Bernhard]

Package: src:linux
Severity: normal
Version: 5.19.11-1

Hello,

I installed with the daily images "testing, bookworm" to Banana Pi M2 Ultra.
After poweroff, there is a kernel exception regarding i2c:

> Last login: Fri Oct  7 13:02:50 CEST 2022 on ttyS0
> [?2004hroot@Banana-Test:~# poweroff
> [?2004l
> Failed to connect to bus: No such file or directory
> [   92.114464] reboot: Power down
> [   94.163385] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
> [  102.615362] [ cut here ]
> [  102.619982] WARNING: CPU: 0 PID: 13 at kernel/irq_work.c:134 
> irq_work_queue_on+0x104/0x108
> [  102.628259] Modules linked in: hci_uart btqca btrtl btbcm btintel 
> bluetooth jitterentropy_rng sha512_generic sha512_arm snd_soc_hdmi_codec 
> dw_hdmi_cec dw_hdmi_i2s_audio evdev sun8i_drm_hdmi
> aes_arm_bs crypto_simd dw_hdmi cryptd drbg axp20x_adc drm_display_helper 
> industrialio cec ansi_cprng brcmfmac brcmutil axp20x_pek sun4i_i2s lima 
> ecdh_generic gpu_sched ecc drm_shmem_helper sunxi_cir
> snd_soc_core snd_pcm_dmaengine sunxi_cedrus(C) snd_pcm rc_core v4l2_mem2mem 
> snd_timer sun8i_thermal sunxi_wdt cfg80211 snd videobuf2_dma_contig soundcore 
> videobuf2_memops videobuf2_v4l2
> videobuf2_common rfkill videodev mc leds_gpio sun6i_dma display_connector 
> fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
> crc32c_generic realtek ahci_sunxi libahci_platform
> dwmac_sun8i libahci stmmac_platform axp20x_regulator stmmac pcs_xpcs phylink 
> mdio_mux of_mdio fixed_phy fwnode_mdio libphy ptp libata pps_core i2c_mv64xxx 
> ehci_platform ohci_platform ohci_hcd
> phy_sun4i_usb ehci_hcd sun4i_drm scsi_mod
> [  102.628661]  sun4i_frontend usbcore sunxi_mmc sun8i_mixer scsi_common 
> sun4i_tcon sun8i_tcon_top drm_cma_helper drm_kms_helper drm
> [  102.727286] CPU: 0 PID: 13 Comm: rcu_sched Tainted: G C
> 5.19.0-2-armmp-lpae #1  Debian 5.19.11-1
> [  102.737367] Hardware name: Allwinner sun8i Family
> [  102.742078]  unwind_backtrace from show_stack+0x18/0x1c
> [  102.747314]  show_stack from dump_stack_lvl+0x40/0x4c
> [  102.752374]  dump_stack_lvl from __warn+0xd0/0x134
> [  102.757176]  __warn from warn_slowpath_fmt+0x80/0xbc
> [  102.762145]  warn_slowpath_fmt from irq_work_queue_on+0x104/0x108
> [  102.768242]  irq_work_queue_on from rcu_implicit_dynticks_qs+0x200/0x330
> [  102.774951]  rcu_implicit_dynticks_qs from force_qs_rnp+0x154/0x250
> [  102.781223]  force_qs_rnp from rcu_gp_fqs_loop+0x224/0x320
> [  102.786714]  rcu_gp_fqs_loop from rcu_gp_kthread+0x110/0x174
> [  102.792377]  rcu_gp_kthread from kthread+0xd8/0xf4
> [  102.797174]  kthread from ret_from_fork+0x14/0x34
> [  102.801881] Exception stack(0xf0851fb0 to 0xf0851ff8)
> [  102.806932] 1fa0:   
>  
> [  102.815102] 1fc0:       
>  
> [  102.823272] 1fe0:     0013 
> [  102.829880] ---[ end trace  ]---
> [  113.127339] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [  113.133263] rcu:   3-O..0: (1 GPs behind) idle=7ad/0/0x1 softirq=4245/4248 
> fqs=1219 
> [  113.140921](detected by 0, t=5255 jiffies, g=2641, q=52 ncpus=4)
> [  113.147098] rcu: Offline CPU 3 blocking current GP.
> 

The complete log from RS232 is attached.
Hopefully it helps.

If i can do some other tests, please let me know.

Best regards and thank you for your support.
Bernhard



U-Boot SPL 2022.10+dfsg-1 (Oct 04 2022 - 00:06:38 +)
DRAM: 2048 MiB
Trying to boot from MMC1


U-Boot 2022.10+dfsg-1 (Oct 04 2022 - 00:06:38 +) Allwinner Technology

CPU:   Allwinner R40 (SUN8I 1701)
Model: Banana Pi BPI-M2-Ultra
DRAM:  2 GiB
Core:  65 devices, 22 uclasses, devicetree: separate
WDT:   Not starting watchdog@1c20c90
MMC:   mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1
Loading Environment from FAT... Unable to use mmc 0:1...
In:serial@1c28000
Out:   serial@1c28000
Err:   serial@1c28000
Net:   eth0: ethernet@1c5
starting USB...
Bus usb@1c19000: ehci_generic usb@1c19000: failed to get usb phy
Port not available.
Bus usb@1c19400: ohci_generic usb@1c19400: failed to get usb phy
Port not available.
Bus usb@1c1c000: ehci_generic usb@1c1c000: failed to get usb phy
Port not available.
Bus usb@1c1c400: ohci_generic usb@1c1c400: failed to get usb phy
Port not available.
Hit any key to stop autoboot:  2  1  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2627 bytes read in 3 ms (854.5 KiB/s)
## Executing script at 4310
Mainline u-boot / new-style environment detected.
5210624 bytes read in 272 ms (18.3 MiB/s)
24053 bytes read in 6 ms (3.8 MiB/s)
25060423 bytes read in 1287 ms (18.6 MiB/s)
Booting Debian 5.19.0-2-armmp-lpae from mmc 0:1...
Kernel image @ 0x4200 [ 0x00 - 0x4f8200 ]
## Flattened Device Tree blob at 4300
   Booting using the fdt 

Bug#1021150: cryptsetup: please upload to bullseye-backports

[Guilhem Moulin]

Hi,

On Sun, 02 Oct 2022 at 20:40:36 +0100, Luca Boccassi wrote:
> Could you please consider an upload of the latest cryptsetup to
> bullseye-backports?

Bookworm/sid's cryptsetup-initramfs conflicts with Bullseye's lvm2.
Could you please upload lvm2 to bullseye-backports, or ask the maintainer
to do it?  I don't have the bandwidth for this, but will take care of
the cryptsetup upload afterwards.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1021390: nvda2speechd: downloads source from the network during build

[Andreas Beckmann]

Source: nvda2speechd
Version: 0.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

During a local rebuild of contrib and non-free (w/o network access
permitted), I noticed

   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/nvda2speechd-0.1'
blhc: ignore-line-regexp: \ \ \ Compiling .*
# Don't do this at home, kids!
curl --cacert /etc/ssl/certs/Amazon_Root_CA_1.pem --proto '=https' --tlsv1.2 -f 
https://sh.rustup.rs > rustup.sh
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
^M  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
0curl: (6) Could not resolve host: sh.rustup.rs
make[1]: *** [debian/rules:27: override_dh_auto_build] Error 6


Andreas

Bug#1016800: libgit2: please package version 1.5.x

[Timo Röhling]

Hi,

* Pirate Praveen  [2022-10-03 12:06]:

Thanks for working on libgit2 update.

Next time, remember to file bugs against all reverse (build) 
dependencies. There was no bug filed against 
golang-github-libgit2-git2go (may be others too).


reverse-depends src:libgit2
reverse-depends -b src:libgit2

These two commands can get you the list of reverse (build) dependencies.

I'm sorry I missed that package; I relied on the transition tracker,
which doesn't really work that well for static linkage.

I'm not very proficient with Go and its packaging policies, but I
updated golang-github-libgti2-git2go locally to v35, which is
pretty straight-forward, and it builds and passes autopkgtests.

How do you propose we should deal with the old API,
golang-github-libgit2-git2go-v32?

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
commit df263ec858fc00e521e072554a2eb2efa2cc92fb
Author: Timo Röhling 
Date:   Fri Oct 7 13:09:08 2022 +0200

Rename -dev package

diff --git a/debian/changelog b/debian/changelog
index ed9bee3..016e0d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+golang-github-libgit2-git2go (35.0.0-1) UNRELEASED; urgency=medium
+
+  * New upstream version 35.0.0
+
+ -- Timo Röhling   Fri, 07 Oct 2022 13:08:18 +0200
+
 golang-github-libgit2-git2go (33.0.9-2) unstable; urgency=medium
 
   * Source-only upload for migration to testing
diff --git a/debian/control b/debian/control
index 257b5e5..80c9a81 100644
--- a/debian/control
+++ b/debian/control
@@ -14,20 +14,20 @@ Build-Depends: debhelper-compat (= 13),
golang-golang-x-crypto-dev,
golang-github-google-shlex-dev,
git,
-   libgit2-dev (>= 1.3~)
-Standards-Version: 4.6.0
+   libgit2-dev (>= 1.5~)
+Standards-Version: 4.6.1
 Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-github-libgit2-git2go.git
 Vcs-Git: https://salsa.debian.org/go-team/packages/golang-github-libgit2-git2go
 Homepage: https://github.com/libgit2/git2go
-XS-Go-Import-Path: github.com/libgit2/git2go/v33
+XS-Go-Import-Path: github.com/libgit2/git2go/v35
 Rules-Requires-Root: no
 
-Package: golang-github-libgit2-git2go-v33-dev
+Package: golang-github-libgit2-git2go-v35-dev
 Architecture: all
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  pkg-config,
- libgit2-dev (>= 1.3~)
+ libgit2-dev (>= 1.5~)
 Description: Go bindings for libgit2
  libgit2 is a portable, pure C implementation of the Git distributed version
  control system core methods provided as a re-entrant link-able library with a


signature.asc
Description: PGP signature

Bug#1021389: tcl-ttkthemes: When this is installed, tclsh 'package require Tk' fails with circular dependency error

[Patty]

Package: tcl-ttkthemes
Version: 3.2.0-1
Severity: grave
Justification: this renders another package 'tclsh' unusable, as well as this 
package itself
X-Debbugs-Cc: dusthillresid...@gmail.com

Dear Maintainer,

When this package is installed, 'tclsh' (the Tcl interpreter, provided by 
debian package 'tcl') becomes broken in such a way that it's no longer possible 
to import/load the Tk graphics/gui extension (provided by debian package 'tk').

Although I'm reporting from a Debian Stable system,
this bug is happening in Ubuntu too,
and this package seems obscure so I assume this may still be an issue that 
nobody else has noticed or fixed yet.

Steps to reproduce:
 0. Start a X windows/desktop session.
 1. Install debian packages 'tcl', and 'tk', and 'tcl-ttkthemes', perhaps with 
this command or similar:
sudo apt-get install tcl tk tcl-ttkthemes
 2. Create a text file with the name 'test.tcl' and put these lines in it:
package require Tk
pack [ label .l -text "Debian" ]
 3. Open a terminal window and run this command:
 tclsh test.tcl
 4. Observe that this error message is printed and the script exits:
circular package dependency: attempt to provide Tk Ϻ£ü requires Tk
while executing
"package require Tk"
(file "test.tcl" line 1)
 5. Uninstall debian package 'tcl-ttkthemes'.
 6. Run 'tclsh test.tcl' again, and note that this time the error is not 
printed and the script opens a window with text "Debian" in it.

Thank you

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

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

Versions of packages tcl-ttkthemes depends on:
ii  tcl  8.6.11+1
ii  tk   8.6.11+1

tcl-ttkthemes recommends no packages.

tcl-ttkthemes suggests no packages.

-- no debconf information

Bug#1012021: yarnpkg: segfault while building greenbone-security-assistant on !amd64

[Andreas Beckmann]

Followup-For: Bug #1012021

And now it fails to build on amd64, too:

   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/greenbone-security-assistant-21.4.4'
dh_auto_build
yarnpkg
yarn install v1.22.19
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
[4/5] Linking dependencies...
warning "@greenbone/ui-components > bootstrap@4.6.0" has unmet peer dependency 
"jquery@1.9.1 - 3".
warning "@greenbone/ui-components > bootstrap@4.6.0" has unmet peer dependency 
"popper.js@^1.16.1".
warning "@greenbone/ui-components > styled-components@5.2.1" has unmet peer 
dependency "react-is@>= 16.8.0".
warning " > babel-loader@8.1.0" has unmet peer dependency "webpack@>=2".
warning "react-scripts > @typescript-eslint/eslint-plugin > tsutils@3.17.1" has 
unmet peer dependency "typescript@>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 
3.4.0-dev || >= 3.5.0-dev || >= 3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || 
>= 3.7.0-beta".
warning "@storybook/react > react-docgen-typescript-plugin@0.6.2" has unmet 
peer dependency "typescript@>= 3.x".
warning "@storybook/react > react-docgen-typescript-plugin > 
react-docgen-typescript@1.20.5" has unmet peer dependency "typescript@>= 3.x".
warning "@storybook/react > react-docgen-typescript-plugin > 
react-docgen-typescript-loader@3.7.2" has unmet peer dependency "typescript@*".
warning " > @testing-library/user-event@13.1.9" has unmet peer dependency 
"@testing-library/dom@>=7.21.4".
warning " > eslint-config-prettier@8.3.0" has unmet peer dependency 
"eslint@>=7.0.0".
[5/5] Building fresh packages...
success Saved lockfile.
Done in 262.03s.
yarnpkg build
yarn run v1.22.19
$ INLINE_RUNTIME_CHUNK=false react-scripts build && rm -f build/*.js*
node:internal/modules/cjs/loader:528
  throw e;
  ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/tokenize' is not 
defined by "exports" in 
/build/greenbone-security-assistant-21.4.4/node_modules/postcss-safe-parser/node_modules/postcss/package.json
at new NodeError (node:internal/errors:393:5)
at throwExportsNotFound (node:internal/modules/esm/resolve:358:9)
at packageExportsResolve (node:internal/modules/esm/resolve:668:3)
at resolveExports (node:internal/modules/cjs/loader:522:36)
at Module._findPath (node:internal/modules/cjs/loader:562:31)
at Module._resolveFilename (node:internal/modules/cjs/loader:971:27)
at Module._load (node:internal/modules/cjs/loader:833:27)
at Module.require (node:internal/modules/cjs/loader:1051:19)
at require (node:internal/modules/cjs/helpers:103:18)
at Object. 
(/build/greenbone-security-assistant-21.4.4/node_modules/postcss-safe-parser/lib/safe-parser.js:1:17)
 {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

Node.js v18.10.0
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this 
command.
make[1]: *** [debian/rules:14: override_dh_auto_build] Error 1


Andreas

Bug#1009703: Bug has been fixed upstream

[pulkomandy]

Upstream bugreport and fix:
https://pulkomandy.tk/projects/GrafX2/ticket/171

Bug#1021387: RM: spirv-llvm-translator -- ROM; no longer used; targets obsolete llvm version

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal
Control: clone -1 -2
Control: retitle -2 RM: intel-opencl-clang -- ROM; no longer used; targets 
obsolete llvm version

Please remove some obsolete versions of spirv-llvm-translator and
intel-opencl-clang from the archive. These "unversioned" packages
currently target llvm-13 and were never usable for the current
versions of intel-graphics-compiler/intel-compute-runtime, since
upstream went directly from llvm-12 to llvm-14.
Newer versions are packaged as spirv-llvm-translator-XX and
opencl-clang-XX (14 and 15 currently being in the archive).

Andreas

Bug#1021386: ITP: samply -- A command line profiler for Linux

[Sylvestre Ledru]

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

* Package name: samply
  Version : 0.9.0
  Upstream Author : Markus Stange 
* URL : https://crates.io/crates/samply
* License : MIT OR Apache-2.0 
  Programming Lang: Rust
  Description : A command line profiler for Linux