[01:23] Hi i am trying todo a snap login [01:23] 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") [04:20] PR snapcraft#1318 opened: tests: refactor the travis jobs using stages === chihchun_afk is now known as chihchun [05:47] mvo: morning! [05:47] mvo: can you have a look at https://github.com/snapcore/snapd/pull/3308 and https://github.com/snapcore/snapd/pull/3307 ? [05:47] PR snapd#3308: tests/lib: introduce pkgdb helper library [05:47] PR snapd#3307: tests: abstract common dirs which differ on distributions [05:49] hey morphis! good moring. sure, I have alook now [05:49] mvo: thanks! [05:51] AdamH_: specifically apparmor/profiles, seccomp/profiles [05:51] 07:49 < zyga> AdamH_: intetesting, yes that does help [05:51] 07:49 < zyga> AdamH_: can you use beta and collect all the security profiles? go to /var/lib/snapd/ [05:51] 07:49 < zyga> AdamH_: and in each directory look for a file named after the application [05:51] 07:49 < zyga> AdamH_: intetesting, yes that does help [05:51] 07:49 < zyga> AdamH_: can you use beta and collect all the security profiles? go to /var/lib/snapd/ [05:51] 07:49 < zyga> AdamH_: and in each directory look for a file named after the application [05:51] AdamH_: then go to edge and collect the same set of files [05:52] zyga: btw. we should add a page on snapcraft.io which explains how to collect necessary debug material [05:52] 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:55] morphis: good idea, I will write something like that! [05:57] morphis: how is everything so far, any fires? [05:57] zyga: no fires I know of :-) [05:58] good :) [06:03] zyga: only fire is that my spread/qemu setup times out a lot today .. [06:14] morphis: on a specific test or on preparation? [06:16] zyga: it times out when running "dnf update" [06:17] must be my network or such a like [06:19] morphis: maybe setup a local proxy? [06:20] morphis, zyga: can you guys get robert ancell to properly tag releases on GitHub [06:21] it's very annoying that he's making releases that don't exist :/ [06:21] Son_Goku: sure [06:21] Son_Goku: huh? in what way? [06:21] Son_Goku: can you just drop him a mail with zyga and me in CC? [06:21] zyga: snapd-glib [06:21] I mean, he's making the tarballs on LP, but they don't have corresponding git tags [06:22] I guess he just releases into the lp/archive [06:22] yeah [06:22] it's just annoying because while I can "guess" where the tarball comes from [06:22] I don't know it [06:23] Son_Goku: not very professional, I know [06:23] Son_Goku: if you don't want to write a mail, a forum topic would be good too [06:23] I'll send an email later [06:24] as it is, I'm desperately trying to go back to sleep [06:24] it's 2:24am here :( [06:25] Son_Goku: do that! [06:48] 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:49] morphis: ü1 [06:49] morphis: +1 [06:49] mvo: actually is there a list of things planed for 2.27? [06:49] mvo: ah sorry, it is already in the post :-) [06:52] mvo: good morning :) [06:53] hey zyga [06:53] morphis: :) [06:53] mvo: too early :-) [06:54] morphis: no problem at all [06:57] mvo, quick question, is snapd 2.26.1 in the edge core snap already? [06:58] abeato: yes [06:58] mvo: something is wrong with core [06:58] 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] zyga: with core uploads? [06:58] mvo: amd64 core (edge) is still pre-version change [06:58] mvo, ahm, ok [06:58] mvo: and in fact gets no updates [06:58] zyga: I think its the new version string [06:59] mvo: well, I wish I had the new version string, I think it didn't build since [06:59] mvo: note that i386 did build [06:59] zyga: but that should have got fixed last week, so maybe something less is broken [06:59] zyga: oh? [06:59] woah [06:59] * mvo looks [06:59] mvo: are you on edge? [06:59] mvo: I'm on edge and I have 1909 [06:59] refreshed: 2017-05-12 06:20:00 +0200 CEST [06:59] zyga: what does snap version tells you? [06:59] snap 2.26.1+201705112259.git.e719341~ubuntu16.04.1 [07:00] zyga: ok, at least abeato gets a pretty recent snapd this way :) but yeah, edge-edge is 5 days old :/ [07:00] mvo: btw, update-ns landed [07:00] mvo, recent enough for us, thanks :) [07:00] mvo: but I noticed we don't run any tools from core (discard-ns, update-ns) [07:00] zyga: holly cow [07:00] mvo: so it will be broken [07:00] mvo: I'm fixing that now [07:00] zyga: please describe it in the forum post for 2.27, thats a huge thing [07:00] mvo: not in tests but in practice [07:01] mvo: yes, I was planning to already :) [07:01] zyga: ok [07:01] zyga: thank you :) [07:01] mvo: I'll be fixing the run-from-core aspect of discard/update ns as I watch the town hall [07:02] zyga: TestLokcUnlockWorks fails in traivs [07:02] zyga: meh :( [07:03] mvo: oh? missing dependency or something else? [07:03] mvo: do you have a log? [07:05] zyga: [07:05] https://travis-ci.org/snapcore/snapd/builds/232709633?utm_source=github_status&utm_medium=notification [07:05] 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:06] PR snapd#3324 opened: Androidboot [07:06] mvo: thanks, I see now [07:07] mvo: weird, it passed tests before [07:07] zyga: we did not run the unit tests for a while on travis [07:07] zyga: only inside spread indirectly [07:08] mvo: aaah [07:08] mvo: I see [07:08] hum hum hum, maybe weird filesystem [07:08] mvo: interesting find [07:08] zyga: anyway, just wanted to mention it, its not a big deal right now :) [07:18] 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:19] morning [07:22] fgimenez: thanks, checking now [07:24] mvo: ah, obvious bug :/ [07:24] mvo: we don't check for the length of l [07:24] mvo: probably data corruption but could be something else [07:25] zyga: obvious bug in the above pastebins or flock or something else :) ? [07:25] 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] mvo: yes [07:26] mvo: in the pastebins from fgimenez [07:26] fgimenez: indeed, that is expected behaviour [07:26] zyga: aha, ok [07:26] mvo: do you want me to propose a PR? [07:26] mvo: ok thanks [07:28] zyga: sure, if you have it all tracked down already +1 [07:29] great :) [07:29] zyga: I have not even looked yet properly :) [07:31] mvo: interestingly we vendor an older version of your package [07:31] mvo: but your package is also panicking in master [07:31] mvo: is api brakage acceptable? [07:32] zyga: hm, any chance we could avoid it :) ? [07:33] mvo: yes, let me tweak things [07:33] ah, it's just internal API, no worries [07:33] all good :) [07:37] fgimenez: any idea why this crash is triggered now, did we just not test before? [07:37] fgimenez: test for this before? [07:37] fgimenez: the code in this area has not really changed recently afaict [07:37] PR core#42 opened: fix version number length [07:38] 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:39] mvo: i created the image using the new prepare-image capability, is the only difference i think [07:39] mvo: FYI the crash looks like data corruption on the card [07:40] zyga: aha thanks! but it happens on two different cards and boards (pi2 and pi3), is it possible that both are corrupted? [07:41] fgimenez: maybe, though less likely [07:41] fgimenez: can you do a dump of the uboot environment file please? [07:42] 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:43] fgimenez: if it was random it may not happen again [07:43] fgimenez: thank you. keen to see the dump [07:44] mvo: https://github.com/mvo5/uboot-go/pull/2 [07:44] PR mvo5/uboot-go#2: Detect and return errors from Open in case of malformed data [07:44] zyga: the api of uenv should not allow to write something without "=" but maybe something else is going on :/ [07:44] mvo: well, whatever you write, you may read smurfs back [07:44] mvo: have a look at the PR [07:45] zyga: yeah, your fix is great [07:45] mvo: separately I think we want two more changes [07:45] mvo: a change that lets open skip malformed data [07:45] (better than failing outright) [07:45] mvo: and an update to snapd vendor commit [07:45] mvo: shall I make those? [07:47] zyga: yes, thank you! [07:47] zyga: first branch is in [07:48] zyga: quick review for https://github.com/snapcore/core/pull/42 would be great [07:48] PR core#42: fix version number length [07:50] mvo: looking [07:51] mvo: done [07:53] hi guys, what part of gpg bundle snapcraft register-key upload on the store? [07:54] PR core#42 closed: fix version number length [07:58] NicolinoCuralli: only the public bits [07:58] pedronis: thanks [07:59] mvo: https://github.com/mvo5/uboot-go/pull/3 [07:59] PR mvo5/uboot-go#3: Add OpenWithFlags and OpenBestEffort flag [08:00] * zyga thinks about breakfast [08:01] zyga: very nice, thank you! [08:02] mvo: I'll get the snapd copy updated now [08:06] zyga: \o/ [08:17] o/ [08:17] mvo: spread has "residual artifacts" [08:18] Chipaca: aha, interessting. you mean for the coverage results? [08:18] mhmm [08:18] https://github.com/snapcore/spread#residue [08:18] you then have to decide which of the 8 coverage files we get you want :-) [08:18] eee [08:18] 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] our first codecov report came in :-D [08:19] Chipaca: weeeee [08:19] 77% :-/ [08:19] yeah [08:19] that's dropped a lot since we looked at it last [08:19] this is why I want it :) [08:19] mvo: thanks for doing this :-) [08:20] oh, mondrian pictures! [08:20] spamming the comments is maybe not that great, I wonder if that can be disabled [08:20] mvo: the problem with doing it in a different step is that we eat up a travis slot [08:20] Chipaca: its being done in the same travis run, it just takes a bit of extra time [08:20] fgimenez, mvo: https://github.com/snapcore/snapd/pull/3325 [08:20] PR snapd#3325: vendor,partition: fix panics from uenv [08:20] ah! [08:20] that's alright then :-D [08:20] PR snapd#3325 opened: vendor,partition: fix panics from uenv [08:21] Chipaca: I will look how much extra time exactly [08:21] mvo: we could always have it in spread just after --static [08:21] Chipaca: indeed, this is what I did now [08:22] mvo: I'll focus on run-from-core for internal tools now [08:22] oh? [08:22] zyga: thank you [08:22] * Chipaca clicks 'view all' [08:22] Chipaca: or was I just dreaming this ? [08:22] Chipaca, mvo: FYI: travis has added "build stages", that may be of some help to you (perhaps) [08:22] mvo: no, it's there [08:23] mvo: it's early [08:23] mvo: i thought i was looking at spread.yaml :-) [08:24] * ogra_ sees the core uploads succeed and hugs mvo [08:24] :) no worries [08:24] ogra_: yay [08:24] more cores! [08:24] :D [08:26] * zyga looks at delta update for core [08:26] niiiiice :) [08:27] mvo: hmm [08:27] mvo: I broke edge [08:27] - 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] mvo: (this is the thing I mentioned) [08:27] mvo: we may want to revert edge to previous for a sec [08:27] mvo: and land a change that fixes this first [08:27] mvo: (update-ns runs from distro) [08:27] mvo: not from core [08:28] zyga: dude, you owe us so much cake [08:28] 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:29] Chipaca: it would be caught by the upgrade test but those don't run on each PR [08:29] (i think) [08:29] it still running, IoT just up right now [08:29] *it is [08:31] zyga: thanks for the branch! trying to get the dump in a bit, will let you and mvo know how it goes [08:34] fgimenez: if you can not get the dump but just the binary uboot.env that is fine too [08:36] mvo: ok thanks [08:37] zyga: could you finish your review of snapd#3321? [08:37] PR snapd#3321: wrappers: service start/stop were inconsistent [08:37] then i can land that and be happy [08:37] * Chipaca penciled in 6 hours of being happy today [08:37] pencilled* [08:41] Chipaca: yes, after the tools from core branch [08:45] 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] mvo: yes, i think that's fine (also i don't mind it posting the report as a comment on the pr) [08:46] because only the author of the pr, and people who've already commented, will get that email [08:46] Chipaca: ok, I will bring it up in the standup [08:46] ok [08:46] mvo: will you add the widget? [08:47] Chipaca: I can :) [08:47] Chipaca: the badge you mean? [08:47] yeah [08:47] Chipaca: let me add it [08:47] i'm a sucker for badges [08:47] Chipaca: hahaha [08:47] * mvo hugs Chipaca === longsleep_ is now known as longsleep [09:02] Chipaca: badge added now [09:02] mvo: yep! thanks :-) [09:03] tried to add a <3 to the commit, but github won't let me [09:03] PR snapd#3326 opened: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible [09:04] mvo: can you please look at https://github.com/snapcore/snapd/pull/3326 [09:04] PR snapd#3326: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible [09:05] mvo: the main/listing test needs update again [09:07] 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] PR snapd#3308: tests/lib: introduce pkgdb helper library [09:07] mvo: I feel somewhat strongly about it but I will accept your call [09:08] zyga: asked mvo already this mornign to have a look :-) [09:08] zyga, morphis it is on my list, unfortunately its a longish list but I will definitely get to it today [09:09] mvo: no hurry [09:10] mvo: don't need a full review yet, just your call on the discussion I had with zyga on it [09:10] morphis zyga: you are mostly interessted in the centralized vs non-centralized approach? [09:10] mvo: yes [09:11] mvo: thank you [09:11] thanks, I will read the PR and scratch my head a little bit over it [09:12] hi guys another question about signing : what ubuntu-image deposits on image of gpg bundle? [09:12] is anyone handling the main/listing test? [09:16] mvo, Chipaca, fgimenez: ^ [09:16] zyga: what's going on with main/listing? [09:17] Chipaca: new edge version broke it [09:17] again :) [09:17] augh [09:17] 16-2.26.1+201705151555.git.d15bf would do that, yes [09:17] that's a nasssty version number [09:17] (also, is that a unique hash, or has it been truncated?) [09:17] truncated :/ [09:17] hash snippet i mean [09:17] mvo: I'd say we should drop the date [09:18] and just go with the hash [09:18] we really need to drop the time from the timestamp [09:18] yes [09:18] date is totally enough if we keep the hash anyway [09:18] well, hash has the date if you git show it ;) [09:18] 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] ok, i'll fix the test [09:19] Chipaca: truncated [09:19] I think the timestamp is more immediately useful [09:19] Chipaca: so we can cut it out [09:19] mvo: is this long version ever going to leave edge? [09:19] (should it?) [09:19] Chipaca: no, only edge will have ugly versions [09:20] ok [09:20] so yeah, I can push another PR to kill the git hash :) [09:20] mvo: so how will we do beta builds? [09:20] mvo: separately from edge builds? [09:21] mvo: let me know what it will look like, so i can fix the listing test to match [09:22] zyga: right now all beta builds are syncronised with uploads of a snapd with a proper version number [09:22] Chipaca: I think just 16-2.26.1+201705151555 [09:23] zyga: not sure if this reply makes sense, I can write more if its unclear :) [09:24] zyga, well, athe actual plan was to do different chasnnels from different archives (beta/stable without PPA) ... [09:24] but we're still far from that [09:24] which is why mvo makes sure to have a stable snapd in the PPA before a beta snap gets rolled atm [09:25] mvo: I think the git hash would be more useful [09:25] mvo: than the date [09:25] mvo: certainly to answer "is this commit in that build already" [09:26] 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:27] hm, maybe [09:27] 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] mvo: no need to cram it into version and also useful for other [09:28] we want a clear distinction between stable and non stable builds in the snap version too though [09:28] fine, I bet we can do that somehow too [09:29] (so that you dont need to actually run an image to determine the version) [09:29] PR snapd#3327 opened: tests/main/listing: tweak core version regexp [09:30] zyga, mvo: ^ [09:31] reviewed [09:35] * zyga -> coffee break [09:36] 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:37] mvo: hi, could you look at snapd#3323 again ? [09:37] PR snapd#3323: overlord/snapstate: avoid creating command aliases for daemons [09:38] Chipaca, zyga, ogra_: how about this as a compromise? http://paste.ubuntu.com/24586017/ [09:38] Chipaca: hmm? [09:38] mvo: does it fit one more character? [09:39] Chipaca: yes [09:39] in fact does it fit five more :-( [09:39] Chipaca: no [09:39] Chipaca: ;) [09:39] figured as much [09:39] mvo: do we really need the date? [09:39] mvo: zyga says the 16-2 at the start will change to 16-2.24.1 [09:40] at which point this will not fit [09:40] zyga: I thought we did but I may misremember [09:41] 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] zyga, Chipaca: we could shorten 2017 to 17 and get two chars [09:42] 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:45] morphis: yes, I recall this but I need to fix update-ns run-from-core and unit tests first [09:45] mvo: 17 will look confusing, how about just date and hash? [09:45] zyga: so something you're going to look into for 2.27? [09:45] mvo: 16-2.24.1-20170516+git.... [09:46] morphis: yes, certainly [09:46] zyga: ok, lets add that to https://forum.snapcraft.io/t/next-snapd-2-27/572/2 [09:46] will see if there is a bug [09:47] mvo: can you add https://bugs.launchpad.net/snappy/+bug/1644573 to the 2.27 page? [09:47] Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection [09:47] zyga: mvo: agreed to not change until discussed, seems there are lot of options [09:47] zyga: mvo: and not sure at this point what questions we want to answer from that information :-) [09:48] Chipaca: one option is to raise the limit :) [09:48] 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] whereas if what you're wanting to answer is "is this edge from last night", you're done [09:48] if you have the commit, you need to check master to see if that commit contains whatever it is you're after [09:49] morphis: sure, will do. the page should be a wiki so you can also add it if you want [09:49] and if you're wanting to answer "is this edge from last night", you need to check what commit it was [09:49] mvo: last time I checked, I couldn't [09:49] or rather, you need to check if that commit is one of the ones from last night [09:49] which means looking for one random string in a collection of random strings, which is worse [09:50] which is why i prefer the timestamp [09:50] morphis: that means I suck, let me fix it [09:50] morphis: maybe something else is funny, it is marked as a wiki [09:52] morphis: added it now [09:52] mvo: maybe just for a few people? [09:52] morphis: good question [09:53] fgimenez: any news on that uboot.env file? just curious because I'm slightly worried about this one [09:56] 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) [10:01] * Chipaca takes a coffee break [10:03] re [10:05] Chipaca: can you have a look at https://github.com/snapcore/snapd/pull/3326 when you're back please [10:05] PR snapd#3326: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible [10:05] zyga: i didn't get to leave yet [10:06] looking [10:06] Chipaca: I need to re-add some of the logging [10:06]