=== asac_ is now known as asac [03:21] hey all, I'm working on a new app that is currently in alpha right now, but I could really use bugs/support in improving the app's experience. What is the best way to get people interested in this project? It's on launchpad with a PPA right now. [06:43] Good morning [06:43] robert_ancell, jasoncwarner1: I'm not that picky about the attendand list; we have other means to ping people [06:44] pitti, hello [06:44] micahg, RAOF: not sure what you mean about "rate limit", but apport limits the number of crash reports per day per program to at most 2 [06:45] hey robert_ancell, how are you? [06:45] pitti, good, busy :) [06:46] pitti: Is that at the collection point, or submission point? The problem is that the gpu hook can trigger multiple times a second for a good long while, leaving you with hundreds of stored duplicate reports. [06:46] pitti: must be a bug somewhere then, I can get much more than 2, http://paste.ubuntu.com/540921/ [06:46] Also, good morning pitti :) [06:47] more than that, but it shows the point sufficiently [06:48] RAOF: oh, we don't rate-limit the hooks [06:48] just the crashes from segfault/python [06:49] RAOF: this needs to get built into that GPU hook indeed; would you mind filing a bug about it and assign it to me? [06:49] pitti: Certainly. [06:49] That'd be filed against x-x-v-intel, right? Where the hook is? [06:52] Also, would you like to give my core-dev application an endorsement, at your leisure? ☺ https://wiki.ubuntu.com/ChrisHalseRogers/CoreDevApplication [06:54] RAOF: oh, I thought we ship that in apport, but you are right [06:55] RAOF: oh, with pleasure! === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [07:24] good morning [07:24] Howdie didrocks [07:25] hey RAOF, how are you? [07:25] Awwlright. [07:25] A bit tired, but I've bent the X server to my will, which is satisfying. [07:27] How about your fine self? [07:27] sure :) [07:27] yeah I'm fine [07:27] will do a quick unity binary python script today [07:27] that will make people's life soooooo easier [07:27] like "clean my compiz unity config" :) [07:29] Mmm, cleaning [09:52] mvo, good morning, I have a riddle for you [09:56] mvo == batman? [10:01] hey mpt [10:01] rickspencer3: haha [10:07] mvo, http://paste.ubuntu.com/540836/ [10:07] mvo, that's USC 1.0 crashing. Is it at all possible that 3.0 could have the same problem? [10:09] mpt: the current version will ignore errors like this, probably 2.0 as well. anoying that 1.0 did not, is it common? the fix is trivial and we could SRU it [10:10] mvo, I don't know if it's common, someone just asked me on Twitter about it :-) [10:16] I guess if we had a crash database we'd know how common it was [10:16] * mvo nods [10:20] mvo, bug 630248 shows it happening in bug 2.1.14.1, bug 661956 and bug 683626 in 3.0.4, bug 667057 in 3.0.5. [10:20] mpt: Bug 630248 on http://launchpad.net/bugs/630248 is private [10:20] mpt: Bug 661956 on http://launchpad.net/bugs/661956 is private [10:20] mpt: Bug 683626 on http://launchpad.net/bugs/683626 is private [10:20] mpt: Bug 667057 on http://launchpad.net/bugs/667057 is private [10:20] ubot2, no they aren't [10:20] Factoid "no they aren't" not found [10:22] mpt: well, not quite. that is also a bug, but a different one [10:23] mpt: let me fix that [10:23] mpt: it will only happen if someone changed their locale but did not generate the needed data (that is done automatically when you use language-selector) [10:24] hm, bazaar.launchpad.net down :/ ? [10:24] Everything's down except the Web interface right now [10:24] (that's why ubot2 thought the bugs were read-only) [10:25] aha, ok. in this case I will take the time to make a cup of tea [10:25] (or a pot) [10:25] mvo, I see, all those reported bugs are about apthistory.py as opposed to aptdaemon/client.py [10:25] yeah, still thanks for pointing them out, I fix this one [10:29] hrm, that is a nasty one actualy, its locale independant code and yet it parses it for no good reason [10:39] mpt: bug fixed (modulo that I can not commit it yet) [10:39] mvo, the apthistory.py one? [10:42] mpt: yes === zyga-afk is now known as zyga [11:00] mvo, so for the client.py one, would a workaround be to use gnome-language-selector to choose another language, and then to reset to the original language? [11:01] (btw it looks like LP is back up) [11:27] didrocks: seems unity has an apport hook now, collecting the compiz info; we recently had an email exchange about that, is there still something missing which you'd like to see in unity bugs? [11:27] didrocks: (apart from the fact that it should be totally broken right now) [11:27] oh, sorry, it isn't broken [11:27] the import line is just not necessary at all [11:31] pitti, I did that one [11:31] pitti, I don't think there is anything especially missing, I've some pending tweaks to it though [11:31] ok, thanks [11:32] np [11:32] pitti: the WI is to improve it, like reporting the specifc unity settings we need [11:33] didrocks: ok; please let me know if you have something you'd like to add, but have trouble expressing that in terms of python and apport [11:34] pitti: sure, I'll have a look before the sprint, but it should be ok, maybe adding some questions we will find useful, but i've already done that in python & apport :) [11:34] thanks [12:01] mpt: yeah, the workaround for the client (and the others) is to use languageselector to generate the matching locales [12:02] ok, thanks mvo [12:04] yw [12:10] mvo: master [12:10] mvo: hope you are not lagging again [12:10] update-manager now hung and destroyed my disk ;) [12:11] j.k. [12:11] see msg [12:11] asac: ha! === MacSlow is now known as MacSlow|lunch [12:30] good morning everyone! [12:33] hey nessita, how are you? [12:34] pretty good, how are you? [12:35] I'm fine, thanks :) [12:37] hey nessita [12:47] seb128 - oh, i got your issue today with the doorhanger notification in firefox displaying on all desktops [12:47] i ran xprop on it [12:47] i might need to get the compiz guys to look at it though, as i'm not sure what properties would make it show on all desktops [12:48] chrisccoulson, talk to smspillaz [12:48] smspillaz, is there anything about this window that would make it display on all desktops in compiz: http://paste.ubuntu.com/540986/ [12:50] * smspillaz waits for firefox to open [12:51] lol [12:51] it should open fast now ;) [12:51] chrisccoulson: hmm? some natty change that makes it faster? [12:51] if it opens slowly, try killing syncdaemon, that normally works for me [12:51] hyperair, yeah, there's a lot of work gone in to improving startup time in firefox, and it opens much quicker now [12:51] chrisccoulson: is it firefox 4's "give feedback window" [12:51] ? [12:52] smspillaz, yes [12:52] chrisccoulson: is it any quicker than firefox 4.0 in the ubuntu-mozilla-daily ppa? [12:52] yeah, that's the one [12:52] hyperair, it shouldn't be [12:52] maybe that _NET_WINDOW_TYPE_UTILITY along with _NET_WM_ACTION_STICK would do it [12:52] chrisccoulson: aw. =\ [12:52] * smspillaz checks ewmh [12:52] smspillaz, ok, thanks [12:52] chrisccoulson: and there i was getting my hopes up [12:52] hyperair: we display certain window types as sticky [12:53] hyperair: tooltips, utility (I think) [12:53] smspillaz: er what? [12:53] ffox 4 starts here in around 3 seconds to a fully usable browser, with a restored session [12:53] that was random, i think [12:53] but i have to kill syncdaemon to get it to start that quickly [12:53] chrisccoulson: hmm. well chromium starts instantly. [12:53] hyperair, so does ffox with a fresh profile. i'm talking about a full session restore with lots of tabs [12:54] chrisccoulson: well so was i. for chromium [12:54] chromium just took 4 seconds on my laptop with no tabs :O [12:54] =O [12:54] blasphemy [12:56] ok, i just started ffox and chromium side-by-side (warm start), and there's no noticeable difference tbh [12:58] meh [12:58] firefox takes... 5 secs [12:58] and chrome takes 10.. [12:59] okay, a warm start makes chrome load faster [12:59] but firefox takes 3 seconds to warm start [12:59] maybe it's the plugins and extensions. [13:00] chrisccoulson: I haven't updated natty in a while, that may be why I am getting the slow starts :p [13:03] yeah, i need to update at some point [13:04] hyperair, yeah, extensions could cause that. i'd be interested if there is a particular extension which makes it slow though [13:04] if there is, then the extension author needs to fix that [13:05] chrisccoulson: probably all combined. [13:05] didn't someone try and make a compositing window manager with XUL ? [13:05] I remember seeing a project to do this somwhere [13:06] heh, that's a bit of a strange technology choice for a WM ;) [13:09] hyperair, mozilla are clamping down quite a bit with third-party extensions atm, particularly back-door extensions (ie, those which get installed in system locations by third party application installers without the users permission [13:09] (eg, anti-virus software) [13:09] mozilla bug 596343 [13:09] Mozilla bug 596343 in General "Users should have exclusive control over selecting their add-ons" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=596343 [13:09] there's a plan to disable these extensions on upgrade to ffox4, and give the user a dialog to re-enable the ones they want [13:33] hmm that's interesting === MacSlow|lunch is now known as MacSlow [13:43] chrisccoulson, i know ff4 feels snappier to me than chromium does, it has improved a lot [13:43] no stats, just it feels faster to me now [13:43] but i never install plugins or extensions [14:00] oooh [14:00] new gir1.0-appindicator-0.1 [14:00] * pitti hugs kenvandine [14:00] hehe... not gtk3 yet though [14:00] but at least it builds in natty now [14:00] for multiple python versions too :) [14:01] i will hopefully get the gtk3 bits done today/tomorrow [14:04] ah, ok [14:04] kenvandine: thanks anyway! at least it builds again [14:05] yeah, once i get libindicate building again [14:05] i'll go back to adding gtk3 to appindicator [14:05] kenvandine: I suppose we don't really need a GIR for the gtk2 version, right? [14:05] nope [14:05] well [14:05] there's still python-appindicator for that [14:05] and we shouldn't port to gtk2/gi [14:05] yeah, for python [14:06] and we don't really need gir for gtk2 version for anything other than generating the vapi [14:06] right, but that can happen during build; we don't need a separate binary package for that or so [14:07] true, so do you think i should put the gtk3 gir in gir1.0-appindicator-0.1? [14:07] we had a binary for that in maverick, even though it wasn't useful [14:07] for now I think yes [14:08] it's an interesting question what happens once we have gtk4 [14:08] then the package names won't be consistent [14:08] but that's hopefully several years away :) [14:08] seb128, so what do we need to have happen before we decide to push the GNOME3 control center and its related packages in? what's the blocker on that? More testing, more packages? [14:08] we'll have libappindicator1 and libappindicator3-1 [14:08] pitti, that's only a year away I believe [14:08] mterry: uh? [14:09] pitti, let me see if I can find the roadmap [14:09] oh man... i hope we aren't going to be building for gtk2, 3 and 4 :) [14:09] pitti, right, they want to do the next gtk in one yeat [14:09] pitti, that is what i heard [14:09] year [14:10] mterry, the issue is to know if GNOME3 will be ready for natty [14:10] like if they will manage to get something stable and we will manage to deal with the changes, updates our patches, deal with things they dropped [14:11] seb128, OK, so we're waiting for some number of people to feel like the GNOME3 PPA is solid? [14:11] mterry, right now it seems it could turn into a lot of work for little win [14:11] especially that we don't have the cycle to spend only on that [14:11] we will need to help on unity [14:12] mterry, I think we would be better saying that we keep it in the ppa for natty [14:12] but we will discuss that at the sprint [14:12] or rally rather ;-) [14:12] seb128, should i use the gnome3 ppa? [14:12] your call [14:12] would it be useful enough for testing? [14:12] we don't lack testing now [14:12] pitti, can't find an official roadmap, but I recall that being the decision after the latest gtk hackfest [14:13] i have been afraid too... since i have been working on getting things done specifically for natty right now [14:13] we don't need you to use the ppa [14:13] ok [14:13] then i won't for now :) [14:13] ok ;-) [14:22] * bcurtiswx_ waves to room [14:25] mvo: what is the status of update-manager-hildon ? python-hildon doesn't build from source, I can't really find a proper site with real tarball releases, 0.9.0 was released in april last year and update-manager-hildon is the only reverse dependency from what I can see. Should I work on fixing the failure or ask to remove python-hildon from archive? [14:26] seb128, did we ever hear back to know what to do next for empathy? [14:26] kenvandine, ^^ [14:26] bcurtiswx_, did you get it built? [14:27] kenvandine, no, it was a dh_* error due to nautilus-sendto-empathy iirc [14:27] oh, right it couldn't include that file [14:27] i would say just do what debian did for now [14:28] it would be useful to just get it built somewhere [14:30] kklimonda: I kill it [14:31] kklimonda: I mean, I kill update-manager-hildon [14:32] ok [14:36] kenvandine, hmm so do we need to change the control file of nautilus-sendto-empathy ? [14:36] that was in the control file for empathy right? [14:36] i think debian just commented it all out [14:40] bcurtiswx_, kenvandine: no we don't [14:40] the nautilus in the ppa should be recent enough [14:40] you just need to figure the right build depends [14:40] or to check if the configure needs to be updated [14:40] there is no reason to comment the binary [14:41] then it is probably just debian/nautilus-sendto-empathy.install [14:41] that needs to be changed [14:42] either that or a build-depends need to be updated [14:42] what is the configure output? [14:42] mpt: I spend a bit of time today on deb-thumbnailer, almost ready [14:42] do you have the build log somewhere? [14:42] so the build-dep of nautilus-sendto or just nautilus needs to be there. i got confused when someone said the sendto is now in nautilus [14:43] diff the empathy configure between version [14:43] so you can figure what build-depends need to be updated or added [14:48] mvo, cool! [14:49] bcurtiswx_, it is very useful to look at the configure.ac in the upstream source [14:49] to see what packages it checks for and versions [14:50] so you need to make sure you have build depends for whatever package provides the pkgconfig file for the pkg it checks for [14:52] kenvandine, i have done this already. My earlier issue (which I think caused a lot of these issues) is that when I try to install nautilus-sendto right now (with the GNOME3 PPA) it tries uninstalling the rest of nautilus [14:52] it won't let me install nautilus-sendto [14:53] bcurtiswx_, nautilus-sendto is deprecated [14:53] it's part of nautilus [14:53] just install nautilus from the ppa and you get it [14:53] so when nautilus-sendto is required by empathy what am I supposed to do ? [14:53] seb128, ^^ [14:54] did you ask cassidy? [14:54] seb128, we still need to depend on nautilus-sendto, see https://bugzilla.gnome.org/show_bug.cgi?id=636377 [14:54] Gnome bug 636377 in General "Bump nautilus dep to >2.91.1 as -sendto is now in-tree" [Normal,Resolved: notabug] [14:55] I'm completely lost on what to do next [14:56] cassidy, but I though there was no nautilus-sendto in 2.91? [14:56] the helper lib is still in a separated module I think [14:57] bcurtiswx_, ok, so comment the binary and drop the .install [14:57] what debian did [14:58] cassidy, seb128. the .install file has usr/lib/nautilus-sendto/plugins/libnstempathy.so .. the directory exists.. but no .so file [15:00] drop the .install [15:00] not sure what GNOME3 is supposed to do with that [15:00] but if the .so is not there comment the binary for now [15:00] OK [15:08] seb128, what might be looking for the nautilus-sendto-empathy.install because i can't find it anywhere and I can't build because of it [15:09] did you read the debian diff I pointed yesterday? [15:09] comment the binary in the control.in [15:13] seb128, im sorry. i don't see a control.in [15:13] so control [15:13] in the debian dir [15:13] yes [15:13] the file which has the build-depends, depends, binaries etc [15:13] comment the sendtoone [15:13] one [15:14] yes.. i already commented that out.. still looking for a nautilius-sendto-empathy.install [15:15] grep nautilius-sendto-empathy debian [15:15] grep for nautilus-sendto in the debian dir files [15:16] mterry, hey, could you resync libcanberra on debian? [15:16] seb128, sur [15:16] thanks [15:17] they got the gtk3 version in experimental [15:17] so we should make sure we use same naming etc than they do [15:18] mterry, if you want to do gobject-introspection as well you are welcome ;-) [15:18] seb128, yes i've done that and everything is commented out.. with the # [15:18] unless # isn't a comment in a control file [15:19] seb128, we'll see, but probably [15:19] ok thanks [15:19] bcurtiswx_, how do you build? [15:19] bcurtiswx_, can you push you work somewhere? [15:19] bzr bd [15:19] yes i will push it if this one last thing doesn't work [15:22] seb128, https://code.edge.launchpad.net/~bcurtiswx/ubuntu/natty/empathy/empathy-2.91.3 [15:23] bcurtiswx_, thanks === bjf[afk] is now known as bjf [15:26] bcurtiswx_, what error do you get during the build? [15:26] seb128, well now nothing.. apparently i don't know that a commit is required before a bzr bd ? [15:27] it should not be required [15:27] well it wasn't working before.. but all of the sudden it is.. afte ri committed [15:27] weird [15:28] i feel like a retarded kid.. but /me shrugs [15:38] seb128, that built fine [15:39] great [15:40] but [15:41] seb128, Gtk-ERROR **: GTK+ 3 symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported [15:41] when running ^^ [15:42] no clue why it could do that [15:42] kenvandine, have you see that before ^^ [15:42] well it means it loads gtk2 code [15:42] dunno why though [15:42] cassidy, ^ do you have any clue? [15:42] pitti, seems the launchpad update broke the retracers :-( [15:42] pitti, they are hanging [15:43] seb128: again? I restarted them about an hour ago [15:43] *sigh* [15:43] seb128, could it be the patches? some worked but none have been converted to GTK3 [15:43] pitti, well they seem to be stucked [15:43] pitti, I killed them manually an hour ago because they were stucked for an hour [15:43] seb128, empathy is linked on both GTK ? [15:43] with nothing in the logs [15:43] seb128: gtkmm blog queued up, I am waiting for my blog service to fix RSS feeds so it'll come tomorrow or something. [15:43] cassidy, well, it could be that it loads a .so or something [15:43] jcastro, ok thanks! [15:43] the control center maybe ? [15:44] kklimonda: nice work on gtkmm, I know the stack's been frustrating for upstream over the years [15:44] empathy itself shouldn't link on GTK2 any more [15:44] cassidy, ok thanks, I've an idea I think [15:44] bcurtiswx_, the lpi patch needs to use the gtk3 version of lpi [15:45] so dh_python is now preferred over pysupport right? [15:45] pitti, do you have some time to investigate the retracer issue or should I try to do that? [15:45] jcastro: hopefully we can get it into shape (and keep it that way) this cycle. [15:45] seb128: I'm currently fighting with OpenOffice; I can try tomorrow morning [15:46] pitti, ok, I will just run a retracing manually to see what's going on exactly [15:46] seb128: thanks [15:46] np [15:46] seb128: do the dup checker, it's easier [15:46] requires no chroot [15:46] right [15:47] seb128, what's the gtk3 version of lpi ? [15:47] seb128, pitti: dh_python is preferred over pysupport right? [15:47] * kenvandine can never keep up with that :) [15:47] kenvandine,you should ask to doko or barry [15:47] kenvandine: dh_python{2,3} are the most preferred now [15:48] I'm not uptodate on python packaging preferred ways [15:48] they don't need any extra build deps [15:48] wondering if i should change libindicate and appindicator while i am messing with them [15:48] and work just fine [15:48] should be a simple change [15:48] bcurtiswx_: liblaunchpad-integration [15:48] bcurtiswx_, the library has gtk2 and gtk3 versions [15:48] bcurtiswx_, you need the one with a -3 in the name [15:48] same of the configure check [15:49] you need to check for the gtk3 one [15:49] bcurtiswx_, launchpad-integration-3.0 [15:49] in the lpi configure patch [15:49] rather than "launchpad-integration" [15:49] seb128, OK is the .h file needing the -3.0 as well ? [15:50] bcurtiswx_, no [15:50] bcurtiswx_, it's in a different directory but the pkg-config call handle that [15:51] OK building again [15:52] seb128, says launchpad-integration-3.0 doesn't exist, is it in the GNOME3 PPA ? [15:52] it's in natty [15:53] you don't make lot of efforts before asking do you ;-) [15:53] run apt-cache search launchpad integration gtk 3 [15:53] ugh, i do... sorry for apparently being lazy [15:55] Laney: we still waiting on MIR stuff? [15:56] bcurtiswx_, no worry [15:56] bcurtiswx_, install liblaunchpad-integration-3.0-dev [15:56] bcurtiswx_, it's the gtk3 version [15:56] you need to update the build-depends as well [15:57] and change the patch [15:57] admittedly, there's a lot i need to learn.. stuff that may come quick and naturally to a lot of you.. I am sorry for appearing certain ways, but I can only say that I'm learning and please bear with me [15:58] to check, the part of the patch that changes configure.ac, make it check for launchpad-integration-3.0 instead of launchpad-integration [15:58] bcurtiswx_, ^^ [15:59] kenvandine, thanks. I've taken care of the 01_lpi.patch fix.. should I put a version on the -3.0 dep or leave one off ? [16:02] if it didn't have it before, just leave it off [16:02] kenvandine, it did before. [16:05] i'll just take the old version off, leave it as none for now [16:08] ok, libindicate transition to dh_python2 was quite painless, maybe i'll do appindicator for good measure [16:10] hmmm, no ted [16:11] does anyone know if libdbusmenu-gtk is going to be using gtk2 or gtk3? [16:11] (or will there be 2 versions?) [16:11] seb128 - not sure if you know the answer to that? :) [16:11] chrisccoulson, both versions [16:11] it's pending upload, kenvandine has it ready [16:11] seb128 - ok, thanks. so, it's safe for me to use in ffox :) [16:12] speak of the devil :) [16:13] i was just thinking the same thing! [16:13] tedg, how is the gdbus branch of dbusmenu looking? [16:13] chrisccoulson, you mean you don't plan to use gtk3 in firefox?! ;-) [16:13] seb128 - no, i think i'll leave that one for now ;) [16:14] chrisccoulson, fun weekend project :) [16:14] i might give it a try if i get bored ;) [16:14] chrisccoulson, you start being lazy I see ;-) [16:15] perhaps over the christmas break ;) [16:15] ;-) [16:15] you first refused to take over libreoffice and now that... [16:15] lol [16:15] i hear pitti is doing libreoffice now anyway [16:16] :) [16:16] \o/ [16:16] ;-) [16:16] * pitti slaps chrisccoulson [16:16] kenvandine, Looking pretty good. I have libappindicator building with it now -- fixed some pkgconfig errors. [16:16] lol [16:16] chrisccoulson, just because you are doing firefox gtk3 :) [16:16] kenvandine, So I'm getting relatively happy :) [16:16] I've the feeling chrisccoulson would still prefer porting firefox ;-) [16:16] oh yes! [16:16] :) [16:16] so would I :) [16:17] * kenvandine is a bit annoyed... no problem getting dh_autoreconf working with libindicate doing multiple python versions [16:17] but it wouldn't work for anything in appindicator! [16:17] kenvandine: you are doing multiple build trees? but that should be done after autoreconf, no? [16:17] yeah [16:18] but it was causing make to re-run configure [16:18] and getting the flags wrong or something [16:18] it isn't doing that in libindicate [16:18] no clue why [16:18] but i spent way too much time trying to make that work in appindicator [16:19]