Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:
--------------------------------------------------------------------------------
[...]
  debian/rules binary
dh binary --buildsystem=octave
    dh_update_autotools_config -O--buildsystem=octave
    dh_autoreconf -O--buildsystem=octave
    dh_octave_version -O--buildsystem=octave
Checking the Octave version... ok
    dh_auto_configure -O--buildsystem=octave
    dh_auto_build -O--buildsystem=octave
    dh_auto_test -O--buildsystem=octave
    create-stamp debian/debhelper-build-stamp
    dh_testroot -O--buildsystem=octave
    dh_prep -O--buildsystem=octave
    dh_auto_install --destdir=debian/octave-vibes/ -O--buildsystem=octave
	octave --no-gui --no-history --silent --no-init-file --no-window-system /usr/share/dh-octave/install-pkg.m /<<PKGBUILDDIR>>/debian/octave-vibes/usr/share/octave/packages /<<PKGBUILDDIR>>/debian/octave-vibes/usr/lib/x86_64-linux-gnu/octave/packages
make[1]: Entering directory '/<<PKGBUILDDIR>>/src'
/usr/bin/mkoctfile --verbose -o "__vibes__.oct" "__vibes__.cpp"
g++ -c -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/octave-8.4.0/octave/.. -I/usr/include/octave-8.4.0/octave  -pthread -fopenmp -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection    __vibes__.cpp -o /tmp/oct-yXW8qv.o
g++ -I/usr/include/octave-8.4.0/octave/.. -I/usr/include/octave-8.4.0/octave  -pthread -fopenmp -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection  -o __vibes__.oct  /tmp/oct-yXW8qv.o   -shared -Wl,-Bsymbolic -Wl,-z,relro  -L/usr/lib/x86_64-linux-gnu -shared -Wl,-Bsymbolic  -flto=auto -ffat-lto-objects -Wl,-z,relro
make[1]: Leaving directory '/<<PKGBUILDDIR>>/src'
copyfile /<<PKGBUILDDIR>>/./src/__vibes__.oct /<<PKGBUILDDIR>>/./inst/x86_64-pc-linux-gnu-api-v58
warning: addpath: package directories should not be added to path: /<<PKGBUILDDIR>>/debian/octave-vibes/usr/share/octave/packages/vibes-0.2.0/+vibes
For information about changes from previous versions of the vibes package, run 'news vibes'.
    dh_octave_check -O--buildsystem=octave
Checking package...
Checking m files ...
warning: addpath: package directories should not be added to path: /<<PKGBUILDDIR>>/debian/octave-vibes/usr/share/octave/packages/vibes-0.2.0/+vibes
[inst/+vibes/beginDrawing.m]
***** test
  vibes.beginDrawing
  vibes.endDrawing
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault
make: *** [debian/rules:5: binary] Error 139
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
--------------------------------------------------------------------------------

The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/202312/

About the archive rebuild: The build was made using virtual machines
from AWS, with enough memory, enough disk, and either one or two
CPUs, using a reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.

Dear submitter,

as the package octave-vibes has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1058025

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)

Hello.

I'm sorry to see this package removed because of this bug which I filed.

