[01:53] <jdstrand> zyga: I commented on 5897 (extensively) earlier today (including the trigger)
[01:53] <jdstrand> zyga: ack on 5901
[01:56] <mup> PR snapcraft#2313 closed: meta: link the icon correctly across filesystems <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2313>
[01:59] <mup> PR snapcraft#2310 closed: nodejs plugin: add support for ppc64el and s390x <Created by anthonyfok> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2310>
[02:02] <mup> PR snapcraft#2314 opened: nodejs plugin: add support for ppc64el and s390x (#2310) (#2310) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2314>
[02:50] <mup> PR snapcraft#2304 closed: project loader: remove remote parts support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2304>
[05:14] <mborzecki> morning
[06:29] <zyga> good morning
[06:30] <zyga> jdstrand: thank you on both, looking at feedback
[06:31] <zyga> hey mborzecki
[06:31] <zyga> tests look reddish today
[06:31] <mborzecki> zyga: hey
[06:34] <zyga> + quiet zypper --gpg-auto-import-keys refresh
[06:34] <zyga> <kill-timeout reached>
[06:34] <zyga> hmmm :/
[06:34] <zyga> and then
[06:34] <zyga> more openSUSE repo woes https://www.irccloud.com/pastebin/1Xu1svZW/
[06:35] <mborzecki> hmm --non-interactive
[06:35] <mborzecki> we don't pass it do we?
[06:36] <zyga> Download (curl) error for 'http://download.opensuse.org/update/leap/42.3/non-oss/repodata/b95bdb6d60aafb004e5486f977be7f0271423a08250b846de8fbd842d2c0a87a-primary.xml.gz':
[06:36] <zyga> Error code: HTTP response: 500
[06:36] <zyga> Error message: The requested URL returned error: 500 Internal Server Error
[06:36] <zyga> it's the server side
[06:36] <zyga> well
[06:37] <mborzecki> fwiw that url is timing out locally too
[06:39] <zyga> ok, if this persists during the day we need to disable opens use
[06:39] <zyga> oh, we disabled 18.04 AFAIR
[06:39] <zyga> we should keep track of those
[06:49] <zyga> ok, time to look at 18.10 live issues
[07:36] <Chipaca> good morning peeps
[07:38] <zyga> good morning Chipaca
[07:38] <zyga> IRC is splitty this morning
[07:38] <zyga> and openSUSE archive is not responding
[07:38] <zyga> but otherwise things are fine
[07:39] <zyga> my cosmic download will finish tomorrow at this rate :/
[07:39] <zyga> (it's raining, LTE speed is very low now)
[07:40] <Chipaca> boo to opensuse
[07:40] <Chipaca> makes me feel we should have a control panel thing for skipping tests
[07:40] <Chipaca> also a cache for spread
[07:40] <Chipaca> boo
[07:41] <zyga> that would be great
[07:41] <Chipaca> a cache for spread where things expire after ~5 days, where you look up with a git hash and get back a list of everything that passed
[07:41] <Chipaca> and then spread just skips those
[07:44] <Chipaca> what could go wrong™
[07:44] <zyga> schedule ;)
[07:48] <mborzecki> https://github.com/snapcore/snapd/pull/5904 could we land this?
[07:48] <mup> PR #5904: spread: put openSUSE to manual <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5904>
[07:49] <zyga> yes
[07:49] <zyga> Chipaca: ^
[07:53] <mborzecki> yay
[07:53] <mborzecki> Chipaca: thanks!
[07:53] <mborzecki> hm mup is somewhat quiet today
[07:53] <zyga> split
[07:53] <mup> PR snapd#5904 closed: spread: put openSUSE to manual <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5904>
[07:54] <mborzecki> maybe
[08:28] <degville> Chipaca: yep, that makes sense.
[08:28] <Chipaca> degville: (the biggest tell used to be that I called the big white thing in the kitchen the ice chest, but I taught myself out of that one)
[08:28] <degville> ahahaha!
[08:29] <mborzecki> zyga: hm so requiring network-online.target comes back to haunt us
[08:29] <zyga> but didn't we drop that
[08:29] <zyga> or is my memory backwards/
[08:29] <mborzecki> wasn't there a PR to dro that?
[08:29] <mborzecki> iirc someone from ce team opened it
[08:29] <zyga> right, I think there was one
[08:29] <zyga> but we don't change existing unit
[08:29] <zyga> so :/
[08:30] <mborzecki> https://github.com/snapcore/snapd/pull/5746 ?
[08:30] <mup> PR #5746: wrappers: remove Wants=network-online.target <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5746>
[08:30] <zyga> so either not released yet
[08:30] <zyga> or released but people did not update
[08:30] <Chipaca> this is more a "make all service files generated" coming back to haunt us, fwiw
[08:30] <Chipaca> or rather, the lack of doing that :)
[08:30] <zyga> yeys
[08:31] <zyga> or at least managed with Ensure-like manner like security code is
[08:31] <zyga> (imagine how terrible it would be if we had not done it that way)
[08:32] <mborzecki> so even if people refresh the core they won't see it fixed
[08:32] <zyga> correct
[08:33] <mborzecki> they'd have to do eg. snap disable/enable as a workaround
[08:33] <Chipaca> mborzecki: hope they're not ssh'ing in to do that
[08:33] <mborzecki> hahaha
[08:38] <mborzecki> something fishy, NetworkManager is not a snap in a desktop installation, is it?
[08:39] <zyga> https://status.opensuse.org/
[08:39] <zyga> mborzecki: no, no it should not be a snap (yet)
[08:40] <pedronis> no, I expected  lxd + network manager both as snaps, not to be super common, unless there is some device setup like that for reasons
[09:09] <mborzecki> pedronis: why would the store send an error for a snap what was send in current snaps but not asked for in a refresh/install action?
[09:10] <pedronis> mborzecki: it shouldn't afaik, I would hope the issue is something else
[09:11] <pedronis> mborzecki: we should be doing that all the time
[09:11] <pedronis> any snap refresh foo
[09:11] <pedronis> would do that
[09:11] <pedronis> or I'm not understanding what you wrote
[09:13] <mborzecki> pedronis: i get a segfault right here https://github.com/snapcore/snapd/blob/master/store/store.go#L2296 which is missing a check (alredy got a fix for it), but added some debugging around that
[09:13] <mborzecki> pedronis: and i'm getting store.go:2302: refresh error of snap "test-snapd-auto-aliases_foo", instance key 7Q1OfI5JLwQMvR4LXoToCw1srmPjnu7z:d3ZayHx_juNBYOCHyKqGCggvrQN-rSGgFeOYyIJOScw, but not asked for? error: duplicated-snap The Snap is present more than once in the request.
[09:14] <mborzecki> pedronis: that's when i tried to install some other snap
[09:14] <pedronis> mborzecki: well, as I said parallel installs are not supported
[09:14] <pedronis> by the store
[09:14] <pedronis> anyway that place is more like the store returned a result for a snap that was only in current
[09:14] <pedronis> and not in any action
[09:15] <mborzecki> pedronis: yes
[09:15] <mborzecki> pedronis: though i don't recall it doing that, otherwise i'd notice i can't install any snaps
[09:15] <mborzecki> (from the store obviously)
[09:16] <pedronis> it shouldn't in the normal case
[09:16] <pedronis> but in your situation it does
[09:20] <pedronis> I would need to see the json to say exactly if it store is being unreasonable
[09:22] <Chipaca> gasp
[09:22] <pedronis> yea, the store is a bit wrong here
[09:22] <Chipaca> bits of our tests still have snapname.developer in them
[09:22] <wgrant> pedronis: Howso?
[09:23] <pedronis> it's returning an action-like error for something that is only in context
[09:23] <wgrant> pedronis: Oh, is it in results rather than error-list?
[09:24] <pedronis> yes
[09:25] <wgrant> Right, can someone file a bug?
[09:25] <pedronis> will do
[09:25] <wgrant> Thanks
[09:28] <mborzecki> pedronis: https://paste.ubuntu.com/p/QGXfB9FPBt/ there you go
[09:35] <pedronis> mborzecki: yea, what I expected, thanks
[10:05] <mup> PR snapd#5905 opened: store: gracefully handle unexpected errors in 'action' response <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5905>
[10:05] <mborzecki> pedronis: Chipaca: ^^
[10:21] <mup> PR snapd#5906 opened: snap, client, daemon, store: use and expose "media" more <Created by chipaca> <https://github.com/snapcore/snapd/pull/5906>
[10:51] <mup> PR snapcraft#2315 opened: tests: use mocked plugins for list-plugins <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2315>
[10:57] <Chipaca> hoping for a second review on #5903
[10:57] <mup> PR #5903: overlord/snapshotstate: store epoch in snapshot, check on restore <Created by chipaca> <https://github.com/snapcore/snapd/pull/5903>
[10:57] <Chipaca> (I've got a followup already ready to go)
[11:12] <mup> PR snapcraft#2316 opened: storeapi: Use structured data for the conflicted current value <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2316>
[11:15] <mup> PR snapd#5902 closed: cmd/snap: tweak UX of snap refresh --list <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5902>
[11:22] <mborzecki> Chipaca: can you take a look at https://github.com/snapcore/snapd/pull/5898 ?
[11:22] <sparkiegeek> sergiusens: o/
[11:22] <mup> PR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5898>
[11:23] <Chipaca> mborzecki: probably yes
[11:23] <mborzecki> Chipaca: it's aliases :)
[11:23] <Chipaca> give me a sec to save state
[11:23] <mborzecki> Chipaca: sure, thank you!
[11:28] <pstolowski> niemeyer: pushed new changes to https://github.com/snapcore/snapd/pull/5759 and commented, let me know what you think
[11:28] <mup> PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759>
[11:31] <pstolowski|lunch> niemeyer: ah, and i think i missed part of your suggestion regarding including attribute names in the key to avoid collision; will address this
[11:35] <zyga> is cdimage.ubuntu.com slow for everyone or just me?
[11:36] <zyga> I'm getting 50KB/s roughly
[11:36] <Chipaca> I have no idea what veeam is, but I already don't like it
[11:36] <popey> zyga: getting 7MB/s here
[11:36] <zyga> sigh , thanks
[11:37] <zyga> I rebooted my router
[11:40] <Chipaca> zyga: you don't have an implementation of tempdir from snap-update-ns etc, right?
[11:40] <zyga> tempdir?
[11:41] <zyga> I don't think we use any apart from stdlbi
[11:41] <zyga> *stdlib
[11:42] <Chipaca> zyga: yeah me neither
[11:43] <zyga> what do you need?
[11:43] <Chipaca> zyga: vvv
[11:43]  * Chipaca prods mup
[11:44] <mup> PR snapd#5907 opened: overlord/snapshotstate: chown the tempdir <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5907>
[11:44] <Chipaca> zyga: ^^^
[11:45] <Chipaca> zyga: I'd love to have a mktempdir that uses O_TEMPDIR :)
[11:45] <zyga> Chipaca: note that the O_TMPFILE thing is only suitable for files, not for directories AFAIK
[11:45] <Chipaca> yeah that
[11:45] <Chipaca> oohhhhhh awwww
[11:45] <Chipaca> boo
[11:45] <zyga> right?
[11:45]  * Chipaca manpages
[11:45] <zyga> software sucks
[11:45] <Chipaca> nah, 's ok
[11:45] <Chipaca> software i can fix
[11:46] <zyga> fg
[11:46] <zyga> heh
[11:47] <zyga> I _just_ got this message from you: zyga: I'd love to have a mktempdir that uses O_TEMPDIR :)
[11:47] <zyga> ordering FTW
[11:47] <Chipaca> wut
[11:47] <Chipaca> your network is in distress
[11:47] <Chipaca> irc can't do out-of-order, so your client is loopy
[11:49] <zyga> are you sure?
[11:49] <zyga> I just noticed it appearing mid log
[11:51] <Chipaca> zyga: it's a tcp connection
[11:51] <Chipaca> a single one
[11:51] <zyga> hohoh
[11:51] <zyga> Chipaca: something cool to show you
[11:52] <Chipaca> oh dear
[11:52] <zyga> http://paste.ubuntu.com/p/Y2zpfGNkQg/
[11:52] <zyga> while my network sucks at pulling ISOs
[11:52] <zyga> I'm going back to past PRs
[11:52] <zyga> remember this one?
[11:53] <zyga> evil genius or evil madman?
[11:55] <mborzecki> anyone know of a simple snap that has services, is in the store and is not lxd?
[11:55] <zyga> xkcd-webserver?
[11:55] <mborzecki> oh, let me try that
[11:57] <mborzecki> edge is really broken now without https://github.com/snapcore/snapd/pull/5905 if there's more than instance of a given snap in the system
[11:57] <mup> PR #5905: store: gracefully handle unexpected errors in 'action' response <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5905>
[12:01] <Chipaca> mborzecki: what will happen if you run 'snap alias foo_bar.baz baz' with a core that doesn't understand instances?
[12:02] <mborzecki> Chipaca: you won't have foo_bar installed
[12:02] <Chipaca> s/core/snapd/ i meant
[12:02] <Chipaca> right, so there's no way to get a SnapSetup that uses a snap name instead of the instance name
[12:03] <Chipaca> that wasn't created when they were equivalent
[12:03] <Chipaca> bah
[12:03] <mborzecki> yes, _ was also invalid for snap names
[12:04] <Chipaca> mborzecki: what happens today, without this pr, if you have instances enabled and install foo and foo_bar and try that alias command?
[12:04] <noise][> mborzecki: bear in mind there is store work still being done to support parallel
[12:05] <Chipaca> mborzecki: and, what happens if you have a snapd running with this pr, run 'snap alias', but before it can run you restart snapd into one that knows about instances but not instances for aliases?
[12:05] <Chipaca> s/run 'snap alias'/run 'snap alias foo_bar.baz baz'/
[12:05] <zyga> Chipaca: I pushed the changes to https://github.com/snapcore/snapd/pull/5869 - please have a look
[12:05] <Chipaca> no
[12:05] <mup> PR #5869: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
[12:05] <mborzecki> Chipaca: you mean the aliases PR?
[12:06] <Chipaca> mborzecki: y
[12:06] <zyga> it's generic and gives pretty useful error messages
[12:07] <mborzecki> Chipaca: so the missing instancekey in snapsetup in aliases was benign, the code operated on snapsup.InstanceName() which gave the same results if you had RealName: "foo_bar" and {RealName: "foo", InstanceKey: "bar"}
[12:07] <mborzecki> i had a change somewhere which triggered panics if snapstate or snapup had name with _ but instancekey was unset
[12:08] <mborzecki> but this is probably only appropriate for tests, not the end users
[12:09] <Chipaca> agreed
[12:10] <Chipaca> mborzecki: ok. I couldn't spot a way for it to break beyond erroring, that is, I couldn't find a way to make it get you an alias on foo.baz when you asked for foo_bar.baz or viceversa
[12:10] <Chipaca> which is why I +1'ed
[12:10] <mborzecki> yup
[12:10] <Chipaca> but, thought I'd ask
[12:10] <Chipaca> as these things make my hair wobble
[12:11] <mborzecki> fwiw, the spread tests were written (somewhat deliberate) before the code change
[12:11] <mborzecki> and were passing :)
[12:12] <Chipaca> mborzecki: right, but you don't have a spread test for "stop snapd just before this change gets run, and switch it to this other one because life is pain"
[12:13] <zyga> FYI: I re-opened the PR that adds a spread test showing how layout migration may fail due to leftovers
[12:13] <zyga> https://github.com/snapcore/snapd/pull/5908
[12:13] <mup> PR #5908: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5908>
[12:14] <zyga> to make it easier to see what happens with the bug fix
[12:14] <mup> PR snapd#5908 opened: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5908>
[12:14] <Chipaca> mostly a note to self: we should try to make commands in a family point to the other ones
[12:14] <Chipaca> e.g. have 'snap aliases' mention alias, unalias, prefer
[12:14] <Chipaca> etc
[12:15] <zyga> note to chipaca, you should make notes to self mention other people so that they remind you of your notes to self ;-)
[12:15] <Chipaca> not necessarily all in all of them, but try to make it non-disconnected
[12:15] <zyga> but yeah
[12:15] <Chipaca> zyga: when they're serious, I make notes to niemeyer and then EOD
[12:15] <Chipaca> like 'snap refresh --dry-run' yesterday
[12:15] <zyga> LOL
[12:15] <zyga> it would be nice to have a common theme (e.g. how they are worded or introduced) for such hints
[12:16] <Chipaca> speaking of hints, I created a label for snapshot prs, because that's how i roll now
[12:20] <zyga> Chipaca: review on https://github.com/snapcore/snapd/pull/5906
[12:20] <mup> PR #5906: snap, client, daemon, store: use and expose "media" more <Created by chipaca> <https://github.com/snapcore/snapd/pull/5906>
[12:21] <Chipaca> zyga: I have a review in my review!
[12:21] <zyga> refresh
[12:21] <Chipaca> oh noes
[12:21]  * Chipaca refreshes again
[12:21]  * zyga stops now ;)
[12:21] <zyga> sorry, your icon triggered me ;)
[12:22] <Chipaca> it's not even on that PR, but ok :)
[12:23] <mup> PR snapd#5909 opened: allow network_control to also use /sbin/iw <Created by ogra1> <https://github.com/snapcore/snapd/pull/5909>
[12:26] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/5903#pullrequestreview-161136203
[12:26] <mup> PR #5903: overlord/snapshotstate: store epoch in snapshot, check on restore <📸󠁟̻> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5903>
[12:28] <mup> PR snapd#5903 closed: overlord/snapshotstate: store epoch in snapshot, check on restore <📸󠁟̻> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5903>
[12:28] <mup> PR snapd#5910 opened: snapshotstate: restore to current revision <📸󠁟̻> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5910>
[12:31] <Chipaca> laptop just powered off
[12:31]  * Chipaca worries
[12:32] <zyga> Uh
[12:32] <Chipaca> nothing in the logs that i can see
[12:32]  * zyga -> walk
[12:32] <Chipaca> anyway, one snapshots PR in, so pushed another
[12:32] <Chipaca> :-)
[12:37] <Chipaca> zyga: once snapshots is landed, I'll see what happens if you try to snapshot a broken snap
[12:37] <Chipaca> zyga: or restore into it
[12:37] <Chipaca> zyga: and then decide what we want to happen, and write a test for it, and implement it :)
[12:37] <Chipaca> but, not before it works for the non-broken case
[12:37] <Chipaca> (we're co slose)
[12:39] <zyga> My point is that you don’t get error
[12:39] <zyga> You get a snap info
[12:39] <zyga> And the error is inside the Broken field
[12:40] <frodus> Hi. I try to make a snap of "Teamviewer version10" by useing Ubuntu 16.04 i386. I have tested that the app it self works before package it. I have made a snap without errors, but when running the snap teamviewer tires to write logfiles to the "non writeable" /snap/teamviewer10/x1/.....   I have heard about $SNAP_USER_DATA but does not know how to use it in my snap to get teamviewer to write in a writeable area. Could anyony point me in the right direction?
[12:41] <popey> hi frodus. does teamviewer have any environment variables or command line options you can pass it?
[12:41] <popey> you could set environment variables in the apps section of the yaml, or pass parameters in the command: line.
[12:42] <frodus> Hi popey. I'll see whay I can find. Is there any other way to acheive this?
[12:43] <popey> Those are the first ways I'd try
[12:44] <popey> Maybe it writes logs to the current directory. Perhaps you can make a launcher script which does a "cd $SNAP_USER_DATA" before launching it
[12:45] <frodus> thanks popey.
[12:49] <Chipaca> zyga: but do you get a Current
[12:51] <Chipaca> zyga: and do we want snapshots failing when the snap is broken
[12:51] <Chipaca> zyga: 'ooh snap broke, better take a snapshot and reinstall it'
[12:51] <Chipaca> zyga: (and note we'll be taking snapshots automatically -- so now you can't remove broken snaps)
[12:52] <Chipaca> bah, it's unclear whether the auto-snapshot failing should error the change, or just leave the data
[12:52] <Chipaca> the latter sounds better; that plus a warning
[13:02] <zyga> Chipaca: that's a great point actually
[13:02] <zyga> worth a comment
[13:08] <mup> PR snapd#5869 closed: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5869>
[13:11] <mup> PR snapd#5911 opened: snap: detect layouts vs layout in snap.yaml (#5869) <Created by zyga> <https://github.com/snapcore/snapd/pull/5911>
[13:13] <mup> PR snapd#5900 closed: release: 2.36~pre1 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5900>
[13:15] <zyga> jdstrand: a trivial one liner that could use your ack https://github.com/snapcore/snapd/pull/5909
[13:15] <mup> PR #5909: allow network_control to also use /sbin/iw <Created by ogra1> <https://github.com/snapcore/snapd/pull/5909>
[13:21] <zyga> Chipaca, mborzecki: a quick review for https://github.com/snapcore/snapd/pull/5908 would be appreciated, for the follow-up fix
[13:21] <mup> PR #5908: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5908>
[13:25] <cachio> sergiusens, https://paste.ubuntu.com/p/WTTFZCBHg6/
[13:25] <cachio> sergiusens, hey,
[13:26] <cachio> any idea what could be causing this error?
[13:26] <sergiusens> cachio: build on 16.04 and it will work
[13:27] <cachio> sergiusens, ok
[13:28] <cachio> is it any workaound to make it work on bionic?
[13:28] <zyga> cachio: build it in a container
[13:29] <zyga> cachio: or use a base: core18 definition
[13:29] <cachio> zyga, ah, ok
[13:37] <zyga>  kenvandine: reproduced, investigating
[13:45] <zyga>  kenvandine debugged
[13:45] <kenvandine> :)
[13:45] <mup> PR snapcraft#2317 opened: tests: add spread suite for plainbox plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2317>
[13:50] <zyga> kenvandine: fixed
[13:53] <kenvandine> zyga: awesome, now to get that fix into cosmic :)
[13:53] <zyga> kenvandine: we could do a distro patch but perhaps not very useful
[13:53] <zyga> kenvandine: the fix is tiny
[13:53] <zyga> mvo is not around today but I would love to see this in the next release candidate of 2.36
[13:54] <kenvandine> zyga: mvo had said he would do a point release with just the fix
[13:54] <zyga> ah, that's ok
[13:54] <zyga> so perhaps tomorrow
[13:54] <zyga> I don't know why he is off today
[13:54] <kenvandine> yeah, please point him to the fix
[13:54] <kenvandine> we talked about it yesterday, so it's on his radar
[13:55] <kenvandine> it's a cosmic release blocker, so it needs to go in
[13:55] <kenvandine> hopefully he's back tomorrow :)
[13:55] <zyga> that's great, I'll just focus on landing it
[14:07] <pedronis> it's a national holiday he said
[14:08] <zyga> ah great
[14:08] <zyga> I was worried he's ill
[14:09] <mup> PR snapd#5912 opened: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5912>
[14:09] <zyga> kenvandine: ^
[14:09] <zyga> mborzecki: ^
[14:10] <zyga> jdstrand: ^
[14:16] <sergiusens> zyga: he as in Michael? German holiday he mentioned
[14:17] <zyga> yeah, that's good to know :)
[14:23] <kenvandine> zyga: awesome
[14:28] <mborzecki> degville: i've dropped some documentation for parallel installs right here https://forum.snapcraft.io/t/parallel-installs/7679 can you take a look?
[14:28] <degville> thanks mborzecki! Just seen it - I'll take a look.
[14:29] <mborzecki> degville: thanks! ping me if you have any questions
[14:29] <degville> mborzecki: will do, thanks.
[14:30] <mborzecki> degville: and sorry for the poor man's tables :)
[14:31] <degville> mborzecki: ahaha! I'll fix them :)
[14:59]  * zyga -> dinner
[15:02] <niemeyer> I need to run an errand as well.. back later
[15:06] <mup> PR snapcraft#2315 closed: tests: use mocked plugins for list-plugins <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2315>
[15:37] <mup> PR snapd#5913 opened:  daemon: expose snapshots to the API <Created by chipaca> <https://github.com/snapcore/snapd/pull/5913>
[15:38] <Chipaca> ^^ 1 more R for snapshots (1 more to go!)
[15:38] <Chipaca> 1 more PR*
[15:38] <Chipaca> taking a break, now
[15:57] <zyga> My daughter is 10 years old now.
[16:15] <pstolowski> i really love snap run --strace
[17:09] <zyga> Chipaca: still here?
[17:21] <mup> Bug #1795947 opened: `snap services` should indicate when services are a oneshot <Snappy:New> <https://launchpad.net/bugs/1795947>
[17:37]  * zyga EODs 
[17:49] <Chipaca> zyga: yes
[18:15] <zyga> Chipaca: can you please look at the PR marked as critical
[18:26] <Chipaca> zyga: will do
[18:26] <Chipaca> zyga: when i get back from the supermarket
[18:28] <mup> PR snapcraft#2314 closed: nodejs plugin: add support for ppc64el and s390x (#2310) (#2310) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2314>
[18:29] <zyga> Thank you
[18:29] <zyga> I want to backport it for 2.36
[18:33] <mup> PR snapd#5912 closed: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Critical> <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5912>
[18:42] <zyga> Wooot
[18:42] <zyga> Thank you
[19:03] <joelkraehemann> hi all
[19:05] <joelkraehemann> https://forum.snapcraft.io/t/alsa-cannot-access-devices/7025
[19:05] <joelkraehemann> ^^ I have the very same problem
[19:05] <joelkraehemann> Here is my snapcraft.yaml:
[19:05] <joelkraehemann> https://bazaar.launchpad.net/~jkraehemann/+junk/gsequencer/view/head:/snap/snapcraft.yaml
[19:06] <joelkraehemann> I have tried all sorts of combination trying to get it up running
[19:06] <joelkraehemann> but without any success
[19:06] <ogra> joelkraehemann, https://forum.snapcraft.io/t/reusable-alsa-lib-part/3556/10
[19:06] <joelkraehemann> I don't want to use pulseaudio at all
[19:07] <joelkraehemann> ogra: just because you share me the link showing this ^^
[19:08] <ogra> joelkraehemann, i dont see any reference to pulse in the remote part that post points to https://github.com/diddledan/snapcraft-alsa
[19:08] <joelkraehemann> pulsify-alsa
[19:09] <joelkraehemann> Yeah, I was trying this ...
[19:09] <ogra> not sure what you are talking about ... that remote part definitely doesnt use pulse and just makes sure to build alsa in a snap consumable way
[19:10] <joelkraehemann> could it be that I have to stage: [- - usr/lib/libasound.so]
[19:10] <ogra> and there are many snaps in the store using it so i'd expect it to work
[19:10] <ogra> if you have probs you probably want to talk to diddledan
[19:11] <ogra> (the author and maintainer of that remote part)
[19:11] <joelkraehemann> thank you
[19:11] <ogra> jdstrand, there is a new dashkiosk-client-browser in the store that would appreciate a helping hand to become a release :)
[19:12] <ogra> (only interested in armhf, you dont need to bother about the other arches if it take extra time)
[19:12] <ogra> *takes
[19:23] <joelkraehemann>     stage:
[19:23] <joelkraehemann>         - -usr/share/alsa
[19:23] <joelkraehemann>         - -usr/lib/x86_64-linux-gnu/libasound.so
[19:23] <joelkraehemann> ^^ is there a way to have an environment variable of x86_64-linux-gnu?
[19:28] <joelkraehemann> I just try to list both x86_64 and i386
[19:28] <joelkraehemann> I think prior the libs in usr/lib/x86_64-linux-gnu/ caused problems
[20:02] <joelkraehemann> ogra: Well it does say anymore about pulseaudio but is what it actually does ;)
[20:03] <joelkraehemann> First my application supports output to pulseaudio
[20:03] <joelkraehemann> What I want is alsa access and not a wrapper
[20:06] <joelkraehemann> ALSA provides just some fancy features like low-latency and MIDI device access
[20:07] <joelkraehemann> So my advice what ever stops you to disable ALSA access, fix it :)
[23:04] <mup> PR snapcraft#2318 opened: meta: add support for the license field <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2318>
[23:06] <jdstrand> ogra: done
[23:07] <jdstrand> and thanks to roadmr for getting r1131 up so fast (it approved r10-r12)
[23:17] <ogra> jdstrand, awesome, thanks (and roadmr too (in absence))