| === 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 | ||
| 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:44 |
| Laney | it's a bit of a weird test, it's kind of verifying that all other update-motd snippets are bug free ... | 09:46 |
| 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:49 |
| ed_ | I have an interest, yes! | 09:54 |
| juliank | Laney: hmm I don't have a solution | 09:55 |
| RikMills | ed_: yes. I meant someone to help you with the issues | 09:57 |
| 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:10 |
| Laney | juliank: one of the test deps kicks it off | 10:18 |
| Laney | 'plinth', something from freedombox I think | 10:18 |
| juliank | Laney: yup it installs timers, but does not disable the service | 10:22 |
| 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:24 |
| Laney | and the integrating packages themselves test their own integration works | 10:25 |
| juliank | can it drop the freedombox bit? | 10:26 |
| Laney | that's one option | 10:26 |
| 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:27 |
| 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:28 |
| Laney | or without W, dunno | 10:29 |
| Laney | still feels kinda sketchy | 10:29 |
| 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 | 10:59 |
| 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:00 |
| 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:01 |
| Laney | plinth | 11:02 |
| Laney | 4478 | 11:02 |
| juliank | oh boy | 11:05 |
| juliank | that sounds wrong | 11:05 |
| * Laney la la la | 11:09 | |
| 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:19 |
| === sem2peie- is now known as sem2peie | ||
| 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:28 |
| 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:34 |
| rbalint | and i've just retriggered s390x which does show up on /running now | 11:35 |
| Laney | rbalint: https://paste.ubuntu.com/p/fqT2yCgJJT/ | 11:36 |
| Laney | that's what we have | 11:36 |
| Laney | oops pasted it twice but you get the idea | 11:37 |
| rbalint | Laney, ok, so i see the results are stored to swift but they don't show up on test history | 11:39 |
| rbalint | Laney, test history for amd64 is refreshed because i see the result from today | 11:40 |
| rbalint | Laney, can the parallel same test mess this up in bileto? | 11:42 |
| rbalint | sil2100,^ | 11:42 |
| 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 | 11:54 |
| === lucas_ is now known as Guest7747 | ||
| seb128 | rbalint, hey, it seems like gcl abort directly with the new glibc, is that a known issue? | 14:18 |
| 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:27 |
| rbalint | seb128, new to me, wher do you observe it? | 14:28 |
| 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:29 |
| seb128 | rbalint, I was poking at why fricas autopkgtests are failing | 14:30 |
| rbalint | seb128, yes, looks bad, do you have an LP bug? | 14:33 |
| seb128 | rbalint, not yet, do you want one? | 14:33 |
| rbalint | seb128, yes please, against gcl for now | 14:34 |
| seb128 | rbalint, https://bugs.launchpad.net/ubuntu/+source/gcl/+bug/1917631 | 14:36 |
| ubottu | Launchpad bug 1917631 in gcl (Ubuntu) "gcl abort on start in hirsute" [Undecided,New] | 14:36 |
| Laney | sil2100: hey is there any way I / you can check where the proposed-migration run is at for silo 4478? | 15:23 |
| 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:24 |
| sil2100 | Laney: looking | 15:58 |
| sil2100 | Laney: uh oh, something barfed, hm | 15:59 |
| sil2100 | Investigating | 15:59 |
| Laney | sil2100: alrighty | 16:08 |
| sil2100 | Laney: but basically, you can find all the interesting files here: | 16:09 |
| sil2100 | https://bileto.ubuntu.com/static/index.html | 16:09 |
| Laney | ooh cool secret URL thanks | 16:10 |
| * Laney saves that one | 16:10 | |
| 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 | 16:11 |
| rbasak | lucasmoura, rbalint: looking at unattended-upgrades, I was expecting one or two MD5s to be added. Why 117? | 17:22 |
| 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:23 |
| rbalint | rbasak, hashes for known config files to not ask for with ucf | 17:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| rbalint | rbasak, the md5s are generated from the git repo and it is documented in debian/README.source | 17:41 |
| rbalint | rbasak, going forward there is a check in debian/rules to not forget about adding md5 for the latest version | 17:42 |
| rbalint | rbasak, i don't think that shipping all historical config files is a good use of resources | 17:43 |
| rbalint | rbasak, i think this is not an established practice for packages using ucf for a good resason | 17:44 |
| 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:47 |
| rbasak | rbalint: is it common to ship >100 md5s? I thought the typical number would be one to three. | 17:49 |
| === ijohnson is now known as ijohnson|lunch | ||
| === lifeless_ is now known as lifeless | ||
| === ijohnson|lunch is now known as ijohnson | ||
| 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. | 20:58 |
| The_LoudSpeaker | *linux-image-oem-20.04b | 21:00 |
| The_LoudSpeaker | Also, what's the difference between oem-20.04-edge and 20.04b ? | 21:01 |
| The_LoudSpeaker | Both seem to be installing 5.10.0-1014 only. | 21:03 |
| ItzSwirlz | Maybe the b means beta? | 21:19 |
| The_LoudSpeaker | ItzSwirlz: isn't that what -edge for? | 21:21 |
| The_LoudSpeaker | or -edge is for something else? | 21:21 |
| 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. | 21:22 |
| 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. | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!