[00:02] <mup> PR snapcraft#2291 closed: meta: put environment into runner instead of app wrapper <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2291>
[05:12] <mborzecki> morning
[05:50] <zyga> o/
[05:50] <zyga> I’m feeling somewhat better.
[05:51] <luk3yx> Hello
[05:55] <zyga> Hey
[05:56] <zyga> The store is fully operational again, great!
[06:01] <mborzecki> zyga: hey
[06:21] <mup> PR snapd#5805 closed: cmd/snap-update-ns: enforce trespassing checks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5805>
[06:21]  * zyga is happy to land that
[06:25] <mup> PR snapd#5864 closed: make sure hostnamectl can be used on core too <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5864>
[06:38] <mup> PR snapd#5857 closed: userd: extend the list of supported XDG Desktop properties when autostarting user applications <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5857>
[06:39] <mup> PR snapd#5840 closed: interfaces/apparmor, interfaces/builtin: tweaks for parallel snap installs <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5840>
[06:51] <mvo> 5571 should be an easy win (just needs a second review)
[06:54] <mborzecki> mvo: 5571 appears to be merged, did you mean another pr?
[06:54] <mborzecki> 5771 maybe?
[06:54] <mvo> mborzecki: yes, sorry
[06:54] <mvo> clearly more tea is needed :)
[07:04] <pstolowski> Morning
[07:06] <mup> PR snapd#5771 closed: selftest: add test to ensure selftest.checks is up-to-date  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5771>
[07:06] <zyga> mvo: trespassing fix is merged, shall I propose a PR to take layouts out of beta?
[07:07] <zyga> mvo: full disclaimer, I'm investigating a bug that is related to propagation settings
[07:07] <zyga> so perhaps not yet but then again, it would help a lot of people with simple layouts already
[07:08] <mvo> zyga: let do it
[07:08] <mvo> zyga: and we can wait with the merge until you finished your investigation
[07:08] <zyga> ok
[07:08] <mvo> zyga: but this way spread can run etc
[07:20] <mborzecki> nice to see the diff in #5596 so short, nearly all i had in the integration branch is now in
[07:21] <mup> PR #5596: [WIP] Parallel installs integration <Blocked> <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
[07:22] <mvo> mborzecki: hm, this looks like the integration PR juts contains some more tests, so time to merge those too?
[07:23] <mborzecki> mvo: i'll push those separately along with couple enhancements to other tests
[07:24] <mvo> mborzecki: cool
[07:24] <mborzecki> but first coffee
[07:35] <mup> PR snapcraft#2300 opened: [WIP] plugins: remove implicit source <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2300>
[07:41] <mup> PR snapd#5866 opened: tests: remove unneeded cleanup from layout tests <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5866>
[07:43] <mup> PR snapd#5867 opened: many: enable layouts by default <Created by zyga> <https://github.com/snapcore/snapd/pull/5867>
[07:46] <zyga> mvo: ^ done
[07:51] <mvo> zyga: ta
[08:02] <mvo> zyga: hm, curious, why switching the default instead of juts removing the option entirely?
[08:02] <mvo> zyga: I mean, whats the use-case, someone who feels uncomfortable with layout should still be able to disable them?
[08:02] <luk3yx> If I make my snap private, will existing users continue getting updates?
[08:02] <luk3yx> And can people still install it by snap name?
[08:03] <luk3yx> (I want a semi-private snap so people download the "official" snap instead)
[08:03] <kyrofa> zyga, mvo do you guys have any thoughts on this? https://forum.snapcraft.io/t/snaps-are-broken-in-bionic-lxd-container/7339
[08:03] <mup> PR snapd#5868 opened: tests/main/snap-env: extend to cover parallel installations of snaps <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5868>
[08:07] <mvo> kyrofa: can you please try the switch core to "edge"?
[08:08] <mvo> kyrofa: we fixed this recently but its not in beta yet, hopefully by EOD though
[08:09] <kyrofa> mvo, will do, thanks
[08:13] <zyga> re
[08:14] <zyga> kyrofa: replied
[08:15] <ackk> hi, I'm getting the following error running snapcraft: ImportError: /snap/snapcraft/2022/lib/python3.5/site-packages/nacl/_sodium.abi3.so: undefined symbol: crypto_pwhash_argon2id_opslimit_moderate
[08:16] <zyga> kyrofa: or how your new neighbours might have said if they spoke broken Spanish like I do: yo ha añadido una respuesta
[08:17] <kyrofa> akk interesting, we've started getting that as well
[08:17] <kyrofa> But it doesn't seem consistent-- you?
[08:17] <zyga> Chipaca: heey
[08:17] <zyga> around?
[08:18] <Chipaca> zyga: (y)
[08:18] <kyrofa> Urgh... why can't I cancel spread...
[08:18] <zyga> Chipaca: I'd like to add a tweak to yams loader for snap.yaml to indicate an error if "layouts" (plural) is used over the singular correct form
[08:18] <zyga> Chipaca: I was thinking of a simple new entry to deserialise with the different name
[08:19] <zyga> Chipaca: but if you have a better idea I'm all ears
[08:19] <Chipaca> kyrofa: you can, it just takes a bit
[08:19] <Chipaca> kyrofa: it delays because it shuts down the remotes, which can take a while to respond
[08:20] <Chipaca> kyrofa: you can also ctrl-backslash, and then use the .spread* to clean up
[08:21] <Chipaca> zyga: I wonder if there's a way to throw an error on anything unparsed
[08:21] <zyga> Chipaca: mmm, that may be future-proof nasty
[08:21] <zyga> I'd rather not
[08:21] <kyrofa> Chipaca, ah, ctrl-backslash will do it!
[08:23] <Chipaca> kyrofa: usually you can then tell spread itself to clean up using e.g. spread -reuse-pid=<the appropriate number from inspecting .spread*> -discard
[08:23] <Chipaca> kyrofa: spread itself will also tell you what the right argument for -reuse-pid is in its log, if it's still in your scrollback
[08:23] <Chipaca> zyga: good point
[08:24] <kyrofa> Chipaca, just --reuse --discard seems to work
[08:25] <zyga> Chipaca: but we could _warn_ about it
[08:25] <zyga> (wink wink)
[08:25] <Chipaca> zyga: if only we had something like that
[08:25] <zyga> right
[08:25]  * Chipaca gets back to writing stuff on the forum
[08:26] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/5869
[08:26] <mup> PR #5869: snap: detect layouts vs layout in snap.yaml <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
[08:27] <mup> PR snapd#5869 opened: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
[08:27] <Chipaca> zyga: what about: TypeLouts errorCatcher
[08:27] <Chipaca> zyga: and then, type errorCatcher struct{}
[08:27] <zyga> errorCatcher?
[08:27] <zyga> ah
[08:27] <Chipaca> zyga: and then, func (errorCatcher) UnmarshalYAML(...)
[08:27] <zyga> and fail on deserialise?
[08:27] <zyga> :D
[08:27] <zyga> yeah
[08:27] <zyga> ++
[08:27] <zyga> I'll do that, great idea
[08:28] <zyga> but...
[08:28] <zyga> how to tweak the error message then?
[08:28] <Chipaca> hmmmm
[08:28] <zyga> no < > to specialise
[08:28] <zyga> still
[08:28] <zyga> I could use a generic type
[08:28] <Chipaca> zyga: make it a layoutsErrorCatcher for now, we can worry about making it generic later
[08:29] <zyga> and subtype it
[08:29] <zyga> yes
[08:29] <zyga> +1
[08:32] <zyga> Chipaca: actually, we can use the struct tags for that
[08:32] <Chipaca> zyga: we can?
[08:32] <Chipaca> zyga: i thought that'd be visible one step up
[08:33] <zyga> Chipaca: TypoLayouts errorCatcher `yaml:"layouts,omitempty",hint:"yada yada"`
[08:33] <zyga> something like that?
[08:33] <Chipaca> zyga: does the errorCatcher deserialiser "see" that hint?
[08:33] <zyga> not sure yte
[08:33] <zyga> looking at this part now
[08:34] <pedronis> #5833 needs a 2nd review
[08:34] <mup> PR #5833: asserts,interfaces/policy: add support for on-store/on-brand/on-model plug/slot rule constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5833>
[08:41] <jamesh> If errorCatcher is implementing yaml.Marshaler, I doubt it would have access to the tag
[08:42] <zyga> yeah, that's what I see so far
[08:42] <zyga> I'm still looking for _a_ way
[08:42] <jamesh> it'd have a pointer to the struct member passed as the receiver, but no way of knowing that it is a member of the struct
[08:42] <jamesh> making the struct itself implement yaml.Marshaler on the other hand might do the trick
[08:43] <zyga> but then we're back to square one with explicit checking per-field like I do nwo
[08:43] <zyga> *now
[08:44] <zyga> it _feels_ like schema
[08:44] <mup> PR snapd#5813 closed: image: warn on missing default-providers <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5813>
[08:44] <zyga> so maybe the simple fix I did now is OK before we have schema support
[08:44] <Chipaca> niemeyer: mvo: how much do we still care about old local revisions? I'm talking about local revisions from before we went negative for local
[08:45] <Chipaca> that is, revisions above 100000
[08:45] <Chipaca> we have tests for them, but I suspect we don't really support them any more outside of those tests
[08:50] <mup> PR snapd#5870 opened: tests/main/parallel-install-services: add spread test for snaps with services <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5870>
[08:59] <niemeyer> Chipaca: My only concern is people using these after installing an old image
[08:59] <zyga> Chipaca: I abandon this idea now,
[09:00] <Chipaca> niemeyer: ack
[09:19]  * zyga -> coffee and snack
[09:26] <Chipaca> mvo: what should I tag warnings as? 2.36?
[09:29] <mvo> Chipaca: yes
[09:29] <mvo> Chipaca: what is missing there?
[09:29] <mvo> Chipaca: I kind of hope to do 2.36 later today
[09:30] <Chipaca> mvo: https://forum.snapcraft.io/t/warnings/7599
[09:30] <Chipaca> mvo: that :-)
[09:30] <Chipaca> degville: https://forum.snapcraft.io/t/warnings/7599
[09:31] <Chipaca> degville: let me know if you can't edit that and want to
[09:31] <Chipaca> (i know you want to :-p)
[09:31] <zyga> Chipaca: how do you feel about adding a warning that warnings are added to everyone refreshing from old snapd? :)
[09:31] <zyga> (and then we remove it in the next release)
[09:32] <Chipaca> zyga: before answering I need to know how many other bad ideas you've had today
[09:32] <zyga> Chipaca: ... I need to re-think the idea to get up in the morning
[09:32] <Chipaca> zyga: I liked at the sprint where you'd announce "this is bad idea #N++"
[09:33] <zyga> :D
[09:33]  * zyga is now being honest
[09:33] <Chipaca> zyga: my main problem with your idea here is that it'd be the _only_ warning the user'd see
[09:33] <zyga> oh
[09:33] <zyga> in that case it'd be futile
[09:33] <Chipaca> zyga: because warnings are there, but nothing uses them as yet
[09:33] <Chipaca> that's 2.37 material
[09:33] <zyga> any low hanging fruit?
[09:34] <zyga> in that case I'd postpone the idea to 2.37
[09:34] <Chipaca> zyga: egrep -ir '(todo|xxx).*warn'
[09:34] <Chipaca> zyga: and, my secondary problem with your idea is that if we need to do that, then we failed to make them obvious and discoverable and subtle and non-intrusive
[09:35] <zyga> warning: your snapd has updated to x.yz, featuring new functionality and bug fixes
[09:35] <zyga> but that's not a warning
[09:36] <Chipaca> zyga: and it'll train the user to ignore them
[09:36] <zyga> mmm, perhaps but that would be a nice touch
[09:36] <Chipaca> so, yeah, -1
[09:36] <zyga> "snapd is getting better while you are to looking"
[09:37] <pedronis> please rate snapd
[09:37] <zyga> mmm, those are way more annoying
[09:37] <mup> PR snapd#5871 opened: snapstate: only report errors if there is an actual error  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5871>
[09:37] <zyga> because they are like beggars asking for a coin, here it's more of a "what's new"
[09:38] <pedronis> anyway lots of our users will not see warnings unless gnome-software learns about them
[09:38] <zyga> yeah, that's true
[09:38] <zyga> it'd be more welcome if any app could do it
[09:38] <zyga> well, back to propagation
[09:38] <pedronis> the app can do it inside themselves
[09:39] <zyga> yeah but if all apps could do it in a standardised way through gnome-software it would be nice
[09:39] <pedronis> maybe, maybe not
[09:39] <pedronis> everything already wants to speak to me
[09:40] <Chipaca> pedronis: that's because you're famous
[09:42] <mup> PR snapd#5872 opened: tests/main/parallel-install-local: rename from *-sideload, extend to run snaps <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5872>
[09:43] <zyga> today Alice in wonderland would have to agree to a privacy policy, EULA and limited warranty before falling down the rabbit hole
[09:50] <diddledan> she wouldn't read them thoroughly, though, or at all, and therefore be violated without her knowing
[09:52] <mup> PR snapd#5866 closed: tests: remove unneeded cleanup from layout tests <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5866>
[09:53] <zyga> thanks!
[10:09] <mup> PR snapd#5873 opened: tests/main/parallel-install-store: run installed snap <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5873>
[10:13] <joc> is there any particular reason why core18 edge hasnt seen an update for about 3 weeks now?
[10:14] <diddledan> joc: is there a problem with what's there now?
[10:14] <joc> was hoping for at least a build with ping back as per https://forum.snapcraft.io/t/core18-included-binaries/7191/14
[10:17] <zyga> joc: yes
[10:18] <zyga> joc: it's because when it is stable we cannot break it
[10:18] <zyga> so that decision was postponed
[10:18] <zyga> joc: I _believe_ this is now the decision of the foundation team though
[10:18] <zyga> mvo: ^
[10:18] <joc> zyga: makes sense for stable channel but was looking at edge
[10:19] <zyga> oh, I missed that, sorry
[10:19] <zyga> in that case I don't know
[10:19] <joc> maybe the transfer to foundations is the reason for the hiatus
[10:31] <mup> Bug #1771793 changed: Interface for hardware temperature monitoring <Snappy:Invalid> <https://launchpad.net/bugs/1771793>
[10:31] <diddledan> mup is slow, I changed that bug 4 minutes ago! :-p
[10:31] <mup> Bug #4: Importing finished po doesn't change progressbar <iso-testing> <lp-translations> <Launchpad itself:Fix Released by carlos> <Ubuntu:Invalid> <https://launchpad.net/bugs/4>
[10:31] <diddledan> haha
[10:32] <diddledan> silly bot
[10:32] <zyga> when the machines rebel mup will remember you said that ;)
[10:33] <diddledan> I, for one, welcome our shiny metal overlords
[10:34] <diddledan> https://memegenerator.net/img/instances/27465850/kiss-my-shiny-metal-ass.jpg
[10:35] <zyga> https://imgflip.com/i/2iu79t
[10:41] <diddledan> nice!
[10:46] <Son_Goku> haha
[10:46] <Son_Goku> ah bender and morpheus
[10:48] <mborzecki> cachio has set up centos images, 2018-09-27 12:47:06 Sending project content to google:centos-7-64 (sep271046-416264)...
[10:50] <mvo> joc: ping is back but the core18 snap is held up in manual review because of this, sil2100 is working on fixing this AIUI
[10:51] <ackk> hi, question about the nodejs plugin: shouldn't it run "yarn install" (with node-package-manager: yarn) automatically during the build phase?
[10:52] <diddledan> ackk: I don't think yarn support works right now
[10:53] <ackk> diddledan, looking at https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/nodejs.py#L178 it seems it does
[10:53] <ackk> diddledan, I mean by setting node-package-manager to yarn I do get yarn installed, but it doesn't really install stuff from the yarn.lock file automatically
[10:53] <diddledan> yes, that's what I'm referring to. it's broken.
[10:54] <ackk> ah, I see
[10:54] <ackk> diddledan, fwiw https://paste.ubuntu.com/p/tYJPk9bt6K/ worked for me
[10:57] <kyrofa> diddledan, akk can one of you please log a bug about that?
[10:58] <ackk> diddledan, maybe you have a bit more context for the bug ^ ?
[10:59] <diddledan> I haven't really dug into it. I meant to, but then forgot :-)
[11:04] <diddledan> https://bugs.launchpad.net/snapcraft/+bug/1794727
[11:04] <mup> Bug #1794727: node plugin doesn't run yarn install during build <Snapcraft:New> <https://launchpad.net/bugs/1794727>
[11:07] <rbasak> snapcraft edge channel broken? beta works. edge failure: https://paste.ubuntu.com/p/GW4gWH4nrC/
[11:07] <rbasak> kyrofa, sergiusens: ^
[11:09] <rbasak> edge 2022; beta 1871
[11:09] <diddledan> rbasak: kyrofa is working on it
[11:10] <kyrofa> rbasak, thank you for letting us know, very nice to have folks testing edge :)
[11:11] <kyrofa> All over it
[11:11] <rbasak> Great, thanks :)
[11:12] <mborzecki> Chipaca: warnings aren't pushed by anything yet, are they?
[11:17]  * zyga needs to take the dog for a walk
[11:19] <diddledan> zyga: going dogging, eh? ;-p
[11:20] <diddledan> I really should take myself for a walk occasionally ;-D
[11:20] <diddledan> <-- lazy
[11:26] <Chipaca> mborzecki: correct; sudo http snapd:///v2/debug action=add-warning message="hello world"
[11:28] <jdstrand> mborzecki: hi! fyi, was looking at pt 5594 and noticed something. see https://github.com/snapcore/snapd/pull/5594/files#r220886654
[11:28] <mup> PR #5594: snap/snapenv: add snap instance specific variables <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5594>
[11:28] <mborzecki> jdstrand: looking
[11:30] <jdstrand> # bind mount *not* used here (see 'parallel installs', above)
[11:30] <mborzecki> jdstrand: this was fixed later on in https://github.com/snapcore/snapd/pull/5735 which came as a result of discussion in #5713 (parallel installs mount mappings)
[11:30] <jdstrand> owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/                  r,
[11:30] <mup> PR #5735: snap/snapenv: drop some instance specific variables, use instance-specific ones for user locations <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5735>
[11:30] <mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
[11:30] <jdstrand> owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/**                mrkix,
[11:31] <mborzecki> jdstrand: so $HOME is instance specific path now, same as $SNAP_USER_DATA
[11:32] <jdstrand> ok, I see that in that pr. thanks!
[11:33] <mborzecki> jdstrand: thank you for being so thorough
[11:33] <jdstrand> mborzecki: it sounds like there isn't anything left for me with this feature?
[11:34] <mborzecki> jdstrand: not at the moment, i'll ping you if i end up doing any tweaks to the interfaces
[11:34] <jdstrand> mborzecki: ok, thanks! I bet you're pretty happy to see this coming to a close :)
[11:34] <mborzecki> jdstrand: and thanks for the reviews again :)
[11:34] <jdstrand> np :)
[11:35] <mborzecki> Chipaca: aargh, need http unix sockets extension
[11:35] <Chipaca> mborzecki: snap install http dude
[11:36] <mborzecki> publisher: John Lenton (chipaca), nice!
[11:36] <Chipaca> :-)
[11:36] <Chipaca> mborzecki: that's why it understands snapd:/// at all :-)
[11:37] <Chipaca> mborzecki: also how it's able to use snapd-control :D
[11:39] <mborzecki> Chipaca: yay, works now
[11:39] <ogra> pedronis, is it normal that i dont get a snap id here ? https://paste.ubuntu.com/p/ZNcjS2P53M/
[11:39] <mborzecki> Chipaca: any plan on where do we start springking warnings first?
[11:39] <Chipaca> mborzecki: also relevant, there's a unshow-all-warnings debug action
[11:40] <ogra> (i'm trying to pre-connect some interfaces from gadget.yaml but if the system doesnt see an id i can not really do that)
[11:40] <Chipaca> mborzecki: egrep -ir '(todo|xxx).*warn'
[11:49] <Chipaca> mvo: how're you feeling about dotfiles for 2.36?
[11:50] <zyga> diddledan: adopting a dog helped with my step count average :)
[11:50] <diddledan> :-)
[11:52] <ogra> hmm
[11:52] <ogra> Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sda1' failed with exit code 1
[11:52] <ogra> is there any chance to find out *why* it actually failed ?
[11:52] <ogra> i can manually mount the device (and it properly carries an auto-import.assertion file)
[11:53] <ogra> journalctl sadly does only print that one line ... and snap changes doesnt mention it either
[11:54] <ogra> (it is a vfat formatted usb stick)
[11:55] <Chipaca> ogra: dmesg might have more info
[11:55] <ogra> doesnt
[11:55] <Chipaca> ogra: that command is run via an udev rule
[11:55] <ogra> manually running the program helps a bit (tells me the user already exists, which is indeed true because i manually created it after the import failed)
[11:55] <Chipaca> ogra: snapd-autoimport.rules (or 66-snapd-autoimport.rules)
[11:55] <ogra> Chright, might help to connect stderr to stdout here
[11:56] <ogra> Chipaca, ^^
[11:56] <ogra> haha
[11:57]  * Chright ~> lunch-making
[11:58] <mborzecki> off to pick up the kids
[12:02] <Chipaca> niemeyer: do you want to review #5856, or should I merge it? (it has two +1s already)
[12:02] <mup> PR #5856: cmd/snap: tame the help zoo <Created by chipaca> <https://github.com/snapcore/snapd/pull/5856>
[12:03]  * Chipaca ~> really lunch
[12:07] <ogra> is there a valid way to find the name of the model from a hook without using snapd-control ?
[12:09] <niemeyer> Chipaca: If it follows what we discussed, +1
[12:10] <mup> PR snapd#5874 opened: Adding missing permission to create /run/wpa_supplicant directory <Created by kubiko> <https://github.com/snapcore/snapd/pull/5874>
[12:20] <mup> PR snapd#5875 opened: Avahi interface update <Created by kubiko> <https://github.com/snapcore/snapd/pull/5875>
[12:24] <Chipaca> niemeyer: there's a change, with a new Admin section that has version, warnings, okay, and get, set and wait (meaning the old Config section went away)
[12:25] <niemeyer> Chipaca: Hmm
[12:25] <niemeyer> Chipaca: Sounds a bit awkward at first sight
[12:25] <niemeyer> Chipaca: The whole of "snap foo" is admin
[12:25] <pedronis> ogra: looks like is locally installed
[12:25] <niemeyer> Chipaca: and get/set/wait seem unrelated to the rest
[12:25] <pedronis> in which case I think that's the current behavior
[12:26] <ogra> pedronis, indeed it is, i'm trying to develop as bunch of default connections for the interfaces
[12:26] <ogra> (trying to test them before uploading indeed)
[12:26] <ogra> ah, thats pretty unfortunate
[12:26] <pedronis> ogra: we don't print a snap id for local snaps (even if there's a corresponding store one)
[12:26] <ogra> i thought it would still pull the id from the store
[12:27] <pedronis> that output is actually a bit confusing
[12:27] <ogra> well, it results in the connections to not happening
[12:27] <pedronis> yes, connections are only for store snaps
[12:28] <pedronis> given they are snap id based
[12:28] <ogra> yeah, thats a bit bad for developing ...
[12:28] <ogra> would be nice if we could use some kind of fake id or some such ... i imaging other developers also would like to test their changes before pushing them to the store
[12:28] <ogra> *imagine
[12:29] <Chipaca> niemeyer: thing is, what we discussed didn't include warnings, so those need adding somewhere; i tried to iterate on this at the sprint but we were never not busy with other stuff :-)
[12:29] <Chipaca> niemeyer: so I thought the second best thing would be to iterate in a PR
[12:30] <niemeyer> Chipaca: Sure, and that's what we're doing here too I guess..
[12:30] <pedronis> ogra: you can always push first as private snap
[12:30] <Chipaca> niemeyer: dunno, I'm having lunch, not iterating
[12:30] <pedronis> ubuntu-image gets annoying but possible
[12:31] <ogra> pedronis, sure, i can also push just to edge and leave it there but preferably i'd like to test locally first
[12:31] <niemeyer> Chipaca: Well, you're iterating on lunch.. agile style? :)
[12:31] <ogra> anyway, i'll get around ... but it would be great to improve in that area
[12:32] <Chipaca> niemeyer: not enough beer for this to be XP, so maybe it's scrum?
[12:41] <mvo> Chipaca: dotfiles> I want it in but we can pull it into ~pre2 or ~rc1. it also need a proper name
[12:44] <Chipaca> I think dotfiles is fine
[12:46] <mvo> Chipaca: even better, less churn :)
[12:46] <diddledan> has anyone tried calling a classic snap command from a process that is itself also a classic snap? does it work?
[12:47] <mvo> Chipaca: I think it needs an ack from jamie, I addressed a bunch of things but I'm not sure if its all to his satisfaction
[12:47] <diddledan> as in crossing the boundary between two classic snaps
[12:47] <Chipaca> mvo: there's even a quora article about dotfiles
[12:47] <Chipaca> mvo: I'm not sure if that's an argument for or against, but it's there
[12:48] <mborzecki> re
[12:50] <pedronis> mvo: are you thinking of cutting 2.36 ?
[12:52] <mvo> pedronis: I was thinking after the meeting - anything pending on your side that should be in that is not milestoned?
[12:53] <pedronis> mvo: yes, 4 PRs,  they should get to reviewable today or early tomorrow
[12:58] <mvo> pedronis: ok
[12:59] <mvo> pedronis: is it about the brand store work?
[12:59] <pedronis> mvo: yes
[12:59]  * mvo nods
[13:00]  * zyga tries to join the standup ...
[13:00] <popey> This is a fun error message...
[13:01] <niemeyer> I'll be a couple of minutes late
[13:01] <popey> https://www.irccloud.com/pastebin/0ofGh1tb/
[13:01] <popey> (kodi isn't even installed)
[13:01] <popey> Maybe it should say "snap "kodi" isn't installed" or something?
[13:03] <popey> (you can easily reproduce this with "snap connect foo:bar"
[13:03] <popey> )
[13:03] <zyga> popey: I'll fix that, thanks!
[13:03] <popey> np
[13:04] <ogra> geez, just install kodi
[13:04] <popey> kodi 18.0b2-Leia installed
[13:04] <popey> ok!
[13:04] <ogra> :D
[13:04] <ogra> we have a leia snap ?!?!?
[13:04] <popey> *I* do
[13:04] <ogra> for armhf by chance ?
[13:04] <diddledan> ok. the problem I'm encountering is specific to vscode then - it cannot launch the dotnet sdk cli which is in a separate classic snap - I've tried to do a reduced testcase but couldn't get that to fail, so something is screwey with the vscode snap
[13:05] <popey> ogra: not yet
[13:05] <diddledan> silly thing, though, is that using the inbuilt command line in vscode can launch the sdk cli
[13:05] <ogra> popey, well, once you do ... i'd be a happy tester
[13:05] <popey> bet you will
[13:05] <ogra> UbuntuCoreElec !!!
[13:06] <mup> PR snapcraft#2295 closed: tests: use SNAPCRAFT_PACKAGE_TYPE everywhere <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2295>
[13:06] <mup> PR snapcraft#2296 closed: part grammar processor: lazily capture attributes from plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2296>
[13:06] <mup> PR snapcraft#2297 closed: [legacy] part grammar processor: lazily capture attributes from plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2297>
[13:06] <mup> PR snapd#5862 closed: cmd: fix C formatting <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5862>
[13:21] <mup> PR snapcraft#2301 opened: tests: move most tests to spread and reorder travis.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2301>
[13:50] <Chipaca> degville: I did the change in 'snap whoami' fwiw (as well as the new Other (miscelanea) category)
[13:51] <degville> Chipaca: thanks! Sad I can no longer use my printer though.
[13:51] <Chipaca> degville: just pipe it to "lp" and it'll work
[13:51] <degville> ahaha!
[13:52] <Chipaca> degville: I don't know if the unicode characters will work though, it might set it to banner mode and print you out of a home
[13:59] <mvo> sil2100: who in foundations might know about translations ? I wonder who can approvehttps://translations.launchpad.net/snapd/trunk/+imports
[13:59] <mvo> sil2100: https://translations.launchpad.net/snapd/trunk/+imports
[13:59] <mvo> sil2100: someone with special powers needs to approve this one and I'm trying to find who that someone is :)
[14:01] <Chipaca> degville: AIUI Miscellanea was a countable miscellany. Ignoring the typo, did I get that wrong?
[14:01] <Chipaca> that is, they're synonyms, but miscellanea are countable and miscellany might not be
[14:02] <Chipaca> but, maybe it's archaic
[14:02] <Chipaca> :) you tell me
[14:02] <diddledan> mvo: https://upload.wikimedia.org/wikipedia/en/thumb/e/eb/SupermanRoss.png/250px-SupermanRoss.png
[14:02] <mvo> diddledan: I'm looking for that dude!
[14:02] <diddledan> all the powers
[14:02] <mvo> diddledan: in the old days it was dpm or danilo but I don't know about the present days :/
[14:03] <sil2100> mvo: this is the part of translations that I have no power over! I think Gunnar is responsible for this now
[14:03] <mvo> I will just pester random people until I find out more
[14:03] <sil2100> mvo: let me poke him through e-mail, he'll at least know
[14:03] <mvo> sil2100: nevermind
[14:04] <mvo> sil2100: I got some help now from colin and hopefully thats enough I will keep in mind that gunnar is the guy
[14:04] <mvo> sil2100: thanks!
[14:08] <mup> PR snapd#5876 opened: selftest: rename selftest.Run() to sanity.Check() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5876>
[14:12] <Chipaca> mvo: do we do tarballs of releases on github?
[14:13] <Chipaca> waaait, is this something github does automagically
[14:13]  * Chipaca prods it
[14:14] <zyga> Chipaca: yes we do
[14:14] <zyga> we produce three dedicated tarballs
[14:14] <Chipaca> yep, https://github.com/snapcore/snapd/releases
[14:14] <Chipaca> looking at that now
[14:16] <Chipaca> zyga: i can haz darwin in lab?
[14:16] <zyga> mmm
[14:16] <zyga> sure
[14:16] <Chipaca> zyga: taw
[14:16] <Chipaca> zyga: I can't even get to the lab, right now
[14:16] <Chipaca> not sure why
[14:17] <zyga> Chipaca: I turned it off (fan noise)
[14:17] <zyga> Chipaca: note, it's updated to Mojave and home-brew is out
[14:17] <zyga> so you need to re-do it
[14:17] <Chipaca> ok
[14:17] <zyga> when I looked at brew it suggested that I don't use sudo though
[14:17] <zyga> so maybe something new?
[14:17] <Chipaca> zyga: not use sudo, and instead what?
[14:17] <zyga> brew
[14:17] <zyga> I mean
[14:17] <zyga> whatever you need :)
[14:17] <mvo> Chipaca: why do you ask?
[14:18] <Chipaca> mvo: because our brew formula currently is only a head formula, and I'd like to make it do releases instead
[14:18] <Chipaca> so you can 'brew install snap' (as opposed to the current 'brew install --HEAD snap')
[14:18] <Chipaca> s/as opposed/in addition/
[14:19] <mvo> Chipaca: aha, nice
[14:20] <diddledan> is that a brew formula for linuxbrew or homebrew (macOS) or both? if it's targeting homebrew in some way, how's that work??!
[14:21] <Chipaca> diddledan: both
[14:22] <Chipaca> although the linuxbrew one is incidental, the objective is homebrew
[14:22] <Chipaca> diddledan: snap, the command, works on darwin
[14:22] <Chipaca> diddledan: snapd does not
[14:22] <sergiusens> diddledan: the same way it works for snapcraft on mac
[14:22] <sergiusens> oh, ic, the how does that work is related to snapd
[14:22] <diddledan> I figured snap would be useless without a snapd to control
[14:23] <sergiusens> diddledan: we want the snap command avail since it is what holds the license field validation logic
[14:28] <Chipaca> diddledan: the only thing stopping snapd from working via remote control is nasty humans
[14:28] <Chipaca> (i.e., auth)
[14:28] <diddledan> bah. filthy scum
[14:29] <Chipaca> ikr
[14:29] <Chipaca> zyga: your network is slow today :-(
[14:30] <zyga> oh?
[14:30] <zyga> not me
[14:30] <zyga> maybe $family or weather
[14:30] <Chipaca> zyga: taking *minutes* to download the go 1.11 bottle
[14:30] <Chipaca> :)
[14:30] <diddledan> try changing the tyres
[14:32] <zyga> bad mirror?
[14:32] <zyga> where are you fetching from?
[14:33] <zyga> I see almost no traffic
[14:34] <ogra> probably there is a detour sign outside your viallge
[14:35] <ogra> *village
[14:42] <Chipaca> dang, 2.35.2 did not build on darwin yet.
[14:43] <Chipaca> mvo: how is the .vendor. tarball built? i'd like to test it with master
[14:44] <Chipaca> that is, i need a tarball for a stable brew build, but the latest snapd_2.35.2.vendor.tar.xz doesn't cut it :-)
[14:45] <mup> PR snapcraft#2290 closed: pluginhandler: update build should overwrite organize <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2290>
[14:50] <Chipaca> mvo: also: can we make those tarballs come pre-generated? ie without needing mkversion etc?
[14:54] <kyrofa> sergiusens, yeah, pip is doing something weird here
[14:55] <kyrofa> pip install pymacaroons==0.9.2 actually does the right thing
[14:55] <kyrofa> But using the requirements.txt seems to be getting 0.9.0
[14:55] <kyrofa> It's interesting because pip freeze shows 0.9.2, then I actually look at it and its __init__ shows 0.9.0
[14:57] <pedronis> fun, if I add an empty TearDownTest to one of the suites in snapstate some unrelated tests fail :/
[15:06] <zyga> Chipaca: look at release-tools
[15:06] <zyga> Chipaca: there's a script for it
[15:08]  * Chipaca looks around for a Neal
[15:09] <mup> PR snapcraft#2280 closed: Use the better snapcraft.io/account URL <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2280>
[15:25] <zyga> Pharaoh_Atem: ^
[15:26]  * Pharaoh_Atem pops in
[15:26] <Pharaoh_Atem> what?
[15:26] <zyga> Chipaca: ^
[15:26]  * zyga runs
[15:26] <Chipaca> heh
[15:26] <Chipaca> Pharaoh_Atem: hola
[15:26] <Pharaoh_Atem> aloha!
[15:26] <Pharaoh_Atem> I'm confused, what's going on here?
[15:26] <Chipaca> Pharaoh_Atem: is the tarball (as in https://github.com/snapcore/snapd/releases) used as part of the rpm build at any point?
[15:27] <Pharaoh_Atem> yes
[15:27] <Chipaca> Pharaoh_Atem: do you need to hoop through jumps to get the version?
[15:27] <Pharaoh_Atem> nope, I set the version in the spec, and propagate it down to everything
[15:27] <Chipaca> Pharaoh_Atem: I mean, the mkversion.sh script
[15:27] <Chipaca> Pharaoh_Atem: you don't use it /  do things differently?
[15:27] <Pharaoh_Atem> I use it
[15:28] <Pharaoh_Atem> ./mkversion.sh %version-%release
[15:28] <Pharaoh_Atem> that's in the spec file for every snapd package derived from my packaging
[15:28] <Chipaca> ahhh
[15:28] <Chipaca> fair enough
[15:28] <Chipaca> Pharaoh_Atem: ok
[15:28] <Chipaca> Pharaoh_Atem: thanks
[15:28] <Pharaoh_Atem> no problem
[15:28] <Chipaca> I might just do that on darwin as well, then
[15:28] <Chipaca> if I can figure out the equivalent in brewish
[15:28] <Pharaoh_Atem> https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd.spec#_403-404
[15:29] <Pharaoh_Atem> brew has a version variable
[15:29] <Chipaca> I was going to do a bunch of work to make mkversion itself figure it out but this is easier
[15:29] <Chipaca> Pharaoh_Atem: and a revision! :-)
[15:29] <Pharaoh_Atem> hold on, I did this recently when I packaged rpm for homebrew
[15:29] <Chipaca> ooohh
[15:30] <Chipaca> Pharaoh_Atem: https://formulae.brew.sh/formula/rpm ?
[15:30] <Pharaoh_Atem> yeah
[15:30] <Pharaoh_Atem> I rewrote that formula
[15:30] <Pharaoh_Atem> I think #{VERSION} is defined?
[15:30] <Chipaca> ah
[15:30] <Pharaoh_Atem> I know it does some introspecting from the tarball name
[15:31] <Chipaca> lowercase, at  least, works
[15:31] <Chipaca> ie #{version}
[15:31] <Pharaoh_Atem> cool
[15:31] <Chipaca> yep
[15:31] <Pharaoh_Atem> yeah, ruby is weird
[15:31] <Chipaca> thanks!
[15:31] <Pharaoh_Atem> no problem ;)
[15:32] <ogra> niemeyer, mvo, zyga https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603 any thoughts here would be appreciated
[15:32] <Pharaoh_Atem> most things tend to behave like rpm spec files :D
[15:32] <Pharaoh_Atem> ogra: shit
[15:32] <Pharaoh_Atem> that explains the bugs I'm getting in Fedora
[15:32] <Pharaoh_Atem> our nsswitch.conf is getting blown away and breaking things
[15:32] <zyga> ogra: hmm
[15:33] <zyga> ogra: yeah, tough choice
[15:33] <zyga> maybe it should be writable?
[15:33] <zyga> and snap might manage that somehow
[15:33] <Pharaoh_Atem> https://bugzilla.redhat.com/show_bug.cgi?id=1596753
[15:33] <Pharaoh_Atem> zyga, ogra ^
[15:34] <zyga> Pharaoh_Atem: we should not be mounting anything on the host
[15:34] <zyga> unless the code is broken
[15:34] <zyga> but then all hell would break lose
[15:34] <Pharaoh_Atem> maybe it is, just not on Ubuntu :(
[15:34] <zyga> we test it on fedora dozens of times a day
[15:34] <Pharaoh_Atem> this is not the only file that we're having problems with caused by snapd
[15:35] <ogra> Pharaoh_Atem, heh
[15:35] <zyga> Pharaoh_Atem: can you see weird mounts on your snap running system?
[15:35] <zyga> if not then we are not doing that (or you are not using any snaps)
[15:35] <Pharaoh_Atem> zyga: I'll check in a bit, when I can get to my snap dev environment
[15:35] <zyga> ok
[15:35] <Pharaoh_Atem> I've removed snapd and snaps from my main workstation because it kept breaking things
[15:35] <zyga>  /o\
[15:36] <Pharaoh_Atem> I had no choice, I can't have a broken workstation at work
[15:36] <Pharaoh_Atem> I had snapd on here for a while to play around with base snaps and building fedora based layered snaps
[15:37] <ogra> Pharaoh_Atem, i'D appreciate a comment on the thread indeed :)
[15:42] <Pharaoh_Atem> ogra: commented: https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603/2
[15:43] <Pharaoh_Atem> zyga, ogra, the really challenging problem is that I have no idea what is causing this
[15:44] <Pharaoh_Atem> the best I can guess is that something is doing a read+writeback and because we can't operate in strict confinement, it actually hits the filesystem and breaks things
[15:46] <ogra> Pharaoh_Atem, thanks !
[16:02] <mvo> Chipaca: I will merge 5865 now but if my question inline is valid please do a followup (if not even better :)
[16:03] <Chipaca> what was 5865?
[16:03]  * Chipaca looks
[16:03] <mvo> Chipaca: the translation comments
[16:03] <Chipaca> mvo: aww
[16:03] <Chipaca> mvo: 5856 was the one i wanted in :-)
[16:03] <mup> PR snapd#5865 closed: cmd/snap: add a bunch of TRANSLATORS notes (and a little more i18n) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5865>
[16:03] <Chipaca> so close
[16:03] <Chipaca> mvo: :-) tahnks
[16:04] <mvo> Chipaca: heh, the --help one has a +1 from me already
[16:04] <Chipaca> mvo: grah, you're right about them not being the same
[16:04] <Chipaca> drat it
[16:04] <mvo> Chipaca: but if degville gives a +1 too …
[16:04] <mvo> Chipaca: no worries
[16:04] <mvo> Chipaca: just do a followup and all is good
[16:04] <Chipaca> okk
[16:05] <mvo> Chipaca: ta!
[16:05] <mvo> Chipaca: uh and 5856 has a conflict now :/
[16:05] <Chipaca> mvo: tests for 5856 haven't started yet, otherwise it's gtg imo
[16:05] <Chipaca> of _course_ it does
[16:05] <Chipaca> :-)
[16:05] <mvo> Chipaca: the help one only had a single +1 so far, no? /me double checks
[16:06] <mvo> Chipaca: aha, silly me, two +1, one from degville  earlier. so yeah, ready once tests are happy :)
[16:06] <degville> :)
[16:06] <Chipaca> and conflcits
[16:07] <Chipaca> mvo: how easy is it for you to build a fake tarball (like the ones in https://github.com/snapcore/snapd/releases)?
[16:07] <mup> PR snapd#5873 closed: tests/main/parallel-install-store: run installed snap <Parallel installs> <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5873>
[16:07] <Chipaca> mvo: I tried doing it starting from dpkg-buildpackage of the git checkout and got into trouble :-)
[16:08] <mvo> Chipaca: the release ones? trivial: "gbp buildpackage -S" and ./release-tools/repack-tarball ../build-area/*.tar.xz
[16:08] <mvo> Chipaca: do you want one?
[16:08] <Chipaca> mvo: of ~master, I could use one to test brew stable build, yes
[16:08] <Chipaca> mvo: I can point it at any url (and then switch it back to github when that's done)
[16:09] <Chipaca> mvo: OTOH, I can also wait for the actual tarball
[16:09] <Chipaca> it's not going to land before that
[16:10] <mvo> Chipaca: building one for you now
[16:12] <mvo> Chipaca: try http://people.canonical.com/~mvo/.chipaca/
[16:12] <Chipaca> mvo: <3
[16:14]  * zyga is starving
[16:15] <Chipaca> woooooo, that worked :-D
[16:15] <Chipaca> mvo: thanks again
[16:39] <mup> PR snapcraft#2040 closed: lifecycle: always prime dependencies <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2040>
[16:50] <mvo> Chipaca: \o/ great to hear that it works :)
[16:56] <rbasak> kyrofa: on the subject of testing edge, I'm looking to land a git-ubuntu regression fix and our CI is failing because our CI is using snapcraft from edge. I'm reluctant to switch it to use beta because then I wouldn't be testing edge, which is useful :)
[16:56] <rbasak> Not sure what I want exactly. I thought I'd mention the situation.
[16:57] <kyrofa> rbasak, yeah, tough situation. I think we've figured out the fix, if it helps
[17:03] <mup> PR snapd#5856 closed: cmd/snap: tame the help zoo <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5856>
[17:06] <Chipaca> mvo: weee
[17:06] <mvo> Chipaca: !!!
[17:06]  * mvo hugs Chipaca 
[17:06] <Chipaca> and go-flags master is working again :-D
[17:07] <mvo> zyga: 5870 looks like you almost gave a +1
[17:07] <Chipaca> some of our tests broke because now it's better :-)
[17:07] <mvo> Chipaca: haha
[17:07] <Chipaca> one of the fixes was that before it left space for all options, even if some of them were hidden
[17:07] <mvo> Chipaca: the update will be a small burden on debian as they will also need to update the package
[17:07] <Chipaca> you can see that in 'snap help prefer' for ex
[17:08] <mvo> Chipaca: cool, thanks for fixing this!
[17:08] <Chipaca> this assumes all the tests are ok, now, of course :-)
[17:08] <Chipaca> grmbl
[17:10] <mup> PR snapd#5583 closed: cmd/snapd,daemon,overlord: without snaps, stop and wait for socket <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5583>
[17:18] <Chipaca> zyga: i'm done with the lab, thanks
[17:22] <mup> PR snapcraft#2302 opened: requirements.txt: stop using pymacaroons-pynacl <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2302>
[17:22] <mup> PR snapcraft#2303 opened: requirements.txt: stop using pymacaroons-pynacl <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2303>
[17:51] <zyga> mvo: looking at 5870
[17:52] <Chipaca> so, we were using a bug in go-flags :-(
[17:52] <Chipaca> sad trombone
[17:52] <zyga> Chipaca: oh?
[17:52] <zyga> Chipaca: cool, what did you find?
[17:52] <Chipaca> we use PassAfterNonOption
[17:52] <Chipaca> but only really use it in 'snap run'
[17:52] <zyga> Chipaca: is it the time when we roll our own?
[17:53] <Chipaca> nah
[17:53] <zyga> or do we have a way to fix it
[17:53] <Chipaca> bah, I think this is fixable
[17:53] <Chipaca> in a few ways
[17:53] <Chipaca> but the basic thing is: PassAfterNonOption means "be strict POSIXly"
[17:53] <Chipaca> there was a bug in go-flags where it didn't actually do its job
[17:53] <Chipaca> so you could have "snap install foo --classic" mean the same as "snap install --classic foo"
[17:54] <Chipaca> which is explicitly not what PassAfterNonOption should do: with PassAfterNonOption, the first --classic is no longer an option
[17:54] <Chipaca> it's an argument, and is passed to the command's Execute as such
[17:54] <Chipaca> but of course we want "snap run http --help" to have that help reach http
[17:54] <Chipaca> so
[17:55] <Chipaca> easy fix: require everybody using snap run directly to do "snap run -- http --help
[17:55] <Chipaca> "
[17:56] <Chipaca> hacky fix: peek at os.Args, and rewrite it to add a -- for 'snap run'
[17:56] <Chipaca> the first one is trivial, only really affects tests on our end
[17:56] <Chipaca> snapped apps continue to work, because we'd add the -- ourselves
[17:56] <Chipaca> only people we'd be breaking are those that use 'snap run' with arguments
[17:56] <Chipaca> but … that's probably some people
[17:57] <Chipaca> so, leaning towards the hacky don't-break-people one
[18:07] <sergiusens> Chipaca: the joys of wanting to mix strict arg parsing with friendly arg parsing :-)
[18:23] <zyga> Chipaca: still hear?
[18:23] <zyga> here
[18:23] <Chipaca> yes
[18:23] <zyga> I have a branch with the Mk** helpers moved
[18:23] <zyga> it's a bit big
[18:24] <zyga> wanna see?
[18:34] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/5877 I opened for RFC
[18:34] <mup> PR #5877: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
[18:34] <mup> PR snapd#5877 opened: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
[18:34] <Chipaca> zyga: hmmm
[18:34] <Chipaca> zyga: are you all hyped up, or are you wrapping up your day?
[18:34] <zyga> more of a task switching
[18:34] <zyga> this was a distraction today
[18:34] <zyga> I'm working on something more involved
[18:35] <zyga> also upset about MBP - still not fixed
[18:35] <zyga> and apparently service people broke the screen /o\
[18:35] <zyga> at this rate I'll get crumbs next week
[18:35] <zyga> iCrumbs
[18:35] <zyga> it was such a nice machine
[18:36] <Chipaca> zyga: official service?
[18:36] <zyga> not real apple but authorised services
[18:36] <zyga> I'm sure they will fix it
[18:36] <zyga> (or just give me a brand new unit)
[18:36] <zyga> but ... what the hell happened
[18:37] <zyga> maybe I should just not think more about it
[18:37] <zyga> and just wait patiently
[18:37] <zyga> and not get more gray
[18:37] <zyga> next time I'll open it in the store
[18:37] <zyga> and just ask for a different unit
[18:38] <zyga> and let them turn gr{a,e}y
[18:38] <zyga> which is it?
[18:38] <zyga> anyway
[18:39] <Chipaca> zyga: depends on where you're standing when you say it
[18:40] <Chipaca> anyway, it's 19:40, I need to make dinner
[18:40] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/5877 landing would make me happy
[18:40] <mup> PR #5877: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
[18:40] <zyga> and I can then go and rest
[18:40] <zyga> you're right, EOD time
[18:40] <Chipaca> and instead I'm knee deep in making our thing work with the new go-flags
[18:40] <Chipaca> zyga: I'll look at that last one after dinner, k?
[18:40] <zyga> er
[18:40] <zyga> no no wrong branch
[18:40] <zyga> but sure
[18:40] <Chipaca> well, leave the one you want me to look at
[18:41] <Chipaca> if it's too big, i'll punt
[18:41] <zyga> meant https://github.com/snapcore/snapd/pull/5869
[18:41] <mup> PR #5869: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
[18:41] <Chipaca> otherwise i'll sleep at 3am again
[18:41] <zyga> :-)
[18:41] <Chipaca> ttfn
[18:41] <zyga> ttyl
[19:07] <JohK> hi
[19:07] <JohK> how do I get snap apps to work when my home is symlinked to a different drive?
[19:07] <gQuigs> is there something obvious I'm doing wrong here: https://pastebin.ubuntu.com/p/jgMBPYSYBz/   following workaround from forum - https://forum.snapcraft.io/t/importerror-no-module-named-six/1002/3
[19:12] <JohK> I get similar errors to what users report when their home is on a nfs mount
[19:12] <JohK> i.e. for pycharm or spotify
[19:15] <ogra> JohK, stop using a symlink and use a bind mount instead
[19:15] <zyga> JohK: hey, as ogra said you must use a bind mount instead
[19:16] <zyga> or just mount your home directory to /home/$LOGNAME
[19:18] <JohK> I use this setup for 15 years...
[19:18] <JohK> ogra: Really? I use this setup for 15 years...
[19:20] <JohK> ogra: why is not having a symlink a requirement for snap to work?
[19:21] <JohK> well I guess Im not using snapd then, thx
[19:57] <zyga> because symlinks and real directories are not the same, have fun with your setup for the next 15 years
[20:00] <mup> PR snapd#5878 opened: overlord/ifacestate: make sure to pass in the Model assertion when enforcing policies <Created by pedronis> <https://github.com/snapcore/snapd/pull/5878>
[20:05] <Chipaca> zyga: chill
[20:21] <Chipaca> zyga: you there?
[20:23] <zyga> yes
[20:24] <Chipaca> zyga: comment on your pr
[20:24] <Chipaca> zyga: and a suggestion coming up in diff form
[20:24] <zyga> on 5877?
[20:24] <Chipaca> zyga: https://pastebin.ubuntu.com/p/V2NbGY6GPp/
[20:24] <Chipaca> 5869
[20:25] <zyga> ah
[20:25] <zyga> did you see what the error looks like if you try that?
[20:25] <Chipaca> zyga: yes
[20:25] <zyga> it's less sublime, talking about unmarshaling and such
[20:25] <zyga> AFAIR, it was less pretty than now
[20:25] <Chipaca> 1 sec
[20:26] <Chipaca> $ snap pack . ..
[20:26] <Chipaca> error: cannot pack ".": cannot parse snap.yaml: cannot use "layouts" (plural), please use singular "layout" instead
[20:26] <zyga> we _can_ parse snap.yaml
[20:26] <zyga> we just don't like what we found
[20:26] <zyga> and without the extra change?
[20:26] <Chipaca> zyga: without which extra change?
[20:26] <zyga> I mean, without your suggestion
[20:27] <Chipaca> zyga: it's in the comment: error: cannot pack ".": cannot use "layouts" (plural), please use singular "layout" instead
[20:27] <zyga> hmm
[20:27] <Chipaca> quite
[20:27] <Chipaca> and this is with pack, where you know at least that you're building this
[20:28] <zyga> I was thinking about making a error type and returning it instead
[20:28] <zyga> and tweaking the error reception in the client
[20:28] <Chipaca> imagine getting «cannot install "foo": cannot use "layouts"»
[20:28] <zyga> but I think it's too late for that today, I was about to hit the bed
[20:28] <zyga> but I'll try both tomorrow
[20:28] <Chipaca> zyga: ?
[20:28] <zyga> and see if the error looks nice in all cases (I was thinking of "snap try" mostly)
[20:28] <Chipaca> zyga: there is no client/server for 'snap pack'
[20:29] <zyga> you can make a snap with older version and install it
[20:29] <zyga> that's what I meant, sorry for not being clear
[20:30] <zyga> I'll continue tomorrow :)
[20:30] <Chipaca> ok
[20:30] <Chipaca> zyga: g'night
[20:30] <Chipaca> i'm off as well
[20:54] <mup> PR snapd#5879 opened: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <https://github.com/snapcore/snapd/pull/5879>
[21:27] <sergiusens> stgraber: hey there, everytime my lxd snap updates (just did recently) my container(s) die(s); from what I recollect this should not be the case so wondering if there is a way to monitor what is going on
[21:28] <stgraber> sergiusens: what channel?
[21:28] <stgraber> sergiusens: journalctl -u snap.lxd.daemon -u 500
[21:28] <sergiusens> stgraber: latest/stable is where I saw it just now
[21:31] <sergiusens> stgraber: exit with 137
[21:31] <sergiusens> stgraber: for context https://pastebin.ubuntu.com/p/8qc6VHhNsW/
[21:33] <stgraber> sergiusens: "dmesg" output?
[21:37] <sergiusens> stgraber: maybe this https://pastebin.ubuntu.com/p/wH2WCMFjsD/ ?
[21:37] <sergiusens> stgraber: I can hand over the full output if you want too
[21:38] <stgraber> sergiusens: nah, unrelated, full output please
[21:38] <stgraber> sergiusens: also, the journalctl didn't show you anything more than what you pasted? that was way shorted than 500 lines
[21:39] <sergiusens> there's more in the journal, I'll send over
[21:40] <sergiusens> stgraber: full journal https://pastebin.canonical.com/p/39DRDZBXtm/
[21:41] <sergiusens> to any other person, sorry for the private link, but I haven't checked if this leaks any sensitive data 🙂
[21:42] <stgraber> sergiusens: full dmesg?
[21:42] <stgraber> sergiusens: ah and "snap version" too please?
[21:43] <sergiusens> stgraber: https://pastebin.canonical.com/p/CMxrySp2cB/
[21:44] <sergiusens> stgraber: http://paste.ubuntu.com/p/Q3Y5mjjj54/
[21:44] <stgraber> sergiusens: "snap changes" output?
[21:46] <sergiusens> stgraber: I think you want this specific change http://paste.ubuntu.com/p/mRqcZrcPyv/
[21:46] <sergiusens> an autorefresh change that is
[21:46] <sergiusens> hmm, let me see if I can get those out in english client side
[21:47] <sergiusens> meh, no
[21:49] <sergiusens> """Detener los servicios del snap "lxd"""" translates to """Stopping services from the snap "lxd""""
[21:50] <stgraber> oh, that's actually very interesting
[21:50] <stgraber> well, maybe not
[21:51] <stgraber> can you show me cat /proc/$(pgrep daemon.start)/environ | tr '\0' '\n'?
[21:51] <sergiusens> right, it doesn't say exactly if it will ignore the stop or not after going in
[21:51] <stgraber> well, no, it not being in english is the interesting part :)
[21:51] <stgraber> because we parse that in our stop code
[21:52] <stgraber> but the environment of the stop code should be such that it's in english
[21:53] <sergiusens> stgraber: my locale at installation time is spanish https://pastebin.canonical.com/p/zsw3RDXCtP/
[21:53] <stgraber> crap, I didn't expect systemd to respect it :)
[21:53] <sergiusens> this is why we don't do translations for these things :-P
[21:53] <stgraber> sergiusens: LANG=C.UTF-8 snap changes
[21:54] <sergiusens> stgraber: tried that already :-)
[21:54] <sergiusens> stgraber: so it means the changes are generated by snapd, they are also ephemeral, so I suppose that restarting snapd will kill the changes
[21:55] <stgraber> snapd stores them as a string in the user's language?
[21:55] <sergiusens> I am not sure about that, I hope not; but I do suppose that snapd returns output to the snap command already in the set lang
[21:56] <stgraber> oh, so the daemon is returning translated strings then, great...
[21:57] <sergiusens> yes, it seems so
[21:57] <sergiusens> it wouldn't be that bad if the client could tell it the language it wanted those strings in
[21:58] <sergiusens> but alas, that does not seem to be the case
[21:59] <stgraber> do you know if there's some new way for us to figure out if we're dealing with a unit restart due to refresh vs unit restart due to host shutdown?
[22:00] <sergiusens> stgraber: given the timestamps, this is certainly a refresh; change 19 which I pasted is from auto-refresh
[22:01] <sergiusens> I was actually doing something else when I saw the container go away
[22:01] <stgraber> sergiusens: yeah, I'm sure that's the problem, I'm just looking for ways to fix it which don't involve me hardcoding strings for every language we may get back from snapd :)
[22:04] <stgraber> sergiusens: curl --unix-socket /run/snapd.socket snapd/v2/snaps/lxd -s | jq .result.status
[22:04] <stgraber> sergiusens: is this in english?
[22:08] <sergiusens> fwiw https://forum.snapcraft.io/t/snap-snapd-language/7607
[22:09] <sergiusens> stgraber: yes, that is in English
[22:09] <sergiusens> returned "active"
[22:09] <stgraber> sergiusens: unfortunately that won't quite be enough as it won't tell me if the snap is being removed, poking at the /changes API instead now
[22:10] <sergiusens> ok, I will have to commute back home right now, but I can get back to this in a bit, just leave me anything required to check
[22:13] <stgraber> sergiusens: curl --unix-socket /run/snapd.socket snapd/v2/changes?select=all\&for=lxd -s | jq -r ".result | .[] | .kind"
[22:14] <stgraber> I think that will be our way out of this problem, much more reliable than parsing snap changes
[22:57] <stgraber> sergiusens: wrote a new query tool that pokes the API directly, building a new snap with that, will test tomorrow (in Europe now, so a bit late here)