[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

Forgot to add my sign-off

Signed-off-by: Marc Karasek mailto:[e-mail]

-------- Original Message --------
Subject: 	Re: [LinuxBIOS] Patch file for Fedora 8 compile problems
Date: 	Tue, 11 Dec 2007 12:31:57 -0500
From: 	Marc Karasek 
To: 	ron minnich 
CC: 	Ed Swierk , LinuxBIOS 
, Carl-Daniel Hailfinger 

References: 	  
  
 
 

I did and I came up with a better solution.  I added an option called 
BUILDID_OPTION to the process.  This is a string that is set to the 
"-Wl,--build-id=none"  for newer ld versions and can be set to blank for 
older ld versions.  I have attached the patch file to add this to V2.  I 
think this should take care of any backwards compatibility. :-)

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

ron minnich wrote:
> I think you are adding too much complexity to the build process. it
> may be time to step back a bit and  think about all this.
>
> Just my $.02
>
> ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

so can others besides me test this, and, Marc, thanks for the patch.

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

Quoting ron minnich :
> so can others besides me test this, and, Marc, thanks for the patch.
>
> ron

I just upgraded my laptop to FC8 x86_64. I will do some test building  
this weekend and report back.

Thanks - Joe

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

I did some more testing and found one more place that needed the 
$(BUILDID_OPTION) added to it.

I will post a patch either today or on Monday for this.  Basically if 
you try to build AMD/Serengeti_cheetah (sp?) you will see which one 
needs it.

ron minnich wrote:
> so can others besides me test this, and, Marc, thanks for the patch.
>
> ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

Hmm. I applied this patch and now nothing works at all on my fc7 system.

how am I supposed to use this patch? How do you disable it? I don't
see this as being convenient for the user -- unless I'm missing
something.

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

In order to enable/disable it you  just have to go into the 
src/config/Options.lb and change the BUILDID_OPTION to be blank for 
older ld versions / non-x86 builds and leave it as "-Wl,--build-id=none" 
for the newer ld versions.

This IMO is the same as using an enviroment variable.   With the added 
benefit of  it being  contained within the build process.   I do not 
know of any other build option(s) that currently use enviroment 
variables.  I believe all of them are currently handled through the 
Options.lb file and see no reason to break from this.

ron minnich wrote:
> Hmm. I applied this patch and now nothing works at all on my fc7 system.
>
> how am I supposed to use this patch? How do you disable it? I don't
> see this as being convenient for the user -- unless I'm missing
> something.
>
> ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

On Dec 16, 2007 4:42 PM, Marc Karasek  wrote:
> In order to enable/disable it you  just have to go into the
> src/config/Options.lb and change the BUILDID_OPTION to be blank for
> older ld versions / non-x86 builds and leave it as "-Wl,--build-id=none"
> for the newer ld versions.

There is no way we can ask users to do this. We never intended for
users to modify src/config/Options.lb as a normal part of making a
build work.

The Options.lb file defines a set of config variables, and sets
reasonable default values for them, and for the most part these values
are mainboard and build related. For the most part, all these settings
work across all distros.

I don't want to ask people to start tweaking this file.

We have to find a better way. Let's keep thinking.

Thanks!

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

Quoting ron minnich :
> On Dec 16, 2007 4:42 PM, Marc Karasek  wrote:
> > In order to enable/disable it you  just have to go into the
> > src/config/Options.lb and change the BUILDID_OPTION to be blank for
> > older ld versions / non-x86 builds and leave it as "-Wl,--build-id=none"
> > for the newer ld versions.
>
> There is no way we can ask users to do this. We never intended for
> users to modify src/config/Options.lb as a normal part of making a
> build work.
>
> The Options.lb file defines a set of config variables, and sets
> reasonable default values for them, and for the most part these values
> are mainboard and build related. For the most part, all these settings
> work across all distros.
>
> I don't want to ask people to start tweaking this file.
>
> We have to find a better way. Let's keep thinking.
>
> Thanks!
>
> ron

I may be way off here but couldn't you just put in a simple if  
statment that says something like this:

if (ld_version >= XXX) {
     Use these build Options;
}

Thanks - Joe

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

OK, to recapitulate, the problem is that on certain OS distributions
we need certain compiler flags set.

Two ways have been proposed to fix this so far, both having problems:
1. awk scripts in the makeflie
2. setting variables in src/config/Options.lb

