Bug#984849: marked as done (dpkg-divert: too sensitive to order of command-line args)

[Debian Bug Tracking System]

Your message dated Tue, 15 Mar 2022 04:21:46 +0100
with message-id 
and subject line Re: Bug#984849: dpkg-divert: too sensitive to order of 
command-line args
has caused the Debian Bug report #984849,
regarding dpkg-divert: too sensitive to order of command-line args
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
984849: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984849
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.20.7.1
Severity: wishlist
X-Debbugs-Cc: rvandegr...@debian.org

dpkg-divert is too sensitive to the order of the command line parameters.
Since I only use it rarely, I almost always run into:

  # dpkg-divert --add /wooo --divert /yeah --rename
  dpkg-divert: warning: please specify --no-rename explicitly, the default will 
change to --rename in 1.20.x
  dpkg-divert: error: --add needs a single argument
  
  Use --help for help about diverting files.

The fix is to move --add last.  But neither the error nor the manpage makes
that clear.

Ross


-- Package-specific info:

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-9
ii  liblzma5 5.2.5-1.0
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.0
pn  debsig-verify  

-- no debconf information
--- End Message ---
--- Begin Message ---
On Thu, 2021-09-02 at 10:12:17 -0700, Ross Vandegrift wrote:
> On Thu, Sep 02, 2021 at 04:16:36AM +0200, Guillem Jover wrote:
> > On Mon, 2021-03-08 at 22:35:49 -0800, Ross Vandegrift wrote:
> > > dpkg-divert is too sensitive to the order of the command line parameters.
> > > Since I only use it rarely, I almost always run into:
> > > 
> > >   # dpkg-divert --add /wooo --divert /yeah --rename
> > >   dpkg-divert: warning: please specify --no-rename explicitly, the 
> > > default will change to --rename in 1.20.x
> > >   dpkg-divert: error: --add needs a single argument
> > >   
> > >   Use --help for help about diverting files.
> > > 
> > > The fix is to move --add last.  But neither the error nor the manpage 
> > > makes
> > > that clear.
> > 
> > Both the man page and the --help output mention that the usage is:
> > 
> >   dpkg-divert [...] 
> > 
> > And then go to list the commands and options on their respective
> > sections. While I guess I could add a hint or similar on the error
> > message (because modifying the way this is parsed would be a pain),
> > that seems it would be too specific for such a generic message. So
> > I'm inclined to leave it as is, TBH. If you have an alternative
> > suggestion I'm happy to consider, otherwise I'm afraid I'll just
> > going to close the report.
> 
> I don't have any good suggestions - I think usage would be more obvious
> if the commands weren't prefixed with dashes, but that would cause much
> worse breakage.  If the parsing is too hard to change, then leaving it
> as-is is sounds reasonable.
> 
> Thanks for thinking about it, feel free to close.

Closing this now.

Thanks,
Guillem--- End Message ---

Bug#995332: marked as done (Package reinstalls/upgrades with files on FAT partitions fail)

[Debian Bug Tracking System]

Your message dated Tue, 15 Mar 2022 04:04:27 +0100
with message-id 
and subject line Re: Bug#995332: Package reinstalls/upgrades with files on FAT 
partitions fail
has caused the Debian Bug report #995332,
regarding Package reinstalls/upgrades with files on FAT partitions fail
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
995332: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995332
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: dpkg
Version: 1.20.9

I recognised just recently that dpkg is not able to gracefully replace 
files on FAT partitions, e.g. when reinstalling or upgrading a package. 
It seems to try creating a file link as backup, while FAT does not 
supports links:

---
unable to make backup link of './path/to/file' before installing new 
version: Operation not permitted

---

This seems to be an expected behaviour, at least I found multiple cases 
where e.g. SBC OS images are shipped with a dedicated /boot FAT 
partition, and measures have been taken to remove existing files from 
/boot before kernel upgrades or via dpkg-divert loops.


Of course Debian is a Linux distribution and the root filesystem needs 
to support UNIX permissions, symlinks and hard links (?) for the system 
to function properly, but it is not uncommon to mount FAT partitions 
into the system, especially using a FAT partition for /boot is required 
for some ARM SBCs to boot and beneficial otherwise to allow fixing boot 
configuration issues or pre-configuring the system as well from Windows 
or macOS systems.


