Bug#1041902: lua5.4: 'lua_settop' may use an invalid pointer to stack

[Asher Gordon]

Package: lua5.4
Version: 5.4.4-3
Severity: normal
X-Debbugs-Cc: none, Asher Gordon 

Dear Maintainer,

I found a bug in which calling lua_toclose() while the "main" stack is
active (i.e., not inside a function which was called by lua_call()), can
sometimes cause memory errors later. As I later found out, this was a
symptom of a bug in lua_settop(). Here is a minimal example showcasing
the bug:
#include 

#include 
#include 
#include 

/* Here's where we do our experimentation. The table returned by the
   Lua program should be given as the sole argument on the Lua
   stack. */
static int experiment(lua_State *L) {
  /* local obj  = class:new() */
  lua_getfield(L, -1, "new");
  lua_rotate(L, -2, 1);
  lua_call(L, 1, 1);
  lua_toclose(L, -1);
  lua_pop(L, 1);

  return 0;
}

int main(int argc, char **argv) {
  lua_State *L;
  const char *prog;

  if (argc != 2) {
fprintf(stderr, "Usage: %s FILE\n", argv[0]);
return 1;
  }

  prog = argv[1];

  L = luaL_newstate();
  luaL_openlibs(L);

  if (luaL_loadfile(L, prog))
lua_error(L);

  lua_call(L, 0, 1);

  if (!lua_istable(L, -1))
luaL_error(L, "%s did not return a table", prog);

#ifdef BAD_CODE
  /* Here's where the error originates! If we call experiment()
 manually like this, closing the value causes memory errors later
 on. Instead, we have to call it through Lua. */
  experiment(L);
#else
  /* This works as expected. */
  lua_pushcfunction(L, experiment);
  lua_rotate(L, -2, 1);
  lua_call(L, 1, 0);
#endif

  lua_close(L);

  return 0;
}
local inspect = require 'inspect'

local class = {}

local mt = {__index = class}

function mt:__close ()
   print('Closing!')
   -- This triggers the error for some reason. I imagine it's not
   -- specific to the 'inspect' package, but rather just doing
   -- something complex with 'self'.
   print(inspect(self))
end

function class:new ()
   assert(self == mt.__index)
   return setmetatable({foo = 'bar'}, mt)
end

return class
Compile using

$ gcc -Wall -O0 -DBAD_CODE `pkg-config --cflags lua5.4` -o memory-error 
memory-error.c `pkg-config --libs lua5.4`

and then run it with

$ valgrind ./memory-error test.lua

You should notice many errors. If you compile without -DBAD_CODE, it
works as expected (see the source for details).

I tried this with the latest upstream version from git, and found that
the bug did not occur. After some bisecting, I found the commit where
this was fixed upstream. The commit is "196bb94d Bug: 'lua_settop' may
use an invalid pointer to stack"
https://github.com/lua/lua/commit/196bb94d66e727e0aec053a0276c3ad701500762

I'm not sure if this is a security issue or not. If so, please raise the
Severity accordingly.

