[04:46] <wxl> hey folks can someone tell me how to generate an i386 image with ubuntu-device-flash? no matter what i do, i can't get it to wor
[04:46] <wxl> k
[04:48] <wxl> i'm trying sudo ubuntu-device-flash core 15.04 -o my-snappy.img --device generic_i386 --channel edge --enable-ssh
[04:48] <wxl> i get a warning that "this option" should only be used to build azure images
[04:48] <wxl> and then it starts downloading a generic-amd64
[04:48] <wxl> and then says it failed to install (but i'm not trying to install it)
[08:04] <fgimenez> good morning
[08:20] <dholbach> good morning
[08:21] <diwic> good morning!
[08:21] <diwic> new day, new snappy questions :-)
[08:22] <diwic> I'm wondering about XDG_RUNTIME_DIR - PulseAudio expects to be able to write to that directory. It currently points to /run/user/1000 where the snap cannot write.
[08:23] <diwic> Should we 1) point XDG_RUNTIME_DIR to somewhere inside /snap/pulseaudio/current/ or 2) add some rule that allows PA to write to /run/user/1000 ?
[08:44] <noizer> kyrofa is that the correct link to download the ubuntu 16.04 for Raspberry pi
[09:37] <JamesTait> Good morning all!  Happy Friday, and happy Fun At Work Day! 😃
[09:53] <mvo> hey JamesTait, good morning! It looks like I missed some messages yesterday, anything important that I should reply to now .) ?
[09:54] <JamesTait> Good morning, mvo!  I don't think there's any action on you at the moment.  I'm just cleaning up my branch and jd-strand is working on the click-reviewers-tools part.
[09:56] <devil_> hi, can somebody clarify for me, if Snappy Personal is still happening?
[09:58] <noizer> Hi i have a question for what should I use Docker on my snappy?
[09:58] <mvo> JamesTait: cool, thanks
[09:58] <noizer> Is it good for things like UWSGI and Nginx?
[10:21] <ogra_> mvo, your gadget snap looks fine but i think something changed the order how/when partitions are created
[10:25] <ogra_> mvo, what my code does it to append all partitions to the created image ... you have three partitions and left a gap at the start ... i append 4,5,6,7,8,9,10 (this is in partition numbering though, pyhsically they would be 1,2,3,4... and then tell sgdisk to sort the numbering by position in the end which should align the numbering to the physical position
[10:26] <mvo> ogra_: oh, the new image has less partitions, its just boot and writable, no more a/b.
[10:26] <ogra_> mvo, somehow "boot" with u-boot.img ends up at the last physical position now
[10:26] <mvo> ogra_: what positition should this have?
[10:27] <ogra_> the number shouldnt matter though
[10:27] <ogra_> i pick up the last one and add +1
[10:27] <mvo> ogra_: ok, let me look at this code again, maybe I get an idea
[10:28] <ogra_> "boot" should be after "aboot" http://paste.ubuntu.com/14694737/
[10:28] <ogra_> the u-boot binary currently expects top find its env on p8
[10:29] <ogra_> mvo, the wrong position isnt the big issue here, it would still boot (though couldnt resize anymore due to writable not being at the end)
[10:29] <ogra_> well, the wrong position of "boot" isnt the blocker
[10:30] <ogra_> its still an issue :)
[10:30] <mvo> ogra_: what is the blocker? the kernel?
[10:31] <ogra_> mvo, no, the uboot binary is broken .... wheere did you get it ?
[10:31] <ogra_> (if i dd mine in place i get a proper uboot shell)
[10:31] <ogra_> heh, well, and yeah, the kernel too :P
[10:31]  * ogra_ isnt awake yet
[10:32] <ogra_> we need to fix all three
[10:32] <mvo> ogra_: I thought I had it from your dragonboard oem snap, let me double check
[10:33] <ogra_> well, if it is the same binary then something in the way it is written to disk is broken
[10:33] <ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps$ md5sum ../oem-snap/snap/u-boot.img
[10:33] <ogra_> aad77edcce10781ace7df4d4a104c891  ../oem-snap/snap/u-boot.img
[10:34] <mvo> ogra_: I thikn its out of http://people.canonical.com/~ogra/snappy/dragonboard/dragonboard_0.1_all.snap
[10:34] <ogra_> thats the md5 here
[10:34] <mvo> ogra_: but let me check
[10:34] <mvo> eh, sorry
[10:34] <mvo> no, the right snap
[10:35] <mvo> ogra_: md5 matches
[10:36] <ogra_> then the way it gets written broke it i guess
[10:36] <ogra_> cant imagine anything else
[10:36] <mvo> ogra_: offset is correct? 3179520 ?
[10:37] <ogra_> 3179520
[10:37] <ogra_> yeah
[10:37] <ogra_> the type GUID is also correct ... but the little kernel complains and stops the boot in the default image
[10:37] <ogra_> as soon as i dd mine it boots fine (to the point where it cant find the uboot.env on partition 8)
[10:38] <mvo> ogra_: ok, I look at u-d-f now. what is the correct kernel url?
[10:38] <ogra_> let me check, ppisati said he has a new deb
[10:39] <ogra_> https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.2.0-2009-generic-dragon410c_4.2.0-2009.9~15.10_arm64.deb
[10:40] <ogra_> mvo, oh, but that needs another dtb (needs changing in package.yaml of the gadget and uboot.env)
[10:40] <asac> mvo: lool: how is producing OS-type initrd going?
[10:42] <asac> (good day :))
[10:42] <mvo> asac: not at all on my side, busy with 4234324 other things :/
[10:42] <ogra_> mvo, the dtb we need it apq8016-sbc
[10:43] <ogra_> asac, mvo i'll do that
[10:43] <ogra_> its essentially just copying the build script from the phone initrd package into the core one
[10:43] <asac> great... i guess for now i would need a one off OS snap with such kernel-less initrd
[10:43] <asac> cool
[10:44] <ogra_> asac, i just want to get that dragonboard image to run first if possible
[10:44] <asac> once we have that i think i can start poking on x86 with some help on how to hack grub bootconf
[10:44] <asac> sure take your time
[10:48] <ogra_> mvo, hmm, could it be that you made the gap at the start of the disk smaller when you dropped the 4th partition in u-d-f ?
[10:48] <ogra_> that would explain why boot gets appended at the end
[10:49] <ogra_> hmm, but looking at the numbers there seems to be enough space
[10:59] <mvo> ogra_: with sudo DEBUG_DISK=1 i see http://paste.ubuntu.com/14694839/ which looks like the partitions are initialized in hte right order, the sorting looks suspicious
[10:59] <ogra_> well, the sorting should just align the numbering with physical position
[11:00] <ogra_> you would have tzo break before the sorting and check the image with sgdisk to see where they physically are
[11:00] <ogra_> but i'm pretty sure boot is at the end already
[11:01] <ogra_> i wonder if it would complain if there is already a boot partition ... could it be that you created it already when this runs ?
[11:03] <mvo> ogra_: yeah, its all a bit myserious - just to double check what it should look like: *first* the rawPartitions and then ours? or *first* ours and then the raw ones?
[11:03] <ogra_> mvo, how about a quick HO
[11:03] <LefterisJP> hey guys if I want to have a python binary using PyYaml available in my pass what's the right way to go about it using snapcraft?
[11:04] <LefterisJP> I have this:   mybinary:
[11:04] <LefterisJP>     plugin: python2
[11:04] <LefterisJP>     python-packages:
[11:04] <LefterisJP>       - PyYAML
[11:04] <LefterisJP> But where should I specify that this is only to be used by a simple python file which should go to the bin/ directory of the final snap?
[11:04] <LefterisJP> It seems that the source attribute would expect a directory
[11:06] <noizer> ogra_ for wat should i use docker on snappy?
[11:06] <noizer> ogra_ or what is meant to be used?
[11:06] <ogra_> mvo, the final order needs to be: all gadget partitions -> system-boot -> writable .... the creation order differs though
[11:07] <ogra_> noizer, for whatever you like
[11:07] <mvo> ogra_: sure, HO is fine.  so what ensures the final order?
[11:08] <ogra_> i mean ... obviously for running apps in containers :)
[11:08] <ogra_> mvo, the physical position ... that is what the sgdisk sorting uses afaik
[11:08] <noizer> ogra_ but snaps ar already containered but for what is there than an advantage to use docker?
[11:08] <ogra_> mvo, https://plus.google.com/hangouts/_/canonical.com/gadget
[11:08] <ogra_> noizer, dunno, even more containment ?
[11:10] <noizer> ogra_ ok
[11:10] <noizer> :D
[11:12] <noizer> ogra_ so when im making a docker vm on an other ubuntu then it can be ran on snappy?
[11:12] <noizer> so its then mutch easier to port to other linux distro's?
[11:26] <noizer> ogra_ how can i install snapcraft 2.0 on a raspberry pi
[11:27] <ogra_> noizer, in xenial images you can enable the classic dimension and use a container
[11:29] <noizer> Will it work on a Ubuntu Mate 16.04 ogra_
[11:29] <noizer> ?
[11:29] <ogra_> sure
[11:30] <ogra_> but why not use it on your snappy directly ?
[11:31] <noizer> hmmm but how can i develop easily on snappy?
[11:31] <ogra_> read above
 noizer, in xenial images you can enable the classic dimension and use a container
