> > I'd like those three logs to have the same timestamp. > > Okay. Why?
Because that way I can use the timestamp as an "id" for everything which happened in the build. For example, when I "expire" a build log because the package used to ftbfs but not anymore, I would also expire the log storing memory usage. > > Also, because some packages FTBFS randomly and in those cases I want to know > > how randomly they fail, sometimes I tell my autobuilders to build the same > > package over and over again. > > > > Because of this I'd also like to use sub-second precision, to avoid > > several build logs to have the same filename. > > I think I don't understand something here. How would two build logs have the > same file name with second-precision but not the same file name with > sub-second-precision? Good question :-) I have a "poor's man" client-server setup where autobuilders ask for build jobs and they receive a tuple containing package, version, distribution and "build mode" (A or B) as a result. I have recently changed the setup so that they also receive the timestamp to be used from the central server. Currently I have an ugly "sleep 1.5" in the coordination server (between succesive jobs) which I would like to either reduce or remove. > > So, what I would really need is a way to provide the timestamp externally. > > Do you? Why not just put the build logs into two distinct directories? In my setup all the build logs are sent to the central server to be stored there in a single directory for every distribution and build mode. For example, In ~/logs/A/buster have around 80000 build logs for build logs of type "dpkg-buildpackage -A" in buster. I could perhaps add the hostname as a suffix, but the filename is already long enough and I would prefer not to make it even longer. [...] > > Would honoring an environment variable like this, when it does exist, > > be more acceptable for you than the new configuration option we were > > discussing before? > > The environment variable name should probably be different because what you > are > supplying there is not just a timestamp but more of a build log filename > suffix > because any string could be passed that way. Sure. The patch is just a proof of concept, i.e. "what this patch does is more or less what I would like sbuild to do by default". If you adopt the patch, feel free of course to name the variables the way you think it's best. Thanks.
