Skip to Content.
Sympa Menu

sm-grimoire-bugs - [SM-Grimoire-Bugs] [Bug 8657] nvidia_driver spell for X86 and X86_64

sm-grimoire-bugs AT lists.ibiblio.org

Subject: SourceMage Grimoire Bug List

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-grimoire-bugs AT lists.ibiblio.org
  • Subject: [SM-Grimoire-Bugs] [Bug 8657] nvidia_driver spell for X86 and X86_64
  • Date: 31 Mar 2007 07:07:34 -0000

http://bugs.sourcemage.org/show_bug.cgi?id=8657


jblosser-smgl AT firinn.org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED

Bug 8657 depends on bug 9078, which changed state.

Bug 9078 Summary: ARCH variable set in spells
http://bugs.sourcemage.org/show_bug.cgi?id=9078

What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED



------- Additional Comments From pmahon AT sourcemage.org 2005-07-30 18:34
-------
In devel there is now SMGL_COMPAT_ARCHS, an array which goes from least
specific
to most specific architecture. In addition, ARCHITECTURE becomes an array in
the
opposite order.

The variables are set during the normal course of running optimize().

--


------- Additional Comments From dmlb2000 AT gmail.com 2005-07-30 21:51 -------
Okay with the addition of the SMGL_COMPAT_ARCH array I fixed this with
perforce
change 63502

--


------- Additional Comments From eric AT sandall.us 2005-08-01 17:13 -------
You what? The SMGL_COMPAT_ARRAY is /only/ available in devel Sorcery so you
cannot depend on it in spells until it makes stable Sorcery.

--


