• Bug#1002789: (No Subject)

    From Dale Richards@21:1/5 to All on Sun Dec 3 16:30:01 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian Bug Tracking System@21:1/5 to All on Tue Jan 23 17:30:02 2024
    This is a multi-part message in MIME format...

    Your message dated Tue, 23 Jan 2024 16:22:33 +0000
    with message-id <E1rSJXl-00BnQe-8x@fasolo.debian.org>
    and subject line Bug#1002789: fixed in python-pycdlib 1.12.0+ds1-5
    has caused the Debian Bug report #1002789,
    regarding python-pycdlib: FTBFS: failed tests
    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 owner@bugs.debian.org
    immediately.)


    --
    1002789: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002789
    Debian Bug Tracking System
    Contact owner@bugs.debian.org with problems

    Received: (at submit) by bugs.debian.org; 28 Dec 2021 20:45:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
    (2018-09-13) on buxtehude.debian.org
    X-Spam-Level:
    X-Spam-Status: No, score=-16.2 required=4.0 tests=BAYES_00,DIGITS_LETTERS,
    FOURLA,FROMDEVELOPER,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham
    autolearn_force=no version=3.4.2-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 317; hammy, 150; neutral, 513; spammy,
    0. spammytokens: hammytokens:0.000-+--python3, 0.000-+--pkgbuilddir,
    0.000-+--PKGBUILDDIR, 0.000-+--H*RU:178.79.145.134,
    0.000-+--Hx-spam-relays-external:sk:xanadu.
    Return-path: <lucas@debian.org>
    Received: from xanadu.blop.info ([178.79.145.134]:46302)
    by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
    (Exim 4.92)
    (envelope-from <lucas@debian.org>)
    id
  • From Debian Bug Tracking System@21:1/5 to Lucas Nussbaum on Sun Mar 3 23:40:01 2024
    This is a multi-part message in MIME format...

    Your message dated Sun, 3 Mar 2024 23:29:44 +0100
    with message-id <ff64de7d-a266-483a-85b7-7b7a2d344506@debian.org>
    and subject line Re: Bug#1002789 closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org> (reply to Thomas Goirand <zigo@debian.org>) (Bug#1002789: fixed in python-pycdlib 1.12.0+ds1-5)
    has caused the Debian Bug report #1002789,
    regarding python-pycdlib: FTBFS: failed tests
    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 owner@bugs.debian.org
    immediately.)


    --
    1002789: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002789
    Debian Bug Tracking System
    Contact owner@bugs.debian.org with problems

    Received: (at submit) by bugs.debian.org; 28 Dec 2021 20:45:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
    (2018-09-13) on buxtehude.debian.org
    X-Spam-Level:
    X-Spam-Status: No, score=-16.2 required=4.0 tests=BAYES_00,DIGITS_LETTERS,
    FOURLA,FROMDEVELOPER,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham
    autolearn_force=no version=3.4.2-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 317; hammy, 150; neutral, 513; spammy,
    0. spammytokens: hammytokens:0.000-+--python3, 0.000-+--pkgbuilddir,
    0.000-+--PKGBUILDDIR, 0.000-+--H*RU:178.79.145.134,
    0.000-+--Hx-spam-relays-external:sk:xanadu.
    Return-path: <lucas@debian.org>
    Received: from xanadu.blop.info ([178.79.145.134]:46302)
    by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
    (Exim 4.92)
    (envelope-from <lucas@debian.org>)
    id