Hi, Quoting Santiago Vila (2024-04-04 15:02:05) > El 4/4/24 a las 14:07, Johannes Schauer Marin Rodrigues escribió: > > well this is an old bug. How have you worked around it being open for the > > past > > six years? > > This is important for me, so I'm still patching my own sbuild version. Yes, > every single time.
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. > 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 > > I also think that there is a more elegant solution to this. If this is just > > about the timestamp, why not add a new configuration option which allows > > customizing the default strftime format %FT%TZ to be anything else? You > > could use such a mechanism to store your own timestamp. This is what you > > suggested doing earlier in this bug report. > > Unfortunately, it's not just about the date format (that's only how it > started), > it's mainly about sbuild allowing me to specify the build log filename > beforehand, > without it second-guessing the string I really want to use. 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. > I have a recent case where the usefulness of this may be seen easily: > > Last time I tried to rebuild bookworm from source, I found several packages > which FTBFS because of expired SSL certificates being used in the tests. > > So I decided to build bookworm "in the future" to know which packages will > fail > for similar reasons in the next years. > > I first tried using libfaketime but did not managed for it to work easily. > > At the end, the most reliable way I found was to actually change the > system clock, like this: > > timedatectl set-time '2031-01-14 12:00:00' > > Now, here is the thing: When I do that, sbuild would think (rightfully) > that I'm on such date, and would use it for both the contents of > the build log and also the build log filename. > > However, in this case I still want the build log filename to be > the present day, because it's the real date where I tried such build in the > future. 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. 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. Thanks! cheers, josch
signature.asc
Description: signature
