[00:20] <teward> vorlon: regarding lubuntu oversize, we know its oversize right now, 3.2 should be fine for now.  (lubuntu team lead hat on) - Simon is ill
[00:20] <teward> so he isnt around to ack or nack at the moment
[00:20] <teward> so i'll do it for him.
[00:36] <vorlon> teward: ok thanks (and wishing tsimonq2 a speedy recovery)
[05:19] <vorlon> xnox: ok, on second look I see that glmark2-es2 is now provided by glmark2-es2-x11, so this can safely be removed (noticed that glmark2-es2 was uninstallable but mir-test-tools was not)
[06:34] -queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (mantic-proposed/universe) [3.0.3 => 3.0.4] (ubuntukylin)
[07:28] -queuebot:#ubuntu-release- Unapproved: metacity (mantic-proposed/universe) [1:3.49.1-1 => 1:3.50.0-1] (ubuntu-desktop) (sync)
[08:15] -queuebot:#ubuntu-release- Unapproved: accepted edubuntu-menu [source] (mantic-proposed) [23.10.13]
[08:15] -queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-menu [source] (mantic-proposed) [0.83]
[08:15] -queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (mantic-proposed) [3.0.4]
[08:45] <schopin> release team: now that the beta is out, I'd like to do a new glibc upload (there are a couple of CVE fixes in there). I realize it's really late in the calendar, though :/
[09:16] <seb128> schopin, technically you don't need an ack for it if it's bugfix only
[09:17] <seb128> still nice to let the release team know though
[09:18] <schopin> I know, and if I don't have feedback by tomorrow morning I'll just go ahead.
[09:20] <seb128> good luck trying to get feedback here
[09:21] <seb128> speaking of which, since my nagging on Friday about https://launchpad.net/bugs/2036981 didn't work I'm trying again
[09:21] -ubottu:#ubuntu-release- Launchpad bug 2036981 in gnome-initial-setup (Ubuntu) "UIFe: update for the new snap store naming and icon" [Undecided, In Progress]
[09:21] <seb128> could someone review ^
[09:37] -queuebot:#ubuntu-release- Unapproved: s390-tools (mantic-proposed/main) [2.29.0-0ubuntu1 => 2.29.0-0ubuntu2] (core)
[09:38] -queuebot:#ubuntu-release- Unapproved: s390-tools-signed (mantic-proposed/main) [2.29.0-0ubuntu1 => 2.29.0-0ubuntu2] (core)
[10:14] <fossfreedom_> Hi release team - re this bug - https://bugs.launchpad.net/subiquity/+bug/2036966 ogayot is recommending the UB mantic daily ISO be built with multiverse enabled.  Can someone in the team help with this please?
[10:14] -ubottu:#ubuntu-release- Launchpad bug 2036966 in subiquity "Budgie Installer fails with internet enabled / additional media support selected" [Undecided, New]
[10:19] <LocutusOfBorg> hello, ping to check virtualbox SRU
[10:19] <LocutusOfBorg> https://lists.ubuntu.com/archives/ubuntu-release/2023-September/005787.html
[10:44] -queuebot:#ubuntu-release- New sync: rust-bindgen-cli (mantic-proposed/primary) [0.66.1-3]
[11:23] <tjaalton> new mesa needs this ^
[11:53] -queuebot:#ubuntu-release- Unapproved: horizon-eda (mantic-proposed/universe) [2.4.0-1build1 => 2.4.0-1.1] (no packageset) (sync)
[11:54] -queuebot:#ubuntu-release- Unapproved: accepted horizon-eda [sync] (mantic-proposed) [2.4.0-1.1]
[11:59] -queuebot:#ubuntu-release- Unapproved: nux (mantic-proposed/universe) [4.0.8+18.10.20180623-0ubuntu4 => 4.0.8+18.10.20180623-0ubuntu5] (no packageset)
[12:00] -queuebot:#ubuntu-release- Unapproved: trophy (mantic-proposed/universe) [2.0.3-2build1 => 2.0.4-1] (no packageset) (sync)
[12:01] -queuebot:#ubuntu-release- Unapproved: accepted trophy [sync] (mantic-proposed) [2.0.4-1]
[12:06] -queuebot:#ubuntu-release- Unapproved: mate-session-manager (mantic-proposed/universe) [1.26.1-1 => 1.26.1-2] (ubuntu-mate) (sync)
[12:07] -queuebot:#ubuntu-release- Unapproved: mate-system-monitor (mantic-proposed/universe) [1.26.0-2 => 1.26.0-5] (ubuntu-mate, ubuntukylin) (sync)
[12:07] -queuebot:#ubuntu-release- Unapproved: mate-utils (mantic-proposed/universe) [1.26.0-0ubuntu1 => 1.26.1-1] (ubuntu-mate, ubuntukylin) (sync)
[12:08] -queuebot:#ubuntu-release- Unapproved: mate-user-guide (mantic-proposed/universe) [1.26.1-1 => 1.26.2-1] (ubuntu-budgie, ubuntu-mate, ubuntukylin) (sync)
[12:10] -queuebot:#ubuntu-release- Unapproved: rust-bindgen (mantic-proposed/universe) [0.60.1-3ubuntu1 => 0.66.1-3] (i386-excludes) (sync)
[12:11] -queuebot:#ubuntu-release- Unapproved: insighttoolkit5 (mantic-proposed/universe) [5.3.0-5 => 5.3.0-6] (no packageset) (sync)
[12:12] -queuebot:#ubuntu-release- Unapproved: accepted insighttoolkit5 [sync] (mantic-proposed) [5.3.0-6]
[12:26] -queuebot:#ubuntu-release- Unapproved: cairo (mantic-proposed/main) [1.17.8-2 => 1.18.0-1] (core, i386-whitelist) (sync)
[12:30] <jbicha> more detail on cairo 1.18 at bug 2037186
[12:30] -ubottu:#ubuntu-release- Bug 2037186 in cairo (Ubuntu) "Update cairo to 1.18.0" [Undecided, Confirmed] https://launchpad.net/bugs/2037186
[12:58] -queuebot:#ubuntu-release- Unapproved: accepted nux [source] (mantic-proposed) [4.0.8+18.10.20180623-0ubuntu5]
[13:26] -queuebot:#ubuntu-release- Unapproved: libei (mantic-proposed/main) [1.0.901-2 => 1.1.0-1] (no packageset) (sync)
[13:27] <jbicha> another pre-release to stable: https://gitlab.freedesktop.org/libinput/libei/-/compare/1.0.901...1.1.0
[14:06] -queuebot:#ubuntu-release- Unapproved: grub2 (mantic-proposed/main) [2.12~rc1-4ubuntu3 => 2.12~rc1-10ubuntu1] (core)
[14:06] <juliank> ^ sorry for the merge but we're doing debian-first grub development - this has been aging in debian for a week now but I didn't get around to uploading it before the beta
[14:07] <juliank> there will be unsigned and signed bits at a later point
[14:08] <juliank> I had planned to pick some more fixes but with the review not fully done, and the timing the way it is now I think it's worth just doing this now vs waiting another week and get more regression potential
[14:08] <juliank> there's a few minor issues we have fixes for that won't make it in that way, but they don't seem to have any practical effect
[14:29] -queuebot:#ubuntu-release- Unapproved: libcupsfilters (mantic-proposed/main) [2.0~rc1-0ubuntu4 => 2.0.0-0ubuntu1] (no packageset)
[14:43] <tsimonq2> vorlon: Thanks :) retroactive ack on what teward said.
[14:43] <tsimonq2> (I'm really curious to see how much of that is snaps vs debs...)
[14:48] -queuebot:#ubuntu-release- Unapproved: ruby3.1 (mantic-proposed/main) [3.1.2-7ubuntu2 => 3.1.2-7ubuntu3] (i386-whitelist)
[14:48] -queuebot:#ubuntu-release- Unapproved: accepted ruby3.1 [source] (mantic-proposed) [3.1.2-7ubuntu3]
[15:03] -queuebot:#ubuntu-release- Unapproved: ben (mantic-proposed/universe) [0.10.2ubuntu2 => 0.10.3ubuntu1] (no packageset)
[15:03] -queuebot:#ubuntu-release- Unapproved: libzstd (mantic-proposed/main) [1.5.5+dfsg2-1ubuntu2 => 1.5.5+dfsg2-2] (core, i386-whitelist) (sync)
[15:05] -queuebot:#ubuntu-release- Unapproved: accepted ben [source] (mantic-proposed) [0.10.3ubuntu1]
[15:13] <vorlon> seb128: LP: #2036981> no one ever subscribed the release team to this for review, only 'ubuntu-release-kpi-admins'
[15:13] -ubottu:#ubuntu-release- Launchpad bug 2036981 in gnome-initial-setup (Ubuntu) "UIFe: update for the new snap store naming and icon" [Undecided, In Progress] https://launchpad.net/bugs/2036981
[15:13] <vorlon> +collector
[15:15] <seb128> vorlon, ups, launchpad autosuggestion fail I guess
[15:16] -queuebot:#ubuntu-release- Unapproved: adsys (mantic-proposed/main) [0.13.0build1 => 0.13.1] (no packageset)
[15:21] -queuebot:#ubuntu-release- Unapproved: libxs-parse-sublike-perl (mantic-proposed/main) [0.18-1ubuntu1 => 0.20-1] (no packageset) (sync)
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted libxs-parse-sublike-perl [sync] (mantic-proposed) [0.20-1]
[15:22] -queuebot:#ubuntu-release- Unapproved: update-manager (mantic-proposed/main) [1:23.10.1 => 1:23.10.2] (core)
[15:29] <juliank> I'll reupload grub2 2.12~rc1-10ubuntu2
[15:29] <juliank> well I'll upload another one with that version
[15:29] <juliank> I burned the ubuntu1 for grub2-unsigned
[15:29] <juliank> I did not have -v in the .changes :(
[15:35] -queuebot:#ubuntu-release- Unapproved: grub2 (mantic-proposed/main) [2.12~rc1-4ubuntu3 => 2.12~rc1-10ubuntu2] (core)
[15:38] <juliank> vorlon: ^ 🥺
[15:38] <vorlon> juliank: I'll review but you're looking at a couple of hours this morning before I can get to it
[15:40] <juliank> vorlon: I'd also take apw he's signing that soon anyhow :)
[15:40] <dbungert> release team: is it possible that the cdimage frontend servers are out of sync?  I'm getting 404s which disappear if I retry a few times.
[15:44] <juliank> Note that we will obviously go and SRU the final 2.12 to mantic after the release, sadly it has not been released so far :(
[15:56] <dbungert> fossfreedom_: I think https://code.launchpad.net/~dbungert/livecd-rootfs/+git/livecd-rootfs/+merge/452012 should do it
[15:59] -queuebot:#ubuntu-release- Unapproved: mesa (mantic-proposed/main) [23.1.7-1ubuntu1 => 23.2.0~rc4-1ubuntu1] (core, i386-whitelist, xorg)
[16:03] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-tiling-assistant (mantic-proposed/main) [41-1+gnome45.2ubuntu1 => 44-1ubuntu1] (ubuntu-desktop)
[16:05] -queuebot:#ubuntu-release- Unapproved: libppd (mantic-proposed/main) [2:2.0~rc1-0ubuntu4 => 2:2.0.0-0ubuntu1] (no packageset)
[16:38] -queuebot:#ubuntu-release- Unapproved: cups-filters (mantic-proposed/main) [2.0~rc1-0ubuntu2 => 2.0.0-0ubuntu1] (desktop-core, ubuntu-server)
[16:38] <fossfreedom_> dbungert really appreciate this! Does this cover the multiverse observation ... i just saw the universe being mentioned?
[16:41] -queuebot:#ubuntu-release- Unapproved: gnome-applets (mantic-proposed/universe) [3.46.0-3build1 => 3.50.0-1] (desktop-extra) (sync)
[16:43] <dbungert> fossfreedom_: it should.  changelog clarified.  The intention is to trigger configure_universe to run, which should also cover multiverse.  https://git.launchpad.net/livecd-rootfs/tree/live-build/functions?h=23.10.44#n845
[16:48] <xnox> doko: "xnox stopgap without follow-up" there is. we still have kernels in mantic-release that require gcc-12, specifically riscv ones. and i cannot do `gcc-12 [riscv64]` because dpkg format doesn't allow this for _all.deb packages.
[16:48] <xnox> so it still cannot be dropped.
[16:49] <xnox> vorlon: yeah my understanding was it was safe. if it isn't, i can add any transitionals you ask me to. but it looked like it was fine as is.
[16:49] <xnox> a revdep
[16:49] <xnox> didn't check that
[16:49] <vorlon> xnox: yes, it's resolved now, was just difficult to see it was clean by looking at the NBS report
[16:50] <xnox> but you sorted it, thanks
[16:50] <vorlon> xnox: now just waiting for linux-restricted-modules-lowlatency https://ubuntu-archive-team.ubuntu.com/proposed-migration/mantic_uninst.txt
[16:51] -queuebot:#ubuntu-release- Unapproved: gpaste (mantic-proposed/universe) [45-1 => 45-2] (no packageset) (sync)
[16:51] <xnox> vorlon: if you are happy to shove linux-laptop & ubuntu-concept-x13s meta into the archive universe, and build it as universe enabled image that's fine. We cannot honestly hand on heart claim linux-laptop is security supported.
[16:51] <xnox> that's the only concern
[16:51] <xnox> vorlon: lowlatency - ergh
[16:51] <xnox> vorlon: let me ping people.
[16:52] <vorlon> xnox: laptop> in a meeting, will come back to this in a bit
[16:52] -queuebot:#ubuntu-release- Unapproved: accepted gpaste [sync] (mantic-proposed) [45-2]
[16:52] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons-ng (mantic-proposed/main) [46+really47.0.4-2ubuntu1 => 46+really47.0.5-1] (ubuntu-desktop) (sync)
[16:52] <xnox> vorlon: ack
[16:53] <xnox> (tag apw - yes we still have gcc-12 built kerenls in mantic on riscv64)
[16:59] <xnox> (linux-laptop has many linux-next patches, which will gain security support upstream, but not yet, and with lack of secureboot it is pwnable due to lack of lockdown, although we might want to boot with lockdown=integrity)
[17:22] <vorlon> xnox: - building an official Ubuntu release image with packages from universe is 100% preferable to building with packages from a PPA, precisely because we're being transparent within the defined archive schema wrt questions of support etc in a way that we're not in a ppa
[17:24] <vorlon> xnox: - there is precedent for producing platform-specific Ubuntu images (as opposed to flavors) with packages from universe and releasing them; raspi specifically.  However, this is something I in general regarded as a bug, and the fact that it was done this way got lost, and the images were built with universe enabled long after the bootstrap was done and this should have been turned off.  So as
[17:24] <vorlon> an implementation requirement, if we're going to do this, the livecd-rootfs code should hard-code mantic when pulling from universe
[17:24] <vorlon> (so that this decision has to be explicitly re-visited each release)
[17:25] <vorlon> xnox: - I haven't decided yet if I'm comfortable with the kernel coming from universe for a release image; will need to think about it a bit more, and I also think this shouldn't be my decision alone
[17:26] <vorlon> xnox: - if we do decide to do this, the fact we're doing it and deviating from the norm should be communicated in a few places (ubuntu-devel, discourse)
[17:27] <xnox> vorlon: i am happy to get those packages in main, if they can pass MIR
[17:27] <xnox> vorlon: it is linux-laptop linux-meta-laptop + the "meta" package which has a couple of hooks to force bluetooth work at runtime, and ensure flash-kernel / grub use the right dtb name always.
[17:27] <vorlon> well you mention security support, and that's where the MIR fails prima facie :)
[17:28] <xnox> vorlon: i am happy to put the kernel in main, as long as people realise that it doesn't have the same security support
[17:28] <xnox> for example it is unsigned kernel
[17:28] <xnox> thus it is on par with linux-raspi in terms of default security policy
[17:28] <vorlon> main vs universe is a Canonical declaration wrt security support
[17:28] <vorlon> sorry, afk for a bit; will read scrollback
[17:28] <xnox> i don't know if expectation is for this kernel to be signed, and for it to be lockdown enforcing
[17:28] <xnox> also we don't have direct OEM support for drivers
[17:29] <xnox> it does feel very much like raspi kernel when we only had support for one model, and it sort of works on a new revision model, but not yet quite but gets better with every sru
[17:29] <xnox> we have all usability criteria in place otherwise (bluetooth, wifi, fingerprint etc, it looks like a fully functioning dekstop)
[17:37] <xnox> vorlon: checking if we have engineering capacity for security support in every stable kernel sru cycle + anything extra required. No ESM for sure.
[17:37] <xnox> and somehow it has to be excluded from Pro support too
[17:37] <xnox> i don't know how kernels are defined there by canonical
[17:37] <xnox> maybe need input from jay or some such
[17:38] <xnox> i think intention is that over the next 12 months we will be able to fold everything into generic and thus roll it off to hwe kernel
[17:38] <xnox> meaning it will become just a normal looking generic desktop with runtime detection / quirks as needed
[17:40] <xnox> afk bym
[17:40] <xnox> gym
[17:48] <vorlon> xnox: ok, so you raise security as a concern, but then you say it's analogous to linux-raspi, which we do have in main and don't have any documented caveats for around security!  My understanding is that with linux-raspi, we have the same *committment* to address security issues, we just can't commit to an identical *timeline* due to the codebase differences.  (And of course, being a different
[17:48] <vorlon> branch means security vulnerabilities might be overlooked completely.)
[17:48] <vorlon> xnox: so if linux-laptop is the same as linux-raspi in this regard, I have no concerns about it being in main
[17:50] <vorlon> regarding it not being signed, I think this makes sense, because we don't want to expose our mainline arm kernels to risk of signing key revocation (or SBAT events) as a result of bugs in unvetted patches from linux-next.  This is something that should be documented prominently on the page for this image (because we are going to want a nice page, separate from the release notes, documenting how
[17:50] <vorlon> awesome it is and also its limitations)
[17:50] <xnox> ack => kernel team process wise, it needs to be in the archive, in main, marked as stable supported, with security notices (known) applied / cranked /released as per usual timelines
[17:51] <xnox> explaining lockdown=integrity actually is needed anyway. as i see that most people do not understand what it is; what it does; and which kernels have it by default; and when they have it
[17:53] <vorlon> xnox: then from my perspective, I don't see any blockers for getting this all into main and included in 23.10, just a pile of Work.  I will want to bikeshed the package names though, as is my right as an archive admin ;)  It's not clear to me that 'linux-laptop' is appropriate for this
[17:55] <xnox> vorlon: everybody hates linux-laptop, make a good name
[17:55] -queuebot:#ubuntu-release- Unapproved: cups-browsed (mantic-proposed/main) [2.0~rc1-0ubuntu2 => 2.0.0-0ubuntu1] (no packageset)
[17:56] <xnox> others call it "linux" , "aarch64-laptops" ppa/overlay/archive/build which uses just "linux"
[17:56] <xnox> i believe we are allowed to use brand names
[17:56] <xnox> so it can be linux-qcom-x13s
[17:57] <xnox> but maybe future gen platforms will be included too, in which case we can call it linux-qcom-client (the client deivision of qcom, to avoid people trying to use it on devices / iot / server)
[17:57] <xnox> wildcard entry is to call it linux-oem
[17:58] <xnox> as this will be the first time we build something that smells like linux-oem for arm64
[17:58] <xnox> with similar properties of rolling off to hwe kernel on per-sku basis
[17:59] <xnox> linux-concept is a contender too
[17:59] <vorlon> xnox: yes, my two immediate thoughts were something like either linux-arm-laptop, or linux-laptop-23.10 to parallel names like linux-oem-22.04, linux-oem-22.04b etc but not polluting the 'oem' namespace with something that doesn't follow that exact schema
[18:00] <vorlon> I like 'linux-laptop-23.10' because it's not tied to any particular SKU, makes it clear that it's a short-lived metapackage branch, etc
[18:00] <xnox> src:linux-oem-6.5 produces binary "meta" which are called like linux-oem-24.04 linux-oem-24.04c and the like as needed.
[18:00] <xnox> yes, i can add such variant, to use it as linux-laptop-23.10.
[18:01] <xnox> (the whole sharade of mimicking oem)
[18:01] <vorlon> or even 'linux-concept-23.10' or similar, since this doesn't strictly have to be about laptops in the future... but I'm not sold on 'concept' and am ok with 'laptop' for now
[18:02] <vorlon> xnox: so, um. can I ask you to write this up as an email to ubuntu-release@ so there's visibility to the archive team of what's going on?
[18:02] <xnox> ok.
[18:02] <xnox> or the FFe bug? or both?
[18:03] <xnox> do FFe subscribed release bugs get mailed to the mailing list?
[18:03] <vorlon> they do not
[18:03] <vorlon> so direct to the mailing list, please
[18:03] <vorlon> this isn't going to require any further sign-offs, but I want people to be aware so there's not confusion and frustration later
[18:05] <xnox> ok
[18:06] <xnox> the target is for this to create ubuntu-desktop-arm64+x13s.iso right, subarch image? because we still reserve the naked one for future generic iso?
[18:06] <vorlon> xnox: and as far as getting it into the 23.10 release: as soon as we have packages in the archive and livecd-rootfs support (which I will leave to you to provide patches for), I will turn on daily builds.  I don't mind doing this post-beta.  Actually making the release will require someone providing test cases for the iso tracker and committing to test
[18:06] <xnox> or are we gonna subarch it as arm64+concept or arm64+laptop ?
[18:06] <vorlon> xnox: arm64+x13s sounds good
[18:08] <xnox> we shall also request SKUs to be sent into cert lab
[18:08] <xnox> in case like mine and juergh laptops die
[18:47] -queuebot:#ubuntu-release- Unapproved: libfuture-asyncawait-perl (mantic-proposed/universe) [0.65-3 => 0.66-1] (no packageset) (sync)
[18:50] -queuebot:#ubuntu-release- Unapproved: accepted libfuture-asyncawait-perl [sync] (mantic-proposed) [0.66-1]
[19:07] <vorlon> xnox: btw is this actually going to be an .iso, not an .img?  I thought this was related to your arm64+generic preinstalled work previous
[19:21] -queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (mantic-proposed/main) [1.22.5-1ubuntu1 => 1.22.6-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[19:43] -queuebot:#ubuntu-release- Unapproved: accepted graphicsmagick [sync] (mantic-proposed) [1.4+really1.3.42-1]
[19:45] <vorlon> jbicha: is this mate-desktop sync something approved/wanted by the affected flavors?  there appears to be new portals functionality, hard to know from code inspection if this is going to be good or if it's going to break something
[19:46] <vorlon> apparently all of mate, unity, kylin affected
[19:48] <jbicha> the addition of the portals.conf just says that MATE uses x-d-p-gtk which is what Debian's x-d-p is falling back to anyways
[19:48] <jbicha> https://github.com/mate-desktop/mate-desktop/compare/v1.26.1...v1.26.2
[19:55] -queuebot:#ubuntu-release- Unapproved: accepted libmatemixer [sync] (mantic-proposed) [1.26.1-1]
[20:02] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (mantic-proposed/main) [23.10.44 => 23.10.45] (desktop-core, i386-whitelist)
[20:03] -queuebot:#ubuntu-release- Unapproved: accepted metacity [sync] (mantic-proposed) [1:3.50.0-1]
[20:04] <vorlon> jbicha: why is it you that's syncing these various mate packages rather than someone on the Ubuntu MATE team?
[20:05] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (mantic-proposed) [2.29.0-0ubuntu2]
[20:08] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools-signed [source] (mantic-proposed) [2.29.0-0ubuntu2]
[20:12] <jbicha> MATE team has been quiet this cycle
[20:12] -queuebot:#ubuntu-release- Unapproved: s390-tools (mantic-proposed/main) [2.29.0-0ubuntu2 => 2.29.0-0ubuntu2] (core)
[20:13] <vorlon> jbicha: ok, but that doesn't mean they've delegated to you the decisions about post-FF updates impacting their images?
[20:15] <jbicha> right
[20:18] -queuebot:#ubuntu-release- Unapproved: accepted mate-session-manager [sync] (mantic-proposed) [1.26.1-2]
[20:27] -queuebot:#ubuntu-release- Unapproved: accepted mate-system-monitor [sync] (mantic-proposed) [1.26.0-5]
[20:49] -queuebot:#ubuntu-release- Unapproved: cinder (lunar-proposed/main) [2:22.1.0-0ubuntu1 => 2:22.1.1-0ubuntu1] (openstack)
[21:10] -queuebot:#ubuntu-release- Unapproved: accepted mate-utils [sync] (mantic-proposed) [1.26.1-1]
[21:26] -queuebot:#ubuntu-release- Unapproved: accepted mate-user-guide [sync] (mantic-proposed) [1.26.2-1]
[21:30] <vorlon> tjaalton: is this rust-bindgen new upstream version going to cause a transition, and are we ready to absorb it? $ grep-dctrl -sPackage -FBuild-Depends rust-bindgen /var/lib/apt/lists/*Sources | wc -l
[21:30] <vorlon> 16
[21:32] <jbicha> yes, rust-bindgen is a transition that just completed in Debian last night
[21:34] <vorlon> jbicha, tjaalton: right, well that implies there are a bunch of other packages that also need synced, but maybe they went straight through and haven't landed in the queue?
[21:34] <vorlon> hmm no, per scrollback they haven't been synced yet
[21:34] <vorlon> so, I'm going to hold off on accepting this until I know there's a plan for getting the full transition in and done
[21:41] -queuebot:#ubuntu-release- Unapproved: aodh (jammy-proposed/main) [1:14.0.0-0ubuntu1.1 => 1:14.1.0-0ubuntu1] (openstack)
[21:42] -queuebot:#ubuntu-release- Unapproved: glance (jammy-proposed/main) [2:24.2.0-0ubuntu1 => 2:24.2.1-0ubuntu1] (openstack)
[21:43] -queuebot:#ubuntu-release- Unapproved: heat-dashboard (jammy-proposed/main) [7.0.0-0ubuntu3 => 7.0.1-0ubuntu1] (openstack)
[21:46] -queuebot:#ubuntu-release- Unapproved: accepted libei [sync] (mantic-proposed) [1.1.0-1]
[21:46] -queuebot:#ubuntu-release- Unapproved: magnum (jammy-proposed/universe) [14.1.0-0ubuntu1 => 14.1.1-0ubuntu1] (openstack)
[21:47] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (mantic-proposed) [2.12~rc1-10ubuntu1]
[21:51] -queuebot:#ubuntu-release- Unapproved: cinder (jammy-proposed/main) [2:20.3.0-0ubuntu1 => 2:20.3.1-0ubuntu1] (openstack)
[21:51] -queuebot:#ubuntu-release- Unapproved: nova (jammy-proposed/main) [3:25.2.0-0ubuntu1 => 3:25.2.1-0ubuntu1] (openstack)
[21:53] <xnox> vorlon: yes this is for a normal daily-live image / live session with installer. because it all works. Previous gen laptop (aka Malta image) was preinstalled desktop, because it really only ran well from usb stick, or required one to boot into windows to use boogcfg to set up uefi variables to be able to boot installed system due to previous lack of EFI variables support on the lenovo yoga
[21:53] <xnox> laptop.
[21:53] <vorlon> xnox: ok spiff
[21:53] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (mantic-proposed) [2.12~rc1-10ubuntu2]
[22:01] <xnox> vorlon: also the explicit Tasks in the PPA meta, and things done in the ppa, are because at the time, livecd-rootfs didn't run germinate a fresh, and didn't run it against merged archive of both ubuntu archive & a PPA. thus many of things things are because of building image out of the archive.
[22:02] <xnox> vorlon: also previously i did copy all packages that are on the iso pool into that ppa, to rsync PPA signed pool to .iso. because i only wanted to trusty on PPA key, both for the installed / online upgrade systems, and the iso pool.
[22:02] <vorlon> xnox: yep - I know *why* you XB-Task'ed, but it's obsolete since mantic, and anyway isn't the right task for this in the archive :)
[22:02] <xnox> so lots of things will be dropped upon upload into the Ubuntu archive.
[22:02] <vorlon> and there's also the question of which way round we want packages to look, this vs what raspi does
[22:03] <xnox> naming wise i could go with oem-x13s-meta => for which we have lots of in-archive support, and what all over $vendors use
[22:03] <xnox> with modalias sensitive to lenovo x13s
[22:03] <xnox> or i could go with something like ubuntu-laptop-meta which would publish raspi-ish looking ubuntu-desktop-x13s on arm64 only
[22:03] <xnox> to mimich ubuntu-desktop-raspi
[22:04]  * xnox love mimich
[22:05] <vorlon> I would avoid the oem meta namespace
[22:05] <xnox> agree
[22:05] <xnox> src:ubuntu-laptop-meta
[22:05] <xnox> if we are sticking with laptop arm64 naming
[22:05] <vorlon> and ubuntu-desktop-raspi is built from ubuntu-meta; do the same here?
[22:05] <xnox> if you are happy with me poluting ubuntu-desktop-raspi with things that's fine.
[22:06] <xnox> cause i am going to stick bluetooth set mac-address systemd .service file there
[22:06] <vorlon> not that specific binary package
[22:06] <vorlon> I'm saying do it in parallel to -raspi
[22:06] <xnox> ...
[22:06] <xnox> confused.
[22:06] <xnox> i'm gonna use ubuntu-desktop seed as normal installer image
[22:06] <vorlon> we have ubuntu-desktop-raspi, from ubuntu-meta source.  can we have ubuntu-desktop-x13s, also from ubuntu-meta?
[22:07] <xnox> unlike raspi, i don't need a top level meta for preinstalled.
[22:07] <xnox> (cause i am doing normal installer image)
[22:07] <vorlon> is the kernel the only difference in the installer image?
[22:07] <xnox> but if you want happy for me to ship quirks in src:ubuntu-meta than yes.
[22:08] <xnox> 1) different kerel 2) grub snippet to sort / set that as preffer flavour 3) set bluetooth mac address .service on boot
[22:08] <xnox> https://git.launchpad.net/ubuntu-concept/tree/?h=x13s/mantic
[22:08] <xnox> let's see what else is there
[22:08] <vorlon> the bluetooth mac address is going to be in the live squashfs?
[22:09] <vorlon> or the standard.squashfs
[22:09] <xnox> hm actually i don't like the current bluetooth service file https://git.launchpad.net/ubuntu-concept/tree/debian/ubuntu-concept-x13s.x13s-set-bluetooth-addr.service?h=x13s/mantic we should set it to a random one
[22:09] <vorlon> right I didn't like that either
[22:09] <xnox> and it should be conditional on btmgmt installed
[22:10] <vorlon> anyway I think I agree with you it's not quite parallel to what raspi does and probably shouldn't be from ubuntu-meta source
[22:10] -queuebot:#ubuntu-release- Unapproved: cinder (mantic-proposed/main) [2:22.1.0+git2023090509.f79048d2-0ubuntu1 => 2:23.0.0~rc1-0ubuntu1] (openstack)
[22:10] <xnox> vorlon: to be honest
[22:11] <xnox> vorlon: all of these things should be shipped by linux-laptop-23.10
[22:11] <xnox> because none of them are actually x13s specific
[22:11] <xnox> but more or less "malfunctioning droid's spare parts" level of things.
[22:11] <xnox> out of src:linux-laptop-meta
[22:11] <waveform> there's something in the Pi settings which sets the BT address from ... some MAC address or maybe the serial number? I can dig it out if you want to nab any of that
[22:11] <xnox> waveform: please.
[22:12] <xnox> waveform: i don't know if reusing system serial; or on-board mac is good or bad. I thought that the chip is the same as wlan, but i don't know if it is good or bad to reuse mac address of wlan on the BT chip?
[22:12] <vorlon> xnox: is this equivalent to the ubuntu-raspi-settings package though, I wonder
[22:13] <vorlon> xnox: uh are BT macs and wlan macs allocated by the same authority
[22:13] <waveform> ah, here we are: derives the BT MAC from a fixed prefix (presumably tied to Pi Ltd) and the last three octets of the serial: https://git.launchpad.net/ubuntu/+source/pi-bluetooth/tree/usr/bin/btuart
[22:14] <xnox> vorlon: there is src:ubuntu-settings and it builds raspi settings (three types) ubuntu-settings for destkop and ubuntu-touch-settings (really?)
[22:15] <xnox> vorlon: ubuntu-settings is indeed a better fit, but also this stuff is very kernel dependant.
[22:15] <vorlon> it would kind of be funny if reusing a wlan mac address that's guaranteed globally unique for ethernet, on a bluetooth device, resulted in a collision because it's a separate collision domain
[22:15] <vorlon> uh too many collisions of different types, but anyway
[22:16] <xnox> vorlon: i would err on shipping things in linux-laptop-23.10 and move them to ubuntu-settings once support lands in generic kernel, to eventually rolloff to src:ubuntu-settings & hwe kernel.
[22:16] <vorlon> ok
[22:16] <waveform> I would hope (probably foolishly) that an entity would have a couple of different MAC prefixes for different domains, but I have no idea
[22:16] <xnox> because the list of things we are doing is very kernel dependent right now
[22:16] <xnox> anybody knows how i can check all the MAC on windows? i wonder what my MAC are for the two sim card modems; wlan; bluetooth
[22:16] <xnox> (there is esim + physical sim)
[22:17] <vorlon> still, cloning the wlan mac to the bt mac would at most have a low *chance* of collision and would be enough to be getting on with for 23.10
[22:17] <waveform> yes, better than a fixed value at any rate
[22:17] <xnox> iff my wlan mac is real!
[22:17] <xnox> need to check that
[22:18] <vorlon> how many other computers do you want to talk to over bluetooth, really
[22:21] <xnox> i wish systemd could set stable random mac, derived from device name + machine-id
[22:22] -queuebot:#ubuntu-release- Unapproved: accepted libcupsfilters [source] (mantic-proposed) [2.0.0-0ubuntu1]
[22:27] -queuebot:#ubuntu-release- Unapproved: rejected libzstd [sync] (mantic-proposed) [1.5.5+dfsg2-2]
[22:28] <xnox> vorlon: summary email sent of plan of action
[22:28] <xnox> please review and we shall see what goes on.
[22:28] <vorlon> xnox: ta
[22:33] -queuebot:#ubuntu-release- Unapproved: accepted adsys [source] (mantic-proposed) [0.13.1]
[22:37] <vorlon> tjaalton: ok uh we got bit hard before by a post-FF mesa update, and https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1993226 is still open from the last time; can you work with the desktop team to get us some adequate test coverage here
[22:37] -ubottu:#ubuntu-release- Launchpad bug 1993226 in mutter (Ubuntu) "mutter autopkgtests fail to detect regressions in mesa" [Undecided, New]
[22:38] <xnox> vorlon: who on release team reviews and merges ubuntu-images changes? the image definition changes
[22:38] <xnox> https://code.launchpad.net/~ubuntu-release/ubuntu-images/+git/ubuntu-images/+ref/mantic/+activereviews
[22:38] <xnox> should it really be ubuntu-release team owned, instead of like ~ubuntu-core-dev?
[22:39] <xnox> one proposal there was sitting for over a month
[22:39] <xnox> mclemenceau: ^^^^
[22:53] -queuebot:#ubuntu-release- Unapproved: gst-rtsp-server1.0 (mantic-proposed/universe) [1.22.5-1 => 1.22.6-1] (no packageset) (sync)
[22:54] -queuebot:#ubuntu-release- Unapproved: accepted gst-rtsp-server1.0 [sync] (mantic-proposed) [1.22.6-1]
[22:58] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (mantic-proposed/main) [0.142ubuntu13 => 0.142ubuntu14] (core, i386-whitelist)
[22:59] -queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (mantic-proposed/main) [1.22.5-1 => 1.22.6-1] (desktop-core, i386-whitelist, ubuntu-server) (sync)
[23:02] -queuebot:#ubuntu-release- Unapproved: alacarte (mantic-proposed/universe) [3.44.3-1 => 3.50.0-1] (desktop-extra) (sync)
[23:07] <xnox> vorlon: i have compelted test builds of all reverse-depends against the new mesa rc, and fixed all FTBFS, none of which were mesa induced and were generic fallout in mantic
[23:07] <xnox> (i.e. stuff like not building with mantic gcc-13)
[23:08] <xnox> hence my debian NMUs and syncs to ubuntu for FTBFS fixes
[23:12] <xnox> vorlon: but yes, there seem to be test suite failure in mutter! https://launchpad.net/~xnox/+archive/ubuntu/mesa/+packages?field.name_filter=mutter&field.status_filter=published&field.series_filter=
[23:12] <xnox> vorlon: it makes sense to no-change rebuild upload mutter, after mesa upload is done
[23:12] <xnox> (note my test is against mesa with different llvm)
[23:14] <xnox> vorlon: note that mesa FFe is multipurposes, hence i care about mesa FFe for both Pi and x13s
[23:14] -queuebot:#ubuntu-release- Unapproved: cogl (mantic-proposed/main) [1.22.8-4 => 1.22.8-4ubuntu1] (desktop-core)
[23:16] -queuebot:#ubuntu-release- Unapproved: clanlib (mantic-proposed/universe) [1.0~svn3827-10 => 1.0~svn3827-11] (no packageset) (sync)
[23:16] -queuebot:#ubuntu-release- Unapproved: accepted clanlib [sync] (mantic-proposed) [1.0~svn3827-11]