FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-14-2012, 08:15 PM
Michael Tokarev
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

In qemu package there's a source file, pc-bios/spapr-rtas/spapr-rtas.S,
which is an PPC assembly file with exactly 5 instructions:

#define KVMPPC_HCALL_BASE 0xf000
#define KVMPPC_H_RTAS (KVMPPC_HCALL_BASE + 0x0)

.globl _start
_start:
mr 4,3
lis 3,KVMPPC_H_RTAS@h
ori 3,3,KVMPPC_H_RTAS@l
sc 1
blr

(it is "Trivial in-partition RTAS implementation, based on a hypercall").

This file is also included in the upstream source in compiled
form, as pc-bios/spapr-rtas.bin. This is because it needs
ppc assembler to compile, and not every system out there has
this tool ready available. The resulting .bin file is 20
bytes long, here's the disassembly output of it:

objdump -b binary -m powerpc:common -EB -D pc-bios/spapr-rtas.bin

0: 7c 64 1b 78 mr r4,r3
4: 3c 60 00 00 lis r3,0
8: 60 63 f0 00 ori r3,r3,61440
c: 44 00 00 22 sc 1
10: 4e 80 00 20 blr


But qemu builds basically on all platforms, and on each platform
it runs, it needs this .bin file to run (emulated) PPC platform.

So we have the following options:

1) package just this single file, of 20 bytes long, in a
separate Arch:all package, in it's own separate source.

2) drop ppc support where this file is required.

Neither of which appears to be good solution.

I think there's on other possibility. But I'm not sure
whenever it can be considered DFSG-clean.

I can ship something like the above disassembly code,
and build the .bin file during package build time using
just hex tools, on all patforms. The source and hex-binary
will both be platform-independent. But on PPC platform,
at build time, I can actually build the .bin file using
the upstream method by calling real compiler/linker/objcopy,
and can compare the result with the result of processing
the hex-binary, and fail if they don't match -- this is to
catch changes in toolchain or the upstream source.

This way, due to trivial nature of the file, we can, with
grain of salt, say that the source is actually modifiable
using just the tools listed in Build-depends, in a form
of hand-crafted binary assembly. If you know the assembler
(description of which is not listed as Build-depends!),
you can hand-translate a several-instructions-long program
from source into binary form by looking up assembly instruction
codes in the manual.

This is a bit of cheating, but I still think it is better
than to create a separate source package just with that
file.

Comments?

Thanks,

/mjt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50539077.1080501@msgid.tls.msk.ru">http://lists.debian.org/50539077.1080501@msgid.tls.msk.ru
 
Old 09-14-2012, 08:31 PM
Bastian Blank
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

On Sat, Sep 15, 2012 at 12:15:51AM +0400, Michael Tokarev wrote:
> This file is also included in the upstream source in compiled
> form, as pc-bios/spapr-rtas.bin. This is because it needs
> ppc assembler to compile, and not every system out there has
> this tool ready available.

binutils-multiarch?

Bastian

--
Dammit Jim, I'm an actor, not a doctor.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120914203116.GA24444@wavehammer.waldi.eu.org">ht tp://lists.debian.org/20120914203116.GA24444@wavehammer.waldi.eu.org
 
Old 09-14-2012, 08:55 PM
Michael Tokarev
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

On 15.09.2012 00:31, Bastian Blank wrote:
> On Sat, Sep 15, 2012 at 12:15:51AM +0400, Michael Tokarev wrote:
>> This file is also included in the upstream source in compiled
>> form, as pc-bios/spapr-rtas.bin. This is because it needs
>> ppc assembler to compile, and not every system out there has
>> this tool ready available.
>
> binutils-multiarch?

Binutils-multiarch, despite its name, does not include assembler.
Only size, strip, objdump, nm, and a few other misc. utils.

/mjt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 505399C5.5020407@msgid.tls.msk.ru">http://lists.debian.org/505399C5.5020407@msgid.tls.msk.ru
 
Old 09-14-2012, 09:03 PM
Kurt Roeckx
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

On Sat, Sep 15, 2012 at 12:15:51AM +0400, Michael Tokarev wrote:
>
> So we have the following options:
>
> 1) package just this single file, of 20 bytes long, in a
> separate Arch:all package, in it's own separate source.
>
> 2) drop ppc support where this file is required.

