[00:02] <vir17> does snapcraft create snappy apps for armhf architecture?
[05:35] <elimisteve> ERROR: 'my-scope' is not a directory
[05:35] <elimisteve> I'm getting ^that^ error when running 'snap build .'
[05:35] <elimisteve> Any idea what that means? I have many things called 'my-scope' so it's hard to know where to look
[05:36] <elimisteve> Excuse me, 'click build .' is the command that gave me that error
[05:46] <elimisteve> Think I solved it. Asked here: http://askubuntu.com/questions/726536/error-building-click-package-with-click-build-is-not-a-directory
[06:38] <elimisteve> Solved it and posted the answer here: http://askubuntu.com/a/726543/125596
[08:04] <fgimenez> good morning
[10:00] <JamesTait> Good morning all!  Happy Thursday, and happy Data Privacy Day! 😃
[10:02] <vir17> with snapcraft can I create snappy apps for armhf devices/
[10:02] <vir17> ?
[10:22] <mvo> JamesTait: good morning! how it the snap.yaml stuff going .) ?
[10:36] <JamesTait> mvo, good morning! Almost there, I think, although it looks like the solution won't be quite as clean as I'd like (just due to the way the current code is structured).
[10:37] <JamesTait> I'm just writing up a quick follow-up to my earlier mail and will add a couple of details to the Trello card for completeness and transparency.
[10:39] <JamesTait> I'll propose a first cut to unblock you guys, and then see about cleaning it up.
[10:42] <vir17> hi all, I need some help to create a snappy app for raspberry pi 2
[10:42] <mvo> JamesTait: \o/
[10:43] <vir17> i have a simple app written in python and when i use snapcraft it creates this output: test_0.1_amd64.snap
[10:44] <vir17> how instead of an amd64 I can produce a armhf
[10:44] <vir17> ?
[10:46] <JamesTait> mvo, actually, I just realised - when you said "we need to support snappy 1.0 until 15.04 EOL", did you mean 15.10?  Because 15.04 EOL is next week.
[10:46] <mvo> JamesTait: snappy has a bit more EOL
[10:47] <mvo> JamesTait: until snappy 16.04 is there
[10:47] <JamesTait> Ah, OK.  That makes more sense. ☺
[10:47]  * JamesTait tries to keep up.
[10:50] <mvo> vir17: if its pure python you can set the the yaml to: architectures: [all]
[10:51] <vir17> thank you mvo  i will try it
[10:59] <Sweet5hark> Hi guys, sorry had to run yesterday. Installed the all-snaps image in the meantime, but cant find any starce in there too. Any hints?
[11:09] <mvo> Sweet5hark: the best I can offer right now is to scp it in, we want htis to be part of the snappy-debug snap but its not quite there yet
[11:11] <Sweet5hark> mvo: k
[11:11] <Sweet5hark> mvo: thx
[11:21] <diwic> how can I use "snappy try"? I'm on 16.04 so there's nothing in the snappy-dev/tools ppa
[11:22] <diwic> and "snappy try" just responds "did you mean activate?"
[11:32] <mvo> diwic: snappy try is not implemented yet, as a workaround you can just install it
[11:34] <diwic> mvo, sorry if this is a newbie question, but how do I install a snap that's not in the store yet?
[11:35] <diwic> (I just made the snap myself, and it's not ready for the store yet)
[11:42] <vir17> and another newbie/stupid question from me, how do I run an application that I have install
[11:43] <mvo> diwic: if you build it with snapcraft you should have a snap file, just scp it to the snappy system (or use snappy-remote) and then you can install it via "sudo snappy install ./path/to/snap.snap"
[11:44] <mvo> vir17: it will generate a command with "snapname.binaryname", check /snaps/bin to see if its there. note that the metadata in meta/package.yaml must be there, i.e. you need to declare what binaries the snap has (or services)
[11:44]  * mvo is away for some minutes
[11:50] <diwic> mvo, snappy-remote seems not available for xenial, so I'm going to try the scp approach. thanks
[12:17] <asac> mvo: lool: ok, so do we need a chat to decide what we do on kernel snap now?
[12:18] <ogra_> asac, ah, that reminds me ... regarding the snapcraft.yaml you showed me yesterday ... how do you make sure the minimal requirements if the kernel config are fulfilled (apparmor, various cgroups and namespace settings etc)
[12:19] <ogra_> do you have some config checker script ?
[12:22] <asac> ogra_: no, but we have default configs later thaht you have to explicitely disable...for now its raw DIY :) ...
[12:23] <ogra_> well, then you need at least a fat README that lists the required options ;)
[12:23] <asac> think we would need default config options that are hard to disable + some patch checker or something to ensure all the right apparmor patches are in
[12:23] <asac> yeah for sure
[12:23] <ogra_> the kernel pacfkage has all this already
[12:23] <asac> think thats polishing
[12:23] <ogra_> i wonder if you could just steal it from there
[12:23] <ogra_> well
[12:23] <ogra_> creating a unusable kernel isnt fun
[12:24] <asac> if you have pointers for the patch checking that would be cool
[12:24] <ogra_> (missing apparmor patches and such cause snaps to become non-executable)
[12:27] <asac> do you have the list handy? otherwise i am sure i will hit this convenience problem when we get to point where we want to boot it :)
[12:27] <ogra_> asac, well, i only know the config file used for the config enforcer, probably ppisati can point to the right person to talk about the code
[12:27] <asac> where is the config enforcer? is that a snappy specific one?
[12:27] <ogra_> it usually lives in linux-source-$ver/debian.$subarch/config/annotations
[12:28] <ogra_> (in the source package ... not sure where in git)
[12:28] <asac> the linux-lts-vivid-3.19.0$ find debian/ | grep annotat
[12:28] <asac> doesnt have that
[12:28] <asac> will check a xenial one i guess
[12:29] <ogra_> might be arm specific, not sure
[12:29] <ogra_> its a loooong time i have built an x86 kernel :P
[12:31] <ogra_> asac, i think in x86 kernels it is in debian.master/config/annotations
[12:32] <vir17> when I run in a raspberry pi with ubuntu snappy "sudo snappy install" I have this error:  Signature verification failed: No signatures, or no origin signature. (exit code 10)
[12:32] <kyrofa> Good morning
[12:33] <vir17> anyone has a clue why this is happening?
[12:37] <ogra_> vir17, are you properly on the network ?
[12:38] <kyrofa> vir17, are you sideloading an app, or installing from the store?
[12:39] <vir17> sideloading
[12:39] <vir17> and i try both ssh and using a keyboard in the raspberry pi itself
[12:39] <vir17> and I have the same error
[12:40] <vir17> i can only install it with snappy remote
[12:40] <vir17> but then there is nothing in the bin file
[12:40] <vir17> to run the app
[12:40] <kyrofa> vir17, are you using --allow-unauthenticated?
[12:40] <vir17> no
[12:41] <vir17> kyrofa: so it is: sudo snappy install [snappy app] --allow-unauthenticated  ?
[12:42]  * ogra_ always puts it after "install" 
[12:43] <kyrofa> vir17, indeed
[12:43] <ogra_> no idea if adding at the end works too :)
[12:43] <kyrofa> ogra_, heh, it does
[12:43] <ogra_> clever go parser ;)
[12:43] <diwic> hi, is rpath encouraged/discouraged in snap executables?
[12:43] <kyrofa> diwic, indeed
[12:43] <diwic> which one of them?
[12:43] <kyrofa> diwic, since depending on the type it takes precedence over LD_LIBRARY_PATH
[12:44] <kyrofa> diwic, dt
[12:44] <diwic> I currently have a binary in /snap/pulseaudio.sideload/weirdcombinationofcharacters/bin and some libraries in /snap/pulseaudio.sideload/weirdcombinationofcharacters/lib
[12:45] <diwic> how is the binary supposed to find its needed libraries?
[12:45] <kyrofa> vir17, so here's the issue you ran into. Snappy checks the signature of all packages it installs to ensure it comes from a valid source. When you upload a package to the store it gets signed by the store, so Snappy verifies that signature. If however you're sideloading it, then it hasn't been signed at all. Make sense?
[12:45] <kyrofa> diwic, when your snap is actually generated, the binary gets a wrapper generated for it
[12:46] <kyrofa> diwic, within that wrapper, many lib directories are added to LD_LIBRARY_PATH. If you're using a non-standard one you may need to write a wrapper script for your binary
[12:46] <vir17> kyrofa: yes it makes sense thank you
[12:47] <kyrofa> diwic, trace through the process starting at the /apps/bin/<package name>.<binary name> script that was generated. You'll see what I'm talking about
[12:47] <kyrofa> diwic, er... /snaps/bin on your version, sorry
[12:49] <vir17> kyrofa:  another question, i cannot find it in apps/bin
[12:49] <diwic> kyrofa, /snaps/bin is empty
[12:49] <vir17> i suppose something is wrong with my yaml file isnt it
[12:49] <kyrofa> diwic, did you declare your binary in the YAML?
[12:50] <kyrofa> Ha, vir17 to you as well
[12:50] <diwic> kyrofa, thanks, probably not, will check that next
[12:52] <kyrofa> sergiusens, got some network issues there?
[12:56] <sergiusens> kyrofa, no, I just connected to a VPN for a sec
[12:56] <kyrofa> sergiusens, oh
[12:56] <sergiusens> kyrofa, another draw back when using irc :-P
[12:56] <vir17> kyrofa: no i am not 100% sure how I do this, i will try and come back
[12:57] <sergiusens> kyrofa, can you review #270?
[12:57] <kyrofa> vir17, check out some of the examples in snapcraft: https://github.com/ubuntu-core/snapcraft/tree/1.x/examples
[12:57] <vir17> thank you :)
[12:58] <kyrofa> sergiusens, yeah, just catching up on emails real quick
[12:58] <kyrofa> vir17, any time!
[12:59] <kyrofa> diwic, by the way, regarding the rpath, I meant DT_RPATH
[13:00] <kyrofa> diwic, DT_RUNPATH would probably be fine
[13:00] <diwic> ok
[13:01] <kyrofa> diwic, and you can use DT_RPATH, just remember that it will override anything snappy tries to do for you, so you'd better get it right :P (this comes from experience)
[13:01] <diwic> I found an RPATH entry inside the executable, will try to remove it
[13:01] <kyrofa> diwic, what build system?
[13:02] <diwic> autotools
[13:03] <kyrofa> diwic, I _think_ --disable-rpath is standard there
[13:04] <diwic> kyrofa, if I'm supposed to set a correct rpath, I need to know the correct path, right? I e, how would I figure out the final installation directory ( /snaps/pulseaudio.sideload/weirdcombinationofcharacters ) ?
[13:04] <kyrofa> diwic, exactly
[13:05] <kyrofa> diwic, you'd have to use $ORIGIN I suppose
[13:05] <kyrofa> diwic, i.e. relative paths
[13:10] <kyrofa> diwic, but try using --disable-rpath first and add the binary to the YAML. See if that fixes things
[13:17] <diwic> kyrofa, ok, so now I got a wrapper (or actually two wrappers). Now to figure out why --disable-rpath actually didn't disable any rpath. Thanks so far!
[13:17] <sergiusens> kyrofa, diwic during SCaLE with didrocks we found out that setting --prefix= (to nothing) libtool or some other tool enables RPATH
[13:17] <sergiusens> diwic, try setting --prefix to something (reasonable)
[13:18] <kyrofa> diwic, ah, too bad
[13:18] <diwic> sergiusens, aha, interesting, what is something reasonable?
[13:18] <sergiusens> diwic, --prefix=/ or --prefix=/usr
[13:19] <kyrofa> diwic, just remember that the prefix will actually affect the placement within the .snap
[13:19] <sergiusens> this can fail depending on the m4 macro's smarts though (from what I recall mterry mentioning)
[13:21] <kyrofa> sergiusens, question for you regarding that. For instance, when building apache it takes its prefix and actually writes it all over the place-- shell scripts, config files, you name it. What I ended up doing is choosing a prefix of essentially REPLACEME and then as part of the build replaced all that stuff with the snappy environment variables
[13:21] <kyrofa> sergiusens, that's nasty. How would you have tackled that?
[13:22] <kyrofa> sergiusens, rather, I did the search/replace after install
[13:25] <kyrofa> mvo, just got your email to the list. Is that stuff in rolling, or all snaps? I'm starting to get confused with our options here :P
[13:25] <mvo> kyrofa: its on all snaps with the next update, just literally landed ~5min ago
[13:26] <mvo> kyrofa: I'm preparing updates as we speak
[13:26] <kyrofa> mvo, alright. Rolling has, uh, stopped rolling, has it not? I'm assuming all-snaps will be rolling eventually, correct?
[13:28] <ogra_> diwic, the current install dir is always a link from /snaps/pulseaudio.sideload/current to /snaps/pulseaudio.sideload/weirdcombinationofcharacters ... and in a store snap (not sideloaded) it will actually be: /snaps/pulseaudio.$maintainer/$snap-version (with the "current" link pointing to it)
[13:28] <ogra_> also there is an envv variable pointing to it at runtime
[13:28] <mvo> kyrofa: yes it has, see https://lists.ubuntu.com/archives/snappy-devel/2016-January/001381.html
[13:29] <mvo> kyrofa: the all-snap images are getting all the love now :)
[13:30] <kyrofa> mvo, ah, right, I remember seeing that. So if I want to release a package for all snaps, do I target rolling in the store then?
[13:31] <mvo> kyrofa: yes, rollling is fine
[13:31] <mvo> kyrofa: the store does not parse snap.yaml yet but for snapcraft thats fine because it will generate compat package.yaml files
[13:33] <kyrofa> mvo, okay. Will all snaps eventually become rolling, or are we moving away from that structure completely?
[13:33] <mvo> kyrofa: all-snaps is rolling, the previous rolling just is not there anymore (sorry, I think that sounds confusing)
[13:33] <sergiusens> kyrofa, once 16.04 is released I'm sure beuno will add the option (not sure everything in rolling will be auto moved/tagged for 16.04 as well)
[13:34] <beuno> yeah, I think we'll add 16.04 soon
[13:34] <ogra_> mvo, hmm, snappy lets me install old snaps on rolling ... but fails to actually install them
[13:34] <ogra_> beuno, ^^
[13:35] <ogra_> shouldnt they be hidden ?
[13:35] <ogra_> http://paste.ubuntu.com/14688116/
[13:35] <beuno> ogra_, they should, yes, we're sorting all of that out
[13:35] <ogra_> ah, k
[13:35] <mvo> ogra_: yes, its a known issue, I meant to write to all the developers but didn't yet because its actually two changes that are needed: the rebuild with squashfs and the convertion to snap.yaml
[13:36] <ogra_> right
[13:36] <mvo> ogra_: the best option (for now) is to unpublish on rolling
[13:36] <ogra_> well, after all i need to snapcraftify all my snaps anyway
[13:36] <ogra_> (again :P )
[13:37] <kyrofa> mvo, okay so u-d-f can still use "rolling" and it'll be all-snaps? On xenial only, it sounds like?
[13:38] <sergiusens> mvo, one question I forgot to ask; are all rolling apps all of the sudden broken due to the use of skills (migration-skill) instead of the known caps, security-<override,policy,template>?
[13:39] <asac> mvo: lool: no answer :)?
[13:46] <jdstrand> mvo: related question, has migration-skill landed on the image?
[13:51] <sergiusens> jdstrand, from the latest email, it seems it has
[13:52] <sergiusens> mvo, do we support the unversioned data path already? (ref email on list)
[13:53]  * jdstrand is not caught up on email today
[13:54] <noizer> Hi guys i packaged an example snap from the github snapcraft. the py2-project is the project but how does i start it?
[13:54] <noizer> or run the snap
[13:55] <kyrofa> noizer, it has a binary in there, right?
[13:55] <kyrofa> That binary causes a script to be placed in /apps/bin (or /snaps/bin if you're on rolling)
[13:55] <kyrofa> noizer, which is in your PATH
[13:56] <kyrofa> noizer, so try running spongeshaker.sha3sum <some file>
[13:59] <noizer> spongeshaker.sha3sum is not a command :s
[13:59] <kyrofa> noizer, take a look in /apps/bin. What is there?
[13:59] <kyrofa> sergiusens, how far off is clean build, you think?
[14:00] <kyrofa> sergiusens, and what does it actually entail? (i.e. how would it work)
[14:00] <noizer> kyrofa some helloworld things from the helloworld application
[14:00] <noizer> but nothing from spongeshaker
[14:00] <kyrofa> noizer, ah, have you installed it yet? I may have jumped the gun
[14:01] <noizer> sudo snappy install --allow-unauthenticated /home/ubuntu/spongeshaker_0_armhf.snap
[14:01] <noizer> that did i
[14:01] <noizer> to install it
[14:03] <kyrofa> noizer, hmm... what folders are contained within /apps?
[14:03] <kyrofa> (and did the install actually succeed?)
[14:03] <kyrofa> noizer, do you see it if you run `snappy list`?
[14:05] <LefterisJP> hey guys, today my Raspberry PI has 5 times already rebooted due to snappy autopilot
[14:05] <LefterisJP> is that normal?
[14:05] <LefterisJP> (RaspberryPi2)ubuntu@localhost:~$
[14:05] <LefterisJP> Broadcast message from root@localhost.localdomain (Thu 2016-01-28 14:00:35 UTC):
[14:05] <LefterisJP>  
[14:05] <LefterisJP> snappy autopilot triggered a reboot to boot into an up to date system -- temprorarily disable the reboot by running 'sudo shutdown -c'
[14:05] <LefterisJP>  
[14:05] <noizer> here you can see the output of snappy list
[14:05] <noizer> kyrofa and hi exists in the dir /apps
[14:05] <noizer> kyrofa
[14:05] <noizer> http://pastebin.com/LkTP0mTH
[14:06] <sergiusens> kyrofa, we just need to do it; maybe a week or two away
[14:06] <sergiusens> kyrofa, I'm still too slow this week; juggling with all the changes that happened while away
[14:06] <sergiusens> kyrofa, cleanbuild is basically lxd
[14:07] <kyrofa> sergiusens, hey, you're fine man! I'm just asking if maybe we should just drop my go PR if that's close
[14:07] <kyrofa> sergiusens, because that changes a lot of things
[14:07] <sergiusens> kyrofa, the thing is, your PR will work for the simple case, but imagine building some lib; then have your go project build after that one
[14:08] <kyrofa> sergiusens, yeah... I feel like the REAL FIX is cleanbuild
[14:08] <kyrofa> sergiusens, drop it?
[14:08] <sergiusens> kyrofa, I would argue that we sometimes do want to export vars ourselves from the system
[14:09] <sergiusens> kyrofa, if not, we should clean all vars for everything before snapcraft runs at all
[14:09] <kyrofa> sergiusens, fair point. Though isn't that what cleanbuild will essentially do?
[14:09] <ogra_> LefterisJP, 5 times ? i'm sure there werent 5 images built. do you perhaps mean it warned you 5 times like above ? (it should start that 10min before it reboots every 2 mins so you have a chance to stop it with the command it tells you if you feel like)
[14:10] <kyrofa> sergiusens, obviously it will do more as well. But no environment leakage, I mean
[14:10] <kyrofa> noizer, something is weird there. Try uninstalling/reinstalling the spongeshaker package
[14:11] <noizer> kyrofa does not work :s
[14:11] <kyrofa> noizer, pastebin the logs
[14:12] <noizer> kyrofa while installing?
[14:12] <kyrofa> noizer, yeah, pastebin the result of installing
[14:13] <LefterisJP> ogra_: so whenever there is a new image this message goes out as long as you have auto pilot config on?
[14:14] <LefterisJP> ogra_: perhaps not 5, but 3 times definitely, and no I meant the actual restarting and installing a new version.
[14:14] <noizer> kyrofa http://pastebin.com/Xaf3XGbe
[14:17] <kyrofa> LefterisJP, did you verify that it was a new version each time? Or is it failing for some reason?
[14:17] <kyrofa> noizer, wait... I thought you said it didn't work
[14:17] <noizer> no no it worked the installation
[14:17] <noizer> kyrofa but how can i start correctly the snap
[14:18] <kyrofa> noizer, pastebin the result of `ls /apps` and `ls /apps/bin/`
[14:19] <noizer> kyrofa http://pastebin.com/s80aA5Nj
[14:19] <awe_> kyrofa, sergiusens, where there any changes to the ability to override plugins in snapcraft 2.0?  I used this to add a patching step to the autotools plugin, but snapcraft doesn't seem to be detecting and/or running my local plugin anymore
[14:20] <LefterisJP> kyrofa: no I did not actually. Good point.
[14:20] <ogra_> LefterisJP, weird ... and yes, autopilot runs every ten mins and checks for a new image ... if there is one, it notifies you for 10 mins a few times and then reboots if you dont intercept
[14:20] <kyrofa> LefterisJP, I mean... still a problem... but yeah :P
[14:20] <kyrofa> awe_ no I believe that should still be working
[14:21] <awe_> kyrofa, ok... I'll poke at it some more and see if I can figure out what's going wrong
[14:21] <kyrofa> awe_ we need to cover that in integration tests. I'll check it out right now as well
[14:21] <sergiusens> awe_, no, there has been no changes; I just used it last week mself
[14:21] <awe_> kyrofa, I know you mentioned that the --help was caused by a lack of LOCALE
[14:21] <sergiusens> kyrofa, it is covered
[14:22] <awe_> maybe that impacts plugins too?
[14:22] <kyrofa> sergiusens, oh. Well then, ignore me!
[14:22] <mvo_> sergiusens: unfortunately not yet
[14:22] <awe_> anyways, I'll dig into it some more after our net/telephony mtg
[14:22] <awe_> I hit this late last night, and took it as a sign to end my day
[14:22] <awe_> ;)-
[14:22] <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/test_local_plugin.py
[14:22] <sergiusens> mvo_, err, not yet to what? :-)
[14:23] <kyrofa> sergiusens, thanks for the reference :)
[14:23] <sergiusens> awe_, give me a `find . | pastebinit` and a `cat snapcraft.yaml | pastebinit` and I'll take a look
[14:24] <mvo_> sergiusens: the data dir is not there yet
[14:24] <mvo_> sergiusens: the fixed one
[14:24] <sergiusens> mvo_, ah, k, thanks!
[14:24] <awe_> sergiusens, ack... I have to dive into a patch quickly before my next meeting, so I'll get this for you a bit later
[14:25] <LefterisJP> kyrofa: how can I verify that I am at the latest version? snappy info shows release: ubuntu-core/15.04/stable and snappy list shows: ubuntu-core  2016-01-20 6
[14:25] <mvo_> sergiusens: it is on the todo though
[14:25] <awe_> sergiusens, I want to make sure it's not my mistake first
[14:25] <sergiusens> mvo_, as everything :-)
[14:25] <awe_> :q!
[14:25] <kyrofa> awe_, yeah ping us if you need us to take a look
[14:25] <awe_> !$#%%! haven't done that in a while!  lol
[14:26] <kyrofa> Awww, awe_ be nice to ubottu
[14:26] <sergiusens> awe_, heh, well the first thing to check is make sure your <plugin> ref is a file named parts/plugins/x_<plugin>.py (notice the underscore)
[14:26] <kyrofa> sergiusens, is the x actually required?
[14:27] <noizer> kyrofa how does i solve it?
[14:27] <awe_> hmmmm; looks like my parts plugin dir got clobbered at some point
[14:27] <sergiusens> kyrofa, to override, yes
[14:27] <kyrofa> noizer, what version of snapcraft are you using?
[14:28] <sergiusens> kyrofa, well, I think it is always required; just to note it is an extension and not an official one
[14:28] <noizer> release: ubuntu-core/15.04/stable kyrofa
[14:28] <kyrofa> sergiusens, what if its named something totally different, though?
[14:28] <awe_> pretty sure I didn't do an rm -rf; but I'll take the blame for now, unless I can prove otherwise...
[14:28] <kyrofa> sergiusens, ahh, okay
[14:28] <ogra_> noizer, and you try to run a snapcraft 2.0 created snap on int ?
[14:28] <sergiusens> kyrofa, oh, you can override or name it whatever you want
[14:28] <ogra_> *it
[14:28] <kyrofa> awe_ there are times when I must scold my fingers for typing rm -rf instead of cp
[14:29] <awe_> haha, yea...
[14:29] <ogra_> kyrofa, you could just set an alias from rm -rf to cp ... that would solve it :P
[14:29] <kyrofa> ogra_, hahaha
[14:29] <noizer> ogra kyrofa my  snapcraft where i build it is snapcraft 1.0
[14:29] <sergiusens> dholbach, bah, that thunderbird conversation view wiped my reply as didrocks's email came in :-P
[14:30] <kyrofa> sergiusens, I'm wondering now-- does snapcraft clean make sure no custom plugins are in parts before it blows it away?
[14:30] <ogra_> noizer, ah, that should still work then
[14:30] <vir17> I have a similar case like noizer I think , this pastebin (http://pastebin.com/gf2qF1g8)  included all my steps, I think I have something wrong with my .yaml files
[14:30] <sergiusens> kyrofa, yup; it doesn't blow away the plugins dir, it only cleans up from defined parts and you can't name a part 'plugins'
[14:30] <sergiusens> kyrofa, way ahead of you ;-)
[14:30] <noizer> ogra_ kyrofa so i tought it too but what does go wrong?
[14:31] <ogra_> vir17, you need to include python in your snap
[14:31] <kyrofa> noizer, where are you getting the example you're snapping?
[14:31] <ogra_> check the snapcraft-examples and take a look at the python2 example
[14:31] <noizer> https://github.com/ubuntu-core/snapcraft/tree/master/examples ogra_ kyrofa
[14:31] <didrocks> sergiusens: oh, you are using that plugin? How come did my answer wiped yours? :p
[14:31] <kyrofa> sergiusens, ah, I believed in you. Just curious :)
[14:32] <ogra_> noizer, these are most likely 2.0 examples ... a lot changed between 1.0 and 2.0
[14:32] <kyrofa> noizer, exactly, what ogra said
[14:32] <kyrofa> noizer, use the examples by doing this: `sudo apt-get install snapcraft-examples`
[14:32] <noizer> ogra_ kyrofa ok where can i get the snappy then for snapcraft 2.0
[14:33] <ogra_> (but 2.0 snaps wont run on 15.04 ... so try to grab the 1.0 examples package instead )
[14:33] <sergiusens> didrocks, I was typing a reply within the same view and your email arrival updated the view and my reply went bye bye
[14:33] <sergiusens> :-)
[14:33] <kyrofa> sergiusens, ahh thunderbird
[14:33] <ogra_> (or switch your target device install to 16.04 )
[14:33] <sergiusens> ogra_, and now, no snaps will run on 16.04 ;-)
[14:33] <ogra_> sergiusens, oh ?
[14:34] <sergiusens> ogra_, look at snappy-devel@
[14:34] <didrocks> sergiusens: urgh, I know why I'm not using that plugin then! (I remembered to have tried it some years ago, but was unconvinced :p)
[14:34] <sergiusens> kyrofa, hey
[14:34] <sergiusens> standup time
[14:34]  * ogra_ wishes his mailserver wouldnt be so stuck :P
[14:34] <kyrofa> sergiusens, oh oops
[14:35] <ogra_> be agile !
[14:35] <ogra_> :P
[14:38] <vir17> ogra_: in order to include python all I have to do is to include "plugin: python2" in the .yaml file?
[14:38] <ogra_> check the example for the exact syntax
[14:38] <ogra_> there is a snapcraft.yaml in it
[14:39] <vir17> ok
[14:45] <noizer> kyrofa what is de difference between snapcraft 1.0 and 2.0
[14:45] <ogra_> new features ... new yaml syntax ... and most important 2.0 uses squashfs files
[14:46] <ogra_> all these bits are only supported in rolling (16.04)
[14:48] <noizer> ok i think i will switch to it but what are squeashfs files? ogra_
[14:49] <ogra_> it is a compressed readonly filesystem
[14:49] <ogra_> saves a lot of diskspace and download time
[14:50] <ogra_> (and you cant just mount it rw, so it adds extra security)
[14:51] <alella> can  packages running on ubuntu 14  be compiled to run on snappy
[14:53] <ogra_> alella, theoretically you could even run packages from last century inside a snap (snaps need to include their dependency chain)
[14:55] <noizer> ogra_ so but is it possible to mount because for me i need to do that for installing main things
[14:56] <ogra_> noizer, in 16.04 everything is a snap and snaps all ship suqashfs inside, so no, you wont be able to modify any of the writable bits anymore
[14:57] <ogra_> 16.04 ships the classic dimension though, that gives you a rw container on top of the readonly fs for development etc
[14:58] <noizer> so when i mount it on a other ubuntu system i cant do changes?
[14:58] <didrocks> ogra_: the container is just for developping, right? It's not started at reboot (and so you can't have services running in it), or am I wrong?
[14:59] <sergiusens> didrocks, it is the intended purpose
[14:59] <alella> so if you a packaga designed for ubuntu 14 you cant  use snappy commands to compile for snappy
[15:00] <ogra_> didrocks, right
[15:00] <didrocks> ok, got it right then :)
[15:00] <ogra_> it is good enough to run snapcraft in it :)
[15:00] <ogra_> what else would anyone want anyway ;)
[15:00] <didrocks> ;)
[15:01] <ogra_> alella, snaps only contain binaries, you can put whatever you want into it
[15:01] <ogra_> i bet you could even put some redhat 4.x binaries into one and make it run as long as you ship all linkedf libs inside :)
[15:02]  * genii shivers in disgust
[15:02] <ogra_> hahaha
[15:03] <ogra_> yeah, scary example, i admit that
[15:03] <ogra_> but technically it might work
[15:11] <elopio> ogra_ could you tell me about pxe in uboot? will we be able to use it on rpi?
[15:12] <ogra_> i cant tell you about PXE but we can surely support some kind of network boot (bootp or so)
[15:12] <jdstrand> ogra_: it buys some security, perhaps. if you have the ability to remount, you have the ability to bind mount, so...
[15:13] <ogra_> i think i didnt remove the netboot setup defaults from the uboot env
[15:13] <jdstrand> (in fact, that is exactly how I am testing certain things on all snaps)
[15:13] <ogra_> just intercept the boot in uboot and check with printenv
[15:13] <jdstrand> actually, I think I used an overlay not a bind mount. still
[15:14] <ogra_> jdstrand, well, it prevents me from hacking on my shell script wrappers directly on the running system
[15:14] <jdstrand> overlayfs /snaps/bin
[15:14] <jdstrand> hack away
[15:14] <ogra_> sure i could do some overlay magic etc ... but ui cant modify the actual squashfs
[15:14] <jdstrand> that is true
[15:14] <jdstrand> and that is definitely an important quality for integrity
[15:14] <ogra_> well, i can ... but only trhrough repacking
[15:14] <ogra_> right
[15:15] <ogra_> it is annoying in the develo0pment process though ...
[15:15] <jdstrand> I realize I'm being pedantic
[15:15] <jdstrand> it is
[15:16] <ogra_> jdstrand, oh, btw ... does your ufw package do anything with bridging ?
[15:16]  * ogra_ recently had someone asking if there was bridge support in snappy 
[15:16] <jdstrand> I've wondered if we shouldn't just straight up have a tool to create a cow overlayfs on /snaps/foo, etc for this sort of thing
[15:16] <ogra_> i assume ufw sits a layer above ?
[15:16] <jdstrand> ogra_: not natively, no
[15:17] <ogra_> yeah, thats what i suspected
[15:17] <jdstrand> ogra_: there are hooks scripts that you can put whatever you want in them for bridges, qos, etc, but it is all on the admin
[15:17] <ogra_> and packaging bridge tools might be a pain wrt securing it
[15:17] <kyrofa> jdstrand, wait... can you use overlayfs to hack on the mounted squashfs snap? Or are you guys saying that's exactly what's NOT possible?
[15:17] <elopio> pitti: is it possible to allow some autopkgtests to access the internet? or are there no exceptions, is it strictly blocked for everybody?
[15:17] <ogra_> kyrofa, you can ... but you wont hack on the squashfs
[15:18] <pitti> elopio: they can all access the internet, as long as they respect the $*_proxy env vars
[15:18] <ogra_> only on the writable overlay
[15:18] <pitti> elopio: and a lot of them actually do
[15:18] <kyrofa> ogra_, right, so it doesn't actually save upon reboot. But it allows you to tinker anyway?
[15:18] <ogra_> yeah
[15:18] <jdstrand> kyrofa: let me give a concrete example. I have root on the device. I want to test the new ubuntu-core-security package before uploading it. I create a cow overlayfs so I can unpack my ubuntu-core-security deb in it and have the system see the update
[15:18] <kyrofa> kgunn, ^^ you might like that
[15:19] <jdstrand> kyrofa: the same thing could be done for an app snap (the above was for the os snap)
[15:20] <kyrofa> jdstrand, interesting, I need to do some overlayfs research
[15:20] <ogra_> note that we do not have it on all kernels (i thinnk)
[15:21] <jdstrand> ogra_: that is probably true and if it isn't now, it will be for sure
[15:21] <ogra_> yeah
[15:22] <jdstrand> but, for working with vms or the bbb and rpi2, it should be fine
[15:22] <ogra_> at least in xenial
[15:22]  * jdstrand is assuming since bbb uses generic and rp2 a modern kernel, it is there
[15:22] <jdstrand> I've only done it on amd64
[15:22] <kgunn> yeah interesting
[15:23] <jdstrand> one could do it with just a bind mount, but then you have to copy everything in
[15:24] <vir17> ogra_: still no success, this is my new .yaml file http://pastebin.com/RfPVJn0f based on this one: https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/py2-project/snapcraft.yaml   and these are the outputs of "ls /apps" and "ls/apps/bin" http://pastebin.com/XMJK272q
[15:24] <jdstrand> kgunn: from my notes (I'm not a huge overlayfs user, but this worked for me)
[15:24] <jdstrand> Say I want to update the templated policy on the device:
[15:24] <jdstrand> $ mkdir /tmp/overlay /tmp/work
[15:24] <jdstrand> $ sudo mount -t overlayfs -o lowerdir=/usr/share,upperdir=/tmp/overlay,workdir=/tmp/work overlayfs /usr/share
[15:24] <jdstrand> $ sudo dpkg-deb -x ./tmp/ubuntu-core-security-seccomp_16.04.10_all.deb /
[15:24] <jdstrand> $ sudo dpkg-deb -x ./tmp/ubuntu-core-security-apparmor_16.04.10_all.deb /
[15:25] <jdstrand> that is how I tested an ubuntu-core-security update on all snaps
[15:31] <kyrofa> jdstrand, excellent notes, thank you!
[15:34] <elopio> pitti: I see. Our tests are timing out doing a git clone, so I could fix them with something like
[15:34] <elopio> git config --global http.proxy $...
[15:34] <elopio> right?
[15:35] <pitti> elopio: no, the env vars should already be set in /etc/environment
[15:35] <jdstrand> kyrofa: you're welcome :)
[15:35] <pitti> elopio: didrocks' ubuntu-make tests use git clone as well and that works
[15:36] <elopio> great, I'll check there.
[15:36] <didrocks> elopio: confirming, I don't need to export any env variable (only for docker config, but that's different)
[15:36] <elopio> didrocks: and do you clone git http: or with git: ?
[15:37] <didrocks> elopio: the https:// scheme
[15:37] <didrocks> the git one (ssh) isn't opened
[15:38] <elopio> I can change the tests to use https instead of ssh, as sergiusens suggested.
[15:38] <mvo_> ogra_: could you please remind me how the kernel (device) tarball is created on cdimage nowdays?
[15:38] <elopio> I wanted to keep at least a test using the git protocol, but that's alright.
[15:43] <sergiusens> ogra_, jdstrand so that is one of the things snappy try is supposed to bring to the table; from you dev area you could `snappy try DIR` and it would just put it in the right place, activate and you can play easily from your classic env
[15:43] <ogra_> neat !
[15:44] <mvo_> sergiusens: yeah, I think we will use something like jdstrand is doing with overlayfs for that
[15:45] <jdstrand> I think that is where we may get into the issues of overlayfs and apparmor though
[15:45] <jdstrand> snappy try could easily use a bind mount though
[15:45] <sergiusens> mvo_, well if it is a first time snap, overlayfs won't exactly work, will it?
[15:46] <jdstrand> that's another reason for a bind mount
[15:46] <sergiusens> jdstrand, I think bind mounts are going to be straight forward as well
[15:46] <jdstrand> just copy stuff in there
[15:46] <mvo_> sergiusens: sorry, I was too terse, I was thinking that we use the overlay for /snaps/bin and bind mount the actual app dir
[15:46] <sergiusens> ah
[15:46] <mvo_> sergiusens: and services probably also as overlay
[15:46] <sergiusens> mvo_, makes sense
[15:46] <mvo_> sergiusens: to avoid leaving stale files around
[15:47] <jdstrand> that should work fine
[15:47] <noizer> kyrofa is snapcraft 2.0 and ubuntu LTS 16.04 already available for raspberry pi?
[15:48] <kyrofa> noizer, yes, but it's still in development
[15:48] <kyrofa> noizer, both, rather
[15:48] <noizer> ok its not a stable version
[15:48] <kyrofa> noizer, indeed
[15:48] <noizer> kyrofa ok and what is the expected release date?
[15:48] <kyrofa> noizer, 16.04 is actually a date
[15:48] <kyrofa> noizer, April, 2016
[15:49] <kyrofa> noizer, the previous version is wily, 15.10, released in October 2015. Make sense?
[15:50] <vir17> Can anyone help me please, this is my .yaml file http://pastebin.com/RfPVJn0f based on this one: https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/py2-project/snapcraft.yaml   and these are the outputs of "ls /apps" and "ls/apps/bin" http://pastebin.com/XMJK272q
[15:51] <noizer> kyrofa but snapcraft 2.0 is much better i think?
[15:51] <diwic> a few dependencies added and some files moved later - now pulseaudio does not complain about missing libraries any more, but it exits immediately with "Bad system call" instead.
[15:51] <kyrofa> noizer, well, it's newer anyway. What feature are you looking for?
[15:51] <diwic> any idea how to troubleshoot? gdb and/or strace does not seem available
[15:51] <kyrofa> diwic, seccomp
[15:52] <noizer> kyrofa none but i need to choose for my development
[15:52] <kyrofa> diwic, are you familiar with snappy-debug?
[15:52] <diwic> kyrofa, nope, but I tried to install it and installation failed
[15:52] <kyrofa> noizer, 15.04 is stable right now, but it reaches end-of-life soon. rolling (what will become 16.04) is still in development, so it can break sometimes
[15:53] <kyrofa> diwic, you're on rolling?
[15:53] <noizer> ok and will snapcraft 1.0 apps work on snapcraft 2.0
[15:53] <kyrofa> noizer, no, but the YAML changes aren't too bad
[15:53] <diwic> kyrofa, the 16.04 image from ~two weeks ago
[15:54] <noizer> kyrofa ok i will make my application then in snapcraft 2.0
[15:54] <kyrofa> diwic, ah, yeah a new version on rolling was released that breaks things. Some packages need to be rebuilt
[15:55] <lool> ogra_: hey
[15:55] <kyrofa> diwic, so check /var/log/syslog for seccomp denials
[15:56] <lool> I have this dragonboard u-boot tree from github, I've built u-boot there; can I just throw it on the SD card, or do I need to run the image tool first?
[15:56] <kyrofa> diwic, are you familiar with seccomp filters? It's one of the confinement technologies used by snappy
[15:56] <lool> (mkbootimg)
[15:56] <lool> [264059.140132] mmcblk1: error -110 sending status command, retrying
[15:56] <lool> uh
[15:57] <lool> not happy  :-(
[15:57] <ogra_> lool, i followed the docs in the tree ... one sec
[15:57] <diwic> kyrofa, there is one, but I'm not sure how to interpret the numbers. syscall=135, which is "sys_personality" judging from a quick googling
[15:57] <lool> ogra_: the last step is:
[15:57] <lool> 5) run img.sh to wrap u-boot into fastboot compatible img
[15:58] <lool> but wasn't sure if we need this
[15:58] <lool> oh hey diwic!
[15:58] <kyrofa> diwic, do you have scmp_sys_resolver on there?
[15:58] <ogra_> lool, i think we do, i just followed the step by step guide
[15:59] <kyrofa> diwic, you should be able to run `scmp_sys_resolver 135`
[15:59] <diwic> kyrofa, it says "personality"
[15:59] <noizer> kyrofa where can i download the development version of it?
[15:59] <kyrofa> diwic, huh. No idea what that does :P
[15:59] <diwic> hi lool
[16:00] <kyrofa> diwic, but it's not in your seccomp profile
[16:01] <kyrofa> jdstrand, is the personality syscall a security issue?
[16:01] <kyrofa> I'm guessing yes
[16:03] <jdstrand> kyrofa: I'd want to exercise caution with that one. tyhicks may have an opionion
[16:03] <jdstrand> I need to step away for a little bit
[16:03] <kyrofa> jdstrand, yeah the manpage is a little tough to understand, but it sounds iffy
[16:04] <jdstrand> I'm mostly worried about exposing that part of the kernel to apps. eg, these different personalities that aren't used much might have future vulnerabilities
[16:05] <jdstrand> but this is really to enable truly legacy binaries
[16:05] <tyhicks> I don't know much personality(2) off the top of my head
[16:06] <tyhicks> I'll have to look into it
[16:06] <jdstrand> maybe there are other use cases...
[16:07] <kyrofa> diwic, do you know why it's being used?
[16:08] <LefterisJP> kyrofa: There it goes again, my system is going down for reboot
[16:08] <LefterisJP> (for update)
[16:08] <LefterisJP> how can I confirm it worked?
[16:08] <kyrofa> LefterisJP, okay when it comes back up compare the version to what you saw last time
[16:08] <LefterisJP> and version is?
[16:09] <diwic> kyrofa, not yet, I'm trying to figure out how to change seccomp profile (if possible?) since there is no info about that in the snapcraft.yaml reference
[16:09] <LefterisJP> snappy info?
[16:09] <jdstrand> tyhicks: we don't have an explicit use case for it. it seems dodgy overall (not keen on how it would add to the attack surface). it does seem to only be for the process itself (the only thing going for it)
[16:09] <tyhicks> the PER_SVR4 and PER_UW7 personalities look nasty since they allow page 0 to be memory mapped
[16:09] <LefterisJP> or snappy list -v ?
[16:10] <jdstrand> tyhicks: I suggest not getting distracted by it. we can investigate/add it at a later date if people need it
[16:10] <jdstrand> (and people can use security-override today to workaround it)
[16:10] <kyrofa> jdstrand, tyhicks thanks for the quick look guys-- sounds like we should avoid it if we can
[16:10] <tyhicks> jdstrand: ok - my vote is 'no' until it becomes more of an issue down the road
[16:11] <ogra_> lool, so i just checked ... i ran run.sh and then dd'ed it to the SD cards boot partition
[16:11] <jdstrand> tyhicks: sounds fine. thanks for the quick glance
[16:11] <kyrofa> diwic, check out some of the snapcraft examples-- the gopaste one has an override for a syscall
[16:11] <ogra_> err
[16:11] <ogra_> img.sh
[16:11] <mvo_> ogra_: could you please remind me how the kernel (device) tarball is created on cdimage nowdays?
[16:11] <kyrofa> LefterisJP, I think it was 6 according to you last paste? Which actually doesn't sound right
[16:11] <kyrofa> LefterisJP, are you running 15.04?
[16:12] <kyrofa> LefterisJP, or rolling?
[16:12] <ogra_> mvo_, in a fresh chroot from live-build/auto/build after the rootfs was done
[16:12] <mvo_> ogra_: thanks!
[16:12]  * ogra_ digs up the line number
[16:13] <ogra_> mvo_, 344 to 487
[16:13] <mvo_> ogra_: heh, thanks :)
[16:14] <mvo_> ogra_: the right file would have been enough but I'm of course thankful for every piece of info
[16:14] <ogra_> heh
[16:14] <ogra_> for that one we can just run mksquashfs
[16:14] <ogra_> the rootfs will be a little trickier
[16:15] <diwic> kyrofa, jdstrand, I believe I found the place in the PA code, it says "Maybe we're autospawned, try to clean up our environment as much as possible". I think I can comment it out since we won't autospawn on snappy
[16:15] <mvo_> ogra_: yeah, I am looking at creating some manifest data for jdstrand right now
[16:15] <ogra_> thanks to the fact that "-preinstalled" hardcodes tarball or ext2
[16:15] <ogra_> ah
[16:15] <diwic> I think it's trying to do restrict itself, i e increase security somehow
[16:15] <kyrofa> diwic, I've had to do similar things to other codebases
[16:15] <ogra_> mvo_, there is already a find call that dumps it to the log
[16:15] <mvo_> ogra_: sweet
[16:16]  * ogra_ tries to find the find
[16:16] <mvo_> ogra_: all good
[16:16] <mvo_> ogra_: no worries
[16:16] <ogra_> 471         # dump the content list into the log
[16:16] <ogra_> 472         echo "I: device tarball contents for $PREFIX.$tarname:"
[16:16] <ogra_> 473         find . -type f
[16:16] <ogra_> just redirect it to a .manifest file in parallel
[16:17] <diwic> ok, need to EOD. Thanks kyrofa and others for all your help so far
[16:17] <kyrofa> diwic, any time :)
[16:17] <ogra_> diwic, thanks for pulse work !!!
[16:18]  * ogra_ is fiddling with a mycroft snap ... urgently waiting for some audio love :)
[16:18] <diwic> ogra_, heh, haven't got that far yet
[16:21] <LefterisJP> kyrofa: 15.04
[16:21] <kyrofa> LefterisJP, and you said an rpi2, right?
[16:21] <LefterisJP> yeah still says 6
[16:21] <LefterisJP> yes it's an rpi2
[16:22] <kyrofa> LefterisJP, hmm... I'm on version 20 here
[16:23] <kyrofa> LefterisJP, you've just left my realm of experience. I'll need to refer you to sergiusens or mvo_
[16:23] <kyrofa> LefterisJP, I'm not sure how to debug the failed update
[16:23] <sergiusens> kyrofa, LefterisJP that is an mvo_ or ogra_ topic, sorry
[16:24] <LefterisJP> all right I am all ears if anyone can help. Good to know at least that the update is failing. That's progress already :)
[16:24] <sergiusens> LefterisJP, maybe elopio or fgimenez can help as well
[16:24] <LefterisJP> btw is any of you going to be in London next week?
[16:25] <sergiusens> LefterisJP, is there anything interesting happening there?
[16:26] <elopio> LefterisJP: are you in rpi2 snappy stable #6 and trying to update to #7?
[16:26] <LefterisJP> elopio: I am in version #6 from what snappy list seems to tell me.
[16:26] <LefterisJP> And the auto update kicks in
[16:27] <mvo_> LefterisJP: sorry, I think I miss some context. so you have a 15.04 stable rpi2 and it fails to update?
[16:27] <LefterisJP> and when it restarts I am still at the same version
[16:27] <mvo_> LefterisJP: could you pastebin the exact error output?
[16:27] <LefterisJP> ofc, but can you help me find it? Where should I look for the error output?
[16:27] <elopio> LefterisJP: do you have a serial cable for that rpi2?
[16:28] <LefterisJP> elopio: not on the ready but I can find one
[16:28] <LefterisJP> can't I see something on the logs?
[16:29] <camako> Is it possible to specify a particular version of a package in 'stage packages' section? Will something like "-libmypackage-dev (= version)" work?
[16:29] <sergiusens> camako, no; we only support the latest in the archives
[16:32] <elopio> LefterisJP: I'm flashing stable #6 to give it a try here.
[16:32] <elopio> This is how I monitor the boot and reboot: http://elopio.net/blog/connecting-to-snappy-through-the-serial-console/
[16:32] <elopio> and dmesg should have all the boot logs. But I think it doesn't keep the ones from the previous boot failure.
[16:33] <LefterisJP> sergiusens: As for London, I am gonna be there in the canonical offices next week and heard some snappy core devs will be there so was wondering if I could meet some of you
[16:33] <ogra_> looks like 6 was released on the 20th and 7 was released today ?
[16:33] <LefterisJP> elopio: thanks. Nice link. Will also try to do that when I get the serial cable.
[16:33] <ogra_> since when do we do weekly releases ?
[16:34] <sergiusens> LefterisJP, wasn't aware of that, from whom may I ask?
[16:36] <LefterisJP> sergiusens: Thibaut Rouffineau
[16:37] <kyrofa> sergiusens, yeah I think his team is sprinting there
[16:39] <sergiusens> LefterisJP, you might be able to go and  meet didrocks then
[16:39] <LefterisJP> yeah it's some kind of sprint and I am gonna be there since it's a nice chance to meet some snappy people and get help with the framework snap we are working on
[16:40] <didrocks> will be happy to chat with you LefterisJP :)
[16:40] <LefterisJP> didrocks: sergiusens: nice :D, would be nice to put some faces on some nicks. Lurking in IRC and the developer lists is nice but has its limits
[16:43] <sergiusens> LefterisJP, I have not been invited to that sprint; sort of glad since I would like to be grounded for a bit :-)
[16:45] <sergiusens> mvo_, does the migration-skill support security-template and security-policy?
[16:45] <mvo_> sergiusens: yes, all of the security stuff is supported 1:1, just a different place now
[16:46] <sergiusens> mvo_, k, so files from -policy are used in the same way, good to know. I recall it in the code now
[16:46] <sergiusens> thanks
[16:46] <mvo_> sergiusens: yw
[16:47] <LefterisJP> sergiusens: I know what you mean :)
[16:48] <LefterisJP> elopio: Here is my dmesg output in case it can mean anything to you. I just noticed there are quite a few errors with the SD card. Could very well be related.
[16:48] <LefterisJP> https://gist.github.com/LefterisJP/500f1907d9cae8471caf
[16:51] <elopio> LefterisJP: update from 6 to 7 worked here.
[16:51] <elopio> we'll need that serial log to understand what's failing during your reboot.
[17:00] <LefterisJP> yeah I see. Then I guess I will need to order that cable. I don't have it after all. For the time being if I simply download and flash a newer raspberry pi image all should be good though I suppose.
[17:01] <LefterisJP> elopio: ^
[17:02] <kyrofa> sergiusens, if I want to test out the upload stuff on the staging server rather than actually doing an upload, do you know the URL off the top of your head?
[17:02] <kyrofa> LefterisJP, yeah that'll work
[17:02] <elopio> LefterisJP: yes, if you don't care about losing your work on that one.
[17:03] <kyrofa> pindonga, actually my question might be better directed to you
[17:04] <kyrofa> pindonga, if I want to test out the upload stuff, I figure I'd best do it on the staging server
[17:04] <ogra_> mvo_, so i finally got around to try that all snaps dragonboard image ... hangs at the lk for me ....
[17:04]  * ogra_ re-flashes the SD to make sure its not a flashing issue
[17:04] <LefterisJP> elopio: yeah no worries about that, it's my testing Pi. Should get that cable though. I had communicated with Samsung's Artik via serial USB and assumed I could do the same with the Pi but it seems that I need the cable you mentioned.
[17:07] <ogra_> lool, didnt you say mvo_'s all-snap image booted for you ?
[17:08] <lool> ogra_: which one?
[17:08] <lool> ogra_: I didn't try the dragonboard one, no
[17:08] <ogra_> http://people.canonical.com/~mvo/all-snaps/
[17:08] <ogra_> ah
[17:08] <lool> I'm tring the efi v2 patchset on top of dragonboard u-boot right now
[17:08] <lool> just trying to figure the right grub2 binary to load
[17:09] <ogra_> well, perhaps we should first ahve a working image before modifying it :P
[17:15] <ogra_> [260] ERROR: Could not do normal boot. Reverting to fastboot mode.
[17:15] <ogra_> [270] Invalid partition index
[17:15] <ogra_> [270] Invalid partition index
[17:15] <ogra_> hmmm
[17:16] <ogra_> i wonder if mvo_'s changes to my u-d-f patch caused that
[17:18] <lool> ogra_: I had some SD errors on an SD here, and then it wouldn't boot on it anymore
[17:18] <lool> I wrote a fresh image to a new SD and then it worked
[17:18] <lool> might not be related but thought I'd mention it
[17:18] <ogra_> yeah, unklikely to be related
[17:19] <ogra_> the partition table looks fine
[17:20] <ogra_> sadly it doesnt print much more than the above .... no actual reason mentioned .... grmbl
[17:20] <pindonga> kyrofa, hi there
[17:22] <pindonga> kyrofa, run it like this UBUNTU_STORE_API_ROOT_URL='https://myapps.developer.staging.ubuntu.com/dev/api' UBUNTU_STORE_UPLOAD_ROOT_URL='https://upload.apps.staging.ubuntu.com/' UBUNTU_SSO_API_ROOT_URL='https://login.staging.ubuntu.com/api/v2/' snapcraft upload
[17:22] <kyrofa> pindonga, excellent, thank you!
[17:23] <pindonga> let me know how it goes
[17:23] <pindonga> sorry, the first one make sure it ends with / (ie, ../dev/api/)
[17:30] <mvo_> ogra_: hm, I thought I did not really modify anything except for resolving conflcits. sad that it fails to boot now
[17:32] <kyrofa> pindonga, how do I get a token for this? I'm getting "No valid creds"
[17:32] <ogra_> yeah, i cant really get it past the little kernel, something is wrong with the partition ids ... i guess due to calling sgdisk differently after your change
[17:32]  * ogra_ checks the tree
[17:33] <mvo_> jdstrand: I'm making some progress on the manifest stuff, hopefulyl by tonight you have what you need
[17:33] <kyrofa> Oh, login
[17:34] <pindonga> kyrofa, right, snapcraft login
[17:34] <pindonga> msg should be clearer about this possibly
[17:34] <kyrofa> pindonga, indeed
[17:35] <pindonga> kyrofa, unless you have 2fa enabled on your account when it asks you about OTP just press enter
[17:35] <kyrofa> dholbach, hey what's the status of the auto document sync?
[17:35] <dholbach> kyrofa: we're just deploying it on staging right now
[17:35] <kyrofa> dholbach, woo hoo!
[17:35] <dholbach> ran into some issues with juju and mojospec
[17:35] <dholbach> so I hope it'll be done beginning of the week
[17:35] <ogra_> mvo_, which dragonboard snap did you use ?
[17:36] <ogra_> (bootloader etc)
[17:36] <mvo_> ogra_: when I compare https://code.launchpad.net/~ogra/goget-ubuntu-touch/dragonboard/+merge/280320 with http://bazaar.launchpad.net/~snappy-dev/goget-ubuntu-touch/all-snaps/revision/251 it looks like I call sgfisk the same way
[17:37] <ogra_> mvo_, oh, i was referring to https://code.launchpad.net/+branch/~mvo/goget-ubuntu-touch/dragonboard
[17:37] <mvo_> ogra_: I used what I got from linux-image4.2.0-2004 kernel snap and your gadget snap
[17:37] <JamesTait> jdstrand, are you around?
[17:37] <ogra_> i thought you landed that alongside
[17:37] <ogra_> mvo_, that kernel wont work
[17:37] <mvo_> ogra_: I don't think I merged that
[17:37] <mvo_> ogra_: aha, thats good to know
[17:37] <ogra_> yeah, i see that now
[17:38] <lool> ogra_: so I have an updated u-boot for dragonboard, I've ran img.sh on it, it looks similar to the one I found in mmcblk1p7, but it seems boot goes straight to emmc, any idea what could be missing?
[17:38] <ogra_> you need ppisatis kernel
[17:38] <mvo_> ogra_: I need to leave for dinner now, if you could point me to the right kernel I can update the snap later
[17:38] <ogra_> lool, you need the right UIDS on the partitions
[17:38] <ogra_> it is very fragile :/
[17:38] <ogra_> mvo_, right, the boot stalls on the bootloader with a partition error though
[17:39] <ogra_> before u-boot
[17:39] <ogra_> so there is something else
[17:39] <dholbach> all right my friends - I call it a day - see you all tomorrow!
[17:40] <ogra_> lool, see my scripts at http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files/5 ... the IDs are in http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/parts.txt (used as input for the partitioner script)
[17:40] <lool> ogra_: I didn't touch the part table though
[17:40] <ogra_> of the SD ?
[17:40] <lool> yeah
[17:40] <ogra_> hmm
[17:41] <lool> I just overwrote u-boot payload
[17:41] <lool> can I stop the boot somehow?
[17:41] <ogra_> so the "boot" partition ? (not "aboot")
[17:41] <lool> S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.0-00261
[17:41] <ogra_> oh
[17:41] <lool> [...]
[17:42] <lool> Android Bootloader - UART_DM Initialized!!!
[17:42] <lool> [0] [0] welcome to lk
[17:42] <ogra_> actually ... on mvo_'s all-snaps image there isnt any boot partition ... hah
[17:42] <lool> [90] [90] boot_verifier: Device is in ORANGE boot state.
[17:42] <lool> [100] [100] Device is unlocked! Skipping verification...
[17:42] <lool> [100] [100] Loading boot image (16521216): start
[17:42] <jdstrand> mvo_: awesome, thanks!
[17:42] <jdstrand> JamesTait: I am
[17:42] <lool> but then it's [    0.000000] Linux version 3.10.49-g0b014e2-00001-gebe2063 (buildslave@aosp-x86-64-08) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #9 SMP PREEMPT Wed Dec 2 10:33:57 UTC 2015
[17:42] <ogra_> lool, ok so that finds uboot and loads it it seems
[17:42] <ogra_> hmm
[17:42] <ogra_> oh
[17:43] <lool> ogra_: [740] [740] Updating device tree: done
[17:43] <lool> [740] [740] booting linux @ 0x80080000, ramdisk @ 0x82000000 (795398), tags/device tree @ 0x81e00000
[17:43] <lool> [750] [750] Jumping to kernel via monitor
[17:43] <ogra_> lool, did you set the dip switch to SD on the bottom of the board ?
[17:43] <lool> yes
[17:43] <ogra_> weird
[17:43] <lool> ogra_: I was booting from SD, updated hte contents and ran "reboot"
[17:43] <JamesTait> jdstrand, I might have figured out the problem, actually: does click-reviewers-tools currently handle squashfs snaps with just meta/snap.yaml?
[17:44] <ogra_> lool, try re-powering ... might be it needs re-init
[17:44] <jdstrand> ogra_: speaking of dragonboards-- I got one in the mail. I don't know what to do with it though (ie, to get it running). I don't need to today or next week even-- I assume instructions will come out sometime (or maybe I missed them already)?
[17:44] <ogra_> for the Sd controller
[17:44] <lool> I did try power cycling already  :-(
[17:44] <ogra_> jdstrand, there are instructions already ... and an early image
[17:45] <jdstrand> JamesTait: the review tools know about squashfs to some extent. they don't know about snap.yaml yet. those two things are what I will be focusing on
[17:45] <ogra_> jdstrand, http://people.canonical.com/~ogra/snappy/dragonboard/README
[17:45] <jdstrand> that doesn't surprise me at all
[17:45] <jdstrand> thanks! :)
[17:45] <ogra_> :)
[17:45] <ogra_> lool, got a full log ?
[17:45] <lool> ogra_: not really
[17:46] <JamesTait> jdstrand, will that also encompass this error: "1 Warning: Unknown field 'daemon' snappy-systemd_package_yaml_unknown_key (server); 1 Fail: (NEEDS REVIEW) squashfs pkg lint_is_squashfs"?
[17:46] <JamesTait> * These errors.
[17:46] <lool> ogra_: ah I might miss your u-boot patch
[17:46] <jdstrand> JamesTait: yes. the new snap.yaml is not supported yet
[17:46] <jdstrand> but I'll get all working
[17:46] <ogra_> lool, well, it should still go to uboot instead of the kernel
[17:47] <JamesTait> mvo_, ^^
[17:47] <JamesTait> Thanks, jdstrand.
[17:47] <JamesTait> nessita, beuno too ^^
[17:47]  * lool drops for dinner and will check again later
[17:47] <jdstrand> I had a card on it-- and upped the priority when I saw it landed
[17:48] <JamesTait> jdstrand, similar story here. ☺
[17:48] <kyrofa> pindonga, I can't seem to be able to login to staging
[17:48] <beuno> JamesTait, ack
[17:48] <jdstrand> heh
[17:48] <kyrofa> pindonga, no 2fa there
[17:48] <pindonga> kyrofa, be aware that staging sso is a separate db from prod
[17:48] <pindonga> so your account may not exist there, or have a diff passwd?
[17:48] <kyrofa> pindonga, yeah-- I can login online
[17:49] <pindonga> k
[17:49] <jdstrand> mvo_, sergiusens: iirc, snappy build is going away and everything is going to use snapcraft, correct?
[17:49] <pindonga> does it give you any error msg?
[17:49] <kyrofa> pindonga, just "login failed"
[17:50] <kyrofa> pindonga, I use the same environment variables you gave me before with `snapcraft login`
[17:50] <kyrofa> pindonga, is that the right way to authenticate for staging?
[17:50] <pindonga> yes, should be
[17:50] <pindonga> let me try it as well
[17:51] <sergiusens> jdstrand, correct
[17:51] <nessita> JamesTait, thanks. So we can land our work waiting for the new click-reviewer-tools and then do the cleanup
[17:53] <jdstrand> sergiusens: ok, so two things: 1) I'm likely going to need to submit a patch to snapcraft to make sure it uses a particular set of options for mksquashfs (I'll submit that) so the store and snapcraft agree and 2) does snapcraft have a way to simply mksquashfs a directory?
[17:53] <jdstrand> sergiusens: I'm not sure yet what those options are otherwise I'd give them to you
[17:53] <JamesTait> nessita, indeed, it looks that way.  I just mangled the snap mvo_ gave me to also include a package.yaml, and the reviewers tools now handle it, but fails with the squashfs manual review and lack of a readme.md
[17:54] <JamesTait> nessita, the click-reviewers-tools work will address both of those and the handling of snap.yaml
[17:54] <kyrofa> jdstrand, yessir!
[17:54] <jdstrand> sergiusens: the second question might be a nice thing to have so that everyone always uses the right options
[17:54] <jdstrand> kyrofa: was that an answer to '2'?
[17:54] <nessita> JamesTait, perfect. So you are a bit blocked now?
[17:54] <pindonga> kyrofa, just logged in and uploaded a file successfully... checking your sso account now
[17:54] <kyrofa> jdstrand, it was
[17:55] <kyrofa> jdstrand, only 2.0 though
[17:55] <jdstrand> excellent
[17:55] <jdstrand> sure
[17:55] <kyrofa> jdstrand, well, obviously
[17:55]  * jdstrand nods :)
[17:55] <kyrofa> jdstrand, yeah, just `snapcraft snap <directory>`
[17:55] <JamesTait> nessita, my branch is ready for review, but might not make much sense without that update.
[17:56] <nessita> JamesTait, if we land *and* deploy that we will block all squashfs uploads, correct?
[17:56] <kyrofa> jdstrand, for your reference: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/commands/snap.py#L80
[17:56] <jdstrand> handy
[17:56] <jdstrand> kyrofa: thanks! :)
[17:57] <kyrofa> jdstrand, obviously feel free to make a PR, but if you make a bug for it we can take of it too :)
[17:57] <jdstrand> ack
[17:57] <JamesTait> nessita, new squashfs uploads (without package.yaml) are blocked already.
[17:59] <pindonga> kyrofa, ok, bug
[17:59] <pindonga> am on it
[17:59] <kyrofa> pindonga, ah, thank you! :)
[17:59] <ogra_> mvo_, dd'ing my u-boot.img in place gets me gurther
[18:00] <ogra_> *further
[18:00] <pindonga> it's passing the otp even when empty
[18:00] <pindonga> which causes sso to fail auth
[18:00] <ogra_> so something is wrong with that u-boot binary
[18:00] <nessita> JamesTait, ok, so we could move forward landing and eventually deploying that, correct?
[18:00] <JamesTait> nessita, I think we're also depending on beowulf's icon_url piece, which I think is waiting until Monday?
[18:00] <kyrofa> pindonga, ah, excellent
[18:01] <JamesTait> If that's the case, maybe we should land this on Monday as well?
[18:02] <nessita> JamesTait, not for this, no
[18:02] <nessita> JamesTait, is independent, I think
[18:03] <JamesTait> nessita, currently I'm unable to publish the package I just uploaded because it needs an icon.
[18:03] <nessita> JamesTait, yeah, that is fine
[18:03] <nessita> meaning is independant of your change
[18:04] <JamesTait> OK, great! 😃
[18:05] <ogra_> mvo_, the next issue is that for some weird reason you added the uboot partition to the end of the disk ... the partition to load uboot.env from is hardcoded at build time in the dragonboard u-boot (and currently points to mmc 1:8 ... while the boot partition on your image is 1:9 ...)
[18:05] <JamesTait> In which case I'll await a review of my branch and land it when we get approval, and I'm ready for something new.
[18:06] <pindonga> kyrofa, sergiusens now that upload is part of snapcraft we might also need to update the examples; this is because the store will only accept a package icon if it's 256x256 px in size
[18:06] <pindonga> the upload will get accepted, but the icon will not
[18:06] <JamesTait> I should probably catch up on e-mails till my EOD in ~40 mins though. 😉
[18:06] <pindonga> ie, if you upload eg gopaste you'll see it there eventually but without the right icon
[18:07] <kyrofa> pindonga, I'm writing an example doc for uploading right now
[18:07] <kyrofa> pindonga, that's only for .pngs I assume?
[18:08] <pindonga> yes, probably.. tbh don't know for sure if the store currently supports other icon formats
[18:08] <kyrofa> pindonga, svgs
[18:09] <kyrofa> pindonga, by the way I'm happy to fix that 2fa bug if you can point me in the right direction
[18:10] <pindonga> almost there
[18:10] <pindonga> I'll let you review it :)
[18:10] <pindonga> + I introduced the bug so I feel responsible for fixing it
[18:10] <pindonga> :)
[18:11] <sergiusens> pindonga, kyrofa our solution could be to just remove all the icons ;-)
[18:11] <kyrofa> sergiusens, I'm on board with that
[18:11] <kyrofa> pindonga, haha, okay sounds good
[18:11] <sergiusens> kyrofa, but they are examples, so we probably need an example with how to do it
[18:13] <kyrofa> sergiusens, did forking turn into a boolean in package.yaml somewhere along the line?
[18:16] <sergiusens> kyrofa, yeah
[18:16] <sergiusens> kyrofa, package.yaml is going away in my skill migrationbranch though
[18:17] <kyrofa> sergiusens, alrighty
[18:17] <sergiusens> kyrofa, when you fix the upload stuff messages, can you silence the unit tests as well?
[18:17] <kyrofa> sergiusens, yup
[18:18] <sergiusens> kyrofa, thanks!
[18:18] <pindonga> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/274
[18:20] <kyrofa> pindonga, can you add a # to the bug ref in the commit? It _might_ work with git-dch, but all the man examples have the #
[18:21] <pindonga> do I need to commit --amend or just update it in github ui?
[18:21] <pindonga> updated in ui
[18:22] <kyrofa> pindonga, you need to amend I'm afraid-- we need it in a commit
[18:22] <pindonga> ack, doing so then
[18:22] <kyrofa> pindonga, thanks :)
[18:23] <nessita> sergiusens, hello! quick question, how can I build a snap without an icon? I'm using snapcraft from ppa:snappy-dev/tools and when running it complains: Issues while validating snapcraft.yaml: 'icon' is a required property
[18:23] <pindonga> pushed
[18:23] <kyrofa> nessita, you need snapcraft 2
[18:24] <nessita> kyrofa, thanks for helping! any instructions where to get it from?
[18:24] <kyrofa> pindonga, I don't see any changes...
[18:25] <pindonga> ah
[18:25] <kyrofa> nessita, that's the xenial release
[18:25] <pindonga> bad push
[18:25] <nessita> kyrofa, is there any way of getting it in willy?
[18:25] <nessita> upgrading to xenial for this feels a bit overkill :-)
[18:25] <kyrofa> nessita, not unless you feel like running from source-- pre-xenial is all Snapcraft 1.x
[18:26] <nessita> kyrofa, I see, thanks
[18:26] <kyrofa> nessita, what are you targeting?
[18:27] <nessita> kyrofa, I'm working on the store and needed to debug issues when uploading a snap without icon
[18:27] <nessita> kyrofa, so basically I need an iconless valid snap
[18:27] <nessita> JamesTait, do you happen to have that? ^
[18:27] <kyrofa> nessita, I'm not sure .snaps without icons are valid in 15.04
[18:28] <JamesTait> nessita, I have a couple you could use.
[18:28] <nessita> kyrofa, they are not, but I don't really need to target any specific snappy, my focus is the store
[18:28] <nessita> JamesTait, highly appreciated!
[18:28] <kyrofa> nessita, ah, I see. Yeah sorry about that. Running from source is pretty easy for what it's worth
[18:29] <nessita> kyrofa, it is? anywhere I can read about how to?
[18:30] <LefterisJP> https://github.com/ubuntu-core/snapcraft is the github repo
[18:30] <kyrofa> nessita, yeah just don't use the upload stuff, it's prereqs aren't available pre-xenial. The rest should work though. Here's the general hacking guide: https://github.com/ubuntu-core/snapcraft/blob/master/HACKING.md
[18:31] <kyrofa> nessita, but really, just clone is and run the bin/snapcraft script
[18:31] <nessita> kyrofa, amazing! thank you
[18:31] <kyrofa> nessita, check debian/control for all its deps. If you're running 1.0 you probably have most of them
[18:32] <kyrofa> nessita, the master branch is 2.x, but not always released. I suggest `git checkout 2.0.1` to get the most recent release-worthy stuff
[18:33] <nessita> kyrofa, super helpful, thank you (still cloning)
[18:33] <kyrofa> nessita, note that 2.x generates .snaps that will only run on xenial. Not sure if that matters for the store stuff you're doing
[18:33] <sergiusens> kyrofa, still need to update the integration tests and examples https://github.com/ubuntu-core/snapcraft/pull/275
[18:33] <sergiusens> but it is a start
[18:33] <sergiusens> need to run for a bit
[18:33] <kyrofa> nessita, any time :) . Let me know if you need help with that
[18:33] <kyrofa> sergiusens, sounds good!
[18:33] <nessita> kyrofa, it does not matter, thanks, I'm just using them to upload to my local store
[18:36] <kyrofa> nessita, whatever you do, don't install it using the setup.py
[18:36] <kyrofa> Just use it straight out of the src
[18:36] <nessita> yes, yes
[18:36] <nessita> or install in a venv
[18:37] <kyrofa> nessita, pssh, you know more about this stuff than I do. You'll be fine :P
[18:37] <nessita> hunting for docopt now
[18:37]  * nessita apt-get installs it
[18:38]  * kyrofa goes to plug in the external monitor. If he drops that's why
[18:39] <kyrofa> Hey! Still here
[18:42] <pindonga> kyrofa, hey... looks like travis choke on that PR
[18:42] <pindonga> what do we do about that?
[18:42] <nessita> kyrofa, so! I ran snapcraft build with this output https://pastebin.canonical.com/148649/ but I don't have a .snap at sight
[18:42] <kyrofa> pindonga, nah it's still going
[18:42] <pindonga> do I need to re-push? is it possible to manually trigger a new job?
[18:42] <kyrofa> pindonga, have faith
[18:42] <pindonga> I mean, the static test suite failed
[18:42] <pindonga> but bc of some lxc related issue
[18:42] <kyrofa> pindonga, oh. So it did
[18:43] <pindonga> ah, looks like it's restarting the job by itsel
[18:43] <pindonga> itself
[18:43]  * pindonga is new to these things
[18:43] <pindonga> :)
[18:43] <kyrofa> pindonga, I poked it
[18:43] <pindonga> coo
[18:43] <elopio> pindonga: is not automatic, there's a button.
[18:44] <kyrofa> nessita, yeah things changed a bit
[18:44] <kyrofa> nessita, run `snapcraft snap`
[18:44] <nessita> ah!
[18:44] <nessita> [Errno 2] No such file or directory: 'mksquashfs'
[18:44] <nessita> installing!
[18:44] <kyrofa> nessita, squashfs tools
[18:45] <nessita> o/
[18:45] <nessita> Snapped foobar_1.1_amd64.snap
[18:45] <nessita> SUCCESS!
[18:45] <kyrofa> Hey hey, there you go!
[18:46] <nessita> and now the store chokes with it "The upload does not appear to be a valid click package" so this may be the fix we await from reviewer-tools
[18:46] <nessita> kyrofa, thanks a lot for your help
[18:46] <kyrofa> nessita, no problem, it's why I'm here :)
[18:51] <kyrofa> elopio, git-dch does not seem to be in git-buildpackage in xenial. Do you know where it went?
[18:53] <kyrofa> elopio, ahh, things were renamed to gbp it seems
[18:54] <elopio> kyrofa: yes, same package, new name.
[18:55] <pindonga> kyrofa, ok, looks like it's all green now
[18:57] <kyrofa> pindonga, excellent, thanks for that :)
[19:28] <mvo_> ogra_: oh, interessting - so there is a off-by-one error in the partition setup?
[19:28] <mvo_> ogra_: one too many?
[19:31] <mvo_> jdstrand: snappy build is goind away yes, we need to have something internal though for our build-in tests, so its going away and also not quite going away
[19:32] <mvo_> jdstrand: looks like I missed all the action around the new snap.yaml :/ so click-reviewers-tools need an update too? will it just warn or outright reject the snap?
[19:35] <vir17> is there a ready version of snappy for raspberry pi that uses snapcraft 2?
[19:36] <kyrofa> vir17, yes indeed
[19:36] <kyrofa> vir17, look here: http://people.canonical.com/~mvo/all-snaps/
[19:37] <kyrofa> vir17, note that snappy and snapcraft are different though. You need to enable the classic dimension before you can use snapcraft on snappy
[19:37] <kyrofa> vir17, do you know what I'm talking about?
[19:38] <vir17> I think you talk about running snapcraft from snappy?
[19:38] <vir17> or i am wrong?
[19:39] <kyrofa> vir17, indeed. Were you wanting something else?
[19:39] <vir17> I use another machine to create the apps
[19:40] <vir17> apps that packed with snapcraft2 could not run in the older version of snappy
[19:41] <kyrofa> vir17, correct. Yeah, you want that app-snaps image then
[19:41] <kyrofa> vir17, do note that a snappy update today breaks .snaps created with snapcraft though. A fix will be out soon
[19:41] <vir17> ok so it is safer to stay with the older version
[19:42] <vir17> and with snapcraft 1
[19:42] <vir17> ??
[19:42] <kyrofa> vir17, for right now yes, but we're trying to stabilize soon
[19:42] <vir17> :)
[19:43] <vir17> I found it easier to follow the example in the new snapcraft
[19:43] <vir17> this is the reason I asked
[19:43] <kyrofa> vir17, which example?
[19:45] <vir17> I had installed in my system the new snapcraft
[19:45] <vir17> and the examples i tried to re-create didnt work for me
[19:46] <vir17> so I thought I could try the new snappy
[19:46] <kyrofa> Ah, okay
[19:47] <vir17> I have to understand now what is wrong with my .yaml file
[19:47] <vir17> because my app doesn't appear in the /apps/bin after a successful installation
[19:47] <kyrofa> Hey pindonga, if you have a minute, would you mind looking this over? https://github.com/ubuntu-core/snapcraft/pull/277
[19:47] <pindonga> sure
[19:47] <kyrofa> vir17, you need to refer to the examples from the right release
[19:48] <kyrofa> vir17, I suggest installing the snapcraft-examples package and using those
[19:48] <vir17> I just install it to a spare raspberry pi running ubuntu mate
[19:48] <kyrofa> pindonga, just make sure I didn't lie in there anywhere :P
[19:48] <vir17> so I will try again
[19:48] <vir17> :)
[19:49] <mvo_> ogra_: is my gadget snap maybe wrong? I think I just took yours but: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/dragonboard/meta/package.yaml - i.e. might this explain the off-by-one issue?
[19:52] <vir17> kyrofa:  if I have both the new snapcraft and snapcraft-examples in my system, how I can choose which version of snapcraft to use to pack my app?
[19:52] <vir17> is it possible?
[19:52] <kyrofa> vir17, I'm afraid having them both installed isn't possible
[19:52] <vir17> i will use the raspberry pi then to pack my app
[19:52] <vir17> thank you :0
[19:52] <vir17> :)
[19:52] <kyrofa> vir17, sure :)
[20:01] <pindonga> kyrofa, comments added
[20:01] <pindonga> do you need to me +1 somewhere?
[20:01] <kyrofa> pindonga, no, that's exactly what I needed, thank you!
[20:02] <kyrofa> pindonga, actually why don't you give it a thumbs up just in an overall comment, if you don't mind
[20:02] <pindonga> k
[20:04] <kyrofa> Alright now that I know that it's actually correct, elopio take a look at https://github.com/ubuntu-core/snapcraft/pull/277 when you have a minute
[20:18] <elopio> kyrofa: reviewed. pindonga: I left in that PR some comments about possible bugs. Could you please check if you agree?
[20:18] <pindonga> already replied :)
[20:18]  * pindonga checks again, just in case
[20:20] <pindonga> yep, all replied to
[20:21] <vir17> kyrofa: are you still there
[20:21] <vir17> ?
[20:24] <kyrofa> vir17, I am
[20:25] <kyrofa> elopio, pindonga thanks guys :)
[20:26] <elopio> cool. thanks kyrofa for all the bugs.
[20:26] <vir17> do you have any clue about this error: FileExistsError: [Errno 17] File exists: '/home/vir17/Desktop/serial-test4/parts/serialdev/build'
[20:26] <vir17> this is my .yaml
[20:26] <vir17> http://pastebin.com/mRbXAkb2
[20:27] <kyrofa> vir17, well, your YAML looks fine for Snapcraft 1.0
[20:27] <kyrofa> vir17, try running `snapcraft clean` and then run `snapcraft` again
[20:27] <vir17> ok
[20:29] <awe_> kyrofa, is there any documentation about how to build snaps on a device running snappy?  trying to figure out the best way to build my snap so it can be run on an ripi2?
[20:29] <kyrofa> awe_ not that I know of but I can walk you through it
[20:30] <awe_> i *just* got the latest rolling image up & running
[20:30] <kyrofa> awe_ as soon as all-snaps is a bit more stable I think we'll have docs on it
[20:30] <awe_> ok
[20:30] <kyrofa> awe_ first question: which version of ubuntu core are you targeting?
[20:30] <awe_> the latest rolling
[20:31] <kyrofa> Excellent. Then all you need to do is enabled classic with `sudo snappy enable-classic`
[20:31] <awe_> i have a snap built using snapcraft 2.0
[20:31] <awe_> ok
[20:31] <kyrofa> awe_ that command will setup the "Classic Dimension," allowing you to use .debs
[20:31] <kyrofa> awe_ once that finishes, you'll be able to apt-get install snapcraft
[20:32] <awe_> ok
[20:32] <kyrofa> awe_ the rest should be easy
[20:32] <awe_> and then what happens when i want to test?
[20:32] <awe_> does that still all work as expected?
[20:32] <awe_> eg. sudo snappy install
[20:32] <awe_> ...
[20:32] <awe_> or do i need to disable classic mode once i've finished building?
[20:33] <kyrofa> awe_ good question, I haven't actually done it
[20:33] <awe_> ;)-
[20:33] <kyrofa> awe_ I actually ran into a make bug when I tried this last time-- make was segfaulting
[20:33] <awe_> well, good thing i bought two new sd cards
[20:33] <awe_> ;D
[20:33]  * awe_ crosses his fingers
[20:33] <kyrofa> awe_ so I ended up installing regular-old Ubuntu on there to build
[20:34] <awe_> ah, ok
[20:34] <awe_> well, let's try this out first
[20:34] <awe_> maybe i'll get lucky
[20:34] <kyrofa> awe_ keep that in mind-- if you hit some weird make segfaulting thing, other people have too
[20:34] <kyrofa> elopio, I can't remember-- did you report that somewhere?
[20:35] <vir17> kyrofa: the same thing happened again
[20:35] <vir17> the complete log: http://pastebin.com/dWhUT36X
[20:35] <awe_> so how involved is installing regular xenial on the ripi2?
[20:36] <kyrofa> awe_ I actually did trusty (I was targeting vivid so that worked for me)
[20:36] <kyrofa> awe_ there was a prebuilt image on the wiki I stole
[20:36] <kyrofa> awe_ not sure about xenial
[20:36] <awe_> k
[20:36] <awe_> we'll see how classic goes then
[20:36] <vir17> to give you more info, the app i try to build is just a simple python file http://pastebin.com/XphBGzUA
[20:37] <elopio> kyrofa: https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1536727
[20:37] <kyrofa> elopio, oh yeah. I confirmed it :P
[20:38] <kyrofa> vir17, you aren't running snapcraft twice, are you?
[20:38] <kyrofa> vir17, just snapcraft clean followed by snapcraft?
[20:38] <vir17> yes
[20:39] <kyrofa> vir17, after snapcraft clean, can you verify that the parts directory has been removed?
[20:39] <kyrofa> elopio, is a OTP prompt of "One-time password (just press enter if you don't use 2FA):" too long?
[20:41] <elopio> kyrofa: it's long, but better than OTP
[20:41] <elopio> kyrofa: but now you introduced the word 2fa
[20:41] <vir17> kyrofa: http://pastebin.com/4hxArVaj
[20:41] <kyrofa> elopio, heh, I knew you'd pick on that
[20:41] <elopio> what about "if you don't use it" ? Still confusing?
[20:41] <vir17> i can snapcraft clean and restart the system to be sure
[20:42] <kyrofa> elopio, yeah that brings up "What's a one-time password? Well, maybe I don't use it" :P
[20:42] <kyrofa> vir17, looks like it's indeed gone. Can you push your entire project somewhere so I can take a look?
[20:43] <elopio> I wouldn't mind making it even longer saying two-factor authentication. But then we might be making it more confusing.
[20:43] <kyrofa> elopio, hrmm... so it sounds like the only good solution is to somehow detect if it's not necessary
[20:43] <kyrofa> elopio, if you agree, I'll make that a separate bug
[20:43] <vir17> ok I will send you the link in 1min, thank you :)
[20:44] <elopio> kyrofa: well, that's the perfect solution. We can live with less than perfect for now.
[20:45] <elopio> there should be a nice way to do it, because it's how it's done on the web. You hit log in, and if you have 2fa enabled the next page asks for it.
[20:45] <elopio> here instead of clicking log in, we press enter after the password.
[20:45] <kyrofa> elopio, agreed. I figure if we can change the prompt to something better that would be a decent intermediate step
[20:46] <sergiusens> awe_, kyrofa in case it wasn't answered; you `sudo snappy enable-classic`; then you `snappy shell classic`; in there you apt all you want; you exit the shell or from a different login `snappy install *.snap`
[20:47] <kyrofa> elopio, it's the "decent" bit that's difficult
[20:47] <kyrofa> sergiusens, ah, thank you!
[20:47]  * elopio leaves for lunch
[20:52] <vir17> kyrofa: you can check here my entire project https://github.com/lmbn/serial/tree/master
[20:55] <kyrofa> vir17, ah, run `snapcraft help python2`
[20:56] <kyrofa> vir17, you're not using it quite right
[20:57] <kyrofa> Nooooo ubuntu bring my mouse pointer back...
[20:59] <vir17> kyrofa:  make sense now, I need a lot more parts to use python
[20:59] <vir17> is this the only way?
[20:59] <vir17> or I can do something else to make a snappy app with just the files I already have
[21:00] <vir17> i mean if I run my code straight into the terminal
[21:00] <vir17> the code is working
[21:00] <vir17> can I create a snappy app out of it?
[21:00] <kyrofa> vir17, it works on your terminal because you already _have_ all those dependencies
[21:00] <kyrofa> vir17, but they need to be put into the .snap itself
[21:01] <kyrofa> vir17, make sense?
[21:02] <kyrofa> Alright, reaching EOD around here
[21:02] <vir17> ok so in other words I need to include dependencies for all my imports (import serial, import time, import os)
[21:02] <vir17> ?
[21:02] <kyrofa> vir17, yes, but snapcraft will take care of that for you if you setup the part correctly. Reference the python2 example
[21:03] <vir17> i will try then :) thank you again kyrofa
[21:03] <kyrofa> Sure thing :) . Have a nice evening everyone!
[21:03] <vir17> you too
[21:22] <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/275
[21:22] <sergiusens> also wouldn't mind a review from jdstrand and mvo (not connected https://github.com/ubuntu-core/snapcraft/pull/275)
[21:25] <kgunn> sergiusens: hey, so reading mvo's mail about additional changes coming like icon having to be in meta/icon etc
[21:25] <kgunn> is that going to be pushed onto snapcraft2.0 ?
[21:25] <jdstrand> I'll add it to my todo-- I may not get to it today though
[21:25] <kgunn> or later....like a 3.0
[21:26] <sergiusens> kgunn, it is already in snapcraft
[21:26] <sergiusens> kgunn, but that is internal formatting
[21:26] <jdstrand> I can also review after the fact. I quickly perused it and see you added the 4 directives under the migration-skill, which is good
[21:26] <sergiusens> kgunn, from a snapcraft perspective you still do icon: path-to-icon
[21:26] <kgunn> sergiusens: ah
[21:26] <sergiusens> kgunn, and snapcraft puts everything in the right place
[21:27]  * kgunn likes it when things get put in the right place magically
[22:05] <awe_> thanks sergiusens!  it actually worked.  still need some tweaks to the snap to get things functional, but good progress!
[22:25] <sergiusens> awe_, nice!
[22:40] <noizer> Hi guys just a question the doc on de developer.ubuntu website is that for snapcraft 2.0 kyrofa
[23:06] <noizer> kyrofa it is snapcraft 2.0 syntax on the dev site of ubuntu?