=== Kilroy- is now known as Kilroy [07:14] Good morning all [07:16] good morning [07:36] good morning desktoppers [07:38] Hi jibel, didrocks, oSoMoN [07:42] hey duflu [07:42] salut jibel & didrocks [07:43] hey duflu, salut oSoMoN === cpaelzer_ is now known as cpaelzer [08:39] Hello all. I've forgotten where did you guys store the scripts for creating the live-cd's ? [08:41] I've managed to create a live image with the help of live-build from debian team. kudos to elementary/os repository on github. [08:41] there is another with is a custom script regolith linux repository on github is using that as well. I only want to compare different ways different teams are working to create live-cd's. [08:42] \m/ [08:42] goood morning desktopers, sounds like I forgot to start IRC today! [08:44] salut seb128 [08:46] Morning seb128 [08:47] lut oSoMoN, hey duflu, how are you? [08:47] seb128, not bad. You? [08:47] I'm alright thanks! [08:48] I'm good, had a very relaxing week-end camping by the beach with friends. [08:49] oSoMoN wins the weekend [10:56] oSoMoN, seb128: hello [10:56] I'm wondering if you had knowledges around XDG Document Portal ? [10:57] context: https://bugzilla.mozilla.org/show_bug.cgi?id=1774556#c56 [10:57] Mozilla bug 1774556 in Core "Firefox fails to save a page and its contents to remote gvfs mount point when using SNAP version" [--, Unconfirmed] [11:04] jamesh, ^ do you maybe know? [11:09] from reading the code it's not super clear to me [11:11] seb128: haven't read all of the bug report, but going by the end of it, I'd expect the mkdir() calls to fail: when exposing a writable file, xdg-desktop-portal really only allows creating a temporary file in the directory provided and renaming the temporary file over the top of the real file name. [11:15] jamesh, ok, do you have some reference that states that and we could link? [11:15] jamesh, also, is this something fundamentally unfixable or just a choice ? [11:17] lissyx, seb128: xdg-desktop-portal does have a relatively new SaveFiles() method that could potentially handle this use case: it lets the caller provide a list of files they want to save to, and returns a corresponding list of document portal paths the app can write to. [11:17] jamesh, yes sergio mentionned that [11:17] jamesh, although would it allow for a directory created ? [11:18] jamesh, and the caller of `SaveFile` is not us, it is GTK, so it would require quite some change either on our side or GTK's [11:20] lissyx: it wouldn't let Firefox create the directory, no. If xdg-desktop-portal allows path elements in the files list though, it might be possible. [11:20] otherwise, Firefox would need to save all the page resources in the current directory [11:21] I am unsure this is an acceptable change, it would make the behavior deviate too much. [11:21] And I realise the paths are important to Firefox, since it needs to fix up URL paths in the HTML [11:21] jamesh, so i'd need to try and pass SaveFiles() the HTML file as well as the resources that are living under the subdir (with the subdir) [11:22] I failed to find some doc on how I could trigger a SaveFiles() manually from maybe shell or python [11:22] I guess I need to try again, some python + dbus and check if we can make something like that [11:34] lissyx: from the look of the xdg-desktop-portal-gtk UI implementation, you could potentially specify subdirectories for some of the files to save. I don't know if xdg-document-portal would actually create them for you when trying to write to those files though. [11:35] It may also decide to rename some of the files you specify if there are existing files by those names. I imagine that'll be a problem for Firefox's use case too: https://github.com/flatpak/xdg-desktop-portal-gtk/blob/main/src/filechooser.c#L152-L174 [11:35] Presumably there is similar code in xdg-desktop-portal-gnome [11:52] yep [11:54] jamesh, I was hopeful because of https://github.com/flatpak/xdg-desktop-portal/blob/13e8307791bbd549cc882b4e368032ad8f53536d/document-portal/document-portal.c#L301-L302 [12:01] good morning [20:01] libsigcplusplus pipeline Jeremy Bicha 391032 * pending (extract-source: pending; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created) [20:10] libsigcplusplus pipeline Jeremy Bicha 391032 * [8 minutes and 26 seconds] failed (extract-source: success; build: success; build i386: success; build source: success; test-build-any: success; test-build-all: success; test-crossbuild-arm64: success; reprotest: failed; lintian: success; autopkgtest: success; blhc: success; piuparts: success)