| === guiverc2 is now known as guiverc | ||
| oSoMoN | good morning desktoppers | 06:01 |
|---|---|---|
| duflu | Hi oSoMoN | 06:02 |
| oSoMoN | hey duflu, how are you? | 06:03 |
| duflu | oSoMoN, not bad, how are you going? | 06:06 |
| oSoMoN | I'm doing good, did many things during the week-end and still managed to get some rest | 06:07 |
| luna | morning | 06:12 |
| duflu | Hi luna | 06:13 |
| oSoMoN | morning luna | 06:13 |
| duflu | oSoMoN, my main achievement was attaching an outdoor heater to a brick wall. Hope it hasn't fallen down already | 06:13 |
| oSoMoN | duflu, that sounds like advanced DIY, but an easy problem from an engineering perspective :) | 06:22 |
| jibel | Good morning all | 06:37 |
| duflu | Morning jibel | 06:43 |
| seb128 | goood morning desktopers! | 07:23 |
| lissyx | hello | 07:25 |
| duflu | Hi seb128 and lissyx | 07:27 |
| didrocks | salut seb128, lissyx, duflu | 07:27 |
| duflu | Hi didrocks | 07:27 |
| seb128 | hey lissyx duflu didrocks, how are you? | 07:36 |
| seb128 | did everyone had a nice weekend? | 07:36 |
| duflu | seb128, not bad and the weekend was nice. How are you? | 07:36 |
| seb128 | I'm alright thanks, my stomach was back to normal just on time to enjoy the sunny weekend :) | 07:38 |
| seb128 | oSoMoN, hey, could you review/sponsor bug #1978341 ? I'm unsure if the patch split makes sense there, feels like it might be easier to maintain as one but I don't know if dpkg complaining is a sign we should handle it differently? maybe a quilt refresh would 'fix' it by 'merging' the changes | 07:40 |
| ubottu | Bug 1978341 in xdg-desktop-portal (Ubuntu) "Merge for xdg-desktop-portal 1.14.4 from Debian unstable" [Wishlist, Confirmed] https://launchpad.net/bugs/1978341 | 07:40 |
| didrocks | ça va :) | 07:40 |
| lissyx | seb128, good enough | 08:03 |
| lissyx | worrying about the heat wave to come ... | 08:03 |
| lissyx | diddledani, so I fail to get /usr/lib/x86-64/libvgfs.... into /snap/xxx/ | 08:04 |
| seb128 | lissyx, the bug you duplicated seems slightly different from yours since it was speaking about using the fuse mount in /var/run/user when you use the gvfs smb:// url, that should go through different stacks | 08:40 |
| seb128 | the first one is a normal local filesystem behind a fuse mount | 08:40 |
| oSoMoN | seb128, sure, let me take a look | 08:40 |
| lissyx | which one? | 08:40 |
| seb128 | lissyx, https://bugzilla.mozilla.org/show_bug.cgi?id=1767316 | 08:40 |
| ubottu | Mozilla bug 1767316 in Core "Snap can browse network share, but cannot read/write there" [S3, Resolved: Duplicate] | 08:40 |
| seb128 | lissyx, the fuse case shouldn't need gvfs where using the smb url does | 08:41 |
| lissyx | "Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol," | 08:41 |
| lissyx | that seems very much like I do | 08:41 |
| lissyx | seb128, and the reporter confirmed seeing exactly the same error message: https://bugzilla.mozilla.org/show_bug.cgi?id=1767316#c13 | 08:41 |
| ubottu | Mozilla bug 1767316 in Core "Snap can browse network share, but cannot read/write there" [S3, Resolved: Duplicate] | 08:41 |
| seb128 | lissyx, k, well I'm just pointed out that the fuse mounts have been made to be able to use mounted shared by softwares not using gvfs | 08:42 |
| seb128 | pointing | 08:42 |
| oSoMoN | hrm, gitlab.freedesktop.org is down, and that breaks the builds of the firefox and chromium snaps, as that's where they get the pipewire source from | 08:42 |
| lissyx | I dont think it's reallly mounted through fuse | 08:42 |
| lissyx | he mentions using nautilus the same way I did, the error he has reports smb:// as well | 08:42 |
| seb128 | lissyx, it should be mounted in /var/run/users/...gvfs/... | 08:42 |
| seb128 | lissyx, well you could try if the fuse mount exist and if using that directory instead of the sidebar entry works | 08:43 |
| lissyx | seb128, the issue so far is lack of libgvfsdbus lib makes the code unable to transform the smb:// URI into a /run/user/... URI | 08:43 |
| lissyx | hence the nullptr for path in the code at some point, that we see in the error message | 08:44 |
| seb128 | lissyx, let me try if adding it fixes it | 08:47 |
| lissyx | that's what I'm trying to do since friday ... | 08:47 |
| oSoMoN | seb128, I commented on bug #1978341, shall I do the merge myself, or let Nathan handle it? | 08:48 |
| ubottu | Bug 1978341 in xdg-desktop-portal (Ubuntu) "Merge for xdg-desktop-portal 1.14.4 from Debian unstable" [Wishlist, Confirmed] https://launchpad.net/bugs/1978341 | 08:48 |
| lissyx | seb128, see the small snap repro in attachment https://bugzilla.mozilla.org/show_bug.cgi?id=1773624 | 08:48 |
| ubottu | Mozilla bug 1773624 in Core "Firefox Snap no longer able to save file on SMB share" [--, New] | 08:48 |
| seb128 | oSoMoN, just do it I would say? | 08:49 |
| seb128 | lissyx, you could locally try by snap download/unsquashfs/change the content/snapcraft snap DIR | 08:49 |
| oSoMoN | seb128, ok | 08:50 |
| lissyx | seb128, I'm trying stuff done on the gimp package but it looks like some variables are not defined | 08:50 |
| lissyx | like $SNAP | 08:50 |
| seb128 | lissyx, from https://wiki.gnome.org/Projects/gvfs/doc 'Local path mapping' that requires talking to gvfsd to query the mounts info and I'm unsure snapd will let you do that as mentioned on friday | 08:52 |
| seb128 | lissyx, $SNAP is defined in the snap | 08:52 |
| seb128 | lissyx, snap run --shell firefox; echo $SNAP | 08:53 |
| lissyx | seb128, I have no idea what all this gvfsd and mount info means precisely | 08:53 |
| lissyx | file picker gets us some smb:// URI | 08:53 |
| lissyx | and the file picker is the one from the xdg portal | 08:53 |
| seb128 | lissyx, the portal is a session component, it has access to libgvfsdbus if that's installed on your distro | 08:54 |
| seb128 | it's not under the snap confinement | 08:54 |
| lissyx | well | 08:56 |
| lissyx | it is installed ... | 08:56 |
| lissyx | seb128, this is where you get the nullptr mentionned in journalctl https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L80 | 09:02 |
| lissyx | URI here is the smb:// | 09:02 |
| seb128 | jamesh, ^ do you have any idea why that would fail? | 09:03 |
| lissyx | the closest I could get was this small reproducer | 09:03 |
| lissyx | running bare, it works | 09:03 |
| lissyx | running under snap, even with no sandboxing applied, it failed | 09:04 |
| lissyx | missing gio modules seemed the best clue | 09:04 |
| lissyx | seb128, I'm trying to unsquash and repack but it's not working and it's possible I'm just messing with gio there | 09:04 |
| seb128 | lissyx, under the snap yes, but the portal isn't in the snap so that doesn't make much sense to me | 09:05 |
| lissyx | gimp's hack from diddledani has some gio module cache rebuild | 09:05 |
| lissyx | I dont think I can run the snap with rr ? | 09:05 |
| jamesh | seb128: xdg-desktop-portal disables gvfs support: https://github.com/flatpak/xdg-desktop-portal/blob/main/src/xdg-desktop-portal.c#L380-L381 | 09:06 |
| seb128 | lissyx, ^ that's the difference with your testcase | 09:06 |
| lissyx | so | 09:06 |
| lissyx | we just cannot get this to work ? | 09:06 |
| seb128 | not today, it needs work on the portals I think | 09:06 |
| seb128 | https://github.com/flatpak/xdg-desktop-portal/issues/213 | 09:06 |
| ubottu | Issue 213 in flatpak/xdg-desktop-portal "ensure the file chooser only sends file: uris back" [Open] | 09:06 |
| jamesh | at present, it won't work. In theory, it could potentially be made to work | 09:07 |
| jamesh | i.e. xdg-document-portal's fuse server could proxy requests to gvfsd-fuse | 09:07 |
| lissyx | ok | 09:09 |
| jamesh | I haven't really looked into how difficult this would be to achieve, and would likely only work for the xdg-desktop-portal-gtk UI | 09:10 |
| jamesh | not kde | 09:10 |
| lissyx | jamesh, seb128, then at least we should not show those mount points into the xdg desktop portal file picker | 09:10 |
| seb128 | lissyx, did you try if browsing the /var/run/user/UID/gvfs ... directory works as a workaround? | 09:10 |
| lissyx | seb128, I was about to test that, but still | 09:11 |
| lissyx | yes it works | 09:11 |
| seb128 | lissyx, yes, sadly I think it's not trivial to hide them because the GTK dev removed the 'local' mode, https://discourse.gnome.org/t/gtk4-gtkfilechooser-show-only-local-files | 09:12 |
| seb128 | lissyx, you should report the issue on https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues at least as a first step | 09:14 |
| lissyx | so the feature is broken, and we can't avoid the user getting tricked into thinking it is going to work | 09:14 |
| lissyx | seb128, why on gnome and not on the original one? | 09:15 |
| seb128 | lissyx, original? you mean xdg-desktop-portal? | 09:15 |
| lissyx | yes | 09:15 |
| seb128 | lissyx, xdg-desktop-portal has the backend and -gnome the frontend | 09:16 |
| lissyx | ok | 09:16 |
| seb128 | lissyx, so there is work on xdg-desktop-portal to add gvfs support, which is already reported, but also as you mentioned until that is done the frontend shouldn't show non working entries, and that's on -gnome | 09:17 |
| lissyx | right | 09:18 |
| jamesh | lissyx: one thing you could try would be to run "GIO_USE_VFS=local /usr/libexec/xdg-desktop-portal-gnome -r", then try to open a file from one of your snaps | 09:18 |
| jamesh | does that remove the non-local file paths from the chooser for you? | 09:19 |
| lissyx | jamesh, I'll test | 09:21 |
| lissyx | jamesh, to make it clear, https://github.com/flatpak/xdg-desktop-portal/issues/213 this is the bug that needs to be fixed so we can have it working, right ? | 09:21 |
| ubottu | Issue 213 in flatpak/xdg-desktop-portal "ensure the file chooser only sends file: uris back" [Open] | 09:21 |
| lissyx | jamesh, yes, I dont see the remotes when this env var is set | 09:22 |
| jamesh | lissyx: that looks like it, yes. | 09:24 |
| jamesh | making xdg-desktop-portal-gnome use GIO_USE_VFS=local is basically just extending the existing restriction to the new UI service | 09:24 |
| lissyx | https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/48 | 09:28 |
| ubottu | Issue 48 in GNOME/xdg-desktop-portal-gnome "File picker should not display remote gvfs mountpoint it cannot handle until https://github.com/flatpak/xdg-desktop-portal/issues/213 is fixed" [Opened] | 09:28 |
| jamesh | looks good. | 09:31 |
| seb128 | lissyx, thanks, I will handle backporting fixes to Ubuntu once there is one | 09:31 |
| lissyx | jamesh, seb128, and there's no nasty workaround we could use to either force the portal to hide it for us, or show the raw mounpoints rather than the gvfs ones? | 09:31 |
| lissyx | because I fear this will continue to create a lot of dupes on our side ... | 09:31 |
| jamesh | maybe note that setting GIO_USE_VFS=local was enough to get the file chooser to only display local files | 09:32 |
| lissyx | done | 09:36 |
| oSoMoN | jbicha, hey, when you get online, you might want to pull https://salsa.debian.org/osomon-guest/xdg-desktop-portal/-/tree/ubuntu/kinetic into https://salsa.debian.org/debian/xdg-desktop-portal (I can't do that myself, and I can't even propose a PR because there's no ubuntu/kinetic branch yet) | 09:49 |
| seb128 | oSoMoN, he's off today, I did it now | 10:19 |
| seb128 | jbicha, ^ fyi | 10:19 |
| oSoMoN | thanks! | 10:19 |
| seb128 | oSoMoN, I also updated the gbp.conf and tagged it now | 10:21 |
| schopin | hi there :). Do I need to do something to get the rust toolchain packages copied over from the security PPA, or will it get done alongside firefox? | 10:27 |
| seb128 | hey schopin, that's a question for oSoMoN ^ | 10:35 |
| seb128 | oSoMoN, weird, https://salsa.debian.org/debian/xdg-desktop-portal/-/jobs/2872792 | 10:36 |
| seb128 | dpkg-source: error: diff 'source_dir/debian/patches/webextensions-portal.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one | 10:36 |
| seb128 | CI doesn't like it but it built fine in the archive, I wonder if next time we should just quilt refresh to reformat | 10:37 |
| oSoMoN | seb128, see my two comments on bug #1978341 | 10:49 |
| ubottu | Bug 1978341 in xdg-desktop-portal (Ubuntu) "Merge for xdg-desktop-portal 1.14.4 from Debian unstable" [Wishlist, Fix Committed] https://launchpad.net/bugs/1978341 | 10:49 |
| oSoMoN | I think dpkg-source is being too restrictive here, I find it perfectly valid to have a patch file that patches multiple times the same file | 10:50 |
| oSoMoN | thanks for the tagging, I had done it locally but forgot to push the tags… | 10:50 |
| oSoMoN | schopin, the rustc and cargo updates prepared by you are in https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages and will be copied over to the respective security pockets by Chris when he sponsors the firefox updates | 10:51 |
| oSoMoN | thanks again for your work on the updates btw! | 10:51 |
| schopin | sure, thanks for the info! | 10:52 |
| nteodosio | oSoMoN: Another option I had found was to apply the patch and then extract the resulting diff in a new patch. This way a given file wouldn't be patched multiple times. | 10:54 |
| oSoMoN | nteodosio, yes, that works too, but the problem remains the same: dpkg-source wants to force us to use a given format for no good reason, and that format increases the maintenance work (and readability of the patch, too) | 10:56 |
| nteodosio | indeed | 10:56 |
| oSoMoN | having a patch broken down into separate commits from an upstream PR looks valid to me, dpkg-source shouldn't try to get in the way | 10:57 |
| seb128 | there is a bit more context on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810720 | 11:31 |
| ubottu | Debian bug 810720 in libdpkg-perl "libdpkg-perl: check_patches_applied does not apply patches if the first patch emits a warning" [Normal, Open] | 11:31 |
| seb128 | bottom line is that dpkg has limitations for $technical_reasons | 11:33 |
| lissyx | so there is no way, when running "snap run snapcraft" to pass some env variables that ends up in the build itself? | 11:36 |
| seb128 | lissyx, what do you mean? you can use env variable in the snapcraft.yaml | 11:37 |
| lissyx | seb128, I want to pass some from when I call it, not burnt within the snapcraft.yaml itself | 11:37 |
| lissyx | I'm ok defining it within the yaml file, but I would need to change its value from outside | 11:37 |
| seb128 | lissyx, it should respect any environment variable set on the machine running the cmd | 11:39 |
| seb128 | https://git.launchpad.net/~mozilla-snaps/+git/firefox-snap/plain/snapcraft.yaml | 11:39 |
| seb128 | there are a few examples in there | 11:39 |
| lissyx | that was clearly not the behavior I was seeing when I tested last week | 11:39 |
| seb128 | the problem is that if you build the snap on the infra you are not going to be able to set it | 11:39 |
| seb128 | since the launchpad builders don't let you tweak the env | 11:40 |
| lissyx | that's not a big deal | 11:40 |
| lissyx | not for the moment | 11:40 |
| lissyx | let me re-test | 11:42 |
| lissyx | seb128, I'm exploring how we could somehow get debug symbols and for now I'm testing by reproducing snap on taskcluster | 11:42 |
| lissyx | according to people in #snappy, for a same set of code source and running build within multipass it should be okay | 11:43 |
| seb128 | great | 11:44 |
| lissyx | beta and nightly are built on github? but stable is built on launchpad, will this hold? | 11:45 |
| lissyx | (I'm also open to references of how the build system on launchpad works) | 11:45 |
| lissyx | my only experience for that is a 10 years old PPA repo, and it was working similar to debian's build system | 11:46 |
| seb128 | lissyx, github is limited in the archs available, unsure if oSoMoN plan to move the others builds to launchpad | 12:02 |
| lissyx | the build is broken locally because of gitlab.freedesktop.org being down :/ | 12:11 |
| lissyx | seb128, interesting, I'm getting a new error now | 13:14 |
| lissyx | "unbound variable" | 13:23 |
| lissyx | no more unbound variable if I put it in build-environment | 13:49 |
| oSoMoN | lissyx, stable, esr and beta are built on launchpad, and nightly is built on github because launchpad didn't seem to like checking out the firefox hg repository (it would fail or time out too frequently to be usable) | 13:57 |
| oSoMoN | and yes, all builds are currently broken atm because of gitlab.freedesktop.org being down :/ | 13:57 |
| lissyx | :) | 13:58 |
| oSoMoN | (it's been down for more than 2 days afaict) | 13:58 |
| oSoMoN | IIRC building a snap on launchpad uses the lxd backend, rather than multipass VMs | 13:59 |
| lissyx | ok | 13:59 |
| lissyx | so it could even maybe not work | 13:59 |
| lissyx | MOZ_REPO=git://nas.home/m-c/ snap run snapcraft | 14:00 |
| lissyx | this is not hnoored :/ | 14:00 |
| oSoMoN | gitlab.freedesktop.org is back online \o/ | 15:17 |
| * oSoMoN frantically hits retry on all failed builds | 15:18 | |
| Rastersoft | Hi all | 16:47 |
| Rastersoft | I'm having an odd problem: I'm using AutoAR from Javascript, and to uncompress an encrypted file, I must hear the "request-passphrase" signal and return there the password | 16:49 |
| Rastersoft | The problem is that AutoAR seems to not receive the password | 16:49 |
| Rastersoft | I even compiled it manually in my system, adding a g_print() before and after sending the signal, and showing the password returned, but it is always NULL | 16:49 |
| Rastersoft | And what is even more odd: it is like the Javascript callback is being called AFTER the signal has been emitted and processed (which would explain the bug, but I presumed that the signals were synchronous...) | 16:50 |
| Rastersoft | Are signals emitted from C and processed in GJS asynchronous? | 16:51 |
| Rastersoft | (they shouldn't, because in that case, "delete-event" couldn't be blocked, but...) | 16:52 |
| Rastersoft | Ops... this was for #gjs... | 16:53 |
| lissyx | jamesh, was there any follow up discussion to https://forum.snapcraft.io/t/collecting-debug-symbols/7017/11 ? | 17:34 |
| seb128 | lissyx, James is in Australia, you have a better chance to catch him in european morning | 17:51 |
| seb128 | but afaik there was no real work since on that | 17:51 |
| seb128 | kenvandine might also know about the status | 17:51 |
| lissyx | :( | 18:16 |
| KGB-2 | ghex tags 16c4d8f Sebastien Bacher upstream/42.3 * Upstream version 42.3 * https://deb.li/58DD | 19:27 |
| KGB-0 | ghex upstream/latest fe2e226 Sebastien Bacher * pushed 7 commits (first 5 follow) * https://deb.li/3xnVz | 19:28 |
| KGB-0 | ghex upstream/latest e94a8ff Logan Rathbone src/main.c * main: Quick hotfix to workaround gtk #4880 * https://deb.li/cxjl | 19:28 |
| ubottu | Issue 4880 in GNOME/gtk "Keyboard focus automatically moves from the filename entry to the file list widget when typing a letter" [Opened] https://gitlab.gnome.org/GNOME/gtk/-/issues/4880 | 19:28 |
| KGB-0 | ghex upstream/latest 9db17f3 Logan Rathbone src/configuration.c * config: Add GNOME 42+ compatibility for dark mode * https://deb.li/3GIvI | 19:28 |
| KGB-0 | ghex upstream/latest cfd6ca8 Logan Rathbone src/configuration.c * config: Fetch dark settings from portal if possible * https://deb.li/3wDRE | 19:28 |
| KGB-0 | ghex upstream/latest 25a253f Logan Rathbone src/gtkhex.c * widget: Properly update highlights upon resize * https://deb.li/itvne | 19:28 |
| KGB-0 | ghex upstream/latest ddc6eca Logan Rathbone src/findreplace.c * findrep: Remove spurious g_object_ref() call. * https://deb.li/z7D | 19:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!