Bug#1068809: dh-buildinfo: consider deprecating and removing the package

[Helmut Grohne]

Package: dh-buildinfo
Version: 0.11+nmu3
X-Debbugs-Cc: ***@debian.org

Hi,

dh-buildinfo much predates the reproducible builds effort and the
.buildinfo file and probably laid ground to it. I am now raising the
question whether it is time to get rid of dh-buildinfo in Debian.

Essentially I am arguing that the use case of dh-buildinfo is now served
by dpkg-genbuildinfo and the generated .buildinfo files on every package
build. Besides the difference in formatting, the main difference is that
dh-buildinfo embeds this information into the binary package rather than
next to it (where it can be lost). I argue that all of the uses of
dh-buildinfo can now be met with examining .buildinfo files.

At the same time, dh-genbuildinfo reduces reproducibility. When cross
building a package, we necessarily install different packages from a
native build. This difference manifests in the embedded buildinfo files
and thus comparing a natively built package with a cross built package
needs to ignore the embedded buildinfo file where we would like cross
builds to exactly reproduce native builds where possible.

As such I am proposing to call dh-buildinfo deprecated, then to actively
remove dependencies on it and finally remove it from Debian.

If you agree with this vision, please tag this bug confirmed. If you
disagree with this vision, please tag it wontfix and explain the added
value that I fail to see.

Thank you

Helmut

[Andreas Tille]

Hi Alastair,

thanks a lot for maintaining the ECMWF software stack in Debian.

Today dh-buildinfo appeared as a candidate for the Bug of the Day[1].
In bug #1068809 the reporter suggested to "consider deprecating and
removing the package". For me the reasons are perfectly valid and
thus I checked the rdepends of this package. I wonder whether you
might like to remove dh-buildinfo from ecbuild (Build-)Depends to
enable the removal of this package.

Kind regards
Andreas.

[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks#bug-of-the-day
[2] https://bugs.debian.org/1068809

[Holger Levsen]

Hi Andreas,

Post by Andreas Tille
Today dh-buildinfo appeared as a candidate for the Bug of the Day[1].
In bug #1068809 the reporter suggested to "consider deprecating and
removing the package". For me the reasons are perfectly valid and
thus I checked the rdepends of this package. I wonder whether you
might like to remove dh-buildinfo from ecbuild (Build-)Depends to
enable the removal of this package.

YES. :)

I've NMUed cdbs already last Sunday and dropped all occurances of
dh-buildinfo from it, so today there are only 3 packages left,
which depend on dh-buildinfo:
- ecbuild
- haskell-devscripts
- debian-multimedia

I do intend to file bugs against those and then NMU as needed to,
and then ask for the removal of dh-buildinfo from unstable.

#1088144 has some more background info and most importantly,
dpkg since 2016 creates .buildinfo files for *all* packages,
while dh-buildinfo is used by only 5% of the archive (mostly
haskell packages and those using cdbs).

I'd like to have dh-buildinfo removed from the archive by the
end of this year.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

It started as a virus and has mutated into an IQ test.

[Alexandre Detiste]

Don't forget the 311 build-depends ...

$ reverse-depends -l -b dh-buildinfo | wc -l
311

These would need a MBF ?

Greetings

Post by Holger Levsen
Hi Andreas,
YES. :)
I've NMUed cdbs already last Sunday and dropped all occurances of
dh-buildinfo from it, so today there are only 3 packages left,
- ecbuild
- haskell-devscripts
- debian-multimedia
I do intend to file bugs against those and then NMU as needed to,
and then ask for the removal of dh-buildinfo from unstable.
#1088144 has some more background info and most importantly,
dpkg since 2016 creates .buildinfo files for *all* packages,
while dh-buildinfo is used by only 5% of the archive (mostly
haskell packages and those using cdbs).
I'd like to have dh-buildinfo removed from the archive by the
end of this year.

[Holger Levsen]

Post by Alexandre Detiste
Don't forget the 311 build-depends ...
$ reverse-depends -l -b dh-buildinfo | wc -l
311

so /usr/bin/reverse-depends was the tool I was looking for, thank you!
I've now installed ubuntu-dev-tools...

Post by Alexandre Detiste
These would need a MBF ?

