Bug#1027050: growing image fails to boot: /scripts/local-bottom/growroot: line 97: wait-for-root: not found

[Martin Pitt]

Hello Santiago,

Santiago Vila [2023-02-18  0:26 +0100]:
> Martin Pitt wrote:
> > The "flock: not found" is #1014662, but that is already present in our 
> > current
> > image with cloud-initramfs-tools 0.18.debian8, and does not seem fatal. So 
> > far
> > the "wait-for-root: not found" seems to be the culprit?
>
> That's what it seems, yes. There is a fix here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014662#34
>
> I've just tested it and it seems to work.

I tested it as well, and confirm that it works. I left a review in the Salsa MR:
https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/2

Thanks!

Martin

Bug#1031434: conda-package-handling: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Nilesh Patra]

Control: reassign -1 python3-zstandard 0.19.0-3
Control: affects -1 + conda-package-handling
Control: forcemerge -1 1031293

On Fri, 17 Feb 2023 06:30:57 +0100 Lucas Nussbaum  wrote:
> Source: conda-package-handling
> Version: 2.0.1-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230216 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This is very clearly due to zstd python and unbundled lib mismatch.
there's nothing that can be done at c-p-h end to fix this.

Reassigning and merging with an already filed bug.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Fri, Feb 17, 2023 at 10:34:29PM +0200, Adrian Bunk wrote:
> 
> The same general problem applies in various "building non-Debian 
> embedded Linux filesystem on Debian" situations where the target
> chroot does not contain mkfs.ext4.

In practice, if the root file system is using ext4, the target chroot
has to have e2fsprogs installed so that fsck.ext4 exists.  So I'm not
sure it's all that unreasonable?

> Or if it is present, it would be a chroot for the target architecture
> where you might have to run mkfs.ext4 under qemu.

Sure, but that's not that difficult; I have a script[1] that will
setup chroots for foreign architectures which use binfmt_misc to run
(for example) arm32 or arm64 binaries using qemu on an x86 machine,
without needing to boot an arm32/arm64 kernel.  For a more detailed
explanation see slide #8 of this slide deck[2].  The setup-buildchroot
script is turn-key; my experience is that several new college grads
and interns hired at $WORK have had no problems setting it up.

[1] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot#L364
[2] https://thunk.org/android-xfstests

Also, in practice, if you are building an image for a foreign system,
you'll need to have a qemu setup to run the second stage of the
debootstrap in any case.  I've just found it simpler to run the mkfs
and debootstrap in a chroot using qemu-user-static compared to messing
around with debootstrap --second-stage, which requires running a
chroot and qemu in any case.

> All image building tools that support bookworm (including all image 
> building tools we ship in bookworm) have to ensure that what they
> produce works on the intended target. There is no general solution
> *how* to do that that could be applied in all cases.

Well, the general solution we can give them is instructions to adjust
/etc/mke2fs.conf on those systems needing to run those image building
systems.  It's a one-line change.  This can be documented in the
release notes, or in an e2fsprogs NEWS entry.

If the RT really insists, we can edit /etc/mkefs.conf for Bookworm to
not enable metadata_csum_seed by default.  This will make it more
difficult for root file systems cloud VM's to be able adjust the file
system UUID on the fly, while the file system is mounted, so that's
the tradeoff.  Quite frankly, the distro that I really care about for
$WORK is Arch, since Google's Cloud Optimized OS is based off of Arch
userspace packages.  So if the Debian Release Team would like to
disable metadata_csum_seed by default in e2fsprogs, I will make that
change and upload a new version of e2fsprogs 1.47.0.

I don't think that's the right way to go, since I don't consider image
building to be a super-common use case, and those who do that can edit
/etc/mke2fs.conf on their own.  However, I accept that this is the
Release Team's call.

If we do make this change to mke2fs.conf for Bookworm, my intention is
to upload a version of e2fsprogs which reverts this change as soon as
Bookworm ships as stable, so that Debian 13 will enable
metadata-csum-seed by default.  At that point, people using Sid or
Debian Testing will have problems if they want to build images for
Bullseye, and I'll note that Daniel, who originally registered this
objection, was building images using Debian Unstable.  So this will
will only give him a reprieve for a few months before he will need to
push changes to vmdb2 or make that one-line change to
/etc/mke2fs.conf.

If the Debian release team could let me know which path they would
prefer, I would appreciate it.  At this point, the grub2 package
version (2.06-8) which supports metadata-csum-seed has migrated to
testing.  So the only thing the e2fsprogs migration is now blocked on
is the RT's decision on this bug.

Best regards,

- Ted

Bug#1031540: libamdhip64-dev: hip-lang cmake support is broken

[Cordell Bloor]

Package: libamdhip64-dev
Version: 5.2.3-4
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

The CMake support for the HIP language is badly broken. Consider a
sample project:

CMakeLists.txt

CMakeLists.txt 
cmake_minimum_required(VERSION 3.22)
project(example LANGUAGES HIP)
add_executable(ex main.hip)

main.hip:

#include 
#include 

#define CHECK_HIP(expr) do {  \
  hipError_t result = (expr); \
  if (result != hipSuccess) { \
fprintf(stderr, "%s:%d: %s (%d)\n",   \
  __FILE__, __LINE__, \
  hipGetErrorString(result), result); \
exit(EXIT_FAILURE);   \
  }   \
} while(0)

__global__ void sq_arr(float *arr, int n) {
  int tid = blockDim.x*blockIdx.x + threadIdx.x;
  if (tid < n) {
arr[tid] = arr[tid] * arr[tid];
  }
}

int main() {
  enum { N = 5 };
  float hArr[N] = { 1, 2, 3, 4, 5 };
  float *dArr;
  CHECK_HIP(hipMalloc(, sizeof(float) * N));
  CHECK_HIP(hipMemcpy(dArr, hArr, sizeof(float) * N, 
hipMemcpyHostToDevice));
  sq_arr<<>>(dArr, N);
  CHECK_HIP(hipMemcpy(hArr, dArr, sizeof(float) * N, 
hipMemcpyDeviceToHost));
  for (int i = 0; i < N; ++i) {
printf("%f\n", hArr[i]);
  }
  CHECK_HIP(hipFree(dArr));
  return 0;
}

Build log:

# HIPCXX=clang++-15 cmake -S. -Bbuild
-- The HIP compiler identification is unknown
CMake Error at 
/usr/share/cmake-3.25/Modules/CMakeDetermineHIPCompiler.cmake:106 (message):
  The ROCm root directory:

   /usr

  does not contain the HIP runtime CMake package, expected at:

   /usr/lib/cmake/hip-lang/hip-lang-config.cmake

Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "/root/hipsample/build/CMakeFiles/CMakeOutput.log".
See also "/root/hipsample/build/CMakeFiles/CMakeError.log".

With a lot of patches, extra flags and environment variables, I was
able to get cmake support for the HIP langauge working, but it required
changes to both the libamdhip64-dev and cmake-data packages. Ideally,
there would also be changes to clang++-15 to search the Debian paths
by default for libamdhip64 and the rocm-device-libs.

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libamdhip64-dev depends on:
ii  libamdhip64-55.2.3-4
ii  libhiprtc-builtins5  5.2.3-4

libamdhip64-dev recommends no packages.

libamdhip64-dev suggests no packages.

-- no debconf information

Bug#1031539: network-manager: NM since 1.42.0-1 overwrites pre-existing dns-search entries

[Christoph Anton Mitterer]

Package: network-manager
Version: 1.42.0-1
Severity: normal

Hey.

Just wanted to file this as a bug against ifupdown, but while writing I found 
out
that actually the upgrade from 1.40.10-1 to 1.42.0-1 causes this:

Ssince around the 10th of Feburary (and I've updated NM on the 11th) my 
dns-search
doesn't get added to resolvconf anymore.

Since years I have in /etc/network/interfaces:
   iface lo inet loopback
   dns-search  scientia.org

And while I also keep eth/wlan config in it, it's not enabled per default but
NetworkManager is used for that (because of the GUI stuff - talking about a 
laptop
here). So I have:
   allow-auto  lo
   #allow-hotplug  eth0 wlan0

So ifupdown does basically nothing, except for being there in case NM should 
have
troubles ... and setting my personal dns-search.
I also use the resolvconf package.

My DHCP sends me an additional fritz.box for the dns-search, which I fail to 
block ^^
But despite all this, for many years, my own dns-search was always added, too.
Now only the fritz.box remains.



It seems, that since 1.42.0-1 NM no longer just appends its own dns-search 
domains
(i.e. fritz.box) but also clears out any that are already there.
Downgrading "fixes" that.


Though it's of course arguable, whether this behaviour is actually proper or 
not.


Anyway... you guys know probably better if that's a desired change or some bug.
If the former, it would perhaps be nice if a NEWS.Debian entry could be added?


Thanks,
Chris.



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

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

Versions of packages network-manager depends on:
ii  adduser 3.131
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libaudit1   1:3.0.9-1
ii  libbluetooth3   5.66-1
ii  libc6   2.36-8
ii  libcurl3-gnutls 7.87.0-2
ii  libglib2.0-02.74.5-1
ii  libgnutls30 3.7.8-5
ii  libjansson4 2.14-2
ii  libmm-glib0 1.20.4-1
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.23-1+b1
ii  libnm0  1.42.0-1
ii  libpsl5 0.21.2-1
ii  libreadline88.2-1.3
ii  libselinux1 3.4-1+b5
ii  libsystemd0 252.5-2
ii  libteamdctl01.31-1
ii  libudev1252.5-2
ii  policykit-1 122-3
ii  polkitd 122-3
ii  udev252.5-2

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd   252.5-2
pn  modemmanager 
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-11

Versions of packages network-manager suggests:
ii  iptables   1.8.9-2
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-1.1

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=keyfile
[ifupdown]
managed=true


-- no debconf information

Bug#1031538: libamdhip64-dev: find_package(hip) requires additional packages

[Cordell Bloor]

Package: libamdhip64-dev
Version: 5.2.3-4
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

The dependencies for libhipamd64-dev appear to be underspecified.

main.cpp:

#include 
#include 

#define CHECK_HIP(expr) do {  \
  hipError_t result = (expr); \
  if (result != hipSuccess) { \
fprintf(stderr, "%s:%d: %s (%d)\n",   \
  __FILE__, __LINE__, \
  hipGetErrorString(result), result); \
exit(EXIT_FAILURE);   \
  }   \
} while(0)

__global__ void sq_arr(float *arr, int n) {
  int tid = blockDim.x*blockIdx.x + threadIdx.x;
  if (tid < n) {
arr[tid] = arr[tid] * arr[tid];
  }
}

int main() {
  enum { N = 5 };
  float hArr[N] = { 1, 2, 3, 4, 5 };
  float *dArr;
  CHECK_HIP(hipMalloc(, sizeof(float) * N));
  CHECK_HIP(hipMemcpy(dArr, hArr, sizeof(float) * N, 
hipMemcpyHostToDevice));
  sq_arr<<>>(dArr, N);
  CHECK_HIP(hipMemcpy(hArr, dArr, sizeof(float) * N, 
hipMemcpyDeviceToHost));
  for (int i = 0; i < N; ++i) {
printf("%f\n", hArr[i]);
  }
  CHECK_HIP(hipFree(dArr));
  return 0;
}

CMakeLists.txt:

cmake_minimum_required(VERSION 3.22)
project(example LANGUAGES CXX)

find_package(hip REQUIRED)

add_executable(ex main.cpp)
target_link_libraries(ex hip::device)

Build log:

# CXX=hipcc cmake -S. -Bbuild
-- The CXX compiler identification is Clang 15.0.7
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/hipcc - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at 
/usr/share/cmake-3.25/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
  By not providing "Findamd_comgr.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "amd_comgr", but CMake did not find one.

  Could not find a package configuration file provided by "amd_comgr" with
  any of the following names:

amd_comgrConfig.cmake
amd_comgr-config.cmake

  Add the installation prefix of "amd_comgr" to CMAKE_PREFIX_PATH or set
  "amd_comgr_DIR" to a directory containing one of the above files.  If
  "amd_comgr" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/hip/hip-config.cmake:206 (find_dependency)
  CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!

Build log after `apt install libamd-comgr-dev`:

# CXX=hipcc cmake -S. -Bbuild
-- The CXX compiler identification is Clang 15.0.7
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/hipcc - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at 
/usr/share/cmake-3.25/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
  By not providing "Findhsa-runtime64.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "hsa-runtime64", but CMake did not find one.

  Could not find a package configuration file provided by "hsa-runtime64"
  with any of the following names:

hsa-runtime64Config.cmake
hsa-runtime64-config.cmake

  Add the installation prefix of "hsa-runtime64" to CMAKE_PREFIX_PATH or set
  "hsa-runtime64_DIR" to a directory containing one of the above files.  If
  "hsa-runtime64" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/hip/hip-config.cmake:215 (find_dependency)
  CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!

Build log after `apt install libhsa-runtime-dev`:

