=== Eleventh_Doctor is now known as Pharaoh_Atem [05:55] morning === [asc] is now known as [-asc-] [06:56] PR snapcraft#1852 opened: Added a missing step in Hacking.md [07:40] o/ [07:41] hey zyga-ubuntu, good monring [07:41] hey :) [07:44] PR core#68 closed: hooks: fix shellcheck complains [07:47] zyga-ubuntu: mvo: morning guys [07:50] good morning [07:51] morning, zyga-ubuntu [07:51] hey :) [07:51] * zyga-ubuntu had a fsck-initramfs-based-morning [07:52] but all is good now, I hope [07:52] not how you wanna start your day... :-( [07:53] PR snapd#4449 opened: cmd/libsnap-confine-private, cmd/snap-confine: fix logging of failed [u]mount when run with SNAP_CONFINE_DEBUG=1 [07:53] hey mborzecki - good morning and good morning kalikiana [07:53] kalikiana: morning [07:53] mborzecki: mvo o/ [07:54] gconstpointer ? [07:54] why do we need that over, apparently, bool? [07:55] ah, could be the limitation of the test protocol [07:55] zyga-ubuntu: just following gtest declarations and didn't want the compiler to scream at me [07:56] I think I would have preferred a debug library but this change is smaller, +1 [07:58] zyga-ubuntu: thanks [08:09] zyga-ubuntu: have you seen this? https://forum.snapcraft.io/t/on-arch-snaps-show-broken-after-switch-from-snapd-to-snapd-git/3427/4 [08:09] pstolowski: morning [08:10] mborzecki: no, I just had a look now - my bet is it's a mount from some directory that dones't exist on arch in default install, maybe /usr/src or something like [08:10] ...that [08:11] if you can strace it you will get the answer [08:12] mborzecki: btw, does it work for you? [08:12] zyga-ubuntu: hm but what fails is: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory [08:12] mborzecki: or also no? [08:12] yes, it does [08:12] that's odd, is the source/target present? [08:12] it would be off for /dev not to exist [08:13] lookign at snap-confine source code, we create the destination directory [08:14] aah, w8, we create the destination only it's it's bidirectional [08:17] PR snapcraft#1853 opened: extractors: support appstream icon and desktop [08:18] hmm [08:19] that feels like a bug [08:19] but [08:19] .. /dev should be in the core snap [08:19] zyga-ubuntu: it is [08:21] Hi, I met a question about snapd. I make a pc.img which use ubuntu-img command. But when i log into the system. the snap can't mount, ant the syslog print:'Jan 5 08:10:49 localhost snapd[889]: 2018/01/05 08:10:49.391477 stateengine.go:101: state ensure error: devicemgr: cannot mark boot successful: cannot determine bootloader' many times. what should i do. Thanks. [08:24] haisheng-from-ch: hey, which gadget/kernel/model did you use? [08:25] also when start the system . the screen print 'Mounting Mount unit for core.Mounted Mount unit for core. Unmounted Mount unit for core. ' many times. [08:25] i'll try to spin a manjaro vm locally and check what's happenning there [08:26] mvo, hi! wrt that changes to base-18 you made on Fri, are they available in the latest build yet? === ackkk is now known as ackk [08:27] ackk: I checked https://code.launchpad.net/~mvo/+snap/base-18 this morning - and it still has not build :( so we probably need to ask in #launchpad what is going on [08:27] I guess the few builders availble are hammered [08:29] ackk: what's wrong with the build farm? [08:30] kernel is 1604. gadget is the sample which provided in website.the model is customized by myself. [08:31] the model is '{ [08:31] "type": "model", [08:31] "authority-id": "9go0hDakgpo17fYGy06ZguLT8Ly0Ma9F", [08:31] "brand-id": "9go0hDakgpo17fYGy06ZguLT8Ly0Ma9F", [08:31] "series": "16", [08:31] "model": "kylin-test", [08:31] "architecture": "amd64", [08:31] "gadget": "kylin-gadget", [08:31] "kernel": "pc-kernel", [08:31] "timestamp": "2018-01-08T06:23:22+00:00" [08:31] } [08:31] ' [08:32] zyga-ubuntu, it was shutdown because of meltdown/spectre, only whitelisted projects are built [08:32] zyga-ubuntu, so no PPA and snap builds [08:33] aaah [08:33] makes sense [08:37] ackk: maybe we are not in that whitelist [08:42] * zyga-ubuntu uses his GPU to heat up the room [08:42] mvo, yeah you should ask about it, I know other teams did [08:42] darn it's a cold day today [08:44] hi, zyga-ubuntu, any info can be provieded for me about this error? [08:44] haisheng-from-ch: not immediately, I work on core snapd but how it combines with reference gadgets and ubuntu image is complex; perhaps ask ogra_ as he's closer to that layer [08:45] it's best to open a forum topic [08:45] include all the details: which ubuntu-image you've used, how did you boot it, etc [08:45] ok thanks. [09:03] PR snapd#4450 opened: snap: support `command-not-found` symlink for `snap advise-command` [09:05] mvo, so with your latest changes you were able to get a working maas snap installed, right? [09:09] ackk: yeah, it was not getting past "intializing" though [09:10] ackk: fwiw, I ask on #launchpad about the build but I guess tricky TZ wise currently [09:10] ackk: to get answers [09:11] mvo, cool. could you pass me the snap for the base so i can try locally (see if I can actually get maas to work) [09:14] ackk: sure, let me try a cleanbuild for you [09:17] mvo, you might want to try #launchpad-ops [09:23] hey Chipaca [09:23] zyga-ubuntu: o/ [09:27] zyga-ubuntu: over the weekend i might've gone all "here's a nickel, kid" on somebody's distro [09:27] Chipaca: sorry, the analogy eludes me [09:27] zyga-ubuntu: http://assets.amuniversal.com/6b08abb09fbb012f2fe600163e41dd5b [09:27] Chipaca: are you saying you tried a bunch of distros? [09:27] haha [09:28] zyga-ubuntu: in particular, https://forum.snapcraft.io/t/cannot-comunicate-with-server-mx-linux-17/3455/2 [09:31] elopio: you're awake? [09:31] PR core#70 opened: hooks: use symlink to run `snap advise-command` [09:31] kalikiana: it's 3am in .cr [09:32] Chipaca: Well, it didn't seem to stop him from pushing code to GitHub, that's why I'm asking [09:32] ah [09:32] kalikiana: i read it as a "are you awake", not as "wtf you awake" [09:32] :) [09:33] :-D [09:34] English is so ambiguous when you don't use properly foul language [09:35] well i could've also been unambiguouss without being lazy, but i'm lazy [09:46] * zyga-ubuntu crosses fingers [09:46] TIL manjaro has a user friendly installer [09:50] is it just me or has the lower temperature brought much higher pressure [09:50] I don't feel sleepy like I did all last week [09:56] mvo: you around? [09:57] Chipaca: yes, good morning! [09:58] mvo: good morning! what are my chances of you finishing your review of #4394? [09:58] PR #4394: snap: give the snap.Container interface a Walk method [10:01] Chipaca: *cough* I let you wait long enough - I do that now as in right now [10:01] :-D [10:01] * kalikiana coffee break [10:03] note fedora tests are disabled again [10:04] btw. i actuallt hit the same problem as the spread tests did when updating my wife's fedora on friday [10:05] mborzecki: which problem? [10:06] mborzecki: or rather, which of the problems? :-) [10:07] Chipaca: failure to downlaod from updates repo [10:07] ah [10:08] mborzecki: i've also seen (in the tests) fedora not having 'snap' in the path, and fedora's systemd not knowing about snapd.service [10:08] that's the point i disabled the test again [10:08] (after re-running them ~6 times because of the repo thing) [10:08] that's interesting, was it reproducible? [10:08] something's very broken, needs fixing, but beyond me atm [10:08] mborzecki: afaik it was just the once, but it was just the breaking point [10:09] haha ok :) [10:09] that is, i had about 6 runs of it breaking because of the repo thing [10:09] then it didn't break because of the repo and instead didn't know about snapd [10:09] or the service [10:09] (different instances of fedora in the same run) [10:09] well f26 was to be switched to manual anyway, hoping we could get the f27 PR merged soon [10:09] so, (╯°□°）╯︵ ┻━┻ === tinwood_ is now known as tinwood [10:18] ok, off to physio for me [10:18] * Chipaca bbi1h [10:38] hmm installed snapd-git on clean manjaro .. and it's broken, seems like snap mount dir is /var/lib/snapd/snap, but there's only /snap in the system, /var/lib/snapd/snap does not exist [10:38] zyga-ubuntu: any idea who i can talk to about this? [10:39] mborzecki: so which of the two layouts would manjro prefer? [10:41] idk, seems like they're undecided [10:42] * kalikiana moving to coffee shop, brb [11:09] so i managed to get: [11:09] Name Version Rev Developer Notes [11:09] core 3748 canonical broken [11:09] hello-world 27 canonical broken [11:09] on manjaro [11:09] mborzecki: what's the configuration there/ [11:09] mborzecki: did it reexec [11:09] mborzecki: is it using /snap or /var/lib/snapd/snap? [11:10] yeah, it's using /var/lib/snapd/snap [11:10] looks like the manjaro `community` repo pacakaes do not do a proper cleanup when removing [11:10] ahh [11:10] that's not catastrophic [11:10] there's bits and pieces left behind, one of those is mounted snaps [11:11] and for some reason i ended up having `hello-world` in /var/lib/snapd/snap but there's no core [11:12] uhh, taje that back, there's 'hello-world' in /snap but no 'core' [11:12] mborzecki: what if you start from scratch on a clean manjaro system [11:12] is it still broken then? [11:13] i had a clean system, then installed snapd-git, but apaprently they have snapd-git in community repo (?) and it was broken like i described earlier [11:13] aha, I see [11:13] mborzecki: they accept PRs there so I guess we need to update it [11:14] then i removed that package and tried to install snapd-git from aur, ran into multiple issues with files left behind by their community package and finally got into the 'broken' state :) [11:17] mvo, any luck on the build? [11:18] * kalikiana having lunch earlier today [11:20] * zyga-ubuntu burns spread cycles on iteration with apparmor [11:21] ackk: not yet, I can give you a manually build one, for some reason "snapcraft cleanbuild" fails for me in artful, maybe deboostrap is doing things that are not supported, I get https://paste.ubuntu.com/26346220/ ( kalikiana may know more). I can give you a hand-hacked one instead [11:23] mvo, that would be helpful, thanks [11:26] PR snapd#4451 opened: cmd/snap-update-ns: improve mocking for tests [11:26] Good morning! [11:27] niemeyer: hello [11:27] long time no see! [11:28] Indeed! [11:28] ackk: please try http://people.canonical.com/~mvo/tmp/base-18_very-unstable_amd64.snap [11:28] Just learning how to type again.. [11:28] mvo, thanks [11:28] hey niemeyer - welcome back! we missed you [11:28] mvo: Heya, thanks! [11:29] Missed you all too.. was a bit hard to put myself away from all action :) [11:29] niemeyer: hey, how was your vacation? [11:30] It was great being so offline for a few days [11:30] mvo, still getting https://paste.ubuntu.com/26346261/ when trying my snap [11:32] mvo: you get that error with cleanbuild? I've never seen that. Would you mind filing a bug? [11:34] niemeyer, hi! welcome back! [11:43] * kalikiana getting food now, biab [11:50] PR snapd#4452 opened: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP [11:50] wow, the bot is instant [11:51] when I opened this PR the latency was << 1s [11:54] * zyga-ubuntu food break [12:00] zyga-ubuntu: i think you just happened to open the PR at :59 :-) [12:00] kalikiana: sure [12:00] ackk: could you please try in clean vm? I can't reproduce this error [12:02] Chipaca: hehe, maybe :) [12:02] Chipaca: you have a first bit of review, I will continue in a little bit, its fine don't get me wrong, just tiny ideas/nitpicks [12:02] mvo: I'll do two more PRs on hole-poking and layouts and then look at LXD mount issue [12:02] mvo: ah then i'll wait (i already added your suggestion, was about to push) [12:03] mvo: if you consider them nitpick-level, i can address them in the followup instead of here [12:03] mvo: let me know :-) [12:03] the AUR snapd package does not build :( [12:06] Chipaca: interessting idea, we could merge and then do a follwup indeed [12:06] mvo: i mean, i have a followup -- but it's not small [12:06] so maybe it's a _bad_ idea :-) [12:07] but it's certainly an idea [12:07] Chipaca: the dirstack is used instead of recursion because you want to keep the open file handles low? [12:07] Chipaca: heh :) [12:07] mvo: and the call stack [12:07] Chipaca: *nod* [12:08] mvo: better to have a stack of string than a stack of stacks [12:08] +1 [12:08] at least that's what i was taught in uni, back when i paid attention [12:08] Chipaca: was just wondering as the recursive version is easier to read but its fine, your reasoning is sound [12:10] Chipaca: when you apply the "readOneDir" idea, maybe "readOneDirN()" and we add the "100" to the readOneDirN() call? [12:10] mvo: what for? [12:11] Chipaca: mostly clarity, readOneDir() is really read100ItemsFromOneDir :) [12:11] (as it is today/in that pastebin) [12:12] mvo: maybe i should rename it babySteps() [12:12] as in Walk() -> babySteps() [12:12] :-) [12:12] Chipaca: heh, yeah, something like this, seriously, just to avoid our future selfs using it assuming it would read *all* of that dir [12:12] (or my future self that has a limited memory span) [12:14] I'll rename it something super obvious, like twiddle() [12:14] doThing() [12:14] oh, i know! doProcessThing() [12:14] just go all the way and call it all twinky, twonky, twooty, twoo, calling each other with one global variable as help [12:16] zyga-ubuntu: and the global variable should be literally 'help' [12:16] Chipaca, hey, there are rumours you have a lot on your plate and might want some help? for example with warnings, or free disk check? [12:16] Chipaca: bonus point if it's a function pointer initialized to a XKCD strip [12:16] pstolowski: warnings comes before free disk check warnings, but free disk computation coud come before that [12:17] * zyga-ubuntu prepares oatmeal, the O(1) complexity food for software developers [12:17] water, flakes, heat, eat [12:17] zyga-ubuntu: this is go, you can't do `var help func() = "http://..."` [12:17] Chipaca: function printing that or sensible-browser opening that would do [12:18] https://xkcd.com/1513/ is fine [12:18] zyga-ubuntu: is it bad that somewhere on my other computer is a javascript page that edits itself until it compiles [12:19] pstolowski: i've got a branch with part of warnings, i think? but not sure if it'd still work as it's from two sprints ago [12:20] Chipaca, perhaps I could take free disk computation? [12:20] pstolowski: disk usage shares some of the issues with snapshots for which i wanted to fix user iteration, but i wasn't able to get to the bottom of those failures [12:21] pstolowski: actually perhaps that's a good place to poke: want to see if you can figure out the failures? [12:22] pstolowski: if you take #4299 and then [12:22] PR #4299: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") [12:22] pstolowski: spread -seed=1512088627 -shell linode:ubuntu-14.04-64:tests/main/{interfaces-browser-support,abort} [12:22] pstolowski: but with -debug instead of -shell [12:22] pstolowski: you'll see the failures i mean (or you should) [12:22] Chipaca, ack, will see if I can find something [12:23] pstolowski: the failure is the whole thing dying (spread says something about EOF) [12:23] pstolowski: good luck [12:23] Chipaca, ahh, that failure [12:23] PR snapd#4453 opened: Update README.md [12:24] pstolowski: indeedly [12:24] PR snapcraft#1854 opened: Update README.md [12:25] hey, any easy way to re-run CI on this? https://github.com/snapcore/snapd/pull/4365 [12:25] PR #4365: interfaces/mir: allow Wayland socket and non-root sockets [12:26] greyback: as in restart? [12:26] greyback: by CI you mean travis? [12:26] just did [12:27] zyga-ubuntu: Chipaca yes and yes [12:27] greyback: merge master first [12:27] aww [12:27] zyga-ubuntu: fedora will fail :-/ [12:27] sorry for wasting cycles [12:27] cancelled [12:27] ah, the fedora thing still not fixed [12:27] ok [12:27] greyback: well, if you merge master, they're disabled [12:27] Chipaca: aha, ok [12:27] will do [12:27] so no, but yes [12:27] :) [12:29] greyback: note if people have looked at it already we ask you merge instead of rebasing [12:29] Chipaca: good to know, thank you [12:30] Chipaca: ok, finished the rest, I get some lunch now [12:30] mvo, I'm testing in a container, not a vm [12:30] I can try a clean one, though [12:30] ackk: if its not too much hassle that would be great. [12:30] sure [12:30] ackk: I couldn't reproduce the issue, but I was testing using a vm :/ [12:30] * mvo lunch [12:34] mvo, https://paste.ubuntu.com/26346467/ in a clean LXD [12:35] ackk: thanks, puzzling [12:35] the first error I 've seen randomly happen, but usually it's just the first time [12:42] re [12:59] Chipaca, interfaces-browser-support from your branch passed here. i'm running 16.04, could this be a factor? [12:59] pstolowski: i'm running 16.04 as well [12:59] pstolowski: note it only fails together with another test [12:59] Chipaca, aha! [13:00] pstolowski: that's why the command was as i typed [13:00] I should treat your command literally.. yes [13:01] niemeyer: standup? [13:12] popey: Hey! Can you provide an example that triggers this bug? https://bugs.launchpad.net/snapcraft/+bug/1741752 [13:12] Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' [13:14] kalikiana: done [13:25] popey: Thanks! Will try to reproduce here [13:30] Chipaca, and it passed https://pastebin.ubuntu.com/26346695/ [13:30] Chipaca, you said it was failing every time for you? [13:34] Chipaca: i can look into fedora issues later today/tomorrow [13:37] kalikiana: are we going to get stacktrace spam turned off sometime soon? [13:39] popey: There were some fixes for that already. Have you tested with the --beta snap? [13:39] kalikiana: I'm on edge [13:40] popey: If that isn't a Freudin slip :-P Can you paste any recent example? We might not have caught all of them [13:40] kalikiana: how about the bug you just asked me to put an example on? :) [13:44] popey: Ah, right. So in this case you see the trace because it's not a known failure case. It's a genuine bug so this will need a proper exception code path. [13:45] We don't generally try to hide those [13:45] I don't ever want to see them [13:45] me too [13:45] unless I pass some kind of -show_me_the_python_nonsense_I_dont_care_about [13:45] only devs need to see those [13:46] just say "we dun goof'd" on unknown errors and leave it there [13:47] SNAPCRAFT_VERBOSE=1 would do [13:47] i would set that on build.snapcraft.io or travis, but never on my laptop [13:48] We could make them `--debug` only and something like `Please re-run with --debug to get a full trace`. The most important aspect to my mind is that there's a clear path to knowing how to get the error and report it if desired. [13:48] that'd work [13:49] even better: --file-bug; that runs through until the failure and then gets all the useful debug info and posts it to launchpad similar to ubuntu-bug does [13:50] or maybe call it "--create-bug" [13:50] something like that anywho [13:50] then we don't need to even work out which bits we need to copy [13:52] That might need some discussion on what that info is... although that's a nice idea [13:53] or rather than being explicit when it hits a failure it just prompts "do you want to create a bug? (Y/n)" which you can disable with a `--quiet` flag [13:54] bonus points for finding duplicates [13:54] That would've been awesome for codein... [13:54] * kalikiana won't have time to look into the anytime soon [13:55] pop it on the backlog :-) [13:55] diddledan: Mind filing a bug for it? [13:56] roger that [13:56] there is one [13:56] i filed it iirc [13:56] For "file a bug"? [13:56] no, for stfu [13:56] https://bugs.launchpad.net/snapcraft/+bug/1740265 [13:56] Bug #1740265: Stack trace makes it hard to discern real errors [13:57] Please don't push that back until after we have bug reporting built in though :( [13:57] popey: Aye, this one is pretty straightforward. I'll bring it up later in our weekly meeting [13:57] thanks [14:03] bug #1741900 [14:03] Bug #1741900: Add file-a-bug functionality on errors [14:05] diddledan: Thanks! [14:10] * pstolowski lunch [14:10] * zyga-ubuntu quick break to catch up with kids [14:19] * mborzecki is off to pick up the kids [14:29] cyphermox, i have the next wlan module that doesnt support unbind ... given how big that block in netplan already is i wonder, cant we get away without unbinding the dirvers at all ? [14:30] cyphermox, ath6kl_sdio this time ... [14:31] not afaik [14:31] * ogra_ will file a bug and patch as usual ... but all these SRUs get tiring [14:32] pstolowski: indeed. Can you run the whole suite? [14:33] pstolowski: also, what's your PROMPT_COMMAND? :-) [14:41] cyphermox, https://code.launchpad.net/~ogra/netplan/+git/netplan/+merge/335824 .. do you need a separate MP for the xenial branch or will you just backport it ? [14:42] PR snapd#4454 opened: snap: fix gadget.yaml parsing for multi volume gadgets [14:42] PR snapd#4455 opened: store, daemon/api: Rename MyAppsServer, point to dashboard.snapcraft.io instead [14:48] back to work [14:52] cyphermox, https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1741910 [14:52] Bug #1741910: ath6kl_sdio does not support unbinding [15:00] ogra_: it's fine as-is,thanks! [15:00] awesome ! [15:00] hello! [15:00] kalikiana: I am awake now :) [15:15] elopio: :-D [15:19] elopio: Actually there's something I'd like your input on. Can you have another look at snapcraft#1847 and tell me your thoughts on conditional `sudo` in `_container_run`? kyrofa wasn't very happy with it, so I changed it twice now. I figure a third opinion would help figure out the best path [15:19] PR snapcraft#1847: lxd: Use user in container when mounting remote via sshfs [15:21] elopio: Also in case you haven't seen it, I made some comments on snapcraft#1853 [15:21] PR snapcraft#1853: extractors: support appstream icon and desktop [15:21] yup, thanks for the review. [15:25] kalikiana: I find that clear, if user != 'root': prepend sudo. [15:26] elopio: first I had heuristics, then I had user=False... if you like this version I'm hoping kyrofa will also like it, but otherwise I'm out of ideas :-P [15:27] kalikiana, haha, I'm sorry to be causing pain. user=False was way better [15:27] kyrofa: :-| [15:27] that's easy to fix, ask kyrofa for what will make him happy, instead of guessing :D [15:27] kalikiana, I mean way better than the heuristics [15:27] lol [15:27] kalikiana, haven't looked at the new way yet [15:27] kyrofa: Oh, hah, okay [15:28] I'm actually liking the latest one a lot more myself now than what I did before [15:28] Alright I'll take a look soon. I have oodles of codein reviews [15:29] The good kind of spam ;-) [15:30] kyrofa: We can also have a quick chat about it in/after the weekly, might be easier at this point [15:30] kalikiana, we can do that if I haven't been able to review by then, I know you go *poof* shortly after [15:32] Yeah. I'm weird like that. As if the sun somehow goes down earlier where I'm at :-P [15:43]