[00:50] <neutrino> Looks like private snapps will be supported in 16.04 LTS
[01:07] <qengho> I'm trying to test a new snap on my Ubuntu classic machine. I get an error at snap install that "sc-filtergen executable not found". Is there a Dependency I should fulfill manually? Is that a bug?
[01:51] <Tenacious-Techhu> In what ways is Snappy secure by default, and in what ways is it not?
[03:04] <Tenacious-Techhu> neutrino, you keep popping in and out; are you sure you aren't a virtual particle?
[08:17] <dholbach> good morning
[08:25] <Tenacious-Techhu> In what ways is Snappy secure by default, and in what ways is it not?
[09:35] <JamesTait> Good morning all!  Happy Friday, and happy Doodle Day! 😃
[09:55] <noizer> Good morning :D
[09:58] <qwebirc389725> In what ways is Snappy secure by default, and in what ways is it not?
[09:59] <Tenacious-Techhu> In what ways is Snappy secure by default, and in what ways is it not?
[10:06] <Chipaca> zyga, pedronis, do you know of any reason not to merge mvo's branches? the ones that move things to the overlord
[10:07] <Chipaca> they have two +1's and are all green and lurvely
[10:07] <pedronis> ?
[10:08] <Chipaca> pedronis, in the list of pull requests, the last four
[10:08] <Chipaca> actually all of mvo's branches
[10:08] <Chipaca> (there are five of 'em)
[10:08] <pedronis> the SetActive one doesn't seem to have two +1
[10:09] <Chipaca> yep
[10:09] <Chipaca> but i can provide that :-)
[10:09] <pedronis> the Install one seem to need an added TODO: about w.Sync
[10:09] <Chipaca> and the one that drops meta repos has no +1s
[10:09] <pedronis> not a strong reason not to land it, but a small branch to do after or something
[10:10] <pedronis> I mean the branch for adding the TODO
[10:10] <Chipaca> yep
[10:10] <pedronis> not solving the problem
[10:10] <Chipaca> with him away until tuesday, i'd merge as is and then push a branch with the todo :-)
[10:12] <pedronis> 395, 397, 398 seems landable
[10:12] <Chipaca> ok, merging the ones with two +1's, then i'll review the diffs for the last two
[10:12] <pedronis> I'm not sure about the rest
[10:12] <Chipaca> yeah, without the first three merged it's tricky to review the last two :-)
[10:13] <Chipaca> ooooh, conflicts!
[10:13] <pedronis> life is hard
[10:14] <Chipaca> i guess i'll be fixing those first then :-)
[10:19] <Chipaca> hmm, how do i merge in a branch from somebody else?
[10:19] <pedronis> ?
[10:19] <Chipaca> I'm on my master, and I want to merge in https://github.com/mvo5/snappy/tree/refactor/remove-details-from-repo
[10:19] <Chipaca> to then fix the conflicts and propose
[10:19] <pedronis> you fetch it and merge
[10:20] <Chipaca> i guess i've got to add mvo as a remote first
[10:20] <pedronis> you can do that or not
[10:20] <pedronis> not works too, you get a FETCH_HEAD
[10:20] <pedronis> that you can merge
[10:20] <pedronis> if yous setup the proper remote
[10:20] <pedronis> you can pulled down the nicely named branch
[10:21] <Chipaca> yeah, doing that
[10:21] <Chipaca> funny how so many months in these things still trip me up
[10:23] <Chipaca> strange, that merged with no conflicts
[10:30] <sergiusens> Chipaca, morning, did you have a chance to look at the %h thing?
[10:30] <Chipaca> sergiusens, no
[10:31] <Chipaca> sergiusens, does the systemd service file have %h in it?
[10:31] <sergiusens> Chipaca, yes
[10:31] <Chipaca> pitti, why would a systemd unit not replace %h?
[10:32] <sergiusens> Chipaca, from the go template we have in snappy
[10:32] <Chipaca> sergiusens, yep, was wondering if it was us messing things up, or if it was systemd
[10:32] <Chipaca> oh, hold on
[10:33] <Chipaca> %h doesn't work when systemd is pid 1?
[10:33] <noizer> Hi, got a short question how can I install python-dev on a snap. it is for installing uwsgi.
[10:33] <Chipaca> sergiusens, %h doesn't work when systemd is id 1
[10:33] <sergiusens> Chipaca, ah
[10:34] <sergiusens> Chipaca, "Please note that specifiers "%U", "%h", "%s" are mostly useless when systemd is running in system mode. PID 1"
[10:34] <sergiusens> kyrofa, ^
[10:34] <sergiusens> Chipaca, should we change %h in snappy to /root?
[10:35] <Chipaca> sergiusens, yes
[10:35] <Chipaca> sergiusens, if we mean /root, yes :-)
[10:38] <sergiusens> Chipaca, we do
[10:48] <sergiusens> Chipaca, for your consideration https://github.com/ubuntu-core/snappy/pull/442/files
[10:50] <Chipaca> sergiusens, hero
[10:52] <Chipaca> sergiusens, oops, tests fail
[10:58] <zyga> Chipaca: no, I don't know but I wasn't really looking at all of mvo's branches lately
[11:05] <dholbach> sergiusens, kyrofa: what do you suggest we do about images in snapcraft docs?
[12:12] <jdstrand> Chipaca: hey, I'm making review tools updates for snap.yaml and trying to understand which of the 'apps' options can be used together. now that there is no separate structure for services and binaries, the trigger for 'is a service' is app.Daemon, correct? Looking add addPackageServices in click.go, that seems to be the case
[12:13] <Chipaca> jdstrand, yes
[12:13] <Chipaca> jdstrand, and binaries have exec=
[12:13] <jdstrand> do they?
[12:13] <Chipaca> don't they?
[12:13] <jdstrand> exec isn't documented in meta.md
[12:13] <Chipaca> i'm reporting from memory, not from code
[12:13] <jdstrand> and addPackageBinaries says !app.Daemon
[12:13] <Chipaca> so believe the code
[12:13] <jdstrand> ok
[12:13] <Chipaca> :-)
[12:15] <jdstrand> Chipaca: I'm going to also assert in the tools that ports, bus-name and the socket options all require daemon. any objections? (obviously, this can be changed going forward)
[12:20] <kyrofa> Good morning
[12:21] <noizer> kyrofa good morning :D
[12:21] <noizer> I have already a question for you
[12:23] <noizer> kyrofa i want to install uwsgi with the pip packages. but got all the time an error
[12:23] <noizer> this error means something like that i need python-de
[12:23] <noizer> *python-dev
[12:24] <noizer> but when i put python-dev in an other part so i would be sure that it is installed before the other part( the part with the uwsgi)
[12:24] <noizer> this can't work because then I have duplicated files from python :s
[12:25] <noizer> I will send you a yaml file
[12:29] <noizer> kyrofa http://pastebin.com/u9S3unUD
[12:30] <kyrofa> noizer, if you want to use a stage package within a part, it should probably be specified within that part instead of another
[12:31] <noizer> ok I tried that too but it doesn't work :s
[12:32] <noizer> he needs to get python.h kyrofa
[12:37] <ogra_> should that be in "build-packages" then instead of "stage-packages" ?
[12:38] <kyrofa> ogra_, probably
[12:38] <kyrofa> noizer, though linux is case-sensitive-- do you actually mean Python.h, or are you really saying python.h?
[12:39] <kyrofa> noizer, because python*-dev only gives the former
[12:39] <noizer> Python.h
[12:39] <noizer> excuse me typo
[12:40]  * ogra_ isnt sure we even copy /usr/include into the snap for stage-packages, might be only /usr/lib|share and /usr/bin|sbin
[12:40] <ogra_> (like we rip  out documentation and other unusable stuff)
[12:41] <kyrofa> ogra_, we unpack the deb... I don't remember seeing code to clean it at all-- though I may be wrong
[12:42] <ogra_> well, i know we dont copy over manpages and stuff
[12:42] <ogra_> so perhaps you need an explicit line under "files" in the copy plugin to copy usr/include
[12:43] <ogra_> should be easy to check with the installed snap what actually ends up in place
[12:46] <kyrofa> matiasb, I uploaded the new version of the owncloud snap (for armhf this time) which also needs the framework fix. Would you mind looking at that when you have a minute?
[12:47] <matiasb> kyrofa, sure, checking!
[12:48] <noizer> kyrofa if you need more testers i want to test it too if needed xD
[12:49] <kyrofa> noizer, hey, feel free! `sudo snappy install owncloud.kyrofa`
[12:50] <noizer> kyrofa I will test it tonight when i'm at home (Belgium hour)
[12:56] <kyrofa> sergiusens, what are your thoughts on dholbach's images?
[12:58] <kyrofa> noizer, since you don't really get much of a manual with the .snap, might be worth reading this: https://github.com/kyrofa/owncloud-snap/blob/master/README.md
[13:00] <mvip> didrocks1: Here you go: https://bugs.launchpad.net/snappy/+bug/1500755
[13:01] <noizer> kyrofa ok intresting
[13:01] <didrocks> ogra_: hey, do you mind looking at that one? ^ those guys have to roll out their own image due to this
[13:02] <ogra_> didrocks, as i'm saying since monday i'm actively working on it, yes
[13:02] <ogra_> should land later today
[13:02] <ogra_> patience ;)
[13:02] <didrocks> ogra_: oh, great! we didn't get any info from the bug report or didn't check IRC enough :)
[13:02] <mvip> ogra_ awesome. :)
[13:02] <mvip> ogra_ thanks man
[13:03] <ogra_> didrocks, well, i commented on the bug on friday ;)
[13:05] <didrocks> ogra_: a week ago! it's ages in our industry as asac would say! :p
[13:05] <sergiusens> kyrofa, your branch idea is good
[13:05] <didrocks> anyway, thanks for looking at it! :)
[13:05] <kyrofa> sergiusens, it leaves them under our control, anyway
[13:05] <kyrofa> sergiusens, dholbach another option is to upload them on the github wiki and link to them there
[13:06] <kyrofa> Then they wouldn't be pulled down in a clone
[13:07] <dholbach> hey alecu :-)
[13:07] <alecu> hey dholbach! :-)
[13:07] <dholbach> kyrofa: I'm happy either way
[13:07] <dholbach> kyrofa: I don't expect crazy amounts of images anytime soon :)
[13:08] <kyrofa> dholbach, ah, it doesn't actually look like you can upload images on the wiki, scratch that
[13:08] <dholbach> ok... images branch then? or link to rawgit?
[13:09] <kyrofa> dholbach, well, rawgit needs a branch anyway
[13:09] <dholbach> so they could live in the same branch and be part of the same commits, right?
[13:09] <kyrofa> dholbach, I'm not actually sure what it gives you-- am I missing something?
[13:10] <dholbach> kyrofa: I was just wondering if we would actually need a separate branch
[13:10] <kyrofa> dholbach, perhaps not. We could make an images folder within the docs folder
[13:10] <kyrofa> dholbach, perhaps that would indeed be easiest
[13:11] <kyrofa> dholbach, as long as you're not expecting tons and tons of images
[13:11] <dholbach> if we just put them in master or 1.x it should be clearer which commit they're part of, etc
[13:11] <dholbach> yeah, I don't expect that to happen :)
[13:11] <kyrofa> dholbach, yeah go for it
[13:11] <kyrofa> dholbach, just remember, when you change binary files (I'm assuming git will treat images as binary files) they'll conflict every time
[13:11] <dholbach> ok, I'll adapt my current PR and do another one to move the image on README.md
[13:12] <kyrofa> dholbach, if git ever tries to merge them, I mean
[13:13] <dholbach> ok
[13:13] <dholbach> I have no idea about that :-/
[13:13] <dholbach> is this something we need to workaround?
[13:14] <kyrofa> Nah, we can deal with it. We'll only hit it if multiple people try to change the image, etc.
[13:14] <kyrofa> But it's something to keep in mind if you get into that situation
[13:15] <dholbach> ok
[13:19] <dholbach> updated
[13:28] <kyrofa> dholbach, that markdown looks fishy. Have you verified that it works?
[13:30] <dholbach> on it
[13:30] <dholbach> sorry
[13:30] <kyrofa> dholbach, would you mind terribly if I asked you to change the URLs temporarily to your branch so we can see the end result?
[13:35] <dholbach> kyrofa: https://github.com/dholbach/snapcraft/blob/1541404/docs/mir-snaps.md
[13:36] <kyrofa> dholbach, hey, yeah, there we go
[13:38] <kyrofa> dholbach, I like the foot note style
[13:40] <dholbach> updated :)
[13:40] <kyrofa> dholbach, ah, so you are going with rawgit?
[13:40] <dholbach> hum... isn't that what we wanted :)
[13:41] <kyrofa> dholbach, well, that's a cache, right? If we upload it into master we can just use the githubusercontent URL, can't we?
[13:42] <kyrofa> dholbach, actually I suspect we can directly use images/image_name
[13:42] <kyrofa> dholbach, then it's branch-independent
[13:43] <dholbach> can we maybe go with githugusercontent for now? O:-) the markdown importer of developer.u.c hasn't learned how to import images and store them in swift storage yet :-)
[13:44] <kyrofa> dholbach, ah! Yeah I can see how that might be _slightly_ problematic
[13:44] <dholbach> it's planned, it's just not done yet
[13:44] <kyrofa> dholbach, tough feature
[13:45] <kyrofa> dholbach, so yeah, totally. Do you agree that using github directly instead of rawgit is better? Might be more reliable
[13:45] <dholbach> I'm happy to change rawgit.com to raw.githubusercontent.com - I haven't worked with github enough yet to be able to say anything about either of the two :)
[13:46] <kyrofa> dholbach, yeah let's do that.
[13:46] <dholbach> ok cool, done
[13:47] <sergiusens> kyrofa, btw https://github.com/ubuntu-core/snappy/pull/442
[13:48] <kyrofa> sergiusens, wait wait... what?
[13:48]  * kyrofa goes to read the manpage
[13:48] <sergiusens> kyrofa, just search for the second %h
[13:48] <sergiusens> kyrofa, at the end of the table
[13:48] <sergiusens> the second %h is at the end of the table
[13:50] <kyrofa> sergiusens, why has this ever worked?
[13:50] <sergiusens> kyrofa, how has it ever worked? I don't think it was ever used
[13:51] <kyrofa> sergiusens, I've used it in the path. The SNAP_USER_DATA path has always been buggy in services since that directory isn't created, but it was indeed previously valid
[13:52] <kyrofa> i.e. was replaced with /root
[13:52] <kyrofa> sergiusens, "so the specifiers only work as shortcuts for things which are already specified in a different way in the unit file"
[13:53] <kyrofa> sergiusens, I'm still not really up to speed on systemd, but after reading that maybe we had something defined elsewhere that was making this work
[13:54] <kyrofa> sergiusens, also, things like 'This is the home directory of the user running the service manager instance. In case of the system manager this resolves to "/root".' give me the impression that it should be hard-coded when running in system mode
[13:56] <sergiusens> kyrofa, right, that is the case for systemd user sessions
[13:56] <sergiusens> root may indeed be a user of such systemd session
[13:56] <sergiusens> this is the problem of root as a role and root as a user fwiw
[13:56] <sergiusens> brb
[13:57] <kyrofa> sergiusens, huh, yeah interesting. Thanks for the fix :)
[13:57] <ogra_> well, i guess we still export SUDO_USER into the env ... you could indeed mangle the path of SNAP_USER_DATA based on tht
[13:57] <ogra_> *that
[13:58] <ogra_> (in a wrapper script or so)
[13:59] <sergiusens> ogra_, no, SUDO_USER is not exported in a systemd unit from pid 1 ;-)
[13:59] <ogra_> ah
[14:29] <p1gmale0n> hi all @here
[14:31] <sergiusens> kyrofa, i need to reboot, will be there in a sec
[14:39] <kgunn> sergiusens: mornin' ....wondering if something else changed in 2.1 i didn't quite catch
[14:39] <kgunn> so i can build my snap just fine
[14:39] <kgunn> but on install attempt i get
[14:39] <kgunn> mir-server_0.19_amd64.snap failed to install: open /tmp/read-file291427386/unpack/meta/package.yaml: no such file or directory
[14:39] <kgunn> wondering if i need to rearrange my files?
[14:39] <kgunn> you can see what i'm pkging here
[14:39] <kgunn> http://bazaar.launchpad.net/~mir-team/+junk/mir-server-snapcraft2.1/files
[14:40] <noizer> I'm trying to install uwsgi but now i got following error. Somebody knows how to fix this?
[14:41] <noizer> error            :/home/ubuntu/software/stage/usr/include/wchar.h:395:47: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
[14:41] <florent-tengio> According to https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-packaging-ros-snaps/ , I need the plugin catkin but snapcraft saids that it doesn't exist. Do you know why?
[14:50] <matiasb> kyrofa, fyi, owncloud last upload should have been fixed a while ago; and also, we just deployed a fix so there is no manual intervention needed anymore for 15.04 uploads
[14:51] <kyrofa> matiasb, 8.2.2kyrofa6-armhf still has no frameworks my myapps, and I can't find it via snappy search
[14:51] <kyrofa> matiasb, but great news on the fix, thank you!
[14:52] <matiasb> kyrofa, hmm... let me re-check
[14:57] <sergiusens> kgunn, we kill package.yaml
[14:57] <sergiusens> kgunn, as ubuntu-core for devel has too; I sent an ANN email, have you seen it?
[14:58] <sergiusens> kgunn, https://lists.ubuntu.com/archives/snappy-app-devel/2016-February/000580.html
[14:58] <kyrofa> florent-tengio, hey there
[14:58] <matiasb> kyrofa, ok, there we go, fixed now; and future uploads should just work (TM)
[14:59] <kyrofa> matiasb, verified, thank you so much :)
[14:59] <matiasb> yw
[14:59] <kyrofa> florent-tengio, the catkin plugin should indeed exist in ever remotely recent version of snapcraft. Can you pastebin your YAML and the error you're seeing?
[15:00] <florent-tengio> hey kyrofa
[15:00] <sergiusens> florent-tengio, please don't PM general questions which can benefit the greater community ;-)
[15:01] <kgunn> sergiusens: you didn't look at my branch did you?
[15:01] <florent-tengio> ok sorry about that. Apparently I got a too old version of snapcraft
[15:01] <kgunn> i've a snapcraft yaml
[15:01] <kgunn> and documentation still seems to match
[15:01] <kyrofa> florent-tengio, what version are you on?
[15:01] <kgunn> https://developer.ubuntu.com/en/snappy/build-apps/
[15:01] <kgunn> unless i am missing something
[15:02] <florent-tengio> it is 0.3
[15:02] <kyrofa> kgunn, it's like you're running on an old image of ubuntu core
[15:02] <kyrofa> kgunn, one that's still expecting the package.yaml, but snapcraft isn't adding it in
[15:02] <kgunn> kyrofa: ah crap...
[15:02] <kgunn> i bet i pulled it the day of 2.1
[15:02] <kyrofa> florent-tengio, oh yeah.. update :)
[15:03] <kgunn> prolly just before
[15:03] <kyrofa> kgunn, yeah this week has kinda sucked as far as releasing features at the same time... *cough*
[15:03] <kgunn> sergiusens: kyrofa ....apologies, nvmd
[15:03] <kgunn> ;) kyrofa
[15:03] <kgunn> tell me brother
[15:04] <sergiusens> kgunn, not yet, havne't looked at it
[15:04] <kyrofa> florent-tengio, what version of ubuntu are you running?
[15:06] <kyrofa> kgunn, no need to apologize by the way. Sorry for the instability :)
[15:07] <florent-tengio> kyrofa it is solved now thanks
[15:08] <kyrofa> florent-tengio, excellent. Let us know if you need any more help!
[15:08] <joc_> florent-tengio: hi, you have newer snapcraft working now?
[15:09] <kyrofa> joc_, are you having troubles?
[15:10] <kgunn> kyrofa: so anyone using snapcraft 2.0 (not 2.1) will they really be able to run that anywhere? e.g. are we producing 16.04 core images somewhere...where people can "go back in time" ?
[15:10] <joc_> kyrofa: hi, no i was just chatting (in person) to florent, hoping he is sorted now :)
[15:11]  * kgunn just thinking about mir snap on 2.0 post...
[15:11] <florent-tengio> joc_ I have on the virtual machine but apparently it is full now... due to ros install
[15:11] <kgunn> prolly irrelevant today :)
[15:11] <qengho> I'm trying to test a new snap on my Ubuntu classic machine. I get an error at snap install that "sc-filtergen executable not found". Is there a Dependency I should fulfill manually? Is that a bug?
[15:15] <kyrofa> kgunn, no, rolling really just rolls on, you know?
[15:16] <kyrofa> kgunn, sort of the nature of the beast
[15:16] <kyrofa> kgunn, once it's actually released though, I doubt such disruptive changes will continue to be made
[15:16] <kyrofa> qengho, you're trying to install a .snap on a normal ubuntu desktop?
[15:17] <qengho> kyrofa: yes
[15:17] <kgunn> just feels weird, like snapcraft2.0 came out...then immediately (effectively) broke with 2.1
[15:18] <sergiusens> kgunn, it tries to catch up with the system; 2.0 snaps wouldn't work on the latest core anyways
[15:18] <kyrofa> qengho, that will made you sad
[15:18] <kyrofa> qengho, it's not supported right now
[15:18] <qengho> :(   <- sad
[15:18] <kyrofa> qengho, try installing Ubuntu Core in a virtual machine instead
[15:24] <kyrofa> sergiusens, just got voip working... seems the conference call is over? :(
[15:25] <sergiusens> kyrofa, yeah; just just now
[15:25] <kyrofa> kgunn, yeah, it's a bit of a moving target right now
[15:25] <sergiusens> kyrofa, at least you have it working now ;-)
[15:25] <kyrofa> sergiusens, thanks for the info. Pretty slick, actually
[15:25] <sergiusens> kyrofa, well now you can call me over sip :-P
[15:26] <kyrofa> sergiusens, what, and miss seeing your face?
[15:26] <sergiusens> lol
[15:31] <plars> ogra_: what's the current status of dragonboard images? Should I be using yours? mvo's newer one that's currently in obsolete/old? :)
[15:31] <plars> ogra_: with both of them, I can only seem to get it to boot one time, then after that it will only boot to emmc
[15:32] <Guest7789> sergiusens I am having an ither isssue with catkin plugin CMake Error: your C compiler: "/home/florent/falcon/snapp/parts/foo/install/usr/bin/gcc" was not found
[15:32] <kyrofa> beuno, I've made several uploads since you introduces the multi-arch support. Other than requiring separate versions, it works exactly the way I would expect. Great job :)
[15:33] <beuno> kyrofa, woooo
[15:33] <beuno> matiasb, ^
[15:34] <elopio> kyrofa: can you tell me the variables to set to connect to staging?
[15:34] <elopio> ah, nevermind. Found it in HACKING. I was looking in docs.
[15:35] <kyrofa> sergiusens, add gcc to your build-packages
[15:35] <kyrofa> Oops. I meant florent_tengio ^^
[15:35] <matiasb> beuno, kyrofa, fyi, with the latest rollout (from a few minutes ago), you should be able to reuse version numbers for diff archs :)
[15:35] <sergiusens> kyrofa, me? florent_tengio ^
[15:35] <kyrofa> matiasb, oh that was rolled out too? Awesome!
[15:36]  * sergiusens goes for a quick bite
[15:39] <florent_tengio> kyrofa How to you do that?
[15:39] <kyrofa> florent_tengio, which version of snapcraft are you on now, then?
[15:40] <ogra_> plars, works fine for me with both, mvo's latest only has half a kernel, so no wifi
[15:40] <florent_tengio> kyrofa 1.0.1
[15:41] <plars> ogra_: oh... is there some reason you can think of that it would only boot once to snappy? I have the switch set to sd boot, obviously since it does boot once. But after that, it only boots what's on the emmc, regardless of whether I soft-reboot, or pull the power cord and hard reboot
[15:41] <ogra_> plars, sounds liek your bootloader gets messed up somehow on the SD
[15:42] <noizer> Hi, I want to install uwsgi with pip. when im doing that on the classic one. it works fine for me but when im trying to install it on snappy i got always the same error. (my snapcraft is 2.1)  http://pastebin.com/bqhNGgrs
[15:43] <plars> ogra_: it happens every time for me, on both images
[15:43] <plars> ogra_: I don't even do anything while I'm booted, just test that it boots
[15:43] <ogra_> plars, right, the only thing i can imagine is that the bootloader gets messed up
[15:43] <ogra_> oh
[15:43] <kyrofa> florent_tengio, https://github.com/ubuntu-core/snapcraft/blob/1.x/docs/snapcraft-syntax.md
[15:43] <ogra_> thats a 4G card, nothing bigger,. like described in the README, right ?
[15:44] <kyrofa> noizer, have you successfully build this standalone?
[15:44] <ogra_> (bigger cards will get messed up, thus the warning to only use 4G)
[15:44] <plars> ogra_: hmm.. actually it might be bigger. I need to double check.  So it could be a resize problem?
[15:44] <plars> ogra_: I'll check that, I bet that's it. Thanks!
[15:44] <ogra_> yes, the resize function needs to be ported to sgdisk
[15:44] <plars> I *think* I still have a 4G card around here somewhere, may have to do some digging
[15:44] <kyrofa> noizer, it looks like the build system is setup to treat warnings as errors
[15:44] <noizer> only a snap with just uwsgi on? No I did not tried that before
[15:44] <ogra_> (and probably also get a cmdline option we can set to disable it)
[15:45] <kyrofa> noizer, no, I mean just by itself, without snappy or snapcraft at all
[15:45] <kyrofa> noizer, these are compile errors-- they have nothing to do with snapcraft
[15:45] <noizer> yes then it works well
[15:46] <noizer> when you try pip install uwsgi
[15:46] <noizer> then it works great
[15:46] <kyrofa> noizer, can you paste your YAML as well?
[15:47] <noizer> kyrofa yes offcourse
[15:47] <kyrofa> noizer, and you'r encountering this in the classic dimension, or on regular xenial?
[15:48] <noizer> pip install on the classic dimension there works it fine. but when i try to snap it then it gave me this crash
[15:49] <kyrofa> noizer, and you're running snapcraft on the classic dimension?
[15:49] <noizer> http://pastebin.com/FYYEDRk7
[15:49] <noizer> yes
[15:49] <kyrofa> noizer, in the future, http://pastebin.ubuntu.com/ is a little less add-heavy
[15:50] <noizer> oooh ok sorry kyrofa
[15:50] <kyrofa> noizer, no apologies necessary! Just wanted you to know :)
[15:50] <noizer> :p
[15:56] <kyrofa> noizer, alright let me give this a shot
[15:56] <kyrofa> florent_tengio, did you get that working?
[15:57] <florent_tengio> kyrofa no
[15:58] <kyrofa> florent_tengio, have you tried the build-packages?
[15:58] <florent_tengio> kyrofa yes I have added build-packages: - gcc
[15:58] <florent_tengio> with the correct indentation
[15:59] <kyrofa> florent_tengio, and you get the same error?
[16:00] <florent_tengio> kyrofa yes
[16:01] <kyrofa> florent_tengio, oh, looking at your error message again, try adding it to stage-packages instead
[16:05] <elopio> pindonga: do you know if there's a way to test getpass with subprocess?
[16:05] <elopio> I see there's the pexepect module, but I wouldn't like to add it if there's another way.
[16:21] <pindonga> elopio, no idea... but I don't see why not, as long as stdin/stdout are properly captured by the subprocess
[16:21] <elopio> pindonga: no, getpass does something different. I can capture the email prompt, but not that one.
[16:23] <elopio> I think I could tell get pass to use stdout, not the tty, but that doesn't sound to good. Or get a test tty, but I guess that's what pexpect does for me.
[16:23] <elopio> I'm trying...
[16:23] <ogra_> ... therefore i am
[16:24] <elopio> I'm test therefore I am.
[16:24] <ogra_> :D
[16:32] <qengho> Hi again. Help? How do I get the Snappy Dimension on Classic installed and working?
[16:32] <ogra_> sudo snappy enable-classic
[16:32] <ogra_> snappy shell classic
[16:34] <qengho> Oh man. That's good. Though, the man page and help has all sorts of things that should never be known to a user like "booted" and "grub-migrate", and that's not mentioned.
[16:35] <ogra_> if you just run "snappy" without any options it tells you about it though :)
[16:35] <qengho> Ah, maybe it's my version of snappy. No option.
[16:35] <ogra_> well, thats 16.04
[16:35] <ogra_> 15.04 didnt have classic iirc
[16:37]  * ogra_ curses
[16:38] <qengho> ogra_: 0.3.7-1.1? What does your "apt-cache policy snappy" say?
[16:38] <Sweet5hark> so ...
[16:38] <ogra_> qengho, there is no apt on snappy
[16:39] <ogra_> qengho, you are not trying to use classic on a desktop, do you ?
[16:41] <Sweet5hark> I have build LibreOffice with debug symbols, threw strace and gdb into the snap for fun, sneaked in an additional disc mounted on /apps to have enough space and then looked at what LibreOffice does.
[16:41] <qengho> ogra_: oh, yes. I thought that was it was for. Maybe I have it inside-out.
[16:42] <ogra_> qengho, classic is a container that sits on top of the readonly rootfs, adding a writable overlay and re-adding the missing apt bits to make it behave like a "normal" ubuntu
[16:42] <Sweet5hark> (with LD_LIBRARY_PATH set and under strace that is)
[16:43] <ogra_> so it enables you to use apt in a container (with bind mounts into the relevant dirs ... i.e. ~/ is shared)
[16:43] <qengho> ogra_: Ah, yeah, I thought it was backwards. Snappy inside a container running on old-timey Ubuntu.
[16:43] <ogra_> yeah, thats different
[16:43] <ogra_> isnt that called purtine ?
[16:44] <ogra_> (ask bregma, i think his team works on that stuff)
[16:44] <bregma> Libertine
[16:44] <ogra_> ah, that uses snappy ?
[16:44] <bregma> not yet
[16:44] <Sweet5hark> turns out it hangs with EAGAIN on trying to read/dlopen a libdesktop_detectorlo.so. at least ldd says it finds all libs. any hint what might wrong?
[16:45] <ogra_> i thought that was just a wrapper for apt packagews
[16:49] <Chipaca> Sweet5hark, 'audit' logs do you get?
[16:49] <qengho> ogra_: thank you for explaining. I have a snap that hope will display to X. Does "Snappy Dimension on Classic" provide X?
[16:50] <ogra_> qengho, no, i doubt you will ever see native Xorg support in snappy ... XMir is the way to go
[16:50] <elopio> pitti: is there a way to pass secrets to the autopkgtests ?
[16:51] <elopio> I have a test that requires a password. I can run it on travis, but I think I'll have to skip it in autopkg.
[16:53] <dholbach> all right my friends - I call it a day - have a great weekend! :-)
[16:53] <elopio> bye dholbach
[16:55] <ogra_> ppisati, hulp !
[16:56] <ppisati> ogra_: ???
[16:57] <ogra_> ppisati, i cant load any dtb from 0x100 on the rpi with the new bootloader firmware tree
[16:57] <ogra_> do you know where it moved to ?
[16:57] <ogra_> (fdt addr 0x100 throws a "bad magic" error)
[16:58] <ppisati> ogra_: what's your version? because i update the fw in Jan and it was ok
[16:58] <ogra_> ppisati, i'm on the "next" branch
[16:58] <ppisati> ogra_: oh, then you are into the future :)
[16:58] <ppisati> ogra_: sorry, don't know
[16:58] <ogra_> (default for the 4.4 kernel)
[16:59] <ppisati> ogra_: dump the memory from uboot until you find something resembling it
[16:59] <ppisati> ogra_: that's what i did
[17:00] <ogra_> ppisati, well ... bug 1500755
[17:00] <ogra_> apparently someone has it working by just replacing start.elf and fixup.dat
[17:00] <ppisati> ogra_: hold on
[17:01] <ogra_> (though it might already work in "master" (vs next) ... i see there were some recent changes to their dtb)
[17:01] <ppisati> ogra_: try if this helps
[17:01] <ppisati> ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/raspberrypi2-firmware_4.1.15-b70b451-1_armhf.deb
[17:01]  * ogra_ tries
[17:01] <ppisati> ogra_: i don't have my raspi2 hooked up
[17:02] <elopio> sergiusens: kyrofa: no planning today?
[17:02] <kyrofa> elopio, yeah sorry, baby hugs
[17:05] <code1o6> Hello guys, is there a way to add a login screen to webdm?
[17:05] <ogra_> ppisati, at least no bad magic error
[17:06] <ogra_> but ... [   12.665908] unexpected IRQ trap at vector 00
[17:06] <ogra_> (during initrd)
[17:06] <ppisati> ogra_: panic?
[17:07] <ogra_> nope, just this message in a loop
[17:07] <ppisati> ogra_: ah
[17:07] <ogra_> let me try with a newer dtb
[17:07] <ppisati> ogra_: i'm using it with the 4.3 kernel (and people reported success with 4.4 too)
[17:07] <ogra_> ppisati, well, the bug is specifically about missing device support
[17:08] <ppisati> ogra_: actually, i got the camera working fine in 4.3 + that firmware
[17:09] <ppisati> ogra_: even 4.2 actually
[17:09] <ogra_> via /dev/vchiq ?
[17:09] <ppisati> ogra_: i used raspistill
[17:09] <ogra_> (seems to be a node for some "hat" board)
[17:10] <ppisati> ogra_: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1532217
[17:11] <ogra_> yeah, doesnt use that device node
[17:12] <ppisati> ogra_: i don't know, my raspi2 is not hooked ATM
[17:12] <ppisati> ogra_: if you want we can debug this further
[17:12] <ogra_> we surely have to if i dont get it to work :)
[17:12] <ppisati> ogra_: k, i'm about to beer'o time
[17:13] <ppisati> ogra_: ping me first thing monday and we can have some fun
[17:13] <ogra_> yeah, i'll try my luck over the weekend, if i cant get it going i'll sit on your lap on monday
[17:13] <ppisati> ogra_: ack
[17:13] <ogra_> enjoy the beer and thanks for the help :)
[17:14] <ogra_> (btw, the error is gone using the latest dtb file)
[17:14] <ppisati> ogra_: updating the dtb ususally helps :)
[17:15] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls -l /dev/vchiq
[17:15] <ogra_> crw------- 1 root root 245, 0 Feb  5 17:13 /dev/vchiq
[17:15] <ogra_> \o/
[17:47] <sergiusens> elopio, oh my, I completely missed the time it is
[17:47] <sergiusens> elopio, so sorry
[17:48] <kyrofa> sergiusens, that's alright, this one wasn't huge since we're not releasing on cadence next time around
[18:16] <didrocks> kgunn: hey, I think you know more on that area than I, do you mind answering this: http://askubuntu.com/questions/729540/can-i-run-any-other-display-server-on-ubuntu-core-except-for-mir?
[18:16] <didrocks> sergiusens: kyrofa: I would be interested (personally) if you can give an answer on http://askubuntu.com/questions/729762/snapcraft-make-plugin-change-directory :)
[18:17] <kyrofa> didrocks, ah, thank you! I don't have the snapcraft tag setup
[18:18] <didrocks> kyrofa: one more to add to get more badges! :-)
[18:20] <kyrofa> didrocks, and yes, answering now
[18:24] <sergiusens> kyrofa, ok, I'll +1 if it is good enough ;-)
[18:29] <ogra_> elopio, so there is a new pi2 oem snap for 15.04 in the store ... would be nice if that could get some testing on 15.04/edge so we are sure i didnt regress anything before next 15.04 release
[18:30] <ogra_> didrocks, ^^ thats your fix for the vhciq device stuff btw
[18:30] <elopio> ogra_: sure, I was planning to do the testing this evening.
[18:30] <ogra_> cool
[18:30] <elopio> ogra_: can you move it to alpha? That makes things easier.
[18:31] <ogra_> elopio, it will be used on all 15.04 builds now (thats the oem snap u-d-f pulls from the store at image creation time)
[18:32] <ogra_> (this includes alpha as well as edge and stable)
[18:33] <elopio> got it.
[18:33] <kyrofa> sergiusens, didrocks how's that?
[19:24] <didrocks> kyrofa: perfect! :)
[19:24] <didrocks> kgunn: thanks as well
[19:24] <didrocks> ogra_: wooooo
[19:27] <xnox> ogra_, who shall i assign bug about unity-scope-snappy?
[19:27] <xnox> ogra_, can i like drop the package from the archive?
[19:27] <ogra_> xnox, no idea, never heard of it
[19:27] <kyrofa> xnox, ask alecu about that
[19:28] <ogra_> is that the store scope ?
[19:28] <kyrofa> xnox, what's the problem with it? ogra_ yeah
[19:29] <xnox> kyrofa, alecu, hi! unity-scope-snappy FTBFS in xenial, because of golang-go 1.6 (cgo argument has Go pointer to Go pointer), which has become invalid Go. And it has invalid Built-Suing metadata. It says "Built-Using: golang-go.tools (= )" there must be a version after '='
[19:29] <xnox> kyrofa, alecu: and there are test suite failures.
[19:29] <xnox> somehow i think it does not work at all with current snappy.
[19:30] <xnox> bug #1542376
[19:30] <xnox> bug #1534346
[19:30] <xnox> who shall I assign these bugs to?
[19:31] <kyrofa> xnox, yeah it's a bit old nowadays. I would suspect it's okay to drop given the prioritization of Ubuntu Personal, but yeah I'd hear from alecu and maybe kgunn about it first
[19:33] <xnox> kyrofa, $ seeded-in-ubuntu unity-scope-snappy
[19:33] <xnox> unity-scope-snappy's binaries are not seeded.
[19:33] <xnox> ..
[19:33] <xnox> i don't think it's in use.
[19:33] <kyrofa> xnox, yeah it was only ever seeded in personal
[19:33] <olli> ogra_, late night Fri ping
[19:33] <alecu> xnox: yes, I think it's fine to drop it, since it was coded against an old version of the snappy rest interfaces
[19:33] <ogra_> olli, whats up ?
[19:33] <olli> ogra_, mind checking 1 mail for me pls?
[19:33] <alecu> and we are not updating it for now.
[19:34] <olli> sorry about the late ping
[19:34] <xnox> alecu, kyrofa - let me file an RM bug, and please comment on it. One moment.
[19:34] <sergiusens> elopio, kyrofa http://paste.ubuntu.com/14894403/
[19:34] <elopio> sergiusens: :o
[19:34] <sergiusens> xnox, Built-Using is generally auto added by dh-golang
[19:35] <kyrofa> sergiusens, niiice
[19:36] <xnox> sergiusens, sure. but in this case it's borked up. and it's impossible for me to rebuild to see if a rebuild would fix the built using =/
[19:36] <xnox> sergiusens, and this trips up germinate.
[19:36] <xnox> kyrofa, alecu - please comment your approval on https://bugs.launchpad.net/ubuntu/+source/unity-scope-snappy/+bug/1542451
[19:36] <xnox> approval to remove the package.
[19:37] <sergiusens> xnox, k, I'm just saying that maybe other packages have broken Built-Using's ;-)
[19:37] <xnox> sergiusens, =) true. So far this is the only one like that, that i found.
[19:38] <xnox> well, tripped on.
[19:40] <genii> BTW, may want to increment the copyright year to 2016 soon. I just built from git and still says 2015
[20:08] <sergiusens> genii, only for files we changed in 2016 or where is this coming from?
[20:09] <sergiusens> kyrofa, elopio if you are feeling it https://github.com/ubuntu-core/snapcraft/compare/master...sergiusens:feature/1480144/cleanbuild-lxd
[20:09] <sergiusens> you can start looking ;-)
[20:09] <genii> sergiusens: Sorry, that was for #quassel
[20:11] <elopio> sergiusens: s/2015/2016
[20:11] <sergiusens> elopio, yeah, done already ;-)
[20:11] <sergiusens> some had some didn't :-p
[20:16] <elopio> sergiusens: what's the most simple valid snapcraft.yaml that generages a valid snap?
[20:20] <sergiusens> elopio, I think it is the webchat one or gopaste
[20:20] <elopio> sergiusens: can't we cut it even further?
[20:21] <sergiusens> elopio, something with the copy plugin maybe
[20:34] <tyhicks> has anyone gotten the latest all-snaps rpi2 image to work?
[20:34] <tyhicks> the bbb image works for me but not rpi2
[20:35] <elopio> tyhicks: let me flash and try.
[20:35] <tyhicks> elopio: thanks - I get 7 blinks of the ACT led
[20:36] <elopio> tyhicks: do you have at hand the name of the kernel and gadget?
[20:36] <tyhicks> elopio: I don't
[20:36] <tyhicks> elopio: I was trying these images: https://people.canonical.com/~mvo/all-snaps
[20:39] <elopio> I wanted to generate it with that u-d-f. but I'll just download it.
[20:54] <elopio> pindonga: https://bugs.launchpad.net/snapcraft/+bug/1542476
[20:54] <pindonga> elopio, right
[20:54] <pindonga> not sure if I mentioned it in the docs or not
[20:54] <pindonga> but it's a requirement
[20:56] <elopio> pindonga: sure, that's clear. We need a better message for when the user doesn't meet the requirement, but I'm not sure what's feasible to ask.
[20:56] <elopio> tyhicks: works for me: https://paste.ubuntu.com/14895861/
[20:57] <pindonga> I think we should start by showing a link and asking them to login via the web ui
[20:57] <pindonga> and sign it there
[20:57] <pindonga> that's the minimum we can do
[20:58] <tyhicks> elopio: ok, thanks for testing - I'll keep trying to hunt down the issue on my end
[20:58] <elopio> tyhicks: do you have a serial cable?
[20:58] <elopio> well, THE serial cable.
[20:58] <tyhicks> elopio: no :/
[20:59] <elopio> tyhicks: https://www.adafruit.com/products/954
[20:59] <tyhicks> ah, nice
[20:59] <tyhicks> that would be helpful
[21:00] <tyhicks> elopio: do you know if this applies to the rpi2? http://elinux.org/R-Pi_Troubleshooting#Green_LED_blinks_in_a_specific_pattern
[21:03] <elopio> tyhicks: I don't know. I know that it wasn't working as expected on the bbb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1510165
[21:03] <elopio> so I wouldn't trust it too much.
[21:04] <tyhicks> elopio: ok
[21:05] <elopio> pindonga: why is my uploaded snap saying this in the store? (NEEDS REVIEW) squashfs pkg lint_is_squashfs
[21:06] <pindonga> elopio, squashfs based snaps don't get automatically approved yet
[21:06] <elopio> pindonga: oh, sad, I can't finish my test. Can't we have autoapprove at least for staging, like today? :)
[21:06] <pindonga> so they're flagged for manual review
[21:06] <pindonga> elopio, nopes
[21:07] <pindonga> like, I'm literally EODing right now :)
[21:07] <elopio> pindonga: oh well, then lunch time for me :D let's talk on monday.
[21:07] <pindonga> elopio, afaiui it's still missing some pieces in click-reviewers-tools
[21:07] <elopio> thank you, and enjoy the evening.
[21:07] <pindonga> so not something we control in the store
[21:08] <pindonga> elopio, as soon as the proper supports lands in click-reviewers-tools we can pull it and get the store to auto-approve those snaps
[21:08] <pindonga> anyway... bye!
[21:08] <pindonga> see you on monday
[21:09] <elopio> ack. There will be a test eagerly waiting for that day.
[21:09] <elopio> beuno: just so you put it higher in the queue, for me ;) ^
[21:24] <sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/303
[21:25] <sergiusens> kyrofa, too ^
[21:26] <elopio> sergiusens: how does this work with two spaces? --output  SNAP
[21:26] <elopio> I thought I read on docopt that the two spaces were for the help
[21:26] <sergiusens> elopio, I don't know, but it does
[21:26] <sergiusens> elopio, I'm fixing it anyways
[21:27] <elopio> sergiusens: maybe an integration test with --output, just to be extra safe
[21:27] <sergiusens> elopio, sure
[21:30] <sergiusens> elopio, ah, can't do subtests
[21:30] <sergiusens> AttributeError: 'NoneType' object has no attribute 'result_supports_subtests'
[21:33] <sergiusens> elopio, done
[21:33] <elopio> sergiusens: interesting. I thought testtools would just support that. Maybe it's an outdated version.
[21:33] <elopio> sergiusens: you can do testscenarios.
[21:33] <sergiusens> elopio, I split it in two tests for now
[21:34] <elopio> but the duplication is not much. Do it as you wish.
[21:34] <sergiusens> elopio, testscenarios are so confusing if you don't know the semantics though
[21:34] <elopio> sergiusens: I think you are right. I'm slowly liking subtests.
[21:34] <sergiusens> I used to use it, but I it's one of those things that is not straightforward
[21:35] <sergiusens> elopio, look at pylxd, it has an interesting scenario based testing using annotations which look super straightforward
[21:36] <elopio> with annotations if I put two, I never get the order right.
[21:36] <elopio> I'll kae a look.
[21:36] <sergiusens> elopio, so I need a release with this before I can move on with cleanbuild
[21:36] <sergiusens> elopio, right that is the problem when using @
[21:36] <sergiusens> :-)
[22:04] <elopio> woa, it's late.
[22:04] <elopio> <- lunch
[23:16] <sergiusens> elopio, I think it is this or to not enable mvn testing for adt https://github.com/ubuntu-core/snapcraft/pull/305