[07:38] Good morning [07:39] good morning [07:39] didrocks: o/ [07:39] :) [08:53] good morning everyone [09:05] hiya tseliot [09:05] good morning [09:05] good morning rickspencer3 [10:46] jcastro: I must rename ubuntu-netbook-remix-default-settings in launchpad to ubuntu-netbook-default-settings (and make some kind of indirection for people using < lucid). Are you in charge or do I just open a request on LP? [10:48] imo there should just be a single project: ubuntu-netbook [10:48] with subtrees etc. :) [10:48] rather than creating one project for each package [10:48] which will cause these kind of issues if you rename a package [10:49] just my 2c [10:49] (if this is about a LP project at all) [11:07] hey asac [11:07] asac, did you read my question yesterday? [11:07] no [11:07] asac, I'm failing to get libgjs working with libmozjs [11:08] hmm [11:08] it's in no way a priority [11:08] but help would be welcome [11:08] do we need libgjs? [11:08] it's a depends for gnome-shell [11:08] cant we get rid of all this ;)? [11:08] yeah. they shouldnt use javascript. we have no engine [11:08] that is suitable for main [11:08] $ ldd /usr/lib/libgjs-dbus.so | grep libmozjs [11:08] libmozjs.so => not found [11:08] libmozjs.so => /usr/lib/xulrunner-1.9.1.7/libmozjs.so (0x00267000) [11:08] I don't get why it's there twice [11:09] and why it find one and not the other one [11:09] someone has to tell them that javascript is a bad situation [11:09] seb128: we had exactly that before [11:09] do you remember where that was? [11:09] I tried to rebuild using as-needed [11:09] right [11:09] but that seems to not do the trick this time [11:09] dunno why [11:09] and the same source works in karmic [11:09] thats using rpath? [11:09] or LD_LIBRARY_PATH? [11:10] I'm a bit puzzled [11:10] LD [11:10] well using /usr/lib/xulrunner-1.9.1.7 works [11:10] what doesnt work then? [11:11] try running gjs [11:11] i dont have lucid yet [11:11] gnome-shelll does some LD_LIBRARY_PATH trick [11:11] but gjs doesn't [11:11] you are on karmic? [11:11] can you run ldd /usr/lib/libgjs-dbus.so | grep libmozjs [11:12] you need to install gjs [11:12] i have gjs but not the dbus module [11:12] gjs [11:12] gjs> [11:12] no gjs-gi? [11:12] export LD_LIBRARY_PATH=/usr/lib/xulrunner-1.9.1.7/ [11:12] it works with LD hack [11:13] you need to write a wrapper for gjs if that is supposed to work oob [11:13] but that should not required [11:13] +be [11:13] hmm [11:13] why wouldnt it be required? [11:13] I hate this thing [11:13] can't we make it a proper lib? [11:13] yes, for universe [11:13] but not main [11:13] it's not in main [11:13] it's in universe [11:13] but at some point folks want it in main [11:13] we will not use gnome-shell this cycle [11:14] thats clearly going to happen [11:14] we have to communicate to upstream, that libmozjs isnt allowed to be used in the distro [11:14] they need to do something else [11:14] before everything is lost and even more move to libmozjs [11:15] I've better things to do that fight over that with them [11:15] I just want gnome-shell in ubuntu to be nice to them [11:15] yes, but if its nice, they dont see that there is a problem [11:16] same attiude as the coucdb folks. they say, if its a problem someone else will fix it. but the fact that we adopted it sucks much. [11:16] anyway, i will check how easy it is to build it standalone [11:16] will take some time [11:18] ok thanks [11:18] I've to go for lunch sorry... [11:18] bbl [11:25] kenvandine, njpatel: wrt. 71_add_gio_extension.patch [11:25] asac / seb128 - joss started a discussion on the gnome desktop-devel list last year, but it didn't really go anywhere: http://mail.gnome.org/archives/desktop-devel-list/2009-September/msg00121.html [11:25] you might be interested in taking a look [11:26] kenvandine: could that become a proper diff -u, and get a standard patch tag header? (upstream link, etc.) [11:28] would any of you apply a patch to the GDM package? [11:29] I've finally got approval for patch at Bug 393854, but I can't commit it myself [11:29] Launchpad bug 393854 in gdm "Update PAM policy to allow password-less logins set up via users-admin" [Unknown,Confirmed] https://launchpad.net/bugs/393854 [11:31] milanbv - it would be good to get an opinion from someone on the security team (eg, kees), or someone like slangasek before any of us commit it [11:31] ah [11:31] i misread your second comment there ;) [11:32] chrisccoulson: yeah, kees just agreed yesterday ;-) [11:33] did you discuss it on IRC? i can't see any comments on the bug report [11:34] on #ubuntu-devel [11:34] (so that you can't check what I'm pretending...) [11:34] thanks :) [11:35] if he's happy with it, then i can commit it when i finish work if nobody else beats me to it [11:35] nice, thanks [11:35] but we're frozen for A2 at the moment anyway (although, i haven't checked my inbox for a release announcement yet, so that might not be the case any more) [11:36] no hurry, I'd just like somebody to do it before the release [11:36] (final release) [12:05] asac: do you know if network-manager 8.1 will make it into Lucid? Or will it stay the same version as in Karmic? === MacSlow is now known as MacSlow|lunch [12:11] TeTeT: it will be 0.8 final most likels [12:11] we have a prerelease version [12:11] first step is rc2 ... which we will try to get to karmic as an SRU as well [12:12] TeTeT: upstream hasnt even released 0.8 final ;) [12:12] so given the pace i nthe past its unlikely that there will be a 0.8.1 [12:13] asac: ok, thanks a lot :) [12:14] asac: any chance the latest nm will get a PPA, so they can copy a working package from there? [12:14] TeTeT: did you read my comment on the pppoe bug? i gave a timeline/plan there [12:15] asac: need to re-read it then, escaped me [12:15] no problem. last comment ;) [12:18] asac: was this bug 483773? [12:18] Launchpad bug 483773 in network-manager "Unable to bring up mobile-broadband system-connection" [Undecided,Fix committed] https://launchpad.net/bugs/483773 [12:28] no [12:28] ;) [12:28] one minute [12:28] TeTeT: bug 432205 [12:28] Launchpad bug 432205 in network-manager "[MASTER] pppd timeout when trying to establish a DSL connection" [High,Fix committed] https://launchpad.net/bugs/432205 [12:34] asac: I wasn't subscribed to that one [12:36] davidbarth: https://edge.launchpad.net/ubuntu/lucid/+milestones [12:38] TeTeT: ok. thought that was your main concern ;) [12:39] TeTeT: if you need to be up-to-date on our NM roadmap in future, i can try to keep you in the loop. just wasnt aware that you rely on this [12:39] asac: I actually never did, but nowadays I seem to get a NM question a day. I even subscribed to the upstream mailing list ... [12:40] asac: not that it would mean anything ... [12:40] asac: do you still need the alpha2/final mobile reports on piware.de or can I take down the cronjobs? (I'll archive the .db and output just in case, but I'd like people to move to the new WI tracker on macaroni) [12:49] pitti: i would like the alpha2 state to be frozen right when alpha2 release is done. then we can move elsewhere [12:49] (but keep the graph and the last state) [12:49] if thats posisble [12:50] where is the new macaronis service= [12:50] ? === MacSlow|lunch is now known as MacSlow [13:13] asac: right, I did a complete backup of the scripts, databases, and output [13:13] asac: I'll keep the alpha-2 reports for a while, but I'd like to remove the lucid/ ones (since they are out of date and imprecise) [13:13] pitti: where can i find the new tracker? [13:13] asac: and above all I'd like to kill the cronjobs [13:13] asac: you don't read your platform@ mail? :-) [13:13] guess i missed a mail in the thread [13:13] asac: http://macaroni.ubuntu.com/~pitti/workitems/ [13:14] i dont read all mails in threads i considered done :) [13:15] pitti: ok, what about the full cycle one? [13:15] asac: the names without the milestone [13:15] asac: likewise, all-* are the ones for entire ubuntu, particular milestone [13:15] and all milestones/all teams == all.html [13:16] it has the full combinatorial explosion [13:16] (they're dead cheap to generate now) [13:16] pitti: ok. just confusing that they dont have canonical- as prefix [13:16] it's not a hardcoded prefix anyway [13:17] oh sorry [13:17] good [13:17] it's LPTEAMNAME-MILESTONENAME [13:17] so our trendline got reset? [13:17] asac: yes, I didn't write a full DB migration script [13:17] asac: but of course I'm fine to adjust the trend line start for you if you want [13:18] yeah. lets try to use the value where the current one ended [13:18] (not that the old start would be too meaningful with the 2 weeks of holidays, etc., but I'm happy to add support for this) [13:18] thtas odd [13:18] there are far less items [13:18] http://piware.de/workitems/mobile/lucid/report.html [13:18] here it was 130 [13:18] and we were behind [13:18] now 130 would mean we are ahead [13:19] http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html [13:19] any clue what specs didnt get picked up? [13:20] asac: it's a different count now [13:20] now it's counting WIs from members of your team [13:20] hmm [13:20] hello guys ! [13:20] before it was counting WIs from all specs of your team, even if they were assigned to a different team [13:20] we want to have our community specs there too [13:20] I'll change it to cover both [13:21] its basically one spec: liquid [13:21] that will come back, yes [13:21] problem is that we cannot really plan how far we are behind based on our progress before [13:21] will work on this next week, when the sprint is done [13:21] i wanted to kill stuff until we hit the line [13:22] cant the other cronjob still run? [13:22] or is that completely f***ed? [13:22] that was my original question [13:22] it can still run [13:22] just the full cycle [13:22] one [13:22] good [13:22] but I can't change anything in the code any more [13:22] yeah [13:22] thats fine. i would then use the full cycle one from there and the milestones ones from the new [13:23] just need liquid in the new spec list [13:23] asac: the old alpha-2 report is probably uninteresting now, I figure? [13:23] cool. thanks [13:23] asac: I think from next week on the charts shold be correct, too [13:23] pitti: just need a final snapshot for later communication [13:23] for alpha-2 [13:23] asac: I won't remove the html pages [13:23] e.g. the html page basically [13:23] ok good [13:23] just stop the alpha-2 cron job [13:23] then its all good [13:23] yeah [13:23] we are close enough there [13:23] alpha-2 is today, so it doesn't make sense to let it run [13:23] and today is release day [13:23] ;) [13:24] the new alpha-2 report will continue to be generated, so you can look at that for stragglers [13:24] hmm. what does that mean? does the trendline go below zero there? [13:25] no, of course not [13:25] currently the new alpha-2 is empty [13:25] oh ok [13:25] asac: I meant WIs which were scheduled for alpha-2, which you didn't get to [13:25] * pitti yays at http://macaroni.ubuntu.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-2.html [13:25] i think: just let it run. i will adapt to the new approach if the full new one is still there [13:25] err full old one [13:25] asac: http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile-lucid-alpha-2.html isn't though [13:26] one item blueprints are good ;) [13:30] pitti: I think you left the proprietary improments blueprint out of that page [13:31] pedro_: yo? [13:32] vuntz, hey, saw my message? [13:39] tseliot: it shouldn't be there; https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers is targetted to alpha-3 [13:39] tseliot: it's on http://macaroni.ubuntu.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-3.html [13:39] pitti: aah, ok [13:44] rodrigo__, stop suggesting upstream to do things which will break our lts ;-) [13:44] seb128, what have I suggested? [13:44] landing the new g-c-c design [13:44] cf my comments on #c-c [13:45] seb128, oh, would that break our lts if it lands in time for 2.30? [13:45] it's quite some changes [13:45] by experience it takes time to find and fix issues on rewrites [13:45] it's better to have one cycle to sort things [13:45] rather than rushing [13:46] you're right in that it's a bit late in the cycle, I guess [13:46] I'm maybe too much on the conservative side [13:46] but breakages over cycles learnt me to do be prudent with such changes ;-) [13:46] well, I asked thos if it was going to land master, it should be now or just wait [13:46] and yeah, seems it's not ready [13:47] seems they are still discussion how to do it [13:47] it seems a bit risky [13:47] let's see what they decide [13:48] upstream should decide on what they think is best, not on what distro will do... [13:48] but we might go back to 2.28 if they do land that [13:48] depends on how well it works I guess [13:48] hey mclasen [13:49] hmm? [13:49] mclasen, did you read my question yesterday? [13:49] saw it go by [13:49] mclasen, some people were asking about the tooltip work you did and if those would go upstream this cycle [13:49] is there anything blocking them? [13:49] they would if I had time to finish them up [13:50] oh ok [13:50] the comment suggested you considered the round corner change ready [13:50] thanks [13:50] need to figure out if there's a way to let theme engines do all the drawing [13:50] and still have the shape match the drawing [13:51] which is a little complicated [13:51] ok [13:51] what is the schedule now for 2.20 btw? [13:51] I guess those changes will be for next cycle now? [13:51] I said 'early january'... but too late now :-( [13:51] pedro_: sorry, I was writing a mail. I was wondering if it'd be possible to analyze the stack traces you get from crashes before forwarding them upstream [13:52] vuntz, hello [13:52] seb128: right now I am operating in 'maybe I have some time next week' mode... [13:52] vuntz, what sort of analyze do you want to do? [13:52] pedro_: I quickly looked at a few of them, and most of them are like "hrm, yeah, I can't do anything about that. I need more details, or it should be run again with --sync, or I need ways to reproduce" [13:52] vuntz, we do that, but what kind of analyze do you want? === gnomefreak is now known as thunderstrck [13:53] vuntz, deciding on how much clue a debugged stacktrace will give to the hacker is not easy [13:53] pedro_: well a gnome-panel crash with only symbols in gdk/gtk+ is generally a bad sign, for example, since it's really hard to debug with just this === thunderstrck is now known as gnomefreak [13:53] (of course, this is not always true) [13:53] vuntz, we default to sending debug ones and let the maintainer decide on if it's useful or not [13:53] seb128: yeah, I know [13:53] I think it's a fair choice [13:53] you can close in one click if you think it's not useful [13:54] but it's better than having bug triagers deciding a stracktrace is not useful when it would be maybe for somebody [13:54] vuntz, well if there's specific requirements for the gnome-panel we can ask those before submitting them there [13:54] seb128: I usually feel bad about closing bugs with a stack trace, without understanding why there was a crash [13:55] and I feel bad about closing those downstream without knowing if it would be useful to upstream or not... [13:55] pedro_, seb128: what would generally help is making it possible to install packages were the applets are not in-process, and then ask the reporter to reproduce === gnomefreak is now known as gnomefreak76 [13:55] but if you have good metrics we can use [13:55] (unless the stack trace makes it obvious where the crashes is) [13:56] eg, I would guess most of the stack traces with no useful symbols crashing gnome-panel might actually be notification area issues [13:56] the things with crashes is that often they are not reproducable [13:56] especially for gnome-panel [13:56] 90% of those are "I was not going anything special and it crashed" [13:56] seb128: package applets out-of-process during the development cycle, then? :-) [13:56] I can do that for sure === gnomefreak76 is now known as gnomefreak [13:56] I will do it with the 2.29 update [13:56] I understand it's not easy [13:57] I'm fine changing build options [13:57] just trying to figure out how the best way for upstream and downstream here [13:57] I just know that asking submitters to install something and reproduce doesn't work in 95% of the cases [13:57] yeah [13:57] true [13:57] if you think the build change would lead to better stacktrace I'm all for it [13:58] I don't get why there is no notification area symbol there though [13:58] if it crashes in the notification-area code [13:58] hey tedg [13:59] vuntz, btw what part of the sourcecode does the applet loading? [13:59] the applets rather [13:59] ie where should I put marked for "start loading " [13:59] "done loading " [13:59] markers [13:59] seb128: panel-applet-frame.c [13:59] thanks [14:00] vuntz, any clue with those crashes have no gnome-panel symbols btw? [14:00] seb128: well, I have a few bugs upstream that are crashes of the out-of-process notification area, and this is in gtk/gtk only [14:00] changing the build mode will lead to the applet crash rather than gnome-panel [14:00] in this case, my guess is that's it's related to some change that was done about transparency [14:00] but will probably not solve the stracktrace issue [14:01] ie those will still have no symbols [14:01] you will just know what process crashes [14:01] seb128: yeah, but knowing that it's the notification area and not gnome-panel+clock+notification area+... is better [14:01] makes sense === gnomefreak is now known as gnomefreak76 === gnomefreak76 is now known as gnomefreak [14:02] vuntz, quick question for you, what pygame version has opensuse? [14:02] your current unstable [14:04] seb128: 1.9.0, apparently [14:05] vuntz, ok, thanks [14:05] pedro_ has been busy today ;) [14:05] i just checked my inbox [14:06] well i have less isos to test , so more time to triage :-P [14:06] Good morning vuntz [14:09] seb128: hi... i didnt understand your response on Bug 437532 .. :( [14:09] tedg, I said hey and your reply to vuntz! [14:09] bug #437532 [14:09] seb128: Heh, sorry. Not through my first cup of coffee, I can't tell Frenchmen apart yet :) [14:09] * vish wonders what's up with bot [14:09] vish, nautilus uses an application indicator now [14:09] seb128: https://bugs.launchpad.net/bugs/437532 :) [14:10] vish, the applet does the icon rendering [14:10] and it's supposed to append something to the name in an automatic way [14:10] and check for that [14:10] this way we don't need any app change [14:10] seb128: so is the icon not needed? i'm a bit confused :( [14:10] it's done transparantly applet side [14:10] tedg, ^ can you confirm that's done yet? [14:10] tedg, the "use monochrome icons" [14:11] or "custom indicator theme" [14:11] or whatever it's called [14:11] seb128: No, we're not appending anything on the icon name yet. [14:11] tedg, but you will? [14:11] seb128: We should, but there aren't any done by the art team so I wasn't up on it :) [14:11] tedg, or do we need to patch applications? [14:11] Yes, we will. [14:11] tedg: hi.. we've been adding monochrome icons to humanity using the -symbolic names , how are we supposed to do it? [14:12] vish: Uhm, sure. The only thing I'm a bit worried about is that we probably won't have time to do all the stuff we wanted to do with the "symbolic" suffix like we discussed at UDS. I'm curious if we should reserve that suffix until we can do the whole enchilada. [14:13] vish: But, honestly. As long as you use a consistent name, a script can change them all pretty quickly :) [14:13] tedg: ah , cool :) [14:14] tedg: hola. I just replied to your mail :-) [14:16] vuntz: Thank you! [14:23] vish, you can close the bug [14:23] seb128: ok.. [14:23] seb128: but seems tedg mentioned above apps need patch^? [14:23] [19:41] tedg, or do we need to patch applications? [14:23] [19:41] Yes, we will. [14:24] vish: Sorry, no I was saying that we will handle it on the indicator side. [14:24] vish: We need to fix those, not the apps. [14:24] tedg: ah , thanks :) [14:24] * vish closing bug [14:43] seb128: alias dreb='debuild -us -uc -nc' === robbiew_ is now known as robbiew [14:54] asac, heh, I don't want to be responsive for those libs ;-) [14:54] I've enough to do [14:54] I just want the gvfs backend to build [14:54] I'm also not sure how to fix the shlibs warnings [14:55] it uses --as-needed [14:55] is there anything else to add? [14:57] pitti - is there anything to fix in g-p-m for bug 432598? g-p-m doesn't provide an interface for initiating suspend/hibernate any more, so don't these checks need to go in to the session applet instead? [14:58] seb128: good question. i dont see those libs being linked directly in the log [14:58] seb128: but symbol gcry_control used by debian/libiphone0/usr/lib/libiphone.so.0.0.0 found in none of the libraries. [14:58] that looks odd [14:58] i think its ok if you fix the ABI tracking stuff and subscribe team to bugs ;) [14:59] and checkout that symbol [15:00] ok [15:00] I like shlibs better that .symbols [15:00] but let's see ;-) [15:00] symbols is better [15:00] :) [15:00] hehe [15:00] it's slower [15:00] the symbol lookup things is ridiculously slow [15:00] anyway, even shlibs stuff isnt in place from what i can tell [15:00] at least not explicitly [15:01] right [15:01] thanks for review [15:01] I will fix those [15:01] good. [15:01] cant the desktop-team as a whole just take responsibility? [15:01] even if that is just: hunt down anyone using libiphone in main to commit to support that ;) [15:01] i really think if you subscribe to bugs you are already responsible :-P [15:02] do you know if usbmuxd is run as root? [15:03] ok updated bug with shortlist discussedhere [15:05] how do we remove a debconf template from cache? i though there was a debconf command/function to clean [15:05] asac, no it doesn't [15:05] run as usbmux [15:06] thanks [15:06] it's also not running all time [15:06] just when a device is detected [15:26] asac, re fontconfig, bug 490326, I have the debdiffs up in the same place as before [15:33] did you update your bzr branch? [15:33] cyphermox: ? [15:33] http://bazaar.launchpad.net/~mathieu-tl/ubuntu/lucid/fontconfig/merge-to-2.8.0-2.lp490326 [15:34]