# CXX=hipcc cmake -S. -Bbuild
-- The CXX compiler identification is Clang 15.0.7
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/hipcc - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- hip::amdhip64 is SHARED_LIBRARY
-- Performing Test HIP_CLANG_SUPPORTS_PARALLEL_JOBS
-- Performing Test HIP_CLANG_SUPPORTS_PARALLEL_JOBS - Failed
-- Configuring done
-- Generating done

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

Kernel: 

Bug#1031188: linux: synaptics speed/sensitivity messed up with 6.1.0-4

[Christoph Anton Mitterer]

Hey Salvatore.

On Wed, 2023-02-15 at 07:12 +0100, Salvatore Bonaccorso wrote:
> Just to be sure, that I understood you correctly. That is if on the
> current system with the issue you roll back just only the kernel back
> to 6.1.8-1, then the issue dissaper? 

Exactly, and the roll back even only in the sense of just booting the
previous one (I do not even reinstall packages or so).


> If this is the case, would you be testing as well directly 6.1.8 and
> 6.1.11 upstream (please do as well 6.1.12, 6.1.12-1 though just
> uploaded to unstable earlier today), and if reproducible, bisect the
> changes between the two versions to find the introducing bad commit?

I've tested 6.1.12 in the meantime, ... still has the problem.

In fact it seems as if any changes I make with the synclient tool to
the relevant settings e.g.:
$ synclient MinSpeed=0.5 MaxSpeed=1.5 AccelFactor=0.5
have no longer any effect at all.

Even if I set extreme values, nothing seems to change.


I've also taken the src:linux package (as of 6.1.12) recompiled it just
with:
6816478c0db15ad0dbe7f9b6ffaff9ad6db5e74d
reverted.
That seemed the most promising one, despite me NOT having an HP
notebook (which that commit is allegedly about, but rather a Fujitsu).

But no change with that.


If you want me to test 6.1.8/12 upstream... is it enough to simply take
the Debian source packages and unapply any Debian patches?
I'm always quite reluctant of taking any code which I cannot properly
verify myself (and I don't trust github or https enough ;-) )


Thanks,
Chris.

Bug#1031309: accountsservice: accounts-daemon service will prevent system boot if shadowconfig is off

[Simon McVittie]

Control: tags -1 + pending

On Tue, 14 Feb 2023 at 14:53:34 -0500, john amidon wrote:
> I set shadowconfig to 'off' when I edited '/etc/group'

I would strongly recommend not doing this: it makes the hashed passwords
of all users visible in /etc/passwd, defeating the purpose of having
/etc/shadow, and is also an uncommon (and therefore rarely-tested)
configuration that is quite likely to trigger things like this.

But, yes, accounts-daemon shouldn't be crashing in this situation. This
is a regression from fixing #1030262. I can see why this is happening,
and I'll aim to upload a fix tomorrow.

smcv

Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[Santiago Vila]

severity 1014662 important
thanks

Note: I'm restoring the original severity because Martin Pitt says
in #1027050 that the fatal failure is due to wait-for-root, not flock.

(However, I could not imagine an upload fixing #1027050 which
would not fix this one in the same upload as well).

Thanks.

Bug#1031525: c-ares: CVE-2022-4904

[Gregor Jasny]

Hi Salvatore,

On 17.02.23 21:31, Salvatore Bonaccorso wrote:

The following vulnerability was published for c-ares.

CVE-2022-4904[0]:
| buffer overflow in config_sortlist() due to missing string length check


I uploaded a fixed package for sid and prepared an update for bullseye 
and buster:


https://salsa.debian.org/debian/c-ares/-/commits/bullseye/
https://salsa.debian.org/debian/c-ares/-/commits/buster/

Are you a member of the Debian Security team and could give me the green 
light to upload those two packages into the "security upload queue".


Thanks,
Gregor

Bug#1027050: growing image fails to boot: /scripts/local-bottom/growroot: line 97: wait-for-root: not found

[Santiago Vila]

severity 1027050 serious
tags 1027050 + patch
thanks

Martin Pitt wrote:

The "flock: not found" is #1014662, but that is already present in our current
image with cloud-initramfs-tools 0.18.debian8, and does not seem fatal. So far
the "wait-for-root: not found" seems to be the culprit?


That's what it seems, yes. There is a fix here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014662#34

I've just tested it and it seems to work.

Thanks.

Bug#1031432: FTBFS: java.util.MissingResourceException: Can't find bundle for base name com.google.javascript.rhino.head.resources.Messages, locale en

[Markus Koschany]

Control: reassign -1 rhino


I have recently updated src:rhino and it seems this is caused by the rhino
script or one of the other scripts in the rhino binary package. Initially I
assumed that the error

java.util.MissingResourceException: Can't find bundle for base name
com.google.javascript.rhino.head.resources.Messages, locale de

was specific to my locale and that it should work with English and French as
stated by upstream here

https://github.com/mozilla/rhino/issues/382

Not sure what is currently missing but I don't think closure-compiler is to
blame here hence I'm going to reassign these bugs to rhino.

Markus 



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

Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[Santiago Vila]

El 17/2/23 a las 22:57, Ross Vandegrift escribió:

On Fri, Feb 17, 2023 at 09:54:08PM +0100, Santiago Vila wrote:

After applying the suggested patch, the reported error
does not show anymore.

Instead, I get this:

/scripts/local-bottom/growroot: line 97: wait-for-root: not found

Where does this "wait-for-root" come from?
I can't find it in any package.


There's a relevant MR in salsa:
https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/2

Would you mind testing the patch there?


Yes, I confirm that your patch works. Thanks a lot!


I don't know how widely used this package is.


It's used by Hetzner, which has a lot of customers (I'm one of them).

Without a fix for this, they will be unable to offer images for Debian 12
which actually work (people will wonder why instances with 80 GB of disk
appear to have only 20 GB).

Thanks.

Bug#1031441: Relax oauth2 dependency

[Daniel Leidert]

I just rebuilt ruby-github-api by relaxing the dependency on oauth2. I
pulled the test cases from github to check if anything happens. It
built just fine. 6 tests failed, but none related to OAuth2 (seems some
keywords/options mismatch).

I think we could fix this by relaxing the dep on oauth2 for now.

There is an upstream report asking for supporting oauth2 2.x at
https://github.com/piotrmurach/github/issues/386.

Regards, Daniel

Bug#916878: New qpsmtpd 1.0.0 release

[Kjetil Kjernsmo]

Hi!

qpsmtpd has just now seen a new release, the first one in 7 years. 

It would be wonderful if it could make it into bookworm, but I realize that's 
a long shot by now. OTOH, there aren't a lot of users and I suspect all of 
them would appreciate if it did get in.

There are some scripts in this PR that might be helpful:
https://github.com/smtpd/qpsmtpd/pull/299

Cheers,

Kjetil

Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Rebecca N. Palmer]

Possibly useful here: gdb disassemble works inside pocl kernels, see 
#920497 for an example.

Bug#287371: xsltproc: Probable memory leak (when using document()?)

[Diederik de Haas]

Control: tag -1 unreproducible

On Wed, 9 Feb 2005 17:12:21 +0100 Mike Hommey  wrote:
> On Dec 27, 2004, Vincent Lefevre  wrote:
> > Package: xsltproc
> > Version: 1.1.8-5
> > 
> > Here xsltproc takes up to 138 MB, making the whole system slow down
> > due to swapping. This problem occurs when generating my blog page,
> > where a document() is used for each blog item (this will change in
> > the future, but the current behavior shouldn't occur). The sources
> > are in a DocBook-based DTD that can be downloaded from
> > 
> >   http://www.vinc17.org/DTD/website.dtd
> > 
> > I'm not including the XML sources since this is quite complicated
> > (lots of inclusions and dependencies). But if the bug is not known,
> > I could try to build a simpler example.
> 
> How big is the document you load with document() ? How many times it
> gets loaded ? Could you provide me the files ?

The year is 2023, which means that 18 YEARS ago you were asked to provide a 
sample document ... which still hasn't happened.
It was reported again xslt version 1.1.8-5 with some mention of version 
2.6.16-1 of libxml2 ... both are ANCIENT, but no newer 'found' version was 
reported.

Just for fun, I downloaded your dtd (attached) and noticed a MathML entity 
which refers to DTD: "http://www.w3.org/TR/MathML2/dtd/mathml2.dtd
Trying to load that document gives a 404, but I found the following:
https://www.w3.org/TR/MathML2/appendixa.html#parsing.usingdtdt

My XML knowledge is a bit rusty, but that means your *custom made* DTD is 
invalid? 

On Sat, 19 Feb 2022 18:28:00 +0100 Vincent Lefevre  wrote:
> I'll test again (I've been using a fake DTD for the past 15 years).

IOW: you're not using your own DTD ... otherwise you might have noticed it's 
no longer valid?

What I do recall from when I was full into XML and related technologies is 
that it indeed uses a lot of memory.
As mentioned in 2005, 138MB is not considered *that* much.
And in 2023 that is even more true.

