[01:30] <netphreak> hi, guys!
[05:58] <shuduo> morning
[07:45] <mvo> ogra_: if you have time at some point it would be great if we could update the arm64 kernel in xenial in the store
[08:03] <zyga> Good morning
[08:08] <mvo> ogra_: hm, the latest rpi2 kernel from the archive (canonical-pi2-linux.canonical_4.4.0-1004.5-1.snap) appears to not boot at all, hangs at "Uncompressing Linux... done, booting the kernel."
[08:09] <mvo> ogra_: auto-rollback-broken-boot ftw :)
[08:19] <dholbach> good morning
[08:19] <didrocks> dholbach: good morning!
[08:19] <dholbach> salut didrocks
[08:38] <shuduo> hello, i am working on repack mopidy (http://github.com/mopidy/mopidy.git) into snap format. i'm referring py2-project of snapcraft-examples. after snapcraft build, i notice the execute file /usr/bin/mopidy as a python script file contain my work directory path in first line.
[08:40] <shuduo> i wonder mopidy is pip compatible but spongeshaker don't has weird path. any idea how to solve or workaround it?
[08:58] <ogra_> mvo, the cdimage snaps shoudl work ...
[08:58] <ogra_> (for updating the store)
[09:00] <asac> hmm. running snapcraft from within snapcraft tree isnt possible anymore? it cannot find the plugins for me :/
[09:01] <asac> odd
[10:05] <ogra_> mvo, for arm64 we now have the linux-snapdragon kernel, the cdimage snap is already built from it by default since friday, i need to create as new package in the store for the new name
[10:05] <ogra_> s/as/a/
[10:06]  * ogra_ is waiting for dd to finish to chekc the rpi image
[10:07] <ogra_> mvo, hmm, i think we need a gadget update for the rpi side
[10:08] <mvo> ogra_: is the kernel available as an artifact on cdimage?
[10:08] <mvo> ogra_: do we need a new dtb ? or why is the gadget update needed?
[10:08] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[10:09] <ogra_> mvo, iirc the 4.4 support was added, the all-snaps gadget is still on older firmware
[10:10] <ogra_> (i updated the 15.04 one but forgot about all-snaps back then)
[10:11] <ogra_> above on the cdimage link are all all-snaps snap artefacts
[10:11] <mvo> ogra_: I can upload the dragonboard snap thats fine, I will upload to edge and you can test on your board?
[10:11] <Sin_> hi, all
[10:11] <ogra_> mvo, sure ... but create a new package called canonical-linux-snapdragon then
[10:12] <ogra_> and delete the old one
[10:12] <mvo> ogra_: oh, its called differently? ok
[10:12] <ogra_> yeah, and that kernel is supposed to support more snapdragons as i understood
[10:12] <mvo> ogra_: I assume the dragonboard.device tar file is not available on cdimage? "just" the snap?
[10:12] <mvo> ogra_: aha, interessting
[10:12] <ogra_> the tarballs are still there too
[10:13] <mvo> ogra_: in the past the tarball device stuff would not boot on the dragonboard
[10:13] <mvo> ogra_: is that no longer the case, i.e. does it boot now?
[10:13] <ogra_> i'm booting the cdimage snaps daily since a few weeks on the dragonboard
[10:13] <mvo> ogra_: cool
[10:13] <ogra_> i admittedly havent tries the rpi in a while ... nor the BBB
[10:13] <ogra_> *tried
[10:14] <Sin_> how to install apache on a rpi 2 ubuntu snappy core?
[10:14] <ogra_> rpi should work after gadget update (will work on that now) ...
[10:14] <ogra_> BBB still needs someone to test (but i can do that as well, just later)
[10:15] <ogra_> Sin_, sure, you just need to snap it up using snapcraft
[10:16] <Sin_> ogra, i'm trying to install snapcraft on rpi, but no luck
[10:16] <ogra_> if you are on the 16.04 image: sudo snappy enable-classic; snappy shell classic
[10:17] <ogra_> that gives you an apt environment in whicgh you can do work to create snaps
[10:17] <ogra_> (you can just apt-get install snapcraft there)
[10:18] <Sin_> "ubuntu core does not use apt-get"
[10:19] <Sin_> 15.04 img
[10:20] <ogra_> Sin_, http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz take that one
[10:21] <Sin_> thank you!
[11:05] <asac> sergiusens: i cannot run the 96boards example from withing my snapcraft-master checkout
[11:05] <asac> it tells me "kernel plugin ot found"
[11:05] <asac> odd because its in the snapcraft/plugins directory
[11:05] <asac> are we still supporting running from within tree?
[11:08] <asac> i am running ../../bin/snapcraft --target arm64 from within that 96b dir
[11:08] <asac> sergiusens: http://paste.ubuntu.com/15452970/
[11:09] <sergiusens> asac, yeah, it is supposed to just work, I've been running in tree
[11:09] <sergiusens> asac, kernel plugin is not in master
[11:10] <sergiusens> asac, https://github.com/ubuntu-core/snapcraft/pull/366
[11:11] <ogra_> ppisati, hmm, did you ever get around the FDT_ERR_BADMAGIC on the pi2 ?
[11:11]  * ogra_ is just trying the -next branch of the firmware 
[11:11] <ppisati> ogra_: yep, there's a way
[11:11] <ppisati> ogra_: hold on
[11:12] <ogra_> (or do you happen to have an up-to-date packaged version of the firmware)
[11:12] <ppisati> ogra_: well, the newest formware relocate the dtb in memory
[11:12] <ppisati> ogra_: so the answer is:
[11:12] <ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/config.txt
[11:13] <ppisati> ogra_: see at the end
[11:13] <ppisati> ogra_: device_tree_address=0x02000000
[11:13] <ppisati> ogra_: and uboot.env needs to be modified to look for the dtb there too
[11:13] <ppisati> ogra_: here is some more info
[11:14] <ppisati> https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=134018
[11:14] <ppisati> ogra_: search for "The slot at 0x100 is limited to...|
[11:14] <ppisati> that gives some more context
[11:14] <ogra_> ppisati, thanks a lot !
[11:14] <ppisati> ogra_: our kernel support teh rpi3 btw
[11:15] <ogra_> yeah, but we have no fully working u-boot yet i think
[11:15] <ppisati> ogra_: yes we do :)
[11:15] <ogra_> (i havent checked swarrens branch on the weekend ... last i checked it still was WIP
[11:15] <ogra_> )
[11:15] <ogra_> ppisati, oh !
[11:15] <ppisati> yeah, i was using that one
[11:15] <ppisati> and it worked
[11:15] <ogra_> for both pi's
[11:15] <ppisati> no
[11:15] <ogra_> ?
[11:15] <ogra_> ah
[11:15] <ppisati> it's not merged
[11:16] <ogra_> right+
[11:16] <ppisati> one for rpi2 and one for rpi3
[11:16] <ogra_> preferably i'd like to use the same image on both ... for 32bit at least
[11:19] <kyrofa> Good morning
[11:42] <ogra_> hmpf ...
[11:42] <ogra_> still not booting the new kernel
[11:44] <ogra_> aha
[11:45] <ogra_> eeek !
[11:45] <ogra_> ppisati, i get a massive load of "cant mount device as F2FS filesystem" during boot
[11:46] <ogra_> purely cosmetic, but looks really scary
[11:48] <ogra_> mvo, so i got it booting ... but you wont like the solution ... our dtb from the kernel snap needs to end up in the toplevel of system-boot and overwrite the one from the firmware
[11:49] <ogra_> ubuntu@localhost:~$ uname -a
[11:49] <ogra_> Linux localhost.localdomain 4.4.0-1004-raspi2 #5-Ubuntu SMP Mon Mar 14 22:27:12 UTC 2016 armv7l armv7l armv7l GNU/Linux
[11:49] <ogra_> (using the cdimage kernel snap)
[11:50] <ogra_> hmm, and resizing worked just fine
[11:50] <ogra_> ubuntu@localhost:~$ df -h |grep /writable
[11:50] <ogra_> /dev/mmcblk0p2  118G  151M  111G   1% /writable
[11:50] <ogra_> not sure what issue ali1234 had with his
[11:50] <ogra_> kyrofa, didnt you also see the rpi not resize ?
[11:50] <kyrofa> ogra_, indeed, yes
[11:51] <ogra_> weird
[11:51] <kyrofa> ogra_, ppisati I've been seeing garbled HDMI output and evbug errors whenever I press keys on the keyboard as well
[11:52] <ogra_> kyrofa, well, lets see if todays update will get you going then
[11:53] <kyrofa> ogra_, awesome :)
[11:53] <ogra_> just need to discuss with mvo what we do with the dtb
[11:54] <kyrofa> ogra_, so reading the scrollback, it seems you have a booting rpi3?
[11:54] <ogra_> (as a quick hack i can indeed just copy it into the gadget, but thats no solution long term)
[11:54] <ogra_> kyrofa, no, paolo has ... i'm working on the existing images today ... once we have a release i'll look at the pi3
[11:54] <sergiusens> kyrofa, good morning! I could really use a review on the kernel plugin PR ;-)
[11:55] <kyrofa> ogra_, ah, read too quickly then, but awesome :)
[11:55] <kyrofa> sergiusens, yessir! Part way through now
[11:55] <davidcalle> kyrofa: sergiusens: hi, is there a way to add an export to the launch wrapper created by snappy/snapcraft?
[11:55] <sergiusens> davidcalle, no; the launch wrapper is an implementation detail
[11:56] <sergiusens> davidcalle, it shouldn't be promoted to anyone ;-) People should write their own wrappers if they need that
[11:56] <sergiusens> davidcalle, or create a plugin that exports env
[11:59] <davidcalle> sergiusens: right, so, maybe the best course of action would be to create a wrapper part myself that exports what I want and launch the actual binary
[12:00] <davidcalle> sergiusens: (first time I'm trying to snap something that's not a terminal game, some concepts and ways of doing things are still abit blurry to me :) )
[12:02] <kyrofa> davidcalle, exactly
[12:02] <davidcalle> kyrofa: sounds good, thanks
[12:02] <kyrofa> davidcalle, you'll find little wrapper scripts here and there to be pretty central to how things are done
[12:07] <sergiusens> darn, in an hour I have meetings for 5 hours :-/
[12:07] <kyrofa> sergiusens, brutal
[12:12] <kyrofa> enoch85, you around?
[12:13] <asac> sergiusens: i am using your feature bran
[12:13] <asac> ch
[12:14] <asac> sergiusens: http://paste.ubuntu.com/15452970/
[12:14] <davidcalle> dholbach: kyrofa: sergiusens: it worked, thanks a lot :)
[12:14] <asac> ls -la ../../snapcraft/plugins/kernel.py
[12:14] <asac> -rw-rw-r-- 1 asac asac 10623 Mar 21 09:55 ../../snapcraft/plugins/kernel.py
[12:15] <asac> sergiusens: let me know if you need anything
[12:15] <asac> i am on 559044dc02646a3b10f078bd1d74182a3efd9a8d
[12:44] <ogra_> mvo, http://people.canonical.com/~ogra/snappy/canonical-pi2_3.1_all.snap built from https://code.launchpad.net/~ogra/+junk/snappy-systems (see revision 32-34) ... that one boots with the cdimage kernel
[12:45] <ogra_> mvo, the dtb problem persistes though and i'm not sure it could boot with a 4.2 kernel at all
[12:46] <ogra_> (without manually copying the 4.2 dtb in place)
[12:48] <ogra_> mvo, bah, you didnt use any of the cdimage snaps for the store, thats not ok
[12:48] <ogra_> (i want to auto-submit them starting this week)
[12:49] <ogra_> oh, wait, i got tricked by the versioning
[12:50] <ogra_> hmm, no, actually correct, not one of them
[12:50] <sergiusens> asac, you need to be on f8fea60694c2f2540c9f7490bdd0376848179c1f
[12:50] <sergiusens> asac, https://github.com/ubuntu-core/snapcraft/pull/366/commits/f8fea60694c2f2540c9f7490bdd0376848179c1f
[12:51] <dholbach> davidcalle, is it running already?
[12:52] <davidcalle> dholbach: yep, got it running :) Now, I'm trying to ship games in the snap and have them accessible to it
[12:52] <dholbach> upload to the store! :)
[12:52] <dholbach> snapcraft upload!
[12:54] <ogra_> mvo, so i think we have to re-do all of this
[12:54] <ogra_> we need to use the cdimage snaps here
[13:07] <davidcalle> dholbach: still trying to figure out some runtime details :)
[13:07] <dholbach> ok ok :)
[13:20] <netphreak> Hello, guys!
[13:35] <mvo> ogra_: sorry, I went for the safe route to ensure the cves are fixed, once they are in stable (i.e. now) I am more than happy to switch to the new artifacts
[13:35] <mvo> ogra_: this was "upload-cve-fixes-first-without-any-risk" mode
[13:36] <ogra_> ?
[13:36] <ogra_> these snaps all come from the very latest xenial archive debs
[13:36] <ogra_> i would not expect any open CVEs in them
[13:37] <ogra_> (they are completely identical to the tarballs ... content wise)
[13:40] <kyrofa> ogra_, the resize on boot thing, is that for the writable partition?
[13:40] <ogra_> yes
[13:40] <kyrofa> ogra_, should that continue to work if the writable partition is on a separate device?
[13:49] <jdstrand> mvo: hey, fyi, there is a new xenial kernel that might land today. this is going to require updates to ubuntu-core-security and ubuntu-core-launcher. I'm not sure when you are planning new os and kernel snap updates, but you might want to ping me if you are doing them before wednesday
[14:00] <elopio> mvo: related to that, if we are going with a two week cadence, we need to prepare today the 16.04 stable release to publish it tomorrow.
[14:00] <elopio> do you think we should talk to the kernel team first about doing 3 weeks instead of 2?
[14:05] <noizer> Hi jdstrand short question is it possible to use security-override and caps ( network-listener, ...) together?
[14:05] <jdstrand> noizer: in 16.04, yes. in 15.04, no
[14:06] <noizer> jdstrand: ok thx
[14:08] <mvo> elopio: I think we can do that
[14:09] <mvo> elopio: i.e. prepare update today
[14:10] <mvo> elopio: I triggered a new image build
[14:14] <elopio> mvo: ok. I also like the idea of trying a release tomorrow to get an idea of what will make it easier. We can decide on the # of weeks a little later.
[14:20] <mvo> elopio: yeah, we did not have a stable release since 8. match, so +1 for a new update
[14:22] <noizer> Will snappy be compatible with the Raspberry pi 3?
[14:23] <ogra_> noizer, yes
[14:24] <noizer> ogra_: ok that will be nicee
[14:25] <kyrofa> ogra_, think the writable partition resize would continue to work if it was on another device (e.g. an external HD)?
[14:26] <ogra_> kyrofa, thats what my "yes" above was for ... as long as the patition is properly named it should all work
[14:26] <ogra_> (and as long as the old label from the old writablöe was removed ... i never tried what happens if you have two of them :) )
[14:26] <kyrofa> ogra_, excellent thank you! And yeah, I imagine other problems would occur if that were the case!
[14:27] <kyrofa> jospoortvliet, are you around?
[14:38] <noizer> what does the caps exactly with a snap. Does it changes the apparmor profiles?
[14:39] <asac> noizer: yes under the hoot it generates the profile for that specific app
[14:39] <sergiusens> ogra_, out of the blue question; how do I build a 32 kernel ofrom an amd64 system?
[14:39] <ogra_> sergiusens, hmm, better aks the kernel guys :)
[14:39] <sergiusens> ppisati, ^ :-)
[14:39] <asac> sergiusens: -m32?
[14:39] <asac> :)
[14:39] <ogra_> i guess with some clever ARCH= setup
[14:39] <sergiusens> asac, is that all?
[14:39] <noizer> asac Is that possible to get the changes for some caps? because i need to make my apparmor myself for my own snaps got special restrictions
[14:39] <ogra_> passed to the toolchain
[14:40] <asac> noizer: are you on 15.04?
[14:40] <noizer> asac no im on 16.04 rolling
[14:41] <sergiusens> asac, how about a 32 bit kernel from an armhf system?
[14:41] <asac> sergiusens: i386_defconfig
[14:41] <asac> dunno i will check this later and let you know if you havnet found :_)
[14:42] <asac> you surely would want a cross compiler on armhf
[14:44] <ogra_> you want to build an x86 kernel on an arm host ?
[14:44] <ogra_> what did you guys smoke today ?
[14:44] <asac> yeah or on amd64 :)
[14:45] <asac> its important that you can read live the build process
[14:46] <ysionneau> hi, does ubuntu-core support booting on a GPT disk?
[14:47] <ogra_> ysionneau, indeed
[14:47] <ysionneau> it seems the init scripts are searching for writable using findfs LABEL=writable, but in GPT you need to do findfs PARTLABEL=writable
[14:47] <ogra_> the amd64 and arm64 images default to it
[14:48] <ogra_> ysionneau, we set both ... partition label and filesystem label
[14:48] <ysionneau> I'm on a Tegra X1 board and I'm using my own xml to describe the partitionning
[14:48] <ysionneau> I guess my issue is in this xml
[14:49] <ysionneau> I set name="writable" for the partition, but it does not seem to set the label, only the partlabel
[14:50] <ogra_> http://paste.ubuntu.com/15463687/
[14:50] <ogra_> ubuntu@localhost:~$ findfs LABEL=writable
[14:50] <ogra_> /dev/mmcblk1p9
[14:50] <ysionneau> ah, I guess it's my ext4 "file" which is missing its label then
[14:50] <ogra_> (thats both on a dragonboard)
[14:51] <ogra_> well, ubuntu.-device-flash creates the labels
[14:51] <ogra_> before it unpacks the os snap in it
[14:51] <ogra_> ("system-boot" and "writable" are the defaults)
[14:53] <ysionneau> I'm creating the ext4 myself, maybe I should just use udf
[14:53] <ogra_> yeah, you definitely should
[15:08] <kyrofa> ogra_, ah, the pi2 gadget was updated?
[15:08] <kyrofa> ogra_, means I need to update my fork
[15:08] <kyrofa> ogra_, what changed?
[15:09] <ogra_> kyrofa, last three commits https://code.launchpad.net/~ogra/+junk/snappy-systems
[15:09] <ogra_> (i'm about to merge that into the main tree)
[15:09] <kyrofa> ogra_, ah, very nice. Okay I'll keep an eye out
[15:11] <sergiusens> kyrofa, meeting?
[15:12] <kyrofa> sergiusens, sure! I figured you were booked
[15:12] <sergiusens> kyrofa, join snapcraft
[15:27] <ysionneau> yeah, I've got snappy booting on the drone board o/
[15:34] <didrocks> nice ysionneau \o/
[15:37] <joc_> elopio: ping
[15:39] <popey> I just updated my snappy machine:-
[15:39] <popey>  /var/lib/dpkg/info/tzdata.config: 379: /var/lib/dpkg/info/tzdata.config: cannot create /etc/timezone: Directory nonexistent
[15:39] <popey> (sorry, classic dimension)
[15:39] <popey> (classic)ubuntu@localhost:~$ ls -l /etc/timezone
[15:39] <popey> lrwxrwxrwx 1 root root 17 Feb  3 09:22 /etc/timezone -> writable/timezone
[15:40] <popey> that looks wrong (writable/timezone) is in red in my shell
[15:43] <ogra_> popey, it exists outside of the classich container
[15:43] <ogra_> (and we can only use relative links for that)
[15:43] <ogra_> (though even absolute wouldnt help in this case)
[15:46] <mvo> elopio: I think we have an updated ubuntu-core in 16.04/edge ready for tesing
[15:46] <elopio> mvo: thanks. I will start.
[15:46] <mvo> elopio: \o/
[15:47] <elopio> mvo: what about the 15.04 update? is it still happening today?
[15:47] <popey> ogra_: so what's the fix?
[15:49] <ogra_> popey, dunno, copy that dir into classic ... (no idea how)
[15:50] <ogra_> there are a bunch more files (three iirc)
[15:50] <ogra_> in /etc/writable
[15:51] <joc_> elopio: hey, the example tests appear to have errored on the plainbox snapcraft PR, would appreciate you having a quick look
[15:51] <ogra_> elopio, please take into acocunt that we have a new name for the dragonoboard kernel and that you *need* the new pi2 gadget snap (3.1) to make the 4.4 kernel boot
[15:55] <elopio> joc_: looking.
[15:56] <elopio> mvo: the tests are failing on the rollback when comparing the versions: 16.04-20160321-05-01+fake1 <= 16.04-20160321-05-01
[15:56] <elopio> that date 20160321-05-01 in the version is new. I suppose the function you wrote to compare is not ready to handle it.
[15:57] <elopio> ogra_: noted.
[15:57] <ogra_> elopio, use ~fake1 ?
[15:57] <ogra_> (i would expect this to work the same as dpkg versions)
[15:58] <mvo> elopio: can you point me to the actual test output please? the statement is correct, I don't think this is a version compare issue
[15:59] <elopio> mvo: https://paste.ubuntu.com/15464432/
[15:59] <mvo> ta
[15:59] <elopio> mvo: fgimenez was saying that the version maybe shouldn't include the date, because we already have a date field.
[16:00] <mvo> elopio: aha, I think I have an idea
[16:00] <elopio> and we can easily change the +fake1 to ~fake1 as ogra says. That's probably better.
[16:00] <mvo> elopio: that may indeed be a bug in the version compare code, iirc you normally can only have a single "-" but thats ok, should be easy to fix
[16:00] <ogra_> elopio, thats a limitation if using cdimage to build the snaps now ...
[16:00] <ogra_> (the date in the version string)
[16:01] <mvo> elopio: I think ~fake1 is not what we want it will be a lower version this way but we want the fake version to be higher
[16:01] <ogra_> i cant make cdimage aware of the latest version in the store so that i could bump it or some such ...
[16:01] <ogra_> fgimenez, ^^
[16:02] <elopio> lower, hum. This version rules are complex.
[16:03] <elopio> ogra_: I think the output of snappy list will be a lot nicer if we don't have the dates twice. I didn't fully understand what you said about making cdimage aware of the latest version. Could you expand a little on that?
[16:04] <jdstrand> mvo: hmmm, bug #1553040 seems to be happening on the hour
[16:04] <mvo> ogra_: lets wait with that before we figure the actual issue out
[16:04] <ogra_> elopio, cdimage doesnt know about the store ... by default it uses version numbers based on the date for everything it builds ... i can neither know what the last version was to bump it nor can i know whats in the store to bump it by 1
[16:04] <mvo> jdstrand: meh, that sucks
[16:04] <jdstrand> I guess I can uninstall ubuntu-core and reinstall
[16:04] <jdstrand> as a workaround
[16:04] <mvo> jdstrand: sorry for the language, I think we need to set the priority to high
[16:04] <mvo> jdstrand: yes, that should work
[16:04] <jdstrand> mvo: no need to be sorry. it does :)
[16:05] <ogra_> elopio, the only safe way to generate a version on cdimage auto-builds is to actually use a version string (or parts of it)
[16:05] <ogra_> err
[16:05] <ogra_> is to actually use a date string
[16:05] <ogra_> :P
[16:05] <mvo> jdstrand: the real fix is to just ensure the bootloader detection magic is smater and will not attempt to reboot if its not a snappy system
[16:05] <fgimenez> ogra_, could you use something like curl -s -H "X-Ubuntu-Architecture: amd64"  -H 'Accept: application/hal+json' 'https://search.apps.ubuntu.com/api/v1/package/ubuntu-core.canonical/edge' | jq '.version' to get the version?
[16:05] <elopio> ogra_: could you take the version from the debian changelog?
[16:05]  * jdstrand nods
[16:06] <ogra_> fgimenez, no, i dont have any access to the outside world during builds
[16:06] <ogra_> elopio, which debian changelog ?
[16:06] <jdstrand> Removing ubuntu-core.canonical
[16:06] <mvo> elopio, ogra_: lets keep the version for now until this is better understood, it smeels like a bug in the version compare code in snappy
[16:06] <jdstrand> snappy package cannot be removed
[16:06] <jdstrand> hmm
[16:06] <mvo> jdstrand: lol, of course not, can't remove your os
[16:06] <elopio> mvo: ogra_: sounds good.
[16:06] <ogra_> mvo, well, i agree with fgimenez that we shouldnt have the date twice ... but i have no idea wht to do
[16:07] <mvo> ogra_: oh, thats orthogonal I guess, thats fine
[16:07] <elopio> what is that -05-01 appended to the date?
[16:07] <ogra_> elopio, the os snap isnt bound to any debian/changelog ... and cant be
[16:07] <ogra_> elopio, time
[16:08] <jdstrand> mvo: yes, that obviously makes sense on a device, but sdoc now is interesting... I really should be able to remove that. I guess I can look at the cron job
[16:08] <elopio> got it.
[16:08] <jdstrand> not cron
[16:08] <ogra_> systemd timer :)
[16:08] <jdstrand> /lib/systemd/system/snappy-autopilot.timer
[16:08] <jdstrand> yes, I was getting there :)
[16:09] <mvo> jdstrand: yes you should
[16:09] <mvo> jdstrand: I mean, yes you should be able to do that, this was written when we had no idea about this use-case
[16:10] <jdstrand> mvo: oh sure, I was simply acknowledging that fact :)
[16:11] <elopio> joc_: looks like an error connecting to the testbed. You can re-try them commenting: "retest this please"
[16:15] <mvo> jdstrand: yeah :)
[16:20] <popey> updating my snappy pi.. I get this...
[16:20] <popey> 2016/03/21 16:19:37.029389 sort.go:162: Invalid version "16.04-20160321-14-25", using '0' instead. Expect wrong results
[16:20] <popey> is that normal?
[16:21] <ogra_> popey, most likely related to the issue that elopio and mvo are looking at above
[16:21] <popey> oh, sorry
[16:22] <mvo> popey: yes, thanks, what ogra_ said, but this error message is actually very useful
[16:22] <popey> Oh good :)
[16:23] <ogra_> yeah, that explins elopio's error :)
[16:23] <ogra_> *explains
[16:23] <popey> http://paste.ubuntu.com/15464724/ is the full output fwiw
[16:25] <ogra_> popey, funny, i wonder what happens after reboot :)
[16:26] <ogra_> seems it thinks it installed them
[16:26] <mvo> ogra_: I finally looked at this and I think changing the version to only have a single "-" in it would be best if that is possible
[16:26] <elopio> popey: thanks a lot. So it affects more than the integration tests, and you caught it early :)
[16:26] <mvo> ogra_: i.e. 16.04+2016032114-25
[16:27] <ogra_> mvo, hmm, yeah ... i can do that but need to re-build and re-upload
[16:27] <ogra_> mvo, with a plus sign ?
[16:27] <mvo> ogra_: yeah, plus is fine
[16:27] <ogra_> ok
[16:27] <mvo> ogra_: or give me a sec and I paste a new string, "-" and ":" are problematic
[16:27] <mvo> ogra_: "+" and "." are fine
[16:27] <ogra_> that takes quite some turnaround time though (livecd-rootfs upload ... waiting for publisher for 2h ... then rebuild and re-upload to the store)
[16:28] <mvo> ogra_: and "-" is fine as long as there is only one
[16:28] <popey> Do I dare reboot this?
[16:31] <ogra_> do you ?
[16:36] <jospoortvliet> kyrofa: I'm around now for a bit
[16:36] <jospoortvliet> sadly, not feeling well today
[16:36] <ogra_> mvo, http://paste.ubuntu.com/15464880/
[16:36] <jospoortvliet> spend most of the day in bed and will be returning soon
[16:36] <lool> sergiusens: hey
[16:37] <kyrofa> jospoortvliet, ah I'm sorry! Nothing important here, go back to bed :)
[16:37] <mvo> ogra_: maybe a "." in between? "date +20%y%m%d.-%M" ?
[16:37] <mvo> ogra_: otherwise looks fine
[16:37] <kyrofa> jospoortvliet, OC9 will be released as soon as it's built
[16:37] <lool> sergiusens: did we have a nack on supporting patch files in snapcraft, or is this something that just needs work?
[16:37] <mvo> ogra_: I think we can not avoid this delay, we could unpublish this particular version that is problematic though
[16:37] <jospoortvliet> kyrofa: rocking
[16:37] <jospoortvliet> kyrofa: we didn't figure out what PHP modules were missing though
[16:37] <lool> sergiusens: other question, is there anything discussing extending CFLAGS/CPPFLAGS/LIBS etc. somewhere?
[16:37] <ogra_> mvo, i'll upload to the PPA first ... that at least speeds up the publlisher
[16:38] <kyrofa> jospoortvliet, the images require imagick
[16:38] <kyrofa> jospoortvliet, that build process is complicated though, so it won't make it by tonight
[16:38] <jospoortvliet> ok... got it
[16:38] <kyrofa> jospoortvliet, it's dog slow on the rpi2 too, FYI
[16:39] <jospoortvliet> kyrofa: yeah, of course... ;-)
[16:39] <kyrofa> jospoortvliet, things are a bit snappier without it :P
[16:39] <jospoortvliet> kyrofa: for ownCloud, we should add caching at least, that'll help with performance
[16:39] <jospoortvliet> quite a bit ;-)
[16:39] <jospoortvliet> was hoping somebody would help...
[16:40] <kyrofa> jospoortvliet, yeah, that'll help
[16:40] <jospoortvliet> btw see https://doc.owncloud.org/server/9.0/admin_manual/installation/source_installation.html for a list of deps that are useful/helpful
[16:40] <jospoortvliet> add what you can ;-)
[16:41] <kyrofa> jospoortvliet, yeah I'm familiar with it, the snap config is pretty bare-bones at the moment indeed
[16:41] <sergiusens> lool, nack on patches
[16:41] <sergiusens> lool, extend CFLAGS, CPPFLAGS and LIBS where?
[16:41]  * sergiusens needs to leave for a bit
[16:42] <lool> sergiusens: I want to pass an extra flag in CFLAGS to my build on top of the snapcraft ones
[16:42] <lool> e.g. cmake build, autotools build etc.
[16:42] <sergiusens> lool, can't you do that with the flags keywords those support?
[16:43] <lool> I cant extend the current flags with this
[16:43] <lool> if I say CFLAGS="foo", it will override
[16:43] <lool> I could try CFLAGS="$CFLAGS foo", but dont think this works
[16:43] <kyrofa> jospoortvliet, anyway, go back to bed. I'll send out an email
[16:43] <sergiusens> lool, maybe CFLAGS="$CFLAGS foo"
[16:43] <jospoortvliet> kyrofa: thanks!
[16:43] <sergiusens> lool, why do you think it wouldn't ? :-)
[16:43] <lool> sergiusens: I think I tried it, but I'll try again
[16:44] <lool> it was before fixing the shell escaping issue, perhaps it works now
[16:45] <sergiusens> lool, btw, what is your strategy with those PRs?
[16:45] <ogra_> lool, stop scaring your shell, then it doesnt try to escape :P
[16:45] <lool> sergiusens: what's the proposed approach for patches? point at a patched tree? I'm adapting this bb recipe https://github.com/open-switch/ops-build/blob/master/yocto/openswitch/meta-distro-openswitch/recipes-ops/openvswitch/ops-openvswitch.bb which is openswitch's openvswitch build (naming is confusing); it uses upstream's tree and adds openswitch patches; trying to do the same with snapcraft is hard
[16:45] <lool> sergiusens: I'm about to update them
[16:46] <sergiusens> lool, the policy is you will have your own tree
[16:46] <sergiusens> lool, if you think about, that is what patches really are; git just makes patching obsolete
[16:46] <sergiusens> just look at our ubuntu kernel :-)
[16:48] <lool> sergiusens: sure, it's just that there is no merge support either, so how do you automatically take latest upstream git with your changes?
[16:48] <lool> it means people need an automation point on their own
[16:48] <lool> if we had something like Launchpad git recipes, then it would be fine though
[16:49] <lool> e.g. I'd point at my branch with patches and merge it with upstream before building
[16:49] <sergiusens> lool, sorry, I can't follow; but more so because I need to run; can we talk later or tomorrow?
[16:49] <lool> sure
[16:49] <lool> ttyl
[16:56] <mvo> ogra_: thanks
[17:22] <ogra_> new image build triggered
[17:38] <elopio> thanks ogra_
[17:38] <elopio> it's awesome when everything starts to be in place. Now jenkins will notice that a new edge was released, and run all the jobs itself.
[17:39] <ogra_> neat !
[17:39] <ogra_> well, the upload is still all me manual ...
[17:39] <ogra_> (and a big PITA)
[17:40] <elopio> oh, sure, it's ci, cyborg integration.
[17:41] <elopio> I also will need to manually select the channel checkbox z.Z
[17:43] <joc_> elopio: unfortunately my "retest this please" comment seems to have been ignored
[17:46] <elopio> joc_: I think I need to whitelist you so you can retest.
[17:46] <elopio> let me see. It's still a little confusing this plugin.
[17:47] <joc_> elopio: thanks
[17:50] <elopio> ogra_: can we change also the version of the latest edge snap?
[17:51] <ogra_> elopio, which one ?
[17:51] <ogra_> i cahnged all versions that are generated by the build to the schema tht mvo suggested above
[17:51] <ogra_> $upstream+YYYYMMDD.HH-MM
[17:51] <elopio> ogra_: in the store, revision #62 edge I see 16.04-20160321-14-13
[17:52] <ogra_> no, tht comes from the snap.yaml
[17:52] <ogra_> i dont think thats changeable
[17:52] <ogra_> (and i learned today that we cant delte snaps ourselves either)
[17:53] <elopio> we can upload a new one with the fixed version.
[17:53] <ogra_> thats what i will do once this build finished
[17:53] <elopio> so if I understand correctly, that would mean to go to that cdimage url where you are uploading the snaps, download it and upload it to the store selecting the edge channel.
[17:53] <ogra_> exactly, thats what i'm doing all day aleready :)
[17:54] <elopio> ogra_: ok, so nevermind I said anything. I thought that last part was on mvo's hands.
[17:54] <ogra_> i was fiddling with the click-toolbelt stuff to have cdimage auto-upload from there ... but that will still take a few days
[17:54] <elopio> ogra_: using snapcraft or calling the api directly?
[17:54] <ogra_> mvo is the one who needs to approve the snaps to have them published :)
[17:55] <ogra_> elopio, 12.04 server ... no snapcraft ...
[17:55] <ogra_> thus: click-toolbelt
[17:56] <elopio> got it, I will be slowly trying to understand all those parts this week. Let me know if I can give you a hand somewhere.
[18:10] <mvo> ogra_: are they ready already :) ?
[18:11] <ogra_> mvo, ready, yes, not uploaded yet
[18:13] <mvo> ogra_: nice, keep me updated!
[18:25] <mhall119> zyga: ping
[18:36] <ogra_> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4142/ (ubuntu-core), https://myapps.developer.ubuntu.com/dev/click-apps/4283/ (canonical-pc-linux (dont forget i386 ;) )), https://myapps.developer.ubuntu.com/dev/click-apps/4284/ (canonical-pi2-linux)
[18:36] <ogra_> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4316/ (canonical-bbb-linux), https://myapps.developer.ubuntu.com/dev/click-apps/4739/ (canonical-snapdragon-linux)
[18:36] <ogra_> happy approving :)
[18:40] <elopio> ogra_: mvo: is this a good version for the ubuntu-snappy deb we upload to the PPA? 1.7.3+20160310ubuntu1~ppa14-1
[18:40] <elopio> 14 is the number of the build, so it's always increasing.
[18:40] <ogra_> why -1 ?
[18:40] <mvo> elopio: this looks good, you can skip the final "-1"
[18:40] <ogra_> :)
[18:43] <kgunn> ogra_: i haven't check on dragonboard in a while, is it getting any love? or is it roughly in same state as ~January
[18:43] <ogra_> kgunn, totally
[18:43] <ogra_> the store is full of shiny new packages and we'll do an alpha release this week
[18:44] <kgunn> cool
[18:44] <ogra_> (4.4 kernel is now canonical-snapdragon-linux ... and ubuntu-core for arm64 just got updated)
[18:44] <ogra_> we still dont have any classic mode on arm64 though
[18:44] <popey> ogra_: so will there be another update i can pull down on my edge pi which will replace the busted one?
[18:44] <popey> (in some hours?)
[18:45] <ogra_> popey, why hours ?
[18:45] <popey> I assume it takes a while :)
[18:45] <ogra_> just pour some extra fuel into elopio and it will be fast :)
[18:49] <elopio> ogra_: mvo: dch adds a 1 at the end. I'm not sure how to remove that.
[18:49] <elopio> dch --distribution xenial -m --local ~ppa$BUILD_NUMBER- Daily release to the PPA
[18:49] <elopio> any tips to improve that ^ ?
[18:51] <ogra_> hmm, i thought it only does that with explicit -i
[18:51] <mvo> elopio: its fine, it won't hurt
[19:52] <kyrofa> sergiusens, this should look familiar, but a bit easier to review: https://github.com/ubuntu-core/snapcraft/pull/384
[19:52] <kyrofa> elopio, ^^
[19:55] <sergiusens> kyrofa, my comments weren't exported though :-P
[19:59] <kyrofa> sergiusens, unfortunately not :( . Darn intermediate branch. I wish I could change the PR partway through
[19:59] <kyrofa> sergiusens, but the complicated bits (strip cleaning) aren't here anymore, so your comments wouldn't be relevant anyway
[20:00] <sergiusens> kyrofa, heh :-) I search for the closed one and replicate
[20:00] <sergiusens> kyrofa, oh they aren't? I don't want to blindly trust you though ;-)
[20:00] <kyrofa> Haha, no don't trust me! I realized a lot of that other PR didn't have anything to do with strip cleaning-- there was a bit of setup to do it. This PR is that "bit of setup"
[20:01] <kyrofa> So then subsequent PRs can just fill in their little bits
[20:01] <kyrofa> sergiusens, smaller PRs=better
[20:03] <sergiusens> kyrofa, oh, you removed the strip part
[20:03] <kyrofa> sergiusens, right
[20:03] <sergiusens> kyrofa, got it; I still managed to add MOAR comments ;-)
[20:04] <kyrofa> Yeah I keep forgetting about !r
[20:04] <sergiusens> kyrofa, btw, somethings failed here https://github.com/ubuntu-core/snapcraft/pull/383
[20:06] <kyrofa> sergiusens, hmm...
[20:12] <kyrofa> sergiusens, huh... I can't connect to the VPN at the moment. NM is telling me it doesn't have permission
[20:12] <sergiusens> kyrofa, heh, I hate nm :-P
[20:12] <kyrofa> *sigh*
[20:12] <sergiusens> kyrofa, elopio btw, I am doing some manual traffic shaping on which PR gets tested next
[20:12] <kyrofa> I'd totally reboot, but I have an emergency build of owncloud going that I can't stop
[20:13] <kyrofa> sergiusens, no problem
[20:13] <sergiusens> kyrofa, ssh and screen ;-)
[20:13] <kyrofa> sergiusens, screen doesn't work in classic
[20:13] <kyrofa> sergiusens, otherwise that's the obvious choice
[20:13] <sergiusens> kyrofa, if it is a serial connection it would be fine
[20:13] <kyrofa> sergiusens, :P
[20:13] <sergiusens> to disconnect and reconnect
[20:13] <kyrofa> sergiusens, SSH I'm afraid
[20:55] <zyga> mhall119: hey
[21:11] <sergiusens> kyrofa, testing is taking forever :-P
[21:11] <kyrofa> sergiusens, yeah, killer
[21:18] <mhall119> zyga: hey, I had a task to follow up with you about show to ship apps written for the phone/tablet on a the snappy desktop, do we have a plan for how we're going to approach that for 16.04?
[21:18] <mhall119> last we spoke you were still workign that out
[21:24] <kyrofa> jdstrand, I've got two owncloud.canonicals in the manual review queue for network-listener. Mind taking a look?
[21:28] <jdstrand> kyrofa: approved
[21:30] <kyrofa> jdstrand, thank you!
[21:30] <zyga> mhall119: I think that hasn't changed since, we're still tying loose knots together to make the system work
[21:31] <zyga> mhall119: I think we're still a bit behind there on what we aim to deliver
[21:40] <mhall119> zyga: with it using the snappy space, will we be able to land that feature for users of 16.04 even after release? Or will it have to wait until 16.10?
[21:42] <sergiusens> kyrofa, care to rebase https://github.com/ubuntu-core/snapcraft/pull/384 ?
[21:44] <zyga> mhall119: I'm almost 100% sure that we'll land updates across all systems
[21:45] <zyga> mhall119: we really need to land all the key things for 16.04 but we'll be making updates as the system evolves; AFAIR we're still trying to determine exactly how snappy updates in ubuntu will look like but that's the plan
[21:48] <mhall119> zyga: ok, can you send an update to the email thread dholbach started, titled "Releasing the SDK libs as a snap" with the current state of things?
[21:49] <zyga> mhall119: yes, I'll read updates since I replied initially and I'll do my best to reply
[21:49] <mhall119> thanks, just to keep everybody in the loop updated
[21:51] <popey> error: owncloud-pi2.kyrofa failed to install: gadget package installation not allowed
[21:51] <popey> should I be able to install that?
[22:02] <sergiusens> popey, no, gadgets are only allowed during image creation
[22:05] <davidcalle> sergiusens: hi again, is there a way to put myself in the position of my snap, with the same constraints and path, and run commands (and maybe install packages)?
[22:06] <davidcalle> paths*
[22:21] <popey> sergiusens: shouldn't they be hidden from snapy find then?
[22:30] <sergiusens> popey, oh they should; I made that statement or logged a bug about that or told stevebiscuit
[22:30] <sergiusens> I forget which
[22:30] <sergiusens> that and other kernels
[22:31] <sergiusens> and also other uninstallables
[22:31] <sergiusens> davidcalle, there's supposed to be a `snappy shell <snap>` ... but zyga
[22:31] <sergiusens> lol, that came out wrong; I mean zyga can expand on if that is implemented or no
[22:31] <sergiusens> t
[23:08] <wililupy> Question: Whats the best documentation for building Kernel Snaps?
[23:40] <sergiusens> elopio, care to look at https://github.com/ubuntu-core/snapcraft/pull/386/files
[23:41] <sergiusens> wililupy, wait for snapcraft 2.5 to be announced later tonight or early in the morning
[23:41] <wililupy> sergiusens: ack
[23:41] <elopio> sergiusens: looks good. Are you going to include these two fixes I have in-progress?
[23:42] <sergiusens> elopio, nah; we will get those in on Wednesday
[23:42] <sergiusens> elopio, I have a bunch of small fixes to get in
[23:42] <sergiusens> these can go there
[23:46] <elopio> sergiusens: will you open a new milestone for the wednesday or should I target these bugs to 2.6?
[23:51] <sergiusens> elopio, 2.6
[23:51] <sergiusens> elopio, 2.6 is the wednesday milestone ;-)
[23:51] <sergiusens> we are releasing 2.5 today :-)