[08:41] <xypron> I am looking for a sponsor for aiocoap 0.4.3-0ubuntu1 available in ppa:xypron/merge-from-debian (LP: #1959315). This version provides Python 3.10 compatibility.
[08:41] <ubottu> Launchpad bug 1959315 in aiocoap (Ubuntu) "autopackage tests fail" [Undecided, New] https://launchpad.net/bugs/1959315
[09:01] <schopin> xypron: I'll take a look.
[09:19] <xypron> Thanks schopin.
[09:19] <xypron> Package make-dfsg - 4.3-4.1ubuntu2 is available in ppa:xypron/merge-from-debian. I am looking for a sponsor. LP: #989961
[09:19] <ubottu> Launchpad bug 989961 in make-dfsg (Ubuntu) "Provide a gmake symlink" [Wishlist, In Progress] https://launchpad.net/bugs/989961
[09:20] <schopin> I'll leave that one to a core dev ;-)
=== mfo_ is now known as mfo
=== slyon_ is now known as slyon
=== jchittum_ is now known as jchittum
=== nicolasbock_ is now known as nicolasbock
[10:20] <eoli3n> Hi
[10:20] <eoli3n> someone said here that ubiquity will be replaced
[10:20] <eoli3n> which will be the new tool ?
[10:25] <ogra> eoli3n, https://discourse.ubuntu.com/t/new-desktop-installer-preview-build/24765
=== alan_g_ is now known as alan_g
[10:43] <eoli3n> thanks ogra
[11:14] <eoli3n> ogra will ubuntu 22.04 LTS be released with this new installer ?
[11:14] <eoli3n> so preseed will not be used anymore ?
[11:15] <ogra> eoli3n, no idea wheer the new installer stands, sorry ... perhaps ask in the thread
[11:18] <seb128> eoli3n, no, the LTS will not get the new installer by default but rather available as a tech preview, we decided to be conservative and postpone the switch to next cycle
[11:52] <ahasenack> good morning
[12:23] <eoli3n> seb128, i need to automate luks-tpm install with preseed
[12:23] <eoli3n> i'm wondering if I should wait for the new installer, will it be usable, even if not the default one ?
[12:24] <eoli3n> will it be simpler to get luks-tpm install with the new one ?
[13:48] <ahasenack> for those on +1 maintenance, I'm handling stunnel4 (a dep8 test failure as part of the python 3.10 migration) in https://code.launchpad.net/~ahasenack/ubuntu/+source/stunnel4/+git/stunnel4/+merge/414829
[14:04] <eoli3n> so ubuntu core supports full disk encryption with TPM, and secure boot
[14:04] <eoli3n> but not ubuntu desktop ?
[14:27] <enr0n> tumbleweed: I was looking at an autopkgtest failure for src:python-gmpy2 caused by using Python 3.10, which is ultimately resolved in the upstream repo (https://github.com/aleaxit/gmpy/issues/296). I noticed that you had previously pulled in a patch related to Python 3.10 for that package. Is this issue already on your radar for the Debian package?
[14:27] <ubottu> Issue 296 in aleaxit/gmpy "Python 3.10.0a6 test failure" [Closed]
[14:32] <cpaelzer> paride: what is the latest summary on fuse3 as I'd soon upload qemu which is another "ready for fuse3" case but would cause conflicts if not all are ready to move
[14:32] <cpaelzer> just as we had it with open-vm-tools :-/
[14:33]  * cpaelzer is reading the recap on the bugs that you recently posted ...
[14:34] <paride> cpaelzer, so IIRC grub2 is still waiting for us, while s390-tools is waiting for upstream, fheimes is confident they'll release in time for FF
[14:34] <paride> the other packages are Fix Released
[14:35] <cpaelzer> ok trusting in fheimes on s390xtools then
[14:35] <cpaelzer> paride: grub is waiting for what exactly ?
[14:35] <paride> anyway grub2 and s390-tools only depend on libfuse, not on bin:fuse, so they _should_ not cause the same issue we had with open-vm-tools
[14:35] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1935659 I guess
[14:36] <ubottu> Launchpad bug 1935659 in grub2-unsigned (Ubuntu Jammy) "grub2 FTBFS when built with libfuse3-dev" [Undecided, New]
[14:36] <paride> cpaelzer, yes. There's a patch available.
[14:38] <paride> cpaelzer, on s390-tools, there are patches that can be cherry-picked if we start worrying about FF
[14:38] <cpaelzer> paride: I think we also need to switch launchpad-buildd for https://bugs.launchpad.net/launchpad-buildd/+bug/1956949 - what do you think
[14:38] <ubottu> Launchpad bug 1956949 in unionfs-fuse (Ubuntu) "CPC AWS jammy builds fail with: 'fuse3 : Breaks: fuse'" [Undecided, New]
[14:39] <paride> looking
[14:39] <cpaelzer> not blocking the transition, but just looking forward
[14:39] <cpaelzer> so we might switch that task back to new
[14:41] <paride> yes, after re-reading Colin's comment I agree
[14:41] <paride> not blocking, but we should switch
[14:44] <cpaelzer> paride: so while we need to get rid of all of these before we can demote fuse2 I think we might be ready to make the switch now
[14:45] <cpaelzer> paride: comparing these two (as only fuse / fuse3 are mutually exclusive)
[14:45] <cpaelzer> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.jammy/rdepends/ALL/fuse
[14:45] <cpaelzer> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.jammy/rdepends/ALL/fuse3
[14:45] <cpaelzer> I thought ahasenack worked on the glusterfs portion of it
[14:45] <cpaelzer> open-vm-tools is ready to be uploaded
[14:45] <ahasenack> hello
[14:46] <ahasenack> glusterfs does not use the system fuse
[14:46] <cpaelzer> and qmeu is another one only depending on the lib, not the fuse[3]
[14:46] <ahasenack> I think that `Depends: fuse` is wrong even, or superfluous
[14:46] <cpaelzer> I remember you said that, but have seen glusterfs-server in the output I linked above
[14:46] <cpaelzer> therefore I wondered
[14:47] <ahasenack> just because of that depends. And fuse3 provides fuse, right?
[14:47] <ahasenack> although I think apt will give preference to the exact match, fuse
[14:47] <cpaelzer> Provides: fuse (= 3.10.5-1)
[14:47] <ahasenack> but I replaced that with fuse3, and even removed it, it makes no difference
[14:48] <ahasenack> I filed a bug with upstream about starting to use system fuse, no response yet. I was hoping for a response there before I went to debian asking to drop that Depends:fuse
[14:48] <cpaelzer> Indeed I see no dependency to fuse in glusterfs-server of jammy
[14:48] <cpaelzer> I wondere why/where the germainate report picked that up
[14:49] <cpaelzer> the report is of today
[14:49] <ahasenack> a seed?
[14:49] <cpaelzer> ah
[14:49] <cpaelzer> glusterfs-server -> glusterfs-client -> fuse
[14:50] <cpaelzer> Full line "Depends: libc6 (>= 2.34), python3:any, fuse, glusterfs-common (>= 10.1-1)"
[14:50] <cpaelzer> no | fuse3 or better "fuse3 | fuse" or since you say it doesn't use it just no fuse at all
[14:52] <cpaelzer> ahasenack: could that just not list fuse at all if it doesn't use the system binary?
[14:52] <ahasenack> yes, that's what I think
[14:53] <cpaelzer> that would be great to be able to let it go and not interfere with the promotion of glusterfs
[14:53] <cpaelzer> paride: for qemu that means I can upload with the libfuse3 dependency
[14:54]  * ahasenack -> lunch
[14:56] <paride> cpaelzer, I don't see other blockers
[14:57] <cpaelzer> paride: I pinged the grub bug, I will upload qemu as proposed (only dep to the lib), ahasenack will look at dropping the dep to fuse from glusterfs and we give s390x a chance to complete, then open-vm-tools can be re-uploaded - does that sound right as a summary ?
[14:57] <paride> cpaelzer, yes sounds 100% right to me
[14:57] <cpaelzer> or actually, I think we can even upload open-vm-tools now, the old issues are gone
[15:07] <cpaelzer> paride: I updated the bugs with the status-of-the-day :-)
[15:07] <cpaelzer> thanks paride and ahasenack
[15:09] <cpaelzer> sergiodj: ahasenack: have you seen the ldap question at https://discourse.ubuntu.com/t/service-ldap-with-tls/11578/4 ?
=== mfo_ is now known as mfo
[15:59] <ahasenack> cpaelzer: I have not seen that discourse question
[18:03] <tumbleweed> enr0n: nope, I see the new upstream fixes the issue, I'll have a look at that
[19:15] <LocutusOfBorg> hello seb128 do you plan a gst-plugins-bad1.0 merge from experimental?
[21:18] <seb128> LocutusOfBorg, hey, jbicha is working on the gstreamer merges
[21:20] <jbicha> yes, I'm working on it now :)
=== genii is now known as genii-core