But you have a machine with *unspecified* but apparently very limited resources 
and there you try to load a *custom made* DTD which is probably quite complex 
(MathML can't be simple AFAIK).
"What could possibly go wrong (tm)"

On Sat, 19 Feb 2022 18:01:52 +0100 Mattia Rizzolo  wrote:
> If you believe so, and you confirmed that it hasn't been fixed in the
> past 15 years, could you please either (or both):
>  * report it to mitre's CVE form
>  * report it in https://gitlab.gnome.org/GNOME/libxml2/-/issues
> ?

That request was made a YEAR ago, but I'm not seeing a 'forwarded'? Or a link 
to a CVE item?

And the final message in this bug is that you run Out Of Memory, so the OOM 
killer does exactly what it needs to do: kill other programs.
But yet, you conclude that this is all xsltproc's fault?

There was no action on this bug for ~ 17 years, any requested information was 
not provided, the issue was not made reproducible, it was not reported 
upstream and I'm probably 'forgetting' a few items.

How in the world could this possibly be considered Release Critical?

I'll leave changing the severity to the maintainer, but 'wishlist' seems 
appropriate to me.

website.dtd
Description: application/xml-dtd


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

Bug#1031534: firmware-linux-nonfree: Package removed from sid and bookworm

[Cyril Brulebois]

Gregor Riepl  (2023-02-17):
> > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#non-free-split
> 
> Oh, I just saw that this page mentions that apt should have shown a
> notice to previous users of firmware-linux-nonfree, but I never saw
> this notice.

Note the “If you were”.

> How exactly was this implemented, and what could be the reason why I
> didn't see it?

This is WIP: https://salsa.debian.org/apt-team/apt/-/merge_requests/282


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1031505: redmine: Install (upgrade) 5.x on Bullseye fails on NameError Redmine::Plugin

[Jakob Haufe]

Control: tag -1 + moreinfo unreproducible

We discussed this in IRC (#debian-ruby in OFTC, feel free to pass by)
and couldn't reproduce the problem.

We installed redmine 4.0 from buster backports and updated the VM to
bullseye, once by installing only the minimum set of packages from
backports and once by installing as much as possible from backports.

Both installs and updates worked fine.

To help investigate this further, could you please provide us with the
following:

1. Any plugins you have installed in redmine, either via the Debian
   repository or manually.
2. The output of apt-forktracer (from the package with the same name).

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpUH6MHwA3Ch.pgp
Description: OpenPGP digital signature

Bug#1008306: python3-prometheus-client: Please package new version

[Faidon Liambotis]

Hi Tina!

Hope you're well!

On Fri, Feb 17, 2023 at 05:15:37PM +, Martina Ferrari wrote:
> > We're now almost a year later, and unfortunately past the bookworm
> > freeze. While the Debian package is still at 0.9.0 (what bullseye was
> > released with), Upstream is now at 0.16.0, including several important
> > bugfixes and enhancements :( Sadly, I didn't notice it earlier,
> > otherwise I would have tried to help.
> 
> I am sorry about this, it completely fell out of my radar, I have not had
> much time for packaging work during the last year. I guess at this stage of
> the freeze it would not be ok to update it?

I think technically it falls outside the rules of the freeze -- but by a
very small margin (less than a week!) and a somewhat long time ahead, so
I think the RT may show some leniency :)

> > Can I ask for this package to be more adequately maintained for trixie?
> > Perhaps it could be transferred under the maintenance of the Python Team
> > so that others such as myself can help?
> 
> We have kept it in the go team because almost all of the prometheus-related
> packages are there, although de facto we are a small sub-group taking care
> of this packages (with not enough person power, as you can see). We would
> love more help, and if that means transferring to the python team, I would
> not be opposed to that.. It just seemed simpler this way.

Oh, I hadn't realized it was under the Go team? The Maintainer/Uploaders
field suggest that there's only three individuals maintaining this,
hence why I was asking for a team! I'm a member of the Go team project
as well, and that would work equally fine for me -- although honestly
that feels like a bit of an odd fit, given none of this is written in
Go? Broadly speaking I would fear that Go packagers may not be up to
speed with Python buildsystems, best practices as they evolve etc., but
I'm not really opinionated. My only interest was in folks signalling
that it's OK for others to touch their packages and help when life
catches up with the rest.

Best,
Faidon

Bug#1031537: RFS: monitoring-plugins-check-oracle-health/3.3.2.1-1 [ITP] -- Nagios plugin check_oracle_health

[Hilmar Preusse]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package 
"monitoring-plugins-check-oracle-health":

 * Package name : monitoring-plugins-check-oracle-health
   Version  : 3.3.2.1-1
   Upstream contact : Gerhard Laußer 
 * URL  : https://labs.consol.de/nagios/check_oracle_health/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/nagios-team/check-oracle-health
   Section  : net

The source builds the following binary packages:

  monitoring-plugins-check-oracle-health - Nagios plugin check_oracle_health

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

  https://mentors.debian.net/package/monitoring-plugins-check-oracle-health/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/monitoring-plugins-check-oracle-health/monitoring-plugins-check-oracle-health_3.3.2.1-1.dsc

Changes for the initial release:

 monitoring-plugins-check-oracle-health (3.3.2.1-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1031535)

Regards,
  Hilmar Preuße

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1031457: Unreproducible

[Daniel Leidert]

Hi,

I cannot reproduce the issue. Buildd and autopkgtest also don't
indicate any problem. I guess that is a one-off (maybe redis didn't
start for some reason?)

Regards, Daniel


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

Bug#1031536: bullseye-pu: package clamav/0.103.8+dfsg-0+deb11u1

[Sebastian Andrzej Siewior]

Package: release.debian.org
Control: affects -1 + src:clamav
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
Severity: normal

ClamAV upstream released 0.103.8 fixing two CVEs:

- CVE-2023-20032: Fixed a possible remote code execution vulnerability in the
  HFS+ file parser. The issue affects versions 1.0.0 and earlier, 0.105.1 and
  earlier, and 0.103.7 and earlier. Thank you to Simon Scannell for reporting
  this issue.

- CVE-2023-20052: Fixed a possible remote information leak vulnerability in the
  DMG file parser. The issue affects versions 1.0.0 and earlier, 0.105.1 and
  earlier, and 0.103.7 and earlier. Thank you to Simon Scannell for reporting
  this issue.

See,
https://blog.clamav.net/2023/02/clamav-01038-01052-and-101-patch.html

The 0.103.x series is a LTS release.
I did test the release in a Bullseye VM.
The attached diff has the changes to the docs/ folder removed (it is
auto generated by upsteams and contains a lot of noise).
Unstable has been addressed by the upload of 1.0.1.

Sebastian
diff -Nru clamav-0.103.7+dfsg/CMakeLists.txt clamav-0.103.8+dfsg/CMakeLists.txt
--- clamav-0.103.7+dfsg/CMakeLists.txt	2022-07-26 06:32:12.0 +0200
+++ clamav-0.103.8+dfsg/CMakeLists.txt	2023-02-13 01:03:33.0 +0100
@@ -15,7 +15,7 @@
 set(VERSION_SUFFIX "")
 
 project( ClamAV
- VERSION "0.103.7"
+ VERSION "0.103.8"
  DESCRIPTION "ClamAV open source email, web, and end-point anti-virus toolkit." )
 
 set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
diff -Nru clamav-0.103.7+dfsg/configure clamav-0.103.8+dfsg/configure
--- clamav-0.103.7+dfsg/configure	2022-07-26 06:32:39.0 +0200
+++ clamav-0.103.8+dfsg/configure	2023-02-13 01:03:59.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for ClamAV 0.103.7.
+# Generated by GNU Autoconf 2.69 for ClamAV 0.103.8.
 #
 # Report bugs to .
 #
@@ -592,8 +592,8 @@
 # Identity of this package.
 PACKAGE_NAME='ClamAV'
 PACKAGE_TARNAME='clamav'
-PACKAGE_VERSION='0.103.7'
-PACKAGE_STRING='ClamAV 0.103.7'
+PACKAGE_VERSION='0.103.8'
+PACKAGE_STRING='ClamAV 0.103.8'
 PACKAGE_BUGREPORT='https://github.com/Cisco-Talos/clamav/issues'
 PACKAGE_URL='https://www.clamav.net/'
 
@@ -1606,7 +1606,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ClamAV 0.103.7 to adapt to many kinds of systems.
+\`configure' configures ClamAV 0.103.8 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1687,7 +1687,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ClamAV 0.103.7:";;
+ short | recursive ) echo "Configuration of ClamAV 0.103.8:";;
esac
   cat <<\_ACEOF
   --enable-dependency-tracking
@@ -1922,7 +1922,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ClamAV configure 0.103.7
+ClamAV configure 0.103.8
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2550,7 +2550,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ClamAV $as_me 0.103.7, which was
+It was created by ClamAV $as_me 0.103.8, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4308,7 +4308,7 @@
 
 # Define the identity of the package.
  PACKAGE='clamav'
- VERSION='0.103.7'
+ VERSION='0.103.8'
 
 
 # Some tools Automake needs.
@@ -6036,7 +6036,7 @@
 $as_echo "#define PACKAGE PACKAGE_NAME" >>confdefs.h
 
 
-VERSION="0.103.7"
+VERSION="0.103.8"
 
 major=`echo $PACKAGE_VERSION |cut -d. -f1 | sed -e "s/^0-9//g"`
 minor=`echo $PACKAGE_VERSION |cut -d. -f2 | sed -e "s/^0-9//g"`
@@ -31896,7 +31896,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.103.7, which was
+This file was extended by ClamAV $as_me 0.103.8, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -31963,7 +31963,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.103.7
+ClamAV config.status 0.103.8
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
@@ -34813,7 +34813,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.103.7, which was
+This file was extended by ClamAV $as_me 0.103.8, which was
 generated by GNU Autoconf 2.69.  

Bug#1029300: src:tar: fails to migrate to testing for too long

[Mechtilde Stehmann]

Hello Paul,
If it is better for the release, please remove my try to fix it.

Kind regards

--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F

Bug#1031535: ITP: monitoring-plugins-check-oracle-health -- Nagios plugin check_oracle_health

[Hilmar Preusse]

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

* Package name: monitoring-plugins-check-oracle-health
  Version : 3.3.2.1
  Upstream Contact: Gerhard Laußer 
* URL : https://labs.consol.de/de/nagios/check_oracle_health/
* License : GPL-2
  Programming Lang: Perl
  Description : Nagios plugin check_oracle_health

 check_oracle_health is a plugin that can be used to check various
 parameters of an Oracle database.

 - The package delivers many performance metrics from Oracle
   data bases, which can be integerated in Nagios.
 - For now I maintain the package in my private repository,
   later I'll probably move it to the Debian Nagios Maintainer
   Group.

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1031356: pinctrl: linux-image-6.1.0-3-amd64 : kernel NULL pointer dereference with intel pinctrl driver

[Salvatore Bonaccorso]

Hi Frédéric,

On Fri, Feb 17, 2023 at 09:59:06PM +, BUISSON Frederic wrote:
> Hi Salvatore,
> 
> The BIOS update has fixed the bug.
> Thanks for your help.

Thanks for the confirmation!

Regards,
Salvatore

Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[Ross Vandegrift]

On Fri, Feb 17, 2023 at 09:54:08PM +0100, Santiago Vila wrote:
> After applying the suggested patch, the reported error
> does not show anymore.
> 
> Instead, I get this:
> 
> /scripts/local-bottom/growroot: line 97: wait-for-root: not found
> 
> Where does this "wait-for-root" come from?
> I can't find it in any package.

There's a relevant MR in salsa:
https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/2

Would you mind testing the patch there?  I don't know how widely used
this package is.

Thanks,
Ross

Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[undef]

Given that upstream changes to this package haven't been integrated in 
years and this bug being pretty limiting to users, Mobian moved to 
systemd-repart. If it's possible for you I might recommend the same 
solution.


Our experience has been that once implemented it is far more reliable. 
The switch can be seen at 
https://salsa.debian.org/Mobian-team/mobian-recipes/-/merge_requests/67/diffs


Key parts:

1. Partitions need to be GPT

2. Partitions being resized need a specific "parttype" UUID configured 
on them.


3. A simple config file needs to be installed in /etc/repart.d.

Bug#1031534: firmware-linux-nonfree: Package removed from sid and bookworm

[Gregor Riepl]

Package: firmware-linux-nonfree
Version: 20221214-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: onit...@gmail.com

Dear Maintainer,

With the recent upgrade to version 20230210 (or 20230117 on testing), the
package has vanished from the apt cache of two of my bookworm/sid
installations.

apt policy reports that firmware-linux-nonfree is stuck at version 20221214-3
on my systems, with the only available version being the one that is locally
installed. According to https://tracker.debian.org/pkg/firmware-nonfree
everything seems to be fine, but I simply don't see any available upgrades.

Opening https://packages.debian.org/source/unstable/firmware-nonfree reports:

"Package not available in this suite."

Were these packages renamed, or what exactly is going on here?


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

Kernel: Linux 6.1.0-3-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 firmware-linux-nonfree depends on:
ii  firmware-amd-graphics  20221214-3
ii  firmware-misc-nonfree  20221214-3

Versions of packages firmware-linux-nonfree recommends:
ii  amd64-microcode  3.20220411.1
ii  intel-microcode  3.20221108.1

firmware-linux-nonfree suggests no packages.

-- no debconf information

Bug#1031533: simka B-D on libgatbcore-dev which doesn't exist on s390x

[Sergio Durigan Junior]

Source: simka
Version: 1.5.3-6
Severity: serious

Hi,

simka build-depends on libgatbcore-dev, but gatb-core has been recently
patched and stopped building on several architectures, including s390x.
simka's build will FTBFS on those architectures.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1031532: minia B-D on libgatbcore-dev which doesn't exist on several architectures

[Sergio Durigan Junior]

Source: minia
Version: 3.2.6-2
Severity: serious

Hi,

minia build-depends on libgatbcore-dev, but gatb-core has been recently
patched and stopped building on several architectures, including
e.g. s390x, armhf, etc.  bcalm's build will FTBFS on those
architectures.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1031531: mindthegap B-D on libgatbcore-dev which doesn't exist on several architectures

[Sergio Durigan Junior]

Source: mindthegap
Version: 2.3.0-1
Severity: serious

Hi,

mindthegap build-depends on libgatbcore-dev, but gatb-core has been
recently patched and stopped building on several architectures,
including e.g. s390x, armhf, etc.  bcalm's build will FTBFS on those
architectures.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1031530: discosnp B-D on libgatbcore-dev which doesn't exist on several architectures

[Sergio Durigan Junior]

Source: discosnp
Version: 1:2.6.2-1
Severity: serious

Hi,

discosnp build-depends on libgatbcore-dev, but gatb-core has been
recently patched and stopped building on several architectures,
including e.g. s390x, armhf, etc.  bcalm's build will FTBFS on those
architectures.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1031529: bcalm B-D on libgatbcore-dev which doesn't exist on several architectures

[Sergio Durigan Junior]

Source: bcalm
Version: 2.2.3-3
Severity: serious

Hi,

bcalm build-depends on libgatbcore-dev, but gatb-core has been recently
patched and stopped building on several architectures, including
e.g. s390x, armhf, etc.  bcalm's build will FTBFS on those
architectures.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#972146: /usr/share/applications/mono-runtime-common.desktop: should not handle MIME type by executing arbitrary code

[Salvatore Bonaccorso]

Hi Gabriel,

On Thu, Feb 16, 2023 at 11:37:57PM +0100, Gabriel Corona wrote:
> Hi,
> 
> Thanks for the patch!

Thanks for staying on top of the issue!
> 
> This has been fixed in Debian testing and sid. However, stable is still
> affected. I believe it would make sense to port the patch to stable and
> allocate a CVE for this.

The last upload to unstable as NMU was for me personally to near to
the point release before christmas. A while has passed, and have now
proposed the same change for bullseye as well, cf. #1031527. Thanks
for pinging again on it, much appreciated! So the issue will/should be
fixed as well with the upcoming point release.

There is no CVE assigned, if you feel strong about it, can you try to
get one allocated by MITRE via the cveform? I think we won't go trough
the needed workflow to assign a Debian specific CVE id for it. But we
will see what MITRE will respond on the request.

Regards,
Salvatore

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Fri, Feb 17, 2023 at 12:43:01PM -0700, Sam Hartman wrote:
> 
> I am not entirely convinced that using current rather than guest
> tools for image building is an anti-pattern.  You've been working on
> filesystems for a long time; I've been working on various image
> building projects since my first watchmaker project at MIT.

For what it's worth, I've been building test appliances[1] for the
purposes of file system testing since 2013 (initially just for Qemu,
but now for Cloud[2] environments as well as Android[3]).  Admittedly,
I haven't been doing this as long as you, but I'm not unfamiliar with
building appliance images using debootstrap, and I've *always* built
my KVM/Qemu images using a build chroot[4], including the mkfs and
debootstrap steps.

[1] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/gen-image
[2] https://thunk.org/gce-xfstests
[3] https://thunk.org/android-xfstests
[4] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot

So I'm happy to talk to you off-line about best practices for building
images, but this is something that I do *regularly*, since there are
weekly updates from upstream xfstests.  Thus, I have personal
experience that using a build chroot for image creation really is
*not* *that* *hard*.  For that matter, when I'm doing test appliance
development, I'm running regression tests[5] several times a day which
build images in a chroot.

[5] https://github.com/tytso/xfstests-bld/blob/master/selftests/appliance

Everything is automated.  No fuss, no muss, no dirty dishes.  :-)
Futher, it provides better build reproducibility, no matter who is
building the image, and it also makes full GPL compliance (if you are
publishing the test appliances) much, *much* easier --- I can provide
an exhaustive list of all components (including mkfs.ext4!) and control
scripts involved with the creation of the image.

Cheers,

- Ted

Bug#1031528: gnome-shell-pomodoro: Screen overlay can't be cleared

[Richard Ayotte]

Package: gnome-shell-pomodoro
Version: 0.22.0-1
Severity: normal
X-Debbugs-Cc: r...@ayottesoftware.com

Dear Maintainer,

A new version which contains numerous bug fixes is available.

Release version 0.22.1:

* Close screen overlay by hitting Esc key - a failsafe method
* Don't open screen overlay while a video call app is fullscreen
* Fixed screen overlays timer label getting ellipsized
* Fixed screen overlay being over screensaver animation
* Add --reset commandline option

See: https://github.com/gnome-pomodoro/gnome-pomodoro/blob/master/NEWS

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

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

Versions of packages gnome-shell-pomodoro depends on:
ii  gnome-shell43.3-1
ii  gnome-shell-pomodoro-data  0.22.0-1
ii  libc6  2.36-8
ii  libcairo2  1.16.0-7
ii  libcanberra0   0.30-10
ii  libglib2.0-0   2.74.5-1
ii  libgom-1.0-0   0.4-1
ii  libgstreamer1.0-0  1.22.0-2
ii  libgtk-3-0 3.24.36-4
ii  libpeas-1.0-0  1.34.0-1+b1
ii  libsqlite3-0   3.40.1-1

gnome-shell-pomodoro recommends no packages.

gnome-shell-pomodoro suggests no packages.

-- no debconf information

Bug#1031527: bullseye-pu: package mono/6.8.0.105+dfsg-3.3~deb11u1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: m...@packages.debian.org, Debian Mono Group 
, Jo Shields , 
Gabriel Corona , car...@debian.org
Control: affects -1 + src:mono

Hi stable release managers,

Please consider accepting the mono change for the next bullseye point
release, following unstable and testing, to address #972146, which may
lead arbitrary code execution, as mentioned in the original post and
as well Gabriel Corona posted on
https://www.openwall.com/lists/oss-security/2023/01/05/1 .  (No CVE is
assigned for it).

The proposed (and already uploaded) change consist of simply
rebuilding the current testing version for bullseye.

Full debdiff attached.

Regards,
Salvatore
diff -Nru mono-6.8.0.105+dfsg/debian/changelog 
mono-6.8.0.105+dfsg/debian/changelog
--- mono-6.8.0.105+dfsg/debian/changelog2021-06-29 22:33:21.0 
+0200
+++ mono-6.8.0.105+dfsg/debian/changelog2023-02-17 06:30:39.0 
+0100
@@ -1,3 +1,17 @@
+mono (6.8.0.105+dfsg-3.3~deb11u1) bullseye; urgency=medium
+
+  * Rebuild for bullseye
+
+ -- Salvatore Bonaccorso   Fri, 17 Feb 2023 06:30:39 +0100
+
+mono (6.8.0.105+dfsg-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert "Added desktop file for mono with and without a terminal window"
+(Closes: #972146)
+
+ -- Salvatore Bonaccorso   Fri, 09 Dec 2022 14:33:03 +0100
+
 mono (6.8.0.105+dfsg-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mono-6.8.0.105+dfsg/debian/mono-runtime-common.desktop 
mono-6.8.0.105+dfsg/debian/mono-runtime-common.desktop
--- mono-6.8.0.105+dfsg/debian/mono-runtime-common.desktop  2021-06-29 
22:33:21.0 +0200
+++ mono-6.8.0.105+dfsg/debian/mono-runtime-common.desktop  1970-01-01 
01:00:00.0 +0100
@@ -1,8 +0,0 @@
-[Desktop Entry]
-Name=Mono Runtime
-Exec=mono
-Terminal=false
-Type=Application
-Icon=mono-runtime-common
-MimeType=application/x-ms-dos-executable;
-NoDisplay=true
diff -Nru mono-6.8.0.105+dfsg/debian/mono-runtime-common.install 
mono-6.8.0.105+dfsg/debian/mono-runtime-common.install
--- mono-6.8.0.105+dfsg/debian/mono-runtime-common.install  2021-06-29 
22:33:21.0 +0200
+++ mono-6.8.0.105+dfsg/debian/mono-runtime-common.install  2022-12-09 
14:32:09.0 +0100
@@ -8,6 +8,3 @@
 /usr/lib/libMonoSupportW.so
 /usr/lib/libmono-native.so*
 /usr/bin/mono-hang-watchdog
-debian/mono-runtime-common.png /usr/share/pixmaps
-debian/mono-runtime-common.desktop /usr/share/applications
-debian/mono-runtime-terminal.desktop /usr/share/applications
Binary files /tmp/pOJGD4X6BP/mono-6.8.0.105+dfsg/debian/mono-runtime-common.png 
and /tmp/q7WuSbASt4/mono-6.8.0.105+dfsg/debian/mono-runtime-common.png differ
diff -Nru mono-6.8.0.105+dfsg/debian/mono-runtime-terminal.desktop 
mono-6.8.0.105+dfsg/debian/mono-runtime-terminal.desktop
--- mono-6.8.0.105+dfsg/debian/mono-runtime-terminal.desktop2021-06-29 
22:33:21.0 +0200
+++ mono-6.8.0.105+dfsg/debian/mono-runtime-terminal.desktop1970-01-01 
01:00:00.0 +0100
@@ -1,8 +0,0 @@
-[Desktop Entry]
-Name=Mono Runtime (Terminal)
-Exec=mono
-Terminal=true
-Type=Application
-Icon=mono-runtime-common
-MimeType=application/x-ms-dos-executable;
-NoDisplay=true

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Tatsuya Kinoshita]

On 2023-02-17 at 09:42 -0700, Sean Whitton wrote:
> So: commit ce4a066ed1e fixes Debian bug #1021842 without the env var.

On 2023-02-14 at 11:32 +, Andrea Corallo wrote:
> Stefan Monnier  writes:
> > `temporary-file-directory' may point to a world-writable directory, so
> > it's vulnerable to the usual race condition where someone manages to
> > predict the name of the file you're going to write and places there
> > a symlink to some "interesting" place, so you end up overwriting some
> > other file unwittingly.
> 
> Okay, ce4a066ed1e generates trampolines in a temporary directory if no
> other option is viable (using the make-temp-file machinery to generate
> the unpredictable name).

> +   finally (cl-return
> +(expand-file-name
> + (make-temp-file-internal (file-name-sans-extension rel-filename)
> +  0 ".eln" nil)
> + temporary-file-directory

Hmm, it seems using make-temp-file-internal with DIR-FLAG=0 which just
constructs a name and do not create the file like make-temp-name, so
there is a race condition as Stefan mentioned.  Is that really OK?

Thanks,
-- 
Tatsuya Kinoshita

Bug#1029260: vice: missing font license in d/copyright

[GCS]

Control: found -1 2.1.dfsg-1
Control: severity -1 important

On Sun, Jan 29, 2023 at 4:03 PM Bastian Germann  wrote:
> So if that font is not GPL-compibly licensed, CBM cannot be GPL licensed.
 It's mentioned as '100% free' and was added to the VICE project in
its 1.22.9 release. The first package version uploaded with it is
2.1.dfsg-1 from March, 2009.

Cheers,
Laszlo/GCS

Bug#1031526: link-grammar: FTBFS on riscv64 (test failure)

[Eric Long]

Source: link-grammar
Version: 5.12.0~dfsg-2
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: i...@hack3r.moe, debian-ri...@lists.debian.org

Dear maintainer,

link-grammar failed to build on riscv64 due to not linking to libatomic during
test:

```
FAIL: tests.py
==
   link-grammar 5.12.0: bindings/python-examples/test-suite.log
==

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests
===

Running by: /usr/bin/python3
Running ./tests.py in: /<>/bindings/python-examples
PYTHONPATH=./../python:../python:../python/.libs
srcdir=.
LINK_GRAMMAR_DATA=./../../data
Traceback (most recent call last):
  File "/<>/bindings/python/linkgrammar.py", line 10, in 
import linkgrammar.clinkgrammar as clg
ModuleNotFoundError: No module named 'linkgrammar.clinkgrammar'; 'linkgrammar' 
is not a package

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/<>/bindings/python-examples/./tests.py", line 24, in 

from linkgrammar import (Sentence, Linkage, ParseOptions, Link, Dictionary,
  File "/<>/bindings/python/linkgrammar.py", line 13, in 
import clinkgrammar as clg
  File "/<>/bindings/python/clinkgrammar.py", line 12, in 
import _clinkgrammar
ImportError: /<>/link-grammar/.libs/liblink-grammar.so.5: 
undefined symbol: __atomic_fetch_add_2
FAIL tests.py (exit status: 1)

```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=link-grammar=riscv64=5.12.0%7Edfsg-2=1674569454=0

This can be fixed by adding -latomic in d/rules, which is done using the
attached patch. If more help is needed, please let me know.

Cheers,
Eric
diff -Nru link-grammar-5.12.0~dfsg/debian/changelog 
link-grammar-5.12.0~dfsg/debian/changelog
--- link-grammar-5.12.0~dfsg/debian/changelog   2023-01-24 13:40:52.0 
+0800
+++ link-grammar-5.12.0~dfsg/debian/changelog   2023-02-18 04:24:12.0 
+0800
@@ -1,3 +1,10 @@
+link-grammar (5.12.0~dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on riscv64
+
+ -- Eric Long   Sat, 18 Feb 2023 04:24:12 +0800
+
 link-grammar (5.12.0~dfsg-2) unstable; urgency=medium
 
   * fix source helper tool copyright-check
diff -Nru link-grammar-5.12.0~dfsg/debian/rules 
link-grammar-5.12.0~dfsg/debian/rules
--- link-grammar-5.12.0~dfsg/debian/rules   2023-01-24 13:29:11.0 
+0800
+++ link-grammar-5.12.0~dfsg/debian/rules   2023-02-18 04:24:12.0 
+0800
@@ -14,6 +14,11 @@
 export DEB_CXXFLAGS_MAINT_APPEND=-O3
 endif
 
+ifeq ($(DEB_HOST_ARCH),riscv64)
+DEB_CFLAGS_MAINT_APPEND+=-latomic
+DEB_CXXFLAGS_MAINT_APPEND+=-latomic
+endif
+
 no_java_archs = hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 m68k sh4
 ifneq (,$(filter $(DEB_HOST_ARCH), $(no_java_archs)))
 CONFIGURE_ARGS += --disable-java-bindings

Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[Santiago Vila]

After applying the suggested patch, the reported error
does not show anymore.

Instead, I get this:

/scripts/local-bottom/growroot: line 97: wait-for-root: not found

Where does this "wait-for-root" come from?
I can't find it in any package.

Thanks.

Bug#1031435: python-inotify: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Lucas Nussbaum]

Hi,

On 17/02/23 at 20:17 +0100, Timo Röhling wrote:
> Control: tags -1 + moreinfo
> 
> Hi Lucas,
> 
> this seems to be bug #1030493 again.
> 
> On Fri, 17 Feb 2023 07:50:37 +0100 Lucas Nussbaum  wrote:
> > > E   -   '')]
> > > E   ?  ^
> > > E   > E   +   ''),
> > > E   ?  ^
> > > E   > E   +  (_INOTIFY_EVENT(wd=1, mask=1073742336,
> > cookie=0, len=16),
> > > E   +   ['IN_DELETE', 'IN_ISDIR'],
> > > E   +   '/tmp/tmpmmbhfdhl',
> > > E   +   'new_folder')]
> 
> Apparently, the returned order of INOTIFY_EVENTS is different with
> your builds than it is on the buildds, my machine, and Bastian's
> machine. Neither Bastian nor I could reproduce the bug. Initially, I
> assumed this is some sort of flakiness and added test retries, but
> it looks like your build system always returns events in a
> different order (or at least often enough so two retries are not
> sufficient).
> 
> I suspect that you are using a different filesystem, which processes
> changes differently and thus makes the inotify API return events in
> a different order, but I don't know for sure.

I'm using ext4, so this is unlikely.

> Can you help us track down the underlying cause, so we can reproduce
> the failure and then think of an appropriate way to work around it?

Sure. I took a look, and it seems that the different behaviour is caused
by me running an old stable kernel, rather than the latest one.

With:
Linux 5.10.0-9-cloud-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) amd64 (x86_64)
it fails consistently.
With:
Linux 5.10.0-21-cloud-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) amd64 (x86_64)
It works consistently.


