On Mon, Jul 24, 2006 at 06:16:20PM +0200, Stefan Reinauer wrote:

I would start out with "linuxbios-utils" as the only package and pack flashrom, the lxbios tool (see fm). If you want to make it more generic, you could call it firmware-utils or bios-utils and pack openbios' toke and detok with it.

And also Anton Borisov's bios extraction tools: Award BIOS: http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz AMI BIOS: http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz Insyde BIOS: http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz Phoenix BIOS: http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz Thanks, Ward. -- Ward Vandewege <ward@fsf.org> Free Software Foundation - Senior System Administrator

On Mon, Jul 24, 2006 at 07:43:42PM +0200, Uwe Hermann wrote:

...

Award BIOS: http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz AMI BIOS: http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz Insyde BIOS: http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz Phoenix BIOS: http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz

I'll have a look at them - if the license permits I'll package them.

Anton may have to clarify the license a bit. He did indicate to me that he was planning to release these under the GPL, but I'm not sure if all the source packages contain the proper files. Thanks, Ward. -- Ward Vandewege <ward@fsf.org> Free Software Foundation - Senior System Administrator

Ward Vandewege wrote:

On Mon, Jul 24, 2006 at 06:16:20PM +0200, Stefan Reinauer wrote:

...

I would start out with "linuxbios-utils" as the only package and pack flashrom, the lxbios tool (see fm). If you want to make it more generic, you could call it firmware-utils or bios-utils and pack openbios' toke and detok with it.

And also Anton Borisov's bios extraction tools:

Award BIOS: http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz AMI BIOS: http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz Insyde BIOS: http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz Phoenix BIOS: http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz

I have noticed that Debian has only * AmiDeco (amideco) * PhoenixDeco (phnxdeco) * AwarDeco (awardeco) Not packaged is * InsyDeco (insydeco) I couldn't find any source for * AcerDeco (acerdeco) * CompaqDeco (cmpqdeco) * HPDeco (hpdeco) * DellDeco (delldeco) @Ward: Where did you get the links from and are there possibly more of them? @Uwe: Any reason why InsyDeco was not packaged? Regards, Carl-Daniel

Hi, On Mon, Jul 24, 2006 at 06:16:20PM +0200, Stefan Reinauer wrote:

...

linuxbios - metapackage which draws in all/most other packages

ie. the other two?

Yes, basically. Maybe there will be more, not sure yet.

...

linuxbios-doc - documentation linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...

romcc is recompiled each time an image is built (which takes a lot less time than running romcc)

Is this a strict requirement? Wouldn't it be possible to compile it once, and distribute it as /usr/bin/romcc in the Debian package? Are any compile-time options involved (vs. runtime/commandline options?)

...

Maybe also something like linuxbios-src which contains the rest, and which can be used to compile images(?)

I would start out with "linuxbios-utils"

Yes, that's definately the easiest one and the most useful, probably.

as the only package and pack flashrom, the lxbios tool (see fm).

lxbios should rather be an extra package as it has a different "upstream" tarball and author(s). But maybe linuxbios could draw it in, i.e. linuxbios could be a metapackage which not only depends on linuxbios-* packages, but also related stuff such as lxbios. Maybe it should have another name then, though. Also, I'll have to check the lxbios license, the DISCLAIMER file has some strange stuff which might pose problems for Debian...

If you want to make it more generic, you could call it firmware-utils or bios-utils and pack openbios' toke and detok with it.

Hm, openbios could be another package (or maybe multiple ones, e.g. openbios-utils?), or we could have multiple payload packages, e.g. linuxbios-payload-openbios linuxbios-payload-etherboot linuxbios-payload-* Or linuxbios-payloads which contains all of them? I'll have to think a bit more about this... this is definately the most complex project I've ever packaged.

The build process would have to be changed to use a prebuilt romcc, and I don't think this makes too much sense, as everything works fine as is, and there's no benefit to doing so.

If there's no reason to build romcc for each compile it would be nice to only have _one_ binary in /usr/bin, IHMO (see above).

Also, I would not swamp the repository with a number of packages just for the sake of doing so (even though this is commonly accepted in debian development) but look at target users of such a package and their requirements.

Yes, it should not be too many packages (although it's really not uncommon in Debian, e.g. there are more than 30 xserver-xorg-* packages).

Having a flash utility like flashrom integrated definitely makes sense. Packing source code in packages in my opinion does not (ok, the kernel may for some reason be an exception here)

I'm not too comfortable with shipping code either (e.g. in /usr/share, /usr/src, or something), but I think it's a matter of convenience - users could have one Debian box for LinuxBIOS work and could apt-get all the required tools and code to work with/on LinuxBIOS. Cheers, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org

Hi, On Mon, Jul 24, 2006 at 08:08:11PM +0200, Stefan Reinauer wrote:

Trying to be provocative.

With quite some success, I might add ;)

...

Yes, basically. Maybe there will be more, not sure yet.

Hm. Then I'd really drop this for now until there's some commensurability. A package count overhead of 50% is pretty much ;)

Agreed, I'll try to keep the number of packages reasonably small.

...

