[00:00] jbicha: ok, so opencv is getting miscompiled by gcc12, which in turn is causing the gst-plugins-bad1.0 failures, building opencv with gcc 11 fixes both issues [00:10] thanks for figuring that out :) [02:24] gnome-initial-setup pristine-tar 88d28b6 Jeremy Bicha gnome-initial-setup_43~beta.orig.tar.xz.delta gnome-initial-setup_43~beta.orig.tar.xz.id * pristine-tar data for gnome-initial-setup_43~beta.orig.tar.xz * https://salsa.debian.org/gnome-team/gnome-initial-setup/-/commit/88d28b6 [02:24] Commit 88d28b6 in gnome-team/gnome-initial-setup "pristine-tar data for gnome-initial-setup_43~beta.orig.tar.xz" [02:24] gnome-initial-setup upstream/latest f45a331 Jeremy Bicha * pushed 78 commits (first 5 follow) * https://deb.li/dcX1 [02:24] gnome-initial-setup upstream/latest e1e9b5d Danial Behzadi po/fa.po * Update Persian translation * https://deb.li/31XLN [02:24] gnome-initial-setup upstream/latest 814355e Piotr Drąg po/POTFILES.in * Update POTFILES.in * https://deb.li/3pBWV [02:24] gnome-initial-setup upstream/latest 2da4ac3 Kukuh Syafaat po/id.po * Update Indonesian translation * https://deb.li/ijOVg [02:24] gnome-initial-setup upstream/latest ef95b75 Hugo Carvalho po/pt.po * Update Portuguese translation * https://deb.li/xbpi [02:24] gnome-initial-setup upstream/latest c0ebe04 Danial Behzadi po/fa.po * Update Persian translation * https://deb.li/3lXbh [02:28] gnome-online-accounts signed tags 91a5527 Jeremy Bicha upstream/3.45.2 * Upstream version 3.45.2 * https://deb.li/scNj [02:28] gnome-online-accounts pristine-tar adb63d0 Jeremy Bicha gnome-online-accounts_3.45.2.orig.tar.xz.delta gnome-online-accounts_3.45.2.orig.tar.xz.id * pristine-tar data for gnome-online-accounts_3.45.2.orig.tar.xz * https://deb.li/Qpc [02:28] gnome-online-accounts upstream/latest b3d1665 Jeremy Bicha * pushed 47 commits (first 5 follow) * https://deb.li/3nXER [02:28] gnome-online-accounts upstream/latest e1332da Paolo Bonzini src/examples/meson.build * do not install examples * https://deb.li/cXVx [02:28] gnome-online-accounts upstream/latest f81441b Paolo Bonzini .gitlab-ci.yml * add frontend-only build to CI * https://deb.li/39FlE [02:29] gnome-online-accounts upstream/latest 67c4eed Paolo Bonzini meson.build src/examples/meson.build src/meson.build * examples can be compiled even if !enable_goabackend * https://deb.li/3x2gl [02:29] gnome-online-accounts upstream/latest d150678 Paolo Bonzini doc/goa-sections.txt * remove more vestiges of GoaOAuthProvider * https://deb.li/ilcII [02:29] gnome-online-accounts upstream/latest bbdfdb8 Milan Crha src/goabackend/goagoogleprovider.c * Update Google OAuth2 for upcoming changes * https://deb.li/3cc9F [02:39] gnome-online-accounts ubuntu/master 5baa36f Jeremy Bicha * pushed 66 commits (first 5 follow) * https://deb.li/3C29N [02:39] gnome-online-accounts ubuntu/master 23665d4 Emmanuele Bassi NEWS * Update for 3.45.1 release * https://deb.li/3PBxD [02:39] gnome-online-accounts signed tags d632e0b Jeremy Bicha ubuntu/3.44.0-1ubuntu1 * gnome-online-accounts Debian release 3.44.0-1ubuntu1 * https://deb.li/v2Nv [02:39] gnome-online-accounts ubuntu/master 7874b44 Emmanuele Bassi meson.build * Post-release version bump to 3.45.2 * https://deb.li/snSV [02:39] gnome-online-accounts ubuntu/master b9b8c55 Milan Crha src/goabackend/goautils.c * goautils: Turn runtime warnings into debug prints, which they really are * https://deb.li/36Fng [02:39] gnome-online-accounts ubuntu/master 05fb1f0 Nart Tlisha po/ LINGUAS ab.po * Add Abkhazian translation * https://deb.li/xn1z [02:39] gnome-online-accounts ubuntu/master 1a7adf8 Nart Tlisha po/ab.po * Update Abkhazian translation * https://deb.li/3Krxs === guiverc2 is now known as guiverc [06:02] morning [06:21] good morning [06:38] good morning desktoppers [06:39] salut oSoMoN [06:41] salut didrocks, ça va? [06:50] oSoMoN, got the Firefox 104 update today :) [06:56] goood morning desktopers [07:00] oSoMoN: ça va, et toi ? [07:00] hey seb128 [07:03] didrocks, bien, merci! [07:03] salut seb128 [07:03] and good morning bittin [07:04] Hi bittin, didrocks, oSoMoN, seb128 [07:04] hey duflu [07:04] hey duflu [07:07] lut didrocks, oSoMoN, duflu, how are you? [07:09] seb128, pretty good. You? [07:12] seb128: FYI, I let you promote lerc/.*pixbuf.*loader, just did the final ACK on the MIRs [07:13] didrocks, 👍 [07:13] duflu, I'm alright, wish it would get a bit colder though [07:19] didrocks, what's the status of iwd and ell from a MIR team perspective, ready as well? security team gave a +1 [07:22] Good morning all [07:22] seb128: that wasn’t discussed yesterday, I can have a look [07:22] do you have the bug # handy? [07:23] Morning jibel [07:23] didrocks, bug #1971739 [07:23] Bug 1971739 in iwd (Ubuntu) "[MIR] iwd" [Undecided, In Progress] https://launchpad.net/bugs/1971739 [07:24] and https://bugs.launchpad.net/ubuntu/+source/ell/+bug/1971738, got them [07:24] Launchpad bug 1971738 in ell (Ubuntu) "[MIR] ell" [High, In Progress] [07:25] seb128: I guess you can change https://bugs.launchpad.net/bugs/1956950 iwd status to fixed released too? [07:25] Launchpad bug 1956950 in iwd (Ubuntu) "iwd FTBFS with LTO enabled" [Low, Confirmed] [07:26] ah no, it has been added there [07:26] I don’t see anything mentioned on the iwd bug that the LTO issue was fixed? [07:28] hey jibel [07:28] didrocks, sorry, it seems I failed to upload my change before holidays, I'm still struggling with restoring things in memory, doing that now [07:29] I just noticed that security team gave a +1 and ff is tomorrow so was wondering if we still could do it [07:29] no worry, just FYI, it’s the third time in 2 days where desktop is asking for the status of a MIR when there is an action pending on us [07:30] so, I think we should get better at this [07:30] indeed, my fault here for sure [07:30] salut jibel [07:56] oSoMoN or someone else, do you have some hints on launchpad build setup for aarch64 snap? [08:05] lissyx, do you mean on the build environment? [08:05] yeah [08:06] how does it performs it, VM ? real hw? what are the disk / cpu / ram specs ? [08:11] I'm not sure there are public specs, the folks on #launchpad might be able to help [08:49] oSoMoN, for https://github.com/snapcore/snapd/pull/11025#issuecomment-1202275770 where I would need to create symlinks [08:49] Pull 11025 in snapcore/snapd "interfaces: Allow access to hunspell dictionaries for spellchecking" [Open] [08:49] oSoMoN, when/where would be the best place to perform that? [08:55] lissyx, that's a tricky question. If it doesn't impact startup time significantly, then in the launcher script. Otherwise, probably in a hook (configure hook?, see https://snapcraft.io/docs/supported-snap-hooks) [10:40] mutter ubuntu/master f6863e5 Jeremy Bicha (574 files in 48 dirs) * Merge tag 'debian/43_beta-3' into ubuntu/master * https://deb.li/iUI7s [10:40] mutter ubuntu/master 75b9dbd Jeremy Bicha debian/patches/ubuntu/x11-Add-support-for-fractional-scaling-using-Randr.patch * Refresh x11-Add-support-for-fractional-scaling patch * https://deb.li/lwTC [11:47] gnome-software signed tags ab77add Jeremy Bicha upstream/43_beta * Upstream version 43~beta * https://deb.li/371eI [12:48] seb128: I ran git clone lp:software-properties and grepped for snap. There's nothing there. Can we drop the snap library dependency there? [12:49] I'm working on a snapd-glib transition as part of the libsoup3 fun [12:52] jbicha, yes, it was used for livepatch before migrating to 'ua' [13:08] oSoMoN, given it would just be about listing dictionaries on the system and doing a few symlinks with hunspell snap, I guess it should be pretty fast? [13:11] lissyx, it should be, but it will have to be measured to make sure the overhead is acceptable [13:11] but https://github.com/snapcore/snapd/pull/11025#issuecomment-1202275770 [13:11] Pull 11025 in snapcore/snapd "interfaces: Allow access to hunspell dictionaries for spellchecking" [Open] [13:11] this mentions using the mount-control interface [13:11] the doc there https://snapcraft.io/docs/mount-control-interface says it does not autoconnect? [13:12] from https://snapcraft.io/docs/interface-management#heading--auto-connections does it means once it is installed from the snap store, we can have it autoconnect ? [13:14] lissyx, I'm not sure I understand why mount-control would be needed [13:15] that is what is suggested to be able to discover host hunspell dictionnaries [13:15] and then use this list to symlink those dics in the hunspell snap [13:15] ah, right [13:16] sorry I misread the suggestion [13:16] this could also be achieved using the system-files interface, I think [13:17] similarly to how firefox is allowed to read the host's /etc/firefox/policies directory [13:18] it could be allowed to read the host's /usr/share/hunspell, and then if it sets DICPATH to point to some other directory there shouldn' [13:18] there shouldn't be any interference [13:18] let me ask mardy on that PR [13:25] right now I have a very simple problem [13:25] I have no idea how to perform the connection :) [13:26] ah it seems :mount-control ? [13:27] but "snap run --shell firefox", I can't see $SNAP_COMMON/host-hunspell [13:33] oSoMoN, this mount-control interface is very unclear in how to be used [13:33] mount command does not work [13:34] snapctl mount does not work [13:34] both complain I'm not root, and sudo is blocked within the snap [13:45] (even within firefox.launcher) [13:48] lissyx, the interfaces aren't done from within the snap, they are things declared in the snapcraft.yaml and managed by snapd [13:48] seb128, I declared it [13:48] seb128, I plugged it [13:48] seb128, the doc says it is up to the snapped application to maintain the mount point [13:50] lissyx, what are you trying to mount and where? [13:56] I wonder if mardy's advice was wrong there, the mount-control interface seems to be about mounting devices? [13:58] or is that because it comes from another snap so technically is a mount? [13:58] lissyx, https://forum.snapcraft.io/t/using-the-snapctl-tool/15002#heading--mount-control has snapctl examples of how to do a mount [14:02] seb128, yes, but those commands are wrong [14:02] :( [14:03] sudo snapctl mount --persistent /usr/share/hunspell $SNAP_COMMON/host-hunspell [14:03] maybe write on the discourse post to say so [14:03] I did [14:03] snapctl mount inside the snap itself cannot work because of sudo [14:03] and the doc says the app has to take care of that [14:03] that sounds completely contradictory to me [14:05] not on discourse, on github [14:05] I dont have a discourse account [14:06] lissyx, discourse use the ubuntu sso I think? [14:06] I tried to, it refused somehow [14:06] :( [14:06] honestly being blocked on that is really not what I anticipated [14:06] anyway I think mardy was wrong there, I pinged him on our internal channel [14:07] I think as well [14:07] but that's not really good news, because it means the current PR still needs to be merged before I can move forward [14:07] lissyx, did you try to do something like https://github.com/canonical/firefox-snap/blob/stable/snapcraft.yaml#L80 ? [14:08] what do you mean? [14:08] use system-files interface to access hunspell? [14:08] use the system-files and give access to /usr/share/hunspell [14:08] no, because I assumed the existing PR was the reason this was not done [14:09] well, depends what you are trying to do [14:09] I though you were trying to read the system files to do the symlink/copy from the content [14:10] I'm doing what mardy said [14:10] so yes, reading the system files to do the symlinks [14:10] but the PR was opened to grant access to /usr/share/hunspell; so I assumed a system-files would just not work [14:11] I pinged him, I wonder if he did a thinko by writing mount-control instead of system-files [14:11] they nacked the PR on the basis that they didn't trust the format to not change or the location to be standard accross distro, from memory [14:12] https://github.com/snapcore/snapd/pull/11025#issuecomment-964647835 [14:12] Pull 11025 in snapcore/snapd "interfaces: Allow access to hunspell dictionaries for spellchecking" [Open] [14:14] so they suggesting getting the list from the system but the content from another snap which is targetting the same snap core serie to ensure we puill content which is compatible with the hunspell version in use [14:14] suggested [14:14] at least that was my understanding [14:14] yes [14:15] that's not the problem [14:15] this part is clear [14:15] there it is also mentionned to mount from the host [14:15] so we are back to mount [14:15] which I think is the thinko, by mardy isn't around atm it seems [14:15] I've searched a lot on other snap's usage of mount-control but I found nothing [14:15] the intend is to make the content of /usr/share/hunspell available in the snap [14:15] and I think system-files is the right way [14:16] not mount-control [14:16] so given the doc, I have no idea how this is intended to be used besides declaring in the snapcraft.yaml [14:16] but let's wait for mardy to clarify [14:16] gnome-bluetooth3 signed tags 12fa577 Jeremy Bicha upstream/42.3 * Upstream version 42.3 * https://deb.li/NZG0 [14:17] gnome-bluetooth3 upstream/latest 1addee4 Jeremy Bicha * pushed 11 commits (first 5 follow) * https://deb.li/igVW2 [14:17] gnome-bluetooth3 upstream/latest 347f4fc Maximiliano Sandoval R sendto/ main.c meson.build * sendto: Initialize libadwaita * https://deb.li/2ZoV [14:17] gnome-bluetooth3 upstream/latest e9b14be Maximiliano Sandoval R sendto/main.c * sendto: Add margins to window * https://deb.li/3hVEg [14:17] gnome-bluetooth3 upstream/latest 7970623 Nart Tlisha po/ LINGUAS ab.po * Add Abkhazian translation * https://deb.li/8cwN [14:17] gnome-bluetooth3 upstream/latest e6f6f4d Nart Tlisha po/ab.po * Update Abkhazian translation * https://deb.li/3oMex [14:17] gnome-bluetooth3 upstream/latest 81ffe36 Bastien Nocera lib/bluetooth-client.c * lib: Better API docs for _connect_service() API * https://deb.li/SM6y [14:17] gnome-bluetooth3 pristine-tar a709cbe Jeremy Bicha gnome-bluetooth3_42.3.orig.tar.xz.delta gnome-bluetooth3_42.3.orig.tar.xz.id * pristine-tar data for gnome-bluetooth3_42.3.orig.tar.xz * https://deb.li/3zZI4 [14:18] seb128, where am I supposed to see the system-files once within the snap? [14:18] there's no /usr/share/hunspell [14:21] lissyx, it should be in the same location, did you snap connect firefox:? [14:22] lissyx, I don't really understand the issue mardy pointed out with /usr being a mount [14:22] I'm trying to get him to join here [14:22] I dont see anything in snap connections firefox for a system-files of hunspell [14:23] maybe reusing the same connector name was a poor diea [14:23] did you add a plug [14:23] hunspell: [14:23] interface: system-files [14:23] read: [hunspell] [14:23] or similar? [14:23] then rebuilt the snap? [14:24] yes [14:25] hi seb128 :-) [14:25] hey mardy, thanks for joining! [14:25] so yes name reuse is a poor idea [14:25] lissyx, ^ mardy should be able to help you better than me [14:26] even after "snap connect firefox:hunspell-host :system-files" I have no /usr/share/hunspell [14:26] mardy, I don't understand why you suggested mount-control, we should be able to mount /usr/share/hunspell from the host using system-files no? [14:26] i dont think that can work, there are namespaces involved and /usr comes from the core snap [14:26] so system-files wont gain you what you want here [14:27] you need *something* that bind mounts the hosts dir on top of the core snaps dir ... (and creates a mountpoint etc) [14:27] yes, that's what mardy explained at https://github.com/snapcore/snapd/pull/11025#issuecomment-1225787194 [14:27] Pull 11025 in snapcore/snapd "interfaces: Allow access to hunspell dictionaries for spellchecking" [Open] [14:28] that's quite limiting :( [14:28] ogra, yes, read above? [14:28] lissyx, what error do you get trying to use snapctl mount? [14:28] maybe share the command and output here for mardy and ogra [14:28] seb128, where am I supposed to do the snapctl mount [14:28] seb128, lissyx: the /usr seen by the snap is not the host's, taht's the problem. It sees the /usr from the base snap (grp ^base /snap/firefox/current/meta/snap.yaml) [14:28] and with what arguments [14:28] from some script ... ? [14:28] tracker upstream/latest 68a59cd Jeremy Bicha * pushed 145 commits (first 5 follow) * https://deb.li/aM0E [14:28] or hook [14:28] I did that, above [14:28] tracker upstream/latest 87d5b79 Carlos Garnacho src/libtracker-sparql/bus/tracker-bus-cursor.c * libtracker-sparql/bus: Initialize string length out value in all paths * https://deb.li/3MZCe [14:28] ogra, should it work from a snap run --shell ? [14:29] snapctl mount refuses to run unless root [14:29] tracker upstream/latest 39d54f1 Carlos Garnacho src/libtracker-sparql/bus/tracker-bus-cursor.c * libtracker-sparql/bus: Check errors and return values reading cursors * https://deb.li/IZAD [14:29] tracker upstream/latest 8258631 Carlos Garnacho src/libtracker-sparql/bus/tracker-bus-cursor.c * libtracker-sparql/bus: Validate column offsets in bus cursors * https://deb.li/3eVhz [14:29] sudo does not seems to be expected to work within the snap [14:29] tracker upstream/latest edbbea3 Carlos Garnacho src/libtracker-sparql/bus/tracker-bus.c * libtracker-sparql/bus: Check return value of g_dbus_message_to_error() * https://deb.li/3kciR [14:29] hmm, i wonder why ... given snapd is running suid you should not need root explicitly [14:29] tracker upstream/latest a048662 Sam Thursfield src/libtracker-sparql/bus/ tracker-bus-cursor.c tracker-bus.c * Merge branch 'wip/carlosg/bus-fixes' into 'master' * https://deb.li/pVGn [14:29] lissyx, can you share the declaration you did in the snapcraft.yaml and the cmd/error? [14:29] (though i admittedly never used mount-control outside of Ubuntu Core (where i use it from daemon snaps only ... that run as root) [14:30] ... but mardy implemented mount-control, he should know more than me here 🙂 [14:30] ogra: I wish, but I'm not an expert with all the rest of snapd :-) [14:31] heh [14:31] 64 host-hunspell: [14:31] 65 interface: mount-control [14:31] 66 mount: [14:31] 67 - what: /usr/share/hunspell [14:31] 68 where: $SNAP_COMMON/host-hunspell [14:31] 69 persistent: true [14:31] 70 options: [ro, bind, noatime, noexec] [14:31] but yes, snapctl is a client, the real mount should be executed by snapd, which runs as root [14:31] right [14:31] and well, the command I dont know how relevant that is, since it refuses to do anything unless root [14:31] lissyx: what error do you get? [14:32] mardy, it refuses to run unless root ? [14:32] seb128: for your viewing pleasure: https://launchpad.net/ubuntu/kinetic/+queue?queue_state=0&queue_text=aad-auth :) [14:32] lissyx: I'm not doubting your word, but the exact error message would help me to grep in the snapd source code [14:33] $ snapctl mount --persistent /usr/share/hunspell [14:33] error: cannot use "mount" with uid 1000, try with sudo [14:33] please note also that from the doc, it is far from clear what exactly is the expectd "snapctl mount" to perform [14:34] the only relevant link https://snapcraft.io/docs/using-snapctl#heading--mount-control does not even state whether this is supposed to be running within a snap or on the host [14:34] i'D use it from a connect hook [14:35] lissyx: it's from a snap indeed. What if you call it from a hook? Dunno which one would be the most appropriate [14:35] (once the interface gets connected, the mount command gets called automatically) [14:35] ogra: ah, you beat me :-) [14:35] --help on "snapctl mount" mentions some ":" and ":" but it is unclear whether you need some snap name or what? [14:36] there is no mention of "connect hook" in https://snapcraft.io/docs/supported-snap-hooks [14:36] you defined what and where above in your snapcraft.yaml [14:36] lissyx: you don't need a snap name; if the snapctl command is called from within a snap's confinement, snapd detects that and knows what is the snap calling it [14:36] ogra, just pointing that the documentation leaves a lot of interrogations points [14:36] lissyx: https://snapcraft.io/docs/interface-hooks [14:37] lissyx, here are some examples: https://github.com/ogra1/config-snap/tree/master/snap/hooks [14:37] (the name is the key "connect-plug-") [14:38] so much things are not explained :( [14:38] lissyx, doc is well hidden in a link in the text of "inerface-hooks" https://snapcraft.io/docs/interface-hooks [14:38] it's easy when you know what you want to search for [14:39] yep ... and if you know the cryptic internal names ... [14:39] so there is no "hooks/" on the firefox snap [14:39] is it going to be enough to create one? [14:40] yeah, just create the dir ... dump a script into it with the proper name and thats it [14:40] should be under snap/hooks/ [14:40] +x ? [14:40] yes [14:40] there's no snap/ [14:40] yeah (though i think snapcraft adds +x automatically nowadays) [14:41] snapcraft.yaml is at the root [14:41] create it then [14:41] snapcraft expects that folder structure to consider it a valid hook [14:41] that's not consistent with your repo: https://github.com/ogra1/config-snap/tree/master/snap [14:41] where it's snapcraft.yaml and hooks/ under snap/ [14:42] yes [14:42] also what is the correct snapctl command? [14:42] snapcraft.yaml can live anywhere [14:42] do I need ":" ? [14:42] hooks can not [14:42] mardy, ogra, should the snapctl cmd work from a snap run --shell env? [14:42] i'd guess so ... not sure [14:42] mardy, ^ [14:42] would make easier to try [14:43] effectively it is supposed to b identical to you running the snap ... [14:43] if it is supposed to work, it does not [14:43] that's the first thing I tested [14:43] right ... and it seems you get the error from the mount command, not from snapd ... which indicates the suid bit is dropped somewhere on the way to call mount [14:43] so: "snapctl mount --persistent /usr/share/hunspell $SNAP_COMMON/host-hunspell" ? [14:44] yeah [14:45] am I supposed to see anything after installatio and running "snap run --shell firefox"? [14:45] like it should be mounted in $SNAP_COMMON/host-hunspell right? [14:45] a different prompt usually [14:45] seb128: yes, I think it should work, but as root [14:46] there is nothing [14:47] lissyx: to make sure that the hook was invoked, make it create a file under $SNAP_COMMON [14:48] right, you might need a mkdir -p $SNAP_COMMON/host-hunspell ... so the mountpoint exists [14:48] lissyx: and I think that the target directory ($SNAP_COMMON/host-hunspell) must exist [14:48] heh ... *snap* [14:49] the good news is that if such a hook is required to perform the mount, this is also where I will be able to perform the symlinks ... [14:50] so, no luck [14:50] no file created under $SNAP_COMMON [14:50] no directory either [14:50] nothing mounted [14:51] anything in journalctl or snappy-debug output ? [14:51] https://paste.mozilla.org/evo0yjO8/raw [14:52] dont frget a connect hook only runs when you actuvely connect the interface .... [14:52] *forget [14:52] geez .... my typing ... [14:52] wait [14:52] so if it was already connected, installing a new snap will not run the hook? [14:53] and i'd suggest to always run snappy-debug in a second terminal ... that'll show you all confinement issues [14:53] just installing an update will not re-connect i think ... it just keeps the existing connection [14:53] so you should disconnect and connect again [14:54] yeah now I get an error when connecting [14:54] great [14:54] so "/usr/share/hunspell not a block device" [14:54] so it runs .. [14:55] wow, our documentation is pretty excessive ... https://snapcraft.io/docs/mount-observe-interface ... [14:55] oh ... because i'm looking at the wrong doc 😛 [14:56] lissyx: oops, indeed, try something like snapctl mount --persistent -o bind,ro $SNAP_COMMON/host-hunspell [14:57] nope, sorry, I missed one part :-) [14:57] snapctl mount --persistent -o bind,ro /usr/share/hunspell $SNAP_COMMON/host-hunspell [14:57] so we need the options twice [14:58] lissyx: those in the yaml are the possible allowed options [14:58] lissyx: the actual ones are those that you use in the command-line [14:58] ok, with the correct options it is mounting [14:59] YAY !!! [14:59] so, 1000$ question [14:59] no more whining about root ? [14:59] should symlink be done on interface connect hook? [14:59] or another hook? [14:59] where do you want to link ? [14:59] where mardy told me to [15:00] we are just going to use this mount point to know system-level installed dictionnaries [15:01] well, i assume you also want to use them too ... not only know about them [15:01] no [15:01] oh ? [15:01] we are going to use snap hunspell ones [15:01] why all the effort then ? [15:01] to know which ones are installed by the system [15:02] so we present a shorter list to the user [15:02] AH ! [15:02] now it makes sense [15:02] I'm not sure exactly what DICPATH I should build [15:03] would post-refresh be a good candidate? https://snapcraft.io/docs/supported-snap-hooks#heading--post-refresh [15:03] do I just need a snap/hooks/post-refresh file, [15:03] to create an env variable ? [15:03] i'D do that frm a command-shain wrapper instead [15:03] *command-chain [15:04] (on app startup) [15:04] no, to create symlinks [15:04] i'm still not sure what you want to link where exactly [15:04] create a DICPATH full of symlinks [15:05] based on the content of both host hunspell and snap hunspell [15:05] host hunspell to know what dic we need [15:05] snap hunspell for the actual files [15:06] right, but why do you need symlinks for this ... you only want the list from $SNAP_COMMON/host-hunspell ... which is a simple ls -1 ... [15:06] gtk3 signed tags 6fed356 Sebastien Bacher ubuntu/3.24.34-3ubuntu2 * gtk+3.0 Debian release 3.24.34-3ubuntu2 * https://deb.li/3cOwy [15:07] DICPATH expect a directory ? [15:07] right now I dont know where I can write ... [15:07] but not $SNAP_COMMON/host-hunspell since you dont want to use that [15:07] $SNAP and $SNAP_COMMON are ro [15:08] (at least from snap shell) [15:08] nope [15:08] SNAP_COMMON is rw but lives in /var [15:08] $ mkdir $SNAP_COMMON/snap-hunspell [15:08] mkdir: cannot create directory \u2018/var/snap/firefox/common/snap-hunspell\u2019: Permission denied [15:08] (so you can only use it from hooks that run as root [15:08] right [15:09] so you have $SNAP_COMMON/host-hunspell ... and you will have $SNAP_COMMON/hunspell-snap-shared-space ... [15:10] you only want to provide the list of langs in the first one by creating symlinks into the second one from a place you can write to, correct ? [15:10] so that would be a command-chain script and putting the links into $SNAP_USER_COMMON [15:11] so you end up with something like: $SNAP_USER_COMMON/hunspell/de_DE.* -> $SNAP_COMMON/hunspell-snap-shared-space/de_DE.* [15:12] and have DICPATH point to $SNAP_USER_COMMON/hunspell/ [15:13] alternatively you can do it all from hooks and then can use SNAP_COMMON for everything ... (but wont have a per-user list then ... not sure that is wanted or not) [15:14] good to know we might have user-specific things [15:14] so from post-refresh hooks ... [15:14] mkdir: cannot create directory '/snap/firefox/x13/snap-hunspell': Read-only file system [15:14] hm that's $SNAP/ sorry [15:15] tracker-miners upstream/latest 0c94e30 Jeremy Bicha * pushed 37 commits (first 5 follow) * https://deb.li/3wVCv [15:15] tracker-miners upstream/latest f990be9 Carlos Garnacho src/libtracker-miner/tracker-miner-fs.c * libtracker-miner: Drop unused stats counter * https://deb.li/3gje [15:15] tracker-miners upstream/latest fe630e9 Carlos Garnacho src/ libtracker-miner/tracker-miner-fs.c miners/fs/tracker-main.c * libtracker-miner: Make stat reports in debug output clearer * https://deb.li/3OEv0 [15:15] tracker-miners pristine-tar 3a7e193 Jeremy Bicha tracker-miners_3.4.0~beta.orig.tar.xz.delta tracker-miners_3.4.0~beta.orig.tar.xz.id * pristine-tar data for tracker-miners_3.4.0~beta.orig.tar.xz * https://deb.li/3C6sn [15:15] tracker-miners upstream/latest 5bb579e Carlos Garnacho src/miners/fs/tracker-miner-files.c * tracker-miner-fs: Do not use unrestricted queries moving files * https://deb.li/zjRA [15:15] tracker-miners upstream/latest cc655ba Weijia Wang src/libtracker-miners-common/tracker-term-utils.c * macOS: add pipe2 fallback * https://deb.li/3vz6i [15:15] tracker-miners upstream/latest 112ea98 Carlos Garnacho src/libtracker-miners-common/tracker-term-utils.c * Merge branch 'darwin' into 'master' * https://deb.li/hqDv [15:15] yeah, i was about to say 🙂 [15:16] good nnews is the error message shows it iterated on the expected content [15:17] but with $SNAP_USER_COMMON nothing is created [15:18] not from a hook, no [15:18] hooks run as root ... SNAP_USER_COMMON points to ~/snap [15:18] well, ~/snap//common ... [15:19] you might find something in /root/snap if you ran from a hook ... [15:19] well I guess $SNAP_COMMON is good neough [15:19] (not sure we finally started preventing that) [15:19] we get on-par with deb/tar [15:19] pfft ... on par ... we should get *beyond* deb/tar with snaps 😉 [15:20] (yeah, i'm slightly biased 🙂 ) [15:20] ogra, given the current status, being on par is already a huge step forward ... [15:20] heh [15:20] opk [15:21] https://paste.mozilla.org/jVAKXGQB/raw [15:21] Good. [15:21] lovely ! [15:21]