| === bjf_ is now known as bjf | ||
| === slangase` is now known as slangasek | ||
| === rcj` is now known as rcj | ||
| dholbach | good morning | 06:21 |
|---|---|---|
| fgimenez | good morning | 07:08 |
| mvo_ | hey fgimenez, good morning | 07:09 |
| fgimenez | hi mvo_ | 07:10 |
| mvo_ | no new good image yet that fully does the upgrade,rollback,upgrade dance, but except for this the most recent one should be good to test | 07:10 |
| mvo_ | and a new image is in the works that hopefully fixes upgrade/rollback/upgrade/rollback | 07:11 |
| p_lorenz | hi - is there a way to redirect the snappy cli tool to an own server infrastructure? i work for a company which would like to host own snaps and system updates | 07:11 |
| fgimenez | mvo_, ok thanks, i'll execute the tests against the latest one | 07:22 |
| clobrano | good morning | 07:32 |
| clobrano | I was looking for info about installing udev rules in snappy (other than using hw-assing). Any suggestion? :) | 07:32 |
| clobrano | a link to any kind of documentation will be great | 07:33 |
| Chipaca | mo'in | 08:04 |
| Chipaca | clobrano: i don't think that exists; what's your use-case? (that is: what do you want to achieve?) | 08:05 |
| clobrano | Chipaca, in our application, we often create symlink to device nodes that respect some regex | 08:06 |
| clobrano | like matching vid/pid pair | 08:07 |
| clobrano | I saw that the example here https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ that include a udev rule in the package.yaml, is there something already available for other udev rules? | 08:08 |
| Chipaca | clobrano: I don't think there is, at the app level, something for that. I suspect what you want to do goes in a gadget snap, not an app snap | 08:10 |
| Chipaca | clobrano: ogra_ probably knows more, but he was up very late fighting with some regressions in the next release :) | 08:10 |
| clobrano | Chipaca: ok, do not worry :) you already gave me a starting point; I didn't know about "gadget snap" :D | 08:11 |
| mvo_ | fgimenez: r165+ should be ok, I did a 165->166->165->166 successfully now | 08:22 |
| p_lorenz | Chipaca: thanks for your mail :) which nickname does Martín have in IRC? | 08:23 |
| fgimenez | mvo_, ok thanks i'll try that now | 08:23 |
| mvo_ | thanks | 08:23 |
| Chipaca | p_lorenz: beuno | 08:23 |
| * mvo_ tries a full upgrade instead of delta now too | 08:23 | |
| p_lorenz | Chipaca: thanks a bunch! | 08:24 |
| Chipaca | p_lorenz: no worries | 08:25 |
| zyga | mvo_: I'd like to add snapcraft --version | 08:29 |
| zyga | mvo_: would you merge that? | 08:29 |
| Chipaca | zyga: snapcraft, or snappy? | 08:31 |
| mvo_ | zyga: sure, unless sergio disagrees thats fine | 08:31 |
| Chipaca | zyga: if snapcraft, ask sergiusens :) | 08:31 |
| Chipaca | zyga: also probably not today | 08:31 |
| zyga | Chipaca: snapcraft | 08:31 |
| zyga | Chipaca: what's going on today? | 08:31 |
| Chipaca | zyga: busy busy busy | 08:31 |
| Chipaca | zyga: like yesterday, but more so | 08:31 |
| mvo_ | Chipaca: more so? *meeeh* | 08:31 |
| * ogra_ phears that | 08:32 | |
| Chipaca | mvo_: same pressure, more tiredness -> more mistakes -> moar busy | 08:32 |
| ogra_ | moaning :) | 08:32 |
| zyga | Chipaca: I know the feeling | 08:32 |
| ogra_ | clobrano, there is no way to "ship" a udev rule, the rule you see in the example is generated by the hw-assign command | 08:33 |
| mvo_ | Chipaca: logical. flawlessly logical… | 08:34 |
| Chipaca | mvo_: https://www.youtube.com/watch?v=THNPmhBl-8I&t=1m55s | 08:35 |
| * Chipaca links to the punchline of a very long joke | 08:35 | |
| * Chipaca is obviously also not in tip-top form today :) | 08:35 | |
| mvo_ | Chipaca: hehe | 08:38 |
| clobrano | ogra_: ok, so is there a way to add custom udev rule? Or is it something yet to be added to snappy? | 08:53 |
| JamesTait | Good morning all; happy Guacamole Day! 😃 | 08:54 |
| ogra_ | i dont think that is planned ... the hw-assign tool will be expanded and perhaps also changed ... and you can define a device (and a snap it uses) in the gadget (today it is called oem) snap | 08:55 |
| clobrano | ogra_: uhm, I understand. Well, it will be great if hw-assign would be flexible enough to allow symlinks too :) | 08:57 |
| ogra_ | clobrano, worth filing a bug i guess :) so the implementers know about that | 08:59 |
| clobrano | ogra_: I was more in the mood of contributing if possible :D, btw I will start with the feature request ;), Thank you, I understood that you all are very busy those days :) | 09:01 |
| ogra_ | clobrano, hw-assign is maintained by our security team, talk to tyhicks or jdstrand once they are around (i think both are in US timezones) | 09:02 |
| ogra_ | i agree it would be nice to be able to define a symlink name via hw-assign so you can use self picked device names in your snap | 09:03 |
| clobrano | ogra_: yep, that was what I thought :) | 09:05 |
| === vrruiz_ is now known as rvr | ||
| davmor2 | hey guys in wily trying to create a snappy personal image is failing http://paste.ubuntu.com/12425581/ I'm assuming that the issue is it doesn't wait for everything to be downloaded before it starts the image creation process. | 09:39 |
| ogra_ | davmor2, it can do that in parallel ... what it creates is an empty image, then it copies stuff inside | 09:57 |
| ogra_ | so the order shouldnt matter | 09:57 |
| ogra_ | do you have enough free diskspace ? IIRC personal is quite big | 09:58 |
| davmor2 | ogra_: 756GB of free space and it installed fine on vivid only had this issue since I tried using it on wily | 09:59 |
| ogra_ | ah, u-d-f 0.30 landed yesterday ... that might have broken it ... try going back to 0.29 | 10:00 |
| ogra_ | ricmm, ^^^ :) | 10:01 |
| ogra_ | might be that the image needs some extra changes to work with the new u-d-f | 10:01 |
| ogra_ | blame sergio ;) | 10:02 |
| ricmm | ah :) indeed | 10:05 |
| ricmm | davmor2: sadly will need to wait for sergio to wake up | 10:05 |
| ricmm | davmor2: wait that error is something else | 10:24 |
| ricmm | davmor2: reboot your machine ;) | 10:24 |
| ricmm | and try again | 10:24 |
| davmor2 | ricmm: will do after this meeting | 10:25 |
| === zbenjamin_ is now known as zbenjamin | ||
| dholbach | sergiusens_, can we turn off the plainbox tests which need internet access during the build? | 11:48 |
| dholbach | https://code.launchpad.net/~dholbach/snapcraft/1496363/+merge/271285 | 11:48 |
| sergiusens_ | dholbach, yeah, we need to make those autopkg ones | 11:58 |
| Mikaela | dholbach: you might be interested in https://freenode.net/sasl | 12:26 |
| dholbach | mh | 12:43 |
| dholbach | sergiusens_, in which cases is the wiki plugin going to be used? | 12:48 |
| sergiusens_ | dholbach, when used in 'after' and the ref'ed part is not there | 12:49 |
| dholbach | sergiusens_, ok... I was just surprised how often during the build wiki.u.c was trying to be opened: http://people.canonical.com/~dholbach/tmp/snapcraft_0.2_amd64.build | 12:50 |
| sergiusens_ | dholbach, or when a part is there but doesn't specify a 'type'; for which the full part definition will be pulled from the wiki and the local definition would overlay it (in python part_from_wiki.update(part_local) | 12:50 |
| sergiusens_ | dholbach, hmm, should be only once; maybe I can initialize it earlier | 12:50 |
| dholbach | sergiusens_, shall I file a bug? | 12:51 |
| sergiusens_ | dholbach, sure | 12:51 |
| dholbach | cool will do | 12:51 |
| === sergiusens_ is now known as sergiusens | ||
| sergiusens | Chipaca, what is the python way for http://golang.org/pkg/sync/#Once.Do ? | 12:52 |
| dholbach | https://bugs.launchpad.net/snapcraft/+bug/1496381 | 12:52 |
| ubottu | Launchpad bug 1496381 in Snapcraft "wiki.u.c is opened a lot during the build" [Undecided,New] | 12:52 |
| Chipaca | sergiusens: a "once" decorator | 12:54 |
| sergiusens | Chipaca, of course :-) | 12:55 |
| Chipaca | sergiusens: http://pastebin.ubuntu.com/12426544/ | 12:58 |
| Chipaca | sergiusens: definitely not this: http://pastebin.ubuntu.com/12426580/ | 13:03 |
| sergiusens | Chipaca, no, I prefer easily readable code | 13:03 |
| Chipaca | :) | 13:03 |
| sergiusens | thank you very much | 13:03 |
| sergiusens | :-) | 13:03 |
| sergiusens | Chipaca, the write less characters thing is only for play :-P | 13:04 |
| Chipaca | sergiusens: disadvantage of the decorator is that the decorated function won't complain about bad number of args | 13:04 |
| Chipaca | sergiusens: that is | 13:04 |
| Chipaca | if f(a) | 13:04 |
| Chipaca | and the first time you call f(1) | 13:04 |
| Chipaca | and the second, f(1,2) | 13:04 |
| Chipaca | the second will just work | 13:04 |
| sergiusens | Chipaca, that's fine, it's an internal decorator | 13:05 |
| Chipaca | k | 13:05 |
| jdstrand | ogra_: fyi, I wouldn't say the security team is maintained by us-- we didn't even implement it :) we did have input to get something going, but others are refining it. the only thing we care about is that hw happens, somehow, in a separate step | 13:06 |
| * ogra_ notes down ... the security team isnt maintained by the security team | 13:07 | |
| * ogra_ grins | 13:07 | |
| jdstrand | as for symlinks, that will be interesting because apparmor resolves symlinks (it must) | 13:07 |
| jdstrand | haha | 13:07 |
| jdstrand | s/the security team/hw-assign/ :) | 13:07 |
| ogra_ | you mean hw-assign i guess :) | 13:07 |
| ogra_ | jdstrand, well i think it might be convenient to allw hw-assign to have options like --symlink-name ... or --exec-script (which would be a script running under confinement inside your snap indeed) | 13:08 |
| jdstrand | but actually, we are using cgroups for hw-assign currently | 13:08 |
| ogra_ | you dont generate the udev rule anymore ? | 13:09 |
| jdstrand | I'm happy to review the mp | 13:09 |
| jdstrand | there are different parts of it | 13:09 |
| clobrano | jdstrand: hi, I was the one interested in symlinks :D, any hope to have the ability to create some? :) | 13:09 |
| jdstrand | it has not changed since april | 13:09 |
| jdstrand | oem snaps (gadgets) may provide udev rule snippets via the 'assign' yaml which can tag devices | 13:10 |
| jdstrand | that tag is then used to add the device to a cgroup | 13:10 |
| clobrano | jdstrand: yep, I saw something in the webcam example | 13:12 |
| jdstrand | otoh, I don't see why snappy in this situation: 'snappy hw-assign foo /dev/symlink' couldn't resolve the symlink and tag the device in the same manner | 13:12 |
| clobrano | interesting | 13:13 |
| jdstrand | someone would 'just' need to implement that | 13:13 |
| jdstrand | (fyi, you can read about the current implementation here: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Cgroups) | 13:13 |
| clobrano | how open is the project for contribution from outsiders? :) | 13:14 |
| clobrano | I mean, I can try and do that? | 13:14 |
| jdstrand | I suggest filing a bug. Note, how hw assignment works is bieing redone aiui, but I don't know who is doing it | 13:14 |
| jdstrand | clobrano: it is completely open :) | 13:14 |
| clobrano | Nice to hear that, I've already filed a bug (https://bugs.launchpad.net/snappy/+bug/1496319) and I think I'll have a look at that feature | 13:15 |
| ubottu | Launchpad bug 1496319 in Snappy "Could not create custom udev rules" [Undecided,New] | 13:15 |
| jdstrand | clobrano: I'm going to direct you to mvo_ for how to contribute processes, but essentially, check out a branch, do your work and then push it to launchpad and request an mp. perhaps a patch on the list would be accepted | 13:15 |
| jdstrand | lp:snappy | 13:15 |
| jdstrand | https://launchpad.net/snappy | 13:16 |
| jdstrand | https://code.launchpad.net/~snappy-dev/snappy/snappy | 13:16 |
| clobrano | perfect, thank you | 13:16 |
| jdstrand | I'll comment in the bug | 13:16 |
| clobrano | jdstrand: great | 13:18 |
| dholbach | sergiusens, shall I file a separate bug for separating tests from build? (https://launchpadlibrarian.net/218099126/buildlog_ubuntu-wily-amd64.snapcraft_0.2-0~168~ubuntu15.10.1_BUILDING.txt.gz) | 13:18 |
| sergiusens | dholbach, sure | 13:19 |
| dholbach | will do | 13:19 |
| jdstrand | clobrano: to get the full picture, you might also want to look at https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk, but I don't think you'll need to change anything there (since it only looks at the tags to add things to the device cgroup-- so if snappy adds the right udev rule, it should all just work) | 13:21 |
| dholbach | https://bugs.launchpad.net/snapcraft/+bug/1496392 | 13:21 |
| ubottu | Launchpad bug 1496392 in Snapcraft "Separate tests from build" [Undecided,New] | 13:21 |
| clobrano | jdstrand: ok, I'll have a look at it | 13:22 |
| lool | mvo: just wanted to double-check if I got that right: the way to set network config for eth0 is to set ubuntu-core/network/interfaces -name: eth0 -content: /some/path/name to an ifupdown config? | 13:46 |
| sergiusens | lool, just run snappy config ubuntu-core on the latest image and it will be clear ;-) | 13:49 |
| lool | sergiusens: haha right | 13:50 |
| lool | sergiusens: how would be transition to a non-ifupdown spec? | 13:56 |
| sergiusens | lool, oh, you are the architect ;-) | 13:56 |
| lool | sergiusens: tsss | 13:56 |
| sergiusens | lool, I'm just the snapcraft software guy now ;-) | 13:56 |
| lool | sergiusens: I'm mostly concerned about upgrades; we could keep compat with ifupdown for a while though | 13:57 |
| sergiusens | Chipaca, https://code.launchpad.net/~sergiusens/snapcraft/1496381/+merge/271299 | 13:58 |
| sergiusens | or dholbach ^ | 13:59 |
| ricmm | lool: whats the problem? most things that configure network try to parse ifupdown first in case theres something they should avoid | 14:07 |
| ricmm | we could also consider that network-admin caps can only be given to one snap | 14:08 |
| ricmm | if ifupdown is being used, os-snap should have that assigned | 14:08 |
| lool | ricmm: I wonder how we'd transition to something not defined by ifupdown snippets | 14:08 |
| ricmm | if it doesnt have it, ifupdown is a no-op | 14:08 |
| lool | ricmm: e.g. systemd-network | 14:08 |
| lool | (for simple networking) | 14:08 |
| ricmm | you mean a seamless translation from ifupdown files to *-network ? | 14:09 |
| mvo_ | lool: ups, sorry, missed the earlier question. yeah, tying ourself into ifup is a concern | 14:09 |
| ricmm | well we are not tying ourseslves, we are exposing it as an option | 14:09 |
| ricmm | we are just tying ourselves to provide the option | 14:10 |
| zyga | https://code.launchpad.net/~zyga/snapcraft/gitignore/+merge/271313 | 14:10 |
| mvo_ | yay, r156 ready for armhf | 14:18 |
| elopio | good morning team | 14:22 |
| elopio | so what needs testing? | 14:22 |
| elopio | fgimenez: ^ | 14:22 |
| sergiusens | elopio, all the things | 14:22 |
| fgimenez | elopio, more testing! even the tests need testing! :) how was your holiday | 14:24 |
| elopio | it was gooood. | 14:24 |
| dholbach | https://code.launchpad.net/~dholbach/snapcraft/1496392/+merge/271319 | 14:28 |
| dholbach | ^ let me know if the test bits make sense like this and if the one test is expected to fail | 14:29 |
| dholbach | sergiusens, replied | 15:33 |
| sergiusens | @reviewlist | 15:34 |
| nothal | https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/lp1496070/+merge/271167 | No reviews (less than a day old) | 15:34 |
| nothal | https://code.launchpad.net/~kyrofa/webdm/autorestart_services/+merge/268120 | No reviews (32 days old) | 15:34 |
| nothal | https://code.launchpad.net/~chipaca/snappy/precommit/+merge/271290 | No reviews (less than a day old) | 15:34 |
| nothal | https://code.launchpad.net/~fgimenez/snappy/resize_test2/+merge/271131 | No reviews (less than a day old) | 15:34 |
| nothal | https://code.launchpad.net/~fgimenez/snappy/udf-revision/+merge/271081 | No reviews (less than a day old) | 15:34 |
| Chipaca | @dance for us | 15:34 |
| nothal | Chipaca: No such command! | 15:34 |
| sergiusens | dholbach, oh my; will fix | 15:35 |
| elopio | sergiusens: have you seen this with the udf from tools-proposed? | 16:00 |
| elopio | http://paste.ubuntu.com/12427656/ | 16:00 |
| sergiusens | elopio, no | 16:01 |
| elopio | sergiusens: just happened 2 out of 3 times here. I'll report a bug. | 16:03 |
| elopio | fgimenez: ah, that makes sense. The comment says that the config is changed after the reboot. | 16:15 |
| fgimenez | elopio, yep, that's for grub | 16:15 |
| elopio | I was trying to be extra smart, and made a mess, as always. I can remove the check. | 16:15 |
| fgimenez | elopio, but now failover tests are trying to modify kernel files on a, have you seen that? | 16:16 |
| elopio | let me give it another try, because I am now wondering what I tested. | 16:17 |
| elopio | fgimenez: no. | 16:17 |
| fgimenez | elopio, ok give it a try | 16:17 |
| elopio | fgimenez: so the change of Next is all wrong? | 16:18 |
| fgimenez | elopio, i don't think so, it works fine on bbb, but maybe because of the problem that mvo_ mentioned with the delta upgrades we are seeing this issues now | 16:19 |
| ogra_ | sergiusens, elopio, davmor2 reported the same issue today (the kpartx one) | 16:21 |
| ogra_ | and i dont think he was using proposed ... that must be something older | 16:21 |
| elopio | davmor2: link? | 16:22 |
| davmor2 | elopio: http://paste.ubuntu.com/12425581/ | 16:22 |
| davmor2 | seems to be working this time for what it is worth | 16:23 |
| elopio | ogra_: the message is not the same. | 16:23 |
| ogra_ | yeah, i just noticed | 16:23 |
| elopio | davmor2: can you please file a bug for that one? | 16:23 |
| davmor2 | elopio: I did an upgrade and rebooted at lunch time now it seems to be working | 16:23 |
| elopio | davmor2: ok, if you happen to see it again, please let us know. | 16:24 |
| ogra_ | and send our greetings too | 16:24 |
| ogra_ | :P | 16:24 |
| elopio | the typical joke from this side of the world would be: and what do I tell him if I don't see him? | 16:26 |
| ogra_ | :) | 16:27 |
| slangasek | ricmm: did the fwupdate seeding for 15.10 happen today? | 16:32 |
| ogra_ | slangasek, cyphermox pinged me about it last night and then noticed it wasnt in the archive yet | 16:32 |
| ogra_ | is it now ? | 16:32 |
| slangasek | ogra_: that's not correct, fwupdate has been in wily for weeks | 16:33 |
| ricmm | ogra_: fwupdate should be in wily yea | 16:33 |
| ricmm | ogra_: could you do that rq if it doesnt interfere with the other stuff? | 16:33 |
| ogra_ | oh | 16:34 |
| ogra_ | <cyphermox> disregard fwupd for now since it's not even in Debian. | 16:34 |
| * ogra_ notes thats a different package | 16:34 | |
| ogra_ | i didnt catch that last night, sorry | 16:34 |
| ogra_ | do we actually have seeds ? | 16:34 |
| ogra_ | (up to now all changes for adding new packages were in livecd-rootfs) | 16:34 |
| ogra_ | i see https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily but are they actually used (we dont have a meta) | 16:37 |
| ogra_ | slangasek, added to the seed, not sure if i have to do any subsequent actions though since we dont have a meta | 16:39 |
| slangasek | ogra_: the core seed is in the ubuntu.wily seed pod... | 16:40 |
| slangasek | ogra_: the system-image seed. You've been hard-coding packages in livecd-rootfs?! ugh | 16:41 |
| ogra_ | slangasek, for 15.04, yes | 16:41 |
| ogra_ | i wouldnt know how i can retroactivly add anything to it | 16:41 |
| slangasek | ogra_: ah because tasks | 16:43 |
| ogra_ | yeah | 16:43 |
| ogra_ | hmm, so the seed isnt actually the one i linked above ? | 16:43 |
| slangasek | ogra_: no, it's not | 16:44 |
| ogra_ | eek ... | 16:45 |
| * ogra_ reverts the last commit then | 16:45 | |
| slangasek | ogra_: and yes, you're right, for 15.04 putting it in the seed doesn't help because task fields don't get regenerated | 16:45 |
| ogra_ | right | 16:45 |
| elopio | fgimenez: I'm on kvm, and I see snappy_mode=try on /boot/grub/grubenv | 16:52 |
| ricmm | mvo_: ^ | 16:54 |
| ricmm | elopio: you probably hit the issue mvo just fixed | 16:54 |
| ricmm | where the update process didnt finish correctly so flags werent set right | 16:54 |
| elopio | ricmm: yes, that was fgimenez' suspicion. I was just giving it a try. | 16:55 |
| Chipaca | elopio: bug 1496486 is also fixed by my branch | 16:57 |
| ubottu | bug 1496486 in Snappy "trunk fails go vet: i18n/xgettext-go/main.go:93: unreachable code" [Undecided,In progress] https://launchpad.net/bugs/1496486 | 16:57 |
| elopio | Chipaca: oh, sorry. | 16:57 |
| elopio | Chipaca: which branch? | 16:57 |
| elopio | you have like 3000, give or take. | 16:58 |
| Chipaca | @reviewlist | 17:00 |
| nothal | https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/lp1496070/+merge/271167 | No reviews (less than a day old) | 17:00 |
| nothal | https://code.launchpad.net/~kyrofa/webdm/autorestart_services/+merge/268120 | No reviews (32 days old) | 17:00 |
| nothal | https://code.launchpad.net/~elopio/snappy/fix1496486-go_vet_unreachable/+merge/271343 | No reviews (less than a day old) | 17:00 |
| nothal | https://code.launchpad.net/~chipaca/snappy/precommit/+merge/271290 | No reviews (less than a day old) | 17:00 |
| nothal | https://code.launchpad.net/~fgimenez/snappy/resize_test2/+merge/271131 | No reviews (less than a day old) | 17:00 |
| Chipaca | elopio: ^ | 17:00 |
| elopio | got it. | 17:00 |
| Chipaca | ok, time for me to go make dinner | 17:02 |
| mvo_ | elopio: what scenario was that that you ended up with try mode? | 17:03 |
| mvo_ | elopio: and is that image/machine still available? the sudo systemctl status ubuntu-snappy.boot-ok would be good | 17:04 |
| elopio | mvo_: I called snappy update. So I expected the try mode, and it worked. | 17:04 |
| mvo_ | elopio: aha and it worked, thats nice, I like that | 17:06 |
| elopio | full of success :D | 17:06 |
| mvo_ | heh :) a bit worn down from all the testing/fixing actually | 17:08 |
| fgimenez | elopio, mm was a it a delta upgrade? i've seen the issue from 168 to 169, for instance | 17:08 |
| mvo_ | I was able to reproduce from 168->170 on kvm/amd64 | 17:10 |
| mvo_ | (and I verified the fix there) | 17:10 |
| elopio | fgimenez: 167 to 175. | 17:11 |
| elopio | using snappy-from-branch from trunk. | 17:12 |
| fgimenez | elopio, the last line of the errored update output should be "can not find file /writable/cache/assets/vmlinuz", are you trying on 15.04? | 17:16 |
| elopio | fgimenez: with that I was just checking that my test for try mode was valid. | 17:17 |
| elopio | I have a 15.04 run in progress, but with the tests from the 15.04 branch. | 17:17 |
| fgimenez | elopio, ok that makes sense, then when the fix land we should expect that the mode is try, right? | 17:19 |
| elopio | fgimenez: right. And if it fails, that's good, we are catching an error. | 17:19 |
| fgimenez | elopio, ok remember to remove http://bazaar.launchpad.net/~fgimenez/snappy/1504_validation/view/head:/_integration-tests/testutils/partition/bootloader.go#L80 | 17:21 |
| fgimenez | wait, i'll remove it | 17:21 |
| elopio | mvo_: you also fixed this: https://bugs.launchpad.net/snappy/+bug/1496486 ^_^ | 17:21 |
| ubottu | Launchpad bug 1496486 in Snappy "trunk fails go vet: i18n/xgettext-go/main.go:93: unreachable code" [Undecided,In progress] | 17:21 |
| elopio | crazy times. | 17:22 |
| mvo_ | elopio: I did? excellent, I don't even remember | 17:22 |
| elopio | yeah, we have three branches for it. | 17:22 |
| mvo_ | oh, I think I fixed and never proposed :/ ? | 17:22 |
| mvo_ | well, a good reason to land one now | 17:22 |
| elopio | mvo_: I'm trying Chipaca's fix now. Not a big deal, you have a lot more big things going on. | 17:24 |
| * elopio just takes notes to support the slow release philosophy. | 17:25 | |
| mvo_ | elopio: +10^100 from me for a slower release next time | 17:26 |
| sergiusens | ogra_, elopio davmor2 i this is the case, it is most likely some open fds left over by snappy (rebuilt to use the latest) | 17:26 |
| sergiusens | elopio, mvo_ fwiw, Chipaca has a branch that fixes that | 17:27 |
| elopio | sergiusens: yup. We just found out. | 17:28 |
| mvo_ | we found 3 branches in total | 17:30 |
| mvo_ | :) | 17:30 |
| elopio | that's how we roll. We will not just hit this release date, we will give you three fixes for everything! | 17:31 |
| slangasek | ogra_: I see that fwupdate needs an MIR now ;) | 17:31 |
| ogra_ | how about faster release with less changes instead ? | 17:31 |
| ogra_ | slangasek, well, half of the stuff we ship needs a MIR :P ... once we are through that release chaos i'll take a look | 17:32 |
| ogra_ | (before EOW i hope) | 17:32 |
| elopio | https://bugs.launchpad.net/snappy/+bug/1496515 | 17:35 |
| ubottu | Launchpad bug 1496515 in Snappy "15.04 fails go vet: helpers/helpers.go:399: result of fmt.Errorf call not used" [Undecided,New] | 17:35 |
| elopio | I think nobody has fixed this one yet ^ | 17:35 |
| * elopio goes for it. | 17:35 | |
| tedg | I really don't understand this nova build. Sometimes it seems fast. Now it's at 90m and 5.8GB of RAM. | 21:09 |
| sergiusens | tedg, heh | 21:10 |
| sergiusens | tedg, can you add back return self.handle_source_options() to python2-project? | 21:18 |
| sergiusens | tedg, how's the shebang issue treating you? | 21:18 |
| tedg | sergiusens: Not well, trying to seperate out the build and install steps but it's not clear how the various parameters interact. | 21:19 |
| tedg | sergiusens: Now trying with the default "build" directory to see if that will work. | 21:19 |
| sergiusens | tedg, there's a build_scripts target as well fwiw | 21:19 |
| tedg | sergiusens: Hmm, yeah, I haven't given up on this yet :-) | 21:22 |
| * tedg has high hopes, he has apple pie, in the sky! | 21:22 | |
| atXyc0 | hello, I am in the process of dd the RPi2 image | 21:26 |
| atXyc0 | it seems rather large | 21:26 |
| atXyc0 | Ctrl-t inidcates im not even 1/5 of the way done | 21:27 |
| atXyc0 | is that an ext4 partition for 4gb sdcard? | 21:28 |
| ogra_ | no, it is an SD card image with multiple partitions | 21:32 |
| asac | atXyc0: should be 4 partitions with 3 being ext4 and one vfat for boot | 21:32 |
| ogra_ | asac, btw for the next release we should shrink writable to 10MB or so ... now that it can auto-grow | 21:33 |
| ogra_ | saves image size | 21:33 |
| atXyc0 | asac: that makes sense. do i need to expand the root partition to fill my 8gb sdcard? | 21:33 |
| ogra_ | if you wait 2 days you can get the new image that will auto resize on first boot | 21:34 |
| ogra_ | hmm, actually ... | 21:34 |
| ogra_ | just dd it and do the upgrade once the new image is out | 21:34 |
| ogra_ | it should then grow to full size automatically | 21:34 |
| atXyc0 | the dd is taking quite a long time | 21:35 |
| ogra_ | yeah, 4GB are a lot | 21:36 |
| ogra_ | for me it takes about 10-15min usually | 21:36 |
| atXyc0 | 30 minutes so far on a MBP | 21:37 |
| atXyc0 | 939524096 bytes | 21:38 |
| asac | thats quite a long time | 21:38 |
| ogra_ | that doesnt look right | 21:38 |
| asac | slow SD card or slow bus/writer | 21:39 |
| asac | otherwise something fishy | 21:39 |
| ogra_ | whats the dd line you used ? | 21:39 |
| atXyc0 | dd if=ubuntu-15.04-snappy-armhf-rpi2.img if=/dev/disk2 bs=64m | 21:46 |
| atXyc0 | ogra_ ^ | 21:47 |
| atXyc0 | sorry, of for the dev line | 21:48 |
| ogra_ | disk2 ? | 21:48 |
| atXyc0 | im on osx | 21:48 |
| ogra_ | you actually have a device named like that ? | 21:48 |
| ogra_ | oh | 21:48 |
| atXyc0 | dd works the same as gnu | 21:48 |
| ogra_ | yeah | 21:48 |
| atXyc0 | the bs type is different | 21:49 |
| ogra_ | well, if it doesnt finish soon i'd try a smaller blocksize ... like 4M or so | 21:49 |
| ogra_ | it should definitely not take that long | 21:49 |
| atXyc0 | not that it matters, what was the blocksize that the image was dd off of | 21:51 |
| ogra_ | hmm, no idea what blocksize ubuntu-device-flash actually uses when creating the image ... sergiusens ? | 21:52 |
| atXyc0_ | sorry d/c | 21:54 |
| sergiusens | ogra_, based on code from ubi provided by cj watson | 21:54 |
| ogra_ | sergiusens, so you dont know :) | 21:55 |
| ogra_ | but i'd guess some typical disk blocksize | 21:55 |
| sergiusens | ogra_, don't remember, no | 22:01 |
| sergiusens | and otp | 22:01 |
| atXyc0_ | 502245 bytes/second seems slow | 22:13 |
| atXyc0_ | i wonder if I got a crappy sdcard with this RPi2 | 22:13 |
| atXyc0_ | i restarted with bs=4m | 22:14 |
| === atXyc0_ is now known as atXyc0 | ||
| asac | atXyc0: most likely bad sd... i had a similar slow one once, just trashed it and new one was on steroids | 22:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!