I think this fix from upstream should be backported to Debian's Lua 5.4,
and possibly 5.{1,2,3} as well (I haven't tested those). Hopefully it is
as simple as applying the patch.

Thanks,
Asher

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: 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 lua5.4 depends on:
ii  libc6 2.37-5
ii  libreadline8  8.2-1.3

lua5.4 recommends no packages.

lua5.4 suggests no packages.

-- no debconf information

-- 
Yesterday upon the stair
I met a man who wasn't there.
He wasn't there again today --
I think he's from the CIA.
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#1041901: RFS: riemann-c-client/1.10.4-3 [NMU] -- Client utility for the Riemann event stream processor

[Romain Tartière]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "riemann-c-client":

 * Package name : riemann-c-client
   Version  : 1.10.4-3
   Upstream contact : Gergely Nagy 
 * URL  : https://git.madhouse-project.org/algernon/riemann-c-client
 * License  : LGPL-3+
 * Vcs  : 
https://git.madhouse-project.org/algernon/riemann-c-client/src/branch/debian/master
   Section  : libs

The source builds the following binary packages:

  libriemann-client0 - C language client library for the Riemann event stream 
processor
  libriemann-client-dev - Development files for the Riemann C client library
  riemann-c-client - Client utility for the Riemann event stream processor

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

  https://mentors.debian.net/package/riemann-c-client/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/riemann-c-client/riemann-c-client_1.10.4-3.dsc

Changes since the last upload:

 riemann-c-client (1.10.4-3) unstable; urgency=medium
 .
   * Fix GnuTLS send/recv.


This change is intended to fix bugs in the library that make the TLS
transport unreliable. I created patches to rebuild the Debian package we
use in production, they solved our issues so I upstreamed them and I
would like them to be introduced in Debian to avoid the need to maintain
patched packages and so that other users can have a better experience
with the package on Debian.

It is my very first submission of a package, so do not intend to request
maintainership for this package ATM.

The mentors.debian.net page list some points that are probably legit,
but I am not sure that they should be addressed in a bugfix release of
the package, so for now I refrained to fix them until instructed to do
so.  Likewise, when filling-in patches "metadata" I was unsure about if
they where intended to be filled by me or not, so left them untouched
(this is not reported on the website).

So I am looking forward for reading mentors feedback to help me leverage
this package fix according to the Debian standards and guide me through
the process of making Debian even better!

Thank you!

Regards,

-- 
Romain Tartière http://romain.blogreen.org/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature

Bug#1041900: cloud.debian.org: please publish arm64 vagrant boxes

[Ross Vandegrift]

Package: cloud.debian.org
Severity: wishlist
User: cloud.debian@packages.debian.org
Usertags: vagrant image
X-Debbugs-Cc: rvandegr...@debian.org

Hello,

I've been in touch with folks from the kdevops project [1].  They are looking
for more vagrant images for arm64.  Would it be possible to publish the arm64
boxes that debian-vagrant-images can build?

I started looking into this.  I'm pretty new to vagrant, but here's what I
learned so far:

- vagrant doesn't handle boxes with different architectures [2].  The advice
  seems to be to publish under a different name: e.g.  "debian/testing-arm64".

- Building the arm64 box works just fine, and I can import it sucessfully.

- I'm trying to get vagrant to boot it, but still not quite there yet.

Thanks,
Ross

[1] - https://github.com/mcgrof/kdevops/
[2] - https://github.com/hashicorp/vagrant/issues/12610

Bug#1041899: libreoffice-uiconfig-report-builder: undeclared file conflicts with libreoffice-report-builder/unstable

[Helmut Grohne]

Package: libreoffice-uiconfig-report-builder
Version: 4:7.6.0~rc1-1
Severity: serious

Hi Rene,

thanks for the fixes to the other file conflict issues. Unfortunately,
your upload also introduces new problems.

libreoffice-uiconfig-report-builder now contains a lot of files below
/usr/lib/libreoffice/share/config/soffice.cfg/modules/dbreport that also
happen to be contained in libreoffice-report-builder (from
bullseye-backports to unstable). Are you missing replaces here?

Helmut

Bug#1041898: libserial-dev: Exception in destructor causes linked program termination

[Matsievskiy S.V.]

Package: libserial-dev
Version: 1.0.0-9
Severity: important
X-Debbugs-Cc: matsievski...@gmail.com

Dear Maintainer,

This version of the library in some situations may throw an exception from
LibSerial::SerialPort destructor. Since it's marked as noexcept, it can't be
caught and causes termination of the program.
This situation can be modelled with the MWE below:

#include 
#include 

int
main(void)
{
std::unique_ptr serial(new
LibSerial::SerialPort("/dev/ttyUSB0"));
std::cout << "Disconnect cable and press Enter" << std::endl;
std::cin.get();
try {
serial->Close();
} catch (const std::runtime_error& err) {
std::cout << "Exception: " << err.what() << std::endl;
std::flush(std::cout);
}
serial.reset();
return 0;
}

Here, we connect to some serial dongle, such as USB to serial adapter and
disconnect it in the middle of the program, which causes Input/Output exception
to take place. Even though the exception is caught when the port is closed,
LibSerial::SerialPort destructor rethrows it, causing the program to terminate.

This behaviour is not observed in the latest version of the library
(https://github.com/crayzeewulf/libserial/commit/f1504de092d94148e2ec690bbb1e7ee21889ede7).
Please, consider updating the package to the newer version.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable'), (50, 'unstable'), (10, 'unstable-debug'), 
(10, 'testing-debug'), (10, 'stable-debug'), (10, 'experimental-debug'), (10, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
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 libserial-dev depends on:
ii  libserial1  1.0.0-9

libserial-dev recommends no packages.

Versions of packages libserial-dev suggests:
pn  libserial-doc  

-- no debconf information

Bug#1041854: bookworm-pu: package calibre/6.13.0+repack-2+deb12u1

[yokota]

> Please go ahead.

Thank you, I uploaded the fixed package.

--
YOKOTA Hiroshi

Bug#1041897: inode too large on 32-bit systems

[陈天宇]

Package: ninja-build
Version: 1.11.1-1
Severity: important
Tags: patch

Hi,

On unstable-i386-sbuild, ninja is complaining 
stat(/usr/share/cmake-3.27/Modules/CMakeCCompilerABI.c): Value too large for 
defined data type. Cause i'm using sbuild with overlay, the inode could be 
large like 8591159748.

Upstream has merged a patch[1] to fix this but has not released 1.12. Could we 
patch ninja to fix it?

[1]: https://github.com/ninja-build/ninja/pull/2203

Tianyu Chen @ Deepin

Bug#1041895: wayvnc: Please package new upstream version 0.6.2

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Boyuan Yang (2023-07-25 03:59:05)
> As we previously discussed, wayvnc package has a dependency chain of wayvnc
> --> neatvnc --> aml. Given that Debian 12 has released, I am looking to
> updating these packages.
> 
> I worked on package neatvnc and aml, and looks like they are having
> some strict version requriements. Now I have pushed the new version of
> neatvnc and aml into Sid, and prepared the new upload of package
> wayvnc at https://salsa.debian.org/debian/wayvnc . If you have time,
> please take a look, check the packaging and upload the new version if it
> looks good. Please let me know if there's any issue.

it looks really good! The only problems I was able to find are, that

 - you used the suite value "unstable" in the latest debian/changelog entry
   instead of UNRELEASED. The problem with using "unstable" is, that there is
   now a state in git which looks as if the package was in sid. This is fine,
   if this state of the package is really the one that gets uploaded but now
   you opened this bug so the latest changelog entry is missing a "closes" of
   this bug.

 - you didn't close this bug (but you probably didn't have a bug number yet?)

 - you are too fast! :D I had a look at the salsa pipeline and your uploads of
   neatvnc and aml to sid are too fresh and the pipeline didn't succeed yet

Would you like to add yourself to the Uploaders field? Then you do not have to
make this an NMU. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1014517:

[Dillon Amburgey]

I have seen this as well. This has recently started breaking apt
update on bookworm docker images as well as images built off bookworm
(e.g. python:3.8)

This can be easily reproduced on FIPS-enabled hosts:
docker run  -it --rm debian:bookworm apt update
Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Get:2 http://deb.debian.org/debian bookworm-updates InRelease [52.1 kB]
Get:3 http://deb.debian.org/debian-security bookworm-security
InRelease [48.0 kB]
Get:4 http://deb.debian.org/debian bookworm/main amd64 Packages [8906 kB]
Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [4732 B]
Get:6 http://deb.debian.org/debian-security bookworm-security/main
amd64 Packages [48.0 kB]
Fetched 9210 kB in 2s (4169 kB/s)
fatal error in libgcrypt, file ../../src/misc.c, line 92, function
_gcry_fatal_error: requested algo not in md context

Fatal error: requested algo not in md context

I also was able to use snapshot.debian.org to isolate when the
failures started. 20230722T085252Z was the last good snapshot with
20230722T110049Z being the first failing snapshot.
docker run -v .:/etc/apt/sources.list.d/:ro -it --rm debian:bookworm apt update
Get:1 http://snapshot.debian.org/archive/debian/20230722T110049Z
bookworm InRelease [151 kB]
Get:2 http://snapshot.debian.org/archive/debian/20230722T110049Z
bookworm-updates InRelease [52.1 kB]
Get:3 http://snapshot.debian.org/archive/debian-security/20230722T110049Z
bookworm-security InRelease [48.0 kB]
Get:4 http://snapshot.debian.org/archive/debian/20230722T110049Z
bookworm/main amd64 Packages [8906 kB]
Get:5 http://snapshot.debian.org/archive/debian/20230722T110049Z
bookworm-updates/main amd64 Packages [4732 B]
Get:6 http://snapshot.debian.org/archive/debian-security/20230722T110049Z
bookworm-security/main amd64 Packages [48.0 kB]
Fetched 9210 kB in 1min 8s (136 kB/s)
fatal error in libgcrypt, file ../../src/misc.c, line 92, function
_gcry_fatal_error: requested algo not in md context

Fatal error: requested algo not in md context

docker run -v .:/etc/apt/sources.list.d/:ro -it --rm debian:bookworm apt update
Get:1 http://snapshot.debian.org/archive/debian/20230722T085252Z
bookworm InRelease [147 kB]
Get:2 http://snapshot.debian.org/archive/debian/20230722T085252Z
bookworm-updates InRelease [52.1 kB]
Get:3 http://snapshot.debian.org/archive/debian-security/20230722T085252Z
bookworm-security InRelease [48.0 kB]
Get:4 http://snapshot.debian.org/archive/debian-debug/20230722T085252Z
bookworm-debug InRelease [49.8 kB]
Get:5 http://snapshot.debian.org/archive/debian/20230722T085252Z
bookworm/main amd64 Packages [8904 kB]
Ign:5 http://snapshot.debian.org/archive/debian/20230722T085252Z
bookworm/main amd64 Packages
Get:6 http://snapshot.debian.org/archive/debian/20230722T085252Z
bookworm-updates/main amd64 Packages [4732 B]
Get:7 http://snapshot.debian.org/archive/debian-security/20230722T085252Z
bookworm-security/main amd64 Packages [48.0 kB]
Get:8 http://snapshot.debian.org/archive/debian-debug/20230722T085252Z
bookworm-debug/main amd64 Packages [3564 kB]
Get:5 http://snapshot.debian.org/archive/debian/20230722T085252Z
bookworm/main amd64 Packages [8904 kB]
Ign:5 http://snapshot.debian.org/archive/debian/20230722T085252Z
bookworm/main amd64 Packages
Get:5 http://snapshot.debian.org/archive/debian/20230722T085252Z
bookworm/main amd64 Packages [8904 kB]
Fetched 11.2 MB in 5min 13s (35.9 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

Bug#1041896: lintian: detect changelog with both QA upload and new maintainer

[Paul Wise]

Package: lintian
Severity: wishlist

Recently I noticed a package enter Debian with a changelog that was
both a QA upload and introducing a new maintainer. This doesn't really
make sense because a QA upload means it is still orphaned but a new
maintainer means it has been adopted. Perhaps the person who did the
upload didn't understand what QA uploads are for. Please check for QA
uploads that change the maintainer and emit a warning for them.

package (1.2.3-4) unstable; urgency=medium

  * QA upload.
  * New maintainer (Closes: #1234567).
  * Other changes here

 -- Some One   Tue, 25 Jul 2023 02:10:51 +

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1038978: Workaround - Backport from Sid

[jygibson102515]

I tried and verified. I was able to manually backport the package from

http://deb.debian.org/debian/pool/main/p/pydrive2/pydrive2_1.15.0-3.dsc

It built and installed fine against bookworm. I was able to create a Google 
drive backup. 

I cannot do it but it could be put in bookworm-backports and made available.

Bug#1041895: wayvnc: Please package new upstream version 0.6.2

[Boyuan Yang]

Source: wayvnc
Severity: normal
Version: 0.5.0-1
X-Debbugs-CC: jo...@debian.org

Dear Debian wayvnc package maintainer,

As we previously discussed, wayvnc package has a dependency chain of
wayvnc --> neatvnc --> aml. Given that Debian 12 has released, I
am looking to updating these packages.

I worked on package neatvnc and aml, and looks like they are having
some strict version requriements. Now I have pushed the new version of
neatvnc and aml into Sid, and prepared the new upload of package
wayvnc at https://salsa.debian.org/debian/wayvnc . If you have time,
please take a look, check the packaging and upload the new version
if it looks good. Please let me know if there's any issue.

Thanks,
Boyuan Yang


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

Bug#1041894: geoclue: unexpected apparmor denial opening /proc/sys/net/ipv6/conf/all/disable_ipv6

[Paul Wise]

Package: geoclue-2.0
Version: 2.7.0-2
Severity: normal
File: /etc/apparmor.d/usr.libexec.geoclue
Usertags: apparmor

The geoclue apparmor confinement seems to cause unexpected denials when
checking if IPv6 is disabled. Either the check mechanism should be
allowed or it should be explicitly denied.

   Jul 25 09:17:39 systemd[1]: Starting geoclue.service - Location Lookup 
Service...
   Jul 25 09:17:39 systemd[1]: Started geoclue.service - Location Lookup 
Service.
   Jul 25 09:17:41 kernel: audit: type=1400 audit(1690247861.799:82): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:41 kernel: audit: type=1400 audit(1690247861.799:83): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:42 kernel: audit: type=1400 audit(1690247862.303:84): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:42 kernel: audit: type=1400 audit(1690247862.303:85): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:42 kernel: audit: type=1400 audit(1690247862.403:86): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:42 kernel: audit: type=1400 audit(1690247862.403:87): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:42 kernel: audit: type=1400 audit(1690247862.415:88): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:42 kernel: audit: type=1400 audit(1690247862.415:89): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:42 kernel: audit: type=1400 audit(1690247862.427:90): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:17:42 kernel: audit: type=1400 audit(1690247862.427:91): 
apparmor="DENIED" operation="open" class="file" profile="/usr/libexec/geoclue" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1560 comm="pool-geoclue" 
requested_mask="r" denied_mask="r" fsuid=140 ouid=0
   Jul 25 09:18:40 geoclue[1560]: Service not used for 60 seconds. Shutting 
down..
   Jul 25 09:18:40 systemd[1]: geoclue.service: Deactivated successfully.

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

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

Versions of packages geoclue-2.0 depends on:
ii  adduser 3.137
ii  libavahi-client30.8-10
ii  libavahi-common30.8-10
ii  libavahi-glib1  0.8-10
ii  libc6   2.37-6
ii  libglib2.0-02.76.4-3
ii  libjson-glib-1.0-0  1.6.6-1
ii  libmm-glib0 1.20.6-2
ii  libnotify4  0.8.2-1
ii  libsoup-3.0-0   3.2.2-2

Versions of packages geoclue-2.0 recommends:
ii  avahi-daemon  0.8-10
ii  iio-sensor-proxy  3.4-2
ii  modemmanager  1.20.6-2
ii  wpasupplicant 2:2.10-12

geoclue-2.0 suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1041893: linux-config: Enable CONFIG_IONIC

[Shannon Nelson]

Package: linux-config
Version: 6.1_6.1.37

The ionic network driver has been in the upstream kernel since v5.4, but 
it is not enabled in the Debian distribution.  We have some customers 
that want to use the inbox driver in the Debian distribution, but the 
kernel has been built without it being enabled:

$ grep IONIC config*
config.amd64_none_amd64:# CONFIG_IONIC is not set
config.amd64_none_cloud-amd64:# CONFIG_IONIC is not set
Following other distributions, such as Red Hat and Ubuntu, please enable 
the driver with

CONFIG_IONIC=m

Thanks,

Shannon Nelson
shannon.nel...@amd.com
Maintainer of ionic

Bug#996850: ITP: rhsrvany -- Windows tools used by virt-v2v

[Ryan Pavlik]

The package is done and works well, I just haven't had time to find a
sponsor and follow it through the new queue process.

Ryan

On Mon, Jul 24, 2023, 11:09 AM Lee Garrett  wrote:

> Hi Ryan,
>
> is there any update on the packaging progress?
>
> Greets,
> Lee
>
>
> On Tue, 19 Oct 2021 10:48:35 -0500 Ryan Pavlik 
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ryan Pavlik 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> >
> > * Package name: rhsrvany
> >   Version : 0.20210127
> >   Upstream Author : Richard W.M. Jones, Red Hat Inc.
> > * URL : https://github.com/rwmjones/rhsrvany
> > * License : GPL-2+
> >   Programming Lang: C
> >   Description : Windows tools used by virt-v2v
> >
> >  This package contains open-source replacements for
> >  proprietary Windows tools, SrvAny (RHSrvAny) and pnp_wait.
> >  They are used by the virt-v2v tool when converting
> >  Windows virtual machines.
> >
> > This is required for virt-v2v (see https://bugs.debian.org/962293)
> > which was formerly part of libguestfs in Buster and now the
> > subject of its own RFP bug linked above.
> > The draft of that package is in the libvirt team,
> > and if this package is accepted, I'd anticipate joining that team
> > for team maintenance and sponsorship. The code itself is quite stable,
> > with a limited purpose and having seen little need for changes in
> > the past several years, so I anticipate
> > packaging maintenance load to be low.
> >
>

Bug#996433: transmission-daemon: Transmission fails to send mail using exim4

[JT Hundley]

I've installed transmission 4.0.2 from testing and found that it reverted
my /etc/systemd/system/multi-user.target.wants/transmission-daemon.service
to have NoNewPrivileges=true which broke exim sending mail again. This bug
seems to still be present. Let me know if there's any other info I can
provide.

On Thu, Jun 15, 2023 at 3:17 PM JT Hundley  wrote:

> I have no idea. I assume upgrading transmission wouldn't ask me to keep an
> older file here and I did not modify any of these files until I ran into
> the issue. I did that test on a fresh install which rules out me messing up
> the files :)
> Also, I'm not sure how I missed your email about this, sorry about that.
> I'm not sure if this bug is still present in the current stable version. I
> found this ticket after looking to make a new one for transmission in
> Debian 12.
>
> On Wed, 13 Oct 2021 22:16:52 -0400 Sandro Tosi  wrote:
> > control: tags -1 +moreinfo
> >
> > > It seems that this bug is caused by this change in Transmission:
> https://github.com/transmission/transmission/pull/795
> > > After changing my
> > > /etc/systemd/system/multi-user.target.wants/transmission-daemon.service
> > > to read "NoNewPrivileges=false" instead of true and reloading the
> > > service and daemon, I find that transmission is properly sending emails
> > > again.
> >
> > this is weird: that PR is included in the 3.00 release provided in
> > debian, and infact the file
> > /lib/systemd/system/transmission-daemon.service includes the PR
> > change; how did you get that outdated file in /etc/systemd/system/ ?
> >
> > --
> > Sandro "morph" Tosi
> > My website: http://sandrotosi.me/
> > Me at Debian: http://wiki.debian.org/SandroTosi
> > Twitter: https://twitter.com/sandrotosi
> >
> >
>

Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux

[Daniel Gröber]

Hi Andrej,

On Mon, Jul 24, 2023 at 07:38:13PM +0200, Andrej Shadura wrote:
> On Mon, 24 Jul 2023, at 16:16, Daniel Gröber wrote:
> > tundra-nat64 is a new userspace implementation of SIIT, NAT64 and
> > [CLAT]. It's multithreaded as opposed to tayga so my hope is the
> > performance will be much better.
> >
> > I plan on maintaining tuntra-nat64 myself but I do need a sponsor :)
> 
> As the maintainer of tayga, I’ll be happy to sponsor tundra too :)

My cup runneth over on this ITP. You're just a smidge too late, I think me
and Paul got this. First come first sponsored I guess? :)

Thanks for the offer nonetheless,
--Daniel

PS: You can expect a crunchy new Tayga PMTU/fragmentation bug within the
fortnight if I don't forget :P

Bug#1041855: linux-image-6.4.0-1-amd64: IO wait regression

[Ben Hutchings]

Control: severity -1 important

On Mon, 2023-07-24 at 15:40 +0200, Christian Göttsche wrote:
> Package: src:linux
> Version: 6.4.4-1
> Severity: serious
> 
> Dear Maintainer,
> 
> Kernel 6.4.4 is affected by a regression causing one core be report
> high IO wait utilization.
> 
> See https://lore.kernel.org/lkml/12251678.o9o76zd...@natalenko.name/

There is no such thing as a CPU having "high IO wait utilization". 
When tasks are in I/O wait state, they are not using a CPU.

Unfortunately, for historical reasons Linux includes such tasks in the
load average and reports a CPU as being in I/O wait state when it's
idle and the last task running on it went into I/O wait state (at least
I think that's what the rule is).

So this bug is about an unwanted change in task/CPU state reporting,
not tasks suddenly using much more CPU time.  For that reason, I don't
think it should "serious", i.e. a blocker for testing propagation.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.



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

Bug#1041892: debchange --bpo ignores -D

[Marco d'Itri]

Package: devscripts
Version: 2.23.5
Severity: normal

If I run e.g. "debchange -D bullseye-backports --bpo" then debchange 
should be smart enough to use the correct value for the changelog entry 
and for the package version, but instead it defaults to the current 
stable release:

package (8.1-1~bpo12+1) bullseye-backports; urgency=medium

  * Rebuild for bookworm-backports.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1041870: [3dprinter-general] Bug#1041870: slic3r-prusa FTBFS on i386

[Christoph Berg]

Re: Adrian Bunk
> 2. the following change:
> 
> --- debian/rules.old  2023-07-24 15:36:20.941771419 +
> +++ debian/rules  2023-07-24 15:36:43.133759741 +
> @@ -5,7 +5,7 @@
>  # less debug info to avoid running out of address space
>  ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
>   export DEB_CXXFLAGS_MAINT_APPEND += --param ggc-min-expand=5 -g0
> -else ifneq (,$(filter $(DEB_HOST_ARCH), armhf))

The old command was wrong anyway, the pattern list comes first:

ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))

Doesn't matter when it's a single item without % wildcards, but will
explode when adding more architectures.

Christoph

Bug#1041891: cloud.debian.org: Debian VM doesn’t boot with "console=hvc0" kernel parameter

[Azat Khusainov]

Package: cloud.debian.org
Severity: important
X-Debbugs-Cc: xycain...@gmail.com

Dear Maintainer,

I've tried to run "genericcloud" arm64 image on QEMU with "device virtconsole" 
argument and direct kernel boot with "console=hvc0" kernel parameter. 
When "hvc0" is the only console argument in kernel parameters - debian doesn't 
boot. 
But when i configure additional console argument like this: "console=ttyAMA0 
console=hvc0" - it boots normally. 
In this case "/sys/class/tty/console/active" contains both consoles "ttyAMA0 
hvc0". 
However "serial-getty" doesn't start at hvc0 as expected. Systemd has to spawn 
getty on hvc0 when it's present. 
I've tried to boot VM using GRUB with 'GRUB_CMDLINE_LINUX="console=hvc0"' 
option. 
It runs - but ttyAMA0 activates anyway and "/sys/class/tty/console/active" 
again contains both consoles "ttyAMA0 hvc0". 
I've tested debian-12-genericcloud-arm64 and debian-11-genericcloud-arm64 
images with same result. 
Noteworthy i've tried another distributions (Ubuntu, Fedora and openSUSE 
"cloud" arm64 images) and they all work with "hvc0" configured as the only 
console, "/sys/class/tty/console/active" contains only "hvc0" and serial-getty 
automatically started on hvc0. 

Bug#1041890: rust-sha2: please update to v0.10.7

[Jonas Smedegaard]

