[00:43] <psusi> oh blast.. I forgot who it was that I was talking to at UDS about the ability to extend a mounted partition... related to some ubuntu cloud tool that does that automatically when the guest boots and detects the image drive has grown
[00:44] <broder> you were talking to smoser
[00:44] <psusi> bingo!
[00:44] <psusi> I got a patch ;)
[02:05] <smoser> broder, thank you for saying my name. i was just talking to alexbligh today about somebody i talked to at UDS about just that!
[02:22] <micahg> smoser: would it make any sense to have a server-common seed that server and cloud-image could derive from?
[02:22] <smoser> maybe. its not that big of a deal, but yeah, that would have fixed this.
[02:22] <smoser> i actually was surprised that 'cloud-image' was not a superset of server
[02:24] <micahg> smoser: it could be if you want it to be :)
[02:24] <smoser> its not like there has been a significant amount of change on either one of those.
[02:26] <smoser> just glancing, it seems as it if it might be a proper superset minus wireless-tools and wpasupplicant
[02:26] <smoser> which are quite dubious for "server"
[02:43] <smoser> micahg, you probably know the answer to this.
[02:43] <smoser> Vcs-Git: git://git.debian.org/git/users/eevans/python-boto
[02:44] <smoser> if we have a delta package, should i change that to XS-Debian-Vcs-Git
[02:44] <smoser> ?
[02:44] <micahg> smoser: not a bad idea
[02:45] <smoser> is there some policy that dictates that? i did it previously, but was just following stuff i saw elsewher.e
[02:47] <micahg> smoser: https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html
[02:48] <smoser> gracias.
[02:48] <micahg> smoser: so, I guess the answer is yes :)
[03:23] <smoser> lool, around ?
[04:00] <smoser> lool, the ping above was wrt https://code.launchpad.net/~smoser/ubuntu/precise/python-boto/merge-2.0.2/+merge/83891
[06:28] <pitti> Good morning
[07:31] <pitti> stgraber: hm, I have a little difficulty with the XMLRPC tracker interface -- how do I get a list of all builds, or builds that belong to a particular product?
[07:31] <pitti> (either is fine)
[07:31] <pitti> stgraber: there doesn't seem to be a drupal.builds.get_list() function that corresponds to drupal.qatracker.products.get_list() or the one for milestones
[07:33] <pitti> stgraber: ah, seems you indeed mentioned that a few days ago
[08:01] <dholbach> good morning
[09:11] <jibel> apw, pitti bug 898040
[09:11] <jibel> 'invalid argument' on bare metal
[09:12] <apw> jibel, joy thanks
[09:12] <pitti> urgh
[09:12] <pitti> so it seems running it in VMs just makes this a lot more likely
[09:12] <pitti> jibel: thanks for finding this
[09:13] <apw> well that fits with my tracing, i can't see the einval on the qemu side
[09:14] <pitti> jibel: want me to dupe, or are you?
[09:14] <pitti> anyway, doing
[09:15] <jibel> pitti, thanks
[09:15] <pitti> but again i386
[09:15] <pitti> jibel: did you ever see this on amd64?
[09:15] <pitti> I think you said "once", but I'm not sure any more
[09:17] <pitti> oh joy
[09:17] <pitti> apw: I wonder if /bin/cp actually would fail on EINVAL
[09:17]  * pitti RTFS
[09:17] <apw> pitti, i don't see how it can't it seems mad to continue
[09:19] <pitti> yeah, it should
[09:20] <pitti>           if (full_write (dest_fd, buf, n) != n)
[09:20] <pitti>             {
[09:20] <pitti>               error (0, errno, _("writing %s"), quote (dst_name));
[09:20] <pitti> that looks ok
[09:20] <pitti>   if (close (dest_desc) < 0)
[09:20] <pitti>     {
[09:20] <pitti>       error (0, errno, _("closing %s"), quote (dst_name));
[09:20] <pitti> so in theory, using cp -r on large trees sohuld also reproduce this; I tried a couple of times, but didn't hit it
[09:21] <pitti> I'll start my cp.py attempted reproducer again and let it run for a while
[09:38] <pitti> apw: meh, I ran http://people.canonical.com/~pitti/tmp/cp.py with the whole /rofs/usr to /mnt (which is /dev/vda) twice now, and no error at all
[09:38] <pitti> what on earth could a write() from ubiquity do differently?
[09:38] <pitti> cp.py is pretty much exactly what ubiquity does
[09:39] <apw> pitti, your cp.py uses the same copy library, can you strace it copying one file
[09:39] <apw> so we can see which of the 3 or 4 ways of copying a file it really uses
[09:39] <pitti> well, it's not a "copy library", it's just shoveling read() into write()
[09:40]  * apw has been assuming its an open() read() write() close() job
[09:41]  * apw is looking at the kernel to see if he can see any new EINVALs, and is going to try instrumenting them on metal to find out how expensive that might be
[09:42] <pitti> apw: http://paste.ubuntu.com/754641/
[09:42] <pitti> nothing that really looks surprising
[09:42] <pitti> no O_DIRECT
[09:43] <pitti> I don't know about the mmap() calls, I suppose read() is using those internally for more efficiency
[09:43] <apw> pitti, that is one reason i'd like a trace off of a small copy if thats easy, using the same python fragment
[09:44] <pitti> ah, you mean a small file which is a single block?
[09:44] <apw> perhaps one small and one large, in case it has different behaviour
[09:46] <pitti> apw: http://paste.ubuntu.com/754643/ is the full strace for cp.py /rofs/lib/init/
[09:46] <pitti> which is just one small file
[09:46] <pitti> line 1011 starts the "real" action
[09:47] <pitti> doesn't really look any different than the previous one, though
[09:50] <apw> so using mmap for buffer space, and open read write close
[09:51] <pitti> right
[09:51] <pitti> interestingly, cp doesn't seem to use mmap()
[09:51] <apw> though it looks like the write buffer is allocated during the python write call
[09:51] <pitti> oh, wait, it does
[09:52] <pitti> just a little earlier
[09:52] <apw> so possibly an einval from there might trigger it
[09:52] <pitti> apw: but it's triggered during write() or even close()
[09:52] <pitti> why would close() allocate an mmap?
[09:53] <apw> close seems less likely indeed
[09:53] <pitti> I now started an infinite cp.py loop, to see whether this ever triggers
[09:54] <pitti> I need to run out for a bit, I'll set this sit there
[09:54] <apw> sounds like a plan
[09:54] <pitti> yay irreducible test cases
[09:54] <apw> my machine has stopped reproducing with O/O now, wtf
[09:55] <apw> Ouserspace+Okernel in the HOST
[09:55] <pitti> I also let the same loop run on my workstation, to compare
[10:17] <dholbach> not too many followed up on the packaging guide rename thread - are there generally any objections or further thoughts?
[10:21] <seb128> dholbach, go for it! ;-)
[10:25] <pitti> apw: hmm, no error after half an hour
[10:25] <apw> pitti, and i am 5 installs in with no reproduce
[10:25] <apw> pitti, its like it only happens on a tuesday
[10:26] <pitti> apw: it's bug 248619 all over again!
[10:30] <apw> pitti, heh, don't even joke
[10:34] <apw> pitti, 7 conscutive installs, no reproduce, this is with the exact same setup i had 1/2 reproduce by yesterday
[10:36] <pitti> apw: kvm clearly needs a "snapshot" command which accepts an argument like "10 seconds ago"
[10:36] <apw> :)
[10:50] <apw> pitti, i've done a normal boot with write instrumented to report when it returns EINVAL and i get no reports on a normal boot, so it may be possible to add diagnostics if you can replace the kernel in your image and are still able to reproduce, right now i am not
[11:01] <pitti> I'm through 5 iterations of cp.py
[11:01] <pitti> and no reproduction
[11:01] <pitti> seems I need to actually run ubiquity again
[11:01] <pitti> doing now
[11:12] <pitti> apw: ah, seems we mid-air collided on bug 891688
[11:12] <pitti> apw: I updated the bug for the root cause/reproducer and sent it to Karel
[11:13] <dholbach> ogra_, thanks a bunch
[11:13] <ogra_> :)
[11:13] <dholbach> I'll add it to our "list of news sources"
[11:14] <dholbach> ogra_, do you know if the logs or minutes are kept in a somewhere more structured place than "irclogs.u.c"?
[11:14] <apw> pitti, heh cool.  so definatly userspace, i'll pass that on
[11:14] <pitti> apw: yes, it's just mishandling of /etc/mtab
[11:14] <pitti> /proc/mounts is fine
[11:15] <pitti> apw: so I don't think "running out of option space" is a real problem here
[11:15] <ogra_> dholbach, not sure, ask skaet, i havent seen a meeting summary yet ... i guess the weekly ML posts are more intresting than the meeting logs
[11:15] <apw> pitti, no in that case all my comments are moot :)
[11:15] <pitti> darn, /etc/mtab should have died twenty years ago
[11:15] <pitti> it's such an utterly, utterly broken concept
[11:15] <tumbleweed> dholbach: https://wiki.ubuntu.com/ReleaseTeam/Meeting/ ?
[11:15]  * dholbach hugs tumbleweed and ogra_
[11:15] <dholbach> thanks :-)
[11:15] <apw> pitti, i know, i thought the point of /proc/mounts was to replace it ...
[11:16] <pitti> apw: one of these days we need to reattempt to make it a symlink
[11:16] <ogra_> tumbleweed, the team pages arent kept up to date by all teams anymore though ... since we switched to ML posts
[11:16] <pitti> apw: I think the main problem is that you can't add options to /proc/mounts which aren't known by the kernel
[11:16] <pitti> apw: such as the helper=udisks stuff
[11:17] <apw> yeah ... sigh
[11:17] <tumbleweed> ogra_: the page for the last meeting has links to the ML posts
[11:17] <ogra_> ah !
[11:18]  * ogra_ didnt know ... i stopped looking at the wiki apart from my own team page that i still keep in sync with the ML post
[11:18] <tumbleweed> yeah, can't say I've looked at the mmuch either, but skaet tends to be organised :)
[11:20] <Laney> I like how we still get called out
[11:20]  * Laney stares at his feet
[11:39] <lool> doko: bash FTBFSed on armhf just as reported in Debian #650349; I see a change to debian/rules related to ncurses -> tinfo but from my reading it's probably not enough to solve the failure, so I suppose some other change fixed it in Debian experimental; do you plan to merge the experimental version since Ubuntu already tracks 4.2?  or would you know which other ncurses -> tinfo fix might be needed?
[11:48] <doko> lool: after alpha1
[11:50] <lool> doko: Ok; thanks
[12:14] <jincreator> Hi. How can I get iso file of Ubuntu Precise Alpha 1?
[12:19] <pitti> jincreator: http://91.189.93.73 -> click on the image you want, and follow "download information"
[12:24] <jincreator> pitti: Thanks. By the way, I find the link(http://cdimage.ubuntu.com/releases/precise/alpha-1/ ) at Ubuntu wiki. What is it?
[12:25] <pitti> jincreator: it's not released yet
[12:25] <pitti> those are candidate images
[12:25] <pitti> a1 release is tomorrow
[12:25] <pitti> right now we are testing
[12:26] <jincreator> pitti: Oh, I see. Again, thanks!
[12:28] <doko> Riddell, ScottK: does k3b need to recommend vcdimager, or is a Suggests enough?
[12:33] <apw> pitti, i am perplexed, i am now 10/10 good installs today, i simply cannot trigger it anymore
[12:45] <doko> jelmer, subunit ping
[13:04] <jelmer> hi doko, I'm looking at making python-junitxml a suggests
[13:05] <doko> jelmer, thanks. reviewed and promoted pygpgme in the meantime
[13:10] <Riddell> doko: feel free to downgrade that to a suggests
[13:10] <mdeslaur> @pilot in
[14:20] <stgraber> pitti: yep :) do you know exactly what you need to get from the tracker? is that just a list of builds or do you also need testcases and results?
[14:20] <quadrispro> hallo everybody
[14:22] <stgraber> pitti: if all you need is the list of builds associated to a given milestone and their status, I can give you that in an hour or so
[14:23] <zyga> hi
[14:23] <zyga> is multiarch supposed to work on all libraries or am I doing something wrong: http://paste.ubuntu.com/754907/
[14:23] <zyga> tryin to install libncurses5:i386 on x86_64
[14:24] <stgraber> zyga: no, packages need to be updated to work with multi-arch (there's a Multi-Arch field that needs to be set for it to work)
[14:25] <zyga> stgraber, right, I thought by default it would all libraries to co-exist
[14:25] <zyga> okay that explains it
[14:25] <zyga> ah
[14:25] <stgraber> the result for libncurses5:i386 on precise seems to be a bit better (doesn't fail), though it still wants to remove libc-bin :)
[14:25] <zyga> since I'm here
[14:26] <zyga> stgraber, ogra said you know something about nbd and booting with nbd instead of nfs as root
[14:26] <zyga> heh :)
[14:26] <stgraber> zyga: well, the packager needs to make sure that you won't get path conflicts between the different architectures
[14:26] <stgraber> yeah, I know a bit about nbd :)
[14:26] <stgraber> we use it for to mount our root filesystem on thin clients with LTSP
[14:27] <stgraber> mounting a squashfs over nbd, then adding overlayfs/aufs on top of that and using that as our root
[14:27] <zyga> stgraber, is it very hard to set up? What do you need to install on both sides to make it work, what kind of kernel cmdline do you need to use?
[14:29] <stgraber> depends what you want to do with it, do you want read/write nbd (exporting an ext4 filesystem) or read-only + overlay? (the former only works if you have a single client)
[14:31] <zyga> stgraber, right now I want a single client
[14:31] <zyga> stgraber, essentially I want to boot my arm board with rootfs stored elsewhere
[14:31] <zyga> stgraber, ideally I'd like to have overlays but I have no experience with either filesystem you mentioned
[14:32] <zyga> stgraber, today I just want to boot with remote rootfs
[14:33] <stgraber> ok, so you'll need to install nbd-client in that rootfs, run update-initramfs and then copy the initrd and kernel to your board (or SD card or TFTP server depending how you want to boot)
[14:33] <stgraber> on the server side, you'll need to install nbd-server and then configure it to export your image
[14:34] <zyga> stgraber, ok, how do I configure the server?
[14:34] <zyga> stgraber, I can probably do the rest
[14:34] <stgraber> you'll need to modifiy /etc/nbd-server/config (or create it), let me find you an example
[14:34] <zyga> stgraber, and how do you set the bootcmd :-)
[14:34] <zyga> thanks!
[14:36] <stgraber> zyga: http://paste.ubuntu.com/754933
[14:36] <stgraber> that .img needs to be a partition image, not a disk image
[14:38] <zyga> stgraber, looking
[14:38] <stgraber> boot parameters should be nbdsrv=1.2.3.4 nbdport=my_example
[14:38] <zyga> ok
[14:39] <zyga> excellent, let me try that
[14:39] <zyga> stgraber, is it a big step up from that to a many-client-devices-at-once?
[14:39] <stgraber> note that I usually use a custom initrd script for LTSP so these boot parameters are based from what I see in the code, never tried it myself ;)
[14:40] <stgraber> oh, and you may need to add root=/dev/nbd0 it's not clear from the script whether you need to or not
[14:40] <stgraber> zyga: it'd be pretty different yes. On the server side, you could just add readonly=true but on the client side you'll need a different initrd script, the easiest would probably be to copy ltsp's
[14:41] <Daviey> Anyone know why grub2 has a hissyfit if you put &&'s into the kernel command line?
[14:41] <zyga> ok
[14:41] <zyga> let me start with the easy part then! thanks a lot
[14:41] <stgraber> (AFAICS nbd's own initrd script doesn't do the overlay magic)
[14:45] <smoser> lool, thanks for your review and upload of python-boto i was really only asking you for review because i dropped your "run tests" patch.
[15:07] <lool> smoser: Yep, I guessed so; I agree that since the results were ignored that's best; would be ideal to fix the testsuite but I didn't check what it would require
[15:07] <smoser> well, it does AWS operations, so its absolutely going to fail in a buildd environment.
[15:08] <smoser> (i added a long winded commit message with other reasons too)
[15:25] <agateau> hey, building a package in a pbuilder, I get a message complaining about debian/changelog not existing ( http://paste.ubuntu.com/754978 ) the file is here though, and running dpkg-buildpackage from within the pbuilder shell works fine. Has anyone already seen that?
[15:28] <geser> no, try added a hook which gives you a shell when a build fails and check if every file is there where you expect it
[15:31] <agateau> geser: I already did that. The file is there, and running dpkg-buildpackage from the pbuilder shell works fine.
[15:52] <agateau> ah, found it... my mistake, created a dir where I shouldn't have.
[15:59] <mpt> pitti, hi, I'm trying to report a bug with ubuntu-bug, but every time I get "Cannot connect to crash database, please check your Internet connection. HTTP Error 503: Service Unavailable"
[15:59] <mpt> but I can access Launchpad just fine.
[16:07] <pitti> stgraber: for now we just need builds
[16:07] <stgraber> pitti: ok, I'll get you a builds.get_list once my IRC meeting is over
[16:07] <pitti> stgraber: for now I just updated the script to use screenscraping, but long-term, XMLRPC is of course more elegant and robust
[16:07] <pitti> stgraber: not urgent, but thanks!
[16:09] <pitti> mpt: hm, can you see https://launchpad.net/+storeblob
[16:12] <mpt> pitti, yes, I can access that page. Should I upload the crash file directly there?
[16:12] <pitti> mpt: no, .crash files have the wrong format, that won't work
[16:12] <pitti> mpt: when exactly do you get the error?
[16:13] <pitti> mpt: when it's collecting information, or after you click on "send"?
[16:13] <mpt> pitti, when the upload is about 80, 90% complete.
[16:13] <pitti> ah, so it's already uploading
[16:13] <pitti> mpt: how big is that .crash file?
[16:13] <pitti> maybe it's LP timing out when the upload gets too big or something
[16:13] <mpt> pitti, 114.4 MB.
[16:14] <pitti> uh, huge
[16:14] <pitti> maybe LP has an internal limit there
[16:14] <pitti> I figure it has, to prevent a DoS from uploading GBs of data there
[16:15] <SpamapS> mterry: thanks for fixing sphinxsearch btw!
[16:15] <SpamapS> mterry: that one had me vexed
[16:16] <mpt> pitti, so is there any practical way to work around it? Or is this bug just unreportable?
[16:18] <pitti> mpt: I wouldn't know a way to work around it
[16:21] <mpt> ok, thanks for your time pitti
[16:21] <pitti> mpt: sorry that I can't be of more help
[16:24] <hallyn> slangasek, if you wanted to talk about the udev/lvm bug, ping me
[16:25] <mterry> SpamapS, :) had me vexed too, with its stupid dpatch system.  /me welcomes our new quilt overlords
[16:32] <stgraber> pitti: http://paste.ubuntu.com/755087/
[16:43] <SpamapS> mterry: did you by any chance push your patch upstream? The stable release of 2.0.3 is eminent
[16:46] <mterry> SpamapS, sent it to debian, but didn't upstream
[16:46] <mterry> SpamapS, will do so now
[16:46] <stgraber> pitti: http://paste.ubuntu.com/755110/ for a patch on top of ubuntu-archive-tools, updates isotracker_xmlrpc for both the build notes (patch I gave you yesterday) and adding a get_build function. Also adds products-status-tracker.py which gives you a list of product on the tracker and their status
[16:47] <stgraber> pitti: have fun (heading out for lunch now, be back in an hour or so if you have questions)
[16:47] <hallyn> Hm, I'm getting build failures for qemu-linaro
[16:47]  * hallyn checks when last time was that it built
[16:48] <pitti> stgraber: thanks! I'll commit that
[16:54] <SpamapS> mterry: awesome
[16:59] <pitti> jamespage, wendar: we also see on https://jenkins.qa.ubuntu.com/view/Precise/ that precise-upgrade failed; that's also one of the things to keep alive every day
[16:59] <mdeslaur> @pilot out
[16:59] <pitti> jamespage, wendar: it looks like a temporary glitch due to buildd arch desync, but I'll have a closer look tomorrow
[17:00] <micahg> pitti: for new firefox locales in updates, do we just have to wait for new langpack runs in natty/oneiric to add support for them?
[17:01] <pitti> micahg: no, langpacks don't have firefox translations any more
[17:02] <micahg> pitti: right, but we have the recommends on the firefox langpack, or is there another mechanism already to pick them up?
[17:02] <pitti> micahg: the recommends are just transitional to fix upgrades
[17:02] <pitti> for a language we didn't alreayd have before, we don't need them
[17:03] <micahg> ok, so for a new language, language selector should just DTRT
[17:03] <pitti> right
[17:03] <micahg> ok, thanks
[17:03] <pitti> need to run now, good night everyone!
[17:03] <hallyn> how do i specify i386 libs in build-depends?
[17:05] <infinity> hallyn: You don't.
[17:06] <hallyn> it's supposed to just do the right thing?
[17:06] <infinity> hallyn: If your application is i386, you build it on i386 and make it multi-arch, so it can be installed on amd64.
[17:07] <hallyn> slangasek, lool: ^ does that mean qemu-linaro build process needs to change?
[17:07] <hallyn> (right now it tries to always build qemu-i386 when building on amd64)
[17:07] <hallyn> (and that is failing for me building in a precise chroot on porter-amd64)
[17:08] <infinity> hallyn: What build-deps does that need?
[17:08] <hallyn> i'm getting complaints about -lnss3 -lnssutil3 -lsmime3 -lssl3
[17:08] <infinity> hallyn: If it's just lib6, there's libc6-dev-i386
[17:08] <infinity> Oh, yeah.  For that dep chain, you really want to be doing as outlined above.
[17:09] <hallyn> think i just destroyed the dchroot
[17:10] <hallyn> apt-get install libnss3:i386 seemed to mess up dpkg
[17:11] <infinity> In the precise chroot?
[17:13] <infinity> libc-bin has been removed.  Well done.
[17:13] <lool> hallyn: qemu-i386 is called i386 because it emulates an i386 CPU, but it doesn't need specifically i386 libs to build, it needs whatever host libs you need
[17:14] <hallyn> lool: hm, yeah
[17:14] <lool> it it complained about missing nss3, then you probably want a libnss-dev bdep
[17:14] <hallyn> so why isn't it finding libnss
[17:14] <hallyn> that's installed
[17:14] <hallyn> maybe i need to add /lib/x86-whatever to LDLIBS
[17:14] <infinity> With the state of this chroot, I'd be shocked if you could find any libraries. :P
[17:15] <lool> hallyn: Might be easier to look into with a build log + source package to poke at
[17:16] <hallyn> lool: i hit it with the current precise version, both in a new schroot on my laptop, and the precise dchroot on porter-amd64.c.c
[17:16] <hallyn> (iow, i think if it gets rebuilt in archive i expect it to FTBFS)
[17:17] <lool> hallyn: so just rebuilding qemu-kvm on amd64?
[17:17] <hallyn> qemu-linaro
[17:17] <lool> ok
[17:21] <mvo> barry: turns out that the release-upgrader trunk has overlayfs support already, I forogot that I commited it, but in order to play with it you will have to edit DistUpgradeAufs.py and change line 74, its not doing any auto detection currently
[17:37] <doko> Daviey,  o suds: python-suds
[17:37] <doko>    [Reverse-Build-Depends: fence-agents]
[17:37] <doko> please add a MIR (or zul)
[17:43] <Daviey> doko: ack
[17:45] <Daviey> doko: bug 898268
[18:06] <mvo> barry: hm, lucid->precise using aufs actually looks encouraging, its much faster han I remember from the last time I tried it. but its still not fast at all, especially for big data sets
[18:07] <barry> mvo: i used aufs in some vms and yes, it sure appeared to slow things down quite a bit
[18:09] <mvo> barry: I will give it a go on real hardware soon, but its better than i expeced. but dinner time for me
[18:09] <barry> mvo: thanks!
[18:10] <mvo> yw
[18:56] <psusi> smoser: I have a working patch for online partition resize if you're still interested in that
[18:56] <smoser> well, yes i am.
[18:56] <smoser> i saw ebroder's referenceof me a couple hours later.
[18:56] <smoser> i had just been talking about that with someone yesterday
[18:57] <psusi> cool... I patched the kernel and parted to be able to use it... successfully extended an ext4 partition online, and extended and also shrank a btrfs one ;)
[18:58] <psusi> did you say you have your own utility that does that resize right now before the root is mounted?
[18:58] <psusi> or do you use parted or something?
[18:59] <smoser> i script sfdisk
[19:00] <psusi> could you switch to parted without much difficulty?
[19:00] <smoser> probably. selection of sfdisk was to easily fit in ramdisk.
[19:00] <smoser> http://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/view/head:/bin/growpart
[19:02] <smoser> but if you're removing the need to fit in ramdisk, then parted would probably be ok. its already in the images.
[19:02] <psusi> ok.. well, if yuo can refactor the script to run from upstart instead of in the initramfs, and call parted, should be able to easily maximize the partition that way
[19:02] <psusi> yea
[19:02] <smoser> doesn't matter when it runs, though right ?
[19:02] <psusi> right
[19:03] <psusi> you tell parted to resize the partition, and give it the new end point, and it makes it so... though it does currently have an annoying warning, are you sure? prompt... not sure if that goes away when you put it in batch mode
[19:14] <lool> hallyn: I could build qemu-linaro here, but I might have extra bdeps on my system
[19:15] <lool> hallyn: so what error were you getting exactly?
[19:21] <hallyn> lool: how exactly did you build?
[19:21] <lool> hallyn: debuild
[19:21] <hallyn> sbuild?  pbuilder?  debian/rules build
[19:21] <hallyn> ok
[19:21] <lool> with all build-depsinstalled
[19:22] <hallyn> instlaled with 'apt-get build-dep'?
[19:23] <lool> hallyn: with apt-get install, but that doesn't realy matter; passed dpkg-checkbuilddeps
[19:23] <hallyn> never heard of that one
[19:23] <lool> it's run as part of dpkg-buildpackage
[19:24] <lool> hallyn: do you have a build log?
[19:24] <dantti> cnd: was that patch alread applied? cause I don't see it on the upstream branch
[19:24] <hallyn> i think i've deleted it.  i'll redo it with sbuild
[19:24] <cnd> dantti, which patch?
[19:24] <cnd> the hid power patch?
[19:24] <dantti> yup
[19:25] <cnd> dantti, which branch are you looking at?
[19:26] <dantti> cnd: nvm, I was looking at the wrong file, I thought the patch would be at hid-core, but it is at hid-input..
[19:27] <cnd> ok
[19:27] <cnd> git log should show you the commit
[19:28] <dantti> cnd: btw I tryed to make the module and then insmod on my stock ubuntu kernel but it does not work :P I even tried to reboot on that kernel but it stuck, do you use it?
[19:28] <cnd> dantti, you have to build it using the ubuntu headers
[19:28] <cnd> go into the hid directory
[19:28] <cnd> then run:
[19:28] <cnd> make -C /lib/modules/`uname -r`/build M=`pwd` modules
[19:28] <dantti> I did make modules SUBDIRS=drivers/hid (worked for apt-get source linux...)
[19:29] <cnd> it worked for apt-get source linux because the headers were the same
[19:29] <cnd> but the headers are different between upstream linux and ubuntu
[19:29] <dantti> cnd: hmm right, thanks going home now, hopefully tomorrow I finish this patch :D
[19:30] <cnd> cool
[19:30] <cnd> good luck!
[20:31] <dantti> cnd: I have several compile errors doing that..
[20:42] <cnd> dantti, there may be too much skew between the ubuntu kernel and the upstream kernel then
[20:42] <cnd> the easiest solution is to boot an ubuntu mainline kernel
[20:42] <cnd> and then try to compile again
[20:42] <cnd> but that assumes the current mainline runs well on your machine :)
[20:42] <dobey> can someoene push libubuntuone in oneiric-proposed out to oneiric-updates, and copy it to precise please? it's been in -proposed for 5 weeks, and i just realized it didn't get pushed out, and there was some confusion between it and the banshee update, so the bug didn't get marked as verification-done :(
[20:45] <micahg> dobey: a new version should be uploaded to precise after alpha1
[20:46] <dantti> cnd: right, I tryied to boot on it but it didn't, I'll try again..
[20:47] <dobey> micahg: and the oneiric update?
[20:47] <micahg> dobey: that's up to the SRU team :)
[20:51] <hallyn> lool, I can't reproduce build failure now  (sigh)  sorry
[21:07] <smoser> psusi, i'm interested in seeing what you have. that would be nice.
[21:07] <psusi> smoser: I posted them today to the parted-devel mailing list
[21:11] <smoser> psusi, i see. thanks. i'll try poking at that later. are you expecting to put the kernel portion to lkml ?
[21:12] <psusi> smoser: yes
[21:13] <psusi> right now I'm adding another new BLKPG operation to get the partition info so parted can stop using the long depreciated HDIO_GETGEO ioctl to figure out where the partition starts
[21:35] <smoser> anyone have ideas on "device or resource busy" log info at https://jenkins.qa.ubuntu.com/job/precise-server-ec2/ARCH=i386,REGION=us-west-1,STORAGE=instance-store,TEST=cloud-config,label=ubuntu-server-ec2-testing/1/artifact/None/i386/m1.small/instance-store/i-835a3dc4/uec2-20111130-1920-5d6ee3bc489541-terminated.console.txt
[21:36] <smoser> the fsk.swap is understood (bad fstab) but xvda2 should have a filesystem in it and a fstab entry like: /dev/xvda2 /opt auto defaults,noexec,comment=cloudconfig 0 2
[21:39] <lool> hallyn: I got a full build completed here too in sbuild
[21:40] <hallyn> lool: no idea what went wrong with my manual builds.  All deps were installed, i swear.  i'll save my ego by saying it was a transient error :)
[21:57] <smoser> ok... i opened a bug with some more info. bug 898373.
[21:57] <smoser> it seems strange to me.
[22:01] <psusi> smoser: maybe a race with udev probing the partition?
[22:02] <smoser> hm.. i'mnot sure. i would have hough tby the time mountall is running partition tables would have to be read.
[22:02] <smoser> but it definitely seems like a race to me.
[22:04] <smoser> anyone know of a "hello world" debian package ? i just need a package to put into a ppa, the simpler the better.
[22:05] <psusi> the table may be, but udev may still be running blkid and such on the partitions
[22:26] <broder> smoser: you mean like..."hello"? :)
[22:27] <broder> (alternatively, hello-debhelper)
[22:28] <tumbleweed> hello doesn't quite fit the bill of the simpler the better, but it does answer the first part of the question
[22:30] <broder> "it does if you run mv debian/rules-dh debian/rules before uploading"
[22:30] <broder> err, hello-debhelper, i guess
[22:45] <SpamapS> How does one definitively say that something is unseeded?
[22:45] <SpamapS> seems like something the +source page on launchpad should show
[22:48] <broder> SpamapS: ./edit_acl.py can query by source package
[22:48] <stgraber> SpamapS: "grep -r <package> ~/data/code/seeds/" where that directory contains an up to date version of all the seeds, quite a few seeds also have a matching task, so if any of the binary packages have a Task assigned to them, they're definitely seeded
[22:48] <broder> (from lp:ubuntu-archive-tools)
[22:49] <stgraber> broder: won't edit_acl just query for packageset?
[22:49] <broder> oh, right. seed, not packageset
[22:49] <stgraber> (a few package sets are based on seeds, not all of them)
[22:49] <SpamapS> Seems like that would be a worthwhile ubuntu-dev-tools addition..
[22:50] <broder> i saw "launchpad" and went chasing down the lplib side of things
[22:50] <stgraber> SpamapS: well, having a central location with the list would be nice (maybe it alreaddy exists though), then we can work on a tool to use it :)
[22:50] <stgraber> yeah, AFAIK Launchpad doesn't know what a seed is
[22:50] <broder> right
[22:50] <StevenK> It does, sort of.
[22:50] <StevenK> The publisher runs germinate
[22:51] <StevenK> But really only internal to the publisher
[22:51] <stgraber> StevenK: to set the Task field on the binary packages?
[22:52] <StevenK> Yup.
[22:53] <stgraber> ideally package sets and tasks really should be made visible/more visible on LP, we could deprecate a whole bunch of scripts once that's done (like the one I wrote to dump all the package sets on a web server) :)
[22:55] <StevenK> Right, package sets are already exported over the API, what would help?
[22:56] <stgraber> seeing them in the UI would be kind of nice I'd think
[22:56] <stgraber> like I'd expect to see that ubuntu/precise/+source/edubuntu-menueditor is in the edubuntu package set
[22:57] <StevenK> ubuntu/precise/+packageset/<> could work too
[22:59] <stgraber> yeah, not having to point users/developers to the API would be a nice improvement :)
[23:00] <stgraber> a "what can this person upload" page might be interesting as well (again easy with the API, not so much from the web UI)
[23:01] <StevenK> stgraber: Right, so adding a portlet to ubuntu/precise/+source/edubuntu-menueditor that says "Packagesets: <x> <y>" is easy. Making those a link to a packageset is much harder.
[23:03] <tumbleweed> stgraber: also, bug 876554
[23:04] <micahg> tumbleweed: that can be done today, take a look at edit_acl.py in ubuntu-archive-tools
[23:04] <tumbleweed> and yes, a tool for parsing your dump would be nice (assuming it'll be around for a while)
[23:04] <tumbleweed> micahg: yeah, I know, it's just not that important