| rsalveti | sergiusens: there should be a new image for both rolling and 15.04 | 00:28 |
|---|---|---|
| rsalveti | including your changes | 00:28 |
| rsalveti | sergiusens: do we need any extra udf change for azure or is it going to consume the grub data from the rootfs? | 00:28 |
| sergiusens | rsalveti: I already tested in the card | 00:33 |
| sergiusens | rsalveti: https://trello.com/c/YkdrYyX6/79-rootdelay-300-for-azure-images | 00:34 |
| rsalveti | oh, great | 00:34 |
| rsalveti | sergiusens: for udf just do one of the options slangasek gave and we should be fine | 00:34 |
| sergiusens | rsalveti: I'm going with this one http://paste.ubuntu.com/11659708/ | 00:36 |
| rsalveti | great, easy enough | 00:36 |
| sergiusens | slangasek: rsalveti I think it needs manual intervention still http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 01:38 |
| sergiusens | delete the powerpc binaries I guess | 01:38 |
| rsalveti | right, hopefully slangasek can give us a hand with that | 01:42 |
| slangasek | sergiusens, rsalveti: correct; looking at it now | 02:00 |
| slangasek | binaries removed | 02:01 |
| trey-gordon | qrl? | 03:59 |
| trey-gordon | hello? | 04:00 |
| tbr | good moaning | 04:01 |
| trey-gordon | how can I begin porting snappy to my desktop | 04:02 |
| trey-gordon | not like running it virtualized, but actually standalone, with mir or something | 04:03 |
| pitti | Chipaca: replied to the MP, LGTM | 04:44 |
| seb128 | hey there, does anyone know how to build a working image from device and rootfs tarballs? | 07:03 |
| mvo_ | seb128: ubuntu-device-flash will do that, but it will use the system-image server, so it needs to be imported there first | 07:04 |
| seb128 | mvo_, no way to do that locally? | 07:04 |
| seb128 | mvo_, we got a working desktop-next build | 07:05 |
| seb128 | mvo_, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29166 | 07:05 |
| mvo_ | seb128: that is a good question | 07:05 |
| seb128 | not sure what to do from the generated files though now ;-) | 07:05 |
| mvo_ | seb128: sergiusens will know if thats possible to do it locally you could shove it into system-image (create a temp channel or something) | 07:06 |
| seb128 | mvo_, well *I* can't I guess, somebody needs to do it for me | 07:08 |
| seb128 | but it's not very handy for local testing | 07:08 |
| mvo_ | seb128: agreed | 07:09 |
| seb128 | mvo_, when is sergiusens usually online? | 07:09 |
| mvo_ | seb128: sergio will be around in ~4h or so | 07:09 |
| seb128 | k, thanks | 07:09 |
| dholbach | good morning | 07:17 |
| seb128 | hey dholbach | 07:18 |
| seb128 | dholbach, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29166 for you | 07:18 |
| dholbach | thanks seb128! :) | 07:18 |
| dholbach | popey, ^ | 07:18 |
| seb128 | dholbach, here is a first working personnal build, good luck trying to make an image from it to put on a device :p | 07:18 |
| seb128 | dholbach, joke aside, waiting for sergiusens now to see how to transform those tarballs in an img that one can dd to a stick | 07:19 |
| dholbach | cool | 07:19 |
| fgimenez | good morning | 07:23 |
| dholbach | hi fgimenez, hi willcooke | 07:24 |
| fgimenez | hey dholbach | 07:25 |
| willcooke | hi dholbach | 07:28 |
| mvo_ | seb128: we need to talk about how we can share code, I am about to fix a bug in one of the hook scripts for ubuntu core and you will have to do exactly the same fix - maybe you can simplify symlink for hooks that are unchanged? | 07:39 |
| dholbach | mvo_, which ppa am I supposed to be using, is it beta? | 07:39 |
| dholbach | with beta I get this: | 07:39 |
| dholbach | ubuntu-snappy : Hängt ab von: ubuntu-snappy-cli (= 1.0.1-0ubuntu1build1) aber 1.0.1-1+439~ubuntu15.04.1 soll installiert werden | 07:39 |
| mvo_ | dholbach: yeah ppa:snappy-dev/beta (confusing, right) | 07:39 |
| mvo_ | dholbach: please only install ubuntu-snappy-cli | 07:39 |
| dholbach | ok | 07:39 |
| fgimenez | good morning mvo_, have a minute? | 07:54 |
| mvo_ | fgimenez: sure | 07:54 |
| mvo_ | fgimenez: good morning! | 07:54 |
| fgimenez | mvo_, :) i'm getting today this output from u-d-f http://paste.ubuntu.com/11666666/ | 07:55 |
| fgimenez | mvo_, not sure if it may be related to some misconfiguration on my side? | 07:56 |
| mvo_ | fgimenez: *ick* let me see if I can reproduce. what version of ubuntu-device-flash are you using right now? I wonder if there was a new version recently | 07:57 |
| mvo_ | fgimenez: this looks a lot like "upstream" | 07:57 |
| mvo_ | fgimenez: I'm curious about the version and the ppa you use so that I can try to figure out more | 07:57 |
| seb128 | mvo_, yeah, symlink would make sense, Colin had some comments about that on the merge request for desktopnext, unsure why didrocks didn't do it though | 07:58 |
| fgimenez | mvo_, http://paste.ubuntu.com/11666692/ no ppa, just wily | 07:58 |
| mvo_ | fgimenez: aha, I think thats the culprit then, hold on a sec, Chipaca fixed this probably but u-d-f will need a rebuild | 07:59 |
| fgimenez | mvo_, ok thx! can i use some ppa in the meantime? | 08:00 |
| mvo_ | fgimenez: yes - https://launchpad.net/~snappy-dev/+archive/ubuntu/tools should work | 08:00 |
| mvo_ | fgimenez: I will do a rebuild in the meantime in wily | 08:01 |
| fgimenez | mvo_, ack, i'll try it thanks! :) | 08:02 |
| mvo_ | fgimenez: uploaded, should be in the archve later today | 08:05 |
| mvo_ | (the fix) | 08:05 |
| fgimenez | mvo_, mm i'm not able to install the package from the ppa, it seems that there was a problem with the build https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/+packages | 08:15 |
| fgimenez | mvo_, this is what i get from apt-get update after adding the ppa repository http://paste.ubuntu.com/11666876/ | 08:18 |
| mvo_ | fgimenez: one sec, let me see if I ca nfix it | 08:29 |
| fgimenez | mvo_, thx, no rush at all | 08:34 |
| mvo_ | fgimenez: should be in the ppa now | 08:35 |
| mvo_ | fgimenez: well, might take some minutes until its published but I copied it to the wily pocket now | 08:36 |
| longsleep | Morning folks, maybe now somebody here to point me to the head tree of Apparmor3 / latest version / patches? | 08:48 |
| JamesTait | Good morning all; happy Cars Day! 😃 | 08:49 |
| ogra_ | asac, FYI http://paste.ubuntu.com/11667823/ (needed a depmod run, i need to see why thats not in the package) | 09:03 |
| fgimenez | mvo_, ok, i have u-d-f 0.22-1+177~ubuntu15.04.1 properly installed :) but i'm still getting the same error http://paste.ubuntu.com/11667736/ | 09:05 |
| ogra_ | hmm, owncloud has a broken icon in webdm | 09:06 |
| asac | ogra_: phenomenal :) ... yay! | 09:06 |
| asac | just ping me and ricmm when the new image up :) | 09:06 |
| asac | that works great | 09:06 |
| ogra_ | how do i test it ? i have never used owncloud | 09:06 |
| asac | thanks so much | 09:06 |
| mvo_ | fgimenez: meh, ok, let me try harder | 09:06 |
| asac | just check the website is working | 09:06 |
| ogra_ | on which port ? webdm doesnt show any info | 09:07 |
| ogra_ | oh | 09:07 |
| * ogra_ notes 80 in the docker cmdline | 09:07 | |
| ogra_ | bah, lies | 09:07 |
| ogra_ | aha 443 works | 09:09 |
| ogra_ | nice ! | 09:10 |
| mvo_ | fgimenez: hm, odd. this appears to be working for me (wily with u-d-f from ppa:snappy-dev/tools). anything unusual on your system? ecryptfs? tmpfs for /tmp or anything that you could think of thats might give a clue? | 09:10 |
| fgimenez | mvo_, nothing special, this was working as of yesterday | 09:13 |
| mvo_ | fgimenez: ok, maybe you can downgrade to the version in ppa:snappy-dev/beta? thats 0.20-something ? and then we tak to sergiusens if he has a idea | 09:14 |
| longsleep | ogra_: can you point me to the git tree i should use for backporting Apparmor3 to my kernel. I would use http://kernel.ubuntu.com/git/jj/ubuntu-vivid.git/log/?h=apparmor , but the tree at http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_odroidc seems to contain a bunch of additional patches. Any idea? | 09:15 |
| jjohansen | longsleep: it needs the additional patches | 09:15 |
| jjohansen | well the backport does | 09:15 |
| longsleep | jjohansen: Thanks! But where do they come from? | 09:16 |
| fgimenez | mvo_, ok thanks | 09:16 |
| ogra_ | longsleep, well, i always used ppisati's tree for that | 09:16 |
| ogra_ | git clone -b snappy_odroidc git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git | 09:16 |
| ogra_ | (see http://people.canonical.com/~ogra/snappy/odroidc/README) | 09:16 |
| jjohansen | how the apparmor backport works, is it starts with the base apparmor patchset and then on top of that the backport patches are applied | 09:16 |
| longsleep | ogra_: Right, but i would prefer to understand where the patches actually come from first. | 09:16 |
| ogra_ | but i guess that has fallen behind a bit | 09:16 |
| ogra_ | longsleep, that you have to ask ppisati ... i was only a consumer of his tree | 09:17 |
| jjohansen | yes we need to update the backports kernel tree, I just haven't found the time to do it yet | 09:17 |
| ogra_ | (for my first tests i used unpatched BSP kernels, he added the magic for me) | 09:17 |
| longsleep | jjohansen: all right, so the source is somewhere internal for eg apparmor: 3.12 backport mtd: Move major number f83c3838 | 09:17 |
| jjohansen | longsleep, give me a sec, I have a repo that is the basis of those patches | 09:19 |
| jjohansen | and yes it needs to be updated as well | 09:19 |
| jjohansen | longsleep: http://kernel.ubuntu.com/git/jj/ubuntu-utopic.git/ | 09:21 |
| * longsleep takes a look | 09:21 | |
| jjohansen | you can see there are android kernel branches like goldfish-aa3-backport | 09:21 |
| longsleep | yes | 09:21 |
| jjohansen | and goldfish-aa3-presquash | 09:21 |
| longsleep | so in some of these branches are the backport fixes? | 09:21 |
| jjohansen | the presquash branches have the backport patches split out | 09:22 |
| longsleep | got it - awesome thanks | 09:22 |
| jjohansen | yes, you can see the individual changes, and they document which kernel changes they are adjusting for | 09:22 |
| longsleep | i guess i can use that | 09:22 |
| longsleep | this means i grab apparmor3 rc1 tag, and the additional patches with numbers greated than the kernel i base on correct? | 09:23 |
| jjohansen | longsleep: updating this to a new better tree against an updated 3.1 kernel is on my todo list | 09:23 |
| jjohansen | longsleep basically | 09:23 |
| longsleep | jjohansen: thanks - i guess i have an idea now. Lets see how it goes :) | 09:24 |
| jjohansen | how I usually do a backport, is take the whole apparmor dir with the snapshot I want, say from ubuntu-vivid | 09:24 |
| jjohansen | just copy the whole dir, over the old apparmor dir, and git add it | 09:24 |
| jjohansen | that avoids all kinds of merge conflicts | 09:24 |
| longsleep | jjohansen: yes that is how the docs suggest to do it too. | 09:24 |
| dholbach | mvo_, should I be worried: http://pastebin.ubuntu.com/11667946/? | 09:25 |
| jjohansen | then I apply the backport patches on top, working my way backwards | 09:25 |
| longsleep | jjohansen: meaning you start with newer patches first? | 09:25 |
| jjohansen | backwards as in 2.10, then 2.9, then 2.8 backport patches, it is the order that the presquash trees use | 09:25 |
| jjohansen | yes | 09:26 |
| mvo_ | dholbach: it sounds alarming, but should be ok | 09:26 |
| longsleep | all right that is really helpful stuff | 09:26 |
| jjohansen | longsleep look at the commit messages for the backborts it will be things like revert 2.10 xxx | 09:26 |
| mvo_ | dholbach: its the error that there is a clickpkg user already | 09:26 |
| dholbach | I don't know... | 09:27 |
| dholbach | do you need a bug for it or should I ignore it? | 09:27 |
| jjohansen | longsleep: so if you backport to 3.2 you will have a longer patch list than say going back to 3.10 | 09:27 |
| mvo_ | dholbach: either is fine, feel free to file a bug | 09:27 |
| longsleep | jjohansen: yes i see that. I need to get the stuff in Kernel 3.10 - so there are only two required as i can see | 09:27 |
| dholbach | thanks mvo_, will do | 09:27 |
| mvo_ | ta | 09:28 |
| jjohansen | longsleep: hrmm, well that depends on where you start from, vivid and wily have one more patch that needs reverted, I haven't done a backport for that yet | 09:29 |
| longsleep | jjohansen: does it matter where i start from, or can i start say from trusty as well? | 09:29 |
| jjohansen | longsleep: vivid and wily are the same, vivid is almost the same as utopic and utopic is a big step over trusty | 09:31 |
| longsleep | jjohansen: ok - a big step for apparmor? But for snappy i it should be vivid/wily ? | 09:31 |
| dholbach | mvo_, bug 1463329 | 09:31 |
| ubottu | bug 1463329 in ubuntu-snappy (Ubuntu) "/nonexistent does not exist, system user clickpkg exists" [Undecided,New] https://launchpad.net/bugs/1463329 | 09:32 |
| jjohansen | longsleep: yes for snappy I would start from vivid/wily. | 09:32 |
| longsleep | jjohansen: all right - i have the plan then. | 09:33 |
| jjohansen | longsleep: if you can wait a day I will try to get a vivid and wily backport up today | 09:33 |
| longsleep | jjohansen: yeah - i will continue to work on it tonight CEST | 09:33 |
| longsleep | by the way, i suggest that 3.10 upstream Kernel should be a default backport target for apparmor3 as many ARM device Kernel trees are based on 3.10. | 09:37 |
| jjohansen | yep | 09:38 |
| ogra_ | sergiusens, hmm, is there a way to disable autopilot from u-d-f ? that would really be handy when building for unsupported arches | 09:40 |
| longsleep | ogra_: i learned you can disable it in the oem snap. | 09:44 |
| ogra_ | oh | 09:44 |
| longsleep | ogra_: just add autopilot: off to ubuntu-core section or something | 09:45 |
| longsleep | cant remember the exact details | 09:45 |
| longsleep | ogra_: autopilot: false it was | 09:46 |
| longsleep | ogra_: below ubuntu-core tree in config section of package.yaml | 09:47 |
| pitti | hm, what am I doing wrong with u-d-f? http://paste.ubuntu.com/11668527/ | 09:54 |
| ogra_ | pitti, looks like the wily bug with go i hit yesterday | 09:55 |
| ogra_ | are you running that on wily ? | 09:55 |
| pitti | yes | 09:55 |
| ogra_ | that might be it then | 09:55 |
| mvo_ | dholbach: ta | 09:55 |
| pitti | . o O { is there anything else? } :) | 09:55 |
| ogra_ | someone said wily's go is screwed | 09:55 |
| pitti | ogra_: ah, I'll try u-d-f from vivid then? | 09:55 |
| ogra_ | yeah | 09:56 |
| pitti | thanks ogra | 09:56 |
| pitti | ogra_: that fails differently | 09:58 |
| ogra_ | weird | 09:58 |
| pitti | 2015-06-09 09:57:48 ERROR snappy logger.go:199 generic-amd64 failed to install: snappy package not found | 09:58 |
| pitti | generic-amd64 failed to install: snappy package not found | 09:58 |
| ogra_ | it should be self contained i thought | 09:58 |
| pitti | the "snappy" command exists | 09:58 |
| ogra_ | oh, you might also need the snappy from vivid | 09:58 |
| pitti | (I opened a schroot and installed u-d-f | 09:58 |
| ogra_ | it is go as well :) | 09:59 |
| pitti | ah, not just ubuntu-snappy-cli then | 09:59 |
| pitti | hm, not the "snappy" package for sure | 10:00 |
| pitti | mvo_: ok, if you can tell me how one creates a snappy image these days, I'll look at bug 1462954 | 10:01 |
| ubottu | bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged] https://launchpad.net/bugs/1462954 | 10:01 |
| fgimenez | mvo_, i've finally got u-d-f working pheww :) it was related to the version of ubuntu-snappy-cli in wily | 10:02 |
| fgimenez | mvo_, downloading and installing it from here http://packages.ubuntu.com/vivid/ubuntu-snappy-cli works again, don't ask me why :) | 10:03 |
| pitti | fgimenez: oh, you have that problem as well? how did you flash snappy? | 10:05 |
| pitti | fgimenez: (see my backscroll from 5 mins ago) | 10:05 |
| pitti | fgimenez: so that's u-d-f from wily plus ubuntu-snappy-cli from vivid? | 10:06 |
| fgimenez | pitti, i was unable to use u-d-f in wily, this was the error http://paste.ubuntu.com/11667736/ | 10:06 |
| pitti | fgimenez: yep, exactly what I got and asked | 10:06 |
| fgimenez | pitti, yep, ubuntu-snappy-cli 1.0.1-0ubuntu1build1 seems to be somehow broken | 10:06 |
| pitti | fgimenez: I tried u-d-f (and u-snappy-cli) from vivid, and that fails too | 10:07 |
| fgimenez | pitti, unstalling u-snappy-cli and installing vivid's deb worked for me | 10:07 |
| pitti | I still get "generic-amd64 failed to install: snappy package not found" | 10:10 |
| pitti | grep -r 'package not found' in goget-ubuntu-touch doesn't have any results | 10:13 |
| fgimenez | pitti, it seems to be a different error, mine was "generic-amd64 failed to install: unpack /tmp/generic-amd64310762128 to /tmp/oem535521461/oem/generic-amd64/1.1.1 failed with exit status 1" | 10:13 |
| pitti | fgimenez: right, I got that with wily's ubuntu-snappy-cli, now I downgraded to vivid's | 10:14 |
| pitti | ok, I installed parted and ca-certificates, and now it's "generic-amd64 failed to install: exit status 2" | 10:16 |
| Chipaca | pitti: what're you doing? | 11:01 |
| pitti | Chipaca: I'm trying to build a snappy VM image with u-d-f | 11:01 |
| Chipaca | pitti: which u-d-f are you using? | 11:01 |
| sergiusens | ogra_: needs to be in the oem config | 11:02 |
| pitti | Chipaca: first I tried wily's, which fails with //paste.ubuntu.com/11667736/ (for ogra, fgimenez and me) | 11:02 |
| pitti | Chipaca: then I tried in vivid, where it first failed with "generic-amd64 failed to install: snappy package not found" | 11:02 |
| Chipaca | sergiusens: is wily's u-d-f the same as the tools ppa's? | 11:02 |
| pitti | Chipaca: then I installed parted and ca-certificates which got it a bit further, but now it fails with "exit status 2"; that's even with --verbose | 11:03 |
| sergiusens | Chipaca: no, it was let through last night | 11:03 |
| Chipaca | pitti: you need the tools ppa's one, i guess | 11:03 |
| sergiusens | Chipaca: what fails is snappy unpack which is using go 1.4 | 11:03 |
| Chipaca | certainly on vivid | 11:03 |
| Chipaca | sergiusens: but that's fixed | 11:03 |
| pitti | it used to work with vivid's version a few months ago (when vivid was still devel) | 11:03 |
| sergiusens | Chipaca: in wily? | 11:03 |
| sergiusens | Chipaca: as in, in wily with no ppa? | 11:04 |
| Chipaca | sergiusens: oahdunno | 11:04 |
| Chipaca | sergiusens: but it was failing with vivid's too | 11:04 |
| pitti | ok, which PPA should I add? | 11:05 |
| Chipaca | pitti: i don't think it's ever worked with vivid's since i've been on the project | 11:05 |
| Chipaca | pitti: which is... ok, a few months, but with few > 3 i think | 11:05 |
| pitti | it seemed to work for fgimenez to use vivid's ubuntu-snappy-cli, but I suppose u-d-f is missing a dependency or so | 11:05 |
| pitti | for sure it's missing parted and ca-certificates | 11:05 |
| ogra_ | pitti, not for me, i had the snappy errors on a wily image | 11:05 |
| Chipaca | $ cat /etc/apt/sources.list.d/snappy-dev-ubuntu-tools-vivid.list | 11:05 |
| Chipaca | deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu vivid main | 11:05 |
| pitti | is there a --verboserer? | 11:05 |
| Chipaca | pitti: ^^ | 11:05 |
| pitti | Chipaca: thanks | 11:06 |
| ogra_ | (i build my images on a trusty machine ... so i have no build issues here) | 11:06 |
| sergiusens | pitti: ca-certificates yes, parted no http://paste.ubuntu.com/11669751/ | 11:06 |
| sergiusens | hmm, ubuntu-snappy-cli also misses the dep on ca-certificates | 11:07 |
| fgimenez | Chipaca, sergiusens pitti in my case downgrading ubuntu-snappy-cli from 1.0.1-0ubuntu1build1 (wily) to 1.0.1-0ubuntu1 (vivid) worked, tested with u-d-f from the archive and from the ppa | 11:08 |
| sergiusens | fgimenez: thanks for confirming | 11:08 |
| pitti | 2015-06-09 11:08:41 ERROR snappy logger.go:199 generic-amd64 failed to install: exit status 2 | 11:08 |
| pitti | still the same with the PPA | 11:08 |
| pitti | $ sudo ubuntu-device-flash core --output=/tmp/snappy.img --developer-mode --channel=edge rolling | 11:09 |
| sergiusens | mvo_: can you release a new ubuntu-snappy into wily? | 11:09 |
| pitti | same with "--channel=stable 15.04" | 11:09 |
| davidcalle | ogra_, hello, do you want us to start updating the raspi2 section with your image on https://developer.ubuntu.com/en/snappy/start/ or do you think it's better to wait a little for user feedback? | 11:09 |
| pitti | is there a $DEBUG/--debug or so? | 11:09 |
| sergiusens | pitti: only --verbose: u-d-f --verbose core rolling ... | 11:10 |
| ogra_ | davidcalle, we should wait for the actual release ... i also plan to push it to http://people.canonical.com/~platform/snappy/ instead of hosting it in my homedir | 11:10 |
| pitti | sergiusens: I have that already, but it doesn't say much, just http://paste.ubuntu.com/11669805/ | 11:10 |
| davidcalle | ogra_, actual release as in "official image"? | 11:11 |
| sergiusens | pitti: but I suspect you are going to have issues with ubuntu-snappy-cli | 11:11 |
| ogra_ | davidcalle, as in the 15.04.1 release for the rest of the world :) | 11:11 |
| davidcalle | ogra_, yay :) | 11:11 |
| gatisp | Hello, I was wondering could somebody clarify steps 2 and 3 from https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/#updating-the-system | 11:11 |
| ogra_ | davidcalle, BBB and amd64 images will soon have a point release | 11:11 |
| sergiusens | seb128: I'm online | 11:11 |
| gatisp | "Apply the latest system image to the other root partition." | 11:11 |
| gatisp | I assumed the only time when this can be done is from initramfs during boot? because you have to remount read-only partition to read-write | 11:12 |
| gatisp | is that correct? | 11:12 |
| pitti | [pid 21480] connect(3, {sa_family=AF_LOCAL, sun_path="/run/udev/control"}, 19) = -1 ENOENT (No such file or directory) | 11:12 |
| pitti | [pid 21480] close(3) = 0 | 11:12 |
| ogra_ | gatisp, that is how it works, yes | 11:12 |
| pitti | [pid 21480] exit_group(2) = ? | 11:12 |
| longsleep | pitti: why did you repeat the same comment on bug 1462954 ? | 11:12 |
| ubottu | bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged] https://launchpad.net/bugs/1462954 | 11:12 |
| pitti | sergiusens: ^ ah, this might be it? it used to work in a schroot, but maybe not any more | 11:12 |
| sergiusens | seb128: mvo_ no easy mechanism for local testing, but livecd-rootfs local building isn't easy to do either | 11:13 |
| pitti | longsleep: sorry, pressed enter accidentally, and firefox still had my last reply in the input box | 11:13 |
| longsleep | pitti: ah - i was just wondering if i was wrong about the problem. | 11:13 |
| gatisp | ogra_, ok but then docs are are bit confusing, at least when I read it :) because the next steps says "Update the bootloader configuration such that the next boot.." | 11:13 |
| gatisp | ogra_, but what it actually means is not the next boot | 11:14 |
| gatisp | but the ongoing boot? | 11:14 |
| ogra_ | gatisp, after "flashing" the bootloader needs to be told to bot from the new partition | 11:14 |
| ogra_ | *boot | 11:14 |
| gatisp | ogra_, but doesn't all the happen from the same boot sequence? | 11:15 |
| ogra_ | no | 11:15 |
| ogra_ | oh, wait, the unpacking on upgrade doesnt actually happen from the initrd ... that happens indeed from the running system before the reboot | 11:16 |
| ogra_ | (sorry, my brain was thinking phone updates :) ) | 11:16 |
| sergiusens | ogra_: we have inOS updates here | 11:17 |
| ogra_ | yeah | 11:17 |
| gatisp | so it unpacks in some read-write partition first? | 11:17 |
| sergiusens | gatisp: it's like solaris' live upgrade mechanism | 11:17 |
| ogra_ | it uses three partitions | 11:17 |
| ogra_ | a is the one you run from ... readonly | 11:17 |
| ogra_ | then you have a rw partition for all the writable bits you need | 11:17 |
| ogra_ | and then there is b ... b is unmounted when you run from a | 11:18 |
| ogra_ | so you can mount it and unpack your stuff | 11:18 |
| ogra_ | then tell the bootloader about that and reboot | 11:18 |
| sergiusens | ogra_: it's actually mounter in /writable/cache/system (we are getting rid of 'cache' in that path though) | 11:18 |
| ogra_ | ah, i didnt know | 11:19 |
| ogra_ | i thought we dynamically mount it | 11:19 |
| pitti | Chipaca, sergiusens: FTR, bind-mounting /run into the schroot helped; now it's working (in vivid) | 11:19 |
| * pitti pats strace | 11:19 | |
| Chipaca | pitti: ot1h, awesome; otoh, why didn't it work wihtout that? | 11:20 |
| gatisp | ok, that clarifies some things, in me head I saw A and B both mounted as read-only at all times when system is running | 11:20 |
| pitti | Chipaca: I don't know; it used to a few months ago, but not any more | 11:20 |
| gatisp | sergiusens, "/writable/cache/system" is that part open sourced somewhere? | 11:21 |
| sergiusens | gatisp: what does "open sourced" somewhere mean? | 11:21 |
| gatisp | I mean can I see that code :) | 11:22 |
| sergiusens | gatisp: lp:snappy | 11:22 |
| gatisp | where is that? its my first time here | 11:22 |
| ogra_ | bzr branch lp:snappy | 11:23 |
| sergiusens | gatisp: http://launchpad.net/snappy | 11:23 |
| ogra_ | running that on an ubuntu system gets you the source | 11:23 |
| gatisp | ok, thanks, I will take a look | 11:23 |
| ogra_ | (or use a browser to browse it with sergiusens' url) | 11:23 |
| sergiusens | ogra_: I bet if someone doesn't know what lp: is, less they know of bzr :-P | 11:23 |
| ogra_ | true true | 11:24 |
| sergiusens | these days they are equivalent to the sme thing :-) | 11:24 |
| pitti | longsleep: indeed, works perfectly when touching the file, thanks! (<- mvo) | 11:24 |
| Chipaca | sergiusens: otoh, typing bzr will tell you how to get it | 11:24 |
| sergiusens | Chipaca: if you are on ubuntu ;-) | 11:24 |
| Chipaca | sergiusens: no other operating system exists | 11:24 |
| sergiusens | Chipaca: what phone do you use again? ;-) | 11:25 |
| Chipaca | sergiusens: an ubuntu phone of course | 11:25 |
| * Chipaca hides his android | 11:25 | |
| * ogra_ shakes head | 11:26 | |
| * Chipaca ides ogra_'s android too | 11:26 | |
| Chipaca | hides* | 11:26 |
| Chipaca | i'm going to have to change this keyboard soon. or maybe my fingers. | 11:26 |
| Chipaca | anyway! back to work | 11:27 |
| ogra_ | i havent run any android in about a year now :) | 11:27 |
| Chipaca | ogra_: you are a better person than i | 11:27 |
| ogra_ | i just dont get along with it anymore after using the ubuntu phone for a while | 11:28 |
| ogra_ | the UX feels so clunky | 11:28 |
| ogra_ | and swiping from the right never does what i expect ! | 11:28 |
| Chipaca | yep | 11:29 |
| sergiusens | ogra_: _1 | 11:29 |
| sergiusens | +1 I meant | 11:29 |
| ogra_ | heh | 11:29 |
| gatisp | I will have to buy Ubuntu phone, its about time to change my Nokia N9 :) | 11:30 |
| mvo_ | sergiusens: I did some update to your noUpdateGrub branch, did you already push your new grub.cfg somewhere? | 11:42 |
| mvo_ | sergiusens: I think thats the bit missing at this point :) | 11:43 |
| ogra_ | hmm our owncloud installation tells me to upgrade it | 11:44 |
| sergiusens | mvo_: only thing missing? | 11:49 |
| sergiusens | mvo_: sorry haven't checked my email yet, was dealing with irc first :-) | 11:50 |
| mvo_ | sergiusens: well, the transition too, but its looking promising | 11:56 |
| mvo_ | sergiusens: no worries, its not urgent at all | 11:56 |
| seb128 | sergiusens, hey | 11:56 |
| sergiusens | mvo_: looking now | 11:57 |
| sergiusens | seb128: hello | 11:57 |
| sergiusens | seb128: for s-i we should just get ubuntu-personal/rolling/edge in place, we are going to need it anyways | 11:57 |
| seb128 | sergiusens, we are trying to get a desktop snappy image going, we made cdimage build an image similar to the ubuntu-core one, see https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next | 11:58 |
| seb128 | sergiusens, well, wfm if you want, but being able to test locally would be convenient | 11:58 |
| sergiusens | seb128: you probably want cprov's branch | 11:59 |
| seb128 | sergiusens, what branch is that and what does it do? | 11:59 |
| sergiusens | seb128: https://code.launchpad.net/~canonical-ci-engineering/goget-ubuntu-touch/local_image/+merge/260531 | 11:59 |
| seb128 | sergiusens, thanks | 12:00 |
| sergiusens | seb128: I'm not sure it's working yet (given the WiP), the resulting tarball might need some massaging (e.g.; putting the rootfs into /system) | 12:00 |
| seb128 | sergiusens, any recommendation on what I can do with the tarballs from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29166 to test the output? | 12:02 |
| seb128 | sergiusens, or where/to who can I request ubuntu-personal/rolling/edge to be configured | 12:02 |
| cprov | sergiusens: seb128: it seems to work fine (so far), we mangle the rootfs to install packages from -proposed and josepht can help you with further tweaks | 12:02 |
| seb128 | cprov, thanks, see ^ for what I'm trying to do | 12:03 |
| cprov | seb128: yup, a 'personal' rootfs | 12:04 |
| seb128 | cprov, right :-) | 12:05 |
| rsalveti | morning | 12:05 |
| seb128 | hey rsalveti | 12:06 |
| rsalveti | hm, goget-ubuntu-touch ftbfs for all archs | 12:07 |
| rsalveti | seb128: hey! | 12:07 |
| gatisp | After running bzr branch lp:snappy | 12:08 |
| gatisp | go get -d -v launchpad.net/snappy/... | 12:08 |
| gatisp | I still don't see /writable/cache/system | 12:08 |
| sergiusens | rsalveti: that's in the ppa; I'm disabling that building now that wily is working | 12:08 |
| gatisp | sergiusens, ogra_ ^ am i missing some step? | 12:09 |
| rsalveti | sergiusens: ftbfs in the archive: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.22-0ubuntu3 | 12:13 |
| rsalveti | after mvo_ uploaded a new version | 12:14 |
| sergiusens | rsalveti: that's fine | 12:14 |
| sergiusens | rsalveti: this is why I wanted it updated in the archive, to play API change catchup ;) | 12:15 |
| rsalveti | sergiusens: how can a ftbfs be fine? :-) | 12:15 |
| sergiusens | rsalveti: I never asked you to rebuild u-d-f ;-) | 12:15 |
| rsalveti | haha, guess that happened yesterday already once you uploaded a newer version | 12:15 |
| sergiusens | oh, mvo_ that u-d-f rebuild isnt' needed | 12:16 |
| rsalveti | sergiusens: is this because of go 1.4? | 12:16 |
| sergiusens | mvo_: snappy unpack needed fixing and getting a rebuild of ubuntu-snappy-cli is enough for that | 12:16 |
| sergiusens | rsalveti: no, because lp:snappy has changed a lot with all the refactor that's going on | 12:16 |
| rsalveti | seb128: yeah, would also point you to the ci guys, since they have a way to use the rootfs (from live-build) when flashing with u-d-f | 12:17 |
| rsalveti | don't remember if we had an MR for it | 12:17 |
| sergiusens | rsalveti: already dealt with ;-) | 12:17 |
| rsalveti | seb128: the system-image server was also modifying the image, but ogra pushed the changes into the initrd now | 12:17 |
| rsalveti | just don't know if you're using the same initrd | 12:17 |
| sergiusens | rsalveti: but would be good for someone to setup ubuntu-personal/rolling/edge in any case | 12:17 |
| ogra_ | rsalveti, there was nothing to push for core ... only touch | 12:18 |
| rsalveti | ogra_: link for mtab? | 12:18 |
| ogra_ | that wasnt in the initrd :) | 12:18 |
| rsalveti | don't remember where you landed that :-) | 12:19 |
| ogra_ | livecd-rootfs | 12:19 |
| rsalveti | then seb128 should already be using that, I'd imagine | 12:19 |
| * ogra_ checks before talking nonsense | 12:19 | |
| ogra_ | yeah | 12:20 |
| ogra_ | 2.304 and 2.305 have the changes | 12:20 |
| rsalveti | cool then | 12:20 |
| ogra_ | mtab, /lib/modules, /lib/formware and /userdata|/writable (depending on the flavour) | 12:21 |
| ogra_ | *firm | 12:21 |
| rsalveti | seb128: and to auto import ubuntu-desktop-next in system-image I guess you'd need to ping slangasek | 12:22 |
| ogra_ | or sil2100 | 12:22 |
| seb128 | rsalveti, ok, thanks | 12:22 |
| rsalveti | mvo_: sergiusens: what is still missing to get https://bugs.launchpad.net/snappy/+bug/1462916 fixed for 15.04.1? | 12:24 |
| ubottu | Ubuntu bug 1462916 in Snappy 15.04 "Simplify TMPDIR handling" [High,In progress] | 12:24 |
| sergiusens | rsalveti: I'll defer to Chipaca | 12:24 |
| rsalveti | iirc this is the last standing bug we have | 12:25 |
| Chipaca | mvo_: with lp:~mvo/ubuntu-core-launcher/tmpdir-simplify-lp1462916 merged and the associated u-c-security also in, tmpdir handling is done, right? | 12:27 |
| Chipaca | rsalveti: (afaik it's done) | 12:28 |
| Chipaca | where done means 'on trunk' | 12:28 |
| rsalveti | Chipaca: guess that everything is pushed to trunk, but nothing released yet | 12:28 |
| Chipaca | not 'on 15.04' | 12:28 |
| rsalveti | right | 12:28 |
| Chipaca | mvo_: just checking with mvo_ who was tracking the whole thing, whether there are further branches for trunk | 12:28 |
| mvo_ | Chipaca: its done but not backported, let me do this now | 12:29 |
| Chipaca | mvo_: ok | 12:29 |
| Chipaca | mvo_: note i forked your branch and fixed it before merging | 12:29 |
| Chipaca | so you want to backport that :) | 12:29 |
| mvo_ | Chipaca: I noticed, thanks a bunch! | 12:29 |
| Chipaca | k | 12:29 |
| rsalveti | mvo_: it seems we need a release for both wily and 15.04.1 then, right? | 12:30 |
| mvo_ | rsalveti: maybe :) why for wily? I'm not sure I follow | 12:31 |
| mvo_ | rsalveti: or you mean the core-launcher upload? yes, indeed | 12:32 |
| rsalveti | mvo_: yeah | 12:32 |
| Chipaca | "release" and "wily" seem to be at ends | 12:32 |
| kyrofa | sergiusens, installing things using the webdm API is still broken here. I ran a "snappy rollback webdm" to try to get back to a working version (0.7 now), but now it's not running. Did I miss something? | 12:33 |
| rsalveti | package upload would probably be a better way to say what I wanted :-) | 12:33 |
| mvo_ | rsalveti: :) sorry, I'm a bit slow today, I will do both wily and vivid uploads | 12:33 |
| rsalveti | mvo_: haha, thanks :-) | 12:34 |
| rsalveti | mvo_: then once both are in the ppa we can finally trigger another image for our final RC | 12:34 |
| rsalveti | unless we find other issues | 12:34 |
| Chipaca | kyrofa: how is it broken? | 12:34 |
| rsalveti | and then ask utlemming to test it on the cloud side | 12:34 |
| sergiusens | kyrofa: hmm, it works fine here, I guess you hit one of the bugs that was fixed this week in snappy/ubuntu-core-launcher itself | 12:35 |
| kyrofa | sergiusens, oh! Yeah, you mentioned that earlier. Do I need to explicitly update ubuntu-core-launcher, then? | 12:36 |
| kyrofa | Chipaca, I'm getting stuff like this: ERROR snappy logger.go:199 xkcd-webserver.canonical failed to install: unpack /tmp/snaps/webdm/0.8/tmp/xkcd-webserver428488438 to /apps/xkcd-webserver.canonical/0.5 failed with exit status 1 | 12:36 |
| Chipaca | kyrofa: rolling edge? | 12:37 |
| kyrofa | Chipaca, yessir | 12:37 |
| Chipaca | looks like the snappy unpack with go 1.4 problem | 12:37 |
| Chipaca | that fix's landed, right? | 12:37 |
| * Chipaca checks | 12:37 | |
| Chipaca | yep, landed in 487 | 12:38 |
| Chipaca | kyrofa: it might not be in an image yet | 12:38 |
| Chipaca | kyrofa: mvo_ will address that in a moment | 12:38 |
| kyrofa | Chipaca, ah, very good! Okay, I'll hang out | 12:39 |
| Chipaca | kyrofa: meanwhile, you have the following workaround: go for a walkaround :-p | 12:39 |
| rsalveti | ogra_: wow, wonder why owcloud takes 10 minutes for the first start | 12:39 |
| kyrofa | Chipaca, ha! | 12:39 |
| rsalveti | kyrofa: unless you really need rolling/edge, please use 15.04/edge instead | 12:40 |
| Chipaca | kyrofa: or if you're in a hurry, you could build snappy from trunk and scp it in | 12:40 |
| ogra_ | rsalveti, it downloads a ton of stuff on first boot | 12:40 |
| ogra_ | s/boot/start/ | 12:40 |
| rsalveti | rolling/edge should be renamed to rolling/probably_broken | 12:40 |
| kyrofa | rsalveti, I don't actually. Back when I made it I needed rolling edge to get webdm. Is that no longer the case? | 12:40 |
| Chipaca | oh, wait | 12:40 |
| * Chipaca checks what he's running | 12:41 | |
| rsalveti | kyrofa: webdm is also available for 15.04 | 12:41 |
| Chipaca | sergiusens: you need to rebuild webdm for wily :-( | 12:41 |
| ogra_ | rsalveti, the package is also outdated ... i get a "please update to the new version" popup all the time ... | 12:41 |
| ogra_ | and the icon in webdm is broken | 12:41 |
| rsalveti | ogra_: oh, got it | 12:41 |
| Chipaca | sergiusens: (which is weird; why is it built with 1.4?) | 12:41 |
| rsalveti | who owns it? | 12:41 |
| ogra_ | kikinz i think | 12:42 |
| kyrofa | rsalveti, good deal, I'll do that | 12:42 |
| ogra_ | *kickinz | 12:42 |
| ogra_ | (at least thats where it downloads all the files from according to syslog) | 12:42 |
| rsalveti | ogra_: but nice to see the new image around, waiting for my rpi2 to test | 12:42 |
| rsalveti | right :-) | 12:42 |
| ogra_ | would be nice if something like "snappy install owncloud" would actually automatically install docker | 12:43 |
| ogra_ | instead of falling over with an error | 12:43 |
| tedg | +1, I think it'd be nice for list too, as then it'd look like we have more in the store on initial look. | 12:44 |
| mvo_ | ogra_: hm, you shouldn't even see owncloud if you don't have docker already | 12:44 |
| ogra_ | mvo_, i didnt run snappy list ... just executed "snappy install owncloud" after firts boot | 12:45 |
| ogra_ | so i'm not sure if it was actually offered | 12:45 |
| tedg | I think everything should be based on app snaps, whether or not they need frameworks is just a technical detail. | 12:45 |
| ogra_ | yeah | 12:45 |
| mvo_ | ogra_: heh, thats funny | 12:45 |
| mvo_ | ogra_: could you file a bug please? | 12:45 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| ogra_ | will do ... but let me verify it again | 12:46 |
| gatisp | ok, after installing vm I see /dev/sda3 on / as read-only and /dev/sda4 on /writable/cache/system as read-only. This is exactly what online docs say, that both system partitions are read-only. So they are remounted to read-write whenever needed? | 12:57 |
| sergiusens | Chipaca: what wrong with webdm being built with 1.4? | 12:57 |
| kyrofa | rsalveti, I downloaded the 15.04 image from the snappy page, and it does appear that webdm is installed, but it doesn't seem to be running. Previously, when I was on rolling, all I had to do was install webdm and snappyd was immediately on port 4200 | 12:57 |
| Chipaca | sergiusens: nothing, because unpack is still done with snappy itself, right? | 12:57 |
| sergiusens | Chipaca: exactly :-) | 12:58 |
| * sergiusens has been trying to say that to many people since days now | 12:58 | |
| Chipaca | then i don't understand why kyrofa's thing is failing | 12:58 |
| sergiusens | kyrofa: the image from the page has a webdm snap of type app, remove it and snappy install webdm again | 12:58 |
| rsalveti | kyrofa: hm, that's probably the old image | 12:58 |
| kyrofa | sergiusens, ah ha | 12:59 |
| rsalveti | try sudo ubuntu-device-flash core 15.04 --channel edge --enable-ssh --developer-mode --output x86.img | 12:59 |
| rsalveti | or similar | 12:59 |
| sergiusens | kyrofa: https://search.apps.ubuntu.com/api/v1/package/webdm (look at the release entry there) | 12:59 |
| rsalveti | kyrofa: the pre-built image is super old | 12:59 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| kyrofa | sergiusens, rsalveti ahh, now I'm up and running. Thanks guys :) | 13:02 |
| rsalveti | mvo_: should we also try fixing https://bugs.launchpad.net/snappy/+bug/1462954 ? | 13:15 |
| ubottu | Ubuntu bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged] | 13:15 |
| rsalveti | it seems we're just missing a touch at the right file, so it can be bind-mounted | 13:15 |
| longsleep | +1 | 13:16 |
| longsleep | by the way, on bug #1462954 - the random-seed is not the only file which cannot be bind-mounted because it is missing | 13:19 |
| nothal | Bug #1462954: systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only <Snappy:Triaged> <Snappy 15.04:Triaged> <Snappy trunk:Triaged> <http://launchpad.net/bugs/1462954> | 13:19 |
| ubottu | bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged] https://launchpad.net/bugs/1462954 | 13:19 |
| ogra_ | rsalveti, someone (pitti ?) said there would also be an ordering problem (the systemd unit starting before the mount) | 13:21 |
| rsalveti | ogra_: thought we'd be bind mounting at the initrd | 13:21 |
| pitti | no, this was just a conjecture; the file is simply missing, so it can't be bind-mounted | 13:21 |
| rsalveti | right | 13:22 |
| pitti | rsalveti: we don't (I thought that too, would be much more robust) | 13:22 |
| pitti | so we need to pre-create it; longsleep and I followed up to the bug | 13:22 |
| longsleep | initrd just writes to fstab as far as i understand it | 13:22 |
| rsalveti | yeah, that should be an easy fix | 13:22 |
| ogra_ | rsalveti, we dont, we fill the fstab and let systemd's fstab handler do the mounting (like we let mountall do it on phones) | 13:27 |
| ogra_ | initrd should only mount the very basic bits to get readonly and rw spaces | 13:27 |
| rsalveti | right | 13:28 |
| ogra_ | so if the random seed unit runs before the fstab one we have an issue | 13:28 |
| pitti | shouldn't though; that "runs too early" was a conjecture if those bind mounts were *not* in fstab | 13:29 |
| rsalveti | easy to check | 13:29 |
| ogra_ | (and i could imagine it does so you get proper encryption security for encrypted mounts) | 13:29 |
| pitti | if they are, the RequiresMountsFor= will take care of it | 13:29 |
| ogra_ | ok | 13:29 |
| ogra_ | i just think we culd have a catch22 here ... for encrypted mounts | 13:29 |
| ogra_ | (not sure we ever plan to support that for the rootfs) | 13:30 |
| rsalveti | eventually, yeah | 13:30 |
| pitti | why would we ever encrypt the root fs? | 13:31 |
| pitti | it's a publically available image, not exactly a secret | 13:31 |
| pitti | well, if we do, the initrd needs to unlock it, just like in a desktop install | 13:32 |
| pitti | that should be done by /usr/share/initramfs-tools/hooks/cryptroot as usual? | 13:32 |
| ogra_ | well, but if we want the persisitent entryopy from the file at this point we would have to mount from initrd | 13:33 |
| jdstrand | mvo_: it looks like you handled the ubuntu-core-security in the ppa for /tmp, so I will make sure that get incorporated into the eventual vivid sru (like the ppa1 version before it) | 13:33 |
| ogra_ | s/mount/bind mount/ | 13:33 |
| mvo_ | jdstrand: yeah, I was about to ask if I should propose a branch for this :) | 13:33 |
| ogra_ | pitti, people encrypt their swap partitions ... so why not the writable partition too :) | 13:33 |
| pitti | ogra_: hm, why do you need the seed in the initramfs for unlocking an encrypted device? | 13:33 |
| mvo_ | jdstrand: do you have a 15.04 branch or is there any other way that I can make your life easier? | 13:34 |
| pitti | ogra_: oh yes, encrypting the writable partition makes sense; I thought you literally meant the root partition | 13:34 |
| jdstrand | mvo_: nah. I need to prepare a branch for 15.04 still. I'll do that then just pull it in | 13:34 |
| ogra_ | pitti, dunno, for making use of it ? | 13:34 |
| mvo_ | rsalveti: if its just a touch we should be good, I add the file to the u-core-config now | 13:34 |
| jdstrand | I mean to do it with ppa1, but didn't | 13:34 |
| ogra_ | doesnt it help to have the entropy available = | 13:34 |
| ogra_ | ? | 13:34 |
| mvo_ | jdstrand: ok :) | 13:34 |
| pitti | ogra_: you mean for session keys? I suppose that will have to make do without seed init (and I guess it does, as that has worked for ages with encrypted root) | 13:35 |
| ogra_ | ah, k | 13:35 |
| pitti | ogra_: TBH I don't know whether luks uses random session keys | 13:35 |
| pitti | for sure you need proper randomness when creating a luks device | 13:35 |
| pitti | I thought at that ^ point you create "the" key, and then just encrypt it using the user password in one of the 8 luks key slots | 13:36 |
| pitti | it sounded quite deterministic to me | 13:36 |
| elopio | good morning. | 13:42 |
| elopio | fgimenez: have you been able to build the webcam appliance into the image? | 13:42 |
| elopio | ogra_: when I do snappy update on raspberry, it should fail right? | 13:48 |
| ogra_ | elopio, it wont switch over to the new rootfs, it will update but will never boot into the new system | 13:48 |
| sergiusens | elopio: it doesn't today | 13:48 |
| ogra_ | we need to handle that better | 13:49 |
| ogra_ | (like blocking the update before it even downloads and tell the user about the unsupported status) | 13:49 |
| elopio | +1 to that. While full update is supported anyway. | 13:49 |
| ogra_ | well, it isnt, thats the point | 13:50 |
| elopio | mvo_: should the webcam snap work on raspberry? | 13:51 |
| sergiusens | ogra_: elopio we have some unlanded MPs for that | 13:51 |
| ogra_ | sergiusens, that prevent the download ? | 13:51 |
| elopio | sergiusens: for updates in raspberry? | 13:51 |
| ogra_ | elopio, for avoiding them :) | 13:51 |
| mvo_ | elopio: I think so, is it not working? and if not, what error do you get? | 13:52 |
| elopio | heh :) | 13:52 |
| sergiusens | ogra_: elopio basically if you build your image with --developer-mode | 13:52 |
| sergiusens | && sideload the "device" tarball it should be blocked | 13:53 |
| ogra_ | sergiusens, why does --developer-mode have any influence here | 13:53 |
| elopio | mvo_: http://paste.ubuntu.com/11672461/ I'll try again with ogra_'s latest image. | 13:53 |
| ogra_ | i thought as soon as you use an external device tarball it should be blocked, no matter what kind of image you built | 13:53 |
| sergiusens | ogra_: oh, I didn't write it, "I'm not sure --developer-mode is the right switch" | 13:54 |
| sergiusens | ogra_: but there is also an && | 13:54 |
| ogra_ | well, that sounds inconsequent | 13:54 |
| sergiusens | ogra_: you shouldn't be able to override these things without --developer-mode though | 13:54 |
| ogra_ | either we block always if an external device tarball is used or we dont | 13:55 |
| ogra_ | ah, i didnt know that | 13:55 |
| ogra_ | i thought you could always roll images | 13:55 |
| ogra_ | (i never tried without --developer-mode ... seems pointless unless you actually build an appliance) | 13:56 |
| elopio | sergiusens: can you give me a link to the branch, please? to add it to the testing report | 13:56 |
| mvo_ | elopio: try "sudo systemctl status -l webcam-demo_webcam-demo_1.0.2.service" | 13:56 |
| mvo_ | (notice the *2* in the name) | 13:56 |
| mvo_ | elopio: I added a task to the trello card that the guide needs to be updated as the version is now 1.0.2 instead of 1.0.1 | 13:56 |
| elopio | mvo_: hah, right. | 13:56 |
| * elopio retries. | 13:57 | |
| jdstrand | mvo_: fyi only: https://code.launchpad.net/~ubuntu-security/ubuntu-core-security/15.04 | 13:57 |
| mvo_ | ta | 13:57 |
| mvo_ | rsalveti: just fyi, I triggered a new vivid build now that all packages are in the ppa | 13:59 |
| sergiusens | elopio: it's card on trello on todo; all there | 13:59 |
| sergiusens | elopio: in doing I mean | 13:59 |
| elopio | sergiusens: ack, thanks. | 13:59 |
| rsalveti | mvo_: awesome, thanks | 14:00 |
| jdstrand | tyhicks: fyi, not adding ping or a child profile to snappy default template-- it requires capset syscall | 14:38 |
| sergiusens | mvo_: help! I can't find a branch (the one that records a sidelod for the device) | 14:41 |
| mvo_ | sergiusens: the one for u-d-f? or the one for snappy? | 14:41 |
| sergiusens | mvo_: oh, nvm I think I found it (I followed the link from u-d-f that pointed to the old one) | 14:42 |
| mvo_ | cool | 14:43 |
| ogra_ | sergiusens, should my autopilot hack be obsolete then ? | 14:43 |
| ogra_ | or woould autopilot still remind aboout the update when i enable it again by default | 14:44 |
| sergiusens | ogra_: yes | 14:44 |
| ogra_ | yes ? | 14:44 |
| elopio | damn, I burned my tty cable. | 14:44 |
| * ogra_ should not ask "or" questions | 14:44 | |
| elopio | I did not use the red cable, *I swear* | 14:45 |
| ogra_ | elopio, how is it broken ? | 14:47 |
| ogra_ | you dont see ttyUSB0 created in dmesg when you plug it in ? | 14:48 |
| ogra_ | (on your PC) | 14:48 |
| elopio | ogra_: I didn't for a while, and my PC shut down, then it started smelling funny. | 14:51 |
| elopio | I gave it some space, now it works again :) | 14:51 |
| ogra_ | heh | 14:52 |
| ogra_ | self healing cable :) | 14:52 |
| tyhicks | jdstrand: so that increases the urgency to get the unprivileged ping patches uploaded in wily? | 14:57 |
| seb128 | cprov, sergiusens, mvo_, rsalveti: so I built goget-ubuntu-touch with the change from https://code.launchpad.net/~canonical-ci-engineering/goget-ubuntu-touch/local_image/+merge/260531 and used "u-d-f core rolling --channel edge --device-part=livecd.ubuntu-desktop-next.device.tar.gz --image-part=livecd.ubuntu-desktop-next.rootfs.tar.gz -o wily.img" which gave me an image, but kvm says it's not a bootable disk ... any idea how to debug? | 15:05 |
| mvo_ | elopio: I wanted to add some integration tests for snappy build, check if systemd/random-seed is writable and similar things, do you think its ok to still do this via the old sh or should I do it in go nowdays? | 15:06 |
| ogra_ | mvo_, you should loop over 7etc7system-image/writable for that | 15:07 |
| mvo_ | seb128: you could boot with -kernel -initramfs -append and point that to your local kernel | 15:07 |
| ogra_ | bah | 15:07 |
| mvo_ | ogra_: I'm confused? | 15:07 |
| ogra_ | /etc/system-image/writable | 15:07 |
| mvo_ | ogra_: aha, yes | 15:07 |
| ogra_ | mvo_, it has all the info what should be writable :) | 15:07 |
| seb128 | mvo_, that sends me to initramfs with error like /etc/fstab no existing, I feel like the generated img is unvalid | 15:10 |
| mvo_ | uh | 15:11 |
| mvo_ | ok | 15:11 |
| seb128 | no idea if the files from our image builder are even valid | 15:11 |
| * seb128 is just poking around | 15:11 | |
| jdstrand | tyhicks: for some value of 'urgency' | 15:22 |
| jdstrand | I don't think it is incredibly high personally, but someone might think it is | 15:23 |
| tyhicks | ok | 15:23 |
| jdstrand | ie, let' snot be distracted by it. just know there is no (safe) workaround policy at this time | 15:23 |
| tyhicks | jdstrand: I'm not sure if I ever mentioned it but upstream iputils merged the unprivileged ping socket patches for ping and ping6 | 15:24 |
| jdstrand | you did. that's great :) | 15:24 |
| tyhicks | cool | 15:24 |
| seb128 | mvo_, are you going to do a livecd-rootfs upload today? or is it ok if I upload the change you commited earlier? | 15:29 |
| elopio | mvo_: first, I would like if you merged https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | 15:33 |
| mvo_ | seb128: yeah, just upload with my changes, thats fine | 15:34 |
| elopio | mvo_: the only blocker in there is that it tries to sign the packages | 15:34 |
| seb128 | mvo_, thanks | 15:34 |
| mvo_ | elopio: aha, ok | 15:34 |
| elopio | mvo_: then, maybe it's better for you to write the test in shell, while we figure out how to do it in go with adt-run. | 15:34 |
| elopio | from the discussion between fgimenez and pitti, I get that there are still some things to figure out. | 15:35 |
| mvo_ | elopio: ok, thats fine, I can convert it to go later once that is settled | 15:35 |
| mvo_ | elopio: let me fix the signing part now | 15:37 |
| elopio | mvo_: thanks. | 15:37 |
| mvo_ | elopio: r468 should have that now | 15:41 |
| elopio | dholbach: davidcalle: are you guys going to take care of the developer docs? | 15:41 |
| mvo_ | elopio: if that looks good, you can top-approve the MP and it will be auto-merged | 15:41 |
| fgimenez | elopio, mvo_ i hope to push something shortly with a simple implementation of pitti's suggestion of creating an image with the debs installed | 15:41 |
| fgimenez | elopio, mvo_ i'll ping you when it'll be ready | 15:41 |
| elopio | mvo_: I'll give it a new try. | 15:41 |
| elopio | fgimenez: thanks! | 15:41 |
| mvo_ | thanks! | 15:41 |
| dholbach | elopio, in which sense? | 15:42 |
| elopio | dholbach: like, who should write about this? https://bugs.launchpad.net/developer-ubuntu-com/+bug/1457935 | 15:43 |
| davidcalle | elopio, please define take care, publish or write, if write, about what ? :) | 15:43 |
| ubottu | Ubuntu bug 1457935 in Ubuntu Developer Portal "The snappy getting started guide doesn't mention the serial console" [Undecided,New] | 15:43 |
| dholbach | I don't know - maybe rsalveti can comment? | 15:43 |
| dholbach | ^ elopio | 15:43 |
| * davidcalle really needs a board | 15:44 | |
| elopio | davidcalle: like a trello board or like a beagle board? :) | 15:45 |
| davidcalle | elopio, beagle (nobody sane would "need" another trello board ;-) ) | 15:46 |
| elopio | davidcalle: they are giving away the raspberries with the orange case, you just have to reply to gustavo's email. | 15:48 |
| davidcalle | elopio, good point | 15:48 |
| elopio | or maybe rsalveti can get you one from the order he's making for the team. If you are going to write docs about snappy, that makes sense. | 15:48 |
| elopio | but well, then we are back to the question: who writes the docs? | 15:49 |
| davidcalle | elopio, common effort, but I will very certainly write some more myself | 15:50 |
| elopio | I suppose, whoever knows about it. So I'll jfdi for the serial. | 15:50 |
| dholbach | <3 | 15:50 |
| pitti | fgimenez, mvo_: note, I did suggest to *not* install debs on snappy, but build a custom image out of it; installing debs on snappy for testing is wrong :) | 15:55 |
| elopio | pitti: still a good step to get started, right? | 15:55 |
| pitti | elopio: well, not "good"; it's an okay workaround for running a test locally | 15:56 |
| elopio | we have a big list of things to fix on the tests, to make them closer to how a real system would work. | 15:56 |
| pitti | mounting / r/w and installing debs is exactly how real systems don't work :) | 15:56 |
| fgimenez | pitti: yep, that's what i'll try, using --install option of u-d-f, sounds good? | 15:56 |
| pitti | and with the writable bind mounts you are going to have a hard time installing debs | 15:56 |
| ogra_ | the --install option is for snaps | 15:57 |
| pitti | fgimenez: I suppose that's going to do the same, though? i. e. mount r/w and install debs? | 15:57 |
| pitti | ah | 15:57 |
| ogra_ | (unless i'm totally wrong) | 15:57 |
| ogra_ | i.e. --install webdm | 15:57 |
| elopio | I'm okay with an okay step to get started :) | 15:57 |
| pitti | but please don't ever put that into production | 15:57 |
| elopio | while fgimenez gets the correct thing working. | 15:57 |
| fgimenez | ogra_: thx! i got confused with the "packages" part of the description | 15:59 |
| ogra_ | np :) | 15:59 |
| fgimenez | then, how can be built a custom image using local debs? | 16:00 |
| pitti | how do we build the official images? | 16:01 |
| === tvoss is now known as tvoss|dinner | ||
| ogra_ | pitti, livecd-rootfs/live-build | 16:01 |
| ogra_ | on cdimage | 16:01 |
| ogra_ | (or "via" | 16:02 |
| ogra_ | ) | 16:02 |
| ogra_ | the rootfs then gets imported by system-image.u.c, diffed for the deltas and merged with the device bits | 16:02 |
| * longsleep cheers at bug 1462954 fix commited | 16:04 | |
| ubottu | bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Fix committed] https://launchpad.net/bugs/1462954 | 16:04 |
| ogra_ | mvo_, hmm, i see /var/lib/systemd/snappy and /var/lib/systemd/click in /etc/system-image/writable-paths but neither of them mounted ... are they leftovers from older implementations or bugs ? | 16:07 |
| elopio | pitti: with "please don't ever put that into production" do you mean trunk? I would like to get mvo's branch merged because it prevents some errors, and will make it easier for us to transition into tests written in go. | 16:08 |
| elopio | if we skip the building the deb part, it also serves to check the released images. | 16:08 |
| === fgimenez_ is now known as fgimenez | ||
| pitti | elopio: I mean relying on installing debs on snappy | 16:08 |
| pitti | it's going to fail for some packages, and it's the wrong approach | 16:09 |
| longsleep | For some reason my FAT partition got borked again automatically .. (second time) | 16:10 |
| elopio | pitti: ok, totally agree to that. | 16:10 |
| elopio | lets figure out something better. | 16:10 |
| ogra_ | longsleep, weird, we explicitly run an fsck on it from the initrd | 16:11 |
| elopio | is snappy always going to be a deb? or will it become a snap at some point? | 16:11 |
| ogra_ | so even if you just pull the power plug it should recover fine | 16:11 |
| pitti | elopio: IMHO it would be a very worthwhile exercise to try and reproduce the image build locally, then simplify/scriptify that, so that we can do it for tests, in the cloud, etc. | 16:11 |
| ogra_ | elopio, i doubt we will stop rolling images from debs | 16:11 |
| pitti | i. e. ideally a live-build config | 16:12 |
| pitti | snappy being a snap sounds like a bootstrap issue | 16:12 |
| pitti | AFAIUI we'll build our system images from debs | 16:12 |
| ogra_ | well, as lon as we build our rootfs from debs it should be a deb | 16:12 |
| pitti | *nod* | 16:12 |
| ogra_ | and i dont see us stop doing that for the next few years | 16:13 |
| ogra_ | since the old ubuntu wont go away | 16:13 |
| elopio | now about the selftests, instead of packaging them as debs, we can just package them as snaps. | 16:16 |
| elopio | in case it was not meta enough before :) | 16:16 |
| pitti | elopio: why do you need to package them at all? | 16:18 |
| longsleep | ogra_: it does not even come to boot, the boot.ini is invalid and thus the u-boot does refuse to boot it | 16:22 |
| longsleep | the text files have some binary garbage in them (in all of them) | 16:22 |
| longsleep | it seems to happen after it automatically rebooted because of new rootfs | 16:23 |
| longsleep | ok its not garbage | 16:24 |
| longsleep | it always added \x94 in regular order | 16:24 |
| longsleep | s/added/replaced/g | 16:24 |
| longsleep | and all the files in a and b are uppercased and using short name | 16:26 |
| longsleep | maybe something wrote to parts of the fat partition upgrade | 16:26 |
| elopio | pitti: I'm copying the test binaries atm, so no *need* to package them. | 16:26 |
| elopio | but it would be extra cool that if you want to verify that your board is correct beyond the checking if it boots, you could | 16:26 |
| elopio | sudo snappy install snappy-selftests && snappy-selftests | 16:26 |
| longsleep | it must have happend when snappy-system.txt was written | 16:27 |
| pitti | elopio: oh, tests are now in go instead of a scripting language? | 16:27 |
| elopio | pitti: that's the experiment I'm trying to do. | 16:27 |
| longsleep | ogra_: Fschk results manually run on that partition confirm that it is broken :/ | 16:29 |
| * longsleep has to leave for linux user group now | 16:29 | |
| pitti | elopio: that sounds hard; a deb can't be installed in principle, and a snap doesn't have the necessary privs; a framework should do, not sure whether that can have "unlimited" system privs | 16:33 |
| pitti | elopio: in particular, not sure if a framework should be able to install snaps and such | 16:33 |
| * pitti waves good night | 16:34 | |
| sergiusens | elopio: pitti it is doable, but beats the purpose of a snap as it can wreck the system (I would not allow install/remove in a test suite designed to run on a live system) | 16:35 |
| elopio | so... maybe we just make the tests a deb and bundle them into the image that we will somehow build from trunk. Or I don't know. First, to get this branch merged, then the future. | 16:39 |
| * elopio tests. | 16:39 | |
| mterry | Is it possible to flash the BBB over USB? (I don't have an SD slot on my laptop) | 16:48 |
| Chipaca | wooohoo! branches landing! woo. | 16:52 |
| elopio | mterry: I don't think so. I have this: http://www.amazon.com/Transcend-Information-Card-Reader-TS-RDF5K/dp/B009D79VH4/ref=sr_1_1?ie=UTF8&qid=1433868800&sr=8-1&keywords=sdcard+reader | 17:04 |
| elopio | mterry: https://lists.ubuntu.com/archives/snappy-devel/2015-June/000732.html | 17:05 |
| sergiusens | elopio: that's not related to sdcard requirements though | 17:06 |
| sergiusens | what mterry wants is network boot | 17:06 |
| mterry | elopio, interesting amazon link. cheap enough | 17:07 |
| elopio | sergiusens: I was wondering if the memory could be flashed from usb, not from sd card as that script is doing. | 17:07 |
| elopio | network boot sounds cool too. I want that. | 17:08 |
| mterry | Do you folks also use some sort of casing for the BBB, or a mat or something? It feels weird to have a bare circuit board | 17:08 |
| * elopio puts it into ogra's TODO :) | 17:08 | |
| sergiusens | mterry: you eventually get used to it ;-) but there are cases | 17:08 |
| mterry | sergiusens, I would also be happy with a USB flash, not necessarily network boot | 17:08 |
| sergiusens | mterry: there is no recovery mode in these devices though, so usb flash seems a tad complicated | 17:09 |
| rsalveti | elopio: so, ideally the way to change the image is basically as pitti said, which is creating another clean image with livecd-rootfs | 17:45 |
| rsalveti | elopio: the proposed-migration work that the ci team is doing basically that, but using launchpad to build the new image | 17:45 |
| rsalveti | we should just have a script or something that can easily do that locally (something like rootstock, ogra_ ^^) | 17:46 |
| rsalveti | elopio: we definitely don't want to change the image by installing debs in runtime, as that's not the same path used when we produce the final images | 17:46 |
| rsalveti | about the selftests, I wonder if we can install them by default, as long it's not big | 17:47 |
| rsalveti | that would allow us to run the tests as part of the produced image | 17:47 |
| rsalveti | sergiusens: what do you think? | 17:47 |
| rsalveti | elopio: one curious thing, while go helps, why are we moving away from shell scripts? | 17:47 |
| ogra_ | i can look into making rootstock work for core | 17:48 |
| rsalveti | I know shell is not necessarily ideal, but it generally easier to script tests, right? | 17:48 |
| sergiusens | rsalveti: I think it's a bad idea | 17:48 |
| sergiusens | rsalveti: installing the selftests on production images | 17:48 |
| rsalveti | sergiusens: why? | 17:48 |
| sergiusens | rsalveti: because they can alter the system | 17:48 |
| rsalveti | right | 17:49 |
| sergiusens | it's not idempotent to run the tests | 17:49 |
| rsalveti | then how can we easily install/deploy the self tests that are compatible with a specific image? | 17:49 |
| ogra_ | well, we could add a rule that test packages cant have maintainer scripts | 17:49 |
| sergiusens | rsalveti: a sideloaded snap is fine | 17:49 |
| sergiusens | rsalveti: but not on the store | 17:49 |
| ogra_ | then they cant alter it | 17:49 |
| rsalveti | sergiusens: right, but then we'd need to find a way to store that and make that easily available | 17:49 |
| sergiusens | rsalveti: but | 17:49 |
| rsalveti | and in a way that we can match the tests with the image | 17:50 |
| sergiusens | rsalveti: this is the reason I suggested to make it a go binary, so it can just be copied over and ran | 17:50 |
| rsalveti | shell script also allows that, right? | 17:50 |
| sergiusens | rsalveti: if it's a snappy package you can match releases at all | 17:50 |
| rsalveti | don't think we're going to remove bash :-) | 17:50 |
| sergiusens | rsalveti: we are going to remove bash actually | 17:51 |
| ogra_ | and even then you could ship your own and use "#"./sh" | 17:51 |
| sergiusens | you can use dash | 17:51 |
| rsalveti | bash is fine | 17:51 |
| rsalveti | yeah, sh and dash should still be around | 17:51 |
| sergiusens | rsalveti: it's going to be removed and provided by the comfy framework | 17:51 |
| rsalveti | sergiusens: what is the comfy framework? | 17:51 |
| ogra_ | yeah, but you most likely also want to test without that installed | 17:51 |
| rsalveti | guess lool was going to write something for it today | 17:51 |
| sergiusens | rsalveti: a set of tools to make the system easy to admin | 17:52 |
| ogra_ | comfy has all the minimal convenience packages for admins | 17:52 |
| rsalveti | right | 17:52 |
| ogra_ | proper vim, htop etc etc | 17:52 |
| rsalveti | got it | 17:52 |
| rsalveti | we still need to find a way to easily provide the selftests that match the image | 17:53 |
| rsalveti | once we merge selftests in lp:snappy, we can at least match the versions in there | 17:54 |
| ogra_ | yeah, then we should just branch into /home/ubuntu | 17:54 |
| ogra_ | and run them from there | 17:54 |
| sergiusens | ogra_: just like we did for click ;-) | 17:54 |
| rsalveti | right, that might be easier indeed | 17:54 |
| ogra_ | no packages or anything at all | 17:54 |
| kyrofa | sergiusens, currently the webdm web interface and the snappy scope talk to webdm via its API. For some reason I've been assuming that webdm will be going away and its API will be moving into snappy itself, and the web interface and scope will be talking directly to snappy. However, it sounds like that's not the case. Can you explain what will become of webdm as you develop the snappy service? | 17:54 |
| sergiusens | kyrofa: what do you mean not the case? | 17:55 |
| rsalveti | I just still don't fully understand the reason to migrate from shell to go for everything (I understand that's a good thing for some tests) | 17:55 |
| ogra_ | yeah | 17:55 |
| rsalveti | since having a go test that will be basically calling many other commands is like an overkill thing | 17:55 |
| rsalveti | shell is perfect for that | 17:55 |
| sergiusens | kyrofa: the diagram on the rest doc shows that afaik | 17:55 |
| ogra_ | i dont think we should add additional compiling if not needed | 17:56 |
| rsalveti | right | 17:56 |
| kyrofa | sergiusens, it shows webdm is still there, but talking to snappy. Can you explain what exactly it's doing other than hosting an API for the web interface? | 17:56 |
| sergiusens | rsalveti: ogra_ you can't bzr branch on the target so what's the problem? | 17:56 |
| ogra_ | you can scp | 17:56 |
| ogra_ | and branch on the host | 17:56 |
| sergiusens | kyrofa: showing a browseable view/interface | 17:56 |
| sergiusens | ogra_: and compile | 17:57 |
| rsalveti | you can install comfy | 17:57 |
| rsalveti | and then checkout | 17:57 |
| rsalveti | or just scp | 17:57 |
| sergiusens | rsalveti: comfy doesn't have bzr | 17:57 |
| ogra_ | well, then you cant test without comfy :) | 17:57 |
| sergiusens | nor git | 17:57 |
| kyrofa | sergiusens, okay so it just becomes the web interface. No API | 17:57 |
| sergiusens | and what ogra said | 17:57 |
| rsalveti | can't we add it? :-) | 17:57 |
| ogra_ | sure | 17:57 |
| rsalveti | at least git | 17:57 |
| sergiusens | kyrofa: well it will have an api that the browser would consume | 17:57 |
| ogra_ | but still, you want to be able to thest the plain image too | 17:57 |
| rsalveti | sure | 17:58 |
| rsalveti | but doing an scp in one script or one binary is the same thing | 17:58 |
| sergiusens | kyrofa: but ted said he wants store + local view consolidated into a single view provided by snappy | 17:58 |
| sergiusens | so things are in flux again | 17:58 |
| rsalveti | how making it go will make it any easier? | 17:58 |
| ogra_ | sergiusens, i would actually stuff binaries into the tree instead of compiling on the host | 17:58 |
| ogra_ | *if* i need any binaries at all | 17:58 |
| kyrofa | sergiusens, yeah flux here too | 17:58 |
| sergiusens | rsalveti: ogra_ anyways, the move to go was to get some test framework in place more than anything else | 17:59 |
| rsalveti | right, that's is a good thing | 17:59 |
| rsalveti | I just don't want us to simply rewrite everything just because of reasons | 17:59 |
| ogra_ | +1 | 17:59 |
| kyrofa | sergiusens, okay. I know we just talked about this, but with my newfound understanding, just to clarify: webdm does NOT need screenshots, reviews, ratings, etc.? | 18:00 |
| rsalveti | elopio: mvo_: I also created a QA column in our backlog to make sure we don't forget about stuff we want to automate: https://trello.com/b/4PQViyUQ/snappy-core-stakeholders-backlog | 18:00 |
| kyrofa | sergiusens, or was that only snappy itself that didn't need that stuff? | 18:01 |
| rsalveti | mvo_: we could use that and include a card for the systemd random-seed regression testing you wanted to add | 18:01 |
| rsalveti | elopio: so since the ubuntu-snappy package includes the bzr rev as part of the package version, we could use that when using the self tests against an specific image | 18:02 |
| rsalveti | once everything is merged | 18:03 |
| rsalveti | so we know we're testing the same revision | 18:03 |
| sergiusens | kyrofa: webdm does need reviews, screenshots and ratings, where and how it gets them is in flux ;) | 18:05 |
| kyrofa | sergiusens, ah, good. Okay, ted didn't like the "extract the snappy store stuff into a lib" idea-- he wants the primary package path to go through snappy. So now I'm thinking I'll write a go lib to get that "leaf data" from the store, and maybe webdm can use that? | 18:07 |
| kyrofa | rsalveti, ^^ | 18:12 |
| rsalveti | kyrofa: if a go lib maybe snappy can use that later | 18:14 |
| rsalveti | but yeah, from what I understood from tedg he wants everything to go via snappy, using the rest api | 18:14 |
| rsalveti | and then everything to consume from the rest api | 18:14 |
| rsalveti | tedg can explain better when he gets back online :-) | 18:14 |
| kyrofa | rsalveti, same understanding here. Does that mean he also wants that extra data (screenshots etc.) coming from snappy? | 18:15 |
| === tvoss|dinner is now known as tvoss | ||
| rsalveti | I'd guess so, but not sure | 18:15 |
| rsalveti | let's wait on tedg | 18:15 |
| kyrofa | rsalveti, alright, good deal | 18:15 |
| === tvoss is now known as tvoss|dinner | ||
| sergiusens | kyrofa: well not webdm but snappy | 18:45 |
| sergiusens | kyrofa: and yeah, even screenshots | 18:45 |
| sergiusens | kyrofa: I think we want to improve the API we have exposed on webdm today | 18:46 |
| tedg | rsalveti, kyrofa, I'd say the leaf data like screenshots isn't critical, but it would be better if it went through snappy. | 18:46 |
| tedg | But it seems to me that once you have 90% of the data going through snappy, you should just do that too. | 18:46 |
| tedg | I like the idea of "one route to get data" even if snappy is just signing the URLs underneath the scope and passing them along. | 18:48 |
| sergiusens | tedg: there are a couple of cases where this needs decoupling though; remote devices (ala google play's webui) | 18:55 |
| tedg | sergiusens, Do you mean "install on my device" like via a website? | 18:56 |
| sergiusens | tedg: yes | 18:56 |
| tedg | sergiusens, Wouldn't in that case it be a push notification to the device? | 18:56 |
| sergiusens | tedg: ah, right | 18:57 |
| tedg | I think we need push messages for two things: new version available and install this app. | 18:59 |
| ogra_ | install this app ?? | 18:59 |
| tedg | ogra_, For like when you're browsing the Google Play store on your computer and you select something to install, it'll then install on your Android device. | 19:00 |
| ogra_ | ah | 19:01 |
| tedg | I think we should definitely do at least one "are you sure?" check there :-) | 19:01 |
| ogra_ | heh, yeah | 19:01 |
| kyrofa | tedg, alright. sergiusens, rsalveti: so the store code should probably stay in snappy, since the scope will continue talking to snappy. For now, I'll write a small go package to get the leaf data, and hopefully that's something that can be repurposed by snappy when it's ready. Does that sound reasonable? | 19:06 |
| tedg | +1 | 19:07 |
| tedg | kyrofa, Or just patch snappy? Work things out in code review? | 19:07 |
| sergiusens | kyrofa: as tedg says, maybe create launchpad.net/snappy/store | 19:08 |
| sergiusens | or remote | 19:08 |
| sergiusens | whatever you want to call it | 19:09 |
| ogra_ | a fork ! | 19:09 |
| tedg | Open Source is about freedom | 19:09 |
| kyrofa | sergiusens, would we need to make a new API call for that stuff? Or will it fit into something we already have? | 19:10 |
| sergiusens | kyrofa: our store api inside snappy is quite limited to cli needs | 19:11 |
| sergiusens | kyrofa: I'd rip it out and decouple and start using store.API | 19:11 |
| kyrofa | sergiusens, ah, right-- you're still waiting for the new API to be approved, right? | 19:14 |
| sergiusens | kyrofa: oh yeah, new api, I wasn't following you; yes, that exposed api needs approval and apparently a retwist to bring back remotes | 19:15 |
| sergiusens | kyrofa: for sure doing PUT /v1/packages/[name] is wrong with this model | 19:15 |
| kyrofa | sergiusens, alright let me talk to alecu about where he wants my priorities. I think this is the solution long-term, but I may do a quick workaround to get the scope off the ground before I come back to this | 19:19 |
| alecu | kyrofa: sergiusens: hola! | 19:23 |
| * alecu reads backlog | 19:23 | |
| beuno | jdstrand, review scripts updated to r476 | 19:35 |
| jdstrand | \o/ | 19:35 |
| jdstrand | thanks :) | 19:36 |
| beuno | jdstrand, sorry it took so long, clouds, storms, etc | 19:36 |
| jdstrand | it's all good :) | 19:37 |
| rsalveti | sergiusens: for our tools we want to have everything available for trusty, utopic and vivid, right? | 19:54 |
| rsalveti | and wily as well, but guess part of the archive | 19:55 |
| sergiusens | rsalveti: yeah, but wait | 19:55 |
| sergiusens | rsalveti: what version are you releasing? | 19:55 |
| rsalveti | sergiusens: not releasing anything yet, just checking our tools ppas | 19:55 |
| rsalveti | want to remove the need for the beta one, align the versions for the other ppas | 19:55 |
| rsalveti | and adjust the build scripts | 19:56 |
| sergiusens | rsalveti: ok; what version is being aligned to? | 19:56 |
| rsalveti | checking now, every ppa got a different version | 19:56 |
| rsalveti | sergiusens: is there anything you want to releasE? | 19:56 |
| sergiusens | rsalveti: maybe 0.23 | 19:57 |
| sergiusens | rsalveti: of u-d-f | 19:57 |
| sergiusens | rsalveti: btw http://bazaar.launchpad.net/~snappy-dev/snappy/snappy-tools-update/view/head:/snappy-tools-update | 19:58 |
| rsalveti | oh, great | 19:59 |
| rsalveti | sergiusens: yeah, would be nice to release udf | 19:59 |
| === devil is now known as Guest99265 | ||
| sergiusens | Chipaca: can you later take a look at my MPs, pretty small | 20:10 |
| elopio | catching up with the backlog. | 20:19 |
| elopio | rsalveti: the tests in go are just a proposal for further discussion, once we have something to show. I think they are more readable and easier to write. | 20:20 |
| elopio | on bash we can do regexp matching, but we can't do proper set up and tear down, nor nice test reporting or failure messages. | 20:20 |
| rsalveti | elopio: right, that's fine, I just want to make sure we don't get into this mode of rewriting everything unless really needed | 20:21 |
| elopio | what we discussed is that as we are already compiling the source code, it wouldn't be a lot more pain to also compile the test. And we get a lot more options. | 20:21 |
| rsalveti | or part of a further test development goal | 20:21 |
| elopio | rsalveti: we don't want to just rewrite the current tests. We want to make them self contained and independent. | 20:22 |
| elopio | as long as we finish testing we can finish the prototype. | 20:22 |
| elopio | s/long/soon. | 20:23 |
| rsalveti | sure, that's fine | 20:23 |
| sergiusens | nice, the powerpc seems to not be broken anymore | 20:52 |
| sergiusens | rsalveti: want to build the images with https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.23-0ubuntu1 ? If that's it, it's the one that needs propagation across the ppas | 20:53 |
| sergiusens | rsalveti: I would like to get the install.yaml in place, but that requires a bit more time | 20:53 |
| rsalveti | sergiusens: yeah, will propagate that | 21:05 |
| === Guest99265 is now known as devil_ | ||
| rsalveti | sergiusens: jdstrand: asac: do you guys know why we have the click-ubuntu-policy package? | 21:59 |
| * rsalveti is doing the tools ppa cleanup | 21:59 | |
| rsalveti | was created by asac a while ago | 22:00 |
| rsalveti | and only published for trusty | 22:00 |
| rsalveti | actually it's also in the archive, but same version | 22:00 |
| rsalveti | so guess just let it there | 22:00 |
| jdstrand | rsalveti: all I can say is that it doesn't do what it sounds like it does | 22:04 |
| rsalveti | yeah :-) | 22:04 |
| jdstrand | I'm not sure what it is or why it is there | 22:04 |
| jdstrand | ah "initial version with the Ubuntu click store public key" | 22:05 |
| rsalveti | yeah, just includes the public key | 22:05 |
| rsalveti | jdstrand: so besides our packages, there are 2 main packages that you are maintaining in there | 22:06 |
| rsalveti | click-reviewers-tools and ubuntu-core-security | 22:07 |
| rsalveti | jdstrand: it seems both are maintained in bzr | 22:08 |
| rsalveti | so was wondering if we could have a recipe to build trunk and automatically publish that into tools-proposed | 22:08 |
| rsalveti | that then migrates to tools once a week | 22:09 |
| rsalveti | jdstrand: or if you would prefer to for us to only track the released versions | 22:09 |
| rsalveti | which then means someone needs to manually track and upload the package to the ppa | 22:09 |
| jdstrand | rsalveti: ubuntu-core-security I'd rather see updates in the archive. we can discuss the review tools, but can we do that tomorrow (heading out) | 22:12 |
| rsalveti | sure, will ping you tomorrow then | 22:13 |
| rsalveti | but guess it's fine to track releases as well | 22:13 |
| rsalveti | usually we just want to update the tools ppa before every stable release, or when required | 22:13 |
| rsalveti | would be even better if we could do binary copies, but we can discuss tomorrow | 22:14 |
| asac | rsalveti: there was a problem during release rush that migth or might not got resolved by this upload to ppa... unfortunately, i cant remember anymore. maybe it was a dependency? if you can purge it from host & target (not sure where its on) on trusty and still can build the webcam demo guide then its not needed :). | 22:54 |
| asac | it was while jdstrand was sleeping :P | 22:54 |
| * asac off | 22:55 | |
| rsalveti | yeah, not doing it for this release :-) | 22:55 |
| elopio | utlemming: my vm is still provisioning in azure. Is it normal that it takes so much time? | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!