Source: rust-sha2
Version: 0.10.5-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to upstream release v0.10.7.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+8kcACgkQLHwxRsGg
ASEVDxAAg/2kUVSYR+Xl1QV95HTIUAhaRyprcCvT18UKRcavvuWFVcEoIpca67zP
3YnXf/+EECdmkY+eg4v2t1qIVo0disg6vYBstMk40/YEvF2lX7BEv7UWR3Rtgd/7
7LDv/caJCnyJDVnANGSjsagV5/81pzLvbKOtYRIkGKtwGW32csCOusDZ08W7kztt
OpeMozWQu2QunA9oc2UsxpTMcUmPNU8OqDp1rThD25Aou13AOZYXoVKOs62AEKST
9ZhiWhMeeep80l5QrsKyc6qorwEf5vM5sRowShZU6PURruOtnzJnn3S5uzMpo6jD
/jHEp3mgra9EeHnVSQLjZeW71/E9XZEf21lhsl8pgdhabdO6muKS8RM9veSU8SG+
U1tkurlEgK438koNpWPlj36dsah1ztA1Dql58BPT8WqCLomJx4quw1pOe5q7l8gJ
t0+rNbLP2gFpY2Cohl6nvKUa9DtsjqIXcDlx3T9IFquBj72fddTYkuiEpwNFQxXZ
mY7jI+ZA/hzLL6JFFUUptvzxFgbXpjspVVV/uDvne2ifoJXZC8jr8SLH96Oj7zWC
y05GN0IridZJuJNLULVhnymz9G8KBBHlZ4G9BHivyd//t3g4/GCHyAU32yyy5bs0
Y4gDwP/03i+Z/biNPcN8eckdaXrepDpDBcXudwMqj1XozQR/T/k=
=Mdyp
-END PGP SIGNATURE-

Bug#1041889: linux-image-6.4.0-1-amd64: Boot fails after GRUB shows loading initrd (encrypted XFS /root, unencrypted /boot, EFI)

[Alvin Cheung]

Package: linux-image-6.4.0-1-amd64
Severity: important
X-Debbugs-Cc: ayhche...@gmail.com

Dear Maintainer,

-- Additional system details:
Debian Sid installed on an EFI system (with separate unencrypted ext4 /boot and 
encrypted XFS /root)

-- How to reproduce:
Upgrade kernel from 6.3 to 6.4 and reboot

-- Expected behaviour:
System boots as normal (Plymouth shows password prompt for encrypted /root)

-- Actual behaviour:
GRUB2 shows system loading initrd (as normal)
Blank screen with blinking cursor (not normal)
No password prompt for encrypted XFS /root

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