So my question is whether it wouldn't be feasible to handle the 
replacement of package files on FAT partitions (and other filesystem 
types with no link support) gracefully. A backup could be created 
differently if this is seen mandatory.


Best regards,

MichaIng
--- End Message ---
--- Begin Message ---
Hi!

On Mon, 2021-10-04 at 13:33:22 +0200, MichaIng wrote:
> As said, there is hardware which simply requires the boot partition to be
> FAT, and the workarounds for this dpkg limitation force package
> maintainers/admins to use much riskier methods, like removing all existing
> kernel files via kernel preinst hook, which extends the time frame
> significantly in which a power loss would render the system unbootable,
> compared to having that risk during individual file write only. Common
> reasons on such systems for being unbootable are not because of a failed
> package install or power loss, but because of the kernel or bootloader or
> initramfs itself being faulty, falsely generated or falsely configured and
> in such case it is very helpful if the filesystem can be accessed and fixed
> from e.g. Windows or macOS.
> 
> Just to clarify: I know this mostly from ARM SBCs, which are currently still
> mostly shipped with a manufacturer or 3rd party kernel and bootloader (not
> the Debian ones) and a /boot FAT partition is either strictly required by
> the hardware or explicitly chosen by the image provider, for mentioned
> reasons, despite the difficulties with dpkg. If dpkg would support FAT, it
> would lower the risk of kernel package installs on those systems.

As mentioned on the FAQ, modern EFI base systems use FAT32 partitions,
and those are handled properly by the current kernel hooks. In
addition this should be way safer than letting dpkg handle the
installation. Consider that dpkg would unpack the kernel, but the
initramfs would not have been generated yet, which would render the
system unbootable for a longer period of time. So generating the
initramfs via a kernel hook, and then installing both (overwriting old
versions if need be), should be way safer than the alternative.

> In the FAQ it is mentioned
> 
> > As part of the dpkg credo, preserving human configuration is of utmost
> importance
> 
> and one could see a FAT partition mounted into root as a human configuration
> decision, despite the obvious downsides and limitations of FAT. And the
> question is whether this decision itself is seen as the bigger risk, or the
> workarounds done to cover the missing dpkg support for it.

That reading looks a bit like cheating though. I'd expect that
"Preserving human configuration" for something that is explicitly listed
as unsupported would not be presumed to be included there. :)

> However, I see that this is a long done design decision, I fully understand
> the reasons behind it and the chance to change that hence being close to
> zero. So yes feel free to close the issue :).

Yeah, I'm doing that now.

Thanks,
Guillem--- End Message ---

Bug#1001054: marked as done (s-s-d: --exec should fall back to other methods if readlink fails)

[Debian Bug Tracking System]

Your message dated Tue, 15 Mar 2022 03:50:19 +0100
with message-id 
and subject line Re: Bug#1001054: /sbin/start-stop-daemon: start-stop-daemon 
--exec should fall back to other methods if readlink fails
has caused the Debian Bug report #1001054,
regarding s-s-d: --exec should fall back to other methods if readlink fails
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1001054: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001054
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.20.9
Severity: normal
File: /sbin/start-stop-daemon

Hi,

I was debugging an init script in a Debian Docker container, and found
it always fails to stop the daemon. Upon a closer inspection, I found
that --exec, which init-d-script always passed, never matches the
executable, even if a PID file is used. I then checked the source and
tried to do the steps manually:

root@d351c00abb80:/# ls /proc/1841/exe -l
ls: cannot read symbolic link '/proc/1841/exe': Permission denied
lrwxrwxrwx 1 sphinxsearch sphinxsearch 0 Dec  3 08:46 /proc/1841/exe

In fact, cwd and root are also inaccessible. I’m not sure it’s some
security setting Docker applies or is it something becaue of the
containers, but the fact is that --exec is unusable in this setting.

I guess falling back to other matching methods might be more useful than
failing to stop at all.

-- 
Cheers,
  Andrej
--- End Message ---
--- Begin Message ---
Hi!