Just upgrading the kernel makes the problem disappear for me. So you
should be able to reproduce the problem by downgrading the kernel (using
snapshot.d.o).

I had not updated the image (AWS AMI) I am using for the rebuilds for a
long time. Sorry about that.

Lucas

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Fri, Feb 17, 2023 at 02:08:28PM -0500, Theodore Ts'o wrote:
>...
> So enabling what may be
> convenient, but ultimately an anti-pattern is something that hopefully
> in the long-term Debian should be striving towards.  Yes, it's
> annoying and and extra work.  So is using build chroots if we are
> building packages for a older Distro versions.  But it's the right
> thing to do.

Don't assume "host = target" would always be possible.

Your proposed solution only works for the trivial
"building Debian on Debian" case.

The same general problem applies in various "building non-Debian 
embedded Linux filesystem on Debian" situations where the target
chroot does not contain mkfs.ext4.

Or if it is present, it would be a chroot for the target architecture 
where you might have to run mkfs.ext4 under qemu.

All image building tools that support bookworm (including all image 
building tools we ship in bookworm) have to ensure that what they
produce works on the intended target. There is no general solution
*how* to do that that could be applied in all cases.

> Secondly, (b) there may be a misapprehension that it is possible to
> get an identical file system just by controlling the contents of
> mke2fs and/or specifying the file system features on the command line.
>...

