Custom kernel build - best way to generate a package

Custom kernel build - best way to generate a package

[Jan Kiszka]

Hi all,

as indicated before, I'm looking into providing a framework for isar to
help users with building their own kernel packages from un-debianized
kernel sources. I'm now scratching my head how to do that best. Options
I'Ve found so far:

1. make bindeb-pkg (from upstream kernel)

   Downside: currently requires patches to feed in missing runtime
   dependencies of the generated package. Also, it seems this is not
   designed to create full replacements of the standard debian kernel
   packages. Might be an uphill battle on the long run.

2. Provide debian/ folder in isar so that dpkg_runbuild works

   Question is here where to pick up the debian/ folder from. The
   original debian kernel package? The version that Frank once create as
   demo [1] (BTW, how was it created?)?

3. make-kpkg

   Still unclear to me what pros and cons are here.

Any comments / suggestions would be highly appreciated!

Thanks,
Jan

[1]
https://github.com/ilbers/linux/commit/b7ab449238b8e59943849a10c95d578aa01d70e7

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: Custom kernel build - best way to generate a package

[Jan Kiszka]

On 2018-01-25 09:50, [ext] Jan Kiszka wrote:
> Hi all,
> 
> as indicated before, I'm looking into providing a framework for isar to
> help users with building their own kernel packages from un-debianized
> kernel sources. I'm now scratching my head how to do that best. Options
> I'Ve found so far:
> 
> 1. make bindeb-pkg (from upstream kernel)
> 
>    Downside: currently requires patches to feed in missing runtime
>    dependencies of the generated package. Also, it seems this is not
>    designed to create full replacements of the standard debian kernel
>    packages. Might be an uphill battle on the long run.
> 
> 2. Provide debian/ folder in isar so that dpkg_runbuild works
> 
>    Question is here where to pick up the debian/ folder from. The
>    original debian kernel package? The version that Frank once create as
>    demo [1] (BTW, how was it created?)?
> 
> 3. make-kpkg
> 
>    Still unclear to me what pros and cons are here.

Just played with it, and it also generates packages that are not meant
to be replacements of the standard debian kernel - incomplete deps. At
least under jessie.

Jan

> 
> Any comments / suggestions would be highly appreciated!
> 
> Thanks,
> Jan
> 
> [1]
> https://github.com/ilbers/linux/commit/b7ab449238b8e59943849a10c95d578aa01d70e7
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: Custom kernel build - best way to generate a package

[Jan Kiszka]

[re-adding the list]

On 2018-01-25 19:24, Benedikt Niedermayr wrote:
> Am 25.01.2018 um 13:56 schrieb Jan Kiszka:
>> On 2018-01-25 09:50, [ext] Jan Kiszka wrote:
>>> Hi all,
>>>
>>> as indicated before, I'm looking into providing a framework for isar to
>>> help users with building their own kernel packages from un-debianized
>>> kernel sources. I'm now scratching my head how to do that best. Options
>>> I'Ve found so far:
>>>
>>> 1. make bindeb-pkg (from upstream kernel)
>>>
>>>     Downside: currently requires patches to feed in missing runtime
>>>     dependencies of the generated package. Also, it seems this is not
>>>     designed to create full replacements of the standard debian kernel
>>>     packages. Might be an uphill battle on the long run.
>>>
>>> 2. Provide debian/ folder in isar so that dpkg_runbuild works
>>>
>>>     Question is here where to pick up the debian/ folder from. The
>>>     original debian kernel package? The version that Frank once
>>> create as
>>>     demo [1] (BTW, how was it created?)?
>>>
>>> 3. make-kpkg
>>>
>>>     Still unclear to me what pros and cons are here.
>> Just played with it, and it also generates packages that are not meant
>> to be replacements of the standard debian kernel - incomplete deps. At
>> least under jessie.
>>
>> Jan
>>
>>> Any comments / suggestions would be highly appreciated!
>>>
>>> Thanks,
>>> Jan
>>>
>>> [1]
>>> https://github.com/ilbers/linux/commit/b7ab449238b8e59943849a10c95d578aa01d70e7
>>>
>>>
> Hi,
> 
> 
>> 2. Provide debian/ folder in isar so that dpkg_runbuild works
> This would be my favorite one. Using a debian/ folder seems to be the
> most generic solution.
> 
> Because then we are able to use a generic class which creates debian
> packages in general for any kind of software package.
> 
> The  "make-kpkg" solution might work very good for the kernel itself....
> but only for the kernel. That represents a disadvantage for me.

