After upgrade of linux-libre, linux-libre-documentation fails to build

  • Done
  • quality assurance status badge
Details
3 participants
  • Leo Famulari
  • Rostislav Svoboda
  • Tomas Volf
Owner
unassigned
Submitted by
Tomas Volf
Severity
normal
T
T
Tomas Volf wrote on 10 Apr 17:05 +0200
(address . bug-guix@gnu.org)
Zhaqq9s3JSDl7mqx@ws
Attachment: file
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmYWqqsACgkQL7/ufbZ/
wanXEA/+Lw7sZljSTQHL9Hb+8wPhKUbXI4LJIW3t9/OJ+KHBg4BYaPThOK0Fvran
RiV8CA10Kv3CaLsDNcBpmzADRrdcWtjkOCbrDl7wK+XLvWBH0LtpwUgNJETwnkeL
YGK2ETiH+qo5cpd41nEqFLTNosZPg5RskXBBiEGpDAFsG4c5IjjmGFeW5grt/iq1
R84HiCLj/e7HhYnGxf1vhErMsEIISVtA/s4Xrdy1Vargb9GPuZsFfGYOsccj+6ZL
jWI315gVsznf47HRD39sJJu4GQUX36jtRLJuPFwRmaFOKeNqc3I7NeC7MfHAa4eZ
Wl5JEam2vqYNAytx7mMJkLjHPjO7iYVkIswrUeC6CAeuZCthYGOEjb8hG/PtDzqf
3er5/02g/zu04RwtvCLaPnLwKoLczOcW8uffwIV8VkJ6NVw9oZ1sNXmonvIXdFPw
I1Zf8ap+jTUe2Y4x00TdJ5fBb1KdUHrKuqoMLuezpMSA8fnygAHFpiEY4cy0KQm6
cfsauqfy+4q5Kaqv+zUGfugMNhNltXqaxGt7Ocu5uylV6luTKfN/MPG5VIInR4s+
2WobDzP7K6o45wgdzPScQ8sEK/gIvy4QnKl+n0CouSBSRY83Zu6aV1lzyk8zbHq2
FfvH3xRzOvArYQ5b6pC6Scvi/LIefQohiOQFWBabO/5f6wQ0To0=
=TqHU
-----END PGP SIGNATURE-----


R
R
Rostislav Svoboda wrote on 11 Apr 01:44 +0200
(address . 70324@debbugs.gnu.org)
CAEtmmezz5Ome_mxMo3e6XuviYuTvbWoY4QUeEiAfOHuWr74NCA@mail.gmail.com
Toggle quote (2 lines)
> linux-libre-documentation is broken again:

Try to repeat ./bootstrap and configure

74517806f80dab17474a3c5f0b91d437e4d4e052

Cheers, Bost
L
L
Leo Famulari wrote on 11 Apr 05:12 +0200
Re: bug#70324: After upgrade of linux-libre, linux-libre-documentation fails to build
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 70324@debbugs.gnu.org)
ZhdVK4WDqH42Ph2l@jasmine.lan
On Wed, Apr 10, 2024 at 05:05:15PM +0200, Tomas Volf wrote:
Toggle quote (8 lines)
> linux-libre-documentation is broken again:
>
> starting phase `build'
> Traceback (most recent call last):
> File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in <module>
> import yaml
> ModuleNotFoundError: No module named 'yaml'

It looks like the package depends on pyyaml now. I wonder if that's
intentional. Did you search the upstream bug tracker to look for more
info?

Toggle quote (2 lines)
> How are these not caught in the CI?

What do you mean? The CI server did register the build failure:


As well as many other build failures in the kernel packages:

T
T
Tomas Volf wrote on 11 Apr 16:42 +0200
(name . Leo Famulari)(address . leo@famulari.name)(address . 70324@debbugs.gnu.org)
Zhf201svFeMkRenZ@ws
On 2024-04-10 23:12:43 -0400, Leo Famulari wrote:
Toggle quote (13 lines)
> On Wed, Apr 10, 2024 at 05:05:15PM +0200, Tomas Volf wrote:
> > linux-libre-documentation is broken again:
> >
> > starting phase `build'
> > Traceback (most recent call last):
> > File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in <module>
> > import yaml
> > ModuleNotFoundError: No module named 'yaml'
>
> It looks like the package depends on pyyaml now. I wonder if that's
> intentional. Did you search the upstream bug tracker to look for more
> info?

I did (now) and the search gives nothing. However I suspect the commit in
question would be a304fa1d10fcb974c117d391e5b4d34c2baa9a62:

docs: Makefile: Add dependency to $(YNL_INDEX) for targets other than htmldocs

Based on the diff:

+htmldocs texinfodocs latexdocs epubdocs xmldocs: $(YNL_INDEX)
+
+htmldocs:

I would assume it is the texinfodocs triggering the YNL_INDEX for us. This
snippet from the commit message:

If one of other targets such as latexdocs or epubdocs is built
without building htmldocs, missing .rst files can cause additional
WARNINGs from sphinx-build as follow:

