[00:25] <guiverc> bdmurray, lubuntu focal daily (2021-08-16) boots fine on sony_vaio_svp112a1cw; ubuntu zsync keeps falling over but i'll get there.. and I'll add entry on bug report in due course
[01:15] <mwhudson> vorlon: omg is it possibly shim-signed works on arm64 on all releases now? or do we still need it to migrate on bionic?
[08:02] <mardy> is there a way for a privileged process (such as snapd) to find the ID of all wayland windows belonging to a certain PID?
[09:34] <schopin> Regarding the freeze, what are the rules regarding the packages that are in -proposed at freeze time? Do they need a freeze exception ?
[09:42] <doko_> no
=== doko_ is now known as doko
[10:08] <slyon> schopin: This would best be asked in #ubuntu-release but from my understanding packages in -proposed are fine and can be migrated after FF (do not need a FFe), they just won't accept anything new into -proposed.
[12:30] <RikMills> mwhudson: qtwebengine fix looks good. it has been uploaded to unstable, and will get synced later
[12:30] <RikMills> sync will close the bug
[13:08] <rafaeldtinoco> sorry.. maybe this was discussed already here but what happened to ddebs.ubuntu.com/dists ?
[13:13] <rafaeldtinoco> asking this because all linux-image-XXX-dbgsym files are 15Kb
[13:14] <rafaeldtinoco> and dists directory was renamed to dists.old
[13:15] <xnox> ddstreet:  laney: forwards the token to juliank.....
[13:20] <ddstreet> thanks, laney that's all you needed right?
[13:21] <juliank> We do not have docs for which token is which or how to udpate them
[13:22] <mclemenceau_> o/ Hello, I'm looking for a sponsor for a simple merge for lshw (LP: #1939695) before feature freeze? anyone interested ? Thx :)
[13:22] <ubottu> Launchpad bug 1939695 in lshw (Ubuntu) "Please merge lshw-02.18.85-0.7 (main) from Debian unstable (main)" [Wishlist, New] https://launchpad.net/bugs/1939695
[13:23] <juliank> nvm, I was on the wrong page
[13:23] <juliank> ERROR cannot deploy bundle: processing option "swift-web-credentials" for application "autopkgtest-web": resolving include "/srv/mojo/mojo-prod-proposed-migration/focal/production/local/swift-web-credentials.conf": include file "/srv/mojo/mojo-prod-proposed-migration/focal/production
[13:23] <juliank> /local/swift-web-credentials.conf" not found
[13:23] <juliank> horry
[13:24] <ddstreet> hmm, well i've never had access to the internals of autopkgtest-cloud deployment, i'm unlikely to be able to help with that
[13:27] <juliank> sil2100: ^ you added include-file for swift-web-credentials.conf to autopkgtest-cloud, but no such secret is provided on prod-proposed-migration
[13:28] <juliank> Also how did Laney deploy this if it's not deployable
[13:34] <sil2100> juliank: we never deployed it in production so I guess! I know it has to be available on the staging instance, but I have no knowledge of how that ties to the creds for production
[13:39] <juliank> sil2100: in any case, it's broken right now, so no github systemd status thingy update
[13:41] <juliank> sil2100: I'll try to reconstruct it and hope everything works :D
[13:44] <slyon> mclemenceau_: o/ I can do that sponsoring.
[13:44] <sil2100> Ah! So I see my private-testing branch got merged! Ok, so uh, I can try reading up on how the mojo creds are being stored, possibly moving those over from the staging instance could work
[13:45] <juliank> sil2100: Copying over doens't work, no, they're separate users
[13:52] <sil2100> juliank: ah, you mean the swift user? Yeah, I wonder if we have a user for that for production, hmmm
[13:53] <juliank> I don't know what you did and how it related, certainly the password is different than what is stored in swift_password
[13:55] <sil2100> Ok, so I see Laney only requested a new swift user for staging, let me request a new user from IS for production
[14:01] <mclemenceau_> o/ slyon sure that would be great thank you!
=== genii-core is now known as genii
[14:09] <Guest11> I created a simple .deb package as per https://ubuntuforums.org/showthread.php?t=910717 .. I need to print some text as a banner while installing or removing the newly created .deb package, does DEBIAN/control supports this?
[14:10] <Guest11> Is it possible to run a set of commands after post-installation or removal of the .deb package?
[14:15] <rbasak> Guest11: try #ubuntu-packaging. This channel is for the development of Ubuntu itself.
[14:28] <laney> sil2100: ohhhh I forgot that
[14:28] <laney> I thought I saw that mojo succeeded, what did I do
[14:29] <laney> nothing good, that's for sure
[14:29] <laney> sil2100: also this is the kind of thing that would be documented ;-)
[14:30] <sil2100> laney: hah, no worries, I also forgot that we had the user only for staging, not production as well! Somehow in my mind I thought it's one for both
[14:30] <laney> juliank: just revert the charm to the previous version in the stable channel thing
[14:31] <laney> juliank: did you revise your opinion of not having docs?
[14:31] <juliank> docs are there
[14:31] <juliank> just in manage/admin thingy, not deploy, but that makes sense I guess
[14:32] <laney> nod
[14:32] <laney> interesting that xnox sent it to you and not me who replied to the thread and was CCed
[14:32] <laney> recipe for confusion there
[14:35] <sil2100> laney: filled in RT: #132557, can you check if what I copy-pasted and edited there makes sense?
[14:36] <laney> sil2100: looks good, get it prioritised
[14:37] <cjwatson> rafaeldtinoco: Both dists and (to be ignored) dists.old are present.  linux-image-*-dbgsym are probably not very interesting due to the signed/unsigned split; it looks like you typically want linux-image-unsigned-*-dbgsym
[14:37] <cjwatson> rafaeldtinoco: If that doesn't solve your problem, please be more specific
[14:38] <juliank> laney: I've blacked out on the whole charm revert thingy
[14:48] <rafaeldtinoco> cjwatson: it does indeed and thank you cjwatson. I thought signed and unsigned had diff debug packages. thx
[14:52] <laney> juliank: charm release takes a revision on the end
[14:53] <laney> juliank: the latest version is 109 so charm release cs:~ubuntu-release/autopkgtest-cloud-worker-108
[14:54] <laney> might be an idea to document that one
[15:00] <juliank> laney: gotta look at -web
[15:01] <juliank> laney: tags for 55,56,57 are missing
[15:01] <laney> I just pushed 57
[15:02] <laney> am I responsible for those others? :p
[15:02] <juliank> laney: I don't know
[15:02] <juliank> laney: neither revert helps anyway
[15:03] <laney> why, hook errors?
[15:03] <laney> let me look a second
[15:03] <juliank> laney: i'll try 54
[15:04] <laney> hang on
[15:04] <laney> look in `juju debug-log`, the blooming disk is full
[15:05] <juliank> laney: still failing at processing that option / unlucde file
[15:05] <laney> where are you seeing this?
[15:07] <laney> when running mojo?
[15:13] <laney> juliank: ok resolved with a hack, removing the unused lxd snap to free up space
[15:13] <laney> mojo was unhappy because the reverted charm doesn't have that config item
[15:13] <juliank> laney: as usual, (mojo-prod-proposed-migration)prod-proposed-migration@wendigo:~$
[15:14] <laney> probably want to reset the checkout there to correspond to 108/56 I guess
[15:14] <laney> we should add constraints to get bigger web machines, 10G is not good
[15:14] <laney> let me do that
[15:15] <laney> done
[15:15] <laney> now we need to ask IS to resize the existing instances to match that, let me do that too
[15:15] <schopin> doko: do you have any problem with me fixing the c++17-related errors in log4shib, including its public headers? You added a -std=g++14 flag but the headers cause failures in other packages :-(
[15:17] <juliank> laney: if we resize, we should also add a 2nd cpu
[15:17] <juliank> this should get rid of all spikes we have now
[15:18] <doko> schopin, well, I uploaded these other packages as well, so these should be fine now ...
[15:18] <laney> juliank: good idea, do you want to fix the constraints for that?
[15:18] <laney> see the commit I just made and the constraint syntax of juju
[15:18] <juliank> ok
[15:18]  * juliank in mth
[15:18] <juliank> * meeting
[15:19] <laney> ack
[15:19] <doko> schopin, I didn't get to libcifpp and libpdb-redo yet, so that's c++17 stuff as well
[15:20] <doko> schopin, so maybe let the current uploads migrate first before touching them again
[15:21] <schopin> doko: you did xmltooling as well?
[15:21] <laney> juliank: what I don't know is if we `mojo run` now that we changed the constraints, will it notice and decide to add new machines ...
[15:21] <laney> well I guess that's not a bad way to do it really
[15:22] <laney> could hack in there, stop download-all-results, and copy the DB over
[15:22] <laney> second option if the resize route takes a long time
[15:22] <juliank> hmm
[15:24] <doko> schopin, are you subscribed to the impish-changes ML?
[15:25] <schopin> up until now I didn't see the point of it except drowning me in mail. I guess I'll start setup some filters then ;)
[15:25] <doko> https://lists.ubuntu.com/mailman/listinfo/impish-changes
[15:31] <vorlon> mwhudson: looks like shim-signed still needs to migrate on bionic...
[15:44] <xnox> laney:  i lost track of things, sorry.
[16:07] <laney> ah well
=== alan_g__ is now known as alan_g
[19:16] <laney> juliank: ah yay, IS did the migration quickly ♥
[19:17] <laney> only one core still, sad
[21:02] <mwhudson> dbungert, vorlon: thanks for the livecd-rootfs review
[21:03] <dbungert> you bet
[21:41] <mwhudson> schopin, doko: all the autopkgtests still fail though because they are not using -std=c++14
[21:42] <mwhudson> i think patching the source would be a more useful fix
[21:50] <bdmurray> mwhudson: The apport autopkgtests are failing with the new glibc fwict due to the gdb fields changing. https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/a/apport/20210815_215748_e3421@/log.gz I've a fix for it https://paste.ubuntu.com/p/d6wPQSrdK4/ but wonder if that's best.
[22:01] <jawn-smith> Is any core dev available to retry https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=syncthing&trigger=glibc/2.34-0ubuntu1
[22:02] <jawn-smith> It's one of the packages blocking glibc, but it appears to just be a flakey test based on some older test results
[22:04] <bdmurray> jawn-smith: I can do that
[22:07] <jawn-smith> thanks bdmurray!
[22:14] <mwhudson> bdmurray: yeah, i mean that patch looks like it would help but as usual i have to ask "what is this test testing"?
[22:15] <bdmurray> mwhudson: I'm not entirely sure but _validate_gdb_fields is used in almost every test
[22:54] <mwhudson> bdmurray: yeah so i've looked at the code and i'm still not really sure what it's trying to do
[22:55] <mwhudson> bdmurray: does anything else read the Stacktrace field or is it mostly for humans to read?
[23:00] <bdmurray> mwhudson: ah, that's a good question so apport generates a StacktraceTop and StacktraceAddressSignature from the Stacktrace
[23:02] <mwhudson> bdmurray: so viewing this as an integration test, it is kinda important that we find out if gdb changes output in a way that breaks crash_signature_addresses
[23:04] <mwhudson> bdmurray: but i'm not sure anything is really testing that?
[23:04] <mwhudson> all the tests of crash_signature_addresses i'm seeing use canned input
[23:04] <mwhudson> (which makes sense for a unit test, of course)
[23:07] <bdmurray> okay, I'll keep digging
[23:07] <mwhudson> thanks
[23:07] <mwhudson> i think if we can convince ourselves the signatures are still ok in the current state of impish-proposed, your patch is fine