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.
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?