It is clear that different versions of tools like mkfs.ext4 or gzip 
might produce different output.

If identical results matter, you can just define $distribution as
build environment and then expect that for example the host tools
from Debian bookworm will always create the same output when building
a Yocto distribution.

> Best regards,
> 
>   - Ted

cu
Adrian

Bug#1031525: c-ares: CVE-2022-4904

[Salvatore Bonaccorso]

Source: c-ares
Version: 1.18.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/c-ares/c-ares/pull/497
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: fixed -1 1.19.0-1

Hi,

The following vulnerability was published for c-ares.

CVE-2022-4904[0]:
| buffer overflow in config_sortlist() due to missing string length check

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-2022-4904
https://www.cve.org/CVERecord?id=CVE-2022-4904
[1] https://github.com/c-ares/c-ares/pull/497
[2] 
https://github.com/c-ares/c-ares/commit/9903253c347f9e0bffd285ae3829aef251cc852d

Regards,
Salvatore

Bug#1031524: fuse3: setxattr is broken

[Graham Inggs]

Source: fuse3
Version: 3.13.0-1
Severity: serious
Forwarded: https://github.com/libfuse/libfuse/issues/730
Control: affects -1 src:ostree

Hi Maintainer

Since the upload of 3.13.0-1, the 'name' string passed to
fs->op.setxattr has the first 8 characters missing.

Steps to reproduce:

$ dget https://deb.debian.org/debian/pool/main/f/fuse3/fuse3_3.14.0-1.dsc
$ cd fuse3-3.14.0/
$ debuild -us -uc
$ cd obj-x86_64-linux-gnu/example/
$ mkdir mnt/
$ ./passthrough mnt/
$ touch mnt/tmp/anewfile-for-fuse
$ setfattr -n user.foo -v bar mnt/tmp/anewfile-for-fuse
setfattr: mnt/tmp/anewfile-for-fuse: Numerical result out of range

Now try setfattr again with 8 dummy characters in front of the name string:

$ setfattr -n 12345678user.foo -v bar mnt/tmp/anewfile-for-fuse
$ getfattr -d -m . mnt/tmp/anewfile-for-fuse
# file: mnt/tmp/anewfile-for-fuse
user.foo="bar"

$ umount mnt/
$ rmdir mnt/

Regards
Graham

Bug#1031315: libjpeg9: libjpeg.so.9* missing

[Bill Allombert]