On Wed, 2021-12-15 at 00:17:46 +0100, Guillem Jover wrote:
> On Fri, 2021-12-03 at 09:56:34 +0100, Andrej Shadura wrote:
> > Package: dpkg
> > Version: 1.20.9
> > Severity: normal
> > File: /sbin/start-stop-daemon
> 
> > I was debugging an init script in a Debian Docker container, and found
> > it always fails to stop the daemon. Upon a closer inspection, I found
> > that --exec, which init-d-script always passed, never matches the
> > executable, even if a PID file is used. I then checked the source and
> > tried to do the steps manually:
> > 
> > root@d351c00abb80:/# ls /proc/1841/exe -l
> > ls: cannot read symbolic link '/proc/1841/exe': Permission denied
> > lrwxrwxrwx 1 sphinxsearch sphinxsearch 0 Dec  3 08:46 /proc/1841/exe
> > 
> > In fact, cwd and root are also inaccessible. I’m not sure it’s some
> > security setting Docker applies or is it something becaue of the
> > containers, but the fact is that --exec is unusable in this setting.
> 
> Yes, this seems to be a known regression in docker, see
>  and all related bugs
> closed w/o any action. It seems you can workaround this by running the
> docker image with ptrace Linux capabilities (even though that looks
> rather unintuitive).
> 
> > I guess falling back to other matching methods might be more useful than
> > failing to stop at all.
> 
> I don't think that would be safe at all, as the interface is expected
> to AND all the match options, to properly select what to act on. And
> in any case this looks like a bug in docker anyway.
> 
> Given the above I'm going to be closing this, unless there's a very
> compelling argument to do otherwise.

Thus, closing it now.

Thanks,
Guillem--- End Message ---

Bug#973259: marked as done (dpkg-scanpackages: local development repos fail due to missing sha512 hashes)

[Debian Bug Tracking System]

Your message dated Tue, 15 Mar 2022 03:48:13 +0100
with message-id 
and subject line Re: Bug#973259: dpkg-scanpackages: local development repos 
fail due to missing sha512 hashes
has caused the Debian Bug report #973259,
regarding dpkg-scanpackages: local development repos fail due to missing sha512 
hashes
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
973259: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973259
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.20.5
Severity: important

Today while working on the autopkgtests of an ITP of mine I discovered
that apt fails to install packages from the local repo, seemingly
because of missing sha512 hashes.  Whether intentional or not, the
effect seems to be that apt is enforcing sha512, which isn't a bad
thing, hence this bug!

…
The following NEW packages will be installed:
  libexpat1 libpython3-stdlib libpython3.8-minimal libpython3.8-stdlib 
mime-support python3 python3-atomicwrites python3-attr
  python3-importlib-metadata python3-minimal python3-more-itertools 
python3-packaging python3-pkg-resources python3-pluggy
  python3-py python3-pyparsing python3-pytest python3-six python3-volatile 
python3-wcwidth python3-zipp python3.8
  python3.8-minimal
0 upgraded, 23 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0 B/5889 kB of archives.
After this operation, 22.9 MB of additional disk space will be used.
Get:1 file:/usr/src/repo/amd64 ./ python3-volatile 2.1.0-1 [5356 B]
Err:1 file:/usr/src/repo/amd64 ./ python3-volatile 2.1.0-1
  Hash Sum mismatch
  Hashes of expected file:
   - SHA256:1210131215ad632c8eb4d09b0448ce680ca9805aaf4ec9b3b99ee2161537f93c
   - SHA1:fc1517b001fe9361d18a31f0d63daac366f93c8e [weak]
   - MD5Sum:e9c3ec5e3d437c610566fa2d24baee47 [weak]
   - Filesize:5356 [weak]
   - 
SHA512:779d3b466eb7cff946f6efebce7374803ec4afd6631ace49e02073d1da4fa98a4b1449e0e207dff6b32e11f735b29b04298a05632dcc077469ecfc674b0cab5d
  Hashes of received file:
   - 
SHA512:d2330098a34a54fe68a57ef12ce79260bb0eeddea3df251e9e4bbd1588dc0e46904ee89cc9e6bf44d8c0a910caedcc1b9c582066f7402ff264d7dc130d7f79c4
   - SHA256:1210131215ad632c8eb4d09b0448ce680ca9805aaf4ec9b3b99ee2161537f93c
   - SHA1:fc1517b001fe9361d18a31f0d63daac366f93c8e [weak]
   - MD5Sum:e9c3ec5e3d437c610566fa2d24baee47 [weak]
   - Filesize:5356 [weak]
  Last modification reported: Tue, 27 Oct 2020 21:23:22 +
