| elopio | um, scratch that. | 00:08 |
|---|---|---|
| elopio | downloaded again and now it works. | 00:08 |
| elopio | unping. | 00:08 |
| Saviq | jdstrand, when you have a sec, I had to upload a new version of emonhub-pi, the review tools did not get an update yet | 01:04 |
| jdstrand | Saviq: accepted | 02:34 |
| === chihchun_afk is now known as chihchun | ||
| === wolfeidau_ is now known as wolfeidau | ||
| dholbach | good morning | 06:44 |
| fgimenez | good morning | 07:01 |
| ogra_ | Saviq, heh, yeah, thats a fake key (--developer-mode needs it) ... next image i'll edit my name out :) | 07:12 |
| ogra_ | Saviq, for installing packages ubuntu-device-flash has the --install option ;) | 07:22 |
| ogra_ | (that's how webdm gets into my image) | 07:23 |
| Saviq | ogra_, yup, learned that, too, but oem/software works after all | 07:51 |
| Saviq | is there (will there be) a way to hw-assign from an OEM snap? or a gadget snap? | 07:52 |
| Saviq | heh and why does unity-settings-daemon die when building an image :D | 07:54 |
| ogra_ | you mean to ship a config with an app snap that enables certain hw access by default ? | 07:54 |
| Saviq | ogra_, not sure if an app snap, but maybe an oem/gadget snap? | 07:54 |
| Saviq | ogra_, but well, sure, app would work, too | 07:55 |
| ogra_ | i think you wont be able to upload that to the store, but for sideloading there should be an ability | 07:55 |
| ogra_ | an oem or gadget snap has full HW access | 07:55 |
| ogra_ | and access to hwe from a framework or app snap needs to be defined for that snap | 07:55 |
| ogra_ | *hw | 07:56 |
| Saviq | ogra_, didn't find anything re: hw-assign in https://developer.ubuntu.com/en/snappy/guides/oem/ - that's where I'd expect to put it? under /oem/hardware | 07:58 |
| ogra_ | what exactly would you do with it ? | 07:59 |
| Saviq | ogra_, I want for an app to have access to /dev/ttyAMA0 straight after flashing | 07:59 |
| ogra_ | right, so that app snap needs to define it, not the oem snap | 08:00 |
| Saviq | but it won't be accepted to the store? | 08:00 |
| ogra_ | it wouldnt be accepted with a default that silently enables access to the device | 08:00 |
| ogra_ | the requirement is that the admin runs the hw-assign command for the snap to switch on the access | 08:01 |
| ogra_ | after installing it | 08:01 |
| Saviq | hmm so how do we plan to support these kind of usecases, say, a managed switch app | 08:01 |
| Saviq | if you want to sell a managed switch, you can't leave the hw-assign to the end user | 08:01 |
| ogra_ | well, for you as developer there will be a way to sideload | 08:02 |
| Saviq | sure, I'm thinking end-user | 08:02 |
| Saviq | [...] or expect for the factory line to boot and run hw-assign on every unit? | 08:02 |
| ogra_ | if you sell a managed switch with a branded and preinstalled image you will likely also have your own store namespace | 08:02 |
| ogra_ | in which you will be able to put such a snap | 08:02 |
| Saviq | hmm | 08:03 |
| ogra_ | (for details better ask the store people :) ) | 08:03 |
| Saviq | ppisati, hi, do you know of a way to disable serial in u-boot for the raspi2? I tried changing std{in,out,err}, but that didn't help, only thing that worked was to set bootdelay to 0 so that it ignores any input (I've an expansion board that talks on ttyAMA0 and interrupts the boot process) | 08:49 |
| Saviq | I thought changing std... should work, but u-boot still reads from the serial port and interrupts auto-boot because the board sends stuff through | 08:51 |
| ppisati | Saviq: disabling uboot from reading the serial... | 08:51 |
| ppisati | Saviq: no idea | 08:52 |
| ppisati | Saviq: you probably need to build your own uboot | 08:52 |
| ogra_ | well, on the Rpi a lot of the initialization is done via the binary blob ... | 08:54 |
| ogra_ | so even building your own uboot might not help | 08:54 |
| ppisati | right, i forgot about thir binary blob | 08:56 |
| ppisati | ogra_: deos it emit anything on the console? i don't remember... | 08:57 |
| ppisati | uhm | 08:57 |
| ogra_ | i dont think it does | 08:57 |
| ogra_ | but i think it initializes it | 08:57 |
| ogra_ | there might be a way to manage that via config.txt | 08:58 |
| Saviq | well, bootdelay=0 it is :P | 08:59 |
| Saviq | it's not like the usb keyboard works anyway ;P | 08:59 |
| ogra_ | bootdelay=0 in config.txt ? | 08:59 |
| ogra_ | as a uboot param it only disables the ability to stop the autoboot | 09:00 |
| ogra_ | wouldnt change anything in console usage | 09:00 |
| Saviq | ogra_, no, setenv | 09:24 |
| Saviq | ogra_, and my problem is exactly that - autoboot is stopped because serial is talking | 09:25 |
| ogra_ | but udev always talks to serial ... it just doesnt wait for input when autoboot is off | 09:27 |
| ogra_ | err | 09:27 |
| ogra_ | "autoboot interception" | 09:27 |
| ppisati | Saviq: i don't see any option to disable the serial output | 09:31 |
| ppisati | Saviq: you can try to change the baud/serial clock | 09:31 |
| ppisati | Saviq: and hope that it doesn't interfer | 09:31 |
| ppisati | albeit it's a crappy solution. i know :) | 09:31 |
| * ogra_ just notes what he wrote above :P | 09:33 | |
| ogra_ | s/udev/uboot/ | 09:33 |
| Saviq | ogra_, sure, and that's exactly it - I just need it to boot, and it doesn't if I leave it - because the board I have is talking on serial on boot, so interrupts u-boot | 09:50 |
| Saviq | ppisati, it's not about output, input rather | 09:51 |
| ppisati | Saviq: same logic applies | 09:51 |
| ogra_ | Saviq, well, thats a matter of luck then | 09:51 |
| ppisati | Saviq: since you don't have any option to not init the serial, wreak it | 09:51 |
| ppisati | Saviq: or better | 09:51 |
| ppisati | Saviq: write an email to the raspy2/broadcom people | 09:51 |
| ppisati | Saviq: and ask for that feature | 09:52 |
| ppisati | Saviq: btw, how did you make it work with the original broadcom img? | 09:52 |
| Saviq | ogra_, sure, I'm not saying bootdelay is the right solution | 09:52 |
| Saviq | ppisati, it Just Works with https://wiki.ubuntu.com/ARM/RaspberryPi and Raspbian | 09:52 |
| Saviq | ppisati, afaict the bootloader there (not u-boot) isn't talking on serial by default? | 09:52 |
| ppisati | Saviq: then patch our uboot | 09:53 |
| ppisati | Saviq: and rip out the serial input part | 09:53 |
| Saviq | ppisati, yeah, need to dig into u-boot for that, there's no obvious configs for that, the only relevant thing I found was SILENT... but that won't help with input I don't think | 09:54 |
| Saviq | I was really expecting setenv stdin "usbkbd" to work | 09:55 |
| Saviq | because it was serial,usbkbd by default | 09:55 |
| Saviq | but that didn't change anything | 09:55 |
| Saviq | so yeah, still looking for the right solution, am ok with the interim one though | 09:56 |
| Rlyeh | Hi all | 10:18 |
| Rlyeh | Is there any GUI for snappy? | 10:18 |
| dholbach | Rlyeh, https://developer.ubuntu.com/en/snappy/guides/webdm/? | 10:19 |
| ogra_ | only web currently | 10:19 |
| Rlyeh | I'm using it now | 10:19 |
| Rlyeh | Thank you | 10:19 |
| seb128 | bah, I don't understand | 10:36 |
| seb128 | upgrading that snappy install, mounting /boot/efi fails | 10:37 |
| seb128 | "FAT-fs (vda2): IO charset iso8859-1 not found" | 10:37 |
| seb128 | but the same partition mounts fine booting the old / on system-b | 10:37 |
| === greyback__ is now known as greyback | ||
| ogra_ | shouldnt it be mounted all the time ? | 10:40 |
| seb128 | ogra_, I don't think so, it's in fstab | 10:43 |
| seb128 | the mount target fails and sends systemd in debug mode | 10:43 |
| ogra_ | sounds like a module mistmatch or so | 10:48 |
| ogra_ | can you check lsmod between the two boots ? | 10:48 |
| seb128 | ogra_, yeah, on the failed boot lsmod lists only psmouse and pata_acpi | 10:55 |
| ogra_ | do you see modules in /lib/modules/* ? | 10:56 |
| seb128 | hum | 10:56 |
| seb128 | only a /lib/modiles/4.0.0-4-generic | 10:57 |
| ogra_ | and nothin underneat ? | 10:57 |
| seb128 | but the kernel in use is 3.19.0-22 | 10:57 |
| ogra_ | ah | 10:57 |
| seb128 | yes, they are there | 10:57 |
| seb128 | but modproble looks for a 3.19 | 10:57 |
| ogra_ | right | 10:57 |
| seb128 | wth | 10:57 |
| seb128 | /boot has 4.0 | 10:58 |
| ogra_ | sounds like an issue with the grub stuff again ? | 10:58 |
| seb128 | where is the booted 3.19 kernel coming from? | 10:58 |
| seb128 | I guess | 10:58 |
| ogra_ | Chipaca, ^^^ ? | 10:58 |
| seb128 | mvo_, sergiusens, Chipaca, ^ | 10:58 |
| ogra_ | i wonder if we hardcode 3.* soemwhere for the version :P | 10:59 |
| seb128 | could be... | 10:59 |
| Chipaca | whasup? | 11:01 |
| Chipaca | seb128: is this on personal? | 11:01 |
| seb128 | yes | 11:02 |
| seb128 | Chipaca, I installed personal 28 yesterday | 11:03 |
| seb128 | and upgraded to 30 with "snappy update" | 11:03 |
| seb128 | the new version fails to boot, it load a kernel 3.19 but the /boot version is 4.0 | 11:03 |
| seb128 | which makes it fail to load modules | 11:03 |
| Chipaca | seb128: what gadget snap does personal use? | 11:06 |
| seb128 | no idea, how do I tell? | 11:06 |
| seb128 | amd64_generic iirc | 11:06 |
| seb128 | if that's one | 11:06 |
| Chipaca | seb128: rolling , yes? | 11:10 |
| seb128 | yes | 11:10 |
| seb128 | Chipaca, http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/ | 11:10 |
| seb128 | Chipaca, looks like $prefix/a and /b both have the 3.19 kernel | 11:11 |
| seb128 | where today's image /boot has 4.0 | 11:11 |
| Chipaca | why does /boot have a kernel, and why are you booting that instead if $prefix/a or /b? | 11:11 |
| seb128 | so unsure what is supposed to update the boot kernels but that went wrong | 11:12 |
| seb128 | Chipaca, well, it's booting $prefix/a /b | 11:12 |
| seb128 | which is what creates the issue | 11:12 |
| Chipaca | sounds to me like personal is broken | 11:12 |
| seb128 | the system-b partition has /lib/modules/4.0 | 11:12 |
| seb128 | which is the current wily kernel | 11:12 |
| seb128 | $prefix/b should have a 4.0 kernel | 11:13 |
| seb128 | that matches the installed os | 11:13 |
| seb128 | Chipaca, could be, but the issue is that the $prefix/b kernel is the old one and not matching the current image kernel | 11:13 |
| seb128 | new image work fine | 11:13 |
| seb128 | it's just a snappy updated one that has that issue | 11:14 |
| Chipaca | seb128: the kernel should not be on /boot | 11:14 |
| Chipaca | it should be on /boot/a/etc | 11:14 |
| seb128 | right | 11:14 |
| Chipaca | boot/grub/a/ or whatever it is | 11:14 |
| seb128 | it loads (gd0,gp2)/EFI/ubuntu/grub/a | 11:14 |
| seb128 | that is 3.19 | 11:14 |
| seb128 | but then it tries to boot | 11:14 |
| Chipaca | which is why i say it sounds like personal is broken | 11:14 |
| seb128 | and disk has /lib/modules/4 | 11:15 |
| seb128 | no 3.19 | 11:15 |
| seb128 | so it fails to load modules | 11:15 |
| seb128 | sorry if what I wrote is confusing | 11:15 |
| seb128 | it does boot the a/b vmlinuz versions | 11:15 |
| seb128 | the issue is that personal 30, which is today image has /lib/modules/4 | 11:16 |
| seb128 | new kernel major | 11:16 |
| seb128 | and for some reason the b partition from the upgrade has an old kernel | 11:16 |
| seb128 | so boot fails because it doesn't find modules matching the kernel | 11:16 |
| Chipaca | yes, yes, i understand | 11:16 |
| Chipaca | it was not confusing | 11:16 |
| ogra_ | Chipaca, how would personal be able to break an underlying mechanism ? | 11:16 |
| Chipaca | i mean, your description wasn't | 11:16 |
| seb128 | k | 11:17 |
| ogra_ | snappy should work distinct from that | 11:17 |
| seb128 | but it's not personal which includes the boot/grub/b | 11:17 |
| seb128 | that was generated/build at the upgrade time | 11:17 |
| seb128 | new image don't have that issue | 11:17 |
| seb128 | Chipaca, the b partition kernel is somehow copied when updating the image I guess? do you know what code does that? | 11:19 |
| Chipaca | seb128: snappy copies it | 11:20 |
| seb128 | from where? | 11:20 |
| Chipaca | seb128: the new version might not include a kernel, in which case it gets copied | 11:21 |
| seb128 | is that coming from the device tarball? | 11:22 |
| seb128 | well the "new version" has a kernel, if you meant the image | 11:23 |
| Chipaca | i don't know where and if the device tarball comes into it :) | 11:23 |
| seb128 | since a fresh image builds fine | 11:23 |
| seb128 | boots fine | 11:23 |
| Chipaca | i expect sergiusens will take one look at the symptoms and know what's going on | 11:23 |
| seb128 | k | 11:23 |
| Chipaca | so better wait for him than waste time guessing now | 11:24 |
| seb128 | let's wait for him then | 11:24 |
| seb128 | thanks | 11:24 |
| Chipaca | if he comes in and doesn't, then let's sleuth around | 11:24 |
| sergiusens | seb128: Chipaca ogra_ the livecdrootfs "kernel" and "initrd" entries are all that matter now | 11:25 |
| ogra_ | sergiusens, and seb128 got that one installed ... but the old one was completelly removed (so no modules) | 11:26 |
| Chipaca | sergiusens: mo'in :) | 11:26 |
| sergiusens | so /boot/grub/[a|b]/vmlinuz | 11:26 |
| sergiusens | ogra_: oh nice, how did that happen? | 11:26 |
| seb128 | sergiusens, hey | 11:26 |
| seb128 | sergiusens, install snappy personal 28 from yesterday | 11:27 |
| seb128 | snappy update | 11:27 |
| seb128 | reboot | 11:27 |
| seb128 | get a system-b boot | 11:27 |
| seb128 | kernel loaded is 3.19 | 11:27 |
| seb128 | disk / files are 4.0 | 11:27 |
| seb128 | boots fail to load any module | 11:27 |
| seb128 | sergiusens, that's the summary | 11:27 |
| sergiusens | seb128: lib/modules/ only for 4 as well? | 11:27 |
| seb128 | yes | 11:27 |
| seb128 | which is basically what fails the boot | 11:27 |
| sergiusens | strange | 11:28 |
| ogra_ | do you have another kernel in /boot directly or some such ? | 11:28 |
| seb128 | modprobe something gives a "fails to load /lib/modules/3.19..." | 11:28 |
| seb128 | no | 11:28 |
| sergiusens | ogra_: there is, I didn't clean those up either in the 500-.*kernel.* task | 11:28 |
| ogra_ | sergiusens, perhaps grub falls back to that ... lbut if seb128 says there isnt one ... | 11:28 |
| sergiusens | there should be in /boot (system-[ab]) | 11:28 |
| sergiusens | ogra_: our grub.cfg doesn't look for one there | 11:29 |
| seb128 | sergiusens, ogra_, http://picpaste.com/grub-9EyGcmUy.png | 11:30 |
| seb128 | if that helps | 11:30 |
| seb128 | http://picpaste.com/pics/grub-9EyGcmUy.1436355024.png | 11:30 |
| seb128 | the vmlinuz size on those matches the 3.19 from hd0,4 | 11:31 |
| sergiusens | seb128: right, that /boot is system-a/boot/ | 11:32 |
| seb128 | sergiusens, well, in any case $prefix/a|b shouldn't be identical | 11:33 |
| sergiusens | seb128: what's in (hd0,2)/[a|b] ? | 11:33 |
| sergiusens | oh, sorry it's above | 11:33 |
| seb128 | right | 11:34 |
| seb128 | neither matches the system kernel | 11:34 |
| seb128 | they both match the old image 3.19 one | 11:34 |
| sergiusens | seb128: I need to see the system-image delta because this would make them look the same: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-desktop-next/hooks/500-move-kernel-to-device-tar.binary | 11:37 |
| seb128 | sergiusens, where is the delta? | 11:37 |
| sergiusens | seb128: /pool/device-c06d05a678026547b8d48d99556b24281164724e7bffd61c95c261c6e9e3ab70.delta-device-4c246a16efc5ecf0c5f861394250cd68147710376c24d533939365c748939449.tar.xz | 11:38 |
| seb128 | sergiusens, do you need that from my system or...? | 11:39 |
| sergiusens | seb128: oh no, I'm downloading for s-i, you don't have it in it's original form anymore ;-) | 11:40 |
| seb128 | k | 11:40 |
| seb128 | let me know if you need more info from me | 11:40 |
| seb128 | but you can probably reproduce by installed personal 29 | 11:40 |
| seb128 | then doing a snappy update | 11:40 |
| seb128 | installing* | 11:41 |
| sergiusens | seb128: I bet core has the same problem | 11:41 |
| sergiusens | fgimenez: ^ | 11:41 |
| seb128 | yeah, I'm doing an install now to see | 11:41 |
| seb128 | but I would bet the same | 11:41 |
| * ogra_ thinks seb128 should just have used the stable personal image ... there also lightdm and the session would work :P | 11:48 | |
| seb128 | :-) | 11:48 |
| utlemming | sergiusens, rsalveti: I am happy to report that with 118, we have a working 15.04 edge for Azure. | 11:49 |
| rsalveti | utlemming: \o/ | 11:49 |
| rsalveti | elopio: fgimenez: I published another image yesterday with a minor fix for azure, and hopefully that should be the last known bug we have | 11:50 |
| ogra_ | utlemming, yay | 11:50 |
| fgimenez | rsalveti, ok thx 118 then right? | 11:52 |
| sergiusens | utlemming: \o/ | 11:52 |
| rsalveti | fgimenez: yeah, and 119 for armhf | 11:52 |
| rsalveti | they are out of sync | 11:52 |
| fgimenez | rsalveti, ok | 11:52 |
| fgimenez | sergiusens, sorry wasn't connected :) which problem on core? | 11:53 |
| utlemming | sergiusens, rsalveti: thank you guys for the help in getting this cleared. You guys were great :) | 11:53 |
| sergiusens | np | 11:54 |
| sergiusens | seb128: ogra_ mvo_ Chipaca these are the system image delivered files in the delta: http://paste.ubuntu.com/11841020/ | 11:59 |
| sergiusens | seb128: ogra_ mvo_ Chipaca assets/vmlinuz and system/boot/vmlinuz-4... | 11:59 |
| sergiusens | this is a livecd-rootfs/s-i problem and not a snappy update one I think | 12:00 |
| sergiusens | and 'removed' basically removes 3.19 | 12:00 |
| ogra_ | sergiusens, eparse ? (for your last line) | 12:05 |
| mvo_ | sergiusens: hm, it should be possible to reproduce this on core too - let me try that | 12:05 |
| sergiusens | ogra_: the s-i 'removed' file has 3.19 listed as a remove target | 12:07 |
| sergiusens | mvo_: yeah, that is the suspicion | 12:07 |
| ogra_ | ah | 12:08 |
| sergiusens | mvo_: I'm not sure how to make livecd-rootfs and/or s-i do what we want though | 12:08 |
| ogra_ | hmm | 12:09 |
| ogra_ | how often do we actually copy the azure tarball around ? | 12:09 |
| ogra_ | there seems to be a cp in live-build/auto/build and there is a hook as well where the same cp gets called | 12:09 |
| sergiusens | ogra_: for rolling we shouldn't be needing it soon-ish | 12:10 |
| ogra_ | well, and even then i guess once would be enough :) | 12:11 |
| ogra_ | i dont see where livecd-rootfs could be wrong here | 12:12 |
| ogra_ | the code seems all fine | 12:13 |
| sergiusens | ogra_: yeah, I don't either | 12:15 |
| sergiusens | ogra_: but how would a different kernel than the one copied end up there? | 12:16 |
| ogra_ | bug in s-i ? | 12:16 |
| sergiusens | ogra_: hmmm, maybe .signed is != than the unsigned one | 12:17 |
| ogra_ | yeah | 12:17 |
| ogra_ | well, we dont ship .signed | 12:17 |
| ogra_ | we copy/move it to be plain vmlinuz, no ? | 12:17 |
| sergiusens | ogra_: yes we do, vmlinuz-4.0.0-4-generic.efi.signed | 12:18 |
| sergiusens | ogra_: yeah, there's an if in the 500 task that prefers the .signed one | 12:18 |
| sergiusens | ogra_: mvo_ that's it | 12:18 |
| ogra_ | but we should have the signed 4.0 one there at that point | 12:19 |
| sergiusens | ogra_: mvo_ I mean, that is the reason for the different sig http://paste.ubuntu.com/11841115/ | 12:19 |
| ogra_ | why would we end up with a 3.x signed one during build | 12:19 |
| ogra_ | ah | 12:19 |
| sergiusens | seb128: can you md5sum the kernels? | 12:20 |
| sergiusens | ogra_: they are all 4.0 delivered in the delta | 12:22 |
| sergiusens | mvo_: this makes me thing the SyncBootAssets stuff runs after the upgrader logic and it is overwritting | 12:22 |
| sergiusens | think* | 12:22 |
| seb128 | sergiusens, what kernels? the a/b vmlinuz? | 12:27 |
| sergiusens | seb128: yeah | 12:28 |
| seb128 | that's going to match the 3.19 kernel I guess | 12:28 |
| seb128 | since they are byte identical in size | 12:28 |
| rsalveti | Saviq: ogra_: you'll be able to assign hardware to snaps at the gadget snap later on, the spec for that is still in progress | 12:28 |
| seb128 | from the ls earlier | 12:29 |
| ogra_ | rsalveti, that still wont enable it in your app snap | 12:29 |
| Saviq | rsalveti, ah, /me just wrote a nice post to the snappy-devel ML ;) | 12:29 |
| sergiusens | seb128: right, then no worries | 12:29 |
| ogra_ | rsalveti, for that you still need to either call hw-assign or have a sideloaded snap that has it enabled | 12:29 |
| Saviq | hmm? | 12:30 |
| sergiusens | Saviq: rsalveti dev nodes are assignable through the oem snap today | 12:32 |
| Saviq | d'oh | 12:32 |
| rsalveti | if just hw-assign yeah, you can do that | 12:32 |
| rsalveti | but for the gadget snap there is also the idea of abstracting hardware and assigning a special piece of hardware to an app or framework | 12:32 |
| sergiusens | Saviq: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ | 12:33 |
| Saviq | ogra_, ppisati, btw, I just grokked what you guys were talking about "the raspi blob and config.txt", I don't think that's a problem as when not using U-Boot (and IIUC booting straight into the kernel) there's no such problems | 12:33 |
| Saviq | sergiusens, right, I was sure I read about that somewhere, but it's not there in the oem guide, or in the packaging reference | 12:33 |
| sergiusens | Saviq: no it's not :-/ | 12:34 |
| * sergiusens blames mvo ;-) | 12:34 | |
| rsalveti | guess we can make an mr for that doc :-) | 12:34 |
| ogra_ | Saviq, RPi can not boot without the binary blob ... | 12:34 |
| mvo_ | sergiusens: hm? | 12:34 |
| === mvo_ is now known as mvo | ||
| ogra_ | Saviq, it is: blob -> u-boot -> kernel | 12:35 |
| Saviq | ogra_, yes | 12:35 |
| sergiusens | mvo: not documenting the oem hw-assign work :-) | 12:35 |
| mvo | *cough* | 12:35 |
| mvo | lalalala | 12:35 |
| Saviq | ogra_, others go blob -> kernel directly | 12:35 |
| ogra_ | yes | 12:35 |
| ogra_ | and dont use an initrd | 12:35 |
| Saviq | ogra_, so disabling console=ttyAMA0 there is enough | 12:35 |
| ogra_ | in the config.txt you mean ? | 12:35 |
| Saviq | ogra_, yes | 12:35 |
| Saviq | ogra_, but when u-boot comes into play, u-boot itself talks serial, too, so changing uEnv.txt is not enough | 12:36 |
| Saviq | ogra_, so all in all I still just need to disable serial in u-boot, and bootdelay 0 gets it done, while obviously not a good solution | 12:36 |
| ogra_ | well, i fear there is no good solution :) | 12:37 |
| ogra_ | as long as there is that binary blob ... | 12:37 |
| Saviq | that's why I thought dropping "serial" from u-boot's env std{in,out,err} would work, but it didn't (sounds like a bug) | 12:37 |
| ogra_ | well, sounds like an upstream bug then | 12:38 |
| Saviq | ogra_, well, it's u-boot that's problematic in my case, blob isn't great for sure, but isn't a problem atm | 12:38 |
| Saviq | ogra_, totally, will go to them to find out | 12:39 |
| === erkules_ is now known as erkules | ||
| seb128 | sergiusens, mvo, do you want a bug report/more info from me on that upgrade/kernel issue? | 13:00 |
| mvo | seb128: I think that would be good, with the exact image versions | 13:01 |
| Saviq | beuno, hey, sorry to bug you, could I ask you to remove emonhub-pi.saviq from the store? I had to rename it (if you could ack emonhub.saviq please - it passes click-review with tools-proposed PPA) and it ended up under phone for some reason, as well as snappy | 13:05 |
| ogra_ | Saviq, isnt there an option in the store UI for you to do it yourself ? | 13:06 |
| Saviq | ogra_, can't see it, it's there for drafts, otherwise I can only unpublish | 13:06 |
| ogra_ | yeah, unpublish was what i meant | 13:07 |
| ogra_ | unpublish and publish again | 13:07 |
| Saviq | ogra_, don't think I can rename this way, can I? and I don't want it under Phone, either, not sure how it ended up there | 13:07 |
| ogra_ | you can not rename | 13:08 |
| kyrofa | seb128, so I created an Ubuntu Personal image with u-d-f and got it in KVM, but I only get the unity8 greeter with the QXL video model, and then my mouse pointer is strangely offset from my actual mouse so I can't possibly get through the edge demo, haha | 13:08 |
| ogra_ | you need a new submission and delete the old one from the store | 13:08 |
| Saviq | ogra_, yeah, which is what I asked for, I can't delete myself it seems | 13:08 |
| ogra_ | kyrofa, wow, thats more than i get ! | 13:08 |
| seb128 | kyrofa, use virt-manager rather than kvm maybe? | 13:08 |
| ogra_ | Saviq, you can unpublish | 13:08 |
| seb128 | kyrofa, I don't get those issues with it | 13:08 |
| Saviq | ogra_, that I did | 13:08 |
| ogra_ | that should delete everything | 13:08 |
| Saviq | ogra_, well, it's still there, just not published ;) | 13:09 |
| ogra_ | and then create a new app in the store under the new name | 13:09 |
| ogra_ | you can not use the old bits anyway | 13:09 |
| kyrofa | seb128, I used virt-manager... thought that was still kvm? | 13:09 |
| Saviq | ogra_, that still leaves me with the original in the list, my OCD can't deal with that ;) | 13:09 |
| ogra_ | heh | 13:09 |
| kyrofa | ogra_, what's happening for you? | 13:10 |
| ogra_ | kyrofa, lightdm with guest account ... if i hit enter it logs into a black screen | 13:10 |
| kyrofa | seb128, initially I tried it with regular-old kvm, but them I get the lightdm | 13:10 |
| kyrofa | ogra_, try QXL video model | 13:10 |
| * ogra_ will ty that later after we released 15.04 :) | 13:11 | |
| kyrofa | ogra_, that's exactly what I get if I DON'T use QXL | 13:11 |
| seb128 | kyrofa, k, unsure about the mouse ofset, you should be able to focus the password entry by clicking around no? | 13:11 |
| ogra_ | (currently my bandwith is used for other images) | 13:11 |
| kyrofa | seb128, that's correct, but the edge demo is hopeless haha | 13:11 |
| seb128 | ogra_, when did you try that? those issues are resolved since friday | 13:11 |
| seb128 | kyrofa, oh :-/ | 13:11 |
| kyrofa | seb128, and I don't get a mouse offset with a regular ubuntu image | 13:11 |
| seb128 | it's just one dnd from the left | 13:11 |
| ogra_ | seb128, thursday ;) | 13:12 |
| seb128 | ogra_, k, try again then! | 13:12 |
| ogra_ | yeah | 13:12 |
| ogra_ | takes a century to download that image :P | 13:12 |
| ogra_ | you carry so much bloat | 13:12 |
| seb128 | lol | 13:12 |
| * Chipaca ~> late lunch | 13:13 | |
| seb128 | yeah, what's up with those people installing softwares so you can actually do something with your system | 13:13 |
| seb128 | rather than watching a blinking cursor | 13:13 |
| ogra_ | my phone doesnt need all that ! | 13:13 |
| ogra_ | :P | 13:13 |
| seb128 | no unity8 on your phone, right ;-) | 13:13 |
| kyrofa | seb128, talking to kgunn it sounded like when he was testing it earlier lightdm was on vt7 and unity8 was on vt8. I couldn't verify that-- is that still how it's supposed to be working? | 13:14 |
| seb128 | kyrofa, we activated autologin now so no | 13:14 |
| seb128 | what kgunn described was when you were getting the greeter at boot | 13:14 |
| kyrofa | seb128, when you run the image, do you see a unity8 login or lightdm? | 13:14 |
| kyrofa | seb128, ah, okay | 13:14 |
| seb128 | unity8 | 13:14 |
| kyrofa | seb128, but you didn't have to mess with the video model settings at all? | 13:15 |
| seb128 | you have to use qlx/spice | 13:15 |
| seb128 | otherwise unity8 doesn't work | 13:15 |
| seb128 | and you get a session which fails to start and send you back to the lightdm greete | 13:15 |
| seb128 | greeter | 13:15 |
| kyrofa | seb128, ah, okay so that makes sense. Definitely what ogra_ is running into then | 13:15 |
| kgunn | unless you install VMM | 13:15 |
| kgunn | then it's magic | 13:16 |
| seb128 | right | 13:16 |
| kyrofa | kgunn, haha man, you guys must have a cooler VMM than I do | 13:16 |
| kyrofa | kgunn, although I'm running mine on trusty. Too old? | 13:17 |
| kgunn | oh may be | 13:17 |
| ogra_ | hopefully not | 13:17 |
| kgunn | kyrofa: curious, what's your desktop gpu | 13:17 |
| ogra_ | if it is it should be updated via an SRU | 13:17 |
| kyrofa | kgunn, I have one of those wonky dual-GPU things. Right now I'm running on intel, but I also have an nvidia auadro K1100M | 13:18 |
| kyrofa | kgunn, s/auadro/quadro/ | 13:18 |
| kgunn | mmm | 13:20 |
| kyrofa | kgunn, yeah, if I fire up an VM using the personal.img I made without modifying the config at all, I get lightdm | 13:20 |
| kgunn | oh ok | 13:20 |
| kgunn | kyrofa: but from scrollback, you're seeing mouse offset being an issue as well ? | 13:21 |
| kyrofa | kgunn, if I fire it up and modify the explicitly use QXL, I get unity8 but my mouse is offset enough I can't make it through the demo | 13:21 |
| kyrofa | kgunn, yeah | 13:21 |
| kgunn | yeah, edge demo was really tricky for me, but got thru | 13:21 |
| kgunn | still not tried yet on wily, am going to as soon as i get off this hangout i'm on :) | 13:22 |
| kgunn | HO + vmm at once is bad :) | 13:22 |
| kyrofa | kgunn, haha | 13:22 |
| sergiusens | seb128: mvo I'm going through the code now, but I have a feeling | 13:29 |
| kyrofa | seb128, I switched from VPN to spice in VMM and now I can't seem to click on anything at all | 13:35 |
| kyrofa | seb128, ugh... VNC. Been dealing with the VPN lately | 13:35 |
| kyrofa | I wonder if bregma has played with this at all yet. Get it running on any hardware? | 13:36 |
| mvo | sergiusens: the s-i code? or snappy? sorry, was in a meeting | 13:39 |
| kyrofa | seb128, ah, I got it working! | 13:40 |
| sergiusens | mvo: I think SyncBootloader files is being done after applying the updates | 13:41 |
| mvo | sergiusens: ohhh | 13:42 |
| kyrofa | seb128, this is cool man, awesome job! | 13:42 |
| mvo | sergiusens: that rings a bell, it might be me who broke that :( | 13:42 |
| sergiusens | mvo: essentially stepping over | 13:42 |
| kyrofa | ogra_, kgunn I had to explicitly set QXL and spice in VMM, and make sure there were no tablet devices in the hardware list (I added one messing around with trying to get VNC to work). VNC worked, but gave me a mouse offset. Spice seems to work great | 13:44 |
| mvo | sergiusens: I think you are spot on | 13:47 |
| sergiusens | mvo: I wish I were; but it seems it is not the case | 13:48 |
| kyrofa | seb128, other than that trouble (which was really my own fault), the only thing I ran into was SSH. There's an SSH server, but it has no host keys. Is that a feature? | 13:49 |
| mvo | sergiusens: meh, ok | 13:49 |
| sergiusens | mvo: systemimage.go:180 shows me a sync first and then an applying updates from the server | 13:49 |
| sergiusens | seb128: in your grub you had a hardware.yaml inside a/b, right? | 13:54 |
| kyrofa | sergiusens, what conclusions can I make if `snappy search webdm` gives me nothing? | 14:00 |
| sergiusens | kyrofa: that's it's not available for the released image you are using | 14:01 |
| kyrofa | sergiusens, ah, so when it was uploaded to the store it was specifically targeting ubuntu-core? | 14:01 |
| sergiusens | kyrofa: maybe | 14:01 |
| kyrofa | sergiusens, any chance we could get it targeting ubuntu-personal as well? | 14:02 |
| sergiusens | kyrofa: and this says yes http://search.apps.ubuntu.com/api/v1/package/webdm | 14:02 |
| sergiusens | kyrofa: sure, if in a hurry just download from the anondownload link there | 14:02 |
| kyrofa | sergiusens, ah, good idea. No rush then :) . The snappy scope just needs it until the snappy service has the API. Then webdm can stop targeting ubuntu-personal | 14:03 |
| seb128 | sergiusens, yaml, yes | 14:19 |
| sergiusens | seb128: mvo I found the issue; "HandleAssets" is ignored because it can't find the hardware.yaml in writable/cache/system during the upgrade | 14:21 |
| elopio | good morning. | 14:23 |
| ogra_ | schnaaapiee | 14:24 |
| elopio | http://paste.ubuntu.com/11839856/ | 14:28 |
| elopio | can somebody give me a hand here? This happens on beagle the second time we fake an update ^ | 14:28 |
| elopio | any idea what could cause it? Works alright on kvm. | 14:28 |
| sergiusens | mvo: and I know why the hardware.yaml is not coming through in the update... it doesn't change | 14:30 |
| sergiusens | mvo: ogra_ https://code.launchpad.net/~sergiusens/livecd-rootfs/snappyDevicePart/+merge/264158 if that works, we should get it in for seb128's personal | 14:47 |
| * ogra_ goes to check his wine cave to see what kind of bribes tro accept | 14:48 | |
| sergiusens | lol | 14:48 |
| sergiusens | rsalveti: elopio mvo fgimenez Chipaca btw ^ should be affecting 15.04 and bbb; luckily we now have the same codepath in rolling so it's faster to detect | 14:49 |
| sergiusens | I'll explain during standup | 14:49 |
| * rsalveti looks | 14:49 | |
| seb128 | sergiusens, changes in livecd-rootfs impact the image build, do they also impact the upgrades? | 14:54 |
| rsalveti | cool, will wait you to explain the issue during the standup | 14:54 |
| seb128 | sergiusens, because a fresh image boots fine | 14:54 |
| sergiusens | seb128: yeah, hmm | 14:56 |
| * sergiusens notices he'll have to explain twice | 14:56 | |
| seb128 | sergiusens, don't bother explaining it to me if I just don't get how the snappy details | 14:57 |
| seb128 | as long as you are sure it's going to do the trick ;-) | 14:57 |
| sergiusens | seb128: what happens is snappy ignores the new kernel and initrd if there is no hardware.yaml, the s-i doesn't not provide the hw.yaml because it is always the same, so it is essentially ignored and you do't get the new kernel | 14:57 |
| sergiusens | seb128: adding versioned kernel's and initrd's to the hardware.yaml effectively changes the file and triggers s-i to provide it | 14:58 |
| seb128 | I see | 14:58 |
| sergiusens | that's it in a nutshell | 14:58 |
| seb128 | sergiusens, thanks for the explanation | 14:58 |
| sergiusens | oh, and the important part is that it is ogra_'s fault! | 14:58 |
| sergiusens | :-D | 14:58 |
| ogra_ | yeah, sorry | 14:59 |
| ogra_ | :P | 14:59 |
| seb128 | he better makes up for it by reviewing the fix then! :-) | 15:00 |
| ogra_ | you just want to keep your wine ! | 15:00 |
| ogra_ | the fix looks fine :) | 15:00 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | ppisati, http://paste.ubuntu.com/11839856/ any idea what that means ? | 15:24 |
| ogra_ | seems elopio gets that on upgrades | 15:25 |
| elopio | ogra_, ppisati: more precisely, on the second fake update. We change the channel cfg to have version -1 to test snappy update on the latest image. | 15:26 |
| elopio | the first time we do that, it works. The second time, the board doesn't boot. | 15:26 |
| ogra_ | elopio, right, that shouldnt really matter ... though what i dont get is that it is the second upgrade but it boots from the b partition | 15:27 |
| ogra_ | if it is the second it should boot from a | 15:27 |
| ppisati | same kernel and same dt? weird | 15:27 |
| ogra_ | not sure it is the same | 15:28 |
| ppisati | FDT_ERR_BADLAYOUT | 15:29 |
| ogra_ | yeah | 15:29 |
| ppisati | sounds like a malformed dtb | 15:29 |
| ppisati | if these are not the same, try to switch to the old one | 15:29 |
| ppisati | if they are the same, can you check with md5sum? | 15:30 |
| ppisati | and report the version if they are different | 15:30 |
| ogra_ | elopio, ^^ can you try that ... alos check if there is actually a dtb | 15:30 |
| ogra_ | on the b dir | 15:30 |
| ppisati | it seems there is | 15:30 |
| ppisati | because it's loading it | 15:30 |
| ppisati | reading b/dtbs/am335x-boneblack.dtb | 15:30 |
| ppisati | 30025 bytes read in 9 ms (3.2 MiB/s) | 15:30 |
| ogra_ | oh, right | 15:30 |
| ppisati | i wonder if it's intact and sound | 15:31 |
| * elopio checks some things. | 15:33 | |
| seb128 | hum | 15:35 |
| ogra_ | dont say that ! | 15:36 |
| seb128 | so in snappy list, upgrade, etc the system refers to "ubuntu-core" versions | 15:36 |
| ogra_ | (that usually means something bad) | 15:36 |
| seb128 | even on personal | 15:36 |
| seb128 | lol | 15:36 |
| seb128 | that one is a detail :-) | 15:36 |
| ogra_ | haha | 15:36 |
| seb128 | I wonder if there is a valid wishlist there | 15:36 |
| seb128 | or if we see personal as a temporary thing/don't want to abstract the name | 15:36 |
| ogra_ | definitely worth a bu, though i guess once ubuntu-* are snaps it will fix itself | 15:37 |
| ogra_ | *a bug | 15:37 |
| seb128 | https://launchpad.net/ubuntu/+source/ubuntu-snappy/+bugs | 15:40 |
| seb128 | 3 bugs reported only | 15:40 |
| seb128 | I've a feeling snappy is one of those projects with unsynced buglists :p | 15:40 |
| * ogra_ quietly points to the channel topic :) | 15:40 | |
| seb128 | yeah | 15:41 |
| sergiusens | seb128: create a bug please, that's an easy fix | 15:42 |
| sergiusens | seb128: goes back to the hardcoded days (but I haven't been able to remove all) | 15:42 |
| seb128 | sergiusens, https://bugs.launchpad.net/snappy/+bug/1472676 | 15:42 |
| ubottu | Ubuntu bug 1472676 in Snappy "refers to "ubuntu-core" even for "ubuntu-personal" images" [Undecided,New] | 15:42 |
| sergiusens | seb128: thanks | 15:42 |
| seb128 | yw! | 15:42 |
| sergiusens | ogra_: hmm, mvo seems to be MIA, can you validate this? http://paste.ubuntu.com/11842157/ (I can upload) | 15:43 |
| ogra_ | sergiusens, ACK., go ahead | 15:43 |
| sergiusens | ogra_: thanks | 15:43 |
| seb128 | ogra_, sergiusens, should the same be done to desktop-next? | 15:44 |
| sergiusens | seb128: doing it differently on desktop next, this is just for 15.04 | 15:44 |
| seb128 | k | 15:44 |
| sergiusens | seb128: the other MP, if it works, we will use for desktop-next as well | 15:44 |
| seb128 | great | 15:44 |
| ogra_ | sergiusens, well, but seb128 surely wants https://code.launchpad.net/~sergiusens/livecd-rootfs/snappyDevicePart/+merge/264158 for that | 15:44 |
| sergiusens | ogra_: yup | 15:45 |
| sergiusens | after we know it works | 15:45 |
| === vmayoral|pc is now known as vmayoral | ||
| ogra_ | sergiusens, merged and uploaded | 15:48 |
| sergiusens | yuppie | 15:49 |
| sergiusens | rsalveti: elopio fgimenez ogra_ I'm going to trigger a 15.04 image build in a bit which might solve the hardware.yaml on upgrades issue for bbb | 15:50 |
| ogra_ | yay | 15:50 |
| sergiusens | oh, stuck waiting on arm64 | 15:51 |
| sergiusens | ogra_: do you just cancel the build? | 15:51 |
| ogra_ | yep | 15:51 |
| fgimenez | sergiusens, ack thanks | 15:52 |
| kyrofa | sergiusens, the anon download link for webdm is giving me a 503. Any ideas? | 15:56 |
| elopio | kyrofa: here too. | 15:56 |
| kyrofa | elopio, oh. Maybe it actually IS temporarily unavailable, eh? | 15:57 |
| elopio | kyrofa: maybe. beuno do you know something? | 15:57 |
| beuno | yes | 15:58 |
| beuno | it's down | 15:58 |
| ogra_ | there is a bunch of stuff down atm | 15:58 |
| ogra_ | phones cant install apps either currently | 15:58 |
| sergiusens | kyrofa: store is down | 15:58 |
| rsalveti | lovely | 15:58 |
| rsalveti | right time for lunch | 15:58 |
| ogra_ | heh | 15:58 |
| kyrofa | sergiusens, beuno thanks guys. Is there a status page I can keep an eye on? | 15:59 |
| beuno | kyrofa, not at the moment, no | 16:00 |
| beuno | sorry | 16:00 |
| kyrofa | beuno, that's alright. Any estimate? | 16:00 |
| beuno | kyrofa, minutes, 5-30 | 16:01 |
| kyrofa | beuno, great, thank you :) | 16:01 |
| seb128 | ogra_, thanks for the merge/upload | 16:01 |
| ogra_ | np | 16:01 |
| ogra_ | i'll trigger a core build too so it can be tested | 16:01 |
| kgunn | seb128: i updated to wily, just tried personal image....works like a champ! \o/ | 16:09 |
| seb128 | kgunn, excellent! | 16:09 |
| kgunn | bregma: willcooke ^ | 16:11 |
| bschaefer | ogra_, hello, so i've my raspi2 image set up with snappy, but it seems to be missing the /dev/dri/card*? This will seem to be problematic for running a mir server | 16:13 |
| bschaefer | i was told possibly something is missing from the kernel in that image? | 16:14 |
| ogra_ | bschaefer, well, that will need a lot more extra work to make the binary blob work to actually drive the graphics HW | 16:14 |
| bschaefer | ogra_, shoots | 16:14 |
| bschaefer | bregma, kgunn ^ | 16:14 |
| bschaefer | ogra_, is this the same with the BBB? (besides not being able to flash the eMMC) | 16:15 |
| ogra_ | the upcoming 15.04 image will have some raw support to hack overlay dtb's and graphical options into the kernel commandline | 16:15 |
| ogra_ | the BBB isnt suitable for graphical stuff | 16:15 |
| bschaefer | i see, thats what i heard but wasnt sure :) | 16:15 |
| bschaefer | ogra_, do you know when that image would be released? | 16:16 |
| ogra_ | dont bother with it ... it is fine for a single app for mmanaging some relais on an attached touchscreen or some such | 16:16 |
| bregma | ogra_, what's the expecxted delivery date for the PI image? | 16:16 |
| ogra_ | but you wont be running a desktop on a BBB | 16:16 |
| bschaefer | ogra_, right, yeah just trying to figure out whats possible and not | 16:16 |
| ogra_ | bregma, for the 15.04 uupdate ? this week i think | 16:16 |
| bschaefer | ogra_, awesome thank you! | 16:16 |
| bregma | ogra_, and we'll be able to run Mir on the PI then? | 16:17 |
| ogra_ | i'll also start providing buuilds of the edge channel with that hw tarball and oem snap | 16:17 |
| ogra_ | bregma, well, it is 15.04 | 16:17 |
| ogra_ | not sure how much you can do on that base ... i would assume you want to wait for the edge image (on my plan for next week) | 16:17 |
| kgunn | 15.04 prollly ok to start with | 16:18 |
| ogra_ | ah, fine then | 16:18 |
| kgunn | ogra_: why is BBB not good for gfx ? | 16:18 |
| * kgunn has no history | 16:18 | |
| bregma | no binary blob graphic driver support for gles, I assume | 16:18 |
| ogra_ | kgunn, single core-industirl-embedded CPU ... while it has a GPU it is really not a powerful one | 16:19 |
| kgunn | ogra_: it has like a sgx530 or some such i thot | 16:19 |
| ogra_ | i think there is an SGX driver for it but that likely needs a specific (and likely very old) kernel and patches | 16:19 |
| kgunn | which is enough for kiosk type thingy | 16:19 |
| ogra_ | right | 16:20 |
| bregma | Mir support for software rendering should fix that, as I understand it | 16:20 |
| ogra_ | thats what i meant above | 16:20 |
| bschaefer | it would still need to support running the server | 16:20 |
| ogra_ | enough to run a UI for your heating controller as single purpose UI | 16:20 |
| bschaefer | which from what i understand you need at lease the /dev/dri/card0* | 16:20 |
| beuno | downloads should be back | 16:20 |
| bregma | that is definitely what we're aiming for here | 16:20 |
| kgunn | ogra_: ok, so it's possible, "we" 're just not investing in it (bbb gfx) | 16:20 |
| ogra_ | bschaefer, i thought dri is dead ? and it is all kms nowadays | 16:21 |
| ogra_ | kgunn, it isnt suitable for desktop ... if you want to build a kiosk thingie, go ahead :) | 16:21 |
| kgunn | k | 16:21 |
| bschaefer | ogra_, err i suppose i could be looking for that as well... that was just waht i got when i was talking to #mir yesterday :) | 16:21 |
| bregma | all we really need for kiosk should be good 2D acceleration | 16:21 |
| * bschaefer hopes it works outside of that | 16:21 | |
| ogra_ | (though the price you pay for BBB plus LCD cape will likely be more expensive than a cheap tablet) | 16:22 |
| kgunn | hehe | 16:22 |
| bschaefer | ogra_, pfft it has a mini HDMI | 16:22 |
| ogra_ | heh | 16:22 |
| bschaefer | but yeah still more expensive | 16:22 |
| bschaefer | (if you get a small screen) | 16:22 |
| kgunn | ok, gonna run/lunch bbiab | 16:23 |
| bregma | a BBB, and old cast-off monitor, a carboard box and some duct tape is all I need to build my info-kiosk for my front door | 16:23 |
| bschaefer | haha | 16:23 |
| ogra_ | thnen you just need to learn to use directfb | 16:23 |
| ogra_ | that should work already :) | 16:23 |
| ogra_ | without any drivers | 16:24 |
| bregma | I don't think that's yet available in Mir | 16:24 |
| ogra_ | no, that is something lower than Mir | 16:24 |
| ogra_ | talking directly to /dev/fb0 via a lib | 16:25 |
| ogra_ | (unaccelerated 2D) | 16:25 |
| elopio | kyrofa: udf works for me now, maybe your server is up too. | 16:33 |
| kyrofa | elopio, yeah, all good here. Thanks beuno! | 16:36 |
| kyrofa | sergiusens, do you know anything about the snappy examples? | 16:42 |
| kyrofa | sergiusens, lp:~snappy-dev/snappy-hub/snappy-examples | 16:42 |
| kyrofa | sergiusens, the hello-dbus example puts the service into a framework and the client into an app. Is there a good reason to do that instead of including both in the same snap? | 16:47 |
| kyrofa | Looks like jdstrand initially wrote it. jdstrand ^^ any input? | 16:48 |
| sergiusens | kyrofa: because the app depends on the framework, it's the only dependency chain allowed | 17:09 |
| sergiusens | kyrofa: and it's just an example, so maybe useless for a real case | 17:10 |
| kyrofa | sergiusens, but couldn't a single snap include both the dbus service and the client? | 17:11 |
| sergiusens | kyrofa: yes they can | 17:14 |
| sergiusens | kyrofa: I had that in one of my apps from before the release | 17:14 |
| sergiusens | elopio: rsalveti do you have a revno for 15.04 on edge handy with an older kernel? | 17:15 |
| rsalveti | sergiusens: hm, not handy | 17:15 |
| rsalveti | sergiusens: we landed a new kernel on monday | 17:15 |
| kyrofa | sergiusens, is there a reason to do one over the other? I understand that this is just an example, I'm just curious. Obviously a framework can be relied upon by multiple snaps, and it decouples the service and the client. Would that really be the only reason to do it that way? | 17:15 |
| rsalveti | since then, I believe we did 2,3 new builds | 17:15 |
| elopio | sergiusens: no sir. Just old 15.04 stable here. | 17:16 |
| sergiusens | rsalveti: k, will check some dates in the index; I wish this process weren't so manual :-) | 17:16 |
| sergiusens | kyrofa: different vendors providing extensions | 17:16 |
| sergiusens | kyrofa: just like docker | 17:16 |
| sergiusens | kyrofa: docker framework and runtimes/dockerapps in apps | 17:17 |
| sergiusens | kyrofa: I don't know how to make it clearer :-) | 17:17 |
| kyrofa | sergiusens, alright, makes sense. Thanks :) | 17:17 |
| rsalveti | sergiusens: well, you own the tool that interacts with that server :P | 17:18 |
| sergiusens | rsalveti: but not the one that does the s-i->cdimage part | 17:19 |
| kyrofa | beuno, how do manual snap upload reviews occur? How long does it typically take? | 17:19 |
| sergiusens | rsalveti: do you see a problem with this? http://paste.ubuntu.com/11842157/ | 17:19 |
| rsalveti | sergiusens: looks fine | 17:20 |
| sergiusens | rsalveti: I get 'hashes: -\n' after building | 17:20 |
| beuno | kyrofa, as a rule, if something is manual it will likely get rejected | 17:21 |
| sergiusens | rsalveti: oh, ic the problem :-/ | 17:21 |
| sergiusens | I think | 17:21 |
| rsalveti | sergiusens: either the var is not protected or we got nothing with md5sum | 17:21 |
| sergiusens | rsalveti: yeah, I don't see the problem, damn shell scripts | 17:22 |
| ogra_ | whats the issue | 17:22 |
| kyrofa | beuno, hmm. I'm referring to the last paragraph on this page: https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ | 17:22 |
| sergiusens | lol | 17:22 |
| kyrofa | beuno, it implies that all snap reviews are manual? | 17:22 |
| * sergiusens thinks ogra_ has a highlight for shell script blasfemy | 17:23 | |
| rsalveti | lol | 17:23 |
| ogra_ | shhh | 17:23 |
| sergiusens | ogra_: I get 'hashes: -\n' after building | 17:23 |
| sergiusens | ogra_: with http://paste.ubuntu.com/11842157/ | 17:23 |
| beuno | kyrofa, they are not. They are automatic and get approved within seconds (if they pass automatic review scripts_ | 17:24 |
| beuno | kyrofa, that's outdated, I guess | 17:24 |
| ogra_ | sergiusens, hmm, i think thats a bashism | 17:24 |
| beuno | asac, who maintains this? https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ | 17:24 |
| ogra_ | cut -f1 -d' ' | 17:25 |
| ogra_ | instead of cut -f1 -d\ | 17:25 |
| kyrofa | beuno, ah! Okay good deal | 17:25 |
| sergiusens | ogra_: ok | 17:25 |
| sergiusens | ogra_: is that the only thing? I want to avoid another 30 cycle :P | 17:26 |
| rsalveti | beuno: our team I guess, why? | 17:26 |
| ogra_ | sergiusens, not sure, do you have any log ? | 17:26 |
| beuno | rsalveti, it says all submissions are manual | 17:27 |
| rsalveti | sergiusens: guess you can easily test that logic locally first | 17:27 |
| beuno | they are not | 17:27 |
| ogra_ | quotes wouldnt be abd either i guess | 17:27 |
| ogra_ | *bad | 17:27 |
| sergiusens | rsalveti: I have | 17:27 |
| rsalveti | beuno: yeah, we can update that | 17:27 |
| beuno | rsalveti, thanks | 17:28 |
| ogra_ | sergiusens, in any case make sure to have a "set -ex" at the top of the script, then we get more detailed logs ... log space is cheap | 17:28 |
| sergiusens | rsalveti: ogra_ ... md5sum: /tmp/tmp.csXhKqYL59/assets/vmlinuz: No such file or directory | 17:28 |
| sergiusens | there we go | 17:28 |
| ogra_ | aha | 17:28 |
| jdstrand | kyrofa: I did it as an example of writing a framework that another snap would depend on. it is fine for a framework to ship other services or binaries | 17:30 |
| kyrofa | jdstrand, thank you | 17:31 |
| kyrofa | jdstrand, hey, thanks for the email about the QHD stuff too. Nice to have crisp notifications again, haha | 17:32 |
| jdstrand | kyrofa: I know, right? that was annoying | 17:33 |
| jdstrand | glad it helped :) | 17:33 |
| ogra_ | sergiusens, hmm, where do you see that ? the build log properly has http://paste.ubuntu.com/11842705/ | 17:33 |
| sergiusens | ogra_: it's set | 17:33 |
| ogra_ | yeah, just noticed | 17:33 |
| sergiusens | ogra_: https://launchpadlibrarian.net/211113785/buildlog_ubuntu_vivid_amd64_ubuntu-core-system-image_BUILDING.txt.gz | 17:33 |
| kyrofa | jdstrand, it's just such a beautiful, crisp screen... and then... yeah | 17:33 |
| ogra_ | cat'ing hardware..yaml at the end would be helpful | 17:33 |
| ogra_ | sergiusens, LOL | 17:34 |
| ogra_ | sergiusens, vmlinux != vmlinuz ;) | 17:34 |
| ogra_ | (your patch has a typo) | 17:34 |
| sergiusens | ogra_: yeah, fixed | 17:35 |
| sergiusens | ogra_: still won't fix the issue ;-) | 17:35 |
| ogra_ | yeah | 17:35 |
| * ogra_ looks at the full code ... | 17:35 | |
| ogra_ | who wrote that code originally ? | 17:38 |
| ogra_ | (why are there all these brackets ?) | 17:38 |
| sergiusens | ogra_: mvo did | 17:38 |
| Saviq | jdstrand, I know you'll hate me, but I'll need an ACK for emonhub.saviq please, same old same old (but I renamed the app...) | 17:38 |
| sergiusens | ogra_: interesting, hashes thing seems to be fine for armhf builds | 17:38 |
| sergiusens | ogra_: I just need to fix that type; on 15.04, hardware.yaml is only used by the bbb | 17:40 |
| ogra_ | well, i think the brackets cause all that stuff between them to be executed in a subshell (which seems a bit ppointless but doesnt explain why you end up with empty vars in the here doc) | 17:40 |
| sergiusens | ogra_: the parens you mean? | 17:41 |
| ogra_ | yeah | 17:41 |
| sergiusens | unspecific germans, sigh :-P | 17:41 |
| ogra_ | i dont really get why mvo used them | 17:41 |
| jdstrand | Saviq: no worries. I think pindonga said the store would be updated today | 17:42 |
| sergiusens | ogra_: http://paste.ubuntu.com/11842767/ | 17:45 |
| jdstrand | Saviq: it isn't downloading right | 17:46 |
| sergiusens | ogra_: I think I prefer that | 17:46 |
| jdstrand | Saviq: I get just an empty file | 17:46 |
| ogra_ | sergiusens, yeah ... and add quotes around the $() | 17:46 |
| sergiusens | ogra_: ok | 17:46 |
| jdstrand | beuno: looking at https://myapps.developer.ubuntu.com/dev/click-apps/3029/review/, if I try to download I only get an empty file | 17:46 |
| beuno | jdstrand, yes, slight issue atm | 17:47 |
| jdstrand | beuno: is there an issue with the store? | 17:47 |
| beuno | will ping back | 17:47 |
| jdstrand | ah, ok | 17:47 |
| jdstrand | Saviq: ^ | 17:47 |
| sergiusens | ogra_: http://paste.ubuntu.com/11842781/ | 17:47 |
| beuno | for a handful of packages | 17:47 |
| * sergiusens dputs | 17:47 | |
| ogra_ | sergiusens, thats schnappy :) | 17:47 |
| sergiusens | \o/ | 17:48 |
| sergiusens | ogra_: I might need one more fix to make this bullet proof | 17:49 |
| ogra_ | sergiusens, well, and a "cat $TMPDIR/hardware.yaml" at the end of the script to get it into the log might not do harm either | 17:50 |
| ogra_ | saves you from having to install an image to find out the file is brooken | 17:50 |
| ogra_ | -o | 17:50 |
| ogra_ | (or download or whatever) | 17:50 |
| jdstrand | sergiusens: there are ubuntu personal images now? | 17:54 |
| jdstrand | sergiusens: cause we need to figure out how to deal with security policy in snappy build | 17:55 |
| kyrofa | jdstrand, yeah, seb128 has been working on them | 17:55 |
| elopio | sergiusens: did you find the rev# of the old kernel? | 17:55 |
| jdstrand | sergiusens: since my plan was to use existing phone policy for ubuntu-personal | 17:55 |
| sergiusens | jdstrand: yes there are | 17:56 |
| jdstrand | sergiusens: so that means snappy build needs to know about core vs personal and pick the right policy vendor | 17:56 |
| sergiusens | jdstrand: and seb128 is creating/seeding all the bits | 17:56 |
| sergiusens | jdstrand: yes, I've proposed adding a --release to Chipaca and mvo | 17:56 |
| jdstrand | (not to mention we need to work out what to do for policy version instead of just hardcoding 15.04 | 17:56 |
| jdstrand | ) | 17:57 |
| jdstrand | ok, cool | 17:57 |
| utlemming | sergiusens: er, looks like build 119 broke cloud images | 17:57 |
| utlemming | sergiusens: sgdisk is needed in for cloud-init to resize the disk | 17:57 |
| sergiusens | utlemming: is that rolling or 15.04? | 17:57 |
| utlemming | sergiusens: 15.04 | 17:58 |
| ogra_ | utlemming, where does that dep come from all of a sudden ? | 18:01 |
| ogra_ | (also did you consider making it a dependency of the cloud-init package then ? ) | 18:01 |
| utlemming | ogra_: that is likely my fault of not catching it in cloud-init logs -- my apologies | 18:03 |
| utlemming | ogra_: checking on the dep piece | 18:03 |
| ogra_ | utlemming, well, i dont get why it worked before in 15.04 and in 119 it doesnt | 18:03 |
| utlemming | orga_: yeah, lets hold on that for a minute...let me dig deeper before calling it the cause | 18:04 |
| ogra_ | doesnt look like we ever had gdisk installed | 18:04 |
| beuno | jdstrand, fixed | 18:04 |
| jdstrand | thanks! | 18:04 |
| sergiusens | ogra_: http://paste.ubuntu.com/11842889/ | 18:07 |
| ogra_ | sergiusens, looks good ... go ahead | 18:08 |
| sergiusens | ogra_: rsalveti seems to be one problem still and I'm not sure how to solve; but if we pull a new initrd and no new kernel, then s-i would remove the kernel from the delta and the upgrade would fail | 18:08 |
| ogra_ | hmm | 18:09 |
| kyrofa | sergiusens, looking at the snappy examples in contract to the snappy document, can I safely assume that .svg icons are no longer required even though the docs say so? | 18:10 |
| sergiusens | ogra_: it's almost as if s-i should generate the hardware.yaml | 18:10 |
| sergiusens | kyrofa: I don't attest to that; I'll leave that to beuno | 18:11 |
| sergiusens | kyrofa: we are mostly killing package.yaml in the future btw... | 18:11 |
| utlemming | ogra_: red-herring | 18:11 |
| kyrofa | sergiusens, ah, good to know. Is there other docs I should be referring to to build snaps, then? | 18:12 |
| sergiusens | kyrofa: well, if you are targetting rolling, the docs on developer.u.c are not what you want | 18:12 |
| sergiusens | lp:snappy /docs | 18:12 |
| sergiusens | but I don't think there is anything in place yet | 18:13 |
| kyrofa | sergiusens, I am indeed. Thank you! | 18:13 |
| sergiusens | kyrofa: rolling has no docs yet and anything is subject to change ;-) | 18:14 |
| rsalveti | sergiusens: why would the upgrade fail? | 18:15 |
| kyrofa | sergiusens, that's alright, I can roll with it | 18:15 |
| utlemming | ogra_: the reason I wasn't seeing the error before was that with /etc/cloud/cloud.cfg.d being a writable path, the regular configurations where not being read when I built an image with that content populated. | 18:17 |
| utlemming | i.e I put stuff in /writable/system-data/etc/cloud/cloud.cfg.d | 18:18 |
| ogra_ | ah | 18:18 |
| sergiusens | rsalveti: because now the opposite happens, during the livecdrootfs phase we don't know what will be added or removed, so we add a kernel and initrd entry | 18:18 |
| ogra_ | yeah, understood | 18:18 |
| sergiusens | rsalveti: but s-i might determine that initrd doesn't need to be in th delta | 18:18 |
| sergiusens | rsalveti: so the entry would point to an invalid file | 18:18 |
| sergiusens | rsalveti: as I was telling ogra, it feels like livecdrootfs is the wrong place to generate this file and it should be done during s-i | 18:19 |
| rsalveti | right, indeed | 18:19 |
| rsalveti | sergiusens: so what can we do for now? | 18:20 |
| sergiusens | rsalveti: update both | 18:20 |
| sergiusens | rsalveti: or none | 18:20 |
| sergiusens | rsalveti: this problem exists in rolling as well | 18:21 |
| rsalveti | guess just update both | 18:21 |
| rsalveti | right, maybe not something we need to fix for this stable release | 18:21 |
| ogra_ | well, how do you update both if one didnt change ? | 18:21 |
| rsalveti | since your fix should already be enough for the current issue | 18:21 |
| ogra_ | in snappy ? | 18:21 |
| sergiusens | ogra_: generated images should update both init and kernel or the updates would fail | 18:22 |
| ogra_ | sergiusens, right, but how do you enforce that ? | 18:22 |
| ogra_ | if one of them is missing thanks to s-i | 18:22 |
| sergiusens | ogra_: we control the stable channels, so it is easier | 18:23 |
| sergiusens | ogra_: in the end, if we want to survive, we would need to have s-i generate the hardware.yaml | 18:23 |
| ogra_ | yes | 18:24 |
| rsalveti | sergiusens: yeah, stable is fine for now I'd say, but definetly something we need to fix in s-i | 18:37 |
| rsalveti | sergiusens: just create a card for it and put it in the backlog | 18:37 |
| sergiusens | rsalveti: card created, I need to leave for a bit | 18:43 |
| rsalveti | sergiusens: sure | 18:43 |
| rsalveti | sergiusens: did you trigger a new image with your recent change? | 18:43 |
| ogra_ | yes, he did | 18:44 |
| * ogra_ cancels the arm64 build | 18:44 | |
| rsalveti | cool | 18:45 |
| Letozaf_ | hey guys, once you installed packages like snake, and chatroom, for instance, If I do not know them and how they work, how can I find out? Is there some documentation somewhere, if I have to check if they work after install I have to know how they work. | 18:55 |
| ogra_ | Letozaf_, webdm is supposed to show descriptions and also have a link that opens their externally defined port | 18:56 |
| ogra_ | the description stuff is still broken i think | 18:56 |
| Letozaf_ | ogra_, I will try again, but yesterday the link did not open anything, just a blank browser page | 18:57 |
| ogra_ | for which app ? | 18:57 |
| Letozaf_ | ogra_, yesterday I install snake and chatroom, just these two, but could not try them out | 18:58 |
| ogra_ | hmm, works fine here ... i click on "raspberyy pi2" in webdm ... then on chatroom ... and there on open/manage | 18:58 |
| ogra_ | that opens the chatroom page for me | 18:59 |
| Letozaf_ | ogra_, I will try again just now, give me two minutes | 18:59 |
| ogra_ | sure | 18:59 |
| ogra_ | (note that chatroom only works in chromium ... (which the description would tell you if it would be shown :P )) | 19:00 |
| ogra_ | sergiusens, rsalveti, hmm, that didnt work it seems | 19:03 |
| ogra_ | https://launchpadlibrarian.net/211130437/buildlog_ubuntu_vivid_amd64_ubuntu-core-system-image_BUILDING.txt.gz | 19:03 |
| ogra_ | oh | 19:03 |
| ogra_ | ignore that :P | 19:03 |
| ogra_ | wrong arch :P | 19:04 |
| ogra_ | hmm, doesnt look like the "cat hardware.yaml" is executed | 19:05 |
| Letozaf_ | ogra_, I am running yesterday's snappy 15.04 amd64 image (ubuntu-core vers. 117) I installed chatroom and in Chromium when I click on "open/manage" I get "The webpage is not available" message | 19:05 |
| ogra_ | weird | 19:06 |
| rsalveti | ogra_: cat should only show up on armhf, right? | 19:06 |
| Letozaf_ | ogra_, I am runnin wily on my Desktop PC | 19:06 |
| ogra_ | Letozaf_, http://webdm.local:6565 | 19:06 |
| ogra_ | try that | 19:06 |
| ogra_ | rsalveti, right, but it doesnt | 19:06 |
| Letozaf_ | ogra_, same: This webpage is not available | 19:07 |
| ogra_ | i can see the hashes being assigned to the vars though | 19:07 |
| ogra_ | but that worked before already | 19:07 |
| ogra_ | Letozaf_, weird, works fine on armhf ... i havent tried on amd64 in a while i must admit | 19:07 |
| rsalveti | ogra_: indeed | 19:08 |
| rsalveti | ogra_: guess we can open the device tarball and see | 19:08 |
| Letozaf_ | ogra_, I have Wily installed and I am also using systemd | 19:08 |
| ogra_ | yeah :/ ... thats what the cat was supposed to avoid | 19:08 |
| ogra_ | but cats never do what you want :P | 19:08 |
| Letozaf_ | am I the cat ? LOL | 19:09 |
| ogra_ | lol | 19:09 |
| ogra_ | meow | 19:09 |
| ogra_ | no :) | 19:09 |
| ogra_ | Letozaf_, a "cat" command that is supposed to put stuff in a logfile ;) | 19:10 |
| Letozaf_ | ogra_, Hah! the cat command I thouth you were talking about a cat animal lol | 19:11 |
| Letozaf_ | lolololo | 19:11 |
| Letozaf_ | rotfl | 19:11 |
| ogra_ | :D | 19:11 |
| elopio | ppisati: ogra_: http://paste.ubuntu.com/11843280/ | 19:11 |
| elopio | was that what you wanted me to compare? How to know if it's correct? | 19:11 |
| ogra_ | elopio, well, does it boot from a ? | 19:11 |
| elopio | and ogra_, it tries to boot first a, then it tries b. And keeps retrying be. | 19:11 |
| ogra_ | if ti is in that state | 19:11 |
| ogra_ | ah | 19:12 |
| ogra_ | and both print that dtb error ? | 19:12 |
| elopio | what I pasted before was not the first try. | 19:12 |
| ogra_ | well, i'd like to see the error from an a boot | 19:12 |
| ogra_ | before it panics and reboots | 19:13 |
| elopio | let me see if I pasted that one somewhere. | 19:13 |
| elopio | nop. I hate that I can't scroll back on screen. | 19:14 |
| elopio | I will reproduce it one more time. | 19:14 |
| ogra_ | partition-layout: system-AB | 19:17 |
| ogra_ | hashes: 462b31071b9f41c50ef05670ca764780-9b0c722b5d417f5152a4f5a5d5084910 | 19:17 |
| ogra_ | dtbs: assets/dtbs | 19:17 |
| ogra_ | rsalveti, sergiusens ^^ looks fine | 19:17 |
| rsalveti | ogra_: yeah, now to test the upgrade and see :-) | 19:18 |
| ogra_ | argh | 19:18 |
| ogra_ | but we have everything duplicated in assets | 19:18 |
| ogra_ | that makes it 52MB big now | 19:18 |
| rsalveti | what | 19:20 |
| ogra_ | initrd.img and initrd.img-3.19.0-22-generic ... | 19:21 |
| ogra_ | same for the kernel | 19:21 |
| Letozaf_ | ogra_, it works, it was a port redirect error :-P | 19:21 |
| ogra_ | ha ! | 19:21 |
| ogra_ | Letozaf_, awesome :) | 19:22 |
| Letozaf_ | ogra_, sorry for the hassle :) | 19:22 |
| ogra_ | np | 19:22 |
| ogra_ | i do that all the time when using kvm :) | 19:22 |
| Letozaf_ | :-) | 19:22 |
| ogra_ | rsalveti, wow, an we ship each and every available dtb by default | 19:22 |
| ogra_ | 8MB of dtb files | 19:22 |
| rsalveti | ogra_: right, at the kernel snap that is expected | 19:23 |
| ogra_ | once that exists, yeah | 19:23 |
| rsalveti | well, it's the evolution from the device tarball :-) | 19:24 |
| ogra_ | evolution ... like growing a third arm to pick your nose and such :P | 19:25 |
| * ogra_ likes that the device tarball is small and on the point ... | 19:26 | |
| ogra_ | but for generic thats probably fine ... | 19:26 |
| rsalveti | right | 19:28 |
| ogra_ | though wasting 25MB for the kernel and initrd duplication doesnt feel right | 19:30 |
| ogra_ | i wonder if we can safely drop the unversioned ones | 19:31 |
| ogra_ | hmm, no .. hardware.yaml uses them by default | 19:32 |
| Saviq | the 'services' and 'no-cloud' config options from https://developer.ubuntu.com/en/snappy/guides/oem/ are a wish for now, right? | 19:37 |
| elopio | ogra_: http://paste.ubuntu.com/11843609/ | 20:00 |
| elopio | that's the first error booting a after the second update. Same badlayout. | 20:01 |
| ogra_ | elopio, so the dtb file is corrupt in general | 20:01 |
| elopio | I wonder if two real updates in a row end up in this too | 20:01 |
| elopio | I'll have to wait for tomorrow to check that. | 20:01 |
| rsalveti | can't we specify the version we want to update? | 20:03 |
| rsalveti | if this indeed causes an issue, we might just break everyone that is using bbb :-) | 20:03 |
| elopio | rsalveti: not without faking things. | 20:04 |
| elopio | fgimenez did a script to update to rev -1 | 20:04 |
| rsalveti | right | 20:04 |
| elopio | Full adventure logs: | 20:05 |
| elopio | http://paste.ubuntu.com/11843622/ | 20:05 |
| elopio | http://paste.ubuntu.com/11843624/ | 20:05 |
| elopio | I don't know how remounting / could cause this. I'll flash 94, update to 95, and wait for 96 to be available. | 20:06 |
| rsalveti | we can trigger a new wily one if you want | 20:06 |
| rsalveti | let me do that while you flash 94 | 20:07 |
| elopio | rsalveti: wait for me to finish the update to 95 | 20:07 |
| rsalveti | elopio: sure, on your command :-) | 20:07 |
| elopio | it will take like ~30 minutes here to do the whole dance. | 20:07 |
| rsalveti | right, probably the same time it takes to get the new image out | 20:07 |
| elopio | rsalveti: I'm in #95. go, please. | 20:25 |
| rsalveti | elopio: done | 20:26 |
| elopio | oh shit. The reboot ended up in emergency mode. | 20:27 |
| rsalveti | man, we got some serious issues with bbb | 20:27 |
| elopio | I bet when I decided to work in QA, all the bad karma came in my aid. | 20:27 |
| ogra_ | rsalveti, serious and weird | 20:28 |
| elopio | fwiw, federico could reproduce the second update issue. | 20:29 |
| elopio | and I haven't had an emergency mode for two weeks now. | 20:29 |
| ogra_ | rsalveti, btw, do we have any complelling reason to use vfat and not ext2 ? we always seem to have issues with files on the fat | 20:31 |
| rsalveti | not sure, would need to ask lool I guess | 20:31 |
| rsalveti | probably because vfat is usually supported everywhere | 20:31 |
| rsalveti | even with super old uboot | 20:31 |
| ogra_ | yeah | 20:32 |
| ogra_ | but we insist on the very latest uboot :) | 20:32 |
| rsalveti | right, which is why would be good to check with lool | 20:32 |
| ogra_ | and we use very new features too | 20:33 |
| ogra_ | bah, crap | 20:42 |
| ogra_ | wily needs the same change in livecd-rootfs | 20:43 |
| Saviq | is there a place recommended to file bugs about docs? | 20:43 |
| ogra_ | + cp -ar boot/initrd.img-* /tmp/tmp.MYidIUKLNU/assets/ | 20:44 |
| ogra_ | cp: cannot stat 'boot/initrd.img-*': No such file or directory | 20:44 |
| ogra_ | E: config/hooks/500-move-kernel-to-device-tar.binary failed (exit non-zero). You should check for errors. | 20:44 |
| ogra_ | P: Begin unmounting filesystems... | 20:44 |
| ogra_ | grrrr | 20:44 |
| elopio | Saviq: about docs in developer.ubuntu.com? | 20:46 |
| Saviq | elopio, yeah | 20:46 |
| elopio | Saviq: https://bugs.launchpad.net/developer-ubuntu-com/ | 20:47 |
| Saviq | elopio, thanks | 20:47 |
| elopio | Saviq: please link the bug here. | 20:47 |
| kyrofa | jdstrand, so if I write a dbus service, I'm getting the impression that it _must_ be a framework. Yes? | 20:47 |
| jdstrand | yes | 20:48 |
| jdstrand | bus-name is only available to frameworks | 20:48 |
| kyrofa | jdstrand, right, okay. Does that immediately mean that I need custom apparmor profiles? All the service does is obviously listen on dbus and act as a network client | 20:49 |
| elopio | ugh, this is no good. Tried again and I'm in emergency mode. It's good I ordered more sd cards. | 20:50 |
| elopio | can somebody try a bbb update from rolling edge #94? | 20:50 |
| Saviq | bug #1472778 | 20:50 |
| nothal | Bug #1472778: "start exploring snappy..." link feels broken <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472778> | 20:50 |
| ubottu | bug 1472778 in Ubuntu Developer Portal ""start exploring snappy..." link feels broken" [Undecided,New] https://launchpad.net/bugs/1472778 | 20:50 |
| jdstrand | kyrofa: that isn't enough-- you need to have dbus bus policy to start a dbus service. I'm confused though-- why does an app need to be a dbus service? | 20:50 |
| elopio | Saviq: :) would you think it's better to link directly to the snappy tour instead? | 20:52 |
| Saviq | bug #1472780 | 20:52 |
| nothal | Bug #1472780: No documentation about "assign" in oem guide <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472780> | 20:52 |
| ubottu | bug 1472780 in Ubuntu Developer Portal "No documentation about "assign" in oem guide" [Undecided,New] https://launchpad.net/bugs/1472780 | 20:52 |
| Saviq | elopio, TBH I'd just drop the link | 20:52 |
| Saviq | elopio, you're looking at "Next steps" by the time you're clicking it already | 20:52 |
| ogra_ | sergiusens, fixed a quoting issue with the wily livecd-rootfs MP, uploaded | 20:53 |
| elopio | Saviq: done. | 20:53 |
| rsalveti | ogra_: thanks for uploading the fix | 20:53 |
| kyrofa | jdstrand, it's the scope to install snaps for ubuntu personal. Scopes can't maintain state, thus the stateful bits are pulled into a dbus daemon | 20:54 |
| kyrofa | jdstrand, so there are two parts-- the dbus daemon and the scope itself | 20:55 |
| Saviq | bug #1472782 | 20:56 |
| nothal | Bug #1472782: webcam guide's assign/part-id does not work <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472782> | 20:56 |
| ubottu | bug 1472782 in Ubuntu Developer Portal "webcam guide's assign/part-id does not work" [Undecided,New] https://launchpad.net/bugs/1472782 | 20:56 |
| Saviq | elopio, ↑ that might be really a snappy bug, but it's unclear without real docs about assign | 20:56 |
| ogra_ | rsalveti, so i guess it will still take a while til there is something to copy to the alpha channel | 20:56 |
| rsalveti | ogra_: yeah, not today | 20:56 |
| ogra_ | cool | 20:57 |
| rsalveti | it's all fine and good until we start finding blockers all around | 20:57 |
| ogra_ | (or not) | 20:57 |
| elopio | Saviq: thanks for the bugs. I'm not sure, so I'll left them for somebody to triage. | 20:59 |
| Saviq | bug #1472783 | 20:59 |
| nothal | Bug #1472783: oem guide mentions unsupported config parameters <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472783> | 20:59 |
| ubottu | bug 1472783 in Ubuntu Developer Portal "oem guide mentions unsupported config parameters" [Undecided,New] https://launchpad.net/bugs/1472783 | 20:59 |
| Saviq | elopio, there's some indentation issues on https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ | 20:59 |
| elopio | we are trying to fix the doc bugs before the next release. | 20:59 |
| Saviq | elopio, in the yaml listings | 21:00 |
| Saviq | bug #1472784 | 21:01 |
| nothal | Bug #1472784: oem guide does not explain immutable config properly <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472784> | 21:01 |
| ubottu | bug 1472784 in Ubuntu Developer Portal "oem guide does not explain immutable config properly" [Undecided,New] https://launchpad.net/bugs/1472784 | 21:01 |
| jdstrand | kyrofa: why wouldn't this be shipped as part of the ubuntu personal image like it is on touch? | 21:05 |
| kyrofa | jdstrand, it can be. We figured it would be easier to update if it was a snap | 21:06 |
| kyrofa | jdstrand, do you disagree? | 21:07 |
| jdstrand | kyrofa: you can't right now. today, you must be framework to be able to be a dbus service | 21:07 |
| jdstrand | kyrofa: note you can't do this as a click either | 21:08 |
| jdstrand | kyrofa: because you need to adjust dbus bus policy (ie, not apparmor) in order to be a service | 21:08 |
| jdstrand | there is no current mechanism to do that (unless you are a framework snap) | 21:08 |
| kyrofa | jdstrand, is it a big deal for it to be a framework snap? | 21:09 |
| jdstrand | kyrofa: I suggest for now keeping it in ubuntu personal image and bringing this up with the architects group | 21:09 |
| jdstrand | kyrofa: it isn't a framework though, is it? you just are picking it as type framework because that happens to get you something you need | 21:10 |
| jdstrand | which I understand why you are doing that | 21:10 |
| jdstrand | I'm just saying that all the use cases for ubuntu personal have not been defined | 21:10 |
| elopio | Saviq: I only see the wrong identation on "build-in:" | 21:10 |
| elopio | am I missing another? | 21:10 |
| Saviq | elopio, that might've been it, checking | 21:10 |
| kyrofa | jdstrand, yeah, it's really quite minimal, but apparently the only way to use dbus is to be a framework, that's all | 21:10 |
| jdstrand | and so there aren't appropriate mechanisms for you to use | 21:11 |
| kyrofa | kgunn, are you still around? ^^ | 21:11 |
| Saviq | elopio, - kernel: video* is 3 spaces in | 21:11 |
| Saviq | and that seems to be it | 21:12 |
| jdstrand | kyrofa: it might be that we want to allow bus-name in app types but trigger a manual review. I don't know (again, architects group (aka, tvoss)) | 21:12 |
| * jdstrand -> meeting | 21:12 | |
| kgunn | kyrofa: i am... | 21:13 |
| elopio | mmm, ok, that one comes from the source. Will propose a change in there. | 21:13 |
| elopio | and the built-in seems to be playing funny tricks with the editor. | 21:13 |
| jdstrand | kyrofa: it might be worth noting that snaps aren't meant to replace debs in a 1 to 1 fashion. this is providing a service to a specific something. perhaps put all those somethings into one snap and make that a framework (still, need architect's direction) | 21:14 |
| jdstrand | kyrofa: frameworks are strictly defined: | 21:14 |
| davidcalle | Saviq, elopio, I've just imported the latest stable oem doc, don't touch the page :p | 21:14 |
| Saviq | ;) | 21:15 |
| davidcalle | Seriously :) | 21:15 |
| * kgunn wonders why Saviq is here :) | 21:15 | |
| jdstrand | kyrofa: https://developer.ubuntu.com/en/snappy/guides/frameworks/ | 21:15 |
| Saviq | kgunn, Orange Matchbox ;) | 21:15 |
| elopio | davidcalle: I'm not touching the oem page | 21:15 |
| kgunn | ah | 21:15 |
| jdstrand | kgunn: he's keeping me busy :P | 21:15 |
| kgunn | fun | 21:15 |
| Saviq | am monitoring my energy use! | 21:15 |
| * jdstrand iskidding (happy to help) | 21:15 | |
| davidcalle | Note that we are working on auto-import for stable and edge snappy docs. In ~two weeks or so. | 21:15 |
| Saviq | oops | 21:15 |
| Saviq | jdstrand, but but but! | 21:16 |
| * Saviq is filing bugs for you all! | 21:16 | |
| Saviq | bugsies | 21:16 |
| Saviq | so many bugsies | 21:16 |
| kyrofa | jdstrand, I gotcha. Yeah, I definitely don't need a framework... I guess I didn't expect dbus to be limited to frameworks is all | 21:16 |
| kgunn | kyrofa: i wouldn't have expected that either...thanks for poking | 21:16 |
| kyrofa | kgunn, so the scope is two pieces-- the scope itself and a little dbus daemon for maintaining state. The docs and jdstrand point out a dbus service is only supported for frameworks, which is way overkill for this | 21:18 |
| jdstrand | kyrofa: well, a dbus service is a service to other apps | 21:18 |
| kgunn | kyrofa: sure... | 21:19 |
| kgunn | jdstrand: but in a generic case, "apps" using dbus are consuming that service no ? | 21:19 |
| kgunn | at least, i'd have thot if you provide a service you have to be an app.... | 21:19 |
| kyrofa | kgunn, yes, but in that case they depend on the framework and have a capability inherited from the framework | 21:20 |
| kgunn | dang it...i mean fmwk | 21:20 |
| kgunn | kyrofa: so in turn "they" proxy dbus? in that case i do understand | 21:20 |
| jdstrand | kgunn: apps may use a service if they security policy allows it. that policy is expressed via framework-policy | 21:21 |
| jdstrand | kgunn: or via system supplied policy | 21:21 |
| jdstrand | kgunn: right now on touch, we have a bunch of dbus services that are shipped as part of the image, and the image ships security policy that apps may specify to use it | 21:22 |
| jdstrand | kgunn: but the services themselves aren't shipped as clicks | 21:22 |
| kyrofa | jdstrand, so the only way to update them is OTA, yes? | 21:23 |
| jdstrand | kgunn: it is the same on snappy. things that ship services to other apps either need to be in the image or shipped as framework snaps | 21:23 |
| jdstrand | kyrofa: if on the image, yes. just like on touch | 21:23 |
| jdstrand | kgunn: my understanding was that the ubuntu personal image was going to be a big image (compared to core) like it is now on touch, as opposed to a collection of snaps on top of core | 21:24 |
| kgunn | jdstrand: yep, and no problem, i think kyrofa can continue down the "it's just in the image" road.... | 21:24 |
| jdstrand | kgunn: if the latter, then we really need to get the architects talking about things with the various stakeholders (core, security, etc) | 21:25 |
| kgunn | i was just curious about the dbus use mandating a thing be a fmwk.... | 21:25 |
| kyrofa | kgunn, jdstrand indeed I can. debs are easy | 21:25 |
| jdstrand | kgunn: well, it is because apps aren't supposed to be services to other apps | 21:25 |
| jdstrand | kgunn: apps are isolated | 21:26 |
| kgunn | got it | 21:26 |
| jdstrand | kgunn: consider this-- if we did make it so that an app could ship a dbus service and that service could listen on the dbus, no other apps would be able to talk to it because there is no security from them to declare to talk to it | 21:26 |
| jdstrand | s/no security from/no security policy for/ | 21:27 |
| kyrofa | jdstrand, except a binary shipped in the same snap, yes? | 21:27 |
| jdstrand | yes | 21:27 |
| jdstrand | you can always do that | 21:27 |
| kyrofa | jdstrand, which is exactly what I need | 21:27 |
| jdstrand | ok, well, you can setup a private dbus | 21:27 |
| jdstrand | and not use the system one. it would be a private session bus | 21:28 |
| kgunn | :P | 21:28 |
| kgunn | please allow myself to talk to myself | 21:28 |
| jdstrand | actually, that won't work just yet | 21:28 |
| jdstrand | you would need the 'sockets' stuff that isn't implemented yet | 21:28 |
| jdstrand | actually, perhaps just an abstract socket unix rule that is namespaced... | 21:29 |
| jdstrand | I need to think about that | 21:29 |
| * jdstrand makes note | 21:29 | |
| jdstrand | anyhoo, that isn't available today | 21:29 |
| kyrofa | jdstrand, alright, not a big deal, getting it in the image is easy enough, just a little more work for seb | 21:30 |
| jdstrand | kgunn: today, you can setup a writable named unix socket in the snap's writable area and have apps communicate over that | 21:30 |
| jdstrand | but that is probably more work than just putting it on the image | 21:30 |
| kyrofa | kgunn, do you think the long-term vision is having this as a snap, or leaving it in the image? If we want it as a snap eventually it sounds like we should start talking to people | 21:31 |
| jdstrand | ok, meeting for real now | 21:31 |
| kyrofa | jdstrand, :P | 21:31 |
| kyrofa | jdstrand, thanks for all your time! | 21:31 |
| jdstrand | np | 21:31 |
| kgunn | kyrofa: honestly, it kinda feels like it'll always be in the image ? i mean at some point | 21:33 |
| kgunn | we'll go all snaps all the time | 21:33 |
| kgunn | and we'll always need a scope installed for the store | 21:33 |
| kyrofa | kgunn, yeah, it's kinda integral | 21:33 |
| kgunn | feels more like a nice to have | 21:33 |
| kyrofa | kgunn, agreed | 21:34 |
| kgunn | in terms of it being a snap | 21:34 |
| kgunn | but thanks for trying | 21:34 |
| kgunn | these are great attempts, we always learn a little more :) | 21:34 |
| kyrofa | kgunn, definitely! Okay, I'll invest some time making sure I've got a good .deb coming out of the CI then instead | 21:35 |
| kyrofa | kgunn, thanks for letting me drag you in! :) | 21:35 |
| === j12t_ is now known as j12t | ||
| kgunn | kyrofa: thank you! | 21:45 |
| Saviq | looking for +1s on bug #1472797, anyone? | 21:54 |
| nothal | Bug #1472797: Should use bmap or a bmap-like solution to reduce flashing time <goget-ubuntu-touch (Ubuntu):New> <http://launchpad.net/bugs/1472797> | 21:54 |
| ubottu | bug 1472797 in goget-ubuntu-touch (Ubuntu) "Should use bmap or a bmap-like solution to reduce flashing time" [Undecided,New] https://launchpad.net/bugs/1472797 | 21:54 |
| Saviq | ;) | 21:54 |
| Saviq | hmm where do I file bugs against ubuntu-core? | 22:01 |
| jdstrand | Saviq: the snappy project is prbably a fine first choice | 22:02 |
| fjay | should /var/lib/apps/<pkgname>/current/ | 22:07 |
| fjay | exist? | 22:07 |
| fjay | w/ the proper packagename obviously | 22:07 |
| fjay | or has that approch been deprecated and the docs do not reflect that. | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
