[03:21] <aroman> 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] <pitti> Good morning
[06:43] <pitti> robert_ancell, jasoncwarner1: I'm not that picky about the attendand list; we have other means to ping people
[06:44] <robert_ancell> pitti, hello
[06:44] <pitti> 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] <pitti> hey robert_ancell, how are you?
[06:45] <robert_ancell> pitti, good, busy :)
[06:46] <RAOF> 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] <micahg> pitti: must be a bug somewhere then, I can get much more than 2, http://paste.ubuntu.com/540921/
[06:46] <RAOF> Also, good morning pitti :)
[06:47] <micahg> more than that, but it shows the point sufficiently
[06:48] <pitti> RAOF: oh, we don't rate-limit the hooks
[06:48] <pitti> just the crashes from segfault/python
[06:49] <pitti> 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] <RAOF> pitti:  Certainly.
[06:49] <RAOF> That'd be filed against x-x-v-intel, right?  Where the hook is?
[06:52] <RAOF> Also, would you like to give my core-dev application an endorsement, at your leisure? ☺ https://wiki.ubuntu.com/ChrisHalseRogers/CoreDevApplication
[06:54] <pitti> RAOF: oh, I thought we ship that in apport, but you are right
[06:55] <pitti> RAOF: oh, with pleasure!
[07:24] <didrocks> good morning
[07:24] <RAOF> Howdie didrocks
[07:25] <didrocks> hey RAOF, how are you?
[07:25] <RAOF> Awwlright.
[07:25] <RAOF> A bit tired, but I've bent the X server to my will, which is satisfying.
[07:27] <RAOF> How about your fine self?
[07:27] <didrocks> sure :)
[07:27] <didrocks> yeah I'm fine
[07:27] <didrocks> will do a quick unity binary python script today
[07:27] <didrocks> that will make people's life soooooo easier
[07:27] <didrocks> like "clean my compiz unity config" :)
[07:29] <RAOF> Mmm, cleaning
[09:52] <mpt> mvo, good morning, I have a riddle for you
[09:56] <rickspencer3> mvo == batman?
[10:01] <mvo> hey mpt
[10:01] <mvo> rickspencer3: haha
[10:07] <mpt> mvo, http://paste.ubuntu.com/540836/
[10:07] <mpt> mvo, that's USC 1.0 crashing. Is it at all possible that 3.0 could have the same problem?
[10:09] <mvo> 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] <mpt> mvo, I don't know if it's common, someone just asked me on Twitter about it :-)
[10:16] <mpt> I guess if we had a crash database we'd know how common it was
[10:16]  * mvo nods
[10:20] <mpt> mvo, bug 630248 shows it happening in bug <IP_ADDRESS>, bug 661956 and bug 683626 in 3.0.4, bug 667057 in 3.0.5.
[10:20] <ubot2> mpt: Bug 630248 on http://launchpad.net/bugs/630248 is private
[10:20] <ubot2> mpt: Bug 661956 on http://launchpad.net/bugs/661956 is private
[10:20] <ubot2> mpt: Bug 683626 on http://launchpad.net/bugs/683626 is private
[10:20] <ubot2> mpt: Bug 667057 on http://launchpad.net/bugs/667057 is private
[10:20] <mpt> ubot2, no they aren't
[10:20] <ubot2> Factoid "no they aren't" not found
[10:22] <mvo> mpt: well, not quite. that is also a bug, but a different one
[10:23] <mvo> mpt: let me fix that
[10:23] <mvo> 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] <mvo> hm, bazaar.launchpad.net down :/ ?
[10:24] <mpt> Everything's down except the Web interface right now
[10:24] <mpt> (that's why ubot2 thought the bugs were read-only)
[10:25] <mvo> aha, ok. in this case I will take the time to make a cup of tea
[10:25] <mvo> (or a pot)
[10:25] <mpt> mvo, I see, all those reported bugs are about apthistory.py as opposed to aptdaemon/client.py
[10:25] <mvo> yeah, still thanks for pointing them out, I fix this one
[10:29] <mvo> hrm, that is a nasty one actualy, its locale independant code and yet it parses it for no good reason
[10:39] <mvo> mpt: bug fixed (modulo that I can not commit it yet)
[10:39] <mpt> mvo, the apthistory.py one?
[10:42] <mvo> mpt: yes
[11:00] <mpt> 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] <mpt> (btw it looks like LP is back up)
[11:27] <pitti> 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] <pitti> didrocks: (apart from the fact that it should be totally broken right now)
[11:27] <pitti> oh, sorry, it isn't broken
[11:27] <pitti> the import line is just not necessary at all
[11:31] <seb128> pitti, I did that one
[11:31] <seb128> pitti, I don't think there is anything especially missing, I've some pending tweaks to it though
[11:31] <pitti> ok, thanks
[11:32] <seb128> np
[11:32] <didrocks> pitti: the WI is to improve it, like reporting the specifc unity settings we need
[11:33] <pitti> 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] <didrocks> 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] <didrocks> thanks
[12:01] <mvo> mpt: yeah, the workaround for the client (and the others) is to use languageselector to generate the matching locales
[12:02] <mpt> ok, thanks mvo
[12:04] <mvo> yw
[12:10] <asac> mvo: master
[12:10] <asac> mvo: hope you are not lagging again
[12:10] <asac> update-manager now hung and destroyed my disk ;)
[12:11] <asac> j.k.
[12:11] <asac> see msg
[12:11] <mvo> asac: ha!
[12:30] <nessita> good morning everyone!
[12:33] <didrocks> hey nessita, how are you?
[12:34] <nessita> pretty good, how are you?
[12:35] <didrocks> I'm fine, thanks :)
[12:37] <seb128> hey nessita
[12:47] <chrisccoulson> seb128 - oh, i got your issue today with the doorhanger notification in firefox displaying on all desktops
[12:47] <chrisccoulson> i ran xprop on it
[12:47] <chrisccoulson> 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] <seb128> chrisccoulson, talk to smspillaz
[12:48] <chrisccoulson> 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] <chrisccoulson> lol
[12:51] <chrisccoulson> it should open fast now ;)
[12:51] <hyperair> chrisccoulson: hmm? some natty change that makes it faster?
[12:51] <chrisccoulson> if it opens slowly, try killing syncdaemon, that normally works for me
[12:51] <chrisccoulson> hyperair, yeah, there's a lot of work gone in to improving startup time in firefox, and it opens much quicker now
[12:51] <smspillaz> chrisccoulson: is it firefox 4's  "give feedback window"
[12:51] <smspillaz>  ?
[12:52] <seb128> smspillaz, yes
[12:52] <hyperair> chrisccoulson: is it any quicker than firefox 4.0 in the ubuntu-mozilla-daily ppa?
[12:52] <chrisccoulson> yeah, that's the one
[12:52] <chrisccoulson> hyperair, it shouldn't be
[12:52] <smspillaz> maybe that _NET_WINDOW_TYPE_UTILITY along with _NET_WM_ACTION_STICK would do it
[12:52] <hyperair> chrisccoulson: aw. =\
[12:52]  * smspillaz checks ewmh
[12:52] <chrisccoulson> smspillaz, ok, thanks
[12:52] <hyperair> chrisccoulson: and there i was getting my hopes up
[12:52] <smspillaz> hyperair: we display certain window types as sticky
[12:53] <smspillaz> hyperair: tooltips, utility (I think)
[12:53] <hyperair> smspillaz: er what?
[12:53] <chrisccoulson> ffox 4 starts here in around 3 seconds to a fully usable browser, with a restored session
[12:53] <hyperair> that was random, i think
[12:53] <chrisccoulson> but i have to kill syncdaemon to get it to start that quickly
[12:53] <hyperair> chrisccoulson: hmm. well chromium starts instantly.
[12:53] <chrisccoulson> hyperair, so does ffox with a fresh profile. i'm talking about a full session restore with lots of tabs
[12:54] <hyperair> chrisccoulson: well so was i. for chromium
[12:54] <chrisccoulson> chromium just took 4 seconds on my laptop with no tabs :O
[12:54] <hyperair> =O
[12:54] <hyperair> blasphemy
[12:56] <chrisccoulson> ok, i just started ffox and chromium side-by-side (warm start), and there's no noticeable difference tbh
[12:58] <hyperair> meh
[12:58] <hyperair> firefox takes... 5 secs
[12:58] <hyperair> and chrome takes 10..
[12:59] <hyperair> okay, a warm start makes chrome load faster
[12:59] <hyperair> but firefox takes 3 seconds to warm start
[12:59] <hyperair> maybe it's the plugins and extensions.
[13:00] <smspillaz> chrisccoulson: I haven't updated natty in a while, that may be why I am getting the slow starts :p
[13:03] <chrisccoulson> yeah, i need to update at some point
[13:04] <chrisccoulson> hyperair, yeah, extensions could cause that. i'd be interested if there is a particular extension which makes it slow though
[13:04] <chrisccoulson> if there is, then the extension author needs to fix that
[13:05] <hyperair> chrisccoulson: probably all combined.
[13:05] <smspillaz> didn't someone try and make a compositing window manager with XUL ?
[13:05] <smspillaz> I remember seeing a project to do this somwhere
[13:06] <chrisccoulson> heh, that's a bit of a strange technology choice for a WM ;)
[13:09] <chrisccoulson> 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] <chrisccoulson> (eg, anti-virus software)
[13:09] <chrisccoulson> mozilla bug 596343
[13:09] <ubot2> 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] <chrisccoulson> 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] <hyperair> hmm that's interesting
[13:43] <kenvandine> chrisccoulson, i know ff4 feels snappier to me than chromium does, it has improved a lot
[13:43] <kenvandine> no stats, just it feels faster to me now
[13:43] <kenvandine> but i never install plugins or extensions
[14:00] <pitti> oooh
[14:00] <pitti> new gir1.0-appindicator-0.1
[14:00]  * pitti hugs kenvandine
[14:00] <kenvandine> hehe... not gtk3 yet though
[14:00] <kenvandine> but at least it builds in natty now
[14:00] <kenvandine> for multiple python versions too :)
[14:01] <kenvandine> i will hopefully get the gtk3 bits done today/tomorrow
[14:04] <pitti> ah, ok
[14:04] <pitti> kenvandine: thanks anyway! at least it builds again
[14:05] <kenvandine> yeah, once i get libindicate building again
[14:05] <kenvandine> i'll go back to adding gtk3 to appindicator
[14:05] <pitti> kenvandine: I suppose we don't really need a GIR for the gtk2 version, right?
[14:05] <kenvandine> nope
[14:05] <kenvandine> well
[14:05] <pitti> there's still python-appindicator for that
[14:05] <pitti> and we shouldn't port to gtk2/gi
[14:05] <kenvandine> yeah, for python
[14:06] <kenvandine> and we don't really need gir for gtk2 version for anything other than generating the vapi
[14:06] <pitti> right, but that can happen during build; we don't need a separate binary package for that or so
[14:07] <kenvandine> true, so do you think i should put the gtk3 gir in gir1.0-appindicator-0.1?
[14:07] <kenvandine> we had a binary for that in maverick, even though it wasn't useful
[14:07] <pitti> for now I think yes
[14:08] <pitti> it's an interesting question what happens once we have gtk4
[14:08] <kenvandine> then the package names won't be consistent
[14:08] <pitti> but that's hopefully several years away :)
[14:08] <mterry> 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] <kenvandine> we'll have libappindicator1 and libappindicator3-1
[14:08] <mterry> pitti, that's only a year away I believe
[14:08] <pitti> mterry: uh?
[14:09] <mterry> pitti, let me see if I can find the roadmap
[14:09] <kenvandine> oh man... i hope we aren't going to be building for gtk2, 3 and 4 :)
[14:09] <seb128> pitti, right, they want to do the next gtk in one yeat
[14:09] <kenvandine> pitti, that is what i heard
[14:09] <seb128> year
[14:10] <seb128> mterry, the issue is to know if GNOME3 will be ready for natty
[14:10] <seb128> 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] <mterry> seb128, OK, so we're waiting for some number of people to feel like the GNOME3 PPA is solid?
[14:11] <seb128> mterry, right now it seems it could turn into a lot of work for little win
[14:11] <seb128> especially that we don't have the cycle to spend only on that
[14:11] <seb128> we will need to help on unity
[14:12] <seb128> mterry, I think we would be better saying that we keep it in the ppa for natty
[14:12] <seb128> but we will discuss that at the sprint
[14:12] <seb128> or rally rather ;-)
[14:12] <kenvandine> seb128, should i use the gnome3 ppa?
[14:12] <seb128> your call
[14:12] <kenvandine> would it be useful enough for testing?
[14:12] <seb128> we don't lack testing now
[14:12] <mterry> pitti, can't find an official roadmap, but I recall that being the decision after the latest gtk hackfest
[14:13] <kenvandine> i have been afraid too... since i have been working on getting things done specifically for natty right now
[14:13] <seb128> we don't need you to use the ppa
[14:13] <kenvandine> ok
[14:13] <kenvandine> then i won't for now :)
[14:13] <seb128> ok ;-)
[14:22]  * bcurtiswx_ waves to room
[14:25] <kklimonda> 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] <bcurtiswx_> seb128, did we ever hear back to know what to do next for empathy?
[14:26] <bcurtiswx_> kenvandine, ^^
[14:26] <kenvandine> bcurtiswx_, did you get it  built?
[14:27] <bcurtiswx_> kenvandine, no, it was a dh_* error due to nautilus-sendto-empathy iirc
[14:27] <kenvandine> oh, right it couldn't include that file
[14:27] <kenvandine> i would say just do what debian did for now
[14:28] <kenvandine> it would be useful to just get it built somewhere
[14:30] <mvo> kklimonda: I kill it
[14:31] <mvo> kklimonda: I mean, I kill update-manager-hildon
[14:32] <kklimonda> ok
[14:36] <bcurtiswx_> kenvandine, hmm so do we need to change the control file of nautilus-sendto-empathy ?
[14:36] <kenvandine> that was in the control file for empathy right?
[14:36] <kenvandine> i think debian just commented it all out
[14:40] <seb128> bcurtiswx_, kenvandine: no we don't
[14:40] <seb128> the nautilus in the ppa should be recent enough
[14:40] <seb128> you just need to figure the right build depends
[14:40] <seb128> or to check if the configure needs to be updated
[14:40] <seb128> there is no reason to comment the binary
[14:41] <kenvandine> then it is probably just debian/nautilus-sendto-empathy.install
[14:41] <kenvandine> that needs to be changed
[14:42] <seb128> either that or a build-depends need to be updated
[14:42] <seb128> what is the configure output?
[14:42] <mvo> mpt: I spend a bit of time today on deb-thumbnailer, almost ready
[14:42] <seb128> do you have the build log somewhere?
[14:42] <bcurtiswx_> 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] <seb128> diff the empathy configure between version
[14:43] <seb128> so you can figure what build-depends need to be updated or added
[14:48] <mpt> mvo, cool!
[14:49] <kenvandine> bcurtiswx_, it is very useful to look at the configure.ac in the upstream source
[14:49] <kenvandine> to see what packages it checks for and versions
[14:50] <kenvandine> 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] <bcurtiswx_> 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] <bcurtiswx_> it won't let me install nautilus-sendto
[14:53] <seb128> bcurtiswx_, nautilus-sendto is deprecated
[14:53] <seb128> it's part of nautilus
[14:53] <seb128> just install nautilus from the ppa and you get it
[14:53] <bcurtiswx_> so when nautilus-sendto is required by empathy what am I supposed to do ?
[14:53] <bcurtiswx_> seb128, ^^
[14:54] <seb128> did you ask cassidy?
[14:54] <cassidy> seb128, we still need to depend on nautilus-sendto, see https://bugzilla.gnome.org/show_bug.cgi?id=636377
[14:54] <ubot2> Gnome bug 636377 in General "Bump nautilus dep to >2.91.1 as -sendto is now in-tree" [Normal,Resolved: notabug]
[14:55] <bcurtiswx_> I'm completely lost on what to do next
[14:56] <seb128> cassidy, but I though there was no nautilus-sendto in 2.91?
[14:56] <cassidy> the helper lib is still in a separated module I think
[14:57] <seb128> bcurtiswx_, ok, so comment the binary and drop the .install
[14:57] <seb128> what debian did
[14:58] <bcurtiswx_> cassidy, seb128.  the .install file has usr/lib/nautilus-sendto/plugins/libnstempathy.so .. the directory exists.. but no .so file
[15:00] <seb128> drop the .install
[15:00] <seb128> not sure what GNOME3 is supposed to do with that
[15:00] <seb128> but if the .so is not there comment the binary for now
[15:00] <bcurtiswx_> OK
[15:08] <bcurtiswx_> 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] <seb128> did you read the debian diff I pointed yesterday?
[15:09] <seb128> comment the binary in the control.in
[15:13] <bcurtiswx_> seb128, im sorry. i don't see a control.in
[15:13] <seb128> so control
[15:13] <seb128> in the debian dir
[15:13] <bcurtiswx_> yes
[15:13] <seb128> the file which has the build-depends, depends, binaries etc
[15:13] <seb128> comment the sendtoone
[15:13] <seb128> one
[15:14] <bcurtiswx_> yes.. i already commented that out.. still looking for a nautilius-sendto-empathy.install
[15:15] <seb128> grep  nautilius-sendto-empathy debian
[15:15] <seb128> grep for nautilus-sendto in the debian dir files
[15:16] <seb128> mterry, hey, could you resync libcanberra on debian?
[15:16] <mterry> seb128, sur
[15:16] <seb128> thanks
[15:17] <seb128> they got the gtk3 version in experimental
[15:17] <seb128> so we should make sure we use same naming etc than they do
[15:18] <seb128> mterry, if you want to do gobject-introspection as well you are welcome ;-)
[15:18] <bcurtiswx_> seb128, yes i've done that and everything is commented out.. with the #
[15:18] <bcurtiswx_> unless # isn't a comment in a control file
[15:19] <mterry> seb128, we'll see, but probably
[15:19] <seb128> ok thanks
[15:19] <seb128> bcurtiswx_, how do you build?
[15:19] <seb128> bcurtiswx_, can you push you work somewhere?
[15:19] <bcurtiswx_> bzr bd
[15:19] <bcurtiswx_> yes i will push it if this one last thing doesn't work
[15:22] <bcurtiswx_> seb128, https://code.edge.launchpad.net/~bcurtiswx/ubuntu/natty/empathy/empathy-2.91.3
[15:23] <seb128> bcurtiswx_, thanks
[15:26] <seb128> bcurtiswx_, what error do you get during the build?
[15:26] <bcurtiswx_> seb128, well now nothing.. apparently i don't know that a commit is required before a bzr bd ?
[15:27] <seb128> it should not be required
[15:27] <bcurtiswx_> well it wasn't working before.. but all of the sudden it is.. afte ri committed
[15:27] <seb128> weird
[15:28] <bcurtiswx_> i feel like a retarded kid.. but /me shrugs
[15:38] <bcurtiswx_> seb128, that built fine
[15:39] <seb128> great
[15:40] <bcurtiswx_> but
[15:41] <bcurtiswx_> seb128, Gtk-ERROR **: GTK+ 3 symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
[15:41] <bcurtiswx_> when running ^^
[15:42] <seb128> no clue why it could do that
[15:42] <bcurtiswx_> kenvandine, have you see that before ^^
[15:42] <seb128> well it means it loads gtk2 code
[15:42] <seb128> dunno why though
[15:42] <seb128> cassidy, ^ do you have any clue?
[15:42] <seb128> pitti, seems the launchpad update broke the retracers :-(
[15:42] <seb128> pitti, they are hanging
[15:43] <pitti> seb128: again? I restarted them about an hour ago
[15:43] <pitti> *sigh*
[15:43] <bcurtiswx_> seb128, could it be the patches? some worked but none have been converted to GTK3
[15:43] <seb128> pitti, well they seem to be stucked
[15:43] <seb128> pitti, I killed them manually an hour ago because they were stucked for an hour
[15:43] <cassidy> seb128, empathy is linked on both GTK ?
[15:43] <seb128> with nothing in the logs
[15:43] <jcastro> 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] <seb128> cassidy, well, it could be that it loads a .so or something
[15:43] <seb128> jcastro, ok thanks!
[15:43] <cassidy> the control center maybe ?
[15:44] <jcastro> kklimonda: nice work on gtkmm, I know the stack's been frustrating for upstream over the years
[15:44] <cassidy> empathy itself shouldn't link on GTK2 any more
[15:44] <seb128> cassidy, ok thanks, I've an idea I think
[15:44] <seb128> bcurtiswx_, the lpi patch needs to use the gtk3 version of lpi
[15:45] <kenvandine> so dh_python is now preferred over pysupport right?
[15:45] <seb128> pitti, do you have some time to investigate the retracer issue or should I try to do that?
[15:45] <kklimonda> jcastro: hopefully we can get it into shape (and keep it that way) this cycle.
[15:45] <pitti> seb128: I'm currently fighting with OpenOffice; I can try tomorrow morning
[15:46] <seb128> pitti, ok, I will just run a retracing manually to see what's going on exactly
[15:46] <pitti> seb128: thanks
[15:46] <seb128> np
[15:46] <pitti> seb128: do the dup checker, it's easier
[15:46] <pitti> requires no chroot
[15:46] <seb128> right
[15:47] <bcurtiswx_> seb128, what's the gtk3 version of lpi ?
[15:47] <kenvandine> seb128, pitti: dh_python is preferred over pysupport right?
[15:47]  * kenvandine can never keep up with that :)
[15:47] <seb128> kenvandine,you should ask to doko or barry
[15:47] <pitti> kenvandine: dh_python{2,3} are the most preferred now
[15:48] <seb128> I'm not uptodate on python packaging preferred ways
[15:48] <pitti> they don't need any extra build deps
[15:48] <kenvandine> wondering if i should change libindicate and appindicator while i am messing with them
[15:48] <pitti> and work just fine
[15:48] <pitti> should be a simple change
[15:48] <seb128> bcurtiswx_: liblaunchpad-integration
[15:48] <seb128> bcurtiswx_, the library has gtk2 and gtk3 versions
[15:48] <seb128> bcurtiswx_, you need the one with a -3 in the name
[15:48] <seb128> same of the configure check
[15:49] <seb128> you need to check for the gtk3 one
[15:49] <seb128> bcurtiswx_, launchpad-integration-3.0
[15:49] <seb128> in the lpi configure patch
[15:49] <seb128> rather than "launchpad-integration"
[15:49] <bcurtiswx_> seb128, OK is the .h file needing the -3.0 as well ?
[15:50] <seb128> bcurtiswx_, no
[15:50] <seb128> bcurtiswx_, it's in a different directory but the pkg-config call handle that
[15:51] <bcurtiswx_> OK building again
[15:52] <bcurtiswx_> seb128, says launchpad-integration-3.0 doesn't exist, is it in the GNOME3 PPA ?
[15:52] <seb128> it's in natty
[15:53] <seb128> you don't make lot of efforts before asking do you ;-)
[15:53] <seb128> run apt-cache search launchpad integration gtk 3
[15:53] <bcurtiswx_> ugh, i do... sorry for apparently being lazy
[15:55] <jcastro> Laney: we still waiting on MIR stuff?
[15:56] <seb128> bcurtiswx_, no worry
[15:56] <seb128> bcurtiswx_, install liblaunchpad-integration-3.0-dev
[15:56] <seb128> bcurtiswx_, it's the gtk3 version
[15:56] <seb128> you need to update the build-depends as well
[15:57] <kenvandine> and change the patch
[15:57] <bcurtiswx_> 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] <kenvandine> 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] <kenvandine> bcurtiswx_,  ^^
[15:59] <bcurtiswx_> 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] <kenvandine> if it didn't have it before, just leave it off
[16:02] <bcurtiswx_> kenvandine, it did before.
[16:05] <bcurtiswx_> i'll just take the old version off, leave it as none for now
[16:08] <kenvandine> ok, libindicate transition to dh_python2 was quite painless, maybe i'll do appindicator for good measure
[16:10] <chrisccoulson> hmmm, no ted
[16:11] <chrisccoulson> does anyone know if libdbusmenu-gtk is going to be using gtk2 or gtk3?
[16:11] <chrisccoulson> (or will there be 2 versions?)
[16:11] <chrisccoulson> seb128 - not sure if you know the answer to that? :)
[16:11] <seb128> chrisccoulson, both versions
[16:11] <seb128> it's pending upload, kenvandine has it ready
[16:11] <chrisccoulson> seb128 - ok, thanks. so, it's safe for me to use in ffox :)
[16:12] <kenvandine> speak of the devil :)
[16:13] <chrisccoulson> i was just thinking the same thing!
[16:13] <kenvandine> tedg, how is the gdbus branch of dbusmenu looking?
[16:13] <seb128> chrisccoulson, you mean you don't plan to use gtk3 in firefox?! ;-)
[16:13] <chrisccoulson> seb128 - no, i think i'll leave that one for now ;)
[16:14] <kenvandine> chrisccoulson, fun weekend project :)
[16:14] <chrisccoulson> i might give it a try if i get bored ;)
[16:14] <seb128> chrisccoulson, you start being lazy I see ;-)
[16:15] <chrisccoulson> perhaps over the christmas break ;)
[16:15] <seb128> ;-)
[16:15] <seb128> you first refused to take over libreoffice and now that...
[16:15] <chrisccoulson> lol
[16:15] <chrisccoulson> i hear pitti is doing libreoffice now anyway
[16:16] <chrisccoulson> :)
[16:16] <seb128> \o/
[16:16] <seb128> ;-)
[16:16]  * pitti slaps chrisccoulson
[16:16] <tedg> kenvandine, Looking pretty good.  I have libappindicator building with it now -- fixed some pkgconfig errors.
[16:16] <chrisccoulson> lol
[16:16] <kenvandine> chrisccoulson, just because you are doing firefox gtk3 :)
[16:16] <tedg> kenvandine, So I'm getting relatively happy :)
[16:16] <seb128> I've the feeling chrisccoulson would still prefer porting firefox ;-)
[16:16] <chrisccoulson> oh yes!
[16:16] <chrisccoulson> :)
[16:16] <pitti> so would I :)
[16:17]  * kenvandine is a bit annoyed... no problem getting dh_autoreconf working with libindicate doing multiple python versions
[16:17] <kenvandine> but it wouldn't work for anything in appindicator!
[16:17] <pitti> kenvandine: you are doing multiple build trees? but that should be done after autoreconf, no?
[16:17] <kenvandine> yeah
[16:18] <kenvandine> but it was causing make to re-run configure
[16:18] <kenvandine> and getting the flags wrong or something
[16:18] <kenvandine> it isn't doing that in libindicate
[16:18] <kenvandine> no clue why
[16:18] <kenvandine> but i spent way too much time trying to make that work in appindicator
[16:19] <kenvandine> it would configure again and get the wrong python version
[16:20] <pitti> strange; even if it's re-running configure it usually remembers the options
[16:20] <kenvandine> it isn't an option
[16:20] <pitti> but perhaps not the env?
[16:20] <kenvandine> PYTHON=build-$* $(DEB_CONFIGURE_SCRIPT) $(DEB_CONFIGURE_NORMAL_ARGS) $(DEB_CONFIGURE_EXTRA_FLAGS)
[16:21] <kenvandine> so make did a re-check and would configure again with the default python version
[16:21] <pitti> that looks funny
[16:21] <pitti> shouldn't that be PYTHON=python$(version) or so?
[16:21] <kenvandine> whoops
[16:21] <kenvandine> yeah
[16:21] <kenvandine> PYTHON=$*
[16:21] <kenvandine> anyway, it gets it from the env
[16:22] <pitti> kenvandine: do you have the current state in bzr somewhere?
[16:22] <kenvandine> yeah
[16:22] <kenvandine> i uploaded it :)
[16:22] <kenvandine> i can try to add it back to see what happens
[16:23] <kenvandine> i changed lots of things since though
[16:23] <pitti> kenvandine: which source package is that?
[16:23] <kenvandine> indicator-application
[16:24] <kenvandine> i added it back and we'll see what happens
[16:25] <kenvandine> i fixed other build issues since
[16:26] <kenvandine> ok... it works now
[16:26] <pitti> kenvandine: hm, I don't see any autoreconf in debian/rules
[16:26] <kenvandine> i guess dropping it got me far enough to fix other problems... which must have been triggering that
[16:26] <kenvandine> oh... no, i had dropped it
[16:27] <kenvandine> because i couldn't get it to work
[16:27] <kenvandine> it was building for both 2.6 and 2.7 targets for python 2.6
[16:27] <pitti> kenvandine: why do we need it in the first place? we have no patches
[16:27] <kenvandine> we did
[16:27] <kenvandine> i had ted roll a release
[16:27] <pitti> ah
[16:27] <kenvandine> which we needed anyway
[16:27] <kenvandine> but it was driving me nuts when i was trying to patch it :)
[16:28] <kenvandine> must have been an ordering problem of some sort
[16:28] <kenvandine> touching some file causing it to reconfigure
[16:36] <seb128> kenvandine, did you talk to mterry?
[16:36] <seb128> he fixed some similar issues recently IIRC
[16:37] <kenvandine> nope
[16:37] <kenvandine> it seems fine now
[16:37] <seb128> ok
[16:37] <mterry> kenvandine, yeah, I did fix a problem where 2.7 was installing as python2.6.  If you see it again, I know how to fix
[16:37] <kenvandine> now i have libindicate ready to upload... and it needs the newer dbusmenu... which isn't ready
[16:38] <kenvandine> mterry, great
[16:44] <mpt_> kenvandine, hi, I have a Gwibber question
[16:44] <chrisccoulson> tedg - do you want me to do the change to dbusmenu to hook up the AboutToShow signal?
[16:44] <mpt_> kenvandine, is there a way for some other program to get the subset of Gwibber's list of accounts for which it makes sense to post text?
[16:45] <mpt_> kenvandine, e.g. Twitter and StatusNet and Identica and Jaiku but not Flickr or Digg
[16:45] <tedg> chrisccoulson, If you'd like that'd be great -- it's on my TODO list and I expect to get to it today or tomorrow -- but I always love help :)
[16:46] <kenvandine> mpt_, yes
[16:46] <chrisccoulson> tedg - cool. if i get to the point where i can start to build the ffox extension, then i'll do the change in dbusmenu too :)
[16:46] <kenvandine> libgwibber provides an api for that
[16:46] <chrisccoulson> not sure if that will be today or tomorrow though
[16:46] <kenvandine> mpt_, indicator-me does that now
[16:47] <mpt_> kenvandine, is there an online reference anywhere?
[16:47] <mpt_> for the API
[16:47] <kenvandine> no... sorry
[16:47] <kenvandine> and the generated docs are terrible
[16:47] <mpt_> ok
[16:48] <kenvandine> i haven't figured out how to properly annotate the vala code so the docs get translated to C
[16:48] <mpt_> kenvandine, one more question: Can Gwibber also tell the program what the character limit is for each account?
[16:48] <mpt_> e.g. 140 for Twitter/Identica, 1000 for Facebook
[16:48] <kenvandine> not yet, but that is on my todo list
[16:48] <mpt_> ok, thank you
[16:48] <kenvandine> right now gwibber hard codes the limit to 140 for everything
[16:49] <kenvandine> but i am making it per service, and the posting widget will allow you to post up to the limit of the lowest selected account
[16:49] <mpt_> ok, I'm not using the posting widget
[16:50] <kenvandine> so if only facebook is selected you can post up to 500ish characters, but if you are posting to twitter and facebook it will limit it to 140
[16:50] <kenvandine> ok, well there will be an API to provide that :)
[16:50] <mpt_> but a checkbox "[/] Also post this review to: [Twitter (@mpt) :^]
[16:50] <kenvandine> nice
[17:02] <mvo> didrocks: hi, is com.canonical.Unity.Panel.Service trigger dbus-activate enabled, i.e. is it save for me in software-center to ping this interface without triggering a strart of it?
[17:02] <mvo> didrocks: to see if unity is active in the current session?
[17:03] <didrocks> mvo: it is dbus activated
[17:03] <mvo> hrm, ok
[17:04] <didrocks> mvo: still need a respawn though, so don't rely on events right now :)
[17:04] <mvo> I just need to remember now how to test the bus without triggering the activation
[17:05] <didrocks> mvo: yeah, sounds the best way to know if unity is there or not :)
[17:06] <mvo> thanks didrocks, I will ponder about it over dinner
[17:06] <didrocks> mvo: yw
[17:11] <seb128> pitti, ok, no luck with the retracers
[17:11] <pitti> no luck with OO.o either *sigh*
[17:11] <seb128> the dup checking queue is empty
[17:11] <seb128> I tried in a retracer to run it manually on a bug
[17:11] <seb128> but the --auth=... doesn't seem to work
[17:11] <seb128> it wants to do the "start a webbrowser" thing
[17:12] <seb128> I'm wondering if retracing hangs on that as well
[17:12] <seb128> do we need an updated token?
[17:16] <mvo> didrocks: bus.name_has_owner() was what should not activate it, fortunately my memory is just slow not faulty
[17:17] <didrocks> mvo: oh nice, I didn't know that one. Ok updating that in my head when someone will ask me "can we detect if unity is launched or not" :)
[17:17] <didrocks> mvo: there will be false positive on --replace, but well…
[17:18] <mvo> oh, because it keeps running?
[17:18] <mvo> well, bad luck ;)
[17:19] <didrocks> mvo: yeah :)
[17:19] <seb128> we need to have a standard code snippet to detect if unity is running somewhere
[17:20] <seb128> or unity to get a UnityRunning() method on dbus
[17:20] <didrocks> mvo: what you really want is asking compiz if the plugin is loading or not (and if compiz is running first…)
[17:20] <seb128> we will have to do such checks in several applications it seems
[17:20] <seb128> didrocks, could unity have a method on dbus for that?
[17:21] <didrocks> seb128: that's a nice idea and can be easy I think
[17:21] <seb128> so we would just have to use that from clients...
[17:21] <didrocks> seb128: will file a bug? or do what to file it?
[17:21] <didrocks> then, that's totally a thing our team can deal with
[17:21] <seb128> didrocks, I will file a bug and let you know
[17:22] <seb128> so we can add it to the contributors list
[17:22] <didrocks> seb128: exactly :)
[17:22] <didrocks> mvo: seb128: neat idea on this, it just need to be in the unity compiz plugin. Thanks! :)
[17:23] <seb128> thank you ;-)
[17:23] <mterry> seb128, let's say a library changed names from foo1.0-1 to foo-1.0-1.  If I just do provides/conflicts/replaces, will that cause a build failure for other packages because now foo1.0-1 is only virtual, or does that get handled correctly?  (i.e. do I need a dummy transitional package?)
[17:23] <seb128> mterry, I guess it's for gir?
[17:23] <mterry> seb128, yeah libgirepository
[17:24] <seb128> mterry, c;p;r is enough
[17:24] <seb128> the virtual will works if the requirement are not versioned
[17:24] <mterry> seb128, so if there is a versioned depends (which seems not unlikely, I'll check), I'd break builds unless I do a transitional package?
[17:24] <seb128> mterry, there is like 6 rdepends
[17:25] <seb128> we don't add dummy binaries for small numbers
[17:25] <seb128> we just do the 6 rebuilds
[17:25] <mterry> seb128, OK, will start doing rebuilds then  :)
[17:25] <mterry> seb128, so answer was need transitional package for large numbers of versioned depends, else don't bother
[17:25] <seb128> mterry, the depends are versioned
[17:25] <seb128> there was a shlibs on the lib
[17:26] <seb128> mterry, yes
[17:26] <mterry> seb128, oh right, because it would also break upgrades, not just builds
[17:28] <seb128> mterry, right, the builds will likely not break
[17:28] <seb128> only the runtime lib has been renamed
[17:28] <seb128> we probably just need a no change upload for those rdepends to pick the new depends
[17:28] <mterry> seb128, gp, builds would point right at -dev
[17:42] <pitti> good night everyone!
[17:43] <didrocks> have a good evening pitti
[17:46] <seb128> 'night pitti
[17:54] <mterry> seb128, son of a ...  I don't have upload rights to libcanberra or gobject-introspection.  can you push for me?  Both are in bzr
[17:57] <johanbr> has anyone tried to compile the gnome-shell 2.91.3 tarball? after fixing a bunch of missing includes, compilation finally breaks with "st/st-texture-cache.c:270: error: 'GdkRGBA' undeclared (first use in this function)"
[17:58] <micahg> johanbr: I started on it, but didn't get too far
[17:58] <seb128> mterry, ok
[17:58]  * mterry starts thinking more seriously about core-dev
[17:59] <johanbr> micahg, alright, thank you... I'll see if I can get it to compile
[17:59] <micahg> johanbr: I probably won't have time until the weekend to get it working
[18:02] <seb128> johanbr, do you use natty or the gnome3 ppa builds?
[18:03] <johanbr> natty
[18:03] <seb128> ok, not sure how well it will work on natty
[18:03] <seb128> you might get closer with the ppa
[18:03] <johanbr> alright, I'll give that a try if natty doesn't work
[18:03] <johanbr> thank you
[18:12] <milanbv> johanbr: I guess you need the latest GTK 3 (2.91.6)
[18:12] <johanbr> milanbv, ahh... that might be a problem
[18:14] <milanbv> OTOH GdkRGBA seems to have been present for several releases...
[18:18] <didrocks> ok, time for some sport and dinner, see you tomorrow guys!
[18:19] <milanbv> johanbr: does the file include gtk/gtk.h?
[18:20] <johanbr> you mean the one where compilation breaks? yes
[18:21] <johanbr> but I think that was a case of it finding the 2.0 gtk/gtk.h file
[18:22] <johanbr> anyway, got it to compile now, but linking breaks... will have a look at that later
[18:22] <seb128> kenvandine, there?
[18:22] <kenvandine> seb128, yup
[18:23] <kenvandine> working with tedg to try to get things to land linked to the right libs
[18:23] <seb128> great
[18:23] <kenvandine> seb128, what's up?
[18:23] <kenvandine> i am finding what is breaking on my laptop :)
[18:24] <kenvandine> good times
[18:24] <seb128> kenvandine, did you send your gdk-pixbuf vala gir patch upstream yet?
[18:24] <kenvandine> not for that one, no
[18:24] <kenvandine> not sure if it is worthy of merging
[18:24] <kenvandine> since it is for 2.x
[18:25] <seb128> kenvandine, hum, ok, it's the only diff we have with debian on this source
[18:25] <seb128> kenvandine, we could sync if we didn't have the patch, but it's a detail
[18:25] <kenvandine> i think it will end up only being temporary
[18:25] <seb128> ok, thanks
[18:25] <kenvandine> once the GIR stuff stabilizes, in theory we won't need it
[18:26] <seb128> kenvandine, do you need any help for landing or testing ted's libs?
[18:26] <kenvandine> same for the patch against gtk2, i only submitted it for gtk3
[18:26] <kenvandine> seb128, nah
[18:26] <kenvandine> i am mostly blocked on him
[18:26] <seb128> ok
[18:26] <seb128> kenvandine, thanks!
[18:26] <kenvandine> the suck now is libindicate FTBFS, and the fix won't build without a dbusmenu rebuild
[18:27] <kenvandine> but dbusmenu FTBFS without the new version
[18:27] <kenvandine> gi-repository versioning
[18:27] <kenvandine> ugh ugh ugh
[18:28] <kenvandine> seb128, i'll be out for a bit this afternoon in case anyone is looking for me... taking a late lunch that will likely be longer than usual
[18:28] <kenvandine> but i'll be back
[18:28] <kenvandine> leaving in about 30m
[18:28] <seb128> kenvandine, ok
[18:29] <seb128> kenvandine, " but dbusmenu FTBFS without the new version"
[18:29] <seb128> can you explain?
[18:29] <kenvandine> seb128, oh... and more fun, tedg split indicator-application and appindicator into two sources, so with the gdbus branch landing we'll have some NEW'ing to do
[18:29] <seb128> do we have a circular depends?
[18:29] <kenvandine> the current dbusmenu won't build
[18:29] <kenvandine> because of GI changes
[18:29] <seb128> NEWing is not an issue
[18:29] <seb128> well, let's land the new version?
[18:29] <seb128> ;-)
[18:29] <kenvandine> but libindicate won't build against the version in the archive because has gi-repository version of 1.1
[18:30] <kenvandine> and it needs 1.2 for g-ir-scanner
[18:30] <kenvandine> dbusmenu is being reviewed for merging in trunk, i think
[18:30] <kenvandine> i have the branch with packaging so i can prepare
[18:30] <seb128> ok
[18:31] <kenvandine> will do that after i get back, so we are positioned to rapidly upload stuff when the floodgates open :)
[18:31] <seb128> seems the way forward is to get the new libdbusmenu to land
[18:31] <kenvandine> yeah
[18:31] <seb128> ok thanks
[18:31] <seb128> let me know if I can be useful
[18:31] <kenvandine> and i think tedg said that was like a 7900 line diff
[18:31] <seb128> or drop me an email if I'm off for today
[18:31] <kenvandine> so reviewing is taking time
[18:31] <kenvandine> will do
[18:31] <kenvandine> tedg, any chance that will land today?
[18:39] <seb128> ok
[18:40] <seb128> do we we someone interested by updating xchat-gnome to a git version?
[18:40] <seb128> or gnome-pilot to the current stable
[18:41] <seb128> or sound-juicer?
[18:41] <seb128> seems contributors tasks for people who want to do something
[18:41] <seb128> let a comment on the channel if interested ;-)
[18:43] <seb128> Laney, hey, do you know if debian is going to update gnome-sharp2 to 2.24.2?
[18:44] <seb128> Laney, or mono-addins to 0.5
[18:45] <seb128> mterry, is there anything stopping to land the new vte in natty?
[18:46] <mterry> seb128, uh, no?
[18:46] <mterry> seb128, I cleared up issues of package naming with the debian folk
[18:46] <mterry> seb128, except I have to implement one packaging change on top of what the PPA has before it hits natty
[18:47] <seb128> mterry, ok, no hurry but seems one of the updates than we could land in natty
[18:48] <mterry> seb128, sure
[18:48] <seb128> I'm trying to clean http://people.canonical.com/~platform/desktop/versions.html ;-)
[19:17] <asac> pitti: hey
[20:08] <chrisccoulson> tedg - oh, i sort-of need a menu-closed event in firefox too ;)
[20:09] <chrisccoulson> although i can perhaps work around that
[20:09] <tedg> chrisccoulson, Just to be curious, why?  What do they use that for?
[20:09] <chrisccoulson> tedg - each menuitem in the DOM has an "open" attribute
[20:09] <chrisccoulson> which is public, so i've no idea what's using that
[20:10] <chrisccoulson> sorry, i meant each menu rather than menuitem
[20:10] <chrisccoulson> https://developer.mozilla.org/en/XUL/menu
[20:11] <tedg> Yeah, if it exists, you can pretty much assume that someone is using it for something stupid :)
[20:11] <chrisccoulson> i was thinking i could probably just reset the attribute when you activate a child menuitem, or open another menu
[20:12] <chrisccoulson> but then there would be a corner case where the user opens a menu and then just closes it again
[20:32] <tedg> chrisccoulson, Yup, it would be interesting to see who uses it.  There might be use-case we're missing and should handle more eloquently.
[20:32] <tedg> Or it just might be crap code that uses it ;)
[20:34] <chrisccoulson> tedg - hmmm, it's used in a few places in ffox: http://paste.ubuntu.com/541138/
[21:57] <seb128> robert_ancell, hey
[21:57] <robert_ancell> seb128, hey
[21:58] <seb128> robert_ancell, how are you?
[21:58] <robert_ancell> good, busy :)
[21:58] <seb128> hehe
[21:58] <seb128> what are you working on recently?
[21:58] <seb128> GNOME3 in the ppa still?
[21:59] <robert_ancell> yes, we're mostly up to date wifth the stable stuf
[22:00] <robert_ancell> Been sending a lot of patches upstream for build failures
[22:00] <seb128> nice
[22:01] <robert_ancell> seb128, hey, are you having any gdm issues?
[22:01] <robert_ancell> I notice it just upgraded
[22:01] <seb128> I didn't update to 2.32 yet
[22:01] <seb128> it's pitti who did the update
[22:02] <robert_ancell> there may be a problem there, I'm running lightdm at the moment as I couldn't log in...
[22:02] <seb128> we got a bug saying that "enter" is not working to select the default user
[22:02] <robert_ancell> I was just going to ask you if you knew of any reason to not upgrade - I was wary of doing it
[22:02] <seb128> but otherwise nobody complained
[22:02] <robert_ancell> When I log in, it returns immediately to the login screen
[22:02] <seb128> seems gnome-session is crashing?
[22:03] <seb128> it could be the changes didrocks do
[22:03] <seb128> the standard session is unity now
[22:03] <robert_ancell> yeah, I was thinking that or compiz, but the logs don't say anything interesting
[22:03] <seb128> there is a "classic" session as well
[22:03] <seb128> which is old GNOME
[22:03] <seb128> but quite some people got bitten by custom compiz configs
[22:03] <robert_ancell> that's what I'm running now. Unity doesn't work in LightDM properly, haven't worked out why
[22:04] <robert_ancell> seb128, so is compiz supposed to be running the gconf backend or the keyfile one?
[22:04] <seb128> did you try to start a session for a new user?
[22:04] <seb128> robert_ancell, gconf
[22:04] <robert_ancell> not yet
[22:05] <seb128> you should perhaps rm .config/compîz-1
[22:05] <seb128> unset /apps/compiz-1 in gconf
[22:05] <seb128> unset /apps/compizconfig-1 in gconf as well
[22:05] <robert_ancell> seb128, will do that
[22:05] <seb128> default is compiz with unity activated using gconf
[22:05] <seb128> no gnome-panel
[22:06] <seb128> the "classic" session is normal compiz and gnome-panel
[22:06] <robert_ancell> when it breaks I miss it, so I think that means it's better
[22:06] <seb128> what? unity? ;-)
[22:06] <robert_ancell> yes
[22:07] <seb128> check COMPIZ_CONFIG_PROFILE also
[22:07] <robert_ancell> env variable?
[22:07] <seb128> it should be set to "ubuntu" in the unity session
[22:07] <seb128> yes
[22:07] <seb128> see /etc/X11/Xsession.d/65compiz_profile-on-session
[22:07] <seb128> that's the unity profile
[22:07] <TheMuso> I have to switch to the user login window with latest gdm, but the classic session is working fine here.
[22:08] <robert_ancell> The upgrade seems very unstable, but didrocks is working on that right?
[22:09] <seb128> robert_ancell, how unstable?
[22:09] <seb128> like people getting screwed sessions?
[22:09] <robert_ancell> seb128, these previous configuration issues
[22:09] <seb128> I think it's people who activated and desactivated unity manually in ccsm
[22:09] <robert_ancell> but it's hard to tell, because I upgraded early, and video has been pretty unstable for me the last month
[22:09] <seb128> not sure how much can be migrated without breaking the "preserve user config"
[22:10] <seb128> that's why we have a new profile
[22:10] <robert_ancell> surely the unity profile will ...
[22:10] <robert_ancell> right, I was just about to say that
[22:10] <seb128> it's just that people who upgraded during the time the migration was still buggy got a buggy new profile
[22:10] <seb128> not sure it would still affect people coming from maverick
[22:11] <seb128> or just people who have been running natty early enough to migrate at a buggy time
[22:11] <seb128> we will need to test that for sure
[22:11] <seb128> but didrocks thinks the migration should be mostly ok now
[22:11] <robert_ancell> seb128, hey, are you talking with the Debian guys about the GNOME3 packaging much?  I hope all the work we're putting into the PPA will be used by Debian, and we're not going to have a bunch of difficult merges coming up
[22:12] <robert_ancell> Is there more we should be doing to raise visibility with Debian?
[22:12] <seb128> I pinged them on #debian-gnome the other day
[22:12] <seb128> I gave them the ppa url
[22:13] <seb128> told them to check with me before starting on update or at least to check what we did
[22:13] <seb128> so we don't duplicate work
[22:13] <robert_ancell> ok, good
[22:13] <seb128> I will try to commit some of the work we did in their svn
[22:13] <seb128> or maybe just dump most there
[22:13] <seb128> so they can't ignore it :p
[22:13] <seb128> I've been sending to debdiff to the bts already recently
[22:13] <robert_ancell> seb128, a good one to do is gtk-engines, because it appeared they hadn't done that yet
[22:13] <seb128> I was not sure what to work on to be honest
[22:15] <seb128> GNOME in natty is mostly uptodate
[22:15] <seb128> GNOME3 is not really something that needs to land now
[22:15] <seb128> ideally we should start hacking on unity
[22:16] <robert_ancell> agreed, I think it's pretty clear now we're not going to have any GNOME3 apps in natty
[22:16] <seb128> robert_ancell, well, we could have some
[22:16] <seb128> gnome-utils
[22:16] <seb128> gnome-games
[22:16] <robert_ancell> seb128, just minor ones
[22:16] <seb128> gcalctool
[22:17] <seb128> then perhaps anjuta
[22:17] <micahg> gnome-shell?
[22:17] <robert_ancell> seb128, not even gnome-games, we still haven't ported all the games to GTK3
[22:17] <robert_ancell> micahg, I think we can't due to gnome-session
[22:17] <seb128> robert_ancell, well at least it doesn't bring other components in
[22:17] <robert_ancell> (but it can be in the PPA)
[22:17] <seb128> micahg, no, I think it's for the ppa
[22:17] <seb128> it will need lot of updated components for their indicators and integration
[22:17] <seb128> they are patching different sources to provides infos on dbus they can use
[22:18] <chrisccoulson> hi robert_ancell! what are your plans for yelp btw? i see you updated the build-depends in the last upload to make it work
[22:18] <robert_ancell> The good news with the PPA is we've done most of the hard work, so it shouldn't be too hard to keep it up to date.
[22:18] <micahg> seb128: oh, hmm, so the distro version will be unusable then? or I'll just have to fix it to work with the gnome 2.x libs
[22:18] <chrisccoulson> if we're keeping the current version, then i need to fix it ;)
[22:18] <seb128> micahg, I think we should remove the universe version and just have it in the ppa with GNOME3
[22:18] <seb128> chrisccoulson, ^
[22:19] <seb128> robert_ancell, right
[22:19] <chrisccoulson> gnome-shell?
[22:19] <seb128> yes
[22:19] <robert_ancell> chrisccoulson, yes, thanks for that!  I updated to the latest stable when you did that.  I want the next one, but I need to get a webkit package working.  Been talking with Debian a little about that, they want the package to build both gtk2 and gtk3 binaries, which is a huge pain in the arse.
[22:19] <seb128> does anybody has a natty pbuilder?
[22:19] <chrisccoulson> i haven't set up one yet
[22:19] <robert_ancell> seb128, yes
[22:19] <micahg> seb128: well, since we're not jumping to GNOME 3 yet, I think we can get away with it
[22:19] <TheMuso> I have a natty sbuild.
[22:20] <micahg> seb128: I have one
[22:20] <seb128> robert_ancell, can you run apt-get update and try to install the build-depends for rhythmbox?
[22:20] <seb128> or micahg or TheMuso
[22:20] <seb128> just trying to figure what makes the rhythmbox upload fail to build
[22:20] <TheMuso> sure just a sec.
[22:20] <chrisccoulson> robert_ancell, so, we're still hopeful for getting the webkit version later in the cycle?
[22:20] <robert_ancell> chrisccoulson, yes, it's just going to take a little time
[22:20] <seb128> robert_ancell, can we downgrade it to the gtk2 stack?
[22:21] <seb128> I think pitti is going to kill you if you try to get a second webkit build on the CD ;-)
[22:21] <chrisccoulson> thanks, i'll leave that one off my list for now then
[22:21] <robert_ancell> seb128, it would probably be hard.
[22:21] <seb128> hum
[22:21] <seb128> so for next cycle as well I guess...
[22:21] <micahg> seb128: I think it's expected ATM
[22:21] <seb128> robert_ancell, what do they use from gtk3?
[22:21] <seb128> micahg, <doko> seb128: any idea about the uninstallability of the thythmbox build dependencies?
[22:22] <TheMuso> hrm schroot is complaining about something here, gotta fix that up first.
[22:22] <seb128> micahg, still I think dodo would like to not what to unblock
[22:22] <seb128> if you are speaking about rb
[22:22] <robert_ancell> seb128, but I don't know, it's worth investigating.  Yelp is the only package that has a compelling reason to upgrade.  I'll have a look.  We'll still have to get any other Webkit packages to upgrade to the latest version though
[22:22] <micahg> seb128: no, second webkit
[22:22] <seb128> oh ok
[22:23] <seb128> robert_ancell, well you say it's probably hard but you don't know ;-)
[22:23] <seb128> it could be just patching the configure to check for gtk2
[22:23] <robert_ancell> seb128, first I was thinking that webkit would need patching, but it's supposed to compile with GTK2.  But I've looked at other packages, and the patches aren't trivial
[22:24] <robert_ancell> seb128, no, because there are a number of important API changes
[22:24] <micahg> seb128: the only thing with dropping gnome-shell is we have some regular users of it who might be upset about dropping it
[22:24] <robert_ancell> seb128, yelp does not support GTK2 anymore
[22:24] <seb128> micahg, well, would they feel better about having a 6 months old version?
[22:24] <seb128> robert_ancell, ok, so let's not bother with it
[22:24] <seb128> robert_ancell, I suggest focussing on unity for now
[22:24] <seb128> we can sort GNOME3 at the sprint
[22:25] <robert_ancell> seb128, sure
[22:25] <seb128> it's getting close from end of year break anyway
[22:25] <micahg> seb128: yeah, I guess that will make people just as upset, you think we can add something to the release notes about the GNOME3 PPA?
[22:25] <seb128> yes
[22:25]  * robert_ancell wants a bzr-pbuild
[22:26] <TheMuso> Tried to install rhythmbox build deps in a chroot, and it looked like apt was happy. Updating my mirror again to see if newer packages change things.
[22:26] <micahg> seb128: ok, so should I still work on it then and propose a merge for someone to upload to the -desktop PPA?
[22:27] <seb128> micahg, if you want sure
[22:27] <seb128> we will get as much of GNOME3 as we can in the ppa
[22:28] <robert_ancell> seb128, micahg, which will probably be all of it according to http://people.canonical.com/~platform/desktop/versions.html
[22:28] <robert_ancell> micahg, please help updating it if you can!
[22:28] <micahg> robert_ancell: I'll be glad to help :)
[22:29] <robert_ancell> seb128,   libgirepository-1.0-1: Conflicts: libgirepository1.0-1 but 0.9.12+git20101124-0ubuntu2 is to be installed.
[22:29] <seb128> robert_ancell, thanks
[22:29] <robert_ancell> seb128, is that what you got?
[22:29] <micahg> how are you handling bugs WRT the GNOME3 PPA?
[22:29] <seb128> robert_ancell, I don't have a pbuilder there to try
[22:29] <seb128> micahg, we don't ;-)
[22:29] <robert_ancell> micahg, just open them against the normal packages, but make clear it's the PPA version
[22:30] <micahg> robert_ancell: ok, maybe there should be a tag, like GNOME3?
[22:30] <TheMuso> Only have to fetch 135MB of updates for my mirror, so should be able to confirm robert_ancell's findings soon.
[22:30] <robert_ancell> micahg, they'll probably just sit there until N+1, but we can forward them upstream
[22:30] <robert_ancell> micahg, good idea
[22:30] <seb128> robert_ancell, TheMuso: ok thanks
[22:30] <seb128> python-gobject needs a rebuild
[22:31] <micahg> robert_ancell: if you like, I can bring it up in the bugsquad meeting on Tuesday so others are aware and don't close them
[22:31] <robert_ancell> micahg, yes, thanks!
[22:31] <TheMuso> /c/c
[22:31] <micahg> robert_ancell: I'll let you know the outcome of the meeting
[22:35] <TheMuso> http://paste.ubuntu.com/541185/
[22:36] <TheMuso> ^^ attempting to apt-get build-dep rhythmbox.
[22:37] <seb128> ok, same that robert_ancell
[22:37] <seb128> it's due to python-gobject, I've uploaded a rebuilt now
[22:37] <TheMuso> ok.
[22:43] <seb128> robert_ancell, what do you think about dropping the desktop effect tab?
[22:43] <seb128> in gcc
[22:44] <seb128> it doesn't really fit for unity against GNOME nowadays
[22:44] <seb128> the fallback should just work
[22:44] <robert_ancell> seb128, why not just hide it when in unity?
[22:44] <seb128> the users who want to tweak their wm can do it in gconf
[22:44] <seb128> well GNOME3 drops the appearance capplet
[22:44] <robert_ancell> We can either hide it or remove it - there's not much difference
[22:44] <seb128> so I was pondering just drop it now
[22:44] <robert_ancell> right, so it's gone in N+1 anyway
[22:45] <seb128> rather than spending time to make it be smart about unity
[22:45] <robert_ancell> I'm OK with removing it.  I'm sure there'll be some people who complain though
[22:45] <seb128> it doesn't work with compiz 0.9
[22:45] <seb128> either
[22:45] <seb128> so it needs work
[22:45] <robert_ancell> well the patch will be if (!getenv("COMPIZ_CONFIG_PROFILE")) gtk_widget_hide()
[22:46] <robert_ancell> oh, then it's gone
[22:46] <seb128> lol
[22:46] <seb128> g-c-c needs a rebuild as well
[22:46] <seb128> if you have time today feel free to do it
[22:46] <seb128> I will have a look tomorrow or next week otherwise
[22:46] <seb128> (I'm having friday off again this week)
[22:47] <robert_ancell> ok, will do
[22:57] <micahg> robert_ancell: minimal GNOME3 means no major GTK3 infrastructure porting, right?
[22:57] <robert_ancell> micahg, do you mean can an app be GNOME3 and still use GTK2?
[22:58] <micahg> robert_ancell: no, I mean are we porting any shared parts of the desktop to gtk3?
[22:58] <micahg> like stuff that Xubuntu would be using
[23:00] <robert_ancell> micahg, no, we're only providing the GTK3 stack, everything is remaining as it was, none of the shared components will change (e.g. to gsettings)
[23:00] <micahg> robert_ancell: great, I'll pass that along, thanks
[23:00] <kklimonda> heh, this new tab grouping in Firefox is dangerous - I no longer close tabs, just open new groups ;)
[23:00] <kklimonda> and firefox is using more and more memory :/
[23:01] <micahg> kklimonda: I'm hit by the same thing :)
[23:02] <kklimonda> it's a cool feature but it needs more polish to ease tab management.
[23:29] <kklimonda> jcastro: I think I can update glom to 1.16.2 now


