[01:27] elopio, I've updated bug 1497108 [01:27] bug 1497108 in Snapcraft "Long paths are not handled correctly when deleting partition mappings" [Medium,In progress] https://launchpad.net/bugs/1497108 [01:27] plars, btw ^ [01:27] plars, if you don't want u-d-f to bail with loops all around, use relative paths for output image :-) [01:30] sergiusens: ah, ok. I thought I had tried relative paths on an older version of udf and it didn't like that [01:55] elopio, btw https://code.launchpad.net/~sergiusens/snapcraft/1498157/+merge/271872 [02:00] sergiusens: Uhg, we need a way for plugins to tie into that processing... [02:00] sergiusens: Or perhaps just append values instead of replacing the whole file. [02:00] It's getting complex [02:08] tedg, it is [02:08] tedg, which part specifically? env? === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [03:51] sergiusens: could you look at this one tomorrow please? https://code.launchpad.net/~dholbach/snapcraft/snapcraft-examples/+merge/271838 [03:52] elopio, since it is a merge into federico's branch I just skipped it [03:52] elopio, and thought of reviewing once he merged it all in one shot [03:53] elopio, I approved in any case ;-) [03:57] sergiusens: thanks. It was you who requested it, so I wanted to make sure it made you happy. [03:58] elopio, yeah, it is good :-) [03:58] elopio, goodnight, just been through my last item for the day :-) [03:59] sergiusens: good night. === bigcat_ is now known as bigcat[fooding] === chihchun_afk is now known as chihchun === bigcat[fooding] is now known as bigcat [06:35] good morning [07:02] good morning [07:03] morning o/ [07:03] hola fgimenez, hola dpm [07:03] morning clobrano [07:03] mornin' [07:03] hey guest42315 [07:04] \o [07:04] wow, it looks like snappy land is just waking up! :) [07:04] hey dholbach and all :) [07:05] * guest42315 sudo snappy install coffee [07:05] :-) [07:05] mvo, can you take a look at https://code.launchpad.net/~dholbach/snapcraft/1497582/+merge/271801 and let me know if it's the right way to deal with the problem? [07:06] fgimenez, I wasn't quite sure if I was doing the right thing with my branch (https://code.launchpad.net/~dholbach/snapcraft/snapcraft-examples/+merge/271838) yesterday [07:06] fgimenez, from a packaging POV it's correct, but I don't know if the test machinery will be able to cope with it like that [07:06] dholbach: sure, I have a look now [07:06] <3 [07:07] hey dholbach [07:07] mvo, https://bugs.launchpad.net/snapcraft/+bug/1497582 and https://bugs.launchpad.net/snapcraft/+bug/1495525 are examples you can use to test it [07:07] Launchpad bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress] [07:07] Launchpad bug 1497582 in Snapcraft "duplicate for #1495525 pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress] [07:08] dholbach, totally, thanks a lot :) i need only to adjust the path to the examples directory and the dependencies to work with it, let me have a look [07:09] <3 [07:09] awesome [07:12] dholbach: hm, I think lp:~snappy-dev/snapcraft/more-apt solves this actually already :/ [07:12] mvo, ok - that works for me [07:16] thanks mvo [07:20] fgimenez, do you still remember where the libssl-dev depends came from in https://code.launchpad.net/~fgimenez/snapcraft/build-examples-test/+merge/270798? [07:21] mvo, would it be easy to let apt download all the necessary packages in one go instead of one by one? [07:22] dholbach, i was getting errors when building the examples without it, give me a second and i'll pastebin it [07:22] mvo, if you try the qmldemo example it feels veeery slow - also the remaining-download-estimate will never give you anything remotely accurate :) [07:24] fgimenez, maybe a missing build-packages in the case of downloader-with-wiki-parts? [07:24] mvo, I'm happy to file a bug for it though, so we can resolve it sometime later [07:29] dholbach: right, we should probably download htem all togehter, I can prepare a branch, essentially we need to adjust dir::cache::archives to the download dir and run cache.fetch_archives() [07:29] good morning :) [07:30] awesome - I'll file a bug and let you know [07:30] cześć zyga [07:30] * zyga wants to try to re-iterate on hostapd example snap/part so that it can be merged [07:30] mvo, can you reject https://code.launchpad.net/~dholbach/snapcraft/1497582/+merge/271801? [07:31] and milestone https://bugs.launchpad.net/snapcraft/+bug/1497582 to 0.2? [07:31] Launchpad bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress] [07:31] dholbach: how do I say "hi" in German? I only remember tschus but AFAIR that's more like "bye" [07:32] zyga, 'hallo' :) [07:32] dholbach: thanks :) [07:32] yes, "tschüss" is "bye" :) [07:35] mvo, https://bugs.launchpad.net/snapcraft/+bug/1498333 [07:35] Launchpad bug 1498333 in Snapcraft "Let apt download all packages in one go" [Undecided,New] [07:38] dholbach: ta, shall I give it a go or do you want to do it? [07:38] dholbach: happy to do it, just want to avoid duplication of effort [07:42] wow [07:43] Hmm [07:43] I just asked on #ubuntu-irc [07:44] Looks like irccloud was k-lined. [07:44] dholbach: I think I have a branch [07:44] <3 [07:45] mvo, can you milestone bug 1497582 to 0.2? [07:45] bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,Fix committed] https://launchpad.net/bugs/1497582 [07:45] dholbach: sure [07:45] maybe at some stage I should join ~snappy-dev :) [07:45] dholbach: do we have a 0.2 series yet? [07:45] no series, just a milestone [07:46] dholbach: done [07:54] dholbach, probably, this is the output http://paste.ubuntu.com/12519630/, i've pushed the changes needed to work with snappy-examples and removed the libssl-dev dependency, you should be able to see the error now [07:56] fgimenez, cool - I'll take a look in a sec [08:00] mvo_, will check it out in a sec [08:01] dholbach: no rush, all good [08:01] dholbach: the qml example is 350mb big [08:01] that explains why I had to wait a bit to get it :) [08:01] yep, I noticed :) [08:01] squid-deb-proxy to the rescue [08:01] it's the perfect example :) [08:01] hahaa [08:02] indeed [08:03] mvo_, [08:03] Get:823 http://de.archive.ubuntu.com/ubuntu/ vivid/main usb-modeswitch amd64 2.2.0+repack0-2ubuntu2 [51.2 kB] [08:03] Fetched 253 MB in 6s (25.9 MB/s) [08:03] :) [08:03] looks like it works ;-) [08:03] a thing of beauty [08:05] mvo_, just two small typos in https://code.launchpad.net/~mvo/snapcraft/lp1498333-even-more-apt/+merge/271918 [08:09] dholbach: thanks for the review and yeah, python-apt rocks [08:09] (and apt as well!) [08:11] fgimenez, commented on https://code.launchpad.net/~fgimenez/snapcraft/build-examples-test/+merge/270798 [08:19] asac, jdstrand, mvo, lool, sergiusens, fyi, I've started porting the manual to markdown. I'd like to propose a string freeze on thursday european evening for a v0.1 of development basics, debugging basics (and, if ready, app porting). In order to start publishing what we have before eow and solve our most prominent docs pain points asap. [08:21] https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921 [08:34] dholbach, thanks! already pushed [08:34] great [08:45] davidcalle: the application manual? think its a bit too early to do that porting [08:45] folks are still doing content etc. [08:48] asac, I'm doing the general outline and already written sections (even if they change during the week), it gives me content to test on the automagic importer to dev.ubuntu.com [08:49] asac, do you think we can have a freeze on some main sections this week? (at least yours and mvo's) [08:59] Good morning all; happy Tuesday, and happy Business Women’s Day! 😃 [09:14] davidcalle: maybe... have to check with team. My section I have to rewrite as the content is mostly the future. have to redo it with what is real right now [09:14] davidcalle: why do you want to freeze? [09:15] or is it about moving it top markdown and abandoning this doc at some point? [09:16] asac, that too but it can happen later, mostly to be able to publish something in the rough timeline we have defined [09:19] asac, I'm asking about these two sections, because they are the most important for app devs ( and snapcraft of course, but for now the trunk demos + currently published docs are fine) [09:38] davidcalle: so our tiemlnie is to get this doc done early octobver ... like 1st or 2nd [09:38] outline we need to finish today [09:38] first two sections is me and mvo... i think we can do it by EOW ... and given that we are busy next week I guess thats what we have to do [09:40] asac, sounds good to me, are you fine with publishing sections as soon as they are ready? We'll be able to change and update them of course, but I think it makes sense to do it early, especially if we have snappy events and clinics coming up [09:41] true [09:41] when are we doing first clinic? [09:41] dholbach, ^? [09:41] mvo_: can we get development basic and debugging section done by EOW? [09:41] you and me? :) [09:41] debuggin section includes sergiusens work [09:41] asac, on the clinic: no idea - I was sort of waiting on news regarding the competition [09:42] asac, but I'm working on bullet points for a presentation already [09:43] ok i will poke mectors [09:43] have a call with him in a bit [09:44] <3 [09:45] asac, hey, bug filed - https://bugs.launchpad.net/snappy/+bug/1498396 [09:45] Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,New] [09:49] mvo_, shouldnt snapcraft delete stage/usr/share/man ? we dont really need it [09:49] * ogra_ notes that he has a ton of manpages there [09:50] ogra_: you can use [09:50] snap: [09:51] - -usr/share/man [09:51] or something [09:51] to strip stuff fromn snap that you dont want [09:51] well, i thionk it should be a default [09:51] why? [09:51] why wiouldnt someone just be able to ship manpages [09:51] at least for the debian packages [09:51] why would you ship them ? [09:51] nothing can use them [09:51] because someone might want to read the manpage for some cli you packaged [09:51] like for bip [09:51] makes sense [09:51] you would ahve to ship man yourself [09:52] sure ... still doewsnt mean that all want to strip it [09:52] i can also read manpages with vi [09:52] :) [09:52] anyway, talk to sergiusens and then have him align with niemeyer on this i guess [09:52] what use would he have to read that manpage ... the ircproxy package is fully cobfigured via snappy config [09:52] ok [09:53] ogra_: but the fact that its so nicely done with sanppy config is because your package is nicely done [09:53] doesnt mean that others want to do something like that [09:53] indeed [09:53] btw, we mifght watn to talk about how to ship docs at all [09:53] e.g. how would you now doc your nice ircproxy package [09:54] yeah [09:54] the config options you providem, how to use it, etc [09:54] well, theoretically i would describe it in the store description ... but only webdm will show that (hopefully one day :P ) [09:54] asac: sanppy sounds like an awesome name for snappy san :) [09:54] ogra_: yeah [09:55] do we plan a snappy equivalent to "apt-cache show " ? [09:55] that would show the store description ... [09:55] asac: develpment basics? is that also on my list? I was working on "Debugging basics" so far and its mostly done except strace/gdb because there is no package yet [09:56] ogra_: yes, its not speced yet, but snappy info is probably that [09:56] ah [09:56] asac, so that would be my docs then ... not sure we want some additional mechanism [09:57] probably the store could just have a field that specifically describes configuration [09:58] snappy info -c could then spit our "snappy config" output with the possible values shown for each option [09:58] (or something like that) [10:15] hah, hello ogra2, hello snappy autopilot :) [10:16] (looks like my ircproxy machine just restarted itself) === ogra2 is now known as ogra-snappy-test [10:18] asac, you haven't sent out the docs? [10:19] asac, I found it hard to describe snapcraft.yaml without describing parts, so was thinking of inverting the order [10:23] mvo_, ogra_: hm, neither wget nor curl installed; what's the recommended way on snappy to download something? [10:23] call python3? [10:23] pitti, download on your host and scp [10:24] ogra_: well, this is for a "setup-classic" script I'm supposed to write [10:24] i have an unconfined wget snap too (amd64 only atm though) [10:24] pitti, ah, well, ship wget inside your sanp then [10:25] *snap [10:25] assuming your "classic" thing comes as snap [10:25] mvo_: ^ will we have a snap for this "classic" setup, or will that need to go into snappy core then? [10:25] * ogra_ thinks core is way way to bloated already [10:26] we are slowly moving out of the embedded space [10:26] would calling python3 -c ... with urllib.urlretrieve() be okay? [10:26] or will python3 go away too/ [10:26] ? [10:26] once we drop clooud-init and system-image we might drop it [10:27] not sure about the first, the latter is actively worked on atm [10:27] okay; this is just a PoC for now, we might even retrieve the "classic" environment through some other way, or bind this to comfy or whatever [10:27] so I guess I don't worry about this too much for now [10:27] * ogra_ would expect system-image to be gone with the next stable release [10:29] pitti, i'm surprised systemd doesnt have a wget equivalent yet :) [10:29] pitti: there is apt-helper download [10:29] ogra_: apt has a wget ;) [10:29] hah [10:30] mvo_: I thought apt would be gone? [10:30] pitti: yeah :( [10:30] pitti: its still there in 15.04 [10:30] pitti, I would expect that that would eventually manage setting this up (classic mode) [10:30] mvo_: "403 Forbidden file type or location" [10:31] sergiusens: what is "that"? === chihchun is now known as chihchun_afk [10:31] he means "this" [10:31] :P [10:32] doesn't help :) [10:32] pitti, err; I just woke up :-P first s/that that/snappy/ [10:32] sergiusens: ah, ok :) so this shell script PoC might be rewritten in go or so [10:32] sergiusens, so snappy woould have a builtin wget ? [10:32] I suppose Go has some url retrieve API [10:33] ogra_, no; setting up classic mode would be eventually driven by snappy [10:33] yeah, go can fetch stuff from http [10:33] I'm just guessing [10:33] right [10:33] as long as we dont have to bloat core more and more ... [10:35] right [10:35] I'm using python3 in the PoC for now that shoudl survive at least next week (and then we might do this completely differently anyway0 [10:36] yeah [10:39] pitti: you have a mail with slides :) [10:44] sergiusens: this can land as-is https://code.launchpad.net/~zyga/snapcraft/fix-1484596/+merge/271863 [10:44] sergiusens: the plainbox bits are merge in trunk now [10:44] sergiusens: and the will be a part of plainbox 0.23 [10:44] sergiusens: which is now in QA [10:44] mvo_: wow sliding mails what will you guys come up with next ;) [11:40] sergiusens, I'm not sure I understand your comment in https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921 [11:41] sergiusens, AFAICS you need libgudev-1.0-dev installed as part of build-packages (for the build to pass locally) AND to bundle libudev-1.0-0 for the snap to work on a snappy system [11:59] * mvo_ hugs dholbach for fixing bug #1498347 [11:59] bug 1498347 in Snapcraft "godd example: error while loading shared libraries: libgudev-1.0.so.0: cannot open shared object file: No such file or directory" [High,In progress] https://launchpad.net/bugs/1498347 [12:03] * dholbach hugs mvo_ back :) [12:06] mvo_, is the MP the right way to fix it? it looks like sergiusens had reservations [12:07] dholbach: not sure if he has reservations in general [12:07] mvo_, no, I meant the comment in the MP [12:08] dholbach: aha, let me read [12:22] dholbach, mvo_ since this is an example, I would use a stage-package without filesets (to remove the headers at least) so the snap doesn't have header file all over it [12:23] mvo_, dholbach the other option is to stage-package the library itself and not -dev; but it makes it a nicer example if the stage-package is the dev one [12:23] sergiusens, I think that's what I'm doing [12:23] stage-packages: [libgudev-1.0-0] [12:23] dholbach, yeah, but you should remove the build-package entry below :-) [12:23] build-packages: [12:23] 10 - libgudev-1.0-dev [12:23] why? [12:24] dholbach, and use a fileset [12:24] it is required to build the package [12:24] hum [12:24] I never used filesets before [12:24] dholbach, it shouldn't be needed; stage-package entries are also used for building [12:24] I see [12:24] mvo_, ^ do you have a strong opinion? [12:36] tedg, hey, mind looking at https://code.launchpad.net/~ted/snapcraft/pkg-config-sysroot/+merge/271751 https://code.launchpad.net/~ted/snapcraft/multi-python-version/+merge/271716 ? [12:45] davidcalle: what manual are you referring to, the the enterprise manual? [12:46] davidcalle: the parts I've written are only a first draft and I have two more sections. I already know there are edits I need to make to the sections I've written [12:46] if we work off a single bzr tree for markdown, things are going to get complicated with merges [12:48] jdstrand, no worries about that, bzr tree will come only after the first published version. DIfferent files for each section as well. [12:51] jdstrand, we can even split it more if needed to ease having simultaneous editors working on it at the same time. Having a bzr trunk makes the publishing process very streamlined. Trunk would be pulled every 2h and turned into fancy cms pages. [12:52] davidcalle: I'm only talking about this week [12:52] davidcalle: what is the verdict? am I supposed to be editing markdown now? [12:52] where is it? [12:52] jdstrand, nope :) [12:53] ok, cause assuming I don't get pulled aside (like the last three days), I plan to work on it after a couple of meetings [12:55] jdstrand, keep going with the gdoc, no rush for this week on your end, by eow I'll publish what's ready: hopefully development basics and debugging basics. What's finished will be converted to markdown as well but I'm happy with this first iteration being in gdocs, I'll handle the publication related details. [12:57] That's a big enough task, let's avoid editors being annoyed by formatting (yet :D) [12:59] dholbach, https://code.launchpad.net/~sergiusens/snapcraft/doc-services/+merge/271959 [12:59] ok... mvo is looking at right now as well [13:07] sergiusens: Sure, BTW, I'm not sure the fixup code should go in the Ubuntu plugin. It seems like it'd be needed no matter how you installed libxml or libxslt. [13:16] tedg, ok, makes sense [13:36] mvo_, thanks for that apt improvement! [13:37] davidcalle: ack, thanks. I hope to have all my parts written by eow at least in 1st/2nd draft quality [13:37] so that seems to work well with your timeline (and moving into bzr) [13:37] jdstrand, indeed, wfm :) [13:42] hey, is it expected/known that building a amd64 image with udf core 15.04 --channel edge and --developer-mode sshing doesn't work? it works with stable though [13:45] sergiusens: your welcome! [13:48] sergiusens, so I'm going to merge mvo's work which does what I guess you were expecting (correct me if I'm wrong): https://code.launchpad.net/~mvo/snapcraft/1498347/+merge/271961 [13:48] sergiusens, dholbach: so the godd example got a little bit more complicated due to the new libgudev dependency. now I could try to hack around that in godd by doing static linking with cgo etc, but it made me wonder if maybe we should do something smarter in snapcraft [13:48] sergiusens, I personally don't feel that snapcraft is easy to understand in this specific example or easy to handle [13:49] mvo_, I'm sure we are going to have more cases like that [13:49] sergiusens, dholbach: i.e. we could auto-copy all libs from the ldd output of each binary listed in binaries by default maybe? [13:49] add a build-dep, bundle a certain set of packages or set of files from other packages [13:49] mvo_, that would probably eliminate most of the hassle :) [13:50] mvo_, stage-packages should get copied over by default [13:51] https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921 is up for review again [13:51] mvo_, dholbach this looks nice! [13:52] sergiusens, I'm not sure I agree - I find it a bit hard to explain it to future snappers :) [13:52] or hard to explain the "here's how you debug which files are missing in your snap" iteration cycle :) [13:53] it'd be nice if it was easier at some golden, glorious and beautiful point in the future [13:55] maybe doing it magically is not the right way, but I would love to have something simple like snap: [$shlibs] or something, a magic var that snapcraft fills that contain the shlib depends? [13:55] dholbach, sergiusens: -^ [13:55] we could even steal https://code.launchpad.net/~mvo/click/click-check-libs/+merge/235960 for this [13:57] mvo_, as long as we look only in the parts [13:57] mvo_, but not the host [13:57] mvo_, but by default everything will be included [13:57] dholbach, ^ [13:58] the fileset is just to make the final snap look nicer [13:58] not mandatory [13:58] I'm only saying we should use it as it is an example [13:58] ok, I think that makes sense [13:58] mvo_: https://code.launchpad.net/~chipaca/snappy/husk/+merge/271965 if you're itching to review something juicy [13:58] we could have two examples, that's right [13:58] but just using 'stage-packages' would of included the libs [13:58] dholbach, the walkthrough goes over this fwiw [13:58] Chipaca: I love to review your stuff, you know that [13:59] mvo_: ⁑D [14:09] mvo_, btw, I don't mind building in default fileset filters as you mentioned 'bins', 'shlibs', 'headers' or 'development' [14:10] sergiusens: I think that would be good, we need to prune the shlibs of course to filter out the ones we already have in core, but that should be straightforward [14:11] mvo_, well, if grabbed from 'stage' it shouldn't matter too much [14:11] then again, weird things can happen [14:15] tedg, btw, do you want me to change env management to use dicts and have each plugin get a copy of the env, be able to add to it and return it when called? [14:15] tedg, it could clean up the case where things get stepped over [14:17] sergiusens: Are we still gonna do shell expansions? [14:17] I think we need to keep those. [14:20] tedg, I don't see why not [14:38] ogra_: have you been able to use parted with --pretend-input-tty ? [14:40] elopio, i havent looked into resizing this week [14:40] on my TODO though [14:40] but RPi is more important [14:44] ogra_: please let me know when you have time for this. For some reason, we are now getting a warning when shrinking the partition on the bbb. [14:44] on the BBB ? [14:45] that doesnt use the GPT codepath at all [14:45] no hurry, but I can't use that option. [14:45] ogra_: yes, on mbr. [14:45] well, MBR is not using any magic [14:45] just the resizepart command [14:45] whats the error you get ? [14:45] ogra_: no, but if I can send a "yes" to parted on mbr, this could work. [14:46] we dont want it interactive at all [14:47] elopio, got some log with the actual error ? [14:48] ogra_: sorry. one second. [14:51] mvo_, so even an image rebuild doesnt make cloud-init show up anymore on the 15.04 image ... do you know where it is seeded for 15.04 ? [14:52] (it is definitely not hardcoded in livecd-rootfs) [14:54] ogra_: its part of the "Task:" header [14:54] ogra_: which is not available in ppas, sowe need to fake it via "X-Tasks: ubuntu-core" [14:55] mvo_, well, or force install it from livecd-rootfs [14:55] live-build/auto/config for 15.04 is a mess already, adding one more line wouldnt hurt i guess [14:56] ogra_: sure, either way is fine [14:56] let me do that then === kickinz1|afk is now known as kickinz1 [15:01] ogra_: Warning: Shrinking a partition can cause data loss, are you sure you want to continue? [15:01] shrinking ?!?! [15:01] there is surely something wrong then [15:02] ogra_: that's what I do to test your resize. That's on my script. [15:03] ogra_: Your resize code works perfectly for my testing so far by the way. So nice work! [15:03] longsleep, thanks, still a hack that will need fixing :) [15:03] ogra_: i am very happy with it :) [15:03] i'm actually pondering to just switch to gdisk [15:04] there is a minor chance you trash your disk if you have powerloss while resizing [15:04] i'd like ot get rid of that possibility ... or at least reduce it [15:21] my snappy on RPi2 seems to be stuck "Starting kernel..." after update - where do I look to investigate the cause? [15:25] tasdomas, oops, i was supposed to mail about that ... you will need to manually copy the kernel and initrd from /boot/uboot/a to /boot/uboot/b for the upgrade to work [15:26] tasdomas, if you reboot the system should boot back into the a partition ... then run snappy update again and then do the file copy before reboot [15:26] ogra_, ack - thanks [15:27] thats sadly caused by the non-official state of the RPi image ... (about to change for the next release) [15:54] plars: could you provide us with an agent for prodstack snappy instances? [15:58] elopio: I thought you were working on that? We specifically said that we would not provide cloud instances since that's something that didn't require special hardware [15:58] plars: I know. We have it solved for canonistack and now we need prodstack. I'm asking if we could add that as a new requirement for the lab. [15:59] elopio: how is it different from canonistack? Why would it be a lab thing? [15:59] we don't have any special connection to prodstack that you don't [16:00] plars: I just don't want to maintain it. As you are maintaining all the other testbeds, I want you to maintain it. [16:00] but if you can't or don't want to, I can do it. That's what I'm asking. [16:00] elopio: I can talk to cwayne about it, but I suspect it's going to fall into the same territory as canonistack [16:01] elopio: on the plus side, I'm very close to being able to provide you with rpi2 [16:01] plars: you see, you'll soon be out of things to do ;) [16:01] elopio: fighting with power problems at the moment - from what I understand, the pi's in the lab may only have a 200ma adapter on them, which makes me wonder how they are running at all [16:01] plars: should I send an email to cwayne? [16:01] elopio: haha, I only wish I were out of things to do! [16:01] elopio: there's a LOT more coming [16:02] elopio: sure, just cc me on it please [16:02] plars: it's a joke, of course. [16:02] plars: sending email... Thanks. [16:11] Hello everyone! [16:11] I'm updating my snappy package and tested it with the new release [16:12] somehow, the SNAPP_APP_PATH env dissappeard [16:12] is there a new way to get the path? [16:19] ogra_: how would you get the start of a partition, by number? [16:20] like get_start /dev/mmcblk0 4 [16:25] utlemming, the latest 15.04 edge has your cloud-init now [16:25] (sorry, that took quite a bit to have it land there) [16:25] ogra_: thank you kindly :) [16:26] elopio, there is code that uses sysfs, somewhere in that sysfs node you should be able to get the start and end bvalues [16:26] ogra_: what is the version number? 176? [16:27] utlemming, 177 [16:27] ogra_: ack, thanks === ogra2 is now known as ogra-snappy-test [16:29] sergiusens, you havent synced snapcraft -proposed into -daily yet, right ? [16:30] (LP uses -daily so my ircproxy test build failed ... ) [16:33] T-mon: I think you want SNAP_APP_PATH, only one P [16:34] ogra_: in bytes :D [16:34] oh, did that change? 2 months ago it worked [16:35] elopio, an opportuntity to compute some math in shell for you \o/ [16:35] tedg, i thought we still support the old way [16:35] ogra_, oh yeah, daily is dead to me :-) [16:36] ugh, last time I spent like an hour trying to take a percentage out of the end. [16:36] ogra_, but I haven't told cjwatson yet [16:36] sergiusens, well, cjwatson uses it for pulling from [16:36] better tell him :) [16:36] behold, /me does some shell math. [16:36] ogra_, if I do, we should update the docs and prepare some for of announcement [16:36] tedg: thx, I'll try it right now :) [16:37] elopio, var=$((1+1)) [16:37] elopio, echo $var [16:37] 2 [16:37] ogra_: I know that now. That double parentheses was tricky :) [16:37] * ogra_ is afk for 1h [16:49]