I trust that removing the package was the right thing to do, but I just
read the removal request you did to ftpmasters (#1058025) and would
like to make a minor comment which is only indirectly related:
This is from debhelper(7):

        HOME, XDG_*
            In compat 13 and later, these environment variables are reset before invoking the upstream build system
            via the dh_auto_* helpers.  The variables HOME (all dh_auto_* helpers) and XDG_RUNTIME_DIR (dh_auto_test
            only) will be set to a writable directory. All remaining variables and XDG_RUNTIME_DIR (except for
            during dh_auto_test) will be cleared.

            The HOME directory will be created as an empty directory but it will be reused between calls to
            dh_auto_*.  Any content will persist until explicitly deleted or dh_clean.

i.e. you may rely on a writable $HOME if it's for a "good cause" (i.e. dh_auto_test).

So, the simple question: Should this not be also implemented in dh_octave_check as well,
which is what octave-vibes was using?

Also, while we are at it, the Policy paragraph that you quoted:

would probably need to be reworded a little bit.

Thanks.

* Santiago Vila <sanvila@debian.org> [2023-12-12 20:25]:

Actually, the main reason for requesting the removal is the fact that the
package is unusable without the VIBES viewer. Note that if the latter is
packaged for Debian, then the octave-vibes package can be resurrected.

Thanks for bringing this to my knowledge. However, I do not quite
understand the text above. Does it mean that, when the package
Build-Depends on debhelper-compat = 13, then $HOME will be set
automatically to a writable directory? Well, octave-vibes that
compatibility level of debhelper, but the autobuilders set
HOME=/nonexistent/.

I agree. I think that a bug report should be filed against
debian-policy on this issue.

Best,

Rafael Laboissière

El 13/12/23 a las 9:27, Rafael Laboissière escribió:

Sorry, I don't really know for sure.

I just remember this case where the debhelper feature allowed for an "easy" fix:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025654

Yes, I'll add that to my todo list.

Thanks a lot.

Rafael

* Santiago Vila <sanvila@debian.org> [2023-12-15 12:59]:

There is something that I definitively do not understand here. Let's
take your build log for octave-vibes:
https://people.debian.org/~sanvila/build-logs/202312/octave-vibes_0.2.0-8_amd64-20231205T162533.194Z

We see that debhelper-compat = 13 is used (line #76) in the build.
However, we see the following in line #3199:

     User Environment
     ----------------

     […]
     HOME=/sbuild-nonexistent
     […]

It seems that your building system is setting HOME to an non-existent
directory. How do you explain that ?

Best,

Rafael

El 15/12/23 a las 17:00, Rafael Laboissière escribió:

In this case, given its name, the variable is set by sbuild
before starting the build. This is the standard software used to
build packages by the official autobuilders and also by anybody
doing archive-rebuilds for QA purposes.

You can find such HOME=/sbuild-nonexistent line in any successful
build log as well:

https://buildd.debian.org/status/fetch.php?pkg=octave&arch=amd64&ver=8.4.0-1%2Bb1&stamp=1700257373&raw=0

After sbuild sets HOME to an unwritable value, some debhelper tools,
it seems, may in turn set HOME to a temporary writable directory in certain
circumstances which I still have not studied carefully.

The thing I don't understand here is why this problem in octave-vibes
was diagnosed as an "unwritable $HOME" in the first place.

Thanks.

* Santiago Vila <sanvila@debian.org> [2023-12-15 18:15]:

This is what I concluded after running some tests, but I do not
remember the details. I will try to replicate it.

Best,

Rafael Laboissière

* Rafael Laboissière <rafael@debian.org> [2023-12-15 21:44]:

I did the investigation again, using pbuilder. Here is what I found:

– In my case, pbuilder sets HOME=/nonexistent/ and debhelper (compat
level = 13) keeps that setting. Hence, the package FTBFS.

– If I use "export HOME = /tmp", for instance, in debian/rules, then
the build succeeds.

Best,

Rafael Laboissière

El 16/12/23 a las 22:30, Rafael Laboissière escribió:

Thanks for the additional investigation. This is why I was sorry to see this
package being removed, as you have just confirmed that the FTBFS problem
was indeed easy to fix... Nevermind, I take note of course that it was not
the main reason for the removal.

I guess a more standard approach, if you ever have to do this in a real package,
would be to do this:

HOME := $(shell mktemp -d)

so that the same directory is never used twice between consecutive builds.

Thanks.

* Santiago Vila <sanvila@debian.org> [2023-12-20 13:43]:

Yes, the real reason is elsewhere.

Yes, this is a much better solution. Thanks for the suggestion. I am just
wondering: is there a simple way to delete the temporary directory after
he build is finished ?

Best,

Rafael

El 20/12/23 a las 21:08, Rafael Laboissière escribió:
so if the package just writes a few files which are also small, it's not
something for which I would worry too much.

Personal note: I also used to worry about that in my archive rebuilds. In fact,
I collected the information about how much junk each package created at /tmp,
with the idea of reporting the extreme cases some day.

This was a problem because I was using the "default" profile
for schroot (i.e. /etc/schroot/default), which bind-mounts the /tmp
in the chroot to the /tmp in the host machine.

But now I've recently switched to the "sbuild" profile, which I use with
either overlayfs or with file-based chroots, so the chroot used for
each package build, including /tmp, is completely new each time.

This is really the "normal thing". If you look at any build log at
buildd.debian.org, you will see something like this:

Purging /<<BUILDDIR>>
Not cleaning session: cloned chroot in use


Thanks.

* Santiago Vila <sanvila@debian.org> [2023-12-20 22:03]:

Yes, it not really a worrisome issue. However, I have just noticed that
the solution that you proposed with mktemp is a little bit intrusive.
Indeed, a new temporary directory is created at each invocation of
debain/rules, such that I end up with five /tmp/tmp.* directories after
package building, with only the last one being actually used. I will try
another approach, probably by changing the dh_octave_check script, which
is the one that eventually needs a writable $HOME directory.

Best,

Rafael Laboissière

Le jeudi 21 décembre 2023 à 08:49 +0100, Rafael Laboissière a écrit :

Note that within the context of a shell script, the following ensures
that the directory is automatically deleted upon exit:

tmpdir=$(mktemp -d)
cleanup ()
{
    rm -rf "${tmpdir}"
}
trap cleanup EXIT

* Sébastien Villemot <sebastien@debian.org> [2023-12-21 15:23]:

Thanks, Sébastien.

I think that it is possible to do something similar in Perl (the language
in which dh_octave_check is written) by using the %SIG hash. I will take
a look at it.

Best,

Rafael

* Rafael Laboissière <rafael@debian.org> [2023-12-22 04:36]:

I got confused, sorry. Actually, dh_octave_check is written in Shell.

I have uploaded version 1.6.0 of dh-octave with the needed changes.

Best,

Rafael