Kernel: Linux 6.3.0-2-amd64 (SMP w/16 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 linux-image-6.4.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20230519-1
ii  linux-base  4.9

Versions of packages linux-image-6.4.0-1-amd64 recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.4.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.06-13
pn  linux-doc-6.4   

Bug#1041888: rust-bs58: please upgrade to v0.5

[Jonas Smedegaard]

Source: rust-bs58
Version: 0.4.0-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade or separately provide newer upstream branch v0.5, needed
by rust-libp2p-identity (bug#1041861).

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+78AACgkQLHwxRsGg
ASFJTQ//S0VnW7oJNMg62qqXdGEWCLaGP+REWxj5ph3LzK8nJIxT02xj2ED5Lgin
otGe52aVLmTexmfINrdQGFUM1bIBMpJWeVz0FFLzvAQjvo2cXG+pkqZru0LLOYL1
Fgjti0N2ZFNAohzHGGcyy0KkMOIc/Co325NZTmpNNxaAhJHp/QJtCZk5Z+WF96if
nJHblGCzkZn4dgUOo3k488Kpb+J6Za63u0V+f+gcgaLK27AQRl2G9d1yoy+HGYUI
TGqIse2UE7E8lA0+8L2lRiHLnkHouKtv136PO0FuJw5sleks6oa1PR2UmfJ7wvVz
cKsnKOhwHIctUe8lThBWQ5b/ATD0Aw7Kue3MeeS9X1s4/jR6tRl5qUDWZjlBBh7x
almNsyK6W6Lu/ee3QZ8y0dvFwvVTwguJhmA5qImT5iLtNSp5DWVhuTyJ8r8PXE9X
Kw12mRovR/Aw4jSlkxV2FEoCbyQZ5nT0GQ+0mYdRhxkanYtFaHLXjNTcNbmKjWB3
KHxJz2394Bx/gW6MoCXC+JU4dfE2XNn87yTvVWEfmvlHUJjIQXbdgtVipl65a3q6
jdOsTZvoi1AjEtP3PoQNl0Ufainhp1UVgORliyMvViXoWSpTtpMp7mt6l43RGZQh
yoJwWp00wykkmVbI7L0jZwBzlbT1aLthMeFChQtNPWhvoKLAqow=
=s6jY
-END PGP SIGNATURE-

Bug#1041883: python3-astroid: please package version 2.15.6

[Sandro Tosi]

> Latest pylint fixes a few issues and requires astroid/2.15.4.

yep. i know

> As far as I know, the attached commits are ready for an upload to
> unstable.

please do not submit patches to packages via email like this, either
open an MR or just nothing at all, i can update a package


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1041886: rust-unsigned-varint: please upgrade to v0.7

[Jonas Smedegaard]

Source: rust-unsigned-varint
Version: 0.5.1-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade or separately provide newer upstream branch v0.7, needed
by rust-multiaddr (bug#1041880).

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+6r0ACgkQLHwxRsGg
ASFWNQ/+OXgbwHzgdqZ6k+4GcnUAd3K9hsyf2FFJWFV3yMiBW5YzBXfZZufcj5Qs
Np2Tw/NAPOsmsZdijml1LY7iz6yJf0fwD1bQUEEKxAZVEw/4hNCQTSQ+T9m8xipz
Ek2zvtalMHBR+ATDoUwqXOTyEKL5mjSTExmeb9XZOk6h/TjUfZzASYT+2Qo+y/nw
Dh+BLjmCs7vGsv5bjJggRRpuqEIg2hg4Hp+E0rBXpDrPpCb7mSGlIGJDj9pjXXKd
Q0EPBNmumXYeibnQ9WY5mwFfPHHJ1vju0fiS/Sdi94rpfkqylUcqZxNlGvjBD8Rf
sL0PPacUPKTUacjxocOW21XkLNeuXRjn4rBYaWKMk6Rw0TXgh30GATM6XT0QgZg6
765IQZzDdSEu3qPSTpgIg/cXJA0OUAs4l297M1uNY0OSqFqVYKKU/Zc9IxQmH5vI
Nf2mEBQnTE0K/DpT5mdOU92Wn0YqOk4nE6BzOFuJABkE9s6jnyy3Bj93k1zKO6N+
rzEy4bdKH10c2eBibEAKpVIJyz7nbCdfg+lDJxHNiEOptXPaEyx9b7y65W6iRlbg
bAg73RPdyTfe+5qTXpVm+m6iW1xzFjyVulWxaDR0M9Ax/xa7nbIPbQ3XjEeaOP88
NWmrkls9c26aSjYi0s57g2DIS6vdwiKWvKDR/2dtzWq5wxyz/q4=
=09c+
-END PGP SIGNATURE-

Bug#644005: pcsxr: FFVIII can't detect memory card

[Jérôme]

FWIW, I had the same problem with Suikoden and changing the BIOS to 
SCPH7003.bin as instructed in aforementioned link did the trick.


I know, not the same game and 7 years later, but I figured it was worth 
mentioning, and worth copying the BIOS name in this thread rather than 
relying on an external forum.


(Note that apparently, after changing the BIOS, one can't reload 
emulator state, so better do it right away before going too far in a 
game.)


--
Jérôme

Bug#1041885: rust-multihash: please upgrade to v0.19

[Jonas Smedegaard]

Source: rust-multihash
Version: 0.11.4-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade or separately provide newer upstream branch v0.19, needed
by rust-multiaddr (bug#1041880).

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+6bAACgkQLHwxRsGg
ASEERg//aXG5VbOZohbQOy9Fcbk2bs9zuH+i9omVE9XOOopVX3HWrch/HNXZW8ih
3W87Y6bRuUg/E4B/OpidUyOnJD3z91PgO7OjVojYxTpI2tZ2nj9VwLT2tDXjmI9B
QR/HaLC+QBGsKVAGwOoWqbNLKIwdigFfWg1ZPTIZnG0Hi/lZOqytb5LqtyjPPirq
NanqSShwGNTSVYngO3xygU7UKolBW3NJeKRJ6sUSk27XidCE3RbLfQrLH4wLIgh1
3iu6hh3+GkzSSiXwGUTMkmy1NEx84w0HiiIYVlRZuOofgi9e0BfXJCMFPOw8cTD7
GvBhUfGOGW94ysjWXiwsJpq4Uj+/M7e8owFmyPIcEFIawV9fN47FvBCewYqM29Ja
vzWwhg0F+wL2s4jwm+ReKzUnpJc0564iCf1qXS91yZYssVGW+blMhw7brAG3zoki
gSRjkenVsf2lpOpScLkwGndjTksxoKKjwiFwWpKBQA9nrz5wii8tVlGx+4c6ewO1
8ipXlHhHsr3y4xso1eRZDO+eWwFd0R7/+1Whch+D7qLobpFwEUv0ravlfP/dWWM/
RRXVq1LzfuQpTBfqjHvlhD6WZsXeL+XNCCgsOtEMhtE1BViFp9/ZxgWeq9jjm9by
jyM3yprw1DTelwstsjzljaGpNm9RpVGWS5L7vi/tO3qEYUKRifQ=
=rwkS
-END PGP SIGNATURE-

Bug#1041488: Please review patches for initial upload

[Elias Oltmanns]

Hi Tony,




Am 21. Juli 2023 um 08:08 schrieb tony mancill:
[...]
> I haven't uploaded yet because I am not yet sure how (or whether it is
> even necessary) to document the license and copyright of a few of the
> test resources.  In particular, these files:
> 
> Files: jwat-arc/src/test/resources/IAH-20080430204825-0-blackbook.arc
>jwat-arc/src/test/resources/IAH-20080430204825-0-blackbook.arc.gz
>jwat-gzip/src/test/resources/IAH-20080430204825-0-blackbook.warc
>jwat-gzip/src/test/resources/IAH-20080430204825-0-blackbook.warc.gz
>jwat-warc/src/test/resources/IAH-20080430204825-0-blackbook.warc
>jwat-warc/src/test/resources/IAH-20080430204825-0-blackbook.warc.gz

This seems to be the original source of those files:
https://archive.org/download/ExampleArcAndWarcFiles/
(See also https://archive.org/details/ExampleArcAndWarcFiles)

> 
> For which the decopy [2] utility generates a very messy copyright
> entry that ends with:
> 
> License: CC-BY-NC-SA-ND-3 or Expat or GPL or LGPL-2.1+
> 
> It's conceivable that these WARC [3] files contain copyrighted materials
> and that uploading them as components of the source package would be
> considered redistribution, but I am admittedly not well-versed enough in
> this area to say for sure without looking into the contents in more
> detail.

Opening IAH-20080430204825-0-blackbook.warc in an editor reveals
that it contains a webcrawl of archive.org (or part of it). It does
include many files of different formats and media types partly carrying
their own license information. This is why decopy lists so many
different licenses.

There might be false positives, though. This is because the warc file
contains web pages listing details about other resources including
license information. At least some of those resources are not included
in the warc file themselves, so the license might actually not be
applicable to any material in the warc file.

Passing the term "-nd" to the editor's search function produces good
examples. The first occurrence appears on a site providing details about
some podcast which is licensed CC-BY-NC-ND. The podcast itself, however,
is not part of the warc file. Unfortunately, there are quite a few
matches of "-nd" that would need checking and I haven't worked out a
good approach to make this actually feasible. Here is one interesting
observation though:

$ grep -ae "^Content-Type:" IAH-20080430204825-0-blackbook.warc \
| cut -d' ' -f2 | sort | uniq
application/http;
application/warc-fields
application/x-javascript
application/x-shockwave-flash
image/gif
image/jpeg
image/png
text/anvl
text/css
text/dns
text/html
text/html;
text/plain
text/plain;
text/xml

In particular, a lot of Content-Types are missing from this list in
relation to the resources mentioned as being licensed under some
CC-BY-ND license.

Since this is from archive.org, their terms of service apply:
https://archive.org/about/terms.php

This might turn out to be a bit to restrictive for DFSG, since it
includes this passage:
Access to the Archive’s Collections is provided at no cost to you
and is granted for scholarship and research purposes only.

It makes sense for them to take this rather defensive approach since
they provide a lot of content from different sources. On the other hand,
the warc file appears to be intentionally prepared for testing and demo
purposes and uploaded by someone at archive.org. That is why I had hoped
for a more permissive license, but could not find any indication of it.

> 
> It would be nice to be able to (a) use the files as-is so that we
> don't have to either (b) remove the files and disable tests, or (c)
> replace the files and rewrite the tests that access them. I
> spot-checked a few tests and they appear to expect to be able to
> locate specific contents in the archive, so (c) would be non-trivial
> and could result in the package being quite difficult to maintain over
> time, since any upstream changes to those tests would require updating
> the patch(es).
> 
> Let me know if you have any thoughts on this.  Otherwise, I will follow
> up once I have a chance to look through the test resources in more
> detail.

Contacting archive.org and asking for license clarification might be an
option. I am not sure whether I would hold my breath, but it seems to me
that removing the files in question might turn out to be the only
alternative. Then again, we could disable the test suite, after all, so
the build would not depend on the presence of those files.

Woud do you thin?

Best wishes,

Elias

> 
> Thank you, tony
> 
> [1] https://salsa.debian.org/java-team/libjwat-java
> [2] https://tracker.debian.org/pkg/decopy
> [3] https://www.loc.gov/preservation/digital/formats/fdd/fdd000236.shtml
> 

Bug#1040679: bullseye-pu: package node-dottie/2.0.2-4+deb11u1

[Adam D. Barratt]

On Mon, 2023-07-24 at 21:27 +0100, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Sun, Jul 09, 2023 at 09:11:26AM +0400, Yadd wrote:
> > [ Reason ]
> > node-dottie is vulnerable to prototype pollution (#1040592,
> > CVE-2023-26132)
> 
> By all means go ahead, but it can't be accepted until the situation
> in
> testing is fixed up (unless we propogate the version from
> bookworm-proposed-updates to testing).
> 

The provided diff appears to be against the package in bookworm.
bullseye has 2.0.2-1.

Regards,

Adam

Bug#1041884: Acknowledgement (sct: segfault at e0)

[Alejandro Colomar]

Never mind.  My filesystem was full.  That was my problem.  I wrote
a program with an accidental infinite loop, and while debugging it,
a printf line started writing lines to somewhere in /opt, and I
forgot to kill it before writing 1 TB of garbage. :-)

Cheers,
Alex

On 2023-07-24 22:21, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1041884: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041884.
> 
> 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.
> 
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   alx.manpa...@gmail.com
> (after having been given a Bug report number, if it did not have one).
> 
> Your message has been sent to the package maintainer(s):
>  Jacob Adams 
> 
> If you wish to submit further information on this problem, please
> send it to 1041...@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.
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039708: bullseye-pu: package lua5.3/5.3.3-1.1+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Jun 28, 2023 at 02:22:21PM +0200, Guilhem Moulin wrote:
> lua5.3=5.3.3-1.1 (buster, bullseye) is vulnerable to CVE-2019-6706 and
> CVE-2020-24370.  These were fixed in an a recent buster-security upload
> (cf. DLA-3469-1).  The Security Team didn't think a DSA was warranted
> for bullseye, and suggested to go via bullseye-pu instead.

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041837: closed by René Engelhard (Re: Bug#1041837: libreoffice-draw: undeclared file conflict with libreoffice-impress-nogui <= trixie: /usr/lib/libreoffice/share/config/

[Rene Engelhard]

Control: found -1 4:7.5.4~rc1-1

Control: fixed -1 4:7.6.0~rc1-1


Am 24.07.23 um 19:27 schrieb Helmut Grohne:

Control: reopen -1
Control: found -1 4:7.5.5-2
Control: found -1 4:7.5.5~rc1-2

On Mon, Jul 24, 2023 at 08:09:07AM +, Debian Bug Tracking System wrote:

08:26 < helmut> _rene_: re libreoffice (short on time atm): seems like I messed 
something up, please close my report. (...)

Further context here. On IRC you also said that this was fixed in
experimental. 20:51  * _rene_ lost hope


What? I didn't say anything on IRC about this.

And I said experimental (NEW). I even pointed to libreoffice-uiconfig-* 
of 7.6 (-> NEW)



Also note that experimentals version is LOWER than sids.

So obviously "fixed in experimental" does not make any sense here otherwise.


In contrast *YOU* said it could be closed. I followed.



/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/sidebarslidebackground.ui
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/layoutlist.xml
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/objectlist.xml
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/styles.xml


All of those are in -draw *and* draw-nogui (and those two conflict, so OK).

That's where they belong (well, probably not needed in -nogui but anyway.)


What looks missing indeed is some Replaces, I bumped them to go sure 
hopefully.


And as said in 7.6 it's fixed since the uiconfig-impress package should 
have the correct Replaces:



Regards,


Rene

Bug#1040679: bullseye-pu: package node-dottie/2.0.2-4+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, Jul 09, 2023 at 09:11:26AM +0400, Yadd wrote:
> [ Reason ]
> node-dottie is vulnerable to prototype pollution (#1040592,
> CVE-2023-26132)

By all means go ahead, but it can't be accepted until the situation in
testing is fixed up (unless we propogate the version from
bookworm-proposed-updates to testing).

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1040677: bullseye-pu: package node-tough-cookie/4.0.0-2+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, Jul 09, 2023 at 08:34:39AM +0400, Yadd wrote:
> [ Reason ]
> node-tough-cookie is vulnerable to prototype pollution

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1006294: bullseye-pu: package knewstuff/5.78.0-4

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Feb 22, 2022 at 10:48:45PM +0100, Patrick Franz wrote:
> [ Reason ]
> A bug in plasma-discover causes a Denial of Service attack
> against the KDE servers. 3 packages needs to be patch to
> mitigate the attack: knewstuff, plasma-desktop and
> plasma-discover.
> This update fixes bug #1006126 for bullseye and has been 
> fixed in unstable in version 5.90.0-1 for knewstuff.

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1007787: bullseye-pu: package adduser/3.118

[Marc Haber]

Hi,

Here are the requested debdiffs against oldstable. The debdiff against
stable would be huge, do you reall want to see this?

Unfortunately, the debian/rules in oldstable rebuilds the po and pot
files which enhances the source-debdiff grotequely. I think it is still
the better idea to go ahead with the unalteres build process instead of
messing with debian/rules in an oldstable point release. Let me know if
you want it differently, and also let me know if you want the changes
done automatically in the build process in the changelog as well.

 [ Checklist ]
   [ ] *all* changes are documented in the d/changelog
   [X] I reviewed all changes and I approve them
   [X] attach debdiff against the package in (old)stable
   [X] the issue is verified as fixed in unstable

Greetings
Marc

diff -Nru adduser-3.118/debian/changelog adduser-3.118+deb11u1/debian/changelog
--- adduser-3.118/debian/changelog  2018-09-15 21:12:39.0 +0200
+++ adduser-3.118+deb11u1/debian/changelog  2023-07-24 22:12:52.0 
+0200
@@ -1,3 +1,10 @@
+adduser (3.118+deb11u1) bullseye; urgency=medium
+
+  * fix command injection vulnerability in deluser
+(Closes: #940577)
+
+ -- Marc Haber   Mon, 24 Jul 2023 22:12:52 
+0200
+
 adduser (3.118) unstable; urgency=low
 
   * Team upload
diff -Nru adduser-3.118/debian/po/ar.po adduser-3.118+deb11u1/debian/po/ar.po
--- adduser-3.118/debian/po/ar.po   2018-09-15 21:12:39.0 +0200
+++ adduser-3.118+deb11u1/debian/po/ar.po   2023-07-24 22:12:52.0 
+0200
@@ -17,7 +17,7 @@
 msgstr ""
 "Project-Id-Version: adduser 3.104\n"
 "Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
-"POT-Creation-Date: 2018-09-15 15:13-0400\n"
+"POT-Creation-Date: 2023-07-24 22:13+0200\n"
 "PO-Revision-Date: 2016-06-17 18:06+0200\n"
 "Last-Translator: Ossama M. Khayat \n"
 "Language-Team: Arabic \n"
diff -Nru adduser-3.118/debian/po/be.po adduser-3.118+deb11u1/debian/po/be.po
--- adduser-3.118/debian/po/be.po   2018-09-15 21:12:39.0 +0200
+++ adduser-3.118+deb11u1/debian/po/be.po   2023-07-24 22:12:52.0 
+0200
@@ -7,7 +7,7 @@
 msgstr ""
 "Project-Id-Version: adduser_3.105_templates\n"
 "Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
-"POT-Creation-Date: 2018-09-15 15:13-0400\n"
+"POT-Creation-Date: 2023-07-24 22:13+0200\n"
 "PO-Revision-Date: 2007-10-14 15:04+0300\n"
 "Last-Translator: Pavel Piatruk \n"
 "Language-Team: Belarusian \n"
diff -Nru adduser-3.118/debian/po/ca.po adduser-3.118+deb11u1/debian/po/ca.po
--- adduser-3.118/debian/po/ca.po   2018-09-15 21:12:39.0 +0200
+++ adduser-3.118+deb11u1/debian/po/ca.po   2023-07-24 22:12:52.0 
+0200
@@ -7,7 +7,7 @@
 msgstr ""
 "Project-Id-Version: adduser 3.112+nmu1\n"
 "Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
-"POT-Creation-Date: 2018-09-15 15:13-0400\n"
+"POT-Creation-Date: 2023-07-24 22:13+0200\n"
 "PO-Revision-Date: 2010-10-23 12:59+0200\n"
 "Last-Translator: Jordi Mallach \n"
 "Language-Team: Catalan \n"
diff -Nru adduser-3.118/debian/po/cs.po adduser-3.118+deb11u1/debian/po/cs.po
--- adduser-3.118/debian/po/cs.po   2018-09-15 21:12:39.0 +0200
+++ adduser-3.118+deb11u1/debian/po/cs.po   2023-07-24 22:12:52.0 
+0200
@@ -15,7 +15,7 @@
 msgstr ""
 "Project-Id-Version: adduser 3.104\n"
 "Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
-"POT-Creation-Date: 2018-09-15 15:13-0400\n"
+"POT-Creation-Date: 2023-07-24 22:13+0200\n"
 "PO-Revision-Date: 2016-06-17 18:05+0200\n"
 "Last-Translator: Miroslav Kure \n"
 "Language-Team: Czech \n"
diff -Nru adduser-3.118/debian/po/da.po adduser-3.118+deb11u1/debian/po/da.po
--- adduser-3.118/debian/po/da.po   2018-09-15 21:12:39.0 +0200
+++ adduser-3.118+deb11u1/debian/po/da.po   2023-07-24 22:12:52.0 
+0200
@@ -8,7 +8,7 @@
 msgstr ""
 "Project-Id-Version: adduser 3.112+nmu2\n"
 "Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
-"POT-Creation-Date: 2018-09-15 15:13-0400\n"
+"POT-Creation-Date: 2023-07-24 22:13+0200\n"
 "PO-Revision-Date: 2016-06-17 18:07+0200\n"
 "Last-Translator: Joe Hansen \n"
 "Language-Team: Danish  \n"
diff -Nru adduser-3.118/debian/po/el.po adduser-3.118+deb11u1/debian/po/el.po
--- adduser-3.118/debian/po/el.po   2018-09-15 21:12:39.0 +0200
+++ adduser-3.118+deb11u1/debian/po/el.po   2023-07-24 22:12:52.0 
+0200
@@ -16,7 +16,7 @@
 msgstr ""
 "Project-Id-Version: adduser 3.51\n"
 "Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
-"POT-Creation-Date: 2018-09-15 15:13-0400\n"
+"POT-Creation-Date: 2023-07-24 22:13+0200\n"
 "PO-Revision-Date: 2016-06-17 18:03+0200\n"
 "Last-Translator: Konstantinos Margaritis \n"
 "Language-Team: Greek \n"
diff -Nru adduser-3.118/debian/po/es.po adduser-3.118+deb11u1/debian/po/es.po
--- adduser-3.118/debian/po/es.po   2018-09-15 21:12:39.0 +0200
+++ adduser-3.118+deb11u1/debian/po/es.po   2023-07-24 22:12:52.0 
+0200
@@ -24,7 +24,7 @@
 msgstr ""
 "Project-Id-Version: 

Bug#1041884: sct: segfault at e0

[Alejandro Colomar]

Package: sct
Version: 1.3-1+b1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi!

I'm not sure if this is a problem with sct(1), but I got an error that
mentions sct, so I'm reporting here in case it's related to sct(1).

Here's the error message as reported by dmesg:

$ sudo dmesg | tail -n2
[  432.416640] sct[3477]: segfault at e0 ip 555a975ee0fd sp 
7ffe887af340 error 4 in sct[555a975ee000+1000] likely on CPU 1 (core 1, 
socket 0)
[  432.416669] Code: 2f 00 00 66 90 00 00 00 00 00 00 00 00 41 57 41 56 41 55 
49 89 f5 41 54 55 53 89 fb 31 ff 48 83 ec 28 e8 86 ff ff ff 48 89 c5 <48> 63 80 
e0 00 00 00 48 89 ef 48 c1 e0 07 48 03 85 e8 00 00 00 48

My computer got a black screen where the only thing I could do is
REISUB.  It had a few problems booting after that for a few times.  I'm
still unsure about the cause, but this is the most notable error report
I've seen.

I have `sct 3000` in my .bash_aliases, so that just by opening a
terminal I get a nice screen temperature.  It has worked for a long
time...

Cheers,
Alex


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
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 sct depends on:
ii  libc6   2.37-6
ii  libx11-62:1.8.6-1
ii  libxrandr2  2:1.5.2-2+b1

sct recommends no packages.

sct suggests no packages.

-- no debconf information

Bug#1041882: dh_installchangelogs: probable typo in search for upstream changelog

[Nicolas Boulenguez]

Package: debhelper
Version: 13.11.4
Severity: minor
Tags: patch

Hello.

I suspect a missing dollar character in dh_installchangelog.
Sorry for the noise if this is some deliberate Perl black magic.

--- a/dh_installchangelogs
+++ b/dh_installchangelogs
@@ -148,7 +148,7 @@
foreach my $suffix ('', qw(.txt .md .rst)) {
foreach my $name (qw{changelog changes history}) {
my @matches=grep {
-   lc basename($_) eq "$name$suffix" && -f $_ && 
-s _ && ! excludefile($_)
+   lc basename($_) eq "$name$suffix" && -f $_ && 
-s $_ && ! excludefile($_)
} @files;
if (@matches) {
return shift(@matches);

Bug#1041881: RM: winwrangler -- RoQA; depends on gtk2; low popcon

[Bastian Germann]

Source: winwrangler
Severity: serious

Please consider removing winwrangler. I guess there is no real use for it 
anymore.
I am going to reassign this to the FTP Masters if nobody reacts within a month.

Bug#1041160: linux-image-6.3.0-2-amd64: no pairing with 6.3.0.1 possible

[Dietmar Czekay]

#1 SMP PREEMPT_DYNAMIC Debian 6.4.4-1 (2023-07-23) brings no change in 
the pairing behavior:



Jul 24 21:36:24 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:27 debian kernel: rtw_8821ce :03:00.0: failed to send 
h2c command
Jul 24 21:36:27 debian kernel: Bluetooth: hci0: unexpected event for 
opcode 0xfc19
Jul 24 21:36:27 debian kernel: Bluetooth: hci0: unexpected event for 
opcode 0x2016
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected cc 0x0c7c 
length: 1 < 3
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x06 from d1:cf:2f:cf:76:28
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x07 from d1:cf:2f:cf:76:28
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x08 from d1:cf:2f:cf:76:28
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x09 from d1:cf:2f:cf:76:28
Jul 24 21:36:28 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:32 debian bluetoothd[789]: src/service.c:service_accept() 
input-hog profile accept failed for D1:CF:2F:CF:76:28
Jul 24 21:36:33 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:36 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:39 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:41 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:46 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:48 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:51 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:52 debian plasmashell[2010]: kf.bluezqt: PendingCall Error: 
"Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy 
blocked the reply, the reply timeout expired, or the network connection 
was broken."
Jul 24 21:36:53 debian kernel: rtw_8821ce :03:00.0: firmware failed 
to leave lps state
Jul 24 21:36:54 debian bluetoothd[789]: 
src/device.c:set_wake_allowed_complete() Set device flags return status: 
Invalid Parameters



I tested the new kernel with sid

On 24.07.23 10:16, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

Hi,

On Wed, Jul 19, 2023 at 10:26:30PM +0200, Dietmar Czekay wrote:

I checked different versions. Here are the results:

beginning right after clicking "add device" until the device manager says
"not able to pair"

Just Debian 6.1.37-1 works.

#1 SMP PREEMPT_DYNAMIC Debian 6.3.11-1 (2023-07-01)

6.4.4-1 was uploaded to unstable in meanwhile, you might be able to
check against the newer version as well?

Regards,
Salvatore

Bug#1041880: ITP: rust-multiaddr -- composable and future-proof network addresses

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-multiaddr
  Version : 0.18.0
  Upstream Contact: Friedel Ziegelmayer 
* URL : https://github.com/multiformats/rust-multiaddr
* License : Expat
  Programming Lang: Rust
  Description : composable and future-proof network addresses

 multiaddr is a library implementing the "multiaddr" format,
 aiming to make network addresses future-proof,
 composable, and efficient.

This package is required by safe-network (bug#1008016).
It will be maintained in the collaborative debian section of salsa, at
.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+0WoACgkQLHwxRsGg
ASH6fw//dxQmpl4IPihgTOSW5bev3xjs/4ANsyh4jG+D9kf3uxlQE5xhDZgR5IZT
VUFpZjZcY7mGiq8tvdOlOKAT0cL2fm9WqqmwWcfUVJIa1Z3wCoO4B61OVHr4Xipx
kKMcKwbCrWlumJXJWy6r+/1bB+Q94NNZWWGc3/MYOPOg8XnJiArYd3n/lUfEsA75
p0hGRsgcgMk+EQRdZvL9n25UPK+daU42gj8nTl5s8fBTRyxwYmd+2hE36euGCWni
wjF2zqzlWQGtVGqfvBU1suXM+MSqOuR12lVCNIPRiAw8UCAmnI8WIMDUe9NQpabc
MjQMmtzZwGQ5cx4cP7U2TpbDVhbW8UqAw25PFbrony4UXAeGvZPGgdi3RcyFk1+C
V8oj9NC2xIDa2OAde4/g0jkykWrMBIeUVh+yisare+o9AwrjBGqp/BDSPLD4qQEq
uNJl7EXGBYxgFZw+tXrmKhJ+UDqUwwoZ2NrdleVYZLJT0zdBKtGQRik6CpcNNzyT
u9zksOsaHciIPOBJ01RzVaROGWxDluWArYAArdNp8B295DmaP3L3C/nSR3aHxOx/
qIl21iy/g5PBSqtvC3Oull9eKfqskN2cjgVUg/RsRkuvIs+iN3KFXjkESjpfs9l/
EttnK4aiWMv9+mD+RiDI0mQRHI2VdLe45g8vLRE65lw+Oqi8ksg=
=Kttr
-END PGP SIGNATURE-

Bug#1041879: rust-quick-protobuf: please upgrade to v0.8.1

[Jonas Smedegaard]

Source: rust-quick-protobuf
Version: 0.7.0-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrasde to v0.8.1, needed by rust-libp2p-identity (bug#1041861).

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+zCgACgkQLHwxRsGg
ASHloQ/9F4qfzn5+uDjRKEk4FfjAlOYiMIGj8HVWB8TDFJtPYFm5yOx8jBbJRl3c
37PhkSQHZqy8Gtx+bJ/nrwUSpE+jSV75Zz4DWALUAJApcwaD/cTV3G7sPdeGizHB
HbkSX3iqthy5L0dmwhRACU2xBq/L0C9ckIR+t22fNwEOXNPSA8WKb51q2zWryGrw
NTDK3JE4E0wEU1K8gCQr18VssoyCUbt8vRP2+TcQrzHPLDT5gYlUFo3boXQZxFp5
9aGkoaG9xvj3fKUp+N3tRKIsOUVHD/sXJsybscbmIpAjEylAjFRsRuPfoGIdhbjV
RLOYGPvAuY7sTok4XgF55fAhRcc+eite625cOlQ2HN2s05vLZMf9q4vq68P3jHRp
09gkkWi+ze4EKKi5wkrxE5llK2F8/MmE2MZr2w9L3QMFTjzHM3pJS/1HD2xAjMxI
ZyLBEUpfOEMw1toLBkAPfDdHdhe1E1uetq2sWS5G84sfWTsrtSjq2iJq51aPQ83M
ArFq9NdJ8SdqSDy6nzdTrMuu9RYEfoHNbOx7w1KHu+LZ4Vnb/LEdsIkJphrnvj4E
ylw8sCcSKYHmEl4h9uOA5CFB+Qv6YMtsgJhNqWh0Zv8+MwLf+HVNrpeoHalagkCk
Se71VFa/rcTkPe6X9Zj9LgEMg2Y3kwja7GURIu5Y71TU40GPMjk=
=aEal
-END PGP SIGNATURE-

Bug#1041878: syntax error in crontab(1)

[Yuri D'Elia]

Package: systemd-cron
Version: 1.16-1
Severity: important

% crontab
  File "/usr/bin/crontab", line 106
if (not len(job.timespec_month)
   ^
SyntaxError: '(' was never closed

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

Kernel: Linux 6.4.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd-cron depends on:
ii  cron-daemon-common  3.0pl1-162
ii  libc6   2.37-6
ii  python3 3.11.4-5
ii  systemd [systemd-sysusers]  254~rc2-3
ii  systemd-sysv254~rc2-3

systemd-cron recommends no packages.

Versions of packages systemd-cron suggests:
ii  dma [mail-transport-agent]  0.13-1+b1

Bug#1041877: adduser: [INTL:nl] Dutch translation for the adduser package's documentation

[Frans Spiesschaert]

 
 
Package: adduser 
Severity: wishlist 
Tags: l10n patch 
 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the adduser package's 
documentation. A draft has been posted to the debian-l10n-dutch mailing
list allowing for review. 
Please add it to your next package revision. 
It should be put as "doc/po4a/po/nl.po" in your package build tree. 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1041722: steam is incompatible with libgudev 238-2

[Simon McVittie]

On Sat, 22 Jul 2023 at 20:21:22 +0200, Felix Zielcke wrote:
> As soon as it enters testing more people are affected

steam-installer is at the same version in testing and unstable, and even
if it wasn't, holding back its migration with a RC bug wouldn't prevent
this crash, because the important parts of Steam auto-update themselves.

I'm surprised that you're seeing this crash, because it seems you already
have the factors that were mentioned in the upstream bug as potential
workarounds: libnm0:i386 is installed, and so is libudev0:i386.

Are these things that you installed as a (successful) workaround, but were
not present at the time that you saw the crash you're reporting?

If those have not been successful workarounds, some other packages you
could try installing (most likely solution first) are:

- libusb-1.0-0:i386
- libudev0:amd64
- libnm0:amd64
- libusb-1.0-0:amd64

Thanks,
smcv

Bug#1041876: nix FTBFS on !amd64

[Adrian Bunk]

Source: nix
Version: 2.16.1+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=nix=2.16.1%2Bdfsg-1

...
src/libcmd/repl.cc:18:10: fatal error: editline.h: No such file or directory
   18 | #include 
  |  ^~~~
compilation terminated.

Bug#1041875: isc-kea: [INTL:nl] Dutch translation of debconf templates

[Frans Spiesschaert]

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

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1041874: debian-edu-router: [INTL:nl] Dutch translation of debconf templates

[Frans Spiesschaert]

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

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1036811: bullseye-pu: package ncurses/6.2+20201114-2+deb11u2

[Sven Joachim]

On 2023-07-24 18:37 +0100, Jonathan Wiltshire wrote:

> Control: tag -1 confirmed
>
> On Fri, May 26, 2023 at 08:51:55PM +0200, Sven Joachim wrote:
>> I would like to address CVE-2023-29491[1] aka bug #1034372[2] in
>> Bullseye.  The changes are the same as in version 6.4-3 (see
>> #1035351[3]), except that there is no need to patch configure.in this
>> time.
>
> Please go ahead.

Thanks, uploaded.

Cheers,
   Sven

Bug#1041873: mdadm: [INTL:nl] Dutch translation of debconf templates

[Frans Spiesschaert]

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

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1041872: command-not-found: Problem with user permission

[robert]

Package: command-not-found
Version: 23.04.0-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Installing "command-not-found" using aptitude, enabling it in /etc/bashrc, and
misspelling a command. A warning was displayed:

"WARNING:root:could not open file
'/etc/apt/sources.list.d/DebianRepositories.sources': Unable to parse section
data".

Nothing else.

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

Searching the DBTS provided information about similar behaviors (#965020,
#1021953), but specially #966307 because to be able to make it work the same
non-sense steps described there must be taken. A similar solution can be found
at StackExchange [1].

1) According to the documentation of "command-not-found"[2], issuing "update-
command-not-found(8)" must create a list of programs from whatever is at
/var/cache/apt/apt-file/. It did nothing, not even an error, because there was
nothing there.

2) Therefore, apt-file(1) must be executed manually as "root" user! Even when
it is a normal user command (again, according to its documentation man page):

~$ LANG=C apt-file update
Reading package lists... Done
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission
denied)
E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13:
Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches
(13: Permission denied)

3) After the previous step, and issuing another "update-command-not-found"
(also as root), the database of programs appears at /var/lib/command-not-found/
as described in [1] and [2]. However, the directory /var/cache/apt/apt-file
still does not exist. So, what will happen the next time "update-command-not-
found" is issued?

4) Currently, when misspelling a command in a CLI, the warning about not being
able to open the sources.list file is still displayed.

~$ LANG=C datE


WARNING:root:could not open file
'/etc/apt/sources.list.d/DebianRepositories.sources': Unable to parse section
data

Command 'datE' not found, did you mean:
  command 'dat' from deb liballegro4-dev
  command 'date' from deb coreutils
Try: apt install 

I do not really know whether the permission of the user play any role in the
crazy behavior of the "command-not-found" tool. However, the fact of getting a
warning about not being able to access a file usually available (mode 644)
every time I misspelled a command was the cause of investigating it.

As a user, I think this is too much trouble.

Anyway, I take advantage of the message to thank you in advance for your work
and help.

Regards, robert

[1] https://unix.stackexchange.com/questions/585107/debian-command-not-found-
error-local-variable-cnf-referenced-before-assignme

[2] /usr/share/doc/command-not-found/README.Debian

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


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 command-not-found depends on:
ii  apt-file 3.3
ii  lsb-release  12.0-2
ii  python3  3.11.4-5
ii  python3-apt  2.6.0

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

-- no debconf information

Bug#1041871: bolt: collision with the former bolt package

[Daniel Vacek]

Package: bolt
Version: 1:16.0-57~exp2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: neel...@gmail.com

The new dependency package from llvm-defaults steals the name from the old
thunderbolt package.

Bug#1041870: slic3r-prusa FTBFS on i386

[Adrian Bunk]

Source: slic3r-prusa
Version: 2.6.0+dfsg-1
Severity: serious
Tags: ftbfs patch
Forwarded: https://github.com/prusa3d/PrusaSlicer/pull/11036

https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=i386=2.6.0%2Bdfsg-1=1690032193=0

...
/<>/src/libslic3r/Format/AnycubicSLA.cpp:327:15: error: no 
matching function for call to ‘crop_value(float_t&, float, float)’
  327 | crop_value(h.delay_before_exposure_s, 0.0f, 1000.0f);
  | ~~^~
/<>/src/libslic3r/Format/AnycubicSLA.cpp:219:24: note: candidate: 
‘template void Slic3r::{anonymous}::crop_value(T&, T, T)’
...


Two fixes are required for fixing the build on i386
(and likely also some non-release 32bit architectures).

1. The patch from the pull request above, and

2. the following change:

--- debian/rules.old2023-07-24 15:36:20.941771419 +
+++ debian/rules2023-07-24 15:36:43.133759741 +
@@ -5,7 +5,7 @@
 # less debug info to avoid running out of address space
 ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
export DEB_CXXFLAGS_MAINT_APPEND += --param ggc-min-expand=5 -g0
-else ifneq (,$(filter $(DEB_HOST_ARCH), armhf))
+else ifeq ($(DEB_HOST_ARCH_BITS), 32)
export DEB_CXXFLAGS_MAINT_APPEND += -g1
 endif
 

Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux

[Daniel Gröber]

Hi Paul,

good to know there's other people in Debian that care about IPv6 :)

On Mon, Jul 24, 2023 at 10:26:03AM -0400, Paul Tagliamonte wrote:
> As a current jool user, I'm very interested in this project. I'll have
> to try this out.

I haven't actually tried it yet myself, I tend to package first -- test and
use later :D

So let me know if you do would love to hear a report.

> > Hence we need more alternatives for these services in Debian.
> > 
> > tundra-nat64 is a new userspace implementation of SIIT, NAT64 and
> > [CLAT]. It's multithreaded as opposed to tayga so my hope is the
> > performance will be much better.
> > 
> > I plan on maintaining tuntra-nat64 myself but I do need a sponsor :)
> 
> Why the heck not, I'm happy to review and sponsor; IPv6 adoption is
> critical, and giving a hand to someone working to maintain current
> tooling to help with the adoption is doing good work. Hit me up off-list
> and we'll work out a workflow and all that.

Excellent. I'll hit you up with a (gbp) package as soon as I get around to
it. Doesn't look very involved at first glance.

FYI: I have another ITP pending for VPP (fdio-vpp) -- a very, very, very
fast userspace packet processor (DPDK based) which also has SIIT/NAT64
support, but not fully featured last I checked.

Might be interesting to you too. I just never got around to actually
deploying VPP in my test network since my use-case for 10/40G routing/NAT64
dissapated so I never finsihed the package. It's about to come back though
so stay tuned :)

Thanks,
--Daniel

Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux

[Andrej Shadura]

Hi,

On Mon, 24 Jul 2023, at 16:16, Daniel Gröber wrote:
> tundra-nat64 is a new userspace implementation of SIIT, NAT64 and
> [CLAT]. It's multithreaded as opposed to tayga so my hope is the
> performance will be much better.
>
> I plan on maintaining tuntra-nat64 myself but I do need a sponsor :)

As the maintainer of tayga, I’ll be happy to sponsor tundra too :)

-- 
Cheers,
  Andrej

Bug#1013893: bullseye-pu: package rhonabwy/0.9.13-3+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, Jun 26, 2022 at 05:36:42PM -0400, Nicolas Mora wrote:
> [ Reason ]
> Fix possible buffer overflow when decrypting forged jwe with invalid iv or
> cypherkey

Please go ahead, mentioning the CVE number in the changelog.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1007787: bullseye-pu: package adduser/3.118

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Wed, Mar 16, 2022 at 07:25:44PM +0100, Marc Haber wrote:
> This is my first try to do a stable upload. Since adduser is a vital
> package, but my time is rather limited at the moment, I would like to
> know whether this fix is acceptable for stable before I prepare an
> actual package. Also, the fix suggested for stable is not the same fix
> that is in place in unstable and testing (that one also fixes the broken
> functionality and adds more safety).

Yes it is, but I'd prefer to see a proposed debdiff against stable before
approving. Could you prepare one please?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1036811: bullseye-pu: package ncurses/6.2+20201114-2+deb11u2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, May 26, 2023 at 08:51:55PM +0200, Sven Joachim wrote:
> I would like to address CVE-2023-29491[1] aka bug #1034372[2] in
> Bullseye.  The changes are the same as in version 6.4-3 (see
> #1035351[3]), except that there is no need to patch configure.in this
> time.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041837: closed by René Engelhard (Re: Bug#1041837: libreoffice-draw: undeclared file conflict with libreoffice-impress-nogui <= trixie: /usr/lib/libreoffice/share/config/

[Helmut Grohne]

Control: reopen -1
Control: found -1 4:7.5.5-2
Control: found -1 4:7.5.5~rc1-2

On Mon, Jul 24, 2023 at 08:09:07AM +, Debian Bug Tracking System wrote:
> 08:26 < helmut> _rene_: re libreoffice (short on time atm): seems like I 
> messed something up, please close my report. (...)

Further context here. On IRC you also said that this was fixed in
experimental. In reality, it is not.

libreoffice-draw version 4:7.5.5-2 (unstable) and 4:7.5.5~rc1-2
(experimental) contain the following files.

/usr/lib/libreoffice/share/config/soffice.cfg/simpress/layoutlist.xml
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/objectlist.xml

These are also contained in libreoffice-impress-nogui version 4:7.4.7-1
(bookworm and trixie). There is no Conflicts nor Replaces relation nor
is there any diversion.

As such, this is a serious bug.

Do you see any mistake in this analysis?

There is another conflict. libreoffice-draw-nogui version 4:7.5.5-2
(unstable) and 4:7.5.5~rc1-2 (experimental) contain the following files.

/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/sidebarslidebackground.ui
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/layoutlist.xml
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/objectlist.xml

These are also contained in libreoffice-impress version 4:7.4.7-1
(bookworm and trixie).

Furthermore, the latter two are also contained in
libreoffice-impress-nogui versoin 4:7.4.7-1 (bookworm and trixie).
Again, there is no Conflicts nor Replaces relation nor any diversion
that would prevent an unpack error.

Again, is there any mistake in this analysis?

Helmut

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Otto Kekäläinen]

Changes done and pending CI to validate that there are no unintended
side effects:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/52

Bug#990028: /usr/bin/mogrify-im6.q16: raw support requires ufraw-batch which is no longer in Debian

[Darshaka Pathirana]

Hi,

On Fri, 03 Sep 2021 22:00:12 + Debian FTP Masters 
 wrote:
> Source: imagemagick
> Source-Version: 8:6.9.12.20+dfsg1-1
> Done: Bastien Roucariès 

If just stumbled over this:

  ❯ identify -format "%f: %wx%h\n" "DSC_0597.NEF"
  identify-im6.q16: delegate failed `'ufraw-batch' --silent --create-id=also 
--out-type=png --out-depth=16 --output='%u.png' '%i'' @ 
error/delegate.c/InvokeDelegate/1966.
  identify-im6.q16: unable to open image 
`/tmp/magick-vD_smqp7YJHGABZ2bxgam6OJlqxQ5NMN.ppm': No such file or directory @ 
error/blob.c/OpenBlob/2924.

I am still running Debian/bullseye, but as far as I can see version 
6.9.12.20+dfsg1-1 is only in experimental.
Any plans to bring it to unstable?

Apart from that, imagemagick-6.q16 + imagemagick-6.q16hdri do still have 
"Suggests: ufraw-batch"[1][2].
This should be removed.

[1] 
https://salsa.debian.org/debian/imagemagick/-/blob/debian/lastest/debian/control?ref_type=heads#L200
[2] 
https://salsa.debian.org/debian/imagemagick/-/blob/debian/lastest/debian/control?ref_type=heads#L411

And finally: is there a workaround for this problem, as Debian/bullseye + 
bookworm still seem to be affected by this bug?
Should we open a new issue or re-open this bug?

Thx for maintaining!

Best,
 - Darsha


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041824: src:volume-el: disable d/watch and sync to latest head version

[Nicholas D Steeves]

Manphiz  writes:

>>> I have been trying to fix uscan error of Emacs addon packages.  When
>>> working on volume-el, I found that the repo on salsa didn't accept merge
>>> requests while most other packages did.  If it can open up merge request
>>> access it would be great and I have some pending d/watch fixes.  Thanks
>>> in advance!
>>
>> This may indicate that the Uploader wants patches rather than MRs, and
>> at the very least may indicate the Uploader doesn't want to monitor
>> Salsa for MRs.
>>
>
> Thanks for the explanation, Nicolas!  Totally make sense.

You're welcome!

> Done.  A little bit of explanation for the changes:
>
> * Upstream never had any tags, so uscan will always fail, so disable
>   d/watch for now.  This will result in an empty uscan results.

Why is breaking notification of any future upstream tags better than
using uscan's git mode?  Uscan's git mode will notify when upstream
pushes any commit, with or without a tag.  Help is available in
#debian-mentors if writing an output format line that is suitable for
volume-el's existing version scheme is too challenging.

Regards,
Nicholas

Bug#1039747: tagging 1039747 ...

[David Prévot]

Hi,

Le Fri, Jul 14, 2023 at 08:56:36AM +0200, David Prévot a écrit :
> tags 1039747 + patch
> forwarded 1039747 
> https://salsa.debian.org/php-team/pear/doctrine/-/merge_requests/1

AFAICT, this change (that I already had locally commited BTW), requires
PHPUnit 10 and breaks under PHPUnit 9, so can’t actually be applied
until PHPUnit 10 makes it to unstable (but may be uploaded to
experimental).

Regards,

David


signature.asc
Description: PGP signature

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Otto Kekäläinen]

On Mon, 24 Jul 2023 at 09:33, Jonathan Wiltshire  wrote:
>
> There are two lintian warnings:
>
> W: debhelper-but-no-misc-depends mariadb-server-10.5
> W: transitional-package-not-oldlibs-optional database/optional

The version in unstable has intentionally no changes to ensure maximum
time of testing of the version that now is going into stable updates.

I have not done any extra Lintian fixes as doing extra Lintian fixes
and quality improvements lead to the Bookworm uploaded being blocked
for months in the first place.

This is the full list of issues currently detected by Lintian:
https://mariadb-team.pages.debian.net/-/mariadb-server/-/jobs/4410572/artifacts/debian/output/lintian.html
https://udd.debian.org/lintian/?packages=mariadb (link not timestamped)

I am now looking into these and will fix them on the
https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/debian/bookworm
branch directly:
* debhelper-but-no-misc-depends mariadb-server-10.5
* transitional-package-not-oldlibs-optional database/optional

> We also have a lack of dbgsym packages, probably because of the maintainer
> upload of amd64 and all. I'd quite like to fix the second lintian warning
> at least; if you uploaded again now with the more conventional version of
> 1:10.11.4-1~deb12u1 do you have to go through NEW again or could you make
> it a source-only upload?

Yes, I can do a source upload of 1:10.11.4-1~deb12u1 once above
changes are done and approved.

Bug#1041869: libcoq-paramcoq no longer depends on libcoq-stdlib-*

[Adrian Bunk]

Package: libcoq-paramcoq
Version: 1.1.3+coq8.17-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:coqeal

Package: libcoq-paramcoq
Version: 1.1.3+coq8.17-1+b1
Depends: libcoq-stdlib (>= 8.17)

Package: libcoq-paramcoq
Version: 1.1.3+coq8.16-3+b1
Depends: libcoq-stdlib-ewsr6


This was likely the root cause of
https://buildd.debian.org/status/fetch.php?pkg=coqeal=amd64=1.1.3-1%2Bb1=1690189656=0

Bug#1041868: Include patch fixing SNDRV_PCM_IOCTL_SW_PARAMS ioctl on src/pcm/pcm_hw.c

[Paul Tagliamonte]

Package: alsa-libs
Severity: normal
Version: 1.2.9-1
Tags: patch

Howdy, ALSA team!

I had some unrelated software (src:direwolf) break on me, which turns
out is a bug in ALSA.

Commit 2115cdb4dc314d66e92a9e04413bcedc543da007 (first part of 1.2.9
AFAICT) introduced a change to src/pcm/pcm_hw.c where sw_params is
passed by value rather than as a pointer in the ioctl call. Whoopsies.

This means for users of specific hardware (I am one such person!), ALSA
was returnning bad address (well, ALSA was returning the kernel being
grumpy) which horked writing audio to ALSA.

I took the attached patch from the upstream repo
(commit a5d8af8e4ef02340531092ea388dd1b668182409) and rebuilt alsa-libs.
This fixes the issue that presented with my hardware, and I was able to
transmit normally.

Thanks to Dan Cross for the fix

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3
From a5d8af8e4ef02340531092ea388dd1b668182409 Mon Sep 17 00:00:00 2001
From: Dan Cross 
Date: Wed, 14 Jun 2023 21:09:10 +
Subject: [PATCH] pcm: fix minor bug in ioctl

Commit 2115cdb added a new call to the `SNDRV_PCM_IOCTL_SW_PARAMS`
ioctl on line 675 of src/pcm/pcm_hw.c, but passed the `sw_params`
argument by value; this should be passed by pointer.

I ran across this in the context of the direwolf software modem
for amateur radio; debugging details are in
https://groups.io/g/direwolf/message/8286

Fixes #329

Signed-off-by: Dan Cross 
---
 src/pcm/pcm_hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c
index b468a071..f488023a 100644
--- a/src/pcm/pcm_hw.c
+++ b/src/pcm/pcm_hw.c
@@ -672,7 +672,7 @@ static int snd_pcm_hw_prepare(snd_pcm_t *pcm)
 
if (hw->prepare_reset_sw_params) {
snd_pcm_sw_params_current_no_lock(pcm, _params);
-   if (ioctl(hw->fd, SNDRV_PCM_IOCTL_SW_PARAMS, sw_params) < 0) {
+   if (ioctl(hw->fd, SNDRV_PCM_IOCTL_SW_PARAMS, _params) < 0) {
err = -errno;
SYSMSG("SNDRV_PCM_IOCTL_SW_PARAMS failed (%i)", err);
return err;


signature.asc
Description: PGP signature

Bug#1041867: tests fail blocking migration

[Jonathan Wiltshire]

Source: node-dottie
Version: 2.0.6+~2.0.5-1
Severity: serious
X-Debbugs-Cc: j...@debian.org

Hi,

The version of node-dottie in sid does not migrate because of a
regression in its tests:

| 91s   46 passing (25ms)
| 91s   2 failing
| 91s 
| 91s   1) dottie.set
| 91sshould not attempt to set __proto__:
| 91s  Error: Accessing Object.prototype.__proto__ has been disallowed with 
--disable-proto=throw
| 91s   at Context. (test/set.test.js:74:17)
| 91s   at callFn (/usr/share/nodejs/mocha/lib/runnable.js:366:21)
| 91s   at Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:354:5)
| 91s   at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:666:10)
| 91s   at /usr/share/nodejs/mocha/lib/runner.js:789:12
| 91s   at next (/usr/share/nodejs/mocha/lib/runner.js:581:14)
| 91s   at /usr/share/nodejs/mocha/lib/runner.js:591:7
| 91s   at next (/usr/share/nodejs/mocha/lib/runner.js:474:14)
| 91s   at Immediate._onImmediate 
(/usr/share/nodejs/mocha/lib/runner.js:559:5)
| 91s   at process.processImmediate (node:internal/timers:471:21)
| 91s 
| 91s   2) dottie.transform
| 91sshould guard against prototype pollution:
| 91s  Error: Accessing Object.prototype.__proto__ has been disallowed with 
--disable-proto=throw
| 91s   at Context. (test/transform.test.js:158:24)
| 91s   at callFn (/usr/share/nodejs/mocha/lib/runnable.js:366:21)
| 91s   at Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:354:5)
| 91s   at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:666:10)
| 91s   at /usr/share/nodejs/mocha/lib/runner.js:789:12
| 91s   at next (/usr/share/nodejs/mocha/lib/runner.js:581:14)
| 91s   at /usr/share/nodejs/mocha/lib/runner.js:591:7
| 91s   at next (/usr/share/nodejs/mocha/lib/runner.js:474:14)
| 91s   at Immediate._onImmediate 
(/usr/share/nodejs/mocha/lib/runner.js:559:5)
| 91s   at process.processImmediate (node:internal/timers:471:21)
| 91s 
| 91s 
| 91s 
| 91s autopkgtest [15:29:22]: test pkg-js-autopkgtest: ---]
| 91s autopkgtest [15:29:22]: test pkg-js-autopkgtest:  - - - - - - - - - - 
results - - - - - - - - - -
| 91s pkg-js-autopkgtest   FAIL non-zero exit status 2
| 91s autopkgtest [15:29:22]:  summary
| 91s pkg-js-autopkgtest-require PASS (superficial)
| 91s pkg-js-autopkgtest   FAIL non-zero exit status 2

(https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-dottie/36116500/log.gz)

Because of the migration blockage, updates for bullseye and bookworm are
also blocked because of version constraints.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
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

Bug#1041836: Version Correction

[Mike Bird]

Please note that the bug is in version 2.36-9+deb12u1 i.e. the
new version just released to Stable.

reportbug saw 2.36-9 because I had to revert to the previous
version before anything but static executables would work.

--Mike

Bug#1041865: AW: Bug#1041865: debos: Output of apt action not shown when running debos in noninteractive shell

[Tobias Junghans]

Hi Christopher,

thank you very much for sharing your finding about the complete raw log! Indeed 
we can see the whole output of apt actions there. I think this is a satisfying 
workaround, especially since this seems to be an issue which needs to be fixed 
elsewhere.

Best regards

Tobias

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Jonathan Wiltshire]

