| === chihchun_afk is now known as chihchun | ||
| === JanC is now known as Guest16348 | ||
| === JanC_ is now known as JanC | ||
| tvoss | good morning | 06:16 |
|---|---|---|
| morphis | tvoss: morning! | 06:23 |
| tvoss | o/ | 06:23 |
| tvoss | @pedronis happy new week :) would be great if you would find some time for https://github.com/snapcore/snapd/pull/3130 | 06:23 |
| nothal | tvoss: No such command! | 06:23 |
| mup | PR snapd#3130: overlord/devicestate: switch to keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130> | 06:23 |
| Mirv | thresh: ah, good that it's reported. I believe it may require some snapcraft changes to be able to properly bypass the problem, like having conditional packages. | 06:51 |
| stub | /usr/lib/snapd/snap-confine: error while loading shared libraries: libudev.so.1: failed to map segment from shared object | 06:51 |
| stub | ^^ anyone know what is going on there? | 06:51 |
| stub | Inside a xenial lxd container, hosted under xenial | 06:52 |
| stub | Its a classic snap, so it should certainly be able to access stuff. And the same snap was working two weeks ago. | 07:02 |
| mup | Bug #1681328 opened: classic snap now failing with udev errors <Snappy:New> <https://launchpad.net/bugs/1681328> | 07:10 |
| seb128 | morning distro | 07:11 |
| zyga | good morning seb128 | 07:16 |
| seb128 | hey zyga ;-) | 07:16 |
| seb128 | distro->snappy (in fact I was typing on another channel, don't do that when xchat-gnome loads, it moves focus to newly joined channel as it does) | 07:17 |
| zyga | hey ara | 07:23 |
| ara | hey zyga | 07:23 |
| tvoss | zyga: good morning. I'm seeing a test failure for main/static, with the test complaining about CGO being unexpected for overlord/devicestate. where would I need to adjust the build/test setup to change that expectation? | 07:51 |
| zyga | tvoss: good morning | 07:55 |
| zyga | tvoss: not sure I understand, can you please post a log? | 07:56 |
| zyga | mvo: good morning | 07:57 |
| tvoss | zyga: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170410_072000_9284e@/log.gz | 07:58 |
| mvo | hey zyga | 07:59 |
| zyga | tvoss: hmmm | 08:00 |
| zyga | tvoss: I honestly don't know | 08:01 |
| tvoss | zyga: okay, the test checks that snapd can be built without cgo. that's certainly not true anymore :) | 08:03 |
| zyga | tvoss: ah, I just had a look at the test | 08:03 |
| zyga | tvoss: yes, feels like something that should be removed now | 08:04 |
| tvoss | zyga: okay, let me remove it and see what the infrastructure thinks | 08:04 |
| pedronis | tvoss: I will look | 08:05 |
| tvoss | pedronis: thx | 08:07 |
| morphis | Son_Goku, zyga: looks like all packages are published now | 08:19 |
| zyga | morphis: nice, I had issues with f26 installation on Friday but I will give it a test as well and commit the changes to ship tab completion | 08:36 |
| morphis | zyga: what kind of issues? | 08:36 |
| zyga | morphis: with f26 installer, not with snaps | 08:36 |
| morphis | ah | 08:36 |
| zyga | morphis: not sure, it would freeze; I rebooted a few times before it finished | 08:36 |
| morphis | Son_Goku: you want to blog about this today? | 08:36 |
| mvo | Chipaca: hey, good morning! I had a look at the hashsum issues this morning because quite a few of the current branches fail with it - I suspect we just don't handle an EOF during download not correctly, i.e. we do not set the right resume point. I think somehting like http://paste.ubuntu.com/24353432/ help - what do you think? is that something you invesitgated yet? | 08:36 |
| morphis | zyga: if I remember well I had problems last week too with F26 | 08:37 |
| mvo | Chipaca: i.e. I hope I did not duplicate some reaseach :/ | 08:37 |
| Chipaca | mvo— heh. I was just starting with this. | 08:37 |
| zyga | mvo: nice! | 08:37 |
| Chipaca | mvo— that does seem correct to me :-) | 08:38 |
| mvo | Chipaca: it needs a test to be certain but I don't see that we handle the seeking but maybe I'm wrong | 08:38 |
| Chipaca | mvo— we do a SEEK_END i think | 08:38 |
| mvo | Chipaca: yeah, I think the problem is that we don't do the hashsum update, its some lines above. without a test just a theory for now | 08:39 |
| mvo | Chipaca: whats funny is that all the hash errors are the same, wonder if there is a too-short file on some of the cdn server somewhere | 08:40 |
| Chipaca | mvo— oh? | 08:40 |
| * zyga eats breakfast, sorry for not coding yet, I was checking email all morning | 08:42 | |
| mvo | Chipaca: e.g. https://github.com/snapcore/snapd/pull/2833#issuecomment-292874676 matches the one in https://forum.snapcraft.io/t/hashsum-failures-during-tests/198 | 08:43 |
| mup | PR snapd#2833: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833> | 08:43 |
| Chipaca | mvo— maybe it's the hash of "503 Go away I'm Comfy" | 08:47 |
| mvo | Chipaca: haha, possible | 08:48 |
| mvo | Chipaca: I'm writing a test, lets see how that goes | 08:49 |
| davmor2 | Chipaca: no more like Oh not you again, what do you want now? | 08:50 |
| morphis | mvo, zyga: if I define in my spread.yaml a new system debian-9-64 is spread/linode able to spawn up a machine with the right image just with this automatically or do we need someone adding an image on the Linode setup itself? | 08:54 |
| mvo | morphis: you will need niemeyer to create this machine for you AFAIK | 08:55 |
| morphis | mvo: ok | 08:55 |
| zyga | mvo: I'm not so sure, with our credentials we can spawn any machine | 08:58 |
| zyga | morphis: just try it | 08:58 |
| mvo | zyga: nice! I was not aware of that | 08:59 |
| morphis | zyga: lets see .. | 09:00 |
| morphis | zyga, mvo: https://github.com/snapcore/snapd/pull/3156 | 09:01 |
| mup | PR snapd#3156: WIP: debian support for spread testing <Created by morphis> <https://github.com/snapcore/snapd/pull/3156> | 09:01 |
| mup | PR snapd#3156 opened: WIP: debian support for spread testing <Created by morphis> <https://github.com/snapcore/snapd/pull/3156> | 09:02 |
| zyga | morphis: do you know you can try it locally? | 09:03 |
| zyga | morphis: with spread linode:... | 09:03 |
| morphis | zyga: if I would have an API token, yes | 09:03 |
| morphis | zyga: need to ask niemeyer for one | 09:03 |
| zyga | morphis: ah, definitely | 09:03 |
| morphis | qemu sucks for these things | 09:03 |
| zyga | morphis: s/qemu/network at home/ | 09:04 |
| morphis | yeah both | 09:05 |
| morphis | mvo, zyga: 2017-04-10 09:04:12 Allocating linode:debian-9-64... | 09:05 |
| morphis | looks like its working | 09:05 |
| zyga | morphis: I don't think qemu is any worse than linode | 09:05 |
| mvo | morphis: nice | 09:06 |
| morphis | ah no | 09:06 |
| morphis | 2017-04-10 09:04:24 Cannot allocate linode:debian-9-64: no Linode image or distribution for "debian-9-64" | 09:06 |
| zyga | morphis: quick idea: add internal snap command like `is-confined` or `is-forced-devmode` or something like that | 09:10 |
| zyga | morphis: and use that in spread tests to skip confinement parts | 09:10 |
| morphis | zyga: yeah I was thinking about the same | 09:10 |
| zyga | morphis: this way we don't have to maintain the exclusion lists | 09:10 |
| zyga | morphis: and we can really test a lot of useful functionality at the same time (only parts of each test would be skipped) | 09:11 |
| mup | PR snapd#3152 closed: store: make hash error message more accurate <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3152> | 09:11 |
| zyga | morphis: I think you got the ID of the system wrong, drop the kernel line and give me a sec, I'll give you the right ID | 09:11 |
| morphis | zyga: followed what is described on https://github.com/snapcore/spread | 09:12 |
| tvoss | zyga: would you mind restarting the travis run for https://github.com/snapcore/snapd/pull/3130 | 09:13 |
| mup | PR snapd#3130: overlord/devicestate: switch to lib(open)ssl for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130> | 09:13 |
| tvoss | zyga: timedout | 09:13 |
| zyga | morphis: there's no `debian-9-64`, you can do `debian-8` (sans -64) | 09:15 |
| morphis | zyga: were we do not support debian-8 | 09:16 |
| morphis | however worth a try | 09:16 |
| zyga | morphis: yeah, I'm just telling you that's what is supported on linode now :/ | 09:17 |
| morphis | yeah, we may have to do our own debian-9 image | 09:18 |
| morphis | same for fedora 24 and 26 | 09:18 |
| zyga | morphis: fedora 24 is available AFAIR | 09:18 |
| zyga | morphis: but yeah, | 09:18 |
| morphis | https://www.linode.com/distributions doesn't have f24 | 09:19 |
| morphis | maybe there is an outdated image still and not listed there | 09:19 |
| zyga | morphis: https://blog.linode.com/2016/06/22/introducing-fedora-24/ | 09:20 |
| zyga | I think the distributions page is outdated | 09:20 |
| zyga | morphis: maybe we could reach out to linode and ask | 09:20 |
| zyga | morphis: e.g. add a debian-9 image, fedora-25 image | 09:20 |
| zyga | morphis: maybe they will refuse | 09:20 |
| zyga | morphis: but maybe it's cheap for them and they will just do it | 09:21 |
| morphis | zyga: just checked, they have on for f24 but listed under "old" | 09:21 |
| morphis | zyga: you can easily do your own images on linode | 09:22 |
| morphis | so linode doesn't have to care at all | 09:22 |
| zyga | morphis: it's easier if someone else cares :) | 09:23 |
| zyga | morphis: but I think we will need our images anyway | 09:23 |
| morphis | zyga: it is :-) | 09:23 |
| Chipaca | mvo— you wouldn't happen to have the whole journalctl output of one of those hashing failures would you? | 09:32 |
| mvo | Chipaca: of course | 09:33 |
| mvo | Chipaca: https://travis-ci.org/snapcore/snapd/builds/219559725#L1320 | 09:34 |
| mvo | Chipaca: and https://travis-ci.org/snapcore/snapd/builds/219416996#L994 | 09:34 |
| Chipaca | cheers | 09:34 |
| mvo | Chipaca: I struggle a bit with the test, I can get a test working but I need to send enough data that the first batch of data is commited to disk so that we trigger the rety. when I do that I get a strange errTrailerEOF error when I cut the connection in the middle (might be a new go 1.7 thing, I'm on zesty :/) | 09:35 |
| Chipaca | mvo— how're you injecting the failure? | 09:36 |
| mvo | Chipaca: http://paste.ubuntu.com/24353606/ is the test with a small amount of data, the amount is too small to get flushed to the local tempfile so when I check what position we are in our temp file I still get "zero" | 09:38 |
| mvo | Chipaca: i..e I use a full mock server and close the client connections (trying to be close to the real problem) | 09:38 |
| Chipaca | mvo— what's missing there is that you're not setting the ContentLength, you're letting go do that | 09:44 |
| mvo | Chipaca: I tried that too, but maybe not hard enough - let me do that again | 09:44 |
| mvo | Chipaca: hm, making progress with the test now (yay) but look like the resume case is actually handled down below, so its not that | 09:52 |
| Chipaca | mvo— i think it properly is the cdn returning some error page instead of the content | 09:54 |
| Chipaca | but I'm not sure | 09:54 |
| Chipaca | mvo— do we check the response status before hashing? | 09:54 |
| mvo | Chipaca: yeah, actually I think you are right, its probably something like "range-requests are not supported" | 09:54 |
| pedronis | that should be some 4xx though? | 09:56 |
| pedronis | are we really not checking error codes? | 09:56 |
| Chipaca | hence my question about whether we check the status before just hashing | 09:56 |
| Chipaca | :-) | 09:56 |
| pedronis | tvoss: done | 09:57 |
| Chipaca | i'm afraid we've made the download code too smart | 09:57 |
| pedronis | heh | 09:57 |
| zyga | re | 09:58 |
| * zyga is grumpy today, woke up at 5:00 AM | 09:58 | |
| zyga | why I know? | 09:59 |
| zyga | because modem company resets modems at 5AM | 09:59 |
| mup | PR snapd#3157 opened: store: add more logs around retry in download <Created by mvo5> <https://github.com/snapcore/snapd/pull/3157> | 09:59 |
| zyga | and the relay clicking woke me up for some reason | 09:59 |
| mup | PR snapd#3158 opened: store: add download test with EOF in the middle <Created by mvo5> <https://github.com/snapcore/snapd/pull/3158> | 10:11 |
| mvo | Chipaca: my theory is wrong, I think our code is fine. unless I miss someting in -^ | 10:11 |
| tvoss | pedronis: thx | 10:15 |
| pstolowski | mvo, thank you very much for this test! btw, just in the meantime there was a comment on this bug: https://bugs.launchpad.net/snapd/+bug/1677557 | 10:31 |
| mup | Bug #1677557: EOF not properly retried under some circumstances <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1677557> | 10:31 |
| pstolowski | mvo, I'm going to look at provoking 'unexpected eof' in the test and retrying it | 10:31 |
| zyga | mvo: can you have a look at https://github.com/snapcore/snapd/pull/3154 | 10:32 |
| mup | PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154> | 10:32 |
| mvo | pstolowski: wait a sec | 10:32 |
| mvo | pstolowski: there is a new ranch comming | 10:32 |
| mvo | branch | 10:32 |
| zyga | mvo: I'm trying to come up with a fix for the clashing plugs, as you know | 10:32 |
| zyga | mvo: I was thinking about spitting this branch so that connections are in separate PR | 10:32 |
| pstolowski | mvo, sure... not going to look at this today, maybe tommorrow-ish | 10:32 |
| zyga | mvo: as it may not land in the end | 10:32 |
| zyga | (specifically this one https://github.com/snapcore/snapd/pull/3154/commits/a69290f0c7836738c41da6f87f859e2971576630 ) | 10:33 |
| mup | PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154> | 10:33 |
| mup | PR snapd#3159 opened: store: retry once on hashsum mismatches in a Download() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3159> | 10:39 |
| mvo | pstolowski: -^ | 10:40 |
| mvo | pstolowski: but I think the EOF case in download() is hanlded, no? the test at least indicates it is | 10:40 |
| mvo | pstolowski: or is EOF and unprovoced eof different? | 10:40 |
| mvo | zyga: sure, I have a look after lunch, I was under the impression you are discussing this with gustavo still, what the best fix is. or is there agreement? | 10:41 |
| zyga | mvo: gustavo discussed if the fixup function should be public or private so I made it private at his request | 10:42 |
| zyga | mvo: as for my feeling on how this should be fixed, we can do it without touching state at all if we pull out the patch I referenced above | 10:42 |
| mup | PR snapd#3160 opened: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160> | 10:57 |
| zyga | Chipaca: hey, I'm seeing this timeout in completiontest | 11:00 |
| zyga | Chipaca: is this something expected of all expect-based tests? | 11:00 |
| zyga | Chipaca: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170406_130441_94744@/log.gz | 11:00 |
| Chipaca | zyga— | 11:01 |
| Chipaca | no | 11:01 |
| Chipaca | wtf | 11:01 |
| Chipaca | zyga— how does a telephone get in there | 11:02 |
| zyga | ???? | 11:02 |
| zyga | wat? | 11:02 |
| Chipaca | snap buy | 11:02 |
| Chipaca | hah | 11:02 |
| Chipaca | maybe it's my browser being silly | 11:02 |
| zyga | browsers are like humans | 11:03 |
| Chipaca | zyga— there's a real bug somewhere | 11:03 |
| zyga | we see faces in ascii, browsers see calendar events and phone numbers | 11:03 |
| Chipaca | zyga— expect times out when it fails to match something | 11:03 |
| Chipaca | so all epect errors are timeouts | 11:03 |
| Chipaca | you need to look at the output to determine what didn't match | 11:03 |
| Chipaca | zyga— that's the same error | 11:04 |
| Chipaca | zyga— that test is checking that "snap buy " tab-completes with purchasable snaps | 11:04 |
| Chipaca | zyga— and it's not | 11:05 |
| * zyga reads the output carefuly | 11:05 | |
| zyga | aha | 11:05 |
| Chipaca | zyga— so somehting's broken (probably something changed in the store?) | 11:05 |
| zyga | so is that a store bug, snapd bog? | 11:05 |
| zyga | Chipaca: can we log from tab completion handlers | 11:05 |
| zyga | Chipaca: adding a debug section that collects such logs could be useful | 11:05 |
| Chipaca | zyga— the snapd-side of completion looks just like a regular search | 11:06 |
| Chipaca | zyga— and that will be in the journalctl output | 11:06 |
| zyga | Chipaca: aha, perfect, let me read the debug section then | 11:06 |
| zyga | : DEBUG: Retrying https://search.apps.ubuntu.com/api/v1/snaps/details ... | 11:07 |
| zyga | maybe it is just another EOF | 11:07 |
| zyga | finished after 1 retries, elapsed time=136.412205ms, status: 200 | 11:07 |
| Chipaca | zyga— what store is it looking at? and does that store have a purchasable test-assumes and test-snapd-tools? | 11:07 |
| zyga | pstolowski: ^ does that mean we got what we asked for or that we didn't and we gave up? | 11:07 |
| zyga | Chipaca: I don't know how to check | 11:08 |
| Chipaca | right now me neither | 11:08 |
| zyga | Chipaca: this is just tests/main/completion | 11:08 |
| Chipaca | (meaning it requires some more context that i haven't loaded) | 11:08 |
| zyga | the logging would be easier to grok if it said "after 1 try and 0 retries" for instance | 11:08 |
| Chipaca | Apr 06 12:44:13 autopkgtest snapd[5022]: 2017/04/06 12:44:13.129725 daemon.go:176: DEBUG: uid=0;@ GET /v2/find?name=test-%2A 5.359029622s 200 | 11:09 |
| Chipaca | *five seconds* | 11:09 |
| Chipaca | a query to the store took *five* *seconds* | 11:10 |
| zyga | Chipaca: aha, I see it | 11:10 |
| zyga | but the reply is 200 | 11:10 |
| ogra_ | stop using GSM | 11:10 |
| zyga | ogra_: but I like my nokia :D | 11:11 |
| ogra_ | :D | 11:11 |
| zyga | Chipaca: so do you think this is it? | 11:11 |
| zyga | Chipaca: store having a unbelievably slow reply? | 11:11 |
| ogra_ | if it comes to core you can drop "unbelivable" from that sentence | 11:12 |
| Chipaca | zyga— that test's expect timeouts at exactly 5 seconds | 11:12 |
| Chipaca | anything over 5 seconds will fail | 11:12 |
| zyga | Chipaca: interesting, thanks | 11:13 |
| Chipaca | realistically, any response from the store over ~200ms is too slow | 11:13 |
| zyga | Chipaca: I'll open a store thread about this | 11:13 |
| ogra_ | rendering the myapps.u.c page for core can easily take a min, there are simply many revisions ... processing them takes a while | 11:13 |
| ogra_ | so i wouldnt be surprised if the download request takes longer too | 11:13 |
| Chipaca | ogra_— myapps.u.c is a different service though | 11:13 |
| ogra_ | same backend, no | 11:14 |
| Chipaca | nope | 11:14 |
| ogra_ | ? | 11:14 |
| ogra_ | ah, k | 11:14 |
| Chipaca | the thing we hit for searches is a wrapped elasticsearch | 11:14 |
| ogra_ | probably to elastic then :P | 11:14 |
| ogra_ | (so elastic, it streches time) | 11:15 |
| Chipaca | ogra_— I think I need to have lunch to appreciate your sense of humour :-) | 11:15 |
| zyga | https://forum.snapcraft.io/t/chasing-unreliable-tests/158/8 | 11:15 |
| ogra_ | heh | 11:15 |
| zyga | Chipaca: thanks for your assistance! | 11:16 |
| zyga | fg | 11:18 |
| pstolowski | zyga, yes, 1 retry and 200 means we got the data | 11:26 |
| mvo | zyga: 3160 is also needed for 2.24 ? are all of your PRs that deal with the connection thing marked? | 11:27 |
| Son_Goku | morphis, did you request whatever golang library does the progress thing to get updated in Fedora? | 11:28 |
| Son_Goku | I recall zyga mentioned something about an issue with that in the bodhi updates | 11:28 |
| pedronis | zyga: are all your PRs needed? also having them split out, doesn't that mean the testing is only partial? | 11:29 |
| mvo | zyga: so what needs to land? the core PR that renames the plugs on the core side and your three PRs? | 11:31 |
| zyga | mvo: I think it may not be needed in the end | 11:31 |
| zyga | mvo: the question is this, when we revert, do we auto-connect the reverted snap? | 11:32 |
| zyga | mvo: is it just like an install? | 11:32 |
| mvo | zyga: I think we do but we need to double check | 11:32 |
| zyga | mvo: if it is just like an install then we can land this branch, it matters little in practice because other branches will automatically connect core plugs anyway | 11:32 |
| zyga | mvo: and on refresh new connections will be made | 11:33 |
| zyga | mvo: I left it out specifically because it is a gray area and just a cleanup on top of the rest | 11:33 |
| mvo | zyga: it sounds like something we can test relatively easily? even a manual test would help to give me confidence in this | 11:33 |
| mvo | zyga: so its 3145,3154 and 3153 that we need to land for 2.24? | 11:34 |
| zyga | mvo: checking | 11:34 |
| mvo | zyga: could you make the forum entry for this a wiki ? then I can add a checklist | 11:34 |
| zyga | mvo: 3145 yes, for sure, 3154 (gee that was super confusing for my mind that swaps last two things around) yes; 3153 yes but I think it can only land after the others have helped | 11:35 |
| zyga | mvo: done, https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184 is now a wiki | 11:36 |
| icey | a snap I've been working on in bits for a while is now stuck with: https://pastebin.ubuntu.com/24354062/ | 11:36 |
| zyga | mvo: are you going to edit it or should I? | 11:37 |
| mvo | zyga: please go ahead | 11:37 |
| icey | the very first line of my main() function should also print out: "Main!" to stdout | 11:37 |
| zyga | icey: this is a bug in golang | 11:37 |
| mvo | zyga: a todo with the minimal fix we absolutely need for 2.24 would be great | 11:37 |
| icey | such fun, it's running a compiled Rust binary :-/ | 11:37 |
| icey | zyga: any ETA on a fix for that? | 11:37 |
| zyga | icey: it's fixed in ubuntu now I think but it needs to be fixed in other places that use go | 11:38 |
| zyga | icey: I think Chipaca is the person to ask | 11:38 |
| zyga | mvo: doing now | 11:38 |
| mvo | zyga: people ask about 2.24 and its not fully clear to me what we need to do now for the fix and what we can do later | 11:38 |
| icey | zyga: in ubuntu now == 17.10 on Thursday? | 11:38 |
| mvo | zyga: thank you | 11:38 |
| zyga | icey: not sure really, sorry | 11:38 |
| icey | 17.04 rather | 11:38 |
| icey | zyga: talking about releases too much today | 11:38 |
| icey | zyga do you know what version of snap it's fixed in? https://pastebin.ubuntu.com/24354069/ is what I'm on now | 11:39 |
| pedronis | mmh, getting this kind of errors in autokpkgtest atm: error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received. | 11:44 |
| zyga | mvo: I'm seeing a lot of tihs | 11:45 |
| zyga | Cloning into '/tmp/go/.cache/govendor/gopkg.in/mgo.v2'... | 11:45 |
| mvo | zyga: also is https://github.com/snapcore/snapd/pull/3145#discussion_r110329005 still relevant in 3145? i.e. do we need those plugs on the core snap afterall? or will the followup branches DTRT? sorry that I have so many questions | 11:45 |
| zyga | error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received. | 11:45 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 11:45 |
| pedronis | context: # cd .; git clone https://gopkg.in/mgo.v2 /tmp/go/.cache/govendor/gopkg.in/mgo.v2 | 11:45 |
| pedronis | Cloning into '/tmp/go/.cache/govendor/gopkg.in/mgo.v2'... | 11:45 |
| pedronis | something wrong with gopkg.in? | 11:45 |
| zyga | mvo: yes, I think we still want to rename them, the internal rename in snapd is just a fixup but we should correct the actual yaml on disk later | 11:45 |
| zyga | pedronis: ha | 11:45 |
| zyga | pedronis: funny that we both reported it :) | 11:45 |
| zyga | yes, looks like something wrong, what is mgo.v2 | 11:46 |
| mvo | zyga: so the internal rename does not have to be in sync with the core snap? so 3145 is fine as is? | 11:46 |
| zyga | mvo: yes | 11:47 |
| zyga | mvo: collecting PRs | 11:48 |
| zyga | mvo: only one left | 11:48 |
| pedronis | zyga: mgo.v2, mongo driver but actually where we get bson encoding support from , I think was added recently | 11:48 |
| zyga | mvo: please check https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184 again | 11:48 |
| pedronis | see errtracker stuff | 11:49 |
| zyga | pedronis: aha, makes sense | 11:49 |
| zyga | right, I remember that | 11:49 |
| zyga | mvo: have a look at that and tell me if it makes sense | 11:49 |
| zyga | mvo: trivial fix on https://github.com/snapcore/core/pull/32#pullrequestreview-31819934 | 11:53 |
| mup | PR core#32: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32> | 11:53 |
| * Chipaca back from lunch | 11:58 | |
| Chipaca | icey, zyga, what's the question again? | 11:58 |
| zyga | Chipaca: golang bug with clone+exec | 11:58 |
| icey | Chipaca: https://pastebin.ubuntu.com/24354062/ | 11:59 |
| zyga | Chipaca: pthread_create doesn't work while execing | 11:59 |
| Chipaca | icey— what're you running there? | 11:59 |
| icey | Chipaca: alacritty :) | 11:59 |
| icey | a snap I've been working on in bits for a while now | 11:59 |
| Chipaca | alright | 11:59 |
| Chipaca | icey— so, *most* of that family of errors are just warnings | 11:59 |
| icey | it builds fine, but hangs when running; if I leave it long enough, I get that output | 11:59 |
| Chipaca | icey— but not all of them :-( | 11:59 |
| icey | if I run the binary itself without snapd, it runs fine | 12:00 |
| icey | the confined version never runs the first line of the main() function | 12:00 |
| Chipaca | icey— but none of it involves hanging | 12:00 |
| icey | this particular binary also does exciting things with opengl and such | 12:00 |
| icey | and is a classic snap | 12:00 |
| Chipaca | icey— that is: either it'll work (sometimes printing a spuriouos warning) or it won't (with something silly about permissions) | 12:00 |
| icey | yeah, this one will literally hang forever (as far as I can tell) and periodically output that line | 12:00 |
| Chipaca | icey— so, the pthread warnings are *probably* ignorable; you're probably getting denies in dmesg | 12:01 |
| icey | Chipaca: with a classic sna? :-/ | 12:01 |
| zyga | icey: with any kind IMO | 12:01 |
| Chipaca | icey— any snap can get denies | 12:01 |
| Chipaca | classic just means the jail is built differently (wider, roomier, but still a jail) | 12:01 |
| Chipaca | even decmode, hah (but harder to do) | 12:02 |
| icey | zyga: Chipaca I'm getting https://pastebin.ubuntu.com/24354169/ in dmesg every time I start it | 12:02 |
| zyga | icey: are you connected over ssh? | 12:03 |
| icey | zyga: I'm running locally | 12:03 |
| zyga | hmmm | 12:03 |
| zyga | odd | 12:03 |
| icey | bash on laptop | 12:03 |
| icey | I don't think this would work well over ssh, it | 12:03 |
| * zyga looks at the leet PID | 12:03 | |
| icey | it is a terminal using GPU acceletarion :) | 12:03 |
| icey | acceleration* | 12:03 |
| zyga | icey: can you please report that bug | 12:04 |
| zyga | icey: it feels like something else now | 12:04 |
| zyga | icey: I recall seeing this somewhere, I'll talk to the security team about it | 12:04 |
| icey | zyga: what data would you like on the bug? this dmesg output? | 12:04 |
| zyga | icey: please open a bug on launchpad.net/snap-confine | 12:04 |
| zyga | icey: that denial is key, please describe the context, maybe how to reproduce it | 12:04 |
| zyga | icey: does it happen with other snaps? | 12:04 |
| zyga | icey: or just this? | 12:04 |
| icey | zyga: not that I have experienced. This snap has hit show-stopping bugs every time I've tried to move forward with it :) | 12:05 |
| Chipaca | icey— have you looked at snappy-debug.security scanlog? | 12:05 |
| icey | Chipaca: ... no ... ? | 12:05 |
| icey | Chipaca: how can I do that :) | 12:05 |
| Chipaca | icey— snap install snappy-debug | 12:06 |
| Chipaca | icey— snappy-debug.security scanlog your.service | 12:06 |
| Chipaca | icey— then start the service | 12:06 |
| Chipaca | icey— see if it says anything | 12:06 |
| Chipaca | jdstrand— ping | 12:07 |
| Chipaca | icey— or, snappy-debug.security --help | 12:08 |
| Chipaca | icey— for more details | 12:08 |
| * zyga AFK for a moment | 12:08 | |
| Chipaca | although, the aduit log being on snap-confine might mean that it's bug#1672819 | 12:09 |
| icey | Chipaca: running "snappy-debug.security scanlog alacritty", followed by starting `alacritty` in a new tab shows no output | 12:09 |
| mvo | zyga: 3154 has test failures that look real | 12:09 |
| Chipaca | ahem | 12:09 |
| * Chipaca pokes hal | 12:09 | |
| Chipaca | bug 1672819 | 12:09 |
| mup | Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-key> <xenial> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):In Progress by colin-king> <https://launchpad.net/bugs/1672819> | 12:09 |
| Chipaca | mup— thank you | 12:09 |
| Chipaca | icey— and you get that audit log every time? | 12:10 |
| icey | as requested zyga: bug 1681421 | 12:10 |
| mup | Bug #1681421: snap-confine dmesg error and snap hangs <Snappy Launcher:New> <https://launchpad.net/bugs/1681421> | 12:10 |
| icey | yeah Chipaca | 12:10 |
| icey | as far as I can tell | 12:10 |
| icey | Chipaca: only thing that changes is the timestamp and PID | 12:11 |
| morphis | Son_Goku: no, didn't looked into that yet | 12:19 |
| morphis | Son_Goku: https://github.com/cheggaaa/pb you mean, right? | 12:22 |
| Son_Goku | yeah | 12:22 |
| morphis | Son_Goku: that is interesting, its not yet in your BuildRequires: list | 12:23 |
| Son_Goku | it is, though | 12:23 |
| morphis | ah no | 12:23 |
| morphis | there it is | 12:23 |
| morphis | Son_Goku: yeah looks a bit outdated, so there is a bodhi request already to get it updated or what did you mean with your second comment? | 12:25 |
| Son_Goku | morphis: like we did with the other one | 12:31 |
| Son_Goku | file a bug to request it to be updated | 12:31 |
| morphis | sure, but for what do we need an update? | 12:31 |
| morphis | Son_Goku: I don't see any direct commetn from zyga on this | 12:33 |
| Son_Goku | https://bodhi.fedoraproject.org/updates/snapd-2.23.6-4.fc25%20snapd-glib-1.10-1.fc25#comment-587757 | 12:33 |
| morphis | ok, lets give a newer version a try and see if that fixes the problem | 12:34 |
| Son_Goku | the progress bar package (https://apps.fedoraproject.org/packages/golang-github-cheggaaa-pb) ships code from 2015 | 12:34 |
| Chipaca | Son_Goku, zyga, dunno if you knew but the socket is no longer needed | 12:35 |
| Son_Goku | Chipaca: wut | 12:35 |
| Son_Goku | why? | 12:35 |
| morphis | Chipaca: /run/snapd.socket is dropped? | 12:35 |
| Chipaca | no | 12:35 |
| zyga | re | 12:35 |
| Chipaca | the .socket is no longer needed | 12:35 |
| Son_Goku | then how is it socket activated? | 12:35 |
| zyga | mvo: looking | 12:35 |
| Chipaca | snapd listens to /run/snapd.socket and /run/snapd-snap.socket automatically if it hasn't been activated on startup | 12:35 |
| zyga | Chipaca: I know | 12:36 |
| Chipaca | ah ok | 12:36 |
| Son_Goku | geez, you scared me for a sec | 12:36 |
| Chipaca | it's still useful, because the .socket can start up earlier than the .service | 12:36 |
| Chipaca | and queue stuff for us | 12:36 |
| Chipaca | Son_Goku— i'd love to be able to say i did it on purpose, but not this time | 12:36 |
| zyga | mvo: aha, I will have some silly test fixups to do | 12:37 |
| zyga | mvo: thank you! | 12:37 |
| Son_Goku | the socket and timer units are enabled by default in Fedora | 12:37 |
| zyga | mvo: this is just a list of grep patterns to correct | 12:37 |
| Chipaca | Son_Goku— enabled but not started? | 12:37 |
| Son_Goku | well, the snapd package will start them if distro policy says they are enabled on install | 12:37 |
| zyga | Son_Goku: right, I think the socket is relevant as before but what Chipaca meant is that we no longer require it strictly speaking | 12:37 |
| Son_Goku | so for Fedora 25 and newer, that will be the case | 12:37 |
| Son_Goku | Fedora 24 and EL7, it won't be | 12:38 |
| morphis | Chipaca, zyga: so you guys basically don't require systemd to pass you a socket fd anymore, correct? | 12:39 |
| mvo | zyga: thanks for looking into it | 12:41 |
| mvo | zyga: silly question, is there anything in 3145 that can be observed from the outside? i.e. I will not see anything in snap interfaces or similar? | 12:42 |
| Chipaca | morphis— dude, you can run snapd directly, for testing and stuff. Hence https://github.com/chipaca/bin/blob/master/run-snapd-srv | 12:42 |
| Chipaca | morphis— (when testing stuff i usuall “go build -o /tmp/srv ./cmd/sanpd && sudo ~/bin/run-snapd-srv” | 12:43 |
| Chipaca | ) | 12:43 |
| morphis | sure but there was a time when we had to do something like https://github.com/teknoraver/snap-openwrt/blob/master/snapd/src/snapd-wrapper.c explicitly to get snapd running | 12:43 |
| Chipaca | morphis— yes; no more | 12:43 |
| morphis | good | 12:44 |
| Chipaca | morphis— if you look at the history of run-snapd-srv, before it used to call systemd-activate | 12:44 |
| Chipaca | same thing really, but easier | 12:44 |
| mvo | niemeyer: your input on https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.24 would be great, 3145 needs a re-review | 12:44 |
| mvo | niemeyer: and the other two need to land for 2.24 as well | 12:44 |
| Chipaca | morphis— you'll see lines like “2017/04/10 13:44:33.800749 daemon.go:211: DEBUG: socket "/run/snapd.socket" was not activated; listening”, which means it's doing this that we're discussing | 12:44 |
| morphis | very good | 12:45 |
| zyga | mvo: thinking | 12:46 |
| zyga | mvo: yes, it wil be seen in snap interfaces | 12:46 |
| zyga | mvo: this is why those tests fail | 12:46 |
| jdstrand | Chipaca: hey | 12:53 |
| Chipaca | jdstrand— snappy-debug is yours, yes? | 12:53 |
| zyga | jdstrand: when would snap confine need /dev/tty ? | 12:54 |
| mvo | zyga: hm, sorry, I'm still not seeing the full picture - 3145 in isolation will not work because it needs a core snap with core-support-plug. either by renaming the meta-data or by landing the followup branch 3154. is that correct? so the order would be 3154, 3145, 3153? | 12:54 |
| zyga | mvo: correct | 12:55 |
| jdstrand | zyga: typically if it is trying to write debug output | 12:55 |
| zyga | jdstrand: aha, interesting | 12:55 |
| jdstrand | zyga: https://bugs.launchpad.net/snap-confine/+bug/1681421/comments/1 | 12:56 |
| mup | Bug #1681421: snap-confine dmesg error and snap hangs <Snappy Launcher:New> <https://launchpad.net/bugs/1681421> | 12:56 |
| jdstrand | zyga: well, or error, info, etc | 12:56 |
| zyga | jdstrand: right | 12:56 |
| jdstrand | Chipaca: well, I guess, yes | 12:56 |
| Chipaca | jdstrand— :) | 12:56 |
| zyga | jdstrand: should we add that to the profile then, I didn't see it today | 12:56 |
| jdstrand | zyga: did you read my comment? :) | 12:56 |
| zyga | jdstrand: yes | 12:56 |
| zyga | jdstrand: you said you'd add it | 12:56 |
| jdstrand | "I'll add this to the snap-confine profile" | 12:56 |
| zyga | jdstrand: since 2.24 is being pushed out we could add this today still | 12:57 |
| Chipaca | jdstrand— i ask because running 'strings' on the .swp file you ship in there is interesting | 12:57 |
| jdstrand | zyga: if you want to do that this second, feel free | 12:57 |
| jdstrand | meh | 12:57 |
| jdstrand | Chipaca: :\ | 12:57 |
| Chipaca | jdstrand— :-D | 12:57 |
| Chipaca | jdstrand— not *that* interesting, otherwise I would've reached out in private | 12:59 |
| jdstrand | Chipaca: yep, thanks for letting me know. I'll also be adding a test to the review tools (I thought I had this already tbh) | 12:59 |
| morphis | Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1440773 | 12:59 |
| Chipaca | jdstrand— I'd poke sergiusens to add .swp files to the ignore list, but he's not around | 13:00 |
| Chipaca | jdstrand— if only we had a place to write down issues we had so we could keep track of them asynchronously | 13:00 |
| jdstrand | Chipaca: haha | 13:00 |
| jdstrand | zyga: so I can get to the /dev/tty thing in a few minutes if that would help. if you are going to do it, let me know | 13:02 |
| icey | jdstrand: your change to the apparmor profile removed the dmesg warning, unfortunately the snap's behaviour hasn't otherwise changed | 13:02 |
| Son_Goku | morphis: was the progress bar thing the one that caused the build to fail on ppc64? | 13:03 |
| jdstrand | icey: are you using snappy-debug? | 13:03 |
| morphis | Son_Goku: no | 13:03 |
| jdstrand | icey: or just dmesg? | 13:03 |
| icey | I have, it gave no output earlier | 13:03 |
| jdstrand | icey: I mean just now | 13:03 |
| morphis | Son_Goku: we didn't found out what the problem is with ppc64 | 13:03 |
| Son_Goku | ah | 13:03 |
| icey | jdstrand: running `$ sudo snappy-debug.security scanlog alacritty` just now gives no output when I run `alacritty` in another tab | 13:03 |
| jdstrand | icey: ok. in another window, do 'grep DEN /var/log/syslog' | 13:04 |
| zyga | jdstrand: I'm in the standup now, if you can do it I'll merge that for 2.24 | 13:04 |
| jdstrand | icey: snappy-debug doesn't yet understand dbus denials (it will, just doesn't yet) | 13:04 |
| zyga | jdstrand: thank you! | 13:04 |
| icey | just multiple lines of the rw on /dev/tty | 13:04 |
| zyga | jdstrand: (I'm still working on the plug rename thing) | 13:04 |
| icey | nothing new | 13:05 |
| jdstrand | icey: ok, then yeah, it is something else. I'll fix the the /dev/tty denial | 13:05 |
| jdstrand | zyga: | 13:05 |
| jdstrand | zyga: ok | 13:05 |
| icey | jdstrand: I'm going to see if a simple rust snap still works :) | 13:05 |
| icey | jdstrand: looks ike a no go on a super simple rust program as well | 13:08 |
| jdstrand | weird | 13:08 |
| === Son_Goku is now known as Conan_Kudo | ||
| jdstrand | icey: is this classic, devmode or strict confinement? | 13:09 |
| === Conan_Kudo is now known as Son_Goku | ||
| icey | jdstrand: classic, I can try devmode / strict with this minimal one too | 13:09 |
| icey | the thing I'm actually trying to snap will require classic though, it's a terminal :) | 13:09 |
| icey | well jdstrand , building it in classic works perfectly | 13:09 |
| icey | (the test one) | 13:10 |
| morphis | Son_Goku: is there an easy way to use a source dir instead of a tarball for an rpm build? | 13:10 |
| jdstrand | sergiusens: hey, can you take a look at backscroll when you're around to help icey with a rust program that isn't running in classic? | 13:10 |
| icey | jdstrand: I've got 2 rust programs not running in classic now | 13:10 |
| jdstrand | icey: in addition to that irc ping, you might bring this topic up in the forum | 13:10 |
| sergiusens | jdstrand, sure, icey and I have been looking at this here and there | 13:10 |
| Son_Goku | morphis: I think you can use rpmbuild -bb --in-place | 13:11 |
| jdstrand | ah | 13:11 |
| Son_Goku | it skips %prep stage | 13:11 |
| jdstrand | ok, I'll step back then | 13:11 |
| morphis | Son_Goku: let me try | 13:11 |
| sergiusens | forum or rocket, irc is sort of dead to me :-P | 13:11 |
| Son_Goku | and ignores source and patch | 13:11 |
| icey | sergiusens: it's the same snap too :) | 13:11 |
| icey | sergiusens: alacritty will /try/ to start with strict mode on, but with classic mode, it hangs | 13:12 |
| sergiusens | icey, yeah, I figured, GL drama and I still need to pass in those flags that were mentioned in the rust plugin | 13:12 |
| icey | as does my super simple, no dependency rust program | 13:12 |
| icey | sergiusens: it's not just gl... | 13:12 |
| sergiusens | icey, is this xenial build, xenial run | 13:12 |
| sergiusens | ? | 13:12 |
| icey | sergiusens: yakkety | 13:12 |
| icey | and sergiusens, this program has the same problem: https://is.gd/wDGfHt | 13:13 |
| icey | super tiny and exhibits the same symptoms | 13:13 |
| sergiusens | icey, mind reminding me in which issue we got the recommendation on flags to pass to rust? | 13:13 |
| sergiusens | icey, most likely a program loader issue | 13:14 |
| icey | sergiusens: https://github.com/rust-lang/cargo/issues/3694 | 13:14 |
| icey | sergiusens: I'm working on a tweak to the rust plugin to set RUSTFLAGS to LDFLAGS | 13:14 |
| icey | sergiusens: this classic mode + rust thing is killing me though | 13:15 |
| icey | strict + rust works fine | 13:15 |
| icey | (if the program can do strict) | 13:15 |
| sergiusens | icey, yeah, so most certainly program loader related | 13:15 |
| sergiusens | icey, so RUSTFLAGS format isn't really documented, is it 1:1 with LDFLAGS? | 13:16 |
| icey | no clue sergiusens :)I was literally just trying shoving ldflags into rustflags | 13:16 |
| icey | but I can't even test since it can't run | 13:16 |
| sergiusens | right, let me ask on the Issue | 13:16 |
| icey | sergiusens: I'm also updating the snap-confine bug with a bit more info | 13:17 |
| icey | sergiusens: looks like we may want something like : RUSTFLAGS = -C link-args="$(LDFLAGS)" | 13:18 |
| sergiusens | icey, oh, "Note that the exact linker that the compiler invokes isn't guaranteed to not change over time, so there's not always a valid interpretation of LDFLAGS even if it exists." | 13:18 |
| sergiusens | icey, can you figure out what linker it is using? | 13:19 |
| === jgrimm-away is now known as jgrimm | ||
| tvoss | pedronis: trying to figure out what your comment about the lib version means :) | 13:21 |
| icey | sergiusens: I suspect that on linux it's using ld, but cargo (and rust) can also compile on all sorts of other systems (windows) so that may be what he's referring to | 13:22 |
| icey | sergiusens: https://www.reddit.com/r/rust/comments/58z5xx/does_rust_use_gnu_or_llvm_linker_on_linux/ | 13:23 |
| mup | PR snapd#3161 opened: snap-confine,browser-support: /dev/tty for snap-confine, misc browser-support for gnome-shell <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3161> | 13:31 |
| morphis | Son_Goku, zyga: we still have "/usr/bin/ld: cannot find -lcap" for rpm builds in latest master | 13:31 |
| Son_Goku | :S | 13:31 |
| cachio | sergiusens, getting "GPG error: http://ports.ubuntu.com/ubuntu-ports xenial InRelease: Could not execute 'apt-key' to verify signature" | 13:31 |
| pedronis | tvoss: it's the command that doesn't like -b < 1024, or it's the library? | 13:31 |
| jdstrand | zyga: fyi, https://github.com/snapcore/snapd/pull/3161 | 13:32 |
| mup | PR snapd#3161: snap-confine,browser-support: /dev/tty for snap-confine, misc browser-support for gnome-shell <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3161> | 13:32 |
| morphis | Son_Goku: let me try to fix this | 13:32 |
| sergiusens | cachio, on what? | 13:32 |
| cachio | sergiusens, when I make apt-get update on classic in my dragonboard | 13:32 |
| sergiusens | cachio, oh, ask ogra_ | 13:32 |
| cachio | sergiusens, ok, tx | 13:32 |
| tvoss | pedronis: it's the library ultimately | 13:32 |
| ogra_ | jdstrand, is https://forum.snapcraft.io/t/would-someone-create-an-electron-snap-for-this-forum/78/16 related | 13:32 |
| tvoss | pedronis: libssl refuses b < 1024 | 13:33 |
| pedronis | tvoss: ok, that was my wondering | 13:33 |
| ogra_ | jdstrand, i noticed that i see the mmap denial only on systems with newer kernels | 13:33 |
| cachio | ogra_, hey, getting "GPG error: http://ports.ubuntu.com/ubuntu-ports xenial InRelease: Could not execute 'apt-key' to verify signature" when I make apt-get update on classic in my dragonboard | 13:33 |
| pedronis | tvoss: you need a 2nd snapd review and input again from tyler I suppose | 13:33 |
| ogra_ | jdstrand, same app works fine on a bare 16.04 with the original 4.4 | 13:33 |
| tvoss | pedronis: I was thinking about erroring out, but just raising to working level seems to be more reasonable | 13:33 |
| cachio | ogra_, any idea why? | 13:33 |
| ogra_ | cachio, yeah, rthere is a bug open for that ... | 13:33 |
| ogra_ | not yet | 13:33 |
| tvoss | pedronis: yup, will give Tyler a ping now | 13:33 |
| cachio | ogra_, ok, thanks | 13:34 |
| ogra_ | cachio, bug 1670475 | 13:35 |
| mup | Bug #1670475: apt-secure complaints with classic snap on arm64 (dragonboard) <Snappy:New> <https://launchpad.net/bugs/1670475> | 13:35 |
| cachio | ogra_, great, tx | 13:35 |
| ogra_ | (this isnt actually dragonvboard only, i see it on pi2/3 too now) | 13:35 |
| ogra_ | i'll try to make up some time for it this week | 13:35 |
| ogra_ | it is old enough that it starts to smell :) | 13:36 |
| cachio | ogra_, good | 13:37 |
| icey | sergiusens: is there anything I can do to help with diagnosing / fixing this classic rust snap issue? | 13:46 |
| icey | I've got a nive 25mb strace output of trying to run it | 13:46 |
| sergiusens | icey, let me wrap up working on yarn support and then look into this. We have a rust integration test demo which I will turn into a classic confined snap for testing out | 13:47 |
| icey | sergiusens: we have to ensure that it runs too, it builds just fine but will never run | 13:47 |
| sergiusens | icey, bottom line is that, `readelf -a <elf>`'s output under program loader needs to have the core snaps ld instead of the one on the system or you are in for trouble | 13:48 |
| sergiusens | icey, yeah, in our demos suite we test that they run ;-) | 13:48 |
| morphis | Son_Goku: ok, this seems to be more my fault but wondering what I am doing wrong with my in-tree build | 13:49 |
| icey | sergiusens: looks like the ld is: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] ? | 13:50 |
| zyga | jdstrand: thank you | 13:51 |
| icey | sergiusens: it looks like, when snapcraft is calling build, that env['LDFLAGS'] is _not_ set | 13:52 |
| sergiusens | icey, it is, you just don't see it... under snapcraft.internal.common.run (or run_output) there's this wrapper script that gets created | 13:53 |
| sergiusens | this was in snapcraft 0.2, before my time (I took over on 0.3) and never managed to improve this logic | 13:54 |
| icey | sergiusens: I'm trying to do something like: https://gist.github.com/ChrisMacNaughton/475882f81acab077e5e693e7df5e433e to get the RUSTFLAGS setup but LDFLAGS isn't present :-/ | 13:54 |
| Chipaca | niemeyer— I think I left a dangling Spread-19 | 13:55 |
| niemeyer | Chipaca: Not a great problem these days.. it should get cleaned up automatically without any ill side effects | 13:55 |
| Chipaca | k | 13:55 |
| Chipaca | niemeyer— i mean, started spread with -reuse, and then deleted the .spread file :-) | 13:56 |
| niemeyer | Chipaca: Aha, yeah, that might make it hard to reuse it ;) | 13:56 |
| zyga | jdstrand: looked again | 13:56 |
| Chipaca | niemeyer— so flaky | 13:56 |
| Chipaca | niemeyer— hopping subjects, from mwhudson on https://bugs.launchpad.net/snappy/+bug/1638537: | 13:58 |
| mup | Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1638537> | 13:58 |
| Chipaca | AIUI, generating an RSA key ends up benchmarking montgomery multiplication, and I know there are SIMD tricks you can use for that. Go doesn't seem to be using anything in this area but it looks like ssh-keygen is using openssh's routines for this and I bet they are optimized nearly as much as is possible. | 13:58 |
| * zyga looks at failing tests on various "rename" branches | 13:58 | |
| tvoss | tyhicks: hey there, would be great if you could have another pass on https://github.com/snapcore/snapd/pull/3130 | 14:00 |
| mup | PR snapd#3130: overlord/devicestate: switch to lib(open)ssl for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130> | 14:00 |
| Chipaca | tvoss— question for you about that | 14:00 |
| Chipaca | tvoss— are you using locking_function and threadid_func? (how/where?) is that even needed? | 14:01 |
| tvoss | Chipaca: shoot, btw: ssh-keygen uses openssl ultimately | 14:01 |
| Chipaca | tvoss— yeah i know, the above was to give gustavo some context about this | 14:01 |
| tvoss | Chipaca: I haven't looked into threaded behavior, yet, as I was just looking at device key generation. | 14:01 |
| tvoss | Chipaca: making generateRSAKey available within all of snapd (and investigating into thread-safety) is on my list next | 14:02 |
| niemeyer | Chipaca, tvoss: Heya, reusing ssh-keygen really looks like the best alternative there | 14:04 |
| Chipaca | niemeyer— that's one to talk with tyhicks, as he's the driver of the move to libssl | 14:04 |
| cachio | jdstrand, did you find any workaround for this bug https://bugs.launchpad.net/snappy/+bug/1670475 ? | 14:04 |
| mup | Bug #1670475: apt-secure complaints with classic snap on arm64 (dragonboard) <Snappy:New> <https://launchpad.net/bugs/1670475> | 14:04 |
| Chipaca | at least afaik | 14:04 |
| morphis | Son_Goku: was my fault | 14:05 |
| tvoss | niemeyer: based on tyhicks feedback, I adjusted the PR to use rsa_generate_key_ex from openssl directly. ssh-keygen uses the same call | 14:05 |
| morphis | tvoss: your PR builds fine on fedora | 14:06 |
| tvoss | morphis: ack | 14:06 |
| morphis | zyga, Son_Goku: https://paste.ubuntu.com/24354626/ that is what fails currently on fedora with latest master | 14:06 |
| Son_Goku | yeah, something is being linked statically | 14:07 |
| zyga | mvo: based on the discussion in the call I'd like to add https://github.com/snapcore/snapd/pull/3160 to the 2.24 milstone if that is okay | 14:07 |
| mup | PR snapd#3160: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160> | 14:07 |
| Son_Goku | morphis: I had this problem before and fixed it | 14:08 |
| zyga | morphis: static linking + fortify = incompatible | 14:08 |
| zyga | morphis: do a patch that allows us not to build it (it's useless on classic systems) | 14:08 |
| zyga | Son_Goku: curious to know what you did | 14:08 |
| Son_Goku | it builds fine in 2.23.6 with all the current patches | 14:08 |
| zyga | aha | 14:09 |
| Son_Goku | but in 2.23.5, I had to do some sed magic to make it build | 14:09 |
| morphis | zyga: I know this isn't supposed to work but we landed all changes in 2.24 and that one fails | 14:09 |
| Son_Goku | to get rid of it requesting static library preferences | 14:09 |
| zyga | Son_Goku: aha | 14:09 |
| zyga | Son_Goku: hmmm | 14:09 |
| zyga | Son_Goku: I think we need that still | 14:09 |
| zyga | Son_Goku: I'd like to find a solution where it can stay and we can link | 14:10 |
| Son_Goku | yes | 14:10 |
| zyga | Son_Goku: (and on fedora the build is entirely dynamic) | 14:10 |
| Son_Goku | yep | 14:10 |
| zyga | anyway, I'm sure we can | 14:10 |
| zyga | just wanted to say this | 14:10 |
| morphis | zyga: did the build for the shutdown helper change between 2.23.6 and 2.24? | 14:11 |
| zyga | morphis: perhaps, the point is that hardedned static builds just don't exist yet AFAIK | 14:12 |
| zyga | morphis: maybe we now apply hardening... well, harder | 14:12 |
| morphis | zyga: we do on fedora | 14:12 |
| jdstrand | cachio: only the crappy one in comment #1 | 14:12 |
| cachio | jdstrand, ok, thanks | 14:13 |
| zyga | morphis: I know but this was disabled so that it could link | 14:14 |
| zyga | morphis: same was true in debian/ubuntu BTW | 14:14 |
| morphis | zyga: were was this disable? | 14:14 |
| morphis | s/disable/disabled/? | 14:14 |
| zyga | morphis: with cflags overrides | 14:14 |
| morphis | zyga: we don't do this for 2.23.6 | 14:15 |
| zyga | morphis: not sure if this is there now, the point is that just static hardened linking doens't exist AFAIK | 14:15 |
| zyga | morphis: I'm lost in which-version-had-what | 14:15 |
| morphis | zyga: that is fine, however something change in the build of the shutdown helper between 2.23.6+patch and 2.24 so that it now doesn't work anymore | 14:17 |
| zyga | morphis: git diff on the makefile to check :) | 14:18 |
| morphis | yeah, checking that already | 14:19 |
| morphis | zyga: didn't you integrate https://github.com/snapcore/snapd/pull/3108 in yours as said on that PR? | 14:21 |
| mup | PR snapd#3108: cmd: use libtool for the internal library <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3108> | 14:21 |
| icey | sergiusens: just posted some fun in #rust that you may enjoy: https://gist.github.com/ChrisMacNaughton/a81233e05995013ebb9a0c333c157b76 | 14:21 |
| mvo | zyga: sure, its ok - sorry for the delay, I was in the releae meeting | 14:25 |
| zyga | mvo: that's okay | 14:26 |
| zyga | mvo: any changes/ | 14:26 |
| mvo | zyga: just that we need validation from the CE team when we do 2.24 to stable | 14:27 |
| zyga | ok, that's good | 14:27 |
| zyga | niemeyer: hey, we're seeing some mgo.v2 errors related to git | 14:28 |
| zyga | niemeyer: e.g. http://pastebin.ubuntu.com/24354760/ in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170410_141305_8a2e6@/log.gz | 14:29 |
| zyga | niemeyer: do you have any ideas if that could be related to gopkg.in? (any spike in load) | 14:29 |
| niemeyer | zyga: No idea.. let me see | 14:30 |
| niemeyer | zyga: Doesn't seem extraordinary.. it's doing ~10mbps in and ~10 out, which is even below what it has been sustaining recently | 14:32 |
| zyga | niemeyer: anything odd in logs? this particular repo failed numerous times today; maybe it's just coincidence | 14:33 |
| niemeyer | zyga: Nothing special I can see.. this is requested about ~10 times every minute | 14:35 |
| niemeyer | zyga: I just fetched it locally as well from my crappy network without issues | 14:36 |
| niemeyer | zyga: Process is up since Feb 21.. RSS at 22MB.. load at 0.2.. can't see much to be worried about yet | 14:37 |
| niemeyer | zyga: The fact this is also an EOF makes me worried that perhaps the networking of those machines is not as healthy as it should be | 14:39 |
| zyga | niemeyer: thanks for checking, I'll keep monitoring | 14:39 |
| zyga | niemeyer: yeah | 14:39 |
| zyga | niemeyer: the only possiblity is linode itself now | 14:39 |
| niemeyer | zyga: Well.. :) | 14:40 |
| niemeyer | zyga: I'm far less optimistic about my abilities to guess problems like that :) | 14:40 |
| ogra_ | tvoss, niemeyer asked me to carry the keygen issue over to the forum, i opened https://forum.snapcraft.io/t/ubuntu-core-key-generation-slowness/229/1 | 14:43 |
| ogra_ | please take a look | 14:43 |
| tvoss | ogra_: ack | 14:43 |
| tvoss | niemeyer: did you have a chance to walk through the PR? | 14:43 |
| ogra_ | tyhicks, jdstrand ^^^ same for you two :) | 14:44 |
| niemeyer | tvoss: No, sorry, I should have done that. That said, I have a reasonable idea of where things stand. The reason I asked ogra_ for some details on that particular piece is just that it feels like ssh-keygen is the best way forward, and there's some disagreement about that which isn't entirely clear, so would like to have a thread for us to talk | 14:46 |
| morphis | zyga: you saw my message about https://github.com/snapcore/snapd/pull/3108 ? | 14:48 |
| mup | PR snapd#3108: cmd: use libtool for the internal library <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3108> | 14:48 |
| zyga | morphis: yes, I won't have time to touch this before 2.24 though | 14:49 |
| morphis | zyga: ok, let me see if I get this quickly up | 14:49 |
| tyhicks | jdstrand: you can ignore the ssh-keygen topic - it was being discussed by mdeslaur, sarnold, and myself | 14:50 |
| tyhicks | I've responded in the forum | 14:50 |
| ogra_ | tyhicks, thanks | 14:51 |
| tyhicks | np | 14:51 |
| niemeyer | tyhicks: Thanks! Will follow up there | 14:51 |
| jdstrand | tyhicks: ack, thanks | 14:52 |
| mup | PR snapcraft#1241 closed: help: replace dashes with underscores when printing plugins help <Created by EduardoVega> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1241> | 14:54 |
| mvo | Chipaca: re https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175> what am I missing? I thought we have all the bits needed in master now? | 14:56 |
| Chipaca | mvo— we do? | 14:58 |
| Chipaca | mvo— let me look :-/ | 14:58 |
| mvo | Chipaca: I replied to that forum thread | 14:58 |
| mikeb_ | I'm having problems with snapcraft daemons. It looks like if I have a 'notify' daemon defined in my snapcraft.yaml, snapd is waiting for the notification before starting other daemons. Is this known behavior? | 14:58 |
| mvo | Chipaca: unless I miss something of course :) | 14:58 |
| mvo | Chipaca: but I think the example from sergio works, at least we have a very similar spread test and I remember fixing things there | 14:59 |
| jdstrand | niemeyer: hi! I found an issue in the mailing list functionality of the forum. where is the best place to report that, the forum? | 15:00 |
| niemeyer | jdstrand: Yes, there's a "forum" category | 15:01 |
| Chipaca | mvo— which is the test that tests this? | 15:01 |
| mvo | Chipaca: https://github.com/snapcore/snapd/blob/master/tests/main/snap-env/task.yaml | 15:02 |
| mvo | Chipaca: https://github.com/snapcore/snapd/blob/master/tests/lib/snaps/test-snapd-tools/meta/snap.yaml | 15:02 |
| zyga | Cloning into '/tmp/go/.cache/govendor/gopkg.in/check.v1'... | 15:02 |
| zyga | error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received. | 15:02 |
| zyga | niemeyer: ^ now on check.v1 | 15:02 |
| mvo | Chipaca: check the EXTRA_CACHE_DIR: $SNAP_USER_DATA/ there | 15:03 |
| mvo | Chipaca: thats the case that we want, right? | 15:03 |
| Chipaca | mvo— note that what I'm saying we should support is | 15:03 |
| niemeyer | zyga: Network seems pretty busted | 15:03 |
| Chipaca | mvo— command: foo $BAR | 15:03 |
| niemeyer | zyga: Let me try restarting the process just in case | 15:03 |
| Chipaca | mvo— which we don't | 15:03 |
| Chipaca | afaik | 15:03 |
| mvo | Chipaca: aha, yes, this one is indeed missing | 15:03 |
| mvo | Chipaca: good point, sorry that I misunerstood this | 15:04 |
| Chipaca | mvo— in you can't even have “command: foo --bar=baz” | 15:04 |
| niemeyer | zyga: Done | 15:04 |
| mvo | Chipaca: yeah, command is super restrictive currently | 15:04 |
| Chipaca | yep | 15:04 |
| mvo | Chipaca: +1 for fixing that | 15:04 |
| Chipaca | mvo— tweaking https://forum.snapcraft.io/t/papercuts-mouth-sized-bugs/228 to explain this | 15:05 |
| mvo | Chipaca: thank you! | 15:06 |
| jdstrand | niemeyer: ok, thanks | 15:06 |
| jdstrand | ah, ``` works in the forum too (thank goodness) | 15:06 |
| niemeyer | jdstrand: Thanks for reporting.. I'm interested as we're planning to migrate the list there pretty soon | 15:07 |
| Chipaca | also in the forum, hitting '?' gives you a list of keyboard shortcuts \o/ | 15:07 |
| zyga | niemeyer: thank you, I restarted tests | 15:07 |
| mvo | zyga: thanks! 3154 looks good now, looks like it needs a second review | 15:08 |
| zyga | yes! | 15:08 |
| mvo | Chipaca: woah, this is cool | 15:08 |
| zyga | I'd review it but that would be self-serving | 15:08 |
| Chipaca | mvo— ikr | 15:09 |
| jdstrand | niemeyer: fyi, https://forum.snapcraft.io/t/mailing-list-urls-have-appended-breaking-the-url-for-text-only-emails/231 | 15:10 |
| zyga | jdstrand: so meta that the key character is not in the actual URL | 15:11 |
| * zyga is starving | 15:11 | |
| mikeb_ | I'll ask my question in a different way... Given a snapcraft.yaml file with several daemons of different types (notify, simple, oneshot, forking) in the apps: section, is there an implicit ordering that is used to start up those daemons at install/boot time? | 15:14 |
| zyga | ogra_: can you review https://github.com/snapcore/core/pull/32 | 15:15 |
| mup | PR core#32: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32> | 15:15 |
| zyga | niemeyer: FYI ^ that's the rename on core snap itself | 15:15 |
| ogra_ | zyga, approved, want me to click the merge button ? | 15:17 |
| * ogra_ clicks | 15:18 | |
| Chipaca | mikeb_— there is no ordering | 15:19 |
| mup | PR core#32 closed: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <Merged by ogra1> <https://github.com/snapcore/core/pull/32> | 15:19 |
| niemeyer | zyga: Thanks, quick lunch first | 15:19 |
| Chipaca | mikeb_— I'll add this to the papercuts thread | 15:19 |
| zyga | ogra_: no, let's wait for gustavo's review please | 15:20 |
| ogra_ | zyga, bah, crap | 15:20 |
| ogra_ | well, i'll care for the rollback in case gustavo is unhappy with it | 15:21 |
| zyga | ogra_: OK | 15:22 |
| zyga | ogra_: no worries, I think it is okay | 15:22 |
| ogra_ | yeah, trivial enough | 15:22 |
| Chipaca | mikeb_— done | 15:22 |
| zyga | + first practical attempt at renaming plugs | 15:22 |
| kyrofa | mikeb_, do your daemon's save pid files? | 15:26 |
| mvo | ogra_: do you mind if I run a core build now that the plug rename has landed? | 15:29 |
| ogra_ | mvo, go ahead | 15:29 |
| mvo | ta | 15:29 |
| * zyga lunch | 15:32 | |
| zyga | (late) | 15:32 |
| mikeb_ | kyrofa: My daemons don't explictly save pid files - that should be handled by snapd or systemd I would think. | 15:32 |
| mikeb_ | Chpaca: I'm not familiar with the "papercuts" thread. | 15:33 |
| Chipaca | mikeb_— I mean, I made a note of this so we don't forget and get around to it eventually | 15:33 |
| Chipaca | mikeb_— is this blocking your work right now? | 15:34 |
| Chipaca | or can you live without it for a while? | 15:34 |
| mikeb_ | Chipaca: There does seem to be some ordering as several daemons were not started because one of my notify daemons didn't notify. | 15:35 |
| Chipaca | oh | 15:35 |
| Chipaca | After={{.MountUnit}} {{.PrerequisiteTarget}} | 15:35 |
| Chipaca | hah, i'm a muppet | 15:35 |
| Chipaca | davmor2— shut up | 15:35 |
| mikeb_ | Chipaca: semi-blocking. I have a nasty hack workaround that does an "end-around" around snappy. I'm trying to leverage as much of snappy's daemon functionality. | 15:36 |
| Chipaca | mikeb_— sorry, give me a bit to actually read the code instead of answering from memory | 15:36 |
| davmor2 | Chipaca: I didn't say a word but now you mention is that are similarities between you and animal | 15:37 |
| mikeb_ | Chipaca: I'm away for a couple hours. I'll check back then. Thanks. I'll also try to put together a demo snap to illustrate further. | 15:38 |
| Chipaca | mikeb_— ah, no, the After= is just for things like networking | 15:38 |
| Chipaca | mikeb_— that would be very useful | 15:38 |
| Chipaca | thanks! | 15:38 |
| morphis | zyga: ok, pushed https://github.com/snapcore/snapd/pull/3162 | 15:41 |
| mup | PR snapd#3162: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162> | 15:41 |
| morphis | zyga: can you comment on what still needs to be changed? | 15:42 |
| mup | PR snapd#3162 opened: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162> | 15:42 |
| zyga | morphis: thanks at lot! looking | 15:43 |
| zyga | morphis: let's see if the tests pass | 15:44 |
| * Pharaoh_Atem sighs | 15:44 | |
| zyga | morphis: at some point I'd like to rm -rf libtool autoconf and automake personally | 15:44 |
| Pharaoh_Atem | meson :) | 15:44 |
| zyga | I love them the same way 70 year old people love going to the doctor's | 15:44 |
| morphis | zyga: me too | 15:44 |
| Pharaoh_Atem | I feel the same way about golang :) | 15:45 |
| Pharaoh_Atem | I'm no fan of autotools either, though | 15:46 |
| zyga | Pharaoh_Atem: I honestly disagree though :) | 15:46 |
| * zyga looks at | 15:46 | |
| zyga | error: cannot install "test-snapd-python-webserver": Get | 15:46 |
| zyga | https://search.apps.ubuntu.com/api/v1/snaps/details/test-snapd-python-webserver?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2C | 15:46 |
| zyga | origin%2Cdeveloper_id%2Cprivate%2Cconfinement: net/http: request canceled (Client.Timeout exceeded while awaiting headers) | 15:46 |
| zyga | whaaat just happened here | 15:46 |
| Pharaoh_Atem | zyga: go code is fine, but everything else about go sucks | 15:46 |
| zyga | pstolowski: around? | 15:47 |
| pstolowski | zyga, yes | 15:47 |
| zyga | pstolowski: can you look at https://travis-ci.org/snapcore/snapd/builds/220592064 | 15:47 |
| zyga | pstolowski: save the logs if needed | 15:47 |
| zyga | pstolowski: I'd like to re-start it | 15:47 |
| zyga | pstolowski: not sure if that's something we should add to retry list | 15:47 |
| zyga | it seems linode has a bad hair day with networking | 15:48 |
| mup | PR snapcraft#1246 opened: Preparation work for collaboration support. Includes refactor of get/push_v… <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/1246> | 15:48 |
| zyga | pstolowski: tell me when ready | 15:49 |
| pstolowski | zyga, ok, saved a copy | 15:49 |
| zyga | pstolowski: thanks! | 15:49 |
| pstolowski | zyga, yes I think it makes sense to retry on those. in fact, we would retry on net.Timeout(), but apparently this doesn't fall into that error category | 15:49 |
| zyga | it would be nice to run qemu with special network that drops packets | 15:50 |
| zyga | to see how we faire | 15:50 |
| pstolowski | zyga, so perhaps again, some unwrapping is needed, or different error type check | 15:50 |
| zyga | pstolowski: seems like the most whack-a-mole bug ever BTW | 15:50 |
| zyga | pstolowski: whack-a-hydra | 15:50 |
| pstolowski | zyga, uhm | 15:50 |
| pstolowski | zyga, perhaps the shouldRetry() check should be totally reversed... e.g. don't retry only on well-known errors that shouldn't be retried. otherwise always retry | 15:52 |
| zyga | pstolowski: what would be the well-known errors? | 15:52 |
| zyga | Chipaca, pstolowski, pedronis: we need more reviews for 2.24 branches | 15:56 |
| Chipaca | yes! looking | 15:56 |
| Chipaca | zyga— 2.24 branches have grown! | 15:57 |
| zyga | can you please start with https://github.com/snapcore/snapd/pull/3154 | 15:57 |
| mup | PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154> | 15:57 |
| zyga | other branches will depend on it | 15:57 |
| Chipaca | snapd#3145 needs niemeyer's eyes | 15:57 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 15:58 |
| Chipaca | (as he marked it as needs-changing) | 15:58 |
| morphis | zyga: at least that patch gets us building on fedora again | 15:58 |
| zyga | yes | 15:58 |
| zyga | morphis: nice! | 15:58 |
| Chipaca | i already had reviewed 3154! | 15:58 |
| * Chipaca actually clicks the button now | 15:59 | |
| morphis | zyga: snap-update-ns was removed? | 15:59 |
| Chipaca | zyga— just needs to be green now | 15:59 |
| zyga | morphis: it wasn't finished, the C parts were removed, we're implementing it in go now | 16:00 |
| morphis | zyga: ah right, I remember looking at that PR from you | 16:01 |
| niemeyer | zyga: About #3145, a question: | 16:04 |
| zyga | niemeyer: yes | 16:05 |
| niemeyer | zyga: How do we get to that state given that we don't have plugs and slots with the same name anymore? | 16:05 |
| morphis | Pharaoh_Atem: Finish: rpmbuild snapd-2.24-4.fc25.src.rpm | 16:05 |
| pstolowski | zyga, i don't know. was just a crazy idea. | 16:05 |
| morphis | Pharaoh_Atem: so the last thing we need is https://github.com/snapcore/snapd/pull/3162 | 16:05 |
| mup | PR snapd#3162: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162> | 16:05 |
| pstolowski | zyga, but perhaps not a bad one | 16:05 |
| zyga | niemeyer: we get to that state because on core -> ubuntu-core transition the `network-bind` plug ends up disconnected as it has two suppliers (during the time core is installed) ubuntu-core and core | 16:06 |
| zyga | niemeyer: I added core-support there just in case I missed something, as it makes sense to ensure those two plugs are just always connected | 16:06 |
| zyga | niemeyer: does that answer your question? (not sure I inferred the "that state" part correctly) | 16:07 |
| niemeyer | zyga: At least I still don't get how we end up there | 16:07 |
| pstolowski | zyga, looking at 3160 | 16:07 |
| niemeyer | zyga: I thought we could only end up there as a consequence of having plug/slot with same name | 16:07 |
| niemeyer | zyga: We agreed to fix that so that never happens | 16:07 |
| zyga | niemeyer: no, that is not a factor in this case | 16:08 |
| zyga | niemeyer: it happens because the migration process installs core before removing ubuntu-core | 16:08 |
| zyga | niemeyer: ah, sorry, | 16:08 |
| zyga | niemeyer: let me think | 16:08 |
| zyga | niemeyer: I either swapped network-bind and core-support | 16:08 |
| zyga | niemeyer: or something else is at play | 16:08 |
| niemeyer | zyga: Yep, smells fishy | 16:08 |
| niemeyer | zyga: That method is handling a single snap and plug/slot name | 16:09 |
| zyga | niemeyer: thanks for the dilligence! | 16:09 |
| zyga | s/ll/l | 16:09 |
| zyga | niemeyer: what is interesting is that branch alone, without internal rename logic from other branches affects the spread test | 16:11 |
| zyga | niemeyer: let me review the code around that | 16:11 |
| niemeyer | zyga: Right, exactly.. because we have a plug and slot with the same name | 16:12 |
| niemeyer | zyga: So it's indeed duplicated | 16:12 |
| niemeyer | zyga: But when we fix that, which is the better approach, we shouldn't need it anymore | 16:12 |
| Pharaoh_Atem | morphis: snapd 2.24 hasn't been released yet, has it? | 16:12 |
| niemeyer | zyga: Exactly the sort of issue we discussed today in the standup.. fixing the invariant will unbreak this and potentially other things we're not even aware about yet | 16:12 |
| morphis | Pharaoh_Atem: it hasn't | 16:13 |
| morphis | Pharaoh_Atem: was just lazy in constructing the source archive name | 16:13 |
| Pharaoh_Atem | ah | 16:14 |
| pedronis | zyga: well auto connection is by interface, so core can auto-connect to core-support in both core and ubuntu-core | 16:15 |
| pedronis | if both snaps are installed (which indeed happens during transition) | 16:15 |
| zyga | pedronis: and then we do ... nothing, because we bail out if there's more than one candidate | 16:16 |
| pedronis | yes | 16:16 |
| pedronis | anyway either we don't have the connections, or we have misnamed connections, cannot have both | 16:16 |
| pedronis | for the same system | 16:16 |
| zyga | ogra_: did new core snap build already in edge? | 16:17 |
| ogra_ | zyga, yup | 16:17 |
| zyga | ogra_: we need to fix master snapd to let tests pass | 16:17 |
| zyga | one sec | 16:17 |
| ogra_ | zyga, ah, so you need a rebuild afterwards ? | 16:18 |
| ogra_ | NP, just ping me then | 16:18 |
| mup | PR snapd#3163 opened: tests: adjust to look for network-bind-plug <Created by zyga> <https://github.com/snapcore/snapd/pull/3163> | 16:19 |
| zyga | ogra_: https://github.com/snapcore/snapd/pull/3163 | 16:19 |
| mup | PR snapd#3163: tests: adjust to look for network-bind-plug <Created by zyga> <https://github.com/snapcore/snapd/pull/3163> | 16:19 |
| zyga | ogra_: we need this to land when the core snap with PR 32 is in ede | 16:20 |
| zyga | edge* | 16:20 |
| ogra_ | ok | 16:20 |
| ogra_ | well, the core snap is there | 16:20 |
| zyga | right | 16:20 |
| niemeyer | zyga: After you're done with your investigation, please let me know how you want to move forward | 16:25 |
| zyga | niemeyer: sure, now I need to take a break but we need to land https://github.com/snapcore/snapd/pull/3163 to unbreak master | 16:27 |
| mup | PR snapd#3163: tests: adjust to look for network-bind-plug <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3163> | 16:27 |
| zyga | niemeyer: I looked at transitionConnectionsCoreMigration for how the clash is affecting it | 16:29 |
| jdstrand | jjohansen: hey, could you look at my comment in https://forum.snapcraft.io/t/would-someone-create-an-electron-snap-for-this-forum/78/18 and let me know if this is the updated mmap mediation (ie, I need to adjust the policy for these denials to add 'm') | 16:29 |
| zyga | niemeyer: but TBH I don't see any impact | 16:29 |
| pedronis | well autoconnection doesn't look at names of plugs | 16:30 |
| niemeyer | zyga: Reviewed snapd#3153.. LGTM plus a suggestion on the wording | 16:30 |
| mup | PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153> | 16:30 |
| zyga | niemeyer: thanks looking | 16:30 |
| niemeyer | zyga: #3163 LGTM | 16:31 |
| pedronis | anyway 3145 is not related to the name duplication, it just intersects with it, still nor sure I like the special casing there though :/ | 16:33 |
| * zyga -> break and coffee | 16:34 | |
| jjohansen | jdstrand: likely bug 1658219 | 16:35 |
| mup | Bug #1658219: flock not mediated by 'k' <verification-done-xenial> <verification-done-yakkety> <AppArmor:In Progress by jjohansen> <linux (Ubuntu):Fix Released> <linux (Ubuntu Xenial):Triaged> <linux (Ubuntu Yakkety):Triaged> <https://launchpad.net/bugs/1658219> | 16:35 |
| zyga | once 3163 is green I'll merge it and merge master into open 2.24 branches to see what's wrong | 16:35 |
| zyga | and get back to the question niemeyer asked above, but so far back to puzzle mode | 16:35 |
| jdstrand | jjohansen: that was what I was thinking, but I wasn't sure of the status of the patches wrt 4.10.0-15.17-generic in zesty | 16:35 |
| zyga | (or maybe just tired / stressful day and didn't see something obvious) | 16:35 |
| jdstrand | jjohansen: I guess based on that bot response, zesty has the patches. it seems like the bug status was moving quite a bit so wanted to ask | 16:36 |
| jjohansen | jdstrand: it was not reverted in zesty | 16:36 |
| jdstrand | jjohansen: ah, ok, thanks. that makes it easier | 16:37 |
| * zyga afk | 16:39 | |
| ondra | roadmr can you please help NicolinoCuralli, he seems to have snap stacked in manual review stage. | 16:57 |
| ondra | roadmr can you please check what's the reason and if what steps are needed to unblock it | 16:58 |
| mup | PR snapcraft#1235 closed: store: API interactions for developer collaboration. <Created by psivaa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1235> | 17:00 |
| mvo | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/ppc64el/s/snapd/20170410_171526_28765@/log.gz has a test failure where even 40s worth of retries (search for "4 retries") we get no response - is linode in bad shape or our network? | 17:24 |
| zyga | hrm, loooots of network.Timeout errors | 17:24 |
| zyga | mvo: hey | 17:24 |
| zyga | mvo: I just opened my laptop (on the walk, yes, nuts people here) | 17:24 |
| zyga | mvo: I'm seeing the same thing | 17:24 |
| mvo | zyga: ha! I have a question in the forum for you soon | 17:24 |
| zyga | mvo: sure | 17:25 |
| mvo | zyga: so do you think its linode? or store? | 17:25 |
| zyga | mvo: that's interesting, I think linode | 17:26 |
| zyga | mvo: my reason is that I saw numerous SSL handshake errors while git clone on linode test setup | 17:27 |
| zyga | mvo: so there are two consistent places where networking is observed as flaky | 17:27 |
| zyga | mvo: but no measurements really | 17:27 |
| zyga | mvo: I'm in a fast-food restaurant as my kids dragged us here, I may use my spread key to run some silly network tests and see what works | 17:28 |
| zyga | mvo: but not sure how to do it | 17:28 |
| zyga | mvo: I was thinking about a hourly "health check" that git clones all the repos we care about | 17:28 |
| zyga | mvo: and asks the store for stuff | 17:28 |
| zyga | mvo: contains grep for retry counts | 17:28 |
| zyga | mvo: and git clone errors | 17:28 |
| zyga | mvo: and reports this somewhere | 17:29 |
| zyga | mvo: but again one of those things I probably never get to finish as I have no recent web konwledge to plot this anywhere | 17:29 |
| zyga | mvo: what was your question? | 17:31 |
| mvo | zyga: what was the remaining issue in the plug renaming ? you mentioned there was something new that came up? | 17:34 |
| zyga | mvo: aha | 17:35 |
| zyga | mvo: sorry, I was meaning to paste but then didn't | 17:35 |
| zyga | mvo: it was here on irc | 17:35 |
| zyga | mvo: do you have logs? | 17:35 |
| mvo | zyga: yeah, but some context is missing for some reason, is there a short summary? | 17:36 |
| zyga | mvo: starts with `18:04 < niemeyer> zyga: About #3145, a question: | 17:36 |
| zyga | mvo: I can pastebin that part of the log if you don't have a IRC logs | 17:36 |
| zyga | mvo: but | 17:36 |
| zyga | mvo: gustavo asked one fundamental question | 17:36 |
| ogra_ | https://irclogs.ubuntu.com/2017/04/10/%23snappy.html | 17:36 |
| zyga | mvo: network-bind was on old and new core (ubuntu core and core) | 17:36 |
| ogra_ | ;) | 17:36 |
| zyga | mvo: or wans't it? | 17:36 |
| mvo | zyga: correct | 17:36 |
| zyga | mvo: ok, so it should have been migrated | 17:37 |
| zyga | mvo: unless there old core didn't have the plug | 17:37 |
| zyga | then no connection and no migration (of connections) | 17:37 |
| ogra_ | old core didnt have a config hook | 17:37 |
| zyga | mvo: the question is this: is the transition bug affected by the clashing plugs we found later | 17:37 |
| ogra_ | that is ubuntu-core didnt | 17:37 |
| zyga | aaaah | 17:37 |
| zyga | ogra_: thanks! | 17:37 |
| ogra_ | :) | 17:37 |
| zyga | mvo: to finish that thought: so are we missing something | 17:37 |
| mvo | zyga: no plugs in ubuntu-core | 17:37 |
| zyga | mvo: (i.e. was there something else at play) | 17:38 |
| zyga | but if the network-bind *plug* (called just network-bind) was first on the new core snap (not ubuntu-core) | 17:38 |
| zyga | then everything broken is accounted for IMO | 17:38 |
| zyga | as it is just a new plug that has two auto-connect options | 17:38 |
| zyga | mvo: does that make sense? | 17:38 |
| zyga | darn so many network issues in linode now | 17:39 |
| zyga | does linode have a status page? | 17:40 |
| zyga | https://status.linode.com/ | 17:40 |
| zyga | all stuff operational | 17:40 |
| zyga | but I see red on PRs all around | 17:40 |
| mvo | zyga: hm, why do we have the bug in network-bind but not in core-support ? that transient correctly, no? | 17:40 |
| zyga | mvo: core-support is a new thing, old core did not provide it | 17:41 |
| zyga | mvo: and also, maybe, no tests for that | 17:41 |
| * zyga checks | 17:41 | |
| mvo | zyga: its something added via snap/implicit.go | 17:41 |
| zyga | mvo: no tests for core-support | 17:42 |
| zyga | mvo: I mean, no spread test | 17:42 |
| mvo | zyga: to see if the transition for that works? | 17:42 |
| zyga | mvo: checks for anything related to core-support | 17:42 |
| zyga | mvo: anything, just grep is empty | 17:42 |
| zyga | mvo: so if it is connected or not, we don't know | 17:42 |
| zyga | mvo: but since it's not in old ubuntu-core I suspect it's not affected | 17:42 |
| zyga | mvo: and this whole rabbit hole started because federico pointed out a failing test in some other repo | 17:43 |
| mvo | zyga: what does "its not in old ubuntu-core" mean? | 17:43 |
| zyga | mvo: and we started pulling | 17:43 |
| zyga | mvo: the "core-support" slot is not provided by "ubuntu-core" | 17:43 |
| zyga | mvo: so when "core" is installed it is connected normally as there's one provider, the new core itself | 17:43 |
| zyga | mvo: if anything I'm saying is fishy please shout, I really want to make sure we've got tihs | 17:44 |
| mvo | zyga: core-support is only added via implict.go and those are added to both ubuntu-core and core, no? | 17:44 |
| zyga | and this release is uneventful | 17:44 |
| zyga | mvo: was it added by snapd that is present in ubuntu-core? | 17:45 |
| zyga | mvo: aaha | 17:45 |
| zyga | mvo: classic | 17:45 |
| mvo | zyga: yeah :) I'm just trying to understand it better | 17:45 |
| * zyga wonders | 17:45 | |
| zyga | mvo: so my theory is that | 17:45 |
| zyga | mvo: because ubuntu-core is old | 17:45 |
| zyga | mvo: there'd be no core-support interface there | 17:45 |
| zyga | mvo: and even if, no test is measuring that | 17:45 |
| ogra_ | it was also never added to the snapcraft.yaml in ubuntu-core ... | 17:46 |
| mvo | zyga: I add the test now :) | 17:46 |
| zyga | mvo: so we only noticed because network-bind was measured via spread | 17:46 |
| zyga | ogra_: yes, because it's implicit | 17:46 |
| ogra_ | ah, right | 17:46 |
| zyga | ogra_: implicit is very tricky, some only get added depending on os-release | 17:46 |
| zyga | mvo: thank you! | 17:46 |
| ogra_ | yeah | 17:46 |
| mvo | zyga: whats strange is that the code that can do the transition also knows about the implicit core-support so when that code runs ubuntu-core should have core-support | 17:46 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/3159 is green in travis and 2/4 adt passed | 17:46 |
| mup | PR snapd#3159: store: retry once on hashsum mismatches in a Download() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3159> | 17:46 |
| mvo | zyga: but yeah, let me add core support | 17:46 |
| zyga | mvo: rest are timeouts | 17:47 |
| zyga | mvo: ack/nack? | 17:47 |
| ogra_ | mvo, but that would only be true if someone actually released an ubuntu-core after the ocde was added ... did we release new ubuntu-core since ? | 17:47 |
| mvo | zyga: it needs review, we need to decide if we want to do one retry unconditionally (thats what the branch is doing) or doing it *only* if we had partial content in a previous retry | 17:47 |
| zyga | mvo: ohhh, sorry, | 17:48 |
| mvo | ogra_: yes, we have to. otherwise we don't transition | 17:48 |
| * zyga was watching wrong PR | 17:48 | |
| ogra_ | (i mean, unless someone uses ubuntu-core from edge ) | 17:48 |
| zyga | mvo: I meant >https://github.com/snapcore/snapd/pull/3163 | 17:48 |
| mup | PR snapd#3163: tests: adjust to look for network-bind-plug <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3163> | 17:48 |
| zyga | 3 failures, travis green | 17:48 |
| mup | PR snapd#3163 closed: tests: adjust to look for network-bind-plug <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3163> | 17:49 |
| mvo | ogra_: if you use ubuntu-core ages old then things don't transition. or only if you updated the deb but never did a successful snap refresh that pulls in a new ubuntu-core which is possible but would be strange | 17:49 |
| zyga | mvo: all network related | 17:49 |
| zyga | as in timeout | 17:49 |
| mvo | zyga: +1 | 17:49 |
| zyga | not network-bind :) | 17:49 |
| zyga | thanks! | 17:49 |
| zyga | I'll merge this into other PRs now | 17:49 |
| mvo | ta | 17:49 |
| mvo | zyga: test is running now (about connected core) | 17:50 |
| mvo | zyga: eh connected core-support | 17:50 |
| mvo | zyga: I still wonder if we should merge network-bind into core-support but I don't think it buys anything and also we need to understand why network-bind acts like it acts and core-support (maybe) dosn't - or maybe it does | 17:51 |
| ogra_ | we really need to become more creative with our naming | 17:51 |
| ogra_ | core and classic are both so overused everywhere now | 17:51 |
| zyga | mvo: we can next time | 17:53 |
| zyga | mvo: I think we need to re-think core plugs | 17:53 |
| mvo | zyga: yes, after the fire. sorry for pushing out the distraction | 17:53 |
| ogra_ | i dont see why we need confinement at all for it | 17:53 |
| ogra_ | given we are in full control of the hook it could well be unconfined | 17:54 |
| zyga | mvo: no worries, I think it's a valid way out of the problem | 17:54 |
| zyga | mvo: kill all those plugs | 17:54 |
| zyga | mvo: and make the connection implicit | 17:54 |
| zyga | well | 17:54 |
| zyga | not connection, permissions | 17:54 |
| zyga | *maybe* | 17:54 |
| zyga | it's something to discuss | 17:54 |
| mvo | zyga: test for core-support works, trying network-bind now | 17:56 |
| zyga | mvo: all 2.24 PRs restarted | 17:59 |
| mvo | ta | 18:00 |
| zyga | mvo: I didn't reply to comments on https://github.com/snapcore/snapd/pull/3145 yet | 18:00 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 18:00 |
| zyga | mvo: I need to reply to niemeyer about his questoin | 18:00 |
| zyga | but I need to move now (family) | 18:01 |
| zyga | can you take that please? | 18:01 |
| zyga | niemeyer: I think, based on my understanding and discussion with ogra and mvo, that the name clashes are not a factor in core transition | 18:01 |
| zyga | I wish I had irssi on screen now | 18:01 |
| mvo | zyga: I don't see open comments in there | 18:02 |
| mvo | zyga: happy to reply of course | 18:02 |
| mvo | zyga: once I know where to :) | 18:02 |
| mvo | zyga: but go if your family needs you | 18:02 |
| mikeb_ | Chipaca: Snappy daemonization issues part 1. https://github.com/mabnhdev/snappy-daemon-demo - See the README file. | 18:02 |
| zyga | mvo: refreshing | 18:02 |
| zyga | maybe stale page | 18:02 |
| cachio | sergiusens, I am creating a dashboard with some kpi for ubuntu core, I thought perhaps we can do the same for snapcraft | 18:02 |
| cachio | sergiusens, the idea would be to detect any regression just looking at the dashboard | 18:03 |
| cachio | sergiusens, it is the current one for snap core https://platform-qa-dashboard.canonical.com/dashboard/db/kpi-ubuntu-core-dashboard?editorTab=Metrics | 18:04 |
| zyga | mvo: walking with open laptop, I see questions from pedronis that I have to answer | 18:04 |
| cachio | sergiusens, any suggestion? what do you thing about that? | 18:04 |
| mvo | zyga: yeah, I can look at those | 18:05 |
| cachio | sergiusens, it is being executed in real hardware | 18:06 |
| pedronis | mvo: zyga: yes, agreed the name clash is not the factor there, I think having just a forum topic for both issues (named after only one) has probably confused things | 18:07 |
| zyga | pedronis: yes, it was started with this, but I do think those are separate two problems | 18:08 |
| zyga | pedronis: thank you for your input! | 18:08 |
| Erix | hi | 18:08 |
| Erix | is this the right place to ask a question about ubuntu nextcloud snap help? | 18:08 |
| pedronis | mvo: I had no blocker question, the issue is mostly understand what those branches do all together, one of my question is that it seems at least two of the fixes will never need to be done together which is good, but part of that understanding | 18:08 |
| mvo | pedronis: I think we don't understand the issue yet tbh | 18:09 |
| pedronis | mvo: which one? :) | 18:09 |
| mvo | zyga: so I added a test that ensures that things are connected - core-support is connected, network-bind is not. this is with the new network-bind-plug | 18:09 |
| mvo | pedronis: the transition issue | 18:09 |
| pedronis | well we install core while ubuntu-core is present | 18:10 |
| pedronis | no? | 18:10 |
| mvo | pedronis: yes | 18:10 |
| zyga | mvo: this matches an existing test that has the same expectation and outcome | 18:10 |
| pedronis | at least autoconnect will not work in that case | 18:10 |
| zyga | mvo: just runs nightly | 18:10 |
| mvo | pedronis: why does it work for core-support ? | 18:10 |
| zyga | feerico has it someqhere | 18:10 |
| pedronis | mvo: does the old ubuntu-core has a core-support plug? | 18:10 |
| pedronis | sorry | 18:10 |
| pedronis | slot? | 18:10 |
| mvo | pedronis: its added via snap/implicit.go for anything that is an OS | 18:11 |
| mvo | pedronis: so I would say yes | 18:11 |
| mvo | pedronis: this is the part that confuses me | 18:11 |
| pedronis | mvo: well, added when? | 18:11 |
| zyga | pedronis: in ifacestate | 18:11 |
| pedronis | mvo: if you have something where you can run this through I would recommend adding logging in the autoconnect bits | 18:11 |
| mvo | pedronis: its added in 6 places or so | 18:12 |
| === bregma__ is now known as bregma | ||
| pedronis | mvo: yea | 18:12 |
| mvo | pedronis: yeah, I add logging | 18:12 |
| pedronis | mvo: notice that sometimes it depends if info comes from repo | 18:13 |
| pedronis | or from snapmanager | 18:13 |
| mvo | pedronis: but still strange, one would assume that when both core-support and network-bind are added via implicit.go either both get connected or none, but not one and and not the other | 18:13 |
| pedronis | snapmanager is not so good at adding implicit slots | 18:13 |
| pedronis | mvo: well, no | 18:13 |
| pedronis | mvo: there's another factor the snap declaration | 18:14 |
| pedronis | possibly | 18:14 |
| mvo | pedronis: ohhhhh | 18:14 |
| zyga | mvo: that is how auto connect works | 18:14 |
| pedronis | network-bind is autoconnect for everything, no? | 18:14 |
| pedronis | core-support I need to recheck what we did exactly | 18:15 |
| sergiusens | cachio: you will want to talk to elopio, we have something similar going on | 18:15 |
| mup | PR snapd#3158 closed: store: add download test with EOF in the middle <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3158> | 18:15 |
| sergiusens | bring it up on the forums or rocket | 18:15 |
| zyga | pedronis: no, same behavior but we only tested it and noticed | 18:15 |
| mvo | sergiusens: yeah, I think thats exactly it, core-support has only a single candidate | 18:15 |
| pedronis | zyga: ? | 18:16 |
| zyga | 20:14 < pedronis> network-bind is autoconnect for everything, no? | 18:16 |
| pedronis | zyga: I mean the declarations doesn't block autoconnect for network-bind | 18:16 |
| mvo | pedronis: hm, maybe not - basedeclartion allows plug-snap-type: core so both core and ubuntu-core should be allowed(?= | 18:16 |
| zyga | right | 18:16 |
| * mvo needs to step out for a little bit | 18:17 | |
| pedronis | mvo: I'm looking, that stuff is confusing | 18:17 |
| * zyga didnt think about assertions | 18:17 | |
| mvo | pedronis: indeed | 18:17 |
| pedronis | mvo: it says deny-auto-connection: true | 18:17 |
| mup | PR snapd#3164 opened: tests: ensure network-bind and core-support are connected <Created by mvo5> <https://github.com/snapcore/snapd/pull/3164> | 18:18 |
| pedronis | so it's back to the snap-declarations | 18:18 |
| pedronis | let me look at those | 18:18 |
| mvo | zyga, pedronis: the above PR should be good to test that our fix actually works | 18:18 |
| mvo | (and it looks like it does not, i.e. we need to figure the root cause still and not just fixup on the next run :/) | 18:19 |
| sergiusens | mvo: not for me I guess | 18:20 |
| zyga | hmmm | 18:20 |
| zyga | mvo: what makes you say so? | 18:20 |
| pedronis | mvo: zyga: so the sna-declaration of both core and ubuntu-core will not let core-support connect | 18:20 |
| pedronis | well auto-connect | 18:21 |
| pedronis | bit wondering how it works at all | 18:21 |
| zyga | store assertion? | 18:21 |
| zyga | on core | 18:21 |
| pedronis | yes, store assertion | 18:21 |
| pedronis | on both | 18:21 |
| pedronis | the base declaration just says deny-auto-connection: true | 18:22 |
| pedronis | so they cannot auto-connect, not sure how the configure hook works now | 18:22 |
| pedronis | but the fact is not interfaces is kind of expected | 18:22 |
| zyga | mvo: sorry to nag but I want to make sure I'm not missing anything, what makes you say that we've still haven't gotten to the bottom of it and tests confirm that | 18:22 |
| pedronis | given that, transition or not | 18:22 |
| pedronis | ah, no | 18:23 |
| pedronis | confusing | 18:23 |
| zyga | pedronis: I'm trying to parse two previous lines | 18:23 |
| zyga | pedronis: cna you re-phrase that | 18:23 |
| pedronis | zyga: sorry | 18:24 |
| zyga | sorry, just tired and really want to understand what's going on here precisely | 18:24 |
| pedronis | zyga: so network-bind doesn't autoconnect? but core-support does? or is that the reverse? | 18:24 |
| zyga | pedronis: network-bind does auto-connect AFAIR, let me check | 18:24 |
| zyga | core-support doesn't autoconnect | 18:24 |
| zyga | ah, super confusing | 18:24 |
| zyga | sorry | 18:24 |
| zyga | we don't know if core-support connects in practice | 18:25 |
| zyga | my two statements were "obvious" intents but not facts | 18:25 |
| zyga | network-bind did not connect according to a test that fgimenez ran | 18:25 |
| pedronis | at least the declarations now that I read them carefully should let them both autoconnect | 18:25 |
| zyga | pedronis: yes, that is certainly the intent | 18:25 |
| zyga | pedronis: that both plugs connect to core and perhaps to ubuntu-core as well (not sure) | 18:25 |
| pedronis | though only os snaps can have core-support plugs or slots | 18:26 |
| zyga | pedronis: what was measured is that ubuntu-core -> core transition started failing in nightly tests where the network-bind *plug* was not connected | 18:26 |
| zyga | pedronis: and at the time we didn't check core-support *plug* | 18:26 |
| pedronis | well, unless the slots are added differently they should behave similarly afaict (at least for the os snap) | 18:27 |
| mvo | zyga: sorry for being confusing. so https://github.com/snapcore/snapd/pull/3164/files#diff-23e6c1e2bbf5a1a24798303971f19b99R83 works | 18:27 |
| mup | PR snapd#3164: tests: ensure network-bind and core-support are connected <Created by mvo5> <https://github.com/snapcore/snapd/pull/3164> | 18:27 |
| mvo | zyga: however the line below does not | 18:27 |
| mvo | zyga: so core-support appears to be fine and connected but network-bind is not | 18:28 |
| zyga | mvo: so line 83 works and line 84 doesn't work? | 18:28 |
| mvo | zyga: correct | 18:28 |
| pedronis | there is no difference between them though | 18:29 |
| zyga | mvo: can you show me the debug output, do you have snap interfaces there? | 18:29 |
| mvo | zyga: sure, one sec | 18:29 |
| zyga | pedronis: maybe, do we auto-add "core-support" to ubuntu-core too? | 18:29 |
| zyga | pedronis: if so, yes, I agree | 18:29 |
| mvo | zyga: http://paste.ubuntu.com/24356000/ | 18:29 |
| zyga | also not sure how this test works | 18:29 |
| zyga | which snapd is used while ubuntu-core is installed? | 18:30 |
| zyga | some ancient one | 18:30 |
| zyga | or master? | 18:30 |
| pedronis | the question is about the slots | 18:30 |
| zyga | `:core-support core:core-support-plug` | 18:30 |
| mvo | zyga: this is pretty recent master | 18:30 |
| zyga | so it's connected | 18:30 |
| pedronis | so yes, they should be added the same way | 18:30 |
| zyga | pedronis: interesting | 18:30 |
| zyga | walking home | 18:30 |
| zyga | 10 min | 18:31 |
| mvo | zyga: the full log, sorry its huge http://paste.ubuntu.com/24356011/ | 18:31 |
| zyga | thnx | 18:32 |
| mvo | zyga, pedronis: sorry, really need to step out for some minutes now | 18:32 |
| mvo | zyga, pedronis: but please keep me updated, bbiab | 18:32 |
| pedronis | zyga: ah, but now we check both sides, plug to slots and slots to plugs | 18:36 |
| pedronis | for autoconnect | 18:36 |
| zyga | yes | 18:38 |
| zyga | for some time | 18:38 |
| pedronis | so slots we know they both have both, because we add them | 18:38 |
| pedronis | but plugs, I don't know | 18:38 |
| pedronis | I mean slots are added implicitly | 18:39 |
| zyga | pedronis: ubuntu-core snap has neither plugs | 18:39 |
| zyga | pedronis: we don't add implicit plugs | 18:39 |
| pedronis | does the ubuntu-core we use has a core-support plug? | 18:39 |
| zyga | re, sorry, wifi connected and n-m bugs galore | 18:40 |
| zyga | 20:39 < zyga> pedronis: ubuntu-core snap has neither plugs | 18:40 |
| zyga | 20:39 < zyga> pedronis: we don't add implicit plugs | 18:40 |
| zyga | pedronis: that's what I said / saw last | 18:40 |
| pedronis | no plug ? | 18:40 |
| pedronis | that would provoke the reverse problem | 18:41 |
| pedronis | I mean if it has no plug then we are back that the two should be symmetric | 18:42 |
| zyga | pedronis: ubuntu-core does not have network-bind plug or core-support plug | 18:42 |
| zyga | pedronis: only core has those | 18:42 |
| zyga | pedronis: yes, I think something is fishy still | 18:43 |
| pedronis | then when we try to connect from slots they should both work? | 18:43 |
| zyga | pedronis: I just got home, setting up to dig | 18:43 |
| zyga | pedronis: no, because the plug on core has two candidates again, core and ubuntu-core | 18:43 |
| zyga | pedronis: because slots are added, even to ubuntu core | 18:43 |
| pedronis | zyga: we try from both sides | 18:43 |
| zyga | pedronis: yes | 18:43 |
| zyga | pedronis: maybe I misunderstand your point | 18:43 |
| pedronis | zyga: so when we try on core from slots | 18:44 |
| pedronis | it doesn't matter how many slots there | 18:44 |
| pedronis | are | 18:44 |
| pedronis | only plugs | 18:44 |
| zyga | pedronis: aha, let me see | 18:44 |
| pedronis | but then as I said | 18:44 |
| pedronis | I still don't understand why those two don't work the same | 18:44 |
| zyga | pedronis: in both auto-connect "sides" (plug/slots) we don't connect if more than one viable candidate; so yes, fishy | 18:47 |
| pedronis | yes, so the from plug side is expected to fail | 18:47 |
| zyga | pedronis: but looking at it I also found: // Suggested connection already exist so don't clobber it. | 18:47 |
| pedronis | because two slots | 18:47 |
| zyga | pedronis: so maybe the clashing names have some impact | 18:47 |
| pedronis | but the from slots, don't understand why one works and the other not | 18:47 |
| zyga | we check if a conn state exists | 18:48 |
| zyga | and | 18:48 |
| zyga | if by that time we migrate ubuntu-core to core | 18:48 |
| zyga | maybe something weird happens | 18:48 |
| zyga | like core:network-bind core:network-bind | 18:48 |
| zyga | so we don't connect it from that side now | 18:48 |
| zyga | plausible? | 18:48 |
| zyga | (that would explain why rename of plug might fix it) | 18:48 |
| zyga | or would it, mmmmmm | 18:49 |
| zyga | well, tired | 18:49 |
| * zyga looks for errors in that code | 18:49 | |
| zyga | maybe something swapped | 18:49 |
| pedronis | anyway indeed ubuntu-core has neither plug | 18:49 |
| pedronis | at least at stable | 18:49 |
| zyga | pedronis: yes but remember our tests do magic repacking so maybe we're missing something non-obvious there | 18:50 |
| zyga | pedronis: I'd like to see a old-snapd update to new-snapd without any magic | 18:50 |
| pedronis | we have a different bug it seems snap download now defaults to edge ??? | 18:51 |
| zyga | pedronis: what is in the snap declaration for ubuntu-core | 18:53 |
| zyga | pedronis: or how can I see that with snap known | 18:53 |
| pedronis | there is nothing interesting in the snap declarations | 18:53 |
| pedronis | for both core or ubuntu-core | 18:53 |
| zyga | pedronis: no? what about assertions? | 18:53 |
| pedronis | ? | 18:53 |
| zyga | pedronis: newAutoConnectChecker | 18:53 |
| pedronis | I mean they don't have any plugs or slots bits | 18:53 |
| zyga | aha | 18:53 |
| pedronis | all it matters is the base declaration | 18:54 |
| pedronis | afaict | 18:54 |
| zyga | pedronis: so how do we let core-support connect, via base? | 18:54 |
| * zyga looks | 18:54 | |
| pedronis | it's confusing | 18:54 |
| pedronis | but the only control we do is really that core-support plugs and slots can only be on os | 18:54 |
| pedronis | nothing else | 18:54 |
| zyga | plug-snap-type: | 18:54 |
| zyga | - core | 18:54 |
| zyga | we have no "core" type, we have "os" | 18:54 |
| zyga | is that just a discrepancy? | 18:54 |
| pedronis | yes core==os | 18:54 |
| zyga | ok | 18:54 |
| pedronis | TypeOS is still the internal name | 18:55 |
| pedronis | but core is what is used in the decls | 18:55 |
| ogra_ | to make it less confusing ? :) | 18:55 |
| zyga | ogra_: decls are public | 18:59 |
| zyga | ogra_: we can fix the core code without anyone noticing | 18:59 |
| ogra_ | well, the snapcraft.yaml uses type: os :) | 18:59 |
| zyga | ogra_: I think we wanted to wait with that as it is old stuff | 19:00 |
| ogra_ | so in other code i'd also expect to find "os" when something is called "type" | 19:00 |
| zyga | ogra_: old == existing | 19:00 |
| zyga | ogra_: and declarations were new | 19:00 |
| ogra_ | heh | 19:00 |
| zyga | ogra_: so we added the right language | 19:00 |
| zyga | ogra_: we'll correct core's snap.yaml in due time | 19:01 |
| ogra_ | k | 19:01 |
| zyga | ok, with https://github.com/snapcore/snapd/pull/3164 I can test a few theories | 19:01 |
| mup | PR snapd#3164: tests: ensure network-bind and core-support are connected <Created by mvo5> <https://github.com/snapcore/snapd/pull/3164> | 19:01 |
| zyga | give me 15 minutes, let's see | 19:01 |
| zyga | ok, test in progress | 19:10 |
| zyga | I will have some useful data in 15 minutes | 19:11 |
| zyga | when spread finishes | 19:11 |
| zyga | hmm | 19:15 |
| zyga | dh_install: snapd missing files: usr/bin/snap-update-ns | 19:15 |
| zyga | what happened there? | 19:15 |
| ogra_ | missed a git add ? | 19:15 |
| zyga | no | 19:15 |
| zyga | it was removed | 19:15 |
| zyga | something resurrected that line | 19:15 |
| * zyga looks | 19:15 | |
| zyga | I see | 19:16 |
| zyga | `-usr/lib/snapd/snap-update-ns | 19:16 |
| zyga | ok, I must be missing something | 19:16 |
| zyga | aha | 19:16 |
| zyga | -resend | 19:16 |
| ogra_ | debian/snapd.install | 19:16 |
| zyga | sorry | 19:16 |
| ogra_ | i see it in there | 19:16 |
| zyga | ogra_: what do you see? | 19:17 |
| ogra_ | look in debian/snapd.install | 19:17 |
| zyga | ogra_: can you paste the line | 19:17 |
| zyga | ogra_: running out of ram... | 19:17 |
| ogra_ | there is a line for it | 19:17 |
| zyga | gah | 19:17 |
| ogra_ | usr/bin/snap-update-ns /usr/lib/snapd/ | 19:17 |
| zyga | ogra_: there is one but is is different than mine? | 19:17 |
| zyga | that's the *correct* line | 19:17 |
| zyga | it's installed from usr/bin because it's a go binary now | 19:17 |
| zyga | I just restarted spread | 19:17 |
| ogra_ | oh, i missed the "lib" | 19:18 |
| zyga | the lib is ok too, not changed | 19:18 |
| zyga | anyway, checking again | 19:18 |
| zyga | I think it was missing -resend | 19:18 |
| niemeyer | zyga, mvo: I think I reviewed the critical things.. am I missing something still? What's the outcome of the prior conversation on the de-dup of adding plugs/slots? | 19:25 |
| * zyga has logs and reviews them now | 19:25 | |
| zyga | niemeyer: we are pursuing one thread that we still don't understand wrt why network-bind is affected but core-support is not | 19:26 |
| zyga | niemeyer: I added something that may help us to understand to logs, reading them now | 19:26 |
| zyga | niemeyer: mvo posted a PR 3164 that shows the failure on vanilla master | 19:27 |
| zyga | niemeyer: no other updates yet | 19:27 |
| tvoss | niemeyer: how do you propose to revert the state of the current branch? just start over and cherry pick commits? | 19:28 |
| mvo | zyga: here is an interessting though - network-bind is used in the tests in both test-snapd-python-webserver and also in core, if I remove test-snapd-python-webserver things seem to work | 19:28 |
| mvo | zyga: I'm double checking that now | 19:29 |
| niemeyer | zyga: Ok | 19:29 |
| niemeyer | tvoss: Need some more context | 19:29 |
| tvoss | niemeyer: for the changes to device key creation | 19:30 |
| mvo | niemeyer: we want to get to the bottom of this just to be sure we don't overlook another problem, its a bit thorny right now | 19:30 |
| cachio | niemeyer, I have created this dashboard with tome kpis for ubuntu core, https://platform-qa-dashboard.canonical.com/dashboard/db/kpi-ubuntu-core-dashboard | 19:31 |
| mvo | zyga: yes, so with test-snapd-python-webserver -> core gets no network-bind. without anything in network-bind: things work | 19:32 |
| cachio | niemeyer, just tell me if you are insterested to see other metrics on there | 19:32 |
| niemeyer | cachio: Oh, nice, let me check it out | 19:32 |
| cachio | niemeyer, all those metrics are obtained from executions on real hardware | 19:32 |
| mup | Bug #1681547 opened: Gnome3 on Ubuntu 17.04 doesn't find snap desktop files <Snappy:New> <https://launchpad.net/bugs/1681547> | 19:33 |
| cachio | niemeyer, any sugestion is welcome | 19:33 |
| zyga | mvo: interesting | 19:33 |
| zyga | mvo: I tweaked logs to be shorter and am trying again | 19:33 |
| cachio | niemeyer, the idea is to detect any performance regression, but we could any other metric | 19:34 |
| niemeyer | cachio: It would be nice to hook that up with our existing test suite | 19:34 |
| niemeyer | cachio: The spread tests specifically | 19:35 |
| cachio | niemeyer, we are working on that | 19:35 |
| niemeyer | cachio: Ah, that's great then | 19:35 |
| niemeyer | In theory that should cover most of the interactions | 19:35 |
| cachio | niemeyer, I have created a change request in spread to export xunit format | 19:35 |
| cachio | niemeyer, once we have that, then we can show test results and a lot metrics on grafana too | 19:36 |
| zyga | mvo: interesting, any theory why? | 19:36 |
| niemeyer | cachio: That's probably not coming, but you can use the format used to display timings in Travis to easily pick up the running time | 19:36 |
| mvo | zyga: no idea right now, just a piece in the puzzle | 19:37 |
| niemeyer | cachio: Ah, wait.. you mean you already did it, let me chcek | 19:37 |
| cachio | niemeyer, https://github.com/snapcore/spread/pull/25/files | 19:38 |
| mup | PR spread#25: Adding capability to write xunit report with the task suites and results <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/25> | 19:38 |
| cachio | niemeyer, well the original idea was to run spread tests in real hardware and report results and performance times to grafana | 19:38 |
| cachio | niemeyer, we are close to that | 19:39 |
| mup | PR snapcraft#1247 opened: Fixing Store integration tests <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1247> | 19:39 |
| pedronis | zyga: because then the slots side doesn't work either, because there are two plugs in the system now | 19:40 |
| pedronis | zyga: working from the plug side is more natural for autoconnect | 19:40 |
| zyga | pedronis: ! | 19:40 |
| zyga | pedronis: aha, yes | 19:40 |
| pedronis | here the slots side almost saves us | 19:40 |
| zyga | pedronis: it also means our slot auto-connect is a bit wonky | 19:40 |
| pedronis | but not if something else needs network-bind | 19:40 |
| zyga | pedronis: it should connect all candidates if that's possible (all plugs) | 19:40 |
| pedronis | yes, it doesn't make a lot of sense I suppose | 19:41 |
| pedronis | but not sure | 19:41 |
| pedronis | anyway | 19:41 |
| pedronis | now things make a bit of sense | 19:41 |
| zyga | pedronis: thank you, this is a very good input, | 19:41 |
| zyga | mvo: ^ I think it makes sense, and it matches what we observe | 19:42 |
| zyga | mvo: I added logs for this, will know ... now | 19:42 |
| * zyga reads | 19:42 | |
| pedronis | zyga: auto-connecting looking from the plugs on core doesn't work because we have core and ubuntu-core we the same implicit slots | 19:43 |
| pedronis | zyga: auto-connection from core core-support slot work because there's only core plug (ubuntu-core doesn't have the plug) | 19:43 |
| pedronis | zyga: network-bind isn't so lucky because from the slot side we observe both the core plug but also any other snap using network-bind plug | 19:44 |
| pedronis | this also indeed shows that the new auto-connect logic we added from the slot side doesn't make complete sense | 19:45 |
| pedronis | bit too tired to think how exactly it should work though | 19:45 |
| * zyga hugs pedronis brilliance! thanks for solving it | 19:45 | |
| * mvo hugs pedronis as well | 19:48 | |
| zyga | ok, restarted tests to just capture the smoking gun log | 19:49 |
| zyga | niemeyer: if that holds, what do you want us to do? | 19:49 |
| zyga | niemeyer: it seems there's another bug where slot-side auto-connection is just silly and needs re-thinking | 19:49 |
| zyga | niemeyer: and we now noticed | 19:49 |
| pedronis | zyga: when we connect from the slot side I suppose the question is not whether there just on matching plug, but whether there are no other snaps with a slot that would connect witht the same plugs as us | 19:50 |
| zyga | pedronis: I think we may want to limit that to content if there's no connection | 19:50 |
| zyga | pedronis: and nothing else maybe | 19:50 |
| zyga | pedronis: (except core perhaps) | 19:50 |
| zyga | pedronis: then re-think | 19:50 |
| pedronis | so just find candidate plugs | 19:51 |
| pedronis | and then reapply the logic from the other side | 19:51 |
| pedronis | and see if we are the winner | 19:51 |
| zyga | mmm | 19:51 |
| pedronis | anyway not a quick fix for 2.24 | 19:52 |
| zyga | yes, I think so too | 19:52 |
| zyga | mvo: tell me what you want to do now | 19:52 |
| pedronis | it just seems that only network-bind plug has the problem we thought both had on core | 19:53 |
| zyga | mvo: yes | 19:53 |
| zyga | er | 19:53 |
| zyga | pedronis: yes | 19:53 |
| niemeyer | Folks, these conversations are much better held in the forum. | 19:54 |
| niemeyer | The scroll will soon be over everybody's screens and those conversations will be lost. | 19:54 |
| zyga | niemeyer: agreed | 19:54 |
| pedronis | niemeyer: I understand but I don't see other solution that copying the result, thinking on the spot through the forum doesn't work for me | 19:55 |
| niemeyer | zyga: I don't know what "that holding" means, for related reasons | 19:55 |
| mvo | zyga: what I want to do :) ? fold network-bind into core support, release 2.24 and fix all the other stuff in 2.25 - but I'm not sure that is feasible | 19:55 |
| niemeyer | pedronis: It's just a different window where you can type the same message. :) | 19:55 |
| pedronis | I suspect that is not so simple (there are empires built on that :) ) | 19:56 |
| pedronis | anyway we don't even have a topic yet about *this* problem | 19:57 |
| pedronis | not the other one | 19:57 |
| niemeyer | pedronis: Yeah, to be clear I'm mainly pointing out I see important conversations scrolling over | 19:57 |
| niemeyer | pedronis: We sort of do.. https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/22 | 19:58 |
| pedronis | that's not this problem | 19:58 |
| niemeyer | pedronis: This is where we're discussing the problems related to network-bind and core-support | 19:58 |
| pedronis | is not about names of plug at alls this one | 19:58 |
| ogra_ | thats rather a new topic ... about auto connection | 19:58 |
| pedronis | yes | 19:59 |
| zyga | pedronis: 2017-04-10T21:57:11+02:00 INFO cannot auto connect {core network-bind-plug} (plug auto-connection), candidates found: "core:network-bind,ubuntu-core:network-bind" | 19:59 |
| niemeyer | mvo: Do we understand the issue of why one works and the other doesn't by now? | 19:59 |
| zyga | pedronis: 2017-04-10T21:57:11+02:00 INFO cannot auto connect {core network-bind} (slot auto-connection), candidates found: "core:network-bind-plug,test-snapd-python-webserver:network-bind" | 20:00 |
| zyga | pedronis: so you were totally right | 20:00 |
| pedronis | niemeyer: yes | 20:00 |
| zyga | mvo: ^ | 20:00 |
| zyga | niemeyer: yes, I think we do | 20:00 |
| stokachu | did the ability to install from --edge disappear? | 20:00 |
| ogra_ | nope | 20:00 |
| pedronis | no | 20:00 |
| * ogra_ does it ever day | 20:00 | |
| stokachu | snap info conjure-up doesn't show the edge channel | 20:01 |
| ogra_ | does the store UI show it in the edge channel ? | 20:01 |
| stokachu | yes | 20:01 |
| ogra_ | thats weird | 20:01 |
| pedronis | zyga: do you want me to write something in the forum? or do you? | 20:01 |
| zyga | pedronis: I'm writing | 20:02 |
| pedronis | ok | 20:02 |
| pedronis | I think a different topic would be better | 20:02 |
| pedronis | fwiw | 20:02 |
| stokachu | i released this morning https://gist.github.com/battlemidget/f5670fe7450258c884eccdd309bdcdf3 | 20:02 |
| pedronis | especially the general autoconnect from slots issue | 20:02 |
| tvoss | pedronis: https://github.com/snapcore/snapd/pull/3130 is back to the ssh-keygen state | 20:02 |
| mup | PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130> | 20:02 |
| tvoss | tyhicks: ^ | 20:02 |
| mvo | niemeyer: the problem is understood now (thanks to pedronis!). the question is what we do. if we want to fix this all for 2.24 it will be at least tomorow, maybe even a day later | 20:02 |
| mvo | niemeyer: I guess thats ok, unless we have some obligations to release soon (jamiebennett may know) | 20:02 |
| stokachu | ogra_: do you see my snap in the edge channel? | 20:03 |
| zyga | pedronis: done | 20:03 |
| ogra_ | stokachu, nope ... | 20:03 |
| stokachu | that makes me sad | 20:03 |
| niemeyer | mvo: Can we strive for tomorrow? Today seems way too late given your timezones, and Wednesday feels too close to holidays | 20:03 |
| zyga | pedronis: yes, I'll start a new topic for this but perhaps tomorrow | 20:03 |
| mvo | niemeyer: we can strieve for tomorrow, zyga, pedronis ? | 20:03 |
| ogra_ | ogra@styx:~/Devel/branches/snapd$ snap info conjure-up|grep edge | 20:03 |
| ogra_ | ogra@styx:~/Devel/branches/snapd$ snap info core|grep edge: | 20:03 |
| ogra_ | edge: 16-2 (1665) 83MB - | 20:03 |
| ogra_ | stokachu, definitely not there | 20:04 |
| stokachu | so what's happening? | 20:04 |
| mvo | niemeyer: alternatively we can paper over it via just having core-support | 20:04 |
| zyga | mvo: I think we can, even current solutions are sufficient | 20:04 |
| ogra_ | stokachu, i guess you need a store person | 20:04 |
| stokachu | the snap store shows revision 185 | 20:04 |
| ogra_ | with a green box ? | 20:04 |
| stokachu | yes | 20:04 |
| mvo | niemeyer: i.e. we could remove the network-bind plug from core, fold that into ore-support and we have a working transition agian and fix things for 2.25 | 20:04 |
| zyga | mvo: we can do the core-support trick but I don't think even that is mandatory now | 20:04 |
| ogra_ | or just a thumbs up icon ? | 20:04 |
| pedronis | mvo: as I said, I think the proper fix for slot autoconnect is more 2.25 material | 20:04 |
| stokachu | nope it's published | 20:04 |
| stokachu | ive been doing this awhile | 20:04 |
| stokachu | :D | 20:04 |
| pedronis | mvo: the issue here is really mostly that core and ubuntu-core coexist for a bit | 20:05 |
| zyga | mvo: but I'd love to discuss that tomorrow morning :) | 20:05 |
| ogra_ | and if you go into the details of this revision it is also released to edge ? | 20:05 |
| zyga | I wonder if we can EOD now | 20:05 |
| stokachu | ogra_: yep | 20:05 |
| pedronis | mvo: auto-connect from slot is just an escape hatch that works for one but not the other (because core-support is only on core) | 20:05 |
| * ogra_ heard others complaining that their channels didnt end up being set (never seen that myself) | 20:05 | |
| mup | PR snapd#3165 opened: interfaces: adjust shm accesses to use 'm' for updated mmap kernel mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3165> | 20:05 |
| niemeyer | pedronis, mvo: That sounds like it could be a problem even for core-support alon | 20:05 |
| niemeyer | e | 20:05 |
| ogra_ | stokachu, well, then probably try nessita | 20:06 |
| stokachu | nessita: hi | 20:06 |
| pedronis | niemeyer: well ubuntu-core doesn't have the plug (but could have) | 20:06 |
| pedronis | I mean the plug for core-support | 20:06 |
| pedronis | atm | 20:06 |
| mvo | niemeyer: core-support alone is fine because nothing else uses core-support currently except core. ubuntu-core does not use any plugs | 20:06 |
| mvo | pedronis: -^ | 20:06 |
| pedronis | mvo: won't that change? or we build ubuntu-core differently? without hooks? | 20:07 |
| mvo | pedronis: we build ubuntu-core without hooks and there is no plan (AIUI) to change that | 20:08 |
| niemeyer | mvo: Okay.. for some reason gut feeling says we should understand and fix the issue with both network-bind and ubuntu-core, as we're close to it | 20:08 |
| niemeyer | Sorry | 20:08 |
| niemeyer | network-bind and core-support.. | 20:08 |
| niemeyer | It feels like we're really close now | 20:08 |
| zyga | niemeyer: I think the issue that needs more coding now is the behavior of auto-connect for slots | 20:08 |
| pedronis | niemeyer: there are two issues | 20:08 |
| pedronis | is not one issue | 20:09 |
| zyga | niemeyer: (or both plgus and slots, but slots are more obviously wrong) | 20:09 |
| pedronis | the 2nd issue make it so that we don't have lucky escape from the first | 20:09 |
| stokachu | who else handles the snap store | 20:11 |
| stokachu | i can't get edge to show up anymore | 20:11 |
| mvo | stokachu: maybe noise][ can help you | 20:12 |
| zyga | mvo: shall we regroup in the morning? | 20:13 |
| stokachu | who can i email about this? | 20:15 |
| pedronis | niemeyer: this is the 2nd issue: https://forum.snapcraft.io/t/auto-connect-logic-starting-from-slots-of-an-installed-refresh-snap-is-naive/236 | 20:15 |
| enoch85 | hey guys | 20:16 |
| enoch85 | how do I import a snap from a .snap file? | 20:16 |
| enoch85 | do I need to install snap first, and then put that file in a certain dir or something? | 20:16 |
| niemeyer | pedronis: Thanks, very clear | 20:17 |
| mvo | zyga: yeah, I will follwoup in the forum | 20:17 |
| niemeyer | enoch85: snap install filename.snap | 20:17 |
| niemeyer | --dengarous | 20:17 |
| niemeyer | --dangerous | 20:17 |
| niemeyer | enoch85: The flag means you acknowledge the fact it's unsigned, unreviewed, and may do Bad Things | 20:17 |
| zyga | mvo: ok | 20:18 |
| zyga | I replied to pedronis' post already | 20:18 |
| zyga | let's talk tomorrow, have a great evening everyone | 20:18 |
| mvo | zyga: sleep well | 20:18 |
| enoch85 | niemeyer: aah ok nice | 20:19 |
| enoch85 | snap install /path-to/filename.snap ? | 20:19 |
| stokachu | niemeyer: will the discourse forum have ubuntusso or other authentication mechanisms? | 20:19 |
| stokachu | like github | 20:19 |
| stokachu | rather use that then create another account | 20:20 |
| ogra_ | enoch85, --dangerous ... else it will not install | 20:20 |
| ogra_ | enoch85, but yeah, the rest is ccorrect | 20:20 |
| enoch85 | ogra_: ok thanks | 20:20 |
| ogra_ | stokachu, long term it will ... but not there yet | 20:21 |
| enoch85 | ogra_: I get this: ZOE ERROR (from /usr/lib/snap/snap): zoeParseOptions: unknown option (--dangerou) | 20:21 |
| enoch85 | ZOE library version 2013-02-16 | 20:21 |
| enoch85 | what's up? | 20:21 |
| ogra_ | you missed an s ? | 20:21 |
| enoch85 | root@daniel-pc:~# snap install /home/daniel/Desktop/nextcloud-client_continuous.gitb02dab3_amd64.snap --dangerous | 20:21 |
| enoch85 | ZOE ERROR (from /usr/lib/snap/snap): zoeParseOptions: unknown option (--dangerous) | 20:21 |
| enoch85 | ZOE library version 2013-02-16 | 20:21 |
| enoch85 | no? | 20:21 |
| ogra_ | snap version ? | 20:22 |
| ogra_ | (whats the output of that ?) | 20:22 |
| enoch85 | tbh I'm on Debian | 20:22 |
| enoch85 | did apt install snap | 20:22 |
| enoch85 | snap version just gives me what I should wrote to get an output | 20:23 |
| enoch85 | like a help sort of | 20:23 |
| enoch85 | SNAP - Semi-HMM-based Nucleic Acid Parser (version 2006-07-28) | 20:23 |
| enoch85 | might be helpful? | 20:23 |
| ogra_ | err | 20:23 |
| ogra_ | apt purge snap ... | 20:23 |
| ogra_ | apt install snapd | 20:23 |
| ogra_ | snap is a media player ... | 20:24 |
| enoch85 | ok sec | 20:24 |
| ogra_ | you want snapd | 20:24 |
| enoch85 | aah better | 20:24 |
| enoch85 | yup | 20:24 |
| enoch85 | that solved it | 20:24 |
| enoch85 | thanks | 20:24 |
| ogra_ | :) | 20:24 |
| enoch85 | now where is the snap? | 20:25 |
| enoch85 | hmm | 20:25 |
| enoch85 | can't find it in my launcher | 20:25 |
| enoch85 | (on Desktop) | 20:25 |
| ogra_ | you might need to log out and back in again ... snapd puts an XDG_DATA_DIR entry in the Xorg start scripts to find the .desktop files ... | 20:26 |
| enoch85 | ogra_: got it from here: https://github.com/nextcloud/client_theming/releases | 20:26 |
| enoch85 | okok | 20:26 |
| enoch85 | will try | 20:26 |
| enoch85 | sec | 20:26 |
| enoch85 | ogra_: yaay it worked | 20:27 |
| ogra_ | :) | 20:27 |
| ogra_ | enjoy | 20:27 |
| enoch85 | now, if I want to update the snap, do I just download the new snap and type snap install again? | 20:28 |
| enoch85 | or do I have to remove old stuff also? | 20:28 |
| ogra_ | just snap install should be fine | 20:28 |
| ogra_ | or better ask oparoz to upload it to the store ... then it would auto-update | 20:29 |
| zyga | niemeyer: just before I EOD, I updated https://github.com/snapcore/snapd/pull/3153 and https://github.com/snapcore/snapd/pull/3154 as suggested | 20:29 |
| mup | PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153> | 20:29 |
| mup | PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154> | 20:29 |
| pedronis | niemeyer: I think now the forums capture what we found here | 20:29 |
| zyga | niemeyer: if you +1 both we can have an easier morning | 20:29 |
| pedronis | s/forums/forum/ | 20:29 |
| enoch85 | ogra_: thanks :D | 20:29 |
| ogra_ | np :) | 20:30 |
| Pharaoh_Atem | zyga, morphis: looks like all the tests failed https://github.com/snapcore/snapd/pull/3162 :( | 20:31 |
| mup | PR snapd#3162: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162> | 20:31 |
| morphis | Pharaoh_Atem: infrastructure issues .. | 20:31 |
| morphis | Pharaoh_Atem: will retrigger tomorrow | 20:32 |
| Pharaoh_Atem | bully :/ | 20:32 |
| zyga | morphis: merge master and retry | 20:32 |
| * zyga is off now | 20:32 | |
| enoch85 | wow snaps are great! | 20:33 |
| enoch85 | like .exe for windows (sorry for the comparison ;) ) | 20:33 |
| enoch85 | or .msi maybe | 20:33 |
| niemeyer | enoch85: Haha, thanks, I guess! ;) | 20:33 |
| Pharaoh_Atem | enoch85: it's basically like self-contained zip thingies for Windows | 20:34 |
| Pharaoh_Atem | or the way apps are handled on MacOS | 20:34 |
| enoch85 | great stuff | 20:34 |
| enoch85 | once you go snap you never go back | 20:34 |
| * Pharaoh_Atem sighs | 20:34 | |
| niemeyer | zyga: They're both approved | 20:35 |
| niemeyer | enoch85: You can actually go back.. see "snap revert --help" | 20:35 |
| * niemeyer ducks | 20:35 | |
| * Pharaoh_Atem knew that was coming | 20:36 | |
| * zyga hugs niemeyer | 20:36 | |
| zyga | just returned to the office to feed the fish and turn lights off | 20:36 |
| Pharaoh_Atem | you have an office? | 20:36 |
| enoch85 | niemeyer: haha | 20:37 |
| zyga | niemeyer: given all the data now can you update your stance on https://github.com/snapcore/snapd/pull/3145 | 20:37 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 20:37 |
| zyga | niemeyer: the needs fixing is 4 days old | 20:37 |
| ogra_ | Pharaoh_Atem, i find more interesting that he has fish TBH | 20:39 |
| ogra_ | **in* his office | 20:39 |
| Pharaoh_Atem | well, I mean, yeah, that too :) | 20:39 |
| zyga | Pharaoh_Atem: yes, it's a separate room upstaris | 20:39 |
| zyga | Pharaoh_Atem: duplex appartment (is that the right term?) | 20:39 |
| mvo | niemeyer: I feel slightly uneasy if we go out with the current set of 2.24 fixes but not the fix for the autoconnect, then core interfaces will only connect because we fixup things in 3145 after the fact. i put an alterative fact^Widea into the forum. but its just my gut feeling, so happy to be overriden | 20:39 |
| zyga | Pharaoh_Atem: essetially small part of attic | 20:40 |
| ogra_ | maisonette :) | 20:40 |
| Pharaoh_Atem | ah | 20:40 |
| mvo | niemeyer: (hope there is enough context in the above) | 20:40 |
| Pharaoh_Atem | zyga: it's a duplex place if it has its own AC, bathroom, and kitchen area | 20:40 |
| Pharaoh_Atem | if it lacks that, then it's just a multi-level apartment | 20:40 |
| zyga | Pharaoh_Atem: no, just window :) | 20:41 |
| zyga | Pharaoh_Atem: and the door is downstairs | 20:41 |
| zyga | Pharaoh_Atem: just 2nd level with attic and roofless terrace | 20:41 |
| nessita | stokachu, hi | 20:42 |
| nessita | stokachu, how can I help you? | 20:42 |
| niemeyer | zyga: isn't the statement there still true? | 20:42 |
| niemeyer | zyga: Actually, the conversation today | 20:43 |
| niemeyer | zyga: We discussed it here rather than in the PR.. I'll update the PR as I should have done originally, sorry | 20:43 |
| niemeyer | mvo: Looking | 20:43 |
| zyga | niemeyer: thank you! that's all I need | 20:44 |
| * pedronis should call it a day | 20:46 | |
| === Sergio_ is now known as Guest18132 | ||
| * tvoss calls it a day | 20:55 | |
| niemeyer | zyga: Updated #3145 with a summary of what we discussed about it here | 20:55 |
| niemeyer | mvo: Replied in the forum | 20:55 |
| niemeyer | tvoss: Have a good night | 20:55 |
| tvoss | niemeyer: would be great if you could follow up on tyhick's question here: https://github.com/snapcore/snapd/pull/3130 | 20:56 |
| mup | PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130> | 20:56 |
| tvoss | niemeyer: would like to pick up tomorrow my morning | 20:56 |
| mvo | niemeyer: thanks a lot ! I will catchup with zyga and pedronis in the european morning and prepare something. thanks again! and a huge HUG to zyga and pedronis for getting to the bottom of this | 20:58 |
| pedronis | mvo: zyga: I just noticed that if we fix slot-driven autoconnect correctly the bug is there, we have a plug and two slots we cannot autoconnect | 20:59 |
| pedronis | so we really need to special case this (core and ubuntu-core both around) somehow, at some point | 20:59 |
| pedronis | slot-driven autoconnect is quite buggy, and core-support works out because of the bug | 21:00 |
| pedronis | atm | 21:01 |
| zyga | pedronis: yes, I saw; is that fixed with the special hack that ignores the "ubuntu-core" candidate or should I EOD, am tired, and don't understand that correctly? | 21:01 |
| mup | PR snapd#3166 opened: interfaces/builtin: fold network-bind into core-support <Created by zyga> <https://github.com/snapcore/snapd/pull/3166> | 21:01 |
| pedronis | zyga: we need something like that, exactly how and where not sure, I fear we get things double connected for a bit that way? | 21:02 |
| pedronis | is that a problem? | 21:02 |
| zyga | pedronis: same plug to same slot? | 21:02 |
| zyga | pedronis: no, that's a no-op | 21:02 |
| zyga | pedronis: (and also not an error) | 21:03 |
| zyga | mvo: fold idea in PR above, no tests, let's discuss this tomorrow :) | 21:03 |
| * zyga really tries to get away now | 21:03 | |
| mup | PR snapcraft#1229 closed: sources: add VCS asset tracking <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1229> | 21:03 |
| mvo | zyga: \o/ I can work on this further in my morning and we catch up | 21:03 |
| pedronis | mvo: the fold will help us only until we fix autoconnect :/ | 21:04 |
| mvo | zyga: *go away* | 21:04 |
| pedronis | so not sure it's a winner | 21:04 |
| mvo | pedronis: yes, but I think thats ok | 21:04 |
| mvo | pedronis: well, maybe | 21:04 |
| mvo | pedronis: I am bit concerned that 2.24 slips even further if we try to fix all the bugs and we are also in a bit of a rush because the 2.24 is sitting on our shoulders which is also not great. I'm trying to find something minimal we can do to move us forward | 21:05 |
| mvo | pedronis: *but* having said that, if the minimal fix/workaround is no good, we need to bite the bullet I think :/ | 21:06 |
| pedronis | my worry is that we do a strange things and then things are broken again | 21:06 |
| mvo | pedronis: your input is very important here, if you think its not the right approach I think we need to reconsider | 21:06 |
| pedronis | as I said I don't think we need to fix autoconnect now fully | 21:06 |
| pedronis | but we should not also do something that is broken again | 21:07 |
| pedronis | once we do that I think :/ | 21:07 |
| mvo | pedronis: well, we will have a test that ensures we don't break things accidently | 21:07 |
| mvo | pedronis: the ubuntu-core -> core transition one will have the new check that core-support is connected | 21:07 |
| mvo | pedronis: but if we go down the other route and not fold things, we still need to do something with auto-connect, no? | 21:08 |
| pedronis | what I'm saying is that we will need some form of #3145 at some point anyway | 21:08 |
| mvo | pedronis: or do you think the 3145 workaorund is good enough? it | 21:08 |
| mvo | pedronis: aha, ok | 21:08 |
| mvo | pedronis: we would probably only need this part https://github.com/snapcore/snapd/pull/3145/files#diff-b88a3954d898e0a8ab681d98f1407a0fR332 though? | 21:09 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 21:09 |
| pedronis | mvo: because as I said during the transition we have two slots | 21:09 |
| pedronis | so autoconnect wouldn't work unless we break the tie somehow | 21:09 |
| mvo | pedronis: what I dislike about 3145 is that we go into a buggy state and then fixup things | 21:09 |
| pedronis | mvo: first of all I'm not sure we need the fixup bit | 21:10 |
| mvo | pedronis: this fixup we will need to keep forever but if we fold network-bind into core-support I think we can get away without a fixup | 21:10 |
| mvo | pedronis: hm, thats interessting | 21:10 |
| pedronis | mvo: we do setup profile with the new core no | 21:10 |
| pedronis | before running the hook | 21:10 |
| pedronis | mvo: so autoconnect itself at that point should fix things if we convince to do the right thing | 21:12 |
| mvo | pedronis: aha, but not with 3145 as it is now, right? | 21:12 |
| mvo | pedronis: some more code is needed for that | 21:12 |
| pedronis | mvo: probably less code | 21:12 |
| mvo | pedronis: less code is good :) | 21:12 |
| pedronis | as I said we don't need the fixup | 21:13 |
| mvo | pedronis: won't we need it for systems who are already in this state(?) | 21:13 |
| pedronis | mvo: I think the question is really what do in autoConnect | 21:13 |
| pedronis | mvo: well, they can be fixed only with a new core, no? | 21:13 |
| pedronis | and the new core will run setup-profiles for itself? | 21:13 |
| pedronis | no? | 21:13 |
| mvo | pedronis: oh, indeed | 21:13 |
| mvo | pedronis: yes, that should work! | 21:14 |
| niemeyer | School run | 21:21 |
| pedronis | mvo: I put some comments about what we discussed in #3145 itself, we should see what to do with it in morning, maybe it can be just cut down to the barebones | 21:25 |
| mvo | pedronis: thanks a lot! yeah, lets catchup in the morning | 21:25 |
| mvo | pedronis: I have to say https://github.com/snapcore/core/pull/33 and https://github.com/snapcore/snapd/pull/3166#pullrequestreview-31963086 look really compelling to me as a way out… | 21:26 |
| mup | PR core#33: the core snap only needs core-support (not network-bind) <Created by mvo5> <https://github.com/snapcore/core/pull/33> | 21:26 |
| mup | PR snapd#3166: interfaces/builtin: fold network-bind into core-support <Created by zyga> <https://github.com/snapcore/snapd/pull/3166> | 21:26 |
| mup | PR core#33 opened: the core snap only needs core-support (not network-bind) <Created by mvo5> <https://github.com/snapcore/core/pull/33> | 21:26 |
| mvo | pedronis: for now at least. but I am sleepy now so I guess I tend to gravitate to the simple solution even more so than usually :) | 21:26 |
| mvo | pedronis: but indeed, we need to fix the auto-connect code in any case at some point | 21:27 |
| pedronis | mvo: well, as I said it will broken again once we fix stuff | 21:27 |
| mvo | pedronis: indeed | 21:27 |
| pedronis | so unless we think is the right thing in some sense, it's not a super win | 21:28 |
| mvo | pedronis: lets talk in the morning, thanks again for all these insights :) | 21:28 |
| mvo | pedronis: fair point | 21:28 |
| pedronis | mvo: I can see argument that would make it make sense, but anyway tomorrow | 21:29 |
| mvo | pedronis: that would make sense to use the "cheap" workaround you mean? | 21:30 |
| mup | PR snapd#3161 closed: snap-confine,browser-support: /dev/tty for snap-confine, misc browser-support for gnome-shell <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3161> | 21:31 |
| jdstrand | mvo: hey, not sure if you want to pull that ^ into 2.24 | 21:31 |
| mvo | jdstrand: absolutely | 21:31 |
| jdstrand | mvo: cool, thanks | 21:31 |
| mvo | pedronis: I'm off now, more tomorrow. /me waves | 21:37 |
| mup | PR snapd#3154 closed: many: rename two core plugs that clash with slot names <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3154> | 22:08 |
| === coreycb is now known as coreycb_vaca | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!