[02:18] <callmepk> good morning
[02:53] <donfede> o/
[05:21] <jibel> Good morning 
[05:54] <bittin> good morning
[05:59] <didrocks> good morning
[06:17] <jibel> salut didrocks 
[06:17] <jibel> hi bittin 
[06:17] <didrocks> hey jibel 
[06:19] <oSoMoN> good morning desktoppers
[06:19] <oSoMoN> happy Friday!
[06:19] <ricotz> good morning everyone
[06:20] <oSoMoN> hey ricotz 
[06:21] <didrocks> hey oSoMoN 
[06:21] <didrocks> morning ricotz 
[06:22] <oSoMoN> salut didrocks 
[06:27] <jibel> salut oSoMoN ricotz 
[06:30] <callmepk> hi jibel bittin didrocks oSoMoN ricotz 
[06:31] <didrocks> hey hey callmepk 
[06:35] <jibel> Hi callmepk 
[06:48] <ricotz> heya oSoMoN didrocks jibel callmepk 
[06:58] <oSoMoN> salut jibel, hey callmepk 
[07:46] <seb128> goood morning deskopers
[07:49] <didrocks> salut seb128 
[07:49] <seb128> didrocks, lut, bon vendredi ! en forme ?
[08:02] <laney> \0\
[08:05] <seb128> hey laney, happy friday! how are you?
[08:07] <ricotz> hello seb128 laney 
[08:08] <seb128> hey ricotz, happy friday! how is it going for you?
[08:09] <seb128> ricotz, oh, just saw your libreoffice upload, nice to see that gcc-8 workarounds the armhf issue
[08:09] <laney> hahahaHAHAHAH
[08:09] <laney> next we'll be bundling a snapshot of gcc
[08:10] <seb128> :)
[08:10] <laney> that's not entirely a joke really
[08:10] <bittin> :D
[08:10] <seb128> I'm sure Matthias is going to be pleased with that solution :p
[08:10] <laney> we can't just keep rolling back compilers
[08:10] <laney> because that bug isn't being worked
[08:10] <laney> hoepfully we can sort out some armhf access for ricotz 
[08:11] <seb128> right, let's see if we can escalade to foundations to get the gcc issue investigated
[08:11] <seb128> or that
[08:11] <laney> both :p
[08:11] <laney> also hey and happy friday!
[08:12] <ricotz> seb128, thanks, yeah, this is clearly a workaround
[08:13] <ricotz> without a proper way to debug I don't have a better solution :(
[08:14] <seb128> ricotz, do we have a testcase smaller than 'rebuild libreoffice'?
[08:14] <ricotz> what bugs me is that this doesn't happen in debian where the toolchain is kind of identical
[08:15] <ricotz> seb128, a minimized package is possible and you can see the failure in the build log
[08:15] <ricotz> test failures are only fatal on amd64 and arm64
[08:16] <oSoMoN> salut seb128, morning laney 
[08:18] <seb128> ricotz, if you could get a smaller testcase I could try to help doing a gcc bisect
[08:18] <ricotz> I assume armhf won't be dropped any time soon, like i386? ;P
[08:18] <laney> 早上好 oSoMoN 
[08:18] <seb128> it's just that if the test case is building gcc + libreoffice then it's going to take a day for each iteration
[08:18] <seb128> not likely no
[08:19] <seb128> and even if it was this cycle that's impacting SRU to older releases now
[08:19] <seb128> weird that it doesn't happen in Debian though
[08:20] <seb128> do we have difference of toolchain default flags? maybe we could try to see if one of those creates the issue?
[08:20] <ricotz> that would be a question for do_ko
[08:20] <ricotz> or how different are the armhf builders
[08:21] <sil2100> ricotz, seb128: hey! Sorry for not getting to you yesterday - let's maybe try going the Updates-only binary-copy-from-bileto approach for now
[08:22] <sil2100> But ultimately I'd just love figuring out what is busted in the new gcc-9 version
[08:22] <ricotz> sil2100, hi, the mentioned workaround is using gcc-8 on armhf which would work for hirsute too, if that is acceptable for a SRU
[08:26] <ricotz> sil2100, correct, I would have hoped that there might be a suspicious commit, which targets armhf, in the upstream log of that gcc update
[08:31] <sil2100> hm, I don't know about that, I'm always a bit weary as gcc-8 is in universe
[08:31] <didrocks> seb128: ça va :)
[08:31] <didrocks> hey laney 
[08:34] <laney> おはようございます didrocks!
[08:37] <didrocks> laney: pronounce it 'aaaaaaaaaas' :)
[08:38] <laney> :D
[08:41] <GunnarHj> Good morning all!
[08:41] <GunnarHj> Wondering if someone can shed some light on a "missing build on" issue.
[08:41] <GunnarHj> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ibus-keyman
[08:41] <GunnarHj> Short story:
[08:41] <GunnarHj> - Previous version: "Architecture: any", but s390x failed.
[08:41] <GunnarHj> - Now the maintainer stated all Debian's official archs except for s390x.
[08:41] <GunnarHj> - It complains since riscv64 built successfully previously and is now excluded.
[08:41] <GunnarHj> I can probably fix it by adding riscv64 to the "Architecture:" list (or return to "any").
[08:41] <GunnarHj> But are there other options? Would removing the present riscv64 build from impish help?
[08:44] <seb128> GunnarHj, hey, that would be an option but we are going to want a working desktop on riscv64 maybe at some point if that package is useful I would just ask if Debian would be wanting to add riscv64 archs list
[08:47] <GunnarHj> seb128: I'm sure the latter is an option, and will do so. Just curious about how it works. Would it have possible to add some kind of exception to britney?
[08:47] <GunnarHj> s/have/have been/
[08:48] <seb128> GunnarHj, no, but it would be up to any archive admin to delete the riscv64 binaries from impish (if there is no rdepends blocking removal)
[08:48] <GunnarHj> seb128: I see. Thanks for your advice!
[08:49] <seb128> GunnarHj, I could do that for now if you want to see it unblocked but please still try to get riscv64 added
[08:50] <GunnarHj> seb128: I'll do. The package is team maintained, so I can do a team upload.
[08:57] <laney> jamesh: do you know offhand if xdp_portal_set_wallpaper() works for us?
[08:57] <laney> nautilus has optional support to use it, wondering whether to enable that
[08:57] <laney> would require MIRing libportal ...
[09:05] <jamesh> laney: I'll have a look after the meeting
[09:05] <laney> ack
[09:05] <laney> I think it's alright to keep it off for now, the current way should be OK
[09:06] <jamesh> laney: wouldn't that only make sense for Nautilus running within a sandbox?
[09:07] <laney> It's mainly for that
[09:07] <laney> just that they enabled it by default, so if it works we could build with it too
[09:09] <jamesh> there has definitely been some motion towards using xdg-desktop-portal for unconfined apps, as it provides desktop-neutral APIs
[09:10] <jamesh> e.g. Firefox doing screen sharing on Wayland
[09:11] <jamesh> I'd imagine the xdg-desktop-portal-gtk backend should be fine for our GNOME install
[09:13] <laney> thanks
[09:13] <laney> I'll turn it off for now. If they stop having 'traditional' fallbacks then we'll need to reconsider
[09:14] <jamesh> It wouldn't be the worst thing in the world to bring in libportal.  IIRC, most of the xdg-desktop-portal tests aren't built if it isn't available.
[09:18] <laney> we can certainly add build-depends, runtime depends in main would require a MIR
[09:23] <jamesh> I'm pretty sure xdg-desktop-portal's libportal deps don't leak past the tests
[09:36] <jamesh> laney: so thinking more about it, Nautilus's use of libportal probably aligns closer with e.g. Firefox's screen sharing use: they want a cross desktop API to set the wallpaper so that they don't need to support N desktop environments
[09:37] <jamesh> laney: xdg-desktop-portal-gtk should definitely handle our default Ubuntu desktop, so it is probably makes sense to enable the Nautilus code (if it is an optional feature)
[09:40] <laney> jamesh: good point. the fallback code is writing to a GSetting so it is GNOME specific
[09:40] <laney> I'd prefer not to block the update on the MIR but we can file it and then enable once that's all approved
[09:41] <seb128> laney, I can do the MIR paperwork if you wish
[09:41] <jamesh> so if you wanted to run Nautilus on KDE Plasma, it would be able to set the background in the appropriate way via xdg-desktop-portal-kde
[09:41] <laney> seb128: sure
[09:42] <laney> it's the approving side that might take some time though :p not as long as in the past with the #newandimprovedmirteam
[09:44] <jamesh> I wouldn't be surprised to see more apps use libportal as time goes by, so it doesn't seem like wasted effort
[09:44] <laney> indeed
[09:44] <laney> alright we have a plan!
[09:47] <seb128> laney, jamesh, the MIR might get blocked on https://github.com/flatpak/libportal/issues/33 to get resolved
[09:47] <ubottu> Issue 33 in flatpak/libportal "Is the API/ABI stable?" [Open]
[09:47] <gitlab-bot> flatpak issue 33 in libportal "Is the API/ABI stable?" [Open]
[09:47] <seb128> that's the reason Debian didn't move it out of experimental
[09:49] <jamesh> seb128: ah. I hadn't realised that.
[09:52] <seb128> also no tests which the MIR team isn't going to like
[09:54] <jamesh> seb128: the tests in xdg-desktop-portal are effectively libportal tests too
[09:54] <seb128> jamesh, they are not part of the libportal build though so wouldn't catch a regression in an update
[09:54] <jamesh> any tests in libportal that depended on xdg-desktop-portal would represent a circular dependency
[09:55] <jamesh> I'm not sure what the best option here is
[09:55] <seb128> ok, opened https://bugs.launchpad.net/ubuntu/+source/libportal/+bug/1932485
[09:55] <ubottu> Launchpad bug 1932485 in libportal (Ubuntu) "[MIR] libportal" [Undecided, New]
[09:55] <seb128> unsure if we should wait for the API stability question to be resolved before subscribing ubuntu-mir though
[09:55] <seb128> laney, ^ opinion?
[09:58] <seb128> jamesh, xdg-desktop-portal does have its tests set up as an autopkgtest but it doesn't depends on libportal? I'm unsure why the depends is not there, the tests do use libportal
[09:59] <jamesh> seb128: because we configure xdg-desktop-portal to not build with libportal
[09:59] <jamesh> (because it isn't in main)
[09:59] <seb128> ah
[09:59] <seb128> alright, so if it's promoted and we enable the option then the autopkgtest should cover libportal
[09:59] <laney> The -tests package could depend on it; that is in universe
[09:59] <seb128> which would block migration from a buggy package
[10:00] <seb128> the reason is probably that we sync from debian and libportal is not in unstable for the reason mentioned before
[10:00] <laney> if someone wanted to try a build with libportal turned on and check the Depends only ends up on x-d-p-tests, we could do that in experimental
[10:00] <jamesh> presumably we could enable libportal support in xdg-desktop-portal now
[10:00] <seb128> let me try
[10:01] <jamesh> as the test binaries end up in the xdg-desktop-portal-tests package, which is in universe
[10:01] <laney> It's probably OK for those two since they'll be developed closely together anyway
[10:01] <laney> but for random other packages I'd be less confident
[10:01] <laney> (in terms of API)
[10:01] <seb128> anyone upstream we know that we could ping to get a reply to the github issue?
[10:01] <jamesh> and I'd be more confident in main xdg-desktop-portal package if the extra tests are built and run
[10:13] <seb128> bah, so the package has a profile to build with libportal
[10:13] <seb128> $ DEB_BUILD_PROFILES=pkg.libportal.enable dpkg-buildpackage 
[10:13] <seb128> xdg-desktop-portal I mean
[10:14] <seb128> but tests seem to hang? or taking ages
[10:15] <seb128> it's blocked on PASS: test-doc-portal 4 /db/create_docs for like 5 minutes now
[10:16] <laney> :(
[10:20] <seb128> https://paste.ubuntu.com/p/TydQJdBdHy/
[10:20] <seb128> in the journal
[10:20] <seb128> kernel problem?
[10:38] <jamesh> seb128: looks like there's some activity on the libportal bug
[10:39] <seb128> 👍
[11:18] <KGB-0> nautilus pristine-tar 27ec19d Iain Lane nautilus_40.2.orig.tar.xz.delta nautilus_40.2.orig.tar.xz.id * pristine-tar data for nautilus_40.2.orig.tar.xz * https://deb.li/eYls
[11:19] <seb128> new nautilus \o/
[11:19] <KGB-0> nautilus upstream/latest ae9da8a Iain Lane * pushed 257 commits (first 5 follow) * https://deb.li/3a3aU
[11:19] <KGB-0> nautilus upstream/latest 885de25 António Fernandes (5 files in 2 dirs) * uncrustify: Enforce single space after control flow keywords * https://deb.li/rixA
[11:19] <KGB-0> nautilus upstream/latest 3c5c9d4 Dušan Kazik po/sk.po * Update Slovak translation * https://deb.li/3fCmi
[11:19] <KGB-0> nautilus upstream/latest b3d68fb Ondrej Holy data/meson.build * ci: Specify test dependencies to fix pipeline * https://deb.li/M7E0
[11:19] <KGB-0> nautilus upstream/latest cba5bee Ondrej Holy src/gtk/nautilusgtkplacesview.c * gtkplacesview: Update to the latest code * https://deb.li/i41u2
[11:19] <KGB-0> nautilus upstream/latest baf799d Ondrej Holy src/nautilus-file-operations.c * file-operations: Fix crashes when extracting encrypted archives * https://deb.li/77bV
[11:20] <KGB-0> nautilus tags 78aadd8 Iain Lane upstream/40.2 * Upstream version 40.2 * https://deb.li/3FYUg
[11:20] <KGB-0> gtk2 tags e3ec140 Sebastien Bacher ubuntu/2.24.33-2ubuntu1 * gtk+2.0 Debian release 2.24.33-2ubuntu1 * https://deb.li/aC5N
[11:20] <KGB-0> gtk2 ubuntu/master 2d2dc3f Sebastien Bacher * pushed 6 commits (first 5 follow) * https://deb.li/3u5Fx
[11:20] <KGB-0> gtk2 ubuntu/master 04bf214 Simon McVittie debian/ control control.in * Increase dependency on librsvg2-common from Suggests to Recommends * https://deb.li/3PAnI
[11:20] <KGB-0> gtk2 ubuntu/master c21af4e Simon McVittie debian/rules * d/rules: Build udeb with extra CPPFLAGS * https://deb.li/iUmRD
[11:20] <KGB-0> gtk2 ubuntu/master e51b069 Simon McVittie debian/patches/ series d-i/textlayout-Clamp-width-to-the-value-we-asked-for-as-a-hac.patch * udeb: Clamp text layout width to no more than was requested * https://deb.li/YrW1
[11:20] <KGB-0> gtk2 ubuntu/master 18375f8 Simon McVittie debian/changelog * Release to unstable * https://deb.li/3QNo2
[11:20] <KGB-0> gtk2 ubuntu/master 3407fba Sebastien Bacher debian/ (6 files in 3 dirs) * Merge branch 'debian/master' into ubuntu/master * https://deb.li/f59y
[11:22] <seb128> oSoMoN, sorry I only saw your ping from yesterday late ... what was the changes in gedit you asked about?
[11:23] <KGB-0> nautilus Iain Lane 244926 * commented merge request !10 * https://deb.li/3k3XM
[11:25] <KGB-0> gnome-shell-extension-gamemode tags 52aab5e Jonathan Carter upstream/5 * https://deb.li/p71R
[11:35] <seb128> oSoMoN, oh, probably require to update libtepl which isn't used anymore now?
[11:35] <seb128> in which case yes we should probably wait for a 41 tarball
[12:32] <oSoMoN> seb128, yes, that was my thinking
[12:33] <seb128> oSoMoN, +1
[12:33] <seb128> I just saw the trello comments
[13:03] <seb128> GunnarHj, hey, would you be interested to do the g-t/vte updates, or at least merge the current debian versions?
[13:07] <GunnarHj> seb128: Sure, I can do it if it can wait until sometimes next week.
[13:07] <seb128> GunnarHj, no hurry, thanks
[14:47] <KGB-2> pygobject tags 82762ee Sebastien Bacher upstream/3.40.1 * Upstream version 3.40.1 * https://deb.li/6I6h
[14:48] <KGB-2> pygobject upstream/latest c56c0ef Sebastien Bacher * pushed 44 commits (first 5 follow) * https://deb.li/39IyR
[14:48] <KGB-2> pygobject upstream/latest 1dd6dfd Christoph Reiter tests/test_gtk_template.py * gtk4: Skip template test for now * https://deb.li/3xDcD
[14:48] <KGB-2> pygobject upstream/latest d6e029c Christoph Reiter gi/overrides/Gtk.py tests/test_ossig.py tests/test_overrides_gtk.py * tests: various fixes for gtk4 * https://deb.li/il84z
[14:48] <KGB-2> pygobject upstream/latest 2ab352a Christoph Reiter gi/overrides/Gtk.py tests/test_overrides_gtk.py * Clean up Widget overrides * https://deb.li/iCR
[14:48] <KGB-2> pygobject upstream/latest d1221d0 Christoph Reiter gi/overrides/Gtk.py tests/test_overrides_gtk.py * overrides: Remove various overrides for gtk4 * https://deb.li/3xCMv
[14:49] <KGB-2> pygobject upstream/latest 0453702 Jean Felder gi/overrides/Gtk.py tests/test_overrides_gtk.py * gtk overrides: Make GTK4 widgets iterable * https://deb.li/b7Gz
[14:49] <KGB-2> pygobject pristine-tar 63c3df7 Sebastien Bacher pygobject_3.40.1.orig.tar.xz.delta pygobject_3.40.1.orig.tar.xz.id * pristine-tar data for pygobject_3.40.1.orig.tar.xz * https://deb.li/39Yjs