[00:26] <psusi> cjwatson, still not had a chance to look at the logs and figure out the partman-auto problem?
[00:31] <cjwatson> psusi: I'm focusing on a wubi bug at the moment; it's taking a lot of attention
[00:33] <psusi> oh joy
[00:34] <cjwatson> I'll try to look at your bug next
[00:36] <psusi> I also made those cleanups you wanted for the two branches to merge... I used Conflicts instead of Breaks though, that ok?
[00:36] <cjwatson> no, please use Breaks
[00:37] <cjwatson> Conflicts << is generally bad
[00:37] <cjwatson> nowadays the policy manual has explicit language about when you should use Conflicts and when Breaks
[00:37] <psusi> hrm... why is that?  I read that the difference is that breaks still allows the other package to be installed, just not configured... well who cares of dpkg thinks it is configured or not, if the lib is there, it's going to be used and thus, cause breakage, won't it?
[00:37] <cjwatson> see the policy manual
[00:37] <cjwatson> I won't merge a branch that uses Conflicts
[00:38] <cjwatson> (in this way)
[00:38] <cjwatson> it makes apt's job unnecessarily harder on upgrade
[00:38] <psusi> hrm...
[00:38]  * psusi runs and changes the Conflicts to Breaks
[00:39] <cjwatson> thanks for making the other cleanups; I haven't looked at them yet for much the same reason
[00:48] <psusi> changed Conflicted to Breaks and pushed... man I love emacs
[00:58] <psusi> honestly, how does gnome-system-monitor manage to burn through ~20% of the cpu when audacious playing mp3s doesn't even register as 1%...
[00:59] <azeem> playing mp3s is a common hw-accelerated operation, no?
[01:01] <psusi> azeem, no
[01:02]  * psusi remembers winamp using 90% of his 90 MHz pentium cpu, hehe.... come a long way since then...
[01:09] <azeem> psusi: pentiums didn't have hw-acceleration, no?
[01:17] <psusi> azeem, hw-acceleration is a function of... hardware... like a 3d video card... mp3s are decoded in software still... even idling alone at the low power 1.6 GHz state, this core i5-2500k is something like 100 times faster than that p-90... then you throw in the fact that it's got 4 cores... and somehow gnome-system-monitor manages to use a significant chunk of that... go figure.
[01:22] <TheMuso> psusi: I've found that gnome-system-monitor has been a CPU hog in the past too, no idea why though.
[01:34] <directhex> the cpu meter drawing algorithm is abysmal?
[01:38] <psusi> do I have to create a dedicated proxy object to use dbus_g_proxy_connect_signal(), then attach a signal handler to that proxy object, or can I use an existing gobject class that already has the desired signal handler and pass that AS the proxy to dbus_g_proxy_connect_signal?
[01:43] <directhex> that's the true answer btw. gnome-system-monitor is so slow because the resources graphs are written in about the most idiotic way they could be. see also http://audidude.com/?p=404
[03:39] <psusi> nothing like blaring loud rock ( Korn ) on a hacking session while the wife is out seeing a play with a friend
[03:44]  * RAOF prefers Cowboy Bebop for hacking.  Or Radiohead when cooking up an undodly abomination unto nature of a regex, like now.
[03:45]  * StevenK is hacking LP while listing to Rammstein
[03:45] <StevenK> Er. Listening
[03:46] <RAOF> Not drunk-hacking? :)
[03:47] <StevenK> No, just having my brain going faster than my fingers. Like usual.
[03:48] <RAOF> Hm.  dpkg-buildpackage is suggesting that missing build-deps is going to become a fatal error for -S in the future.
[03:48] <RAOF> That would be annoying.
[03:48] <StevenK> Indeed
[03:49] <StevenK> I routinely build source packages with only debhelper installed.
[03:50] <psusi> ohh, Rammestein... there's something I've not listened to in quite some time...
[03:59] <RAOF> Run along now evolution.  Daddy wants his 2GiB back for the build tmpfs.
[04:06] <hallyn> I compiled my own version of open-vm-dkms (using sbuild -d natty -A *.dsc), but installing the resulting open-vm-dkms*.deb gives me:
[04:06] <hallyn> This package appears to be a binaries-only package you will not be able to build against kernel 2.6.38-5-generic since the package source was not provided
[04:06] <hallyn> i don't know what htat means
[04:07] <StevenK> RAOF: Thunderbird is only taking up 1GiB here
[04:08] <RAOF> Yeah, I've tried Thunderbird in the past.  I've always found it to be just a little bit more crap than Evolution.
[04:09] <StevenK> Maybe we just should just ship mutt at the default MUA.
[04:11] <psusi> odd... my tibrd process only has 121m rss atm... and I have a LOT of very LARGE mailboxes ;)
[04:12] <StevenK> My thunderbird's RSS is 300MiB, but virtual is a touch over 1GiB
[04:12] <psusi> I have been wondering lately why so many processes seem to have such massive virtual sizes when rss is reasonable
[04:13] <RAOF> Leprachauns.
[04:14] <TheMuso> Interesting discussion at a time when I am poindering trying anothe email client for a bit...
[04:14] <TheMuso> pondering
[04:14] <TheMuso> And evolution is off the list already...
[04:15] <psusi> I keep meaning to make myself try mutt
[04:15] <TheMuso> ...and xul apps are off the list, as they perform poorly with Orca atm.
[04:15] <StevenK> TheMuso: I suggest telnet
[04:15] <TheMuso> StevenK: lol
[04:15] <maco> TheMuso: and kmail as well of course....
[04:16] <TheMuso> maco: Of course...
[04:16] <maco> oh right! there's a qt at spi tarball im supposed to turn into a package soonish
[04:16] <TheMuso> I was thinking about Claws actually, as its GTK based.
[04:16] <psusi> then again, I find myself getting sucked more and more into emacs lately... been using it for terminal windows now... probably going to end up using gnus to read mail
[04:16] <maco> by which i mean 2 days ago
[04:16] <StevenK> TheMuso: That isn't dead yet?
[04:16] <RAOF> I tried claws for a while.
[04:16]  * psusi tries claws too for a while
[04:16] <TheMuso> StevenK: Not sure, haven't really started investigating yet.
[04:16] <StevenK> I used to used emacs to read mail ...
[04:18] <RAOF> Claws wasn't really better than evolution in any way I found, didn't have calendar stuff, and didn't have my 50-odd filtering rules.
[04:18] <StevenK> That's what server-side filtering is for.
[04:18] <psusi> filtering rules go on the server.. sieve for the winz ;)
[04:18] <TheMuso> Well calendaring doesn't matter as I have to use Evolution to do that anyways *grumble grumble*, and filtering is done server side for me.
[04:19] <StevenK> RAOF: If you use dovecot for IMAP (and you should!), setting up sieve is easy and full of win
[04:20]  * psusi been using dovecot for imap with sieve on his server at work for a few years now
[04:21] <RAOF> StevenK: Why would I run an imap server?
[04:21] <StevenK> RAOF: For your personal e-mail?
[04:21] <RAOF> Eh; google's got that.
[04:21] <psusi> though I need to rejigger it to put all of the old archives into a compressed mbox file instead of the Maildir
[04:22] <StevenK> RAOF: I thought gmail did filtering anyway
[04:22] <RAOF> It does, but it sucks at it.
[04:22] <StevenK> Buy a Linode, set up dovecot and postfix, use sieve, profit?
[04:23] <RAOF> Or, at least, almost all of my filters are filter-by-mailinglist (which it doesn't do correctly, or didn't last time I checked) or specific-header matching (likewise)
[04:23] <RAOF> I guess I could…
[04:24] <RAOF> It seems an awful lot like unnecessary work, though.
[04:25] <psusi> RAOF, what is "it"?
[04:25] <RAOF> Buying a Linode, setting up dovecot and postfix, and sieve.
[04:25] <StevenK> Then you need to move MX records and such :-)
[04:25] <RAOF> Then maintaining the same.
[04:26] <psusi> is linode like a virtual server?  I run dovecot and postfix on my server at work with sieve for filter rules and it works great
[04:26] <StevenK> A Linode is a VPS
[04:26] <psusi> it pulls mail with fetchmail, then uses postfix and dovecot with sieve filters to sort, store, and serve mail
[04:27] <psusi> which I read with thunderbird at home and at work... though I have also tried using claws and evolution and ended up back in tbird
[04:27] <psusi> really need to give mutt a good try one of these days...
[04:28] <StevenK> RAOF: I have dovecot, postfix, apache and duplicity to handle the-datacentre-is-now-a-smoking-crater case and spend maybe ten minutes a week looking after it. Then again, it is your time.
[04:29]  * psusi needs to spend some time again soon deciding if he should improve dump ( if it needs it ) or go back to using tar
[04:29] <ajmitch> StevenK: some of us still use procmail instead :)
[04:29] <StevenK> Work mail is filtered using procmail, so I can use that too.
[04:39] <psusi> then again, maybe first I should finish my proposal from years ago about automagical read/write mounts of cd/dvd/bd-rw media so they behave like giant floppies
[04:45] <psusi> yea, so.. macs have a little check box in the gui to disable permissions on mounts... I did some work in that area for udf a few years aback... would it be useful to do some kernel work for ext4 to be able to disable permissions on external media and integrate that into the gui disc properties dialog box?
[07:24] <didrocks> good morning
[07:34] <pitti> Good morning
[07:35] <geser> good morning
[07:52] <pitti> lool: thanks for fixing cdbs!
[07:52] <pitti> lool: retrying gdb build
[08:04]  * pitti sends a metric ton of new langpacks launchpadwards
[08:22] <pitti> dpm: ^ FYI; note that they already have the firefox 4.0 final XPIs, so they won't work yet with our beta12; but Chris is going to upload 4.0rc1 this week
[08:23] <dpm> morning pitti. Thanks for the heads up. Can you paste the message you are pointing to above? I wasn't on the channel yet and I cannot see it
[08:24] <pitti> dpm: oh, nothing special: "* | pitti sends a metric ton of new langpacks launchpadwards"
[08:24] <dpm> ah, ok :)
[08:26] <dpm> pitti, do you think you'll be able to have a look at bug 731298, so that we can start the maverick langpack testing tomorrow? If not, I'll simply delay the call for testing
[08:27] <pitti> dpm: I'll try
[08:27] <pitti> I hope it's not too involved
[08:29] <dpm> pitti, thanks a lot. Yeah, if you could just let me know whatever the outcome is, that'd be great, so I know whether I should send the announcement or delay it
[08:33] <dholbach> good morning
[08:33] <richardcavell> good morning
[08:59] <pitti> dpm: hm, they've always been meant to also be in the update package, but I guess since we don't use LP translations for them anyway they wouldn't need to be
[09:00] <pitti> dpm: that doesn't seem to be the actual problem, but it might aggravate it
[09:00] <pitti> dpm: anyway, I'm afraid we'll need fresh -base packages to clean this up
[09:00] <dpm> pitti, ah, I didn't know that. I thought they could only be on the -base packages because LP only exported FF translations on full exports
[09:01] <pitti> dpm: when I originally implemented that, I assumed that we do want them in updates as well, just as normal po files
[09:01] <pitti> dpm: I wasn't actually aware that we only use po2xpi
[09:02] <pitti> dpm: I'm totally unsure why https://lists.ubuntu.com/archives/ubuntu-translators/2011-March/004486.html claims that there's an empty firefox 4.0 dir, though; his dpkg -L output doesn't show that
[09:02] <pitti> but indeed it does show that the file structure changed quite a bit; I'll try to reproduce that
[09:04] <dpm> pitti, I'm not sure why LP can't export them in delta exports, because they are essentially PO files with a bit of a different format. Theoretically, it would be useful to have them in delta packages too, but I don't know if there are technical limitations there (either on the LP or the packaging side). "dpm: I wasn't actually aware that we only use po2xpi" - I'm not sure I follow this part, what do you mean with that?
[09:11] <pitti> dpm: sorry, I mistyped; I meant to say "that we only use xpi2xpi, and not the LP translations"
[09:11] <dpm> ah, ok
[09:11] <pitti> anyway, I see the problem
[09:13] <pitti> dpm: I'll create a test case for it first
[09:13] <dpm> ok, cool
[09:14] <pitti> I still don't understand why installing the update package makes the original files go away, though
[09:15] <pitti> dpm: just to be sure, this only affects the PPA, not current lucid-updates, right?
[09:15] <pitti> or lucid-proposed as well?
[09:16] <dpm> pitti, that's what translators reported (it affects only PPA). They only started seeing it when they got the latest PPA update, as far as I understood it
[09:16] <dpm> in maverick, and then someone confirmed it for the Lucid PPA as well
[09:16] <pitti> dpm: right, because the lucid-proposed packs are empty
[09:17] <pitti> we had a -base refresh on 20110204
[09:17] <pitti> ok, good
[09:19] <pitti> dpm: so, the PPA update packages do ship a single empty ./usr/lib/firefox-addons/extensions/langpack-de@firefox-4.0.ubuntu.com/ dir, but why does that remove the 3.6 translations..
[09:29] <Daviey> @pilot in
[09:34] <dholbach> pitti, do you think apport could grow a "report & restart" option?
[09:34] <dholbach> in the case of compiz crashing I'd LOVE for it to be reported and compiz restarted, so I can get back to work afterwards
[09:34] <dholbach> (and I'm never sure if compiz needs a bunch of command line arguments that I don't know of)
[09:34] <pitti> dholbach: sure; I guess at that point one of it should perhaps become a checkbox instead
[09:35] <pitti> to avoid having four buttons
[09:35] <dholbach> whatever way it's implemented, I'm happy :)
[09:36] <pitti> dpm: would it matter much if we postpone today's call for testing?
[09:37] <pitti> dpm: I could do a half-arsed hack and hope for the best, or fix it properly, with test cases, and in a robust fashion, but then it'll take a bit longer than "today 1400"
[09:38] <dpm> pitti, I'd prefer the full-arsed fix as well :) So let's delay it. Do you have any rough estimate when you'll have time to implement the proper fix, so I can add some info to the announcement?
[09:39] <pitti> dpm: I think I can get that done today, and let the new build/upload run overnight
[09:39] <pitti> dpm: should I do that straight to -proposed, or do you prefer having it in the PPA first?
[09:39] <pitti> (the former would avoid another build round in the ppa)
[09:41] <dpm> pitti, yeah, I think direct upload to -proposed would be a good idea. That's where people should test it from, no need to have it first on the PPA at this point
[09:41] <pitti> *nod*
[09:42] <dpm> thanks a lot pitti
[09:50] <janimo> fta, hello, the arm build still has not hardening enabled and needs debugging?
[09:52] <lool> pitti: gdb rebuild worked fine; thanks!
[10:05] <Daviey> janimo, Thanks for fixing i386 / axis2c... such a frustrating bug
[10:06] <janimo> Daviey, cheers
[10:10] <ogra> Daviey, you are aware that if janimo fixes an x86 bug for you you are on duty to fix an arm bug for us, right ?
[10:10] <ogra> *g*
[10:11] <dholbach> ogra, you need to twist his ARM harder
[10:11] <ogra> haha
[10:12] <dholbach> just when everybody thought all stupid ARM jokes had been made already :)
[10:17] <Daviey> ogra, If you give me arm hardware, i'll gladly fix stuff :)
[10:18] <Daviey> I know they don't cost an ARM and a leg... but even so.
[10:18] <Daviey> (hope that isn't purely a britishism)
[10:19]  * ogra hands Daviey a bangle ... (i didnt know you were that much into jewelry)
[10:20] <Daviey> thanks :)
[10:45] <pitti> dpm: btw, do you want me to upload both lucid and maverick at the same time? or just one?
[10:46] <dpm> pitti, just maverick to -proposed. I guess Lucid will be fixed automatically at the next PPA upload, and we're not planning any updates until the next point release there
[10:48] <tseliot> cjwatson: if grub-gfxpayload-lists is in universe, I don't think I can fix cards that have problems with grub's bootsplash with nvidia and fglrx
[10:48] <dpm> pitti, FYI henninge just confirmed that for firefox translations exported from Launchpad there is no special treatment, i.e. they can either be exported in the delta tarballs or in the full ones, so my assumption that they were only exported on full tarballs was wrong
[10:48] <tseliot> cjwatson: any plans to move it to main?
[10:50] <cjwatson> tseliot: oh, yes, it really ought to be moved to main
[10:50] <cjwatson> tseliot: could you send me an e-mail reminder?
[10:50] <tseliot> cjwatson: sure
[10:50] <tseliot> thanks
[10:51] <pitti> dpm: ok, thanks; I disabled the maverick cron job now, and kept lucid
[10:56] <dpm> pitti, ok, cool. Do you think you could you also enable the natty ones now that the full langpack is building? Btw, I see on http://macquarie.canonical.com/~langpack/crontab that natty langpacks are only being build on Tue, but according to the schedule they should also be built on Fri. Is the cron job set for Fridays as well, or is it just a glitch in the parser that creates the human friendly description on the exported crontab page?
[10:57] <pitti> dpm: sure; do you want to enable it youselves, to get the hang of it?
[10:57] <dpm> pitti, sure :-)
[10:59] <pitti> dpm: it's not just a glitch, natty cronjobs really just run once a week right now
[10:59] <pitti> dpm: but I'm sure that the current perl magic won't get along with two days
[11:00] <dpm> pitti, ok, that's not critical as long as the two days are enabled, and it shows it's enabled/disabled
[11:11] <c2tarun> I am working on security issues of package phpmyadmin. the patch available on http://www.phpmyadmin.net/home_page/security/PMASA-2011-2.php . it seems that they are fixing all the issues in 3.3.x version, lucid has 3.3.2 with no issues fixed while maverick has 3.3.7 with most of the issues fixed. What should I do, take the patch from the link and fix version 3.3.2 or backport the maverick one?
[11:19] <geser> c2tarun: patch any issue the lucid version is affect by and ask ubuntu-security-sponsors for sponsoring
[11:47] <c2tarun> geser: hey just applying is enough or we have to test also that patch is working or not?
[11:52] <geser> c2tarun: don't know, better ask someone from the security team.
[11:53] <geser> you should at least test if the application still works
[11:53] <c2tarun> geser: ok thanks :) i'll do that
[12:24] <Norrlanning> Hi there! couldn't find a development channel so I thought that I'd give it a try  here. Is there anyone that tried to customize ubiquity? I've done quite a lot but  there's one problem I can't seem to solve. And that is how to change the  pre-highlighted install language. By default the highlighted installer-language  is english. I would just like to change it to Swedish. However it seems like
[12:24] <Norrlanning>  tere 's ALOT of files ubiquity uses to process that kind of information...Oops, cut and paste from the ordinary ubuntu channel ;)
[12:25] <cjwatson> Norrlanning: just put sv in /isolinux/lang on the CD
[12:26] <cjwatson> or boot with debian-installer/language=sv as a boot parameter
[12:27] <Norrlanning> cjwatson: And that will also make the english option remain? in that case that sounds awesome :-)
[12:27] <cjwatson> yes, that should just change the default
[12:28] <diwic> Norrlanning, I'm Skåning ;-)
[12:28] <Norrlanning> Because the default on the system is correct, it's just ubiquitys installer that needs to change :-)
[12:28] <Norrlanning> diwic: Hehe well hiya :-D
[12:28] <Norrlanning> diwic: LX?
[12:29] <diwic> Norrlanning, I think we have to make skånska the default ;-)
[12:29] <cjwatson> Norrlanning: yes, I mean it should change the default selection on ubiquity's language selection page
[12:30] <pitti> dpm: at least it shows the first day correctly on http://macquarie.canonical.com/~langpack/crontab
[12:30] <Norrlanning> cjwatson: Thank you very much. This problem has been bugging me for 2 whole days :-D
[12:30] <Norrlanning> diwic: Haha oh yes ;)
[12:30] <dpm>  pitti yeah :)
[12:31] <Daviey> c2tarun, Hey, are you around?
[12:32] <c2tarun> Daviey: yup
[12:32] <c2tarun> hi
[12:32] <Daviey> c2tarun, Super... you've been super busy fixing some of the FTBFS bugs!
[12:33] <c2tarun> Daviey: I was fixing some FTBFS but in free time :) not busy, why what happened?
[12:33] <dholbach> barry, I just replied on the ubuntu-packaging-guide merge proposal
[12:33] <dholbach> sorry for the long wait
[12:33] <dholbach> although I had hoped somebody else would get to it earlier
[12:33] <Daviey> c2tarun, it's really good work....
[12:33] <c2tarun> Daviey: thanks :)
[12:33] <Daviey> c2tarun, The only thing i'm thinking is https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032632.html
[12:33] <Daviey> c2tarun, Under the latest natty toolchain they do build..
[12:34] <Daviey> c2tarun, As that mail says, when o-series opens - we'll have the same bug again.  So i was thinking, keep the bug open, see if Debian adopt the patches when O-Series opens?
[12:34] <Daviey> c2tarun, This will mean we should get the fix for free, without deviating too far from Debian.  What are your thoughts?
[12:35] <Daviey> c2tarun, Over the weekend, i did forward one of your patches to Debian... but am i right in saying that you have pushed the rest of the patches to Debian?
[12:36] <c2tarun> Daviey: yup, artur told me to file a bug in debian first and then close that bug in changelog.
[12:37] <Daviey> c2tarun, So you are ok with your patches not going into Natty?
[12:38] <barry> dholbach: no worries.  i'll do the merge.  i'll be taking off soon-ish to pack and travel for pycon
[12:39] <dholbach> barry, gotcha - just get it in there and I'll put some work into restructuring
[12:39] <dholbach> it'll be great to just have the content in there first
[12:39] <barry> dholbach: awesome!
[12:39] <c2tarun> Daviey: what do you mean by not going into natty? I mean they are being fixed at both places I guess in debian as well as in natty, + I dont understand what on that link mean exactly? I mean the one who posted the bug is saying that do not drop ld --as-neede patch, why would someone drop that patch?
[12:40] <c2tarun> Daviey: is he saying for the release next to natty?
[12:41] <Daviey> c2tarun, So, the patches you have submitted fix FTBFS.... but under the current toolchain in Natty they do build.  What i am suggesting is that your work goes straight into Debian, and next cycle they'll get sync'd across.
[12:42] <Daviey> So your fixes will be in O-Series when it opens.
[12:42] <c2tarun> Daviey: sorry to ask this but what is O-Series?
[12:42] <Daviey> c2tarun, Part of the concern i have is that some of these packages, it introducing a delta - which means that someone will need to manually request a sync.
[12:43] <barry> dholbach: merged and pushed
[12:43] <dholbach> ROCK
[12:43]  * dholbach hugs barry
[12:43] <dholbach> barry, blueprint updated
[12:43] <Daviey> c2tarun, O-Series is the name of the next development cycle, that i can neither spell nor pronounce :)
[12:44]  * barry feels better already!
[12:44] <c2tarun> Daviey: ok :) so if my work goes straight to debian we can easily get them sync automatically without any manual sync request right? that sounds good :)
[12:46] <c2tarun> Daviey: ping
[12:47] <Daviey> c2tarun, yeah!  There is one more thing you can add to make tracking easier for the bugs you've opened... On Launchpad you can mark, "affects distribution" and paste the url to the debian bug.  Makes it easier to track next for next cycle.
[12:47] <\sh> micahg: zf 1.11.4 is ready for backport :) thx :)
[12:47] <c2tarun> Daviey: sure I'll do that :) not a problem at all.
[12:50] <Daviey> c2tarun, you rock, thanks :)
[12:50] <SpamapS> Daviey: ty for the squid upload. :)
[12:51] <Daviey> SpamapS, I wasn't sure if ":" was a bashism, that wouldn't work in dash... seems it does... perfect, didn't even need to comment on it :)
[12:52] <SpamapS> Daviey: I tend to think that all terse confusing things will work in dash.
[12:52] <cjwatson> portability of ':'> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#colon
[12:56] <cjwatson> the difference between : and true is that : is required to be a "special built-in utility", so need not be execve-able etc.
[12:56] <cjwatson> in some shells the special built-ins will be more efficient
[12:57] <Daviey> cjwatson, bash doesn't have a built-in 'true' does it?
[12:58] <soren> $ which true
[12:58] <soren> /bin/true
[12:58] <soren> Nope.
[12:58] <cjwatson> yes it does!
[12:58] <soren> Really?
[12:58] <Daviey> soren, I just did that aswell :), but wondered if exec overides the which :)
[12:58] <ogra_> man bash
[12:58] <cjwatson> true has to be provided on the search path, per POSIX
[12:58] <soren> I thought which would say it was a built-in.
[12:58] <cjwatson> type will say it's built-in
[12:58] <cjwatson> which explicitly searches $PATH
[12:58] <cjwatson> $ type true
[12:58] <cjwatson> true is a shell builtin
[12:58] <Daviey> ah, so it does!
[12:59]  * soren thought which was a built-in, but apparantly not.
[12:59] <cjwatson> nope
[12:59] <soren> I guess it would be kind of hard for a not-builtin to decide if something else was a built-in.
[12:59] <cjwatson> exactly
[12:59] <Daviey> type is a built-in :)
[12:59] <Daviey> This patch piloting lark, is educational :)
[12:59] <soren> Indeed.
[13:00]  * soren crawls back under his rock
[13:00] <Daviey> cjwatson, so in this instance : is as efficient as true, but if we had a shell which doesn't builtin true - : would be better?
[13:00] <cjwatson> right
[13:01] <Daviey> nice.
[13:01] <cjwatson> 'true' is a "regular built-in utility" in POSIX parlance - may be built into shells, must still be provided on search path, has special treatment for command execution (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01)
[13:02] <Daviey> Who needs the internet / grep code, when you have a cjwatson.
[13:02] <cjwatson> that special treatment being in brief that you can't change its behaviour just by putting a different implementation in front of the system one on $PATH
[13:03] <cjwatson> (which is probably not widely known - it's not something I remembered until I looked it up just now)
[13:04] <Daviey> Interesting.
[13:33] <pitti> dpm: ah, forgot one thing to reply: the lucid .debs in the PPA will get fixed automatically in the next run, but people who already upgraded to the broken ones will need to purge them and the -base and reinstall
[13:33] <dpm> pitti, ah, thanks for the heads up. I'll let translators know
[13:33] <pitti> dpm: thanks
[13:36] <artfwo> I see there's a blueprint to replace gdm with lightdm in natty, but it's not implemented yet. will this feature come in natty or natty+1?
[13:40] <pitti> artfwo: the blueprint was about providing lightdm; it wasn't planned to replace the default in natty
[13:40] <seb128> artfwo, not natty for sure but it will be discussed at uds for next cycle
[13:41] <artfwo> it's about replacement judging from description, https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-display-manager
[13:42] <artfwo> but thanks for the answers, hopefully this area will get some attention for the ocelot
[13:42] <seb128> artfwo, see the whiteboard
[13:43] <seb128> seems like the whiteboard didn't really get a summary of the UDS discussion notes though
[13:44] <mdz> seb128, gnome-user-share was in the default install in 10.04 but gone in 10.10; was it an intentional change? (looking at bug 536766)
[13:45] <mdz> chrisccoulson, ^
[13:45] <seb128> mdz, was it?
[13:45] <chrisccoulson> yeah, i think it was recommended by gnome-bluetooth
[13:45] <mdz> seb128, it wasn't seeded, but it was on the CD (chrisccoulson pointed it out to me)
[13:46] <mdz> that's how I noticed: I wanted to receive files over bluetooth and it took a while to figure out what to install
[13:46] <seb128> seems like it should still be recommended
[13:46] <seb128> not sure when and why it got dropped though
[13:46] <mdz> it was dropped to suggests
[13:46] <chrisccoulson> ah
[13:46] <seb128> that seems wrong
[13:46] <chrisccoulson> yeah, the "Receive Files" button in gnome-bluetooth doesn't work without it
[13:46] <mdz> no mention in the changelog
[13:47] <mdz> oh, the changelog is abbreviated
[13:47] <mdz>   [ Andrea Veri ]
[13:47] <mdz>   * debian/control:
[13:47] <mdz>     - added a suggests on gnome-user-share, its bluetooth
[13:47] <mdz>       support should be working fine now.
[13:48] <seb128> mdz, that seems wrong
[13:48] <mdz> seb128, it's an odd thing to say if it already had a Recommends
[13:49] <seb128> mdz, ?
[13:49] <seb128> oh the changelog
[13:49] <mdz> y
[13:52] <seb128> mdz, ok, it's a merge error in http://launchpadlibrarian.net/49137567/gnome-bluetooth_2.30.0-0ubuntu3_2.30.0-1ubuntu1.diff.gz
[13:52] <mdz> seb128, ahh, well spotted
[13:53] <seb128> mdz, I will put it back, thanks for spotting it
[13:53] <mdz> seb128, should we use bug 536766 to track the lost recommends then?
[13:54] <mdz> I will fix it up if so
[13:55] <mdz> it should be a non-issue if gnome-user-share is installed by default
[13:55] <mdz> though it's not directly to do with bluetooth
[13:56] <mdz> maybe it would make sense to seed gnome-user-share
[13:56] <abhinav-> is there any option to pass to fsck so that it takes all answers as yes by default ? :-| I am unable to boot , filesystem seems to be corrupted
[13:57] <seb128> mdz, no, let's keep that bug about what the title describes, people might still uninstall the recommends and run into it
[13:57] <seb128> mdz, I will add the Recommends back now, no need to track it in a bug
[13:57] <mdz> ok
[13:57] <mdz> yeah, it's talking about the apache based sharing so a different issue
[14:06] <janimo> TheMuso, hello, planning a new pulse upload soon?
[14:07] <ogra_> janimo, did you recieve the patches from ndec ?
[14:07]  * ogra_ cant remember seeing them yet
[14:13] <janimo> ogra_, ndec? Related to what?
[14:14] <janimo> who is ndec? :)
[14:14] <ogra_> janimo, nicolas from TI ... he has pulse atches we need to integrate
[14:14] <ogra_> *patches
[14:15] <janimo> ogra_, ah no. There's just one small issue in the porting queu
[14:15] <ogra_> ah
[14:16] <janimo> ogra_, I did not know about anything TI &pulse related
[14:16] <ogra_> we still need to add the UCM config to alsa-utils first though
[14:16] <ogra_> and we can only do that after the kernel was switched to .38
[14:18]  * ogra_ grumbles, still no trace of the new livecd-rootfs ... the publisher annoys me 
[14:46] <YokoZar> mvo: any objections for a patch to app-install-data for a package before it's in the archive?
[14:46] <YokoZar> (but is in my PPA ;) )
[14:47] <mvo> YokoZar: hello! will it be in the archive soon?
[14:48] <YokoZar> mvo: I hope so, but there's a chance it might not make it in at all in the release.  Would that be a bad thing?
[14:48] <YokoZar> mvo: I'm hoping software center does the smart thing and hides it completely if the referent package doesn't exist.  Which would make adding it a good thing even if it only existed in PPA
[14:49] <mvo> I need to double check that, it may assume your repo data is outdated
[14:49] <mvo> (i.e. for some reason /var/lib/apt/lists/ is empty/incomplete)
[14:49] <mvo> so it will probably offer you to update
[14:49] <YokoZar> over and over
[14:49] <YokoZar> which would be bad
[14:50] <YokoZar> but wouldn't that happen if a user disabled universe?
[14:52] <kiwinote> YokoZar: if an app is listed in app-install-data, then s-c will display it in the listings whether it is available or not; in the details view an error will appear 'the pkg $pkgname is not available in your current software sources'
[14:53] <YokoZar> kiwinote: ahh ok, that makes sense.  Best to get it in the archive then!
[14:53] <kiwinote> YokoZar: yep, that would be best ;)
[14:53]  * YokoZar laments that we still don't have the ability for PPAs to add additional proper entries
[15:34] <hallyn> hm, why is my install-exec-hook not happening?
[15:38] <pitti> dpm: uploading maverick-proposed langpacks now; they'll compete on buildd power with the natty ones, so it'll take a while
[15:54] <alkisg> LP bug #422298 has been fixed in Debian's dash 0.5.6.1-1~exp1, but Natty has 0.5.5.1-7.2ubuntu1.
[15:54] <alkisg> I'm interested in helping get this backported for Lucid, what method should I follow? I think the standard SRU policy doesn't apply here as the bug isn't fixed in Natty...
[15:59] <Chipzz> alkisg: do you really think that is a good idea? I *SERIOUSLY* doubt it
[16:00] <Chipzz> alkisg: given that dash is the default /bin/sh, there is a LOT of potentital for regressions
[16:00] <fta> janimo, hi, correct, pie disabled on arm (only), due to lack of h/w on my side and lack of help in general
[16:11] <nigelb> diwic: Hey, just wanted to let you know --> Great work on the audio hook!
[16:11] <alkisg> Chipzz: why not? It currently breaks even touching a file in the Greek translation of "desktop"
[16:11] <diwic> nigelb, thanks :-)
[16:11] <nigelb> diwic: I'd taken a session on apport hooks and was WOW when I saw it :)
[16:12]  * nigelb hugs diwic 
[16:12] <Chipzz> alkisg: I just told you why...
[16:13] <alkisg> Chipzz: well, it's a 2 lines patch, which is confirmed to fix a serious problem
[16:13] <alkisg> So I don't see why I should be afraid of regressions for that
[16:13] <Chipzz> alkisg: yeah? and? so? what?
[16:13] <alkisg> Chipzz: and so, systems here break, and they can be fixed
[16:13] <Chipzz> alkisg: you do realize that not every bugfix gets a backport to stable, do you?
[16:13] <alkisg> I don't see your point
[16:13] <Chipzz> and I do not see your point at all
[16:13] <alkisg> Sure. I only care about serious bugs
[16:14] <Chipzz> and IMO that one is not serious
[16:14] <alkisg> I say again, that touching a file in the greek desktop fails because of this bug
[16:14] <Chipzz> (but that's just my 2c)
[16:14] <alkisg> I wouldn't have reported that bug if I wasn't affected
[16:14] <alkisg> Anyway, any answers to my question?
[16:14] <alkisg> (thank you for your thoughts + time btw)
[16:14] <Chipzz> alkisg: please elaborate on how the fact that this bug affects you personally makes it important?
[16:15] <alkisg> Chipzz: no, it affects all of 200 greek schools I keep an eye on
[16:15] <Chipzz> I have dozens of bugs affecting me, but I'm not going to claim they're important because they affect me...
[16:15] <alkisg> It doesn't affect me personally
[16:15] <cjwatson> alkisg: to me, that bug sounds reasonable to fix in an SRU
[16:15] <cjwatson> it's high-impact for many people
[16:15] <alkisg> cjwatson: thank you. My problem is that I think that for an SRU, it needs to be fixed in Natty first
[16:15] <cjwatson> yes, it does
[16:16] <cjwatson> figure that out first :)
[16:16] <alkisg> Yup, that's where I have the problem, and why I was asking :)
[16:16] <alkisg> How to get that fixed for natty past feature freeze :)
[16:16] <Chipzz> cjwatson: do you really think it is a good idea to mess around with the default /bin/sh ??
[16:16] <cjwatson> are there any other feature changes between what we have now and what's in Debian
[16:16] <cjwatson> Chipzz: if it's having that kind of impact, it is perfectly reasonable to consider it
[16:17] <alkisg> I haven't checked the changelog from natty to debian exp
[16:17] <Chipzz> cjwatson: like I mentioned above, the regression potential is HUGE
[16:17] <cjwatson> obviously such a change should be well-tested
[16:17] <cjwatson> but I think it's inappropriate of you to reject it out of hand
[16:17] <Chipzz> if a backport of dash breaks, it doesn't just break lightly, it breaks everything everywhere
[16:18] <cjwatson> alkisg: you should - but if it's too big, we can backport just that fix to natty
[16:18] <alkisg> Is there some cherry picking procedure that we could use to only backport those 2 lines?
[16:18] <cjwatson> Chipzz: excellent, then we'll notice it and we can avoid promoting it to -updates
[16:18] <alkisg> Thank you cjwatson, will check the changelog and comment on the bug report
[16:19] <cjwatson> alkisg: sure, fish out the patch and apply it :)
[16:19] <Chipzz> cjwatson: I doubt users of an LTS release would appreciate literrally having half of their system broken ^^ ;)
[16:19] <cjwatson> Chipzz: it won't affect them until it's been regression-tested in -proposed
[16:19] <cjwatson> it is sensible to take care with -updates, but frankly I think you're being unnecessarily alarmist
[16:20] <cjwatson> we can assess this sort of thing calmly, without resorting to hyperbole
[16:21] <cjwatson> if an update exhibits that kind of breakage, then it's an easy decision not to roll it out to everyone
[16:22] <Ampelbein> Daviey: If you are still on duty, could you check on the branch at bug 715766?
[16:24] <Chipzz> well I'ld say if that bug is so important how come it was unfixed in an LTS for close to a year?
[16:24] <cjwatson> oh come on, we have lots of bugs which are important which were unfixed in the LTS and which we fix in updates
[16:24] <Chipzz> sure
[16:24] <cjwatson> that's a circular argument for never issuing any updates
[16:24] <Daviey> Ampelbein, Hey, yes - I was hoping to speak to doko about that - he is the Debian maintainer.
[16:25] <Chipzz> I'm not saying you're doing a bad job fixing bugs
[16:25] <cjwatson> you're actively discouraging people from doing so
[16:27] <Chipzz> I don't have any figures, but I'ld say that most SRU's are a) either fixed soon(ish) after release, or are the result of an earlier regression?
[16:27] <Ampelbein> Daviey: ok, thank you!
[16:28] <cjwatson> Chipzz: I think your gut feel is incorrect here
[16:30] <Chipzz> it might be; you would have more knowledge about it than me
[16:31] <bluegoat> anybody here using quickly?
[16:31] <Chipzz> my feeling is simply that if a bug in a core package is critical, it would be fixed a lot faster than a year (allmost 2 full release cycles)
[16:32] <cjwatson> this really isn't a good argument for things that only affect a section of the userbase
[16:33] <cjwatson> native English speakers will likely never notice this bug
[16:33] <cjwatson> but I don't think that's a good reason for us to be Anglocentric
[16:33] <cjwatson> (or Latin-language-centric)
[16:33] <cjwatson> UTF-8 handling bugs *are* important
[16:34] <cjwatson> most of our core developers speak English much of the time, and few of them use non-Latin languages very much, and that inevitably skews what we work on; but that is not necessarily a good reflection of our userbase, and it is not an excuse for failing to fix bugs that affect others
[16:35] <Daviey> Ampelbein, Thanks for the branch!  It does look like it fixes the issue, the only concern i have is that it's not the best way.  Looks like doko is away for the rest of the week... Looking further.
[16:36] <tkamppeter> pitti, hi
[16:36] <pitti> hey tkamppeter
[16:39] <Ampelbein> Daviey: hm, what do you mean with 'not the best way' I thought that keeping the python modules in /usr/share/pyshared and symlinking from /usr/lib/python2.X/dist-packages is correct? And if I understand dh_python2 script correctly it does that?
[16:45] <Chipzz> cjwatson: well I just read the SRU guidelines again; none of them seem to apply in this case (although it does state above that they're examples so I guess the list isn't exhaustive); but when I read sth like "As for dash-0.5.4, in expand.c:240 there is a line rmescapes(p);", alarmbells start to ring
[16:45] <Chipzz> changing a macro which removes escapes seems like a good opportunity to introduce new problems
[16:45] <cjwatson> you're welcome to disagree
[16:46] <Chipzz> like I said above, just my 2c
[16:46] <Chipzz> :)
[16:46] <cjwatson> I don't think we're going to get anywhere arguing about it
[16:47] <Chipzz> then I'll just stop arguing :)
[16:47] <ogra> mumble mumble ...
[16:48] <ogra> so the publisher ... if i upload a package and it builds in less than 5min, why doesnt the darn thing publish source *and* binary then ...
[16:48] <ogra> i always have to wait two runs to actually get my binary
[16:50] <cjwatson> ogra: it does if the binaries land in time
[16:50] <ogra> hmm, but i'm sure they did
[16:51] <Daviey> Ampelbein, Yes, i think you are right... but i'm trying to work out why doko did it the way he did.
[16:51] <cjwatson> ogra: they need to land before :00, not before :03, in order to catch the queue run job
[16:51] <ogra> hmm, k
[16:52] <cjwatson> that may have confused you, perhaps
[16:53] <ogra> dunno, i see i did the upload at :49
[16:53] <ogra> building livecd-rootfs takes around 5min
[16:54] <ogra> thats why i would have expected it to make this run ...
[16:55] <ogra> hmm, seems i was tricked by the queue, binary only finished 47min ago
[16:55]  * ogra rests his case then
[16:58] <cjwatson> ogra: your source upload was processed in the queue run at 16:00 UTC, and didn't actually process livecd-rootfs until 16:02:41 because the queue was swamped with language packs
[16:58] <cjwatson> ogra: the queue doesn't run at :55, perhaps for historical reasons, which may not have helped
[16:58] <ogra> cjwatson, yep grokked that now
[16:58] <cjwatson> ogra: in any case, the build time of the binary does not mean it'll be scheduled immediately :)
[16:58] <ogra> ah, and indeed i know about the :55 omission
[16:58]  * ogra totally forgot about that one
[16:59] <Daviey> Ampelbein, I think i was worrying too much... merging now :)
[17:00] <Ampelbein> Daviey: better save than sorry or how do they say ;-)
[17:12] <ryanakca> Could somebody with bash-4.0 (not 4.1) please try to reproduce http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537525 , you'll need to setup PS1 as he described.
[17:13] <Daviey> Ampelbein, That is great, thanks!  Uploaded... nice work
[17:14] <ryanakca> (You can use whichever term you want, no need to use urxvt)
[17:25] <abhinav-> ttx, thank you for accepting the tomcat6 patch. bug 707405 . :-)
[17:32] <c2tarun> Daviey: ping
[17:36] <Daviey> c2tarun, o/
[17:37] <c2tarun> Daviey: can you please look at debian bug 617465
[17:38] <c2tarun> Daviey: there are several patches in there? where did they come from?
[17:38] <c2tarun> Daviey: and what am I suppose to do with them?
[17:39] <Daviey> c2tarun, crikey!
[17:39] <Daviey> c2tarun, looking
[17:39] <Daviey> there are many there :)
[17:40] <c2tarun> Daviey: actually I am not getting what Peter is trying to say, I looked at most of the patches and they work fine as they should.
[17:43] <Daviey> c2tarun, A quick visual look at the patches, they look really good!  If that gets pushed to Debian this week, i think a sync request is a really good idea.
[17:44] <c2tarun> Daviey: yup they are good, but what am I suppose to do here? and what is a principal maintainer.
[17:44] <Daviey> c2tarun, It's always nice to see a package have a good clean, and convert to quilt (3.0) IMO... so i'd like to see that get into Debian soon :)
[17:45] <Daviey> c2tarun, I think you need to just wait to see if the get applied and uploaded to debian unstable/experimental ?
[17:45] <Daviey> c2tarun, Ideally - they'll do it this week... but I don't think you can do too much to influence that.
[17:46] <c2tarun> Daviey: or i'll just say that I have no objections ;D as they asked?
[17:46] <Daviey> c2tarun, I think he was thanking you; but asking the Debian Maintainer what he thought of his patches.
[17:47] <c2tarun> Daviey: thats good, one more help please, how else can I contribute except packaging?
[17:49] <Daviey> c2tarun, I've noticed you've been super busy the last week contributing patches, and that is really, really useful...  The other area we really need help is testing.
[17:49] <Daviey> c2tarun, -> Does that interest you?
[17:49] <c2tarun> Daviey: i'll try :)
[17:50] <Daviey> c2tarun, join -> #ubuntu-quality
[18:05] <Daviey> bdmurray, Can i pick on you for a comment?
[18:16] <bdmurray> Daviey: hmm, I was on a call
[18:18] <dpm> pitti, ok, cool, thanks (re: maverick-proposed langpack upload)
[18:18] <Daviey> bdmurray, Sorry.. it's not urgent.  I just wanted to gauge your opinion on something.  I have a situation where someone has submitted a one line branch fixing something, but not updated the changelog.  What do you think a sponsor / patch pilot should do in this sitaution?
[18:19] <Daviey> I mean, I could fudge a changelog to look like theres... but then have i gone too far in helping them get their code in the branch?
[18:19] <Daviey> s/branch/archive
[18:21] <bdmurray> I don't think so - our documentation is spread out all over the place and its possibly wrong is some places.  So I'd do it for them but be very verbose about what you did and where the supporting documentation is.
[18:22] <bdmurray> Imagine their response "wow, this daviey guy was great and helped me get this done" vs "man this daviey guys want me to do more? I already had to do this that and the other thing."
[18:25] <Daviey> bdmurray, Oh totally, earlier on i fixed someones email address and s/maverick/natty for that reason.
[18:26] <Daviey> bdmurray, I don't agree with just bouncing comments back saying fix every trivial thing as "that is the only way they will learn"... but creating a new entry n the changelog , i was mixed on
[18:28] <ScottK> If it's their first experience with contributing I think the most important thing they feel is that they are successful and it's not tiresome to participate.
[18:28] <Daviey> ScottK, Yeah - I agree with that...
[18:28] <ScottK> I once sponsored an upload where the only thing that was left untouched of the contributors input was their name in the changelog.
[18:31] <bdmurray> Daviey: I just wouldn't be surprised if writing a debian changelog is a missing step in documentation somewhere.  Additionally, how long might it take you to fix it vs waiting for them and it getting lost.
[18:32] <Daviey> Yeah, ping-pong is a timesink for just GTD/JFDI.
[18:32] <Daviey> ping-pong of comments, "Needs Fixing"
[18:34] <abhinav-> Daviey, bdmurray I also submitted my first two patches recently :) . I was confused about the debian changelog entry, it said Maverick in the top, but I was working on the natty release of source code.
[18:35] <abhinav-> but yes my working in maverick
[18:35] <abhinav-> *I was workin in maverick :D
[18:39] <jdstrand> @pilot in
[18:40] <Daviey> abhinav-, Yeah - Really i think dch should default to the next development version...
[18:40] <Daviey> most of us run the development version so we don't notice it. :/
[18:40] <abhinav-> yes, so it should be changed to the latest release anyways ?
[18:41] <Daviey> abhinav-, raise a bug :)
[18:42] <Daviey> abhinav-, probably against devscripts
[18:42]  * Daviey ^5's jdstrand 
[18:42] <jdstrand> :)
[18:42] <jdstrand>  5
[18:42] <jdstrand> o/
[18:45] <abhinav-> Daviey,  oh , I thought it was usual. but I dont know about devscripts much
[18:47] <Daviey> abhinav-, Having said that, if people are using PPA's, it's likely it's for the version they are currently running.  So perhaps not a bug.
[18:47] <geser> oh, no backport of natty's devscripts in maverick-backports?
[18:48] <abhinav-> Daviey, yes perhaps right.
[18:55] <ScottK> jdstrand: thanks for taking care of linux-n900.
[19:00] <jdstrand> ScottK: sure thing :)
[19:03] <Daviey> bdmurray, It bit me in the bum... :)
[19:04] <Daviey> bdmurray, Had i of uploaded this, i image i would have upset people :/ .. https://code.launchpad.net/~dave-martin-arm/ubuntu/natty/linaro-image-tools/udisks-dep/+merge/52543
[19:12] <NCommander> directhex:is there a nice set of prepackaged mono 2.10.1 packages somewhere? :-)
[19:12] <directhex> NCommander, not yet.
[19:20] <abhinav-> Daviey, thank a lot :-) . made my week by approving my first patch :)
[19:22] <bdmurray> Daviey: you never said it was a linaro thing ;-)
[19:23] <Daviey> bdmurray, it /shouldn't/ matter. :)
[19:23] <Daviey> abhinav-, Which one was that?  I've had patches coming out of my ears today!
[19:24] <abhinav-> Daviey,  :-D bug 707405
[19:24] <abhinav-> tomcat6 one
[19:24] <Daviey> abhinav-, Yeah, that was a good catch! :)
[19:24] <abhinav-> thank you :)
[19:26] <Daviey> abhinav-, Just FYI, an easy(ish) way of submitting patches to debian, is the console tool - 'submittodebian' ..
[19:26] <Daviey> i've done that now, and added the bug to the LP bug
[19:27] <abhinav-> Daviey, oh I did not know that :-|
[19:27] <Daviey> abhinav-, Don't worry, you did good.. :)
[19:27] <abhinav-> I attended barry's session in developer week, and since then I have been learning everyday :)
[19:27] <abhinav-> thank you
[19:31] <TheMuso> janimo: Yes, I am, today hopefully.
[19:33] <janimo> TheMuso, ok, I was asking because of the pending arm FTBFS patch you had iun your PPA, and the removal of implicit-it from debian.rules
[19:35] <TheMuso> janimo: Yeah figured as much.
[19:57] <Daviey> @pilot out
[20:10] <calc> anyone happen to know how to select which display on a multihead setup the menus show up on?
[20:12]  * andreserl if would have known that Daviey was piloting, he'd have given him lots of things to review :)
[20:12] <RoAkSoAx> arg
[20:12]  * RoAkSoAx if would have known that Daviey was piloting, he'd have given him lots of things to review :)
[20:13] <NCommander> directhex: nuts :-(
[20:19] <soren> RoAkSoAx, andreserl: What's with the split personality?
[20:20] <RoAkSoAx> soren: wanted to change nicks to andreserl (cause many people couldn't relate my LP page with nickname) but when I used it people don't have idea of who I am either :)
[20:25] <NCommander> directhex: what would be necessary to test mono 2.10.1 on Ubuntu?
[20:27] <soren> RoAkSoAx: Ah :)
[20:32] <Daviey> andreserl / RoAkSoAx: If it was in the queue, it would have got looked at.... *hint*, subscribe ~ubuntu-sponsors :)
[20:32] <RoAkSoAx> Daviey: haha was just messing around ;)
[20:33] <Daviey> :)
[20:45] <hallyn> kees: is there a way to get sbuild to install a particular .deb before compiling?
[20:46] <hallyn> can't really do '--pre-build-commands="dpkg -i x.deb"' since I'm not root...
[20:47] <kees> hallyn: yes, one sec
[20:47] <hallyn> well i suppose i can temporarily install it in the -sources chroot
[20:47] <hallyn> then remove it when i'm done.  ugly.
[20:48] <kees> hallyn: try using --chroot-setup-commands instead of --pre-build-commands
[20:49] <hallyn> kees: will try, thanks
[20:50] <slangasek> mvo: hi, I've got a couple of apt bugfixes needed in natty for multiarch (one prevents multiarch from working as designed, the other breaks your system horribly if you try to remove foreign-arch packages from your system); DonKult has reviewed them but I think I've depressed him with my patch that removes half of his work around Arch: all packages... :)  Do you want to review these changes, or should I just push?
[20:50] <slangasek> calc: xrandr --output $name --primary; I don't think there's a way to do it from the GUI, and that's been annoying me lately ;)
[20:52] <mvo> slangasek: I would like to look at them before pushing, I quickly scanned them today and first glance is good (as excpted)
[20:52] <mvo> slangasek: I have a udev cdrom bugfix pending as well
[20:53] <mvo> slangasek: if tomorrow is fine with you I will prepare a upload then
[20:53] <slangasek> mvo: that would be awesome, thanks :)
[20:54] <mvo> slangasek: great
[21:07] <hallyn> kees: success!  (once I used absolute path instead of relative :)  thanks
[21:14] <kees> hallyn: great! :)
[21:20] <alkisg> (06:31:50 PM) Chipzz: my feeling is simply that if a bug in a core package is critical, it would be fixed a lot faster than a year (allmost 2 full release cycles)
[21:20] <alkisg> ==> for another example, see LP bug #580961, it affects 772 people (in launchpad, thousands in reality), it's been broken since Jaunty and while a fix exists it hasn't been committed yet
[21:20] <alkisg> I'll try to propose a debdiff for that too, if pitti isn't working on it atm
[21:52] <abhinav-> I tried booting from a live usb of natty , it gave crash errors of compiz and ubiquity. apport created a log report, but I could not report it because the keyboard was also not workin in there. is the the information that apport collects stored somewhere in the usb ?
[21:56] <slangasek> lamont: there's not supposed to be any persistent state in ppa chroots, right?
[22:40] <calc> slangasek: thanks :)
[22:44] <jdstrand> @pilot out