=== bjf_ is now known as bjf
=== slangase` is now known as slangasek
=== rcj` is now known as rcj
[06:21] <dholbach> good morning
[07:08] <fgimenez> good morning
[07:09] <mvo_> hey fgimenez, good morning
[07:10] <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:11] <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:22] <fgimenez> mvo_, ok thanks, i'll execute the tests against the latest one
[07:32] <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:33] <clobrano> a link to any kind of documentation will be great
[08:04] <Chipaca> mo'in
[08:05] <Chipaca> clobrano: i don't think that exists; what's your use-case? (that is: what do you want to achieve?)
[08:06] <clobrano> Chipaca, in our application, we often create symlink to device nodes that respect some regex
[08:07] <clobrano> like matching vid/pid pair
[08:08] <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:10] <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:11] <clobrano> Chipaca: ok, do not worry :) you already gave me a starting point; I didn't know about "gadget snap" :D
[08:22] <mvo_> fgimenez: r165+ should be ok, I did a 165->166->165->166 successfully now
[08:23] <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:24] <p_lorenz> Chipaca: thanks a bunch!
[08:25] <Chipaca> p_lorenz: no worries
[08:29] <zyga> mvo_: I'd like to add snapcraft --version
[08:29] <zyga> mvo_: would you merge that?
[08:31] <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:32]  * 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:33] <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:34] <mvo_> Chipaca: logical. flawlessly logical…
[08:35] <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:38] <mvo_> Chipaca: hehe
[08:53] <clobrano> ogra_: ok, so is there a way to add custom udev rule? Or is it something yet to be added to snappy?
[08:54] <JamesTait> Good morning all; happy Guacamole Day! 😃
[08:55] <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:57] <clobrano> ogra_: uhm, I understand. Well, it will be great if hw-assign would be flexible enough to allow symlinks too :)
[08:59] <ogra_> clobrano, worth filing a bug i guess :) so the implementers know about that
[09:01] <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:02] <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:03] <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:05] <clobrano> ogra_: yep, that was what I thought :)
=== vrruiz_ is now known as rvr
[09:39] <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:57] <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:58] <ogra_> do you have enough free diskspace ? IIRC personal is quite big
[09:59] <davmor2> ogra_: 756GB of free space and it installed fine on vivid only had this issue since I tried using it on wily
[10:00] <ogra_> ah, u-d-f 0.30 landed yesterday ... that might have broken it ... try going back to 0.29
[10:01] <ogra_> ricmm, ^^^ :)
[10:01] <ogra_> might be that the image needs some extra changes to work with the new u-d-f
[10:02] <ogra_> blame sergio ;)
[10:05] <ricmm> ah :) indeed
[10:05] <ricmm> davmor2: sadly will need to wait for sergio to wake up
[10:24] <ricmm> davmor2: wait that error is something else
[10:24] <ricmm> davmor2: reboot your machine ;)
[10:24] <ricmm> and try again
[10:25] <davmor2> ricmm: will do after this meeting
=== zbenjamin_ is now known as zbenjamin
[11:48] <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:58] <sergiusens_> dholbach, yeah, we need to make those autopkg ones
[12:26] <Mikaela> dholbach: you might be interested in https://freenode.net/sasl
[12:43] <dholbach> mh
[12:48] <dholbach> sergiusens_, in which cases is the wiki plugin going to be used?
[12:49] <sergiusens_> dholbach, when used in 'after' and the ref'ed part is not there
[12:50] <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:51] <dholbach> sergiusens_, shall I file a bug?
[12:51] <sergiusens_> dholbach, sure
[12:51] <dholbach> cool will do
=== sergiusens_ is now known as sergiusens
[12:52] <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:54] <Chipaca> sergiusens: a "once" decorator
[12:55] <sergiusens> Chipaca, of course :-)
[12:58] <Chipaca> sergiusens: http://pastebin.ubuntu.com/12426544/
[13:03] <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:04] <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:05] <sergiusens> Chipaca, that's fine, it's an internal decorator
[13:05] <Chipaca> k
[13:06] <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:07]  * 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:08] <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:09] <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:10] <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:12] <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:13] <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:14] <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:15] <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:16] <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:18] <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:19] <sergiusens> dholbach, sure
[13:19] <dholbach> will do
[13:21] <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:22] <clobrano> jdstrand: ok, I'll have a look at it
[13:46] <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:49] <sergiusens> lool, just run snappy config ubuntu-core on the latest image and it will be clear ;-)
[13:50] <lool> sergiusens: haha right
[13:56] <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:57] <lool> sergiusens: I'm mostly concerned about upgrades; we could keep compat with ifupdown for a while though
[13:58] <sergiusens> Chipaca, https://code.launchpad.net/~sergiusens/snapcraft/1496381/+merge/271299
[13:59] <sergiusens> or dholbach ^
[14:07] <ricmm> lool: whats the problem? most things that configure network try to parse ifupdown first in case theres something they should avoid
[14:08] <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:09] <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:10] <ricmm> we are just tying ourselves to provide the option
[14:10] <zyga> https://code.launchpad.net/~zyga/snapcraft/gitignore/+merge/271313
[14:18] <mvo_> yay, r156 ready for armhf
[14:22] <elopio> good morning team
[14:22] <elopio> so what needs testing?
[14:22] <elopio> fgimenez: ^
[14:22] <sergiusens> elopio, all the things
[14:24] <fgimenez> elopio, more testing! even the tests need testing! :) how was your holiday
[14:24] <elopio> it was gooood.
[14:28] <dholbach> https://code.launchpad.net/~dholbach/snapcraft/1496392/+merge/271319
[14:29] <dholbach> ^ let me know if the test bits make sense like this and if the one test is expected to fail
[15:33] <dholbach> sergiusens, replied
[15:34] <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:35] <sergiusens> dholbach, oh my; will fix
[16:00] <elopio> sergiusens: have you seen this with the udf from tools-proposed?
[16:00] <elopio> http://paste.ubuntu.com/12427656/
[16:01] <sergiusens> elopio, no
[16:03] <elopio> sergiusens: just happened 2 out of 3 times here. I'll report a bug.
[16:15] <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:16] <fgimenez> elopio, but now failover tests are trying to modify kernel files on a, have you seen that?
[16:17] <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:18] <elopio> fgimenez: so the change of Next is all wrong?
[16:19] <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:21] <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:22] <elopio> davmor2: link?
[16:22] <davmor2> elopio: http://paste.ubuntu.com/12425581/
[16:23] <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:24] <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:26] <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:27] <ogra_> :)
[16:32] <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:33] <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:34] <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:37] <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:39] <ogra_> slangasek, added to the seed, not sure if i have to do any subsequent actions though since we dont have a meta
[16:40] <slangasek> ogra_: the core seed is in the ubuntu.wily seed pod...
[16:41] <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:43] <slangasek> ogra_: ah because tasks
[16:43] <ogra_> yeah
[16:43] <ogra_> hmm, so the seed isnt actually the one i linked above ?
[16:44] <slangasek> ogra_: no, it's not
[16:45] <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:52] <elopio> fgimenez: I'm on kvm, and I see snappy_mode=try on /boot/grub/grubenv
[16:54] <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:55] <elopio> ricmm: yes, that was fgimenez' suspicion. I was just giving it a try.
[16:57] <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:58] <elopio> you have like 3000, give or take.
[17:00] <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:02] <Chipaca> ok, time for me to go make dinner
[17:03] <mvo_> elopio: what scenario was that that you ended up with try mode?
[17:04] <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:06] <mvo_> elopio: aha and it worked, thats nice, I like that
[17:06] <elopio> full of success :D
[17:08] <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:10] <mvo_> I was able to reproduce from 168->170 on kvm/amd64
[17:10] <mvo_> (and I verified the fix there)
[17:11] <elopio> fgimenez: 167 to 175.
[17:12] <elopio> using snappy-from-branch from trunk.
[17:16] <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:17] <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:19] <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:21] <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:22] <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:24] <elopio> mvo_: I'm trying Chipaca's fix now. Not a big deal, you have a lot more big things going on.
[17:25]  * elopio just takes notes to support the slow release philosophy.
[17:26] <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:27] <sergiusens> elopio, mvo_ fwiw, Chipaca has a branch that fixes that
[17:28] <elopio> sergiusens: yup. We just found out.
[17:30] <mvo_> we found 3 branches in total
[17:30] <mvo_> :)
[17:31] <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:32] <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:35] <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.
[21:09] <tedg> I really don't understand this nova build. Sometimes it seems fast. Now it's at 90m and 5.8GB of RAM.
[21:10] <sergiusens> tedg, heh
[21:18] <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:19] <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:22] <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:26] <atXyc0> hello, I am in the process of dd the RPi2 image
[21:26] <atXyc0> it seems rather large
[21:27] <atXyc0> Ctrl-t inidcates im not even 1/5 of the way done
[21:28] <atXyc0> is that an ext4 partition for 4gb sdcard?
[21:32] <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:33] <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:34] <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:35] <atXyc0> the dd is taking quite a long time
[21:36] <ogra_> yeah, 4GB are a lot
[21:36] <ogra_> for me it takes about 10-15min usually
[21:37] <atXyc0> 30 minutes so far on a MBP
[21:38] <atXyc0> 939524096 bytes
[21:38] <asac> thats quite a long time
[21:38] <ogra_> that doesnt look right
[21:39] <asac> slow SD card or slow bus/writer
[21:39] <asac> otherwise something fishy
[21:39] <ogra_> whats the dd line you used ?
[21:46] <atXyc0> dd if=ubuntu-15.04-snappy-armhf-rpi2.img if=/dev/disk2 bs=64m
[21:47] <atXyc0> ogra_ ^
[21:48] <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:49] <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:51] <atXyc0> not that it matters, what was the blocksize that the image was dd off of
[21:52] <ogra_> hmm, no idea what blocksize ubuntu-device-flash actually uses when creating the image ... sergiusens ?
[21:54] <atXyc0_> sorry d/c
[21:54] <sergiusens> ogra_, based on code from ubi provided by cj watson
[21:55] <ogra_> sergiusens, so you dont know :)
[21:55] <ogra_> but i'd guess some typical disk blocksize
[22:01] <sergiusens> ogra_,  don't remember, no
[22:01] <sergiusens> and otp
[22:13] <atXyc0_> 502245 bytes/second seems slow
[22:13] <atXyc0_> i wonder if I got a crappy sdcard with this RPi2
[22:14] <atXyc0_> i restarted with bs=4m
=== atXyc0_ is now known as atXyc0
[22:41] <asac> atXyc0: most likely bad sd... i had a similar slow one once, just trashed it and new one was on steroids