[08:52] doko: how come on ARM i cannot use any PE targets with binutils? i.e. objcopy with --target=efi-app-aarch64 fails [08:52] 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] (efi-app being a subsystem of PE) [09:17] 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] vorlon, delete the i386 build from focal proper? [09:19] doko: i'm rebuilding binutils with --enable-targets=arm-pe => and then objcopy seems to work [09:19] but not sure if that makes valid EFI PE binaries or not [09:25] well, maybe check first =) nobody asked for that before ... [09:28] 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] anyone in foundations: https://bugs.launchpad.net/~foundations-bugs/+members <- they are all admins! [09:31] nice :) [09:35] 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] xnox: what about eu-objcopy? [09:47] doko: what is eu-objcopy? [09:52] apt install elfutils [09:53] doko: that one does not have objcopy, only objdump [09:54] ouch === ricab_ is now known as ricab === ricab_ is now known as ricab === ricab_ is now known as ricab [11:56] doko, isn't pycxx python2 package being reintroduced? [11:56] in Debian I mean [11:58] LocutusOfBorg: whatever, but the Breaks relation is not sufficient in focal [11:58] doko, if we reintroduce, why a breaks would be needed at all? [11:58] the breaks is because of the removal of the old package [11:58] if we reintroduce it... meh [11:58] Replaces: python-cxx-dev (<< 7.0.3-3) [11:58] no, the move of the header file [11:59] this is what you are talking about? [11:59] oh... ok [11:59] ok, so lets wait for Debian to reintroduce the Python2 binding and then add the breaks? [12:02] yes === ricab is now known as ricab|bbl [15:08] doko, do you know if there is a known issue with pylint in focal? [15:08] 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] AttributeError: 'Import' object has no attribute 'infer_name_module' [15:23] rbalint, thx for looking at that valgrind/glib dbg symbols issue! [15:30] RikMills, hey, could you get k3b rebuild for the libdvdread new soname in focal? (hipefully that's a no change rebuild...) [15:31] seb128: doing... [15:31] RikMills, thanks! [15:32] seb128: I didn't check. Maybe a new upstream is needed, 2.2.2 is 12 months old [15:33] doko, there is 2.4.4-1 in focal-proposed, I should perhaps try with that one, thx for pointing the outdated part out :) === ricab|bbl is now known as ricab [16:31] 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:31] bug 1852772 in software-properties (Ubuntu) "test_updates_interval fails on focal" [High,Triaged] https://launchpad.net/bugs/1852772 [16:33] cyphermox: thanks! [17:33] 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] 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] 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] i.e. if I dput libreoffice, will it create build record on i386 today? [17:40] xnox: https://people.canonical.com/~ubuntu-archive/packagesets/focal/i386-whitelist is generated from LP [18:24] 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] sil2100: that's not your fault, mind [19:07] xnox, don't reupload libreoffice please, it's going to take days again, let's wait for vorlon to be around [20:42] 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] 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] 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] thats the only thing on my radar of this nature that might need kept. [21:03] teward: why would they need a 32-bit package of znc on focal when there will be no 32-bit focal hosts? [21:03] the whitelist only affects focal builds; you'll still get i386 builds on older releases [21:04] vorlon: unless we have disabled the 32bit upgrade path ? [21:04] if we have then ignore me [21:04] we have [21:04] ah cool wasnt aware :) [21:04] so nevermind :) [21:04] *returns to consuming feasts* [21:04] and it's even more disabled by the fact that there's no 32-bit kernel in focal (or eoan) [21:04] :)