| dholbach | good morning | 06:15 |
|---|---|---|
| fgimenez | good morning | 07:12 |
| dholbach | hey ogra_ - how's life? | 08:39 |
| ogra_ | monday morningish :) | 08:39 |
| dholbach | :) | 08:39 |
| dholbach | ogra_, I just had a long weekend, so I thought I'd just give you a ping and suggest we have a chat whenever you feel like working on the py-snapper :) | 08:40 |
| ogra_ | dholbach, i'm still in the middle of experimenting | 08:42 |
| dholbach | ogra_, cool - let me know how it goes :) | 08:50 |
| ogra_ | essentially we'll just use PYTHONUSERBASE ... but i'm still fiddling on scriptery to get the interpreter shipped and used too | 08:51 |
| ogra_ | (since python will eventually be gone from the images) | 08:52 |
| ogra_ | if apps define #!/usr/bin/python we're screwed with that ... i have no clue how to get around this | 08:54 |
| damjan | ogra_: report bug upstream to use console_scripts entry point :) | 08:58 |
| damjan | ogra_: PYTHONUSERBASE FTW! | 08:58 |
| ogra_ | damjan, against all packages in the ubuntu/debian archives ? | 09:02 |
| ogra_ | i think the only solution would be to bind or overlay mount the shipped interpreter on top of /usr/bin/python ... and only do that insode the confined space | 09:06 |
| JamesTait | Good morning all; happy Monday, and happy Nature Photography Day! 😃 | 09:09 |
| ricmm | ogra_: that last one sounds kind of volatile | 09:11 |
| ricmm | ogra_: if they *ship* the interpreter in the snap, isn't it ok to assume that they would also modify the shebangs accordingly? | 09:12 |
| ogra_ | not really | 09:12 |
| ricmm | why not | 09:12 |
| ogra_ | i wouldnt assume the packager to be fluent in that if he uses a script to roll some upstream project into a snap | 09:13 |
| ricmm | they are already going through the work of shipping the interpreter | 09:13 |
| ogra_ | like not everyone installing from a tarball on linux does need to know C fopr "configure, make, make install" | 09:13 |
| ogra_ | they are running a script that ships the interpreter | 09:14 |
| ogra_ | (at least thats the plan .. ) | 09:14 |
| ricmm | right so they arent shipping anything thmselves | 09:14 |
| ricmm | you are | 09:14 |
| ogra_ | exactly | 09:15 |
| ogra_ | and my problem is to make it work without mangling their shebang lines | 09:15 |
| ricmm | I guess its ok to do what you said then | 09:19 |
| ricmm | considering it is also your script which will be bundling the interpreter | 09:19 |
| ricmm | so the possible paths are all accounted for, and chosen by you | 09:20 |
| ogra_ | <ricmm> I guess its ok to do what you said then | 09:20 |
| ogra_ | ? | 09:20 |
| ogra_ | i gave three options :) | 09:20 |
| ricmm | the overlay/bind mount | 09:20 |
| ogra_ | ah | 09:20 |
| ogra_ | well, how would i do that so it only affects the snap ? | 09:21 |
| ogra_ | is there some cgroup stuff i can use ? | 09:21 |
| ricmm | I dont think so | 09:21 |
| ogra_ | (overlay mount is out of discussion as long as we want to support BSP kernels, needs to be a bind mount ) | 09:21 |
| ricmm | right | 09:22 |
| ogra_ | which doesnt make it easier :) | 09:22 |
| ricmm | ogra_: thinking | 09:24 |
| ricmm | what other options do you have? | 09:24 |
| ricmm | so, python is an important part of snapcraft and so on | 09:25 |
| ogra_ | loop over all files in our snap and patch the shebang with a variable if we find it ... | 09:25 |
| ogra_ | i dont think there are more | 09:25 |
| ricmm | ogra_: what if we remove python from the snap, but instead replace the interpreter with one of your awesome shell scripts | 09:25 |
| ricmm | one that sets up the env for the calling snap | 09:26 |
| ogra_ | not sure what you mean ... replace the interpreter of the snappy installation ? | 09:26 |
| ricmm | yea | 09:26 |
| ogra_ | phew | 09:26 |
| ogra_ | that might make barry unhappy :) | 09:26 |
| ricmm | what we dont want is people using the shipped interpreter, but that doesnt mean we cant catch their usage with a script of our own | 09:26 |
| ricmm | unhappier than removing python altogether? | 09:27 |
| ogra_ | well, that will happen eventually ... what do we do then ? | 09:27 |
| ogra_ | once my shell script is gone the packages have the same prob again | 09:27 |
| ricmm | why would your shell script be gone | 09:28 |
| ricmm | I'm talking about *removing* python | 09:28 |
| ricmm | and shipping your /usr/bin/python shell script instead | 09:28 |
| ogra_ | and i'm not sure we want to ship such scripts for all possible interpreters out there (i assume we'll have the same issue with other script langs) | 09:28 |
| ricmm | I don't see why not, if we want to provide a generic way of doing things | 09:28 |
| ogra_ | hmm | 09:28 |
| ricmm | either we provide something, or we dont provide anything at all | 09:28 |
| ricmm | sorry, either we provide everything or nothing :p | 09:29 |
| ricmm | but anywhere in between might be confusing and chaotic | 09:29 |
| ogra_ | right | 09:29 |
| ogra_ | thats a lot of maintenance work :/ | 09:30 |
| ricmm | well, someone made a choice about this somewhere ;) | 09:30 |
| ricmm | lets think a bit more | 09:30 |
| ricmm | short of having something in /usr/bin/python be it a script, a bind mount of an interpreter, or the actual distro one... theres nothing we can do | 09:31 |
| ricmm | besides catching a call to open() | 09:31 |
| ricmm | and stat | 09:31 |
| ricmm | ogra_: maybe its time to discuss a libsnappy.so :) | 09:35 |
| ricmm | that is always preloaded | 09:36 |
| * ricmm has goosebumps | 09:36 | |
| ogra_ | haha | 09:40 |
| === vrruiz_ is now known as rvr | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| rsalveti | morning | 11:39 |
| rsalveti | ricmm: libsnappy? :-) | 11:49 |
| rsalveti | really wish we had a proper overlay support | 11:49 |
| ricmm | rsalveti: :) | 11:49 |
| ogra_ | rsalveti, tell that to the BSP kernels :P | 11:51 |
| rsalveti | ogra_: we don't even have a proper overlay story with upstream | 11:52 |
| ogra_ | yeah | 11:52 |
| ogra_ | well, the live iso uses it, no ? | 11:53 |
| ogra_ | so we have some story there | 11:53 |
| longsleep | My snappy has a problem to get a DHCP address after i changed ethernet to another network. Dhclient loops with send_packet: Network is unreachable while trying to send DHCPREQUEST to the previous DHCP server. | 11:53 |
| rsalveti | ogra_: not with apparmor | 11:54 |
| ogra_ | ah | 11:55 |
| longsleep | ogra_: Does socker work on your rpi2 image? On my odroid i just get BUG: scheduling while atomic: docker.armhf/1227/0x00000002 when running a container :/ | 12:13 |
| * longsleep just realized that he has to start armhf images on arm platform | 12:18 | |
| ogra_ | longsleep, yep, running the owncloud package here | 12:20 |
| ogra_ | on top of docker | 12:20 |
| ogra_ | (thats usually my definitive test for the image, snapy install docker ... snappy instrall owncloud .... wait 10-15min ... test owncloud) | 12:20 |
| ogra_ | (teh owncloud install downloads stuff in bg for 10-15min before first start) | 12:21 |
| longsleep | ogra_: mhm ok - so its probably the kernel then. I get plenty of scary messages when running a docker container | 12:22 |
| ogra_ | i havent tried running a docker container directly though | 12:22 |
| ogra_ | i always only install these two snaps | 12:22 |
| ogra_ | ou need some modules in your kernel for docker to work though | 12:22 |
| longsleep | if anyone wants to take a look http://paste.ubuntu.com/11719136/ | 12:23 |
| ogra_ | http://paste.ubuntu.com/11719142/ | 12:23 |
| longsleep | can you try docker run -i -t armv7/armhf-ubuntu_core /bin/bash | 12:23 |
| ogra_ | Unable to find image 'armv7/armhf-ubuntu_core:latest' locally | 12:24 |
| ogra_ | latest: Pulling from armv7/armhf-ubuntu_core | 12:24 |
| ogra_ | ffb007497c55: Downloading 2.751 MB/44.71 MB | 12:24 |
| ogra_ | ... | 12:24 |
| ogra_ | now it downloads | 12:24 |
| longsleep | yeah that works for me too, but it just hangs with kernel bug message in log | 12:24 |
| longsleep | when it starts after download | 12:25 |
| ogra_ | ffb007497c55: Already exists | 12:26 |
| ogra_ | Digest: sha256:f9678f50148f8461bec2593967e62aa1e2a95184eb1adb74c299c1399bf4e99b | 12:26 |
| ogra_ | Status: Downloaded newer image for armv7/armhf-ubuntu_core:latest | 12:26 |
| ogra_ | root@e198690d2cce:/# | 12:26 |
| ogra_ | looks fine to me | 12:26 |
| longsleep | yeah good thanks - this means i need to look at the kernel again .. | 12:27 |
| rsalveti | ogra_: I'm trying to write a general status for our all team, and looking for the snaps that got uploaded/updated to the store, and I know you updated at least chatroom last week | 12:38 |
| rsalveti | ogra_: is there any other snap that you uploaded/updated over the past 2 weeks? | 12:38 |
| rsalveti | I might just write a script for that, since it seems there is even a changelog in there now | 12:39 |
| ogra_ | rsalveti, no, i was working a bit on Os.js but havent finished it yet ... and i plan to re-upload the fhem-demo one too but same thing ... the pi image ate nearly all of my last week | 12:43 |
| rsalveti | yeah, no worries | 12:44 |
| seb128 | sergiusens, hey, did you get anywhere on friday with the personnal image issues? | 13:03 |
| sergiusens | seb128: sorry, its taking longer than expected | 13:04 |
| sergiusens | given I took the opportunity to change things and not hack something in | 13:05 |
| seb128 | sergiusens, did you find things wrong? | 13:05 |
| seb128 | great | 13:05 |
| sergiusens | seb128: no, no real issues, I just don't want to code dup ;-) | 13:06 |
| seb128 | sergiusens, k, but should hacking a different partition size should be enough to write the image? do you know what's the "issue while mapping partitions: more partitions then expected while creating loop mapping" is? | 13:08 |
| sergiusens | seb128: that should be kpartx doing something weird (dmsetup clear might work around it) | 13:11 |
| seb128 | sergiusens, not sure I understand what you mean there ... what should I try and how? | 13:11 |
| sergiusens | seb128: kpartx -avs [outfile]; parted [loop returned] print // should be 5 | 13:12 |
| seb128 | sergiusens, kpartx returns nothing on the img... | 13:15 |
| seb128 | well I'm unsure what that .img is now, since the udf command fails on the loop map error | 13:15 |
| sergiusens | seb128: sudo DEBUG_DISK=1 ubuntu-device-flash ... | 13:27 |
| seb128 | sergiusens, does it work locally for you? | 13:28 |
| sergiusens | seb128: u-d-f in general yes; what won't work for you is that you have no packages in the store for personal | 13:29 |
| * sergiusens thought he mentioned this on Friday | 13:29 | |
| seb128 | sergiusens, unsure what it's downloading as well, the device tarball is < 100 mb that doesn't match the tarball from the cdimage builder | 13:29 |
| seb128 | sergiusens, you mean "package"? | 13:30 |
| sergiusens | seb128: I mean all packages in the store are for core; snappy sends out the release name (and flavor) to the store to get packages | 13:30 |
| seb128 | sergiusens, I've been tried with the local hack from http://paste.ubuntu.com/11700710/ | 13:31 |
| seb128 | sergiusens, well, packages are a matter once you have a working base img you can boot no? | 13:31 |
| seb128 | I'm not trying to install packages, just to get an image that starts | 13:31 |
| sergiusens | seb128: the oem package needs to be in the store at least for personal (not that this is blocking you now) | 13:32 |
| sergiusens | beuno: ^ | 13:32 |
| sergiusens | seb128: I'll give that patch a go and tell you what's wrong with it | 13:32 |
| beuno | what what? | 13:33 |
| sergiusens | beuno: we need the personal counterpart for core-rolling | 13:34 |
| beuno | sergiusens, ack. nessita ^ | 13:35 |
| seb128 | sergiusens, thanks | 13:38 |
| seb128 | sergiusens, you need to UDF_UBUNTU_CORE_NAME=ubuntu-personal but I guess you saw that from the code ;-) | 13:38 |
| sergiusens | seb128: yup | 13:39 |
| jdstrand | kgunn: regarding lchown... apps don't currently have lchown cause apps don't know what user to chown things to, however, it can be added to you framework in the file you specify for seccomp to "security-policy" | 13:39 |
| sergiusens | seb128: I see a 900MB ~ download here | 13:43 |
| seb128 | sergiusens, only one download? or do you cumulate tarballs? | 13:44 |
| seb128 | sergiusens, that doesn't match the sizes from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29728 | 13:44 |
| sergiusens | seb128: err sorry, 456 and 99 | 13:45 |
| seb128 | sergiusens, right, same here, but that doesn't match the tarballs from ^ | 13:46 |
| seb128 | even recompressing the device one in .xz it's 120M | 13:46 |
| seb128 | unsure if the channel tarballs are identical to the livefs build ones though | 13:46 |
| nessita | seb128, not sure what you need, how can I help? | 13:49 |
| sergiusens | seb128: it's 100MB on the s-i server | 13:49 |
| sergiusens | it's just M so not sure it's MiB or MB | 13:50 |
| ogra_ | seb128, well, i think slangasek had a valid point with the /system dir prefix | 13:50 |
| sergiusens | seb128: here too -rw-r--r-- 1 sergiusens sergiusens 100M jun 15 10:45 /home/sergiusens/.cache/ubuntuimages/pool/device-9a06d62b4fe6485e22b0ae9f1d7da08aed8605b0286a63b6fa5639bc6e1f1187.tar.xz | 13:50 |
| ogra_ | you might need to re-package the cdimage tarball | 13:50 |
| ogra_ | (not sure that is your actual issue here ) | 13:50 |
| seb128 | nessita, hey, I want to build a snappy personnal image ;-) | 13:51 |
| ogra_ | just do it then ... dont hold back | 13:51 |
| * ogra_ hides | 13:51 | |
| seb128 | but I think sergiusens is looking at helping, so probably no need to have more people looking at the same thing | 13:51 |
| seb128 | ogra_, oh, why didn't I think of that! :p | 13:51 |
| ogra_ | :D | 13:52 |
| seb128 | nessita, we have tarballs built on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next and slangasek got those in a system-image channel for personnal, but bits are missing still to be able to get u-d-f to build a working img, trying to figure out what those bits are exactly | 13:52 |
| nessita | seb128, hi! sorry I meant sergiusens before, autocomplete failure :-) | 13:53 |
| seb128 | nessita, oh ok ;-) | 13:53 |
| nessita | sergiusens, so what do you need from me/the store? | 13:53 |
| nessita | seb128, sorry sorry, I'm not that skilled in snappy to help you there | 13:54 |
| seb128 | nessita, no worry | 13:54 |
| sergiusens | nessita: releases today are core-15.04 and core-rolling, we need personal-rolling | 13:55 |
| sergiusens | or the other way around with flavor / release | 13:55 |
| * sergiusens always forgets | 13:55 | |
| nessita | sergiusens, currently we have rolling-core | 13:58 |
| nessita | 15.04-core | 13:58 |
| nessita | sergiusens, shall I add rolling-personal then? | 13:58 |
| sergiusens | nessita: yeah | 13:58 |
| nessita | sergiusens, done | 13:59 |
| elopio | good morning | 14:08 |
| tedg | Morning elopio! | 14:08 |
| seb128 | nessita, sergiusens, just trying to understand what's going on/how thing work, what are those server release? what is "personal-rolling" now, a channel name or...? | 14:08 |
| ogra_ | elopio, such a beautiful game on the weekend !! | 14:11 |
| sergiusens | seb128: the store filters on releases, it's like frameworks from the click world | 14:11 |
| seb128 | sergiusens, ah, I see | 14:11 |
| sergiusens | seb128: so when you start to publish snaps that only work for personal we won't see them in core and vice versa | 14:11 |
| seb128 | sergiusens, who/what defines on what release you are? can you see that info from the command line? | 14:12 |
| sergiusens | although I suspect everything in core would work on personal | 14:12 |
| seb128 | it should | 14:12 |
| sergiusens | seb128: right now snappy info (but it's derived from the channel name) | 14:12 |
| seb128 | k | 14:12 |
| sergiusens | seb128: the current u-d-f patch doesn't have the right release setting right now, but once it's used it will affect you | 14:12 |
| elopio | fgimenez: https://plus.google.com/hangouts/_/g6uj5z3fgt7ybmm4ltyadiyqima | 14:12 |
| elopio | ogra_: wait, the one agains korea? | 14:13 |
| elopio | *against | 14:13 |
| ogra_ | yeah | 14:13 |
| * ogra_ loved it | 14:13 | |
| sergiusens | seb128: http://paste.ubuntu.com/11719625/ | 14:14 |
| sergiusens | seb128: so it works for me, the mapping error you see needs to be signalled to the kernel somehow; but I don't really know how to get out of it sometimes without a reboot | 14:14 |
| seb128 | sergiusens, hum, unsure what you did differently? | 14:15 |
| sergiusens | it sometimes keeps showing 2 partitions even though it has 5 (according to parted on the .img at least) | 14:15 |
| seb128 | mvo has the same mapping error than me when he tried | 14:15 |
| seb128 | so it's a random failure issue, need to reboot and retry? | 14:15 |
| sergiusens | seb128: I rinsed and repeated twice already and no mapping errors (this time without --install webdm) | 14:18 |
| seb128 | sergiusens, k, let me try again locally, thanks | 14:18 |
| seb128 | sergiusens, I see a grub error in your log though, did that make the img generation fail? | 14:18 |
| sergiusens | seb128: your image is missing /usr/lib/grub/x86_64-efi/modinfo.sh in any case steve would know how to get that in | 14:18 |
| sergiusens | seb128: yeah | 14:19 |
| seb128 | slangasek, ^ | 14:19 |
| sergiusens | seb128: that's run with 'chroot' so it needs to be either seeded or mungled in from livecd-rootfs | 14:19 |
| zyga | re | 14:19 |
| seb128 | sergiusens, right, I see that livecd-rootfs/auto/config has "add_package install grub-pc" | 14:21 |
| seb128 | I guess we need that in desktop-next | 14:21 |
| sergiusens | seb128: that's seeded as well | 14:21 |
| seb128 | mvo was right, we should merge those sections :p | 14:22 |
| sergiusens | seb128: grub-pc, grub-efi-amd64-bin and grub-efi-ia32-bin (for amd64) | 14:22 |
| mvo | ha! I like to be right | 14:22 |
| seb128 | mvo, :-) | 14:22 |
| * mvo has no idea what he was right about | 14:22 | |
| seb128 | sergiusens, oh, right | 14:22 |
| seb128 | Get:1019 http://ftpmaster.internal/ubuntu/ wily/main grub-pc amd64 2.02~beta2-25ubuntu1 [221 kB] | 14:22 |
| seb128 | on https://launchpadlibrarian.net/209103030/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz | 14:22 |
| seb128 | hum | 14:23 |
| mvo | seb128: oh, yeah, we need some sort of inheritance in that script indeed | 14:23 |
| elopio | ogra_: that was good, yes! I thought nobody watched women football games. | 14:25 |
| ogra_ | i watch a lot of them | 14:25 |
| davmor2 | ogra_: is the watchman | 14:27 |
| ogra_ | :D | 14:27 |
| tedg | Ha, in the US we do, it's where we win sometimes :-) | 14:27 |
| ogra_ | yeah, your team is pretty awesome | 14:28 |
| * ogra_ relaly hopes for germany vs USA | 14:28 | |
| slangasek | sergiusens, seb128: see the core seed, which includes both grub-efi-amd64-bin and grub-pc. Ultimately, you actually want to have shim-signed, grub-efi-amd64-signed, and grub-pc-bin seeded, so maybe you want to seed those now and see if udf keeps up | 14:36 |
| seb128 | slangasek, https://launchpadlibrarian.net/209105327/buildlog_ubuntu_wily_amd64_ubuntu-core_BUILDING.txt.gz doesn't mention grub-efi... | 14:38 |
| slangasek | seb128: I don't know that that's the right build log, then? | 14:39 |
| seb128 | slangasek, that's one from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core | 14:39 |
| seb128 | isn't that ubuntu-core? | 14:39 |
| slangasek | seb128: no, that's the old ubuntu-core | 14:40 |
| slangasek | (ubuntu-core doesn't build on powerpc or arm64) | 14:40 |
| seb128 | slangasek, hum, that's all confusing to me :-/ | 14:41 |
| seb128 | slangasek, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/touch-core isn't the right seed either? | 14:41 |
| slangasek | lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.wily | 14:42 |
| slangasek | grep -rl snappy --> system-image | 14:42 |
| slangasek | but again this is /not/ what I'm recommending you seed for the personal image; instead I'm recommending that you seeed: | 14:43 |
| slangasek | shim-signed [amd64] | 14:43 |
| slangasek | grub-efi-amd64-signed [amd64] | 14:43 |
| slangasek | grub-pc-bin [i386 amd64] | 14:43 |
| slangasek | grub-efi-ia32 [i386] | 14:43 |
| ogra_ | seb128, FYI https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/ | 14:43 |
| seb128 | slangasek, yeah, I'm just wondering if we based/derived from the wrong seed | 14:44 |
| seb128 | Laney, ^ do you think we got confused? | 14:44 |
| seb128 | slangasek, thanks | 14:44 |
| slangasek | seb128: quite possibly. The touch seeds being a separate seed pod, not tied to main, is a bug | 14:44 |
| ogra_ | well, you want the seed content from the touch-desktop seed | 14:45 |
| ogra_ | but not necessarily the same setup in the end ... | 14:46 |
| ogra_ | (since ... snappy vs system-image) | 14:46 |
| seb128 | ogra_, yeah, I though we wanted ubuntu-core + desktop_bits | 14:46 |
| Laney | seb128: Sorry, confused about what? | 14:46 |
| seb128 | so that we wanted to inherit from core | 14:46 |
| seb128 | rather than duplicate | 14:46 |
| Laney | Where do we get the core bits from now? | 14:46 |
| seb128 | Laney, core seems to be http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.wily/view/head:/system-image | 14:47 |
| * ogra_ doesnt actually know where the ubuntu-core-system-image seed lives ... | 14:47 | |
| slangasek | ogra_: the touch-desktop seed being outside of ubuntu.wily is a bug | 14:47 |
| ogra_ | mvo, ? ^^ | 14:47 |
| slangasek | I already pointed them to the source of the ubuntu-core system-image seed | 14:47 |
| ogra_ | ah, k | 14:47 |
| seb128 | Laney, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop is the "Task-Seeds" wrong then? | 14:48 |
| * seb128 confused | 14:48 | |
| sergiusens | can we rename that file to core or snappy-core? | 14:48 |
| ogra_ | slangasek, oh, btw, do yoou think it is ok to move the /system prefix creation into livecd-rootfs (i understood your mail comment like that) | 14:48 |
| ogra_ | sergiusens, "that file" ? | 14:49 |
| zyga | hey | 14:49 |
| sergiusens | ogra_: system-image in the seeds | 14:53 |
| Laney | seb128: I think that means that we get the packages from Task: touch-core too | 14:53 |
| ogra_ | sergiusens, ah | 14:53 |
| ogra_ | i guess we can | 14:53 |
| Laney | seb128: Not sure what your question is - do you want to include that system-image seed? | 14:53 |
| slangasek | ogra_: it's ok, but needs to be properly coordinated across both sides of the infrastructure | 14:54 |
| seb128 | Laney, it seems like it would make sense, what do you think? | 14:56 |
| Laney | seb128: probably, would touch-core need splitting up then? | 14:57 |
| seb128 | Laney, I'm unsure what my question is ;-) trying to figure out what's the right way to do what we need | 14:57 |
| seb128 | should be seed grub&co like slangasek recommended | 14:57 |
| seb128 | or somehow makes our seed include the system-image (ubuntu-core) one | 14:57 |
| seb128 | which already brings those in | 14:58 |
| seb128 | Laney, unsure, why would it? | 14:58 |
| Laney | It has click and some of the same core utilities | 14:59 |
| slangasek | sunsetting the ubuntu-touch seed pod would not be a bad idea | 14:59 |
| slangasek | it was only ever separate because we needed something that worked while the touch packages were not yet in the archive | 15:00 |
| slangasek | it has long outlived its usefulness | 15:00 |
| ogra_ | slangasek, well, most touch packages are still universe ... the initial plan back then was to merge the touch seed into the official ubuntu branch once they have migrated to main | 15:04 |
| slangasek | ogra_: that's upside-down | 15:04 |
| ogra_ | but then we were told to not push for main inclusion anymore and the whole thing fell off the table | 15:04 |
| slangasek | packages move to main *because* they're in the seed | 15:04 |
| seb128 | Laney, I'm unsure to understand, what would you split touch-core into? | 15:05 |
| slangasek | who said not to push for them in main? | 15:05 |
| ogra_ | slangasek, right, once they are ready for that | 15:05 |
| ogra_ | slangasek, product team iirc ... i dont know who exactly, back then asac forwarded the info | 15:05 |
| ogra_ | (when he was still a phone guy... thats all long ago) | 15:05 |
| Laney | seb128: Do you want click on this image? | 15:06 |
| ogra_ | slangasek, all main inclusion efforts have stopped since (beyond stuff like Mir which is used on the desktop too) | 15:07 |
| seb128 | Laney, not especially, I don't think click is going to work in the image is ro? | 15:07 |
| Laney | It's in touch-core | 15:07 |
| seb128 | Laney, in any case http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.wily/view/head:/system-image has click-apparmor and some other bits | 15:07 |
| seb128 | Laney, right, but is that right that we derivate from touch-core | 15:08 |
| seb128 | rather than from system-image ^ | 15:08 |
| slangasek | ogra_: I don't know what you think "once they're ready" means... getting them ready for main means going through the MIR process | 15:09 |
| ogra_ | slangasek, exactly that :) | 15:09 |
| ogra_ | having MIRs, making sure the deps are migrateable etc | 15:09 |
| seb128 | Laney, sorry, it's all confusing ... I think the easiest first change would be to add the grub depends slangasek recommended to http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop | 15:09 |
| seb128 | we can see about re-organizing later I guess | 15:10 |
| seb128 | slangasek, is system-image (ubuntu-core) not including shim-signed [amd64] on purpose? | 15:10 |
| ogra_ | slangasek, point is, i was the guy nagging people to get their stuff into main and at some point i was told to stop nagging since that wouldnt be wanted ... so i stopped ... and thats the status quo | 15:11 |
| ogra_ | ask asac for details ... | 15:11 |
| Laney | seb128: OK, I guess it would fine to reorganise it in conjunction with moving everything to 'ubuntu' | 15:12 |
| Laney | I imagine the MIR team is going to have to grow first | 15:12 |
| ogra_ | that too | 15:13 |
| noise][ | sergiusens: or ogra_: hi, have a minute to help me figure out why that latest rpi2 image I installed has an old/messed-up webdm? | 15:13 |
| ogra_ | noise][, not only that but you also have a clock at 1970 ... and thats tecnically impossible with the recent image | 15:14 |
| ogra_ | noise][, did you try flashing it again ? | 15:14 |
| ogra_ | does smell a bit like your flashing failed | 15:14 |
| noise][ | ogra_: yes, reflashed, and: cat /etc/ubuntu-build | 15:14 |
| noise][ | 3 | 15:14 |
| ogra_ | system-image-cli -i | 15:14 |
| Laney | seb128: You might want to know if they add things to system-image to mirror those over to desktop | 15:14 |
| noise][ | and there's recent (jun 11) files | 15:14 |
| Laney | i.e. maybe consider subscribing to that branch | 15:15 |
| ogra_ | thats the better way to find your version | 15:15 |
| noise][ | k | 15:15 |
| ogra_ | (but will indeed output 3 too) | 15:15 |
| noise][ | http://pastebin.ubuntu.com/11719922/ | 15:15 |
| ogra_ | yeah, that looks all fine | 15:15 |
| seb128 | Laney, yeah | 15:15 |
| noise][ | but getting that same snappy list output i stuck in the email | 15:16 |
| noise][ | w/ webdm 0.1 | 15:16 |
| ogra_ | i'm not really sure what to say ... | 15:17 |
| noise][ | i feel like i must be doing/have done something silly but not seeing what it is :) | 15:17 |
| ogra_ | there cant be a 0.1 version | 15:17 |
| ogra_ | and the image clearly ships 0.9 | 15:17 |
| noise][ | i checked the md5sum of the image I dd'd and clearly i'm on #3 | 15:17 |
| noise][ | maybe i'll try to build an image for kicks | 15:18 |
| mvo | mterry: have you looked if go generate might be helpful for the gettext stuff? | 15:26 |
| ogra_ | well, if you use my oem snap and my device tarball and the latest ubuntu-devlce-flash you most likely get an identical image, but try it :) | 15:26 |
| ogra_ | noise][, you could try to zero the card first or some such | 15:26 |
| mterry | mvo, no, let me see what that's about | 15:27 |
| noise][ | ogra_: I totally wiped it before last dd :( | 15:28 |
| ogra_ | do you ahev a serial cable so you could capture a full boot with screen -L ? | 15:30 |
| ogra_ | *have | 15:30 |
| ogra_ | screen /dev/ttyUSB0 115200 -L | 15:31 |
| ogra_ | that will create screenlog.0 in your current dir | 15:31 |
| noise][ | yes, will do | 15:31 |
| mterry | mvo, hmm, no probably not super useful. It's easier to extract strings from all files at once | 15:31 |
| genii | Need sudo with screen if you want to set the speed | 15:31 |
| ogra_ | genii, ug, on gentoo perhaps | 15:31 |
| ogra_ | :P | 15:32 |
| mvo | mterry: aha, if it does not do wildcards, then yeah, probably not. it would also have to run automatically at least during package build which it seems is currently not done | 15:32 |
| ogra_ | genii, a proper ubuntu should be using udev-acl and give you full access to ttyUSB0 | 15:32 |
| elopio | sorry I missed the last part of the meeting. | 15:32 |
| elopio | crappy internet here. | 15:32 |
| ogra_ | no sudo needed | 15:32 |
| mterry | mvo, yeah, it doesn't run automatically, and it seems oriented towards doing something to *this* file or *this* package. Whereas I want it to work on all project go files | 15:33 |
| genii | ogra_: Interesting, I found without sudo before, and parameters passed don't take. But this is with 12.04 | 15:33 |
| mterry | Not much convience over a tiny shell script | 15:33 |
| ogra_ | genii, hmm, even 12.04 should allow that ... sounds like a bug | 15:34 |
| mvo | mterry: *nod* | 15:35 |
| mterry | mvo, if it ran automatically, that would be nice. Is there a concept like "install hook"? | 15:35 |
| mterry | mvo, btw you can see what I proposed here: https://code.launchpad.net/~mterry/snapcraft/gettext/+merge/261965 | 15:36 |
| mvo | mterry: I look at it, thanks | 15:38 |
| elopio | fgimenez: https://code.launchpad.net/~elopio/snappy/go-tests2/+merge/261982 | 15:38 |
| elopio | fgimenez: and I think you can remove the python code, your go version works nicely. | 15:39 |
| fgimenez | elopio, awesome thx! | 15:40 |
| elopio | fgimenez: this one fails: FAILED: ./_integration-tests/tests/80_test_failover. Because of the no reboot file we are touching, right? | 15:43 |
| fgimenez | fgimenez, i haven't executed it yet but it'll likely be because of that, we should look into the adt-run error while rebooting | 15:45 |
| awojo | is snappy ready to be used as your daily driver on a laptop? | 15:50 |
| ogra_ | as a server perhaps | 15:51 |
| beuno | yeah, not yet | 15:51 |
| elopio | fgimenez: it's a little before the reboot. rm: cannot remove ‘/writable/cache/system/etc/rc.local’: No such file or directory | 15:51 |
| elopio | I'll dig more to see what's that about. | 15:52 |
| === chihchun is now known as chihchun_afk | ||
| fgimenez | elopio, i'm getting this http://paste.ubuntu.com/11720144/ it seems that it's rebooting ok? | 16:00 |
| elopio | fgimenez: I hate it when it fails only for me | 16:01 |
| fgimenez | elopio, yep very frustrating :) there are other tests that also reboot, 07_test_install_framework is working? | 16:04 |
| elopio | fgimenez: yes, I was wrong. My error is after the reboot, on the last step. | 16:04 |
| === dpm is now known as dpm-afk | ||
| noise][ | well I can't explain it, but I re-flashed a 3rd time and now I've got the correct webdm 0.9. system-image-cli -i output is exactly the same before/after. very strange. In any case thx ogra_ for the help. | 16:10 |
| elopio | fgimenez: http://paste.ubuntu.com/11720208/ the first thing that seems different on mine is that it says "another snappy is running". | 16:10 |
| elopio | mvo, sergiusens: any idea what can cause that? ^ | 16:11 |
| ogra_ | noise][, \o/ | 16:12 |
| ogra_ | hooray !!! | 16:12 |
| noise][ | now to take over the world! | 16:12 |
| ogra_ | +1 | 16:13 |
| fgimenez | elopio, i've seen something similar when executing commands at the same time that snappy-autopilot was doing its thing, don't know if it's applicable here | 16:14 |
| fgimenez | have a nice evening everyone o/ | 16:17 |
| sergiusens | elopio: disable autopilot | 16:32 |
| === utlemming_away is now known as utlemming | ||
| ogra_ | *sniff* | 18:37 |
| * ogra_ sees the vido conferencing thread and notes that nobod even thought about snappy chatroom | 18:37 | |
| ogra_ | *video | 18:38 |
| ogra_ | ToyKeeper, did the MAC address fix work for you ? | 18:38 |
| * ogra_ needs to get some additional data from other RPis | 18:38 | |
| ToyKeeper | ogra_: Yes, it did. Thanks. :) | 18:38 |
| ToyKeeper | ogra_: I tried the snappy chatroom, actually. :) | 18:39 |
| ogra_ | could you tell me your MAC ? | 18:39 |
| ToyKeeper | b8:27:eb:ec:38:8d | 18:39 |
| ogra_ | i'm not sure it is actually unique (i only have one Pi) | 18:39 |
| ogra_ | damn ! | 18:40 |
| ToyKeeper | Same? | 18:40 |
| ogra_ | yeah | 18:40 |
| * ogra_ will need to talk to the Pi people then ... seems this one is hardcodd into u-boot ... we need the start.elf to hand us the actual info | 18:40 | |
| ogra_ | ToyKeeper, chatroom is likely not for connferencing with customers indeed ... but every time that discussion comes up i wonder why people dont just run a snappy cloud instance and use it :) | 18:41 |
| ToyKeeper | I showed it to Samantha to make a point, and she was quite impressed that "that little thing" could host a video-conferencing service. | 18:42 |
| ogra_ | :D | 18:42 |
| ToyKeeper | (she's trying to find a service to use for a network of private support groups for her nonprofit) | 18:42 |
| ogra_ | well, in fact your browser hosts it (but dont tell her) :) | 18:42 |
| ogra_ | the snappy part is only establishing the connections | 18:43 |
| ogra_ | (and serving the website indeed) | 18:43 |
| ToyKeeper | BTW, any suggestions for a relatively easy way to build binaries for the orange box? | 18:47 |
| ogra_ | plars, hmm, i think the beagle guys took some effort to make latest beagles not require the S2 button after you booted from the SD once | 18:47 |
| ToyKeeper | I'm pondering possibly setting up a lxc host configured to cross-compile, or maybe running a native build environment under docker on the box itself. | 18:47 |
| ogra_ | the easiest is using qemu-debootstrap to just create an armhf chroot ... but not as fast as real cross compiling | 18:48 |
| plars | ogra_: yeah, I really don't want it to behave like that though | 18:48 |
| ogra_ | plars, but thats upstreams default | 18:48 |
| ogra_ | we should better deal with it instrea of reverting it | 18:48 |
| plars | ogra_: I have a modified emmc image that fixes this for the most part | 18:48 |
| ogra_ | *instead | 18:48 |
| plars | ogra_: that way we can test snappy without having to mess with the snappy image | 18:49 |
| ogra_ | plars, well, but that way we break fixes that upstream did to their default board setup | 18:49 |
| plars | ogra_: the patch that zyga sent for set the bootpart is useful regardless of what I'm trying to do, since it helps deal with the fact that you don't know what's on the emmc | 18:50 |
| ogra_ | i wouldnt want to do that for the general public | 18:50 |
| plars | ogra_: no, the image I'm running is just for me | 18:50 |
| ogra_ | what if they want to go back to their default debian image | 18:50 |
| plars | ogra_: that's the point, you can't do that in any automated way if you have an sd card in there | 18:50 |
| plars | ogra_: the only way to do it is to eject the sd card right now | 18:50 |
| plars | ogra_: I want a way to get back to the image running on the emmc even if there's something in the sd slot | 18:51 |
| ogra_ | right, i just got stuck on "I can reliably boot into the emmc when s2 is not held down, and boot to the sd card when it is held down." ... that sounds like you always need to press the button now | 18:51 |
| ogra_ | which is not upstreams behavior | 18:51 |
| plars | ogra_: ah, sorry. that's *only* if you are running my emmc imge | 18:51 |
| ogra_ | it stores the info if you pressed that button and keeps the setting | 18:51 |
| plars | *image | 18:51 |
| ogra_ | ah, cool then | 18:52 |
| ogra_ | zygas case is different because he completely zeroed the MMC | 18:52 |
| plars | ogra_: the funny thing right now, is with the default debian image, you can boot snappy without ever touching s2 | 18:52 |
| ogra_ | (including the preinstalled bootloader) | 18:52 |
| plars | ogra_: and if you just boot with the snappy sd card, it loads uboot off the emmc and boots the sd card with it - so you could break uboot in the snappy image and nobody would know most likely | 18:53 |
| ogra_ | heh, yeah | 18:53 |
| ogra_ | well, the fix is fine then | 18:54 |
| plars | ogra_: right, zyga's patch is useful because we currently assume that the user is running the stock debian image. But if they've replaced it, or destroyed it in some weird way, then snappy won't boot | 18:54 |
| ogra_ | it was just that sentence that made me wonder | 18:54 |
| ogra_ | yup | 18:54 |
| plars | ogra_: sorry for the confusion, I was mostly just trying to add that I had tested it, and it does not even interfere with my automation plans :) | 18:54 |
| ogra_ | plars, np | 18:55 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| n00b | hi there | 19:03 |
| ogra_ | yo | 19:07 |
| === conyoo is now known as aux|con|AW | ||
| === aux|con|AW is now known as conyoo | ||
| === conyoo is now known as cony|beer | ||
| kgunn | jdstrand: hey, just wanna clarify something...i saw where if you goof with apparmor policy and install same snap version you need to | 21:24 |
| kgunn | sudo aa-profile-hook | 21:25 |
| kgunn | to regenerate the profile, but for seccomp, is there something similar | 21:25 |
| kgunn | or is if fine to just keep adding to the list and installing | 21:25 |
| kgunn | ....and do i even have to build the snap? or can is there a file i can modify in place on the filesystem (to cut down on the build/install time) | 21:26 |
| === joshh20- is now known as joshh20 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!