[05:46] <pieq> Hi everyone!
[05:47] <pieq> Question: I'm having troubles with the Firefox snap on 21.10. Namely, I cannot open files in /tmp/, or even files in my ~/.local/ directory. Either I'm told the file does not exist, or firefox does not have the right permissions (even though the file is chowned by me).
[05:48] <pieq> But when I run `ubuntu-bug firefox`, I'm told "firefox is provided by a snappublished by mozilla. Contact them via... for help". Is that what we should be doing from now on?
[06:04] <amurray> pieq: snap confinement means firefox has it's own private /tmp and so cannot see the real /tmp from the host system - similarly, snap confinement restricts access to all '.' (dot) directories / files to stop snaps getting arbitrary access to your ssh / gpg keys or other sensitive data that may be stored in these locations
[06:09] <jamesh> It's something that could work if it was using xdg-desktop-portal/xdg-document-portal to access the files
[06:09] <jamesh> that'd require changes in Firefox itself rather than something that oculd happen automatically
[06:44] <oSoMoN> good morning desktoppers
[06:51] <duflu> Morning oSoMoN 
[06:55] <pieq> amurray: thanks for the clarification! I've seen this issue on early attempts at snapping desktop apps (namely, GIMP) a few years ago. It's good to know the reason why, but it's still quite disturbing, as an end user, to see this kind of behavior: how am I supposed to know that (1) Firefox is running as a confined snap and (2) it has its own /tmp directory  when the error message is "I cannot find /tmp/this.html" even though I, as a user, can?
[06:56] <pieq> The firs tthing I might be tempted to do is `snap remove firefox && sudo apt install firefox`
[06:57] <oSoMoN> hey duflu 
[06:57] <oSoMoN> salut pieq 
[06:57] <oSoMoN> I'm seeing discussion about the firefox snap but am missing the backlog, can you fill me in?
[07:00] <pieq> oSoMoN: ah oui, désolé :)
[07:00] <pieq> 13:47:56 <pieq> Question: I'm having troubles with the Firefox snap on 21.10. Namely, I cannot open files in /tmp/, or even files in my ~/.local/ directory. Either I'm told the file does not exist, or firefox does not have the right permissions (even though the file is chowned by me). 13:48:44 <pieq> But when I run `ubuntu-bug firefox`, I'm told "firefox is provided by a snappublished by mozilla. Contact them via... for help". Is that what we should
[07:01] <pieq> (sorry for the poor formatting, oSoMoN)
[07:05] <pieq> amurray: just to be clear, I understand the rationale in terms of security, and I think it's a great asset of snaps and flatpaks, but security is always hard to sell to users when you take away usability at the same time :)
[07:07] <oSoMoN> pieq, agreed, that's poor UX on two fronts (opening files in unauthorized locations, and reporting bugs)
[07:07] <amurray> pieq: shared /tmp is a common source of vulns in applications and most users don't know about or use /tmp anyway so we figured it was a reasonable trade-off but I agree it could definitely be improved usability-wise
[07:07] <oSoMoN> pieq, FWIW we track all firefox snap related bugs on the upstream bug tracker at bugzilla.mozilla.org
[07:23] <oSoMoN> pieq, for the ubuntu-bug problem though, this is very ubuntu-specific, so if you don't mind can you please file a bug against the ubuntu source package (manually, at https://bugs.launchpad.net/ubuntu/+source/firefox/+filebug) ?
[07:23] <oSoMoN> I'll see how we can improve the situation
[07:27] <pieq> oSoMoN: this problem will happen more and more, as we have more snaps, right? Cause apport only supports debian packages... is there a plan to migrate apport so it can support snaps as well?
[07:30] <oSoMoN> pieq, no, apport has support for snaps, it's just that it's not hooked up properly for the firefox snap
[07:30] <jibel> morning all
[07:50] <jpnurmi> good morning
[07:59] <jibel> Hey jpnurmi 
[08:06] <jpnurmi> hey jibel
[08:24] <Nafallo> morning
[08:31] <oSoMoN> salut jibel, good morning jpnurmi & Nafallo 
[08:32] <jpnurmi> hey Nafallo and oSoMoN
[08:35] <duflu> Morning jpnurmi, jpnurmi, Nafallo 
[08:40] <seb128> goood morning desktopers!
[08:40] <oSoMoN> salut seb128, ça va?
[08:41] <jpnurmi> hey seb128
[08:41] <jpnurmi> and hey duflu
[08:44] <duflu> Morning seb128 
[08:49] <seb128> oSoMoN, salut! ça va, mais journée de babysitting en vue, S. a une conjonctivite bactérienne et la crèche préfère ne pas la prendre tant qu'on a pas vu le medecin pour avoir une crème... et toi, en forme ?
[08:50] <seb128> hey jpnurmi, duflu, how is it going?
[08:50] <oSoMoN> ouch :/ pas de babysitting, journée productive en perspective!
[08:55] <ricotz> hello desktopers :)
[08:55] <duflu> seb128, going well so far, you?
[08:55] <duflu> Hi ricotz 
[08:55] <oSoMoN> hey ricotz 
[08:57] <Nafallo> salut seb128 :-)
[08:58] <Nafallo> morning ricotz :-)
[08:58] <seb128> hey ricotz, Nafallo 
[09:00] <seb128> duflu, as I was saying in french, going to be another of those kids distracted days ;-/ the baby has a conjunctivitis and she is not welcome to the daycare until she sees the doctor and get some cream
[09:00] <seb128> but otherwise it's going fine enough :-)
[09:00] <KGB-2> vala tags baea5f7 Rico Tzschichholz upstream/0.54.5 * Upstream version 0.54.5 * https://deb.li/SWUI
[09:00] <KGB-2> vala upstream/latest 691e673 Rico Tzschichholz * pushed 19 commits (first 5 follow) * https://deb.li/3bq1A
[09:00] <KGB-2> vala upstream/latest f2fa29f Rico Tzschichholz tests/Makefile.am * tests: Add missing methods/parameter-ccode-type.vala * https://deb.li/3gPFe
[09:00] <KGB-2> vala upstream/latest c12d6d4 Rico Tzschichholz vapi/glib-2.0.vapi * glib-2.0: Always use the actual C type for CCode.array_length_type * https://deb.li/ixaN0
[09:00] <ricotz> hello duflu oSoMoN Nafallo seb128 :)
[09:00] <KGB-2> vala upstream/latest aa9f592 Alexander Kanavin vapigen/vapigen.m4 * vapigen.m4: use $PKG_CONFIG_SYSROOT_DIR * https://deb.li/kWQM
[09:00] <Nafallo> seb128: ice cream! :-D
[09:00] <KGB-2> vala upstream/latest 1eb0925 Rico Tzschichholz build-aux/git-version-gen * build: Update git-version-gen to latest upstream * https://deb.li/3Wqvj
[09:00] <KGB-2> vala upstream/latest 279fe4a Lorenz Wildberg tests/girwriter/ class-final.test combined.test * tests/girwriter: Use the actual expected output of our girwriter * https://deb.li/ePR4
[09:01] <KGB-2> vala pristine-tar 5212fa2 Rico Tzschichholz vala_0.54.5.orig.tar.xz.delta vala_0.54.5.orig.tar.xz.id * pristine-tar data for vala_0.54.5.orig.tar.xz * https://deb.li/3AanD
[09:02] <duflu> :(
[09:02] <duflu> re Seb
[09:09] <Nafallo> ugh. now that I checked what it was, ice cream is unlikely to help at all.
[09:09] <seb128> lol
[09:46] <pieq> oSoMoN: apport has support for snaps? Cause every time I tried to use ubuntu-bug with a snap, I got a similar error message, so I thought it just didn't have any support
[10:08] <ricotz> seb128, you probably noticed the vala commit spam above ;P, would you have time to upload vala 0.54.5-1?
[12:34] <seb128> pieq, the snap integration with ubuntu-bug isn't great but it exists. It relies on the contact information defined by the snap, if that's an upstream resource there isn't much it can do other than pointing you to the url. But for projects that use launchpad it works, try ubuntu-bug snap-store as an example
[20:30] <ricotz> seb128, this seems to require some action https://launchpad.net/ubuntu/+source/fwupd/1.7.1-1~ubuntu1
[20:30] <seb128> ricotz, see #ubuntu-release
[20:31] <ricotz> seb128, oops, what a timing
[20:31] <seb128> :-)