[01:18] kyrofa, elopio: https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c [01:19] I think I just need to figure out how to set those env vars now ..... should I just set them in os.environ ? [01:20] bdx: we usually pass them in the env argument for the run methods [01:23] elopio: ok, how are the actually set though? [01:25] bdx: take a look here, for example https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/go.py#L190 [01:29] this is where I went next, is this legit https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c ? [01:29] checking [01:29] I see [01:30] I feel like I'm on the right track [01:31] bdx: it looks pretty good, yes. Why don't you make a pull request? We can continue reviweing it there, and the comments and changes will be very useful for when we have to modify the code in the future. [01:32] ok [01:33] bdx: I usually start with a very very simple integration test, to make sure that the plugin covers the basic case. And then continue making it more complicated, one step at a time. [01:33] you can take a look at the integration_tests directory. [01:38] alright, thanks [02:22] PR snapcraft#1365 opened: Add Ruby Plugin === chihchun_afk is now known as chihchun [03:37] PR snapcraft#1337 closed: autotools: don't force uniqueness on configflags [08:29] good morning [08:29] sorry for joining so late [08:33] mwhudson: o/ [08:52] PR snapd#3484 opened: tests: add autopilot-introspection interface test [08:59] raahghghghg [08:59] zyga-ubuntu: help please [09:01] Chipaca: yes? [09:01] Chipaca: as much as I can be today [09:01] zyga-ubuntu: I can't get rid of these stupid "cannot update mount namespace" things [09:02] Chipaca: hmm [09:02] zyga-ubuntu: frehsly booted, fresh snapd state, make hack, running from master. Can't install nor try a single thing. [09:02] Chipaca: disable reexec [09:02] and compile and install snap-update-ns [09:02] that should be enough [09:02] doesn't make hack do that? [09:03] Chipaca: no, it only does that snap-confine parts [09:03] (feel free to improve it though [09:03] as the name implies, it's just a hack [09:03] I didn't take the name to imply it was a hack, but that it let you hack [09:03] :-/ [09:04] zyga-ubuntu: actually, strange thing: hello-world does install [09:04] it did, but it needs update since we added update-ns [09:04] zyga-ubuntu: test-snapd-python-webserver does not [09:04] curious [09:04] well [09:04] we only update ns if there's a bound ns [09:04] if there's none, we don't even try [09:06] zyga-ubuntu: why does it complain on the first 'try' of a snap package? core was already installed [09:06] ("a snap package" -- test-snapd-python-webserver) [09:06] complain on try? can you expand on that please? [09:06] zyga-ubuntu: sudo snap install --edge core [09:07] zyga-ubuntu: worked fine \o/ [09:07] zyga-ubuntu: sudo snap try tests/lib/snaps/test-snapd-python-webserver/prime [09:07] with core from edge it should be all fine since snapd will use assests from the core snap, most likely [09:08] zyga-ubuntu: http://pastebin.ubuntu.com/24863432/ [09:08] oh oby [09:08] boy [09:09] that's a long way to say "not implemented" [09:09] did you rebuild snapd too? [09:09] this is running a snapd from master, yes === chihchun is now known as chihchun_afk [09:10] ok, you have to copy snap-update-ns to /usr/lib/snapd/ then [09:10] snapd master, if it doesn't reexec, will use internal tools from distro location [09:11] siigh [09:12] yes that did it [09:12] i'll push a branch to have 'make hack' do that as well [09:12] thank you [09:12] i already have enough grey hair [09:12] interestingly, I think snapd could hold internal tools [09:12] less binaries [09:12] less divergence [09:12] but anyway, back to qemu [09:18] Chipaca: hi, I reviewed your PR [09:18] pedronis: i saw! thanks [09:22] pedronis: I didn't realise the usual case was just to leave the tomb unended [09:23] maybe it's not true [09:23] shouldn't taskrunner kill the tomb when removing it from the map? [09:23] now that I think [09:23] I think we do kill it [09:23] tomb.Kill(handler(t, tomb)) [09:23] yea, sorry [09:23] that's done before delete(tombs, tomb) [09:23] then the converse is true though [09:24] trying to Kill the process is strange [09:24] given we know it has finished [09:24] how do we know it's finished? [09:24] I mean [09:25] if you abort, the tomb gets killed, but if you don't have something looking at the tomb and killing the process when the tomb gets killed, nothing kills the process [09:25] so, many, commas [09:25] I'm saying if you get back from Wait you will still get to Kill [09:26] ah, yes [09:27] pedronis: but process doens't have an Alive() call [09:27] hmm [09:27] you need your own book keeping [09:27] anyway that's why I suppor runHookAndWait is so outside-in [09:28] but I don't really have to do my own book keeping [09:28] nothing bad happens if I kill it and it's already dead [09:28] it's now extra-dead \o/ [09:28] maybe I should add a comment? [09:29] or! maybe i only kill it if it's in AbortState? [09:29] well that pid could be reused [09:29] now you kill the bad process [09:30] Process is just a glorified int [09:30] if the pid is reused there's no way to tell one way or another [09:30] which is why in general pids aren't reused [09:30] Chipaca: ? [09:31] pedronis: unless you're forkbomming or something [09:31] they cycle around very slowly [09:32] pedronis: anyway my point is that the only thing we have for a process is the int, there isn't any magic to be had [09:34] Chipaca: my point is that the logic in runHook shows that you can avoid these doubts [09:34] to some extent [09:36] pedronis: you realise that does pretty much the same thing? [09:36] pedronis: or am I missing something? [09:36] ? [09:36] it doesn't call Kill if Wait returned [09:36] so our definition of same is not the same :) [09:37] ah! [09:37] missed the return in the select [09:37] /o [09:37] anyway, I'm probably just getting super nitpicky [09:41] Chipaca: interesting there's not a lot of hook specific in runHookAndWait , wondering if it could be turned into a osutil helper and used by both managers [09:41] I'm in the middle of doing exactly that :-) [09:43] it kills the whole group etc [09:43] seems the best approach medium term [09:59] Bug #1698107 opened: Ubuntu Core images should include ntfs-3g [10:01] would it be ok if a hook, when told to abort, had a log message of "command aborted" instead of "hook aborted"? [10:01] pedronis: ^ asking you becaus pstolowski is out today :-/ [10:02] I'm going with "yeah it's fine" [10:02] a log to where? [10:04] there's no logging in runHookAndWait atm [10:05] Chipaca: are you passing a task to this new helper? not just a tomb? [10:05] pedronis: the error returned from this is logged to the task [10:06] there's a couple of "hook"s in those errors that I'm replacing wiht "command"s [10:06] it'll seem obvious given the context, i think [10:16] Chipaca: if you look we prefix those with run hook %q: anyway, so that's fine I even think you can just have "aborted" [10:16] from the helper [10:16] Chipaca: indeed if you are adding things that print the full command, probably better to do it one level up [10:16] yeah, but then "cannot abort:" makes me feel weird [10:17] (as opposed to "cannot abort command:" [10:17] ) [10:17] it's probably just me though [10:17] run hook %q: cannot abort command works [10:17] without command works to [10:17] my commend was mostly about "command aborted" [10:17] we are not aborting the command [10:18] we are aborting the task [10:18] conceptually [10:18] to abort the task we need to abort the command [10:18] anway may just be how brain works [10:21] Chipaca: hola [10:21] mwhudson: q'acelga, caeza! [10:21] Chipaca: sorry i actually only know one word of spanish [10:21] mwhudson: “whaduuupp” [10:21] heh [10:22] but only in a small area of where i grew up in the world [10:22] mwhudson: about this exec thing, were you planning to backportify it? [10:22] s/brain/my brain/ [10:24] Chipaca: hadn't really thought about it too hard [10:25] Chipaca: we'd only really care about the golang-1.6-go in xenial, right? [10:25] Chipaca: would the fact that the core snap would then be built with the workaround in place mean that it wouldn't matter so much if other distros didn't get the kernel fix for ages? [10:26] mwhudson: it's probably more complicated than that, because re-exec means the first exec is from whatever-snapd-is-in-distro [10:26] if so, then i think it sohuld be backported [10:26] right, i'm not sure at which layer the re-exec happens [10:26] if it's snapd-from-distro -> snapd-from-core that's ok right? [10:27] because the snapd-from-core -> snap-confine exec would be protected, and that's the one that screws up [10:28] hmmm [10:28] mwhudson: you're correct on that one [10:28] mwhudson: they all hit the silly pthread thing, but only the setuid one hits the in-kernel race itself [10:28] ("silly pthread thing" being the EAGAIN because of losing the race with clone) [10:28] ah yeah [10:29] that one goes away with this lock, by the way, but I didn't feel like making the case for removing the retry [10:29] ah yeah [10:29] the retry was added for some other reason too iirc [10:29] ah ok [10:30] anyhow, you're correct that the one we care about is the one that exec's snap-confine, and that's (usually) the in-core one [10:30] ok backporting makes sense then [10:30] usually because in some scenarios the distro snapd can be ahead of the core snapd in which case no reexec happens [10:31] did ian's comments on gerrit make sense? [10:31] but that should be rare [10:31] yes! done and pushed patchset 3 [10:35] looks nice and simple [10:36] Chipaca: so yeah create a task on golang-1.6-go and assign it to me once ian seems happy? [10:36] (create a xenial task too, if you have perms for that?) [10:37] will do (or pester people to do) [10:37] mwhudson: thanks! [11:25] * zyga-ubuntu takes a break to find some cool air [11:34] pedronis: three commits added (split in three just for easier review and logging) to #3480 [11:34] snapd#3480 [11:34] PR snapd#3480: overlord/oddjobstate: new package for running commands as tasks [11:35] mup: ya lazy git [11:35] Chipaca: I apologize, but I'm pretty strict about only responding to known commands. [11:35] you say that, but you sure like responding to unknown commands more than you like responding to known ones [11:42] that's funny definition of strict [11:42] unless there's a strict definition of responding behind it [11:47] 32+C makes my mind suffer [11:52] PR snapcraft#1366 opened: cli: Add --version command [11:52] Chipaca: +1 with a couple small wonderings [11:53] thank you [12:01] found a small bunch of Uppercase errors doing some related spelunking [12:22] pedronis: wrt the "cannot RunAndWait", does it show that those were this >< close to be panic(...)? [12:22] yes [12:22] :-) [12:23] fgimenez: https://paste.ubuntu.com/24864240/ doesn't look too bad I would say :-) [12:23] most of them fail because somehow `snap debug confinement` is broken [12:25] morphis: nice! \o/ [12:26] also need to get a proper version for the deb package.. 2.26.4+git3.g2494bc0.dirty looks broken :-) === JanC_ is now known as JanC [12:39] pedronis: would “internal error: osutil.RunAndWait needs ...” be alright? I can't seem to get the name out of the errors without the message losing meaning [12:40] yes, that's fine [12:41] pedronis: you mind if I amend a commit instead of pushing a new one? [12:43] it's ok because it's holiday somewhere [12:43] ;) [12:43] bah, never mind, i'd have to go amend a commit two up [12:43] then rebase [12:43] 's a mess [12:55] * zyga-ubuntu wants to hit his head against the wall [12:56] oooh. frell [12:56] * zyga-ubuntu wasted hour looking for the missing \n that kept stuff stuck [13:01] * zyga-ubuntu tries to join standup [13:06] ogra_: hello, i am a bit confused about uboot. once I have image on the disk do I need to load into memory basically every time to display it as a splash screen with fatload first? [13:14] ogra_: I am just confused what address I should be loading my image to tbh [13:34] the rumours of that being the last iteration of the go patch were greatly exaggerated [13:39] * zyga-ubuntu lunch [13:46] didrocks: hi! is gtk-3-demo expected to work with wayland? (not in strict mode of course-- I'm asking for when I pick up the waylond interface work) [13:46] wayland* [13:47] jdstrand: no, it's just a quick showoff (that's why I didn't want to add a .desktop file) to show that themes are working with current desktop [13:47] jdstrand: I saw you rejected it because of this… [13:48] didrocks: well, I can approve it, but note that with no desktop file if it shows up in the unity launcher and someone pins it, it will be launched unconfined [13:49] didrocks: when run from the command line, does it show up in the unity7 launcher? [13:49] jdstrand: yeah, it's not really for end user (and will probably will removed shortly) [13:49] * jdstrand would love to see someone fix that bug btw [13:50] didrocks: can you request a manual review? [13:50] jdstrand: it does, but I have the deb binary installed here [13:50] jdstrand: sure, thanks! [13:51] jdstrand: so, I would need to clean the whole cache and things (but yeah, I opened a bug about the unity7 cache, unsure it will get fixed though) [13:51] done [14:04] re [14:08] mi [14:08] * Chipaca 's probably done that one before [14:09] ooh, “omnidirectional snapping” [14:10] what? :D [14:12] zyga-ubuntu: http://www.businesswire.com/news/home/20170614005246/en/Omnidirectional-Snapping [14:20] can someone look into [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645) during snapcraft? [14:43] Chipaca: are you up to review s/http.StatusOK/200/ etc ? it will probably be big and tedious [14:48] pedronis: sure [14:50] im blocked on building snaps atm because of that ssl verification error [14:50] is anyone around that can look into that? [14:51] noise][: ^ [14:51] niemeyer, do I need special forum powers to make a wiki? [14:51] kyrofa: have you seen ^ [14:51] we're on it, should be fixed shortly [14:51] noise][: ok thank you [14:51] I think is being worked on atm [14:51] and I'm fixing the monitor we were apparently missing for it :/ [15:08] * zyga-ubuntu defeated another issue in intrd testing [15:09] stokachu: resolved now, sorry for the inconvenience [15:09] noise][: np thanks! [15:21] I have a doubt about the store: is it possible to use build.snapcraft.io to build the snaps for the beta channel of an application but at the same time still manually upload the ones for the stable one? [15:23] pachulo: build.snapcraft.io will release to edge, and then you can release those same revisions to other channels OR upload manually other revisions and release them to channels you choose [15:23] does that help? [15:32] yeah! thanks noise][ ! [16:07] PR snapcraft#1360 closed: cli: stop leaking green text [16:08] \o/ [16:09] Chipaca: seems there's a new bunch of shellcheck failures in prepare.sh etc [16:09] augh [16:10] fgimenez: can you add shellcheck to the ubuntu-16.04-64 image? or does that require a gustavo? [16:12] Chipaca: yes we need him, i can prepare an instance with the required changes but we need an snapshot from it and create an image from that snapshot, gustavo does that part [16:13] ok [16:23] PR snapd#3485 opened: tests: fix nightly suite [16:32] PR snapd#3486 opened: many: switch to use http numeric statuses as agreed [16:33] Chipaca: ^ [16:33] * Chipaca looks [16:38] pedronis: is it bad that I know by heart what 418 is, but not what 405 is? [16:38] not bad, but peculiar :) [16:39] Chipaca: snap [16:39] :-) [16:40] Chipaca: anyway feel to add where I should add a comment [16:40] *feel free [16:40] so far i've only had to double-check the 405 [16:41] anyway there I didn't add the comment also becasue there's BadMethod on the other side [16:42] though it's really MethodNotAllowed to be precise [16:51] pedronis: feel free to rename the handler if you wish [16:51] handler/responder/whatever it's called [16:51] but anywa, +1 [16:52] thx [17:00] My french press broke. I have to make every cup via pour over. Someone pity me [17:00] noise][: if an automatic snap is setup in the store but the alias is removed from the snapcraft.yaml will it still try to auto connect that alias? [17:01] conjure-up currently owns the juju top level alias [17:01] noise][: i guess we need to remove that check from the store because both juju and conjure-up can't be installed alongside each other [17:09] noise][: https://forum.snapcraft.io/t/please-remove-juju-alias-from-conjure-up/1016 just when you have time [17:22] morphis, ping [17:23] om26er: pong [17:23] morphis, re: snapd on raspbian, how reliable is that for now ? [17:23] ...or stable [17:23] it's based on the 2.26.4 release of snapd, doesn't have confinement yet but works for most snaps [17:24] we're currently validating most things by running our extensive test suite on it [17:25] ok, any effort to make snapd installed by default on Raspbian ? snaps on that environment by default make great sense and would make our lives easier [17:25] I know its a bit early to ask, but still. [17:27] stokachu: doing.. [17:28] morphis, re: Pi zero, is debian going to be in the core snap, given Ubuntu is not available on that arch. [17:28] noise][: ty! [17:28] om26er: right now there is no core snap available for the Pi zero as Ubuntu doesn't support armv6l [17:30] will Ubuntu support armv6l in future ? [17:30] (I presume not) [17:35] om26er: we're soon introducing something called base snaps [17:35] morphis, i.e. a core snap that is not Ubuntu based ? [17:35] somewhat [17:35] you will have a generic core snap which ships snapd and a base snap for raspbian [17:36] but this is still in design on nowhere done [17:36] hi there [17:36] is there a way on build.snapcraft.io to point to a github branch ? [17:36] pachulo: hi ;) [17:37] morphis, are you in touch with Raspbian community or is that an isolated effort ? [17:37] om26er: it's not isolated [17:37] but nothing I can talk about yet [17:37] * om26er would very much like to be able to install snaps on RPi by default. Makes our work very simple for cases where we need to do PoCs on Pi. [17:46] lasconic: not at this time, sorry: https://github.com/canonical-ols/build.snapcraft.io/issues/701 [17:46] er not that one [17:46] https://github.com/canonical-websites/build.snapcraft.io/issues/440 [17:49] cjwatson: thanks, I added my voice [17:54] lasconic: no need [17:54] but thanks for the data point [17:55] cjwatson: it never hurts to feel that there is an actual need [17:56] stokachu: Note it seems you have a `ln -s conjure-up.juju /snap/bin/juju` in your configure hook that was confusing me (thx to pedronis for figuring that out) [17:57] noise][: yea we're still wanting new users to be able to run `juju` if they have never installed it before [17:57] but other who want juju + conjure-up to not conflict as well [17:57] snap doesn't have a nice way to tell a user that if they want both then need to unalias conjure-up.juju [17:58] well there's snap prefer [17:58] in 2.25+ and install --unaliased in 2.27+ [17:58] on 2.24 that alias will probably prevent to install a juju snap anyway [17:59] yea that was the issue [17:59] some people wanted both [17:59] even if it's not in snap aliases [17:59] the logic for that in 2.25+ and 2.24 is different [17:59] stokachu: I think is worth pinging Gustavo about this issues when he's back [18:00] we will want to keep it a single command `sudo snap install conjure-up --classic` so maybe adding `--unaliased` to that? [18:00] or would be nice for snap to just prompt the user [18:00] ok, i can post some thoughts to the forum too [18:01] fwiw, now if i install conjure-up, then juju, I get the juju snap's juju (with snapd 2.24) [18:02] noise][: yea that i think that's intended, cory_fu_ ^? [18:02] noise][: interesting, I thought that wouldn't work [18:02] right, that's what i would expect at least, was just replying to pedronis comment [18:03] I'm probably misremembering some detail [18:03] I'm quite sure it's expected to work with 2.25 [18:04] https://pastebin.ubuntu.com/24866018/ [18:04] noise][: that is weird [18:05] PR snapcraft#1362 closed: Only install golang-go if it is not found in PATH [18:07] stokachu: Yeah, that's the expected behavior. Defer to the juju snap if it's installed before or after [18:08] cory_fu_: ok cool [18:10] stokachu, noise][, pedronis: FWIW, though, the juju provided by conjure-up never shows up as an alias because it's not a proper snapd alias. That was the only way I could make it defer automatically [18:10] it's a bit of a hack tbh [18:11] otoh the full feature set to deal with this was deemed too complex, so as I said worth pinging Gustavo when is around [18:54] kyrofa: I can probably get you an aeropress sometime tomorrow [18:55] Chipaca, I need to get one of those for travel anyway. I'm tired of hotel instant coffee [18:58] kyrofa: I'm told (but couldn't confirm) that there are manual burr grinders that slot into the aeropress's plunger for a very compact travel coffee thing [19:02] https://www.amazon.com/gp/product/B0044ZA066/ [19:03] Porlex Mini Stainless Steel Coffee Grinder [19:27] * genii 's ears perk up for a moment at the mention of coffee [19:37] Oh, that's an excellent idea! [20:18] anyone else seeing slow downloads from the snap store? I'm getting like 150 KB/s from an aws box [20:24] kyrofa: thanks for the review! [20:24] ryebot, yeah, ctrl+c and try again. Some of the cdn endpoints suck [20:25] bdx, no problem :) [20:26] kyrofa: ack, thanks [20:27] ryebot, I think half of them are in tanzania [22:25] PR snapd#3486 closed: many: switch to use http numeric statuses as agreed === test is now known as Guest7150