El 4/4/24 a las 19:44, Johannes Schauer Marin Rodrigues escribió:
instead of doing that, you could've worked around this by just placing the
build log into a dedicated temporary directory and then copying it to where you
want it after the build is finished.
That would be an option, yes, but maybe it's too convoluted for my taste.
Can you give me a small hint about how I should proceed? (For example, which
files in the source would require to be modified?) (Preferred name for the
command line?)
An example commit that adds a new option would be
a44b29e76450ce8c80467e0957ebc6909167e425 by Jochen. You need to touch these
files:
- lib/Sbuild/Build.pm to implement the thing
- lib/Sbuild/Conf.pm to add the configuration option
- lib/Sbuild/Options.pm to add the command line argument changing the config
option
- man/sbuild.1.in to document the command line argument
Thanks a lot! I'll try that.
I think I'd find an option useful which allows to pass a completely custom
build log filename. There is already the LOG_DIR configuration variable. Maybe
add the LOG_FILENAME configuration variable containing the filename that the
log will have when placed in LOG_DIR. The command line option can be named
--log-filename accordingly.
But I only need the date part. I still want sbuild to take care of the filename,
just not of the timestamp part of the filename.
I'll take a look at your hints above and see what I can do.
Don't run sbuild in the future. Only run dpkg inside sbuild in the future. This
is what the BUILD_ENV_CMND option lets you do. From the man page:
This command is run with the dpkg-buildpackage command line passed to it (in
the chroot, if doing a chrooted build). It is used by the sparc buildd
(which is sparc64) to call the wrapper script that sets the environment to
sparc (32-bit). It could be used for other build environment setup scripts.
I'm not sure that running only dpkg in the future is what I want to do.
I want to recreate the experience of building in the future as faithfully
as possible, so I believe setting the system clock still makes sense.
If you run sbuild with a fake time, you also run apt with a fake time which
means you potentially get into trouble with https mirrors and their certificate
expiration times, for example.
I know, but that would violate the principle of desert island for QA,
which I formulate as follows:
"It must be possible to build all packages in stable several years after
the release without having to update any of them".
or in other words:
"Packages in stable must not contain time bombs preventing their succesful build
in the few years which follow the release of stable"
In practice I already found the expiration problem for the release files
that you mention, so I already know how far in the future I can go.
My plan is to ask RMs to consider RC any FTBFS bug which happens not just
the day before we release trixie as stable (which is what we did for bookworm)
but also some years ahead (for example, maybe two for stable, two for oldstable,
and one more for general LTS).
Thanks.
