[13:08] <Pendulum> does anyone know if the OMG!Ubuntu guys have an IRC channel?
[13:17] <Pendulum> akgraner: I've got about 1/2 of ITB done and in, however, I'm getting error messages when I try to go to anything on OMG!Ubuntu
[13:17] <Pendulum> downforme says it's just me so I don't know if anyone else can do those articles
[13:18] <Pendulum> if not I suggest just leaving the links in without summaries for now as I'm sure the site and content will be back up within a day (if it's truly down)
[13:20] <Pendulum> akgraner: nevermind, now they're working so I'll get those done
[13:29] <Pendulum> akgraner: ITB is done
[14:32] <akgraner> Good Morning :-)
[14:43] <Pendulum> akgraner: ITB is done and on the google doc (because the etherpad seemed to be empty)
[14:43] <Pendulum> I am heading out shortly to go ruin my shoulders at a historical museum with really really yummy cookies
[14:44] <akgraner> Pendulum, thank you!
[14:45] <akgraner> Have fun - Happy 4th!
[14:55] <Pendulum> thanks! you too!
[15:23] <nhandler> Pendulum:
[15:23] <nhandler> Pendulum: #omg!ubuntu!
[16:07] <akgraner> highvoltage, how goes the planet summaries  - internalkernel how goes in other news?
[16:10] <nhandler> akgraner: I'm going to be out this afternoon, so I'll do the Team Reports in an hour. I just hope not to many teams were planning on doing their reports later today
[16:11] <akgraner> nhandler, nods...  I plan on publishing around 5pm
[16:12] <akgraner> nhandler, you always ask them to have them in on Saturdays iirc and remind them a week before - so if it doesn't go in  - it's not on you :-)
[16:13] <akgraner> to have it in on Saturdays (dang I am expecting you to read my mind)  sorry about that  - missing word fail there
[16:20] <akgraner> I am bummed the other past editors I asked to comment only one did :-( - I suppose life happens though
[16:32] <internalkernel> akgraner: gotta run out for a bit, but I'll hit other news when I get back... tanx!
[16:37] <akgraner> nhandler, add what you have and just let me know which teams I should check on before I publish and I'll just add them manually..
[16:55] <nhandler> akgraner: I'm not as concerned about the LoCos, I would have liked it if some of the Councils had finished their reports. I think I'll start sending my reminder to the team councils mailing list in the future. But the councils are the only teams I would check on
[16:56] <akgraner> nhandler, gotcha - I'll check on the before I publish then
[16:56] <nhandler> Thanks a lot akgraner
[16:57] <akgraner> nhandler, no worries  - and enjoy your afternoon! and Happy 4th!
[17:35] <akgraner> nhandler, just let me know when you have added the reports :-) just so I know when you've done your thing - thanks!
[17:35] <nhandler> akgraner: I'm running to the store, and I'll add them when I return. I've started formatting them, and just have to fix CammelCases
[17:36] <akgraner> awesome!  Thanks!
[17:36] <highvoltage> akgraner: shey!
[17:36] <highvoltage> oops, hey :)
[17:36] <akgraner> hey
[17:37] <highvoltage> I had lots of interruptions but I'm getting into the UWN stuff now
[17:41] <akgraner> ok let me know if you need some help I'm finishing up a few things will be out of the wiki in just a sec
[17:44] <akgraner> ok I am out of the wiki for anyone who needs to get in there for a few
[18:31] <nhandler> akgraner: Team Reports are up
[18:31] <akgraner> nhandler, thank you!
[18:31] <nhandler> I've told people who looked like they might be working on reports to ping you and me in here when they are done
[18:32] <akgraner> great!
[18:32] <akgraner> Thank you!
[18:32] <nhandler> Also, I forgot that the upcoming meetings section was still done by hand. I could probably borrow some ClassBot code and automate that section. Would this help you scott_ev ?
[18:33] <akgraner> nhandler, that would help all of us ;-)
[18:33] <highvoltage> nhandler: cool, I said to akgraner just last week it would be really cool if that was automated!
[18:34] <nhandler> If I remember after the holidays, I'll start looking into it.
[18:34] <nhandler> highvoltage: Yeah, it seems like a very tedious task (I must give scott_ev credit for doing that :) )
[18:34] <akgraner> nhandler, if you have time then great!
[18:35] <nhandler> akgraner: Most of the code is already written. I just need to modify it to display the output in wiki format
[18:35] <akgraner> oh cool!
[18:46] <zkriesse> akgraner: and I'll be writing the BT report here today
[18:46] <akgraner> BT report?
[18:47] <zkriesse> Beginners Team
[18:47] <akgraner> ahhh - just let me know the link when you have it finished
[18:47] <zkriesse> yup
[19:14] <zkriesse> scott_ev: ya 'round?
[19:39] <highvoltage> akgraner: I sometimes have some trouble summarizing some entries because I'm not sure what angle the summary should take, or what the important parts are that should be emphasized
[19:39] <highvoltage> this one is an example of that: http://blog.brettalton.com/2010/07/02/local-school-board-and-ubuntu/
[19:39]  * akgraner looks
[19:40] <highvoltage> is the story here that they are warming up to Ubuntu, that 3 years desktop support is still short for some companies or that some 3rd party providers just suck at supporting their own products?
[19:40] <highvoltage> (or perhaps all of that?)
[19:42] <scott_ev> zkriesse: mormnin
[19:42] <scott_ev> akgraner: mornin
[19:42] <zkriesse> hey scott_ev how ya doin
[19:42] <scott_ev> time to do my part
[19:42] <scott_ev> so far, so good - got my starbucks and waiting on morning meds to work
[19:42] <scott_ev> you?
[19:42] <zkriesse> eh editing some wiki....
[19:46] <akgraner> highvoltage,  see  http://ietherpad.com/UWN
[19:47] <scott_ev> zkriesse: mine is looking pretty good
[19:49] <highvoltage> akgraner: ah, pros-and-cons angle... thanks!
[19:50] <akgraner> yep.. it's important for the developers to see how things are being used - and what happens when things aren't supported anymore
[19:50] <akgraner> not that it changes people's minds but lets everyone know what and how people are using Ubuntu
[19:50] <scott_ev> wow, I've never seen etherpad before
[19:51] <akgraner> scott_ev, I like it  - it's like gobby
[19:51] <akgraner> but it's web based and now it's been open sourced
[19:51] <scott_ev> nice simple kayout
[19:51] <scott_ev> layout
[19:51] <akgraner> nods
[19:51] <akgraner> it's great for real time joint collaboration
[19:54] <scott_ev> I found my new desktop Ubuntu derivative
[19:55] <czajkowski> aloha
[19:55] <scott_ev> INX Linux
[19:55] <scott_ev> oi
[19:55] <czajkowski> Irish team report is a bit late so if too late we understand https://wiki.ubuntu.com/IrishTeam/TeamReports/10/June
[19:57] <scott_ev> czajkowski: I bet it can still be incorporated but it's up to our overworked benevolent editor akgraner
[19:58] <czajkowski> aye like I said I know tis late
[19:58] <czajkowski> one of the guys who always does it completely forgot and then we had a mini emergecny at home, so if it can, that's great if not, we understand
[19:58] <czajkowski> scott_ev: thanks
[19:59] <scott_ev> czajkowski: just make sure you talk to akgraner
[19:59] <czajkowski> akgraner: you about ?
[19:59] <scott_ev> I'm in no position of decision making
[19:59] <czajkowski> scott_ev: aye aye, tis cool, will poke akgraner
[19:59] <scott_ev> kk
[20:00] <highvoltage> it's also kind of hard to summarize someone's entry if you don't completely agree with them :)
[20:01] <akgraner> czajkowski, yep we'll add it - thanks
[20:02] <czajkowski> akgraner: *hugs* thanks
[20:02] <czajkowski> highvoltage: bless :)
[20:02] <akgraner> very welcome
[20:02] <highvoltage> czajkowski: bless?
[20:02] <czajkowski> highvoltage: doesnt come across well on irc, picture my tone :) at your comment
[20:03] <akgraner> highvoltage, that's why i try not to apply what i think on a person level until monday
[20:03] <akgraner> personal i mean
[20:03] <highvoltage> czajkowski: :)
[20:35] <highvoltage> akgraner: woops, forgot to say, the summaries are done but I'm not sure how good they are, mind taking a look for some feedback?
[20:35] <akgraner> highvoltage, sure i'll take a look and let you know :-)
[21:18] <scott_ev> akgraner: finished upcoming meetings & events
[21:18] <scott_ev> it's in the wiki
[21:18] <akgraner> scott_ev, thanks!
[21:19] <scott_ev> np. it's kinda fun
[21:20] <akgraner> scott_ev, check those dates ;-)
[21:21] <scott_ev> kk
[21:21] <scott_ev> oops
[21:22] <akgraner> :-)
[21:23] <akgraner> also pull the LoCo team meetings off the UWN list I'll send out a note and link to the LoCo Team meeting Calendar next week and ask newz2000 to add a header and links to all the Calendars
[21:24] <akgraner> I created the new one and we'll get it up and start adding too it next week
[21:24] <akgraner> Don't take them off the Fridge Calendar  - just don't put them into UWN
[21:25] <scott_ev> fixed
[21:26] <scott_ev> OK, that's gonna start next week  - nice
[21:29] <holstein> akgraner: ping
[21:29]  * holstein just making sure everything is covered
[21:30] <holstein> news-wise
[21:30] <holstein> i picked up another gig for tonite, and im going to be leaving soon :/
[21:30] <akgraner> holstein, have fun!
[21:31] <akgraner> we'll be finished shortly so no worries
[21:31] <holstein> COOL
[21:31] <holstein> :)
[21:31] <holstein> i'll get back on the wagon next week
[21:31] <holstein> laterz
[21:31] <akgraner> scott_ev, nods yep the upcoming events goes from Monday to Sunday
[21:31] <akgraner> holstein, thanks
[21:33] <scott_ev> isn't that what I did?  lemme check
[21:34] <akgraner> scott_ev, you did - I was agreeing and adding that for the benefit of everyone
[21:34] <cjohnston> akgraner: if something could be included on user day saturday would be much apprecieated.. i dont have time to write anything right now
[21:34] <scott_ev> ah, OK
[21:34] <cjohnston> maybe Pendulum or pleia2 could
[21:34] <akgraner> cjohnston, let me see it it has been mentioned somewhere we are about to publish in about 45 minutes
[21:34] <akgraner> if it has
[21:35] <cjohnston> :-)
[21:35] <cjohnston> I just added the loco dir meeting thursday too
[21:35] <akgraner> is it on the calendar?
[21:35] <cjohnston> it is now
[21:35] <cjohnston> i added it
[21:35] <akgraner> the Fridge Calendar too
[21:36] <cjohnston> i added to fridge cal and uwn meetings list
[21:36] <akgraner> ok
[21:36] <akgraner> you are cutting it close :-)
[21:36] <cjohnston> its not my meeting...
[21:36] <cjohnston> :-P
[21:36] <cjohnston> there is a article in the uwn about it tho
[21:36] <cjohnston> heh
[21:50] <akgraner> yep Daniel added it
[22:10] <akgraner> hey folks I am adding the ION summaries  if you want to read through the newsletter and see if there are any glaring spelling or grammar errors  - let me know
[22:13] <scott_ev> ....don't read upcomming meetings & events....
[22:20] <akgraner> internalkernel, hey!
[22:20] <akgraner> can you start proofing I am adding the ION summaries..


