=== asac_ is now known as asac [00:10] im back as well [00:11] kees: ill upload it and do the testcase if you want [00:15] slangasek: sorry I wasnt available I was getting some dental work done and was at the dentist [00:15] slangasek: um dental work done and family commitments [00:16] zul: that'd be great, thanks. [01:36] Hi ember [01:36] hey emgent, sup [01:51] zul: ah, so kees volunteered you sight-unseen, ok then... :) [01:52] slangasek: im trying to test the debdiff now after I get this dapper vm setup [01:54] guys [02:00] slangasek: well, I'd volunteered zul and mathiaz since they've had the most apache-touching recently and I was already swamped with equally time-critical things. :) [02:08] <[Relic]> how long does it take between a report and the time someone actually looks at fixing something? [02:09] [Relic]: It depends, usually. What's the bug number, I'll have a quick look. [02:10] <[Relic]> basically it is snatching a c file from a newer kernel module and inserting to bring ubuntu 45nm core temp support -> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/235119 [02:10] Launchpad bug 235119 in linux "Coretemp outdated / can't show 45nm core temps" [Undecided,New] [02:10] Ahhhh. [02:12] <[Relic]> I run blender which is CPU rendering so I really want to know my core temp. I know multiple people have verified it can work if lm-sensors 3.0.2 sensors detect and the new coretemp.c with the model x17s are brought in [02:43] <[Relic]> I need a bigger back buffer when they do that :( [02:44] can I float this idea guys? http://software-libre.rudd-o.com/Streams_vs._documents [02:46] Seems a bit OT here. More of an upstream thing. [02:52] * davidm is away: [02:53] Rudd-O: ever heard of plan9? [03:21] Rudd-O: Is that in response to bryce's blog post? [03:29] heh i got a bug report about openoffice from the head of osnews [03:30] the name sounded familar so i googled it and found out it was her [03:30] calc: In Launchpad? [03:31] StevenK: yea [03:32] calc: Bug number? :-) [03:32] Eugenia? [03:32] 242557 [03:32] yea [03:33] bug #242557 [03:33] Launchpad bug 242557 in openoffice.org "I can't uninstall openoffice without destroying my system" [Undecided,Invalid] https://launchpad.net/bugs/242557 [03:33] probably should just find the original bug where it is filed and merge it rather than invalid [03:38] calc: im not sure if it counts as invasion of privacy, but I found knuth's LP account [03:42] Polling it for activity is maybe an invasion of pricacy, but LP accounts have become part of our public faces. [03:43] so... lets say that I have a raid 6 device that I want to do an install on, and an up-and-running hardy box to plug it into... is there a wubi-like thing, or do I get to reboot the machine and do the install from there? [03:47] morning people [03:51] lamont: debootstrap? [03:51] well, yeah. [03:51] I want all the rest of it to turn it into a hardy desktop machine [03:51] preferrably without doing all those steps manually [03:51] (because that sucks) [03:51] (all 6 or 7 times I've done it before...) [03:52] OK. debootstrap target; chroot target /bin/bash; apt-get install ubuntu-desktop [03:52] that's about 16 steps short of clueful [03:52] Well, yes. It could use a pretty GUI python wrapper, and misses a few bits. [03:53] How about booting the ISO in a VM attached to the device? [03:54] "few". heh [03:56] lamont: What? Do you really want such niceties as a locale, or host definitions? [03:59] default first user, partitioner, etc [04:02] Right. `kvm -hdc /dev/sdq ubuntu-hardy.iso` [04:03] Or virt-manager. I've found that nice. [04:03] Err `kvm -hdc /dev/sdq -cdrom ubuntu-hardy.iso` [04:03] RAOF: For installing Ubuntu Desktop on a bare RAID device? [04:04] Start the interface as root and I'm pretty sure you can use a raw device as the target. [04:05] kvm also works, of course, and may be more obvious given a browse of the man page ;) [04:19] * pwnguin should try out kvm now that ubuntu-mobile is offering an image [04:51] does the -generic kernel have kvm support, or does that require the kvm kernel? [04:51] -generic has kvm support. Is there a kvm kernel? Do you mean -xen, or -openvt, or something? [04:52] -generic supports kvm as a guest, and runs within kvm [04:52] hmm [04:52] Daniel T Chen 2005-08-07 Expired on 2007-08-16 [04:53] Your hardware must support kvm though. Otherwise virtualbox and kqemu are alternates (but you have to build your own kqemu modules from source) === LucidFox is now known as GamingFox === nenolod is now known as happinessturtle [05:54] hrm... 3TB ext3 FS on RAID5 takes a while to create... :-( [06:03] win 20 [06:03] It's such a badly named command. [06:07] Nah. It's awesome. [06:07] lifeless: Can I win 30? :) [06:07] that would #squeak [06:08] * StevenK wonders about Unicode code points for small caps === GamingFox is now known as LucidFox [06:30] good morning === happinessturtle is now known as nenolod [06:30] bryce: still there? :) === dholbach_ is now known as dholbach [06:59] Good morning [07:00] Morning pitti [07:00] good $TZ_TIME_OF_DAY [07:00] cjwatson_: chiark> my server moved to a new IP, could that gbe it? [07:01] cjwatson_: s/gbe/be/ [07:01] tjaalton: do you keep X packages in bzr/git/something? [07:02] tjaalton: if not, I'm going to drop our patch on xserver-xorg-input-vmmouse (as the scaling was fixed in the new upstream release too and fixing the scaling twice broke the mouse in kvm for me) [07:07] pitti: oh, btw, i already upload the debdiff for openvpn [07:07] nxvl: debdiff? [07:07] it's a (fake)sync, isn't it? not much of a diff [07:07] Bug #242537 [07:07] Launchpad bug 242537 in openvpn "Please sync openvpn 2.1~rc7-5 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/242537 [07:08] pitti: yep, but i don't have any other way to upload my work [07:08] pitti: the diff is the debian changes aplied to our old package [07:08] nxvl: ah, I see; heh, I could just have done it myself, but thanks [07:08] :D [07:08] * pitti uploads [07:09] it was just a bitsize fix [07:09] just one line [07:12] nxvl: uploaded [07:13] :D [07:13] thanks [08:13] hi seb128 [08:13] hello dholbach [08:18] dholbach: yeah [08:19] bryce: did the xserver-xorg-input-vmmouse upload myself - hope that was OK [08:19] * pitti hugs dholbach for the vmmouse fix -- the previous version drove me mad in intrepid :) [08:19] dholbach: sure that's probably fine. I was just looking at that bug earlier [08:20] hey seb128, bonjour [08:20] guten tag pitti [08:28] i'm trying to build a gdal package with gdal support but i am getting this error in hardy , feisty gutsy it did work fine [08:28] http://pastebin.ca/1055587 [08:29] i'm building using that command dpkg-buildpacka [08:29] ge -rfakeroot [08:29] i'm building using that command dpkg-buildpackage -rfakeroot [08:35] Riddell: oooh! https://svn.pardus.org.tr/uludag/trunk/PolicyKit-kde/ [08:35] Riddell: just read a mail on hal@ that it is near completion === shadowxp is now known as shadow [08:57] * ogra wonders why Keybuk set bug 98955 to fix committed ... [08:57] Launchpad bug 98955 in upstart "logd not running" [Medium,In progress] https://launchpad.net/bugs/98955 [09:08] sorry for question not strictly related to ubuntu development, but i think you devs might be the only ones able to answer: how is the CAP_SYS_RAWIO capability handled in ubuntu? i am developing a userspace USB driver and read with ioctl from /dev/bus/usb/*/*. on my gentoo machine, no problem. on ubuntu i get "Operation not permitted" and the only thing i can imagine is that the RAWIO capability is disabled. on the other hand, it doesn't even [09:08] work using sudo. any ideas? [09:09] berzerka: you could try in #ubuntu-kernel [09:09] dholbach: oh, right. thank you! [09:10] np :) === tkamppeter_ is now known as tkamppeter === mdz_ is now known as mdz [09:52] thekorn: bug.activity is GREAT - thanks [09:52] dholbach: what is that? [09:53] >>> import launchpadbugs.connector as Connector [09:53] >>> Bug = Connector.ConnectBug() [09:53] >>> bug = Bug(242667) [09:53] >>> print bug.activity [09:53] [, , , ] [09:53] >>> [09:55] dholbach: ah, nice ;-) [10:02] dholbach, oh, good to hear it's working and you like it [10:02] but this shows me that I have to update the wiki more often [10:02] :) === cjwatson_ is now known as cjwatson [10:07] pitti: could be - what's the new IP, and I'll pass it on? [10:08] cjwatson: 213.9.93.70 [10:08] cjwatson: (host piware.de) [10:08] pitti: ah yes, doesn't match slave0.ns.chiark.greenend.org.uk [10:09] Heh, wasn't piware moved like a week ago? :-) [10:11] can take a little while to notice slave NS misconfiguration [10:11] the cron job that whines about it on that system is weekly, I think [10:12] Ah. [10:16] which reminds me, I should set the DNS TTL back to a day (currently an hour) [10:16] ogra: because a "fix" has been committed ? [10:17] * StevenK checks what his TTL is, since he recently moved his domain too [10:19] ArneGoetje: does the anthy patch apply for you? it doesn't for me [10:21] dholbach: against the hardy version? [10:21] dholbach: works for me [10:21] Keybuk, well, removing the code is not actually what i would call a fix :) [10:22] (unless i understood the upstream commit wrong) [10:22] ArneGoetje: sorry - my mistake, I'll update it to be "intrepid" instead of "hardy [10:22] dholbach: ? [10:23] ArneGoetje: the changelog says 'hardy' [10:24] ArneGoetje: ah - we have a newer version in intrepid - that why it does not apply [10:25] dholbach: correct [10:25] the patch needs a bit of updating then [10:25] dholbach: in that case, I'll test if the bug still applies for intrepid [10:26] well, we can't upload to hardy any more (or it needs to follow StableReleaseUpdates) [10:26] dholbach: bug fix? [10:27] still it'd be hardy-proposed instead of hardy and it needs to go into intrepid first anyway [10:27] https://wiki.ubuntu.com/StableReleaseUpdates [10:27] MacSlow, 01_fix_missing_semicolon.patch ? thats sweet :) [10:27] dholbach: my guess is that the issue has been fixed in intrepid already... but I'll check that [10:28] ogra, mvo found that one actually [10:28] ogra: it closes the bug [10:28] ArneGoetje: gracias [10:28] Keybuk, it doesnt fix logging, so i'd disagree [10:28] ogra: where "Fix Committed" means that the bug will be made invalid [10:28] ogra, I didn't even see this failing initially with all the tons of output pbuilder creates [10:28] since there's no "Something that will make this bug Invalid Committed" status ;) [10:29] well, isnt it to be fixed in upstart in the end ? and isnt the final fix to have a proper boot log ? [10:29] no [10:29] ogra, Keybuk: I informed the debian maintainer and also filed a bug upstream with the patch attached... as it was still not fixed in trunk... odd isn't it... in over four months nobody ran into that [10:29] * ogra doesnt get the logic [10:30] MacSlow, well, i poked on that package quite often in the past and slangasek as well ... seems nobody of us ever spotted it [10:31] are we meant to keep confflags-gnome and confflags-gtk in debian/rules for goffice? debian only uses confflags and does not make a distinction between gtk- and gnome-related flags. [10:31] MacSlow, xubuntu :) [10:31] they dont want gnome libs [10:32] mvo, sorry for implicitly stealing your credit regarding the semicolon-patch regarding planner! [10:32] ogra, so how should I go about merging that? just put everything in confflags? [10:33] MacSlow, ask one of the xubuntu people i'd say, they likely have touched that before and created that diff [10:33] MacSlow: no worries [10:33] you likely want to keep the ubuntu changes the way they are [10:34] not sure if there is more involved than confflags [10:34] debian doesn't build a gtk variant [10:34] there might be additional patches [10:34] hm... ok... gnumeric is a tougher beast than anticipated... goffice (newer version needed for gnumeric) looks nasty to me merge-wise [10:35] ogra, MacSlow: it seems to be releated/triggered by the new glib [10:35] ogra: I don't really have any solution for logging yet [10:35] mvo, yes... dependencies of goffice introduced the need for a newer glib [10:36] removing the claim of the feature is the best fix for now [10:37] Keybuk, yeah understood, i just didnt get the logic first place [10:37] seb128, hm... debian enables static libraries for goffice... do we want that too? [10:37] * MacSlow assumes not [10:38] usually we want what debian do if we don't have strong reason to not take the changes [10:38] there might be an entry in the changelog explaining it ;) [10:39] ogra: Fix Committed is a silly status really [10:39] at least, according to the LP model [10:39] yeah [10:39] you should be able to add bug tasks for a branch [10:39] then that branch could be marked Invalid/Wont Fix or something [10:39] well, cant you just mark it Invalid and make it hishlist for a new app ? [10:39] *whishlist [10:39] then when I make a release on that branch, the bug status should be automatically copied to the task for the upstream package [10:39] Keybuk: it's not when you have the packaging in bzr and if launchpad was updated automatically on commit [10:40] seb128: err, ? [10:40] seb128: that doesn't make what I said invalid [10:40] ogra: Fix Committed is a silly status really [10:40] that was a reply to that [10:40] seb128: the next line is more important ;) [10:40] right, but I was typing then ;-) [10:41] in your use, and my model, committing would set the branch bug task to "Fix Released" [10:41] right [10:41] releasing would set the upstream bug task to "Fix Released" [10:41] packaging would set the distro bug task to "Fix Released" [10:41] hum, not really [10:41] Fix Committed is silly because you can do more than commit Fixes :p [10:41] fix released is when the update is pushed in the distribution [10:41] right, that's what I mean - couldn't think of a good word :P [10:42] what does the -i option in dh_ in debian/rules? [10:43] man debhelper [10:43] MacSlow: ^- [10:44] Keybuk: "fixed" would do it ... [10:44] cjwatson, ah thanks [10:45] cjwatson: ? [10:46] seb128, for goffice we still don't want -dbg pakcages?! that's currently stated in a comment in goffice's debian/rules [10:47] Keybuk: for a branch status, "fixed" would be sufficient and clearer, and would avoid seb's "is when the update is pushed in the distribution" objection which I guess is due to the "released" word [10:47] cjwatson: ogra disagrees that "fixed" is clear [10:47] ogra: oh? [10:47] cjwatson: an upstream upstart bug is marked "Fix Committed" [10:48] Keybuk: oh, I'm not objecting to "invalid" also being an option [10:48] because trunk no longer has any code relevant to the bug, so will make it Invalid [10:48] ah [10:48] got you [10:48] ogra: (never mind) [10:48] yeah if you get rid of "Fix Committed" then you can rename "Fix Released" to just "Fixed" [10:48] right, that's what I mean [10:48] which is a much better name without any nasty overtones of "go get it now, pull, pull" [10:49] MacSlow: not sure, I've no real opinion either way [10:50] MacSlow: we have dbgsym so we don't need those, and since the ubuntu version builds several variants the dbg build might require changes [10:50] ok [10:54] dholbach: the bug still exists in intrepid [10:55] so in any case it needs fixing in intrepid first and the patch needs some changes [10:57] pitti: You said in bug #228969 that libcairo was gone from Intrepid, but it survives to this day. [10:57] Launchpad bug 228969 in libcairo "Remove libcairo from Ubuntu" [Wishlist,Fix released] https://launchpad.net/bugs/228969 [10:59] wgrant: weird; I was sure I saw it in process-removals, hmm [10:59] wgrant: doing again then [11:00] pitti: Soyuz does seem to often have issues with overrides, removals or syncs not sticking... [11:00] Thanks. [11:02] done === sebner_ is now known as sebner [11:07] TheMuso: hi, did you see mail about the PS3 kernel yesterday? [11:11] dholbach: the patch itself (debian/patches/06_fix_vu_dpatch.dpatch) also works against the intrepid version and fixes the issue [11:12] ArneGoetje: right... the debdiff needs updating [11:12] dholbach: I will make a new debdiff for intrepid [11:13] ArneGoetje: I think I synced scim-hangul a bit too quickly the other day and some changes were still required, could you have a look and maybe reapply those if that's the case since you probably know better about those [11:14] seb128: err... ok, I'll try [11:14] ArneGoetje: ROCK [11:15] dholbach: ? [11:15] ArneGoetje: "great" :) [11:15] dholbach: ah :D [11:16] * ArneGoetje -> dinner, bbl === sebner_ is now known as sebner [11:30] * pitti arghs at Python's optparse, which suddenly yields a "UnicodeDecodeError: 'ascii' codec can't decode byte" blabla exception [11:31] (suddenly -> after .mo files got installed) [11:32] blabla exception ? oh, thats an evil error :) [11:33] after some googling it seems I need to do some black magic with setting sys.stdout to a codecs wrapper, or something [11:33] but heck -- why should I even care??? [11:34] i'm building using that command dpkg-buildpackage -rfakeroot [11:34] http://pastebin.ca/1055587 [11:34] any idea ? [11:34] this is gdal package from apt-get source gdal [11:34] . [11:36] ; [11:37] ؟ [11:39] DarKnesS_WolF: seems like a bug, if you're building it on the version of Ubuntu it was released for with all the build-dependencies installed === halex_ is now known as halex [11:53] DarKnesS_WolF: you have a lib in /usr/local/lib which gdal links against [11:53] oh yes, I can't read [11:57] pitti: see e.g. http://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu/annotate/cjwatson%40canonical.com-20080620095615-rf3zpj1maa556ro1?file_id=helptogfxboot.py-20071128181623-fb6n7sukjr5u2r1p-4 [11:59] cjwatson: I saw some similar recipes, but those were all hacks which hardcoded a particular encoding [11:59] cjwatson: I think it is http://bugs.python.org/issue2931 [11:59] I haven't tried the patch yet [12:00] (hm, that wasn't it) [12:00] cjwatson: thanks for the pointer, anyway! [12:01] cjwatson: I don't see why I should even care in my Python programs (from a 10,000 m perspective) [12:01] the output encoding is determined by the locale, and the input encoding is given in the .mo files and thus by gettext [12:02] pitti: replacing 'UTF-8' with locale.getpreferredencoding() should deal with the hardcoding objection (not tested though) [12:02] pitti: and I certainly agree the current situation is hopeless [12:02] oh, good idea [12:03] pitti: see also http://ewx.livejournal.com/457086.html for the last time I remember discussing this [12:05] monining [12:12] cjwatson: hm, it still fails even with your recipe; *gnargh*; anyway, I'll try again after lunch [12:15] could someone poke MOM to get a fresh overview ? [12:23] ogra: ? mom is running fine [12:23] last update was 11 minutes ago [12:23] Keybuk, how often ? would be good to raise the frequency [12:23] hourly [12:23] at least on days before import freeze that makes the overview easier [12:23] hmm [12:23] k [12:24] the frequency is not limited by malaise [12:24] well, i still see ltsp and moodle on there [12:24] how long ago did you upload the merged packages? [12:24] moodle has not yet been published [12:24] moodle was 15mins ago, ltsp 1h [12:25] ltsp was only published 20 minutes ago [12:25] MoM can't really run faster than the publisher ;-) [12:25] bah, add a time machine :P [12:25] when MoM runs at 1105Z, it will see ltsp in the archive (assuming the mirror happens by then) [12:25] right [12:25] thats enough then [12:25] it will pick up moodle once that has been published and mirrored, which may be as early as 1105Z, but may not [12:26] yeah [12:26] the average MoM run takes between 50 and 70 minutes right now [12:26] so it really can't go any faster [12:26] i'm just lazy and dont want to compare changes with MoM all the time to find what to grab and whats gone [12:26] *-changes [12:26] actually, the 1105Z was cancelled due to lock [12:27] so the next run will be 1205Z (the 1005Z only just finished) [12:27] ogra: surely you have a vague idea which source packages you've touched in the last couple of hours? ;-) [12:27] Keybuk, mine are done, i'm starting to grab others === ara is now known as ara_lunch [12:35] mvo: erm, there seems to be a problem with the changelog of the ubuntu-artwork package (dch complains that the maintainer field is empty) [12:35] mvo: as you were the last one to update it, I thought I should ask you ;-) [12:36] kwwii: let me check [12:36] mvo: just look at the last two changelog entries and you'll see the problems [12:39] bryce: so, err, around/ [12:39] I'm having a little X problem [12:42] kwwii: please update, I fixed it in bzr [12:43] kwwii: the " -- author ..." line was empty, emacs is less picky about it, I guess this is why I forgot about it [12:43] mvo: excellent, thanks for the help :-) [12:51] how in the hell is one supposed to use bzr with launchpad these days? the crappy lp:~path stuff is simply confusing and shitty [12:51] boah, sorry for going off but this is silliness [12:51] ? [12:52] bzr branch lp:upstart [12:52] how is it that when I do a pull, make changes, commit and then try to push and it gives me grief about using http? [12:52] saves remembering a URL [12:52] the lp stuff is exactly what is messing it up it seems [12:52] because you don't have permission to push to that branch? [12:52] what's the branch? [12:52] no, I do [12:52] did you at the point you branched? [12:53] lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu [12:53] yepp [12:53] bzr info says? [12:53] kwwii: you need to run "bzr lp-login " I expect [12:53] kwwii@clive:~/bzr/test/u-art$ bzr push lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu [12:53] bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-art-pkg/ubuntu-artwork/ubuntu/.bzr/repository/lock): Transport operation not possible: http does not support mkdir() [12:53] kwwii: and then "bzr push --remember lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu" [12:53] kwwii: bzr launchpad-login [12:53] newer bzr gives you a hint about this. [12:54] I just pushed another branch under ~ubuntu-art-pkg and it worked fine [12:54] lifeless: doesn't it use $USER if not set? [12:54] Keybuk: no [12:54] lifeless: isn't that a bit silly? [12:54] Keybuk: root cause - because it doesn't fallback to http on ssh login failure [12:54] Keybuk: hey, $code-I-didn't-writely-urs [12:55] Keybuk: or a better answer - incremental improvements [12:55] Keybuk: if the non-fallback bug is fixed, using $USER becomes plausible [12:56] But wouldn't that mean it would ask all conceivable key passphrases even if you didn't have an LP account? [12:56] kwwii, do you have launchpad_username set in ~/.bazaar/bazaar.conf ? [12:57] random bug of the day [12:57] bootchart still runs in recovery mode [12:57] hey, then you can see how fast you get to the rootshell ... thats a feature :P [12:58] ogra: and you see how long you were in the root shell [12:58] and you see what you did while there, and how long that took [12:58] and then you see how long the rest of the boot took after you resume [12:58] hehe [12:58] and then you see your disk full with a massive svg [12:58] kwwii: you can continue to use the old-style bzr+ssh:// URLs [12:59] kwwii: replace lp: with bzr+ssh:// in the above and it should work (as a means of getting you past the immediate problem) [12:59] Keybuk: stop viewing your porn in recovery mode [12:59] lol [12:59] cjwatson: I'm trying to get X to work :-/ [13:00] and get a bigger disk ... [13:01] maybe usplash related [13:01] is there any interest in making luks accessible to the masses in ubuntu? [13:02] seems rather quiet on launchpad, https://blueprints.launchpad.net/ubuntu/+spec/ubiquity-luks-support [13:07] donri: that's blocked on general support in ubiquity for other than plain block devices [13:08] donri: we do need to do that anyway, e.g. for dmraid-support, but it's hard to give much attention to ubiquity-luks-support until that's in place [13:08] cjwatson: sorry, what? I don't understand. [13:08] donri: plain block devices == /dev/sda1 and such [13:08] as in ordinary hard disks [13:08] in order to support luks, ubiquity needs to have support for more complicated block devices in general [13:08] ok... [13:08] which is a fair amount of work to put in place, although it is on the plan [13:09] i see, that's good. [13:09] soren, ping from yesterday. I misread the patch for libvirt. Please ignore the comment in #ovirt [13:12] cjwatson: Hasn't that been targetted to every release greater than or equal to Edgy? [13:15] wgrant, and you still didnt send a patch :( [13:15] SEJeff: Alright, cool :) [13:15] * soren goes to lunch [13:15] soren, FYI: I'm trying to get ovirt wui running in Ubuntu. We'll see [13:16] is anyone doing hotkey-setup ? [13:20] ogra: I wasn't exactly complaining. Just wondering if it really was still coming RSN. [13:21] wgrant, sure, it will if someone sends a patch (hint hint) ;) [13:21] wgrant, its not that we dont want to do it, its a manpower issue [13:30] cjwatson: in which upcoming ubuntu release do you estimate it might be included? [13:31] lamont: Could you please add virtualbox-ose in Pas to lpia? [13:32] lool: "# Please email comments, corrections to james@nocrew.org, lamont@debian.org and/or adconrad@debian.org. See ChangeLog for history." [13:32] for tracking purposes and all that [13:32] Okay === ara_lunch is now known as ara [13:34] * lamont finds himself annoyed at the encrypted filesystem stuff [13:34] lamont: Mailed [13:34] wgrant: *cough* [13:34] "/boot/grub/stage1 not read correctly" [13:34] wgrant: actually not so much for edgy because we knew it was blocked on the partitioner reimplementation [13:34] donri: hard to say at present, sorry; I think intrepid+1 would probably be a decent guess [13:35] lool: updated [13:36] lamont: Thanks; when do Ubuntu buildds notice? [13:36] lool: that'd be an infinity question (in about 3.5 hours when he should be around) [13:37] the answer for debian is "generally within 24-48 hours" [13:37] not sure how quickly ubuntu will notice [13:37] lamont: Ok; as long as it's automatic, I don't care [13:37] entirely [13:39] lucas: hi. I am doing the ruby1.9 merge for ubuntu, and was doing a schroot amd64 intrepid build before upload, and found that it hangs at test_copy_stream_rbuf(TestIO). Have you seen this before? (I saw your name in the changelog of the Debian package) [13:40] \sh: ^ have you seen this in your previous merges? [13:41] cjwatson: so 9.04? that's good, it's in october 2009 scary things start happening in sweden. [13:42]