| anuragh | #blackarch | 01:34 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| zyga_ | good morning | 08:01 |
| zyga_ | Pharaoh_Atem: looking :/ | 08:01 |
| mup | PR snapd#3248 closed: tests: fail early in the spread suite if trying to run it inside a container <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3248> | 08:01 |
| zyga_ | aha, not great | 08:01 |
| zyga_ | Pharaoh_Atem: I'll fix that in a sec, thanks for reporting | 08:01 |
| pstolowski | hey zyga_ ! | 08:02 |
| zyga_ | pstolowski: hello | 08:02 |
| zyga_ | Pharaoh_Atem: offtipic, can I propose rawhide packaging for inclusion into packaging/ | 08:05 |
| zyga_ | Pharaoh_Atem: it will be useful for CI soon | 08:05 |
| === zyga_ is now known as zyga | ||
| morphis | zyga: we can't yet | 08:15 |
| zyga | morphis: because of patches/ | 08:15 |
| morphis | zyga: we still miss changes to get snap-confine building | 08:15 |
| zyga | morphis: we can add the actual patches too you know | 08:15 |
| morphis | zyga: but I have things locally and will submit PRs soon | 08:15 |
| zyga | aha ok | 08:15 |
| * zyga pushed the fix for shellcheck | 08:15 | |
| zyga | now where's my github token :/ | 08:15 |
| morphis | unless we have initial CI I would like to held the .spec file back | 08:16 |
| morphis | as only then it has value inside the tree | 08:16 |
| morphis | zyga: but if you have a good idea of how we can solve the problem http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/0001-cmd-use-libtool-for-the-internal-library.patch solves, that would be awesome :-) | 08:17 |
| zyga_ | Pharaoh_Atem: https://github.com/snapcore/snapd/pull/3258 | 08:19 |
| mup | PR snapd#3258: cmd/snap-confine/tests: fix shellcheck on recently added files <Created by zyga> <https://github.com/snapcore/snapd/pull/3258> | 08:19 |
| mup | PR snapd#3258 opened: cmd/snap-confine/tests: fix shellcheck on recently added files <Created by zyga> <https://github.com/snapcore/snapd/pull/3258> | 08:19 |
| zyga_ | pstolowski: this needs a 2nd trivial review https://github.com/snapcore/snapd/pull/3234 | 08:21 |
| mup | PR snapd#3234: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <https://github.com/snapcore/snapd/pull/3234> | 08:21 |
| pstolowski | ok | 08:21 |
| zyga | morphis, Pharaoh_Atem: is that shellcheck fix something you can easily carry in the tree? | 08:25 |
| zyga | (as a pathc) | 08:25 |
| zyga | patch | 08:25 |
| morphis | zyga: I think Pharaoh_Atem is fine as long as we have a PR or the PR merged upstream | 08:25 |
| mup | PR snapd#3230 closed: tests: extend network-control spread test to cope with network namespaces <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3230> | 08:26 |
| morphis | zyga: do you have a raspbian system at hand? | 08:29 |
| Chipaca | morphis— out of curiosity, for what? | 08:29 |
| morphis | Chipaca: snapd packages :-) | 08:29 |
| zyga | morphis: yes | 08:30 |
| zyga | well | 08:30 |
| zyga | on a pi1 | 08:30 |
| zyga | but I can (probably) move that to a pi2/3 easily | 08:30 |
| morphis | zyga: hm, would be nice to see the error message on the pi1 | 08:30 |
| zyga | error message about? | 08:31 |
| morphis | zyga: that we don't have a suitable core snap for the pi1 | 08:32 |
| morphis | I guess it will try to load the armhf one but not sure | 08:32 |
| mup | PR snapd#3234 closed: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3234> | 08:32 |
| zyga | morphis: I think it will just fail, let me try | 08:33 |
| zyga | pstolowski: thanks! | 08:33 |
| morphis | zyga: yeah | 08:33 |
| zyga | pi1 is so slow... | 08:33 |
| morphis | :-) | 08:34 |
| Chipaca | zyga— remember snap 1 on the bbb? | 08:34 |
| Chipaca | or weren't you around for that | 08:34 |
| Chipaca | snappy* | 08:34 |
| zyga | Chipaca: snap 1 as in 15.04 snapd? | 08:34 |
| Chipaca | snappy --help | 08:34 |
| pstolowski | zyga, yw | 08:34 |
| Chipaca | <30 seconds waiting> | 08:34 |
| zyga | Chipaca: I recall it was slow :D | 08:34 |
| zyga | was that in python or all go already? | 08:34 |
| Chipaca | snappy was python | 08:35 |
| zyga | heh | 08:35 |
| zyga | nice :D | 08:35 |
| Chipaca | and the slow was the main driver for the move to go | 08:35 |
| * zyga would love to see python code of snappy | 08:35 | |
| Chipaca | zyga— no, no you wouldn't | 08:35 |
| Chipaca | but it's in git :-) | 08:35 |
| Chipaca | zyga— this was pre-overlord, so the fs was the transaction layer | 08:35 |
| zyga | was is terrible? | 08:36 |
| zyga | aaaaha :D | 08:36 |
| zyga | remember the 16.04 push to make the insanity go away? | 08:36 |
| zyga | morphis: let me update first, I'll install snapd shortly | 08:36 |
| morphis | zyga: let me upload the repo first | 08:38 |
| zyga | morphis: which repo is that? | 08:47 |
| morphis | zyga: deb https://mm.gravedo.de/raspbian/ jessie main | 08:49 |
| zyga_ | morphis: fyi, raspbian already has snapd | 08:50 |
| zyga_ | 500 http://archive.raspbian.org/raspbian stretch/main armhf Packages | 08:50 |
| morphis | zyga: stretch does, yes | 08:51 |
| zyga_ | 2.21-2 | 08:51 |
| morphis | zyga: that is currently in rc | 08:51 |
| morphis | so everyone out there is still using raspbian based on debian 8 | 08:51 |
| morphis | which doesn't have it | 08:51 |
| morphis | and a stable raspbian based on debian 9 is still months away | 08:51 |
| morphis | zyga: what you officially get from the pi foundation is jessie: https://www.raspberrypi.org/downloads/raspbian/ | 08:57 |
| morphis | zyga: are you running stretch then on your pi? | 09:00 |
| === chihchun is now known as chihchun_afk | ||
| zyga_ | morphis: yes | 09:05 |
| zyga_ | morphis: well, not stretch, but raspbian + jessie/wheezy/stretch raspbian archives | 09:05 |
| morphis | sounds hacky :-) | 09:06 |
| morphis | zyga: however, if you add the repository you should get snapd 2.24 | 09:12 |
| === chihchun_afk is now known as chihchun | ||
| pstolowski | zyga, have you seen the failures in master? https://forum.snapcraft.io/t/tests-broken-in-master/457 | 09:15 |
| zyga_ | pstolowski: no, looking now | 09:16 |
| zyga_ | pstolowski: can you please edit your post to use formatting | 09:16 |
| morphis | zyga_: once I did some more testing I will make a post in the forum to call for wider testing | 09:18 |
| zyga_ | morphis: ^ did you see that failure? update test hangs on debian | 09:20 |
| morphis | zyga_: which failure? | 09:21 |
| morphis | pstolowski: you have a link to the test run on in travis? | 09:24 |
| pstolowski | zyga, done; i thought I did by using ` , but apparently it's not enough | 09:24 |
| pstolowski | zyga, https://travis-ci.org/snapcore/snapd/builds/227867834?utm_source=email&utm_medium=notification | 09:25 |
| zyga_ | pstolowski: I think you need ``` | 09:25 |
| pstolowski | i'm not sure it's from the same travis run, but failed the same I think | 09:26 |
| zyga_ | pstolowski: so... | 09:27 |
| zyga_ | pstolowski: I think we rejected one fix that may be the cause here | 09:27 |
| pstolowski | it got stuck on Run configure hook of "core" snap if present | 09:27 |
| morphis | zyga, pstolowski: so this is running 2.21 and installing the core snap from stable | 09:27 |
| morphis | zyga, pstolowski: sounds very muhc like https://bugs.launchpad.net/snappy/+bug/1674193 | 09:29 |
| mup | Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:Fix Committed by morphis> <snapd (Debian):Fix Committed> <snapd (Fedora):Fix Committed by morphis> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193> | 09:29 |
| pstolowski | morphis, indeed it's an upgrade from old version. but I wonder why it's failing now, i don't think it's a new test? | 09:31 |
| morphis | pstolowski: did we release a new core snap to stable recently? | 09:31 |
| pstolowski | or rather, any new conditions | 09:31 |
| pstolowski | dunno | 09:32 |
| morphis | zyga_: any idea? | 09:32 |
| zyga_ | morphis: yes | 09:32 |
| * zyga_ looks for the PR | 09:32 | |
| zyga_ | https://github.com/snapcore/snapd/pull/3145 | 09:33 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3145> | 09:33 |
| morphis | zyga_, pstolowski: ok, can reproduce the same problem on my debian install | 09:33 |
| zyga_ | look at https://github.com/snapcore/snapd/pull/3145/commits/71ce65eb95b3210515a8c81f4737e5c3d9bd18fb | 09:34 |
| zyga_ | so we rejected that PR | 09:34 |
| zyga_ | let me try to recall the rationale | 09:34 |
| zyga_ | https://github.com/snapcore/snapd/pull/3145#discussion_r110766622 | 09:34 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3145> | 09:34 |
| pstolowski | zyga, looking at your last comment, you had a simpler variant merged? | 09:34 |
| zyga_ | so the question is, why did the slot not auto-connect after restarting into new snapd? | 09:35 |
| morphis | zyga: with a core snap from edge the problem doesn't exist | 09:35 |
| morphis | a $ snap install core fails and a $ snap install --edge core works | 09:36 |
| zyga_ | morphis: how about edge? | 09:36 |
| zyga_ | er | 09:36 |
| zyga_ | beta | 09:36 |
| morphis | zyga: what do we have currentl in stable? | 09:36 |
| zyga_ | morphis: no idea | 09:36 |
| zyga_ | morphis: the version field is useless | 09:36 |
| morphis | wonderful .. | 09:36 |
| zyga_ | ogra_: hey | 09:37 |
| ogra_ | zyga_, yo | 09:37 |
| zyga_ | ogra_: is the snapcrat feature that would let us give real and sensible verison available now | 09:37 |
| pstolowski | shall we take this conversation to https://forum.snapcraft.io/t/tests-broken-in-master/457? | 09:37 |
| zyga_ | ogra_: so that "snap info core" shows the snapd version there? | 09:37 |
| ogra_ | zyga_, not sure if it landed with the last drop | 09:37 |
| morphis | zyga_: beta works too | 09:38 |
| ogra_ | zyga_, if it did i have to do a few changes first ... the bug wasnt closed but perhaps thats just an oversight from sergio | 09:38 |
| zyga_ | ogra_: aha, thanks | 09:38 |
| zyga_ | morphis: ok, then when 2.25 is released this should be fixed | 09:38 |
| morphis | zyga: right | 09:38 |
| morphis | however that wont help us to get CI back working on master | 09:38 |
| morphis | zyga_: unless we do a $ snap install --beta core for debian during the test run | 09:39 |
| zyga_ | morphis: I think that's a reasonable compromise for now | 09:39 |
| morphis | let me do a PR | 09:39 |
| zyga_ | is federico working today? I'd like to know his opinion | 09:39 |
| zyga_ | morphis: please do, thanks! | 09:39 |
| zyga_ | pstolowski: yeah, let's summarize on the forum | 09:41 |
| zyga_ | we can paste this converstation | 09:41 |
| morphis | zyga_, pstolowski: https://github.com/snapcore/snapd/pull/3259 | 09:43 |
| mup | PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259> | 09:43 |
| morphis | pstolowski: can you summarize the discussion in the forum? | 09:43 |
| mup | PR snapd#3259 opened: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259> | 09:44 |
| pstolowski | morphis, will do | 09:49 |
| zyga_ | morphis: hmm | 09:52 |
| zyga_ | morphis: so one question | 09:52 |
| zyga_ | morphis: after 2.25 is out it won't change anything in debian | 09:52 |
| zyga_ | morphis: because debian is frozen, right? | 09:52 |
| zyga_ | morphis: so I'm trying to understand one thing there | 09:52 |
| zyga_ | morphis: the test installs some debs | 09:52 |
| zyga_ | morphis: are they not the same as snapd in edge? | 09:52 |
| zyga_ | morphis: (except for the name of the plug?) | 09:52 |
| zyga_ | morphis: what I'm trying to say is that perhaps, if we get this rigth, the change is not needed, no need to special-case debian | 09:53 |
| zyga_ | morphis: I think some code may be missing from master | 09:53 |
| zyga_ | morphis: master contains code that renames core-support to core-support-plug | 10:00 |
| zyga_ | morphis: so it should work | 10:00 |
| morphis | why? | 10:01 |
| morphis | better asked, why -plug as suffix? | 10:01 |
| pstolowski | morphis, zyga_ summarized the discussion in the forum, let me know if i missed anything | 10:01 |
| zyga_ | morphis: to keep plug and slot names distinct | 10:01 |
| morphis | zyga_: isn't is already imminent for a plug that it is a plug? | 10:02 |
| Son_Goku | ogra_: in re yesterday's question about test script, I don't know | 10:05 |
| Son_Goku | maybe? | 10:05 |
| Son_Goku | the shellcheck thing has always been there, though | 10:05 |
| Son_Goku | it passed in 2.24 | 10:06 |
| Son_Goku | zyga_, morphis: https://paste.fedoraproject.org/paste/NmsFYMd2WEStihK1ATvizV5M1UNdIGYhyRLivL9gydE= | 10:06 |
| Son_Goku | shellcheck test fails on 2.25 | 10:06 |
| ogra_ | Son_Goku, to late ... fix is alöready pending | 10:06 |
| ogra_ | :) | 10:06 |
| Son_Goku | ogra_: is there an active PR? | 10:06 |
| ogra_ | (zyga works in his sleep :P ) | 10:06 |
| ogra_ | https://github.com/snapcore/snapd/pull/3258 | 10:07 |
| mup | PR snapd#3258: cmd/snap-confine/tests: fix shellcheck on recently added files <Created by zyga> <https://github.com/snapcore/snapd/pull/3258> | 10:07 |
| Son_Goku | excellent :D | 10:07 |
| Son_Goku | well... not so excellent | 10:07 |
| Son_Goku | what the hell happened to spread/travis? | 10:07 |
| Son_Goku | oh, welp | 10:08 |
| morphis | Son_Goku: from what I experienced so far there are differences between shellcheck on Ubuntu and others | 10:08 |
| ogra_ | also the version plays a role | 10:08 |
| Son_Goku | yeah, shellcheck runs are disabled on F24 and older | 10:08 |
| ogra_ | the 14.04 shellcheck is pretyt crappy ... not sure what versioon that was thopugh | 10:08 |
| Son_Goku | because shellcheck < 0.4.4 doesn't actually support -x | 10:09 |
| ogra_ | my trees all install a 16.04 chroot when doing shellcheck | 10:09 |
| Son_Goku | Fedora 24 and EPEL 7 have shellcheck 0.3.x, which can't actually run the tests :/ | 10:09 |
| ogra_ | is pedronis around today ? | 10:09 |
| ogra_ | manually upgrading a pi3 gets me "[/] Setup snap "core" (1829) security profiles (phase 2)" ... forever .... shell prompt never returns | 10:10 |
| ogra_ | (pretty much like described in one of the forum threads) | 10:11 |
| Son_Goku | wut | 10:18 |
| Son_Goku | this PR somehow breaks Fedora builds | 10:18 |
| zyga_ | Son_Goku: fixed | 10:18 |
| zyga_ | Son_Goku: sorry, the patch had a broken file inside by accident | 10:18 |
| Son_Goku | take 4 | 10:19 |
| Son_Goku | good, gobuild is fixed | 10:21 |
| Son_Goku | now we're at C build | 10:21 |
| Son_Goku | shellcheck passed... good | 10:21 |
| zyga_ | Son_Goku: yeah, sorry about the earlier patch | 10:23 |
| * zyga_ feels like he has cold :/ | 10:24 | |
| ogra_ | zyga_, dude ... i tend to test stuff before commenting ... shellcheck didnt disagree ;) | 10:24 |
| ogra_ | but leave it ugly if you feel like ;) | 10:24 |
| zyga_ | ogra_: I think it may be different version then, I did fix all the things shellcheck reported | 10:25 |
| zyga_ | ogra_: I tested on F26 | 10:25 |
| ogra_ | ah | 10:25 |
| zyga_ | I wanted to have a patch that would be clean for fedora packaging | 10:25 |
| ogra_ | well, newer ubuntu versions might spill a warning there | 10:25 |
| zyga_ | btw, I think shellcheck would disagree about $FOO/"whatever" but I may be worng | 10:25 |
| zyga_ | warning? | 10:26 |
| ogra_ | yeah | 10:26 |
| zyga_ | about extra quoting? | 10:26 |
| Son_Goku | zyga_: I think shellcheck would be fine with "$FOO/whatever", though | 10:26 |
| ogra_ | about possible interpretation as: "$TMP/$(basename " $0 ")" | 10:27 |
| Son_Goku | well, for inner quotes, shouldn't you use a different quote for the inner one? | 10:27 |
| ogra_ | anyway, if it doesnt complain now, leave it | 10:27 |
| Son_Goku | like single quotes for inner and double for outer | 10:27 |
| ogra_ | technically just quoting $0 is enough | 10:28 |
| zyga_ | Son_Goku: no, that's actually correct | 10:29 |
| zyga_ | Son_Goku: $() gives new quoting context | 10:29 |
| Son_Goku | zyga_: ah | 10:29 |
| Son_Goku | shell is confusing :) | 10:29 |
| zyga_ | Son_Goku: "$(echo "This is $(echo "ok")")" | 10:29 |
| zyga_ | yes | 10:29 |
| Son_Goku | well, I'm about ready to commit my 2.25 package | 10:31 |
| zyga_ | +1 | 10:31 |
| Son_Goku | unless there's any other patches I need besides PR3222 and PR3258 (though I don't need the latter) | 10:31 |
| zyga_ | Son_Goku: not sure, I don't know of any | 10:31 |
| Son_Goku | well, I guess that's what testing updates is for :) | 10:32 |
| Son_Goku | I've also created a snap-mgmt script that will be run on %preun on final removal | 10:32 |
| Son_Goku | based on the snapd.postrm script | 10:32 |
| Son_Goku | so that will need specific testing | 10:32 |
| Son_Goku | zyga_, morphis: building: https://koji.fedoraproject.org/koji/taskinfo?taskID=19367859 | 10:36 |
| morphis | Son_Goku: awesome! | 10:36 |
| zyga_ | Son_Goku: thank you | 10:37 |
| Son_Goku | building on all Fedora branches now | 10:38 |
| Son_Goku | zyga_: there are some advantages to building for an upstream distro that moves fast :) | 10:39 |
| Son_Goku | I hate armv7hl builds :( | 10:45 |
| Son_Goku | they need to fully move over to the VMs on aarch64 hosts | 10:45 |
| Son_Goku | those are so much faster... | 10:45 |
| zyga_ | Chipaca: hey | 10:57 |
| Chipaca | zyga_— hi | 10:58 |
| zyga_ | Chipaca: can you please review https://github.com/snapcore/snapd/pull/3259 | 10:58 |
| mup | PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259> | 10:58 |
| zyga_ | Chipaca: master is currently broken because of htis | 10:58 |
| zyga_ | Chipaca: howerver plase note what I said above: | 10:58 |
| zyga_ | Chipaca: actually let me add that to the forum | 10:59 |
| Chipaca | zyga_— you said a lot of things above. Which is the note? | 10:59 |
| zyga_ | https://forum.snapcraft.io/t/tests-broken-in-master/457/6 | 10:59 |
| zyga_ | I want to fix master but I'm not sure this is the actual fix | 10:59 |
| zyga_ | and that we're not missing anything | 11:00 |
| Son_Goku | zyga_, morphis: https://bodhi.fedoraproject.org/updates/FEDORA-2017-866e9643a8 (F24), https://bodhi.fedoraproject.org/updates/FEDORA-2017-2e4459fa03 (F25), https://bodhi.fedoraproject.org/updates/FEDORA-2017-74f7c7df46 (F26) | 11:06 |
| Son_Goku | morphis, zyga_: please specifically test final removal of snapd *after* upgrading or installing v2.25 | 11:10 |
| Son_Goku | source script: https://src.fedoraproject.org/cgit/rpms/snapd.git/tree/snap-mgmt.sh | 11:10 |
| Son_Goku | install step: https://src.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n434 | 11:11 |
| Son_Goku | scriptlet execution: https://src.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n568 | 11:11 |
| zyga_ | Son_Goku: ack, will do | 11:12 |
| morphis | Son_Goku: will do! | 11:13 |
| Son_Goku | this is specifically for solving https://bugzilla.redhat.com/show_bug.cgi?id=1444422, so that's what this aims to fix | 11:14 |
| * Son_Goku hopes the patch load doesn't get any bigger on snapd... | 11:17 | |
| Son_Goku | I'm sort of cheating by using PR diffs, but the number of patches being applied to snapd is quite high now :( | 11:17 |
| Chipaca | fwiw i think we agreed that we should let you remove core if it was the last snap left, but it wasn't prioritised | 11:28 |
| zyga_ | Chipaca: yes, I think we agreed | 11:29 |
| Chipaca | (but my memory is bad so don't trust me alone on this) | 11:29 |
| zyga_ | Chipaca: I think it should be easy, right? | 11:29 |
| zyga_ | Chipaca: no other snap installs in progress | 11:29 |
| zyga_ | Chipaca: and no other snaps | 11:29 |
| Chipaca | zyga_— i think it wasn't super easy because of how isolated the bit that checks for core was, but i could be misremembering | 11:30 |
| Chipaca | in any case, it still isn't prioritised :-) | 11:30 |
| zyga_ | Chipaca: we could catch the context at the time the op is made | 11:30 |
| zyga_ | and pass a flag like "ok-to-remove-core' | 11:30 |
| Chipaca | zyga_— that sounds like the wrong way to do it | 11:32 |
| * Son_Goku grumbles about crappy hotel Wi-Fi | 11:33 | |
| Chipaca | lunch! | 11:51 |
| pstolowski | good idea | 12:01 |
| ogra_ | zyga_, https://bugs.launchpad.net/snapd/+bug/1687608 ... you asked about more info about this in https://forum.snapcraft.io/t/device-gets-bricked-after-trying-to-upgrade-core-snap/453 .... i can reproduce it fine here if you want me to collect data | 12:04 |
| mup | Bug #1687608: running "snap refresh core" on an UbuntuCore device locks you out until reboot <snapd:New> <https://launchpad.net/bugs/1687608> | 12:04 |
| === palasso_ is now known as palasso | ||
| zyga_ | re | 12:11 |
| zyga_ | ogra_: looking | 12:11 |
| morphis | zyga_: you had time to give snapd on raspbian a try? | 12:12 |
| zyga_ | ogra_: aha, can you tell me what is in snap changes? | 12:12 |
| zyga_ | morphis: no, I left the apt-get update && apt-get dist-upgrade -y running in the background | 12:12 |
| zyga_ | let's see | 12:12 |
| ogra_ | zyga_, http://paste.ubuntu.com/24498251/ | 12:13 |
| Son_Goku | morphis, zyga_: could one of you guys create a topic on the forums announcing the snapd 2.25 testing for Fedora once it syncs out to updates-testing? | 12:14 |
| ogra_ | zyga_, note that my SD is worn out, thus change 13 failed (but rolled byck fine) ... change 14 is the actual one showing the issue | 12:14 |
| ogra_ | *back | 12:14 |
| zyga_ | interesting | 12:15 |
| zyga_ | I wonder why change 13 failed | 12:15 |
| zyga_ | how is your SD a factor? | 12:15 |
| ogra_ | zyga_, because uboot.env was trashed (Sd worn out) | 12:16 |
| zyga_ | aah | 12:16 |
| zyga_ | 2017-05-02T09:40:50Z ERROR cannot finish core installation, there was a rollback across reboot | 12:16 |
| morphis | Son_Goku: sure | 12:16 |
| ogra_ | right, ignore that one | 12:16 |
| ogra_ | it rolled back fine | 12:16 |
| zyga_ | ogra_: ok so after rollback what did you do? | 12:16 |
| ogra_ | zyga_, snap refresh core | 12:17 |
| zyga_ | 2017-05-02T10:04:41Z INFO Waiting for restart... | 12:17 |
| zyga_ | I'm trying to grok the log there | 12:17 |
| zyga_ | it was waiting for restart over and over | 12:17 |
| ogra_ | which also works fine but does never finish the "Setup snap "core" (1829) security profiles (phase 2)" bit | 12:17 |
| zyga_ | yeah | 12:17 |
| zyga_ | I think we have a bug there | 12:17 |
| zyga_ | let me look | 12:17 |
| ogra_ | yes, we do | 12:17 |
| ogra_ | it used to give me the console back before ... now it doesnt anymore | 12:17 |
| zyga_ | weird | 12:19 |
| zyga_ | so | 12:19 |
| zyga_ | we log that message when snapd itself saves in the state that it is waiting to restart | 12:19 |
| ogra_ | yeah, the message was there before ... but didnt spin forever | 12:20 |
| zyga_ | and that is not even saved in the state | 12:20 |
| zyga_ | it's just saved in memory | 12:20 |
| zyga_ | so we really need to restart | 12:20 |
| zyga_ | (though I suspect that it may be broken if we restart snapd rather then the machine) | 12:20 |
| ogra_ | the security profiles thing is saved in memory ? | 12:20 |
| zyga_ | ogra_: no | 12:20 |
| zyga_ | the "restarting" flag | 12:20 |
| ogra_ | the restarting flag isnt the issue | 12:21 |
| zyga_ | the task just does nothing until that flag is cleaned | 12:21 |
| zyga_ | so what is? | 12:21 |
| ogra_ | the issue is "Setup snap "core" (1829) security profiles (phase 2)" never finishing | 12:21 |
| ogra_ | or at least never returning the console access | 12:21 |
| zyga_ | ogra_: ... | 12:21 |
| zyga_ | ogra_: did you look at the code? | 12:21 |
| ogra_ | no | 12:21 |
| zyga_ | ogra_: the restaring flag guards that code from running | 12:21 |
| zyga_ | ogra_: that's why I mentioned it | 12:22 |
| ogra_ | well, the code obviously runs :) | 12:22 |
| zyga_ | ogra_: yes and bails out instantly because of that | 12:22 |
| ogra_ | http://paste.ubuntu.com/24498125/ shows even the spinner rotating between line 60 and 78 | 12:22 |
| zyga_ | yeah, the spinner is client side query | 12:23 |
| zyga_ | so... | 12:23 |
| ogra_ | ah, so you mean the reboot flag kicks in to early ? | 12:23 |
| zyga_ | no, I don't think it does | 12:23 |
| * zyga_ thinks | 12:23 | |
| zyga_ | so | 12:23 |
| zyga_ | it's just this | 12:23 |
| zyga_ | we set the flag | 12:23 |
| zyga_ | and ask the system to reboot | 12:23 |
| ogra_ | right | 12:24 |
| zyga_ | but the reboot is not instant, it will be a while before it happens | 12:24 |
| ogra_ | which obviously works as expected | 12:24 |
| zyga_ | then lots of time passes | 12:24 |
| zyga_ | and then we reboot | 12:24 |
| zyga_ | and then it works OK | 12:24 |
| zyga_ | but the UX is not making it clear what is going on | 12:24 |
| ogra_ | that message has been there before since day one ... but it always left me interacting with the tty ... now it doesnt anymore and the spinner goes on | 12:24 |
| zyga_ | ogra_: you can ctrl-c and exit | 12:25 |
| zyga_ | ogra_: but I suspect shutdown may set nologin | 12:25 |
| ogra_ | before the spinner stopped at some point | 12:25 |
| ogra_ | no, ctrl-c is ignored | 12:25 |
| zyga_ | ogra_: yes but there was a bug there (hence phase 2) | 12:25 |
| zyga_ | morphis: no luck with your repo | 12:26 |
| zyga_ | morphis: apt-get doesn't like it | 12:26 |
| ogra_ | i think before it acvtually printed the "[/] Setup snap "core" (1829) security profiles (phase 2)" ... finished it and only then the reboot message showed up | 12:26 |
| ogra_ | at least thats what i remember | 12:27 |
| ogra_ | now both are there at the same time and the "[/] Setup snap "core" (1829) security profiles (phase 2)" seems to hold the console access | 12:27 |
| morphis | zyga_: what does apt-get say? | 12:27 |
| morphis | it will most likely complain because if the unknown key | 12:27 |
| zyga_ | E: Failed to fetch https://mm.gravedo.de/raspbian/dists/jessie/InRelease | 12:28 |
| ogra_ | raspbian !? | 12:29 |
| morphis | zyga_: that file exists, can you give me the full output? | 12:29 |
| morphis | ogra_: yeah | 12:29 |
| zyga_ | morphis: there's nothing else reall | 12:31 |
| ogra_ | can that even run our armhf binaries ? | 12:31 |
| zyga_ | let me pastebin | 12:31 |
| zyga_ | http://pastebin.ubuntu.com/24498297/ | 12:31 |
| ogra_ | (given it is a re-compile of the whole archive for v6) | 12:31 |
| morphis | ogra_: these packages are rebuild for raspbian | 12:31 |
| ogra_ | ah, k | 12:31 |
| morphis | zyga_: there we go: E: The method driver /usr/lib/apt/methods/https could not be found. | 12:31 |
| morphis | zyga_: and it gives you the solution in the next line | 12:32 |
| ogra_ | apt-transport-https isnt a default in raspbian | 12:34 |
| ogra_ | ? | 12:34 |
| * ogra_ would expect it to be seeded in all deb based distros nowadays ... | 12:34 | |
| zyga_ | oh | 12:35 |
| zyga_ | sorry | 12:35 |
| morphis | ogra_: me too | 12:35 |
| ogra_ | 01 16:56:05 localhost.localdomain /usr/lib/snapd/snapd[897]: helpers.go:173: cannot connect plug "core-support" from snap "core", no such plug | 12:42 |
| ogra_ | May 01 16:56:05 localhost.localdomain /usr/lib/snapd/snapd[897]: helpers.go:173: cannot connect plug "network-bind" from snap "core", no such plug | 12:42 |
| ogra_ | hmm | 12:42 |
| ogra_ | i thought we fixed that one | 12:42 |
| niemeyer | Good days | 12:43 |
| niemeyer | The forum is going down and back up for a quick configuration change | 12:43 |
| * ogra_ wonders if his drafted answer will survive that :) | 12:44 | |
| niemeyer | ogra_: Yes, it saves while typing | 12:44 |
| ogra_ | ah, cool then | 12:44 |
| niemeyer | It's back up already | 12:46 |
| zyga_ | morphis: installing | 12:47 |
| ogra_ | niemeyer, and worked fine :) | 12:47 |
| zyga_ | morphis: installed :) | 12:51 |
| zyga_ | morphis: trying to install stuff | 12:51 |
| morphis | zyga_: good | 12:51 |
| zyga_ | morphis: well, it downloads core now | 12:51 |
| morphis | zyga_: hm | 12:51 |
| zyga_ | morphis: which is terrbile, we should print architecture that snapd knows about in "snap version" | 12:51 |
| ogra_ | zyga_, UH OH ! so hitting ctrl-c like 5 times actually gets me the console back .... it seems just inconsistent in accepting ctrl-c after all! | 12:51 |
| ogra_ | still though ... i did never need to actually hit ctrl-c at all before | 12:52 |
| morphis | zyga_: which architecture does the kernel report? | 12:52 |
| morphis | niemeyer: you have a minute to snapshot Spread-08 as a new fedora-25-64 image? | 12:53 |
| zyga_ | morphis: it runs the configure hook now | 12:56 |
| zyga_ | morphis: armv6l | 12:56 |
| zyga_ | morphis: core has installed! | 12:56 |
| niemeyer | morphis: Yeah | 12:56 |
| niemeyer | morphis: Is it ready? | 12:56 |
| Chipaca | zyga_— snapd prints its architecture on startup (not sure of the context) | 12:56 |
| zyga_ | Chipaca: thanks, so snapd on arm6l thinks it is arctually armhf | 12:57 |
| zyga_ | so it all misbehaves | 12:57 |
| Chipaca | well, we don't support arm6l inside snapd so ¯\_(ツ)_/¯ | 12:58 |
| morphis | niemeyer: it is, down to 1022M, the minimal size we can get to | 12:58 |
| Chipaca | are we doing a standup today? | 12:58 |
| ogra_ | well, and we dont really have any v6 in the archive ... so your build-deps will be armhf, your libc will be at build time etc etc | 12:58 |
| niemeyer | morphis: Okay, working on it | 12:58 |
| morphis | Chipaca, zyga_: we shouldn't then download the armhf snap on arm6l | 12:58 |
| morphis | niemeyer: thanks! | 12:59 |
| ogra_ | Chipaca, good question ... who is around ? you, zyga_, me and pstolowski ? | 12:59 |
| Chipaca | yeah | 12:59 |
| pstolowski | o/ | 12:59 |
| ogra_ | we could meet asnd rant about the guys in montreal ;) | 12:59 |
| Chipaca | and people not reviewing branches, also | 12:59 |
| zyga_ | morphis: runtime.GOARCH is "arm" | 12:59 |
| ogra_ | yeah | 13:00 |
| zyga_ | Chipaca: I'm in the room now | 13:00 |
| zyga_ | Chipaca: let's hang out for 5 min | 13:00 |
| morphis | zyga_: I see, that actually is our problem then .. | 13:01 |
| morphis | zyga_: what does /proc/cpuinfo give you on the pi1? | 13:01 |
| zyga_ | morphis: http://paste.debian.net/930351/ | 13:04 |
| morphis | zyga: uname -m reports arm6l? | 13:06 |
| zyga_ | yes | 13:06 |
| morphis | good | 13:06 |
| ralsina | Morning folks! I don't have access to my canonical account anymore since I don't work there anymore, but I can't use my preferred namespace "ralsina" for my new personal account. Is there any way to get it back? | 13:08 |
| niemeyer | morphis: All done.. please remember to test the update task in the spread-images project so we're able to update it easily in the future | 13:14 |
| morphis | niemeyer: thanks! | 13:15 |
| zyga_ | morphis: suggestion to use uname data to konw the real architecture | 13:21 |
| ogra_ | zyga_, note that an armhf kernel could drive a v6 userspace though | 13:21 |
| ogra_ | (technically ... not sure that is done anywhere) | 13:22 |
| zyga_ | ogra_: yeah perhaps, for now let's just close one big gap though | 13:22 |
| ogra_ | yeah, unlikely that you hit that in the real-world | 13:22 |
| ogra_ | hmm, well ... except probably in a raspbian chroot running on top of a debian installation ... | 13:24 |
| ogra_ | (for testing or building or some such) | 13:25 |
| mup | PR snapd#3260 opened: WIP: Implement --user instance for snapd <Created by morphis> <https://github.com/snapcore/snapd/pull/3260> | 13:37 |
| morphis | niemeyer, zyga_: time to review https://github.com/snapcore/snapd/pull/3222 again? | 13:53 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 13:53 |
| mup | PR snapd#3261 opened: snap-confine: init the ENTRY variable, coverity is unhappy otherwise <Created by mvo5> <https://github.com/snapcore/snapd/pull/3261> | 13:54 |
| === daniel is now known as Guest47234 | ||
| === Guest47234 is now known as Odd_Bloke | ||
| elopio | Facu: our fake servers in snapcraft turned into an ugly beast. We need at least an url router. Would it make sense to use flask? or maybe there's something lighter. | 14:29 |
| Facu | elopio, can't you route urls using something static? like apache? | 14:30 |
| dragly | I have an app that crashes with a segfault when run in a snap sandbox. Is there any way I can run gdb to debug this? | 14:32 |
| elopio | Facu: wouldn't it be worst to add apache as a dependency than flask? I want something like this, but it's not in xenial :( https://github.com/pretenders/pretenders | 14:36 |
| Facu | elopio, understand; to just re-route probably flask is even too big, maybe a smaller web framework would also do the job, like pyramid; but if you already are proficient with flask, go for it | 14:39 |
| pachulo | stupid question: what is the wdl-nextcloud snap for? | 14:42 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | pachulo, perhaps kyrofa knows ... i'd just go with the nextcloud snap from nextcloud | 14:44 |
| ogra_ | pachulo, i thinnk wdl means "western digital" and is tied to the netxcloud box | 14:45 |
| pachulo | ah, ok, that makes sense! Thanks ogra_ ! | 14:46 |
| elopio | Facu: I'll take a look at pyramid. Thanks. | 14:49 |
| daker | hi, does anyone know the state of mir-kiosk stuff(gui apps on ubuntu-core), is it still developed/maintained? | 14:52 |
| kyrofa | pachulo, ogra_: no idea. It doesn't seem to be available in the stable channel-- how did you find it? Last I heard the upstream nextcloud snap was still shipped on the nextcloud box | 14:52 |
| ogra_ | kyrofa, snap find nextcloud on a pi3 shows it to me | 14:52 |
| kyrofa | ogra_, ah, so armhf then | 14:52 |
| ogra_ | yeah | 14:52 |
| kyrofa | That always gets me :P | 14:52 |
| ogra_ | stop using dead arches, arm is the future! | 14:53 |
| ogra_ | ;) | 14:53 |
| kyrofa | ogra_ does all his development work on a pinebook | 14:54 |
| ogra_ | haha, not really :) | 14:55 |
| roadmr | jdstrand: hello! r875 of the tools is now in production | 14:57 |
| jdstrand | roadmr: that was fast. thanks! :) | 15:05 |
| jdstrand | roadmr: fyi, the review-tools fork of crt and its edge snap is not bad | 15:06 |
| jdstrand | roadmr: I'm not ready to say 'integrate this into the snapcraft.io store in lieu of crt', but I wouldn't mind feed back from people playing with it | 15:07 |
| jdstrand | feedback even | 15:07 |
| roadmr | nice! | 15:07 |
| zyga_ | jdstrand: hey | 15:13 |
| zyga_ | jdstrand: I'm working with a user that has xenial with 4.4 kernel and hits an apparmor denial for snap-confine | 15:14 |
| zyga_ | jdstrand: I'm quite puzzled by what's going on | 15:14 |
| jdstrand | what is the denial? | 15:14 |
| zyga_ | https://github.com/lxc/lxd/issues/3267 | 15:15 |
| zyga_ | jdstrand: a downgrade to 2.24 helps | 15:15 |
| zyga_ | until a reboot | 15:15 |
| zyga_ | when it is broken again | 15:15 |
| olive | Hi! | 15:16 |
| zyga_ | I did a diff of snap-confine in 2.24 and I don't see anything relevant | 15:16 |
| zyga_ | olive: hey! | 15:16 |
| zyga_ | jdstrand: olive here is affected by this issue | 15:16 |
| zyga_ | jdstrand: my quick idea is that snapd 2.24 doens't use snap-confine from core yet, i'm checking that now | 15:16 |
| zyga_ | jdstrand: the actual denial though is very odd; IMO it is allowed by the profile | 15:16 |
| zyga_ | [11120.777073] audit: type=1400 audit(1493729112.057:3410): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/var/lib/lxd/" pid=31726 comm="snap-confine" srcname="/var/snap/lxd/common/lxd/" flags="rw, rbind" | 15:17 |
| zyga_ | this is one denial | 15:17 |
| zyga_ | (actually this one feels wrong, I saw a different one earlier) | 15:17 |
| zyga_ | and this one is also something unexpected | 15:17 |
| zyga_ | olive: is there anything in /var/lib/snapd/mount/snap.lxd.fstab | 15:18 |
| jdstrand | zyga_: there is no rule for that in 2.25 | 15:18 |
| jdstrand | mount options=(rw rbind nodev nosuid noexec) /var/lib/snapd/hostfs/var/lib/lxd/ -> /var/lib/lxd/, | 15:18 |
| zyga_ | jdstrand: right, I saw a different denial earlier that matched this rule you just pasted | 15:18 |
| jdstrand | the srcname in the denial is /var/snap/lxd/common/lxd/ | 15:18 |
| zyga_ | (saw == on irc) | 15:18 |
| olive | zyga_: not better after reboot | 15:19 |
| zyga_ | olive: ok, thank you for checking | 15:19 |
| olive | snapd 2.25 | 15:19 |
| zyga_ | jdstrand: so olive here is on 2.25 with no snap-confine installed (I was worried because there was a .dpkg-bak file in /etc/apparmor.d/) | 15:20 |
| olive | /var/lib/snapd/mount/snap.lxd.fstab: No such file or directory | 15:20 |
| * zyga_ is puzzled | 15:20 | |
| zyga_ | ok | 15:20 |
| zyga_ | olive: can you do this please: | 15:20 |
| zyga_ | export SNAP_CONFINE_DEBUG=yes | 15:20 |
| zyga_ | and then start lxd if you can | 15:20 |
| zyga_ | though | 15:20 |
| zyga_ | you can run anything else | 15:21 |
| zyga_ | even hello-world snap | 15:21 |
| zyga_ | as the denial should be generic | 15:21 |
| olive | http://paste.ubuntu.com/24499042/ | 15:22 |
| jdstrand | zyga_: it seems snap-confine is doing something wrong. why is it trying to use /var/snap/lxd/common/lxd/ as the srcname instead of /var/lib/snapd/hostfs/var/lib/lxd? | 15:23 |
| zyga_ | jdstrand: no idea yet | 15:23 |
| zyga_ | jdstrand: but very fishy | 15:24 |
| zyga_ | olive: great, can you couple that with 'dmesg | grep DENIED' | 15:24 |
| zyga_ | olive: get the last lines | 15:24 |
| zyga_ | olive: it should be just one, paste it here directlyu | 15:24 |
| jdstrand | /var/snap/lxd/common/lxd/ is for the lxd snap. /var/lib/snapd/hostfs/var/lib/lxd is the core snap. it seems to be picking the wrong thing | 15:24 |
| olive | [ 384.578585] audit: type=1400 audit(1493738612.509:148): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/var/lib/lxd/" pid=7625 comm="snap-confine" srcname="/var/snap/lxd/common/lxd/" flags="rw, rbind" | 15:24 |
| olive | [ 384.690504] audit: type=1400 audit(1493738612.621:149): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/var/lib/lxd/" pid=7631 comm="snap-confine" srcname="/var/snap/lxd/common/lxd/" flags="rw, rbind" | 15:24 |
| zyga_ | jdstrand: note that snap-confine debug log doens't mention anything related to lxd common at all | 15:25 |
| * zyga_ looks at the source | 15:25 | |
| jdstrand | olive: does /var/lib/snapd/hostfs/var/lib/lxd exist? is it a symlink? | 15:26 |
| zyga_ | jdstrand: that mount has hard-coded arguments, I doubt we're doing anything worng | 15:26 |
| zyga_ | jdstrand: note, hostfs is just inside snaps | 15:26 |
| zyga_ | olive: can you please `ls -ld /var/lib/lxd` | 15:26 |
| zyga_ | jdstrand: a symlink the is likely the cause | 15:26 |
| roadmr | jdstrand: sorry was otp! oh so review-tools? you say it's a fork? where does that live? | 15:27 |
| olive | ls: cannot access '/var/lib/snapd/hostfs/var/lib/lxd': No such file or directory | 15:27 |
| olive | # ls -ld /var/lib/lxd | 15:27 |
| olive | lrwxrwxrwx 1 root root 25 Feb 1 22:45 /var/lib/lxd -> /var/snap/lxd/common/lxd/ | 15:27 |
| zyga_ | aha | 15:27 |
| zyga_ | olive: perfect | 15:27 |
| zyga_ | olive: so two questions | 15:27 |
| zyga_ | olive: did you do that manually? | 15:27 |
| olive | no. | 15:28 |
| jdstrand | zyga_: 'hostfs is just inside snaps'. huh? it has to exist at whatever point snap-confine is running to mount it. I guess you mean within its mount namespace | 15:28 |
| zyga_ | olive: and did it really work before? | 15:28 |
| olive | yes :) | 15:28 |
| jdstrand | roadmr: https://launchpad.net/review-tools | 15:28 |
| ogra_ | hahaha | 15:28 |
| zyga_ | jdstrand: yes, I mean that the hostfs directory as you specified it is always empty from a typical unconfined shell | 15:28 |
| * ogra_ looks forward to jdstrand's answer in https://forum.snapcraft.io/t/startx-as-a-regular-user/460 | 15:28 | |
| zyga_ | olive: so that symlink won't work unfortunately, let me think about it for a sec | 15:29 |
| ogra_ | (i think the user asked here before and was toold "no Xorg on UbuntuCore" ... but seems he tried anyway (or it is another person) | 15:29 |
| zyga_ | olive: is that directory empty? | 15:29 |
| zyga_ | olive: I mean /var/lib/lxd | 15:29 |
| olive | yes, just this symlink | 15:30 |
| olive | oh.wait. | 15:30 |
| zyga_ | olive: right, but if you follow the symlink, is /var/snap/lxd/common/lxd empty? | 15:30 |
| olive | when I cd /var/lib/lxd and ls... it is not empty. o_O | 15:30 |
| zyga_ | stgraber: ^^ is that symlink anything you are familiar with? (symlink from /var/lib/lxd -> /var/snap/lxd/common/lxd) | 15:31 |
| zyga_ | olive: ok, as a quick work-around do this: | 15:31 |
| olive | ok sorry, I'm tired, of course, it is a symlink... :( | 15:31 |
| stgraber | zyga_: nope | 15:31 |
| stgraber | zyga_: not something we do or would ever recommend someone do | 15:31 |
| olive | zyga_: http://paste.ubuntu.com/24499072/ | 15:32 |
| stgraber | zyga_: folks should just "export LXD_DIR=/var/lib/snap/common/lxd/" if they want tools outside of the snap talking to the snap LXD | 15:32 |
| jdstrand | it isn't something that would be allowed by the profile anyway | 15:33 |
| zyga_ | olive: can you try stgraber's advice, remove that symlink please | 15:33 |
| olive | I promise you that I have not tweaked myself. I only followed the stgrabber article;) | 15:33 |
| jdstrand | ie, the snap couldn't create that symlink | 15:33 |
| zyga_ | jdstrand: I'll patch snap-confine to be smarter | 15:33 |
| zyga_ | jdstrand: it should not belly-up fail on that | 15:34 |
| zyga_ | I wonder if we could kill the LXD quirk now | 15:34 |
| jdstrand | the lxd snap would have to (ab)use its lxd-support interface to load and/or change to a profile that allowed that write and perform the symlink | 15:34 |
| stgraber | jdstrand: the lxd snap never uses /var/lib/lxd | 15:34 |
| jdstrand | stgraber: right, not saying you are doing that. saying you'd know if you did cause you'd have to go through hoops | 15:35 |
| olive | I remove the /var/lib/lxd link ? | 15:35 |
| stgraber | olive: yeah | 15:35 |
| zyga_ | olive: yes, please | 15:35 |
| jdstrand | olive: curious, did you ever try to run lxd inside of a container launched from the lxd snap? | 15:36 |
| stgraber | jdstrand: I'm pretty sure this bind-mount was added for the juju, conjure-up or similar snaps that wanted to talk to the host LXD | 15:36 |
| zyga_ | stgraber: ah, perhaps that is it | 15:36 |
| olive | ok now snapd is running Active: active (running) since Tue 2017-05-02 17:35:10 CEST; 5s ago | 15:36 |
| olive | jdstrand: I don't think so | 15:36 |
| * jdstrand is wondering if a container was given write access to the host's filesystem and then did that | 15:36 | |
| jdstrand | olive: did you use juju or conjure-up like stgraber said? | 15:37 |
| zyga_ | jdstrand: note that 2.25 has reassociate fix, maybe what is going on is that snap-confine breaks out of the container? | 15:37 |
| zyga_ | jdstrand: though I bet lxd uses process namespace | 15:37 |
| zyga_ | jdstrand: so probably not that | 15:37 |
| olive | never tried juju in the server. | 15:37 |
| olive | in this* server | 15:37 |
| jdstrand | zyga_: it might be the reassociate stuff | 15:37 |
| olive | conjure-up either | 15:38 |
| jdstrand | I think making snapd more robust in the face of this is a fine fix, but the root cause needs to be found | 15:38 |
| * jdstrand notes he also uses the lxd snap, is on 17.04 with snapd 2.25 and does not have this issue | 15:39 | |
| morphis | zyga_: thanks for the comment, completely forgot to mention that | 15:40 |
| olive | thank you everybody. specially zyga_ and stgraber :) | 15:41 |
| olive | and jdstrand | 15:41 |
| olive | (and sabdfl) | 15:41 |
| zyga_ | jdstrand: trying to reason about this, I don't think is could be the reassociate fix, after all, it should not change anything in this case; | 15:42 |
| zyga_ | olive: you are welcome! | 15:42 |
| zyga_ | stgraber: all lxd containers use the PID namespace, right? | 15:42 |
| zyga_ | jdstrand: and in the pastebin from SNAP_CONFINE_DEBUG log above we see: DEBUG: re-associating is not required | 15:44 |
| jdstrand | something created that symlink | 15:46 |
| jdstrand | the only thing I can think of is a container that had /var(/...) mounted inside | 15:47 |
| jdstrand | and then it did it | 15:47 |
| jdstrand | or as stgraber said, some tool trying to be smart and getting something wrong (but those tools weren't run) | 15:48 |
| dragly | Found a way to get gdb running. Is there any reason why QFontDatabase::findFont should segfault when calling into libQt5XcbQpa? | 15:49 |
| dragly | For instance a plug that should give access to fonts? | 15:50 |
| ogra_ | shouldnt the desktop-qt part provide that ? | 15:51 |
| zyga_ | jdstrand: I think that we don't bind mount all of /var, right? | 15:51 |
| zyga_ | jdstrand: so that cannot be done from inside a snap | 15:52 |
| zyga_ | dragly: no, sorry :/ | 15:52 |
| zyga_ | dragly: there are no fonts in the core snap | 15:52 |
| ogra_ | why would there | 15:52 |
| zyga_ | dragly: and host fonts are not accessible | 15:52 |
| ogra_ | the snapcraft desktop parts install fonts inside the snap | 15:52 |
| ogra_ | that should just work, provded you used the right part in your snapcraft.yaml | 15:53 |
| zyga_ | ogra_: we wanted to offer sharing of classic fonts | 15:53 |
| zyga_ | ogra_: e.g. run your favourite editor with locally-installed font | 15:53 |
| ogra_ | zyga_, right, i'm talking about today | 15:53 |
| * zyga_ nods | 15:54 | |
| ogra_ | there definitely no reason for the above error if you include the right bits | 15:54 |
| ogra_ | dragly, https://github.com/ubuntu/snappy-playpen/blob/master/qcomicbook/snapcraft.yaml as an example | 15:56 |
| ogra_ | (see the "after: [desktop-qt5]" there) | 15:57 |
| jdstrand | zyga_: lxd is in a position to do its own reassociate. not saying it does, it just can. I'm grasping at how it could have happened | 15:58 |
| zyga_ | jdstrand: aha, that's true | 16:00 |
| zyga_ | jdstrand: still I don't think it is reassociate that was re-enabled that is at fault here | 16:00 |
| dragly | ogra_: thanks. I'm using a custom Qt install, but it might help to install the default Qt packages and use those to have all the necessary pieces set up and ready. I'll look up what after does. | 16:05 |
| mup | PR snapd#3262 opened: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <https://github.com/snapcore/snapd/pull/3262> | 16:18 |
| zyga_ | morphis: hey | 16:26 |
| morphis | zyga_: hey! | 16:26 |
| zyga_ | morphis: do you have a working qmeu image I can use for debian? | 16:26 |
| zyga_ | morphis: I'm still debugging https://github.com/snapcore/snapd/pull/3259 | 16:26 |
| mup | PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259> | 16:26 |
| zyga_ | morphis: I think there's a deeper problem there | 16:26 |
| zyga_ | morphis: I can work on linode but I'd prefer a local image | 16:26 |
| morphis | zyga_: was looking into that too but it looks to me like those failing bits are not coming from the debian part .. | 16:27 |
| jdstrand | zyga_: I suspect we need to keep an eye on this. there is no reproducer and other lxd snap users are not complaining. if/when they do, we can request a reproducer/etc | 16:27 |
| morphis | zyga_: but let me check if I have my dirty script to create a debian qemu image still, didn't had time to clean them up yet | 16:29 |
| zyga_ | morphis: much appreciated! | 16:31 |
| morphis | zyga_: take http://saimei.ftp.acc.umu.se/cdimage/openstack/testing/debian-testing-openstack-amd64.qcow2 and use https://gist.github.com/morphis/1e181e60b3803f8a72952c580fad9a21 | 16:31 |
| morphis | zyga_: $ ./adt-buildvm-ubuntu-cloud -r sid --image=$PWD/debian-testing-openstack-amd64.qcow2 --verbose | 16:31 |
| morphis | zyga_: save the gist as adt-buildvm-ubuntu-cloud | 16:32 |
| zyga_ | thanks | 16:32 |
| morphis | zyga_: the script is a hacked variant of the ubuntu variant | 16:32 |
| morphis | but should give you an image with debian:debian to login | 16:33 |
| zyga_ | morphis: I have it, thank you! | 16:35 |
| morphis | zyga_: however it looks more like the tests are a bit racy | 16:39 |
| morphis | linode:ubuntu-16.04-32:tests/main/interfaces-openvswitch is the one which fails now | 16:39 |
| dragly | I am getting a "No such file or directory: [...]/parts/qml/install/etc/xdg/qtchooser/snappy-qt5.conf" when using desktop-qt5 | 16:46 |
| zyga_ | morphis: gee, that iso image clones forever | 16:52 |
| zyga_ | wgets | 16:52 |
| zyga_ | I get modem speeds on it | 16:53 |
| morphis | zyga: https://cdimage.debian.org/cdimage/openstack/ | 16:53 |
| morphis | try a different mirror thne | 16:53 |
| zyga_ | thnx | 16:53 |
| === JanC is now known as Guest15747 | ||
| diddledan | is there a way of telling `snapcraft cleanbuild` to use a different release of ubuntu for a local build? I think I need to use a more-recent version than 16.04 for some of my build dependencies to be satisfied | 17:23 |
| diddledan | specifically I need a more recent vala than 0.34.0: checking whether /usr/bin/valac is at least version 0.34.0... no | 17:24 |
| qengho | diddledan: No. Instead, make "vala" a separate part. Compile your compiler. | 17:42 |
| morphis | zyga_: you found anything? | 17:43 |
| morphis | zyga_: looks like all tests for https://github.com/snapcore/snapd/pull/3259 passed now | 17:43 |
| mup | PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259> | 17:43 |
| zyga | morphis: still downloading the image, currently at 25% | 17:43 |
| morphis | zyga_: even on another mirror? | 17:43 |
| zyga | yes, maybe something elsewhere on the network | 17:44 |
| zyga | morphis: mvo just said he's looking too | 17:44 |
| morphis | zyga: ok | 17:58 |
| zyga_ | jdstrand: is my explanation in https://github.com/snapcore/snapd/pull/3252 sufficient? | 18:00 |
| mup | PR snapd#3252: tests,cmd/snap-confine: port older snapd-discard-ns tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3252> | 18:00 |
| cratliff | I'm going through the running nodejs as a service demo and am running into this issue. https://github.com/canonical-websites/tutorials.ubuntu.com/issues/70 does anyone have a workaround other than to run services in devmode? I'm wanting to convert some code that's using systemd to snaps and it doesn't seem like it will work right now. | 18:21 |
| zyga_ | cratliff: can you just build it entirely, not with snap try | 18:26 |
| zyga_ | cratliff: whatever the issue it will likely function correctly then | 18:26 |
| zyga_ | cratliff: I suspect you are on encrypted home folder or something else | 18:26 |
| zyga_ | cratliff: can you tell me where the [...] part that you removed in the issue was pointing to? | 18:26 |
| zyga_ | it finally downloaded | 18:29 |
| * zyga_ debugs debian | 18:29 | |
| cratliff | Sorry, I'm not aware of removing anything, I'm not sure what you are referring to. I've not attempted to build it without try yet, let me see. | 18:29 |
| zyga_ | aha | 18:33 |
| zyga_ | cratliff: sorry, I assumed you were reported of the issue there | 18:33 |
| zyga_ | cratliff: just build the snap and install it | 18:33 |
| zyga_ | cratliff: as for snap-try, there are still some issues | 18:33 |
| mup | PR snapcraft#1294 opened: plugin: Add plugin for meson build system <Created by JulianLiu> <https://github.com/snapcore/snapcraft/pull/1294> | 18:33 |
| zyga_ | I think I just figured out a simple way to handle it actually | 18:34 |
| cratliff | I installed the server with --dangerous, not --devmode. It is working, since I used dangerous it should show that it is running without issue contained, right? | 18:39 |
| zyga_ | cratliff: not sure really, does snap list say it is devmode? | 18:40 |
| cratliff | no, it does not. | 18:40 |
| zyga_ | cratliff: great, then you are good :) | 18:41 |
| cratliff | cool, thanks for the help. | 18:41 |
| zyga_ | cratliff: good luck | 18:44 |
| zyga_ | finally | 18:56 |
| zyga_ | geez | 18:56 |
| zyga_ | forever | 18:56 |
| mup | PR snapd#3263 opened: snap: make `snap prepare-image --extra-snaps` derive side info <Created by mvo5> <https://github.com/snapcore/snapd/pull/3263> | 19:04 |
| zyga_ | and it doesn't boot :/ | 19:06 |
| zyga_ | I think I will resort to regular debian image to deubg this | 19:06 |
| mup | PR snapd#3241 closed: snap: make `snap prepare-image` read .assert files for local snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3241> | 19:06 |
| zyga_ | ok, so it gets to login prompt | 19:08 |
| zyga_ | but debian/debian doesn't work | 19:08 |
| * zyga_ looks at the script again | 19:08 | |
| === alvaro is now known as fede2 | ||
| diddledan | how do I tell snapcraft to keep the lxc container using cleanbuild when the build fails so that I can try to figure out why I'm getting a permission denied error when running an autotools build when it tries to execute ./configure | 21:44 |
| diddledan | ignore that, I'm gonna do it a different way - run an lxc container manually and call snapcraft directly within that without using cleanbuild | 21:49 |
| diddledan | ok, so it only dies in cleanbuild :-/ | 21:53 |
| === alvaro is now known as fede2 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!