Re: debdelta service back on track
hi Mark Brown ha scritto: On Tue, Jul 17, 2007 at 11:23:53AM +0200, A Mennucc wrote: The problem was due to a subtle change in zlib1g: in newer versions, the compressed output has 0x02 instead of 0x00 at the 10th byte (that is in the header). This change occurred somewhere between version 1.2.3-13 and 1.2.3.3.dfsg-5 . Byte 10 is the XFL field which contains compression method specific flags. For deflate a value of two indicates that the compressor was aiming for maximum compression and a value of zero indicates nothing in particular. The code was previously not bothering to provide any information about how hard it was trying to compress things. thanks for the explanation (I was too lazy to go look into it myself :-) Since dpkg-deb uses zlib1g, this changed the .deb files. So a file reconstructed by debpatch would be different with the original in 2 bytes. Two bytes? a .deb file is an ar archive containing both a control.tar.gz and a data.tar.gz BTW: let me remind that one goal of debdelta is to obtain perfect reconstruction. The change in zlib1g did break perfect reconstruction; but the reconstructed .deb files were OK in all other respects. I have added a workaround for that problem in 'debdelta' version 0.21 , and I have installed it in the server that prepares deltas for 'debdelta-upgrade' . Now it should work again as expected. (If it does not, mail me, or send a bug in the BTS). I'm not sure exactly what debdelta is doing here but it sounds like it ought to have specific code for handing the reconstruction of this header in order to be robust against reasonable upstream changes. that is what I did. Currently a delta file also saves the header file and then puts it back forcibly. There are several fields in there which are informational and could be varied by the compressor pretty much at will. debdelta relies on the fact that dpkg-deb uses zlib1g to compress control.tar.gz and a data.tar.gz ; so debdelta calls minigzip, that obtains the same exact result - unless zlib1g changes, of course. debdelta currently is not robust w.r.t. strong changes in zlib1g ... the only way to achieve robustness would be that I should ship a copy of the source code of zlib1g inside the debdelta package (but that is inconvenient in other respects). a. signature.asc Description: OpenPGP digital signature
debdelta service back on track
hi all, about two weeks ago 'debdelta-upgrade' started failing. Unfortunately I was away with (almost) no Internet access. Today I could finally fix the problem. The problem was due to a subtle change in zlib1g: in newer versions, the compressed output has 0x02 instead of 0x00 at the 10th byte (that is in the header). This change occurred somewhere between version 1.2.3-13 and 1.2.3.3.dfsg-5 . (I am sending a CC to the upstream authors and to the Debian Mantainer, in case they are not aware of this change). Since dpkg-deb uses zlib1g, this changed the .deb files. So a file reconstructed by debpatch would be different with the original in 2 bytes. I have added a workaround for that problem in 'debdelta' version 0.21 , and I have installed it in the server that prepares deltas for 'debdelta-upgrade' . Now it should work again as expected. (If it does not, mail me, or send a bug in the BTS). Note that endusers that only use 'debpatch' and 'debdelta-upgrade' do not need to upgrade: the workaround is in the delta-ing code. a. --- Info debdelta is a program suite designed to compute changes between Debian packages. It contains various utilities, including 'debdelta-upgrade' that can be used by people with slow access to Internet to speed up their apt-get upgrade. The debian package is http://packages.debian.org/unstable/devel/debdelta More info are available at http://tonelli.sns.it/pub/mennucc1/debdelta/README signature.asc Description: OpenPGP digital signature
Re: debdelta service back on track
On Tue, Jul 17, 2007 at 11:23:53AM +0200, A Mennucc wrote: The problem was due to a subtle change in zlib1g: in newer versions, the compressed output has 0x02 instead of 0x00 at the 10th byte (that is in the header). This change occurred somewhere between version 1.2.3-13 and 1.2.3.3.dfsg-5 . Byte 10 is the XFL field which contains compression method specific flags. For deflate a value of two indicates that the compressor was aiming for maximum compression and a value of zero indicates nothing in particular. The code was previously not bothering to provide any information about how hard it was trying to compress things. (I am sending a CC to the upstream authors and to the Debian Mantainer, in case they are not aware of this change). Not that it's likely to be important but you've only CCed me, not upstream. Since dpkg-deb uses zlib1g, this changed the .deb files. So a file reconstructed by debpatch would be different with the original in 2 bytes. Two bytes? I have added a workaround for that problem in 'debdelta' version 0.21 , and I have installed it in the server that prepares deltas for 'debdelta-upgrade' . Now it should work again as expected. (If it does not, mail me, or send a bug in the BTS). I'm not sure exactly what debdelta is doing here but it sounds like it ought to have specific code for handing the reconstruction of this header in order to be robust against reasonable upstream changes. There are several fields in there which are informational and could be varied by the compressor pretty much at will. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
