Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1221901 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-11-28 01:40 +0100
    Bug#1068809: dh-buildinfo: consider deprecating and removing the package Guillem Jover <guillem@debian.org> - 2024-12-06 00:40 +0100
      Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-12-06 01:20 +0100
        Bug#1068809: dh-buildinfo: consider deprecating and removing the package Holger Levsen <holger@layer-acht.org> - 2024-12-06 11:10 +0100
          Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-12-06 13:30 +0100
            Bug#1068809: dh-buildinfo: consider deprecating and removing the package Holger Levsen <holger@layer-acht.org> - 2024-12-08 12:30 +0100
              Bug#1068809: dh-buildinfo: consider deprecating and removing the package Holger Levsen <holger@layer-acht.org> - 2024-12-14 13:40 +0100
                Bug#1068809: dh-buildinfo: consider deprecating and removing the package Holger Levsen <holger@layer-acht.org> - 2024-12-14 14:00 +0100
                  Bug#1068809: dh-buildinfo: consider deprecating and removing the package Holger Levsen <holger@layer-acht.org> - 2024-12-14 14:20 +0100
                Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-12-14 14:10 +0100
                  Bug#1068809: dh-buildinfo: consider deprecating and removing the package Chris Hofstaedtler <zeha@debian.org> - 2024-12-14 14:20 +0100
                    Bug#1068809: dh-buildinfo: consider deprecating and removing the package Chris Hofstaedtler <zeha@debian.org> - 2024-12-14 14:30 +0100
                      Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-12-18 15:20 +0100
                        Bug#1068809: dh-buildinfo: consider deprecating and removing the package Chris Hofstaedtler <zeha@debian.org> - 2024-12-18 22:10 +0100
                          Bug#1068809: dh-buildinfo: consider deprecating and removing the package Yann Dirson <ydirson@free.fr> - 2024-12-18 23:00 +0100
                            Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-12-19 02:10 +0100
                              Bug#1068809: dh-buildinfo: consider deprecating and removing the package наб <nabijaczleweli@nabijaczleweli.xyz> - 2024-12-19 03:40 +0100
                                Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-12-21 00:40 +0100
                          Bug#1068809: dh-buildinfo: consider deprecating and removing the package Holger Levsen <holger@layer-acht.org> - 2024-12-19 17:00 +0100
                            Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-12-21 00:30 +0100
                    Bug#1068809: dh-buildinfo: consider deprecating and removing the package Santiago Vila <sanvila@debian.org> - 2024-12-14 14:30 +0100
            Bug#1068809: dh-buildinfo: consider deprecating and removing the package Holger Levsen <holger@layer-acht.org> - 2024-12-08 12:30 +0100

Page 1 of 2  [1] 2  Next page →

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

[Multipart message — attachments visible in raw view] — view raw

Sorry, I forgot the patch. Here it is.

[toc] | [next] | [standalone]

#1222877

Hi!

On Thu, 2024-11-28 at 01:11:05 +0100, Santiago Vila wrote:
> 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.

On Thu, 2024-11-28 at 01:33:12 +0100, Santiago Vila wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#1222880

>> --- /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"
> `---

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.

[toc] | [prev] | [next] | [standalone]

#1222913

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 06, 2024 at 01:10:50AM +0100, Santiago Vila wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#1222928

[Multipart message — attachments visible in raw view] — view raw

El 6/12/24 a las 10:59, Holger Levsen escribió:
> On Fri, Dec 06, 2024 at 01:10:50AM +0100, Santiago Vila wrote:
>> 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!
  
> (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-qa@l.d.o would be a good place?)

Thanks a lot!

[toc] | [prev] | [next] | [standalone]

#1223197

[Multipart message — attachments visible in raw view] — view raw

On Sun, Dec 08, 2024 at 12:02:56PM +0100, Niels Thykier wrote:
> 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)

[toc] | [prev] | [next] | [standalone]

#1223940

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 14, 2024 at 12:51:27PM +0100, Niels Thykier wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#1223941

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 14, 2024 at 01:46:18PM +0100, Niels Thykier wrote:
> 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?

[toc] | [prev] | [next] | [standalone]

#1223956

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 14, 2024 at 02:07:24PM +0100, Niels Thykier wrote:
> 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.)

[toc] | [prev] | [next] | [standalone]

#1223952

El 14/12/24 a las 13:37, Holger Levsen escribió:
> On Sat, Dec 14, 2024 at 12:51:27PM +0100, Niels Thykier wrote:
>> 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

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.

[toc] | [prev] | [next] | [standalone]

#1223954

On Sat, Dec 14, 2024 at 01:59:51PM +0100, Santiago Vila wrote:
> El 14/12/24 a las 13:37, Holger Levsen escribió:
> > On Sat, Dec 14, 2024 at 12:51:27PM +0100, Niels Thykier wrote:
> > > 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
> 
> 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:

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

Chris

[toc] | [prev] | [next] | [standalone]

#1223967

* Santiago Vila <sanvila@debian.org> [241214 14:18]:
> El 14/12/24 a las 14:09, Chris Hofstaedtler escribió:
> > 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

[toc] | [prev] | [next] | [standalone]

#1224743

El 14/12/24 a las 14:23, Chris Hofstaedtler escribió:
> * Santiago Vila <sanvila@debian.org> [241214 14:18]:
>> El 14/12/24 a las 14:09, Chris Hofstaedtler escribió:
>>> 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.

[toc] | [prev] | [next] | [standalone]

#1224780

* Santiago Vila <sanvila@debian.org> [241218 15:12]:
> > 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.

> 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.

> (Probably by reassigning this bug to ftp.debian.org).

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

Chris

[toc] | [prev] | [next] | [standalone]

#1224785

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

-- 
Yann

----- Mail original -----
> De: "Chris Hofstaedtler" <zeha@debian.org>
> À: "Santiago Vila" <sanvila@debian.org>
> Cc: 1068809@bugs.debian.org, "Holger Levsen" <holger@layer-acht.org>, "Niels Thykier" <niels@thykier.net>, "Guillem
> Jover" <guillem@debian.org>, "Yann Dirson" <dirson@debian.org>, "Helmut Grohne" <helmut@subdivi.de>
> Envoyé: Mercredi 18 Décembre 2024 22:07:45
> Objet: Bug#1068809: dh-buildinfo: consider deprecating and removing the package
> 
> * Santiago Vila <sanvila@debian.org> [241218 15:12]:
> > > 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.
> 
> > 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.
> 
> > (Probably by reassigning this bug to ftp.debian.org).
> 
> (Might be best to clone + reassign, but leaving this to whomever
> does it.)
> 
> Chris
> 

[toc] | [prev] | [next] | [standalone]

#1224794

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.

[toc] | [prev] | [next] | [standalone]

#1224804

[Multipart message — attachments visible in raw view] — view raw

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

On Thu, Dec 19, 2024 at 02:05:32AM +0100, Santiago Vila wrote:
> 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:

> leaktracer
This is in the RM queue already.

> 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

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

Best,

[toc] | [prev] | [next] | [standalone]

#1225059

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.

[toc] | [prev] | [next] | [standalone]

#1224866

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 18, 2024 at 10:07:45PM +0100, Chris Hofstaedtler wrote:
> 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
 
> > 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.
> 
> > (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.

[toc] | [prev] | [next] | [standalone]

#1225056

> 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-qa@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-qa@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-qa@lists.debian.org.

Thanks a lot.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web