Hi,
being a Debian developer I wondered wether it would make sense to create one or more Debian packages for LinuxBIOS. It seems there are no packages available at the moment - is this correct?
I'm not sure it makes sense to have the src/* and targets/* stuff packaged (maybe it does), but some things would be nice, I guess.
For example (quick draft):
linuxbios - metapackage which draws in all/most other packages linuxbios-doc - documentation linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...
Maybe also something like linuxbios-src which contains the rest, and which can be used to compile images(?)
Anyways, let me know if that makes sense or whether there are problems (e.g. if you'd HAVE TO recompile romcc/flashrom/whatever every time on your own, it doesn't make sense to package it)...
Cheers, Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060724 17:39]:
being a Debian developer I wondered wether it would make sense to create one or more Debian packages for LinuxBIOS. It seems there are no packages available at the moment - is this correct?
right.
I'm not sure it makes sense to have the src/* and targets/* stuff packaged (maybe it does), but some things would be nice, I guess.
For example (quick draft):
linuxbios - metapackage which draws in all/most other packages
ie. the other two?
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)
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" 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.
Anyways, let me know if that makes sense or whether there are problems (e.g. if you'd HAVE TO recompile romcc/flashrom/whatever every time on your own, it doesn't make sense to package it)...
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.
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. 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)
Just my 2ct. We're happy about anything that improves the user range of LinuxBIOS of course.
Stefan
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.
Hi,
On Mon, Jul 24, 2006 at 06:41:24PM +0200, Ward Vandewege wrote:
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'll have a look at them - if the license permits I'll package them.
Uwe.
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.
Hi Anton,
(note: CC to LinuxBIOS mailing list)
I've recently started creating LinuxBIOS Debian packages, and I'll probably also package your BIOS tools if the license permits and if you don't mind.
Is it correct that all of the *deco tools are GPL'd (it seems so)? Also, where can I get the latest versions of all the tools, the only page with download links I found is http://www.kaos.ru/biosgfx/index_2005.html and the links there are all broken. The links below from Ward Vandewege do work, however.
Do you plan to merge all of the tools into one big package one day? They all look and work pretty similar, I guess... If so, I'd also create one single Debian package. If not, should I have one Debian package for each tool, or merge them myself into one big "biosdeco" package (or any other name)? What do you think?
On Mon, Jul 24, 2006 at 10:47:32PM +0200, Ward Vandewege wrote:
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.
Cheers, Uwe.
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
On Tue, Nov 21, 2006 at 12:15:05AM +0100, Carl-Daniel Hailfinger 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
@Ward: Where did you get the links from and are there possibly more of them?
I got them from Anton via e-mail, and I also put them on the FAQ page at the wiki:
Thanks, Ward.
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.
Trying to be provocative.
* Uwe Hermann uwe@hermann-uwe.de [060724 19:39]:
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.
Hm. Then I'd really drop this for now until there's some commensurability. A package count overhead of 50% is pretty much ;)
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?)
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.
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.
romcc is a very special tool. I doubt there is too much use for it in other projects (except _maybe_ uboot, but I doubt even that).
I would think that does not help the debian project except with regard to staying the distribution with the largest number of packages (and thus user confusion)
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...
What's wrong? The software is GPL.
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?
If at all, pack it into one of them.
Each of the payloads is between 20 and 200k. The .deb overhead is probably more than that for most of the payloads.
Be careful when making this too finegrained. It will make it completely unmaintainable for you, which will lead to not up to date packages (which is a big problem in debian in general) and might in the end even paralyze progress.
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)
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).
Again: Why would it be nice? For safing one second?
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.
well, they can now svn co all the code without any extra effort and extra layer.. Is that less convenient?
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, le Thu 27 Jul 2006 22:28:20 +0200, a écrit :
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.
Yes, and since you'll have to fetch updates from cvs, you can choose to do this frequently.
Samuel
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?
Hi,
On Thu, Jul 27, 2006 at 01:52:26PM -0700, David Hendricks wrote:
Apologies if I missed this earlier, but did anyone address the issue of where this package would reside?
Um, well, in the Debian archive. When all is finished a user does 'apt-get install linuxbios' and that's it.
I could provide some DEBs for beta-testing maybe, but the goal is to get the package into main Debian...
HTH, Uwe.
On Mon, Jul 24, 2006 at 05:39:12PM +0200, Uwe Hermann wrote:
It seems there are no packages available at the moment - is this correct?
Yep. But not by design.
I'm not sure it makes sense to have the src/* and targets/* stuff packaged (maybe it does), but some things would be nice, I guess.
For example (quick draft):
linuxbios - metapackage which draws in all/most other packages
This strikes me as a bad idea since users may get the impression that apt-get install linuxbios would be all that is required to change BIOS. While that would be very nice at some point I think we may not be there quite yet. Ideally we should be able to programmatically identify which mainboard a system is running on. Is this possible? A fuctury BIOS checksum -> LB target whitelist perhaps?
linuxbios-doc - documentation
Maybe more than one doc package since there are a few different kinds of docs. I'm not familiar with debian package conventions so I don't know what would be best.
linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...
This makes sense, but ideally I think each util should be a separate package. Again I don't know how well that fits into debian package convetion.
Maybe also something like linuxbios-src which contains the rest, and which can be used to compile images(?)
There are no real LB relases yet. Versioning would be done based on snapshot date or svn revision.
//Peter
Hi,
On Mon, Jul 24, 2006 at 06:28:53PM +0200, Peter Stuge wrote:
linuxbios - metapackage which draws in all/most other packages
This strikes me as a bad idea since users may get the impression that apt-get install linuxbios would be all that is required to change BIOS.
Ok, maybe another, clearer name. But installing the package should not actively _do_ anything, it should merely provide the required tools.
While that would be very nice at some point I think we may not be there quite yet. Ideally we should be able to programmatically identify which mainboard a system is running on. Is this possible? A fuctury BIOS checksum -> LB target whitelist perhaps?
That might be nice, but I bet it's pretty hard to achieve...
Anyways, I do not want the package to (automatically) flash the BIOS or similar things - that would surely result in distaster...
linuxbios-doc - documentation
Maybe more than one doc package since there are a few different kinds of docs. I'm not familiar with debian package conventions so I don't know what would be best.
One -doc package should suffice. It can contain various types of documentation, that's no problem.
linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ...
This makes sense, but ideally I think each util should be a separate package. Again I don't know how well that fits into debian package convetion.
It'll be several packages already and one for every executable is overkill, IMHO. All utilities from the linuxbios source should be in linuxbios-utils, external utils (lxbios, etc.) can go in extra packages.
Maybe also something like linuxbios-src which contains the rest, and which can be used to compile images(?)
There are no real LB relases yet. Versioning would be done based on snapshot date or svn revision.
Hm, will this change anytime soon? I _could_ base the package on svn checkouts, but basing it on released tarballs would be nicer.
Cheers, Uwe.
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.
ron
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
//Peter
* 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
On Tue, Nov 21, 2006 at 04:59:40PM +0100, Stefan Reinauer wrote:
- 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
How is this different from the other version? We don't want to maintain two different versions, I think.
Uwe.
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
* ron minnich rminnich@gmail.com [061121 01:00]:
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.
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.
Stefan
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.
* Uwe Hermann uwe@hermann-uwe.de [061122 08:02]:
Yeah, I've been thinking about how/whether to package LinuxBIOS, but I haven't come up with a good solution, yet.
Dell has been working on what I think is a similar solution: http://linux.dell.com/firmware-tools/
But I'll surely package flashrom soon, that's a general purpose utility which might be useful for other projects.
Cool!
-
Carl-Daniel Hailfinger -
David Hendricks -
Peter Stuge -
ron minnich -
Samuel Thibault -
Stefan Reinauer -
Uwe Hermann -
Ward Vandewege