Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
info@openhub.net
Hey guys,
I'm getting the following upon attempting to upload one of two regular releases I'm making from our CI
2009-05-07 21:46:04 3874 Instruct file '/home/chroot/projects/o/openrasta/instructs/ohloh.xml' running.
2009-05-07 21:46:05 3874 Error: #/usr/lib/ruby/1.8/net/http.rb:2097:in error!'./script/../lib/fup/poster.rb:31:in
post'./script/../lib/fup/instruct.rb:79:in accept!'script/fup_instruct:50:in
accept'script/fupinstruct:48:in `each'script/fupinstruct:48:in accept'./script/../lib/fup/pid_file.rb:22:in
lock'./script/../lib/fup/pidfile.rb:19:in `open'./script/../lib/fup/pidfile.rb:19:in lock'script/fup_instruct:47:in
accept'script/fupinstruct:80:in `send'script/fupinstruct:80:in `run!'script/fup_instruct:93
2009-05-07 21:46:05 3874 Instruct file '/home/chroot/projects/o/openrasta/instructs/ohloh.xml' failed.
Note that this is (or should be) exactly the same instruct file as for the beta 1 release that gets pushed out fine. Somehow the trunk one doesn't.
Anyone got any ideas?
Thanks,
Seb
Hi Seb,
I think the problem is that filename OpenRasta-2.0.200.exe
has already been used.
The way our distribution system is set up, files are expected to be immutable, so the same filename cannot be re-used for new content.
If you choose another filename, the upload should work.
If the filename is non-negotiable, let me know, because there may be some monkey patching we can do behind the scenes to free up the filename.
If it's still broken even after you try another filename, let me know and I'll do some more digging.
Thanks,
Robin
Hey Robin,
thanks for the reply.
I'm a bit confused. I've been uploading OpenRasta-2.0.100.exe to send newly patched versions of the file continuously for the last couple of weeks, and it seems the upload worked just fine and just overwrote the previous version of the file in that situation, which is the behavior I wanted.
This lets me publish new versions including the latest patches from the community while still preserving the download stats for a specific version (aka the number of donwloads for any of the beta 1 binaries, whatever patches are included).
I just downloaded and installed the OpenRasta-2.0.100.exe currently on ohloh and confirmed that the version of the binaries that is included is indeed the latest one from the builds, and I assume this means that the behavior I described is what is happening for that file.
Is there a reason why OpenRasta-2.0.100.exe and OpenRasta-2.0.200.exe seem to have different behavior?
How do you suggest i proceed for uploading new hotfix releases of a version without having to have separate files?
I'm happy doing whatever work is needed on my side, as it's already dead nice of you guys to be handling the massive amount of downloads my releases are triggering (the whole 40 of them!) :)
Thanks,
Seb
If you need me to have different file names for each upload, let me know I'll make the change. It wouldn't be much of an issue.
The current behavior just has me a bit confused :)
keep up the good work
Seb
Hi Seb,
Hmm, now it's my turn to be a bit confused. If you've been uploading the same filename over and over, I have some debugging to do. That really shouldn't work, and I'm very curious how you snuck through.
I did some more trials today, and tried re-running your latest instruct file while watching its progress. I can confirm that (at least today) our system is rejecting the new upload because it has a filename that is already in use. That's the designed behavior, even if it's not documented and there was no helpful error message. :-(
I'll go modify our documentation right now to include the information that filenames must be unique within the scope of a single project.
I'm sorry for the troubles. Let me know if there's anything else I can do help out.
Thanks,
Robin
HTML tag #fail .. please ignore (repost below).
Hi Robin,
Love the scp interface .. great idea!!
I'm not sure if this is related but I found your reference to 'files are expected to be immutable, so the same filename cannot be re-used for new content.'.
I have set-up:
a) a 'Package' called 'Application Builds'
b) a 'Release' called v0.1 and v0.2
c) planned to upload the binary file (same name) to both ..
note: with the package and release structure it would seem feasible to keep the same file name. Might be good to FAQ this (I may have missed it).
That said, in trying it I am getting the log result ...
2009-11-29 23:31:18 26345 Instruct file '/home/chroot/projects/e/enumdiscoverer/instructs/applications.xml' running.
2009-11-29 23:31:19 26345 Error: #/usr/lib/ruby/1.8/net/http.rb:2097:in error!'./script/../lib/fup/poster.rb:31:in
post'./script/../lib/fup/instruct.rb:79:in accept!'script/fup_instruct:50:in
accept'script/fupinstruct:48:in `each'script/fupinstruct:48:in accept'./script/../lib/fup/pid_file.rb:22:in
lock'./script/../lib/fup/pidfile.rb:19:in `open'./script/../lib/fup/pidfile.rb:19:in lock'script/fup_instruct:47:in
accept'script/fupinstruct:80:in `send'script/fupinstruct:80:in `run!'script/fup_instruct:93
2009-11-29 23:31:19 26345 Instruct file '/home/chroot/projects/e/enumdiscoverer/instructs/applications.xml' failed.
Have emailed samples to info 'at' etc.
Cheers,
Alan
Hi Alan,
From the looks of it, you already figured this out. For the sake of others with the same problem: Yes, the issue is reusing the same filename. Sorry the error was cryptic. I'll add a bug to make this easier but I can't estimate by when we'll fix it.
DV Video can only be transfered to PC by the Firewire port. The USB port is only for any still pictures you've taken, since it's much too slow to keep up with the video.