It occurred to me this morning that the right way to catch the
distribution version and set build-time makefile variables is in the
buildtarget script itself. The buildtarget script is under-utilized at
present. So, Marc, do you think you could take a look at hacking
buildtarget? We could modify the makefiles to pick up an include file
called Make.distro or some such, and buildtarget could create that
include file. That way, we get our automagic build variable creation,
but it's done once, not on every make command, and it doesn't impact
the system in the way that that Options.lb patch did.

Thanks

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

The patch could be put in as a blank option or now with a 
"README.Fedora8" file in the root.  The readme would give instructions 
to change the Options.lb file to include the -Wl,--build-id=none 
option.  At some point in the future we could change it around and make 
it so that the default is the option with a "README.build-id" about 
removing it.  This would hopefully be a mute point, at some future time, 
as V2 would give way to V3 (which does not have this problem).

I still feel the Options.lb patch is the best and cleanest way to go at 
this point.  The only sticking point is that the majority of people are 
not on Fedora8 yet and do not "need" this patch.  I think my suggestion 
above solves this problem.  The only issue I can see is if the change to 
add the option sneaks into the tree with a future patch file before we 
want to make the switch.  This will just take some watchfullness on our 
part to make sure it does not happen.

I can put together a patch file with the changes and also the added 
README.Fedora8 file, if this is OK...

