| elfgoh | Hi i am trying todo a snap login | 01:23 |
|---|---|---|
| elfgoh | get an error error: cannot get snap access permission from store: Post https://myapps.developer.ubuntu.com/dev/api/acl/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) (see "snap login --help") | 01:23 |
| mup | PR snapcraft#1318 opened: tests: refactor the travis jobs using stages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1318> | 04:20 |
| === chihchun_afk is now known as chihchun | ||
| morphis | mvo: morning! | 05:47 |
| morphis | mvo: can you have a look at https://github.com/snapcore/snapd/pull/3308 and https://github.com/snapcore/snapd/pull/3307 ? | 05:47 |
| mup | PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308> | 05:47 |
| mup | PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307> | 05:47 |
| mvo | hey morphis! good moring. sure, I have alook now | 05:49 |
| morphis | mvo: thanks! | 05:49 |
| zyga | AdamH_: specifically apparmor/profiles, seccomp/profiles | 05:51 |
| zyga | 07:49 < zyga> AdamH_: intetesting, yes that does help | 05:51 |
| zyga | 07:49 < zyga> AdamH_: can you use beta and collect all the security profiles? go to /var/lib/snapd/ | 05:51 |
| zyga | 07:49 < zyga> AdamH_: and in each directory look for a file named after the application | 05:51 |
| zyga | 07:49 < zyga> AdamH_: intetesting, yes that does help | 05:51 |
| zyga | 07:49 < zyga> AdamH_: can you use beta and collect all the security profiles? go to /var/lib/snapd/ | 05:51 |
| zyga | 07:49 < zyga> AdamH_: and in each directory look for a file named after the application | 05:51 |
| zyga | AdamH_: then go to edge and collect the same set of files | 05:51 |
| morphis | zyga: btw. we should add a page on snapcraft.io which explains how to collect necessary debug material | 05:52 |
| morphis | zyga: we do something similar for our stack documentation (e.g. https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/report-bug) | 05:52 |
| zyga | morphis: good idea, I will write something like that! | 05:55 |
| zyga | morphis: how is everything so far, any fires? | 05:57 |
| morphis | zyga: no fires I know of :-) | 05:57 |
| zyga | good :) | 05:58 |
| morphis | zyga: only fire is that my spread/qemu setup times out a lot today .. | 06:03 |
| zyga | morphis: on a specific test or on preparation? | 06:14 |
| morphis | zyga: it times out when running "dnf update" | 06:16 |
| morphis | must be my network or such a like | 06:17 |
| zyga | morphis: maybe setup a local proxy? | 06:19 |
| Son_Goku | morphis, zyga: can you guys get robert ancell to properly tag releases on GitHub | 06:20 |
| Son_Goku | it's very annoying that he's making releases that don't exist :/ | 06:21 |
| morphis | Son_Goku: sure | 06:21 |
| zyga | Son_Goku: huh? in what way? | 06:21 |
| morphis | Son_Goku: can you just drop him a mail with zyga and me in CC? | 06:21 |
| morphis | zyga: snapd-glib | 06:21 |
| Son_Goku | I mean, he's making the tarballs on LP, but they don't have corresponding git tags | 06:21 |
| morphis | I guess he just releases into the lp/archive | 06:22 |
| Son_Goku | yeah | 06:22 |
| Son_Goku | it's just annoying because while I can "guess" where the tarball comes from | 06:22 |
| Son_Goku | I don't know it | 06:22 |
| morphis | Son_Goku: not very professional, I know | 06:23 |
| morphis | Son_Goku: if you don't want to write a mail, a forum topic would be good too | 06:23 |
| Son_Goku | I'll send an email later | 06:23 |
| Son_Goku | as it is, I'm desperately trying to go back to sleep | 06:24 |
| Son_Goku | it's 2:24am here :( | 06:24 |
| morphis | Son_Goku: do that! | 06:25 |
| morphis | pedronis, mvo: https://forum.snapcraft.io/t/gadget-snap-config-defaults-dont-work/409/5 should be added to https://forum.snapcraft.io/t/next-snapd-2-27/572 , shouldn't it? | 06:48 |
| mvo | morphis: ü1 | 06:49 |
| mvo | morphis: +1 | 06:49 |
| morphis | mvo: actually is there a list of things planed for 2.27? | 06:49 |
| morphis | mvo: ah sorry, it is already in the post :-) | 06:49 |
| zyga | mvo: good morning :) | 06:52 |
| mvo | hey zyga | 06:53 |
| mvo | morphis: :) | 06:53 |
| morphis | mvo: too early :-) | 06:53 |
| mvo | morphis: no problem at all | 06:54 |
| abeato | mvo, quick question, is snapd 2.26.1 in the edge core snap already? | 06:57 |
| mvo | abeato: yes | 06:58 |
| zyga | mvo: something is wrong with core | 06:58 |
| mvo | abeato: well, it should be, looks like there is a upload bug in our edge snap right now, let me double check what is going on | 06:58 |
| mvo | zyga: with core uploads? | 06:58 |
| zyga | mvo: amd64 core (edge) is still pre-version change | 06:58 |
| abeato | mvo, ahm, ok | 06:58 |
| zyga | mvo: and in fact gets no updates | 06:58 |
| mvo | zyga: I think its the new version string | 06:58 |
| zyga | mvo: well, I wish I had the new version string, I think it didn't build since | 06:59 |
| zyga | mvo: note that i386 did build | 06:59 |
| mvo | zyga: but that should have got fixed last week, so maybe something less is broken | 06:59 |
| mvo | zyga: oh? | 06:59 |
| mvo | woah | 06:59 |
| * mvo looks | 06:59 | |
| zyga | mvo: are you on edge? | 06:59 |
| zyga | mvo: I'm on edge and I have 1909 | 06:59 |
| zyga | refreshed: 2017-05-12 06:20:00 +0200 CEST | 06:59 |
| mvo | zyga: what does snap version tells you? | 06:59 |
| zyga | snap 2.26.1+201705112259.git.e719341~ubuntu16.04.1 | 06:59 |
| mvo | zyga: ok, at least abeato gets a pretty recent snapd this way :) but yeah, edge-edge is 5 days old :/ | 07:00 |
| zyga | mvo: btw, update-ns landed | 07:00 |
| abeato | mvo, recent enough for us, thanks :) | 07:00 |
| zyga | mvo: but I noticed we don't run any tools from core (discard-ns, update-ns) | 07:00 |
| mvo | zyga: holly cow | 07:00 |
| zyga | mvo: so it will be broken | 07:00 |
| zyga | mvo: I'm fixing that now | 07:00 |
| mvo | zyga: please describe it in the forum post for 2.27, thats a huge thing | 07:00 |
| zyga | mvo: not in tests but in practice | 07:00 |
| zyga | mvo: yes, I was planning to already :) | 07:01 |
| mvo | zyga: ok | 07:01 |
| mvo | zyga: thank you :) | 07:01 |
| zyga | mvo: I'll be fixing the run-from-core aspect of discard/update ns as I watch the town hall | 07:01 |
| mvo | zyga: TestLokcUnlockWorks fails in traivs | 07:02 |
| mvo | zyga: meh :( | 07:02 |
| zyga | mvo: oh? missing dependency or something else? | 07:03 |
| zyga | mvo: do you have a log? | 07:03 |
| mvo | zyga: | 07:05 |
| mvo | https://travis-ci.org/snapcore/snapd/builds/232709633?utm_source=github_status&utm_medium=notification | 07:05 |
| mvo | zyga: it looks like its simply not working for whatever reason, not super important right now, I will just skip the test on travis for now, but slightly strange | 07:05 |
| mup | PR snapd#3324 opened: Androidboot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324> | 07:06 |
| zyga | mvo: thanks, I see now | 07:06 |
| zyga | mvo: weird, it passed tests before | 07:07 |
| mvo | zyga: we did not run the unit tests for a while on travis | 07:07 |
| mvo | zyga: only inside spread indirectly | 07:07 |
| zyga | mvo: aaah | 07:08 |
| zyga | mvo: I see | 07:08 |
| zyga | hum hum hum, maybe weird filesystem | 07:08 |
| zyga | mvo: interesting find | 07:08 |
| mvo | zyga: anyway, just wanted to mention it, its not a big deal right now :) | 07:08 |
| fgimenez | hi mvo good morning :) during the 2.26.1 validation at beta i had two panics on pi2 http://paste.ubuntu.com/24581585/ and pi3 http://paste.ubuntu.com/24581419/, it would be great if you could take a look | 07:18 |
| pstolowski | morning | 07:19 |
| mvo | fgimenez: thanks, checking now | 07:22 |
| zyga | mvo: ah, obvious bug :/ | 07:24 |
| zyga | mvo: we don't check for the length of l | 07:24 |
| zyga | mvo: probably data corruption but could be something else | 07:24 |
| mvo | zyga: obvious bug in the above pastebins or flock or something else :) ? | 07:25 |
| fgimenez | mvo: thank you, i also wanted to mention, i've been using the new --extra-snaps capability of prepare-image (to include assertions along with sideloaded snaps), it works fine but i have an issue, probably it is expected, if i download the kernel snap from stable and then create the image with --channel beta, then kernel tracks beta and is automatically refreshed to the latest version on that channel | 07:25 |
| zyga | mvo: yes | 07:25 |
| zyga | mvo: in the pastebins from fgimenez | 07:26 |
| mvo | fgimenez: indeed, that is expected behaviour | 07:26 |
| mvo | zyga: aha, ok | 07:26 |
| zyga | mvo: do you want me to propose a PR? | 07:26 |
| fgimenez | mvo: ok thanks | 07:26 |
| mvo | zyga: sure, if you have it all tracked down already +1 | 07:28 |
| zyga | great :) | 07:29 |
| mvo | zyga: I have not even looked yet properly :) | 07:29 |
| zyga | mvo: interestingly we vendor an older version of your package | 07:31 |
| zyga | mvo: but your package is also panicking in master | 07:31 |
| zyga | mvo: is api brakage acceptable? | 07:31 |
| mvo | zyga: hm, any chance we could avoid it :) ? | 07:32 |
| zyga | mvo: yes, let me tweak things | 07:33 |
| zyga | ah, it's just internal API, no worries | 07:33 |
| zyga | all good :) | 07:33 |
| mvo | fgimenez: any idea why this crash is triggered now, did we just not test before? | 07:37 |
| mvo | fgimenez: test for this before? | 07:37 |
| mvo | fgimenez: the code in this area has not really changed recently afaict | 07:37 |
| mup | PR core#42 opened: fix version number length <Created by mvo5> <https://github.com/snapcore/core/pull/42> | 07:37 |
| fgimenez | mvo: yes we executed the same tests before (there have been changes in the suite but not much disruptive), no idea why this is happening now | 07:38 |
| fgimenez | mvo: i created the image using the new prepare-image capability, is the only difference i think | 07:39 |
| zyga | mvo: FYI the crash looks like data corruption on the card | 07:39 |
| fgimenez | zyga: aha thanks! but it happens on two different cards and boards (pi2 and pi3), is it possible that both are corrupted? | 07:40 |
| zyga | fgimenez: maybe, though less likely | 07:41 |
| zyga | fgimenez: can you do a dump of the uboot environment file please? | 07:41 |
| fgimenez | zyga: sure, i need to reproduce first, (now i'm running the tests after refreshing from stable) will ping you when i have it | 07:42 |
| zyga | fgimenez: if it was random it may not happen again | 07:43 |
| mvo | fgimenez: thank you. keen to see the dump | 07:43 |
| zyga | mvo: https://github.com/mvo5/uboot-go/pull/2 | 07:44 |
| mup | PR mvo5/uboot-go#2: Detect and return errors from Open in case of malformed data <Created by zyga> <https://github.com/mvo5/uboot-go/pull/2> | 07:44 |
| mvo | zyga: the api of uenv should not allow to write something without "=" but maybe something else is going on :/ | 07:44 |
| zyga | mvo: well, whatever you write, you may read smurfs back | 07:44 |
| zyga | mvo: have a look at the PR | 07:44 |
| mvo | zyga: yeah, your fix is great | 07:45 |
| zyga | mvo: separately I think we want two more changes | 07:45 |
| zyga | mvo: a change that lets open skip malformed data | 07:45 |
| zyga | (better than failing outright) | 07:45 |
| zyga | mvo: and an update to snapd vendor commit | 07:45 |
| zyga | mvo: shall I make those? | 07:45 |
| mvo | zyga: yes, thank you! | 07:47 |
| mvo | zyga: first branch is in | 07:47 |
| mvo | zyga: quick review for https://github.com/snapcore/core/pull/42 would be great | 07:48 |
| mup | PR core#42: fix version number length <Created by mvo5> <https://github.com/snapcore/core/pull/42> | 07:48 |
| zyga | mvo: looking | 07:50 |
| zyga | mvo: done | 07:51 |
| NicolinoCuralli | hi guys, what part of gpg bundle snapcraft register-key upload on the store? | 07:53 |
| mup | PR core#42 closed: fix version number length <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/42> | 07:54 |
| pedronis | NicolinoCuralli: only the public bits | 07:58 |
| NicolinoCuralli | pedronis: thanks | 07:58 |
| zyga | mvo: https://github.com/mvo5/uboot-go/pull/3 | 07:59 |
| mup | PR mvo5/uboot-go#3: Add OpenWithFlags and OpenBestEffort flag <Created by zyga> <https://github.com/mvo5/uboot-go/pull/3> | 07:59 |
| * zyga thinks about breakfast | 08:00 | |
| mvo | zyga: very nice, thank you! | 08:01 |
| zyga | mvo: I'll get the snapd copy updated now | 08:02 |
| mvo | zyga: \o/ | 08:06 |
| Chipaca | o/ | 08:17 |
| Chipaca | mvo: spread has "residual artifacts" | 08:17 |
| mvo | Chipaca: aha, interessting. you mean for the coverage results? | 08:18 |
| Chipaca | mhmm | 08:18 |
| Chipaca | https://github.com/snapcore/spread#residue | 08:18 |
| Chipaca | you then have to decide which of the 8 coverage files we get you want :-) | 08:18 |
| Chipaca | eee | 08:18 |
| mvo | Chipaca: I can look into that, however I also kind of like the run of the unit tests in an extra step mostly because if something is wrong there things fail early | 08:18 |
| Chipaca | our first codecov report came in :-D | 08:18 |
| mvo | Chipaca: weeeee | 08:19 |
| Chipaca | 77% :-/ | 08:19 |
| mvo | yeah | 08:19 |
| Chipaca | that's dropped a lot since we looked at it last | 08:19 |
| mvo | this is why I want it :) | 08:19 |
| Chipaca | mvo: thanks for doing this :-) | 08:19 |
| ogra_ | oh, mondrian pictures! | 08:20 |
| mvo | spamming the comments is maybe not that great, I wonder if that can be disabled | 08:20 |
| Chipaca | mvo: the problem with doing it in a different step is that we eat up a travis slot | 08:20 |
| mvo | Chipaca: its being done in the same travis run, it just takes a bit of extra time | 08:20 |
| zyga | fgimenez, mvo: https://github.com/snapcore/snapd/pull/3325 | 08:20 |
| mup | PR snapd#3325: vendor,partition: fix panics from uenv <Created by zyga> <https://github.com/snapcore/snapd/pull/3325> | 08:20 |
| Chipaca | ah! | 08:20 |
| Chipaca | that's alright then :-D | 08:20 |
| mup | PR snapd#3325 opened: vendor,partition: fix panics from uenv <Created by zyga> <https://github.com/snapcore/snapd/pull/3325> | 08:20 |
| mvo | Chipaca: I will look how much extra time exactly | 08:21 |
| Chipaca | mvo: we could always have it in spread just after --static | 08:21 |
| mvo | Chipaca: indeed, this is what I did now | 08:21 |
| zyga | mvo: I'll focus on run-from-core for internal tools now | 08:22 |
| Chipaca | oh? | 08:22 |
| mvo | zyga: thank you | 08:22 |
| * Chipaca clicks 'view all' | 08:22 | |
| mvo | Chipaca: or was I just dreaming this ? | 08:22 |
| zyga | Chipaca, mvo: FYI: travis has added "build stages", that may be of some help to you (perhaps) | 08:22 |
| Chipaca | mvo: no, it's there | 08:22 |
| Chipaca | mvo: it's early | 08:23 |
| Chipaca | mvo: i thought i was looking at spread.yaml :-) | 08:23 |
| * ogra_ sees the core uploads succeed and hugs mvo | 08:24 | |
| mvo | :) no worries | 08:24 |
| mvo | ogra_: yay | 08:24 |
| mvo | more cores! | 08:24 |
| ogra_ | :D | 08:24 |
| * zyga looks at delta update for core | 08:26 | |
| zyga | niiiiice :) | 08:26 |
| zyga | mvo: hmm | 08:27 |
| zyga | mvo: I broke edge | 08:27 |
| zyga | - Setup snap "core" (1934) security profiles (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented) | 08:27 |
| zyga | mvo: (this is the thing I mentioned) | 08:27 |
| zyga | mvo: we may want to revert edge to previous for a sec | 08:27 |
| zyga | mvo: and land a change that fixes this first | 08:27 |
| zyga | mvo: (update-ns runs from distro) | 08:27 |
| zyga | mvo: not from core | 08:27 |
| Chipaca | zyga: dude, you owe us so much cake | 08:28 |
| mvo | zyga: ok | 08:28 |
| * ogra_ guesses zyga was just distracted by the townhall :P | 08:28 | |
| * Chipaca forgot about the town hall, but slept 8 hours \o/ | 08:28 | |
| zyga | Chipaca: it would be caught by the upgrade test but those don't run on each PR | 08:29 |
| zyga | (i think) | 08:29 |
| ogra_ | it still running, IoT just up right now | 08:29 |
| ogra_ | *it is | 08:29 |
| fgimenez | zyga: thanks for the branch! trying to get the dump in a bit, will let you and mvo know how it goes | 08:31 |
| mvo | fgimenez: if you can not get the dump but just the binary uboot.env that is fine too | 08:34 |
| fgimenez | mvo: ok thanks | 08:36 |
| Chipaca | zyga: could you finish your review of snapd#3321? | 08:37 |
| mup | PR snapd#3321: wrappers: service start/stop were inconsistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/3321> | 08:37 |
| Chipaca | then i can land that and be happy | 08:37 |
| * Chipaca penciled in 6 hours of being happy today | 08:37 | |
| Chipaca | pencilled* | 08:37 |
| zyga | Chipaca: yes, after the tools from core branch | 08:41 |
| mvo | Chipaca: wdyt, a single coverage report that is kept being updated is ok? codecov will not spam, it will have one report per branch and keeps updating it. do you think this is acceptable? | 08:45 |
| Chipaca | mvo: yes, i think that's fine (also i don't mind it posting the report as a comment on the pr) | 08:45 |
| Chipaca | because only the author of the pr, and people who've already commented, will get that email | 08:46 |
| mvo | Chipaca: ok, I will bring it up in the standup | 08:46 |
| Chipaca | ok | 08:46 |
| Chipaca | mvo: will you add the widget? | 08:46 |
| mvo | Chipaca: I can :) | 08:47 |
| mvo | Chipaca: the badge you mean? | 08:47 |
| Chipaca | yeah | 08:47 |
| mvo | Chipaca: let me add it | 08:47 |
| Chipaca | i'm a sucker for badges | 08:47 |
| mvo | Chipaca: hahaha | 08:47 |
| * mvo hugs Chipaca | 08:47 | |
| === longsleep_ is now known as longsleep | ||
| mvo | Chipaca: badge added now | 09:02 |
| Chipaca | mvo: yep! thanks :-) | 09:02 |
| Chipaca | tried to add a <3 to the commit, but github won't let me | 09:03 |
| mup | PR snapd#3326 opened: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <https://github.com/snapcore/snapd/pull/3326> | 09:03 |
| zyga | mvo: can you please look at https://github.com/snapcore/snapd/pull/3326 | 09:04 |
| mup | PR snapd#3326: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <https://github.com/snapcore/snapd/pull/3326> | 09:04 |
| zyga | mvo: the main/listing test needs update again | 09:05 |
| zyga | mvo: and with lower priority, can you look at https://github.com/snapcore/snapd/pull/3308 - this will define how all our spread tests look like in wake of support of non-debian distributions; | 09:07 |
| mup | PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308> | 09:07 |
| zyga | mvo: I feel somewhat strongly about it but I will accept your call | 09:07 |
| morphis | zyga: asked mvo already this mornign to have a look :-) | 09:08 |
| mvo | zyga, morphis it is on my list, unfortunately its a longish list but I will definitely get to it today | 09:08 |
| morphis | mvo: no hurry | 09:09 |
| morphis | mvo: don't need a full review yet, just your call on the discussion I had with zyga on it | 09:10 |
| mvo | morphis zyga: you are mostly interessted in the centralized vs non-centralized approach? | 09:10 |
| morphis | mvo: yes | 09:10 |
| zyga | mvo: thank you | 09:11 |
| mvo | thanks, I will read the PR and scratch my head a little bit over it | 09:11 |
| NicolinoCuralli | hi guys another question about signing : what ubuntu-image deposits on image of gpg bundle? | 09:12 |
| zyga | is anyone handling the main/listing test? | 09:12 |
| zyga | mvo, Chipaca, fgimenez: ^ | 09:16 |
| Chipaca | zyga: what's going on with main/listing? | 09:16 |
| zyga | Chipaca: new edge version broke it | 09:17 |
| zyga | again :) | 09:17 |
| Chipaca | augh | 09:17 |
| Chipaca | 16-2.26.1+201705151555.git.d15bf would do that, yes | 09:17 |
| Chipaca | that's a nasssty version number | 09:17 |
| Chipaca | (also, is that a unique hash, or has it been truncated?) | 09:17 |
| zyga | truncated :/ | 09:17 |
| Chipaca | hash snippet i mean | 09:17 |
| zyga | mvo: I'd say we should drop the date | 09:17 |
| zyga | and just go with the hash | 09:18 |
| ogra_ | we really need to drop the time from the timestamp | 09:18 |
| zyga | yes | 09:18 |
| ogra_ | date is totally enough if we keep the hash anyway | 09:18 |
| zyga | well, hash has the date if you git show it ;) | 09:18 |
| mvo | zyga: I think there was a discussion with gustavo about that, he was keen to keep the timestamp but considered the git hash clutter | 09:18 |
| Chipaca | ok, i'll fix the test | 09:18 |
| mvo | Chipaca: truncated | 09:19 |
| Chipaca | I think the timestamp is more immediately useful | 09:19 |
| mvo | Chipaca: so we can cut it out | 09:19 |
| Chipaca | mvo: is this long version ever going to leave edge? | 09:19 |
| Chipaca | (should it?) | 09:19 |
| mvo | Chipaca: no, only edge will have ugly versions | 09:19 |
| Chipaca | ok | 09:20 |
| mvo | so yeah, I can push another PR to kill the git hash :) | 09:20 |
| zyga | mvo: so how will we do beta builds? | 09:20 |
| zyga | mvo: separately from edge builds? | 09:20 |
| Chipaca | mvo: let me know what it will look like, so i can fix the listing test to match | 09:21 |
| mvo | zyga: right now all beta builds are syncronised with uploads of a snapd with a proper version number | 09:22 |
| mvo | Chipaca: I think just 16-2.26.1+201705151555 | 09:22 |
| mvo | zyga: not sure if this reply makes sense, I can write more if its unclear :) | 09:23 |
| ogra_ | zyga, well, athe actual plan was to do different chasnnels from different archives (beta/stable without PPA) ... | 09:24 |
| ogra_ | but we're still far from that | 09:24 |
| ogra_ | which is why mvo makes sure to have a stable snapd in the PPA before a beta snap gets rolled atm | 09:24 |
| zyga | mvo: I think the git hash would be more useful | 09:25 |
| zyga | mvo: than the date | 09:25 |
| zyga | mvo: certainly to answer "is this commit in that build already" | 09:25 |
| mvo | zyga: fair enough, we can discuss this in the standup. I would like to have both but there is no enough space on this margin for this wonderful version | 09:26 |
| * ogra_ also thinks to remember that in the last discussioon we agreed to cutting the date shorter and leave the hash instead | 09:26 | |
| mvo | hm, maybe | 09:27 |
| zyga | mvo: another idea, let the version be whatever but teach snap info to publish key-value meta-date like git-hash build-date and other nice stuff | 09:27 |
| * mvo looks at it | 09:27 | |
| zyga | mvo: no need to cram it into version and also useful for other | 09:27 |
| ogra_ | we want a clear distinction between stable and non stable builds in the snap version too though | 09:28 |
| zyga | fine, I bet we can do that somehow too | 09:28 |
| ogra_ | (so that you dont need to actually run an image to determine the version) | 09:29 |
| mup | PR snapd#3327 opened: tests/main/listing: tweak core version regexp <Created by chipaca> <https://github.com/snapcore/snapd/pull/3327> | 09:29 |
| Chipaca | zyga, mvo: ^ | 09:30 |
| zyga | reviewed | 09:31 |
| * zyga -> coffee break | 09:35 | |
| Chipaca | zyga: i'm going to need a timeframe on "this test needs to be different because this thing will change at some time when the stars align" :-) | 09:36 |
| pedronis | mvo: hi, could you look at snapd#3323 again ? | 09:37 |
| mup | PR snapd#3323: overlord/snapstate: avoid creating command aliases for daemons <Created by pedronis> <https://github.com/snapcore/snapd/pull/3323> | 09:37 |
| mvo | Chipaca, zyga, ogra_: how about this as a compromise? http://paste.ubuntu.com/24586017/ | 09:38 |
| zyga | Chipaca: hmm? | 09:38 |
| Chipaca | mvo: does it fit one more character? | 09:38 |
| mvo | Chipaca: yes | 09:39 |
| Chipaca | in fact does it fit five more :-( | 09:39 |
| mvo | Chipaca: no | 09:39 |
| mvo | Chipaca: ;) | 09:39 |
| Chipaca | figured as much | 09:39 |
| zyga | mvo: do we really need the date? | 09:39 |
| Chipaca | mvo: zyga says the 16-2 at the start will change to 16-2.24.1 | 09:39 |
| Chipaca | at which point this will not fit | 09:40 |
| mvo | zyga: I thought we did but I may misremember | 09:40 |
| morphis | zyga: did you saw you're going to look into the problem with the unnecessary bind call snapctl issues and then gets killed by seccomp? | 09:41 |
| mvo | zyga, Chipaca: we could shorten 2017 to 17 and get two chars | 09:41 |
| mvo | Chipaca, zyga: but I think we should keep it as is for now (fix the test of course) and talk about it in the standup, I have the feeling in the discussion there it may change anyway (because high bandwidth discussion etc) | 09:42 |
| zyga | morphis: yes, I recall this but I need to fix update-ns run-from-core and unit tests first | 09:45 |
| zyga | mvo: 17 will look confusing, how about just date and hash? | 09:45 |
| morphis | zyga: so something you're going to look into for 2.27? | 09:45 |
| zyga | mvo: 16-2.24.1-20170516+git.... | 09:45 |
| zyga | morphis: yes, certainly | 09:46 |
| morphis | zyga: ok, lets add that to https://forum.snapcraft.io/t/next-snapd-2-27/572/2 | 09:46 |
| morphis | will see if there is a bug | 09:46 |
| morphis | mvo: can you add https://bugs.launchpad.net/snappy/+bug/1644573 to the 2.27 page? | 09:47 |
| mup | Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1644573> | 09:47 |
| Chipaca | zyga: mvo: agreed to not change until discussed, seems there are lot of options | 09:47 |
| Chipaca | zyga: mvo: and not sure at this point what questions we want to answer from that information :-) | 09:47 |
| zyga | Chipaca: one option is to raise the limit :) | 09:48 |
| Chipaca | if we have just the timestamp, you need to check master to see what commit we were at at that timestamp, and then check if that contains whatever branch it is you're interested in | 09:48 |
| Chipaca | whereas if what you're wanting to answer is "is this edge from last night", you're done | 09:48 |
| Chipaca | if you have the commit, you need to check master to see if that commit contains whatever it is you're after | 09:48 |
| mvo | morphis: sure, will do. the page should be a wiki so you can also add it if you want | 09:49 |
| Chipaca | and if you're wanting to answer "is this edge from last night", you need to check what commit it was | 09:49 |
| morphis | mvo: last time I checked, I couldn't | 09:49 |
| Chipaca | or rather, you need to check if that commit is one of the ones from last night | 09:49 |
| Chipaca | which means looking for one random string in a collection of random strings, which is worse | 09:49 |
| Chipaca | which is why i prefer the timestamp | 09:50 |
| mvo | morphis: that means I suck, let me fix it | 09:50 |
| mvo | morphis: maybe something else is funny, it is marked as a wiki | 09:50 |
| mvo | morphis: added it now | 09:52 |
| morphis | mvo: maybe just for a few people? | 09:52 |
| mvo | morphis: good question | 09:52 |
| mvo | fgimenez: any news on that uboot.env file? just curious because I'm slightly worried about this one | 09:53 |
| fgimenez_ | mvo: not yet, still running the scenario in which we execute the suite after upgrading from stable, it'll finish soon though (91/116 pi3 and 57/116 pi2) | 09:56 |
| * Chipaca takes a coffee break | 10:01 | |
| zyga | re | 10:03 |
| zyga | Chipaca: can you have a look at https://github.com/snapcore/snapd/pull/3326 when you're back please | 10:05 |
| mup | PR snapd#3326: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <https://github.com/snapcore/snapd/pull/3326> | 10:05 |
| Chipaca | zyga: i didn't get to leave yet | 10:05 |
| Chipaca | looking | 10:06 |
| zyga | Chipaca: I need to re-add some of the logging | 10:06 |
| zyga | Chipaca: for tests to be happy | 10:06 |
| zyga | Chipaca: but this (or similar) has to land to unbreak edge | 10:06 |
| Chipaca | zyga: having a list of distros not to reexec in seems weird | 10:07 |
| Chipaca | (yes i know that's already there) | 10:07 |
| zyga | Chipaca: yes but there's a good reason for that for now | 10:07 |
| zyga | Chipaca: once we have CI I'd like to pop fedora from that list | 10:08 |
| Chipaca | zyga: which is that reason? | 10:08 |
| zyga | Chipaca: snap-confine still has some build-time choices | 10:08 |
| Chipaca | zyga: it sounds to me like we should have a list of distros to reexec in, not the other way around | 10:08 |
| zyga | Chipaca: and we must build snap-confine in a way to have more flexibility there (talk to snapd) | 10:08 |
| Chipaca | OTOH, infinite derivatives | 10:08 |
| zyga | Chipaca: I think this list can be removed soon | 10:08 |
| zyga | Chipaca: it's more like "do I ship with patches" | 10:09 |
| zyga | Chipaca: and "is snap-confine from core useful to me" | 10:09 |
| zyga | Chipaca: but those can be patched in the distro as well :) | 10:09 |
| pedronis | Chipaca: so master is broken ? | 10:09 |
| zyga | Chipaca: we also don't re-exec in places that are not tested, it makes it more likely that we get a working result | 10:09 |
| Chipaca | pedronis: well, there's a failing test | 10:10 |
| zyga | pedronis: master is broken wrt the new core version | 10:10 |
| zyga | pedronis: and edge is broken wrt update-ns not running from core | 10:10 |
| zyga | pedronis: (but not broken in any test) | 10:10 |
| pedronis | well, I see this too: subprocess.CalledProcessError: Command 'tail -n 10 /var/log/syslog' returned non-zero exit status 1 | 10:10 |
| pedronis | in interfaces-log-observe | 10:11 |
| pedronis | is that fixed somewhere | 10:11 |
| pedronis | zyga: we don't have CI for core ? | 10:11 |
| pedronis | or not enough of it | 10:12 |
| pedronis | I mena the project | 10:12 |
| pedronis | s/mena/mean/ | 10:12 |
| Chipaca | pedronis: as soon as snapd#3327 lands we're good again | 10:12 |
| mup | PR snapd#3327: tests/main/listing: tweak core version regexp <Created by chipaca> <https://github.com/snapcore/snapd/pull/3327> | 10:12 |
| Chipaca | pedronis: ah. ouch. | 10:12 |
| pedronis | Chipaca: is log-observe stuff already fixed? | 10:12 |
| Chipaca | no | 10:12 |
| pedronis | :( | 10:12 |
| Chipaca | i'll fix that when i come back from my break | 10:12 |
| Chipaca | but now, i'm going to go take that break | 10:12 |
| * Chipaca has been trying for a while now :-) | 10:12 | |
| zyga | pedronis: our upgrade tests are very basic and don't catch this issue | 10:13 |
| pedronis | zyga: sounds like core project CI should run all the spread tests too, before we break snapd own development (maybe base snaps will claritfy this) | 10:16 |
| zyga | pedronis: all from that version, yes | 10:16 |
| * zyga runs spread locally to fix some issues | 10:27 | |
| Chipaca | i'm going to piggyback the log-observe fix on the listing fix | 10:32 |
| zyga | Chipaca: I'll merge master into my fix, hopefully this will unbreak everything | 10:37 |
| zyga | (when your branch lands) | 10:37 |
| Chipaca | here's hoping | 10:38 |
| fgimenez | mvo: zyga the crash happened again while executing the suite on a pi2 stable image with core refreshed to beta, this is uboot.env https://dl.dropboxusercontent.com/s/8c4yfyfca5rldza/uboot.env?dl=0, the output of fw_printenv http://paste.ubuntu.com/24586332/ and syslog http://paste.ubuntu.com/24586332/ let me know if you need anything else | 10:42 |
| zyga | fgimenez: ! thank you | 10:42 |
| zyga | fgimenez: I think the sylong link is incorrect | 10:43 |
| zyga | heh | 10:43 |
| zyga | incrementing URL by one yields some homework | 10:43 |
| fgimenez | zyga: mvo yep sorry, this one http://paste.ubuntu.com/24586341/ | 10:44 |
| zyga | thanks | 10:44 |
| fgimenez | there's also this failure in the execution of tests/main/ubuntu-core-classic http://paste.ubuntu.com/24586382/ it happens before the crash and seems unrelated | 10:48 |
| zyga | fgimenez: interesting, that doesn't fail with master (I can load the file) | 10:51 |
| zyga | fgimenez: (master uboot-go) | 10:51 |
| zyga | fgimenez: I'm checking what the problem might be | 10:52 |
| zyga | still, the panic is in parseData as before | 10:52 |
| zyga | May 16 08:46:18 localhost snapd[1174]: github.com/snapcore/snapd/vendor/github.com/mvo5/uboot-go/uenv.parseData(0x34e68005, 0x1fffb, 0x3fdfb, 0x5d18aa1) | 10:52 |
| zyga | Chipaca: rewrote your branch description a little | 10:56 |
| zyga | fgimenez, mvo: this is actually fixed by an earlier commit that we didn't simply use in snapd | 10:57 |
| zyga | fgimenez: 69978a3e4b05cca9d7cfee489b3453dfed45e72c fix incorrect handling of \0\0 EOF in a uboot.env fil | 10:57 |
| zyga | fgimenez: so simply syncing vendor.json will fix it | 10:57 |
| zyga | fgimenez: we should add a periodic task to sync vendor.json on each new dev cycle | 10:58 |
| zyga | mvo: ^^ | 10:58 |
| zyga | (and review the changes) | 10:58 |
| * zyga vents mind | 11:05 | |
| fgimenez | zyga: sounds very good, i'll prepare a spread-cron branch for it, do you think that proposing a PR to snapcore/snapd should be ok? | 11:10 |
| mvo | zyga: yeah | 11:11 |
| mvo | zyga: thanks for investigating | 11:11 |
| mvo | zyga, fgimenez: we just need to make sure we carefully review those dependency updates, but +1 otherwise | 11:11 |
| zyga | fgimenez: yes, I think this is even better as long as we review it carefully each time | 11:14 |
| Chipaca | zyga: go go go | 11:19 |
| zyga | Chipaca: thanks! | 11:19 |
| mup | PR snapd#3327 closed: tests: fix failing tests (snap core version, syslog changes) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3327> | 11:19 |
| zyga | Chipaca: 2nd review on https://github.com/snapcore/snapd/pull/3289 will make us have just 20 PRs open :) | 11:21 |
| mup | PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289> | 11:22 |
| mup | PR snapd#3321 closed: wrappers: service start/stop were inconsistent <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3321> | 11:22 |
| zyga | mvo: can you please do the 2nd review on https://github.com/snapcore/snapd/pull/3326 | 11:26 |
| mup | PR snapd#3326: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <https://github.com/snapcore/snapd/pull/3326> | 11:26 |
| zyga | mvo: this will unbreak edge builds | 11:26 |
| zyga | mvo: and once it lands we should try to build another core snap | 11:26 |
| mup | PR snapd#3289 closed: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3289> | 11:26 |
| NicolinoCuralli | hi guys another question about signing : what ubuntu-image deposits on image of gpg bundle? | 11:28 |
| zyga | NicolinoCuralli: what is "gpg bundle"? | 11:29 |
| zyga | NicolinoCuralli: ubuntu-image drops assertions into the image | 11:30 |
| zyga | NicolinoCuralli: and assertions are signed with various keys | 11:30 |
| NicolinoCuralli | zyga: thank, you mean "sudo ubuntu-image -c beta -o pi3-test.img pi3.model" drops assertion pi3.model into the image pi3-test.img | 11:33 |
| zyga | NicolinoCuralli: yes, it drops a feed of assertions that snapd imports on first boot | 11:36 |
| === chihchun is now known as chihchun_afk | ||
| NicolinoCuralli | zyga: the previous question is preparatory to another about serial-assertion , serial-vault configuration and Store | 11:39 |
| NicolinoCuralli | how store check that serial assertion is signed from the same key which signed model assertion? it seem a feature of brand store | 11:41 |
| zyga | NicolinoCuralli: I think this is a pedronis question | 11:42 |
| pedronis | NicolinoCuralli: that's not exactly what the store checks, what the store can check is that the brand store brand matches the authority-id of the serial | 11:42 |
| pedronis | and that the serial embedded key is the key of the device | 11:44 |
| NicolinoCuralli | how the device key is generated? | 11:44 |
| pedronis | at the moment is a software key, but we do plan to support hardware keys at some point | 11:45 |
| NicolinoCuralli | is this device key unique for device ? | 11:45 |
| pedronis | yes | 11:46 |
| pedronis | of course the store also checks that the signature of the serial itself was done with one of the authority-id == brand keys | 11:46 |
| Chipaca | looks like we'll be supporting the android bootloader soon \o/ | 11:47 |
| pedronis | NicolinoCuralli: there are 3 flows involved here, device registration that produces the serial, then exchanging a serial + device key proof with a device session, and then using of the device session | 11:47 |
| * zyga lunch | 11:48 | |
| Chipaca | lunch! what a good idea | 11:48 |
| * Chipaca is feeling lazy today though | 11:49 | |
| NicolinoCuralli | pedronis: is it a good idea open a thread about this on forum ? | 11:49 |
| pedronis | NicolinoCuralli: it's all in the code | 11:49 |
| NicolinoCuralli | yes, i see but it is more accessible explain the flow with a sequence diagram ( i can make it) | 11:51 |
| pedronis | NicolinoCuralli: ah, I misunderstood your question | 11:52 |
| NicolinoCuralli | i wiould like open a thread on forum with answer from you about my previous question and describe the process with a sequence diagram | 11:53 |
| pedronis | NicolinoCuralli: yes, you can open a forum topic | 11:53 |
| NicolinoCuralli | another question: in Serial Vault what is the paramenter for pointing the private part of gpg key | 11:54 |
| pedronis | NicolinoCuralli: that's configured afair | 11:55 |
| pedronis | model -> private key | 11:55 |
| dragly | Hi. Is there a way to get the real home path of the user inside a snap? | 11:57 |
| dragly | File dialogs are currently broken because the Home-button doesn't take the user to the real $HOME directory, but the shadowed one that points to $HOME/snap/appname/version. | 11:58 |
| NicolinoCuralli | pedronis: it means here serial-vault:8080/models/keypairs/new? | 11:59 |
| ogra_ | there is an interface for accessing home, yes | 11:59 |
| ogra_ | but not sure that influences the default path of the file manager | 11:59 |
| pedronis | NicolinoCuralli: yes, somewhere there | 12:00 |
| zyga | dragly: hey, not yet | 12:05 |
| zyga | dragly: I was thinking about this actually and I'll add something | 12:05 |
| zyga | ogra_: it doesn't | 12:05 |
| ogra_ | yeah, thought so | 12:06 |
| zyga | dragly: I think home cannot change back and forth (environment cannot be changed in existing processes) | 12:06 |
| zyga | dragly: but we should expose the old value of HOME | 12:06 |
| dragly | zyga: Great! In the meantime we will just `export HOME=/home/$USER` | 12:06 |
| dragly | or does that break everything? :-) | 12:07 |
| zyga | dragly: well, that will break everyrthing | 12:08 |
| zyga | dragly: and that will never be the proper fix | 12:08 |
| dragly | yes, I figured something was wrong when it ended up exposing all the hidden files in $HOME as well | 12:08 |
| dragly | app config files are also loaded non-sandboxed | 12:09 |
| zyga | dragly: I think that the long-term proper fix is to use xdg portals | 12:09 |
| zyga | dragly: but we can teach specific software, during a transition phase, to load say $SNAP_OLD_HOME | 12:09 |
| zyga | dragly: but this is very very specific to special cases | 12:09 |
| zyga | dragly: and won't work as a generic solution | 12:09 |
| zyga | dragly: for that morphis is looking at portal code | 12:10 |
| dragly | zyga: seems like a security issue though. snap developers can give their apps access to hidden files by setting $HOME in their launcher scripts. | 12:11 |
| dragly | zyga: yes, seems like Qt, Gtk and alike also would need to use a different env variable for the home button in their dialogs. | 12:12 |
| zyga | dragly: no | 12:15 |
| zyga | dragly: security is totally not dependant on HOME | 12:16 |
| zyga | dragly: for qt and gtk they are already being made to use portals | 12:16 |
| pedronis | mvo: hi, would appreciate a review of #3322 , do you some PRs that neeed my review ? | 12:24 |
| pedronis | snapd#3322 | 12:25 |
| mup | PR snapd#3322: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322> | 12:25 |
| mup | PR core#43 opened: remove generated logs, cleaner lsb-release removal <Created by ogra1> <https://github.com/snapcore/core/pull/43> | 12:35 |
| mup | PR snapd#3328 opened: Snapctl outside hooks v2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/3328> | 12:35 |
| morphis | mvo, ogra_: do we support cloud-init today on our ubuntu-core iamges? | 12:38 |
| mup | PR snapcraft#1311 closed: add missing VCS dependencies to HACKING.md <Created by felicianotech> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1311> | 12:38 |
| mup | PR snapcraft#1312 closed: state: fix the name of the source details <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1312> | 12:38 |
| ogra_ | morphis, kind of (if we dont yet, it is definitely in the works) | 12:38 |
| morphis | ogra_: kind of means I can sideload a cloud-script and it gets executed on boot? | 12:39 |
| ogra_ | morphis, we recently landed a bunch of changes from rharper that are supposed to make clud-init fully work | 12:39 |
| ogra_ | iirc your gadget needs to ship the initial config ... not sure about sideloading | 12:40 |
| morphis | hm | 12:40 |
| ogra_ | morphis, talk to rharper | 12:40 |
| morphis | ogra_: so not possible to put one into the writable partition? | 12:40 |
| morphis | rharper: ping :-) | 12:40 |
| ogra_ | (i assume you could just put it there, after all the gadget does the same ... but i dont know if ubuntu-image does anything additionally) | 12:41 |
| mup | PR snapcraft#1309 closed: meta: read and write the desktop file with utf-8 encoding <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1309> | 12:47 |
| mup | PR snapcraft#1308 closed: allow capital Y to accept the dev agreement <Created by felicianotech> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1308> | 12:53 |
| dragly | zyga: that is strange, because when we override $HOME, we were able to access hidden folders. The only difference was that it was installed with dangerous AFAIK. | 12:55 |
| dragly | I can see if I'm able to reproduce it with a minimal example | 12:55 |
| pedronis | dragly: it was probably devmode? (dangerous doesn't control confinement) | 12:55 |
| dragly | No, it was strict | 12:56 |
| pedronis | weird | 12:56 |
| dragly | Haven't tested devmode in weeks | 12:56 |
| zyga | dragly: that means that confinement is off | 12:56 |
| zyga | dragly: no need to reproduce | 12:56 |
| zyga | dragly: --dangerous installs your snap with confinement set to non-enforcing mode | 12:57 |
| zyga | dragly: --dangerous implies --devmode AFAIR | 12:57 |
| * zyga looks | 12:57 | |
| zyga | ah, the reverse | 12:57 |
| zyga | what does snap info that-snap-name tells you | 12:58 |
| dragly | Oh... But how do you test confinement? I can't installinstal local snaps without dangerous because of signing. | 12:58 |
| dragly | I'll check when I'm at my machine | 12:58 |
| zyga | dragly: I was wrong, | 12:59 |
| zyga | dragly: it should be confined | 12:59 |
| zyga | --devmode implies --dangerous, not the other way around | 12:59 |
| pedronis | yes | 13:00 |
| Facu | elopio, sergiusens, may I get feedback on https://forum.snapcraft.io/t/in-progress-snapcraft-2-30/347/13 ? I'm interested into knowing if that work would be relased into 2.30 or not | 13:19 |
| Facu | roadmr, ↑ | 13:19 |
| mup | PR snapcraft#1304 closed: cleanbuild: set the container language to C.UTF-8 <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1304> | 13:26 |
| zyga | mvo: http://paste.ubuntu.com/24586959/ | 13:30 |
| zyga | mvo: this is the diff if we sync all vendorized bits | 13:30 |
| zyga | pedronis: it also includes golang.org/x/crypto | 13:30 |
| mup | PR snapd#3292 opened: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <https://github.com/snapcore/snapd/pull/3292> | 13:31 |
| pedronis | zyga: if we are doing this there's a couple we can remove | 13:32 |
| pedronis | I think | 13:32 |
| zyga | pedronis: yes, I think we can drop a few | 13:32 |
| zyga | let me see if govendor helps with this | 13:32 |
| zyga | (websocket I think) | 13:32 |
| zyga | vu github.com/gorilla/websocket | 13:32 |
| zyga | vu github.com/testing-cabal/subunit-go | 13:32 |
| zyga | we can drop those | 13:32 |
| zyga | mvo: do you want a PR that removes those? | 13:33 |
| mvo | zyga: yes please | 13:33 |
| AdamH_ | zyga: Apologies been away from the desktop. If providing those files is still useful let me know and will sort out | 13:34 |
| mup | PR snapd#3329 opened: vendor: remove unused pacakges <Created by zyga> <https://github.com/snapcore/snapd/pull/3329> | 13:35 |
| zyga | AdamH_: yes, it might be useful though if you don't want to just report a bug about this with enough details | 13:36 |
| pedronis | zyga: Chipaca: main change seems we get some assembler opt for sha3 on amd64, hopefully the code is correct | 13:42 |
| zyga | pedronis: amd64 or arm64? | 13:43 |
| pedronis | amd64 | 13:43 |
| zyga | pedronis: ok, if you want I can propose a isolated patch for that | 13:43 |
| pedronis | ? | 13:44 |
| zyga | pedronis: for that part of vendor.json | 13:44 |
| rharper | morphis: here, what's up ? | 13:47 |
| pedronis | zyga: that change is from Dec 2016, so it's been out a bit | 13:49 |
| pedronis | as you prefer | 13:49 |
| mvo | fgimenez: what revision is the pi2 gadget snap of the failing image? | 13:51 |
| fgimenez | mvo: let me check 1sec | 13:51 |
| pedronis | even earlier actually | 13:51 |
| fgimenez | mvo: in pi3 it is rev6 http://paste.ubuntu.com/24587045/ i'm currently using the pi2 for double checking 2.25, i can reflash it later with 2.26 if needed | 13:55 |
| mvo | fgimenez: is the https://dl.dropboxusercontent.com/s/8c4yfyfca5rldza/uboot.env?dl=0, from the pi2 or the pi3? | 13:58 |
| mvo | fgimenez: pardon my ignorance here | 13:58 |
| rharper | morphis: reading backscroll, there are a few things to be resolved before it's all blessed; Testing the edge image last week, ran into this issue https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1689944, will need to get that fixed in cloud-init or workaround it by creating one of the two files/dirs checked already by cloud-init; Next is for now, when building images, snap prepare will disable cloud-init unless | 13:58 |
| rharper | you provide a config in the gadget; I've a branch which would remove that given that current cloud-init won't automatically run anymore unless you provide it configuration; (https://github.com/raharper/snapd/commit/3e83b3aa281f02bce9a230a812ad4f02d0d66c22) ; both can be worked around with some massaging of the image in the short term; I'm happy to help out there; After that, it's a matter of supplying cloud-config via | 13:58 |
| mup | Bug #1689944: util.system_is_snappy needs additional checks <cloud-init (Ubuntu):New> <https://launchpad.net/bugs/1689944> | 13:58 |
| rharper | a ConfigDrive or some other DataSource that cloud-init understands (http://cloudinit.readthedocs.io/en/latest/topics/datasources.html) | 13:58 |
| fgimenez | mvo: pi2, it is the last one that failed | 13:58 |
| mvo | fgimenez: thank you, then lets wait for the results of pi2 with 2.25 | 13:59 |
| mvo | fgimenez: still a bit of a mystery :) | 13:59 |
| * pedronis break | 13:59 | |
| fgimenez | mvo: yep :) let's see, will let you know how it goes | 14:00 |
| Chipaca | rharper: when you say "cloud-init won't automatically run anymore unless you provide it configuration", does that really mean it doesn't run, or does that mean it starts up, sees it has no configuration, and exits? | 14:04 |
| rharper | at systemd-generator time it checks for known cloud signatures and files which indicate there is data to consume; this is non-python code which determins if we actually invoke /usr/bin/cloud-init later on in start-up | 14:05 |
| rharper | this avoids invoking the python binary and library load unless you actually need to (ie, you have cloud configuration or user-data you want to apply) | 14:05 |
| Chipaca | excellent | 14:05 |
| morphis | rharper: ok, good to know, was using an image build from stable and did remove the flag prepare-image put in to disable cloud-init | 14:15 |
| rharper | stable requires more work | 14:15 |
| rharper | as it does not yet have an updated cloud-init | 14:15 |
| zyga | spread is sad | 14:16 |
| zyga | travis is sad | 14:16 |
| zyga | are we using all test slots? | 14:16 |
| * Chipaca hugs zyga | 14:16 | |
| Chipaca | don't you be sad as well | 14:16 |
| zyga | I see just two yellow boxes on PRs | 14:16 |
| zyga | but travis is not starting | 14:16 |
| mup | PR snapd#3330 opened: fail if unused dependencies are found <Created by mvo5> <https://github.com/snapcore/snapd/pull/3330> | 14:17 |
| === rye is now known as ryebot | ||
| morphis | rharper: I see, but with edge I should get a cloud-config I supply with ubuntu-image working? | 14:20 |
| mup | PR snapcraft#1319 opened: kernel plugin: config check: remove DMIID option <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1319> | 14:20 |
| verterok | Hi, getting a weird (*new*) error while installing prometheus snap (using juju charm) | 14:36 |
| verterok | basically the promtool binary is failing with: cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied | 14:37 |
| verterok | it gets "fixed" after rebooting the instance/machine | 14:38 |
| zyga | verterok: hey | 14:38 |
| verterok | zyga: hola! | 14:38 |
| zyga | verterok: can you tell me more about your system, what does 'snap version' say? | 14:38 |
| verterok | zyga: Chipaca told me you would be interested in that ^ :) | 14:38 |
| zyga | verterok: hola :) | 14:38 |
| verterok | zyga: it's trusty, let me get the version | 14:39 |
| zyga | aha | 14:39 |
| zyga | using 14.04 kernel/ | 14:39 |
| zyga | or LTS enablement kernel? | 14:39 |
| verterok | zyga: http://paste.ubuntu.com/24587234/ | 14:39 |
| zyga | I see | 14:39 |
| zyga | well that is interesting | 14:40 |
| zyga | can you get me dmesg | grep DENIED | 14:40 |
| verterok | zyga: this is prodstack4.5 | 14:40 |
| zyga | and is that the latest kernel you can get (from the 4.4 series) | 14:40 |
| zyga | I want to eliminate known issues that may be lurking | 14:40 |
| verterok | zyga: it's a freshly booted instance, let me apt update and see what is available | 14:41 |
| zyga | verterok: please! | 14:41 |
| zyga | verterok: and if you can also check dmesg | 14:41 |
| zyga | verterok: I think it is most interesting here | 14:41 |
| verterok | zyga: http://paste.ubuntu.com/24587246/ | 14:41 |
| zyga | verterok: and if you see a kernel upgrade available, take it and reboot | 14:41 |
| verterok | dmesg ^ | 14:41 |
| verterok | zyga: it worked after rebooting | 14:41 |
| zyga | oh | 14:41 |
| zyga | [ 16.794142] audit: type=1400 audit(1494943609.127:13): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="unconfined" name="snap.prometheus.prometheus" pid=1020 comm="snap-confine" | 14:41 |
| zyga | does prometheus (I don't know what it is) tries to run other snap commands? | 14:42 |
| Chipaca | zyga: the son of iapetus | 14:42 |
| zyga | Chipaca: well that fixes it ;) | 14:43 |
| Chipaca | also of clymene | 14:43 |
| Chipaca | got his liver eaten by a vulture | 14:43 |
| verterok | zyga: prometheus is a timeseries DB + scrapper to collect metrics | 14:43 |
| zyga | verterok: ok, is it a strictly confined snap? | 14:43 |
| verterok | zyga: no idea, how can I check? | 14:44 |
| zyga | verterok: snap list | grep prometheus | 14:44 |
| ogra_ | Chipaca, with apples and onions ? | 14:44 |
| verterok | zyga: snap list | grep prometheus | 14:44 |
| verterok | prometheus 1.5.2 11 jacek - | 14:44 |
| zyga | ok | 14:44 |
| Chipaca | ogra_: also the guy that stole fire from olympus and gave it to mankind | 14:44 |
| zyga | verterok: so this seems to be a strictly confined snap | 14:44 |
| ogra_ | yeah | 14:44 |
| rharper | morphis: not yet, we need to fix the cloud-init bug I mentioned earlier ; ogra_ do you know when or why the /etc/system-image/config.d directory got removed? looking at the previous core snaps it had been present but empty; was it just pruned? | 14:44 |
| * Chipaca shuts up about the greeks | 14:44 | |
| zyga | verterok: but it seems to want to run apps from other snaps | 14:44 |
| ogra_ | heh | 14:44 |
| zyga | verterok: do you have any idea why? | 14:45 |
| Chipaca | zyga: “snap list <snap name>” works :-) | 14:45 |
| zyga | Chipaca: oh, thanks | 14:45 |
| Chipaca | zyga: “snap list [snap...] | 14:45 |
| Chipaca | ” | 14:45 |
| verterok | zyga: it's failing to run an utility command provided by the prometheus snap itself | 14:45 |
| ogra_ | rharper, well, we havent used system-image since 15.04 ... | 14:45 |
| ogra_ | so that dir is a dead thing since quite a while | 14:46 |
| zyga | verterok: looks like a bug in the snap | 14:46 |
| verterok | zyga: worth noting it was working last week (I made a couple deploys of it) | 14:46 |
| ogra_ | writable-paths will soon move one level up and it will be gone completely | 14:46 |
| zyga | verterok: that utility should be invoked using internal name | 14:46 |
| zyga | verterok: not using the name exposed to the outside world | 14:46 |
| nacc | Chipaca: i am looking at the new completion functionality. If I use python3-argcomplete, is there a trivial way to hook into it? Do I basically take what python3-argcomplete's global enable and make that may app's completer? Note that I have to have two completers, actually, because 'git-ubuntu' and 'git ubuntu' go through different executables. Is that supported? | 14:46 |
| verterok | zyga: the juju charm fails while trying to tun: /snap/bin/prometheus.promtool version | 14:47 |
| Chipaca | nacc: there's no support for aliases yet | 14:47 |
| zyga | verterok: too many facts, I don't know all those snaps | 14:47 |
| ogra_ | rharper, do you mean between two stable versions ? i think /etc/system-image/config.d is gone since a lot longer already | 14:47 |
| zyga | verterok: snaps cannot run commands from other snaps | 14:47 |
| verterok | zyga: no idea what promtool is doing, but I think it's just a compiled go thing, no way to look inside easily | 14:47 |
| zyga | verterok: or even from their own snap | 14:47 |
| zyga | verterok: nothing from /snap/bin | 14:47 |
| nacc | Chipaca: aliases in what sense? you mean that `git-ubuntu` and `git ubuntu` both work? | 14:47 |
| Chipaca | nacc: but other than that, the completer is just the snippet you'd drop in /usr/share/bash-completion/completions | 14:47 |
| nacc | Chipaca: that's default git behavior | 14:48 |
| zyga | verterok: they can only run stuff they find locally (e.g. via $SNAP/bin/stuff) | 14:48 |
| rharper | ogra_: interesting, so maybe it was always gone in edge for quite some time then ? | 14:48 |
| ogra_ | yeah | 14:48 |
| zyga | verterok: default PATH should make that happen | 14:48 |
| rharper | I had typically built with stable or beta | 14:48 |
| Chipaca | nacc: sorry, maybe i misunderstood | 14:48 |
| ogra_ | did you use it for anything ? | 14:48 |
| zyga | verterok: that is, for snap application /snap is not on path | 14:48 |
| nacc | Chipaca: i already have (in my snap) `git-ubuntu` and `git ubuntu`. | 14:48 |
| rharper | cloud-init used to determine if the system was ubuntu-core or not | 14:48 |
| morphis | rharper: does cloud-init touch /etc/netplan? | 14:48 |
| Chipaca | nacc: are you snapping "git-ubuntu"? | 14:48 |
| ogra_ | rharper, uuuh | 14:48 |
| rharper | morphis: cloud-init support rendering netplan | 14:48 |
| zyga | verterok: I'm wondering why it sometimes "works" for you | 14:48 |
| morphis | rharper: more concrete, /etc/netplan/00-snapd-config.yaml? | 14:49 |
| zyga | verterok: can you tell me more about it | 14:49 |
| nacc | Chipaca: yeah, and both commands become available via the same snap | 14:49 |
| nacc | Chipaca: becuase of how `git` itself works (in a classic world where git is already installed, say) | 14:49 |
| Chipaca | nacc: right, but not via an alias but because git does that magic? | 14:49 |
| nacc | Chipaca: yeah | 14:49 |
| verterok | zyga: not sometimes, let me explain :) | 14:49 |
| Chipaca | nacc: and how does git plug into completion of its subcommands? | 14:49 |
| rharper | morphis: , yes, http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html | 14:49 |
| verterok | zyga: I'm using juju to deploy a prometheus "service" juju deploy cs:~prometheus-charmers/prometheus | 14:49 |
| nacc | Chipaca: right, it looks for me to add a shell snippet that defines _git_ubuntu into the .bashrc (or i think it if was in the completion directory that would work too) | 14:49 |
| verterok | zyga: that boot a openstack instance (trusty) | 14:50 |
| morphis | rharper: I enabled cloud-init in my image build with edge now and get an error in console-conf that the netplan file is invalid | 14:50 |
| nacc | Chipaca: but `git-ubuntu`'s completion is different | 14:50 |
| rharper | ogra_: at the time we added support it was the 15.04 image, (a/b partitions), then the new snaps came and os-release still had Xenial information; | 14:50 |
| nacc | Chipaca: so can i hve two completers for the same 'app'? | 14:50 |
| verterok | zyga: and run the prometheus charm, all that is classic stuff apt based | 14:50 |
| morphis | rharper: ala "set-name requires match properties" | 14:50 |
| ogra_ | rharper, yeah, for 15.04 that was okayish .. | 14:50 |
| verterok | zyga: then it install the prometheus snap | 14:50 |
| morphis | rharper: but could be console-conf too | 14:50 |
| verterok | zyga: and tries to use it, which is when it fails | 14:50 |
| rharper | morphis: that's a known issue with console-conf and cloud-init; cloud-init recognizes the baked in snap config, and should remove it; I've not yet determined why it failed to remove it, so you'll find two files in /etc/netplan/ | 14:51 |
| verterok | zyga: if I reboot the instance/machine, it works ok after | 14:51 |
| rharper | the 00-snapd one, as well as one that cloud-init rendered | 14:51 |
| morphis | rharper: ah I see | 14:51 |
| verterok | zyga: but until the instance is reboot, it keeps failing | 14:51 |
| zyga | verterok: wait, what is "it" in the sentence: < verterok> zyga: and tries to use it, which is when it fails | 14:51 |
| Chipaca | nacc: to answer your last question, no | 14:51 |
| verterok | zyga: the charm, think of it as a set of scripts to setup a service in a machine/instance | 14:51 |
| nacc | Chipaca: ok :( I guess I could write one that sources my two? :) | 14:52 |
| zyga | verterok: is any of this running inside containers? | 14:52 |
| verterok | zyga: nope | 14:52 |
| verterok | zyga: is all running in "real" VMs | 14:52 |
| Chipaca | nacc: there is no way to define _git_ubuntu in the user's shell from inside the snap | 14:52 |
| Chipaca | nacc: so that is not going to work, even if you did it | 14:52 |
| zyga | verterok: hmm hmm hmm | 14:53 |
| rharper | ogra_: I've a bug against cloud-init to add additional methods to detect cloud-init is on ubuntu-core (https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1689944) ; | 14:53 |
| mup | Bug #1689944: util.system_is_snappy needs additional checks <cloud-init (Ubuntu):New> <https://launchpad.net/bugs/1689944> | 14:53 |
| fgimenez | mvo: it looks that https://github.com/snapcore/snapd/commit/08f60b88c28416dc627308b619b6ffdbbb2cd593 somehow made it to the release/2.25 branch and is making tests/main/snap-connect fail (no --last option in 2.25's snap tasks), other than that the tests on pi2 are good so far (28/115) | 14:53 |
| zyga | verterok: I need to play with this more, can you tell me how to reproduce this? I have 14.04 around | 14:53 |
| zyga | verterok: just a few basic commands, maybe just the snap part | 14:53 |
| zyga | verterok: the charm/juju side feels like not a factor | 14:53 |
| verterok | zyga: indeed | 14:54 |
| verterok | zyga: let me extract the commands run by the charm | 14:54 |
| rharper | ogra_: would it be terrible in the core-build config to re-create the config.d dir (would something eles break if it were present but empty) ? | 14:54 |
| Chipaca | nacc: OTOH, git-ubuntu is a classic snap, so it can do anything | 14:54 |
| ogra_ | rharper, it would be very ugly | 14:54 |
| nacc | Chipaca: in classic there is, just not automatically | 14:54 |
| rharper | ogra_: ok | 14:54 |
| nacc | Chipaca: right :) | 14:54 |
| ogra_ | rharper, it shouldnt have been used in the first place really ... use os-release ... thats reliable ... or if you need the info earlier, use the cmdline | 14:55 |
| Chipaca | nacc: if it's going to remain classic, I don't think the confined completion support really buys you anything | 14:55 |
| rharper | ogra_: the os-release at the time it was added didn't yet differ from Xenial | 14:55 |
| zyga | verterok: thanks! | 14:55 |
| Chipaca | nacc: and it can do things automaticall by, for example, dropping a file in /usr/share/bash-completion/completions from the configure script | 14:56 |
| ogra_ | rharper, yes, but that was fixed :) | 14:56 |
| ogra_ | (actually in 15.04 already IIRC) | 14:56 |
| === shadeslayer_ is now known as shadeslayer | ||
| nacc | Chipaca: are there explicit post-install steps? Or do you mean, I can just organize my snap to write there? | 14:57 |
| Chipaca | nacc: (note we don't yet have an "uninstall" hook, so make it resilient to your snap not being there...) | 14:57 |
| ogra_ | /etc/os-release is definitely not dropping the ID=ubuntu-core | 14:57 |
| NicolinoCuralli | pedronis: i have some problem to understand where SerialVualt take the authority-id for build the serial assertion for a device | 14:57 |
| rharper | ogra_: ok; I'd appreciate a comment on that cloud-init bug w.r.t which you feel are the most stable moving forward, and we'll fix up the detection and likely include as many that are stable | 14:58 |
| * rharper eyes another cloud-init sru to xenial | 14:58 | |
| Chipaca | nacc: post-install steps, no. There's a configure hook. | 14:59 |
| Chipaca | nacc: which is called on install | 14:59 |
| nacc | Chipaca: ah i see it now | 15:00 |
| nacc | Chipaca: sorry, wasn't there before (when i was using snaps earlier, i mean). Will read. | 15:00 |
| Chipaca | nacc: https://github.com/snapcore/snapd/wiki/hooks#configure | 15:00 |
| nacc | Chipaca: thanks! | 15:00 |
| Chipaca | nacc: and AIUI there will be more hooks, better suited for what you want, but I might be wrong (haven't been paying attention), and no idea what timeframe | 15:01 |
| verterok | zyga: it's basically this: http://paste.ubuntu.com/24587337/ | 15:02 |
| verterok | zyga: let me try to repro manually | 15:03 |
| zyga | verterok: Thank you | 15:03 |
| zyga | booting 14.04 now | 15:03 |
| zyga | verterok: I have a theory but let me try it first :) | 15:03 |
| pedronis | NicolinoCuralli: in which sense? it's the brand-id in the serial-request | 15:05 |
| pedronis | that comes from the model assertion of the device | 15:06 |
| NicolinoCuralli | pedronis: brand-id is always equal to authority-id? what is the sense of duplicate use on serial assertion response? | 15:13 |
| pedronis | NicolinoCuralli: all assertions have an authority-id (the authority emitting them, and right now also the signer) | 15:14 |
| verterok | zyga: damn, I can't reproduce it manually (without juju and the charm) :( | 15:14 |
| verterok | jacekn: ^ FYI | 15:14 |
| nacc | Chipaca: thanks! | 15:14 |
| morphis | Pharaoh_Atem: did my log help you to update the snap-mgmt script? | 15:14 |
| zyga | verterok: aha, | 15:14 |
| * zyga found the charger for his VM host laptop | 15:14 | |
| pedronis | NicolinoCuralli: we decided it was more consistent to repeat the info (than to have different fields for that per assertion in some cases) | 15:14 |
| zyga | verterok: hmm hmm | 15:14 |
| zyga | verterok: I can install a server image and do more if that helps | 15:15 |
| Pharaoh_Atem | morphis: yeah, I'm going to prepare the 2.26.1 update during my lunch hour with the changes | 15:15 |
| morphis | Pharaoh_Atem: nice! | 15:15 |
| pedronis | NicolinoCuralli: also we are planning to support some cases where authority-id != brand-id (though atm they must be == ) for serial | 15:15 |
| zyga | verterok: but please give me instructions on how to reproduce | 15:15 |
| verterok | zyga: thanks, these are the full logs of my manual test: http://paste.ubuntu.com/24587397/ | 15:15 |
| ogra_ | mvo, lloking at our images ... there is still init=/lib/systemd/systemd --- shouldnt we be able to finally drop that ? | 15:15 |
| zyga | verterok: after installing manually you can add /snap/bin to path manually | 15:16 |
| zyga | verterok: ah but this then works OK | 15:16 |
| zyga | hmm hmm | 15:17 |
| verterok | zyga: yup, now trying to reproduce with juju and charm. doing a capture of the full logs (at least what the charm logs) | 15:17 |
| zyga | verterok: thank you! | 15:17 |
| ogra_ | mvo, testing with it dropped seems to work fine ... | 15:18 |
| zyga | mvo: merged and iterating | 15:19 |
| zyga | mvo: but edge should no longer be broken (just need a build) | 15:19 |
| mup | PR snapd#3326 closed: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3326> | 15:19 |
| verterok | zyga: ok, I'm not crazy...it seems :) reproduced, collecting full logs now | 15:21 |
| zyga | verterok: good! | 15:21 |
| ogra_ | mvo, oh ! ... seems i spoke to early | 15:23 |
| mvo | zyga: thanks for unbreaking master. will you do a followup to 3326 with the review comments? | 15:23 |
| ogra_ | ogra@pi3:~$ snap list | 15:23 |
| ogra_ | error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused | 15:23 |
| ogra_ | wow | 15:23 |
| mvo | ogra_: yeah, its still 16.04 so init itself is still upstart | 15:23 |
| * zyga goes to build core again | 15:23 | |
| dragly | zyga and pedronis: I am unable to reproduce the case where I had access to hidden files in $HOME now. | 15:24 |
| zyga | dragly: good :) | 15:24 |
| zyga | dragly: though it might be better if we did | 15:24 |
| dragly | We were trying out --classic earlier, so it might just have been because of that. | 15:25 |
| dragly | That we somehow had a version with --classic installed while testing. | 15:25 |
| NicolinoCuralli | pedronis : a question: on SerialVault i can upload a different gpg bundle different from Store? | 15:26 |
| pedronis | NicolinoCuralli: in which sense? | 15:27 |
| pedronis | the store needs to check the signature of serials, so any key used to sign serials need to be registered with the store | 15:27 |
| NicolinoCuralli | pedronis: it means the i need to upload one of the key uploaded to Brand store? | 15:30 |
| pedronis | one of the keys registered (In snapcraft register-key) sense, yes | 15:30 |
| NicolinoCuralli | i mean upload a Brand Store key to Serial Vault by Admin UI? | 15:30 |
| pedronis | a brand key, registered with the store, yes | 15:31 |
| pedronis | (public) keys are not per store | 15:32 |
| NicolinoCuralli | pedronis : i mean one of gpg key registrered on the Brand Store | 15:34 |
| pedronis | NicolinoCuralli: we are probably talking about the same thing, but keys are registered with the store, not a specific substore | 15:35 |
| NicolinoCuralli | pedronis: ok we are talking about the same thing | 15:35 |
| zyga | Chipaca, verterok: so FYI, this issue is caused by running on top of 3.13 before a reboot applies a new kernel | 15:42 |
| verterok | jacekn: ^ this will surely affect new deploys using trusty. xenial is cool | 15:42 |
| zyga | mvo: we need to do something smarter in snapd/snap; I'd suggest that we bail out if on Ubuntu 14.04 and we're not on a 4.x kernel | 15:42 |
| zyga | with a simple message | 15:42 |
| zyga | this would be unique to "snap run" | 15:42 |
| zyga | which should catch "my snaps don't work at all" | 15:43 |
| zyga | but I worry about installing and running hooks | 15:43 |
| zyga | perhaps snapd should also refuse to do anything | 15:43 |
| zyga | (which may mean it cannot update itself either) | 15:43 |
| zyga | actually, it should not do anything at all (snapd) | 15:43 |
| Chipaca | zyga: what is 3.13? | 15:43 |
| zyga | mvo: ^^ I'll open a forum thread about this | 15:43 |
| zyga | Chipaca: 3.13 kernel that 14.04 systems start with | 15:43 |
| zyga | Chipaca: they only pull the LTS enablement kernel by installing snapd | 15:43 |
| Chipaca | zyga: uh, so the "snap version" verterok posted was post-reboot? | 15:43 |
| zyga | yes | 15:44 |
| zyga | we got to the bottom of this in a private chat where we exchanged more logs | 15:44 |
| Chipaca | verterok: so, yeah, installing a new kernel requires a reboot ¯\_(ツ)_/¯ :-) | 15:44 |
| === JamieBen_ is now known as JamieBennett | ||
| zyga | (we didn't want to leak any magic passwords or anything by accident) | 15:44 |
| zyga | Chipaca: sure but snapd packaging make this unobviou | 15:44 |
| Chipaca | zyga: that's fine | 15:44 |
| zyga | Chipaca: and the effects will worsen with time | 15:44 |
| verterok | Chipaca: I live in a world of ksplice and livepatch...never reboot! ;-) | 15:44 |
| Chipaca | zyga: anything that gives me a reason to make fun of verterok is good | 15:45 |
| Chipaca | zyga: (those chances are rare) | 15:45 |
| ogra_ | verterok, until the next systemd update indeed :P | 15:45 |
| ogra_ | (or upstart in case of 14.04) | 15:45 |
| Chipaca | verterok: well, if it were something newer than 14.04, you could've kexec'ed :-p | 15:45 |
| verterok | Chipaca: the problem is not snapd, but the charm that tries to use it right away and allow deploying on trusty :) | 15:46 |
| Chipaca | 14.04, or as we called it back then, MCD.IV | 15:46 |
| zyga | hmm launchpad times out for me... | 15:46 |
| Chipaca | + su -c 'SNAPPY_USE_STAGING_STORE=0 snap prepare-image --channel edge --extra-snaps snapweb /tmp/root/model.assertion /tmp/root' test | 15:48 |
| Chipaca | error: Please buy pi2 before installing it. | 15:48 |
| Chipaca | I thought we'd gotten rid of the bug where it thinks it needs to buy something? | 15:48 |
| verterok | zyga: something changed recently? this same deploy worked last week | 15:48 |
| zyga | verterok: no | 15:48 |
| zyga | verterok: well | 15:48 |
| zyga | verterok: maybe | 15:48 |
| verterok | maybe a bug fix? :) | 15:48 |
| zyga | verterok: but "work" is exaggerated | 15:49 |
| zyga | verterok: it's just it was never ever intended to work :-) | 15:49 |
| verterok | zyga: quite probably :) | 15:49 |
| zyga | verterok: as 3.13 is definitely too old to have working apparmor | 15:49 |
| verterok | so, we "just" need a could image with 4.x cooked in | 15:50 |
| zyga | verterok: for snaps, definitely | 15:50 |
| zyga | verterok: in fact, this is some feedback for clould team | 15:50 |
| zyga | verterok: for those that want 14.04 and snaps they need to start producing an image that works ootb | 15:50 |
| zyga | verterok: (good kernel at least, but maybe snapd preinstalled too) | 15:50 |
| morphis | mvo, niemeyer: shouldn't https://forum.snapcraft.io/t/in-progress-snapd-2-25/414 be marked as done? | 15:52 |
| morphis | mvo, niemeyer: or does the "In progress" just confuse me? | 15:52 |
| morphis | ah 2.25 isn't yet in stable | 15:53 |
| rharper | ogra_: thanks for the comments | 15:54 |
| ogra_ | np | 15:55 |
| pedronis | Chipaca: no, discussion was that it needs to be fixed on the store side | 15:55 |
| zyga | pstolowski: feedback on 3328 | 16:05 |
| mvo | morphis: correct, not quite in stable yet | 16:05 |
| pstolowski | zyga, thanks | 16:05 |
| morphis | mvo: just got a bit confused by the forum, sorry for the noise :-) | 16:08 |
| mvo | morphis: no worries | 16:08 |
| zyga | pstolowski: tomorrow I'll find my work on regexp-free validation | 16:10 |
| pstolowski | zyga, great, thanks! | 16:10 |
| mup | PR snapd#3325 closed: vendor,partition: fix panics from uenv <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3325> | 16:24 |
| === JanC_ is now known as JanC | ||
| zyga | mvo: +1 to merge coverage report? | 16:34 |
| zyga | mvo: I'd love to see it | 16:34 |
| mvo | zyga: +1 | 16:35 |
| mup | PR snapd#3313 closed: send things to codecov.io <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3313> | 16:36 |
| zyga | mvo: do you have the time to voice your preference on https://github.com/snapcore/snapd/pull/3308 | 16:37 |
| mup | PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308> | 16:37 |
| mvo | zyga: sorry :( looking now | 16:39 |
| mvo | zyga: after I uploaded 2.26.2 | 16:40 |
| mup | PR snapd#3331 opened: tests: remove unit tests task <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3331> | 16:48 |
| zyga | mvo: thank you for getting 2.26.2 out | 16:49 |
| * zyga hugs mvo | 16:49 | |
| zyga | mvo: is 2.26.2 a .1 + cherry pick or master snapshot? | 16:53 |
| zyga | mvo: I want to build snapd master and rebuild the core snap but I don't want to mess up your work | 16:55 |
| * zyga wonders if this abbreviates to "I should EOD" | 16:55 | |
| Chipaca | zyga: you could review snapd#3292 if not | 16:56 |
| mup | PR snapd#3292: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <https://github.com/snapcore/snapd/pull/3292> | 16:56 |
| Chipaca | also could use one other review | 16:56 |
| Chipaca | so feel free, other reviewers :-) | 16:56 |
| zyga | or that :) | 16:59 |
| * zyga does that now | 16:59 | |
| fgimenez | mvo: no crashes on the 2.25 execution http://paste.ubuntu.com/24587949/ the ubuntu-core-classic error also happened on 2.26.1, maybe something has changed in the classic snap | 17:00 |
| pedronis | mvo: somebody was mentioning problems with classic snap the other day | 17:08 |
| pedronis | mvo: <AdamH_> Any body else get the following when trying to install classic snap? Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/xenial/InRelease Could not resolve 'ports.ubuntu.com' | 17:10 |
| Chipaca | imma gonna eod | 17:11 |
| zyga | Chipaca: hey | 17:15 |
| zyga | Chipaca: have a look | 17:15 |
| zyga | I think there's a bug in your PR | 17:15 |
| zyga | pedronis: it's a bug that people mention | 17:16 |
| zyga | pedronis: but I don't know the cause yet | 17:16 |
| zyga | pedronis: do you see any errors in journalctl? | 17:16 |
| pedronis | zyga: where? | 17:17 |
| zyga | pedronis: maybe we got hit by something like DNSSEC? | 17:17 |
| zyga | pedronis: just run journalctl -f while this rusn | 17:17 |
| pedronis | that's not me reporting that | 17:17 |
| zyga | *run | 17:17 |
| pedronis | it's a user | 17:17 |
| zyga | pedronis: aaah | 17:17 |
| * zyga misread that | 17:17 | |
| zyga | sorry ;) | 17:17 |
| pedronis | well I misread "a clasisic snap" vs "the classic snap" when he reported it | 17:18 |
| pedronis | so fun | 17:18 |
| mup | PR snapd#3329 closed: vendor: remove unused packages <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3329> | 17:21 |
| pedronis | zyga: mvo: fun, just disovered timeutil.Next takes 1s+ when last is 0 | 17:23 |
| pedronis | because we have unittest now trying to schedule/running refreshes :/ | 17:23 |
| mup | PR snapd#3332 opened: interfaces/seccomp: document Backend.NewSpecification <Created by zyga> <https://github.com/snapcore/snapd/pull/3332> | 17:27 |
| mup | PR snapd#3333 opened: vendor: refresh everything <Created by zyga> <https://github.com/snapcore/snapd/pull/3333> | 17:35 |
| Chipaca | zyga: responded (with code!) | 17:43 |
| Chipaca | zyga: basically, you're wrong, neener neener neener | 17:43 |
| kenvandine | Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path | 17:56 |
| kenvandine | snapcraft validation file is missing from installation path | 17:56 |
| kenvandine | anyone know how to fix that? | 17:56 |
| kenvandine | i can't build anything anymore | 17:57 |
| kyrofa | kenvandine, are you running from source? | 18:03 |
| kenvandine | kyrofa, no | 18:04 |
| kenvandine | i'm on artful | 18:04 |
| kenvandine | using the package | 18:04 |
| kenvandine | it was fine a few minutes ago... | 18:04 |
| kenvandine | made a little change to my snapcraft.yaml and hit this | 18:04 |
| kenvandine | now i can't build anything | 18:04 |
| mvo | pedronis: meh :/ not cool. thanks for finding this! | 18:05 |
| pedronis | mvo: it seems we haven't really decided explicitly what to do when last-refresh is 0 | 18:05 |
| zyga | Chipaca: I'm glad to be shown wrong, thanks :) | 18:07 |
| kenvandine | kyrofa, any insight? | 18:09 |
| kyrofa | kenvandine, it should be looking in /usr/share/snapcraft/schema . Do you see anything in there? | 18:10 |
| kenvandine | yes | 18:10 |
| mvo | pedronis: indeed | 18:10 |
| kyrofa | kenvandine, try running with `-d` to turn on debugging mode. You'll see where that exception is thrown. Do you see what file it's trying to open? | 18:11 |
| * zyga really EODs | 18:12 | |
| zyga | take care! | 18:12 |
| kenvandine | FileNotFoundError: [Errno 2] No such file or directory: '/snap/gedit/x16/share/snapcraft/schema/snapcraft.yaml' | 18:12 |
| kenvandine | it thinks it should still be installed | 18:13 |
| cachio | niemeyer, hey, here I have some results using the xunit branch https://platform-qa-jenkins.ubuntu.com/view/snapd/job/snapd-spread-full-execution/lastCompletedBuild/testReport/ | 18:13 |
| kenvandine | oh | 18:13 |
| kenvandine | geez | 18:13 |
| * kenvandine is in a snap run --shell :) | 18:13 | |
| kenvandine | sigh | 18:13 |
| kenvandine | kyrofa, thx! | 18:13 |
| kyrofa | kenvandine, hahahahahahaha | 18:13 |
| cachio | niemeyer, of spread to run the snapd test suite on jenkins | 18:13 |
| kyrofa | kenvandine, I NEVER would have guessed that | 18:13 |
| mup | PR snapd#3334 opened: Release snapd 2.26.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3334> | 18:59 |
| mup | PR snapd#3330 closed: fail if unused dependencies are found <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3330> | 19:00 |
| mup | PR snapd#3323 closed: overlord/snapstate: avoid creating command aliases for daemons <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3323> | 19:07 |
| pedronis | mvo: is there some problem with autopkgtests? except off ppc64el they seem to be running forever | 19:07 |
| kyrofa | noise][1, I'm getting 504's when trying to view stats in dashboard.snapcraft.io | 19:19 |
| noise][1 | kyrofa: which snap? | 19:21 |
| kyrofa | noise][1, nextcloud | 19:21 |
| noise][1 | i know we have perf. issues there still w/snaps with a lot of revisions | 19:21 |
| noise][1 | but i'll take a look | 19:21 |
| kyrofa | noise][1, slow is okay. Perhaps timeouts simply need to be upped a bit | 19:22 |
| kyrofa | And indeed, I can see stats on other snaps | 19:22 |
| mup | Bug #1689301 changed: Can't set program_usb_boot_mode pi-config option <Snappy:New> <https://launchpad.net/bugs/1689301> | 19:46 |
| mup | PR snapd#3335 opened: daemon: teach the daemon to wait on active connections when shutting down <Created by pedronis> <https://github.com/snapcore/snapd/pull/3335> | 19:56 |
| pedronis | mvo https://forum.snapcraft.io/t/snapd-2-26-fails-to-start-in-lxd/651 | 20:00 |
| kyrofa | Now I'm getting proxy errors when trying to upload snaps. And status.snapcraft.io is all green | 20:26 |
| kyrofa | Gotta be honest... I largely don't even look there anymore | 20:27 |
| kyrofa | pedronis, is there currently a way for brand stores to be restricted to specific models? | 20:33 |
| pedronis | kyrofa: yes, you need to ask for that to be turned on | 20:33 |
| pedronis | and those models will need proper serials | 20:33 |
| kyrofa | pedronis, a store-side assertion, then? How is it associated with the model in question? | 20:34 |
| pedronis | kyrofa: not a store side assertion, store config that you need to ask for | 20:34 |
| kyrofa | pedronis, ah, okay. How does that work? What information do they need? | 20:35 |
| pedronis | kyrofa: store, brand, model names as specified in the model assertions for those | 20:35 |
| kyrofa | pedronis, alright, thank you :) | 20:36 |
| === mardy_ is now known as mardy | ||
| jorian | Hello, I was wondering if snappy sounds like the right tool for this job. I am trying to build some code that requires the boost library at a newer version than what is available in my distro's repository. Since this code requires many libraries, it occurred to me that maybe it might be easier to build a snap with just the newer library and then build the full app normally. Is it possible to have a snap | 23:45 |
| jorian | that just exposes a library? Or does it need to expose a binary? (like in the example's hello) | 23:45 |
| nacc | jorian: snaps are confined and aren't (by default) visible to each other (there is some feature work here that maybe i'm not fully aware of) | 23:46 |
| nacc | jorian: a libary is more like a 'part' in snap parlance than an app | 23:46 |
| jorian | that was kind of the vibe i got | 23:46 |
| jorian | thanks for clarifying | 23:46 |
| nacc | jorian: snaps are more designed around packaging the application | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!