[01:31] <holmanb> rbasak: Reseting machine-id at runtime would force boot order requirements on all services (present and future) that use machine-id. Do we have an idea of which/how many services this might affect?
[01:46] <lunatiq> in regard to postfix/mailutils to enable mail() on dedicated machine. Do I select Internet Site for each domain or do I create a domain for it?
[01:47] <lunatiq> can I just use local and use it for local use only?
[01:47] <lunatiq> Would that enable scripts on local machine to use mail() ?
[01:59] <blahdeblah_> lunatiq: If all you want is mail on local machine then you can choose local
[03:48] <lunatiq> blahdeblah_ does that mean PHP can use mail() function?
[03:55] <blahdeblah_> lunatiq: I don't know enough about the PHP mail() function to answer that, but if it can be configured to use localhost as its SMTP server, or /usr/bin/mail as its local mailer, then I'd think it would work.
[08:23] <effendy[m]> holmanb: systemctl -t service | nc -l for instance? Services is a broad word.
[08:23] <effendy[m]> broad idea*
[16:09] <Odd_Bloke> holmanb: I guess my response would be that those services doing the wrong thing earlier in boot (due to a stale machine-id) is not a desirable outcome, so it seems irrelevant how many/which services would be affected.
[16:13] <Odd_Bloke> Having said that, I don't see a systemd level dependency on /etc/machine-id in any units on my system, so I don't know if there will be an _easy_ way to do that.
[16:13] <Odd_Bloke> s/do that/determine that set of services/
[16:14] <Odd_Bloke> As a data point, DigitalOcean already have vendor-data to handle resetting machine-id on first boot, because not doing so causes problems.
[16:18] <holmanb> Odd_Bloke: Which services seems relevant in that any that are ordered before cloud-init would have to be restarted with the new machine-id - and really any that use it should probably be explicitly ordered after whichever cloud-init unit would be made to do the runtime rewriting of machine-id. 
[16:19] <holmanb> Odd_Bloke: How many services was just a question of the scope that such a change would affect.
[16:22] <Odd_Bloke> holmanb: Ack, understood, thanks!
[17:33] <ahasenack> rbasak: did we ever plan or think about extracting detached orig tarball signatures, if they exist in lp or pristine-tar, when running git ubuntu export-orig ?
[19:37] <rbasak> ahasenack: I was not aware that they exist
[19:38] <ahasenack> I don't know if they are handled by pristine-tar (i.e., ingested), or LP
[19:38] <ahasenack> but every now and then I see a dpkg warning during build that a gpg key exists in the source, but no detached signature
[19:38] <ahasenack> and I think this could be improved, if the .sig files are stored somewhere
[19:38] <rbasak> Sounds reasonable, if they work everywhere else through the pipeline
[19:39] <ahasenack> dpkg-buildpackage seems to check it when building it seems
[19:39] <ahasenack> but I haven't verified. I just saw the warning