[12:40] <ajreznicek_> hello
[12:45] <Pygi> hi ajreznicek_
[12:45] <Pygi> he left :/
[01:39] <newlinuxd00d> A dapper update broke lvm and I have / on lvm. My system is unbootable. How can I put the stuff to load and activate a volumegroup in the initrd?
[02:11] <benplaut> is the following patch in dapper's xorg?
[02:11] <benplaut> http://www.mail-archive.com/devel@xfree86.org/msg03333.html
[02:45] <TerminX> can anyone reproduce this?  if you resize a window to the smallest possible size horizontally on dapper, the app bites the dust with an X error
[02:45] <zul> nope
[02:46] <TerminX> I get "BadAlloc (insufficient resources for operation)", can reproduce with multiple applications
[02:57] <infinity> Any specific app doing this to you?
[02:58] <TerminX> Firefox, Gaim...
[03:00] <infinity> Nope.  I've got a tiny pinprick of a firefox window now, but no crash.
[03:00] <infinity> I'd recommend running it in gdb and check where it's dying.
[03:01] <TerminX> I tried, but it was an X Window System Error, so I can't get a backtrace or anything because it's not a real "crash" I guess.
[03:07] <daniels> TerminX: run it with --sync and attach to gdb to see where it's tanking
[03:12] <TerminX> daniels: I ran it with --sync and attached gdb to it, but I'm not really sure what you want me to do after it bites it
[03:14] <daniels> TerminX: get a backtrace, maybe?
[03:14] <daniels> whatever you think would be useful
[03:19] <TerminX> daniels: I, uh, can't get it to do it with gdb attached.
[03:20] <TerminX> in fact, now it won't do it at all, even though it did it 5 minutes ago, repeatedly
[03:20] <TerminX> I can paste you the useless X Window System errors it dumped into the terminal
[03:20] <jdub> BenC: ping
[03:21] <BenC> jdub: pong
[03:21] <Jacobo221> Hi. i've been told ubuntu is working on some new init scripts. i'm looking through the wiki but i can see nothing related. can someone point me to the right direction? i want to read about it
[03:21] <jdub> BenC: is the UP/SMP switching stuff in 2.6.15, or a patch we've pulled in?
[03:22] <BenC> it's a patch I partly wrote
[03:22] <jdub> ahar, cool
[03:22] <jdub> got any descriptive text for people interested in the implementatino?
[03:22] <BenC> found the initial patch on l-k archive, against 2.4
[03:30] <daniels> TerminX: no thanks; they're, as you said, useless
[03:31] <daniels> TerminX: the only thing it tells you is that somewhere along the line, the X server refused to allocate something the client requested
[03:31] <daniels> this could be because it's too big, or because it's 0x0
[03:33] <BenC> jdub: basically it just converts lock's to nops at boot
[03:33] <BenC> saves a few cycles for UP machines
[03:40] <Jacobo221> or maybe i'm wrong and there is not such "generation boot scripts" project going on?
[03:44] <jdub> Jacobo221: nothing really directly related to init scripts
[03:44] <jdub> Jacobo221: most of it is concentrating on hardware activation
[03:44] <jdub> BenC: do you regard this as 'in early testing' or 'ready for dapper'?
[03:44] <Jacobo221> jdub: is there any url where I can read about it? or any REDME or..?
[03:45] <BenC> jdub: early stages
[03:46] <jdub> Jacobo221: i forget what the spec is named, but you can look through the ubuntu/ubz specs on launchpad, or search the wiki to find it
[03:46] <jdub> BenC: cool
[03:46] <Jacobo221> jdub: i am working on a wrapper script for an application which should start at boot time, for debian/ubuntu/lsb-compliant distros and i've been told this might be of my interest. i'd like it to be compatible with any future ubuntu generation scripts, of course
[03:46] <jdub> BenC: it is a funky feature
[03:46] <BenC> jdub: I still need to get it %100
[03:46] <BenC> the module lock/nop is perfect, so I don't have it enabled right now
[03:46] <BenC> isn't perfect
[03:46] <Jacobo221> jdub: ok, i'll do my best ;) thanks for yor time and help
[03:50] <desrt> daniels; is fglrx known to be broken right now or is a bug report appropriate?
[03:51] <daniels> er, could you be less specific?
[03:51] <desrt> daniels; specifically, the X server seems to think that direct rendering is go but glxinfo disagrees (possibly libGL problem?)
[03:51] <daniels> oh yeah, the paths still haven't been updated
[03:51] <daniels> i think there's a bug already open on this
[03:51] <daniels> infinity mostly handles l-r-m these days
[03:51] <desrt> excellent.  thanks.
[03:52] <daniels> np
[04:08] <psusi> anyone know if the newer xserver-xorg-driver-ati driver in dapper is supposed to support newer radeon cards like the 9800 pro?  the messages when the driver is loaded indicates that it does, only
[04:09] <psusi> it later says it is loading the r300 firmware... only the 9800 pro is based on the r350
[04:09] <daniels> psusi: ... what makes you ask?
[04:09] <daniels> psusi: noting that I've been running it on my x850 xt pe for around a year now
[04:09] <daniels> well, probably more like ten months, but eh
[04:10] <psusi> well, the new dapper version has a problem for me on my 9800 pro with totem and gxzine's overlays showing thorugh any black areas of a window placed on top... like transparancy
[04:10] <psusi> I filed a bug last week
[04:10] <psusi> but I just noticed in my xserver logs it is loading the R300 firmware... which seems wrong
[04:10] <daniels> yeah, that's known upstream
[04:10] <daniels> don't worry about the firmware
[04:11] <psusi> also, a lot of times when I try to restart the x server, it hangs up HARD... caps lock doesn't even work... but the magic sysrq keys do
[04:11] <psusi> and sometimes the card starts making a high pitch noise
[04:11] <infinity> desrt : DRI is broken because of a hardcoded path in the libGL binary.  Fixing in the next upload.
[04:11] <psusi> I'd say right around 20 khz
[04:12] <daniels> infinity: don't sed the binary.  ati don't like that.
[04:12] <infinity> daniels : My only other option is symlinks in /usr/X11r^, which I'd really like to go away.
[04:12] <infinity> X11R6, too.  Yay, shift keys.
[04:12] <daniels> infinity: i would love it to go away also
[04:12] <psusi> daniels, is the xorg driver going to some day support 3d accel? ;)
[04:13] <infinity> Meh.  I can do symlinks now, if it's more policially correct, and hope for an Xorg7.0 build before release.
[04:13] <daniels> psusi: what do you mean, 'some day'?
[04:13] <psusi> daniels, it says it's 2d only
[04:13] <psusi> and it seems to be...
[04:13] <Mithrandir> daniels: any chance you could make nb and nn alternatives for the no keymap in xserver-xorg.config?  I think dk as an alternative for da (or the other way around) might be useful too.
[04:13] <daniels> daniels@ephemera:~/canonical/xorg/lib/libx11/libX11-1.0.0% dpkg -L libgl1-mesa-dri | grep r300
[04:14] <daniels> /usr/lib/dri/r300_dri.so
[04:14] <psusi> daniels, and iirc, it mentions an experimental mesa driver you can pull the source for and build with 3d support
[04:14] <daniels> Mithrandir: as in, language -> keymap?
[04:14] <daniels> psusi: it's not experimental anymore
[04:14] <Mithrandir> daniels: yes.
[04:14] <psusi> ohh ohhh, is it in the repositories?
[04:14] <daniels> psusi: that version of mesa has been in since *breezy*
[04:14] <daniels> Mithrandir: nb_* and nn_*?
[04:14] <Mithrandir> daniels: yup
[04:14] <psusi> eh?  in what package?
[04:14] <daniels> psusi: you're about five months late to the party
[04:15] <daniels> psusi: look up like six lines, dude
[04:15] <Mithrandir> daniels: that is, nb* and nn*, since you might not get a full, valid locale in.
[04:15] <daniels> Mithrandir: hrngh
[04:16] <psusi> then why is everyone still saying to use ati's drivers for 3d? ;)
[04:16] <daniels> psusi: because people are stupid
[04:16] <Mithrandir> daniels: just add it below the     *--no*) XMAP="no";;
[04:16] <Mithrandir> line
[04:17] <daniels> Mithrandir: actually, you're SOL
[04:17] <Mithrandir> daniels: oh, why?
[04:17] <daniels> Mithrandir: because I've ripped out the language 'smarts' in xserver-xorg.config
[04:17] <Jacobo221> jdub: i could find nothing about it in the wiki. if you sometime remember the specs name, please tell me. i'll be here. waiting ;) thanks so much anyway
[04:18] <SEJeff> BenC: ping
[04:18] <Mithrandir> daniels: well.. could I have it back, please?  I need some way to get from language to keymap for keyboard configuration to work on the live cd.
[04:18] <daniels> Mithrandir: we really, really need to push this down into d-i
[04:18] <psusi> damnit... I'm so exicted trying to figure out how to get this working is killing me
[04:18] <Mithrandir> daniels: new live CD doesn't use d-i.
[04:18] <infinity> daniels : No d-i on the livecd anymore.
[04:18] <Mithrandir> it's just an initramfs.
[04:18] <daniels> Mithrandir: into something that's not X
[04:18] <Mithrandir> and deep, scary magic.
[04:19] <daniels> Mithrandir: basically, console keymap and xkb map need to be in alignment
[04:19] <daniels> and the former is a subset of the latter
[04:19] <Mithrandir> so configuring X keymap and then deriving console keymap makes sense?
[04:19] <daniels> psusi: it should 'just work'.  if it doesn't, you probably need newer DRM bits for the kernel.
[04:19] <daniels> Mithrandir: yep.  that's how we should be doing it in the installer.
[04:19] <daniels> since there are like five console keyamaps
[04:20] <Mithrandir> daniels: I care very little about console keymaps compared to X keymaps.
[04:20] <daniels> and fifty hojillion xkb maps, each with seventeen obscure variants that no-one cares about until two days before the release when OH MY GOD IT'S BROKEN WTF IS GOING ON
[04:20] <daniels> Mithrandir: think of the installer case, not just livecd
[04:20] <Mithrandir> heh
[04:21] <psusi> daniels, i seem to already have libgl1-mesa-dri installed... what do I need to put in my xorg.conf to tell the server to use it?  right now I'm using the 'radeon' driver
[04:21] <psusi> and it doesn't look like that package installs drivers in the xorg directories... hrm...
[04:22] <daniels> psusi: you don't need to put anything in xorg.conf
[04:22] <daniels> psusi: just run glxinfo.   if it's telling you that dri is disabled and you've purged fglrx (not just stopped using it), then look in your Xorg.0.log to find out why, but this is getting into #ubuntu territory
[04:22] <psusi> I can't quite tell from reading these descriptions... is mesa binary compatible with opengl or do apps have to be rebuilt to use mesa?
[04:23] <infinity> mesa is an implementation of OpenGL.
[04:25] <psusi> under breezy my xorg log used to have messages saying that the 9800 is not supported by this driver... under dapper, I see this:
[04:25] <psusi>         *** Direct rendering support is highly experimental for Radeon 9500
[04:25] <psusi>         *** and newer cards. The 3d mesa driver is not provided in this tree.
[04:25] <psusi>         *** A very experimental (and incomplete) version is available from Mesa
[04:25] <psusi> which is why I mentioned pulling the source
[04:26] <daniels> ignore that message
[04:27] <psusi> well, it says that drm is enabled... and playing dvds is nice and smooth with rather little cpu used... so it looks like I have 2d accel... yet glxinfo shows no dri
[04:27] <psusi> isn't dri acceleration for both 2d and 3d?
[04:27] <daniels> you have completely purged fglrx, right, not just stopped using it?
[04:27] <psusi> yes... and made sure there are no references to in in my xorg.conf
[04:28] <psusi> and of course, there is no kernel module now... upgraded kernels a dozen times since then
[04:31] <psusi> wait a second...doh... looks like it got split out of the linux-restricted module and into xorg-driver-fglrx now... heh... the copyright and changelog in /usr/share/doc/xorg-driver-fglrx still claim to be linux-restricted-modules-2.6.15
[04:32] <daniels> so you do have fglrx installed.
[04:32] <psusi> it seems so... purging now... but if it isn't being loaded in xorg.conf, why would it matter?
[04:32] <daniels> because it replaces libGL
[04:33] <daniels> i wasn't just saying that for fun, it really does need to be purged if you want to stop using it
[04:33] <lifeless> daniels: hey, I installed that new package, still got no side-of-trackpad scrolling
[04:33] <psusi> hrm.... don't two packages that have conflicting files usually specify that they conflict with each other so you can't install both?  how do I get the old libgl back now?
[04:33] <daniels> lifeless: xorg.0.log pls
[04:33] <psusi> it's purged now
[04:33] <daniels> psusi: purge fglrx and it will magically reappear
[04:33] <lifeless> is that /var/log/gdm/:0.log ?
[04:34] <psusi> interesting... how does that work?  dpkg notices there's another package that wants to install that file and installs it once that one is removed?
[04:34] <lifeless> oh, capital X.
[04:34] <lifeless> daniels: anything I should censor in it before uploading it to p.u.c ?
[04:34] <infinity> psusi : "dpkg-divert"... Ugly hack.
[04:35] <infinity> psusi : Required because we can't very well have xorg-driver-fglrx conflict with libgl1-mesa (which the world depends on)
[04:35] <daniels> lifeless: nope
[04:36] <lifeless> http://people.ubuntu.com/~robertc/Xorg.0.log
[04:36] <psusi> interesting... ok... so I don't even have to reinstall libgl1-mesa?  just restart x?
[04:37] <daniels> you don't have to restart X, either
[04:38] <daniels> lifeless: *shrug*
[04:40] <desrt> man
[04:40] <desrt> fglrx is pwned
[04:40] <desrt> infinity; sorry for that flood of bugmails :p
[04:42] <psusi> hrm... glxinfo still says no direct rendering... I don't need libgl1-mesa-swrast do I?  that's just the pure software renderer it looks like
[04:42] <desrt> daniels; psusi is right
[04:42] <desrt> daniels; r300_dri.so is nowhere on the system
[04:43] <infinity> Erm.
[04:43] <infinity> (base)adconrad@cthulhu:~$ ll /usr/lib/dri/r300_dri.so
[04:43] <desrt> so even if he's using the right libGL and it's looking in the right place ....
[04:43] <infinity> -rw-r--r-- 1 root root 1962568 2005-12-16 21:10 /usr/lib/dri/r300_dri.so
[04:43] <desrt> mind telling me what package that's in?
[04:43] <infinity> (base)adconrad@cthulhu:~$ dpkg -S /usr/lib/dri/r300_dri.so
[04:43] <infinity> libgl1-mesa-dri: /usr/lib/dri/r300_dri.so
[04:43] <desrt> ah.  lovely how that's not part of ubuntu-desktop :)
[04:44] <desrt> direct rendering: Yes
[04:44] <desrt> woo.
[04:44] <psusi> hrm... it's not part of ubuntu-desktop?
[04:44] <desrt> certainly, i had ubuntu-desktop installed but not libgl1-mesa-dri
[04:44] <infinity> it is.
[04:44] <infinity> x-window-system-core depends on it.
[04:44] <psusi> if it isn't I have no idea how I managed to have it installed... I built this system from the livecd with debootstrap, then installed ubuntu-desktop
[04:45] <infinity> Oh, WTF.
[04:45] <infinity> libgl1-mesa provides libgl1-mesa-dri.
[04:45] <infinity> SWEET.
[04:45] <daniels> useful.
[04:45] <desrt> :)
[04:45] <desrt> plz fix.
[04:45] <daniels> oh, I know why that is
[04:46] <desrt> man.  this makes me a happy camper.  to hell with fglrx.
[04:46] <infinity> because mesa-sri and mesa used to both provide a libGL, before the proper split happened?
[04:46] <infinity> s/sri/dri/
[04:46] <daniels> (debian calls libgl1-mesa, libgl1-mesa-dri.)
[04:47] <daniels> and libgl1-mesa is libgl1-mesa-swratst
[04:47] <psusi> infinity, it looks like they both still do
[04:47] <daniels> and swrast
[04:47] <daniels> but primarily swratst
[04:47] <infinity> psusi : No, we have no libGL in our mesa-dri package, just the DRI modules.
[04:47] <infinity> daniels : Any chance ot a mess of NMUs in Debian to get mesa in sync?
[04:48] <infinity> daniels : Poeple keep begging for Debian's mesa situation to be sorted anyway.
[04:48] <daniels> infinity: not from me, but I've been maintaining a Debian tree in parallel to my Ubuntu one
[04:48] <psusi> oops, nevermind... you're right
[04:48] <daniels> it'll get hijacked when modular gets uploaded
[04:49] <infinity> daniels : Fair enough.  So, what do we do in the interim?.. That Provides is breaking seeds.
[04:49] <infinity> daniels : I guess if x-window-system-core had a versioned dep on mesa-dri, that would "fix" it, since provides don't provide versions. :)
[04:50] <daniels> infinity: Uploading via ftp mesa_6.4.1-0ubuntu2_source.changes: done.
[04:50] <daniels> i just removed it.  it's a non-issue because -dri has a tight dep on libgl1-mesa anyway.
[04:50] <infinity> Of course, the X metapackages all need to get split out anyway, since they still come from xorg right now.
[04:50] <daniels> infinity: they'll still come from the xorg source package, it'll just be ... lighter
[04:51] <infinity> Heh.
[04:51] <infinity> And lacking in the massive orig, I assume.
[04:51] <desrt> wow.
[04:51] <psusi> blarg!  everything else looks fine except for direct rendering: no... xserver logs look like everything is working... glxinfo shows it's using the mesa stuff.... I'm going to try retsarting X
[04:51] <daniels> no, I'll leave the orig in out of spite
[04:51] <desrt> psusi; you're not missing much
[04:51] <desrt> psusi; when they say the driver is highly experimental they're not kidding
[04:51] <infinity> Mmm, spite.
[04:52] <psusi> they told me I couldn't get ubuntu installed on my sata hardware fakeraid dual booting with windows... took me two weeks... but I won ;)
[04:52] <desrt> psusi; i fired up Xglx and my computer crashed hard
[04:52] <desrt> psusi; i think this is really something you should wait for
[04:53] <psusi> hey, if it doesn't work, I can allways go back to the way things are now...
[04:53] <psusi> and file bugs of course...
[04:54] <desrt> psusi; you're pretty far outside the scope of this being a problem with ubuntu, though
[04:54] <psusi> heck.. I may as well install todays' batch of updated dapper packages and reboot... 
[04:54] <desrt> psusi; maybe get involved with upstream r300_dri development if you want to help?
[04:55] <psusi> problem is... there's about a dozen projects I'd like to see advance more... and I'm only one person with a full time job ;)
[04:56] <psusi> I love linux and open source because I CAN fix things... I love ubuntu because I don't have to ;)
[04:57] <psusi> hrm.. that reminds me... I wonder if my lilo patch ever got accepted upstream?
[04:57] <desrt> then you should stick to breezy :)
[04:57] <psusi> desrt, got it on another partition in case things break and I don't feel like looking into it
[04:58] <Burglaptop> does debian ship with build-essential installed by default?
[04:58] <psusi> ok... reboot time... brb
[04:59] <womble> Burglaptop: No, unless you choose to install development-related tasks
[04:59] <Burglaptop> womble: ok, cheers
[05:00] <desrt> infinity, daniels; thanks for the help but i think i'm gonna stick it out in 2D land for now :)
[05:02] <Burglaptop> daniels: is dri for i810 borked currently?'
[05:02] <infinity> desrt : Wimp. :)
[05:05] <desrt> infinity; is r300 *expected* to be working in any way?
[05:06] <infinity> desrt : I dunno.  Doesn't really do much of anything useful for me yet.
[05:06] <infinity> I'm not following it closely, though.
[05:10] <psusi> daniels, still no direct rendering... should I file a bug?  if so, against what module?  the mesa library?
[05:11] <daniels> Burglaptop: install libgl1-mesa-dri
[05:12] <Burglaptop> daniels: ah
[05:13] <psusi> xorg log says direct rendering is enabled... is there a way to get more info from glxinfo about WHY it doesn't think it is?
[05:15] <desrt> psusi; LIBGL_DEBUG=verbose glxinfo
[05:15] <desrt> psusi; but seriously.... #ubuntu man
[05:15] <psusi> they don't seem to talk much about dapper over there ;)
[05:18] <infinity> Then start talking about dapper over there.  Seriously.  Please.
[05:18] <infinity> -:- Topic (#ubuntu-devel): Ubuntu Development (not support, even with dapper)
[05:18] <psusi> well I'll be... it isn't looking in the right place for r300_dri.so... it is checking several dirs in /usr/X11R6 but it is actually in /usr/lib/dri
[05:19] <infinity> psusi : Then you still have xorg-driver-fglrx's libGL installed.
[05:19] <psusi> I purged it and even reinstalled the mesa packages
[05:19] <infinity> psusi : ls -l /usr/lib/libGL*
[05:19] <desrt> md5sum /usr/lib/libGL.so.1.2
[05:19] <psusi> 14152de53fb6c8dee1d1fb7d535f7434  /usr/lib/libGL.so.1.2
[05:20] <desrt> that's not mesa libGL
[05:20] <desrt> it's not the one i'd expect to see from fglrx either tho.... :)
[05:20] <psusi> hrm...
[05:21] <infinity> psusi : i386 or amd64?
[05:21] <psusi> amd64
[05:21] <desrt> ah.  of course.
[05:22] <desrt> psusi; grep for that md5sum in /var/lib/dpkg/info/*
[05:22] <infinity> psusi : ls -l /usr/lib/libGL*
[05:22] <desrt> psusi; to find out what package it originally came from
[05:23] <psusi> libgl1-mesa.md5sums:14152de53fb6c8dee1d1fb7d535f7434  usr/lib/libGL.so.1.2
[05:23] <infinity> Yeah, that's fine.
[05:23] <infinity> But it's also obviously not the library being loaded.
[05:23] <psusi> thought so... yet it's looking in the wrong place for the .so
[05:24] <desrt> psusi; check for other libGL's in /usr/lib.....
[05:24] <psusi> that's the one that the libGL.so.1 symlink points to... and there's no others
[05:24] <infinity> psusi : And "ldd glxinfo" shows it resolving to /usr/lib/libGL.so.1?
[05:24] <psusi> yep
[05:25] <desrt> psusi; grep /usr/X11 /usr/lib/libGL.so.1
[05:25] <desrt> binary file matches?
[05:25] <infinity> ("strings" works well there)
[05:25] <infinity> Anyhow, I should get back to work.
[05:25] <desrt> infinity; eh.  this is a case of either it is or it isn't :)
[05:26] <infinity> Any chance I can convince you two to take this to -users?
[05:26] <psusi> you lost me... grep what?  the glxinfo binary for /usr/lib/libGL?
[05:26] <desrt> psusi; see /query
[05:26] <psusi> k
[05:26] <infinity> strings libGL.so.1.2 | grep '/usr'
[05:26] <infinity> I'm curious.
[05:26] <infinity> But it should return /usr/lib/dri
[05:27] <psusi> only one match:
[05:27] <psusi> /usr/lib/dri
[05:27] <desrt> w t f
[05:29] <psusi> maybe I should just give it a symlink in the dir it wants to the real location? ;)
[05:29] <infinity> No.
[05:30] <infinity> glxinfo 2>/dev/null | grep vendor
[05:30] <BenC> SEJeff: pong
[05:31] <SEJeff> BenC: nvm. I was trying to figure out why older kernels freaked out and wouldn't mount my lvm filesystems
[05:31] <psusi> infinity, sgi, sgi, mesa
[05:32] <SEJeff> BenC: I thought it was a bug, but then I remembered how much udev and the likes were changed
[05:32] <infinity> psusi : Oh, that is special.
[05:32] <BenC> yeah, once you go dapper-kernel, you can't go back easily
[05:33] <SEJeff> BenC: So I noticed...
[05:33] <psusi> yea... dapper does not like being booted with the older kernels, and breezy doesn't like newer ones... at least newer than 2.6.13 that I build myself
[05:35] <sistpoty> BenC: I saw a new linux-source-2.6.15 approaching... did it adress #20910?
[05:35] <infinity> The general rule when using new kernels on older distributions is to build monolithic (or close to it) kernels.
[05:35] <infinity> Features like udev and such are bound to break, and often module loading in general will break.
[05:35] <BenC> preach it brotha infinity
[05:36] <jblack> BenC: Hiya.. Fabbione suggested I talk to you
[05:36] <BenC> sistopy: not directly, but it's very possible
[05:36] <sistpoty> BenC: ok, will test it... thx
[05:39] <psusi> hrm....
[05:40] <desrt> psusi; ./configure;  make tea;  drink
[05:41] <psusi> touch ; finger ; unzip ; gasp; yes; yes; yes; zip; done;
[05:47] <psusi> yep... strace confirms, glxinfo IS using /usr/lib/libGL.so.1, which points to libGL.so.1.2, which matches the md5sum from the mesa package
[05:47] <BenC> jblack: about what?
[05:48] <jblack> I am a proud owner of a sony vaio. It seems the latest kernels removed sony acpi support
[05:49] <jblack> Fabbio suggested I ask you if there was something bad going on in that module before I dive into kbuild
[05:52] <BenC> jblack: not intentional
[05:53] <BenC> jblack: for some reason the module deps on ACPI_INTERPRETER, but nothing provides it, so it's disabled
[05:55] <jblack> Well, maybe the kernel guys will fix it some day.
[05:56] <psusi> why would the module depend on a non existant service/package that is part of the kernel?
[05:56] <psusi> oh.. nevermind... different dep
[05:56] <BenC> jblack: no, I'll fix it today :)
[05:57] <jblack> Thank you so much.
[05:58] <jblack> can you do make-acpi-sleep-work magical stuff too?
[06:01] <BenC> that's black magic :)
[06:02] <StevenK> jblack: BenC would, but he doesn't have a spare virgin at the moment ...
[06:02] <jblack> I have a 11 year old daughter that I could contribute....
[06:03] <BenC> jblack: get a sack of grain, and two left-handed mules, and I'll see what I can do
[06:04] <psusi> rofl
[06:05] <jblack> Hmmm. Does it count if she's stubborn and I donate the ex-wife as well? 
[06:06] <psusi> does she have two left feet?
[06:06] <jblack> Yeah. 
[06:07] <jblack> And about five mouths and eyes in the back of her head. =)
[06:07] <jblack> I kinda like the kid though.
[06:16] <psusi> well... if I symlink /usr/X11R6/lib/modules/dri to /usr/lib/dri, direct rendering works fine... wonder what package I should file a bug against?
[06:19] <infinity> psusi : The one you find that path hiding in?
[06:19] <fabbione> morning
[06:20] <psusi> infinity, I've searched and searched... can't find it... at least not hard coded in any binaries... and I don't see any conf files being open()ed that look like they might contain it
[06:21] <psusi> but hell... with the symlink, I get 3000 fps in glxgears ;)
[06:23] <infinity> psusi : Do you have a /usr/lib32/libGL.so.1.2?
[06:24] <daniels> glxgears is not a benchmark.
[06:24] <psusi> infinity, yes... I do... 
[06:25] <psusi> daniels, but it is a good indicator of weather or not direct rendering is working ;)
[06:25] <infinity> psusi : And "strings /usr/lib32/libGL.so.1.2 | grep '/usr'" tells you what?
[06:26] <infinity> psusi : (and /usr/lib32/libGL.so.1 points to where?)
[06:28] <psusi> well farg... tried shrinking the glxgears window to speed up the fps... it went faster... for a few seconds... then the xserver hard locked and it was magic sysreq time
[06:28] <psusi> someone was saying something about lib32?
 psusi : And "strings /usr/lib32/libGL.so.1.2 | grep '/usr'" tells you what?
 psusi : (and /usr/lib32/libGL.so.1 points to where?)
[06:29] <infinity> Also, the new r300 stuff on my X300 actually plays Quake3 smoothly.  Neat.
[06:29] <eruin> I know! /usr/X11R6/lib/modules/dri 
[06:29] <psusi> well, glxgears is a 64 bit elf image, so it should not be able to link to the lib32 version... and I can see from strace that it is, in fact, loading /usr/lib/libGL.so.1.2... but I'll check anyhow
[06:30] <psusi> it shows /usr/lib/dri
[06:33] <daniels> grep -r /usr/X11R6/lib/modules/dri /
[06:34] <infinity> daniels : Heh.  That could take a little while. ;)
[06:34] <daniels> well, this has taken like an hour so far
[06:35] <psusi> blast... locked up again running glxgears... strange that the cursor still worked
[06:36] <infinity> daniels : Fair point.
[06:36] <infinity> psusi : Just grep your whole system for /usr/X11R6/lib/modules/dri and see what turns up. :)
[06:36] <psusi> rofl
[06:37] <infinity> (And you think we're kidding)
[06:37] <psusi> ok... let's see... how to do that.... something with find -exec grep?
[06:37] <psusi> maybe find -exec strings grep be better
[06:37] <infinity> rgrep /usr/X11R6/lib/modules/dri /
[06:38] <psusi> ok...
[06:38] <infinity> Maybe with a 2>/dev/null on that, if you don't want to see a mess of errors about premissions and dangling links.
[06:39] <psusi> hrm... it looks like it isn't doing anything... printed a few errors, then stopped... don't hear the disks, and cpu load is nil
[06:40] <psusi> OMFG
[06:40] <psusi> I limited it to /etc, and bingo:
[06:40] <psusi> /etc/profile:    LIBGL_DRIVERS_PATH=$LIBGL_DRIVERS_PATH:/usr/X11R6/lib64/modules/dri/:/usr/X11R6/lib/modules/dri/
[06:40] <psusi> /etc/profile:  LIBGL_DRIVERS_PATH=/usr/X11R6/lib64/modules/dri/:/usr/X11R6/lib/modules/dri/
[06:40] <desrt> wow.  you're still on about this :)
[06:40] <daniels> lib64??
[06:40] <daniels> looks like that's your problem, man
[06:41] <psusi> how on earth did that get there?
[06:41] <infinity> That looks very much like something the ATI fglrx installer (not our packages) did to you.
[06:41] <infinity> Or advice you got from a forum or from Gentoo.
[06:41] <daniels> almost certainly fglrx installer
[06:41] <psusi> I did install the ati driver from their web site at one point... a long time ago
[06:41] <infinity> Well, there you go.
[06:41] <infinity> Problem solved.
[06:41] <infinity> Now we can go about our day.
[06:41] <eruin> blasted! a symlink from /usr/X11R6/lib/modules/dri/ to /usr/lib/dri/ is all that was missing for me to enjoy 3d gaming bliss with fglrx on dapper!
[06:42] <Robi-> who's got a min to troubleshoot a usb wifi driver?
[06:42] <psusi> so...  how can I fix it? ;)
[06:42] <`anthony> infinity: that's cos the ricers think that lib64 makes your system go faster, even on 32 bit systems ;)
[06:42] <daniels> psusi: ... remove it.
[06:42] <psusi> change it to point to the right place, or remove it completely?
[06:42] <infinity> eruin : Err.  That and an fglrx module that works with kernel 2.6.15...
[06:42] <daniels> `anthony: DUDE THERE'S TWO EXTRA NUMBERS ON THE END
[06:42] <daniels> it goes 64% faster
[06:42] <psusi> ok.... cool... thanks...
[06:42] <daniels> psusi: remove it completely
[06:42] <infinity> eruin : WARNING, YOUR MACHINE WILL CRASH.
[06:42] <eruin> infinity, works like a dream here
[06:42] <psusi> now... to figure out why the x server locks up hard
[06:42] <eruin> infinity, in fact, only the ati driver crashes my machine, while fglrx is rock stable
[06:42] <daniels> psusi: because r300 is screwed
[06:43] <psusi> hehehe... I'd imagine so... especially when running on an r350 ;)
[06:43] <infinity> eruin : You're lucky.  Kernel panics for everyone else who figured out how to unbreak it. ;)
[06:43] <Robi-> lsusb shows Bus 001 Device 003: ID 124a:4023 AirVast, supposedly a prism2/2.5/3 card, so prism2_usb driver
[06:43] <Robi-> loading it, no error, and nothing happens, no new device created
[06:43] <Robi-> modinfo shows an alias for 124a:xxxx on two occasions but the numbers, dont match exactly
[06:43] <eruin> infinity, well, X produces a kernel BUG and locks the system on exit, but that's my only woe ;)
[06:44] <Robi-> this is the PN15 usb wufi card on a shuttle sff pc
[06:44] <daniels> psusi: ignore r350
[06:44] <infinity> eruin : I get the BUG/lock if DRI is disabled.  When I fix DRI, I get panics.
[06:44] <daniels> psusi: r3xx is screwed
[06:44] <daniels> as a general statement
[06:44] <`anthony> eruin: So it's fine except that it crashes the system? ;)
[06:44] <desrt> eruin; sounds like my problem but in addition to that any glx app that attempts to use DRI locks up :)
[06:44] <Robi-> doesn't work in dapper fl2 either
[06:44] <eruin> anthony: it only crashes when I want it shut down anyway :p
[06:44] <psusi> daniels, why do you say that?  earlier you said it was working fine for you?
[06:45] <eruin> desrt, I just ran enemy-territory fine :)
[06:45] <desrt> eruin; fglrx?
[06:45] <daniels> psusi: 3d has never worked for me
[06:45] <eruin> yup
[06:46] <psusi> are you messing with me now?  I am a bit tipsy at this point in the evening...
[06:49] <daniels> psusi: no, I don't say this shit to mess with random people on channel when I could be working productively instead
[06:49] <Robi-> daniels, who might know usb drivers well? or where?
[06:50] <psusi> I swear you said earlier the mesa libs had working 3d for 5 months... oh well, it is getting late... time to call it a night... thanks for the help... I knew those proprietary drivers had messed something up somewhere...
[06:51] <desrt> O_o
[06:52] <`anthony> daniels: Nah, you say this shit because it amuses you ;)
[06:54] <floam> is the rc3 xorg server close at all to finally getting into dapper?
[06:56] <daniels> no
[06:56] <daniels> and it won't get into dapper
[06:56] <daniels> `anthony: i think I need some more port
[06:56] <floam> daniels: skipping it?
[06:56] <daniels> Robi-: if you have a specific bug, try bugzilla.ubuntu.com
[06:57] <Robi-> daniels , bug like this driver doesn't recognize this card? heh bit broad
[06:57] <daniels> Robi-: name the specific driver and the specific card and you've got a workable bug report
[06:57] <daniels> StevenK: yeah, well we all make mistakes
[06:57] <daniels> StevenK: iirc our original estimate was january 2005
[06:57] <desrt> Robi-; sounds pretty specific.  give the vendor/product codes of the card that's not being recognised
[06:57] <daniels> floam: yes, I'm already most of the way through packaging rc4
[06:58] <StevenK> daniels: Heh, that looks about right.
[06:58] <daniels> 138 packages done, ~67 to go
[06:58] <floam> I didn't realize rc4 was released
[06:58] <Robi-> desrt well i cant be sure i have the right driver
[06:58] <daniels> floam: http://xorg.freedesktop.org/releases/X11R7.0-RC4/
[06:58] <Robi-> hence i want to get it workign first
[06:58] <floam> s/didn't/hadn't/
[06:58] <Robi-> then have them fix it
[06:59] <floam> cool
[06:59] <desrt> Robi-; is it a usb device not being recognised or the usb host controller driver not recognising your usb port?
[07:00] <Robi-> device, i have an shuttle sff pc here with an internal usb wifi card
[07:00] <Robi-> AirVast 124a:4023
[07:00] <Robi-> google et a says prism2/2.5/3
[07:00] <desrt> then go into the driver you think it is and add those tags to the list
[07:00] <Robi-> prism2_usb
[07:01] <Robi-> tried with ith a hex editor on the driver i have
[07:01] <desrt> uhm
[07:01] <desrt> it's opensource for a reason...
[07:01] <Robi-> point taken
[07:01] <desrt> search for 'struct usb_device_id'
[07:03] <Robi-> k need to get the kernel-modules for this kernel
[07:06] <Robi-> if i could find them
[07:08] <desrt> you probably want linux-source-2.6.15
[07:11] <Robi-> i have 2.6.12
[07:11] <desrt> o
[07:12] <Robi-> mainer , yes but that doens't matter as there is no wifi device yet
[07:14] <Robi-> desrt, downloading
[07:16] <Robi-> desrt, untaring
[07:18] <Robi-> hmm, can't find the driver
[07:18] <desrt> drivers/net/wireless/prism2
[07:19] <Robi-> only prism54 found
[07:20] <desrt> Robi-; probably easiest way to do one-shot module builds is to use linux-headers
[07:20] <desrt> maybe it's not in 2.6.12
[07:20] <Robi-> could try to use that
[07:20] <daniels> it'll be in a patch
[07:20] <Robi-> well it comes with teh installed system so it better be
[07:20] <desrt> daniels; linux-source comes with patches applied, no?
[07:21] <daniels> no
[07:21] <daniels> fakeroot debian/rules patch
[07:21] <daniels> 2.6.12 is pre-git iirc
[07:21] <desrt> i see.
[07:22] <Robi-> ya i doubt its the prism54 driver it's seems all pci
[07:22] <Robi-> even tho thid card does b/g
[07:23] <Robi-> so now what?
[07:23] <desrt> Robi-; did you do what daniels said?
[07:24] <Robi-> that's a command?
[07:25] <Robi-> root@3[linux-source-2.6.12] # cat version.Debian
[07:25] <Robi-> 2.6.12-10.dcc3.0
[07:25] <Robi-> there is no debian dir
[07:25] <Robi-> desrt ?
[07:39] <Robi-> desrt ?
[08:16] <JaneW> who handles the ubuntu shutdown screen? And specifically the choice of progress bar going 
[08:16] <JaneW> backwards?
[08:18] <infinity> Me.
[08:18] <infinity> Of course, it's no even uploaded yet, so I suppose you are free to argue with me now if you'd like.
[08:21] <floam> I think backwards makes sense
[08:21] <floam> since it goes fowards filling up as you boot
[08:22] <JaneW> infinity heh
[08:22] <JaneW> infinity: I have a mail whining^H asking about it...
[08:24] <infinity> What specifically do they whine about?... Just that they think "backwards is dumb"?
[08:24] <infinity> Does Metallica help with security work?
[08:24] <fabbione> infinity: it keeps me a bit more awake
[08:26] <JaneW> infinity: mail on the way, yeah they think it's dumb, and looks like there's a problem (esp cos of the red)
[08:29] <infinity> Yeah, I was undecided on the red, but probably won't do it (cause red is "alarmist")
[08:33] <jsgotangco> JaneW, re: email WOW
[08:33] <JaneW> jsgotangco: nod
[08:34] <JaneW> jsgotangco: but I didn;t really know what to make of it....
[08:34] <JaneW> fabbione: fuchia?
[08:34] <JaneW> infinity: think he has a valid point though?
[08:34] <fabbione> JaneW: probably.. some kind of fancy women purple
[08:35] <JaneW> fabbione: it's the name of a flower that's why I know it. I have several in my garden ;)
[08:35] <JaneW> heh
[08:36] <JaneW> ok which one of you guys has stolen a penguin?! http://www.iol.co.za/index.php?set_id=1&click_id=29&art_id=qw113500332165B231
[08:36] <infinity> JaneW : About the red?... Probably.  The "why backward" comment was more of an aside.
[08:37] <infinity> JaneW : As for using a progress bar rather than throbber... <shrug>... Personal preference, I guess.  I wouldn't mind the latter, but I doubt we'll do it.
[08:37] <JaneW> ok, I think if anything the red part is a valid concern...
[08:37] <JaneW> the average person would think oh $$#@ what have I done!?
[08:38] <JaneW> fabbione: http://www.denhoedt.nl/hans/031010_fuchia/source/3.html
[08:38] <jsgotangco> JaneW, that guy is like 200% more qualified than me
[08:38] <fabbione> JaneW: SCORE!
[08:38] <JaneW> jsgotangco: but he wants money :P
[08:38] <jsgotangco> JaneW, i've read lots about him, he could actually put order in our doc process....
[08:38] <jsgotangco> JaneW, OH
[08:38] <jsgotangco> i didnt see that in the email
[08:38] <JaneW> jsgotangco: which is why I didn;t want to ignore him....
[08:38] <jsgotangco> argghh
[08:39] <jsgotangco> i didnt see the last line
[08:39] <JaneW> yep, it was all good until that point...
[08:39] <jsgotangco> jeezz
[08:39] <jsgotangco> that just deflated my spirits
[08:40] <JaneW> also why I decided to run it past you before silbs or someone else...
[08:40] <jsgotangco> JaneW, i think we're doing good as a volunteer group IMHO
[08:40] <jsgotangco> but if there's a need for a guy to be paid to do that, well that's a company strategy
[08:41] <whiprush> hey infinity, at UDU we talked about ldap for a bit ... if you had to make a choice today would you be in the openldap camp or the fedora ds camp? (note, if you say neither then that kind of sucks for me.)
[08:42] <whiprush> jsgotangco / JaneW: didn't mean to kill the channel!
[08:43] <jsgotangco> heh
[08:44] <dholbach> good morning developers
[08:45] <seth_k|lappy> morning dholbach :)
[08:45] <crimsun> 'lo daniel
[08:45] <whiprush> hi daniel.
[08:45] <dholbach> whoo guys! how are you?
[08:45] <jsgotangco> JaneW, anyways, despite the background of the guy, its up to you guys based on your strategy
[08:53] <JaneW> jsgotangco: k
[08:55] <lucas> hi
[08:55] <sivang> good morning all
[09:04] <lucas> arg, still no time announced for the CC meeting
[09:28] <sivang> nice, seems mono is fixed?
[09:53] <vamsee> hey guys, this is my first time here... just wanted to give some thanks and leave.
[09:53] <vamsee> I want to congratulate the laptop team. they have done an amazing job
[09:54] <vamsee> my thinkpad works flawlessly with a default breezy install.
[09:54] <vamsee> I had to jump through many hoops to get the same done in debian.
[09:54] <dholbach> vamsee: nice to hear that - i think the laptop guys are on #ubuntu-laptop or something, but yeah - they did a great job :)
[09:55] <jsgotangco> =)
[09:56] <vamsee> jsgotangco: keep at it, there will be many thankful laptop users like me down the line
[09:56] <jsgotangco> vamsee, if you got time to test out dapper, we'd love test data
[09:57] <vamsee> wow. thanks for the offer, I'll think about it. right now, I'm just a web developer with too much on my plate. I'll surely think about it.
[09:58] <vamsee> ok, bye all.
[10:06] <ogra> ENOELMO ??
[10:15] <pitti> Good morning
[10:16] <ogra> morning pitti 
[10:16] <ogra> i'm syncing a new gobby today (hint, hint :) )
[10:21] <Treenaks> Who do I contact for Fridge bugs?
[10:21] <ogra> Treenaks, fridge-devel@
[10:21] <Treenaks> ogra: argh, mail.. ok
[10:21] <ogra> or whiprush, or jdub directly
[10:23] <Treenaks> whiprush: The fridge atom-feed links to 'glossary#term8', which is a relative link, which gets converted to 'http://fridge.ubuntu.com/atom/glossary#term8' -- which doesn't exist.
[11:29] <Kamion> jdub: ttf-dejavu seeded
[11:29] <jdub> Kamion: rocking, thanks :)
[11:29] <paines> hi
[11:30] <paines> i would like to add the emacs-snapshot package from debian-unstable to ubuntu. never done something like this before. are their any tutorials ?
[11:31] <seb128> pool/universe/e/emacs-snapshot/emacs-snapshot_20051215-1_i386.deb
[11:31] <seb128> already to universe
[11:31] <paines> ups
[11:31] <paines> <- blind !
[11:33] <seb128> Kamion: do you do NEW approval for new source packages? gst-plugins-base0.10 gstreamer0.10-ffmpeg are waiting and I'm not sure if elmo is around this week
[11:33] <Kamion> seb128: not normally, no
[11:33] <Kamion> but I can, give me a second
[11:33] <Kamion> elmo was around yesterday judging by activity on ubuntu-changes-auto
[11:34] <Kamion> (the "autosync" is manually started each day by elmo ...)
[11:34] <seb128> k, let them for elmo if he's around, I'll try pinging him
[11:34] <Kamion> doesn't look like he did new yesterday though
[11:38] <Kamion> seb128: gst-plugins-base0.10 and gstreamer0.10-ffmpeg done, although I accidentally sent the first to main
[11:38] <Kamion> do I need to kick that back out to universe, or is it targeted at main RSN anyway?
[11:38] <seb128> Kamion: thanks. Target is main, I want to switch rhythmbox/totem to gst0.10 soon
[11:38] <jdub> (ROCK!)
[11:39] <seb128> :)
[11:40] <seb128> Kamion: we can argue that's a new gst-plugins0.8 version anyway
[11:40] <seb128> should I make a wiki page for its promotion?
[11:40] <siretart> seb128: does gstreamer0.10-ffmpeg include a new copy of ffmpeg?
[11:41] <seb128> new like what?
[11:41] <seb128> newer than ... ?
[11:42] <Kamion> seb128: no need I think, it's obvious
[11:42] <seb128> cool
[11:42] <Kamion> basically existing source, just renamed
[11:43] <seb128> right, part of existing source, they basically splitted to -base/good/bad/ugly
[11:43] <siretart> seb128: I mean with 'new' 'another' copy of ffmpeg
[11:43] <seb128> siretart: that's gst-ffmpeg 0.8 for gst0.10
[11:43] <seb128> no difference
[11:43] <siretart> ok
[11:52] <Kamion> infinity: 2.6.15-9 kernels NEWed, so now's probably a good time for l-r-m
[12:19] <janimo> do others experience given-backs? the error in my case is '/usr/bin/apt-cache failed'
[12:20] <janimo> does giving back a package depend on it's structure too or is it just a build system internal thing
[12:21] <Kamion> internal
[12:21] <Kamion> it generally means your package was unlucky enough to build at a time when apt-ftparchive was running on the master archive; the buildd admin will sort it out
[12:45] <Mithrandir> pitti: thanks for the prod about sane-backends, it had gotten rejected and I hadn't gotten around to doing anything about it.
[12:45] <pitti> Mithrandir: heh, I just wondered about the total lack of an udev rule :)
[12:45] <pitti> thanks for fixing
[12:46] <zul> Kamion: ping
[12:46] <Kamion> zul: hi
[12:46] <Mithrandir> pitti: is it correct that rules are installed to /etc/udev or should they go to /etc/udev/rules.d?
[12:46] <zul> Kamion: did you have a look at the diff yet?
[12:46] <pitti> Mithrandir: they should go to rules.d without any symlink mess
[12:46] <Kamion> ok, looking now
[12:47] <pitti> Mithrandir: oops, did you use symlinks to /etc/udev?
[12:47] <Mithrandir> pitti: no symlinks, but the file is installed directly in /etc/udev.  I can fix that easily enough, though.
[12:47] <pitti> Mithrandir: quick, upload another one until sb notices and you need a proper conffile transition :)
[12:47] <Kamion> zul: in future an interdiff would be easier
[12:48] <zul> ok
[12:48] <pitti> Mithrandir: it should be /etc/udev/rules.d/45-libsane.rules
[12:48] <Kamion> ideally without enormous configure and Makefile.in diffs ... looks like you reran the autotools?
[12:48] <pitti> Mithrandir: files in /etc/udev are not evaluated at all
[12:48] <zul> yeah i did sorry about that
[12:48] <Kamion> zul: oh, vomit, that Ubuntu version thing is FOUL
[12:48] <Mithrandir> pitti: are you sure?  It seems to work on my laptop.
[12:49] <pitti> Mithrandir: pretty sure, yes. And you are sure that you don't have a symlink in rules.d which points to /etc/udev/libsane.rules?
[12:49] <zul> Kamion: how so?
[12:49] <Kamion> I'd rather not include that, it's just too bad
[12:49] <Kamion> +       if echo "$kernel_version" | grep -q ^2.6.8; then
[12:49] <Kamion> +               ubuntu_version="(Ubuntu 4.10)"
[12:49] <Kamion> +       fi
[12:49] <Kamion> come on
[12:49] <Mithrandir> pitti: oops, I do. :-/
[12:50] <zul> Kamion: it was simple to do at the time and it worked
[12:50] <pitti> Mithrandir: just remove both in the preinst and install the new one as normal conffile
[12:50] <Kamion> IMHO it's too sucky to maintain
[12:50] <pitti> carlos: hey, rosetta export is running again?
[12:50] <pitti> carlos: I have a tarball from today (however, it's tiny)
[12:50] <Kamion> I'd rather set up initial values in grub-installer using os-prober (which can extract the version properly) and update those for the current filesystem in update-grub
[12:51] <Kamion> then we can fetch them from lsb_release output rather than messing with a big map of kernel versions to releases
[12:51] <opi> Kamion, also, I was running different kernel on 4.10
[12:51] <Kamion> zul: why the change to automake1.8?
[12:51] <zul> sure...it worked though at the time
[12:52] <opi> Kamion, so this script would fail
[12:52] <Kamion> zul: for you
[12:52] <zul> Kamion: yeah, i didnt automake 1.8 istalled and it couldnt find aclocal-1.8
[12:52] <Kamion> automake1.9 |    1.9.6-1 |        dapper | source, all
[12:53] <pitti> carlos: and it's still called rosetta-breezy; do you import dapper already?
[12:53] <Kamion> ah, debian/rules just needs a one-line fix instead of that
[12:53] <carlos> pitti, I was renabling it yes
[12:53] <carlos> pitti, no, not yet
[12:53] <zul> didnt have automake1.9 installed either
[12:53] <pitti> carlos: any idea why it's only 22 MB?
[12:53] <carlos> pitti, only changes
[12:53] <pitti> carlos: ah, I see
[12:53] <pitti> carlos: any chance to get a dapper tarball?
[12:53] <Kamion> zul: it was already in the build-depends
[12:54] <pitti> carlos: I need to build new langpacks today or tomorrow to rearrange locales
[12:54] <Kamion> zul: there was already debian/patches/raid_cciss.diff for the cpqarray stuff; did you look at why that didn't work before adding another similar patch?
[12:54] <zul> Kamion: ok but aclocal-1.8 is hard coded in the debian/rules
[12:54] <carlos> pitti, for dapper?
[12:54] <Kamion> yeah, fixing that would be a much much much simpler change
[12:55] <pitti> carlos: yes
[12:55] <carlos> pitti, I cannot give you that tarball
[12:55] <zul> Kamion: it wasnt in the lib/device.c so i dont think it would work
[12:55] <carlos> we need gina running on production
[12:55] <carlos> for that
[12:55] <pitti> carlos: ok, then I'll use the buildd output
[12:55] <carlos> and my latest branch merged
[12:55] <carlos> ok
[12:55] <carlos> pitti, as soon as dapper is using Rosetta I will tell you it
[12:56] <Kamion> --- grub-0.95+cvs20040624/lib/device.c  2004-05-23 18:45:35 +0200
[12:56] <Kamion> +++ grub-0.95+cvs20040624.debian/lib/device.c   2004-10-06 13:43:44 +0200
[12:56] <Kamion> bzzt
[12:56] <zul> meh..
[12:56] <Kamion> zul: on the "nitpicky" front, we should stick with upstream's indentation conventions rather than inventing our own
[12:57] <zul> sure..
[12:57] <Kamion> (i.e. two-space indents, GNU-style)
[12:57] <Kamion> ++      for (controller = 0; i < 8; i++)
[12:57] <Kamion> that just looks plain wrong
[12:57] <zul> argh!!!
[12:58] <zul> ok maybe it wasnt quite ready...ill go back to the drawing board
[12:58] <Kamion> and your cpqarray.diff patches a line that was previously added by grub-i2o.diff, which seems redundant :)
[12:58] <seb128> Kamion: could you promote gstreamer0.10 so gst-plugins-base0.10 can build? Thank you :)
[12:58] <Mithrandir> pitti: thanks, uploaded.
[12:59] <Kamion> zul: ok, thanks - the i2o stuff certainly seems necessary once it's fixed, although it clearly needs testing :) I'm less sure about the rest of it
[12:59] <zul> ok well back to the drawing board then
[01:00] <Kamion> seb128: promote which binaries?
[01:00] <zul> Kamion: thanks anyways
[01:00] <Kamion> np
[01:00] <seb128> Kamion: libgstreamer0.10-dev libgstreamer0.10-0 for now
[01:01] <Kamion> seb128: done
[01:01] <seb128> Kamion: other parts will probably need to be seeded or grabbed by Depends
[01:01] <seb128> thanks
[01:04] <jbailey> fabbione: Hey Fabio. =)
[01:04] <jbailey> fabbione: That X driver you gave me doesn't seem to have hung so far.
[01:04] <fabbione> jbailey: that's cool..
[01:05] <fabbione> next upload will have that patch
[01:05] <fabbione> already spoken with daniels
[01:05] <jbailey> fabbione: Is that an expected side effect?  I couldn't remember if there was something more than just debug enabling in here.
[01:05] <fabbione> yes it is expected
[01:05] <fabbione> there is code change compared to the old patch i added a few weeks back
[01:05] <jbailey> Cool.
[01:06] <fabbione> the redrawing issue is something related to the server
[01:06] <fabbione> it's not a driver fault at all
[01:06] <jbailey> Right.
[01:06] <jbailey> It'll just be so sweet if this works.
[01:06] <fabbione> yup
[01:06] <jbailey> You mentioned it was DRM related, does that mean they're growing hardware accell for this card?
[01:13] <fabbione> jbailey: no idea about all details.. i just reported what benh told me
[01:14] <jbailey> fabbione: No worries.  I just want to make sure that if I'm there's other things changing around me, that I'm testing all the needed pieces.
[01:16] <pitti> fabbione: btw, do you see any reason to keep linux 2.6.12 in dapper? it's not patched for security and works poorly with the new udev stuff anyway
[01:18] <fabbione> pitti: not at all
[01:18] <fabbione> we can kill it
[01:18] <pitti> ok
[01:18] <pitti> oh, elmo is not online
[01:18] <fabbione> i want to talk with Ben before we kill it 100%
[01:18] <fabbione> afaik it can't even build in dapper
[01:23] <jbailey> pitti: ia64 and hppa might still need it for booting.
[01:23] <jbailey> pitti: I'm lagged on a klibc upload that they need to boot.
[01:23] <pitti> jbailey: ah, so it's still the default kernel on those arches?
[01:23] <fabbione> jbailey: ia64 boots with .15
[01:24] <fabbione> hppa i need to check .15-rc6
[01:24] <fabbione> rc5 has a problem with the scsi driver and crashes
[01:24] <fabbione> we also need to speedup initramfs for ia64..
[01:24] <jbailey> fabbione: Err, how?
[01:24] <jbailey> fabbione: klibc shared libraries don't seem to work on ia64.
[01:24] <fabbione> it looks like that mckinley generated initrd keeps missing a module
[01:24] <jbailey> BenC tracked down that using the static ones seemed to solve the problem there.
[01:24] <fabbione> jbailey: they still use initrd-tools?
[01:25] <jbailey> They can't with 2.6.15.  initrd-tools needs devfs.
[01:25] <fabbione> dude.. i am sure as hell i did boot .15 on ia64
[01:25] <fabbione> using itanium-smp kernel
[01:25] <fabbione> mckinley no
[01:26] <jbailey> fabbione: I'm not saying that you didn't, I just want to know how. =)
[01:26] <fabbione> apt-get install $random kernel...
[01:26] <fabbione> really.. i did nothing more than that
[01:26] <fabbione> i can check again.. give the time to power them up
[01:29] <sivang> ok, mere panel problems , nothing more :)
[01:31] <fabbione> jbailey: Linux golion 2.6.15-8-itanium-smp #1 SMP Tue Dec 13 05:44:26 UTC 2005 ia64 GNU/Linux
[01:31] <fabbione> Linux baldios 2.6.12-9-hppa32-smp #1 SMP Mon Oct 10 13:32:14 UTC 2005 parisc GNU/Linux
[01:31] <fabbione> as i said.. .15 on ia64 works
[01:31] <jbailey> fabbione: CAn you unpack the initramfs for me
[01:32] <fabbione> i just really installed it from dapper...
[01:32] <jbailey> ?
[01:32] <fabbione> jbailey: of course i can.. what do you want me to check?
[01:32] <jbailey> fabbione: mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img-2.6.15-8-itanium-smp | cpio -i
[01:33] <fabbione> file /boot/initrd.img-2.6.15-8-itanium-smp 
[01:33] <fabbione> /boot/initrd.img-2.6.15-8-itanium-smp: Linux Compressed ROM File System data, little endian size 11010048 version #2 sorted_dirs CRC 0xc8990b8c, edition 0, 2125 blocks, 338 files
[01:33] <fabbione> told you it is still using initrd-tools
[01:33] <fabbione> hey sabdfl 
[01:33] <jbailey> Do you have devfs in that kernel somehow?
[01:33] <jbailey> It should really *not* work...
[01:33] <sabdfl> hey hey
[01:33] <fabbione> jbailey: no..
[01:33] <jbailey> g'day Mark
[01:33] <fabbione> there is no way to have devfs in .15
[01:34] <fabbione> it has been removed from upstream in .13
[01:34] <sabdfl> hiya mvo
[01:34] <jbailey> The reports I had from all over the place were that it failed wildly.
[01:34] <sivang> hey sabdfl 
[01:34] <jbailey> Which makes sense, since there's no device tree.
[01:36] <pitti> hi sabdfl 
[01:38] <fabbione> jbailey: perhaps my ia64 is more clever than the others?
[01:39] <fabbione> jbailey: i really can't say.. my experience on that machine can be counters in hours on the tip of my fingers
[01:39] <jbailey> Feh.  I need to bring my ia64 home.  Having it in Toronto makes boot testing scary.
[01:42] <fabbione> jbailey: i can give you some temporary access for the next week if you want. I will get full console setup between Xmas and newyear mostlikely
[01:42] <jbailey> fabbione: Lemme try to find one more locally.  The lag to your place just kills me for interactive.
[01:42] <jbailey> thanks for the offer, though.
[01:44] <fabbione> jbailey: yes i know :/
[01:45] <jbailey> fabbione: Do you get that sort of lag to the DC?
[01:45] <fabbione> no
[02:17] <zul> heylo
[02:22] <BenC> jbailey: I boot initrd on my ia64 with 2.6.15
[02:22] <BenC> still works
[02:27] <zul> Kamion: ping...how does os-prober work?
[02:29] <Kamion> zul: it runs in the installer, mounting each filesystem it can find in turn and poking about in it using a variety of methods to figure out the OS version
[02:29] <Kamion> it shouldn't be used in a normal system
[02:30] <zul> ok..
[02:33] <zul> just trying to figure out a better way to do the version number stuff
[02:47] <thesaltydog> what time is it the CC meeting?
[03:07] <Pygi> welcome mxpxpod
[03:07] <mxpxpod> hey Pygi 
[03:16] <jbailey> fabbione: X hung again, no message in the X log at all.
[03:16] <jbailey> fabbione: It did hold up *much* longer than the previous one, though.
[03:29] <Pygi> welcome vuntz, mvirkkil, akatemik ;)
[03:30] <Akatemik> Grah. Unbelievable brokedown at uni network
[03:30] <zakame> heya Pygi 
[03:30] <Akatemik> NFS-servers are still down, so no home-folders.
[03:31] <pappan> i am tired looking for a project to work for
[03:31] <pappan> where can i find some projects in ubuntu which needs some coders
[03:33] <zul> pappan: #ubuntu-motu
[03:33] <pappan> or atleast something thru which i can contribute to ubuntu
[03:35] <pappan> zul: ty
[03:37] <fabbione> jbailey: try disabling dri
[03:42] <jbailey> fabbione: Well, I'm less worried about working around the problem than I am about making sure that I give you a decent bug report so that it's fixed in time for Dapper.
[03:43] <fabbione> jbailey: i dunno how to. You need to talk with daniels and benh for that.
[03:43] <fabbione> jbailey: but isolating the issue in the first place to a config option will help
[03:44] <jbailey> How close is our X code to upstream?  Will talking to BenH be useful?
[03:44] <jbailey> I don't usually like to annoy upstream directly with bugs that might be in Ubuntu and not elsewhere.
[03:44] <fabbione> our code is the same upstream afaik
[03:45] <fabbione> in the actual pkg -ati is rc3 + benh patch that's already in daniels rc4 tree and next ati package
[03:45] <fabbione> so no difference afaict
[03:56] <jbailey> Cool, thanks
[03:56] <jbailey> I'll try and catch him online later, then.
[04:36] <pitti> Kamion: what would be your preferred interface in the installer to set up and generate the default system locale?
[04:36] <pitti> Kamion: a particular way of calling locale-def?
[04:36] <pitti> Kamion: erm, locale-gen
[04:36] <Kamion> anything vaguely similar to what localechooser's post-base-installer script does now is fine
[04:37] <Kamion> if it gets simpler, bonus
[04:37] <pitti> no idea about that - does it add the locale to /etc/locale.gen?
[04:38] <Kamion> yes
[04:38] <pitti> Kamion: would 'locale-gen xx_YY.UTF-8' be fine for you?
[04:38] <pitti> since we don't have /etc/locale.gen any more
[04:38] <Kamion> if validlocale says it isn't there yet
[04:38] <Kamion> and then calls locale-gen --keep-existing
[04:38] <Kamion> pitti: sure, that's fine
[04:38] <pitti> Kamion: alternatively, adding to /var/lib/locales/supported.d/local would do the same, but that should be hidden probably
[04:39] <Kamion> could it take one or more locales on the command line rather than just one, and also silently skip doing anything if the locale you give it already exists?
[04:39] <Kamion> I definitely prefer just calling locale-gen to editing some random file
[04:39] <pitti> Kamion: sure, it would imply --keep-existing
[04:39] <pitti> and multiple locales should be easy to do
[04:40] <pitti> Kamion: what's the installer's use case for multiple locales?
[04:40] <pitti> Kamion: locale-gen already supports generating all locales for a particular language, do you need sth similar?
[04:40] <Kamion> pitti: (a) mdz asked that we always generate English, no matter what the installation language
[04:41] <pitti> ah, right
[04:41] <Kamion> pitti: (b) in expert mode you can select exactly what locales you want
[04:41] <Kamion> (as a multiselect)
[04:41] <pitti> ok, thanks
[04:41] <Kamion> any objections to me removing the casper seed, which IMO is now obsolete? speak now or forever hold your peace ...
[04:42] <siretart> doko: I have a package, which needs 'just' python2.x-twisted-bin, not the complete python2.x-twisted (and the zopeinterface). I notice that there is no dummy package 'python-twisted-bin', but just a 'python-twisted'. 
[04:42] <tepsipakki> great! you seem to have hit the nail here, I just installed dapper and noticed that I got a bunch of unneeded locales ;)
[04:42] <Kamion> tepsipakki: depends on your definition of "needed"
[04:43] <tepsipakki> kamion: most of the en_* -stuff
[04:43] <Kamion> I doubt that will change
[04:43] <tepsipakki> because I preseed them
[04:43] <tepsipakki> duh
[04:43] <ogra> that wont go away, see above
[04:43] <siretart> doko: I think it would be sensible to introduce a 'python-twisted-bin' dummy package to depend on the 'default python' twisted-bin package, so I don't need to maintain a patch for my package in ubuntu
[04:44] <Kamion> Mithrandir: any chance of probing the framebuffer modules relatively early in casper startup, so that if you select a video mode other than plain VGA in the bootloader, you get to still see the startup?
[04:45] <tepsipakki> ogra: hmm, I came in the middle of the discussion.. but do you mean that regardless what I tell the installer, I'm still going to get the default locales as well?
[04:45] <ogra> tepsipakki, see option (a) Kamion talked about ...
[04:46] <tepsipakki> but there are like twenty of them..
[04:46] <tepsipakki> and all I need is one, plus fi* and sv*
[04:46] <ogra> yes, i know :)
[04:46] <tepsipakki> bugger
[04:46] <CarlFK> https://wiki.ubuntu.com/MarksHoaryGoals "Nice To Have ... fax support" - Is there any more to this?  If not, I'll make a wiki page or something of "how to fax"
[04:46] <tepsipakki> a regression to breezy
[04:46] <tepsipakki> from..
[04:47] <ogra> nope
[04:47] <ogra> its aleays been like this ...
[04:47] <ogra> *always
[04:47] <tepsipakki> yes it is, I can install a breezy for you to see ;)
[04:47] <tepsipakki> preseeded netboot
[04:47] <Treenaks> CarlFK: we need it to be easy, like in other Oss
[04:47] <tepsipakki> -install
[04:48] <ogra> tepsipakki, we're talking about the default install 
[04:49] <tepsipakki> ogra: yes, well I'm not ;)
[04:49] <CarlFK> Treenaks: I thought I had seen a "fax printer driver" in some distro - probably FC2...   
[04:49] <tepsipakki> ogra: but still at the moment the result is the same
[04:49] <tepsipakki> but if it is known, I won't bother you ;)
[04:49] <Treenaks> CarlFK: http://www.linuxprinting.org/cups-faq.html#q_2_15
[04:50] <CarlFK> Treenaks: is anyone working on a faxing in Ubuntu ?
[04:51] <Treenaks> CarlFK: not that I know of, but have a look at that link
[04:51] <ogra> there is gfax+efax ...
[04:54] <CarlFK> I want to help, just not sure where to start.
[04:55] <Kamion> tepsipakki: breezy had the same code
[04:55] <CarlFK> searched around and that Mark page was the closest thing I could find to someone doing something
[04:55] <Kamion> although you're right that it shouldn't override preseeding; that's a bug
[04:55] <tepsipakki> kamion: yes
[04:56] <Kamion> (the comment in the code says "Always support English (unless preseeded otherwise)")
[04:56] <Kamion> file a localechooser bug
[04:56] <tepsipakki> ok
[04:57] <tepsipakki> otherwise netboot seems fine, but the problem that network is not started at boot is a bit annoying ;)
[04:57] <doko> siretart: the pythonX.Y packages for twisted will go away soonish anyway
[04:59] <siretart> doko: can you give I timeframe? I want to decide if I should rather wait with an upload or fix it right away
[04:59] <doko> siretart: this year
[05:00] <siretart> doko: ok, then I'll wait. cheers!
[05:00] <ogra> Kamion, what do you think about a preseeding option for fonts that supresses the fontconfig call in postinst ... so we could run fontconfig once in the end of the install instead of 10 times 
[05:00] <ogra> installing the fonts is still the most slowing down part in the installer ...
[05:02] <janimo> I have a library packaging question
[05:02] <janimo> libgoffice can be built with or without gnome libs
[05:02] <janimo> if I have two different debs with the two options
[05:02] <janimo> can they have the same lib names provided the API is the same and only the impl details differ?
[05:03] <janimo> also, I make the packages conflict each-other? add update-alternatives in the mix?
[05:03] <janimo> alternatively there can be a libgoffice.so and a libgoffice-gtk.so
[05:04] <janimo> and they can coexist on the system
[05:05] <janimo> the latter option means a package which uses goffice( gnumeric) should explicitely say it builds agains one or the other
[05:05] <janimo> and cannot just pick up the available one provided in build-deps
[05:06] <janimo> if you know source packages which provide binaries like I described I'd go and study what they do
[05:12] <seb128> janimo: no
[05:12] <seb128> janimo: we are not going to do that for sure
[05:13] <janimo> seb128, I am talking about debian upstream
[05:13] <seb128> same
[05:13] <janimo> anyway the question was purely technical at this point
[05:13] <seb128> 2 packages shipping the same lib file with different API is not going to happen
[05:13] <janimo> did you read what I wrote?
[05:13] <janimo> same API different impl
[05:13] <seb128> what is "impl"?
[05:14] <janimo> AFAIK libgoffice exports same api in both cases
[05:14] <janimo> implementation
[05:14] <janimo> only some are stubs or less featureful in non-gnome case
[05:14] <janimo> how do tyou think gnumeric runs on windows?
[05:14] <seb128> that's not the same ABI if the functions don't return the same objects
[05:14] <janimo> you said API
[05:15] <janimo> I did not look that close to see what ABI is
[05:15] <janimo> but I assume is the same
[05:15] <janimo> it is C no?
[05:15] <seb128> why di you need 2 variants if that's exactly the same API/ABI?
[05:15] <janimo> return NULL instead of a valid gnome object or something like that
[05:15] <janimo> because one brings in friggin bonobo&co
[05:16] <janimo> while the other does not
[05:16] <janimo> and still works
[05:16] <seb128> it if brings extra stuff the AB I is probably not the same
[05:16] <seb128> ABI/API
[05:16] <janimo> one uses glib_uri_from_display the other vfs
[05:16] <janimo> the same objects in and out just different inside
[05:17] <seb128> k
[05:17] <janimo> if it were different API's I don;t think gnumeric devs would have done it in the firts place
[05:17] <seb128> different API works fine
[05:17] <seb128> you just have to #ifdef GNOME
[05:17] <seb128> #ifdef GNOME
[05:17] <seb128> code_path1
[05:17] <seb128> #else
[05:17] <seb128> code_path2
[05:18] <janimo> yeah I know
[05:18] <seb128> works pretty fine for a limited set of functions
[05:18] <janimo> upstream packager of goffice and gnumeric said if I make the pacthes he'd take them
[05:18] <janimo> but he personally won't
[05:18] <seb128> JHM?
[05:18] <janimo> so I am trying to make those patches and asked for advice not flamage 
[05:19] <janimo> yes Ray Dassen
[05:19] <seb128> there is no flamage
[05:19] <seb128> but using alternatives for that would be the ugliest stuff ever
[05:20] <janimo> I think current gnome lib dependency hell is way uglier
[05:20] <janimo> many apps bring in the whole thing just for calling gnome_program_init instead of gtk_init
[05:20] <janimo> _that_ is ugly and wasteful too
[05:21] <seb128> if you are sure there is 0 API/ABI difference you can make 2 differents packages conflicting each other and Build-Depends on the right one
[05:21] <janimo> but YMMV :)
[05:21] <seb128> and I'm the one starting a flame...
[05:21] <janimo> exactly what I did before asking if they can provide the same lib names
[05:22] <janimo> so I made two debs with different names conflicting on eachother
[05:22] <janimo> but the question is, if API is the same can they provide libs with the same name? 
[05:23] <janimo> so libgoffice-gtk.deb provides goffice.so and libgoffice.deb does the same
[05:23] <seb128> if the ABI and the API are the same
[05:23] <seb128> ie: if you are *sure* they return the same object
[05:23] <seb128> and have the same working logic
[05:23] <janimo> same _type_ of object
[05:23] <seb128> same logic too
[05:24] <seb128> if one never returns NULL and the other do that's a difference of ABI
[05:24] <janimo> well the interface is that matters not the internal logic right?
[05:24] <eruin> infinity, I spoke too soon.. fixing dri == regular crashes ;)
[05:24] <seb128> because the app can expected never getting NULL
[05:24] <seb128> right
[05:24] <janimo> yeah, if it does not check for null that's a bug not an API question :_
[05:24] <seb128> but if the possible return values are differents that's an ABI difference
[05:24] <janimo> right
[05:25] <seb128> s/ABI/API/
[05:25] <janimo> anyway I want to send this to debian, so whether he tales it or not you/gnome are not affected
[05:25] <janimo> s/tals/takes/
[05:25] <seb128> yeah
[05:25] <seb128> that's just going to make extra duplication
[05:25] <seb128> but we start beeing used to that
[05:26] <janimo> upstream provides configurability
[05:26] <janimo> why shouldn't debian take advantage?
[05:26] <seb128> yeah, rhythmbox has a zillion of option
[05:26] <janimo> I do not propose providing debs for all possible permutations of configure flags though :)
[05:26] <seb128> we don't do 15 packages one with tag writing, one with cd recording, one with no feature, one with podcast, etc
[05:26] <janimo> just two options : bloat and light
[05:27] <seb128> as said if the Debian maintainer wants to go on this path up to him
[05:27] <jsgotangco> night
[05:27] <janimo> I'd like to have gnumeric just like abiword part of the default desktop
[05:27] <pitti> Kamion: ok, 'locale-gen' and 'locale-gen de fr_FR.UTF-8 en_US' will now DTRT
[05:27] <seb128> janimo: the default desktop has all the libs you call "bloated"
[05:28] <pitti> seb128: that should also satisfy the 'generate additional locales' case
[05:28] <seb128> pitti: cool :)
[05:28] <seb128> pitti: do we keep the ability to let translator fix their locales for stuff like "start of the week is monday" with the new system?
[05:28] <Riddell> fabbione: a question from KDE, will extattr be in the dapper linux?
[05:29] <desrt> Riddell; they're in breezy....
[05:29] <pitti> seb128: sure, we just need to update the locales package
[05:29] <ogra> isnt it already ?
[05:29] <pitti> seb128: it's easy now since it is a separate source
[05:29] <seb128> pitti: "just"
[05:29] <seb128> ok
[05:29] <ogra> Riddell, you need to enable it in fstab afaik
[05:29] <pitti> seb128: my start of the day is broken, too (starts on Tuesday ATM)
[05:29] <Riddell> ogra: dunno, I'm just passing on the question :)
[05:29] <fabbione> Riddell: extatrr?
[05:29] <seb128> because we "just" needed to do that before too, but nobody wanted to take the responsability to changes locales stuff :p
[05:29] <desrt> fabbione; filesystem extended attributes
[05:29] <pitti> seb128: as soon as we have Rosetta integration of locales, we need to think about it again
[05:29] <seb128> ok
[05:29] <pitti> seb128: but in general, updating langpack-locales source is easy
[05:30] <ogra> fabbione, he maeans the user_xattr mount option ...
[05:30] <fabbione> we already have them enabled..
[05:30] <desrt> Riddell; just toss 'user_xattr' in t... ya.  what he said :)
[05:30] <ogra> :)
[05:31] <fabbione> i dunno.. 
[05:31] <jsgotangco> good night
[05:35] <Kamion> ogra: preseeding would be inappropriate there; there's another better option which I already know how to implement, and will do as soon as I have time to test it
[05:36] <Kamion> ogra: namely diverting fc-cache during base-config
[05:36] <Kamion> pitti: great, thanks
[05:36] <ogra> Kamion, ah, great :)
[05:37] <Riddell> infinity: no new ubuntu-artwork?
[05:37] <pitti> Kamion: I explained the changes and the potential dist-upgrade breakage in an u-d-a mail
[05:37] <dholbach> have a nice evening guys :)
[05:37] <ogra> it always bothered me that it takes so much time :)
[05:37] <ogra> dholbach, have fun playing with the ar :P
[05:37] <ogra> *car
[05:37] <dholbach> oh yeah, thanks - enough time to play :)
[05:37] <ogra> heh
[05:43] <sivang> ogra: dholbach got a new car?
[05:50] <Kamion> tepsipakki: why do you set the owner of localechooser/supported-locales to be base-config? that's just bizarre :)
[05:50] <Kamion> not that it actually matters, but
[05:50] <tepsipakki> hum
[05:50] <tepsipakki> wait
[05:51] <tepsipakki> it was from some example, I think
[05:51] <Kamion> "d-i" is the usual owner for anything in the first stage
[05:53] <tepsipakki> seems that the "d-i" version gets preseeded by the one I'm using..
[05:53] <tepsipakki> but I'll change it
[05:54] <Kamion> it just sets the owner in the debconf database, it's not a different namespace or anything
[05:56] <tepsipakki> okay
[05:57] <tepsipakki> base-config is not yet obsoleted for dapper? I remember that Joey intends to get rid of that phase
[05:57] <Kamion> not quite yet, no
[05:58] <Kamion> I'm not yet sure whether it'll land for dapper, although I hope it will
[05:58] <Kamion> I've been fairly involved with a lot of that upstream
[05:58] <tepsipakki> cool
[05:59] <tepsipakki> no news regarding preseeded LVM-setups ?
[06:00] <Kamion> no
[06:00] <Kamion> well, that's not quite true, Fabio's been doing some work on things that would be needed for that, but AFAIK it's not remotely all there yet
[06:01] <tepsipakki> yes I saw the upstream changelogs, but couldn't quite parse all of it
[06:01] <Kamion> it's been more about adjusting the existing recipes to play more nicely with LVM
[06:05] <fabbione> Kamion: doesn't preseeding just pre-answer the debconf questions?
[06:06] <fabbione> and set them in a way that won't be asked?
[06:06] <fabbione> or the pkg itself needs to take care of that?
[06:07] <Kamion> fabbione: it just pre-answers, yes
[06:07] <fabbione> Kamion: ok, than i don't see what i need to do differently.. really.. i do ask debconf questions like any other d-i package in this world.
[06:08] <fabbione> meh.. tepsipakki 
[06:08] <fabbione> the same way you preseed partman-auto, you can preseed -lvm
[06:08] <Kamion> fabbione: no
[06:09] <Kamion> fabbione: the problem with complicated partman preseeding is that doing stuff like LVM and RAID in partman involves a control loop, where d-i asks the same question more than once and you need to provide different answers
[06:09] <fabbione> ahhhhh
[06:09] <fabbione> ok
[06:09] <fabbione> i understood partman-auto-lvm
[06:09] <fabbione> not just LVM
[06:09] <Kamion> normal partman preseeding basically works around this, by providing a mechanism where you can specify a single recipe that describes in one go what partman needs to do
[06:09] <Kamion> in order to make LVM preseeding work, we need to allow the recipe format to describe a full LVM partitioning scheme
[06:09] <fabbione> yeah i understand what you mean
[06:10] <fabbione> sorry i was out of context
[06:10] <tepsipakki> I tried to debug this a month ago (?), and we talked about it then
[06:10] <fabbione> no, there is no plan for me to work on making that to work
[06:10] <fabbione> my target was only partman-auto-lvm
[06:11] <tepsipakki> how hard would it be for me to make it?-)
[06:12] <Kamion> tepsipakki: you'd have to fully grok the design of partman recipes
[06:13] <tepsipakki> gah
[06:13] <Kamion> and then work your way through some somewhat arcane shell code
[06:13] <Kamion> but I'm sure it would be possible
[06:13] <Kamion> it's not rocket science, just messy :)
[06:13] <seb128> Kamion, infinity, lamont: could you give a buildd retry on dbus/amd64?
[06:17] <janimo> seb128, when I meant default desktop 50 minutes ago I meant xfce desktop not gnome
[06:17] <seb128> janimo: I figured :)
[06:17] <janimo> :)
[06:37] <slomo_> infinity / lamont: please give-back gst-plugins-base0.10 on x86 and after it built gstreamer0.10-ffmpeg everywhere... thanks :)
[06:38] <janimo> infinity/lamont same for xubuntu-default-settings, thanks
[06:39] <seb128> slomo_: how does base require ffmpeg?
[06:39] <seb128> slomo_: other way probably no?
[06:40] <seb128> oh, I misread
[06:40] <seb128> :)
[06:40] <ogra> hmm, dholbach didnt fix the broken firefox upload ? 
[06:40] <slomo_> seb128: ok :)
[06:41] <seb128> ogra: which one?
[06:41] <ogra> seb128, amd64 is ftbfs 
[06:41] <seb128> oh
[06:41] <ogra> due to libssl it seems
[06:43] <Kamion> hmm, ubuntu-desktop uninstallable on all arches again
[06:43] <ogra> oops, why ?
[06:43] <Treenaks> totem
[06:43] <Kamion> you can find out about as quickly as I can
[06:43] <ogra> i only see totem ...
[06:43] <Treenaks> at least, on amd64 it's totem (= 1.2.1) vs 1.3.x
[06:43] <ogra> but not on all arched
[06:43] <Kamion> http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html, as usual
[06:43] <ogra> arches 
[06:44] <Kamion> people should bookmark that :)
[06:44] <ogra> heh, i'm to lazy, i always look at cdimage, so i can check the CD sizes with one look
[06:44] <ogra> phew, thats a lot
[06:45] <Kamion> ah, hal needs to switch to the new dbus
[06:45] <seb128> right
[06:45] <seb128> it breaks half of the world
[06:45] <seb128> pitti said he wants to try before uploading but new dbus hasn't built yet on amd64
[06:46] <Kamion> doesn't help that it FTBFS on amd64/powerpc
[06:46] <seb128> and he went to bed for today anyway
[06:46] <Kamion> can a mono person please look at these build failures?
[06:46] <seb128> Kamion: a retry on amd64 should do the try (I've asked so some time ago)
[06:46] <seb128> s/try/trick/
[06:46] <Kamion> ok, will do now
[06:46] <Kamion> how about powerpc?
[06:46] <seb128> according to slomo_ that's a mono issue
[06:47] <seb128> slomo_: dbus/ppc? :)
[06:47] <slomo_> dbus ppc will work soon
[06:47] <Kamion> dbus/amd64 given-back; I'm off for dinner
[06:47] <seb128> thanks
[06:47] <slomo_> but for mono... no idea, upstream knows about it and rated the bugreport "minor" *sigh*
[07:06] <ptlo> i don't know if its the right chan, but just a quick questions - if i'm translating breezy packages in rosetta now, will [or, can at all]  the translations be transferred to dapper, or should i just go ahead and translate just dapper?
[07:15] <toresbe> ptlo: This is an unqualified guess, but I believe the strings that are identical are carried through
[07:15] <toresbe> WHOA.
[07:15] <toresbe> what just happened there
[07:15] <eruin> ?
[07:15] <toresbe> Sorry, had a kernel..happening all over my terminal
[07:16] <ptlo> yeah....that's the [educated guess]  reply that i've got on other channel too. i'm just wandering, how and wen the transfer is done - since, for example, right now i can modify both breezy and dapper translations - so at some point, breezy ones will have to overwrite dapper ones
[07:16] <toresbe> complete with a call trace etcetera. Thought I was in a different channel
[07:20] <ptlo> i'm afraid the kernel cares little about on which particular irc channel you chat at the moment ./
[07:47] <Kamion> ptlo: if you want an authoritative answer you'd need to ask #launchpad
[07:47] <ptlo> oh, that's the place. thanks, i tried #rosetta, but i was pretty lonely there .-] 
[08:11] <Kamion> hmm, I'm getting a segfault in the gtkmozembed python module; does it need to be rebuilt for firefox 1.5?
[08:14] <seb128> no, it needs to be debugged
[08:14] <seb128> I think mvo did some debugging on it and said it's a firefox bug
[08:14] <seb128> mvo?
[08:21] <mvo> Kamion: yes, firefox bug, happend after the ff 1.5 upgrade
[08:21] <mvo> Kamion: #20338 has a test-case and backtrace etc
[08:22] <slomo_> lamont / infinity: can you give me hardware details about the ppc buildds? mono upstream asks for it...
[08:23] <mvo> slomo_: what do you need?
[08:23] <infinity> Is it so difficult to figure out what changed between mono 1.1.10 and 1.1.11 that made it stop failing?
[08:24] <infinity> Anyhow, the buildds are all Apple Xserve Dual G5s, running ppc64 kernels, but the builds happen in a "linux32" environment, so from the build perspective, it should appear as a normal ppc32 system.
[08:24] <slomo_> infinity: it's between 1.1.10 and 1.1.10.1... they say there were only few changes, nothing that could cause it... and it works fine on osx with a smp g5 running 32bit userland
[08:24] <slomo_> infinity: ok, thanks :)
[08:25] <infinity> And no, we definitely will NOT hand-compile binaries (especially not stuff that's in main, it's just not supportable in the least)
[08:26] <infinity> So, if it's a problem with the buildd configs, we need to figure that out, if it's a problem with upstream's code (more likely), we need to fix that.
[08:26] <infinity> The fact that it just built fine on my ppc32 system isn't really all that useful to know. :)
[08:27] <slomo_> infinity: mvo reproduced it on another ppc64 with 32bit userland
[08:28] <mvo> slomo_, infinity: actually I reproduced it on "davis", one of our machines. not sure how much that counts :)
[08:28] <janimo> infinity, can this be unstuck somehow? http://people.ubuntu.com/~lamont/buildLogs/x/xubuntu-default-settings/0.2/
[08:28] <infinity> mvo : Counts fine, since it eliminates gcc-opt and other fun as the possible cause.
[08:29] <infinity> mvo : So, it could still be a bug in our userland (gcc, glibc, who knows), but definitely not a bug specific to the buildds.
[08:29] <mvo> infinity: right. I'm building 1.1.10 on the same machine/config that 1.1.10.1 segfaulted on now
[08:30] <infinity> janimo : I gave it a whack just a while ago.
[08:30] <Robi-> anyone have a shuttle sff pc with those usb wifi cards built in?
[08:30] <janimo> infinity, thanks
[08:30] <infinity> mvo : Thanks, dude.
[08:33] <Robi-> the PN15 or AirVast card doens't get detected properly by prism2_usb
[08:33] <infinity> Rob- : Haven't you been in and out, complaining about this for the last day or two?
[08:33] <mvo> woah, segfault for 1.1.10 as well
[08:33] <slomo_> infinity, mvo: thanks for your time :)
[08:34] <infinity> Robi- : I'd recommend filing a bug.
[08:34] <zul> Robi-: can you please open a bug..kthxbye
[08:34] <mvo> ^--- slomo_ 
[08:34] <slomo_> mvo: uh... so let's look what changed in that month...
[08:34] <Robi-> no i've been trying to find a solution
[08:35] <mvo> slomo_: http://paste.ubuntu-nl.org/5963
[08:36] <infinity> mvo : dpkg -l gcc-4.0 libc6-dev linux-kernel-headers binutils
[08:36] <slomo_> mvo: yes, seems to be the same...
[08:37] <mvo> infinity, slomo_ http://paste.ubuntu-nl.org/5964
[08:39] <infinity> That's davis?
[08:39] <infinity> That chroot is way out of date.
[08:39] <infinity> Which is helpful in this case.
[08:39] <mvo> yes, davis
[08:40] <infinity> The only thing different between that chroot and the chroot where 1.1.10 built successfully is libc6.  libc6-dev_2.3.5-1ubuntu15 versus libc6-dev_2.3.5-1ubuntu16
[08:40] <infinity> Which would be a useful data point, if libc6's changelog mentioned anything at all about powerpc between 15 and 16... :/
[08:41] <tseng> yay for clues
[08:42] <slomo_> and 15 and 16 are nowhere anymore :/
[08:42] <janimo> is dbus-1-1 going to stay around too or everything gets rebuilt
[08:43] <mvo> janimo: everything will be rebuild
[08:43] <tseng> slomo_: snapshot?
[08:43] <janimo> mvo, and for apps which are still using 0.50 do we fix them?
[08:43] <slomo_> infinity: no kernel changes between 24.11. and 15.12.?
[08:43] <infinity> slomo_ : Nope.
[08:43] <janimo> or is 0.60 backwards compat?
[08:44] <mvo> janimo: yes, it's mostly a rebuild. only rhythmbox gave us a bit of trouble
[08:44] <janimo> just want to know if it's time to rebuild/upload some packages
[08:44] <mvo> but nothing can give you real trouble if seb128 is around :)
[08:44] <seb128> ah ah
[08:44] <slomo_> infinity: ok, glib has changed since then too... and mono uses glib (2.8.X to 2.9.0)
[08:44] <seb128> don't blame GTK
[08:44] <seb128> you .... freak!
[08:45] <tseng> iz glib boog
[08:45] <mvo> haha
[08:45] <slomo_> seb128: i don't blame anyone :P i only search for relevant changes in that timeframe
[08:45] <janimo> is this a mono/glib thing FTBFS or runtime breakage?
[08:45] <tseng> ftbfs on ppc
[08:45] <tseng> (64?)
[08:46] <slomo_> tseng: on a normal ppc it works fine... at least for me
[08:46] <janimo> link or exact package name?
[08:46] <janimo> a mono 1.1.12?
[08:46] <tseng> source is 'mono'
[08:47] <infinity> slomo_ : Did glib change between 1.1.10 and 1.1.10.1?
[08:47] <slomo_> infinity: yes
[08:47] <infinity> slomo : Ahh, maybe we're poking too low-level then.  Might not be toolchain breakage at all, might be glib...
[08:48] <janimo> oh, FTBFS but because of mono runtime errors
[08:48] <infinity> mvo : What's the version of glib stuff on davis?
[08:48] <janimo> i.e not a gcc error but a mono compiler thing
[08:48] <tseng> i find it unlike that glib has odd arch specific breakage in a point release after all this time
[08:48] <mvo> infinity: 2.9.0-0ubuntu1
[08:48] <seb128> tseng: it's 2.8 to 2.9
[08:48] <seb128> tseng: so not a point
[08:49] <tseng> huh ok
[08:49] <infinity> tseng : Also, weirder things have happened.
[08:49] <infinity> Maybe glib is doing Very Bad Things in this release...
[08:49] <tseng> this is true
[08:49] <tseng> i would be pretty happy if it wasnt mono :)
[08:50] <infinity> It could still be toolchain breakage, though (binutils breaking glibc, or somesuch), but I do like the "blame glib" idea better.
[08:50] <jbailey> Strangely enough, so do I. =)
[08:50] <slomo_> hehe
[08:50] <infinity> I'll have to dig up some old glib sources and rebuild it to test the theory.
[08:50] <jbailey> I think we have concensus.
[08:50] <seb128> grrrrr
[08:51] <jbailey> seb128: You're just bitter because it starts with "g"
[08:51] <jbailey> =)
[08:51] <seb128> not really, glibc would start with a g too
[08:51] <seb128> and curiously I would not grrrrr to it :)
[08:52] <jbailey> seb128: Right, but I thought you were taking that from me? =)
[08:53] <mdke> is there a new kernel coming?
[08:53] <seb128> jbailey: nah
[08:53] <mdke> a post on a bug report yesterday said to test with a new kernel, but one hasn't appeared...
[08:54] <seb128> 5049 ?
[08:54] <seb128> (aka eject bug)
[08:54] <mvo> everyone knows that everything starting with "g" is a seb package
[08:54] <Kamion> mdke: already in the archive
[08:54] <mdke> Kamion, hmm *looks*
[08:54] <Kamion> (since this morning)
[08:55] <mdke> Kamion, i don't see it on gb.archive
[08:55] <Kamion> gb.archive is master
[08:55] <Kamion> and it's there
[08:55] <Kamion> 2.6.15-9
[08:56] <mdke> perhaps I'm missing a metapackage
[08:56] <Kamion> linux-meta hasn't been updated yet
[08:56] <mdke> ahhh
[08:58] <mdke> thanks Kamion 
[08:58] <mdke> hope your cold is better!
[08:58] <Kamion> marginally :-/
[08:59] <mdke> jack the old vitamin C
[09:02] <infinity> mdke : linux-meta wont's be updated until an amd64 header problem is resolved.
[09:03] <mdke> infinity, no problem. Did you test the new kernel on that ata2 error?
[09:04] <infinity> mdke : Not yet, no.
[09:04] <infinity> mdke : it's 7am, give me a break. ;)
[09:05] <mdke> lol
[09:05] <mdke> fair enough
[09:05] <seth_k|lappy> seb128, ping
[09:10] <seb128> seth_k|lappy: pong
[09:10] <infinity> Kamion : Care to NEW LRM on !amd64?
[09:10] <mvo> ping Riddell 
[09:11] <Riddell> mvo: hi
[09:11] <slomo_> gn8 everybody
[09:11] <seb128> 'night slomo_
[09:12] <seth_k|lappy> hi seb128 :) I was wondering if you would poke libgpod 0.3.0 into main for me, because gtkpod 0.99 requires it and I was hoping to get that in. In case you don't want to do it yourself, I posted it here: http://revu.tauware.de/details.py?upid=1252 (it drops the patch you added earlier since it is incorporated upstream, but makes no other changes)
[09:12] <seth_k|lappy> seb128, I thought I would talk to you since you seem to care for that package
[09:12] <seb128> seth_k|lappy: I'll update, I didn't notice there was a new tarball
[09:12] <seth_k|lappy> thanks :)
[09:12] <seb128> yeah, rhythmbox uses it
[09:14] <seb128> time for dinner now but I'll do that after it
[09:15] <seth_k|lappy> i appreciate it
[09:15] <Kamion> elmo: can you do l-r-m? you probably have more of the finger-macros for it than I d
[09:15] <Kamion> do
[09:15] <elmo> k
[09:16] <Kamion> ta
[09:17] <pitti> elmo: can you please sync sysfsutils from debian/incoming?
[09:17] <elmo> pitti: no - not unless it got uploaded in the last 20mins; it's in limbo between incoming and the archive
[09:17] <infinity> elmo : Oh, hi.  Not used to you being awake at the same time as I am, or I would have sent that NEW request to you. :)
[09:17] <pitti> elmo: ah, ok.
[09:23] <ogra> oh, Riddell, thanks for the edubutnu-artwork fix ...
[09:34] <Riddell> ogra: I updated all of them, wonder if there's an xfce one to do yet
[09:35] <ogra> i think so ...
[09:35] <ogra> janimo will know
[09:35] <janimo> yes, xubuntu-docs is still in NEW
[09:35] <janimo> I am just dling kubuntu-docs to get an example of how u-a is done
[09:36] <janimo> and when it get into dapper I'll fix it
[09:36] <mdke> Riddell, did you do the joint source thing for (k)u-docs?
[09:37] <Riddell> mdke: no
[09:38] <mdke> ah, i saw some cool-looking stuff happening in there
[09:38] <mdke> has anything changed for the purposes of the ubuntu-docs packaging?
[09:38] <Riddell> nope
[09:38] <Riddell> but I did the serverguide with froud's KDE stylesheet and xsltproc
[09:39] <Riddell> so we'll just have to have it uncompressed and not looking the same as the rest
[09:39] <mdke> Riddell, how different are they?
[09:40] <Riddell> very
[09:40] <mdke> oh dear
[09:40] <mdke> Riddell, so how did you get it working without the external? you've moved some stuff into trunk/debian?
[09:41] <Riddell> mdke: no I just move kubuntu/debian to a directory below for the packaging
[09:41] <mdke> Riddell, ahh. but you have definitely added some stuff to trunk/debian in the repo
[09:43] <Riddell> mdke: that's for the update-alternatives
[09:44] <mdke> Riddell, hope you don't mind explaining this stuff to me, I'm a bit of a thick with this stuff: what is update-alternatives?
[09:45] <Riddell> mdke: we have the issue of clashing index pages for firefox
[09:46] <Riddell> so we're using update-alternatives to set up a symlink in /etc/alternatives to the one in {ubuntu,kubuntu,edubuntu}-docs
[09:46] <mdke> Riddell, ah nice one!
[09:50] <mdke> Riddell, is that a temporary or long-term solution?
[09:51] <mdke> i was discussing with diziet recently the possibility of shipping translated firefox html pages with ubuntu-docs, along with the english one 
[09:52] <Riddell> mdke: it's a solution until something better comes along
[09:52] <Riddell> mdke: any ideas on how to do that?
[09:52] <mdke> Riddell, the translations?
[09:53] <mdke> https://wiki.ubuntu.com/DapperFirefoxStartPageTranslation
[09:55] <janimo> Corsac, so you consider exo/terminal and xfmedia ready to upload by one of the DDs?
[09:57] <janimo> mvo, if a package b-depends unversioned on libdbus-glib-1-dev it just needs a rebuild? no other changes in the control file?
[09:57] <mvo> janimo: I added libdbus-glib-1-dev >= 0.60 as well to make sure the rebuild picks the right version
[09:58] <janimo> ok so if package had no version I'd better change that too?
[09:58] <janimo> so no build1 but ubuntu1 ?
[09:58] <mvo> yes, I think that is appropriate
[09:58] <janimo> ok
[10:18] <seb128> jbailey: ping?
[10:19] <mdke> Kamion, you didn't have a chance to have a look at the ubuntu-docs upload to breezy-updates did you?
[10:19] <Kamion> mdke: oh, no, sorry :(
[10:20] <mdke> Kamion, only an 8.5MB debdiff...
[10:22] <Kamion> I wasn't planning on reading every line anyway. :)
[10:24] <jbailey> seb128: pong
[10:24] <Kamion> I'm scanning it now
[10:24] <seb128> jbailey: you said to dholbach that totem should not force the current-version on totem-*?
[10:25] <jbailey> seb128: No, I asked him why it did. =)
[10:25] <seb128> I did that so apt-get install totem update the real package too
[10:25] <Kamion> mdke: does it require any changes to kubuntu/edubuntu?
[10:25] <jbailey> I was curious since i386's breakage keeps me from testing the upgraded version on ppc.  I was curious what the tight depends served.
[10:25] <jbailey> seb128: Maybe make it >= ?
[10:26] <seb128> would not make a difference
[10:26] <mdke> Kamion, it shouldn't, but it wouldn't hurt for me to double check with Riddell 
[10:26] <jbailey> Yes.  That would solve both our problems.
[10:26] <seb128> you mean >= current_upstream?
[10:26] <jbailey> No, the built package version.
[10:26] <seb128> how would that solve it?
[10:26] <Riddell> kubuntu-docs are separate from breezy and don't have any translations
[10:26] <seb128> you would get totem arch all first
[10:26] <seb128> requiring a totem-gstreamer you don't have yet
[10:26] <jbailey> It would force upgrades when it got upgraded, and also let totem-gstreamer be newer when i386 FTBFS'd but ppc didn't.
[10:26] <mdke> Riddell, would an update to ubuntu-docs (text and css changes to the firefox homepage) hurt?
[10:27] <Riddell> mdke: what's the change to the firefox homepage?
[10:27] <jbailey> seb128: It's not really a problem that's worthy of this much discussion.  It was just something that came up since totem-gstreamer hasn't been installable for me for a couple of days.
[10:27] <jbailey> seb128: No big deal, really. =)
[10:27] <Riddell> I believe that is broken is breezy, maybe we should change kubuntu-docs for that too
[10:27] <seb128> jbailey: totem-gstreamer is not installable?
[10:27] <jbailey> seb128: right, because totem is too old.
[10:27] <seb128> jbailey: should be the other way, totem is arch all, it's built first
[10:27] <mdke> Riddell, change to the body of the text, and the css, which is up a directory
[10:28] <seb128> jbailey: I don't get how that can happen
[10:28] <jbailey> seb128: Mm, no.  It's built by whatever arch the buildd admins feel like building it on.
[10:28] <jbailey> seb128: Right now, that's i386
[10:28] <jbailey> So when i386 FTBFSs, you don't get the updated arch: all package.
[10:28] <Kamion> mdke: it'd be nice in dapper to ensure that all the HTML files were autogenerated at build-time, rather than huge clearly-autogenerated files being in the source package ...
[10:28] <seb128> jbailey: right, that's the symetric of the common breakage
[10:29] <mdke> Kamion, we ship the xml too, but yeah, clearing stuff out of the source package has already been partly implemented in dapper
[10:29] <jbailey> seb128: Right.
[10:29] <seb128> jbailey: usually i386 build fine so you get the issue on other arches :)
[10:29] <ogra> Riddell, the switch to the alternatives system should avoid such breakage in the future
[10:29] <jbailey> seb128: So in this case, it built on ppc, not on i386.
[10:29] <Kamion> mdke: great
[10:29] <seb128> jbailey: that doesn't prevent you to install current totem-gstreamer
[10:29] <jbailey> seb128: Since I test ppc more than most people I looked to see why it wasn't installable.
[10:30] <jbailey> seb128: totem won't install beside it.
[10:30] <jbailey> seb128: And so it wants to uninstall totem, and uninstall ubuntu-desktop
[10:30] <seb128> right
[10:30] <mdke> Riddell, i don't see a reason it should cause a problem (that isn't already present), but if you think it's worth testing the package, it's at http://doc.ubuntu.com/debs/breezy-updates
[10:30] <ogra> oh, its about a breezy-update ...
[10:30] <mdke> yeah
[10:30] <ogra> hmm...
[10:31] <ogra> that will break edubuntu as well i think ... so i should push an update as well ? 
[10:31] <mdke> ogra, why will it break?
[10:31] <mdke> just the very fact of having an update?
[10:32] <Kamion> it doesn't *look* like it'll break
[10:32] <daniels> if it compiles, ship it
[10:32] <ogra> Kamion, i didnt use dpkg-divert 
[10:32] <mdke> the changes won't break anything, i'm pretty confident
[10:32] <Kamion> unless you're relying on the file name /usr/share/ubuntu-artwork/home/aboutubuntu.css
[10:32] <Kamion> (are you?)
[10:32] <ogra> nope
[10:32] <Kamion> since that moves to /usr/share/ubuntu-artwork/ubuntu.css
[10:32] <mdke> Kamion, that's replaced by /usr/share/ubuntu-artwork/ubuntu.css
[10:33] <Kamion> ogra: what aren't you diverting? :-)
[10:33] <mdke> it's called by -artwork/home/index.html
[10:33] <Kamion> as in, how do your package and ubuntu-docs interact?
[10:33] <ogra> Kamion, index.html
[10:33] <Kamion> but that's in /usr/share/edubuntu-artwork/
[10:34] <ogra> i moved the index.html to inde.html.orig (i know its wrong, dont rant) and linked the index.html to mine ...
[10:34] <mdke> that file will still be there after the update though
[10:34] <Kamion> you do? the package seems to use update-alternatives
[10:34] <ogra> you said you change the contents in index.html ...
[10:34] <Kamion> oh, that's in dapper
[10:35] <ogra> Kamion, nope, its doesnt
[10:35] <ogra> yup
[10:35] <mdke> ogra, yeah the contents, but the place doesn't change
[10:35] <Kamion> oh MY GOD
[10:35] <Kamion> ok, that will fuck up in ways I cannot immediately imagine
[10:35] <ogra> nozt if i also push an update ...
[10:35] <mdke> eh? :(
[10:35] <Kamion>       if [ ! -e /usr/share/ubuntu-artwork/home/index.html.orig ] ; then
[10:35] <Kamion>         mv /usr/share/ubuntu-artwork/home/index.html /usr/share/ubuntu-artwork/home/index.html.orig
[10:36] <ogra> mdke, you will overwrite my symlink with your file 
[10:36] <Kamion>       else
[10:36] <Kamion>         rm /usr/share/ubuntu-artwork/home/index.html
[10:36] <Kamion>       fi
[10:36] <Kamion>       ln -s /usr/share/edubuntu-artwork/home/index.html /usr/share/ubuntu-artwork/home/index.html
[10:36] <mdke> oh bloody hell
[10:36] <Kamion> does kubuntu have this brain-damage too?
[10:36] <ogra> nope
[10:36] <ogra> they use a broken dpkg-divert 
[10:36] <daniels> hold on
[10:36] <daniels> so you only ever copy it once
[10:36] <ogra> yup
[10:36] <daniels> so you keep a very old copy around
[10:37] <ogra> but the symlink will be overwritten on update
[10:37] <ogra> so people will suddenly see the ubuntu content
[10:37] <Kamion> ogra: your alternatives hack in dapper is broken too
[10:37] <Kamion> oh, hmm, need to check ubuntu-docs in dapper
[10:37] <ogra> Kamion, i didnt do that 
[10:37] <Mithrandir> Kamion: re loading fb modules in the casper startup, sure.
[10:37] <Kamion> but at the very least it looks like it needs a bit more smooth upgrade handling
[10:38] <mdke> so is there anything that can be done about this?
[10:38] <ogra> Kamion, and edubuntu-artwork is still pending locally for dapper i didnt do an upload yet
[10:38] <ogra> mdke, yes
[10:38] <ogra> mdke, i need to push an update afetr yours
[10:38] <mdke> use a different file for edubuntu?
[10:38] <Kamion> ogra: before, not after
[10:38] <Kamion> we need an edubuntu-artwork upload that removes this awfulness and does something less broken instead
[10:39] <Kamion> a divert would do fine
[10:39] <ogra> Kamion, but then i have to change the whole ...
[10:39] <xhaker> can elmo do universe packages synch from debian (of course)?
[10:39] <ogra> an update afterwards wont need any changes
[10:39] <Riddell> xhaker: yes
[10:39] <Kamion> ogra: we may want to make other ubuntu-docs uploads to breezy, and we cannot have them blocked on edubuntu-artwork changes in this way
[10:39] <Riddell> Kamion: I've just done that upload
[10:39] <ogra> xhaker, ask a motu for it in -motu
[10:39] <ogra> Kamion, ok
[10:39] <Riddell> in dapper
[10:39] <Kamion> Riddell: sorry, which upload?
[10:40] <xhaker> ogra, already tried that nobody seems to know who should do something
[10:40] <ogra> Kamion, *-artwork
[10:40] <Riddell> Kamion: make edubuntu-artwork use update-alternatives in dapper
[10:40] <Kamion> Riddell: yes, but we need a divert in breezy
[10:40] <xhaker> it looks like the packages are simply sinched from debian unstable
[10:40] <Kamion> Riddell: we're discussing a breezy-updates upload here
[10:40] <Riddell> right
[10:41] <Kamion> xhaker: if the package hasn't been modified in Ubuntu, then there's no need to talk to anyone; syncs will happen semi-automatically
[10:41] <ogra> Kamion, mdke is it enough if i do that tomorrow morning ? 
[10:41] <Kamion> (until upstream version freeze)
[10:41] <mdke> ogra, sure
[10:41] <ogra> oki
[10:41] <Kamion> ogra: fine by me
[10:41] <Kamion> other than that the ubuntu-docs upload is fine by me
[10:41] <mdke> thanks
[10:41] <fabbione> night fellas
[10:42] <mdke> ogra, lucky you were around :)
[10:42] <ogra> Riddell, you should probably fix the broken breezy -artwork alongside as well 
[10:42] <xhaker> Kamion, -1 in ubuntu -6 in unstable :( libswt3.1-gtk-java depends on mozilla-browser on dapper, on debian unstable it depends on mozilla-firefox | mozilla-browser
[10:42] <ogra> mdke, i read breezy-changes, i'd have noticed it :)
[10:42] <Riddell> ogra: that would mean changing kubuntu-docs and ubuntu-docs as well (which might not be a bad idea)
[10:42] <mdke> ogra, hasn't it been on breezy-changes already?
[10:42] <ogra> Riddell, they want to upload ubuntu-docs ...
[10:43] <mdke> ogra, yeah, it arrived on saturday :D
[10:43] <mdke> *friday
[10:43] <ogra> yes, friday 
[10:43] <ogra> oh, damned .. 
[10:44] <Kamion> xhaker: libswt3.1-gtk-java | 3.1.1-1ubuntu3 | dapper/universe | all
[10:44] <Kamion> xhaker: modified in Ubuntu, needs a manual merge, not a sync
[10:44] <Kamion> unless the result of the merge is to ask elmo to sync it and overwrite the Ubuntu changes
[10:45] <xhaker> gonna check the changes then
[10:45] <Kamion> ogra: I don't want major structural changes to ubuntu-docs in breezy-updates, just fixes to the current arrangement
[10:45] <ogra> Kamion, yup, i'll just remove the linking and moving and add a dpkg-divert
[10:45] <xhaker> Kamion, should'nt that package have a changed-by line?
[10:45] <ogra> xhaker, yes, in the changelog
[10:46] <infinity> ogra : If you use dpkg-divert, you'll need to conflict with kubuntu-docs
[10:46] <ogra> gah
[10:46] <infinity> ogra : Two packages can NOT divert the same file twice, or dpkg will scream at you.
[10:46] <ogra> thats bad 
[10:46] <mdke> is it?
[10:46] <mdke> people run kubuntu and edubuntu together?
[10:46] <ogra> since some edubuntu users ant to install kubuntu-desktop
[10:46] <mdke> argh
[10:46] <ogra> *want
[10:46] <ogra> sure
[10:46] <sistpoty> elmo: please sync openrpg and lxml from unstable, ubuntu override ok. thx
[10:47] <ogra> as users run ubuntu-desktop and kubuntu-desktop together
[10:47] <infinity> ogra : This is precisely why things needed to be changed to use alternatives.
[10:47] <xhaker> oh.. doko is the one
[10:47] <ogra> infinity, but that wont help us in breezy :/
[10:47] <Kamion> oh, argh
[10:48] <infinity> ogra : The only way in breezy to make it all right is to switch to alternatives there too.  And test it very heavily before uploading.  With all possible package combinations and upgrade scenarios.
[10:48] <Kamion> ok, I guess we have to go to alternatives then
[10:48] <mdke> oh bloody hell
[10:48] <infinity> ogra : If that's too scary, then leaving things broken is the best option.
[10:48] <ogra> sigh
[10:48] <mdke> can you use my source for ubuntu-docs if you need to amend that?
[10:48] <ogra> mdke, is that using alternatives in breezy ? 
[10:49] <ogra> i dont need -docs ... 
[10:49] <infinity> No.  Nothing in breezy used alternatives.
[10:49] <mdke> no
[10:49] <ogra> its only this one file i have in breezy
[10:49] <infinity> ubuntu-docs installed the canonical file, kubuntu-docs diverted it, edubuntu-docs did a horrible evil hack.
[10:49] <ogra> yup
[10:49] <jdong> Anyone have experience with audio programming?
[10:49] <mdke> ok let's think this through
[10:49] <mdke> is the amount of evilness needed to fix this worth the change to the aweful breezy css for the browser home page?
[10:50] <mdke> the text changes are definitely not uber-important
[10:50] <infinity> mdke : It's not so much the ubuntu-docs update that's a problem as the edubuntu-docs package being broken in general.
[10:50] <Kamion> mdke: it doesn't matter whether you change the file or not - any ubuntu-docs upload will break it
[10:50] <ogra> i dont care about the css ...
[10:50] <mdke> oh hang on... any update is gonna break it
[10:50] <ogra> yes
[10:50] <Kamion> and I think that's unacceptable and needs to be fixed for supportability
[10:50] <mdke> we definitely need _an_ update :)
[10:50] <Kamion> so I don't think we can leave it the way it is
[10:51] <Riddell> so lets update!
[10:51] <Riddell> I'm happy to do it all if people want, or we can split the work
[10:51] <mdke> as long as you use the new source for ubuntu-docs, I'm fine with whatever you guys want to do
[10:52] <Kamion> might want to put the source package somewhere public
[10:52] <ogra> switch to alternatives completely and be prepared for breezy->dapper in a clean way 
[10:52] <infinity> The only other option (apart from switching to alternatives, which is correct, but intrusive) is to upload an edubuntu-docs that removes the horrible symlink hack, and leaves edubuntu-docs crippled, without a start page.
[10:52] <mdke> Kamion, http://doc.ubuntu.com/debs/breezy-updates
[10:52] <Kamion> good, thanks
[10:52] <ogra> infinity, so it wouldnt need any update ...
[10:53] <Kamion> infinity: regressing Edubuntu kind of sucks if we can avoid it, though
[10:53] <infinity> ogra : Yes, it would, to get rid of the postinst-from-hell.
[10:53] <mdke> lol
[10:53] <infinity> Kamion : Agreed.  But testing "broken situation -> clean alternatives situation" is effort, that's all.  If people are up for it, yay.
[10:53] <ogra> infinity, removing edubuntu-docs would only revert the ubuntu index.html file 
[10:54] <infinity> ogra : Which would also be wrong.
[10:54] <ogra> infinity, sure ... 
[10:57] <Kamion> infinity: for a stable release update, I think we have to put in the time :-/
[10:57] <sistpoty> infinity: could you eventually help me with bootstrapping fpc (freepascal)? 
[10:58] <mdke> is there any other way I can help, or can I leave it with you til tomorrow evening?
[10:58] <infinity> sistpoty : Maybe, but the way my TODO looks for the next few days, it may not be until after Christmas.
[10:58] <sistpoty> infinity: ok, then I'll ping you again after christmas?
[10:59] <infinity> sistpoty : Sounds fair to me.  Write yourself a note. :)
[10:59] <sistpoty> infinity: will do... thx :)
[11:00] <ogra> mdke, Riddell and me will sort our docs until tomorrow for you, then ubuntu-docs should be fine ...
[11:00] <Riddell> who will do ubuntu-docs?
[11:00] <infinity> ogra / Riddell : Can you two ping me when you have source packages prepared, and I'll have a look at them?
[11:01] <ogra> infinity, yup
[11:01] <ogra> Riddell, oh, good question ..
[11:01] <infinity> Riddell : If you can do ubuntu-docs too, I'll look at what you have and mangle it further.
[11:01] <seth_k|lappy> seb128, hmm, I noticed you updated libgpod to .20 ubuntu3, will you have time to do .30 today or should I hold off on gtkpod?
[11:01] <Riddell> ok, I'll do it based on mdke's update
[11:01] <infinity> Riddell : I've got about 12 days of work to do, and 3 days to do it in, so I'm delegating like a mofo.
[11:01] <mdke> Riddell, rock thanks
[11:02] <mdke> Riddell, if I can help on anything, mail me?
[11:02] <seb128> seth_k|lappy: I uploaded this one before you pinged me, I said I will update today, a bit of patience please
[11:02] <seth_k|lappy> seb128, np, I just wasn't sure if there was a miscommunication. sorry to bother, just was planning my day
[11:02] <seb128> seth_k|lappy: I'm on it right now, I've just downloaded the tarball
[11:02] <infinity> ogra / Riddell : Just keep in mind that I don't have access to the -updates queues (well, I do as buildd admin, but I don't REALLY, so ignore that), so while I'm playing Kamion on vetting these packages, you'll need to ping and make stuff downloadable for me.
[11:03] <ogra> oki
[11:03] <ogra> thats what rookery is for :)

[11:03] <mdke> does someone need to bitch slap the current ubuntu-docs out of the updates queue?
[11:05] <mdke> Kamion, ^
[11:10] <Kamion> mdke: no, I think it can be left there until the rest is resolved
[11:11] <mdke> ok
[11:11] <mvo> janimo: thanks for uploading the xfce dbus packages
[11:12] <janimo> mvo, np :)
[11:12] <janimo> they are in universe
[11:12] <janimo> I thought you take care for main only no?
[11:14] <janimo> Kamion, does casper need to be removed form the live seed too?
[11:14] <janimo> since the file itself is gone
[11:15] <mvo> janimo: yes, usually
[11:15] <seb128> infinity: could you give a retry to firefox on i386?
[11:15] <Kamion> janimo: no?
[11:15] <Kamion> janimo: the casper package still exists
[11:16] <infinity> seb128 : If you ask nicely.
[11:16] <Kamion> and is essential for the live CD build process
[11:16] <Kamion> I nuked the casper *seed*, but that's different
[11:16] <seb128> infinity: pleeeeease? :)
[11:16] <janimo> Kamion, ok . I did not quite get from the seed bzr logs how much casper gies away
[11:17] <janimo> goes
[11:17] <Kamion> ah, need to update STRUCTURE though
[11:17] <infinity> seb128 : ;)
[11:17] <Kamion> janimo: entries in seeds don't include other seeds, which seems to be part of your confusion
[11:17] <janimo> probably
[11:17] <Kamion> janimo: the casper seed was the old d-i-based live CD infrastructure
[11:17] <janimo> and the live seed?
[11:18] <janimo> old as in hoary or breezy?
[11:18] <ogra> is it still there ? 
[11:18] <ogra> i thought i saw a doko upload for it
[11:19] <infinity> It's still there.  And completely unreproducible outside sbuild.  My favourite.
[11:19] <ogra> heh
[11:20] <xhaker> doko, you there?
[11:21] <infinity> janimo : "old" as in "up until last week"
[11:21] <janimo> :)
[11:22] <janimo> night all
[11:22] <infinity> janimo : The live seed is stuff that gets installed in the live filesystem (livefs is base+desktop+live+kernel)
[11:23] <infinity> mvo : Have you decided to play MOTU for the day, or are you just a liferea user, and thus annoyed by it not transitioning yet? :)
[11:24] <mvo> infinity: I wanted to see what it feels like to be a MOTU
[11:24] <mvo> also no fur or swords
[11:24] <seb128> mvo: keep your superpowers for the hug day tomorrow
[11:25] <mdke> use them for evil!
[11:26] <mvo> SUPER HUG POWERS
[11:27] <mdke> bah
[11:27] <mdke> you guys can't be corrupted
[11:28] <infinity> mvo : No giant cats in armour either?
[11:28] <Riddell> mdke: http://doc.ubuntu.com/debs/breezy-updates not working for me
[11:28] <mdke> Riddell, i'll take a look
[11:28] <ogra> yes, same here 
[11:29] <mdke> Riddell, our server is not powerful enough for all the hits it gets i think, it goes down a fair bit
[11:30] <mdke> Riddell, working now
[11:31] <mdke> albeit ridiculously slowly
[11:31] <StevenK> Since I have no idea where NEW is ...
[11:32] <daniels> it's on jackass
[11:33] <StevenK> But, being NEW, I suspect I have no access to it.
[11:33] <mvo> infinity: I'm sure I look gorgeous in a leather armour :P
[11:34] <Kamion> StevenK: yeah, it's in NEW
[11:35] <StevenK> I thought so. Neat how I don't get notified.
[11:35] <Kamion> are you not whitelisted?
[11:35] <jdub> morning StevenK 
[11:35] <StevenK> I am.
[11:35] <infinity> StevenK : Didn't get notified for new source, or new binaries?
[11:35] <Kamion> oh, new binaries you won't get notified
[11:35] <infinity> StevenK : You won't get notified for binaries, since it's the buildd that uploaded them, not you.
[11:35] <StevenK> Right.
[11:36] <StevenK> Yeah, but I've been waiting for them, since then I can just build xemacs and the world can stop ending.
[11:36] <StevenK> Or something.
[11:36] <infinity> Upload xemacs with versioned build-deps, and let it sort itself out.
[11:37] <Kamion> StevenK: could you use dpkg-{buildpackage,genchanges} -vLASTVERSIONINUBUNTU for merge uploads, please? that way I can see the whole intervening changelog
[11:38] <StevenK> Kamion: I didn't upload.
[11:38] <Kamion> ah, kick your sponsor then
[11:38] <StevenK> With pleasure.
[11:41] <Kamion> StevenK: processed
[11:41] <StevenK> Kamion: Ah, thanks.
[11:48] <Pygi> welcome sistpoty
[11:48] <sistpoty> hi Pygi
[11:49] <infinity> mvo : How do you feel about the state of our current draft of NetworkWideUpdates?
[11:49] <infinity> mvo : If someone were insane enough to spend some "spare time" starting to build small bits of it...
[11:50] <mvo> infinity: I have to admit that I haven't looked recently on it
[11:50] <infinity> mvo : I assume it hasn't changed since the hideous braindumping we did at UBZ.
[11:50] <infinity> mvo : Someone in #ubuntu-server is offering to attack the spec and try to make some of it reality.
[11:51] <mvo> woah!
[11:51] <infinity> mvo : Perhaps you should hop in and give him 5 minutes of your time.
[11:51] <mvo> infinity: I will have a look at it again tomorrow morning
[11:52] <mvo> infinity: I'm in, but it's late here, I would rather prefer tomorrow
[11:53] <infinity> mvo : Yeah, no problem.
[11:54] <mvo> infinity: bastard :P