[08:08] <harmw> hm, isn't there something like a codestandard on readthedocs..? I know of some openstack projects that have just that
[12:40] <smoser> philips, it doesn't actually matter there.
[12:40] <smoser> the '-' get converted to '_'.
[12:41] <smoser> harmw, suck.
[12:42] <smoser> i don't know what to do about that really. i like that there is a version string in the image, but I really wish that
[12:42] <smoser> a.) i didn't screw that up
[12:42] <smoser> b.) i could properly "promote" a release
[12:42] <smoser> (ie, rename)
[12:43] <smoser> build-release doens't do anything that shouldn't be doable in a ci build
[12:47] <smoser> harmw, the '~pre1' is by design (versus '-pre1'). '~' in dpkg means "less than".
[13:04] <harmw> uhm, whats wrong with committing a change in bin/build-release since that's where you keep track of version numbering :)
[13:05] <harmw> and using the ~ annoyed me, I wasn't aware of a dpkg design thingy
[13:06] <harmw> but whats wrong with using - instead of ~? 0.3.2-pre1 would still be the same as 0.3.2~pre1, right?
[13:30] <smoser> harmw, 0.3.2-pre1 is > 0.3.2
[13:31] <smoser> $ dpkg --compare-versions 0.3.2-pre1 gt 0.3.2 && echo yes, greater || echo no
[13:31] <smoser> yes, greater
[13:31] <harmw> ah like that
[13:32] <smoser> the issue with committing a change in bin/build-release is that then you cant feed it a tag as input.
[13:33] <smoser> the other issue is that then 0.3.2~pre4 can't just be "promoted" to 0.3.2 
[13:33] <smoser> as it has that yucky string in it.
[13:33] <smoser> i don tknow. its over thinking things i know. 
[13:37] <harmw> can't we just go from 0.3.2rc1 to 0.3.2?
[13:37] <smoser> what do you mean?
[13:38] <harmw> nah, just thinking out loud
[13:44] <smoser> harmw, i'm ok to punt on that, and just change that one thing and call it 0.3.2.
[13:44] <smoser> assuming my kernel change didn't cause anything else
[13:45] <harmw> it builds just fine, I haven't tested the new image though
[13:45] <harmw> planning to do just that tonight
[13:53] <smoser> crap.
[13:53] <smoser>  /dev/null has bad perms in the tarball.
[13:55] <smoser> and disk image
[14:04] <harmw> and you only updated the kernel :p stupid kernel
[14:04] <smoser> ?
[14:04] <smoser> oh. no. it was a bug before.
[14:04] <smoser> fix in hand.
[14:05] <smoser> and it explains why running 'cirros-status' as root would not get you network debug info
[14:05] <harmw> hm, so my images are broken as well?
[14:05] <smoser> right
[14:05] <harmw> (since I'm not using bin/bla)
[14:06] <smoser> fixed and pushed.
[14:06] <harmw> nice, now I only need to wait till midnight :p
[14:06] <smoser> you weren't using bin/bla ?
[14:06] <smoser> at all ?
[14:06] <smoser> you probably were.
[14:07] <harmw> haha, then I'm not going to get the fun out of this commit
[14:07] <harmw> I was using the steps you describe in README
[14:07] <smoser> you were. xmakedeves gets called from
[14:07] <smoser>  * build disk images using bin/bundle
[14:07] <smoser>    $ sudo ./bin/bundle -v output/$ARCH/rootfs.tar download/kernel-$ARCH.deb output/$ARCH/images
[14:08] <harmw> bin/bundle, yes
[14:08] <harmw> not bin/build-release
[14:08] <smoser> right. build-release just does what is in the README
[14:08] <smoser> its proably almost identical to yours
[14:08] <harmw> indeed it is :)
[14:08] <harmw> (though mine doesn't upload to LP )
[14:09] <smoser> it doesn't upload
[14:09] <smoser> where did you think it did that ?
[14:09] <smoser> (actually, theres a bug that *i*haven't uploaded to launchpad :)
[14:15] <harmw> hm well I thought to have skimmed over some bits that pushed something to LP
[14:15]  * harmw should probably just stop thinking every know and then
[17:50] <harmw> smoser: I see 0.3.2 is tagged as such?
[17:50] <harmw> I'm auto-building in about 10 minutes
[17:51] <smoser> no tag
[17:51] <harmw> just ned to think of something to only build a new buildroot when it is really -really- neded
[17:52] <smoser> i'mo building trunk right now.
[17:52] <smoser> i'll put it on download and just not call it
[17:52] <smoser> but can point you at it
[17:53] <harmw> fair enough :)
[17:53] <smoser> its built i386, amd64 and is 10 minutes into arm
[17:54] <smoser> i suspect 20 minutes it'll finish.
[17:54] <harmw> ah yes, the other archs - I'm still only building x86_64
[17:54] <harmw> btw why is make br-source done witj i386 as arch?
[17:54] <smoser> just because
[17:55] <harmw> hmk, and its wrong to have it build with $ARCH ?
[17:55] <harmw> i386/arm/x86_64 ?
[17:56] <smoser> probably, yeah. they do have different packages though i think.
[17:57] <smoser> i forget. 
[17:57] <harmw> well having it build against x86_64 went great, haven't tried it on arm/i386 though
[18:00] <smoser> oh. right. it iwll work.
[18:00] <smoser> and it i think does it anyway.
[18:00] <smoser> the explicit step is just to have the download done
[18:00] <smoser> so that it hits cache 
[18:01] <harmw> ah lol
[18:01] <harmw> well its caching those downloads anyway
[18:01] <harmw> any thoughts on this btw https://bugs.launchpad.net/cirros/+bug/1292973 ?
[18:07] <harmw> harlowja: news from the bsd front?
[18:07] <harlowja> harmw ah, let me see if i can get sean in, didn't chat last week
[18:07] <harlowja> pinging now
[18:08] <harmw> hm, sucks my server hasn't got enough firepower left to host a jenkins instance for c-i nightlies
[18:09] <smoser> harmw, is that busted in current buildroot ?
[18:09] <smoser> we should forward there if it is
[18:09] <harmw> yea, it regards the 2012.05 buildroot
[18:09] <harmw> or just upgrde buildroot
[18:10] <harmw> which i've already done in some branch
[18:15] <harlowja> harmw no response ping from sean, i'll let u know
[18:15] <harlowja> will get him in here or bug him about whats happening/status
[18:16] <smoser> http://paste.ubuntu.com/7109590/
[18:17] <smoser> harmw, ^ . its odd. i built on an azure instance to a tmpfs, thkning it would go crazy faster.
[18:17] <smoser> but it did not.
[18:19] <smoser> harmw, http://download.cirros-cloud.net/pre-release/0.3.2/
[18:29] <harmw> tmpfs, nice, I was thinking of going that way aswell
[18:30] <harmw> my buildroot is 2G, thats gonna be a close call...
[18:31] <smoser> well, 7G was within a cuple hundred meg.
[18:31] <smoser> but that included everything.
[18:32] <harmw> 2.1GB, without the downloads folder
[18:32] <harmw> oh and its still compiling
[18:33] <harmw> ah no, just finishing up
[18:33] <harmw> took 33 minutes
[18:34] <harmw> http://buildservice.weites.com/cirros/trunk/
[18:34] <harmw> nice :>
[18:35] <harmw> smoser: do you have reallife results from ARM-based cirros boots?
[18:35] <smoser> no. other than lxc.
[18:36] <harmw> cool, I'm expecting a cubietruck which has hardware virt stuff
[18:36] <smoser> oh nice.
[18:37] <smoser> canonical has some such hardware, and its possible people here have used it.
[18:37] <smoser> but i'm not sure actually. i really did it for lxc. but i'd like to have it known functional on som eactual hardware
[18:37] <smoser> and at some point would want arm64 stuff too
[18:38] <harmw> it should arrive next week or so
[18:38] <harmw> and then Ill load it up as nova-compute node