[01:30] <netphreak> Hi, guys :)
[01:32] <netphreak> Any news on ubuntu snappy support on the RPI 3?
[02:25] <zyga> jdstrand: hey
[02:26] <zyga> jdstrand: could you have a quick look at https://github.com/ubuntu-core/snappy/pull/635
[02:26] <zyga> jdstrand: the only new thing there since we last looked at that is https://github.com/ubuntu-core/snappy/pull/635/commits/939d1d5824c8ced1b7e994cf4f2f88ad289693ba
[02:27] <zyga> jdstrand: I would *really* like to land this branch as it's been in a linbo for a week and I have some code that needs it
[02:27] <zyga> jdstrand: if I lost track of the desired file name and other templates then please correct me but I think it is okay
[02:28] <zyga> davidcalle: hey, sorry, lost IRC connection
[02:29] <zyga> davidcalle: can you re-state your request please?
[08:26] <dholbach> good morning
[08:39] <noizer> Good morning
[09:05] <noizer> jdstrand: Hi are you available?
[09:19] <zyga> good morning
[09:48] <ogra_> mvo, you didnt approve the kernels from the last build/upload ?
[10:00] <noizer> Did you heard about the bomming in belgium dammed
[10:08] <zyga> ogra_: hey, good morning
[10:08] <mvo> ogra_: I see nothing in the unapproved queue
[10:19] <netphreak> good morning ;)
[10:19] <netphreak> Any news on ubuntu snappy support on the RPI 3?
[10:20] <noizer> I heard it will be working on RPI 3 netphreak
[10:20] <noizer> But i'm not a canonical developer
[10:21] <ogra_> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4739/rev/2/ https://myapps.developer.ubuntu.com/dev/click-apps/4316/rev/3/ https://myapps.developer.ubuntu.com/dev/click-apps/4284/rev/8/ https://myapps.developer.ubuntu.com/dev/click-apps/4283/rev/16/ https://myapps.developer.ubuntu.com/dev/click-apps/4283/rev/17/
[10:22] <ogra_> morning zyga
[10:25] <mvo> ogra_: aha, please click on "request for manual review", then I can see them in the review queue, otherwise they are invisible for me
[10:26] <mvo> ogra_: I can do that now myself
[10:26] <mvo> ogra_: just for the next time, that click makes it easier for me to find them
[10:26] <ogra_> ok
[10:27] <ogra_> i wonder how to do that for the automated uploads then :P
[10:29] <zyga> jdstrand: hey
[10:29] <zyga> jdstrand: I didn't know you were around
[10:29] <mvo> ogra_: I think we need to talk to jdstrand and see if we can drop the -all-root requirement
[10:29] <mvo> ogra_: for the squashfs, I think that is causing the issues right now because the repack of the snap can not be done because of different parameters and this causes this manual review thing
[10:29] <ogra_> mvo, well, at least special case os snaps
[10:29] <zyga> jdstrand: I don't know if you saw the discussion on telegram; we were wondering about the apparmor cache, specifically what maintains the cache enabled by https://github.com/ubuntu-core/snappy/pull/635/files#diff-48ca5117699c941398b92fcd61caaed5R43
[10:30] <mvo> ogra_: yes, or that
[10:30] <ogra_> i think the --all-root was wanted (there was a bug)
[10:30] <ogra_> Bug #1546821
[10:31] <sergiusens> ogra_, yes; the bug sequence was, make snapcraft support the os snap without all-root and remove the snappy build functionality
[10:31] <sergiusens> wednesday's release will have that
[10:32] <ogra_> sergiusens, ah, good to know
[10:37] <ogra_> sergiusens, please leave me a few days with the removal from snappy though (even though i expect no issues with switching livecd-rootfs, if there are any we are screwed with the dailies)
[10:38] <sergiusens> ogra_, I am not removing snappy build, that is on mvo and his merry friends :-)
[10:38] <ogra_> ah, ok
[10:41] <ysionneau> can ubuntu-device-flash generate separate .img files for each partition instead of a big img file?
[10:42] <ogra_> ysionneau, nope, but kyrofa has a script to split it into two img files
[10:42] <ogra_> (one for the boot stuff, one for writable
[10:42] <ogra_> )
[10:43] <ysionneau> I guess fdisk + losetup + dd should do the job?
[10:43] <mvo> sergiusens: we still need that bit for various tests (and its ~5 lines) happy to hide it (and make it only available in the tests)
[10:43] <ysionneau> but I'd like to have a look at the script anyway :)
[10:44] <dholbach> davidcalle, want to have a chat about snappy/snapcraft docs in a bit? or shall we talk later?
[10:45] <davidcalle> dholbach: can you do a quick one in ~20min?
[10:45] <dholbach> yes, a quick one
[10:46] <sergiusens> mvo, well I'm not the one pushing for it https://bugs.launchpad.net/snapcraft/+bug/1546821 look at comment #8
[10:47] <sergiusens> mvo, you can hide it; but personally I think our QA would be a lot better if you use snapcraft's snap instead
[10:47] <sergiusens> mvo, if it is just 5 lines it could also just be moved to the test runner code
[10:48] <mvo> sergiusens: fair enough, yes, I think a separate package would be good
[10:48] <mvo> sergiusens: anyway, let me look at this
[10:48] <sergiusens> mvo, but of most importance; people like you and me need to stop using `snappy build`
[10:53] <mvo> sergiusens: thats fine, can we make "snapcraft snap" not look for snapcraft.yaml maybe? this would allow us to keep using our tests
[10:54] <sergiusens> mvo, have you used snapcraft snap? ;-)
[10:54] <mvo> sergiusens: http://paste.ubuntu.com/15471199/
[10:55] <sergiusens> mvo, `snapcraft snap DIR` :-)
[10:56] <mvo> sergiusens: thanks! http://paste.ubuntu.com/15471206/ :P I guess it wants to tell me that the architectures field is mandatory
[10:56] <popey> I spy new update coming down the pipe!
[10:56] <popey> Updating canonical-pi2-linux (4.4.0-1004-raspi2+20160321.17-52)
[10:56] <popey> \o/
[10:56] <mvo> sergiusens: I will prepare a branch that replaces snappy build with snapcraft snap
[10:57] <mvo> sergiusens: will snapcraft snap also run the click-reviewers-tools automatically?
[10:58] <oparoz> Hello guys, I didn't RTFM, but I was just wondering. Can we have several snaps installed and communicte with one another? Redis snap, Libreoffice snap, all usable from a webapp snap?
[11:01] <dholbach> davidcalle, let me know when you have time
[11:02] <popey> is this expected when i update http://paste.ubuntu.com/15471238/ - to 4.4.0-1004-raspi2+20160321.17-52 ?
[11:05] <davidcalle> dholbach: I do now :)
[11:06] <dholbach> yes!
[11:20] <kyrofa> Good morning
[11:22] <kyrofa> ysionneau, those scripts are currently specific to the rpi2 image (they need to be generalized), but they're here: https://github.com/owncloud/pi-image/tree/master/image-creation-tools
[11:36] <sergiusens> mvo, I need to make it run it; but I'm waiting for stabilization of the whole infra for that (wrt click review)
[11:36] <sergiusens> as it might just end up confusing with all the churn
[11:38]  * ogra_ tickles pitti with bug 1547033 ... would be nice to have that fixed before final release ;)
[11:41] <ogra_> sergiusens, https://github.ubuntu.com/96boards/linux ??
[11:41] <ogra_> (from your blogpost)
[11:42] <ogra_> sergiusens, i assume there sneaked some wishful thinking in to take over github with ubuntu ?
[11:44] <sergiusens> ogra_, lolz
[11:44] <sergiusens> ogra_, let me fix that :-P
[12:00] <kyrofa> sergiusens, elopio whew, so those examples were failing for everyone?
[12:02] <sergiusens> kyrofa, yes, I dug into it last night; it is related to the snappy changes that landed yesterday
[12:02] <kyrofa> sergiusens, ah, okay
[12:03] <sergiusens> kyrofa, first -> binary_name = appname if appname == snapname else "snapname.appname"
[12:03] <sergiusens> second, PWD for apps changed again
[12:03] <sergiusens> to be PWD
[12:03] <sergiusens> kyrofa, now the testing infra is broken ;-)
[12:03] <kyrofa> sergiusens, yeah, and a number of environment variables were removed, too
[12:08] <kyrofa> sergiusens, I see an opencv failure as well... trying to track that down
[12:09] <ogra_> mvo, do you think we can do anything about the umount error messages on shutdown (i see a lot red on reboot)
[12:09] <mvo> ogra_: what is that? do you have some more details?
[12:09] <ogra_> mvo, /writable and some bind mounts cant be unmounted
[12:10] <mvo> ogra_: hm, I check
[12:10] <ogra_> i think we should just skip unmounting altogether, call sync and remouont ro
[12:10] <ogra_> and not spit out an error :)
[12:14] <pitti> ogra_: followed up to the bug, mind having a look?
[12:15] <ogra_> pitti, i'll adjust that and we'll see :)
[12:15] <pitti> ogra_: cheers
[12:16] <ysionneau> kyrofa: thx !
[12:17] <kyrofa> sergiusens, does the opencv example work for you on xenial? I'm getting libmvec errors
[12:17] <kyrofa> ysionneau, no problem
[12:18] <sergiusens> kyrofa, well the examples tests runs them, so I hope they do
[12:19] <kyrofa> sergiusens, yeah mine failed... and it fails locally as well. I'll rerun them just to be safe
[12:21] <noizer> What interfaces are there available for network?
[12:21] <kyrofa> jdstrand, haha, using indent in the launcher now?
[12:21] <sergiusens> kyrofa, don't run retest this as it will fail :-)
[12:21] <jdstrand> kyrofa: yeah, I am spending some time in there :)
[12:22] <kyrofa> sergiusens, :(
[12:22] <jdstrand> mvo, ogra_: where do you want to drop -all-root?
[12:22] <ogra_> jdstrand, for os snap builds
[12:23] <ogra_> (we need the system-user-owned files and dirs there)
[12:24] <jdstrand> background: -all-root is required to verify snaps from untrusted sources
[12:24] <jdstrand> otherwise I can't resquash
[12:24] <jdstrand> an os snap is of course trusted
[12:25] <jdstrand> I'm pretty sure if I remove -all-root from the resquash we are going to get different users at some point, if not today
[12:25] <jdstrand> but I can try
[12:25] <jdstrand> ogra_: what about the kernel snap?
[12:26] <ogra_> jdstrand, there it doesnt matter .. nor for the gadget
[12:26] <kyrofa> sergiusens, ah, I was able to get rid of my local failure by upgrading gcc, g++ and libc6-dev
[12:26] <jdstrand> ok
[12:26] <sergiusens> jdstrand, I've been doing kernel snaps with all-root just fine
[12:26] <jdstrand> ok good
[12:26] <sergiusens> kyrofa, weird situation, abi breakage again?
[12:26] <ogra_> it is only important for the system daemons to have their users around
[12:26] <jdstrand> hopefully I can just remove -all-root if it is an os snap and it will work. but I might have to disable the resquash for them
[12:26] <kyrofa> sergiusens, yeah not sure. Everything is broken!
[12:28] <sergiusens> kyrofa, tests seem to be running fine now for your stuff ;-)
[12:30] <jdstrand> mvo, ogra_: I added a card for -all-root and os snaps
[12:30] <ogra_> thanks !
[12:31] <ysionneau> will the ubuntu-device-flash available at http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash be packaged for ubuntu desktop 16.04 ?
[12:33] <ogra_> ysionneau, there is a replacement in the works called ubuntu-image, though i was hoping mvo pushes the changes for bridging the time til thats ready if it takes longer
[12:33] <kyrofa> mvo, yeah still worth landing I say
[12:33]  * ogra_ isnt sure what the actual ETA for ubuntu-image is ... sergiusens knows though
[12:35] <sergiusens> ogra_, you didn't join the meeting yesterday; so you didn't figure it out
[12:35] <kyrofa> popey, I just noticed you tried to install the owncloud-pi gadget. Are you just looking for the owncloud snap?
[12:35] <sergiusens> ogra_, now you might
[12:36] <ysionneau> ogra_: ah ok
[12:36] <ogra_> sergiusens, yeah, i totally missed while being busy releasing snaps to the store
[12:42] <ogra_> ppisati, do you happen to have auboot binary for the rpi3 ?
[12:42]  * ogra_ is to lazy to compile one :P
[12:52] <ysionneau> hmmmm, so when snapcraft says 'architectures' when trying to build a gadget snap, it means?
[12:53] <popey> kyrofa: yeah, i just thought I'd try installing that
[12:53] <kyrofa> popey, oh okay, so not really looking for anything in particular?
[12:55] <popey> well, owncloud in particular, yeah :)
[12:58] <sergiusens> ysionneau, it means we have a bug :-)
[12:58] <sergiusens> ysionneau, can you log one?
[12:59] <kyrofa> popey, oh, just try `snappy install owncloud`
[12:59] <ysionneau> you mean can I file a bug report ?
[12:59] <sergiusens> ysionneau, yes please https://bugs.launchpad.net/snapcraft/+filebug
[12:59] <sergiusens> ysionneau, I will add it to the 2.6 work due tomorrow
[12:59] <popey> kyrofa: on 16.04?
[12:59] <kyrofa> popey, indeed
[12:59] <ysionneau> I'm really not used to your bugtracker and I don't even have an account
[12:59] <ysionneau> but I guess it's the occasion
[12:59] <popey> kyrofa: ok
[12:59] <ysionneau> let me try that...
[13:01] <kyrofa> popey, the gadget snap only exists for creating an image with the owncloud snap preinstalled
[13:03] <kyrofa> sergiusens, I swear every time I run the example tests I get one more failure. I'm up to 4 now
[13:03] <sergiusens> kyrofa, yeah I see the same
[13:03] <sergiusens> fgimenez, any help ^
[13:03] <sergiusens> ?
[13:04] <kyrofa> The opencv failure is the same one I just got rid of locally by updating
[13:04] <kyrofa> I wonder if the others are similar
[13:05] <ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560481
[13:06] <popey> kyrofa: does it start automatically once installed?
[13:07] <kyrofa> popey, yes, though it takes a moment to generate mysql creds and stuff. Check the syslog
[13:07] <kyrofa> popey, you'll see apache waiting for creds, and mysql initializing
[13:07] <kyrofa> popey, on the rpi2, maybe a few moments ;)
[13:08] <popey> it's been a while.
[13:08] <sergiusens> kyrofa, ogra_ jdstrand https://github.com/ubuntu-core/snapcraft/pull/391
[13:09] <popey> kyrofa: no apache or mysql processes running
[13:09] <ogra_> sergiusens, looks good
[13:09] <kyrofa> popey, hmm, see errors in the syslog then?
[13:09] <popey> [340124.599445] audit: type=1400 audit(1458651897.178:59): apparmor="DENIED" operation="capable" profile="owncloud.canonical_mysql_9.0.0ubuntu1" pid=10400 comm="mysqld" capability=24  capname="sys_resource"
[13:10] <popey> kyrofa: ah, works on my edge pi2, but not my stable pi2
[13:10] <popey> guess this is expected?
[13:10] <kyrofa> popey, uh oh, no it's not
[13:10] <popey> heh
[13:10] <kyrofa> popey, but I just released in an attempt to fix that
[13:11] <kyrofa> popey, I apparently failed
[13:11] <popey> no worries
[13:11] <kyrofa> popey, can you give me the errors on the stable?
[13:11] <popey> any particular logs?
[13:12] <popey> http://paste.ubuntu.com/15471936/
[13:12] <popey> that's dmesg last bunch of lines
[13:12] <kyrofa> popey, just the syslog where they fired up. Those denials are normal
[13:12] <ysionneau> hope my bug ticket is clear enough sergiusens
[13:14] <popey> ricmm: fyi, the youtube-streamer demo (I think it's yours?) spams the syslog every 5 seconds after install http://paste.ubuntu.com/15471942/
[13:18] <sergiusens> ysionneau, no worries; I know what you are after :-)
[13:19] <sergiusens> ysionneau, in any case, gadget snaps in they future will be arch specific
[13:19] <sergiusens> so this is rather a remporary thing
[13:19] <ppisati> ogra_: yep
[13:19] <ogra_> i cant even get a purp out of mine (i finally built an aarch64 one)
[13:19] <ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/uboot.bin
[13:20] <ppisati> ogra_: and here is an ubuntu img, if you want to do some debug etc
[13:20] <ppisati> ogra_: http://people.canonical.com/~ppisati/ubuntu_embedded/ubuntu-embedded-16.04-raspi3.img.xz
[13:20] <ogra_> well, i hopefully only need a gadget snap :)
[13:21] <ppisati> ogra_: +1
[13:21] <ogra_> bah+
[13:21] <ogra_> reading uboot.env
[13:21] <ogra_> *** Warning - bad CRC, using default environment
[13:21] <ogra_> missing our patch
[13:22] <ogra_> ppisati, how exactly did you build it ?
[13:23] <ppisati> ogra_: you mean the steps?
[13:23] <ppisati> export ARCH=arm; export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-
[13:23] <ppisati> make rpi_3_32b_defconfig
[13:23] <ogra_> ppisati, oh, 32bit ?
[13:23] <ppisati> make ...
[13:24] <ppisati> ogra_: yep
[13:24] <ogra_> ah, there is a special config ... thats my error
[13:24] <ppisati> ogra_: my uboot binary is of some days ago
[13:24] <ppisati> ogra_: i think back then there was no 64b option
[13:25] <ogra_> rpi_3_defconfig defaults to 64 in swarrens branch
[13:25] <ppisati> i just noticed that
[13:26] <ogra_> grmpf
[13:26] <ogra_> still doesnt boot
[13:26] <ogra_> i suspect my trusty gcc is to old or something
[13:26] <ppisati> ogra_: i'm on wily FWIW
[13:39] <didrocks> popey: it's mine, and yeah, it will spam you until you configure it!
[13:39] <popey> :(
[13:39] <didrocks> popey: which is better than failing IMHO
[13:39] <didrocks> we can maybe just make it print once
[13:39] <popey> my poor sd card
[13:39] <popey> it's been spamming for days
[13:39] <didrocks> why did you install something without having it running?
[13:40] <popey> to look at it
[13:40] <didrocks> (hem, look at the logs, you have way more spammer ;))
[13:40] <popey> I can't believe you asked that question
[13:40] <didrocks> but didn't configure it, so didn't look at it? :p
[13:40] <popey> i wanted to see what was in the package, I didn't expect my syslog to be spammed for days as a result. "I'll configure that later"
[13:40] <popey> "NO, YOU MUST CONFIGURE IT NOW!"
[13:41] <popey> And I'll keep reminding you until your SD card wears out :)
[13:41] <didrocks> popey: the issue is that if we didn't spam regularly, how would you know days after what to put in it?
[13:41] <popey> Documentation
[13:41] <popey> a README perhaps is the standard way
[13:41] <didrocks> no way to expose the README in snappy
[13:41] <popey> I can find it in the directory it's installed in
[13:41] <didrocks> (forget people looking at the source git branch)
[13:42] <didrocks> hum, I'm unsure
[13:42] <didrocks> at least, it should print it once, ok
[13:42] <popey> Thunderbird doesn't spam my syslog if I don't configure a mail account.
[13:42] <didrocks> yeah, but configuring it is easier than snappy
[13:42] <popey> Debateable :)
[13:42] <didrocks> and you have a walkthrough
[13:43] <popey> I don't believe that spamming the syslog is ever a right answer to "How should we tell the user that the app isn't configured"
[13:43] <ogra_> ppisati, no go :( not sure why
[13:43]  * ogra_ just built on a wily machine 
[13:43] <didrocks> popey: remember you are not in the regular case, you are in the one installing something but not using it. However, I do agree, I can spam you once
[13:44] <didrocks> popey: then, you go to answer people asking how to configure it :)
[13:44] <didrocks> popey: mind opening a bug on the demo branch?
[13:44] <didrocks> I'll do that on Friday
[13:44] <popey> link?
[13:44] <didrocks> http://github.com/ubuntu-core/demos
[13:44] <popey> (I strongly disagree that people don't install and not configure stuff)
[13:45] <didrocks> popey: I guess the real SD card issue is something else though, look at the logs you have, and yeah, we need ubuntu core to care about this
[13:47] <popey> didrocks: done.
[13:47] <didrocks> popey: link?
[13:47] <popey> https://github.com/ubuntu-core/demos/issues/2
[13:48] <ogra_> ppisati, was there any script i need to run ?
[13:48] <ppisati> ogra_: oh yeah, after yui build the uboot binary
[13:48] <ppisati> ogra_: you need to run...
[13:49] <jdstrand> sergiusens: ack, thanks
[13:49] <ogra_> i thought i remembered mkknlimage ... but cant find it
[13:51] <ppisati> ogra_: mkknlimg
[13:51] <ppisati> ogra_: https://github.com/raspberrypi/tools/blob/master/mkimage/mkknlimg
[13:51] <ysionneau> sergiusens: is there something I can do in my snap.yaml to temporary work around the issue to keep working?
[13:52] <sergiusens> ysionneau, use `snappy build` for now
[13:52] <ysionneau> ah, works, thanks!
[13:53] <kyrofa> ysionneau, note that will be going away soon, so move back to snapcraft once the bug is fixed
[13:53] <ysionneau> allright, noted, thanks!
[13:58] <ogra_> sigh .. no go
[13:58] <fgimenez> sergiusens, no idea, it seems that 3 of the failures are consistent in each execution. we have a new test image fwiw, iirc that caused problems previously
[14:00] <ysionneau> how can I make a kernel snap? any example?
[14:05] <kyrofa> ysionneau, did you see the new Snapcraft release announcement? And sergiusens blog post?
[14:07] <ysionneau> kyrofa: was it on snappy-devel ?
[14:07] <ysionneau> I subscribed to this ML on the 10th of feb
[14:08] <kyrofa> ysionneau, snappy-app-devel
[14:08] <ysionneau> ah, I should subscribe to this one then
[14:08] <kyrofa> ysionneau, indeed!
[14:08] <kyrofa> Check the archives, sent out about 10 hours ago
[14:08] <ysionneau> done.
[14:08] <ysionneau> thx
[14:09] <ysionneau> https://lists.ubuntu.com/archives/snappy-app-devel/2016-March/000645.html o/
[14:09] <ysionneau> awesome!!
[14:11] <sergiusens> ysionneau, bug reports welcome :-)
[14:11] <ysionneau> ah, you need to have snapcraft build your kernel, maybe I can hack something by creating a squashfs out of my already built kernel+modules+initrd
[14:12] <ysionneau> $ snapcraft --target-arch arm64 < !!!!!
[14:12] <ysionneau> --target-arch ? :)
[14:12] <ysionneau> so snapcraft is beginning to have some cross compilation notions ?
[14:12] <ogra_> ppisati, i dont really get it ... do you do anything special ?
[14:12] <ogra_> ppisati, i cant even get a burp out of the board with any uboot binary i build
[14:13] <ppisati> ogra_: raspi3, right?
[14:14] <ogra_> ppisati, yeah ... which compiler do you use ? just the gcc-5 eabihaf ?
[14:14] <ogra_> *hf
[14:16] <sergiusens> ysionneau, only for kernels
[14:17] <ysionneau> but can any other plugin get the --target-arch value?
[14:18] <ysionneau> I'll have a look anyway
[14:18] <ysionneau> it would be cool if I can make my Alchemy plugin use that
[14:18] <ysionneau> so that I don't need to set the TARGET_CPU via environmnent variable
[14:23] <ppisati> ogra_: don't you get to the uboot console?
[14:23] <ppisati> ogra_: i mean, nothing
[14:23] <ppisati> ogra_: zero output on the serial?
[14:23] <ogra_> nothing
[14:23] <ogra_> rightr
[14:23] <ppisati> ogra_: oh wait
[14:23] <ppisati> ogra_: is it the first time you use it?
[14:23] <ogra_> if i copy yours in place it gets me the console but obviously the snappy patches are missing
[14:24] <ogra_> yes
[14:24] <ogra_> copying mine back in place gets me total silence on the serial
[14:24] <ppisati> ok
[14:24] <ppisati> let me try to rebuild one
[14:25] <ogra_> mind throwing http://paste.ubuntu.com/15472180/ in ?
[14:25] <ogra_> ppisati, you are using the swarren rpi_dev branch ?
[14:25] <ppisati> yes
[14:26] <ogra_> and only --dtok as option to mkknlimg ?
[14:26] <ogra_> (ro also --283x=
[14:26] <ogra_> --283x)
[14:26] <ogra_> *or
[14:27] <ogra_> (though it doesnt seem to make any difference here )
[14:27] <ogra_> my only idea is that we use different compilers or so
[14:27] <sergiusens> kyrofa, fwiw, I see opencv failing now too (on the builders)
[14:28] <kyrofa> sergiusens, urgh. Do the builders update first?
[14:28] <sergiusens> ysionneau, implement set_target_machine in your plugin
[14:31] <sergiusens> kyrofa, we can ask elopio like live now :-)
[14:31] <kyrofa> sergiusens, good idea
[14:32] <kyrofa> elopio, standup?
[14:33] <ppisati> ogra_: i just compiled the tip of rpi-dev and uboot doesn't work here either
[14:33] <ogra_> aha
[14:35] <ogra_> do you knwo which commit you used ?
[14:36] <ppisati> ogra_: ok
[14:37] <ppisati> ogra_: git checkout -b rpi_dev_32bok f135e8f
[14:37] <ppisati> ogra_: make rpi_3_32b_defconfig
[14:37] <ppisati> ogra_: make ...
[14:37] <ppisati> ./mkknlimg --dtok --ddtk --283x u-boot/u-boot.bin myuboot.bin
[14:37] <ppisati> and it will work
[14:37] <ppisati> just tested
[14:38] <ppisati> either he broke 32bits or we are doing something wrong with the latest
[14:38] <ppisati> but this will work
[14:39] <ogra_> hmm git acts up
[14:41] <ogra_> ogra@styx:~/all-snaps/rpi3/u-boot$ LC_ALL=C git checkout -b rpi_dev_32bok f135e8f
[14:41] <ogra_> fatal: Cannot update paths and switch to branch 'rpi_dev_32bok' at the same time.
[14:41] <ogra_> Did you intend to checkout 'f135e8f' which can not be resolved as commit?
[14:42] <ogra_> ppisati, thats after a fresh: git clone git://github.com/swarren/u-boot.git
[14:43] <ppisati> ogra_: i wonder if he deleted that commit, and the corresponding object is not present in the upstream repo anymore
[14:43] <ogra_> :(
[14:43] <ppisati> ogra_: i can give you a copy of my uboot tree
[14:43] <ppisati> ogra_: until we find what's going on
[14:43] <ogra_> yes please ... just tar it up or so
[14:46] <ppisati> it's tarring...
[14:53] <ogra_> swamped under hot tar ?
[14:56] <ppisati> ogra_: http://people.canonical.com/~ppisati/u-boot.tgz
[14:56] <ogra_> thx !!!
[14:56] <ppisati> ogra_: today i got a new internet connection and a new router
[14:56] <ogra_> cool ... how fast ?
[14:56] <ppisati> ogra_: my firewall&c is a bit fucked up ATM
[14:56] <ppisati> 100Mbit / 50Mbit
[14:56]  * ogra_ just switcvhed to 50/10 
[14:56] <ppisati> d / u
[14:57] <ogra_> the best i could get here
[14:57] <ogra_> (after 10 years with 2/2 ...)
[14:57] <ppisati> i guess you live far from a city
[14:57] <ogra_> i live in the middle of a city :P
[14:57] <ppisati> doh!
[14:57] <ppisati> :)
[14:57] <ogra_> germany is a third world country wrt internet speed
[14:58] <ppisati> you must something really bad to your isp then
[14:58] <ppisati> neeee
[14:58] <ppisati> italy is worst
[14:58] <ppisati> i justgot lucky
[14:58] <ppisati> i have FTTH
[14:58] <ogra_> we dont even have 2% fiber coverage afaik
[14:58] <ogra_> and DSL max speed is around 100MBit ... but you have to be lucky
[14:59] <ppisati> here vodafone is selling 300 / 30 fiber
[14:59] <ppisati> but i didn't want to switch isp
[14:59] <ogra_> (my wire could go up to 70 but then it would get shaky ... old cables ... )
[14:59] <Trevinho> ppisati: I told you to do that... :-)
[14:59] <ppisati> (now i'm on fastweb / swisscom)
[14:59] <ppisati> Trevinho: you have fweb too? or vodafone?
[14:59] <Trevinho> ppisati: vodafone, but using telecom actually.
[15:00] <Trevinho> ppisati: I mean, they've not their fiber network here yet (building atm)
[15:00] <ppisati> Trevinho: yeah, i was scared about downtime, etc
[15:00] <ppisati> Trevinho: so i got an upgrade from my existing isp
[15:00] <Trevinho> ppisati: i've to say it's reaaaaally good in that terms. I was worreid, but it's not like their bad adsl
[15:00] <ogra_> in most of germany the copper is still from the 70s ... i think thats the main prob
[15:01] <ppisati> ogra_: i think pretty much everywhere copper sucks
[15:01] <ppisati> ogra_: i must admit, having real fiber popping out of your wall is very nice :)
[15:01] <ogra_> yeah
[15:21] <ogra_> ppisati, ok, now i end up with FTD errors
[15:21] <ogra_> *FDT
[15:24] <ogra_> Hit any key to stop autoboot:  0
[15:24] <ogra_> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
[15:24] <ogra_> No FDT memory address configured. Please configure
[15:24] <ogra_> the FDT address via "fdt addr <address>" command.
[15:25] <ogra_> i got device_tree_address=0x02000000 in config.txt and also have my env set up to use fdt addr 0x02000000
[15:38] <ogra_> ppisati, do you have your uboot.env.in somewhere ?
[15:45] <ysionneau> sergiusens: it seems I need a snapcraft.cfg or something to use the kernel plugin?
[15:45] <ysionneau> or else the load_config will return {} and the  storeapi.download() will fail
[15:49] <sergiusens> ysionneau, oh, maybe a bug is in order; but you need to `snapcraft login` first
[15:50] <ysionneau> ah!
[15:50] <ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/uboot.env
[15:50] <ogra_> ppisati, i'm looking for the content, not the blob :)
[15:50] <ppisati> ogra_: heh :)
[15:50] <sergiusens> ysionneau, it's necessary to obtain the generic initrd found in the os snap
[15:51] <kyrofa> elopio, examples tests are still failing it seems
[15:51] <ysionneau> sergiusens: works after snapcraft login :) bear in mind I'm a snapcraft noob ! thx !
[15:51] <ppisati> ogra_: http://pastebin.ubuntu.com/15472788/
[15:51] <sergiusens> ysionneau, no worries; your bug reports will be welcomed as we want to provide the easiest experience possible
[15:51] <ppisati> ogra_: i'm out for a bit
[15:52] <ogra_> ppisati, ok, i cant seem to load any devicetree at all
[15:52] <ogra_> looks like you dont do anything different in your env
[15:52] <ppisati> ogra_: which firmware version are you using?
[15:53] <ogra_> ppisati, the one from your package in the "embedded" PPA
[15:53] <ppisati> ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+sourcepub/6187265/+listing-archive-extra
[15:53] <ogra_> right, exactly that
[15:53] <ppisati> ogra_: and the dtb is called...
[15:53] <ppisati> bcm2710-rpi-3-b.dtb?
[15:53] <ogra_> and the dtb from the latest 4.4. kernel
[15:54] <ysionneau> sergiusens: cool :) done! https://bugs.launchpad.net/snapcraft/+bug/1560553
[15:54] <ogra_> (though by now i tried all of them upstream, our kernel, and from your test img)
[15:54] <ogra_> ppisati, right
[15:54] <ppisati> if you skip the dtb in memory, you load it from uyboot and pass it to the kernel
[15:54] <ppisati> ogra_: does it work?
[15:54] <ogra_> ah, we dont have a concept of that in snappy ... i'll try
[15:55] <ogra_> (we always use what the blob gives us in ram since we need overlay support)
[15:57] <ogra_> U-Boot> fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
[15:57] <ogra_> reading bcm2710-rpi-3-dtb
[15:57] <ogra_> ** Unable to read file bcm2710-rpi-3-dtb **
[15:57] <ogra_> hmm
[15:58] <ogra_> oh, copy paste messes up the uboot shell
[15:58] <ogra_> fun
[15:59] <ppisati> ah
[15:59] <ppisati> fuck me
[16:00] <ppisati> sudo ./mkknlimg --dtok ../../u-boot/u-boot.bin myuboot.bin
[16:00] <ppisati> fixed the uboot in memory problem for me
[16:00] <ppisati> try it out
[16:00]  * ppisati really rushes out now, biab
[16:00] <ppisati> ogra_: ^
[16:00] <ogra_> ok
[16:01] <sergiusens> elopio, fantastic :-/ http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/317/testReport/junit/test_busybox/BusyBoxTestCase/test_busybox/
[16:05] <kyrofa> sergiusens, that's the opencv error
[16:05] <kyrofa> sergiusens, so something isn't updated
[16:05] <elopio> cannot find /lib/x86_64-linux-gnu/libmvec.so.1
[16:06] <kyrofa> elopio, yeah, I fixed that by updating gcc g++ and libc6-dev
[16:07] <kyrofa> I assume it was actually libc though
[16:07] <elopio> kyrofa: sergio added apt-get upgrade.
[16:07] <elopio> ah E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
[16:08] <kyrofa> elopio, ah, so it didn't actually happen
[16:08] <elopio> fgimenez: do you have a good solution in mind to make sure that the slaves are always up-to-date before jobs run?
[16:09] <elopio> maybe a nightly redeploy?
[16:11] <elopio> sergiusens: that solution might not be too good, because it forces us to have one single execution at a time.
[16:11] <elopio> that means that if we have three PRs that want to run tests, the last one will have to wait like 2 or 3 hours.
[16:11] <sergiusens> elopio, what solution? the hackish thing I did?
[16:11] <elopio> yes, apt-get in the test script.
[16:12] <sergiusens> where should it go?
[16:12] <elopio> on the other hand, we are ok with only one apt-get upgrade per day-ish, so it's fine to let the other jobs fail when they can't get the lock.
[16:12] <elopio> sergiusens: I don't know, that was my question for fgimenez.
[16:13] <fgimenez> elopio, nightly redeploy sounds very good, that way we can make sure we have the versioned code up to date
[16:14] <elopio> fgimenez: we would have to trigger also the regeneration of the dockers, right?
[16:14] <fgimenez> we can begin with the current (and weak) validation and improve it as we find holes
[16:14] <sergiusens> elopio, fgimenez can we force a redeploy now?
[16:14] <elopio> sergiusens: I'm forcing an upgrade now.
[16:14] <sergiusens> ok, whatever gets the job done
[16:15] <fgimenez> elopio, the engine can stay, only the containers should be updated
[16:15] <elopio> redeploying when there's a queue of pending executions is not that good.
[16:15] <ogra_> crap
[16:16] <ogra_> bah, no mvo
[16:16] <fgimenez> elopio, but before any new redeploy we need to fix the extraction of the config.xml files of the jobs
[16:17] <elopio> fgimenez: you mean, removing the old and keeping just the new ones?
[16:17] <fgimenez> elopio, yep, keeping the ones that come with the container
[16:18] <elopio> ogra_: heads up that I'm enabling now the dput job from master. Could you do your thing after the new deb is in place so we get the new version in edge?
[16:18] <ogra_> elopio, what deb is that ?
[16:18] <ogra_> ubuntu-snappy(-cli) ?
[16:18] <elopio> ogra_: yes. take a look: http://162.213.35.179:8080/job/github-snappy-daily-ppa/
[16:19] <elopio> it's currently dputing to a test ppa. I've just changed it to do it from now on on the image ppa.
[16:19] <ogra_> elopio, hmm,. that shoudl go to the archive, no ?
[16:19] <ogra_> we are not supposed to use PPAs in 16.04
[16:20] <elopio> ogra_: for edge, I think we must use PPAs. I wouldn't want to put to the archive directly from master.
[16:20] <elopio> once we are ready to promote to stable it's when we should update the archive, I think.
[16:21] <ogra_> elopio, well, the ubuntui-core snap doesnt make a difference between edge/stable ... it is just building from the archive (which you can override from the PPA but we are supposed not to)
[16:21] <ogra_> we dont have any separate ubuntu-core snap build
[16:22] <elopio> ogra_: the edge you published yesterday was build from the image ppa, right?
[16:23] <ogra_> elopio, it has the PPA enabled but we removed all xenial packages from there
[16:23] <ogra_> (apart from the dragonboard kernel which will be moved ot the archive this week)
[16:24] <ogra_> elopio, the point is that we cant have PPA snappy in ubuntu-core when we release it ... this is the official snap
[16:24] <ogra_> we would need some ubuntu-core-edge snap for that ... that would mean to introduce a completely new product on cdimage
[16:24] <ogra_> (not really trivial)
[16:26] <elopio> ogra_: but, don't you agree that we shouldn't update the archive until we know that this snappy package is stable?
[16:26] <ogra_> elopio, we should, but we cant do the testing in the production snap
[16:27] <elopio> so, yes, we have a circular mess here.
[16:27] <ogra_> right
[16:28] <ogra_> we can indeed do it like you want until release
[16:28] <ogra_> after all the 16.04 ubuntu-core snap isnt officially released yet
[16:28] <ogra_> but the problem needs solving
[16:29] <elopio> ogra_: what if the PPA has only this ubuntu-snappy deb?
[16:29] <elopio> Then, we use the PPA only as a staging place for this deb, but is built using all the dependencies from the archive. Every day, we dput a new ubuntu-snappy to this ppa. Every day, you take this new ppa and build a snap. Every day, we publish this snap to edge.
[16:29] <elopio> Once we are ready to go to stable, we both promote the snap and push the deb into the archive?
[16:30] <ogra_> elopio, you would have to delete the deb from the PPA before we build the official snap
[16:30] <ogra_> each time
[16:32] <elopio> ok, there's a step missing. What I don't like is to have to generate a new snap. I want just to promote the same snap we put earlier into edge.
[16:32] <elopio> but that breaks your requirement of not using the ppa for the official snap.
[16:33] <sergiusens> elopio, there is no problem with putting a new snappy-cli in the archive
[16:33] <sergiusens> few will directly consume it
[16:33] <sergiusens> unless you really don't trust it; then automating this step is not really good
[16:33] <elopio> sergiusens: isn't it the same package that will be used for snappy-dimension on classic ?
[16:33] <sergiusens> they will in the end consume the snap
[16:34] <sergiusens> elopio, yes they will btw
[16:35] <elopio> I still don't like updating the archive once a day.
[16:35] <sergiusens> elopio, what shall we do with https://github.com/ubuntu-core/snapcraft/pull/388 ?
[16:35] <sergiusens> are we waiting on something?
[16:36] <elopio> ogra_: where does this no-ppa requirement come from? If the PPA only has the exactly same deb that will go to the archive, the result is the same when we use the ppa or the archive.
[16:36] <ogra_> elopio, sabdfl
[16:36] <ogra_> elopio, in 16.04 only the archive should be used
[16:36] <ogra_> updates only via SRU
[16:36] <sergiusens> elopio, the no PPA requirement makes perfect sense; it should have never been a PPA
[16:36] <elopio> sergiusens: we are waiting on the slaves to dist-upgrade
[16:37] <sergiusens> elopio, ah, ok, thanks :-)
[16:37] <elopio> but if we want a daily edge, then we would have to SRU every day.
[16:38] <ogra_> elopio, which wont fly with the SRU rules :)
[16:38] <ogra_> SRUs need to stay 2 weeks in quarantaine
[16:39]  * ysionneau flooding bugs
[16:39] <elopio> so that makes it even bad if we don't want a daily edge.
[16:39] <sergiusens> ysionneau, what else did you find?
[16:39] <ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560570
[16:39] <elopio> let's say we have a two week cycle. At the end of the second week we want to release, but we will have to put the version for two weeks in quarantine
[16:39] <ogra_> elopio, well, we would need to have a whole cdimage setup for an ubuntu-core-edge
[16:40] <ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560569
[16:40] <ogra_> elopio, which is possible but quite some work, nothing i can "just do"
[16:40] <elopio> ogra_: but I also don't want an ubuntu-core-edge. I just want the same package to be promoted from edge -> stable
[16:43] <ogra_> elopio, well, then your daily builds need to go to the archive
[16:43] <elopio> ogra_: I think that for me, the least bad option of what you told me is to generate the edge snap from the ppa. Once we are ready to move to stable, put the deb into the archive and generate the stable snap from the archive.
[16:44] <elopio> it kind of invalidates part of the testing we do during the week, but it's not terrible.
[16:44] <elopio> all the other options look worse to me. ogra_: what's your prefered option?
[16:44] <ogra_> well, not using the PPA :)
[16:45] <ogra_> or getting permission to use it all the time ...
[16:45] <elopio> ogra_: so with not using the PPA do you mean, daily pushes to the archive, or no daily edge?
[16:45] <ogra_> daily to the archive
[16:46] <ogra_> but that wont fly witgh the SRU policy
[16:47] <elopio> ok, I'll send an email. sergiusens: does what I said make sense to you? Or am I missing another requirement here?
[16:49] <sergiusens> ogra_ and ppisati, can you comment on https://bugs.launchpad.net/snapcraft/+bug/1560570 please. I feel estranged
[16:50] <ysionneau> or maybe it's just a need for tegra (x1?) kernels ?
[16:50] <ysionneau> but by looking at the file path, it seems arm64 generic
[16:50] <ogra_> sergiusens, i'll leave that to ppisati
[16:50] <sergiusens> ysionneau, it confuses me since I'm not a kernel guy and I see 64bit and 32bit mixups in there
[16:50] <ysionneau> yep
[16:50] <ysionneau> but I can confirm that in our build system we also set CROSS32CC
[16:51] <ogra_> ysionneau, any reason to not use an aarch64 gcc ?
[16:51] <ysionneau> it's consistent with the web link I've put
[16:51] <sergiusens> ysionneau, seems hackish tbh
[16:51] <sergiusens> ogra_, https://devtalk.nvidia.com/default/topic/894945/jetson-tx1/jetson-tx1/post/4742474/#4742474
[16:51] <ysionneau> ogra_: no idea, it's what we use here and it's also what's on the web link
[16:51] <ysionneau> the kernel is compiled using aarch64 toolchain, but a few parts are compiled using "VDSO32C" makefile variable
[16:52] <ysionneau> which is set from CROSS32CC
[16:53] <ogra_> oh my
[16:53]  * ogra_ agress with sergiusens ... seems hackish
[16:53] <ysionneau> or maybe ... https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/powerpc/Makefile
[16:54] <ysionneau> do something like CROSS32CC = $(CC) -m32
[16:54] <sergiusens> ysionneau, yeah, powerpc is 32bit :-)
[16:55] <ogra_> ppc32tegra ?
[16:55] <ogra_> :)
[16:55] <ysionneau> o/
[16:56] <ysionneau> only source I find for this hack is https://devtalk.nvidia.com/default/topic/917802/issue-with-building-nvidia-kernel-for-tx1/ and https://devtalk.nvidia.com/default/topic/923810/jetson-tx1/rebuilding-the-tegra-tx1-kernel-from-source/
[16:57] <sergiusens> ysionneau, fwiw I marked this invalid as you can solve it in your snapcraft.yaml https://bugs.launchpad.net/snapcraft/+bug/1560569
[16:58] <kyrofa> sergiusens, elopio still waiting on the upgrade? How are you guys seeing that, anyway?
[16:58] <sergiusens> kyrofa, I can't see anything; I'm shooting blanks ;-)
[16:58] <sergiusens> err, shooting in the dark :-)
[16:59] <kyrofa> sergiusens, well, where did you put the dist-upgrade in the first place?
[16:59] <ysionneau> sergiusens: arg sorry!
[16:59] <kyrofa> sergiusens, or was that in that one git repo?
[16:59] <elopio> kyrofa: I'm dealing with the last slave.
[16:59] <sergiusens> kyrofa, inside the jenkins instance; but they removed that in favor of something else
[16:59] <elopio> I found the problem: libc-dev-bin : Depends: libc6 (> 2.23) but 2.21-0ubuntu6 is installed
[17:00] <sergiusens> elopio, dist-upgrade?
[17:00] <sergiusens> ysionneau, no worries
[17:00] <ogra_> ppisati, http://paste.ubuntu.com/15473201/ ... but sadly it hangs there (with blinking cursor though)
[17:00] <elopio> sergiusens: yes, solved with install -f and dist-upgraded again.
[17:00] <elopio> should be done soon.
[17:00] <sergiusens> ysionneau, I still have to think about that CC thing; you can do it from the outside (as in `CCXXXX=xxxx snapcraft --target arm64`) if you want
[17:01] <ysionneau> yes for now I do export it from my shell before running snapcraft
[17:01] <ysionneau> it's not a blocker for me
[17:01] <ysionneau> I have to confess I'm not a Tegra kernel export either ... so I don't know if it's a good thing for you to integrate that
[17:01] <sergiusens> ysionneau, k; I'll leave the bug open in case more people run into it; this one I guess will go in if the population seeing it is huge
[17:01] <ysionneau> but I need it to compile
[17:02] <ysionneau> btw I've tried -m32 from aarch64 toolchain, does not seem OK :o
[17:02] <sergiusens> ysionneau, from the bc thing and others it seems it is an android kernel this is based out of
[17:02] <ysionneau> let me ask but it's highy probable
[17:03] <ysionneau> at least I see some android merges in the git history
[17:07] <sergiusens> ysionneau, thought so :-)
[17:08] <sergiusens> elopio, so are we good?
[17:08]  * sergiusens is getting anxious ;-)
[17:08] <sergiusens> I bet kyrofa is too
[17:08]  * kyrofa is indeed, he has all sorts of stuff queued up
[17:08] <elopio> sergiusens: good, but the slave is still unpacking debs.
[17:09] <elopio> they are slow. Maybe we should use the slaves only to direct scripts to scalingstack instances.
[17:11] <elopio> ok, done. I'm retesting my branch.
[17:14] <kyrofa> Thanks elopio! Hopefully that fixes things
[17:15] <ysionneau> allright, kernel snap is done o/
[17:19] <ysionneau> sergiusens: your kernel plugin works well o/ thanks!
[17:41] <ysionneau> any idea what this could be? http://paste.ubuntu.com/15473724/
[17:46] <ogra_> ysionneau, you dont need --developer-mode with the all-snaps u-d-f
[17:46] <ogra_> tough the issue looks like something with your gadget
[17:49] <Laney> snappy friends
[17:50] <Laney> I was looking at doing the seed change for xenial that you are asking for
[17:50] <Laney> but... https://paste.ubuntu.com/15473751/
[17:50] <ogra_> Chipaca, ^^
[17:50] <ogra_> i assume they would rather seed ubuntu-snappy-cli to not get the systemd services installed
[17:50] <ogra_> s/would/should/
[17:52] <sergiusens_> elopio, kyrofa we are back in business
[17:52] <kyrofa> sergiusens_, YES!
[17:52] <ogra_> you business people you
[17:54] <elopio> \o/
[17:55] <Laney> ogra_: I'm off in 5 minutes - maybe you can execute the seed/meta change when someone waks up?
[17:55] <Laney> https://bugs.launchpad.net/ubuntu/+source/ubuntu-snappy/+bug/1548887
[17:55] <ogra_> Laney, well, *if* someone wakes up
[17:56] <Laney> sure
[17:56] <ogra_> not sure if mvo planned to come back today ... and Chipaca's IRC client is a zombie since the telegram group exists
[17:57] <Laney> It's really weird
[17:57] <ogra_> (would really be nice if he could just shut it down)
[17:57] <Laney> sometimes this seems urgent
[17:57] <Laney> but nobody is actually pushing the change
[17:57] <Laney> so I don't really understand what's going on tbh
[17:58] <ogra_> well, i think it is just the wrong package ... i suggested -cli before but smoser said he'd like ubuntu-snappy instaed
[17:58] <ogra_> i think the systemd units come from the ubuntu-snappy package and -cli will omit them ...
[17:58] <Laney> mvo re-confirmed on the bug after I asked
[17:58] <ogra_> you definitely do not want them
[17:59] <Laney> was assuming that having it on the beta is a good thing
[17:59] <Laney> but hey ho
[17:59] <ogra_> yeah, it would be
[17:59] <ogra_> but if you cant reach anyone who can make that decision ...
[17:59] <Laney> nobody is chasing though
[18:00] <Laney> and they're apparently asking for the wrong thing
[18:00] <Laney> so ?!?!?!
[18:00] <ogra_> *shrug*
[18:00] <Laney> you see what I mean :P
[18:00] <ysionneau> btw where can I fetch the os snap? (or do I need to generate it? how?)
[18:00] <ysionneau> I used the os.snap which appeared in my kernel snap parts dir
[18:00] <ogra_> ysionneau, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[18:00] <ogra_> just grab the one for your arch
[18:01] <ysionneau> should it be the arch of the kernel or user space?
[18:01] <ogra_> or simply use: -os ubuntu-core.canonical
[18:01] <ogra_> that will pull the last released one from the store
[18:01] <sergiusens_> ogra_, no need for .canonical iirc
[18:01] <ogra_> oh ?
[18:01] <ogra_> when was that dropped ?
[18:01] <jdstrand> kgunn: is it possible to test the mir snap in a qemu vm?
[18:02] <sergiusens_> ogra_, not dropped; it is optional
[18:02] <ogra_> well, it used to be mandatory for a while :)
[18:02] <ysionneau> not sure what's wrong with my gadget snap
[18:02] <sergiusens_> jdstrand, using virt-manager it is easier; you need a different display
[18:02] <sergiusens_> ogra_, we setup an alias :-
[18:02] <sergiusens_> :-)
[18:02] <ogra_> ah
[18:02] <Chipaca> looking...
[18:02] <ogra_> Chipaca, !
[18:02] <ogra_> alive !
[18:02] <Chipaca> ogra_, not a zombie! just even more lagged
[18:02] <ogra_> :D
[18:03] <ysionneau> http://paste.ubuntu.com/15473862/ here is my meta.yaml
[18:03] <jdstrand> sergiusens_: you're saying it will work in virt-manager?
[18:03] <Chipaca> people always ping me at 6pm :-(
[18:03] <ysionneau> 19:01 < ogra_> or simply use: -os ubuntu-core.canonical < ok!
[18:03] <Chipaca> um
[18:03] <ogra_> ysionneau, that will just produce an empty gadget
[18:03] <ogra_> you dont define any files
[18:03] <Chipaca> i don't think you should install those services on a system with apt-get
[18:03] <kgunn> jdstrand: right, that's my understanding is that other vm's don't have nicely configured display/gfx stacks
[18:04] <jdstrand> I can use virt-manager all day :)
[18:04] <jdstrand> ok, thanks
[18:04] <ogra_> Chipaca, thats why i suggested to seed -cli instead
[18:05] <ogra_> (assuming that doesnt ship the units)
[18:05] <kgunn> jdstrand: curious, you just getting around to display-server policy stuff?
[18:05] <Chipaca> this is mvo territory i'm afraid
[18:05] <ogra_> then we have to wait i guess
[18:07] <jdstrand> kgunn: sadly no. still blocked, but hopefully soon
[18:07] <jdstrand> I wanted to test a launcher change
[18:07] <kgunn> ok, lemme know if you have any probs
[18:08] <Chipaca> ogra_, i've not looked in to what's needed; it might be ubuntu-snappy itself, with the services adhoc-disabled somehow
[18:08] <Chipaca> i've just never had to look :-)
[18:08] <ogra_> heh, same here
[18:10] <Chipaca> i'd love to *know*, of course, but my bandwidth is only so much
[18:10] <ysionneau> ogra_: I think I'm fine with an empty gadget for now
[18:10] <ogra_> ysionneau, but ubuntu-devicel-flash isnt :)
[18:10] <ysionneau> ok =)
[18:11] <ogra_> you use the ubuntu-device-flash binary from mvo's all-snaps dir ?
[18:11] <ysionneau> yes
[18:11] <Chipaca> ok, back to making dinner for me
[18:12] <ogra_> Chipaca, enjoy
[18:12] <ysionneau> ah indeed I've put a dummy file and now it goes forward to the next error
[18:12] <ogra_> good
[18:12] <ysionneau> ../paros_gadget/paros_1.0_all.snap failed to install: exit status 2
[18:12] <ysionneau> o/
[18:12] <ysionneau> maybe it should be absolute path
[18:13] <ysionneau> nop, same
[18:13] <ogra_> no, its the content
[18:14] <ogra_> so you have a dtb file thats called tegra-x1 ?
[18:14] <ysionneau> no
[18:14] <ysionneau> stat("/tmp/diskimage828293005/tegra-x1.dtb", 0xc8202e0448) = -1 ENOENT (No such file or directory) <= indeed
[18:14] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/meta/snap.yaml
[18:15] <ogra_> have a look at that file
[18:15] <ysionneau> yes I based my snap from this and from the gadget documentation
[18:15] <ogra_> you need the boot-assets ... and your platform entry should be the same as your dtb
[18:15] <ysionneau> allright, let's do this
[18:17] <ysionneau> maybe this field should be renamed "dtb" instead of platform :o
[18:17] <ysionneau> so that it's more clear what you are supposed to put
[18:17] <ogra_> well, the gadget is supposed to becompletely re-worked (i learned today) ...
[18:19] <ysionneau> ahah, ok
[18:24] <ogra_> elopio, so whatever we'll do with the PPA stuff, lets for now just do it as you said ... (and perhaps start a mail discussion about how we want to finally fix this process) ... and let me know when i should hit the button for a build
[18:24] <ogra_> we are still in pre-release after all
[18:25] <elopio> ogra_: I sent the mail. Let me dput...
[18:25]  * ogra_ doesnt want to be the blocker
[18:32] <elopio> ogra_: oh, you are not at all. We just need to finish the details of how to connect everything.
[18:32] <elopio> ogra_: in his update from yesterday, mvo added a changelog entry for the upload. Should I do that?
[18:33] <elopio> with my current dch, I get a version that's lower than his.
[18:34] <ogra_> then it wont be pulled in
[18:34] <ogra_> you need a higher version
[18:35] <ogra_> (livecd-rootfs is dumb ... it just pulls the latest available versions)
[18:43] <jdstrand> kgunn: so, I installed it and rebooted and see this in the logs: http://paste.ubuntu.com/15474097/
[18:44] <jdstrand> kgunn: I'm using 'vmvga': http://paste.ubuntu.com/15474110/
[18:44] <jdstrand> this is the same setup I would use to run unity7
[18:44] <elopio> ogra_: no, that makes sense. But what's the trick to get a version number like 1.7.3+20160322ubuntu1~ppa3 automatically?
[18:45] <elopio> I'm not sure how to increase the date of the previous entry.
[18:46] <kgunn> jdstrand: hmmm....fails on the vt arg
[18:46] <jdstrand> kgunn: this is on 16.04. is there a mir snap in the store for 15.04?
[18:46] <jdstrand> I can try there too
[18:47] <kgunn> jdstrand: i took down the 15.04 one i think
[18:47] <jdstrand> that would explain why I couldn't snappy search it
[18:47] <jdstrand> is https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ up to date?
[18:47] <kgunn> jdstrand: yes
[18:48] <kgunn> jdstrand: and i just now tested against snapcraft2.5
[18:48] <kgunn> and it worked fine
[18:48] <jdstrand> kgunn: do you have a vm where this works? if so, can you paste 'virsh dumpxml <vmname>'
[18:49] <jdstrand> kgunn: I downloaded the mir from the store. should I be using snapcraft like in the instructions?
[18:49] <kgunn> jdstrand: nah, that snap should work fine
[18:49] <kgunn> jdstrand: i'm using Virtual Machine Manager
[18:49] <kgunn> which
[18:49] <jdstrand> yeah that's fine
[18:49] <jdstrand> what is the name of the vm?
[18:50] <jdstrand> in a terminal you should be able to do 'virsh list --all'
[18:50] <jdstrand> to see the names
[18:50] <ogra_> elopio, you dont want to increase the date but turn ubuntu1 to ubuntu2
[18:50] <jdstrand> then if you could paste 'virsh dumpxml <your vm name>' that would be great
[18:50] <ogra_> (that is what will effectively land in the archive)
[18:51] <elopio> ogra_: that's easy, with -i. But that would still be less than the one mvo uploaded. Should I delete that deb?
[18:51] <jdstrand> kgunn: ^
[18:51] <kgunn> jdstrand: https://pastebin.canonical.com/152534/
[18:52] <jdstrand> ah qxl
[18:52] <jdstrand> kgunn: thanks!
[18:52] <elopio> ogra_: also I can't combine -i, with the --local to add the prefix ppa# that mvo told me to use.
[18:52] <elopio> these tools...
[18:56] <jdstrand> kgunn: ok, progress. a black screen :)
[18:57]  * jdstrand builds the mir client snap
[19:02] <kgunn> ;)
[19:08] <jdstrand> I have clocks :)
[19:08] <jdstrand> kgunn: ^
[19:09] <kgunn> i assumed you ooo'd and awww'd
[19:09] <jdstrand> kgunn: curious if it makes sense to upload mir-client-demo or soemthing
[19:09] <ogra_> elopio, well, you could assemble the version externally and just pass it to dch
[19:09] <jdstrand> kgunn: it is very cool-- I did! :)
[19:13] <elopio> ogra_: yes, I went that way. Failed to build on armhf, I'm reporting a bug.
[19:13] <ogra_> elopio, fun
[19:21]  * ogra_ calls it a day
[19:25] <elopio> have a good night ogra_!
[19:25] <ogra_> and you a good rest of the day :)
[20:10] <kyrofa> elopio, is sergio off for a bit?
[20:11] <elopio> kyrofa: I didn't notice when he left. Maybe lunch?
[20:12] <kyrofa> elopio, he pinged out a bit ago. Yeah, maybe
[20:13] <elopio> kyrofa: I'm about to take a lunch break too. I quickly saw your clean branch, which looks awesome
[20:14] <elopio> I'll look at it all when I'm back.
[20:14] <kyrofa> elopio, oh good! Excellent, thank you :) . I've got some more ready when that one lands
[20:14] <elopio> kyrofa: this state, partial clean and resume look nice. What do you think about putting some integration tests in there?
[20:15] <kyrofa> elopio, yeah I'll do that when things are actually cleaned (that PR is just preliminary stuff)
[20:16] <elopio> great. To be clear, I'm not asking for this branch :)
[20:16] <elopio> we can define some important use cases, and make sure that the binaries work for them with tests. Maybe leave that for next week, and I'll help you writing some.
[20:24] <kyrofa> Sounds good
[20:31] <ezraholm50_TAM> hey guys, could anyone help me get webmin running on snappy?
[20:37] <genii> !webmin
[20:38] <genii> ...so probably not
[20:45] <ezraholm50_TAM> ah great... thnx for the heads up
[20:45] <ezraholm50_TAM> anyway, aside from snap, it works great on my 5 ubuntu 14 to 16 systems
[20:46] <ezraholm50_TAM> i just need to easily figure out some stuff that i would rather do with some kind of a UI then on cmd line
[20:46] <ezraholm50_TAM> checking out deb2snap right now
[20:57] <roadmr> is there a way to get "snapcraft snap" to rebuild if files changed? Right now I have to rm -rf parts stage which feels super kludgy
[21:04] <kyrofa> roadmr, indeed, it's yucky. Unfortunately not just yet, but it's in progress
[21:10] <roadmr> kyrofa: thanks :) I can do it that way in the meanwhile, no problem
[21:13] <roadmr> is there a way to run a command at snap installation time? use case is e.g. a custom ssh server for which I'd like to generate keys when the snap is installed (rather than shipping the same set of keys to every user :)
[21:15] <kyrofa> roadmr, no, but you can check to see if keys already exist, and if not, generate them
[21:25] <roadmr> kyrofa: that works! thanks :)