[00:09] <eikeon> Anyone running an ubuntu core AMI on EC2 and know how to get it to recognize a bigger volume. I end up with the same size filesystems regardless of how big I make the root volume at EC2 launch time
[00:19] <miken> Small fix to the snapcraft tutorial: https://code.launchpad.net/~michael.nelson/snapcraft/fix-golang-tutorial-to-match-changes-from-r132/+merge/270131
[07:06] <fgimenez> good morning
[07:07] <mvo> hey fgimenez, good morning
[07:09] <fgimenez> hi mvo!
[07:16] <dholbach> good morning
[07:42] <miken> Hi people o/ Small MP with some updates for the tutorial: https://code.launchpad.net/~michael.nelson/snapcraft/fix-golang-tutorial-to-match-changes-from-r132/+merge/270131
[07:44] <miken> Also, is the daily-build of snapcraft manually triggered? Current one in the PPA is quite a way back from trunk (r135)
[08:50] <Chipaca> mvo: I've not blocked your two new-stuff-in-the-yaml branches with a needs-fixing just because i don't know if they're urgent or not
[08:50] <Chipaca> mvo: if they're urgent, we can easily land docs after
[08:50] <Chipaca> mvo: otherwise i'd be happier if the docs got updated together with the code
[08:51] <mvo> Chipaca: yeah, good point, thanks a lot. I am also not sure how urgent it is, but docs are pretty big so I will that,  thanks for the prompt review
[08:52] <Chipaca> mvo: docs should be fairly straightforward also :)
[08:53] <mvo> yep
[08:55] <Chipaca> if you find yourself writing "chapter 2: of how the service begot its socket, and the events that unfolded henceforth", start over
[08:55] <Chipaca> thenceforth?
[08:55] <Chipaca> thenceforth is a word.
[08:56]  * mvo is stunned by that and looks it up
[08:56] <mvo> Chipaca: reading the classics lately :) ?
[08:56] <Chipaca> xchat doesn't underline it, and it underlines "xchat" :)
[08:57] <Chipaca> mvo: lately? no. But I read Munchausen as a kid, and it stays with ya
[08:57] <mvo> hihi
[08:57] <Chipaca> ("thenceforth" makes sense, given "henceforth" is from here, and not from there)
[08:58] <Chipaca> (which is why you should be suspicious of it; nothing in english makes sense and isn't out to stab you)
[09:10] <JamesTait> Good morning all; happy Friday, and happy Bring Your Manners To Work Day! 😃
[09:16]  * Chipaca either always brings what manners he has
[09:16] <Chipaca> s/either//
[09:17] <mvo> kickinz1|lunch: hey, I'm working on http://paste.ubuntu.com/12117177/ right now and would like to ask if we could make "socket: yes/no implicit, i.e. if there is a listen-stream we always use socket: yes. or is there a use-case were we have a socket without a listen-stream?
[09:17] <mvo> kickinz1|lunch: plus I would like to rename "SocketUser" to socket-user to make it more yamlish
[09:17] <mvo> kickinz1|lunch: sounds ok?
[10:18] <Chipaca> mvo: ping
[10:24] <mvo> Chipaca: pong
[10:25] <Chipaca> mvo: hiya. I just noticed, in the socket branch, that you're not using generate*FileName in two places where you could. Is it because there's not much to it and you've had to prune the directory off it anyway? Or just because you didn't notice?
[10:25] <mvo> Chipaca: I think I did not noticed, mind to point to the lines? maybe I did notice and forgot about it too, but in any case worth a comment at least (or a fixing)
[10:26] <Chipaca> mvo: inline
[10:27] <mvo> ta
[10:27] <Chipaca> i'd already half-asked inline before pinging you :)
[10:53] <ogra_> mvo, so i was looking around a bit ... we should be able to call genext2fs as last step in livecd-rootfs to actually generate .img files of the rootfs and publich them on cdimage ... that way you would only have to pick them up from there without tinkering to generate a rootfs snap
[10:54] <ogra_> then we could just install them wherever we like ... (system-boot or writable or wherever)
[10:54] <mvo> ogra_: sounds reasonable, we will have to add the meta/* stuff to it as well plus it will have to be squashfs
[10:55] <ogra_> why, we could start with simple ext2
[10:55] <mvo> ogra_: I made some progress yesterday on that
[10:55] <ogra_> ah, ok
[10:55] <mvo> ogra_: if it does not work out, I'm happy to go back to ext2 of course
[10:56] <ogra_> right ...
[13:17] <Chipaca> mvo: are you going to wait for a review from kickinz1|lunch ?
[13:18] <mvo> Chipaca: probably not, I guess he is busy, we can probably land
[13:22] <mvo> ogra_: in case you are fiddling with the image building, I think we need squashfs-tools soon :)
[13:22] <ogra_> mvo, thats a dep of livecd-rootfs i think
[13:22] <ogra_> will need some code changes to produce img files though
[13:23] <ogra_> unless you want to keep the tarballs for porters or whatnot and do the squashing at snap build time
[13:23] <mvo> ogra_: I have a script that builds images out of the cdimage artifacts
[13:23] <mvo> ogra_: I don't mind either way really
[13:24] <ogra_> i think keeping the tarball makes it easier for others to inspect the rootfs
[13:24] <mvo> ogra_: I guess best to discuss with the store guys what the most sensible process for this is
[13:24] <ogra_> so if you already have a script. lets use that
[13:24] <mvo> ogra_: yeah, sounds good to me to keep it
[13:24]  * ogra_ hes to check if the RPi kernel actually has squashfs at all 
[13:25] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo modprobe squashfs
[13:25] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /proc/filesystems |grep squash
[13:25] <ogra_> 	squashfs
[13:25] <ogra_> ok, that was quick :)
[13:25] <mvo> yay!
[13:26] <ogra_> well, i have a complteley module-less initrd in the device tarball atm ...
[13:26] <ogra_> need to adjust that
[13:26] <mvo> ogra_: could you simpliy add it to the kernel ?
[13:26] <ogra_> mvo, paolo could ... ppisati ^^^
[13:27] <ogra_> ppisati, we need squashfs built into the kernel
[13:27] <mvo> ogra_: its not going to happen before the weekend, no worries :) I'm just making better progress right now than I had hoped, but that can chnage quickly on the next road-block
[13:27] <ogra_> right, i want to be prepared on all devices for it :)
[13:28] <ppisati> ogra_: k, i'll add it to -generic, v/raspi2 and w/raspy2
[13:28] <ogra_> v and w ?
[13:29] <ppisati> ogra_: vivid and wily
[13:29] <ogra_> ah :)
[13:29] <ppisati> ogra_: 3.19 and 4.2
[13:29] <ogra_> oh, right, we have two kernels now
[13:29]  * ogra_ will need to adjust his build script too 
[13:49] <elopio> ogra_: can you please review https://code.launchpad.net/~elopio/snappy/test_free_space/+merge/270137 ?
[13:51] <Chipaca> sergiusens: ping
[13:51] <ogra_> elopio, as far as my go knowledge goes it looks ok
[13:51] <ogra_> (thats not very far, mind you :) )
[13:52] <sergiusens> Chipaca, pong
[13:52] <elopio> ogra_: that's good enough, thanks :)
[13:52]  * sergiusens was having issues with irssi and freenode
[13:53]  * sergiusens said, hell it is Friday and installed xchat
[13:53] <ogra_> +1
[13:53] <ogra_> xchart FTW
[13:53] <ogra_> *xchat
[14:18] <tedg> sergiusens: Did my long rambling e-mail about ubuntu packages make any sense?
[14:19] <sergiusens> tedg, heh, I'm trying to figure it out, I think I understood the TODOs and the WANTs
[14:20] <tedg> sergiusens: K :-)
[14:20] <sergiusens> tedg, let me get back to you in a bit
[14:49] <elopio> ogra_: when I run parted on the bbb it tells me that there's one block not used.
[14:49] <elopio> is that a bug, or is that ok?
[14:51] <ogra_> hmm, do you have the exact output ?
[14:51] <ogra_> it should be fine i think
[15:02] <elopio> Warning: Not all of the space available to /dev/vda appears to be used, you can
[15:02] <elopio> fix the GPT to use all of the space (an extra 1 blocks) or continue with the
[15:02] <elopio> current setting?
[15:02] <elopio> ogra_: ^
[15:03] <ogra_> elopio, huh ? thats BBB ??
[15:03] <elopio> ogra_: sorry, no, kvm.
[15:03] <ogra_> ah
[15:04] <ogra_> well, doesn it resize fine beyond that ?
[15:05] <elopio> ogra_: it has 0.04% free at the end, so my test passes.
[15:05] <elopio> I just have to ignore the stderr. What I'm asking is if that's ok to ignore.
[15:06] <ogra_> as long as there is a proper filesystem on disk and it resized, yeah ignore it for now ... the whole GPT handling will change anyway
[15:07] <elopio> ack.
[15:34] <sergiusens> ogra_, elopio that error bust me too when doing the uflash PoC with the recvory image
[15:35] <ogra_> sergiusens, even when not resized ?
[15:36] <ogra_> hmm, livecd-rootfs doesnt have anything about subgid subuid ...
[15:41] <ogra_> sergiusens, aha ... bug 1475749 ... seems slangasek already fixed it in wily
[15:41] <sergiusens> ogra_, even when no resized (just when adding a partiton on top of something that already exists)
[15:42] <ogra_> sergiusens, ok, thats a general issue with the kvm GPT then ... funny that i dont see it here
[15:52] <elopio> happy anniversary dholbach!
[15:52] <ogra_> not yet :P
[15:52] <dholbach> thanks elopio :)
[15:52] <ogra_> but yeah, welcome to the ten-year-club dholbach :)
[15:53] <dholbach> thanks ogra_ :)
[16:04] <fgimenez> nice weekend everyone o/
[16:42] <slangasek> ogra_: bug #1475749> and in vivid-proposed, if you want to verify the fix
[16:42] <nothal> Bug #1475749: usermod --add-subuids fails for users not in /etc/passwd <Canonical System Image:New> <shadow (Ubuntu Vivid):Fix Committed> <http://launchpad.net/bugs/1475749>
[17:03] <ogra_> slangasek, thanks, will do
[17:12]  * Chipaca -> mostly EOW
[18:41] <sergiusens> ted, so back to stage-packages, either we do it like build-deps but put them in $TOPDIR/stage or grab them before each pull and it goes into $TOP/parts/$part/installdir (and conflicts managed with the filtering thing that needs to get done)
[18:44] <sergiusens> mvo, still around? if yes, do you know how the conflict resolution rules are for that 'packages' entry?
[18:51] <mvo> sergiusens: what packages entry exactly?
[18:52] <sergiusens> mvo, in the spec, at the very end
[19:04] <tedg> sergiusens: Sorry, I missed your message. Someone else already has "ted" on Freenode :-(
[19:05] <tedg> sergiusens: I like the idea of letting dpkg do the filtering, I think it knows more about what can overlap and what can't.
[19:13] <tedg> Seems like they haven't used it in 9 weeks though… getting close.
[19:41] <sergiusens> tedg, I'll need to take that one level higher the decision making process; for now pull/unpack are done before pull now
[19:44] <sergiusens> tedg, I'm going to see if I can make the plugin stage-packages part of the yaml in a clean way (maybe it will end up being what you want
[19:47] <tedg> sergiusens: Makes sense
[20:00] <sergiusens> tedg, do you have code for the pip plugin somewhere?
[20:11] <tedg> sergiusens: Pushed to here: lp:~ted/snapcraft/python-pip
[20:11] <tedg> Might be kinda hacked though
[20:11] <tedg> I was screwing with it trying to get it to work.
[20:12] <sergiusens> tedg, no worries
[20:46] <sergiusens> tedg, why don't you call pip install directly?
[20:47] <sergiusens> tedg, and another question, why not just do pip install from the build stage?
[20:47] <tedg> sergiusens: You mean by importing the module?
[20:47] <sergiusens> tedg, yeah
[20:47] <tedg> sergiusens: In that case it was a python2 vs 3 thing.
[20:47] <tedg> sergiusens: I was trying to keep things in pull for the LP builders.
[20:48] <tedg> sergiusens: I think we'd also have to have the module in the host system to include it? No?
[20:50] <sergiusens> tedg, for the lp builders, the lifecycle rolls over the comple cycle for a part before going to the next, so I'm not sure we can separate this at all without drastic changes
[20:50] <sergiusens> tedg and I don't grep that last line about includes :-)
[20:51] <tedg> sergiusens: I don't think it goes over the complete cycle if you just do "snapcraft pull" as a command, no?
[20:51] <tedg> sergiusens: I think it only does the complete cycle for each with all.
[20:52] <tedg> sergiusens: I was thinking that you don't want to install pip into the host system. But I guess you could, except for the potential python version mismatch.
[20:55] <sergiusens> tedg, ah, good point on calling 'snapcraft pull'
[20:55] <sergiusens> tedg, yeah, let's not install pip on the host :-)
[20:56] <sergiusens> tedg, but depending on python-pip brings in pip into the part
[21:13] <tedg> sergiusens: Seems like we need a way to specify build-deps vs. runtime deps I guess.
[21:14] <tedg> sergiusens: I could, for instance, have a python build system like Waf but not want python in my snap.
[21:15] <sergiusens> tedg, isn't that what filesets is for?
[21:15] <sergiusens> filesets/stage and filesets/snap respectively
[21:15] <tedg> sergiusens: Yeah, but then if you're talking about an ubuntu package you'd need to know all the files in the package.
[21:16] <tedg> sergiusens: We could perhaps auto-populate that.
[21:19] <sergiusens> tedg, I'd exclude by default, then again; the staging terminology in snapcraft is confusing
[21:19] <sergiusens> there are two stages in a stage it seems; the part stage and the general stage
[21:20] <tedg> Huh, I didn't realize that.
[21:21] <sergiusens> tedg, oh wait, nevermind
[21:23] <sergiusens> tedg, I had that stuck on my mind for a while and now I self settled it
[21:25] <tedg> Left brain vs. Right brain. Fight! ;-)
[21:26] <sergiusens> tedg, btw, this is why I asked about pip 'bin/python2: cannot import name IncompleteRead; 'pip' is a package and cannot be directly executed'
[21:27] <sergiusens> tedg, and calling pip directly pkg_resources.DistributionNotFound: pip==1.5.6
[21:28] <tedg> sergiusens: I think that comes from the path issue, you need to be able to call the python2 binary that is installed so that you're using the right pip.
[21:29] <tedg> sergiusens: The environments weren't quite right for that. I'm not sure if we're going to have to go down to the full virtualenv path. I was hoping to avoid it though. Just to keep things simpler.
[21:30] <sergiusens> tedg, might be necessary; in any case I think I can say that with my latest MP you are unblocked :-)
[21:31] <sergiusens> I asked mvo to review the code on Monday as well (and to have him validate it against the spec).
[21:31] <sergiusens> I'm going to implement the fileset stuff now and table the plugin listing for now; there are some encapsulation and delegation of concern issues there if I want to top level it
[21:32] <tedg> sergiusens: Cool, I'll update on Monday. Oh, wait, Tuesday :-)
[21:32] <tedg> sergiusens: Thanks!