Linutronix / elbe

Embedded Linux Build Environment
https://elbe-rfs.org
GNU General Public License v3.0
163 stars 59 forks source link

Elbe fails to find the source of kernel package #382

Closed schlatterbeck closed 8 months ago

schlatterbeck commented 11 months ago

I'm building a kernel package using the deb-pkg target in the mainline kernel (in fact 6.1.42 from Greg KH's stable series with a set of my own patches, that's where the '+' in the version comes from). This is put into my own debian-dist.

This produces

linux-headers-6.1.42+_6.1.42+-1_armhf.deb
linux-image-6.1.42+_6.1.42+-1_armhf.deb
linux-libc-dev_6.1.42+-1_armhf.deb

And for the sources:

linux-upstream_6.1.42+-1_armhf.changes
linux-upstream_6.1.42+-1.dsc
linux-upstream_6.1.42+.orig.tar.gz

Note the missing '-1' in the orig.tar.gz

All binary packages have a header line Source: linux-upstream

And the 'Sources' file in the debian mirror has

Package: linux-upstream
...
Checksums-Sha1:
 54778e44fd1daf1b40ea0f3c6cf11df04416ec29 1033 linux-upstream_6.1.42+-1.dsc
 a67caa255368105c8ea6bd2ce607766f1e408ca4 225785612 linux-upstream_6.1.42+.orig.tar.gz
 ccefe9f74fd0acccab3a3eb003d600d6ca1c16d1 489761 linux-upstream_6.1.42+-1.diff.gz
Checksums-Sha256:
 81f4ff03f6fd12aa09f3b56a714b92f7493e97b07d84a6bd1c0a0fcbb70fa540 1033 linux-upstream_6.1.42+-1.dsc
 a5936466890c710fd9c65378b96cd637bf2a093583ab65ed1ed7dfc906fb7d42 225785612 linux-upstream_6.1.42+.orig.tar.gz
 999056a2075f207465ed25b8ae154883ae0216ba94382232720769f9fc0d57a9 489761 linux-upstream_6.1.42+-1.diff.gz
Files:
 90eaeee8de41906de953b996200931cc 1033 linux-upstream_6.1.42+-1.dsc
 38ff404326815048dbb2c1ee54cd06fc 225785612 linux-upstream_6.1.42+.orig.tar.gz
 cfed7986f690d2329f2e825a2804b59b 489761 linux-upstream_6.1.42+-1.diff.gz

But Elbe complains (in log.txt when downloading files after failed build): [ERROR]No sources for package 'linux-upstream-6.1.42+-1': No source found for linux-upstream_6.1.42+-1

It looks like it is searching for the orig.tar.gz with the '-1' in the name. Unfortunately the default when building a kernel package using the mainline deb-pkg target does not include '-1'. So Elbe probably should properly use the 'Files' entry in the Sources file when considering source files.

If the '-1' is not the reason for that error message, please let me know how I can diagnose this.

jogness commented 11 months ago

I'm building a kernel package using the deb-pkg target in the mainline kernel ...

But Elbe complains (in log.txt when downloading files after failed build): [ERROR]No sources for package 'linux-upstream-6.1.42+-1': No source found for linux-upstream_6.1.42+-1

It is known that the deb-pkg target in mainline Linux does not produce proper Debian packages. This should be fixed in mainline Linux.

It looks like it is searching for the orig.tar.gz with the '-1' in the name. Unfortunately the default when building a kernel package using the mainline deb-pkg target does not include '-1'.

It is correct that the '-1' is not in the orig name. The problem is the debianization from the deb-pkg target.

schlatterbeck commented 11 months ago

On Tue, Aug 01, 2023 at 05:41:03AM -0700, John Ogness wrote:

I'm building a kernel package using the deb-pkg target in the mainline kernel ...

But Elbe complains (in log.txt when downloading files after failed build): [ERROR]No sources for package 'linux-upstream-6.1.42+-1': No source found for linux-upstream_6.1.42+-1

It is known that the deb-pkg target in mainline Linux does not produce proper Debian packages. This should be fixed in mainline Linux.

Hmm, I've traced today all the debian-repo format and the parsing in Elbe and it seems it should be compatible. Elbe should correctly parse the 'Files' section in the Sources. And the filename appears correctly there.

But it seems that Elbe doesn't recognize my Repo as having sources. In /var/cache/elbe/[uid]/chroot/etc/apt/sources.list in the elbe VM I have:

deb-src [trusted=yes] http://bee.priv.zoo/debian bookworm main deb [trusted=yes arch=armhf] http://bee.priv.zoo/debian bookworm main deb [trusted=yes] http://bee.priv.zoo/debian bookworm-updates main deb [trusted=yes] http://cat.priv.zoo:9999/debian-dist bookworm main

where the bee.priv.zoo urls are my local debian repo (also listed as primary_host in the section of elbe.xml) and the cat.priv.zoo:9999 url is the repo used for the kernel. Note that the latter doesn't have a deb-src entry.

The entry for cat.priv.zoo:9999 in the xml is

http://cat.priv.zoo:9999/debian-dist bookworm main http://cat.priv.zoo:9999/debian-dist/pubring.asc

Maybe I need to add something there so that the sources are also used? Note that the sources work for that repo, when I add this manually to sources.list I can successfully download sources.

So it seems to be a problem of the configuration of the sources not the file names, at least downloading the sources is not tried at all currently.

Maybe I'm missing something in the elbe config (but I think this used to work in an older version, or missing sources did not fail the build previously)

Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: @.***

jogness commented 11 months ago

The source repositories must be specified. See https://github.com/Linutronix/elbe/blob/master/examples/armhf-ubuntu.xml#L23 as an example.

schlatterbeck commented 11 months ago

I've now added the source repos to my XML spec and it works as expected: I get a successful build.

But: Specifying the same URL twice, first in the <binary> and then in the <source> tag seems redundant. Is it possible that previous version of ELBE used the URL in <binary> as the default also for <source>? Also why is it guessing the source URL correctly for the <primary_host> in section <mirror> but not for the other URLs??? At least with the previous configuration, the build was not failing with older versions of ELBE (probably as far back as debian old-old-stable aka buster), so either the missing source for the kernel was ignored (and the build succeeded anyway) or the source URL was guessed somehow.

I think we can close this after some clarifications, I really want to find out why this worked previously. And at least the kernel's deb-pkg target is not in error.