User1: 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
User2: Small fix to the snapcraft tutorial: https://code.launchpad.net/~michael.nelson/snapcraft/fix-golang-tutorial-to-match-changes-from-r132/+merge/270131
User3: good morning
User4: hey fgimenez, good morning
User3: hi mvo!
User5: good morning
User2: 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
User2: Also, is the daily-build of snapcraft manually triggered? Current one in the PPA is quite a way back from trunk (r135)
User6: User4 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
User6: User4 if they're urgent, we can easily land docs after
User6: User4 otherwise i'd be happier if the docs got updated together with the code
User4: User6 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
User6: User4 docs should be fairly straightforward also :)
User4: yep
User6: if you find yourself writing "chapter 2: of how the service begot its socket, and the events that unfolded henceforth", start over
User6: thenceforth?
User6: thenceforth is a word.
 * mvo is stunned by that and looks it up
User4: User6 reading the classics lately :) ?
User6: xchat doesn't underline it, and it underlines "xchat" :)
User6: User4 lately? no. But I read Munchausen as a kid, and it stays with ya
User4: hihi
User6: ("thenceforth" makes sense, given "henceforth" is from here, and not from there)
User6: (which is why you should be suspicious of it; nothing in english makes sense and isn't out to stab you)
User7: Good morning all; happy Friday, and happy Bring Your Manners To Work Day! ð
 * Chipaca either always brings what manners he has
User6: s/either//
User4: 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?
User4: kickinz1|lunch: plus I would like to rename "SocketUser" to socket-user to make it more yamlish
User4: kickinz1|lunch: sounds ok?
User6: User4 ping
User4: User6 pong
User6: User4 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?
User4: User6 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)
User6: User4 inline
User4: ta
User6: i'd already half-asked inline before pinging you :)
User8: 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
User8: then we could just install them wherever we like ... (system-boot or writable or wherever)
User4: User8 sounds reasonable, we will have to add the meta/* stuff to it as well plus it will have to be squashfs
User8: why, we could start with simple ext2
User4: User8 I made some progress yesterday on that
User8: ah, ok
User4: User8 if it does not work out, I'm happy to go back to ext2 of course
User8: right ...
User6: User4 are you going to wait for a review from kickinz1|lunch ?
User4: User6 probably not, I guess he is busy, we can probably land
User4: User8 in case you are fiddling with the image building, I think we need squashfs-tools soon :)
User8: mvo, thats a dep of livecd-rootfs i think
User8: will need some code changes to produce img files though
User8: unless you want to keep the tarballs for porters or whatnot and do the squashing at snap build time
User4: User8 I have a script that builds images out of the cdimage artifacts
User4: User8 I don't mind either way really
User8: i think keeping the tarball makes it easier for others to inspect the rootfs
User4: User8 I guess best to discuss with the store guys what the most sensible process for this is
User8: so if you already have a script. lets use that
User4: User8 yeah, sounds good to me to keep it
 * ogra_ hes to check if the RPi kernel actually has squashfs at all
User8: (RaspberryPi2)ubuntu@localhost:~$ sudo modprobe squashfs
User8: (RaspberryPi2)ubuntu@localhost:~$ cat /proc/filesystems |grep squash
User8: squashfs
User8: ok, that was quick :)
User4: yay!
User8: well, i have a complteley module-less initrd in the device tarball atm ...
User8: need to adjust that
User4: User8 could you simpliy add it to the kernel ?
User8: mvo, paolo could ... ppisati ^^^
User8: ppisati, we need squashfs built into the kernel
User4: User8 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
User8: right, i want to be prepared on all devices for it :)
User9: User8 k, i'll add it to -generic, v/raspi2 and w/raspy2
User8: v and w ?
User9: User8 vivid and wily
User8: ah :)
User9: User8 3.19 and 4.2
User8: oh, right, we have two kernels now
 * ogra_ will need to adjust his build script too
User10: User8 can you please review https://code.launchpad.net/~elopio/snappy/test_free_space/+merge/270137 ?
User6: User11 ping
User8: elopio, as far as my go knowledge goes it looks ok
User8: (thats not very far, mind you :) )
User11: Chipaca, pong
User10: User8 that's good enough, thanks :)
 * sergiusens was having issues with irssi and freenode
 * sergiusens said, hell it is Friday and installed xchat
User8: +1
User8: xchart FTW
User8: *xchat
User12: User11 Did my long rambling e-mail about ubuntu packages make any sense?
User11: tedg, heh, I'm trying to figure it out, I think I understood the TODOs and the WANTs
User12: User11 K :-)
User11: tedg, let me get back to you in a bit
User10: User8 when I run parted on the bbb it tells me that there's one block not used.
User10: is that a bug, or is that ok?
User8: hmm, do you have the exact output ?
User8: it should be fine i think
User10: Warning: Not all of the space available to /dev/vda appears to be used, you can
User10: fix the GPT to use all of the space (an extra 1 blocks) or continue with the
User10: current setting?
User10: User8 ^
User8: elopio, huh ? thats BBB ??
User10: User8 sorry, no, kvm.
User8: ah
User8: well, doesn it resize fine beyond that ?
User10: User8 it has 0.04% free at the end, so my test passes.
User10: I just have to ignore the stderr. What I'm asking is if that's ok to ignore.
User8: 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
User10: ack.
User11: ogra_, elopio that error bust me too when doing the uflash PoC with the recvory image
User8: sergiusens, even when not resized ?
User8: hmm, livecd-rootfs doesnt have anything about subgid subuid ...
User8: sergiusens, aha ... bug 1475749 ... seems slangasek already fixed it in wily
User13: bug 1475749 in Canonical System Image "usermod --add-subuids fails for users not in /etc/passwd" [High,New] https://launchpad.net/bugs/1475749
User11: ogra_, even when no resized (just when adding a partiton on top of something that already exists)
User8: sergiusens, ok, thats a general issue with the kvm GPT then ... funny that i dont see it here
User10: happy anniversary dholbach!
User8: not yet :P
User5: thanks elopio :)
User8: but yeah, welcome to the ten-year-club dholbach :)
User5: thanks ogra_ :)
User3: nice weekend everyone o/
User14: User8 bug #1475749> and in vivid-proposed, if you want to verify the fix
User15: 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>
User13: bug 1475749 in Canonical System Image "usermod --add-subuids fails for users not in /etc/passwd" [High,New] https://launchpad.net/bugs/1475749
User8: slangasek, thanks, will do
 * Chipaca -> mostly EOW
User11: 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)
User11: mvo, still around? if yes, do you know how the conflict resolution rules are for that 'packages' entry?
User4: User11 what packages entry exactly?
User11: mvo, in the spec, at the very end
User12: User11 Sorry, I missed your message. Someone else already has "ted" on Freenode :-(
User12: User11 I like the idea of letting dpkg do the filtering, I think it knows more about what can overlap and what can't.
User12: Seems like they haven't used it in 9 weeks thoughâ¦ getting close.
User11: tedg, I'll need to take that one level higher the decision making process; for now pull/unpack are done before pull now
User11: 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
User12: User11 Makes sense
User11: tedg, do you have code for the pip plugin somewhere?
User12: User11 Pushed to here: lp:~ted/snapcraft/python-pip
User12: Might be kinda hacked though
User12: I was screwing with it trying to get it to work.
User11: tedg, no worries
User11: tedg, why don't you call pip install directly?
User11: tedg, and another question, why not just do pip install from the build stage?
User12: User11 You mean by importing the module?
User11: tedg, yeah
User12: User11 In that case it was a python2 vs 3 thing.
User12: User11 I was trying to keep things in pull for the LP builders.
User12: User11 I think we'd also have to have the module in the host system to include it? No?
User11: 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
User11: tedg and I don't grep that last line about includes :-)
User12: User11 I don't think it goes over the complete cycle if you just do "snapcraft pull" as a command, no?
User12: User11 I think it only does the complete cycle for each with all.
User12: User11 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.
User11: tedg, ah, good point on calling 'snapcraft pull'
User11: tedg, yeah, let's not install pip on the host :-)
User11: tedg, but depending on python-pip brings in pip into the part
User12: User11 Seems like we need a way to specify build-deps vs. runtime deps I guess.
User12: User11 I could, for instance, have a python build system like Waf but not want python in my snap.
User11: tedg, isn't that what filesets is for?
User11: filesets/stage and filesets/snap respectively
User12: User11 Yeah, but then if you're talking about an ubuntu package you'd need to know all the files in the package.
User12: User11 We could perhaps auto-populate that.
User11: tedg, I'd exclude by default, then again; the staging terminology in snapcraft is confusing
User11: there are two stages in a stage it seems; the part stage and the general stage
User12: Huh, I didn't realize that.
User11: tedg, oh wait, nevermind
User11: tedg, I had that stuck on my mind for a while and now I self settled it
User12: Left brain vs. Right brain. Fight! ;-)
User11: tedg, btw, this is why I asked about pip 'bin/python2: cannot import name IncompleteRead; 'pip' is a package and cannot be directly executed'
User11: tedg, and calling pip directly pkg_resources.DistributionNotFound: pip==1.5.6
User12: User11 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.
User12: User11 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.
User11: tedg, might be necessary; in any case I think I can say that with my latest MP you are unblocked :-)
User11: I asked mvo to review the code on Monday as well (and to have him validate it against the spec).
User11: 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
User12: User11 Cool, I'll update on Monday. Oh, wait, Tuesday :-)
User12: User11 Thanks!
snappy
Ubuntu IRC