Is this a strict requirement? Wouldn't it be possible to compile it once, and distribute it as /usr/bin/romcc in the Debian package? Are any compile-time options involved (vs. runtime/commandline options?)

Not exactly a strict requirement, but romcc compiles within less than a second. This is not even 1% of the average compile time of a LinuxBIOS image.

Possible yes, but I have not read a reason yet, why we should do such a change.

Oh, you would not need to do it in svn, if that matters. I could do the change in the Debian package only... I don't have a (very) strong opinion on this, it just feels a bit strange to compile it every time. I mean, I don't build gcc every time I want to compile a C program either, so why should I build romcc every time?

In fact, if we find a bug in romcc now and fix it, we can point people to use revision XX from subversion and they are fine. I dont want to take the overhead of explaining people they have to update their debian package or switch the build process to use the "builtin version" for a build time reduced by less then a second. Even opening my mail client takes longer than that.

Well, that's a general problem with packages - they _always_ lag behind upstream, some more and some less. Using a mixture of upstream stuff _and_ Debian stuff is probably not a good idea. So either people use the Debian packages for code+tools+docs, or they don't and use the svn code directly; nobody should mix both, that'll result in problems, I guess. As for romcc - if there's a change in svn, you'll have to tell people anyways, regardless of whether they use Debian or not, and regardless of whether Debian ships a /usr/bin/romcc or only the source of it.

...

Also, I'll have to check the lxbios license, the DISCLAIMER file has some strange stuff which might pose problems for Debian...

What's wrong? The software is GPL.

GPL is fine of course. What needs checking is whether the other comments cause problems or not (I don't think they will, though), e.g.: This work was produced at the University of California, Lawrence Livermore National Laboratory (UC LLNL) under contract no. W-7405-ENG-48 (Contract 48) between the U.S. Department of Energy (DOE) and The Regents of the University of California (University) for the operation of UC LLNL. The rights of the Federal Government are reserved under Contract 48 subject to the restrictions agreed upon by the DOE and University as allowed under DOE Acquisition Letter 97-1. ############################################################################# OUR NOTICE AND TERMS AND CONDITIONS OF THE GNU GENERAL PUBLIC LICENSE Our Preamble Notice ------------------- A. This notice is required to be provided under our contract with the U.S. Department of Energy (DOE). This work was produced at the University of California, Lawrence Livermore National Laboratory under Contract No. W-7405-ENG-48 with the DOE. B. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. C. Also, reference herein to any specific commercial products, process, or services by trade name, trademark, manufacturer or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. The precise terms and conditions for copying, distribution and modification follows.

...

Or linuxbios-payloads which contains all of them?

If at all, pack it into one of them.

Agreed.

In my opinion linuxbios should not be more than two packages:

bios-utils and linuxbios-images (and I doubt whether we really want an -images package)

You mean image as in the images which will be flashed? I.e. pre-built binaries, so that "end-users" would not need to compile anything at all? If that's (easily) possible that would be a good idea indeed. It'll lower the learning-curve for LinuxBIOS quite a lot, I think... Anyways, I have created a small manpage for flashrom (Debian policy requires a manpage for every binary executable) which will be in the package, feel free to put it in svn if you want and if it makes sense... The manpage probably needs some fixing and checking - e.g. I'm not sure I got all of the authors right etc. Feel free to send me corrections... Btw, where should I send (smaller) patches which fix some issues I notice while I'm doing the packaging? This mailing list or the bug tracker? Cheers, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org

Apologies if I missed this earlier, but did anyone address the issue of where this package would reside? Uwe, do you have an unofficial repo somewhere that people could just add to sources.list? Should the repo be hosted @ coresystems.de? Or is this going into an -experimental (or similar) branch?

* Peter Stuge <stuge-linuxbios@cdy.org> [061121 04:46]:

On Mon, Nov 20, 2006 at 05:00:56PM -0700, ron minnich wrote:

...

don't make a linuxbios package. Make a buildrom package. I think that's a better path. most people want to build a full rom, not a linuxbios, and for that, buildrom is a great way to go.

Maybe also where I should take my shrinkwrapped LinuxBIOS thoughts.

Where is buildrom then?

Here, it seems: http://wiki.laptop.org/go/Building_LinuxBIOS

there's also svn://linuxbios.org/buildrom/ http://www.linuxbios.org/viewvc/buildrom-devel/?root=buildrom -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/

On 11/21/06, Uwe Hermann <uwe@hermann-uwe.de> wrote:

How is this different from the other version? We don't want to maintain two different versions, I think.

the linuxbios one is an older version and could be updated to the newest git. eventually they will fork as the olpc one is very olpc-specific. ron

On Tue, Nov 21, 2006 at 05:04:17PM +0100, Stefan Reinauer wrote:

Doesnt make sense to package linuxbios itself or buildrom at all, as it would only include the sources. Instead, we should provide linuxbios images with linux payload for download.

Packaging binary bios images in debian is kind of useless since you would flash them and deinstall the package again, which is not easier than downloading the stuff from our web page and flash that.

Yeah, I've been thinking about how/whether to package LinuxBIOS, but I haven't come up with a good solution, yet. But I'll surely package flashrom soon, that's a general purpose utility which might be useful for other projects. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org