[11:32] <noizer> Ok such as an user interface?
[11:32] <noizer> or istn't that it?
[11:32] <ogra_> sudo snappy enable-classic
[11:32] <noizer> ok i will try it
[11:32] <ogra_> ... that will create the container ...
[11:32] <kyrofa> Good morning
[11:33] <noizer> ok i will have a look
[11:39] <noizer> OK i did that but what are the concrete difference between that oter?
[11:39] <noizer> *other
[11:52] <ogra_> noizer, so if you now run "snappy shell classic" you are in a normal ubuntu 16.04 and can use apt to install snapcraft and build your packages
[11:54] <ogra_> noise][, the advantage is that this container is fully based on the readonly snappy rootfs, it only extends it by the missing pieces to get a normal apt based ubuntu
[11:54] <ogra_> err
[11:54] <ogra_> sorry
[11:54] <ogra_> (didnt notice he left)
[12:05] <sergiusens> good morning
[12:05] <kyrofa> Morning sergiusens :)
[12:05] <Lefteris`> morning
[12:06] <ogra_> moin
[12:06] <Lefteris`> hey guys how can I have a simple python binary which depends on a pypi package with snapcraft? The python plugin seems to expect you to give a directory and build a whole package.
[12:09] <kyrofa> Lefteris`, I'm not super familiar with python packaging, but is that something you can use requirements.txt for?
[12:09] <sergiusens> kyrofa, oh, git guy :-) Heeeeello
[12:09] <kyrofa> sergiusens, what's up?
[12:09] <sergiusens> kyrofa, how do you think this will merge https://github.com/ubuntu-core/snapcraft/pull/273 ?
[12:10] <kyrofa> sergiusens, looks fine to me. Are you concerned because it's not rebased?
[12:11] <sergiusens> kyrofa, nah, just wondering what will happen to the first commit which is already in master
[12:11] <kyrofa> sergiusens, oh, I didn't notice that
[12:12] <kyrofa> sergiusens, so he built this feature on another, eh?
[12:13] <kyrofa> sergiusens, my initial reaction is to expect a conflict. But github isn't whining about it
[12:13] <didrocks> it's the same commit id
[12:13] <didrocks> so no conflict, it will be like if he forked later on
[12:14] <didrocks> (basically, on the graph, there will be 2 "merges commit" with just one branch alongside)
[12:15] <Lefteris`> kyrofa: I have a simply .py file that I want to be executable and part of my snap and depends on PyYaml. Any idea what's the best way to achieve this? From what I see in snapcraft, both requirements.txt and python-packages in yaml will work. Adding the dependency is not my problem. My problem is how to specify that my python file should be what I want as the final binary and depending on PyYaml.
[12:17] <Lefteris`> I got this:   configurator:
[12:17] <Lefteris`>     plugin: python2
[12:17] <Lefteris`>     python-packages:
[12:17] <Lefteris`>       - PyYAML
[12:18] <Lefteris`> If I add the location of my python file as source then it says it expects a directory. So I assume it expects me to have a custom made python package with a setup.py as the source attribute. Can't I just give a simple python script in some way?
[12:19] <sergiusens> didrocks, so if he would have created the PR in the future, it would only be one id?
[12:19]  * sergiusens will just hit merge
[12:19] <didrocks> sergiusens: exactly!
[12:19] <kyrofa> sergiusens, indeed, tested locally as well
[12:19] <kyrofa> Thanks didrocks :)
[12:19] <didrocks> yw ;)
[12:19] <sergiusens> didrocks, kyrofa seems to just be a presentation problem I guess
[12:19] <sergiusens> well, I consider it a presentation problem, others might not ;-)
[12:19] <kyrofa> sergiusens, yeah, I wish github would update
[12:20] <sergiusens> or just tell me it is already in master, it is so smart about everything else :-P
[12:20] <didrocks> yeah, github doesn't "refresh" the list of commits not included in master
[12:20] <didrocks> it should IMHO, if the hash matches
[12:20] <kyrofa> didrocks, nor the diff
[12:20] <kyrofa> didrocks, agreed
[12:20] <sergiusens> mvo, btw, mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/278
[12:20] <kyrofa> didrocks, I see that change happening twice and my first conclusion is "conflict"
[12:20] <didrocks> (but then, you need to ensure that the hash order is the same)
[12:21] <sergiusens> kyrofa, but same id
[12:21] <sergiusens> right
[12:21] <didrocks> disclaimer: I'm probably lagging as being on 4G (in the TGV to Brussels)
[12:22] <kyrofa> Lefteris`, sorry, I'm not ignoring you :)
[12:23] <didrocks> you know, even if the hash is different, but the diff is the same, git is smart enough to do a silent reconciliation
[12:23] <didrocks> (but then, you have an additional commit)
[12:23] <kyrofa> didrocks, but the additional commit is gross :P
[12:23] <didrocks> heh, yeah ;)
[12:26] <kyrofa> Lefteris`, I think you need two parts here
[12:26] <kyrofa> Lefteris`, one part that uses the python2 plugin and the requirements.txt, and another part that uses the copy plugin to put your script in the right place
[12:26] <kyrofa> Lefteris`, then declare your script as the binary
[12:27] <kyrofa> Lefteris`, make sense?
[12:28] <Lefteris`> kyrofa: yeah it does make sense, and this is what I was doing right now, but seems kind of dirty
[12:28] <Lefteris`> would be nice if we the python plugin could allow you to do that withou involving the copy plugin
[12:29] <kyrofa> Lefteris`, yeah it's kinda made for a project with a setup.py or something
[12:29] <kyrofa> Lefteris`, would that be easier? Have the setup.py install your script?
[12:29] <diwic> Ok, I need pulseaudio to access /run/udev in order to scan for sound cards. I was trying by adding "security-overrides: read-paths: [/run/udev]" but it looks like this is not working, and that the feature might not even be implemented...?
[12:30] <kyrofa> Lefteris`, otherwise, if we added the ability to place random scripts wherever, we just duplicated the copy plugin :P
[12:31] <Lefteris`> kyrofa: hmmm maybe the copy plugin would make more sense, don't want to have separate directory and setup.py for no reason
[12:31] <kyrofa> diwic, I think it's just security-override (singular)
[12:31] <Lefteris`> let me try it out :D
[12:31] <sergiusens> kyrofa, did you already fix this https://bugs.launchpad.net/snapcraft/+bug/1539247 ?
[12:32] <kyrofa> sergiusens, no. That reflects the current state
[12:32] <sergiusens> kyrofa, great, I wish it were automatic
[12:32] <sergiusens> didrocks, what was the tool jono showed?
[12:32] <diwic> kyrofa, right. It was right in the snap, I just made a typo on IRC
[12:32] <sergiusens> the trello but for github
[12:32] <kyrofa> sergiusens, it should be! Let's write a launchpad script and plug it into travis
[12:33] <kyrofa> diwic, oh darn :P
[12:33] <kyrofa> diwic, but I know read-paths works, since we have an example for it
[12:34] <didrocks> sergiusens: ah, one sec, looking in my history
[12:34] <kyrofa> diwic, https://github.com/ubuntu-core/snapcraft/blob/master/examples/mosquitto/snapcraft.yaml
[12:34] <diwic> kyrofa, okay - how does wildcards work here? If I do /run/udev, does that include /run/udev/dir1/dir2/file3 ?
[12:34] <kyrofa> diwic, no I don't believe so
[12:34] <Lefteris`> sergiusens: could it be https://waffle.io/ ?
[12:34] <kyrofa> diwic, you need some asterisks
[12:35] <kyrofa> diwic, it's apparmor
[12:35] <Lefteris`> This is what comes to my mind when I think of "trello for github"
[12:35] <diwic> kyrofa, hmm, so if I want to give read access to /run/udev and everything below that?
[12:35] <didrocks> sergiusens: yeah, it's waffle.io
[12:35] <kyrofa> diwic, /run/udev/** I _think_
[12:36] <didrocks> thanks Lefteris` :)
[12:36] <diwic> kyrofa, thanks, will try
[12:36] <kyrofa> sergiusens, or... you know... we could just use gitub
[12:37] <kyrofa> Or even github
[12:37] <diwic> kyrofa, and now that I've changed that, can I just write "stage" to parts/pulseaudio/state to avoid a full rebuild of PulseAudio ?
[12:37] <diwic> or is there some smarter way?
[12:37] <kyrofa> diwic, so you've completely build a .snap, and all you've changed is the YAML?
[12:37] <sergiusens> kyrofa, with waffle.io ;-)
[12:38] <kyrofa> sergiusens, oh... yeah that would be epic
[12:38] <diwic> kyrofa, yes, I've just changed /run/udev to /run/udev/** in snapcraft.yaml
[12:38] <kyrofa> sergiusens, although then my LP karma would start dropping
[12:39] <kyrofa> sergiusens, what is the best solution in Snapcraft 2 for diwic's problem without --force?
[12:41] <kyrofa> sergiusens, also, I vote we use waffle.io just because of firefly now
[12:47] <kyrofa> diwic, trying to run build again won't hurt anything, but I imagine it will probably say "already built"
[12:47] <sergiusens> kyrofa, edit the parts/<part-name>/state file I guess
[12:47] <kyrofa> diwic, in which case you can at the very lease edit the... yeah
[12:50] <kyrofa> diwic, open the parts/<part>/state file and change the state to "build" and run snapcraft snap again
[12:51] <kyrofa> diwic, we're currently working on a --force option that will do that for you, but we're still in the design phase
[12:54] <diwic> kyrofa, right, that's what I thought
[12:56] <noizer> kyrofa and orga_ where can I find more information about the classic dimension or what is is the difference with the normal snappy?
[12:56] <diwic> kyrofa, actually, I don't think I need to do that. Just running "snapcraft snap" will update snap/meta/*.yaml accordingly
[12:57] <kyrofa> diwic, ah! Good catch!
[12:57] <kyrofa> diwic, you just hit the special case of only modifying the YAML that gets directly copied to other YAML :P
[12:57] <diwic> kyrofa, next question. How do I allow it to talk to the system dbus?
[12:58] <sergiusens> kyrofa, are you getting rid of the roscore plugin today?
[12:58] <diwic> I expect bluetoothd to be there, so can't do bluetooth audio without it
[12:58] <kyrofa> diwic, last I knew that needed custom security policies... I'm honestly not sure how one is supposed to do that in 16.04. sergiusens?
[12:59] <kyrofa> sergiusens, no I'm still on the store stuff. Why, you really want it gone eh?
[12:59] <kyrofa> :P
[12:59] <sergiusens> kyrofa, yeah, remove the qml one while at it ;-)
[12:59] <kyrofa> sergiusens, I can do that. No replacement?
[13:00] <kyrofa> sergiusens, bad enough to pause the store stuff for a little bit?
[13:00] <sergiusens> diwic, I will invoke tyhicks if you need either a security-policy, security-template or security-override
[13:00] <sergiusens> kyrofa, nah
[13:01] <kyrofa> sergiusens, next task then, you got it :)
[13:01] <diwic> thanks. I'll double check with awe when he gets online to make sure bluetoothd is where it's supposed to be
[13:01] <sergiusens> kyrofa, just roscore, the qml thing is political at this point :-P
[13:01] <kyrofa> sergiusens, hahaha
[13:02] <sergiusens> kyrofa, it even depends on something we don't have
[13:02] <kyrofa> sergiusens, that sounds problematic
[13:02] <kyrofa> sergiusens, oh, mir?
[13:02] <sergiusens> kyrofa, yeah ;-)
[13:02] <kyrofa> sergiusens, duh
[13:03] <noizer> ogra_ about the classic how can we see it in snappy
[13:03] <kyrofa> sergiusens, yeah I agree with you though. The presence of the plugin indicates first-class support
[13:03] <kyrofa> And... it's not
 noizer, the advantage is that this container is fully based on the readonly snappy rootfs, it only extends it by the missing pieces to get a normal apt based ubuntu
[13:03] <ogra_> you left to early :=
[13:03] <ogra_> :)
[13:04] <ogra_> noizer, just use "snappy shell classic"
[13:04] <kyrofa> sergiusens, if a dev needs it they can include it in-tree
[13:04] <ogra_> then you can spt-get update and apt-get install snapcraft and use it there
[13:04] <ogra_> *apt-get
[13:04] <kyrofa> sergiusens, anyway, let me know
[13:05] <noizer> ogra_ ok then can i get there than an User interface so I can develop faster?
[13:05] <ogra_> user interface ?
[13:06] <ogra_> it gives you a place to build your snaps in
[13:06] <noizer> ogra_ hmmm I now developing on lubuntu for Raspberry Pi but now i want to install it on snappy but how can i do that the easiest way
[13:06] <ogra_> oh, you dont have a PC to work with ?
[13:07] <sergiusens> command line user interfaces ftw :-)
[13:07] <ogra_> :D
[13:08] <noizer> ogra_ hahah ok thats hard then but can i develop on my lubuntu en scp it to the classic ubuntu
[13:09] <ogra_> i usually develop in a bzr branch ... so i can push from the PC, pull from classic and then just run snapcraft snap, install and test the package
[13:10] <ogra_> (such a process makes you automatically backup your code too :) )
[13:11] <kyrofa> ogra_, and results in this https://xkcd.com/1296/
[13:11] <ogra_> (indeed, if you prefer git thats the same )
[13:11] <noizer> i uses git :p ok intresting but to make the yaml for the software thats a hard part i think
[13:11] <ogra_> kyrofa, lol, yeah
[13:12] <ogra_> making the yaml for the first time is hard ... but having a pretty giu around your editor wont change that ;)
[13:12] <kyrofa> You'll get the hang of it noizer !
[13:13] <ogra_> yeah
[13:13]  * ogra_ hated yaml in the beginning .... after getting used to it i actually like it a lot
[13:13] <noizer> hah thats a fact kyrofa ogra_
[13:13] <noizer> ok i will try to push it to my ubuntu classic
[13:14] <noizer> and hopefully it will work
[13:15] <noizer> for snapcraft installation is it sudo apt-get install snapcraft
[13:15] <noizer> but when i type it it fails
[13:16] <noizer> should i need to add the ppa,
[13:16] <noizer> ?
[13:16] <kyrofa> noizer, how does it fail?
[13:17] <noizer> kyrofa http://pastebin.com/KVNjkVnE
[13:17] <kyrofa> noizer, do `sudo apt-get update` first
[13:19] <diwic> btw. Can I change the contents of either one of the wrap scripts somehow? I e, to be able to start pulseaudio with some switches (such as --path-to-something=/snaps/pulseaudio/weirdcharacters/somewhere) ?
[13:19] <diwic> or to set an environment variable
[13:19] <kyrofa> diwic, you can pass those things in the binary/service exec line
[13:19] <asac> sergiusens: so got a good idea how to make a nice global parallel and verbose option available? maybe just hook those to the top level main.py somehow?
[13:19] <kyrofa> diwic, in the YAML
[13:20] <diwic> kyrofa, but at that point I don't know the "weird characters"
[13:20] <kyrofa> diwic, remember the environment variables though-- don't hard-code /snaps/etc.
[13:20] <asac> e.g. not in build.py
[13:20] <kyrofa> diwic, ah, you don't know the environment variables then!
[13:20] <kyrofa> diwic, double-check-- you're on rolling?
[13:21] <kyrofa> diwic, oh, /snaps, yes you are
[13:22] <diwic> kyrofa, I am on 16.04. Say that I want to add one environment variable, e g XDG_RUNTIME_DIR=$SNAP/tmp/somedir
[13:22] <kyrofa> diwic, so you can use the $SNAP environment variable, which will point to the /snaps/pulseaudio/version
[13:22] <kyrofa> diwic, yeah, just put it on the command line like you would in the shell
[13:23] <diwic> kyrofa, ok, so that will end up being a long line I expect, but that's ok :-9
[13:23] <diwic> :-)
[13:23] <kyrofa> diwic, the alternative is to write a shell script to be your binary instead, which is perfectly acceptable if you prefer it
[13:24] <diwic> just three wrappers to start the executable ;-)
[13:24] <kyrofa> diwic, welcome to Snapcraft. We wrap your wrappers so we can wrap them
[13:25] <ogra_> its like christmas and your birthday at once !
[13:25] <asac> sergiusens: think i would keep the getter/setter parts for those flags in common.py and just drop the build.py parts from my cleaned patches... in that way you can land the CLI wiring later. soudns good?
[13:25]  * diwic renames it to wrapcraft
[13:26] <asac> ppisati: where can i find the definite list of minimal patches and config flags that are super essential for a runnign snappy system?
[13:26] <asac> "minimal and super essential"
[13:26] <asac> lol
[13:27] <ogra_> asac, no idea how recent that is http://people.canonical.com/~ppisati/snappy_config/#
[13:28] <ogra_> asac, and wrt pathes ... "the latest apparmor" is a rule of thumb
[13:28] <ogra_> *patches
[13:30] <ppisati> asac: kernel version?
[13:31] <asac> ppisati: 4.4?
[13:31] <asac> or if we have a lookup table for each main version that would be nicer even
[13:31] <asac> the latest apparmor is vague
[13:31] <sergiusens> asac, making it global is easy
[13:31] <noizer> ogra_ sorry for the many question but how do I instal it best NGinx and UWSGI?
[13:31] <asac> for someone coming from outside
[13:32] <asac> sergiusens: ok with you if i move it to main.py from build.py? think those flags could also be honoured by some other lifecycle rules
[13:32] <asac> not all of course
[13:32] <asac> buut install maybe could pick it up for some plugins
[13:32] <asac> or even pull :)\
[13:32] <kyrofa> sergiusens, did you annotate the 2.0.1 tag?
[13:32] <ogra_> noizer, for what exactly ?
[13:32] <ogra_> *for doing
[13:33] <noizer> for running a webpage
[13:34] <diwic> kyrofa, jftr, you can't put things like "XDG_RUNTIME_DIR=$SNAP/tmp pulseaudio" as your binary, "snapcraft snap" will fail with "file not found: XDG_RUNTIME_DIR=$SNAP/tmp"
[13:34] <sergiusens> kyrofa, yes
[13:34] <noizer> my snap exist about html page and some backend modules etc
[13:34] <sergiusens> kyrofa, oh, annotate, no https://github.com/ubuntu-core/snapcraft/tags
[13:34] <noizer> and running with flask ogra_
[13:35] <vir17> hi guys, i need help for a .yaml file, after the yesterday failures I try today to create a simple first app (a python helloworld)  my code is here: https://github.com/lmbn/hellosnappy   and my .yaml file http://pastebin.com/j2hpwDri , what I dont know is what I have to add in my .yaml file so after the installation to have my app into "apps/bin" and run it  (sorry for the newbie question)
[13:36] <ogra_> noizer, well, create a snapcraft.yaml that builds ngnix from source or use the copy plugin and ngnix as stage package to grab the deb binary (but then you might need to adjust the config to match all the changed paths)
[13:36] <sergiusens> if it is just a webpage, write a simple server with go
[13:36] <kyrofa> diwic, ah, right, I'm sorry I misled you! You'll have to create a wrapper script, then
[13:36] <noizer> ogra_ sergiusens its not a simple webpage :s
[13:36] <ogra_> noizer, right, what sergiusens said ... there is even an example webserver (in 5 lines or so)
[13:38] <sergiusens> noizer, you said html, I replied in response to that ;-)
[13:38]  * sergiusens goes for a quick run
[13:38] <kyrofa> vir17, you need to specify `binaries` there somewhere
[13:38] <noizer> sergiusens ok sorry :p
[13:39] <kyrofa> vir17, like this: https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/py2-project/snapcraft.yaml#L4
[13:39] <noizer> ok i will try now to make my yaml file
[13:40] <kyrofa> sergiusens, I need to babysit for a bit this morning, I'm afraid I need to miss standup, I'm sorry!
[13:41] <diwic> kyrofa, actually XDG_RUNTIME_DIR is perhaps a bigger question; should we set that by default to something inside the snap or user? It seems reasonable for it to point to something writable by default IMO.
[13:42] <ogra_> diwic, i think ted brought that up before .... thgere was a discussion somewhere
[13:42] <ogra_> tedg i mean
[13:42] <sergiusens> kyrofa, elopio let's just cancel and do the planning then
[13:42] <kyrofa> sergiusens, okay, sounds good
[13:43] <kyrofa> sergiusens, go for your run :)
[13:44] <kyrofa> diwic, probably user-specific, so I suggest SNAP_USER_DATA
[13:44] <diwic> ogra_, ok; I'm going to try to work around it for the time being, if you're aware that there's an issue
[13:44] <ogra_> not on the level we have worked on yet .... i am awarwe it will be an issue in graphical envs and desktop context
[13:45] <diwic> ok
[13:45] <ogra_> IoT and server ... not so much
[13:46] <ogra_> lets ask tedg once he is around what came out of that discussion
[13:46] <ogra_> i know he started one
[13:48] <mvo> ogra_: I think I know now now what is going on with sgdisk, when you tell it to create a partition with num 0 and start 0 it will find the first free partition and then looks for the first available sector in the largest free area on disk. this happens to be (by pure chance) that part *after* writable once we reach partition 7 :) so mystery solved, I will add the offset and we need to continue with that and force sgdisk to write to the numbers we
[13:48] <mvo>  give it
[13:48] <mvo> ogra_: that was hard work!
[13:49] <ogra_> mvo, it was ! thanks so muchj !
[13:53] <vir17> thanks kyrofa  i will try
[13:58] <olli> hey ogra_, did you have a chance to work on that Pi2 bug for ectors?
[13:58] <ogra_> olli, i worked on getting the dragonboard images ready, Pi2 firmware update is on my list
[13:59] <ogra_> (i guess they are eaqually important :) )
[14:00] <mvo> ogra_: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz should have the right layout now
[14:00] <mvo> ogra_: would be nice to know if uboot is still broken
[14:00] <ogra_> mvo, pulling now
[14:00] <mvo> \o/
[14:06] <olli> ogra_, thx!
[14:07] <ogra_> mvo, u-boot still broken :/
[14:08] <ogra_> mvo, eeek
[14:08] <ogra_> and all bootloader partitions now have an x appended to the name
[14:16] <mvo> ogra_: uff
[14:16] <ogra_> gimme a sec ... the u-boot issue might actually be the naming issue
[14:17] <ogra_> dding my uboot in place didnt work either until i dropped the x from bootx in the partition name
[14:17] <ogra_> i'm just re-flashing from scratch to see if just fixing the name helps
[14:17] <mvo> ogra_: wait, let me make a new image
[14:17]  * ogra_ wants faster dd !!!
[14:17] <mvo> ogra_: godd!
[14:18] <mvo> ogra_: and a scandisk extreme
[14:18] <ogra_> well, that wont make faster bytes i gues :)
[14:18] <mvo> ogra_: let me make a new image
[14:18] <ogra_> *guess
[14:18] <mvo> ogra_: sure it will ;)
[14:18] <mvo> ogra_: ok, maybe not, but *progressbar*
[14:18] <ogra_> \o/
[14:19] <ogra_> fixing the name is enough
[14:19] <ogra_> bah
[14:19] <ogra_> but i end up in an initrd shell now
[14:19] <mvo> ogra_: oh, but the kernel boots? that is the wrong kernel :)
[14:19] <ogra_> insmod: can't read './lib/modules/*/kernel/fs/squashfs/squashfs.ko': No such file or directory
[14:19] <mvo> ogra_: still the old one from your dir, not the kernel from pablo
[14:20] <ogra_> ah, i thought you used the arm64 one frrom the archive
[14:20] <ogra_> mine should boot, but has obviously no squashfs enabled :)
[14:20] <mvo> ogra_: I'm slow
[14:20] <ogra_> so lets switch to paolos latest kernel and we should be golden
[14:21] <ogra_> this looks very good already :D
[14:21] <mvo> ogra_: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/20 is the new syntax, if you give the raw-partition a "pos" paramter it will put it there and all following right behind (unless you use pos again)
[14:21] <mvo> ogra_: sweet, I will update the kernel snap next
[14:21] <ogra_> mvo, but pos isnt required for all of them ? thats good then
[14:22] <ogra_> mvo, dont forget you need to switcch to the other dtb
[14:22] <ogra_> mvo, "apq8016-sbc"
[14:23] <mvo> ogra_: yeah, pos is only needed for the first one if they are all aligned
[14:23] <ogra_> great
[14:25] <kyrofa> Chipaca, do you have any favorite python3 progress indicator libs? Or do you typically roll your own?
[14:39] <sergiusens> kyrofa, if you pick the right implementation/module you don't need to worry about vte/vt sizes
[14:39] <kyrofa> sergiusens, yeah that's exactly my concern
[14:39] <kyrofa> sergiusens, researching options
[14:39] <sergiusens> mvo, what was the pbar used for snappy when it was python?
[14:40] <mvo> sergiusens: let me look
[14:40] <mvo> sergiusens: and also look at your branch, sorry, full day
[14:40] <mvo> sergiusens: I think it was a nice progress bar
[14:41] <sergiusens> mvo, or point me to the sources, I can't find them; yeah iirc barry helped out on that so I guess it has good qa too :-)
[14:41] <sergiusens> and indeed it worked nicely
[14:42] <sergiusens> kyrofa, and this is for you http://whatthecommit.com/
[14:42] <tedg> ogra_: I never got anywhere with it, replied on the mailing list, to silence.
[14:42] <kyrofa> sergiusens, hahaha, awesome
[14:43] <ogra_> tedg, well, now you have a companion in diwic :) perhaps you can revive the thread
[14:44] <tedg> diwic: You should reply, see if you can get responses. :-)
[14:44] <tedg> diwic: If you do, I have a bunch of other questions you can ask.
[14:45] <mvo> sergiusens: I think it was python3-progressbar but I can't find the old python source right now :/ let me look harder
[14:47] <mvo> sergiusens: yeah, python3-progressbar it is
[14:47] <sergiusens> mvo, great, thanks
[14:47] <sergiusens> mvo, do you have links to the old code anywhere btw?
[14:47] <sergiusens> kyrofa, python3-progressbar
[14:48] <kyrofa> sergiusens, I've read that SIGWINCH throws it off
[14:49] <kyrofa> sergiusens, but I'm playing with it now
[14:49] <mvo> sergiusens: I think it was mostly a frontend for click back in the day, here is the acquire bits https://code.launchpad.net/~mvo/click/progressmeter/+merge/243498
[14:49] <mvo> are
[14:49] <diwic> tedg, what mailing list
[14:49] <diwic> ?
[14:50] <tedg> diwic: I think that conversation was on snappy-devel
[14:51] <diwic> ok
[14:54] <mvo> ogra_: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz has an updated kernel now
[14:54] <ogra_> pulling
[14:55] <noizer> ogra_ can I scp it to the classic ubuntu?
[14:55] <ogra_> it ?
[14:56] <noizer> ogra_ some files
[14:56] <ogra_> (and i dont know, you can surely scp from inside the classic container)
[14:56] <ogra_> (or wget or whatever to pull stuff from somewhere remote)
[14:56] <noizer> ok xD
[15:00] <ogra_> reading canonical-dragon-linux.sideload_ILPMLfIRBYVH.snap/dtbs/msm8916-mtp.dtb
[15:00] <ogra_> ** Unable to read file canonical-dragon-linux.sideload_ILPMLfIRBYVH.snap/dtbs/msm8916-mtp.dtb **
[15:00] <ogra_> mvo, ^^^^
[15:01] <ogra_> it needs a name change in the gadget/oem snap too
[15:02] <mvo> ogra_: oh, yeah, I knew there was soemthing else
[15:03]  * ogra_ adjusts the env manually
[15:03] <wxl> where can i get the latest ubuntu-device-flash for trusty?
[15:04] <ogra_> mvo, bah, that kernel is broken
[15:04] <ogra_> ppisati, ^^^^
[15:04] <ogra_> [    6.029908] mmc1: error -110 whilst initialising SD card
[15:04] <ogra_> [    6.135706] mmc1: Reset 0x1 never completed.
[15:04] <ogra_> hangs hard here
[15:04] <ppisati> ogra_: which one did you use?
[15:05] <ogra_> https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.2.0-2009-generic-dragon410c_4.2.0-2009.9~15.10_arm64.deb
[15:05] <ogra_> the one you linked from your last mail
[15:05] <ppisati> ogra_: ah, but that's bad & broken
[15:06] <ogra_> ppisati, not in my kernel buiolds
[15:06] <ogra_> oh, you mean that binary :)
[15:06] <ogra_> yeah, obviously :)
[15:06] <mvo> is there a right one somewhere?
[15:07] <ogra_> mvo, well, given ppisati said it was uploaded i'd guess there is something in xenial-proposed we could fish out ?
[15:07] <ogra_> (but likely also missing squashfs until paolo lands that change)
[15:07] <mvo> ogra_: thats ok
[15:07] <ppisati> https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.2.0-2011-generic-dragon410c_4.2.0-2011.11_arm64.deb
[15:07] <ogra_> there you go :)
[15:07] <ppisati> ogra_: in the archive is
[15:08] <ppisati> linux-snapdragon
[15:08] <mvo> ppisati: ta
[15:08] <ogra_> mvo, we are >< *that* close :)
[15:09] <ppisati> if you want i have a deb image too
[15:09] <vir17> guys how can I fix this error: [Errno 13] could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'
[15:09] <ppisati> http://people.canonical.com/~ppisati/ubuntu_embedded/ubuntu-embedded-16.04-dragon410c.img.xz
[15:10] <vir17> ^^at snappy
[15:10]  * ogra_ needs some food ... brb
[15:10] <davmor2> snappy get ogra_ food......did it work?
[15:14] <ogra_> Error: "get" no such command
[15:14] <wxl> where would i file a bug against the snappy-dev ppa version of ubuntu-device-flash?
[15:16] <ogra_> just file it in general and mention the ppa version you use
[15:16] <wxl> k thx ogra_
[15:16] <ogra_> whats the issue ?
[15:17] <wxl> ogra_: can't build a generic_i386 image
[15:17] <ogra_> hmm, not sure you can at all
[15:17] <wxl> ogra_: is that new?
[15:17] <ogra_> i386 isnt actually in focus
[15:17] <wxl> i thought it was part of edge
[15:18] <ogra_> well, we never tested it
[15:18] <wxl> and for that matter that developer portal mentions using ubuntu-device-flash to get an i386 image
[15:18] <ogra_> an i doubt anyone has it on the plan to test/try it at all
[15:18] <wxl> it seems to suggest it's a supported possibility
[15:18] <wxl> then i guess we should file a bug against the developer portal, hm?
[15:18] <davmor2> ogra_: just remove the documentation bug fixed ;)
[15:18] <ogra_> well, does your arch not support 46bit ?
[15:18] <ogra_> err
[15:18] <ogra_> 64
[15:19] <wxl> ogra_: i have some machines that are i386 only, so i'd like to do some testing
[15:19] <ogra_> davmor2, yeah, i guess thats in order unless we want to start doing i386 ...
[15:19] <ogra_> up to now i386 hasnt been among the released and tested arches
[15:20] <wxl> your buggy "code" is here in the first bullet point https://developer.ubuntu.com/en/snappy/start/#try-x86
[15:21] <wxl> should you decide instead to support i386, let me know XD
[15:22] <ogra_> well, we might "support" it, ... as in ... we do build the parts to assemble something ... but it definitely isnt in the list of tested or released arches
[15:25] <mvo> ogra_: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz has an even more updated kernel now plus new dtb
[15:25] <ogra_> ok.gimme a bit to finish eating
[15:31] <mvo> sure
[15:40] <kyrofa> sergiusens, how would you feel about handling a keyboard interrupt a bit nicer?
[15:40] <noizer> ogra_ Hi i was testing snapcraft 2.0 but i tried to make a snap but it didn't work i typed just like in snapcraft 1.0 just snapcraft. but thats not the way anymore to make a snap
[15:40] <kyrofa> noizer, `snapcraft snap`
[15:41] <noizer> ok thx a lot
[15:43] <sergiusens> kyrofa, I wouldn't mind
[15:43] <kyrofa> sergiusens, I dunno... I feel like it might look a little more "polished"
[15:44] <sergiusens> kyrofa, oh, I said yes, change ;-)
[15:44] <kyrofa> sergiusens, hahaha
[15:44] <sergiusens> kyrofa, 'cancelled by user input' or something; maybe with smarts later on to rollback to a last known good state
[15:44] <kyrofa> sergiusens, okay :)
[15:44] <kyrofa> sergiusens, agreed
[15:45] <sergiusens> but the latter for later, we don't have the smarts for that
[15:46] <elopio> fgimenez: https://github.com/go-check/check/pull/76
[15:46] <ogra_> mvo, nope
[15:47] <ogra_> ** Unable to read file canonical-dragon-linux.sideload_ILPOPIVJLVGO.snap/dtbs/msm8916-mtp.dtb **
[15:47] <ogra_> reading canonical-dragon-linux.sideload_ILPOPIVJLVGO.snap/initrd.img
[15:47] <elopio> fgimenez: sorry, one of your reviews was a push I did wrong. You were asking there for the logger tests. This is fully covered in run_tests.
[15:47] <ogra_> mvo, seems it still uses the old uboot.env
[15:47] <elopio> once we move the logger out of check.go, we can add lower level tests specific to that package.
[15:47]  * ogra_ fixes by hand again
[15:48] <ogra_> mvo, and smae kernel bug :(((
[15:48] <ogra_> [    6.333797] mmc1: error -110 whilst initialising SD card
[15:48] <ogra_> [    6.439615] mmc1: Reset 0x1 never completed.
[15:49] <ogra_> and now paolo is gone ... :/
[15:49] <mvo> ogra_: *gar* mkenv was missing, I updated the .in but not the .env
[15:50] <ogra_> mvo, well, the kernel is broken anyway
[15:51] <mvo> ogra_: hrm, hrm, ok
[15:52] <ogra_> paolo has a img at people.canonical.com/~ppisati/ubuntu_embedded/ubuntu-embedded-16.04-dragon410c.img.xz i'll take a look if i can steal something from that
[15:52] <ogra_> he said it would work
[15:52] <ogra_> else i'mm just rebuild my own kernel with SQUASHFS=Y
[15:52] <ogra_> *i'll
[15:53] <ogra_> oh, wait, that could be a dtb issue ... i remember i had to fix something
[15:53] <mvo> ogra_: a dtb issue in what way?
[15:54] <ogra_> in that the SD controller was only initialized half
[15:55] <mvo> ogra_: ok, I'm away for some minutes but if you have something, please ping me via tg
[15:55] <ogra_> will do
[15:55] <mvo> JamesTait: just curious what the state of the snap.yaml support is, sorry for naging
[15:57] <ogra_> mvo, http://paste.ubuntu.com/14696129/
[15:58] <JamesTait> mvo, it's landed in SCA trunk (within the last hour), should be on Staging for me to QA; after that, just needs the work in click-reviewers-tools.
[16:00] <mvo> ogra_: oh, with that it works?
[16:01] <ogra_> mvo, yeah, it should ... i'll try to just use my dtb, not sure how much it its tied to the kernel version
[16:01] <JamesTait> mvo, jd-strand was looking at that, but he's off today, so it might not happen until Monday - it doesn't appear to be in the changelog for c-r-t trunk at least.
[16:02] <mvo> JamesTait: hm, ok. is c-r-t a blocker? i.e. it will just mean we loose  the checks but for manual review it would be ok?
[16:02] <mvo> JamesTait: or is this not the case?
[16:05] <ogra_> WHEEEE !
[16:06] <JamesTait> mvo, c-r-t currently doesn't understand snap.yaml, so squashfs snaps lacking package.yaml are assumed to be debclick packages.  c-r-t then barfs because DEBIAN/* files aren't present.
[16:06] <ogra_> ubuntu@localhost:~$ uname -a
[16:06] <ogra_> Linux localhost.localdomain 4.2.0-2011-generic-dragon410c #11-Ubuntu SMP Mon Jan 25 11:21:40 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
[16:06] <ogra_> ubuntu@localhost:~$ snappy list
[16:06] <ogra_> Name                   Date       Version      Developer
[16:06] <ogra_> canonical-dragon       2016-01-29 ILPOPIQWILRE sideload
[16:06] <ogra_> canonical-dragon-linux 2016-01-29 ILPOPIVJLVGO sideload
[16:06] <ogra_> ubuntu-core-arm64      2016-01-29 ILPOPJFVLUfH sideload
[16:06] <ogra_> mvo, ^^^
[16:06] <ogra_> :D
[16:06] <mvo> JamesTait: right, but that means it will warn, not block, right?
[16:06] <mvo> ogra_: wooah!
[16:07] <mvo> ogra_: what did you do?
[16:07] <ogra_> replace the dtb and hack the uboot.env for the proper name
[16:07] <mvo> JamesTait: what I am trying to get at is that it might be good enough for the few selected snaps we need to fix our unit tests to manually approve those :)
[16:07] <JamesTait> mvo, with that, I don't think there's an option to manually approve - I think that option only appears where we have a "REDFLAG" error (like we get when the package is a squashfs), not a complete failure.
[16:07] <mvo> JamesTait: aha, ok. then I misunderstood what is happening. thanks
[16:07] <ogra_> mvo, http://people.canonical.com/~ogra/apq8016-sbc.dtb
[16:08] <ogra_> grab that for the next image
[16:08] <mvo> ogra_: yes sir
[16:08] <ogra_> (and fix the uboot.env ;) )
[16:08] <mvo> ogra_: uboot.env got fixed ages^Wminutes ago ;)
[16:09] <ogra_> haha
[16:09]  * ogra_ checks if wlan will work
[16:13] <vir17> is there anything that I can do to allow the snappy to open tty ports?
[16:13] <vir17> I get this error
[16:13] <vir17>  [Errno 13] could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'
[16:14] <ogra_> mvo, bah, crap, so polos kernel doesnt include the wlan driver or any of the firmware for it
[16:14] <ogra_> no networking :/
[16:15] <ogra_> vir17, is that *on* snappy or on your PC trying to talk to snappy via serial ?
[16:15] <vir17> on snappy
[16:15] <ogra_> mvo, oh !
[16:16] <vir17> snappy try to talk to an arduino
[16:16] <ogra_> mvo, whatever creates your kernel snap has never run depmod ... i cant load modules and i cant run depmod either because of the readonly squashfs
[16:17] <ogra_> mvo, also you want all the firmware included in the kernel snap ... seems /lib/modules only has a few modules, there should be a few 100 MB of firmware files too
[16:17] <ogra_> (from linux-firmware and if available linux-image-extra )
[16:17] <mvo> ogra_: right, I think we can fix all this once the kernel hits the archive
[16:18] <ogra_> mvo, well
[16:18] <mvo> ogra_: this is more or less a hacked up kernel snap, the script is really build on top of what we get from the device tarball
[16:18] <ogra_> i'm not sure paolo can actually include the wlan firmware
[16:18] <ogra_> not sure about the licensing
[16:18] <mvo> ogra_: thats fine, if its available in some package. or are you saying we can't have the firmware in the archive at all?
[16:19] <ogra_> mvo, right
[16:19] <mvo> ogra_: new image with your fix uploaded
[16:19] <ogra_> trying
[16:20]  * ogra_ sighs ... i went through all these issues in december ... but only write down stuff for half of them,
[16:20] <ogra_> *wrote
[16:21] <ogra_> vir17, and you try to use that devicfe as "ubuntu" user from commandline ?
[16:21] <ogra_> or do you have a snap that tries to access it
[16:22] <vir17> ogra_:  I have a snap that sends a command through serial
[16:22] <vir17> tries to send a command
[16:22] <ogra_> vir17, well, then you need to define the permission to access this device in your snapcraft.yaml first
[16:22] <vir17> how I can do this?
[16:22] <ogra_> snaps cant just access devices or any files outside their confined area
[16:23] <vir17> is there any tutorial/documentation on how to do this?
[16:23] <ogra_> this changed a lot recently, so ui dont know exactly .... you were able to run the hw-assign command before after installing the snap to prevent access
[16:24] <ogra_> now there are capabilities and skills you need to define in the snapcraft.yaml ... but i didnt have any time to look into that yet
[16:25] <vir17> ogra I cannot use now the hw-assign?
[16:25] <ogra_> not in 16.04 ... it should still be in the old 15.04 images
[16:26] <ogra_> (bot it is obsolete so better get familiar with the new way)
[16:26] <ogra_> *but
[16:26] <vir17> at the moment i have the old image
[16:26] <ogra_> well, then hw-assign should work
[16:26] <vir17> how the command was exactly
[16:26] <vir17> snappy hw-assign?
[16:27] <noizer> ogra_ ok i made a snap in the classic. How can i install it then on my snappy?
[16:27] <ogra_> noizer, iirc /home/ubuntu is a shared dir
[16:28] <ogra_> so exit the classic shell and you should see it
[16:28] <ogra_> in the homedir
[16:28] <noizer> oooh ok niceeee
[16:31] <noizer> ogra_ what was the parameters to install the snaps?
[16:31] <ogra_> --allow-unauthenticated
[16:33] <vir17> ogra_: thanks it works now :)
[16:33] <ogra_> :)
[16:33] <vir17> in the new image when you said "try to use this device as "ubuntu" user"
[16:34] <vir17> you mean with the classic shell
[16:34] <vir17> ?
[16:34] <ogra_> nope, just via ssh
[16:34] <ogra_> or serial console
[16:34] <vir17> serial console from snappy?
[16:34] <ogra_> to snappy
[16:35] <ogra_> mvo, works ! (execpt for thze missing modules.dep and wlan)
[16:35] <vir17> ok, just asked to check if there is another to way to do what I am thinking
[16:36] <vir17> snappy to talk to arduino
[16:36] <ogra_> mvo, the modules.dep should really be fixed in any case ... you just need to run depmod with the right params before mksquashfs
[16:36] <dholbach> all right my friends - I call it a day - see you all on Monday again - have a great weekend! :)
[16:36] <ogra_> vir17, no,. that seems fine
[16:36] <vir17> :0
[16:36] <vir17> :)
[16:37] <ogra_> dholbach, you too ... any enjoy the last bits of your jetlag ;)
[16:37] <dholbach> hehe :)
[16:37] <dholbach> will do
[16:37]  * ogra_ too
[16:38] <vir17> ogra_: should we expect new tutorials from the new image? because as you said it is good to start developing for the new snappy
[16:38] <ogra_> there will be, yes
[16:38] <vir17> :)
[16:38] <ogra_> it is mainly all snapcraft nowadays though
[16:38] <vir17> what do you mean?
[16:39] <ogra_> well, all you need in the new world is snapcraft and a properly created snapcraft.yaml
[16:39] <ogra_> (and snapcraft to build your snap indeed)
[16:39] <ogra_> there is no extra tools like hw-assign anymore etc
[16:40] <ogra_> the developer life turns into a single yaml file ;)
[16:44] <mvo> ogra_: yeah, lets talk on monday
[16:44] <vir17> hahaha
[16:44] <vir17> sounds scary!
[16:44] <vir17> hahhaha
[16:45] <mvo> ogra_: ideally this would all be par tof the device.tar.gz like on the rpi2 and the bbb
[16:45] <ogra_> mvo, yeah
[16:49] <ogra_> mvo, mailed a status to the ML
[16:49] <mvo> great
[16:50] <kyrofa> sergiusens, elopio my wife isn't home yet-- can we push the planning back an hour?
[16:51] <ogra_> hmm, no HDMI out ... i guess we need to fix that one too
[16:51] <ogra_> oh !
[16:51] <ogra_> there is ... but only for login indeed
[16:51] <ogra_> great
[16:52] <ogra_> lol... but no USB kbd without module support :P
[16:55] <sergiusens> kyrofa, I don't mind, elopio ?
[16:56] <kyrofa> Sorry guys
[17:00] <sergiusens> kyrofa, no worries
[17:03] <elopio> kyrofa: I can't an hour later. I need to pick up some sd cards before the store closes, and have a date to have lunch with my mother at that time.
[17:03] <elopio> can you do the planning without me?
[17:06] <kyrofa> sergiusens, elopio what if we do it on Monday this once?
[17:08] <kyrofa> pindonga, do you know if the store supports chunked uploads?
[17:09] <LefterisJP> guys I got a pretty basic question! So far I have been using an Ubuntu VM to develop for my Ubuntu core target machine. My host is ArchLinux. Is there any possible, conceivable way to build snaps (basically use snap and snapcraft tools) from another linux distro? It would save me from firing up a VM all the time I work on Ubuntu Core.
[17:09] <sergiusens> kyrofa, elopio lets do it in 30 if possible and if not we'll see what to do
[17:10] <ogra_> LefterisJP, why dont you just build *on* ubuntu-core instead ?
[17:10] <ogra_> it has a mode for that
[17:10] <LefterisJP> ? :o
[17:10] <LefterisJP> first time I hear of that
[17:11] <ogra_> sudo snappy enable-classic
[17:11] <ogra_> snappy shell classic
[17:11] <kyrofa> sergiusens, alright
[17:11] <ogra_> and you are in a container that allows you to use apt and friends to build snaps
[17:11] <LefterisJP> ok that's interesting
[17:11] <LefterisJP> :)
[17:12] <ogra_> then just apt-get update ... apt-get install snapcraft and you are ready to go
[17:12] <ogra_> the homedir is shared so if you place your generated snaps in 7home/ubuntu in the container you will find them later in snappy
[17:13] <ogra_> (for sideloading)
[17:14] <LefterisJP> ok I am definitely gonna try that. But still the question stands, do you think it would be possible to try and port snappy tools to another distro?
[17:14] <ogra_> not sure
[17:15] <ogra_> it makes a lot of use of archive packages to get build dependencies in place etc
[17:15] <ogra_> while i could imagine it wouldnt be to hard to port to debian, i think arch is a bit different
[17:16] <kyrofa> LefterisJP, Snapcraft is just Python. If you get the right dependencies on arch there's no reason it shouldn't work
[17:16] <ogra_> kyrofa, even the plugins that apt-get install build deps etc ?
[17:16] <kyrofa> ogra_, oh yeah... that
[17:16]  * ogra_ doubts it is that easy with a different package manager
[17:17] <ogra_> debian will be an easy target to port to though
[17:17] <kyrofa> LefterisJP, ignore me
[17:17] <ogra_> non deb distros will surely be possible ... but will need a lot extra work
[17:18] <core_t> what do you get if you #reinvent debian?
[17:21] <LefterisJP> kyrofa: I know snapcraft is python, was talking about the rest. Well let's see .. for now will try the way ogra_ suggested but will also look into eventually allowing me to work from my host machine ... I would really love the convenience :)
[17:26] <ogra_> LefterisJP, well, you should be able to use an ubuntu chroot on your host ... definitely more convenient than a vm
[17:28]  * ogra_ calls it a day
[17:29] <LefterisJP> hmm indeed, had done that for a previous job with Debian. Should set that up.
[17:29] <LefterisJP> ogra_: good night!
[17:29] <sergiusens> or lxc
[17:29] <sergiusens> lxd (if you want to grab the tarball)
[17:33] <kyrofa> sergiusens, elopio now does work by the way
[17:33] <sergiusens> kyrofa, elopio lets do this then
[17:33] <elopio> kyrofa: sergiusens: joining the call.
[17:34] <LefterisJP> sergiusens: yeap, also good idea
[17:39] <pindonga> kyrofa, don't think so, but let me check
[17:39] <kyrofa> pindonga, how does the web interface display upload progress?
[17:40] <pindonga> it's a streaming upload
[17:40] <kyrofa> pindonga, hmm... I'm trying to figure out how to get upload progress out of the requests lib
[17:40] <pindonga> but let me get you properly backed facts instead of spitting out buzz words :)
[17:42] <pindonga> kyrofa, on the web ui we're using the YUI uploader component, which handles the progress itself (don't really know how)
[17:42] <pindonga> but I'm getting you those answers
[17:46] <pindonga> kyrofa, I guess you could do something like this: https://stackoverflow.com/questions/10525635/python-3-and-requests-with-a-progressbar#10576521
[17:47] <pindonga> oh, but it looks like requests itself doesn't support upload streaming
[17:47] <pindonga> https://stackoverflow.com/questions/13909900/progress-of-python-requests-pos
[18:39] <sergiusens> ogra_, if still around, mind telling me what uname -m returns for the dragon?
[19:28] <wxl> ok, so i tried ubuntu-device-flash to get an amd64 image and i get issues while partitioning
[19:29] <wxl> well that's the incredibly verbose error
[19:32] <wxl> $ sudo ubuntu-device-flash core --device generic_amd64 --channel ubuntu-core/15.04/edge --enable-ssh -o mysnappy.img
[19:45] <ogra_> sergiusens, ubuntu@localhost:~$ uname -m
[19:45] <ogra_> aarch64
[19:59] <sergiusens> ogra_, thanks
[21:24] <kyrofa> elopio, what changed to make the unit tests so noisy on master?
[21:24] <elopio> kyrofa: um, I don't know. Let me give it a try.
[21:25] <kyrofa> elopio, something to do with the loggers
[21:52] <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/282 if you want to take a look
[21:52] <sergiusens> elopio, ^
[22:42] <kyrofa> sergiusens, do you know what changed to make the test output so noisy? Something regarding the loggers?
[22:49] <kyrofa> bisect to the rescue
[23:10] <sergiusens> kyrofa, the landing of the tests for store uploads
[23:10] <kyrofa> sergiusens, yeah I bisected to that, but I can't seem to figure out exactly what's causing it!
[23:10] <sergiusens> those tests need to use the mocked loggers like the other test
[23:11] <kyrofa> sergiusens, but I'm seeing Catkin logs and stuff
[23:11] <kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/283 by the way. I can clean that up in another PR
[23:13] <sergiusens> kyrofa, do something like this https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/tests/test_commands_build.py#L62
[23:13] <kyrofa> sergiusens, there are indeed some of those, but the use the level of INFO. Does that set it for EVERYthing?
[23:13] <sergiusens> no need to assign
[23:14] <sergiusens> sorry baby in arms
[23:14] <kyrofa> sergiusens, understood! I gotta run too :)
[23:23] <bdmurray> How can I install a snap that I've created on my own?
[23:26] <ogra_> snappy install --allow-unauthenticated /path/to/snap
[23:26] <ogra_> +sudo
[23:27] <bdmurray> ogra_: so just scp it over then?
[23:27] <ogra_> yeah
[23:27] <vir17> guys I am a little confused, I have a .csv file with some data inside and I want from a python script to read this data, how can I declare this inside the .yaml file?
[23:28] <ogra_> there is a tool called snappy-remote that can do both, but i dont know in what shape it is (never used it)
[23:34] <vir17> I suppose I have to put the file in the directory where the python code will be
[23:34] <vir17> is "plugin:copy" something that I can use?
[23:36] <ogra_> vir17, well, do you need to read the csv at package build time ?
[23:36] <vir17> no, when the app will run in the snappy
[23:36] <ogra_> yeah, then the copy plugin is the right thing
[23:38] <vir17> ogra_:  thank you,  do you know also what is the correct declaration for plugin:copy ?
[23:39] <vir17> how i am going to add the destination
[23:39] <ogra_> http://paste.ubuntu.com/14708722/
[23:40] <ogra_> that would make it copy myfile from the toplevel of the source dir into the toplevel of the snap dir
[23:41] <vir17> thank you ogra_ much appreciated! :)