[12:28] <wasabi_> oh hell
[12:28] <wasabi_> there is a script here.
[12:30] <doko> wasabi_: I think tromey told you ;)
[12:30] <wasabi_> I asked last night and haven't been able to check personal email heh
[12:32] <schweeb> IBM X41s are sweet.
[12:32] <tseng> hm
[12:35] <wasabi_> May get something done tonight. ;)
[12:35] <Mez> MOTUTodo confuses me - it sesm theres's useful links and done, but nothing to do
[12:39] <diamond> Mez: aye, ditto
[12:47] <Mez> lol
[01:03] <thom> hunger: the sata thing is known
[03:34] <bob2> woo, some dhtml crashed firefox
[04:34] <quio> Hello every one !  I'm using Breezy and I just upgraded my dist... when i tried to start my X , I got this error:  glibc detected *** double free or corruption (fasttop) , somebody knows how to fix it?
[04:34] <schweeb> did you check the mailing list?
[04:34] <maswan> elmo: 130.239.18.137 is gone from ftp.acc for the moment, you should probably update
[04:34] <jamesh> quio: it means that the app is buggy
[04:35] <schweeb> X is known to be pretty broken in breezy
[04:35] <schweeb> (intentionally so)
[04:36] <jamesh> quio: you could try running "MALLOC_CHECK_=0 startx" to see if it starts
[04:36] <quio> ok, let me try it :)
[04:37] <jamesh> that just turns off glibc's malloc bug checker
[04:38] <quio> yeeeeah!!! :D it works!! thanks jamesh ... really I appreciate your help ;)
[04:40] <jamesh> quio: setting that env var doesn't solve the problem though -- it just stops glibc from looking for it
[04:43] <quio> so, It appears to be a glibc bug, by now I can continue working with your sol :).  To really fix this, do you think that I have to wait for the upgrade of glibc or have another permanent solution?
[04:44] <jamesh> not a glibc bug
[04:44] <jamesh> a bug in the application (e.g. calling free() on the same bit of memory twice)
[04:45] <jamesh> once the heap gets corrupted anything can happen in the program, which is why glibc checks for the condition and aborts
[04:45] <quio> mmm yes..... ok, thank jamesh... I will continue my work by now ;)....
[04:45] <jamesh> better to have an aborted process than a rooted system.
[04:48] <eruin> anyone packaging istanbul in here?
[05:03] <seth_k> eruin, see my reply in -motu
[05:22] <fabbione> morning
[05:31] <schweeb> mornin
[05:38] <toresbe>  moin
[06:32] <wm_eddie_> hmmm... autoplay and multiple log-ins and auto-play don't work together...
[06:32] <Lathiat> autoplay?
[06:34] <wm_eddie_> I put in a DVD, and my sister's account auto-played it.
[06:35] <wm_eddie_> hmm...
[06:35] <wm_eddie_> Maybe the Fast User Switching Applet can tell gnome via D-BUS who'
[06:35] <wm_eddie_> s
[06:35] <wm_eddie_> account is currently visible.
[06:37] <Lathiat> oh right
[06:38] <Lathiat> wm_eddie_: well, yeh, g-v-m already does dbus so
[06:38] <wm_eddie_> There's no other way huh...
[06:38] <Lathiat> wm_eddie_: thats not such a badidea
[06:38] <Lathiat> maybe g-v-m can figure out what tty its X server ison?
[06:38] <wm_eddie_> Yeah, but the auto-play stuff needs to know about multiple logged in users.
[06:39] <Lathiat> yeh but
[06:39] <Lathiat> if it know what tty it is on
[06:39] <Lathiat> it can see if its active or not
[06:40] <wm_eddie_> What do you mean tty?
[06:40] <wm_eddie_> :0, :1, etc?
[06:41] <daniels> wm_eddie_: vt7, vt8, et al
[06:41] <wm_eddie_> hmm
[06:41] <daniels> but what $DISPLAY it's on is more interesting, easy to get, and practical
[06:42] <wm_eddie_> What do you mean it's on?
[06:42] <Lathiat> daniels: but can you tell what $DISPLAY is active?
[06:43] <daniels> Lathiat: if FUS was keeping track, sure
[06:43] <daniels> if you switch away, or have a multiseat setup, all bets are off
[06:43] <Lathiat> right
[06:43] <daniels> (but if you wanted to keep track of it even through vt switches, an x extension could potentially be interesting)
[06:43] <Lathiat> wel obviosuly it would be overriden for multiseat
[06:43] <Lathiat> in favour or manual config
[06:43] <daniels> right, as g-v-m is now
[06:44] <Lathiat> is there an easy way to find what xserver is on a tty?
[06:44] <Lathiat> im just thinking an X extension could be over the top
[06:44] <wm_eddie_> It's pretty frustrating that I can't eject my DVD because my sister logged into the computer 4 days ago...
[06:44] <Lathiat> wm_eddie_: just unmount it
[06:44] <Lathiat> as root
[06:44] <Lathiat> :)
[06:44] <Lathiat> but yeh, it is
[06:45] <Lathiat> (if she has stuff open on it)
[06:45] <wm_eddie_> Yeah, I know that, but that's because I've been using linux for years.
[06:45] <Lathiat> linux really could do with a way to invalidate files for removable media
[06:45] <daniels> Lathiat: no solution that doesn't involve ps and grep, no
[06:45] <Lathiat> so it can just tell a process usingit to fuck off
[06:45] <daniels> Lathiat: even though, you'd need a root helper app to determine what tty you're on anyway
[06:45] <Lathiat> daniels: or looking around /proc, slightly lessevil
[06:46] <daniels> Lathiat: still equally evil, and open to subversion from user processes with carefully crafted strings
[06:46] <Lathiat> hm
[06:46] <Lathiat> \
[06:46] <daniels> i've been thinking of an X extension for different (and arguably stupid) reasons anyway
[06:46] <Lathiat> like?
[06:47] <daniels> have your compmgr hook into a vt switch event.  when switching in, fade in from black (either gamma or just tool wit hthe colourmap), when switching out, delay the switch until you've faded down to black
[06:47] <wm_eddie_> daniels, That'd be pretty cool.
[06:47] <Lathiat> daniels: heh neat
[06:47] <Lathiat> how bout a cube animation? :)
[06:48] <wm_eddie_> That'd be too Appley
[06:48] <Lathiat> apple do that?
[06:48] <Lathiat> hm ok
[06:48] <wm_eddie_> We have to take it a step further.
[06:48] <Lathiat> triangular? :)
[06:48] <wm_eddie_> Yes OS Xs fast user switching does a cube animation.
[06:48] <daniels> the most extreme example of stupidity I can think of is animating a spinning globe or something
[06:48] <daniels> where all your sessions are mapped over a sphere
[06:49] <daniels> however, if anyone actually implements that, I'll be extremely dirty at them for wasting their talent on something like that and not spending their time hacking on core X
[06:49] <wm_eddie_> What about melting off of the background session?
[06:50] <daniels> which hooks in well with the vt switch idea, since you don't need knowledge of the other user'ss session
[06:50] <wm_eddie_> If I don't win any Google bounties I'll see what I can do about that bug.
[06:50] <daniels> if you needed an image of another session, you'd have to use something like dmx
[06:50] <daniels> to which my answer is 'no'
[06:51] <daniels> unless your gdm slave could request an image of other slaves from the master
[06:51] <wm_eddie_> Eh, I'm sure the glitz powered X can do something like that easily.
[06:52] <daniels> wm_eddie_: if it includes getting images of other sessions, then the answer is no, not really
[06:52] <daniels> it won't be computationally expensive, but how do you screen-scrape another session?
[06:52] <daniels> unless you just disable all authentication, in which case you're completely screwed when someone just points a keylogger at your $DISPLAY
[06:52] <wm_eddie_> I see...
[06:55] <Lathiat> and its potentially security bad unless you know your about to switch to that display
[06:56] <Lathiat> daniels: so when do we get working glx+composite?
[06:58] <wasabi> In other words, when can the arteests start making eyecandy?
[06:58] <daniels> you can do it today with xglx
[06:58] <daniels> or xegl or whatever
[06:58] <daniels> xgl*
[06:59] <wm_eddie_> OMFG!!!!
[06:59] <wasabi> I'm not an arteest. THe problem is most arteests can't install all that crud. ;)
[06:59] <daniels> provided your compmgr is glx-based
[06:59] <wasabi> But when it's in front of them!
[06:59] <wm_eddie_> I just heard a Puerto Rican song in Japanese radio!!!!
[06:59] <daniels> david reveman demonstrated glxcompmgr at guadec
[06:59] <daniels> wasabi: well, yeah.  i'm packaging it.
[07:00] <wasabi> I'm curious... what are the long term plans for a totally GL based gfx system? I was reading some of the wishlists and stuff about running X on top of GL instead of the other way around.
[07:01] <wasabi> Are people working on that?
[07:01] <daniels> xglx is running X on top of GL
[07:01] <daniels> ditto xegl
[07:01] <wasabi> Or is it just a pleasent dream at this point?
[07:01] <wasabi> Oh.
[07:01] <daniels> it works today if you want it
[07:02] <daniels> thing is, stacks of people use render these days, and render ops are generally far far better accelerated by 3D engines (in particular all the compositing) than 2D
[07:02] <daniels> so handing off to a GL library is a big win in that case
[07:03] <wasabi> Oh I have no doubt. Having X on top of GL is the obvious good way to go.
[07:03] <wasabi> xgl runs inside of X though doesn't it?
[07:03] <wasabi> like xnest
[07:03] <daniels> pretty much the only problem with doing that is arbitration
[07:03] <daniels> wasabi: xglx does; xegl doesn't
[07:04] <Lathiat> whats xegl
[07:04] <Lathiat> like xglx but runningunder it?
[07:04] <wasabi> seems sol
[07:04] <daniels> (xgl* is a family of X servers that translate to GL calls.  glx is the gl-over-X protocol, and egl is an 'embedded GL' subset thingy.  we can plug mode switching into egl fairly easily, so the plan is to make that the API the X server relies upon.)
[07:04] <wasabi> SO how is that stack implemented? THe video vendors wil have to build differnet GL drivers that are interfacing with something else?
[07:04] <daniels> there aren't any accelerated egl drivers available to us at the moment, but we have xegl rendering to the linux framebuffer justfine
[07:04] <daniels> the vendors will have to supply egl drivers, right
[07:04] <daniels> which isn't too difficult
[07:06] <wasabi> Interesting. So egl is the base graphics framework, and there would be... for instance, an xorg driver for it?
[07:06] <wasabi> Or would it be totally different than that.
[07:07] <Lathiat> nice im on 91% and acpi predicts 5h5m battery left
[07:07] <Lathiat> with bt, 802.11 and music playing
[07:07] <daniels> wasabi: an X server layered on EGL, yes
[07:08] <daniels> wasabi: so instead of having radeon_drv et al, we just have an EGL driver
[07:08] <wasabi> That really sounds like such an ideal design, etc.
[07:08] <Lathiat> daniels: so the question is
[07:08] <Lathiat> if im running a s3 trio
[07:08] <daniels> wasabi: this lets the vendor provide a completely binary driver if they want.  there's one argument that says this is great, because everyone will do it.  there's one argument that says this is absolutely terrible, because everyone will do it.
[07:08] <wasabi> You could have gdm basically do fast user switching between different X server instances on VTs by rotating the cube the X servers are on.
[07:08] <Lathiat> will this be slower?
[07:08] <daniels> Lathiat: in that case, you hang back on the xorg server
[07:09] <Lathiat> daniels: right
[07:09] <Lathiat> is Xgl part of xorg?
[07:09] <wasabi> The vendors will come in line wiuth the open source thing on their own.
[07:09] <wasabi> No reason to force their hand.
[07:09] <wasabi> That is, if we really believe it's better.
[07:09] <daniels> Lathiat: right now, it's not
[07:09] <daniels> Lathiat: we're working towards much greater codebase parity though
[07:09] <wasabi> If it's not better, then I wouldn't ask them to. ;)
[07:09] <daniels> (modularisation will help us a *lot* here)
[07:10] <Lathiat> daniels: is it based on xorg?
[07:10] <Lathiat> or xfree?
[07:10] <daniels> wasabi: given the extreme reluctance every vendor is now displaying to do open source (intel probably being the least reluctant), this is a terrible thing
[07:10] <daniels> wasabi: closed drivers for every card is a nightmare
[07:10] <daniels> Lathiat: closer to kdrive than anything
[07:10] <Lathiat> daniels: ahh ok
[07:10] <wasabi> Well, I personally think that people will choose foss because it is simply a better system.
[07:10] <wasabi> Market forces, etc, yadda yadda.
[07:11] <Lathiat> they should be foss
[07:11] <wasabi> obviously it will be fought tooth and nail, like everyting.
[07:11] <Lathiat> but have code like the nv driver in xorg
[07:11] <wasabi> ANd ti will suck until they get on board.
[07:11] <wasabi> But they will.
[07:11] <daniels> Lathiat: not if it involves their 3D engine, they won't
[07:11] <daniels> wasabi: i'm not convinced they will
[07:11] <wasabi> daniels, im talking over the course of Many Years.
[07:11] <daniels> wasabi: some vendors who were previously very keen on open source are now retreating back into their proprietary shell as quickly as they can
[07:12] <daniels> wasabi: we're designing an X server for next year
[07:12] <wasabi> There are still many people, a vast majorty I would say, who don't like Linux itself because it's open source.
[07:12] <daniels> wasabi: if I have to endure 5 years of binary-only drivers to get a win, then screw that
[07:12] <wasabi> heh.
[07:12] <daniels> if that's the case, there's a whole class of us who will just keep on maintaining Xorg until there are free EGL drivers
[07:13] <wasabi> I think that when Linux becomes main stream. When we have a product that people EXPECT to work.
[07:13] <wasabi> The vendors will be forced to make that happen.
[07:13] <wasabi> And the only way they'll be able to, is by playing nice.
[07:13] <Lathiat> it'l be all about vendors
[07:13] <Lathiat> then
[07:14] <wasabi> IT's never about vendors.
[07:14] <wasabi> It's about users.
[07:14] <Lathiat> we'll lose the hackers cus open source wont be minority or fun anymore :)
[07:14] <wasabi> Well. Heh.
[07:14] <wasabi> I dunno.
[07:14] <wasabi> I can't predict that. Either all teh FOSS guys will jump ship... for hurd...
[07:14] <wasabi> ANd Linux will turn corporate. ;)
[07:14] <wasabi> Or not.
[07:15] <Lathiat> hurd ;p
[07:15] <Lathiat> heh
[07:15] <Lathiat> well im off
[07:15] <Lathiat> tofix some stupid computer 
[07:15] <daniels> the only thing that keeps some vendors with tiny bits of nominally open source drivers is that most distributors flat-out refuse to distribute proprietary drivers, at least in their default set
[07:16] <wasabi> We're a massive minority right now.
[07:16] <daniels> sure
[07:17] <wasabi> And we're not going away.
[07:17] <daniels> but I guarantee you that if Ubuntu, RHEL/Fedora, et al, all said 'we'll distribute proprietary drivers in our default set', the free drivers would vanish from the vendor radar
[07:17] <wasabi> Short term I'd agree.
[07:17] <wasabi> But at the same time, there is a reason people use Linux and not *insert closed source OS here*
[07:18] <wasabi> I mean, I hope there is.
[07:19] <wasabi> I have a firm belief that if we can't win on our own merit, we don't desearve to win.
[07:20] <maswan> well, you know, in the server space, drivers are already happening, with a few exceptions
[07:20] <maswan> because there it isn't as much a vocal minority as a significant part of the market
[07:20] <wasabi> Anybody aware of the eepro/e100 driver deal?
[07:20] <wasabi> I'm curious about that one.
[07:21] <maswan> what regarding it?
[07:21] <wasabi> eepro existed, then e100 came into being.
[07:21] <maswan> yeah
[07:21] <wasabi> Looked like one was a community effort, the other was official.
[07:21] <maswan> one was becker's driver, the other was intel
[07:21] <maswan> 's
[07:21] <wasabi> Why did Intel do that?
[07:22] <daniels> elmo: x11proto-* -> main please
[07:22] <maswan> because becker writes drivers quickly, but not always the best possible. at least in our experience
[07:22] <daniels> elmo: (xorg b-d)
[07:22] <wasabi> Yeah but what made intel give the source vs just releasing a binary only driver?
[07:22] <wasabi> I think that's a rhetorical question.
[07:22] <daniels> the fact rhel wouldn't distribute it if it was a binary-only driver?
[07:22] <maswan> Well, probably clue. :)
[07:23] <fabbione> hey maswan 
[07:23] <wasabi> daniels, thank god for the redhats of the world then, right?
[07:23] <maswan> hi there
[07:23] <grover> well....
[07:24] <maswan> wasabi: I think that in our experience, we're grateful that becker wrote drivers for network cards, we just wish they had been more solid and less buggy. :)
[07:24] <fabbione> maswan: you tell me when you are awake enough to setup the buildd :)
[07:24] <maswan> fabbione: want more stuff?
[07:24] <maswan> I am
[07:24] <fabbione> maswan: well i need some packages and some sudo rights
[07:24] <daniels> (also, the kernel guys deliberately don't expose a stable ABI, so attempting to provide a binary driver is far, far mroe difficult in that case)
[07:24] <grover> open sourcing lowers maintenance burden, since the community can proactively fix stuff
[07:24] <fabbione> maswan: ok let me find all the stuff we need :)
[07:24] <wasabi> Just make sure to keep EGL rotating. ;)
[07:24] <maswan> fabbione: ok. what do you need?
[07:25] <daniels> grover: however, in reality, the number of people who can, say, fix an SMP-related deadlock in radeon DRM/DRI, is pretty low
[07:25] <fabbione> maswan: looking at the overall :)
[07:25] <maswan> grover: having drivers in the kernel.org tree means less chance of changes breaking it
[07:25] <grover> daniels: true, nice drivers are simpler
[07:25] <grover> nic driver
[07:25] <grover> s
[07:26] <stockholm> ogra: hi!
[07:26] <wasabi> I dunno. I think there'sa  reason FOSS is growing as fast as it is.
[07:27] <wasabi> It doesn't just give a warm fuzzy feeling.
[07:27] <grover> it's free? :)
[07:27] <wasabi> It's doing something right.
[07:27] <wasabi> Maybe that's it.
[07:27] <wasabi> But it's actually GOOD. ;)
[07:28] <wm_eddie> gah WTF is updatedb running now...
[07:29] <wm_eddie> I still can't beleive I heard a Puerto Rican song on Japanese radio...
[07:32] <daniels> mdz: -25 uploaded
[07:36] <daniels> elmo: (libx11-dev and libx11-6 need to be in main also, but they already have binary overrides)
[07:37] <wm_eddie> I think the next couple of years is going to be the second open-source explosion.
[07:46] <wm_eddie> With Mandrake turning into one big MegaDistro, Novell pushing Mono, RedHat with their mad X magic, and Ubuntu doing things the way they should be done.  It's just a matter of time before critical-mass.
[08:18] <pitti> Moins moins
[08:20] <wm_eddie> Crap, major security holes in Sun Java :(
[08:21] <\sh> *grmpf*
[08:21] <\sh> what was the common fix for this error message?
[08:21] <\sh> g++-4.0.gcc-opt: ../intl/libintl.a: No such file or directory
[08:21] <\sh> on amd64/ia64
[08:26] <doko> b-d on getttext?
[08:28] <\sh> yepp
[08:28] <\sh> and I tried gettextize -f -c 
[08:33] <\sh> ah...una momenta..
[08:34] <\sh> this looks good
[08:42] <jdub> daniels: still can't enter text :-)
[08:45] <robitaille> jdub,  the news on the right-hand side of planet.u.c seem a bit confused since the wiki conversion
[08:45] <jdub> robitaille: hmm
[08:47] <jsgotangco> NEWS: CD does not boot
[08:47] <jsgotangco> nice
[09:41] <pitti> Kamion: would it be totally evil if the Kubutu installer installed kde-i18n-<lang> in addition to language-support-<lang>? otherwise I had to create a l-support-kde-<lang> which just depends on kde-i18n-<lang>, which would add another ~80 packages to the archive
[09:42] <pitti> Kamion: it is trivially easy to generate the kde-support packages (in fact I have to disable that actively), but I don't want to make elmo cry
[09:55] <\sh> gentlemen, i would like to point to this mailing http://article.gmane.org/gmane.linux.ubuntu.devel/8094 and if -devel is the right place to ask this. do we have a common ubuntu solution?
[10:04] <mvo> is it possible to add comments to a task in malone (not to the bug itself, but the "needs fixing in ..." bits)?
[10:15] <Kamion> <cjwatson@cairhien ~/src/ubuntu/cdimage/debian-cd/data/breezy/preseed/kubuntu>$ grep patterns kubuntu.seed
[10:15] <Kamion> base-config     base-config/language-pack-patterns      string language-pack-$LL kde-i18n-$LL
[10:15] <Kamion> pitti: it already does :)
[10:15] <Kamion> (with language packs, rather than language support packages)
[10:15] <pitti> Kamion: oh, neat
[10:15] <pitti> Kamion: the plan is to pull the translations out of kde-i18n-<lang> and into language-pack-kde-<lang>
[10:16] <pitti> Kamion: so the remaining contents of kde-i18n-<lang> will be translated documentation, which is rather support-ish
[10:16] <fabbione> hey Kamion 
[10:16] <fabbione> hi pitti
[10:16] <pitti> Hey fabbione 
[10:16] <Kamion> pitti: I can install them with support instead, sure
[10:16] <fabbione> Kamion: i figured the pcmcia thingy.. it was bong.. there was a pcmcia-storage-modules for it :)
[10:16] <Kamion> might involve a couple of lines of code, but nothing new or exciting
[10:16] <pitti> Kamion: ok, fine. I ping you back if that change is actually done
[10:16] <Kamion> fabbione: ah yes
[10:16] <Kamion> pitti: cool
[10:17] <pitti> s/if/when/ :-/
[10:17] <fabbione> Kamion: yeah.. cleaning the all is a pain, but it's coming nice and dandy :)
[10:17] <Kamion> let's see how broken today's CD is ...
[10:17] <fabbione> Kamion: before upload i will push you the changes so you can take a look
[10:36] <\sh> guys, why does my package compile normally on amd64 and i386 but not on the buildd's?
[10:36] <pitti> build-depends?
[10:36] <\sh> no
[10:36] <Kamion> what package?
[10:36] <\sh> sdcv
[10:37] <\sh> i tested it on a adm64 box, and it compiled without problems, on my i386 box as well
[10:37] <Kamion> it's trying to run stuff like gettextize during the build, which it really shouldn't; that's a maintainer tool
[10:38] <Kamion> timestamp issues on files in the source package?
[10:38] <Kamion> make sure that your tests involve unpacking the source package, rather than just copying the build tree around
[10:38] <\sh> Kamion: if I'm not running it, i386 would compile , not no 64bit archs...
[10:38] <Kamion> and if you're running gettextize in the build, don't
[10:39] <Kamion> similarly aclocal and automake
[10:39] <\sh> s/not no/but no/
[10:40] <\sh> Kamion: so u mean better to make a patch out of it? takin orig source, gettextize, aclocal etc., taking the diff and put it as patch?
[10:41] <Kamion> that sort of stuff should really be in the upstream source package, but if it isn't, then yes it should be part of the .diff.gz
[10:41] <Kamion> I don't care which patch system or none you use :)
[10:42] <\sh> ok..then i will try it the other way around ;)
[10:53] <bob2> go muine
[10:53] <bob2> when you pause it, it consumes 100% cpu
[10:53] <Treenaks> bob2: nice
[10:53] <Treenaks> bob2: sounds appropriately .NETish
[10:55] <stockholm> ogra: ?
[11:07] <stockholm> when is ogra awake?
[11:07] <Treenaks> stockholm: usually about now
[11:07] <stockholm> (c:
[11:08] <stockholm> ok
[11:21] <koke_> hi all!
[11:22] <koke_> hey, what do you think about http://koke.amedias.org/img/ooo-splash-ubuntu.png ??
[11:30] <wm_eddie> It'd be better without the blue "Office" 
[11:33] <mvo> hey seb128 
[11:34] <seb128> hi mvo
[11:43] <pitti> elmo: ping
[11:52] <pitti> mvo: do you see any problem with adding two new colums "KDE translations" and "Gnome translations" to the langpack selector?
[11:53] <pitti> Riddell: here?
[11:53] <mvo> pitti: not really, might be better to automatically install them depending if kde/gnome is installed
[11:54] <mvo> what do you think? or is this impractiacal?
[11:54] <pitti> mvo: well, the installer will install them for your primary language
[11:54] <pitti> mvo: but not for additional languages you might want
[11:54] <pitti> mvo: it's the same as with the normal language-pack-<lang>
[11:55] <pitti> mvo: in the future there will be l-pack-gnome-<lang>[-base]  and l-pack-kde-<lang>[-base]  in addition
[11:55] <mvo> yes, I was thinking that if the user selects "translation" and has gnome installed we may just automatically install the language-pack-gnome-<lang> (same for kde of course)
[11:55] <pitti> mvo: ah, right, that's even better
[11:56] <pitti> mvo: hm, but there should still be an interface of any kind; the user might want translated KDE apps he uses under Gnome
[11:58] <Riddell> mvo's idea sounds good
[11:58] <mvo> pitti: how many packages does the langpack for kde cover? I assume there is a list? language-detector could use that list to deciede if it needs to install the langpack. 
[11:58] <pitti> Riddell: since the new langpack-o-matic works now, are you fine with stripping the kde-i18n-<lang> packages now?
[11:58] <mvo> I mean, adding a column for gnome/kde is no problem, I'm just playing around with ideas
[11:59] <pitti> mvo: well, right now only 3 apps, but that'll change if we actually strip kde-i18n-xx
[11:59] <mvo> pitti: what about gnome? how many apps there?
[11:59] <pitti> mvo: maybe the Gnome/KDE colum is automatically selected if you check translations and are under Gnome/KDE?
[11:59] <Riddell> pitti: stripping kde-i18n-<lang> seems good
[12:00] <pitti> mvo: 99 apps for de ATM
[12:00] <pitti> mvo: (gnome)
[12:01] <pitti> Riddell: ok, then I upload a new pkgstriptranslations without the KDE blacklist, pester infinity to install it, and then ping you to reupload kde-i18n again?
[12:01] <Riddell> pitti: ok
[12:01] <mvo> pitti: could you please send both lists to me? 
[12:01] <pitti> mvo: yes
[12:02] <Riddell> mvo: the kde langpack covers a lot of packages, there's no list (a list of course packages would be easy, list of binary packages longer)
[12:02] <pitti> mvo: for all languages, or is .de as example enough?
[12:02] <mvo> pitti: does the list vary for different languages?
[12:02] <pitti> mvo: I only have a list of translation domains per language, not per application or deb
[12:03] <pitti> mvo: so if there is a German translation for rhythmbox, but not a Spanish one, it would differ
[12:03] <mvo> ah, I see. this makes things more complicated certainly. please send me the german one as a start then
[12:03] <mvo> if we have no mapping pkg<->translation domain :/
[12:04] <pitti> mvo: oh, I have such a mapping, it's generated during import
[12:04] <pitti> mvo: ah, you mean you want to install the langpack if the user has any such app installed?
[12:04] <mvo> pitti: yes
[12:04] <pitti> mvo: great idea :-)
[12:04] <mvo> :-D
[12:04] <pitti> mvo: however, the list will change since there are still some stripping issues
[12:05] <pitti> mvo: http://people.ubuntu.com/~pitti/de-gnome.txt  http://people.ubuntu.com/~pitti/de-kde.txt  http://people.ubuntu.com/~pitti/de-main.txt
[12:05] <mvo> pitti: that shouldn't be a problem as long language-selector is updated regularly
[12:06] <pitti> mvo: it won't change any/much more close before the release; I think updating the map in l-s is doable right before the release
[12:07] <mvo> pitti: is the mapping pkg<->domain available somewhere too?
[12:07] <pitti> mvo: http://people.ubuntu.com/~pitti/domain_map.txt
[12:07] <pitti> mvo: that is a symlink to langpack-o-matic, i. e. updated automatically
[12:10] <mvo> pitti: thanks
[12:11] <Mithrandir> smurfix: is your smurflogbot a bit sick? :-)
[12:11] <ogra> heh
[12:11] <smurfix> Mithrandir: It's OK now
[12:11] <smurfix> It managed not to log to the right files :-/
[12:13] <jsgotangco> heh
[12:19] <fabbione> smurfix: why are logging the same chans i do?
[12:19] <fabbione> i think it's a bit pointless :)
[12:19] <smurfix> fabbione: cause I missed that
[12:20] <fabbione> ehhe ok
[12:20] <smurfix> fabbione: which channels *are* you logging?
[12:20] <smurfix> I'll take mine off them
[12:20] <fabbione> smurfix: a sec...
[12:20] <tseng> is it safe to update all this x stuff?
[12:20] <fabbione> i need to check
[12:41] <pitti> Hey jbailey 
[12:41] <pitti> jbailey: btw, do you plan to upload a new glibc soon? maybe we can fix the gettext lookup then
[12:42] <pitti> infinity: do you have some minutes for me?
[01:09] <jbailey> pitti: I can do that next week.  I have some high priority tasks for this week.
[01:16] <Lathiat> daniels: remind me, why is middle click with 2 buttonsdisabled by defualt?
[01:46] <sandip> My heartfelt thanks to Canonical for shipping 5.04 over to my place for distributing to my local LUG. :) ... to New Delhi, India.
[01:50] <pitti> erm, jbailey?
[01:50] <jbailey> pitti: yess'r?
[01:50] <pitti> jbailey: is there a reason why amd64 and ia64 don't have gettext in libc?
[01:50] <jbailey> umm, what?
[01:51] <pitti> jbailey: I banged my head about the question why some stripped translation tarballs are broken
[01:51] <jbailey> Is this recent breakage or has always been this way?
[01:51] <pitti> jbailey: I found out that (some?) amd64 and ia64 builds don't install translations, but powerpc and i386 do
[01:51] <pitti> jbailey: that is broken for quite some time now
[01:52] <jbailey> oh good.  I was worried that you were saying that I had broken it recently with one of the uploads. =)
[01:52] <jbailey> Lemme check on it in a moment.
[01:52] <Keybuk> ok, hct is working again now
[01:53] <pitti> jbailey: if any 64 bit platform finishes a build as the last one, the stripped tarball is broken
[01:53] <sabdfl> Keybuk: w00t :-)
[01:53] <Keybuk> database was wedged up its jacksie with no useful errors
[01:53] <Keybuk> stub hit it with a wrench
[01:55] <pitti> seb128: I finally found the reason for the b0rked translation tarballs :-)
[01:55] <seb128> oh ?
[01:55] <pitti> seb128: yes, it's not a pkgstriptranslations bug after all, but a libc problem on 64 bit platforms, as it seems
[01:56] <pitti> seb128: depending on whether a 32 or 64 bit platform buildd finished last, we get a correct or broken tarball
[01:56] <seb128> k
[02:06] <Kamion> sandip: you're welcome; share the love. :-)
[02:29] <thom> mvo: seen:
[02:29] <thom> debconf: unable to initialize frontend: Gnome
[02:29] <thom> debconf: (Can't locate object method "new" via package "Text::Iconv" (perhaps you forgot to load "Text::Iconv"?) at /usr/share/perl5/Debconf/Encoding.pm line 57, <> line 24.)
[02:29] <thom> ?
[02:29] <thom> or Kamion, either
[02:30] <Kamion> debconf-i18n unconfigured?
[02:30] <mvo> thom: not seens yet, when does it happens?
[02:30] <Kamion> it Depends: libtext-iconv-perl
[02:30] <Kamion> is this during an upgrade?
[02:32] <thom> Kamion: during an upgrade, yes. but debconf was upgraded a while ago
[02:32] <thom> ie, this has been happening for some days
[02:34] <thom> and no, debconf-i18n is fully installed
[02:35] <thom> ah
[02:35] <thom> libtext-iconv-perl appears not actually contain Text/Iconv.pm
[02:35] <thom> that might explain it
[02:36] <Kamion> !
[02:36] <Kamion> b0rked b0rked b0rked
[02:36] <Kamion> seems fine in the archive
[02:37] <Kamion> thom: arch?
[02:37] <pitti> seb128: it should be fixed in the most recent version?
[02:37] <Kamion> oh, it's just on amd64
[02:37] <Kamion> B0RKED
[02:37] <Kamion> thom: I'll sort it out
[02:38] <seb128> pitti: the current version has some regression 
[02:38] <thom> Kamion: oh, rocking. thanks
[02:38] <pitti> another one?
[02:38] <seb128> pitti: "find ./ -regex '.*\.so\..?.?$'" used to work, it doesn't
[02:38] <thom> and yes, was just updating my i386 chroot to see if it occured there
[02:39] <seb128> pitti: doesn't seems to like the ".?"
[02:40] <Keybuk> seb128: hct source gdm
[02:40] <Keybuk> enjoy
[02:40] <Kamion> ah, I think libtext-iconv-perl/amd64 was caught by the perl MakeMaker bug
[02:40] <Keybuk> (it was imported after all, there was a missing publishing record so hct couldn't see it)
[02:41] <seb128> Keybuk: thanks (I've just reworked gdm without it yesterday, but I'll find something else to play :p)
[02:41] <Keybuk> bah :p  I just spent the last two hours debugging that for you <g>
[02:41] <seb128> I've waited for a few weeks
[02:42] <Keybuk> true
[02:42] <Keybuk> that was a fucking strange bug ;)
[02:42] <seb128> I didn't though it would be fixed today
[02:43] <seb128> Getting gdm_2.6.0.7.orig.tar.gz
[02:43] <seb128> it works :)
[02:43] <pitti> ^ for breezy?
[02:43] <HiddenWolf> bug#?
[02:44] <Kamion> thom: no-source-changes rebuild uploaded, should sort it out
[02:45] <thom> what was the MakeMaker issue?
[02:45] <thom> thanks
[02:45] <seb128> pitti: what?
[02:45] <pitti> seb128: so far I thought hct would only get you hoary packages
[02:46] <seb128> gdm has not changed since hoary
[02:46] <seb128> dunno which one is that
[02:47] <Kamion> thom: Debian bug #312419
[02:48] <seb128> grumpf, gdm picks /usr/X11R6/include instead of /usr/include ... anybody if that's xorg to blame?
[02:48] <Lathiat> blame daniels 
[02:48] <Lathiat> so.. why did gnome remove the run application menu item
[02:48] <fabbione> seb128: mostlikely :)
[02:48] <infinity> seb128 : Which buildd (or were all build broken)?
[02:49] <thom> ah, ouch
[02:49] <thom> Kamion: thanks
[02:49] <lbm> breezy kernels != inotifized?
[02:49] <Keybuk> pitti: I, uh, copied a breezy publishing record <g>
[02:49] <fabbione> lbm: 2.6.12 has inotify
[02:49] <ogra> lbm, what makes you think this ?
[02:50] <seb128> infinity: trying to build a new gdm on my box
[02:50] <lbm> ogra: 2.6.10 doesn't seem to include it
[02:50] <fabbione> lbm: inotify in 2.6.10 is dangerous
[02:50] <ogra> lbm, breezy will user 2.6.12
[02:50] <ogra> use even
[02:50] <fabbione> lbm: you can use it at your own risk
[02:50] <fabbione> lbm: adding inotify as boot options
[02:51] <fabbione> lbm: but be aware.. it's disabled for a very good reason..
[02:51] <fabbione> lbm: wrong operation = crash
[02:51] <lbm> fabbione: oh, maybe i should just give 2.6.12 a try? (do i need inotify boot parm for that one too?)
[02:51] <Keybuk> pitti: I've asked the Soyuz guys to do another gina run against breezy, though not sure what their ETA is (there's a refactor going on)
[02:51] <seb128> the config.log has
[02:51] <seb128> | #include <X11/Intrinsic.h>
[02:51] <seb128> configure:21246: result: libraries /usr/X11R6/lib, headers /usr/X11R6/include
[02:51] <fabbione> lbm: if you are running breezy yes.. you can use and test .12, and inotify is enabled by default
[02:52] <lbm> fabbione: is it, in breezy lingo, fairly stable?
[02:52] <fabbione> lbm: just keep in mind that 2.6.12 is not final upstream yet.. it's a release candidate
[02:52] <lbm> sure
[02:53] <fabbione> lbm: i am using it.. since a while.. i know for sure ipw2100 is broken (due to some upstream problems)
[02:53] <fabbione> lbm: but i am not aware of other big issues
[02:53] <lbm> i need ipw2200
[02:53] <fabbione> ipw2200 is ok.. or should be
[02:53] <fabbione> i don't own that hardware..so i can't really say
[02:54] <lbm> so restricted modules is packaged for 2.6.12 too, perfect
[02:54] <fabbione> no
[02:54] <fabbione> there is no l-r-m
[02:54] <ogra> lbm, it might wipe your HD or elope with your girlfriend, but for most people it ran stable until now
[02:54] <lbm> ogra: last time i tried (mid-hoary-dev-cycle) it ran fairly stable :)
[02:54] <fabbione> lbm: we might do l-r-m as soon as 2.6.12 will be final upstream
[02:55] <lbm> fabbione: isn't ipw* part of l-r-m?
[02:55] <fabbione> lbm: spending too much time during the devel cycle is not worth
[02:55] <fabbione> lbm: nope.. it's a GPL driver
[02:55] <fabbione> and it is part of main
[02:55] <fabbione> + kernel
[02:55] <lbm> what about the firmware?
[02:56] <fabbione> lbm: it will work.. trust me
[02:56] <fabbione> lbm: btw.. where do you live in dk?
[02:56] <fabbione> <- copenhagen
[02:57] <lbm> fabbione: i live in the northern part, close to aalborg :)
[02:57] <fabbione> we should try to get some .dk people for an ubuntu beer
[02:57] <fabbione> ah ok
[02:57] <fabbione> a bit far ...
[02:57] <lbm> fabbione: indeed
[02:57] <fabbione> i used to live in Aarhus
[02:57] <lbm> fabbione: no, denmark is a small country, 4 hours and i'll be with you :)
[02:57] <fabbione> lbm: i know.. i lived here in dk for 5 years now
[02:58] <lbm> i will move to aarhus later this year, great city don't you think?
[02:58] <fabbione> i just don't *cough*speak*cough danish
[02:58] <lbm> fabbione: study?
[02:58] <lbm> :)
[02:58] <fabbione> lbm: no.. work
[02:58] <fabbione> and family
[02:58] <lbm> it will come
[02:58] <lbm> okay, may i ask where?
[02:58] <fabbione> yeah i am starting lessons the 1st of Aug
 <- copenhagen
