[09:44] <Laney> juliank: what's a valid way to wait for a parallel 'apt update' to finish?
[09:44] <Laney> I'm looking at the update-motd test failure, I think letting the apt update settle before trying to run update-motd would do it
[09:46] <Laney> it's a bit of a weird test, it's kind of verifying that all other update-motd snippets are bug free ...
[09:49] <RikMills> is there anyone with a particular interest in getting the rust-* things in proposed migrated?
[09:49] <RikMills> ed_: ^^
[09:49] <RikMills> as I don't really know who to talk to
[09:54] <ed_> I have an interest, yes!
[09:55] <juliank> Laney: hmm I don't have a solution
[09:57] <RikMills> ed_: yes. I meant someone to help you with the issues
[10:10] <juliank> Laney: but confused why apt update is running while we do the test
[10:10] <juliank> Laney: is there some service/timer we forgot to disable on the autopkgtest image?
[10:18] <Laney> juliank: one of the test deps kicks it off
[10:18] <Laney> 'plinth', something from freedombox I think
[10:22] <juliank> Laney: yup it installs timers, but does not disable the service
[10:24] <juliank> Laney: at least I thought it did
[10:24] <Laney> I don't wanna fix freedombox really :p
[10:24] <Laney> that's sort of why I say this test in update-motd is weird
[10:24] <Laney> it should probably make a drop in itself and check that that works
[10:24] <Laney> if it's trying to test the interface
[10:25] <Laney> and the integrating packages themselves test their own integration works
[10:26] <juliank> can it drop the freedombox bit?
[10:26] <Laney> that's one option
[10:27] <juliank> there's no way to reliably wait for an update to end
[10:27] <juliank> while we touch a few files due to update-notifier or send signals over dbus when freedombox is installed)
[10:28] <juliank> by the time you setup wait on those, they might already have happenedf
[10:28] <juliank> Ah but of course, you could lock /var/lib/apt/lists/lock
[10:28] <Laney> I was writing something based on F_SETLKW on /var/lib/apt/lists/lock but yeah
[10:29] <Laney> or without W, dunno
[10:29] <Laney> still feels kinda sketchy
[10:59] <Laney> juliank: ok I added a kinda dubious script to do that
[10:59] <Laney> works locally, let me check in a silo
[10:59] <juliank> hooray
[11:00] <Laney> it just locks at the start though
[11:00] <Laney> doesn't hold it through the whole update-motd run
[11:00] <Laney> arguably that would be better, not sure if it would break anything inside there if they want to apt update
[11:01] <Laney> well it would, I mean I'm not sure if anything *does* do that
[11:01] <Laney> I saw that that plint thing itself does a dist-upgrade and installs unattended-upgrades when it starts up /o\
[11:02] <Laney> plinth
[11:02] <Laney> 4478
[11:05] <juliank> oh boy
[11:05] <juliank> that sounds wrong
[11:09]  * Laney la la la
[11:19] <rbalint> Laney, rtkit tests i triggered yesterday seem to have gone missing but today one newly triggered one passed
[11:19] <rbalint> Laney, not sure if there is anything to do with the lost ones
[11:28] <Laney> rbalint: I don't see them in the logs at all, that implies the submission didn't get to the queue for some reason
[11:34] <rbalint> Laney, i've triggered rtkit/non-amd64 today, but i don't see the results on https://autopkgtest.ubuntu.com/packages/r/rtkit/hirsute/arm64 nor on http://autopkgtest.ubuntu.com/running
[11:35] <rbalint> and i've just retriggered s390x which does show up on /running now
[11:36] <Laney> rbalint: https://paste.ubuntu.com/p/fqT2yCgJJT/
[11:36] <Laney> that's what we have
[11:37] <Laney> oops pasted it twice but you get the idea
[11:39] <rbalint> Laney, ok, so i see the results are stored to swift but they don't show up on test history
[11:40] <rbalint> Laney, test history for amd64 is refreshed because i see the result from today
[11:42] <rbalint> Laney, can the parallel same test mess this up in bileto?
[11:42] <rbalint> sil2100,^
[11:54] <Laney> rbalint: some more results just showed up
[11:54] <Laney> not sure what you mean about bileto but I can't imagine how things would interfere
[14:18] <seb128> rbalint, hey, it seems like gcl abort directly with the new glibc, is that a known issue?
[14:27] <rbalint> Laney, could you please merge and deploy https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/399088 ?
[14:27] <rbalint> seb128, looking
[14:28] <rbalint> seb128, new to me, wher do you observe it?
[14:29] <seb128> rbalint, $ gcl
[14:29] <seb128> The assertion realpath(s,o) on line 475 of main.c in function mbin failed: Invalid argumentAborted (core dumped)
[14:30] <seb128> rbalint, I was poking at why fricas autopkgtests are failing
[14:33] <rbalint> seb128, yes, looks bad, do you have an LP bug?
[14:33] <seb128> rbalint, not yet, do you want one?
[14:34] <rbalint> seb128, yes please, against gcl for now
[14:36] <seb128> rbalint, https://bugs.launchpad.net/ubuntu/+source/gcl/+bug/1917631
[15:23] <Laney> sil2100: hey is there any way I / you can check where the proposed-migration run is at for silo 4478?
[15:24] <Laney> I feel like I would have expected it by now but maybe it is still running
[15:24] <Laney> or in a queue
[15:58] <sil2100> Laney: looking
[15:59] <sil2100> Laney: uh oh, something barfed, hm
[15:59] <sil2100> Investigating
[16:08] <Laney> sil2100: alrighty
[16:09] <sil2100> Laney: but basically, you can find all the interesting files here:
[16:09] <sil2100> https://bileto.ubuntu.com/static/index.html
[16:10] <Laney> ooh cool secret URL thanks
[16:10]  * Laney saves that one
[16:11] <sil2100> Not that secret, it's on every Bileto page actually! There's a 'Browse Raw Files' button ;)
[16:11] <Laney> heh
[16:11] <Laney> make the text boring enough and nobody will click it
[17:22] <rbasak> lucasmoura, rbalint: looking at unattended-upgrades, I was expecting one or two MD5s to be added. Why 117?
[17:23] <rbasak> It seems quite opaque to me, rather like checking in a binary. It isn't clear to me what inputs would result in these hashes, so I can't predict behaviour.
[17:26] <rbalint> rbasak, hashes for known config files to not ask for with ucf
[17:27] <rbalint> rbasak, so while i expected only a few appering 117 is also ok
[17:27] <rbasak> rbalint: but the purpose of ucf is to prompt if the user has locally changed the config file.
[17:27] <rbasak> If you include basically all possible configuration permutations in the history file, won't you be defeating that?
[17:28] <rbasak> How did 117 different possibilities arise?
[17:28] <rbalint> rbasak, no, only the combinations are present which were shipped
[17:28] <rbalint> rbasak, there are paralled config files for multiple distros
[17:28] <rbasak> rbalint: sure, but the risk here is that users' customisations won't be preserved because they collide with previously shipped permutations
[17:28] <rbasak> So I'd like to know what the permutations you're matching actually are, but I can't do that since you're only providing the hashes.
[17:29] <rbalint> rbasak, no, the risk here is accidentally preserving things
[17:29] <rbalint> rbasak, i'll be back, in a meeting now
[17:29] <rbasak> Sure
[17:30] <rbasak> For later, I think that given there are 117, we should provide the source for those hashes since they aren't trivially "look at the previous version of the package".
[17:30] <rbasak> Maybe ship them in a directory, and compute their hashes in a build step?
[17:30] <rbasak> But apart from that, I'd still like to understand why there are so many.
[17:41] <rbalint> rbasak, the md5s are generated from the git repo and it is documented in debian/README.source
[17:42] <rbalint> rbasak, going forward there is a check in debian/rules to not forget about adding md5 for the latest version
[17:43] <rbalint> rbasak, i don't think that shipping all historical config files is a good use of resources
[17:44] <rbalint> rbasak, i think this is not an established practice for packages using ucf for a good resason
[17:47] <rbalint> rbasak, as a side note it was not me who prepared the sru, i just accepted the new md5sum and fixed it in hirsute, so i let lucasmoura to comment on the matter
[17:49] <rbasak> rbalint: is it common to ship >100 md5s? I thought the typical number would be one to three.
[20:58] <The_LoudSpeaker> Found a bug/ weirdness. On installing linux-image-generic-hwe-20.04b, touch stopped working. I mean the device was recognised but didn't take any inputs. Works fine on regular 5.4 kernel that comes with 20.04
[20:58] <The_LoudSpeaker> Have a IdeaPad flex 5 14 if it matters.
[21:00] <The_LoudSpeaker> *linux-image-oem-20.04b
[21:01] <The_LoudSpeaker> Also, what's the difference between oem-20.04-edge and 20.04b ?
[21:03] <The_LoudSpeaker> Both seem to be installing 5.10.0-1014 only.
[21:19] <ItzSwirlz> Maybe the b means beta?
[21:21] <The_LoudSpeaker> ItzSwirlz: isn't that what -edge for?
[21:21] <The_LoudSpeaker> or -edge is for something else?
[21:22] <The_LoudSpeaker> whatever be the case, should I file a bug report against 20.04b ? coz I did not change anything else and touch wasn't working.
[23:18] <ItzSwirlz> When in doubt, bug away imo. Worst thing that can happen is it gets marked invalid or a duplicate which aren't bad things.