/*********************

Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

ron minnich wrote:
> On Dec 16, 2007 4:42 PM, Marc Karasek  wrote:
> > In order to enable/disable it you  just have to go into the
> > src/config/Options.lb and change the BUILDID_OPTION to be blank for
> > older ld versions / non-x86 builds and leave it as "-Wl,--build-id=none"
> > for the newer ld versions.
>
> There is no way we can ask users to do this. We never intended for
> users to modify src/config/Options.lb as a normal part of making a
> build work.
>
> The Options.lb file defines a set of config variables, and sets
> reasonable default values for them, and for the most part these values
> are mainboard and build related. For the most part, all these settings
> work across all distros.
>
> I don't want to ask people to start tweaking this file.
>
> We have to find a better way. Let's keep thinking.
>
> Thanks!
>
> ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

On Dec 17, 2007 7:45 AM, Marc Karasek  wrote:
> The patch could be put in as a blank option or now with a
> "README.Fedora8" file in the root.  The readme would give instructions
> to change the Options.lb file to include the -Wl,--build-id=none
> option.  At some point in the future we could change it around and make
> it so that the default is the option with a "README.build-id" about
> removing it.  This would hopefully be a mute point, at some future time,
> as V2 would give way to V3 (which does not have this problem).

And every time someone does an svn command they'll have to deal with
the fact that this file is different.

I'm really sorry but I think this idea is a non-starter with me. Can
you look at my proposed buildtarget change? v2 is going
to be around for a while. We need to do this in the right manner.

thanks

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

Was this option just keeping the Config.lb changes and using an 
Environment Variable?

If so were does the environment variable  get set?  Is it up to the  
programmer or is it part of the build?

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

ron minnich wrote:
> On Dec 17, 2007 7:45 AM, Marc Karasek  wrote:
> > The patch could be put in as a blank option or now with a
> > "README.Fedora8" file in the root.  The readme would give instructions
> > to change the Options.lb file to include the -Wl,--build-id=none
> > option.  At some point in the future we could change it around and make
> > it so that the default is the option with a "README.build-id" about
> > removing it.  This would hopefully be a mute point, at some future time,
> > as V2 would give way to V3 (which does not have this problem).
>
> And every time someone does an svn command they'll have to deal with
> the fact that this file is different.
>
> I'm really sorry but I think this idea is a non-starter with me. Can
> you look at my proposed buildtarget change? v2 is going
> to be around for a while. We need to do this in the right manner.
>
> thanks
>
> ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

On Dec 17, 2007 8:18 AM, Marc Karasek  wrote:
> Was this option just keeping the Config.lb changes and using an
> Environment Variable?

no.
> If so were does the environment variable  get set?  Is it up to the
> programmer or is it part of the build?

it would be part of the buildtarget step, which is not up to the
programmer and is not part of the actual build. buildtarget is a sort
of meta-build, wherein the build environment gets set up. This is the
right place to capture distro issues. I don't know why it did not hit
me sooner.

thanks

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

So as part of the buildtarget script you would check the distro 
(possible using awk) and then set BUILDID_OPTION as an environment 
variable?

The only problem I see with this approach is it is not volatile across 
terminal windows.  For example, you open one window run buildtarget in 
it, this sets teh environment var properly.   You can then compile in 
this window, I have checked by manually doign an "export 
BUILDID_OPTION=-Wl,--build-id=none"  and commenting out the lines in the 
src/config/Config.lb file.   If you open another terminal however, you 
cannot compile in it,  the first window only has the environment var 
set, the second window does not.  And if you close the first window you 
have to run ./buildtarget again.   The only way I see to make it 
volatile across windows is somehow embed the option in the Makefile as a 
define.

Maybe I am missing something, is buildtarget supposed to do a 
configure/build or is it just meant for configure?

From your previous email...
/***********************************************************

if you just retained this much:
Index: src/arch/i386/Config.lb
===================================================================
--- src/arch/i386/Config.lb     (revision 3003)
+++ src/arch/i386/Config.lb     (working copy)
@@ -100,7 +100,7 @@

makerule linuxbios
                depends "crt0.o init.o $(LINUXBIOS_APC)
$(LINUXBIOS_RAM_ROM) ldscript.ld"
-               action  "$(CC) -nostdlib -nostartfiles -static -o $@
-T ldscript.ld crt0.o init.o"
+               action  "$(CC) $(BUILDID_OPTION) -nostdlib
-nostartfiles -static -o $@ -T ldscript.ld crt0.o init.o"
                action  "$(CROSS_COMPILE)nm -n linuxbios | sort > linuxbios.map"
         end

Then couldn't the build pick up an environment variable?

/**********************************************************

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

ron minnich wrote:
> On Dec 17, 2007 8:18 AM, Marc Karasek  wrote:
> > Was this option just keeping the Config.lb changes and using an
> > Environment Variable?
>
> no.
> > If so were does the environment variable  get set?  Is it up to the
> > programmer or is it part of the build?
>
> it would be part of the buildtarget step, which is not up to the
> programmer and is not part of the actual build. buildtarget is a sort
> of meta-build, wherein the build environment gets set up. This is the
> right place to capture distro issues. I don't know why it did not hit
> me sooner.
>
> thanks
>
> ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

On Dec 17, 2007 11:19 AM, Marc Karasek  wrote:
> So as part of the buildtarget script you would check the distro
> (possible using awk) and then set BUILDID_OPTION as an environment
> variable?

not quite.

What I propose is that we modify the standard makefiles to do
something like this:
include makefile.distro

The makefile.distro is created by buildtarget script in, e.g.,
targets/pcengines/alix1c/alix1c, i.e. the build directory.
> The only problem I see with this approach is it is not volatile across
> terminal windows.  For example, you open one window run buildtarget in
> it, this sets teh environment var properly.   You can then compile in
> this window, I have checked by manually doign an "export
> BUILDID_OPTION=-Wl,--build-id=none"  and commenting out the lines in the
> src/config/Config.lb file.   If you open another terminal however, you
> cannot compile in it,  the first window only has the environment var
> set, the second window does not.

correct.
> And if you close the first window you
> have to run ./buildtarget again.   The only way I see to make it
> volatile across windows is somehow embed the option in the Makefile as a
> define.

exactly. that is my proposal :-)

But instead of modifying the makefile, we *generate* a file (always)
that is included in the makefile. In most cases, the generated file
may only have stuff like:
BUILDID_OPTION=

But in your case, it would actually define that option. We can also
use this to deal with the -fstack-protector mess.

So one other function performed by the buildtarget script will be a
new function, that of creating the makefilo.distro in the build
directory.

So we are close!

thanks

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

Quoting ron minnich :
> On Dec 17, 2007 11:19 AM, Marc Karasek  wrote:
> > So as part of the buildtarget script you would check the distro
> > (possible using awk) and then set BUILDID_OPTION as an environment
> > variable?
>
> not quite.
>
> What I propose is that we modify the standard makefiles to do
> something like this:
> include makefile.distro
>
> The makefile.distro is created by buildtarget script in, e.g.,
> targets/pcengines/alix1c/alix1c, i.e. the build directory.
> > The only problem I see with this approach is it is not volatile across
> > terminal windows.  For example, you open one window run buildtarget in
> > it, this sets teh environment var properly.   You can then compile in
> > this window, I have checked by manually doign an "export
> > BUILDID_OPTION=-Wl,--build-id=none"  and commenting out the lines in the
> > src/config/Config.lb file.   If you open another terminal however, you
> > cannot compile in it,  the first window only has the environment var
> > set, the second window does not.
>
> correct.
> > And if you close the first window you
> > have to run ./buildtarget again.   The only way I see to make it
> > volatile across windows is somehow embed the option in the Makefile as a
> > define.
>
> exactly. that is my proposal :-)
>
> But instead of modifying the makefile, we *generate* a file (always)
> that is included in the makefile. In most cases, the generated file
> may only have stuff like:
> BUILDID_OPTION=
>
> But in your case, it would actually define that option. We can also
> use this to deal with the -fstack-protector mess.
>
> So one other function performed by the buildtarget script will be a
> new function, that of creating the makefilo.distro in the build
> directory.
>
> So we are close!
>
> thanks
>
> ron

I agree with you Ron. I makes alot of sense just to make this a  
makefile option. No need to make things more complicated than they  
need to be. But, I don't really know why we would need to add a  
seperate build option file that the makfile calls just for one  
function (assuming it would only be one function), unless your idea is  
to designate the makefilo.distro file for future distro specific issues?

Thanks - Joe

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

On Dec 17, 2007 8:19 PM,   wrote:
> I agree with you Ron. I makes alot of sense just to make this a
> makefile option. No need to make things more complicated than they
> need to be. But, I don't really know why we would need to add a
> seperate build option file that the makfile calls just for one
> function (assuming it would only be one function), unless your idea is
> to designate the makefilo.distro file for future distro specific issues?

You are not really 'calling' the makefile, you are including a file of
definitions such as
BUILD_ID="blah blah"

This file is created by buildtarget.
By using an include file, you avoid having to actually change the
makefile. This is pretty flexible.

It's not one function, it's one variable define.

But, yes, this does nicely set us up for handling other future distro
and gnu toolchain issues.

Thanks

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

Quoting ron minnich :
> On Dec 17, 2007 8:19 PM,   wrote:
> > I agree with you Ron. I makes alot of sense just to make this a
> > makefile option. No need to make things more complicated than they
> > need to be. But, I don't really know why we would need to add a
> > seperate build option file that the makfile calls just for one
> > function (assuming it would only be one function), unless your idea is
> > to designate the makefilo.distro file for future distro specific issues?
>
> You are not really 'calling' the makefile, you are including a file of
> definitions such as
> BUILD_ID="blah blah"
>
> This file is created by buildtarget.
> By using an include file, you avoid having to actually change the
> makefile. This is pretty flexible.
>
> It's not one function, it's one variable define.
>
> But, yes, this does nicely set us up for handling other future distro
> and gnu toolchain issues.
>
> Thanks
>
> ron

Oh, ok that makes more sense, so it is more like a header file. The  
next question would be then how to make this automatic or would you  
have compile buildtarget with the makefile option (BUILD_ID="blah  
blah") before you started using LB? Sorry if this question has already  
been answered....

Thanks - Joe

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[ron minnich]

On Dec 17, 2007 9:27 PM,   wrote:
> Oh, ok that makes more sense, so it is more like a header file. The
> next question would be then how to make this automatic or would you
> have compile buildtarget with the makefile option (BUILD_ID="blah
> blah") before you started using LB? Sorry if this question has already
> been answered....

buildtarget is a shell script, more or less.

Marc has already shown us lots of ways of making it automatic. We will
use one of his ideas.

ron

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

Quoting ron minnich :
> On Dec 17, 2007 9:27 PM,   wrote:
> > Oh, ok that makes more sense, so it is more like a header file. The
> > next question would be then how to make this automatic or would you
> > have compile buildtarget with the makefile option (BUILD_ID="blah
> > blah") before you started using LB? Sorry if this question has already
> > been answered....
>
> buildtarget is a shell script, more or less.

Yes, and the makefilo.distro would be more like a header file for buildtarget?
> Marc has already shown us lots of ways of making it automatic. We will
> use one of his ideas.
>
> ron

Yes I do agree that Marc has some very good ideas of making it  
automatic. Just trying to help with the brain storming process:-)

Thanks - Joe

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

I have attached a awk script file that has a awk command to find the if 
you are currently running fc8 or not.  This uses the /proc/version 
string, so a custom kernel will prob fail on this check.

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

ron minnich wrote:
> On Dec 17, 2007 8:18 AM, Marc Karasek  wrote:
> > Was this option just keeping the Config.lb changes and using an
> > Environment Variable?
>
> no.
> > If so were does the environment variable  get set?  Is it up to the
> > programmer or is it part of the build?
>
> it would be part of the buildtarget step, which is not up to the
> programmer and is not part of the actual build. buildtarget is a sort
> of meta-build, wherein the build environment gets set up. This is the
> right place to capture distro issues. I don't know why it did not hit
> me sooner.
>
> thanks
>
> ron

{for (i=1;i<=NF;i++) if ($i=="2.17"){n++} }; END {print n}

(echo | ld --version) | awk '{for (i=1;i<=NF;i++) if ($i=="2.17.50.0.18-1"){n++} }; END {print n}'

(cat /proc/version ) | awk '{for (i=1;i<=NF;i++) if ($i ~ /fc8/){n++} }; END {print n}'

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Carl-Daniel Hailfinger]

Hi Marc,

how about using /etc/*fedora*-release?

Regards,
Carl-Daniel

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

That would work, but this brings up a rather interesting point.  What 
are we todo about all the other Distros?   At some point (if not 
already) they will also face a similar issue.

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Carl-Daniel Hailfinger wrote:
> Hi Marc,
>
> how about using /etc/*fedora*-release?
>
> Regards,
> Carl-Daniel

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Uwe Hermann]

On Mon, Dec 17, 2007 at 02:55:35PM -0500, Marc Karasek wrote:
> That would work, but this brings up a rather interesting point.  What 
> are we todo about all the other Distros?   At some point (if not 
> already) they will also face a similar issue.

Yep, true. The correct thing IMO is to check for the actual feature/bug,
not for version number strings of compilers or programs or distros.

Uwe.

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Marc Karasek]

So how about this

(ld --help) | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END 
{print n}'

This will return a 1 if it finds the string build-id in the ld help.

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Uwe Hermann wrote:
> On Mon, Dec 17, 2007 at 02:55:35PM -0500, Marc Karasek wrote:
> > That would work, but this brings up a rather interesting point.  What 
> > are we todo about all the other Distros?   At some point (if not 
> > already) they will also face a similar issue.
>
> Yep, true. The correct thing IMO is to check for the actual feature/bug,
> not for version number strings of compilers or programs or distros.
>
> Uwe.

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Peter Stuge]

On Mon, Dec 17, 2007 at 02:55:35PM -0500, Marc Karasek wrote:
> That would work, but this brings up a rather interesting point. 
> What are we todo about all the other Distros?
> At some point (if not already) they will also face a similar issue.

As Uwe hinted, this of course has nothing to do with a distribution
but rather a specific package.

Long term, we work with upstream for that package.

Short term, I like Ron's test at buildtarget time, and saving that in
a Make.buildparam.or.whatever in the freshly created build directory.

On Mon, Dec 17, 2007 at 03:16:40PM -0500, Marc Karasek wrote:
> So how about this
>
> (ld --help) | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END 
> {print n}'
>
> This will return a 1 if it finds the string build-id in the ld help.

Almost, it seems to output the number of times the string is found.

I suggest ld --help|grep -q build-id instead, which may even be
slightly easier to work with in a script.

//Peter

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Gregg C Levine]

Hello!
I agree.
My current Linux development box does indeed make use of a custom kernel,
and runs Slackware Linux, their release numbered 11.0 as it happens.

So far I've not had any problems with building the tools for checking to see
what he uses for the superio function part of his mother board. Incidentally
this box is a Dell Optiplex GX150 and uses the I810 chipset family.

Depending on my finances and a few other things, I might be able to find a
second unit, and work on a complete port. The big headache will be in
obtaining one. I believe I've seen them for sale via Weirdstuff.

Especially since my projects during the coming year just might require the
presence of a legacy free BIOS on board.

Incidentally Marc where are you based? I am based in NYC, Astoria Queens in
fact.
--
Gregg C Levine [e-mail]
"The Force will be with you always." Obi-Wan Kenobi
> -----Original Message-----
> From: [e-mail]

[mailto:[e-mail]] On
> Behalf Of Marc Karasek
> Sent: Monday, December 17, 2007 2:56 PM
> To: Carl-Daniel Hailfinger
> Cc: ron minnich; LinuxBIOS
> Subject: Re: [LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile

problems]
> That would work, but this brings up a rather interesting point.  What
> are we todo about all the other Distros?   At some point (if not
> already) they will also face a similar issue.
>
> /*********************
> Marc Karasek
> MTS
> Sun Microsystems
> mailto:[e-mail]
> ph:770.360.6415
> *********************/
>
> Carl-Daniel Hailfinger wrote:
> > Hi Marc,
> >
> > how about using /etc/*fedora*-release?
> >
> > Regards,
> > Carl-Daniel

[LinuxBIOS] [Fwd: Re: Patch file for Fedora 8 compile problems]

[Carl-Daniel Hailfinger]

On 17.12.2007 20:52, Carl-Daniel Hailfinger wrote:
> Hi Marc,
>
> how about using /etc/*fedora*-release?

Sorry, that should have been  /etc/fedora-release (without the stars).

Regards,
Carl-Daniel