public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
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 16:19:07 +0200	[thread overview]
Message-ID: <20220722161907.5dde4183@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <21000553.4csPzL39Zc@home>

Thanks! I will give that a try. Sorry for not sharing that patch, it
is trivial.

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.

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}"
> 
> do_prepare_build[cleandirs] += "${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
> }
> 
> >   
> > > 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  
> 
> 


  reply	other threads:[~2022-07-22 14:19 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 [this message]
2022-07-22 19:16       ` Henning Schild
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=20220722161907.5dde4183@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