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
> 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
Possible yes, but I have not read a reason yet, why we should do such a
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
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
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
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?