[02:59] <lbm> i was asking about your employer
[02:59] <lbm> :)
[03:00] <fabbione> lbm: you can happily zless /usr/share/doc/linux-source-2.6.10/changelog.Debian.gz
[03:00] <fabbione> ;)
[03:00] <ogra> hehe
[03:00] <Kamion> "where" is not a good question to ask when trying to find out who employs somebody around here :)
[03:01] <fabbione> Kamion: point :)
[03:01] <lbm> fabbione: hehe :)
[03:01] <ogra> hmm, is there a reason we dont have python-mathml packaged ?
[03:01] <ogra> and hydra ?
[03:01] <lbm> oh, firmwares are included in the kernel image package
[03:02] <lbm> fabbione: you moved to denmark because of family?
[03:02] <fabbione> lbm: kinda...
[03:02] <fabbione> i never hide that she was blonde :)
[03:02] <fabbione> but i am now married with a brunette ;)
[03:03] <lbm> fabbione: hehe, we have great girls don't you think? :)
[03:04] <fabbione> lbm: eheheh :)
[03:04] <fabbione> anyway.. back to more important stuff
[03:04] <lbm> fabbione: ;)
[03:04] <lbm> always nice meeting danes
[03:04] <fabbione> lbm: Aarhus is a nice city.. a bit too small for my taste
[03:04] <lbm> let me give 2.6.12 a try
[03:04] <fabbione> lbm: well. i am italian :)
[03:04] <fabbione> don't confuse here, eh? ;)
[03:05] <lbm> fabbione: i like the size
[03:05] <lbm> fabbione: irc is messy :)
[03:05] <fabbione> lbm: it's ok really.. you can have a lot of fun there
[03:05] <lbm> fabbione: great city life i think
[03:05] <ogra> new
[03:13] <tseng> elmo: did muine go into new (new binaries)? it built, but isnt on archives
[03:25] <lamont> daniels: you awake?
[03:25] <lamont> libx11 Build-Depends: pkgconfig
[03:25] <pitti> Hi lamont
[03:28] <infinity> lamont : It's more broken than that, I've been hunting.
[03:28] <infinity> lamont : Even if I get all the missing build-deps in (pkg-config x11proto-kb-dev x11proto-input-dev), it's still broken. :)
[03:29] <pitti> Hi infinity
[03:29] <Simira> hi JaneW 
[03:47] <Kamion> thom: libtext-iconv-perl_1.2-4build1_amd64.deb confirmed fixed
[03:48] <thom> Kamion: rocking
[03:55] <infinity> lamont : Eureka.  Looks like I've got it all fixed.
[03:57] <robertj> hrmm, I've got a program that is giving me main.c:89: error: DBUS_INTERFACE_ORG_FREEDESKTOP_DBUS undeclared (first use in this function)
[03:57] <robertj> I downloaded the latest dbus and installed it, but I'm still getting that error, do I have to tell it to use the local one?
[03:59] <pitti> robertj: interesting, I didn't know that xchat can display inverse text :-)
[04:00] <robertj> me neither
[04:00] <robertj> I just copied and pasted from OS X terminal
[04:00] <robertj> (still can't get dual head to work on my machine at work :(
[04:00] <mvo> robertj: what program is complaining?
[04:00] <robertj> avahi
[04:00] <seb128_> your software is not updated for the current API probably
[04:01] <robertj> seb128_: ok, so I probably need to regress instead of progress eh?
[04:01] <robertj> it threw that same error with the breezy version
[04:01] <seb128_> better to update your software
[04:02] <robertj> seb128: I'm running avahi from svn and last night's release of dbus
[04:02] <seb128_> yeah, update the code of your software for the new dbus
[04:03] <robertj> hehe, a slightly bigger task than I wanted to chew on ;)
[04:03] <jdong> is it ok for KDE Backports to be compiled against Kubuntu's new hoary-updates 3.4.1 repo?
[04:04] <jdong> I assume amarok users would be using Kubuntu, and since the 3.4.1 is an official Kubuntu.org repo, it'd be ok
[04:04] <tseng> it sounds like you would have to widely document that
[04:04] <tseng> since i dont think hoary-updates is enabled for default installs
[04:05] <JaneW> Simira: hi
[04:07] <Riddell> jdong: compile it against KDE 3.4.0 then it'll work for everyone
[04:08] <jdong> ok, thanks
[04:17] <skora> ick.
[04:17] <skora> trollers posting links to goatse in the main channel....meh.
[04:18] <sivang> wheeee! we switched back to moin?
[04:18] <tseng> yes, it rocks.
[04:18] <sivang> tseng: since when?
[04:18] <tseng> since a few days ago
[04:19] <sivang> tseng: did you notice the performance boost ?
[04:19] <tseng> yes
[04:19] <tseng> its huge
[04:19] <tseng> and the theme looks much cleaner as well
[04:20] <sivang> tseng: oh that's so cool, who the person to bless for?
[04:20] <lamont__> g'morning
[04:20] <tseng> sivang: some guy i never heard of before, he posted to -devel
[04:21] <sivang> tseng: about that he made moin work inside plone/zope ? I mean, sure;ly there has been some porting to do..
[04:21] <tseng> beats me
[04:21] <sivang> tseng: well, it's just cool,. I'll go look for that thread
[04:23] <sivang> morning lamont__ , 'sup?
[04:25] <Kamion> infinity: is "sentinal" meant to be misspelt that way? (x11proto-core)
[04:27] <infinity> Kamion : No, I just can't spell.  It's correct in the source, broken in my changelog. :)
[04:28] <infinity> The next person to touch the changelog is welcome to fix my typos. :)
[04:28] <infinity> (But the package is fine)
[04:28] <pitti> infinity: is the quick fix for rescuing langpacks possible?
[04:29] <infinity> pitti : ... Did I miss a conversation?
[04:29] <Nafallo> tseng: what's up with muine?
[04:29] <pitti> infinity: it's in the email
[04:30] <tseng> Nafallo: i duno
[04:30] <tseng> Nafallo: it built, its not in the archive
[04:30] <infinity> pitti : One sent to me? :)
[04:30] <infinity> pitti : If so, I probably stupidly deleted it in a rage of spam-killing.
[04:30] <Nafallo> tseng: and no buildlogs either (amd64)
[04:31] <tseng> well it isnt set for amd64 or something
[04:31] <elmo> tseng: why are the plugins split out like this?
[04:31] <Nafallo> tseng: I built it myself and that works.
[04:31] <tseng> elmo: because thats how the debian developer did it
[04:31] <tseng> elmo: the trayicon plugin isnt installed by default by the makefile
[04:31] <elmo> gar
[04:31] <tseng> and the inotify one I just followed along
[04:32] <tseng> there are a bunch of external plugins
[04:32] <pitti> infinity: i bounce it back to you
[04:32] <Nafallo> tseng: I get segfaults with that plugin enabled ;-)
[04:32] <Nafallo> tseng: trayicon that is
[04:32] <elmo> tseng: there's a small (but x 15000 and it adds up) cost to adding extra packages, there needs to be a good reason to do it
[04:32] <pitti> infinity: bounced; "Subject: Found the reason of broken translation tarballs"
[04:32] <elmo> if a plugin package comes from upstream source and doesn't have any extra depends, I'm unclear why it's in a separate binary package
[04:33] <tseng> when i was doing the package locally i made it in the same binary
[04:33] <elmo> tseng: also, debian doesn't seem to have any muine-plugin packages despite having 0.8.3-1?
[04:33] <tseng> it was uploaded to unstable split up
[04:33] <tseng> its in NEW
[04:33] <elmo> ah, they're in NEW; I suspect/hope an ftp-master will reject it
[04:34] <infinity> pitti : I'm betting the current scheme just does an scp of the tarball without looking.  I'd have to wrap that to do filesize checking.
[04:34] <jvw> depends on which camp has the most interesting offer...
[04:34] <infinity> pitti : WOuld it hurt terribly to wait on getting it fixed properly?
[04:35] <tseng> elmo: k
[04:36] <tseng> elmo: i tend to follow the debian way as closely as possible, i can put it back together no problem
[04:36] <elmo> tseng: don't get me wrong, following debian is a good default - I'm not criticising you, it's their bad split
[04:36] <infinity> pitti : Another quickfix option is to encode the $ARCH in the tarball filename, so we get 4 instead of 1 and you can pick and choose.
[04:37] <elmo> tseng: for now, if you could put them back, I'd appreciate it - if it goes into Debian split like it is, feel free to then follow them
[04:37] <tseng> elmo: k.
[04:37] <pitti> infinity: well, the langpacks are broken with that and the later we fix it, the later we need to recompile half of the archive
[04:37] <pitti> infinity: alternatively, would it hurt to just take i386 and ppc tarballs for now?
[04:38] <pitti> infinity: I doubt that there are many ia64/amd64 specific pacakges with translations
[04:38] <pitti> infinity: the $ARCH option would be a possible workaround, too
[04:39] <Kamion> there are a few such in the installer, but they don't count
[04:42] <infinity> pitti : Well, that would be on your end. :)
[04:44] <pitti> infinity: *grumpf*, okay, fixing my scripts shouldn't be too hard :-)
[04:49] <ogra> Riddell, ping
[04:54] <Riddell> ogra: hi
[04:54] <ogra> Riddell, 3 probs in ivman
[04:54] <Riddell> ogra: ok
[04:55] <ogra> Riddell, missing build-deps on libxml2-dev and on libhal-dev, and you got a spare ${misc:Depends} in the control file
[04:55] <ogra> Riddell, if you solve these, the package is fine, nice work :)
[04:55] <Riddell> ogra: cool, thanks
[05:00] <Riddell> ogra: you missed that it was build-depping on build-essential and the section shouldn't be kde :)
[05:01] <ogra> Riddell, ouch, true
[05:02] <infinity> build-dep on build-essential?
[05:02] <infinity> How... Odd.
[05:02] <Riddell> infinity: wasnae me, the cdbs control generation did it
[05:02] <jbailey> infinity: There's some nasty crack that snuck in between uvf and us sync'ing it again. =(
[05:03] <jbailey> Anyone feel free to upload it (here or in Debian) to remove that build-dep...
[05:07] <Duck_work> jbailey: synced in svn somewhere ?
[05:07] <jbailey> Duck_work: I'll merge it to svn sometime after to do a mop up.
[05:08] <jbailey> Duck_work: I get a nice diff of what's changed between Debian and Ubuntu's packages, so when I sync them, I can see which bits really want to make their way back to Debian.
[05:08] <jbailey> Ubuntu inherits the changes from Debian quite easily.
[05:09] <Duck_work> jbailey: ok, so you'll do the doc sync by yourself in a natural way ?
[05:09] <jbailey> Duck_work: Yup, if you upload it into the Debian package no prob.
[05:09] <Duck_work> nice :-)
[05:09] <jbailey> If you want to work with the Ubuntu package directly, that's possible too.
[05:10] <jbailey> Although involves sponsoring and other stuff until you're much better known by this community.
[05:10] <Duck_work> i don't think that's needed, even if i never reject ubuntu users contacting me because they look at maintainer's field
[05:11] <bob2> Colony.
[05:11] <jbailey> bob2: Thanks. =)
[05:38] <lamont__> jbailey: he could have called them 'Cete's, as well... But chose 'Colony'
[05:39] <lamont__> although he was pushing for a <mumble> Crow release, so that he could make 'Murder 1' available early on
[05:43] <Kamion> lamont__: who, me? :-)
[05:43] <Nafallo> lol
[05:45] <jbailey> *lol*
[05:47] <daniels> Lathiat: because the algorithm is broken, and often produces missed keypresses
[05:47] <mdz> morning
[05:47] <Nafallo> morning mdz :-)
[05:47] <Lathiat> daniels: ah right
[05:47] <daniels> Lathiat: you end up with move-move-move-move-press-release, instead of press-move-move-move-move-release
[05:47] <daniels> i.e. you can't drag
[05:47] <Lathiat> who middle click drags? :)
[05:47] <daniels> it does this with all buttons
[05:48] <daniels> basically, it waits to see if another click is going to come through, and sends motion events through while doing this
[05:48] <Lathiat> daniels: uh, really?
[05:48] <Lathiat> i never noticed that..
[05:48] <daniels> yeah
[05:48] <Lathiat> ah right, so its a little late?
[05:48] <Lathiat> hm
[05:48] <Lathiat> i also only just noticed
[05:48] <Lathiat> nautilus has a middle click drag context menu
[05:48] <Lathiat> :)
[05:49] <daniels> night dude
[05:49] <daniels> remind me to buy you an ultimate long island some time
[05:50] <infinity> Yessir.
[05:50] <bob2> how many fists does that contain?
[05:50] <daniels> bob2: about six
[05:50] <daniels> bob2: the one at blue train is really good as well.  last time, infinity had to send his back to get them to add more coke and lemon.
[05:51] <bob2> hahaha
[05:52] <infinity> (He's not joking)
[05:54] <\sh> doko: ping
[05:56] <daniels> bob2: along with jesters and sumo
[05:58] <bob2> and 24 hour JB
[05:58] <ogra> mdz, ping
[06:01] <mdz> ogra: pong
[06:01] <ogra> mdz, like a short edubuntu update
[06:01] <ogra> ?
[06:01] <mdz> ogra: yes, definitely
[06:01] <pitti> Hi mdz
[06:02] <pitti> Treenaks: I just uploaded a new eject version which now works with encrypted devices, too. So using the icon right-click now works properly. Testing appreciated :-)
[06:03] <mdz> pitti: good morning
[06:08] <fabbione> hey mdz
[06:22] <doko> \sh: pong
[06:27] <seb128> anybody knows how /etc/X11/default-display-manager is managed?
[06:27] <seb128> the current value is "/usr/bin/gdm", but gdm has moved the binary to "/usr/sbin/gdm"
[06:27] <seb128> I'm trying to figure how /etc/X11/default-display-manager should be updated
[06:28] <ogra> via alternatives ?
[06:28] <ogra> err update-alternatives
[06:29] <seb128> random guess? I don't think that's an alternative
[06:29] <seb128> that's a text file
[06:33] <mdz> seb128: probably managed the same way as /etc/X11/X
[06:33] <ogra> seb128, ye, wild guess
[06:33] <daniels> ogra: for what it's worth, Xlib.h is now in /usr/include/X11
[06:33] <daniels> seb128: iirc d-d-m is managed via debconf
[06:34] <mdz> seb128: gdm.postinst updates it
[06:34] <ogra> daniels, thanks :)
[06:34] <mdz> as do the other display managers
[06:38] <seb128> mdz: thanks. I've figured that but I'm trying to find how to force it to update the config ... 
[06:38] <seb128> # debconf is not a registry, so we only fiddle with the default file if it
[06:38] <seb128> # does not exist
[06:38] <mdz> check if its value is /usr/bin/gdm, and if so, change it to /usr/sbin/gdm
[06:39] <seb128> removing /etc/X11/default-display-manager if is set to /usr/bin/gdm to force its update would be fine?
[06:39] <seb128> k, what I thought
[06:39] <seb128> thanks
[06:51] <\sh> oh lord, sometimes call-center people can be sooo stupid
[06:52] <mdz> thom: huzzah network-manager in breezy
[06:52] <Nafallo> yay! :-D
[06:52] <ogra> YAY
[06:53] <daniels> does it ... work?
[06:53] <ogra> daniels, who cares.... its in !
[06:53] <ogra> :)
[06:54] <Nafallo> hmm, network-manager-gnome? ;-)
[06:59] <elmo> mdz: there's a bunch of packages that don't sync - and I'm too lazy to find out why beyond "it's not josie's fault" - mind if I file bugs on them?
[07:00] <elmo> it usually just involves working out what the problem is, either a non-main package is now building something from main and needs promoted, or there's been orig.tar.gz damage and someone needs to work out how to proceed etc.
[07:01] <Lathiat> ogra: heh
[07:07] <Lathiat> ah fuge
[07:08] <estragon> hello
[07:08] <Lathiat> i didnt pay attention
[07:08] <Lathiat> and dist-upgrade just removeda bunch of packages
[07:08] <Lathiat> like gdm
[07:08] <Lathiat> :)
[07:08] <Lathiat> he following packages will be REMOVED:
[07:08] <Lathiat>   gdm gksu gnome-netstatus-applet gnome-system-monitor gnome-system-tools
[07:08] <Lathiat>   gnome-volume-manager hwdb-client libgksu1.2-0 libgksuui1.0-0 ubuntu-desktop
[07:08] <Lathiat>   x-window-system-core xbase-clients xterm
[07:08] <estragon> i have make a tray with bb
[07:08] <Lathiat> ah crap
[07:08] <Lathiat> i didnt mean to paste that
[07:08] <Lathiat> irssi paste detection needs to work on 3 lines
[07:09] <mdz> Lathiat: this is a normal (transient) situation in the development branch
[07:09] <Lathiat> mdz: i know, sorry, like i said, i didnt mean to paste it :)
[07:09] <Lathiat> i hit the wrong window
[07:09] <Lathiat> i was saving the list to go back and fix it
[07:09] <Lathiat> :)
[07:10] <ogra> Lathiat, the way around that is not to dist-upgrade, use only upgrade and pick the leftovers manually...
[07:10] <Lathiat> well,usually i pay attention and make sure itsnot doing bad things
[07:10] <Lathiat> they all install again anyway
[07:11] <Kamion> Lathiat: /set paste_verify_line_count <whatever>
[07:11] <Lathiat> Kamion: oh,cool
[07:12] <Lathiat> that was the best feature irssi ever implemented
[07:12] <Lathiat> saved me a few times
[07:13] <Lathiat> interesting, apt wanted to remove those packages so it can upgrade libx11-6/libx11-dev, yet, even if it does, it still holds themback
[07:14] <mdz> elmo: don't sync?
[07:14] <elmo> mdz: as in the sync program breaks, deliberately, and they get added to the BROKEN list
[07:15] <mdz> elmo: what would be an example of a problem which could cause that?  the repository is not maintained correctly?
[07:16] <mdz> does josie spit out enough information for someone who can't run josie to diagnose it?
[07:16] <elmo> mdz: I just did?
[07:16] <mdz> ah, I see
[07:17] <elmo> mdz: I'd post what josie says to the bug and give a rough indication
[07:17] <mdz> elmo: ok, sounds fine
[07:17] <elmo> I mean it's not many and I could do it myself, but I've been saying that for months now
[07:17] <elmo> ok, thanks
[07:18] <mdz> elmo: is faad2 one of them?
[07:23] <elmo>         if pkg == "mozilla-thunderbird" or pkg == "ocrad" or pkg == "gnuradio-core" or pkg == "gtk-smooth-engine" or pkg == "lib
[07:23] <elmo> ant1.6-java" or pkg == "ncmpc" or pkg == "glade":
[07:23] <elmo> is the current, unchecked list
[07:23] <elmo>  think faad2 was blacklisted, which I've just now taken off and am resyncing stuff
[07:24] <Lathiat> that line is so unpythonic :)
[07:26] <elmo> aww, man
[07:26] <elmo> IOError: [Errno ftp error]  421 Too many connections (2) from this IP
[07:28] <mdz> ogra: I think UniverseCandidates needs an update; it says the package must build on warty :-)
[07:28] <ogra> oops
[07:28] <ogra> heh
[07:29] <elmo> that looks like a urllib bug too, rock on
[07:29] <Amaranth> urllib bug? can i see? :)
[07:31] <mdz> urllib or urllib2?
[07:33] <elmo> urllib
[07:33] <mdz> daniels: please add your new -dev packages to supported or change stuff to build-dep on them
[07:34] <daniels> mdz: hm?
[07:34] <mdz> daniels: incoming
[07:34] <elmo> mdz: cron.sync hasn't been run since xorg was uploaded with new b-d's?
[07:34] <elmo> if so, it'll f-p on you
[07:35] <elmo> err, false-positive
[07:35] <elmo> my over-acronymn-ing is such a problem
[07:35] <daniels> i'm so confused
[07:35] <mdz> you need to o-a less
[07:35] <mdz> daniels: I will recheck as elmo suggests
[07:35] <daniels> cool
[07:35] <daniels> if it doesn't, should I just grab the seeds out of arch and dump them in?
[07:36] <elmo> no, don't add them to seeds unless they really need to be there
[07:36] <elmo> unnecessary seedings make baby jesus whine quietly
[07:36] <mdz> daniels: looks like it's mostly OK after re-germinating
[07:37] <mdz> these want to fall into universe:  o pm-dev, xlibmesa-glu-dev                                             {xorg}
[07:37] <daniels> yeah, sounds about right
[07:37] <daniels> actually, i don't think either of those actually exist anymore
[07:37] <daniels> if they do, they want to fall into universe, yeah
[07:45] <mdz> they definitely both exist
[07:46] <infinity> How's that now?
[07:46] <infinity> Package: xlibmesa-glu-dev
[07:46] <infinity> Source: xorg
[07:46] <infinity> Version: 6.8.2-10
[07:46] <infinity> That's so not right.
[07:46] <Kamion> it's no longer built from source
[07:46] <infinity> Right, so it should be dropped, not moved to universe.
[07:47] <Kamion> agreed
[07:47] <dilinger> fg
[07:52] <elmo> moving to universe is harmless
[07:52] <elmo> rene's painful atm due to either glibc or the kernel
[07:54] <elmo> done anyway
[08:04] <wasabi_> elmo, just want to see if you know about my keyring request. No hurry.
[08:04] <elmo> wasabi: can you mail keyring@ubuntu.com if you haven't?  that way I won't forget
[08:05] <wasabi_> oh yes. always forget.
[08:05] <elmo> and btw, TB people, please tell people to do that when you give them main rights, kthxbye
[08:05] <wasabi_> my fault. ;)
[08:06] <wasabi_> I'm just brain damaged.
[08:06] <elmo> wasabi: nah, it's not your fault, the last 3 main uploaders have all had the same problem
[08:07] <elmo> anyhoo, so I had this rocking idea when I couldn't sleep last night, and it's probably horribly obvious and/or already specced, but:
[08:07] <elmo> do we have/plan to have hotplug packages?
[08:07] <Lathiat> you mean hotplug-ng?
[08:07] <elmo> dunno.  I mean, when you plug in a HP OfficeJet, hplip should be auto-installed, if it's available, for example
[08:08] <daniels> elmo: hm
[08:08] <Lathiat> oh
[08:08] <Lathiat> i see what you mean
[08:08] <daniels> elmo: i would expect someone to be saying that
[08:08] <wasabi_> Wow that's a damned cool idea. ;)
[08:08] <daniels> elmo: and your reply to be punctuated with profanity and the word 'crack', with a mentioning of the security implications of just installing random (pseudo-random) packages onto their desktop
[08:08] <daniels> cool as it would be
[08:08] <elmo> what security implications?  it's packages from ubuntu/main
[08:08] <Lathiat> whats that package
[08:08] <wasabi_> Obviously those apps would have to be in main.
[08:08] <wasabi_> And gpg signed.
[08:09] <Lathiat> that finds debian packagesthings need
[08:09] <Lathiat> i assume it does some kind of LD_PRELOAD
[08:09] <Lathiat> trapping open()
[08:09] <elmo> Lathiat: that _is_ crack
[08:09] <Lathiat> elmo: it really is
[08:09] <daniels> elmo: i can just see people getting a little peeved that packages just wander on to their machine
[08:09] <elmo> I'm talking about on detection of hardware
[08:09] <Lathiat> im just curious whatit is
[08:09] <Mithrandir> Lathiat: auto-apt?
[08:09] <Lathiat> since you mentioned a similar topic
[08:09] <elmo> daniels: only hardcore linux guys
[08:09] <elmo> daniels: real users expect their officejet to just work
[08:09] <wasabi_> Windows does it. ;)
[08:09] <daniels> elmo: oh, fo'shizzle
[08:09] <elmo> and it's not an unreasonable expectation
[08:09] <daniels> yeah
[08:10] <Lathiat> elmo: office jet drivers should already be installed?
[08:10] <elmo> Lathiat: no, they're not
[08:10] <Lathiat> i mean
[08:10] <Lathiat> like
[08:10] <elmo> well, not in hoary
[08:10] <Lathiat> they _should_ be
[08:10] <daniels> hmm, i thought hplip was targetted for breezy
[08:10] <Lathiat> not, they are now
[08:10] <daniels> we ran with hpoj for hoary and man was that ever a mistake
[08:10] <daniels> and I am so not asleep right now
[08:11] <elmo> daniels: hplip is in breezy and once you install it, the officejet stuff (well scanning anyway) Just Works(tm)
[08:11] <daniels> elmo: right
[08:11] <elmo> but AFAIK, hplip isn't targetted for install-by-default
[08:11] <daniels> elmo: i'm pretty sure it's in desktop tho?
[08:11] <daniels> gar, still not in bed
[08:11] <elmo> it's not in current ubuntu-desktop package in breezy at least
[08:12] <elmo> in any event, hplip/OfficeJet is just an example I dealt with personally in the last 48 hours, I'm sure there's more use cases and packages we don't necessarily want to install by default
[08:12] <elmo> (I'm surprised we want to do hplip, it adds two daemons)
[08:12] <wasabi_> One of these days I'll finish my .apt file idea.
[08:13] <wasabi_> (Where you can open a .apt file from a web site and it will walk you through installing packages described by it.)
[08:15] <doko> elmo: please sync twisted from unstable
[08:19] <mdz> Kamion: does it work to specify multiple patterns with debconf-copydb?
[08:19] <mdz> hmm, no, doesn't look like it
[08:19] <wasabi_> Hmm. Almost 10 minutes is wasted in Eclipse on compiling SWT for ia64, ppc and sparc.
[08:19] <wasabi_> on i386. =/
[08:21] <wasabi_> Heh. It compiles for win32 also.
[08:25] <mdz> wasabi_: whaa?
[08:26] <wasabi_> silly build process.
[08:26] <mdz> wasabi_: compiling SWT for ia64 on i386?  cross-compiling?
[08:27] <wasabi_> It's indiscriminate about what parts it builds.
[08:27] <wasabi_> No. It's Java.
[08:27] <wasabi_> It builds seperate Jars for each.
[08:27] <mdz> won't they be identical?
[08:27] <wasabi_> Basically.
[08:27] <wasabi_> or close to it.
[08:27] <wasabi_> 64 bit platforms use long for raw pointers.
[08:27] <mdz> I thought SWT was mostly native code
[08:27] <wasabi_> the others will be the same.
[08:27] <wasabi_> No, SWT is mostly not native code.
[08:27] <wasabi_> SWT is mostly Java with a thin JNI wrapper.
[08:27] <wasabi_> The SWT code itself is Java. Obviously it uses Gtk.
[08:28] <Nafallo> yay! network-manager installed and netapplet thrown out :-)
[08:28] <wasabi_> It's just silly. It doesn't detect what platform it's on and build what it needs.
[08:28] <Nafallo> thom: thanks! :-)
[08:28] <wasabi_> It builds everything and then only includes what it needs in the output.
[08:28] <torkel_> Nafallo: and it seem to be working?
[08:28] <Nafallo> torkel_: dunno. I'm still online anyway ;-)
[08:28] <torkel_> :-)
[08:29] <wasabi_> It's platform specific Java.
[08:29] <wasabi_> But it's still Java, not native.
[08:44] <Lathiat> thom: ping
[08:45] <Nafallo> yikes :-P
[08:45] <Nafallo> NetworkManager just made my laptop _really_ hot :-)
[08:45] <Lathiat> so
[08:45] <Lathiat> how do you actually use NM with nm-gnome?
[08:46] <Nafallo> I don't know. my syslog got spammed anyway ;-)
[08:46] <Lathiat> oh, theres an applet now, looks like im being bitten by notification issues again
[08:46] <Lathiat> brb :)
[08:47] <Nafallo> hmm
[08:47] <Nafallo> thom: ping ;-)
[08:54] <mdz> thom: Depends: bind9?
[09:04] <Lathiat> hub: interesting
[09:04] <Lathiat> doh
[09:11] <Kamion> mdz: no. I suppose I could make it do that if you'd like, but I generally just use a fancier pattern :-)
[09:16] <mdz> Kamion: yeah, Perl REs will get me there as well ;-)
[09:23] <Nafallo> mdz: is it bugzilla or Malone for NetworkManager? :-P
[09:25] <mdz> Nafallo: there won't be an entry in bugzilla for it yet, since it's in universe
[09:25] <Nafallo> mdz: oki. thanks :-).
[09:26] <mdz> Nafallo: considering that it's only been in breezy for a few hours, thom might prefer that you mention something to him if he's around, before filing a bug
[09:27] <Nafallo> mdz: yea. but he isn't :-/.
[09:40] <Nafallo> baah, I'll wait for him :-)
[09:44] <mdz> mjg59: ping?
[09:44] <mjg59> mdz: Hi
[09:44] <mdz> mjg59: hey, looking for a status update on LaptopMission for BreezyGoals
[09:44] <mjg59> mdz: To be sorted at the weekend
[09:44] <mjg59> (Sorry, life has been relentlessly awkward this week)
[09:44] <mdz> mjg59: what's the next milestone-or-few?
[09:44] <mjg59> We have a list of people, I just need to get in touch with them
[09:45] <mjg59> Then we need to get hardware out
[09:45] <mjg59> I've got the testing spec pretty much written
[09:45] <eruin> what's going on wrt sound in breezy?
[09:45] <mdz> do we have a list of the people documented anywhere?  I assume there are wiki bits to be created
[09:45] <mdz> eruin: http://udu.wiki.ubuntu.com/AudioInfrastructure
[09:46] <mjg59> mdz: Afraid not. I'll sort that at the weekend.
[09:46] <eruin> thanks. I fear I'll have to start collecting data for bug reports :P
[09:46] <mdz> mjg59: ok, thanks
[09:46] <mdz> has anyone else experienced firefox violently crashing while moving the cursor in textareas?
[09:47] <eruin> mdz, have there been any reports about sound playing but in a very dirty (as in noise) fashion, and is that expectable atm you think?
[09:47] <mdz> it's awfully inconvenient
[09:47] <mdz> eruin: yes, that's known at the moment, and there are some possible fixes inbound
[09:47] <eruin> I havent seen anything about it on the list (apart from by myself)
[09:47] <eruin> ah, great
[09:47] <mdz> things are, shall we say, in flux :-)
[09:47] <eruin> hehe
[09:48] <mdz> eruin: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313378
[09:48] <mdz> I believe that's the issue you're hearing about
[09:48] <mdz> which reminds me, I should import it into bugzilla
[09:49] <eruin> yeah, that's the one
[09:50] <mdz> now also https://bugzilla.ubuntu.com/show_bug.cgi?id=11903
[09:51] <mdz> so folks can add themselves to the CC list there for updates
[09:53] <whiprush> thom: I _think_ the n-m in the archive built without dhcdbd support, because rebuilding it when dhcdbd is installed works.
[09:53] <whiprush> DCHDBD_BINARY_PATH is undefined
[09:54] <whiprush> DHCDBD_BINARY_PATH I mean
[09:55] <Mithrandir> jamesh: ping?
[09:56] <Mithrandir> jamesh: on fd#3550; I'm inclined to just drop the caching altogether as you're talking about.. I wonder what's the real reason why Keybuk added it though.
[09:56] <wasabi_> http://flickr.com/photos/bicherele/18416780/
[09:56] <wasabi_> haha
[09:56] <wasabi_> i am so sort.
[09:57] <wasabi_> i should have thought longer before pasting that
[09:58] <wasabi_> hope I don't get in trouble. =(
[10:01] <ogra> wasabi_, was already on planet.... 
[10:01] <wasabi_> oh was it?
[10:01] <ogra> yep, jdub posted it
[10:01] <wasabi_> oh I don't feel nearly as bad as I did then
[10:10] <whiprush> thom: I've filed 11904 and 11905 under unknown component (bugzilla doesn't have a n-m component yet)
[10:11] <\sh> hmmm
[10:12] <\sh>  /etc/network/interfaces was overwritten by my dist-uprade to breezy without asking to do so
[10:15] <Nafallo> whiprush: thanx, I'll try it :-
[10:15] <Nafallo> :-)
[10:17] <eruin> http://pastebin.com/300569 <- how would I go about submitting a bug / gathering bug data for that?
[10:19] <eruin> Seems to only occur after the system has been up for a while
[10:20] <eruin> in a hoary environment
[10:36] <Nafallo> thom: why do we need to dep on bind9? I want to use my lan-server for my internal domain! :-P
[10:37] <elmo> Nafallo: read the changelog
[10:38] <Nafallo> elmo: and that should tell me what?
[10:38] <elmo> ... read it?
[10:39] <Nafallo> elmo: you don't mean the ubuntupackage? cause I do and bind9 is not mentioned.
[10:41] <elmo> hum.
[10:41] <Nafallo> elmo: indeed
[10:42] <elmo> well, in the first version there was a NEWS.Debian, but that disappeared
[10:42] <xuzo> nas
[10:42] <Nafallo> elmo: so you know the answer to the question? :-)
[10:43] <elmo>   These packages are still quite rough and need a fair amount of work. The main
[10:43] <elmo>   issues are: 
[10:43] <elmo> i.e. it's WIP
[10:43] <elmo>    * Currently, you need to manually kill any preexisting dhclients
[10:43] <elmo>    * Depends on bind9
[10:43] <elmo>    * resolv.conf will have interesting potential issues.
[10:44] <Nafallo> I just rebuilt locally without it. I'll see where this lands ;-).
[10:45] <seth_k> eruin, you around?
[10:48] <syndicate> your DNS won't work
[10:53] <mvo> I uploaded balsa this morning (~12h ago) and it was accepted, but it wasn't attempted to build yet. is there anything wrong?
[10:54] <elmo> it b-d's on a removed package
[10:54] <elmo> or the buildds think it does
[10:54] <elmo> yeah, it still does
[10:55] <elmo> fix the gtkhtml3.2 dep
[11:01] <ogra> grmpf
[11:01] <ogra> seems nm doesnt like pcmcia
[11:14] <mvo> elmo: thanks, I was fooled by control vs. control.in :/
[11:17] <azeem> ogra: I think I've seen control.in.in.in
[11:17] <ogra> argh
[11:17] <ogra> what for ?
[11:17] <azeem> don't remember
[11:18] <ogra> no, i mean why ....
[11:18] <mvo> azeem: arggg
[11:18] <azeem> the Debian GNOME team uses control.in to populate Uploaders with an up-to-date list
[11:19] <Nafallo> ogra: and it _depends_ on bind :-P
[11:44] <KaiL_> does anybody know, which driver is selected for a Matrox Parhelia?