Well, this case is about the kernel itself, only. The control files
needed to build the kernel are not reusable for other tasks.

> 
> Are there any proposals or ideas for generic "debianization" of software
> packages yet? I think when it comes to that point, we will realize that
> the most generic way of creating
> 
> debian packages will take precedence, since it comes with a generic
> workflow.
> 
> Otherwise we will have different solutions for different types of
> software packages.
> 
> 
> What I have implemented for know, was a generic debianization with:
> 
> 1. Generate the debian control file (fill with dependencies to other
> packages, built with Isar )
> 
> 2. Generate the debian "rules" makefile
> 
> 3. Run dh_make
> 
> 4. Run dpkg-buildpackage
> 
> It's a generic workflow and can be applied to any software package. It
> can also be turned off, if a software package already contains the
> required files within its debian folder.
> 
> 
> I will try to create patch series based on upstream Isar. For know its
> "only" a working solution within my Isar fork.
> 

But did you check dpkg-raw in upstream? It's not full debianization, but
at least packaging of pre-existing files with some degree of
customization. One should also be able to combine it with build steps
prior to running the packaging, though purists say that this is better
handled with real debian control files.

Of course, whenever we can generalize common tasks, just parameterizing
their details, that could be offered as class for reuse.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: Custom kernel build - best way to generate a package

[Benedikt Niedermayr]

Am 25.01.2018 um 19:36 schrieb Jan Kiszka:
> [re-adding the list]
>
> On 2018-01-25 19:24, Benedikt Niedermayr wrote:
>> Am 25.01.2018 um 13:56 schrieb Jan Kiszka:
>>> On 2018-01-25 09:50, [ext] Jan Kiszka wrote:
>>>> Hi all,
>>>>
>>>> as indicated before, I'm looking into providing a framework for isar to
>>>> help users with building their own kernel packages from un-debianized
>>>> kernel sources. I'm now scratching my head how to do that best. Options
>>>> I'Ve found so far:
>>>>
>>>> 1. make bindeb-pkg (from upstream kernel)
>>>>
>>>>      Downside: currently requires patches to feed in missing runtime
>>>>      dependencies of the generated package. Also, it seems this is not
>>>>      designed to create full replacements of the standard debian kernel
>>>>      packages. Might be an uphill battle on the long run.
>>>>
>>>> 2. Provide debian/ folder in isar so that dpkg_runbuild works
>>>>
>>>>      Question is here where to pick up the debian/ folder from. The
>>>>      original debian kernel package? The version that Frank once
>>>> create as
>>>>      demo [1] (BTW, how was it created?)?
>>>>
>>>> 3. make-kpkg
>>>>
>>>>      Still unclear to me what pros and cons are here.
>>> Just played with it, and it also generates packages that are not meant
>>> to be replacements of the standard debian kernel - incomplete deps. At
>>> least under jessie.
>>>
>>> Jan
>>>
>>>> Any comments / suggestions would be highly appreciated!
>>>>
>>>> Thanks,
>>>> Jan
>>>>
>>>> [1]
>>>> https://github.com/ilbers/linux/commit/b7ab449238b8e59943849a10c95d578aa01d70e7
>>>>
>>>>
>> Hi,
>>
>>
>>> 2. Provide debian/ folder in isar so that dpkg_runbuild works
>> This would be my favorite one. Using a debian/ folder seems to be the
>> most generic solution.
>>
>> Because then we are able to use a generic class which creates debian
>> packages in general for any kind of software package.
>>
>> The  "make-kpkg" solution might work very good for the kernel itself....
>> but only for the kernel. That represents a disadvantage for me.
> Well, this case is about the kernel itself, only. The control files
> needed to build the kernel are not reusable for other tasks.
>
>> Are there any proposals or ideas for generic "debianization" of software
>> packages yet? I think when it comes to that point, we will realize that
>> the most generic way of creating
>>
>> debian packages will take precedence, since it comes with a generic
>> workflow.
>>
>> Otherwise we will have different solutions for different types of
>> software packages.
>>
>>
>> What I have implemented for know, was a generic debianization with:
>>
>> 1. Generate the debian control file (fill with dependencies to other
>> packages, built with Isar )
>>
>> 2. Generate the debian "rules" makefile
>>
>> 3. Run dh_make
>>
>> 4. Run dpkg-buildpackage
>>
>> It's a generic workflow and can be applied to any software package. It
>> can also be turned off, if a software package already contains the
>> required files within its debian folder.
>>
>>
>> I will try to create patch series based on upstream Isar. For know its
>> "only" a working solution within my Isar fork.
>>
> But did you check dpkg-raw in upstream? It's not full debianization, but
> at least packaging of pre-existing files with some degree of
> customization. One should also be able to combine it with build steps
> prior to running the packaging, though purists say that this is better
> handled with real debian control files.
>
> Of course, whenever we can generalize common tasks, just parameterizing
> their details, that could be offered as class for reuse.
>
> Jan
>

