On Fri, Jul 18, 2014 at 9:49 AM, Andrej N. Gritsenko <and...@rep.kiev.ua> wrote: > This is a very interesting issue. It was also reported by someone from > siduction. I believe there is some difference in dpkg processing on some > architectures so it actually creates that link instead of ignore it as > it's done on other architectures. May be this bug should be reported to > dpkg instead but I think the reasonable workaround should be inserted > into the file debian/libfm-dev.postinst (see diff below): > > set -e > > # remove empty directory so symlink can be installed there > +test -h /usr/include/libfm/libfm-1.0 && rm -f /usr/include/libfm/libfm-1.0 > test -d /usr/include/libfm && test ! -h /usr/include/libfm && rmdir > /usr/include/libfm > # if no symlink created then create it > test -h /usr/include/libfm || ln -s libfm-1.0 /usr/include/libfm > > I'm not very familiar with cross-compilation so I would like to ask you > if you could test if this will fix the issue. Thank you very much for > your help and diagnostics.
It has nothing to do with cross-compilation: both builds were native builds on unofficial architectures. My suspicion is actually that there's some race condition in the package build, which manifests intermittently if using a parallel build. I've also seen the issue happen on amd64 builds using pbuilder, though using a custom repository with locally rebuilt packages, and it wasn't 100% reproducible there. I haven't tried it using pbuilder with a vanilla chroot, but I wouldn't be at all surprised to find that it happens sometimes with that setup as well. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
