From chess at chessgriffin.com Wed Aug 8 14:46:34 2012 From: chess at chessgriffin.com (Chess Griffin) Date: Wed, 08 Aug 2012 10:46:34 -0400 Subject: [sbopkg-users] Faenza-Xfce download issue Message-ID: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> Faenza-Xfce downloaded source is saved as 'v.0.2.1' and build fails. http://lists.slackbuilds.org/pipermail/slackbuilds-users/2012-August/009054.html -- Chess Griffin From mauro.giachero at gmail.com Wed Aug 8 17:34:50 2012 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Wed, 8 Aug 2012 19:34:50 +0200 Subject: [sbopkg-users] Faenza-Xfce download issue In-Reply-To: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> References: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> Message-ID: Gave a quick look at the issue. Seems to me that adding the --content-disposition flag to wget should fix the issue. The wget(1) 1.13.4 man page tells it's "experimental" and "not fully-functional", so I don't know whether blindly adding it by default is going to break things. Bye -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From chess at chessgriffin.com Wed Aug 8 19:31:25 2012 From: chess at chessgriffin.com (Chess Griffin) Date: Wed, 08 Aug 2012 15:31:25 -0400 Subject: [sbopkg-users] Faenza-Xfce download issue In-Reply-To: References: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> Message-ID: <1344454285.27107.140661112403649.45B59474@webmail.messagingengine.com> On Wed, Aug 8, 2012, at 01:34 PM, Mauro Giachero wrote: > Gave a quick look at the issue. > Seems to me that adding the --content-disposition flag to wget should fix > the issue. The wget(1) 1.13.4 man page tells it's "experimental" and "not > fully-functional", so I don't know whether blindly adding it by default > is > going to break things. Hey Mauro! That does indeed make the build proceed but I don't understand what's happening. Without that flag, the source is indeed downloaded but just named incorrectly. I wonder if there is a failure within the script -- somewhere in the get_source_names function perhaps? The source should be: shimmerproject-Faenza-Xfce-v.0.2.1-0-gd3e85cf.tar.gz but instead it's named just 'v.0.2.1'. It doesn't even keep the .tar.gz. Actually, now that I think about it, the script obviously correctly figures out what the name of the source /should/ be since it builds fine if the correctly-named source is there. -- Chess Griffin From chess at chessgriffin.com Thu Aug 9 01:39:15 2012 From: chess at chessgriffin.com (Chess Griffin) Date: Wed, 08 Aug 2012 21:39:15 -0400 Subject: [sbopkg-users] Faenza-Xfce download issue In-Reply-To: <1344454285.27107.140661112403649.45B59474@webmail.messagingengine.com> References: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> <1344454285.27107.140661112403649.45B59474@webmail.messagingengine.com> Message-ID: <1344476355.15428.140661112525957.67BBDE41@webmail.messagingengine.com> > That does indeed make the build proceed but I don't understand what's > happening. Without that flag, the source is indeed downloaded but just > named incorrectly. I wonder if there is a failure within the script -- > somewhere in the get_source_names function perhaps? The source should > be: shimmerproject-Faenza-Xfce-v.0.2.1-0-gd3e85cf.tar.gz but instead > it's named just 'v.0.2.1'. It doesn't even keep the .tar.gz. > > Actually, now that I think about it, the script obviously correctly > figures out what the name of the source /should/ be since it builds fine > if the correctly-named source is there. > You what is strange? This package builds perfectly on -current x86_64 with sbopkg as-is. -- Chess Griffin From chess at chessgriffin.com Thu Aug 9 03:06:51 2012 From: chess at chessgriffin.com (Chess Griffin) Date: Wed, 08 Aug 2012 23:06:51 -0400 Subject: [sbopkg-users] Faenza-Xfce download issue In-Reply-To: <1344476355.15428.140661112525957.67BBDE41@webmail.messagingengine.com> References: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> <1344454285.27107.140661112403649.45B59474@webmail.messagingengine.com> <1344476355.15428.140661112525957.67BBDE41@webmail.messagingengine.com> Message-ID: <1344481611.3704.140661112551857.177B53DC@webmail.messagingengine.com> On Wed, Aug 8, 2012, at 09:39 PM, Chess Griffin wrote: > > That does indeed make the build proceed but I don't understand what's > > happening. Without that flag, the source is indeed downloaded but just > > named incorrectly. I wonder if there is a failure within the script -- > > somewhere in the get_source_names function perhaps? The source should > > be: shimmerproject-Faenza-Xfce-v.0.2.1-0-gd3e85cf.tar.gz but instead > > it's named just 'v.0.2.1'. It doesn't even keep the .tar.gz. > > > > Actually, now that I think about it, the script obviously correctly > > figures out what the name of the source /should/ be since it builds fine > > if the correctly-named source is there. > > > > You what is strange? This package builds perfectly on -current x86_64 > with sbopkg as-is. > Larry Hajali points out this is a common issue with github. http://lists.slackbuilds.org/pipermail/slackbuilds-users/2012-August/009090.html I don't think it's something that necessarily needs to addressed in sbopkg. -- Chess Griffin From mauro.giachero at gmail.com Thu Aug 9 07:39:51 2012 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Thu, 9 Aug 2012 09:39:51 +0200 Subject: [sbopkg-users] Faenza-Xfce download issue In-Reply-To: <1344481611.3704.140661112551857.177B53DC@webmail.messagingengine.com> References: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> <1344454285.27107.140661112403649.45B59474@webmail.messagingengine.com> <1344476355.15428.140661112525957.67BBDE41@webmail.messagingengine.com> <1344481611.3704.140661112551857.177B53DC@webmail.messagingengine.com> Message-ID: As I understand it, wget uses the last part of the url path as the file name but some servers (like github ones) use an http header to specify the desired file name. The flag tells wget to use that header. I think fixing the issue in sbopkg is a good idea, and maybe would let us to drop some related workaround we currently have in the code. BTW, maybe the thing works on -current just because in recent wget versions the behavior triggered by the flag became the default. -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From chess at chessgriffin.com Fri Aug 10 03:48:59 2012 From: chess at chessgriffin.com (Chess Griffin) Date: Thu, 09 Aug 2012 23:48:59 -0400 Subject: [sbopkg-users] Faenza-Xfce download issue In-Reply-To: References: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> <1344454285.27107.140661112403649.45B59474@webmail.messagingengine.com> <1344476355.15428.140661112525957.67BBDE41@webmail.messagingengine.com> <1344481611.3704.140661112551857.177B53DC@webmail.messagingengine.com> Message-ID: <1344570539.25925.140661113015009.6560FF7D@webmail.messagingengine.com> On Thu, Aug 9, 2012, at 03:39 AM, Mauro Giachero wrote: > As I understand it, wget uses the last part of the url path as the file > name but some servers (like github ones) use an http header to specify > the > desired file name. The flag tells wget to use that header. Okay, makes sense. > I think fixing the issue in sbopkg is a good idea, and maybe would let us > to drop some related workaround we currently have in the code. > BTW, maybe the thing works on -current just because in recent wget > versions > the behavior triggered by the flag became the default. Yeah, although I also think that the issue isn't really with sbopkg since it does work on -current and it does work on 13.37 if that wget flag is added. IOW, sbopkg is correctly parsing the source name, but it's just wget that fails to properly download. At most, I could see maybe adding a prompt about including the "--content-disposition" flag temporarily to $TWGETFLAGS much like we do already with "--no-check-certificate" in check_cert_prompt. Maybe even in the same function (i.e. modify the warning and add it to $TWGETFLAGS at the same time) or, if we don't want to do it there, maybe add a check to see if github is in the download URL (if that's the only problematic site) and then offer to add the "--content-disposition." Although, to be honest, part of me is thinking not to bother at all and just leave it up to user to add to WGETFLAGS in sbopkg.conf since I'm not aware of any other packages that are affected by this other than faenza-xfce. -- Chess Griffin From slakmagik at gmail.com Sat Aug 18 18:21:06 2012 From: slakmagik at gmail.com (slakmagik) Date: Sat, 18 Aug 2012 14:21:06 -0400 Subject: [sbopkg-users] Faenza-Xfce download issue In-Reply-To: <1344570539.25925.140661113015009.6560FF7D@webmail.messagingengine.com> References: <1344437194.8975.140661112288257.701B2091@webmail.messagingengine.com> <1344454285.27107.140661112403649.45B59474@webmail.messagingengine.com> <1344476355.15428.140661112525957.67BBDE41@webmail.messagingengine.com> <1344481611.3704.140661112551857.177B53DC@webmail.messagingengine.com> <1344570539.25925.140661113015009.6560FF7D@webmail.messagingengine.com> Message-ID: <20120818182106.GB30175@devbox> On 2012-08-09 (Thu) 23:48:59 [-0400], Chess Griffin wrote: > On Thu, Aug 9, 2012, at 03:39 AM, Mauro Giachero wrote: > > As I understand it, wget uses the last part of the url path as the file > > name but some servers (like github ones) use an http header to specify > > the > > desired file name. The flag tells wget to use that header. > > Okay, makes sense. > > > I think fixing the issue in sbopkg is a good idea, and maybe would let us > > to drop some related workaround we currently have in the code. > > BTW, maybe the thing works on -current just because in recent wget > > versions > > the behavior triggered by the flag became the default. > > Yeah, although I also think that the issue isn't really with sbopkg > since it does work on -current and it does work on 13.37 if that wget > flag is added. IOW, sbopkg is correctly parsing the source name, but > it's just wget that fails to properly download. > > At most, I could see maybe adding a prompt about including the > "--content-disposition" flag temporarily to $TWGETFLAGS much like we do > already with "--no-check-certificate" in check_cert_prompt. Maybe even > in the same function (i.e. modify the warning and add it to $TWGETFLAGS > at the same time) or, if we don't want to do it there, maybe add a check > to see if github is in the download URL (if that's the only problematic > site) and then offer to add the "--content-disposition." Although, to > be honest, part of me is thinking not to bother at all and just leave it > up to user to add to WGETFLAGS in sbopkg.conf since I'm not aware of any > other packages that are affected by this other than faenza-xfce. > Sorry for being so late to the party - I was reading this thread as it was happening and meant to say something eventually but "eventually" became a long time. :) My impulse is to agree with Chess. If this is a fluke thing then let it be handled flukily. It does seem like a wget (or, more exactly, a server-side) problem. Fixing it in sbopkg won't let us drop any code because we'll still need those workarounds for everyone who isn't using the content-disposition header or who isn't using it properly. I'm actually in favor of just adding a note in KNOWN_ISSUES.