Right, I've gone down a rabbit hole with this. I don't have a fix yet,
but I'll post what I've found here in case it makes sense to anyone.
The problem manifests when the internal_check_dot_dir_record() and
internal_check_dotdot_dir_record() functions from
tests/integration/test_common.py are run. In particular the tests are
comparing the posix_file_links attribute of the Rock Ridge PX record to
an expected value. In this case posix_file_links corresponds to the
st_nlink member as defined in POSIX:5.6.1 (i.e. the number of links to
the file/inode), and allows Rock Ridge to store this extended POSIX
information within an ISO9660 CD file system.
For both the . (dot) and .. (dotdot) directory entries within the
generated .iso file, the tests are expecting the number of links to be
3, although in my build tests it it actually appears to be 2 for <dot>
and 3 for <dotdot>.
Curiously, when I extract the failing tests from the package and run
them in isolation, the posix_file_links value is 3 for both the . and
.. directory entries, and the tests pass as expected. I did, however,
have to make a tweak to the test logic...
At test_hybrid.py:784, the source package is creating its temporary
directory with:
indir = tmpdir.mkdir('rronefileonedir')
When I tried this in isolation, the mkdir() method was not found, so I
substituted it with:
indir = os.path.join(tmpdir, 'rronefileonedir')
os.mkdir(indir)
Presumably I missed an import or type definition somewhere when
isolating the tests, but the tests run successfully with this code.
On my test system, creating a directory with os.mkdir() from Python
gives st_nlink==2 for . and st_nlink==3 for .., and I get the same
results when creating the directory directly with the mkdir command.
My first thought was that my build chroot was somehow messing with the
st_nlinks value of the created directories, but I can reproduce the
same test failures when building directly on my test machine without a
chroot.
Perhaps there's something odd about the tmpdir.mkdir() method called in
the original code, or the way Python's os module creates directories
during the Debian build sequence?
At this point my head started to hurt, so I've stopped looking for now,
but I thought I'd braindump here in case this rings a bell for anyone
with more POSIX/Rock Ridge/Debian/Python experience than me.
Best regards,
Dale Richards
