From: Henning Schild <henning.schild@siemens.com>
To: Uladzimir Bely <ubely@ilbers.de>
Cc: isar-users <isar-users@googlegroups.com>
Subject: Re: sbuild migration help needed
Date: Fri, 22 Jul 2022 21:16:56 +0200 [thread overview]
Message-ID: <20220722211656.6ab7aceb@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <20220722161907.5dde4183@md1za8fc.ad001.siemens.net>
Am Fri, 22 Jul 2022 16:19:07 +0200
schrieb Henning Schild <henning.schild@siemens.com>:
> Thanks! I will give that a try. Sorry for not sharing that patch, it
> is trivial.
In fact that patch also does not apply anymore but did before sbuild.
You made it a
echo "\noverride_dh_usrlocal:" >> ${S}/debian/rules
And i ended up turning into another sed.
> I find it a little worrying that a recipe which worked perfectly
> before all of a sudden has to be significantly changed. If there
> would have been a forgotten build-dep i would have been happy, but
> here we have a maybe dramatic change in how the recipe needs to be
> written.
This recipe was easy enough to share but it shows a fundamental change
in isar. Where before sbuild all of WORKDIR became available in the
buildchroot, now we only get S.
I would not know how many other recipes in countless layers would care,
but maybe we can somehow get back to WORKDIR and not only S being
mounted and usable in the chroot.
That recipe is a classic hack where one just packages something with
deb_debianize and the patch features of isar. Being forced to move code
around to arrange an S where WORKDIR would simply work (and be
patchable) is not nice. More involved projects might require more
involved "constructing S" steps.
We are moving code around and patching Makefile here, so all of a
sudden you need to really understand what you previously could
deb_debianize around with.
I guess the whole thing is relevant for projects where parts of the
code you care about live in a bigger repo.
> I will change it as you suggested. Thanks again! But we will have to
> look out for such big changes breaking existing recipes. All the big
> API changes can and will cause a lot of frustration in all the various
> layers.
>
> And there are the known ones, which are in the changelog ... plus the
> ones that just happen ... like this one, or the meson/ccache i just
> sent a patch for.
>
> Henning
>
> --
> Index: ifdtool/Makefile
> ===================================================================
> --- ifdtool.orig/Makefile
> +++ ifdtool/Makefile
> @@ -6,7 +6,7 @@ PROGRAM = ifdtool
>
> CC = gcc
> INSTALL = /usr/bin/env install
> -PREFIX = /usr/local
> +PREFIX = /usr
> CFLAGS = -O2 -g -Wall -Wextra -Wmissing-prototypes -Werror
> CFLAGS += -I../../src/commonlib/include
> -I../../src/commonlib/bsd/include CFLAGS += -I../cbfstool/flashmap
> --
>
>
> Am Fri, 22 Jul 2022 16:08:45 +0300
> schrieb Uladzimir Bely <ubely@ilbers.de>:
>
> > In the email from Friday, 22 July 2022 14:11:19 +03 user Uladzimir
> > Bely wrote:
> > > In the email from Friday, 22 July 2022 12:16:35 +03 user Henning
> > > Schild
> > wrote:
> > > > Hi,
> > > >
> > > > i have a recipe where i am building just a util from a bigger
> > > > package, so my S is somewhere inside WORKDIR and some headers
> > > > are below S.
> > > >
> > > > With sbuild that recipe stopped working, not finding those
> > > > headers anymore. I did not yet look into the details, but maybe
> > > > only S get put into that chroot and not all of WORKDIR.
> > >
> > > I've looked a bit at the problem.
> > >
> > > Sbulid doesn't use WORKDIR at all, but builds the package basing
> > > on its .dsc file. It happens that generated `ifdtool_4.14.dsc`
> > > refers to `ifdtool_4.14.tar.gz`, which simply doesn't contain
> > > upper directories.
> > >
> > > I think, something more complex than automatic `deb_debianize`
> > > should be used here.
> >
> > For instance, it worked for me in form of separate ${S} directory
> > where I copy required files and modify Makefile to fit new directory
> > structure:
> >
> > inherit dpkg
> >
> > DESCRIPTION = "Tool for Fast, secure and flexible OpenSource
> > firmware"
> >
> > SRC_URI =
> > "https://github.com/coreboot/coreboot/archive/${PV}.tar.gz"
> > SRC_URI[sha256sum] =
> > "73740c313935f21964577fd6621f9acaddf1244cc704e88046f854d93ed6feab"
> >
> > DEBIAN_DEPENDS = "\${misc:Depends}"
> >
> > S = "${WORKDIR}/${PN}-${PV}"
this is nothing but WORKDIR/P ... the default ... can be skipped
> >
> > do_prepare_build[cleandirs] += "${S}/debian"
has to be S not S/debian
> > do_prepare_build() {
> > cp -rf ${WORKDIR}/coreboot-${PV}/util/${PN}/* ${S}/
> >
> > # Copy required sources from upper directories
> > cp -rf ${WORKDIR}/coreboot-${PV}/util/cbfstool/flashmap
> > ${S}/ mkdir -p ${S}/commonlib/include
> > cp -rf ${WORKDIR}/coreboot-${PV}/src/commonlib/include/*
> > ${S}/ commonlib/include/
> > mkdir -p ${S}/commonlib/bsd/include
> > cp -rf ${WORKDIR}/coreboot-${PV}/src/commonlib/bsd/include/*
> > ${S}/ commonlib/bsd/include/
> > # Fix include paths
> > sed -i -e "s/\.\.\/cbfstool\/flashmap/flashmap/g"
> > ${S}/Makefile sed -i -e "s/\.\.\/\.\.\/src\/commonlib/commonlib/g"
> > ${S}/Makefile
> >
> > deb_debianize
> > echo "\noverride_dh_usrlocal:" >> ${S}/debian/rules
> > }
Thanks again. I managed to get my layer to build with your input and
ended up simply taking most of your code!
But again i think that isar could maybe learn to put the whole WORKDIR
into the chroot, where S would be a subdir. So that good old patching
and good old recipes remain working.
Not sure we really want that, but this very recipe could become part of
the tests. As a showcase of "we care about some parts" and
"deb_debianize" them out of the whole thing. Possibly .. ing below S
Henning
> >
> > >
> > > > Here is the recipe:
> > > >
> > > > ifdtool_4.14.bb:
> > > > --
> > > > inherit dpkg
> > > >
> > > > DESCRIPTION = "Tool for Fast, secure and flexible OpenSource
> > > > firmware"
> > > >
> > > > SRC_URI =
> > > > "https://github.com/coreboot/coreboot/archive/${PV}.tar.gz"
> > > > SRC_URI[sha256sum] =
> > > > "73740c313935f21964577fd6621f9acaddf1244cc704e88046f854d93ed6feab"
> > > > SRC_URI += "file://Makefile-prefix.patch"
> > > >
> > > > DEBIAN_DEPENDS = "\${misc:Depends}"
> > > >
> > > > S = "${WORKDIR}/coreboot-${PV}/util/${PN}"
> > > >
> > > > do_prepare_build[cleandirs] += "${S}/debian"
> > > > do_prepare_build() {
> > > >
> > > > deb_debianize
> > > >
> > > > }
> > > > --
> > > >
> > > > Henning
> >
> >
>
next prev parent reply other threads:[~2022-07-22 19:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-22 9:16 Henning Schild
2022-07-22 10:20 ` Uladzimir Bely
2022-07-22 11:11 ` Uladzimir Bely
2022-07-22 13:08 ` Uladzimir Bely
2022-07-22 14:19 ` Henning Schild
2022-07-22 19:16 ` Henning Schild [this message]
2022-07-23 6:40 ` Uladzimir Bely
2022-07-25 6:47 ` Moessbauer, Felix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220722211656.6ab7aceb@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=ubely@ilbers.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox