[00:29] <jdstrand> ogra_: fyi, snappy install ufw.jdstrand. enjoy :)
[02:07] <sergiusens> jdstrand, btw, I can't do $SNAP_APP_DATA_PATH in a `start` for a service
[02:33] <sergiusens> jdstrand, mind approving this later https://myapps.developer.ubuntu.com/dev/click-apps/3989/seq/1/ ?
[02:34] <sergiusens> and that also relates to the question about using $SNAP_APP_DATA_PATH
[03:36] <Sam_> : )
[07:36] <dholbach> good morning
[08:09] <fgimenez> good morning
[08:38] <pandatrone> what is this https://uappexplorer.com/app/ubuntu-kernel.mvo ???
[08:39] <mvo> pandatrone: its the next step on the road to 16.04, kernel and os snaps
[08:39] <pandatrone> mvo, awesome! i like it
[08:40] <mvo> pandatrone: yeah, I'm quite excited about it too, it will open up a lot of new possibilities :)
[08:40] <pandatrone> you snappy people are great
[08:40] <pandatrone> and mir people :D
[08:40] <mvo> heh, thanks :-D
[08:40] <pandatrone> i get 10-50% more fps in glmark2 in OTA8 compared to OTA5 on mx4
[08:41] <pandatrone> unity people are a little confused buy they'll catch up
[08:41] <pandatrone> *but
[09:14] <fgimenez> hi mvo good morning
[10:05] <mvo> hey fgimenez
[10:05] <mvo> fgimenez: sorry for the slow reply
[10:06] <fgimenez> mvo, np :) i was getting some errors from udf but now it seems to be working again
[10:06] <fgimenez> mvo, 254 is available already in jenkins
[10:07] <mvo> fgimenez: nice!
[10:14] <JamesTait> Good morning all; happy Thursday, and happy Use Less Stuff Day! 😃
[11:06] <shouting-sergius> sergiusens hello
[11:06] <shouting-sergius> balloons hello
[11:36] <sergiusens> dpm, mind approving https://myapps.developer.ubuntu.com/dev/click-apps/3989/seq/2/ ?  the failure there is due to an outdated reviewer tool being used
[11:38] <dpm> sergiusens, I haven't reviewed an app in quite a long time, so I'm not sure I'm the right person, but I'm sure dholbach or popey can help
[11:38] <popey> sure thing!
[11:38] <dpm> cool, thanks!
[11:42] <popey> sergiusens, done
[11:45] <sergiusens> popey, thanks, now balloons can use a snap instead for irc ;-)
[11:47] <livcd> so i'd like to use snappy as a base image with vagrant on mac  to run docker containers. Would it work for my use case ?
[11:47] <sergiusens> livcd, it should, there is a docker snap already, there are some gotchas, but I don't run docker myself to remember those
[11:48] <sergiusens> livcd, if you run into trouble, just ask (on askubuntu would be even better to keep some history and help others seeing the same you would)
[11:53] <shout-user69> popey thanks for approving me into existence :-)
[11:53] <popey> haha
[11:53] <popey> what have I done!!
[11:53] <livcd> sergiusens: not yet familiar with what a snap is :-)
[11:53]  * shout-user69 twiddles fingers
[11:54] <sergiusens> livcd, oh; a snap is a package
[11:58] <sergiusens> livcd, maybe go over the tutorials?
[11:58] <livcd> reading them atm
[11:59] <sergiusens> livcd, https://developer.ubuntu.com/en/snappy/start/#vagrant
[11:59] <sergiusens> you can read and play at the same time ;-)
[12:17] <livcd> sergiusens: i'd like to build an img myself with packer
[12:18] <sergiusens> livcd, I can't help you there; if you drop your question on askubuntu maybe someone can help out
[12:22] <Chipaca> what's packer?
[13:11] <jdstrand> sergiusens: can you request a manual review?
[13:15] <jdstrand> beuno, pindonga: hey, can somone pull in the review tools? there are are fixes for sergiusens' failure and two others for clicks that popey and dholbach saw. This is not the branch for non-click/all snaps (that is in progress)
[13:16] <pindonga> jdstrand, what revno?
[13:16] <jdstrand> the latest is fine
[13:16] <jdstrand> r550
[13:16] <pindonga> we'll need to do some QA on staging before we can roll  it out (to verify all pending changes are good to go) but I'll plan for the rollout asap
[13:17] <jdstrand> thanks
[13:48] <sergiusens> Chipaca, I think packer is a vagrant thing
[13:48] <sergiusens> Chipaca, https://www.packer.io/intro/getting-started/vagrant.html
[14:52] <sergiusens> Chipaca, elopio mind looking at https://github.com/ubuntu-core/snapcraft/pull/102 ?
[14:53] <elopio> sergiusens: oh good, I'll try to play with the nodejs bbb package again.
[14:53] <elopio> you have a copy&paste error: GoPluginTestCase
[14:58] <sergiusens> elopio, ah, interesting :-)
[15:00] <sergiusens> elopio, fixed, still not pushed, but 100% coverage is what I had to share with you :-P
[15:02] <sergiusens> dholbach, is the wiki completely dead?
[15:26] <dholbach> sergiusens, this morning I got a 500 internal server error, pinged IS and it came back again
[15:27] <sergiusens> dholbach, works now, thanks
[15:27] <sergiusens> mvo, ^^
[15:29] <jdstrand> sergiusens: hey, can you request a manual review for https://myapps.developer.ubuntu.com/dev/click-apps/3989/seq/1/?
[15:29] <jdstrand> mvo: hey, I'm going to remove click-apparmor from the system-image seed on xenial
[15:30] <sergiusens> jdstrand, what for, seq/2 is already approved
[15:30] <sergiusens> ?
[15:31] <jdstrand> ok, there is a 0.0.1
[15:31] <jdstrand> I'll reject that
[15:40] <mvo> jdstrand: thanks!
[15:53] <jdstrand> mvo: I'm also updating ubuntu-core-security to remove sc-filtergen and not pull in easyprof
[15:59] <mvo> jdstrand: nice, very very nice
[16:01] <faenil> hello
[16:01] <faenil> I'm trying to port snappy to a new board, but the image ubuntu-device-flash outputs has a partition table which is not recognized by either uboot or "Disks" app on Ubuntu
[16:02] <faenil> fdisk -l reports fat + 3 ext4 partitions
[16:02] <faenil> while "Disks" and uboot only see a huge fat partition, thus failing to access the data in any of the partitions
[16:03] <faenil> any advice
[16:03] <faenil> ?
[16:07] <faenil> ogra_: ^ maybe :)
[16:38] <sergiusens> faenil, what does parted say?
[16:39] <faenil> sergiusens: parted shows the partitions
[16:39] <faenil> gparted doesn't
[16:39] <faenil> "Disks" software doesn't
[16:39] <faenil> uboot doesn't
[16:39] <faenil> fdisk -l shows the partitions
[16:39] <sergiusens> faenil, does your u-boot support ext4?
[16:40] <faenil> sergiusens: I rebuilt it to add ext4 commands
[16:40] <faenil> sergiusens: still, gparted and Disks on desktop only show a big fat partition, like uboot
[16:41] <sergiusens> faenil, can you run `kpartx -avs <image.img>` ?
[16:41] <sergiusens> someone who can help with u-boot itself is lool
[16:45] <faenil> sergiusens: http://pastebin.ubuntu.com/13348638/ kpartx
[16:46] <faenil> sergiusens: I can loop mount the img on desktop, but not the sdcard (but I guess that's expected). I can still mount the fat partition from the sdcard using "-o offset"
[16:52] <sergiusens> faenil, has your 'dd' finished correcly (ins and outs match and all that)
[16:52] <sergiusens> sorry for asking a possibly dumb question
[16:52] <faenil> sergiusens: yeah
[16:53] <faenil> sergiusens: I tried multiple times, and with 2 different sdcards
[16:53] <faenil> 2925000000 bytes (2.9 GB) copied, 162.81 s, 18.0 MB/s
[16:53] <faenil> (that's the size of the img)
[16:54] <sergiusens> faenil, parted against the sdcard is also fine?
[16:54] <faenil> sergiusens: what do you mean?
[16:55] <faenil> yes, "print" shows 4 partitions on the sdcard
[16:56] <faenil> gparted instead shows 1 partition as big as the sdcard, with "Unknown filesystem"
[16:56] <faenil> and lba flags
[17:21] <sergiusens> faenil, could this be a gpt problem?
[17:21] <faenil> sergiusens: I guess it could...
[17:24] <faenil> sergiusens: even though parted says "Partition Table: msdos
[17:27] <sergiusens> faenil, are you sure you are booting your u-boot and not whatever is on the board?
[17:27] <faenil> sergiusens: yes, 100%
[17:27] <faenil> the versions tells it
[17:28] <faenil> and I have ext4 commands available, which the original uboot for this board don't have
[17:29] <faenil> sergiusens: I defined
[17:29] <faenil> #define CONFIG_CMD_EXT4
[17:29] <faenil> #define CONFIG_CMD_EXT4_WRITE
[17:29] <faenil> is there anything else needed for ext4 support? that seems all it's needed, I had a look at README.ext4 in uboot's docs
[17:30] <longsleep> faenil: what u-boot version are you based on?
[17:30] <faenil> longsleep: 2015.4
[17:31] <longsleep> faenil: sounds good
[17:31] <faenil> should be, yeah :)
[17:31] <longsleep> faenil: i am stuck at 2011.3 :/
[17:31] <faenil> yeah, I guess most of the people are not that lucku
[17:32] <longsleep> faenil: not sure if it helps, but https://github.com/longsleep/u-boot-odroidc/commits/master is my u-boot tree to make the upstream u-boot work with snappy
[17:32] <faenil> sergiusens: the img was created using --oem beagleblack (because there doesn't seem to be any generic-armhf package and that's what the Porting guide recommends), using edge channel
[17:32] <faenil> but that shouldn't make a difference on the partition table, should it
[17:33] <faenil> longsleep: cheers
[17:36] <sergiusens> faenil, well if your board is exactly the same wrt to boot setup, then there you go
[17:36] <sergiusens> faenil, fwiw, I took a stance at updating the porting guide
[17:36] <sergiusens> faenil, https://gist.github.com/sergiusens/fa40a344ad4b395a99ed
[17:36] <sergiusens> still needs a review from ogra_ but he is off this week on leave
[17:37] <faenil> sergiusens: isn't there a list of oem snaps?
[17:37] <longsleep> faenil: in general, if u-boot fails its best to figure it out in u-boot shell, maybe your oem snap did overwrite some stuff of the partition table
[17:38] <faenil> longsleep: I wish there were a generic armhf oem snap :/
[17:38] <sergiusens> faenil, well you can search the store with `type: oem`
[17:39] <sergiusens> faenil, I always forget how to query the store though and we never baked that into u-d-f
[17:39] <faenil> sergiusens: hehe
[17:39] <faenil> anyway, there's no generic armhf oem snap :)
[17:39] <longsleep> faenil: mhm well, how can there be a generic one if all devices need other bootcode?
[17:39] <sergiusens> faenil, there is no such thing as a generic bootloader for arm ;)
[17:40] <sergiusens> u-boot is the closest you can get, but they all boot at different offsets
[17:40] <faenil> ok, sorry, I don't know what the oem snap contains so I'm just blind guessing ;)
[17:40] <longsleep> faenil: Look at https://github.com/longsleep/snappy-odroidc - that puts all the gear together to build u-boot, kernel, oem snap and device tarball for the ODROID-C platform
[17:41] <faenil> longsleep: ok, I'll have a look thanks
[17:45] <longsleep> sergiusens: Your porting guide looks good - i think that will help people a lot when its ready
[17:46] <sergiusens> thanks, still a bit to update wrt to uEnv.txt and others
[17:46] <faenil> sergiusens: longsleep beagleblack doesn't touch the partition table afact http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/beagleblack/
[17:46] <longsleep> sergiusens: maybe you can add a section on how the initrd can be optained
[17:47] <longsleep> faenil: no, but it wites stuff raw at the beginning of the disk, see the boot-assets in the meta/package.yaml
[17:49] <faenil> longsleep: I see...is that snappy yaml syntax to do that?
[17:50] <longsleep> faenil: yes, when ubuntu-device-flash assembles the image, it writes the stuff under raw-files 'raw' at the specified disk offset
[17:50] <longsleep> faenil: what these offsets are actually depens where your arm device expects its bootcode to be
[17:50] <faenil> longsleep: sure
[17:50] <faenil> my question now is more generic :)
[17:50] <faenil> is that what happens when you "install" that snap?
[17:51] <faenil> I guess it's not something specific to device-flash
[17:51] <longsleep> faenil: nope, when you install a snap it essentially just downloads a special kind of deb package and extracts it to a well known location
[17:51] <longsleep> faenil: the special kind of snap with type oem, is used by u-d-f when you create a image for that platform
[17:51] <faenil> longsleep: so that raw stuff is a special direction that only udf will use?
[17:51] <faenil> ok
[17:52] <longsleep> faenil: yes, for now the boot-assets stuff is only used by u-d-f afaik
[17:52] <faenil> ok, thanks
[17:53] <faenil> longsleep: I guess my next step is to have a look at what you I guess, then :)
[17:53] <faenil> since the porting guide doesn't cover this part at all :)
[17:54] <faenil> I also read ogr a's post, but it doesn't mention what to do when, for instance, your board doesn't come with initrd support by default
[17:54] <faenil> which is all stuff we should really take care of, in a porting guide :)
[17:55] <faenil> sergiusens: ^
[17:57] <faenil> or when your uboot doesn't read any env file, for instance
[17:57] <longsleep> faenil: mhm, initrd should be unrelated to the board, its related to the kernel and the distribution
[17:57] <longsleep> faenil: well, every u-boot has variables, just make it read one
[17:57] <faenil> longsleep: that's not the right attitude for a guide, imho :D
[17:57] <faenil> if we want to attract more people, we have to make it easier
[17:58] <longsleep> faenil: sure, but i fear porting to whatever arm platform is not so easy, and i am not sure if a snappy porting guide should explain u-boot so much
[17:58] <longsleep> faenil: there could be a u-boot guide though :(
[17:58] <faenil> yeah, initrd is unrelated, but not all distro/kernel that you get with a board come with initrd...while the guide assumes that you have one and that you can adapt it
[17:59] <longsleep> faenil: ah ok, i get what you mean. I think you should turn the initrd question around, Snappy has one and you should adapt it to mach your kernel. That is how i did it
[18:00] <longsleep> faenil: essentially i use the exact initrd from snappy upstream, see https://github.com/longsleep/snappy-odroidc/blob/master/device.mk#L59
[18:03] <faenil> longsleep: I see, ok.
[18:03] <faenil> yeah I believe we just have to be a bit more detailed :)
[18:04] <faenil> and I have almost 0 experience with dev boards, so I'm just giving feedback on how we could improve the guide :)
[18:08] <longsleep> faenil: yeah, i had little u-boot experience when i started porting to snappy, but with lots of help from ogra_ i managed to get it done without very much issues. I have written about it a bit https://www.stdin.xyz/2015/06/14/snappy-ubuntu-core-for-odroid-c1/ if you want to get some ideas what problems i found
[18:09] <faenil> longsleep: awesome, thanks
[18:10] <faenil> longsleep: it is important that we don't let those post stay post (I'm probably going to write one as well), but we collect all the issues we had and update the official guide accordingly :)
[18:10] <faenil> we don't let those posts remain posts on a blog*, I meant
[18:11] <longsleep> faenil: yes, it would be awesome to have good guides, for now i think the best answer is go to #snappy IRC and ask - the guys here are awesome.
[18:13] <faenil> :)