W: Sources disagree on hashes for supposely identical version '2.1.0-1' of 
'python3-volatile:amd64'.
E: Failed to fetch 
file:/usr/src/repo/amd64/../pool/python3-volatile_2.1.0-1_all.deb  Hash Sum 
mismatch
   Hashes of expected file:
- SHA256:1210131215ad632c8eb4d09b0448ce680ca9805aaf4ec9b3b99ee2161537f93c
- SHA1:fc1517b001fe9361d18a31f0d63daac366f93c8e [weak]
- MD5Sum:e9c3ec5e3d437c610566fa2d24baee47 [weak]
- Filesize:5356 [weak]
- 
SHA512:779d3b466eb7cff946f6efebce7374803ec4afd6631ace49e02073d1da4fa98a4b1449e0e207dff6b32e11f735b29b04298a05632dcc077469ecfc674b0cab5d
   Hashes of received file:
- 
SHA512:d2330098a34a54fe68a57ef12ce79260bb0eeddea3df251e9e4bbd1588dc0e46904ee89cc9e6bf44d8c0a910caedcc1b9c582066f7402ff264d7dc130d7f79c4
- SHA256:1210131215ad632c8eb4d09b0448ce680ca9805aaf4ec9b3b99ee2161537f93c
- SHA1:fc1517b001fe9361d18a31f0d63daac366f93c8e [weak]
- MD5Sum:e9c3ec5e3d437c610566fa2d24baee47 [weak]
- Filesize:5356 [weak]
   Last modification reported: Tue, 27 Oct 2020 21:23:22 +
E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?
autopkgtest [18:15:29]: ERROR: testbed failure: apt repeatedly failed to 
download packages


Regards,
Nicholas
--- End Message ---
--- Begin Message ---
Hi!

On Tue, 2020-11-17 at 19:56:24 +0100, Guillem Jover wrote:
> On Tue, 2020-10-27 at 18:30:43 -0400, Nicholas D Steeves wrote:
> > Package: dpkg-dev
> > Version: 1.20.5
> > Severity: important
> 
> > Today while working on the autopkgtests of an ITP of mine I discovered
> > that apt fails to install packages from the local repo, seemingly
> > because of missing sha512 hashes.  Whether intentional or not, the
> > effect seems to be that apt is enforcing sha512, which isn't a bad
> > thing, hence this bug!
> 
> But sha256 is not weak, so that should be enough, the problem seems
> to be something else. I've already implemented this locally, but I'm
> afraid it would need coordination with at least ftp-masters as DAK
> might actually reject such .dsc and .changes files.
> 
> Hmm, but I tried to reproduce this, and I'm unable to, downloaded 

Bug#1003452: marked as done (dpkg: missing alternatives for x-terminal-emulator)

[Debian Bug Tracking System]

Your message dated Tue, 15 Mar 2022 03:46:28 +0100
with message-id 
and subject line Re: Bug#1003452: dpkg: missing alternatives for 
x-terminal-emulator
has caused the Debian Bug report #1003452,
regarding dpkg: missing alternatives for x-terminal-emulator
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1003452: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003452
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.21.1
Severity: important

I notice that /usr/bin/mlterm is missing from the alternatives
for x-terminal-emulator:

cventin:~> update-alternatives --display x-terminal-emulator
x-terminal-emulator - manual mode
  link best version is /usr/bin/gnome-terminal.wrapper
  link currently points to /usr/bin/xterm
  link x-terminal-emulator is /usr/bin/x-terminal-emulator
  slave x-terminal-emulator.1.gz is /usr/share/man/man1/x-terminal-emulator.1.gz
/usr/bin/gnome-terminal.wrapper - priority 40
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/gnome-terminal.1.gz
/usr/bin/koi8rxterm - priority 20
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/koi8rxterm.1.gz
/usr/bin/lxterm - priority 30
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/lxterm.1.gz
/usr/bin/urxvt - priority 20
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/urxvt.1.gz
/usr/bin/uxterm - priority 20
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/uxterm.1.gz
/usr/bin/xterm - priority 20
  slave x-terminal-emulator.1.gz: /usr/share/man/man1/xterm.1.gz

This was also the case for the xterm related programs until
I reinstalled xterm with dpkg -i.