There are two lintian warnings:

W: debhelper-but-no-misc-depends mariadb-server-10.5
W: transitional-package-not-oldlibs-optional database/optional

We also have a lack of dbgsym packages, probably because of the maintainer
upload of amd64 and all. I'd quite like to fix the second lintian warning
at least; if you uploaded again now with the more conventional version of
1:10.11.4-1~deb12u1 do you have to go through NEW again or could you make
it a source-only upload?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041865: debos: Output of apt action not shown when running debos in noninteractive shell

[Christopher Obbard]

Control: forwarded -1 https://github.com/go-debos/debos/issues/416

On Mon, 2023-07-24 at 17:56 +0200, q wrote:
> Package: debos
> Version: 1.1.1-2.1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> we're using debos within Gitlab CI runners which basically works. However the
> output of apt does not appear in the job logs due to special character 
> sequences
> printed by apt. This makes it hard to debug any issues if the apt action fails
> and always requires us to run debos in an interactive shell manually.
> 
> Please see https://github.com/go-debos/debos/issues/416 for details and

Hi,

It is shown, it is just that GitLab Runner seems to hide certain lines ending 
in certain
newline character sequences.

You _can_ get to the full apt actions logs by going to the job and pressing the 
"Show complete 
raw" button at the top next to the Search bar.


