Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)

[Guillem Jover]

Hi!

On Sat, 2022-12-17 at 17:24:57 -0700, Sean Whitton wrote:
> On Sat 17 Dec 2022 at 04:43PM +01, Guillem Jover wrote:
> > Sorry, probably my fault! As I tend to use «Fixes:» git pseudo-fields
> > for things that fix part of a bug, but are not intended yet to close it,
> > for which I use «Closes:».
> >
> > And for some reason I think I also got the impression, even though
> > the stanza changes had been committed, they could still be backed out.
> > (BTW I've now gone over the wiki and updated all paragraph references
> > that applied to stanza.)
> >
> > In any case, I've sat down and gone over the meat of the original
> > report. See below.
>·
> We're sticking with 'stanza', and in light of that, could you confirm
> that the bug is reopened in order to make additional fixes, rather than
> back anything else out?

In case my other replies to Russ didn't make this clear. This comment
was in reference to the various replies in the sub-thread started by
Charles, where it looked to me like whether to back that out was still
an open question for the editors.

In any case, as I mentioned, given the changes being included in the
release, I took that as indeed, sticking with the term, and that's why
I reopened and submitted the actual changes this original report was
intending on requesting. :)

As an aside I've since updated the dpkg code and docs to refer to
these as stanzas everywhere applicable.

Thanks,
Guillem

Bug#1028503: UDD: Unknown "yes" value for Forwarded field in patch metadata

[Guillem Jover]

On Thu, 2023-01-12 at 12:05:51 +0100, Lucas Nussbaum wrote:
> On 12/01/23 at 01:57 +0100, Guillem Jover wrote:
> > I just noticed though that it does
> > not recognize a "yes" value for the Forwarded field, while the
> > "Patch Tagging Guidelines" has this to say about it:
> > 
> >   * Forwarded (optional)
> > 
> > Any value other than "no" or "not-needed" means that the patch has
> > been forwarded upstream. Ideally the value is an URL proving that
> > it has been forwarded and where one can find more information about
> > its inclusion status.
> > 
> > If the field is missing, its implicit value is "yes" if the "Bug"
> > field is present, otherwise it's "no". The field is really required
> > only if the patch is vendor specific, in that case its value should
> > be "not-needed" to indicate that the patch must not be forwarded
> > upstream (whereas "no" simply means that it has not yet been done).
> > 
> > So it says that any value other than "no" or "not-needed" means
> > forwarded, then it says that if the field is missing it means it is an
> > implicit value of "yes", where I've always interpreted as implicitly
> > stating that "yes" is also a valid value.
> 
> If the field is missing, then its implicit value is 'yes' only if the
> Bug field (which points to the upstream bug) is present.

Sure, the point I was trying to make is that when the field is present
it is stated that any value (other than "no" or "not-needed") is
considered to mean it has been forwarded. And as I had the perception
that you might be trying to be strict on the values accepted, I was
trying to argue that because the value "yes" is mentioned (with quotes,
so I interpret it as one more of the "known values" even if referred
as an implicit value), then when the field is present it should also
be accepted with such "known values".

I otherwise do not know how we can mark patches as forwarded when
for example you send them directly to upstream via email or to a mailing
list that has no public archive or similar.

> > (I also recently amended the patch metadata header template generated
> > by dpkg-source and did not have "yes" as a value there, but I've added
> > it locally now, and will probably queue it for dpkg 1.22.x.)
> 
> The logic in the UDD implementation is documented just below the table:
> > The forwarded value in the table is computed and might differ slightly
> > from the original DEP3 specification. It is yes only if an URL is
> > provided as value. It is invalid if none of the other value could be
> > determined with certainty (yes, no, not-needed).

I'm wondering why diverge from the patch metadata guidelines? If there's
a desire to change the field semantics, perhaps it would be better to
change the guidelines instead? :)

But given this interchange, perhaps we should try to make it more
clear or explicit about some of these aspects there!

> But I could do better, and consider the Bug field in the analysis.

I think the Origin field needs to be taken into account too, in
particular when it has an "upstream" or a "backport" value. As well as
the Applied-Upstream field.

> The problem I have is that the 'Bug' header is often misused, and used
> for the Debian bug instead of the upstream bug. But I could special-case
> that.

Sure, if the Bug field is misused I see no problem with flagging it as
erroneous.

Thanks,
Guillem

Bug#1028503: UDD: Unknown "yes" value for Forwarded field in patch metadata

[Guillem Jover]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi!

The new patch data is great, thanks! I just noticed though that it does
not recognize a "yes" value for the Forwarded field, while the
"Patch Tagging Guidelines" has this to say about it:

  * Forwarded (optional)

Any value other than "no" or "not-needed" means that the patch has
been forwarded upstream. Ideally the value is an URL proving that
it has been forwarded and where one can find more information about
its inclusion status.

If the field is missing, its implicit value is "yes" if the "Bug"
field is present, otherwise it's "no". The field is really required
only if the patch is vendor specific, in that case its value should
be "not-needed" to indicate that the patch must not be forwarded
upstream (whereas "no" simply means that it has not yet been done).

So it says that any value other than "no" or "not-needed" means
forwarded, then it says that if the field is missing it means it is an
implicit value of "yes", where I've always interpreted as implicitly
stating that "yes" is also a valid value.

(I also recently amended the patch metadata header template generated
by dpkg-source and did not have "yes" as a value there, but I've added
it locally now, and will probably queue it for dpkg 1.22.x.)

Thanks,
Guillem

Bug#1028296: dpkg-query man page: unclear about -S reproducibility

[Guillem Jover]

Hi!

On Mon, 2023-01-09 at 11:59:17 +0100, Jakub Wilk wrote:
> Package: dpkg
> Version: 1.21.17

> The dpkg-query(1) man page says about the -S option:
> 
> > Hint: When machine parsing the output, it is customary to set the locale
> > to C.UTF-8 to get reproducible results.
> 
> Assuming that "set the locale" means setting the LC_ALL environment
> variable, then that's not sufficient, because the output is still affected
> by LANGUAGE:

I worded that hint vaguely so that I would not need to give details
about system specific quirks. :) In my mind "set the locale" implies
do whatever is necessary so set any locale stuff so that it does not
affect the output. Do you think it would have been more clear to say
instead something like "set the locale and language to C.UTF-8" or
similar?

>$ LC_ALL=C.UTF-8 dpkg -S /bin/zgrep
>diversion by zutils from: /bin/zgrep
>diversion by zutils to: /bin/zgrep.gzip
>gzip, zutils: /bin/zgrep
> 
>$ LANGUAGE=pl LC_ALL=C.UTF-8 dpkg -S /bin/zgrep
>ominięcie przez zutils z: /bin/zgrep
>ominięcie przez zutils do: /bin/zgrep.gzip
>gzip, zutils: /bin/zgrep
> 
> See also bug #748215.

(While I think I might have been aware of the precedence at some point
in time, that might not have properly sink in, as I see several
instances in the code setting LC_ALL but not LANGUAGE (in some cases
LANG instead which perhaps were a typo for LANGUAGE), so I'll be
fixing this in the code in the future. Thanks for the pointer!)

Thanks,
Guillem

Bug#1027476: closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#1027476: fixed in cron 3.0pl1-155)

[Guillem Jover]

Control: reopen -1

Hi!

Although I've not tested nor checked the affected code, the fix done
to close this cannot possibly be correct, see below. :)

On Mon, 2023-01-09 at 21:27:06 +, Debian Bug Tracking System wrote:
> Date: Sun, 01 Jan 2023 07:12:58 -0500
> From: "Kevin P. Fleming" 
> To: Debian Bug Tracking System 
> Subject: cron: postrm script fails because expected dpkg-statoverride is
>  not present

> The postrm script in the current version of the cron package assumes the
> presence of a dpkg-statoverride for /usr/bin/crontab, but no such statoverride
> is present on my systems. As a result when I try to 'purge' the cron package
> the process fails.

I think the description might be read incorrectly. The error is not
that the dpkg-statoverride program is missing, as that's not possible
(w/o force) being part of dpkg which is an Essential package. But that
a statoverride entry setup by some package is missing.

> This results in the following output:
> 
> Reading package lists... Done
> Building dependency tree... Done
> The following packages will be REMOVED:
>   cron*
> 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue? [Y/n] y
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LANG = "en_US.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such 
> device)
> (Reading database ... 11054 files and directories currently installed.)
> Purging configuration files for cron (3.0pl1-154) ...
> dpkg-statoverride: warning: no override present

As can be seen here, the tool is executed and it runs, but it warns that
it cannot find the statoverride entry.

> dpkg: error processing package cron (--purge):
>  installed cron package post-removal script subprocess returned error exit
> status 2
> Errors were encountered while processing:
>  cron
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Editing /var/lib/dpkg/info/cron.postrm to remove the first section resolves 
> the
> issue.

Adding a dependency on dpkg cannot have solved anything here.

Thanks,
Guillem

Bug#1028044: $bf->strip can't strip duplicated flags

[Guillem Jover]

Hi!

On Fri, 2023-01-06 at 16:58:44 +0800, Shengjing Zhu wrote:
> Package: libdpkg-perl
> Version: 1.21.13
> Severity: normal
> X-Debbugs-Cc: z...@debian.org

> Given input `-flto=auto -flto=auto`, $bf->strip($flag, "-flto=auto") returns
> `-flto=auto`.
> However if given `-flto=auto -ffat-lto-objects -flto=auto`, it will return
> `-ffat-lto-objects`. (two -flto=auto are tripped)
> 
> I read the code has `g` in regexp, so I think you want to strip duplicated
> flag. But the regexp pattern is bit buggy when two duplicated flags are 
> together.

Ah, indeed nice catch, this is caused due to the space left at the
beginning which then does not match on the subsequent iteration.
Fixing it for 1.21.18.

> Background:
> 
> In dh-golang, I use $bf->strip to strip lto flags
> https://salsa.debian.org/go-team/packages/dh-golang/-/merge_requests/18
> 
> It works for a while in Debian. But I found Ubuntu still carries an LTO
> patch in the Go compiler. Then I wonder whether my dh-golang hack doesn't
> work for them.
> 
> In Ubuntu, for unknown reason, their dpkg-buildflags gives a duplicated lto
> flags. `-flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects`.
> After $bf->strip($flag, "-ffat-lto-objects -flto=auto"), it becomes 
> `-flto=auto`.
> Still one lto flag left...

This is a problem in the Ubuntu dpkg delta, which they have
kept incorrectly rebasing, and have been applying the off-tree lto patch
even after it got merged upstream, so now they are injecting these twice.
I mentioned this at the time, and reminded the recent person doing the
merge to fix, but that's entirely on their hands.

Thanks,
Guillem

Bug#1027716: dpkg: consider trimming changelog.gz

[Guillem Jover]

Hi!

On Mon, 2023-01-02 at 09:56:56 +0100, Helmut Grohne wrote:
> Package: dpkg
> Version: 1.21.12
> Severity: wishlist

> dpkg's changelog.gz keeps growing. For the changelog.Debian.gz,
> debhelper has started pruning old entries. At this time, the changelog
> contributes one 7th of dpkg's Installed-Size and a third of its .deb
> size. For development systems, one typicalls has four copies of it. I
> think it would be worth investigating possible reductions:
> 
> a) Is it really necessary to keep changelogs until 2009?

So, I'm not very happy with the change in debhelper trimming
changelogs, even more so, given that apt still uses the on-disk
changelog, so there's currently no easy way to get at those.

I think, though that not shipping the «git log» at all would be a fine
compromise. So I guess I'll add --no-trim, and stop shipping the
ChangeLog. Because in any case people can always exclude these paths.

> b) Consider reducing the copies by using symbolic links to the instance
>in the dpkg binary package.

I've considered this option in the past, but it would require a strict
dependency on dpkg which did not seem ideal.

Thanks,
Guillem

Bug#1027759: pylint: Missing dependency on python3-tomli for python3 < 3.11

[Guillem Jover]

Control: reopen -1
Control: reassign -1 devscripts
Control: retitle -1 devscripts: Wrong usage of pylint as a module breaks

Hi!

On Thu, 2023-01-05 at 00:18:13 -0500, Sandro Tosi wrote:
> > Package: pylint
> > Version: 2.15.9-1
> > Severity: serious

> > It looks like the recent release is missing a dependency on
> > python3-tomli when the python used is not at least 3.11. Seen on
> > test suite failures locally and on the devscripts CI pipelines:
> >
> >   https://salsa.debian.org/guillem/devscripts/-/jobs/3733272#L2644
> 
> this bug is invalid; pylint is a cli tool, not a module, so running it as
> 
>   /usr/bin/python3.10 -m pylint 
> 
> (https://salsa.debian.org/guillem/devscripts/-/jobs/3733272#L2619) in 
> incorrect.
> 
> call /usr/bin/pylint

In that case, this should be fixed in devscripts (as that MR did not
introduce this usage, it just triggered the failure). Reassigning.

Thanks,
Guillem

Bug#501456: dpkg-deb: Add new option --compress-program=

[Guillem Jover]

Control: tags -1 - patch

Hi!

On Sat, 2016-06-18 at 23:19:16 +0300, Konstantin Khlebnikov wrote:
> Here is tiny patch which adds new option dpkg-deb --compress-program=
> Program is executed as a filter with single argument: compression level -0 .. 
> -9

The code is not reaping the child, nor closing the file descriptors,
this is covered in fd_fd_filter(), but…

> So, any existing parallel compression tool (pigz/pbzip2/pxz/pixz)
> could be used here.
> Of course compression type (-Z) must match. Such compression might not
> suit for official
> builds because it have lower ratio, but will save tons of time for
> building debug packages.

…this is the main problem I have with such patch, that you can specify
any random program and it might or might not match the intended
compression. Also as stated previously several of these tool generate
output that is not ideal anyway.

Thanks,
Guillem

Bug#1027966: building of cross-toolchain-base broken, wrong assumption of dpkg-buildinfo

[Guillem Jover]

Control: found -1 1.21.10

On Thu, 2023-01-05 at 11:23:30 +0100, Matthias Klose wrote:
> Package: dpkg-dev
> Version: 1.21.16
> Severity: serious
> Tags: sid bookworm

> see 
> https://buildd.debian.org/status/fetch.php?pkg=cross-toolchain-base-ports=all=60=1672912429=0
> 
> touch /<>/glibc-2.36/stamp-dir/binaryinst_libc6.1-udeb
> make[1]: Leaving directory '/<>/glibc-2.36'
>  dpkg-genbuildinfo --build=any -O../glibc_2.36-7_alpha.buildinfo
> In file included from /usr/include/features.h:392,
>  from /usr/include/unistd.h:25,
>  from :1:
> /usr/include/features-time64.h:20:10: fatal error: bits/wordsize.h: No such
> file or directory
>20 | #include 
>   |  ^
> compilation terminated.
> dpkg-genbuildinfo: error: alpha-linux-gnu-gcc -w -x c - subprocess returned
> exit status 1
> dpkg-buildpackage: error: dpkg-genbuildinfo --build=any
> -O../glibc_2.36-7_alpha.buildinfo subprocess returned exit status 25
> make: *** [debian/rules:366: stamp-dir/build-glibc2.alpha] Error 2
> 
> 
> there is a bad assumption that the existence of a cross compiler means that
> you can successfully run the cross compiler.  Here we just built the
> "missing" glibc headers, so you cannot yet use the cross compiler.

Hmm, ok. And we cannot use -ffreestanding either. I guess I'll just
make the code ignore the condition when the compiler fails. I suppose
this might be blocking you for the toolchain freeze, so I'll upload a
fix right away.

Thanks,
Guillem

Bug#1027794: sqop: Please package latest upstream release 0.27.2

[Guillem Jover]

Source: rust-sequoia-sop
Source-Version: 0.27.2
Severity: wishlist
Tags: upstream

Hi!

This version is supposed to fix the issue that prevented it from being
used by dpkg-dev for its SOP OpenPGP backend. I'm only filing this
because it would be nice to add support for it for the upcoming Debian
release, but there's only few days until the toolchain freeze. I'm
planning on doing (probably more) but at least a final release around
the 9th, to give room for dpkg to migrate before the 12th.

Otherwise, no hurry, and I'll enable sqop as a SOP implementation
after that. :)

Thanks,
Guillem

Bug#1027759: pylint: Missing dependency on python3-tomli for python3 < 3.11

[Guillem Jover]

Package: pylint
Version: 2.15.9-1
Severity: serious

Hi!

It looks like the recent release is missing a dependency on
python3-tomli when the python used is not at least 3.11. Seen on
test suite failures locally and on the devscripts CI pipelines:

  https://salsa.debian.org/guillem/devscripts/-/jobs/3733272#L2644

Thanks,
Guillem

Bug#1027720: dgit: Can now avoid using Dpkg::Compression::Process

[Guillem Jover]

Package: dgit
Version: 10.4
Severity: wishlist

Hi!

With dpkg 1.21.14, the Dpkg::Compression module got some improvements,
the one that seems relevant to dgit, is that you can now fetch the
command-line to execute from a Dpkg::Compression getter instead of
having to create a Dpkg::Compression::Process object. With
compression_get_cmdline_decompress().

Thanks,
Guillem

Bug#1027719: sbuild: Uses deprecated libdpkg-perl functions

[Guillem Jover]

Package: sbuild
Version: 0.84.2
Severity: wishlist

Hi!

With dpkg 1.21.14 several functions and modules got deprecated,
including deprecation warnings, but those were causing autopkgtest
failures which would prevent dpkg from migrating so I silenced them
for now. It would still be nice to switch to the new functions, see:

  
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=3ed9fc40eda34d77ef73e1d0dbb0b47b3c4462b0

Thanks,
Guillem

Bug#1027718: devscripts: Uses deprecated libdpkg-perl functions

[Guillem Jover]

Package: devscripts
Version: 2.22.2
Severity: wishlist

Hi!

With dpkg 1.21.14 several functions and modules got deprecated,
including deprecation warnings, but those were causing autopkgtest
failures which would prevent dpkg from migrating so I silenced them
for now. It would still be nice to switch to the new functions, see:

  
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=3ed9fc40eda34d77ef73e1d0dbb0b47b3c4462b0

Thanks,
Guillem

Bug#1026230: debhelper: Unable to successfully build in read-only source directory.

[Guillem Jover]

On Sat, 2022-12-17 at 12:07:22 +0100, Niels Thykier wrote:
> On Fri, 16 Dec 2022 13:13:34 -0500 Garrett Kajmowicz wrote:
> > One other possibly-related item of note (I can file a separate bug if you 
> > like)
> > and which may have an existing solution:
> > Passing in --buildinfo-option=-u/out still results in a -O option which
> >   refers to the wrong directory. That is, I get the following:
> > dpkg-genbuildinfo -u/out --build=binary 
> > -O../_2.0.6-1_amd64.buildinfo
> > dpkg-genbuildinfo: error: cannot write 
> > ../_2.0.6-1_amd64.buildinfo.new: Permission denied
> > 
> > This resulted from an experiment where I was copying the source code to
> > a temporary directory with read/write permissions, but where the parent
> > directory was not writable.

> If it is a bug, then it is a separate one for dpkg. I will let Guillem
> comment on that.

After checking this, I think I'd consider this at most a missing
feature, related to the overall request here, and as part of that to be
able to specify a different global "upload-files-dir".

But for now I think you should be able to overcome this by using the
dpkg-buildpackage --buildinfo-file option.

Thanks,
Guillem

Bug#1026230: debhelper: Unable to successfully build in read-only source directory.

[Guillem Jover]

Hi!

On Sat, 2022-12-17 at 12:07:22 +0100, Niels Thykier wrote:
> On Fri, 16 Dec 2022 13:13:34 -0500 Garrett Kajmowicz wrote:
> > Package: debhelper
> > Version: 13.6ubuntu1
> > Severity: wishlist

> I have CC'ed Guillem Jover because *if* this is a change to be supported,
> then it would need dpkg and debhelper to support it.
> 
> > I'm working on a use-case which can be generalized as wanting to be able
> > to perform a build with debhelper in a read-only source directory. Not
> > simply that the files themselves are read-only, but that the full
> > directory
> > tree is read-only. [...]
> 
> Ok.  As you have discovered, having a read-only source directory is not a
> use-case that the Debian build stack supports at the moment.  The build
> process is largely working with the assumption that the source package is
> copied to a writeable directory and then built there (i.e., you have a
> writeable base directory and then unpack the source package into a subfolder
> of that directory).

Right, and while I'm happy to entertain the possibility to support
something like this, it seems a bit like one of those gargantuan
projects we might end up with. So, I guess I'd also like to understand
the motivations, and perhaps whether other alternatives are not
fulfilling? :)

I've not checked very deep on what might be blocking this, or whether
there might be other difficulties, so do not take the following as
extensive.

> For this to be possible, it would require two "independent" features in the
> Debian build stack:
> 
>  C1) Provide a writeable directory for the output artefacts (the
>  produced .debs, the .changes file etc.)
>  - This would enable to the parent directory be read-only.

This would currently be blocked by at least something like #657401,
I think

>  C2) Provide a writeable directory for the build process itself.
>  - This would enable the source directory itself to be read-only.
> 
>  => There will be packages that *cannot* support C2 as they only
> support "in-source" built (which is probably why we have the
> current setup in the first place).

I think this is partially blocked on something like
<https://lists.debian.org/debian-devel/2020/03/msg00085.html>, and
because several of the currently written files are part of the
expected interface. :/

> The C1) case is something that could be useful for Debian itself.  There are
> some tools that want to choose the location of the produced artefacts.  It
> has been a low priority wish for me to have this solved "eventually".

The overall problem, IMO, is the original packaging design we've got
in front of us, with package building being inside-out, where the build
is mainly driven by the package itself, instead of an external driver.
We have discussed this with Niels in the past, and we have some WIP work
(which I should merge the dpkg side of and email out, something I had
actually in mind talking with Niels already the past weeks!). But I'm not
seeing this (at least right now) being used by Debian for example. :/

> For the C2) case, it is not that I cannot see possibilities in it. I am more
> whether it outweighs the cost of doing it.
> 
>  => If we are going for C2, I would expect that you provide CI test
> cases to ensure the feature does not regress (at least for debhelper
> for the gitlab CI pipeline).  Otherwise, it is going to be a game of
> "whack-a-mole".
> 
>  => For C2, You may also have to do patches and tests for dh-autoreconf
> and dh-strip-nondeterminism as they are part of the default dh
> pipeline (and not maintained by me nor Guillem).

The main problem I see there, besides the current pathnames as
interfaces, is that I don't think this can be universally supported by
any package, and as such something like dpkg-buildpackage would need
to way to know whether the package supports this mode, for every and
each package (say a field such as the R³ marking), and if it that does
not get tested per package, then it will tend to break. :/

So I think I'm also currently in the "does it outweigh the cost?"
pondering phase too.

> > Many of the required capabilities are already supported. For example,
> > the --builddirectory flag allows the building step to be placed in a
> > different
> > directory.
> 
> While there are many options that package can use to tweak locations, they
> are not aimed at the thing you are doing.  Notably the dh_* -P option is
> really painful to use at scale (if you have multiple binary packages in the
> same source package).

Also I'd expect many source packaging (say overrides in debian/rules or
even debian/rules not using dh or debhelper), ancillary packaging tools
(say dh extensions) might expect

Bug#1026319: dpkg-dev: Please mention DEB_BUILD_PROFILES in dpkg-buildflags(1), too.

[Guillem Jover]

Hi!

On Sun, 2022-12-18 at 16:03:01 +0100, Axel Beckert wrote:
> Package: dpkg-dev
> Version: 1.21.12
> Severity: wishlist

> for me it seems "obvious" that the way, in which build profiles are set,
> is documented in dpkg-buildflags(1). But it isn't. It's only mentioned
> dpkg-checkbuilddeps(1) and dpkg-buildpackage(1).

Right (the only ones that end up making direct use of it).

