[01:47] <cgmb> Could someone retry the rocr-runtime proposed builds on amd64, ppc64el and riscv64?
[01:48] <cgmb> https://launchpad.net/ubuntu/+source/rocr-runtime/5.7.1-1
[02:07] <dbungert> cgmb: clicking but not for armhf
=== JanC is now known as Guest5782
=== JanC_ is now known as JanC
[03:32] <cgmb> dbungert: Thanks! I don't think armhf has ever successfully built for any version, so fortunately that's not a regression.
=== bastif is now known as bastif_
=== bastif_ is now known as bastif
[07:22] <bastif> Does #ubuntu-motu exist?
[07:26] <bastif> Apparently not.
[07:34] <vorlon> bastif: see https://lists.ubuntu.com/archives/ubuntu-devel/2023-October/042828.html , https://lists.ubuntu.com/archives/ubuntu-devel/2023-November/042846.html
[07:34] <vorlon> i.e., this is the correct channel for anything that would previously have gone there
[07:38] <cgmb> I didn't even notice I wasn't in #ubuntu-motu. :O
[07:39] <vorlon> you are!  it's just called #ubuntu-devel
[07:39] <JackFrost> I think I'm the only one left in there. :3
[07:39] <bastif> oh, ok. I started writing a mail to the mailing list ubuntu-motu. Well. I package qt for android (named qt-android-6.6 for example) and wanted to know if there is some interest for Ubuntu
[07:41] <vorlon> bastif: hmm, how do you see this fitting in the context of Ubuntu? We have a native Qt stack and we don't really have an Android library stack
[07:43] <bastif> Users would be Android App developers that use Qt framework in their app. It could be useful for F-Droid too, but FDroid uses Debian, not Ubuntu.
[07:45] <vorlon> why would developers want to consume this in the form of .debs distributed in Ubuntu?
[07:45] <vorlon> I know we have some android libraries included, by way of Debian; but my impression was that they're bit rotted
[07:46] <vorlon> I could be wrong though
[07:46] <bastif> why? to avoid the qt's installers
[07:46] <bastif> for example
[07:47] <vorlon> anyway, my questions aside, I'd suggest that unless you find an Ubuntu developer who feels invested in this and wants to champion it, the best option is to try to get this into Debian and then into Ubuntu via a sync
[07:47] <bastif> and have it installed cleanly on the system as a package which can be added/removed cleandly
[07:47] <bastif> Already tried for Debian. It doesn't seem there is much interest
[07:48] <vorlon> well, fair enough!  I guess I would have expected some sort of self-contained SDK option for this without messy installers
[07:48] <vorlon> but also uh I don't develop for Android so
[07:49] <vorlon> have you considered publishing it as a snap? that would have the value of not requiring an Ubuntu developer to sponsor it, and also not being tied to Ubuntu's release cycle
[07:49] <bastif> moreover it depends on Android SDK & NDK (which are packaged as 'installers' in non-free)
[07:49] <bastif> well it's on my ppa, but well, that's not the same visibility
[07:49]  * vorlon nods
[07:49] <vorlon> sorry, I don't have anything more concrete to offer you
[07:50] <vorlon> and it's bedtime here :)
[07:50] <vorlon> good luck
=== sem2peie- is now known as sem2peie
=== guiverc2 is now known as guiverc
=== pushkarnk1 is now known as pushkarnk
=== litios_ is now known as litios
=== sem2peie- is now known as sem2peie
=== pushkarnk1 is now known as pushkarnk
[12:21] <fheimes> Dear #archive-admins AA - the s390-tools v2.31 s390x binaries need special approval and are currently in noble's unapproved queue (also visible here: https://launchpad.net/ubuntu/+source/s390-tools/2.31.0-0ubuntu1/). Please would you mind giving your approval?
=== pushkarnk1 is now known as pushkarnk
=== pushkarnk1 is now known as pushkarnk
=== pushkarnk1 is now known as pushkarnk
=== pushkarnk1 is now known as pushkarnk
[14:06] <paride> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: paride
[14:41] <bluca> paride: hi, any chance you could please help with lvm2? There's two changes that would be good to get in noble before the freeze, https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/2054683 and https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/2054620
[14:41] -ubottu:#ubuntu-devel- Launchpad bug 2054683 in lvm2 (Ubuntu) "Please merge lvm2 2.03.16-3 from Debian unstable." [Undecided, New]
[14:41] -ubottu:#ubuntu-devel- Launchpad bug 2054620 in lvm2 (Ubuntu Noble) "libdm returns wrong error code when dm-verity key cannot be found" [Undecided, Confirmed]
[14:41] <bluca> note that the second one is merged upstream, which is also now available in debian unstable and could be synced
[14:43] <paride> bluca, hey, sure, looking
[14:46] <bluca> thanks!
[15:02] <paride> bluca, in https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/2054620 you mention that " currently in noble lvm2 fails to build due to https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/2054683 which is unrelated to the MR linked here"
[15:02] -ubottu:#ubuntu-devel- Launchpad bug 2054620 in lvm2 (Ubuntu Noble) "libdm returns wrong error code when dm-verity key cannot be found" [Undecided, Confirmed]
[15:02] -ubottu:#ubuntu-devel- Launchpad bug 2054683 in lvm2 (Ubuntu) "Please merge lvm2 2.03.16-3 from Debian unstable." [Undecided, New]
[15:03] <paride> bluca, you mean that your patch ftbfs because it needs the merge to be done first?
[15:03] <paride> or am I missing the point?
[15:05] <bluca> lvm2 ftbfs as it is currenlty in noble
[15:06] <bluca> so it needs lp:2054683 to fix the build failure too
[15:06] -ubottu:#ubuntu-devel- Launchpad bug 2054683 in lvm2 (Ubuntu) "Please merge lvm2 2.03.16-3 from Debian unstable." [Undecided, New] https://launchpad.net/bugs/2054683
[15:06] <bluca> my patch is unrelated to that
[15:06] <bluca> but is affected by it, as any other build of lvm2
[15:07] <bluca> (or at least, that was the situation 4 days ago when I left that comment, there might have been other /usr-merge changes happening in the meanwhile in noble)
[15:16] <paride> bluca, looks like Debian has lvm2 .22, while aiui that patch is included in .23
[15:17] <paride> bluca, and in any case we have other Ubuntu delta, we'd still need to merge
[15:17] <paride> bluca, I reviewed waveform's merge and it looks good, I'm going to sponsor that
[15:19] <bluca> ah indeed, I thought debian was updated to the latest, rather than latest-1
[15:20] <paride> bluca, as I understand it libdm-propagate-ioctl-errors-back-to-caller improves the UX when a certain error condition happens
[15:20] <bluca> yes - not just UX, but other programs calling libdm too, like systemd and cryptsetup
[15:22] <paride> bluca, in general I'm not a great fan of patching upstream releases unless it's necessary. moreover the the work towards getting good error messages on ENOKEY doesn't seem to be fully complete. The patch itself says:
[15:23] <paride> + This is not enough to make libcryptsetup actually propagate the ENOKEY
[15:23] <paride> + correctly, that also needs a patch to libcryptsetup, but this is part of
[15:23] <paride> + the puzzle.
[15:23] <bluca> that patch is included in cryptsetup 2.7.0 which was just uploaded to debian
[15:47] <paride> bluca, I replied to the bug
[16:01] <rbasak> bdrung: hi have you seen https://code.launchpad.net/~racb/ubuntu-sponsoring/+git/ubuntu-sponsoring/+merge/460697 please?
[16:02] <dbungert> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: paride, dbungert
[16:08] <bdrung> rbasak, yes. I forgot to press the save button back then.
[16:12] <rbasak> Thank you for the review. I'll fix that.
=== pizzaiolo is now known as pizza
[16:38] <bluca> paride: thanks, updated the description as requested, let me know if you need more details
[16:46] <paride> @pilot off
[16:46] <ubottu> (pilot <in|out>) -- Set yourself as in or out of patch pilot.
[16:46] <paride> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: dbungert
[16:46] <paride> bluca, I left a note on your bug/patch in the handover discourse post
[16:46] <paride> so some other pilot, maybe dbungert, can have a look
[16:47] <bluca> thanks!
[17:10] <tsimonq2> rbasak: Would you or someone else from Canonical Server be willing to review an ssh-import-id MP I'm preparing?
[17:12] <tsimonq2> I want to finally get https://bugs.launchpad.net/ssh-import-id/+bug/1745538 solved before Feature Freeze. If there isn't any interest in Canonical Server, cool I'll quilt patch and seek a review elsewhere. If there *is* interest I can give you an ETA of a few hours before it's all good.
[17:12] -ubottu:#ubuntu-devel- Launchpad bug 1745538 in ssh-import-id "Support for teams should be added" [Wishlist, In Progress]
[17:18] <xypron> I am looking for a sponsor for LP #2047298 - nothing existing just fixing build dependencies
[17:18] -ubottu:#ubuntu-devel- Launchpad bug 2047298 in ghdl (Ubuntu) "Building ghdl fails if LLVM and Clang versions are not provided explicitly" [Undecided, New] https://launchpad.net/bugs/2047298
[17:18] <rbasak> tsimonq2: asking here is probably best. If Ubuntu takes it then I think upstream should do so as well.
[17:18] <rbasak> tsimonq2: the catch is that of course everyone wants reviews two days before feature freeze :-/
[17:19] <rbasak> If Ubuntu takes it> I mean that if an Ubuntu core dev says they've reviewed it and would sponsor it in principle, then upstream should just merge that.
[17:19] <rbasak> (no quilt patch upload needed)
[17:20] <tsimonq2> Works for me. I'll abstain from reviewing my own MP, of course. ;)
[17:21] <tsimonq2> (Also, yeah, this Feature Freeze is a difficult deadline for some people including myself. :P)
[17:35] <dbungert> bluca: thanks for the updated context on LP: #2054620 .  My gut says to allow lvm2 to migrate and treat this as a bugfix, so no problem to merge post-feature-freeze if lvm2 migration ends up being non-trivial.  What do you think?
[17:35] -ubottu:#ubuntu-devel- Launchpad bug 2054620 in lvm2 (Ubuntu Noble) "libdm returns wrong error code when dm-verity key cannot be found" [Undecided, Confirmed] https://launchpad.net/bugs/2054620
[17:38] <bluca> sure no problem - I've rebased the PR on top of the merge
[17:57] <bluca> is there a specific team/person who looks after cryptsetup? it would be great to have the new version in noble, it adds quite a few features that we can use in systemd
[18:07] <rbasak> bluca: the Foundations team does. It seems late to be asking now though - feature freeze is in two days.
[18:08] <rbasak> Ah and the new upload only went into unstable yesterday
[18:10] <bluca> yeah it took a while for the version to be picked in unstable
=== mfo is now known as Guest2142
=== mfo_ is now known as mfo
[20:49] <arraybolt3> Before I attempt a stunt, I want to verify this works - can I upload a *native* package that supercedes an older *quilt* package?
[20:53] <dbungert> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
[20:56] <arraybolt3> (reasoning for wanting to do so - there's a Lubuntu-specific package that was initially made as an "upstream" software application and then was packaged "downstream" in Ubuntu. This got very cumbersome because the only place this software is ever going to be used is in Ubuntu, and it's far easier to "merge" upstream and downstream by making it a native package.)
[21:01] <dbungert> arraybolt3: a bit uncommon perhaps but I doubt there is anything wrong with that.  Removing unnecessary merge work sounds like a plus.
[21:02] <arraybolt3> +1
[21:13] <rbasak> arraybolt3: as long as the version number goes up. Eg. you can't drop the suffix to make a non-native go native since that'd (probably) require the version to go backwards.
[21:13] <rbasak> Please don't use an epoch though!
[21:17] <arraybolt3> I'm changing the version from something like 1.2.3-0ubuntu1 to 24.04.1.
[21:17] <arraybolt3> I'm pretty sure that will go forwards?
[21:17]  * arraybolt3 checks with dpkg
[21:18] <arraybolt3> yep, that goes forward
[21:20] <arraybolt3> (the versioning convention being, release code + upload number)
[21:43] <rbasak> arraybolt3: I'd avoid 24.04 since that isn't known yet (albeit highly likely)
[21:44] <rbasak> eg. 6.06.
[21:44] <rbasak> We only know the codename right now.
[21:50] <arraybolt3> rbasak: um... it's a bit late sadly
[21:50] <arraybolt3> but in the event 24.04 gets missed, it can be bumped to 24.06 or whatever
[21:50] <rbasak> Yeah it's not the end of the world.
[21:51] <rbasak> I try and avoid setting such an example though - because then everyone starts doing it in the archive and then it'd more of a mess if something were to change.
[21:59] <Eickmeyer> Version numbers are cheap.
[22:01] <rbasak> ...until you start looking over your shoulder :-P
[22:01] <Eickmeyer> XD