=== JanC is now known as Guest8709
=== JanC_ is now known as JanC
[11:06] <rbasak> lvoytek: the dovecot dep8 failure for mysql-8.0 should go away after the sync - there's a new version of dovecot in the mantic release pocket with the issue fixed.
[11:07] <rbasak> But there's no point chasing it because the s390x failure will remain, and might as well wait for the Debian sync for that.
[11:07] <rbasak> I didn't see anything else held up on a failure on the older version of dovecot's dep8 test, so there's nothing else to retry.
[13:55] <lvoytek> rbasak: Thanks for letting me know! I'll get the sync mp set up today
[14:28] <nteodosio> ogra, how do you run snapcraft to get logs? 'snapcraft --verbosity=trace --debug' gives me 'No such option: --verbosity Did you mean --verbose?'
[14:29] <nteodosio> --verbosity is an option according to the help page...
[14:29] <ogra> nteodosio, heh, snapcraft behaves completely different based on your "base:" ... some need --verbose, others need --verbosity=
[14:30] <ogra> i always forget which needs which and ususally do trial and error ...
[14:31] <ogra> (and the older core and core18 bases dont need anything and just make it behave like a developer tool as expected ? )
[14:33] <nteodosio> Ah OK so it depends on the core thing... I wonder why the help section says nothing about that. Thanks for the help!
[14:39] <nteodosio> I just determined that on core22 snapcraft doesn't complain about "--verbose", but the build doesn't become verbose, so you need --verbosity; on core20, --verbosity doesn't work (as reported above), only --verbose.
[14:39] <nteodosio> This confused me to no end.
[14:45] <ogra> nteodosio, well, be happy you dont have to deal with customers relying to 100% on snapcraft ? i have to explain the odd behavior about twice a week ...
[14:46] <nteodosio> Ouch
[14:56] <ahasenack> jbicha: hey, did you mean to include this diff in your lunar sponsoring of gdm3?
[14:56] <ahasenack> -Uploaders: Jeremy Bicha <jbicha@ubuntu.com>, Marco Trevisan (Trevi?o) <marco@ubuntu.com>
[14:56] <ahasenack> +Uploaders: Jeremy Bicha <jbicha@ubuntu.com>
[15:00] <jbicha> ahasenack: Seb was the sponsor, but I encourage you to ignore the Uploaders field. It is controlled by the dh_gnome_clean script & names come & go there for unimportant reasons
[15:02] <ahasenack> cool. np
[16:55] <mdeslaur> juliank: I'm stealing your libraw merge
[17:19] <ahasenack> things that don't help an sru: patching two ubuntu releases with the same patch, but with a) different patch filename; b) different dep3 headers
[17:20] <ahasenack> why oh why
[17:22] <seb128> ahasenack, if that's gdm that's because I started doing the SRUing from email ping before noticing that the bug had patches and sponsors subscribed and I though it was not nice for the submitter to not have used those but I've enough to do that I didn't want to reject and reupload for the other series, sorry :-/
[17:32] <danilogondolfo> Hi folks, may I ask someone to review/sponsor this network-manager MR? https://code.launchpad.net/~danilogondolfo/network-manager/+git/ubuntu-1/+merge/443876
[17:32] <danilogondolfo> It's addressing 2 LP bugs related to the changes we've made during the netplan integration.
[17:37] <seb128> danilogondolfo, I can review/sponsor it, and feel free to request me as reviewer in n-m changes
[17:38] <danilogondolfo> thanks seb128!
[17:39] <seb128> np!
[17:40] <danilogondolfo> I just requested another one hehehe
[17:42] <mdeslaur> did "optional=lto" go away in symbols files in mantic?
[17:45] <ahasenack> if it did, builds will fail
[17:46] <ahasenack> no?
[17:46] <bdmurray> enr0n: Have you looked at the halted phased update of systemd for Kinetic?
[17:48] <mdeslaur> ahasenack: yeah, I'm having failing builds :)
[17:48] <ahasenack> oops
[17:48] <mdeslaur> at least, locally
[17:48] <mdeslaur> let me upload and see if it,s a local problem
[17:48] <ahasenack> where these using lto before?
[17:49] <mdeslaur> same package builds fine in lunar
[17:49] <ahasenack> maybe it was being disabled via the lto-disabled-list package? And you don't ahve it for some reason?
[17:49] <mdeslaur> uh, let me research that
[17:50] <ahasenack> it's an rdep of dpkg-dev, so unlikely, but...
[17:50] <mdeslaur> nope not in that list
[17:50] <enr0n> bdmurray: oh, yes that was lost in my mail. There is no retrace info or logs on any of the occurrences, however, so I don't think those are actionable.
[17:51] <mdeslaur> ahasenack: oh wait a sec, I think I'm actually the issue ;)
[17:52] <ahasenack> the individual on the chair?
[17:52] <mdeslaur> ahasenack: yeah, that's the idiot I'm talking about
[17:52] <ahasenack> it keeps us rubber ducks employed
[17:52] <mdeslaur> hehe :)
[17:55] <bdmurray> enr0n: ugh - if https://errors.ubuntu.com/problem/7b3d6633f7edcb113a9a8d688d970b31087ac5fe failed to retrace it shouldn't block the SRU then
[18:04] <bdmurray> enr0n: not that it matters for the SRU but https://errors.ubuntu.com/problem/6ce92393c63aca4e5c471dabfba1b9e1acd8dbc2 looks similar to https://errors.ubuntu.com/problem/d00331a0400fe4f6d7a69d80935214be783b0fe9
[18:05] <cjwatson> Launchpad's Debian importer is working again now, on its new deployment.
[18:14] <enr0n> bdmurray: yeah they do look similar
[18:16] <bdmurray> For the record - I went through all the other regression crash reports blocking phased updates and only those two systemd ones failed to retrace.
[18:19] <enr0n> Often I find that when looking at those errors for systemd, the crashes are caused by wider system failures. Maybe there were other issues that prevented proper crash data from being obtained?
=== orndorffgrant4 is now known as orndorffgrant