[00:40] -queuebot:#ubuntu-release- New binary: fenics-ffcx [amd64] (jammy-proposed/universe) [1:0.3.0-3] (no packageset)
[08:40] <bdmurray> mwhudson: can you get the smooth_updates conversation restarted?
[09:00] -queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (focal-proposed/universe) [1.16.2-2.1ubuntu1 => 1.16.3-0ubuntu1] (i386-whitelist, kubuntu)
[09:03] -queuebot:#ubuntu-release- Unapproved: simplestreams (bionic-backports/main) [0.1.0~bzr460-0ubuntu1.1 => 0.1.0-48-gb936edd4-0ubuntu1~bpo18.04.1] (ubuntu-cloud, ubuntu-server)
[09:59] -queuebot:#ubuntu-release- New: accepted fenics-ffcx [amd64] (jammy-proposed) [1:0.3.0-3]
[11:00] <rbasak> sil2100: have you seen this failing oem-meta-packageset-sync cronjob on snakefruit spamming devel-permissions@?
[11:00] <rbasak> sil2100: could you disable it for now please?
[11:21] <bdmurray> rbasak: I'll let him know when I see him
[11:26] <holmanb> not sure if there is time in SRU vanguard today or not. cloud-init has a queued for -proposed (22.1-14-g2e17a0d6) that we'd like to request review for upload  into (bionic|focal|impish)-proposed  per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1961446
[11:26] <ubottu> Launchpad bug 1961446 in cloud-init (Ubuntu Impish) "sru cloud-init (22.1 update) Bionic, Focal, Impish" [Undecided, In Progress]
[11:26] <holmanb> Please also reject the prior unaccepted cloud-init 22.1-1 uploads that are queued for bionic, focal and impish.
[11:29] <bdmurray> holmanb: Is it a priority to get it done this week? A couple of SRU team members are at a sprint.
[11:31] <bdmurray> holmanb: If it is a priority you might try pinging RA_OF
[11:38] <holmanb> bdmurray: it will push back the start of our aging to Monday if it doesn't go in today. It wouldn't be the worst thing, but sooner is better.
[11:50] -queuebot:#ubuntu-release- New binary: fenics-dolfinx [ppc64el] (jammy-proposed/universe) [1:0.3.0-13] (no packageset)
[12:11] <laney> rbasak: can you fix the owner of https://people.canonical.com/~ubuntu-archive/packagesets/jammy/canonical-oem-metapackages to be ~ubuntu-archive? I wonder why it got created with a different owner - does the initialisation process need to be fixed?
[12:12] <laney> ah, I see you already noticed the spam
[12:39] -queuebot:#ubuntu-release- New binary: fenics-dolfinx [s390x] (jammy-proposed/universe) [1:0.3.0-13] (no packageset)
[12:51] <sil2100> rbasak: hey! You were pinging about the oem-meta-packageset-sync, right?
[12:51] <rbasak> o/
[12:52] <rbasak> Yes, but laney suggests what's wrong above. I'm just looking into fixing that now.
[12:52] <sil2100> I'll take a look, I think the creds might have expired. Will check up soon
[12:52] -queuebot:#ubuntu-release- New binary: fenics-dolfinx [armhf] (jammy-proposed/universe) [1:0.3.0-13] (no packageset)
[12:52] <sil2100> Oh, ok o/
[12:52] <sil2100> No backlog here!
[12:55] <sil2100> If you need any help or anything, just give me a poke. I'll get back to sprinting madness then
[12:55] <rbasak> Thanks
[12:55] <rbasak> OK owner changed to ~ubuntu-archive
[12:56] <rbasak> Thanks laney!
[12:56] <rbasak> Let's see if that fixes it.
[12:58] <rbasak> FTR:
[12:58] <rbasak> pkgset = lp.packagesets.getByName(name='canonical-oem-metapackages', distroseries=lp.distributions['ubuntu'].getSeries(name_or_version='jammy'))
[12:58] <rbasak> pkgset.owner = lp.people['ubuntu-archive']
[12:58] <rbasak> pkgset.lp_save()
[12:59] <laney> merci rbasak
[12:59] <laney> you should find out in 45 seconds I guess :-)
[12:59] <rbasak> Ah just in time :)
[13:00] <laney> Worked 👍
[13:01] <rbasak> \o/
[13:01] <laney> how come that all only just happened?
[13:01] <laney> I'd have expected the packageset to have existed all along
[13:01] <rbasak> Thanks laney. I couldn't determine the problem from the backtrace
[13:02] <laney> no worries, the 401 unauthorized gave it away to me
[13:02] <laney> probably an 'if you know, you know' thing
[13:04] -queuebot:#ubuntu-release- New binary: fenics-dolfinx [arm64] (jammy-proposed/universe) [1:0.3.0-13] (no packageset)
[13:08] <rbasak> Looks like the jammy packageset was created on 2021-10-15
[13:09] <rbasak> But since then the emails suggest that the script never tried to add any entries to the jammy packageset
[13:09] <rbasak> So this is the first time it got triggered to actually use the packageset perhaps?
[13:11] <laney> it must be that this function wasn't returning jammy up until now https://git.launchpad.net/~developer-membership-board/+git/oem-meta-packageset-sync/tree/oem-meta-packageset-sync#n77
[13:11] <laney> perhaps snakefruit only just got an update to distro-info-data
[13:13] <RikMills> kubuntu daily ISO build is not getting copied to cdimage
[13:13] <rbasak> Just updating the DMB docs on this.
[13:14] <rbasak> The archive admin team runs/manages the script, right? Not the release team?
[13:15] <laney> yes, but the DMB owns it in that they're supposed to gatekeep all code changes - that's why it is under that team on LP
[13:17] <rbasak> Thanks. I updated https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Canonical_OEM_metapackage_packageset - I noticed that while the packageset was documented the automation was not.
[13:17] <rbasak> I've glossed over packageset/per-series packagesets
[13:17] <laney> looks great
[13:21] -queuebot:#ubuntu-release- Packageset: 97 entries have been added or removed
[13:48] <doko> Eickmeyer: you uploaded onetbb, do you continue with the transition?
[13:50] -queuebot:#ubuntu-release- New: accepted fenics-dolfinx [arm64] (jammy-proposed) [1:0.3.0-13]
[13:50] -queuebot:#ubuntu-release- New: accepted fenics-dolfinx [ppc64el] (jammy-proposed) [1:0.3.0-13]
[13:50] -queuebot:#ubuntu-release- New: accepted fenics-dolfinx [armhf] (jammy-proposed) [1:0.3.0-13]
[13:50] -queuebot:#ubuntu-release- New: accepted fenics-dolfinx [s390x] (jammy-proposed) [1:0.3.0-13]
[14:01] <sil2100> rbasak, laney: thanks!
[15:49] <Eickmeyer> doko: I'm not sure. It seems to me that the old tbb needs to be removed first (I did file a bug report about that), but the new onetbb seems to introduce some regressions according to britney. I was going to leave it up to ubuntu-archive.
[16:48] <ginggs> Eickmeyer: these packages need rebuilding before the old tbb can be removed
[16:48] <ginggs> https://people.canonical.com/~ubuntu-archive/transitions/html/onetbb.html
[16:49] <Eickmeyer> ginggs: I see. I also see that some of them are incompatible with a newer libtbb?
[16:50] <ginggs> but at least half of those in level 2 will FTBFS
[16:50] <ginggs> so I think we should revert onetbb for now
[16:50] <ginggs> doko: ^
[16:50] <Eickmeyer> ginggs: If that's the case, we lose numba, which will cause all sorts of issues.
[16:51] <ginggs> Eickmeyer: we already removed numba, what kind of issues will removing it again cause?
[16:51] <Eickmeyer> ginggs: I uploaded a newer version, and part of the reason python3-defaults wouldn't migrate was the lack of numba, and a bunch of packages depended on it.
[16:51] <doko> Eickmeyer: then repackage tbb to have non-conflicting packages?
[16:52] <ginggs> Eickmeyer: numba was not a reason why python3-defaults would not migrate
[16:52] <doko> no, migration of python3-defaults was independent of that
[16:52] <Eickmeyer> OK, let's remove numba and revert tbb.
[16:52] <Eickmeyer> This is what I get for trying to help.
[16:53] <doko> help is appreciated if it's complete =)
[16:53] <Eickmeyer> Well, I had no idea this was going to happen.
[19:49] <mwhudson> bdmurray: ack
[20:26] <LocutusOfBorg> ubuntu-archive: can we please kick myspell out from jammy? removed in sid, bug: #1006134
[20:26] <ubottu> Bug 1006134 in Stellarium "Ocular plugin: minor issue when adding a telescope" [Low, Fix Released] https://launchpad.net/bugs/1006134
[20:27] <LocutusOfBorg> ifrench-gut mighe
[20:27] <LocutusOfBorg> *might need to migrate first, others are false positives
[20:54] <jochensp> Hi, could someone help with getting the latest open3d into jammy? Maybe by simply dropping the old ppc64el build?
[21:11] <RikMills> jochensp: looks like a LTO related build error, and when trying the proposed amd64 build in a VM it segfaults on launch
[21:12] <jochensp> RikMills: interestingly it build in Debian, will try to run it
[21:12] <RikMills> jochensp: debian does not build with LTO enabled by default yet
[21:14] <jochensp> but open3d is build with -flto in Debian: https://buildd.debian.org/status/fetch.php?pkg=open3d&arch=amd64&ver=0.14.1%2Bdfsg-7&stamp=1645372419&raw=0
[21:16] <jochensp> (though I guess the incompatible compiler options are from Ubuntu: ‘-mrelocatable’ and ‘-mcall-linux’ are incompatible)
[21:27] <jochensp> small correction: only the Python plugin is build with -flto and Ubuntu building everything with it is probably the reason for the segfault
[21:27] <jochensp> would you still accept a patch to disable LTO for Ubuntu?
[21:35] <mwhudson> jochensp: we've certainly disabled lto on other packages for this sort of reason
[21:36] <jochensp> I guess DEB_CFLAGS_MAINT_APPEND=-fno-lto should do it, should we push that through Debian or do you want to do a +ubuntu1 version? (I would really like to have the new version in jammy)
[21:37] <mwhudson> jochensp: there is the lto-disabled-list package too
[21:37] <mwhudson> i assume open3d is in universe
[21:38] <sarnold> hopefully helpful https://wiki.ubuntu.com/ToolChain/LTO
[21:38] <jochensp> universe, yes
[21:43] <jochensp> can I do something to have it fixed in jammy?
[21:46] <mwhudson> jochensp: file a bug in launchpad?
[21:46] <jochensp> against which package?
[21:47] <mwhudson> jochensp: open3d pls
[21:47] <mwhudson> i can do the archive bits, they're trivial enough
[21:50] <jochensp> mwhudson: https://bugs.launchpad.net/ubuntu/+source/open3d/+bug/1963556 (thanks :) )
[21:50] <ubottu> Launchpad bug 1963556 in open3d (Ubuntu) "Open3D segfaults when compiled with LTO" [Undecided, New]
[21:51] <mwhudson> til https://en.cppreference.com/w/cpp/language/siof
[21:55] <mwhudson> jochensp: uhhh open3d is already in here
[21:56] <mwhudson> and has been since march 2021
[21:56] <jochensp> but I see a lot of -flto here: https://launchpadlibrarian.net/587715572/buildlog_ubuntu-jammy-amd64.open3d_0.14.1+dfsg-7build1_BUILDING.txt.gz
[21:57] <mwhudson> where is this coming from then
[21:57] <jochensp> I don't see them in the Debian build
[21:58] <mwhudson> time to do some debugging i guess
[22:00] <mwhudson> why does open3d have its own copy of dpkg-buildflags??
[22:00] <mwhudson> ah wait no
[22:05] <mwhudson> jochensp: the lto build flags are not the ones ubuntu uses though hm,m
[22:07] <mwhudson> this is going to be cmake somehow isn't it
[22:09] <mwhudson> ah, pybind
[22:09] <jochensp> pybind uses LTO in Debian as well, but not the rest
[22:10] <mwhudson> jochensp: all the hits for flto in https://launchpadlibrarian.net/587715572/buildlog_ubuntu-jammy-amd64.open3d_0.14.1+dfsg-7build1_BUILDING.txt.gz are for python bits afaics
[22:12] <jochensp> seems like, yeah
[22:13] <mwhudson> in particular the link of libOpen3D.so.0.14.1 doesn't use anything exotic, so maybe this isn't https://github.com/isl-org/Open3D/issues/4747 after all
[22:13] <ubottu> Issue 4747 in isl-org/Open3D "Link Time Optimization (-flto) triggers static initialization bug in Open3D" [Open]
[22:16] <jochensp> maybe.. do you have an idea where ‘-mrelocatable’ and ‘-mcall-linux’ are incompatible is coming from in the ppc64el build? (maybe that gives us a hint)
[22:17] <jochensp> here: https://launchpadlibrarian.net/588854642/buildlog_ubuntu-jammy-ppc64el.open3d_0.14.1+dfsg-7build1_BUILDING.txt.gz
[22:26] <mwhudson> jochensp: no
[22:26] <mwhudson> but i can try a ppc64el build and see what i can find i guess
[22:27] <mwhudson> -Bsymbolic-functions is always a good bet for "things go wrong in strange ways"
[22:29] <mwhudson> what is *this* person doing https://stackoverflow.com/questions/50746045/how-to-disable-mcall-linux-in-gcc
[22:30] <mwhudson> "It is not a full OS. We do not use RAM. All the executables are loaded in the processor cache."
[22:30] <sarnold> mwhudson: *wild*
[22:33] <jochensp> the unstable open3d packages work in jammy so seems to be something in the Ubuntu build
[23:19] <mwhudson> jochensp: what is the default gcc / g++ in debian currently?
[23:19] <mwhudson> but that's interesting, means it's not glibc 2.35 i guess
[23:19] <jochensp> 11.2.0-18
[23:20] <jochensp> and libc6 is 2.33-7
[23:20] <mwhudson> Ubuntu 11.2.0-16ubuntu1
[23:20] <mwhudson> close enough, you'd have thought