Not sure how to report this - I use getdelta as my fetch command, worked fine for a long time, lately (since the new md5 all files is when I really noticed) any of the dtu files, after successfully downloading, report that there is a filesize mismatch. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: continuous loop of downloading the .dtu and filesize mismatch error Expected Results: .dtu file downloads, creates new archive successfully I use getdelta because I am on a dialup connection. The easy workaround is to simply comment out the FETCHCOMMAND line in /etc/make.conf, however that requires me downloading a lot longer than I "should" have to. I am not sure if this is a problem upstream, or not, but no one seems to be responding in #dynamic-deltup-server.
Just got a response - This is due to bzip2 1.0.3 changes in the compression - could we have getdelta require 1.0.2 of bzip2? or would it not matter?
*** Bug 89742 has been marked as a duplicate of this bug. ***
Do you have a rough estimate of how many packages are affected? I think they are not many ... so they can just be downloaded manually .. but it is not good that getdelta keeps trying again and again ..
they are working on it - but until developers start picking up 1.0.3 and making their bz2 files with it, not really - its due to the way the compression scheme works and there is afaik, no way to differentiate between whether 1.0.2 and 1.0.3 were used to create the bz2 file. it will affect some packages, but not all - it's fairly luck of the draw right now.
some details bothie found on this issue: The only thing 1.0.3 doesn't do anymore is to emit huffman codes >17 bits, while 1.0.2 emitted up to 20 bit long huffman codes. One way to detect 1.0.2 is to check for huffman codes >17 bits. So, it might be useful to use a modified version of bzip2 and create both versions - then check which one passes the MD5SUM check. And no, this "modified version" does not exist yet, but we are trying our best.
> One way to detect 1.0.2 is to check for huffman codes >17 bits. Only to prevent confusions: If we find a hc >17 bits, we know it's not 1.0.3, but if we don't it still may be 1.0.2, so even this is no save way to distinquish 1.0.2 and 1.0.3 :( Regards, Bodo
Created attachment 57454 [details] WRONG This is the solution to the problem - actually I found deltup was perfectly prepared for this issue, because there were similar problems between bzip-0.9 and bzip-1.0.0 So here's what these ebuilds change: the ebuild of getdelta-0.6.9-r1 depends on >=bzip2-1.0.3 now, but installs a statically linked version of bzip-1.0.2 as /usr/bin/bzip2_old the ebuild of deltup-0.4.2-r1 does not change any code of deltup - just changes the output in --help and when trying to patch with dtu that need bzip2_old. So it tells the user he need version 1.0.2 as bzip_old (instead of 0.9 before) and that -e would check if the md5sum is correct (when building a dtu) because of the difference to version <1.0.3 (instead of 1.0.0 before) I have tested this - and it works perfectly. I think this is the best solution - much better than changing the code of any application since we have 4 deltup servers now - the extra cpu power needed on server side is ok - I haven't seen them working all at the same time so we actually have that cpu power now. genstef, please submit this as soon as possible - I will inform the other server owners which changes are needed. best wishes, Nicolai aka blackpenguin
Created attachment 57455 [details] new ebuilds for deltup and getdelta
Comment on attachment 57455 [details] new ebuilds for deltup and getdelta oops...need some sleep :) Ok this is the correct file.
oh, btw... I informed upstream john whitney about my changes in deltup's output. already
thanks, fixed