[00:08] <Demosthenes> wow, thats *REALLY* odd. i killed off 4L-gui and a few defunct 4L-cli processes, and bzr works now.
[00:08] <Demosthenes> WTF
[00:12] <Demosthenes> i don't see any differences in /usr, /lib, or /bin that would indicate i was hacked. the only diffs are .gz files that are package documentation, and they pass gzip -t
[00:12] <Demosthenes> has a later bzr been backported to lenny?
[00:13] <ed-209> how come whenever I anonymously access launchpad, bzr works fine, but when I try to set up an account with SSH keys and all, it jus fails out?
[00:13] <Demosthenes> ed-209: ssh -vvv and watch
[01:38] <spiv> lifeless: I'd welcome patches for news_merge (of course)
[01:38] <spiv> lifeless: it's pretty hackish in various ways
[01:39] <spiv> lifeless: Partly because of the stupidly simple parser
[01:40] <spiv> lifeless: partly because it uses Merge3.merge_regions, but it expects lines and I want to feed it other kinds of blocks of text
[01:42] <spiv> lifeless: or rather, it doesn't really want to feed Merge3 lines at all, but ideally two-tuples, e.g. [('section', 'Bug Fixes'), ('bullet', '* Fix crash in frobber.'), ...]
[05:24] <lifeless> spiv: Activation energy is still too low; I may patch it in future
[05:24] <lifeless> spiv: but if you can patch it in work time, we both win :)
[07:05] <lifeless> \o/ test suite loop closed.
[08:52] <thumper> lifeless: you around?
[08:52] <lifeless> thumper: hi, yeah, just making testr rock
[08:52] <thumper> lifeless: I'm starting a new python project
[08:52] <thumper> lifeless: and I want some test infrastructure
[08:53] <thumper> lifeless: what do you recommend?
[08:53] <thumper> lifeless: I have nothing right now
[08:53] <lifeless> testrepository
[08:53] <lifeless> and testtools
[08:53] <thumper> lifeless: automatic discovery if possible
[08:53] <thumper> is it packaged?
[08:53] <lifeless> uhm, if you want that you can use the discover module
[08:53] <lifeless> [I don't really like automatic discovery, but thats me :P]
[08:53] <thumper> I can register I suppose
[08:54] <thumper> I want a simple way to just run the tests...
[08:54] <lifeless> can I show you something
[08:54] <thumper> sure
[08:54] <lifeless> branch lp:testrepository
[08:54] <lifeless> install python-testresources and python-testscenarios and python-testtools
[08:56] <thumper> python-testscenarios not found
[08:56] <lifeless> you are running lucid, yea?
[08:56] <thumper> no
[08:56] <lifeless> ah
[08:56] <lifeless> add the subunit PPA
[08:56] <thumper> which is?
[08:57] <lifeless> sudo add-apt-repository ppa:subunit/ppa
[08:59] <thumper> lifeless: got muffins in the oven
[08:59] <thumper> lifeless: got that installed
[08:59] <thumper> but the oven is calling
[08:59] <lifeless> ok
[08:59] <lifeless> I'll be here
[09:00] <lifeless> thumper: oh, also you might like lp:commitfromnews; its verra useful :)
[09:05] <thumper> lifeless: not a branch
[09:05] <lifeless> sorry
[09:06] <lifeless> bzr-commitfromnews
[09:06] <thumper> which does?
[09:06] <lifeless> diffs NEWS to suggest commit messages
[09:07] <lifeless> oh, you'll also need python-subunit installed
[09:07] <lifeless> sorry, you're getting a full stack here ;)
[09:07] <thumper> it better be worth it
[09:08] <lifeless> I think you'll like it
[09:08] <lifeless> I've just pushed rev 88 of testrepository, probably worth having
[09:09] <lifeless> anyhow, there are two main things here
[09:09] <lifeless> I want to show you the layout I used in testrepository, as I'm pretty happy with that
[09:09] <lifeless> and I want to show you testrepository itself
[09:10] <lifeless> as I think its an excellent workflow
[09:10] <lifeless> brb in a couple of minutes, organising dinnery things.
[09:10] <lifeless> have a poke aroun testrepository's code base; try 'make check' etc
[09:17] <lifeless> thumper: ok, back
[09:22] <phix> hey
[09:22] <phix> what's new?
[09:22] <lifeless> hi
[09:22] <lifeless> stuff :P
[09:22] <phix> nice
[09:23] <phix> ummm, I am suprised this channel is still here
[09:23] <lifeless> why?
[09:23] <phix> Well, git has been pretty stable for the last few years now
[09:23] <lifeless> so? Thats git, this is bzr.
[09:24] <lifeless> We're gaining users faster than ever
[09:24] <fullermd> RCS has been rock-stable for decades   :p
[09:24] <phix> yeah but git kind of makes bzr look like cvs
[09:24] <lifeless> phix: I think that comparison is false
[09:24] <thumper> phix: no one likes trolls
[09:24] <phix> ok ok, I will give you some credit, more like svn :P
[09:24] <phix> hehe
[09:24] <phix> thumper: aawwww
[09:25] <phix> I m not trolling though
[09:25] <lifeless> phix: Is that a considered opinion, or a joke?
[09:25] <phix> no no no, bzr is the joke actually :)
[09:25] <phix> well no, the fact that ppl still use it is I suppose
[09:25] <phix> any way
[09:25] <phix> I am off :)
[09:25] <phix> see you guys in #git soon for sure
[09:26] <lifeless> phix: thats either hostile or a troll, and neither is particularly friendly or encouraging.
[09:26] <phix> oh
[09:26] <phix> revert phix
[09:26] <fullermd> Oh, sweet.    Presumably a good one, naturally.
[09:55] <lifeless> ah
[09:55] <lifeless> unless its dark humour
[09:57] <lifeless> uhm
[09:57] <lifeless> this is a wtf moment:
[09:57] <lifeless> make docs
[09:57] <lifeless> python -c "import shutil; shutil.copyfile('NEWS', 'doc/en/release-notes/NEWS.txt')"
[09:57] <lifeless> I think if we have Make, we can surely assume 'cp' ?
[10:03] <fullermd> That should be implemented with inline ASM, to be more optimized.
[10:06] <lifeless> you're here all week right? So you might improve.. :)
[10:06] <fullermd> Don't forget to tip your waitress!
[10:08] <lifeless> <3 commitfromnews
[10:17] <bialix> hi igc
[10:17] <Kamping_Kaiser> is there a bzr plugin to mark bugs in debbugs pending on commit to a bzr repo? (I can't imagine i'm the only person to wonder this, but i've not seen it asked before)
[10:17] <lifeless> bzr builddeb would be a good place to put that
[10:18] <lifeless> its really 'bzr-debian' :P
[10:18] <Kamping_Kaiser> ok , I'll check to see what it does :)
[10:18] <Kamping_Kaiser> hehe
[10:25] <igc> hi bialix
[10:25] <bialix> Marco Polo is good codename, the first great explorer, right?
[10:25]  * bialix uploading installer now
[10:27] <bialix> igc: installer done
[10:28] <igc> bialix: certainly one of the better known early explorers
[10:29] <igc> bialix: thanks for the installer too
[10:29] <bialix> :-)
[10:29] <igc> bialix: http://en.wikipedia.org/wiki/Exploration
[10:30] <bialix> igc: I have an theory that every "project" in human life takes about 9 months to get somewhere. your bzr-explorer is another confirmation ;-)
[10:30] <lifeless> heh
[10:30] <lifeless> I'm only just getting to where I want testing to be, after 14 years
[10:31] <igc> bialix: I just hope it's stable enough to warrant 1.0
[10:31] <bialix> lifeless: I don't say about maturity
[10:31] <lifeless> :P
[10:31] <fullermd> Ogod, I hope this project will be done in less time than that   :(
[10:32] <bialix> the question is what this for you
[10:32]  * bialix waves hi to all
[11:20] <lifeless> igc: grats on 1.0.0
[12:23] <dsuch> Hi, I'm using bzrlib in a piece of software of mine and I'm wondering if it's safe to keep a reference to a WorkingTree instance in multiple processes?
[12:23] <dsuch> Am I not going to get hit by some weird race condition sooner or later? (Just wondering, not that I have seen anything like that so far)
[12:24] <dsuch> I'm currently using 2.1.0
[12:28] <dsuch> Or, alternatively, can those subprocesses have their own separate WorkingTrees pointing to the same repository location? I guess that should be safe?
[12:38] <lifeless> dsuch: do you mean 'are WorkingTree methods correctly locked' ?
[12:38] <lifeless> dsuch: and the answer is 'we think so' ;)
[12:39] <dsuch> yea, guess that was the question :)
[12:39] <dsuch> thanks
[12:41] <dsuch> lifeless: and if I don't share those objects, there sure will be no problems at all, right?
[12:41] <lifeless> what do you mean by share
[12:42] <dsuch> share as in multiple threads have the same WorkingTree instance assigned to them
[12:43] <dsuch> but it's not that I really want it
[12:43] <dsuch> in fact, I could as well have each thread/subprocess use its own WorkingTree object so there would be no sharing of a WorkingTree instance's state at all
[12:44] <lifeless> so
[12:44] <dsuch> and that, if I understand it correctly, should be perfectly safe?
[12:44] <lifeless> on unix, os locks are not exclusive across threads
[12:44] <lifeless> you can stomp on yourself trivially.
[12:44] <lifeless> *processes* are safe.
[12:45] <lifeless> *threads* are not.
[12:45] <dsuch> mhm
[12:46] <lifeless> even if you have separate WorkingTree objects, in different threads, you could zerg your dirstate file
[12:46] <dsuch> got it
[12:46] <lifeless> dirstate2, *when* we get to it, will not use OS locks at all, and won't have this risk.
[12:47] <dsuch> I fear to ask what a dirstate is :) I take it it's some important internal repo structure?
[12:47] <lifeless> yes
[12:47] <dsuch> ok
[12:47] <lifeless> .bzr/checkout/dirstate
[12:47] <lifeless> it lists all the files in the tree
[12:48] <lifeless> and their inode fingerprint
[12:48] <lifeless> merge status
[12:48] <dsuch> okay so it is important :)
[12:48] <lifeless> semantic changes to this file are locked with a dir-lock, which is safe even in threads.
[12:48] <lifeless> however, readonly locks can do cache-updates to this file
[12:48] <lifeless> and they are only protected by an OS lock
[12:49] <lifeless> which as I mentioned is not actually as safe as one might hope
[12:49] <dsuch> I see.
[12:53] <lifeless> gnight
[12:53] <lifeless> if you have more questions, just ask, I'm sure someone will answer eventually :)
[12:53] <dsuch> sure, thanks again lifeless
[12:54] <dsuch> hope you get better ;-)
[12:54] <dsuch> (sorry, couldn't resist)
[13:30] <felixhummel_> hi! how would you put files under version control that belong to one project, but live in different directories scattered across the whole file system?
[13:31] <felixhummel_> e.g. all hand-edited configuration files of a ubuntu box
[13:32] <jelmer> felixhummel_: Generally the configuration files of a ubuntu box would be in /etc
[13:32] <jelmer> felixhummel_: other than that, you should be able to use symlinks to a versioned directory
[13:34] <felixhummel_> jelmer: so you would do ``cd /etc; bzr init .; bzr add hosts``?
[13:34] <jelmer> felixhummel_: basically, yeah
[13:34] <jelmer> felixhummel_: I'm using the etckeeper app to maintain my /etc
[13:35] <jelmer> it wraps around bzr and takes care of e.g. invoking bzr commit when you upgrade or install packages
[13:36] <felixhummel_> looks like etckeeper fits my use case perfectly. thanks, jelmer!
[13:36] <jelmer> felixhummel_: you're welcome
[14:42] <jelmer> maxb: the bzr-rewrite trunk should be fixed now
[15:56] <ajeans> hello
[15:57] <ajeans> I have a question about "./bzr selftest", and yahoo couldn"t find the answer for me
[15:57] <ajeans> :)
[15:58] <ajeans> ".bzr selftest" runs all the bzr unit tests (> 25000), what is the command to run one
[15:59] <ajeans> (sorry) only one of the unit tests (e.g. tests contained in bzrlib/tests/test_osutils.py) ?
[16:20] <fullermd> ajeans: Either giving it a substring as an argument, or using -s and a class prefix.
[16:29] <ajeans> @fullermd: From the root, I am trying "./bzr selftest -s TestStatus" and also tried "./bzr selftest bzrlib/tests/test_status.py", with no success
[16:35] <ajeans> @fullermd: Thanks for the information, you can pass the method name to only run it
[16:35] <ajeans> ./bzr selftest --help had some information about it.
[16:36] <ajeans> I was hoping to simply pass the Class name to execute all the tests within, but I can still list all the methods manually... thanks again
[16:52] <fullermd> ajeans: You can use -s to pass the class name, it just has to be fully qualified.  e.g., "-s bzrlib.tests.test_foo.TestFoo....."
[16:53] <fullermd> Or 'selftest test_foo'.  The former is faster because it doesn't have to build the full list of all the tests then search through it.
[16:57] <mgedmin> long-term wishlist: automatic mirroring of my bzr branch
[16:57] <mgedmin> sort of like bzr bind or manual bzr push after each commit, but without having to wait for the push
[16:58] <mgedmin> let the push happen in the background, opportunistically
[17:14] <ubuntujenkins> if I do bzr merge lp:~ubuntu-manual/ubuntu-manual-screenshots/bg -r 0..-1 does that update the status of the branch in lanuchpad?
[17:16] <jelmer> ubuntujenkins: it might mark a merge proposal as "merged" if there is a merge proposal for that merge
[17:16] <jelmer> otherwise it won't affect the status of the branch
[17:17] <ubuntujenkins> weird I the status has changed from devolpment to merged. I don't know why its anoying as I have to change it back on 47 branches now
[17:23] <ubuntujenkins> thanks for your help jelmer
[17:49] <ajeans> @fullermd: thanks for the explanation, it works perfectly :)
[17:55] <maxb> jelmer: Excellent! But, now there's a 'trunk', a 'rebase-trunk', and a 'trunk-mirrorred' ... it's a bit confusing
[17:55] <jelmer> maxb: trunk is the right one
[17:55] <jelmer> it's also registered as the development focus
[17:56] <maxb> Sure.. but why the others?
[17:57] <jelmer> historical reasons
[17:57] <maxb> oh. stacked branches prevent deletion?
[17:58] <maxb> perhaps set them as 'Abandoned' if they are no longer relevant?
[17:59] <jelmer> maxb: feel free to do so
[18:00] <maxb> jelmer: I'm pretty sure only the branch owner can
[18:00] <jelmer> maxb: the branch status isn't really useful at the moment imho, and I have too much branches to set all of their statuses appropriately
[18:02] <maxb> I find the branch status quite useful - it would be nice to at least have ones with 'trunk' in their name which are no longer relevant hidden from the project's default branch listing
[18:02] <jelmer> maxb: isn't that what the development focus is for though?
[18:04] <lifeless> moin
[18:05] <jelmer> maxb: I've changed the status for these two branches to abandoned, although I don't really see the problem tbh
[18:05] <jelmer> hey lifeless
[18:06] <jelmer> oh, looks like I could remove them after all
[18:24] <jelmer> lifeless: if you could give some quick feedback on my named-branches patch, that'd still be much appreciated :-)
[18:28] <lifeless> jelmer: ah yes, I knew I forgot something this weekend
[18:28] <lifeless> jelmer: shall do
[19:45] <jelmer> maxb, if your merge request is still relevant, can you please resubmit it against lp:bzr-rewrite?
[20:50] <mgedmin> time bzr rocks on a Nokia N900 --> 1.72 seconds wall-clock time
[20:50] <mgedmin> seems a bit on the high-side
[20:51] <mgedmin> it's a 600 MHz ARM CPU
[20:53] <lifeless> if you run it again?
[21:19] <mgedmin> lifeless, varies between 2.32s and 1.38s (I suspect cpufreq)
[21:19] <lifeless> wow
[21:19] <mgedmin> this is 2.0.2, I should package a newer version...
[22:24] <jono> hey all
[22:25] <jono> anyone here used the bzrlib python module?
[22:32] <lifeless> yes
[22:33] <lifeless> bah
[22:38] <thumper> lifeless: hey
[22:38] <lifeless> hi
[22:38] <thumper> lifeless: when we did stacking we decided that the server should hit to the bzr client to stack
[22:38] <thumper> lifeless: do you know if the --no-stacked (or similar) option can or does ignore the suggestion?
[22:39] <lifeless> it should, it doesn't
[22:39] <thumper> s/hit/hint/
[22:39] <thumper> lifeless: is there a bug?
[22:39] <lifeless> I'm sure of it
[22:55] <slangasek> is anyone here using pristine-tar for importing of upstream tarballs outside of LP?
[22:56] <lifeless> aie aie
[22:56] <slangasek> lifeless: I was trying to work off http://www.advogato.org/person/robertc/diary/130.html to do bzrification and debianization of a new source package, but import-dsc doesn't seem to have usefully imported the autotoolage
[22:57] <slangasek> is there an undocumented step I'm missing?
[22:57] <slangasek> rather, it imported it as part of a single commit with the Debian stuff
[22:57] <lifeless> let me just see what post that is
[22:57] <lifeless> rbtcollins.wordpress.com has better urls
[22:58] <lifeless> ah yes
[22:58] <slangasek> well, rbtcollins.wordpress.com is not what you have linked from Planet Debian :)
[22:58] <lifeless> meh :P
[22:58] <lifeless> ok, so import-dsc does two imports
[22:58] <lifeless> a tarball, accessible from 'bzr tags'
[22:58] <lifeless> and a debianised
[22:59] <lifeless> look at 'bzr log -n0' or at 'bzr tags'
[22:59] <slangasek> neither shows me what I'm looking for
[22:59] <lifeless> the upstream-XYZ tag should be precisely the tarball contents
[22:59] <slangasek> does it matter that this is 3.0 (quilt) ?
[22:59] <lifeless> probably, AFAICT quilt-3.0 is a <censored>-<censored>
[23:00] <lifeless> uhm
[23:00] <slangasek> there's no 3.0 (bzr) format
[23:00] <slangasek> and 3.0 (native) is n/a
[23:00] <slangasek> and I have an upstream tar.bz2
[23:00] <lifeless> slangasek: pastebin bzr tags and bzr log -n0 somewhere
[23:02] <slangasek> http://paste.ubuntu.com/385962/, http://paste.ubuntu.com/385963/
[23:03] <lifeless> ok, no upstream- tag
[23:03] <slangasek> I'll mention that when following the directions as written, import-dsc first gave me an error about 'bzr add'ing debian/changelog first
[23:03] <slangasek> and rather than doing this, I moved my debian/ dir aside
[23:04] <slangasek> so if I'm meant to actually do the 'bzr add', I can go back and try that
[23:04] <lifeless> do you have the session in history, so I can see it?
[23:04] <slangasek> I can uncommit and do it again? :)
[23:04] <lifeless> no
[23:05] <lifeless> you can start from a fresh branch though
[23:05] <slangasek> ok
[23:05] <lifeless> *don't* branch from this branch
[23:05] <slangasek> yep
[23:06] <slangasek> lifeless: http://paste.ubuntu.com/385965/
[23:07] <lifeless> slangasek: and bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk is an *upstream* branch - no packaging in it at all ?
[23:08] <lifeless> slangasek: the debian dir shouldn't be present: the revert step in my instructions is to remove the packaging (because it said debianise as normal :P)
[23:08] <slangasek> correct
[23:08] <igc> morning
[23:08] <slangasek> but 'bzr revert' doesn't delete new files
[23:09] <lifeless> slangasek: heh
[23:09] <lifeless> slangasek: anyhow, yes, you are right to not have the debian dir present
[23:09] <slangasek> so I inferred, when I got the error, that this is what you wanted, so I moved debian/ away :)
[23:09] <lifeless> ok
[23:09] <lifeless> and what happens then
[23:11] <slangasek> http://paste.ubuntu.com/385967/
[23:11] <slangasek> single commit, no upstream tag
[23:11] <lifeless> can you paste the dsc
[23:11] <slangasek> (this is with bzr-builddeb 22, btw; Debian unstable seems to be a version behind Ubuntu)
[23:12] <lifeless> and check there is only one dsc in the dir above
[23:12] <lifeless> slangasek: generally you will want bzr-builddeb trunk :P
[23:12] <slangasek> http://paste.ubuntu.com/385968/
[23:12] <slangasek> no, generally *I* want to be dogfooding what's actually in the distro ;)
[23:12] <slangasek> yes, there's only one .dsc
[23:13] <lifeless> this is very strange
[23:13] <lifeless> I'd like you to try trunk.
[23:13] <lifeless> if it doesn't work, file a bug.
[23:13] <slangasek> ok - url?
[23:13] <lifeless> if it does, file a different bug
[23:14] <lifeless> bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb
[23:19] <slangasek> lifeless: yep, works with trunk
[23:19] <lifeless> slangasek: so; you want a newer package ;)
[23:19] <slangasek> (another wrinkle: had an out-of-date version of bzr in my Debian env, updated from bzr 2.0 to 2.1 to get builddeb trunk to work; and I can't seem to use the old builddeb in unstable with new bzr...)
[23:19] <lifeless> jml: are you online?
[23:20] <slangasek> looks like bzr-builddeb 2.3 is in experimental, I'll double-check with that also
[23:21] <slangasek> 2.3 also works correctly
[23:22] <slangasek> so someone needs to put 2.3 in unstable
[23:22] <slangasek> jelmer: ^^ :)
[23:26] <jono_> mwhudson, around?
[23:30] <mwhudson> jono_: just about to have lunch, but can hang around a bit ... how can i help?
[23:30] <jono_> mwhudson, I am just starting hacking with bzrlib - is there a short example of checking out a branch?
[23:31] <jono_> mwhudson, actually, forget it
[23:31] <jono_> I figured it out :)
[23:31] <mwhudson> jono_: heh
[23:31] <jono_> thanks!
[23:31] <mwhudson> jono_: generally to find out how command 'foo' works
[23:31] <mwhudson> look for cmd_foo in bzrlib/builtins.py
[23:31]  * mwhudson afk for a few then
[23:31] <jono_> right thanks!
[23:31] <jono_> cheers pal
[23:31] <jono_> I will add some examples to python-snippets
[23:32] <jono_> would be awesome if you could submit some more :)
[23:32] <Daviey> There is no stopping jono_ now!
[23:32] <jono_> Daviey, :)
[23:32] <jono_> just hacking Acire to check out the code directly from bzr
[23:32] <jono_> then no dailly PPA is needed :)
[23:33] <lifeless> jono_: hi
[23:33] <jono_> hey lifeless
[23:33] <lifeless> jono_: your mail server is naffed
[23:33] <poolie> hello jono, lifeless
[23:34] <jono_> lifeless, yeah, I know
[23:34] <lifeless> jono_: I emaile you a week ago with the answer to this :P
[23:34] <jono_> 1and1 having troubles
[23:34] <jono_> lifeless,
[23:34] <jono_> ahhh
[23:34] <jono_> can you forward it to jono AT ubuntu DOT com?
[23:34] <lifeless> when you pinged me, then disconnected ;P
[23:34] <jono_> hah
[23:34] <lifeless> jono_: sure
[23:34] <jono_> thanks!
[23:36] <lifeless> poolie: there is a gift for you in the tribunal review queue ;)
[23:38] <poolie> heh, thanks
[23:39] <poolie> btw did you see my grief on friday was due to a fsck bug?
[23:39] <lifeless> poolie: I didn't see the resolution of it, no.
[23:39] <lifeless> thats good news.
[23:41] <poolie> my machine is still down but at least the problem is known
[23:41] <poolie> it's actually fairly obvious where it must be
[23:41] <poolie> ironically similar to some bugs we had in dirstate
[23:42] <poolie> in this case, it incorrectly sorts things that are lexicographically before '.' i think
[23:42] <lifeless> heh
[23:42] <lifeless> so 'do not fsck and you will be fine'
[23:42] <lifeless>  ?
[23:44] <poolie> do not use -D
[23:45] <poolie> *afaik, there may be other problems
[23:45] <poolie> actually since the manpage says it may resort directories sometimes even without -D
[23:45] <poolie> i don't think that's enough
[23:45] <poolie> and you can't upgrade without fscking
[23:58] <lifeless> mwhudson: is the link in http://doc.bazaar.canonical.com/bzr.dev/developers/#developing-using-bzrlib stale? (to the api docs)