Spec URL: http://cassmodiah.fedorapeople.org/zsync-0.6/zsync.spec SRPM URL: http://cassmodiah.fedorapeople.org/zsync-0.6/zsync-0.6-1.fc10.src.rpm Description: Zsync is a file transfer program to download files from remote web servers. If a previous version of a file is available locally, zsync will only download changed parts and hereby minimise the download volume. The algorithm is the same as used by rsync, but zsync does not require any server software (apart from a web server), nor does it need shell access. Instead, it uses a control file (.zsync file) that describes the file to be downloaded, which it uses to determine the blocks to fetch. This file is created once on the server (and not for each request) and sits next to actual file to download RPMLINT: silent
A review request already exists for this package. Closing as duplicate. *** This bug has been marked as a duplicate of bug 478617 ***
https://fedorahosted.org/fesco/ticket/134 has to be solved/approved first.
Update to 0.6.1 SPEC: http://cassmodiah.fedorapeople.org/zsync-0.6/zsync.spec SRPM: http://cassmodiah.fedorapeople.org/zsync-0.6/zsync-0.6.1-1.fc11.src.rpm Still the internal zlib problem!
Created attachment 364673 [details] zsync-0.6.1-nozlib.patch Patching out the internal zlib and zsync still worksforme. This patch could be improved with sufficient autofoo to just just touch Makefile.am (and maybe also remove zlib/Makefile.in from configure.ac, but I ran into so nasty auto nonsense so stopped here.
Comment on attachment 364673 [details] zsync-0.6.1-nozlib.patch Sorry I was not testing properly this doesn't build - got fooled by a hardlink moved by emacs... ;-(
Created attachment 365321 [details] patch to use zlib from forked from rsync the patch is not tested, just a proof-of-concept
According to bug #495310 comment #15, that won't work.
*** Bug 533778 has been marked as a duplicate of this bug. ***
*** Bug 478617 has been marked as a duplicate of this bug. ***
Hey Robert, any updates on this bug?
I'm not aware, that anything changed or improved so far...
Any updates?
There is no use requesting info from Robert. If you read this bug carefully you will see that bug 504493 is blocking this one. If you want to advance there, please bring this up to FESCo or the Fedora packaging committee.
Rsync upstream prepared patch, which allows to build rsync with system provided zlib. Are there any consequences of this patch regarding zsync? git://git.samba.org/rsync.git commit 7da17144fd764a2420a8d08897475c0b7fdbf956
I have found this in ./c/zlib/README.zsync in the zsync source code: > Local changes to zlib used by zsync > ----------------------------------- > > .... > > Contrary to some internet discussion, the changes are not related to rsync's > changes nor to rsync compatibility (zsync isn't compatible with rsync - > whatever that would mean - nor do these changes relate in any way to the > rsyncable gzip patch). Do I understand it correctly that even if we unbudle zlib from rsync, it 1) won't have any impact on zsync 2) zsync will still not be fit to be included in Fedora?
(In reply to Kamil Páral from comment #15) > Do I understand it correctly that even if we unbudle zlib from rsync, it 1) > won't have any impact on zsync 2) zsync will still not be fit to be included > in Fedora? I'd like to know too, since bug 495310 (rsync contains forked copy of zlib) was just closed in Rawhide.
Interesting...I have the same understanding as in comment #15 but also the same expectation as in comment #16. Might current rsync and zlib maintainers maybe help us here porting zsync to use a system zlib? However this requires a nice amount of expertise in that area, if I am not mistaken. Anyone?
CCing Peter Schiffer, the current zlib maintainer. Peter, would you be able to advise us here, please? I have looked at OpenSUSE zsync package and IIUIC they use the upstream version, with bundled zlib. I'm not exactly clear on the rules for granting an exception in Fedora packaging guidelines, but we at least try to ask for it, if we don't find a better way.
Kamil, I can try to look into this issue some time next week or so, but if I'm not mistaken, it was already asked for FESCO exception which was denied, here: https://fedorahosted.org/fesco/ticket/134 peter
jgrulich's scratch build of kdevelop?#c8e2b9bc57f11e41f3dc6612cdbcc591078d9062 for f22-candidate and git://pkgs.fedoraproject.org/kdevelop?#c8e2b9bc57f11e41f3dc6612cdbcc591078d9062 completed http://koji.fedoraproject.org/koji/taskinfo?taskID=11212117
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
This is an automatic action taken by review-stats script. The ticket reviewer failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we reset the status and the assignee of this ticket.
This review request is really old. Do you still intend to complete it? If so, I can review. If not, please close this issue and make it block FE-DEADREVIEW, or do nothing, in which case automation will close the request in one month. Previously, this was blocked because of bundled zlib. Since then, the rules have changed and a FESCo exception is no longer needed, just adding the appropriate virtual provide. Thus, the bundling situation should not block this any more. Links to specfile and srpm are dead, please provide fresh ones.
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.