Concerning mlterm and x-terminal-emulator, I can see in
the /var/log/alternatives.log* log files from the latest
mlterm upgrade until I noticed the issue:

update-alternatives 2021-08-16 16:27:55: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/mlterm 20 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/mlterm.1.gz
update-alternatives 2021-08-22 01:56:43: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/gnome-terminal.wrapper 40 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/gnome-terminal.1.gz
update-alternatives 2021-09-13 09:49:58: run with --remove x-terminal-emulator 
/usr/bin/urxvtcd
update-alternatives 2021-09-13 09:50:00: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/urxvt 20 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/urxvt.1.gz
update-alternatives 2021-09-27 14:08:32: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/gnome-terminal.wrapper 40 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/gnome-terminal.1.gz
update-alternatives 2021-11-23 13:29:02: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/gnome-terminal.wrapper 40 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/gnome-terminal.1.gz
update-alternatives 2021-12-06 13:49:47: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/gnome-terminal.wrapper 40 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/gnome-terminal.1.gz
update-alternatives 2021-12-06 13:49:47: link group x-terminal-emulator updated 
to point to /usr/bin/gnome-terminal.wrapper
update-alternatives 2022-01-05 11:01:08: run with --remove x-terminal-emulator 
/usr/bin/urxvtcd
update-alternatives 2022-01-05 11:04:12: run with --install 
/usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/urxvt 20 --slave 
/usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz 
/usr/share/man/man1/urxvt.1.gz

I wonder whether some upgrade of gnome-terminal or rxvt trashed the 
alternatives.

-- Package-specific info:

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: 

Bug#914515: marked as done (dpkg: please provide an interface to bootstrap dpkg from zero)

[Debian Bug Tracking System]

Your message dated Tue, 15 Mar 2022 03:43:47 +0100
with message-id 
and subject line Re: Bug#914515: dpkg: please provide an interface to bootstrap 
dpkg from zero
has caused the Debian Bug report #914515,
regarding dpkg: please provide an interface to bootstrap dpkg from zero
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
914515: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914515
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.19.2
Severity: wishlist

Hi,

lintian recently tagged mmdebstrap with uses-dpkg-database-directly
because mmdebstrap contains the string "/var/lib/dpkg" in several
places. Instead of overwriting the lintian tag in mmdebstrap, dpkg could
also gain an interface which avoids mmdebstrap having to do anything
with /var/lib/dpkg inside the chroot. Specifically, what mmdebstrap does
is the following:

 - create /var/lib/dpkg, /var/lib/dpkg/triggers, /var/lib/dpkg/info,
   /var/lib/dpkg/alternatives and /var/lib/dpkg/updates because dpkg
   throws an error if these directories are not present

 - an empty /var/lib/dpkg/status because dpkg refuses to work without
   the file being present

 - adds architectures to /var/lib/dpkg/arch because $(dpkg
   --add-architecture) doesn't work without any packages inside the
   chroot

 - cleans up leftover /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock

This could be avoided if:

 - dpkg would not complain anymore about non-existing directories but
   instead create them if they don't exist yet

 - dpkg would not complain about a non-existing status file but create
   an empty one if it doesn't exist yet

 - allow $(dpkg --add-architecture) to work in places other than /

 - add an interface to clean up /var/lib/dpkg

Thanks!

cheers, josch
--- End Message ---
--- Begin Message ---
Version: 1.20.2

Hi!

On Fri, 2019-03-15 at 14:55:41 +0100, Johannes Schauer wrote:
> Quoting Guillem Jover (2019-03-15 05:22:32)
> > On Sat, 2018-11-24 at 10:24:09 +0100, Johannes 'josch' Schauer wrote:
> > > lintian recently tagged mmdebstrap with uses-dpkg-database-directly 
> > > because
> > > mmdebstrap contains the string "/var/lib/dpkg" in several places. Instead
> > > of overwriting the lintian tag in mmdebstrap, dpkg could also gain an
> > > interface which avoids mmdebstrap having to do anything with /var/lib/dpkg
> > > inside the chroot. Specifically, what mmdebstrap does is the following:
> > > 
> > >  - create /var/lib/dpkg, /var/lib/dpkg/triggers, /var/lib/dpkg/info,
> > >/var/lib/dpkg/alternatives and /var/lib/dpkg/updates because dpkg
> > >throws an error if these directories are not present
> > Right, will handle those.
> > 
> > >  - an empty /var/lib/dpkg/status because dpkg refuses to work without
> > >the file being present
> > I've fixed this one now in a local next/bootstrap branch which I'll push out
> > tomorrow-
> 
> Cool! But I'll only follow up on this in mmdebstrap once we release Buster. :)
> 
> Another file that I found is required is /var/lib/dpkg/available. If this file
> does not exist (it can even be empty) then package removals will fail.

