[00:18] <elopio> dustino: sorry, I missed your question. We are not working on making it installable on the emmc.
[08:15] <fgimenez> good morning
[08:23] <zyga> good morning
[08:35] <dholbach> good morning
[08:35] <noizer> good morning :D
[08:41] <noizer> mvo do you know when the update will be available today?
[09:05] <mvo> noizer: yes!
[09:06] <noizer> mvo yihaaaa lets snap the world today :D
[09:06] <mvo> noizer: xz is running right now
[09:06] <noizer> mvo ok thx :D
[09:06] <mvo> noizer: eta something like 15min
[09:09] <noizer> mvo ok where can I find the release notes?
[09:11] <mvo> noizer: I will send a mail on snappy-devel@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/snappy-devel
[09:11] <mvo> noizer: later today
[09:12] <noizer> ok
[09:14] <noizer> mvo are there already products in production that uses snappy?
[09:14] <mvo> noizer: https://people.canonical.com/~mvo/all-snaps/ its there now for amd64, enjoy and let me know if you notice any issues
[09:15] <noizer> i saw but i need the Raspberry pi one xD
[09:15] <mvo> noizer: yes erle robotics for example http://erlerobotics.com/blog/snappy-store/
[09:15] <mvo> noizer: and https://insights.ubuntu.com/2015/10/21/snappy-core-unlocks-iot-value-within-the-dell-edge-gateway-5000-series/
[09:15] <mvo> noizer: those are all 15.04 based currently though. but 16.04 will be much better
[09:15] <mvo> even better I should say :)
[09:16] <noizer> haha :D thats why i'm developing on snappy 16.04 :D
[09:17] <noizer> are you building the other images too (raspberry pi)?
[09:17] <noizer> mvo
[09:18] <mvo> noizer: yes, as we speak :)
[09:19] <mvo> noizer: rpi2 will take a bit longer because of the manual testing I do on the sd card, but I think in 1h at latest it will be up too
[09:20] <noizer> mvo thx thats best service with on going development i ever had :D
[09:20] <noizer> :p
[09:22] <mvo> :-D
[09:31] <JamesTait> Good morning all!  Happy Wednesday and happy Carrot Cake Day! 😃
[09:38] <Mikaela> Where do you get thowe days?
[09:43] <davmor2> JamesTait: ^ I think that one is directed at you and I can't remember the link
[09:43] <JamesTait> Mikaela, various sources on the internet, some "official", some just silly.
[09:44] <Mikaela> ack
[09:44] <JamesTait> daysoftheyear.com and nationaldaycalendar.com both had today's.
[09:45] <JamesTait> wellcat.com is another.
[09:45] <Mikaela> I must take a look sometime
[10:04] <mvo> noizer: rpi2 is available now as well on https://people.canonical.com/~mvo/all-snaps/
[10:18] <noizer> mvo thx :D
[10:27] <noizer> mvo writing the image to my sd card :D
[10:28] <dholbach> mvo: did we drop 'snappy search'?
[10:29] <dholbach> mvo: did you see anything like this before? http://paste.ubuntu.com/14864883/
[10:29] <mvo> dholbach: what version of snappy are you on right now?
[10:30] <mvo> dholbach: I'm preparing a mail for this right now
[10:30] <dholbach> mvo: I used the amd64 all-snaps image from you
[10:30] <mvo> dholbach: if you could give me the snappy list output that would be great
[10:31] <dholbach> mvo: http://paste.ubuntu.com/14864906/
[10:32] <mvo> dholbach: this is probably fallout from the switch from package.yaml to snap.yaml and/or fallout from the store changes. so I'm super keen to figure out the root
[10:32] <dholbach> ok...
[10:32] <dholbach> mvo: and 'snappy search' is gone as well?
[10:32] <dholbach> or will there be a new incarnation of it?
[10:32] <mvo> dholbach: yeah, its now "snap find"
[10:33] <dholbach> ah, great - thanks
[10:34] <mvo> dholbach: I prepare a mail now that explains the changes a bit more :)
[10:35]  * dholbach hugs mvo
[10:50] <mvo> dholbach: sorry for the trouble, it looks like the store is really confused - https://bugs.launchpad.net/software-center-agent/+bug/1541317 is causing the issues
[10:51] <mvo> dholbach: which means I may need to create new images because right now the all-snap image is defaulting to the stable channel for the os/kernel snaps. but maybe that is actaully not a bad thing :)
[10:56] <didrocks> do we have an example of a seccomp override file?
[10:56] <didrocks> it seems that snappy install isn't happy when parsing one, just containing "setpriority" for instance
[11:03] <didrocks> mvo: maybe you would know a good example with an appamor and seccomp override?
[11:03] <didrocks> (maybe it expects a yaml file?)
[11:08] <mvo> didrocks: here are some examples https://github.com/ubuntu-core/snappy/blob/master/snappy/security_test.go#L832
[11:09] <pitti> Chipaca, mvo: still any trouble with the wait4net service?
[11:09] <mvo> pitti: I still did not manage to work on the proper fix :( the images were broken and I had to unbreak them first
[11:10] <mvo> pitti: while you are here :) is there a trivial setting to make /tmp not a tempfs with systemd? for snappy we ran into various issues in the testsuite with /tmp being too small
[11:11] <didrocks> mvo: isn't that supposed to point to a file rather?
[11:11] <didrocks> (from the doc)
[11:11] <pitti> mvo: it defaults to not being a tmpfs
[11:11] <mvo> didrocks: that was in 15.04 iirc that it was a file
[11:11] <didrocks> mvo: I saw "deprecated" in the tests, so I didn't dare trying
[11:11] <pitti> mvo: so, revert whatever you do to make it a tmpfs -- most likely, /etc/fstab?
[11:11] <mvo> didrocks: and in 15.04 its json
[11:11] <mvo> pitti: aha, ok, thats good to know, I will dig around
[11:11] <didrocks> mvo: hum, do you have one example?
[11:12] <mvo> didrocks: a 15.04 example?
[11:12] <pitti> mvo: could also be that snappy enables /usr/share/systemd/tmp.mount
[11:12] <didrocks> yeah :)
[11:12] <didrocks> with this file
[11:12] <didrocks> I was expecting it to be a seccomp-like file
[11:12] <pitti> mvo: but check /etc/fstab first
[11:12] <pitti> mvo: but how would that work on snappy? isn't the root fs r/o?
[11:12] <mvo> ta, will do
[11:12] <pitti> mvo: or a tmpfs by itself?
[11:12] <mvo> pitti: root is r/o but we can just bind mount the writable partition on top of /tmp
[11:12] <mvo> the tmp of the writable partition
[11:13] <pitti> mvo: I thought with "all snaps" you'd have an empty root tmpfs as /, and then bind-mount the r/o .snaps into it?
[11:13] <didrocks> because if it's json, what do we put as a key?
[11:13] <pitti> or did I misunderstand this?
[11:13] <didrocks> I guess maybe something like: { "syscalls": ["setpriority"] }?
[11:13] <pitti> mvo: ah, so I guess change /tmp in fstab to be a bind mount to /writable/tmp instead of a tmpfs?
[11:14] <mvo> pitti: yeah, I think that is what we need to do. thanks. for some reason I was thinking that systemd would do that by default and we had to do something in ubuntu to disable it (it being the tmpfs on /tmp)
[11:14] <mvo> didrocks: I need to check for the details, jdstrand is the master of this but I look for an exmaple now
[11:15] <pitti> mvo: upstream does, but we don't in Debian/Ubuntu as that discussion is still ongoing and haven't decided yet
[11:15] <mvo> didrocks: https://github.com/ubuntu-core/snappy/blob/15.04/snappy/security_test.go#L253 maybe?
[11:15] <didrocks> mvo: thanks! yeah, an example would be awesome!
[11:15] <mvo> pitti: thanks, thats super useful
[11:15] <noizer> mvo i got a strange error http://pastebin.com/LnZW0TDA do you know what i did wrong?
[11:16] <didrocks> mvo: trying in progress :)
[11:16] <didrocks> (didn't spot that one in tests)
[11:18] <didrocks> mvo: \o/
[11:18] <didrocks> yeah, yaml it was :)
[11:18] <didrocks> mvo: extra bonus question, our package needs to be configure for credentials before being able to work
[11:18] <didrocks> so, we have a systemd service
[11:19] <didrocks> I would like to set "only starts if file <foo> is present" with the correct service key
[11:19] <didrocks> can we extend the systemd .service generated file?
[11:19] <didrocks> (and extra bonus: apart from the config script calling sudo snappy service start…<>, is there a less hackish way of restarting the service after a config change?)
[11:21] <tsouza_> hello all, I'm trying to run latest stable snappy through vagrant. The VM won't boot, it keeps rebooting really fast and I can not see whats going on in the virtualbox gui... any clue anyone?
[11:30] <mvo> noizer: unfortunately not, how can I reproduce this?
[11:31] <mvo> didrocks: we can not expand the .service right now, the service itself would have to check that currently. we can talk about expanding our .service files of course
[11:31] <noizer> mvo I try to install the plugin python2 and that don't works but when i try to install python3 then it works
[11:32] <noizer> so i think python2 is bugged
[11:32] <noizer> But i need python2 because one lib is only supported in python2 at the moment
[11:32] <mvo> noizer: via snapcraft? sergiusens and kyrofa are your experts for that
[11:32] <noizer> yea via snapcraft
[11:33] <noizer> ok are the online at the moment?
[11:33] <mvo> noizer: I suspect a issue with snapcraft, unfortunately I'm not a expert there
[11:33] <noizer> ok np i will ask them :D
[11:33] <mvo> noizer: not yet but should be soon, they on the americas
[11:33] <noizer> ok thx
[11:34] <didrocks> mvo: the thing is that the service checks, and so, it tries to restart
[11:34] <didrocks> upon 3 times
[11:34] <didrocks> then, nothing "triggers" it once properly configured
[11:35] <opny> hi all! I'm using snapcraft with autotools plugin, I have an issue over libssl  (I guess) as it does not find openssl/bn.h May it be related to the snapcraft build?
[11:35] <mvo> didrocks: right, lets talk about adding code for start conditions then in a bit (after lunch?)
[11:35] <didrocks> mvo: sure!
[11:38] <dholbach> sergiusens: should snapcraft pull in request_toolbelt from somewhere?
[11:39] <dholbach> I got
[11:39] <dholbach> No module named 'requests_toolbelt'
[11:39] <noizer> sergiusens Hi, got a strange thing going with snapcraft. I want to install python2 as plugin but when i try i got this error: http://pastebin.com/LnZW0TDA
[11:40] <noizer> sergiusens but i tried it now with python3 and it gave me the same issue
[11:40] <didrocks> mvo: however, we don't have any /var/lib/appamor/profiles dir (or content anymore) :/
[11:41] <didrocks> seems something burned it
[11:41] <didrocks> not even sure how we can recreate it. We try to install an old snap, and nothing happens
[11:43] <mvo> didrocks: its in /var/lib/snappy/apparmor now iirc
[11:43] <mvo> didrocks: in 16.04
[11:43] <mvo> didrocks: or is this on 15.04?
[11:45] <dholbach> sergiusens: I'm also seeing this happening: http://paste.ubuntu.com/14865381/
[11:45] <dholbach> which might not work when not running with sudo
[11:48] <didrocks> mvo: it's 15.04, for mwc
[11:48] <didrocks> mvo: /var/lib/snappy/apparmor/profiles was deleted
[11:48] <didrocks> by installing a snap
[11:49] <didrocks> (the whole directory)
[11:49] <mvo> didrocks: *urgh*
[11:49] <didrocks> yeah, doesn't sound "yummy" :/
[11:50] <didrocks> is there any way to at least for now, tell apparmor to rebuild all profiles?
[11:50] <mvo> didrocks: is this reproducable? I think its click-appamor handling this dir on 15.04
[11:50] <mvo> didrocks: I don't know, jdstrand will know how to tell apparmor to rebuild all profiles
[11:51] <didrocks> mvo: we did install it multiple times, we want the demo to work before reproducing (but apparmor/seccomp doc is a little bit of a PITA)
[12:36] <kyrofa> Good morning
[12:36] <torbit> good morning
[12:36] <noizer> kyrofa good morning xD
[12:37] <noizer> I have already a question for you :D
[12:38] <noizer> since the update of the ubuntu core i can't install python anymore as plugin :s
[12:38] <noizer> kyrofa here you get the error http://paste.ubuntu.com/14865381/
[12:39] <kyrofa> noizer, I'm not really sure what I'm looking at, here. However, is your project publicly available? Can I give it a try?
[12:40] <noizer> No it inst available i was developing for it :p
[12:40] <noizer> wait I will give you a my yaml file
[12:41] <kyrofa> noizer, yeah, whatever is causing the failure for you so I can reproduce it here
[12:46] <noizer> wait i will test an other thing just only install python so i can see if it realy python
[12:50] <kyrofa> noizer, for what it's worth seems seem a bit broken on the most recent all-snaps release for me as well
[12:54] <noizer> kyrofa what can we do about it?
[12:54] <noizer> kyrofa i minimized my snap and tested this and got the error http://pastebin.com/nz3pgysu
[12:55] <noizer> and that is since the update from today( for you yesterday night)
[12:56] <kyrofa> noizer, yeah I need to see your project if that's possible
[12:57] <noizer> kyrofa i can't show it because its for the company that i work for
[12:57] <noizer> but yesterday it worked all fine until the update came
[12:57] <kyrofa> noizer, oh you put the YAML in the paste, okay I can work with that
[12:57] <noizer> ok this yaml I tried but normally its correct but it doesn't work :s
[13:06] <noizer> kyrofa do you get the same problem?
[13:07] <kyrofa> noizer, one minute, I have to put out a fire dholbach found for me
[13:07] <dholbach> kyrofa: sorry :)
[13:07] <noizer> kyrofa ok np :D
[13:07] <kyrofa> dholbach, super embarrassing :P
[13:08] <opny> hello, I'm using snapcraft with autotools plugin to build rethinkdb, I have an issue over libssl  (I guess) as openssl/bn.h is not found May it be related to the snapcraft build?
[13:08] <sergiusens> dholbach, sorry need context
[13:08]  * sergiusens just got out of the dentist
[13:09] <dholbach> opny: do you have libssl-dev installed?
[13:09] <dholbach> sergiusens: err... context to which question?
[13:09] <sergiusens> opny, add openssl to the stage-packages
 sergiusens: I'm also seeing this happening: http://paste.ubuntu.com/14865381/