> Well, this case is about the kernel itself, only. The control files
> needed to build the kernel are not reusable for other tasks.
I did not catch how kernel control file differs from other control files 
(apart from dependencies) ?

> But did you check dpkg-raw in upstream? It's not full debianization, but
> at least packaging of pre-existing files with some degree of
> customization. One should also be able to combine it with build steps
> prior to running the packaging, though purists say that this is better
> handled with real debian control files.
>
> Of course, whenever we can generalize common tasks, just parameterizing
> their details, that could be offered as class for reuse.
That's a good and smart solution for the beginning I think.

Next step could be to generate Build-Depends and Depends for the control 
file?


Benni

Re: Custom kernel build - best way to generate a package

[Henning Schild]

Am Thu, 25 Jan 2018 09:50:14 +0100
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

> Hi all,
> 
> as indicated before, I'm looking into providing a framework for isar
> to help users with building their own kernel packages from
> un-debianized kernel sources. I'm now scratching my head how to do
> that best. Options I'Ve found so far:
> 
> 1. make bindeb-pkg (from upstream kernel)
> 
>    Downside: currently requires patches to feed in missing runtime
>    dependencies of the generated package. Also, it seems this is not
>    designed to create full replacements of the standard debian kernel
>    packages. Might be an uphill battle on the long run.

We do have an internal recipe to build a kernel like that. Ben
suggested that as a viable approach. I later found that such a kernel
has a pretty broken control-file and suggested an upstream patch.
https://lkml.org/lkml/2017/11/27/659

> 2. Provide debian/ folder in isar so that dpkg_runbuild works
> 
>    Question is here where to pick up the debian/ folder from. The
>    original debian kernel package? The version that Frank once create
> as demo [1] (BTW, how was it created?)?

Maybe Ben can enlighten us, i guess the folder is maintained for a
specific kernel and can not be fetched from somewhere to match a wide
range of versions.
 
> 3. make-kpkg
> 
>    Still unclear to me what pros and cons are here.

I think that one is dying and we would have to have a close look at the
control-information, probably also broken. Last thing i remember from
another project is, that it produced broken header-packages.

Maybe there is a 4. and 5. that we are not aware of? Ben?

Henning

> Any comments / suggestions would be highly appreciated!
> 
> Thanks,
> Jan
> 
> [1]
> https://github.com/ilbers/linux/commit/b7ab449238b8e59943849a10c95d578aa01d70e7
>