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