Bugzilla Bug 89475

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 an attachment (id=57454) [edit]
new ebuilds for deltup and getdelta

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 an attachment (id=57455) [edit]
new ebuilds for deltup and getdelta

(From update of attachment 57455 [edit])
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