[12:16] <Keybuk> yes, you do love a good spanking
[12:16] <dieman> screen #0:
[12:16] <dieman>   dimensions:    2400x1920 pixels (655x530 millimeters)
[12:16] <dieman> mmmmm
[12:17] <_ion> Ooooo
[12:17] <dieman> 2 24in screens rotated, and gnome isn't horking on the xinerama hints from nvidia, which is an improvement from hoary
[12:17] <dieman> to dapper
[12:17] <dieman> well, it was probally metacity
[12:19] <HiddenWolf> dieman: man, you've got two?
[12:19] <HiddenWolf> dieman: I have one of those, and I already lose my mouse pointer when I'm tired...
[12:21] <dieman> heh
[12:21] <dieman> yeah
[12:21] <dieman> upgraded from a single core 3.4 to a dual 3.2
[12:21] <dieman> too
[12:21] <dieman> which is obscenely fast
[12:21] <dieman> i couldn't believe how fast gnome loaded
[12:22] <HiddenWolf> heh, I wait for the core2. :)
[12:22] <dieman> yeah
[12:22] <dieman> i actually agree with you on that, but we just do planned upgrades of labs
[12:22] <dieman> so its whatever the labs are getting
[12:24] <Keybuk> dieman: how long does it take to compile OpenOffice?
[12:24] <dieman> thats a good question
[12:24] <Keybuk> if it's < 5 hours, tell doko; he goes a wonderful shade of green
[12:24] <dieman> its 'only' got 2gb of memory
[12:24] <dieman> if it had like 8
[12:24] <dieman> then i bet it would do openoffice quite quickly
[12:25] <dieman> does OO.o build parallelise at all?
[12:25] <dieman> i thought they used their own build tool
[12:25] <Keybuk> yeah, it does
[12:25] <dieman> awesome
[12:25] <dieman> i did it once on a previous machine
[12:25] <dieman> it was like 12 hours
[12:25] <dieman> i think that was only a 2.8 though
[12:25] <Keybuk> this did it in just over 2 hours, which I was quite pleased with
[12:25] <dieman> nice
[12:25] <dieman> what is it?
[12:25] <Keybuk> a reasonably high-spec X2
[12:25] <dieman> ahh
[12:25] <dieman> nice
[12:26] <dieman> we've got boxes with dual opteron dual core procs
[12:26] <dieman> that could probally do it in some obscene amount of time
[12:26] <dieman> with 4gb of memory
[12:26] <Keybuk> the memory helps a lot
[12:26] <dieman> yah
[12:26] <Keybuk> dual core vs. dual proc actually appears a benefit for large compiles too
[12:26] <dieman> ive got a box with 32gb of memory
[12:26] <dieman> and 8 procs
[12:26] <dieman> but its not up right now
[12:26] <dieman> but its older opteron procs
[12:27] <dieman> still, you can do it in memory then
[12:27] <dieman> the wikipedia db in mysql in ram works quite well
[12:28] <HiddenWolf> haha, yeah, that's a league of it's own
[12:29] <Keybuk> hmm
[12:34] <doko> Keybuk: you must be color-blind ;-P
[12:38] <BenC> so does libc6-i386 supercede ia32-libs on amd64?
[12:39] <Keybuk> doko: green with envy
[12:39] <Keybuk> it's a UKish thing I guess
[12:39] <LaserJock> it's not "green with envy" other places?
[12:40] <doko> BenC: ia32-libs does have some extra libs, but if you only need glibc, yes
[12:40] <BenC> ia32-libs is uninstallable for me on amd64 right now, so I hope it's ok :)
[01:06] <Keybuk> mdz: re teardown
[01:06] <Keybuk> I did it all in the BOF where we discussed it
[01:06] <Keybuk> I only have to type dupload *.changes <g>
[01:06] <mdz> well ok then
[01:06] <mdz> fire away
[01:07] <Keybuk> getting mom fed with sufficient kittens first
[01:09] <Keybuk> (and should merge those first, in reality)
[01:12] <jvw> Keybuk: did I understand correctly you're already bcc'ing some launchpad/ubuntu mails to the PTS's 'derivates' interface?
[01:13] <Keybuk> yes
[01:14] <Keybuk> the changes files of ubuntu uploads, iirc
[01:14] <jvw> ah, then I must be looking at the wrong bit of the PTS 
[01:14] <Keybuk> under the "derivatives" keyword, apparently
[01:15] <jvw> yeah, but logging of the PTS isn't sorted by keyword, but by incoming interface :)
[01:15] <Keybuk> http://wiki.debian.org/qa.debian.org/Reports/Draft
[01:19] <jvw> hm, did you encounter any succesful instance of a message thusly relayed via the PTS? I might really be blind, but I can't find any instance
[01:19] <Keybuk> I haven't actually, honestly, asked yet
[01:20] <Keybuk> at some point I'll track down a Debian guy and get them to try it out :)
[01:20] <jvw> well, I'm one of the PTS maintainers :)
[01:20] <jvw> and I really do appreciate your efforts on this and like to assist getting it to work :)
[01:20] <Keybuk> LP is definitely trying to send them, whether or not they're getting anywhere is another matter though
[01:20] <Keybuk> they'll be coming from drescher.ubuntu.com
[01:21] <zul> hey
[01:21] <jvw> it does like like they're not reaching the PTS -- unfortunately I don't have access to the actual mail logs, but I do have access to the mbox getting a copy of all incoming PTS mail
[01:21] <Keybuk> I don't have the mail logs either
[01:21] <Keybuk> yay paranoid sysadmins <g>
[01:21] <Keybuk> want me to try sending one?
[01:21] <HrdwrBoB> paranoia is one of the staple food groups
[01:21] <jvw> heh, partially same sysadmins as Debian :)
[01:21] <jvw> sure, go ahead
[01:22] <Keybuk> pick a source package
[01:22] <jvw> any you like and have a patch for
[01:23] <Keybuk> ok
[01:23] <Keybuk> should be a mail on its way to dpkg_derivatives@packages.qa.debian.org
[01:29] <jvw> got like 50 spams in the meanwhile, but not your mail yet -- sent a mail myself there, maybe master is just slow (high load, and deals with tons of mail)
[01:31] <jvw> anyway, before I asked, I grepped the incoming mail for 'derivatives', and didn't find anything except you mentioning it in some bug that also got via the PTS
 2006-06-28 00:24:09 1FvMu9-000744-P2 => dpkg_derivatives@packages.qa.debian.org R=lookuphost T=remote_smtp H=master.debian.org [70.103.162.30] 
 2006-06-28 00:24:09 1FvMu9-000744-P2 Completed
