Hi, I've worked out what seemed to be a correct URL for for rakarrack spec, now that it is accessed via git within the sf website:
%global commit a6208406d94a1da978f435605072ee5caefe1491 Source0: http://sourceforge.net/code-snapshots/git/r/ra/rakarrack/git.git/rakarrack-g...
Which works OK for some time, but then the next day it fails. It seems that the web site creates the archive dynamically, and you can download it multiple times using the above URL, within say 6-20 hours: https://sourceforge.net/p/rakarrack/git/ci/master/tree/ click Download Snapshot, then cancel the auto download, and copy the direct URL.
Then next day, I noticed rpmlint is kicking up an error saying source doesn't exist. Indeed attempting to wget the filename fails.
But then if I go to the web page again and click Download Snapshot (which creates the archive), now rpmlint succeeds.
I couldn't work out how to fit the sourceforce git URLs from: https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net or https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services
to suit. Any ideas for a standard way to handle sf git snapshots ?
Is the provided URL (which goes stale quickly, yet is re-generate-able) OK ?
On Sun, Mar 13, 2016 at 9:15 PM, David Timms dtimms@iinet.net.au wrote:
Hi, I've worked out what seemed to be a correct URL for for rakarrack spec, now that it is accessed via git within the sf website:
I couldn't work out how to fit the sourceforce git URLs from: https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net or https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services
to suit. Any ideas for a standard way to handle sf git snapshots ?
Move them to github. Seriously. Sourceforge has been playing various games to avoid accessing content without going through their adveritising functions since they were first founded, and I've found no reason to work with any project hosted there since..... checking old notes, not since 2009.
Is the provided URL (which goes stale quickly, yet is re-generate-able) OK ?
If it goes stale quickly, I'd consider it useless. Git was not designed to support magical dancing URL's, that kind of instability takes actual planning and work to inflict on the software repository and on its users..
On 14/03/16 13:12, Nico Kadel-Garcia wrote:
On Sun, Mar 13, 2016 at 9:15 PM, David Timms dtimms@iinet.net.au wrote:
Hi, I've worked out what seemed to be a correct URL for for rakarrack spec, now that it is accessed via git within the sf website:
I couldn't work out how to fit the sourceforce git URLs from: https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net or https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services
to suit. Any ideas for a standard way to handle sf git snapshots ?
Move them to github. Seriously. Sourceforge has been playing various games to avoid accessing content without going through their adveritising functions since they were first founded, and I've found no reason to work with any project hosted there since..... checking old notes, not since 2009.
I do not have power over upstream. I'm talking about downstream packaging. I'd like to hear from someone with a legit answer, please ?
Is the provided URL (which goes stale quickly, yet is re-generate-able) OK ?
If it goes stale quickly, I'd consider it useless. Git was not designed to support magical dancing URL's, that kind of instability takes actual planning and work to inflict on the software repository and on its users..
I think it's quite reasonable; they have the complete content stored as git diffs, they then do-not need to store a zip archive after every commit ever made. Instead, just create one when someone asks for it...
I'm really asking how I should write my .spec Source0 url.. maybe I could write 2x lines (one that triggers the creation of the archive, and the second which is the actual location) ??
David Timms dtimms@iinet.net.au wrote:
On 14/03/16 13:12, Nico Kadel-Garcia wrote:
If it goes stale quickly, I'd consider it useless. Git was not designed to support magical dancing URL's, that kind of instability takes actual planning and work to inflict on the software repository and on its users..
I think it's quite reasonable; they have the complete content stored as git diffs, they then do-not need to store a zip archive after every commit ever made. Instead, just create one when someone asks for it...
Sure, creating a file when someone asks for it is fine, but that's not what they do, according to your description. Your problem is that you have to first create the file with one request, and then ask for it with another request.
There wouldn't be a problem if it were all done with a single URL. The server could perfectly well create the file on the fly and send it as the response to the first request.
If it's done with HTTP redirection, where the first GET request creates the file and returns a 303 See Other response with the URI to the file, then that's unnecessarily complex but should still work with any reasonably competent download utility. Then you only need to find out the correct first URI and use that in your spec file.
If it's done with Javascript or some such trickery that only works in a browser, then that's not reasonable. That's being difficult on purpose.
Björn Persson
On 03/13/2016 08:12 PM, Nico Kadel-Garcia wrote:
On Sun, Mar 13, 2016 at 9:15 PM, David Timms dtimms@iinet.net.au wrote:
Hi, I've worked out what seemed to be a correct URL for for rakarrack spec, now that it is accessed via git within the sf website:
I couldn't work out how to fit the sourceforce git URLs from: https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net or https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services
to suit. Any ideas for a standard way to handle sf git snapshots ?
Move them to github. Seriously. Sourceforge has been playing various games to avoid accessing content without going through their adveritising functions since they were first founded, and I've found no reason to work with any project hosted there since..... checking old notes, not since 2009.
Just to let people know:
https://sourceforge.net/blog/sourceforge-acquisition-and-future-plans/
On Seg, 2016-03-14 at 08:54 -0600, Orion Poplawski wrote:
On 03/13/2016 08:12 PM, Nico Kadel-Garcia wrote:
On Sun, Mar 13, 2016 at 9:15 PM, David Timms dtimms@iinet.net.au wrote:
Hi, I've worked out what seemed to be a correct URL for for rakarrack spec, now that it is accessed via git within the sf website:
I couldn't work out how to fit the sourceforce git URLs from: https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.ne t or https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Se rvices
to suit. Any ideas for a standard way to handle sf git snapshots ?
Move them to github. Seriously. Sourceforge has been playing various games to avoid accessing content without going through their adveritising functions since they were first founded, and I've found no reason to work with any project hosted there since..... checking old notes, not since 2009.
Devshare (I think it is called devshare) was a mistake and only happens on windows, and all the fault can't be impute to sf.net. sf.net was and still is an important organization that support open source and free software .
Just to let people know:
https://sourceforge.net/blog/sourceforge-acquisition-and-future-plans /
On Mon, Mar 14, 2016 at 11:38 AM, Sérgio Basto sergio@serjux.com wrote:
On Seg, 2016-03-14 at 08:54 -0600, Orion Poplawski wrote:
On 03/13/2016 08:12 PM, Nico Kadel-Garcia wrote:
On Sun, Mar 13, 2016 at 9:15 PM, David Timms dtimms@iinet.net.au wrote:
Hi, I've worked out what seemed to be a correct URL for for rakarrack spec, now that it is accessed via git within the sf website:
I couldn't work out how to fit the sourceforce git URLs from: https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.ne t or https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Se rvices
to suit. Any ideas for a standard way to handle sf git snapshots ?
Move them to github. Seriously. Sourceforge has been playing various games to avoid accessing content without going through their adveritising functions since they were first founded, and I've found no reason to work with any project hosted there since..... checking old notes, not since 2009.
Devshare (I think it is called devshare) was a mistake and only happens on windows, and all the fault can't be impute to sf.net. sf.net was and still is an important organization that support open source and free software .
I didn't mention Devshare. I referred to the confusing and difficult to predict mishmosh of redirects, used to force developers like myself to click thorugh at least one page of undesired graphical advertisement to get a working URL for the actual source code.
packaging@lists.fedoraproject.org
-
Björn Persson -
Development discussions related to Fedora -
Nico Kadel-Garcia -
Orion Poplawski -
Sérgio Basto