> https://github.com/go-debos/debos/commit/b1197b80b4e87c6cd1cd7b06669faa7c40798551
> 
> for a possible solution which already has been merged into the upstream's main
> branch. Would it be possible to include this patch in an package update?

Unfortunately this will not fix the issue and the issue really belong to the 
GitLab
runner and its termination character detection. I will search for an issue on 
the
GitLab.com tracker, but so far I haven't found anything as yet.

It would help if we could find a bug on the tracker already about the 
termination
character issue.

Bug#1041854: bookworm-pu: package calibre/6.13.0+repack-2+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Mon, Jul 24, 2023 at 10:19:20PM +0900, YOKOTA Hiroshi wrote:
> [ Impact ]
> Preferences dialog won't work

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041475: hnswlib 0.4.0-3+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1041475 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: hnswlib
Version: 0.4.0-3+deb11u1

Explanation: fix double free in init_index when the M argument is a large 
integer [CVE-2023-37365]

Bug#1040865: yajl 2.1.0-3+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040865 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: yajl
Version: 2.1.0-3+deb11u2

Explanation: security fixes: potential denial of service with crafted JSON file 
[CVE-2017-16516]; heap memory corruption when dealing with large (~2GB) inputs 
[CVE-2022-24795]; fix incomplete patch for CVE-2023-33460

