[12:02] <stewart> although device manager shows a bt878
[12:02] <Keybuk> I don't know anything about tvtime I'm afraid
[12:02] <Keybuk> if device manager shows it, it's a bug in tvtime
[12:02] <Keybuk> (though when detected, your audio won't work because of the above bug :p)
[12:03] <Keybuk> it could be related to it
[12:03] <stewart> in breezy there was a multimedia test tool
[12:03] <Keybuk> I'd certainly do the blacklist/modules trick and see if it works after a reboot
[12:03] <stewart> you could check see if your capture card was there is there similar under dapper?
[12:04] <Keybuk> does the same test tool not exist?
[12:04] <HiddenWolf> Keybuk: taken from the menu's, I guess
[12:04] <stewart> yeah its not on themenus
[12:04] <Keybuk> what was the tool?
[12:05] <ogra> gstreamer-properties
[12:05] <stewart> system>adminsitration>multimedia I think
[12:05] <Keybuk> stewart: try just running what ogra suggested
[12:05] <HiddenWolf> that's it
[12:05] <HiddenWolf> Keybuk: thank you for your time
[12:06] <stewart> yeah cheers thats the same panel, didnt realise it was a gstreamer thing
[12:07] <HiddenWolf> ack, Keybuk, I pressed the wrong button on LP, now I assigned it to udev again. :(
[12:07] <Keybuk> put it back :p
[12:07] <HiddenWolf> Keybuk: how? :P
[12:07] <HiddenWolf> Can I just have bugzilla back?
[12:07] <Keybuk> fixed
[12:08] <HiddenWolf> mental note: stay away from unfamiliar buttons
[12:16] <stewart> Keybuk what do you make of xgl from a dev perspective?
[12:21] <Keybuk> stewart: personally I'm waiting for X to go away
[12:21] <Keybuk> it's an evil monolithic hunk of crap that belongs in the 70s
[12:22] <Keybuk> the most we need (imo) is a GL proxy server; that directs GL received from apps across the network, or to the appropriate video device
[12:23] <jdub> and X11 wouldn't be a good protocol to do that with, given its backwards compatibility and other benefits...?
[12:24] <Keybuk> as I understand X11, you end up with apps using GL to draw on a pixmap which is sent to a card that could receive GL just fine
[12:24] <Keybuk> I'm not necessarily against X11 being extended to support GL drawing commands directly
[12:25] <Keybuk> I'm definitely against the Xorg/X386 implementation
[12:25] <jdub> no, that is bollocks
[12:25] <jdub> that's precisely what GLX is for
[12:25] <Keybuk> for example, if I unplug an Nvidia graphics card and plug an ATI one in instead, I shouldn't have to stop all my running applications
[12:25] <Keybuk> ok
[12:25] <Keybuk> then I guess as a dev, I like the direction GLX is taking us :)
[12:25] <jdub> you're thinking of software rendering, which is an option everywhere
[12:26] <jdub> GLX is an extension to send GL commands over the X protocol
[12:26] <jdub> that's why you can run glxgears from OS X, over ssh, displaying on your linux box, and it still works well
[12:27] <jdub> hooray for architecture, operating system, and network independence
[12:27] <Keybuk> the thing I don't like about X is the way that it's a huge thing sitting on top that needs to be configured and stuff
[12:27] <jdub> X is not huge *at all*
[12:27] <Keybuk> my display should be independant to my hardware
[12:27] <jdub> it was invented for machines smaller than your calculator
[12:28] <jdub> the fact that it needs to be configured is a relic, rapidly being fixed now we have Xorg
[12:28] <Keybuk> Xorg doesn't seem to be moving in the right direction though
[12:28] <Keybuk> you can't unload one video driver, and load another, without the display needing to be killed
[12:28] <jdub> (keith has done some really interesting work on autoconfiguration and hotplug in kdrive)
[12:28] <jdub> well, that's a very niche case that could be attended to
[12:29] <Keybuk> likewise X doesn't automatically deal with me plugging a monitor into my laptop, and then unplugging it again
[12:29] <jdub> it will be able to do that very soon
[12:29] <Keybuk> plug a monitor in, I should get a new screen to put things on, unplug it, that screen should get tidied away
[12:30] <Keybuk> (just going to bounce, brb)
[12:31] <Keybuk> jdub: X is still the one thing about Linux that makes me ashamed though
[12:32] <HiddenWolf> Keybuk: try the sound stack
[12:32] <Keybuk> we're so far behind the way Windows and Mac OS X deal with displays :(
[12:32] <Keybuk> HiddenWolf: nothing especially wrong with ALSA and Gstreamer
[12:32] <jdub> Keybuk: not really, and in some ways, we're ahead. :-)
[12:32] <Keybuk> jdub: Windows has had on-the-fly driver, resolution, depth, etc. changing and direct-to-card rendering for nearly a decade
[12:32] <Keybuk> in fact, over a decade
[12:33] <jdub> Keybuk: there are some warts, but not enough that it's worth throwing away. indeed, few of these problems actually need extensions and all that kind of stuff.
[12:33] <Keybuk> jdub: I don't necessarily disagree; when I talk about "X" I guess I refer to the implementation we have today -- rather than the underlying protocol
[12:33] <jdub> Keybuk: X can do resolution, depth and direct rendering. we can't do on-the-fly driver changing yet.
[12:34] <Keybuk> jdub: it can only change between existing preconfigured resolutions
[12:34] <Keybuk> and as I recall, it _can't_ do depth changing
[12:34] <jdub> Keybuk: that's not true at all - look at XRANDR
[12:34] <Keybuk> XRandR only supports changing between the configured resolutions
[12:34] <jdub> nup :-)
[12:34] <jdub> i only have one resolution in my xorg.conf
[12:34] <Keybuk> oh ok
[12:34] <jdub> but i can change to all the resolutions my monitor supports
[12:34] <Keybuk> it can't change between depths though
[12:35] <Keybuk> you have to kill every running X app to do that
[12:35] <stewart> XRandR only supports changing between the configured resolutions <-- is that different to windows?
[12:35] <jdub> stewart: it's untrue to begin with, but no
[12:35] <stewart> if I want a custom resolition I still have to hack my drivers inf file on xp
[12:36] <jdub> Keybuk: ok - depth is not implemented because it wasn't deemed necessary, which i tend to agree with.
[12:37] <jdub> Keybuk: the only computer i have running anything less than 24/32bit is an old laptop of pia's.
[12:37] <Keybuk> jdub: what if you plug in an old monitor for some reason
[12:37] <jdub> Keybuk: which only does 16 bit at its full screen resolution.
[12:37] <stewart> still from an end user "could my ma use it" point of view x configs are still overly messy
[12:37] <Keybuk> or plug into one of those annoying projectors
[12:37] <jdub> Keybuk: old monitors and projectors do 32 bit. it's not a display issue, it's a memory / video chipset issue.
[12:37] <stewart> and my ma is/was a design engineer so theres plenty of refinement
[12:37] <Keybuk> Linux users at conferences are funny
[12:38] <Keybuk> the first day where everyone has to deal with the projector
[12:38] <jdub> stewart: xrandr works nicely now - xorg autoconfiguration is being worked on.
[12:38] <stewart> good good
[12:38] <jdub> Keybuk: that has more to do with bad video drivers than anything else.
[12:38] <Keybuk> jdub: yeah, that's certainly part of the problem
[12:38] <stewart> I think drivers must be a sticking point for the FLOSS world in general but never more so than video
[12:39] <jdub> you're blaming X about things for which it alone is not responsible ;)
[12:39] <Keybuk> how is X alone not responsible?
[12:39] <Keybuk> where X ~= everything X and X-related
[12:40] <jdub> ok
[12:40] <jdub> so
[12:40] <jdub> you're blaming X for being "big"
[12:40] <jdub> which it is not
[12:40] <Keybuk> xorg-* is a large set of packages
[12:40] <jdub> you're blaming it for features it doesn't have
[12:40] <jdub> which it does
[12:40] <jdub> you're blaming it for features it doesn't have
[12:41] <jdub> that are extremely shallow use cases
[12:41] <stewart> well without getting on too much of a downer improvements from a user point of view seem to have been accelerating
[12:41] <Keybuk> I don't think they are shallow use cases
[12:41] <jdub> and blaming it for problems that we would have with *any* system
[12:41] <jdub> such as drivers
[12:41] <Keybuk> sure :)
[12:41] <jdub> Keybuk: changing depth? in this day and age?
[12:41] <jdub> stewart: very rapidly with the Xorg split
[12:41] <jdub> stewart: (both from XFree86 and its build split)
[12:42] <Keybuk> jdub: I've frequently had to deal with projectors that can only do 16-bit
[12:42] <Keybuk> so I think it's still relevant
[12:42] <jdub> i'd still call that a shallow use case
[12:42] <jdub> those projectors are broken
[12:42] <jdub> and rare
[12:42] <Keybuk> sorry, but that's just something I don't agree with
[12:42] <Keybuk> it's our job to work with the hardware the user has
[12:42] <jdub> depth is not a display side issue to a massive degree
[12:42] <Keybuk> not tell the user it's their hardware's fault
[12:42] <stewart> but exactky jdub you both seem to be saying a more similar thing than you realise
[12:43] <jdub> sure, but there's massively deployed hardware and pitifully deplpyed hardware
[12:43] <jdub> i'm more interested in the problems posed by massively deployed hardware
[12:43] <Keybuk> we should work with both
[12:43] <stewart> what kb is saying is that people are frustrated with x becuase in honesty it didnt seem to move for like 5-10 years
[12:43] <HrdwrBoB> for example, xv crashes X on my X40
[12:43] <HrdwrBoB> quite often
[12:43] <HrdwrBoB> requiring a reboot
[12:43] <jdub> stewart: when Keybuk says "X is 70s technology that should be dumped", i am in absolute opposition to that idea :)
[12:43] <stewart> and what you're saying is hang on its moving rapidly now that everyones moaning at it
[12:43] <jdub> Keybuk: sure, but there are priorities. depth changing in XRANDR is possible, but not a priority.
[12:44] <Keybuk> Keybuk doesn't know *much* about X, it's both above and below the areas I tend to deal with
[12:44] <Keybuk> you probably know more than I do
[12:44] <mjg59> How on earth do projectors end up refusing to accept more than 16-bit?
[12:44] <mjg59> It's an analogue signal...
[12:44] <HrdwrBoB> designed by rent-an-ee in some cheap country?
[12:44] <Keybuk> so where I tend to throw a problem at "X", you know more about where that problem truly should be directed
[12:44] <jdub> mjg59: maybe a bandwidth issue? sounds completely nuts to me.
[12:45] <jdub> Keybuk: mmm - i've had to learn and keep up, given gnome stuff.
[12:45] <HrdwrBoB> jdub: it probably translates it back to digital, and the software is just crap
[12:45] <mjg59> Red Hat are dealing with many of the current problems with X
[12:45] <Keybuk> mjg59: my experience was a projector that only did 640x480 at default depth; but was happy to do 800x600 or 1024x768 at 16-bit
[12:45] <mjg59> The biggest one being run-time reconfiguration
[12:46] <stewart> well this isnt gettingmy TVTIME fixed ;-)
[12:46] <Keybuk> jdub: aye; currently I'm more interested in the underlying problems of getting kernel and userspace to play nice together -- and the higher problem of graphical users being able to see and change what's happening with their system
[12:46] <stewart> Im gonna hit the hay night guys and keep up the great work
[12:46] <Keybuk> X is somewhere in the middle of that, and not something I keep up to date with
[12:47] <mjg59> The biggest technology problem with X would be that changing depth on the fly is awkward
[12:47] <mjg59> But other than that...
[12:48] <infinity> AFAIUI, depth is becoming a non-issue as we're seeing the ability for windows to set their own depth.
[12:49] <infinity> (So, changing the server depth would just mean resetting the depth on all windows, including the root)
[12:49] <infinity> Which can probably be done today, but there's no cute tool to do it.
[12:50] <joelbryan> X can deal with those things, all it need is a smart script to do this and that.
[12:53] <joelbryan> I personally believe that x.org is way cooler than Windows, and has magical powers.
[12:53] <Keybuk> jdub: mmm, harder!
[12:53] <jdub> temple pressure is good :)
[12:57] <sivang> hehe
[12:59] <HiddenWolf> jdub: for dapper+1, will we see xgl or aiglx?
[12:59] <Keybuk> jdub: perhaps you could explain what the difference between those two is? :)
[01:01] <HiddenWolf> Keybuk: one is cocaine, the other is heroin.
[01:01] <Keybuk> that doesn't actually help me
[01:02] <jdub> HiddenWolf: they're both in dapper universe
[01:02] <hunger> Keybuk: It does not really matter which one is chosen anyway... the "cool thing" is compris:-)
[01:02] <HiddenWolf> hunger: Oh please
[01:02] <HiddenWolf> metacity++
[01:03] <_ion> hunger: Do you mean compiz?
[01:03] <hunger> Keybuk: Which is a GLX based composition manager enableing all kinds of graphic gimicks.
[01:03] <hunger> _ion: Aehm... yes, of course:-)
[01:03] <HiddenWolf> jdub: I know, but unless things move forward and some distro's actually ship it as default, not a whole lot will happen.
[01:03] <HiddenWolf> Keybuk: http://www.freesoftwaremagazine.com/free_issues/newsletters/accelerated_x/
[01:03] <hunger> By dapper+1 it should run on both xgl and the other one.
[01:04] <jdub> Keybuk: Xgl is an xserver that uses GL to render *everything*. AIGLX is a set of extensions that let you do indirect acceleration (into off-screen memory), which lets your compositing manager do all kinds of cool things faster.
[01:05] <jdub> Keybuk: we'll get AIGLX bits as a matter of course; Xgl will probably continue to be an option for people who's hardware can handle it.
[01:05] <jdub> s/who's/whose/
[01:05] <Keybuk> what does AIGLX give us that GLX doesn't?
[01:06] <jdub> interesting question
[01:06] <jdub> basically, it gives us a lot of love for a lower cost
[01:06] <jdub> Keybuk: GLX != Xgl
[01:06] <jdub> we're always using GLX here
[01:07] <jdub> Xgl is designed for a world where graphics cards are just 3d cards that happen to be drawing 2d objects
[01:08] <jdub> AIGLX is a bit more hospitable to reality as it is now
[01:08] <hunger> Keybuk: From what I understand aiglx adds an extension to do GLX-based compositing. But that is from a Xgl developer, so I do not completly trust that statement;-)
[01:09] <Keybuk> as I understand the world-to-be though, we're going to fast see graphics cards dropping 2d chips?
[01:09] <jdub> for instance, video overlays - with AIGLX, you use the existing XVideo overlay foo, but don't get tasty 3d manipulation of overlayed video. with Xgl, all of that video stuff is done through pixel shaders and crap like that on the GPU.
[01:09] <Amaranth> iirc the cards in the new macs don't have dedicated 2d
[01:09] <jdub> hunger: they're not nasty to each other. Xgl has switched to the same extensions.
[01:09] <jdub> Amaranth: no, that's more of a bios issue than what's going on on the chipset
[01:09] <hunger> Keybuk: Didn't that happen already? I remember reading that some cards no longer have 2D ops.
[01:10] <jdub> Keybuk: possibly. in the future.
[01:10] <Keybuk> BenC: I just had a rather nasty idea ... if only we could symlink hdaX -> sdaX reliably <g>
[01:10] <hunger> jdub: Yes, that is what he said, too.
[01:12] <ogra> Keybuk, unionfs ? or bind mount it ?
[01:13] <Keybuk> ogra: thinking about dapper+1, when IDE subsystem go bye-bye
[01:13] <Keybuk> and we'll have to deal with replacing /dev/hdXY in everyone's configs, fstab, etc. with /dev/sdZA
[01:14] <ogra> aiee
[01:15] <ogra> who decided such a crazy thing like removing potential root device nodes ?
[01:15] <Keybuk> it makes sense
[01:15] <ogra> thats evil
[01:15] <Keybuk> it unifies every single disk-like device into one subsystem
[01:15] <Amaranth> 2.6.16 doesn't have the IDE subsystem?
[01:15] <Keybuk> Amaranth: 2.6.17
[01:15] <Amaranth> ogra: the SCSI subsystem is much better than the others
[01:15] <Amaranth> that's why all new devices use it
[01:15] <ogra> may make sense, but i doubt *anybody* provides a good upgrade path from krenel.org ...
[01:16] <Keybuk> Amaranth: indeed; which is why SATA is implemented under SCSI, not IDE
[01:16] <Amaranth> usb, sata, etc
[01:16] <Keybuk> ogra: since when do kernel.org care about upgrade paths? :p
[01:16] <Keybuk> they leave that for us
[01:16] <infinity> ogra: We had no upgrade path when SATA stuff jumped from IDE to SCSI (via libata) either.
[01:16] <ogra> thats what i mean *sigh*
[01:16] <infinity> ogra: Such is life.
[01:16] <ogra> yeah
[01:16] <ogra> but still :)
[01:16] <Amaranth> it's better in the long run
[01:16] <Keybuk> infinity: fortunately at that point not many people were using SATA
[01:16] <Amaranth> hard upgrade, easier maintenance
[01:16] <infinity> Keybuk: I was. :)
[01:17] <infinity> Keybuk: And it freaked me right out.
[01:17] <infinity> Keybuk: (Though not for long)
[01:17] <Keybuk> the switch has an annoyingly upcoming problem
[01:17] <infinity> Keybuk: The largest headache was orchestrating kernel upgrades on some remote machines where I knew the device would swap.
[01:17] <Keybuk> most modern motherboards have SATA for the disks, and IDE for the CD drives
[01:17] <alp> mjg59: ping
[01:17] <Keybuk> I wonder what kind of random disk ordering we'll get from that
[01:17] <hunger> _ion: Does NM start the scripts in /etc/network/ip-*?
[01:18] <Keybuk> hunger: yes, via NetworkManagerDispatcher
[01:18] <hunger> Keybuk: Great! Thanks. I was getting worried that my mails won't be delivered once I switched to NM:-)
[01:19] <mjg59> alp: Hi
[01:19] <_ion> hunger: If you mean if-*, yes.
[01:19] <infinity> Or, for that matter, where ANY of the uploads have gone since the last LP rollout.
[01:19] <infinity> Fuck.
[01:19] <alp> mjg59: what's the right wiki/list to notify that i've got sdhci working with a TI on a sony t1xp using the modified fakephp patch and liberal setpci based on the docs?
[01:20] <mjg59> alp: Unsure. It's not really a patch we can support
[01:20] <mjg59> (Though if we're /really/ lucky, the native tifmxx driver will drive it soon and we can stop worrying)
[01:22] <alp> mjg59: sure. i might be able to generalise this into a catch-all bash script to bring a few smiles to some laptop owners' faces in the meantime. will take it to the sdhci list. also, on a different topic, there's a few bugs open about a trivial variable misnomer in a laptop-mode bash script that should get fixed and uploaded
[01:30] <Keybuk> ooh, visualisations are working again
[01:30] <hunger> Any idea why NM applet always pops up a window that it does not work when starting gnome while kNM in KDE works great?
[01:30] <Keybuk> hunger: which version?
[01:30] <hunger> Is that because of different permissions of the users?
[01:31] <hunger> Keybuk: NM is 0.6.1-0ubuntu1
[01:32] <hunger> The gnome user may not do sudo... maybe that's the problem?
[01:32] <_ion> Is the gnome user in plugdev group?
[01:33] <hunger> _ion: Nope.
[01:34] <hunger> _ion: He shouldn't meddle with things:-)
[01:34] <Keybuk> why does the user have to be in plugdev?
[01:34] <_ion> keybuk: Fixing that is in TODO.
[01:34] <hunger> But this should explain why the mount popups always die:-)
[01:35] <Keybuk> _ion: the 0.5 packages used libpamforeground, no?
[01:35] <alp> mjg59: s/THIS_GOVERNOR/THIS_CPU_GOVERNOR/ in /usr/sbin/laptop_mode fixes cpu scaling. can't figure out how to use malone or i'd report it
[01:36] <Keybuk> mjg59: weird bug ... something saved my session when the battery ran out
[01:36] <Keybuk> would that be a g-p-m bug?
[01:37] <infinity> I think something's just randomly saving sessions the whole time you're logged in.
[01:37] <infinity> Cause if I violently hit the power, I'll come back with where I left off (ish), not with my last saved session (which is what I'd expect)
[01:38] <Keybuk> infinity: I get worse; I never save my session, I leave it blank
[01:38] <Keybuk> now, after loosing power, I have a dozen loaded apps which I need to kill
[01:38] <infinity> Fun.
[01:38] <Keybuk> and no way to fix that, fwict
[01:39] <infinity> Session handling's gone very goofy in dapper.
[01:39] <infinity> I just wish the little tickbox would come back in my logout screen, but it was deemed too unintuitive, or something.
[01:39] <_ion> keybuk: I grepped for pam and foreground in the 0.5.1 directory and didn't find anything. But yeah, seems like that could be fixed with libpam-foreground.
[01:40] <Keybuk> _ion: is in the dbus policy, at-console="true" or whatever
[01:41] <_ion> keybuk: The policy contains the at_console="true" stuff, but it doesn't seem to be enough at least on my computer.
[01:42] <mjg59> Nngh why is laptop-mode playing with CPU frequency stuff?
[01:43] <mjg59> "Oh, upgrade laptop-mode, that's why things are crashing. It'll be MUCH BETTER"
[01:43] <mjg59> Except it also does insane amounts of other stuff that we already deal with
[01:43] <tseng> the laptop-mode wrapper a script is a "scratch my own itch, the rest of you be damned" deal
[01:46] <alp> it is sick, but it seems to have got installed, so it might as well work
[01:50] <Kinnison> Never fear, I am here, (Not that I know what I'm doing, vodka on pasta can do that to a guy)
[01:50] <ogra> :)
[01:51] <Surak> :-)
[01:51] <Kinnison> Okay, running commentary on ##soyuz1.0 if anyone cares
[01:52] <jdub> o/~ we built this kitty on rock and roll! o/~
[01:52] <Amaranth> Kinnison: I need to stop joining random channels.
[01:52] <Kinnison> heh
[01:53] <Amaranth> Keybuk: is this "move to SCSI subsystem" roadmap posted anywhere?
[01:53] <bddebian> Vodka on pasta?
[01:53] <Keybuk> hahahahaha  "road map"
[01:54] <Keybuk> Amaranth: the current patch set is:
[01:54] <Keybuk> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/1402.html
[01:54] <Amaranth> Keybuk: Is there at least a drunken rant on lkml about why it should be done?
[01:54] <Keybuk> Amaranth: it's reasonably obvious why it should be done; because it's the right thing to do
[01:54] <mjg59> Amaranth: Have you /read/ the code in drivers/ide
[01:55] <mjg59> ?
[01:55] <mjg59> If so, that should give you a good idea :)
[01:55] <Amaranth> mjg59: I try to stay away from the kernel.
[01:55] <mjg59> The legacy IDE code is horrible, full of locking races and makes hotplug almost impossible
[01:55] <Amaranth> mjg59: I almost got into it once, whiskey was needed. :P
[01:56] <mjg59> libata is readable
[01:56] <infinity> mjg59: So, are people madly porting ancient IDE drivers to libata, or will there still be some mix-n-match hell for crazies with 486 machines?
[01:56] <Keybuk> PATA support in libata is one of those things where just about everyone goes "yup, please!"
[01:56] <mjg59> infinity: Alan Cox is doing it. So, yes.
[01:56] <infinity> Sex.
[01:56] <infinity> Go Cox.
[01:56] <mjg59> In fact he's written support for some hardware that was never previously supported...
[01:56] <infinity> That's very Alan.
[01:57] <mjg59> Amaranth: As a reference, piix.c (from drivers/ide) is 20K. ata_piix is 17K, and does SATA as well as legacy IDE
[01:58] <Amaranth> damn
[01:58] <mjg59> And is /much/ more readable
[01:58] <Keybuk> not to mention any comments about the IDE subsystem maintainer being almost as hard to work with as the IDE subsystem code ;)
[01:59] <mjg59> Whoever the IDE subsystem maintainer happens to be at that point in time
[01:59] <jdub> yay _A_
[01:59] <Keybuk> he rejected our patch to take away the race condition between the "ADD /dev/hda" and "/proc/ide/hda" actually existing
[02:00] <Amaranth> mjg59: so crappy code attracts assholes?
[02:00] <Keybuk> likewise the patch to put the /proc information into /sys where it belonged
[02:00] <mjg59> Amaranth: Or, rather, sane people stay away
[02:01] <mjg59> Anyway. The world will All be Good once this is sorted
[02:01] <Keybuk> well, not All good
[02:02] <Keybuk> if only we could mv drivers/scsi drivers/disk or something
[02:02] <mjg59> Keybuk: That's the long-term goal
[02:02] <mjg59> Or, rather, the long term goal is to move it away from scsi again
[02:02] <mjg59> There's no need for it to all go through the scsi layer
[02:02] <Keybuk> ah, so drivers/scsi would just be scsi controller drivers using a common disk subsystem?
[02:02] <mjg59> Yeah
[02:03] <Keybuk> instead of using the scsi core as the common disk subsystme
[02:03] <mjg59> Yes
[02:03] <Keybuk> we decided that we'd hum loudly and pretend "sda1" stands for "storage device 'a' partion '1'" :)
[02:03] <mjg59> Heh
[02:03] <mjg59> The migration is going to be "fun"
[02:04] <Keybuk> o/~ It's givin' me good migrations
[02:04] <Keybuk> o/~ Ooh! Ooh! Ooh! Good migrations
[02:05] <jdub> Keybuk: ha ha
[02:05] <ogra> lol
[02:05] <Amaranth> oh no, my hda is going away
[02:06] <Amaranth> i guess that converts to OF calls or whatever on install so it would still work, right?
[02:06] <mjg59> Well, with luck
[02:07] <Amaranth> heh
[02:07] <Amaranth> i think i'll stick with 2.6.15 for a while
[02:07] <Amaranth> err, crap
[02:07] <Amaranth> all the migration stuff will force usage of 2.6.17
[02:08] <predius_> nvidia doesn't work on .16 :(
[02:08] <Amaranth> predius_: small change needed to fix it
[02:08] <predius_> Amaranth: link?
[02:09] <Amaranth> *shrug*
[02:09] <Amaranth> google
[02:09] <Surak> huh
[02:10] <Keybuk> Amaranth: if you're running dapper, I'd recommend sticking with 2.6.15 anyway
[02:10] <Keybuk> they are /sys changes in 16 onwards that could break udev
[02:10] <Amaranth> Keybuk: i meant when i switch to dapper+1
[02:10] <Amaranth> like, 4 days after it opens :P
[02:10] <Keybuk> if you're gonna run dapper+1, you gotta enjoy the ride <g>
[02:10] <ogra> yeah
[02:10] <Keybuk> release cycles are like rollercoasters
[02:10] <infinity> It'll be a good ride.
[02:10] <ogra> we'll break the world :)
[02:10] <Keybuk> sometimes there's dips, and sometimes there's climbs
[02:11] <Keybuk> and sometimes you fall off, cheat death, and then get hunted down with bizarre things happening to you
[02:11] <Amaranth> i missed most of dapper
[02:11] <Amaranth> i got the "omg we're gonna die" parts
[02:11] <Keybuk> infinity: albeit a very quick one
[02:12] <Keybuk> we'll have just enough time to break everything, and no time to fix it
[02:12] <infinity> That seems ideal.
[02:12] <predius_> i'm sure dapper+1 will be broken for the first couple of months
[02:12] <infinity> Mark wanted it to be another warty, I think we can pull that off. :)
[02:12] <ogra> you mean the first *pair* ?
[02:13] <Amaranth> hmm
[02:13] <Amaranth> i actuallly didn't ever use warty
[02:14] <predius_> ogra: hm?
[02:14] <infinity> warty worked, but was aptly named.
[02:14] <Amaranth> i jumped right on to hoary when it opened
[02:14] <Keybuk> infinity: "erratic" ?
[02:14] <ogra> predius_, dapper+1 has only a ~4 month release cycle ...
[02:14] <Keybuk> "enfeebled"?
[02:14] <Amaranth> 4 1/2
[02:14] <predius_> ogra: yeah.
[02:14] <Amaranth> at least that 1/2 is taking a break
[02:14] <predius_> well, at least we have until dapper+2 to get #1 closed
[02:15] <Keybuk> I think we should skip to 'f'
[02:15] <Keybuk> "frightening"
[02:15] <Keybuk> "fragmented
[02:15] <Keybuk> "flickering"
[02:15] <Keybuk> "failed"
[02:15] <ogra> hah
[02:15] <mjg59> jdub: Seen http://www.mepis.org/node/9454 ?
[02:15] <Keybuk> "fractured"
[02:15] <lamont> ENOPITTI
[02:15] <Amaranth> what's wrong with edgy? it seems to fit
[02:15] <Keybuk> theres a lot of good words in "f"
[02:15] <lamont> gnome-volume-manager
[02:15] <lamont> -mix.mmjgroup.com 312:
[02:15] <lamont> :-(
[02:15] <_ion> "f****d"
[02:15] <ogra> mjg59, cool !
[02:16] <Amaranth> _ion: what animal could go with that?
[02:16] <predius_> dingo?
[02:16] <predius_> dodo.
[02:17] <Amaranth> needs to start with f, we like alliteration (sp?)
[02:17] <ogra> furrylittlethingie ?
[02:17] <predius_> heh, I know.
[02:17] <predius_> fairy?
[02:17] <mjg59> ferret
[02:18] <predius_> dat
[02:18] <_ion> fish, flamingo(?)
[02:18] <ogra> frightening ferret ?
[02:18] <jdub> mjg59: seen teh fridge? :)
[02:18] <predius_> furious flamingo
[02:18] <mjg59> jdub: Pf. Don't be silly
[02:18] <predius_> as good as it gets
[02:18] <Surak> furious flamingo... hum
[02:19] <predius_> i'd hate to see the boxart on that
[02:19] <jdub> oh man
[02:19] <jdub> ControlMaster in ssh config
[02:19] <mjg59> jdub: Anyway, where's the RSS feed from fridge?
[02:19] <jdub> AWESOME INSIDE
[02:19] <jdub> mjg59: atom/feed or node/feed
[02:19] <_ion> http://fridge.ubuntu.com/atom/feed
[02:19] <predius_> mjg59: ttp://fridge.ubuntu.com/node/feed
[02:20] <_ion> RSS is teh suxor, Atom ftw.
[02:21] <mjg59> jdub: Pff. Why is there no buzzword compliant button on the front page?
[02:22] <jdub> mjg59: i will make it compliant immediately, with the new orange buzz compliant icon
[02:22] <mjg59> Excellent
[02:22] <_ion> Be sure to put a lot of enterprise into it.
[02:22] <mjg59> COMMUNITY FEEDBACK AT ITS FINEST
[02:22] <jdub> i will
[02:22] <mjg59> Haha
[02:22] <jdub> The Fridge is totally ready for Star Trek
[02:22] <mjg59> The Daily WTF has been excellent this week in that respect
[02:22] <Keybuk> WARP FACTOR FIVE MR WAUGH!
[02:22] <_ion> mjg: Yeah. :-)
[02:25] <Surak> engage
[02:26] <sivang> night all!
[02:27] <Surak> night sivang.
[02:27] <sivang> (3:26am here, so nobody would think I'm a slacker ;-)
[02:27] <sivang> nite
[02:28] <nictuku> should a dist-upgrade using aptitude work fine? is it recommended? in debian it's the prefered method
[02:28] <_ion> Wow, the same timezone.
[02:28] <_ion> sivang: Where do you live?
[02:29] <CarlFK> dapper-server doesn't react to the power button, same box, dapper live cd from a few days ago does.  what package do I bug?
[02:29] <_ion> Probably something ACPI-related.
[02:30] <Kinnison> _ion: sivang lives in israel I believe
[02:30] <CarlFK> dern... keep forgetting about #u-bugs
[02:33] <Amaranth> bah, the network manager 0.6 stuff is x86 only
[02:33] <infinity> That's easily solved.
[02:33] <Amaranth> yep, building now
[02:43] <Amaranth> well, it works just as good as the one in dapper
[02:44] <Amaranth> i blame the bcm43xx driver for wireless networks not working
[02:44] <Amaranth> [76583.711537]  SoftMAC: Authentication response received from 00:16:b6:1b:dc:e3 but no queue item exists. <--that's a new one
[02:45] <mjg59> Amaranth: Yeah, bcm43xx seems to fail to switch back to your network after doing a scan
[02:45] <mjg59> Amaranth: There's a patch on the mailing list to fix that
[02:46] <Amaranth> i've never been able to connect with it (longer than 2 minutes, once, with a static ip)
[02:47] <mjg59> You need to limit your rate to 11M for it to work even vaguely reliably
[02:47] <mjg59> But then it's fairly good
[02:48] <LaserJock> mjg59: how's the macintel work going? I looked like from the changelog you have got it running
[02:48] <mjg59> LaserJock: Yeah, just need a couple of installer fixes
[02:49] <LaserJock> mjg59: will it make it in Dapper? I'm talking to some fink guys and they wondered
[02:50] <mjg59> LaserJock: Should do
[02:50] <mjg59> By the end of the week, with luck
[02:50] <LaserJock> great news. This iMac is kicking my tail
[02:50] <LaserJock> Nothing *nixy is working well at all
[02:50] <Keybuk> oh, that's quite cute
[02:50] <LaserJock> python and gcc seem to be a mess
[02:50] <Keybuk> this package compiles on i386 but not amd64
[02:51] <jdub> mjg59: delivered/
[02:51] <mjg59> jdub: Mm?
[02:51] <Amaranth> LaserJock: i spent a week getting qt4 compiled on os x
[02:51] <jdub> mjg59: feeds in the html
[02:51] <jdub> mjg59: for wetware
[02:51] <mjg59> jdub: Hurrah!
[02:51] <jdub> (rather than html for software, which was already there)
[02:51] <Amaranth> then another week teaching sip and pyqt4 about os x
[02:52] <jdub> mjg59: i even got a skanky food reference in
[02:53] <mjg59> jdub: Indeed
[02:53] <mjg59> I'm very impressed
[02:55] <neuralis> mjg59: in case you don't hear it enough, your work is awesome and very much appreciated.
[02:55] <mjg59> neuralis: Thank you :)
[02:56] <infinity> I also would like to sup on mjg59's wang.
[02:57] <infinity> Or anything for that matter.
[02:57] <Burgundavia> Seveas: we need your quote bot ^
[02:59] <mjg59> infinity: You may have to negotiate with Fiona first
[02:59] <jdub> mjg59: "MEPIS is no longer involved with the DCC due to 'creative differences.' We wish Progeny, Xandros, and Linspire the best of luck in their mutual endeavors," said Woodford.
[02:59] <ajmitch> hah
[02:59] <mjg59> Go DCC
[02:59] <jdub> 'creative differences' such as... 'creating anything'
[03:00] <jdub> or perhaps 'creating trademark confusion'
[03:00] <Burgundavia> hmm, dcc needs to update their website. Mepis is still there
[03:00] <mjg59> jdub: Where's that from?
[03:01] <crimsun> isn't the 6.0 beta release based on dapper?
[03:01] <Amaranth> jdub: hey, no images in the feeds?
[03:02] <mjg59> crimsun: Yup
[03:02] <crimsun> rock
[03:03] <mjg59> jdub: Ah, never mind, found it
[03:04] <jdub> Amaranth: so i'm wondering about that too
[03:05] <jdub> Amaranth: appears to be an atom thing (they're in the rss feed)
[03:05] <jdub> not atom's fault
[03:05] <Amaranth> "let's unify all the syndication methods by...get this...making a new one!"
[03:13] <Keybuk> it fills me with infinite joy that this library designed to provide an easier kernel interface has *never* been tested on a 64-bit machine
[03:13] <Kinnison> well that'd be too goddamn easy
[03:13] <Keybuk> in fact, it looks like it's never been tested on anything other than i386
[03:14] <Kinnison> common
[03:18] <Keybuk> nl-tctree-dump.c:31: warning: cast from pointer to integer of different size
[03:18] <Keybuk> WWAAAAHHH!!!!
[03:18] <Keybuk> MUMMY!!!!!!
[03:18] <bddebian> heh
[03:18] <Keybuk> and this is supposed to work, is it?
[03:19] <Amaranth> Keybuk: magic fairy dust
[03:19] <Keybuk> Amaranth: no, this is magic SEGV dust
[03:20] <Amaranth> those are always fun
[03:20] <Keybuk> "dear authors; you cannot stuff an int into a pointer on every architecture"
[03:20] <bddebian> hehe
[03:20] <Amaranth> that's actually the reason i don't use C: everything i touch segfaults
[03:21] <Amaranth> gcc is like "you added a comment? i'll add a segfault!"
[03:21] <sladen> jdub: where's the DCC quote?
[03:21] <bddebian> Amaranth: :-)
[03:21] <jdub> sladen: top ITP story on teh fridge
[03:21] <Fjodor> Would someone be interested in trying out some supposedly performance-on-amd64-improving patches for glibc, that I notified Jeff Bailey about, or should I wait for him to include it and call for testers?
[03:22] <robertj> hrmm, wesnoth isn't playable in multiplayer at version 1.1, it's too old for the dev server and too new for the stable server
[03:22] <sladen> jdub: yeah, I couldn't see the actual quote in it (or in the linked linuxtoday article)
[03:23] <xhaker> just asking, gaim2.0 = dapper+1 right?
[03:24] <xhaker> i'm asking this since watching cvs commits they seem to be almost there
[03:25] <jdub> sladen: that is not the top one
[03:25] <xhaker> another thing, has anyone thought of making a gaim smiley theme for Ubuntu as part of the UI revamp?
[03:29] <Robot101> xhaker: it was discussed with them (upstream) and me (Debian maintainer) and we decided it wasn't a safe bet to be ready on the dapper timeframe
[03:29] <Robot101> xhaker: I wouldn't go for 2.0.0 either, it will be followed up after a week or two with a load of "oh shit" bugfixes
[03:29] <xhaker> lol
[03:30] <xhaker> Robot101: thanks for the heads up then
[03:30] <Robot101> what concerns me more is the 70 or so issues found by the coverity checker
[03:30] <Robot101> which they've fixed most of in cvs
[03:30] <xhaker> in 1.5?
[03:30] <Robot101> but nobody has looked to see a) which are security problems or b) remotely exploitable or c) applicable to 1.5.x
[03:31] <xhaker> Robot101: handpicking cvs blocks is not doable too
[03:31] <Robot101> I don't have time to do any of those, but based on Gaim's track record it's not only likely, but inevitable
[03:31] <xhaker> argh, stuff for backports hopefully
[03:31] <Robot101> yeah but even in Debian there's no real way to sign off on a Gaim release and call it fit for stable
[03:32] <Robot101> maybe even its stuff for volatile
[03:33] <xhaker> Robot101: what do you mean, they change too much?
[03:34] <Robot101> yeah, it's too much work to track the changes between a fixed release of gaim and HEAD and know what is or isn't worthy for backporting
[03:34] <Robot101> I suppose it's nowhere near as bad as mozilla, but it still worries me
[03:34] <Robot101> people try crashing IM clients far more than they do web browsers
[03:49] <Fjodor> No testers for my amd64 patch? Anyone want to advise as to what I should try to run on a patched vs. an unpatched system then?
[04:00] <childe> Hi, where can I get a debug kernel?
[04:00] <childe> To use with addr2line.
[04:03] <xhaker> childe: i think if you want it in ubuntu the way is to compile it yourself
[04:04] <xhaker> with the debug options turned on
[04:05] <childe> xhaker: Hmmm...why don't Ubuntu provide such a package, like in RedHat. Compiling a kernel on my own system costs a lot of time. It will be better to provide a package.
[04:06] <xhaker> it would indeed, i don't think it's a lot of time though, depends on the hardware/connection
[04:07] <xhaker> childe: do you think a -debug kernel is necessary? really really? if you file a bug in launchpad.net the kernel team might hear you
[04:08] <childe> xhaker: I reported that bug to X team because it's that i810 X driver causes kernel panic.
[04:08] <childe> xhaker: Should I report it to the kernel team?
[04:09] <xhaker> childe: just file a wishlist bug asking for a fully ready -debug kernel
[04:09] <childe> xhaker: If the kernel team put their debug kernels online, other people who have time can help them.
[04:10] <childe> ok
[04:10] <xhaker> childe: i don't know if they are debug kernels
[04:10] <xhaker> but they might, i mean.. the daily kernels BenC hosts
[04:11] <childe> xhaker: Could you please tell me the URL of the daily kernels?
[04:11] <xhaker> http://people.ubuntu.com/~bcollins/
[04:12] <xhaker> it seems that he stopped doing them.. atleast the last one dates from january :S
[04:12] <xhaker> childe: those are old kernels :/
[04:13] <childe> xhaker: It's OK because this bug is reproducible even on Breezy.
[04:13] <childe> xhaker: But it seems these kernels are not debug kernels :-(
[04:13] <childe> xhaker: The bug is #34697 on launchpad
[04:14] <xhaker> crap.. double clicked it
[04:14] <xhaker> lol
[04:16] <childe> xhaker: This bug is really anonying. Now I can only use xfs_freeze then Sysrq+O to shutdown the machine :(
[04:16] <xhaker> i read it
[04:17] <xhaker> too bad :/
[04:18] <xhaker> have you tried the i386 kernel?
[04:18] <childe> And the X team seems too busy and have no time to deal with this non-critical bug...so I want to try to debug it by myself.
[04:18] <childe> xhaker: AFAIK, it's a x86_64 only bug.
[04:19] <xhaker> figured
[05:04] <jdub> BenC: ping
[05:04] <jdub> BenC: ping (payload: smaps)
[05:06] <_ion> jdub: Pong.
[05:07] <_ion> There seems to be a routing error.
[05:07] <childe> _ion: Do you know where I can download a debug kernel?
[05:08] <_ion> childe: Uh, no.
[05:10] <childe> OK...maybe I need to compile it on my own machine :-(
[05:12] <_ion> I have had to compile my own kernel, so that i can use /dev/fb* with Matrox G400 properly.
[05:13] <childe> _ion: What machine do you use and how long it took?
[05:13] <_ion> childe: PIII 500MHz, 384MiB memory; i don't remember.
[05:13] <_ion> Not too long.
[05:14] <childe> _ion: I think you configured the kernel to meet your specific hardware devices
[05:14] <_ion> Yes.
[05:14] <childe> _ion: But I need the debug version of the official full kernel
[05:14] <childe> :-(
[05:41] <jdub> Amaranth: that feed images thing is fixed
[05:58] <jdub> anyone have ideas for a new poll on the fridge?
[06:00] <nictuku> ahmm music player of choice?
[06:00] <nictuku> how can I ask for an update of https://launchpad.net/distros/ubuntu/+spec/network-wide-updates /
[06:00] <nictuku> *?
[06:01] <nictuku> I suppose I should not change it myself
[06:03] <robitaille> jdub:  for a pool:   kubuntu?  ubuntu?  xubuntu?  etc.  I'm curious of the ratio ubuntu vs kubuntu these days
[06:03] <robitaille> s/pool/poll
[06:09] <jdub> robitaille: feel kinda uncomfortable with obviously competitive stuff on there
[06:13] <_ion> jdub: Emacs vs. KDE
[06:13] <_ion> "Which one is better?"
[06:14] <infinity> "Who's a better source of information?" [ ]  The Fridge  [ ]  Your mom
[06:15] <nictuku> what do you use at home? a) Ubuntu b) Windows 3.11
[06:15] <robitaille> how about a poll about potential names for Dapper+1
[06:15] <nictuku> isn't that decided already?
[06:18] <_ion> nictuku: In that case the poll could have just one radio button and the submit button. :-)
[06:18] <_ion> A poll about potential names for Dapper.
[06:18] <_ion> [ ]  Dapper
[06:19] <_ion> [ submit ]
[06:19] <nictuku> and the second radio button is inselectable
[06:19] <nictuku> *un
[06:25] <jdub> robitaille: hrm, wish i could do a write-in poll, then we could ask for suggestions for animal names that start with E
[06:26] <Burgundavia> jdub: marks hair styles for a laugh?
[06:26] <jdub> can't do images as poll items :(
[06:26] <jdub> as soon as we can though, i'm up for it
[06:27] <G0SUB> jdub: wiki?
[06:27] <jdub> G0SUB: ?
[06:27] <G0SUB> jdub: can't we use a wiki for the poll?
[06:28] <jdub> i'm looking for a new poll for the fridge
[06:28] <G0SUB> i see
[06:28] <G0SUB> how about ``Edgy Elk'' ?
[06:29] <G0SUB> Elk is a large Deer btw
[06:30] <robitaille> brown or blue for your theme?  (or maybe we have done that one already....)
[06:30] <HrdwrBoB> enraged elephant
[06:30] <G0SUB> HrdwrBoB: edgy is fixed
[06:31] <HrdwrBoB> ah
[06:31] <G0SUB> Edgy Elk sounds good IMO
[06:33] <mroth> Edgy Emu
[06:34] <robitaille> jdub: what was your prefered OS before Ubuntu?
[06:34] <HrdwrBoB> no-name-yet
[06:34] <HrdwrBoB> :)
[06:34] <Burgundavia> robitaille: is that a question or a poll?
[06:34] <Burgundavia> I would like to know the answer though
[06:35] <G0SUB> Debian?
[06:36] <robitaille> Burgundavia:  poll...we would need to add the usual suspects for choices
[06:37] <Burgundavia> I like it
[06:37] <robitaille> tells us how many people are switcher (from windows, etc) vs switcher from other linux, etc etc
[06:37] <_ion> eagle, earthworm, eel, elephant, elk, emu, ewe
[06:38] <robitaille> in my case, I came from FC1
[06:38] <Burgundavia> rh8 for me
[06:38] <Burgundavia> windows for my brother
[06:38] <G0SUB> I came from Debian
[06:38] <G0SUB> [for the desktop]
[06:38] <_ion> I switched from AmigaOS to Debian when i got a PC.
[06:39] <Burgundavia> interestingly, I was diggging through popcon on debian
[06:39] <_ion> Now i use Ubuntu for the desktop.
[06:39] <Burgundavia> it appears that gnome and kde are about neck and neck for installations, with gnome slightly ahead
[06:41] <robitaille> That's why I wanted a Ubuntu vs Kubuntu poll :)
[06:42] <joelbryan> do you think ekiga should be run on startup in dapper?
[06:42] <hendry> isn't there something like popularity contest for ubuntu?
[06:42] <robitaille> we had a visitor at work today, with a Kubuntu laptop.  Being the resident ubuntu fanboy, people pointed that to me very quickly
[06:43] <hendry> joelbryan: ekiga shouldn't be in startup
[06:43] <joelbryan> hendry: why?
[06:43] <hendry> joelbryan: takes up valuable resources
[06:43] <joelbryan> ok
[06:43] <HrdwrBoB> should my X40 stall while 'loading hardware drivers' until I break it ?
[06:43] <hendry> i don't think ekiga works through a firewall, does it?
[06:43] <Burgundavia> hendry: you mean default install?
[06:44] <Burgundavia> yes, it works through most firewalls
[06:44] <hendry> Burgundavia: pardon?
[06:44] <joelbryan> hendry: yes, through STUN
[06:44] <hendry> why does it have this odd NAT dectection phase?
[06:44] <Burgundavia> ekiga should be in the default install because we want to encourage free codecs for speech
[06:44] <joelbryan> I have a strict NAT setup
[06:44] <joelbryan> and it works
[06:45] <joelbryan> yes
[06:45] <hendry> in order for ekiga to work. do you have to sign up to ekiga service??
[06:45] <Burgundavia> no
[06:45] <joelbryan> yes
[06:45] <_ion> hendry: You can use any SIP provider/server.
[06:45] <Burgundavia> all you need is to call any other sip account
[06:45] <joelbryan> ah, ok, you use your IP
[06:45] <joelbryan> h323
[06:45] <Burgundavia> sip is an open protocol, unlike skype
[06:46] <Burgundavia> h323 is an older standard for video conferencing
[06:46] <Burgundavia> h323 != sip
[06:46] <_ion> h323 < sip :-)
[06:46] <joelbryan> yup
[06:46] <hendry> what do win32 users have to install to talk to you?
[06:46] <joelbryan> but you can call an ip using h323
[06:47] <Burgundavia> openwengo
[06:47] <Burgundavia> any video conferencing program that speaks sip
[06:47] <hendry> why doesn't ubuntu provide SIP addresses?
[06:47] <joelbryan> google talk?
[06:47] <hendry> can I use my google account with Ekiga?
[06:48] <Burgundavia> hendry: http://en.wikipedia.org/wiki/List_of_SIP_software
[06:48] <Burgundavia> hendry: that is jabber and that is a different protocol entirely
[06:48] <hendry> Burgundavia: so that's a no?
[06:48] <Burgundavia> https://wiki.ubuntu.com/UbuntuMac
[06:48] <Burgundavia> no
[06:48] <Lathiat> ekiga provides its own sip address server
[06:49] <Burgundavia> ideally we should one "talking to people" client that does all this
[06:49] <Lathiat> you get @ekiga.nets
[06:49] <hendry> so with Ekiga I can't talk to GoogleTalk peeps. Oh gawd
[06:49] <Lathiat> no, googletalk is a totally separate protocol
[06:50] <joelbryan> I think google is upto sip support
[06:50] <Burgundavia> nothing but googletalk currently does the video stuff from there
[06:50] <G0SUB> hendry: GTalk is XMPP
[06:50] <Burgundavia> Google Talk supports XMPP with the beta release. We plan to support SIP in a future release. Additionally, we will evaluate other protocols as appropriate, to continue to deliver on our commitment to open communications
[06:50] <hendry> i remember writing a SIP review paper. I remember it sucking
[06:51] <hendry> http://www.cs.helsinki.fi/u/kraatika/Courses/MobInt/Essay2/Hendry.pdf
[06:52] <joelbryan> Burgundavia: your from google! cool.
[06:52] <Burgundavia> joelbryan: uh, I wish
[06:53] <joelbryan> misinterpreted your post, looks like your from Google
[06:53] <hendry> wish to be another corporate Google drone? ;)
[06:53] <_ion> He probably pasted it.
[06:53] <Burgundavia> joelbryan: I copied that from the googletalk faq
[06:53] <Burgundavia> sorry, should have quoted it
[06:53] <joelbryan> yeah, I understand now.
[06:54] <fabbione> sladen: have you decided to take over X?
[06:54] <Burgundavia> fabbione: he touched it, his now!
[06:55] <fabbione> sladen: i don't mind if you want to work on X, but we need to coordinate the work.
[06:55] <sladen> fabbione: oh, don't worry, I left the Maintainer field along so you'll get all the bugs :)
[06:55] <_ion> :-)
[06:55] <fabbione> sladen: eheh i didn't touch it either.. sucks to be Daniel Stone
[06:56] <sladen> fabbione: yeah, I'm only  interested in i810 stuff that I can test here and that's not too intrusive
[06:56] <joelbryan> do you think there should be a welcome screen for Dapper, just like fresh install XP's?
[06:56] <fabbione> sladen: what has agpgart to do with the resolution issue?
[06:56] <Burgundavia> joelbryan: only in the OEM mode
[06:56] <fabbione> sladen: that guy had 1MB of shared ram allocated from the BIOS.. X did the detection correctly
[06:56] <joelbryan> Burgundavia: really, are there screenshots?
[06:56] <sladen> fabbione: what's your opinion on fixing the Xv stuff---that's a bug that has been bugging for ages
[06:57] <fabbione> sladen: what bug is that?
[06:57] <sladen> fabbione: doesn't the agpgart support allow the available memory window to be dynamically altered?
[06:57] <Burgundavia> joelbryan: OEM currently is text only. It would be nice if it had a pygtk interface. Want to write one?
[06:57] <fabbione> sladen: i did a round of fixes to get rid of stupid bugs in the libs.. i still need to get to drivers
[06:57] <fabbione> sladen: not if the BIOS forces the shared mem to N Mb
[06:57] <joelbryan> Burgundavia: yeah, I'm currently writing a GTK+ version
[06:58] <fabbione> sladen: this is one of these card that doesn't have its own RAM.
[06:58] <fabbione> sladen: so the BIOS rules you
[06:58] <fabbione> sladen: have seen it many many many times
[06:58] <sladen> fabbione: bug #28326  for the Xv
[06:58] <Ubugtu> Malone bug 28326 in xserver-xorg-driver-i810 "crashes after long-use -> infinite resprawn (Xv trigger?)" [Major,Confirmed]  http://launchpad.net/bugs/28326
[06:58] <joelbryan> Burgundavia: I want to know what OEM mode asks to the user?
[06:59] <Burgundavia> joelbryan: name, password, timezone, dob, mothers maiden name, dogs birthday, what you ate for dinner last night :)
[06:59] <Burgundavia> joelbryan: seriously, only the first three are what you need
[06:59] <sladen> fabbione: most cards are shared memory now (eg. i810) and the allocated RAM goes up and down based on what X asks for  (IIRC, E&OE)
[07:00] <joelbryan> Should it asks to register a Ekiga.net SIP name?
[07:00] <Burgundavia> joelbryan: and you migth be able to reuse on of the espresso parts (the one that creates users)
[07:00] <Burgundavia> joelbryan: nope
[07:00] <joelbryan> Should it asks to run Ekiga on startup?
[07:00] <hendry> does anyone here use Gmail and still doesn't have Talk integrated?
[07:01] <Burgundavia> joelbryan: just checking, do you know what the OEM installer is?
[07:01] <fabbione> sladen: do we have a patch for 28326? otherwise i am not sure i can fix it...
[07:01] <joelbryan> I've seen it, but not use it, it doesn't have an explanation of what OEM mode is, so I use normal install instead
[07:02] <sladen> fabbione: AlanH pointed me to some stuff of his, but it needs pulling out from bigger commit
[07:02] <Burgundavia> joelbryan: OEM installer is when someone is installing the box for somebody else. Such as Dell, who preinstall Windows
[07:02] <fabbione> sladen: i have never seen this dynamic mem allocation happening.. i *think* the only way to force the request it to set VideoRAM but we can't do it by default
[07:03] <Burgundavia> joelbryan: the questions that are relevant to the user (their name and where they live) are left until the end. The machine is shipped at the state when you turn it on, you get those questions asked
[07:03] <fabbione> sladen: bigger commit for the i810 or all over the X tree?
[07:03] <Burgundavia> joelbryan: currently that is a text mode, but it would be much nicer if it was a pygtk interface
[07:03] <fabbione> sladen: i am dealing to ask UVF breakage if there are good reaons
[07:03] <fabbione> reasons even
[07:04] <joelbryan> Burgundavia: should it be called, "Personalize Installation (OEM Mode)"
[07:04] <sladen> fabbione: only instead i810.  I think the only other thing in that bundle might be rotation support (which would be nice to have aswell to support the various tablets)
[07:04] <Burgundavia> joelbryan: OEM installation is really only good for those who are doing lots of installs on machine they themselves are not going to be doing
[07:05] <sladen> fabbione: ^^only inside i810
[07:05] <infinity> joelbryan: More to the point, it's everything BUT personal.    They "install" ubuntu once.  Image the disk XXX thousand times and then when each user turns on their machine for the first time it's already installed but still asks the username/password...
[07:06] <infinity> joelbryan: If you've ever bought a machine with a Windows OEM install on it, you'd know what I mean (except theirs is graphical and ours isn't quite yet)
[07:06] <Burgundavia> joelbryan: http://ubuntu.wordpress.com/2005/10/11/ubuntu-oem-mode/
[07:06] <Burgundavia> infinity: can we use the espresso user-setup bit?
[07:07] <sladen> fabbione: maybe I'll look at it when awake.  the Xv is a bug-fix for something that's been around for a long time;  xrandr would be a UVF feature request (it's been in Xorg CVS for about 12weeks now)
[07:07] <infinity> Burgundavia: Probably.  I don't know how much developer time there is to go around to fix up OEM mode AND finish espresso.
[07:07] <fabbione> sladen: did they release a new driver with this stuff?
[07:07] <fabbione> sladen: or are we talking only CVS...
[07:07] <infinity> Burgundavia: But espresso could well be used as the graphical stage2 for OEM, yeah...
[07:07] <Burgundavia> infinity: OEM works, that is all i care about
[07:07] <infinity> Burgundavia: (Well, bits of it)
[07:07] <joelbryan> Burgundavia: should it be pygtk?, why not C?
[07:08] <Burgundavia> joelbryan: because pygtk is easier and faster to write in
[07:08] <Burgundavia> not that I write code...
[07:08] <joelbryan> Burgundavia: ok, uhmm... don't know much about python, but I can write it entirely in GTK+
[07:09] <joelbryan> Burgundavia: I mean C
[07:09] <joelbryan> Burgundavia: or I use Glade and generate it in libglade
[07:10] <infinity> It's just faster to prototype in a scripting language, that's all.  If you're comfortable and quick with C, no one's suggesting you not use it.
[07:12] <joelbryan> infinity: ok, hehehe, just trying to comform with ubuntu standards, maybe I'll break something if I use this and that.
[07:13] <joelbryan> clearly Ruby isn't installed default, so I should not use it.
[07:13] <infinity> joelbryan: If you want to have other people be able to make very rapid changes/bugfixes to it, python's a better choice than C  (I say this, despite not really liking python at all, and rather quite liking C)
[07:14] <infinity> joelbryan: But if you don't know python at all, and aren't in the mood to learn (or just plain prefer C), then go with C.  Most anyone who will want to hack on your stuff will know C anyway.
[07:16] <Mez> hey infinity, everyone else
[07:17] <joelbryan> Is there a problem with Glade generated source?, future compatibility issues? security holes?
[07:18] <joelbryan> I think Glade generated source is neat, it has modular source codes, much easier to understand.
[07:23] <Burgundavia> fabbione: why is timezone data stored in glibc?
[07:25] <infinity> Burgundavia: It's not anymore.
[07:25] <infinity> Burgundavia: It's in "locales" now.
[07:25] <Burgundavia> infinity: but why does upstream do it that way?
[07:25] <Burgundavia> it seems very "kitchen sink"ish
[07:26] <infinity> Burgundavia: Upstream doesn't dictate how we split it up.
[07:26] <infinity> Burgundavia: glibc can't really do its job (well, all of its jobs) without timezone and locale info, so upstream ships that too.
[07:26] <Burgundavia> ah
[07:26] <infinity> We happen to know (from experience), that on a cut down system, you can live without that stuff.
[07:26] <infinity> So we now ship them seperately.
[07:26] <jdub> glibc is our rock
[07:26] <infinity> But most people probably still want the kitchen sink.
[07:27] <Mithrandir> I like kitchen sinks.  Hard to make food without one.
[07:27] <infinity> 99.9% of installations are "broken" without locales and zoneinfo, IMO.
[07:27] <infinity> The other 0.1%... Well.. I happen to be one of those users. :)
[07:27] <Burgundavia> ok. I just seemed so odd to have two seemingly non-relating things in one package
[07:27] <Burgundavia> package being glibc, not in the debian sense
[07:27] <Mez> Mithrandir, why is it hard to make food without the kitchen sink? surely you dont really need that much water
[07:28] <Mez> infinity, that's cause you're weird ;)
[07:28] <Mithrandir> Mez: I wash the stuff I make food with quite a lot.  Like, the semi-large knife I use for meat and vegetables, for instance.
[07:28] <Mithrandir> Mez: as well as all the plates and stuff I use in between
[07:29] <Mez> Mithrandir, surely you could wash those in the bathroom sink though? or under the tap outside?
[07:29] <Mez> Mithrandir, why does it specifically have to be a "kitchen" sink]
[07:29] <Mithrandir> Mez: tap outside?  In -10C and one floor down?
[07:29] <Mithrandir> because I tend to make food in the kitchen and having the tools I need to make food elsewhere is not helpful?
[07:29] <Mez> Mithrandir, *shrugs* I've had to deal with worse (-10 inside )
[07:30] <Mez> Mithrandir, it's helpful to have a kitchen sink  but not essential
[07:30] <Mez> (anyway - I'm just rambling)
[08:02] <pitti> Good morning
[08:17] <fabbione> who has an opinion on #35758 ?
[08:18] <fabbione> it looks like a dumb bug
[08:18] <fabbione> Ubugtu: malone #35758
[08:18] <Ubugtu> Malone bug 35758 in xinit "startx leaks .serverauth.???? files" [Normal,Unconfirmed]  http://launchpad.net/bugs/35758
[08:19] <infinity> Looks like a "Don't Do That, Then" bug to me.
[08:19] <fabbione> yeah exactly
[08:25] <hendry> can ubuntu resize ntfs?
[08:25] <infinity> Yes, but I'm not sure I'd recommend it.
[08:26] <hendry> infinity: from the installer eh?
[08:27] <infinity> It might be disabled in the install out of paranoia.  I'm not sure.
[08:27] <infinity> Kamion / Mithrandir : --^
[08:34] <infinity> mdz: Around?
[08:34] <mdz> infinity: yep
[08:35] <Burgundavia> pitti: have you seen this? https://wiki.ubuntu.com/RootSudo?action=diff&rev2=28&rev1=27
[08:35] <infinity> mdz: How do you feel about a UVF exception for ttf-freefont?
[08:36] <mdz> infinity: nervous
[08:36] <Seveas> Burgundavia, I already reverted the latest edit
[08:36] <infinity> mdz: It's currently FTBFS (and has been since January, go us!), Christian Perrier has taken it over in Debian and is giving it much love.
[08:36] <mdz> new upstream versions of freefont always seem to have unpleasant side effects
[08:36] <mdz> changed glyphs, adding new ones which override other fonts in unexpected ways, etc.
[08:36] <infinity> mdz: Yes, but at least this time it's being maintained by someone who's close to both the installer and the translators.
[08:36] <mdz> takes a while to shake out
[08:37] <mdz> what's the nature of the FTBFS?  this version built at one point
[08:37] <Burgundavia> Seveas: thanks, I saw that
[08:37] <infinity> mdz: Alternately, I could just fix the FTBFS... But that would, ironically, bring us a new upstream too, since we never got the new upstream built.
[08:37] <infinity> mdz: Ever since it was synced, it hasn't built.  No one bothered to check.
[08:38] <Seveas> Burgundavia, episode 999 in the story of John Richard Moser - more to follow soon I'm afraid...
[08:38] <infinity> mdz: I'm going through every FTBFS in main right now (only a couple left) and found this.  <sigh>
[08:38] <Burgundavia> Seveas: we seem to have a few. George Farris is another
[08:39] <Seveas> that's the downside of being popular
[08:39] <infinity> mdz: We have 20051102-2 built, 20051206-2 synced (but FTBFS), and current upstream is 20060126b-2
[08:39] <mdz> infinity: gah
[08:39] <pitti> Burgundavia: heh, classic trojan horse :)
[08:40] <infinity> mdz: That's what I thought. :/
[08:40] <Seveas> Burgundavia, there was a troll yesterday that followed me everywhere and even called me on the phone (which means he can google, takes ~3 seconds to find it) - just symptoms of a growing community
[08:40] <Burgundavia> Seveas: ah, the warty days
[08:40] <infinity> mdz: Alternate option at this stage would be to reupload the old version with a hideous version number, since we know it works for us.
[08:40] <Seveas> Burgundavia, how I long for those sometimes...
[08:40] <infinity> mdz: Perhaps I should discuss this with Kamion instead, since this has a pretty high impact on the installer?
[08:40] <mdz> infinity: it does?
[08:41] <infinity> mdz: At least, I believe this is the scary font that gets used in the installer, right?
[08:41] <infinity> Or am I thinking of another scary font...
[08:41] <infinity> Maybe I'm on crack. :)
[08:41] <mdz> I think the installer uses default fonts
[08:41] <infinity> The installer uses some scary all-in-one font for a few screens (though that may be obsolete now with gfxboot)
[08:42] <Burgundavia> Seveas: I sort of do, but then think of the cool projects that are happening because Ubuntu is big
[08:42] <Seveas> true, true
[08:42] <Burgundavia> and the NM work by _ion and others
[08:42] <Seveas> ah well, let's not behave like old men and look forward instead of looking back
[08:43] <Burgundavia> Seveas: incidentally, how old are you?
[08:43] <Seveas> If I get the wxwidgets problem sorted, then maybe I can have Xara ready in time
[08:43] <Seveas> Burgundavia, 23.5 minus 8days
[08:43] <Burgundavia> Seveas: ah, my age then
[08:44] <Seveas> and certainly not the age yet to keep dreaming about the past ;)
[08:44] <mdke> youngsters
[08:45] <Seveas> Burgundavia, did you see what was going on in #ubuntu between now and 8 hours ago?
[08:45] <Seveas> I heard some rumours arnieboy 'paid us a visit' and started swearing at everyone
[08:45] <Burgundavia> Seveas: happily, my time constraints mean I can no longer follow #ubuntu
[08:46] <Seveas> hehe, lucky fellow :0
[08:46] <Seveas> it's increasingly hellish there at time
[08:46] <Seveas> s
[08:47] <Seveas> OMG, when did karma explode at launchpad?
[08:47] <Seveas> I was at 1267 yesterday, checking regularly since I wanted a screenshot of Karma: 1337 but now my karma is 42617
[08:48] <infinity> I need to write some karma bits into all the buildd administration actions, so I look like less of slacker...
[08:48] <Seveas> hehe
[08:48] <Seveas> apparently bug triaging is very high vaued now
[08:49] <Seveas> so shall I file some bugs against a few of your packages? >:)
[08:49] <infinity> I have enough bugs, thanks. :P
[08:49] <robitaille> yeah, some of us have had very good karma increases in the last 24 hours
[08:50] <Burgundavia> it appears that specs are good karma boosters too
[08:50] <Seveas> robitaille, your karma must be close to infinity (no pun intended0 now
[08:50] <Seveas> robitaille, btw: next CC meeting is april 3, 09:00 UTC. Could you please add that to the fridge?
[08:51] <robitaille> Seveas:  done already
[08:51] <Seveas> you rock
[08:51] <infinity> pitti: If I yell at you, can you pass the chastisement on to mvo when he shows up (since I've fixed this bug several times now, and you both did it more than once)? :)
[08:51] <pitti> infinity: erm, erm, for which bug?
[08:52] <infinity> pitti: INTLTOOL-UPDATE IS IN INTLTOOL, ARGH!  *cough*
[08:52] <infinity> There, all done.
[08:52] <pitti> ah, that one *blush*
[08:56] <infinity> doko_: Are you alive, or just suffering client bounce?
[08:58] <doko_> infinity: both
[08:59] <infinity> doko: Do you recall what your rationale was for switching libidl to mcpp from cpp?
[08:59] <infinity> doko: It's FTBFS with mcpp, works great with cpp.
[09:00] <doko> infinity: have only one cpp used on the CD, all of gnome uses mcpp
[09:00] <infinity> doko: Because of xrdb, I assume...
[09:01] <infinity> (At least, it's the only thing that directly depends on mcpp)
[09:01] <infinity> We could just switch xrdb to using cpp...
[09:01] <infinity> Unless that breaks the world.
[09:01] <infinity> Otherwise, feel free to investigate the libidl FTBFS.
[09:01] <Mithrandir> infinity: I thought we switched to mcpp since it's way quicker?
[09:01] <infinity> I have no idea, hence why I was asking. :)
[09:02] <doko> yes, the speed was mcpp's advantage
[09:02] <infinity> doko: Kay, can you kindly make libidl actually work with mcpp, then? :)
[09:03] <infinity> I suspect it's just a broken autoconf test or something equally silly, but haven't poke it.
[09:06] <fabbione> if you are fixing mcpp there is also another annoying bug about predefined macros not being there that it would be very nice to get rid of
[09:10] <doko> infinity: hmm, doesn't fail here ...
[09:10] <infinity> doko: ...
[09:10] <infinity> doko: It failed on every buildd, some several times...
[09:12] <mdke> is there a good reason the exim4 metapackage is in universe?
[09:12] <mdke> its dependencies are both in main, i think
[09:13] <infinity> mdke: No, I keep meaning to seed the metapackage.
[09:13] <doko> Predefined macro file '/usr/lib/gcc/i486-linux-gnu/4.0.3/include/mcpp_gcc40_predef_old.h' is not found
[09:13] <infinity> mdke: Thanks for the reminder.
[09:13] <mdke> infinity, ah cool. nice
[09:13] <doko> that's the only warning I get
[09:14] <fabbione> doko: yes.. that one
[09:14] <fabbione> there are 2
[09:14] <fabbione> old and std
[09:14] <infinity> configure: error: C preprocessor "mcpp" fails sanity check
[09:14] <infinity> doko: my local attempt --^
[09:15] <infinity> Oh, haha..
[09:15] <infinity> /home/adconrad/libidl/libidl-0.8.6/./configure: line 4208: mcpp: command not found
[09:15] <infinity> That would be much more useful if you didn't hide it in a log, dear autoconf!
[09:15] <Keybuk> "Microsoft delays launch of Vista"
[09:15] <Keybuk> *blink*
[09:16] <Keybuk> ...by 6 weeks?
[09:16] <infinity> doko: You just forgot the build-dep, that's all.  Feh.
[09:16] <Seveas> Keybuk, something like that
[09:16] <pitti> Keybuk: 'World delays launch of April - by six weeks'
[09:16] <infinity> doko: I'll upload right now.
[09:16] <pitti> Keybuk: that would be much more helpful to both M$ and us, wouldn't it? :)
[09:16] <Keybuk> yes
[09:17] <Keybuk> we could add an extra 42-day month after March
[09:17] <Keybuk> we could call it Stroll
[09:17] <pitti> Keybuk: Polishuary
[09:17] <doko> infinity: ohh, would be better ;)
[09:17] <Seveas> pitti, Bugfixtember
[09:17] <pitti> Seveas++
[09:17] <Keybuk> "Sliptember"
[09:18] <pitti> hey mvo
[09:18] <Treenaks> Hugtember?
[09:18] <Kamion> 05:57 < Burgundavia> joelbryan: OEM currently is text only. It would be nice if it had a pygtk interface. Want to write one?
[09:18] <pitti> mvo: protect your ears, infinity will yell at you
[09:18] <mvo> hey pitti
[09:19] <Kamion> Burgundavia: Oi, check your facts before saying that. ;-)
[09:19] <mvo> pitti: what did I do?
[09:19] <Kamion> infinity: installer and gfxboot both use unifont
[09:19] <infinity> pitti: No, no, you were supposed to pass it along for me.
[09:19] <infinity> Kamion: Ahh, I misremembered, then.
[09:19] <Keybuk> Kamion: could you process a NEW for me?
[09:19] <pitti> mvo: <infinity> pitti: INTLTOOL-UPDATE IS IN INTLTOOL, ARGH!  *cough*
[09:19] <infinity> mdz: Right, ball's back in your court, then, unless you want to delegate this one to the desktop guys. :)
[09:20] <pitti> infinity: I didn't know whether just yelling at me vented enough of your frustration already :)
[09:20] <Kamion> Keybuk: sure, I was halfway through morning NEW processing when Kirsten chucked me off the laptop for her morning website browsing
[09:20] <infinity> mdz: We can either upload the old package with a wonky version number, fix the currently FTBFS (and untested) one, or upload the newer onr from Debian.
[09:20] <Keybuk> Kamion: libitwouldbeniceifsomeonetestedthisoni386
[09:20] <mvo> heh :) I suppose we are talking about hwdb-client?
[09:20] <Keybuk> uh, I mean, libnl ;)
[09:20] <Keybuk> and stick a "!" in there
[09:20] <Keybuk> *ahem*
[09:20] <infinity> mvo: I think you may have done one or two, I know pitti did a couple. :)
[09:20] <Seveas> Keybuk, that's the thing used by NM, right?
[09:20] <Keybuk> Seveas: yes
[09:21] <Burgundavia> Kamion: by text I meant ala d-i text
[09:21] <Seveas> what do you need tested - I'm on i386
[09:21] <Keybuk> it only worked on i386
[09:21] <Keybuk> it didn't even compile on amd64
[09:21] <Kamion> Burgundavia: well sorry, you're still wrong :)
[09:21] <mdz> infinity: I suppose we bite the bullet; if we need to take a new upstream we might as well get the latest from Debian
[09:21] <Kamion> Burgundavia: oem-config is and has always been pygtk
[09:22] <infinity> mdz: Alright, I'll sync it right now, then.
[09:22] <Burgundavia> Kamion: I have not played with oem for a long time (breezy beta). I stand corrected
[09:22] <Kamion> you do a regular install first, but the "OEM installer" bit of it is pygtk
[09:22] <Kamion> breezy beta oem-config was pygtk too
[09:22] <infinity> mdz: At least I know the current maintainer is reasonably sane...
[09:22] <Burgundavia> I think I tried breezy at the time when OEM installer was borked, so hmm...
[09:23] <Kamion> it's borked in dapper now at the moment too - blocked on me having time to chase down the buglets
[09:23] <mdz> infinity: does soyuz not give you appropriate notifications/reports for FTBFS yet?
[09:23] <Kamion> also, FYI, it already uses user-setup
[09:24] <Kamion> (the backend)
[09:24] <infinity> mdz: Nope!  I'm using britney's out-of-date reports to tear through everything that's currently broken in main, then will quinn-diff universe to file bugs for the MOTUs.
[09:24] <Burgundavia> Kamion: hey, you get to wave the retroactive feature wand today :)
[09:25] <Kamion> Keybuk: do you need this in main straight away?
[09:25] <Kamion> mind you, that'd need an inclusion report ...
[09:26] <Keybuk> just to universe for now, then I'll get pitti to look at it
[09:26] <Kamion> ok
[09:26] <Kamion> accepted
[09:27] <Kamion> the last
[09:28] <Kamion> well, either that or all three, but the last will be the one that gets built :)
[09:28] <infinity> (as of yesterday, the last will be the only one that gets built)
[09:28] <infinity> Yay for that bug being fixed.
[09:28] <Keybuk> I  Soyuz
[09:29] <doko> infinity, mdz: you may use your https://launchpad.net/people/<user>/+packages page to get this kind of information
[09:29] <infinity> doko: Individuals can, I sure as heck can't. :)
[09:30] <infinity> doko: Not unless someone decides I own all the source packages in the archive.
[09:31] <doko> infinity: just open some tabs in your browser ;-P
[09:39] <mdz> sabdfl: morning
[09:40] <mdz> sabdfl: are you near SteveA? he seems to have called my phone about an hour ago
[09:50] <infinity> Oh, FFS... ttf-freefont was converted to cdbs, but our cdbs produces broken udebs.
[09:50] <infinity> \o/
[09:51] <_ion> Working packages are overrated.
[09:52] <siretart> hi _ion
[09:53] <_ion> Hi siretart
[09:53] <siretart> _ion: now my test is over. what's the status about your nm packages?
[09:54] <_ion> siretart: There's still stuff to be done. Mostly polishing.
[09:54] <mvo> infinity: for the intltool stuff (and one liners like this) I would prefer a quick ping/mail. I maintain all my stuff in bzr so I have to integrate the changes into that anyway
[09:54] <siretart> _ion: do you have a repository for source package you work on?
[09:55] <_ion> siretart: Nope, but setting one up wouldn't be a bad idea.
[09:55] <infinity> mvo: Duely noted for the future.  I'm just trying to kill every FTBFS in main right now. :)
[09:56] <siretart> _ion: do you coordinate with the debian utopia ppl?
[09:56] <siretart> _ion: they are the guys you have sent me the wpasupplicant patch for nm after all
[09:56] <_ion> siretart: Not exactly coordinate, but i have looked at their packages.
[09:56] <mvo> infinity: yeah, thanks for this :)
[09:57] <siretart> ok
[09:57] <siretart> _ion: I assume I need a patched l-r-m for madwifi, no? is there one available for current kernels?
[09:58] <_ion> siretart: Their packages are going to somewhat different direction  they support VPN and use cdbs, whereas i switched back to the old build system from cdbs (which i was using originally) because i was told that changing the build system from 0.5.1 would decrease the chance of the package being accepted.
[09:58] <siretart> _ion: ok, I see
[09:59] <_ion> siretart: Hmm, i don't think there are patched l-r-m packages available for the current kernel image yet.
[09:59] <siretart> _ion: oh. ok, then I need to patch them myself.
[09:59] <_ion> siretart: But using n-m with madwifi-old is problematic as long as madwifi-old doesn't support background scanning.
[10:00] <_ion> siretart: IIRC Pygi is going to look whether it's feasible to backport it form madwifi-ng.
[10:00] <_ion> from
[10:00] <siretart> _ion: thats no real regresseion. but afaik, you can disable scanning in nm while having a connection
[10:01] <_ion> Ok.
[10:01] <infinity> _ion: I intend to include that small madwifi patch (the WPA one) in my next LRM upload, so we can stop building custom test packages.
[10:02] <_ion> infinity: Nice.
[10:02] <infinity> _ion: Reading over the code it touches, it seems harmless to me.
[10:02] <Keybuk> infinity: do we have madwifi-ng yet?
[10:02] <infinity> _ion: As for backporting the scanning thing, that would be awesome, but would require some heavy review and testing.
[10:02] <_ion> keybuk: Dapper will not get madwifi-ng AFAIK.
[10:02] <Keybuk> _ion: that wasn't the plan
[10:03] <infinity> Keybuk: Dirty hacks to include both?  mjg59 and I have tossed around a few scary ways to do it that involve sed and a screwdriver, but we've not gotten to it yet.
[10:03] <siretart> that would be really awesome
[10:04] <siretart> I mean there is already nvidia and nvidia-legacy. whats the conceptual difference in madwifi-old vs madwifi-ng?
[10:04] <mvo> Kamion: thanks for processing ttf-sil-doulos, ttf-sil-charis. ttf-gentium has the same license, but is in multiverse right now, what needs to be done to get it into universe? is a new upload required for this?
[10:06] <infinity> siretart: The biggest differece is that nvidia is only one kernel module, madwifi is a whole set of them (with dependencies).
[10:07] <infinity> siretart: So, the hack gets a bit dirtier, in that one set (ideally the old ones, since we want to switch to -ng eventually) will need internal renaming, not just a filename change.
[10:08] <_ion> Btw., why is l-r-m a single, monolithic source package?
[10:08] <infinity> siretart: Anyone willing to step up and do said renaming is welcome to do so.  Then we need to get some PCI ID lists ASAP for machines that MUST use -ng (they'll skip on trying to load -old at all in the new world order, stuff like new Thinkpads), everyone else gets -old by default, and you can switch if you feel the urge.
[10:08] <infinity> siretart: Ish.
[10:08] <infinity> _ion: So it's not a royal pain in the ass to update on every kernel ABI bump.  It's intentional.
[10:09] <siretart> infinity: i see. thanks for explanation
[10:09] <Treenaks> hmm.. http://www.securityfocus.com/bid/17178/info
[10:13] <Kamion> mvo: no need for a new upload - I'll move it once this publisher run has finished
[10:14] <infinity> Happy hacking, kids.
[10:16] <mvo> Kamion: thanks, I'll ask for it to enter main later, it one of the missing fonts that we want in fontconfig
[10:17] <mvo> pitti: could you add ttf-lao as a dependency for language-support-lo please?
[10:20] <Pygi> infinity: you there perhaps?
[10:29] <pitti> mvo: shouldn't fonts go to *-desktop rather?
[10:29] <mvo> pitti: if we still have room on the cd, sure
[10:29] <pitti> mvo: well, we don't, but it's our current policy...
[10:29] <pitti> mvo: and 50 kB isn't too bad
[10:29] <mvo> pitti: ok, it's not a big package
[10:29] <mvo> I'll add it
[10:33] <Mithrandir> mvo: language-selector-common needs a versioned replaces on language-selector for /usr/share/language-selector/data/countries
[10:33] <mvo> Mithrandir: hm, I'm thought I added one, let me check
[10:34] <Mithrandir> mvo: you added one for <<, not for =<
[10:34] <mvo> Mithrandir: yeah, damm. thanks!
[10:35] <carlos> pitti: hi, do you have a couple of minutes?
[10:35] <pitti> actually not, but if it's urgent?
[10:36] <pitti> carlos: the blender POT thingy?
[10:36] <carlos> pitti: not really, openoffice
[10:36] <carlos> but it can wait
[10:38] <seb128> Mithrandir: https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/35845
[10:38] <Kamion> Kinnison: awake?
[10:38] <Ubugtu> Malone bug 35845 in xkeyboard-config "compose:ralt option broken with 0.8 update" [Normal,Unconfirmed]
[10:38] <carlos> pitti: just ping me when you are less busy, please
[10:38] <seb128> Mithrandir: any opinion on the suggest change?
[10:38] <Kamion> Kinnison: your fix for binary accepts last night left out a (presumably) cowboy fix that cprov did for me on change-override.py
[10:39] <Kamion> Kinnison: bug 35889
[10:39] <Ubugtu> Malone bug 35889 in launchpad-upload-and-queue "change-override.py broken by 20060321 rollout" [Normal,In progress]  http://launchpad.net/bugs/35889
[10:39] <pitti> carlos: will do; OO.o? that isn't for doko rather?
[10:40] <carlos> pitti: not really, it's related with the es-ES.po -> es.po mapping
[10:40] <Mithrandir> seb128: he's upstream, isn't he? :-)
[10:40] <seb128> Mithrandir: he is ;)
[10:41] <Mithrandir> seb128: could you apply it and see if it fixes it for you?  If so, I say we just run with that
[10:41] <seb128> Mithrandir: k, will do that
[10:46] <pitti> carlos: what about it? YM the po files that OO.o generates during build?
[10:46] <Kinnison> infinity: how're the binaries?
[10:47] <carlos> pitti: yes, I think we talked about mapping them at pkgstriptranslations but I don't remember the details or even if we reach an agreement on it...
[10:47] <carlos> pitti: same with abiword
[10:48] <pitti> carlos: oh, did we? I can't remember
[10:48] <carlos> pitti: same here
[10:48] <carlos> ;-)
[10:49] <siretart> _ion: where can I see your latest nm 0.6 source package?
[10:49] <Kinnison> Kamion: impressive considering I cp'd the current tree to change
[10:51] <Kamion> Kinnison: boggle
[10:51] <hunger> Is it a known issue that the buttons on a thinkpad T43p do no longer work?
[10:52] <Kinnison> Kamion: ask cprov?
[10:53] <hunger> Oh, false alarm, the buttons work, it is just the kde popup windows that went missing.
[10:54] <Kamion> ogra: help re gnome-screensaver?
[10:54] <Kamion> ogra: 'sudo gnome-screensaver-command --poke' can't talk to the session bus
[10:55] <Kamion> ogra: which makes it hard to use from within espresso, which is invoked via sudo
[10:58] <Kinnison> either whatever invokes espresso needs to preserve DBUS_SESSION_BUS (envvar) or you're going to have to find some way around it
[11:00] <Kamion> YM DBUS_SESSION_BUS_ADDRESS?
[11:00] <Kamion> and sudo does preserve that
[11:01] <Kamion> I don't have DBUS_SESSION_BUS set
[11:01] <Kinnison> sorry, yes _ADDRESS
[11:01] <Kinnison> I forgot it changed
[11:01] <Kinnison> not got to laptop yet
[11:02] <stewski> is it worth creating a bug/wishlist that the gnome trash would store a restore path (cope with duplicates)
[11:10] <dholbach> hello
[11:10] <Treenaks> morning
[11:10] <pitti> hi dholbach
[11:11] <Pygi> when will finally croatian keyboard layout start workin' properly in xorg by default? ;)
[11:12] <infinity> Kinnison: My binaries are fine, thanks. :)
[11:12] <infinity> Pygi: You rang?  I'm only around for a few minutes.
[11:12] <Pygi> infinity: o, hello ;)
[11:12] <Pygi> infinity: yup, I did...can you please  build patched l-r-m on new kernel build?
[11:13] <Kinnison> infinity: cool, thanks
[11:13] <infinity> Pygi: As I told _ion, I'll be including that patch in my next LRM upload to the archive, so we can stop with the forked build.
[11:13] <infinity> Pygi: It seems safe and correct enough to me to do so.
[11:13] <pitti> does anyone know 'join'? I'm currently desperating on it
[11:13] <Pygi> infinity: hm, ok, thanks ^_^ any ideas when will that be?
[11:13] <Pygi> some people are rampaging :-/
[11:13] <infinity> Pygi: We'll also get wider testing that way and know if we have to back it out. :)
[11:13] <infinity> Pygi: Tomorrow, probably.
[11:13] <Pygi> kk, thanks infinity ;)
[11:13] <infinity> Pygi: (My tomorrow, which is in ~12 hours)
[11:14] <Pygi> same here
[11:14] <Pygi> 13 hours here tho
[11:14] <pitti> Kamion: you have used join, right? do you have a minute to help me?
[11:14] <infinity> Well, "tomorrow" is in 3 hours for me, technically, but I'm planning on sleeping at some point.
[11:14] <Pygi> infinity: yes, I know ^_^ you are in australia...
[11:15] <Seveas> infinity: sleep, schmeep :)
[11:15] <Pygi> Seveas: that patch I showed you yesterday makes the package unbuildable
[11:15] <Pygi> ;)
[11:16] <Seveas> Pygi, then don't hang around here - fix it for crying out loud!
[11:17] <Pygi> Seveas: heh ^_^
[11:22] <Kamion> pitti: sure
[11:22] <Kamion> Kinnison: any idea what else it might be, given that DBUS_SESSION_BUS_ADDRESS is preserved?
[11:23] <Kamion> Kinnison: strace shows that it's sending AUTH EXTERNAL claiming uid of 0 (fair enough)
[11:23] <Kamion> which is about where it fails
[11:24] <Kinnison> aah
[11:24] <Kinnison> hmm
[11:24] <Kinnison> maybe it needs to sudo -u personname gnome-screensaver-command --poke
[11:28] <Kamion> sudo -u $SUDO_USER? ugh, but would work I guess
[11:29] <Kamion> yeah, "sudo sh -c 'sudo -u $SUDO_USER gnome-screensaver-command --poke'" DTRT
[11:29] <Kamion> how horrible
[11:29] <Kamion> thanks
[11:31] <Kinnison> you'll wash the dirty feeling off eventually
[11:34] <ogra> Kamion, hey, it prevents you from depending on dbus at least :)
[11:36] <Mithrandir> seb128: doesn't evince antialias graphics?
[11:37] <seb128> Mithrandir: if poppler is built with cairo probably, but we build it with splash
[11:37] <Mithrandir> seb128: ok
[11:49] <lifeless> anyone else having gnome-screensaver routinely blank-cause-it-wants-to ?
[11:50] <dholbach> whiprush, jdub: could somebody of you please remove the bugsquad meeting from the calendar - we need to postpone it, I'll send an announcement later
[11:51] <jdub> dholbach: ok
[11:51] <dholbach> jdub: thank you very much
[11:53] <Kamion> Mithrandir: ok, uploaded your espresso changes now, thanks as ever
[11:55] <Mithrandir> Kamion: thanks
[12:01] <Riddell> ogra: you don't like the flame xscreensaver?
[12:01] <mvo> I would like to add ttf-thai-tlwg, ttf-lao, ttf-gentium to ubuntu-desktop. any objections? otherwise I'll commit it in a bit
[12:02] <ogra> Riddell, why ?
[12:03] <Mithrandir> seb128: do you have any idea what the submitter in https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/33565 is talking about?
[12:03] <Ubugtu> Malone bug 33565 in xkeyboard-config "xkeyboard use pc105 instead of macintosh" [Major,Unconfirmed]
[12:04] <Riddell> ogra: kscreensaver happens to use that one for its test to see if xscreensaver exists
[12:04] <Riddell> I'll change it to something else
[12:04] <ogra> Riddell, its in xscreensaver-data (it should be at least)
[12:05] <Kamion> mvo: how big are they combined?
[12:05] <seb128> Mithrandir: https://bugs.freedesktop.org/show_bug.cgi?id=2870
[12:05] <infinity> Kamion: Oh, we now have end-to-end %source support for seeds, right?  It's safe to use it?
[12:05] <Kamion> infinity: yes
[12:05] <mvo> Kamion: ~1,5mb
[12:06] <Riddell> ogra: it's in xscreensaver-data-extra
[12:06] <Kamion> mvo: oof, more than I'd hoped
[12:06] <seb128> Mithrandir: I think that should be fixed with xkeyboard-config 0.8
[12:06] <mvo> well, we could ship them as part of the language-support packs
[12:06] <seb128> 2005-10-11 svu
[12:06] <seb128>         * symbols/macintosh_vndr/fr: update French Macintosh keyboard, closed
[12:06] <seb128>         https://bugs.freedesktop.org/show_bug.cgi?id=2870
[12:06] <ogra> Riddell, oh, then it wasnt in the default selection in wart~breezy ...
[12:06] <mvo> at least for some
[12:06] <seb128> Mithrandir: the changelog has that mention
[12:06] <Mithrandir> seb128: excellent, I'll close the bug, then
[12:07] <Kamion> pitti's right, we have traditionally put fonts in desktop
[12:07] <infinity> Anyone have any objections to "eximon4" (the exim monitor) heading to supported as a result of changing the exim4 seeds to a source seed?
[12:07] <Mithrandir> infinity: I've never seen it as useful, but I don't have an active objection.
[12:07] <Kamion> infinity: not me
[12:08] <infinity> Mithrandir: I don't use it either, but it reduces 5 lines of messy seeds to a 1 line source seed that seems more sane.
[12:08] <ogra> Keybuk, bzrk doesnt work with the recent bzr and bzrtools ...
[12:09] <mvo> Kamion: so 1,5mb is a problem ?
[12:09] <Keybuk> ogra: ddaa maintains bzrk now
[12:10] <ogra> ah,k
[12:10] <Mithrandir> is bzrk pronounced "berzerk"?
[12:10] <Mithrandir> possibly berserker.
[12:10] <ogra> heh
[12:10] <Seveas> bzrkr
[12:10] <Seveas> bzr-kr - bzr written in K&R C
[12:10] <Kamion> mvo: we do have room though, so go ahead; we can revisit later if need be
[12:11] <Keybuk> Mithrandir: yes
[12:11] <mvo> thanks
[12:12] <Mithrandir> Keybuk: so bzr should be pronounced like bursar.
[12:12] <Keybuk> "buzzer"
[12:12] <Mithrandir> bzzt
[12:12] <Keybuk> it could be "bursar" if dried frog pills were involved
[12:14] <Mithrandir> does bzr exist in that universe?
[12:14] <mvo> lol
[12:15] <ajmitch> so that's why launchpad has the librarian
[12:15] <infinity> Kamion: And if I do a " * %source" in support and a " * binary" in ship, germinate will do the expected thing, I assume?
[12:16] <Mithrandir> also, I claim my luggage of sapient pearwood.
[12:20] <fabbione> Kamion: could you be so kind to NEW xserver-xorg-driver-v4l ?
[12:20] <infinity> pitti: Another oddity.  All of postgresql-8.1 lands in main except for -server-dev ... Intentional, or should be fixed?
[12:21] <Kamion> Mithrandir: so should bug 34332 be fixed now?
[12:21] <Ubugtu> Malone bug 34332 in espresso "crashes right after timezone selection" [Normal,Confirmed]  http://launchpad.net/bugs/34332
[12:21] <Kamion> infinity: yes
[12:21] <pitti> infinity: we don't really need it in main, but it's completely harmless
[12:21] <Mithrandir> Kamion: yes
[12:21] <Kamion> Mithrandir: will you say that in the bug or should I?
[12:21] <pitti> infinity: I'm just hesitant to explicitly seed it, since we don't want to add library-like stuff to the seeds any more, right?
[12:21] <infinity> pitti: Do we get anything out of not having it in supported (since we support the source)?
[12:22] <infinity> pitti: I was going to convert the 6 pgsql seeds to 1 source seed, actually. :)
[12:22] <pitti> infinity: no, just seed cruft
[12:22] <infinity> pitti: Hence the question.
[12:22] <pitti> infinity: oh, wow, then go ahead :)
[12:22] <Mithrandir> Kamion: I can close the bug, just a sec
[12:23] <Kamion> infinity: any idea why https://launchpad.net/+builds/+build/178965 says "Dependencies: libxosd-dev"?
[12:24] <infinity> Kamion: Because somehting has a bit of a (harmless, it seems) bug that cprov and I need to find.
[12:25] <infinity> Kamion: Ignore it for anything but Dep-Wait packages (where it's actually sane and correct)
[12:25] <Mithrandir> ooh, shiny.  LP no longer lists fixed bugs by default.
[12:26] <fabbione> Mithrandir: i had to make kiko an offer he couldn't refuse...
[12:26] <Mithrandir> fabbione: fix bug or concrete shoes? ;-)
[12:26] <Kamion> fabbione: for main?
[12:26] <Kinnison> infinity: thanks for clashing with my half-prepared g-p-m upload, but never mind
[12:27] <fabbione> Mithrandir: concrete shoes :)
[12:27] <fabbione> Kamion: hmm yes... that have to be main.. otherwise we will have regressions from breezy
[12:27] <infinity> Kinnison: I didn't know you were in the process of one.
[12:28] <Kinnison> infinity: aye, hence I asked fabbione to file the bug rather than upload a fix
[12:28] <Kinnison> :-)
[12:28] <Kinnison> infinity: s'okay, won't cause any hassle
[12:28] <Kamion> fabbione: accepted; please either seed it or make something depend on it (IIRC, we generally make xserver-xorg-driver-all depend on stuff)
[12:28] <fabbione> Kamion: yes.. in the next upload...
[12:31] <Diziet> fabbione: Well done for fixing that scroll back/forward bug at last.  Thank you very much.
[12:31] <infinity> Kamion / pitt: Okay, the only other one I want to touch for binary->source seed changes is db4.X, which currently doesn't seed a couple of bindings packages (neother of which pull in extra deps into main)
[12:32] <Kamion> that one's pitti's call AFAIAC, I don't mind the extra bindings
[12:32] <infinity> pitti: ^^^
[12:32] <pitti> yep, saw it; as I said, I'm fine with seeding -server-dev
[12:32] <pitti> s/seeding/putting it into main/
[12:32] <pitti> I just want to avoid explicitly seeding it
[12:32] <infinity> pitti: We've moved past that to BDB. :)
[12:33] <pitti> infinity: *sniff* :)
[12:34] <infinity> pitti: Any objections to db4.x bindings (tcl and java) moving to supported?
[12:34] <infinity> That's my last proposed seed change for the day. :)
[12:34] <pitti> infinity: I generally appreciate moving binaries to main whose source is in main already
[12:35] <pitti> infinity: since we need to provide security udpates for them anyway
[12:35] <infinity> I've just been looking forward to saying "our default db version is FOO", seeding the source, and not having to worry about -utils, -doc, etc. :)
[12:35] <infinity> pitti: Kay, cool.  I'm with you on that wavelength (as long as they don't pull in extra deps from universe, of course)
[12:35] <pitti> right, that should considerably clean up the seeds
[12:35] <fabbione> Diziet: assuming that's the right fix..
[12:37] <Diziet> So can someone explain to me what Pango is and why we want to use it ? :-)
[12:37] <tseng> Diziet: its a font renderer that can handle all sorts of strange i18n needs
[12:37] <mvo> Diziet: it's a text rendering engine and it is used by gtk
[12:37] <tseng> like right to left
[12:38] <Diziet> So the reason we need to use it is for i18n ?
[12:38] <Kamion> Kinnison: bug 35078 sheds more light on the disappearing gparted dialog; will you have time to look at it soon, or should I have a go?
[12:38] <Ubugtu> Malone bug 35078 in gparted ""Apply operations to harddisk" dialog is in background" [Normal,Unconfirmed]  http://launchpad.net/bugs/35078
[12:38] <mvo> Diziet: apparently. and because gtk is using it. why? do you want to get rid of it?
[12:38] <Diziet> (pango.org seems vaguely informative ...)
[12:38] <Kamion> also consistent rendering across all desktop applications, AIUI
[12:39] <Kinnison> Kamion: I have a patch I should have uploaded yesterday
[12:39] <Diziet> It seems that our firefox is slow according to many people, and setting MOZ_DISABLE_PANGO makes it faster.
[12:39] <Kinnison> Kamion: I'll get that done ASAP
[12:39] <pitti> infinity: does germinate figure that out automatically? (implicitly seed binaries from  main sources whose deps are all in main)?
[12:39] <Diziet> It could be that that disables use of Cairo.
[12:39] <Kamion> Kinnison: thanks
[12:39] <Kamion> pitti: no
[12:39] <pitti> so we just check with anastacia
[12:39] <Diziet> I haven't looked at the code yet to see what exactly setting that variable does.
[12:39] <Kamion> pitti: the extra seed lists extra binaries from main sources that aren't otherwise seeded, and if you use a %source seed (e.g. %postgresql) then all binaries from that source get seeded and any extra dependencies get pulled in
[12:40] <mvo> Diziet: I wouldn't be supprised if it would also break loads of international websites
[12:40] <Diziet> If there's some reason why we _have_ to use Pango and Cairo then I should just reject the report.
[12:40] <pitti> Kamion: alright; thanks for the heads-up
[12:40] <jdub> fabbione: yay xorg v4l :)
[12:41] <Mithrandir> Diziet: does it render CJVKK pages correctly without it?
[12:41] <Mithrandir> CJVK, even
[12:41] <Kamion> and Thai
[12:41] <Mithrandir> that too
[12:41] <Diziet> mith: I don't know.  I probably couldn't tell if it didn't.  If we have someone that could try it then that would be a quick way of dealing with the issue.
[12:41] <Kamion> oh, worth checking Hebrew and Arabic too for right-to-left-ness
[12:41] <Diziet> It's a shame it's slow.
[12:42] <Kinnison> can you have pango enabled and cairo disabled?
[12:42] <infinity> Alright, I'll check in all these changes tomorrow when I have all the seeds checked out and can merge between all the branches.
[12:42] <infinity> Thanks for the input guys.
[12:42] <Diziet> kinnison: I don't know.
[12:42] <Kinnison> Diziet: cairo is dog slow
[12:42] <Diziet> So I should try to have pango but not cairo ?
[12:42] <jsgotangco> sladen: ping?
[12:43] <Kinnison> It'll still link cairo because of gdk2.8 but if moz can get by without calling it, it should be faster
[12:43] <Diziet> There are some configuration options in this area, and I think yes, it can probably do it.
[12:43] <Diziet> I don't know how well-tested a code path it is.
[12:44] <infinity> I did notice that Tbird got a tiny bit slower with pango/cairo enabled, but it also seemed to get a bit prettier, so I'm of two minds.
[12:44] <Kinnison> cairo rendering is better than gdk
[12:45] <Kinnison> but it's slower because everything is a trapezoid
[12:45] <ogra> isnt cairo used for svg rendering ? we'll loose that without cairo i think
[12:45] <infinity> I'm inclined to just take the performance hit and wait for cairo to improve.
[12:46] <Mithrandir> there's nothing inherent in cairo which makes it slow, it's just that it's not optimised, AIUI.
[12:47] <Diziet> I suppose I could profile it.  But the thought of profiling Mozilla doesn't fill me with optimism and good cheer.
[12:47] <Kinnison> do we compile cairo with all of gcc4's funky vectorising turned on?
[12:47] <infinity> You mean the fnuky stuff that would render it unable to run on certain CPUs, or other funky stuff? :)
[12:48] <Kinnison> I imagine there're some optimisations which would break some cpus
[12:48] <Kinnison> we could have libcairo-686 for that
[12:48] <lifeless> Kinnison: prod
[12:48] <Kinnison> lifeless: looks fucked
[12:48] <Diziet> I think extra optimisations for faster more modern CPUs is rather missing the point.
[12:49] <lifeless> Kinnison: stdout and sterr races AFAICT
[12:49] <infinity> Kinnison: No need for two packages, we can just double up and dump one in /usr/lib/i686/cmov, but someone should see if it's worth the effort.
[12:50] <Kinnison> rjek is currently trying on amd64
[12:50] <infinity> Diziet: Well, I won't debate one way or the other for cairo, but it certainly makes sense for libssl (one of the few multi-target optimised libraries on the system)
[12:50] <sladen> jsgotangco: yo
[12:50] <sladen> jsgotangco: ask the question, rather than pinging :)
[12:50] <lifeless> Kinnison: still the question is - is it sufficient
[12:50] <jsgotangco> sladen: do you happen to know what might cause a toshiba not to reboot at all since Flight 3?
[12:50] <Kinnison> lifeless: fix the race
[12:51] <jsgotangco> sladen: modules not unloaded perhaps?
[12:51] <Kinnison> lifeless: making stdout and stderr present separately on the page, or else go down the same pipe would probably do
[12:51] <lifeless> Kinnison: later.
[12:51] <lifeless> Kinnison: I will tweak it a little now the hard part is done
[12:51] <Kinnison> lifeless: once it's more readable, you qualify for cashing in the token
[12:51] <lifeless> heh
[12:52] <sladen> cairo:  for when --OMG-faster makes crap libraries better
[12:54] <lifeless> also it would be a lot less sucky if make check_merge cooperated
[12:58] <Kinnison> infinity: it seems, asking dapper's gcc on amd64 to tree-vectorize cairo causes an ICE
[12:59] <jsgotangco> sladen: i've did reinstalls and upgrades and it still doesn't work
[12:59] <sladen> jsgotangco: the reboot methods have changed.
[01:00] <sladen> jsgotangco: /me *gone*
[01:03] <Mithrandir> seb128: are you working on xkb stuff today?
[01:04] <seb128> Mithrandir: I just built xkeyboard-config with that ralt patch and I was going to reboot to try it
[01:04] <seb128> Mithrandir: out of that, nothing plan on it no, I still have a lot of desktop bugs catchup to do
[01:04] <Mithrandir> seb128: 'k, please do.  I am writing a definition for my desktop keyboard, so we should merge at some point
[01:05] <seb128> brb, rebooting
[01:06] <lifeless> bug 35241 is _really_ hurting
[01:06] <Ubugtu> Malone bug 35241 in gnome-screensaver "screen blanks randomly whilst I am typing" [Major,Unconfirmed]  http://launchpad.net/bugs/35241
[01:07] <doko> Seveas: for #31231 you have still not the /sbin and /usr/sbin in your path?
[01:07] <Mithrandir> Ubugtu: kill and restart gss and you should be fine.
[01:07] <Mithrandir> s/Ubugtu/lifeless/
[01:09] <seb128> Mithrandir: the patch doesn't fix the issue, I'll comment for svu on the bug
[01:09] <Seveas> doko, can't tell now - I'm at work behind a fedora machine, will poke you later today
[01:09] <Mithrandir> seb128: thanks
[01:11] <seb128> hum
[01:11] <seb128> I forgot a part of the patch in fact, brb
[01:11] <doko> Seveas: thanks
[01:13] <ajmitch> hi doko
[01:13] <ajmitch> StevenK: why? :)
[01:13] <StevenK> I just managed to accidently upload Linda 0.3.19 to upload.u.c, not ftp-master.d.o
[01:14] <ajmitch> ah well
[01:15] <ajmitch> if it's a binary upload it should get rejected, and it was uploaded to unstable :)
[01:15] <lifeless> Mithrandir: it happens across login after login
[01:15] <lifeless> Mithrandir: are you saying I need to kill gss after every login ?
[01:16] <Mithrandir> lifeless: uh, weird.  I thought it was the same bug as I'm seeing, but then it's not.
[01:16] <lifeless> I've just killed and spawned it
[01:16] <lifeless> if it stops it for this session I will note that in the bug.
[01:18] <seb128> Mithrandir: grumpf, no, doesn't work
[01:22] <Mithrandir> seb128: should KPDL give you KP_Decimal or KP_Separator?
[01:24] <Mithrandir> (in a french locale)
[01:24] <Mithrandir> seb128: I'm wondering if bug 30211 is an X bug or a gnumeric bug, or maybe both.
[01:24] <Ubugtu> Malone bug 30211 in xkeyboard-config "in french locale, KPDL returns period instead of KP_SEPARATOR" [Normal,Unconfirmed]  http://launchpad.net/bugs/30211
[01:24] <seb128> KP_Decimal I would say
[01:24] <Mithrandir> Ubugtu is too bloody quick.  I swear it answered at the same time I pressed enter.
[01:25] <Mithrandir> seb128: I get KP_Separator with a norwegian layout, fwiw.
[01:26] <seb128> hum
[01:28] <Mithrandir> seb128: (and so does br, cs, de, dk, fi, gr, hu, mk, no, pl, ro, ru and se)  (at least)
[01:28] <seb128> the issue is that french use a ","
[01:28] <seb128> but the keyboards have a "." printed on the numeric pad key
[01:29] <seb128> cf /etc/X11/xkb/symbols/fr
[01:29] <Mithrandir> so either way, we make some people unhappy?
[01:29] <seb128> "    // French uses a comma as decimal separator, but keyboards are labeled with a period
[01:29] <seb128>     // Will take effect when KP_Decimal is mapped to the locale decimal separator
[01:29] <seb128>     key <KPDL>  { [       KP_Delete,          period,           KP_Delete,           KP_Decimal ]  };"
[01:29] <Mithrandir> yeah, I saw.
[01:32] <seb128> Mithrandir: you have a "," with your locale? Do you have it with every GTK app or only gnumeric?
[01:33] <Mithrandir> seb128: I don't have the bug, it's apparently only a bug in the french setup (we have , as decimal separator and get it when pressing KPDL)
[01:34] <seb128> you get it for every single GTK widget?
[01:34] <seb128> or that's a gnumeric feature?
[01:34] <Mithrandir> I don't think gnumeric is relevant here
[01:35] <Mithrandir> I get , everywhere, as I should
[01:35] <seb128> I get a "," when pressing KPDL in a spreasheet
[01:35] <seb128> and I get "." elsewhere
[01:35] <Mithrandir> and that's how it should be, or?
[01:36] <seb128> that's what the submitter is asking I think
[01:36] <seb128> the use of that key is controversial
[01:36] <seb128> let me comment on the bug
[01:36] <Mithrandir> thanks
[01:36] <seb128> np
[01:39] <infinity> mdz: How do you feel about a UVF exception for samba (3.0.21b to 3.0.21c), appears to be entirely bugfixes, passed from sid->etch without a word on debbugs.
[01:41] <infinity> mdz: Appears to fix some issues with NT4 clients.
[01:43] <lifeless> Kinnison: fixed, soon as the queue clears it'll come good
[01:46] <Kinnison> lifeless: prod me again when I can look
[01:46] <lifeless> whats wrong ?
[01:46] <Kinnison> Well, I get:
[01:46] <Kinnison> Win_GParted.cc:1383: error: no match for ternary operator?: in (((GParted::Win_GParted*)this)->GParted::Win_GParted::installer_mode != 0) ? *((GParted::Win_GParted*)this)->GParted::Win_GParted::plug : *(GParted::Win_GParted*)this
[01:47] <Kinnison> I should never have decided to make this neater
[01:47] <Kinnison> I could have uploaded already
[01:47] <Robot101> hnahrgahr
[01:48] <Kinnison> #define TRANSIENT_TARGET ((installer_mode)?(*(this ->plug)):(*this))
[01:49] <lifeless> WTF are you using fully qualified paths there
[01:49] <Kinnison> I am not
[01:49] <Kinnison> the compiler reports the error as such
[01:49] <lifeless> oh, I see complier barf
[01:49] <Kinnison> #define TRANSIENT_TARGET (*((installer_mode)?(this ->plug):(this)))
[01:49] <Kinnison> let's see if that helps
[01:50] <Kamion> Kinnison: heh, I tried to do exactly the same thing a while ago and ran into the same issue
[01:50] <Kinnison> Kamion: grah!
[01:50] <Kinnison> Kamion: I cleaned up so many if statements
[01:50] <Kinnison> and now it b0rken
[01:50] <Kamion> Kinnison: I gave up and added a transient_target member to Win_GParted I think
[01:50] <Kamion> Kinnison: which works fine
[01:51] <Kamion> (you realise it's not actually transience that's breaking here, but whether the window is brought to the front - but don't let me stop you cleaning up the transience too)
[01:51] <Kinnison> it's metacity being odd about the bring-to-front yes
[01:51] <Kinnison> but I wanted to tidy the transience too
[01:58] <Kinnison> I'm hoping that the raise issue is fixed by judicious application of an ->raise() just before showing the confirmation dialog
[01:58] <Kinnison> :-)
[01:59] <Kinnison> since it never pops under in my tests
[01:59] <Kinnison> bwuahaha I have tamed the compiler beast
[01:59] <Kinnison> #define TRANSIENT_TARGET (*((installer_mode)?((Gtk::Window*)(this ->plug)):((Gtk::Window*)this)))
[02:00] <Keybuk> Kinnison: does gpm, to your knowledge, deliberately save the session before the power goes out?
[02:00] <Kinnison> Keybuk: it sends a signal to the session manager to shutdown
[02:00] <Kinnison> Keybuk: the session manager saves the session
[02:00] <Keybuk> does it say to save in that?
[02:00] <Kinnison> I believe so
[02:00] <dholbach> Kinnison: you could try on #c++ or #gparted in irc.gimp.net, maybe they can make you happy in a different way :)
[02:00] <Keybuk> could it not, then?
[02:00] <Keybuk> because something saved my session when the battery ran flat
[02:00] <Keybuk> so now every time I login, I get those apps
[02:01] <Kinnison> Keybuk: is this related to 35961?
[02:01] <mjg59> Keybuk: What's your critical battery action set to?
[02:01] <Keybuk> ubuntu 35961
[02:01] <Keybuk>  Bug #35961 in gksu (Ubuntu): "-u option is being ignored"
[02:01] <Ubugtu> Malone bug 35961 in gksu "-u option is being ignored" [Normal,Unconfirmed]  http://launchpad.net/bugs/35961
[02:01] <Keybuk> ?
[02:02] <Keybuk> I don't think it's related to that, no
[02:02] <Keybuk> mjg59: Shutdown
[02:02] <mjg59> Keybuk: Right. Then that's unsurprising.
[02:02] <Keybuk> mjg59: no, it is surprising; because I have "Save Session at Logout" turned *off*
[02:02] <Keybuk> and there's no way to clear what it saved now
[02:02] <mjg59> Keybuk: Hm. Sounds like a session manager bug.
[02:03] <Keybuk> (other than removing files in ~/.*)
[02:03] <Kinnison> Keybuk: must have made a note wrong
[02:03] <Kinnison> one sec
[02:04] <Kinnison> Keybuk: bug 35691 even
[02:04] <Ubugtu> Malone bug 35691 in gnome-power-manager "Session is saved at critical battery shutdown" [Normal,Unconfirmed]  http://launchpad.net/bugs/35691
[02:04] <mjg59> If the session manager is doing two different things depending on how the shutdown is requested, something sounds broken
[02:04] <sabdfl> Keybuk, mjg59: could that explain why gnome terminal is launching itself when i log in?
[02:04] <Keybuk> sounds like exactly my bug
[02:04] <Keybuk> sabdfl: yes
[02:04] <mjg59> sabdfl: Probably, yes
[02:04] <Kinnison> I think g-p-m explicitly requests a session save
[02:04] <sabdfl> ah. Confirmed then :-)
[02:05] <Keybuk> I get 30 of the buggers, plus three copies of firefox (two of which just display dialogs) and four evinces
[02:05] <Keybuk> it's quite annoying
[02:05] <sabdfl> mjg59: another thing, do you have a documented policy on gpm shutdown/hibernate policy defaults?
[02:05] <mjg59> Given that we don't actually make any pretence to support session management, we should probably just rip all of it out
[02:05] <mjg59> sabdfl: We default to enabling hibernate, I believe
[02:06] <Keybuk> aye, if session management *worked*, I wouldn't mind
[02:06] <sabdfl> my laptop used to sleep when it was on battery and i closed the lid, but no longer
[02:06] <Lathiat> session management really tends to be more hassly than time saving :)
[02:06] <sabdfl> mjg59: +1 on stripping out session management
[02:06] <Keybuk> but all the windows are blank, and nothing like what it saved
[02:06] <sabdfl> leave it in main for the brave
[02:06] <Kinnison> sabdfl: can you dump that on that bug?
[02:06] <mjg59> sabdfl: Preferences/power management/Running on battery/Sleep on lid cloes?
[02:07] <sabdfl> Kinnison: the gpm hibernation, or the terminal issue?
[02:07] <Kinnison> sabdfl: bug 35691
[02:07] <Ubugtu> Malone bug 35691 in gnome-power-manager "Session is saved at critical battery shutdown" [Normal,Confirmed]  http://launchpad.net/bugs/35691
[02:07] <sabdfl> mjg59: i looked there, and it was set to blank screen until the battery was critical, then hibernate
[02:07] <sabdfl> i didn't change the pref
[02:08] <sabdfl> so i suspect our default prefs have moved
[02:08] <mjg59> sabdfl: It should be ok for breezy->current dapper upgrades, but may have been broken if you upgraded in the intervening period
[02:08] <mjg59> But "Sleep on lid close" was never a supported option, really
[02:09] <sabdfl> mjg59: ok, thanks, at least i know this is expected behaviour
[02:09] <mjg59> sabdfl: Tangentially, Intel Mac support is now only lacking installer support
[02:10] <sabdfl> mjg59: those installer slackers
[02:10] <mjg59> Yeah, it's disgraceful
[02:11] <mjg59> Anyway, Colin's going to take a look when he's got time
[02:11] <Seveas> mjg59, you know that that sort-of equals never ;)
[02:11] <mjg59> But it should be practical for dapper, even if we don't decide to ship it as the default iso
[02:12] <sabdfl> be wonderful to have it as a download option, even
[02:12] <Kinnison> Kamion: yay, this call to raise() causes a segv
[02:12] <Treenaks> mjg59: Could you tell me again what the 'interesting' values in my Radeon registers were? (bug 20283)
[02:12] <Ubugtu> Malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Normal,Unconfirmed]  http://launchpad.net/bugs/20283
[02:13] <Kinnison> Kamion: but in other news, it's started popping under
[02:13] <Kinnison> Kamion: so I actually have something to debug
[02:14] <mjg59> Treenaks: Anything starting CRTC, possibly also the ones starting FP
[02:14] <mjg59> (Would be my suspicion)
[02:15] <Treenaks> mjg59: ok, thanks
[02:18] <Kamion> mjg59: actually, I think I now have all the udeb support we need; I'm just looking at how to make the CD images work (see my question about blessing files)
[02:18] <Kinnison> Kamion: In fact, reading the code and the gtk docs, the transient stuff being correct should cause metacity to put the window on top of the gparted window
[02:18] <Kamion> Seveas: nah, this is actually high enough up my interest list to get done
[02:19] <Kinnison> Kamion: so I'm inclined to say this iz metacity boog
[02:19] <Kamion> it never used to pop under
[02:19] <mjg59> Kamion: Ah, cool
[02:19] <Kamion> it was only after your gparted change that that started, AFAI
[02:19] <Kamion> K
[02:20] <Mithrandir> sladen: any idea how to fix 35080?  (Thanks for the analysis, though)
[02:20] <Kamion> sabdfl: http://sourceforge.net/mailarchive/forum.php?thread_id=9984881&forum_id=47882 suggests and approach that might even be safe to use by default, although it has the disadvantage of using up a wodge more space on the CD (because we'd have to duplicate the kernel)
[02:21] <Kamion> the hybrid option is probably more space-efficient but isn't as safe
[02:27] <sabdfl> Kamion: i don't think we have the luxury of the space, unfortunately
[02:27] <mjg59> Kamion: We might as well give the hybrid option a shot
[02:27] <sabdfl> mactel is very much a nice-to-have for this round
[02:27] <sabdfl> mjg59: +1
[02:27] <sabdfl> in a pre-beta flight
[02:27] <Mithrandir> Riddell: it'd be nice if you could shave a bit off the size of the ppc live image.
[02:28] <sabdfl> get mdz's byu-in though
[02:28] <Kamion> sabdfl: yeah, my feeling too
[02:28] <Mithrandir> mjg59: if you can have it ready this week, I can chuck it in next week's flight.
[02:28] <mjg59> Their refusal to boot off ISO9660 is very tiresome
[02:28] <Kamion> though you never know, i386 has more free space on powerpc so it might actually be doable
[02:28] <Kamion> more free space than powerpc
[02:28] <mjg59> sabdfl: Oh, Linus emailed me asking for help on getting Linux on his new Mac
[02:29] <sabdfl> DOIT!
[02:29] <sabdfl> :-)
[02:29] <mjg59> I said it would be painful until the installer was sorted, but I'd let him know then
[02:29] <sabdfl> tell him to file a support request like everyone else... nah.
[02:30] <sabdfl> you guys are going to love the launchpad by dapper+1
[02:30] <sabdfl> promise
[02:30] <sabdfl> sprint is going very well
[02:31] <tseng> sabdfl: rock!
[02:31] <sabdfl> and the next ui phase will, i hope, address many of the issues we've had
[02:32] <tseng> i was a big fan of some of bradb's recent mockups
[02:32] <Riddell> Mithrandir: yes, I'll do that, hopefully today
[02:32] <Mithrandir> Riddell: thanks.
[02:32] <Mithrandir> Riddell: I'm aiming for a flight in a week, is that fine with you?
[02:32] <Mithrandir> ogra: ^^ and with you?
[02:32] <ogra> sure
[02:33] <Riddell> Mithrandir: yeah, that's good
[02:33] <ogra> gah, ENOSEB
[02:33] <Mithrandir> great
[02:34] <dholbach> ogra, Mithrandir: new gnome is due on april 10th, so next week should be fine
[02:34] <dholbach> 10th-12th
[02:34] <Mithrandir> dholbach: that's almost three weeks away so shouldn't be any kind of problem
[02:35] <dholbach> yeah
[02:35] <dholbach> Mithrandir: I was just referring to ogra's "gah, ENOSEB"
[02:35] <Mithrandir> dholbach: ah, ok.
[02:35] <ogra> dholbach, yes, that was about gdm
[02:35] <ogra> :)
[02:44] <Mithrandir> uh, what should I do about missing translation bugs?  Yes, sure, the translation is missing, because there is no translation.
[02:45] <Kinnison> Kamion: afaict metacity is ignoring the transience for the dialog and popping it under to stop it stealing focus
[02:45] <Kinnison> Kamion: because the plug it's a top level window
[02:45] <Kinnison> Kamion: I'm trying to verify this
[02:46] <Kinnison> Kamion: if I'm correct, then it very much iz metacity boog
[02:46] <maswan> So, for stupid dapper tricks, I have stored a bit over 5000 copiers of flight-4 dapper-install-amd64.iso on tape.
[02:48] <zul> heylo
[02:52] <MrFaber> hi all
[02:52] <MrFaber> Where can I make bug repots for dapper kernel?
[02:52] <MrFaber> I haven't found the 686 package in launchpad
[02:53] <dholbach> MrFaber: try linux-sourfce-2.6.15
[02:53] <dholbach> MrFaber: ummm linux-source-2.6.15
[02:54] <MrFaber> But it happens only with 686
[02:54] <MrFaber> not with 386
[02:54] <dholbach> you can mention that in the bug report
[02:55] <MrFaber> ok, I am going to try to manage it in launchpad if I am lucky :-D
[02:55] <dholbach> ok, cool :)
[02:56] <MrFaber> No packages matching 'linux-source-2.6.15' are published in Ubuntu.
[02:56] <MrFaber> I hate launchpad
[02:56] <MrFaber> there are only 12 kernels
[02:56] <MrFaber> there are only 2.6.12 kernels
[02:57] <dholbach> naaaaah, you don't hate it, how does this one look: http://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+filebug
[02:57] <MrFaber> How do you find it
[02:57] <maswan> Btw, is that place the correct place to submit unsupported hardware to, or is that a support request or whatever?
[02:58] <mjg59> maswan: launchpad is probably the right place
[02:58] <mjg59> Wishlist if you wouldn't expect it to work, normal if it ought to be supported but isn't
[02:58] <maswan> on linux-source-2.6.15?
[02:59] <mjg59> Yeah
[02:59] <dholbach> launchpad.net -> the ubuntu distribution -> enter 'linux-source' in source package text box, click on 2.6.15 in the list -> report a bug
[03:00] <dholbach> MrFaber: but to be honest, i know how the links are made up, so I 'assembled' the url on my own :)
[03:00] <MrFaber> ok :)
[03:00] <MrFaber> I used the search function
[03:03] <MrFaber> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/36014
[03:03] <Ubugtu> Malone bug 36014 in linux-source-2.6.15 "kernel 686 can't scale cpu frequency" [Normal,Unconfirmed]
[03:03] <MrFaber> please fix it :)
[03:03] <MrFaber> and I have another bug but I am not sure
[03:03] <MrFaber> And there is another bug in latest kernel. I can change some values like scaling_governor or sony_brightness with root but not with sudo. Same syntax but if I do this with sudo I got a permission denieded.
[03:03] <MrFaber> Wrong sudo permissions?
[03:03] <dholbach> check if it'S filed already, if not file it
[03:03] <dholbach> launchpad is the best place
[03:04] <MrFaber> launchpad is ingored :)
[03:04] <dholbach> it's not
[03:04] <MrFaber> my loop-aes but is still unconfirmed
[03:04] <MrFaber> after two monthes
[03:04] <jono> hey
[03:04] <MrFaber> and I have posted it here several times
[03:04] <MrFaber> after one month
[03:04] <MrFaber> hi joelbryan
[03:04] <MrFaber> sorry
[03:04] <MrFaber> hi jono
[03:04] <jono> hey MrFaber
[03:04] <Mithrandir> MrFaber: how are you trying to change the governor using sudo?
[03:05] <dholbach> there are 35000 bugs and there are 15 to 50 developers, depending how you count
[03:05] <Mithrandir> 'morning jono
[03:05] <jono> hey Mithrandir :)
[03:06] <jono> anyone have some odd problems with the keyboard settings tool where it changes the theme?
[03:06] <Treenaks> jono: that's when it crashes gnome-settings-daemon (which gets restarted immediately)
[03:07] <Treenaks> (afaik)(
[03:07] <jono> Treenaks, ahhh
[03:07] <Mithrandir> gnome-settings-daemon shouldn't crash, though.
[03:07] <Mithrandir> jono: when you select what keymap?
[03:07] <MrFaber> https://launchpad.net/distros/ubuntu/+source/sudo/+bug/36018
[03:07] <Ubugtu> Malone bug 36018 in sudo "can't access proc or sys with sudo" [Normal,Unconfirmed]
[03:08] <Mithrandir> MrFaber: do you know how sudo and you shell works?
[03:08] <Mithrandir> MrFaber: you need to do echo ondemand | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[03:08] <MrFaber> dholbach, I understand it but two monthes and I have posted an easy fix
[03:08] <MrFaber> for now I am useing loop-aes from debian sid
[03:08] <MrFaber> that works under dapper
[03:08] <jono> Mithrandir, yep
[03:09] <MrFaber> Mithrandir, in past I always used echo 6 > ...
[03:09] <MrFaber> with sudo and it works
[03:09] <jono> it only happened for my on a small Sony Vaio - I will dig into it tonight and try to reproduce it
[03:09] <Mithrandir> MrFaber: then you need to be root _first_
[03:09] <MrFaber> I thought sudo executes it as root?
[03:09] <Mithrandir> jono: please do; I'm attacking the xkb problems at the moment and it would be nice to get them all nailed.
[03:09] <jono> Mithrandir, no worries :)
[03:09] <MrFaber> Mithrandir, then remove the bug if I am wrong
[03:09] <Mithrandir> MrFaber: the redirection is done by your shell.
[03:09] <Kamion> MrFaber: > redirections are processed by the shell *before* sudo takes effect
[03:10] <Kamion> (it's always been that way)
[03:10] <MrFaber> but I am pretty sure that this works under Breezy
[03:10] <Kamion> I'm pretty sure it doesn't
[03:10] <Treenaks> (and can't really be changed easily)
[03:10] <MrFaber> ok, sorry
[03:10] <Mithrandir> MrFaber: no problem; I rejected the bug.
[03:10] <MrFaber> but changing brightness doesn't work with the new kernel
[03:10] <MrFaber> from today update
[03:11] <MrFaber> and with the kernel before it works with my keys
[03:11] <MrFaber> there is an sony_brightness acpi script
[03:11] <MrFaber> So I have no influence
[03:11] <MrFaber> But I haven't checked it in detail
[03:11] <MrFaber> So maybe it is only a temporary bug
[03:12] <MrFaber> thx btw
[03:12] <MrFaber> bbl
[03:24] <Kinnison> Kamion: It's definitely a metacity misbehaviour (in my opinion) -- currently filing upstream bugs to garner opinions of metacity's authors
[03:26] <jono> is there a boot time feature for fixing a grub partition ?
[03:26] <jono> sorry, a broken grub
[03:28] <mdke> i don't think so
[03:28] <mdke> i've heard it suggested as a good feature
[03:28] <zul> broken as in how?
[03:30] <Kamion> jono: not boot time, but use an install CD, boot into rescue mode, follow the menus, select your root partition, select "Reinstall GRUB boot loader"
[03:34] <trappist> has something been changed in karma on malone?  mine went from ~250 to ~50,000 in a couple of days, and I haven't been that great
[03:35] <Kamion> mjg59: I think adding an -hfs-bless-file option to mkisofs is going to be the cleanest answer here; doing that now
[03:36] <Kamion> Zomb: (I'll send you the patch once I've got it tested)
[03:37] <jono> Kamion, cool :)
[03:39] <mvo> Zomb: oh, I forgot that python-apt upload, sorry for this
[03:39] <mjg59> Kamion: Rock, thanks
[03:46] <mvo> Kamion: do you know if promotion work in breezy-updates? I would like to get python-vte from universe to main in it
[03:48] <jono> mjg59, are you busy tonight?
[03:48] <Kinnison> Kamion: Right, I think that popunder bug you listed earlier can be marked fix-released by the new metacity upload I just did
[03:48] <mjg59> jono: Probably not, though my throat is fucked
[03:48] <Kinnison> Kamion: do you agree?
[03:48] <jono> mjg59, so the rumours are true then :P
[03:48] <jono> mjg59, next show, want that belated interview?
[03:48] <mjg59> jono: Sounds good
[03:49] <jono> mjg59, cool, I guarentee it this time :)
[03:50] <Kamion> mvo: I haven't tried yet, let me just try it now and see what happens ...
[03:50] <mvo> Kamion: cool, thanks
[03:50] <Kamion> actually
[03:50] <Kamion> Kinnison: do pockets have independent overrides from their parent distrorelease?
[03:50] <Kinnison> Kamion: yes
[03:51] <Kinnison> Kamion: whether or not change-override obeys this is another question
[03:51] <Kinnison> Kamion: I'd do it --dry-run first to be sure
[03:51] <Kinnison> Kamion: and/or ask cprov to check
[03:52] <Kamion>   File "../../canonical/launchpad/database/distribution.py", line 244, in getRelease
[03:52] <Kamion> canonical.launchpad.interfaces.launchpad.NotFoundError: 'breezy-updates'
[03:52] <pitti> sivang: ping
[03:52] <Kamion> maybe it needs an option for pockets
[03:52] <Kamion> Kinnison: popunder> if it works for you, go ahead and close the bug
[03:52] <Kinnison> Kamion: looks like it should be using a different function yes :-)
[03:52] <Kamion> I'll file a bug
[03:52] <Kinnison> cool
[03:55] <Kamion> mvo: blocked by bug 36022
[03:55] <Ubugtu> Malone bug 36022 in launchpad-upload-and-queue "change-override can't handle pockets" [Normal,Unconfirmed]  http://launchpad.net/bugs/36022
[03:55] <Keybuk> . o O { what's in its pocketses? }
[03:57] <Kinnison> Kamion: closed the two related bugs in gparted
[03:57] <Kamion> ta
[03:58] <Kinnison> lunch and then back to g-p-m
[03:59] <Kinnison> Kamion: I assume the agreement we had about g-p-m being under the gnome UVF exception still stands? (I'm updating it to 2.14.0 + a few CVS patches)
[03:59] <Kamion> Kinnison: if g-p-m is still following GNOME release scheduling policies upstream, then yes
[04:01] <Kinnison> Kamion: I believe it is. However he never made a 2.14.0.news so I'll have to extract that one I've eaten lunch for you to take a quick peek at
[04:02] <Kamion> Kinnison: FWIW #29474 was probably originally because ubuntu-express did set_keep_above(True)
[04:02] <Kamion> I took that out a while back
[04:04] <Kamion> mjg59: I need to bless elilo.efi, right?
[04:04] <mjg59> Kamion: Yup
[04:05] <mjg59> Then elilo.conf just wants to point at the kernel and initrd, and have the usual boot options
[04:06] <Kamion> that part should be done, just uploading debian-installer with that now
[04:06] <Kamion> I have a suspicion that elilo-installer won't be quite right
[04:06] <Kamion> but we can deal with that once the CDs boot
[04:06] <mjg59> Sure
[04:11] <Kinnison> Kamion: Do you have any changes to the glade file not pushed to p.u.c?
[04:11] <Kinnison> Kamion: (espresso)
[04:12] <Kamion> Kinnison: nope
[04:12] <Kamion> I'm pushing anyway just in case
[04:12] <Kinnison> Kamion: okay, I'm taking out a minilock so I can make the UI changes for the N-of-M stage ui fix
[04:12] <Kamion> go for it
[04:12] <Kinnison> have you finished pushing?
[04:12] <Kamion> yes
[04:13] <Kinnison> cool
[04:13] <Kamion> (there was nothing to push as it happened)
[04:13] <Kinnison> hehe
[04:14] <fabbione> Keybuk: what did you break with udev/initramfs this time?
[04:14] <fabbione> Begin: Waiting for root file system... ...
[04:14] <fabbione> and it ends there..
[04:14] <Kamion> mjg59: do we still need the legacy-free option in elilo.conf?
[04:14] <fabbione> [    7.008720]   sdb: sdb1 sdb2 sdb3
[04:14] <fabbione> root is there...
[04:15] <Kamion> mjg59: and will chooser=textmenu work? the mactel-linux.com live CD has chooser=simple
[04:15] <Kinnison> Kamion: any preferences on where the step N-of-M goes?
[04:15] <Kinnison> Kamion: My current preference is bottom-left of the page
[04:15] <Kamion> Kinnison: bottom-left, yes
[04:16] <Kinnison> cool
[04:16] <Keybuk> fabbione: that's strange
[04:16] <Keybuk> it looks until /dev/sd* turns up
[04:16] <Keybuk> which clearly it isn't
[04:17] <Kinnison> Kamion: Do you know how to insert a vbox around an element?
[04:17] <Kamion> Kinnison: if the element's already in a box, use Insert Before, put a vbox there, cut/paste the element into the vbox, decrease the size of the containing box again
[04:18] <fabbione> Keybuk: it was.. and it's booting.. it just took a while.... weird.. i will give you console access to that box...
[04:18] <Kinnison> Kamion: and that won't eat containment, names etc?
[04:18] <Keybuk> fabbione: it just took a while
[04:18] <Keybuk> slow scsi warm-up then
[04:18] <Amaranth> whoa, when you run out of memory the kernel starts killing random things?
[04:18] <Kamion> Kinnison: it may eat packing
[04:18] <Kinnison> Kamion: umm, argh
[04:18] <Kamion> I think the rest should be ok
[04:18] <Keybuk> if you didn't touch it, and didn't hit ^C, and nothing
[04:18] <fabbione> Keybuk: i will check it again.. got distracted by the phone
[04:18] <Keybuk> your hardware needed a run-up
[04:18] <Kamion> packing is small enough to remember
[04:18] <fabbione> Keybuk: no nothing..
[04:18] <Keybuk> ok
[04:18] <Keybuk> this the new shiny?
[04:18] <Kagou> hi
[04:18] <JaneW> Yes, Dennis Daniels has done loads
[04:18] <Kinnison> Kamion: Erm, I need to reparent the steps widget
[04:18] <JaneW> ECHAN
[04:19] <Kamion> Kinnison: it'll only eat the packing of steps itself, not stuff inside it
[04:19] <Kinnison> Kamion: aah right
[04:19] <Kinnison> okay
[04:19] <Kinnison> thanks
[04:19] <Kamion> (at worst)
[04:19] <Kinnison> cool
[04:19] <Keybuk> fabbione: once it's said "Waiting for root filesystem" it's literally just in a while/sleep loop waiting for the hardware to get out of bed and brush its teeth
[04:19] <fabbione> Keybuk: ok..
[04:20] <Keybuk> that doesn't rule out BenC-bugs of course ;)
[04:20] <fabbione> no.. it was working with -19 and old udev :)
[04:20] <fabbione> but i will check it again
[04:20] <Keybuk> nothing's particularly changed in the scsi case
[04:20] <fabbione> ncpus probed    : 24
[04:20] <fabbione> ncpus active    : 24
[04:21] <Kamion> mjg59: hmm, how about automatically turning on ia32_gconf.legacy_free_boot in apple_fudge()? would that be crack?
[04:23] <Kamion> (and #ifdef CONFIG_ia32)
[04:23] <Keybuk> fabbione: I'm assuming you have plain root=/dev/sd* and not lvm, dmraid, evms, or anything I might not have heard of?
[04:24] <fabbione> Keybuk: hmmm i don't remember.. let me check..
[04:25] <fabbione> Keybuk: LVM on pure scsi..
[04:25] <fabbione> Keybuk: again don't worry.. i will look at it again..
[04:25] <mjg59> Kamion: Would probably be reasonable
[04:25] <fabbione> if i can't figure it out, i will give you console access
[04:25] <Keybuk> ok
[04:25] <Keybuk> that would be ideal, thankyou
[04:25] <Kamion> mjg59: shall I do that and upload then? not that I can test, but it seems easy enough ...
[04:26] <fabbione> i have been distracted and lost count of seconds..
[04:26] <Kamion> (famous last words)
[04:26] <mjg59> Kamion: Sure
[04:26] <Keybuk> evms, lvm and md are massively undertested in dapper still
[04:26] <Keybuk> I'm not even sure they work :(
[04:26] <hunger> Keybuk: They work-for-me(TM)
[04:27] <mjg59> Kamion: (As long as you're sure CONFIG_ia32 is defined there)
[04:27] <Keybuk> hunger: do they work after today's update
[04:27] <hunger> Keybuk: I am using lvm on all my boxes (4 of them, all on dapper).
[04:27] <hunger> Keybuk: LVM on MB on one box (dapper as well).
[04:27] <fabbione> Keybuk: yes they do work...
[04:28] <fabbione> Keybuk: i use them a lot as test cases
[04:28] <Keybuk> ok
[04:28] <hunger> Keybuk: Do I need to reboot to get updates activated?
[04:28] <Keybuk> hunger: yes
[04:28] <hunger> Keybuk: I have all boxes updated, but I did not yet reboot.
[04:28] <Keybuk> you need to reboot to test the "mounting of root filesystem at boot time" :)
[04:28] <hunger> Keybuk: Oh, I did not get that;-)
[04:29] <hunger> Keybuk: It did work this morning after the -19- kernel upgrade if that helps.
[04:29] <Keybuk> the udev update is what I was interested in
[04:29] <Keybuk> to ubuntu20
[04:30] <hunger> Keybuk: Hmmm.... donno whether that was installed at that time. Probably not.
[04:30] <Kinnison> Kamion: can espresso be started from within the dev tree, for testing the UI appearance?
[04:30] <hunger> Keybuk: I'll reboot asap (after finishing install of this crap).
[04:31] <hunger> Keybuk: BBL.
[04:32] <Kamion> mjg59: should be, Make.defaults sticks it in CPPFLAGS
[04:32] <mjg59> Kamion: Excellent
[04:32] <Kamion> Kinnison: err, possibly but I'm not sure
[04:33] <Kamion> you can always try sudo ./installer and fix whatever breaks ...
[04:33] <Surak> Hello.
[04:33] <Kinnison> Kamion: heh
[04:34] <Surak> people, the xserver-xorg src package has some packages marked to not be created in some architectures. (for instance, xserver-xorg-via-driver in amd64 and powerpc).
[04:34] <fabbione> Surak: yes.. that is correct..
[04:35] <Surak> fabbione: can I request some help from you?
[04:35] <fabbione> Surak: help -> #ubuntu
[04:36] <Surak> fabbione: I'm intended to provide a backport for it. The help is in generating the package.
[04:36] <fabbione> Surak: you can't backport it
[04:36] <hunger> Keybuk: Does *NOT* work.
[04:36] <Keybuk> hunger: waits three minutes?
[04:36] <hunger> Keybuk: With the normal kernel I get no output at all.
[04:37] <Keybuk> "no output at all" ?
[04:37] <Keybuk> black screen?
[04:37] <hunger> Keybuk: With the "safe mode" kernel it writes something about "waiting for root" or similar.
[04:37] <Keybuk> ok
[04:37] <hunger> Keybuk: blank after grub is done with its text.
[04:37] <Surak> fabbione: why? There are patches on via driver on Xorg's cvs. Not intended to backport the whole 7.0 driver, but only those patches required for some hardware to work.
[04:37] <Keybuk> and then if you wait three minutes, it carries on?
[04:37] <hunger> Keybuk: I have not waited 3min yet.
[04:38] <Kinnison> Kamion: I'm just rsyncing the liveCD down for testing
[04:38] <hunger> Keybuk: Lets just sit around and wait a bit:-)
[04:38] <fabbione> Surak: if you want to backport patches is one thing. doing a backport means pushing the via driver from a release to another
[04:39] <hunger> Keybuk: It continued to boot now...
[04:39] <hunger> Keybuk: 3min seems to be pretty close to what I am seenig;-)
[04:39] <Keybuk> okies
[04:39] <Keybuk> http://people.ubuntu.com/~scott/udev
[04:39] <fabbione> Keybuk: it did wait exactly 3 minutes and then kept going.. even if root was there...
[04:39] <Keybuk> ^ build and install that, then reboot again
[04:39] <Surak> fabbione: specifically, the build-tree/xc/programs/Xserver/hw/xfree86/drivers/via/via_mode.c needs to be patched. But yet I don't know how to change the debian structure so I can enable some package to be created in some architecture.
[04:39] <fabbione> Keybuk: gonna setup access for you