[07:01] <oSoMoN> good morning desktoppers
[07:23] <jibel> Good morning folks
[07:28] <duflu> Morning oSoMoN and jibel 
[07:30] <jpnurmi> good morning oSoMoN and jibel, hey duflu
[07:31] <duflu> Hi jpnurmi 
[07:31] <jibel> hi duflu jpnurmi 
[07:36] <oSoMoN> hey duflu 
[07:36] <oSoMoN> good morning jpnurmi 
[08:13] <seb128> goood morning desktopers
[08:18] <duflu> Hi seb128 
[08:21] <seb128> duflu, hey, how are you?
[08:22] <duflu> seb128, tired but I've done my interviews and 360s now so all down hill... How are you?
[08:23] <seb128> duflu, a bit tired as well but it's nice and sunny outside so let's see if that's enough to wake me up properly
[08:47] <oSoMoN> salut seb128 
[08:50] <seb128> lut oSoMoN, en forme ?
[08:52] <oSoMoN> on fait aller :)
[11:24] <KGB-0> gtk3 Simon McVittie 300561 * commented merge request !6 * https://deb.li/3BUyz
[12:00] <jbicha> good morning
[12:03] <seb128> jbicha, hey, how are you?
[12:05] <jbicha> happy Mario Day, lol
[12:23] <seb128> jbicha, I'm curious but why are you rebuilding half of the archive for a 'new gdx picbuf'?
[12:23] <seb128> gdk pixbuf even
[12:23] <seb128> we didn't even have an upload for that package this year
[12:26] <jbicha> it's an old transition from Debian that we never finished. Debian bug 981141
[12:28] <seb128> jbicha, is it really worth DoSing the infra and triggering tests accross the board to drop a transitional?
[12:30] <jbicha> Debian would eventually drop the transitional package and this way we're ready for it. I think the infrastructure isn't too loaded now
[12:30] <seb128> alright :-(
[12:31] <seb128> we probably have higher priority issues that are visible to users to deal with though
[13:14] <jbicha> seb128: the webkit/surf/arm64 autopkgtest failed with the new version
[13:16] <seb128> jbicha, right, I tested that yesterday and reported https://bugs.webkit.org/show_bug.cgi?id=237636
[13:17] <luna> todays iso worked to install
[13:19] <seb128> 👍
[13:19] <jbicha> thank you
[13:27] <jbicha> seb128: what do you think about having gnome-shell use the new gnome-bluetooth? we would still need to keep the old gnome-bluetooth in main for our gtk3 gnome-control-center
[13:28] <jbicha> it would avoid needing to revert ~6 commits https://gitlab.gnome.org/GNOME/gnome-shell/-/commits/main/js/ui/status/bluetooth.js
[13:30] <jbicha> the "wedged state" fix requires the new gnome-bluetooth or backporting the set_default_adapter_powered API to the old gnome-bluetooth
[13:35] <seb128> jbicha, is that separate source? I don't think the MIR team is going to like that, it's one of the usual rules to have only one variant for a source in main
[13:36] <jbicha> yes, it is a separate source
[13:37] <seb128> you can try to make your case to the MIR team but I would rather stick to the 'one copy of the source to main' and backport the patches
[13:37] <seb128> or revert the shell requirement
[13:40] <jbicha> Trevinho brought up one additional point earlier: if a GNOME Shell extension tries to mess with the Bluetooth menu, it may break because we've diverged enough there from the usual Shell 42
[13:41] <jbicha> maybe that's rare. It would be cool to have something like codesearch for extensions.gnome.org
[13:42] <Trevinho> jbicha: I think you can ask Adkins admin there to grep the extensions 
[13:43] <seb128> jbicha, if we backport the gnome-bluetooth patches we need to our main version that means no delta on the shell no?
[13:43] <seb128> jbicha, Trevinho, also is one of you working on unblocking the shell migration?
[13:45] <jbicha> no for backporting being a complete fix because there is a <switch to GListModel> API change that I think would break API for other uses
[13:45] <jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/gnome-bluetooth3.html
[13:46] <seb128> jbicha, k, you made it sound earlier that we just needed a new api
[13:46] <tillkamppeter> seb128, hi
[13:46] <seb128> tillkamppeter, hey
[13:47] <jbicha> yes, for one particular bluetooth improvement in the new series :|
[13:47] <tillkamppeter> seb128, you seem to have not returned yesterday, so let us try now.
[13:47] <jbicha> I fixed gpaste yesterday so the remaining task for gnome-shell migration is doing a git bisect to figure out when the testcase got one pixel off
[13:49] <tillkamppeter> seb128, I have looked into merging the CUPS package from Debian, but their change, the "SystemGroup: lpadmin root" we had already as Ubuntu-specific patch for a longer time, so a merge would not lead to anything new.
[13:49] <seb128> jbicha, well, you have my opinion, I don't think the MIR team is going to like having a second copy in main but feel free to try your chance with them
[13:50] <seb128> tillkamppeter, hey, sorry I need to step out again now, but I do think the issue is rather than the printer somehow, my android phone wouldn't be able to connect to it either
[13:50] <tillkamppeter> seb128, so your problem is another and I could only find out about it by the usual info, error_log in debug mode, what did you try, ...
[13:50] <seb128> tillkamppeter, I will try on windows later and if it works I will ping you back to see why it doesn'"t work on Ubuntu
[13:50] <tillkamppeter> So then perhaps poer-cycle printer ...
[13:50] <seb128> tillkamppeter, but if it's not working on windows I'm going to assume it's a printer issue
[13:50] <tillkamppeter> Check printer's web interface ...
[13:51] <seb128> tillkamppeter, k, I need to step out for a bit but I will check that later and let you know if I've news, thanks
[13:51] <seb128> jbicha, I saw for gpaste, thanks, let's see if Trevinho can sort ouf the test or maybe ignore it
[13:51] <jbicha> seb128: would I need a MIR then a FFE if I wanted to try for the gnome-bluetooth3 for gnome-shell?
[13:52] <seb128> jbicha, yes
[13:53] <Trevinho> seb128: I probably can just disable it for now... Really have no clue what that Pixel difference is due to 
[13:53] <seb128> alright, I need to drop from IRC, I need to be somewhere in 7 min and I'm late, use mattermost or try again if you need to reach me
[13:53] <seb128> Trevinho, please do, we need to unblock that update one way or another
[13:53] <seb128> bbl
[13:54] <jbicha> Trevinho: should we jump mutter/gnome-shell to 42 RC now or wait for migration first?
[13:55] <Trevinho> jbicha: can see how that will be expensive 
[13:55] <Trevinho> But probably better go with beta first as it's more tested 
[13:57] <jbicha> ok, I'll do a gnome-shell upload for LP: #1964136 now
[14:04] <KGB-2> gnome-shell signed tags b2e7f84 Jeremy Bicha ubuntu/42_beta-1ubuntu2 * gnome-shell Debian release 42~beta-1ubuntu2 * https://deb.li/3QFRE
[14:04] <KGB-2> gnome-shell ubuntu/master 680e944 Jeremy Bicha debian/patches/ series ubuntu/Revert-ui-Rename-gnome-control-center-to-org.gnome.Settin.patch * Add patch to restore Settings item in system menu * https://deb.li/12jl
[14:04] <KGB-2> gnome-shell ubuntu/master f906057 Jeremy Bicha debian/changelog * releasing package gnome-shell version 42~beta-1ubuntu2 * https://deb.li/3VcvI
[14:16] <KGB-0> gnome-bluetooth3 upstream/latest e502510 Jeremy Bicha * pushed 17 commits (first 5 follow) * https://deb.li/3TFKc
[14:16] <KGB-0> gnome-bluetooth3 upstream/latest 748dbb5 Jiri Grönroos po/fi.po * Update Finnish translation * https://deb.li/TBDD
[14:16] <KGB-0> gnome-bluetooth3 upstream/latest 530fe98 Bastien Nocera tests/integration-test.py * tests: Fix wait_for_condition() AGAIN 😩 * https://deb.li/iiOsz
[14:17] <KGB-0> gnome-bluetooth3 upstream/latest 91aed31 Bastien Nocera tests/integration-test.py * tests: Wait longer than one loop iteration for device removal * https://deb.li/QBf2
[14:17] <KGB-0> gnome-bluetooth3 upstream/latest 80daa7a Bastien Nocera lib/bluetooth-client.c * lib: Merge device removal with adapter removal * https://deb.li/3D23C
[14:17] <KGB-0> gnome-bluetooth3 upstream/latest 942dda2 Bastien Nocera tests/integration-test.py * tests: Add test for device removal coalescing/quieting * https://deb.li/VXBh
[14:17] <KGB-0> gnome-bluetooth3 pristine-tar e135c28 Jeremy Bicha gnome-bluetooth3_42~rc.orig.tar.xz.delta gnome-bluetooth3_42~rc.orig.tar.xz.id * pristine-tar data for gnome-bluetooth3_42~rc.orig.tar.xz * https://deb.li/3qBOd
[14:20] <KGB-2> gnome-shell ubuntu/master b0d9577 Jeremy Bicha * pushed 98 commits (first 5 follow) * https://deb.li/3icTF
[14:20] <KGB-2> gnome-shell ubuntu/master ba23279 Jonas Dreßler js/ui/workspace.js * workspace: Don't freeze the layout when there's no layout yet * https://deb.li/i2XP1
[14:20] <KGB-2> gnome-shell ubuntu/master fc4f9f6 Florian Müllner js/misc/signalTracker.js js/ui/environment.js js/ui/messageTray.js tests/unit/signalTracker.js * signalTracker: Explicitly register destroyable types * https://deb.li/wFve
[14:20] <KGB-2> gnome-shell ubuntu/master 6d3df38 Sebastian Keller js/ui/workspace.js * workspace: Scale slots to current workspace size when layout is frozen * https://deb.li/3tB70
[14:20] <KGB-2> gnome-shell ubuntu/master 462d17d Piotr Drąg po/pl.po * Update Polish translation * https://deb.li/GcnA
[14:20] <KGB-2> gnome-shell ubuntu/master c2bc101 Florian Müllner (6 files in 5 dirs) * Bump version to 42.rc * https://deb.li/3yXfi
[17:46] <jbicha> oSoMoN: are you going to unblock firefox from jammy-proposed soon? Jammy users are getting both the deb and snap of Firefox currently
[17:47] <oSoMoN> jbicha, there are a few details to iron out before it can be unblocked
[18:45] <seb128> jbicha, we also need to figure out what we do about the fact that the snap and so the new deb are available on less architectures, it's going to lead to component mismatches for things that require a browser
[18:48] <jbicha> install Epiphany on those weird architectures? 😜
[18:50] <seb128> I was thinking that yes
[18:50] <seb128> but if that's the option we pick then we need to MIR it so it's going to take a while
[18:53] <sarnold> I have trouble seeing us being able to provide a similar level of security support for the boutique browsers..
[18:54] <jbicha> how long do we need to support those architectures for?
[18:55] <mdeslaur> we're currently unable to provide reasonable webkit2gtk updates for the duration of an LTS
[18:55] <mdeslaur> I wouldn't want that to be a browser engine installed by default
[19:00] <KGB-0> gnome-control-center Marco Trevisan 300651 * commented merge request !24 * https://deb.li/3OSw2
[19:10] <jbicha> We only offer Ubuntu Desktop ISOs for amd64 + arm64 right? is it doable to have epiphany in main to satisfy dependencies on other architectures but with documentation that it doesn't have official security support?
[19:30] <KGB-0> gnome-control-center ubuntu/master 3561f76 Marco Trevisan (Treviño) debian/patches/ series ubuntu/Allow-tweaking-some-settings-for-Ubuntu-Dock.patch * ubuntu-panel: Support Shell screen transition on theme change * https://deb.li/3DS4R
[19:54] <seb128> sarnold, mdeslaur, technically epiphany is only glue around webkitgtk which is already in main and on the ISO
[19:54] <sarnold> seb128: I thought we had gone to some effort to ensure it was never fed 'untrusted' html?
[19:54] <seb128> but yeah, the alternative option is to provide w3m or something as a webbrowser on those non desktopish architectures
[19:54] <sarnold> heh
[19:55] <seb128> the goal isn't to provide a desktop experience
[19:55] <sarnold> I like w3m myself.. but it's a bit of a stretch, yeah :)
[19:55] <seb128> it's just to make component mismatch deal with the fact that firefox as our preferred browser isn't available
[20:04] <KGB-2> gnome-control-center Sebastien Bacher 300664 * commented merge request !24 * https://deb.li/Gs3y