------- Additional Comments From dmlb2000 AT gmail.com 2005-08-01 19:43 -------
(In reply to comment #13)
> You what? The SMGL_COMPAT_ARRAY is /only/ available in devel Sorcery so you
> cannot depend on it in spells until it makes stable Sorcery.

it's fine the way I did it, the spell defaults to the x86 if the variable
doesn't exist, so if they want x86-64 nvidia_driver spell they will have
to use devel sorcery or bug andrew to push that to test and stable sooner
or make their own spell that only supports x86-64.

--


------- Additional Comments From acedit AT armory.com 2005-08-02 02:44 -------
I don't think its a good assumption that all x86_64 users will be using devel
sorcery. Would bad things happen if an x86_64 user had the x86 drivers
installed?

You can check if SMGL_COMPAT_ARCHS is set, if it isnt then do something like
find $ARCH_SPECS -name $ARCHITECTURE|grep -q x86-64 as a temporary fallback.
Either trust that as a replacement for SMGL_COMPAT_ARCHS (for now), or just
bail
out suggesting the usage of devel sorcery w/ x86_64.

As an aside:
Im also open to suggestion/discussion on how to deal with feature skew between
stable/devel sorcery. We cant integrate the feature until we're reasonably
sure
it works, cant test it fully until spells adopt it, and spells can't adopt it
until the feature is in stable sorcery, or they have to implement hacks like
suggested above (and thats no good in the long run).

As for integrating the SMGL_COMPAT_ARCHS enhancement to stable, how many
spells
would/could take advantage of it? How high of a priority is this?

--


------- Additional Comments From dmlb2000 AT gmail.com 2005-08-02 05:55 -------
Well the SMGL_COMPAT_ARCHS would be mainly for z-rejected binary spells
so firefox-bin openoffice-bin jdk1.5-bin j2sdk-bin nvidia_driver ...
any of those spells could use this to support downloading of the appropriate
arch specific binary

--


------- Additional Comments From dmlb2000 AT gmail.com 2005-08-02 06:18 -------
(In reply to comment #15)
> I don't think its a good assumption that all x86_64 users will be using
> devel
> sorcery. Would bad things happen if an x86_64 user had the x86 drivers
> installed?

I'm not suggesting that all x86-64 users will use devel sorcery, and the spell
wouldn't compile if it used the x86 drivers. But technically this is an
unsupported architecture the SMGL_COMPAT_ARCHS var in devel is a big step to
fully supporting other archictures, especially for binary spells, and not just
for x86-64. So I really don't see the problem, those users that use stable or
test sorcery are left in the same boat as they were before, running sourcemage
on an architecture that is techically unsupported by sourcemage.

> You can check if SMGL_COMPAT_ARCHS is set, if it isnt then do something like
> find $ARCH_SPECS -name $ARCHITECTURE|grep -q x86-64 as a temporary fallback.
> Either trust that as a replacement for SMGL_COMPAT_ARCHS (for now), or just
> bail
> out suggesting the usage of devel sorcery w/ x86_64.

I honestly wouldn't like to do some weird hack like that to try to support
this
for test and stable sorcery.

--


------- Additional Comments From acedit AT armory.com 2005-08-02 06:38 -------
(In reply to comment #17)
My concern is avoiding obscure errors and/or confusing behavior. So Im just
registering the opposing point of view. Better error messages mean less irc
support in theory, but given the size of our x86_64 contingent, Im fine with
your assessment.

In anycase, Im glad that we're getting these cross-platform issues sorted out
now, rather than when x86_64 (or some other arch) is 'officially' supported.

--


------- Additional Comments From eric AT sandall.us 2005-08-02 16:24 -------
I'm of the opinion that no spell should use any feature that isn't in stable
Sorcery. And even then they should probably check to make sure the feature
they're using is in the version of Sorcery the user has as not everyone does a
`sorcery system-update` but rather, usually `scribe update && sorcery queue`
(at
least I do).

You can check `sorcery -v` for what version is installed to see if you can use
the feature or not. The x86_64 cases are special in that we don't officially
support them anyways, however, I'd like to not encourage developers into using
features that aren't in stable Sorcery, which is why I brought this up. For
x86_64 it's probably 'okay' to do it.

--


------- Additional Comments From gareth AT caffeinefuelled.com 2005-08-10 10:41
-------
David, I appreciate that you're doing things the "right way" - we absolutely
need a sorcery feature that allows us to tell what arch we're casting spells
on and I'm glad that you requested it and that it's now in devel. But using
that feature before it's in stable sorcery is pointless - it's just going to
confuse users. You might as well not bother having the architecture check in
the spell at all if it's not going to work.

I'm running x86_64 myself now and noticed that the SOURCE_URL for that arch
was incorrect, and while I was fixing that I've fixed the architecture check
for stable/test sorcery too. I think as soon as the SMGL_COMPAT_ARCHS feature
reaches stable the spell should be changed back to use that feature, but not
before. For the sake of 2 lines of script it's not worth confusing / annoying
users when they try to install what is quite a fundamental spell for a lot of
people.

--


------- Additional Comments From dmlb2000 AT gmail.com 2005-08-10 11:20 -------
(In reply to comment #20)
> David, I appreciate that you're doing things the "right way" - we
> absolutely
> need a sorcery feature that allows us to tell what arch we're casting
> spells
> on and I'm glad that you requested it and that it's now in devel. But using
> that feature before it's in stable sorcery is pointless - it's just going
> to
> confuse users. You might as well not bother having the architecture check
> in
> the spell at all if it's not going to work.

Well then I'd certianly like to know how we are supposed to test new features
that show up in sorcery, so that we can be assured they are safe by the time
they reach stable sorcery, this seems like a chicken and the egg problem.

> I'm running x86_64 myself now and noticed that the SOURCE_URL for that arch
> was incorrect, and while I was fixing that I've fixed the architecture
> check
> for stable/test sorcery too. I think as soon as the SMGL_COMPAT_ARCHS
> feature
> reaches stable the spell should be changed back to use that feature, but
> not
> before. For the sake of 2 lines of script it's not worth confusing /
> annoying
> users when they try to install what is quite a fundamental spell for a lot
> of
> people.

I wouldn't have used a check against uname I probably would have done a check
against either HOST or ARCHITECTURE because those are set in stable iirc and
they are internal to sorcery and would be safer to use.

--


------- Additional Comments From jblosser-smgl AT firinn.org 2007-03-31 01:07
-------
closing fixed bugs

--
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



  • [SM-Grimoire-Bugs] [Bug 8657] nvidia_driver spell for X86 and X86_64, bugzilla-daemon, 03/31/2007

Archive powered by MHonArc 2.6.24.

Top of Page