[00:19] <mup> PR snapcraft#2744 closed: project_loader: load build-environment after snapcraft environment <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2744>
[03:23] <mup> PR snapcraft#2745 opened: tests: introduce gtk3 test for gnome extension <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2745>
[03:34] <NickZ> I hate npm so much
[05:24] <mup> PR snapd#7561 closed: tests: update system-usernames test now that opensuse-15.1 works <Simple 😃> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7561>
[05:31] <mborzecki> morning
[06:32] <mborzecki> mvo: morning
[06:35] <mvo> hey mborzecki
[06:38] <mborzecki> school run, back in 20 or so
[06:53] <pokk> Good morning. Any updates to the rsync snap?
[06:54] <mup> PR snapd#7559 closed: tests: change regex to validate access to cdn during snap download <Simple 😃> <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7559>
[06:57] <mborzecki> re
[07:03] <pstolowski> morning
[07:03] <zyga> o/
[07:07] <zyga> joedborg: I do now, sorry for being absent last evening
[07:08] <mborzecki> pstolowski: zyga: hey
[07:32] <mborzecki> zyga:  some comments under #7547
[07:32] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[07:32] <zyga> thanks, looking
[07:39] <zyga> thanks for spotting the odd mode, I'll change that
[07:39] <zyga> the rest of the comments are easy to apply, I'll adjust that shortly
[07:51] <mborzecki> mvo:  can you take a look at https://github.com/snapcore/snapd/pull/7557 ? could land easily
[07:51] <mup> PR #7557: interfaces/mount: account for cgroup version when reporting supported features <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7557>
[07:56] <zyga> brb
[07:59] <mvo> mborzecki: yes
[08:02] <mborzecki> mvo: thank you!
[08:10] <mup> PR snapd#7557 closed: interfaces/mount: account for cgroup version when reporting supported features <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7557>
[09:02] <mborzecki> mvo: system-key has a Version field witha comment that need to bump it when adding new inputs, however it looks like we never bumped when adding new fields
[09:02] <mborzecki> mvo: this field https://github.com/snapcore/snapd/blob/master/interfaces/system_key.go#L60
[09:03] <mvo> mborzecki: uh, right - we should
[09:03] <mvo> mborzecki: in a meeting right now
[09:06] <Chipaca> mborzecki: we could set it using reflect (or, maybe better, test it using reflect)
[09:07] <Chipaca> mborzecki: i'll push a pr to do that
[09:07] <mborzecki> Chipaca: yeah, that's another point, we unmarshal and then test, assuming we can actually unmarshal the thing
[09:08] <Chipaca> mborzecki: in the tests you mean? or where?
[09:08] <mborzecki> Chipaca: https://github.com/snapcore/snapd/blob/master/interfaces/system_key.go#L210
[09:08] <pstolowski> degville: hey, can you update https://bugs.launchpad.net/snappy/+bug/1823343 and/or reassign to appropriate project if neccessary?
[09:08] <mup> Bug #1823343: Getting Started Intro out of date <Snappy:New> <https://launchpad.net/bugs/1823343>
[09:09] <mborzecki> Chipaca: it's assume that the old format can be unmarshalled into the new struct, not sure if it's worth to make it super safe though
[09:09] <Chipaca> mborzecki: what would you do differently there?
[09:10] <Chipaca> I mean, I'd look at unmarhsaling from the file and using .More() etc but still
[09:10] <Chipaca> mborzecki: it assumes it's backwards-compatible which doesn't seem like too much of a stretch (and we can/should test for it)
[09:11] <mup> Bug #1781789 changed: snapctl doesn't advertise that it's an internal tool <snapd:Confirmed> <https://launchpad.net/bugs/1781789>
[09:11] <mborzecki> Chipaca: super safe would probably be unmarshal into a struct with a single Version `json:"version"` field, or map, though as i wrote, it's probably not worth it and assuming backwards compat is reasonable (we control the format after all and it's quite simple)
[09:14] <mup> Bug #1805162 changed: Impossible to get newly settled props <configure> <props> <snapctl> <snapset> <validation> <snapd:New> <https://launchpad.net/bugs/1805162>
[09:16] <zyga> brb
[09:20] <mup> Bug #1746564 changed: snapd should not allow --classic installation for snaps with strict confinment mode <Snappy:Fix Released> <https://launchpad.net/bugs/1746564>
[09:23] <degville> pstolowski: will do - thanks!
[09:26] <Chipaca> huh, in 304d3a72ed68fb00cd3afec27bc302c618d1ed1a we dropped 'core' from systemKey
[09:29] <zyga> small break as Lucy just has to be on my hands having saw me
[09:29] <mup> Bug #1781790 changed: snapctl start gives error message that is useless to beginners, and nothing of it is explained in --help or a man page (which doesn't seem to exist) <Snappy:New> <https://launchpad.net/bugs/1781790>
[09:32] <abeato> pedronis, hi, would it be possible to update https://forum.snapcraft.io/t/the-gadget-snap/696 with the new role types that ondra introduced for lk?
[09:33] <abeato> pedronis, I think I can do the edit if you are fine with that
[09:35] <mup> Bug #1803002 changed: Multiple SELinux alerts on install / uninstall on Fedora 29 <Snappy:Fix Released> <https://launchpad.net/bugs/1803002>
[09:43] <mup> PR snapd#7563 opened: interfaces: bump system-key version (and keep on bumping) <Created by chipaca> <https://github.com/snapcore/snapd/pull/7563>
[09:45] <Chipaca> mborzecki, mvo, maybe something like this ^
[09:46]  * pstolowski walk, bbiab
[09:51] <mborzecki> Chipaca: why 9 though? :)
[09:52] <Chipaca> mborzecki: git log -p interfaces/system_key.go
[09:52] <mborzecki> Chipaca: fair enough
[09:52] <Chipaca> mborzecki: and count fields added/removed
[09:52] <Chipaca> there's 8 additions and 1 removal
[09:52] <Chipaca> mborzecki: also, it just lines up with the number of fields
[09:52] <Chipaca> so, yay for coincidences
[09:54] <mup> PR snapd#7564 opened: interfaces: add cgroup-version to system-key <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7564>
[09:54] <Chipaca> mbuahah
[09:54] <mborzecki> Chipaca: ok, so ^^ depends on your PR
[09:54] <Chipaca> aww
[09:55]  * Chipaca likes it when nice things are said about code he wrote
[10:03] <pedronis> abeato: yes, please do edit, and ping me when is done, I can check
[10:03] <mborzecki> pedronis: do you think we should explicilty error out on mon1-mon1 (which is the same as mon1)?
[10:04] <abeato> pedronis, cool, will do
[10:04] <pedronis> abeato: (I was in meeting)
[10:04] <abeato> :)
[10:05] <pedronis> mborzecki: seems unlikely enough that it might make sense, can be a follow up though
[10:05] <mborzecki> pedronis: ok, i'll push the tweaks only then, and leave this for the next PR
[10:11] <mborzecki> pedronis: updated #7443
[10:11] <mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
[10:21] <abeato> pedronis, I've updated https://forum.snapcraft.io/t/the-gadget-snap/696 now
[10:22] <mvo> Chipaca: really nice PR!
[10:22] <mvo> mborzecki: reading backlog now
[10:27] <Chipaca> I need to go move my car, will bbiab
[10:31] <mborzecki> zyga:  hmmm https://paste.ubuntu.com/p/7KmCHRxVGC/ that's on disco
[10:32] <mborzecki> zyga:  it's as if snap.mount was started after snap-core-*.mount
[10:38] <thresh> howdy.  is there are repo for 18.04 with a recent snapcraft in .deb?
[10:45] <abeato> sil2100, I have updated and added comments to https://github.com/CanonicalLtd/ubuntu-image/pull/175
[10:46] <mup> PR CanonicalLtd/ubuntu-image#175: Little kernel bootloader support <Created by alfonsosanchezbeato> <https://github.com/CanonicalLtd/ubuntu-image/pull/175>
[10:53] <mup> Bug #1652265 changed: Initialization changes are removed right after first boot <Snappy:Invalid> <https://launchpad.net/bugs/1652265>
[10:57] <mup> Bug #1654130 changed: Adding a tag indicating manual connection is needed when displaying interfaces <snapd:Triaged> <https://launchpad.net/bugs/1654130>
[10:57] <mup> PR snapd#7565 opened: snap-repair: add addtional comment about trust in runner.Verify() <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7565>
[11:03] <mup> Bug #1750840 changed: [Enhancement] Please show (optionally) size consumed by snap in snap list <enhancement> <Snappy:New> <https://launchpad.net/bugs/1750840>
[11:03] <mup> PR snapd#7566 opened: snap-repair: add missing check in TestRepairBasicRun <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7566>
[11:08] <pstolowski> degville: another one: https://bugs.launchpad.net/snappy/+bug/1790153 (i've no idea if the suggestion for the bug report is correct, may need verification)
[11:08] <mup> Bug #1790153: Documentation: easy-openvpn typos <Snappy:New> <https://launchpad.net/bugs/1790153>
[11:08] <Chipaca> pstolowski: WRT comparing keys with deepequals, the issue is that current code assumes that a key that looks at some aspect and determines it to correspond with go's default value (e.g. an empty list), and a key that doesn't look at that aspect at all, compare as equal when they're not
[11:09] <degville> pstolowski: thanks - I'll check and update.
[11:09] <pstolowski> Chipaca: hmm i see, ok
[11:10] <pstolowski> degville: sorry, one more: https://bugs.launchpad.net/snappy/+bug/1749538
[11:10] <mup> Bug #1749538: refresh time docs lacks the correct command <docs> <Snappy:New> <https://launchpad.net/bugs/1749538>
[11:11] <pedronis> zyga: hi, I sent you a non-urgent email about forum gardening
[11:13] <degville> pstolowski: it's no problem, but the bigger issue is these are for Core Docs which have many more problems than these small issues, all of which is being worked on separately (the 'report issue' link on those pages goes to Snappy on LP, which is why we're getting them).
[11:13] <mvo> pedronis: I sent the mail about repair assertion test now and CCed you
[11:13] <mvo> pedronis: hope it did reach you :)
[11:13] <pedronis> mvo: saw it
[11:14] <pstolowski> degville: uhm, i see. can they be re-assigned manually to Core Docs then?
[11:14] <degville> pstolowski: not sure there's a single entity we can assign them to.
[11:14] <mvo> pedronis: great, no action needed just wanted to double check that my mail setup is happy again
[11:16] <zyga> pedronis: ack
[11:16] <degville> pstolowski: I'll bring it up in the standup, but I think it's probably best these are won't fix while we wait for the updated Core Docs to be published and replace these old ones.
[11:16] <mup> PR snapd#7567 opened: snap-repair: error if run as non-root <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7567>
[11:28] <mup> PR snapd#7568 opened: snap: when running `snap repair` without arguments, show hint <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7568>
[11:30] <Chipaca> is there a way to get apparmor confinement working in debian? (in a forum-explainable way)
[11:30] <mup> PR snapd#7552 closed: tests: add new option "invert" to retry-tool <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7552>
[11:30] <Chipaca> if so please https://forum.snapcraft.io/t/use-classic-confinement-for-dynocsv-app/13543/10?u=chipaca
[11:32] <sil2100> abeato: thanks!
[11:49] <Chipaca> mborzecki: #7564 has conflicts
[11:49] <mup> PR #7564: interfaces: add cgroup-version to system-key <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7564>
[11:49] <mup> PR snapd#7563 closed: interfaces: bump system-key version (and keep on bumping) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7563>
[11:49] <mborzecki> Chipaca: ack, thx
[11:49] <Chipaca> mborzecki: :-)
[12:00] <mup> PR snapd#7256 closed: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
[12:02] <dot-tobias> ogra: Do you have experience with USB WiFi dongles on Raspberry Pi 3B/3B+ running Ubuntu Core? I'm planning to add dual interface support to my gadget, currently investigating proper dongles since the official Raspberry one is now EOL
[12:09] <mup> PR snapd#7569 opened: snap: remove limit of 32 characters for version <Created by cjp256> <https://github.com/snapcore/snapd/pull/7569>
[12:09] <mup> PR snapd#7570 opened: [RFC] snap-mount-dir: add mount unit for snap-mount-dir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7570>
[12:11] <ogra> dot-tobias, not with core, i have used dongles before on a pi2, if you get one the kernel supports OOTB it should just work on core though
[12:12] <dot-tobias> ogra: Thanks! Do you happen to know where I can find info which ones have kernel support (I guess chipset names)?
[12:12] <ogra> (i used to use a wired USB dongle on my dragonboard with core for quite some time ... that worked well too, i dont see a reason why a wlan one should be any different (as long as there is a driver in the kernel)
[12:13] <ogra> hmm not really ... i think asix and realtek might be a good bet
[12:39] <mborzecki> Chipaca: i've updated #7564
[12:40] <mup> PR #7564: interfaces: add cgroup-version to system-key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7564>
[12:57] <mup> PR snapd#7569 closed: snap: remove limit of 32 characters for version <⛔ Blocked> <Created by cjp256> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7569>
[13:01] <Chipaca> 2fa...
[13:38] <mup> PR snapcraft#2746 opened: elf: handle missing dependencies not found on system <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2746>
[13:57] <zyga> rogpeppe: flashing now
[13:57] <zyga> mvo: ^ that magic SD card
[14:01] <zyga> mborzecki: I fixed the instance problem
[14:12] <mup> PR snapd#7571 opened: sandbox/cgroup: refactor process cgroup helper to support v2 and named hierarchies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7571>
[14:12] <mborzecki> zyga: ^^ prepping up for named hierarchy
[14:13] <vidal72[m]> is there an official way to pass additional env var to snap, like flatpak --env=xxx?
[14:13] <Chipaca> vidal72[m]: in what sense?
[14:14] <Chipaca> vidal72[m]: usually if it's an app, it'll get most of your environment as is
[14:14] <Chipaca> vidal72[m]: if it's a service, you can use 'systemctl edit'
[14:14] <vidal72[m]> Chipaca: I want to add anv env which isn't in global environment
[14:14] <Chipaca> vidal72[m]: as a user, or as a packager?
[14:15] <vidal72[m]> user
[14:15] <Chipaca> vidal72[m]: FOO=bar the-thing-to-run
[14:17] <vidal72[m]> yeah, however this work only if I run it directly
[14:18] <Chipaca> vidal72[m]: as opposed to what?
[14:18] <vidal72[m]> btw is TMPDIR honored by snap?
[14:18] <Chipaca> no
[14:18] <Chipaca> bah
[14:18] <Chipaca> no, but
[14:18] <Chipaca> the snap binary will get it
[14:18] <Chipaca> so it's up to that
[14:19] <Chipaca> that is: if you do TMPDIR=/foo/bar some-snapped-app
[14:19] <Chipaca> snap won't do anything with TMPDIR, but will pass it in
[14:19] <vidal72[m]> Chipaca: as opposed to some launcher
[14:19] <Chipaca> whether soem-snapped-app does something with it is up to that app
[14:20]  * Chipaca checks
[14:20] <Chipaca> actually that might be wrong
[14:20] <vidal72[m]> I wondered because TMPDIR is usually dropped by suid binaries
[14:20] <Chipaca> yeah it looks like TMPDIR and TEMPDIR are not passed in
[14:21] <Chipaca> ah well
[14:21] <Chipaca> vidal72[m]: was that the env var you were wanting to set?
[14:22] <vidal72[m]> one of them :)
[14:22] <Chipaca> vidal72[m]: you could copy (or edit in place) the generated .desktop file
[14:23] <Chipaca> vidal72[m]: it'll be in /var/lib/snapd/desktop/applications
[14:23] <vidal72[m]> yes, however if desktop file changes with some update I will miss it
[14:23] <Chipaca> vidal72[m]: if you go for 'copy', copy it to ~/.local/share/applications, but be mindful of refreshes
[14:23] <Chipaca> exactly
[14:24] <mvo> zyga: omg! I can't wait to see/hear results
[14:25] <vidal72[m]> my concrete use case was opening files in external apps in firefox which needs both GTK_USE_PORTAL and TMPDIR
[14:25] <vidal72[m]> unfotunately for what I read snap thinks it's mozilla issue to solve and mozilla thinks it's snap's :)
[14:26] <mup> PR snapcraft#2742 closed: cli: use click utilities for login prompts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2742>
[14:28] <Chipaca> vidal72[m]: ?
[14:28] <Chipaca> vidal72[m]: it's not just a matter of setting env vars
[14:29] <vidal72[m]> does snap support xdg-portal?
[14:29] <Chipaca> vidal72[m]: yes
[14:30] <Chipaca> wait
[14:30] <Chipaca> no
[14:30] <Chipaca> vidal72[m]: no
[14:30] <Chipaca> not yet
[14:30] <vidal72[m]> ah
[14:30] <Chipaca> vidal72[m]: it's almost all there though
[14:31] <Chipaca> vidal72[m]: (on master)
[14:31] <Chipaca> in fact i think master might already have all the bits
[14:32] <Chipaca> hm, there might be a couple of PRs still pending
[14:32] <Chipaca> vidal72[m]: jamesh knows more (probably asleep now though)
[14:32] <vidal72[m]> anyway for FF the problem is namespaced /tmp and lack of TMPDIR override
[14:33] <vidal72[m]> so even with xdg-portal support it won't work
[14:33] <vidal72[m]> https://forum.snapcraft.io/t/sharing-files-via-tmp/1613/15
[14:34] <Chipaca> vidal72[m]: I don't think namespaced tmp will break once we have portals, I don't see how it would, but if it does we can probably fix it
[14:35] <Chipaca> vidal72[m]: that topic is not about portals at all
[14:35] <zyga> mvo: I need to clean my desk :D
[14:35] <vidal72[m]> Chipaca: well it break even flatpak
[14:35] <zyga> mborzecki: ack
[14:35] <zyga> looking now
[14:35] <vidal72[m]> which jas full portal support
[14:36] <mvo> xnox: is it a known issue that "test memory" on the eoan daily installier just gives an error and does not load anything?
[14:36] <vidal72[m]> the thing is FF/TB always saves temp files to /tmp or TMPDIR and they won't be visible for any other app
[14:37] <Chipaca> vidal72[m]: and what does that have to do with portals?
[14:37] <mvo> xnox: ups, that is disco, flashed the wrong thing
[14:37] <vidal72[m]> Chipaca: the portal passes file app can't reach and fail
[14:38] <vidal72[m]> what they do in flatpak is setting TMPDIR=xxx in wrapper
[14:39] <ogra> well, that wouldnt work in snaps
[14:39] <ogra> since /tmp is a very special dir inside the confinement
[14:39] <xnox> mvo:  yes
[14:40] <xnox> mvo:  are you on bios or uefi?
[14:40] <vidal72[m]> ogra: the point is to set something else than /tmp
[14:40] <zyga> mborzecki: reviewed, please check
[14:40] <ogra> while you could set $TMPDIR it could point only to some dir inside the confined area anyway ...
[14:40] <vidal72[m]> ogra: Chipaca like this https://src.fedoraproject.org/rpms/firefox/blob/0adc4aecec45e195b0f6cbcdb1625839846482bc/f/firefox.spec#_710
[14:40] <mvo> xnox: uefi
[14:41] <mvo> xnox: is it just a problem on uefi?
[14:41] <Chipaca> ogra: well, snap-confine has special handling of TMPDIR and TEMPDIR, so
[14:41] <ogra> vidal72[m], where would you set it to ? it wouldnt be any dir thats accessible on the filesystem because it lives in the confined space
[14:41] <vidal72[m]> ogra: yes but not every dir is namespaced likr /tmp
[14:41] <ogra> so something outside of that space wouldnt see it
[14:42] <xnox> mvo:  not really. It's just there is a uefi app we ship that one can execute for memory testing on uefi.
[14:42] <xnox> mvo:  not sure if that is hooked up correctly w.r.t. secureboot etc. at one point it wasn't.
[14:42] <xnox> in general it should work
[14:43] <xnox> mvo:  is your machine busted? and can you run the vendor's self-test from bios stuff?
[14:43] <mvo> xnox: ok, once I finished flashing eoan I will give it a go and if it fails pester someone - who is the best person?
[14:43] <vidal72[m]> ogra: does snap namespace /run/user/$uid?
[14:43] <mvo> xnox: not busted, just wanted to play with it to see if memory is stble
[14:43] <xnox> mvo:  cyphermox who is off today i think. or just open a bug against
[14:43] <ogra> Chipaca, sure, the point is that the portal runs on your desktop, unconfined ... while FF runs inside the confined space ....
[14:44] <mvo> xnox: cool, will give it a go, thank you! (usb stick takes forever to write :/
[14:44] <xnox> mvo:  against shim
[14:44] <Chipaca> i'm off to the doc's
[14:44] <Chipaca> ttfn
[14:45] <mvo> xnox: ta
[14:45] <Floflobel_> hello, how can I see the history of all "refresh" that snapd has performed?
[14:45] <vidal72[m]> ogra: https://forum.snapcraft.io/t/firefox-url-handler-does-nothing/5329/6 and https://bugzilla.mozilla.org/show_bug.cgi?id=1461759
[14:45] <ogra> vidal72[m], you could try pointing FF to $SNAP_USER_DATA (which translates to ~/snap/firefox/current/)
[14:45] <ogra> thats one of the two dirs that can be used to share data with the host
[14:46] <ogra> (the other is $SNAP_DATA but thats only root writable (for services/daemons and such))
[14:47] <vidal72[m]> yes, but but it have to be done through TMPDIR=$SNAP_USER_DATA and this is blocked
[14:47] <vidal72[m]> unless you add it to shell wrapper
[14:48] <vidal72[m]> which will be overwrittent with update...
[14:48] <zyga> vidal72[m]: please file a bug with the details and I will consider it
[14:48] <vidal72[m]> zyga: I linked to opened bugs
[14:48] <zyga> vidal72[m]: thanks, I'll add them to my backlog
[14:49] <zyga> vidal72[m]: I'm debugging something else and I cannot focus on this problem but I want to say I'm interested
[14:49] <vidal72[m]> I think it's mozilla job but they don't seem to agree
[14:49] <vidal72[m]> zyga: no problem, thx
[14:54] <ogra> vidal72[m], well, i'm pretty sure the issue is that you try to override it ... if TMPDIR was simply set in the snapcraft.yaml of the firefox snap i bet it would work ... so yeah, that would be a firefox issue after all ... us lacking a mechanism to override would be our issue (though i guess that will need some deep securit review first)
[14:57] <vidal72[m]> does TMPDIR from snapcraft.yaml passes through snap suid binary?
[14:57] <zyga> vidal72[m]: no but there's a mechanism to do so
[14:57] <zyga> vidal72[m]: there's a pass-through system
[14:57] <zyga> vidal72[m]: it may also be a bug that setting TMPDIR is not respected in practice but that's a simple fix if so
[15:00] <vidal72[m]> flatpak has same issue if bubblewrap is installed as suid https://github.com/flatpak/flatpak/issues/2641
[15:53]  * cachio lunch
[15:59] <mup> PR snapd#7572 opened: gadget: rename "boot{select,img}" -> system-boot-{select,image} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7572>
[16:14] <mvo> xnox: memtest works on eoan usb installer, sorry for the noise. but a different question I installed eoan now (on real HW) on an uefi system with the default installer options and it looks like it did not create a uefi system partition for me - didn't it do that in the past?
[16:15] <xnox> mvo: there usually is one already, and we always reuse it.
[16:16] <xnox> mvo:  so didn't create => do you mean you have no esp and booted the usb stick in bios mode?
[16:16] <mvo> xnox: its a fresh disk with nothing on it
[16:16] <xnox> mvo:  give me your /var/log/installer/
[16:16] <mvo> xnox: I might have booted in bios mode
[16:16] <xnox> mvo:  how did you create the usb stick?
[16:16] <mvo> xnox: I selected boot menu and usb stick but that might have triggered bios
[16:16] <mvo> xnox: let me retry this
[16:16] <xnox> mvo:  boot menu may list the usb stick multiple times.
[16:17] <mvo> xnox: do you still want the log?
[16:17] <xnox> mvo:  pick the one that sounds fanciest.
[16:17] <xnox> mvo:  just try rebooting
[16:17] <mvo> xnox: doing now
[16:17] <xnox> mvo:  also you might want to disable legacy boot fallback in bios
[16:17] <mvo> xnox: uefi makes this all rather annoying
[16:17] <xnox> mvo:  cause then it will not show you the bios boot options of the stick
[16:17] <mvo> xnox: sometimes I wonder how our users manage to install stuff :/
[16:18] <xnox> unfortunately we kind of have to make the sticks "dual-bios-uefi" bootable
[16:18]  * mvo is maybe just getting dumb
[16:18] <xnox> mvo:  they go to azure.com and click the biggest orange button they see
[16:18] <mvo> xnox: hahaha
[16:21] <mvo> xnox: yeah, selecting the "other" usb stick in the boot menu did the trick, thanks again and sorry for the noise
[16:32] <mup> PR snapcraft#2747 opened: nodejs plugin: fix errors when building in confinement <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2747>
[17:05]  * Chipaca ⇝ dinner
[18:02] <mvo> Chipaca: 7533 could do with a re-review, hopefully I addressed all your points
[18:16] <mup> PR snapd#7533 closed: client: add support to use the new "download" API <Needs Samuele review> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7533>
[18:44] <mup> PR core-build#55 opened: Drop abootimg support, not used anymore <Created by xnox> <https://github.com/snapcore/core-build/pull/55>
[19:10] <mup> PR snapd#7565 closed: snap-repair: add additional comment about trust in runner.Verify() <Needs Samuele review> <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7565>
[19:33] <mup> PR snapd#7510 closed: daemon: make /v2/download take snapRevisionOptions <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7510>
[19:59] <mup> PR snapd#7573 opened: [RFC] client: add support for the new "/v2/assertions/%s?remote=true" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7573>
[20:26] <mup> PR snapd#7574 opened: [RFC] client: add KnownOptions to Know() and support remote assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7574>
[23:24] <mup> PR snapd#7575 opened: cmd/model: add authority-id to verbose fields <Needs Samuele review> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7575>