Bug#1040758: spip 3.2.11-3+deb11u9 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040758 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: spip
Version: 3.2.11-3+deb11u9

Explanation: security fix for extended authentification data filtering

Bug#1036240: kscreenlocker 5.20.5-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1036240 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: kscreenlocker
Version: 5.20.5-1+deb11u1

Explanation: Fix authentication error when using PAM

Bug#1041435: fixed in bitsnpicas 2.0+ds-2

[Nilesh Patra]

Control: reopen -1
Control: retitle -1 bitsnpicas: Contains potentially non-free binary unicode 
data
Control: found -1 2.0+ds-2

On Mon, 24 Jul 2023 13:20:33 + Debian FTP Masters 
 wrote:
>  bitsnpicas (2.0+ds-2) unstable; urgency=medium
>  .
>* Apply patch to fix usability. (Closes: #1041435)
>  Thank you Nilesh Patra.

Thanks for applying my patch, it is atleast usable now. However, this
part of the bug still remains un-fixed, which would mean potentially
pushing non-free software into main.

I've thus retitled the bug and reopened it.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#996850: ITP: rhsrvany -- Windows tools used by virt-v2v

[Lee Garrett]

Hi Ryan,

is there any update on the packaging progress?

Greets,
Lee


On Tue, 19 Oct 2021 10:48:35 -0500 Ryan Pavlik  wrote:

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

* Package name: rhsrvany
  Version : 0.20210127
  Upstream Author : Richard W.M. Jones, Red Hat Inc.
* URL : https://github.com/rwmjones/rhsrvany
* License : GPL-2+
  Programming Lang: C
  Description : Windows tools used by virt-v2v

 This package contains open-source replacements for
 proprietary Windows tools, SrvAny (RHSrvAny) and pnp_wait.
 They are used by the virt-v2v tool when converting
 Windows virtual machines.

This is required for virt-v2v (see https://bugs.debian.org/962293)
which was formerly part of libguestfs in Buster and now the
subject of its own RFP bug linked above.
The draft of that package is in the libvirt team,
and if this package is accepted, I'd anticipate joining that team
for team maintenance and sponsorship. The code itself is quite stable,
with a limited purpose and having seen little need for changes in
the past several years, so I anticipate
packaging maintenance load to be low.

Bug#1041866: Package: geeqie

[Florian Cramer]

Package: geeqie

geeqie (version 1:2.0.1-8+b2, Trixie package) depends on the
package liblua5.1-0 . However, liblua5.1-0 is not included in the
dependencies of Trixie's geeqie package and needs to be manually installed.
Without an installed liblua5.1-0, geeqie quit upon launch with an
error message about liblua5.1.so.0 missing.

I am using Debian Trixie with kernel 6.3.0-1-amd64 #1 SMP PREEMPT_DYNAMIC
Debian 6.3.7-1 (2023-06-12) x86_64 GNU/Linux.

Bug#1041865: debos: Output of apt action not shown when running debos in noninteractive shell

[q]

Package: debos
Version: 1.1.1-2.1
Severity: important
Tags: upstream

Dear Maintainer,

we're using debos within Gitlab CI runners which basically works. However the
output of apt does not appear in the job logs due to special character sequences
printed by apt. This makes it hard to debug any issues if the apt action fails
and always requires us to run debos in an interactive shell manually.

Please see https://github.com/go-debos/debos/issues/416 for details and

https://github.com/go-debos/debos/commit/b1197b80b4e87c6cd1cd7b06669faa7c40798551

for a possible solution which already has been merged into the upstream's main
branch. Would it be possible to include this patch in an package update?

Thanks,

Tobias


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debos depends on:
ii  busybox1:1.35.0-4+b3
pn  debootstrap
ii  libc6  2.36-9
ii  libglib2.0-0   2.74.6-2
pn  libostree-1-1  
pn  qemu-system-x86
ii  qemu-user-static   1:7.2+dfsg-7
pn  systemd-container  

Versions of packages debos recommends:
pn  bmap-tools 
ii  bzip2  1.0.8-5+b1
ii  e2fsprogs  1.47.0-2
ii  linux-image-amd64  6.1.37-1
ii  mount  2.38.1-5+b1
pn  ovmf   
pn  parted 
pn  systemd-resolved   
ii  udev   252.6-1
ii  xz-utils   5.4.1-0.2
pn  zip

Versions of packages debos suggests:
pn  libslirp-helper  
pn  user-mode-linux  

Bug#1041864: RM: netkit-rsh -- RoQA; obsolete, dead upstream, open security issues

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: netkit-...@packages.debian.org
Control: affects -1 + src:netkit-rsh

Please remove netkit-rsh. It's obsolete, dead upstream and has open security 
issues.

Bug#1041863: amd64-microcode: CVE-2023-20593: use-after-free in AMD Zen2 processors

[Salvatore Bonaccorso]

Source: amd64-microcode
Version: 3.20230414.1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1  3.20191218.1

Hi,

The following vulnerability was published for amd64-microcode.

CVE-2023-20593[0]:
| use-after-free in AMD Zen2 processors

Merge request at [2].

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-20593
https://www.cve.org/CVERecord?id=CVE-2023-20593
[1] https://lock.cmpxchg8b.com/zenbleed.html
[2] https://salsa.debian.org/hmh/amd64-microcode/-/merge_requests/5

Regards,
Salvatore

Bug#1041862: roundcube-plugins-extra: roundcube-sauserprefs throws Call to undefined function get_form_tags(

[Schnitzi]

Package: roundcube-plugins-extra
Version: 1.4.10+1-4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Using roundcube-sauserprefs
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
enable the module
   * What was the outcome of this action?
Roundcube throws throws Call to undefined function get_form_tags() when 
clicking on sauserprefs in settings
   * What outcome did you expect instead?
Just works

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


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages roundcube-plugins-extra depends on:
ii  roundcube-core  1.6.1+dfsg-1

roundcube-plugins-extra recommends no packages.

Versions of packages roundcube-plugins-extra suggests:
pn  fail2ban  

-- Configuration Files:
/etc/roundcube/plugins/html5_notifier/config.inc.php changed [not included]
/etc/roundcube/plugins/sauserprefs/config.inc.php changed [not included]
/etc/roundcube/plugins/thunderbird_labels/config.inc.php changed [not included]

-- no debconf information

The problem is that the version of roundcube-sauserprefs is too old (version 
1.18) which is not compatible with roundcube 1.5 and above. As we are currently 
packaging roundcube 1.6.1 
this means that roundcube-sauserprefs needs to be updated in order to work.
Problem is described in 
https://github.com/johndoh/roundcube-sauserprefs/issues/66
--> Please update roundcube-sauserprefs with upstream version 1.19
Thanks :)

Bug#1041861: ITP: rust-libp2p-identity -- libp2p peer identifying structures and algorithms

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-libp2p-identity
  Version : 0.2.1
  Upstream Contact: Parity Technologies (UK) Ltd.
* URL : https://github.com/libp2p/rust-libp2p
* License : Expat
  Programming Lang: Rust
  Description : libp2p peer identifying structures and algorithms

 libp2p-identity contains
 data structures and algorithms for identifying peers in libp2p.

This package is needed by safe-network (bug#1008016).
It will be maintained in the collaborative debian section of salsa, at
.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+nfoACgkQLHwxRsGg
ASGO+A//YSVjy9TOFAnY4MICxcRZDx2DG80MyYDZP37ogZ7FC6Z5ygrgvJ9TOK4Z
TAGVDoZ1zmYM+7IlQkzMwjIxw7u8EFGAP65cfDheIH8SRAO87QzwHvP3nSCxrPuR
nBrucacutHWKSBMtQ5Gk/sPj7DI9+VK+1vOLh7rxy74EBdjTRVJE7LWak7vyC+uK
3HvRMqmsm+u1YBSzOPBXKPeDjCFgqlyN4bfap0uvDzQP0ZvN2dvjEqeMb3EbgF9h
GN65QZJcLy/LZbCNO+uH09pR75dar22WA0Cqqb4+l7hLY6rIa+U6rDDR1TbDlHfB
FKhLH9Q44i7UP2l4kI0SYpxVJWIKqBozGO4BE2/fdN9Sz1MAGFRhfpwERSMJSbsS
2IxZDlU3N4KNdvCa+DsxAjGF8Bbo7I6M/kVqpTETU91u1E3cCAoZsvXgRbzMCxyH
LOlTYquXdUVSrJCgvDK+1PdXHLAgByVolZay2imBPSSsPQN1iyILD0K0yt5u0WC/
/qVZbTWtomNS9BtrJbdXXU5zcH4FKG6MQ0W3kYAykWTPNfPsEWpxXYsiYPc7doGU
QcGHRGh44t7/W5a4yYYSRvDvhARUmIEVbQ644XSvcbekcB2piTRnoN0O6kwTP3XB
VVNRsbiUxGPCd4SuOJLjWyUNudERHi+QsUU70sjRLaIPji5IKZE=
=81qQ
-END PGP SIGNATURE-

Bug#966494: (no subject)

[Christopher Voglstätter]

Working fine here as well with one caveat.

We need to use the php-sabre-dav and php-sabre-vobject provided with the 
tar ball on github.
If the debian packages php-sabre-dav and/or php-sabre-vobject with the 
versions packaged in Debian 12.1 are installed roundcube throws a 
"Uncaught Error: Call to undefined method 
Sabre\VObject\Component\VCard::getDocumentType()".

Documented also here: https://github.com/mstilkerich/rcmcarddav/issues/449

So tag as conflict with php-sabre-dav and/or php-sabre-vobject below 
a certain version?


Cheers

Christopher

Bug#1041860: cyrus-sasl2: Enable SCRAM mechanisms in Debian builds

[Ondrej Kuznik]

Source: cyrus-sasl2
Severity: normal
X-Debbugs-Cc: on...@mistotebe.net

Dear Maintainer,
now that MD5 support is being phased out from all crypto libraries (and
more generally), DIGEST-MD5 is going to disappear from cyrus-sasl. Its
replacement the SCRAM family of SASL mechanisms is however not being
shipped in Debian.

Please build and ship the SCRAM plugin with cyrus-sasl2.

Thanks,
Ondřej Kuzník

Bug#619328: console-setup-freebsd: Uninstallable on Linux hosts

[Paul Gevers]

Hi,

On Wed, 23 Mar 2011 10:49:42 +0100 Julien Cristau  
wrote:

On Wed, Mar 23, 2011 at 11:36:00 +0200, Anton Zinoviev wrote:
> Does this mean the 
> architectures are not equal in rights - an 'all' package is allowed to 
> be uninsallable on kFreeBSD but not on Linux?
> 
No, it's fine.


While I totally stand behind this, with the kfreebsd's removed now even 
from the ports [1], maybe it's time to stop building console-setup-freebsd?


Paul

[1] https://www.ports.debian.org/ 2023-07-14


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041512: Unable to parse icon type 'ic12' 'ic07' 'ic13' 'ic14'

[Paul Wise]

On Mon, 2023-07-24 at 11:48 +0200, Bastian Germann wrote:

> A new upstream version was uploaded to mentors:
> https://mentors.debian.net/package/libicns/
> 
> Would you please consider reviewing it?

Thats a snapshot. I'll likely review the patches xiao sent upstream,
add some upstream polish, make a new upstream release, import xiao's
Debian packaging changes and upload the result.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1039957: light-locker: Bug 1039957: light-locker: coredump from light-locker

[Yves-Alexis Perez]

On Mon, Jul 24, 2023 at 05:00:36PM +0200, Paul Gevers wrote:
> Hi,
> 
> On 24-07-2023 15:27, Yves-Alexis Perez wrote:
> > so what you're saying is that you're a KDE user (not Xfce)
> 
> Indeed.
> 
> > but you're
> > still using LightDM (not KDM), and light-locker is still started as part
> > of your desktop session.
> 
> I'm not aware that I ever did that actively. It seems that also nothing
> obvious changed for me since I deinstalled light-locker. So everything
> *looks* like before.

Yeah I meant before removing it.
> 
> > In any case, if you don't use it on your box it's quite ok to remove it.
> 
> I tried to say in my previous message that I already did that.
> 
Yes indeed, I was just saying that it was ok.

-- 
Yves-Alexis Perez

Bug#1039957: light-locker: Bug 1039957: light-locker: coredump from light-locker

[Paul Gevers]

Hi,

On 24-07-2023 15:27, Yves-Alexis Perez wrote:

so what you're saying is that you're a KDE user (not Xfce)


Indeed.


but you're
still using LightDM (not KDM), and light-locker is still started as part
of your desktop session.


I'm not aware that I ever did that actively. It seems that also nothing 
obvious changed for me since I deinstalled light-locker. So everything 
*looks* like before.



In any case, if you don't use it on your box it's quite ok to remove it.


I tried to say in my previous message that I already did that.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041859: qemu-user-static: Segfault when running armhf python3 in chroot

[Alper Nebi Yasak]

Package: qemu-user-static
Version: 1:8.0.3+dfsg-3
Severity: normal
Control: found -1 1:8.0.3+dfsg-2

Dear QEMU maintainers,

I've recently noticed my armhf development chroot fails to upgrade
python3-minimal. I've tracked it down to a segmentation fault when
running python3 (for py3compile) as part of the package postinst.

Should be possible to reproduce with something like:

  $ sudo sbuild-createchroot \
  --include=gnupg --arch=armhf --chroot-suffix="-test" \
unstable /srv/chroot/unstable-armhf-test \
http://deb.debian.org/debian

  $ sudo schroot -c unstable-armhf-test -u root -d /root -- \
apt install -y python3-minimal
  [...]   Setting up python3.11-minimal (3.11.4-1) ...
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  dpkg: error processing package python3.11-minimal (--configure):
   installed python3.11-minimal package post-installation script
subprocess returned error exit status 139
  Errors were encountered while processing:
   python3.11-minimal
  E: Sub-process /usr/bin/dpkg returned an error code (1)

Downgrading qemu-user and qemu-user-static to 1:8.0.3+dfsg-1 makes
things work again. It also fails with 1:8.0.3+dfsg-2.

I see a bug #1040981 about segfaults in klibc-utils which might be
related, but I don't understand much of the discussion at first glance.
Apparently version 1:8.0.3+dfsg-2 fixes that but breaks this.

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

Kernel: Linux 6.4.0-1-amd64 (SMP w/24 CPU threads; PREEMPT)
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

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  systemd  254~rc2-3

qemu-user-static suggests no packages.

Versions of packages qemu-user depends on:
ii  libc6 2.37-6
ii  libcapstone4  4.0.2-5
ii  libgcc-s1 13.1.0-9
ii  libglib2.0-0  2.76.4-4
ii  libgnutls30   3.7.9-2
ii  libnuma1  2.0.16-1
ii  liburing2 2.4-1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages qemu-user recommends:
ii  qemu-user-static [qemu-user-binfmt]  1:8.0.3+dfsg-3

qemu-user suggests no packages.


-- no debconf information

Bug#1041774: [Pkg-utopia-maintainers] Bug#1041774: udisks2: Hangs for about 20 secs. and timeout error after upgrading to 2.10.0-3 on trixie

[Ricardo Pérez López]

El dom, 23 jul 2023 a las 21:56, Michael Biebl ()
escribió:

> Am 23.07.23 um 16:06 schrieb Ricardo Pérez:
> > Package: udisks2
> > Version: 2.10.0-3
> > Severity: important
> > X-Debbugs-Cc: rica...@ubuntu.com
> >
> > Dear Maintainer,
> >
> > After upgrading to 2.10.0-3 on trixie, when I try to run Thunar or
> > something similar, it hangs for about 20 secs. and then I got the
> > following error message:
> >
> > Error creating proxy: Error calling StartServiceByName for
> org.gtk.vfs.UDisks2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)
>
> This should be https://github.com/storaged-project/udisks/issues/1139
>
> It's supposedly both a bug in Thunar (for not running the query async)
> and should be mitigated by installing util-linux 2.39 (from experimental).


After upgrade to util-linux 2.39 and libmount 2.39 from experimental, the
issue seems to be fixed. Thank you!

Ricardo.

Bug#1041847: man-db: ftbfs on all arch due to test failed

[Bo YU]

Hi!

On Mon, Jul 24, 2023 at 7:37 PM Colin Watson  wrote:
>
> On Mon, Jul 24, 2023 at 06:05:43PM +0800, Bo YU wrote:
> > The package build failed due to like:
>
...
> I can't easily do an upstream release immediately, because there are a
> number of changes that ought to go through a call for updated
> translations.  I'll cherry-pick the fix, though.

It was fixed quite fast, many thanks!

BR,
Bo
>
> --
> Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1041249: cpp-httplib: FTBFS on s390x: ../test/test.cc:5462: Failure

[Andrea Pappacoda]

Il giorno lun 24 lug 2023 alle 09:05:30 +02:00:00, Sebastian Ramacher 
 ha scritto:
Please prepare transitions in experimental first. This would avoid 
such

issues.

If there are no news regarding a fix for this bug, please revert
cpp-httplib 0.11.4 to get back to a good state.


Hi, I'll be sure to do it next time. I've looked into this, but I 
couldn't find any change which would cause test failures on s390x 
specifically. cpp-httplib's test suite is a bit flaky though, so it may 
have been just an unlucky run (this is an issue in itself, but I have 
already reported it upstream and it didn't get much attention). Is it 
possible to re-try the build?


Thanks :)

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux

[Paul Tagliamonte]

On Mon, Jul 24, 2023 at 04:16:52PM +0200, Daniel Gröber wrote:
> Stateless IP/ICMP translation (SIIT), Stateful NAT64 and [CLAT]
> are important mechnisms to pave the way to an IPv6-only future. I've
> found the tools we currently have in Debian to provide and use these
> services, Tayga and Jool, lacking in various respects.

As a current jool user, I'm very interested in this project. I'll have
to try this out.

> Tayga has major performance problems due to being single-threaded and
> comes nowhere near to even measily 100Mbit forwarding on modern
> hardware but it currently is the only viable way to implement [CLAT]
> on Debian.
> 
> [CLAT]: Is the client-side of a 464XLAT setup. This is used to support
> applications using IPv4 literals on top of an IPv6-only access network.
> 
> Jool being an out-of-tree kernel module has to employ various kernel
> hacks to get it's job done that lead to all kinds of jankyness. It's
> reasonably fast though, so it's more suited for deployment as a
> network service. Unfortunately the upstream project is in "maintanance
> only" mode so my concern is it may get abandoned at some point.

Same :)

