Bug 712336
Summary: | s3cmd-1.0.1 is available | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Upstream Release Monitoring <upstream-release-monitoring> |
Component: | s3cmd | Assignee: | Matthew Miller <mattdm> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | bughunt, lkundrak |
Target Milestone: | --- | Keywords: | FutureFeature, Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | s3cmd-1.5.0-0.alpha3.fc19 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-08-24 22:27:53 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Upstream Release Monitoring
2011-06-10 10:39:33 UTC
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. BUMP! On Fedora 18: $ rpm --query s3cmd s3cmd-1.0.1-2.fc18.noarch Meanwhile, at http://s3tools.org/s3cmd or more precisely https://github.com/s3tools/s3cmd/ s3cmd 1.5.0-alpha1 -- released on 2013-Feb-19 s3cmd 1.1.0-beta2 -- released on 2012-Jan-07 Question is, are there stable releases :-( (I'm actually hitting the problem that s3cmd can't deal with non-ASCII directory names (and this is 2013) but then again, the 1.5.0 alpha apparently cannot do so either. Time for a git clone, then) I just built the alpha4 on Rawhide yesterday, in fact. (There's actually an alpha4 beyond alpha1) I'm going to trickle that back through the existing releases -- can you test the rawhide version? I don't have many actual use cases to try it with. s3cmd-1.5.0-0.alpha3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/s3cmd-1.5.0-0.alpha3.fc19 Actually, David, can you test the F19 version and give karma if that works for you? Package s3cmd-1.5.0-0.alpha3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing s3cmd-1.5.0-0.alpha3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15230/s3cmd-1.5.0-0.alpha3.fc19 then log in and leave karma (feedback). Hi Matthew, Tested on an Amazon EC2 F19 image. There are two aspects: 1) Yes, as far as I can see, 1.5 alpha works 2) But it still cannot deal with non-ASCII directory names. UnicodeDecodeError: 'ascii' codec can't decode byte .... in position ... But that is actually a Python problem whereby logging fails abysmally because the default writer for stdout assumes it only gets ASCII, cough and dies when it isn't ASCII (In a dynamic language?!?) and there is no easy or standard way to change that. I ended up editing the code to make it behave, see https://github.com/s3tools/s3cmd/issues/215 3) Will leave karma as "worksforme" 4) I think there should be a prerequisite on "gpg". s3cmd-1.5.0-0.alpha3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. (In reply to David Tonhofer from comment #7) > 1) Yes, as far as I can see, 1.5 alpha works Cool; that's sufficient for this bug. The others should be separate bug entries if you think they warrant it. > 2) But it still cannot deal with non-ASCII directory names. > > UnicodeDecodeError: 'ascii' codec can't decode byte .... in position ... > > But that is actually a Python problem whereby logging fails > abysmally because the default writer for stdout assumes it only gets > ASCII, > cough and dies when it isn't ASCII (In a dynamic language?!?) and > there is no easy or standard way to change that. I ended up editing the > code to make it behave, see Rewriting in Python 3 is the long term / sane fix. > 4) I think there should be a prerequisite on "gpg". I prefer to avoid adding hard dependencies when the package is useful/functional without. |