Hi, Quoting Santiago Vila (2024-04-04 20:35:47) > 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.
it's a trade-of between doing that and patching sbuild over and over and over again. Or working on a patch for this bug I guess. :D > > 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. You could also add a LOG_TIMEFORMAT variable which by default would be set to "%FT%TZ" but which you could customize to your liking. > > 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). Ah okay, I understand. Yes, in that case it makes sense to run sbuild itself in the future as well. But then you should not run sbuild with LOG_TIMEFORMAT because a person in the future will not do that. To faithfully re-create what will happen in the future, you might want to use sbuild in the same way as well. Thanks! cheers, josch
signature.asc
Description: signature
