| === jamesh_ is now known as jamesh | ||
| === ebarretto_ is now known as ebarretto | ||
| === pieq_ is now known as pieq | ||
| juliank | Phased updates for APT are coming soon. I'm looking at the behavior of chroot-like scenarios where you do things like apt -o Dir=$mychroot update | 09:11 |
|---|---|---|
| juliank | Notably, the behavior of which packages will be installed depends on /etc/machine-id (which is used to seed a random number generator to pick a random number which is then compared to the package's phased update percentage) | 09:12 |
| juliank | The question arose that if $mychroot/etc/machine-id does not exist, how apt should behave | 09:13 |
| juliank | 1. Should it try to read /etc/machine-id from the host? | 09:13 |
| juliank | 2. Should it directly fall back to a fixed UUID? | 09:13 |
| juliank | Clearly 1 means that these environments are no longer self-contained, their behavior/set of available updates changes if you copy them around | 09:14 |
| cjwatson | Another option would be to disable phasing if there's no machine-id | 09:16 |
| juliank | cjwatson: That would work as well, yes | 09:16 |
| cjwatson | I kind of think phasing is less important for environments like chroots anyway | 09:17 |
| juliank | I think this is reasonable, yes | 09:18 |
| juliank | cjwatson: Do the buildd chroots have a machine-id? How will they behave if phasing gets enabled (and should they make use of phasing?) | 09:23 |
| juliank | Only relevant once hirsute becomes stable, but it just crossed my mind | 09:23 |
| juliank | Oh I should also disable phasing if SOURCE_DATE_EPOCH is set for reproducible image builds or whatever | 09:32 |
| Laney | juliank: what does it do, if you install a package that you don't have installed already, you might not get the -updates version? or is it only for upgrading? | 09:53 |
| juliank | Laney: That's a good point, i think it would install the release/security version | 09:54 |
| juliank | Laney: It really just pins down updates to 1 | 09:54 |
| juliank | Laney: But you're right, I can make it make it phase stuff for upgrades, not new installs | 09:55 |
| juliank | This also makes things faster! | 09:55 |
| Laney | Yeah, I think that's what I would expect, also a UI hint that some updates are not being applied due to phasing | 09:57 |
| Laney | Also, it is fairly easy to end up with systemd installed which generates a maachine ID in its postinst | 09:57 |
| Laney | I guess build environments would want to explicitly turn this off to prevent any accidents | 09:57 |
| juliank | Laney: I don't think I have a way to expose a UI hint at the moment, but I can maybe try | 09:57 |
| juliank | The way it's hacked into apt is in policy by pinning down the version that is being phased | 10:00 |
| juliank | I can make it calculate a different candidate version without phasing though, and then compare them | 10:01 |
| Laney | or you can call systemd-detect-virt and turn it off automatically :D | 10:03 |
| juliank | i do want my system containers to benefit from phasing | 10:08 |
| juliank | or wsl for that matter | 10:09 |
| juliank | or you know vms | 10:09 |
| Laney | do they detect as --chroot? | 10:09 |
| juliank | Nah, but more generically | 10:09 |
| juliank | I did not know about --chroot | 10:10 |
| juliank | :D | 10:10 |
| juliank | But then I'd reimplement systemd-detect-virt --chroot rather than dealing with exec-ing it | 10:11 |
| Laney | yeah | 10:12 |
| juliank | it's just stat(/proc/1/root) == stat(/) | 10:12 |
| juliank | well the devs and inos | 10:12 |
| cjwatson | juliank: buildd chroots must not make use of phasing. I don't remember what they have (and am EOY) - you can fetch them from LP and have a look | 11:57 |
| ItzSwirlz | tdaitx: Use this link http://reqorts.qa.ubuntu.com/reports/sponsoring/ | 13:03 |
| The_LoudSpeaker | I had asked here the other day about SRU-ing micro to 2.0.6-2 in focal. We need golang-github-zyedidia-tcell-dev v 1.4.8 in focal for that. But we have 1.4.4 in focal. I tried building the .8 in focal and it built fine without any errors. has no major changes between .4 and .8 (version number bumps and debhelper-compat bump as seen from dch) also has zero rdeps apart from micro. So is it good to SRU golang-github-zyedidia-tcell | 21:53 |
| The_LoudSpeaker | first to 1.4.8 and then micro? Anything else I should be careful about? | 21:53 |
| The_LoudSpeaker | https://paste.ubuntu.com/p/9FSFNPc4TM/ | 21:53 |
| The_LoudSpeaker | Also, side quest: is debhelper-compat 13 going to be in focal anytime soon? It's in 12 as of now afaik. that's only dependency change for golang-github-zyedidia-tcell from 1.4.4 to 1.4.8 | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!