| pitti | elopio: where are you running this? --flavor autopkgtest is a custom flavor that only exists in scalingstack | 07:41 |
|---|---|---|
| pitti | elopio: in principle that looks like a correct invocation, yes; add some -d after adt-run and ssh to see what happens | 07:41 |
| fgimenez | good morning | 08:08 |
| dholbach | good morning | 08:23 |
| zyga | good morning :) | 08:24 |
| didrocks | good morning dholbach, fgimenez and zyga! | 08:25 |
| dholbach | salut didrocks | 08:25 |
| fgimenez | hey hey didrocks, dholbach and zyga :) | 08:27 |
| dholbach | hola fgimenez :) | 08:27 |
| fgimenez | zyga, quick question for you (i guess), what is the minimum yaml for a snap to provide a skill, is this enough http://paste.ubuntu.com/15072870/ ? | 08:31 |
| zyga | looking | 08:35 |
| zyga | fgimenez: I think you can abbreviate that further to offsers: [bool-file] | 08:36 |
| * zyga checks the spec | 08:36 | |
| zyga | type defaults to name | 08:36 |
| zyga | unless changed explicitly | 08:36 |
| zyga | fgimenez: are you building a snap that provides the bool file skill? | 08:36 |
| fgimenez | zyga, i'm beginning with integration tests for skills, i'm using the branch you pointed out last friday as a base | 08:38 |
| fgimenez | yep, thanks already looked at that, but was having problems after building the snap, let me try again and paste you the results | 08:38 |
| zyga | nice | 08:38 |
| zyga | fgimenez: sure, let's work together on this | 08:39 |
| fgimenez | zyga, great :) | 08:39 |
| clobrano | hello everybody, I assume that it's possible to install different version of the same snap, but I'm getting an error like this "failed to install: a package by that name is already installed". I'm installing a snap file in my filesystem, it's version is 0.7, while the version installed is 0.6. Any Idea? Thanks! | 08:48 |
| fgimenez | zyga, ok for the provider, the problems are with the consumer, probably uses: [bool-file] doesn't work there? http://paste.ubuntu.com/15072941/ | 08:51 |
| zyga | fgimenez: hmm, yes, it seems that snappy-side parsing is not correct yet | 08:55 |
| zyga | fgimenez: note that we haven't enabled bool-file (or any other non-migration skill) -- we are trying to do that since last week but we need to do it in the state engine desing and that's not trivial | 08:56 |
| zyga | fgimenez: so even if all my branches today would land, you would still not be able to use bool file in practice | 08:56 |
| fgimenez | zyga, ok np, i'll try to keep an eye on the development and update the tests accordingly, bool-file is the first skill type that is going to be available, right? | 08:57 |
| zyga | yes | 08:57 |
| fgimenez | zyga, ok thanks, could we write something about the migration-skill or is this going to go away shortly? | 08:58 |
| fgimenez | zyga, write some integration tests i mean :) | 08:59 |
| zyga | fgimenez: I think not shortly | 09:01 |
| zyga | fgimenez: but that's not exercising anything new (though the test will stay valid) | 09:01 |
| zyga | fgimenez: migration skill is not using the skills system yet | 09:02 |
| zyga | fgimenez: I think a lot will become clearer this week | 09:02 |
| zyga | fgimenez: then we can plan which tests to invest in | 09:02 |
| fgimenez | zyga, great thanks | 09:04 |
| clobrano | uhm, I just read this https://developer.ubuntu.com/en/snappy/guides/packages-names/, at which Phase are we now? Is it already possible to install more version of the same snap? Thanks | 09:05 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| === cprov_ is now known as cprov | ||
| === davidcalle_ is now known as davidcalle | ||
| * zyga writes a small piglow demo | 09:48 | |
| === vrruiz_ is now known as rvr | ||
| ysionneau | asac: Hi! I just managed to get snappy boot correctly in qemu (with cloud-init working and therefore the ubuntu/ubuntu login working) | 10:25 |
| ysionneau | I had indeed to merge a bit of kernel config + extract the initrd from the rpi2 snappy .img | 10:26 |
| ysionneau | I still need to figure out why I don't have any network interface (apart from lo) :o | 10:32 |
| zyga | ysionneau: out of curiosity, how do you run qemu? | 10:37 |
| ysionneau | ./arm-softmmu/qemu-system-arm -M raspi2 -smp 4 -kernel ~/dev/kernel-rpi2/linux/arch/arm/boot/zImage -sd ~/Downloads/ubuntu-15.04-snappy-armhf-raspi2.img -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -dtb ~/dev/kernel-rpi2/linux/arch/arm/boot/dts/bcm2709-rpi-2-b.dtb -usbdevice mouse -usbdevice keyboard -net nic,model=smc91c111 -net user -nographic -redir :8090::80 -redir :8022::22 -initrd ~/initr | 10:39 |
| ysionneau | something like that | 10:39 |
| ysionneau | maybe I should extract snappy dtb and use that instead of my own vanilla dtb | 10:41 |
| ysionneau | let's try that. | 10:41 |
| ysionneau | Warning: requested NIC (anonymous, model unspecified) was not created (not supported by this machine?) | 10:46 |
| ysionneau | hmmm I guess the raspi2 qemu port just does not support NIC | 10:46 |
| ysionneau | :/ | 10:46 |
| === bigcat_ is now known as bigcat | ||
| ysionneau | what's weird is that even with a usb network device it does not work (-usbdevice net). The kernel detects the USB NIC, but no usb0 is created | 10:49 |
| asac | ysionneau: nice! | 12:12 |
| asac | ysionneau: is raspi2 in standard qemu? | 12:12 |
| asac | ysionneau: have you tried with our default kernel etc.? | 12:13 |
| === chihchun is now known as chihchun_afk | ||
| ysionneau | 13:12 < asac> ysionneau: is raspi2 in standard qemu? < nop, I used this: https://github.com/0xabu/qemu | 12:27 |
| ysionneau | 13:13 < asac> ysionneau: have you tried with our default kernel etc.? < hmm no, lemme try | 12:27 |
| asac | ysionneau: right. so afaik the NIC is a USB nic on the raspi2 | 12:28 |
| asac | :) | 12:28 |
| asac | so think you are on right track and just need to get the right kernel that supports the usb device you "plug in" | 12:29 |
| ogra_ | thats quite fiddly with qemu (bot doable) | 12:38 |
| ogra_ | *but | 12:38 |
| ysionneau | hmm interesting, at least with the snappy kernel, I get an eth0 iface | 12:40 |
| ysionneau | but I still get some errors and I don't have network | 12:40 |
| ogra_ | it has the driver builtin iirc | 12:40 |
| ysionneau | http://paste.ubuntu.com/15073838/ | 12:41 |
| ogra_ | you probably need some tun/tap device setup the VM attaches to | 12:42 |
| ogra_ | (i'm just widly guessing here though) | 12:42 |
| ysionneau | in theory, in -net user mode, I should not need that, but let's try in bridge mode | 12:43 |
| ysionneau | I often think of finding correct qemu args as black magic | 12:46 |
| ysionneau | like ffmpeg cmdline | 12:46 |
| ysionneau | when you find the correct line, you keep it preciously | 12:47 |
| ogra_ | hah | 12:48 |
| asac | yeah i agree | 12:54 |
| asac | qemu arguments to do what you want and still work together is like ffmpeg :) | 12:54 |
| asac | but think you are close :_) | 12:55 |
| ysionneau | hmmm cannot get an ip address | 13:10 |
| ysionneau | I think the usb nic is buggy somehow | 13:10 |
| ysionneau | either in qemu or in the linux kernel I use | 13:11 |
| ysionneau | maybe I should rebase the qemu port onto qemu master | 13:11 |
| asac | ysionneau: did you try our kernel? | 13:22 |
| ysionneau | asac: yes, with your kernel it improves the situation a bit, I can get an eth0 iface | 13:31 |
| ysionneau | but it is not usable | 13:31 |
| Tomer | hi there, i'm trying to compile bluez5 for an RPi 2 running snappy core 15.04, but the generated snap package is for amd64, is it possible to compile for ARMv7? | 13:33 |
| ogra_ | yes, if you do it on an armv7 system | 13:35 |
| ogra_ | (i.e. on the rpi) | 13:35 |
| Tomer | how do I install tools like git on the snappy core (apt-get not available...)? I'm a total noob regarding snappy core | 13:36 |
| ysionneau | asac: hmmm you said I should not use arm64 version on 15.04 because it's not very well tested and not stable. What about having an arm64 kernel but using the arm32 15.04 system? Does this work? | 13:37 |
| ysionneau | an arm64 kernel should be able to run an arm32 user space | 13:37 |
| opny | ysionneau, asac I've spent a bit of time on snappy vs qemu too. On 15.04 eth0 never get an ip and cloud-init failed | 13:37 |
| ysionneau | I'm asking because we have a drone on Tegra X1 (arm64) | 13:37 |
| ogra_ | well, in 16.04 there is the classic dimension, that gives you a full apt environment on demand for such stuff ... in 15.04 you can use a container (lxc or docker) or you can use a chroot | 13:37 |
| ysionneau | and it would be cool for me to be able to test 15.04 on Tegra X1 board | 13:37 |
| asac | ysionneau: interesting idea :) | 13:38 |
| asac | ricmm: what do you think? guess could work to use a arm64 kernel and make it work with our 15.04 image | 13:38 |
| asac | ? | 13:38 |
| ysionneau | arm64 kernel + your arm32 images | 13:39 |
| ysionneau | opny: which -M were you using? (which board were you emulating?) | 13:39 |
| opny | ysionneau, vexpress-a9 | 13:40 |
| ogra_ | asac, i think 15.04 is still a bit risky wrt arm64, i'D go straight to 16.04 for that | 13:40 |
| asac | nah | 13:41 |
| asac | ogra_: we are talkinga bout using 32-bit image | 13:41 |
| ricmm | you can try armhf userland sure | 13:41 |
| asac | with 64-bit kernel | 13:41 |
| ogra_ | (and actually use arm64 for the rootfs too) | 13:41 |
| asac | no | 13:41 |
| asac | its not ready enough :) | 13:41 |
| ogra_ | why not ? | 13:41 |
| asac | not ready enough | 13:41 |
| ogra_ | nonsense :P | 13:41 |
| ogra_ | i'm just running it here ... rock solid :) | 13:41 |
| ogra_ | (and i compiled some quite heavy stuff on the weekend (webkit and qtwebkit) on it ... i have seen no issues) | 13:43 |
| opny | ysionneau, I was trying to emulate armhf/ armv7 https://github.com/muka/qemu-snappy-experiments/blob/master/run-snappy.sh | 13:45 |
| ysionneau | opny: have you tried with a usb NIC? maybe you will be luckier than me | 13:46 |
| ysionneau | ogra_: I'm a bit lost, you are saying 15.04 is risky for arm64 (kernel ? or user space?) and then afterward you say it's rock solid? Maybe I misunderstood something | 13:46 |
| ogra_ | ysionneau, i'm not sure how ready 15.04 is ... we just added arm64 to 16.04 though, this is what i'm using here and it is rock solid | 13:48 |
| ysionneau | ah ok arm64 with 16.04 is rock solid, got it | 13:48 |
| ogra_ | (15.04 will be droped when 16.04 goes stable so all dev focus is on 16.04 currently) | 13:48 |
| zyga | ogra_: hey | 13:48 |
| ysionneau | but, what about having the arm32 userland on 15.04 but with an arm64 kernel? | 13:48 |
| ysionneau | should be "ok", right? | 13:48 |
| ogra_ | technically, yes | 13:49 |
| ogra_ | practically i have no experience with that :) | 13:49 |
| ysionneau | only thing that bothers me with 16.04 is 1°) it's not released yet 2°) it's not much documented like 15.04 | 13:49 |
| ogra_ | yeah, and constantly moving | 13:49 |
| ysionneau | 15.04 dev/support will be dropped as soon as 16.04 is released? | 13:50 |
| ysionneau | meaning all the ubuntu website documentation will turn into 16.04 compatible tutorials? | 13:50 |
| ogra_ | (its a bit of a pain to make snaps if your floor changes underneath you all the time ... but the worst changes should have landed by now) | 13:50 |
| ogra_ | yeah | 13:50 |
| ysionneau | if the snappy release cycle is like normal ubuntu, 16.04 release is pretty soon :o | 13:51 |
| ysionneau | but I would have finished my evaluation long before the release anyway | 13:51 |
| ogra_ | well, snappy is a rolling release, so they are not really synced up (156.04 will see fixes and changes after release for sure) ... but the stable channel will switch to it by 16.04 release or shortly after | 13:52 |
| ogra_ | s/156.04/16.04/ | 13:52 |
| ysionneau | hmmm doesn't rolling release mean there is "no" release? | 13:53 |
| ysionneau | like a 15.04 will become automatically a 16.04? | 13:53 |
| ogra_ | it isnt that easy since the image design changed in an incompatible way | 13:54 |
| ogra_ | so you have to re-flash for 16.04 ... | 13:54 |
| ysionneau | ok | 13:54 |
| ogra_ | (there is no easy way to migrate to the new partitioning for example) | 13:55 |
| ysionneau | right got it | 14:01 |
| elopio | fgimenez: do you know why I can't ssh into an scalingstack ubuntu-server instance created from jenkins? | 14:11 |
| === bpierre_ is now known as bpierre | ||
| === benoitc_ is now known as benoitc | ||
| fgimenez | elopio, mm no idea, are you adding the user's keypair in the create command? | 14:31 |
| elopio | fgimenez: there is one keypair for RegionOne in the slaves. I'm passing it's name to the create command. | 14:32 |
| fgimenez | elopio, and then you try to ssh from a canonistack instance passing as -i the private key, right? | 14:32 |
| dpm | davidcalle, dholbach, popey mentions that on the getting started snappy page the rpi2 image link is out of date - could perhaps one you update it to the 16.04 image? Either popey or ogra should have the right link | 14:36 |
| ogra_ | dpm, no | 14:36 |
| ogra_ | dpm, 16.-04 isnt released, we only point to stable images | 14:37 |
| ogra_ | (the links will be updated once we release 16.04 as stable) | 14:37 |
| elopio | fgimenez: where is the private key of the RegionOne keypair? | 14:38 |
| ogra_ | we could perhaps link to dev images additionally, once we actually have the all-snaps one coming from the build system | 14:39 |
| ogra_ | but thats still a bit away | 14:39 |
| fgimenez | elopio, i think it must be in the tarmac server, let me check | 14:39 |
| ogra_ | (the only "proper" 16.04 image is atm the one that mvo builds by hand ... nothing we should promote yet) | 14:39 |
| fgimenez | elopio, yes, there it is, ~/credentials/scalingstack/ues-snappy-integration_RegionOne.key | 14:41 |
| elopio | fgimenez: yes, I tried with that one. | 14:41 |
| elopio | no luck. | 14:41 |
| fgimenez | elopio, no idea, the snappy instances used in the tests doesn't use this keypair, anyway you can always create a new one | 14:43 |
| elopio | fgimenez: should I create a new keypair as part of the deploy? | 14:44 |
| fgimenez | elopio, sure that way it won't need any secret management, if the deploy and the keypair have short live it's a good solution. if the deployed instances are expected to last longer maybe you could use an existing keypair | 14:47 |
| opny | Hi, in a snap (xenial) I've used printenv to have a clue of avail vars but I'm a bit confused now .. $SNAP is where the executable is. What is the difference of $SNAP_APP_DATA_PATH and $SNAP_USER_DATA ? | 15:17 |
| opny | http://paste.ubuntu.com/15075093/ | 15:18 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| ogra_ | opny, there used to be a wikipage but i cant find it anymore | 15:33 |
| opny | ok thanks | 15:33 |
| ogra_ | the USER stuff is all for actual executables a user can manually run though | 15:34 |
| ogra_ | SNAP_APP_DATA_PATH is just the writable area of the snap ... used by services etc | 15:34 |
| opny | Do you think there is a sane way to have like a `ln -s` at build time paths that are hardcoded in the app runninig in a snap? | 15:36 |
| ogra_ | i would do that from a startup wrapper | 15:38 |
| opny | ogra_, oh that's right.. I have a read call like /run/resolvconf/resolv.conf I cannot see a way to solve that.. | 15:42 |
| opny | or read from something like /proc/2368/net/ipv6_route (read) | 15:46 |
| ogra_ | opny, yeah, i dubt confinement will allow you | 15:53 |
| ogra_ | probably tyhicks or jdstrand have some hint if/how thats possible | 15:53 |
| opny | ogra_, I've noticed. Shouldn't the app see the fs as root (/) ? | 15:54 |
| ogra_ | nope | 15:55 |
| ogra_ | it sees its real path ... but cant access anything outside | 15:55 |
| olli_ | hey | 15:56 |
| olli_ | morning | 15:56 |
| opny | ouch, so bad... | 15:56 |
| opny | and let's add either a "only a single skill is supported, 2 found" | 15:56 |
| opny | to the soup | 15:56 |
| * ogra_ isnt much familiar with skills yet ... i had just started to understand caps ... then they were replaced :) | 15:57 | |
| opny | ogra_, well being aware that I am not alone is a good start :) | 15:58 |
| opny | ogra_, *IRC101* how do you do that chat reflection thingy? | 16:00 |
| ogra_ | "chat reflection thingy"? | 16:01 |
| opny | * ogra_ isnt much familiar with skills yet .. | 16:01 |
| ogra_ | /me isnt much familiar .... | 16:01 |
| * opny is learning IRC | 16:01 | |
| ogra_ | :) | 16:01 |
| opny | that's has been a productive day | 16:02 |
| opny | :) | 16:02 |
| zyga | opny: skills are not live yet | 16:02 |
| zyga | opny: except for migration-skill | 16:02 |
| opny | zyga, oh that's good | 16:03 |
| opny | zyga, thanks, do you know if they will be avail ? (I found them in snapcraft json/yaml schema) | 16:06 |
| ysionneau | when using arm64 kernel with rpi2 (arm32) image it boots but I get cloud-init issues (url_helper.py) when not using any initrd. | 16:08 |
| ysionneau | if I use the initrd from the rpi2 snappy img I get this : http://paste.ubuntu.com/15075934/ | 16:09 |
| ysionneau | boot freezes at this point | 16:09 |
| ogra_ | you *need* to use the initrd, else you wont get the proper mount farm ... | 16:09 |
| ysionneau | that's what I understood | 16:10 |
| ysionneau | ah, if I wait long enough I get some timeout and it told me it's a rootfs name issue ("could not find fe02 root partition") | 16:10 |
| ysionneau | I'll try other names | 16:10 |
| ogra_ | Kernel command line: rw earlyprintk loglevel=8 console=ttyAMA0,115200 root=fe02 | 16:11 |
| ogra_ | this cant work at all | 16:11 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | u-boot has a huge scriptery that assembles an actual cmdline | 16:11 |
| ogra_ | try mimicing one from a booted system instead | 16:12 |
| ogra_ | (i.e. boot snappy once and copy the cmdline into your qemu call) | 16:12 |
| ogra_ | since you are not using uboot | 16:12 |
| wigleworm | I used the java "hello-world" example in snapcraft and the resulting snap was 130MB - is that correct? | 16:13 |
| wigleworm | why so large | 16:13 |
| ogra_ | because it includes hjava i'd guess :) | 16:13 |
| ogra_ | *java | 16:13 |
| ysionneau | 17:12 < ogra_> try mimicing one from a booted system instead < ok :) | 16:14 |
| wigleworm | any clue where to look for a method to pair that down? | 16:14 |
| ogra_ | i dont think there is one ... apart from making java itself smaller or some such | 16:15 |
| ogra_ | if you want your snap to run java bits the jvm needs to be shipped along | 16:15 |
| wigleworm | also, from the example I could not see where the script was pulling JAVA from - anyone know? | 16:15 |
| wigleworm | ogra - thank you | 16:16 |
| ogra_ | that would be a quaesion for the snapcraft guys ... but sergiuens isnt arund and i dont know if kyrofa is familiar with the java bits | 16:16 |
| ogra_ | you should be able to dig though the snapcraft plugin code though ... | 16:17 |
| wigleworm | is there another channel for snapcraft or is this it? | 16:19 |
| wigleworm | irc channel that is | 16:19 |
| ogra_ | this is it ... | 16:19 |
| ogra_ | there is a sprint at the US westcoast that many are attending, so catching people from the team might be hard this week | 16:20 |
| wigleworm | -orga_- thank you, I will dig into the snapcraft docs | 16:20 |
| fgimenez | elopio, i'm getting lots of errors like this http://paste.ubuntu.com/15076159/, can you please try to reproduce when you have time? | 16:21 |
| elopio | fgimenez: sure. | 16:22 |
| fgimenez | elopio, the image used by jenkins was built a few weeks ago and we still don't have the automation in place with the new sources, maybe something has changed somewhere that make the new one fail, if you confirm the error i can manually trigger the build to make it visible in the PRs | 16:24 |
| fgimenez | elopio, we can also put the build job in cron mode and create a new image every day, the cleanup jobs are working now | 16:26 |
| elopio | fgimenez: I updated my snappy image and I can install hello world. | 16:31 |
| elopio | it's using ubuntu-core 2016-02-12. | 16:31 |
| ogra_ | crazy stuff ! | 16:31 |
| elopio | fgimenez: ah, the error is running it. | 16:33 |
| elopio | fgimenez: yes, confirmed. Pleaes report the bug. | 16:33 |
| ogra_ | elopio, did you guys already start testing with all-snap images ? | 16:34 |
| fgimenez | elopio, sure, i'll fire up also a new image build | 16:34 |
| ogra_ | or are you wating til they come from the official build system | 16:34 |
| elopio | ogra_: jenkins is testing the pull requests with all-snaps. | 16:34 |
| ogra_ | cool ! | 16:35 |
| elopio | fgimenez: also confirmed that it doesn't happen with ubuntu-core from 2016-02-03 | 16:35 |
| ysionneau | with root=/dev/vda2 now it boots, and cloud-init works (I also added a few parameters from a /proc/cmdline of a live snappy system= | 16:36 |
| ysionneau | and I also have a network iface ... "sit0" but it only gets ipv6 address upon dhcp :o | 16:36 |
| ogra_ | ysionneau, still wrong | 16:36 |
| ogra_ | ysionneau, root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc | 16:37 |
| ogra_ | thats the least you want in the kernel cmdline ... | 16:37 |
| elopio | wigleworm: it is installing the default-jdk package from the archive. | 16:37 |
| ysionneau | yes I've put the panic=-1 and init stuff | 16:37 |
| ysionneau | I'll try with the remaining parts | 16:38 |
| ysionneau | are you sure I'm supposed to boot on the writable rootfs ? :o seems weird | 16:40 |
| ysionneau | others seem to boot from the system-a or system-b fs | 16:40 |
| ogra_ | ysionneau, you want the init= and the root= | 16:41 |
| ogra_ | panic and fixrtc arent that important | 16:42 |
| ysionneau | if I do root=/dev/disk/by-label/system-a it works way better than writable | 16:46 |
| ogra_ | lol | 16:46 |
| ogra_ | yeah, sorry | 16:47 |
| ogra_ | i'm running the all-snaps image ... you indeed want system-a on older images | 16:47 |
| ogra_ | sorry | 16:47 |
| ogra_ | (in all-snaps system-a is actually a loop device living in /writable which is why thats the rootfs device) | 16:47 |
| === kickinz1 is now known as kickinz1|afk | ||
| fgimenez | elopio, the new image is uploaded and it's already showing the error http://162.213.35.179:8080/job/snappy-daily-rolling-openstack/103/console | 17:02 |
| elopio | fgimenez: great. I set the bug priority as critical. | 17:03 |
| wigleworm | elopio: :) I wish I knew - do you know how I find out? | 17:05 |
| elopio | wigleworm: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/jdk.py#L24 | 17:06 |
| fgimenez | elopio, thx, i'll prepare the changes for reacting to modifications in the snaps from the store and build the images accordingly, hopefully it won't take too long | 17:07 |
| elopio | fgimenez: have you decided on a name for the images? | 17:07 |
| * ogra_ votes for "fred" | 17:08 | |
| ogra_ | (unless they are female indeed) | 17:08 |
| fgimenez | elopio, i think that your idea of the timestamps is great, we can sort and select them without modifying the existing tools, -tests-job and -cloud-image | 17:08 |
| elopio | elsa for female. | 17:09 |
| ogra_ | +1 | 17:09 |
| elopio | fgimenez: but then the -1 trick wouldn't work. Because it won't necessarily be ubuntu-core -1. It could be kernel -1. | 17:10 |
| wigleworm | elopio: from the file that you linked me to, I am guessing it is installing whatevere I have installed - is that correct | 17:10 |
| elopio | I think we need to modify the tools. | 17:10 |
| ogra_ | wigleworm, it is running "apt-get install default-jdk" | 17:11 |
| ogra_ | inmside the snapcraft dir | 17:11 |
| elopio | wigleworm: https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-parts.md | 17:11 |
| ogra_ | ogra@styx:~$ apt-cache show default-jdk|grep Depends | 17:12 |
| ogra_ | Depends: default-jre (= 2:1.7-52), openjdk-7-jdk (>= 7~u3-2.1.1) | 17:12 |
| ogra_ | (thats what i get on 15.10) | 17:12 |
| elopio | take a look at stage-packages in that link. | 17:12 |
| wigleworm | ok, I see default-jdk :) - understand that | 17:14 |
| wigleworm | where does default-jdk get defined - i.e. is it set to 1.7.x. or 1.8.x? | 17:14 |
| fgimenez | elopio, ok, i'll submit a PR and we can discuss there, the alternative could be 3 separate padded version numbers of our own, so that we can sort and compare | 17:14 |
| ogra_ | wigleworm, in the ubuntu archive | 17:15 |
| elopio | fgimenez: maybe we extend snappy-cloud-client to receive optional versions for the three snaps. If there's no image, it will create one and upload it to glance. | 17:15 |
| elopio | fgimenez: then we don't care about the name, we'll just use whatever ip it returns. | 17:15 |
| wigleworm | ogra_ - thanks, can you point me in the direction of the ubuntu archive or tell what I am searching for exaclty? | 17:16 |
| ogra_ | wigleworm, like the gcc package depends on a specific gcc-$version package ... it is selected during a release | 17:16 |
| fgimenez | elopio, but how do we know if we have available an image for the requested versions, if the versions are not stored in the name? and it can be ugly, only ubuntu-core's version looks like 2016-02-12 16.04.0-14... well, we can discuss in the PR | 17:19 |
| ogra_ | wigleworm, just run "apt-cache show default-jdk|grep Depends" on your machine and it will tell you which open jdk version it would install | 17:19 |
| wigleworm | so is it looking at the dev system and saying "which version is the default java?" and then down loading that version? | 17:19 |
| wigleworm | ok, so basically the default jdk for the development system that was used to create the snap | 17:20 |
| ogra_ | yeah | 17:20 |
| elopio | fgimenez: yes, I mean that the name will only be important for the tool that returns the ip, not for the jobs. But of course we need a way to identify the versions in the image. It's late for you, let's talk later. | 17:21 |
| wigleworm | ok, thank you | 17:21 |
| fgimenez | elopio, ok nice evening everyone o/ | 17:23 |
| longsleep | hey folks it has been a while since i had time to work with snappy, to get up to speed is there a vagrant box to get a 16.04 snappy running quickly? | 17:23 |
| elopio | longsleep: we are finishing the details of the new all-snaps images for 16.04. In the meantime you can get images from https://people.canonical.com/~mvo/all-snaps/ | 17:24 |
| longsleep | elopio: great thanks | 17:24 |
| ogra_ | elopio, not sure thats suitable for vagrant without converting it though | 17:25 |
| ogra_ | there are currenly no all-snap cloud images afaik | 17:25 |
| longsleep | well i can upgrade my odroidc stuff but i guess i have to learn some new stuff first then | 17:26 |
| longsleep | so i would need something which runs in kvm or virtualbox | 17:26 |
| ogra_ | the amd64 one runs fine in kvm | 17:30 |
| longsleep | ogra_: ah ok great - i will use that one for now then - thanks! | 17:31 |
| ogra_ | but iirc vagrant needs a special image format you need to convert to | 17:31 |
| longsleep | no problem - i can boot a plain disk image | 17:31 |
| ogra_ | longsleep, good to have you back btw :) | 17:31 |
| longsleep | ogra_: yeah - i am still very busy and not much snappy time unfortunately :/ | 17:32 |
| ogra_ | sad ... but busy means you guys are getting forward, thats good :) | 17:32 |
| wigleworm | ok, new issue with java-hello-world. I installed the snap and ran it - error - no java found. Then I did some searchs on the system and I found that java is on the system, under the snap I just install but it seems like my program (snap) does not know where to look. Should I be setting a "path" somewhere in the hello sample or somewhere else? | 17:36 |
| ogra_ | dont you need JAVA_HOME in java ? | 17:37 |
| ogra_ | or some such | 17:37 |
| ogra_ | the wrapper script that runs the app should set this to your snap dir | 17:37 |
| ogra_ | (or respectively to the path underneath the snap dir actually) | 17:38 |
| longsleep | ogra_: amd64-all-snap.img.xz booted just fine thanks! | 17:52 |
| ogra_ | awesome | 17:52 |
| longsleep | some grub migration service failed, thats normal? | 17:52 |
| ogra_ | longsleep, sudo snappy enable-classic; snappy shell classic | 17:52 |
| ogra_ | thats one of the new awesome things ;) | 17:53 |
| ogra_ | longsleep, yeah, we need to look into that | 17:53 |
| ogra_ | should be harmless though | 17:53 |
| longsleep | yeah i follow the maillinglist - will try that for sure | 17:53 |
| longsleep | ogra_: no more snappy search? | 17:56 |
| ogra_ | snap find | 17:56 |
| longsleep | cool thanks | 17:56 |
| ogra_ | (but snapy install ..., yay consistency) | 17:56 |
| longsleep | well - once you know it :) | 17:57 |
| longsleep | ogra_: ok, maybe last question for today - how do i sideload a snap quickly now? | 18:01 |
| ogra_ | same as before | 18:01 |
| longsleep | mhm getting some wild error | 18:01 |
| longsleep | /tmp/spreed-webrtc_0.24.10-1_amd64.snap failed to install: can not open /tmp/spreed-webrtc_0.24.10-1_amd64.snap: cannot open snap: unknown header: "!<arch>\ndebian-binar" | 18:01 |
| ogra_ | suo snappy install --allow-unauthenticated /peth/to/snap | 18:01 |
| ogra_ | yeah ... it should rather say "unsupported snap version" | 18:01 |
| longsleep | ah | 18:01 |
| ogra_ | 16.04 requires squashfs snaps without the click package legacy (which is dpkg based) | 18:02 |
| longsleep | good, i guess then i have something to work on for tomorrow | 18:02 |
| longsleep | i assume snapcraft has the gear to build those snaps? | 18:02 |
| * ogra_ looks forward to 16.04 release ... all that "floor moves underneath you all the time" is really painful | 18:03 | |
| ogra_ | yeah | 18:03 |
| ogra_ | you need xenial though | 18:03 |
| ogra_ | (a chroot or what not) | 18:03 |
| longsleep | ok, xenial vagrant already somewhere? | 18:03 |
| ogra_ | dunno ... you mean normal server ? | 18:04 |
| longsleep | yes to run snapcraft | 18:04 |
| ogra_ | there surely is ... but dont ask me where :) | 18:04 |
| longsleep | guess i can use those https://cloud-images.ubuntu.com/xenial/ | 18:04 |
| ogra_ | yeah | 18:04 |
| * zyga hacks on i2c skills | 18:10 | |
| elopio | kyrofa: are you here today? | 19:13 |
| === kzapalowicz is now known as koza | ||
| zyga | ogra_: hey, still around? would you mind telling me where the gadget snaps live (sources?) | 20:50 |
| wigleworm | back again looking for java and snapcraft help | 21:32 |
| wigleworm | I have now twice used the example code | 21:32 |
| wigleworm | and both times snapcraft completes and creates a snap (java-hello-word exaple) | 21:33 |
| wigleworm | install the snap and run the wrapper <-- I think thats what I am suposed to do | 21:34 |
| wigleworm | I get "./wrapper: 2: ./wrapper: java: not found | 21:34 |
| wigleworm | Comments on what I should do to debug this would be welcome | 21:35 |
| barty | hi! just a fast question. I've discovered today snappy and installed it in a RPI2. I'm from Spain and I'm unable to change the default keyboard layout to spanish. I've search a lot over the web and found nothing. Anyone there know how to do it? | 21:47 |
| wigleworm | barty: are you familiar with desktop ubuntu "dpkg" program? | 21:53 |
| wigleworm | more than likely you can use that and install the "consol-common" deb pkg on the system - you will need to make sure that you get the dependencies that are needed though | 21:55 |
| barty | ok :) | 21:56 |
| barty | I thought there will be a command already installed like locale-get or something | 21:56 |
| barty | thank you very much!!!! | 21:56 |
| wigleworm | @bar(input):button2 | 21:58 |
| nothal | wigleworm: No such command! | 21:58 |
| wigleworm | huh? | 21:58 |
| wigleworm | nothal: are you saying dpkg wont work? | 22:01 |
| wigleworm | I just used it the other day | 22:01 |
| barty | I'm using dpkg right now. I think nothal says no such command like locale-gen | 22:01 |
| longsleep | bug #1458866 | 22:01 |
| ubottu | bug 1458866 in Snappy "hangs in uboot boot prompt if dtbs dir is missing" [Critical,Triaged] https://launchpad.net/bugs/1458866 | 22:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!