[13:12] <kyrofa> sergiusens, please accept my humble apologies for https://bugs.launchpad.net/snapcraft/+bug/1541349 . After that looks PR is merged I'd be happy to crank out 2.1.1
[13:13] <sergiusens> kyrofa, lets do a 2.1.1
[13:13] <sergiusens> kyrofa, let me get that started
[13:13] <kyrofa> sergiusens, I'm sorry man
[13:13] <sergiusens> kyrofa, its fine
[13:15] <opny> dholbach, sergiusens yes sure, I've tried to add the :i386 one either nut no luck
[13:16] <dholbach> opny: it should be in libssl-dev
[13:16] <sergiusens> kyrofa, I'll fix
[13:16] <dholbach> opny:
[13:16] <dholbach> daniel@daydream:~$ dlocate openssl/bn.h
[13:16] <dholbach> libssl-dev:amd64: /usr/include/openssl/bn.h
[13:16] <dholbach> daniel@daydream:~$
[13:16] <sergiusens> kyrofa, unless you already have
[13:16] <kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/288
[13:17] <sergiusens> kyrofa, I can see that was quickly done ;-)
[13:17] <kyrofa> *sigh*
[13:17] <sergiusens> kyrofa, no worries!
[13:18] <opny> dholbach, uhm, you're right.. It's not on my system, only in stage-packages
[13:18] <kyrofa> sergiusens, fixed
[13:18] <dholbach> opny: using build-packages: you can specify it in the snapcraft.yaml
[13:19] <dholbach> opny: so others using the same recipe will surely have the package installed upon build
[13:19] <sergiusens> dholbach, mind looking at https://github.com/ubuntu-core/snapcraft/pull/288
[13:19] <opny> dholbach, oh, ok thanks... was using the wrong one!
[13:20] <sergiusens> kyrofa, this just means we need integration tests for upload/login/logout
[13:20] <kyrofa> sergiusens, indeed
[13:20] <kyrofa> sergiusens, making the issue now
[13:21] <dholbach> kyrofa: are all these packages required as build-deps?
[13:22] <dholbach> I haven't checked in a while - is this because we run the unit tests during the build?
[13:22] <kyrofa> dholbach, sergiusens perhaps they should be in the test control?
[13:22] <kyrofa> I guess I'm not sure
[13:22] <dholbach> let me check
[13:23] <sergiusens> kyrofa, debian/tests/control pulls in the package deps
[13:24] <dholbach> sergiusens: but that's only for the autopkgtest
[13:24] <sergiusens> dholbach, yeah, I think kyrofa is just nervous now and wants to add the dep everywhere ;-)
[13:24] <dholbach> kyrofa: they're still required - the unit tests are run during the build: https://launchpadlibrarian.net/236098042/buildlog_ubuntu-xenial-amd64.snapcraft_2.1_BUILDING.txt.gz (at about 90% of the log)
[13:24] <kyrofa> sergiusens, yeah paste paste pate
[13:24] <sergiusens> dholbach, it's still in Build-Depends iirc
[13:25] <dholbach> sergiusens, kyrofa: looks like it's a good idea to keep them in build-depends too :-)
[13:25] <sergiusens> in debian/control
[13:25] <kyrofa> Haha, okay good
[13:25] <sergiusens> well, I didn't see them removed
[13:25] <dholbach> sergiusens: I just wanted to check if they're still required as build-deps and it turns out they are :)
[13:25] <kyrofa> Yeah I think dholbach was just checking the whole thing
[13:26] <sergiusens> dholbach, yeah, they are; just for module import if anything else
[13:29] <opny> dholbach, oh no, after adding the build-packages, snapcraft has gone.. python says too many open files http://paste.ubuntu.com/14866019/
[13:29] <dholbach> opny: that should be fixed in snapcraft 2.1
[13:30] <kyrofa> opny, is that snapcraft 1?
[13:30] <opny> dholbach, kyrofa ok, 1.0.1
[13:30] <kyrofa> opny, yeah, that fix is only in 2 I'm afraid
[13:30] <dholbach> kyrofa: maybe the fix for bug 1537705 should be backported?
[13:31] <opny> kyrofa, where may I update my snapcraft to 2.0? git?
[13:31] <dholbach> opny: where did you install snapcraft from?
[13:31] <opny> dholbach, ppa as per docs
[13:32] <sergiusens> kyrofa, while you are at it https://github.com/ubuntu-core/snapcraft/pull/289
[13:32] <opny> dholbach, ppa:snappy-dev/tools
[13:32] <dholbach> kyrofa, sergiusens: ^ where do we land snapcraft 2.x?
[13:32] <sergiusens> dholbach, nice that you made kyrofa the official backporter
[13:32] <sergiusens> dholbach, only on xenial
[13:32] <sergiusens> dholbach, 2.x is only on xenial
[13:33] <kyrofa> sergiusens, haha, I'm the 1.x maintainer, remember?
[13:33] <dholbach> kyrofa: what what? I just asked him because he had just responded in the same context :-)
[13:33] <sergiusens> or we break all 15.04 users; I'm not sure we will backport as soon our deps to xenial will increase
[13:33] <dholbach> don't blame me for giving kyrofa all the hard work
[13:34] <opny> is there a vagrant box for xenial ?
[13:34] <ogra_> sergiusens, it wouldnt work anyway since the concept changed drastically between 15.04 and xenial
[13:34] <kyrofa> opny, the side effect of using Snapcraft 2 is that you can only target 16.04 Snappy
[13:34] <dholbach> sergiusens: isn't it just https://github.com/ubuntu-core/snapcraft/pull/268/files that needs backporting?
[13:34] <sergiusens> dholbach, yes, I was replying in the context of where we publish 2.x
[13:34] <sergiusens> dholbach, and I said, only xenial
[13:34] <ogra_> dholbach, xenial snapcraft produces squashfs snaps by default .... there is no support for that setup in 15.04 images
[13:35] <kyrofa> sergiusens, happy to backport if you give the OK
[13:35] <dholbach> sergiusens: ok
[13:35] <sergiusens> dholbach, backporting things from 2.x to 1.x should be ok :-)
[13:35] <dholbach> ogra_: I know
[13:35] <sergiusens> kyrofa, go ahead
[13:35] <dholbach> guys... I was never suggesting we should backport EVERYTHING
[13:35] <sergiusens> everyone calm down and keep on rolling :-)
[13:35] <kyrofa> opny, thanks for catching that, I'm on it
[13:35] <ogra_> well, we should ... but only if 15.04 stable goes EOL
[13:35] <ogra_> which should happen with the xenial snappy release as i understand
[13:36] <opny> kyrofa, no problem, I'm good a breaking stuff :)
[13:36] <dholbach> ok... too many threads of discussion at the same time ;-)
[13:36] <kyrofa> Hahaha
[13:38] <kyrofa> sergiusens, is https://bugs.launchpad.net/snapcraft/+bug/1541353 the same issue you noticed?
[13:38] <opny> btw, is there a xenial image for amd64 and/or arm I can pick ?
[13:38] <sergiusens> kyrofa, yeah, not sure why `-` is not allowed; maybe pindonga knows
[13:39] <ogra_> kyrofa, thats just because dholbach produces that -buggy package ;) snapcraft is clever, wont let buggy things in ;)
[13:39] <kyrofa> opny, yeah http://people.canonical.com/~mvo/all-snaps/
[13:39] <sergiusens> kyrofa, that's going to 2.2; I'll release it while camping during carnaval ;-)
[13:41] <opny> kyrofa, thank you. Is qemu for arm known to work?
[13:41] <kyrofa> opny, I've used it, though it's dog slow
[13:41] <ogra_> i dont think we actually produce usable snappy images for qemu-system, do we ?
[13:41] <ogra_> (armhf thatis)
[13:42] <pindonga> kyrofa, sergiusens in snapcraft/storeapi/_upload.py there's a regexp for validating the pkg file name
[13:42] <pindonga> - is valid for name
[13:42] <pindonga> so maybe the pkg is missing version or arch?
[13:42] <kyrofa> pindonga, any ideas on bug #1541353 ?
[13:42] <pindonga> kyrofa, we need to find out what the built pkg name is
[13:42] <opny> ogra_, I've tried on 15.04 but network was never picked up and cloud-init failed
[13:43] <ogra_> opny, oh, with what cpu emulation did you run qemu ?
[13:43] <plars> ogra_: around? If you get a chance at some point, I was curious if you had any thoughts about installing snappy on db emmc via fastboot
[13:43] <noizer> kyrofa do you already any idea with my problem :p
[13:43] <kyrofa> ogra_, oh, I was just answering a general "yes, qemu can emulate arm" :P
[13:43] <sergiusens> pindonga, kyrofa I say we remove the regexp, we already have a regexp when we json schema de hell out of it
[13:43] <ogra_> kyrofa, yeah, vexpress and omap3 ;)
[13:44] <kyrofa> noizer, I'm looking at it now
[13:44] <pindonga> sergiusens, fine with me
[13:44] <noizer> kyrofa htx xD
[13:44] <kyrofa> sergiusens, I thought the regex was for extracting the name, not actually _validating_ anything
[13:44] <pindonga> sergiusens, the regexp here was jut to avoid a failure after the file was uploaded (ie, during the scan)
[13:44] <sergiusens> pindonga, in the case of dholbach's bug we might need the full yaml
[13:44] <opny> ogra_, armhf https://github.com/muka/qemu-snappy-experiments#2-use-ubuntu-snappy-not-working
[13:44] <pindonga> ie, a quick sanity check to avoid uploading the file only for the store to fail later
[13:44] <ogra_> plars, only vaguely, i try to not touch any internal disks with our images until we have a recovery installer ... but it shouldnt be hard to modify the EMMc bootloader
[13:45] <sergiusens> pindonga, yeah sounds good, but we fail on the yaml as soon as we load it, so its blocked earlier; I'd be fine with checks, but these regex's have changed so often I got weary of them :-)
[13:45] <dholbach> sergiusens: attached: https://launchpadlibrarian.net/236141324/snapcraft.yaml
[13:46] <plars> ogra_: all I'm really looking for is an automated way to provision it, regardless of what was on it before
[13:46] <pindonga> sergiusens, I'm not opposed to removing the filename check
[13:46] <pindonga> sergiusens, my bet is what's confusing the regexp is the - in the version
[13:46] <ogra_> opny, yeah, you dont really want that ... what would work would be an image thats actually designed for vexpress ..  you cant just re-puropse a rpi image for this
[13:46] <sergiusens> dholbach, try removing the - from the version (or change it to `.`)
[13:46] <plars> ogra_: another option, of course, is using the sd to boot from. But the only control I've found over the sd so far is via the hard switch on the bottom of the board, which is going to be flaky to solder to
[13:46] <pindonga> also, the yaml doesn't include an arch, is that correct?
[13:47] <sergiusens> pindonga, not this one, the internal one has that; I don't think that is the problem as I've uploaded just fine
[13:47] <dholbach> sergiusens: that made it work
[13:47] <pindonga> sergiusens, all that said, I completely agree regexpes are a pain to maintain
[13:47] <pindonga> up to you to remove it
[13:47] <sergiusens> so confirmed, it is just the version check
[13:47] <plars> ogra_: but it does look like I can probably get into fastboot automatically somehow, via the reset button controlled from the uart board, and power control. If I could use that to install to the emmc reliably, it would be something to consider
[13:48] <ogra_> plars, you just need to replace the content of the "boot" partiton on the eMMC with a working u-boot binary ... the rest shoudl be scripting .... well and probably invalidate the u-boot on the SD, then it will always fall back to the internal uboot
[13:48] <ogra_> nothing to solder here
[13:48] <mvo> sergiusens: you mentioned an incorrect service file the other day that had no %h in the SNAP_USER_DATA - what snap was this again?
[13:49] <opny> ogra_, ok thanks, has been interesting anyway
[13:49] <plars> ogra_: I'd like to stay as close as possible to what u-d-f generates though, and not have to change the image we're testing
[13:50] <ogra_> plars, well, u-d-f ignores the fact that an eMMC exists
[13:50] <plars> ogra_: so booting an unmodified sd image would mean I need it to really boot from the sd
[13:50] <ogra_> it will always focus on SD only
[13:50] <plars> apparently that's controlled by gpio_81, but it doesn't seem to be exposed anywhere else as far as I can tell
[13:50] <sergiusens> mvo, that was kyrofa ^
[13:50] <sergiusens> mvo, so I mentioned, kyrofa has the issue
[13:51] <ogra_> plars, did you ask in the #96boards channel ?
[13:51] <plars> but if the image on the sd is bad, or if I need to overwrite it, I would need it to go back to booting something stable off the emmc
[13:51] <kyrofa> mvo, o/
[13:51] <plars> ogra_: not yet, some of this is pretty specific to snappy I think
[13:51] <sergiusens> kyrofa, upload your snap to people.canonical.com if you can
[13:51] <ogra_> plars, right, thjats automatic
[13:51] <dholbach> pindonga: do you know which rev of click-reviewers-tools is used in myapps right now?
[13:51] <kyrofa> sergiusens, sure thing
[13:51] <ogra_> if the SD is broken my board here always falls back to eMMC in any case
[13:52] <ogra_> which is why i said you can just use a clever u-boot on the MMC ... that could pull a new SD image and write it for example ... just invalidate the bootloader on the SD at the end of your test
[13:52] <plars> ogra_: but I also need it to fall back if I'm trying to put a new image on there, so I'd like to have more control over it... or are you saying that for that, we should just dd some zeros to the sd card boot part to make it bad?
[13:53] <ogra_> ... and a reboot would get you into the MMC uboot
[13:53] <sergiusens> dholbach, btw, we have planning meetings on Friday's with kyrofa and elopio for snapcraft; someone once mentioned we could open those up to the public; I have to quarrel against that
[13:53] <pindonga> dholbach, 567
[13:53] <plars> ogra_: gotcha
[13:53] <dholbach> pindonga: can you pull again?
[13:53] <ogra_> plars, yeah, even just into the first partition of the Sd should be enough
[13:53] <pindonga> dholbach, on prod, on staging we're on 572
[13:53] <sergiusens> dholbach, I just have one requirement; hands off keyboard unless you are the triager
[13:53] <opny> Let's say I would like to create an UI via a snap to handle networking or create an access point. Do you think is feasible via a snap?
[13:53] <plars> ogra_: actually, right now with the snappy image, I only get one boot out of it. any boot after that goes to the emmc. Is that a known issue?
[13:53] <dholbach> pindonga: 572 sounds great
[13:53] <pindonga> right, we just need to deploy to prod
[13:54] <pindonga> but you can test on staging
[13:54] <kyrofa> sergiusens, who mentioned that?
[13:54] <ogra_> opny, what kind of UI ... web-UIs surely work already
[13:54] <sergiusens> opny, check the mir guide on the developer site
[13:54] <dholbach> sergiusens: you quarrel against the calls being public? I'm not sure I understand
[13:54] <sergiusens> kyrofa, not you; it was mentioned in one of the community hangouts
[13:54] <kyrofa> sergiusens, oh interesting
[13:54] <sergiusens> dholbach, oh, in one of the community things (video, text, something) someone mentioned making planning public
[13:54] <sergiusens> dholbach, I thought it was you
[13:54] <opny> ogra_ yes a web ui, with simple shell commands or more advanced (networkd?)
[13:55] <sergiusens> dholbach, I am saying I don't mind if our planning meetings are public and open to everyone
[13:55] <dholbach> ah ok, cool :)
[13:55] <dholbach> yeah, let's think about how we can do that best
[13:55] <sergiusens> dholbach, streamed is fine; joining the hangout has 2 reqs, hands off keyboard and see your face
[13:56] <sergiusens> dholbach, seeing the face is a bit controversial; but it is sort of necessary to keep the face to face value
[13:56] <opny> sergiusens, mir-snaps ?
[13:56] <ogra_> opny, afaik there is a network-manager snap in the works ... i guess you could create another snap that talks to it via snapd on a socket or local network port to manipulate networking via snappy config then
[13:56] <sergiusens> dholbach, and seeing someone's face provides a lot of feedback
[13:56] <dholbach> I like that
[13:56] <mvo> ogra_, ppisati: silly question, it appears that am335x-boneblack.dtb is not/no longer part of the kernel tree in xenial? do you happen to know about this? or am I looking at the wrong place?
[13:56] <dholbach> yes, I agree
[13:56] <noizer> kyrofa sorry i cant follow xD let me know when you have a sollution
[13:56] <ogra_> mvo, oh, i havent touched the BBB in ages
[13:56] <kyrofa> noizer, will do
[13:56] <sergiusens> opny, yes https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
[13:56]  * ogra_ has to defer to ppisati 
[13:57] <rickspencer3> if I am running xenail, just $sudo apt-get snapcraft will get me and keep me on the latest, right?
[13:57] <sergiusens> dholbach, speaking of that we should probably take this from mhall and put this into our repo https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
[13:57] <ogra_> rickspencer3, yes
[13:57] <sergiusens> or it will get outdated fast
[13:57] <sergiusens> rickspencer3, correct
[13:57] <mvo> ogra_: no worries, I just wanted to build a "community" maintained one with all snaps and this is my blocker right now
[13:57] <rickspencer3> thanks ogra_ and sergiusens
[13:57] <ogra_> mvo, are you sure you grabbed the right binary ?
[13:58] <dholbach> sergiusens: I'll file a bug for it - I have like 5 things I'm doing at the same time right now :)
[13:58] <opny> sergiusens, ok nice but what is mir in practice? is it a webcontainer?
[13:58] <mvo> ogra_: not entirely, I was still using the artifact from cdimage
[13:59] <opny> sergiusens, found.. sorry
[14:00] <ogra_> ogra@anubis:~/datengrab$ dpkg -x linux-image-4.4.0-3-generic_4.4.0-3.17_armhf.deb unpack/
[14:00] <ogra_> ogra@anubis:~/datengrab$ find unpack/ -name am335x-*|grep boneblack
[14:00] <ogra_> unpack/lib/firmware/4.4.0-3-generic/device-tree/am335x-boneblack.dtb
[14:00] <ogra_> ogra@anubis:~/datengrab$
[14:00] <ogra_> mvo, ^^^
[14:00] <ogra_> seems to be there
[14:00] <mvo> ogra_: hmmm, thanks, I will find out what is causing this
[14:01] <ogra_> (thats the latest xenial binary package)
[14:01] <sergiusens> dholbach, kyrofa https://github.com/ubuntu-core/snapcraft/pull/290
[14:02] <kyrofa> jdstrand, I use your overlay notes every day, by the way
[14:04] <sergiusens> opny, a display server
[14:04] <sergiusens> opny, you have to be clear when you say ui ;-)
[14:05] <sergiusens> opny, if youwant to do something over the web; just use nodejs or go or something you like (look at gopaste or shout in the snapcraft examples)
[14:06] <mvo> ogra_: found the issue, I'm an idiot
[14:06] <mvo> ogra_: but thanks!
[14:06] <zyga> mvo: never, you are just tired :)
[14:06] <ogra_> mvo, i disagree !!!
[14:07] <kyrofa> mvo I just PMd you a link to the snap in question
[14:07] <opny> sergiusens, awesome stuff! Yes I meant the web, sorry :) My doubt is how can I then interact with eg. if* or ip route or iptables et like
[14:07] <opny> sergiusens,  with custom apparmor profiles?
[14:08] <ogra_> opny, there is a ufw snap already
[14:08] <ogra_> you shoudl be able  to talk to it via snapd or some such ... jdstrand might be able to tell you more
[14:08] <ogra_> (for firewall config that is)
[14:08] <kyrofa> mvo, adding an echo to the binary wrapper for ros-example.listener, you can see that SNAP_USER_DATA looks fine. But if you add an echo to $SNAP/command-rosmaster.wrapper (which is launched by systemd) it's missing the home directory
[14:08] <sergiusens> kyrofa, walking back home to make it for standup
[14:08] <kyrofa> sergiusens, sounds good
[14:09] <sergiusens> hopefully the ci tests finish running by then
[14:09] <opny> ogra_, ok thanks. Seems I need to upgrade to 16.04 first
[14:10] <kyrofa> mvo, rather, the home directory seems to be /
[14:11] <kyrofa> mvo, so echoing $SNAP_USER_DATA in the service wrapper gives me //snaps/ros-example.sideload/ILcTLfMVPLca
[14:28] <opny> is there any documentation about 16.04 and topics like snapd or similar ?
[14:31] <wiggleworm> Can someone point me to documentation on how to set a static ip address when using a wifi connection
[14:33] <ogra_> opny, i guess Chipaca can point you to any snapd docs if they exist
[14:35] <ogra_> wiggleworm, http://people.canonical.com/~ogra/snappy/dragonboard/README has some syntax for how to set up wifi with DHCP ... see "man interfaces" on an ubuntu desktop/server for the static part
[14:36] <wiggleworm> ogra_ - thanks - so standard desktop settings for wifi should work for Snappy?
[14:36] <opny> ogra_, is the source in launchpad?
[14:36] <ogra_> wiggleworm, snappy uses /etc/network/interfaces.d …. so yes :)
[14:37] <ogra_> opny, on github i think
[14:38] <wiggleworm> thank you
[14:39] <opny> Chipaca, hello, I was looking for docs about snapd. Do you have anything I could be read about it? Thanks
[14:43] <opny> May use dbus for IPC in a set of snap I would build?
[14:51] <wiggleworm> Can someone show me where on the snappy\Canonical site I submit my snap to the store?
[14:56] <ogra_> wiggleworm, https://myapps.developer.ubuntu.com/
[14:56] <ogra_> (you need to create an account first)
[14:57] <wiggleworm> thank you - I found that site and it did not say it was for Snappy as well - good to know - thank you
[15:01] <elopio> sergiusens: kyrofa: http://autopkgtest.ubuntu.com/packages/s/snapcraft/
[15:01] <elopio> what's tricky is the s.
[15:02] <kyrofa> elopio, ah! Favorited
[15:02] <kyrofa> elopio, thank you :)
[15:07] <sergiusens> dholbach, [ubuntu/xenial-proposed] snapcraft 2.1.1 (Accepted)
[15:08] <dholbach> sergiusens: good work! :)
[15:08] <sergiusens> dholbach, I hope the autopackage tests really work this time, we are so close
[15:09] <dholbach> crossing fingers then :)
[15:10] <jdstrand> didrocks: fyi, /var/lib/snappy/apparmor/profiles is not the right directory for 15.04. you are looking for /var/lib/apparmor/profiles
[15:11] <jdstrand> didrocks: pcoca and I discussed the issues you guys were having. it seems you guys didn't see the notes for 15.04. I gave him all the info
[15:12] <jdstrand> didrocks: as for rebuilding all the profiles on 15.04, you use 'sudo aa-clickhook -f'
[15:12] <didrocks> jdstrand: excellent! Thanks a lot :) (I think we still have a cryptic issue as aa_exec_one or such error without any further info), but we'll keep you posted
[15:12] <jdstrand> kyrofa: re overlay: cool! :)
[15:13] <didrocks> jdstrand: oh great! (we should maybe add a symlink to aa-snappyhook :p)
[15:14] <kyrofa> Chipaca, the other day you mentioned the ability to `snappy shell foo`. But it seems it only works for classic, not any other app. Did I misunderstand?
[15:14] <jdstrand> opny (and ogra_): ufw is an 'app' snap, not a framework. snapd (or anything else in snappy does not expose interfaces for an app to drive in this manner
[15:14] <jdstrand> opny: in other words, you need to do both the web frontend and the iptables/etc backend
[15:15] <ogra_> jdstrand, oh, no snappy config interface you coudl use ?
[15:15] <jdstrand> didrocks: are you trying to execute things from /apps/bin from you snap?
[15:15] <ogra_> (if it exposes snappy config it should also be manageable through snapd)
[15:16] <jdstrand> ogra_: ufw only has rudimentary snappy config. it will likely get some more, but that isn't exposed to other snaps, only the admin
[15:16] <ogra_> ah
[15:17] <didrocks> jdstrand: no, it's a systemd service, so it's a little bit more convoluted to debug
[15:18] <jdstrand> I guess snapd could be used to drive such config, but that is a larger discussion that is happening with ricmm, et al. the whole networking story needs to be defined and then we can see if ufw fits, it at all
[15:18] <jdstrand> (atm, I can only imagine this as shoehorning ufw, so not sure that is the way to go)
[15:19] <jdstrand> anyhoo, that is being discussed elsewhere
[15:19] <ogra_> yeah, i would imagine you can use snapd for this or even just a socket or network port directrly if the snap exposes it .... to flange a UI onto a snap
[15:19] <ogra_> (from another snap)
[15:19] <ogra_> after all it would just be talking to localhost here
[15:20] <jdstrand> didrocks: if you give me the error, I can probably point you in the right direction. an aa-exec error is likely one of two things-- you are trying to execute something in /apps/bin rather than from SNAP_APP_DATA or the profile isn't loaded
[15:20] <jdstrand> that flanging needs to happen in a very controlled manner, since it breaks application confinement
[15:21] <jdstrand> ogra_: ^
[15:21] <ogra_> sure, there needs to be auth or even the bottom servioce snap should define if thats allowed at all
[15:21] <didrocks> jdstrand: will do for sure, thanks for hanging with us ;)
[15:21] <ogra_> but in my imagination i can create a gadget snap that pulls in a handfull of service snaps and one UI snap on top that can manage the others
[15:22] <ogra_> to c4reate my product
[15:27] <mvo> jdstrand: fwiw, I pushed a bbb all-snap image too, I know you have some of those :)
[15:27] <jdstrand> mvo: woo! I do :)
[15:27] <jdstrand> mvo: thanks :)
[15:30] <mvo> yw
[15:31] <opny> jdstrand, ogra_ thanks. I'm looking on how to handle various configuration needs (over http ui). Currently thinking to have rest http proxy to dbus-connected handler/api, if this may work!?
[15:31] <jdstrand> mvo: curious (and this is just curiosity since I have a device that would be fun to move to snappy for 16.04, but I can continue to use server), are we going to have i386 snappy images for 16.04?
[15:32] <jdstrand> opny: you can do that within your snap, yes. you provide the dbus service backend and you provide the webui, then the webui can talk to the dbus service
[15:33] <jdstrand> mvo: why can't I ever remember the answer to that question?
[15:33] <jdstrand> mvo: you don't have to answer the 2nd question :)
[15:33] <beuno> jdstrand, yes, i386 will be one of the supported archs
[15:33] <jdstrand> oh, nice! :)
[15:33] <beuno> 32 and 64bit intel
[15:33] <jdstrand> \o/
[15:33] <beuno> 32 and 64 bit arm
[15:34] <ogra_> now we just need properly supported i386 images :P
[15:35] <xnox> ogra_, beuno - why 32 bit? even atoms are 64-bit these days.
[15:35] <xnox> (i386 that is)
[15:35] <ogra_> xnox, to annoy you and to undermine your attempt of dropping i386 images indeed ;)
[15:35] <beuno> yes.
[15:35] <genii> "because we can"
[15:36] <ogra_> xnox, we dont really have i386 images ... (we produce the artifacts and you can use ubuntu-device-flash to roll an i386 img file, but they are not tested or supported or anything )
[15:36] <ogra_> so no worries :)
[15:37] <beuno> but we will have to produce them for 16.04
[15:37] <opny> jdstrand, Great.. Still, I miss one last thing.. if the snap is confined can I alter eg. interfaces.d/ files? I will need custom apparmor profilles?
[15:37] <ogra_> there *are* intel 32bit only IoT platforms though
[15:37] <beuno> ogra_, 32bit intel is very much a supported architecture for 16.04
[15:37] <beuno> officially supported and tested
[15:37] <ogra_> beuno, oh, thats news to me
[15:37] <beuno> if that doesn't match reality, reality needs to be fixed
[15:37] <xnox> ogra_, beuno, genii - you people hate the planet, build time, and CO2, and waste bandwidth budget =)
[15:37] <ogra_> well, reality is that the hardware is rare :)
[15:38] <beuno> xnox, some people use it as heat in their homes!
[15:38] <ogra_> xnox, thats why i own three porsches ... indeed i do :P
[15:38] <xnox> ogra_, can i hi-jack one, for testing purposes?
[15:38] <ogra_> even two ;)
[15:39] <ogra_> beuno, who came up with that ? sabdfl ?
[15:39] <ogra_> i think actual i386 only HW is really rare
[15:40] <olli> ogra_, our commitment is to deliver 4 reference images
[15:40] <olli> which include 32bit intel
[15:40] <genii> 32bit VM is more efficient and less wasteful than a 64bit VM
[15:40] <mvo> jdstrand: I will clarify about i386 but we can certainly have unofficial ones
[15:40] <ogra_> not sure what testing on 64bit HW will actually gain us to validate these images
[15:40] <beuno> mvo, we totally, 100% have committed to having official i386 ones
[15:41] <ogra_> beuno, and do we know how we will test them ? (we should have actual i386-only HW for that)
[15:41] <ogra_> or do we think kvm testing will be enough
[15:42] <beuno> ogra_, I don't know specifically, I'd expect you fine folks to come up with a great plan!
[15:42] <beuno> we can help where needed
[15:42] <mvo> beuno: oh, cool
[15:42] <olli> mvo, ogra_ I would expect that the key target for 32bit intel is a VM so I am not sure we need to worry about the HW aspect
[15:42] <ogra_> well, thats a QA question indeed .... i just wonder how valid such testing actually is if we dont use actual HW
[15:42] <ogra_> or re-purpose 64bit HW for that
[15:42] <ogra_> olli, ok
[15:43] <mvo> beuno: thanks!
[15:43] <olli> ogra_, I am already talking w/ slangasek about all the official images
[15:43] <ogra_> that cealrifies it :)
[15:43] <ogra_> *clearifies
[15:44]  * olli offers "clarifies"
[15:44] <olli> :)
[15:44] <ogra_> olli, if the target is just 4 we should drop i386 for MIPS instead ;)
[15:45] <ogra_> (will also make 4 in total then)
[15:46] <kyrofa> I know of at least one company that uses 32-bit hardware and have asked me about i368 support in Snappy
[15:46] <ogra_> ah, good
[15:47] <ogra_> if there is demand and we can actually validate the images proper thats indeed fine
[15:47] <beuno> ogra_, and cloud instances
[15:47] <beuno> which is a pretty big market  :)
[15:47] <kyrofa> ogra_, indeed, let me know if you need someone to give it a test drive and I can ping them
[15:48] <ogra_> beuno, thats curious ... assuming the underlying HW is most likely 64bit i wonder what that gains you ?
[15:49] <ogra_> slightly less ram use due to smaller binaries  ?
[15:59] <jdstrand> ogra_, xnox: fyi, I administer a few actual 32 bit boxes. I'm asking cause one would be neat for snappy and it is not ancient (only a few years old)
[16:03] <kyrofa> opny, any chance you could share the YAML that opened too many file descriptors?
[16:04] <kyrofa> opny, I need a test case and the one I thought I had isn't breaking (hate it when things don't break correctly)
[16:05] <opny> kyrofa, sure
[16:07] <opny> kyrofa, here it is https://github.com/muka/rethinkdb.snap/blob/master/snapcraft.yaml
[16:08] <kyrofa> opny, excellent, thank you!
[16:08] <opny> kyrofa, has gone broken after adding build-packages list
[16:08] <kyrofa> opny, but there's no build-packages in here
[16:11] <opny> kyrofa, sorry I pushed my current stuff
[16:12] <kyrofa> opny, I need stuff that makes snapcraft barf. Maybe push into a temporary branch?
[16:12] <opny> kyrofa, here it is
[16:12] <opny> kyrofa, in master, it's broken anyway
[16:13] <kyrofa> opny, oh, I misunderstood-- I thought you said adding the build-packages made it break
[16:13] <kyrofa> opny, so what you gave me should fail?
[16:13] <kyrofa> opny, I'll give it a shot
[16:14] <opny> kyrofa, I moved from stage-* to prod-* and python error popped out
[16:15] <opny> kyrofa, Maybe I've used the wrong syntax?
[16:16] <kyrofa> opny, prod-*? you mean build-*?
[16:17] <opny> kyrofa, yes sorry...
[16:17] <kyrofa> opny, that makes sense-- build-packages aren't installed the same way, so that should "fix" the fd leak
[16:19] <kyrofa> opny, you understand the difference between stage- and build-packages?
[16:20] <opny> kyrofa, not sure, they are 2 different phases and in stage I can hack stuff... right?
[16:21] <kyrofa> opny, not quite-- check this out: https://github.com/ubuntu-core/snapcraft/blob/1.x/docs/snapcraft-syntax.md
[16:21] <kyrofa> opny, stage-packages get staged and end up in the final .snap. build-packages actually get installed on the host
[16:22] <kyrofa> opny, so for example, if you wanted to keep your snap as thin as possible, have the -dev packages as build-packages, and runtime-only packages as stage-packages
[16:24] <kyrofa> opny, what version of Ubuntu are you using to run Snapcraft?
[16:27] <opny> kyrofa, I'm on 14.04 and used snapcraft 1.0.1. Now I'm trying to jump to 2.x with no luck..
[16:27] <kyrofa> opny, hmm... I'm getting 404s when trying to get the packages
[16:27] <opny> kyrofa, the docs on github are far more clear than on the ubuntu website
[16:28] <opny> kyrofa, I messed badly on that..
[16:28] <kyrofa> opny, dholbach has been working on making them autosync
[16:28] <dholbach> kyrofa: we're still struggling with the deployment :-(
[16:29] <dholbach> we're still very close
[16:29] <kyrofa> dholbach, so close! That's alright, we'll get there :)
[16:29] <opny> kyrofa, dholbach formatting seems still a bit incoherent
[16:29] <kyrofa> opny, formatting of the github docs?
[16:30] <opny> kyrofa, no on github is pretty structured. (This is the source of my snap https://www.rethinkdb.com/docs/install/ubuntu/#get-the-build-dependencies)
[16:32] <opny> kyrofa, actually on ubuntu ws is pretty fine either (https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/). It's almost a RTFM problem :)
[16:33] <opny> kyrofa, may I ask you how to get snapcraft 2.x ? I've tried from git / python setup.sh but error arise after install
[16:33] <kyrofa> opny, it only works on xenial
[16:34] <opny> kyrofa, it's ok for me, would like to get the most up to date stuff to work on
[16:34] <kyrofa> opny, it's easy then-- install xenial and `apt-get install snapcraft`
[16:35] <opny> opny, oh.. you mean I must run xenial not "snappy xenial"
[16:36] <opny> kyrofa, oh.. you mean I must run xenial not "snappy xenial"
[16:36] <kyrofa> opny, right
[16:36] <ogra_> you can run snappy xenial and use the classic dimension though
[16:36] <kyrofa> opny, both ways-- it only runs on xenial and it only builds packages for xenial
[16:36] <kyrofa> opny, what ogra_ says is true as well
[16:37] <ogra_> saves you from having to copy around your snaps and gets you the proper build for the architecture you  work on
[16:37] <opny> kyrofa, ogra_ is it too early to try to install on my work pc (currently I'm stuck on 14.04 due to deps, will weep and move to 15.10 in the weekend )?
[16:38] <kyrofa> opny, you can always put it in virtualbox
[16:38] <kyrofa> (or similar)
[16:38] <opny> kyrofa, ok, it is how I run snappy xenial. I'll keep it this way, so. Thank you!
[16:41] <sergiusens> elopio, look at these https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/snapcraft/20160203_155457@/log.gz
[16:41] <sergiusens> elopio, those are first time issues
[16:41] <sergiusens> elopio, of course, new arch ;-)
[16:42] <sergiusens> elopio, "s390x is not supported, please log a bug athttps://bugs.launchpad.net/snapcraft"
[16:42] <sergiusens> elopio, yay, I have a bug in my "report a bug message" :-P
[16:43] <elopio> sudo: no tty present and no askpass program specified
[16:43] <jdstrand> mvo: so.. weird. I now see hello-world.canonical on a 15.04 bbb and a 15.04 amd64 vm 'upgrading' to 1.0.18 again
[16:43] <elopio> I'm getting the same on the lxd runs.
[16:43] <sergiusens> elopio, yeah, that too...
[16:43] <jdstrand> mvo: this time, snappy list -u shows them as upgradable
[16:43] <elopio> sergiusens: lol.
[16:44] <jdstrand> mvo: note, that it stopped for a while yesterday. today it started 43 minutes ago
[16:44] <jdstrand> matiasb: ^
[16:44] <mvo> jdstrand: woah, no I need to check that on my bbb
[16:44] <mvo> jdstrand: but dinner first
[16:44] <mvo> jdstrand: fwiw, a i386 all-snap image is up now too
[16:45] <matiasb> jdstrand, so, you have hello-world 1.0.18 installed, and it is trying to install it again?
[16:47] <kyrofa> niemeyer, hey have you had a chance to go over that launching document?
[16:48] <jdstrand> mvo: re i386> woo! :)
[16:48] <jdstrand> matiasb: precisely
[16:48] <jdstrand> matiasb:
[16:48] <jdstrand> $ sudo snappy list -u
[16:48] <jdstrand> Name          Date       Version
[16:48] <jdstrand> ...
[16:48] <jdstrand> hello-world*  2015-06-19 1.0.18
[16:49] <jdstrand> Feb  3 10:00:21 cho systemd[1]: Started Ubuntu Core Snappy Autopilot.
[16:49] <jdstrand> Feb  3 10:00:21 cho systemd[1]: Starting Ubuntu Core Snappy Autopilot...
[16:49] <jdstrand> Feb  3 10:00:35 cho kernel: [1239804.724808] audit: type=1400 audit(1454515235.320:159): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="hello-world.canonical_usehw_1.0.18" pid=1234 comm="apparmor_parser"
[16:49] <jdstrand> ...
[16:49] <jdstrand> Feb  3 10:00:40 cho snappy[1165]: Name        Date       Version Developer
[16:49] <jdstrand> Feb  3 10:00:40 cho snappy[1165]: hello-world 2015-06-19 1.0.18  canonical
[16:49] <jdstrand> matiasb: snappy list -u output and syslog output
[16:50] <matiasb> jdstrand, ack... that's weird, wondering how the update code decides it should update
[16:50] <jdstrand> matiasb: the profile loads and the final to lines show it is installing
[16:50] <jdstrand> yeah, not sure
[16:50] <jdstrand> I find it particularly curious that it did it for several hours, then didn't, then is again
[16:51] <jdstrand> (ie, yesterday, not last night, and just now)
[16:51] <matiasb> yeah, that's really odd too
[16:55] <mvo> matiasb: it uses the click-metadata endpoint and posts what it has to it
[16:55] <jdstrand> Chipaca: hey, I just updated an allsnaps vm. snappy list doesn't show anything, even with -v. I expected the kernel, os and gadget snaps to be listed...
[16:55] <matiasb> mvo, can you confirm you are passing the right arch/release headers when checking for updates? (since now we can return different values in those cases)
[16:55] <mvo> jdstrand: uh, what image is that that does not show anything?
[16:55] <jdstrand> mvo: amd64
[16:55] <jdstrand> vm
[16:56] <sergiusens> elopio, not sure if you are still bored with no tasks, but maybe you can run the snapcraft suite against the recently announced image ;-)
[16:56] <jdstrand> mvo: Reboot to use ubuntu-core version 16.04.0-5.
[16:56] <jdstrand> Reboot to use canonical-pc-linux version 4.3.0-2-3.
[16:56] <kyrofa> sergiusens, are hyphens not allowed in the version?
[16:56] <mvo> jdstrand: oh, you upgraded from an older all-snaps image to the latest?
[16:56] <jdstrand> after reboot, I don't see anything
[16:56] <sergiusens> kyrofa, they should be
[16:56] <kyrofa> sergiusens, ah okay
[16:56] <jdstrand> mvo: well, older-- I mean, it isn't terribly old
[16:56] <mvo> jdstrand: is it more than a day old ;) ?
[16:56] <sergiusens> kyrofa, schema/snapcraft.yaml has the correct things
[16:57] <mvo> jdstrand: if so, its old :P
[16:57] <elopio> sergiusens: no bored at all now. But that's just a command.
[16:57] <jdstrand> it is more than 1 day old :)
[16:57] <mvo> jdstrand: but seriously, there are some compatiblity issues because of the snap.yaml transition
[16:57] <jdstrand> ok, let me just nuke that and create a new one
[16:57] <mvo> jdstrand: I *think* some of this can be fixed, I need to look into the details in the morning
[16:57] <jdstrand> no worries. just wanted to make sure it was expected
[16:57] <mvo> jdstrand: I have not fully investigated what it takes
[16:59] <mvo> matiasb: I will have to debug this by creating the right image etc, probably tomorrow morning
[17:00] <matiasb> mvo, ack, let me know; I guess a possible confusion may be that if the headers are missing, we are returning there is an update (latest published revision), but then when requesting the package details passing the right headers, the latest available version for your config is returned (being the same you have already installed)
[17:02] <jdstrand> didrocks: fyi, I updated https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement and it has a link to https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/15.04. in the 16.04 doc cleanup, had some circular references (ie, snappy docs pointed to wiki and wiki pointd to snappy docs) for security-override
[17:02] <jdstrand> didrocks: I told pcoca I would fix the docs, but he is offline atm, so letting you know :)
[17:03] <mvo> matiasb: that sounds plausible, so we need to post to click-metadata "hello-world/edge" instead of "hello-world" ?
[17:03] <mvo> matiasb: hm, actually we are doing this
[17:04]  * jdstrand notes that both images are ubuntu-core/15.04/stable
[17:04] <jdstrand> mvo: ^
[17:04] <jdstrand> s/images/devices/
[17:05] <mvo> jdstrand: \o/
[17:05] <mvo> jdstrand: that might be it
[17:06] <plars> dragon
[17:06] <plars> err
[17:06] <matiasb> mvo, you should pass the release and arch headers to click-metadata, to get the right latest version available for those arch/release, besides channel
[17:06] <sergiusens> mvo, you joining the ho?
[17:07] <plars> mvo: no dragonboard image for the new release?
[17:07] <mvo> sergiusens: what HO?
[17:07] <didrocks> jdstrand: excellent! Thanks a bunch :)
[17:07] <sergiusens> mvo, the one david setup up
[17:07] <mvo> matiasb: the code says we are doing this
[17:10] <matiasb> mvo, ok, if that's the case, the issue is something else then
[17:14] <sergiusens> elopio, seems there are still issues http://autopkgtest.ubuntu.com/running.shtml#pkg-snapcraft
[17:19] <kyrofa> sergiusens, take a look at https://github.com/ubuntu-core/snapcraft/pull/291 when you have a sec? The backport wasn't quite as clean as I'd hoped, so I'd like a double-check
[17:21] <niemeyer> kyrofa: I haven't, sorry.. I'll try to get to it before the end of my day tomorrow the latest
[17:21] <niemeyer> kyrofa: With some chance of getting it done today still
[17:21] <niemeyer> kyrofa: Sorry I didn't get to it before
[17:22] <kyrofa> niemeyer, oh that's alright :) . Just a bug that keeps biting me!
[17:23] <jdstrand> Chipaca: fyi, latest allsnaps image I tried to configure timeezone and have: $ sudo snappy config ubuntu-core /tmp/c
[17:23] <jdstrand> unable to create /etc/localtime: open /etc/localtime: read-only file system
[17:23] <jdstrand> Chipaca: known? should I file a bug?
[17:23] <Chipaca> jdstrand, buuuuuuug
[17:23]  * jdstrand files
[17:25] <ogra_> i think we have one for that
[17:25]  * ogra_ goes digging
[17:25] <jdstrand> ogra_: https://bugs.launchpad.net/snappy/+bug/1541521
[17:26] <jdstrand> ogra_: I just filed that
[17:27] <ogra_> yeah, the bug i remembered was for /etc/timezone
[17:27]  * ogra_ adds a livecd-rootfs task
[17:29] <jdstrand> ogra_: I don't suppose you'd be interested in fixing bug #1504657 and bug #1504645 while you are at it?
[17:30] <ogra_> jdstrand, i totally am but i have some more importanmt tasks atm ... they are on my list to fix before 16.04 in any case
[17:30] <ogra_> hmm,. i havent seen the last one yet
[17:30] <ogra_> oh, i have :P
[17:31] <jdstrand> ogra_: thanks
[17:36] <kyrofa> sergiusens, elopio what's wrong with my migration skill here? http://paste.ubuntu.com/14868652/
[17:36] <kyrofa> It doesn't like my security-policy
[17:37] <sergiusens> kyrofa, nothing from what I see, but maybe this is more of a zyga question
[17:37] <kyrofa> sergiusens, I get a snapcraft error on it though
[17:37] <kyrofa> sergiusens, hold on
[17:37] <sergiusens> oh, then it is probably a bug :-/
[17:38]  * sergiusens is always confused on override, template and policy
[17:38] <kyrofa> sergiusens, a json exception: "{'security-policy': {'apparmor': 'path/apparmor', 'seccomp': 'path/seccomp'}, 'type': 'migration-skill'} is not valid under any of the given schemas"
[17:38] <kyrofa> sergiusens, but the json schema looked okay to me
[17:39] <sergiusens> kyrofa, hmm, that is unit tested
[17:39] <kyrofa> sergiusens, this is actually in another unit test. Let me push real quick and show you what's really going on
[17:40] <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/tests/test_yaml.py#L716
[17:40] <kyrofa> sergiusens, yeah I saw that one, which doesn't help my confusion
[17:41] <kyrofa> sergiusens, the test is still in development, but here: https://github.com/kyrofa/snapcraft/blob/bugfix/1524663/better_yaml_errors/snapcraft/tests/test_yaml.py#L335
[17:41] <kyrofa> The SnapcraftSchemaError that's raised contains the error I pasted
[17:42] <sergiusens> kyrofa, oh, remove mock_path_exists.return_value = False
[17:42] <sergiusens> kyrofa, or change it to true
[17:43] <sergiusens> kyrofa, this is what hits you https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/yaml.py#L39
[17:43] <kyrofa> sergiusens, that's actually what's under test here
[17:43] <kyrofa> sergiusens, so that's the error I get from that? Sheesh!
[17:44] <kyrofa> sergiusens, that's part of what I'm fixing, I just expected a different error I guess
[17:44] <kyrofa> sergiusens, yeah you're right
[17:44] <kyrofa> sergiusens, okay good, sorry about that. The test was failing for the reasons I expected, just not the _way_ I expected
[17:44] <kyrofa> sergiusens, thanks for the help!
[17:47] <didrocks> kyrofa: hey, we can't find your owncloud snap for 15.04 (which is without docker), are we missing something?
[17:47] <didrocks> or it's not in the store and hidden in a git repo? :p
[17:47] <kyrofa> didrocks, no it should be there
[17:47] <ogra_> jdstrand, hmm, looking at the localtime issue thats actually caused by mvo's changes ... i'll see what i can do though
[17:47] <didrocks> kyrofa: mind giving it a snappy search owncloud? (we only find the docker version there)
[17:47] <ogra_> seems /etc/writable now lives inside the squashfs
[17:47] <kyrofa> didrocks, for armhf it's `owncloud.kyrofa`, and amd64 it's `owncloud-amd64.kyrofa`
[17:48] <kyrofa> didrocks, though multi-arch uploads were enabled yesterday, I'm actually working on making them both owncloud.kyrofa right now
[17:48] <ogra_> kyrofa, does that still use docker ?
[17:48] <kyrofa> ogra_, no
[17:48] <ogra_> didrocks, note that docker snaps need docker installed first to even show you snaps using docker in snappy search
[17:48] <didrocks> kyrofa: on pedro's box, it can't find it, weirdly
[17:48] <sergiusens> kyrofa, np
[17:48] <ogra_> ah, then nevermind
[17:48] <didrocks> ogra_: yeah, we are trying the docker-less flavor
[17:48] <sergiusens> didrocks, store has gone bonkers this week
[17:49] <ogra_> didrocks, right, that should just show up
[17:49] <kyrofa> didrocks, checking here, one moment
[17:49] <didrocks> ah… that might be it
[17:49] <didrocks> yeah, double confirmation will never hurt :)
[17:50] <kyrofa> didrocks, huh, yeah I'm seeing that too
[17:50] <sergiusens> didrocks, https://uappexplorer.com/app/owncloud.kyrofa  https://uappexplorer.com/app/owncloud-amd64.kyrofa
[17:50] <sergiusens> matiasb, ^ 15.04; didrocks needs help
[17:50] <kyrofa> didrocks, yeah myapps says it's published and stuff
[17:50] <ogra_> ubuntu@localhost:~$ snappy search owncloud
[17:50] <ogra_> Get https://search.apps.ubuntu.com/api/v1/search?fields=alias%2Canon_download_url%2Cchannel%2Cdownload_sha512%2Cdescription%2Cbinary_filesize%2Cdownload_url%2Cicon_url%2Clast_updated%2Cpackage_name%2Corigin%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Csupport_url%2Ctitle%2Ccontent%2Cversion&q=owncloud: dial tcp: lookup search.apps.ubuntu.com on [::1]:53: read udp [::1]:57121->[::1]:53: read: connection refused
[17:50] <ogra_> WOAH !
[17:50] <kyrofa> ogra_, oops...
[17:50] <didrocks> ah, we didn't get that :)
[17:50] <ogra_> thats a board with no network ...
[17:50] <didrocks> we just got no output
[17:50] <kyrofa> ogra_, hahaha
[17:50] <ogra_> we really need to improve the error message ;)
[17:50] <didrocks> and the board has network here :p
[17:51] <kyrofa> didrocks, yeah no output here either
[17:51] <didrocks> we can find and install the docker version
[17:51] <didrocks> kyrofa: ah, we are not that crazy :)
[17:51] <didrocks> even snappy install fails
[17:51] <kyrofa> didrocks, must be store side
[17:51] <didrocks> yeah… so, it's in the store, but… cannot be downloaded
[17:51] <kyrofa> didrocks, apparently :P
[17:52] <kyrofa> didrocks, curl https://search.apps.ubuntu.com/api/v1/package/owncloud.kyrofa
[17:52] <didrocks> thanks for confirming sergiusens, kyrofa, ogra_ :)
[17:52] <didrocks> oh good
[17:52] <didrocks> let's do that
[17:52]  * didrocks notes that down for later
[17:52] <kyrofa> didrocks, err, owncloud-amd64.kyrofa
[17:52] <didrocks> yeah, got it :)
[17:53] <kyrofa> didrocks, sorry for the troubles!
[17:53] <didrocks> no worry, and not your fault! ;-)
[17:54]  * ogra_ files bug 1541530
[17:55]  * jdstrand hrms at https://bugs.launchpad.net/snappy/+bug/1541529
[17:56] <sergiusens> jdstrand, that's a bug for mvo ;-)
[17:56] <ogra_> jdstrand, works here when attaching --oem=generic-amd64
[17:56] <jdstrand> Determining oem configuration
[17:56] <jdstrand> Starting download of generic-amd64
[17:57] <jdstrand> it seems to have found it
[17:57] <ogra_> hmm, yeah, works even without it
[17:58] <ogra_> i'm on trusty using the xenial u-d-f though
[17:58] <jdstrand> I'm on xenial, trying xenial's and wily's udf
[17:59] <ogra_> so probably something with the surrounding tools like kpartx
[18:00] <didrocks> kyrofa: ok, we got it installed. Did you try to add more apps, like calendar and such?
[18:00] <didrocks> kyrofa: it seems that it doesn't find anything that isn't installed by default
[18:01] <kyrofa> didrocks, hmm, no, but I'll look into it!
[18:01] <jdstrand> ogra_: plausible: kernel: [ 956.113096] device-mapper: table: 252:0: linear: dm-linear: Device lookup failed
[18:01] <ogra_> yeah
[18:01] <didrocks> kyrofa: great! :-)
[18:02] <kyrofa> didrocks, it was a little interesting getting ownCloud confined while still allowing for apps to be installed and config changed, so I may have missed something there
[18:03] <jdstrand> ogra_: downgraded kpartx and it worked fine
[18:03] <didrocks> kyrofa: yeah, I wonder what's up. It seems that we can't find any apps that aren't enabled
[18:03] <didrocks> so I guess some networking cap?
[18:03] <ogra_> jdstrand, i blame xnox ... he secretly snaks in that s390 code everywhere in xenial ;)
[18:04] <kyrofa> didrocks, except that you're able to reach it
[18:04] <didrocks> kyrofa: yeah, so it acts as a server, maybe not as a client?
[18:04] <didrocks> let's look at denials from apparmor
[18:04] <kyrofa> didrocks, ah, interesting theory
[18:04] <kyrofa> didrocks, yeah let me know! That would be an easy fix indeed
[18:05] <jdstrand> hmm, seems I didn't have the latest kpartx from xenial
[18:05] <ogra_> ah
[18:05]  * jdstrand tries again with ubuntu12
[18:06] <coretex__> hello. what is this? https://uappexplorer.com/app/canonical-i386.canonical
[18:06] <coretex__> This package contains a simple gadget snap for i386 systems
[18:06] <coretex__> what's a snappy gadget?
[18:06] <ogra_> it is the gadget for building i386 images
[18:07] <ogra_> a gadget is a snap that describes your device
[18:07] <coretex__> oh :D i see
[18:07] <ogra_> and defines what kenrel is used etc
[18:07] <jdstrand> meh, ubuntu10 (what I had) was bad, ubuntu12 is fine
[18:07] <ogra_> heh, fun
[18:07] <jdstrand> stupid out of date mirror
[18:08] <didrocks> kyrofa: nothing network-related, just spawning access to /usr/sbin and /usr/bin
[18:08] <kyrofa> didrocks, darn
[18:08] <didrocks> oh wait one sec
[18:08] <didrocks> one complain about not having "network-admin"
[18:08] <xnox> ogra_, no clue mate. what's s390? i don't touch that acient 31-bit port, i touch s390x only ;-)
[18:08] <ogra_> lol
[18:09] <ogra_> is the X meaning four wheel drive ? (like BMW )
[18:09] <didrocks> kyrofa: maybe that's it? Would worth a try
[18:11] <didrocks> kyrofa: I'm wondering btw how you get access to the network, there is no network-service caps
[18:11] <kyrofa> didrocks, you get network-listener by default in 15.04
[18:11] <didrocks> ah, that makes sense!
[18:11] <kyrofa> didrocks, I believe that encompasses the server permissions that are broken out in 16.04 ( jdstrand would know better)
[18:12] <kyrofa> didrocks, when are you demoing this?
[18:13] <didrocks> kyrofa: we want to demo it for mwc
[18:13] <kyrofa> didrocks, yeah, when is that?
[18:13] <didrocks> 2 weeks and half?
[18:14] <kyrofa> didrocks, alright let me finish squashing some snapcraft bugs and I'll get it working. Does https://github.com/kyrofa/owncloud-snap/issues/10 seem to sum up the issue?
[18:15] <kyrofa> didrocks, if you notice any other issues please do let me know (or log them there) and I'll look into them as well
[18:16] <jdstrand> didrocks: the caps are all different in 15.04. install snappy-debug, then do: snappy-debug.security list -i
[18:16] <jdstrand> didrocks: network-client is added if you don't specify 'caps', otherwise, you need to use it or network-service
[18:17] <didrocks> kyrofa: perfect, yeah :)
[18:17] <didrocks> jdstrand: ah great, thanks for the head's up
[18:17] <kyrofa> didrocks, I appreciate your giving it a spin
[18:18] <jdstrand> also, the 16.04 ones are still in flux
[18:18] <didrocks> yw! thanks for looking at it :)
[18:18] <didrocks> jdstrand: yeah, for mwc, we are only focusing on 15.04 due to that (moving target)
[18:32] <didrocks> jdstrand: ok, so stupid quesiton (don't find any answer on the wiki), for the override-security, is this an addition to the apps security or do we have to copy the whole template?
[18:32] <didrocks> sorry, found an example on https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/15.04
[18:32] <didrocks> I guess we have to reset the policy group, as caps would be ignored
[18:41] <matiasb> sergiusens, didrocks, still having issues with owncloud and 15.04? let me check
[18:41] <kyrofa> matiasb sounds like the framework issue
[18:41] <didrocks> matiasb: yep
[18:42] <matiasb> kyrofa, hmm... that's supposed to be fixed
[18:42] <kyrofa> matiasb, i.e. the fix to https://bugs.launchpad.net/click-package-index/+bug/1540409
[18:42] <kyrofa> matiasb, it's the side effect of that fix
[18:42] <matiasb> nessita, fyi ^?
[18:42] <kyrofa> matiasb, sounds like snappy needs to use slightly different search params
[18:43] <nessita> kyrofa, would you please summarize the issue? is not clear to me from the backlog
[18:43] <matiasb> kyrofa, didrocks, so the issue is that owncloud can't be found in 15.04?
[18:44] <kyrofa> nessita, fabian sent out an email yesterday warning of this-- I think you received it as well?
[18:45] <nessita> kyrofa, yes, I did, but as far as I know snappy CLI would remove the framework on searches, for 16.04 and that solves "all issues"
[18:45] <nessita> kyrofa, so I'm not sure what this specific issue is
[18:46] <nessita> kyrofa, and for 15.04 the snappy search would behave just like before and will find all packages with framework 15.04
[18:47] <nessita> we assume snaps for 15.04 will declare the 15.04 framework in the manifest.json (deprecated in 16.04, but required for 15.04) file
[18:49] <kyrofa> nessita, hmm... I thought the problem was that the snap wasn't declaring a framework dependency anymore
[18:50] <kyrofa> nessita, which was why it was showing up on the phone
[18:50] <beuno> kyrofa, well, 16.04 isn't
[18:50] <beuno> 15.04 is still?
[18:51] <kyrofa> beuno, I'm checking now
[18:51] <nessita> kyrofa, so the *snap* for 16.04 does not need to declare a framework, the snap for 15.04 has to declare the "classic" framework
[18:51] <nessita> a snap for 16.04 *could* declare a framework and that will (should) not break anything
[18:53] <kyrofa> nessita, the package that caused bug #1540409 to be logged was built for 15.04. I just checked the manifest, and it does actually have framework: ubuntu-core-15.04-dev1
[18:54] <kyrofa> nessita, which means the description isn't quite right
[18:54] <kyrofa> nessita, it also means now I'm confused what the problem was, and what the problem is now :P
[18:55] <matiasb> didrocks, maybe you can make it clear what's the issue you are having?
[18:56] <kyrofa> matiasb, the symptoms of the problem now is that `snappy search owncloud` returns nothing
[18:57] <beuno> kyrofa, and you have docker installed?
[18:57] <kyrofa> matiasb, similarly, `snappy install owncloud-amd64.kyrofa` returns "package not found"
[18:57] <kyrofa> beuno, this one doesn't require docker
[18:57] <didrocks> I guess kyrofa summed it up well :)
[18:57] <matiasb> kyrofa, and this is for which arch/release configuration?
[18:57] <matiasb> didrocks, ^
[18:57] <beuno> kyrofa, and you are on amd64, right?
[18:57] <kyrofa> matiasb, amd64, 15.04
[18:57] <beuno> promise?
[18:57] <beuno> :)
[18:57] <kyrofa> beuno, promise!
[18:58] <didrocks> yeah, can be easily confirmed in a vm
[18:59] <matiasb> kyrofa, fwiw, I just did a search using the arch:amd64 + framework:15.04-core and I'm getting the result there: owncloud-amd64.kyrofa
[19:02] <kyrofa> matiasb, using the snappy tool?
[19:02] <matiasb> kyrofa, https://pastebin.canonical.com/149070/
[19:02] <matiasb> kyrofa, using the search API ^
[19:02] <kyrofa> matiasb, yeah curl works fine-- it's definitely in the store
[19:02] <kyrofa> matiasb, but all of a sudden hidden from snappy
[19:02] <kyrofa> matiasb, worked fine last time I tried... maybe two days ago
[19:04] <matiasb> kyrofa, ok... if I explicitly pass the framework, I don't see any results
[19:05] <matiasb> kyrofa, so this may be related to the bug you mentioned before <- nessita, fyi (not sure if the above is the expected behaviour)
[19:08] <elopio> sergiusens: kyrofa: can you make sense of this one? https://paste.ubuntu.com/14870696/
[19:09] <kyrofa> elopio, sorry I can't scroll that far to the right
[19:09] <kyrofa> elopio, in all seriousness, no clue
[19:10] <elopio> oh wait, I got this. It happened last week.
[19:10] <elopio> if only I had good memory...
[19:12] <elopio> ah, update-ca-certificates
[19:12] <matiasb> kyrofa, didrocks, ok, can you try again? it seems that the amd64 binary didn't have a framework set, so 15.04 will never find it
[19:13] <kyrofa> matiasb, hey, there it is!
[19:13] <matiasb> :)
[19:13] <kyrofa> matiasb, so wait... what did you do exactly?
[19:13] <matiasb> so, yes, it was related to the bug above
[19:13] <matiasb> kyrofa, that particular version for amd64 didn't have a framework set
[19:14] <ryanleesipes> Hello
[19:14] <matiasb> kyrofa, since 15.04 is searching passing the framework, the package coudn't be found
[19:14] <kyrofa> matiasb, ah, the version is messed up though-- that's a super old version
[19:14] <kyrofa> matiasb, owncloud.kyrofa should be at kyrofa5 and be armhf
[19:14] <kyrofa> matiasb, owncloud-amd64.kyrofa should also be kyrofa5 and be amd64
[19:14] <matiasb> kyrofa, ah, also there is that, there are 2 owncloud packages
[19:15] <matiasb> kyrofa, so let me check the other one, owncloud-amd64
[19:16] <matiasb> kyrofa, ok, I see, we have the same issue with this one, let me set the framework; also, not sure what you want to do with the previous one?
[19:17] <kyrofa> matiasb, I'm not sure I undersand. Previous one?
[19:18] <matiasb> kyrofa, there are 2 diff owncloud packages; I fixed one (owncloud.kyrofa), the one appears in searches now, and I'm fixing the other (owncloud-amd64.kyrofa)
[19:19] <kyrofa> matiasb, they're both valid, they predate the multi-arch support
[19:19] <matiasb> kyrofa, so now you should be having 2 results when searching
[19:19] <noizer> Hi guys just got a little question
[19:19] <noizer> i got an issue with my c++ on snappy
[19:19] <sergiusens> elopio, network error maybe?
[19:19] <noizer> locale::facet::_S_create_c_locale name not valid
[19:19] <noizer> thats the error
[19:20] <kyrofa> matiasb, ahh, I'm seeing kyrofa1 because of the multiarch!
[19:20] <matiasb> kyrofa, right, but one uploaded binary from the owncloud.kyrofa package is for the amd64 arch too
[19:20] <kyrofa> matiasb, that's actually awesome
[19:20] <elopio> sergiusens: no, outdated certificates on the slave.
[19:20] <kyrofa> matiasb, yeah don't worry
[19:20] <matiasb> kyrofa, right! :)
[19:20] <noizer> but it sais you need to export LC_ALL="en_US.utf-8"
[19:20] <kyrofa> matiasb, I'll upload a new one and unpublish amd64
[19:20] <noizer> but does not work
[19:20] <elopio> sergiusens: that was the only error with the all snaps image. I still need to run more binaries, but looks good.
[19:20] <matiasb> kyrofa, sounds good, let me know if you need any help, I'll check with nessita and fabian about the issue, to confirm we are ok there
[19:21] <kyrofa> matiasb, okay so... I'm confused. Are we building the .snaps incorrectly?
[19:21] <kyrofa> matiasb, or is this still a store bug?
[19:21] <sergiusens> matiasb, it really is only one result on clients as arch counts
[19:21] <matiasb> kyrofa, no, no, this is related to the fact that snaps are not having a framework set anymore, but 15.04 snappy is still sending it to filter searches in the store
[19:21] <sergiusens> elopio, nice work!
[19:22] <kyrofa> matiasb, okay good deal
[19:22] <sergiusens> elopio, yeah, network error includes certs :-P
[19:22] <matiasb> sergiusens, right, arch counts, but here we have 2 diff packages with published versions for amd64
[19:22] <elopio> sure :)
[19:23] <sergiusens> matiasb, oh, ignore me then ;-)
[19:23] <matiasb> np!
[19:24] <sergiusens> elopio, I can't see the adt results for 2.1.1 anywhere; any direct link hidden anywhere?
[19:26] <elopio> sergiusens: it's running
[19:26] <elopio> http://autopkgtest.ubuntu.com/running.shtml
[19:27] <sergiusens> elopio, ah, it wasn't on update excuses anymore
[19:27] <sergiusens> these polling systems drive me nuts
[19:27] <sergiusens> elopio, wow this is slow :-P
[19:28] <elopio> it is, yes. So cool, all the dependencies running.
[19:29] <kyrofa> didrocks, heads up-- as soon as it finishes building owncloud-amd64 will be going away, to be replaced with owncloud.kyrofa for both armhf and amd64
[19:29] <elopio> sergiusens: one integration test left to fix. But what does it mean?
[19:29] <sergiusens> elopio, there are 11 errors though FAILED (failures=1, errors=11)
[19:30] <elopio> oh, and where are the logs for them :(
[19:31] <sergiusens> elopio, needs to finish building afaik
[19:31] <didrocks> kyrofa: good! thanks for the head's up
[19:33] <kyrofa> matiasb, whatever you did, will it remain in effect when I upload new versions?
[19:35] <matiasb> kyrofa, unless you explicitly set the framework in your 15.04 package, yes (because while 15.04 snappy passes the framework filter in searches, packages without frameworks set will be excluded)
[19:36] <kyrofa> matiasb, okay yeah, I'm not doing anything with frameworks
[19:51] <nessita> sergiusens, mvo wanted to confirm that snaps for 15.04 are still being built in the "old way", where the deprecated framework value is always set
[19:52] <renat> Hi! It's Renat again=)
[19:53] <renat> Currently I'm unpacking squashfs and building a snap using snapcraft
[19:53] <renat> But today saw somewhere that it's possible to create a squashfs snap
[19:53] <renat> Where I can read about it?
[19:54] <sergiusens> nessita, they should be if on 15.04 and 14.04
[19:54] <sergiusens> nessita, only people on 16.04 can ONLY build for 16.04/devel
[19:54] <sergiusens> the only problem would be someone not using snapcraft
[19:55] <sergiusens> going out of their way to do it
[19:55] <sergiusens> our 16.04 snaps don't work on 15.04 anyways; so it is fine if they don't show up ;-)
[19:55] <kyrofa> renat, yeah, Snapcraft 2 builds squashfs snaps
[19:55] <kyrofa> renat, but they're only compatible with Snappy 16.04
[19:56] <renat> It it documented anywhere?
[19:56] <nessita> sergiusens, ack, thanks. I needed to confirm that 15.04 snaps (built with snapcraft) are always declaring the proper 15.04-dev1 framework
[19:56] <renat> Sorry. Is it documented anywhere?
[19:56] <kyrofa> renat, https://github.com/ubuntu-core/snapcraft/tree/master/docs
[19:58] <sergiusens> didrocks, still here? mind looking at http://paste.ubuntu.com/14871051/ ?
[19:59] <renat> kyrofa, thanks. Will try to find there
[20:00] <didrocks> sergiusens: mind if I push it tomorrow morning (first thing)?
[20:00] <sergiusens> didrocks, no worries, I have it locally already ;-)
[20:01] <didrocks> good, will sponsor it after a quick review then!
[20:01] <sergiusens> thanks
[20:02] <camako> My snap is failing to build with the following output : http://pastebin.ubuntu.com/14871088/
[20:03] <camako> This is in a clean xenial container image that I installed today
[20:03] <camako> with snapcraft 2.1.1
[20:04] <sergiusens> camako, try adding libc6-dev to our build-packages
[20:04] <camako> sergiuens, thanks
[20:08] <kgunn> sergiusens: so haven't had need to do look at help in a while...but snapcraft --help in a pretty clean lxc just gives
[20:08] <kgunn> https://pastebin.canonical.com/149075/
[20:09] <kgunn> guessing the "suggested" pkgs for snapcraft might solve this
[20:09] <kgunn> ?
[20:09] <kyrofa> kgunn, how exactly did you make that lxc?
[20:10] <kyrofa> kgunn, it's because you're missing locale, so it tries to use ascii
[20:10] <kyrofa> kgunn, but I've had trouble duplicating so I haven't been able to fix
[20:11] <kyrofa> kgunn, as for why help needs utf8, that's another problem
[20:11] <kgunn> kyrofa: from images.linuxcontainers.org
[20:11] <kyrofa> kgunn, that's what lxd does, right?
[20:12] <kgunn> kyrofa: yeah, well...it's one way
[20:12] <kgunn> kyrofa: i originally learend/followed from
[20:12] <kgunn> https://linuxcontainers.org/lxd/getting-started-cli/
[20:14] <kgunn> sergiusens: did you write the cmake plugin?
[20:14] <sergiusens> kgunn, no, only improved it a bit for out of source builds
[20:15] <kyrofa> kgunn, I think that was mterry
[20:15] <mterry> kgunn, heyo
[20:15] <mterry> kgunn, I don't know if it's still recognizable from my version, but shoot
[20:16] <kgunn> mterry: hey, so i've a belief, but camako makes me doubt... my belief is the the snapcraft cmake plugin doesn't magically take care of the fact your includes/libs your snap
[20:16] <kgunn> builds against are going to be local to your snap project
[20:16] <kgunn> cmake is still thinking that by default stuff is installed on the host
[20:17] <kgunn> ...so you gotta tinker with all the pathing
[20:17] <kgunn> but camako says, no it should be magic
[20:17] <mterry> kgunn, I thought snapcraft set environment variables like CFLAGS or whatever that is magic
[20:17] <mterry> kgunn, yeah I think it's usually magic
[20:17] <kgunn> mmm
[20:17] <mterry> kgunn, but I don't know how that magic works anymore  :-/
[20:17] <kgunn> my experience has been far different...and i just thot it was "Expected of me"
[20:18] <mterry> kgunn, I think the magic is in snapcraft itself, not cmake
[20:18] <mterry> kgunn, *not the cmake plugin* that is
[20:18] <mterry> kgunn, well then maybe I'm just out of the loop these days
[20:18] <kgunn> around last nov, i actually had a mir snap building mir from source and i had to do some major tinkering
[20:19] <kgunn> mterry: nothing wrong with being out of loop, but raises the question is it a bug?
[20:19] <kgunn> but that's a question for sergiusens and others i suppose
[20:20] <mterry> kgunn, yeah I dunno intended behavior these days
[20:21] <mterry> kgunn, at the time, the intention was that it was magic I think, as long as the plugin could handle standard CFLAGS and such
[20:25] <kyrofa> kgunn, indeed, CFLAGS should be set etc
[20:26] <kyrofa> kgunn, https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/yaml.py#L280
[20:27] <sergiusens> kgunn, mterry the problem comes when using things like pkgconfig where you can only have one sysroot; I'm working on fixing that; I am also working on allowing to just use build-packages and really need stage-packages unless it is for a runtime/dlopen thing
[20:29] <kyrofa> matiasb, so I uploaded a new version and verified it via curl, but snappy search is still showing me kyrofa1 as the only option on amd64
[20:31] <matiasb> kyrofa, ack let me check, I guess you are missing the framework in this case too (you aren't using snapcraft for 15.04 to build the package, are you?)
[20:32] <matiasb> kyrofa, there, it should be set now
[20:32] <kgunn> sergiusens: ok, so at least i'm not crazy
[20:32] <kyrofa> matiasb, yes I'm using snapcraft for 15.04, and I verified the framework was set in the manifest
[20:33] <matiasb> kyrofa, hmm... that's weird then, because the uploaded version doesn't have a framework set
[20:34] <kyrofa> matiasb, here is the contents of DEBIAN/manifest of the exact package I uploaded: http://pastebin.ubuntu.com/14871277/
[20:35] <sergiusens> matiasb, kyrofa so framework was never set in package.yaml; it was only ever set in the internal control part of the deb 'manifest'
[20:35] <kyrofa> sergiusens, yeah... we much have been missing each other every time?
[20:36] <sergiusens> kyrofa, /me cannot parse
[20:36] <nessita> sergiusens, with that info, I see 2 options: on parse, we either always use manifest.json for 15.04 snaps, or package.yaml also includes the frameworks
[20:36] <nessita> (on the store side)
[20:36] <matiasb> I see...
[20:36] <kyrofa> sergiusens, I mean we were all talking different things :P
[20:36] <sergiusens> nessita, it is not my call, I don't work on this, I just know how it works
[20:37] <nessita> sergiusens, oh, who works on this?
[20:38] <sergiusens> nessita, mvo, niemeyer and Chipaca ; we only started building snaps in snapcraft starting 2.0 for xenial
[20:38] <nessita> sergiusens, so what's the recommded path to build snaps for 15.04? so I review what we are producing with that
[20:39] <kyrofa> didrocks, owncloud-amd64 is no more
[20:40] <sergiusens> nessita, apt-add-repository ppa:snappy-dev/tools on 14.04 or 15.04 or 15.10 and install snappy-tools; then you can use snapcraft (which shells out to snappy) or snappy directly
[20:40] <didrocks> kyrofa: \o/
[20:40] <nessita> sergiusens, right, my question is which is the recommended way to see if the framework is always set and in which file
[20:41] <nessita> or, let me ask a different question:
[20:41] <nessita> * can we always expect a valid manifest.json on 15.04 snaps?
[20:47] <sergiusens> nessita, yes to manifest in 15.04 snaps
[20:48] <sergiusens> using debclick and all that cruft
[20:51] <elopio> oh, sorry kyrofa. I totally ignored your migration-skills question
[20:51] <elopio> did you get it working? Not that I know how to fix it, just feeling bad for not replying :)
[21:30] <kyrofa> elopio, yup, all good! Thanks though :)
[21:30] <kyrofa> elopio, turns out the gross "invalid schema" error I was getting was actually the one I wanted to fix. It was just worse than I thought it was
[21:40] <awe__> kyrofa, sergiusens, jdstrand, can someone give me a hand with 'migration-skill'? cutover for bluez?
[21:51] <kgunn> sergiusens: curious, do you have a bug for the find_package/sysroot issue with snapcraft?
[21:56] <sergiusens> kgunn, no; but if you create one it will move faster ;-)
[21:56] <sergiusens> working on cleanbuild now
[21:57] <kgunn> camako: ^
[21:57] <kgunn> :)
[21:57] <kgunn> camako: we might wanna include what to mod on our branch to exhibit the issue (since we've got a temp w.a.)
[21:58] <camako> kgunn, gotcha.. creating now
[21:58] <kgunn> thanks
[22:03] <noizer> how can i execute this command
[22:05] <noizer> export LC_ALL="en_US.utf-8"
[22:25] <camako> kgunn, https://bugs.launchpad.net/snapcraft/+bug/1541620
[22:26] <kgunn> thanks
[22:26] <camako> yw
[22:58] <sergiusens> camako, kgunn that is weird, it pkg-config is indeed looking for things in stage_dir; can you please add the sources, this should just work
[23:00] <camako> sergiusens, sure
[23:21] <elopio> I'm going to leave earlier today to attend a class on kicad an pcbs. Telegram if you need me. BBL.