[00:00] <wgrant> ogra: Interesting...
[00:00] <wgrant> ogra: Default theme?
[00:00] <ogra> superm1, yes, its a bug in gnome-session not bringing up the other dislog
[00:00] <superm1> wgrant, i'm not sure what that actually means when it is calling that function
[00:00] <ogra> *dialog
[00:00] <Ng> slangasek: ah
[00:00] <wgrant> superm1: I'll check the source.
[00:00] <ogra> wgrant, nope, still the gnome theme, lets see, i'll change it
[00:01] <ogra> wgrant, well, human has the right icon as well atm (battery with only about 80% green)
[00:01]  * ogra plugs in AC
[00:01]  * wgrant waits for g-p-m to get rid of its broken brightness dialog so he can read ogra's second-last line.
[00:01] <superm1> i understand theres this big push for multiuserness and fast user switching, but don't most people associate power button with turning something on and off still?
[00:01] <wgrant> There we go.
[00:02] <wgrant> superm1: One would think so.
[00:03] <wgrant>         XRRChangeOutputProperty (brightness->priv->dpy, output, brightness->priv->backlight, XA_INTEGER, 32,
[00:03] <ogra> ok, i got a popup telling me about the state change, my brightness went to 100% as well but the icon stays at 80% charged battery ... no power plug or anything
[00:03] <wgrant>                                  PropModeReplace, (unsigned char *) &value, 1);
[00:03] <wgrant> So it seems that XRandR does actually do backlight. That I didn't know.
[00:03] <wgrant> ogra: What if you make the icon disappear and reappear?
[00:04] <ogra> no change
[00:04] <ogra> same icon
[00:05] <superm1> randr shouldn't be doing backlight - the interface on different laptops is not necessarily a software interface
[00:06] <ogra> wgrant, what i dont get is that it works flawless on a freshly installed ubuntu-mobile image and even in the usb live session on that image
[00:06] <wgrant> ogra: Run g-p-m with --verbose --no-daemon, and watch for where it reassigns the icon (you'll get 'Trying SOMETHING icon', then 'got-filename: something' then '** EMIT: icon changed: something'
[00:06] <ogra> i get a fresh icon if i kill it
[00:07] <wgrant> superm1: Well, g-p-m thinks it can.
[00:07] <wgrant> ogra: Right, but try to get it into a state where it should switch the icon while you've got verbosity up.
[00:07] <slangasek> well, that appears to be the second time in 15 minutes I've done something based on comments in this channel that has kicked me out of my computer
[00:07] <slangasek> since when does choosing 'log out' immediately log you out with no warning?
[00:07] <wgrant> slangasek: Hahaha.
[00:07] <wgrant> Since fusa became stupid.
[00:07] <TheMuso> Ouch.,
[00:08] <slangasek> tedg: is this intended behavior?  When I choose 'Log Out' from the system menu, I get a dialog :P
[00:08] <slangasek> also, when is someone in GNOME going to care about session saving? :P
[00:08] <wgrant> ogra: You can get it to recalculate the icon by changing the icon policy.
[00:09] <slangasek> hmm, didn't fusa also have icons before?
[00:09] <wgrant> It did.
[00:09] <wgrant> It had a presence state selector.
[00:10] <ogra> oh, intresting
[00:10] <ogra>  - no devices critical, so no icon will be displayed.
[00:10] <ogra>  - emitting value-changed : '/apps/gnome-power-manager/ui/icon_policy'
[00:10] <ogra>  - key : /apps/gnome-power-manager/ui/icon_policy
[00:10] <ogra>  - unknown key /apps/gnome-power-manager/ui/icon_policy
[00:10] <ogra> unknown key ???
[00:10] <wgrant> Um.
[00:10] <slangasek> wgrant: but no icons for "Log out", "Restart", "Shut down"?
[00:11] <wgrant> slangasek: I don't recall it having them... but the applet is stupid so I got rid of it for a while.
[00:11] <ogra> fusa is the evil
[00:11] <slangasek> hmm
[00:11] <wgrant> ogra: What did you change it from/to?
[00:11] <ogra> wgrant, from "never" to "always"
[00:12] <wgrant> ARGH WTF
[00:12] <ogra> or critical to always rather
[00:12] <wgrant> g-p-m's preferences now deny I have a battery.
[00:12] <slangasek> well, I'm not terribly impressed with fusa; for starters, the design only looks good if it's to the far right on the panel, and I don't want it there
[00:12] <ogra> its the evil
[00:13]  * ogra massively hates fusa ... but thats because he develops ltsp where it breaks the world
[00:13] <slangasek> and at this point, there's duplication between the menus and the applet... dunno if that's something that should be corrected?
[00:14] <wgrant> ogra: Did you get any '** EMIT: icon-changed'?
[00:14] <ogra> yes, remove fusa from the default install :)
[00:14] <ogra> wgrant,  - ** EMIT: icon-changed: none
[00:14] <slangasek> ogra: has this plan been run past the desktop team? :-P
[00:14] <wgrant> ogra: But the icon stays there?
[00:15] <ogra> slangasek, i tried it in gutsy but couldnt convince them
[00:15] <ogra> wgrant, right
[00:16] <RAOF> Is it possible/planned for the shiny new fluendo-codec-package(s) offered on the Canonical store to be better integrated into the codec-install dialog?  By that, I mean only showing the option when a plugin from that package will actually play the offending file.
[00:16] <ogra> slangasek, i was told it would be a good thing that it shows you who you are
[00:16] <ogra> as if i wouldnt know that :P
[00:17] <ogra> and in real multiuser setups like ltsp its just broken
[00:20] <slangasek> hmm? what's broken about it?
[00:20] <bryce> I updated to latest code since about a week ago; now no sound works
[00:20] <slangasek> my only problems with it are cosmetic and UI-related, I think
[00:20] <bryce> although it did play the login sound...
[00:21] <slangasek> bryce: kill pulseaudio and restart it, I bet you have the same bug I do
[00:21] <ogra> slangasek, http://lists.freedesktop.org/archives/hal/2008-October/012312.html
[00:21] <ogra> that might help the file handle issue
[00:22] <slangasek> ogra: I already have a fix for the fd leak; that patch is unrelated
[00:22] <ogra> ah, k
[00:22] <wgrant> ogra: http://pastebin.com/m221a326f is what I get when I change the policy from charging to critical.
[00:23] <slangasek> the only thing I haven't proven is whether the fd leak is connected to the fclose() crash
[00:23] <bryce> slangasek: ok alsamixer liked that better... firefox is unhappy... restarting
[00:23] <slangasek> bryce: restarting what?
[00:23] <bryce> slangasek: restarting firefox
[00:23] <slangasek> ok
[00:24] <bryce> cool, ok all happy now
[00:24] <superm1> slangasek, yeah i'm seeing that same thing too but i have to remove .pulse* every time it happens
[00:24] <slangasek> TheMuso: ^^ bryce is another candidate for testing any fixes you have :)
[00:24] <superm1> is there a bug about it yet?
[00:24] <slangasek> superm1: I don't know; TheMuso pointed me earlier to a report that he thought was related
[00:24] <ogra> wgrant, i dont get - ** EMIT: icon-changed: none
[00:25] <ogra>  - ** EMIT: icon-changed: gpm-primary-080 is what i have
[00:25] <wgrant> ogra: Even if the policy is critica
[00:25] <wgrant> +l?
[00:25] <ogra> unplugging AC gets me:
[00:25] <ogra>  - Trying CHARGING icon: primary, ups
[00:25] <ogra> TI:01:25:30	TH:0x97ca640	FI:gpm-cell-unit.c	FN:gpm_cell_unit_get_icon,211
[00:25] <ogra> TI:01:25:30	TH:0x97ca640	FI:gpm-engine.c	FN:gpm_engine_recalculate_state_icon,590
[00:25] <ogra> yes, even then
[00:25] <TheMuso> Don't you just love it when you can't reproduce these problems locally at all? :)
[00:25] <bryce> fwiw, the sound volume in youtube seems a heck of a lot better now
[00:26] <TheMuso> I'll get intrepid set up on one more box with another different sound card and see if that gives me the same issues.
[00:26] <ogra> wgrant, after a while i get:
[00:26] <ogra>  - Trying CHARGING icon: primary, ups
[00:26] <wgrant> ogra: Can you pastebin a trace of just switching from charging to critical?
[00:26] <ogra> TI:01:26:10	TH:0x97ca640	FI:gpm-cell-unit.c	FN:gpm_cell_unit_get_icon,211
[00:26] <ogra> TI:01:26:10	TH:0x97ca640	FI:gpm-engine.c	FN:gpm_engine_recalculate_state_icon,590
[00:26] <bryce> TheMuso: Indeed
[00:26] <ogra> but no actual change
[00:26] <superm1> bryce, are you seeing it on the same hardware that I sent you w/ the AMD 3650 graphics?
[00:27] <bryce> superm1: let me check
[00:27] <superm1> okay so you saw it on something different then
[00:27] <superm1> initially at least
[00:27] <superm1> that's where i was seeing it
[00:27] <ogra> wgrant, oh i get the  EMIT: icon-changed: none, i just missed it before
[00:28] <wgrant> ogra: Do you get anything relevant after that?
[00:28] <ogra> http://paste.ubuntu.com/53009/
[00:28] <wgrant> There's a fairly deep stack after that.
[00:28] <ogra> thats gnome-power-manager --verbose --no-daemon|grep icon for changing from always to critical
[00:29] <wgrant> ogra: OK. So we can be fairly sure it executes                 gpm_tray_icon_show (icon, FALSE);
[00:29] <bryce> superm1: nope, that laptop's sound is working fine with today's updates
[00:29] <wgrant> WHich does this:
[00:29] <wgrant>         g_return_if_fail (GPM_IS_TRAY_ICON (icon));
[00:29] <wgrant>         gtk_status_icon_set_visible (GTK_STATUS_ICON (icon->priv->status_icon), enabled);
[00:30] <bryce> fwiw, this sound issue was on the dell inspiron 1420
[00:30] <wgrant> ogra: I really can't see how it can go wrong once you get no icon will be displayed
[00:30] <ogra> wgrant, well, restarting gpm gets me the right icon, unplugging AC gets me a battery icon, replugging AC *doesnt* get me the AC icon back
[00:30] <ogra> thats what i see here
[00:31] <wgrant> ogra: Does the icon end up going away in the events shown in that log?
[00:31] <ogra> yes
[00:31] <wgrant> Hmmm.
[00:31] <ogra> but it always returns the battery icon, never the AC one
[00:31] <wgrant> OK, can I see the log for where it should give you an AC one?
[00:32] <ogra> http://paste.ubuntu.com/53010/
[00:33] <ogra> seems its stuck at gpm-primary-100
[00:33] <ogra> while it should be gpm-primary-100-charging
[00:37] <ogra> and here is a AC unplug/replug http://paste.ubuntu.com/53012/
[00:37] <ogra> seem like gpm_engine_recalculate_state_icon is the prob
[00:40] <wgrant> ogra: It must be escaping from there at 438.
[00:40] <wgrant> Because we end up with an icon, but we don't see "Trying PRESENT icon".
[00:41] <wgrant> Which might mean that gpm_cell_unit_get_icon is the problem.
[00:44] <ogra> hmm, the last changelog entry refers to bug 274681
[00:44] <wgrant> ogra: The tooltip does say that it's charging, right?
[00:44] <ogra> yes, tooltips and popups are fine
[00:45] <wgrant> And you are fairly up-to-date?
[00:45] <ogra> yep
[00:47] <ogra> oh, wait
[00:47] <ogra> i'm missing exactly that update
[00:47]  * ogra updates
[00:48] <ogra> bah
[00:48] <ogra> fixes it
[00:48] <ogra> yes, all fine, reproducable
[00:48] <ogra> even the delays are gone, its updating much faster
[00:49] <ogra> sigh
[00:49] <wgrant> Heh.
[00:49] <wgrant> Interesting.
[00:49] <wgrant> It didn't look quite like that bug.
[00:49] <ogra> do you have ubuntu3 installed?
[00:49] <ogra> but it was a patch to gpm-cell-array.c
[00:49] <wgrant> I do.
[00:49] <wgrant> But I don't have this same bug.
[00:49] <ogra> or rather it dropped one
[02:20] <Socceroos> Is Ubuntu 8.10 Beta still on schedule to be released soon?
[02:20]  * slangasek mumbles at the mangling of bug #273907's bug state
[02:20] <slangasek> Socceroos: "soon", yes, but releases don't happen on Australian time :)
[02:22] <Socceroos> ah ok, I was just looking at the Launchpad release schedule and it recons it was supposed to be released an hour ago. Is that because Launchpad is telling me the release time in my own timezone?
[02:23] <slangasek> mm. which page are you looking at?
[02:23] <slangasek> one hour ago was midnight UTC; but we don't target the releases that exactly
[02:24] <Socceroos> https://launchpad.net/ubuntu/+milestone/ubuntu-8.10-beta
[02:25] <Socceroos> ah, ok. I was just getting over excited to read all about it =P ....i can wait :)
[03:07] <slangasek> ScottK: are there any key features in Kubuntu 8.10 that you think should be highlighted in https://wiki.ubuntu.com/IntrepidIbex/BetaAnnouncement ?
[03:08] <slangasek> superm1|away, laga: ^^ same question, mythbuntu :)
[03:08] <ScottK> slangasek: The big one is the switch to KDE4.
[03:08] <slangasek> right, that's covered
[03:09] <ScottK> slangasek: OK.  There's been some discussion on kubuntu-devel ML about it.  https://wiki.kubuntu.org/IntrepidIbex/Beta/Kubuntu is the current state of the Kubuntu specific writing.  Dunno if you want to borrow anything from there.
[03:11] <slangasek> persia, TheMuso: what should https://wiki.ubuntu.com/IntrepidIbex/BetaAnnouncement say about UbuntuStudio?  Is there any sort of webpage that we should be linking to?
[03:11] <bryce> kees: confirmed fix to -evdev for that tty security issue is uploaded.  Maybe too late for beta though.
[03:12] <slangasek> ahem, slightly
[03:12] <bryce> slangasek: dunno if it's worth mentioning, but the failsafeX stuff is all majorly reworked
[03:12] <ScottK> slangasek: You did some work on the kphotoalbum build-dep on libkexif in Bug 269916.  Did you want to finish and do the upload or would you rather I take care of it?
[03:13] <TheMuso> slangasek: Afaik we don't really have anything in particular in terms of a webpage, however, the one thing that has changed for this release is no realtime kernel, and we are encouraging people with low latency requirements to stick with hardy. I can have a look at whats there for studio and make changes appropriately if you like.
[03:13] <cody-somerville> I imagine I need to write something up for Xubuntu
[03:13] <nxvl> were are the bugs milestoned for beta?
[03:13] <TheMuso> As it is, I am not sure if we should announce a regression like that, but just encourage people to stick with hardy if they have specific performance requirements.
[03:13] <slangasek> ScottK: please do so, I was just trying to establish whether bringing back libkexif was the right course of action
[03:14] <ScottK> slangasek: OK.  Will do.  Thanks for doing it.
[03:14] <slangasek> TheMuso: currently there's a big "TBD" for UbuntuStudio.  I'm not sure if we want this announcement to say things like "don't use this variant"... :)
[03:15] <slangasek> bryce: I'm not thinking that belongs in the top three, but maybe you can add something to https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview ?
[03:15] <ScottK> slangasek: I think though for the RT needing people it's better to warn them up front.
[03:15] <TheMuso> slangasek: I agree, but persia or Cory might have somethign else to say. Unfortunately it seems that _MMA_ is not in here. I'll poke him.
[03:15] <slangasek> ScottK: but probably in the release notes, not in the beta announcement?
[03:15] <slangasek> cody-somerville: I emailed xubuntu-devel, perhaps my mail is still stuck in the moderation queue :P
[03:15] <ScottK> slangasek: Do you want those people testing the beta?
[03:16] <slangasek> ScottK: I don't think the beta announcement is the right place to warn them off; we have the web page that tells people about errata, and we have the release notes for identifying issues that people need to pay attention to when upgrading
[03:17] <slangasek> (though the latter isn't live yet)
[03:18] <ScottK> OK.  Your call.  I know we say these aren't suitable for general users, but I think it's reasonable to say "It's particularly not suitable for ...".
[03:19] <cody-somerville> slangasek, there she goes.
[03:22] <tedg> slangasek: Yes, the reason you need a dialog is to choose, but we've already provided the choices on the menu.
[03:23] <slangasek> tedg: well, I guess I would expect a confirmation dialog
[03:23] <tedg> slangasek: The icons not being there is more of an aesthetic thing.  Trying to clean up the menus in general, use icons for accent instead of "everywhere someone could think to put one" which seems to be the current philosophy :)
[03:23] <slangasek> hmm
[03:23] <slangasek> is this a new UI principle being followed?
[03:24] <slangasek> because I learn the icons associated with actions and find that preferable to having to read the text
[03:24] <tedg> slangasek: The start of one.  Not fully formed yet.
[03:24] <tedg> Yes, but the problem there is when you have lots of icons, you really end up reading the text anyway.
[03:24] <tedg> Because, for the most part, the icons are arbitrary.
[03:25] <wgrant> I agree with not having icons for all items, but I think that many is suited to having them.
[03:25] <tedg> I personally thing we've probably gone a little bit to the sparse side, but definitely it was cluttered before.
[03:25] <slangasek> for application menus, sure; for system menus, I'm not convinced
[03:25] <slangasek> tedg: ok, at least we agree on that then :)
[03:25] <wgrant> s/many/menu/. I suck.
[03:25] <ScottK> tedg: You might want to explain this principle to some LP developers too.
[03:25] <tedg> Just change your default font to wingdings, then you'll have all the icons you could want ;)
[03:25] <slangasek> I don't think that's compatible with my definition of "icon" :)
[03:26] <tedg> Sadly, probably more descriptive/intuitive than many of them...
[03:27] <tedg> ScottK: Well, the goal is try to use some of the same design philosophies in everything, so hopefully it'll help Launchpad also.
[03:27]  * slangasek flips through menus and blinks
[03:28] <slangasek> why does "Bazaar Preferences" belong in System->Preferences?
[03:28] <ScottK> tedg: Right, I'm just thinking they've recently taken a major step in the direction of icon mania, and so perhaps they'd benifit from the discussion.
[03:29] <tedg> slangasek: No other place to put it?
[03:30] <slangasek> tedg: if there's no other place to put it, then why does it need to be there at all?
[03:30] <slangasek> if I'm doing everything else with bzr from the commandline, why do I need to be able to /configure/ bzr from the menu?
[03:30] <tedg> ScottK: My favorite launchpad thing is the tiny icons, in general, you can't express anything in under 200 pixels :)
[03:31] <StevenK> tedg: The team membership icons?
[03:31] <tedg> slangasek: Well, you could use Olive.  But, I would say in that case probably calling it from Edit->Bazaar Preferences in Olive is sufficient.
[03:31] <tedg> StevenK: Yeah, and I think some others.
[03:32] <tedg> They're very cryptic.
[03:32] <slangasek> tedg: precisely - since I don't have that installed, it doesn't make any sense to have it in my System menu...
[03:32] <slangasek> now if I can figure out which package to blame, I'll file a bug :)
[03:48] <nxvl> slangasek: is there any chance for new revision (as in upstream svn revisions) in main now?
[03:48] <Hobbsee> nxvl: right now, while ther'es a beta happening?  no.
[03:49] <nxvl> ugh
[03:49] <nxvl> network-manager-openvpn is FTBFS because of unment deps
[03:49] <nxvl> and that unment dep is network manager
[03:49] <slangasek> well, it can stay FTBFS until after beta
[03:50] <nxvl> slangasek: i mean from now until release
[03:50] <slangasek> though that seems to imply that someone accepted half of the batch of nm uploads :)
[03:50] <nxvl> slangasek: not now as in right now
[03:50] <slangasek> nxvl: NM 0.7 is going to be allowed in immediately after beta
[03:50] <nxvl> \o/
[03:50] <slangasek> it's already in the queue and has been discussed
[03:50] <nxvl> 0.7~~svn20080928 is needed
[03:52] <nxvl> were is the queue btw
[03:52] <Hobbsee> it's non-public, last i knew.
[03:52] <Hobbsee> well, not visible to !archive admins
[03:52] <StevenK> Hobbsee, slangasek: Can one of you pretty please approve Kourou 0.4 in unapproved?
[03:53] <Hobbsee> and used to be visible at http://people.ubuntu.com/~ubuntu-archive/queue/ but apparently no longer
[03:53] <Hobbsee> s/visible/mirrored/
[03:53] <slangasek> StevenK: done
[03:53] <Hobbsee> bah
[03:53] <StevenK> slangasek: Thanks
[03:53] <slangasek> wait
[03:53]  * Hobbsee waits for launchpad, again.
[03:53] <slangasek> no, I said that blindly after typing the command
[03:53] <slangasek> StevenK: not in the queue :P
[03:53] <Hobbsee> oh, there we are.  it only took 15 seconds to load that.
[03:54] <StevenK> Hm.
[03:54] <StevenK> I uploaded it
[03:54] <slangasek> did you get an acknowledgement email back?
[03:54] <StevenK> Not yet, which makes me suspect I'll get it in 30 seconds
[03:54] <nxvl> need to run, see you in the morning
[03:54] <slangasek> StevenK: let us know when you've gotten an ack email; until then it's still processing
[03:55] <cody-somerville> slangasek, when are you planning on releasing? (ie. # of hours)
[03:55] <slangasek> cody-somerville: it'll be > 12:00 London time; how much later depends on how things fall into place
[03:56] <StevenK> Sigh. LP, I'd like the new Kourou in this publisher run. Looks like I lose.
[04:00] <Hobbsee> slangasek: beat you :)
[04:00] <slangasek> heh :)
[04:05] <Anon9050> Does anyone out there know how to edit the home directory. I want to change the name of said directory !
[04:06] <cody-somerville> #ubuntu for support please
[04:07] <nixternal> change your nick :P
[04:07] <nixternal> err, login name
[04:08] <Anon9050> does not work !!
[05:45] <superm1> slangasek, there's some sort of bug that crept up related to the mythbuntu-backend-master task that is preventing the alternate cd from working right.  it's trying to pull apache2-mpm-prefork & apache2-mpm-worker from the task.  i'm a bit confused by why though.
[05:46] <superm1> http://pastebin.com/f557ba44f
[05:50] <StevenK> TheMuso: Nice work on mplayer, it built everywhere.
[05:52] <TheMuso> StevenK: I know. :)
[06:19] <cody-somerville> slangasek, ping
[06:19] <slangasek> superm1: hrm, I don't seem to be able to install the mythbuntu-backend-master task with 'apt-get install mythbuntu-backend-master^'; hints on reproducing this?
[06:19] <slangasek> cody-somerville: pong
[06:20] <cody-somerville> slangasek, can you push ubuntu-restricted-extras through?
[06:20] <slangasek> cody-somerville: and then what?
[06:20] <slangasek> is that on the CDs?
[06:20] <cody-somerville> I hope not :P
[06:20] <cody-somerville> (no)
[06:21]  * StevenK kicks Sam, and gtklookat
[06:21] <slangasek> cody-somerville: ah, multiverse; yah, pushing
[06:22] <StevenK> slangasek: With your Debian hat on, have you heard anything about gtklookat?
[06:22] <slangasek> StevenK: mmno
[06:23] <StevenK> Damn it libopenvrml, document your API changes!
[06:25] <slangasek> superm1: are the mythbuntu tasks in the archive's Packages files?
[06:30] <TheMuso> slangasek: afaik only the ubuntu tasks are in the archive packages files, but I could be wrong.
[06:30] <slangasek> well, xubuntu and kubuntu ones are too; if the mythbuntu ones aren't, I don't know where they are, so it's hard to help debug
[06:32] <superm1> slangasek, they should be
[06:33] <superm1> slangasek, cjwatson would know for sure where they are though
[06:33] <superm1> tbh the way these tasks work is black magic to me.  laga worked with cjwatson to get them functional
[06:35] <slangasek> ok; the tasksel data shows mythtv-backend-master is the key package, and I don't see any other packages in the archive with the task field set... let's see what I get with just the one package
[06:38] <slangasek> superm1: reproducible with 'aptitude --with-recommends install mythtv-backend-master'
[06:38] <superm1> slangasek, is that what tasksel ends up using for it's backend then (aptitude rather than apt-get)?
[06:38] <superm1> i would imagine that similar server apache tasks ran into the same thing though
[06:39] <slangasek> superm1: is it /meant/ to pull in apache? is the bug only the conflict, or is the bug that there shouldn't be a webserver at all?
[06:39] <superm1> there should be a webserver, yes
[06:39] <superm1> it sets up a website (mythweb) with the master backend task
[06:39] <slangasek> superm1: nah, tasksel uses apt-get AFAIK, I'm just using aptitude because it has a simpler switch for toggling recommends
[06:39] <superm1> and that's what pulls apache
[06:39] <slangasek> ok - then I guess it's not reproducible, I only see apache2-mpm-prefork being pulled and not apache2-mpm-worker
[06:40] <superm1> well not reproducible outside of the alternate disk env you mean.  i can consistently make it happen on the latest daily
[06:41] <slangasek> yes, that's what I mean
[06:41] <slangasek> let me have a look at the build log; apache2-mpm-worker shouldn't even be on the CD, by all rights
[06:42] <StevenK> gtklookat.cpp:619: error: 'cout' is not a member of 'std'
[06:42] <StevenK> gtklookat.cpp:619: error: 'cerr' is not a member of 'std'
[06:42]  * StevenK kicks C++ more
[06:43] <slangasek> superm1: ah - apache2 prefers worker, but something else is also pulling in php5, which requires prefork
[06:43]  * StevenK sighs that php5 requires prefork
[06:43] <superm1> slangasek, well mythweb would be pulling in libapache2-mod-php5 or php5
[06:43] <StevenK> I thought std::cout and friends still worked?
[06:44] <slangasek> StevenK: yeah, such a tragedy that php5 doesn't work with threaded webservers so that PHP can be more widely adopted ;P
[06:44] <StevenK> Haha
[06:44] <slangasek> superm1: then something needs to be hard-coded in the dependency ordering to ensure that apache2-mpm-prefork is always seen first
[06:45] <superm1> slangasek, so probably hack on the the mythweb depends
[06:45] <StevenK> Isn't it because one library isn't thread-safe?
[06:45] <wgrant> It's probably just because PHP is awful and wants to die.
[06:46] <slangasek> StevenK: it's because the last time I tried to turn on the thread-safe SAPI for PHP, upstream bitched at me that this was only supported on Windows, and we were doing a horrible thing by breaking binary compatibility with the all-important proprietary accelerators
[06:46] <superm1> slangasek, would just making the depends apache2-mpm-prefork | apache2 cover it then likely?
[06:47] <slangasek> superm1: why have an alternative at all?
[06:47] <kees> bryce: very cool!  does that fix me too (even though I didn't show evdev?)
[06:47] <superm1> slangasek, well i guess in case worker is ever supported in php5
[06:47] <superm1> but i suppose you're right
[06:48] <slangasek> superm1: also, please fix mythweb to not list 'libapache2-mod-php4 | php4 | ' in the alternatives list, those packages are dead and buried and I doubt the current code would even work with them :)
[06:48] <slangasek> ditto 'php4-mysql | '
[06:48] <superm1> slangasek, that was there mostly for backportability
[06:49] <slangasek> well, unless someone is backporting to dapper, they're redundant
[06:49] <bryce> kees, yes; you're probably using evdev even though kbd was shown in your xorg.conf
[06:49] <superm1> current code does still work with the php4 stuff, but i'm not sure how far back we'll be backporting, probably not to dapper anymore; you're right
[06:49] <slangasek> superm1: and if you think they're still needed, I would recommend moving them last
[06:49] <kees> bryce: ah-ha, yeah, reading the new comments in the bug report.  nice.
[06:49] <superm1> i'll drop them
[06:49] <slangasek> ok
[06:50] <superm1> thanks for the quick help slangasek
[06:50] <slangasek> superm1: sure.  will you be doing an upload tonight, that I should watch for?
[06:50] <superm1> slangasek, yeah i'll do it in a few moments
[06:50] <slangasek> ok; I'll stick around to push it through the queue
[06:50] <superm1> thanks
[06:51] <cody-somerville> slangasek, I have a few things I need pushed as well
[06:52] <slangasek> cody-somerville: uh.  that's... not good?
[06:52] <slangasek> cody-somerville: are we talking beta showstoppers?
[06:52] <cody-somerville> slangasek, no
[06:52] <slangasek> ok
[06:53] <cody-somerville> but it would be nice to offset the barage of inevitable bugs reports and e-mails I'll get if I don't get the fixes into the archive :)
[06:53] <slangasek> in the archive, but not on the CDs, yes?
[06:53] <cody-somerville> Right.
[06:53] <cody-somerville> They can be rolled in for the release candidate
[06:54] <kees> sabdfl or mdz: hi! can you renew my ubuntu-dev membership when you get a chance?  I just got a reminder email.  :)
[06:55] <cody-somerville> kees, whats your launchpad id?
[06:55] <wgrant> kees: You're not meant to keep your direct membership; you should be in motu or core-dev instead.
[06:56] <kees> cody-somerville: "kees"
[06:56] <kees> wgrant: oh.  :P
[06:57] <StevenK> I thought I got renewed in -dev. I'm not sure.
[06:57] <cody-somerville> kees, you probably want to be renewed in core-dev, not dev :P
[06:57] <kees> sabdfl and mdz: never mind :)
[06:57] <kees> cody-somerville: no, I seem to be in both.
[06:57] <kees> my ubuntu-dev is just redundant.
[06:57] <wgrant> Right.
[06:57] <cody-somerville> Right
[06:57] <dholbach> good morning
[06:57] <cody-somerville> but your membership is core-dev is about to expire too
[06:58] <kees> heya dholbach :)
[06:58] <wgrant> ubuntu-dev should in the end consist of ubuntu-core-dev and motu.
[06:58] <cody-somerville> (in
[06:58] <cody-somerville> guh
[06:58] <cody-somerville> *in
[06:58] <kees> cody-somerville: well, in 2 months
[06:58] <wgrant> Isn't core-dev self-renewable?
[06:58] <dholbach> hi kees
[06:58] <cody-somerville> kees, Thats like next week :P
[06:58] <kees> wgrant: I think so
[07:09] <slangasek> superm1: ping me when you've uploaded, please
[07:10] <superm1> slangasek, should have been uploaded now
[07:10] <slangasek> ok
[07:11] <FatalError> not sure if this is the correct place to ask -- but how do I find out who owns a package? that, or how would I go about contributing an updated package for something?
[07:12] <RAOF> FatalError: Generally, no one owns packages in Ubuntu.
[07:13] <liw> FatalError, to contribute, make an updated package, and file the patch or debdiff as a bug in Launchpad
[07:14] <FatalError> oh, right on
[07:14] <FatalError> because the current xchat has a nasty file descriptor leak ( which has since been fixed ) :) I'll go take a look at launchpad
[07:40] <pitti> Good morning
[07:41]  * slangasek waves
[07:42] <StevenK> Morning pitti
[07:43] <geser> Guten Morgen pitti
[07:43] <cody-somerville> Oh lovely
[07:44] <cody-somerville> I guess people don't listen to music much on Xubuntu or our testers completely missed the fact that Audacious has pulseaudio set as the default output plugin when Xubuntu uses alsa...
[07:49] <TheMuso> cody-somerville: How does audacious store its default settings?
[07:49] <RAOF> Whoops.  It seems the latest ubuntustudio-menu upload broke compiz :)
[07:50] <TheMuso> RAOF: how?
[07:50] <TheMuso> RAOF: and why do you have ubuntustudio-menu installed?
[07:50] <RAOF> TheMuso: Someone set XDG_CONFIG_DIRS, and the compiz wrapper script is broken.
[07:50] <RAOF> TheMuso: I don't, but someone on ubuntuforums does.
[07:51] <TheMuso> RAOF: how does that break the compiz wrapper script?
[07:51] <RAOF> The compiz wrapper script stores stuff in /etc/xdg/compiz/compiz-manager.  However, it doesn't handle XDG_CONFIG_DIRS correctly; it only handles a single setting there.
[07:52] <TheMuso> Riiiiight.
[07:52] <RAOF> It's always been broken, it's just that practically no one sets a list of dirs in XDG_CONFIG_DIR.
[07:52] <TheMuso> So that sounds more like a compiz wrapper scrit problem then.
[07:52] <RAOF> Right.
[07:52] <TheMuso> RAOF: Well both edubuntu and now ubuntustudio do.
[07:52] <RAOF> Indeed.
[07:52] <TheMuso> The ubuntustudio package got the code from edubuntu menus.
[07:52]  * RAOF goes of to fix the compiz wrapper.
[07:53] <cody-somerville> TheMuso, not sure
[07:53] <TheMuso> cody-somerville: I'll have a dig if you like.
[07:54] <cody-somerville> TheMuso, I've had some complaints about audacious anyhow
[07:54] <cody-somerville> TheMuso, I'm thinking rhythmbox or exaile would be better candidates for Xubuntu
[07:54] <TheMuso> ah man, it patches a c file? *sigh*
[07:55] <TheMuso> cody-somerville: Right. You already have gstreamer there for totem correct? Then thats an almost no-brainer.
[07:55]  * cody-somerville nods.
[07:56] <RAOF> So, I want to iterate over a colon-separated list.  Setting IFS to : and then looping with for is a perfectly sane implementation, right?
[07:56] <TheMuso> RAOF: Sounds sane, jjust make sure to store the old IFS and set it back to how it was.
[07:58] <RAOF> Right.  That's how I've done it in the past.  Just checking that there isn't some magical shell tricks that everyone else knows that I don't :).
[08:00] <siretart> lool: if you are OK, I'd like to upload the debdiff attached to bug #97721
[08:01] <siretart> lool: oh, ignore me. that fix is already in the package
[08:05] <cody-somerville> rhythmbox doesn't seem to accept cdda:/ has a URI. What URI would I pass to rhythmbox to get it to play a CD?
[08:07] <TheMuso> cody-somerville: give me a bit and I'll find out.,
[08:11] <TheMuso> cody-somerville: from my test here its cdda://scd0 but I am not sure what represents the scd0 in terms of the device node. I'd say its in the gconf schemas somewhere. :)
[08:37] <cody-somerville> TheMuso, that doesn't work for me
[08:37] <cody-somerville> TheMuso, Failed to load cdda://scd0: No registered source can handle URI cdda://scd0
[08:39] <RAOF> Does Xubuntu have gnome-vfs or gvfs installed?  That'd be a fair guess as to what provides cdda:// URIs.
[08:40] <roachmmflhyr> what causes my ubuntu graphics to look very windows 98ish??
[08:42] <RAOF> So, how does the compiz team like their bzr branch merge requests?
[08:42] <henux> maybe a gtk theme?
[08:43] <cody-somerville> RAOF, yea
[08:43] <roachmmflhyr> henux, im using the human clear looks theme
[08:45] <wgrant> roachmmflhyr: What do you mean it looks Windows 98ish?
[08:45] <RAOF> seb128: Aha.  As the only member of ~compiz on irc at the momen, you're my target :).  How would you like a bzr branch of the Compiz packaging to be presented?
[08:46] <RAOF> Just as soon as the launchpad/bzr unholy duo stop being crazily slow.
[08:46] <seb128> that's a mistake, I should unsubscribe of this team, you want to talk to mvo when he will be there
[08:46] <roachmmflhyr> like in nautilus or any notification windows that pop up there are gray and boxy--what package is gtk in? I want to reinstall it
[08:47] <RAOF> Heh.  Fair enough.
[08:48]  * roachmmflhyr fixed it..... wgrant
[08:48] <cody-somerville> How stable is elisa?
[08:48] <RAOF> It seemed to work OK for me.  It's been uninstallable for quite some time, though.
[08:48] <roachmmflhyr> wgrant, just reinstalled libgtk<IP_ADDRESS>, turned off desktop effects and then turned them back on...all good to go now
[08:49] <seb128> reinstalling is not likely to make any difference
[08:50] <dholbach> hey seb
[08:50] <dholbach> seb128: I sponsored the new totem - do you think you can take a look at the libgnomecanvas sponsoring item?
[08:51]  * wgrant hopes seb128 is right.
[08:51] <seb128> dholbach: we are frozen I'm not going to sponsor anything today
[08:52] <seb128> dholbach: thanks for the sponsoring though, I'll look at other items after the beta freeze if I can connect to launchpad again ;-)
[08:52] <dholbach> ok
[08:53] <seb128> dholbach: and out of the freeze I've connectivity issues today, can't reach any of the canonical or gnome boxes
[08:54] <dholbach> that sucks :-/
[08:55] <lool> siretart: So it's fixed as a side effect of not enabling optimizations?
[08:55] <seb128> indeed, I can't read my mails or do bug triage
[08:57] <pitti> seb128: ssh and mutt FTW :)
[08:58] <siretart> lool: no, it was a patch that you already imported from somewhere else
[08:58] <seb128> pitti: well, you need a box you can ssh to which has access to mail.canonical.com and that's not my case right now ;-)
[08:58] <siretart> lool: it turns out that the version in hardy is still affected but not the version in intrepid. the package was synced too late
[08:58] <roachmmflhyr> nevermind some of my windows and menus are still win 98ish looking  check it out here http://pichostonline.com/u/081002/9e101d34b4.png
[08:59] <StevenK> seb128: Routing issues?
[09:00] <seb128> it seems so
[09:00] <seb128> it stops after "ae-1-100.ebr2.Amsterdam1.Level3.net (<IP_ADDRESS>)     80.442ms asymm 10" on no reply apparently
[09:03] <pitti> superm1: http://cdimage.ubuntu.com/mythbuntu/daily/20081002.1/ hot and fresh
[09:03] <StevenK> pitti: Z3r0-d4y w4r3z?
[09:03] <lool> siretart: Oh ok
[09:03] <pitti> StevenK: shh, s3kr1t!
[09:04]  * StevenK grins
[09:07] <lool> seb128: Happened to me some weeks ago, I was really in trouble
[09:07] <StevenK> seb128: Can you get to mangled.wedontsleep.org? I can set up a mail tunnel, if you wish
[09:07] <lool> seb128: We could work on some proxying for you
[09:07] <seb128> lool: what that an isp issue and did you have to tell them about it?
[09:08] <lool> seb128: My ISP is Free, I did try to contact them and even used in house contacts
[09:08] <lool> Nobody understood the issue I was raising and they told me to wait
[09:08] <lool> It was fixed a couple of days after it started
[09:08] <lool> My in house contacts replied too late
[09:08] <seb128> thanks guys but don't bother for now, I can access to cdimage.ubuntu.com (but not launchpad, debian.org or gnome.org) so I just synced a new iso
[09:08] <lool> As in didn't pick the phone and got to my email hours after it was fixed
[09:09] <lool> SOMEONE GIVE ACCESS TO BUGS.LAUNCHPAD.NET TO seb128!
[09:09] <seb128> I will do some iso testing for a while, if internet is still not back after that I might ping you for the proxy thing ;-)
[09:09] <mdz> what does the "PIIX3...enabling passive release" message mean which comes up in KVM?
[09:09] <lool> seb128: :-P
[09:09] <mdz> sorry, meant that for -kernel
[09:12] <cjwatson> roachmmflhyr: you were installing libraries from source last time I heard - if you broke your system that way, you'll have to fix it yourself, we have no idea what you did and can't in general support people doing that sort of thing
[09:14] <cjwatson> kees: done your pocket-copies
[10:11] <mdz> dholbach: I have a small tool which I'd like to add to ubuntu-dev-tools. it depends on bsdtar.  should I make that a depends or a recommends?
[10:22] <RAOF> mvo: I've got a bzr branch of compiz that fixes compiz-manager's handling of XDG_CONFIG_DIRS.  How would you like it?
[10:23] <mvo> RAOF: if its a branch, then just give me the location and I merge
[10:23] <mvo> RAOF: you should be part of the compiz team :)
[10:24] <RAOF> mvo: it's lp:~raof/compiz/wrapper-fix
[10:25] <RAOF> I haven't touched compiz packaging for _ages_ - I'd be afraid of stepping on your toes :)
[10:27] <mvo> RAOF: I have big shoes :) help in the team would be very welcome!
[10:28] <dholbach> mdz: if you make it a recommends, it'd be nice if the tool would not explode if it's not installed :-))
[10:28] <dholbach> mdz: what kind of tool is it?
[10:29] <mvo> RAOF: thanks, commited
[10:32] <mdz> dholbach: just a simple script which extracts the version info from an .iso, I use it during testing
[10:32] <mdz> mizar:[.../canonical/ubuntu-dev-tools] ./isoversion /space/tmp/mdz/tmp/hardy-server-i386.iso
[10:32] <mdz> Ubuntu-Server 8.04 "Hardy Heron" - Release i386 (20080423.2)
[10:32] <cjwatson> I use 'isoinfo -R -i foo.iso -x /.disk/info'
[10:33] <mdz> cjwatson: I used to use that, too, then I decided it should be a script :-)
[10:33] <mdz> it could as easily use isoinfo, I suppose
[10:33] <cjwatson> oh, sure :-) I just meant if you thought genisoimage was less exotic than bsdtar
[10:33] <cjwatson> although bsdtar is certainly very useful
[10:33] <cjwatson> genisoimage is in main though
[10:33] <mdz> cjwatson: I was thinking of adding some additional options to the script and bsdtar seems more flexible
[10:34] <mdz> it does whine about out-of-order files a lot though
[10:35] <mdz> and isoinfo is a lot faster. it wins
[10:35] <mdz> dholbach: same question, though; depends or recommends?  I notice that bzr is only a recommends, though some of the tools use it
[10:36] <dholbach> I'd probably make it a recommends and let the tool print a "Please run: sudo apt-get install ...." if it can't find the package
[10:36] <dholbach> but I didn't write a "ubuntu-dev-tools rulebook" :)
[11:07] <mdz> pitti: do you have thoughts on whether bug 264696 should be fixed in consolekit or gnome-session?
[11:10] <pitti> mdz: gnome-session can't do that, and  CK is unrelated; according to the comments in usplash's init script, "it expects the display manager to have started the daemon with usplash_down", so it should either be in gdm, or we should fix usplash's init script
[11:11] <pitti> mdz: in my test installation I did see a splash down, although only a very short one
[11:11] <pitti> (in kvm, it doesn't work on my workstation)
[11:11] <pitti> mdz: I'll reassign it to usplash for now
[11:12] <mdz> pitti: I don't think it can be fixed in usplash; how would it know when X has exited?
[11:12] <mdz> pitti: it gets started in init.d/sendsigs or something, for the last 1 second of shutdown, which is pointless and should probably be removed
[11:12] <pitti> oh, right, that's yet another bug
[11:13] <pitti> gnome-session doesn't actually shut down the session any more, it just triggers the reboot
[11:13] <pitti> if it would do that, X would already be shutdown when /etc/rc0.d/K01usplash runs, or not?
[11:14] <mdz> pitti: what should happen is that X shuts down, and *immediately* after that, usplash_down is run
[11:14] <pitti> right
[11:14] <mdz> pitti: otherwise the user sees a bunch of console message garbage in between
[11:14] <mdz> this used to work properly ca. gutsy, I think it may be somewhat broken in hardy
[11:16] <pitti> so previously, GDM_LOGOUT_ACTION_SHUTDOWN caused gdm to call usplash_down?
[11:17] <pitti> seb128: WDYT, should we change that to just call usplash_down and quit X, but not shutdown? and change gnome-session to call ACTION_SHUTDOWN for the CK shutdown path, too?
[11:18] <seb128> pitti: no real opinion on the topic, gnome-session is not the only way to shutdown the box nowadays, would that work for the fast user switch applet for example?
[11:19] <pitti> seb128: they all just call ConsoleKit?
[11:19] <seb128> pitti: dunno, I didn't look at what ted did in the new fast-user-switch-applet
[11:19] <mdz> pitti: I filed bug 277058 about that
[11:19] <seb128> pitti: same about the restart now notification
[11:20] <pitti> I'm only afraid that adding usplash_down to /usr/lib/ConsoleKit/scripts/ck-system-stop won't work either
[11:20] <seb128> why not?
[11:20] <pitti> at least not until we can actually make sure that gnome-session stopped the session and gdm killed X before ck-system-stop runs
[11:21] <mdz> pitti: yes, that's what previously happened
[11:21] <pitti> otherwise we could just add it to /etc/rc0.d/K01usplash
[11:21] <mdz> (gdm called usplash_down)
[11:21] <pitti> (which would be more correct then)
[11:22] <mdz> I would go ahead and fix bug 277058, but it would look like a regression without fixing bug 264696 first
[11:22] <pitti> so how about we add it to /etc/rc0.d/K01gdm then?
[11:22] <mdz> pitti: my only concern there would be the use case of "sudo /etc/init.d/gdm stop"
[11:23] <mdz> it would be pretty weird for usplash to start unless the system is actually shutting down
[11:23] <pitti> mdz: it could check if the runlevel is 0 or 6
[11:23] <mdz> pitti: does upstart have runlevels?
[11:23] <pitti> $ runlevel
[11:23] <pitti> N 2
[11:23] <pitti> mdz: I think as long as we use rc0.d/, it will
[11:23] <mdz> where is Keybuk?
[11:24]  * pitti fires up kvm and tests
[11:25] <pitti> "This tool is provided for compatibility with the traditional  System  V
[11:26] <pitti>        init(8).   Upstart  has  no  notion  of  runlevels itself, this and the
[11:26] <pitti>        telinit(8) tool are provided to emulate their behaviour."
[11:27] <mdz> Keybuk: pitti and I were talking about how best to fix bug 264696
[11:28] <mdz> Keybuk: he made the suggestion to add code to /etc/init.d/gdm:stop which would check the current runlevel, and if 0 or 6, then start usplash_down after gdm finished shutting down
[11:28] <mdz> I don't know how kosher that is in upstart-land
[11:29] <Keybuk> that seems perfectly valid
[11:29] <Keybuk> though is gdm stop called on shutdown?
[11:30] <Keybuk> the same effect could be made by just making "usplash stop" actually start usplash
[11:30] <Keybuk> since there's a K01usplash in 0 and 6
[11:30] <pitti> that's what I just tried
[11:31] <mdz> Keybuk: yes, it installs K01gdm
[11:31] <pitti> I do get some seconds of text mode with an empty screen and cursor until usplash starts, though
[11:31] <pitti> so if we could start it just a little earlier, that would be perfect
[11:31] <Keybuk> wouldn't you get the same seconds by doing it at the end of K01gdm?
[11:31] <Keybuk> there isn't anything between the two
[11:31] <pitti> can we actually call usplash_down *before* killing X? this should already switch VT, and thus if X can be killed without interfering with VTs, it would be seamless
[11:32] <pitti> Keybuk: right, thus ^
[11:32] <Keybuk> that's what we did before, no?
[11:32] <mdz> Keybuk: that might work, until we get a display manager whose name begins with 'v'
[11:32] <mdz> pitti: possibly, but not for intrepid
[11:32] <cjwatson> mdz: (xdm!)
[11:32] <mdz> too many races
[11:32] <mdz> cjwatson: ha!
[11:32] <pitti> architecturally, K01usplash would be the right solution, to not clutter gdm and kdm init scripts with usplash knowledge
[11:32] <cjwatson> actually there's wdm too
[11:32] <Keybuk> where was usplash invoked before?
[11:32] <mdz> Keybuk: from gdm itself
[11:32] <pitti> Keybuk: directly from gdm
[11:33] <pitti> and kdm, I suppose
[11:33] <Keybuk> that patch no longer works because CK does the shut down?
[11:33] <mdz> pitti: the gdm and kdm init scripts already have usplash knowledge, to make sure that it's shut down before they start
[11:33] <mdz> this is actually a use case for making them upstart jobs
[11:34] <mdz> but at this point I'm just looking for a way to restore the old behaviour for intrepid
[11:34] <mdz> it's been ripped out of gdm because it doesn't handle shutdown anymore, that goes gnome-session->consolekit
[11:35] <pitti> doing usplash_down right before gdm doesn't even help, too many VT switches
[11:35] <Keybuk> it doesn't look like consolekit makes any special effort to stop gdm
[11:35] <pitti> so, a safe 80% fix is to add it to K01usplash
[11:35] <pitti> Keybuk: no, just through the standard init scripts
[11:35] <Keybuk> so the only way to do it is to add the code to K01gdm, K01kdm, etc.
[11:36] <Keybuk> or have a K02usplash (yes, I just renumbered it :p)
[11:37] <cody-somerville> heh
[11:37] <Keybuk> at least, that's the only immediately apparent way that doesn't involve the red VT switch and the blue VT switch having a race
[11:37] <mdz> and conditionalize it based on the runlevel?
[11:38] <cjwatson> Keybuk: *earworm*
[11:38] <Keybuk> well, if it's done in usplash stop, you wouldn't need to do that?
[11:38] <pitti> mdz, Keybuk: I added my findings as followup to bug 264696
[11:39] <pitti> was it actually seamless in hardy? ISTR those couple of seconds of text terminal as well
[11:41] <cjwatson> (for those lacking the earworm: http://darkaeon.wordpress.com/2008/05/02/the-red-car-and-the-blue-car-had-a-race/)
[11:44] <Keybuk> pitti: it was more seamless, but then also quite racey
[11:45] <mdz> Keybuk: it wasn't racy IIRC
[11:45] <Keybuk> I quite often saw a shutdown where the first stage usplash never made it
[11:46] <mdz> oh, yes, I think that was possible, but the vt switching wasn't racy at least
[11:47] <Keybuk> I always put it down to a vt switch race
[11:48] <Keybuk> but I only really did cursory debugging
[12:06] <asac> zul: to get the current openvpn in the network-manager PPA for hardy, is it just openvpn that needs to be backported or also some build-deps?
[12:30] <zul> asac: both maybe I havent looked at it :)
[12:30] <asac> zul: what is "both"?
[12:31] <zul> asac: er....build-deps
[12:31]  * zul just rolled out of bed
[12:33] <lool> pitti: I've pushed facile_1.1-6.1ubuntu1; I did some additional changes aside of the published debdiff:
[12:33] <lool>   * Set DEB_MAKE_CHECK_TARGET to check || true to not fail the build if the
[12:33] <lool>     testsuite doesn't pass; NB: it does seem to pass currently.
[12:33] <lool>   * Use Vcs-* headers instead of XS-Vcs-*.
[12:33] <lool>   * Bump up Standards-Version to 3.8.0.
[12:33] <lool> It pbuilt fine and is now lintian -I clean
[12:34] <lool> pitti: Could you please accept it, and I'll set the MIR to In progress :)
[12:35] <pitti> lool: I accepted all pending universe stuff, thank you
[12:35] <pitti> lool: why ||true'ing the test suite then, if it works?
[12:37] <Koon> asac: about n-m-openvpn, I could reproduce bug 275608 -- not sure it isn't fixed on the pending release though. I am a little lost in the panel building subtleties
[12:37] <asac> Koon: i saw a patch for that somewhere
[12:37] <asac> i think on NM mailing list
[12:38] <Koon> asac: noted
[12:38] <asac> Koon: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00287.html
[12:38] <asac> Koon: can you test that and confirm that with that patch everything is ok?
[12:39] <Koon> asac: sure.
[12:44] <lool> pitti: I wasn't confident that it would remain working and preferred having the package build succeed if it starts not doing so
[12:45] <pitti> lool: hm, I usually prefer having the test suite fail the build, so that regressions become immediately obvious
[12:48] <lool> pitti: Ok; I will probably commit the testsuite failing the build in Debian then
[12:48] <lool> I think I did it from experience with the heavy testsuites in GNOME libs or using xvfb which had a tendency to break over time or on some arches, but this doesn't apply to this one
[12:49] <lool> I just had a bad feeling about the testsuite upstream implementation that I didn't want the build to fail if upstream didn't care about it
[12:49] <lool> (The ./configure hackery and upstream custom Makefile felt fragile)
[12:57] <ogra> cjwatson, hmm, when did the auto-login fix in ubiquity get in ?
[12:58] <ogra> i dont see an upload for it, but its definately working on todays mobile image
[13:06] <cjwatson> ogra: 1.10.2; you didn't see it on -changes because that was rejected and only 1.10.3 was accepted, but the latter contained the former
[13:06] <ogra> cjwatson, ah, i think debcommit -r wasnt intelligent and just didnt include the changelog entry, i see it in the package changelog
[13:06] <cjwatson> debcommit doesn't generate the .changes
[13:06] <ogra> ah, or that :)
[13:06] <ogra> oh, indeed, it doesnt
[13:06] <ogra> anyway, bug fixed, works fine ;)
[13:06] <cjwatson> I could have used debuild -v1.10.1, but I expected both 1.10.2 and 1.10.3 to be accepted in which case both would have shown up on .changes
[13:07] <liw> asac, when testing an upgrade of xubuntu from hardy to intrepid, I get (at least) four windows saying "The NetworkManager applet could not find some required resources. It cannot continue". (Make that five, another popped up just now)
[13:07] <liw> asac, does that sound familiar?
[13:08] <asac> liw: you tried to manually restart things? or did you reboot?
[13:08] <liw> asac, the ugprade is still running (six windows now)
[13:08] <liw> asac, I haven't touched anything, except to move the windows so I can count them (seven)
[13:09] <asac> liw: so was NM already unpacked?
[13:09] <liw> asac, how do you mean? it was running in the system from which I started the upgrade
[13:10] <liw> asac, this is under kvm, if that matters (though it shouldn't)
[13:11] <asac> liw: what i wonder about is whether this happens before or after the NM bits have been unpacked during upgrade
[13:12] <liw> asac, hmm, I don't think I can figure that out anymore
[13:12] <liw> asac, unless there's some log file I can grep for you
[13:17] <liw> asac, this is a guess, but based on the timestamps in dpkg.log, I would guess the problems started happening approximately when network-manager(,-gnome} were unpacked; I can't verify that that's true, but my internal clock would indicate it is
[13:18] <liw> (but my internal clock thinks it is about 22:57 right now, where as NTP tells me it is 15:18 local time)
[13:24] <asac> liw: ok. strange that it happens in xubuntu.
[13:24] <asac> liw: did the upgrade restart dbus or something?
[13:27] <asac> liw: ok that error message comes from 0.7 applet
[13:27] <asac> liw: this means that you restarted the applet
[13:27] <asac> (if not you something else restarted it)
[13:27] <asac> which must not happen
[13:28] <asac> liw: maybe the xubuntu xsession does some magic to restart binaries?
[13:28] <liw> asac, I don't know what xubuntu does, I just test this :)
[13:28] <asac> cody-somerville: ^^
[13:29] <cody-somerville> We don't do any magic
[13:29] <asac> liw: can you see when the nm-applet process was started?
[13:30] <liw> asac, long before the problems
[13:30] <asac> liw: question is if it was started long before the unpack :)
[13:30] <liw> (ps says it was started 14:26, problems started around 15:00)
[13:31] <liw> unpack also approximately at 15:00
[13:31] <asac> liw: so 14:26 is about the time you logged into xubuntu?
[13:31] <liw> asac, yeah
[13:31] <asac> liw: and you did nothing? e.g. not even tried to start the connection editor or something?
[13:32] <liw> asac, nope, I only ran the upgrade command
[13:32] <liw> (sudo update-manager -d -c)
[13:32] <asac> mvo: does update-manager try to restart things?
[13:33] <Koon> asac: patch works (slightly modified so that it picks up translations correctly), needs to be refreshed to apply to pending release though. Will do whenever the dependant packages are released. Commenting on bug right now.
[13:33] <mvo> asac: restart what? firefox?
[13:33] <mvo> liw: sudo is not needed (but shouldn't hurt either)
[13:33] <asac> mvo: no restart nm-applet (which usually gets auto started by the session)
[13:34] <liw> mvo, ok, I just copy paste from https://wiki.ubuntu.com/Testing/Cases/DesktopUpgrade (I'll get that fixed)
[13:34] <mvo> asac: no, it can't because the actual installation runs as root
[13:34] <asac> mvo: myterious then. liw logged into xubuntu. ran upgrade and without doing anything suddenly sees applet error dialogs from 0.7
[13:34] <mvo> asac: however it seems that network manager kills the network when it gets upgraded sometimes (or all th time?)
[13:34] <asac> mvo: thats not done anymore
[13:35] <asac> mvo: dbus restart could cause something though
[13:35] <asac> but i dont see how it can restart the applet :(
[13:35] <mvo> asac: we don't do that
[13:35] <mvo> asac: it might be that the applet probably restarts itself (or gets restarted by something like the session) because it crashes when the new n-m gets installed
[13:36] <liw> asac, if the applet has been running since I logged in and before I started the upgrade, did it really get upgraded?
[13:36] <asac> liw: yeah.
[13:36] <asac> liw: my grep was bogus ... 0.6.6 applet will complain like that too in some cases
[13:37] <asac> liw: do you see if NM restarted was restarted?
[13:37] <asac> (the daemon)
[13:38] <liw> asac, it has also been running since 14:26, i.e., hasn't been restarted, as far as I can see
[13:39] <asac> liw: ok looks like it happens if NM tries to use icons that it didnt use previously
[13:39] <asac> liw: so most likely would just be the case if you have more or less a fresh started session
[13:40] <liw> asac, ok, that sounds reasonable; shall I continue with the upgrade, then, or do you want me to grep for something more? also, should I file a bug?
[13:40] <asac> liw: you could strace -eopen -p PID
[13:40] <asac> and tell me which file it tries to open when it complains
[13:40] <liw> asac, the applet?
[13:40] <asac> yeah
[13:41] <asac> liw: we could consider to create compatibility links ... and then see what other resources nm-applet would complain when the icons are still available
[13:42] <asac> maybe there would be a missing .glade resource too ... which would be harder to fix
[13:42] <liw> asac, I can't seem to be able to trigger the applet to open the icon anymore, hmm
[13:42] <liw> ah, no, got it now
[13:42] <liw> asac, it's (at least) /usr/share/icons/gnome/16x16/actions/gtk-edit.png and gtk-about.png
[13:43] <liw> asac, though both now succeed, hmm
[13:43] <asac> yeah those are not NM icons
[13:44] <asac> liw: http://paste.ubuntu.com/53182/
[13:44] <asac> those are the ones i suspect to be missing
[13:45] <asac> liw: seems like the only one missing is vpn-lock
[13:45] <asac> can you confirm that?
[13:45] <asac> yeah thats vpn-active-lock now from what i can see
[13:45] <liw> there is no file matching vpn-lock* under /usr/share/icons
[13:45] <asac> liw: right
[13:46] <asac> thats gone ... and thats why you get this
[13:46] <asac> ln -s /usr/share/icons/hicolor/22x22/apps/nm-vpn-active-lock.png /usr/share/icons/hicolor/22x22/apps/nm-vpn-lock.png
[13:46] <asac> might be what we want
[13:46] <liw> in fact, no icon matching vpn*
[13:46] <liw> oh, nm-vpn*
[13:46] <asac> liw: dpkg -L network-manager-gnome | grep vpn.*png$
[13:46] <MacSlow> pitti, what apart from d-feet can I use to monitor/query all this DBus-"stuff"
[13:46] <asac> liw: i will ask NM folks why that icon was renamed ;)
[13:47] <asac> liw: everyother icon is there right?
[13:48] <MacSlow> pitti, of would d-feet work if I export its display to another machine where I have X.org up constantly? I mean on the machine I test/debug my gdm-graphical-greeter on I start and stop X11 all the time.
[13:48] <liw> asac, nm-device-wired-autoip seems to be missing, too
[13:51] <liw> asac, so, do you need a bug report filed, or do you remember this anyway?
[13:52] <asac> liw: yes please. what i need is a list of icons that are used in nm 0.6 but that are not there in 0.7 anymore (at best from the list above)
[13:52] <asac> liw: most likely its those two icons
[13:52] <liw> asac, OK, I'll quote much of the above discussion, for clarity
[13:54] <asac> liw: yeah. just state in the beginning the list of icons we just found
[13:55] <asac> subscribe me to the bug and milestone :)
[13:55] <asac> thanks!!
[13:55] <pitti> MacSlow: that would work, yes (ssh -X)
[13:55] <pitti> MacSlow: for monitoring, dbus-monitor --system is useful
[13:56] <MacSlow> pitti, thanks
[14:01] <MagicFab> siretart, around ?
[14:04] <siretart> MagicFab: sort of, yes?
[14:05] <liw> asac, https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/277084 (I don't seem to be able to milestone it, but you're subscribed (twice?))
[14:05] <MagicFab> siretart, I am cleaning up a bunch of AMR codec related bug
[14:05] <MagicFab> bugs*
[14:06] <MagicFab> siretart, if/when you have a couple of minutes (*not* urgent by anymeans) I'd love to discuss some of them
[14:06] <MagicFab> *quick* cleanup :)
[14:09] <siretart> MagicFab: sure. what's up?
[14:10] <MagicFab> siretart, I see bugs related to "AMR free support in ubuntu in general"
[14:10] <siretart> MagicFab: I think I even have a patch that would allow us to enable amr in ubuntu. it mainly needs testing
[14:10] <MagicFab> and others "ffmpeg-specific AMR support"
[14:10] <MagicFab> and others "AMR in medibuntu not working"
[14:10] <siretart> yes. that sucks
[14:11] <MagicFab> in the first group free meaning "GPL or similarly licensed" to men
[14:11] <MagicFab> to me * :)
[14:11] <siretart> there is not GPL licensed amr implementation TTBOMK
[14:11] <siretart> at least not yet
[14:11] <MagicFab> siretart, agreed
[14:12] <asac> liw: thanks
[14:12] <MagicFab> so any patch leading to something we can't package/push as an update is not advised now unless
[14:13] <MagicFab> 1) it's some sort of plugin to external sources (like flash or decss I guess)
[14:13] <MagicFab> or
[14:13] <MagicFab> 2) it's not packages but remains as a binary somewhere else
[14:14] <siretart> there is a 3rd approach
[14:14] <siretart> the altlinux folks have crafted a patch that allows ffmpeg to load the amr libs at runtime
[14:15] <siretart> this means that we could compile ffmpeg with amr support, but it would only be useful if the user has the libamr libraries installed on his system
[14:15] <siretart> and this is the patch I've been talking a few lines above
[14:15] <MagicFab> siretart, ah, correct - so the libraries would come from..?
[14:16] <pitti> cody-somerville: do you need that new xubuntu-meta on beta? i. e. does it need a publisher run and new CDs?
[14:16] <MagicFab> siretart, and could that be implemented in the current automatic-codecs gui?
[14:16] <siretart> MagicFab: I don't really care as long it's not ubuntu. medibuntu already distributes them and I'd expect them to work
[14:17] <siretart> MagicFab: possibly. but before thinking about the automatic-codecs gui I'd suggest first working on the ffmpeg side
[14:18] <MagicFab> siretart, ok, so I tend to block dev when legal issues arise
[14:19] <siretart> 'block dev'?
[14:19]  * siretart suspect thats not 'block device' here :)
[14:20] <cody-somerville> pitti, I'm starting to fear so
[14:25] <siretart> MagicFab: are we finished with that topic?
[14:27] <MagicFab> siretart, yes, that'll help me decide. Just so you know I'll be changing those bugs statuses today
[14:27] <MagicFab> siretart, thank you
[14:27] <MagicFab> block dev -> not involve developers unless legal issues have been cleared
[14:29] <pitti> cody-somerville: well, release is supposed to happen in a few hours, so you better decide quickly :)
[14:32] <cody-somerville> davmor2, can you help test the respin?
[14:33] <davmor2> What respin
[14:37] <cody-somerville> davmor2, Xubuntu
[14:37] <davmor2> pitti, cody-somerville: is this just desktop cd's or both?
[14:38] <cody-somerville> both
[14:38] <pitti> cody-somerville: note, I didn't do it yet, I was just asking since I accepted it from unapproved, and it looked kinda important
[14:41] <davmor2> cody-somerville: if we take it that wubi works as it's been tested a boat load on other cd re-spins then that's 16 tests I gotta go off for about 30< in a bit so it's plausible have a word with slangasek though first
[14:42] <pitti> cody-somerville: the current CDs are too broken to release them?
[14:42] <terminator__> When Approximately be released today?
[14:42] <pitti> current plan is slangasek's noon, as far as I understood
[14:43] <terminator__> I mean 8.10 Beta?
[14:43] <pitti> we could release xubuntu beta a bit later, I guess, but it would look a bit weird
[14:44] <cjwatson> what's the justification for the respin?
[14:44] <cjwatson> I see you've made a bunch of changes (and that you aren't using current germinate ...)
[14:46] <terminator__> When the 8.10 beta release is made, what http page on Ubuntu will it be found.  I'd like to set it up in advance?
[14:46] <davmor2> cody-somerville: we can probably test it all but we'll need the cd's sooner than latter
[14:46] <cody-somerville> pitti, I wouldn't say too broken but there has been more than just some minor modifications
[14:47] <cjwatson> cody-somerville: which ones are beta-critical?
[14:47] <pitti> cody-somerville: well, the amount of modifications isn't really interesting
[14:47] <slangasek> pitti: oh, well, I had said London's noon or thereabouts; but this is certainly not done yet.  What's the context for the current xubuntu discussion?
[14:47] <cjwatson> there are lots of other things stacked up for *after* beta
[14:47] <pitti> cody-somerville: but if the current CDs break installation in a way which cannot easily be fixed with a system upgrade
[14:47] <cody-somerville> a respin would only be to take advantage of the extra testing thats available
[14:48] <pitti> slangasek: good morning; darn, I hoped to be able to start that release upgrade wiki page before you get up (got sucked into bug fixing and meeting now)
[14:48] <slangasek> pitti: no worries
[14:48] <mpt> cjwatson, excuse my ignorance, but is there a chart anywhere showing how much of the CD image is taken up by each package included on it?
[14:48] <cjwatson> cody-somerville: at the moment you're asking for testers to put in more hours after already spending a few days testing, so it needs a justification
[14:48] <slangasek> pitti: I didn't exactly warn you that I was getting up early :-)
[14:48] <pitti> cody-somerville: pretty much everyone who installs beta needs to keep the isntall up to date afterwards anyway
[14:48] <cjwatson> mpt: not in a single place, unfortunately
[14:48] <jdstrand> asac: would you mind peeking at bug #264104? people are suggesting it's the kernel, but feels like the last nm update triggered it...
[14:49] <cjwatson> cody-somerville: if there's a justification of the form "eats people's disks", "will break upgrades from beta to final", etc., that sort of thing could be discussed
[14:49] <jdstrand> asac: hi btw!
[14:49]  * cody-somerville isn't pushing for a respin.
[14:49] <pitti> cody-somerville: I'd primarily be concerned about installation failures; everything else can be release-note'd, and fixed with a dist-upgrade
[14:50] <pitti> cody-somerville: (not urging you into either direction, just telling you our experience and practice)
[14:50] <cody-somerville> Okay, no respin
[14:50] <mvo> mpt: you could try baobab on a cd, not sure if you are happy with the resulting chart (or if it is very useful) but might be worth a try
[14:50] <liw> . o O (a podcast (series) on release management, by Debian and Ubuntu release management teams, would be really interesting)
[14:51] <pitti> liw: darth debian and Luke Spacewalker?
[14:51] <cjwatson> cody-somerville: you should be able to get plenty of testing from now until final
[14:52] <davmor2> so no respin?
[14:52] <mpt> mvo, interesting idea, but it says that 98.4% of the disc is taken up by casper, and I'm sure that's not true :-)
[14:53] <slangasek> mpt: it's taken up by the livefs which is in the casper dir :)
[14:53] <mvo> mpt: heh :) sorry, I was thinking about the alternate disk
[14:54] <mpt> ah I see, filesystem.squashfs
[14:54] <mpt> oh well
[14:54] <liw> can you run baobab from within the live system?
[14:55] <cjwatson> you'd want some way to aggregate the results into packages
[14:55] <mvo> liw: I guess the problem is that the package are uncompressed there
[14:55] <cjwatson> germinate output would probably be more useful all told
[14:55] <mpt> I thought a chart of that might help in deciding which packages should be kicked off and which let on
[14:55] <cjwatson> but it's split up into lots of bits
[14:55] <mvo> mpt: you could use synaptic in the livecd
[14:56] <mvo> mpt: than add the "installed size" column and sort by that
[14:56] <cjwatson> mpt: we typically use germinate output for that but it usually ends up being nowhere near that simple
[14:56] <slangasek> mpt: I think what we want is for all packages to go on a diet instead
[14:56] <mvo> (if you are intressed in the top size packages)
[14:56] <cjwatson> packages don't exist in isolation
[14:56] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/
[14:56]  * liw doesn't suggest solving all space problems by removing OO.o from default installation
[14:56] <cjwatson> within that you want the required, minimal, boot, standard, desktop-common, desktop, and live files
[14:56] <mpt> slangasek, do you have specific ideas in mind?
[14:56] <cjwatson> there may be some overlaps
[14:57] <slangasek> mpt: no, because unfortunately we're not keeping good track of how individual packages change in size over time
[14:57] <cjwatson> but deciding whether removing a package or set of packages makes a big size difference also depends on whether that would allow some dependencies to drop out, not only on the size of the packages themselves - and that often makes a big difference
[14:58] <mpt> fair enough
[14:58] <cjwatson> it would be lovely to have some magic interface that let us visualise this
[14:58] <mpt> yes, just what I was imagining :-)
[14:59] <liw> make a list/graph that shows for each package how much space can be saved if you remove that, plus all deps+recommends that aren't dep/recommended by any other package?
[14:59] <liw> something like that?
[14:59] <cjwatson> it'd need to be at least as smart as germinate
[14:59] <mvo> playing with synaptic on the livecd helps a bit to get idea, it will have a little status line saying "198 MB will be freeed"
[14:59] <cjwatson> or possibly it could get away with using germinate's output
[14:59] <mvo> when clicking on remove on OOo
[14:59] <asac> jdstrand: ipw2200 is a legacy driver
[14:59] <asac> jdstrand: well old not legacy ;)
[15:00] <cjwatson> liw: I think in many cases you would want to be considering small groups too
[15:00] <asac> jdstrand: do you see something like "scan_capa" in the syslog ? is that 0x00?
[15:00] <jdstrand> asac: alright, so you have identified I have an old laptop ;)
[15:00] <asac> jdstrand: actually 2200 shouldnt be that bad. i think 2100 is worse
[15:01] <mvo> together with the automatic dependency information, that should be a useful first approximation
[15:01] <jdstrand> with the occassion glitch after suspend, it's worked well for me for sometime
[15:01] <liw> cjwatson, yeah, good point
[15:01] <asac> jdstrand: oh so just after suspend?
[15:02] <jdstrand> asac: hibernate never really seemed to be a problem no-- but I don't use it all the time, and only hibernate when travelling
[15:02] <liw> cjwatson, that makes it less easy to present as a static list, though... some kind of interactive app might be helpful
[15:03] <jdstrand> asac: as for scan_capa, don't have any of those
[15:03] <jdstrand> asac: also, wouldn't you know it-- this morning, after doing *nothing*, it isn't symptomatic...
[15:03] <jdstrand> :/
[15:04] <asac> jdstrand: sigh
[15:04] <asac> jdstrand: does associate=0 fix that for you?
[15:04] <asac> (kernel module parameter)
[15:04]  * jdstrand wonders if it needed a cold reboot after those updates from the other day...
[15:05] <jdstrand> asac: I read that in the report, but haven't tried it
[15:05] <jdstrand> asac: if I can reproduce it reliably, I'll try that
[15:05] <asac> jdstrand: well associate must not be 1
[15:05] <asac> for old things like ipw2200
[15:06] <asac> we had the same issue before ... so its a deja-vu ;)
[15:08] <asac> jdstrand: ok asked for feedback and assigned to rtg directly with the hint that we should change associate default to 0
[15:08] <jdstrand> asac: I did a modinfo ipw2200, and it claims auto associate is on by default.
[15:08] <asac> jdstrand: yeah. thats bad
[15:08] <jdstrand> I don't see anything in /etc/modprobe.d to override that
[15:08] <asac> ok milestoning that bug
[15:08] <asac> jdstrand: no its the default in the kernel source
[15:08]  * jdstrand nods
[15:08] <asac> jdstrand: we should patch that or add something to modprobe.d
[15:09] <asac> i leave that to the kernel team
[15:09] <jdstrand> asac: it does seem to work sometimes (like this morning). is that consistent with your experience with this driver?
[15:09] <asac> jdstrand: yes auto associate will cause randomness
[15:10] <jdstrand> asac: cool-- thanks for looking into it!
[15:10] <asac> jdstrand: well we had really severe issues due to races with ipw3945 which turned out to be caused by auto associate. this makes sense to me
[15:11] <asac> jdstrand: thanks for pointing me at this bug ;)
[15:11] <jdstrand> asac: np :)
[15:17] <slangasek> pitti: on consolekit crasher, Ng found a fd leak yesterday; I'm trying to establish today whether it's related, I haven't yet leaked out all of my fds since my last reboot so I'm waiting to see
[15:17] <pitti> slangasek: I saw Ng's bug report and answered; ATM I'm nto sure whether it's related either
[15:18] <slangasek> I have the one-liner patch for the fd leak, I'm just waiting to get some evidence the two are related before uploading
[15:18] <pitti> slangasek: I spent 1.5 hours today to clean up the CK crashers, and in the end it's just three really different ones (of which one is the double close() I uploaded to intrepid now)
[15:18] <slangasek> oh, you found a double-close?
[15:18] <pitti> slangasek: oh, nice! so there was a double close *and* a forgotten close()?
[15:18] <slangasek> yes... :)
[15:18] <jcristau> doesn't that even out?
[15:19] <pitti> slangasek: yes, see bug 263245 and the upstream bug I created for that (linked from there)
[15:19] <pitti> jcristau: if it would be that easy...
[15:19] <slangasek> pitti: ok - in that case I don't need to test anymore, I can just send you the patch
[15:19] <slangasek> after I take care of a few other things first
[15:20] <slangasek> like the beta
[15:20] <slangasek> :-)
[15:20] <pitti> slangasek: I noticed a lot of other crashes which are not really "obvious"; I wonder if a double close() can cause memory corruption which wreaks havoc in the process later on
[15:20] <pitti> slangasek: details :)
[15:20] <slangasek> what's the package for the CD bootloader? syslinux?
[15:24] <pitti> slangasek: I think so, yes
[15:25] <pitti> seb128, tedg: I just added a stanza about the logout applet to https://wiki.ubuntu.com/IntrepidReleaseNotes; can you please take a look at it that I described the situation correctly?
[15:25] <cjwatson> slangasek: which bit of it?
[15:25] <cjwatson> slangasek: the UI is gfxboot-theme-ubuntu + gfxboot
[15:25] <slangasek> cjwatson: the bit for bug #277033 :)
[15:25] <slangasek> so possibly should be gfxboot instead
[15:26] <cjwatson> god, could be anything
[15:26] <slangasek> ok :-)
[15:26] <slangasek> (but not grub!)
[15:29] <tedg> pitti: Looks good.
[15:30] <jdstrand> asac: for giggles, I looked in /sys/module/ipw2200/parameters/associate on hardy, and it is on by default as well
[15:31] <jdstrand> which actually may explains a few things about wireless on that system...
[15:32] <seb128> pitti: looks good to me, I just commented on the bug to list what I think are the options we have for upgrades
[15:37] <slytherin> I am seeing this error when using latest alternate CD image (which I suppose is for beta) with apt-get. - W: Failed to fetch file:///media/ubuntucd/ubuntu/dists/intrepid/Release  Unable to find expected entry  main/binary-i386/Packages in Meta-index file (malformed Release file?)
[15:38] <slangasek> error, or warning?
[15:38] <cjwatson> slytherin: known bug
[15:38] <slangasek> W: - warning
[15:38] <slytherin> oops, warning
[15:38] <cjwatson> it's non-fatal
[15:38] <slytherin> cjwatson: non-fatal in what sense? Will users be able to install using alternate CD?
[15:38] <cjwatson> yes
[15:39] <cjwatson> it's bug 276349
[15:39] <slytherin> Ok. Then why doesn't upgrade work. I am already using intrepid and was trying to upgrade it with this image.
[15:40] <cjwatson> upgrade is a different matter, I suspect
[15:40] <cjwatson> mvo: ^-
[15:40] <slytherin> cjwatson: The bug says upgrade works but does not specify which upgrade path. Let me try once ahain.
[15:41] <mvo> slytherin: in what way does it not work? did you added file urls manually to the sources.list (instead of using apt-cdrom add)?
[15:41] <mvo> slytherin: if so, please try using "apt-cdrom add"
[15:41] <slytherin> mvo: I am not using CD. I am using image. So yes I have added file:// url.
[15:42] <superm1> slangasek, pitti i just tested the mythbuntu alternate generated last night.  appears to work properly now
[15:42] <pitti> superm1: "last night" as in "the ping I sent you 7 hours ago"?
[15:42] <mvo> slytherin: aha, thanks. could you please add this use-case and the failure to the bugreport. I think this is going to be difficult (or even impossible) to fix
[15:42] <pitti> superm1: great to hear, thanks for testing
[15:43] <mvo> (this == this use case)
[15:43] <superm1> pitti, yeah after the ping you sent me
[15:43] <slytherin> mvo: will do.
[15:43] <mvo> slytherin: thanks!
[15:43] <mvo> cjwatson: then can of worms grew another head :/ how bad would it be to re-add the uncompressed files?
[15:43] <mvo> s/then/the/
[15:44] <cjwatson> mvo: find me 2MB? :-P
[15:45] <cjwatson> or whatever it was
[15:45] <superm1> slangasek, for release notes, can you just add a pointer to http://mythbuntu.org/8.10/beta ?  We'll be opening that page up as soon as our live disk makes it to mirrors
[15:45] <cjwatson> mvo: I guess we can if it's really too bad, but I want commitment that we're going to be able to do this at some point in the future
[15:45] <cjwatson> because sources of megabytes on the CD are like gold dust
[15:46] <mvo> cjwatson: right, I absolutely agree, I will look hard into it before making a call
[15:46] <mvo> cjwatson: its just that its quite a few problems (and the file:/// uri one might be a really difficult one)
[15:46] <asac> jdstrand: yeah. the reason why the race isnt that bad on hardy is that i have a hack that enforces the essid
[15:46] <mvo> (also its a unusual use-case)
[15:47] <jdstrand> asac: interesting-- it's only very occassionally that my wife's laptop has problems associating-- I'm gonna try associate=0 there too
[15:47] <cjwatson> mvo: hmm, interesting. Why is file:// different? I had expected it to work the same kind of way as http://
[15:47] <asac> jdstrand: yes do that
[15:48] <asac> jdstrand: the hack doesnt help in all cases. just was added so that you can connect more regularly
[15:48] <slangasek> mvo: talk to the GNOME uploaders if you want the space back... :)
[15:49] <mvo> cjwatson: it does, there we have the (uncompressed) Packages file in the Release file (but on the CD we don't)
[15:50] <cjwatson> right, so can we fix the bug that means we can't put the uncompressed file's information in the Release file?
[15:50] <mvo> cjwatson: it may be easier to re-add the uncompressed Packages file to Release file info again in debain-cd and add code in update-manager that deals with that (+ a backport of apt so that people on hardy can still use apt-cdrom add)
[15:51] <cjwatson> mvo: apt/hardy-updates ...
[15:51] <mvo> cjwatson: yes, that is pretty straightforward and might be the best option
[15:51] <mvo> (where backport just means backporting the small fix)
[15:59] <slangasek> superm1: link added; you don't want to give me a one-liner blurb in addition?
[16:00] <mvo> cjwatson: thanks, I outlined a plan in the bug
[16:06] <slangasek> persia: did you have any thoughts on what we should highlight for UbuntuStudio 8.10 in https://wiki.ubuntu.com/IntrepidIbex/BetaAnnouncement ?
[16:06] <slangasek> or even a link to a page?
[16:07] <persia> _MMA_ was discussing that earlier, and some target language was mentioned.  Let me see if I can track down a link or anything.
[16:08] <superm1> slangasek, na, there's nothing big and exciting in the alternates, just bug fixes
[16:08] <stgraber> ogra-maemo, ogra: http://paste.ubuntu.com/53211/
[16:10] <ogra-maemo> stgraber, uuh
[16:10] <ogra-maemo> did you use --copy-sourceslist there ?
[16:10] <stgraber> ogra-maemo: that's d-i
[16:10] <stgraber> when selecting the LTSP option on Beta candidate cdimage
[16:11] <ogra-maemo> hmm
[16:12] <ogra-maemo> stgraber, are the files mentioned there in the right places ?
[16:13] <stgraber> nope, only Packages.gz is there
[16:13] <stgraber> no Packages
[16:16] <ogra-maemo> sounds to me like the cd is broken
[16:17] <philn> hi
[16:17] <cjwatson> ogra-maemo,stgraber: see the above discussion with mvo; removing Packages (uncompressed) was deliberate
[16:17] <philn> can someone please review #276107 ?
[16:17] <cjwatson> but turns out it needs some more apt work
[16:17] <cjwatson> philn: please mention what it's about, otherwise every developer has to look in order to find out :)
[16:17] <philn> cjwatson: it's a MIR for cssutils
[16:17] <cjwatson> philn: it already has the ubuntu-mir team subscribed; it is in the queue
[16:18] <philn> okay
[16:19] <kirkland> bryce: ideas?  glxinfo says:
[16:19] <kirkland> Xlib:  extension "GLX" missing on display ":0.0".
[16:19] <kirkland> Segmentation fault (core dumped)
[16:20] <kirkland> bryce: xorg-less, intrepid on a thinkpad x61
[16:20] <ogra-maemo> cjwatson, any option we could use as workaround ?
[16:22] <cjwatson> ogra-maemo: with the current images, I don't think so, although mvo might have an idea
[16:23] <ogra-maemo> mvo, ??
[16:23]  * ogra-maemo wonders why this foldable keyboard doesnt have an alt key ... tsk, they put a windows key on it, even altgr ...
[16:24] <ion_> ogra: Make caps lock a control and make the control an alt.
[16:25] <ogra-maemo> ion, yeah, i indeed can remap, i just wonder what the heck the manufacturer was smoking
[16:25] <ion_> Heh
[16:25] <ogra-maemo> it has keys for pond, yen and internet explorer, but no alt
[16:26] <ion_> :-D
[16:26] <henux> How or where can I find a mentor for me?
[16:27] <henux> There is an Ubuntu wiki page about becomming a mentor
[16:27] <norsetto> henux: https://wiki.ubuntu.com/MOTU/Mentoring (and this is the wrong channel to ask, use #ubuntu-motu pls.)
[16:27] <persia> slangasek: Beta Announcement updated.  Not much to say, and the language previously discussed was far too much spin in the context of the real improvements to some flavours.
[16:27] <henux> norsetto: point taken
[16:27] <ogra-maemo> stgraber, i guess you see the same on i386 ?
[16:28] <slangasek> persia: ok.  That does seem rather bland; you have the option of not having an explicit US mention at all there, if you prefer
[16:31] <persia> slangasek: I think it's better to have a mention.  While many users aren't going to be very excited because of the regressions (no -rt), and lack of new stuff (no ffado, not much more LASH, missing some targeted applications), others will find it useful (audacity works now).
[16:34] <mvo> ogra-maemo: is lts the issue?
[16:35] <mvo> ogra-maemo: the only workaround that may work is --allow-unauthenticated
[16:36] <ogra-maemo> mvo, that would ignore a missing Packages file ?
[16:36] <stgraber> ogra-maemo: I'd think so yes
[16:38] <mvo> ogra-maemo: the error comes from the release file
[16:38] <norsetto> tseliot: will the -qt gui drag in the whole kde desktop?
[16:39] <tseliot> norsetto: ???
[16:39] <tseliot> care to explain?
[16:39] <mvo> ogra-maemo: it should DTRT when it finds a compressed file and uncompres it into var/lib/apt/lists
[16:39] <norsetto> tseliot: what does it depends on? What qt/kde libraries will it drag?
[16:40] <tseliot> norsetto: python-kde and the oxygen icons
[16:40] <norsetto> tseliot: there is no python-kde package?
[16:41] <tseliot> norsetto: python-kde4
[16:42] <norsetto> tseliot: did you see what that depends on?
[16:42] <tseliot> norsetto: yes, but there's nothing I can do about it
[16:43] <norsetto> tseliot: so, if you make the -gtk gui install the -qt gui, somebody on gnome will see almost the whole kde desktop installed on his machine
[16:43] <norsetto> tseliot: of course you can, don't impose it, leave it as a choice to the user
[16:43] <tseliot> norsetto: the gtk package is a transitional package because I don't have the time to finish the GTK ui
[16:44] <norsetto> tseliot: I inderstand, but don't let it point to the qt one
[16:44] <tseliot> norsetto: a choice between what?
[16:44] <norsetto> tseliot: between not having a gui or installing the -qt one
[16:44] <ogra-maemo> mvo, will that be fixed after beta _
[16:44] <ogra-maemo> ?
[16:45] <tseliot> norsetto: currently the gtk ui crashes and doesn't start at all
[16:45] <norsetto> tseliot: I understand, and thats not my point, my point is that you are forcing somebody who is upgrading from hardy to install tons of libraries, not even informing him about it
[16:46] <tseliot> norsetto: envyng-core (the textual interface) can still be installed without having to download any dependency on kde
[16:46] <tseliot> norsetto: shall I remove the gtk version?
[16:46] <tseliot> and maybe add it back in Jaunty?
[16:47] <norsetto> tseliot: personally, between forcing the -qt one and removing I'd rather remove it, yes
[16:48] <norsetto> tseliot: if somebody still wants a gui he/she can install (but its their choice) the -qt one
[16:48] <tseliot> norsetto: ok, ScottK was dealing with the bug report. Can you remove the gtk package from the archive and update the rest, please?
[16:48] <norsetto> tseliot: that bug report is not approved, nothing has been uploaded
[16:49] <tseliot> ah, ok
[16:54] <ScottK> tseliot: Once there is an upload that doesn't build the gtk package it'll be NBS and removed semi-automatically.
[16:56] <cody-somerville> Can an archive admin push exo through?
[16:57] <tseliot> ScottK: ok, thanks for the information
[16:58] <Riddell> cody-somerville: is it important for beta?
[16:58] <cody-somerville> Its a universe package
[16:59] <slangasek> cody-somerville: that's not an answer, plenty of xubuntu stuff is universe packages ;)
[17:00] <cody-somerville> hehe
[17:00] <cody-somerville> Its not reroll worthy material, if thats the question
[17:02]  * davmor2 puts down the big hammer.  Doesn't need to hit cody-somerville with it any more
[17:09] <lool> ogra-maemo: Re: gvfs not handling obex:// do you have gvfs-backends?
[17:09] <lool> I was pretty sure it was supported
[17:12] <superm1> ogra-maemo, lool especially since we had to patch gvfs for the bluez 4.x support....
[17:14] <seb128_> superm1: there is a patch for the new bluez in the upstream gvfs svn
[17:14] <cody-somerville> slangasek, charlie-tca is owning Xubuntu release notes
[17:14] <cody-somerville> (for this beta)
[17:14] <slangasek> cody-somerville: ok
[17:14] <superm1> seb128_, i would suspect it's pretty similar to what we put together.  do you have a link?
[17:15] <seb128_> superm1: http://svn.gnome.org/viewvc/gvfs?view=revision&revision=2035
[17:16] <ogra-maemo> lool, i was only talking about the existing situation
[17:16] <ogra-maemo> there we definately dont have it
[17:16] <seb128_> superm1: it's quite some change, it's a shame if you duplicated the work rather than looking upstream if they worked on the upgrade
[17:17] <superm1> seb128_, well per the date on that, our work was done before it landed upstream
[17:17] <seb128_> superm1: it was in bugzilla for a while before being pushed to svn
[17:17] <superm1> seb128_, i'll update the gvfs package to their patch and test it then
[17:17] <seb128_> superm1: the patch is coming from fedora, I guess they are using it
[17:18] <superm1> seb128_, it's likely very close to what we have then too.  ours was initially based off the one in fedora
[17:18] <superm1> ill look
[17:21] <pitti> superm1: hi
[17:21] <superm1> hi pitti
[17:21] <pitti> superm1: did you check whether your wifi card matches any of the modaliases of b43/b43legacy?
[17:21] <jg> hi superm1
[17:21] <superm1> pitti, there's no reason it should have stopped matching... it did match in hardy just fine
[17:22] <superm1> i'll double check though
[17:22] <superm1> hi jg
[17:22] <jg> did you see the powertop bug I filed?
[17:22] <superm1> jg, yeah i saw it pass by bug mail at some point
[17:28] <lool> pitti: Re: debian #500916 urgh!  are many packages providing these?
[17:28] <lool> pitti: We could quickly add some touch calls in the postinst to update the timestamps
[17:29] <pitti> lool: I don't know how many do; I don't expect more than five, though
[17:29] <lool> Or just rm the cache in these postinst
[17:29] <lool> pitti: That sounds like a not too hard transition
[17:30] <pitti> lool: rm the cache, or call the fdi cache builder, yes
[17:30] <pitti> lool: the patch I sent is a quickfix which people should immediately get after teh 8.10 beta announcement, that's why I uploaded it already
[17:31] <pitti> lool: I know it's not the best, but we can revert it safely, and at least it won't totally break X.org input on upgrade
[17:31] <lool> pitti: Sure, I think it was the best short term thing to do
[17:32] <lool> I'm looking at other options because I wouldn't want us to regress on startup time of hal
[17:32] <lool> It's needed to start Xorg, so really on the critical path to login screen or desktop
[17:33] <pitti> lool: right, I'm happy with getting a better solution in by hardy final
[17:33] <lool> *intrepid  ;)
[17:35] <genii> Does pastebinit use some hardcoded url or so? If so anyplace to easily change it. I'm currently getting http://error.000webhost.com/not_found.html                as the return url
[17:36] <mvo> ogra-maemo: yes, one way or the other
[17:37] <superm1> BenC, pitti and I were discussing some things about wl vs b43.  how come b43 "succeeds" to load and stays loaded even if firmware isn't found?
[17:37] <superm1> BenC, it would really seem to make more sense to have it leave it's message in dmesg and then unload itself
[17:37] <genii> nvm man pastebinit shows syntax to change default site
[17:53] <kees> pitti: hi!  what's let to get the hardy-proposed kernel out the door?  It's (kind of) blocking security publications
[17:53] <pitti> kees: slangasek needs to accept my jockey SRU to enable configuration for the new 'wl' module, then superm to verify it
[17:54] <pitti> kees: I was asked to not move -21 to -updates until we have the wl configuration module as well (by the kernel team)
[17:54] <slangasek> and what about verification of the other SRU bugs?
[17:56] <pitti> haven't checked recently, so far rtg told me that it looked good now
[17:57] <liw> "incomplete" is such a badly named bug state
[17:57] <superm1> well the LBM that accompanies it needs to be uploaded still
[17:57] <superm1> the one there breaks things
[17:57] <superm1> rtg has had some issues with uploading the new one as i understand
[18:00] <liw> calling it "needs more information" would be more descriptive and less insulting of the bug reporter's efforts to make a good report
[18:00] <sbeattie> slangasek: I couldn't reproduce bug 104837 or bug 221351, and don't have enough ram for bug 257293
[18:01] <sbeattie> slangasek: for bug 236699, I'm concerned that there's a second fix that also needs to be applied; I left a comment to that effect.
[18:02] <sbeattie> kees: got any ideas on what to test for with bug 246663
[18:02] <slangasek> sbeattie: does 236699 regress any, without the additional fix?
[18:03] <kees> sbeattie: not really.  All I know is that the original fix broke VMWare somehow, but I think -proposed contains the fix for that too.
[18:04] <kees> 17:03 < kees> sbeattie: not really.  All I know is that the original fix broke VMWare somehow, but I think -proposed contains the fix for that too.
[18:04] <kees> smb_tp: ^^ is that right?
[18:06] <sbeattie> hmm, well, vmware is working here.
[18:06] <smb_tp> kees, I only got the last. But I guess it is about the one thing I have to have a closer look. The first change was there IIRC but the fix for VMWARE I am not sure
[18:06] <kees> smb_tp: okay.  if it turns out it's needed, we can include it in the -security build maybe?  sounds like normal vmware is okay
[18:06] <smb_tp> kees, Maybe it was fixed by other (later) changes.
[18:06]  * kees nods
[18:07] <kees> okay, so, it sounds like rtg is needed to sort ouf the lrm upload?
[18:07] <kees> s/ouf/out/
[18:08] <smb_tp> kees, might be. I think he was last one touching it
[18:08] <superm1> asac, what is the actual purpose of the "Create wireless network" option in NM 0.7?
[18:09] <sbeattie> slangasek: re 236699 I don't know, I just happened to come across the added fix while googling to understand the original fix and how I might test it.
[18:11] <pitti> superm1: at least in previous versions it was for setting up an ad-hoc network (has never really worked for me, though)
[18:11] <kees> 16:57 < superm1> rtg has had some issues with uploading the new one as i understand
[18:11] <kees> rtg: where "new one" was LRM
[18:11] <kees> rtg: which is required for wl, and jockey
[18:11] <kees> I'm lost.  :)
[18:11] <sbeattie> slangasek: actually, re-reading http://lkml.org/lkml/2008/5/13/392 I think the first fix for bug 236699 does introduce a regression for reinjected larger ipv6 packets.
[18:11] <rtg> nope, new one was LBM
[18:12] <kees> rtg: oh! sorry, lBm
[18:12] <rtg> I have a build issue with LBM that I need to figure out. It fixes symbol collisions with LRM
[18:12] <sbeattie> the referenced git commit (e2b58a67) is the one that is being applied in 236699
[18:12] <superm1> pitti, thats what I thought too, but I have never seen it work either.  I wasn't really sure how it was supposed to work anyhow though if you weren't running a dhcp server on the network you created
[18:13] <kees> rtg: okay, do you have any kind of ETA?  I'd love to get the -proposed kernel out today or monday so smb_tp and I can focus on getting the -security kernels built next week for hopefully a publication on the 16th
[18:14] <sbeattie> but I have no idea how to actually prove that it does or doesn't introduce that regression, not being particularly ipv6 netfilter injection knowledgable.
[18:14] <rtg> kees: its next on my todo list
[18:14] <kees> rtg: \m/  very cool, thanks muchly :)
[18:18] <pitti> kees: \m/ ???
[18:18] <pitti> you have weird ears :)
[18:19] <jdstrand> pitti: does this help:
[18:19] <jdstrand> \m/ *rock* \m/
[18:20]  * pitti squeezes his eyes to interpret the m, knowing only \o/
[18:20] <jdstrand> pitti: think back to the 80's, and headbanging
[18:20] <seb128_> doing a work break now bbl
[18:20] <pitti> ah :)
[18:21] <jdstrand> \m/ <head goes up and down to beat of awesome tune> \m/
[18:21] <jdstrand> :)
[18:21] <slangasek> sbeattie: --> verification-failed, then?
[18:22] <superm1> rtg, perhaps in BenC's absence, can you try to field the question that pitti and I were posing about b43/wl?   how come b43 "succeeds" to load and stays loaded even if firmware isn't found? it would really seem to make more sense to have it leave it's message in dmesg and then unload itself, and that would mean that wl could take over at that point.
[18:22] <pitti> ogra-maemo: can you please forward 10-samsung-Q1-keymap.patch upstream? seems you have the hardware, and you applied the patch
[18:23] <rtg> superm1: its because SSB has already claimed the PCI ID.
[18:23] <superm1> rtg, but why is SSB claiming it if nothing is being done with it?
[18:23] <superm1> moreover - why is ssb still loaded then?
[18:23] <rtg> superm1: thats something else we need from Broadcom, e.g., get them to play nicer with upstream.
[18:23] <ogra-maemo> pitti, sigh, yes, i dont want the same flaming from dannyk again i had when i asked for evtouch fdi inclusion
[18:23] <superm1> right, but why is upstream doing it this way in the first place?
[18:24] <ogra-maemo> pitti, i dont think he will like the layout
[18:24] <superm1> it just causes spam messages up and down dmesg about how you don't have firmware, you don't have firmware
[18:24] <rtg> superm1: SSB believes deep in its heart that it owns all PCI devices connected to its PCI interface.
[18:24] <ogra-maemo> its specific to mobile/mid
[18:25] <pitti> ogra-maemo: well, I'd say that *everything* in hal-info is specific to particular hardware :)
[18:25] <superm1> rtg, pitti is that how other firmware loading drivers operate too though?
[18:25] <rtg> superm1: SSB is a mezanine bus driver that arbitrates access to SSB based devices, such as b44 and b43.
[18:26] <rtg> superm1: those are the on;y devices that I know of so far.
[18:32] <superm1> rtg, right but it's only fair to question if that model is correct about upstream's take on this, has this discussion been challenged to them in the past?
[18:33] <rtg> superm1: dunno. it happened a couple of years ago IIRC, and I don't see it changing any time soon just to accommodate a binary driver.
[18:34] <bryce> kirkland: I see you mentioned an xorg problem earlier, but didn't give details... lp#?
[18:35] <kirkland> bryce: hadn't filed one yet, taking a pulse if this is a new issue
[18:35] <kirkland> bryce: i switched to my wife's x61 (again)
[18:35] <kirkland> bryce: xorg-less worked well for me this time :-)
[18:36] <kirkland> bryce: was trying to 3d acceleration working right
[18:39] <bryce> kirkland: well, it's sort of a generic error - mesa failed for some reason, GLX didn't initialize, and the 3D apps could run
[18:40] <bryce> kirkland: Xorg.0.log might tell you what the failure was
[18:41] <kirkland> bryce: cool, thanks, i'll dig a bit deeper when i get a chance
[18:42] <bryce> ok cool
[18:43] <bryce> kirkland: btw, if you file a bug via `ubuntu-bug mesa` it should attach all the necessary files automatically
[18:46] <kirkland> bryce: okay, I'm an idiot...
[18:46] <kirkland> bryce: it seems i had to reboot (or at the very least restart X) after I uninstalled all of the nvidia extensions
[18:47] <kirkland> bryce: now, 3d (compiz) seems to be working correctly
[18:50] <kirkland> cjwatson: i added some basic, sticky support for browsing/searching manpages.ubuntu.com for other languages
[18:51] <kirkland> cjwatson: in doing so, i looked a bit closer at some of the "language" directories where some manpages get installed
[18:51] <kirkland> cjwatson: funnily, "py" and "sh"  :-)
[18:51] <kirkland> cjwatson: http://manpages.ubuntu.com/manpages/intrepid/
[19:00] <bryce> kirkland: gotcha
[19:00] <kirkland> bryce: my bad ;-)
[19:43] <tedg> pedro_, bdmurray: Could you guys try gpm-2.24.0-0ubuntu4~ppa2 in PPA to see if it fixes your respective bugs?
[19:44] <tedg> cody-somerville: Could you try ^ to ensure that it doesn't break Xubuntu?  You guys use your own session manager, right?
[19:44] <cody-somerville> tedg, yup
[19:44] <pedro_> tedg: yep
[19:44] <cody-somerville> what ppa? :P
[19:45] <tedg> cody-somerville: Okay, well the patch changes GPM from using XSMP to trying GSM's DBus protocol and then falling back.  Should work...
[19:45] <tedg> http://launchpad.net/~ted-gould/+archive
[19:45] <tedg> Oh, wait, hasn't finished building yet..
[19:45] <kirkland> DktrKranz: hey, i was trying to fix a trivial manpage bug in kmediafactory, but I can't get it to build for intrepid, depends on libdvdread3-dev, which doesn't exist
[19:46] <tedg> Sorry, getting ahead of myself.
[19:46] <kirkland> DktrKranz: -> #ubuntu-motu
[19:47] <mvo> is someone here who has a interesst in the ghc6 packages?
[19:48] <cody-somerville> mvo, I did a merge once
[19:48]  * Laney does too
[19:49] <cody-somerville> sistpoty loves ghc6
[19:49] <mvo> excellent, I noticed a hardy -> intrepid upgrade issue that is caused by the way the ghc-pkg script is run
[19:49] <mvo> I will file a bug with all details
[19:49] <mvo> I was just not sure how many ghc6 users we actually have :)
[19:50] <pedro_> brb
[19:54] <pedro_> tedg: yes it does fixes it, it now display the right dialog ;-), thanks you!
[19:56] <tedg> pedro_: Cool, let's see if it break Xubuntu now :)
[20:19] <cody-somerville> Can someone please push exo through? I already have another upload to sponsor for that package :P
[20:36] <TheMuso> slangasek: I am reliably able to reproduce that audio bug on another box here. Its a race purely because everything gets loaded at once, without any clear delay for one thing to wait for another. Thats the impression I get anyway.
[20:37] <ogra> superm1, i cant get your ppa packages installed, bluez-audio removes everythig
[20:39] <persia> ogra: What's the dpkg error?
[20:39] <ogra> well, one package just removes the other
[20:39] <ogra> no errors
[20:39] <ogra> installing bluez-audio removes all other bluez packages
[20:40]  * persia looks at the branch, suspecting the versioned conflicts have an issue
[20:41] <ogra> installing bluez-utils pulls in bluetooth, bluez, bluez-alsa ad bluez-gstreamer but removes bluez-audio
[20:41] <ogra> beyond that bluetoothd is constantly crasing after the first click on the applet
[20:42] <ogra> installing them results in a ton of mknod errors
[20:42] <slangasek> I thought bluez-audio was supposed to go away along with bluez-network and bluez-serial
[20:42] <ogra> well, its in the ppa
[20:43] <ogra> the instructions from marios mail left me with a half installed BT stack
[20:43] <ogra> i.e. apt-get upgrade doesnt work since it needs to remove parts
[20:44]  * ogra is more worried bout the about 100 lines of mknod cannot create blah, mkdev blah failed
[20:45] <ogra> the applet lets me open the "add device" dialog and then crashes immediately
[20:46]  * ogra reboots the device
[20:49] <ogra> no, no go
[20:49] <ogra> persia, is there a list anywhere of the packages i actually need installed ?
[20:49] <persia> ogra: If you enable the PPA, and upgrade an existing system, it should pick the set of packages that's right for you.
[20:50] <persia> RIght.  bluez-audio was dropped.  Now there is bluez-alsa and bluez-gstreamer.
[20:50] <persia> Not having bluez-audio is fine.
[20:50]  * norsetto has the bluez
[20:51] <persia> norsetto: 3.x or 4.x?
[20:51] <norsetto> 46.x ...
[20:53] <sebner> norsetto: where is your harmonica? :)
[20:53] <TheMuso> lol
[20:53] <norsetto> ah TheMuso is alive!
[20:54] <TheMuso> Yes, but I am not normally around at this time.
[20:54]  * norsetto wonders if he can ask TheMuso about his dmraid problem
[20:54] <TheMuso> norsetto: Sure.
[20:55] <norsetto> TheMuso: well, I can't boot into intrepid, I get thrown to a busybox prompt with the error: can't find the raid partition
[20:56] <norsetto> TheMuso: if I give dmraid -ay in the busybox it continues but hen it fails becauise the fs is mounted readonly
[20:56] <TheMuso> norsetto: Ok, to get passed that, run the command "dmraid -ay" then press Control + D to exit the prompt. Once you are booted, I can work with you to work out the problem/
[20:56] <TheMuso> norsetto: ah ok.
[20:56] <ogra-Q1> bluetoothd[5239]: segfault at 0 ip b7dfe2c3 sp bfa4ad1c error 4 in libc-2.8.90.so[b7d87000+158000]
[20:56] <TheMuso> norsetto: Can I ask when this system was installed?
[20:56] <ogra-Q1> persia, ^^^
[20:57] <norsetto> TheMuso: hmmm, long ago, it went from Gutsy->Hardy->Intrepid
[20:57] <persia> ogra: Cool!  Can I have a stacktrace with symbols?
[20:57] <ogra-Q1> meh
[20:57] <TheMuso> norsetto: Right...
[20:57] <ogra-Q1> why alsways me
[20:58] <norsetto> TheMuso: It was working fine with intrepid but after some update it stopped (about, hmmm, 2 months ago or similar)
[20:58] <TheMuso> norsetto: If the system is not critical, I suggest installing with the latest alternate CD, and checking to see if the problem remains. If so, then we have more debugging work to do.
[20:58] <TheMuso> As there have been a lot of dmraid fixes since then.
[20:58] <norsetto> TheMuso: well, thats anoter problem, my cd-rom writer is not recognised by the kernel
[20:59] <ScottK> norsetto: Perhaps try with a live cd to see if the newer kernel sees it?
[20:59] <TheMuso> norsetto: ah lovely. Ok. This is interesting.
[20:59] <norsetto> TheMuso: its not critical, I'm happy to use it as a chroot, but I need to boot to check another bug for bryce
[20:59] <TheMuso> norsetto: Right.
[21:00] <TheMuso> norsetto: What I don't understand is why it halts because the fs is read only. The root fs is always mounted read-only at first.
[21:00] <norsetto> ScottK: right, and how do I burn that cd :-)
[21:01] <ScottK> Ah.  Good point.  I'd assumed from your other working system.
[21:01] <ogra> persia, starting it manually makes it survive
[21:01] <persia> ogra: OK.  How did you break it?
[21:01] <ogra> no idea
[21:02] <ogra> but /etc/init.d/bluetooth start made it
[21:02] <ogra> work
[21:02] <ogra> err
[21:02] <ogra> no not really
[21:02] <persia> OK.  I'm calling this UNREPRODUCIBLE.  If you can reproduce it, I want a stacktrace, and I'll fix it.
[21:02] <ogra> it crashed again now, but before it paired successfully with my freedom kbd
[21:03] <TheMuso> norsetto: Oh BTW, what raid setup is it, i.e is it raid0, raid1, etc.
[21:03] <persia> ogra: Very odd.  It was working fine for me on last test cycle.
[21:04] <norsetto> TheMuso: raid 0
[21:04] <TheMuso> norsetto: Ok. Could you boot the system, and when you get to the busybox prompt, cat /proc/modules and tell me if dm_mod is loaded?
[21:04] <TheMuso> As well as any other errors you get related to raid?
[21:05] <norsetto> ok, have to reboot then ... be back soon
[21:05] <ogra> ok, it works with my phone
[21:05] <ogra> persia,
[21:05] <ogra> i can browse files
[21:05] <ogra> it crashes with the gps reciever
[21:05] <ogra> and the keyboard doesnt work, though it connects
[21:05] <persia> ogra: Does your GPS receiver work with 3.x ?
[21:05] <ogra> no
[21:05] <persia> For the keyboard, wait about 30 seconds after connecting.
[21:05] <persia> OK.  Not a regression then.
[21:05] <ogra> nothing worked with 3.x
[21:06] <persia> I could browse my phone with 3.x.  Not transfer anything, but browse.
[21:08] <ogra> the icons in the device dialog are quite meaningless
[21:08] <ogra> what does the star mean ?
[21:08] <ogra> and is the plug a connect or a disconnect ?
[21:08] <slangasek> superm1: care to unblock the mythbuntu beta page?
[21:09] <persia> ogra: The plug is disconnect.  The star is trust.
[21:09] <Nafallo> zo/
[21:09] <ogra> ok
[21:09] <Nafallo> MEEH! FAIL!
[21:09] <Nafallo> \o/
[21:10] <persia> Nafallo: Are you sure it wasn't a combination of salutes from several places?
[21:10] <ogra> persia, so it immediately crashes if i switch the kbd to SPP mode
[21:10] <ogra> in HID it connects but doesnt work
[21:10] <Nafallo> persia: not even sure what you mean, so no :-P
[21:11] <persia> Hmm.  I didn't test SPP.  HID should work, but you may have to trust the keyboard (the star).
[21:11] <persia> For the crash, I need a stack trace.
[21:13] <ogra> right, but not today anymore
[21:13] <ogra> really, i'm done
[21:13] <norsetto> TheMuso: yes, all dm_ modules are loaded (7 of them)
[21:14] <maix> hi, just one question: will python2.6/python3 appear in intrepid?
[21:14] <slangasek> python3 is in intrepid.
[21:14] <TheMuso> norsetto: Oh I'm sorry, I didn't realise thats the system you are using. So when it halts, how do you continue to boot?
[21:14] <TheMuso> as in, after you run dmraid -ay in initramfs
[21:14] <maix> oh ;)
[21:15] <norsetto> ctrl+D or exit
[21:15] <norsetto> TheMuso: ctrl+D or exit
[21:15] <maix> ok sry i just searched for 2.6 one the packages website
[21:15] <TheMuso> norsetto: And then it just works? Hrm.
[21:15] <maix> so 2.6 won't be in intrepid?
[21:15] <norsetto> TheMuso: well, it stops will the read-only fs error at one point
[21:16] <slangasek> maix: correct
[21:16] <TheMuso> norsetto: so how do you get through that?
[21:16] <maix> :(
[21:16] <norsetto> TheMuso: I don't
[21:16] <ogra> persia, but s far the onl device that doesnt make the daemon segfault is my phone, all others just cause the daemon to die immediately
[21:16] <TheMuso> norsetto: oh right.
[21:17] <TheMuso> norsetto: So am I right in guessing that the dmraid install is on the same machine you are usin now?
[21:17] <norsetto> TheMuso: indeed
[21:18] <TheMuso> norsetto: Ok thats somewhat helpful. Mind pastebinning your /etc/fstab?
[21:18] <ogra> persia, and i dont get why it wants me to input a PIN on the keyboard, there is no way to do such a thing
[21:18] <norsetto> TheMuso: for the partition I'm using right now or the one I'm trying to boot into?
[21:19] <TheMuso> norsetto: For the one you're trying to boot into. If you have dmraid installed on that install, you should just be able to mount the /dev/mapper device.
[21:19] <persia> ogra: Are you sure?  My keyboard allows PIN input using the number keys and the enter key.
[21:19] <ogra> my leyboard has a predefined 0000 PIN
[21:19] <norsetto> TheMuso: well, in one of the attempts I made to recover, I also deleted the whole fstab, have to see if I kept a backup
[21:19] <ogra> but bluez generates one for it
[21:20] <persia> Oh.  Bad keyboard.
[21:20] <TheMuso> norsetto: Ok.
[21:20] <ogra> bad bluez i'd say
[21:20] <ogra> kbd wrks fine on the n800
[21:20] <persia> Why?  hardcoded passwords are inherently insecure.
[21:20] <persia> Yes, but anyone can snoop your keystrokes.
[21:21] <persia> (and no, it's *not* hard to brute-force bluetooth, but that's not the point)
[21:21] <ogra> well, it tells me it is connected while it isnt
[21:22] <ogra> oh, this time it actually said it failed
[21:22] <norsetto> TheMuso: no backup, so, its empty right now; it used to be /dev/mapper/via_ceecdjfcj2 / ext3 defaults 0 1
[21:23] <TheMuso> norsetto: Ok thanks, I now know what dmraid metadata format you are using, which possibly explains the failure.
[21:23] <TheMuso> norsetto: Do you have dmraid installed on the install you are using now?
[21:23] <norsetto> TheMuso: yes
[21:24] <TheMuso> norsetto: Ok, if you could pastebin the output of "sudo dmraid -s" plesae
[21:24] <TheMuso> please
[21:25] <norsetto> TheMuso: http://ubuntu.pastebin.com/d461415f
[21:25] <pitti> slangasek: yay, congrats to the beta release!
[21:25] <slangasek> pitti: I believe I now owe you a consolekit patch :)
[21:26] <pitti> slangasek: no hurry, I'm about to go to bed, and won't be at home over the weekend anyway
[21:26] <slangasek> ok; then maybe I owe you a consolekit upload instead
[21:26] <TheMuso> norsetto: Ok, if you could also pastebin "sudo dmraid -n", and then create a temporary dir, go into it, and run "sudo dmraid -rD", tar the dir up, and email it to me, that would be great. That gives me a dump of your metadata so I can work things out more easily on my end.
[21:26] <pitti> slangasek: as you prefer; mailed patch is fine, too
[21:27] <TheMuso> norsetto: One more thing, how old is the motherboard?
[21:27] <norsetto> TheMuso: dmraid -n: http://ubuntu.pastebin.com/d51f11ef9
[21:27] <soren> What do I do if I want a package to be built by a different source package? Obviously, I just start building it in the new package, but will soyuz just let the binary package automatically replace the one built by the old source package?
[21:28] <slangasek> pitti: well, I would like *my* console-kit-daemon to stop crashing too, so I'll probably upload :-)
[21:28] <slangasek> pitti: where should I send the patch upstream?
[21:28] <norsetto> TheMuso: I think I bought it end 2004/beginning 2005
[21:28] <pitti> slangasek: I'm pretty sure I fixed your's with the upload which is sitting in unapproved
[21:28] <TheMuso> norsetto: ok.
[21:28] <slangasek> pitti: oh, right
[21:29] <pitti> slangasek: I sent mine to bugzilla.freedesktop.org, and it got committed within hours
[21:29] <slangasek> pitti: let me get that first, then :-)
[21:29] <pitti> slangasek: you should have some bug mail about bug 263245, with the link to upstream, and details
[21:29] <cjwatson> soren: yes, if the version is higher
[21:29] <cjwatson> soren: obviously please stop building it from the old one too
[21:30] <slangasek> pitti: right; fwiw, I tried the test you provided, and also couldn't reproduce the crash that way
[21:30] <soren> cjwatson: It's the only binary the old source package built, so I just file a removal request?
[21:30] <cjwatson> soren: yeah
[21:30] <soren> cjwatson: Great. Thanks.
[21:31] <pitti> slangasek: I never actually saw that crashing, apparently glibc uses the moon phase divided by the dollar conversion rate to decide whether it returns EBADFD or a segfault :/
[21:31] <pitti> slangasek: but the stack trace on the bug was pretty clear
[21:31] <norsetto> TheMuso<EMAIL_ADDRESS>?
[21:31] <TheMuso> norsetto: Thats fine, thanks.
[21:31] <pitti> slangasek: (on that bug and on all the gazillion dupes)
[21:31] <slangasek> pitti: heh
[21:32] <TheMuso> norsetto: Basically the problem is that dmraid used to use an init script for initramfs and latre in the boot to load everything, however I switched it to using udev. I'm guessing that udev's vol_id can't correctly identify your dmraid array, hense the droppign to an initramfs prompt.
[21:32] <pitti> slangasek: the fun thing is, that we don't even *have* logrotation for that history file (which is a bug of its own), so I don't see why the file should change underneath consolekit so often
[21:32] <slangasek> right
[21:32] <pitti> slangasek: but anyway, please give it a try and let me know
[21:32] <TheMuso> norsetto: So I am going to have to get vol_id to use dmraid somehow.
[21:32] <norsetto> TheMuso: I see, that could indeed explain it
[21:32] <TheMuso> norsetto: However, that doesn't explain the read-only fs error you get later in the boot.
[21:35] <TheMuso> norsetto: Thanks. I'll get back to you when I find something.
[21:35] <TheMuso> norsetto: Looks like I'll be able to test this metadata in a vm, which is useful.
[21:36] <norsetto> TheMuso: thanks Luke, you are GREAT!
[21:36] <TheMuso> norsetto: You're welcome.
[21:39] <psusi> TheMuso: ping
[21:40] <TheMuso> psusi: pong.
[21:41] <psusi> TheMuso: hey... I do a little work on dmraid sometimes and since it looks like the general trend these days is to move to bzr, and I noticed that you had imported dmraid into bzr, I decided to try to learn to use it for future work on the package, but now that I have it checked out, it only contains the debian/ directory
[21:41] <psusi> what gives?
[21:42] <TheMuso> psusi: Yes thats how many packages I've seen have their bzr packaging done. However, I kinda don't use it any more, because I just forgot to update it. As it is, I am now going to be working on the dmraid packaging for Ubuntu and debian on alioth. The plan is to do everything in debian, and sync the dmraid package. I co-maintain it with a prospective DD from debian.
[21:43] <psusi> ahh, I see
[21:44] <psusi> I thought the idea was for the lp bazzar repo to contain branches for each upstream release for easy merging back and forth with the current ubuntu code base which could then just be checked out and tarballed to make a package
[21:44] <psusi> which is why I was very confused to only see the contents of debian/ in the repo
[21:44] <TheMuso> psusi: Until we use bzr for all packages, everyone works differently.
[21:44] <TheMuso> as in, everyone uses bzr for packaging somewhat differently.
[21:45] <ogra> persia, the headset actually connects, uses the proper 0000 PIN, but fails to play any sound
[21:45] <psusi> hrm.... then in the future I guess I should go back to just hacking on the debian source package and attach the debdiff to the bug report?
[21:45] <persia> ogra: Using aplay -D ?
[21:45] <psusi> for dmraid that is
[21:46] <ogra> persia, yep, following the instrictions in superm1's mail
[21:46] <ogra> i think its not happy about the 44.1KHz
[21:46] <persia> Odd.  I'll admit to not getting my handset to play sound, but that's the same as what I had with 3.x
[21:47] <ogra> well, at least it airs and doesnt crash the daemon
[21:47] <persia> Honestly, the only improvement I see with 4.x over 3.x is the better interface, my keyboard works, and there's a bit more support for OBEX.
[21:47] <ogra> i even get a notification
[21:47]  * ogra wishes his kbd would work
[21:47] <persia> Yeah.  Not crashing the daemon is one of the big improvements between 3.x and 4.x :)
[21:47] <ogra> but the PIN generation definately prevents that
[21:47] <TheMuso> psusi: yeah sounds sane, or at least a diff against the latest svn. When things are going properly, I'll let you know where to find the svn.
[21:47] <ogra> and SPP just kills the app
[21:48] <persia> There must be some hint somewhere.  I'm annoyed that I don't get PIN generation for my handset, and have to use 0000.
[21:48] <psusi> TheMuso: ok
[21:48] <ogra> why the heck do you need a PIN there ? i have only seen PIN input at the host yet, never at the device
[21:48] <persia> Because I have buttons on it, and so I don't see the reason to not enter a PIN?
[21:49] <ogra> and how are you supposed to put in a PIN on a hedset ? morse it with the power key ?
[21:49] <persia> (It's a little phone for your phone, complete with it's own address book and microSD slot)
[21:49] <ogra> my headset is a headset
[21:49] <persia> Depends on the device.  Mine is a handset
[21:49] <ogra> it has three buttons
[21:49] <ogra> power, vol up and down
[21:49] <persia> for that, I can see hardcoding a PIN.
[21:49] <ogra> so how would i be supposed to type in a pin for it
[21:50] <persia> Anyway, the point being that I want to enter a PIN for both my handset and my keyboard, and you want to not enter a pin for your headset and your keyboard.
[21:50] <ogra> no, it *has* a hardcoded PIN builtin
[21:50] <ogra> but there is no way to type in the pin on the computer side
[21:50] <persia> Since the code sets 0000 for all audio, and NNNN for all keyboard, there must be a key somewhere we can hint.
[21:50] <ogra> same goes for my gps and my keyboard
[21:50] <ogra> they all have factory hardcoded PINS
[21:50] <ogra> and i cant type in a PIN in bluez anywhere
[21:51] <ogra> its the wrong way round is what i try to say
[21:51] <ogra> the only device where it makes sense is a phone
[21:51] <ogra> where you have a numbepad
[21:51] <ogra> *number
[21:53] <ogra> persia, oh, i didnt mention, there is a public holiday in germany tomorrow, i might be around less than normal
[21:54] <bryce> slangasek: do uploads need to get bumped in still, or is the queue just backed up?  I uploaded -ati this morning but seems to have not gone through yet?
[21:55] <persia> ogra: I'll just chalk it up to latency then.
[21:55] <ogra> no, i mean i didnt tell lool or davidm
[21:55] <ogra> in cae someone looks for me
[21:57] <davidm> what's up?
[22:00] <NCommander> persia, so, I'm a member of ~bluetooth now ;-). libpam-blue is fixed
[22:00] <persia> NCommander: Excellent news both.  Any of the rdepends still outstanding?
[22:01] <NCommander> persia, that was the lastone
[22:01] <NCommander> superm1 posted that they were doing beta testing, and then it would get dumped into the archive post BetaFreeze
[22:03] <persia> Well, it needs more test reports.  Do you have hardware?  Does it work for you?
[22:03] <NCommander> persia, I'll test it with my cell phone this weekend
[22:03]  * NCommander finds getting GSM DUN to work is like trying to pull teeth out of your skull
[22:03]  * TheMuso hopes to test with his phone, and some Braille displays this weekend.
[22:04] <NCommander> So I'll be testing OPP, voice gateway, and DUN/SPP
[22:04] <ogra> slangasek, hmm, if the freeze is lifted, could you let midbrowser out of its jail ? (i uploaded shortly before your announcement) ... i'd like to have it in tonights image
[22:05] <Ng> something changed very recently wrt thinkpad hotkeys, didn't it? mine stopped working today
[22:05] <persia> TheMuso: Would you mind also checking the Braille displays both with the intrepid stack, and with the intrepid stack + crevette's bluez-gnome 0.28?  If there's a regression with 4.x, I'm curious if there is also a regression with 0.28, which fixes some (but not all) of the issues.
[22:05] <Ng> hmm, ish, some are working that weren't, but at least one that was working, isn't
[22:06] <nxvl> Ng: on my T61 they work fine, which hotkey is not working for you?
[22:06] <TheMuso> persia: I intend to test with the current stack in intrepid, and then the stack in the ppa.
[22:06] <Ng> nxvl: Fn-F4 (suspend)
[22:06] <Ng> nxvl: I use it regularly, and this afternoon is the first time it's not worked
[22:06] <nxvl> i will need to suspend my machine
[22:06] <nxvl> ugh
[22:06] <nxvl> here we go
[22:06] <Ng> I don't seem to get anything in /var/log/acpid either for the last month or so
[22:07] <slangasek> bryce: the queue is not unblocked yet; I'm tying up lose ends and will flush the queue ASAP
[22:07] <ogra> Ng, are you sure uswsusp isnt installed ? its known to break suspend and friends
[22:07] <nxvl> working
[22:07] <ogra> and gets pulled in by a recommends at
[22:07] <ogra> m
[22:07] <Ng> ogra: I would never install uswsusp ;)
[22:08] <ogra> Ng, but gpm would ;)
[22:08] <persia> TheMuso: OK.  If you end up with extra time and could also test bluez-gnome (but not gnome-user-share) from https://launchpad.net/~bmillemathias/+archive in the case that 4.x has significant regressions, I'd appreciate it.  We've held back the update to 0.28 in anticipation of the 4.x transition, but we really need to update at least one of them (except I don't want to break things that work without updating)
[22:08] <nxvl> Ng: are you with intrepid already?
[22:08] <Ng> nxvl: yep, have been for a couple of months
[22:08] <NCommander> persia, anyway, I just installed the transition packages :-)
[22:08] <nxvl> yeah, it worked here on my T61
[22:08] <nxvl> with intrepid
[22:08] <TheMuso> persia: Sure, I'll make time. These displays aren't mine, but I will have access to them, so I will want to get as much good testing as possible.
[22:09]  * NCommander notes that this bluetooth transition really waited to the very end of the cycle ;-)
[22:10] <bryce> slangasek: ok cool
[22:10] <nxvl> wow it even suspended the KVM i was running
[22:10] <nxvl> that didn't happend in hardy
[22:10] <nxvl> \o/
[22:10] <persia> TheMuso: Thank you.
[22:11] <Ng> nxvl: hmm, thanks for checking that. i guess I need to dig around for whatever it was that changed
[22:12] <torkel> Ng: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/267682
[22:16] <Ng> torkel: nice, thanks
[22:17]  * calc sees the lwn article about 5s boot and wants that in 9.04 :)
[22:17] <superm1> ogra, that's correct, bluez-audio should be no longer there
[22:18] <superm1> ogra, it's replaced by bluez-alsa and bluez-gstreamer (fully intended)
[22:18] <ion_> calc: Mind sharing the URL for the lazy ones among us? :-)
[22:18] <calc> http://lwn.net/Articles/299483/
[22:18] <superm1> ogra, and apt-get upgrade should do the trick since bluez-utils depends on bluetooth which recommends bluez-alsa/gstreamer and conflicts bluez-audio
[22:18] <ion_> Thanks
[22:18] <calc> apparently they have the kernel boot bit down to 1s now and will be .5s for 2.6.28
[22:18] <slangasek> calc: the 5s boot was a kludge, it wasn't done with a generic kernel on arbitrary hardware
[22:19] <Nafallo> meeh. I was just about to suggest we move to 2.6.28 for the Ibex ;-)
[22:19] <calc> slangasek: true, though they mention that by including some modules in the kernel directly and subbing one with initrd for uncommon hardware it would work for most
[22:19] <superm1> slangasek, it will be unblocked after our mirrors are fully synced
[22:20] <slangasek> superm1: ok
[22:20] <calc> i'm still reading the article though so perhaps they did other cheats, not sure
[22:23] <superm1> ogra, the  trick is don't try to install bluez-audio now :)
[22:41] <superm1> NCommander, don't expect much out of voice gateway yet.
[22:42] <superm1> NCommander, and for DUN, you'll need to use rfcomm
[22:42] <NCommander> superm1, yes, I know, I've done rfcomm
[22:42] <NCommander> How's A2DP looking these days?
[22:42] <NCommander> (aka, still a **** to setup?
[22:42] <superm1> NCommander, well i've got a stereo headset that works pretty well
[22:43] <NCommander> Yeah, but its still tricky to get the headsets to work just right
[22:43] <superm1> the problem is that ALSA doesn't make virtual devices that can be offered to apps at the moment when queried
[22:43] <superm1> so the current experience is  this:
[22:43] <superm1> 1) Pair device through gui
[22:43] <superm1> 2) set app to use the device called "headset"
[22:43] <superm1> if you make an asoundrc you can redirect all output to this device
[22:44] <TheMuso> superm1: What needs to be done to correct this?
[22:44] <superm1> TheMuso, upstream is adding in a new framework for the rest of it
[22:44] <TheMuso> Unfortunately I don't have a headset, but I could try bluetooth from one computer to another and make an audio service available..
[22:44] <TheMuso> superm1: Right. Pulseaudio is also going to support bluetooth natively in a future version.
[22:44] <superm1> TheMuso, yeah there are three fronts for audio that need the improvement
[22:44] <superm1> pulseaudio is one of them
[22:44]  * TheMuso nods.
[22:45] <superm1> gstreamer and alsa both still need pieces to that framework too.
[22:48] <superm1> but nonetheless, this is still an improvement over the last set through
[22:49] <TheMuso> Agreed.
[22:52] <slangasek> superm1: "if you make an asoundrc" - that's improved then, last time I tried that I couldn't get things like ekiga to work with bluetooth even using an asoundrc
[22:53] <superm1> slangasek, i was able to get non mplayer, vlc, and myth to all handle it
[22:54] <superm1> slangasek, mplayer w/o the asoundrc too (it supports specifying device on command line)
[22:54] <slangasek> it's conceivable that ekiga is special :P
[22:54] <superm1> does it use gstreamer?
[22:54] <slangasek> no
[22:54] <superm1> oh hum.  i say special then too.
[23:00] <TheMuso> Can I assume that the bluetooth stack has an alsa plugin that it uses?
[23:01] <kirkland> superm1: hmm, regarding bluetooth....
[23:01] <superm1> TheMuso, yeah it does
[23:01] <superm1> TheMuso, part of the NEW bluez-alsa package
[23:02] <slangasek> TheMuso: yes; however, some apps run afoul of the fact that you can't enumerate bluetooth alsa devices
[23:03] <kirkland> superm1: i don't see my bluetooth device, on my laptop
[23:03] <kirkland> superm1: it doesn't appear in lspci or lshw
[23:04] <TheMuso> slangasek: Right. I wonder if thats the apps, or the plugin. This used to be a problem with the pulseaudio plugin.
[23:04] <superm1> kirkland, generally lsusb is where you'll see it
[23:04] <superm1> TheMuso, its a problem with the plugin right now
[23:04] <kirkland> superm1: ah, okay, Bus 001 Device 005: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
[23:04] <TheMuso> superm1: Right I thought as much.
[23:04] <superm1> their changes will allow it to be part of the enumerated device eventually, by creating virtual devices
[23:05] <slangasek> TheMuso: problem with the plugin that you can't enumerate outputs; problem with the apps that you can't manually specify an output...
[23:05] <TheMuso> slangasek: Right, I know ekiga is one of those culprets.
[23:05] <TheMuso> Unless thigns have changed this cycle.
[23:06] <slangasek> maybe it's changed in the ekiga ppa package :)
[23:09] <kirkland> superm1: i don't see any devices when i tell it to "Setup New Device"
[23:09] <TheMuso> superm1: I assume setting up an audio service on one machine, and making it available by bluetooth to another is a good way of testing?
[23:09] <superm1> TheMuso, depending on which direction the audio service is providing on the other machine sure
[23:09] <superm1> TheMuso, there are multiple audio services available
[23:09] <TheMuso> superm1: right
[23:10] <superm1> TheMuso, linux<->linux you won't get the correct audio services provided yet
[23:10] <TheMuso> right
[23:10] <superm1> kirkland, check that the daemon is running, and make sure you have all 4.x packages now - one of the guys wasn't getting bluez-utils to update correctly
[23:10] <superm1> until he manuall did apt-get install bluez-utils
[23:11] <charlie-tca> I downloaded the MD5SUMS text file on http://cdimages.ubuntu.com/xubuntu/releases/intrepid/beta/ to verify md5sums
[23:11] <kirkland> superm1: packages don't look right: http://paste.ubuntu.com/53303/
[23:11] <charlie-tca> on the CD downloads. I got an html file that is a 404 error page.
[23:11] <superm1> kirkland, yup that's your problem
[23:11] <superm1> kirkland, apt-get install bluez-utils and it should go
[23:11] <charlie-tca> Does it take time for the server to generate the file?
[23:12] <kirkland> superm1: odd, okay, installing
[23:12] <superm1> kirkland, i suspect its because the PPA is still providing an "old" bluez-audio binary package
[23:12] <superm1> and its confusing apt
[23:13] <TheMuso> NBs packages in PPAs are quite possible AFAIU.
[23:13] <wgrant> tedg: Regarding bug #261084, I think there might actually really be lots of keypresses. I'm not sure who to blame for them, however.
[23:13] <wgrant> Er.
[23:13] <wgrant> Not that one.
[23:13] <wgrant> Bug #261724
[23:15] <RAOF> Hm.  Now that I've paired this mouse with the new bluetooth stack, how do I actually make it work as a _mouse_?
[23:15] <tedg> wgrant: Yeah, I realize.  But, I think debouncing them in GPM will work.
[23:15] <cjwatson> charlie-tca: not to generate it, but if you're using a mirror then it might not have copied over yet
[23:15] <tedg> wgrant: It may even be funky keyboard controllers handling those differently.
[23:15] <wgrant> tedg: OK. Testing now.
[23:15] <tedg> wgrant: It's odd that there are SO many in some of the reports.
[23:15] <charlie-tca> Thanks
[23:15] <wgrant> tedg: Has something changed recently? It worked fine in Hardy.