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