Greetings list,

Currently catalyst (2.0.5, 2.0.6pre4) doesn't seem to change what uname
outputs. uname -r, for example, prints the version of the kernel running
catalyst, not the kernel that's in the stage. Of course, that's how it
is, but isn't it possible to hack that somehow? It's a bit tedioius to
patch everything that depends on uname (e.g. the raling-rt61 ebuild).
Can the "uname string" be set by some envirnoment variable in an env
script specified in the spec file?

--
gentoo-catalyst@lists.gentoo.org mailing list

lurker wrote:

Greetings list,

Currently catalyst (2.0.5, 2.0.6pre4) doesn't seem to change what uname
outputs. uname -r, for example, prints the version of the kernel running
catalyst, not the kernel that's in the stage. Of course, that's how it
is, but isn't it possible to hack that somehow? It's a bit tedioius to
patch everything that depends on uname (e.g. the raling-rt61 ebuild).
Can the "uname string" be set by some envirnoment variable in an env
script specified in the spec file?


Any ebuild that depends upon the output of uname is broken and should be fixed.

--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
gentoo-catalyst@lists.gentoo.org mailing list

On Wednesday 13 February 2008, lurker wrote:
> Currently catalyst (2.0.5, 2.0.6pre4) doesn't seem to change what uname
> outputs. uname -r, for example, prints the version of the kernel running
> catalyst, not the kernel that's in the stage. Of course, that's how it
> is, but isn't it possible to hack that somehow? It's a bit tedioius to
> patch everything that depends on uname (e.g. the raling-rt61 ebuild).
> Can the "uname string" be set by some envirnoment variable in an env
> script specified in the spec file?

stages dont have kernels
-mike

On Wed, 2008-02-13 at 22:11 -0500, Mike Frysinger wrote:
> On Wednesday 13 February 2008, lurker wrote:
> > Currently catalyst (2.0.5, 2.0.6pre4) doesn't seem to change what uname
> > outputs. uname -r, for example, prints the version of the kernel running
> > catalyst, not the kernel that's in the stage. Of course, that's how it
> > is, but isn't it possible to hack that somehow? It's a bit tedioius to
> > patch everything that depends on uname (e.g. the raling-rt61 ebuild).
> > Can the "uname string" be set by some envirnoment variable in an env
> > script specified in the spec file?
>
> stages dont have kernels

Indeed. As Andrew has said and Mike as alluded to, not a single
catalyst target has a kernel compiled prior to stage4/livecd-stage2, so
there's no reason for this. Any ebuild that uses uname for *anything*
is broken and a bug should be filed to have the package fixed.

--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer

On 14/02/08 04:01, Andrew Gaffney wrote:
> lurker wrote:
>> Greetings list,
>>
>> Currently catalyst (2.0.5, 2.0.6pre4) doesn't seem to change what uname
>> outputs. uname -r, for example, prints the version of the kernel running
>> catalyst, not the kernel that's in the stage. Of course, that's how it
>> is, but isn't it possible to hack that somehow? It's a bit tedioius to
>> patch everything that depends on uname (e.g. the raling-rt61 ebuild).
>> Can the "uname string" be set by some envirnoment variable in an env
>> script specified in the spec file?
>
> Any ebuild that depends upon the output of uname is broken and should be
> fixed.

Sorry, I meant the compile scripts, e.g. the Makefile of ralink-rt61.

--
gentoo-catalyst@lists.gentoo.org mailing list

lurker wrote:

On 14/02/08 04:01, Andrew Gaffney wrote:

lurker wrote:

Greetings list,

Currently catalyst (2.0.5, 2.0.6pre4) doesn't seem to change what uname
outputs. uname -r, for example, prints the version of the kernel running
catalyst, not the kernel that's in the stage. Of course, that's how it
is, but isn't it possible to hack that somehow? It's a bit tedioius to
patch everything that depends on uname (e.g. the raling-rt61 ebuild).
Can the "uname string" be set by some envirnoment variable in an env
script specified in the spec file?

Any ebuild that depends upon the output of uname is broken and should be
fixed.


Sorry, I meant the compile scripts, e.g. the Makefile of ralink-rt61.


Whether it's the ebuild or the package's build system, it's still broken. Doing
crap like this makes it impossible to build a package for another machine that's
not running the same kernel.


--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
gentoo-catalyst@lists.gentoo.org mailing list