Seems to indicate it is intentional.

Toggle quote (11 lines)
>
> > How are these not caught in the CI?
>
> What do you mean? The CI server did register the build failure:
>
> https://ci.guix.gnu.org/build/3863875/details
>
> As well as many other build failures in the kernel packages:
>
> https://ci.guix.gnu.org/eval/1228559

Right, I should have written the question differently. I am curious how this
got onto the master. Given the point 9. in (guix)Submitting Patches, and the
fact the QA should run on every patch before it is accepted, I was surprised
that the broken build of dependent package was committed.

Since this was second time in past ~two months the linux-libre-documentation
package on master was broken, I was curious if it is special in some way.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmYX9tMACgkQL7/ufbZ/
walvhg//ScRaZCH1Vt/werf9l9ytIR7kplcb5dj4Z9jR0Z5nyBN09GwV6bxMg2/I
R5JLZRpAoVsQ40x2qlpY4hLFXaFKWoLDieD3OseHr4pnD+82sHCEq+FoMDdoRzOP
JuY6tZsI6s1lRuYyLjUrYhBOBKnevAODfOLgTnAbN3lTfEKmdT2Gk7nLr/jcFsN5
ZZDJAjxIwZ5ETFnzZw6QmInZsJlVKBS5jBB130O6EMpyY9NToaDD7kygpaW3mF+U
leJ0QmMwHOKQahxvzSlRTGoDJJNDXpB/brYXqHSip5Dcw0v6LwGedBsr0ZBkEKRD
3Z0/YP9USk2bwhnya5fTlLKAeoJd5HbxB7Tf9drREwdZg9gYbQBcr0ewb/Y12dD7
08qGXqwJ3LQZw6Lxs5e8F3MEiUAS9YE4MZT7WMBXOz4scfNDJilMKfN0DPi3Gw61
RwDqS5kdBJIz88+bZsSTxTC0Lpwhp8220m+DUIRfB2Z7zo7I7Zk7ATWgA9N+wf5D
4V1DiPE47ZFCJtle4yZrzydoQjhF7l/XD8/tohwnqzRAIiSU88LZdtIgltm3OXf/
ieZ8/Fh8Fc+vpA8Up43/O6b2+wUisdVYZIEHMiaRUnps1PPrWLzLy3wTnvTvRI46
pGZcIVVCDd/jruyo4p6QKMxeTbwAUzA97n2lhkN1WkmizEuT0QY=
=Uluh
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 11 Apr 16:55 +0200
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 70324@debbugs.gnu.org)
Zhf561zU6NRKor9H@jasmine.lan
On Thu, Apr 11, 2024 at 04:42:27PM +0200, Tomas Volf wrote:
Toggle quote (9 lines)
> I would assume it is the texinfodocs triggering the YNL_INDEX for us. This
> snippet from the commit message:
>
> If one of other targets such as latexdocs or epubdocs is built
> without building htmldocs, missing .rst files can cause additional
> WARNINGs from sphinx-build as follow:
>
> Seems to indicate it is intentional.

Okay, thanks for looking. We can add a dependency on python-pyyaml and
it should work.

Toggle quote (8 lines)
> Right, I should have written the question differently. I am curious how this
> got onto the master. Given the point 9. in (guix)Submitting Patches, and the
> fact the QA should run on every patch before it is accepted, I was surprised
> that the broken build of dependent package was committed.
>
> Since this was second time in past ~two months the linux-libre-documentation
> package on master was broken, I was curious if it is special in some way.

Oh, I see. As shown on the 'kernel-updates' Cuirass jobset page, our
infrastructure at ci.guix.gnu.org can build less than of the kernel
packages successfully. So, the documentation failures are "lost in the
noise".


I'm looking for more people to help with the kernel packages, and one
person has joined the effort and that is great!

But if we want to hold the kernel packages to the normal Guix standard,
we need more help:


Based on lack of complaints, it seems that people are only using Guix's
linux-libre kernels on x86_64. Either nobody is using the other
architectures, or they are using different kernels. So bugs are seldom
reported or fixed.

Example of CI failure bugs that don't seem to affect anyone:

And qa.quix.gnu.org is too slow for kernel updates, which occur roughly
once a week. If QA takes more than one week to process the proposed
updates, then we would never catch up. The QA workflow is very good and
we should be using it, but it needs to be more powerful.
L
L
L
Leo Famulari wrote on 13 Apr 21:18 +0200
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 70324-done@debbugs.gnu.org)
ZhradPUivr2HxSB8@jasmine.lan
On Thu, Apr 11, 2024 at 03:18:49PM -0400, Leo Famulari wrote:
Toggle quote (4 lines)
> I sent a patch:
>
> https://issues.guix.gnu.org/issue/70343

This should be fixed with commit cc38699cf0cfd804a43ca1b6c8602cfc84e06117

Please let us know if you see more problems. Thanks for the report!
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 70324@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 70324
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch