[02:22] <lanoxx>  #ubuntu+1
[02:25] <lanoxx> im wondering what is necessary to approve a pending merge request for bzr? If I have read the code changes and think they are ok, can i approve a merge or do i need to part of some special group to do such a thing?
[02:25] <lanoxx> In Launchpad I can choose approve Approve and enter a "review type" what should i enter there?
[02:25] <lanoxx> does that have any effect?
[02:25] <micahg> lanoxx: for Ubuntu, it's ubuntu-dev, you can help test by joining the reviews team
[02:26] <lanoxx> the particular packet is update-notifier
[02:27] <lanoxx> Do I need to show that I have programming experience or anything to be in the review team?
[02:27] <RAOF> Note that approving the merge is purely metadata - it's not going to actually merge the code.
[02:27] <RAOF> If you're familiar with kernel or X development, consider it the same as a Reviewed-By: tag.
[02:28] <ajmitch> maybe some time in the future, approving a merge on LP will do the merge, and automagically create a package from that. But not now
[02:28] <micahg> lanoxx: I don't think so, you can get more information in #ubuntu-reviews, do you have a link to the merge in question?
[02:31] <lanoxx> yes i post the link, one moment
[02:31] <lanoxx> https://code.launchpad.net/~cristiklein/update-notifier/use-xdg-folders/+merge/15038
[04:30] <LucidFox> E: light-themes: debian-changelog-file-contains-invalid-email-address james@james-laptop
[04:30] <LucidFox> o_O
[04:31] <ion> Seems valid to me.
[04:32] <ion> Perhaps a bit difficult to reach, but valid nevertheless.
[04:32] <TheMuso> There is no dot in that address.
[04:32] <TheMuso> Which is why its claiming invalidity.
[04:33] <ion> Non-compliant to the policy, sure, but not invalid. :-P </nitpick>
[04:33] <TheMuso> ion: Hense saying it claims invalidity.
[04:33] <TheMuso> ion: I am not saying that it is invalid.
[04:34] <StevenK> I *think* the RFC says it's invalid
[04:35] <SpamapS> which RFC?
[04:36] <StevenK> Damn it, I knew someone was going to ask that
[04:36] <StevenK> 822 is what my brain is prompting
[04:36] <SpamapS>    An addr-spec is a specific Internet identifier that contains a
[04:36] <SpamapS>    locally interpreted string followed by the at-sign character ("@",
[04:36] <SpamapS>    ASCII value 64) followed by an Internet domain
[04:36] <SpamapS> thats 2822
[04:36] <ion> http://www.mythic-beasts.com/~pdw/cgi-bin/emailvalidate
[04:37] <SpamapS> My whois client says james-laptop isn't found. Maybe james just forgot to renew?
[04:37] <StevenK> Hah
[04:38] <StevenK> I wonder how much it costs for a GTLD
[04:39] <ion> . would be even cooler to own.
[05:23] <pitti> Good morning
[05:23] <pitti> Keybuk: I'm now
[06:19] <pitti> tkamppeter: ah, seems the "cups does not start" problem was now fixed in lucid-proposed
[06:19] <pitti> tkamppeter: bug 554172  FYU
[07:25] <hamish> Hi - Is anyone actively on line?
[07:25] <pitti> !ask | hamish
[07:27] <hamish> Ok - I have downloaded 10.1 Maverick - has anyone got mono-develop running and using C# development IDE?
[07:28] <tseliot> hamish: doesn't it work?
[07:28] <hamish> nope
[07:30] <tseliot> hamish: maybe file a bug report with the following command? "ubuntu-bug monodevelop"
[07:30] <hamish> just thought I'd pick someones brains - but I will maybe get back to it :-)
[07:30] <tseliot> you may also find a bug report with the same problem
[07:30] <hamish> 10nx
[07:30] <tseliot> np
[07:33] <directhex> what specifically sin't working?
[07:33] <directhex> oh...
[07:49] <hyperair> anyone using reprepro here? i'm wondering if there's a more elegant solution than sed -i -e '/ddeb/d' when using reprepro in the presence of pkg-create-dbgsym
[08:00] <dholbach> good morning
[08:01] <pitti> hey dholbach
[08:02] <dholbach> hey pitti
[08:40] <directhex> i guess hamish was having trouble due to mono being in NEW on i386 but not amd64, so it's uninstallable on all arches other than i386
[08:42] <pitti> didrocks: right, it gets held back here
[08:43] <didrocks> directhex: ^^
[08:43] <directhex> which is due to upstream sticking a new library in their minor bugfix update. which isn't new behaviour for them, really
[08:44] <RAOF> Or to switch “long-term-support” to a 2.6 release? :)
[08:45] <directhex> RAOF, i understand the reasons for that... i wish they were a bit more honest up front though
[08:46] <directhex> 2.6.7 is definitely where it's at though, it aligns us with novell's enterprise products
[08:51] <pitti> directhex: mono NEWed
[08:51] <directhex> pitti, thanks!
[08:52] <pitti> and new kernel with it, while I was at it
[08:52] <directhex> you're a queue-mangling superstar
[10:04] <jibel> mvo, Hey, could you have a look at bug 606150 , it was fixed in bug 571743 but this time the problem is with mythbuntu-desktop
[10:04] <mvo> jibel: yes
[10:07] <jibel> mvo, thank you
[11:02] <tkamppeter> pitti, I have seen it in my e-mail. Great.
[11:03] <tkamppeter> pitti, only problem is that this has somehow distracted us from switching CUPS over to native upstart.
[13:58] <jdstrand> mdeslaur: hey. at some time convenient for you would you mind giving virt-manager a workout with the new libvirt I uploaded? I tested it for several things but not super-extensively
[14:01] <mdeslaur> jdong_: yeah, sure
[14:01] <mdeslaur> jdong_: sorry, not you
[14:02] <mdeslaur> jdstrand: yes, sure
[14:04] <jdstrand> mdeslaur: thanks
[15:26] <robbiew> superm1: ping
[16:21] <superm1> robbiew, pong
[16:21] <robbiew> superm1: looks like bluetooth is busted in maverick...have you noticed this?
[16:22] <superm1> robbiew, i've only been testing installer stuff in maverick, so no i haven't.  how busted is it?
[16:23] <robbiew> doesn't work
[16:23] <robbiew> :/
[16:23] <robbiew> but it's recent
[16:23] <robbiew> could just be a desktop issue, i.e. the underlying plumbing stuff could be fine
[16:23] <robbiew> I haven't looked into it yet
[16:28] <superm1> robbiew, well plumbing stuff looks quite suspect, it was just updated 18 hours ago
[16:29] <robbiew> heh
[16:30] <robbiew> ok...hadn't checked that
[16:30]  * robbiew only found out today
[16:32] <mathiaz> pitti: hi!
[16:32] <LucidFox> How does one add a screenshot to software-center?
[16:32] <mathiaz> pitti: while reviewing the apache2 apport hook I noticed that there is already a apache2 .bug-script for reportbug
[16:33] <mathiaz> pitti: I wonder if there is any integration in apport to automatically support all of these scripts?
[16:41] <robbiew> LucidFox: ask mvo
[16:41] <mvo> LucidFox: go to screenshots.ubuntu.com and upload it there
[16:41] <mvo> (hello btw :)
[16:42] <LucidFox> Oh!
[16:42] <LucidFox> Didn't even know it existed
[16:42] <mvo> LucidFox: yeah, we need to make more noise about it
[16:56] <pitti> hey mathiaz
[16:56] <pitti> mathiaz: no, there isn't; I had a look at them some time ago, and most of them weren't very useful
[16:57] <mathiaz> pitti: ok
[16:57] <pitti> mathiaz: and they don't have a predictable structure, so we could only put the entire blob as one attachment
[16:57] <mathiaz> pitti: for apache2 the hook was doing the same thing as the script
[16:57] <mathiaz> pitti: right - that's what I'd suggest
[16:57] <pitti> mathiaz: but if the apache one is useful in particular and does nontrivial stuff, of course feel free to include it using command_output()
[16:57] <mathiaz> pitti: cool - thanks for the advice
[16:57] <pitti> mathiaz: but the bug scripts are geared towards email inclusion in reportbug
[16:58] <pitti> mathiaz: i. e. they could (and some do) also ask questions on stdin, etc.
[16:58] <mathiaz> pitti: and it seems that they can also prompt the user
[16:58] <pitti> those are better done with the interactive apport hooks
[16:58]  * mathiaz nods
[16:58] <mathiaz> pitti: it's probably a case-by-case basis then
[16:58] <mathiaz> pitti: and for the non-interatice ones, command_output() is enough
[17:03] <kees__> pitti: sent you some email...
[17:14] <pitti> asac, seb128: argh, I just fixed a bug in the WI tracker cron job which would prevent team membership updates; that'll explain the problems that you saw
[17:14] <pitti> silly thing
[17:14] <pitti>      # stuff that we do daily only
[17:14] <pitti> -    if [ `date +%H` = 0 ]; then
[17:14]  * seb128 hugs pitti
[17:14] <pitti> +    if [ `date +%H` = 00 ]; then
[17:14] <asac> wow. very good
[17:14] <asac> now i can pick up 1000 new WI for all the newcomers ;)
[17:14] <asac> and make them feel bad :-P
[17:15] <pitti> asac, seb128: I run a refresh now
[17:15] <pitti> but unfortunately these days the bloody thing runs for 1.5 hours
[17:15] <seb128> pitti, thanks
[17:15] <pitti> SpamapS: ^ help
[17:15] <asac> thanks. i will go hunting for the expected WI increase in a bit then ;)
[17:16] <pitti> SpamapS: didn't you say you'd enable per-user charts for some teams only?
[17:16] <asac> pitti: how long does a run take nowadays?
[17:16] <asac> 1h ?
[17:16] <pitti> asac: 1.5
[17:16] <pitti> ish
[17:16] <asac> wow
[17:16] <pitti> it produces nearly 2000 files each run now
[17:16] <pitti> http://people.canonical.com/~pitti/workitems/maverick/u/
[17:16] <asac> might make sense to parallelize it in the cloud to put more pressure on launchpad ;)
[17:17] <asac> i guess most time its talking to launchpad? or is it really pure processing?
[17:17] <pitti> asac: pure processing
[17:17] <pitti> http://people.canonical.com/~pitti/workitems/maverick/u/pitti-ubuntu-10.10-beta.html
[17:17] <pitti> now I can watch my one WI for beta with very high granularity :)
[17:17] <asac> you are lagging ;) ... by 1 item for beta
[17:18] <asac> guess you can easily catch up though ;) ... ok i will check in 2h then
[17:18] <pitti> so, good night and have a nice weekend everyone
[17:18] <asac> enjoy your weekend!
[17:18] <SpamapS> pitti: they're generated for everybody
[17:19] <pitti> SpamapS: ah, I thought I remember limiting it to some teams
[17:19] <SpamapS> pitti: but there's a bug, WI's are selected for any specs you're assigned to
[17:19] <pitti> but that might have been for one of jiboumans' features
[17:19] <SpamapS> pitti: inprogress is limited to teams
[17:20] <SpamapS> we didn't want to mess with peoples' numbers
[17:20] <SpamapS> in case they're graphing the todo somewhere, inprogress might confuse that
[17:21] <pitti> SpamapS: maybe it would be enough to produce the per-user charts for the current milestone or the entire cycle only?
[17:21] <SpamapS> pitti: it takes 1.5 hours for the whole thing?
[17:21] <pitti> as it is right now, lillypilly constantly runs 100% cpu for this thing
[17:21] <pitti> SpamapS: yes
[17:21] <SpamapS> pitti: how much of that is waiting on launchpad? ;)
[17:22] <pitti> I had to decrease the cronjob from being hourly to 2-hourly
[17:22] <pitti> SpamapS: maybe 10 mins
[17:22] <pitti> SpamapS: collect doesn't take any more time
[17:22] <pitti> SpamapS: it's just generate-all
[17:22] <SpamapS> pitti: maybe the indexes had some unexpected side effects?
[17:22] <SpamapS> or is it just that the box is fairly limited?
[17:22] <pitti> SpamapS: no, it's just the sheer quantity, I think; it has to calculate and create over 1800 files, after all
[17:22] <pitti> of which 1/3 is pychart
[17:22] <SpamapS> on my macbook pro it takes 40 minutes to do the whole thing, but 25 of that is querying launchpad
[17:23] <pitti> LP is fast, it's in the DC after all; maybe 10 mins
[17:23] <SpamapS> right, for me LP is halfway around the world
[17:23] <pitti> SpamapS: lillypilly is a 8-core 2.4 GHz
[17:23] <pitti> but of course we don't parallelize
[17:24] <SpamapS> pitti: might be worth profiling it again.. I used the python profiler and found right away that it was spending all of its time on the selects in report_tools
[17:24] <SpamapS> if nothing else, make sure sqlite is using the indexes.
[17:25] <SpamapS> pitti: on your other point, I think it makes perfect sense to skip generation of past milestones.
[17:26] <pitti> SpamapS: right, that would already help a lot; could you do that?
[17:27] <pitti> or just the currently active milestone
[17:27]  * pitti waves, have to run now
[17:28] <SpamapS> pitti: will take a look at it
[17:28] <SpamapS> have fun board breaking. :)
[17:45] <jdstrand> slangasek: hey, so qt4-qws is massive (and coming from alexandros.frantzis@linaro.org). could you tell me (or point me to a page stating) the end goal of this package?
[17:51] <ScottK> jdstrand: It's in New?
[17:51] <jdstrand> ScottK: yes
[17:51] <ScottK> Oh my.
[17:51] <ScottK> Nothing like a "small" code copy.
[17:51] <jdstrand> my thoughts exactly
[17:51] <jdstrand> Estimated lines of source: 1831032
[18:10] <slangasek> jdstrand: sorry, not familiar with it.  Is it actually a code copy, or is it a fork of the upstream code?
[18:11] <slangasek> jdstrand: I assume it's qt building for a non-X target, but I don't know why that should be a fork
[18:11] <slangasek> jdstrand: looks like https://blueprints.launchpad.net/ubuntu/+spec/arm-m-qt-on-embedded is the thing
[18:13] <jdstrand> slangasek: it seems like he took Riddell's package and updated a few debian/* files, changing references to qt4 to qt4-qws... :\
[18:13] <jdstrand> and there is no bug
[18:14] <jdstrand> without looking at it super closely, it seems these things could just be integrated...
[18:15] <Riddell> not without making it much harder to maintain the qt4-x11 package
[18:15] <slangasek> why would it make it harder to maintain?
[18:15] <slangasek> increased build time?
[18:15] <jdstrand> I am really leery of an almost 2 million line cody copy that is sure to diverge
[18:16] <jdstrand> regardless, this should be tracked in a bug
[18:16] <slangasek> what should be?
[18:16] <Riddell> you'd have to build it and package it twice, that's going to make the packaging much harder to maintain (currently we don't have much diff from debian) as well as the increased build time
[18:17] <jdstrand> is this destined for main?
[18:17] <Riddell> no
[18:17] <slangasek> Riddell: as far as I'm concerned, that's an argument for coordinating this change with Debian, not for pushing it out into a separate source package containing identical sources
[18:18] <SpamapS> Riddell: we do that for a lot of server side packages that are pretty big.. mysql.. php.. its common to need several configurations of a single code base
[18:18] <jdstrand> Riddell: perhaps you should be the one accepting it, but it make me really uncomfortable. I have a debdiff in /tmp/jdstrand between what is in maverick and the package. if it were left to me, I would reject it, asking the submitter to file a bug so that people could comment on how to best get it included
[18:20] <jdstrand> in fact, I think I am going to reject it saying just that
[18:20] <Riddell> alf__: best defend yourself quickly :)
[18:20] <Riddell> or asac
[18:21] <alf__> alf: what?
[18:21] <alf__> Riddell: what?
[18:21] <Riddell> alf__: see above conversation about qt4-qws
[18:21] <slangasek> alf__: archive admin concerns about not shipping two nearly-identical source packages of qt4 in maverick
[18:21] <slangasek> alf__: do you know of reasons why this shouldn't be built from the same source package?
[18:22] <jdstrand> nearly identical with almost 2 million lines of source, that are sure to diverge at some point, making a maintenance nightmare
[18:22]  * Riddell notes that having 36 hour long builds is also a maintenance nightmare
[18:23] <jdstrand> it seems clear this is contentious at best
[18:23] <jdstrand> it needs to be discussed somewhere and tracked outside of irc
[18:23] <slangasek> I would have expected that everything outside the core gui bits could be shared between the builds, making the total build time significantly less than 2x the current built time, no?
[18:23] <Riddell> slangasek: no
[18:23] <alf__> jdstrand: agree with riddell + the complexity of having multiple build runs for the same source package
[18:24] <superm1> is it only building again for non-X for arm though?
[18:24] <slangasek> Riddell: why not?  e.g, libqt4-network has no GUI dependencies
[18:24] <jdstrand> we have 36 hour or longer builds for other packages due to arm. why should this be different, assuming slangasek's comments don't apply
[18:26] <Riddell> superm1: it's for any arch
[18:26] <Riddell> slangasek: it's a different ABI
[18:26] <slangasek> Riddell: really? why?
[18:26] <Riddell> jdstrand: mostly because that makes it my problem whereas this way it's nicely kept as linaro's problem :)
[18:26] <Riddell> slangasek: dunno
[18:27] <jdstrand> but linaro will surely not be keen on that as soon as there is a security or bug fix update
[18:28] <didrocks> jdstrand: can you bin new utouch, please?
[18:28] <slangasek> Riddell: it's not just linaro's problem; if the packages are completely disjoint, that's going to start leaking across into dependencies of packages that use qt and can run with either variant
[18:28] <slangasek> which is much less elegant
[18:28] <jdstrand> to me, it seems like a code copy is that absolute last resort, after demonstrating why doing it other ways doesn't work
[18:28] <Riddell> slangasek: being a different ABI packages can only run with one variant
[18:29] <slangasek> Riddell: do you have a pointer to more information about how the ABI is different?
[18:29] <jdstrand> didrocks: ok
[18:29] <didrocks> jdstrand: thanks a lot :)
[18:29] <Riddell> slangasek: nope
[18:30] <jdstrand> ok, well, I am going to reject, asking for more information as to why this is the way it must be
[18:30] <slangasek> alf__: do you know anything about ABI differences when building for X11 vs. QWS?
[18:31] <alf__> slangasek: I will forward you an email with upstream
[18:31] <slangasek> alf__: thanks
[18:35] <alf__> slangasek: anyone to CC to?
[18:36] <slangasek> alf__: you could cc: it to jamie@ubuntu.com
[18:39] <ScottK> slangasek: shouldn't it go to ubuntu-archive?
[18:40] <slangasek> alf__: ^^ you can send it there too
[18:40] <slangasek> ScottK: I'm not subscribed to ubuntu-archive, so I generally neglect that list for anything other than archival of information :)
[18:40] <ScottK> Oh.  OK.
[18:41] <ScottK> Actually I'm not either.  I just read the web archive sometimes.
[18:41] <neeraj> Hi, I have copied my .gnupg folder from lucid to my maverick, but my keys aren't getting synced. I am also not seeing password and keys manager in applications->accessories.
[18:43] <alf__> slangasek: sent (not to ubuntu-archive though, you were not fast enough :))
[18:46] <slangasek> smoser, mathiaz: do we need 10.04.1 builds of EC2/UEC, or is this already covered by the regular image refreshes?
[18:46] <mathiaz> slangasek: we don't need to publish EC2/UEC images for 10.04.1
[18:46] <mathiaz> slangasek: EC2/UEC images are taken care of independently
[18:47] <slangasek> thought so, but wanted to double-check
[18:47] <slangasek> thanks
[18:47] <smoser> slangasek, yeah, there are a couple bugs that i want to have in before there would be a 10.04.1 refresh. we're hoping (with landscape team) to have something soon ish after that.
[18:47] <mathiaz> slangasek: 10.04.1 deliverables for the server team are the two -server isos (amd64, i386)
[18:47] <slangasek> smoser: ok
[18:48] <slangasek> mathiaz: server up, http://iso.qa.ubuntu.com/qatracker/build/all
[18:49] <mathiaz> slangasek: great - thanks
[18:49] <slangasek> ogasawara: are you still maintaining http://qa.ubuntu.com/reports/ogasawara/weatherreport.html ? can we get that switched to point at lucid for 10.04.1?
[18:52] <ogasawara> slangasek: http://qa.ubuntu.com/reports/ogasawara/weatherreport-10.04.html, but gimme a sec to make sure the scripts are pointing at the right data
[18:52] <slangasek> ogasawara: I guess not, a lot of 'manifest not found' there :-)
[18:52] <ogasawara> slangasek: indeed
[18:53] <slangasek> paths should be lucid/daily-live/current, kubuntu/lucid/daily-live/current, ubuntu-server/lucid/ [...]
[18:55] <slangasek> alf__: thanks for that mail!  I'm going to give it a ponder, but I suppose he's right and we have to have completely disjoint sets of binaries :(
[18:59] <ogasawara> slangasek: do you know the paths for the DVD's?
[19:00] <slangasek> ogasawara: would be lucid/dvd/ if we had any, but I had no plans for publishing those
[19:00] <ogasawara> slangasek: ok, I'll just comment them out from the script
[19:00] <slangasek> (whoever turned lucid on in the cronjob didn't include DVDs, and we've certainly foregone them in the past)
[19:06] <SpamapS> slangasek: when you said "server up", did you mean its coming, or its already up? I get a 404 on http://cdimage.ubuntu.com/ubuntu-server/daily/20100813.2/lucid-server-i386.iso
[19:13] <slangasek> SpamapS: http://cdimage.ubuntu.com/ubuntu-server/lucid/daily/20100813.2/lucid-server-i386.iso - the ISO tracker doesn't do the best at handling point release URLs
[19:19] <mathiaz> SpamapS: are you planning to do some iso testing for 10.04.1?
[19:19] <mathiaz> SpamapS: if so - I'd suggest to start by doing the raid1 test case
[19:19] <mathiaz> SpamapS: that would be very helpful
[19:20]  * slangasek stares at bug #617516
[19:20] <slangasek> could people please stop using the plymouth package as a dumping ground for everything that doesn't work at boot?
[19:23] <ion> and go back to using the upstart package for that
[19:24] <SpamapS> mathiaz: yes I had planned to do that test again
[19:24] <mathiaz> SpamapS: great - I'm going through the other tests first
[19:24] <slangasek> ion: exactly :)
[19:24] <mathiaz> SpamapS: so if you start by raid1 we'll meet up at some point
[19:26] <SpamapS> mathiaz: I may not get to it for 1 or 2 hours.
[19:26] <mathiaz> SpamapS: that's ok - any help in this area is appreciated
[19:28] <SpamapS> mathiaz: to me, the lvm/raid1 stuff is the only really important part of the ISO's anyway. ;)
[19:28] <mathiaz> SpamapS: :)
[19:33] <slangasek> ogasawara: kubuntu netbook is also included in the .1, btw - could you pull it into the report?
[19:33] <ogasawara> slangasek: yep
[19:33] <slangasek> thanks!
[19:34] <ogasawara> slangasek: I assume some of the packages in the images are being pulled from -proposed correct?
[19:34] <slangasek> yes, they are
[19:43] <ogasawara> slangasek: I've added it to the report, currently showing "Manifest NOT found"
[19:44] <ogasawara> slangasek: once it's there, the report should show it
[19:44]  * ogasawara skips out for a quick bite to eat
[19:46] <slangasek> ogasawara: ack
[20:40] <rickspencer3> tedg, we had a community process for picking featured apps!
[20:41] <tedg> rickspencer3, Oh, what is it?
[20:41] <rickspencer3> we had a wiki page where community members nominated apps
[20:41] <rickspencer3> then we had some criteria, discussed in a meeting, etc...
[20:41] <rickspencer3> I forget it exactly
[20:42] <rickspencer3> I guess we need to think about starting it again for maverick :/
[20:42] <tedg> rickspencer3, Yeah, I guess I was thinking something formalized, etc.
[20:42] <tedg> rickspencer3, i.e. who gets the "final call"
[20:42] <rickspencer3> tedg, that was me
[20:42] <rickspencer3> but I didn't have to make any "calls"
[20:43] <tedg> rickspencer3, I know, and I love you rick, but you're still not elected :)
[20:43] <rickspencer3> the community sorted it out without needing any interventions
[20:43] <rickspencer3> well, elected or not, it was still my responsibility :)
[20:44] <tedg> rickspencer3, Yes, I guess I would worry about someone half as cool getting the responsibility -- and how do we deal with that.  Not as much that what we have is broken, but how do we make it better.
[20:45] <rickspencer3> tedg, I think hear you volunteering
[20:45]  * rickspencer3 writes blueprint, assigns to tedg
[20:45] <rickspencer3> j/k
[20:45] <tedg> rickspencer3, heh, sure.  saacfl (self appointed application chooser for life) ;)
[20:47] <tedg> All in all, I thought that's what jono's post was about -- and I thought it was a good idea :)  Now, the fact that I read it wrong is a different problem :)
[20:49] <tedg> Heh
[20:49] <saacfl> not sure I like having a nick that is pronounced "sack full"
[20:59] <tedg> rickspencer3, I think it just means you throw big parties: http://www.lyricsdomain.com/1/acdc/big_balls.html
[20:59] <rickspencer3> I'm not even going there
[21:11] <lool> Was sparc dropped already?!
[21:12] <lool> Hmm I guess I need to poke someone to build glib2.0/sparc by hand or so
[21:15]  * lool mailed lamont
[21:23] <rsavoye> I thought sparc was stil being supported
[21:24]  * micahg saw a post on -devel that it's being discussed at the next TB meeting
[21:24] <rsavoye> we talked about it at UDS
[21:25] <micahg> rsavoye: right, but the decision was to evaluate at Feature freeze if anyone has committed to maintain which they'll do at the next meeting
[21:25] <rsavoye> ah
[23:16] <ScottK> lool: sparc is not dropped, but glib2.0 was eating buildds.  That's why it was banned.
[23:27] <ScottK> rsavoye: So far no on has appeared, so it'll be dropped shortly.
[23:28] <ScottK> (barring last minute maintainers from nowhere)
[23:28] <rsavoye> sounds fair, if nobody wants to support it, why bother...
[23:28] <rsavoye> especially if it causes problems
[23:28] <ScottK> That last sparc installer that worked was in Gutsy.  It doesn't run on Karmic or Lucid as I understand it.
[23:29] <ScottK> It may compile stuff, but it's really quite dead already.
[23:29] <rsavoye> I think with Oracle, Sparc is dead anyway
[23:29]  * ScottK nods
[23:58] <lamont> lool: still around?