[00:32] sergiusens: kyrofa: would it be ok to add the nodejs version to the yaml? [00:32] it seems to work to package bonescript with node 0.10. [00:36] elopio, in the schema? [00:36] it does if we have links, yeah [00:36] is this older or newer? [00:37] sergiusens: older. [00:38] elopio, ah, then maybe test; if it is location indep as the current one it may be all ok [00:38] you are building the link from a constant. I think we can make that constant the default, and accept a variable from the conf. [00:38] elopio, as long as the semantics for installing are ok, we should be good [00:39] elopio, btw, for running the example tests, can we just download the image from mvo's pcc? [00:39] the problem is that the only example I have requires beaglebone, and I can't test if the generated snap works because bbb is busted. [00:40] sergiusens: yes, download it, start it in kvm, and then call ./runtests.sh --ip localhost --port 8022 [00:40] elopio, ah, nice [00:52] elopio, I'm no sure about adding the example as an example; since the example is not complete; what do you say? [00:54] sergiusens: do you mean the one by andreas? [00:54] elopio, yeah [00:54] sergiusens: yeah, I wasn't thinking about everything he has in there. [00:54] something more simple that shows the issue. [00:55] your unit tests are good, so this is not a blocker. But it would be nice to have. [00:56] elopio, something simple mean writing auto.*.ac and Makefile.am though and I am not profficient in that [00:56] let me see if I can find something simple [00:56] sergiusens: I understood you requested that from andreas. [01:21] Can anyone take a look at this pull request: https://github.com/ubuntu-core/snapcraft/pull/233 and let me know why it thinks the coverage has decreased? [01:21] nevermind, ignore my last comment. [01:22] elopio, kyrofa, sergiusens If possible can you take a look at this: https://github.com/ubuntu-core/snapcraft/pull/233 === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [04:51] how does deduplication work [05:04] what dedup you mean? === kickinz1|eod is now known as kickinz1 [08:03] good morning [10:00] Good morning all! Happy Friday, and happy Hat Day! 😃 🎩 [10:10] Chipaca, ping [10:10] liuxg: pong [10:11] Chipaca, I accidentally installed snapcraft by running "python3 setup.py install", now my snapcraft version is totally wrong. do you know if there is any method to remove the installation? [10:11] liuxg: you installed it at the system level, by hand? [10:12] liuxg: ie you actually did "sudo python3 setup.py install"? [10:12] liuxg: or did that install it in your home directory? [10:13] Chipaca, by hand, last time, snapcraft did not support the local source code, I reported a bug, and later on, sergiusens asked me to try it. I tried to install it by hand. [10:14] Chipaca, I tried the method at https://stackoverflow.com/questions/1550226/python-setup-py-uninstall , since I pulled down the latest repository, and now my snapcraft version is 2.0. I think it should not be so right for me. [10:14] liuxg: I'm afraid I have no idea in what state you've managed to put your system [10:14] Chipaca, yes, I actually did "sudo python3 setup.py install" manually on my PC. [10:14] oh dear [10:14] don't do that [10:14] ever [10:15] your system is now in an unknown state [10:15] Chipaca, I know it is too late. I really want to get it back. the snapcraft is totally wrong. [10:16] you have actively decided to take control of your system away from apt and do it manually [10:16] so you will have to clean it up manually [10:16] and hope that that is enough [10:16] liuxg: do you have a log of the installation process? [10:16] liuxg: to know exactly what that setup.py install actually installed? [10:16] Chipaca, now, the snapcraft info is like http://paste.ubuntu.com/14503790/ on my PC.. [10:18] Chipaca, as said, I followed the link https://stackoverflow.com/questions/1550226/python-setup-py-uninstall, and now the files are http://paste.ubuntu.com/14503796/ [10:19] Chipaca, I have removed the files already, however the snapcraft version still shows 2.0 [10:19] liuxg: do you have a log of the installation process? [10:20] Chipaca, I do not have that unfortunately, it happened long time ago. Do you want me to try it again? [10:21] Chipaca, the help content is still for 1.0 http://paste.ubuntu.com/14503819/ though the version shows 2.0 [10:22] no, do not try it again [10:23] liuxg: pastebin the output of: find /usr/local -ls [10:25] Chipaca, http://paste.ubuntu.com/14503836/ [10:26] liuxg: ok, i can't guid you through that [10:26] liuxg: what you need to do is remove all traces of snapcraft from your system [10:26] liuxg: and all the dependencies that the manual install installed [10:27] liuxg: but you've got too much other cruft in /usr/local for me to help [10:27] liuxg: so [10:27] liuxg: first, sudo apt-get purge snapcraft && sudo apt-get --purge autoremove [10:27] liuxg: then, manually remove from /usr/local anything your manual install might've installed [10:27] you've got django and npm and who-knows-what-else in there, so good luck with that [10:28] also given you've got npm, you've probably got your system in a screwy state anyway. You're on your own. [10:28] next time you feel the need to install something in your system without using apt-get, use a virtual machine [10:28] Chipaca, I have done sudo apt-get purge snapcraft && sudo apt-get --purge autoremove the command, so I need to reinstall it? [10:28] or tell whatever tool you're using to install stuff to do so in a local environment and not in the system itself [10:29] liuxg: you reinstall *after* cleaning /usr/local [10:31] Chipaca, do I need to remove all of the snapcraft related directories manually? [10:32] liuxg: the ones you created manually? yes [10:32] by manually there i mean 'via python3 setup.py' also [10:33] Chipaca, in fact, I did not manually create the directories. after running your "remove" command, the directory is like http://paste.ubuntu.com/14503863/ [10:34] Chipaca, may I just go ahead to manually remove those snapcraft related directoies? [10:34] liuxg: those are the ones you created via 'python3 setup.py' [10:35] Chipaca, I think so. I did not manually create those directories and files. [10:36] liuxg: apt-get did not create them; you created them yourself, using setup.py. You did not do 'mkdir', no, but you created them outside of the control of the packaging system [10:36] Chipaca, yes, I think the setup.py created them. [10:37] Chipaca, so, may I just remove them manually? [10:37] liuxg: I have told you yes twice already. This is the third time. Yes, remove manually those directories which you created using setup.py. [10:38] liuxg: as you have not kept a log of what you did with setup.py, I can't tell which those are. You're on your own. [10:38] Chipaca, OK. thanks! I just want to double confirm it :) [10:42] Chipaca, thanks for helping. now my snapcraft version become 1.0 :) [10:43] Help guys. I just download snappy OVA and run it. But default user/pwd not working [10:47] https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ [10:47] cant logon with ubuntu / ubuntu [10:47] any one ? [10:53] any know default user/pass other than ubuntu/ubuntu [10:54] sanong: not that I know [10:55] i download .OVA and boot vm [10:55] cant logon [10:57] ogra_: so I looked a bit into the multiple initird stuff for snappy - one generic initird from ubuntu-core, one with the kernel specific bits from the kernel. it seems feasible but I will need some help with the uboot stuff, do you think you could give me a hand with that? [11:10] mvo: who creates the ova files? [11:21] Chipaca: ova files? what does that mean? [11:21] mvo: it's one of the options here https://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/ [11:21] mvo: and was blogged about here https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ [11:21] mvo: but i know we don't build 'em [11:21] Chipaca: oh, I think thats ben howard [11:22] mvo: and sanong above was saying he couldn't log in with u/u [11:22] Chipaca: with this particular image he can not log in? [11:22] cant logon with ubuntu / ubuntu [11:23] he is no longer in the channel :/ did he/she mention what image? [11:25] mvo: i think there's only one, i can try it on vmware now ... [11:26] thanks beowulf [11:38] OVA was published https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ [11:39] by one of cannocal marketing [11:39] I think all snappy image will have same password. Any know ? [11:41] mvo_: sanong: i see that too, the ubuntu/ubuntu password doesn't work on that image [11:41] s/image/ova [11:42] anyone know password [11:46] utlemming: hi, I hope you are the right person to ask - do you know more about the ova images? we got a report from sanong that the login via ubuntu/ubuntu does not work with those. maybe thats intentional because of the cloud nature, but maybe https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ could mention if the login is different [11:47] mvo_: that is correct; OVA's are cloud targets [11:47] sanong: see above, this is intentional [11:48] sanong: is this for virtualbox or vmware or something else? [11:48] mvo_, sanong: http://blog.utlemming.org/2015/04/using-snappy-ova-images-when-you-dont.html [11:48] sanong: use option 2 [11:49] mvo_, multiple ? [11:49] why multiple [11:49] just move the modules into a squashfs and mount them right before anything else [11:49] ogra_: one generic one with our scripts and one with kernel modules if you boot your snappy from a remote iscsi target [11:50] sanong: cloud image targets need to have security. We can't have every cloud image of Snappy universally accessible by a well-known password [11:50] mvo_, well, if you boot from iscsi, your initrd needs to come from somewhere ... just put the modules suqshfs next to it in the same place [11:50] ogra_: right, we can do that if everything is in the kernel that is needed to mount root - this won't work right now even for us because of squashfs.ko. but mayb apw can help and make squashfs.ko a buildin for the kernel [11:50] and loop mount it [11:51] no [11:51] you dont need everything to mount root [11:51] you only need everything to loop mount the modules squashfs from the same place yoou load your intird from [11:51] ogra_: I'm not sure I follow. what if your initird comes from pxe boot? [11:51] wont work [11:51] well, tftp then [11:51] try that [11:51] already [11:52] if your initrd comes from the net that measn that you have a way to pull the suqashfs the same way [11:53] will that be the cause ? [11:53] i just dont see a need that we have more than /lib/modules|firmware in tthat squashfs [11:53] utlemming: i've been using u-d-f and then qemu-img convert to vmdk for vmware ... option 3 :) [11:54] mvo_, indeed that requires to have squashfs and loop device support in the kernel itself [11:54] ogra_: so our generic initird would fetch (cp, tftp, *) a file right next to the initird img and use that for the modules? and we enforce that the kernel has enough support buildin to get to that place? that works for me [11:55] (though i guess we dont necessarily need it to be a squash image) [11:55] ogra_: so we just need to convince the kernel people to give us this kernel [11:55] ogra_: yeah, it can be anything [11:55] right [11:56] orgra_: why not an initramfs script? [11:56] ogra_: works for me, lets talk about the details on monday [11:56] the PXE part will be a bit tricky since we need to do the loading from there ... we cant do it from the initrd, else we'd need all NIC modules [11:56] utlemming, ^ [11:56] :) [11:56] mvo_, yeah [11:56] ah, right [11:56] * ogra_ is looking forward to finally implement the generic initrd :) [11:57] oh ! [11:57] ogra_: well AIUI the multiple-initird is really just two initrds concacted so this approach might work for PXE [11:57] sanong: if you try option 2 as utlemming outlines in his blog post it will work [11:57] (or multiple ones, not just two) [11:57] * ogra_ just noticed that the DSL update on his second DSL line has happened while being at the dentist ... [11:57] WOHOOO !!! [11:57] from 2Mbit to 50 ! [11:57] ogra_: congrats [11:58] ogra_: thats a jump [11:58] yeah [11:58] hi, after I sideload install a snap on snappy, what is its package name? for example, webcam-webui demo of snapcraft-examples [11:58] well, i need to reconfig the phone stuff now ... else susie will kill me [11:58] ogra_: enjoy, we talk monday. the pxe issue with the nics sounds serious to me though, worth thinking about it more IMO [11:59] shuduo: "webcam-webui.sideload" I believe [11:59] mvo_, yeah [12:01] stevebiscuit: yes, it's . thanks. [12:01] mvo_, there is cirtainly some support for multiple initrds concatentated yes, they all get unpacked [12:01] mvo_, and if you want a generic one and a device specific one ramming them together on the rmeote server sounds like a good plan [12:01] mvo_, not that you can look at them any more with the tooling but hey [12:03] apw: cool, we can write new tooling for that - if thats fully supported that sounds like the easiest option. [12:03] ogra_: -^ [12:03] ogra_: if its just a concat but otherwise looks like a normal initrd that seems like its what we want, right? [12:03] mvo_, let me investigate to confirm, i know we use it for cpu firmware, that makes a dual initrfamfs [12:03] apw: thanks! [12:03] so the added part would have /lib/modules|firmware only ? [12:04] mvo_, i believe you can literally cat A B >initrd and the kernel groks them [12:04] ogra_: yeah [12:04] mvo_, if each is in the rigght format [12:04] apw: sweet [12:04] yeah, thats similar to mounting a squashfs i guess [12:04] just earlier [12:04] mvo_, but let me go and confirm that on a VM first [12:04] apw: thanks! [12:05] mvo_, the refulting file is just bits from a bootloader point of view [12:05] * mvo_ likes this [12:05] mvo_, and because we use it for cpu firmware i beleive we know the bootloaders ought to handle it right [12:05] apw: yeah, exactly, this is the part I like, pxe, uboot, grub all work as before, the smartz is in the kernel [12:05] mvo_, anyhow leave it with me for a little and i'll report back [12:05] apw: and we don't even need to modify anything in our scripts [12:05] apw: sure, no rush really [12:05] just the making the initrd needs to change [12:06] apw: I was waiting for an image upload and this was nagging in the back of my mind :) [12:06] and ... i assume ninitramfs-tools already knows how becuase it does it for cpu firmwae [12:06] mvo_, if i don't do it now i will forget :) [12:06] apw: yeah, well, we just make two initrds with the normal tooling and in the final stage do the cat - sounds easy [12:06] (foumous last words) [12:06] apw: ha! do it NOW [12:06] :) [12:06] * mvo_ gets lunch in the meantime [12:08] ogra_: sounds exciting, generic initird afterall :) [12:08] \o/ [12:08] ogra_: but I leave you alone, enjoy your vac [12:08] :) [12:08] yeah, and my new teeth :) [12:08] * ogra_ just returned from dentist [12:09] ogra_: woah, new dsl, new teeth, the year starts great it seems [12:10] (and generic initrd soon) [12:10] well, only interim teeth, but yeah ... after 20years the visibla gap is gone :) [12:10] ogra_, nice [12:20] Good morning [12:29] sergiusens, would it be bad if plugins could add apps? [12:30] kyrofa, not at all, but we need to design for it [12:31] kyrofa, as in, lets not just bolt that together and hope for the best passing the full snapcraft yaml dictionary to plugins [12:31] kyrofa, are you thinking of catkin? [12:32] kyrofa, the problem then becomes, is it a daemon, a cli, a desktop icon... [12:33] sergiusens, right, which would need to be handled by the plugin as well. And yeah, catkin and roscore (I'm still trying to think of how to get rid of the roscore plugin :P ) [12:34] kyrofa, I don't see why the catkin plugin can't just do everything in there [12:35] sergiusens, only one single reason: When we have the ability to share roscore, what if someone wants to make a shared .snap containing JUST roscore? [12:36] I guess if I updated the catkin plugin to accept building no packages, then they could specify the stage package and the app just like normal [12:36] sergiusens, think that would be good enough? [12:36] mvo_, ok confirmed if you make a second initramfs cpio.gz style image and literally cat play.gz >>initrd.img the kernel will load both and merge them before executing [12:37] mvo_, and from what i can see of the code it literally keeps trying until there is no data, so you can have 10 [12:38] kyrofa, I think so [12:38] kyrofa, but lets get this in and work on that next week as I guess it is not a 1 hour task :) [12:39] updated : OVA option 2 : still cant logon with ubuntu/ubuntu [12:39] try 2 image now [12:40] ogra_, enjoy some ferocious meat eating then ;-) [12:41] haha, i will :) [12:41] sergiusens, agreed. And if we can figure out a good way for plugins to add apps, that would get really slick [12:42] kyrofa, sure, let's brainstorm that a bit next week ;-) [12:42] sergiusens, or the week after, considering where you'll be :P [12:51] sergiusens, I need to miss standup-- I need to watch the kiddo this morning [12:54] kyrofa, no worries [12:57] mvo_: o/ [12:57] mvo_: I have been here for the past few weeks :) [12:59] * zyga posted https://github.com/ubuntu-core/snappy/pull/329 [12:59] more bool file work around security [13:01] * zyga refreshed https://github.com/ubuntu-core/snappy/pull/324 (merge with trunk, delta minimized) [13:09] tsimonq2: haha, sorrry :) there is so much going on, I did not really notice :) [13:09] :) [13:11] kyrofa, good job on the branch, I just tried it with all the other branches and it works fine :-) [13:11] sergiusens, excellent! [13:13] kyrofa, so the only thing I don't like about squashing is that I can't see what changed between two pushes, any easy way to check from the github ui? [13:15] sergiusens, hmm... there is in gitlab... looking [13:15] fgimenez, elopio: what does it mean when github says "no test results found" for integration tests? [13:17] flaky tests? flaky test system? something else? [13:19] sergiusens, it doesn't seem so. If it was just us I'd suggest using --fixup commits in response to PR review, and one autosquash before merge, but I'm concerned about asking the community at large to do that [13:22] kyrofa, maybe we can merge without using github ;-) [13:22] sergiusens, what are you thinking? [13:23] doing it manually [13:23] or maybe an automated task with our merge strategy [13:23] sergiusens, haha, I mean in what situation? [13:23] kyrofa, just random friday thoughts though [13:23] sergiusens, that's what Fridays are for :) [13:24] sergiusens, what should REALLY happen is that github should autosquash upon merge FOR you. That's what I think [13:24] kyrofa, ask jono for that ;-) [13:24] sergiusens, ha! Brilliant! [13:25] sergiusens, I mean, it would always succeed and the commit message is a given because they're fixups [13:25] kyrofa, hmm, you coverage has dropped :-P [13:25] sergiusens, I know... stupid roscore plugin [13:26] sergiusens, I need to bite the bullet and toast it. Next week maybe [13:27] sergiusens, but I think that PR is good to go if you're good with it [13:31] kyrofa, yay for toasting, and yes, I'm merging it before elopio wakes up ;) [13:44] * sergiusens takes a break to run a bit [13:45] mvo_, any idea when the new 15.04 image will be built? [13:48] kyrofa: its ready, I am prepareing the pre-build images as we speak [13:48] meeting right now [13:49] mvo_, excellent :) [14:03] zyga, that's normally because of a problem before the execution even starts, if you follow the "Details" link in the PR page you can reach the console log page to inspect the cause http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/344/console [14:04] zyga, it seems that there was a connectivity problem getting the dependencies [14:10] * zyga works on apparmor security module [14:10] fgimenez: thanks! what's the procedure in that case? Retry/ [14:14] kyrofa: you should get the new 15.04 via snappy update already (if you haven't already) [14:15] mvo_, nothing yet [14:18] kyrofa: what does snappy list show you? and what does snappy info show? [14:19] mvo_, wait... I see a version 12 with the release date of today. Is that it? Must have been done automatically? [14:19] kyrofa: yep, magic :) [14:19] kyrofa: great, thanks! [14:21] zyga, yes, you can retrigger the execution with a comment "retest this please" [14:28] mvo_, jdstrand ah, 15.04.12~ppa15 of the security packages didn't make it in eh? [14:28] kyrofa: unfortunately not it seems. I just checked myself [14:28] kyrofa: I tried. the builder and mvo were too fast [14:29] jdstrand, haha, that's alright, I can work around it for now :) [14:29] mvo_: context> there is an update to ubuntu-core-security that kyrofa needs that I tried to sneak in last night [14:30] jdstrand: hello :) [14:30] jdstrand: heh, the builders were not exactly fast :) thats unfortunate, but there is always a next image. how urgent is that update? [14:31] mvo_: I'll let kyrofa comment on that [14:31] zyga: hello :) [14:32] elopio, going to be 15' late if you don't mind [14:32] kyrofa, just in case ^ [14:32] mvo_, how often are images built? Think another one will come out before Wednesday? [14:32] kyrofa: unlikely. we can build anohter one, why wednesday? [14:33] mvo_, deadline for the owncloud stuff, but I can always add permission to the .snap temporarily [14:33] jdstrand: do you know of any sysfs symlink attacks? [14:34] jdstrand: just curiosity around how I've structured some bits in the code so far [14:34] jdstrand: is it a security issue to resolve symlinks in sysfs multiple times vs doing it once and caching the result [14:34] (for the same path0 [14:36] zyga: not otoh but I'd like tyhicks to comment too [14:37] jdstrand, tyhicks: https://github.com/ubuntu-core/snappy/pull/329/files that's the place [14:56] sergiusens, nothing makes you appreciate mksquashfs like using 1.0 [14:57] kyrofa, lol [14:58] mvo_: oh, also, big thank you for the emergency update :) [14:58] * jdstrand hugs mvo_ [15:00] jdstrand: heh, thanks! thank you for fixing it in the first place [15:01] mdeslaur: ^ :) [15:01] jdstrand: I read through the details of the cve [15:01] interessting stuff and scary [15:01] yeah, it was a really well done investigation [15:02] * jdstrand notes mdeslaur did the update-- he deserves the credit :) [15:03] jdstrand, ooo I'd like to read this [15:04] kyrofa: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/OpenSSHClientRoaming. at the bottom, see Qualys findings [15:05] jdstrand, ah, that explains why SSH updated on all my servers last night [15:05] indeed :) [15:11] elopio, I see your PR passed tests but stalled en coveralls [15:11] is that normal? [15:14] pindonga: ugh, no, it was a lie. Travis playing with my feeligs. [15:14] Fails with this: call to remove-on-empty (freezer:0) failed: invalid request [15:14] pindonga: what if you skip your tests if the system is not xenial? [15:14] I will run them here, and once we get this working they will start running on CI. [15:15] elopio, the problem is that my PR introduces a new dependency which currently is only available on xenial [15:15] not sure if it's worth playing the backports game here [15:16] unless of course we need the latest snappy to work on trusty [15:17] zyga: I'm not aware of any symlink attack possibilities in sysfs [15:17] pindonga: ah, right. We don't need to backport. So, let me bother stgraber one more time. [15:17] stgraber: I am now getting "call to remove-on-empty (freezer:0) failed: invalid request". Any pointers about how to fix that? [15:18] elopio, kyrofa mvo_ mind looking at this https://github.com/ubuntu-core/snapcraft/pull/234 it is the envvar replacement one [15:18] I'll run tests in the meantime [15:19] sergiusens: seems simple enough. And as snappy supports both for now, I won't even have to update my snaps. [15:23] elopio, right; that's why I want it in now; if people start uploading, they might as well have the smallest delta possible [15:24] agree. [15:32] tyhicks: thanks [15:56] mvo_, how do I get the latest snappy-debug on 16.04? [15:56] sergiusens: build as squashfs and upload to the edge channel with rolling as the target [15:56] sergiusens: this way you can only install it via snappy install snappy-debug/edge in 16.04 [15:57] sergiusens: but at least you can intsall it [15:57] and once the store is ready we can make it available without the edge [15:59] mvo_, I don't even know where snappy-debug sources are, I just consume it ;- [15:59] ;-) [15:59] sergiusens: neither do I, I would just download, unpack (dpkg-deb -x), repack and reupload :) [16:00] sergiusens: thats what I did with docker [16:00] mvo_, ack [16:07] elopio, for the deploy you need also to wait for the images to be built https://hub.docker.com/r/fgimenez/snappy-jenkins/builds/ https://hub.docker.com/r/fgimenez/snappy-jenkins-slave-xenial/builds/ and https://hub.docker.com/r/fgimenez/snappy-jenkins-slave-vivid/builds/ [16:07] elopio, green light ahead, just don't go to fast or a red light will get you crashing ;-) [16:10] sergiusens: do not be hasty, that is my motto. [16:10] https://i.ytimg.com/vi/8HHVPnvDBlU/maxresdefault.jpg [16:14] fgimenez: I forgot about this: https://github.com/ubuntu-core/snappy-jenkins/pull/45 [16:15] elopio, that IS south america :-P [16:30] fgimenez: for the cloud provision we are still using nova. [16:30] should we move that also to openstack? [16:31] elopio, yes we need to update that too, but it's not urgent IMO running from the laptop doesn't give the error, i'll take note of it [16:32] ack. [16:36] sergiusens, if vivid is EOL next month, what is the official recommendation for what people should be using for Ubuntu Core? [16:36] sergiusens, it can't really be rolling, can it? [16:38] fgimenez: do you know about this? http://pastebin.ubuntu.com/14505876/ [16:40] ah, that's the openstack bug. [16:41] elopio, yes https://bugs.launchpad.net/ubuntu/+source/python-keystoneclient/+bug/1242992, you are running from a canonistack instance, i forgot [16:41] Launchpad bug 1242992 in python-keystoneclient (Ubuntu) "Unable to autolaunch a dbus-daemon without a $DISPLAY for X11" [Undecided,Confirmed] [16:41] ok, I'll do the update here. [16:42] kyrofa, in theory, mvo_ is working hard to get an alpha channel or similar for 16.04 [16:42] but they know the plan better, or maybe olli [16:43] elopio, all the docker images have finished building [16:47] kyrofa, sergiusens my suggestion is to (ab)use the "edge" channel for 16.04 snaps - if that was the question, I lack some context here it seems [16:48] mvo_, vivid EOL is next month. My question was "what should people use between then and 16.04?" [16:48] mvo_, or will vivid Ubuntu Core continue to receive updates? [16:48] kyrofa: I think we need to continue to do updates for some weeks [16:48] kyrofa: I would love to get an alpha out and delcare it good enough [16:49] but there are some gaps still [16:49] mvo_, yeah, okay good I'm glad to hear that [16:49] mvo_, I know that's more work, but I think it'll be appreciated [16:54] fgimenez: is nova boot --poll the same as openstack server create --wait? [16:55] elopio, yes, but not sure if the output has the same fields/format, maybe our checks needs some tweaking [16:56] I will know soon. [16:57] sergiusens: so this 2.0 release should work on all snaps? or also on the rolling edge non-all-snaps? [17:00] elopio, on both, but why? [17:00] sergiusens: just to see which one to flash. [17:00] elopio, flash all snaps [17:00] elopio, obviously ;-) [17:04] mvo_, bootloader stuff now lives in the kernel, rght? [17:04] or should live there [17:16] sergiusens: should, its not done yet, still the gadget that is doing it [17:24] mvo_, right, I'm just in "writing presentation" mode [17:34] sergiusens, can you explain now the tmp stuff works? In the binary wrapper I see `TMPDIR="/tmp/snaps/name/version/tmp"`, but when I look in /tmp I see /tmp/snap.0_name_version/ which contains a file called tmp [17:35] sergiusens, is there some confinement magic happening there? [17:39] cgroups and mounts [17:39] kyrofa, ^ [17:40] sergiusens, okay very good, thanks :) [18:04] sergiusens: the shout port is 9000, right? [18:06] elopio, I will lie if I say yes [18:06] elopio, check with netstat [18:07] sergiusens: shows only 22 for tcp. [18:08] I think it's not serving, but the logs show no errors, as far as I can see. [18:14] fails on rolling edge #320 and on all snaps. [18:14] sergiusens: kyrofa: can one of you verify if you can access the shout or webchat port from the host? [18:16] elopio, let me check [18:20] kyrofa, I still have /usr/bin/python, can you give it a try? [18:20] sergiusens, yeah one sec [18:21] One more thing. Latest rolling edge, I get (amd64)ubuntu@localhost:~$ java-hello-world.hello [18:21] /apps/java-hello-world.sideload/IKNMMGUUJQeN/command-hello.wrapper: 9: exec: /bin/wrapper: not found [18:21] sergiusens: kyrofa ^ [18:21] it works on all snaps. [18:21] maybe it doesn't have the short env vars. [18:22] elopio, I guess it is the cap [18:22] elopio, install hello-world.mvo and verify ;-) [18:23] sergiusens: hello-world.echo from hello-world.mvo works. [18:23] elopio, I mean, run hello-world.env and check the env :-) [18:23] ah [18:24] sergiusens, to verify: the ros example has stuff rewritten fine? [18:24] SNAPP_APP_PATH=/apps/hello-world.mvo/2.0 [18:24]