yes, sigh & thanks. If we only had removed dh-buildinfo in 2017...
(I tentatively plan to announce this mass bug filing as needed
on debian-devel@ though I'd be very happy if someone else would do it!)
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Make lying wrong again.

[Bill Allombert]

Post by Holger Levsen

Post by Alexandre Detiste
Don't forget the 311 build-depends ...
$ reverse-depends -l -b dh-buildinfo | wc -l
311

so /usr/bin/reverse-depends was the tool I was looking for, thank you!
I've now installed ubuntu-dev-tools...

Post by Alexandre Detiste
These would need a MBF ?

yes, sigh & thanks. If we only had removed dh-buildinfo in 2017...
(I tentatively plan to announce this mass bug filing as needed

Upload a version of dh_buildinfo that does nothing be output a warning
'warning: db_buildinfo is obsolete, please remove from Build-Depends'.
This would gives time to maintainers to fix the issue before a MBF.
Add a lintian warning if there is none already ?

Cheers,

[Holger Levsen]

Post by Bill Allombert
Upload a version of dh_buildinfo that does nothing be output a warning
'warning: db_buildinfo is obsolete, please remove from Build-Depends'.

I certainly wouldn't mind anyone doing this.

(I also doubt many people would see and act on this warning. dh-buildinfo
was practially useless the last 8 years and noone noticed or acted.)

Post by Bill Allombert
This would gives time to maintainers to fix the issue before a MBF.

And whats the real benefit of this? I mean, MBF is a mass bug filing,
and yeah, a package would receive one less bug report. (Which I see as a
small benefit, but not a real benefit, which would block *me* from
filing 311 bugs now^wsoon.)

Post by Bill Allombert
Add a lintian warning if there is none already ?

I'd applaud that.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Make earth cool again.

[Alexandre Detiste]

Maybe the usual ddlist posting on debian-devel + draft of MBF wording;
some people are very quick and will fix anything they can on the very same day;
and then MBF in a few days. (with severity = ?)

I fixed 5 packages just now.

Post by Holger Levsen
I certainly wouldn't mind anyone doing this.
(I also doubt many people would see and act on this warning. dh-buildinfo
was practially useless the last 8 years and noone noticed or acted.)

Post by Bill Allombert
This would gives time to maintainers to fix the issue before a MBF.

And whats the real benefit of this? I mean, MBF is a mass bug filing,
and yeah, a package would receive one less bug report. (Which I see as a
small benefit, but not a real benefit, which would block *me* from
filing 311 bugs now^wsoon.)

[Santiago Vila]

[ trimming non-lists from Cc ]

Hi.

I'll note that from the 300 packages affected, around 150 are maintained by Jonas.

Please be nice with maintainers. Making dh-buildinfo a no-op
(or "defusing" it as Chris has worded it) seems a natural
first step.

Next would come lintian and lintian-brush.

Thanks.

[Chris Hofstaedtler]

Post by Holger Levsen

Post by Bill Allombert
Upload a version of dh_buildinfo that does nothing be output a warning
'warning: db_buildinfo is obsolete, please remove from Build-Depends'.

I certainly wouldn't mind anyone doing this.
(I also doubt many people would see and act on this warning. dh-buildinfo
was practially useless the last 8 years and noone noticed or acted.)

Post by Bill Allombert
This would gives time to maintainers to fix the issue before a MBF.

And whats the real benefit of this?

IIRC you said in some other thread that dh-buildinfo is causing you
issues. If that is the case (= if I'm not misremembering), an upload
that "defuses" dh-buildinfo would immediately solve the issue.

And then maintainers can get to their bugs whenever. Possibly only
when dh-buildinfo actually gets removed from unstable.

So - does dh-buildinfo cause you issues?

Chris

[Alexandre Detiste]

From a quick survey on 10 packages:

- most only need the one line from d/control removed.
-> I think that for those making dh-buildinfo a virtual package
provided by debhelper would be nice

- aflplusplsu needed some more trimming from d/rules.

https://salsa.debian.org/pkg-security-team/aflplusplus/-/commit/a0bd228ff6a96cfe12e52d5582efd9a4b2ee2107

I think a 10% x 300 = 30 FTBFS risk totally acceptable.

Post by Chris Hofstaedtler
IIRC you said in some other thread that dh-buildinfo is causing you
issues. If that is the case (= if I'm not misremembering), an upload
that "defuses" dh-buildinfo would immediately solve the issue.

It would still create the FTBFS issue
if someone wants to call this helper directly ...

Post by Chris Hofstaedtler
And then maintainers can get to their bugs whenever. Possibly only
when dh-buildinfo actually gets removed from unstable.

By past knoweledge FTP Masters will in very most cases
remove a package only after _all_ rdpends are cleared
(they did removed python3-future which was a big nuisance tough)

Greetings

[Holger Levsen]

Post by Chris Hofstaedtler
IIRC you said in some other thread that dh-buildinfo is causing you
issues. If that is the case (= if I'm not misremembering), an upload
that "defuses" dh-buildinfo would immediately solve the issue.
And then maintainers can get to their bugs whenever. Possibly only
when dh-buildinfo actually gets removed from unstable.
So - does dh-buildinfo cause you issues?

yes. several:
- dh-buildinfo makes packages less reproducible as the *current* build
environment is included in the packages. (while not having them stored
inside the packages allows or at least doesn't block 100% identical
rebuilds in a slighlty different build environment.)
- it increases build times, thus ressource usages and often humans wait
for builds.
- it increases installed size, both for the archive as well as on
millions of installations.
- it's not useful at all, as it's only used by 5% of the packages, while 100%
of the packages build with dpkg produce .buildinfo files outside the
packages built.

It's not the greatest bug in the world, yet it is a bug.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

wirklicher reichtum ist nicht privatjet fliegen, sondern sich vor dem schÃŒtzen
können, was privatjet fliegen auslöst." <3 böhmermann am 3.2.23

[Bill Allombert]

Post by Holger Levsen

Post by Chris Hofstaedtler
IIRC you said in some other thread that dh-buildinfo is causing you
issues. If that is the case (= if I'm not misremembering), an upload
that "defuses" dh-buildinfo would immediately solve the issue.
And then maintainers can get to their bugs whenever. Possibly only
when dh-buildinfo actually gets removed from unstable.
So - does dh-buildinfo cause you issues?

- dh-buildinfo makes packages less reproducible as the *current* build
environment is included in the packages. (while not having them stored
inside the packages allows or at least doesn't block 100% identical
rebuilds in a slighlty different build environment.)
- it increases build times, thus ressource usages and often humans wait
for builds.
- it increases installed size, both for the archive as well as on
millions of installations.
- it's not useful at all, as it's only used by 5% of the packages, while 100%
of the packages build with dpkg produce .buildinfo files outside the
packages built.
It's not the greatest bug in the world, yet it is a bug.

Replace dh_buildinfo by a script that just print a warning but does not actually
generate the file, then ask for binNMU ?
Update the description to mention the problem.

Cheers,

[Holger Levsen]

Post by Bill Allombert
Replace dh_buildinfo by a script that just print a warning but does not actually
generate the file, then ask for binNMU ?
Update the description to mention the problem.

why pamper it over if we can fix it?
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Only change is constant.

[Bill Allombert]

Post by Holger Levsen

Post by Bill Allombert
Replace dh_buildinfo by a script that just print a warning but does not actually
generate the file, then ask for binNMU ?
Update the description to mention the problem.

why pamper it over if we can fix it?

Because binNMU are much quicker than NMU, so the issue would be fixed for all packages sooner.
But it seems I am missing something, so sorry for bothering you.

Cheers,

[Santiago Vila]

Post by Holger Levsen

Post by Bill Allombert
Replace dh_buildinfo by a script that just print a warning but does not actually
generate the file, then ask for binNMU ?
Update the description to mention the problem.

why pamper it over if we can fix it?

Because the fix you have in mind involves bothering a lot of people,
or worse, a few people with a lot of work, while the intermediate
status proposed by Bill fixes all the undesired effects you
have listed before.

BTW: I've just built the 311 packages which BD on dh-buildinfo
with a modified dh-buildinfo package which does nothing but
emit a warning and I only found one package which failed to build
that did not failed before, aflplusplus, and that one is already
fixed in salsa, so making dh_buildinfo a no-op in trixie seems
to be safe.

Thanks.

[Holger Levsen]

Post by Santiago Vila
Because the fix you have in mind involves bothering a lot of people,
or worse, a few people with a lot of work, while the intermediate
status proposed by Bill fixes all the undesired effects you
have listed before.

but then I will still want to bother all those people^wpackages
eventually.

that said, I now can see how the no-op dh-buildinfo helps to bother
less people^wpackages, eg. those which then can be fixed with a binNMU.

and first, someone needs to actually make dh-buildinfo do a noop,
which hopefully won't bother it's maintainer too much.

& personally I'm a bit bothered by such much bothering about
fixing stuff properly, because this just needs a trivial change & and
an upload. (or rather, 300 of them.)

debian is not frozen. we can fix things today.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Die Faktenlage bzgl. Klimakatastrophe ist so eindeutig und die Folgen sind so
schwerwiegend, dass Parteien und Organisationen, die immer noch wirksame Maß-
nahmen dagegen behindern, als verbrecherisch einzustufen sind.

[Santiago Vila]

Post by Holger Levsen

Post by Santiago Vila
Because the fix you have in mind involves bothering a lot of people,
or worse, a few people with a lot of work, while the intermediate
status proposed by Bill fixes all the undesired effects you
have listed before.

but then I will still want to bother all those people^wpackages
eventually.

Such process has already started. наб has already reported several
bugs (with severity:normal). Maybe this is not very orthodox without
a MBF email in -devel first, but so be it. I think "normal" is completely ok
at this point.

I hope наб (in CCO) will find the way to tell Jonas about his 150 packages
without filing 150 different bugs.

Post by Holger Levsen
that said, I now can see how the no-op dh-buildinfo helps to bother
less people^wpackages, eg. those which then can be fixed with a binNMU.
and first, someone needs to actually make dh-buildinfo do a noop,
which hopefully won't bother it's maintainer too much.

I've proposed a patch to the maintainer (which you can read in the bug logs).
I hope he accepts it. If someone else can propose a change for the extended
description, that would also help.

Thanks.

[наб]

Post by Holger Levsen

Post by Santiago Vila
Because the fix you have in mind involves bothering a lot of people,
or worse, a few people with a lot of work, while the intermediate
status proposed by Bill fixes all the undesired effects you
have listed before.

but then I will still want to bother all those people^wpackages
eventually.

Such process has already started. Маб has already reported several
bugs (with severity:normal). Maybe this is not very orthodox without
a MBF email in -devel first, but so be it. I think "normal" is completely ok
at this point.

I also opened MRs for all (or close-to-all?) the packages on Salsa that
are on Salsa and can take MRs (and calibre on github).
The bugs were only sent for the packages with no valid VCS
(as a basis for justifying either NMUs or salvaging later).

I hope Маб (in CCO) will find the way to tell Jonas about his 150 packages
without filing 150 different bugs.

I'm not sold on this being the best approach either way.

out of the 313 build-deps on dh-buildinfo 226 are in topic teams,
going by the VCS fields (128 perl + 5 python + 19 science +
27 js + 45 multimedia + 2 haskell) and 30 more in collab-maint/debian,
so one'd expect the 39 stragglers to be the most problematic

And this seems to hold IMO.

The perl packages are all going to be relatively uniform, so iterating over
PGPASSWORD=udd-mirror psql --port=5432 --host=udd-mirror.debian.net --username=udd-mirror udd -c 'select vcs_url from sources where (build_depends like '\''%dh-buildinfo%'\'' or build_depends_arch like '\''%dh-buildinfo%'\'' or build_depends_indep like '\''%dh-buildinfo%'\'') and release = '\''sid'\'' and vcs_url like '\''%perl-team%'\'';'
+ https://salsa.debian.org/perl-team/modules/packages/perlrdf.git
+ https://salsa.debian.org/perl-team/modules/packages/libcatalyst-view-petal-perl.git
(both on salsa but not uploaded since the move)
in a mostly-mechanised fashion by any uploading team member
(something like
gbp clone "$1"
cd "$(expr "$1" : '.*/\(.*\)\.git')"
sed -i -e '/^[[:space:]]*dh-buildinfo[,]*$/d' -e 's/,[[:space:]]*dh-buildinfo//' debian/control
grep buildinfo debian/rules && $SHELL
git commit -am 'd/control: Build-Depends: remove dh-buildinfo (see #1068809)'
gbp dch -R --team --spawn-editor=never
git commit -am "Upload $(IFS="$IFS()" read -r pkg v _ < debian/changelog; echo $pkg $v) to unstable"
gbp buildpackage -S
gbp tag
git push && git push --tags
worked for me on a random sample of a few from the list)
and clicking through it thusly seems much more sensible
than micro-managing each uploader separately.
The same should apply to packages team-maintained by other teams.

If you want to avoid mass-uploading 200 packages,
then just committing the removal and letting it get picked up
with the next upload should be even less controversial
(but considering how long the tail gets,
given perlrdf and libcatalyst-view-petal-perl, well.).

I'd click through this if I could, but I can't,
so I focused on the packages that were less automatable.

[Andreas Tille]

Hi,

Post by Alexandre Detiste
Don't forget the 311 build-depends ...
$ reverse-depends -l -b dh-buildinfo | wc -l
311

I did some UDD query


select source, release, build_depends from sources where build_depends like '%dh-buildinfo%' and release = 'sid';

which found 313, but well, these are details.

Post by Alexandre Detiste
These would need a MBF ?

Seems so. At least I removed it from the last remaining Debian Med
package and picked a more or less random Debian Science package (irstlm)

Not sure whether this is the right time to MBF >300 packages, but well,
at some point in time it should go.

Post by Alexandre Detiste

Post by Holger Levsen
Hi Andreas,
YES. :)
I've NMUed cdbs already last Sunday and dropped all occurances of
dh-buildinfo from it, so today there are only 3 packages left,
- ecbuild
- haskell-devscripts
- debian-multimedia

The last one is gone with my upload a couple of hours ago.

I guess haskell-devscripts might be the hard one remaining.

Kind regards
Andreas.

[Andreas Tille]

debian-multimedia (0.12) unstable; urgency=medium
* Task devel: Do not suggest dh-buildinfo (bug #1068809 asking for removal)
[...]

oh, great! Thank you, Andreas.

Greetings from Bug of the Day team to Reproducible Builds team. ;-P

See you
Andreas.

[Santiago Vila]

tags 1068809 patch
thanks

Hello Yann.

The attached patch (which I've tried it to be as minimal as possible)
would make dh_buildinfo a no-op, as discussed in this thread.

This would remove its undesired effects. Most notably, the ones related to
reproducibility pointed out by Holger, where the smallest change
in the build environment makes a package to be different again,
and it would achieve it with mininal fuss, as we would not need
sourceful uploads for hundreds of packages.

Additionally, if you don't object, it would be nice to reflect in the
extended description of the package that we would like everybody
to stop using it, i.e. some general statement about deprecateness.

Note 1: I've actually tried to build the 311 packages having dh-buildinfo
in their build-depends with this modified package, and none of them broke.

Note 2: The wording

dh-buildinfo is obsolete, please remove it from Build-Depends

is naturally meant to be interpreted as dh-buildinfo being
the package to be removed from build-depends (hence the "-"),
not the command executed in debian/rules (which would use "_").

Post by Helmut Grohne
If you agree with this vision, please tag this bug confirmed. If you
disagree with this vision, please tag it wontfix and explain the added
value that I fail to see.

I also would like to see this issue being handled with your approval.

Thanks.

[Santiago Vila]

Sorry, I forgot the patch. Here it is.

[Guillem Jover]

Hi!

Post by Santiago Vila
The attached patch (which I've tried it to be as minimal as possible)
would make dh_buildinfo a no-op, as discussed in this thread.
This would remove its undesired effects. Most notably, the ones related to
reproducibility pointed out by Holger, where the smallest change
in the build environment makes a package to be different again,
and it would achieve it with mininal fuss, as we would not need
sourceful uploads for hundreds of packages.

I think that would be a nice incremental improvement with immediate
benefits, which does not preclude the cleanup that Holger was talking
about, which can then run at its own independent course. I think
people agreeing with this was more about untangling the concerns,
more than not considering the cleanup worthwhile.

Post by Santiago Vila
Sorry, I forgot the patch. Here it is.
--- /dev/null
+++ b/debian/dummy_dh_buildinfo
@@ -0,0 +1,2 @@
+#!/bin/sh
+echo "Warning: dh-buildinfo is obsolete, please remove it from Build-Depends"

Perhaps using instead the following, would give a bit more visibility
to the warning:

,--- dh_buildinfo ---
#!/bin/sh

PROGNAME=dh_buildinfo
. /usr/share/dpkg/sh/dpkg-error.sh
setup_colors

warning "dh-buildinfo is obsolete, please remove it from Build-Depends"
`---

(I've been bothered by the seemingly gratuitous boilerplate required
for dpkg-error.sh in the past, but this now made that resurface, so
I'm working on reducing it in dpkg git, for future similar usages. :)

Thanks,
Guillem

[Santiago Vila]

Post by Guillem Jover

Post by Santiago Vila
--- /dev/null
+++ b/debian/dummy_dh_buildinfo
@@ -0,0 +1,2 @@
+#!/bin/sh
+echo "Warning: dh-buildinfo is obsolete, please remove it from Build-Depends"

Perhaps using instead the following, would give a bit more visibility
,--- dh_buildinfo ---
#!/bin/sh
PROGNAME=dh_buildinfo
. /usr/share/dpkg/sh/dpkg-error.sh
setup_colors
warning "dh-buildinfo is obsolete, please remove it from Build-Depends"
`---

Nice! Yes, this is a lot better, and also in line with other
deprecation warnings I've seen elsewhere.

Ok, I believe there is enough consensus to do the change.

Yann: I'm going to NMU this package tomorrow, using the patch
I posted several weeks ago plus the color changes from Guillem.

I will not make any other change.

Please speak up if for any reason you do not agree.

Thanks.

[Holger Levsen]

Post by Santiago Vila
Yann: I'm going to NMU this package tomorrow, using the patch
I posted several weeks ago plus the color changes from Guillem.
I will not make any other change.

Thanks already!

(I'm a bit sick so a bit less active on this than I wanted...)
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Home is where the climate crisis is.

[Santiago Vila]

Post by Holger Levsen

Post by Santiago Vila
Yann: I'm going to NMU this package tomorrow, using the patch
I posted several weeks ago plus the color changes from Guillem.
I will not make any other change.

Thanks already!

You are welcome!

Post by Holger Levsen
(I'm a bit sick so a bit less active on this than I wanted...)

I hope this upload makes you feel better :-)


Ok, I've just done the NMU I announced, in the most minimalistic
style possible. The debdiff is attached for reference.

I have not added anything to the extended description for several
reasons:

- I know myself and would spend hours trying to find the perfect wording,..
The current changes already have the desired effect.

- If we are lucky and fix all the packages before the release of trixie
(no hurry anymore in doing so), it would not be necessary at all.

- Anybody who wonders why dh_buildinfo now behaves the way it does
will easily find the changelog, the bug number, and this discussion,
so it's not as if this was a secret conspiracy.

- If we finally have to release trixie with this no-op dh-buildinfo,
we can just make another release for documentation purposes.

There are some pending issues, which I leave to others as they see fit:

- lintian should probably warn about the build-depends
- lintian-brush should probably remove the build-depends

(even if we remove dh-buildinfo for trixie, we would also like
to "send the message" to our downstreams and third parties).

- in theory, we could binNMU affected packages now,
Holger, I think you would love doing that.

- As it has been suggested earlier in this thread: Would debhelper
maintainers be willing to "hijack" this dummy dh_buildinfo and move
it to debhelper, just for trixie?

The new debhelper would conflicts/replaces the old dh_buildinfo,
and most importantly it would *provide* it, which would allow
us to remove the dh-buildinfo package itself quite soon and without
bothering a lot of people.

Adding Cc Niels for the above.

I'm keeping this bug open because the NMU does not completely
fix the issue, and also because it's useful to continue
the discussion here (maybe debian-***@l.d.o would be a good place?)

Thanks a lot!

[Holger Levsen]

I see about 9 bugs blocking this one suggesting we are talking a hijack to
avoid 9 uploads. If this is truly the scale of the problem now, then I would
prefer we just fixed the remaining packages and moved on.
If the problem is measured in "considerably more" packages, then I might
reconsider.

it is much bigger, it affects roughly 5% of the archive:

in unstable:

$ apt-file search -x 'buildinfo_(amd64|all).gz | wc -l
3742

$ build-rdeps dh-buildinfo | tail -2 | head -1
Found a total of 1459 reverse build-depend(s) for dh-buildinfo.

and contrary to my assumptions a few days ago, these not only cause unreproducibility
when cross-building, but also when doing native rebuilds. (because dh-buildinfo
documents all installed packages, while dpkg's .buildinfo implementation
only records installed build-depends of the package being build, thus missing
packages like apt, login or fakeroot...)
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

We are not moving into a 1.5C world, we are briefly passing through it in 2024.
(James Hansen)

[Holger Levsen]

I see about 9 bugs blocking this one...

this is due to an incomplete mass bug filing...
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Punk ist nicht tot.
Punk trÀgt Maske, ist solidarisch und schÌtzt sich und andere.
(@Kreuzpirat)

[Holger Levsen]

control: severity 1068809 important
control: retitle 1068809 dh-buildinfo: deprecated, turned into a no-op and scheduled for removal
thanks

since dh-buildinfo 0.11+nmu4, which migrated to trixie already, the package
does nothing, and thus nothing harmful as well. thus it can now be removed
if it werent for all the build dependencies.

Currently in sid there are still 1443 reverse build-depends for dh-buildinfo.
and in total 3719 'buildinfo_(amd64|all).gz' files can be found. (Though this
is not limited to amd64...)
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

If nothing saves us from death, may love at least save us from life.

[Holger Levsen]

Ok, can someone provide a salsa MR or a patch against debhelper for that
base of what we are pulling into debhelper, so I can easier review what I
would potentially accept?

I believe you just need to add these three lines to d/control:

Breaks: dh-buildinfo
Replaces: dh-buildinfo
Provides: dh-buildinfo

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces is
relevant paragraph in -policy.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Historians have a word for Germans who joined the Nazi party, not because they
hated Jews, but out of hope for restored patriotism, or a sense of economic
anxiety, or a hope to preserve their religious values, or dislike of their
opponents, or raw political opportunism, or convenience, or ignorance, or
greed.
That word is "Nazi". Nobody cares about their motives anymore.

[Santiago Vila]

Post by Holger Levsen

Ok, can someone provide a salsa MR or a patch against debhelper for that
base of what we are pulling into debhelper, so I can easier review what I
would potentially accept?

Breaks: dh-buildinfo
Replaces: dh-buildinfo
Provides: dh-buildinfo

In addition to those three fields, the idea would be to put in
debhelper the minimalistic "do-nothing" dh_buildinfo that we have
recently put in the dh-buildinfo package, namely this:

--------------------------------------
#!/bin/sh

PROGNAME=dh_buildinfo
. /usr/share/dpkg/sh/dpkg-error.sh
setup_colors

warning "dh-buildinfo is obsolete, please remove it from Build-Depends"
--------------------------------------

Thanks.

[Chris Hofstaedtler]

Post by Santiago Vila

Post by Holger Levsen

Ok, can someone provide a salsa MR or a patch against debhelper for that
base of what we are pulling into debhelper, so I can easier review what I
would potentially accept?

Breaks: dh-buildinfo
Replaces: dh-buildinfo
Provides: dh-buildinfo

In addition to those three fields, the idea would be to put in
debhelper the minimalistic "do-nothing" dh_buildinfo that we have

I think we can just fix the packages actually *calling*
dh_buildinfo, if necessary with NMUs.

Chris

[Santiago Vila]

Post by Chris Hofstaedtler

Post by Santiago Vila

Post by Holger Levsen
Breaks: dh-buildinfo
Replaces: dh-buildinfo
Provides: dh-buildinfo

In addition to those three fields, the idea would be to put in
debhelper the minimalistic "do-nothing" dh_buildinfo that we have

I think we can just fix the packages actually *calling*
dh_buildinfo, if necessary with NMUs.

We could, but that way we are introducing quite a bunch of RC bugs,
which is what I tried to avoid when I NMUed dh-buildinfo in the first place.

Thanks.

[Holger Levsen]

A quick codesearch suggests that `dh_buildinfo` still appears in about 20-25
packages and not all of them having a `if dh_buildinfo exists` guard. So if
I add those without a `dh_buildinfo` script to go with it, there will be
FTBFS bugs.

I think that is an acceptable number but I'm clearly biased. :)

I can add those three lines to `debhelper`, no problem. But I assume
"someone else" will handle the clean up/fall out. To be clear, that "someone
else" is not going to me.

The clearness is appreciated!

So before I add it, who will clean up the reminder? (Just so I know it is
not going to fall between 5 chairs with everyone going "I thought you had
it")

I will. I've also filed #1089874 ("drop depends on dh-buildinfo from haskell-devscripts")
today, which - with rebuilds - will handle most of the problems more to the core.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Where will you go when you become a climate refugee?

[Holger Levsen]

Thanks. It is now committed as 97819c3cf66633b39af06e31d40631f5e3c94943.

thank you! <3

I went with Policy 7.6.2 (using Conflicts rather than Breaks) since that
avoids lintian warnings for version constraints and should still be
applicable here.

seems sensible to me as well!
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Privacy is a Human Right. (Universal Declaration of Human Rights, article 12.)

[Chris Hofstaedtler]

Post by Chris Hofstaedtler
I think we can just fix the packages actually *calling*
dh_buildinfo, if necessary with NMUs.

We could, but that way we are introducing quite a bunch of RC bugs,
which is what I tried to avoid when I NMUed dh-buildinfo in the first place.

Fewer than 20 packages will need changes, some of these packages
have been asked to be removed themselves. If we have no immediate
urgency in getting rid of src:dh-buildinfo, I think it's manageable.

Chris

[Santiago Vila]

Post by Chris Hofstaedtler

Post by Chris Hofstaedtler
I think we can just fix the packages actually *calling*
dh_buildinfo, if necessary with NMUs.

We could, but that way we are introducing quite a bunch of RC bugs,
which is what I tried to avoid when I NMUed dh-buildinfo in the first place.

Fewer than 20 packages will need changes, some of these packages
have been asked to be removed themselves. If we have no immediate
urgency in getting rid of src:dh-buildinfo, I think it's manageable.

Hi. There was no immediate urgency in getting rid of src:dh-buildinfo,
but if I'm not mistaken, those 20 packages, which currently
have BD: dh-buildinfo and explicitly call dh_buildinfo in debian/rules,
will now FTBFS regardless of src:dh-buildinfo existing or not
(due to the Provides added to debhelper).

If that's actually the case (can someone please confirm?), then it
would seem that we could ask for src:dh-buildinfo to be removed now.
(Probably by reassigning this bug to ftp.debian.org).

Thanks.

[Chris Hofstaedtler]

Post by Santiago Vila

Post by Chris Hofstaedtler
Fewer than 20 packages will need changes, some of these packages
have been asked to be removed themselves. If we have no immediate
urgency in getting rid of src:dh-buildinfo, I think it's manageable.

Hi. There was no immediate urgency in getting rid of src:dh-buildinfo,
but if I'm not mistaken, those 20 packages, which currently
have BD: dh-buildinfo and explicitly call dh_buildinfo in debian/rules,
will now FTBFS regardless of src:dh-buildinfo existing or not
(due to the Provides added to debhelper).

I've NMUed all packages that were going to FTBFS, and had no open RM
bug or FTBFSed already.

Post by Santiago Vila
If that's actually the case (can someone please confirm?), then it
would seem that we could ask for src:dh-buildinfo to be removed now.

Yes, dh-buildinfo can now be removed.

Post by Santiago Vila
(Probably by reassigning this bug to ftp.debian.org).

(Might be best to clone + reassign, but leaving this to whomever
does it.)

Chris

[Yann Dirson]

Great, thanks for your work - I should indeed have done that myself a long time ago :|
--
Yann

----- Mail original -----

Envoyé: Mercredi 18 Décembre 2024 22:07:45
Objet: Bug#1068809: dh-buildinfo: consider deprecating and removing the package

Post by Santiago Vila

Post by Chris Hofstaedtler
Fewer than 20 packages will need changes, some of these packages
have been asked to be removed themselves. If we have no immediate
urgency in getting rid of src:dh-buildinfo, I think it's
manageable.

Hi. There was no immediate urgency in getting rid of
src:dh-buildinfo,
but if I'm not mistaken, those 20 packages, which currently
have BD: dh-buildinfo and explicitly call dh_buildinfo in
debian/rules,
will now FTBFS regardless of src:dh-buildinfo existing or not
(due to the Provides added to debhelper).

I've NMUed all packages that were going to FTBFS, and had no open RM
bug or FTBFSed already.

Post by Santiago Vila
If that's actually the case (can someone please confirm?), then it
would seem that we could ask for src:dh-buildinfo to be removed now.

Yes, dh-buildinfo can now be removed.

Post by Santiago Vila
(Probably by reassigning this bug to ftp.debian.org).

(Might be best to clone + reassign, but leaving this to whomever
does it.)
Chris

[Santiago Vila]

Thanks Yann for showing up! Now we know that we are all in agreement for this.

For completeness, I've rebuilt the 272 packages which BD on dh-buildinfo and found
that the following ones do not build from source:

bcron
csound
eccodes
gnumeric
leaktracer
libcache-lru-perl
libept
libjson-webtoken-perl
liblo
liblog-dispatch-message-passing-perl
libxml-libxml-debugging-perl
libyaml
o2
reqwest
runit

Some of them fail for reasons not related with dh-buildinfo.

Some of them are already reported.

But some of them are not reported yet. Among them:

- Some have a versioned BD on dh-buildinfo, which only the real one
satisfies but debhelper conflicts dh-buildinfo so the build fails
with "unsatisfiable build-depends".

- Some have "dh $@ --with buildinfo" which debhelper no longer handles.

Can someone care about reporting those? Please do not make 0-day NMUs, remember
that they will fail to build regardless of dh-buildinfo existing or not.

I'd like to wait for everything to be reported before we think of
reassigning to ftp.debian.org.

Regarding the blocks, I think they do not make sense at this point, because none
of the 272 packages try to install src:dh-buildinfo when they are built.
The ones that fail to build will fail with or without src:dh-buildinfo in
the archive, so I wonder if nab (hope this transliteration is ok)
would be willing to remove the blocks as a pre-condition to ask
ftpmasters to remove the package.

Thanks.

[наб]

Control: unblock -1 by 1088380 1088384 1088392 1088393 1088394 1088395 1089892 1089900 1089901 1089906 1089911

Post by Santiago Vila
Thanks Yann for showing up! Now we know that we are all in agreement for this.
For completeness, I've rebuilt the 272 packages which BD on dh-buildinfo and found
leaktracer

This is in the RM queue already.

Post by Santiago Vila
Some of them fail for reasons not related with dh-buildinfo.
Some of them are already reported.
But some of them are not reported yet.

Now they are:
#1090770: runit: depends on unsatisfiable dh-buildinfo
#1090771: libyaml: depends on unsatisfiable dh-buildinfo
#1090772: bcron: depends on unsatisfiable dh-buildinfo
#1090773: o2: uses removed --with buildinfo
#1090774: liblo: uses removed --with buildinfo
#1090775: csound: uses removed --with buildinfo
#1090776: libxml-libxml-debugging-perl: uses removed --with buildinfo
#1090777: liblog-dispatch-message-passing-perl: uses removed --with buildinfo
#1090778: libjson-webtoken-perl: uses removed --with buildinfo
#1090779: libcache-lru-perl: uses removed --with buildinfo

Post by Santiago Vila
I'd like to wait for everything to be reported before we think of
reassigning to ftp.debian.org.

Probably g2g now.

Best,

[Santiago Vila]

severity 1068809 normal
reassign 1068809 ftp.debian.org
thanks

Dear Debian ftpmasters:

We (the participants in this bug) believe that the package dh-buildinfo
can be removed now, and we request that it's removed.

The rationale for deprecating dh-buildinfo is explained
in a very detailed way in the first message of this bug
which I'm now reassigning.

The reason that dh-buildinfo can be removed now is that
debhelper maintainers agreed to add a "Provides: dh-buildinfo"
so that this deprecation can happen sooner.

Now, packages having dh-buildinfo in their build-depends
will either satisfy the build-dependency with debhelper,
if it's not versioned, or will fail with unsatisfiable build-depends
if it's versioned, because debhelper has a conflicts: dh-buildinfo.

As a result, none of the 272 packages still having dh-buildinfo
in their build-depends will actually try to install the real
dh-buildinfo when being built, and this is why we consider that
the package can be removed now.

All the required bugs have been filed, and the few packages which
FTBFS with the new setup (where debhelper provides dh-buildinfo)
have a trivial patch available in the bug report (which is RC
because of the FTBFS status).

Thanks for your consideration.

And also thanks to everybody who helped to make this possible.

[Holger Levsen]

Post by Chris Hofstaedtler
I've NMUed all packages that were going to FTBFS, and had no open RM
bug or FTBFSed already.

wheeehooo, that's awesome, thank you! <3

Post by Chris Hofstaedtler

Post by Santiago Vila
If that's actually the case (can someone please confirm?), then it
would seem that we could ask for src:dh-buildinfo to be removed now.

Yes, dh-buildinfo can now be removed.

Post by Santiago Vila
(Probably by reassigning this bug to ftp.debian.org).

(Might be best to clone + reassign, but leaving this to whomever
does it.)

I'd actually suggest to file a new bug, and refer to this one in that.

And I'd like to make 1068809: 1088392, 1089906, 1089900, 1089911, 1088395,
1088393, 1088394, 1088380, 1089892, 1089901, and 1088384 blockers against
this bug again, so we can reference this bug to see what cleanup still
needs to be done.

similar with the bugs filed by Маб - and thanks for filing those!

#1090770: runit: depends on unsatisfiable dh-buildinfo
#1090771: libyaml: depends on unsatisfiable dh-buildinfo
#1090772: bcron: depends on unsatisfiable dh-buildinfo
#1090773: o2: uses removed --with buildinfo
#1090774: liblo: uses removed --with buildinfo
#1090775: csound: uses removed --with buildinfo
#1090776: libxml-libxml-debugging-perl: uses removed --with buildinfo
#1090777: liblog-dispatch-message-passing-perl: uses removed --with buildinfo
#1090778: libjson-webtoken-perl: uses removed --with buildinfo
#1090779: libcache-lru-perl: uses removed --with buildinfo
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

War is peace. Freedom is slavery. Covid is like the flu.

[Santiago Vila]

Post by Holger Levsen
I'd actually suggest to file a new bug, and refer to this one in that.
And I'd like to make 1068809: 1088392, 1089906, 1089900, 1089911, 1088395,
1088393, 1088394, 1088380, 1089892, 1089901, and 1088384 blockers against
this bug again, so we can reference this bug to see what cleanup still
needs to be done.

I think we don't need to readd the blocks. To track the progress we can use tags,
so I've just created this one:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-***@lists.debian.org;tag=dh-buildinfo

As for creating a new bug for ftp.debian.org, I also don't think it's necessary.

If there is something else to discuss, we can meet in debian-***@lists.debian.org.
In fact, I've just started a thread there right now which serves as a reference.

So: I'm going to reassign the bug. See you all in debian-***@lists.debian.org.

Thanks a lot.