[01:53] zyga: I commented on 5897 (extensively) earlier today (including the trigger) [01:53] zyga: ack on 5901 [01:56] PR snapcraft#2313 closed: meta: link the icon correctly across filesystems [01:59] PR snapcraft#2310 closed: nodejs plugin: add support for ppc64el and s390x [02:02] PR snapcraft#2314 opened: nodejs plugin: add support for ppc64el and s390x (#2310) (#2310) [02:50] PR snapcraft#2304 closed: project loader: remove remote parts support for bases [05:14] morning [06:29] good morning [06:30] jdstrand: thank you on both, looking at feedback [06:31] hey mborzecki [06:31] tests look reddish today [06:31] zyga: hey [06:34] + quiet zypper --gpg-auto-import-keys refresh [06:34]

[06:34] hmmm :/ [06:34] and then [06:34] more openSUSE repo woes https://www.irccloud.com/pastebin/1Xu1svZW/ [06:35] hmm --non-interactive [06:35] we don't pass it do we? [06:36] Download (curl) error for 'http://download.opensuse.org/update/leap/42.3/non-oss/repodata/b95bdb6d60aafb004e5486f977be7f0271423a08250b846de8fbd842d2c0a87a-primary.xml.gz': [06:36] Error code: HTTP response: 500 [06:36] Error message: The requested URL returned error: 500 Internal Server Error [06:36] it's the server side [06:36] well [06:37] fwiw that url is timing out locally too [06:39] ok, if this persists during the day we need to disable opens use [06:39] oh, we disabled 18.04 AFAIR [06:39] we should keep track of those [06:49] ok, time to look at 18.10 live issues [07:36] good morning peeps [07:38] good morning Chipaca [07:38] IRC is splitty this morning [07:38] and openSUSE archive is not responding [07:38] but otherwise things are fine [07:39] my cosmic download will finish tomorrow at this rate :/ [07:39] (it's raining, LTE speed is very low now) [07:40] boo to opensuse [07:40] makes me feel we should have a control panel thing for skipping tests [07:40] also a cache for spread [07:40] boo [07:41] that would be great [07:41] 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] and then spread just skips those [07:44] what could go wrong™ [07:44] schedule ;) [07:48] https://github.com/snapcore/snapd/pull/5904 could we land this? [07:48] PR #5904: spread: put openSUSE to manual [07:49] yes [07:49] Chipaca: ^ [07:53] yay [07:53] Chipaca: thanks! [07:53] hm mup is somewhat quiet today [07:53] split [07:53] PR snapd#5904 closed: spread: put openSUSE to manual [07:54] maybe [08:28] Chipaca: yep, that makes sense. [08:28] 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] ahahaha! [08:29] zyga: hm so requiring network-online.target comes back to haunt us [08:29] but didn't we drop that [08:29] or is my memory backwards/ [08:29] wasn't there a PR to dro that? [08:29] iirc someone from ce team opened it [08:29] right, I think there was one [08:29] but we don't change existing unit [08:29] so :/ [08:30] https://github.com/snapcore/snapd/pull/5746 ? [08:30] PR #5746: wrappers: remove Wants=network-online.target [08:30] so either not released yet [08:30] or released but people did not update [08:30] this is more a "make all service files generated" coming back to haunt us, fwiw [08:30] or rather, the lack of doing that :) [08:30] yeys [08:31] or at least managed with Ensure-like manner like security code is [08:31] (imagine how terrible it would be if we had not done it that way) [08:32] so even if people refresh the core they won't see it fixed [08:32] correct [08:33] they'd have to do eg. snap disable/enable as a workaround [08:33] mborzecki: hope they're not ssh'ing in to do that [08:33] hahaha [08:38] something fishy, NetworkManager is not a snap in a desktop installation, is it? [08:39] https://status.opensuse.org/ [08:39] mborzecki: no, no it should not be a snap (yet) [08:40] 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] 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] mborzecki: it shouldn't afaik, I would hope the issue is something else [09:11] mborzecki: we should be doing that all the time [09:11] any snap refresh foo [09:11] would do that [09:11] or I'm not understanding what you wrote [09:13] 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] 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] pedronis: that's when i tried to install some other snap [09:14] mborzecki: well, as I said parallel installs are not supported [09:14] by the store [09:14] anyway that place is more like the store returned a result for a snap that was only in current [09:14] and not in any action [09:15] pedronis: yes [09:15] pedronis: though i don't recall it doing that, otherwise i'd notice i can't install any snaps [09:15] (from the store obviously) [09:16] it shouldn't in the normal case [09:16] but in your situation it does [09:20] I would need to see the json to say exactly if it store is being unreasonable [09:22] gasp [09:22] yea, the store is a bit wrong here [09:22] bits of our tests still have snapname.developer in them [09:22] pedronis: Howso? [09:23] it's returning an action-like error for something that is only in context [09:23] pedronis: Oh, is it in results rather than error-list? [09:24] yes [09:25] Right, can someone file a bug? [09:25] will do [09:25] Thanks [09:28] pedronis: https://paste.ubuntu.com/p/QGXfB9FPBt/ there you go [09:35] mborzecki: yea, what I expected, thanks [10:05] PR snapd#5905 opened: store: gracefully handle unexpected errors in 'action' response [10:05] pedronis: Chipaca: ^^ [10:21] PR snapd#5906 opened: snap, client, daemon, store: use and expose "media" more [10:51] PR snapcraft#2315 opened: tests: use mocked plugins for list-plugins [10:57] hoping for a second review on #5903 [10:57] PR #5903: overlord/snapshotstate: store epoch in snapshot, check on restore [10:57] (I've got a followup already ready to go) [11:12] PR snapcraft#2316 opened: storeapi: Use structured data for the conflicted current value [11:15] PR snapd#5902 closed: cmd/snap: tweak UX of snap refresh --list [11:22] Chipaca: can you take a look at https://github.com/snapcore/snapd/pull/5898 ? [11:22] sergiusens: o/ [11:22] PR #5898: tests: spread tests for aliases with parallel installed snaps [11:23] mborzecki: probably yes [11:23] Chipaca: it's aliases :) [11:23] give me a sec to save state [11:23] Chipaca: sure, thank you! [11:28] niemeyer: pushed new changes to https://github.com/snapcore/snapd/pull/5759 and commented, let me know what you think [11:28] PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug === pstolowski is now known as pstolowski|lunch [11:31] niemeyer: ah, and i think i missed part of your suggestion regarding including attribute names in the key to avoid collision; will address this === Mirv_ is now known as Mirv [11:35] is cdimage.ubuntu.com slow for everyone or just me? [11:36] I'm getting 50KB/s roughly [11:36] I have no idea what veeam is, but I already don't like it [11:36] zyga: getting 7MB/s here [11:36] sigh , thanks [11:37] I rebooted my router [11:40] zyga: you don't have an implementation of tempdir from snap-update-ns etc, right? [11:40] tempdir? [11:41] I don't think we use any apart from stdlbi [11:41] *stdlib [11:42] zyga: yeah me neither [11:43] what do you need? [11:43] zyga: vvv [11:43] * Chipaca prods mup [11:44] PR snapd#5907 opened: overlord/snapshotstate: chown the tempdir [11:44] zyga: ^^^ [11:45] zyga: I'd love to have a mktempdir that uses O_TEMPDIR :) [11:45] Chipaca: note that the O_TMPFILE thing is only suitable for files, not for directories AFAIK [11:45] yeah that [11:45] oohhhhhh awwww [11:45] boo [11:45] right? [11:45] * Chipaca manpages [11:45] software sucks [11:45] nah, 's ok [11:45] software i can fix [11:46] fg [11:46] heh [11:47] I _just_ got this message from you: zyga: I'd love to have a mktempdir that uses O_TEMPDIR :) [11:47] ordering FTW [11:47] wut [11:47] your network is in distress [11:47] irc can't do out-of-order, so your client is loopy [11:49] are you sure? [11:49] I just noticed it appearing mid log [11:51] zyga: it's a tcp connection [11:51] a single one [11:51] hohoh [11:51] Chipaca: something cool to show you [11:52] oh dear [11:52] http://paste.ubuntu.com/p/Y2zpfGNkQg/ [11:52] while my network sucks at pulling ISOs [11:52] I'm going back to past PRs [11:52] remember this one? [11:53] evil genius or evil madman? [11:55] anyone know of a simple snap that has services, is in the store and is not lxd? [11:55] xkcd-webserver? [11:55] oh, let me try that [11:57] 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] PR #5905: store: gracefully handle unexpected errors in 'action' response [12:01] mborzecki: what will happen if you run 'snap alias foo_bar.baz baz' with a core that doesn't understand instances? [12:02] Chipaca: you won't have foo_bar installed [12:02] s/core/snapd/ i meant [12:02] right, so there's no way to get a SnapSetup that uses a snap name instead of the instance name [12:03] that wasn't created when they were equivalent [12:03] bah [12:03] yes, _ was also invalid for snap names [12:04] 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] mborzecki: bear in mind there is store work still being done to support parallel [12:05] 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] s/run 'snap alias'/run 'snap alias foo_bar.baz baz'/ [12:05] Chipaca: I pushed the changes to https://github.com/snapcore/snapd/pull/5869 - please have a look [12:05] no [12:05] PR #5869: snap: detect layouts vs layout in snap.yaml [12:05] Chipaca: you mean the aliases PR? [12:06] mborzecki: y [12:06] it's generic and gives pretty useful error messages [12:07] 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] i had a change somewhere which triggered panics if snapstate or snapup had name with _ but instancekey was unset [12:08] but this is probably only appropriate for tests, not the end users [12:09] agreed [12:10] 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] which is why I +1'ed [12:10] yup [12:10] but, thought I'd ask [12:10] as these things make my hair wobble [12:11] fwiw, the spread tests were written (somewhat deliberate) before the code change [12:11] and were passing :) [12:12] 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] FYI: I re-opened the PR that adds a spread test showing how layout migration may fail due to leftovers [12:13] https://github.com/snapcore/snapd/pull/5908 [12:13] PR #5908: tests,cmd/snap-update-ns: add test showing mount update bug [12:14] to make it easier to see what happens with the bug fix [12:14] PR snapd#5908 opened: tests,cmd/snap-update-ns: add test showing mount update bug [12:14] mostly a note to self: we should try to make commands in a family point to the other ones [12:14] e.g. have 'snap aliases' mention alias, unalias, prefer [12:14] etc [12:15] note to chipaca, you should make notes to self mention other people so that they remind you of your notes to self ;-) [12:15] not necessarily all in all of them, but try to make it non-disconnected [12:15] but yeah [12:15] zyga: when they're serious, I make notes to niemeyer and then EOD [12:15] like 'snap refresh --dry-run' yesterday [12:15] LOL [12:15] it would be nice to have a common theme (e.g. how they are worded or introduced) for such hints [12:16] speaking of hints, I created a label for snapshot prs, because that's how i roll now [12:20] Chipaca: review on https://github.com/snapcore/snapd/pull/5906 [12:20] PR #5906: snap, client, daemon, store: use and expose "media" more [12:21] zyga: I have a review in my review! [12:21] refresh [12:21] oh noes [12:21] * Chipaca refreshes again [12:21] * zyga stops now ;) [12:21] sorry, your icon triggered me ;) [12:22] it's not even on that PR, but ok :) [12:23] PR snapd#5909 opened: allow network_control to also use /sbin/iw [12:26] Chipaca: https://github.com/snapcore/snapd/pull/5903#pullrequestreview-161136203 [12:26] PR #5903: overlord/snapshotstate: store epoch in snapshot, check on restore <📸󠁟̻> [12:28] PR snapd#5903 closed: overlord/snapshotstate: store epoch in snapshot, check on restore <📸󠁟̻> [12:28] PR snapd#5910 opened: snapshotstate: restore to current revision <📸󠁟̻> === pstolowski|lunch is now known as pstolowski [12:31] laptop just powered off [12:31] * Chipaca worries [12:32] Uh [12:32] nothing in the logs that i can see [12:32] * zyga -> walk [12:32] anyway, one snapshots PR in, so pushed another [12:32] :-) [12:37] zyga: once snapshots is landed, I'll see what happens if you try to snapshot a broken snap [12:37] zyga: or restore into it [12:37] zyga: and then decide what we want to happen, and write a test for it, and implement it :) [12:37] but, not before it works for the non-broken case [12:37] (we're co slose) [12:39] My point is that you don’t get error [12:39] You get a snap info [12:39] And the error is inside the Broken field [12:40] 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] hi frodus. does teamviewer have any environment variables or command line options you can pass it? [12:41] you could set environment variables in the apps section of the yaml, or pass parameters in the command: line. [12:42] Hi popey. I'll see whay I can find. Is there any other way to acheive this? [12:43] Those are the first ways I'd try [12:44] 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] thanks popey. [12:49] zyga: but do you get a Current [12:51] zyga: and do we want snapshots failing when the snap is broken [12:51] zyga: 'ooh snap broke, better take a snapshot and reinstall it' [12:51] zyga: (and note we'll be taking snapshots automatically -- so now you can't remove broken snaps) [12:52] bah, it's unclear whether the auto-snapshot failing should error the change, or just leave the data [12:52] the latter sounds better; that plus a warning [13:02] Chipaca: that's a great point actually [13:02] worth a comment [13:08] PR snapd#5869 closed: snap: detect layouts vs layout in snap.yaml [13:11] PR snapd#5911 opened: snap: detect layouts vs layout in snap.yaml (#5869) [13:13] PR snapd#5900 closed: release: 2.36~pre1 [13:15] jdstrand: a trivial one liner that could use your ack https://github.com/snapcore/snapd/pull/5909 [13:15] PR #5909: allow network_control to also use /sbin/iw [13:21] Chipaca, mborzecki: a quick review for https://github.com/snapcore/snapd/pull/5908 would be appreciated, for the follow-up fix [13:21] PR #5908: tests,cmd/snap-update-ns: add test showing mount update bug [13:25] sergiusens, https://paste.ubuntu.com/p/WTTFZCBHg6/ [13:25] sergiusens, hey, [13:26] any idea what could be causing this error? [13:26] cachio: build on 16.04 and it will work [13:27] sergiusens, ok [13:28] is it any workaound to make it work on bionic? [13:28] cachio: build it in a container [13:29] cachio: or use a base: core18 definition [13:29] zyga, ah, ok [13:37] kenvandine: reproduced, investigating [13:45] kenvandine debugged [13:45] :) [13:45] PR snapcraft#2317 opened: tests: add spread suite for plainbox plugin [13:50] kenvandine: fixed [13:53] zyga: awesome, now to get that fix into cosmic :) [13:53] kenvandine: we could do a distro patch but perhaps not very useful [13:53] kenvandine: the fix is tiny [13:53] mvo is not around today but I would love to see this in the next release candidate of 2.36 [13:54] zyga: mvo had said he would do a point release with just the fix [13:54] ah, that's ok [13:54] so perhaps tomorrow [13:54] I don't know why he is off today [13:54] yeah, please point him to the fix [13:54] we talked about it yesterday, so it's on his radar [13:55] it's a cosmic release blocker, so it needs to go in [13:55] hopefully he's back tomorrow :) [13:55] that's great, I'll just focus on landing it [14:07] it's a national holiday he said [14:08] ah great [14:08] I was worried he's ill [14:09] PR snapd#5912 opened: interfaces/apparmor: handle overlayfs snippet for snap-update-ns [14:09] kenvandine: ^ [14:09] mborzecki: ^ [14:10] jdstrand: ^ [14:16] zyga: he as in Michael? German holiday he mentioned [14:17] yeah, that's good to know :) [14:23] zyga: awesome [14:28] 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] thanks mborzecki! Just seen it - I'll take a look. [14:29] degville: thanks! ping me if you have any questions [14:29] mborzecki: will do, thanks. [14:30] degville: and sorry for the poor man's tables :) [14:31] mborzecki: ahaha! I'll fix them :) [14:59] * zyga -> dinner [15:02] I need to run an errand as well.. back later [15:06]