> It would be nice, if dpkg-buildflags(1) would at least contain a pointer
> to where documentation about build profiles can found. And maybe also
> why they aren't build _flags_ despite some of them, e.g. "noopt" and
> "nocheck", look similar on a first glance.

There's no noopt build profile though. :) I was about to ask where the
confusion might be stemming from, but I guess it is precisely what you
spelled it here, that "nocheck" is both a build profile and a build
option?

(For ref:
https://wiki.debian.org/BuildProfileSpec#Map_DEB_BUILD_OPTIONS_to_namespaces,
and also note in the definition where it mentions that both need to be
set.)

In principle I'd tend to avoid mentioning things that are unrelated to
the specific tool, or even things that are "vendor policy" and not
directly used by dpkg (such as most of the currently defined build
profiles in Debian) in contrast to the mechanisms.

But I guess I could add perhaps a generic text saying more or less:

  Some build profiles might require their counterpart to also be
  included in the build options, as they are currently not properly
  integrated, the list of such build profiles is vendor specific.

or something along those lines.

I think in the past there's been talk about making for example
dpkg-buildpackage setting one if the other is set, but there was some
resistance(?). At a guess, perhaps the fact that dpkg-buildpackage is
not our official entry point, or perhaps giving freedom to users to
specify one but not the other? But right now I do not exactly recall
the details and would need to dig them up.

Thanks,
Guillem

Bug#1026316: dpkg: doesn't complain on dpkg -i breaking = dependencies

[Guillem Jover]

Control: forcemerge 20471 -1

Hi!

On Sun, 2022-12-18 at 14:43:05 +0100, Rene Engelhard wrote:
> Package: dpkg
> Version: 1.21.12
> Severity: important

> libuno-cppuhelpergcc3-3 has
> 
> Depends: ${misc:Depends}, ${shlibs:Depends}, uno-libs-private (= 
> ${binary:Version})
> 
> which then boils down to (uninteresting stuff stripped):
> 
> # apt-cache show libuno-cppuhelpergcc3-3
> Package: libuno-cppuhelpergcc3-3
> Architecture: amd64
> Version: 1:7.5.0~beta1-1
> [...]
> Depends: uno-libs-private (= 1:7.5.0~beta1-1), libc6 (>= 2.32), libgcc-s1 (>= 
> 3.3.1), libstdc++6 (>= 11), libuno-cppu3 (>= 4.4.0~alpha), libuno-sal3 (>= 
> 5.1.0~alpha), libuno-salhelpergcc3-3 (>= 1.4.0)
> [...]
> Package: libuno-cppuhelpergcc3-3
> Source: libreoffice
> Version: 1:7.4.3-2
> [...]
> Depends: uno-libs-private (= 1:7.4.3-2), libc6 (>= 2.32), libgcc-s1 (>= 
> 3.3.1), libstdc++6 (>= 11), libuno-cppu3 (>= 4.4.0~alpha), libuno-sal3 (>= 
> 5.1.0~alpha), libuno-salhelpergcc3-3 (>= 1.4.0)
> [...]
> 
> So as we see the = dependency on uno-libs-private is there.
> 
> Now (tried during finding out whether I need bumped depends/conflicts)
> try to upgrade it alone ("thanks" to apt now upgrading all packages in a
> source package manually with dpkg):
> 
> # dpkg -l libuno-cppuhelpergcc3-3 uno-libs-private
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ NameVersion  Architecture Description
> +++-===---
> ii  libuno-cppuhelpergcc3-3 1:7.4.3-2amd64LibreOffice UNO runtime 
> environment -- CPPU helper library
> ii  uno-libs-private1:7.4.3-2amd64LibreOffice UNO runtime 
> environment -- private libraries used by public ones
> # dpkg -i 
> /var/cache/apt/archives/uno-libs-private_1%3a7.5.0~beta1-1_amd64.deb 
> (Reading database ... 519340 files and directories currently installed.)
> Preparing to unpack .../uno-libs-private_1%3a7.5.0~beta1-1_amd64.deb ...
> Unpacking uno-libs-private (1:7.5.0~beta1-1) over (1:7.4.3-2) ...
> Setting up uno-libs-private (1:7.5.0~beta1-1) ...
> Processing triggers for libreoffice-common (1:7.4.3-2) ...
> # dpkg -l libuno-cppuhelpergcc3-3 uno-libs-private
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ NameVersion Architecture Description
> +++-===-===--
> ii  libuno-cppuhelpergcc3-3 1:7.4.3-2   amd64LibreOffice UNO 
> runtime environment -- CPPU helper library
> ii  uno-libs-private1:7.5.0~beta1-1 amd64LibreOffice UNO 
> runtime environment -- private libraries used by public ones
> 
> Shouldn't dpkg complain and refuse to do that unless I actually also
> upgrade libuno-cppuhelpergcc3-3?
> 
> This combo causes
> 
> $ lowriter
> Failed to open display
> Warning: failed to launch javaldx - java may not function correctly
> /usr/lib/libreoffice/program/soffice.bin: symbol lookup error: 
> /usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3: undefined symbol: 
> _ZN9xmlreader9XmlReaderC1ERKN3rtl8OUStringE
> 
> (there's more stuff here breaking (also in libmerged.so in
> libreofice-core) but uno-libs-private gets Breaks and
> libreoffice-core gets Depends, but still.
> For this case I worked around
> with 
> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/69d4c143847a02a0b147fd061bdb010c36ce5d05
> of which at least the Breaks: against libuno-cppuhelpergcc3-3 (<< 1:7.5.0~),
> should not be needed at all given the = dependency.)
> 
> apt rightfully complains about Unmet dependencies afterwards when
> installing some random package ...
> 
> # apt install less
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> less is already the newest version (590-1).
> You might want to run 'apt --fix-broken install' to correct these.
> The following packages have unmet dependencies:
>  libuno-cppuhelpergcc3-3 : Depends: uno-libs-private (= 1:7.4.3-2) but 
> 1:7.5.0~beta1-1 is to be installed
>  ure : Depends: uno-libs-private (= 1:7.4.3-2) but 1:7.5.0~beta1-1 is to be 
> installed
> E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
> specify a solution).
> #

Yeah, a known issue, which is currently tricky to fix AFAIR. Merging
with the others.

Thanks,
Guillem

Bug#1026463: kanshi: Please ship kanshictl command and man page

[Guillem Jover]

Package: kanshi
Version: 1.3.1-1
Severity: wishlist

Hi!

There seems to be a kanshictl program to control kanshi. It would be
nice if it was shipped (alongside its man page) in the package too.

Thanks,
Guillem

Bug#1026227: vagrant: Uninstallable in sid with VirtualBox 7.0.x

[Guillem Jover]

Hi!

On Sun, 2022-12-18 at 18:10:16 -0300, Antonio Terceiro wrote:
> On Fri, Dec 16, 2022 at 06:31:41PM +0100, Guillem Jover wrote:
> > Package: vagrant
> > Version: 2.2.19+dfsg-2
> > Severity: serious

> > Since virtualbox 7.0.4 got uploaded, vagrant is no longer installable
> > in Debian sid. I assume this will require packaging a new upstream
> > release to support the new virtualbox version 7.0.x series.
> 
> I cherry picked a patch from upstream that should solve the issue. The
> Breaks: restriction will now make the package installable with
> virtualbox 7.0, but I don't use virtualbox so I can't really test that
> it actually works.
> 
> Can you please try the package from git master?

I built it from git HEAD, installed and it seems to work fine now with
virtualbox 7.0.4, thanks! Even though I saw the following from the test
suite output:

  ,---
  # 
terminated with exception (report_on_exception is true):
  /tmp/vagrant/lib/vagrant/machine.rb:208:in `block in action': Vagrant 
attempted to call the action 'destroy' on the provider 
(Vagrant::Errors::UnimplementedProviderAction)
  '#', but this provider 
doesn't support this action. This
  is probably a bug in either the provider or the plugin calling this
  action, and should be reported.
  from /tmp/vagrant/lib/vagrant/environment.rb:614:in `lock'
  from /tmp/vagrant/lib/vagrant/machine.rb:201:in `call'
  from /tmp/vagrant/lib/vagrant/machine.rb:201:in `action'
  from /tmp/vagrant/lib/vagrant/batch_action.rb:86:in `block (2 levels) 
in run'
  `---

it didn't affect the test suite results nor the apparent operation with
the virtualbox plugin, so I guess this is completely unrelated.

Thanks,
Guillem

Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)

[Guillem Jover]

On Sat, 2022-12-17 at 08:35:02 -0800, Russ Allbery wrote:
> (That said, and this is only personal preference and I don't feel that
> strongly about it, I usually err on the side of creating lots of bugs so
> that there can be roughly one bug per patch.  It can make it a bit harder
> to track things if there's one bug following a bunch of semi-related but
> separable changes.  Unfortunately, the BTS doesn't support the concept of
> a hierarchy with a tracking issue and a bunch of underlying implementaton
> issue very well.)

(Right, personally I don't think I'd split one bug per patch, as long
as the patch is covering the same thing, perhaps. In this case I
pondered about opening a new one, but given the initial discussion
and context was here it seemed best to keep it together. Should have
perhaps split the stanza stuff into another report, though. :)

(In any case, hope this is all not too inconvenient!)

> Guillem Jover  writes:
> > And for some reason I think I also got the impression, even though
> > the stanza changes had been committed, they could still be backed out.
> > (BTW I've now gone over the wiki and updated all paragraph references
> > that applied to stanza.)
> 
> I'm personally happy to stick with stanza.

Sorry, rereading that paragraph it seems not clear on what I was
trying to convey. :) I meant that because I thought this could be backed
out until an upload, I guess subconsciously postponed further changes
for this (both in dpkg and here) based on that. Should have asked.

> > I also recalled another term that has always seemed very confusing in
> > context: «control information files» or «control information area». For
> > example in a sentence such as “the control file is a control information
> > file in the control information area in a .deb archive”. :) This also
> > seems confusing when some of the files in the .deb control member are
> > not really “control files” with a deb822(5) format.
> 
> > My thinking has been going into calling these as the «metadata files»,
> > and being located in either the  «metadata part of the .deb archive» or
> > explicitly the «control member of the .deb archive», in contrast to the
> > filesystem part. In dpkg I'd be eventually switching to meta/metadata
> > and fsys/filesystem, from control or info and data. I've added a patch
> > with the proposed change, but again nothing set in stone, and I'm again
> > open to discussing pros/cons of this.
> 
> I like metadata file, but I think I prefer talking about the "control
> member" than the "metadata part" because it more closely matches what one
> sees if one takes the *.deb file apart.  But I haven't looked at your
> diffs yet.

Probably more clear currently, yeah. To expand on the above, my thinking
has been for example that if we ever have a deb 3.0 format, I'd probably
like to name the members, something like: «meta.tar.*» and «fsys.tar.*»,
and that's also what I've kind of been moving the dpkg internals to
(functions, structs and similar). Also as part of the file metadata work,
I've also have pending splitting the dpkg db info/ dir into a dir that
contains things shipped by the .deb, and a dir for stuff generated by
dpkg itself, so that they cannot conflict or get overwritten or need
to be taken into account doing any of that.

Thanks,
Guillem

Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)

[Guillem Jover]

Control: reopen -1

Hi!

Sorry, probably my fault! As I tend to use «Fixes:» git pseudo-fields
for things that fix part of a bug, but are not intended yet to close it,
for which I use «Closes:».

And for some reason I think I also got the impression, even though
the stanza changes had been committed, they could still be backed out.
(BTW I've now gone over the wiki and updated all paragraph references
that applied to stanza.)

In any case, I've sat down and gone over the meat of the original
report. See below.

On Sat, 2022-12-17 at 03:09:10 +, Debian Bug Tracking System wrote:
> Date: Sun, 18 Sep 2022 22:28:00 +0200
> From: Guillem Jover 
> To: sub...@bugs.debian.org
> Subject: debian-policy: Clarifying nomenclature for control file names
> 
> Package: debian-policy
> Version: 4.6.1.1
> Severity: wishlist

