[01:38] <RAOF> ???
[01:40] <RAOF> What is happening here? mir-1.7.0-0ubuntu2 has a libmiral3.symbols file which includes `(c++)mir::Foo::~Foo()`. objdump -T on libmiral.so.3 from that package asserts that it does *not* contain `mir::Foo:~Foo()`.
[01:41] <RAOF> And then the build of mir-1.7.1-0ubuntu1 with no changes to `Foo` fails because `mir::Foo::~Foo()` doesn't exist in the object?
[01:41] <wxl> did we add some thing to check the iso on boot?
[01:41] <wxl> if so, where?
[01:41] <RAOF> I don't see how all three of these things can happen?!
[01:42] <wxl> also does anyone know if this new iso manifest-diff check applies to flavors? or can we make it be? is there code for this somewhere?
[01:43] <wxl> er huh i should probably ask this on release blah
[07:19] <seb128> vorlon, hey! so icu still didn't go as expected? :-(
[07:19] <vorlon> seb128: I think it's going to go in the current run
[07:20] <seb128> fingers crossed!
[07:20] <vorlon> should've gone in a previous run but there was a znc sync and it took me a while to realize that was entangled with python3.8
[08:31] <seb128> hum, is there a problem with the arm64 autopkgtest infra/capacity?
[08:32] <seb128> backlog doesn't seem to go down but we didn't upload that much in recent days?
[08:38] <seb128> vorlon, I had packages just migrating but not those blocked on icu, I guess it means it failed again? :(
[08:57] <didrocks> it go down, but not fast. My yesterday’s upload only ran this morning on arm64
[09:07] <seb128> Laney, juliank, vorlon, do we have a page that list the number of active builders for autopkgtest? something like https://launchpad.net/builders/
[09:07] <Laney> nope
[09:07] <seb128> :(
[09:07] <Laney> you can count the builds on the running page
[09:07] <seb128> the arm64 backlog doesn't seem to go down
[09:08] <seb128> let me do that
[09:08] <juliank> seb128: patches welcome!
[09:08] <juliank> :D
[09:08] <seb128> :)
[09:11] <Laney> ubuntu@juju-prod-ues-proposed-migration-machine-11:~$ journalctl --since=08:00 ADT_ARCH=arm64 | grep -c 'Acknowledging request'
[09:11] <Laney> 114
[09:11] <Laney> it is going
[10:11] <LocutusOfBorg> rafaeldtinoco, ruby-psych and jruby have a chicken and egg serious problem, and now they are uninstallable both...
[10:13] <rafaeldtinoco> LocutusOfBorg: hum, that was part of the ruby transition uploads, I'm almost home will take a look shortly
[10:26] <LocutusOfBorg> thanks
[10:40] <rafaeldtinoco> kanashiro: fyi ^
[11:02] <rafaeldtinoco> looks like for this build loop I'll have to drop ruby-psych from build-depends of jruby, and after building ruby-psych do another build of jruby supporting it
[11:03] <rafaeldtinoco> and open a bug in debian to check what they can come up with as ruby-psych has been alternating between suggest and dependency since 2017
[11:03] <rafaeldtinoco> kanashiro: ^
[11:07] <seb128> icu migrated \o/
[11:07] <seb128> vorlon, well done :-)
[11:14] <kanashiro> rafaeldtinoco, let me know if your plan work as you planned
[11:14] <rafaeldtinoco> kanashiro: yep, will give it a try locally now
[11:19] <rafaeldtinoco> kanashiro: your transitions page look much better today
[11:19] <rafaeldtinoco> just a few packages missing from the 1st wave
[11:20] <kanashiro> rafaeldtinoco, yes, and I am checking it and some of the packages in red already built fine, it might be a matter of waiting to update it
[11:29] <rbasak> ahasenack: pam_mysql is a sync I believe. Could you please review before I sync it?
[11:29] <rbasak> (pam-mysql)
[11:45] <rbasak> libdbi-drivers is in main. So why doesn't https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/rdepends/libdbi-drivers/ exist?
[12:41] <seb128> vorlon, your tepl upload to pick i386 is depwaiting on amtk to be also added
[12:43] <Laney> wish I could update that i386 seed myself
=== wgrant is now known as wgrant_
=== wgrant_ is now known as wgrant
[13:40] <rbasak> Ah - apparently we unseeded libdbi-drivers this cycle
[15:04] <ahasenack> how can I get access to focal on armhf to troubleshoot http://autopkgtest.ubuntu.com/packages/c/cacti/focal/armhf ?
[15:04] <ahasenack> should I use a bileto ticket and do "interactive" debugging with it, one print() per upload?
[15:16] <Laney> ahasenack: get an arm64 VM and use lxd to launch armhf inside that
[15:54] <ddstreet> juliank hi, i'm assuming you probably won't have time to review this MR until after focal? https://code.launchpad.net/~ubuntu-support-team/software-properties/+git/software-properties/+merge/379928
[15:55] <ddstreet> i can split it up or adjust or whatever, but need to know what you'd like to see done, otherwise i'll just keep developing and it will grow larger :)
[16:00] <juliank> ddstreet: that's hard
[16:00] <ddstreet> you mean it's hard to review at all?
[16:01] <juliank> i don't know
[16:01] <ddstreet> oh
[16:01] <ddstreet> well i'll be at the sprint next week if you want to talk
[16:01] <juliank> I think I reviewed in the wrong order
[16:02] <juliank> I was looking at the commit that removes PPA stuff before the commit that rewrites it
[16:02] <juliank> ddstreet: Do you know if anything is using the library that could break by this change?
[16:03] <cjwatson> ddstreet: https://code.launchpad.net/~ddstreet/launchpadlib/nosudo/+merge/379694 is on my queue but I'd find it helpful if you didn't add extra review requests please :)
[16:04] <ddstreet> cjwatson ack, i wasn't sure if you were on the list
[16:04] <juliank> ddstreet: I don't want it to get even larger :D
[16:04]  * cjwatson deletes that request - I'm already in ~lazr-developers
[16:04] <juliank> but I also don't really have time or nerve to review this yet
[16:04] <ddstreet> juliank i dont think anything is using the changed code, but i'll check all the reverse-depends
[16:05] <juliank> worst case, I guess we can sit down for 30 mins next week and go over the commits
[16:06] <ddstreet> sounds good, thnx
=== jdstrand_ is now known as jdstrand
[16:23] <ahasenack> Laney: thanks, that worked!
[16:24]  * Laney does a celebratory moonwalk
=== alan_g is now known as alan_g_
=== alan_g_ is now known as alan_g
[20:15] <vorlon> seb128: thanks for the hint re: amtk, sorted that now also
[20:15] <seb128> vorlon, thanks for sorting it out, days are a bit crazy with ff this week but I will take time to learn to do that myself next time I get one
=== hggdh is now known as hggdh-msft
[22:33] <seb128> vorlon, what issue was your libxml2 recent patch fixing? There is no bug reference in the changelog/patch and Debian has applied what look like a subset of your change in https://packages.qa.debian.org/libx/libxml2/news/20200227T184953Z.html and I would like to check if that's enough to fix the issue you were having
[22:34] <seb128> vorlon, in which case we could sync back, which would be nice because Debian also backported some extra CVE fixes
[22:34] <vorlon> seb128: I actually opened a PR upstream for my change, and upstream pointed out it was fixed differently on trunk.  so a newer upstream is probably fine
[22:35] <vorlon> the issue was a testsuite failure in libxml-libxslt-perl on armhf
[22:35] <vorlon> because it was constructing trees of nodes that were unexpected by libxml2
[22:35] <seb128> vorlon, ok, Debian took the fix from upstream so I guess it should be fine to sync, thanks
[22:36] <seb128> vorlon, right, https://salsa.debian.org/xml-sgml-team/libxml2/-/commit/f91d1425 sounds like a variant for the same fix
[22:36] <seb128> thanks for confirming!
[22:36] <vorlon> and I spoke w/ mapreri this morning on #debian-devel
[22:36] <vorlon> so yeah we should be good
[22:37] <vorlon> if it gets hung up again on the autopkgtest, we'll know soon enough
[22:37] <seb128> right