[01:01] <sergiusens> rsalveti: I am back
[01:05] <sergiusens> rsalveti: jdstrand elopio I think that systemd change was orchestrated by Chipaca and mvo; I didn't have a part on it, sorry.
[01:07] <sergiusens> now I think snappy-systemd as a hook was dropped for both 15.04 and rolling and it's all implemented in snappy now.
[01:07] <sergiusens> it is just apparmor that remains
[02:36] <sergiusens> rsalveti: https://code.launchpad.net/~sergiusens/snappy/qualifiedUpdate/+merge/263987
[06:31] <elopio> ping pitti: do you have any clue about why this is happening? https://bugs.launchpad.net/snappy/+bug/1468868
[06:36] <pitti> elopio: I replied in the bug
[06:39] <elopio> thanks pitti. I'll ask what timezone we use on the image built.
[06:39] <elopio> and we'll probably send a patch to you with the warning=none
[06:40] <pitti> elopio: that should be simple to fix in autopkgtest, I'd just like to be able to reproduce it first; I think I see them occasionally, but I've never used --warning and thus I'm not 100% sure it will suppress that
[06:41] <elopio> pitti: we see it on every ./run-checks on snappy. So it will be easy to confirm.
[06:41] <pitti> lib/VirtSubproc.py:320:                'tar --create --absolute-names -f $d/autopkgtest-tmpdir.tar'
[06:41] <pitti> lib/VirtSubproc.py:337:                ' tar --extract --absolute-names -f $d/autopkgtest-tmpdir.tar;'
[06:41] <pitti> elopio: ^ those two are what you want to change
[06:42] <pitti> /usr/share/autopkgtest/python/VirtSubproc.py
[06:43] <elopio> pitti: ack. I'll try tomorrow.
[06:43] <elopio> thank you!
[06:43] <pitti> sorry, you want that too:
[06:43] <pitti> lib/VirtSubproc.py:511:        taropts[idst] = '--preserve-permissions --extract --no-same-owner'
[06:43] <pitti> I'll put those in the bug
[07:01] <dholbach> good morning
[07:01] <seb128> hey dholbach
[07:04] <mvo> elopio: hey, are you still up by chance?
[07:04] <elopio> mvo: o/
[07:04] <mvo> elopio: nice! what do I need to run to run the new _intergration-tests ?
[07:05] <mvo> elopio: the command in the readme gives me a error "failure File not found: snappy"
[07:05] <elopio> mvo: install the latest autopkgtest
[07:05] <elopio> mmm, I haven't seen that one.
[07:06] <mvo> elopio: so the command from the readme should work?
[07:06] <mvo> elopio: just running that in the top-level dir? or inside _integration-tests?
[07:06] <mvo> fwiw, I have autopkgtest 3.15.1
[07:06] <elopio> mvo: no, I have a branch that updates the REAMDE, in progress.
[07:06] <elopio> mvo: that's alright. With that, just ./run-checks
[07:07] <mvo> elopio: thanks!
[07:07] <elopio> mvo: http://bazaar.launchpad.net/~elopio/snappy/bbb_integration/view/head:/_integration-tests/README.md
[07:08] <mvo> elopio: neat!
[07:09] <mvo> elopio: thanks, I have what I need now :)
[07:12]  * ogra_ grumbles about live-build
[07:12] <elopio> mvo: no problem.
[07:12] <mvo> ogra_: heh, I thought you like it?
[07:12] <elopio> fgimenez: please follow up the publishing of the RC on cdimage.ubuntu.com.
[07:12] <seb128> hey mvo
[07:12] <elopio> I'm going to be. be back soon.
[07:12] <ogra_> mvo, well, until i was asked to somehow get libc6:i386 into the amd64 images :P
[07:12] <elopio> s/be/bed
[07:12] <mvo> hey seb128
[07:13] <mvo> ogra_: heh
[07:13] <seb128> mvo, the personal image boots to a working unity8 desktop session now ;-)
[07:13] <mvo> seb128: \o/
[07:13] <mvo> yay!
[07:16] <fgimenez> good morning
[07:17] <fgimenez> elopio, ack thanks (get some rest :)
[08:17] <mvo> ogra_: let me know if there is anything I can do to help with the libc stuff
[08:21] <fgimenez> mvo, thanks a lot for the AddCleanup functionality :)
[08:21] <mvo> hey fgimenez - you are very welcome
[08:21] <mvo> (was fun :)
[08:24] <fgimenez> mvo, waiting for elopio's opinion i've added a couple of comments via email to the mp and they don't show up (hopefully they will :) shall i forward them to you?
[08:26] <Chipaca> blame Chipaca!
[08:26]  * Chipaca parties
[08:31] <mvo> fgimenez: please forward it to me
[08:32] <mvo> chey Chipaca
[08:32] <mvo> Chipaca: its a bit early to party, no ;) ?
[08:32] <Chipaca> mvo: seems like we got the blame for breaking something again
[08:32] <Chipaca> mvo: nevah!
[08:32] <mvo> Chipaca: or did you had a extra strong cup of coffee ?
[08:32] <Chipaca> i think i'm going to have a *second* cup of extra strong coffee
[08:32] <mvo> Chipaca: meh, stuff broke? what/where
[08:32] <Chipaca> with some ginger snaps
[08:32] <mvo> lol
[08:32] <Chipaca> mmmm, yep
[08:33] <fgimenez> mvo, done thx :)
[08:34] <mvo> ta
[08:37] <mvo> fgimenez: excellent suggestion!
[08:41] <fgimenez> mvo, thx it's built upon your proposal :)
[08:41] <fgimenez> mvo, we just should take care to call the SnappySuite.TearDownTest from the tests in other suites that define a TearDownTest, right?
[08:42] <mvo> fgimenez: indeed,thanks! I did not check that
[08:43] <JamesTait> Good morning all; happy Chocolate Day! 😃
[08:46] <yisamu> Hey guy! How are you?
[08:46] <yisamu> guys!
[08:46] <yisamu> I need an advice
[08:46] <yisamu> Have anyone running lxc on snappy?
[08:47] <yisamu> where should I dig to get it working?
[08:47] <yisamu> Please advice
[08:57] <ogra_> mvo, http://paste.ubuntu.com/11834942/ ... i guess a hook is the only possibility (i tried differnt config opts, but cant convince live-build to use multiarch)
[09:01] <ogra_> mvo, one thing that isnt clear to me is if i need to explicitly remove the package lists that this apt-get update call creates ... (i guess that bloats the image) or if we already have some mechanism that wipes them
[09:03] <ogra_> oh, crap ... we actually do have code for this ... but thats run in the first hook
[09:07] <ogra_> ok, this should be good then http://paste.ubuntu.com/11834973/
[09:11] <mvo> ogra_: looks good
[09:11] <ogra_> ok, let me try a build with that in place then
[09:30]  * ogra_ kicks off a 15.04 build and crosses fingers
[09:37] <damjan> I have snappy running in kvm, how can I change the 'channel' it's on
[09:38] <ogra_> hmm, that didnt work ... i wonder why
[09:43] <seb128> nice, with yesterday snappy updates the personal grub menu works now
[09:43] <seb128> only one "system-a" entry and it boots
[09:43] <ogra_> OH !
[09:43] <ogra_> it did work ...
[09:43] <ogra_> but why is it executed so much earlier in the log ...
[09:44] <seb128> what is earlier in the log?
[09:44] <ogra_> seb128, my hack ...
[09:45] <mvo> seb128: do you also get a system-b when you update :) ?
[09:45] <seb128> oh, k
[09:45] <ogra_> i added a hook for installing libc6:i386
[09:45] <seb128> mvo, need an update to try that ;-)
[09:45] <mvo> you have the power to create one ;)
[09:45] <seb128> mvo, I'm going to kick a new image later on
[09:45] <seb128> right
[09:45] <ogra_> with a 12-* prefix ... so i would expect it to be executed after 11-* ... but seems it is executed way way earlier
[09:45] <seb128> I just want to do some small changes first
[09:46] <ogra_> well, at least it worked, libc6:i386 is installed now
[09:54] <ogra_> hmm, i canceled the arm64 image build ... why do i get a failure mail for that
[09:55] <dholbach> balloons, https://ubuntuonair.com/ is updated
[10:00] <Aabdyldaev> Hi All!
[11:05] <mvo> sergiusens: quick question, I'm preparing to send the patch(es) for shadow upstream with the --extra-users. I was curious about the use_extrausers, and I wonder if 1010_extrausers and 1011_extrausers-toggle should be merged? it seems to me that your approach is more localized and that maybe we don't need (most) of 1010 anymore with that? expect that I'm not sure if anything relies on the auto-detection and needs updating for the new --extrausers
[11:14] <sergiusens> mvo: morning! Maybe merging is the right thing to do, but passwd relies on auto detection
[11:16]  * ogra_ still finds xnox' comment interesting ... to bad he didnt answer my question on the bug 
[11:18] <sergiusens> ogra_: whataya talking about?
[11:18]  * sergiusens reads the backlog
[11:18] <ogra_> sergiusens, about the extrausers bug
[11:19] <ogra_> Bug 1323732
[11:43] <rsalveti> sergiusens: https://code.launchpad.net/~sergiusens/snappy/qualifiedUpdate/+merge/263987 got one question from mvo
[11:47]  * Chipaca waiting so long for a snappy build, he's starting to consider making build parallel
[11:47] <seb128> hum
[11:49] <mvo> Chipaca: wuuut? how long does it take?
[11:49] <mvo> sergiusens: aha, I see, thanks, that makes perfect sense now
[11:49] <Chipaca> mvo: 7 minutes of cpu time and counting
[11:50] <sergiusens> Chipaca: get a newer laptop :-P
[11:50] <mvo> Chipaca: woah, this includes the integration tests or really just the building? and if just the building what are you building this on?
[11:50] <sergiusens> mvo: I don't mind changing it if you want, but the struct isn't that big to require a pointer
[11:50] <mvo> Chipaca: or is it all dependencies?
[11:51] <Chipaca> mvo: building a *snap*, not snappy
[11:51] <Chipaca> sergiusens: ^
[11:51] <Chipaca> 200M of libraries
[11:51] <mvo> sergiusens: sure, its fine, I was just curious if there was a reason (i.e. I wanted to learn new tricks ;)
[11:51] <mvo> Chipaca: ohhhh, sorry
[11:51] <sergiusens> mvo: if so, we should also consider 'for i := range snaps' instead of for _, snap := range snaps' across the board (which we have debated a bit with Chipaca in some cases)
[11:52] <mvo> sergiusens: if we make it use the struct instead of the pointer you mean?
[11:52] <Chipaca> sergiusens: mvo: where is this?
[11:53] <Chipaca> ah, yes, if it's going to be a struct and not a pointer, no copying in loop :)
[11:54] <sergiusens> Chipaca: if the struct isn't hug, it's fine
[11:54]  * Chipaca likes structs that are hugs
[11:55] <sergiusens> err hugged I meant!
[11:55] <sergiusens> :-P
[11:55] <sergiusens> mvo: that MP brings in the issue that QualifiedName for a directory name was probably a bad idea as qualified names should always include the origin
[11:56] <Chipaca> 15 minutes ...
[11:58] <mvo> sergiusens: so whats the advantage of using the struct directly instead of the pointer? again, I'm just in learn-new-tricks land right now :)
[11:58] <mvo> sergiusens: QualifiedName> hrm, the sometimes-there-is-a-origin-sometimes-not is annoying :/
[11:59] <mvo> Chipaca: what is it doing? is it gzip that chewing all the cpu?
[11:59] <mvo> rsalveti: anything urgent for the release I should look at ? otherwise I will just continue with my cards
[11:59] <Chipaca> mvo: i presume so
[11:59] <Chipaca> mvo: although gzip wouldn't take this long
[11:59] <Chipaca> so i dunno
[12:02] <rsalveti> mvo: nops, just missing this last mr from sergiusens
[12:02] <sergiusens> mvo: there is always going to be one now on new systems
[12:03] <mvo> sergiusens: yep
[12:03] <sergiusens> mvo: well, if you use the latest u-d-f from wily at least
[12:03] <sergiusens> mvo: but most of that code in there is to contemplate upgrades
[12:03]  * mvo nods
[12:05] <sergiusens> rsalveti: that just needs approval or an explicit please fix this from my PoV ;-)
[12:06] <mvo> sergiusens: done, I didn't intend to block the MP, was just curious about the rational
[12:08] <sergiusens> mvo: no worries.
[12:20] <rsalveti> requested a new build for ubuntu-snappy and will trigger another image once it gets published
[12:20] <rsalveti> ogra_: all good from the livecd-rootfs side, right?
[12:20] <ogra_> yep
[12:20] <ogra_> i just did build one btw
[12:21] <ogra_> (to check the libc6:i386 addition)
[12:22] <rsalveti> ogra_: great
[12:22] <rsalveti> so we should be good
[12:22] <ogra_> yeah
[12:23] <ogra_> oh ... jolla gets split up
[12:24] <ogra_> (into HW ans SW companies it seems)
[12:24] <ogra_> *and
[12:24] <Chipaca> ok, can confirm it's the actual tar creation that is this slow
[12:24] <Chipaca> wth
[12:24] <ogra_> Chipaca, tar itself or the compression ?
[12:24] <Chipaca> poteito, potahto
[12:24] <ogra_> haha
[12:25] <Chipaca> i'd have to add more prints for that :)
[12:25] <ogra_> tomeito tomatoh ?
[12:25]  * Chipaca wishes gdb would actually work
[12:25] <Chipaca> tomeito tomahto
[12:26] <Chipaca> anyhow, it's finished; the 15+ minute one might've been a bug in a for-testing snappy i had lying around
[12:48] <rsalveti> launchpad is so slow sometimes, more than 20 minutes and package is still not published
[12:49] <ogra_> arm64 holding up the publication ?
[12:49] <rsalveti> ogra_: no, aborted that build as well
[12:50] <rsalveti> just waiting the armhf one to be published
[12:50] <ogra_> weird
[12:50] <rsalveti> so I can trigger another build
[12:51] <rsalveti> sergiusens: elopio: fgimenez: latest tools published at tools-proposed
[12:51] <rsalveti> we should use that ppa when validating the RC image
[12:51] <rsalveti> so we can also validate the tools at the same time
[12:52] <fgimenez> rsalveti, ack thanks
[12:53] <rsalveti> yay, published
[12:57] <sergiusens> ogra_: link?
[12:57] <ogra_> sergiusens, ?
[12:57] <ogra_> http://www.ubuntu.com/
[12:57] <ogra_> thats a link :P
[12:58] <sergiusens> ogra_: oh, jolla
[12:58] <ogra_> ah, that
[12:58] <sergiusens> good golly jolla
[12:58] <ogra_> yeah,. they are splitting up into a HW company and a SW licensing sales one
[12:58] <elopio> good morning.
[12:58] <ogra_> (only german links)
[12:59] <sergiusens> ogra_: to support the russian deal maybe?
[12:59] <ogra_> yeah, perhaps
[12:59] <ogra_> though the deal might have been fake
[12:59] <ogra_> i just heard that russia now demands that all phones come without OS
[13:00] <rsalveti> wtf
[13:01] <fgimenez> hi elopio
[13:01]  * ogra_ twiddles thumbs waiting for google
[13:01] <elopio> hey fgimenez.
[13:02] <elopio> so, do we have an rc to test today?
[13:02] <ogra_> sergiusens, in case you want to use google translate http://www.golem.de/news/sailfish-os-lizenzierung-jolla-spaltet-sich-auf-1507-115094.html
[13:03] <balloons> elopio, rsalveti http://cdimage.ubuntu.com/ubuntu-snappy/15.04/rc/ is still 404
[13:05] <rsalveti> balloons: yeah, working on that
[13:05] <rsalveti> elopio: the image is building
[13:06] <balloons> :-) ok, just wanted to make sure
[13:06] <rsalveti> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
[13:07] <elopio> 51 minutes, that will be just in time :)
[13:13] <seb128> Chipaca, sergiusens, mvo, the new grub config doesn't work well on personal, after install it has one install "system-a" which works, after a "snappy update" it has 4 entries which doesn't have labels mentioning system-a/b
[13:13] <seb128> booting the default boots the b partition
[13:13] <seb128> but then a snappy rollback ubuntu-core doesn't boot back to the system-a
[13:14] <conyoo> QUESTION: can i install 10 snaps at the same time?
[13:14] <conyoo> oh.. am i early?
[13:14] <sergiusens> seb128: are you using the latest snappy?
[13:14] <seb128> sergiusens, yes, upgraded this morning
[13:14] <sergiusens> seb128: because we aren't running update-grub anymore, so there should be only 1 grub entry at all times
[13:15] <seb128> sergiusens, oh, the image I did "snappy upgrade" on is likely having the old version installed
[13:16] <seb128> I guess I need to kick a new build to be able to try the upgrade for today's image
[13:16] <balloons> rsalveti, elopio ready for the hangout as well? Who all will be joining dholbach and I?
[13:17] <conyoo> -40 minutes
[13:18] <elopio> conyoo: yes, you are too early. And no, snappy install receives only one package as an argument.
[13:18] <elopio> you would have to call it ten times.
[13:18] <conyoo> :'(
[13:19] <conyoo> thanks elopio
[13:19] <elopio> balloons: ready here. I'm hoping the whole team will join.
[13:19] <balloons> elopio, awesome
[13:19] <balloons> no worries conyoo, we'll still answer  your questions until then :p
[13:19] <conyoo> :D nice
[13:21] <conyoo> but is it technically possible to install more than 1 snap at the same time? i mean.. they are isolated from each other
[13:21] <conyoo> would be really nice to sudo snappy install snap1 snap2 snap3
[13:21] <Chipaca> conyoo: you mean, can you have more than one snap installed at the same time?
[13:21] <conyoo> yep
[13:22] <conyoo> no
[13:22] <conyoo> NO
[13:22] <conyoo> i want to install 10 snaps at the same time in parallel
[13:22] <conyoo> and download
[13:22] <Chipaca> conyoo: you can't currently do that
[13:22] <Chipaca> conyoo: why do you want to do that?
[13:22] <conyoo> oh :'(
[13:23] <conyoo> oh well :d
[13:23] <conyoo> but it's not theoretically impossible?
[13:23] <Chipaca> conyoo: no, it's not theoretically impossible.
[13:23] <conyoo> super! thanks
[13:23] <balloons> can you have more than one active snappy process?
[13:24] <sergiusens> Chipaca: webdm is doing that today...
[13:24] <Chipaca> balloons: there is currently a single lock for all writes
[13:24] <sergiusens> parallel download unpack
[13:24] <Chipaca> sergiusens: nice, i missed that, good job
[13:24] <sergiusens> locking needs to happen after downloading at the least
[13:24] <Chipaca> locking *could* be made to be per-package
[13:24] <Chipaca> but it'd get fiddly :)
[13:25] <balloons> gotcha.. that would be the only way. I assumed a global lock
[13:25]  * conyoo awesome! brb beer low
[13:25] <Chipaca> balloons: it does have a global lock, but only because it was the quickest way forwards; we don't have global state that would require it
[13:26] <Chipaca> and one could argue that installing things is not supposed to be the most common state of a snappy system, so it isn't particularly high priority
[13:26] <Chipaca> but one won't
[13:32] <mterry> sergiusens, I switched the snapcraft trunk yesterday to our new python-based version.  Now tarmac is giving me crap: https://code.launchpad.net/~mterry/snapcraft/debian-packaging/+merge/263937
[13:32] <mterry> sergiusens, how does tarmac know what to install (i.e. pep8)?
[13:33] <Nikolay> Hello! Does anyone know how to read ADC data from BeagleBone Black with Ubuntu Snappy on it? There is no /sys/bus/iio file there.
[13:33] <mterry> sergiusens, do I just add sudo apt-get install lines to .tarmac.sh?
[13:38] <sergiusens> mterry: I'll install that, but no, we aren't rnning in chroots
[13:38] <mterry> sergiusens, there are probably more packages too -- how do other packages handle this?
[13:38] <mterry> sergiusens, I mean, more dependencies too
[13:48] <josepht> the link to the RC image here is broken: https://wiki.ubuntu.com/Snappy/OpenHouses/20150707
[13:50] <balloons> hey josepht, it's currently building..
[13:50] <elacheche> josepht, try this http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
[13:51] <balloons> it is indeed fresh fresh fresh
[13:51] <elacheche> balloons, the workwhop will use a new build?
[13:51] <elacheche> Ah ok!
[13:51] <balloons> yes, I think the builder is going to cut it close, hehe :-)
[13:52] <rsalveti> yeah, but the annoying sync that makes the image public might not run in time =\
[13:52] <rsalveti> forgot this takes ages
[13:52] <rsalveti> the image can be generated with ubuntu-device-flash at least
[13:52] <balloons> rsalveti, is there a matching rev # on the edge channel or ?
[13:52] <rsalveti> sudo ubuntu-device-flash core 15.04 --channel edge --oem generic-amd64 --install=webdm --enable-ssh --output ubuntu-15.04-snappy-amd64-generic.img
[13:52] <rsalveti> sudo ubuntu-device-flash core 15.04 --channel edge --oem beagleblack --install=webdm --enable-ssh --output ubuntu-15.04-snappy-armhf-bbb.img
[13:52] <rsalveti> image 117 for amd64 and 118 for armhf
[13:53] <rsalveti> make sure to have https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed in your system
[13:54] <elacheche> Anyone will use KVM? All of you have IoT hardware?? o_O x)
[13:54] <balloons> elacheche, I've done it with KVM. No IoT hardware for me at the moment so :-)
[13:55] <elacheche> Good to know that am not alone balloons x)
[13:55] <balloons> rsalveti, will the image be ready or should we tell folks to use u-d-f as you've laid out above?
[13:55] <woobadooba> hi all
[13:55] <balloons> howdy woobadooba
[13:56] <sergiusens> balloons: do we /join #ubuntu-on-air or is eveything going to be discussed here?
[13:56] <adam8157> ypwong: I almost fogot, thanks to google calendar, XD
[13:56] <balloons> everything will be here sergiusens
[13:57] <elopio> balloons: updating some steps to use udf, because the sync won't finish on time.
[13:57] <balloons> elopio, ok, I'll leave you to it. Thanks for updating the wiki
[13:57] <rsalveti> balloons: elopio: http://paste.ubuntu.com/11835948/
[13:59] <woobadooba> QUESTION: why is the irc chatbox under the video so tiny?
[13:59] <balloons> woobadooba, is it really small
[13:59] <balloons> ?
[13:59]  * balloons looks
[13:59] <woobadooba> yes
[13:59] <elopio> balloons: what's the url for the hangout?
[13:59] <balloons> hmm.. indeed. I wonder if we can make it larger
[13:59] <woobadooba> the video is wider than the chatbox :))
[14:00] <mariogrip> ChrisTownsend: I dunno if you saw this or not https://code.launchpad.net/~mariogrip/unity8-preview-lxc/unity8-preview-lxc-snappy I made it work with the snappy preinstalled personal tarballs, It boots but, does not seem to work correctly...
[14:00] <eager1> Hi
[14:00] <woobadooba> phew fixed it :d
[14:01] <woobadooba> i just hached the html from chrome
[14:01] <woobadooba> LOL
[14:01] <balloons> woobadooba, I updated the width to be the same as the video. Check it out now
[14:01] <woobadooba> balloons: perfect
[14:01] <ChrisTownsend> mariogrip: Sweet!  I knew we would have to support that soon.
[14:02] <elacheche> Here we go!
[14:02] <ChrisTownsend> mariogrip: In what way does it not work correctly?
[14:02]  * olli waves
[14:03] <balloons> woobadooba, thanks for pointing it out.. you are right it was tiny ;-)
[14:04] <woobadooba> balloons: thanks for fixing it so fast :D
[14:05] <ypwong> adam8157 :)
[14:05] <elacheche> ogra_, the img still building?
[14:05] <ogra_> elacheche, which one ? RPi you mean ?
[14:05] <elacheche> The one in the wiki ogra_
[14:05] <elacheche> http://cdimage.ubuntu.com/ubuntu-snappy/15.04/rc/ubuntu-15.04-snappy-amd64-generic.img.xz
[14:05] <mariogrip> ChrisTownsend: I need to do some debugging, but something is crashing. I get black screen with cursor.
[14:06] <ogra_> elacheche, ah, i dont know if we actually have a new img.xz yet ... i think we are currently testing directly via ubuntu-device-flash from the 15,.04 edge channel
[14:07] <ChrisTownsend> mariogrip: Ah, ok.  If you don't know already, try looking in /var/log/lightdm/unity-system-compositor.log and/or ~/.cache/upstart/unity8.log.
[14:07] <ChrisTownsend> mariogrip: When I have some time, I'll try this too.
[14:07] <ChrisTownsend> mariogrip: Thanks for working on this!  This is great!
[14:07] <elacheche> ogra_, so we can't test using KVM? Should we just download the old IMG for KVM?
[14:07] <rsalveti> elacheche: we're still waiting the publisher
[14:08] <rsalveti> elacheche: you can build yourself with ubuntu-device-flash
[14:08] <ogra_> elacheche, you should be able to use ubuntu-device-flash
[14:08] <rsalveti> https://wiki.ubuntu.com/Snappy/OpenHouses/20150707
[14:08] <ogra_> (or yes, you would need to wait)
[14:08] <rsalveti> there are instructions in there on how to build it
[14:09] <mariogrip> ChrisTownsend: Awesome, i will do some more debugging and ping you when i get it working :)
[14:09] <elacheche> thx rsalveti ogra_, I'll try that
[14:09] <ogra_> :)
[14:09] <ChrisTownsend> mariogrip: Great, thanks again!
[14:09] <alecu> kyrofa: one thing I forgot, not only we have to include the snappy scope, but we also need webdm in the image
[14:10] <alecu> seb128: is there a way to add a snap package to the seed?
[14:10] <kyrofa> alecu, indeed, good point
[14:10] <alecu> if not, we may need to repackage webdm as a deb
[14:10] <kyrofa> alecu, although in the most recent Core image, webdm was preinstalled
[14:10] <elacheche> ogra_, rsalveti unfortunately the PPA don't support 12.04 x(
[14:10] <elacheche> Think that I should go home and use my home laptop x)
[14:11] <seb128> alecu, no
[14:11] <alecu> kyrofa: we need to check with seb128 if webdm is preinstalled in the Personal image too
[14:11] <seb128> it's not
[14:11] <dholbach> if you have questions, please prefix them with QUESTION: so we can more easily pick up the questions on the hangout
[14:11] <ogra_> elacheche, oh, yeah, 12.04 is a bit ancient ... but ubuntu-device-flash is a static go binary
[14:11] <woobadooba> QUESTION: when is the snappy personal image ready to download (amd64)?
[14:11] <seb128> alecu, kyrofa, I guess the way to pre-install snap is to add them to the udf command that builds the image
[14:11] <ogra_> elacheche, theoretically it could work on 12.04 if you just dpkg -i the deb package for trusty (14.04)
[14:12] <seb128> woobadooba, subscribe to the snappy-devel list, it's going to be announced there
[14:12] <alecu> seb128: that sounds good, thanks.
[14:12] <seb128> alecu, yw
[14:12] <woobadooba> seb128: what's a mailing list?
[14:12] <ogra_> woobadooba, hmm, you just pointed out a flaw in our planning, we should have invited seb128 to this ubuntuonair ... he works on personal
[14:12] <woobadooba> joking but eww
[14:12] <woobadooba> thanks
[14:12] <seb128> woobadooba, https://lists.ubuntu.com/mailman/listinfo/snappy-devel
[14:12] <kyrofa> seb128, oh, that's pretty easy
[14:12] <woobadooba> thanks seb128
[14:12] <ogra_> dholbach, ^^^ how could we forget to invite the french guy :)
[14:12] <woobadooba> and ogra_
[14:12] <seb128> yw
[14:14] <tsimonq2> QUESTION: When do you think it will be ready for Ubuntu Desktop? (IF APPLICABLE)
[14:14] <woobadooba> QUESTION: is snappy fit for gigabit home routers?
[14:15] <leafbold> QUESTION: Do you plan to have a possibility to mark official/verified snap packages, to allow users to differentiate between third party packages of a software and a package build by the dev.
[14:16] <mzanetti> so far the theory :)
[14:16] <tsimonq2> QUESTION: What is the delay on this Hangout?
[14:17] <yisamu> QUESTION: Hey guys! are planning to add support for openvswitch, btrfs, lxd  in snappy itself or shell I look into making framework with it?
[14:18] <rsalveti> https://launchpad.net/snappy/+milestone/15.04.2
[14:18] <jcastro> QUESTION: How straightforward is it to install snappy on a normal x96 box, like say an Intel NUC?
[14:18] <jcastro> I meant x86 of course. :D
[14:19] <sergiusens> jcastro: you scared me there for a bit... new arch to support and all :-P
[14:19] <tsimonq2> jcastro, It is probably pretty universal. Just my guess. :)
[14:19] <mzanetti> QUESTION: I've managed to snappify my project with services, apps and everyhting. seems working so far. That project supports plugins. Can other people somehow publish plugins for my service through the store?
[14:19]  * sergiusens leaves the real answers for the hangout
[14:19] <ogra_> you can just dd the img to a USB stick and it should boot right away
[14:19] <jcastro> tsimonq2: yeah I just want to know if I can just dd a stick and go to town?
[14:20] <woobadooba> QUESTION: will the ubuntu phones use snappy in the future (whenish)?
[14:20] <tsimonq2> jcastro, Good QUESTION hahahahaha
[14:20] <ogra_> jcastro, yup. you can
[14:20] <kyrofa> QUESTION: How do I enable i2c on the raspberry pi 2 using Ubuntu Core?
[14:20] <jcastro> yeah, that option isn't on the instruction page so I was wondering if it was that simple
[14:20] <sergiusens> pun for ogra_ :P
[14:20] <balloons> here's the channel guide: https://developer.ubuntu.com/en/snappy/guides/channels/
[14:20]  * ogra_ hides 
[14:20] <jcastro> ogra_: good to know! flashing now. :D
[14:21] <bschaefer> hello, so I flashed an SD card with the default raspi2 image, but it doesn't seem to support networking at all? Is there a different image or do i have to make my own?
[14:21] <alecu> QUESTION: "snappy" is used for naming so many things that it's starting to be difficult to understand from context. (the OS that uses snap packages, the command line tool, the package format, and perhaps something else). Can we please start calling things using other names? (eg, the OS would be "Ubuntu Core" instead of "snappy", etc)
[14:22] <kyrofa> bschaefer, I did that last week and DHCP worked fine...
[14:22] <kyrofa> bschaefer, only ethernet, of course
[14:22] <balloons> thanks for the questions guys.. we'll get started answering them in a just a moment. Great questions!
[14:22] <bschaefer> kyrofa, right, ethernet wasnt being picked up sadly :(. (also didnt see an online demo was going on opps!)
[14:23] <ogra_> bschaefer, networking definitely works for me and all testers ...
[14:23] <elopio> https://wiki.ubuntu.com/Snappy/OpenHouses/20150707
[14:23] <bschaefer> ogra_, well super sad face, i see "net init skipped" on boot
[14:23] <ogra_> bschaefer, you are not usin a wlan dongle or some suchm right ? you are talking about the wired NIC
[14:23]  * bschaefer re-installs and hopes something broke
[14:24] <bschaefer> ogra_, yup just a straight ethernet cable
[14:24] <ogra_> (wlan works but needs manual tinkering)
[14:24] <bschaefer> ogra_, and i tested it on a different raspi2 image (and it worked fine)
[14:24] <bschaefer> so its not hardware
[14:24]  * bschaefer tries re-installing
[14:24] <biezpal> QUESTION: What about Java platform on Snappy?
[14:24] <balloons> for those who want to help, this is the wiki page that should let you follow along with Leo: https://wiki.ubuntu.com/Snappy/OpenHouses/20150707
[14:25] <seb128> sergiusens, mvo, it seems like the personal device tarball increased by 20+M since yesterday, do you know why/if any of the recent changes can explain that?
[14:25] <saulo> QUESTION: how does configuration files behave between updates?
[14:26] <ogra_> seb128, i included gdbserver and libc6:i386 in the core seed (respectively for imbc6 i needed a hook in livecd-rootfs)
[14:26] <ogra_> but that shouldnt make up 20M
[14:26] <ogra_> s/imbc6/libc6/
[14:26] <seb128> ogra_, that should be in the rootfs not the device tarball no?
[14:27] <ogra_> yeah
[14:27] <ogra_> i didnt touch the device bits
[14:27] <seb128> yeah, so that's not that
[14:27] <ogra_> yeah, sorry, missed that you said device
[14:27] <sergiusens> seb128: maybe diff the .manifest?
[14:27] <sergiusens> oh, I missed the 'device' part of the comment as well
[14:28] <ogra_> heh
[14:29] <sergiusens> feel free to log webdm bugs as well
[14:30] <balloons> For those willing to try, please remember to leave your feedback as well! http://bit.ly/1KHQZF6
[14:30] <ogra_> sergiusens, url ?
[14:30] <ogra_> :)
[14:31] <sergiusens> ogra_: http://bugs.launchpad.net/webdm
[14:31] <kyrofa> seb128, if we package the snappy scope as a .deb to be on the Personal image, how is it updated?
[14:31] <seb128> kyrofa, uploads to ubuntu
[14:31] <ogra_> kyrofa, with the next image build
[14:32] <seb128> kyrofa, but you might just want to make it a snap and have image built with that snap preinstalled otherwise...
[14:32] <kyrofa> seb128, I can do either/both. It's really whatever is easiest for you
[14:33] <seb128> kyrofa, having a snap is probably easier since it's no work
[14:33] <seb128> unsure if it's "right" though
[14:33] <seb128> if that should be part of the core image or if having it a a snap is fine...
[14:33] <seb128> we can maybe start with a snap
[14:33] <seb128> easier to test/update
[14:34] <kyrofa> seb128, kgunn might have some more thoughts there
[14:34] <seb128> yeah
[14:34] <sergiusens> mterry: pep8 is installed
[14:35] <balloons> if you have a question, feel free to ask. Just prefix with QUESTION, and I'll add it to the list to be answered :-)
[14:35] <balloons> And again, those willing to try running snappy, give it a try now and let us know how it works for you! http://bit.ly/1KHQZF6
[14:36] <kgunn> kyrofa: if it's simple +1 to it being a snap
[14:36] <olli> nicely put ogra_... snappy is ready for desktop,but desktop might not be ready
[14:36] <sergiusens> ogra_: https://insights.ubuntu.com/2015/05/13/iot-world-snappy-for-whitebox-switches/
[14:36] <sergiusens> switches ^
[14:36] <tsimonq2> QUESTION: Define your terminology when you say "Snap"
[14:37] <p_lorenz> QUESTION: what about official support of the raspberry pi 2 - will it come?
[14:37] <adam8157> QUESTION: is there a doc like "snappy from scratch"? which we could learn the system-level mechanism from, also will help transplanting
[14:37] <kyrofa> kgunn, alright, I'll play with that as soon as I have a personal image running. The only "weirdness" I see there is that unity8 etc. isn't a framework so the scope snap can't rely on it. Obviously I'll target the rolling-personal release, but it'll just have to _assume_ that unity8 is there
[14:37] <kgunn> yes, understood....
[14:38] <elopio> https://github.com/lxc/lxd-pkg-ubuntu/tree/snappy
[14:38] <elopio> lxd snap ^
[14:40] <mzanetti> but that still doesn't allow me to load .so plugins :/
[14:40] <mzanetti> and IPC for those plugins is not an option
[14:41] <mzanetti> ogra_, ^
[14:41] <tsimonq2> QUESTION: If we have questions after this Hangout, is there an email we can use? Where do we go to get our questions answered?
[14:43] <balloons> tsimonq2, great question. You can ask in this channel at a later time, although timezones might mean no one is around when you ask.. Either way, there's a lovely mailing list where you can get help and ask questions
[14:43] <balloons> tsimonq2, https://lists.ubuntu.com/mailman/listinfo/snappy-devel
[14:43] <tsimonq2> balloons: Thanks! :)
[14:44] <elopio> and https://lists.ubuntu.com/mailman/listinfo/snappy-app-devel
[14:45] <Sid_Payton> QUESTION: will we be able to easily install and configure (both via GUI) Server side apps like email, cloud, contacts Server? it would be brilliant if my parents (normal Joe) could easily do this and be more privacy aware.
[14:46] <bmullan> lots of people on Reddit talk about snappy but many are asking the question does snappy = container.   That probably needs to be cleared up in snappy preso's.
[14:46] <dougburks> QUESTION: Can we use DKMS or is there some other provision for kernel modules?
[14:46] <blaroche> QUESTION:  is  https://bugs.launchpad.net/snappy the best/only resource for those looking to contribute?
[14:46] <balloons> bmullan, interesting. Thanks for the feedback
[14:48] <p_lorenz> QUESTION: i have to use custom apparmor and seccomp profiles in my snaps, but finding out what's missing in them is sometimes rather difficult. do you have any tricks on figuring out what's missing easily?
[14:48] <tsimonq2> QUESTION: When Debian Ubuntu finally transitions into Snappy Ubuntu, won't it break everything, or will you have replacements for all of the packages? Will the config files and general GUI of the application stay, or will people have to start from scratch again?
[14:49] <elopio> blaroche: depending on what you want to contribute. We welcome code, translations, bugs and questions.
[14:50] <mterry> p_lorenz, often I just do "sudo grep DEN /var/log/syslog"
[14:51] <balloons> dougburks, p_lorenz tsimonq2 I'll try and answer your questions now :-)
[14:51] <mterry> mvo, can you make a new ~snappy-dev PPA?  "snapcraft-daily" or some such?
[14:51] <p_lorenz> mterry: sometimes, it's difficult to find the main cause - a forbidden syscall is only listed by a number and sometimes enabling file/directory permissions for something doesn't fix the issue because of some special attributes :/
[14:51] <balloons> dougburks, I don't believe dkms is an option. Is there a good way to get kernel modules ogra_ ?
[14:52] <mterry> p_lorenz, another useful tool is to scp strace over to your snappy device and use that
[14:52] <ogra_> balloons, i actually dont know, i know the architects were discussion DKMS support, but i do not know the outcome ... perhaps ricmm could answer this one
[14:52] <mterry> p_lorenz, but yeah it would be nice to have a slick tool to tell you about denials
[14:52] <ogra_> *discussing
[14:53] <balloons> tsimonq2, you won't have to start from scratch. The debian base for ubuntu isn't going away, nor is the normal distribution. The point is the base for snappy and snap packages can still very much be debian
[14:53] <tsimonq2> balloons: Thanks!
[14:53] <p_lorenz> mterry: thanks, i'll try strace next time i run into a problem :)
[14:53] <balloons> tsimonq2, I hope that helps. Plus there are some tools the team is working on to make packaging up existing stuff easy
[14:53] <ogra_> tsimonq2, there will also be a tool called snapcraft in the future that is supposed to make it easy for you to create a snap from a bundle of deb packages to roll your own project into a store snap
[14:54] <tsimonq2> ok
[14:54] <tsimonq2> good
[14:54] <balloons> So I'll link again, try out snappy and let us know what happens! http://bit.ly/1KHQZF6
[14:54] <ogra_> i dont think we will just blindly convert deb to snap for everything in the archive though
[14:54] <mvo> mterry: sure, does https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily look good? you should have edit access
[14:54] <mterry> sergiusens, it's not just pep8.  I'd also need pyflakes, plainbox, and python3-yaml (maybe that's it?)
[14:54] <balloons> lol ogra_ indeed! We don't want to reinvent the wheel, but we don't want to clone it either!
[14:55] <sergiusens> mterry: sure, np
[14:55] <ogra_> yeah, else we would have just renamed dpkg :)
[14:55] <sergiusens> mterry: plainbox?
[14:55] <kyrofa> tsimonq2, don't worry, normal Ubuntu isn't going anywhere!
[14:55] <mterry> sergiusens, it's a test runner
[14:55] <sergiusens> mterry: is there a plainbox for trusty?
[14:55] <tsimonq2> kyrofa: YAY
[14:55] <mterry> sergiusens, yes, but I haven't tried with that version...
[14:56] <sergiusens> mterry: installed then, if there's a ppa we need, just send it over
[14:56] <elopio> so, starting from now and until the RC is ready for release, the team will be testing the different snappy features.
[14:56] <elopio> ping fgimenez or me if you want to test, if you get lost following the guides or if you find a bug.
[14:56] <mterry> mvo, ah interesting...  I was thinking new PPA but using tools-proposed should be fine
[14:57] <svij> isn't there a live stream? ubuntuonair.com links to the community q&a
[14:57] <mvo> mterry: I don't mind either way, feel free to edit as needed
[14:57] <esiotrot> For things like python/java/whatever would each snap come bundled with its own python interpreter/JVM/etc?
[14:57] <mterry> mvo, thanks
[14:57] <mvo> yw
[14:57] <elopio> svij: the community q&a is the next on air session.
[14:57] <sergiusens> svij: the on air part just ended
[14:57] <mterry> esiotrot, yes (but de-duplication will eventually help avoid a lot of the space concerns)
[14:57] <sergiusens> it's all irc now
[14:57] <svij> sergiusens: oh right, so I just missed it, thanks
[14:57] <tsimonq2> ogra_ balloons So, can you define what will change in the Ubuntu workflow once Snappy is implemented(kernel, APIs, apps, GUI, etc.)?
[14:58] <esiotrot> mterry: Thanks.  Would that also avoid loading duplicate things in RAM?  Or just disk?
[14:58] <balloons> svij, yes we had the last hour
[14:58] <elopio> svij: https://www.youtube.com/watch?v=YMJ-R7KeMr0
[14:58] <balloons> but we're still here chatting and testing
[14:58] <svij> elopio: thanks!
[14:58] <seb128> sergiusens, no idea about the device tarball increase/where to look at then?
[14:59] <mterry> esiotrot, there was a plan to deduplicate RAM too
[14:59] <balloons> svij, give it a try and tell us what happens: http://bit.ly/1KHQZF6
[14:59] <esiotrot> mterry: OK
[14:59] <esiotrot> How will updates to things like OpenSSL be handled?  Upgrade all affected snaps?  How will one know which snaps are affected?
[15:00] <tsimonq2> QUESTION: ogra_ balloons So, can you define what will change in the Ubuntu workflow once Snappy is implemented(kernel, APIs, apps, GUI, etc.)?
[15:00] <balloons> tsimonq2, what do you mean by workflow? I'm a little lost on what you are asking, sorry
[15:00]  * ogra_ too 
[15:01] <mterry> esiotrot, snap maintainers will need to update their snaps -- we have some plans to add metadata about library versions to snaps with our standard tools to help decide if something is affected
[15:01] <tsimonq2> balloons, Implementing snappy means replacing...
[15:01] <tsimonq2> GUI
[15:01] <tsimonq2> Apps
[15:01] <tsimonq2> etc.
[15:01] <ogra_> tsimonq2, snappy images (and most likely also official snap packages that come from canonical) are usually based on deb packages from the archive ... so essentially there is just one additional step in the flow to "snappify" things
[15:02] <esiotrot> mterry: OK, but essentially it is a case of updating all affected snaps instead of a single shared lib.  Why is this considered more secure? :)
[15:02] <tsimonq2> So it makes it easier to install/develop applications?
[15:02] <ogra_> we try to re-use the existing archive here as much as we can ...
[15:02] <svij> isn't there some documentation on how to build a snap package which includes arm, x86_64 in one package? That's what I asked myself a few weeks ago when I tried to build a snap
[15:02] <balloons> tsimonq2, it makes it easier for an end user to always have up to date and isolated stuff that won't break, and can rollback if it does
[15:02] <kyrofa> ogra_, the i2c devicetree overlay will need to work in order to use the PiGlow, correct?
[15:03] <tsimonq2> Cool!
[15:03] <ogra_> kyrofa, yes, i fear so ...
[15:03] <mterry> esiotrot, well there are other security threads with snappy -- namely each snap is very confined by apparmor (so snaps affected by a busted openssl can only hurt themselves)
[15:03] <tsimonq2> Installing Snappy now
[15:03] <esiotrot> mterry: I see
[15:03] <balloons> tsimonq2, so for the app developer, they can push things out similar to the phone / store model. For the user, they can consume things in the same model. Historically on something like a server I would be loathe to update lots of things unless I needed to
[15:03] <kyrofa> ogra_, but it's possible to get it working, albeit nasty?
[15:03] <balloons> tsimonq2, I don't like breakage, but at the same time I do want the latest version of wordpress or something
[15:03] <tsimonq2> Lol ok thanks
[15:04] <ogra_> kyrofa, i'm trying to make the config.txt way that RPi upstream uses to work though ... so you might be able to just hack that fiule to have it working (as an interim solution)
[15:04] <balloons> tsimonq2, let us know what you think :-) http://bit.ly/1KHQZF6. Thanks for giving it a shot
[15:04] <balloons> do you have a device to try it on?
[15:06] <esiotrot> balloons: So for ARM it's basically just beaglebone black and Raspberry pi?
[15:06] <kyrofa> ogra_, I'd love to get that working, even in the interim. Do you plan on sending out an email to snappy-devel?
[15:06] <ogra_> kyrofa, yes, indeed, as soon as the new snappy image is out i'll publish the RPi one and send a mail
[15:07] <kyrofa> ogra_, I'm looking forward to it. Thank you for that!
[15:08] <ogra_> :)
[15:09] <elopio> esiotrot: there's a community port to odroid.
[15:09] <tsimonq2> balloons: Can I link a screencast in the form?
[15:09] <balloons> tsimonq2, sure! Sounds great
[15:09] <elopio> https://github.com/longsleep/snappy-odroidc
[15:09] <tsimonq2> balloons: I use LXDE hahahaha
[15:09] <balloons> esiotrot, as far as I know those are the published images. rsalveti ogra_ will there / are there more? or a generic image
[15:09] <balloons> ?
[15:10] <esiotrot> elpio, balloons: OK.  The only device I would be able to try it on other than a VM would be an old AR7 DSL router, but even OpenWRT doesn't support it very well, so I am not surprised if Snappy doesn't :)
[15:10] <ogra_> esiotrot, there is a odroidc image that longsleep maintains
[15:11] <esiotrot> ogra_: OK
[15:11]  * ogra_ has a few other borads here butr didnt find the time for images yet 
[15:11] <ogra_> (parallella, and bananapi)
[15:12] <ogra_> seb128, WOW ... yor last build exploded in flames
[15:12] <ogra_> looks like an isotracker issue
[15:14] <seb128> ogra_, hum? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next suggests it worked
[15:15] <seb128> bah, can't ssh to recent personal images
[15:15] <ogra_> http://paste.ubuntu.com/11836230/
[15:15] <ogra_> thats the log i just got mailed by nusakan
[15:15] <Laney> the tracker is down
[15:15] <Laney> be becalmed
[15:15] <ogra_> ah, right, so just ugly noise
[15:16] <ogra_> seb128, and indeed you can ssh ... you removed cloud-init ... and i think sshd defaults to key auth
[15:16] <seb128> "error: could not load host key: /etc/ssh/ssh_host_rsa_key"
[15:16] <ogra_> *can not
[15:16] <seb128> oh!
[15:16] <seb128> :-/
[15:16] <ogra_> you will need to add something that creates the keys on first boot
[15:17] <ogra_> some systemd unit
[15:17] <ogra_> and/or script
[15:24] <tsimonq2> balloons: My screencast is (slowly) encoding, but I got an error.
[15:25] <tsimonq2> balloons: I don't know how to fix it. hahahahahaha
[15:25] <balloons> tsimonq2, awesome. Do you have steps to reproduce? I can try and do so
[15:27] <elopio> fgimenez: I tried to set up my access in canonistack and failed because I can't follow instructions.
[15:27] <elopio> can you help me tomorrow?
[15:29] <fgimenez> elopio, sure :) i struggled to follow https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack until it speaks about the dashboard, from there all is easy :)
[15:31] <fgimenez> sergiusens, thx a lot for the pointer :) sorry where can i find those instructions again? https://developer.ubuntu.com/en/snappy/start/ doesn't mention it?
[15:36] <tsimonq2> balloons: Sorry for the delayed reply, I can get you my system info and a list of all applications installed
[15:36] <tsimonq2> YOu will have to see the video for the error
[15:37] <balloons> tsimonq2, ack, I'll wait for that :-)
[15:39] <tsimonq2> balloons: UGH 16% And I can't change rendering settings :(
[15:39] <tsimonq2> And it is probably a REALLY simple error :D
[15:40] <balloons> tsimonq2, can you take a couple screenshots?
[15:40] <balloons> otherwise I guess we wait.. But I'll be here for some time so :-)
[15:40] <sergiusens> fgimenez: no, ubuntu.com/snappy
[15:41] <sergiusens> not developer ;)
[15:41] <tsimonq2> balloons: Do you have Google Hangouts?
[15:41] <tsimonq2> hahaha probably
[15:41] <balloons> tsimonq2, certainly do
[15:42] <tsimonq2> balloons: And no on the screenshots, sorry
[15:42] <tsimonq2> Ok
[15:42] <sergiusens> fgimenez: ah, it's a redirect now
[15:42] <sergiusens> fgimenez: e.g.; https://developer.ubuntu.com/en/snappy/start/#snappy-amazon the cloud-data part
[15:43] <sergiusens> ogra_: rsalveti any idea when we removed support for iso9660? http://paste.ubuntu.com/11836309/
[15:44] <ogra_> sergiusens, modprobe ?
[15:46] <sergiusens> ogra_: if it wasn't modeprobed before and needs so now it is a regression
[15:46] <sergiusens> ogra_: that bug is the 15.04 blocker in any case
[15:50] <tsimonq2> balloons: I have a hangouts call
[15:50] <tsimonq2> https://goo.gl/pIylSG
[15:50] <tsimonq2> I am showing my screen
[15:50] <tsimonq2> Join
[15:51] <tsimonq2> balloons: Would you like to?
[15:52] <fgimenez> sergiusens, ok thx :) do you know where this cloud.cfg file should be generated? ubuntu's home?
[15:54] <balloons> tsimonq2, sure, one second
[15:56] <sergiusens> fgimenez: depends on the stack itself, maybe utlemming can help on how to feed that in for canonistack
[15:59] <balloons> snappy is 64-bit only right?
[16:02] <balloons> It's interesting trying to run a 64-bit kvm on a 32-bit host
[16:02] <balloons> thoughts?
[16:02] <fgimenez> sergiusens, sure thx
[16:08] <bschaefer> ogra_, very strange i had to manually set my ip address to ssh into it with (ifconfig eth0 <ip>/24 up)
[16:08] <bschaefer> also no default routing tables
[16:09]  * bschaefer isn't sure if thats expected
[16:19] <elopio> balloons: why don't you get a 32-bit image and vm?
[16:19] <elopio> I think that should work, but haven't tried it.
[16:24] <rsalveti> sergiusens: trying to think what could have changed for that bug to show up
[16:24] <rsalveti> sergiusens: maybe cloud-init itself?
[16:24] <rsalveti> or did it always require iso9660?
[16:24] <sergiusens> rsalveti: from what I think, it may have always required it, utlemming might be the right person to ask
[16:25] <sergiusens> rsalveti: but cloud-init did change, yes
[16:26] <rsalveti> utlemming: do you have any idea about when this started to happen?
[16:31] <balloons> elopio, is there a 32 bit snappy build?
[16:32] <elopio> balloons: you can pass  --oem generic-i386 to ubuntu-device-flash.
[16:32] <elopio> again, not sure what will happen. But you can try :)
[16:32] <balloons> elopio, bah, I knew it. I figured u-d-f would let you
[16:38] <rsalveti> balloons: the image is there but not properly validated atm, we officially only support amd64 and armhf (beaglebone black) atm
[16:39] <balloons> rsalveti, right, but you plan to keep building 32-bit in the interim?
[16:39] <rsalveti> no reason not to do it :-)
[16:46] <rsalveti> elopio: another one that might be good for regression testing https://bugs.launchpad.net/snappy/+bug/1472317 (once we get the fix)
[16:46] <rsalveti> ogra_: sergiusens: can you guys work with utlemming to find out why this is broken?
[16:47] <elopio> rsalveti: ack. Subscribing...
[17:04] <tsimonq2> balloons
[17:05] <balloons> ohh hello again tsimonq2
[17:05] <tsimonq2> I pmed you\
[17:05] <balloons> sorry, I don't always see those right away :-)
[17:06] <tsimonq2> Ok
[17:06] <tsimonq2> I am using Lubuntu 15.04
[17:06] <tsimonq2> balloons
[17:06] <tsimonq2> Quick question
[17:07] <tsimonq2> Did you try this in a 32 bit ubuntu VM?
[17:07] <tsimonq2> *Ubuntu
[17:07] <ogra_> bschaefer, no, surely not expected and not seen by anyone else yet (to my knowledge)
[17:07] <bschaefer> ogra_, sad face, not sure what im doing differently, but its working just strange
[17:08] <ogra_> bschaefer, and you are using the right image ?
[17:08] <balloons> tsimonq2, did I ? No I've not tried
[17:08] <bschaefer> ogra_, the one from the snappy core site
[17:08] <tsimonq2> Use something like VirtualBox and try it there
[17:08] <bschaefer> ogra_, wget http://people.canonical.com/~platform/snappy/raspberrypi2/ubuntu-15.04-snappy-armhf-rpi2.img.xz
[17:08] <bschaefer> is the image im using
[17:09] <ogra_> yeah, thats the right one
[17:09] <tsimonq2> I am but my computer is probably slower than yours :)
[17:09] <sergiusens> rsalveti: ogra_: maybe we should just add iso9660 to /etc/modules-load.d/modules.conf ?
[17:09] <tsimonq2> balloons
[17:09] <ogra_> sergiusens, well, i dont get why module-init-tools doesnt load it on boot
[17:09] <ogra_> it should load it on demand i mean
[17:10] <ogra_> sergiusens, utlemming, was that a recent addition to cloud-init ?
[17:11] <jcastro> I cannot seem to get any docker container to write a data directory in the /home/ubuntu directory, permission denied
[17:11]  * ogra_ would like to find out why it broke before we hack around it 
[17:11] <ogra_> jcastro, yeah, snaps cant write outside their defined space
[17:11] <jcastro> oh, so I'm in the wrong defined space then?
[17:11] <tsimonq2> balloons: Are you present?
[17:12] <jcastro> ogra_: how do I find out where a snap is allowed to write to?
[17:12] <ogra_> jcastro, there is $SNAP_APP_USER_DIR (which i forgot where exactly it points to by default) ... that should point to a subdir un the users home where you can pit data
[17:12] <jcastro> got it, thanks!
[17:12] <sergiusens> the data pit
[17:13] <jcastro> that would explain this apps directory then I take it, heh
[17:13] <ogra_> there was also some doc on dev.ubuntu.com that talks about the exact path
[17:13] <balloons> tsimonq2, I'm here. I don't have a 32-bit vm
[17:13] <ogra_> heh
[17:13] <balloons> tsimonq2, but yours seems to be a packaging error
[17:13] <balloons> I'm not sure
[17:13] <balloons> we can try something simpler to eliminate the issue
[17:14] <tsimonq2> balloons, Installing one uninstalls the other, which installing back uninstalls the other
[17:14] <tsimonq2> So it seems to be circular
[17:16] <tsimonq2> balloons, If it works in a VM, then it is my computer and we will need to diagnose. If it doesn't work on my VM, it is a problem either with Snappy or the command you gave me
[17:16] <mterry> sergiusens, you said tarmac could use a ppa?
[17:17] <mterry> sergiusens, we might need a ppa for newer version of plainbox
[17:17] <tsimonq2> balloons, And either way, I want it to work in this VM
[17:17] <tsimonq2> balloons, unless I can put it in another VM...
[17:17] <tsimonq2> WAIT
[17:17] <tsimonq2> OMG
[17:17] <balloons> yes?
[17:17] <sergiusens> ogra_: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/cloud-init/vivid/revision/389
[17:17] <sergiusens> mterry: yeah, just tell me which one
[17:18] <ogra_> sergiusens, whats that mess ?
[17:18] <mterry> sergiusens, ppa:hardware-certification/public ?
[17:18] <ogra_> (all these ~/.pc thingies there)
[17:19] <tsimonq2> I should try it in VirtualBox, balloons
[17:19] <sergiusens> ogra_: the cloud-init from updates that uses the azure data source
[17:19] <ogra_> ah...
[17:19] <sergiusens> ogra_: utlemming 583    for fstype in ("iso9660", "udf"):
[17:19] <sergiusens> inside .pc/lp-1375252-1458052-Azure-hostname_password.patch/cloudinit/sources/DataSourceAzure.py
[17:19] <ogra_> so thats new in cloud-init ...
[17:19] <ogra_> ok
[17:20]  * ogra_ just wanted to be sure it didnt work before and the image changed or whatnot
[17:20] <sergiusens> ogra_ yes, but it may have been there for walinuxagent
[17:20] <utlemming> sergiusens: that is the bit that enables it...but what is wierd is that it works for rolling
[17:20] <utlemming> sergiusens: and yes, walinuxagent would have required it
[17:20] <sergiusens> so the only thing I can think of is our new kernel
[17:21] <ogra_> so it probably added the right bits for modprobing it
[17:21] <jcastro> ogra_: that snap env variable doesn't appear to be set, also can't find where in the docs that would be listed. :-/
[17:22] <tsimonq2> balloons, Looks like the img file you gave me won't work in VirtualBox, OR Disk Image Mounter...
[17:22] <tsimonq2> Or that the command game me
[17:22] <tsimonq2> *gave
[17:22] <tsimonq2> There is a chance that it could be that
[17:23] <sergiusens> utlemming: although sergiusens@lothlorien:~/source/walinuxagent-2.0.13$ grep -R iso9660 returns nothing
[17:23] <ogra_> jcastro, i never used docker directly, only via the pwncloud snap yet ... perhaps you can deduct from there how it works (just install it and then look in /apps)
[17:23] <ogra_> *owncloud
[17:23] <tsimonq2> balloons, What do you think about that?
[17:23] <jcastro> yeah I'll keep digging because I tried guessing from the owncloud.
[17:23] <ogra_> sergiusens, is that kernel any different from our -generic one ??
[17:24] <ogra_> or is it the very same package ?
[17:24] <ogra_> oh
[17:24] <tsimonq2> ballons, BRB
[17:24] <ogra_> it is the first 4.0 kernel ?
[17:25] <sergiusens> ogra_: it is the SAME kernel
[17:25] <ogra_> are we talking wily or 15.04 ?
[17:25] <sergiusens> ogra_: livecdrootfs now just does a cp of the generic one to the azure one
[17:25] <ogra_> ok
[17:25] <sergiusens> ogra_: wrt to device
[17:25] <sergiusens> ogra_: and yes, 15.04
[17:25] <ogra_> ah, k
[17:25] <sergiusens> ogra_: as ben said, everything seems to be fine on rolling
[17:26]  * ogra_ sees there was a walinuxagent upload to 15.04 yesterday
[17:26] <sergiusens> ogra_: we aren't using walinuxagent anymore
[17:26] <ogra_> k
[17:26] <sergiusens> ogra_: it's all in cloud-init now
[17:27] <tsimonq2> balloons, Here
[17:28] <tsimonq2> balloons, Are YOU here?
[17:28] <balloons> tsimonq2, the img file for snappy?
[17:28] <balloons> it works in kvm only. There is an ova image that should work in vbox I would think
[17:28] <ogra_> https://launchpad.net/ubuntu/+source/linux/3.19.0-22.22
[17:29] <tsimonq2> balloons, yes
[17:29] <tsimonq2> balloons, NOTHING can open it
[17:29] <ogra_> nothing regarding filesystems :/
[17:30] <tsimonq2> balloons, redownloading
[17:30] <balloons> tsimonq2, my idea was to ppa-purge
[17:30] <balloons> ppa:snappy-dev/tools-proposed
[17:30] <balloons> then try installing snappy and going through the steps again
[17:30] <balloons> just in case there's a packaging issue
[17:32] <tsimonq2> balloons, I am downloading the .img file again. Then, I will try opening it again. If that doesn't work, I will do that.
[17:32] <tsimonq2> ok
[17:32] <tsimonq2> doing it
[17:33] <tsimonq2> Running ppa-purge ppa:snappy-dev/tools-proposed
[17:33] <mterry> mvo, do you mind creating a new ppa just for snapcraft (can still call it snapcraft-daily or something)?  I want to enable a new dependent PPA for building on trusty, and I'd feel better if it was more isolated (plus, users testing snapcraft may not want the rest of those tools)
[17:33] <tsimonq2> balloons, welp, had to install ppa-purge
[17:34] <jcastro> ogra_: found it, you just have to be explicit when telling docker the directory, I'll write it down on askubuntu for the next person
[17:34] <tsimonq2> balloons, Note, I had to add sudo
[17:34] <ogra_> jcastro, awesome, thanks !!
[17:35] <tsimonq2> balloons, Then do I have to reinstall the PPA?
[17:35] <tsimonq2> balloons, or am I good?
[17:37] <tsimonq2> balloons
[17:38] <ogra_> sergiusens, so lets just add isofs to /etc/modules on azure images i guess ...
[17:39] <tsimonq2> balloons
[17:40] <balloons> tsimonq2, after using ppa purge, update apt and try installing snappy again
[17:40] <balloons> then run the same commands
[17:40] <ogra_> sergiusens, hrm, but we cant do that during build i fear that would add isofs to all images ... not so good
[17:41] <mterry> rsalveti, do you mind creating a snapcraft-daily ppa under ~snappy-dev?
[17:41] <ogra_> sergiusens, any way to do that from the oem snap ?
[17:42] <tsimonq2> Ok
[17:44] <tsimonq2> balloons, So I am redownloading the image, or I am reinstalling snappy?
[17:44] <tsimonq2> OHHH
[17:44] <tsimonq2> Got it
[17:44] <tsimonq2> Nevermind
[17:44] <balloons> tsimonq2, :-) awesome
[17:45] <balloons> is everything installing a-ok now? then you should be able to launch the image
[17:45] <tsimonq2> I cannot install Snappy
[17:45] <tsimonq2> proceeding
[17:47] <tsimonq2> ballons, errors, emailing you a screenshot
[17:47] <balloons> so snappy fails, and kvm still fails?>
[17:48] <tsimonq2> You will see
[17:48] <tsimonq2> Check your email
[17:48] <tsimonq2> I sent you the screenshot as an attachment, balloons
[17:49] <sergiusens> ogra_: we need to do it from the device tarball for azure
[17:50] <ogra_> sergiusens, right ...
[17:50] <sergiusens> ogra_: so it's a half revert of the livecd-rootfs change
[17:50] <ogra_> *sniff*
[17:50] <sergiusens> yeah :-P
[17:51] <balloons> tsimonq2, I see it
[17:51] <sergiusens> ogra_: who should do it?
[17:51] <ogra_> i'm just trying to find the commit ... why didnt it have your name ?
[17:52] <balloons> hmm.. your system is still a bit interesting because of the packaging stuff
[17:52] <ogra_> ah
[17:52] <ogra_> it had ... just well hidden :P
[17:52] <sergiusens> ogra_: lol
[17:52] <balloons> tsimonq2, I would probably go ahead and remove the packages
[17:52] <sergiusens> ogra_: livecd-rootfs for vivid is what we need to change
[17:53] <sergiusens> ogra_: I don't know why it works for wily as is, but it works
[17:53] <ogra_> sergiusens, yeah, but i guess the dropped code was the same
[17:53] <tsimonq2> balloons, I have to leave for a meeting. I will email you when I get back on in a couple of hours so we can experiment some more. I am emailing you this as well. Be back around 3PM CST(Central Standard Time, USA). Sorry. Bye!
[17:54] <sergiusens> ogra_: right, we just need to tar up $HERE as the generic device, then echo the modules (isofs) and tar up again as azure
[17:54] <sergiusens> ogra_: although...
[17:54] <ogra_> http://paste.ubuntu.com/11837056/
[17:54] <sergiusens> ogra_: we won't work on any openstack install and only on azure if we don't make it generic
[17:54] <ogra_> so i guess thats the relevant bit
[17:55] <sergiusens> ogra_: yes
[17:55] <sergiusens> ogra_: I'm thinking we should just make it generic though...
[17:55] <ogra_> hmm
[17:55] <ogra_> you mean isofs in all images ? nah
[17:56] <ogra_> thats super ugly (and might break with BSP kernels)
[17:56] <sergiusens> ogra_: yeah, it's not azure specific
[17:56] <ogra_> hmpf
[17:57] <mvo> mterry: sure, one sec
[17:57]  * ogra_ would really rather see cloud-init call modprobe then)
[17:58] <mvo> mterry: is this https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily ok ?
[18:00] <sergiusens> ogra_: in any case, why isn't it automatic?
[18:00] <jcastro> well, I got docker containers up and running with data being saved in the right places
[18:00] <jcastro> and then /oem seems to have filled up
[18:00] <ogra_> sergiusens, why would it be loaded if there is no CDROM ?
[18:01] <sergiusens> jcastro so /oem is bind mounted to /writable; maybe create a bigger image (--size X)
[18:01] <sergiusens> ogra_: I don't know, mount should :-P
[18:01] <mterry> mvo, yeah perfect
[18:01] <mterry> mvo, thanks man
[18:02] <sergiusens> ogra_: but why does it work on wily?
[18:02] <ogra_> good question
[18:02] <sergiusens> ogra_: also, special case it for amd64, not all arches
[18:02] <ogra_> apw, do you know if anything in regard of loading filesystem modules changed in the recent vivid kernel ?
[18:03] <jcastro> sergiusens: oh I see what happened, I gave it a 60gb disk but it seemed to partition that area for 1.6GB
[18:03] <jcastro> I was assuming it would just use the rest of the disk as writeable
[18:03] <ogra_> jcastro, you could just expand the writable partition with gparted or some such
[18:04] <ogra_> (just dont touch system-a|b|boot ...)
[18:05] <ogra_> sergiusens, utlemming, are we actually 100% sure the isofs module isnt loaded (or could the sr0 device be corrupt perhaps) ?
[18:07] <sergiusens> jcastro: it should have
[18:07] <sergiusens> ogra_: good point, bad superblock....
[18:07] <ogra_> sergiusens, "bad option" ...
[18:07] <ogra_> does "-o ro,sync" even work with isofs ?
[18:08] <ogra_> (i thought isofs implies ro anyway, and i doubt it supports sync at all)
[18:08] <sergiusens> ogra_: wait_for /dev/sr0
[18:09] <utlemming> ogra_: based on what I am seeing, it looks like the module is not loaded
[18:09] <ogra_> hmm, k
[18:10] <ogra_> utlemming, and that code has worked before with these mount options ?
[18:10] <utlemming> ogra_: yes, it works in rolling-edge incidently
[18:10] <ogra_> k
[18:10] <jcastro> hmm, so I clearly misinstalled this: http://pastebin.ubuntu.com/11837141/
[18:10] <utlemming> ogra_: and I've confirmed the code path for cloud-init in a generic cloud image
[18:11] <ogra_> right, then it can only be the kernel
[18:11] <ogra_> i dont get why it wouldnt autoload
[18:13] <ogra_> ogra@styx:~$ lsmod|grep isofs
[18:13] <ogra_> ogra@styx:~$ sudo mount -t iso9660 /dev/foo /mnt
[18:13] <ogra_> mount: /dev/foo is write-protected, mounting read-only
[18:13] <ogra_> mount: special device /dev/foo does not exist
[18:13] <ogra_> ogra@styx:~$ lsmod|grep isofs
[18:13] <ogra_> isofs                  40960  0
[18:13] <ogra_> i'm running the exact same kernel on this laptop :/
[18:15] <ogra_> sergiusens, ! ... i like that --config idea !!
[18:22] <deker> Anyone tried the OVA image of snappy ? Attempting to deploy http://cloud-images.ubuntu.com/ubuntu-core/15.04/core/stable/current/core-stable-amd64-cloud.ova fails because the sha256 hash of the .ovf file doesn't match
[18:25] <rsalveti> balloons: elopio: took just a few hours :-) http://cdimage.ubuntu.com/ubuntu-snappy/15.04/rc/
[18:25] <rsalveti> next time need to remember to do that one day earlier
[18:29] <ogra_> sergiusens, i dont see any changes on the images over the last days that could anyhow cause this
[18:29]  * ogra_ just re-activated his changelog script
[18:31] <ogra_> http://paste.ubuntu.com/11837262/ ... nothing except the kernel itself ... but that kernel loads isofs just fine here
[18:33] <ogra_> errr
[18:33] <ogra_> looking at that ....
[18:34] <ogra_> ah, nevermind
[18:35] <rsalveti> yeah, it's super weird that is not loaded by default
[18:35] <rsalveti> can you load it manually with modprobe?
[18:35]  * rsalveti checks
[18:35] <ogra_> i honestly have no idea why
[18:36] <ogra_> rsalveti, see above, even "sudo mount -t iso9660 /dev/foo /mnt" loads it for me before it spillls the error
[18:36] <rsalveti> mterry: seems mvo already created the ppa for you
[18:36] <mterry> rsalveti, yeah thanks!
[18:36] <rsalveti> mterry: guess we just need to ask it to be armhf as well (if not enabled by default)
[18:36] <ogra_> rsalveti, and i use the exact same kernel here on my vivid laptop
[18:36] <rsalveti> trigger the first build and we'll see
[18:37] <rsalveti> ogra_: right, but that is not snappy :-)
[18:37] <mterry> rsalveti, I got distracted by helping unity7 folks with a greeter document, will flesh out the PPA in a bit
[18:37] <ogra_> rsalveti, it worked before the kernel upgrade i was told
[18:37] <ogra_> (on snappy)
[18:38] <ogra_> https://launchpad.net/ubuntu/+source/linux/3.19.0-22.22 has nothing that could touch this area either
[18:38] <rsalveti> ogra_: yeah, the dependencies are definitely right, and I can load it manually just fine
[18:38] <ogra_> right
[18:39] <ogra_> rsalveti, rmmod it and try: sudo mount -t iso9660 /dev/foo /mnt
[18:39] <rsalveti> is there any easy way to manually reproduce the issue?
[18:39] <ogra_> see if it gets auto loaded
[18:39] <ogra_> (here it auto loads before mounts spills the error)
[18:39] <ogra_> *mount
[18:39] <rsalveti> ogra_: yup, loaded fine
[18:40] <ogra_> on snappy ?
[18:40] <ogra_> hmm...
[18:40] <rsalveti> ogra_: yup
[18:40] <sergiusens> rsalveti: 15.04?
[18:40] <ogra_> i dont get it then :P
[18:40] <rsalveti> sergiusens: yes, 15.04/edge
[18:40] <rsalveti> amd64
[18:41] <sergiusens> ogra_: wait_for_root /dev/sr0
[18:41] <sergiusens> won't that be a probable cause?
[18:41] <ogra_> sergiusens, who would call that ?
[18:41] <rsalveti> what creates /dev/sr0 ?
[18:41] <sergiusens> rsalveti: azure's hypervisor I guess
[18:41] <sergiusens> utlemming: ^
[18:42] <utlemming> rsalveti, sergiusens: correct
[18:42] <rsalveti> there is definitely no wait-for-root for every block device
[18:42] <sergiusens> ogra_: I say maybe we should, it might just take time to show up?
[18:42] <ogra_> ah
[18:43] <rsalveti> a race would then explain why it works on rolling
[18:44] <rsalveti> utlemming: sergiusens: can you manually restart/start cloud-init after booted the system?
[18:44] <ogra_> sergiusens, yeah, so lets try it, but add a timeout so it doesnt hang forever :)
[18:44] <rsalveti> just trying to understand how we can manually reproduce the issue
[18:44] <sergiusens> ogra_: right, we only want to wait for it on azure if we do this
[18:45] <sergiusens> rsalveti: launch a kvm instance with a cd attached I guess.
[18:46] <rsalveti> https://github.com/Azure/WALinuxAgent
[18:46] <rsalveti> The information flow from the platform to the agent occurs via two channels:
[18:46] <rsalveti>   * A boot-time attached DVD for IaaS deployments.
[18:47] <sergiusens> rsalveti: we saw the code, it tries to mount it, the new cloud-init, while the walinuxagent from vivid didn't
[18:47] <rsalveti> utlemming: sergiusens: but will it always be there?
[18:47] <sergiusens> rsalveti: I can't answer that ;-)
[18:47] <rsalveti> saw that as well, just trying to understand why that device exists
[18:47] <utlemming> rsalveti: for Azure, yes
[18:48] <ogra_> well, if it is always there i doubt wait-for-root busy us anything
[18:48] <ogra_> *buys
[18:48] <sergiusens> ogra_: always there, but takes time
[18:48] <rsalveti> ogra_: that helps giving a timeout for the block device to really show up
[18:48] <rsalveti> we had similar issues for the other partitions
[18:49] <rsalveti> but the wait-for-root logic can be called from somewhere else
[18:49] <rsalveti> like in cloud-init itself
[18:49] <sergiusens> as in always ever since it shows up and not since the begining of the vms lifecycle
[18:49] <ogra_> yeah
[18:49] <rsalveti> no need to hack up the initrd for an azure specific option (which is a pain)
[18:49] <ogra_> /usr/lib/initramfs-tools/bin/wait-for-root foo bar
[18:50] <sergiusens> utlemming: maybe hack that in for a test? ^
[18:50] <utlemming> ogra_: actually, walinuxagent does mount the iso
[18:50] <sergiusens> utlemming: yeah, I only saw that in the new cloud-init code
[18:51] <utlemming> ogra_: its more obvious in the new cloud-init code...walinuxagent buries it
[18:51] <utlemming> ogra_: and walinuxagent tries up to 6 times, sleeping for 5 seconds between attempts
[18:51] <rsalveti> right :-)
[18:51] <ogra_> ah
[18:52] <rsalveti> that might explains
[18:52] <ogra_> /usr/lib/initramfs-tools/bin/wait-for-root DEVICE TIMEOUT ...
[18:52] <ogra_> add that then
[18:52] <rsalveti> or just have a similar retry logic
[18:52] <ogra_> yeah
[18:52] <ogra_> but
[18:52] <ogra_> ....
[18:52] <utlemming> wild idea...udev rule that identifies if this is azure that blocks until the /dev/sr0 appears?
[18:53] <ogra_> if the mount call doesnt load the isofs module, it wont load the module later either
[18:53] <rsalveti> ogra_: I don't think that the module is the issue
[18:53] <rsalveti> it was probably loaded
[18:53] <sergiusens> utlemming: ogra_ rsalveti this boots fine btw kvm_snappy -cdrom ~/Downloads/ubuntu-14.04.2-desktop-amd64.iso azure.img
[18:53] <ogra_> it should even load it if sr0 isnt there yet
[18:53] <ogra_> rsalveti, utlemming said it wasnt
[18:53] <sergiusens> /dev/sr0 is instantly there and cloud-init doesn't choke
[18:54] <ogra_> ok
[18:54] <rsalveti> sergiusens: was the module loaded?
[18:54] <ogra_> obviously ... if he didnt get the error
[18:54] <rsalveti> guess the kernel tried to read the block device and then loaded the correct module to handle that
[18:54] <ogra_> well, mount -t iso9660 should omit any probing
[18:54] <rsalveti> in the broken case I don't think it can even read the block device
[18:55] <ogra_> and just blindly load isofs
[18:55] <rsalveti> that's true
[18:55] <ogra_> well, you did the test yourself on your snappy ... mounting /dev/foo doesnt exist either
[18:55] <rsalveti> but in the azure case it was there, just not really there
[18:56] <rsalveti> so not sure if that would case any other weird side effect
[18:56] <ogra_> well, lets try the loop/wait logic and see
[18:56] <rsalveti> yeah, in any case, having the retry logic seems a good thing to do anyway
[18:56] <ogra_> yup
[18:56] <sergiusens> sorry, intel driver crash
[18:57] <rsalveti> utlemming: the udev rule could trigger something, but cloud init would still try to read it
[18:57]  * sergiusens missed some bits and pieces
[18:57] <rsalveti> sergiusens: http://paste.ubuntu.com/11837389/
[18:57] <rsalveti> in case you missed irc as well
[18:58] <Saviq> ogra_, are you building u-boot yourself for the pi2 images? could I ask for your config etc.? /me needs to disable serial in u-boot
[18:59] <ogra_> Saviq, no, i pull ppisatis binary from github
[18:59] <ogra_> and now i cant find the link :(
[19:00]  * ogra_ has it in the browser history on the other machine :(
[19:01] <ogra_> Saviq, https://github.com/piso77/ubuntu-embedded/tree/master/boards/raspy2/bootloaders
[19:01] <Saviq> ogra_, thanks!
[19:04] <ogra_> Saviq, originally the source comes from https://github.com/swarren/u-boot ... but i dont know which branch exactly ppisati used
[19:04] <ogra_> (there are many rpi ones)
[19:04] <Saviq> ogra_, yeah, let's see if I can get somewhere with this, otherwise I'll bug him tomorrow, thanks
[19:09]  * sergiusens takes short break
[19:22] <bschaefer> ls
[19:22] <bschaefer> opps
[19:23] <rsalveti> utlemming: so will you take care of trying to add a retry logic in there?
[19:23] <rsalveti> just to make sure someone is on top of the issue
[19:40] <Letozaf_> hey guys I have installed snappy and wanted to launch webdm on my local machine, I stared kvm with -redir :8090::80  but if I type http://localhost:8090 in my browser webdm does not start, what am I doing wrong ?
[19:41] <manik_> Letozaf_: webdm is running on port 4200 i believe, you need to redirect that port to a local port on your computer as well
[19:41] <sergiusens> Letozaf_: webdm listens on 4200
[19:41] <Letozaf_> manik_, sergiusens ok thanks
[19:45] <apw> ogra_, not that i know of ... no
[19:54] <kyrofa> kgunn, are you running Ubuntu Personal in kvm?
[19:54] <kgunn> kyrofa: yes, i use Virtual MAchine Manager
[19:54] <kgunn> there's some magic for the gfx drivers
[19:55] <kyrofa> kgunn, did you have to switch it to QGL?
[19:55] <kyrofa> kgunn, QXL, rather
[19:55] <kgunn> i wrote up my instructions for how i did it as part of the snappy gui
[19:55] <kgunn> https://docs.google.com/document/d/14msTXe_cFulk9z4jFptEjFJzZx58b1mWU_r4VivLkfA/edit
[19:56] <kgunn> kyrofa: ^
[19:59] <kyrofa> kgunn, so you didn't have to change the machine config at all? Doing it that way I get to a lightdm-looking prompt, which gives me a black screen after I enter the password. If I change the video model to QXL I get more of a unity8-ish login prompt, but then I can't get past the intro demo thing
[20:00] <kgunn> mmm
[20:01] <kgunn> kyrofa: almost sounds like you're getting what i saw a week ago
[20:01] <kgunn> kyrofa: and correct i didn't change a thing
[20:02] <kyrofa> kgunn, hmm. And was the login screen lightdm or unity8?
[20:02] <bschaefer> ogra_, hey, soo just ran into a fun issue with ras pi2. Theres no /dev/dri (which is causing the mir server to fail)
[20:02] <kgunn> kyrofa: i do have instructions on how to dismiss the unity8 greeter from the command line (gotta ssh in ahead of time tho....cause you can't vt switch after you hit unity8 greeter)
[20:02] <kgunn> kyrofa: so it's weird, greeter for desktop shows up on vt7
[20:02] <kgunn> and unity8 greeter shows up on vt8
[20:02] <kyrofa> kgunn, ohhh, interesting
[20:03] <kgunn> kind of an artifact of the unity8-on-desktop
[20:03] <kgunn> package....
[20:03] <kgunn> eventually it should not be like that
[20:04] <kgunn> kyrofa: so here's another doc thtat addresses what i saw last week
[20:04] <kgunn> https://docs.google.com/document/d/13teoUPInWNfFONZ2Dq1U9VTiqs9aUEV52D2M8VCXOA4/edit
[20:05] <kgunn> kyrofa: so seb was saying we shouldn't have to do those monkey manual steps...
[20:05] <kgunn> but i haven't caught up myself, i was going to update to wily today and try
[20:05] <kgunn> just been busy til now :)
[20:07] <utlemming> rsalveti: well, we could put the retry logic into cloud-init, but that is going to take an SRU cycle.
[20:07] <rsalveti> utlemming: we could experiment with that at our snappy ppa
[20:08] <utlemming> rsalveti: true
[20:08] <rsalveti> then if we actually confirm the fix, we can start a sru for it
[20:08] <kyrofa> kgunn, no problem, I just thought I'd try taking it for a spin today :) . I'll keep playing with it, ping me when you get a chance to mess with it again?
[20:17] <Saviq> jdstrand, resubmitted, thanks
[20:18] <utlemming> rsalveti: fixing this in cloud-init is not exactly straight forward
[20:23] <utlemming> rsalveti: actually, I don't think that fixing this in cloud-init is going to fix it
[20:23] <rsalveti> utlemming: why?
[20:23] <rsalveti> wither we do a retry logic in there or something before that code gets executed
[20:23] <utlemming> rsalveti: the cloud-init code searches for devices that have iso9660 and udf types. From that it finds that /dev/sr0 is a candidate.
[20:24] <rsalveti> right
[20:24] <rsalveti> but it does call mount after that, right?
[20:24] <rsalveti>  
[20:24] <rsalveti> 98
[20:24] <rsalveti>                 if cdev.startswith("/dev/"):
[20:24] <rsalveti>  
[20:24] <rsalveti> 99
[20:24] <rsalveti>                     ret = util.mount_cb(cdev, load_azure_ds_dir)
[20:24] <rsalveti> argh
[20:25] <utlemming> rsalveti: so the mere fact that it identified /dev/sr0 as iso9660 means that the mount failing is not a cloud-init issue, per se
[20:25] <utlemming> rsalveti: see lines 618
[20:25] <utlemming> through 625
[20:26] <jdstrand> Saviq: approved
[20:26] <Saviq> jdstrand, thank you
[20:27] <jdstrand> np
[20:28] <rsalveti> utlemming: right, it's definitely an issue in cloud-init itself, but we need to add the workaround logic for azure somewhere
[20:28] <rsalveti> we could add it before cloud-init, but it's also not so trivial since this is device specific
[20:28] <rsalveti> *not an issue
[20:28] <rsalveti> sorry
[20:28] <Letozaf_> hey guys, but once you installed packages like snake, and chatroom, for instance, If I do not know them, how can I find out how they have to be used, just to  check if they are workign
[20:29] <utlemming> rsalveti: so riddle me this...why does it work with rolling but not 15.04?
[20:29] <rsalveti> utlemming: it could be a pure race condition
[20:29] <rsalveti> slower boot?
[20:29] <rsalveti> which is why we wanted to add a retry logic to at least identify if that could indeed be the reason
[20:30] <rsalveti> we suspect it's the same issue we had for other block devices
[20:30] <rsalveti> which we added the wait-for-root workaround
[20:30] <utlemming> rsalveti: ack...okay, I can look
[21:16] <Saviq> ogra_, /me just noticed ogra@anubis being in authorized_keys on the pi2 image, you planning to take over the world?
[21:17] <rsalveti> yeah, that's his evil plan
[21:17] <Saviq> and /me finally managed to get ubuntu to boot with the emon board in!
[21:52] <Saviq> how do I preinstall webdm, for example, on my image? it's there in ogra_'s image, but not on mine, built using the same commands
[21:53] <Saviq> ah, oem/software
[21:53]  * Saviq tries
[21:57]  * Saviq likes bmaptool
[22:01] <Saviq> ok, oem/software is ignored
[22:02] <Saviq> d'oh
[22:04] <Saviq> it's actually working fine
[22:06] <Saviq> with the exception that `snappy build` craps out trying to unmount
[22:06]  * Saviq reboots for good measure
[22:07] <utlemming> rsalveti: yeah, so actually, this is a cloud-init bug. Its trying to mount a udf file system as iso9660
[22:07] <utlemming> rsalveti: I'm trying to track down why that is the case
[22:07] <rsalveti> utlemming: but why would that work on rolling then?
[22:08] <utlemming> rsalveti: I think it may be an ordering thing
[22:08] <rsalveti> hm, alright
[22:41] <utlemming> rsalveti: okay, nested exceptions....the real issue is https://bugs.launchpad.net/snappy/+bug/1472422
[22:41] <utlemming> rsalveti: which is the reason why provisioning fails
[22:41] <rsalveti> utlemming: interesting
[22:41] <rsalveti> let me upload a fix for that
[22:42] <utlemming> rsalveti: ack, thanks
[22:54] <rsalveti> utlemming: do you know if we need any other dir than /var/lib/waagent ?
[22:54] <rsalveti> this is just because we need a different fix in our images, since the main issue is that it tries to create that dir during runtime
[22:54] <rsalveti> and /var/lib is ro
[22:55] <rsalveti> so we need to create the dir in build time and make it writable
[22:55] <utlemming> rsalveti: er, no, I think the others that are needed are there
[22:55] <rsalveti> great
[23:17] <rsalveti> utlemming: pushed the fix, will trigger another image once it lands
[23:17] <rsalveti> we should know more tomorrow
[23:17] <utlemming> rsalveti: thank you kindly, I'll verify first thing in the morning
[23:18] <rsalveti> awesome, thanks for investigating the issue
[23:43] <elopio> rsalveti: I can't login with ubuntu/ubuntu to that image you published in cdimage.
[23:47] <elopio> that is on the amd image. On the beagle it works.