Dear Maintainer,

* What led up to the situation?

I performed an upgrade (apt upgrade) with the following manually held back packages due to bug reports: libc6, libc6:i386, libc6-dev, libxml2, libxml2:i386, and lintian.

Following is a complete list of held back packages resulting from the manually held back packages:
----------------------------------------------------------------------------------------------------------------------------------------------------

The following packages have been kept back:
  cpp-9 gcc-11-base gcc-11-base:i386 gcc-9 gcc-9-base gcc-9-base:i386 libasan5
  libasan6 libatomic1 libatomic1:i386 libc-bin libc-dev-bin libc6 libc6:i386
  libc6-dev libcc1-0 libgcc-9-dev libgcc-s1 libgcc-s1:i386 libgfortran5 libgomp1
  libgomp1:i386 libitm1 liblsan0 libquadmath0 libstdc++6 libstdc++6:i386 libtsan0
  libubsan1 libuno-sal3 libxml2 libxml2:i386 lintian locales mpv vorbis-tools

----------------------------------------------------------------------------------------------------------------------------------------------------

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

n/a

* What was the outcome of this action?

----------------------------------------------------------------------------------------------------------------------------------------------------

libdvd-pkg: Downloading orig source...
I: libdvdcss_1.4.3
/usr/bin/wget --tries=3 --timeout=40 --read-timeout=40 --continue -O libdvdcss_1.4.3.orig.tar.bz2 \
https://download.videolan.org/pub/libdvdcss/1.4.3/libdvdcss-1.4.3.tar.bz2 \
        || /usr/bin/uscan --noconf --verbose --rename --destdir=/usr/src/libdvd-pkg --check-dirname-level=0 --force-download --download-current-version /usr/share/libdvd-pkg/debian
--2021-09-11 02:13:51--  https://download.videolan.org/pub/libdvdcss/1.4.3/libdvdcss-1.4.3.tar.bz2
Resolving download.videolan.org (download.videolan.org)... 213.36.253.2, 2a01:e0d:1:3:58bf:fa02:c0de:5
Connecting to download.videolan.org (download.videolan.org)|213.36.253.2|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 388404 (379K) [application/octet-stream]
Saving to: ‘libdvdcss_1.4.3.orig.tar.bz2’

libdvdcss_1.4.3.orig 100%[======================>] 379.30K  1.35MB/s    in 0.3s

2021-09-11 02:13:52 (1.35 MB/s) - ‘libdvdcss_1.4.3.orig.tar.bz2’ saved [388404/388404]

libdvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...

----------------------------------------------------------------------------------------------------------------------------------------------------

* What outcome did you expect instead?

A normal upgrade.

I have the same result, although in my case, the command I had run was
'apt-get dist-upgrade' and there were no packages kept back.

By "the same result", I mean that except for cosmetic things like the
timestamp, the reported download speed, and the width of the wget
download-progress bar, the output appears to be exactly identical.

Looking at the scripts involved, I don't see anything that looks
obviously different from what this seems to have been before; it's still
just invoking 'apt-get check', reacting to the exit status, and
returning success. That leads me to think that the difference must be
the result of a change in the behavior of 'apt-get check', which would
mean that the most likely cause is a change in apt itself.

Looking at the apt changelog (from the uploads to experimental over the
months of the release freeze), I see a few things which could maybe if
the circumstances are right be handwaved as being related; however, I
don't know the libdvd-pkg design well enough to be able to judge which
of them might actually be related, and I'm not currently inclined to
grab the apt source and start digging to see what 'apt-get check' is
actually doing now that might be different from the last time this was
known to be working.

I do want to note that after getting this error, I ran 'dpkg-reconfigure
libdvd-pkg' as suggested elsewhere, and saw it complete with no errors.

I understand that "apt check" should not fail on held packages so
I suspect there might be something wrong with the state of
package management on system. Could you try "apt install -f" please?

---

If the truth offends, it's our job to offend.
 -- Satoshi Kanazawa

---
Your Facebook friends are wrong about the lockdown. A non-hysterics's guide
to COVID-19 by Tom Woods.
 -- https://wrongaboutlockdown.com/

severity 994081 important
quit

Hi,

After basically any apt upgrade, I get:

Processing triggers for libc-bin (2.36-8):
libdvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK
libdvd-pkg: `apt-get check` failed, you may have broken packages.
Aborting...

I can confirm that "apt-get check" returns 0. AFAICT this failing check
is stopping libdvd-pkg from proceeding, which seems like an important bug.

Regards,

Matthew

Hi,

I went looking to try and see where the check was being carried out, and
it's in:

/usr/lib/libdvd-pkg/b-i_libdvdcss.sh

apt-get check >/dev/null 2>&1
if [ "$?" -ne 0 ]; then
     echo "${PKGI}: \`apt-get check\` failed, you may have broken
packages. Aborting..."
     exit 0
fi

Which is why there's no useful information in the error message. So I
edited that file on my system and ran apt autoremove so force a trigger
run, and that gets:

/usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process
29788 (apt)
N: Be aware that removing the lock file is not a solution and may break
your system.
E: Unable to acquire the dpkg frontend lock
(/var/lib/dpkg/lock-frontend), is another process using it?
libdvd-pkg: `apt-get check` failed, you may have broken packages.
Aborting...

So I'm afraid the problem is that running this script from apt (as it is
evidently intended to be run) can never work, because apt-get check
tries to hold the dpkg lock, but it's help by apt.

