Hi! On Tue, 2017-01-10 at 11:16:27 -0500, Sam Hartman wrote: > package: dpkg > version: 1.18.10
> It's not working very well. > When I run dpkg -x hadron-installer-efi_0.10_all.deb /tmp/foo, > I get > root@mini-buildd:/tmp# ls -l /tmp/foo/usr/share/hadron-installer/ > total 8388608 > -rw-r--r-- 1 root root 8589934592 Jan 10 09:52 installer-efi.raw Right, this is running tar(1) underneath. > But when I run dpkg -I I get less promising results. > > root@mini-buildd:/tmp# dpkg -i /tmp/hadron-installer-efi_0.10_all.deb > Selecting previously unselected package hadron-installer-efi. > (Reading database ... 155174 files and directories currently installed.) > Preparing to unpack .../hadron-installer-efi_0.10_all.deb ... > Unpacking hadron-installer-efi (0.10) ... > Setting up hadron-installer-efi (0.10) ... > root@mini-buildd:/tmp# ls -l /usr/share/hadron-installer > total 0 > -rw-r--r-- 1 root root 0 Jan 10 09:52 installer-efi.raw This is instead running dpkg's internal extractor. > While this is not something we're releasing, there's no significant > proprietary interest. I'd be happy to give you access to the resulting > deb, more of the build log, whatever is necessary. > The deb is over 2g in size, but I'm happy to make it available. > For debian developers, I've placed a URI to the deb in > master.debian.org:~hartmans/dpkg-bug-url > I would prefer that URI not be posted in public simply to avoid exposing > our infrastructure. Thanks! I've gotten the .deb, can reproduce the issue locally and have confirmed my initial suspicion. This is an LFS issue, GNU tar encodes sizes that exceed the POSIX tar entry size limit in binary form, but dpkg's internal extractor does not know about that, and it does not abort either. :( I'll fix this in unstable, also because this gives us better LFS, and it's something I had pending to add support for anyway. :) Thanks, Guillem
