[05:51] <jibel> Good morning all
[06:16] <seb128> goood morning desktopers
[06:16] <jibel> salut seb128, ça va?
[06:16] <seb128> lut jibel , ouais, et toi ?
[06:18] <jibel> seb128, oui bien, le break d'hier a fait du bien, même si les activités sont plutôt limitées
[06:19] <seb128> :-)
[06:28] <RAOF> Aaaaah. colord built on s390x in the past because we didn't fail the build when it was totally broken!
[07:07] <duflu> Morning jibel and seb128 
[07:07] <duflu> Evening RAOF 
[07:10] <oSoMoN> good morning desktoppers
[07:14] <duflu> Morning oSoMoN 
[07:19] <didrocks> good morning
[07:21] <oSoMoN> good afternoon duflu 
[07:21] <oSoMoN> salut didrocks 
[07:21] <duflu> Hi didrocks 
[07:25] <didrocks> hey oSoMoN, duflu 
[08:05] <jibel> salut duflu oSoMoN didrocks 
[08:05] <didrocks> salut jibel 
[08:06] <oSoMoN> salut jibel 
[08:16] <marcustomlinson> morning jibel seb128 duflu oSoMoN didrocks
[08:16] <oSoMoN> good morning marcustomlinson 
[08:16] <duflu> Hi marcustomlinson 
[08:17] <didrocks> hey marcustomlinson 
[08:45] <seb128> hey duflu, oSoMoN, didrocks, marcustomlinson, RAOF, how are you?
[08:45] <oSoMoN> salut seb128 
[08:46] <oSoMoN> I'm good, almost over that cold, and you?
[08:46] <seb128> RAOF, s390x/desktop isn't a thing so probably not worth blocking on errors there
[08:46] <seb128> oSoMoN, tired but I'm fine otherwise!
[08:49] <duflu> seb128, suffering through another sinus headache as the weather changes again. But the good news is that both the graphics corruption issues of late have fixes on the way.
[08:49] <seb128> :-(
[08:49] <seb128> duflu, ah, nice
[08:50] <seb128> duflu, btw any chance I could convince you to spend some time on the dock code to try to fix bugs there? as you know we have several annoying bugs that turned out to be due to it and Marco is just swamped with other things
[08:50] <didrocks> hey seb128, good, and you?
[08:50] <seb128> didrocks, lut, ça va :)
[08:51] <didrocks> little one has running nose, feeling really tired, stomatch ache
[08:51] <didrocks> let’s see, Julie stayed at home
[08:51] <didrocks> and ofc he didn’t go to school
[08:51] <duflu> seb128, I know, but I'll see how things go this month. Only just getting back to trying to finish the outstanding performance branches
[08:52] <seb128> duflu, k, well the dock bugs are probably impacting more on the user experience than the performances at this point, but fair enough that you want to finish what you started
[08:53] <seb128> didrocks, good luck to him and you!
[08:53] <seb128> you plural :)
[08:53] <didrocks> thanks :)
[09:02] <RAOF> seb128: it's actually broken on all big-endian architectures, s390x just happens to be the only one we support 😀
[09:05] <marcustomlinson> seb128: hey I’m doing alright thanks. About as good as you sound ;)
[09:07] <Laney> yo
[09:07] <seb128> hey Laney, how are you
[09:07] <didrocks> hey Laney 
[09:07] <seb128> RAOF, sounds like it does need fixing :-)
[09:15] <seb128> jamesh, hey, so I talked with Ken a bit about the thunderbird issue and he said that might be an issue you have some clue about
[09:17] <Laney> hey seb128 hey didrocks 
[09:17] <Laney> I'm alright!
[09:17] <Laney> you?
[09:17] <jamesh> seb128: I'm in a meeting right now.  Can we talk in 15 minutes?
[09:17] <seb128> jamesh, snapd does try to use the portal but it gets that error
[09:18] <seb128> jamesh, sure, no hurry, I will write here, feel free to comment whenever works for you
[09:18] <seb128> ** (/usr/libexec/xdg-desktop-portal:53237): WARNING **: 10:17:28.305: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list
[09:18] <seb128> XDP: Rejecting open request as fd has no path associated to it
[09:18] <seb128> ignore the first line I think, I'm under a test env atm, but the XDP one is the issue I think
[09:22] <oSoMoN> yo Laney 
[09:22] <oSoMoN> hey jamesh 
[09:23] <seb128> Laney, I'm alright thanks :)
[09:25] <Laney> wassup oSoMoN 
[09:29] <oSoMoN> watching the game, having a… cup of tea
[09:29] <Laney> true
[09:32] <jamesh> hi oSoMoN 
[09:33] <Laney> so glad I left myself an XXX here's what you were trying to do when I left last night
[09:34] <Laney> would have totally forgotten
[09:35] <jamesh> seb128: the OpenURI.OpenFile() D-Bus method passes a file descriptor for the file it wants to open as proof the app can read the file.  x-d-p then does a readlink on /proc/self/fd/$number to get the file name, and checks to see whether it is the same file as the fd by comparing stat info.  What this probably means is that the path does not match.
[09:35] <jamesh> doh.  no seb
[09:38] <luna_> hellsworth kenvandine sadly missing your bof as thats my LAS voluenteer work shift
[09:45] <seb128> bah, that was not the best idea to try to install wpasupplicant from bionic on focal, locked myself out of the wifi, it took me a while to recover it!
[09:45] <seb128> jamesh, sorry I dropped off IRC due to my own stupidity :p
[09:45] <jamesh> seb128: the OpenURI.OpenFile() D-Bus method passes a file descriptor for the file it wants to open as proof the app can read the file.  x-d-p then does a readlink on /proc/self/fd/$number to get the file name, and checks to see whether it is the same file as the fd by comparing stat info.  What this probably means is that the path does not match.
[09:46] <jamesh> seb128: this is probably due to trying to open a file stored in the snap's private /tmp
[09:47] <jamesh> for Flatpaks they do support some path mapping, but that doesn't really help us since a regular user can't traverse /tmp/snap.$snap_name to see the private file
[09:47] <seb128> jamesh, the file is in /run/user/<uid>/... but I guess that has the same issue
[09:48] <seb128> hum, should not though
[09:48] <jamesh> seb128: I wouldn't expect that path to be a problem
[09:48] <seb128> that's not a private dir
[09:48] <jamesh> is this a doc portal path by any chance?
[09:48] <seb128> jamesh, it is
[09:48] <seb128> /run/user/1000/doc/7b39c39f/boarding-pass.pdf
[09:49] <seb128> well assuming the 'doc' dir is what you call doc portal path?
[09:49] <jamesh> yes
[09:49] <jamesh> can you read the data at that path?
[09:50] <seb128> yes
[09:50] <jamesh> (i.e. just trying to work out whether the data has been shared successfully)
[09:51] <seb128> $ strings /run/user/1000/doc/7b39c39f/boarding-pass.pdf
[09:51] <seb128> %PDF-1.4
[09:51] <seb128> 2 0 obj
[09:51] <seb128> etc
[09:51] <seb128> why is the path special?
[09:51] <seb128> e.g why is the portal refusing to open it? 
[09:54] <seb128> jamesh, oh, I can but
[09:54] <seb128> $ sudo cat /run/user/1000/doc/7b39c39f/boarding-pass.pdf
[09:54] <seb128> cat: /run/user/1000/doc/7b39c39f/boarding-pass.pdf: Permission denied
[09:55] <seb128> jamesh, which probably means the file portal can't read it?
[09:55] <seb128> also I've no idea why the tb attachment ends up in that directory...
[09:56] <jamesh> seb128: the doc portal is a fuse file system.  Unless you mess with /etc/fuse.conf, other users can't read from those mounts (even root)
[09:56] <jamesh> xdg-desktop-portal is a session service, so it is running as your user account
[09:56] <jamesh> so that shouldn't be the issue
[09:59] <jamesh> seb128: do you know where the doc portal path originated?
[10:32] <seb128> jamesh, sorry got pulled away from the computer
[10:32] <seb128> jamesh, no, I don't, as said the user scenario is
[10:32] <seb128> * start thunderbird as a snap
[10:32] <seb128> * compose a new mail
[10:32] <seb128> * add an attachement, try to open it from the composer window
[11:00] <popey> seb128 morning. I filed a bug against snap-store, but it might need an 'affects' snappy, because I don't know where you fix this. bug 1903977  :) it's fun. briefly talked about it with Ken and Sergio earlier in the week. 
[11:01] <popey> seb128 and thanks to your comment on bug 1903687 i realised I can reproduce that now! :D
[11:03] <seb128> popey, interesting issue for apps which are services :/
[11:03] <popey> Yeah, i guess after a week it'll get force-updated anyway
[11:03] <seb128> that's something
[11:03] <seb128> but maybe we should teach snap-store to exist if there is a pending refresh waiting
[11:04] <seb128> I mean exist when closing the UI
[11:04] <seb128> or to display an in app banner like firefox does
[11:04] <popey> yeah, I dunno what the best course of action is there, some thought needed
[11:04] <seb128> 'an update is available, do you want to apply it and restart'
[11:04] <popey> we launch snap-store on login too, so not a lot of time between boot and login to sneak a refresh in
[11:06] <seb128> right
[11:07] <popey> in edge, snap-store shows nothing below editors picks for me, do you see that too seb128?
[11:08] <popey> https://imgur.com/a/oGtjJHc
[11:14] <jamesh> seb128: sorry, was out for a walk while there's still light.  I'll see if I can come up with a simpler reproducer based on that.
[11:15] <seb128> jamesh, thanks
[11:15] <seb128> popey, it was working yesterday, now it seems to hand on start
[11:15] <seb128> but we had reports of that issue in the past with gnome-software
[11:15] <seb128> could be that it fails to load the packagkit data or appstream or something... 
[11:16] <seb128> if you start for a command line the output probably gives some clues
[11:16] <seb128> oh, it started and has the same issue :/
[11:17] <seb128> Gs  failed to get categories: no categories to show
[11:17] <seb128>  Gs  not GsPlugin error snapd-error-quark:10: status-code=500 kind=(null) message=cannot sections: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/sections"
[11:17] <seb128> that url isn't working, store issue?
[11:17] <seb128> (same in firefox)
[11:31] <popey> someone tweeted earlier that they couldn't see some categories, will check with store team
[11:32] <popey> oh, no need. https://status.snapcraft.io/
[11:32] <popey> api is down
[11:56] <Trevinho> tjaalton: hey, I was looking into SSSD for smartcard access, now groovy and hirsute are fine... The problem is focal, where SSSD is compiled with NSS support, and not openssl... Which leads to using a NSS database that is never set in debian/ubuntu (/etc/pki/nssdb) which indeed we could create, but... I was wondering, would you think could be possible to have
[11:56] <Trevinho> https://salsa.debian.org/sssd-team/sssd/-/commit/f4f7bfee91e9aa929585b95e5c579597d0ab156b backported or.... Hack the deb to build p11_child at least (don't think is used with anything else) to use openssl?
[11:57] <Trevinho> I was wondering if there's some other things that may involve or not...
[11:57] <tjaalton> I'm fine with that, but I'm not the maintainer on ubuntu anymore ;)
[11:59] <Trevinho> tjaalton: ah I see... Well as that would make things nicer, who is it? As I don't see other than you in the recent changelog entries
[11:59] <tjaalton> the server team owns it these days, maybe ask ahasenack
[11:59] <tjaalton> right, it's synced from debian
[11:59] <Trevinho> but of course for focal they'll have to handle it
[11:59] <tjaalton> yep
[11:59] <Trevinho> i see, thanks
[11:59] <tjaalton> they're well on top of things wrt sru's
[12:00] <Trevinho> tjaalton: wit your hat would you think would be break something else? As, the only things I see coudl break are things which we don't support anyways
[12:00] <tjaalton> only thing I can think of is if that will pass the sru team ;)
[12:01] <Trevinho> tjaalton: well, that's my concern as well
[12:01] <Trevinho> but well...
[12:01] <Trevinho> we can explain
[12:01] <tjaalton> right
[12:01] <Trevinho> *maybe* :D
[12:01] <tjaalton> the other option would be uglier?
[12:02] <Trevinho> tjaalton: well users will have to create  a nss db in /etc/pki/nsssdb, adding their card module (or p11-kit proxy) and their CA certificates there... WHich will then break in next SRU as well, so since we're creating this for the first time, I'd like to have a solution that work in a stable way for the future
[12:03] <Trevinho> s/next SRU/next LTS/
[12:04] <Trevinho> ideally I think I could just make that module to compile with openssl, and leave the rest as it is, but not sure it would be nice
[12:04] <tjaalton> right
[12:09] <KGB-2> mutter ubuntu/focal 42cf238 Gunnar Hjalmarsson debian/ changelog patches/series patches/Fixes-for-devices-not-picking-config-in-X11-session.patch * Fixes for devices not picking config in X11 session * https://deb.li/3pVdn
[13:34] <hellsworth> good morning desktopers
[14:04] <luna_> hello hellsworth will try to follow along to the Flutter Snapping BoF as i am helping with moderating the room, even copied some boilerplate dart and flutter from Digital Ocean Blog :D
[14:04] <luna_> https://www.digitalocean.com/community/tutorials/flutter-your-first-flutter-app
[14:04] <hellsworth> ok great
[14:17] <GunnarHj> seb128: Does this MR make sense?
[14:17] <GunnarHj> https://code.launchpad.net/~gunnarhj/britney/+git/hints-ubuntu/+merge/393650
[14:22] <seb128> GunnarHj, ask #ubuntu-release, but I think they are likely to prefer to see the bug fixed since it's real rather than worked around
[14:24] <seb128> GunnarHj, I retried with the archive gtk version on https://autopkgtest.ubuntu.com/packages/i/isenkram/hirsute/amd64 and you can see it failed so it's not a regression in gtk so you can argue they should skip that result to let gtk migrate
[14:25] <GunnarHj> seb128: Fixed it better, of course, but that has to be done by the maintainer or someone else with the sufficient knowledge. My thought was to prevent it from blocking migration of several packages in the meantime.
[14:27] <seb128> GunnarHj, well you can try asking them :)
[14:27] <seb128> meanwhile gtk should be possible to skip and unblock since a retry of release showed the same issue
[14:35] <GunnarHj> seb128: Asked at #ubuntu-release. Are there other means to unblock e.g. gtk?
[14:55] <luna_> snapcraft
[14:55] <luna_> /snap/snapcraft/5737/snap/command-chain/snapcraft-runner: 3: exec: /snap/snapcraft/5737/usr/bin/python3: not found
[14:55] <luna_> :(
[15:01] <seb128> GunnarHj, no, but wait I'm sure someone will reply
[15:01] <seb128> luna_, on what distribution and serie?
[15:02] <luna_> seb128: Rolling Rhino, might be my fault however has done a lot of wierd and stupid things
[15:05] <luna_> so um latest 21.04 Devel 
[15:05] <jibel> snapcraft 5737 works fine for me on hirsute
[15:06] <luna_> jibel: guess its me that done something stupid then
[15:12] <luna_> yep it worked in a VM so its me that done something wierd
[16:09] <seb128> Saviq, is that expect that multipass purge makes my wifi reconnect?
[16:10] <seb128> or is that just notification noise because an extra interface is changing?
[16:11] <seb128> right, seems rather just noise and no real disconnect
[16:29] <juliank> didrocks: jibel: I added a grubzfs-testsuite task for bug 1899372, as we didn't card it, this might be something you want to look at
[16:31] <didrocks> juliank: is separate /usr something that we support?
[16:31] <didrocks> I read the contrary on #u-meetings?
[16:31] <didrocks> "So this is an abnormal setup and we'll pass on fixing it. I guess it might be something for the desktop team."
[16:31] <didrocks> if this is something foundation consider abnormal, should we fix it then?
[16:32] <juliank> didrocks: I don't know about zfs, but we do for normal systems
[16:32] <juliank> I don't think we give people the option to configure zfs systems with separate /usr, but I don't know
[16:32] <didrocks> we don’t, but people can install it manually. so in case
[16:33] <didrocks> ack in any case, thanks for the head’s up
[16:33] <didrocks> but I thought we followed the https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
[16:33] <juliank> our requirement is that /usr is mounted in the initramfs
[16:34] <didrocks> unsure ZFS initramfs script does mount /usr in initramfs though (outside of this grub issue)
[16:34] <didrocks> I wonder how we can fix the issue, but it should be doable