On Wed, Feb 15, 2023 at 05:45:26AM +0800, Roy Clark (kralcyor) wrote:
> Package: libjpeg9
> Version: 1:9d-1.1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> /usr/lib/*/{libjpeg.so.9,libjpeg.so.9.4.0} are missing in the package, making 
> it completely unusable:
> $ dpkg -L libjpeg9 
> /.
> /usr
> /usr/share
> /usr/share/doc
> /usr/share/doc/libjpeg9
> /usr/share/doc/libjpeg9/README.gz
> /usr/share/doc/libjpeg9/changelog.Debian.gz
> /usr/share/doc/libjpeg9/changelog.gz
> /usr/share/doc/libjpeg9/copyright
> 
> This issue may related to changes in the build system. While libjpeg.so.9* 
> appear in the old version 1:9d-1, a rebuilt package of version 1:9d-1 on a 
> latest unstable Debian system also lacks libjpeg.so.9*.

Ah thanks. I should have checked that the NMU was correct.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1031213: Intent to NMU libpam-ldap to fix longstanding l10n bugs

[Helge Kreutzmann]

Hello Lucas,
I intend to NMU libpam-ldap around 2023-03-01 to fix a longstanding l10n
bug[1]. The changelog would be something like the following:

 libpam-ldap (186-4.2) unstable; urgency=medium

   * Non-maintainer upload.
   * Update debconf template translation
 - Turkish translation.
   Thanks to Atila KOÇ (Closes: #1031213)

Please tell me if you are currently preparing a new release yourself
and would like me to skip the NMU.

Greetings

 Helge

[1] https://i18n.debian.org/nmu-radar/nmu_bypackage.html

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


signature.asc
Description: PGP signature

Bug#1024696: Intent to NMU powerline to fix longstanding l10n bugs

[Helge Kreutzmann]

Hello Samuel,
On Sun, Feb 12, 2023 at 08:50:19PM +, Samuel Henrique wrote:
> > Could we make it more simple and straightforward?
> >
> > You add me (kreutzm-guest) temporarily to your team and I directly
> > commit the proposed update to your git repository. Then you review it
> > and perform the upload? In case you have anything else, you could
> > easily add it then.
> 
> Sounds good, I have given you permission to push to the salsa repo.

Thanks and done.

Please add anything you have in the queue and upload.

Greetings

 Helge

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


signature.asc
Description: PGP signature

Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Paul Gevers]

Hi,

On 16-02-2023 23:34, Andreas Beckmann wrote:

@elbrus: Why does britney try to migrate clinfo together with pocl?


Honestly, I don't know. The logic that does that *is* rather greedy as 
often it helps (but not always).


IMO clinfo should be able to migrate on its own without causing new 
regressions in testing. It does not have any (transitive) dependency on 
pocl.


I have scheduled the job with only clinfo from unstable and the test 
passed. So I think clinfo can just migrate after the information becomes 
available.


Thanks.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Theodore" == Theodore Ts'o  writes:


Theodore> So enabling what may be convenient, but ultimately an
Theodore> anti-pattern is something that hopefully in the long-term
Theodore> Debian should be trying to *avoid*.

That's certainly true.
I am not entirely convinced that using current rather than guest tools
for image building is an anti-pattern.
You've been working on filesystems for a long time; I've been working on
various image building projects since my first watchmaker project at
MIT.

I can understand the arguments about why it's an anti-patern, but I can
also understand why it may be the correct answer.
I'd love to have that discussion with you some time, although preferably
not on a bug like this, and I'm not entirely sure my thoughts are
organized enough for a large mailing list discussion.

I think that discussion is clearly well beyond the scope of what the RT
needs to make an immediate decision here.


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Fri, Feb 17, 2023 at 02:08:28PM -0500, Theodore Ts'o wrote:
> So enabling what may be
> convenient, but ultimately an anti-pattern is something that hopefully
> in the long-term Debian should be striving towards.

Sigh, I managed to invert the sense of what I was trying to say.  This
should have read:

So enabling what may be convenient, but ultimately an anti-pattern is
something that hopefully in the long-term Debian should be trying to
*avoid*.

- Ted

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii]

> From: Sean Whitton 
> Cc: Eli Zaretskii ,  aymeric.a...@yandex.com,
>   monn...@iro.umontreal.ca,  emacs-de...@gnu.org,  la...@gnus.org,
>   r...@defaultvalue.org
> Date: Fri, 17 Feb 2023 09:42:29 -0700
> 
> > Otherwise you have to revert probably 654428b65ae and 2f28496d038 and
> > cherry pick in order 1795839babc 5d0912f1445 and ce4a066ed1e from
> > feature/inhibit-native-comp-cleanup.  But this is a blind guess, I can't
> > guarantee it to work without trying it.
> 
> Those are the right ones!
> 
> So: commit ce4a066ed1e fixes Debian bug #1021842 without the env var.

Thanks for testing.

Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[Santiago Vila]

severity 1014662 serious
tags 1014662 + patch
thanks

I can reproduce this as well.

I have a packer setup which takes a Hetzner cx11 instance (the smallest
available size), upgrades it to bookworm, installs some extra packages,
and then takes a snapshot.

This used to work before I added the "upgrades it to bookworm" part.

Now it does not work, and as a result, the images only work ok
if I create an instance of the same size that was used to create
the image.

undef  wrote:

Without updating to the latest upstream version, simply adding
`copy_exec /bin/flock /bin` to the growroot hook also solves the issue.


I've converted the above hint into a patch.

(using /usr/bin/flock as the path as that's what dpkg -L util-linux
reports as the canonical location)

Please consider applying the patch before the hard freeze. The package
is not very useful in its current state.

Thanks.--- a/growroot/hooks/growroot
+++ b/growroot/hooks/growroot
@@ -12,5 +12,6 @@ esac
 copy_exec /sbin/sfdisk /sbin
 copy_exec /usr/bin/growpart /sbin
 copy_exec /usr/bin/udevadm /sbin
+copy_exec /usr/bin/flock /bin
 
 # vi: ts=4 noexpandtab

Bug#1031435: python-inotify: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Timo Röhling]

Control: tags -1 + moreinfo

Hi Lucas,

this seems to be bug #1030493 again.

On Fri, 17 Feb 2023 07:50:37 +0100 Lucas Nussbaum  wrote:

> E   -   '')]
> E   ?  ^
> E   
> E   +   ''),

> E   ?  ^
> E   
> E   +  (_INOTIFY_EVENT(wd=1, mask=1073742336, cookie=0, len=16),

> E   +   ['IN_DELETE', 'IN_ISDIR'],
> E   +   '/tmp/tmpmmbhfdhl',
> E   +   'new_folder')]


Apparently, the returned order of INOTIFY_EVENTS is different with
your builds than it is on the buildds, my machine, and Bastian's
machine. Neither Bastian nor I could reproduce the bug. Initially, I
assumed this is some sort of flakiness and added test retries, but
it looks like your build system always returns events in a
different order (or at least often enough so two retries are not
sufficient).

I suspect that you are using a different filesystem, which processes
changes differently and thus makes the inotify API return events in
a different order, but I don't know for sure.

Can you help us track down the underlying cause, so we can reproduce
the failure and then think of an appropriate way to work around it?


Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

On Fri, Feb 17, 2023 at 08:51:33AM -0800, Russ Allbery wrote:
> Adrian Bunk  writes:
> 
> > The image creators could just set the features they enable to what they
> > copied from /etc/mke2fs.conf from the target distribution, a label with
> > a timestamp wouldn'tbring much benefit here.
> 
> That's a very good point and I'm embarrassed it wasn't immediately obvious
> to me.  Sorry about the noise.

One other thing I woud add here is (a) this whole discussion of
mke2fs.conf only helps for ext4, and the general problem is something
that extends to all file system.  The immediate question may be ext4
specific, but as I mentioned earlier, XFS is enabling the "bigtime"
feature for the first time in Bookworm.  So enabling what may be
convenient, but ultimately an anti-pattern is something that hopefully
in the long-term Debian should be striving towards.  Yes, it's
annoying and and extra work.  So is using build chroots if we are
building packages for a older Distro versions.  But it's the right
thing to do.

Secondly, (b) there may be a misapprehension that it is possible to
get an identical file system just by controlling the contents of
mke2fs and/or specifying the file system features on the command line.
While this is mostly true, it is not the whole story.  For example,
the size and location of the journal is determined hueristically, and
in the past, this has changed as we have discovered that (for example)
making the default journal size larger would result in better
performance.  The location of the journal has also changed from the
beginning of storage device (low-numbered LBA's) to the middle of the
device.

So just as a binary compiled using the default gcc on Buster might be
different from a binary build using Sid, even if you you force the use
of older glibc shared libraries at link time or use -static to
statically link with the glibc installed in your random desktop
environment, the results from using mke2fs on Debian N may be
different from using mke2fs on Debian M, even if you control for thea
file system features.  (And other things which _are_ controllable on
mke2fs.conf, but which go beyond mke file system features.  For
example, in Bookworm starting with e2fsprogs 1.46.4, the default inode
size is forced to always be 256 bytes, even for small file systems.
This was not true in Buster and older Debian distributions.)

So if you want a bootable image that is identical to what would be
created by using the Buster or Bullseye debian-interaller, you
*really* want to use the mkfs that was supplied by Buster or Bullseye,
and that means running the mkfs from a chroot.

Best regards,

- Ted

Bug#1031523: ITP: iqmol -- molecular builder and visualization package

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debichem Team 
, Debian Science List 


* Package name: iqmol
  Version : 3.1.2
  Upstream Contact: Andrew Gilbert 
* URL : http://iqmol.org/
* License : GPL
  Programming Lang: C++
  Description : molecular builder and visualization package

IQmol is able to build molecules, set up and submit input for Q-Chem
calculations, and analyse the output. Analyses include display of
molecular surfaces (densites, molecular orbitals) and animations of
frequencies and reaction pathways.

To be maintained by the Debichem Team.

Bug#1031522: yt-dlp: Unable to extract uploader id

[Peter Wienemann]

Package: yt-dlp
Version: 2023.01.06-1
Severity: grave
Tags: fixed-upstream
Justification: renders package unusable

Dear Maintainer,

it seems that version 2023.01.06-1 of yt-dlp suffers from the issue
described in:

https://github.com/yt-dlp/yt-dlp/issues/6247

Upstream has provided a fix for this issue:

https://github.com/yt-dlp/yt-dlp/commit/149eb0bbf34fa8fdf8d1e2aa28e17479d099e26b

Best regards,

Peter

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 yt-dlp depends on:
ii  python33.11.1-3
ii  python3-brotli 1.0.9-2+b6
ii  python3-certifi2022.9.24-1
ii  python3-mutagen1.46.0-1
ii  python3-pkg-resources  66.1.1-1
ii  python3-pycryptodome   3.11.0+dfsg1-4
ii  python3-websockets 10.4-1

Versions of packages yt-dlp recommends:
ii  ca-certificates  20211016
ii  curl 7.87.0-2
ii  ffmpeg   7:5.1.2-2
ii  python3-pyxattr  0.8.0-1+b1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2+b2
ii  wget 1.21.3-1+b2

Versions of packages yt-dlp suggests:
pn  libfribidi-bin | bidiv  
ii  mpv 0.35.1-1
pn  phantomjs   

-- no debconf information

Bug#1019404: wireplumber doesn't start

[matthias . geiger1024]

Hi Adam,

running openRC, I just stole this wrapper script from alpine linux:

https://git.alpinelinux.org/aports/tree/community/pipewire/pipewire-launcher.sh

I moved it to /usr/libexec/pipewire-launcher and it also just *works*. Note 
that one has to run/call the script though dbus, see 
https://wiki.alpinelinux.org/wiki/PipeWire#Runnin 
g. You also will have to 
kill/disable the pulseaudio daemon/service if using pipewire-pulse.

Matthias

PS: this is kinda needed is you want to enable webrtc screensharing in wayland

Bug#987752: ITP: calindori -- convergent calendar app

[Marco Mattiolo]

Hi,

I see this started as RFP and was then changed to ITP and assigned to 
the original bug submitter.


I assume nothing is really going on in order to package calindori for 
Debian. If so, may I take over?


I am already maintaining some Plasma Mobile packages, calindori would be 
a great step to have a complete Plasma Mobile system in Debian repositories.


Kind regards

Marco

Bug#987751: ITP: kalk -- a convergent calculator app

[Marco Mattiolo]

Hi,

I see this started as RFP and was then changed to ITP and assigned to 
the original bug submitter.


I assume nothing is really going on in order to package calindori for 
Debian. If so, may I take over?


I am already maintaining some Plasma Mobile packages, kalk would be a 
great step to have a complete Plasma Mobile system in Debian repositories.


Kind regards

Marco

Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[James Addison]

Package: python3-zstandard
Followup-For: Bug #1031443
Control: forcemerge -1 1031293 1031449

Bug#1031379: kaffeine: does not work

[Marco Mattiolo]

Hi,

I am not the package maintainer, but this bug report is almost useless.

What's the issue? Is kaffeine not starting? Is it crashing? Or is just 
not showing what you expect?


Which kind of DVB device are you using? Have you checked the device to 
work with other apps?


Before flagging this bug report as "grave" (i.e. unusable app), have you 
checked if kaffeine is able to play local media? Imo, this is more 
"important" severity...


Kind regards

Marco

Bug#1030464: aiomysql: FTBFS: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: 'unknown'

[s3v]

Dear Maintainer,

After adding python3-setuptools-scm to build depends, I was able to
build your package in a sid chroot environment.
Please note that the build creates a "aiomysql/_scm_version.py" file
which prevents the next build:


...
dpkg-source: info: using options from aiomysql-0.1.1/debian/source/options: 
--extend-diff-ignore=^[^/]*[.]egg-info/
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building aiomysql using existing ./aiomysql_0.1.1.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: warning: ignoring deletion of file docs/make.bat, use 
--include-removal to override
dpkg-source: info: local changes detected, the modified files are:
 aiomysql-0.1.1/aiomysql/_scm_version.py
dpkg-source: info: Hint: make sure the version in debian/changelog matches the 
unpacked source tree
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/aiomysql_0.1.1-3.diff.1zsVoB
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2


To avoid this, I think the removal needs to be added to the other cleanups in 
debian/rules.

Kind Regards

Bug#1008306: python3-prometheus-client: Please package new version

[Martina Ferrari]

Hi,

On 16/02/2023 16:54, Faidon Liambotis wrote:


We're now almost a year later, and unfortunately past the bookworm
freeze. While the Debian package is still at 0.9.0 (what bullseye was
released with), Upstream is now at 0.16.0, including several important
bugfixes and enhancements :( Sadly, I didn't notice it earlier,
otherwise I would have tried to help.


I am sorry about this, it completely fell out of my radar, I have not 
had much time for packaging work during the last year. I guess at this 
stage of the freeze it would not be ok to update it?



Can I ask for this package to be more adequately maintained for trixie?
Perhaps it could be transferred under the maintenance of the Python Team
so that others such as myself can help?


We have kept it in the go team because almost all of the 
prometheus-related packages are there, although de facto we are a small 
sub-group taking care of this packages (with not enough person power, as 
you can see). We would love more help, and if that means transferring to 
the python team, I would not be opposed to that.. It just seemed simpler 
this way.


--
Martina Ferrari (Tina)

Bug#1031455: charliecloud: FTBFS: config.h:38: error: "PACKAGE_VERSION" redefined [-Werror]

[Peter Wienemann]

Control: reassign -1 src:fuse3
Control: found -1 3.13.1-1
Control: forwarded -1 https://github.com/libfuse/libfuse/issues/729
Control: tags -1 + fixed-upstream
Control: affects -1 src:charliecloud

Dear Lucas,

thanks for reporting this problem. It seems that the root cause of this 
FTBFS issue is a problem which was introduced by fuse3 3.13.1. A fix has 
been provided by upstream:


https://github.com/libfuse/libfuse/commit/d7560cc9916b086bfe5d86459cc9f04033edd904

Best regards,

Peter

Bug#1031521: openjdk-17: ld.so assertion failure with multiple commercial games

[Antoine Le Gonidec]

Source: openjdk-17
Severity: normal

Multiple Java games fail to launch when trying to run them with Debian builds 
of OpenJDK, including:
- Blocks That Matter
- Gathering Sky
- Lenna's Inception
- Slay the Spire
- The Count Lucanor
- Urtuk: The Desolation

All of these games fail to run with OpenJDK > 8, throwing the following error:

Inconsistency detected by ld.so: dl-lookup.c: 107: check_match: Assertion 
`version->filename == NULL || ! _dl_name_match_p (version->filename, map)' 
failed!

Due to the similarities with bug report #982443 
(https://bugs.debian.org/982443), we gave a try to the proposed workaround:

DEB_LDFLAGS_SET='-Wl,-z,relro,--no-as-needed' DEB_BUILD_OPTIONS=nocheck debuild 
--no-sign -b -j4

Using this build of OpenJDK, the listed games work nicely.

More details can be found on ./play.it forge, where we did the original 
investigation:
https://forge.dotslashplay.it/play.it/games/-/issues/880

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

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

Bug#1031520: maxima: triggers kernel error about memory allocation glitch

[Jörg-Volker Peetz]

Package: maxima
Version: 5.46.0-11
Severity: normal

Dear Camm Maguire,

calling maxima generates a kernel message:

kernel: __vm_enough_memory: 1 callbacks suppressed
kernel: __vm_enough_memory: pid: 13721, comm: maxima, no enough memory for the
allocation

The second line appears 10 times. I'm using a self-compiled upstream kernel.
Any idea?

Regards,
Jörg.

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

Kernel: Linux 6.1.11 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages maxima depends on:
ii  libc6  2.36-8
ii  libedit2   3.1-20221030-2
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libtirpc3  1.3.3+ds-1
ii  libx11-6   2:1.8.3-3

Versions of packages maxima recommends:
ii  gnuplot-qt [gnuplot-x11]  5.4.4+dfsg1-2+b2
ii  maxima-share  5.46.0-11

Versions of packages maxima suggests:
ii  maxima-doc5.46.0-11
ii  maxima-emacs  5.46.0-11
pn  texmacs   
ii  tk [wish] 8.6.11+1
pn  xmaxima   

-- no debconf information

Bug#418855: (g)mplayer enters infinite loop when using -loop 0

[Reimar Döffinger]

> On 17 Feb 2023, at 00:49, Lorenzo  wrote:
> 
> Control: tags -1 confirmed upstream
> 
> Hello,
> 
> On Thu, 12 Apr 2007 12:48:08 +0200 Bernard Jungen
>  wrote:
>> Package: mplayer
>> Version: 1.0~rc1-13
>> Severity: minor
>> 
>> gmplayer enters infinite loop when doing the following:
>> [...] 
>> As for mplayer, it continuously displays the error message if the
>> file doesn't exist.
> 
> This is still happening with mplayer 1.5
> 
> $ mplayer -loop 0 anyfile
> MPlayer UNKNOWN-12 (C) 2000-2023 MPlayer Team
> do_connect: could not connect to socket
> connect: No such file or directory
> Failed to open LIRC support. You will not be able to use your remote
> control.
> 
> Playing anyfile.
> File not found: 'anyfile'
> Failed to open anyfile.
> 
> 
> Playing anyfile.
> File not found: 'anyfile'
> Failed to open anyfile.

As far as I know this is intentional and documented behaviour.
It acts the same as if you had specified "anyfile" infinitely many times on the 
command-line.
It is useful behaviour in case the file might be created or replaced.
I suspect the behaviour you wanted is the one you get when you add -loop 0 
after the file name.

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Sean Whitton]

Hello,

On Fri 17 Feb 2023 at 09:00AM GMT, Andrea Corallo wrote:

> can't you just test feature/inhibit-native-comp-cleanup directy?  That
> would be the safest and simpler option IMO.

Not really -- Debian filters out a lot of the source tree due to
disagreements with the FSF regarding software freedom, and we have our
other patches.  So trying it directly it wouldn't give much confidence
regarding the original bug filing.

> Otherwise you have to revert probably 654428b65ae and 2f28496d038 and
> cherry pick in order 1795839babc 5d0912f1445 and ce4a066ed1e from
> feature/inhibit-native-comp-cleanup.  But this is a blind guess, I can't
> guarantee it to work without trying it.

Those are the right ones!

So: commit ce4a066ed1e fixes Debian bug #1021842 without the env var.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Russ Allbery]

Adrian Bunk  writes:

> The image creators could just set the features they enable to what they
> copied from /etc/mke2fs.conf from the target distribution, a label with
> a timestamp wouldn'tbring much benefit here.

That's a very good point and I'm embarrassed it wasn't immediately obvious
to me.  Sorry about the noise.

-- 
Russ Allbery (r...@debian.org)  

Bug#1014782: The problem remains

[Celejar]

On Fri, 27 Jan 2023 22:40:17 +0100 Tormod Volden
 wrote:
> OK. Maybe you can try 6.06, it is in salsa but is awaiting sponsoring
> and uploading. In any case, please attach the verbose log from
> xscreensaver -v -v -v -log your.log
> 
> I am not able to reproduce the issue.
> 
> Tormod

Sorry - I just saw this. I'm currently on 6.06 (Sid package). The
"Preview" button is currently working, but the screensaver isn't
activating on its own. I started it with logging enabled, and I see
regular deactivate events like the following logged every 20 seconds:

ClientMessage DEACTIVATE: already inactive, resetting activity time

I saw this:

https://www.jwz.org/xscreensaver/faq.html#no-blank

I guess I have to figure out what application is sending these messages?
Firefox? I do tend to keep a lot of tabs open.

If you think the log may contain more useful information, I'm happy to
attach it.

-- 
Celejar

Bug#1031519: RM: gitlab -- ROM; Remove gitlab from unstable (keep the version in experimental)

[Pirate Praveen]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Severity: normal
X-DebBugs-CC: t...@security.debian.org

Since protobuf was updated in unstable only recently, reuploading all 
(build)dependencies to unstable could not be completed in time for 
freeze and security team requested it to be kept only in experimental 
to avoid confusion for users (many open security issues and a very old 
version in unstable, whereas experimental has all the latest security 
updates).


We will try to reupload to unstable after freeze is lifted.

Bug#1031518: gem2deb: prefer github.com tarballs in watch file when available

[Pirate Praveen]

Package: gem2deb
severity: wishlist

npm2deb does this already and we could do it too when gemspec mentions 
it the homepage as github. We might have to use the rubygems.org api to 
find homepage, like npm2deb does.


Also using api.github.com can help getting all tags instead of only the 
latest tags when there are too many frequent releases and we want an 
older version.


An example watch file is:

version=4
opts="searchmode=plain, \
 repacksuffix=+dfsg,repack,compression=xz,\
 dversionmangle=auto,\
 filenamemangle=s/.+\/v@ANY_VERSION@/@PACKAGE@-$1\.tar\.gz/" \
https://api.github.com/repos/chartjs/Chart.js/releases \
https://api.github.com/repos/chartjs/Chart.js/tarball/v@ANY_VERSION@ 
group

Bug#1031510: Please open a new debian-puppet list

[Jérôme Charaoui]

Hello,

I'm a member of the Debian Puppet team, and I approve this message.

Thanks,

-- Jérôme

Bug#1031517: RFS: sane-frontends/1.0.14-17 [RC] -- scanner graphical frontends

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "sane-frontends":

   Package name : sane-frontends
   Version  : 1.0.14-17
   Upstream contact : [fill in name and email of upstream]
   URL  : http://www.sane-project.org
   License  : LGPL-2+, Artistic-1.0, GPL-2+, GPL-2+ with sane 
   exception, public-domain
  Vcs  : https://jff.email/cgit/sane-frontends.git
   Section  : graphics

The source builds the following binary packages:

  sane - scanner graphical frontends

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

  https://mentors.debian.net/package/sane-frontends/

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

 dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-frontends/sane-frontends_1.0.14-17.dsc

or from 

 git https://jff.email/cgit/sane-frontends.git?h=release%2Fdebian%2F1.0.14-17



Changes since the last upload:

 sane-frontends (1.0.14-17) unstable; urgency=medium
 .
   * debian/patches/0001-fix_missing_sane-config.patch:
 - Fix FTBFS (Closes: #1031453).
   Thanks to Lucas Nussbaum 
   * Declare compliance with Debian Policy 4.6.2.0 (No changes needed).
   * debian/copyright:
 - Add year 2023 to myself.
   * debian/tests/control:
 - Remove superficial test.

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/


Matrix:   @joergff:matrix.snct-gmbh.de
Threema:  HU6U7Z6H
Wire: @joergfringsfuerst
Skype:jff-skype@jff.email
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1031042: Acknowledgement (bullseye-pu: package mariadb-10.5 10.5.19-0+deb11u1)

[Otto Kekäläinen]

Can I proceed to upload MariaDB 10.5.19 to proposed stable updates?

Bug#1031516: fbterm: typos in package description

[Jakub Wilk]

Package: fbterm
Version: 1.7-5
Severity: minor
Tags: patch

--
Jakub Wilk
From: Jakub Wilk 
Date: Fri, 17 Feb 2023 16:52:27 +0100
Subject: [PATCH] Fix typos in package description

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 95a387d..112d435 100644
--- a/debian/control
+++ b/debian/control
@@ -20,11 +20,11 @@ Description: fast framebuffer based terminal emulator for Linux
 enabled on framebuffer device
   * select font with fontconfig and draw text with freetype2, same as Qt/Gtk+
 based GUI apps
-  * dynamicly create/destroy up to 10 windows initially running default shell
+  * dynamically create/destroy up to 10 windows initially running default shell
   * record scrollback history for every window
   * auto-detect current locale and convert text encoding, support double width
 scripts like Chinese, Japanese etc
   * switch between configurable additional text encoding with hot keys
 on the fly
-  * copy/past selected text between windows with mouse when gpm server is 
+  * copy/paste selected text between windows with mouse when gpm server is
 running
-- 
2.39.2

Bug#1031515: fbterm: missing tags 1.7-3, 1.7-5

[Jakub Wilk]

Source: fbterm

Tags for 1.7-3 and 1.7-5 are missing from the git repo:

   $ git ls-remote https://salsa.debian.org/debian/fbterm.git 
'refs/tags/debian/1.7-*[0-9]'
   bd1616f26a09a4f2ca58b7712643367eb6053bf3 refs/tags/debian/1.7-1
   f41d4eff26affc40f8e3c06ed54142625549eb96 refs/tags/debian/1.7-2
   0ce83f9b23187655e8809880895033390f942452 refs/tags/debian/1.7-4


--
Jakub Wilk

Bug#1031514: tzdata: create /etc/timezone with default SELinux context

[Christian Göttsche]

Package: tzdata
Version: 2022g-6
Tags: patch
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux

Dear Maintainer,

with version 2022g-6 the postinst script creates /etc/timezone if not existent.
Please ensure the file, especially if created, has the default SELinux
context, e.g. via:


diff --git a/debian/tzdata.postinst b/debian/tzdata.postinst
index bcb7d52..239377b 100644
--- a/debian/tzdata.postinst
+++ b/debian/tzdata.postinst
@@ -34,6 +34,7 @@ if [ "$1" = configure ]; then
   which restorecon >/dev/null 2>&1 && restorecon
"$DPKG_ROOT/etc/localtime"
   fi
   echo "$TIMEZONE" > "$DPKG_ROOT/etc/timezone"
+   which restorecon >/dev/null 2>&1 && restorecon "$DPKG_ROOT/etc/timezone"

   echo
   echo "Current default time zone: '$TIMEZONE'"

Bug#592834: Seeing this under bookworm/sid

[Charles Curley]

The unattended upgrade of grub failed (due to the fact that I had
replaced the hard drive and used dd to copy sector for sector from the
old one to the new, and that changed the identity of the hard drive).
Per the instructions in the unattended upgrade message, I ran the
following:

root@white:~# DEBIAN_FRONTEND=dialog dpkg --configure grub-pc
Setting up grub-pc (2.06-8) ...
grub-pc: Running grub-install ...
Installing for i386-pc platform.
File descriptor 3 (pipe:[225467]) leaked on vgs invocation. Parent PID 3611: 
grub-install
File descriptor 3 (pipe:[225467]) leaked on vgs invocation. Parent PID 3611: 
grub-install
File descriptor 3 (pipe:[225467]) leaked on vgs invocation. Parent PID 3611: 
grub-install
Installation finished. No error reported.
  grub-install success for /dev/sda
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-3-686
Found initrd image: /boot/initrd.img-6.1.0-3-686
Found linux image: /boot/vmlinuz-6.1.0-2-686
Found initrd image: /boot/initrd.img-6.1.0-2-686
Found memtest86+ image: /boot/memtest86+x32.bin
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done
root@white:~# cat /etc/debian_version
bookworm/sid
root@white:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:n/a
Codename:   bookworm
root@white:~# pre grub
grub2-common2.06-8  i386
grub-common 2.06-8  i386
grub-pc 2.06-8  i386
grub-pc-bin 2.06-8  i386
root@white:~# 

This machine is identical to the one on which I encountered this bug in
January. Both are Compulab Fit-PCs.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#1031513: clamav: new upstream security release, CVE-2023-20032

[Joost van Baal-Ilić]

Package: clamav
Severity: grave

Hi,

As you'll likely know there is
https://security-tracker.debian.org/tracker/CVE-2023-20032 and
https://blog.clamav.net/2023/02/clamav-01038-01052-and-101-patch.html

"CVE-2023-20032: Fixed a possible remote code execution vulnerability in the
HFS+ file parser. The issue affects versions 1.0.0 and earlier, 0.105.1 and
earlier, and 0.103.7 and earlier. Thank you to Simon Scannell for reporting
this issue."

Upstream released fixed tarballs for all their supported branches.  I've
managed to build 0.103.8+dfsg-0+deb10u1~uvt0 for Debian 10/buster from that,
it's available from https://non-gnu.uvt.nl/debian/buster/clamav/ (including
sources).

We are now running this build on the Tilburg University mail infrastructure,
it might work for others too.

Anybody working on a proper Debian supplied fix: feel free to contact me (via
IRC, e.g.)

HTH, Bye,

Joost

-- 
Joost van Baal-Ilić   http://abramowitz.uvt.nl/
 Tilburg University
mailto:joostvb.uvt.nl   The Netherlands


signature.asc
Description: PGP signature

Bug#992491: Package acpi-call-dkms 1.1.0-6 believes that acpi is disabled on 5.10 kernel

[Andreas Beckmann]

Followup-For: Bug #992491
Control: tag -1 pending

In order to clean up all dkms packages for the upcoming release, I've
prepared a NMU fixing this issue and uploaded it to DELAYED/5.

The corresponding changes can again be found in

g...@salsa.debian.org:anbe/acpi-call.git branch dkms-updates

Andreas

Bug#1031512: docbook-defguide: non-free GFDL-licensed files

[Bastian Germann]

Source: docbook-defguide
Severity: serious
Version: 2.0.17+svn9912-2

Some files in the package are licensed under the non-free variant of the GFDL 
with explicit Invariant Section.
Please repack to remove them.

Bug#863740: Fixed in pagekite versoin 1.5.2.201011-1 in experimental?

[Petter Reinholdtsen]

I just uploaded the latest upstream version of pagekite to experimental.
Please test to see if the problem with earlier versions is fixed in
version 1.5.2.201011-1.  If it work for you, we can consider including
it in Bookworm.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1031511: RFS: reiserfsprogs/1:3.6.27-5 -- User-level tools for ReiserFS filesystems

[Felix Zielcke]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : reiserfsprogs
   Version  : 1:3.6.27-5
   Upstream contact : reiserfs-de...@vger.kernel.org
 * URL  : 
https://www.kernel.org/pub/linux/kernel/people/jeffm/reiserfsprogs
 * License  : GPL-2
   Section  : admin

The source builds the following binary packages:

  reiserfsprogs - User-level tools for ReiserFS filesystems
  libreiserfscore0 - ReiserFS core library
  libreiserfscore-dev - ReiserFS core library - headers
  reiserfsprogs-udeb - User-level tools for ReiserFS filesystems
  mkreiserfs-udeb - User-level tools for ReiserFS filesystems

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/r/reiserfsprogs/reiserfsprogs_3.6.27-5.dsc

Changes since the last upload:

 reiserfsprogs (1:3.6.27-5) experimental; urgency=medium
 .
   * Build and ship libreiserfsprogs. (Closes: #1031342)
   * Bump policy to 4.6.2.
   * Rewrite d/copyright in copyright-format 1.0.
   * Add Rules-Requires-Root: no.
   * Update watch file to use version 4 and verify upstream signature.

Regards,
-- 
  Felix Zielcke

Bug#1029261: dm-writeboost-dkms: module fails to build for Linux 6.1: error: ‘struct dm_io_request’ has no member named ‘bi_op’

[Andreas Beckmann]

Control: tag -1 fixed-upstream pending
Control: tag 1027870 pending

On Fri, 20 Jan 2023 13:37:01 +0100 Andreas Beckmann  wrote:

/var/lib/dkms/dm-writeboost/2.2.15/build/dm-writeboost.h:506:46: error: ‘struct 
dm_io_request’ has no member named ‘bi_op’; did you mean ‘bi_opf’?


This is fixed in a new upstream release which I've NMUed to DELAYED/5.
The changes can be found in branch 2.2.16 on salsa.


Andreas

Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[James Addison]

Package: python3-zstandard
Followup-For: Bug #1031443
Control: affects -1 = src:python-scrapy src:libzstd src:rpmlint 
src:python-zstandard
Control: merge -1 1031293

Bug#1031433: diffoscope: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[FC Stegerman]

Should be fixed by [1]

- FC

[1] https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/126

Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[James Addison]

Package: python3-zstandard
Followup-For: Bug #1031443
Control: affects -1 - src:rpmlint
Control: affects -1 + src:rpmlint
Control: merge -1 1031293

Bug#1031506: darktable: Please adjust the architectures on which darktable is built

[David Bremner]

David Bremner  writes:

> Laurent Bigonville  writes:
>
>> Source: darktable
>> Version: 4.2.0-2
>> Severity: normal
>>
>> Hello,
>>
>> On x32 architecture, darktable FTBFS with the following error:
>>
>>71 | #error "Unfortunately we only work on the 64-bit architectures 
>> amd64, ARMv8-A, PPC64 and riscv64."
>>
>> ATM, I see that ppc64 and riscv64 are not listed in the package
>> architectures list. These should maybe be added.
>>
>> On the other side, x32 should maybe be removed
>>
>
> So x32 is built because of "Arch: any-amd64"? That seems like a bug to
> me, but what do I know.

So, I see that is really what dpkg-architecture thinks. If I understand
correctly your proposal is to replace "any-amd64" with the list of
things that are known to work? Sounds a bit tedious, but doable
(eventually).

Bug#1031510: Please open a new debian-puppet list

[Thomas Goirand]

Package: lists.debian.org
Severity: important


Hi listmasters!

We'd like to have a new debian-puppet list. Here's the answer to all the
fields of the MailingLists/HOWTO_start_list page. Please do reach us at
#debian-puppet if you need to.

Please note that the following DDs are behind this request (and I'm only
the messager):
- apoikos
- pollo
- lavamind
- olasd
- zigo

Name: debian-pup...@lists.debian.org

Rationale:
The puppet team still uses an old Alioth list, and we'd like to move-on.
We also need a space to be able to exchange ideas/work, and IRC isn't enough.

Short description:
Puppet server, agent and modules packaging and Puppet in Debian discussions.

Long description:
This list is mostly used by the team of DDs behind the packaging of Puppet
(Puppet agent, Puppetserver, PuppetDB, Puppet modules, etc.) in Debian. It
is however open to any kind of discussion related to any specifities of
using Puppet in Debian.

Category:
Developers

Subscription Policy:
Open

Post Policy:
Open

Web Archive:
Yes

Cheers,

Thomas Goirand (zigo)

Bug#1031509: clamav: 2 RCE bugs in ClamAV 0.103 (+ 1.0.0), CVE-2023-20032/CVE-2023-20052

[Robert Waldner]

Package: clamav
Version: 0.103.7+dfsg-0+deb11u1
Severity: important

Dear Maintainer,

ClamAV/Cisco have released a security advisory concerning 2 potential-RCE
bugs in ClamAV:
https://blog.clamav.net/2023/02/clamav-01038-01052-and-101-patch.html

According to the the security tracker, all versions currently in Debian
are vulnerable:
https://security-tracker.debian.org/tracker/CVE-2023-20032
https://security-tracker.debian.org/tracker/CVE-2023-20052

Please consider an update. Currently, ClamAV is not suitable for use in a
(quite common) email-scanning setup like with Amavis, but can still be
used (with appropriate care) directly. Thus I think Severity: important fits.

Kind regards,
Robert

-- Package-specific info:
--- configuration ---
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package

DatabaseOwner clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogVerbose false
LogSyslog false
LogFacility LOG_LOCAL6
LogFileMaxSize 0
LogRotate true
LogTime true
Foreground false
Debug false
MaxAttempts 5
DatabaseDirectory /var/lib/clamav
DNSDatabaseInfo current.cvd.clamav.net
ConnectTimeout 30
ReceiveTimeout 0
TestDatabases yes
ScriptedUpdates yes
CompressLocalDatabase no
Bytecode true
NotifyClamd /etc/clamav/clamd.conf
# Check for new database 24 times a day
Checks 24
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net

--- data dir ---
total 226104
-rw-r--r-- 1 clamav clamav293670 Feb 17 14:46 bytecode.cvd
-rw-r--r-- 1 clamav clamav  60744631 Feb 17 14:44 daily.cvd
-rw-r--r-- 1 clamav clamav69 Feb 17 14:43 freshclam.dat
-rw-r--r-- 1 clamav clamav 170479789 Feb 17 14:46 main.cvd

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

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

Versions of packages clamav depends on:
ii  clamav-freshclam [clamav-data]  0.103.7+dfsg-0+deb11u1
ii  libc6   2.31-13+deb11u5
ii  libclamav9  0.103.7+dfsg-0+deb11u1
ii  libcurl47.74.0-1.3+deb11u3
ii  libjson-c5  0.15-2
ii  libssl1.1   1.1.1n-0+deb11u3
ii  zlib1g  1:1.2.11.dfsg-2+deb11u2

Versions of packages clamav recommends:
ii  clamav-base  0.103.7+dfsg-0+deb11u1

Versions of packages clamav suggests:
pn  clamav-docs   
pn  libclamunrar  

-- no debconf information

Bug#1031449: python-scrapy: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10502 hardcoded in zstd

[James Addison]

Package: python3-zstandard
Followup-For: Bug #1031449
Control: affects -1 - src:rpmlint src:python-zstandard src:python-scrapy
Control: affects -1 + src:rpmlint src:python-scrapy src:python-zstandard
Control: merge -1 1031293

Bug#1031388: icingaweb2-module-pdfexport: server software depending on chromium?

[Shengjing Zhu]

On Thu, 16 Feb 2023 12:45:20 +0100 David Kunz  wrote:
>
> > The current version of icingaweb2-module-pdfexport depends on chromium.
> All versions are like thes.
>
> > icingaweb2 is a web service.  Depending on a graphical browser in a web
> > server component is not at all reasonable.
> I know, but upstream considers this to be the best possible way to solve
> this problem.
>
> Now we can provide this package as it is or no package exist and all
> packages that depends to it are unusable.

You can demote chromium to Recommends. There are multiple benefits:
+ Users can use proprietary version of chrome from Google
+ Users can use snap/flatpak to install the latest chromium.
+ Users can use remote chromium as documented here:
https://github.com/Icinga/icingaweb2-module-pdfexport/blob/master/doc/02-Installation.md#using-a-remote-chromechromium

Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[James Addison]

Package: python3-zstandard
Followup-For: Bug #1031443
Control: affects -1 - src:python-scrapy src:rpmlint
Control: affects -1 + src:python-scrapy src:rpmlint
Control: merge -1 1031293

Bug#1031508: lomiri-thumbnailer: Please rename /etc/apport/blacklist.d to /etc/apport/report-ignore

[Benjamin Drung]

Package: lomiri-thumbnailer
Version: 3.0.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

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

  * Rename /etc/apport/blacklist.d to /etc/apport/report-ignore for
Apport >= 2.25.0

This patch might be useful for upstream, but the new path is not taken
into account by older apport versions. So upstream should not take the
patch if they want to support older Ubuntu versions.

Thanks for considering the patch.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru lomiri-thumbnailer-3.0.1/debian/lomiri-thumbnailer-service.install 
lomiri-thumbnailer-3.0.1/debian/lomiri-thumbnailer-service.install
--- lomiri-thumbnailer-3.0.1/debian/lomiri-thumbnailer-service.install  
2022-07-20 00:15:27.0 +0200
+++ lomiri-thumbnailer-3.0.1/debian/lomiri-thumbnailer-service.install  
2023-02-17 11:27:32.0 +0100
@@ -1,4 +1,4 @@
-etc/apport/blacklist.d/lomiri-thumbnailer
+etc/apport/report-ignore/lomiri-thumbnailer
 usr/bin/lomiri-thumbnailer-admin
 usr/libexec/lomiri-thumbnailer/thumbnailer-service
 usr/libexec/lomiri-thumbnailer/vs-thumb
diff -Nru 
lomiri-thumbnailer-3.0.1/debian/lomiri-thumbnailer-service.maintscript 
lomiri-thumbnailer-3.0.1/debian/lomiri-thumbnailer-service.maintscript
--- lomiri-thumbnailer-3.0.1/debian/lomiri-thumbnailer-service.maintscript  
1970-01-01 01:00:00.0 +0100
+++ lomiri-thumbnailer-3.0.1/debian/lomiri-thumbnailer-service.maintscript  
2023-02-17 11:35:52.0 +0100
@@ -0,0 +1 @@
+mv_conffile /etc/apport/blacklist.d/lomiri-thumbnailer 
/etc/apport/report-ignore/lomiri-thumbnailer 3.0.1-1ubuntu1~
diff -Nru 
lomiri-thumbnailer-3.0.1/debian/patches/1001_rename_apport_directory.patch 
lomiri-thumbnailer-3.0.1/debian/patches/1001_rename_apport_directory.patch
--- lomiri-thumbnailer-3.0.1/debian/patches/1001_rename_apport_directory.patch  
1970-01-01 01:00:00.0 +0100
+++ lomiri-thumbnailer-3.0.1/debian/patches/1001_rename_apport_directory.patch  
2023-02-17 11:39:19.0 +0100
@@ -0,0 +1,43 @@
+From b4e6aec81bab0bd2d1689f45a80a85073c2d5c48 Mon Sep 17 00:00:00 2001
+From: Benjamin Drung 
+Date: Fri, 17 Feb 2023 11:39:10 +0100
+Subject: Rename /etc/apport/blacklist.d to /etc/apport/report-ignore
+
+Apport 2.25.0 renamed `/etc/apport/blacklist.d` to `/etc/apport/report-ignore`.
+
+Signed-off-by: Benjamin Drung 
+---
+ data/CMakeLists.txt   | 8 
+ in => etc_apport_report-ignore_lomiri-thumbnailer.in} | 0
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+ rename data/{etc_apport_blacklist.d_lomiri-thumbnailer.in => 
etc_apport_report-ignore_lomiri-thumbnailer.in} (100%)
+
+diff --git a/data/CMakeLists.txt b/data/CMakeLists.txt
+index 6a6b4dc..2717ea7 100644
+--- a/data/CMakeLists.txt
 b/data/CMakeLists.txt
+@@ -5,13 +5,13 @@ execute_process (COMMAND ${PKG_CONFIG_EXECUTABLE} gio-2.0 
--variable glib_compil
+ execute_process (COMMAND ${_glib_comple_schemas} ${CMAKE_CURRENT_SOURCE_DIR} 
--targetdir=${CMAKE_CURRENT_BINARY_DIR} OUTPUT_STRIP_TRAILING_WHITESPACE)
+ 
+ configure_file(
+-  etc_apport_blacklist.d_lomiri-thumbnailer.in
+-  etc_apport_blacklist.d_lomiri-thumbnailer
++  etc_apport_report-ignore_lomiri-thumbnailer.in
++  etc_apport_report-ignore_lomiri-thumbnailer
+   @ONLY
+ )
+ 
+ install(FILES
+-  "${CMAKE_CURRENT_BINARY_DIR}/etc_apport_blacklist.d_lomiri-thumbnailer"
++  "${CMAKE_CURRENT_BINARY_DIR}/etc_apport_report-ignore_lomiri-thumbnailer"
+   RENAME lomiri-thumbnailer
+-  DESTINATION "${CMAKE_INSTALL_SYSCONFDIR}/apport/blacklist.d"
++  DESTINATION "${CMAKE_INSTALL_SYSCONFDIR}/apport/report-ignore"
+ )
+diff --git a/data/etc_apport_blacklist.d_lomiri-thumbnailer.in 
b/data/etc_apport_report-ignore_lomiri-thumbnailer.in
+similarity index 100%
+rename from data/etc_apport_blacklist.d_lomiri-thumbnailer.in
+rename to data/etc_apport_report-ignore_lomiri-thumbnailer.in
+-- 
+2.37.2
+
diff -Nru lomiri-thumbnailer-3.0.1/debian/patches/series 
lomiri-thumbnailer-3.0.1/debian/patches/series
--- lomiri-thumbnailer-3.0.1/debian/patches/series  2023-02-05 
17:03:53.0 +0100
+++ lomiri-thumbnailer-3.0.1/debian/patches/series  2023-02-17 
11:26:53.0 +0100
@@ -1,3 +1,4 @@
+1001_rename_apport_directory.patch
 2001_dont-check-whitespaces-in-debian-subfolder.patch
 1300_disable_qml_and_dbus_tests.patch
 2001_ignore-more-file-types-in-copyright-check.patch

Bug#1031506: darktable: Please adjust the architectures on which darktable is built

[David Bremner]

Laurent Bigonville  writes:

> Source: darktable
> Version: 4.2.0-2
> Severity: normal
>
> Hello,
>
> On x32 architecture, darktable FTBFS with the following error:
>
>71 | #error "Unfortunately we only work on the 64-bit architectures amd64, 
> ARMv8-A, PPC64 and riscv64."
>
> ATM, I see that ppc64 and riscv64 are not listed in the package
> architectures list. These should maybe be added.
>
> On the other side, x32 should maybe be removed
>

So x32 is built because of "Arch: any-amd64"? That seems like a bug to
me, but what do I know.

d

Bug#1031396: Unable to upgrade to *gnome* 1:43+1 with `apt full-upgrade`

[Simon McVittie]

Control: reassign -1 pipewire
Control: affects -1 = gnome src:meta-gnome3

On Fri, 17 Feb 2023 at 13:25:47 +0100, Dylan Aïssi wrote:
> This seems to be solved by adding pulseaudio-module-bluetooth in Conflicts and
> Replaces of pipewire-audio. pipewire-audio already conflicts and replaces
> pulseaudio for some reasons, but looks like it is not enough.

Thanks for identifying that solution. Please could you make that change
in the next pipewire upload? (Note that this is currently marked as RC.)
I don't think this is likely to be addressable from the meta-gnome3 side,
so I'm reassigning this.

As far as I can see, that wouldn't regress co-installability, because
pipewire-audio and pulseaudio-module-bluetooth are already not
co-installable (pipewire-audio Conflicts pulseaudio,
pulseaudio-module-bluetooth Depends pulseaudio)

Adding technically-unnecessary Conflicts/Replaces or Breaks/Replaces is
sometimes necessary to hint apt's heuristics for "should I be willing to
remove package A to get package B upgraded?" into doing what we consider
to be the right thing.

smcv

Bug#1031449: python-scrapy: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10502 hardcoded in zstd

[James Addison]

Source: python-scrapy
Followup-For: Bug #1031449
Control: reassign -1 python3-zstandard 0.19.0-3
Control: affects -1 + src:libzstd src:python-scrapy src:python-zstandard 
src:rpmlint
Control: merge -1 1031293