This should have been fixed initially with 1.20.0, but then a few
lingering things got fixed in 1.20.2. I'm closing this now, as I
forgot to add the closure on the changelog (which I later amended, but
that did not get picked up by debbugs).

Closing now, please feel free to reopen or file a new one if there's
anything still missing.

Thanks,
Guillem--- End Message ---

Bug#757607: dpkg-dev: unhelpful error message when quilt-patching debian/*

[Guillem Jover]

Hi!

On Thu, 2015-08-27 at 13:18:12 +0200, Jakub Wilk wrote:
> Control: found -1 1.18.2
> 
> * Guillem Jover , 2014-08-09, 20:45:
> > > This is what happens when you add a debian/* file to a quilt patch
> > > (which is apparently something newcomers sometimes do...) and then
> > > try to build the source package:
> > > 
> > > patching file debian/rules
> > > Reversed (or previously applied) patch detected!  Skipping patch.
> > > 1 out of 1 hunk ignored
> > > dpkg-source: info: fuzz is not allowed when applying patches
> > > dpkg-source: info: if patch 'moo.diff' is correctly applied by
> > > quilt, use 'quilt refresh' to update it
> > > 
> > > Here the patch is correctly applied by quilt (in the sense that you
> > > can push and pop it), but no amount of refreshing will fix the
> > > problem.
> > > 
> > > Could dpkg-source say explicitly that quilt-patching debian/* files
> > > is not supported, and suggest using "quilt remove"?
> > 
> > Sure, makes sense. I'm fixing this for 1.17.12, as I'm wrapping up the
> > 1.17.11 release right now.
> 
> Any news on this? 1.17.12 was released over a year ago, but I can still
> reproduce this bug.

I think at the time it seemed quick to fix, but when I actually looked,
it wasn't. In the mean time, through another (related) report, I improved
the error message which now reads as follows:

  ,---
  […]
  dpkg-source: info: applying debian-changes.patch
  patching file debian/rules
  Reversed (or previously applied) patch detected!  Skipping patch.
  2 out of 2 hunks ignored
  dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
  dpkg-source: info: if patch 'debian-changes.patch' is correctly applied by 
quilt, use 'quilt refresh' to update it
  dpkg-source: info: if the file is present in the unpacked source, make sure 
it is also present in the orig tarball
  dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B 
.pc/debian-changes.patch/ --reject-file=- < 
source-1.0.orig._XkvRm/debian/patches/debian-changes.patch subprocess returned 
exit status 1
  dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
  `---

Where it is now hinted that patching a file that is not present in the
orig tarball will fail. I think this is an improvement, that covers
this case too, although perhaps it's not entirely obvious to a newcomer.

Ideally, the patch would get parsed, and any hunk modifying or
deleting (instead of adding) a file that is not present in the orig
tarball would be detected and handled on its own, but I'm afraid that
will need more work here.

Thanks,
Guillem

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

-- stop hard-coding dpkg_datadir
> to avoid changing all pathname concatenation I changed dpkg_datadir to
> «$(patsubst %/,%,$(dir $(lastword $(MAKEFILE_LIST». But given that
> I think we might still need to substitute other things I've left this
> one out for now.

A rebased and slightly less intrusive version is attached.

-- scripts/mk/buildopts.mk: small optimisations
> I've left this one out as it is kind of an API change. I think it

The tradition in Make APIs is to condider that "undefined" and "empty"
are equivalent.  I dislike this tradition, but it is widely accepted
and there were precedents in scripts/mk/*.mk.

> might perhaps make more sense to fallback to setting it to 1 if it's
> missing, but I need to ponder about possible consequences/fallout, etc.

In case you decide to keep an undefined (or empty :-) value by
default, I suggest to add a commented example:
# $(MAKE) $(addprefix -j,$(DEB_BUILD_OPTION_PARALLEL))
# SPHINXDOC += $(addprefix -j,$(DEB_BUILD_OPTION_PARALLEL))
$(addprefix) avoids an explicit test, which is exactly the purpose of
DEB_BUILD_OPTION_PARALLEL as far as I understand.

-- scripts/mk: reduce the number of subprocesses
> I've left this one out for now. I'm not entirely satisfied with the
> sed usage here. If we keep using sed, then I think it needs to be set
> via a SED variable, substituted from the value found at configure
> time. But then, I've been pondering whether we can have better export

That is right only for packages using autoconf, but even then, how do
you get $(SED) from debian/rules?

Even autoconf-generated ./configure scripts assume that a minimal 'sed'
is available, so I think we can do the same when building a Debian
package.

> formats, that might make the sed usage not necessary. I started with a
> make-eval export mode for buildflags, but perhaps it would be better a
> more generic formatting mode where the caller can specify how the
> output should look like, akin «dpkg-query --showformat». Will ponder
> about this.

For me, the main problem is not whether COMMAND=dpkg-buildflags or
COMMAND=dpkg-buildflags|sed, but Make itself.
$(shell COMMAND) replaces line terminators with spaces, and then
removes duplicate spaces.

If we want to invoke COMMAND at most once for all variables, its ouput
should contain multiple Make assignments.  Make assignments are
usually separated by line terminators, which are unavailable, so I
have embedded each assignment in its own $(eval).
In other words, I have used balanced parenthesis as separators.
This seems a sensible compromise for build flags.

The ideal solution would set Make variables with raw values,
but I see no simple way.

One could define ad-hoc variables like

  space := $(undefined) $(undefined)
  define new_line :=


  endef

that the output of COMMAND can $$(embed), but then you also need
$(equal), $(colon), $(openparenthesis) and so on :-)

A temporary file intended for inclusion by debian/rules solves most
escaping problems, but adds complexity.

-- scripts/mk: protect against repeated inclusion
> dedicated variable instead of reusing the existing ones, in case the

Fixed in the attached commit.

-- scripts/mk: improve details in documentation
> I've left this one out for now. The version information was added on
> purpose to help people know when each interface or file was added, so

Fixed in the attached commit (sorry, I thought that we were not
supporting anything before oldoldstable).

Thanks for the answers.
>From 043f2cd6b8c445a2f0667260a2e4fabbe2e2488b Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Mon, 29 Jul 2019 14:38:32 +0200
Subject: [PATCH 1/6] scripts/mk: stop hard-coding dpkg_datadir

The Makefile snippets include each other from their common directory,
but the path differ during tests and after installation.  Instead of
rewriting the file with a hardcoded path, compute it within Make.
---
 build-aux/subst.am   |  6 --
 scripts/mk/Makefile.am   | 16 
 scripts/mk/buildtools.mk |  2 +-
 scripts/mk/default.mk|  2 +-
 4 files changed, 2 insertions(+), 24 deletions(-)

diff --git a/build-aux/subst.am b/build-aux/subst.am
index 74a40bf0b..4cd4bdca8 100644
--- a/build-aux/subst.am
+++ b/build-aux/subst.am
@@ -38,9 +38,3 @@ SUFFIXES += .pl
 	@test -d `dirname $@` || $(MKDIR_P) `dirname $@`
 	$(do_perl_subst) <$< >$@
 	$(AM_V_at) chmod +x $@
-
-# Makefile support.
-
-do_make_subst = $(AM_V_GEN) $(SED) \
-	-e "s:dpkg_datadir[[:space:]]*=[[:space:]]*[^[:space:]]*:dpkg_datadir = $(pkgdatadir):" \
-	# EOL
diff --git a/scripts/mk/Makefile.am b/scripts/mk/Makefile.am
index a82e409d6..0c635bf00 100644
--- a/scripts/mk/Makefile.am
+++ b/scripts/mk/Makefile.am
@@ -9,19 +9,3 @@ dist_pkgdata_DATA = \
 	pkg-info.mk \
 	vendor.mk \
 	# EOL
-
-SUFFIXES =
-
-include $(top_srcdir)/build-aux/subst.am
-
-# Ideally we'd use '$(SED) -i', but unfortunately that's not portable.
-install-data-hook:
-	$(do_make_subst) <$(DESTDIR)$(pkgdatadir)/default.mk \
-