On 2019-06-07, Guillem Jover wrote: > On Tue, 2019-04-09 at 10:02:25 +0200, Santiago Vila wrote: >> Hmm, I said: >> > Is dpkg in buster calling tar with any options that makes this >> > behaviour to happen more easily? Is tar in buster more prone to this >> > failure when using overlayfs? >> >> By looking at my build logs I see that this is not really related to >> buster, but related to the fact that I started to use virtual machines >> from Scaleway. Apparently this is really easy to happen there. >> >> Still, I would like to know if there is some kind of workaround other >> than stopping using overlayfs. > > I don't really know. I just know that overlayfs has caused compliance > problems in the past, so I'd recommend avoiding it TBH. I'm having intermittant similar issues with sbuild+overlay fs (from the linux kernel, not the fuse implementation; I presume ) with building "linux" on my laptop. The build failures were really infrequent when running stretch (less than 1 out of 100 builds) but have recently started becoming much more frequent since upgrading to buster... (e.g. it had it happen 3 times in a row and the 4th worked fine). dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building linux using existing ./linux_5.1.7.orig.tar.xz tar: linux-5.1.7/arch/csky/boot/dts/include: Directory renamed before its status could be extracted tar: linux-5.1.7/arch/csky/boot/dts: Directory renamed before its status could be extracted tar: linux-5.1.7/arch/csky/boot: Directory renamed before its status could be extracted tar: linux-5.1.7/arch/csky: Directory renamed before its status could be extracted tar: linux-5.1.7/arch/arm64/boot/dts/arm: Directory renamed before its status could be extracted tar: linux-5.1.7/arch/arm64/boot/dts: Directory renamed before its status could be extracted tar: linux-5.1.7/arch/arm64/boot: Directory renamed before its status could be extracted tar: linux-5.1.7/arch/arm64: Directory renamed before its status could be extracted tar: Exiting with failure status due to previous errors dpkg-source: error: tar -xf - --no-same-permissions --no-same-owner subprocess returned exit status 2 The upperdir is a tmpfs and the lowerdir is an ext4 filesystem in my case. I'm not sure if there's some way to generate the .orig.tar.xz in a way that reduces the likelihood of this happening? I've been using "debian/bin/genorig.py ." from a git repository that also contains upstream tags. live well, vagrant
Attachment:
signature.asc
Description: PGP signature