Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
The full build log is available from:
http://qa-logs.debian.net/2025/01/24/libsgml-parser-opensp-perl_0.994-7_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20250124;users=lucas@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20250124&fusertaguser=lucas@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Control: tag -1 + unreproducible

That's an interesting one :)

I can't reproduce this in my cowbuilder chroot, and I wonder what
happened tp /tmp in the build environment …


Cheers,
gregor

Hi Gregor,

Indeed :)

Maybe related to me using sbuild from backports and the unshare backend?
But at the same time, it did not fail on 2025-01-07 when I was already
using the same setup.

I tried it again and reproduced it... But I can also confirm that it
builds fine on another machine... (so it's OK to downgrade)

Lucas

Control: severity -1 important

Salut !

:)
ownership of /tmp in any way? Or might there be some other cause for
"Parent directory (/tmp/) is not safe (Directory owned neither by
root nor the current user)"?

In any case: Ownership of /tmp seems out of scope for a specific
package.

Ok, downgrading to important …


Cheers,
gregor

Hi,

It should not

No idea

That's the only package failing in that way

Lucas

FWIW, I tried to run the autopkgtests with the unshare backend
yesterday (for the first time :)), and I didn't encounter any
problems.

Weird …

Looks like the code uses a rather rare feature of File::Temp:

lib/SGML/Parser/OpenSP.pm:    File::Temp->safe_level(File::Temp::HIGH);


  safe_level
      Controls the lengths to which the module will go to check the
      safety of the temporary file or directory before proceeding.
      Options are:

      STANDARD
              Do the basic security measures to ensure the directory
              exists and is writable, that temporary files are opened
              only  if  they  do  not  already exist, and that
              possible race conditions are avoided. Finally the
              unlink0 function is used to remove files safely.

      MEDIUM
              In  addition  to  the  STANDARD  security, the output
              directory is checked to make sure that it is owned
              either by root or the user running the program. If the
              directory is writable by group or by other, it is then
              checked to make sure that the sticky bit is set.

              Will not work on platforms that do not support the "-k"
              test for sticky bit.

      HIGH
              In addition to the MEDIUM security checks, also check
              for the possibility of ``chown() giveaway'' using the
              POSIX sysconf() function. If  this is a possibility,
              each directory in the path is checked in turn for
              safeness, recursively walking back to the root
              directory.

              For  platforms that do not support the POSIX
              "_PC_CHOWN_RESTRICTED" symbol (for example, Windows NT)
              it is assumed that ``chown() giveaway'' is possible and
              the recursive test is performed.


This might explain why this kind of failure doesn't appear for other
package but it still leaves the question wyh /tmp has this untypical
ownership (at least that's something the package cannot change).


Cheers,
gregor

Hi,

I don't think so. There's another bug with /tmp strangeness (#1094100),
also raised by File::Temp.

Lucas

Lucas Nussbaum <lucas@debian.org> writes:

/tmp is shown above as being owned by the nobody user (65534) rather than
root. Have you by any chance changed something about how UID mappings in
the file system might work in your builds? For example, if the build
chroot is on a remote NFS server with root-squash enabled, one might see
this. I'm not sure if using user namespaces may do something similar.

I switched to using the unshare sbuild backend (instead of schroot). But
if I understand the current state of things correctly, this is also the
case on buildds.

Lucas