[00:00] <utlemming> aatchison: yup, confirmed....I just pulled it and it worked as expected.
[00:03] <aatchison> utlemming, I just installed it today, but I'll check. I'm going to another talk at Scale, but I'll get back to this;)
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== p1gmale0_ is now known as p1gmale0n
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[10:02] <JamesTait> Good morning all!  Happy Friday, and happy Answer Your Cats' Questions Day! 😃  🐈
[10:15] <jstephan> He guys, I am playing around with Ubuntu Core (snappy) on Raspberry, My project is in Python, any idea how I can get pip and compile some modules I need?
[10:23] <asac> ppisati: i am playing with making a snapcraft plugin that builds kernel snaps from source without having to do a deb etc. as intermediate step and noticed that make install behaves odd in the sense that it does not just install the zImage etc. in INSTALL_PATH, buut it rather also tries to create a .deb etc.... any idea how i can do make install without that part?
[10:24] <asac> jstephan: check out snapcraft ... it has python2/python3 plugins that should support pip
[10:24] <ppisati> asac: not really, the deb packaging of the kernel is a bit convoluted
[10:25] <ppisati> asac: try to ping apw, he might know better than me what to do
[10:25] <ppisati> asac: but if i was you
[10:25] <asac> apw: :)
[10:25] <ppisati> asac: i would just create our config from our src tree
[10:25] <asac> ppisati: so make install just magically assumes that i want to produce a .deb? wow :)
[10:25] <ppisati> asac: e.g. fdrc && fdr-prepare-generic
[10:26] <asac> ok.... and then?
[10:26] <ppisati> asac: copy the config to a git tree and compile it there
[10:26] <ppisati> oh wait
[10:26] <asac> sure the compile is fine... i have features in myh plugin for providing a config file or using defconfig or use defconfig and overload a few CONFIGS etc.
[10:27] <apw> asac, in the packaging we use like make boot/Zimage or whatever to get just the kernel bits of the right form and we make install_modules to make that
[10:27] <asac> install is causing the trouble for me... it starts off doing the right thing (e.g. copy stuff to INSTALL_PATH)
[10:27] <asac> but then it also goes and creates a deb
[10:27] <apw> asac, but i would not expect make install to make a deb
[10:27] <asac> right, but it does for me :(
[10:27] <asac> latest torvalds trunk that is... but let me see
[10:28] <tzununbekov__> asac, hey, have you seen our email to you?
[10:28] <jstephan> asac: I will have a look
[10:28] <asac> tzununbekov__: not sure... who are you :)?
[10:30] <asac> tzununbekov__: jst /msg me the mail subjhect and i will look for it :)
[10:47] <asac> apw: ok found that kernel make install runs /sbin/installkernel if that exists on system, which i would guess (as that is on my system from a package called debianutils) seems to be the one spoiling the raw make install show :)\
[10:48] <asac> a bit sad that there is no switch to ignore an installkernel helper ... hmm.
[10:50]  * asac gives up and makes custom code to fiddle the right bits out of tree instead of make install
[10:55] <LefterisJP> kyrofa: As you suggested yesterday I made a PR for the suggested generic script snapcraft plugin: https://github.com/ubuntu-core/snapcraft/pull/252
[11:15] <LefterisJP> ops, there is an error in another test. Fixing it now.
[11:44] <apw> asac, would you not be making the bits for this in a chroot of your own making, so you can control if that is in there, ie supply like a snappy-build package which diverts the existing and replaces it with one yout want
[11:49] <asac> apw: yeah, think i could do it, but then few lines o python that copies the *image is also goodie
[11:49] <asac> thanks
[12:29] <kyrofa> Good morning
[12:29] <LefterisJP> kyrofa: Morning :)
[12:29] <kyrofa> LefterisJP, thanks for the PR! I'll take a look :)
[13:03] <renat> Hi all! It's Renat from Screenly.
[13:03] <renat> I have a question again=)
[13:03] <renat> How can I "sign" a snap, so I won't need to use --allow-unauthenticated flag to install a snap, or build an image?
[13:10] <LefterisJP> kyrofa: addressed the remarks of your review
[13:13] <kyrofa> renat, that's done in the store
[13:13] <kyrofa> renat, though in 16.04 you'll be able to do it yourself with assertions
[13:14] <renat> kyrofa, thanks!
[13:15] <kyrofa> renat, it's a debsig. So while you could sign it, Ubuntu Core 15.04 is only setup to verify against a single key: the store's
[13:16] <renat> kyrofa, didn't know. Thanks!
[13:17] <kyrofa> renat, sure thing :)
[13:17] <kyrofa> renat check out /etc/debsig/policies
[13:22] <renat> kyrofa, one more question. About "follow symlinks"
[13:22] <kyrofa> renat, ah, yes?
[13:23] <renat> It was named "symlinks" before, and copied symlinks as symlinks only if it's value is true. But after I renamed it to follow symlinks - logic should change now. So follow-symlinks means "copy file instead of symlink", right?
[13:26] <kyrofa> Ah, interesting point. Indeed, I agree. And I do agree that follow-symlinks is a more clear config name
[13:27] <kyrofa> renat, what did you think of my dangling link comment, by the way?
[13:28] <renat> We can add "ignore-dangling" option to control that behavior.
[13:28] <kyrofa> renat, but read the docs for copytree-- I don't think that'll work
[13:28] <renat> 1 min.
[13:29] <kyrofa> renat, it only seems to apply when you're FOLLOWING the symlinks. If you're copying the symlinks it doesn't seem to care
[13:30] <kyrofa> renat, here: "Changed in version 3.2: Added the copy_function argument to be able to provide a custom copy function. Added the ignore_dangling_symlinks argument to silent dangling symlinks errors when symlinks is false."
[13:30] <renat> It only silences the error message.
[13:30] <renat> You won't get error message if you copy symlinks as symlinks.
[13:31] <kyrofa> renat, right, which means we can _create_ dangling symlinks
[13:31] <kyrofa> renat, in this case, what I mean by dangling is symlinks that point outside the snap
[13:31] <kyrofa> renat, they might be valid at the time of .snap creation
[13:31] <kyrofa> renat, but not install/runtime
[13:31] <kyrofa> renat, make sense?
[13:32] <renat> Yes.
[13:32] <renat> Understood.
[13:32] <kyrofa> renat, as-is, copying everything following the symlinks, that's not a problem. So the only way I see to avoid introducing that problem is with a custom copy function that symlinks what it can and copies the rest
[13:33] <kyrofa> renat, kind of annoying, granted
[13:33] <kyrofa> renat, sorry :P
[13:33] <renat> kyrofa, this approach is not very intuitive. You will need to add "smart-copy" and document its behavior then.
[13:33] <renat> sorry, smart-copy option.
[13:34] <kyrofa> renat, so perhaps you would argue that, if they turned the symlink following off, (I guess it should be on by default), they deserve the dangling symlinks since they should have known about them?
[13:34] <kyrofa> renat, and it is indeed a corner case
[13:35] <renat> kyrofa, yes. At least - they will know about it during testing.
[13:36] <kyrofa> renat, maybe. It could be more insidious. I'll have to get my colleagues thoughts there
[13:36] <renat> kyrofa, thanks.
[13:36] <kyrofa> renat, sorry for the trouble, thanks for bearing with us :)
[13:37] <renat> kyrofa, no problem. Let me return to work and generate more questions=)
[13:47] <kyrofa> elopio, sergiusens and I have a meeting which may flow over standup
[14:27] <pindonga> elopio, I've reworked my PR so it doesn't depend on xenial anymore... if you, kyrofa or someone else could please review it? https://github.com/ubuntu-core/snapcraft/pull/197
[14:27] <pindonga> if you like the approach, I'll squash the commits and fix the coveralls errors
[14:30] <kyrofa> pindonga, excellent use of discretion regarding the squashes. For future reference, checkout git commit --fixup. Makes the squash insanely easy
[14:30] <pindonga> ack
[14:31] <kyrofa> pindonga, https://robots.thoughtbot.com/autosquashing-git-commits
[14:32] <pindonga> kyrofa, while ssoclient is already packaged in xenial, I proposed vendoring it in to avoid the blockage on getting tests running in xenial
[14:32] <pindonga> this also enables snapcraft to include this feature in previous versions
[14:32] <pindonga> eg, trusty
[14:33] <kyrofa> pindonga, I've never vendored in python before. I guess elopio or sergiusens might need to speak on that
[14:37] <kyrofa> pindonga, do you have experience with that?
[14:37] <pindonga> kyrofa, not really, I've essentially looked what other people do
[14:38] <pindonga> ideally I'd like not have to modify the vendored pkg import paths
[14:38] <pindonga> so if someone more experienced in this area can suggest a way, +1
[14:38] <kyrofa> pindonga, agreed
[14:39] <elopio> good morning.
[14:39] <kyrofa> elopio, good morning!
[14:40] <elopio> pindonga: working around xenial seems the way to go. As the only thing that fails on travis are the examples, it's ok because the idea has been always to move that to jenkins. But yesterday the disk of the jenkins slaves got full. What a week to be QA...
[14:40] <elopio> fgimenez: ^ did you see the slaves? I wasn't sure what I could delete.
[14:41] <elopio> kyrofa: np about the standup. If you want to do it, ping me when ready.
[14:41] <mvip> mectors: We have a blocking issue for Screenly on MWC. The bug is filed here (https://bugs.launchpad.net/snappy/+bug/1500755). Any chance you or someone could bump up the priority for that one?
[14:41] <ubottu> Launchpad bug 1500755 in Snappy "bootloader firmware needs update to get vchiq working with 4.2" [High,Confirmed]
[14:41] <pindonga> elopio, right, I also think vendoring in this case makes sense to prevent snapcraft requiring xenial from now on
[14:42] <pindonga> not sure what's the best way to vendor stuff in cases like this though
[14:44] <elopio> I'll check.
[14:44] <elopio> pindonga: first thing I see is that your branch drops coverage 7%.
[14:44] <pindonga> yes, am looking at that
[14:44] <pindonga> but I was mostly concerned whether you're ok with the vendoring of ssoclient
[14:45] <pindonga> elopio, and tbh, that coverage drop is only there bc I've modified main.py and it didn't have enough coverage to begin with
[14:45] <pindonga> :)
[14:47] <elopio> right, I'm not saying you have to get it back to 90%. Just looking :)
[14:47] <elopio> pindonga: so, how do we run the tests of that vendor package?
[14:48] <pindonga> elopio, I didn't include the tests for the vendored packages as those should be tested upstream
[14:48] <pindonga> and considered here just as an external library
[14:48] <pindonga> vendored in for convenience only
[14:48] <pindonga> ie, we don't test them
[14:49] <elopio> pindonga: um, I get the idea. And why don't we just put it in a different repository, package them and import them here?
[14:49] <pindonga> package as in deb packaging?
[14:50] <pindonga> that's what we're trying to avoid here
[14:50] <pindonga> new packages should go via xenial
[14:50] <pindonga> also, it's quite an overhead
[14:50] <pindonga> and this code might evolve in ways incompatible with deb pkg lifecycles
[14:52] <elopio> ah right right. I don't like this, copying code into the repository without running its tests. What about a git submodule?
[14:52] <elopio> pindonga: lets say we want to make a release suddenly. How can we be sure that the new code works with this vendored library?
[14:53] <sergiusens> elopio, want to do the standup now?
[14:53] <elopio> sergiusens: yes.
[14:53] <pindonga> elopio, there are tests for the commands that use the vendored lib
[14:53] <pindonga> elopio, I could include the upstream tests here as well if you like, but I see little to no benefit
[14:54] <pindonga> as long as the upstream lib doesn't change it's api this should work ok
[14:54] <pindonga> and since we control those upstream apis we should make sure to update snapcraft when/if they change
[14:55] <elopio> pindonga: ok. Let me read it fully after the call.
[14:55] <pindonga> ack
[14:58] <Chipaca> JamesTait: question, is there a way in cpi to search only on the package name?
[14:59] <JamesTait> /api/v1/search?q=name:%22package_name%22 should work I think?
[15:00] <JamesTait> e.g. https://search.apps.ubuntu.com/api/v1/search?q=name%3A%22com.ubuntu.music%22&page=1
[15:01] <elopio> ping jdstrand: do you have some time to help me here? https://github.com/elopio/snapcraft/commit/43d6ed402f98fa39046d455ffdcbbde0a244c943#commitcomment-15606270
[15:03] <JamesTait> Chipaca, yay?
[15:06] <fgimenez> elopio, sorry didn't notice it, it's the same problem we had with devicemapper http://paste.ubuntu.com/14597997/, hopefully we'll have a new server deployed in a few minutes
[15:09] <jdstrand> elopio: I planned on giving you a hand but wasn't ready just yet. I will ask-- what is this on 15.04 or 16.04?
[15:09] <mvip> mectors: Cool. Thanks.
[15:15] <elopio> jdstrand: 16.04, all snaps.
[15:16] <elopio> jdstrand: but don't hurry, whenever you have time. I was just wondering if you got the ping.
[15:18] <jdstrand> I did
[15:19] <pindonga> elopio, btw, pushed a new test that improves coverage
[15:19] <elopio> pindonga: saw it. Thanks!
[15:20] <jdstrand> I responded in the request. the fix is actually on its way. I am curious though, can I see your snapcraft.yaml, /snaps/mosquitto.../current/meta/package.yaml and /var/lib/snappy/apparmor/profiles/mosquito...
[15:32] <elopio> jdstrand: oh nice, so I can just remove the overwrite.
[15:32] <elopio> jdstrand: here's the yaml: https://github.com/elopio/snapcraft/blob/43d6ed402f98fa39046d455ffdcbbde0a244c943/examples/mosquitto/snapcraft.yaml (from the previous link I gave you you just have to swipe up :)
[15:32] <fgimenez> elopio, the old server is up again http://162.213.35.179:8080/ after http://paste.ubuntu.com/14598180/
[15:32] <elopio> and I didn't write any apparmor profile. But I saw the one from mosquitto upstream, let me find it again.
[15:32] <fgimenez> elopio, i've taken the opportunity to spin up a vivid slave there too
[15:32] <elopio> fgimenez: awesome. Let me join the hangout.
[15:33] <asac> apw: ppisati: is it possible to use squashfs as initrd?
[15:33] <apw> asac, initramfs is cpio.gz format, each segment of an initramfs has to be that format
[15:34] <elopio> jdstrand: https://git.eclipse.org/c/mosquitto/org.eclipse.mosquitto.git/tree/security/mosquitto.apparmor
[15:34] <elopio> I assume my snap is consuming that one. Is that right?
[15:34] <asac> apw: hmm. i see this; http://lists.busybox.net/pipermail/buildroot/2013-January/066195.html
[15:36] <apw> asac, legacy mode will mount other types, iff that type is not a module ... but why that format, when we have a format that is good
[15:37] <asac> apw: just pondering as we use squashfs for snaps etc.
[15:37] <asac> apw: do i need to enable some config to get legacy mode?
[15:38] <apw> asac, it is enabled by default, though whether upstream will keep it long term is less clear
[15:39] <jdstrand> elopio: can you give me /snaps/mosquitto.../current/meta/package.yaml and /var/lib/snappy/apparmor/profiles/mosquito... too?
[15:39] <asac> right. maybe its not in trunk anymore? my kernel just detects junk according to log
[15:39] <jdstrand> elopio: (fyi, I'm in and out of meetings so I will be laggy)
[15:41] <apw> asac, with which kernel, i'd expect it to detect junk and then detect it if it was going to
[15:41] <apw> but ... i am not sure it is a good idea to rely on it
[15:41] <apw> noone uses those formats normally, everything is the new cpio format and has been for a long time
[15:43] <asac> apw: yeah, it didnt detect it after seeing junk though... but ok, guess better not go down that path at all
[15:44] <kgunn> mvo: hey there, i was just trying u-d-f from your all-snaps branch just now...but i can't quite figure out the commands....
[15:44] <kgunn> i thot it would be
[15:44] <kgunn> sudo /home/kg/Downloads/ubuntu-device-flash core rolling --channel edge -o xenial_core_amd64.img --developer-mode --gadget=generic-amd64 --size=5
[15:45] <kgunn> but it keeps saying "expected 1 gadget snap"
[15:48] <sergiusens> kgunn, maybe try --gadget=generic-amd64/edge ?
[15:54] <kgunn> sergiusens: thanks...but no joy
[15:55] <elopio> @kyrofa https://github.com/ubuntu-core/snapcraft/pull/202
[15:55] <nothal> elopio: No such command!
[15:56] <elopio> pleeeeaaase
[15:56] <kyrofa> elopio, sheesh man
=== chihchun is now known as chihchun_afk
[16:01] <kyrofa> Alright, time to move off the grid a bit to weather the storm. I'll be a bit difficult to reach I'm afraid
[16:02] <elopio> jdstrand: ah, you meant the installed ones. I'm sorry. https://paste.ubuntu.com/14598353/
[16:03] <mvo> kgunn: sorry that its a bit hard to use right now, there is an exmaple here http://people.canonical.com/~mvo/all-snaps/make-rpi2-all-snap and here is what I use for amd64 http://paste.ubuntu.com/14598354/
[16:03] <elopio> kyrofa: good luck man! I'll wait for the cute new release pictures on monday ^_^
[16:03] <kgunn> mvo: ta
[16:03] <kgunn> will try in a moment
[16:04] <kyrofa> elopio, ugh
[16:04] <kyrofa> elopio, I might have to birth that boy myself :P
[16:07] <elopio> hah, show the world that free software prepares you for absolutely everything. make us proud!
[16:07] <kyrofa> elopio, hahahaha!
[16:11] <Chipaca> JamesTait: thanks muchly
[16:11] <Chipaca> JamesTait: no i'm not lagged why do you ask
[16:11] <Chipaca> :-)
[16:11] <JamesTait> 😃
[16:11] <JamesTait> Glad to be of service!
[16:23] <elopio> fgimenez: can you upload your vivid udf somewhere?
[16:23] <fgimenez> elopio, sure give me a second
[16:25] <fgimenez> elopio, 10.55.32.74:/home/ubuntu
[16:26] <elopio> thank you.
[16:34] <Chipaca> JamesTait: question for you, v2
[16:36] <JamesTait> No, we don't have a v2 api yet. 😉
[16:38] <Chipaca> https://search.apps.ubuntu.com/api/v1/search?q=name%3D%22http%22
[16:38] <Chipaca> JamesTait: what's going on there? (what'm i missing?)
[16:40] <Chipaca> JamesTait: because I *could* argue that the match from those names to "http" is rather poor
[16:40] <Chipaca> JamesTait: if I were feeling ornery, I mean
[16:40] <Chipaca> not that I am, in any way, trying to argue this, of course
[16:41] <Chipaca> it just seems to me that "bankaustria.peter-bittner" does not, strictly speaking, if I were being picky, match "http".
[16:41] <JamesTait> Hmmm...
[16:44] <JamesTait> Looks to me like it's matching http from the description for some reason.
[16:46] <JamesTait> Er, hang on... what's that %3D in there? Shouldn't that be %3A ?
[16:47] <JamesTait> Ah, but that doesn't find your package because its full name is http.chipaca and it doesn't have an alias!
[16:47] <Chipaca> d'oh! 3A!
[16:48] <JamesTait> But dropping the %22 from the query to make it a keyword search instead of a literal phrase returns your package and one other.
[16:48] <Chipaca> JamesTait: it's only exact matches when used like this?
[16:48] <Chipaca> ah
[16:49] <Chipaca> woooo!
[16:49] <Chipaca> that's perfect, then
[16:49] <Chipaca> so, name:$query
[16:49] <Chipaca> not name=$query
[16:49]  * Chipaca LARTs himself
[16:50] <Chipaca> JamesTait: thanks again
[16:50] <Chipaca> and sorry to have wasted your time a little there :-)
[16:50] <JamesTait> q=[<field_name>:]value[,[field_name:]value]...
[16:51] <JamesTait> Or q=[<field_name>:]"value"[,[field_name:]"value"]...
[16:51] <JamesTait> Or some combination thereof.
[16:52] <Chipaca> JamesTait: and if value contains " how do you quote it?
[16:53] <JamesTait> That, sir, is an excellent question!
[16:53] <Chipaca> or ,
[16:53] <Chipaca> I mean, it could also be ","
[16:53] <Chipaca> :-)
[16:53] <Chipaca> because users are eeevil
[16:53] <JamesTait> No! Say it ain't so!
[16:53] <Chipaca> JamesTait: https://www.youtube.com/watch?v=ZGNtl9A1JwU
[16:54] <JamesTait> Ah, Spongebob. Where would we be without you?
[16:54] <jdstrand> elopio: security-override ended up in 'subscribe'. I think you want it in mosquito, no?
[16:54] <JamesTait> Not in a pineapple under the sea, that's for sure.
=== chihchun_afk is now known as chihchun
[16:55] <elopio> jdstrand: oh... I'm ashamed, I'm sorry :)
[16:56] <JamesTait> I think the answer to your question is to \-escape them, but I'm looking for an example to verify that.
[16:56] <elopio> fgimenez: m-o credentials ready, xenial slaves patched. Is it normal for the vivid slave to take that much time to go online?
[16:57] <Chipaca> JamesTait: and is there documentation as to what things are "special" in a query? i notice "*" is special, for example
[16:57] <Chipaca> JamesTait: as is ?
[16:59] <fgimenez> elopio, great! it's still pulling layers from docker hub, but it seems that won't take too long, most of them are already pulled http://paste.ubuntu.com/14598736/
[16:59] <elopio> ok, I'll wait.
[17:00] <JamesTait> Chipaca, in fact, \-escaping the quote doesn't seem to make a difference, so I'm not sure.  The "special" characters mostly come down to those that Elasticsearch uses in its query syntax, which I wish I could find documented in a single place.
[17:02] <Chipaca> and elasticsearch is just a frontend for lucene, is it not?
[17:06] <elopio> fgimenez: I still don't understand vault to keep secrets. We would store the m-o password in a local vault, and then pass a token from an environment variable to read it?
[17:06] <elopio> oh well, but it's late for you. That's for next week.
[17:10] <fgimenez> elopio, np, yes they recommend a $VAULT_TOKEN var, anyway so far i had just looked into kubernetes secrets, the bin/create-secrets.sh script is about those
[17:10] <fgimenez> elopio, vivid slave is about to show up
[17:15] <jdstrand> elopio: np
[17:17] <fgimenez> o/ nice weekend everyone
=== chihchun is now known as chihchun_afk
[18:20] <elopio> today I'm going to take a looong lunch to teach a class of geographers about openstreetmap
[18:20] <elopio> let's see how it goes.
[18:20] <elopio> bbl.
[20:14] <kyrofa> elopio, quick one: https://github.com/ubuntu-core/snapcraft/pull/253
[22:26] <wiggleworm> I am looking for help with enabling console but with a twist - I want to see the systemA/systemB login via console
[22:26] <wiggleworm> I am able to enable cosole ttyS(x) and see the boot process
[22:27] <elopio> <- back
[22:27] <wiggleworm> I want to be able to see the boot choices systemA/systemB
[22:49] <elopio> wiggleworm: we are leaving the systemA/systemB implementation
[22:49] <elopio> now everything is handled as snaps, even the boot files.
[22:50] <elopio> maybe you should explain what's your goal, and then somebody will be able to give you pointers.
[22:50] <elopio> however, it's friday and it's late. The developers are already afk.
[22:58] <tsimonq2> elopio: although there still might be some developers in the US that are lurking! :)
[23:01] <elopio> tsimonq2: right. [Most] devs are afk. And if they are not, they should starting the party right now. It's been a good week :)
[23:05] <tsimonq2> elopio: well, again, some devs are still in the US, and idk if most of them are in Europe anyways :)
[23:05] <tsimonq2> ¯\_(ツ)_/¯