Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #64228

Bug#926387: oxygen-icons5: FTBFS randomly (Directory renamed before its status could be extracted)

From Vagrant Cascadian <vagrant@debian.org>
Newsgroups linux.debian.bugs.dist, linux.debian.kernel
Subject Bug#926387: oxygen-icons5: FTBFS randomly (Directory renamed before its status could be extracted)
Date 2019-06-07 01:50 +0200
Message-ID <y6aiS-iV-3@gated-at.bofh.it> (permalink)
References (4 earlier) <xKTZn-1CN-3@gated-at.bofh.it> <xJ7WN-bb-7@gated-at.bofh.it> <y69wt-8fu-5@gated-at.bofh.it> <xJ7WN-bb-7@gated-at.bofh.it> <y69wt-8fu-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.debian.kernel | Previous | Next | Find similar | Unroll thread


Thread

Bug#926387: oxygen-icons5: FTBFS randomly (Directory renamed before its status could be extracted) Vagrant Cascadian <vagrant@debian.org> - 2019-06-07 01:50 +0200

csiph-web