3) Just ship the .bin part together with the rest.

I don't see a problem with it not complying with the DFSG, the
source is available and it's possible to build with with something
else in main, just not on all arches.

As far as I know, we don't have a requirement that everything
needs to be build from source, just that we can do it.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120914210335.GA17054@roeckx.be">http://lists.debian.org/20120914210335.GA17054@roeckx.be
 
Old 09-14-2012, 09:11 PM
Michael Tokarev
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

On 15.09.2012 01:03, Kurt Roeckx wrote:
> On Sat, Sep 15, 2012 at 12:15:51AM +0400, Michael Tokarev wrote:
>>
>> So we have the following options:
>>
>> 1) package just this single file, of 20 bytes long, in a
>> separate Arch:all package, in it's own separate source.
>>
>> 2) drop ppc support where this file is required.
>
> 3) Just ship the .bin part together with the rest.
>
> I don't see a problem with it not complying with the DFSG, the
> source is available and it's possible to build with with something
> else in main, just not on all arches.

Well, in that case we can ship alot more .bin files from qemu
sources too, and build these on corresponding architecturs like
already mentioned (to verify the result is still the same).
Additional x86 ROMs, sparc ROMs, this PPC ROM, ...

The only problem is to get some real agreement on this.

> As far as I know, we don't have a requirement that everything
> needs to be build from source, just that we can do it.

Yes, this same qemu uses a few Arch:all packages (like seabios
and vgabios, openbios and a few more) which can be built on
just one architecture (seabios on x86, openbios on sparc, etc),
and from this point of view, _whole_ qemu (together with all
dependencies) can't be built on any one architecture already.

But I'm still a bit, well, uncomfortable to ship the blobs,
even if the source is available and it is verified on buildds
during package build on corresponding architectures.

Allowing such packaging may act as a bad example in the future.

And yes, that'd be the BEST option, ever, from whole packaging
point of view, including debian archive management too.

Thanks,

/mjt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50539D93.3050809@msgid.tls.msk.ru">http://lists.debian.org/50539D93.3050809@msgid.tls.msk.ru
 
Old 09-14-2012, 09:37 PM
Kurt Roeckx
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

On Sat, Sep 15, 2012 at 01:11:47AM +0400, Michael Tokarev wrote:
> On 15.09.2012 01:03, Kurt Roeckx wrote:
> > On Sat, Sep 15, 2012 at 12:15:51AM +0400, Michael Tokarev wrote:
> >>
> >> So we have the following options:
> >>
> >> 1) package just this single file, of 20 bytes long, in a
> >> separate Arch:all package, in it's own separate source.
> >>
> >> 2) drop ppc support where this file is required.
> >
> > 3) Just ship the .bin part together with the rest.
> >
> > I don't see a problem with it not complying with the DFSG, the
> > source is available and it's possible to build with with something
> > else in main, just not on all arches.
>
> Well, in that case we can ship alot more .bin files from qemu
> sources too, and build these on corresponding architecturs like
> already mentioned (to verify the result is still the same).
> Additional x86 ROMs, sparc ROMs, this PPC ROM, ...
>
> The only problem is to get some real agreement on this.
>
> > As far as I know, we don't have a requirement that everything
> > needs to be build from source, just that we can do it.
>
> Yes, this same qemu uses a few Arch:all packages (like seabios
> and vgabios, openbios and a few more) which can be built on
> just one architecture (seabios on x86, openbios on sparc, etc),
> and from this point of view, _whole_ qemu (together with all
> dependencies) can't be built on any one architecture already.
>
> But I'm still a bit, well, uncomfortable to ship the blobs,
> even if the source is available and it is verified on buildds
> during package build on corresponding architectures.
>
> Allowing such packaging may act as a bad example in the future.

I do agree it's best to try and build everything from source. But
I don't see the value for an assembler file.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120914213710.GA17980@roeckx.be">http://lists.debian.org/20120914213710.GA17980@roeckx.be
 
Old 09-14-2012, 09:49 PM
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

On Sep 14, Michael Tokarev <mjt@tls.msk.ru> wrote:

> Well, in that case we can ship alot more .bin files from qemu
> sources too, and build these on corresponding architecturs like
> already mentioned (to verify the result is still the same).
> Additional x86 ROMs, sparc ROMs, this PPC ROM, ...
>
> The only problem is to get some real agreement on this.
This is an old issue which is well established, widely agreed and
does not really need to be discussed again. The facts are:
- if the source and the tools to build them are in Debian, then
there is no DFSG issue
- if some binary is shipped in the source package and not rebuilt
automatically every time the package is built, then this is acceptable
as long as the security team will not complain

So I recommend that you ship this tiny program pre-built and add a
target to debian/rules which manually rebuilds it.

> Allowing such packaging may act as a bad example in the future.
We have already allowed them for a very long time.
I cannot think of any examples right now, but I remember having this
same conversation on debian-devel@ at least twice.

--
ciao,
Marco
 
Old 09-15-2012, 12:03 AM
Ben Hutchings
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

On Fri, 2012-09-14 at 23:49 +0200, Marco d'Itri wrote:
> On Sep 14, Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> > Well, in that case we can ship alot more .bin files from qemu
> > sources too, and build these on corresponding architecturs like
> > already mentioned (to verify the result is still the same).
> > Additional x86 ROMs, sparc ROMs, this PPC ROM, ...
> >
> > The only problem is to get some real agreement on this.
> This is an old issue which is well established, widely agreed and
> does not really need to be discussed again. The facts are:
> - if the source and the tools to build them are in Debian, then
> there is no DFSG issue

Right, absolutely.

> - if some binary is shipped in the source package and not rebuilt
> automatically every time the package is built, then this is acceptable
> as long as the security team will not complain
>
> So I recommend that you ship this tiny program pre-built and add a
> target to debian/rules which manually rebuilds it.
>
> > Allowing such packaging may act as a bad example in the future.
> We have already allowed them for a very long time.
> I cannot think of any examples right now, but I remember having this
> same conversation on debian-devel@ at least twice.

firmware-free (which doesn't even have the debian/rules target, but I'll
look into it if the sources ever do change).

Ben.

--
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky
 
Old 09-15-2012, 08:03 AM
"Bernhard R. Link"
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

* Michael Tokarev <mjt@tls.msk.ru> [120914 23:12]:
> But I'm still a bit, well, uncomfortable to ship the blobs,
> even if the source is available and it is verified on buildds
> during package build on corresponding architectures.
>
> Allowing such packaging may act as a bad example in the future.
>
> And yes, that'd be the BEST option, ever, from whole packaging
> point of view, including debian archive management too.

We currently do not ensure hard that other things can be built
either. Things were able to build when they were uploaded and
sometimes thankfully someone even checks if they still build
(and judging from the many FTBFS bugs filed in the process,
being buildable back then and being buildable now is really not
the same). So I don't see why storing the result and comparing
it to a newly built one (and failing if it does not match) on
the corresponding architecture is not quite a good solution
( if you want to make it even better, you can set up a regular
private rebuild on that architecture to make sure it still is
buildable all the time... ;-> )

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120915080309.GA30348@client.brlink.eu">http://lists.debian.org/20120915080309.GA30348@client.brlink.eu
 
Old 09-18-2012, 10:31 AM
Ian Jackson
 
Default packaging a tiny/trivial blob in a DFSG-clean way?

Marco d'Itri writes ("Re: packaging a tiny/trivial blob in a DFSG-clean way?"):
> This is an old issue which is well established, widely agreed and
> does not really need to be discussed again. The facts are:
> - if the source and the tools to build them are in Debian, then
> there is no DFSG issue
> - if some binary is shipped in the source package and not rebuilt
> automatically every time the package is built, then this is acceptable
> as long as the security team will not complain
>
> So I recommend that you ship this tiny program pre-built and add a
> target to debian/rules which manually rebuilds it.

I think this is the right answer.

Perhaps this should be documented somewhere.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20568.19871.786821.170591@chiark.greenend.org.uk"> http://lists.debian.org/20568.19871.786821.170591@chiark.greenend.org.uk
 

Thread Tools




All times are GMT. The time now is 05:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org