[07:55] <pitti> hey calc, good luck with that
[07:55] <pitti> I'm just getting an ordinary cold, but terribly sore throat
[08:25] <huats> morning everyone
[12:53] <seb128> james_w: hi, do you still get bug #173212?
[12:54] <james_w> I did two months ago
[12:54] <james_w> I can test again if you like
[12:54] <james_w> I guess it's more an alsa problem
[12:54] <seb128> james_w: I think the bug is misassigned
[12:55] <seb128> right, but it's not clear exactly what your issue is
[12:55] <seb128> you say that the mixer and applet don't show the same volumes for the same channel?
[12:55] <james_w> the issues is that a new session changes the behaviour
[12:55] <seb128> but that's specific to the applet?
[12:55] <james_w> I'm not sure
[12:55] <seb128> or alsamixer show issues too?
[12:56] <seb128> it would be interesting to know if the alsa settings changes
[12:56] <seb128> or if that's just the applet which shows a wrong status
[12:57] <seb128> there is no hurry to try, don't close your session only for that
[12:57] <seb128> I'm just trying to clean the needinfo bugs
[12:57] <seb128> the fact that this one is hardware specific seems to suggest a driver or alsa issue rather than an applet one
[12:58] <seb128> we lack somebody knowing about the audio stack triaging those bugs
[12:59] <mvo> ember_: hello! I'm looking at the brasero update right now, thanks for working on this! what is the rational for dropping "-+X-Ubuntu-Gettext-Domain=brasero" - is this now done automatically by something?
[13:03] <mvo> seb128: do we have something that sets the X-Ubuntu-Gettext-Domain automatically now (or is there something that makes it obsolete?)
[13:03] <seb128> mvo: gnome.mk when using cdbs does
[13:03] <seb128> mvo: but that's not new
[13:04] <seb128> mvo: otherwise you have to do it in the rules
[13:04] <mvo> I rarely use gnome.mk I guess this is why I haven't noticed
[13:04] <seb128> mvo: cdbs hater ;-)
[13:05] <seb128> mvo: in fact langpack.mk does it, so you can include that rather than gnome.mk but GNOME packages usually use the gnome one for schemas registration, etc
[13:05]  * mvo nods
[13:06] <mvo> ember_: thanks, seb128 figured it out for me :)
[13:10] <james_w> seb128: confirmed.
[13:10] <james_w> seb128: when in a session I can mute, which leaves the volume level at e.g. 50% and sets the mute flag
[13:11] <james_w> seb128: when I restart my session it comes back muted, but with the volume set to 0%, and not having the mute flag set
[13:11] <seb128> you mean the applet has a mute icon?
[13:11] <james_w> seb128: alsamixer just shows a pulseaudio device, do you know how I can debug that side of this further
[13:12] <seb128> what does alsamixer shows?
[13:12] <james_w> the applet has a mute icon, but the checkbox in the context menu is un-checked
[13:12] <seb128> well the applet displays a mute icon when volume = 0
[13:12] <james_w> if you scroll to 0% in the applet then it gets the mute icon
[13:12] <seb128> try pavucontrol?
[13:13] <seb128> what does the gnome mixer displays if you double click on the applet icon for example?
[13:13] <seb128> just to be clear there
[13:13] <seb128> - you have some volume set
[13:13] <seb128> - right click on the applet, select the mute option there
[13:14] <seb128> - the applet is showing the volume as muted, what does the mixer display as volume then?
[13:14] <james_w> the same value as before selecting mute
[13:14] <seb128> - then you restart your session and the volume is 0 rather than using the mute toggle
[13:14] <james_w> yes
[13:14] <seb128> it seems that the volume is changing between sessions then
[13:14] <james_w> so my complaint is that it is not consistent.
[13:15] <seb128> something is switching mute and volume to volume = 0
[13:15] <james_w> agreed
[13:15] <james_w> pavucontrol isn't showing anything useful
[13:15] <seb128> I guess you will have the same issue without having an applet configured
[13:15] <james_w> the gnome mixer is showing volume = 0 and not muted, as you would expect
[13:15] <seb128> ok, I don't know enough about pulseaudio and alsa to give you useful hints there
[13:16] <james_w> I agree, but I don't know how to confirm that
[13:16] <seb128> you would not expect that
[13:16] <seb128> you would expect the volume to be what it was during the previous session
[13:16] <james_w> yeah, I mean I expect that given what the applet is showing
[13:16] <seb128> and the mute flag to be set
[13:16] <seb128> ok, anyway doesn't look like a gnome-applets bug
[13:16] <james_w> I agree
[13:17] <seb128> maybe you can reassign to alsa-lib rather and try to ask to crimsum when he's around if he has an idea about the issue
[13:17] <seb128> you can also try to uninstall pulseaudio and see if you still get the issue when using alsa directly
[13:17] <seb128> hum
[13:17] <seb128> you opened this bug before the pulseaudio time I think
[13:18] <seb128> reassing to alsa-lib and let them deal with the bug
[13:25] <james_w> thanks seb128
[13:25] <james_w> I updated the bug report to be more clear about the behaviour
[13:25] <seb128> james_w: thank you for testing and updating the bug ;-)
[14:01] <asac> seb128: installed xul 1.9.0.4 yet? please go for it and let me know if ephy still crashes on shutdown
[14:02] <seb128> asac: not yet, I will let you know, they fixed something which seems similar to the issue?
[14:03] <asac> seb128: just the comment from debian ;)
[14:03] <seb128> ok
[14:10] <asac> seb128: hmmm .... do you use REVU and get acks from two MOTUs for new packages :-P ?
[14:10] <seb128> asac: lol, good one!
[14:10] <asac> well. i am looking through wiki
[14:10] <seb128> asac: no, I use my upload power and get one ack from pitti when it's in NEW ;-)
[14:11] <asac> thats breach of policy isnt it?
[14:11] <seb128> what policy?
[14:11] <asac> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[14:11] <seb128> that's a MOTU thing
[14:11] <asac> what does that mean?
[14:11] <seb128> I'm not a MOTU ;-)
[14:12] <asac> core-devs dont need taht?
[14:12] <pitti> seb128: you are
[14:12] <asac> this just came up because MOTUs want mozilla packages to go through REVU ... which is completely senseless imo
[14:12] <seb128> well, let's say I've enough to do without bothering using revu, etc
[14:12] <seb128> so maybe I'm abusing my power there dunno
[14:12] <asac> because no MOTU ever reviewed any mozilla package
[14:12] <seb128> but I really don't feel doing extra paper work only to be compliant to some MOTU policy on the topic
[14:13] <asac> seb128: i feel the same. but just ignoring it cant be right ;)
[14:13] <asac> we need to fix that policy then i think
[14:13] <pitti> I thought that revu thing would only apply for non-MOTUs
[14:14] <asac> pitti: apparenlty thats not the case.
[14:14] <pitti> i. e. folks who start learning packaging have to get two MOTU acks (or, likely, some iterations of fixing) before uploading to NEW?
[14:14] <asac> persia said that everything has to go through REVU
[14:14] <asac> for NEW packages
[14:14] <pitti> hm, that's news to me, too
[14:14] <asac> pitti: i think REVU is for non-MOTUs ... and new-packages
[14:14] <asac> pitti: well. policy is that you need two ACKs if you want to upload a new package
[14:15] <asac> REVU is just the standard procedure
[14:15] <asac> pitti: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[14:15] <pitti> asac: oh, good to know
[14:16] <seb128> what define a policy and who approve what is official policy?
[14:16] <asac> pitti: my personal feeling is that this policy cannot be valid for packages that MOTU team doesnt care for
[14:16] <seb128> ie is that wiki page something official or something MOTU decided in a unilateral way?
[14:16] <asac> for instance: mozillateam packages -> MOTU never touch those
[14:16] <pitti> asac: well core-dev is a subset of MOTU
[14:17] <asac> seb128: i am not sure what the policy process is
[14:17] <asac> from what i understand motu council can just release policies on their own
[14:17] <seb128> and that stands for universe imho
[14:18] <seb128> well I'm not sure why a MOTU should have to go through REVU review either
[14:18] <asac> as a matter of fact most packages go into universe first
[14:18] <seb128> somebody who knows about packaging should be able to just do it and upload
[14:18] <asac> i agree
[14:18] <seb128> right, but that's creating paper work, slowness and extra work for no good reason
[14:19] <asac> right. and fta's experience with REVU is that you never get two acks there
[14:19] <seb128> let's move that to #ubuntu-devel maybe rather?
[14:19] <asac> the first will happen quickly ... the second never happens and you have to run around poking folks
[14:19] <seb128> or wait for dholbach reply?
[14:20] <asac> seb128: lets wait for dholbach
[14:20] <seb128> well, REVU is similar to sponsoring
[14:20] <asac> seb128: and then discuss this properly
[14:20] <asac> when i have the cycles too
[14:20] <seb128> lot of items, not enough manpower, extra delais
[14:20] <asac> i am about to run ;)
[14:20] <seb128> ok
[14:20] <asac> i think archive admin review should be enough for those that have upload rights
[14:20] <seb128> yes
[14:21] <asac> if archive admins say that there is too much garbage then they are supposed to push for a pre-review
[14:21] <asac> at least if archive admins dont ask for it, there is no reason for such a policy
[14:21] <seb128> well, somebody who has upload rights should be able to produce a mostly correct package
[14:36] <ember_> sorry mvo i wasn't here, and thanks for sponsoring.
[14:36] <ember_> seb128: when you have time can you renew me on desktop-bugs team
[14:37] <seb128> the team is an open one you can do that on launchpad directly
[14:37] <ember> where? i was able to renew bugteam but not desktop-bugs
[14:38] <seb128> not sure of the url but your subscription details should let you renew it
[14:38] <seb128> or you might need to wait until expiration
[14:39] <seb128> the team is an open one for sure and you don't need an admin approval, not sure about the launchpad interface, you can ask on #launchpad if that's not clear
[15:40] <seb128> fta: hey, did you read my comments about the cairo update the other day?
[16:00]  * pitti rings the desktop team meeting bell
[16:00] <calc> here
[16:00] <pitti> https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-11-18
[16:00] <pedro_> hello
[16:00] <seb128> hey
[16:00] <calc> oh yea this should be updated on fridge bueno can do it apparently if we ask him
[16:00] <pitti> bryce, Riddell, Keybuk, ArneGoetje: there?
[16:01] <ArneGoetje> hi
[16:01] <Keybuk> _o/
[16:01] <pitti> asac is on holiday
[16:02] <Riddell> hi
[16:02] <pitti> calc: as our US representative, could you ring bryce?
[16:02] <calc> ok
[16:03] <pitti> that's actually the first topic
[16:03]  * calc looking up his number now
[16:03] <pitti> I'll talk to beuno to get the desktop team meeting on the fridge
[16:03] <pitti> seb128 noticed that there wasn't a team meeting reminder
[16:03] <pitti> do you guys actually want to get one every week? or woudl having the meeting in evo be enough for you, and we avoid cronspam?
[16:04] <seb128> having it in e-d-s would be enough imho
[16:04] <seb128> which is not the case right now
[16:04] <Keybuk> pitti: I briefly talked to persia about it, apparently the meeting can't go on the fridge, because we don't use #ubuntu-meeting
[16:04] <pitti> uh?
[16:04] <Riddell> an e-mail the day before to remind about activity I find nice
[16:05] <calc> he didn't answer the phone
[16:05] <pitti> calc: ok, thanks for trying
[16:05] <Riddell> there's nothing channel specific about fridge events, it's for all events
[16:05] <Keybuk> Riddell: apparently the #ubuntu-meeting bot gets confused
[16:05] <Riddell> that's the bot's problem
[16:06] <pitti> ok, I'll continue to send the reminders for now
[16:06] <pitti> ACTION: pitti to continue to send out meeting reminder emails and ask beuno to get it on the fridge
[16:06] <seb128> Keybuk: the calendar can have non meeting events too no? we don't specifically need that to be set as a meeting slot there
[16:07] <Keybuk> dunno :)
[16:07] <Riddell> "Desktop Team Meeting" is on fridge, but for wrong day
[16:07] <pitti> before we come to the main topic: two weeks ago we went through the intrepid-updates bugs
[16:07] <seb128> well, milestones are on the calendar
[16:07] <pitti> it would really be good to get them sorted by UDS, since at UDS and afterwards we'll all have jaunty in our heads
[16:07] <pitti> are there any blockers, or bugs which turned out to be complicated?
[16:08] <Riddell> the cmake/kde4libs/adept breakage is a bit strange
[16:08] <pitti> Riddell: the kde4libs SRU broke builds?
[16:08] <Riddell> yeah
[16:08] <Riddell> NCommander is being great and working on it though
[16:09] <pitti> so shold that block -updates migration of kde4libs? (the bug is verified otherwise)
[16:09] <Riddell> yes, for now
[16:09] <Riddell> it'll likely need a patch to kde4libs to fix
[16:09] <pitti> Riddell: noted
[16:09] <pitti> all others are fine with their intrepid-updates bugs?
[16:10] <seb128> GNOME 2.24.2 tarballs due next week
[16:10] <pitti> oh, fun
[16:10] <seb128> but I don't think we will try to do all the updates since that's not a lts
[16:10] <pitti> right, I agree; it actually was a special exception for hardy
[16:10] <seb128> the evo stack will likely get an another round of updates though
[16:10] <pitti> so we'll only do updates to major bug fixes then?
[16:11] <seb128> yes
[16:11] <pitti> which reminds me, Riddell, is the new kde microrelease in -proposed?
[16:11] <Riddell> pitti: no, I got distracted by merges
[16:11] <Riddell> pitti: I wasn't clear, does it need one bug for every package?
[16:11] <Riddell> or just one meta-bug?
[16:11] <pitti> Riddell: yes, one representative for each package would be good, to track verification and migration
[16:11] <pitti> some uploads already have an LP #
[16:12] <pitti> so we only need one for packages which don't fix any LP bug in their changelog
[16:12] <Riddell> ok
[16:12] <pitti> ok, then let's get to UDS preps
[16:12] <pitti> Keybuk: any initial words?
[16:13] <pitti> last week I asked you to think about what you would like to work on during jaunty
[16:13] <pitti> so I propose everyone gives a quick overview about their intentions
[16:14] <pitti> personally I'd like to concentrate on fixing bugs, robustifying the apport retracers, and working on CD size
[16:14] <Keybuk> I think it'd be worth going through each person to get a list of spec ideas firmed up
[16:14] <seb128> what pitti said + GNOME 2.26 ;-)
[16:15] <pitti> ArneGoetje: ?
[16:15] <ArneGoetje> I have enough on my plate: basically continue to work on my usual stuff... fonts, language-selector, font-selector, plus a new item: ibus (a candidate to replace scim)
[16:16] <Keybuk> you've registered a spec about ibus
[16:16] <ArneGoetje> yes
[16:16] <Keybuk> are there any others you'd want for UDS?
[16:16] <pitti> ArneGoetje: does ibus need UDS discussion, or is it a "just do it" thihng?
[16:16] <ArneGoetje> needs UDS discussion
[16:16] <pitti> ah, ok
[16:16] <ArneGoetje> Keybuk: no thanks :) as I said, I have enough on my plate
[16:16] <Keybuk> do you think language-selector or font-selector could warrant a discussion?
[16:17] <Keybuk> especially since we have new UI and Desktop-interested people?
[16:17] <ArneGoetje> I will probably discuss with mpt about GUI rework and additional features for language-selector.
[16:17] <pitti> ArneGoetje: please register a spec for this then, so that it can be scheduled
[16:18] <ArneGoetje> font-selector: I'm looking forward to finally get hold of Keith Packard... need to prod him for more info about fontconfig.
[16:18] <Keybuk> sounds like they're both worth scheduling an hour for, then
[16:18] <ArneGoetje> pitti: will do
[16:18] <mpt> mm, additional features
[16:18] <pitti> ArneGoetje: thanks; please propose it for the uds-jaunty meeting, so that it stands out from the noise
[16:19] <ArneGoetje> pitti: ok
[16:19] <pitti> ok, thanks
[16:19] <pitti> calc?
[16:19] <calc> get release exception and OOo 3.1 in, get OOo languages switched to Pootle/Rosetta, get OOo split builds working.
[16:19] <Keybuk> which of those are worth a UDS discussion?
[16:20] <Keybuk> sounds like the pootle/rosetta one could be?
[16:20] <calc> i need to talk to doko and rosetta people about that one yes
[16:20] <calc> the release exception i just need to ask for it from the release team i guess, not sure if we need a meeting for that one
[16:21] <pitti> calc: agreed, but the pootle one does warrant one, I think
[16:21] <calc> yes
[16:21] <calc> i will create a blueprint for it
[16:22] <pitti> @all: please nominate them for uds-jaunty
[16:22] <pitti> Riddell: what are your plans?
[16:23] <Keybuk> (and the plans of the Kubuntu Kommunity)
[16:23] <Keybuk> err, I swear I didn't do that deliberately
[16:23] <pitti> of Kourse
[16:23] <Riddell> pitti: listed here https://wiki.kubuntu.org/KubuntuJauntySpecs
[16:24] <Riddell> pitti: summaried as make Kubuntu with KDE 4 good enough for the whingers on the kubuntu-users mailing list :)
[16:24] <Riddell> pitti: we have a meeting tonight to discuss them more, then I'll register the specs in LP
[16:24] <pitti> Riddell: nicely prepared!
[16:25] <pitti> ok, that's everyone except bryce
[16:25] <pitti> ACTION: pitti to talk to bryce about jaunty plans
[16:25] <Keybuk> (and asac, but he's on leave)
[16:25] <pitti> right
[16:25] <pitti> so it seems to be a cleanup cycle for GNOME and KDE, and in general
[16:26] <kwwii> so I am officialy not on the team anymore, right?
[16:26] <pitti> kwwii: sorry, wasn't aware that you were lurking; feel free to introduce your plans as well :)
[16:27] <kwwii> pitti: actually, I don't think I am part of the team anymore...wasn't being nasty :-)
[16:29] <pitti> ok, please make sure to register your specs, preferably by the end of the week
[16:30] <pitti> and let's finish that intrepid thing, so that we have our heads free for jaunty
[16:30] <pitti> I cleared my intrepid-updates bug list, so if anyone needs a hand for his', please give me a ping
[16:30] <pitti> AOB?
[16:31] <pitti> oh, one thing
[16:31] <pitti> DebianImportFreeze is December 25, which means in practice that we have this, next, and one week after UDS for finishing merges
[16:32] <pitti> okay, I feel alone now, so let's wrap up :)
[16:32]  * seb128 hugs pitti
[16:33]  * calc hugs everyone while... not getting them sick ;-)
[16:33] <seb128> oh, I intend to start on GNOME 2.25 for GNOME 2.25.2
[16:33] <seb128> ie, the week before uds
[16:33] <seb128> I don't think we have a real need to hurry on pushing 2.25.1, there is not a lot of users on jaunty yet
[16:33] <seb128> and I prefer to use the time to do cleaning
[16:33] <Keybuk> kwwii: *hugs*
[16:34] <pitti> seb128: sounds fine
[16:35] <seb128> pitti: ok, good, let's do some good cleaning before starting on new crack ;-)
[16:36] <pitti> yeah, and for jaunty too :)
[16:36] <pitti> I appreciate having some time to work on bugs
[16:37] <seb128> me too
[16:38] <bryce> heya
[16:38] <bryce> sorry, I'm onsite in Lexington and was helping an engineer with an X bug
[16:39] <seb128> hey bryce
[16:40] <pitti> hi bryce
[16:41] <pitti> bryce: can you please give a quick intro about what you are planning to work on in jaunty?
[16:41] <bryce> regarding specs, there are a few that ubuntu-x community members are taking the lead on (config tools, etc.) which I'll be assisting on
[16:41] <bryce> I've also posted one for switching -ati from XAA to EXA
[16:41] <bryce> that should be pretty straightforward; mostly just testing and following up on bugs
[16:42] <bryce> testing = stability + performance testing
[16:42] <bryce> also I plan to do more work on my ongoing Xorg testing spec.  Make XSmoke, and the historical drivers page
[16:42] <bryce> aside from that probably won't have much time remaining - OEM X bugs are consuming most of my time these days
[16:44] <bryce> I do want to put a lot of time into getting distro X bugs closed as I'm having good momentum with upstream at getting fixes, so am glad bug fixing is a focus.  I hope I'll have enough time to work on that.
[16:44] <pitti> bryce: ok, so maintenance, cleanup, and better testing?
[16:45] <bryce> right, and enhancing tools for configuration and troubleshooting
[16:45] <pitti> great, seems everyone is focusing on that in jaunty, so far I didn't hear about major new structural changes
[16:45] <pitti> (of which we had quite a lot in hardy, for example)
[16:45] <pitti> jaunty should have been an ideal LTS cycle :-P
[16:45] <seb128> we picked the bad cycle for hardy
[16:45] <bryce> the one pending  X structural change is kernel modesetting; not sure how much we want to push that.  Sounds like it's still fairly experimental.
[16:45] <seb128> s/hardy/the lts
[16:46] <pitti> bryce: ok, thanks for the intro; can you please make sure that the things you want to discuss with others have a blueprint registered, and proposed it for uds-jaunty?
[16:46] <bryce> pitti: yes, all have blueprints registered at this point
[16:46] <pitti> bryce: right, KMS sounds worth discussing
[16:46] <bryce> I'll make sure they're proposed
[16:46] <pitti> bryce: cheers
[16:49] <Keybuk> bryce: are the ones you've posted suggested for uds-jaunty?
[16:49] <Keybuk> I can't find them in the proposed list
[16:49] <seb128> pitti: btw is the multimedia stack a platform or a desktop team land?
[16:49] <bryce> Keybuk: not yet; I'm doing that presently
[16:49] <seb128> I really think we should do something to address the audio stack being outdated and buggy
[16:49] <rlaager> Amen!
[16:49] <Keybuk> bryce: *resists the urge to bring the previous #ubuntu-devel topic in here*
[16:50] <pitti> seb128: as in gstreamer (desktop) or alsa (platform)?
[16:50] <seb128> pitti: as in pulseaudio
[16:50] <pitti> pulseaudio actually sounds desktopish, but since Luke handles it, it's platform
[16:51] <seb128> pitti: or totem and rhythmbox
[16:51] <seb128> not working correctly due to it
[16:51] <bryce> Keybuk: done.
[16:51] <seb128> pitti: "handle", the list of bugs doesn't seem really triaged, the version is outdated, sound effects are not working due to oudated libcanberra, etc
[16:52] <bryce> Keybuk: a few don't really need full discussion sessions for them.
[16:52] <seb128> pitti: would be really nice to put some extra ressources to solve that
[16:52] <pitti> yes, full ack
[16:53] <Keybuk> bryce: x.org conf options editor - is that separate to alberto's spec?
[16:54] <rlaager> pitti, seb128: If the "replacing Pidgin with Empathy" thing comes up again, I'd really like to find a way (i.e. figure out the design and get some code written) to ensure that users can have their libpurple (Pidgin, et al.) IM logs automatically read by Empathy. I think that's the most important "data" that an IM client has given that buddy lists are generally stored on the server.
[16:55] <bryce> Keybuk: nope it's one of the items alberto is working on
[16:55] <rlaager> pitti: I'm obviously not going to propose having that discussion at UDS, but you thought it might come up. If it does, I'd definitely want to be involved.
[16:55] <bryce> Keybuk: that's actually a part-2 from a spec we discussed last UDS
[16:55] <Keybuk> https://blueprints.edge.launchpad.net/ubuntu/+spec/screen-configuration-ui
[16:55] <Keybuk> is already proposed
[16:55] <pitti> rlaager: personally I'm not planning it for jaunty either, since I'd really like to let people work on bug fixing
[16:56] <rlaager> pitti: Ok. I like bug fixing. That's what I want to focus on, but I'm not on any Ubuntu teams officially.
[16:56] <calc> rlaager: merged users (across protocols) is somewhat useful as well and is only stored in libpurple
[16:56] <pitti> rlaager: but independently from that, I think that switch will be made in the distro worlds at *some* point, so talking about migration paths is always good, even if it lands in jaunty+n
[16:56] <tedg> Is there a session at UDS planed for talking about the new GDM?
[16:56] <seb128> rlaager: hi
[16:56] <rlaager> calc: It was my understanding that Empathy didn't support meta-contacts/persons.
[16:57] <calc> rlaager: oh ok
[16:57] <pitti> tedg: good point; can you please register one, so that we can review the missing features and see which ones we need to implement?
[16:57] <bryce> Keybuk: yep, screen-configuration-ui is essentially a part-3 to this, to expand on the xorg-options-editor functionality
[16:57] <rlaager> seb128: Hello! Hopefully I'll be generating more patches for you instead of just a pile of bug reports. :)
[16:57] <tedg> pitti: Okay.
[16:57] <Keybuk> bryce: ah
[16:57] <Keybuk> which is part 1 ?
[16:57] <Keybuk> which is part 2?
[16:57] <seb128> rlaager: quick comment about this gtk bug where you added a upstream change, we usually don't do too much backporting to non-lts if there is not a strong reason to do
[16:58] <seb128> rlaager: the stable updates are quite some work and the team is small so we try to reserve backports to annoying issues
[16:58] <bryce> part 1 is the little dialog enhancement to screen-display-properties which adds in Virtual options for dual-screen functionality - this is deployed already in Intrepid
[16:58] <rlaager> seb128: Fair enough. What about for Jaunty? I'm not sure how much distro patching you like to do.
[16:58] <Keybuk> ok great
[16:58] <Keybuk> I've put them in the right order in the schedule
[16:59] <seb128> rlaager: let's see when they will roll a new tarball, if they don't we will do backporting
[16:59] <bryce> part 2 is to expand that into a general purpose option editor.  part 3 is to expand that into a general purpose xorg.conf configuration tool.
[16:59] <bryce> part 2 is mostly done except for integration, so part 3 is maybe doable for jaunty, but needs discussion.
[17:00] <rlaager> seb128: For what it's worth, I'm at basically 100% of my non-public data under ~/Private now and things seem to work well. I'd love to hear your thoughts on killing off ~/.recently-used (note, not .xbel) by finding and rooting out the EggRecent code from apps (at least Totem, I think).
[17:01] <seb128> that's a good idea but ideally something GNOME would do
[17:01] <johanbr> rlaager: Empathy git has some code for log migration. Haven't tried it, though.
[17:01] <rlaager> johanbr: I'll have to look at that.
[17:09] <ArneGoetje> I guess we are finished with the meeting?
[17:10] <pitti> bryce: oh, were you planning to do the acpi-support obsoletion, too? some of it can be fanned out to several people, but I think someone needs to coordinate it
[17:11] <pitti> ArneGoetje: yes, a while ago
[17:11] <ArneGoetje> pitti: didn't notice since there is still discussion going on... :P
[17:11]  * ArneGoetje -> bed
[17:11] <pitti> well, it's #ubuntu-desktop :)
[17:11] <pitti> ArneGoetje: sleep well
[17:11] <ArneGoetje> thanks
[17:12] <bryce> pitti: unfortunately I likely won't have much time to help
[17:12] <bryce> pitti: the OEM team is going to need a lot of X support going forward, and don't have a dedicated X guy (yet?)
[17:12] <pitti> bryce: since you absorbed quite a lot of knowledge about acpi-support while you were debugging this stuff and doing the merge, would you mind giving a quick tutorial about it at UDS, so that others can help?
[17:13] <bryce> sorry, I must run to another OEM thingee... bbia hour
[17:13] <pitti> so that we get a plan "what do we need to do to migrate to pm-utils"?
[17:13] <bryce> pitti: be happy to participate in the session.  Don't know I really have that much wisdom to share but glad to braindump.
[20:03] <rlaager> This might be something to discuss at UDS: https://bugs.launchpad.net/ubuntu/+bug/40306
[20:04] <rlaager> It is, of course, not fixed (at least not from my point of view with bug #40334, which was marked as a duplicate of it).