| doko | vorlon: did you only reueue the ones for focal, or everything? just seeing the ones in impish triggered for gcc-7/gcc-8 being in progress as well | 04:00 |
|---|---|---|
| RikMills | looks like just uploaded netplan.io is the latest thing to hit the missing riscv64 build problem. I guess what was said in #launchpad is the latest on this? | 08:38 |
| slyon | RikMills: Yeah. I was wondering why the riscv build is missing.. | 08:39 |
| RikMills | if you hadn't seen, for some reason the builders are not doing riscv64 builds for arch: linux-any | 08:40 |
| slyon | okay. | 08:50 |
| RikMills | excuses is seeing these as missing build, so blocking migration. so I hope we get a fix soonish :/ | 08:55 |
| -queuebot:#ubuntu-release- Unapproved: shim-signed (hirsute-proposed/main) [1.46 => 1.47] (core) (sync) | 09:11 | |
| -queuebot:#ubuntu-release- Unapproved: shim (hirsute-proposed/main) [15.4-0ubuntu1 => 15.4-0ubuntu2] (core) (sync) | 09:11 | |
| -queuebot:#ubuntu-release- Unapproved: shim-signed (groovy-proposed/main) [1.45 => 1.47] (core) (sync) | 09:11 | |
| -queuebot:#ubuntu-release- Unapproved: shim (groovy-proposed/main) [15+1552672080.a4a1fbe-0ubuntu2 => 15.4-0ubuntu2] (core) (sync) | 09:11 | |
| * enyc meows | 09:38 | |
| enyc | hrrm, hirsute stuff appearing in -release channel .... does this channel remain 21.04hirsute related for a while now...? | 09:38 |
| xnox | enyc: all releases always appear here =) | 10:16 |
| xnox | enyc: so you see mentions for SRUs fro focal bionic here too. | 10:16 |
| enyc | xnox: aaah, i see. | 10:18 |
| enyc | xnox: hrrm, new puzzle -- why did a hueeeeeeeg list of price- changes all appear all at ance earlier? | 10:18 |
| xnox | enyc: precise has had ESM for a few years now. However, that is now stopping. It looks like all the precise ESM updates are now being made public, such that they end up in the public old-releases.ubuntu.com archive as part of precise complete sunset (end of ESM). | 10:34 |
| xnox | cause those who have paid for ESM in the past, need to still be able to find sources and binaries forever. | 10:35 |
| enyc | xnox: hrrm that mkes sense! =). | 10:35 |
| xnox | which will then be archived onto tape and taken to cold offline storage too. | 10:35 |
| tseliot_ | vorlon, the i386-whitelist doesn't seem to apply to the nvidia 465 driver in this PPA (soon to be in the archive too) in Groovy and Focal (Hirsute and Bionic are covered): https://launchpad.net/~oem-solutions-group/+archive/ubuntu/nvidia-driver-staging/+packages | 12:13 |
| rbalint | doko, python3-lib2to3 in impish-proposed needs python3:any (>= 3.9.5-0~), i think a python3-defaults upload is missing | 13:43 |
| rbalint | doko, it makes systemd ftbfs | 13:43 |
| doko | ok, uploading | 13:44 |
| doko | hmm, better I soften the requirement | 13:45 |
| rbalint | yes, possibly | 13:50 |
| juliank | Laney: did you just break autopkgtest.u.c? | 14:00 |
| juliank | Laney: now it's back but it just had server error, going to read logs | 14:00 |
| juliank | still takes 16s to load the page in chrome | 14:02 |
| juliank | the / page | 14:02 |
| juliank | but my curl needs 2s, so ... | 14:03 |
| juliank | ah now it got a 10s one too | 14:03 |
| juliank | time to rewrite autopkgtest-web in Go :D | 14:04 |
| Laney | heh | 14:46 |
| Laney | don't accuse me >:( | 14:46 |
| Laney | juliank: I bet some of the sql queries could be optimised, that's what it spends it time doing really | 14:50 |
| Laney | or the db itself | 14:50 |
| juliank | sqlite was a suboptimal choice maybe | 14:50 |
| juliank | but worth profiling the queries | 14:51 |
| -queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.1.1-0ubuntu4 => 2:12.1.1-0ubuntu7] (openstack, ubuntu-server) | 15:18 | |
| -queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.1.1-0ubuntu4 => 2:12.1.1-0ubuntu4.1] (openstack, ubuntu-server) | 16:03 | |
| ddstreet | i just uploaded this neutron, who keeps uploading the increasing version numbers? | 16:04 |
| ddstreet | coreycb are you uploading neutron, specifically the ...ubuntu7 version? | 16:04 |
| ddstreet | coreycb looks like your gpg key, are you ok if i ask for deletion of the ubuntu6 and ubuntu7 uploads, so they can review my ubuntu4.1 upload? it's properly versioned and includes the correct changelog in the changes file | 16:09 |
| ddstreet | bdmurray if you're on sru shift already today, could you delete the neutron uploads in bionic with versions ...ubuntu6 and ...ubuntu7, and review the upload in bionic with version ...ubuntu4.1 | 16:09 |
| ddstreet | the ubuntu4.1 and ubuntu7 uploads have the same patch content, the only diffs are version suffix and i put dep3 info into the added patches | 16:10 |
| waveform | juliank, yes -- the (single as far as I can tell?) query on the front-page would benefit from the addition of an index on result(run_id desc) | 16:14 |
| juliank | waveform: we can play with that! | 16:15 |
| waveform | juliank, it makes a fair difference to the explain output: https://paste.ubuntu.com/p/3PCznCdnKF/ | 16:18 |
| juliank | waveform: I'll do benchmark | 16:19 |
| juliank | What I think though is that we need some output caching | 16:19 |
| juliank | I don't know if Apache has that, I use nginx on my site and configure fastcgi output caching there | 16:20 |
| waveform | I'm always rather wary of caching when I can wring a bit more out of the (poor, usually horribly abused!) database | 16:20 |
| juliank | I don't know how many requests we get, but like a 30s cache of /running and / could be useful | 16:22 |
| juliank | Huh but running just opens a json file and dumps it, why is it so slow | 16:23 |
| waveform | how big's the json? | 16:24 |
| waveform | hmm, it is using the built-in the json parser too so if it's particularly large that might be another cheap win (switching to simplejson or some such) | 16:25 |
| Laney | looking forward to merge requests ;-) | 16:26 |
| Laney | some well selected indexes would be great | 16:27 |
| waveform | Laney, switching the json import I could certainly MP but fiddling with the database structure ... I can happily suggest things but I've yet to figure out where its structure is defined (unless it's just publish-db?) | 16:28 |
| juliank | I have code! | 16:29 |
| Laney | waveform: init_db() in utils.py or publish-db depending on which table you're after (yeah ...) | 16:31 |
| Laney | sounds like juliank is saving you though | 16:31 |
| juliank | Laney: Should be it https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/402210 | 16:33 |
| juliank | Laney: eek, I pushed it to main repo | 16:33 |
| juliank | Laney: I have wrong remote set up :( | 16:34 |
| Laney | git revert! | 16:34 |
| Laney | nah it's ok, let's just try it | 16:35 |
| juliank | Laney: :) | 16:36 |
| Laney | fix that though 😬 | 16:36 |
| juliank | Laney: I have now :) | 16:36 |
| * waveform peeks through his fingers to see if his inadvertantly pushed suggestion blows up autopkgtest ... | 16:36 | |
| Laney | lol | 16:37 |
| Laney | we have staging for testing such things | 16:37 |
| Laney | usually not things directly pushed to tha main branch though :p | 16:37 |
| Laney | https://autopkgtest.staging.ubuntu.com/ I mean, not broken ... | 16:38 |
| juliank | Laney: What changes is publish-db and download-{all-,}results really :D | 16:40 |
| juliank | Laney: What do I need to do aside from pushing, build the charm locally and then deploy it from wendigo? | 16:40 |
| Laney | juliank: I did it already, but https://autopkgtest-cloud.readthedocs.io/en/latest/deploying.html#update-the-code | 16:41 |
| juliank | Laney: ah ok, I have do the charm publishing locally and then run mojo run -m manifest-upgrade on wendigo, though for future things? | 16:41 |
| Laney | pushing to the charm store is the main bit which makes the manifest able to see it | 16:41 |
| juliank | Laney: Can we auto-publish main with some git hook from launchpad? | 16:42 |
| juliank | Sounds dangerous, need to remove commit privileges and setup a merge bot :D | 16:42 |
| Laney | we could lock it and require merge proposals | 16:43 |
| Laney | I don't know how to set that latter part up though | 16:43 |
| Laney | anyway that is in production now! | 16:44 |
| juliank | Or we make it publish tags, and tag when we want to publish, and continously deploy main to staging | 16:44 |
| * Laney whispers "github actions" | 16:44 | |
| waveform | hmm, is publish-db generally a bottleneck? Just reading through it and there's quite a few changes I could suggest there too (would also depend on the version of python3 on the host though -- some stuff like using the SQLite backup API to copy stuff instead of messing with flocks would depend on it being >=3.7) | 16:45 |
| juliank | It doesn't run in the web frontend thread, but it sure eats up like 40% CPU when it runs | 16:45 |
| Laney | we're on focal there | 16:46 |
| waveform | okay - I can certainly understand why. Any idea what python version is on the host? | 16:46 |
| waveform | okay, that's good | 16:46 |
| Laney | be nice to move off sqlite completely really | 16:47 |
| juliank | Laney: Still have to create a sqlite db for publishing? | 16:47 |
| juliank | Well I guess we could go to another interchange format for britney and friends | 16:47 |
| waveform | while I'm more of a postgres type, sqlite really is pretty capable -- just need to treat it right :) | 16:48 |
| juliank | Laney: I think download-results.service needs a restart to make it create the index, which mojo didn't od | 16:48 |
| juliank | I'd run a NoSQL file based database :D | 16:48 |
| * waveform shudders | 16:48 | |
| Laney | heh | 16:48 |
| Laney | juliank: ah right, I thought browse.cgi called init_db too, do it | 16:49 |
| Laney | two autopkgtest-webs don't forget | 16:50 |
| juliank | Laney: I think what we should do is split the result downloading and publishing into its own server, and then download the db on the web workers, this would avoid the spikes every couple minutes in CPU usage that drive request times up to 17s | 16:51 |
| juliank | Laney: waveform / now returns in like 0.8s best case, nice. | 16:52 |
| Laney | could do | 16:52 |
| juliank | Laney: or we switch to dqlite :D | 16:53 |
| Laney | cheap thing to do quickly would be to apply resource limits to it, but maybe waveform's fixes will sort it all out | 16:53 |
| waveform | good to hear -- I'll run some experiments tonight. I'm reasonably confident some fairly big gains could be made in publish-db though I'm still not clear on some bits of this architecture. Is there "one true" SQLite db (which stuff writes to) that gets periodically copied by publish-db for publishing? | 16:53 |
| juliank | waveform: yes, well each web server has its own db they built independently and then copy them | 16:54 |
| Laney | yeah there's a "read only" one | 16:54 |
| Laney | it's basically building that | 16:54 |
| juliank | waveform: So the JSON is 368K large | 16:56 |
| waveform | at that size it's probably worth benchmarking the internal json vs simplejson assuming adding dependencies like that isn't a major no-no | 16:57 |
| juliank | Laney: I think what would help would be second CPUs since we run at like 60% quite a lot | 16:58 |
| juliank | Most overhead is cache-amqp really | 16:58 |
| juliank | and amqp-status-collector and publish-db | 16:59 |
| juliank | But yeah, CPU limits on background services would help too | 17:01 |
| Laney | I guess we can either move the load off or beef up the machines or optimise the code | 17:01 |
| Laney | well, any combination of thoes | 17:01 |
| Laney | right I'm off, see ya later | 17:01 |
| coreycb | ddstreet: I'm fine with my uploads getting rejected, let's just make sure the stable/queens git branch is updated | 17:02 |
| coreycb | let me know if you don't have access to push | 17:02 |
| ddstreet | coreycb so the pkg can match what's already in the ubuntu-openstack-dev git tree, we should probably ask for my upload to be rejected, but i think you also need to rebuild your upload using the -v param so that it includes the changelogs from ...ubuntu5 and ...ubuntu6, since those versions were never accepted | 17:26 |
| ddstreet | either way is fine with me | 17:26 |
| RikMills | britney runs are are not completing due to failure to fetch results. not had a successful run and update of excuses since ~11am | 17:49 |
| RikMills | juliank: is that related to what you were doing, or something else? | 17:49 |
| juliank | no! | 17:50 |
| juliank | RikMills: Well, 11am UTC? | 17:50 |
| RikMills | yep | 17:50 |
| juliank | Right no, not done anything before 15:00 | 17:50 |
| RikMills | current excuses: Generated: 2021.05.04 10:42:04 +0000 | 17:51 |
| juliank | um 14:00 :D | 17:51 |
| juliank | That's when I saw the error on autopkgtestubuntu.com | 17:51 |
| juliank | I'll leave britney stuff to Laney and sil2100, I don't have insight there | 17:51 |
| juliank | or I guess someone in the US | 17:51 |
| RikMills | runs are crashing with things like: https://paste.ubuntu.com/p/n53fXB6PvN/ | 17:51 |
| juliank | hmm works for me | 17:52 |
| juliank | That url | 17:52 |
| RikMills | https://people.canonical.com/~ubuntu-archive/proposed-migration/log/impish/2021-05-04/17:26:13.log | 17:53 |
| RikMills | It fetches result fine for a while, then boom | 17:53 |
| juliank | RikMills: ack, I see it in haproxy log | 17:53 |
| RikMills | aha. anyway, as long as someone is now aware :) | 17:54 |
| RikMills | which you highlight should have taken care of ;) | 17:56 |
| RikMills | *your | 17:56 |
| juliank | RikMills: Hmm, so this is just proxying to swift storage | 18:06 |
| juliank | RikMills: I have forwarded that to IS | 18:15 |
| RikMills | juliank: cheers! | 18:15 |
| juliank | RikMills: The error seems to be May 4 17:41:17 juju-4d1272-prod-proposed-migration-6 haproxy[3496355]: [WARNING] 123/174117 (3496355) : Server https_service/apache2-0-80 is DOWN, reason: Layer7 wrong status, code: 500, info: "Internal Server Error", check duration: 585ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. | 18:58 |
| Laney | we should back off better, but I also think the proxying should move to haproxy, there's no need for it to have to hit the backends I think | 18:58 |
| juliank | Laney: ^ | 18:58 |
| Laney | juliank: both died or what? | 18:58 |
| Laney | that's half the point of load balancing them | 18:59 |
| juliank | Laney: Yes, both die regularly on / with database error (inconsistent image or whatever) and return 500 | 18:59 |
| juliank | 10.15.102.10 - - [04/May/2021:17:41:16 +0000] "HEAD / HTTP/1.0" 500 172 "-" "-" | 18:59 |
| Laney | at the same time though | 18:59 |
| Laney | sad | 18:59 |
| juliank | Laney: I think it won't retry immediately | 19:00 |
| juliank | Laney: Shifting britney cron job back 5 minutes might fix it... | 19:00 |
| Laney | anyway, let's move it off the web nodes | 19:00 |
| Laney | britney just runs whenever it can | 19:00 |
| Laney | do you speak haproxy? | 19:00 |
| juliank | Laney: I just read some docs where they did that, but no | 19:01 |
| juliank | This is the error fwiw, sqlite3.DatabaseError: database disk image is malformed: /var/lib/juju/agents/unit-autopkgtest-web-0/charm/webcontrol/browse.cgi | 19:01 |
| juliank | Not sure why it prints the browse.cgi script as the database name | 19:02 |
| Laney | what is it, a race with publish-db? | 19:02 |
| Laney | bad bad bad | 19:02 |
| juliank | Maybe? | 19:02 |
| juliank | for haproxy, probably use_backend swift_server if { path_beg /results/ } | 19:03 |
| juliank | and setup backend | 19:03 |
| Laney | lets fiddle on staging | 19:03 |
| juliank | Laney: I didn't understand how the image can be inconsistent, but I guess now it might be a problem with the journal | 19:11 |
| juliank | no? | 19:11 |
| juliank | It shouldn't be because the journal is a write ahead one that gets merged with the db? | 19:11 |
| juliank | and we rename the new db atomically | 19:12 |
| juliank | how can that race? | 19:12 |
| Laney | I don't get it, we should see either the old or the new one as we do it atomically | 19:13 |
| Laney | https://autopkgtest.staging.ubuntu.com/results/autopkgtest-impish/impish/armhf/g/gzip/20210428_154557_d7576@/log.gz <- that is proxying @ haproxy now | 19:13 |
| Laney | now I need to translate from haproxy.cfg to the charm config | 19:13 |
| juliank | There might not be a way to atomically copy the .db while the wal is being merged | 19:13 |
| juliank | By copying the file | 19:13 |
| juliank | waveform's changes to make it use sqlite backup stuff should fix that I suppose | 19:14 |
| juliank | Laney: Or, we are supposed to open the r/w database with sqlite, acquire a shared lock using it, and _then_ we can copy the file | 19:15 |
| juliank | so instead of the top, we should do | 19:17 |
| juliank | con = sqlite3.connect(config["web"]["database"]) | 19:17 |
| juliank | bck = sqlite3.connect(target_new) | 19:17 |
| juliank | with bck: | 19:17 |
| juliank | con.backup(bck, pages=1, progress=progress) | 19:17 |
| juliank | con.close() | 19:18 |
| juliank | That should fix the race I suppose if there is one | 19:18 |
| juliank | Potentially we might want to use VACUUM INTO instead, which makes the published database smaller | 19:19 |
| juliank | but costs cycles | 19:19 |
| juliank | so con.execute("VACCUM INTO {}", target_new) | 19:20 |
| juliank | um VACUUM INTO ? | 19:20 |
| juliank | let's run a quick bench | 19:23 |
| juliank | backup API makes more sense | 19:28 |
| Laney | SURE does! | 19:30 |
| juliank | Laney: They both have the same speed on our DB, though; but since we add data afterwards anyway it makes sense to use backup API | 19:34 |
| juliank | Laney: https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/402216 | 19:41 |
| juliank | Laney: Also backup is actually 1/3-50% faster | 19:41 |
| juliank | Laney: We ought to do it incrementally with sleep I guess as https://www.sqlite.org/backup.html says such that the lock can be released in between | 19:44 |
| juliank | Ah Python sleeps automatically for us | 19:45 |
| juliank | Ah no, we need to specify a pages=5 or something | 19:46 |
| juliank | Now it does online backup | 19:49 |
| juliank | with lock releasing to not block other things from writing to it for 2s :D | 19:49 |
| juliank | Testing now on staging sort of | 20:00 |
| -queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.1.1-0ubuntu4 => 2:12.1.1-0ubuntu7] (openstack, ubuntu-server) | 20:04 | |
| coreycb | ddstreet: alright, I've uploaded a new version. thanks for catching that. | 20:05 |
| coreycb | please can someone reject all but the most recent upload of neutron (2:12.1.1-0ubuntu7) from the bionic unapproved queue? and if someone from the SRU time has cycles we'd like to see if we can get a review of that last upload. | 20:06 |
| waveform | juliank, yup -- backup API is definitely the way to do -- don't worry too much about vacuuming; there's generally very few scenarios where it's actually worthwhile (although I'm not familiar enough with autopkgtest to say it definitely isn't one of those, my general rule of thumb is that it's not :) | 20:09 |
| Laney | waveform: maybe you can review that MR if juliank stole your work? :-) | 20:09 |
| waveform | Laney, sure thing :) | 20:09 |
| waveform | oh, while I'm here could someone reject linux-firmware-raspi2 from focal-proposed -- was checking something earlier and realized I'd missed something when reviewing it last week (it shouldn't remove the Breaks line in d/control) | 20:11 |
| juliank | Laney, waveform I have run the current state of the branch successfully on staging instance fwiw | 20:11 |
| juliank | waveform: Sorry for stealing your stuff :D | 20:12 |
| waveform | juliank, no prob -- steal away :) | 20:12 |
| juliank | waveform: I'm not sure if I want to increase #pages or decrease the sleep (python defaults to 250ms) | 20:13 |
| juliank | Laney: Can I charm push this to edge channel? | 20:16 |
| juliank | Laney: I only curled the file and ran it manually :D | 20:17 |
| juliank | But I want to play with pushing to channel properly again | 20:17 |
| juliank | but there's your change in there | 20:17 |
| juliank | (I suppose) | 20:17 |
| juliank | Laney: eek, no write access to the autopkgtest-web charm anyway | 20:18 |
| Laney | one second | 20:18 |
| Laney | ah yeah you're not in ubuntu-release ;-) | 20:18 |
| Laney | let me remember how to grant that | 20:19 |
| * juliank wants to get britney running again before going to bed :D | 20:19 | |
| Laney | ok that should work | 20:20 |
| Laney | juliank: can you check out wip/haproxy-proxy too | 20:20 |
| juliank | Laney: Shall I rebase on that? | 20:20 |
| juliank | merge them locally I guess | 20:20 |
| Laney | as you wish, I don't mind merge commits really | 20:21 |
| waveform | juliank, the changes in the merge look sane but I'm probably being horribly thick in not really understanding the *three* databases involved here (not that that's a change you've made -- I get that's always the way it's been, but I'm not grokking the purpose of them all) | 20:21 |
| juliank | waveform: The r/o database has extra data on top of the r/w for consumers, so we first copy the r/w one in; then the extra data from the old r/o one | 20:22 |
| juliank | probably should open the old r/o in ?mode=ro | 20:22 |
| juliank | Laney: can't push still :( | 20:22 |
| Laney | what | 20:23 |
| juliank | Laney: | 20:23 |
| juliank | $ charm push /tmp/charm-builds/autopkgtest-web cs:~ubuntu-release/autopkgtest-web | 20:23 |
| juliank | ERROR cannot post archive: access denied for user "juliank" | 20:23 |
| * juliank sad | 20:23 | |
| Laney | let me read docs I guess | 20:24 |
| waveform | juliank, brief note on pages/sleep on the backup API -- I might be tempted to bump the pages up a bit -- with the default page-size (4KB) that'll mean it's copying 4MB then sleeping a quarter second, rinse'n'repeat. Given a typical SSD can manage quite a bit more than that I'd be tempted to bump it up to doing ~1s worth of writing before its 1/4 sec pause (which is reasonable) | 20:24 |
| juliank | Laney: Your change looks good | 20:25 |
| juliank | waveform: Right, but it only sleeps if there are writers waiting? | 20:25 |
| juliank | It certainly did not sleep for me, but I had no other connections open | 20:25 |
| waveform | juliank, good question, don't know -- I would *hope* that's the case but it's not a feature I'm terribly familiar with (one of those new things I've briefly played with and gone "cool!" but not dug into deeply yet) | 20:26 |
| juliank | waveform: I'll raise to 128k pages | 20:28 |
| Laney | laney@dev> charm grant --acl write cs:\~ubuntu-release/autopkgtest-cloud-worker juliank | 20:28 |
| Laney | laney@dev> | 20:28 |
| Laney | I don't know | 20:28 |
| Laney | wait web not cloud-worker | 20:29 |
| juliank | Laney: yeah web :D | 20:29 |
| Laney | ok did that | 20:29 |
| Laney | it returned 0 ... | 20:29 |
| juliank | waveform: Updated to 128k pages | 20:29 |
| juliank | Laney: doesn't work yet, maybe there's a delay until it takes effect | 20:31 |
| juliank | Laney: Anyhow, I manually tried the change by curling the file and running it | 20:31 |
| Laney | will have to ask the juju people I guess :( | 20:32 |
| * Laney joins #juju | 20:32 | |
| * juliank joins as well | 20:33 | |
| Laney | I merged my branch | 20:34 |
| Laney | now /results/ is not hitting the backends | 20:35 |
| Laney | hopefully that gets proposed-migration working | 20:35 |
| juliank | Laney: possibly, want to get mine in too to make sure though | 20:36 |
| juliank | :D | 20:36 |
| Laney | yeah for sure | 20:36 |
| Laney | might have to sort the ACL stuff out tomorrow | 20:36 |
| Laney | need to do duolingo and play animal crossing | 20:36 |
| juliank | I need to go to sleep soon :/ | 20:37 |
| juliank | waveform: could you write me an ACK on the merge? :D | 20:39 |
| juliank | late night infra fixing :) | 20:42 |
| waveform | sure, jsut a mo | 20:42 |
| waveform | done | 20:43 |
| juliank | Laney: please just merge, publish, and deploy that :D | 20:45 |
| juliank | charm playing on staging I can do tomorrow :D | 20:45 |
| juliank | This worked last year (two years ago?) | 20:45 |
| Laney | waveform: I looked for that pkg to reject btw and didn't see it | 20:52 |
| Laney | coreycb: I'll do yours tomorrow if someone doesn't beat me | 20:53 |
| Laney | nn! | 20:53 |
| coreycb | thanks Laney | 20:53 |
| waveform | Laney, weird -- I can see it in the queue. Anyway, it can wait -- go have fun :) | 20:54 |
| Laney | maybe I'm looking in the wrong queue | 20:54 |
| Laney | share a link and i'll do it tomrrow too | 20:54 |
| waveform | https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=&memo=30&start=30 linux-firmware-raspi2 second from the top on that page (multiverse, misc) | 20:55 |
| waveform | version 4-0ubuntu0~20.04.1 | 20:55 |
| juliank | released! | 20:56 |
| waveform | ah https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=linux-firmware-raspi2 might be more useful! (doh) | 20:56 |
| juliank | RikMills: We believe that britney should be working again now | 20:57 |
| waveform | oh, it's not in -proposed yet -- that's why you can't see it. Anyway, doubly not to worry then! | 20:57 |
| juliank | waveform: heh, publish-db with backup API now takes 2 minutes instead of 30s, but the corruption is gone, so not super unhappy | 21:06 |
| juliank | A bit odd maybe, maybe it needs a lot of retrying due to lots of writes | 21:07 |
| waveform | that could well be the case -- it was always going to be longer than a straight file-copy anyway, and add a bit extra on top for any writes getting in the way -- that's not too bad. Can probably gain a bit back with some other optimizations -- will see if I can have another look tomorrow | 21:15 |
| -queuebot:#ubuntu-release- Unapproved: pi-bluetooth (focal-proposed/multiverse) [0.1.10ubuntu6 => 0.1.15ubuntu0~20.04.1] (raspi) | 21:28 | |
| -queuebot:#ubuntu-release- New binary: pipewire [amd64] (impish-proposed/main) [0.3.26-1] (desktop-core) | 22:54 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!