[sbopkg-users] [Slackbuilds-users] nvidia-driver.info missing 64bit file info

slakmagik slakmagik at gmail.com
Wed Jul 17 23:26:01 UTC 2013


On 2013-07-17 (Wed) 07:50:32 [-0400], Chess Griffin wrote:
> On Tue, 16 Jul 2013 23:25:56 -0500
> Robby Workman <rworkman at slackbuilds.org> wrote:
> 
> > On Tue, 16 Jul 2013 11:26:01 +0200
> > Heinz Wiesinger <pprkut at liwjatan.at> wrote:
> > 
> > > On Monday 15 July 2013 12:56:58 Robby Workman wrote:
> > > > On Mon, 15 Jul 2013 18:52:20 +0100
> > > > 
> > > > "Greg' Ar Tourter" <artourter at gmail.com> wrote:
> > > > > All the recently released/updated nvidia*-driver.info file are
> > > > > missing the source files and associated md5sum for the 64bit
> > > > > version. There are indeed common to bot the 32 and 64 bit
> > > > > version but need to be specified for both. Currently sbopkg
> > > > > fails because it isn't downloading the tar.xz files on 64bit
> > > > > machines since only the .run file is specified.
> > > > 
> > > > Hrm, my fault, but I'm not convinced that sbopkg is DTRT.
> > > > 
> > > > I'm going to CC  the sbopkg list to solicit feedback, but it's my
> > > > point of view that sbopkg should *always* pull the things
> > > > specified in $DOWNLOAD, and if on x86_64, pull the things
> > > > specified in $DOWNLOAD_x86_64.  Unless my memory is failing me,
> > > > that is how we envisioned things working when we added the
> > > > *_x86_64 variables to the .info file.
> > > 
> > > It's a little bit more complicated. The way it was meant: When
> > > DOWNLOAD_x86_64 is empty, use DOWNLOAD (indicating source is the
> > > same for both platforms), if filled (and not UNSUPPORTED/UNTESTED)
> > > use DOWNLOAD_x86_64 (different source per platform). And then there
> > > is also the rather rare case where DOWNLOAD could be
> > > UNSUPPORTED/UNTESTED (app works only on x86_64). This is also more
> > > or less how the website logic works when displaying download links
> > > to the sources.
> > 
> > 
> > Okay, that makes sense - thanks for the clarification.  We should
> > probably document that somewhere public if we haven't already.
> > I should probably keep up better ;-)
> > 
> > -RW
> 
> I'm trying to follow this thread but apparently I haven't had enough
> coffee yet.  ;-)  Is there still an open issue for sbopkg?  Something
> we need to look at?
> 

No, I think we're good. :)


More information about the sbopkg-users mailing list