Bug#1068189: debhelper: --link-doc checking for known packages makes linux-signed build FTBFS
Control: reassign -1 src:linux 6.7.9-2
Hi Niels,
On Mon, Apr 01, 2024 at 05:19:43PM +0200, Niels Thykier wrote:
> Salvatore Bonaccorso:
> > Source: debhelper
> > Version: 13.15
> > Severity: serious
> > Tags: ftbfs
> > Justification: Regression for other package builds, FTBFS
> > X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org
> > Control: affects -1 +
> > src:linux,src:linux-signed-amd64,src:linux-signed-arm64
> >
> > Hi Niels,
> >
> > Not fully investigated, but starting to fill a bugreport. I noticed
> > that the src:linux pipeline on salsa started to fail for the
> > jobs in th build-signed stage (in the build-signed job).
> >
> > https://salsa.debian.org/carnil/linux/-/jobs/5527774
> >
> > (and for saving the output):
> >
> > [...]
> >
> > (attached as well the raw log)
> >
> > I'm not 100% sure yet, this might be a problem in our packaging in
> > which case we can re-eassign. But it only got triggered with the
> > change recently in debhelper:
> >
> > https://salsa.debian.org/debian/debhelper/-/commit/dec5cfad00e2abd9ee3594f90c93f3fa42bb73ff
> >
> > Regards,
> > Salvatore
>
> Hi Salvatore
>
> It was a suggestion raised (I think on IRC) to have debhelper explicitly
> check these parameters, because a lot of t64 breakage was "unnoticed" by
> debhelper. That is, when people forgot to update --link-doc parameters
> (etc.).
>
> The code for `--link-doc` uses `${binary:Version}` for the dependency, so
> the package should really be from the same source[1]. In my view, it was
> never a case that was expected to work between source packages.
>
> I think `linux` with `linux-signed` is doing something really special here
> (especially considering it has worked so far), and I think the question is
> whether `linux`/`linux-signed` should get a special-case or concluding that
> the `--link-doc` is not suitable for the `linux`/`linux-signed` case.
>
> I would like to hear your case for what makes `--link-doc` sensible for the
> `linux-signed` case. I know of `linux-signed`, but I have no idea what you
> are dealing with in practice, so it is hard for me to make a judgement call
> on this (other than my biased gut feeling of wanting to minimize
> special-cases).
Thanks for your very quick reply, this is much appreicated.
I understand the reason and src:linux should not get really to be
exceptionally handled. So for now I will re-assign it to src:linux
and we can search for a solution in our package.
Thanks a lot for your work on debhelper!
Regards,
Salvatore
Bug#1068189: debhelper: --link-doc checking for known packages makes linux-signed build FTBFS
Salvatore Bonaccorso:
Source: debhelper
Version: 13.15
Severity: serious
Tags: ftbfs
Justification: Regression for other package builds, FTBFS
X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org
Control: affects -1 + src:linux,src:linux-signed-amd64,src:linux-signed-arm64
Hi Niels,
Not fully investigated, but starting to fill a bugreport. I noticed
that the src:linux pipeline on salsa started to fail for the
jobs in th build-signed stage (in the build-signed job).
https://salsa.debian.org/carnil/linux/-/jobs/5527774
(and for saving the output):
[...]
(attached as well the raw log)
I'm not 100% sure yet, this might be a problem in our packaging in
which case we can re-eassign. But it only got triggered with the
change recently in debhelper:
https://salsa.debian.org/debian/debhelper/-/commit/dec5cfad00e2abd9ee3594f90c93f3fa42bb73ff
Regards,
Salvatore
Hi Salvatore
It was a suggestion raised (I think on IRC) to have debhelper explicitly
check these parameters, because a lot of t64 breakage was "unnoticed" by
debhelper. That is, when people forgot to update --link-doc parameters
(etc.).
The code for `--link-doc` uses `${binary:Version}` for the dependency,
so the package should really be from the same source[1]. In my view, it
was never a case that was expected to work between source packages.
I think `linux` with `linux-signed` is doing something really special
here (especially considering it has worked so far), and I think the
question is whether `linux`/`linux-signed` should get a special-case or
concluding that the `--link-doc` is not suitable for the
`linux`/`linux-signed` case.
I would like to hear your case for what makes `--link-doc` sensible for
the `linux-signed` case. I know of `linux-signed`, but I have no idea
what you are dealing with in practice, so it is hard for me to make a
judgement call on this (other than my biased gut feeling of wanting to
minimize special-cases).
Best regards,
Niels
[1]: Policy also documents the "same source" requirement.
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information
Bug#1068189: debhelper: --link-doc checking for known packages makes linux-signed build FTBFS
Source: debhelper Version: 13.15 Severity: serious Tags: ftbfs Justification: Regression for other package builds, FTBFS X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org Control: affects -1 + src:linux,src:linux-signed-amd64,src:linux-signed-arm64 Hi Niels, Not fully investigated, but starting to fill a bugreport. I noticed that the src:linux pipeline on salsa started to fail for the jobs in th build-signed stage (in the build-signed job). https://salsa.debian.org/carnil/linux/-/jobs/5527774 (and for saving the output): dh_installdocs --link-doc=linux-headers-6.7+unreleased-cloud-amd64 dh_installdocs: error: Requested unknown package linux-headers-6.7+unreleased-cloud-amd64 via --link-doc, expected one of: linux-image-6.7+unreleased-amd64 linux-image-amd64 linux-headers-amd64 linux-image-6.7+unreleased-cloud-amd64 linux-image-cloud-amd64 linux-headers-cloud-amd64 linux-image-6.7+unreleased-rt-amd64 linux-image-rt-amd64 linux-headers-rt-amd64 make[2]: *** [debian/rules.real:81: binary_meta] Error 25 make[1]: *** [debian/rules.gen:21: binary-arch_amd64_none_cloud-amd64_meta] Error 2 make: *** [debian/rules:19: binary-arch] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 (attached as well the raw log) I'm not 100% sure yet, this might be a problem in our packaging in which case we can re-eassign. But it only got triggered with the change recently in debhelper: https://salsa.debian.org/debian/debhelper/-/commit/dec5cfad00e2abd9ee3594f90c93f3fa42bb73ff Regards, Salvatore 5527774.log.gz Description: application/gzip