[00:15] <jamesh> thumper: ping?
[00:15] <thumper> jamesh: pong
[00:17] <jamesh> thumper: I'm getting timeouts trying to access Launchpad at the moment.  I was wondering if it is just my connection or something further upstream
[00:17] <thumper> jamesh: edge?
[00:17] <jamesh> yeah
[00:17] <thumper> seems ok to me
[00:18] <thumper> what sort of things are you doing?
[00:18] <thumper> I just went to the bzr overview and code page
[00:18] <thumper> no problems
[00:18] <jamesh> I'm also timing out on the Canonical IRC server
[00:20] <thumper> jamesh: I think it is just you
[00:20] <thumper> or your connection to the UK
[00:20] <jamesh> thumper: thanks.  I guess I'll check with my ISP
[00:20] <thumper> jamesh: ok
[02:18] <aleka> What is the average lag time between requesting a translation .po file and receiving it via email on LP?
[02:35] <Hobbsee> sabdfl: :D  thanks!
[03:35] <ubotu> New bug: #163968 in malone "Problems with drop down list on incorrect team name" [Undecided,New] https://launchpad.net/bugs/163968
[03:38] <sabdfl> sure Hobbsee
[03:42]  * Hobbsee throws more stuff at ppa
[05:38]  * Hobbsee pokes launchpad
[05:39] <Hobbsee> error ID  OOPS-689EA15
[05:39] <Hobbsee> mpt: do you want a bug for a broken URL, or do you want to just fix it?
[05:40] <Hobbsee> +editemail != +contactaddress
[05:41] <Hobbsee> bwah?
[05:41] <Hobbsee> it appears these are 2 separate sections now.
[05:41] <mpt> Hobbsee, I can use grep :-)
[05:41] <Hobbsee> what happened to the old manage email addresses page, where you could select the default?
[05:41] <Hobbsee> and why do we have this duplication?
[05:42] <Hobbsee> mpt: https://edge.launchpad.net/%7Ekubuntu-members/+editemail is a 404, but apparently shouldn't point to https://edge.launchpad.net/~kubuntu-members/+contactaddress
[05:42] <Hobbsee> because the dialog is different
[05:43]  * Hobbsee wonders how one is supposed to set the default email address now.
[05:43] <Hobbsee> or remove them.
[05:45]  * Fujitsu guesses it's due to the new mailinglist crack.
[05:45] <Hobbsee> Fujitsu: would be odd...
[05:46] <Hobbsee> Fujitsu: you used to be able to manage addresses for people and teams, and set the default
[05:46] <Hobbsee> but i like this "notify the email, or notify everyone on the team" bit.
[05:47] <Fujitsu> Hobbsee: It's like that on production too, so it's not a particularly new thing.
[05:47] <Hobbsee> Fujitsu: how weird!
[05:48]  * Fujitsu wonders how the upgrade can manage to take 3.5 hours.
[05:48] <Hobbsee> mpt: i think i'll file a bug on this - because they're not the same dialog
[05:48] <Fujitsu> Some translation schema changes, I guess...
[05:48] <Hobbsee> and hey, one of my bugs got fixed in a day, so maybe it's worth reporting them :P
[05:49] <Fujitsu> Nice.
[05:49] <Hobbsee> was a soyuz regression bug, but still :)
[05:50] <mpt> Hobbsee, yeah, it's a mistake that has its own typo
[05:50] <Hobbsee> mpt: ah, goody :)
[05:50] <Hobbsee> mpt: can i ask why we have 2 dialogs for essentially the same thing?
[05:50] <mpt> Because barry needs more coffee
[05:51] <Hobbsee> a logical enough reason, i guess :)
[05:51] <stdin> do ppa's look in ${release}-backports ?
[05:51] <mpt> It should be one page that shows different stuff depending on whether it's yourself or a team you're dealing with
[05:52] <mpt> not two pages with one of them hidden by a typo
[05:52] <Hobbsee> mpt: got it :)
[05:52] <stdin> or can they?
[05:52] <mpt> thanks Hobbsee
[05:52] <Fujitsu> stdin: They do not.
[05:52] <Hobbsee> mpt: you're welcome, thanks for fixing it.
[05:59]  * thumper checks for reviewer meeting
[06:00]  * thumper notices it isn't on just yet, and heads back to the BBQ
[06:00]  * Hobbsee heads off to work
[06:02]  * thumper wishes he had a little program to send an SMS when pinged...
[06:02] <jamesh> I think it is time for the review meeting
[06:02] <jamesh> who is here?
[06:05] <thumper> me
[06:05] <thumper> sort of
[06:05] <thumper> BBQ is cooking dinner
[06:05] <thumper> :)
[06:05] <jamesh> spiv, lifeless: ping for review meeting?
[06:05] <jamesh> I guess jml and jtv won't be available
[06:06] <thumper> nah, jml won't be making it today
[06:06]  * thumper smells good food, garlic mushrooms I think...
[06:07] <thumper> jamesh: it might just be you and me
[06:07] <jamesh> I don't think there is much to discuss, so it'll be short
[06:08] <thumper> there seems to be quite a few branches that didn't make it all the way through the review process for 1.1.11
[06:08] <jamesh> any problem holding next weeks meeting at the same time?
[06:08] <thumper> but the current queue is short
[06:08] <thumper> same time is fine for me
[06:09] <jamesh> I wonder how many of those branches were submitted for merge?
[06:09] <thumper> I'm going to propose that they decide in the US/EU meeting that we implement the slots
[06:09] <thumper> and suggest people no longer use the general queue
[06:09] <thumper> not sure about the number submitted
[06:09] <jamesh> given that there aren't many people here it is probably best to do the review process discussion on list
[06:09] <thumper> it seems that quite a few got stuck in needs-reply
[06:09] <thumper> jamesh: fair enough
[06:10] <thumper> I think that almost everyone agrees anyway
[06:10]  * thumper smells burning
[06:11] <thumper> jamesh: I don't have anything else particular to bring up
[06:11] <thumper> jamesh: do you?
[06:11] <jamesh> nope.
[06:11] <thumper> ok, it looks like we're done then
[06:11] <thumper> thanks jamesh
[06:11]  * thumper heads back to food and the BBQ
[06:15] <lifeless> thanks jamesh;
[06:16] <lifeless> I started at 5am; finished earlier and was awol at the meeting time.
[06:51] <ubotu> New bug: #163991 in malone "Attachments for initial comment are not displayed" [Undecided,New] https://launchpad.net/bugs/163991
[07:20] <ubotu> New bug: #163997 in soyuz "Subject of Soyuz binaryful acceptance emails, emails, emails, emails, emails, emails stutter" [Undecided,New] https://launchpad.net/bugs/163997
[07:24] <carlos> morning
[07:24] <Fujitsu> Morning carlos.
[09:36] <mrevell> morning
[09:39] <Fujitsu> Hmm... Am I missing something, or are security uploads no longer being announced to *-changes?
[09:39] <Fujitsu> That seems to be a fairly nasty regression.
[09:42] <slytherin> Hi. Has anyone else noticed this. Changing the ownership of a bzr branch doesn't change the url in branch/bound i.e. target branch
[09:43] <Fujitsu> Right, there have been no security uploads announced to -changes since they day before 1.1.10.
[09:43]  * Fujitsu files a bug.
[10:00] <ubotu> New bug: #164027 in soyuz "As of 1.1.10, security uploads no longer generate announcements to <distroseries>-changes" [Undecided,New] https://launchpad.net/bugs/164027
[10:06] <ubotu> New bug: #164029 in launchpad-bazaar "Changing owner of a branch does not change target url in branch/bound" [Undecided,New] https://launchpad.net/bugs/164029
[10:11] <Fujitsu> slytherin: Erm, how is Launchpad going to modify your local branch?
[10:12] <slytherin> Fujitsu: no. this is not about modifying local branch. I synced/pulled from launchpad from scratch.
[10:12] <Fujitsu> slytherin: Which URL did you pull from?
[10:13] <slytherin> Fujitsu: http://bazaar.launchpad.net/~apt-offline/apt-offline/dev
[10:14] <Fujitsu> slytherin: Works fine for me.
[10:14] <Fujitsu> It would be the local bzr setting that URL, anyway.
[10:15] <slytherin> Fujitsu: works fine as in? what did you try?
[10:15] <Fujitsu> slytherin: I bzr got it.
[10:16] <Fujitsu> Then bzr upped and bzr infoed it.
[10:17] <slytherin> let me try pull from scratch once again
[10:18] <Fujitsu> I suspect you were using an old branch (accidentally or otherwise), as I don't see where it could get that URL otherwise.
[10:50] <slytherin> Fujitsu: hmm. looks like it is not a bug. my bad. I will try a few things first and then close it as invalid
[11:40]  * Hobbsee waves
[12:09] <stdin> hmm, is there a limit (quota) for ppa's?
[12:10] <Hobbsee> stdin: 1gb, but not yet
[12:10] <Hobbsee> not until you can remove packages
[12:10] <stdin> Hobbsee: good, because apparently I'm using 4.4GB
[12:14] <mrevell> The 1gb quote will almost certainly be negotiable
[12:14] <mrevell> s/quote/quota
[12:15]  * Hobbsee waves to mrevell and carlos
[12:15] <mrevell> yo Hobbsee
[12:15] <mrevell> Hmm, I'm gonna take a lunch break. biab
[12:29]  * Hobbsee waves to Spads
[12:29]  * Spads waves in return
[12:35] <gnomefreak> are the buildds for ppa hardy messed up by chance?
[12:37] <Hobbsee> gnomefreak: which in particular?
[12:38] <gnomefreak> not sure atm but it was 386 64 and the other arch all failed, said failed to apply or remove patch but builds fine locally
[12:38] <gnomefreak> let me see if i can find it
[12:39] <gnomefreak> its a bunch of them
[12:39] <Hobbsee> gnomefreak: if you've got a build log, that would be handy
[12:40] <gnomefreak> http://launchpadlibrarian.net/10478174/buildlog_ubuntu-hardy-i386.nss_3.12.0%7Ecvs20071118t2115-0ubuntu1%7Eppa1_FAILEDTOBUILD.txt.gz  failed during make not patches
[12:42] <gnomefreak> all nss failed that way
[12:42] <gnomefreak> nspr failed with http://launchpadlibrarian.net/10478117/buildlog_ubuntu-hardy-i386.nspr_4.7.0%7Ecvs20071106t1834-0ubuntu1%7Eppa1_FAILEDTOBUILD.txt.gz
[12:43] <Hobbsee> gnomefreak: how's that a failed to apply or remove patch?
[12:43] <gnomefreak> nspr is the failed patch Applying patch 30_config_64bits.patch
[12:43] <gnomefreak> patching file mozilla/nsprpub/configure.in
[12:43] <gnomefreak> Hunk #1 FAILED at 52.
[12:43] <gnomefreak> Hunk #2 FAILED at 218.
[12:43] <gnomefreak> 2 out of 2 hunks FAILED -- rejects in file mozilla/nsprpub/configure.in
[12:43] <gnomefreak> Patch 30_config_64bits.patch can be reverse-applied
[12:43] <gnomefreak> nss is glibc errors
[12:44] <Hobbsee> i'd only looked at the first one
[12:44] <Hobbsee> that would be...rather odd for that to build locally
[12:44] <gnomefreak> nss (the first one) is glibc errors and come to think of it i have a bug on that, but why would it build cleanly here
[12:45] <gnomefreak> i built and have it installed
[12:45] <Hobbsee> what are you building in?
[12:46] <gnomefreak> http://pastebin.mozilla.org/246174
[12:46] <gnomefreak> that is build dir for nss
[12:46] <gnomefreak> im building it in hardy system
[12:46] <gnomefreak> no chroot no pbuilder just system
[12:47] <Hobbsee> head-->desk.
[12:47] <Hobbsee> try it in a proper builder (sbuild or pbuilder), and see if it still breaks.
[12:47] <gnomefreak> nspr xulrunner and ff3 also built fine here
[12:47]  * gnomefreak doesnt know how to use pbuilder thats why i use chroots
[12:47] <Hobbsee> asked for help?
[12:48] <Hobbsee> followed !pbuilder?
[12:48] <gnomefreak> i didnt think there was a need since it built fine here
[12:48] <Hobbsee> you need a clean source, and a clean build place, how else do you expect it to work fine on others systems?
[12:48]  * Hobbsee wonders if the patch is already applied or something, so that's why it's bailing.
[12:49] <gnomefreak> i didnt add patches i just renamed already built sources and re tared the dir up and changelog edit
[12:49] <Fujitsu> pbuilders are easier to use than plain chroots, and actually do sane things.
[12:50]  * Hobbsee tries it here
[12:50] <gnomefreak> Hobbsee: nspr needs to be first build
[12:51] <gnomefreak> cant remember what version of nspr and nss are in hardy but since i was building it for ppa nsor than nss than xulrunner than ff3
[12:53] <Hobbsee> gnomefreak: OK, so it doesnt apply here
[12:53] <gnomefreak> it does here :(
[12:53]  * gnomefreak wonders why
[12:54] <Hobbsee> gnomefreak: debian/patches/30_config_64bits.patch is already applied to your source.
[12:54]  * Hobbsee thinks you screwed over your source, and didn't rebuild in a clean place
[12:55] <Hobbsee> gnomefreak: in fact, both 30_'s have been applied, adn it's bad to have 2 patches starting with the same #
[12:55] <Hobbsee> methinks you applied the patches to the source, *then* built the source.
[12:55] <gnomefreak> Hobbsee: i didnt make the patches i only took already built sources from someones archive to build for ppa
[12:56] <gnomefreak> might have i will try cleaning it up and trying again
[12:56] <Hobbsee> yup, they're all already applied.
[12:56] <Hobbsee> gnomefreak: who was the someone, and do you trust their packaging skills to be sane?  :)
[12:57] <gnomefreak> yes i trust them
[12:57] <gnomefreak> they started on 3.0 right after alpha1
[12:57] <Hobbsee> then either their source was wrong...or yours is :)
[12:58] <gnomefreak> i think i know what happened its my fault if im right
[12:58] <Hobbsee> the patches got applied manually, it appears, and then the source got built.
[13:40] <AnMaster> hey is there a way to get new commits in a branch hosted on launchpad as rss, subscribing seems to be email only, right?
[13:41] <AnMaster> I just want rss with the commit message of new commits
[13:43] <gmb> AnMaster: At the moment that functionality isn't available. However, it is being worked on :)
[13:43] <AnMaster> ah I see
[13:49] <cavedon> hi all!
[13:50] <cavedon> mrevell, SteveA: what about launchapd-beta-testers membership approvation?
[13:51] <mrevell> cavedon: Hi, have you have applied for membership?
[13:51] <cavedon> I made a resquest a couple of days ago
[13:51] <cavedon> on 17th
[13:52] <mrevell> cavedon: I've approved your membership. welcome to the team
[13:53] <cavedon> mrevell: thank you!
[13:53] <mrevell> np :)
[14:25] <lamont> cprov: could I talk you into a mass-give-back on lpia/hardy?
[14:25] <lamont> I get tired of clicking
[14:25] <ubotu> New bug: #164065 in launchpad-bazaar "more revision properties" [Undecided,New] https://launchpad.net/bugs/164065
[14:25] <Hobbsee> lamont: another greasemonkey script required?
[14:25] <lamont> that's more than a script...
[14:25] <Hobbsee> ooh, more interesting options here
[14:25] <Hobbsee> oh i know :)
[14:26] <Hobbsee> lamont: it's yours that does the build rescores in a click, isnt it?
[14:26] <lamont> mithrandir is more to blame for it - I just use it.
[14:26] <lamont> otoh, the version I have is currently broken (claims to work, doesn't change anything)
[14:26] <cprov> lamont: I'm about to leave for lunch, can we talk when I come back or is it urgent ?
[14:26] <Hobbsee> lamont: the one i'm using works fine
[14:26]  * lamont wishes those LP guys would quit breaking greasemonkey scripts with their changes...
[14:26] <lamont> cprov: no hurry
[14:27] <lamont> there are a bunch of failures and I'm too lazy to figure out which ones
[14:27] <lamont> :-)
[14:27] <cprov> lamont: ok, talk to you in bit.
[14:27] <lamont> Hobbsee: hrm... could be that retry works, and rescore is b0rked.  dunno
[14:28] <Hobbsee> lamont: although, it appears to just say it's worked, show the correct increment, but not go back to the previous page
[14:28] <Hobbsee> which should be simple to fix, but i dont speak greasemonkeyesque.
[14:29] <lamont> I don't mind it not going back a page... what I was seeing was that when I went back to the build queue and hit shift-reload, I didn't see the new scores.
[14:29] <lamont> which is, um, strange
[14:29] <Hobbsee> weird.  i'd say yours is borken
[14:30] <lamont> cprov-lunch: actually, the bigger question is why lpia isn't doing anything with the 300+ builds it has in needs-build...
[14:30] <Hobbsee> lamont: i was wondering that earlier.
[14:31] <lamont> hppa is back below 2600 needs-builds... :-(
[14:32] <Hobbsee> mrevell: u-d mail unmoderated btw.
[14:32] <mrevell> Hobbsee: Thanks. I thought I was a member. I'll have to rejoin.
[14:33] <Hobbsee> mrevell: for non-developers, it's moderated.
[14:33] <Hobbsee> and as you're not a part of ~ubuntu-dev...
[14:33] <mrevell> Hobbsee: Ah right...
[14:33] <Hobbsee> :)
[14:47] <lamont> cprov-lunch: and ~lamont/chroot-fresh has freshened hardy chroots to help speed the build process along a little
[14:49]  * lamont heads officewards
[14:56] <ubotu> New bug: #164071 in malone "The comments in +text are difficult to read" [Undecided,Confirmed] https://launchpad.net/bugs/164071
[18:05] <ubotu> New bug: #164136 in rosetta "+translate page triggering a ShortListTimeOutError" [Critical,New] https://launchpad.net/bugs/164136
[18:35] <ubotu> New bug: #164144 in launchpad "oops tools should categorize ProtocolErrorException in a different section" [High,Confirmed] https://launchpad.net/bugs/164144
[18:46] <crevette> hello
[18:47] <crevette> is there people here which can help me with liblaunchpad-integration APIs ?
[18:48] <glatzor> Hello, I would need to remove some file from a PPA, since I made a versioning error
[18:55] <crevette> how can I integrate liblaunchpad-integration with glade ?
[18:56] <crevette> gcalctool migrates to glade
[18:56] <crevette> migrated even
[19:01] <carlos> crevette: you mean to get the extra entries in the Help menu?
[19:11] <glatzor> crevette: take a look at synaptic
[19:11] <glatzor> crevette: basically a three line patch:
[19:12] <glatzor> +#include <launchpad-integration.h>+   widget = glade_xml_get_widget (_gladeXML, "help1_menu");
[19:12] <glatzor> +   launchpad_integration_add_items (widget, -1, TRUE, TRUE);
[19:24] <crevette> thanks glatzor
[19:35] <jelmer> is there some XML/RPC that can be used to obtain the list of branches registered on launchpad?
[19:45] <ubotu> New bug: #164162 in launchpad "OOPS when requesting a non-existent host" [High,Triaged] https://launchpad.net/bugs/164162
[20:31] <thumper> morning lunch padders
[21:00] <mpt> Gooooooooooooooood morning Launchpadders!
[21:08] <thumper> morning mpt
[21:23] <cr3> is there a plan to make code.launchpad.net support private branches?
[21:24] <thumper> cr3: yes, why?
[21:38] <cr3> thumper: I would very much like that for my own projects :) is there any scheduled date for this feature?
[21:39] <thumper> cr3: yes, see priv msg
[22:15] <ubotu> New bug: #164196 in malone "Quickly-undone actions shouldn't send mail notifications" [Undecided,New] https://launchpad.net/bugs/164196
[22:52] <stdin> are the any PPA admins about, I need some packages removed from my PPA


