Your message dated Sun, 28 Jan 2018 15:12:06 +0100
with message-id <20180128141206.ej5zutntnizsl...@angband.pl>
and subject line Re: FTBFS: chown: cannot access '.../t.so': No such file or
directory
has caused the Debian Bug report #886116,
regarding FTBFS: chown: cannot access '.../t.so': No such file or directory
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
886116: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886116
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: xppaut
Version: 6.11b+1.dfsg-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid your package fails to build:
dh_fixperms
chown: cannot access 'debian/xppaut/usr/share/doc/xppaut/examples/ode/t.so': No
such file or directory
chown: cannot access
'debian/xppaut/usr/share/doc/xppaut/examples/ode/testbd.ps': No such file or
directory
dh_fixperms: find debian/xppaut -true -print0 2>/dev/null | xargs -0r chown
--no-dereference 0:0 returned exit cod
e 123
dh_fixperms: Aborting due to earlier error
Tested on armhf and amd64. Log attached.
Meow!
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1,
'experimental')
Architecture: armhf (armv7l)
Kernel: Linux 4.15.0-rc6-00272-g1414bf97abd7 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
xppaut_armhf.build
Description: inode/symlink
--- End Message ---
--- Begin Message ---
On Sun, Jan 28, 2018 at 04:30:01AM +0100, Andreas Beckmann wrote:
> Control: tag -1 moreinfo
> On Tue, 02 Jan 2018 14:32:03 +0100 Adam Borowski <kilob...@angband.pl> wrote:
> > dh_fixperms
> > chown: cannot access
> > 'debian/xppaut/usr/share/doc/xppaut/examples/ode/t.so': No such file or
> > directory
> > chown: cannot access
> > 'debian/xppaut/usr/share/doc/xppaut/examples/ode/testbd.ps': No such file
> > or directory
> > dh_fixperms: find debian/xppaut -true -print0 2>/dev/null | xargs -0r chown
> > --no-dereference 0:0 returned exit cod
> > e 123
> > dh_fixperms: Aborting due to earlier error
>
> I cannot reproduce this failure in pbuilder (amd64, i386,
> armhf in qemubuilder on amd64).
> Can you still reproduce it with current debhelper?
I can't!
And in December and early January I could, on multiple different machines
(also arm64, another amd64).
Closing, as no one unpays us for bug archaeology. If it was debhelper or
some other piece of the toolchain, whatever was the cause should be ok. If,
instead, there's a hash of phase of the moon somewhere, the bug will return
and only then it'd be worth looking into.
> Two things I noticed in your log:
>
> * dh_compress did not emit the compat level deprecation warning:
> "dh_compress: Compatibility levels before 9 are deprecated (level 7 in use)"
>
> Is this a pristine dh_compress? The error sounds like a file system race
> between dh_compress and dh_fixperms (s.t. find sees the uncompressed files
> but chown only sees the compressed ones), but these two shouldn't run in
> parallel ...
Pristine.
> * the disk space calculation failed:
>
> /usr/bin/du: cannot access
> '/<<BUILDDIR>>/xppaut-6.11b+1.dfsg/debian/xppaut/usr/share/doc/xppaut/examples/ode/t.so':
> No such file or directory
> /usr/bin/du: cannot access
> '/<<BUILDDIR>>/xppaut-6.11b+1.dfsg/debian/xppaut/usr/share/doc/xppaut/examples/ode/testbd.ps':
> No such file or directory
> E: read_command failed to execute du
> E: Cannot determine space needed for /<<BUILDDIR>>/xppaut-6.11b+1.dfsg (du
> failed)
>
> That sounds fishy ... kind of a filesystem problem?
Shouldn't be -- I tried multiple machines, multiple filesystems, multiple
architectures.
Multiple filesystems rule out
https://github.com/torvalds/linux/commit/e4fd493c0541d36953f7b9d3bfced67a1321792f
which would look like a likely cause had I tested btrfs only.
On the other hand, no machine had a kernel older than 4.14 (official buildds
all run 4.9 and 3.16 AFAIK), so kernel issue can't be ruled out. I had
since upgraded to newer 4.14 point / 4.15 rc releases, and assuming the
FTBFS doesn't return, downgrading would be a waste of time.
I'll instead recheck other packages which had similar issues -- machine time
is cheap, human time can be better spent fighting beers than bugs. Which
I also recommend to you. :)
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back. What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda? Łambinowice? Most ex-German KLs? If those were "soviet
⠈⠳⣄⠀⠀⠀⠀ puppets", Bereza Kartuska? Sikorski's camps in UK (thanks Brits!)?
--- End Message ---