> Hence we need more alternatives for these services in Debian.
> 
> tundra-nat64 is a new userspace implementation of SIIT, NAT64 and
> [CLAT]. It's multithreaded as opposed to tayga so my hope is the
> performance will be much better.
> 
> I plan on maintaining tuntra-nat64 myself but I do need a sponsor :)

Why the heck not, I'm happy to review and sponsor; IPv6 adoption is
critical, and giving a hand to someone working to maintain current
tooling to help with the adoption is doing good work. Hit me up off-list
and we'll work out a workflow and all that.

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3

Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux

[Daniel Gröber]

Package: wnpp
Severity: wishlist
Owner: Daniel Gröber 
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@darkboxed.org

Hi,

* Package name: tundra-nat64
  Upstream Contact: Vt Labuda
* URL : https://github.com/vitlabuda/tundra-nat64
* License : BSD3
  Programming Lang: C
  Description : A minimal, user-space, stateless NAT64, CLAT and SIIT 
implementation for Linux

Stateless IP/ICMP translation (SIIT), Stateful NAT64 and [CLAT]
are important mechnisms to pave the way to an IPv6-only future. I've
found the tools we currently have in Debian to provide and use these
services, Tayga and Jool, lacking in various respects.

Tayga has major performance problems due to being single-threaded and
comes nowhere near to even measily 100Mbit forwarding on modern
hardware but it currently is the only viable way to implement [CLAT]
on Debian.

[CLAT]: Is the client-side of a 464XLAT setup. This is used to support
applications using IPv4 literals on top of an IPv6-only access network.

Jool being an out-of-tree kernel module has to employ various kernel
hacks to get it's job done that lead to all kinds of jankyness. It's
reasonably fast though, so it's more suited for deployment as a
network service. Unfortunately the upstream project is in "maintanance
only" mode so my concern is it may get abandoned at some point.

Hence we need more alternatives for these services in Debian.

tundra-nat64 is a new userspace implementation of SIIT, NAT64 and
[CLAT]. It's multithreaded as opposed to tayga so my hope is the
performance will be much better.

I plan on maintaining tuntra-nat64 myself but I do need a sponsor :)

Thanks,
--Daniel

Bug#969162: checkit-tiff, new upstream available (Update 2023)

[Romeyke, Andreas]

Hi,

the main repository is available at https://git.fsfe.org/art1pirat/checkit_tiff

The homepage is http://andreas-romeyke.de/software.html#_checkit_tiff

With best regards

Andreas

--
team member “long-term preservation“

Saxon State- and University Library Dresden (SLUB)
Department 2 (IT), Division 2.3 (infrastructure and digital long-term 
preservation) 
Zellescher Weg 18 | 01069 Dresden
phone: +49 351 4677 763
E-Mail: andreas.rome...@slub-dresden.de 
http://www.slub-dresden.de/ | @slubdresden



smime.p7s
Description: S/MIME cryptographic signature

Bug#1041857: Warnings about systemd-udev-settle.service is deprecated on debian 12 ZFS, plus zfs-import-scan.service missing After=zfs-load-module.service

[Laurent GUERBY]

Package: zfsutils-linux
Version: 2.1.11-1
Severity: important

Hi,

On a brand new debian 12 VM with ZFS while looking at boot logs I
found:

Jul 21 22:21:24 testhost udevadm[355]: systemd-udev-settle.service is
deprecated. Please fix zfs-import-cache.service, zfs-load-
module.service not to pull it in.

Looking at the ZFS service files:

/lib/systemd/system# grep systemd-udev-settle zfs*|grep Requires=
zfs-import-cache.service:Requires=systemd-udev-settle.service
zfs-import-scan.service:Requires=systemd-udev-settle.service
zfs-load-module.service:Requires=systemd-udev-settle.service

I removed above the Requires= lines: my ZFS still worked after reboot
and no warnings about deprecated. I left the After= lines they seem
harmless and could be useful is one is still relying on systemd-udev-
settle in some way.

I then tested a switch from zfs-import-cache (which the documentation
in /etc/default/zfs says is not recommanded on Linux) to zfs-import-
scan:

systemctl disable  zfs-import-cache
systemctl enable zfs-import-cache
systemctl daemon-reload
reboot

There was an error at boot about /sys/module/zfs not being there,
looking at dependancies I noticed:

/lib/systemd/system# grep zfs-load zfs*
zfs-import-cache.service:Requires=zfs-load-module.service
zfs-import-cache.service:After=zfs-load-module.service
zfs-import-scan.service:Requires=zfs-load-module.service
zfs-import-scan.service:Requires=zfs-load-module.service

zfs-import-scan is missing an After=zfs-load-module.service and has two
times Requires=zfs-load-module.service so probably a copy/paste thinko.

I changed the second Requires= to After=

Next error was due to:

ConditionFileNotEmpty=!/etc/zfs/zpool.cache

I removed this "ConditionFileNotEmpty=!" line entirely since the
zpool.cache file is ignored by zfs-import-scan (that's the whole
purpose of this unit) and I couldn't find documentation about "=!" in
systemd unit files.

With both edits I was able to successfully reboot and have all my ZFS
pools ready using zfs-import-scan.

Note: in my setup (VM running debian 12 with multiple disks and ZFS
pools) zfs-import-cache sometimes fails to import all the pools at boot
while zfs-import-scan always succeed.

Thanks in advance for your help,

Sincerely,

Laurent GUERBY

Bug#1041825: libopenraw: new upstream release 0.3.6

[Yves-Alexis Perez]

On Mon, Jul 24, 2023 at 02:37:50PM +0100, Simon McVittie wrote:
> On Mon, 24 Jul 2023 at 14:57:23 +0200, Yves-Alexis Perez wrote:
> > If libopenraw Debian package isn't maintained in practice, maybe it
> > makes sense to drop it completely. For tumbler we can just remove the
> > dependency (and lose the hability to generate thumbnails for them) or
> > maybe investigate a way to uses a different library.
> 
> For what it's worth, gegl switched from libopenraw to libraw (libraw-dev)
> a while ago. libraw seems to be somewhat widely used: it's also what
> gthumb, shotwell, geeqie, kimageformat-plugins, etc. use.

Thanks for the pointer, I'll transfer that to upstream!

Regards,
-- 
Yves-Alexis