[03:00] <NCommander> Man, Freenode been glitchy
[03:01] <ScottK> You say that like it's news.
[03:05] <NCommander> ScottK, I remember freenode when it was steady as a rock
[03:06] <ScottK> NCommander: Do you have some time to try and verify a security patch for me (It's C, so I'm hopeless)?
[03:06] <jdong> NCommander: yeah yeah and you walked in 15 feet of snow uphill and downhill everyday to school in the next city....
[03:07] <ScottK> jdong: You got it wrong, "Up hill both ways".
[03:07] <NCommander> jdong, no, I took a bus
[03:07] <NCommander> ScottK, define verify
[03:07] <jdong> NCommander: verify (v. trans. InfoSec): "Yeah, I think most of ~/ is still there AFAICT..."
[03:07] <jdong> *ducks*
[03:07] <ScottK> NCommander: Upstream produced a new upstream release that has both a working exploit test and a very invasive fix.
[03:08] <NCommander> Ok
[03:08] <ScottK> NCommander: Upstream gave a hint on how to shortcut avoiding the problem in a less invasive way
[03:08] <ScottK> NCommander: Debian maintainer has produced a patch that he thinks is good, but upstream doesn't have time to deal with confirming it works.
[03:09] <ScottK> I'm looking for some independent verification.
[03:09] <NCommander> So, why not install package, run verification test?
[03:09] <ScottK> You've looked at the code before so I thought of you.
[03:09] <ScottK> I'd have to understand Perl to run the test.
[03:10] <ScottK> That and I'm currently busy trying to understand why cmake seems broken in Jaunty.
[03:18] <ScottK> I guess that's a no then.
[03:18] <ScottK> Tries again.
[03:18] <ScottK> I guess that's a no then.
[03:20] <NCommander> ScottK, sorry, my laptop froze
[03:20] <NCommander> ScottK, sure, I can be convinced to test it
[03:20] <ScottK> OK.  I'll email you some stuff.  You'll want libspf2 from Jaunty and Hardy.  What address.
[03:22] <ScottK> NCommander: ^^
[03:23] <NCommander><EMAIL_ADDRESS>[03:24] <ScottK> NCommander: Forwarded you the upstream hint and the proposed patch.
[03:24] <NCommander> is the patch in jaunty or the new upstream?
[03:25] <ScottK> The patch is against 1.2.5 (in Dapper -> Hardy).
[03:25] <ScottK> The new upstream is in Jaunty/Intrepid-security.
[03:25] <ScottK> The test is in the new upstream.
[03:25]  * NCommander grabs the jaunty source package
[03:26] <ScottK> If the package is vulnerable, the test will cause a segfault.
[03:26] <ScottK> NCommander: Be sure to grab the -security version.
[03:26] <NCommander> ScottK,   libspf2-2: Depends: glibc-private but it is not installable
[03:26] <ScottK> That adds the patch that made it possible to get to this problem (fix one vulnerability and expose another latent one |o/)
[03:26] <NCommander> *ahem*
[03:27] <ScottK> ?
[03:27] <NCommander> Trying to install on jaunty
[03:27] <NCommander> Package is broken
[03:28] <ScottK> Weird.  Installs on Intrepid.
[03:28] <ScottK> Same package.
[03:28] <NCommander> :-P
[03:28] <NCommander> Yeah
[03:28] <NCommander> its broken on jaunty
[03:28] <ScottK> OK.  Separate issue.  I'll look at that.
[03:29] <NCommander> ok, I figured out how to run the test suite against various versions of the package :-)
[03:29] <ScottK> Great.
[03:29] <NCommander> I'll test the jaunty package (assuming it compiles)
[03:29] <ScottK> Try the hardy-security version against it and see.
[03:30] <NCommander> I need to have a known working negetive
[03:30] <ScottK> Right.
[03:30] <NCommander> argh
[03:30] <NCommander> damn it
[03:30] <NCommander> I actually have to install the library
[03:30]  * NCommander breaks pbuilder out
[03:31] <NCommander> argh
[03:31] <NCommander> the test suite needs a non-packaged perl module it seems
[03:34] <ScottK> Upstream runs Gentoo, so who knows.
[03:34]  * NCommander whacks head
[03:34] <NCommander> bah
[03:34] <NCommander> Getting this test suite to run is a ****
[03:35]  * NCommander upgrades perl base
[03:35] <NCommander> ok
[03:35] <NCommander> confirmed that the version in jaunty does not suffer the buffer overflow
[03:38] <NCommander> argh
[03:40] <NCommander> t/11_overflows.......dubious
[03:40] <NCommander> 	Test returned status 0 (wstat 11, 0xb)
[03:40] <NCommander> DIED. FAILED tests 3-5
[03:40] <NCommander> 	Failed 3/5 tests, 40.00% okay
[03:41] <NCommander> ScottK, ^
[03:41] <NCommander> (that being said, the test suite might be a false postive, I had to kick it to actually compile )
[03:41] <ScottK> That's Jaunty?
[03:41] <NCommander> Hardy security
[03:42] <ScottK> OK.  I'm fairly certain that one isn't vulnerable.  More than one person who knows the code verified that.
[03:42] <ScottK> Ah.  Hardy Security.  Sorry
[03:42] <NCommander> yeah
[03:42] <NCommander> it segfaulted
[03:43] <ScottK> I'd expect Hardy Security to fail.
[03:43] <ScottK> That's the indication it's vulnerable.
[03:43] <NCommander> it got through 2/3 tests however
[03:44] <ScottK> The patch in Hardy security I think is tested for in that same test.
[03:45] <NCommander> root@blacksteel:~/libspf2-1.2.5.dfsg/perl# perl t/11_overflows.t
[03:45] <NCommander> 1..5
[03:45] <NCommander> ok 1 - use Mail::SPF_XS;
[03:45] <NCommander> ok 2 - parse_cidr did not run off start of data
[03:45] <NCommander> Segmentation fault
[03:46] <ScottK> I think that's right.  I suspect the one in hardy-release would fail 2
[03:48] <NCommander> so now what?
[03:48] <NCommander> libspf has two rdepends
[03:48] <NCommander> It might just be worth doing a backport
[03:50] <ScottK> So the question is does the patch I emailed you fix it?
[03:50] <NCommander> oh
[03:50] <NCommander> I thought the patch was applied already
[03:52] <ScottK> No.
[03:52] <ScottK> I emailed you patch #2 that hopefully finishes fixing it.
[03:52] <NCommander> Lets find out
[03:53] <NCommander> t/11_overflows.......ok
[03:53] <NCommander> WOOOO!
[03:53] <cody-somerville> NCommander, chillax :P
[03:53] <NCommander> chillax?
[03:55] <ScottK> NCommander: So it works.  Would you view it as sane?
[03:56] <NCommander> Yes, expect it makes a blank patch file as well
[03:56] <NCommander> 51_actually-keep-track-of-max_var_len.dpatch - empty
[03:56] <NCommander> 52 - has the real patch
[03:57] <ScottK> expect/except?
[03:57] <NCommander> *except :-P
[03:58] <ScottK> OK.
[03:58] <ScottK> NCommander: Thanks.  I'll work on -security debdiffs then.
[03:58] <NCommander> \o/
[03:58] <ScottK> NCommander: Any thoughts on where glibc-private in Jaunty comes from?
[03:59] <NCommander> no idea
[03:59] <NCommander> it might just need a binary rebuild
[03:59] <ScottK> Tried that.  No luck.
[03:59] <ScottK> It picks that up from somewhere.
[04:01] <NCommander> apt-cache doesn't know what it is
[04:01] <ScottK> It doesn't exist.
[04:01] <NCommander> its in none of the shlibs files I have
[04:03]  * NCommander pokes LP
[04:18] <NCommander> ScottK, I'm semi-stumped
[04:18] <ScottK> NCommander: I dunno the relevancy, but glibc in Intrepid defines a large number of symbols in GLIBC_PRIVATE that seem to be gone in Jaunty.
[04:18] <NCommander> bug in glibc?
[04:19]  * NCommander debates downgrading to intrepid
[04:20] <ScottK> NCommander: I was thinking more planned change we need to figure out how to work with.
[04:20] <NCommander> ??
[04:21] <ScottK> Looking at debian/changelog this symbol thing was on purpose.
[04:21] <ScottK> Not sure if it's relevant to the problem at hand or not.
[04:21] <NCommander> where is doko when you need him
[05:19] <glaksmono> hello
[05:38] <ScottK> NCommander: Thanks.  -security debdiffs are done.
[05:38] <NCommander> yay
[05:38]  * ScottK goes and sleeps.
[06:23] <\sh> moins
[06:24] <\sh> NCommander: welcome on board of the MOTU ship :)
[06:24] <NCommander> \sh, thanks :-)
[06:24] <NCommander> \sh, do you know who the resident grub guy is on Ubuntu?
[06:25] <\sh> NCommander: nope...sorry...
[06:57] <NCommander> cjwatson, I'd like to talk to you on adding splash images for grub
[07:05] <wgrant> NCommander: Not by default, I hope.
[07:06] <NCommander> wgrant, ?
[07:07] <wgrant> NCommander: It was, I believe, decided that yet another mode change wasn't necessary.
[07:07] <pitti> Good morning
[07:07] <NCommander> wgrant, mode change?
[07:07]  * NCommander notes our current grub does properly support splashimages, and those work just fine
[07:08] <wgrant> NCommander: Splash image == graphical mode == mode switch == flickering == baaad
[07:08] <wgrant> Morning pitti.
[07:08] <NCommander> fair enough
[07:08] <NCommander> morning Pici
[07:08]  * NCommander hit head
[07:08] <NCommander> pitti,
[07:08] <wgrant> Flickering and slowness and other stuff, probably.
[07:08] <pitti> wgrant: pong
[07:08] <wgrant> It's not accidental that we lack a splash image, at any rate.
[07:08] <wgrant> pitti: See bug #293318/
[07:08] <wgrant> I think it's that one.
[07:08] <wgrant> Yes it is.
[07:09] <tjaalton> fedora removed their grub splash image
[07:09] <NCommander> They did?
[07:09] <tjaalton> for the same reason
[07:09]  * NCommander notes Debian still has one
[07:09] <pitti> wgrant: I got the bug mail, yes
[07:09] <NCommander> wgrant, I can find that leak
[07:09] <wgrant> NCommander: Huh?
[07:09] <tjaalton> now they don't even show the menu anymore, unless there's another boot option available (like windows)
[07:09] <NCommander> the memory leak
[07:09] <wgrant> tjaalton: That's what we do, isn't it?
[07:09] <tjaalton> wgrant: yes
[07:09] <wgrant> NCommander: I've even fixed it upstream...
[07:09] <NCommander> oh
[07:10] <NCommander> nm
[07:10]  * NCommander hadn't finished reading the bug :-)
[07:11] <wgrant> NCommander: Why do you want a GRUB splash?
[07:11] <NCommander> Brainstorm #21, and my mom freaked when she saw it when I installed Ubuntu on her PC
[07:12] <wgrant> Surely it's no more scary than watching a POST.
[07:12] <NCommander> At least no computer I've owned in a few years shows a text based PoST
[07:12] <NCommander> ... PSOT
[07:12] <NCommander> ... POST!
[07:12] <NCommander> on mine, I get Sony VIAO -> grub -> usplash
[07:12] <tjaalton> just get rid of windows and you're saved
[07:13]  * NCommander gets the grub countdown
[07:13] <tjaalton> no grub menu anymore
[07:13] <NCommander> yes, I know
[07:13] <Treenaks> On my eee I get grub (very short) -> usplash
[07:13] <Treenaks> \o/ bios quickboot
[07:14] <tjaalton> NCommander: oh, yet another "idea" I can close?-)
[07:15] <NCommander> tjaalton, if you must ;-)
[07:19] <tjaalton> ah, fedora didn't actually remove the splash, but it's not shown unless the menu is
[07:21]  * NCommander notes thats how itlled is on Ubuntu as well if a splash is insta
[07:22] <pitti> wgrant: did you sent the two g-s-d input patches upstream? There aren't any patch headers or gnome bz refs
[07:22] <wgrant> pitti: The upstream-relevant parts are upstream.
[07:22] <pitti> wgrant: ah, nice; thanks
[07:22] <wgrant> I didn't add patch headers because the patches were already there.
[07:24] <pitti> wgrant: I added the bug ref for 293318 to the changelog; does 08_extra_touchpad_options.patch correspond to a bug report, too?
[07:25] <wgrant> pitti: They're both for that bug, though 08_extra_touchpad_options.patch is more of an additional defense.
[07:25] <pitti> ok, thanks!
[07:26] <wgrant> No, thank you.
[07:26] <wgrant> tjaalton: Are any other distros going to be sharing our pain in the immediate future?
[07:26] <pitti> fedora isn't yet?
[07:27] <pitti> wgrant: I assume "pain" == "input hotplug"? :-)
[07:27] <wgrant> pitti: Input hotplug for everything, yes.
[07:30] <dholbach> good morning
[07:31] <tjaalton> wgrant: fedora is
[07:31] <tjaalton> at least
[07:31] <tjaalton> and when lenny is released I bet debian will follow
[07:31] <wgrant> tjaalton: Hmm, I wonder how they dealt with g-s-d...
[07:32] <wgrant> From what I could see they hadn't.
[07:32] <pitti> wgrant: nothing on http://daniel.holba.ch/harvest/handler.py?pkg=gnome-settings-daemon ?
[07:33] <tjaalton> wgrant: what in particular?
[07:34] <wgrant> pitti: No...
[07:34] <wgrant> tjaalton: Mouse settings (most annoyingly right/left-handedness) don't persist when you hotplug devices.
[07:34] <wgrant> Some keyboard stuff doesn't work at all, but that's another less important story.
[07:36] <tjaalton> wgrant: okei
[07:36] <tjaalton> uh
[07:36] <tjaalton> "okay"
[07:44] <pitti> slangasek: did you see the response in bug 236830? seems there is still a bug there?
[08:10] <SYDN> 谁知道有64的JAVA 那里下载
[08:11] <RAOF> Indeed.
[08:12] <SYDN> where
[08:13] <wgrant> I agree with RAOF.
[08:14] <RAOF> Aha.  Sorry.
[08:14] <RAOF> Google tells me that you want to download Java.
[08:15] <RAOF> SYDN: You want the "sun-java6-jre" package.
[08:16] <SYDN> oh
[08:17] <iulian> There is a #ubuntu-cn channel though.
[08:17]  * iulian wonders why he didn't join there.
[08:42] <pitti> mvo: good morning
[08:42] <pitti> mvo: I checked the hardy SRUs, and it seems that bug 220890 is the only one which holds up -updates propagation of 3 hardy-proposed uploads
[08:42] <pitti> mvo: anything we can do about it? or is it not a regression, and we can copy and keep the bug open?
[08:45] <mvo> pitti: I look into it now, sorry that it got put on hold during intrepid
[08:47] <NCommander> Ugh, that one
[08:47]  * NCommander puts that on the Ports todo tracker
[08:50] <slangasek> superm1: ok, changed in bzr, thanks
[08:51] <slangasek> pitti: 236830> the only issue I see at the end of the bug log was user error, which EtienneG addressed?
[08:52] <pitti> slangasek: ahh, I read it as "that's what the package should ship"
[08:52] <mvo> NCommander: what is the url for this?
[08:52] <pitti> slangasek: ok, so that's basically "didn't get any feedback" then
[08:52] <NCommander> mvo, right now, I'm just going to note it on the kernelportspage
[08:52]  * NCommander kicks the spacebar
[08:53] <slangasek> pitti: ah, so it is; I guess we should kick people for testing :/
[08:53] <NCommander> But at least w.r.t. to powerpc, I've been working w/ a bunch of other people to make sure PowerPC is a top-notch port again
[08:55] <emgent> good morning
[08:57] <NCommander> mvo, I think I can probably fix this bug in Jaunty
[08:57] <NCommander> (the ports one)
[08:59] <mvo> NCommander: I check it out now and let you know what I find, I thought I fixed it already :/
[09:00] <NCommander> I thought it was broken on Intrepid
[09:00] <NCommander> mvo, are you a ports user?
[09:00] <mvo> no, that i part of the problem
[09:00] <NCommander> install lpia on something w/ a CD then
[09:01] <NCommander> Its considered a port on LP
[09:02] <mvo> right, good idea
[09:02] <NCommander> I have those occasionally :-)
[09:03] <pitti> mvo: I'm ready to accept update-manager for intrepid-proposed, unless you have some more changes stacked up?
[09:05] <mvo> pitti: is the other one in -updates now?
[09:05] <pitti> mvo: yes, I copied it this morning
[09:06] <mvo> excellent!
[09:06] <mvo> nothing pending currently
[09:06] <pitti> mvo: good; accepted then
[09:07] <kirkland> mvo: pitti: I have a debdiff coming shortly for update-notifier for Jaunty;  adds an update-motd hook such that update notifications are appended to the MOTD
[09:07] <NCommander> pitti, what is binary NEWed?
[09:09] <mvo> kirkland: nice, I will merge it when its ready
[09:11] <soren> Is anyone else unfortunate enough to have to deal with the wl wifi driver?
[09:12] <NCommander> soren, yes, I have
[09:12] <soren> I find there's a huuuuge difference between the latency of my network connections when I use that and when I use ndiswrapper (which used to be my only option).
[09:13] <NCommander> pitti, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/mtd-utils/+bug/294428
[09:13]  * soren runs a simple benchmark
[09:14] <soren> NCommander: Is it horribly laggy for you as well?
[09:19] <pitti> NCommander: a package which hasn't been built before must be checked by the archive admins, and is held in a queue for that before being published to the archive
[09:19] <NCommander> soren, my current machine doesn't have wl, but in my experience, yes
[09:20] <NCommander> pitti, ah, I see. I enabled proposed on my intrepid box, and checked it, so now what :-)?
[09:21] <pitti> NCommander: if it works, then it's good for copying to intrepid-updates, and closing the bug
[09:21] <geser> pitti: Hi. Please give-back vim on i386. Thanks.
[09:21] <NCommander> It works to the extent I can test it (I don't have anythign attached to this PC I can forgot jffs2, but the tools, and the help for the tools work)
[09:22] <soren> NCommander: http://people.ubuntu.com/~soren/wlstats.txt <---- No fun at all
[09:22] <pitti> geser: it's built already
[09:23] <geser> pitti: https://launchpad.net/ubuntu/jaunty/+source/vim/+builds shows a FTBFS for i386
[09:24] <pitti> geser: indeed, seems my script is broken
[09:25]  * pitti fixes it for s/intrepid/jaunty/
[09:25] <pitti> given back
[09:25]  * soren wonders why he didn't see the e-mail about that build failure... :/
[09:36] <wgrant> How does one get posting privileges revoked from -devel-discuss?
[09:37] <slangasek> mail -devel-discuss-owner, I guess?
[09:37] <cody-somerville> wgrant, is there a particular reason you ask? :P
[09:38] <wgrant> They're not doing a very good job of making developers want to read it.
[09:42] <ogra> that's why it's called -discuss :)
[09:42] <ogra> for actual development there is ubuntu-devel
[09:43] <wgrant> I mean, I thought I directed some serious torrents of hate at Launchpad, but that just doesn't compare...
[10:02] <Hobbsee> wgrant: hmm, I wonder who has powers over that list
[10:03] <Hobbsee> oh, wow.  It's getting even better.
[10:04] <NCommander> What list?
[10:04] <wgrant> -devel-discuss
[10:05] <Hobbsee> NCommander: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-November/006221.html and that general thread (and other useless wastes of bytes on that list)
[10:05] <Hobbsee> NCommander: oh, and those sorts of posts are normal for that guy, too.
[10:05] <NCommander> WTF is the difference between devel-discuss and -devel
[10:05] <wgrant> One has ******** on it.
[10:05] <Hobbsee> NCommander: devel == sane.  has developers on it, and is moderated so you don't get that kind of rubbish.
[10:05] <liw> NCommander, one is discussion about developement, one is discussion about discussion about development?
[10:06] <NCommander> Hobbsee, semi-moderated, developers are whitelisted
[10:06] <Hobbsee> NCommander: -devel-discuss: users speaking to developers...Or, now, as the case may be, lots of hate mail, which most people ignore, and occasional developer discussions, which a few people follow.
[10:06] <NCommander> who do I get in contact if I want a mailing list
[10:06] <Hobbsee> NCommander: well, yeah.  But the developers aren't expected to behave badly.
[10:06] <Hobbsee> NCommander: depends.  What for?
[10:06]  * NCommander would like an ubuntu-ports list <g>
[10:06] <Hobbsee> NCommander: do you want to use listadmin on it?
[10:06] <NCommander> listadmin?
[10:07]  * NCommander knows listsrv, but not listadmin
[10:07] <Hobbsee> NCommander: http://debaday.debian.net/2007/09/12/listadmin-command-line-mailman-moderator-queue-manipulation/
[10:07] <NCommander> Probably
[10:07]  * NCommander would whitelist developers of course
[10:07] <Hobbsee> NCommander: if you do, you can't use the launchpad lists, you'll need to get a list on lists.ubuntu.com (and I think you'll need to speak to jcastro about it)
[10:08] <NCommander> jcastro, ^
[10:08] <Heller_Barde> what program is this volume OSD of ubuntu part of?
[10:08] <liw> it's probably night for jcastro
[10:09] <wgrant> Heller_Barde: gnome-settings-daemon, I believe.
[10:09] <Heller_Barde> ah. and where can i find out how the shortcut is bound to it?
[10:10] <wgrant> Heller_Barde: What do you mean?
[10:10] <Heller_Barde> or does gnome-settings-daemon capture shortcuts itself?
[10:10] <wgrant> It does.
[10:10] <Heller_Barde> ah
[10:10] <Heller_Barde> i don't use gnome and actually dont want to but nothing else is able to look appropriately aesthetic :(
[10:11] <Heller_Barde> oh well
[10:12] <hyperair> bah the two-stage rsync mirroring script from ubuntu is useless on slow internet connections
[10:13] <hyperair> rsync the debs first, then the indexes. sounds like the perfect idea. but then it takes so goddamn long to rsync the debs that the indexes have updated by then =.=
[10:13] <wgrant> hyperair: You're not meant to mirror the archive on dialup.
[10:13] <hyperair> wgrant: i'm not on dialup damnit
[10:14] <hyperair> wgrant: this is a university connection
[10:18] <mvo> pitti: I looked into #220890 and AFAICT the remaining issue is that source code is not recognized as "offical" on powerpc but binary deb lines are. so it should be ok for -update (and I will push another one afterwards that fixes the source lines)
[10:31] <pitti> mvo: ok, thank you
[10:32] <sebner> pitti: is your list for coping stuff from -proposed to -updated already empty (for intrepid)?
[10:32] <pitti> sebner: yes; see http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[10:33] <sebner> pitti: intrepid has 2 packages with 7 days ;D
[10:33] <pitti> sebner: but not verified one
[10:33] <pitti> s
[10:34] <sebner> pitti: what has to happen to make it verified?
[10:34] <pitti> sebner: test that the package in -proposed still works as usual, and that it fixes the bug, and give written confirmation of that in the bug
[10:35] <sebner> pitti: my package (audacious) has over 5 users can confirm that the update in -proposed fixes the issue ;)
[10:35] <pitti> sebner: ah, then nobody from motu-sru set the verification-done tag apparently; please do so then
[10:37] <sebner> pitti: done
[10:37] <pitti> thanks
[10:37] <sebner> pitti: np, thank you your copying then :D
[10:40] <tkamppeter> pitti, hi
[10:41] <tkamppeter> what is missing to get the CUPS SRU released?
[10:41] <pitti> tkamppeter: testing and being 7 days in -proposed
[10:49] <tkamppeter> pitti, did not know that there is a "minimum 7 days" condition. All bugs related to pstopdf are answered and the answers suggest that the problems which I have addressed with pstopdf are really solved.
[10:49] <pitti> tkamppeter: right, except for the 'prints garbage on samsung' for splix
[10:49] <pitti> but we can keep that open and still move to -updates
[10:50]  * ogra grumbles at asac ... my mobile phone is suddenly not detected as USB HDD anymore ... grrr
[10:51]  * mvo thinks that asac probably sneaked int ogra house just to play that trick on him
[10:51]  * ogra tries to get the pictures off the camera with bluetooth instead
[10:52] <ogra> mvo, he doesnt go that far south for playing tricks i bet :)
[10:52] <liw> ogra, perhaps he has agents everywhere?
[10:52] <ogra> haha
[10:52] <liw> he is, after all, a manager ;)
[10:53] <mvo> ogra: you never know, he is on vac, maybe that is part of his vacationfun ;)
[10:53]  * mvo stops being silly
[10:53] <tkamppeter> pitti, and the AppArmor thingy with the network protocols I can confirm. The problem appears (I have 6 network printers) on the machine where I did not update to -proposed and does not appear with the -proposed package.
[10:54] <pitti> tkamppeter: can you please say so in the bug, for having a written track of testing?
[10:56] <tkamppeter> pitti, done.
[11:02] <tkamppeter> pitti, the garbarge printing which you observer with SpliX now is most probably a problem of SpliX itself. Therefore I need you to do tests with the LSB packages from OpenPrinting. The test on 2.0.0rc2 can reveal whether there is perhaps a bug in the Ubuntu packaging. The test of the 1.1.1 version can show whether the 2.x generation of SpliX introduced a new bug.
[11:02] <pitti> tkamppeter: ah, ok; I'll do that
[11:03] <tkamppeter> pitti, I have modified the OpenPrinting packaging last week so that these drivers can coexist with the ones coming from the distros.
[11:03] <tkamppeter> So you do not need to uninstall any package.
[11:20] <wgrant> mvo: Does do-release-upgrade do the xorg.conf inputdevice mangling too?
[11:21] <ogra> wgrant, what mangling ?
[11:22] <wgrant> ogra: We comment out inputdevices on upgrades to let input-hotplug work its magic.
[11:22] <ogra> xorg will ignore keyboard and mose settings from the file if not forced
[11:22] <wgrant> No it won't...
[11:22] <ogra> thats inside xorg afaik
[11:22] <wgrant> Really new xservers will ignore kbd and mouse entries, as evdev needs to grab them.
[11:23] <ogra> there was a setting i dont remember you have to add to the xorg.conf to make it use these entries
[11:23] <wgrant> AutoAddDevices, yes.
[11:23] <ogra> right
[11:23] <wgrant> But that's not what I'm talking about here.
[11:23] <ogra> else it will use evdev by default
[11:23] <ogra> and ignore the xorg.conf entries for keyboard and mouse
[11:24] <wgrant> I know, but this is somewhat separate.
[11:24] <ogra> for other input devices it depends on the driever ...
[11:25] <ogra> i.e. wacom will only use hal if yu copy the .fdi in place, else xorg.conf should be used
[11:25] <wgrant> And lots of them will break horribly, which is why we now comment them out on upgrades.
[11:25] <ogra> really?
[11:25]  * ogra wasnt aware we touch xorg.conf at all
[11:25] <wgrant> As of late Intrepid we do.
[11:26] <ogra> hmm
[11:31] <tkamppeter> pitti, I have investigated bug 293883 now and it is an evince bug, so it does not block the SRU release of CUPS. pstopdf was not the culprit there.
[11:38] <cjwatson> NCommander: we tried it before and it broke some people's hardware, so I'm not all that interested in trying it again TBH
[11:39] <NCommander> Works for me
[11:39]  * NCommander deletes the idea from his brain
[11:39] <mok0> rm -rf /sys/brain/idea
[11:39] <mvo> wgrant: yes
[11:39] <NCommander> mok0, file not found
[11:39] <wgrant> mvo: Hmm, OK, I have a report from somebody that it didn't.
[11:40] <mok0> hehe
[11:40] <wgrant> But perhaps not fully trustworthy.
[11:40] <mvo> wgrant: it writes out a log what its doing
[11:40] <mvo> wgrant: please ask the reporter about the stuff in /var/log/dist-uprade/*
[11:40] <mvo> wgrant: is there a LP bug for it?
[11:40] <wgrant> mvo: There isn't. I'll ask for logs.
[11:40] <mvo> thanks
[11:42] <hyperair> late intrepid touches xorg.conf?
[11:42] <wgrant> hyperair: Since late in the Intrepid release cycle, the dist-upgrader touches xorg.conf.
[11:42] <hyperair> oh
[11:42] <hyperair> what does it do
[11:43] <wgrant> Comments out inputdevices.
[12:00] <pitti> slangasek: I ported your hal patch 99_new-kernel-rfkill-interface.patch as best as I could to new hal upstream; but since I don't get any observable lshal change when flipping the killswitch either with your old nor with my ported patch, I can't really test it; can you?
[12:04] <slangasek> pitti: I guess that's for jaunty?  I'm afraid I can't test that very easily; but the main point would be whether NM detects the status change, I guess?
[12:05] <pitti> slangasek: yes, for jaunty
[12:05] <pitti> slangasek: well, NM doesn't do anything if I change the killswitch
[12:05] <slangasek> hmm
[12:05] <slangasek> not with either version?
[12:05] <pitti> but didn't do that in intrepid either
[12:05] <pitti> that's why I can't test the ported patch
[12:05] <slangasek> hrm
[12:05] <StevenK> slangasek: Bit early, isn't it?
[12:05] <slangasek> pitti: this is on a system with Intel wireless?
[12:05] <slangasek> StevenK: ?
[12:06] <StevenK> slangasek: It's 4am in LA
[12:06] <pitti> slangasek: yes, iwl3945 with dell killswitch
[12:06] <slangasek> pitti: do you have /sys/class/net/$dev/device/rfkill?
[12:06] <slangasek> StevenK: yep, right in the middle of my Monday shift
[12:07] <slangasek> pitti: (you're running the Intrepid kernel, right?)
[12:08] <pitti> slangasek: intrepid kernel> yes
[12:08] <pitti> slangasek: /sys/class/net/wlan0/device/rfkill/rfkill0/state
[12:09] <pitti> slangasek: I can put the new consolekit and hal into my intrepid PPA, if that would help you
[12:09] <slangasek> pitti: that would be better
[12:09] <slangasek> I'm still puzzled that it doesn't work for you, though
[12:09] <slangasek> for me, the nm-applet icon reflects the state change within a few seconds
[12:10] <pitti> well, the killswitch itself works
[12:10] <pitti> in the sense of that it blocks wifi
[12:10] <pitti> but NM doesn't react to that
[12:11] <slangasek> hmm
[12:11] <slangasek> then I guess my patch is screwed up somehow, even though IWFM :/
[12:11] <pitti> slangasek: someone else on the upstream bug confirmed that it works
[12:11] <pitti> seems hw specific
[12:11] <slangasek> yeah, I saw
[12:12] <slangasek> but I don't understand /why/ i would be hw-specific
[12:14] <pitti> slangasek: if you change the killswitch, do you see something in lshal flip state?
[12:21] <pitti> slangasek: both uploaded and building now
[12:23] <slangasek> pitti: lshal changes> no; though apparently if I'm lucky, I can hard-lock my laptop in the process
[12:24] <slangasek> pitti: but I guess calling 'hal-ystem-killswitch-get-power' directly should show the output?
[12:24] <slangasek> +s
[12:25] <pitti> w$ sudo ./hal-system-killswitch-get-power
[12:25] <pitti> .: 10: hal-functions: not found
[12:25] <pitti> bah
[12:25] <slangasek> doh
[12:25] <pitti> but it's there... ?!?
[12:33] <Nafallo> anyone know if we have support for Intel 4500MHD?
[12:33] <Treenaks> Nafallo: what is it?
[12:33] <Treenaks> Nafallo: a CPU?
[12:33] <Nafallo> Treenaks: some kind of new graphics thing.
[12:34] <Nafallo> I think :-P
[12:34] <Nafallo> Intel Graphics Media Accelerator 4500MHD DVMT (Dynamic Video Memory Technology)
[12:34] <Nafallo> yea. new GMA.
[13:00] <asac> ogra: so you want to use your phone as HDD and not 3G device ;)?
[13:01] <ogra> asac, well, it used to show up as HDD when i plugged it in with cable ...
[13:01] <ogra> but BT works fine for pulling off files
[13:02] <ogra> my phone has a 2G micro SD card i use as data storage from time to time
[13:02] <asac> ogra: when did USB stopp working?
[13:02] <ogra> no idea, i just pluged it in for the first time after an aeon
[13:02] <ogra> i dont think i even tried it in intrepid at all before
[13:03] <ogra> it used to show up as HDD in hardy iirc
[13:03] <asac> ogok
[13:03] <ogra> ogok ?
[13:03] <liw> I wouldn't mind using my phone as a storage device, too, in order to move files to the memory card
[13:03] <asac> ogra: do you have different modes?
[13:03] <asac> (on the phone)
[13:03] <ogra> its in usb storage mode by default ...
[13:04] <liw> (but I'm happy to shuffle the memory card around for now)
[13:04] <ogra> one sec, doorbell, brb
[13:04] <asac> ogra: maybe it was the airprime driver?
[13:05] <asac> (that one was dumbed in intrepid afaik)
[13:10] <mvo> cjwatson: do you happen to know if we use the wget udeb still these days? it got added by fabio in the feisty days and I was wondering if we should keep this change around or not
[13:15] <cjwatson> mvo: I think Fabio might have wanted it for system-integrity-check maybe? nothing in d-i itself uses it
[13:17] <mvo> cjwatson: yes, that looks right
[13:17] <mvo> thanks!
[13:17] <cjwatson> mvo: that said, I don't see anything in system-integrity-check that relies on it
[13:17] <cjwatson> oh, no, Depends: wget-udeb. WTF
[13:18] <cjwatson> fabbione: why was busybox's wget not good enough?
[13:18] <cjwatson> fabbione: it doesn't seem as if system-integrity-check uses any features not in busybox's wget
[13:31]  * NCommander laughs evilly
[13:32] <slangasek> jordi: yuck, why is there a lib64asound2-plugins?  Is there really a use case for 64-bit alsa support on 32-bit installs?
[13:32] <directhex> NCommander, evil laughter? that can only mean added mono! ;)
[13:33] <NCommander> slangasek, offhand, I'm going to guess for compiler biarch sanity
[13:33] <slangasek> huh?
[13:33]  * NCommander shakes head
[13:33] <NCommander> Wow, I'm loosing it
[13:33] <NCommander> just ignore me
[13:34] <NCommander> directhex, actually, debhelper 7 was backported (thank you slangasek)
[13:34] <NCommander> That unblocks at least 10, maybe more backports
[13:34] <directhex> NCommander, version?
[13:34] <NCommander> hardy-backports
[13:35] <directhex> i meant actual package ver
[13:37] <NCommander> directhex, the one from intrepid, 7.0.13ubuntu1
[13:40] <pitti> StevenK: what's the rationale for your pilot-link patch 30_3_arg_open.dpatch? no patch headers, no bug refs, no rationale in changelog :(
[13:41] <fabbione> cjwatson: at the time, it was not good for https. We started doing all the stuff to https and the whole thing was stalled on lack of time
[13:41] <cjwatson> oh, right
[13:41] <pitti> StevenK: oh, nevermind, got it
[13:42] <cjwatson> mvo: ^- above is still the case
[13:42] <fabbione> cjwatson: not sure if wget in busybox does https now.. nor if ubuntu cares about s-i-c. I gave it to the server team a while ago.. no idea if they have done anything about it
[13:43] <cjwatson> I don't think anyone cares very much about s-i-c any more, but wget doesn't do https and that seems like a valid use case
[13:43] <cjwatson> busybox wget that is
[13:44] <fabbione> cjwatson: ok. I personally don't think i care nor i have time to do s-i-c. Might worth discussing it again with the server team and free resources at the datacenter since there is a server side for it
[13:44] <pitti> StevenK: did you send it to an upstream ML? I don't find an upstream bug tracker
[13:44] <fabbione> cjwatson: the code is still in bzr somewhere public I believe. anyway the last releae in the archive had everything that was in bzr anyway
[13:52] <mvo> cjwatson, fabbione: right, thanks
[14:02] <fabbione> mvo: no worries :)
[14:04] <Keybuk> cjwatson: still trying to figure this udev bzr packaging case out
[14:04] <Keybuk> hit another problem; the udev git repository doesn't contain (as you'd expect) configure, Makefile.in, etc.
[14:04] <Keybuk> which means merging with "bzr pull" isn't going to produce something like the orig.tar.gz
[14:05] <Keybuk> the diff.gz will always end up with autoconf changes
[14:06] <Mithrandir> not if you nuke them in the clean target
[14:06] <Mithrandir> (and build-depend on auto*)
[14:08] <pitti> Keybuk: what's wrong with having autogenerated autofoo stuff in the diff.gz?
[14:08] <pitti> it might not be nice, but well, it's just noise
[14:09] <Keybuk> pitti: well, fwics, I have two options
[14:09] <Keybuk> clean bzr packaging, based off a git import, with merges and changes done with bzr nicely - but messy resultant traditional source package
[14:09] <Keybuk> or a clean source package, created by lots of by-hand heavy lifting with bzr/git
[14:10] <Keybuk> also wouldn't it break colin's "what you checkout from bzr must be buildable" requirement?
[14:11] <pitti> james_w: do you care about backuppc? You did the last merge, but it's currently on my plate since I did a last-minute dependency fix
[14:11] <pitti> Keybuk: can't speak for others, but for e. g. jockey I don't care about messy diff.gz if the ubuntu package is a direct branch of upstream trunk
[14:12] <james_w> pitti: I did the last merge as it was DIF and unmerged I believe.
[14:12] <james_w> pitti: I don't mind merging again if you want it off your plate
[14:12] <Keybuk> pitti: but then debcheckout doesn't give you anything buildable?
[14:12] <pitti> Keybuk: since you aren't going to use patch systems or MoM for those, messy diff doesn't really hurt IMHO
[14:12] <pitti> Keybuk: it should be buildable, of course
[14:12] <pitti> Keybuk: debian/rules could just call autogen.sh?
[14:12] <Keybuk> how do you make it buildable?
[14:12] <Keybuk> but then the package has to depend on auto*
[14:13] <pitti> lots of packages do
[14:13] <Keybuk> please nuke autogen.sh ;)
[14:13] <pitti> (yes, I repeatedly argued against it in the past, for packages which update autofoo on build)
[14:13] <cjwatson> Keybuk: james_w may have technology to generate the tarball branch (i.e. git + configure/etc.) automatically
[14:13] <pitti> Keybuk: or autoreconf -v, or whatever :)
[14:13] <james_w> lies!
[14:14] <cjwatson> autogen.sh> still useful when you're doing things that autoreconf doesn't do :P
[14:14] <pitti> james_w: ok, nevermind then; I just wondered if you were actually using it and could test it or so, but seems not :)
[14:14] <james_w> though it might be possible thinking about it
[14:15] <Keybuk> it'd have to be a Build-Depend-Indep on auto*, right?
[14:15] <cjwatson> james_w: the only hard bit is identifying the revision from which the tarball was produced; after that you just unpack and blat the changes into the archive
[14:15] <Keybuk> or is it only build-depends?
[14:15] <cjwatson> Build-Depends is stronger than Build-Depends-Indep in practice
[14:15] <cjwatson> policy is extremely confusing on this
[14:15] <Keybuk> yeah, I've never really understood it
[14:16] <Keybuk> at one point I thought -Indep was for "things needed to make the source package"
[14:16] <Keybuk> but it appears policy disagrees on that now
[14:16] <cjwatson> basically I only use Build-Depends-Indep if either (a) I have an explicit build-indep rule and the dependency is only used there and/or (b) it's only used in binary-indep
[14:16] <cjwatson> I don't think policy ever said anything like that
[14:16] <pitti> Keybuk: the way I understood it, you don't need -indep when building with -B
[14:16] <pitti> such as the !i386 buildds
[14:16] <NCommander> I was under the impression that Build-Dep-Indep is anything the independent build-deps needed explicately
[14:16] <Keybuk> cjwatson: it's entirely likely it didn't ;)
[14:16] <cjwatson> oh, it might have had confusing language about clean at some point
[14:16] <Keybuk> thought of the day: we should have an autoreconf meta package :p
[14:17]  * pitti generally just ignores B-D-I, too confusing to think about
[14:17] <cjwatson> yeah, that's usually the right answer
[14:18] <cjwatson> there are a small number of cases where it is important and/or useful
[14:18] <pitti> that the !i386 buildds use -B is really just an implementation detail packagers shouldn't really care about, FWIW
[14:18] <pitti> cjwatson: oh? so there's more to it than just buildds?
[14:19] <cjwatson> pitti: no, I didn't say that :)
[14:19] <cjwatson> pitti: I just meant that it is usually reasonable to default to sticking everything in B-D, and only think about B-D-I if you find you need to
[14:19] <pitti> ah, right
[14:20] <siretart> a common case is running doxygen to create an libfoo-doc package. doxygen can go to B-D-I then
[14:20] <ScottK> I'm looking at a package that has gone uninstallable in Jaunty because it believes it needs to depend on a non-existant package called glibc-private.  Rebuilding produces the same result.  Package builds and produces an installable binary on Intrepid.  Any suggestions about where to look?
[14:21] <pitti> ScottK: sounds like a bad .shlibs file?
[14:21] <siretart> ScottK: bad shlib.local file in the package?
[14:21] <pitti> ScottK: if local build does the same, grep /var/lib/dpkg/info/*.shlibs for glibc-private?
[14:21] <cjwatson> ScottK: that means that the package is relying on private glibc symbols and it shouldn't be
[14:21] <cjwatson> ScottK: it's basically glibc arranging for the package to blow up
[14:21] <pitti> oh, magic
[14:21] <siretart> sweet
[14:21] <ScottK> Argh.  OK.  Thanks for the hints.
[14:22] <ScottK> Yes.  Does the same thing on local builds, so I'll look.
[14:22] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462444
[14:22] <ScottK> Thanks.
[14:23] <cjwatson> I think you can pass -xglibc-private to dpkg-shlibdeps to skip it if you know what you're doing
[14:23] <cjwatson> but it's probably worth investigating first
[14:24] <ScottK> OK.  I'm definitely in an area where "know what I'm doing" doesn't apply.
[14:25] <ScottK> Which is, of course, half the fun.
[14:28] <Keybuk> cjwatson: did you autosync contrib or non-free?
[14:32]  * ogra wonders if MoM is broken
[14:32] <ogra> or probably she simply forgot i exist
[14:34] <pitti> ogra: curious
[14:34] <ogra> i only seem to have one package in universe
[14:34] <pitti> ogra: you've got stuff on http://merges.ubuntu.com/universe.html, thoug
[14:34] <mvo> ogra: generally it seems to be running quite happily
[14:35]  * mvo just checked the logs
[14:35] <ogra> which additionally is better off to be merged by LaserJock
[14:35] <cjwatson> Keybuk: not yet
[14:35] <cjwatson> Keybuk: doing so now
[14:36] <pwnguin> Hobbsee: looking at the record thus far, I don't think the recent post by Vincenzo is "normal" in tone or language. it also doesn't reflect my own interactions with him.
[14:40] <siretart> Mithrandir: did you have the chance yet to look into the pkg-config issue slomo and I asked you about?
[14:40] <Mithrandir> siretart: I didn't, no. :-/
[14:41] <pwnguin> It does reflect somewhat my own frustration with the status quo, but I'm not about to write angry letters over it
[14:41] <hyperair> what pkg-config issue?
[14:42] <Keybuk> ogra: ;)
[14:42] <ogra> :)
[14:42] <Keybuk> I suspect it's because you've got your "you touched it last" list down to almost zero
[14:43] <ogra> seems like
[14:43] <ogra> which is weird
[14:43] <siretart> hyperair: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504220
[14:43] <ogra> i thought i touched a good bunch
[14:43] <Keybuk> not really, you tend to touch things in universe more than main
[14:43] <ogra> but i'll pick up leftovers
[14:44] <Keybuk> and universe has a high "fix after freeze" ratio
[14:44] <hyperair> hm ubottu handles debian bugs too?
[14:44] <hyperair> i never knew
[14:44] <ogra> yeah, since i'm in mobile i touch a lot of universe
[14:46] <Mithrandir> siretart: you need to depend on the -dev packages.
[14:47] <siretart> Mithrandir: but isn't that insane? why do depending packages need to care about whether libavcodec-dev links against libtheora or not?
[14:48] <Mithrandir> siretart: if it is in "Requires.private", then it not only links with it, but also needs the headers from it.
[14:48] <Mithrandir> like gtk exposes glib types in its headers.
[14:48] <siretart> Mithrandir: libavcodec does not TTBOMK expose any libtheora internals
[14:48] <Mithrandir> if it just links with it without exposing any of libtheora's types, using libs.private should be fine.
[14:49] <siretart> okay. is there any documentation or any document I could point upstream at to get that fixed?
[14:49] <Mithrandir> once I get around to writing it. :-/
[14:49] <siretart> may I quote this irc conversation?
[14:53] <Mithrandir> sure.
[15:02] <tkamppeter> pitti, did you do the test for bug 292690, I have also added another possibility to test.
[15:08] <fta> dear archive admins, please, consider opening the ppa gates to jaunty.
[15:09] <cjwatson> is it our decision?
[15:09] <cjwatson> I thought that was an LP thing
[15:09] <fta> i asked there 1st => <cprov> fta: the decision belongs to the archive-admins at this point, so #ubuntu-devel might be a better place to discuss it.
[15:09] <cjwatson> cprov: do it
[15:09] <cjwatson> I don't think we have the lever; if we do then please tell me
[15:10] <cprov> cjwatson: okay, I will organise the opening
[15:10] <cjwatson> cprov: I can't think of any reason why we wouldn't want to open a distroseries for PPAs at the same time as we open it for regular uploads. Do you know why it is done separately?
[15:12] <cprov> cjwatson: those decisions are still orthogonal in the DB. We open a new distroseries by change its status from frozen to development
[15:12] <cprov> cjwatson: PPA archs are enabled per distroarchseries base.
[15:13] <cjwatson> cprov: OK, I'll edit our NewReleaseCycleProcess to say we need to notify you to enable PPAs
[15:14] <cprov> cjwatson: right, if you think it's appropriate, we could try to glue those decisions in a single form.
[15:14] <cprov> https://launchpad.net/ubuntu/jaunty/{i386, amd64, lpia}/+admin
[15:14] <cjwatson> cprov: I don't mind as long as it gets done; a note in NewReleaseCycleProcess should be good enough
[15:15] <cjwatson> cprov: yeah, I don't have access to that
[15:15] <cjwatson> see also: why can't distro drivers administer distroseries, eh?
[15:15] <cprov> cjwatson: me neither, I will ask kiko.
[15:16] <fta> cprov, cjwatson: wonderful, thanks guys :)
[15:21] <jordi> slangasek: I assumed it is as useful as lib64asound2
[15:25] <cprov> cjwatson: fta: jaunty PPAs are supported.
[15:26] <fta> great
[15:28] <cjwatson> thanks!
[15:29] <siretart> cprov: when exactly did you enable jaunty PPAs?
[15:30] <cprov> siretart: few minutes ago.
[15:30] <siretart> ah, ok. I tried this morning and got my upload rejected
[15:31] <hyperair> ...what happens when someone uploads a html file that redirects to a virus site to launchpad? =.=
[15:31] <hyperair> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695
[15:31] <hyperair> see the last comment
[15:35] <ScottK> hyperair: You should take that up in #launchpad.
[15:35] <hyperair> lol
[15:37] <tkamppeter> pitti, ping
[15:40] <ScottK> hyperair: Why is that funnny?  They're the only ones that can do anything about it.
[15:41] <hyperair> yesy es
[15:41] <hyperair> well, i'm the kind of person who laughs when yet another windows user gets struck by a virus
[15:41] <hyperair> i'm evil like that
[15:42] <hyperair> anyway i've alerted the guys at #launchpad
[15:47] <pitti> tkamppeter: hi
[15:48] <pitti> tkamppeter: btw, I can't configure the lsb splix2 packgage; s-c-p doesn't find it, and if I select the PPD manually, I just get an internal cups error
[15:48] <directhex> mono 2.0-1 very soon, apparently
[15:51] <pitti> tkamppeter: oh, nevermind, it didn't get configured (lsb dependency isn't installed)
[15:52] <pitti> tkamppeter: yep, works now
[16:07] <pitti> tkamppeter: new filter tested now, too
[16:21] <evand> Anyone have a 4GB USB disk, a recent Apple computer, and a free moment to test something for me?
[16:23] <liw> evand, I'm lacking all three, but just for clarification: do you need exactly 4 gigs or at least 4?
[16:23] <evand> at least
[16:24] <evand> (I have an image to dd to such a disk, so the other requirement would be a disk that you don't care about :)
[16:27] <pitti> pedro_, sbeattie: any chance to give gparted in hardy-proposed a test, for bug 37768? I was the uploader, so I need a second tester
[16:31] <mvo> kirkland: hello! how often is update-motd run ?
[16:31] <kirkland> mvo: every 10 minutes;  i'm putting a delayer in the script i'm working on to ensure that the update-notifier bit wouldn't run more frequently than once per hour
[16:32] <mvo> kirkland: the update-notifier bit is to pick up notification from user.d/ ?
[16:33] <kirkland> mvo: actually, i meant: /usr/lib/update-notifier/apt-check
[16:33] <kirkland> mvo: i propose something like this: http://pastebin.ubuntu.com/70058/
[16:33] <kirkland> mvo: call it "notify-updates-available"
[16:33] <mvo> kirkland: aha, ok - I'm adding support for new release upgrade notification into update-manager-core right now (just fyi) - and it should ideally be only once a day
[16:34] <kirkland> mvo: similar to "notify-reboot-required"
[16:34] <kirkland> mvo: cool, what i'd really like is just a number dumped into /var/run/updates-available
[16:35] <kirkland> mvo: also, i find it really, really odd that /usr/lib/update-notifier/apt-check puts the number of updates available on STDERR ... why's that?
[16:35] <mvo> kirkland: would it make sense to have a /etc/update-motd.d{.daily/,.hourly, etc} ?
[16:35] <kirkland> mvo: yes, i'm working on that, as update-motd's upstream
[16:35] <kirkland> mvo: i intend to do that very soon
[16:35] <mvo> kirkland: its a workaround because sometimes other stuff gets spit onto stdout
[16:35] <kirkland> mvo: oh
[16:36] <kirkland> mvo: it gave me a few fits :-)
[16:36] <kirkland> mvo: i got around it
[16:36] <mvo> kirkland: would it make sense to just modify apt-check so that it has a "--for-update-motd" (or something like that) so that it prints out exactly what you need?
[16:37] <mvo> kirkland: update-notifier has a lot of UI dependencies, so changes to update-notifier are required I assume?
[16:37] <kirkland> mvo: right, i'd need something in update-notifier-common
[16:37] <kirkland> mvo: can't really bring all those UI deps into ubuntu-server
[16:38] <kirkland> mvo: what cronjob currently drives apt-check?
[16:38] <mvo> kirkland: indeed :) so if we need to do that anyway, I wonder if we should have a apt-check that is tailored to the needs of update-motd in the sense that it outputs the right kind of message (with i18n and everything)
[16:39] <mvo> then all that is needed is that it installs a symlink to update-motd and is done with it
[16:39] <kirkland> mvo: okay, so i have throw one more wrinkle into the mix ...
[16:39] <mvo> kirkland: update-notifier itself drives apt-check, it has inotify rules to monitor apt/dpkg so that it known when it should (re)check for updates
[16:40] <kirkland> mvo: i think it's going to be landscape-sysinfo that's going to gather this info
[16:40] <mvo> kirkland: hm
[16:40] <kirkland> mvo: so landscape-sysinfo could even use a python library to grab this from apt-check
[16:41]  * mvo scratches his head and thinks about it a bit
[16:43] <sbeattie> pitti: I'll take a peek
[17:33] <ddfire> hi
[17:33] <ddfire> i need help making a deb package
[17:33] <ddfire> or backporting asterisk 1.4.21 from 8.10 to 8.04
[17:33] <ddfire> anyone have an idea?
[17:34] <ddfire> a pdf?
[17:34] <ddfire> a clue?
[17:34] <Nafallo> ddfire: wrong channel. try #ubuntu-motu.
[17:34] <ddfire> Nafallo: thanks
[17:36] <ddfire> Nafallo: what is the objetive of this channel?
[17:36] <Nafallo> ddfire: what the topic says ;-)
[17:38] <EtienneG> quick question ... will we get Mono 2.0 in Jaunty?  I suppose so, just wondering.
[17:44] <ddfire> ok
[17:44] <ddfire> thanks
[17:47] <maxb> The intrepid-backports devscripts has broken the "dch --distributor" option :-/
[17:48]  * maxb wanders in the direction of launchpad
[17:52] <pitti> mvo: is it really deliberate that apt-get build-dep installed packages get auto-removed?
[17:52] <pitti> it makes 'autoremove' pretty useless on a developer box
[17:57] <ScottK> Maybe we need apt-get autoremove-build-dep-yes-really
[17:59] <maxb> "apt-get build-dep" is an explicit user request to install packages, so shouldn't they count as manually installed?
[17:59] <cjwatson> I could go either way
[18:00] <cjwatson> often build-dep is only very temporary for me
[18:00] <cjwatson> install, build, remove
[18:00] <cjwatson> anyway:
[18:00] <cjwatson>   * make "apt-get build-dep" installed packages marked automatic
[18:00] <cjwatson>     by default. This can be changed by setting the value of
[18:00] <cjwatson>     APT::Get::Build-Dep-Automatic to false (thanks to Aaron
[18:00] <cjwatson>     Haviland, closes: #44874, LP: #248268)
[18:00] <cjwatson> so change that configuration option if you don't like it
[18:01] <ion_> Yeah, build-deps are typically temporary – if i want -dev packages that stay, i can make them manually installed.
[18:03] <pitti> cjwatson: ah, thanks; so feature, not bug
[18:06] <liw> I tend to find that apt's (or aptitude's) heuristics of autoremovable packages meshes badly with what I want to keep, but I am probably excentr^Wodd
[18:11] <ion_> liw: You might want to try debfoster. I use that (and apt-mark-sync to sync its decisions to apt and aptitude).
[18:20] <apachelogger> james_w: we are going to discuss bzr for KDE packages at the next Kubuntu meeting, please select agreeable time slots at http://doodle.com/participation.html?pollId=tvt9bb3fvtbqda8v
[18:26] <bryce> slangasek: hey, SRU question for you
[18:28] <bryce> slangasek: wacom tablets are fairly broken right now in Intrepid.  There is a newer version of the linuxwacom driver in Jaunty (0.8.1-6 vs 0.8.1-4) with necessary fixes.  Would a sync of something like that be conceivably within the realm of possibility?
[18:45] <jdong> bryce: since it's the same upstream version can't we just call it a "SRU"? :)
[18:46] <bryce> jdong: guess that's my question ;-)
[18:46] <pwnguin> bryce: isn't it really hard to test jaunty right now?
[18:46] <bryce> pwnguin: indeed.  In this case, the users self-compiled the driver and tested it on intrepid.
[18:46] <jdong> I mean if wacom is "fairly broken" IMO it wouldn't hurt to do some ~proposed testing. If you have big enough a base, put it into a PPA I guess
[18:46] <pwnguin> i mean, im all for better wacom; the status quo is terrible
[18:46] <jdong> s/base/bug subscriber base/
[18:47] <pwnguin> i hope i dont have a big ppa base
[18:48] <pwnguin> anyways, i dont have the right hardware to test
[18:48] <jdong> me neither.
[18:48] <jdong> christmas presents welcome ;-)
[18:48] <pwnguin> heh
[18:48] <bryce> well, I'm trying to determine how much time this is going to require.  If we can just sync it in, it should be a reasonable amount of time and I'll give it a shot.  If it's going to require patch cherry picking, ppa testing, and so on, I likely won't have sufficient time to see the whole thing through to completion, so ought to focus my efforts elsewhere.
[18:49] <jdong> bryce: well I assume the differences between debian revision 4 and 6 is just going to be a lot of debian/patches magic, right?
[18:50] <bryce> probaby
[18:50] <bryce> +l
[18:50] <jdong> I'd just package all of those patches into a SRU-like version number (i.e. -4ubuntu0.1) and consider that a SRU candidate, get a couple users to tell you it works okay, then you're done :)
[18:51] <jdong> (QA FOLKS PLEASE LOOK AWAY)
[18:51] <pwnguin> heh
[18:51] <pwnguin> what's the worst that can happen?
[18:51] <pwnguin> wacom remains broke?
[18:51] <jdong> pwnguin: from the way it sounds, it can't get any worse.
[18:51] <jdong> s/any/much/
[18:52] <pwnguin> i suppose it could crash X
[18:52] <jdong> I wouldn't expect that to happen with the kind of changes in a new debian revision though.
[18:52] <pwnguin> but the recovery tools are supposed to be bulletproof now ;)
[18:53] <jdong> I'd be a lot more scared if it were an entire new upstream release and a huge diff
[18:55] <mvo> pitti: it was a feature request to have it this way, -o apt::get::build-dep-automatic=false turns it off
[18:55]  * ScottK notices the upload of sane-backends and waits for insane-backends .
[18:55] <mvo> pitti: I don't mind either way, I can switch it to the reverse again
[18:56] <sebner> ScottK: I just subscriped MC, I'll recieve more and more questions so it's easier
[18:56] <pwnguin> bryce: fyi, wacom is apparently scheduling a new release next week ;)
[18:56] <ScottK> sebner: OK.  You know you didn't really answer all my questions in your reply.
[18:57] <sebner> ScottK: well, I didn't know. apachelogger told me. So maybe I'm missunderstanding you or my lack of english skills has the fault
[18:57] <bryce> pwnguin: nice... wonder if they'll include the changes needed for hal
[18:58] <pwnguin> i suspect not;
[18:58] <pwnguin> The new hotplugging (Xorg 1.5.1 or later) will be supported with linuxwacom version 0.8.4 (0.8.3 will be its unstable release).  It is too late to add the support to the coming stable release (0.8.2), which is scheduled to be posted this week.
[18:58] <pwnguin> ""
[18:58] <ScottK> sebner: I'll write a new mail.
[18:58]  * ScottK waits for jdong to package insane-backends
[18:59] <sebner> ScottK: yeah! yet another mail. keep going. I have a bet running that I'll recieve more than 10 questions :D
[19:00] <ScottK> sebner: Sent.
[19:02] <sebner> ScottK: now I'm subscriped, Does also my pending question (for dholbach) get's posted?
[19:03] <ScottK> sebner: You mean you sent a reply to dholbach?  If so, I haven't seen it.
[19:03] <sebner> ScottK: besides .. would you mind explaining your question question  ^ ^  I don't know what you want. A specific example?
[19:03] <sebner> ScottK: well, I wasn't subscriped so it was pending
[19:04] <sebner> or still is
[19:04] <ScottK> Yes.  An example of one you wish you had asked for and didn't and one you wish you hadn't asked for and why, what you learned, etc.
[19:06] <sebner> ScottK: I made mistakes (like syncs that were merges) but I don't have regrets about any sync that filed
[19:06] <sebner> + I
[19:06] <ScottK> sebner: Then comment on that to the ML.
[19:07] <sebner> ScottK: ah, ok (though it seems that is not the answer you wanted to hear) :)
[19:10] <sebner> ScottK: ah ah ah. I lost your mail xD would you mind resending it to me?
[19:16] <geser> sebner: I've just moderated your mail to motu-council
[19:17] <sebner> geser: thx, I'm now subscriped. sry for the trouble
[19:19] <sebner> geser: but please don't vote yet. still more questions are in the pipelie ;D
[19:19] <sebner> *pipeline
[19:22] <james_w> apachelogger: done, thanks. Unfortunately I can't commit to any times this week, but I will do my best to attend if one of those times is picked
[19:32] <apachelogger> james_w: looks like it's gonna be sunday since you have time and we have a quorum for the membership application :)
[19:32] <james_w> I have time, but I may be asleep :-)
[19:36] <ScottK> james_w: As long as you're awake enough to simulate agreement to do stuff, I think it'll be fine.
[19:37] <ScottK> Better you're not awake enough to really process it anyway.
[19:38] <james_w> heh :-)
[19:39] <ScottK> apachelogger: He thinks I'm kidding.
[19:50] <superm1> kees, ping
[19:51] <apachelogger> james_w: no one really is awake at kubuntu meetings, at least I am not, I usually just drop off some lines and continue dozing ;-)
[20:01] <kees> superm1: pong
[20:01] <superm1> kees, i'm thinking something in default build flags decided to wreck some havock
[20:01] <superm1> kees, would you mind taking a look, i think you saw this before: bug 296453
[20:01]  * kees goes to read
[20:02] <kees> heheh, that's a great build log
[20:03] <kees> superm1: I thought cvs was fixed for hardening weirdness.  I will poke at it.
[20:04] <superm1> thanks
[20:36] <kees> superm1: I can't reproduce the cvs crashes...
[20:47] <slangasek> jordi: right, so how useful is /that/? :)
[20:49] <slangasek> bryce: wacom tablets are broken in intrepid aside from the known, release-noted fdi issue?
[20:49] <superm1> kees, i'm assuming on jaunty up to date chroot?
[20:50] <superm1> i've got a local sbuild lvm snapshot that is fully updated with no delta otherwise ( both i386 and amd64) that reproduce it
[20:51] <kees> superm1: might be a bit out of date, let me try it again, on sec
[21:03] <cyberix> In some previous version of Ubuntu I double clickked on a gnumeric file and it suggested I should install gnumeric.
[21:03] <cyberix> Why doesn't this work anymore?
[21:18] <kees> superm1: here's the note I removed about cvs: https://wiki.ubuntu.com/CompilerFlags?action=diff&rev2=27&rev1=26
[21:19] <kees> superm1: I still can't reproduce on either amd64 or i386, updated jaunty chroots
[21:19] <superm1> kees, how weird that you can't reproduce.  i can in sbuild, pbuilder, and on buildd's
[21:19] <bryce> slangasek: yeah, additional bugs
[21:20] <superm1> kees, so try to rebuild cvs with that env variable and see if things improve then?
[21:20] <kees> superm1: are there any minimal commands that fail for you?
[21:20] <slangasek> bryce: what bugs are those?
[21:21] <kees> superm1: yeah, that'll certainly force those checks off in cvs, but I'd like to have a better idea of what's going wrong.
[21:21] <superm1> kees, the most minimal command that fails is "cvs status"
[21:22] <kees> .... uhm
[21:22] <kees> it's failing for me now.
[21:22] <kees> wtf.
[21:23] <NCommander> hey superm1
[21:23] <superm1> hi NCommander
[21:23] <NCommander> superm1, how goes it?
[21:23] <superm1> NCommander, busy as usual :)
[21:23] <bryce> slangasek: like #291908, hangs device when any pressure is on it
[21:24] <NCommander> superm1, busy with what specifically; anything I can do to hep?
[21:25] <superm1> NCommander, with work related things, so not really so much.  but if you are looking for bugs to fix on stuff, i've got plenty i can point you at :)
[21:25] <NCommander> heh, ScottK just got me on one :-)
[21:27] <kees> superm1: ah-ha, cvs 1:1.12.13-11 happened on Jan 27, 2008.  Hardening was enabled on Jun 08, 2008.
[21:27] <bryce> slangasek: basically my question is whether a sync of the driver is feasible, or if the individual fix needs to be identified and SRU'd by itself
[21:27] <kees> superm1: so, this is a problem now (I have no idea how it was ever noticed during intrepid... weird)
[21:28] <superm1> kees, ah so it never got rebuilt for hardening.  the fact that we synced is why it happens now
[21:28] <kees> superm1: right.  I'm curious how the problem in the wiki was ever noted, but when I tested it had "gone away" since it wasn't rebuilt yet.  wheee
[21:28] <superm1> kees, well at least i'm catching this early You've got eon's to ponder on it now. :)
[21:29]  * kees wonders why it doesn't freak out in fedora...
[21:45] <jackrabbit> I'm having a problem running autogen.sh on a svn build of network-manager-applet since upgrading to 8.10
[21:45] <jackrabbit> the error I get is: libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
[21:46] <jackrabbit> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
[21:46] <jackrabbit> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
[21:46] <jackrabbit> does anybody know what's causing this?
[21:48] <cjwatson> jackrabbit: surely that is a warning, not an error; if you aren't the developer you can ignore it
[21:48] <jackrabbit> well, it started after I upgraded and then I got some other errors as well
[21:48] <cjwatson> then you should investigate the things that are actually errors
[21:48] <jackrabbit> and . . . I ma developing
[21:48] <jackrabbit> :)
[21:49] <cjwatson> the output you quote from libtoolize is clear instructions to developers on changes in libtool macro handling
[21:49] <jackrabbit> which I believe are responsibles for the errors later on
[21:49] <cjwatson> but, as you can tell from the language used ("Consider ..."), they don't need to be fixed immediately
[21:50] <cjwatson> jackrabbit: it seems unlikely, but it is impossible to tell without knowing what those errors are
[21:50] <jackrabbit> cc1: warnings being treated as errors
[21:50] <jackrabbit> utils.c: In function ‘utils_fill_connection_certs’:
[21:50] <jackrabbit> utils.c:231: error: implicit declaration of function ‘nm_setting_802_1x_set_ca_cert_from_file’
[21:50] <jackrabbit> utils.c:235: error: implicit declaration of function ‘nm_setting_802_1x_set_client_cert_from_file’
[21:51] <cjwatson> totally and utterly unconnected to the libtoolize output
[21:51] <cjwatson> what is the svn url?
[21:51] <jackrabbit> I think they're caused by the abcense of header files
[21:51] <cjwatson> what would libtoolize have to do with header files?
[21:51] <cjwatson> (it operates on objects and has nothing to do with headers)
[21:51] <jackrabbit> svn://svn.gnome.org/svn/network-manager-applet/trunk
[21:52] <jackrabbit> cjwatson: I'm not that familiar with libtool/autotools etc
[21:56] <cjwatson> jackrabbit: the network-manager-applet version you're compiling requires a newer NetworkManager than what's packaged in Ubuntu 8.10
[21:57] <cjwatson> jackrabbit: the nm_setting_802_1x_set_ca_cert_from_file and nm_setting_802_1x_set_client_cert_from_file functions were added in revision 4239 of NetworkManager, which was committed on the day 8.10 was released
[21:57] <jackrabbit> that's svn too
[21:57] <jackrabbit> ok, I'll re-install and see if that helps
[21:58] <cjwatson> that suggests that you are not successfully using the headers from the NetworkManager you built, but are instead using the system headers, then
[21:59] <jackrabbit> cjwatson: mind if I ask how you figured that out?
[21:59] <cjwatson> how I figured which bit out?
[22:00] <jackrabbit> that the symbols were from a newer version than 8.10
[22:00] <cjwatson> jackrabbit: I checked out NetworkManager, grepped for that function, used 'svn blame' to find out when the lines in the header file in question were last changed, and used 'svn diff' to confirm that the revision in question was the one that initially introduced those symbols
[22:01] <cjwatson> and then 'svn log' told me the commit date which was later than the time 8.10 was released so I didn't need to look any further than that
[22:02] <jackrabbit> ok
[22:02] <jackrabbit> thanks, now I'll be able to check that out next time :)
[22:08] <directhex> hm, /me spots a minor bug
[22:08] <directhex> looks like a gtk label doesn't have pango markup enabled on it
[22:44] <kees> holy cow.  cvs implements its own kind of asprintf.
[22:44] <kees> and manually constructs %n-using vsprintfs
[23:07] <kees> superm1: well that was fun to track down.  I've uploaded a fixed cvs now.
[23:09] <NCommander> hey kees
[23:09] <kees> hola NCommander
[23:09] <NCommander> So here's my research
[23:09] <NCommander> If you have a prebuilt PIE GCC and glibc, you can install it into an existing system
[23:10] <NCommander> But I need doko's help to actually get a usable patch, mine breaks the C++ compiler from compiling :-/
[23:10] <kees> why do gcc and glibc need to be PIE before I can built other PIE stuff?
[23:10] <kees> er, can build
[23:10] <NCommander> no, if you want glibc/gcc to be pie
[23:10] <NCommander> :-)
[23:10] <NCommander> You can have PIE binaries without them
[23:11] <kees> I'm happy to move one step at a time
[23:11] <NCommander> kees, if your going to be at UDS, we could work on this there (aka, get the spec fully hammered out and such)
[23:11]  * kees nods
[23:11] <kees> yup, I'll be there.  :)
[23:12] <NCommander> That way, we can also pin doko and extract the secrets of GCC from his brain
[23:14] <elmo> woo, security vs. toolchain!
[23:14] <elmo> it wouldn't be a UDS without it!
[23:14] <kees> :)
[23:15] <elmo> \o/
[23:15] <wgrant> Toolchain always wins.
[23:15] <elmo> wgrant: this time, kees brought reinforcements
[23:15] <elmo> TAG TEAM CAGE MATCH
[23:15] <kees> though, I think I still lost since I ended up joining the toolchain group.  :P
[23:16] <NCommander> We should have a four way fight, toolchain v. server v. kernel v. security!
[23:16]  * NCommander runs
[23:16] <wgrant> elmo: But now you've warned doko of the evil reinforcement plan.
[23:16] <NCommander> elmo, got a moment?
[23:17] <wgrant> Do the archive admins know that Jaunty PPAs are waiting on them now, or are we in a deadlock like we were with Intrepid translations?
[23:17] <elmo> NCommander: not really, but what's up?
[23:18] <NCommander> elmo, its yet another PPA question. I have a pending request to see if the kernel team can get a non-virtualized PPA for the linux-ports kernel. Obviously building the -ports kernel on x86/amd64 is of *ahem* limited value :-)
[23:18] <NCommander> er
[23:19] <NCommander> THat wasn't meant to be a PM
[23:19] <NCommander> https://answers.edge.launchpad.net/soyuz/+question/48531 - the distro team asked me to bring to the PPA admins
[23:19] <wgrant> NCommander: You mean the other way around?
[23:20] <NCommander> wgrant, what the otherway around?
[23:20] <wgrant> The PPA people seem to be asking you to ask the distro team, not vice-versa.
[23:20] <NCommander> the distro team sent me back :-P
[23:20] <wgrant> Ah.
[23:20] <NCommander> EINFINITELOOP
[23:24] <elmo> well
[23:25] <NCommander> Ports is somewhat unique, since even just finding some of the hardware *cough*hppa*/cough* is a down right pain
[23:50] <kees> ogra: can you handle the moodle merge? the security fixes I added are all in the Debian package now.
[23:59] <DoYouKnow> how do I get the latest development kernel on ubuntu?


[11:10] <smartboyhw> Is balloons here?
[11:15] <smartboyhw> balloons, you there?????
[11:23] <smartboyhw> Show up, balloons.....
[11:23] <smartboyhw> ****
[11:23] <smartboyhw> * smartboyhw waves
[11:28] <smartboyhw> Balloons, show up....
[11:34] <smartboyhw> Balloons, get up!!!!!
[12:13] <astraljava> Erhm... he's on vacation, so most likely won't pay much attention.
[12:28] <smartboyhw> What? Balloons on vacation?
[12:28] <smartboyhw> BTW, astrajava, I think you will be chair on 29th August...
[12:28] <smartboyhw> I and balloons discussed it yesterday...
[12:46] <astraljava> Ok, I'll mark it on the calendar, but depending on the job schedule, I may have to re-arrange it.