[01:32] <jvw> ok, so it's on debian's side
[01:33] <Keybuk> yeah, it looks like it's going out of our smarthost (adelie.ubuntu.com)
[01:33] <Keybuk> and master accepted it
[01:33] <jvw> packages.qa.d.o's mail is getting processed slowly to not blow up master, so I'll wait a bit and see whether this mail did arrive
[01:34] <Keybuk> I could also believe that the changes mailer isn't processing Bcc
[01:34] <Keybuk> I got lost when the twisty evil code reached zope
[01:34] <Keybuk> (that mail I sent by hand on the command-line, just to be sure)
[01:41] <bddebian> Howdy folks
[01:42] <LaserJock> hiya bddebian 
[01:45] <jvw> From lp_archive@drescher.ubuntu.com Tue Jun 27 18:44:37 2006
[01:46] <Keybuk> ok, so that one got through
[01:46] <Keybuk> did it go to the right place?
[01:46] <jvw> cool, so this worked -- and through grepping I verified I really only found this one, and no previous mail of this kind
[01:47] <jvw> well, didn't check yet, but if it didn't, I can fix it
[01:47] <Keybuk> right
[01:47] <Keybuk> so there's definitely an e-mail channel
[01:47] <jvw> fwiw, having some introductionary paragraph stating what this diff is about would be cool -- but a cosmetic thingy, getting it to work is more interesting :)
[01:48] <jvw> ew, debian-dpkg@l.d.o is subscribed to that one, oh well
[01:48] <jvw> (so yes, it worked)
[01:48] <Keybuk> right
[01:48] <Keybuk> so LP is clearly not sending them out -- but that's ok, because they're going to get sent from the mom/patches system soon anyway
[01:49] <Keybuk> cause that can produce better mails
[01:50] <jvw> For most people, having just a notification there was an ubuntu-upload in the first place is 90% of the interesting information already, and would be good to have at some point
[01:50] <Keybuk> I'll tickle the soyuz guys when they get up to work out why those aren't getting out though
[01:50] <Keybuk> right, that was the theory behind sending our changes announcements -- it was a good first step
[01:50] <jvw> yup
[01:50] <jvw> the mail you sent was a diff instead
[01:51] <Keybuk> right, that's because I sent it with the stuff I had in front of me -- which is the stuff that will actually be able to send ubuntu3 -> ubuntu4 diffs and attach them to the bottom of the changes mail
[01:51] <Keybuk> and that file was right in front of me :)
[01:52] <jvw> :) -- ok, so the PTS side of things seems to work, good to know that -- feel free to ping me or buxy whenever you're ready on the ubuntu side of things
[01:53] <Keybuk> will do
[01:53] <Keybuk> btw, https://patches.ubuntu.com/
[01:53] <Keybuk> is almost, but not quite, ready now
[01:54] <jvw> woah, with spiff site layout this time :)
[01:54] <jvw> https://patches.ubuntu.com/3/3ddesktop/ -> apache.conf, IndexOptions namelength=*
[01:54] <Keybuk> fsvo "spiff" ... HTML is not my forte
[01:55] <jvw> for values of 'spiff' equalling "not the apache default index page'
[01:55] <Keybuk> yeah
[01:55] <Keybuk> I've an outstanding admin request for that
[01:56] <jvw> anyway, the PTS already uses that new URL, thanks to buxy, I'm not sure yet where else in debian's QA to present that info to maintainers
[02:33] <Keybuk> oh, man
[02:33] <Keybuk> so distracted by shiny thing in NEW
[02:34] <zul> what shiny thing?
[02:34] <Keybuk> libtelepathy
[02:34] <Keybuk> it's a shame I have to REJECT it :'(
[02:34] <zul> heh
[02:35] <Keybuk> *cries*
[02:44] <LaserJock> Keybuk: you mean shininess alone doesn't get a package into the archives? ;-)
[02:46] <bddebian> heh
[02:48] <Keybuk> LaserJock: it can do, providing the packager bothers to read the COPYING file and put the right damned licence in debian/copyright
[02:48] <Keybuk> which dholbach failed to do :-/
[02:48] <bddebian> Doh
[02:49] <LaserJock> ouch
[02:59] <Lathiat> Riddell: why is kdebase going to depend on the libdnssd stuff?
[07:40] <pitti> Good morning
[07:43] <Hobbsee> hi pitti 
[07:43] <pitti> Hi Hobbsee 
[07:55] <fabbione> morning
[07:55] <Hobbsee> hi fabbione :)
[07:55] <fabbione> hey Hobbsee 
[07:57] <jsgotangco> morning pitti, fabbione
[07:57] <Hobbsee> hi jsgotangco 
[07:58] <jsgotangco> hi!
[09:28] <crimsun> For MoM -- if Ubuntu changes can be dropped, I presume we follow the same protocol for requesting syncs?
[09:29] <Mithrandir> crimsun: yes, if the ubuntu changes can be dropped, you request a sync.
[09:29] <crimsun> Mithrandir: nifty, thanks
[09:37] <fabbione> pitti: since you are into dovecot
[09:38] <fabbione> pitti: want to take care of bug #51038 ?
[09:38] <Ubugtu> Malone bug 51038 in dovecot "sub-folders disappear on upgrade from breezy to dapper" [High,Confirmed]  http://launchpad.net/bugs/51038
[09:39] <pitti> fabbione: meh, the 'touched it last' assignment method :)
[09:39] <pitti> sounds pretty upstream'ish, but I can forward it upstream 
[09:39] <fabbione> pitti: no, i assigned it to me, but it seems you have been playing with dovecot quite a lot
[09:40] <fabbione> so i rather prefer somebody that already know the code to touch it
[09:40] <pitti> I use it on my server, right
[09:40] <fabbione> so do i
[09:40] <pitti> I don't know the code, though
[09:40] <fabbione> but i am still at breezy
[09:40] <pitti> my server is sarge :)
[09:40] <fabbione> i so much had no time to upgrade my main server
[09:41] <pitti> fabbione: oh, elmo's reply explains a lot
[09:41] <fabbione> pitti: well it's simple..
[09:41] <fabbione> breezy Maildir uses .subscription
[09:42] <fabbione> dapper uses subscription
[09:42] <fabbione> for no reason
[09:42] <pitti> that sounds easily fixable at least
[09:42] <fabbione> so we need to fix dapper in such a way that upgrade from breezy and new install from dapper will work
[09:42] <pitti> looking at both sounds right
[09:42] <fabbione> yes, but we need to consider some upgrade paths
[09:42] <fabbione> the dovecot you uploaded in edgy.. what does it use?
[09:43] <fabbione> is that .subscription change still upstream or was it a bad release?
[09:43] <fabbione> somehow we need to converge with upstream on that
[09:43] <pitti> hm, grab-merge.sh already wiped the source, so I'll wait until it's in the archive
[09:44] <pitti> but since we do not have any patches wrt that, it's an upstream change
[09:47] <fabbione> pitti: yeps thanks
[09:55] <pitti> meh, why does my X crash when I try to load http://people.ubuntu.com/~mdz/anastacia.txt in firefox???
[09:57] <mdke> I've heard some people have odd crashes from loading webpages using the nvidia driver
[09:57] <robitaille> pitti:  that text file has a very long line of text... after getting it with wget, vi also has problem reading it...
[09:58] <robitaille> oopps...forget the vi comment...user mistake :)
[09:58] <pitti> yeah, I noticed; all the kernel stuff from 2.6.17
[09:58] <Mithrandir> worksforme, amd64.
[09:58] <pitti> Mithrandir: in firefox? I'm on amd64+nvidia drivers
[09:59] <pitti> robitaille: but that wrapping you see in vim is normal
[09:59] <Mithrandir> pitti: yes, in firefox.  I kinda need to reboot to get -25 in, but otherwise up-to-date
[09:59] <robitaille> pitti:  I did a bad cut and paste...and did a vi on the http url :)
[09:59] <lifeless> does anyone know how to tell X that resolv.conf has changed ?
[10:00] <lifeless> I'm getting all X clients timeing out reading for the ICE auth socket
[10:01] <hunger> lifeless: a sighup might work... dunno.
[10:01] <lifeless> is it gnome-session that answers queries on it ?
[10:01] <hunger> lifeless: IIRC ICE is not gnome specific.
[10:01] <lifeless> sure, but that does not mean that gnome does not implement that component
[10:02] <hunger> lifeless: iceauth was written by the x consortium.
[10:03] <hunger> lifeless: So I guess gnome has nothing to do with it.
[10:04] <lifeless> hunger: I know that to. It still does not have the imllication you are assigning to it.
[10:04] <Mithrandir> pitti: reproduced with latest kernel.  Joy.
[10:04] <pitti> Mithrandir: nvidia? or other driver?
[10:05] <pitti> Mithrandir: bug 51180, in case you have any news (or want to confirm it)
[10:05] <Ubugtu> Malone bug 51180 in xorg "X crashes when viewing a file with long lines in firefox" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51180
[10:07] <Mithrandir> pitti: -23 works for me.
[10:07] <Mithrandir> pitti: and yes, nvidia driver.
[10:07] <Hobbsee> pitti: not sure if this helps, but i'm using the upstream firefox binaries, everything updated in dapper, and no nvidia driver, and it works here
[10:08] <ivoks> it didn't crash here
[10:08] <ivoks> nvidia + -25 (not amd64)
[10:09] <TheMuso> np here, i386, with -25 kernel, and xorg open ATI driver.
[10:09] <pitti> joy
[10:10] <pitti> ivoks, TheMuso, Hobbsee: can you please add your configurations to the bug, so that we can see a pattern?
[10:10] <TheMuso> Ok.
[10:10] <ivoks> of xorg?
[10:11] <pitti> ivoks: bug 51180
[10:11] <Ubugtu> Malone bug 51180 in xorg "X crashes when viewing a file with long lines in firefox" [Untriaged,Confirmed]  http://launchpad.net/bugs/51180
[10:12] <Hobbsee> added :)
[10:12] <Hobbsee> that /sysinfo script is sure useful.
[10:13] <ivoks> i forgot to mention that it doesn't crash :)
[10:13] <Hobbsee> haha
[10:13] <Hobbsee> great
[10:13] <TheMuso> ?
[10:13] <TheMuso> Hobbsee: sysinfo?
[10:13] <Hobbsee> Sysinfo for 'sarah': Linux 2.6.15-25-686 running KDE 3.5.3, CPU: Mobile Intel(R) Celeron(R) CPU 2.40GHz at 2394 MHz (4793 bogomips), HD: 14/36GB, RAM: 643/993MB, 97 proc's, 47.22min up
[10:14] <Hobbsee> TheMuso: ^ konversation script
[10:14] <TheMuso> oh ok
[10:18] <Kamion> hmm, anastacia output was wedgied
[10:18] <Kamion> have corrected that, hopefully
[10:18] <Kamion> helps if I read my drescher cronmail
[10:24] <Fujitsu> Guys, I've seen that bug before.
[10:24] <Fujitsu> It's around somewhere, let me find it.
[10:25] <Fujitsu> It was the Nvidia driver last time as well.
[10:25] <Kamion> somebody might like to take a copy of anastacia.txt if you need it to reproduce that bug#
[10:26] <Kamion> since that long line should disappear in about ten minutes
[10:26] <Fujitsu> There's an attached version, isn't there?
[10:26] <Kamion> yep
[10:26] <Hobbsee> yep
[10:26] <Kamion> ok, good
[10:26] <Fujitsu> Hmm.
[10:27] <Fujitsu> LP just went down for me.
[10:27] <Fujitsu> Everything else is fine.
[10:27] <TheMuso> Fine here.
[10:27] <pitti> Kamion: yes, I attacked it
[10:27] <pitti> Kamion: erm, attached
[10:27] <Fujitsu> Heheh.
[10:27] <Hobbsee> hehehe
[10:28] <Hobbsee> hehe, seems to be a lot of that going on lately.  should i scream at you next?
[10:28] <Hobbsee> s/scream/get mad
[10:29] <Fujitsu> Evening, Seveas.
[10:30] <Hobbsee> hi Seveas 
[10:31] <Seveas> mornin'
[10:34] <Fujitsu> I think I found the bug that's the same as this:
[10:34] <Fujitsu> 49407.
[10:34] <mvo> jdub: hi! for the popcon support (sort by popcon rating) in gnome-app-install we need more popcon data. do you think we could write something on the fridge to get more users to install it?
[10:35] <Mithrandir> mvo: most users have it installed, but not enabled.
[10:35] <Fujitsu> 46034 is also similar.
[10:35] <Mithrandir> mvo: it's part of *ubuntu-standard
[10:35] <Hobbsee> bug 49407
[10:35] <Ubugtu> Malone bug 49407 in xorg "Crashes Xorg server when visiting a launchpad.net page" [Untriaged,Needs info]  http://launchpad.net/bugs/49407
[10:35] <jsgotangco> its already installed isn't not?
[10:36] <Fujitsu> bug 46034
[10:36] <Ubugtu> Malone bug 46034 in nvidia-glx "Page crashes X" [High,Confirmed]  http://launchpad.net/bugs/46034
[10:36] <Fujitsu> They all involve CoC signatures (which are ultra-long lines), X crashes, and Nvidia drivers.
[10:37] <mvo> Mithrandir: even better, so we just need to advertise to enable it
[10:37] <Mithrandir> mvo: yup
[10:38] <mvo> Mithrandir: is it just a matter of dpkg-reconfigure popcon?
[10:39] <Kamion> popularity-contest, but yes
[10:39] <Mithrandir> mvo: yes.  And answering "yes" to enabling it, obviously.
[10:42] <Hobbsee> Fujitsu: i'd say there all the same bug, but someone like pitti should probably try the same files to check
[10:42] <Fujitsu> I would assume they were all identical.
[10:45] <Hobbsee> Fujitsu: i'm not an X person, but i'd probably mark them as a dupe of  bug 49407 - seems that there's a solution there too
[10:45] <Ubugtu> Malone bug 49407 in xorg "Crashes Xorg server when visiting a launchpad.net page" [Untriaged,Needs info]  http://launchpad.net/bugs/49407
[10:46] <Fujitsu> No.
[10:46] <Fujitsu> Mark as a dupe of 46034, as it's the earliest.
[10:47] <Fujitsu> I just tested the test's in some of the bugs with a friend. It crashes.
[10:48] <Fujitsu> *tests
[10:48] <Fujitsu> Where did that apostrophe come from...
[10:48] <Hobbsee> whichever - i'd mark it as a dupe of whichever had the fix or whichever was the most coherant, although they both seem to
[10:49] <Riddell> Lathiat: kdebase depends on libdnssd because it includes the code for avahi support (via our patch)
[11:38] <sivang> morning
[11:38] <pitti> hi sivang 
[11:39] <jsgotangco> sivang!
[11:39] <sivang> hey jsgotangco , what's up? :-)
[11:39] <jsgotangco> about to go home =)
[11:41] <sivang> jsgotangco: from work?
[11:41] <jsgotangco> yeah
[01:04] <Mez> infinity, ping
[01:04] <Mez> or mdz, ping
[01:07] <mvo> Kamion: could you please sync directfb from debian/unstable? overwrite is ok
[01:08] <heno> Kamion: is gfxboot generally 640x480? 
[01:08] <heno> Kamion: would the high viz menu have the standard boot prompt below it as well?
[01:08] <heno> (I'm working on the graphics for that)
[01:10] <Mithrandir> heno: 640x400, probably.
[01:11] <heno> Mithrandir: right. And should I make separate images for the highlighted menu items? (with a box around, say)
[01:12] <Mithrandir> heno: I don't think you need to, no.
[01:14] <heno> ok thanks. It will look something like: https://wiki.ubuntu.com/Accessibility/Specs/LiveCdAccess?action=AttachFile&do=get&target=NewBootMenu2.png
[01:15] <sivang> heno: Looks Kool
[01:17] <Kamion> mvo: please file a bug on directfb and subscribe ubuntu-archive
[01:17] <Kamion> heno: currently 640x480 but it will change to 640x400, as Mithrandir says
[01:17] <Kamion> heno: dunno about the high viz menu yet
[01:18] <mvo> Kamion: I did that yesterday, sorry for pushing, but the new cairo/gtk depends on it
[01:18] <Kamion> ok, I'll do a sync run now then
[01:18] <heno> Kamion: ok, thanks. if I stick to 640x400 I should be ok I guess
[01:18] <mvo> thanks
[01:18] <Kamion> mvo: please *subscribe* ubuntu-archive, not assign
[01:19] <Kamion> mvo: if you assign, it doesn't show up on the list we use
[01:19] <mvo> Kamion: *ick* I was not aware of this
[01:19] <Kamion> oh, you did subscribe as well, that's ok then
[01:27] <chuck> heylo
[01:27] <pitti> hi zul, hey chuck :)
[01:28] <Mithrandir> Seveas: you're the guy doing the -changes RSS feeds, right?
[01:28] <Mithrandir> Seveas: it seems like the parser get _really_ confused with Manoj-style changelogs.
[01:29] <Seveas> Mithrandir, give me a for-instance
[01:30] <Mithrandir> Seveas: make-dfsg ; http://launchpad.net/distros/ubuntu/edgy/+source/make-dfsg/3.81-2 is the link.
[01:31] <Seveas> Mithrandir, hmmm funky
[01:32] <Seveas> Mithrandir, yes, it gets quite confused about that...
[01:33] <Seveas> not too hard to fix though
[01:34] <ogra> hmm, am i forced to merge a package that we always packaged from the upstream tarball directly ?
[01:37] <Kamion> mvo: done
[01:37] <mvo> thanks
[02:26] <doko> pitti: is your change in binutils_2.16.1cvs20060117-1ubuntu2.1 still needed for 2.17?
[02:27] <tseng> Mithrandir++
[02:27] <Mithrandir> http://err.no/tmp/b/ for a couple of graphs.
[02:27] <pitti> doko: hm, I cannot tell without looking
[02:27] <pitti> Mithrandir: so you removed X? :-P
[02:27] <_ion> mithrandir: \/
[02:28] <Mithrandir> pitti: I sorted the file system. :-P
[02:28] <Mithrandir> I think we should be able to get off a bunch more too.
[02:28] <Mithrandir> uh, shave off some more time.
[02:32] <TheMuso> Cool!
[02:37] <Riddell> Kamion: I've fixed the sentence you marked on +spec/kubuntu-hwdb, I don't know if you get notification of changes the specs you've revieved
[02:39] <Kamion> Riddell: thanks, bumped to pending-approval
[02:53] <mdz> Mez: yes?
[02:54] <tseng> morn mdz 
[02:54] <mdz> morning
[02:59] <sivang> morning mdz 
[03:48] <ogra>        * src/gs-monitor.c: (listener_simulate_user_activity_cb),
[03:48] <ogra>         (disconnect_listener_signals), (connect_listener_signals):
[03:48] <ogra>         Rename Poke to SimulateUserActivity since that seems to be
[03:48] <ogra>         preferred from feedback on XDG list.  How boring.
[03:49] <ogra> all apps that dont have dbus support use gnome-screensaver-command --poke in ubuntu :(
[03:56] <mdz> mgalvin: I just noticed that your last two UWN messages were waiting in the moderation queue for ubuntu-news
[03:56] <mdz> mgalvin: mako apologizes for that
[03:56] <ogra> well, they were on planet at least
[03:57] <Kamion> ogra: so add an alias for that option for a while, until the callers are converted
[03:57] <ogra> Kamion, i havent built it yet, not sure if that only means the dbus backend ...
[03:58] <ogra> but changing that would do much harm to us ... in any case we'd have to youch all these packages again at some point
[03:58] <ogra> *touch
[03:59] <fabbione> Setting up dpkg (1.13.21ubuntu1) ...
[03:59] <fabbione> touch: setting times of `/var/log/dpkg.log': Function not implemented
[03:59] <fabbione> dpkg: error processing dpkg (--configure):
[03:59] <fabbione> doh!
[03:59] <ogra> mount -t proc proc /proc ?
[04:00] <fabbione> righ
[04:00] <fabbione> point
[04:00] <ogra> :)
[04:00] <fabbione> ogra: sometimes you are not completely useless :P
[04:00] <ogra> haha
[04:01] <fabbione> :)
[04:02] <sivang> fabbione: you
[04:02] <sivang> fabbione: err, you're using a chroot?
[04:02] <fabbione> sivang: yes
[04:02] <mdke> heno: ping?
[04:04] <HiddenWolf> mdke, is there any way to get a breadcrum trail above the community docs at help.ubuntu.com?
[04:05] <mdke> HiddenWolf: of pages visited? not at the moment
[04:06] <HiddenWolf> too bad
[04:08] <bddebian> Morning folks
[04:09] <Keybuk> pitti: holy crap, that's damned weird
[04:09] <pitti> Keybuk: udev or MoM?
[04:10] <Keybuk> udev
[04:10] <Keybuk> MoM is being weird?
[04:11] <pitti> Keybuk: I mailed you about not generating a proper orig.tar.gz/diff.gz for the merged result
[04:11] <Keybuk> ah, I've not read my canonical inbox yet ... I'll look into that in a moment
[04:11] <Keybuk> did the merged result have conflicts?
[04:11] <pitti> Keybuk: no
[04:12] <pitti> Keybuk: for the ones having conflicts the behaviour seems ok to me (having the package in a single tarball)
[04:12] <Keybuk> hmm, yes, I see that isn't right
[04:12] <Keybuk> it hasn't given you "-sa" in the genchanges suggestion either
[04:13] <pitti> I saw more examples of that, so it wasn't just a single glitch
[04:13] <Keybuk> I'll debug that momentarily
[04:13] <Keybuk> just as soon as I have more coffee
[04:14] <Keybuk> how do you find the new format in general btw?
[04:15] <pitti> Keybuk: TBH, the << == >> conflict files are somethimes confusing, since I do not see the base revision
[04:15] <pitti> Keybuk: a three-way diff would sometimes help
[04:15] <pitti> Keybuk: in general I prefer separate .rej files (bonus: in unidiff format :) )
[04:15] <pitti> but that might just be me
[04:16] <pitti> in general, today's merges went very fine with the current format
[04:16] <Mithrandir> pitti: you get those if you just apply one of the .patches by hand.
[04:16] <pitti> sure, but there is no 'merged' patch
[04:17] <pitti> and it's not possible to generate one if there are conflicts
[04:24] <Keybuk> pitti: the << || == >> thing seemed to confuse every editor I tried it in
[04:41] <mako> mgalvin: about stuff on -news
[04:44] <sivang> hmm, group photo went out nice
[04:45] <jsgotangco> yes very nice indeed
[04:47] <Keybuk> aha!  found the cause of pitti's mom bug
[04:47] <Keybuk> I was using ${without_epoch}.orig.tar.gz  not ${upstream}.orig.tar.gz
[04:47] <Keybuk> heh
[04:55] <Kamion> mdke: could you update the installation guides on doc.ubuntu.com to the current version in dapper?
[04:55] <Kamion> mdke: it might also be nice to add the installation guide to help.ubuntu.com
[05:08] <mgalvin> mdz, mako: no worries, i blogged about them so they got some exposure
[05:08] <mgalvin> mako: whats up
[05:08] <mdz> mgalvin: I added your address to the whitelist, but could you post future editions using your @ubuntu.com address so that they look more official?
[05:09] <mgalvin> mdz: cool, i don't have an @ubuntu :(
[05:09] <mdz> mgalvin: !  why not?
[05:09] <jsgotangco> ?
[05:09] <jjesse> how do you get a @ubuntu.com email? just being a member right?
[05:09] <Kamion> mgalvin: you should do, you're in ubuntumembers
[05:10] <Kamion> mgalvin at ubuntu.com
[05:10] <Kamion> jjesse: right
[05:10] <mdz> Kamion: I revived seed-cleanup as non-informational considering the changes to germinate that we discussed
[05:10] <Kamion> mdz: ok
[05:11] <mgalvin> is it a forwarder address?
[05:13] <Kamion> yes, to your preferred e-mail address as listed in launchpad
[05:13] <mako> mgalvin: no, i can still send them out
[05:14] <mako> or do you want to resend it w/ a message
[05:14] <mako> or have me do so
[05:14] <mako> it's up to you
[05:14] <Kamion> yea verily choose-mirror merges are tedious unto death
[05:14] <Keybuk> heh
[05:15] <Keybuk> I just wrote down a list of all of the packages I touched in dapper, so I can merge them
[05:15] <Keybuk> and had to get more paper
[05:15] <bddebian> heh
[05:15] <Hobbsee> hehe
[05:16] <mgalvin> mako: i can send them out, I will do it in a moment
[05:22] <mgalvin> mdz: oh, and thanks for adding me to the whitelist
[05:22] <mdz> mgalvin: np
[05:23] <mdz> mgalvin: ping me when you send a message from @ubuntu.com to ubuntu-news and I'll do the same for that address
[05:23] <zul> mdz: ill be updating my quiet grub patch with ideas from the spec tonight
[05:24] <mdz> mgalvin: I sent a test email to mgalvin@ubuntu.com
[05:24] <mdz> zul: should I hand that off to you?  I'm currently the assignee but you've beat me to it
[05:24] <zul> mdz: no problem
[05:24] <zul> im going to be syncing grub tonight anyways..
[05:25] <mdz> zul: ok, that's another I'll remove from my todo list then ;-) thanks
[05:26] <zul> your welcome
[05:26] <mgalvin> mdz: thanks, i got it, now i know that it actually works :)
[05:31] <mgalvin> mdz: alright if i just send a test message to -news so you can set it?
[05:35] <mgalvin> mdz: well, i just sent a test to ubuntu-news with my @ubuntu address and it works, thanks
[05:39] <Hobbsee> mgalvin: test passed
[05:39] <Hobbsee> @ the ubuntu news mailing list
[05:39] <mgalvin> Hobbsee: yea thanks :)
[05:40] <fabbione> Keybuk: ping?
[05:40] <Keybuk> fabbione: pong
[05:40] <fabbione> Keybuk: yo.. when and if you have time could you please get openais out of NEW?
[05:41] <mdz> fabbione: ubuntu-cluster is already approved, and ubuntu-edgy-cluster just points to ubuntu-cluster
[05:41] <mdz> fabbione: there is no need to approve it again
[05:41] <fabbione> mdz: i did talk with Mithrandir for a review. I am going to cleanup the spec so that's more clear what's dapper and what's edgy
[05:41] <mdz> fabbione: unless you want to split out the incomplete parts into a new spec, which might be a good idea
[05:42] <Keybuk> fabbione: sure, there's a few things in NEW waiting review; I tend to do that in an hour or two
[05:42] <fabbione> mdz: we did agree in having an History session or something like that..
[05:42] <fabbione> Keybuk: that's fine for me.
[05:42] <fabbione> Keybuk: i am in no hurry to get it in the archive, but i would prefer to avoid to have to build it manually on 6 arches for testing :)
[05:43] <bluefoxicy> ubuntu's policy with screwing with the toolchain and glibc is no right?
[05:43] <bluefoxicy> (eyeing up -hashvals and -dynsort .... -Bdirect has implication that can be rough on the maintainers for now)
[05:44] <fabbione> bluefoxicy: toolchain changes for release foo needs to be discussed and approved during foo -1
[05:44] <fabbione> bluefoxicy: approved implies also tested
[05:44] <fabbione> toolchain needs to be ready for when foo opens up
[05:44] <bluefoxicy> ah ok.
[05:44] <fabbione> and they are the first packages to be built
[05:45] <fabbione> so basically toolchain changes for edgy are already too late
[05:45] <bluefoxicy> that's fine
[05:45] <mdz> fabbione: that sounds fine; I made a similar comment on sparc64
[05:45] <fabbione> and they have been discussed in dapper timeframe
[05:45] <fabbione> mdz: thanks a lot
[05:45] <bluefoxicy> it'll give meeks time to stabilize some stuff, maybe get it into actual binutils mainline, and get some inter-optimization optimizations going
[05:46] <fabbione> bluefoxicy: mainline > *
[05:46] <bluefoxicy> (they gave him a cvs branch AFAIK :)
[05:46] <fabbione> bluefoxicy: remember one very very important detail of diverging from upstream is that makes support for us more difficult
[05:46] <bluefoxicy> I know.
[05:46] <fabbione> an entire CVS branch for you?? crazy..
[05:46] <bluefoxicy> no not for me XD for Michael Meeks
[05:47] <bluefoxicy> He's been trying to get OpenOffice.org to load faster
[05:47] <bluefoxicy> along the way he's done some sort of subset of direct binding; precomputed ELF hash values of symbols (reduces L2 cache misses and avoids a big mathematical operation); and sorted symbol and relocation sections (reduces L1/L2 cache misses)
[05:48] <bluefoxicy> which makes symbol binding a lot faster (this is a good thing)
[05:48] <bluefoxicy> I guess Edgy+1
[05:49] <Keybuk> I like the way he spends all this time trying to fix the link-loader, and doesn't fix the fact OpenOffice's build system is fucking stupid
[05:49] <Keybuk> it doesn't need 300 .so files, it could have one statically linked binary
[05:49] <bluefoxicy> heh
[05:50] <bluefoxicy> if it had one giant library, it'd have has buckets with even more entries per bucket
[05:50] <bluefoxicy> and would load even slower :P
[05:50] <Keybuk> not one library
[05:50] <Keybuk> one binary
[05:50] <Keybuk> as in /usr/bin/openoffice
[05:50] <bluefoxicy> oh
[05:50] <Keybuk> no stupid .so files that nothing else uses
[05:50] <bluefoxicy> that'd break address space randomization
[05:51] <bluefoxicy> http://people.redhat.com/drepper/no_static_linking.html
[05:51] <Keybuk> they don't _NEED_ to be .so files
[05:51] <Keybuk> there's only one openoffice process anyway
[05:51] <bluefoxicy> bullet point 2 :P
[05:51] <bluefoxicy> heh
[05:51] <bluefoxicy> It'd still be slower anyway methinks.
[05:51] <azeem> Keybuk: maybe it's easier to get a branch in binutils than in OOo
[05:51] <Keybuk> it's MUCH MUCH MUCH faster
[05:52] <bluefoxicy> Why would it be faster
[05:52] <fabbione> azeem: that's because it's easier to hack binutils than OOo :)
[05:52] <Keybuk> because it doesn't need to perform any relocation (other than libc, etc.) to load openoffice itself
[05:52] <bluefoxicy> oh right
[05:52] <Keybuk> it doesn't need to jump through the PLT for every internal function call
[05:52] <bluefoxicy> I keep thinking it'll still need to run around resolving symbols
[05:52] <azeem> I didn't even know openoffice itself had loads of libraries, I assumed he was fighting the GNOME stack
[05:53] <Keybuk> don't get me wrong, DSOs are a good thing when you consider an application stack like GNOME
[05:53] <Keybuk> because they're actually shared between multiple applications
[05:53] <bluefoxicy> yeah
[05:53] <bluefoxicy> also openoffice.org doesn't really load everything at startup
[05:53] <Keybuk> but building a single application, with a single binary, by splitting it into 100s of .so files and linking them all together through the link-loader and dlopen() is just MADNESS
[05:54] <bluefoxicy> Meeks actually said he'd split OOo into twice as many libraries if it were feasible so he could load less stuff at startup :P
[05:54] <Keybuk> that's the way Windows programs are written ("the entire application is in DLLs") not the way UNIX programs are written
[05:54] <bluefoxicy> (some of the stuff is not needed immediately)
[05:54] <Keybuk> which is silly
[05:54] <Keybuk> if he joined it into one binary, it would be loaded optimally *anyway*
[05:54] <Keybuk> as the kernel would only map the used pages into physical memory from disk
[05:54] <Keybuk> unused bits of code would stay on disk
[05:55] <mdz> linux incorporates 1960s technology known as 'demand paging'
[05:55] <fabbione> azeem: try to do a OOo build and you will suddenly change your mind and probably reinstall from scratch because not even rm -rf / can get rid of all build-deps
[05:55] <mdz> fabbione: hmm?
[05:55] <bluefoxicy> fabbione:  and you start using the 'f' word yelling at doko *glances at Keybuk*
[05:55] <bluefoxicy> a lot :)
[05:56] <Keybuk> heh, I scared everyone in the room with that
[05:56] <bddebian> heh
[05:56] <fabbione> mdz: i was answering azeem about the tons of .so libs in OOo
[05:56] <fabbione> Keybuk: nah.. i used to build OOo over nfs for breezy :)
[05:56] <fabbione> Keybuk: 48 hours with ccache
[05:56] <Keybuk> fabbione: it was just my great amusement really
[05:56] <bluefoxicy> Keybuk:  besides, the advantage of what Meeks is doing is that the whole damn system gets faster.
[05:56] <fabbione> Keybuk: oh yeah...
[05:56] <Keybuk> I'd made a fresh i386 chroot for it on quest
[05:57] <Keybuk> and did apt-get build-dep openoffice
[05:57] <mdz> Keybuk: can MOM give us a status report of what has been merged in edgy and what hasn't yet?
[05:57] <Keybuk> and there was a cry of "A FUCKING GIGABYTE?!  THAT'S THE ENTIRE FUCKING ARCHIVE!  DOKO!!!"
[05:57] <fabbione> Keybuk: that was an rsync of archive into /var/cache/apt/archives..
[05:57] <Keybuk> mdz: yes; it will be able to by the end of today
[05:57] <mdz> Keybuk: you are my hero
[05:58] <Keybuk> bluefoxicy: redesigning ELF so it doesn't require strcmp() would be a start :p
[05:58] <bluefoxicy> Keybuk:  direct binding, precomputerd elf hashes, and dynamic symbol sorting are all in gentoo; certain gentoo users have become really attached to "ultra-fast systems" because they stopped using CFLAGS="-O99 -march=k7_stepping3_revision2 -fomit-everything -ffast-math -ffaster-math -feverything-else" and started using CFLAGS="-O2 -pipe" LDFLAGS="-Wl,-O1,-Bdirect,-hashvals,-dynsort" :P
[05:59] <bluefoxicy> (nothing you do to gcc optimizations is going to make the system "ultra uber fast")
[05:59] <bluefoxicy> Keybuk:  that's what -hashvals does ;)
[06:00] <bluefoxicy> Keybuk:  well, not really.  It replaces a hash computation (that reads a string) with a precomputed hash value.. I guess -Wl,-O1 reduces the number of strcmp()s, and -Bdirect reduces it massively by not walking you through every library loaded
[06:00] <Keybuk> neither -Bdirect -hashvals or -dynsort is in upstream binutils yet though, no?
[06:00] <bluefoxicy> (direct binding binds a symbol to a DT_NEEDED entry, so the linker doesn't have to go find the library with the symbol)
[06:00] <doko> Keybuk: desparately crying for OOo maintainership? ;-P
[06:01] <bluefoxicy> Keybuk:  not yet, and I would be wary about using -Bdirect for a while because it has rough edges.  Meeks hasn't finished up a method to handle interposing yet
[06:01] <Keybuk> doko: as I said in the team meeting, I'll happily take over OOo -- provided nobody minds my first (and last) act as maintainer being "remove-package -m '(keybuk) GET OUT OF MY ARCHIVE' openoffice.org" :p
[06:01] <Hobbsee> Keybuk: haha do it :P
[06:01] <Hobbsee> Keybuk: easier to get koffice in that way :P
[06:01] <bluefoxicy> it seems that a lot of our programs seem to rely on interposers... i.e. 3 libs have the same symbols, the linker links you to the first lib with the symbol
[06:01] <Keybuk> bluefoxicy: I know what they do :p
[06:01] <fabbione> Keybuk: i think with to add a -fremove-bugs to gcc first, but the problem is that gcc upstream wants a test case for that.. i am not sure how to prove my patch work since i can't break it
[06:02] <Keybuk> I follow ELF/ld stuff pretty closely ... side-effect of being the libtool maintainer for years
[06:02] <bluefoxicy> ah
[06:02] <Keybuk> Hobbsee: koffice is also not compliant with my vision of how an office suite should work
[06:02] <Hobbsee> Keybuk: actually, that sounds rational.  who needs more than a text editor anyway?
[06:02] <lifeless> fabbione: write a test that is a bug, then your patch will fix it
[06:03] <Keybuk> sadly I've not yet had time to NIH my own office, so meh
[06:03] <Hobbsee> keep kate and gedit, kill off the office suites!
[06:03] <epx> is koffice still alive? :)
[06:03] <fabbione> lifeless: that doesn't work... becuase the resulting code will be working :)
[06:03] <Hobbsee> epx: i believe so
[06:03] <fabbione> lifeless: and you can't prove the code was broken in the beginning
[06:03] <lifeless> fabbione: he resulting code is meant to work ;)
[06:04] <lifeless> fabbione: sure you can, write it faultily.
[06:05] <bluefoxicy> Keybuk: I had an idea to use patricia tries for the hash buckets for symbol tables but not sure if that'll work that great.  The theory is sound (you only compare common prefixes ONCE, not once per symbol in the bucket with that prefix preceeding the symbol you need; basically the best case becomes the worst case)
[06:07] <bluefoxicy> Keybuk:  the state machine to search the tree is sound, it's light weight, it's fast; building it I have not figured out (it'd be recursive), but it's possible.  The only issues I have are I'm not sure about the nature of a hash bucket; can the total data in it grow bigger than 64k, particularly
[06:07] <mdz> mvo: is there an existing spec for the g-a-i improvements we discussed? specifically the .desktop file cache and the popcon sorting
[06:07] <bluefoxicy> popcorn?
[06:08] <lifeless> bluefoxicy: look into (IIRC) perfect tries
[06:08] <lifeless> bluefoxicy: ah right, gperf is what  I am thinking of.
[06:08] <bluefoxicy> lifeless: patricia tries follow a string until two keys differ, then branches; how is that not perfect ;)
[06:10] <lifeless> bluefoxicy: I know what a patricia is. Have you read up on what I referenced ? If not, I think youare just arguing for arguments sake.
[06:10] <bluefoxicy> gperf is perfect hashes
[06:11] <bluefoxicy> doesn't that generate hash functions?  (which can become annoyingly not perfect when you're dynamic linking, because they rely on the exact data set not to change)
[06:12] <mvo> mdz: no, both are discussed in the filetypes spec, but not done seperately
[06:13] <bluefoxicy> lifeless:  you could do it, but you'd need a hash function per library loaded; and then, since the linker runs through every library, you'd need to rehash each symbol you look up over and over again with each idfferent hash function
[06:13] <bluefoxicy> lifeless:  which is already more CPU time than we're using now.
[06:13] <lifeless> for some reason I thought it generated a variation of trie, I've just re-read its guts myself.
[06:13] <lifeless> so ignore my reference.
[06:13] <bluefoxicy> kay.
[06:13] <lifeless> however I have another useful reference for you - hash-tries.
[06:14] <lifeless> let me dig up citseseer for it
[06:14] <bluefoxicy> "An ordinary trie used to store hash values"
[06:14] <lifeless> I think http://citeseer.ist.psu.edu/459691.html is what I am thinking of, but I'll need to quickly read it to be sure.
[06:15] <mdz> lifeless: are you happy with easy-codec-installation apart from your comment? (which was trivially addressed)
[06:15] <lifeless> mdz: let me check.
[06:17] <lifeless> mdz - yes it looks reasonable to me
[06:17] <mdz> lifeless: thanks
[06:17] <bluefoxicy> lifeless:  looks like a hash table of hash tables of tries
[06:18] <mdz> Keybuk: I've set you as approver on https://launchpad.net/distros/ubuntu/+spec/easy-codec-installation since I wrote it; it's now pending approval
[06:19] <Keybuk> mdz: ok, I'll look in a bit
[06:19] <mdz> common-customizations also needs review
[06:20] <lifeless> bluefoxicy: the HAMT structure? if you wanted a buzzword description, sure. I suggest reading the paper though, as its extremely likely to give better results than patricias tries for linker tables.
[06:22] <bluefoxicy> lifeless:  any particular reason?  I'm trying to reduce the lookup time from O(s*n) to O(n) once the hash bucket is fallen into during a search; I believe (am guessing) that the hash tables themselves are simply hashed and then reduced (i.e. masked, modulused, etc) to a search space, which is turned into an array index, so the lookup of the actual hash table entry should be O(1)
[06:22] <lifeless> in something like this, the golden rule is do not guess
[06:23] <bluefoxicy> well I'd have to do a separate section so I could very well do it that way if I want anyway ;)
[06:23] <bluefoxicy> Keybuk:  how's the elf hash table work :) (when you get a chance)
[06:23] <Keybuk> how do you mean?
 ....I believe (am guessing) that the hash tables themselves are simply hashed and then reduced (i.e. masked, modulused, etc) to a search space, which is turned into an array index, so the lookup of the actual hash table entry should be O(1)
[06:24] <bluefoxicy> Keybuk:  do they generate a hash and iterate a sparse table (O(n) style) or turn it into an array index (O(1) style)
[06:25] <Keybuk> O(1)
[06:25] <bluefoxicy> lifeless:  :)
[06:25] <bluefoxicy> Keybuk:  thanks.
[06:27] <lifeless> bluefoxicy: if I can suggest, read that paper closely. from memory it is designed with processor cache size and prefetch concepts considered.
[06:27] <lifeless> bluefoxicy: just twiddling the current system is often an unrewarding optimisation technique - you need to go right back and question the core algorithms. Sun wrote a nice paper on this.
[06:28] <bluefoxicy> lifeless:  I have a degree to go pick up, i'll look when I get back; skimmed the paper but it looks like the search is compute hash and make a linear search (which is what we do right now)
[06:28] <lifeless> bluefoxicy: then you dont understand it at all
[06:28] <bluefoxicy> lifeless:  I did consider processor cache size  -->  http://sourceware.org/ml/binutils/2006-06/msg00399.html
[06:29] <bluefoxicy> "To nd a given record, rst compute the keys hash. [...]  and then making a linear search to nd the correct record." page 11, 4.1.  Searching is the only operation I'm concerned with
[06:30] <bluefoxicy> oh wait.  Wow I scrolled through too fast huh.  There's a lot of algorithms described here.
[06:31] <Keybuk> HEALTH AND SAFETY WARNING: Do not do a Google Images search for "mom" with SafeSearch turned OFF
[06:31] <bluefoxicy> XD
[06:37] <bddebian> Can anyone tell me why I can apt-get update and install x11proto-gl-dev inside of pbuilder login but pbuilder build foo.dsc fails for build-dep x11proto-gl-dev?
[06:37] <bddebian> Heya ivoks
[06:38] <glatzor> ping wasabi
[06:42] <slomo> Riddell: avahi in debian will have an /etc/defaults file soon... it's already implemented, only waits for an upload now... i'll merge back everything after it was uploaded
[06:43] <Riddell> slomo: excellent
[07:09] <dieman> funny, theres a dapper/multiverse/debian-installer, but not a dapper-updates/multiverse/debian-installer :)
[07:16] <Kamion> dieman: neither will ever be used ...
[07:16] <Kamion> well, not in dapper anyway
[07:25] <dieman> Kamion: yah, i figured :0
[07:25] <dieman> :)
[07:26] <bluefoxicy> dapper-updates?
[07:27] <dieman> i ended up writing a perl script to add a couple packages to main for myself and add a new task based on ubuntu-desktop with some packages added/removed
[07:27] <dieman> its much faster than rewriting the override files and allowing apt-ftparchive crunch the entire archive :)
[07:28] <Kamion> dieman: definitely
[07:28] <siretart> are there only packages from 'main' on 'http://merges.ubuntu.com'?
[07:28] <Kamion> I tend to use apt-ftparchive on individual packages
[07:28] <dieman> yah
[07:29] <dieman> im just feeding it an file list and override files for the small amount of stuff we modify that needs to be there for debootstrap
[07:29] <dieman> and then it will also be handling our own dapper-local archive
[07:30] <dieman> in both cases the files are kept in a seperate pool that im currently sorting out by hand
[07:42] <sivang> re
[07:51] <fabbione> hey guys
[07:51] <fabbione> so i have heard rumors of the new X guy that will take care of edgy
[07:52] <bddebian> zakame? :-)
[07:52] <zul> new x guy?
[07:52] <rodarvus> O_o
[07:53] <fabbione> i will tell only under heavy payment in local beer
[07:53] <bddebian> Gah, darn foreigners, too expensive to pay in beer :-)
[07:54] <HiddenWolf> new x guy?
[07:55] <zul> heh...will find out when we read the changelog
[07:55] <fabbione> zul: exactly :)
[07:55] <HiddenWolf> fabbione, what kind of beer do you prefer? :)
[07:56] <fabbione> HiddenWolf: well i live in dk and here they produce Tuborg and Carlsberg..
[07:56] <zul> isnt carlberg german?
[07:56] <HiddenWolf> I thought so
[07:57] <fabbione> nope.. it's danish
[07:57] <fabbione> it's acutally the same company as tuborg
[07:57] <fabbione> it has been bought not too long ago
[07:58] <fabbione> anyway 
[07:58] <rodarvus> danish beer is great stuff
[07:58] <rodarvus> contrast it with the non-alcoholic brazilian beer I'm allowed to drink :)
[07:59] <fabbione> why non-alcoholic?
[07:59] <bddebian> Damn I hate autoconf some times
[07:59] <HiddenWolf> I prefer belgian beer, really. :)
[07:59] <fabbione> last time i was in .br they had alchool
[07:59] <bddebian> Aye, Belgium had some good beers
[08:00] <bddebian> Ooohh, we are getting Overfiend?? ;-P
[08:00] <rodarvus> fabbione, we do - I can't drink alcoholic beer for other reasons (had a surgery two months ago)
[08:00] <zul> anything but american swill
[08:00] <fabbione> rodarvus: oh well make sense :)
[08:00] <HiddenWolf> sivang, the most masochistic debian-x-team member most probably. ;)
[08:00] <glatzor> ping sivang
[08:00] <rodarvus> it is better than no-beer-at-all, but just barely :D
[08:00] <sivang> glatzor: pong
[08:00] <fabbione> bddebian: don't kid too much about OF..
[08:01] <bddebian> fabbione: ?  I know he was a little miffed at Debian
[08:01] <fabbione> bddebian: he is a very good friend of mine
[08:01] <glatzor> how are you? arrived in Israel fine?
[08:01] <sivang> glatzor: yeah, sure, been a bit bumpy but otherwise cool :-)
[08:01] <fabbione> bddebian: X maintainers are miffed at everything by definition...
[08:02] <bddebian> fabbione: That was no slam.  Why do you seem to take everything I say negatively?  I like him.
[08:02] <glatzor> sivang: I talked with mpt and we made some minor changes to the ui. but nothing drastic.
[08:02] <Mithrandir> fabbione: but X is so much love!
[08:02] <fabbione> bddebian: same reason i just told you :)
[08:02] <glatzor> sivang: and I once again forget your repo url :)
[08:02] <fabbione> Mithrandir: no, it's pure BDSM
[08:02] <dieman> heh
[08:02] <bddebian> fabbione: Ah :-)
[08:02] <dieman> X isn't so bad
[08:02] <sivang> glatzor: heh, I should put it on bazarr.l.n :-)
[08:02] <dieman> after you read a few drivers worth of code
[08:02] <dieman> to insert some small patch
[08:02] <glatzor> sivang: let's switch over to ddesktop? it is not so crowded :)
[08:02] <dieman> its all just lots of reading and thinking
[08:03] <fabbione> you guys should really try to maintain X for like a year 
[08:03] <dieman> yeah, no thanks :)
[08:03] <sivang> glatzor: sure
[08:03] <fabbione> and then i will come and visit you at the mental hospital
[08:03] <dieman> heh
[08:03] <dieman> i dont even want to spend the time to figure out why 945gm locks up or does other weird stuff when you try to crt/lcd
[08:04] <dieman> ive never looked at x multiplatform issues either
[08:04] <dieman> which i guess is a huge chunk of what nailed debian for a while
[08:05] <fabbione> so how can you say that X is not that bad if you didn't look at 99.9% of its problems?
[08:05] <dieman> heh
[08:05] <dieman> i didn't know thats 99.9% :)
[08:05] <dieman> ignorance is bliss?
[08:05] <Mithrandir> fabbione: I've hacked XKB stuff.  According to at least some X people, it's the worst of the worst.
[08:06] <fabbione> Mithrandir: oh yeah you have my deepest and biggest respect for that. The Family will always protect you
[08:06] <fabbione> Mithrandir: but you have seen only one corner of X
[08:06] <Mithrandir> fabbione: And I haven't got mad yet! :-)
[08:06] <fabbione> Mithrandir: eheheh that's how it feels in the beginning..
[08:07] <Mithrandir> s/got/gone/
[08:07] <fabbione> see.. already the first signs of itaglish..
[08:07] <fabbione> you are addicted now
[08:07] <ogra> Mithrandir, in the beginning you just dont notice :P
[08:07] <Mithrandir> ogra: at least I haven't started losing my apostrophes. :-P
[08:08] <Mithrandir> fabbione: good thing we have fresh blood for X, then.
[08:08] <dieman> yeah, i guess when I'm thinking about X its just the server and drivers, much less the rest of the system.
[08:08] <dieman> and thats not very much of it
[08:13] <fabbione> Mithrandir: yeah :)
[08:24] <zul> mdz: ping
[08:27] <slomo> Kamion: can you move nunit2.2 to main and move nunit to universe (and accept nunit from binary NEW)?
[08:27] <zul> mdz: unping
[08:28] <Kamion> slomo: I did the binary NEW a while back
[08:29] <Kamion> slomo: for the rest, sure, is it going to be a (build-)dependency of something?
[08:29] <Keybuk> mdz: errr, isn't that team meeting time somewhat off-schedule
[08:29] <Keybuk> tomorrow's meeting should be in ~8 hours according to my calendar :P
[08:30] <slomo> Kamion: it is already... of mono-tools (my merge from debian uploaded some seconds ago) and nant (on dep-wait because of that)
[08:30] <Kamion> slomo: oh, ok, but I'm about to have friends round for dinner and the publisher is still running so I can't change overrides
[08:31] <Kamion> Keybuk: can you deal with slomo's request after the publisher finishes?
[08:31] <slomo> Kamion: np :) i can also send you a mail or remind you tomorrow... it's not that urgent
[08:31] <sivang> hey slomo !
[08:31] <Keybuk> yup, slomo: ping me in ~15 mins
[08:31] <slomo> hi sivang :)
[08:32] <slomo> Keybuk: ok, will do... thanks
[08:32] <sivang> slomo: how was your trip home?
[08:32] <slomo> sivang: nice... although i left really late for the flight i had to wait 40 minutes or something and then everything was on time :)
[08:33] <slomo> sivang: and your's? how long did it take btw? :)
[08:36] <mdz> Keybuk: how does your calendar work?
[08:37] <slomo> infinity: please give-back banshee on i386... last try was a bit too early and a dependency wasn't there yet :) thanks
[08:37] <mdz> Keybuk: when we skipped the previous meetings, we picked up the rotation where we left off, rather than skipping steps in the pattern
[08:39] <Keybuk> mdz: ah, that would explain why I was out of sync then
[08:39] <ogra> Keybuk, you dont use the fridge calendar in evo ? it shows the right time
[08:39] <Keybuk> it's just evolution 4-weekly things
[08:39] <Keybuk> ogra: the fridge calendar has too much other crap on it
[08:39] <ogra> well, i cant see it anyway anymore since i use the release schedule :P
[08:40] <Keybuk> ogra: you can't have _just_ the technical board meetings
[08:40] <ogra> couldnt we have an additional version with only the milestone dates ? 
[08:41] <ogra> i have to switch it off to see *something* in my panel calendar now 
[08:41] <ogra> else the days until edgy release are simply all bold :)
[08:41] <ogra> (yes i know i'm moaning)
[08:42] <Keybuk> ogra: you can make your own :p
[08:42] <Keybuk> I must admit, I tend to use the list at the bottom of the applet rather than the bold/not-bold bit
[08:42] <ogra> i think thats what i will d, but then i'll miss changes
[08:42] <Keybuk> ogra: subscribe to the wiki page?
[08:42] <ogra> well, i use to look up dates for the week on monday ... 
[08:43] <ogra> there the bold days come in handy
[08:44] <ogra> i actually never use the evo calendar itself ...
[08:45] <sivang> slomo: was good, I Liked the food on the aircraft :-)
[08:45] <sivang> slomo: about 4:30 hours
[08:45] <Keybuk> I've actually been _trying_ to use the evo calendar :p
[08:45] <sivang> Keybuk: I had trouble setting it up
[08:46] <ogra> well, i did that several times, but it never convinced me to do my day to day work
[08:46] <sivang> so anyway, when is the development meeting taking place? :-)
[08:46] <Keybuk> sivang: 1400 UTC ... whatever the announcement says :p
[08:46] <ogra> and my todo list is still the TODO.txt file on my desktop which i edit with vim :)
[08:46] <slomo> sivang: the food i got on the aircraft was rather bad ;)
[08:46] <slomo> Keybuk: ping :)
[08:46] <Keybuk> slomo: right, yes
[08:47] <Keybuk> slomo: what can I do for you?
[08:47] <slomo> Keybuk: move nunit to universe and nunit2.2 to main. some parts of main are already depending on libnunit2.2-cil and FTBFS because it's only in universe currently
[08:48] <slomo> Keybuk: and nunit is a newer, incompatible version of nunit that nobody uses yet
[08:48] <Keybuk> define "nunit" and "nunint2.2"
[08:48] <Keybuk> which binary and source packages would you like changed?
[08:48] <slomo> nunit source package to universe and nunit2.2 source package and libnunit2.2-cil binary package to main
[08:50] <Keybuk> ok, done
[08:50] <slomo> thanks :)
[08:50] <azazello> there's a regression in acpi-support, acpi_fakekey no longer works... does anyone know about a possible fix?
[08:51] <Keybuk> azazello: please file a bug
[08:51] <azazello> there is one
[08:51] <azazello> https://launchpad.net/distros/ubuntu/+source/kubuntu-meta/+bug/46948
[08:51] <Ubugtu> Malone bug 46948 in kubuntu-meta "[Laptop Regression]  Kubuntu doesn't honour Fn Key request" [High,Confirmed]  
[08:51] <azazello> and a corresponding one in debian
[08:51] <Keybuk> then the bug will be soon to in time
[08:52] <azazello> basically acpid no longer gets events from keypresses sent to /dev/input/event*
[08:52] <azazello> seems to be a kernel change...
[08:52] <azazello> or a udev change, or something
[08:52] <Keybuk> *shrug*
[08:52] <Keybuk> this isn't a support channel
[08:52] <ogra> its likely moved into hal
[08:52] <azazello> *shrug*
[08:53] <azazello> I'm not asking for support. I'm actually porting this to gentoo
[08:53] <Keybuk> porting to gentoo is also off-topic here
[08:53] <azazello> and getting stuck because of this regression
[09:11] <ogra> Keybuk, congrats for implementing the first spec :)
[09:12] <Keybuk> heh
[09:12] <ogra> its one i was really looking forward to ... ltsp will gain a lot of it :)
[09:14] <HiddenWolf> keybuk did one already?
[09:17] <fabbione> Keybuk: can you please reject openais from NEW?
[09:18] <fabbione> Keybuk: i think i did something badly wrong with the packaging that not even -0ubuntu0 should ever hit archive
[09:18] <fabbione> Kamion or mdz: ^^
[09:18] <fabbione> thanks guys
[09:20] <Keybuk> fabbione: yes, but not right now
[09:20] <Keybuk> actually, you only want a reject, yes I can do that now
[09:20] <fabbione> Keybuk: yes reject please
[09:20] <Keybuk> fabbione: gone
[09:21] <fabbione> Keybuk: sorry to be a pain but it was better gone than in
[09:22] <lifeless> bluefoxicy: oh, BTW, a radix tree (trie) is -not- a Patricia - they are not synonyms. See http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/PATRICIA/ for instance.
[09:22] <lifeless> a Patricia can be considered a PC trie (path compressed) trie.
[09:23] <bluefoxicy> lifeless:  wikipedia said they're the same
[09:24] <bluefoxicy> http://en.wikipedia.org/wiki/Patricia_trie
[09:25] <bluefoxicy> heh, Practical Algorithm To Retrieve Information Coded In Alphanumeric.  Interesting.
[09:25] <lifeless> wikipedia is wrong, nuff said.
[09:26] <lifeless> a patricia is a variation on the general pattern that is tries. Its true to say that 'a patricia is a trie', its not true to say that 'a trie is a patricia'.
[09:27] <lifeless> The first sentence in the wikipedia article under 'overview' is in fact wrong. It says radix tree when it means patricia.
[09:31] <lifeless> if you want to stick with a regular trie, you can look into LPC tries too, which IIRC are referenced from the HAMT paper.
[09:40] <setuid> I'm finding it more difficult to build packages these days on Dapper, because everything is 6 months ahead. No updates to Dapper in many moons. Is Edgy stable enough to function without making my entire development machine break? 
[09:40] <setuid> Or is it so much eye-candy that I'll go blind and not be able to work? 
[09:42] <Keybuk> "6 months ahead" ?
[09:43] <Keybuk> dapper only released three weeks ago
[09:43] <setuid> I've been doing daily apt-get updates and there haven't been updates in several months now
[09:43] <setuid> So it probably froze before release
[09:44] <bluefoxicy> lifeless:  radix tries are?
[09:45] <Keybuk> setuid: do you have dapper-updates in your sources.list ?
[09:45] <Keybuk> there have certainly been updates right up until June 1st
[09:45] <Keybuk> and since then in dapper-updates
[09:45] <setuid> deb http://archive.ubuntu.com/ubuntu dapper-updates main restricted
[09:45] <bluefoxicy> lifeless:  that link you gave me doesn't mention what a radix trie is.
[09:45] <lifeless> a radix tree is a trie.
[09:45] <wasabi_> Hmm. locales still broken.
[09:46] <lifeless> a radix trie is not a meaningful things AFAIK
[09:46] <bluefoxicy> lifeless:  yes, a radix trie is a trie in which the nodes with only single children are collapsed into their children, so "a - s - d" -> "asd", one node not 3
[09:47] <lifeless> erm, radix trie means 'radix radix tree'
[09:47] <lifeless> Its not meaningfull
[09:47] <lifeless> what you just described is a level-compressed trie.
[09:48] <bluefoxicy> http://www.ug.cs.usyd.edu.au/~cs2/dds/trie.html
[09:49] <zul> later
[09:50] <lifeless> bluefoxicy: dont believe everything you read. I can check TAoCP when I return home.
[09:50] <lifeless> which I think is sufficiently authoritative.
[09:50] <bluefoxicy> kay
[09:51] <lifeless> http://en.wikipedia.org/wiki/Trie is sane, for instance. Tries are radix trees by definition.
[09:52] <lifeless> (because the value of the item is the key itself)
[09:55] <lifeless> in fact, that http://www.ug.cs.usyd.edu.au/~cs2/dds/trie.html link is faulty in another way, it describes a patricia, not a random trie, which is annoying if the plan is to teach people accurate terms
[09:58] <bluefoxicy> every reference I've seen describes patricia/radix and trie different
[10:00] <Keybuk> siretart: I wanted to make sure MoM could do multiple passes on main before it started on universe
[10:00] <Keybuk> as there's pretty much a corner case in every package anyway
[10:42] <lifeless> night all
[10:42] <jjesse> night lifeless
[11:19] <bddebian> Gah, I thought TomeRaider was a TombRaider knock-off and I was getting excited :-)
[11:20] <HiddenWolf> bddebian, you like babes with guns and oversized boobs, don't you? ;)
[11:21] <bddebian> moi?
[11:21] <HiddenWolf> what else is tomb raider about? :)
[11:21] <Keybuk> Lara Croft is a Drag Queen
[11:21] <bddebian> What?
[11:22] <HiddenWolf> she is?
[11:23] <Keybuk> yes
[11:23] <HiddenWolf> I think that's an insult to the average drag queen. :)
[11:23] <ChipX86> pfft, Lara Croft is a fictional character. Therefore, she can be anything you want her to be.. and more. But not too much more.
[11:24] <HiddenWolf> lol
[11:24] <Keybuk> ChipX86: oh, c'mon, you're telling me you've ever seen a real woman swing their hips like she does?
[11:24] <ChipX86> I have. Have you?
[11:24] <bddebian> haha
[11:25] <ChipX86> that's probably the last thing I should play at work :)
[11:36] <bddebian> What determines when/if you need makefile.mk?
[12:01] <shawarma> bddebian: I think you only really need it if you're using a straight makefile (ie. no autotools stuff)
[12:01] <bddebian> Ah, thanks shawarma
[12:03] <shawarma> bddebian: np