[08:52] <xnox> doko:  how come on ARM i cannot use any PE targets with binutils? i.e. objcopy with --target=efi-app-aarch64 fails
[08:52] <xnox> it seems like none of the PE targets are enabled for neither armel, armhf, or arm64 but it seems as if they sort of exists?
[08:52] <xnox> (efi-app being a subsystem of PE)
[09:17] <seb128> vorlon, so, it's unclear to me, what are we supposed to do with things that are blocked in propose due to a missing i386 build now?
[09:17] <seb128> vorlon, delete the i386 build from focal proper?
[09:19] <xnox> doko:  i'm rebuilding binutils with --enable-targets=arm-pe => and then objcopy seems to work
[09:19] <xnox> but not sure if that makes valid EFI PE binaries or not
[09:25] <doko> well, maybe check first =)  nobody asked for that before ...
[09:28] <seb128> doko, hey, golang-1.13 shows on component mismatch, does it requires anything from the MIR side to get promoted or does it just qualify as a new version of packages already in main? (still needs foundations team to be subscribed to the source ... who can do that? bdmurray?)
[09:29] <Laney> anyone in foundations: https://bugs.launchpad.net/~foundations-bugs/+members <- they are all admins!
[09:31] <seb128> nice :)
[09:35] <xnox> doko:  hm, it seems like whilst pe-arm target exists (and one can use efi-app-arm-little for example) the pe-aarch64 does not. But it looks like llvm-objcopy does have it
[09:40] <doko> xnox: what about eu-objcopy?
[09:47] <xnox> doko:  what is eu-objcopy?
[09:52] <doko> apt install elfutils
[09:53] <xnox> doko:  that one does not have objcopy, only objdump
[09:54] <doko> ouch
[11:56] <LocutusOfBorg> doko, isn't pycxx python2 package being reintroduced?
[11:56] <LocutusOfBorg> in Debian I mean
[11:58] <doko> LocutusOfBorg: whatever, but the Breaks relation is not sufficient in focal
[11:58] <LocutusOfBorg> doko, if we reintroduce, why a breaks would be needed at all?
[11:58] <LocutusOfBorg> the breaks is because of the removal of the old package
[11:58] <LocutusOfBorg> if we reintroduce it... meh
[11:58] <LocutusOfBorg> Replaces: python-cxx-dev (<< 7.0.3-3)
[11:58] <doko> no, the move of the header file
[11:59] <LocutusOfBorg> this is what you are talking about?
[11:59] <LocutusOfBorg> oh... ok
[11:59] <LocutusOfBorg> ok, so lets wait for Debian to reintroduce the Python2 binding and then add the breaks?
[12:02] <doko> yes
[15:08] <seb128> doko, do you know if there is a known issue with pylint in focal?
[15:08] <seb128> e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/u/ubuntu-dev-tools/20191128_062811_68c66@/log.gz
[15:08] <seb128> AttributeError: 'Import' object has no attribute 'infer_name_module'
[15:23] <seb128> rbalint, thx for looking at that valgrind/glib dbg symbols issue!
[15:30] <seb128> RikMills, hey, could you get k3b rebuild for the libdvdread new soname in focal? (hipefully that's a no change rebuild...)
[15:31] <RikMills> seb128: doing...
[15:31] <seb128> RikMills, thanks!
[15:32] <doko> seb128: I didn't check. Maybe a new upstream is needed, 2.2.2 is 12 months old
[15:33] <seb128> doko, there is 2.4.4-1 in focal-proposed, I should perhaps try with that one, thx for pointing the outdated part out :)
[16:31] <cyphermox> coreycb: you wanted code review for bug 1852772; I did so and assigned you the bug since you can upload and commit this yourself, but let me know if you'd rather I push the changes
[16:33] <coreycb> cyphermox: thanks!
[17:33] <xnox> seb128:  i don't know if blacklist is already in place inside launchpad, and I.e. if one tries to rebuild libreoffice whether or not i386 build will be triggered
[17:34] <xnox> seb128:  instead of uploading new libreoffice, i wonder if we should mark it's i386 autopkgtests as bad, to let the lot migrate. for example.
[17:37] <xnox> cjwatson:  is i386 white/black list inside launchpad for focal already or not? and is there any way to query that from the API or web-ui?
[17:37] <xnox> i.e. if I dput libreoffice, will it create build record on i386 today?
[17:40] <cjwatson> xnox: https://people.canonical.com/~ubuntu-archive/packagesets/focal/i386-whitelist is generated from LP
[18:24] <mwhudson> sil2100: looking at https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/376144 ... why are the ubiquity-hooks inside casper instead of, you know, ubiquity??
[18:24] <mwhudson> sil2100: that's not your fault, mind
[19:07] <seb128> xnox, don't reupload libreoffice please, it's going to take days again, let's wait for vorlon to be around
[20:42] <vorlon> seb128: yes to deleting i386 binaries from focal; sorry if that wasn't clear.  with my remark on #ubuntu-release before I was roughly committing myself to doing this work on a daily basis (holidays included) to keep things moving forward, but now I seem to be a bit handicapped by the fact that qa.ubuntuwire.org is down so reverse-depends is unavailable
[20:45] <vorlon> but I'm not clear what the relationship is between the whitelist and any libreoffice proposed-migration blockage, since libreoffice was built on i386 before the whitelist was in place
[21:00] <teward> vorlon: the ZNC PPA I maintain might need its packages whitelisted, theres a number of people using it and I believe using older 32bit infra too to keep up to date with latest ZNC.  I can survive without i386 builds but I dont think everyone can, what needs to be done to whitelist that from a PPA perspective to keep getting i386 builds?
[21:00] <teward> thats the only thing on my radar of this nature that might need kept.
[21:03] <vorlon> teward: why would they need a 32-bit package of znc on focal when there will be no 32-bit focal hosts?
[21:03] <vorlon> the whitelist only affects focal builds; you'll still get i386 builds on older releases
[21:04] <teward> vorlon: unless we have disabled the 32bit upgrade path ?
[21:04] <teward> if we have then ignore me
[21:04] <vorlon> we have
[21:04] <teward> ah cool wasnt aware :)
[21:04] <teward> so nevermind :)
[21:04] <teward> *returns to consuming feasts*
[21:04] <vorlon> and it's even more disabled by the fact that there's no 32-bit kernel in focal (or eoan)
[21:04] <vorlon> :)