So I think this is RC, do you agree?

Regards,

Matthew

Hi,

I got the following error when running "apt dist-upgrade" to get from
Debian-11 to Debian-12. (German locale)

Dear Maintainer,
TL;DR: could apt-get be called with "--dry-run" a flag when we call its
"check" command as to get libdvd-pkg triggers script to run?



The error trigger on each installi (or reinstall) or removal of a package.
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...

Adding "set -x" to /usr/lib/libdvd-pkg/b-i_libdvdcss.sh
and removing the stdout and stderr redirection from the "apt-get check"
and "dpkg -P nonexistent-package" calls, I get:

+ . /usr/lib/libdvd-pkg/VARS
+ PKGI=libdvd-pkg
+ DIR=/usr/src/libdvd-pkg
+ PKGG=libdvdcss2
+ PKGG_ALL=libdvdcss2 libdvdcss-dev
+ P88=88libdvdcss-pkg
+ VERGG=1.4.3-1
+ dpkg --status libdvdcss2
+ perl -0ne print $1 if m{^Status:\s+install\s+ok\s+installed}sm and m{^Version:\s+(\S+)}sm;
+ VERG=1.4.2-1~local
+ dpkg --compare-versions 1.4.3-1~local gt 1.4.2-1~local
+ [ 0 = 0 ]
+ [ -f /usr/src/libdvd-pkg/libdvdcss2-1.4.3-1.is-installed ]
+ dpkg -P non-existent-package
dpkg: warning: ignoring request to remove non-existent-package which isn't installed
+ [ 0 -eq 2 ]
+ [ ! -s /usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2 ]
+ echo libdvd-pkg: Checking orig.tar integrity...
libdvd-pkg: Checking orig.tar integrity...
+ sha256sum --check --strict /usr/share/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2.sha256
/usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK
+ [ 0 -ne 0 ]
+ apt-get check
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2522949 (apt)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
+ [ 100 -ne 0 ]
+ echo libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...
+ exit 0


dpkg only check for /var/lib/dpkg/lock and /var/lib/dpkg/triggers/Lock

"apt-get check" always fails in a trigger as
[200~/var/lib/dpkg/lock-frontend is locked by the parent apt.
So the whole script is nowadays a noop.

I believe passing the "--dry-run" flag to "apt-get check" would keep the
consistency check and allow to the script to fulfill its duty.

solution because --dry-run does not what needs to be done?
I just switched to Debian 12 from 11 and ran into this issue. And when I
saw that the issue was about two years old I was flabbergasted: I am used
to the high quality of Debian.

I made in /usr/lib/libdvd-pkg/b-i_libdvdcss.sh the following change:
    # @@@@ added ry-run and /dev/null redirection removed
    apt-get check --dry-run # >/dev/null 2>&1

I am now waiting until my system needs an upgrade to see the result from
this change.
I will share it when I have it.

Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081
 "Upgrade Results in 'apt-get check' Failure"

It is fairly nasty bug. Nasty because it hides well.
Thing is that the `apt check` is during development never called
as a child proces of `apt`.  It reveals it self only during
an upgrade by `apt` or `apt-get`, not during a `dpkg --install`.

Adding '--dry-run' is to prevent bail out on
  E: Could not get lock /var/lib/dpkg/lock-frontend.
     It is held by process PID (apt)
  E: Unable to acquire the dpkg frontend lock

Manual page of `apt-get` says about `--dry-run`
  Locking will be disabled (Debug::NoLocking) so the system
  state could change while apt-get is running.

The removal of 'exit 0' makes it possible that the (build) script
continues. Frankly, I think the whole `apt check` part should
be removed. It is not up to /usr/lib/libdvd-pkg/b-i_libdvdcss.sh
to judge the sanity of the build system.

No it could not.
The problem is that 'apt-get check' wants to get the lock that already is
taken by 'apt upgrade'. So when the lock is not taken by using --dry-run we
do not have the problem that a lock is requested that already is taken. And
because the lock is already taken by 'apt upgrade' it should not be
possible that the system state changes.

Control: tags 994081 +patch

The patch is in Message #47
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081#47 )

And attached to this email.


Groeten
Geert Stappers
DD

On Sun, 3 Sep 2023 15:52:23 +0200 Cecil Westerhof <cldwesterhof@gmail.com> wrote:
wrote:
    apt-get check >/dev/null 2>&1
    if [ "$?" -ne 0 ]; then
        echo "${PKGI}: \`apt-get check\` failed, you may have broken
packages. Aborting..."
        exit 0
    fi

into:
    # @@@@ dry-run toegevoegd en /dev/null redirection verwijderd
    echo "BEFORE 'apt-get check' problem"
    apt-get check --dry-run # >/dev/null 2>&1
    if [ "$?" -ne 0 ]; then
        echo "${PKGI}: \`apt-get check\` failed, you may have broken
packages. Aborting..."
        exit 0
    fi
    echo "AFTER  'apt-get check' problem"

I had an upgrade that could be done and this resulted in:
    BEFORE 'apt-get check' problem
    Reading package lists...
    Building dependency tree...
    Reading state information...
    AFTER  'apt-get check' problem

So by adding --dry-run we do not get the error anymore.
So if there is no reason that --dry-run would be wrong, I think it is a
good idea to add it: then this two year old problem would finally be solved.