=== rs20096 is now known as rs2009 [05:49] good morning [05:52] Hi didrocks === rs20092 is now known as rs2009 [05:55] hey duflu === tjaalton_ is now known as tjaalton [07:58] goood morning desktopers! I think I forgot to say hey on IRC earlier? [08:23] Hi seb128 [08:30] duflu, hey, how are you? [08:30] seb128, not bad. How are you? [08:31] I'm alright thanks! [08:32] I'm stuck trying to build firefox snap on arm64 ... [08:32] "launch failed: Unable to find an image matching "core20". Please use `multipass find` for supported remotes and images." [08:33] "multipass find" does not help that much ... [08:33] https://paste.debian.net/1256758/ [08:38] morning desktoppers [08:42] on my amd64 build machine "multipass find core20" does not find anything either ... [08:58] lissyx, what are you trying to do? get a snap core20 env? [08:58] lissyx: IIRC, snapcraft uses special multipass VM images rather than the default ones. Perhaps they weren't built for arm64? [08:58] seb128, build on arm64 [08:58] jamesh, yes well, maybe, but since there's no doc, and no explanation of what to do, I have no idea how to check ... [08:59] lissyx: it's possible you'll have more luck using "snapcraft --use-lxd" [08:59] lissyx, multipass find snapcraft:core20 [08:59] seb128, yes, it is not there [08:59] on amd64 it is [08:59] at least for me [09:00] which is what the first error message already said, but as you can notice, the error only mentions "core20" and not "snapcraft:core20" which is already confusing [09:00] yes, on amd64 it is as well [09:00] which uses default LXD images rather than special Snapcraft ones. [09:00] "multipass find" does not yield more info about where those images are coming from [09:01] right, multipass could do better there. But what James said, try with --use-lxd maybe (and why is that mode still not the default?) [09:02] https://github.com/canonical/multipass/pull/2395 also [09:02] -ubottu:#ubuntu-desktop- Pull 2395 in canonical/multipass "[custom] add `core20` on LXD" [Open] [09:02] seb128: It is the default if your snapcraft.yaml says "base: core22", but isn't otherwise... [09:03] jamesh, seb128, lxd fails with some permissions errors ... [09:03] since there's effectively two Snapcrafts for now, selected based on the base version. [09:03] jamesh, I see [09:04] lissyx: if you've just installed lxd, you'll need to add yourself to the lxd group (creating it if it doesn't exist). You'd need to log out and in again for your processes to have that group membership though (or use sg or newgrp) [09:05] jamesh, and yet snapcraft suggested to set it up for me ... [09:05] so it's a snap [09:06] lissyx: lxd is shipped as a snap, yes. But even if it was shipped as a .deb, it likely wouldn't go adding users to a new group. [09:06] the group membership is used to control access to the lxd control socket. [09:07] yes ... [09:07] lissyx: and I agree that this is more painful than it should be. [09:08] An error occurred with the instance when trying to launch with 'LXD': Failed creating instance record: Failed initialising instance: Invalid devices: Failed detecting root disk device: No root device could be found. [09:08] Ensure that 'LXD' is setup correctly and try again. [09:09] lissyx: you need the "sudo lxd init" bit from https://snapcraft.io/docs/build-on-lxd [09:11] finally maybe it is working? [09:11] that's still super inconvenient instead of cross-compiling ... [09:18] seb128, ok so on another front, I have a patch for https://bugzilla.mozilla.org/show_bug.cgi?id=1785278 [09:18] -ubottu:#ubuntu-desktop- Mozilla bug 1785278 in Core "AutoConfig in snap" [S3, Reopened] [09:18] seb128, that would require to allow /etc/firefox, not just /etc/firefox/policies [09:18] but I think with mkaply we are open to the path to allow there? [09:27] lissyx: it'd need an update to the etc-firefox-policies plug in the snapcraft.yaml, and a change to the snap-declaration on the store to let the updated plug autoconnect [09:28] what James said [09:29] lissyx, also I mentioned the core image missing to one of the multipass maintainers, it's tracked in https://github.com/canonical/multipass/issues/2776 now [09:29] -ubottu:#ubuntu-desktop- Issue 2776 in canonical/multipass "Support Ubuntu Core 20 and 22 images" [Open] [09:44] seb128: it's not clear that bug is the same issue: that seems to be about running Ubuntu Core 20/22 in a multipass VM. But the Snapcraft VMs are classic Ubuntu [09:45] i.e. snapcraft:core20 is just the classic Ubuntu 20.04 image with a few customisations. [09:45] jamesh, I joined mid-discussion, that was about adressing the fact that 'multipass find core20' doesn't find anything [09:46] but yes that seems orthogonal to what Alexandre was trying to achieve [09:46] ah. But even if "multipass find core20" found something, Snapcraft would probably still give the same error message :-( [09:56] jamesh, right, the name overload is a bit confusing, would have been nice to have an image snapcraft-core20 [11:25] the build failed because of not enough disk space [11:26] even though the arm64 instances has 80GB of disk ... [11:26] I've lost enough time and money on that for now [13:35] this is waaay above my head ("is HDR harder?" at the Xorg Developers Conference this past week) [13:36] https://youtu.be/nDnbWaIMJJA [13:36] ... forgot to paste the yootoobe [14:02] seb128, I need your opinion [14:03] seb128, for https://bugzilla.mozilla.org/show_bug.cgi?id=1785278 [14:03] -ubottu:#ubuntu-desktop- Mozilla bug 1785278 in Core "AutoConfig in snap" [S3, Reopened] [14:03] seb128, I have https://phabricator.services.mozilla.com/D159059 that: adds reading defaults/pref from under /etc/firefox on Snap ; can source the file pointed by general.config.filename in /etc/firefox (for now) [14:04] seb128, but for the latter, that means we need to allow the snap package whole /etc/firefox ; maybe this is not something we want to do? [14:04] seb128, would it be better to search for this file under some other subdirectory we grant at snap plugs level? e.g., /etc/firefox/autoconfig [14:06] lissyx, I think it's fair that the firefox snap can access anything to /etc/firefox , the directly is named after the software and shouldn't contain any data that shouldn't be accessible to firefox right? [14:06] shrug, typos [14:07] lissyx, I think it's fair that the firefox snap can access anything in /etc/firefox , the directory is named after the software and shouldn't contain any data that shouldn't be accessible to firefox right? [14:07] seb128, that would be my assumption, but you might want to restrict as much as possible [14:07] since right now it grants specific access to /etc/firefox/policies [14:08] lissyx, I don't know what the directory can be used for, but I feel like that if something is in there and the snap doesn't have access then we will end having a report asking to grant access because if a file has been put in /etc/firefox that's probably because firefox needs it for something [14:09] so I lean torward just giving access to /etc/firefox now [14:14] ok [14:15] you will end up in manual review anyway and the security team will review it if you change a path in a system-files interface [14:15] so just let them worry about it 😉 [14:17] ogra, it's just that whether or not /etc/firefox is fully open or more fine-grained has impacts on my patch :) [14:18] and given /etc/firefox/policies current handling, I was unsure :) [14:21] yeah, i dont think it is a bad idea to just allow the whole dir ... but you have a saftey net due to the review in any case [14:21] (and dont forget to adjust the interface name, the name must match the path by policy) [14:22] what interface? [14:23] seb128, https://github.com/canonical/firefox-snap/pull/8 [14:23] -ubottu:#ubuntu-desktop- Pull 8 in canonical/firefox-snap "Bug 1785278 - Allow reading from /etc/firefox" [Open] [14:27] lissyx, the one you changed in that commit 🙂 all good 🙂 [14:27] ogra, so nothing else required, right? [14:28] and then autoconnect will be taken care of on snap store level [14:28] right ... except forum post and discussion once it goes into manual review [14:28] why? [14:29] because it is a super privileged interface and it wont auto-connect by default either ... [14:30] so security team needs to take a look if/how it is dangerous to grant it ... and you surely want it to aut-connect at install time too [14:30] should be a no-brainer for such a change [14:30] but paperwork s involved [14:31] I dont really care as long as I dont land the change on our side and then people want to change the directory we source autoconfig file from [14:46] ogra, does it require a forum post to discuss tweaking an existing permission? [15:01] seb128, i would hope so ... else you could just switch from /etc/firefox to /etc without anyone noticing [15:01] ogra, ? [15:02] if it does not trigger a manual review that'd be a bug in the review tools [15:02] ogra, I didn't say it shouldn't go to manual review and be reviewed [15:02] ogra, read again what I wrote [15:02] well, if it goes to manual the reply you get from the str is in general "please file a forum post" [15:02] *store [15:03] which makes sense for a new permission [15:03] you can perhaps use a short-cut and ask internally or so [15:03] I was just expecting that for an obvious change the reviewed would make you go through more paperwork [15:03] but let's see [15:03] yeah [15:03] reviewer wouldn't* [15:03] if you widen the permissions like above it should definitely block you [15:08] ogra, oh, I've no doubt it will go to manual review, I was just arguing over using the forum to do paperwork [15:09] well, that is where we keep the paper-trails ... perhaps you can fast-track it though ... [15:16] let's follow the process [15:17] (i dont think anyone has ever exercised a change to an existing system-files interface FWIW) [15:19] it's easy to post, at least gives context to the reviewer [15:20] on that note going to drop from IRC as I'm changing location and we still don't have a messaging system which deals with that nicely :( [16:10] gnome-shell signed tags dcbebd3 Jeremy Bicha ubuntu/43.0-1ubuntu2 * gnome-shell Debian release 43.0-1ubuntu2 * https://deb.li/sx2R [18:11] gnome-terminal signed tags 4a89b69 Jeremy Bicha ubuntu/3.46.2-1ubuntu1 * gnome-terminal Debian release 3.46.2-1ubuntu1 * https://deb.li/Whge [18:12] gnome-terminal ubuntu/master 2fd1936 Jeremy Bicha * pushed 19 commits (first 5 follow) * https://deb.li/3ZGI0 [18:12] gnome-terminal ubuntu/master 65167e7 Christian Persch meson.build * build: Post release version bump * https://deb.li/AdlA [18:12] gnome-terminal ubuntu/master c7daa25 Sabri Ünal po/tr.po * Update Turkish translation * https://deb.li/30Nai [18:12] gnome-terminal ubuntu/master 5c01679 Christian Persch src/ meson.build terminal-prefs-process.cc terminal-settings-utils.cc terminal.cc * prefs: Move prefs binary to libexecdir * https://deb.li/dTxv [18:12] gnome-terminal pristine-tar eae37a6 Jeremy Bicha gnome-terminal_3.46.2.orig.tar.bz2.delta gnome-terminal_3.46.2.orig.tar.bz2.id * pristine-tar data for gnome-terminal_3.46.2.orig.tar.bz2 * https://deb.li/ihpF [18:12] gnome-terminal ubuntu/master 1142420 Christian Persch data/meson.build po/POTFILES.in data/org.gnome.Terminal.Preferences.desktop.in * prefs: Add NoDisplay desktop file for the prefs binary * https://deb.li/3YKen [18:12] gnome-terminal ubuntu/master b19b82b Christian Persch src/ (5 files) * client: Use verified schema * https://deb.li/34kEs [18:12] gnome-terminal upstream/latest 3f8e75d Jeremy Bicha * pushed 13 commits (first 5 follow) * https://deb.li/ijLuU [18:12] gnome-terminal upstream/latest 65167e7 Christian Persch meson.build * build: Post release version bump * https://deb.li/AdlA [18:12] gnome-terminal upstream/latest c7daa25 Sabri Ünal po/tr.po * Update Turkish translation * https://deb.li/30Nai [18:12] gnome-terminal upstream/latest 5c01679 Christian Persch src/ meson.build terminal-prefs-process.cc terminal-settings-utils.cc terminal.cc * prefs: Move prefs binary to libexecdir * https://deb.li/dTxv [18:13] gnome-terminal upstream/latest 1142420 Christian Persch data/meson.build po/POTFILES.in data/org.gnome.Terminal.Preferences.desktop.in * prefs: Add NoDisplay desktop file for the prefs binary * https://deb.li/3YKen [18:13] gnome-terminal upstream/latest b19b82b Christian Persch src/ (5 files) * client: Use verified schema * https://deb.li/34kEs [18:56] gspell pristine-tar 4e6b3aa Jeremy Bicha gspell_1.12.0.orig.tar.xz.delta gspell_1.12.0.orig.tar.xz.id * pristine-tar data for gspell_1.12.0.orig.tar.xz * https://deb.li/BE4e [18:56] gspell upstream/latest 877c49c Jeremy Bicha * pushed 17 commits (first 5 follow) * https://deb.li/jQyI [18:56] gspell upstream/latest 8d57e56 Zurab Kargareteli po/ LINGUAS ka.po * Add Georgian translation * https://deb.li/3DzDA [18:56] gspell upstream/latest 0723975 Zurab Kargareteli po/ka.po * Update Georgian translation * https://deb.li/3V63N [18:56] gspell upstream/latest 6cf279d Sébastien Wilmet README.md * readme: add link to gspell for GTK 4 * https://deb.li/D6rc [18:56] gspell upstream/latest 2473b48 Sébastien Wilmet configure.ac * build: replace use of deprecated macro * https://deb.li/3LrTy [18:56] gspell upstream/latest cd76632 Sébastien Wilmet gspell.doap * doap: small update/simplification * https://deb.li/0QYG [19:01] glib pristine-tar d6c10ab Jeremy Bicha glib2.0_2.72.4.orig.tar.xz.delta glib2.0_2.72.4.orig.tar.xz.id * pristine-tar data for glib2.0_2.72.4.orig.tar.xz * https://deb.li/3lQcl