> This is a followup from my comment at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#43
> 
> To summarize, we have IMO confusing naming and nomenclature for the
> various control files and paragraphs/stanzas, and this is even
> confusing me when having to deal with dpkg code, so I'd like to give
> these more clear and unambiguous new names, and I'd very strongly
> prefer to agree on the same naming for Debian policy and dpkg, to
> avoid further and worse confusion (even though they currently do not
> match exactly anyway, but I'd prefer to not make it worse…).
> 
> Just for reference and to give some context, I've got the following
> WIP branches, trying to clarify the names in documentation and in the
> API on, which I'll probably rework (split/merge) and reword as needed,
> so do not take them as anything set in stone:
> 
>   
> https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/clarify-control-filenames
>   
> https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/deb822-field-types
> 
> 
> File descriptions
> -
> 
> For example we have:
> 
>   * debian/control:
> policy → «Source package control file»
> dpkg   → «Debian source packages' master control file»
> 
>   * .dsc:
> policy → «Debian source control file»
> dpkg   → «Debian source packages' control file»
> 
>   * DEBIAN/control
> policy → «Binary package control files»
> dpkg   → «Debian binary packages' master control file»

Seems I missed another file:

  * .changes:
policy → «upload control file» / «Debian changes file»
dpkg   → «upload control file» / «.changes control file» /
 «Debian .changes file» / «Debian changes file»

> These are quite confusingly close.
> 
> I've been considering naming debian/control something like
> «Debian template source package control file», as that is used to
> generate both the source and binary control files. And always
> prefixing with Debian, so that would end up as:
> 
>   * debian/control: «Debian source package template control file»
>   * .dsc:   «Debian source package control file»
>   * DEBIAN/control: «Debian binary package control file»

For changes I think something like the following might be a more clear
option (and has the minor bonus of aligning perfectly on the first
words! :), with it mentioning explicitly this is about changes being
uploaded, and that it is a control file (but I'm not sure I'm entirely
convinced about it):

* .changes:   «Debian upload changes control files»

> This also removes the «master» usage in dpkg, for me for the same
> reasons as I covered at
> <https://lists.debian.org/debian-dpkg/2021/03/msg2.html>.

> File contents
> -
> 
> We have references to the various parts being called as «paragraphs»,
> «stanza», «blocks», but this seems to be more of an issue with dpkg, as
> the usage in the Debian policy is quite clear and uniform now, so I'll
> at least try to remove the «block» usage there, stanza has the nice
> property of being shorter and policy already mentions that this is
> currently a common alias, so I might keep paragraph and stanza for now
> in dpkg.

I've also found instances of «record» and «section» referring to fields
or stanzas.

> The other thing affecting dpkg and debian-policy is how the parts
> within the control files are referred to. We have for example:
> 
>   dpkg   → «general section of control info file»
>«source stanza»
>   policy → «general paragraph»
> 
>   dpkg   → «package's section of control info file»
>   policy → «binary package paragraphs»
> 
> 
> So, how does «source package paragraph» and «binary package paragraph»
> (of the «template control file») sound instead?

> If I've missed any other problematic nomenclature, I'm happy to
> discuss and update those on the dpkg side.

I also recalled another term that has always seemed very confusin

Bug#1026227: vagrant: Uninstallable in sid with VirtualBox 7.0.x

[Guillem Jover]

Package: vagrant
Version: 2.2.19+dfsg-2
Severity: serious

Hi!

Since virtualbox 7.0.4 got uploaded, vagrant is no longer installable
in Debian sid. I assume this will require packaging a new upstream
release to support the new virtualbox version 7.0.x series.

Thanks,
Guillem

Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

[Guillem Jover]

Hi!

On Wed, 2022-12-14 at 15:27:18 +0100, Juri Grabowski wrote:
> Package: wnpp
> Version: 1.79
> Severity: wishlist
> Owner: Juri Grabowski 
> X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@jugra.de

> * Package name: distribution-gpg-keys
>   Version : 1.7.9
>   Upstream Author : Miroslav Suchý 
> * URL : https://github.com/xsuchy/distribution-gpg-keys/
> * License : CC0-1.0
>   Programming Lang: data
>   Description : GPG keys by various Linux distributions
> 
> used by various Linux distributions to sign packages.
> 
> needed by mock/3.5 and I need a sponsor for this package. See current 
> packaging in
> https://salsa.debian.org/pkg-rpm-team/distribution-gpg-keys
> After I know ITP bug number I upload this source package to
> https://mentors.debian.net/package/distribution-gpg-keys/

The project name talks about gpg keys, but those are really OpenPGP
keys (or even better, certificates). I've asked upstream to rename the
project to avoid this common confusion. So you might want to wait until
that's settled to avoid multiple trips over NEW.

  

(If this project is also intended to only cover RPM-based distributions,
as Adam brought up, you might want to further ask them to make that clear
from the project name, say rpm-distribution-openpgp-keys or similar. But
in any case regardless of the intended target use, it still seems like a
very generic name which can be easily confused for a package that would
be needed for Debian, or derivatives.)

Thanks,
Guillem

Bug#1021292: Fw: Re: Enabling branch protection on amd64 and arm64

[Guillem Jover]

On Mon, 2022-12-12 at 04:28:29 +, Wookey wrote:
> The debian-devel thread continued but most responses were not copied
> to the bug (I've just realised). Possibly this means that you (guillem)
> didn't see most of the conversation.
> 
> The bottom line is the security team were very unenthusiastic about
> enabling this by default because it might produce unexpected changes
> on security uploads, which is fair enough.
> 
> Another suggestion was that it should be turned on for x32 too.
> 
> I was expecting (after that discussion) the 'branch' functionality to be
> included in the next dpkg upload, just not enabled by default, but it
> was not included in 1.21.12
> 
> Do you disagree or did this just get forgotten?

As I think I mentioned previously, the problem is that we cannot
currently add it even disabled by default, due to many packages using
«hardening=+all» which has the same effect for these as the option
being enabled by default.

What I also mentioned, and as I was expecting there to be pushback on
the new hardening feature, is to perhaps add versioned buildflags
support. I'll post what I've got to debian-dpkg during this week.

Thanks,
Guillem

Bug#1025436: lintian: Silence executable-stack-in-shared-library tag on mips*

[Guillem Jover]

Package: lintian
Version: 2.115.3
Severity: important

Hi!

It seems that glibc forces an executable stack on MIPS architectures
(see #1022787).

On mipsel and mips64el architectures this is causing for all shared
libraries the emission of the executable-stack-in-shared-library tag.

As that report does not seem that it will be handled for bullseye, it
would be nice if the tag could be silenced on these architectures, as
there is nothing maintainers can really do about this, which is
actually leading them into dead ends and incorrect fix attempts.

Thanks,
Guillem

Bug#1025261: vagrant: Broken with ruby3.1

[Guillem Jover]

Package: vagrant
Version: 2.2.19+dfsg-1
Severity: serious

Hi!

After the upgrade of ruby to the 3.1 version vagrant has stopped
working completely, I'm getting the following errors repeated multiple
times:

,---
/usr/lib/ruby/vendor_ruby/rubygems/resolver/conflict.rb:47:in 
`conflicting_dependencies': undefined method `request' for nil:NilClass 
(NoMethodError)

[@failed_dep.dependency, @activated.request.dependency]
   
from /usr/lib/ruby/vendor_ruby/rubygems/exceptions.rb:61:in 
`conflicting_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/exceptions.rb:55:in `initialize'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `exception'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `raise'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `rescue in 
resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:191:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:411:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:423:in 
`resolve_current'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:230:in `finish_resolve'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:287:in `block in 
activate_bin_path'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `activate_bin_path'
from /usr/bin/vagrant:25:in `'
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:317:in
 `raise_error_unless_state': Unable to satisfy the following requirements: 
(Gem::Resolver::Molinillo::VersionConflict)

- `vagrant (= 2.2.19)` required by `user-specified dependency`
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:299:in
 `block in unwind_for_conflict'
from :90:in `tap'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:297:in
 `unwind_for_conflict'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:682:in
 `attempt_to_activate'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:254:in
 `process_topmost_state'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:182:in
 `resolve'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolver.rb:43:in
 `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:190:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:411:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:423:in 
`resolve_current'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:230:in `finish_resolve'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:287:in `block in 
activate_bin_path'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `activate_bin_path'
from /usr/bin/vagrant:25:in `'
`---

Installing ruby3.0 and forcing the «/usr/bin/ruby» symlink back to
ruby3.0 make vagrant work again.

Thanks,
Guillem

Bug#1014136: golang-mongodb-mongo-driver FTBFS due to failing tests

[Guillem Jover]

Control: tag -1 moreinfo unreproducible

On Thu, 2022-06-30 at 13:25:36 -0500, William 'jawn-smith' Wilson wrote:
> Package: golang-mongodb-mongo-driver
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu kinetic ubuntu-patch

> There was already a patch in this package to skip tests that require
> a running mongodb instance. The latest upstream release added more
> tests with this requirement, so I added logic to skip them to the
> already existing patch
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Resolve FTBFS by Skiping more tests that require a running mongodb 
> instance

I have no mongodb running and when building there's no build failure,
so I think I'm not understanding what this is trying to fix? This
definitely does not FTBFS in Debian.

Thanks,
Guillem

Bug#1013876: Please close this bug report for keepassxc-browser to migrate to testing

[Guillem Jover]

On Thu, 2022-11-17 at 13:52:38 +, Amr Ibrahim wrote:
> On Sat, 24 Sep 2022 21:37:45 +0200 Guillem Jover  wrote:
> > I've kept the package on hold since, but try to upgrade from time to
> > time to see whether its fixed. Last time I did with the latest version
> > currently in sid, it seemed to be still broken.
> 
> Is this still broken in Chromium?

Well, nothing has changed in webext-keepassxc-browser since my last
reply, so I'd assume yes. In any case I just upgraded again to check
and, yes it's still broken.

> There is no problem in Firefox, and this bug report is preventing
> the package to migrate to testing

Sure, but that makes it unusable with Chromium which would be a
disservice to those users, so not migrating seems entirely the right
outcome.

Thanks,
Guillem

Bug#1023486: Re: Bug#1023486: Please add loong64 support to dpkg

[Guillem Jover]

On Mon, 2022-11-14 at 18:01:26 +0800, 张丹丹 wrote:
>   > I think the part that was missing, which was asked on the list, and a
>   > rather important part of this! :) Is the ABI this conforms to.
>   > 
>   > I'm attaching a patch that updates the test suite so that it passes,
>   > and adds what I think (but I don't know as I didn't check deeper) might
>   > change the ABI for built objects, which ties into the ABI this
>   > architecture is intended to conform to.
>   > 
>   > I guess the main question is whether objects with these different
>   > EF_LOONGARCH_* flags can be mixed when linking or they are ABI
>   > incompatible, as the code in the patch now assume.
> 
>   1、The value of ELF_FLAGS_LOONGARCH_* flags (you provided) conform to the 
> loongarch ABI standard.
>   2、After confirmation, the following three ELF_FLAG_LOONGARCH_* can not be 
> mixed when linking，Because of different ABIs do not allow linking, otherwise 
> an 
>   error will occur. As follows,
>ELF_FLAG_LOONGARCH_SOFT_FLOAT   => 0x0001,   // soft float
>ELF_FLAG_LOONGARCH_SINGLE_FLOAT => 0x0002,   // single float
>ELF_FLAG_LOONGARCH_DOUBLE_FLOAT => 0x0003,   // double float

I assume anything not matching exactly values within OBJABI_MASK
would not be linkable either. If I'm reading the binutils source
correctly it seems to confirm this, although the comment there reads
to be negated:

/* Disallow linking different ABIs.  */
/* Only check relocation version.
   The obj_v0 is compatible with obj_v1.  */

So shouldn't the latter be s/compatible/incompatible/?

Also is the port going to be ABI v1?

Thanks,
Guillem

Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages

[Guillem Jover]

On Mon, 2022-11-14 at 13:38:30 +0100, Johannes Schauer Marin Rodrigues wrote:
> Quoting Guillem Jover (2022-11-14 13:17:34)
> > On Sun, 2022-11-13 at 11:22:50 +0100, Enrico Zini wrote:
> > > The way I chopped dpkg-checkbuilddeps was a first approximation. Given
> > > that now we have `apt-get satisfy`, my next step would be to have my
> > > hacked version print a list of arguments for it, which can include
> > > "Conflicts:", but which can already be preprocessed to reduce some noise
> > > like packages required or not required from the target architecture.
> > 
> > Ah, so from this I gather that in essence what we need is a way to map
> > from build-dependencies into run-time dependencies, removing/filtering
> > them from anything that is not accepted in the latter. That makes
> > sense and does not seem to have the concerns of the previously filed
> > bug request, as that required performing decisions in a layer too low
> > where that required information was not available.
> > 
> > I could see gathering any build-dependency fields as restricted by
> > (-A/-B/-I), remapping them based on current arch/profile, then
> > outputting them as a pair of Depends/Conflicts fields (perhaps even
> > an Architecture field if there was arch-restrictions applied?). For
> > «apt satisfy» you might need to trim the «Depends: » part though.
> > 
> > Would that work for you? I think it would work for pbuilder.
> > 
> > > More generally, I'd like Debian to have, as a standard, something
> > > similar to `rpmspec --parse filename.spec | grep BuildRequires`
> > > because I see it reimplemented so many times (pbuilder, sbuild, and so
> > > on) that my instincts screams invoking the rule of three and
> > > refactor[2].
> > 
> > I think the above would solve your problem, and potentially could
> > substantially reduce the code in pbuilder-satisfydepends. For sbuild
> > and mk-build-deps (devscripts), which are already in perl, that would
> > only potentially help if this is included as part of a public module.
> > So I'll be going that way in case they want to (eventually) switch.
> 
> As far as I can see, this additional feature will not break anything in 
> sbuild,
> so I think I was CC-ed because the question is whether sbuild can use this? In
> an earlier mail, Enrico writes:

Sorry, probably the phrasing and placement of my reply made this
unclear, with above I meant my previous reply, where I was referring to
adding new code in a module to handle this mapping, the bulk of that
mapping is already being done by deps_parse(), so I was thinking
something a bit more higher-level, but I've not checked the various
implementations (including the ones within dpkg-dev), whether they'd
benefit from something more higher-level than deps_parse().

I'd imagine something taking a source deb822 control stanza from
debian/control or the entire thing, and then mapping
build-dependencies in there into Depends and Conflicts (according to
some selectable criteria or similar).

Thanks,
Guillem

Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages

[Guillem Jover]

Hi!

[ CCing devscripts, pbuilder and sbuild, as this is about some
  potential functionality refactoring. ]

On Sun, 2022-11-13 at 11:22:50 +0100, Enrico Zini wrote:
> On Sat, Nov 12, 2022 at 09:30:43PM +0100, Guillem Jover wrote:
> > There was a bug filed requesting adding custom output format support
> > (#214566) but it was closed “recently”. I think there might be some
> > value in that, but not for the intended use the submitters seemed
> > to want it.
> > 
> > I'd be interested to know how you'd want to use this new output/option
> > as from the PoC script you provide it is not obvious to me, as it
> > prints both build-depends and build-conflicts in an indistinguishable
> > way, and it includes version constraints and alternative dependencies.
> 
> My specific use case at the moment is setting up a container
> *description* (not a container) with all the dependencies I need to do
> development on a package[1].
> 
> I could run apt-get build-dep inside the container and get the
> development environment installed, but then I lose the ability of being
> able to describe it in a terse way, and I can only do something along
> the lines of listing all installed packages in the container and their
> versions, which is too noisy for an average bug report.

Ok, so basing this description on .buildinfo would not seem to be
satisfactory then.

> The way I chopped dpkg-checkbuilddeps was a first approximation. Given
> that now we have `apt-get satisfy`, my next step would be to have my
> hacked version print a list of arguments for it, which can include
> "Conflicts:", but which can already be preprocessed to reduce some noise
> like packages required or not required from the target architecture.

Ah, so from this I gather that in essence what we need is a way to map
from build-dependencies into run-time dependencies, removing/filtering
them from anything that is not accepted in the latter. That makes
sense and does not seem to have the concerns of the previously filed
bug request, as that required performing decisions in a layer too low
where that required information was not available.

I could see gathering any build-dependency fields as restricted by
(-A/-B/-I), remapping them based on current arch/profile, then
outputting them as a pair of Depends/Conflicts fields (perhaps even
an Architecture field if there was arch-restrictions applied?). For
«apt satisfy» you might need to trim the «Depends: » part though.

Would that work for you? I think it would work for pbuilder.

> More generally, I'd like Debian to have, as a standard, something
> similar to `rpmspec --parse filename.spec | grep BuildRequires`
> because I see it reimplemented so many times (pbuilder, sbuild, and so
> on) that my instincts screams invoking the rule of three and
> refactor[2].

I think the above would solve your problem, and potentially could
substantially reduce the code in pbuilder-satisfydepends. For sbuild
and mk-build-deps (devscripts), which are already in perl, that would
only potentially help if this is included as part of a public module.
So I'll be going that way in case they want to (eventually) switch.

I've pondered for a while to add a dpkg-deb822 to parse and manipulate
control data, but perhaps something more specific to source packages
would be helpful too, where people want to query the list of binary
packages to build (dh_listpackages) and similar stuff, but that's for
later. :)

Thanks,
Guillem

Bug#1023870: dpkg: Problems in buildds due to slow compression

[Guillem Jover]

Hi!

On Sun, 2022-11-13 at 00:17:36 +0100, Aurelien Jarno wrote:
> On 2022-11-12 22:28, Guillem Jover wrote:
> > On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo wrote:
> > > Package: dpkg
> > > Version: 1.21.9
> > > Severity: normal
> > > X-Debbugs-Cc: m...@debian.org, debian-wb-t...@lists.debian.org
> > 
> > > After some investigation by aurel32 and myself, this was traced back to 
> > > the
> > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the 
> > > calculation of
> > > the memory that can be used, to determine the number of threads to use, 
> > > was
> > > changed from half of the physical mem to be based on the memory available.
> > 
> > Ah, thanks for tracking this down! I think the problem is the usual
> > "available" memory does not really mean what people think it means. :/
> > And I unfortunately missed that (even thought I was aware of it) when
> > reviewing the patch.
> > 
> > Attached is something I just quickly prepared, which I'll clean up and
> > merge for the upcoming 1.21.10. Let me know if that solves the issue
> > for you, otherwise we'd need to look for further changes.
> 
> Thanks for providing a patch. I have not been able yet to try it for the
> case where we have found the issue, i.e. building linux. However I have
> tried to setup a similar environment:

> - I took a just booted VM with 4 GB RAM, 4 GB swap and 4 GB tmpfs, and very 
> few
>   things running on it.
> - I filled the tmpfs with 4 GB of random data, which means that after
>   moving the content of the tmpfs to the swap, 4 GB could still be used
>   without issue.
> - I ended up with the following /proc/meminfo:
> MemTotal:3951508 kB
> MemFree:  130976 kB
> MemAvailable:  10584 kB
> Buffers:2448 kB
> Cached:  3694676 kB
> SwapCached:12936 kB
> Active:  3111920 kB
> Inactive: 610376 kB
> Active(anon):3102668 kB
> Inactive(anon):   606952 kB
> Active(file):   9252 kB
> Inactive(file): 3424 kB
> Unevictable:   0 kB
> Mlocked:   0 kB
> SwapTotal:   4194300 kB
> SwapFree:3777400 kB
> Zswap: 0 kB
> Zswapped:  0 kB
> Dirty: 0 kB
> Writeback: 0 kB
> AnonPages: 12960 kB
> Mapped: 6700 kB
> Shmem:   3684416 kB
> KReclaimable:  27616 kB
> Slab:  54652 kB
> SReclaimable:  27616 kB
> SUnreclaim:27036 kB
> KernelStack:2496 kB
> PageTables: 1516 kB
> NFS_Unstable:  0 kB
> Bounce:0 kB
> WritebackTmp:  0 kB
> CommitLimit: 6170052 kB
> Committed_AS:4212940 kB
> VmallocTotal:   34359738367 kB
> VmallocUsed:   16116 kB
> VmallocChunk:  0 kB
> Percpu: 2288 kB
> HardwareCorrupted: 0 kB
> AnonHugePages: 0 kB
> ShmemHugePages:0 kB
> ShmemPmdMapped:0 kB
> FileHugePages: 0 kB
> FilePmdMapped: 0 kB
> HugePages_Total:   0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> Hugetlb:   0 kB
> DirectMap4k:  110452 kB
> DirectMap2M: 5132288 kB
> DirectMap1G: 5242880 kB

> With the current version of dpkg, it means it consider 10584 kB are available
> (not however that there is 130976 kB of unused physical RAM). With your patch,
> it's a bit better, as it would be 123408 kB. Still far less that one the VM is
> capable of.

Err sorry, the patch was computing the used memory and not the truly
available one! The updated patch should do better. :)

Thanks,
Guillem
diff --git i/lib/dpkg/compress.c w/lib/dpkg/compress.c
index 8cfba80cc..9b02b48b7 100644
--- i/lib/dpkg/compress.c
+++ w/lib/dpkg/compress.c
@@ -605,8 +605,14 @@ filter_lzma_error(struct io_lzma *io, lzma_ret ret)
  * page cache may be purged, not everything will be reclaimed that might be
  * reclaimed, watermarks are considered.
  */
-static const char str_MemAvailable[] = "MemAvailable";
-static const size_t len_MemAvailable = sizeof(str_MemAvailable) - 1;
+
+struct mem_field {
+	const char *name;
+	ssize_t len;
+	int tag;
+	uint64_t *var;
+};
+#define MEM_FIELD(name, tag, var) name, sizeof(name) - 1, tag, 
 
 static int
 get_avail_mem(uint64_t *val)
@@ -615,6 +621,14 @@ get_avail_mem(uint64_t *val)
 	char *str;
 	ssize_t bytes;
 	int fd;
+	uint64_t mem_free, mem_buffers, mem_cached;
+	struct mem_field fields[] = {
+		{ MEM_FIELD("MemFree", 0x1, mem_free) },
+		{ MEM_FIELD("Buffers", 0x2, mem_buffers) },
+		{ MEM_FIELD("

Bug#1023870: dpkg: Problems in buildds due to slow compression

[Guillem Jover]

Hi!

On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo wrote:
> Package: dpkg
> Version: 1.21.9
> Severity: normal
> X-Debbugs-Cc: m...@debian.org, debian-wb-t...@lists.debian.org

> After some investigation by aurel32 and myself, this was traced back to the
> commit f8d254943051e085040367d689048c00f31514c3 [2], in which the calculation 
> of
> the memory that can be used, to determine the number of threads to use, was
> changed from half of the physical mem to be based on the memory available.

Ah, thanks for tracking this down! I think the problem is the usual
"available" memory does not really mean what people think it means. :/
And I unfortunately missed that (even thought I was aware of it) when
reviewing the patch.

Attached is something I just quickly prepared, which I'll clean up and
merge for the upcoming 1.21.10. Let me know if that solves the issue
for you, otherwise we'd need to look for further changes.

Thanks,
Guillem
diff --git i/lib/dpkg/compress.c w/lib/dpkg/compress.c
index 8cfba80cc..7f9345186 100644
--- i/lib/dpkg/compress.c
+++ w/lib/dpkg/compress.c
@@ -605,8 +605,14 @@ filter_lzma_error(struct io_lzma *io, lzma_ret ret)
  * page cache may be purged, not everything will be reclaimed that might be
  * reclaimed, watermarks are considered.
  */
-static const char str_MemAvailable[] = "MemAvailable";
-static const size_t len_MemAvailable = sizeof(str_MemAvailable) - 1;
+
+struct mem_field {
+	const char *name;
+	ssize_t len;
+	int tag;
+	uint64_t *var;
+};
+#define MEM_FIELD(name, tag, var) name, sizeof(name) - 1, tag, 
 
 static int
 get_avail_mem(uint64_t *val)
@@ -615,6 +621,15 @@ get_avail_mem(uint64_t *val)
 	char *str;
 	ssize_t bytes;
 	int fd;
+	uint64_t mem_total, mem_free, mem_buffers, mem_cached;
+	struct mem_field fields[] = {
+		{ MEM_FIELD("MemTotal", 0x1, mem_total) },
+		{ MEM_FIELD("MemFree", 0x2, mem_free) },
+		{ MEM_FIELD("Buffers", 0x4, mem_buffers) },
+		{ MEM_FIELD("Cached", 0x8, mem_cached) },
+	};
+	const int want_tags = 0xf;
+	int seen_tags = 0;
 
 	*val = 0;
 
@@ -632,14 +647,23 @@ get_avail_mem(uint64_t *val)
 
 	str = buf;
 	while (1) {
+		struct mem_field *field = NULL;
 		char *end;
+		size_t f;
 
 		end = strchr(str, ':');
 		if (end == 0)
 			break;
 
-		if ((end - str) == len_MemAvailable &&
-		strncmp(str, str_MemAvailable, len_MemAvailable) == 0) {
+		for (f = 0; f < array_count(fields); f++) {
+			if ((end - str) == fields[f].len &&
+			strncmp(str, fields[f].name, fields[f].len) == 0) {
+field = [f];
+break;
+			}
+		}
+
+		if (field) {
 			intmax_t num;
 
 			str = end + 1;
@@ -657,16 +681,25 @@ get_avail_mem(uint64_t *val)
 			/* This should not overflow, but just in case. */
 			if (num < (INTMAX_MAX / 1024))
 num *= 1024;
-			*val = num;
-			return 0;
+
+			*field->var = num;
+			seen_tags |= field->tag;
 		}
 
+		if (seen_tags == want_tags)
+			break;
+
 		end = strchr(end + 1, '\n');
 		if (end == 0)
 			break;
 		str = end + 1;
 	}
-	return -1;
+
+	if (seen_tags != want_tags)
+		return -1;
+
+	*val = mem_total - (mem_free + mem_buffers + mem_cached);
+	return 0;
 }
 # else
 static int

Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages

[Guillem Jover]

Control: user d...@packages.debian.org
Control: usertags -1 dpkg-checkbuilddeps
Control: tags -1 moreinfo

Hi!

On Sat, 2022-11-12 at 14:00:38 +0100, Enrico Zini wrote:
> Package: dpkg-dev
> Version: 1.21.9
> Severity: wishlist

> I often find myself[1] in need of a tool that, given a source package,
> prints a list of its build depends, given an architecture, a build
> profile, and so on.

There was a bug filed requesting adding custom output format support
(#214566) but it was closed “recently”. I think there might be some
value in that, but not for the intended use the submitters seemed
to want it.

I'd be interested to know how you'd want to use this new output/option
as from the PoC script you provide it is not obvious to me, as it
prints both build-depends and build-conflicts in an indistinguishable
way, and it includes version constraints and alternative dependencies.

> Would it be possible to add a way to print the unfiltered list?

Anything is possible, I guess my concern is whether this might create
confusion, or whether this is better solved already by some other
tool? Or if there is no workable alternative, finding the right
semantics to add this.

> Ideally, it can become a --print-depends/--print-conflicts option to
> dpkg-checkbuilddeps, instead of a separate tool. Unfortunately my
> perl-foo is too rusty to pretend I could propose a competent patch :/

I don't mind implementing it at all, but I'd like to understand what
this is needed for. :)

Thanks,
Guillem

Bug#1023882: git: Add a way to disable «git clean» per repo

[Guillem Jover]

Package: git
Version: 1:2.38.1-1
Severity: wishlist
Tags: upstream

Hi!

[ Filing this here, because it seems upstream "tracks" bug reports
  from the mailing list!? So to avoid this potentially getting lost…
  And it's not clear whether that also applies to wishlist or just
  regressions and actual bugs. ]

For repositories that are not tracking code, say when storing your ~/
under git, or to store say collections of data files such as photos,
texts or similar, you might end up using .gitignore to unclutter
«git status». The problem is that both ignored and non-ignored
untracked files can be “precious”, as in not version-tracked by losing
them might imply data loss.

Accidentally running «git clean -xdf» or «git clean -Xdf» might be
catastrophic there. But for the ~/ case (or any such tracking in a
parent of git trees, this is even worse, as an accidental «cd» too
much might end up accidentally recursively running those «git clean»
on an unexpected working tree and all of its subdirectories (except
for other git working trees).

I tend to be rather careful with this, but I recently had a scare
where this happened to me, and lost a few (not essential) files before
I noticed and Ctrl-C'd git. I then set out to try to disable git clean
on these situations, but I see no way to do that as aliases do not work
with built-ins, and adding a ~/bin/git wrapper to check for this seems
extremely cumbersome.

It would thus be nice if there was an option that could be set to
completely disable «git clean» on a repo. I guess it might make sense
to disable for any untracked file, or perhaps for ignored and/or
non-ignored. So that these kind of work trees could be protected.

Thanks,
Guillem

Bug#1023486: Please add loong64 support to dpkg

[Guillem Jover]

Hi!

On Sat, 2022-11-05 at 18:08:03 +0800, 张丹丹 wrote:
> Package: dpkg
> Version: 1.21.10
> Severity: wishlist
> Tags: patch
> User: debian-de...@lists.debian.org
> Usertags: loongarch64

> According to the result of disscussion from 
> debian-d...@lists.debian.org(https://lists.debian.org/debian-dpkg/2022/11/msg1.html),
>  guil...@debian.org, hel...@subdivi.de, *@loongson.cn and so on.
> Dpkg architecture of loong64 just determine the name of the software packages.
> Should add loong64 architecture to dpkg package?
> 
> - Add support for loongarch64 CPU.
> Here is a simple patch to dpkg for the loongarch64.
> Please download from attachment.
> 
> - Have an official GNU triplet in the GNU config project. 
> https://git.savannah.gnu.org/cgit/config.git/commit/?id=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f
> 
> - GNU binutils, gcc, and the respective libc project have merged by upstream.
> Binutils: 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch
> Gcc: https://gcc.gnu.org/gcc-12/changes.html
> Glibc: https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html
> 
> 
> - Please tell me if I've missed something.

I think the part that was missing, which was asked on the list, and a
rather important part of this! :) Is the ABI this conforms to.

I'm attaching a patch that updates the test suite so that it passes,
and adds what I think (but I don't know as I didn't check deeper) might
change the ABI for built objects, which ties into the ABI this
architecture is intended to conform to.

I guess the main question is whether objects with these different
EF_LOONGARCH_* flags can be mixed when linking or they are ABI
incompatible, as the code in the patch now assume.

Thanks,
Guillem
From bd0462298d5cf833ab47b0124ca470d0e156d902 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 11 Nov 2022 12:43:38 +0100
Subject: [PATCH] arch: Add support for loong64 CPU
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is based on the LoongArch 64-bit little-endian hard-float ISA.

Closes: #1023486
Based-on-patch-by: 张丹丹 
---
 data/cputable  | 1 +
 scripts/Dpkg/Shlibs/Objdump.pm | 9 +
 scripts/t/Dpkg_Arch.t  | 4 ++--
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/data/cputable b/data/cputable
index 172cea3f5..7b1ee2c58 100644
--- a/data/cputable
+++ b/data/cputable
@@ -26,6 +26,7 @@ arm		arm		arm.*			32	little
 arm64		aarch64		aarch64			64	little
 avr32		avr32		avr32			32	big
 hppa		hppa		hppa.*			32	big
+loong64		loongarch64	loongarch64		64	little
 i386		i686		(i[34567]86|pentium)	32	little
 ia64		ia64		ia64			64	little
 m32r		m32r		m32r			32	big
diff --git a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm
index baeb8bb5c..9deedb4b4 100644
--- a/scripts/Dpkg/Shlibs/Objdump.pm
+++ b/scripts/Dpkg/Shlibs/Objdump.pm
@@ -101,6 +101,7 @@ use constant {
 ELF_MACH_XTENSA => 94,
 ELF_MACH_MICROBLAZE => 189,
 ELF_MACH_ARCV2  => 195,
+ELF_MACH_LOONGARCH  => 258,
 ELF_MACH_AVR_OLD=> 0x1057,
 ELF_MACH_OR1K_OLD   => 0x8472,
 ELF_MACH_ALPHA  => 0x9026,
@@ -125,6 +126,13 @@ use constant {
 
 ELF_FLAG_IA64_ABI64 => 0x0010,
 
+ELF_FLAG_LOONGARCH_SOFT_FLOAT   => 0x0001,
+ELF_FLAG_LOONGARCH_SINGLE_FLOAT => 0x0002,
+ELF_FLAG_LOONGARCH_DOUBLE_FLOAT => 0x0003,
+ELF_FLAG_LOONGARCH_ABI_MASK => 0x0007,
+ELF_FLAG_LOONGARCH_OBJABI_V1=> 0x0040,
+ELF_FLAG_LOONGARCH_OBJABI_MASK  => 0x00c0,
+
 ELF_FLAG_MIPS_ABI2  => 0x0020,
 ELF_FLAG_MIPS_32BIT => 0x0100,
 ELF_FLAG_MIPS_FP64  => 0x0200,
@@ -158,6 +166,7 @@ my %elf_mach_map = (
 # behavior, and we do not drop dependencies.
 my %elf_flags_mask = (
 ELF_MACH_IA64() => ELF_FLAG_IA64_ABI64,
+ELF_MACH_LOONGARCH() => ELF_FLAG_LOONGARCH_ABI_MASK | ELF_FLAG_LOONGARCH_OBJABI_MASK,
 ELF_MACH_MIPS() => ELF_FLAG_MIPS_ABI_MASK | ELF_FLAG_MIPS_ABI2,
 ELF_MACH_PPC64()=> ELF_FLAG_PPC64_ABI64,
 );
diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index 012f67c63..59855dfa4 100644
--- a/scripts/t/Dpkg_Arch.t
+++ b/scripts/t/Dpkg_Arch.t
@@ -16,7 +16,7 @@
 use strict;
 use warnings;
 
-use Test::More tests => 18407;
+use Test::More tests => 18900;
 
 use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
 debarch_eq debarch_is debarch_is_wildcard
@@ -28,7 +28,7 @@ use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
 get_host_gnu_type
 get_valid_arches));
 
-my $KNOWN_ARCHES_TOTAL = 554;
+my $KNOWN_ARCHES_TOTAL = 569;
 my @valid_arches = get_valid_arches();
 
 sub get_valid_wildcards
-- 
2.38.1

Bug#1023753: dpkg-buildpackage: Asking for a very early hook ("preinit")

[Guillem Jover]

Control: reassign -1 dpkg-dev
User: d...@packages.debian.org
Usertags: dpkg-buildpackage

Hi!

On Wed, 2022-11-09 at 16:29:26 +0100, Christoph Biedl wrote:
> Package: dpkg
> Version: 1.21.9+b1
> Severity: wishlist

> in some (admittedly unusual) scenarios, I'd like to hook
> dpkg-buildpackage way earlier then via the "init" hook. More precisely,
> I'd like to run a hook *before* debian/changelog and debian/control are
> inspected.

I'd be interested to know about those scenarios (or abstract descriptions
of them), to be able to understand the required semantics for this, or
whether there are other alternatives?

> Implementing this (I called the hook "preinit") was rather trivial,
> would you consider including this in dpkg? That would take the burden of
> carrying that patch locally from me. There's one thing worth to mention
> in any documentation: The substitutions are not supported there as the
> accordingly variables are not defined yet at that time.

Yeah, I think this seems fine, but as mentioned above I'd like to
understand what are the proposed semantics, so that the code makes
sense, and potential new code can preserve those semantics.

Thanks,
Guillem

Bug#1023562: dpkg-buildflags: hardening: add stack clash protection

[Guillem Jover]

Control: forcemerge 918914 -1

Hi!

On Sun, 2022-11-06 at 19:23:21 +0100, Christian Göttsche wrote:
> Package: dpkg-dev
> Version: 1.21.9
> Tags: security

> Please consider to add stack clash protection to the hardening
> options. The related flag, `-fstack-clash-protection`, is supported by
> GCC since version 8 and Clang since version 10 (x86 only).
> More details on the functionality iself:
> https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc-part-3
> https://blog.llvm.org/posts/2021-01-05-stack-clash-protection/

This was already filed, but there were some concerns and no one drove
this per the usual procedure to enable new flags. Merging.

Thanks,
Guillem

Bug#1023824: crmsh: WARNING: crmadmin -S unexpected output

[Guillem Jover]

Package: crmsh
Version: 4.4.0-2
Severity: important
Tags: upstream patch
Forwarded: https://github.com/ClusterLabs/crmsh/issues/970

Hi!

The output from pacemaker changed from what crmsh expects, which makes
certain commands now fail (in addition to causing WARNING and INFO output).

This is affecting us on our HA setup.

The (merged) upstream commit fixing this is
,
which I'm attaching here for your convenience.

Thanks,
Guillem
From f83aa41185dbc71a25a3def39d42356e503b1f96 Mon Sep 17 00:00:00 2001
From: liangxin1300 
Date: Wed, 11 May 2022 11:09:28 +0800
Subject: [PATCH] Fix: utils: wait4dc: Make change since output of 'crmadmin
 -S' changed(bsc#1199412)

---
 crmsh/utils.py | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/crmsh/utils.py b/crmsh/utils.py
index 9f2603a1..9ebce28f 100644
--- a/crmsh/utils.py
+++ b/crmsh/utils.py
@@ -895,15 +895,10 @@ def wait4dc(what="", show_progress=True):
 return False
 cmd = "crmadmin -S %s" % dc
 rc, s = get_stdout(add_sudo(cmd))
-if not s.startswith("Status"):
-logger.warning("%s unexpected output: %s (exit code: %d)", cmd, s, rc)
-return False
-try:
-dc_status = s.split()[-2]
-except:
-logger.warning("%s unexpected output: %s", cmd, s)
+if rc != 0:
+logger.error("Exit code of command {} is {}".format(cmd, rc))
 return False
-if dc_status == "S_IDLE":
+if re.search("S_IDLE.*ok", s):
 if output_started:
 sys.stderr.write(" done\n")
 return True
-- 
2.38.1

Bug#1023654: liburing 2.3 breaks binary compatibility

[Guillem Jover]

Hi!

I've forwarded this upstream now.

On Tue, 2022-11-08 at 14:44:25 +0100, Guillem Jover wrote:
> On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote:
> > On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev  wrote:
> > > In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
> > > their sizes. Both of these structures are parts of io_uring structure
> > > which the main part of the API.  Here's the difference:
> > > 
> > > @@ -43,7 +79,9 @@
> > > @@ -56,13 +94,18 @@
> > > size_t ring_sz;
> > > void *ring_ptr;
> > > -   unsigned pad[4];
> > > +   unsigned ring_mask;
> > > +   unsigned ring_entries;
> > > +
> > > +   unsigned pad[2];
> > 
> > This does not look like it is changing the size actually, - I haven't
> > noticed it adjusts pad[] accordingly. So this is not the issue here.
> > 
> > But the end result is the same: samba compiled with liburing 2.2 does
> > not work with runtime liburing 2.3, and samba compiled with liburing
> > 2.3 does not work with runtime liburing 2.2.

I've checked the code and this is weird, the new code is taking care of
initializing all members with the new shared library. So I'd expect
samba built against the old liburing to work with the new one. But the
problem seems to be that code built against the new liburing will not
work with the old liburing, as that one does not initialize the new
members being used from the inline functions.

If you are really seeing samba linked against old liburing not working
with the new liburing, then we'd need to dig further to see what else
might be missing, but I'm currently not seeing it just by a very quick
code staring.

Thanks,
Guillem

Bug#1023654: liburing 2.3 breaks binary compatibility

[Guillem Jover]

Hi!

On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote:
> On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev  wrote:
> > Source: liburing
> > Version: 2.3-1
> > Severity: grave
> > 
> > liburing 2.3 broke binary compatibility without bumping the soname.

Indeed. :/ Should make a habit of checking the header diffs, as this
is not the first time this has happened.

> > In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
> > their sizes. Both of these structures are parts of io_uring structure
> > which the main part of the API.  Here's the difference:
> > 
> > @@ -43,7 +79,9 @@
> > @@ -56,13 +94,18 @@
> > size_t ring_sz;
> > void *ring_ptr;
> > -   unsigned pad[4];
> > +   unsigned ring_mask;
> > +   unsigned ring_entries;
> > +
> > +   unsigned pad[2];
> 
> This does not look like it is changing the size actually, - I haven't
> noticed it adjusts pad[] accordingly. So this is not the issue here.
> 
> But the end result is the same: samba compiled with liburing 2.2 does
> not work with runtime liburing 2.3, and samba compiled with liburing
> 2.3 does not work with runtime liburing 2.2.
> 
> I'm just too tired now to dig further.

The problem is that this release has deprecated the kring_mask and
kring_entries, and does not have fallback code to use them if they are
being used by the callers.

I'll report this upstream to see how they want to fix this, either
with a SOVERSION bump or trying to add dynamic fallback code or
similar.

For sid, I guess I could bump the affected functions required minimal
versions in the symbols file, and then add breaks on the old packages
using the old ABI, but meh. :/

Thanks,
Guillem

Bug#1022766: dpkg-shlibdeps: repeatedly emits duplicate warnings

[Guillem Jover]

Hi!

On Tue, 2022-10-25 at 14:23:18 +0200, Andreas Beckmann wrote:
> Package: dpkg-dev
> Version: 1.21.9
> Severity: normal

> While checking the nvida-cuda-toolkit buildd logs [1], I came across a
> long sequence of repeated error messages:
> 
> pkg-shlibdeps: warning: can't extract name and version from library name 
> 'libfoobar.so'
> 
> There are about 40 repetitions of this warning (with no further messages
> interleaved) for most of the libraries, but I don't know what this
> number corresponds to.
> Since nvida-cuda-toolkit just repacks upstream binary libraries we
> unfortunately have to cope with a lot of libraries without proper sonames.

> [1] https://buildd.debian.org/status/package.php?p=nvidia-cuda-toolkit

Ah, I guess something like the attached patch might do? In addition to
somewhat improving performance. :)

Thanks,
Guillem
From 12e690ec338d7ba2e808ae7f6ba7c31e060b0e8e Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 25 Oct 2022 18:36:16 +0200
Subject: [PATCH] dpkg-shlibdeps: Cache soname check against shlibs files

Closes: #1022766
---
 scripts/dpkg-shlibdeps.pl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/dpkg-shlibdeps.pl b/scripts/dpkg-shlibdeps.pl
index 6c8a2d3ab..47e79ca13 100755
--- a/scripts/dpkg-shlibdeps.pl
+++ b/scripts/dpkg-shlibdeps.pl
@@ -172,7 +172,8 @@ my %global_soname_notfound;
 my %global_soname_used;
 my %global_soname_needed;
 
-# Symfile and objdump caches
+# Shlibs, Symfile and objdump caches
+my %shlibs_cache;
 my %symfile_cache;
 my %objdump_cache;
 my %symfile_has_soname_cache;
@@ -721,6 +722,10 @@ sub split_soname {
 sub extract_from_shlibs {
 my ($soname, $shlibfile) = @_;
 
+if (exists $shlibs_cache{$shlibfile}{$soname}) {
+return $shlibs_cache{$shlibfile}{$soname};
+}
+
 my $shlibs_re = qr{
 ^\s*
 (?:(\S+):\s+)?  # Optional type
@@ -738,6 +743,7 @@ sub extract_from_shlibs {
 unless (defined $libname) {
 	warning(g_("can't extract name and version from library name '%s'"),
 	$soname);
+$shlibs_cache{$shlibfile}{$soname} = undef;
 	return;
 }
 # Open shlibs file
@@ -769,6 +775,7 @@ sub extract_from_shlibs {
 	}
 }
 close($shlibs_fh);
+$shlibs_cache{$shlibfile}{$soname} = $dep;
 return $dep;
 }
 
-- 
2.37.2

Bug#712939: control messages ugly: cont.

[Guillem Jover]

Hi!

On Thu, 2014-02-06 at 03:11:50 +0100, Guillem Jover wrote:
> On Sat, 2014-02-01 at 15:35:21 +0100, Mathieu Parent wrote:
> > Control: tag -1 + wontfix
> 
> > I can confirm that this is still the case.
> > 
> > Example:
> > http://packages.qa.debian.org/p/php-horde-activesync/news/20140129T212127Z.html
> > 
> >  php-horde-activesync - ${phppear:summary}
> > 
> > Guillem: Was it a different reason that #659814 (my guess is still #5210)?
> 
> Ah, yeah sorry, I guess I did not pay enough attention to this bug's
> details. But I think these substvars make some sense, so I'll ponder
> about the possibility of supporting this in dpkg-genchanges.

BTW, if I've reloaded the context correctly for this, substvars for
Description fields for .changes files are supported since dpkg 1.19.0,
so I guess the wontfix can be removed from here, and handled in
whatever way needed?

Thanks,
Guillem

Bug#931402: could not leave editor on examining a config file conflict

[Guillem Jover]

Control: reassign -1 apt

[ Adding some context. ]

On Thu, 2019-07-04 at 10:05:31 +0200, Harald Dunkel wrote:
> Package: dpkg
> Version: 1.18.25

> On the upgrade from Stretch to Buster there was a config
> file conflict (with /etc/issue, but that doesn't matter).
> dpkg allowed me to examine the conflict ("Z"). I could
> adjust the old file using the mg editor, I could save the
> config file using Ctrl-X Ctrl-S, but I could not leave mg
> using Ctrl-X Ctrl-C. The Ctrl-C did not work.
> 
> AFAICT dpkg's "Z" session should set the terminal back to a
> reasonable state before starting a new shell.

On Sun, 2021-02-28 at 10:06:30 -0800, Norman Rasmussen wrote:
> Package: dpkg
> Version: 1.20.7.1
> Followup-For: Bug #931402

> I can reproduce this in just the shell that's started. Ctrl-C doesn't
> seem to have any immediate effect. However once the shell is exited, the
> Ctrl-C causes dpkg to terminate early.
> 
> I suspect that dpkg isn't creating a new foreground process group, so
> the SIGINT from Ctrl-C is being delivered to dpkg instead of the shell
> (or relevant sub-process like the editor).
> 
> Adding a setsid or setpgid call somewhere in spawn_shell and/or
> show_diff would probably fix it.

So AFAICT, the problem seems to be with apt? It sets the process dpkg
is running on as session leader (setsid()), and sets the terminal as the
controlling terminal of that process in pkgDPkgPM::SetupSlavePtyMagic().

Then in pkgDPkgPM::Go() it has the following:

  /* Mask off sig int/quit. We do this because dpkg also does when
 it forks scripts. What happens is that when you hit ctrl-c it sends
 it to all processes in the group. Since dpkg ignores the signal
 it doesn't die but we do! So we must also ignore it */
  sighandler_t old_SIGQUIT = signal(SIGQUIT,SIG_IGN);
  sighandler_t old_SIGINT = signal(SIGINT,SigINT);

The code ignoring these signals is very very old, and the setsid() and
TIOCSCTTY ioctl() are more recent, which I think would have made the
former signal ignoring code irrelevant now.

I've only tested this in dpkg (w/o apt involved it works fine), and I
don't think this can be fixed sanely in dpkg, as I'd need to make dpkg
steal the controlling terminal, and force the signal disposition,
which the caller might have set for some reason, etc. But I think
getting rid of those SIG_IGN sets in apt might fix the issue at hand?

If I've misread the situation, I'm happy to fix dpkg if there's a sane
way to do that though.

Thanks,
Guillem

Bug#985749: apt: "apt-mark hold" flag lost on package upgrade using --ignore-hold

[Guillem Jover]

Control: reassign -1 apt

Hi!

On Tue, 2021-03-23 at 00:06:21 +0100, Sven-Haegar Koch wrote:
> On Mon, 22 Mar 2021, David Kalnischkies wrote:
> > On Mon, Mar 22, 2021 at 10:21:59PM +0100, Sven-Haegar Koch wrote:
> > > I hold the package, and with normal upgrade/dist-upgrade it works
> > > exactly as expected.
> > > 
> > > But when I then upgrade these single package later using --ignore-hold,
> > > the hold flag is lost afterwards.
> > 
> > holds are stored by dpkg as a "selection state", which e.g. install or
> > deinstall are, too, and which will override the old selection state sort
> > of by design.
> > 
> > It is also this way since the dawn of time, so that is kinda unlikely to
> > change – resolving this bug might be as "simple" as adding a note that
> > holds will be (potentially) lost if they are ignored.
> > 
> > Sorry, as that is probably not what you wanted to hear.
> 
> Thanks.
> 
> I think a note in the apt-get manpage on the options (--ignore-hold and 
> --allow-change-held-packages) would already have helped me a lot - it 
> took very long to figure out that my problem was indeed loosing the 
> mark after upgrading the package - as usually the availability of the 
> next version of a marked package happens weeks or months later.
> 
> And when you discover the mark missing on a dist-upgrade call then, you 
> mostly think "I thought I set it, did I really also on this server?" :)
> 
> Never even got the idea that the hold would not be supposed to 
> survive, neither from apt-get nor from apt-mark manpages.

In dpkg this got clarified with bug #926472, I've just pushed a commit
to dpkg git HEAD to further clarify a confusing wording in the man page
for the --force-hold description, but otherwise I think the stuff in
the «Packages selection states» subsection should be clear enough
already.

Given that you request improvements to the apt documentation, I'm
reassigning back.

Thanks,
Guillem

Bug#932988: dpkg-gensymbols: Please add a option to set the Build-Depends-Package field

[Guillem Jover]

Control: user d...@packages.debian.org
Control: usertags -1 dpkg-gensymbols
Control: tag -1 moreinfo

On Thu, 2019-07-25 at 16:59:14 +0200, Jörg Frings-Fürst wrote:
> Package: dpkg-dev
> Version: 1.19.7
> Severity: wishlist
> 
> please add a option to set the Build-Depends-Package meta-information
> field.

This field is supposed to be written into the .symbols file by the
packager. I'm not sure I understand what's being requested here, could
you clarify?

Thanks,
Guillem

Bug#977862: support systems without lchown, perhaps with Gnulib

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Mon, 2021-08-23 at 22:51:25 +0200, Guillem Jover wrote:
> So, while I'm truly interested in improving portability for dpkg, I'm
> not sure (as in, I've not kept up with times) whether MinGW might be a
> valid target at all? Also AFAIR there's still the problem with its
> GNU system name not being ready to be merged in dpkg.
>·
> dpkg does still make use of fork+exec constructs, which AFAIR were
> problematic on Windows-based systems, and while I'm slowly getting rid
> of them, this is still the case.
>·
> Then there's the dpkg requirements on filesystems
> <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_the_filesystem_requirements_by_dpkg.3F>.
>·
>·
> If lchown() is really the only thing stopping dpkg to be buildable and
> runnable there, I'm happy to consider options here. I think Windows
> gained better symlink support "recently", wouldn't adding lchown()
> support to MinGW be a better option here? But otherwise if there's a
> possibility to add a non-stub version of the function I'd be happy to
> take a patch for it. :)

So given the above, if there's no further input, I think I'll be
closing this in a bit, as this could always be reconsidered once the
arch name situation is solved or a better alternative exists.

Thanks,
Guillem

Bug#1020533: dpkg should use /var/lib/dpkg/arch to determine native arch when running chrootless

[Guillem Jover]

Control: retitle 825385 "dpkg: Does not know the native arch for another db"
Control: forcemerge 825385 -1

Hi!

On Thu, 2022-09-22 at 22:13:34 +0200, Johannes Schauer Marin Rodrigues wrote:
> Package: dpkg
> Version: 1.21.8
> Severity: normal
> X-Debbugs-Cc: jo...@debian.org

> steps to reproduce on amd64:
> 
> #!/bin/sh
> set -exu
> mkdir -p dpkgroot/var/lib/dpkg
> echo "arm64" > dpkgroot/var/lib/dpkg/arch
> cat << 'END' > dpkgroot/var/lib/dpkg/status
> Package: perl-base
> Status: install ok installed
> Architecture: arm64
> Version: 1
> END
> mkdir -p pkg/DEBIAN
> cat << 'END' > pkg/DEBIAN/control
> Package: perl-modules-5.34
> Version: 1
> Architecture: all
> Depends: perl-base
> END
> dpkg-deb --build pkg pkg.deb
> PATH=/usr/sbin:/usr/bin:/sbin:/bin dpkg \
>   --log=/dev/null \
>   --force-not-root \
>   --force-script-chrootless \
>   --root=dpkgroot \
>   --install pkg.deb
> 
> result:
> 
> Preparing to unpack pkg.deb ...
> Unpacking perl-modules-5.34 (1) ...
> dpkg: dependency problems prevent configuration of perl-modules-5.34:
>  perl-modules-5.34 depends on perl-base.
> dpkg: error processing package perl-modules-5.34 (--install):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  perl-modules-5.34
> 
> If one changes "Architecture: arm64" to "Architecture: amd64" (the
> architecture of my native dpkg) it works.
> 
> Maybe the prolbem is, that dpkg treats perl-modules-5.34 (it being
> arch:all) implicitly as the native arch which is (wrongly) chosen to be
> amd64 instead of arm64. And in that case, perl-base:arm64 cannot satisfy
> its dependency.

As mentioned on IRC, the problem here (and on #825385) is indeed that
dpkg considers its own arch the native one, and when operating on a
cross-arch chroot, that goes wrong, both in dependency resolution
and when outputting arch-qualified package names for example.

Fixing this properly is tricky though, because there are multiple
requirements in tension here:

  * The external dpkg should be able to tell what's the arch for the
internal one w/o having to execute anything (that it might not be
able to run anyway).
  * Setting a file on the database means either requiring a dpkg
maintscript (for the bootstrap phase) which we are trying to get
rid of, or offloading this to the bootstrappers (even worse), it
also means it could be modified w/o dpkg noticing, which can break
dependency resolution from an existing system.
  * Shipping a file with the arch would seem like the best option (as
that is checksummed) and not in the db, but that means then, that
pathname under /usr needs to be selectable too at run-time, as
that encodes configure-time vendor-specific fsys layout.
  * Setting that directory from the config file is currently
problematic as dpkg does not have a way to specify a different
config directory.
  * Perhaps just adding a new --foodir option to dpkg could be enough
for now, if the inner dpkg uses a different pathname, in the
same way if it uses a different database pathname.
  * But then only specifying the db pathname would no longer be
enough, and dependency resolution and arch-qualifying would still
be wrong. :/
  * But then if the file does not exist (or cannot be found in the
«right» place) it could still fallback to the currently running
native arch, but that looks flaky (not worse than now, though,
but not ideal). :/

I guess I can prototype something with the --foodir idea though, but
that's still rather meh.

Thanks,
Guillem

Bug#873138: Installed-Build-Depends lack architecture qualification

[Guillem Jover]

Hi!

On Sat, 2022-09-24 at 23:58:28 +0200, Helmut Grohne wrote:
> On Thu, Aug 24, 2017 at 09:45:39PM +0200, Helmut Grohne wrote:
> > while looking into a .buildinfo file, I noticed that
> > Installed-Build-Depends are useless beyond #871494: They lack
> > architecture qualification. Thus there is no way to figure out for which
> > architecture to install which package. The installation set cannot be
> > reproduced.
> > 
> > I believe that a good solution here would be to simply arch qualify
> > every package and then drop all :$DEB_BUILD_ARCH qualifications. For
> > native builds there won't be a difference. For cross builds, the field
> > becomes useful. I am proposing DEB_BUILD_ARCH rather than DEB_HOST_ARCH
> > here, because essential will always be installed for the build
> > architecture and thus poses significant chunk of packages.
> 
> I've implemented the proposed solution and seek review from both cross
> and reproducible folks. You'll find a patch attached.

I recalled that we had discussed dpkg-genbuildinfo having broken
dependency handling some time ago on IRC, and that Johannes (CCed) had
provided a patch, initially thought on the mailing list or a bug, and
it looks like that was provided over a paste on IRC (around 2017-01),
but that was during the freeze, so it seems like I only merged/fixes
the most impactful and non-invasive fixes at the time, and I guess then
I lost track of the rest, as I only saved it in a file and not a branch
or report, sorry about that. :/

In any case I'm attaching it here, I've started to split it into atomic
pieces and update on top of git HEAD, and once the obvious stuff has been
merged will then compare any remaining part against the one provided by
Helmut.

Thanks,
Guillem
From 62529c0b35880058c714f2b90cc050ad9db831d5 Mon Sep 17 00:00:00 2001
From: Johannes 'josch' Schauer 
Date: Thu, 26 Jan 2017 10:52:48 +0100
Subject: [PATCH] Fix multiarch handling of dpkg-checkbuilddeps and
 dpkg-genbuildinfo

Problems with dpkg-genbuildinfo:

 - ignores Pre-Depends
 - no architecture reduction for build dependencies
 - dropping of version restrictions of build dependencies
 - not adding explicit architecture qualifier for packages that are not
   of the host architecture
 - no handling of :native and :any architecture qualifiers
 - allowing the :all architecture qualifier
 - ignoring Multi-Arch:foreign and Multi-Arch:allowed

Problems with dpkg-checkbuilddeps:

 - ignores multiarch constraints on virtual packages
 - build dependencies without architecture qualifier are satisfied by
   Architecture:all packages

These problems were solved by:

 - extending Dpkg::Deps::KnownFacts to handle more than build dependency
   resolution
 * let functions return lists of packages instead of booleans
 * special-case dependencies of type build_dep
 o respect the host architecture instead of the binary package
   architecture
 o allow :native
 * Architecture:all packages are now of the build architecture
 * respect multiarch constraints for providers of virtual packages
 - extending Dpkg::Deps::Simple with a function who_provides returning
   all installed real providers of a dependency
 * let get_evaluation be a wrapper around who_provides
 - extending Dpkg::Deps::Simple with a member storing the binary package
   architecture that the dependency originates from to allow propagation
   of the architecture in a multiarch scenario
 - letting dpkg-genbuildinfo use who_provides for dependency resolution
---
 scripts/Dpkg/Deps.pm | 181 ---
 scripts/dpkg-genbuildinfo.pl | 148 ---
 scripts/t/Dpkg_Deps.t|  36 +++--
 3 files changed, 247 insertions(+), 118 deletions(-)

diff --git a/scripts/Dpkg/Deps.pm b/scripts/Dpkg/Deps.pm
index 56f7b2826..dbe65f75f 100644
--- a/scripts/Dpkg/Deps.pm
+++ b/scripts/Dpkg/Deps.pm
@@ -238,6 +238,11 @@ this when parsing non-dependency fields like Conflicts.
 If set to 1, allow build-dep only arch qualifiers, that is “:native”.
 This should be set whenever working with build-deps.
 
+=item architecture (defaults to undef)
+
+The architecture of the binary package that this dependency is from. This will
+be stored in the returned Dpkg::Deps::Simple objects.
+
 =item tests_dep (defaults to 0)
 
 If set to 1, allow tests-specific package names in dependencies, that is
@@ -268,6 +273,7 @@ sub deps_parse {
 $options{union} //= 0;
 $options{build_dep} //= 0;
 $options{tests_dep} //= 0;
+$options{architecture} //= get_build_arch();
 
 if ($options{reduce_restrictions}) {
 $options{reduce_arch} = 1;
@@ -280,6 +286,7 @@ sub deps_parse {
 build_arch => $options{build_arch},
 build_dep => $options{build_dep},
 tests_dep => $options{tests_dep},
+	architecture => $options{architecture},
 );
 
 # Strip trailing/leading spaces
@@ -491,6 +498,16 @@ Dpkg::Deps::KnownFacts object given as 

Bug#1021292: dpkg-dev: Please add support for pointer authentication on arm64

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Wed, 2022-10-05 at 03:46:06 +0100, Wookey wrote:
> Package: dpkg-dev
> Version: 1.19.7
> Severity: wishlist
> Tags: patch

> As discussed in the below-linked thread on dpkg-dev, we should enable
> PAC and BTI on arm64 as a standard hardening flag.
> https://lists.debian.org/debian-dpkg/2022/05/msg00022.html
> 
> Attached is Guillem's proposed patch which does the trick, updated for
> current dpkg (I opened this bug file in June, but forgot to actually
> press send, so now updated for the current 1.21.9)

Yes, I've had this locally as a branch since then:

  


:)

> Despite this delay, I hope we can can have this in for bookworm.

As mentioned on the thread, I was expecting a thread to be started on
debian-devel, as this changes the current default for both amd64 and
arm64. As mentioned on the thread on d-dpkg, we can always detangle
the arch support and postpone either if they seem controversial. So,
if you could start that discussion, that would be great. If there is
pushbach, then I guess this would not be currently mergeable as-is,
even disabled by default. But then we could entertain what I've
recently mentioned elsewhere about versioning the features surface
and the “all” selector in particular to be able to add it anyway (at
least disabled though).

Thanks,
Guillem

Bug#1020698: O: dlocate -- fast alternative to dpkg -L and dpkg -S

[Guillem Jover]

Hi!

[ Sorry, should have CCed Craig, doing that now. ]

On Fri, 2022-09-30 at 04:07:05 +0200, Guillem Jover wrote:
> Hi!
> 
> On Sun, 2022-09-25 at 16:19:08 +0200, Tobias Frost wrote:
> > Package: wnpp
> > 
> > The current maintainer of dlocate, Craig Sanders ,
> > is no longer maintaining this packages.
> > 
> > Maintaining a package requires time and skills. Please only adopt this
> > package if you will have enough time and attention to work on it.
> > 
> > If you want to be the new maintainer, please see
> > https://www.debian.org/devel/wnpp/#howto-o for detailed
> > instructions how to adopt a package properly.
> 
> Hmm, if this is really unmaintained now, although given that this is a
> native package it is not clear to me, then given the relationship and
> namespace usage, I think this would fit nicely within the dpkg suite.
> So I'm willing to take this one if so.

Just to clarify, I'd would only ever consider taking this on, if the
upstream status is also really "unmaintained".

Thanks,
Guillem

Bug#1021156: calamares-settings-debian: Confusing/generic program names

[Guillem Jover]

Package: calamares-settings-debian
Version: 12.0.3-1
Severity: normal

Hi!

I just noticed that this package provides a dpkg-unsafe-io script,
which creates a calamares specific config file for dpkg. Looking
further I noticed the other installed program have concerningly
generic names such as "install-debian", "bootloader-config",
"sources-final" and "sources-media". I guess the same applies to the
desktop file "install-debian.desktop".

Do all of these need to be installed on the PATH? If they are internal
implementation details perhaps they could instead be installed under a
/usr/share/ directory? Otherwise could these be namespaced to denote
they are calamares specific?

Thanks,
Guillem

Bug#1020698: O: dlocate -- fast alternative to dpkg -L and dpkg -S

[Guillem Jover]

Hi!

On Sun, 2022-09-25 at 16:19:08 +0200, Tobias Frost wrote:
> Package: wnpp
> 
> The current maintainer of dlocate, Craig Sanders ,
> is no longer maintaining this packages.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
> 
> If you want to be the new maintainer, please see
> https://www.debian.org/devel/wnpp/#howto-o for detailed
> instructions how to adopt a package properly.

Hmm, if this is really unmaintained now, although given that this is a
native package it is not clear to me, then given the relationship and
namespace usage, I think this would fit nicely within the dpkg suite.
So I'm willing to take this one if so.

Thanks,
Guillem

Bug#892664: dpkg with zstd support (was Re: dpkg with threaded xz decompression.)

[Guillem Jover]

On Wed, 2022-09-28 at 01:57:56 +0100, Sérgio Basto wrote:
> BTW not about xz , but Zstd, which is available on dpkg (1.21.1ubuntu1)
> 
>   [..]
> - Add Zstd compression and decompression support for binary
> packages.
> 
> i.e. maybe also include Zstd to be compatible with Ubuntu 
> 
> reference : https://bugzilla.redhat.com/show_bug.cgi?id=2112807

Yes, I'm not happy at all about how this was pushed from the Ubuntu
side. But it's been looking like there's not many options here. :(
See, last item on:

  

So I'm still not certain how this will be added, but certainly before
the Debian freeze. I'm though not planning on adding zstd support for
source packages.

Thanks,
Guillem

Bug#1020898: Uninstallable due to file conflict A37F26876B58371B70EDD889AD69F064C90AC2C6

[Guillem Jover]

Package: perl6-readline,raku-file-which,raku-librarycheck,raku-readline
Severity: serious

Hi!

[ Filing against all affected packages because it's not clear to me which
  one needs to be fixed. ]

These packages all contain (at least) these same filenames:

  ,---
  perl6-readline: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6
  perl6-readline: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id
  raku-file-which: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6
  raku-file-which: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id
  raku-librarycheck: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6
  raku-librarycheck: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id
  raku-readline: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6
  raku-readline: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id
  `---

which cause the installation to fail:

  ,---
  Preparing to unpack .../raku-file-which_1.0.1-3+b1_amd64.deb ...
  Unpacking raku-file-which (1.0.1-3+b1) over (1.0.1-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/raku-file-which_1.0.1-3+b1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6',
 which is also in package raku-readline:amd64 0.1.6-2+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../raku-librarycheck_0.0.10-3_amd64.deb ...
  Unpacking raku-librarycheck (0.0.10-3) over (0.0.10-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/raku-librarycheck_0.0.10-3_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6',
 which is also in package raku-readline:amd64 0.1.6-2+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/raku-file-which_1.0.1-3+b1_amd64.deb
   /var/cache/apt/archives/raku-librarycheck_0.0.10-3_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  `---

while perl6-readline and raku-readline can be installed to replace one
another, they cannot be installed alongside the others AFAICS.

Thanks,
Guillem

Bug#1013876: Please close if fixed to migrate to testing

[Guillem Jover]

Hi!

On Fri, 2022-09-23 at 13:27:31 +, Amr Ibrahim wrote:
> On Mon, 27 Jun 2022 07:21:33 +0200 Bruno Kleinert 
> wrote:
> > thanks for the report. Something else in 1.8.0 is bugging me that may
> > be related to upstream's jQuery removal. I'm expecting upstream may
> > release 1.8.1 soonish.

> Please close this bug if fixed in unstable to migrate the package to
> testing.

I've kept the package on hold since, but try to upgrade from time to
time to see whether its fixed. Last time I did with the latest version
currently in sid, it seemed to be still broken.

Thanks,
Guillem

Bug#1020275: dpkg-dev: Please add support for -D_FORTIFY_SOURCE=3 hardening build flag

[Guillem Jover]

Control: tags -1 moreinfo

On Mon, 2022-09-19 at 10:06:11 +0200, intrigeri wrote:
> Package: dpkg-dev
> Version: 1.21.9
> Severity: wishlist

> According to
> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level,
> _FORTIFY_SOURCE=3 improves memory management protections. It requires
> glibc 2.34. It's been supported in Clang "for some time" and support
> was added to GCC 12. I understand it has some performance impact.

It would be nice to understand what's the impact here. Paul Wise also
mentioned a thread on .

If the intention is to update the default, then that would require a
discussion on d-d:

  


> I suppose we don't want to switch hardening=fortify fortification
> level 3, at least to start with.
> 
> So perhaps a new hardening=XYZ flag could allow package maintainers to
> opt-in?

The main problem is that any new feature added to an area such as
hardening will be automatically picked up by anything that is
currently specifying hardening=all. :/

I've been pondering about managing this kind of thing via
, but I
don't think that would even help with the =all problem. So I was
thinking a potential solution would be to version the =all request
somehow.

We'd have =all meaning level 0, then say =all-v1 for the new defaults,
that would also mean we can safely add new features that will not be
part of the current =all.

Thanks,
Guillem

Bug#1020542: inetutils: telnet[d] descriptions: suggest different alternative packages

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Fri, 2022-09-23 at 02:20:21 +0200, Bastian Germann wrote:
> Source: inetutils
> Version: 2:2.3-5
> Severity: wishlist
> Control: block 1018949 by -1

> To help with #1018949 (netkit-telnet: Drop in favour of netkit-telnet-ssl),
> please suggest to install telnet[d]-ssl in the telnet[d] descriptions
> instead of the lately introduced packages.
> 
> This can prevent introducing the new netkit-telnet[d] packages in bookworm.
> They are unnecessary and duplicate code in the archive.

I agree with the sentiment, but I'd like to hear what Simon has to say
about this, and whether the packages are going to stay or not.

> I have included a patch that applies on the current main branch.

Thanks! Depending on what Simon says, I'd either merge this, or amend
it to add the references in addition to the current ones.

I also think the blocking is backwards, as this is not my decision to
make, only to sync the documentation with reality, on what might
happen on the netkit-telnet side. :)

Thanks,
Guillem

Bug#1020267: Essential packages only provide functionality after being configured

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 20:27:46 -0700, Russ Allbery wrote:
> Helmut Grohne  writes:
> > […] It can be made explicit in section 3.8 quite easily:
> 
> >  Since dpkg will not prevent upgrading of other packages while an
> >  ``essential`` package is in an unconfigured state, all ``essential``
> >  packages must supply all of their core functionality even when
> > -unconfigured. If the package cannot satisfy this requirement it must not
> > +unconfigured after being configured at least once.
> > +If the package cannot satisfy this requirement it must not
> >  be tagged as essential, and any packages depending on this package must
> >  instead have explicit dependency fields as appropriate.

Seconded.

Thanks,
Guillem


signature.asc
Description: PGP signature

Bug#998282: Please make Section a required field for the source paragraph in d/control

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 19:36:36 -0700, Russ Allbery wrote:
> Felix Lechner  writes:
> > The installable stanzas in d/control (called "binary package paragraphs"
> > in policy) inherit the Section field from the source paragraph. There is
> > no reason to provide inheritance the other way around.
> 
> Huh, this pointed out to me that I don't know what the current behavior
> is.  I think I've always put a Section field in the first stanza and then
> overridden it as necessary, or at least I don't remember thinking about
> this before.

If you omit the field in the source stanza, then both dpkg-genchanges
and lintian will complain about it with a warning.

> The current Policy description of the Section field is rather cryptic:
> 
> This field specifies an application area into which the package has
> been classified. See Sections.
> 
> When it appears in the debian/control file, it gives the value for the
> subfield of the same name in the Files field of the .changes file. It
> also gives the default for the same field in the binary packages.
> 
> I understand what it's trying to say, but that's a very mechanical
> definition that isn't clear about the relationship between the Section
> field in the source stanza and the Section field in the binary stanzas.
> (It also claims Section is about an "application area," a term that I
> don't think we use anywhere else in Policy.)
> 
> So, what happens today if you put Section in a binary stanza but not in
> the source stanza?  Is it inherited from the binary stanza by the source
> stanza (I agree that seems weird)?  If so, from which binary stanza is it
> inherited, if there are several?  The definition of the Files field
> implies that the section may just be - in some cases.

Some of the fields found in the debian/control binary stanzas inherit
their values (if omitted) from the source stanza, otherwise they get
overridden.

The binary packages use a combination of information from
debian/changelog, the source stanza and their own binary stanza.

For non-binary packages (sources) or artifacts (say .buildinfo, or
byhand objects) there are no binary stanzas, so no information is
taken from them.

If you specify a Section field for every binary stanza, and omit it
from the source stanza, then dpkg-genchanges will have to fill it with
«-» when generating the .changes file.

If you omit the Section field from both the source stanza and one of
the binary stanzas, then that binary package will contain no Section
field, dpkg-genchanges will warn about both missing fields, and it
will fill the section value as «-» for that binary package on the
.changes file.

Thanks,
Guillem

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 21:42:37 -0700, Russ Allbery wrote:
> "Daniel Shahaf"  writes:
> > Here's a revision of the patch incorporating the feedback so far:
> 
> Thank you for this patch!  I confirmed that your description matches the
> regular expression.  This has now been applied for the next release of
> Debian Policy.

I also committed a changed based off this patch to dpkg's
deb-changelog(5) man page, which I mentioned some time ago I'd do,
but probably didn't as I thought the patch here still had the issue
discussed at the time.

Thanks,
Guillem

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Guillem Jover]

Hi!

On Thu, 2022-09-22 at 14:26:38 +0900, Charles Plessy wrote:
> Le Tue, Sep 20, 2022 at 06:08:16PM -0700, Russ Allbery a écrit :
> > I do find the use of paragraph the way we were previously using it to
> > be confusing, particularly given that the paragraphs contain fields
> > which in turn contain actual paragraphs in the normal sense of the
> > term.

Idem.

> > I don't want to keep using paragraph, but I'd be open to some other term
> > that Guillem was also open to (I think matching the terminology in dpkg is
> > very important).  Section or block are commonly used for things like this,
> > but aren't very precise, so I'm not that enthused by them.
> 
> In the spec, the word "paragraph" is only used in the specified context,
> so I always felt that there is no ambiguity.  But of course, it can
> create opportunities for misunderstanding when discussing about the
> spec.  So point taken about "paragraph", although interestingly, the
> Simple English definition of "paragraph" is quite spot on if one would
> replace "sentence" with "field": ”one or more sentences that are written
> together with no line breaks separating them.  Usually they are
> connected by a single idea.” ()

In the end nothing will match exactly, and we need to choose some
terminology. In this case, as previously mentioned, «stanza» has the
good properties of not usually applying to prose, being short, distinct
from the other terms and the less ambiguous of them all. It also makes
constructing sentences to describe things less cumbersome.

> I do not mind the word "section".  It is the term used in the manual
> page "systemd.syntax" that describes systemd's unit files, which means
> that readers may be already familiar with the concept.  One could argue
> that its definition in Simple English
> (, “A section of a thing or
> place is a part of it”) would allow a reader to think that a Field is
> also a section, but I feel it is unlikely to happen.  This said, one big
> disadvantage of "section" is that when searching for this word in a
> document, there may be a lot of noisy hits such as "refer to section xyz
> for details".

The problems with section, is that as you mention is not very
searchable, but worse we already have a field with the same name!

> I understand about avoiding ambiguity, but in my opinion it is the price
> to pay to be able to translate information into simple words from
> English to non-European languages.  Although the Policy itself is not
> going to be translated, I think that it can be advantageous if its
> contents can be discussed in simple words in people's native languages.

As a non-native speaker, and a translator, I agree having clear
wording in the original text is important, as otherwise that tends to
make translation work harder. But then, part of that work is to find
or create terminology, in many cases not existing yet in the
translated language, that might be suitable there, trying several terms
that might not necessarily be direct translations.

For a translation anecdote related to finding the right terms, when
triggers got introduced, and having to translate them to Catalan, we
initially used «gallets» (which would be the direct translation). But
when reading them that was bothering several of us as it sounded weird,
it could be read as “small roosters” («gall» being rooster, and «ets»
forming the plural diminutive), or being too close to «galets» which is
a type of pasta used for example in «sopa de galets» ("galets" soup). We
then switched to «activadors» which sounds way nicer, even though it's
not a direct translation. But if we had to translate the spec today,
that would be annoying as it uses «activating» all over the place, so
perhaps using «disparador» would be better. So, in the end this is a
process too, and terms can be changed if they are deemed confusing or
not helping convey the meaning. And in some others, you just need to
simply create new terminology, and describe what it means in specific
contexts.


For example for Catalan/Spanish «stanza» is simply «estrofa» which
seems like a nice term to use here.

Thanks,
Guillem

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 21:21:23 -0700, Russ Allbery wrote:
> Here is a patch to fix this wording in Policy.  I think it's ready for
> seconds.

> >From c98654d7effa875c6e11da16159ac3feded8f763 Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Tue, 20 Sep 2022 21:17:55 -0700
> Subject: [PATCH] Binary and Description optional in .changes
> 
> In .changes files for source-only uploads, the Binary and
> Description fields are not present.  Document this, and be clearer
> in the description of the Description field for .changes files that
> only descriptions of binary packages are included.
> ---
>  policy/ch-controlfields.rst | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 428b8a7..f85f75d 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -278,7 +278,7 @@ The fields in this file are:
>  
>  -  :ref:`Source ` (mandatory)
>  
> --  :ref:`Binary ` (mandatory)
> +-  :ref:`Binary `

For deb-changes(5) I switched from “(required)” to “(required in
context)”, but I don't think there's any similar precedent in the
Debian policy. Just noting here mostly for reference or as possible
inspiration :), and not as any kind of blocker or conditional on
seconding.

>  
>  -  :ref:`Architecture ` (mandatory)
>  
> @@ -292,7 +292,7 @@ The fields in this file are:
>  
>  -  :ref:`Changed-By `
>  
> --  :ref:`Description ` (mandatory)
> +-  :ref:`Description `
>  
>  -  :ref:`Closes `
>  
> @@ -809,12 +809,13 @@ See :ref:`s-descriptions` for further information on
>  this.
>  
>  In a ``.changes`` file, the ``Description`` field contains a summary of
> -the descriptions for the packages being uploaded. For this case, the
> -first line of the field value (the part on the same line as
> -``Description:``) is always empty. It is a multiline field, with one
> -line per package. Each line is indented by one space and contains the
> -name of a binary package, a space, a hyphen (``-``), a space, and the
> -short description line from that package.
> +the descriptions of the binary packages being uploaded. (``.changes``
> +files for uploads containing only source packages will not have this
> +field.)

Hmm, I guess that's fine, but perhaps it would be more precise and/or
future-proof to state instead that the field is only present if there
are binary packages included (or will be missing if they are not
present, but based on the binary packages instead of the source
packages)? Things that cross my mind might be say .changes that include
only byhand entries or similar, dunno.

> […] For this case, the first line of the field value (the part on the
> +same line as ``Description:``) is always empty. It is a multiline field,
> +with one line per binary package. Each line is indented by one space and
> +contains the name of a binary package, a space, a hyphen (``-``), a space,
> +and the short description line from that package.
>  
>  .. _s-f-Distribution:
>  
> @@ -924,7 +925,8 @@ every architecture. The source control file doesn't 
> contain details of
>  which architectures are appropriate for which of the binary packages.
>  
>  When it appears in a ``.changes`` file, it lists the names of the binary
> -packages being uploaded, separated by whitespace (not commas).
> +packages being uploaded, separated by whitespace (not commas). If only
> +source packages are being uploaded, this field will not be present.

Ditto.

>  
>  .. _s-f-Installed-Size:

Thanks,
Guillem

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 18:52:22 -0700, Russ Allbery wrote:
> Here is a patch that I believe implements that, and which I think is ready
> for seconds.

> >From 2260f7a3aafe93282860aad07b7d8c1544bcf0ce Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Tue, 20 Sep 2022 18:49:04 -0700
> Subject: [PATCH] new-version now passed to more maintainer scripts
> 
> Starting with dpkg 1.18.5, several maintainer script actions
> involving a new package version get that version as an argument
> after the old version. Update Policy's maintainer script
> documentation accordingly.
> ---
>  policy/ch-maintainerscripts.rst | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
> index 709aabf..724074c 100644
> --- a/policy/ch-maintainerscripts.rst
> +++ b/policy/ch-maintainerscripts.rst
> @@ -107,8 +107,8 @@ old version of a package that is being upgraded from or 
> downgraded from.
>  The ``preinst`` script may be called in the following ways:
>  
>  | ``new-preinst`` install
> -| ``new-preinst`` install *old-version*
> -| ``new-preinst`` upgrade *old-version*
> +| ``new-preinst`` install *old-version* *new-version*
> +| ``new-preinst`` upgrade *old-version* *new-version*
>  
>  The package will not yet be unpacked, so the ``preinst`` script
>  cannot rely on any files included in its package. Only essential
> @@ -168,10 +168,10 @@ The ``prerm`` script may be called in the following 
> ways:
>  where dependencies are only "Half-Installed" due to a partial
>  upgrade.
>  
> -``new-prerm`` failed-upgrade *old-version*
> -Called during error handling when ``prerm upgrade`` fails. The new 
> package will not yet be
> -unpacked, and all the same constraints as for ``preinst upgrade``
> -apply.
> +``new-prerm`` failed-upgrade *old-version* *new-version*
> +Called during error handling when ``prerm upgrade`` fails. The new
> +package will not yet be unpacked, and all the same constraints as for
> +``preinst upgrade`` apply.
>  
>  The ``postrm`` script may be called in the following ways:
>  
> @@ -189,7 +189,7 @@ The ``postrm`` script may be called in the following ways:
>  the package's dependencies if those dependencies are unavailable.
>  [#]_
>  
> -``new-postrm`` failed-upgrade *old-version*
> +``new-postrm`` failed-upgrade *old-version* *new-version*
>  Called when the old ``postrm upgrade`` action fails. The new package
>  will be unpacked, but only essential packages and pre-dependencies
>  can be relied on. Pre-dependencies will either be configured or will
> @@ -197,8 +197,8 @@ The ``postrm`` script may be called in the following ways:
>  configured and was never removed.
>  
>  | ``new-postrm`` abort-install
> -| ``new-postrm`` abort-install *old-version*
> -| ``new-postrm`` abort-upgrade *old-version*
> +| ``new-postrm`` abort-install *old-version* *new-version*
> +| ``new-postrm`` abort-upgrade *old-version* *new-version*
>  
>  Called before unpacking the new package as part of the error
>  handling of ``preinst`` failures. May assume the same state as
> @@ -229,7 +229,7 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   new-prerm failed-upgrade *old-version*
> +   new-prerm failed-upgrade *old-version* *new-version*
>  
> If this works, the upgrade continues. If this does not work, the
> error unwind:
> @@ -305,13 +305,13 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   *new-preinst* upgrade *old-version*
> +   *new-preinst* upgrade *old-version* *new-version*
>  
> If this fails, we call:
>  
> .. parsed-literal::
>  
> -   *new-postrm* abort-upgrade *old-version*
> +   *new-postrm* abort-upgrade *old-version* *new-version*
>  
> i.  If that works, then
>  
> @@ -331,13 +331,13 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   *new-preinst* install *old-version*
> +   *new-preinst* install *old-version* *new-version*
>  
> Error unwind:
>  
> .. parsed-literal::
>  
> -   *new-postrm* abort-install *old-version*
> +   *new-postrm* abort-install *old-version* *new-version*
>  
> If this fails, the package is left in a "Half-Installed" state,
> which requires a reinstall. If it works, the packages is left in
> @@ -397,7 +397,7 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   *new-postrm* failed-upgrade *old-version*
> +   *new-postrm* failed-upgrade *old-version* *new-version*
>  
> If this works, installation continues. If not, Error unwind:
>  
> @@ -410,7 +410,7 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   

Bug#1020335: Enable lfs (large file support) by default for building packages

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 12:03:41 +0200, Helge Deller wrote:
> Package: dpkg
> Severity: wishlist
> Tags: lfs, hppa

> I've seen quite some lfs errors (on 32-bit platform) with packages in
> the last weeks.
> Isn't it time now (year 2022), to take lfs down from "future" feature
> to "standard" feature and enable it by default?

Ideally? Yeah, I'd love that. In practice this unfortunately cannot
be done. I think not even with something like
! :/

> I mean, instead of requiring package maintainers to add:
>   DEB_BUILD_OPTIONS="future=+lfs"
> or
>   DEB_BUILD_MAINT_OPTIONS="future=+lfs"
> 
> simply enable this feature now by default?
> 
> With that everyone (on a 32-bit platform) would e.g. get:
> 
> dpkg-buildflags --get CPPFLAGS
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
> 
> I have to admit, that I don't know if some packages would fail to build
> with it, but if they do, they should be fixed

Besides potential build failures (although those should have been
sorted out when building on 64-bit arches), the main problem here is
that this would break ABIs everywhere, which for shared libraries,
plugins, modules and similar would be catastrophic. And as I mentioned
above I don't think it would be safe to enable automatically even with
some kind of dpkg compat level, as this might still break the ABI, and
not be noticed until run-time when things start to misbehave/segfault
etc.

So, as mentioned while I'd really like for us to be able to complete
the LFS switch, which has been going on for years now, I'm afraid it
cannot (at least currently) be done automatically from the dpkg side.
And thus I'm inclined to mark this as wontfix and close in a bit. :/

Thanks,
Guillem

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 17:34:57 -0700, Russ Allbery wrote:
> Sean Whitton  writes:
> > On Mon 19 Sep 2022 at 12:45AM +02, Guillem Jover wrote:
> >> So, personally, I'd be happy to fully switch to stanza TBH, because it
> >> seems more specific to our use, probably easier to search for, and
> >> it's shorter.
> 
> > I think this is fine for Policy to do.
> 
> I vote for switching to stanza.  Paragraph is going to be confusing when
> talking about package descriptions, which often have multiple paragraphs
> in the normal English meaning of the term.

Ok, I've prepared the attached incremental patch, which only switches
from paragraph(s) to stanza(s) all over the place.

I've updated all the specs for consistency. I've updated the footnote
to swap the preference and to mention paragraph is now discouraged
nomenclature. I've also updated all «id»s out of consistency, which
might break links, so I can revert that if you'd prefer. And I've
preserved the (upper) casing for one of the titles (“Stand-alone
License Stanza”, although that was not consistent with the other
titles, such as “Files stanza”, I'm happy to lower case that one).

I've gone one by one, but please review carefully as I might have
perhaps switched in excess!

Thanks,
Guillem
From 6d02f28eb1f0cd2f7afa75b04691265425122366 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 19 Sep 2022 22:33:40 +0200
Subject: [PATCH] Use stanza to refer to deb822 parts instead of paragraph
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The «stanza» name is a commonly used and understood term when referring
to deb822 blocks. Although «paragraph» is commonly used it has the
problem of being confusing as it then makes it hard to distinguish
actual text paragraphs in prose, while «stanza» is a very specific
term that is not applied anywhere else in the deb822 context, so it's
always more clear and specific.

In addition «stanza» is shorter, which is always a nice attribute
on code for example.

The references in dpkg documentation and code, will be updated shortly,
so that there is uniform nomenclature used.

Fixes: #1020248
---
 autopkgtest.md |   2 +-
 copyright-format-1.0.xml   | 116 -
 policy/ch-controlfields.rst|  46 ++---
 policy/upgrading-checklist.rst |   8 +--
 4 files changed, 87 insertions(+), 85 deletions(-)

diff --git a/autopkgtest.md b/autopkgtest.md
index bc7bdaf..74d6885 100644
--- a/autopkgtest.md
+++ b/autopkgtest.md
@@ -219,7 +219,7 @@ debian/control by adding
 
 XS-Testsuite: autopkgtest
 
-in the `Source:` paragraph.
+in the `Source:` stanza.
 
 Implicit test control file for known package types
 --
diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index d5d2bbe..954a65b 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -115,17 +115,17 @@
   The syntax of the file is the same as for other Debian control files, as
   specified in the Debian Policy Manual.  See its https://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax;>section
-  5.1 for details. Extra fields can be added to any paragraph.  No
+  5.1 for details. Extra fields can be added to any stanza.  No
   prefixing is necessary or desired, but please avoid names similar to
   standard ones so that mistakes are easier to catch.  Future versions of
   the debian/copyright specification will attempt to
   avoid conflicting specifications for widely used extra fields.
 
 
-  The file consists of two or more paragraphs.  At minimum, the file
-  must include one header
-  paragraph and one Files
-  paragraph.
+  The file consists of two or more stanzas.  At minimum, the file
+  must include one header
+  stanza and one Files
+  stanza.
 
 
   There are four types of fields.  The definition for each field in this
@@ -184,22 +184,22 @@
 
   
 
-  
-Paragraphs
+  
+Stanzas
 
-  There are three kinds of paragraphs.  The first paragraph in the file
-  is called the header paragraph.
-  Every other paragraph is either a Files paragraph or a stand-alone License
-  paragraph.  This is similar to source and binary package
-  paragraphs in debian/control files.
+  There are three kinds of stanzas.  The first stanza in the file
+  is called the header stanza.
+  Every other stanza is either a Files stanza or a stand-alone License
+  stanza.  This is similar to source and binary package
+  stanzas in debian/control files.
 
 
-
-  Header paragraph (once)
+
+  Header stanza (once)
   
-The following fields may be present in a header paragraph.
+The following fields may be present in a header stanza.
   
   
 
@@ -249,9 +249,9 @@
  

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

On Sun, 2022-09-18 at 18:01:38 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> 
> > Oh! I've completely missed this all this time, I think because that
> > feels very weird given that it has no synopsis and the text is added
> > already on the first line on the spec. :/
> 
> Other formatted fields with the same semantics are Source, Disclaimer, and
> Comment.  I don't think there are any fields in debian control files with
> those semantics (Description is the only formatted field and it has a
> synopsis), but there are several of them in copyright files.
> 
> Source is another ongoing minor problem, since it's *usually* a URL but is
> not required to be one, and sometimes a textual description of the source
> is needed.  Here too, a structured format would have been nicer, so that
> you could have something like:
> 
> source:
>   urls:
> - https://example.com/foo
> - https://example.org/foo
>   comment: >-
> The foo-rewrite script was originally posted to comp.unix.sources in
> 1992 but otherwise has no source other than the Debian package.

I think Disclaimer and Comment do not seem as problematic because they
tend to contain descriptive prose. For Source it's true that it's
weird as it seems to indeed want to have two different semantics
depending on the content, and considering the current deb822 format,
perhaps having used two different field names might have been better
as you alluded with your YAML example, say Source-Urls (line-based list),
and Source-Comment (formatted text). Such split still seems feasible
and backwards compatible right now though.

But see below.

> > Right, the problem I see is that applying this formatting to a field
> > that has no special treatment for the first line just after the field
> > name seems very unintuitive, because the first line does not contain an
> > additional prefixing space, or if it does no one is adding it!
> 
> > It feels very weird to me that all these would be equivalent:
> 
> >   Copyright: Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
> 
> > and
> 
> >   Copyright:  Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
> 
> > and
> 
> >   Copyright:
> > Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
> 
> I think my brain just assumes that all whitespace after the colon of a
> field name and before the first non-whitespace character is ignored, so
> doesn't have a problem with that, but I can see why it would be confusing.

Just to try to clarify to make sure we are on the same page (if we are,
sorry for the obvious!). What I find confusing is that the semantics
of the field imply different line-wrapping semantics depending on leading
spaces, and because there's no synopsis, the first line is supposed to
act just like the rest, but if spaces are ignored, then how do you
select either of the line-wrapping behaviors for the first line? Also
because adding such spaces after the colon look like typographic errors
to me somehow.

So I think what seems most confusing to me is that for formatted-text
fields with no synopsis, the first line is being used at all, because
that messes with the intuition on how the Description field operates.

> > Otherwise, if the current semantics are retained, at least for me, the
> > first line behavior really needs to be clarified.
> 
> Yes, we should distinguish between formatted text with synopsis and
> formatted text without synopsis more clearly.

Yes.

> Or, you know, just propose
> a new YAML format which would make it trivial to clean up all of these
> problems *and* would provide first-class editor support and easy parsing
> in every major programming language.  :)  But that's WAY bigger than this
> bug.

Ahem, yeah. :)

> > If we end up switching the field semantics, that seems it might cause
> > unnecessary modification churn, given that I (not sure whether other
> > people have done this before than me as well) at least have "instigated"
> > unintentionally this type of change in several places (packages I
> > maintain, golang/prometheus team), including tooling (AFAIR dh-make and
> > dh-make-golang), and other people might have also picked this up too. :/
> 
> I think making the field a line-based list is the obviously correct thing
> to do.  It's just not backward-compatible, so we will have to face the
> question of how we handle a version bump in the copyright file (and of
> course figure out 

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

On Sun, 2022-09-18 at 18:04:00 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> > BTW, just to make this clear, if this feels like it might not be decided
> > quickly on the Debian policy side, then I'll prepare/commit changes to
> > revert this behavior from tooling that I've previously introduced, until
> > and if this changes again. Otherwise if the feeling is that this might
> > get decided quickly, then I'd prefer to avoid the flip-flopping behavior
> > change (but not to be taken as "current-practice" pressure to swindle
> > the decision! And I'm happy to do it in this case anyway if that makes
> > people feel better about it).
> 
> I have an entirely unpredictable schedule for Debian work, unfortunately,
> so I truly don't have any idea how long this will take.

No problem. Then in that case I guess I'll try to prepare/commit such
revert patches for the tooling during this week or so.

Thanks,
Guillem

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Guillem Jover]

On Sun, 2022-09-18 at 14:53:30 -0700, Sean Whitton wrote:
> On Sun 18 Sep 2022 at 10:28PM +02, Guillem Jover wrote:
> 
> > So, how does «source package paragraph» and «binary package paragraph»
> > (of the «template control file») sound instead?
> 
> Can we standardise on 'stanza', please?
>
> I thought that was already standard, and "paragraph" is for prose.

I was also thinking about whether I'd prefer paragraph or stanza, and
the latter seems more specific to deb822 "blocks", and as you say
paragraph seems more for prose.

I went for paragraph, because dpkg has some instances of it already in
docs and code (and stanza only in code), and mainly because the Debian
policy uses almost exclusively paragraph for this with a single
mention of "stanza" in a footnote to mention it's a common alias or
similar.

So, personally, I'd be happy to fully switch to stanza TBH, because
it seems more specific to our use, probably easier to search for, and
it's shorter.

Thanks,
Guillem

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 22:56:16 +0200, Guillem Jover wrote:
> On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote:
> > Russ Allbery  writes:
> > > I would happily apply a version of 0002 that only changes Files and
> > > leaves Copyright alone.
> 
> I can split that up, for an incremental update yes. Will send later.

Attached.

> > Or, perhaps even better, one that changes Copyright the way that you did,
> > but just adds an extra space.  I think that's the simplest compromise
> > between what you're trying to accomplish and the field definition.
> 
> If we end up switching the field semantics, that seems it might cause
> unnecessary modification churn, given that I (not sure whether
> other people have done this before than me as well) at least have
> "instigated" unintentionally this type of change in several places
> (packages I maintain, golang/prometheus team), including tooling
> (AFAIR dh-make and dh-make-golang), and other people might have also
> picked this up too. :/

BTW, just to make this clear, if this feels like it might not be
decided quickly on the Debian policy side, then I'll prepare/commit
changes to revert this behavior from tooling that I've previously
introduced, until and if this changes again. Otherwise if the feeling
is that this might get decided quickly, then I'd prefer to avoid the
flip-flopping behavior change (but not to be taken as "current-practice"
pressure to swindle the decision! And I'm happy to do it in this case
anyway if that makes people feel better about it).

Thanks,
Guillem
From 6c74ff53624595267215405edaf09ab3146d5b93 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 18 Sep 2022 18:10:59 +0200
Subject: [PATCH] copyright-format: Wrap and sort -sat Files field

Do not place entries on the first line with the field name, and place
one item per line, so that adding or removing entries generates as
minimal a diff as possible, and avoids modifying unrelated lines. Use
a single space so that the indentation is always uniform among all
fields.
---
 copyright-format-1.0.xml | 42 ++--
 debian/copyright | 18 +++--
 2 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index 0f86a76..d5d2bbe 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -316,19 +316,23 @@ Upstream-Contact: John Doe john@example.com
 
   
 Example files paragraphs
-Files: *
+Files:
+ *
 Copyright: 1975-2010 Ulla Upstream
 License: GPL-2+
 
-Files: debian/*
+Files:
+ debian/*
 Copyright: 2010 Daniela Debianizer
 License: GPL-2+
 
-Files: debian/patches/fancy-feature
+Files:
+ debian/patches/fancy-feature
 Copyright: 2010 Daniela Debianizer
 License: GPL-3+
 
-Files: */*.1
+Files:
+ */*.1
 Copyright: 2010 Manuela Manpager
 License: GPL-2+
 
@@ -401,12 +405,14 @@ License: LGPL-2.1
 
   
 recurrent license
-Files: src/js/editline/*
+Files:
+ src/js/editline/*
 Copyright: 1993, John Doe
1993, Joe Average
 License: MPL-1.1
 
-Files: src/js/fdlibm/*
+Files:
+ src/js/fdlibm/*
 Copyright: 1993, J-Random Corporation
 License: MPL-1.1
 
@@ -1261,7 +1267,8 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Source: ftp://ftp.example.com/pub/games
 Upstream-Name: X Solitaire
 
-Files: *
+Files:
+ *
 Copyright: 1998 John Doe 
1998 Jane Smith 
 License: GPL-2+
@@ -1298,39 +1305,46 @@ Source: https://www.example.com/code/venus
 Upstream-Name: Planet Venus
 Upstream-Contact: John Doe 
 
-Files: *
+Files:
+ *
 Copyright: 2008, John Doe 
2007, Jane Smith 
2007, Joe Average 
2007, J. Random User 
 License: PSF-2
 
-Files: debian/*
+Files:
+ debian/*
 Copyright: 2008, Dan Developer 
 License: permissive
  Copying and distribution of this package, with or without modification,
  are permitted in any medium without royalty provided the copyright notice
  and this notice are preserved.
 
-Files: debian/patches/theme-diveintomark.patch
+Files:
+ debian/patches/theme-diveintomark.patch
 Copyright: 2008, Joe Hacker 
 License: GPL-2+
 
-Files: planet/vendor/compat_logging/*
+Files:
+ planet/vendor/compat_logging/*
 Copyright: 2002, Mark Smith 
 License: MIT
  [LICENSE TEXT]
 
-Files: planet/vendor/httplib2/*
+Files:
+ planet/vendor/httplib2/*
 Copyright: 2006, John Brown 
 License: MIT2
  Unspecified MIT style license.
 
-Files: planet/vendor/feedparser.py
+Files:
+ planet/vendor/feedparser.py
 Copyright: 2007, Mike Smith 
 License: PSF-2
 
-Files: planet/vendor/htmltmpl.py
+Files:
+ planet/vendor/htmltmpl.py
 Copyright: 2004, Thomas Brown 
 License: GPL-2+
 
diff --git a/debian/copyright b/debian/copyright
index 357ae48..21a514b 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -7,7 +7,8 @@ Comment: Complete copyright notices for all contributors to the vario

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 10:42:28 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> 
> > These are the set of changes I keep doing to the debian/copyright files
> > I end up touching. While some could be characterized as a subjective
> > style issue, I've tried to give as close as possibly objective :)
> > rationale for every and each of the changes in the commit messages which
> > I'll summarize here.
> 
> Thanks!  I have applied these changes for the next release except for
> patch 0002 (applying wrap-and-sort -sat).
> 
> I agree with patch 0002 for Files, but unfortunately I believe it's
> incorrect for Copyright.  You're treating Copyright as if it were a
> line-based list field, but for better or worse (I think probably for
> worse) the current specification says that it's a formatted field.

Oh! I've completely missed this all this time, I think because that
feels very weird given that it has no synopsis and the text is added
already on the first line on the spec. :/

> This means that your change to, for example:
> 
> Copyright:
>  2008 John Doe 
>  2007 Jane Smith 
>  2007 Joe Average 
>  2007 J. Random User 
> 
> means that the semantic content of that field is now:
> 
>  2008 John Doe  2007 Jane Smith 
>  2007 Joe Average  2007 J. Random User
>  
> 
> and a format-aware display engine should show it as such.  This is the
> reason why lines are indented: that makes them verbatim lines per the
> formatting specification in
> https://www.debian.org/doc/debian-policy/ch-controlfields#s-f-description

Right, the problem I see is that applying this formatting to a field
that has no special treatment for the first line just after the field
name seems very unintuitive, because the first line does not contain
an additional prefixing space, or if it does no one is adding it!

It feels very weird to me that all these would be equivalent:

  Copyright: Something long that might trigger some wrapping behavior
Other thing very long that might not be clear behaves as the above
More

and

  Copyright:  Something long that might trigger some wrapping behavior
Other thing very long that might not be clear behaves as the above
More

and

  Copyright:
Something long that might trigger some wrapping behavior
Other thing very long that might not be clear behaves as the above
More

> I would agree with changing the definition of Copyright to a line-based
> list, although in order to do so we'd have to figure out the implications
> of a format change in the specification, and we should also flesh out the
> definition of a line-based list to explain how to handle a line that's
> longer than the normal wrap length.

Right, I'd prefer this too, but obviously that is more involved than
what this report intended to be. So I guess it should be detangled
into another request.

Otherwise, if the current semantics are retained, at least for me, the
first line behavior really needs to be clarified.

On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote:
> Russ Allbery  writes:
> > I would happily apply a version of 0002 that only changes Files and
> > leaves Copyright alone.

I can split that up, for an incremental update yes. Will send later.

> Or, perhaps even better, one that changes Copyright the way that you did,
> but just adds an extra space.  I think that's the simplest compromise
> between what you're trying to accomplish and the field definition.

If we end up switching the field semantics, that seems it might cause
unnecessary modification churn, given that I (not sure whether
other people have done this before than me as well) at least have
"instigated" unintentionally this type of change in several places
(packages I maintain, golang/prometheus team), including tooling
(AFAIR dh-make and dh-make-golang), and other people might have also
picked this up too. :/

Thanks,
Guillem

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Guillem Jover]

Package: debian-policy
Version: 4.6.1.1
Severity: wishlist

Hi!

This is a followup from my comment at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#43

To summarize, we have IMO confusing naming and nomenclature for the
various control files and paragraphs/stanzas, and this is even
confusing me when having to deal with dpkg code, so I'd like to give
these more clear and unambiguous new names, and I'd very strongly
prefer to agree on the same naming for Debian policy and dpkg, to
avoid further and worse confusion (even though they currently do not
match exactly anyway, but I'd prefer to not make it worse…).

Just for reference and to give some context, I've got the following
WIP branches, trying to clarify the names in documentation and in the
API on, which I'll probably rework (split/merge) and reword as needed,
so do not take them as anything set in stone:

  
https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/clarify-control-filenames
  
https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/deb822-field-types


File descriptions
-

For example we have:

  * debian/control:
policy → «Source package control file»
dpkg   → «Debian source packages' master control file»

  * .dsc:
policy → «Debian source control file»
dpkg   → «Debian source packages' control file»

  * DEBIAN/control
policy → «Binary package control files»
dpkg   → «Debian binary packages' master control file»

These are quite confusingly close.

I've been considering naming debian/control something like
«Debian template source package control file», as that is used to
generate both the source and binary control files. And always
prefixing with Debian, so that would end up as:

  * debian/control: «Debian source package template control file»
  * .dsc:   «Debian source package control file»
  * DEBIAN/control: «Debian binary package control file»

This also removes the «master» usage in dpkg, for me for the same
reasons as I covered at
.


File contents
-

We have references to the various parts being called as «paragraphs»,
«stanza», «blocks», but this seems to be more of an issue with dpkg, as
the usage in the Debian policy is quite clear and uniform now, so I'll
at least try to remove the «block» usage there, stanza has the nice
property of being shorter and policy already mentions that this is
currently a common alias, so I might keep paragraph and stanza for now
in dpkg.

The other thing affecting dpkg and debian-policy is how the parts
within the control files are referred to. We have for example:

  dpkg   → «general section of control info file»
   «source stanza»
  policy → «general paragraph»

  dpkg   → «package's section of control info file»
  policy → «binary package paragraphs»


So, how does «source package paragraph» and «binary package paragraph»
(of the «template control file») sound instead?


If I've missed any other problematic nomenclature, I'm happy to
discuss and update those on the dpkg side.

Thanks,
Guillem

Bug#1020243: debian-policy: Use OpenPGP instead of PGP

[Guillem Jover]

Package: debian-policy
Version: 4.6.1.1
Severity: minor
Tags: patch

Hi!

Another minor patch I had laying around, switching references to the
OpenPGP specification instead of to the specific PGP implementation.

Thanks,
Guillem
From 4dd6c1ef7c487fe2cd293e8fbddfdc898e0e9199 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 23 Dec 2021 07:11:55 +0100
Subject: [PATCH] Use OpenPGP instead of PGP

The standard is called OpenPGP, PGP instead is a specific
implementation. And while depending on the context (such as filename
extensions) using .pgp is better and more neutral than using some
other implementation specific extension (such as .gpg), in this context
the text refers to the generic OpenPGP signatures.
---
 policy/ch-controlfields.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index daff424..533abba 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -212,7 +212,7 @@ The fields in this file are:
 Debian source control files -- ``.dsc``
 ---
 
-This file consists of a single paragraph, possibly surrounded by a PGP
+This file consists of a single paragraph, possibly surrounded by an OpenPGP
 signature. The fields of that paragraph are listed below. Their syntax
 is described above, in :ref:`s-controlsyntax`.
 
@@ -261,7 +261,7 @@ Debian changes files -- ``.changes``
 
 The ``.changes`` files are used by the Debian archive maintenance
 software to process updates to packages. They consist of a single
-paragraph, possibly surrounded by a PGP signature. That paragraph
+paragraph, possibly surrounded by a OpenPGP signature. That paragraph
 contains information from the ``debian/control`` file and other data
 about the source package gathered via ``debian/changelog`` and
 ``debian/rules``.
-- 
2.37.2

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

Package: debian-policy
Version: 4.6.1.1
Severity: wishlist
Tags: patch

Hi!

These are the set of changes I keep doing to the debian/copyright
files I end up touching. While some could be characterized as a
subjective style issue, I've tried to give as close as possibly
objective :) rationale for every and each of the changes in the
commit messages which I'll summarize here.

The main drive is for uniformity in formatting (compared to the
recommended GPL notice example), minimization of diff delta on changes
(the same we seem to be converging with wrap-and-sort -sat), making
the notice future-proof (by using an URL instead of a postal address),
and moving the Debian-specific filesystem location reference into a
Comment to not confuse with the actual upstream/in-code notice. Then
there's the placement of the Source field, which I guess is the
possibly more style/subjective one, but that's one that seems to also
be triggering some OCDish button or similar. :)

This change was implemented on top of the spacing and typographical
patches and seems to depend on changes in there.

Thanks,
Guillem
From 600aabb1a2235396db5fce4240ac0751258fcf7f Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 18 Sep 2022 18:05:57 +0200
Subject: [PATCH 1/6] copyright-format: Place Source field after Format field

These both contain URLs, are the most important references, and nicely
align, so it's nice to get them as early as possible in the file.
---
 copyright-format-1.0.xml | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index d29c490..3d5c672 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -271,9 +271,9 @@
   
 Example header paragraph
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Source: https://www.example.com/software/project
 Upstream-Name: SOFTware
-Upstream-Contact: John Doe john@example.com
-Source: https://www.example.com/software/project
+Upstream-Contact: John Doe john@example.com
   
 
 
@@ -1265,8 +1265,8 @@ also delete it here.
 package):
 
   
 
@@ -1339,10 +1329,9 @@ Files:
 Copyright:
  2008 Dan Developer 
 License: permissive
- Copying and distribution of this package, with or without
- modification, are permitted in any medium without royalty
- provided the copyright notice and this notice are
- preserved.
+ Copying and distribution of this package, with or without modification,
+ are permitted in any medium without royalty provided the copyright notice
+ and this notice are preserved.
 
 Files:
  debian/patches/theme-diveintomark.patch
@@ -1380,26 +1369,22 @@ License: PSF-2
  [LICENSE TEXT]
 
 License: GPL-2+
- This program is free software; you can redistribute it
- and/or modify it under the terms of the GNU General Public
- License as published by the Free Software Foundation; either
- version 2 of the License, or (at your option) any later
- version.
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
  .
- This program is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- PURPOSE.  See the GNU General Public License for more
- details.
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
  .
- You should have received a copy of the GNU General Public
- License along with this package; if not, write to the Free
- Software Foundation, Inc., 51 Franklin St, Fifth Floor,
- Boston, MA  02110-1301 USA
+ You should have received a copy of the GNU General Public License along
+ with this package; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA.
  .
- On Debian systems, the full text of the GNU General Public
- License version 2 can be found in the file
- '/usr/share/common-licenses/GPL-2'.]]>
+ On Debian systems, the full text of the GNU General Public License
+ version 2 can be found in the file '/usr/share/common-licenses/GPL-2'.]]>
   
 
   
diff --git a/debian/copyright b/debian/copyright
index eef116a..d80be52 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -99,15 +99,15 @@ Copyright:
 License: GPL-2+
 
 License: GPL-2+
- This manual is free software; you may redistribute it and/or modify it
- under the terms of the GNU General Public License as published by the
- Free Software Foundation; either version 2 of the License, or (at your
- option) any later version.
+ This manual is free software; you may redistribute it and/or modify
+ it under the terms of t

Bug#1020238: debian-policy: Spacing an typographical cleanups

[Guillem Jover]

Package: debian-policy
Version: 4.6.1.1
Severity: minor

Hi!

I'm attaching a few patches fixing spacing and typographical issues.
For the quotes fix, I personally highly prefer UTF-8 character pairs
such as «», “”, ‘’, but went with the conservative ASCII ones '' as
that tends to cause less opposition. But I'm happy to convert these to
some of the UTF-8 ones if you prefer.

Thanks,
Guillem
From a367e8cd6dd50c4304978c07d3823826bfb61365 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Wed, 5 Jan 2022 02:49:28 +0100
Subject: [PATCH 1/3] Remove trailing whitespace

---
 Makefile|  2 +-
 README.md   |  2 +-
 debconf/commands.xml|  2 +-
 debconf/priorities.xml  |  2 +-
 debian/changelog| 48 
 historical/README.shlibdeps | 20 +-
 historical/libc6-migration.txt  | 56 ++--
 policy/ap-license.rst   |  2 +-
 policy/index.rst|  2 +-
 virtual-package-names-list.yaml | 66 -
 10 files changed, 101 insertions(+), 101 deletions(-)

diff --git a/Makefile b/Makefile
index 5640fb8..0c8765d 100644
--- a/Makefile
+++ b/Makefile
@@ -299,4 +299,4 @@ $(XML_FILES:=.txt) $(XML_SINGLE_FILES:=.txt) $(XML_SPLIT_FILES:=.txt): \
 .DELETE_ON_ERROR:
 
 # No default suffixes work here, don't waste time on them.
-.SUFFIXES: 
+.SUFFIXES:
diff --git a/README.md b/README.md
index 2cf6637..fcbd8b9 100644
--- a/README.md
+++ b/README.md
@@ -113,7 +113,7 @@ as possible for others to review your work.
for your change.  If your change is particularly large, it might be
more readable not to use `--word-diff=plain`, but usually the word
diff is better.
-   
+
 Do not quote the output -- many people have mail readers which
 will colorise the diff if it is left unmodified.
 
diff --git a/debconf/commands.xml b/debconf/commands.xml
index ca73e28..490e1be 100644
--- a/debconf/commands.xml
+++ b/debconf/commands.xml
@@ -78,7 +78,7 @@
   Using a template has the advantage that titles are translatable and
   that they can be maintained in the same place as other text
   displayed to users.
- 
+
   
   
 
diff --git a/debconf/priorities.xml b/debconf/priorities.xml
index 114a9c7..7730491 100644
--- a/debconf/priorities.xml
+++ b/debconf/priorities.xml
@@ -24,7 +24,7 @@
   
 	high
 	
-  Items that don't have a reasonable 
+  Items that don't have a reasonable
 	  default.
 	
   
diff --git a/debian/changelog b/debian/changelog
index bc08838..dcb9de8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1366,7 +1366,7 @@ debian-policy (3.9.6.0) unstable; urgency=low
 Seconded: Tony Mancill 
 Seconded: Bill Allombert 
 Closes: #754876
-  * virtual-package-names-list: Add httpd-wsgi 
+  * virtual-package-names-list: Add httpd-wsgi
 Wording: Bill Allombert 
 Seconded: Jonas Smedegaard 
 Seconded: Piotr Ożarowski 
@@ -1955,9 +1955,9 @@ debian-policy (3.9.0.0) unstable; urgency=low
 Seconded:  Julien Cristau  
 Seconded:  Gregor Herrmann 
 Closes: #566220
-  * extend UID range of user accounts by removing the 3-5 reserved 
+  * extend UID range of user accounts by removing the 3-5 reserved
 ranges.
-Proposed by Santiago Vila  
+Proposed by Santiago Vila
 Seconded:  Russ Allbery
 Seconded:  Luk Claes   
 Seconded:  Raphael Hertzog 
@@ -2093,25 +2093,25 @@ debian-policy (3.8.4.0) unstable; urgency=low
   [ Manoj Srivastava ]
   * [b270d2d]: Typo fix: relayed -> related. Thanks to Matt Kraai for
 pointing this out.
-  * [c74ac74]: 
+  * [c74ac74]:
 Policy: Grant an FHS exception for the multiarch library directories
 Wording: Steve Langasek.
 Seconded: Aurelien Jarno
 Seconded: Julien Cristau
 Seconded: Kurt Roeckx
 Closes: #542865
-  * [7ac3ee6]: 
+  * [7ac3ee6]:
 virtual package list: Added Doom virtual packages
 Wording: Manoj Srivastava
-Seconded: Russ Allbery 
+Seconded: Russ Allbery
 Seconded: Giacomo A. Catenazzi
 Closes: #518199
   * [8fd91a0]
 README Process upgrading-checklist: Created/converted to org-mode
 Wording: Manoj Srivastava
-Seconded: Russ Allbery 
+Seconded: Russ Allbery
 Closes: #545548
-  * [4da0692]: [typo-fixes]: 
+  * [4da0692]: [typo-fixes]:
 policy: Fix a number of grammatical or typographical errors
 wording: Eric Dantan Rzewnicki
 Seconded: Manoj Srivastava
@@ -2145,7 +2145,7 @@ debian-policy (3.8.4.0) unstable; urgency=low
  - Support of crontab entries with names for days and months,
ranges, step values
  - Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
-
+
   [ Russ Allbery ]
   * Policy: Clarify policy on named pipes in packages
 Wording: Russ Allbery 
@@ -2286,8 +2286,8 @@ debian-policy (3.8.2.0) unstable; urgency=low
   [ Bill Allombert ]
   * Add mys

Bug#1014476: /usr/bin/dpkg: dpkg --skip-same-version should look at arch too

[Guillem Jover]

Hi!

On Wed, 2022-07-06 at 18:50:08 +0100, Ian Jackson wrote:
> Package: dpkg
> Version: 1.20.10
> Severity: normal
> File: /usr/bin/dpkg
> Tags: patch

> Recently, I did a complex semi-manual crossgrade.  Runes like
>   dpkg -iGEOB
> were frequently involved.  But I discovered that dpkg -E would
> skip a package if the same version, but a different architecture,
> was involved.
> 
> I don't think that's right.  I think that for a normal
> (non-coinstallable) package,
>   dpkg --skip-same-version foo_otherarch.deb
> should crossgrade it.
> 
> For a coinstallable package, it should coinstall it.
> 
> I think that the attached patch achieves this behaviour.  I used it[1]
> during my crossgrade it and functioned well.

Thanks for the patch! So while I think the new behavior makes more
sense, my main concern has been mostly about the long option now feeling
somehow inaccurate. :/ I guess if this becomes bothersome or confusing
we can always add a new alias or similar.

In any case I've merged this locally, with a small fix to the --help
output to make it fit under 80 chars, and this addition to the man
page to clarify the behavior change:

,---
Since dpkg 1.21.10, the architecture is also taken into account,
which makes it possible to cross-grade packages or install additional
co-installable instances with the same version, but different architecture.
`---

And I'm going to be pushing this to git.

Thanks,
Guillem

Bug#765662: dpkg: please consider adding support for the :target qualifier in build dependencies

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Wed, 2015-02-11 at 07:43:59 +0100, Johannes Schauer wrote:
> Quoting Guillem Jover (2014-10-20 17:21:00)
> > The rest looks good (as long as it behaves correctly that is :). But it 
> > would
> > be nice to add some unit tests to Dpkg_Deps.t, I've just enabled very 
> > minimal
> > ones for :native.
> 
> I fixed the s/host/target/ error and added a test case.

Thanks for the updated patch, as I mentioned at the time on IRC!

Also just to record here, that I'm still in principle fine with
merging this, and I keep having it in the back of my head, but I've
still got the same concerns I've mentioned on #debian-bootstrap when
this has come up in the past.

My recollection (confirmed from logs from 2014-10, 2015-02) was that:

  - I did not act on this as it looked like there was talk that it was
not needed/relevant anymore.
  - On one side there was the question of whether this solved the
cross-toolchain problem at all?
  - Then there was the question of how this interacted with the M-A
values.
  - And it seems Johannes mentioned starting a thread on some lists
(debian-dpkg, debian-toolchain and multiarch-devel), but I think
that was replaced by filing this report during the freeze to not
forget about it, and the mail was then postponed.

What I like about the patch in principle is that it completes the arch
handling for the build/host/target arches, so if you know about M-A,
it should be intuitive to reason about, it also gives an additional
"tool" to work with dependencies related to crossing. But the downside
is that this is more fringe stuff that people might get confused by,
and if it does not really fix any current problem properly, then I'm
also hesitant to add it TBH.

Thanks,
Guillem

Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Guillem Jover]

On Wed, 2022-09-14 at 17:31:16 +0200, Santiago Ruano Rincón wrote:
> Yeah, sorry. I lately realised not all the packages would autoreconf
> during building time.
> 
> So silencing these warnings would make sense.

Please consider implementing a way to be able to conditionally re-enable
locally these warnings so that we can try to hunt down and fix those,
otherwise we might end up hitting these once we revert the silencing,
for example for code paths that are not commonly exercised.

I've mentioned this on the upstream bug report, but it would be nicer
if you could coordinate a way upstream might be happy with, say using
a specific environment variable or similar.

Thanks,
Guillem

Bug#1017996: dpkg: please provide `--force-really-unsafe-io` (or similar) option

[Guillem Jover]

Control: forcemerge 985888 -1

On Tue, 2022-08-23 at 22:40:37 +0200, Ansgar wrote:
> Package: dpkg
> Version: 1.21.9
> Severity: wishlist
> Tags: upstream d-i

> please reconsider to provide a `--force-really-unsafe-io` (or similar)
> option that skips the calls to `fsync()` & friends in dpkg.

I think I've mentioned this elsewhere, but the main blocker has been
lack of database taint tracking support. I do have a draft branch for
a --force-reckless-io.

> I tried installing a larger package set (in stable), including
> texlive-full, KDE, GCC and other packages. It took:
> 
>   Default dpkg: ~4h10m = 250m
>   --force-unsafe-io: ~2h20m = 140m
>   eatmydata: ~22m
> 
> So skipping all fsync() calls provides a speedup of 11 compared to
> dpkg's defaults and still 6 compared to --force-unsafe-io. This is a
> very noticable change.

All fsync()s from dpkg, which are not necessarily all fsync()s
performed indirectly by maintscripts/triggers.

Guillem

Bug#1017908: dpkg: Setting to change the diff tool to view conffile difference

[Guillem Jover]

Control: forcemerge 313204 -1

On Mon, 2022-08-22 at 11:41:19 +0200, Axel Beckert wrote:
> Package: dpkg
> Version: 1.21.9
> Severity: wishlist

> it would be nice if there would be a setting (or environment variable or
> interactive option) to use a different tool than "diff" to view conffile
> differences.
> 
> This would add the possibility to e.g. use colorized diffs as provided
> by tools like colordiff, "dwdiff -c" or icdiff which allows to review
> changes more easily (like the adduser.conf changes which came in today).
> 
> P.S.: I've looked and searched through the man pages of dpkg(1) and
> dpkg.cfg(5) but found no such setting, hence the wishlist bug report.

Yeah, I've been meaning to add this, I just need to define a syntax so
that the arguments can be specified independently of the tool.

Merging with the older requests.

Thanks,
Guillem

Bug#1019565: dpkg: incorrect profile in .dsc's Build-Depends if multiline value in d/control with profiles

[Guillem Jover]

Hi!

On Mon, 2022-09-12 at 07:50:51 +0200, Fab Stz wrote:
> Package: dpkg
> Version: 1.20.12
> Severity: normal

>* What led up to the situation?
> 
> Have a package for which in debian/control there is this:
> 
> Build-Depends: debhelper-compat (= 13),
>android-sdk-build-tools
> 
> 
> 
> ,
> 
> Note the fact that the build profiles are on several lines, and not on the 
> same line as the package name.

>* What was the outcome of this action?
> 
> .dsc then contains a faulty profile. Note the "<<" and ">>" in the line.
> 
> Build-Depends: debhelper-compat (= 13), android-sdk-build-tools < android-6.4.armeabi-v7a pkg.qt-android-6.4.systemsdk>  android-6.4.arm64-v8a pkg.qt-android-6.4.systemsdk>  pkg.qt-android-6.4.systemsdk>  android-6.4.systemsdk>>

I've fixed this now locally, by converting the field values to a
single line before parsing, and will be part of my next push
targeting 1.21.10.

> This value is not correct and makes other tools fail:
> - `dpkg-source -b` will report 
>   E: Problem parsing dependency: Build-Depends

That's not an error message from dpkg-source, I'd assume that's apt
complaining.

Thanks,
Guillem

Bug#1019693: dpkg-buildpackage: fails with unknown sequence when including missing file

[Guillem Jover]

Control: reassign -1 debhelper

On Tue, 2022-09-13 at 15:50:07 +0200, Fab Stz wrote:
> Package: dpkg-dev
> Version: 1.29.9
> Severity: normal
> File: /usr/bin/dpkg-buildpackage

> This may be a regression because I don't have this problem with 1.20.12 which 
> is on bullseye.
> 
> 
> When in debian/rules, I include a file that doesn't exists, dpkg will try to
> run
> 
> dh /path/to/missing/file 
> 
> which leads to this failure & error:
> 
> dh: error: unknown sequence/path/to/missing/file (choose from: binary binary-
> arch binary-indep build build-arch build-indep clean install install-arch
> install-indep)
> 
> 
> for example, in your debian/rules, at the top, put
> 
> -include /path/to/missing/file
> 
> then, run dpkg-buildpackage

This seems like an issue with debhelper, if at all. As
dpkg-buildpackage does not call dh directly, debian/rules does.
Reassigning.

Thanks,
Guillem

Bug#1019688: unace FTCBFS: uses the build architecture compiler

[Guillem Jover]

Hi!

On Sun, 2022-09-11 at 12:29:41 +0200, Helmut Grohne wrote:
> Source: unace
> Version: 1.2b-21
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs

> your -21 upload broke cross building by adding CC=$(CC) without
> initializing $(CC) properly. As far as I understand it, you deliberately
> added it to override the upstream choice (e.g. for supporting clang
> builds). Unfortunately, you failed to add proper initialization.
> Possibly, you thought that buildtools.mk was part of default.mk so that
> was sufficient, but it is not as of today.

Cannot recall what was the train of thought there TBH. :/

> Please either include it or
> change default.mk in dpkg. I'm attaching a patch for the former for your
> convenience.

I'm afraid the builtools.mk was not added to default.mk on purpose, to
avoid breakage. I've now added this commit to the dpkg-build-api
branch and to the spec on the wiki:

  
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/perl-Dpkg-BuildAPI=cddecf191ed4c50536b625e4e370d733b083bf54

In any case, thanks! I've merged your patch and I'm uploading a fixed
package right away.

[ Would be nice to have cross building status on DDPO or the UDD
  dashboard, as that's the main reason I've missed this. :/ ]

Regards,
Guillem

Bug#1019320: openvpn: Prints warnings due to obsolescent egrep usage

[Guillem Jover]

Hi!

On Wed, 2022-09-07 at 12:25:02 +0200, Guillem Jover wrote:
> Source: openvpn
> Source-Version: 2.6.0~git20220818-1
> Severity: normal

> With the recent grep 2.8 release, egrep usage, which has been slated
> for removal for a long time, now generates warnings, such as:
> 
>   egrep: warning: egrep is obsolescent; using grep -E
> 
> When checking the /etc on my systems, I noticed openvpn uses egrep
> at least on its init script (checking the source it also does on its
> test suite).

If reporting upstream or fixing locally, please also notice the fgrep
usage in the test suite.

Thanks,
Guillem

Bug#1019322: pcscd: Prints warnings due to obsolescent egrep usage

[Guillem Jover]

Package: pcscd
Version: 1.9.8-1
Severity: normal

Hi!

With the recent grep 2.8 release, egrep usage, which has been slated
for removal for a long time, now generates warnings, such as:

  egrep: warning: egrep is obsolescent; using grep -E

When checking the /etc on my systems, I noticed pcscd uses egrep
at least on its init script (checking the source seems that's the only
relevant instance).

Thanks,
Guillem

Bug#1019320: openvpn: Prints warnings due to obsolescent egrep usage

[Guillem Jover]

Source: openvpn
Source-Version: 2.6.0~git20220818-1
Severity: normal

Hi!

With the recent grep 2.8 release, egrep usage, which has been slated
for removal for a long time, now generates warnings, such as:

  egrep: warning: egrep is obsolescent; using grep -E

When checking the /etc on my systems, I noticed openvpn uses egrep
at least on its init script (checking the source it also does on its
test suite).

Thanks,
Guillem

Bug#1019319: etckeeper: Prints warnings due to obsolescent egrep usage

[Guillem Jover]

Source: etckeeper
Source-Version: 1.18.17-1
Severity: normal
Tags: upstream patch

Hi!

With the recent grep 2.8 release, egrep usage, which has been slated
for removal for a long time, now generates warnings, such as:

  egrep: warning: egrep is obsolescent; using grep -E

This causes unintended output on etckeeper usage. I'm attaching a
patch that should fix those. I've not touched the doc/todo/ items.

Thanks,
Guillem
From b5ba219b124d415af78cb4bb3d17ca2ec199e03c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Wed, 7 Sep 2022 12:08:00 +0200
Subject: [PATCH] =?UTF-8?q?Use=20=C2=ABgrep=20-E=C2=BB=20instead=20of=20ob?=
 =?UTF-8?q?solescent=20=C2=ABegrep=C2=BB?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The grep 2.8 release generates warnings when invoking egrep, such as:

  egrep: warning: egrep is obsolescent; using grep -E

as it is slated for removal in a later release.
---
 etckeeper | 4 ++--
 list-installed.d/50list-installed | 2 +-
 post-install.d/50vcs-commit   | 4 ++--
 pre-commit.d/20warn-problem-files | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/etckeeper b/etckeeper
index 0085eee..6de4754 100755
--- a/etckeeper
+++ b/etckeeper
@@ -84,7 +84,7 @@ elif [ "$command" = "pre-apt" ]; then
 	command=pre-install
 fi
 
-if echo "$command" | LANG=C egrep -q '[^-a-z_]'; then
+if echo "$command" | LANG=C grep -E -q '[^-a-z_]'; then
 	echo "etckeeper: invalid command $command" >&2
 	exit 1
 fi
@@ -142,7 +142,7 @@ else
 	# fallback if perl isn't present
 	for script in $ETCKEEPER_CONF_DIR/$command.d/*; do
 		if [ ! -d "$script" -a -x "$script" ]; then
-			echo "$script" | egrep -q "/[-a-zA-Z0-9]+$"
+			echo "$script" | grep -E -q "/[-a-zA-Z0-9]+$"
 			[ $? -eq 0 ] && "$script" "$@"
 		fi
 	done
diff --git a/list-installed.d/50list-installed b/list-installed.d/50list-installed
index 3b2ff6f..0551af4 100755
--- a/list-installed.d/50list-installed
+++ b/list-installed.d/50list-installed
@@ -17,7 +17,7 @@ else
 	# format "package version\n" (or something similar).
 	if [ "$LOWLEVEL_PACKAGE_MANAGER" = dpkg ]; then
 		dpkg-query -W -f '${Status}\t${Package} ${Version} ${Architecture}\n' | \
-			egrep '(ok installed|ok config-files)' | cut -f2,3
+			grep -E '(ok installed|ok config-files)' | cut -f2,3
 	elif [ "$LOWLEVEL_PACKAGE_MANAGER" = rpm ]; then
 		rpm -qa --qf "%|epoch?{%{epoch}}:{0}|:%{name}-%{version}-%{release}.%{arch}\n" | sort
 	elif [ "$LOWLEVEL_PACKAGE_MANAGER" = pacman ]; then
diff --git a/post-install.d/50vcs-commit b/post-install.d/50vcs-commit
index e8fa4fc..11657af 100755
--- a/post-install.d/50vcs-commit
+++ b/post-install.d/50vcs-commit
@@ -66,7 +66,7 @@ if etckeeper unclean; then
 			get_changed_packages | sort | uniq > $pl.found-pkgs
 			if [ -s $pl.found-pkgs ]; then
 sed -i 's/^/^[-+]/;s/$/ /' $pl.found-pkgs
-etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | egrep '^[-+]' | grep -f $pl.found-pkgs > $pl.found-packages
+etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | grep -E '^[-+]' | grep -f $pl.found-pkgs > $pl.found-packages
 if [ -s $pl.found-packages ]; then
 	echo "Packages with configuration changes:"
 	cat $pl.found-packages || true
@@ -74,7 +74,7 @@ if etckeeper unclean; then
 fi
 			fi
 			echo "Package changes:"
-			etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | egrep '^[-+]' || true
+			etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | grep -E '^[-+]' || true
 		) | etckeeper commit --stdin
 	else
 		etckeeper commit "$(printf "$message")"
diff --git a/pre-commit.d/20warn-problem-files b/pre-commit.d/20warn-problem-files
index 6bd5c2b..43320e4 100755
--- a/pre-commit.d/20warn-problem-files
+++ b/pre-commit.d/20warn-problem-files
@@ -2,7 +2,7 @@
 set -e
 
 exclude_internal () {
-	egrep -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
+	grep -E -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
 }
 
 if [ "$VCS" = bzr ] || [ "$VCS" = darcs ]; then
-- 
2.37.2

Bug#1018978: sway: Switch from policykit-1 to polkitd

[Guillem Jover]

Package: sway
Version: 1.7-3
Severity: wishlist

Hi!

The policykit-1 package has been split into polkitd and pkexec as
there's been concerns about attack surface when having pkexec around.
Given that sway seems to only require polkitd, it would be nice if the
dependency got switched to allow for a lighter installation.

Thanks,
Guillem

Bug#919697: arcanist: file conflict with arc

[Guillem Jover]

Control: reassign -1 arcanist

Hi!

On Fri, 2022-09-02 at 07:46:43 +0200, Sylvestre Ledru wrote:
> Le 02/09/2022 à 01:10, Guillem Jover a écrit :
> > So we have reached the point at which arc is getting autoremoved from
> > testing as the RC is still filed against it too. :(
> > 
> > Could some arcanist maintainer please check this, and ideally agree to
> > reassign this bug to arcanist? If necessary I'm willing to prepare a
> > patch for arcanist to stop installing as bin/arc, as described above,
> > if this would expedite things.

> However, as:
> * phabricator is dying
> * Richard, Christoph and myself didn't show a strong interest to keep
> it alive (it is currently broken in unstable).
> 
> Please do what you want. ;)

Thanks! Much appreciated, I've reassigned it now with this mail!

On Fri, 2022-09-02 at 12:12:06 +0200, Christoph Biedl wrote:
> Sylvestre Ledru wrote...
> > I don't think renaming is the right approach against an MS-DOS
> > software (and I still think that Debian's policy is too binary for
> > this).
> 
> As there is a very small chance users would want to install *both*
> packages, can't we just resolve this with a Breaks: on both sides, or
> anything else that prevents co-installation from happening?

See Adrian's reply.

> Else I think for the various reasons it's indeed the arcanist package
> that should move. Although I have concerns here since (arcanist's) arc
> program is a command line tool and therefore users will have created
> scripts around it.

> About the policy - I think the idea behind it is right, and colliding
> file names are a problem. Can you think of a better way to handle this?

See my proposal on the previous mail, quoted here for convenience:

> > On Wed, 2022-08-10 at 01:29:27 +0200, Guillem Jover wrote:
> > > Could you please rename the archanist /usr/bin/arc into
> > > /usr/bin/arcanist? Or if that's not feasible, then stop installing the
> > > symlink in PATH, and document that users might want to add the /usr/share
> > > /arcanist/bin/ into their own PATH? Or do both?

I think this would make the program match the package name, and at the
same time make it possible for willing users to simply modify their
pathname or add a symlink say under ~/bin/arc pointing to the actual
program.

I can take a stab at this (as gratitude :), and propose a patch during
the weekend or something, if you want.

Thanks,
Guillem

Bug#919697: arcanist: file conflict with arc

[Guillem Jover]

Hi!

On Wed, 2022-08-10 at 01:29:27 +0200, Guillem Jover wrote:
> [ The bug has been (correctly) bumped back to serious. Sorry that I
>   have not engaged about this bug in the past, but the reply to simply
>   ignore policy looked rather off-putting, I just noticed the reply
>   below, which seemed encouraging! :) ]
> 
> On Sat, 2019-01-26 at 11:20:13 +0100, Sylvestre Ledru wrote:
> > As we shipped the previous release with this bug, we are close to
> > the freeze and there is not easy fix,
> > I propose that we fix this issue for the next stable release.
> 
> Could you please rename the archanist /usr/bin/arc into
> /usr/bin/arcanist? Or if that's not feasible, then stop installing the
> symlink in PATH, and document that users might want to add the /usr/share
> /arcanist/bin/ into their own PATH? Or do both?
> 
> Renaming the binary from the arc package, which matches the package
> name itself, seems unfair, as it has existed upstream and has been in
> the Debian archive for way way longer, and in addition the idea of
> potentially having a binary package arc with a non-arc program, and
> arcanist providing an arc program seems rather confusing and just
> wrong. :)
> 
> Otherwise, all these package will get removed in the coming days. So I'd
> also appreciate if you could reassign these bugs to arcanist.

So we have reached the point at which arc is getting autoremoved from
testing as the RC is still filed against it too. :(

Could some arcanist maintainer please check this, and ideally agree to
reassign this bug to arcanist? If necessary I'm willing to prepare a
patch for arcanist to stop installing as bin/arc, as described above,
if this would expedite things.

Thanks,
Guillem

Bug#1018857: bullseye-pu: package dpkg/1.20.12

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]

This update backports multiple fixes from unstable for RC bugs and fixes
broken behavior. It makes the dpkg-fsys-usrunmess script more robust,
fixes mishandling of versioned symbols due to output changes in objdump,
fixes the removal-on-upgrade conffile support, and adds support for the
ARC arch. There's also a tiny fix for the Dutch translated man pages.

[ Impact ]

* The dpkg-shlibdeps problem would cause wrong dependency information
  which could lead to programs unable to run-time link due to missing
  symbols.

* The removal-on-upgrade conffile support could end up removing
  pathnames owned by other packages.

* The dpkg-fsys-usrunmess changes make the script more robust, to
  reduce the potential for breakage and avoid known problematic
  scenarios that can leave the system messed up, requiring arduous
  recovery.

* The arc arch porters cannot introduce it properly as the infr runs
  on stable which currently does not know about it.

[ Tests ]

* The fix for dpkg-shlibdeps can be verified by running that version
  on unstable/testing and building cppcheck. (I have pending adding
  a minimal test case into the test suite in git main though.)

* The removal-on-upgrade conffile fix contains functional tests.

* The dpkg-fsys-usrunmess has been run on a merged-/usr system with
  the various conditions and it works as expected.

* The arc arch addition is trivial, but still contains some test suite
  coverage.

[ Risks ]

All these fixes have been in unstable/testing for months now, w/ no
reported regressions. The biggest changes are for the
removal-on-upgrade conffile support, but that ends up being more of
moving code around, and the changes to dpkg-fsys-usrunmess. But none
are that big anyway.

[ Checklist ]

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

[ Changes ]

The git log is included in the debdiff, which I'm attaching in its full
compressed form with no filtering applied.

[ Other info ]

None.

Thanks,
Guillem


dpkg-1.20.11-1.20.12.debdiff.xz
Description: application/xz

Bug#1018854: buster-pu: package dpkg/1.19.9

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]

This update fixes the same regression (introduced in the security fix
in dpkg 1.19.8) that was fixed in bullseye for dpkg 1.20.11 (#1014206).

[ Impact ]

This introduced a regression when unpacking source packages.

[ Tests ]

As lintian does not appear to have had the failing test there, I did
the following quick verification:

  - Download a source package.
  - Unpack the orig tarball.
  - Remove all write permissions from all files.
  - Repack and amend the .dsc
  - Unpacking with dpkg-source -x does not work in buster, works with
the fixed package.

(And I'll be adding a functional test in dpkg 1.21.x to cover this…)

[ Risks ]

The code has been in unstable, bookworm and bullseye for a while. The
patch applied cleanly, and it's minimal.

[ Checklist ]

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

[ Changes ]

The git log is included in the debdiff, which I'm attaching in its full
compressed form with no filtering applied.

[ Other info ]

None.

Thanks,
Guillem
diff -Nru dpkg-1.19.8/.dist-version dpkg-1.19.9/.dist-version
--- dpkg-1.19.8/.dist-version   2022-05-24 13:40:09.0 +0200
+++ dpkg-1.19.9/.dist-version   2022-09-01 03:40:03.0 +0200
@@ -1 +1 @@
-1.19.8
+1.19.9
diff -Nru dpkg-1.19.8/ChangeLog dpkg-1.19.9/ChangeLog
--- dpkg-1.19.8/ChangeLog   2022-05-24 13:40:09.0 +0200
+++ dpkg-1.19.9/ChangeLog   2022-09-01 03:40:03.0 +0200
@@ -1,3 +1,137 @@
+commit e2254431dca4eccb5125c21cb7299090e6725b3a
+Author: Guillem Jover 
+Date:   Thu Sep 1 03:43:20 2022 +0200
+
+Release 1.19.9
+
+ debian/changelog | 8 +---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+commit e1e6c85841778630facbefa1b8ed928668283d79
+Author: Guillem Jover 
+Date:   Thu Sep 1 03:40:03 2022 +0200
+
+po: Regenerate .pot files and merge .po files with them
+
+ dselect/po/bs.po| 2 +-
+ dselect/po/ca.po| 2 +-
+ dselect/po/cs.po| 2 +-
+ dselect/po/da.po| 2 +-
+ dselect/po/de.po| 2 +-
+ dselect/po/dselect.pot  | 4 ++--
+ dselect/po/el.po| 2 +-
+ dselect/po/es.po| 2 +-
+ dselect/po/et.po| 2 +-
+ dselect/po/eu.po| 2 +-
+ dselect/po/fr.po| 2 +-
+ dselect/po/gl.po| 2 +-
+ dselect/po/hu.po| 2 +-
+ dselect/po/id.po| 2 +-
+ dselect/po/it.po| 2 +-
+ dselect/po/ja.po| 2 +-
+ dselect/po/ko.po| 2 +-
+ dselect/po/nb.po| 2 +-
+ dselect/po/nl.po| 2 +-
+ dselect/po/nn.po| 2 +-
+ dselect/po/pl.po| 2 +-
+ dselect/po/pt.po| 2 +-
+ dselect/po/pt_BR.po | 2 +-
+ dselect/po/ro.po| 2 +-
+ dselect/po/ru.po| 2 +-
+ dselect/po/sk.po| 2 +-
+ dselect/po/sv.po| 2 +-
+ dselect/po/tl.po| 2 +-
+ dselect/po/vi.po| 2 +-
+ dselect/po/zh_CN.po | 2 +-
+ dselect/po/zh_TW.po | 2 +-
+ man/po/dpkg-man.pot | 4 ++--
+ po/ast.po   | 2 +-
+ po/bs.po| 2 +-
+ po/ca.po| 2 +-
+ po/cs.po| 2 +-
+ po/da.po| 2 +-
+ po/de.po| 2 +-
+ po/dpkg.pot | 4 ++--
+ po/dz.po| 2 +-
+ po/el.po| 2 +-
+ po/eo.po| 2 +-
+ po/es.po| 2 +-
+ po/et.po| 2 +-
+ po/eu.po| 2 +-
+ po/fr.po| 2 +-
+ po/gl.po| 2 +-
+ po/hu.po| 2 +-
+ po/id.po| 2 +-
+ po/it.po| 2 +-
+ po/ja.po| 2 +-
+ po/km.po| 2 +-
+ po/ko.po| 2 +-
+ po/ku.po| 2 +-
+ po/lt.po| 2 +-
+ po/mr.po| 2 +-
+ po/nb.po| 2 +-
+ po/ne.po| 2 +-
+ po/nl.po| 2 +-
+ po/nn.po| 2 +-
+ po/pa.po| 2 +-
+ po/pl.po| 2 +-
+ po/pt.po| 2 +-
+ po/pt_BR.po | 2 +-
+ po/ro.po| 2 +-
+ po/ru.po| 2 +-
+ po/sk.po| 2 +-
+ po/sv.po| 2 +-
+ po/th.po| 2 +-
+ po/tl.po| 2 +-
+ po/tr.po| 2 +-
+ po/vi.po| 2 +-
+ po/zh_CN.po | 2 +-
+ po/zh_TW.po | 2 +-
+ scripts/po/ca.po| 2 +-
+ scripts/po/de.po| 2 +-
+ scripts/po/dpkg-dev.pot | 4 ++--
+ scripts/po/es.po| 2 +-
+ scripts/po/fr.po| 2 +-
+ scripts/po/pl.po| 2 +-
+ scripts/po/ru.po| 2 +-
+ scripts/po/sv.po| 2 +-
+ 82 files changed, 86 insertions(+), 86 deletions(-)
+
+commit d0f3775a0334261b793acc87c56146df7bb3fc66
+Author: Guillem Jover 
+Date:   Sat Jun 4 05:48:21 2022 +0200

Bug#1018800: buster-pu: package inetutils/2:1.9.4-7+deb10u2

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

Hi!

This is the counterpart to #1018744 but for buster.

[ Reason ]

This fixes three pending security issue, that the security team (CCed)
would prefer to see handled as normal oldstable updates.

(This is the same set of changes as the bullseye version, plus a couple
of patches from upstream for CVE-2019-0053, that are missing in that
version.)

[ Impact ]

All changes are security related, mostly buffer overflows, that can at
least cause crashes and DoS.

[ Tests ]

The same tests as the ones for bullseye in #1018744 were used here and
the issues could be reproduced before, and not any more after the
patched version.

[ Risks ]

Same risks as the version for bullseye.

[ Checklist ]

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

[ Changes ]

  * Security fixes for telnet client:
- Validate supplied environment variables.
- Check for buffer overflows when processing telnet protocol messages.
- Add checks for option reply parsing limits causing buffer
  overflow induced crashes due to long option values.
- Fix infinite loop causing a stack exhaustion induced crash due to
  malicious server commands.
Fixes CVE-2019-0053. Closes: #945861
  * Fix inetutils-ftp security bug trusting FTP PASV responses.
Fixes CVE-2021-40491. Closes: #993476
  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
adapted by Erik Auerswald .
Fixes CVE-2022-39028.

[ Other info ]

None.

Thanks,
Guillem
diff -Nru inetutils-1.9.4/debian/changelog inetutils-1.9.4/debian/changelog
--- inetutils-1.9.4/debian/changelog2020-09-18 20:06:42.0 +0200
+++ inetutils-1.9.4/debian/changelog2022-08-31 00:58:35.0 +0200
@@ -1,3 +1,23 @@
+inetutils (2:1.9.4-7+deb10u2) buster; urgency=medium
+
+  * Security fixes for telnet client:
+- Validate supplied environment variables.
+- Check for buffer overflows when processing telnet protocol messages.
+- Add checks for option reply parsing limits causing buffer
+  overflow induced crashes due to long option values.
+- Fix infinite loop causing a stack exhaustion induced crash due to
+  malicious server commands.
+Fixes CVE-2019-0053. Closes: #945861
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+Fixes CVE-2022-39028.
+
+ -- Guillem Jover   Wed, 31 Aug 2022 00:58:35 +0200
+
 inetutils (2:1.9.4-7+deb10u1) buster; urgency=medium
 
   * CVE-2020-10188 (Closes: #956084)
diff -Nru 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
  1970-01-01 01:00:00.0 +0100
+++ 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
  2022-08-31 00:58:35.0 +0200
@@ -0,0 +1,54 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c |   21 +
+ 1 file changed, 21 insertions(+)
+
+--- a/ftp/ftp.c
 b/ftp/ftp.c
+@@ -1357,6 +1357,13 @@ initconn (void)
+ uint32_t *pu32 = (uint32_t *) _addr_sa4->sin_addr.s_addr;
+ pu32[0] = htonl ( (h[0] << 24) | (h[1] << 16) | (h[2] << 8) | 
h[3]);
+   }
++  if (data_addr_sa4->sin_addr.s_addr
++  != ((struct sockaddr_in *) )->sin_addr.s_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv4 */
+ else /* IPv6 */
+   {
+@@ -1387,6 +1394,13 @@ initconn (void)
+ pu32[2] = htonl ( (h[8] << 24) | (h[9] << 16) | (h[10] << 8) 
| h[11]);
+ pu32[3] = htonl ( (h[12] << 24) | (h[13] << 16) | (h[14] << 
8) | h[15]);
+   }
++

Bug#1018744: bullseye-pu: package inetutils/2:2.0-1+deb11u1

[Guillem Jover]

Hi!

Sorry, I'm updating the request as I found missing stuff while
preparing the companion update for buster!

On Tue, 2022-08-30 at 00:37:03 +0200, Guillem Jover wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: t...@security.debian.org

> [ Reason ]
> 
> A recent vulnerability (DoS) was reported upstream, for which I
> uploaded a fixed package to sid (will migrate tomorrow). There was a
> (minor) pending security update missing from bullseye. The security
> team (CCed) would prefer to see these handled as normal stable updates.

I'm adding a couple of patches to solve lingering buffer overflow issues
from #945861 and CVE-2019-0053.

> [ Impact ]
> 
> These are both security issues. One against malicious ftp servers
> which can end up controlling the client to connect to other hosts,
> the other a DoS on the telnetd server which makes it crash with
> specific two-byte payloads.

The additional patches are buffer overflows.

> [ Tests ]
> 
> For the ftp client, there's a test recipe at
> <https://lists.gnu.org/archive/html/bug-inetutils/2021-06/msg2.html>.
> 
> For the telnetd server there's a test recipe at
> <https://lists.gnu.org/archive/html/bug-inetutils/2022-08/msg3.html>
> which amounts to «printf "\xff\xf7" | nc -n -v localhost 23».

The two new patches fix the following reproducers:

  $ DISPLAY=`perl -e 'print Ax"5"'` telnet -l`perl -e 'print "A"x5000'` 
localhost

and

  
https://raw.githubusercontent.com/hackerhouse-opensource/exploits/master/telnet_term_0day.py

> Both test recipes could be reproduced before, and do not work after
> the patched version.

> [ Risks ]
> 
> The fix for the ftp client has been in sid since 2021-09 with no
> reported regressions.
> 
> The fix for telnetd has not yet migrated to testing, but is few lines
> long fixing a couple of NULL pointer dereferences.

Both new fixes have been part of sid/testing for a while now.

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

  * telnet: Add checks for option reply parsing limits causing buffer
overflow induced crashes due to long option values.
Fixes CVE-2019-0053. Closes: #945861
  * Add patch from upstream to fix infinite loop causing a stack exhaustion
induced crash in telnet client due to malicious server commands.
Closes: #945861
>   * Fix inetutils-ftp security bug trusting FTP PASV responses.
> Fixes CVE-2021-40491. Closes: #993476
>   * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
> a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
> or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
> adapted by Erik Auerswald .

> [ Other info ]
> 
> None.

I'm attaching the refreshed debdiff.

Thanks,
Guillem
diff -Nru inetutils-2.0/debian/changelog inetutils-2.0/debian/changelog
--- inetutils-2.0/debian/changelog  2021-02-05 23:14:20.0 +0100
+++ inetutils-2.0/debian/changelog  2022-08-30 13:34:41.0 +0200
@@ -1,3 +1,21 @@
+inetutils (2:2.0-1+deb11u1) bullseye; urgency=medium
+
+  * telnet: Add checks for option reply parsing limits causing buffer
+overflow induced crashes due to long option values.
+Fixes CVE-2019-0053. Closes: #945861
+  * Add patch from upstream to fix infinite loop causing a stack exhaustion
+induced crash in telnet client due to malicious server commands.
+Closes: #945861
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+Fixes CVE-2022-39028.
+
+ -- Guillem Jover   Tue, 30 Aug 2022 13:34:41 +0200
+
 inetutils (2:2.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
2022-08-30 13:33:33.0 +0200
@@ -0,0 +1,59 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] 

Bug#1018744: bullseye-pu: package inetutils/2:2.0-1+deb11u1

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

Hi!

[ Reason ]

A recent vulnerability (DoS) was reported upstream, for which I
uploaded a fixed package to sid (will migrate tomorrow). There was a
(minor) pending security update missing from bullseye. The security
team (CCed) would prefer to see these handled as normal stable updates.

[ Impact ]

These are both security issues. One against malicious ftp servers
which can end up controlling the client to connect to other hosts,
the other a DoS on the telnetd server which makes it crash with
specific two-byte payloads.

[ Tests ]

For the ftp client, there's a test recipe at
<https://lists.gnu.org/archive/html/bug-inetutils/2021-06/msg2.html>.

For the telnetd server there's a test recipe at
<https://lists.gnu.org/archive/html/bug-inetutils/2022-08/msg3.html>
which amounts to «printf "\xff\xf7" | nc -n -v localhost 23».

Both test recipes could be reproduced before, and do not work after
the patched version.

[ Risks ]

The fix for the ftp client has been in sid since 2021-09 with no
reported regressions.

The fix for telnetd has not yet migrated to testing, but is few lines
long fixing a couple of NULL pointer dereferences.

[ Checklist ]

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

[ Changes ]

  * Fix inetutils-ftp security bug trusting FTP PASV responses.
Fixes CVE-2021-40491. Closes: #993476
  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
adapted by Erik Auerswald .

[ Other info ]

None.

Thanks.
Guillem
diff -Nru inetutils-2.0/debian/changelog inetutils-2.0/debian/changelog
--- inetutils-2.0/debian/changelog  2021-02-05 23:14:20.0 +0100
+++ inetutils-2.0/debian/changelog  2022-08-28 16:01:41.0 +0200
@@ -1,3 +1,14 @@
+inetutils (2:2.0-1+deb11u1) bullseye; urgency=medium
+
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+
+ -- Guillem Jover   Sun, 28 Aug 2022 16:01:41 +0200
+
 inetutils (2:2.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
2022-08-28 16:01:41.0 +0200
@@ -0,0 +1,59 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c | 21 +
+ 2 files changed, 30 insertions(+)
+
+diff --git a/ftp/ftp.c b/ftp/ftp.c
+index d21dbdd8..7513539d 100644
+--- a/ftp/ftp.c
 b/ftp/ftp.c
+@@ -1365,6 +1365,13 @@ initconn (void)
+ uint32_t *pu32 = (uint32_t *) _addr_sa4->sin_addr.s_addr;
+ pu32[0] = htonl ( (h[0] << 24) | (h[1] << 16) | (h[2] << 8) | 
h[3]);
+   }
++  if (data_addr_sa4->sin_addr.s_addr
++  != ((struct sockaddr_in *) )->sin_addr.s_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv4 */
+ else /* IPv6 */
+   {
+@@ -1395,6 +1402,13 @@ initconn (void)
+ pu32[2] = htonl ( (h[8] << 24) | (h[9] << 16) | (h[10] << 8) 
| h[11]);
+ pu32[3] = htonl ( (h[12] << 24) | (h[13] << 16) | (h[14] << 
8) | h[15]);
+   }
++  if (data_addr_sa6->sin6_addr.s6_addr
++  != ((struct sockaddr_in6 *) )->sin6_addr.s6_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv6 */
+   

Bug#1017632: lintian: False positive on partial match for bin-sbin-mismatch

[Guillem Jover]

On Mon, 2022-08-22 at 09:59:34 +0200, Axel Beckert wrote:
> Guillem Jover wrote:
> > The bin-sbin-mismatch triggers false positives on partial matches such
> > as /usr/bin/dpkg-www and /usr/sbin/dpkg-www-installer, or
> > /usr/bin/dpkg and /usr/sbin/dpkg-fsys-usrunmess.
> 
> Urgs. Thanks! Nice catch!

> > This is due to the check in lib/Lintian/Check/Files/Contents.pm, where
> > it essentially does the following:
> > 
> >   perl -E '$str = "/bin/dpkg-www-installer"; \
> >say "wrong-match" if $str =~ m{\B/\Qbin/dpkg-www\E\b}x'
> > 
> > I've got false-positives in dpkg and dpkg-www.
> 
> So that last \b should be a $, right?

I don't think so, as I think the intention of the code is to find such
instances anywhere in a line, say in pseudo-lines:

  «^variable = "/usr/sbin/dpkg-www-installer"$»

or in documentation?

  «^This does blah via /usr/sbin/dpkg-www-installer and something other.$»

Thanks,
Guillem

Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11

[Guillem Jover]

Control: reassign -1 linux
Control: affects -1 liburing debci

Hi!

It seems like there was a regression with the latest stable update
that affects the autopkgtest for liburing. Reassigning.

On Mon, 2022-07-18 at 21:07:28 +0200, Paul Gevers wrote:
> Source: liburing
> Version: 2.1-2
> Severity: important
> X-Debbugs-Cc: br...@ubuntu.com

> Some days ago (approximately 7) the autopkgtest of liburing started to
> behave badly on the Debian and Ubuntu infrastructure. It's not totally
> clear to me what happens, but I have lxc containers left behind after
> the test that I can't clean up.
> 
> A similar thing seems to happen on the Ubuntu side because they have
> blocked the test from running recently and I'll do the same on our
> side.
> 
> https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/commit/?id=fedf747ea808837217d373773d105f242819702d
> 
> Because your package didn't change in that time, I suspect one of your
> dependencies caused liburing to behave differently. It would be great
> if we figured out what that is.

Thanks,
Guillem

Bug#1017769: man-db: Uses setpriv which seems to be Linux-only

[Guillem Jover]

On Sat, 2022-08-20 at 00:44:17 +0100, Colin Watson wrote:
> On Sat, Aug 20, 2022 at 01:35:54AM +0200, Guillem Jover wrote:
> > The man-db package seems to have switched from start-stop-daemon to
> > setpriv, but the latter seems to be Linux-only. On a hurd-i386 box I
> > see the following now:
> > 
> >   Processing triggers for man-db (2.10.2-2) ...
> >   /var/lib/dpkg/info/man-db.postinst: 22: setpriv: not found
> 
> Bother.  Do you know of a portable replacement, or do I have to add a
> fallback to perl?  I was hoping to avoid the latter, especially since
> setpriv is clearly simpler.

I was checking man-db packaging history and it was not clear to me why
start-stop-daemon was switched to the perl code. I don't understand
why s-s-d would not be available during debootstrap (didn't fine a
commit with the change, as it seemed to be included as part of a merge
commit, and just the changelog entry)?

Thanks,
Guillem