[00:00] <Freddi> But I found how to create a Dbusmenu on https://wiki.ubuntu.com/Unity/LauncherAPI#Python_Example Unfortunately they attach it to a unity quicklist. I assume there is a similar way to add the Dbusmenu to the appmenu?
[00:00] <thumper> hi Freddi
[00:00] <thumper> Freddi: ted is probably the person who could help most
[00:00] <thumper> Freddi: unfortunately he is done for the day
[00:01] <Freddi> Ok, so I can reach him tomorrow?
[00:01] <thumper> should be able to, he works US mountain time UTC-7 (I think)
[00:01] <Freddi> thanks!
[00:02] <thumper> np
[00:44] <bschaefer> jaytaoko, ping. Have a question about StaticText and StaticCairoText
[01:22] <bschaefer> thumper, hey, if you have some time could you look at this branch that should be ready for merge now!
[01:22] <bschaefer> https://code.launchpad.net/~brandontschaefer/unity/fix-711199/+merge/89192
[01:39] <jaytaoko> bschaefer: ping
[01:43] <bschaefer> hey jaytaoko
[01:44] <thumper> bschaefer: reviewed
[01:44] <bschaefer> jaytaoko, so when I tried using StaticText it was not working correctly; and also giving some weird behavior
[01:45] <bschaefer> thumper, thanks, is there anything you see that I should change with it?
[01:47] <bschaefer> thumper, nevermind see it now!
[01:48] <thumper> :)
[01:48] <bschaefer> thumper, what do you mean by normal result view?
[01:49] <thumper> the grid results
[01:49] <thumper> I couldn't see anywhere where you maked the other view inactive
[01:49] <thumper> what happens there?
[01:50] <bschaefer> thumper, hmm, do you mean with the use of active_lens_view?
[01:50] <thumper> maybe...
[01:51] <bschaefer> thumper, that was a global I was using, it get set else where when the lens gets chagned
[01:51] <thumper> bschaefer: so if it isn't there, nothing shows?
[01:53] <bschaefer> thumper, each view has its own lens, and when it isn't the active lens I don't wouldn't think anything would get active in it
[01:54] <bschaefer> thumper, each lens remembers its state though, so when I type "abc" in the music lens then leave and come back it remembers that state
[01:54]  * thumper nods
[01:54] <bschaefer> thumper, so I don't think I have to set anything as inactive since that should have already been the case
[01:54] <thumper> and it works?
[01:54] <thumper> :)
[01:54] <bschaefer> thumper, as I only changed what happens when the on_search_finished signal gets emited()
[01:55] <bschaefer> and yes :)
[01:55] <bschaefer> I should make a small clip
[01:55] <thumper> ok, just the style changes then :)
[01:55] <bschaefer> thumper, also will change to use sstream
[01:56] <bschaefer> thumper, there are a few screen shots on the bug report ill make a small clip to put of there to demo it
[01:56] <bschaefer> thumper, also fixed a bug in the music lens with the help of mhr3 which was causing some problems but that is gone now
[01:57] <thumper> awesome
[01:58]  * thumper goes on the school run
[01:58] <bschaefer> thumper, have fun :)
[02:10] <bschaefer> jaytaoko, hey, I have also been looking at the IMContext, and the ibus is not connecting with the ibus-daemon when i gets created
[02:10] <bschaefer> which is weird, but that is something im looking at now
[02:17] <jaytaoko> bschaefer: sorry, I have to go but I will be back later
[02:19] <bschaefer> jaytaoko, no worries, I need to dig some more :)
[02:34] <TheMuso> Could a unity dev with review powers please bless lp:~themuso/unity/fix-launcher-accessible-focus? njpatel approved it, but it hasn't been marked as approved, and I'd like to get it into trunk... It restores accessibility to the launcher.
[03:12] <solclaimjak> I just tried to install unity 5.2 and it doesn't appear to have upgraded
[03:13] <solclaimjak> how do I check to see which version i am running?
[03:20] <TheMuso> solclaimjak: apt-cache policyh unity if you are comfortable with the terminal.
[03:20] <TheMuso> Otherwise there is likely a way to check in software centre, but I'm not sure about how that is done, since I tend not to use that myself.
[03:21] <bschaefer> TheMuso, yeah I can approve it, ill trust njpatel judgment ;)
[03:34] <solclaimjak> Well, it says I am using 5.2.0 but it doesn't appear to have the changes that the sites have said it has. I will keep looking...
[03:36] <solclaimjak> i think i am using unity 2d....
[03:36] <solclaimjak> thanks for the help :)
[03:48] <TheMuso> bschaefer: Thanks very much.
[04:38] <jaytaoko> bschaefer: ping
[04:46] <bschaefer> jaytaoko, hey!
[04:47] <jaytaoko> bschaefer: hey
[04:48] <jaytaoko> bschaefer: so you had a question about StaticText?
[04:48] <bschaefer> jaytaoko, o yes, so when I changed my StaticCairoText to use StaticText it would just not work anymore!
[04:49] <bschaefer> jaytaoko, so I wanted to ask you if there would be a reason for the StaticText to not like the use of SetText()
[04:50] <bschaefer> jaytaoko, branch for reference; https://code.launchpad.net/~brandontschaefer/unity/fix-711199/+merge/89192
[04:51] <jaytaoko> bschaefer: let me check
[04:51] <bschaefer> jaytaoko, thank you!
[04:52] <jaytaoko> bschaefer: does the code crash, or it just doesn't work?
[04:52] <bschaefer> jaytaoko, it works fine, no warning either. What is weird is the text will only show up on the last lens
[04:53] <bschaefer> since there are 4, so when I set it use StaticText the other lenses dont show a message except for 1
[04:53] <bschaefer> and when that message gets set to "" like half an S is still rendered. It is slightly wired.
[04:54] <bschaefer> jaytaoko, let me take some screenshots!
[04:55] <jaytaoko> bschaefer: ok, I am downloading the branch. I will compile it shortly.
[04:55] <bschaefer> jaytaoko, sweet, I was going to ask someone to test that soon
[04:56] <bschaefer> jaytaoko, was trying to get recordmydesktop to work but nothing would render under the video! (besides my wallpaper...)
[05:01] <jaytaoko> bschaefer: no worry, I am compiling
[05:02] <bschaefer> jaytaoko, cool, also if you have some time we can talk about IMContext and why ibus_bus_is_connected is returning FALSE!
[05:03] <bschaefer> jaytaoko, it might be pretty late for you, tomorrow all my focus is going into that
[05:03] <bschaefer> jaytaoko, I lost track of time haha
[05:05] <jaytaoko> bschaefer: sure, let me get the IMContext branch
[05:10] <bschaefer> jaytaoko, also found this: http://src.chromium.org/svn/trunk/src/chrome/browser/chromeos/input_method/
[05:11] <bschaefer> jaytaoko, you might have looked at it, but it seems to be doing something very similar to what we are trying to do
[05:12] <jaytaoko> bschaefer: yeah. And it seems the only way to get into IM is to look at what others have done before. Otherwise it is hard to start it from scratch
[05:13] <jaytaoko> bschaefer: ok, I am running your branch
[05:13] <bschaefer> jaytaoko, yeah i know, the api is very bad...
[05:13] <jaytaoko> bschaefer: i see the text message when there is no result found
[05:13] <bschaefer> jaytaoko, alright, so with the StaticCairoText everything works correctly doesn't it?
[05:13] <bschaefer> jaytaoko, right now it is using the StaticCairoText
[05:14] <jaytaoko> bschaefer: ok, How to I use StaticText
[05:14] <bschaefer> jaytaoko, you just have to change 2 lines of code
[05:14] <jaytaoko> bschaefer: tell me the file name where I do the change
[05:14] <bschaefer> jaytaoko, in LensView.h and LensView.cpp
[05:14] <bschaefer> LensView.h change StaticCairoText to StaticText
[05:15] <bschaefer> and in LensView.cpp change new StaticCairoText to new StaticText
[05:15] <jaytaoko> bschaefer: I see it
[05:16] <bschaefer> jaytaoko, wait it is working for you?
[05:16] <jaytaoko> bschaefer: no still compiling
[05:16] <bschaefer> jaytaoko, o, ops thought you ment you see it haha
[05:16] <jaytaoko> bschaefer: I was talking about the StaticCairoText
[05:16] <bschaefer> yeaaah
[05:17] <bschaefer> jaytaoko, but good the StaticCairoText is working for you!
[05:18] <jaytaoko> bschaefer: compiling with StaticText...
[05:22] <bschaefer> jaytaoko, what is wired for me is the fact that the StaticText works with 1 out of the 4 lenses
[05:23] <jaytaoko> bschaefer: it seems to be working fine here with StaticText
[05:23] <jaytaoko> bschaefer: let me check again...
[05:24] <jaytaoko> bschaefer: what I do is I type some bogus text in the search entry, and then it displays the "No result" message in the center
[05:24] <bschaefer> jaytaoko, for all the lenses?
[05:24] <jaytaoko> bschaefer: yes, for all lenses
[05:25] <bschaefer> jaytaoko, hmm weird. Im going to recompiling nux as I pulled from trunk and it said some fonts were changed
[05:25] <bschaefer> maybe thats my problem
[05:25] <jaytaoko> bschaefer: the font stuff in nux as nothing to do with Unity... it is something else
[05:26] <jaytaoko> bschaefer: what is your revision of Nux?
[05:26] <bschaefer> jaytaoko, hmm, that is weird; let me take a screen shot of it half ass working on the music lens
[05:26] <bschaefer> jaytaoko, well I just pulled from trunk and am comping it right now so im not sure.
[05:28] <bschaefer> jaytaoko, in the meantime does everything look good on the no-results message to you?
[05:29] <jaytaoko> bschaefer: looks fine here
[05:30] <bschaefer> jaytaoko, http://imgur.com/Uan8J
[05:30] <bschaefer> so that is a picture of what it looks like where there are results
[05:30] <bschaefer> and you can see the sliver of the 'S' in the middle
[05:32] <bschaefer> jaytaoko, and here is one of the home lens http://imgur.com/UnYOW
[05:32] <bschaefer> jaytaoko, with StaticText
[05:32] <jaytaoko> bschaefer: Are you on precise?
[05:32] <bschaefer> yeah
[05:33] <bschaefer> jaytaoko, let me make sure everything is up to date. Nux just got done compiling and ill re compiling unity
[05:34] <bschaefer> jaytaoko, while that is going, I wanted to ask you where you left off on the IMContext branch
[05:34] <bschaefer> jaytaoko, and to kinda hear what your thinking/approach to this was
[05:36] <jaytaoko> bschaefer: http://i.imgur.com/rzPmf.jpg this is what i get
[05:36] <bschaefer> jaytaoko, Thats good! As im guessing I messed something up ;)
[05:37] <jaytaoko> bschaefer: go ahead with the IM
[05:38] <bschaefer> jaytaoko, so now that we can create the IMEContext I started seeing where it was failing in the code
[05:38] <bschaefer> jaytaoko, which happens to be here...looks up the code online one sec
[05:39] <bschaefer> http://bazaar.launchpad.net/~unity-team/nux/nux.text-entry-dev/view/head:/Nux/InputMethodIBus.cpp#L35
[05:39] <bschaefer> jaytaoko, which is pretty much saying that the ibus_ cannont connect with the ibus-daemon!
[05:40] <bschaefer> jaytaoko, so now I have started looking through that chromeos src to see what is missing before that call
[05:40] <jaytaoko> bschaefer: right. do we need some env setting
[05:40] <bschaefer> jaytaoko, that one is used when the ibus is already working
[05:41] <jaytaoko> bschaefer: also tell me if I need to have some special settings on my system
[05:41] <bschaefer> jaytaoko, I will, umm I think to compile the test right now you need to include the $(IBUS_CFLAGS) in the make file
[05:41] <bschaefer> which I missed doing, because that is need when you create the IMEContext
[05:42] <jaytaoko> bschaefer: can you send me the line in the make file for that
[05:42] <bschaefer> jaytaoko, yeah
[05:43] <bschaefer> in tests/Makefile.am::128
[05:43] <bschaefer> jaytaoko, put $(IBUS_CFLAGS) \
[05:43] <bschaefer> and under that in TestLibs add $(IBUS_LIBS) \
[05:44] <bschaefer> jaytaoko, I should just commit these changes...
[05:50] <jaytaoko> bschaefer: system crash! My system has been having issues lately...
[05:51] <jaytaoko> bschaefer: can you type in the makefile info again?
[05:51] <bschaefer> jaytaoko, that sucks! Also just updated both unity and nux and the text still isn't show hmm
 in tests/Makefile.am::128
 jaytaoko, put $(IBUS_CFLAGS) \
 and under that in TestLibs add $(IBUS_LIBS) \
[05:51] <bschaefer> jaytaoko, ill be pushing those changes in a second
[05:52] <bschaefer> jaytaoko, just wanted to double check it working before I push
[05:58] <jaytaoko> bschaefer: ok, compiling
[06:02] <bschaefer> jaytaoko, alright, just pushed the changed
[06:02] <bschaefer> jaytaoko, alright, just pushed the changes
[06:02] <bschaefer> took a little to compile
[06:03] <jaytaoko> bschaefer: pulling
[06:07] <bschaefer> jaytaoko, another idea for getting this to work would to try to figure out why ibus isn't working through XIM with TextEntry
[06:08] <bschaefer> jaytaoko, also do you have ibus setup?
[06:10] <jaytaoko> bschaefer: not sure, tell me how to
[06:10] <bschaefer> jaytaoko, so ibus should come with unity, so on the command line type "ibus-setup"
[06:10] <bschaefer> jaytaoko, let me know if it ask to start the ibus-daemon
[06:11] <jaytaoko> bschaefer: it started and I see the IBus preference panel
[06:11] <bschaefer> jaytaoko, cool, now go over a tab to input method
[06:11] <jaytaoko> ok
[06:12] <bschaefer> jaytaoko, then under select an input method select chinese and pinyin
[06:12] <bschaefer> jaytaoko, then add
[06:12] <jaytaoko> bschaefer: done
[06:12] <bschaefer> ok now close and go the command line and hit Ctrl + Space
[06:12] <bschaefer> and try typing
[06:13] <bschaefer> jaytaoko, and you should start typing in chinese!
[06:13] <bschaefer> jaytaoko, Ctrl + Space to leave that mode
[06:14] <jaytaoko> bschaefer: ok, i type and I see chinese characters
[06:14] <bschaefer> jaytaoko, cool, that is set up then! You can also switch the Input Method to XIM by right clicking the command prompt
[06:15] <bschaefer> jaytaoko, right now it should be IBus, but under XIM ibus still works!
[06:15] <bschaefer> jaytaoko, well it should, since your ibus daemon had already started
[06:15] <jaytaoko> bschaefer: ok it is IBUS
[06:15] <bschaefer> jaytaoko, switch it to X Input Method
[06:16] <jaytaoko> bschaefer: so Ibus uses XIM?
[06:16] <bschaefer> and see if ibus is till working
[06:16] <bschaefer> well ibus works through XIM, which could be a possible fix to this bug (1 of the options)
[06:16] <jaytaoko> bschaefer: yes, ibus is still working if I choose XIM
[06:17] <bschaefer> jaytaoko, see the reason njpatel and I used that Env var is because the when ibus was working XIM in the Dash wasn't working
[06:18] <bschaefer> jaytaoko, and it was being very weird, because XIM alone should be able to handle the ibus (I believe)
[06:18] <jaytaoko> bschaefer: ok, so that is  a  bug?
[06:19] <jaytaoko> bschaefer: what about gtk, it uses Ibus or XIM?
[06:19] <bschaefer> jaytaoko, possibly, that was kinda a while ago and I should replicate it
[06:19] <bschaefer> jaytaoko, well IBus has code for XIM, it's slightly confusing and it also has code for GTK
[06:20] <bschaefer> jaytaoko, the code that gets used for XIM works correctly but when the ibus uses the gtk version it doesn't like korean text
[06:20] <bschaefer> because of the env var
[06:21] <jaytaoko> bschaefer: ok
[06:21] <bschaefer> jaytaoko, I feel like im doing a bad job at explaining this...
[06:23] <jaytaoko> bschaefer: it sure isn't easy to understand
[06:24] <jaytaoko> bschaefer: Are you running the text-entry example program?
[06:24] <bschaefer> jaytaoko, yeah it runs, but no ibus support. Did you comment back in the line where you create the ime?
[06:25] <bschaefer> jaytaoko, yeah ibus is very confusing, im not sure why there havn't been more problems like this...
[06:25] <jaytaoko> bschaefer: no, let me do that
[06:25] <jaytaoko> bschaefer: wait where is that commented line?
[06:26] <bschaefer> jaytaoko, under tests/text-entry-xtext.cpp::86
[06:26] <jaytaoko> bschaefer: wait, you are talking about tests/text-entry-xtest.cpp
[06:26] <jaytaoko> bschaefer: right
[06:26] <bschaefer> jaytaoko, yeah it is where I thought you were working off
[06:27] <jaytaoko> bschaefer: right, but I should turn this into and example for now rather than a test
[06:27] <bschaefer> jaytaoko, so I was looking though the other code and it seems to checks if the ibus has made a connection with the daemon a few times
[06:28] <bschaefer> ibus_controller.cc:877:    ibus_init();
[06:28] <bschaefer> ibus_engine_controller.cc:123:    ibus_init();
[06:28] <bschaefer> ibus_ui_controller.cc:126:    ibus_init();
[06:29] <bschaefer> jaytaoko, which that init according to the api and some comments I saw is what gets ibus setup to make a connection
[06:29] <bschaefer> jaytaoko, for reference: src.chromium.org/svn/trunk/src/chrome/browser/chromeos/input_method
[06:30] <jaytaoko> bschaefer: looking
[06:31] <bschaefer> jaytaoko, because I swear if we can get the ibus to successfully to connect I dont see why It wouldn't work
[06:31] <bschaefer> as you have all the other signals all set up
[06:33] <bschaefer> jaytaoko, I wonder if we need to also set up an ibus_config
[06:34] <jaytaoko> bschaefer: can you go on mumble or skype?
[06:35] <bschaefer> jaytaoko, don't have a webcam for skype but I can go on so you can talk haha
[06:36] <jaytaoko> bschaefer: no need for web cam, just a microphone
[06:36] <bschaefer> jaytaoko, Ill get one tomorrow, forgot that is not what is required...haha
[06:37] <jaytaoko> bschaefer: no problem
[06:37] <bschaefer> but I can still get on skype for now for that
[06:37] <bschaefer> jaytaoko, if it helps you
[06:38] <jaytaoko> bschaefer: no if you don't have a mic, we can do that another time
[06:38] <jaytaoko> bschaefer: in ibus_ui_controller.cc, ConnectToIBus is initializing ibus
[06:38] <bschaefer> jaytaoko, alright, yeah that would help. Ill have one tomorrow!
[06:38] <jaytaoko> bschaefer: just like we do
[06:38] <bschaefer> jaytaoko, yup
[06:38] <bschaefer> jaytaoko, but it is also doing it in 2 other locations
[06:39] <bschaefer> ibus_controller.cc:877:    ibus_init();
[06:39] <bschaefer> ibus_engine_controller.cc:123:    ibus_init();
[06:39] <bschaefer> jaytaoko, in those 2 locations it is doing pretty much the same thing
[06:39] <bschaefer> jaytaoko, but it seems like they have to keep checking if the daemon is ready for a connection
[06:40] <bschaefer> jaytaoko, this code actually has a lot of comments
[06:40] <jaytaoko> bschaefer: ok in our case we only need to do it once and make sure it ibus_bus_is_connected returns true
[06:41] <bschaefer> jaytaoko, yeah, but I wonder if the ibus_config has to be setup
[06:42] <bschaefer> jaytaoko, GDBusConnection* ibus_connection = ibus_bus_get_connection(ibus_);
[06:42] <bschaefer> jaytaoko, that line looks like more of a direct call to get the connection
[06:43] <jaytaoko> bschaefer: so I checked and ibus_init is working
[06:43] <jaytaoko> bschaefer: it returns a valid ibus pointer
[06:44] <bschaefer> jaytaoko, so after the ibus_init and bus_ = new... the pointer isn't NULL?
[06:44] <bschaefer> jaytaoko, im about to send the ibus_bus_is_connected through a while loop to see if it will ever connect...
[06:44] <jaytaoko> bschaefer: yes, it is not null. You maybe right, we have to call ibus_bus_get_connection before we check ibus_bus_is_connected
[06:46] <bschaefer> jaytaoko, good, and yeah Im just wondering why they keep checking 3 different times if bus_ is made and ready to go
[06:46] <bschaefer> jaytaoko, and right now ibus_bus_is_connected(bus_) is always returning false...
[06:47] <bschaefer> jaytaoko, which is why im thinking something is missing...I need to take a look at that smaller code example you found
[06:48] <bschaefer> jaytaoko, for reference: http://code.google.com/p/google-gadgets-for-linux/source/browse/trunk/extensions/gtk_edit_element/
[06:48] <jaytaoko> bschaefer: I added GDBusConnection* ibus_connection = ibus_bus_get_connection(bus_);
[06:49] <jaytaoko> bschaefer: I expect to receive a message in void IBusIMEContext::OnConnected(IBusBus *bus)
[06:50] <bschaefer> jaytaoko, oo, so look at ibus_ui_controller.cc ::150
[06:50] <bschaefer> jaytaoko, yeah it should send a message there when it gets connected
[06:51] <bschaefer> so it looks like they get the connection then make a service out of it
[06:51] <bschaefer> jaytaoko, but im not really sure what the IBusPanelService is...
[06:51] <jono> thumper, around?
[06:53] <jaytaoko> bschaefer: how to you get to see the line numbers
[06:53] <bschaefer> o I wget it so i can mess around with it in the command line
[06:53] <bschaefer> jaytaoko, and grep
[06:54] <jaytaoko> bschaefer: ok, I copied the file into my text editor
[06:54] <jono> are there no PPA hooks for the unity-team PPA?
[06:54] <jono> I can'
[06:54] <jono> I can't file a bug using ubuntu-bug
[06:56] <bschaefer> jaytaoko, man there is so much code to dig through...
[06:57] <jaytaoko> bschaefer: true!
[06:57] <bschaefer> jaytaoko, i really wish the api had more details, like I looked at the ibus_panel and it just says it is an ibus_panel haha
[06:58] <bschaefer> jaytaoko, very redundant
[06:58] <jaytaoko> bschaefer: yeah, it isn't helping much
[06:58] <jaytaoko> bschaefer: ok, almost 2am here.
[06:58] <jaytaoko> bschaefer: I will try to continue tomorrow if possible
[06:58] <bschaefer> jaytaoko, yeah go to sleep, Ill dig some more but I spent a lot of time doing other stuff today
[06:59] <bschaefer> jaytaoko, no worries, ill spend some more time on it and a lot more tomorrow
[06:59] <jaytaoko> bschaefer: thank you very much for your help!
[06:59] <jaytaoko> bschaefer: cheers
[06:59] <bschaefer> jaytaoko, no worries, this is still fun (somewhat haha; when it is fixed it iwll be worth it!)
[06:59] <bschaefer> jaytaoko, you too, have a good night!
[07:00] <jaytaoko> bschaefer: thanks !
[07:07] <jono> morning didrocks
[07:07] <didrocks> hey jono
[07:08] <jono> hows things?
[07:08] <jono> I have been rocking the multi-monitor goodness herer
[07:08] <jono> generally working well
[07:08] <didrocks> I'm fine here, thanks! Quite cold in France though :)
[07:08] <didrocks> ah nice! ;)
[07:08] <jono> didrocks, quick q: Nick told me we can use ubuntu-bug on PPAs if there is a hook included in the PPA
[07:08] <jono> do you know if this is the case?
[07:09] <didrocks> jono: yeah, it will file bug upstreams only, but that won't really help us in that case, because for instance, crashes won't get retraced
[07:10] <didrocks> jono: I think that we should work on a more general purpose on the crash database next cycle to support some "blessed" ppas as we are going more and more to the ppa direction
[07:10] <didrocks> (or using the -proposed pocket)
[07:10] <jono> right
[07:10] <jono> if we are moving more and more to proposed, this seems like a natural next step
[07:10] <didrocks> indeed :)
[07:11] <didrocks> that's why I didn't installed the hook, as the most valuable info from the ppa are the crashes
[07:11] <didrocks> crashes*
[07:11] <jono> right
[07:11] <didrocks> for the rest, the testing tool should cover the regressions :)
[07:11] <jono> cool
[07:12] <jono> btw, do you know if notify-osd bubbles should appear on both monitors?
[07:13] <didrocks> jono: I think design planned that was two cycles already, but nobody in dx is maintaining the osd notification
[07:14] <jono> right, I filed https://bugs.launchpad.net/unity/+bug/928095 and unfortunately it kind of means that I miss almost all the bubbles
[09:00] <bschaefer> mhr3, hey, pushed new changes :)
[09:01] <bschaefer> mhr3, should have question that since max_results had a default value!!
[09:02] <mhr3> bschaefer, great :)
[09:16] <bschaefer> mhr3, also, if you get a chance could you look over my no-results branch? I fixed thumpers problems, but the more people who look at the better :)
[09:16] <mhr3> bschaefer, yea, sure i'll give it a go
[09:16] <bschaefer> mhr3, since you worked on the no-results-hint, https://code.launchpad.net/~brandontschaefer/unity/fix-711199
[09:17] <bschaefer> mhr3, thanks, I kept the hardcoded string in there but I will have a talk with thumper about it
[09:19] <bschaefer> mhr3, Ill owe you a lot of beer by the next uds at this rate haha
[09:27] <tsdgeos> greyback: screeinfo warning fixed
[09:27] <greyback> tsdgeos: ok, approving (and morning!)
[09:27] <tsdgeos> greyback: morning :-)
[09:28] <greyback> tsdgeos: you see my message on https://code.launchpad.net/~aacid/unity-2d/unity-2d_panel-newbuttons/+merge/91442
[09:28] <tsdgeos> yep
[09:28] <tsdgeos> saw that
[09:29] <greyback> ok, just thought I'd annoy you a little more :)
[09:39] <tsdgeos> greyback: which shortcut keys do you have associated for mumble-speak shortcut?
[09:56] <greyback> tsdgeos: ctrl+shift
[09:57] <tsdgeos> greyback: can you try this? close mumble, kill all your unity-2d-launcher, start mumble, start unity-2d-launcher, check if your ctrl+shift shortcut works
[09:57] <greyback> tsdgeos: launcher or shell? Or does it matter
[09:58] <tsdgeos> greyback: well, Kaleo complained that failed on shell and we should fix it before merging, but i can reproduce it too with launcher, so please try with launcher to see if it's a bug we introduced with shell or was already there
[09:58] <greyback> tsdgeos: ok, trying..
[10:00] <greyback> tsdgeos: yep, I reproduce here too
[10:00] <tsdgeos> greyback: ok, thanks, will open a bug against unity-2d and remove it from the stack of things to fix in -shell before merging
[10:01] <greyback> tsdgeos: ok. Mumble isn't receiving any keystrokes afaics. Possibly a Mumble bug (shock!)
[10:02] <tsdgeos> greyback: maybe
[10:02] <tsdgeos> you have to kill it and start it again
[10:02] <tsdgeos> then it works
[10:02] <greyback> tsdgeos: but report against 2d for now, we'll deal with it later
[10:03] <greyback> tsdgeos: got time for a quick mumble?
[10:03] <tsdgeos> greyback: sure
[10:15] <greyback> tsdgeos: screeninfo-refactor approved
[10:15] <tsdgeos> yay
[10:16] <kaleo> greyback: yay :)
[10:19] <snadge> why does the volume control have a light grey background now? :p
[10:24] <kaleo> snadge: good question, Cimi?
[10:24] <kaleo> Cimi: 11:19 < snadge> why does the volume control have a light grey background now? :p
[10:25] <Cimi> Kaleo, bug in ido
[10:26] <Kaleo> Cimi: cheers
[10:31] <tsdgeos> Kaleo: the mumble bug affects regular unity-2d too so together with greyback we agreed it doesn't make sense to delay shell merging because of that
[10:32] <greyback> tsdgeos: can you confirm that https://code.launchpad.net/~aacid/unity-2d/unity-2d_test_alt_f2_esc_alt_f2/+merge/91660 is for merging in trunk, and not shell?
[10:32] <tsdgeos> greyback: yes, that's the test, we make it go to trunk and then merge it to shell, no?
[10:33] <greyback> tsdgeos: yep, just wanted to check
[10:39] <Kaleo> tsdgeos: agreed
[10:40] <Kaleo> tsdgeos: any idea since when?
[10:40] <Kaleo> tsdgeos: do we have a bug report?
[10:40] <tsdgeos> nope & nope
[10:42] <Kaleo> tsdgeos: rev 893 seems like a good candidate for being the culprit
[10:43] <Kaleo> tsdgeos: and it's not
[10:43] <Kaleo> tsdgeos: bisecting
[10:43] <tsdgeos> Kaleo: oki
[10:46] <tsdgeos> greyback: fixed conflicts on screeinfo again https://code.launchpad.net/~unity-2d-team/unity-2d/refactor-screeninfo/+merge/91471 approve please?
[10:57] <Kaleo> tsdgeos: raaah, I reverted up to rev 800 and still no luck..
[10:57] <tsdgeos> Kaleo: you sure it's not been broken "forever" ?
[10:58] <Kaleo> tsdgeos: pretty sure as I was using mumble everyday :)
[10:58] <tsdgeos> Kaleo: and starting unity-2d-launcher while mumble was on?
[10:58] <Kaleo> tsdgeos: good point
[11:00] <Kaleo> tsdgeos: right, you are correct
[11:01] <Kaleo> tsdgeos: with any revision, mumble does not break if the launcher was started before mumble
[11:01] <Kaleo> tsdgeos: and with any revision, in the opposite order, it breaks
[11:01] <tsdgeos> yeah :/
[11:01] <tsdgeos> might even be a mumble bug
[11:01] <Kaleo> tsdgeos: so, it's problematic if Unity crashes when mumble is running
[11:01] <Kaleo> tsdgeos: otherwise, no big deal
[11:01] <tsdgeos> true
[11:01] <Kaleo> tsdgeos: let's report the bug and forget about it
[11:02] <Kaleo> tsdgeos: priority medium I would say
[11:02] <tsdgeos> ok
[11:02] <tsdgeos> will do in a sec
[11:02] <Kaleo> tsdgeos: thanks!
[11:19] <Kaleo> tsdgeos: doing another round of quick testing on shell I spotted one issue
[11:20] <Kaleo> tsdgeos: the dash maximise button is still at the bottom right corner :(
[11:20] <tsdgeos> Kaleo: shoot
[11:20] <Kaleo> tsdgeos: I'm figuring out why with nerochiaro
[11:20] <tsdgeos> dash maximise button?
[11:20] <tsdgeos> you mean the one that shows in the panel?
[11:21] <Kaleo> tsdgeos: the one button that maximises the dash; it used to be at the bottom right corner of the dash and was moved to the panel
[11:21] <Kaleo> tsdgeos: but in the shell branch, we have both..
[11:21] <tsdgeos> ahhh
[11:21] <apw> do i expect selecting an album in the music lense will start that music playing, rather than just opening banshee and doing nothing ?  (precise)
[11:24] <tsdgeos> Kaleo: do i remove it? or wait for nerochiaro's answer?
[11:26] <Kaleo> tsdgeos: wait a minute
[11:40] <greyback> MacSlow: ping
[11:41] <MacSlow> greyback, what's up?
[11:42] <greyback> MacSlow: just something small about the filter-compact stuff. I just want to check with you that it is the lens which chooses for checkboxes to be compact or not
[11:42] <MacSlow> greyback, yes
[11:42] <greyback> MacSlow: ok I thought so, thanks.
[11:42] <greyback> The Documents lens needs to have the "Last Modified" checkboxes as compact
[11:43] <greyback> I'll try to get that done
[11:43] <MacSlow> greyback, I only ever heard that the music-lens was the only one to use the compact / 3-column layout
[11:43] <greyback> MacSlow: that's all, thank you
[11:44] <MacSlow> greyback, but my last update on that is from the rally in Budapest... so
[11:44] <greyback> MacSlow: sure. I'm just comparing with mockups. We had a hack in Unity2D for this, and we applied it also for LastModified, hence I noticed.
[12:08] <Kaleo> tsdgeos: ok, the conclusion is that we need to revert 958 in -shell
[12:12] <tsdgeos> Kaleo: ok, want me to do that?
[12:13] <Kaleo> tsdgeos: sure
[12:13] <Kaleo> tsdgeos: so the issues are:
[12:13] <Kaleo> tsdgeos: the 1 pixel rectangle on the left
[12:13] <Kaleo> tsdgeos: the lack of shadow for the dash bottom right corner in composited mode
[12:14] <Kaleo> tsdgeos: a more proper solution is to check for composited/non composited mode in InputShapeManager
[12:14] <Kaleo> tsdgeos: and do ShapeInput or ShapeBounding depending on the case
[12:17] <tsdgeos> Kaleo: and r958 reversion
[12:22] <tsdgeos> Kaleo: about the 1 pixel rectangle on the left in non composited mode, i'm not sure it's worth fixing
[12:23] <tsdgeos> greyback is working on something xfixes based to detect the mouse "pushing" into the launcher
[12:23] <tsdgeos> so any work we do now on that will be "lost time"
[12:28] <Kaleo> tsdgeos: understood
[12:29] <tsdgeos> Kaleo: what about the maximize button on lower left part?
[12:29] <Kaleo> tsdgeos: I am taking care of it
[12:29] <tsdgeos> Kaleo: nice
[12:30] <Kaleo> tsdgeos: but first we are reverting 948 as well
[12:30] <Kaleo> tsdgeos: and fixing it properly
[12:30] <Kaleo> tsdgeos: would you like to implement what I described above?
[12:30] <Kaleo> tsdgeos: if so, do you need more details?
[12:30] <tsdgeos> Kaleo: you mean 958
[12:30] <Kaleo> tsdgeos: if so, mumble?
[12:30] <Kaleo> tsdgeos: right
[12:30] <Kaleo> tsdgeos: I mean, 958 and 948 are being reverted :)
[12:31] <tsdgeos> Kaleo: yeah i'm on that, i think i have understood all you meant, you'll have a MR in a moment
[12:31] <Kaleo> tsdgeos:  brillian
[12:31] <Kaleo> t
[12:31] <tsdgeos> Kaleo: why 948?
[12:31] <tsdgeos> ah, that's the maximize stuff
[12:31] <tsdgeos> ok
[12:31] <tsdgeos> you doing that
[12:31] <tsdgeos> and i'm doing 958
[12:31] <tsdgeos> confused for a second
[12:32] <Kaleo> tsdgeos: right :)
[12:32] <Kaleo> tsdgeos: numbers are confusing
[12:34] <tsdgeos> wops
[12:34] <tsdgeos> we broke isCompositingManagerRunningChanged when merging Saviq's stuff
[12:34] <tsdgeos> damnit
[12:35] <tsdgeos> actually no
[12:35] <tsdgeos> we didn't, was already broken :D
[12:35] <tsdgeos> we had the signal but was never emitted
[12:43] <tsdgeos> Kaleo: basically this https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_shape_bounding_shape_input/+merge/91815 ?
[13:20] <Kaleo> tsdgeos: yep, something like that :)
[13:20] <Kaleo> tsdgeos: I don't think Qt is able to tell us when a compositing manager started or stopped
[13:38] <tsdgeos> Kaleo: yeah looked for that and Qt doesn't have info for that
[13:48] <Kaleo> tsdgeos: quick question
[13:48] <tsdgeos> Kaleo: yep?
[13:49] <Kaleo> tsdgeos: with trunk, the maximise button in the panel when the dash is up, is it enabled for you?
[13:49] <Kaleo> tsdgeos: can you click it?
[13:49] <tsdgeos> Kaleo: non-shell, right?
[13:51] <tsdgeos> Kaleo: i can click it but somehow it does not maximize
[13:52] <Kaleo> tsdgeos: non shell
[13:52] <Kaleo> tsdgeos: erk
[13:52] <tsdgeos> Kaleo: actually no, it works
[13:52] <Kaleo> tsdgeos: ah?
[13:52] <tsdgeos> i was using a wrong combination
[13:52] <Kaleo> tsdgeos: ok
[13:52] <tsdgeos> yes, i can click it correctly
[13:54] <tsdgeos> Kaleo: doesn't work there
[13:54] <tsdgeos> ?
[13:54] <Kaleo> tsdgeos: nope :(
[13:54] <Kaleo> tsdgeos: I am trying to figure out what I am doing wrong
[13:55] <tsdgeos> Kaleo: do you have the formfactor set to desktop?
[13:55] <tsdgeos> do the buttons show or not show at all?
[13:55] <Kaleo> tsdgeos: they show, formFactor is desktop
[13:56] <tsdgeos> Kaleo: have you checked you are running the correct unity-2d-places and not the system autostarted one? that was the problem i had
[13:56] <Kaleo> tsdgeos: yep
[13:57] <mgedmin> wheee
[13:57] <Kaleo> tsdgeos: and I experience the issue with both trunk and the daily build
[13:57] <mgedmin> right-clicked on a launcher icon somehow that triggered the bug where the popup menu ignores all events
[13:57] <tsdgeos> Kaleo: weird
[13:58] <Kaleo> tsdgeos: right
[14:05] <Kaleo> tsdgeos: sorry, I had the wrong formFactor
[14:06] <tsdgeos> ok, better that than something else :-)
[14:18] <mgedmin> I think that was https://bugs.launchpad.net/ubuntu/+source/unity/+bug/919194
[14:23] <Debolaz> The new HUD stuff looks quite neat. Can I safely install the current Unity from PPA without it butching up the system in some way?
[14:49] <greyback> tsdgeos: hey, can you please try running the visual tests in the panel (for the new assets) - it fails on me.
[14:49] <tsdgeos> greyback: do they?
[14:49] <tsdgeos> i ran then
[14:49] <tsdgeos> failed and then fixed them
[14:49] <tsdgeos> greyback: which error do you get?
[14:50] <greyback> tsdgeos: hmm, fail on me  with: https://pastebin.canonical.com/59599/
[14:51] <tsdgeos> that's the first one, right?
[14:53] <greyback> only one actually
[14:53] <greyback> which is odd
[14:54] <tsdgeos> greyback: did you check that the buttons actaully showed? remember we have that bug (with the old code too) that buttons sometimes don't show
[14:55] <greyback> tsdgeos: I'm watching, they show
[14:55] <tsdgeos> runs fine here
[14:55] <tsdgeos> greyback: i'm wondering, can the color of the panel be changed? my captures include part of the background
[14:57] <greyback> tsdgeos: hmm, will look. Am digging now
[15:12] <Kaleo> tsdgeos: the maximise button at the bottom right is now removed; nerochiaro did a live review
[15:13] <tsdgeos> Kaleo: cool, pushed to the repo already? Are you approving my 1 line fix for the shape thing?
[15:13] <Kaleo> tsdgeos: I'm looking at it now
[15:20] <tsdgeos> Kaleo: i don't understand at all what you guys did with reverting r948, but looks wrong
[15:20] <tsdgeos> we have some code that says
[15:20] <tsdgeos> d->m_activeWindowIsDash = qstrcmp(name, "unity-2d-places") == 0;
[15:20] <tsdgeos> ?
[15:22] <tsdgeos> or you are doing new code that still needs to be merged?
[15:23] <Kaleo> tsdgeos: indeed, there is new code that will redo the same
[15:23] <Kaleo> tsdgeos: (but better)
[15:23] <tsdgeos> ah
[15:23] <tsdgeos> ok :-)
[15:27] <kklimonda> hmm, are there some known issues with running unity 5.2 under virtualbox? It doesn't seem to refresh itself
[15:29] <Kaleo> tsdgeos: hmm, the spread won't come up anymore
[15:29] <Kaleo> tsdgeos: it seems unrelated to your MR though
[15:29] <tsdgeos> Kaleo: doing what? pressing on the launcher button?
[15:30] <Kaleo> tsdgeos: yep and trying super+s too
[15:30] <tsdgeos> works here
[15:30] <Kaleo> tsdgeos: :)
[15:30] <Kaleo> tsdgeos: I'll try again
[15:32] <didrocks> greyback: hey :)
[15:32] <didrocks> greyback: I'll do a small unity-2d update today
[15:32] <didrocks> greyback: with "lock launcher" being the default
[15:32] <didrocks> let me look at the code, sholdn't be hard to change that :)
[15:33] <tsdgeos> Kaleo: though i can see a few problems with intellihide and spread
[15:33] <tsdgeos> :-/
[15:35] <Kaleo> tsdgeos: :(
[15:35] <tsdgeos> adding them to the sketchpad
[15:38] <tsdgeos> Kaleo: http://paste.kde.org/~tsdgeos/201404/ doesn't look good
[15:39] <greyback> didrocks: ok cool, let me know if you need a hand
[15:40] <Kaleo> tsdgeos: not cool
[15:41] <didrocks> greyback: I made a merge proposal, seems to only be the gsetting key to change
[15:41] <greyback> tsdgeos: you're missing some verification images, namely the *_over.png images
[15:41] <greyback> didrocks: ok cool
[15:41] <tsdgeos> greyback: what might very well be :D
[15:41] <greyback> didrocks: we're still missing the corner-reveal function. I'll poke you when it's ready
[15:42] <didrocks> greyback: well, right now, you are even with -3d on that :)
[15:42] <tsdgeos> greyback: they are there now
[15:42] <didrocks> greyback: but yeah please, poke me! :)
[15:42] <Kaleo> greyback: what's the corner reveal?
[15:42] <greyback> didrocks: will do
[15:42] <greyback> Kaleo: launcher reveals if cursor put in top left corner
[15:42] <greyback> we used to have it with the old homebutton in the panel I believe
[15:43] <greyback> tsdgeos: good now, thanks!
[15:44] <tsdgeos> sorry for forgetting :_/
[15:44] <greyback> no biggie
[15:46] <Kaleo> greyback: yes, but it was long dropped by design
[15:46] <Kaleo> greyback: is it something we care about now?
[15:46] <greyback> Kaleo: it's in the gnome-settings spec, so yes
[15:54] <sbte> I'm currently trying to fix memory leaks and other valgrind warnings to help make unity better, but I was wondering if I should submit the fixes one at a time, or all at the same time. And if so in separate commits or in one commit?
[15:55] <tsdgeos> Kaleo: r943 broke the connects, having a look why
[15:56] <gord> sbte, more commits make for a better revision history, generally it makes sense to have more submissions too, so if there is a problem with fix a, it does not block fix b from landing
[15:56] <sbte> gord, ok, thanks
[15:57] <gord> sbte, give me a ping if you have anything waiting, memory leak fixes are always good to get in :)
[15:57] <tsdgeos> Kaleo: or maybe not :D
[15:58] <sbte> gord, I'm submitting one now for bamf
[16:01] <gord> niice
[16:03] <sbte> gord, https://code.launchpad.net/~sbte/bamf/fix-memory-leak/+merge/91869
[16:03] <sbte> I'm still all new to this, so just tell me when I'm doing something wrong :P
[16:05] <gord> have assigned the relevant person, you should get spam from launchpad when they do the review :)
[16:06] <tsdgeos> actually it's r942 that broke it
[16:06] <sbte> gord, thanks
[16:07] <Kaleo> tsdgeos: ah ah
[16:08] <tsdgeos> Kaleo: don't see anything obviously wrong there at first glance, having a deeper look
[16:09] <Kaleo> tsdgeos: ok
[16:09] <Kaleo> tsdgeos: I approved the shpaing
[16:09] <Kaleo> shaping*
[16:09] <tsdgeos> Kaleo: oki
[16:19] <Kaleo> tsdgeos: let's catch up on mumble in 10 minutes
[16:19] <tsdgeos> Kaleo: ok
[16:29] <tsdgeos> Kaleo: this fixes those bad connects for me https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_fix_spread_connects/+merge/91872
[16:29] <tsdgeos> Kaleo: in mumble in a sec
[16:38] <Kaleo> tsdgeos: still there?
[16:38] <tsdgeos> Kaleo: doh
[16:38] <tsdgeos> i was speaking :D
[16:38] <tsdgeos> wait
[16:38] <tsdgeos> i started the launcher
[16:38] <tsdgeos> and thus it broke the shortcut
[16:42] <Kaleo> tsdgeos: one sec
[16:42] <tsdgeos> Kaleo: ok
[16:42] <Kaleo> unity-2d-spread: [WARNING] file:///home/kaleo/Projects/upicek/unity-2d//spread/Workspaces.qml:214: Error: Cannot assign [undefined] to int
[16:42] <Kaleo> unity-2d-spread: [WARNING] file:///home/kaleo/Projects/upicek/unity-2d//spread/Workspaces.qml:214: Error: Cannot assign [undefined] to int
[17:13] <tsdgeos> Kaleo: luckily the activeWindow thing is not used at all, so i just killed it from the QML
[17:13] <tsdgeos> Kaleo: tomorrow i'll tackle the other one
[17:26] <mhr3> greyback, anyone from 2d working on https://bugs.launchpad.net/unity/+bug/711199 ?
[17:26] <greyback> mhr3: not right now, no
[17:27] <mhr3> greyback, it's on its way to 5.4, so if you have a free slot.. :)
[17:28] <greyback> mhr3: you're welcome to try :)
[17:30] <mhr3> greyback, you made that sound like non-achievable task by mere mortals :P
[17:30] <mhr3> so i'll rather pass
[17:30] <greyback> mhr3: lol
[17:30] <greyback> excuses excuses
[17:30] <greyback> it's on the list, but we've plenty to do before FF
[17:30] <mhr3> yea, i can imagine
[17:31] <mhall119> some nice UX/DX praise here for you guys: http://www.itworld.com/it-managementstrategy/247574/will-unity-win-battle-linux-desktop
[17:32] <mhall119> well-deserved too, I might add
[17:42] <seb128> didrocks, can we get https://bugs.launchpad.net/bugs/916879 on a blocker list?
[17:42] <didrocks> seb128: yep, adding, thanks!
[17:43] <seb128> if it's not yet, it's quite busy in comments and duplicates
[17:43] <seb128> didrocks, thanks
[17:54] <seb128> DBO, ^ could you look at this bug? switcher suggests your code ;-)
[17:54] <DBO> looking
[17:54] <seb128> DBO, thanks
[18:45] <majsterkoo> Hi, I have one question... Why Ubuntu (Unity) dev team don´t integrate utility to easy change Unity theme?
[18:51] <lucas_> Hi, "Not getting an answer? Post on the https://launchpad.net/~ayatana-dev mailing list"    this link is broken. Where can I find the current unity-dev mailing list?
[18:53] <lucas_> ok, found it.
[19:11] <vanRijn> re, all
[19:14] <vanRijn> are there programmatic ways to disable Unity (the left hand side launcher, the menu relocation to the top of the screen, and the titlebar going away when the window is maximized)? If we're in Ubuntu Unity 3D DE, there's a CCSM checkbox that turns these things off, but I can't find where the back end value for that is actually stored.
[19:14] <vanRijn> and if we're in Ubuntu Unity 2D DE, I don't see any way of disabling these things
[19:17] <vanRijn> anyone?
[19:18] <vanRijn> also, the ayatana-dev mailing list URL in the /topic is broken
[19:19] <greyback> vanRijn: using unity2d, you'll need to replace the ubuntu-2d.session file with something that you want.
[19:19] <greyback> it is there that the panel & launcher are defined to be required for login
[19:19] <vanRijn> greyback: is there a way to disable it temporarily and turn it back on?
[19:20] <greyback> vanRijn: well, you can kill the panel & launcher, they're apps
[19:20] <greyback> gnome-session will restart them, but that can be stopped by looking to their .desktop files
[19:21] <greyback> or just kill it, wait for restart, then kill again. gnome-session gets the message then
[19:21] <vanRijn> greyback: I'm guessing the best way to talk about this would be to email a dev list somewhere (could you point me to which one I should use please?), but I'm working for VMware and we'd like our VMware Unity mode (where we show VM windows as discrete host windows instead of just showing the entire VM desktop) to play nicely with Ubuntu Unity and there's some challenges we're not sure how to
[19:21] <vanRijn>  approach
[19:21] <vanRijn> greyback: oh, gnome-session won't try to restart things if you kill them more than once?
[19:22] <greyback> vanRijn: yep :)
[19:22] <greyback> but not a great solution for you
[19:22] <vanRijn> yeah, not really
[19:23] <vanRijn> greyback: is there an official ubuntu-dev mailing list somewhere that I should bring this up on?
[19:24] <greyback> vanRijn<EMAIL_ADDRESS>should be good place
[19:25] <vanRijn> greyback: okay, thanks. I can't seem to get launchpad to let me even go to the unity-dev page. grr
[19:26] <vanRijn> it should be http://lists.launchpad.net/ayatana-dev shouldn't it?
[19:26] <vanRijn> er.. unity-dev.. but I can't get to ayatana-dev either
[19:26] <vanRijn> ooh, there we go. *sigh*
[19:27] <greyback> ?
[19:28] <vanRijn> http://lists.launchpad.net/ayatana-dev doesn't work at all (nor does https://launchpad.net/~ayatana-dev for me), but http://lists.launchpad.net/unity-dev does
[19:29] <greyback> ah ok
[19:29] <greyback> good luck!
[19:29] <vanRijn> thanks. =:)
[19:31] <krnekhelesh> hi, i have a question
[19:31] <krnekhelesh> do you guys get a 1.5 sec lag when you use alt-tab?
[19:32] <krnekhelesh> there is a bug report regarding this at https://bugs.launchpad.net/unity/+bug/928339
[19:32] <krnekhelesh> would appreciate if you can confirm this?
[19:36] <krnekhelesh> anybody?
[19:54] <JanC> krnekhelesh: not sure you are seeing the same as I do, but I commented on the bug...
[19:54] <JanC> (I should set up one of my systems with "precise" really..
[19:56] <JanC> krnekhelesh: does the 1.5 sec happen always, or only after some time?
[20:01] <krnekhelesh> JanC, I am not having the trouble, the original reporter does
[20:02] <JanC> krnekhelesh: hm, okay, I'll ask that question in the bug report then...
[20:02] <krnekhelesh> JanC, i just read your comment
[20:02] <krnekhelesh> and I haven't noticed the lag, although I will now try to see if that happens when I leave my computer on for a long time
[20:03] <JanC> my desktop tends to be "up" for weeks
[20:03] <krnekhelesh> oh, wow!
[20:04] <JanC> actually, I have to reboot or login/logout more often than I really want because of this sort of issues...
[20:05] <krnekhelesh> anyways, i have marked the bug as incomplete so he should reply back
[20:05] <krnekhelesh> JanC, then the issue u face, isn't a bug to be addressed by the unity team?
[20:05] <JanC> somehow, I wish Compiz would revert back to the old C codebase, as it was way more stable than the new C++ codebase...
[20:06] <JanC> OTOH, the C++ might be easier to extend/maintain, duno
[20:06] <krnekhelesh> oh yeah, I hate compiz  because of its instability
[20:07] <JanC> I never liked C++, but I won't argue against it for a project I don't contribute to  ;)
[20:07] <krnekhelesh> true
[20:08] <krnekhelesh> i really like how Precise is coming along...small minor things getting fixed, the attention to detail
[20:08] <krnekhelesh> Unity is also really stable
[20:08] <krnekhelesh> I am actually using 12.04 as my production pc at the moment.
[20:11] <JanC> krnekhelesh: seems like the reporter mentions this is new to unity 5.2 though
[20:25] <krnekhelesh> JanC, i will test it
[20:25] <krnekhelesh> i have not noticed anything yet until now
[20:58] <mhall119> thumper: ping
[21:06] <bschaefer> mhr3, hey, thanks for reviewing my branch. I have a question about your last comment, about how the lens might take time to update
[21:07] <bschaefer> mhr3, so when it might be taking time to get results will it be returning 0 to OnSearchFinished even when it is still searching?
[21:12] <mhr3> bschaefer, no, searchfinished will only fire once the search finishes
[21:12] <mhr3> but that might be between 1microsecond and infinity :P
[21:13] <bschaefer> mhr3, hmm, so I can only think that the message will display if you say delete the entire search string and it is waiting for the results to update
[21:13] <mhr3> yes, that would be one way to trigger that
[21:13] <bschaefer> mhr3, the musicstore scope updates a little slow and the message doesn't get displayed until there no results get returned
[21:14] <mhr3> bschaefer, the problem is when the message is already displayed and you start new search
[21:14] <bschaefer> mhr3, aaaa I see haha
[21:15] <bschaefer> mhr3, that is slightly annoying, thanks for the suggestions Ill have to look into that now
[21:15] <mhr3> bschaefer, making it perfect requires sometimes "interesting" solutions :)
[21:16] <mhr3> another thing that can happen is that when there's a misbehaving lens the searchfinished will never get emitted
[21:17] <bschaefer> mhr3, yeah, perfection always seems to grow at an exponential rate!
[21:17] <mhr3> so it can still happen that the dash won't display anything... but there's not much we can about that
[21:17] <bschaefer> mhr3, hmm that could be a problem, yeah...
[21:17] <mhr3> we actually shouldn't, that will kick the devs to fix the lens :)
[21:18] <bschaefer> mhr3, haha! Yeah, but being safe is never bad :) (if you can be)
[21:18] <mhr3> sure
[21:18] <mhr3> that why i want the timer at least
[21:18] <bschaefer> mhr3, but I don't see a simple solution for a signal not getting fired. Yeah Ill start looking into how that works,
[21:18] <mhr3> search taking long is pretty real issue as opposed to misbehaving lenses
[21:19] <mhr3> bschaefer, as i said, you need to fire a timer when the search starts and if the message is shown and the timer gets called just hide the message
[21:20] <mhr3> that way it shouldn't cause flicker and should work fine
[21:20] <bschaefer> mhr3, alright, sounds simple :)
[21:20] <bschaefer> and fun to do
[21:20] <mhr3> timers are never simple :P
[21:21] <mhr3> they create quite a lot of new code paths
[21:21] <bschaefer> mhr3, similar to a goto it seems!
[21:22] <mhr3> i'd say that goto is still more predictable and obvious
[21:22] <bschaefer> mhr3, haha yeah, well hopefully it fits in well with the existing code :)
[21:31] <nhaines> So are we disabling autohide by default in 12.04?


[15:38] <qwebirc6785> ?
[15:39] <qwebirc6785> What is going on here now?
[15:39] <pleia2> we don't have any classes scheduled at this time
[23:03] <pietrubens> hello?
[23:05] <jarlen> hello pietrubens
[23:05] <jarlen> there is no classroom sessions now
[23:06] <pietrubens> what does the classroom teach?
[23:07] <pietrubens> is this a place to throw problems and questions regarding ununtu, or is this more an organized teaching session?
[23:07] <jarlen> everything ubunturelated that people want to teach others
[23:07] <nhandler> pietrubens: #ubuntu is the Ubuntu support channel
[23:07] <jarlen> this is organized teaching sessions
[23:11] <nalioth> ya know, we used to help folks in here when classes weren't using it
[23:12] <nalioth> #ubuntu is too busy, so this channel would be used to bring folks and help them in a slower place
[23:13] <jarlen> Ok, I didn't know that, actually
[23:13] <jarlen> why not just use private messages, or similar?
[23:17] <nalioth> because YOU don't know everything
[23:18] <nalioth> YOU also don't have a support bot
[23:18] <nalioth> YOU = any single person on the other end of a PM


[00:59] <bkerensa> slangasek: Would iputils have some reason for lacking manpages?
[02:13] <slangasek> bkerensa: packages may lack manpages for many reasons :)
[02:27] <slangasek> bkerensa: but I don't see what you mean here; iputils-ping has manpages, as does iputils-tracepath
[04:59] <pitti> Good morning
[05:20] <bkerensa> slangasek: <blkperl> [03:38:01] where did steve go. (in loco channel)
[05:58] <hyperair> bug #930938 ← i can has sponsor please?
[06:01] <RAOF> @pilot in
[06:02] <RAOF> Huh, not final freeze yet?  This piloting session is going to be more interesting than I thought :)
[06:22] <pitti> ev: did you see the whoopsie FTBFS due to test failure on arm?
[06:57] <dholbach> good morning
[07:03] <RAOF> hyperair: Did you test that debdiff?  Is the infinite-scrolling that I see *really* the behaviour you want? :)
[07:03] <hyperair> RAOF: yes i did. what infinite scrolling?
[07:03] <hyperair> RAOF: or do you have CoastingFriction set to 0 by any chance?
[07:04] <RAOF> I've got whatever are the defaults; presumably that includes CoastingFriction set to 0
[07:04] <hyperair> can you do synclient -l | grep CoastingFriction?
[07:04] <hyperair> it should be 50 by default
[07:04] <RAOF> 50, apparently.
[07:05] <hyperair> hmmm
[07:05] <hyperair> lemme check
[07:05] <RAOF> Yet if I do a 2 finger scroll in evolution it never stops.
[07:05] <hyperair> hmmmmm yeah you're right
[07:05] <hyperair> it doesn't stop in evince either
[07:05] <RAOF> (And also carries over if I do alt-tab, which is stupidly wrong behaviour that's stupid and wrong and is why this needs to be in gtk)
[07:05] <hyperair> =(
[07:05] <hyperair> it's in gtk.
[07:05] <hyperair> partilaly
[07:05] <hyperair> partially*
[07:06] <hyperair> for some reason the kinetic scrolling doesn't kick in
[07:06] <hyperair> i checked via gdb
[07:09] <hyperair> RAOF: do you get infinite scrolling without the patch? (very slow infinite scrolling, if you do a really fast flick)
[07:10] <RAOF> No.  I get a couple of ticks of extra scroll, and then it stops.
[07:11] <hyperair> hmm
[07:11] <hyperair> oaky
[07:11] <hyperair> i guess we can't include this patch then
[07:12] <RAOF> Yeah, I'll nak it.
[07:13] <RAOF> Although if you find that there's a follow-up patch or two which actually implements sane behaviour, we could still get that in :)
[07:14] <hyperair> sure
[07:18] <RAOF> Oh, man, that behaviour is terribly annoying.
[07:58] <hyperair> RAOF: okay, it looks like priv->scroll.coast_speed_y is getting set to an absurdly high value. it's not that it scrolls forever, it just takes forever to stop.
[08:00] <hyperair> RAOF: but you can stop scrolling by touching the touchpad, so it's not like it's not easily worked around
[08:01] <RAOF> Right, but that's not exactly the most elegant default behaviour.
[08:04] <hyperair> RAOF: it's a good stopgap that removes the regression from oneiric until gtk gets proper kinetic scrolling
[08:05] <RAOF> Urrr...
[08:05] <hyperair> er, i really meant the fixed patch
[08:05] <hyperair> which i'm working on now
[08:05] <hyperair> i think i've naild this
[08:05] <hyperair> nailed*
[08:05] <RAOF> :)
[08:05] <RAOF> Ah, ok.
[08:05] <RAOF> That makes more sense.
[08:06] <hyperair> :)
[08:06] <hyperair> should i merge this into the patch, or make this a separate patch?
[08:06] <RAOF> You probably want to make a separate patch, because you'll be sending it upstream, right?
[08:06] <RAOF> :)
[08:07] <RAOF> And the initial patch you've added is a cherry-pick from upstream.
[08:12] <mpt> bkerensa, I made two suggestions in the bug report: "Landscape" or "Landscape Administration". I didn't include "Service" because three words ("Landscape Management Service") would wrap to three lines, making the window taller, and because "Service" doesn't add any meaning.
[08:14] <bkerensa> mpt: ok I will fix my merge proposal and resubmit then should I ping you for review or just let sponsors handle?
[08:14] <hyperair> RAOF: it's not a cherry-pick actually, it's not committed yet
[08:15] <mpt> bkerensa, I guess my review wouldn't hurt, and it would take all of ten seconds :-)
[08:19] <bkerensa> mpt: https://code.launchpad.net/~bkerensa/ubuntu/precise/landscape-client/fix-for-962974/+merge/101839
[08:20] <bkerensa> mpt: diff preview is still updating but only change was from Landscape Management Service to Landscape Administration
[08:20] <mpt> bkerensa, reviewed, thanks :-)
[08:20] <bkerensa> k
[08:22] <hyperair> has anyone noticed that killall doesn't function with long process names any more?
[08:24] <jamespage> @pilot in
[08:25] <hyperair> RAOF: okay, it works. and i've uploaded the fixed patch.
[08:25] <hyperair> bug #930938
[08:26] <bkerensa> mpt: I dont think we will get a exception for the merge though
[08:32] <RAOF> hyperair: whot's said that he's committed it :)
[08:39] <jamespage> RAOF, any specific areas you are focussing on from the sponsorship report this morning?
[08:40] <RAOF> jamespage: I was looking at the top of the queue and picking off things which looked reasonable, but mostly I've been testing hyperair's synaptics patch.
[08:41] <jamespage> RAOF, OK - just wanted to make sure I was not looking at the same stuff as you
[08:42] <RAOF> I'm looking at 805509 and 930938
[08:42] <RAOF> And then it'll probably be time to stop :)
[08:44] <ev> pitti: yes - jumping on a porter box and digging at it is on my list for today :)
[08:44] <ev> re whoopsie arm failure
[08:44] <jamespage> RAOF, guess as final freeze was yesterday we need to limit sponsoring to high priority + for main and universe>
[08:45] <RAOF> I'm clearly timezone deficient; I haven't seen final freeze annoncement.
[08:45] <jamespage> hmm
[09:06] <pitti> well, the topic says "Archive: frozen"
[09:07] <pitti> but if that's too confusing, lets change it
[09:45] <brendand> does anyone know what the gconf key is to prevent the screen from turning off?
[09:45] <dupondje> jibel: care fixing https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? :) i'm updating my 'devbox' and got this bug ...
[09:45] <dupondje> if you need some debugging :)
[09:46] <Whoopie> jamespage: do you have time to discuss bug 898003? The new package is to avoid a regression in precise.
[09:47] <jamespage> Whoopie, lemme just read the bug report
[09:47] <Whoopie> jamespage: sure, thanks
[09:48] <Whoopie> jamespage: I didn't attach a debdiff as it's 2 MB because the whole folder structure has changed in version 1.1.1.
[09:49] <brendand> or is it gsettings now?
[10:00] <jamespage> Whoopie, not sure I understand why you have dropped usbip-source - is the kernel module no longer required?
[10:01] <Whoopie> jamespage: it's in kernel staging and enabled since 3.2.0-22.35 in the ubuntu kernel.
[10:01] <jamespage> Whoopie, right - I think I understand then
[10:03] <jamespage> Whoopie, I think that overall the approach you have taken looks sensible
[10:03] <jamespage> Whoopie, questions:
[10:03] <jamespage> 1) have you discussed this with the debian maintainer of this package?
[10:03] <Whoopie> no
[10:06] <Whoopie> jamespage: have to jump to a meeting, but will be back in 1 hour. If you have further questions, I'll try to answer them all later.
[10:06] <Whoopie> BTW, I'll contact the debain maintainer.
[10:06] <jamespage> Whoopie, I'll stick some feedback in the bug report
[10:06] <Whoopie> jamespage: great, thanks.
[10:07] <Whoopie> jamespage: but if it's not possible to get it into debian and then sync the package, could it be added to precise?
[10:07] <jamespage> Whoopie, I think so but we should try to get some agreement on approach from the DM
[10:07] <Whoopie> ok
[10:08] <RAOF> @pilot out
[10:08] <tumbleweed> considering that Debian and Ubuntu ship different kernel versions, there's a fair chance that that package couldn't stay in sync
[10:08] <tumbleweed> but yes, talking to the debian maintainer is always a good idea :)
[10:08] <jamespage> Whoopie, you have pretty much change most of the packaging - we would normally try to keep the ubuntu delta to a minimum
[10:08] <dupondje> is there a way to get more debug info from do-release-update ? :)
[10:09] <tumbleweed> apt logs?
[10:09] <jamespage> tumbleweed, agreed - but it should be a temp delta not a permanent fork so discussing with DM is important in this case
[10:10] <tumbleweed> jamespage: yeah. Or at least the same approach+packaging, but maybe different upstream versions.
[10:10] <dupondje> nothing usefull in it :( trying to debug why I get "E:Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle."
[10:10] <jamespage> tumbleweed, yes - that would make sens
[10:10] <jamespage> e
[10:11] <hyperair> RAOF: really? i don't see it in the upstream git tree
[10:11] <RAOF> hyperair: Yeah, neither do I, actually.
[10:11] <hyperair> git a commit hash?
[10:12] <hyperair> *got
[10:13] <RAOF> No; I just read whot's post on xorg-devel.
[10:14] <RAOF> Anyway, it's now pushed to precise-proposed.
[10:15] <hyperair> okay, thanks
[10:18] <dupondje> slangasek: could you check https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? Could be caused by some change you did.
[10:23] <shnatsel> pitti: hello! I have a question about https://launchpad.net/~apport. I'm deploying Apport in elementary Project, and it seems we need the same retracing bot; so I have two questions: first, where to find the sources for the bot so we can set it up for our projects, and second, how to make Apport subscribe our bot to the reports instead of ~apport?
[10:24] <tjaalton> chrisccoulson: hey, do you have time updating enigmail to 1.4.1? it fixes bug 968122
[10:24] <chrisccoulson> tjaalton, it will be updated with the regular 6 week releases (ie, with Thunderbird 12)
[10:25] <pitti> shnatsel: the retracer bot in our DC has no additional code, it just runs straight out of lp:apport
[10:25] <pitti> shnatsel: you need to supply it with a couple of config dirs, though
[10:25] <pitti> shnatsel: http://paste.ubuntu.com/927711/ is the crontab which regularly invokes crash-digger for i386 and amd64 and dup checking
[10:26] <tjaalton> chrisccoulson: ah, ok
[10:26] <pitti> shnatsel: it's a bit more difficult there as this is a lucid box and we do that in a porter dchroot (which has python-launchpadlib and the other necessary pacakges installed)
[10:26] <pitti> shnatsel: as for the "apport" subscription, that's currently hardcoded in apport/crashdb_impl/launchpad.py like 174
[10:26] <pitti> shnatsel: err, "line 174"
[10:27] <pitti> shnatsel: please feel free to open a bug to make this a config option in /etc/apport/crashdb.py
[10:27] <pitti> shnatsel: line 178, too
[10:27] <shnatsel> pitti: thanks a lot!
[10:27] <shnatsel> I take it nobody ever used a custom Apport bot then? :)
[10:28] <pitti> shnatsel: either that, or they just changed that locally and didn't tell me :) I wasn't really aware of that hardcoding
[10:28] <shnatsel> pitti: one more question. Where can I find samples of those config dirs or documentation on writing them?
[10:29] <shnatsel> those config dirs include bug patters, I presume?
[10:29] <pitti> shnatsel: it's described in "man apport-retrace"
[10:29] <shnatsel> pitti: thanks! Will dig :)
[10:29] <pitti> shadeslayer: no, this is just the config for the apt sources for the sandboxes
[10:30] <pitti> shnatsel: http://paste.ubuntu.com/927719/
[10:30] <pitti> shnatsel: those are two configs from our bot
[10:30] <pitti> shnatsel: they really all look alike
[10:31] <pitti> shnatsel: the only oddity is that we include ddeb apt sources for previous releases, due to the really hackish way ddebs.u.c. works
[10:31] <pitti> (long story, just do it :) )
[10:31] <shnatsel> okay! xD
[10:32] <maxb> Do the amd64 buildds run multiarch-enabled for oneiric and precise?  (Because debootstrap sets up a new chroot that way, which surprised me)
[10:32] <shnatsel> pitti: thanks a lot! I'll report back if when deploy it (or fail to)
[10:33] <pitti> shnatsel: I suggest you check out lp:apport, then create a config dir for a release you are intersted in, and start with manually calling apport-retrace and see how that goes
[10:33] <pitti> shnatsel: once that works, you can use crash-digger to iterate over all pending bugs
[11:16] <dupondje> bleh, to bad upgrade from oneiric still fails :(
[11:41] <shnatsel> one more question: are *-dbgsym packages at ddebs.ubuntu.com the same as -dbg packages in main archive, or that's something different?
[11:42] <cjwatson> they are different
[11:42] <cjwatson> *-dbgsym: automatically stripped debugging symbols
[11:42] <cjwatson> *-dbg: may be debugging symbols in some cases, but can also be entirely separate debugging builds (e.g. python2.7-dbg)
[11:44] <shnatsel> cjwatson: thanks! So if I make a package with automatically stripped debugging symbols in a somewhat main archive (PPA), shall I call it -dbg or -dbgsym? Also, is it OK for Apport to have only -dbg and not -dbgsym?
[11:44] <shnatsel> for apport-retrace I mean
[11:44] <cjwatson> I don't know the answer to your apport question
[11:45] <dupondje> somebody wants to look at https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? :)
[11:45] <dupondje> quite annoying, as it blocks my upgrade :(
[11:45] <cjwatson> If you generate a package in your own packaging rules, it should be -dbg; -dbgsym should only be generated by pkg-create-dbgsym
[11:46] <shnatsel> cjwatson: thanks a lot!
[11:46] <shnatsel> pitti: one more question: is it OK for Apport to have only -dbg packages and not -dbgsym?
[11:46] <pitti> shnatsel: you won't get very good results
[11:46] <broder> pitti: are you ok with me cherry picking http://cgit.freedesktop.org/upower/commit/?id=6fb36eb5eb85386d2e1c5d9fb760d68053d8afc5 onto upower? (i'm open to doing it as an sru if that's preferable)
[11:47] <pitti> shnatsel: i. e. for packages which don't have a -dbg, you won't get any symbols, and most likely also stack traces which fail in the middle because of missing symbols, etc.
[11:47] <pitti> broder: I'd rather apply it to Debian, too, to avoid getting out of sync
[11:48] <broder> pitti: ok. that would be awesome if you could - i got bitten by the broken behavior a couple of times in the last week before finally hunting down the bug
[11:49] <pitti> broder: is there a bug # for it? at this point we should have them for release tracking
[11:49] <broder> would a bts bug as a reminder be easiest?
[11:49] <broder> no, i haven't done anything yet
[11:49] <broder> i'll open an lp bug
[11:49] <pitti> just curious that there is no existing bug at all about it
[11:49] <pitti> it mighth be against gnome-power-manager, or a different package
[11:49] <broder> err, there might be. i didn't look - i just figured out what was going wrong
[11:50] <broder> there are a handful of moving parts that lead to the brokenness
[11:50] <dupondje> slangasek: around ?
[11:50] <shnatsel> pitti: I take it Ubuntu ddeb archive has -dbgsym for all packages, so to use -dbg instead I'll have to make sure all my custom packages have -dbg, otherwise retracing will fail?
[11:51] <broder> pitti: i kind of suspect that any bug that starts with "my laptop doesn't suspend when i close the lid" immediately gets shuffled off to die in kernel purgatory
[11:53] <pitti> shnatsel: don't you base your project on top of an ubuntu release?
[11:54] <pitti> shnatsel: if you don't, you need to ensure to build -dbg packages for teh things you care about, yes
[11:54] <shnatsel> Pici: well, we do... but we need newer libs than are present in Ubuntu sometimes
[11:54] <shnatsel> Pici: sorry
[11:54] <shnatsel> pitti: ^
[11:56] <broder> pitti: bug #980746
[12:01] <shnatsel> reported making apport bot name configurable as bug #980726
[12:02] <broder> pitti: thanks for taking a look. i need to go to sleep, but let me know if i can help and i'll look at it tomorrow
[12:02] <pitti> broder: bug 948485 ?
[12:03] <broder> hmm, yeah, sounds like the same bug, though it's hard to tell for sure with the given information. i'll post a followup comment and find out
[12:04] <infinity> shnatsel: For your custom packages, there's nothing stopping you from also doing dbgsym extraction (ie: by building with pkg-create-dbgsyms installed)
[12:05] <pitti> broder: hm, that bug could also be a dupe of bug 682262
[12:06] <broder> moral of the story: docking stations are evil
[12:06] <pitti> broder: anyway, I'll cherry-pick it, unless you want do do a debdiff, etc.
[12:06] <pitti> broder: no, they are awesome!
[12:06] <broder> only when they work :)
[12:07] <broder> i don't need to get credit for the upload. whichever is easier and fastest for you to deal with
[12:08] <pitti> broder: ok, I'll just thank you in the changelog then?
[12:08] <broder> pitti: works for me
[12:09] <shnatsel> infinity: will that allow building normal -dbg packages, etc etc? Since we use PPAs as our only repositories we [probably] can't set something as a dependency for all packages, and I have an automated script to enable -dbg packages anyway, so I'd rather patch packaging to enable -dbg than -dbgsym
[12:09] <infinity> broder: Oh, hey.    What's the name of your lintian host again?
[12:09] <pitti> shnatsel: no, -dbg must be done manually in the packaging
[12:09] <broder> infinity: odo.tribbl.es
[12:10] <pitti> shnatsel: that's why I wrote pkg-create-dbgsym, so that we don't have to modify packages
[12:10] <pitti> shnatsel: i. e. to build -dbgsym packages for all packages
[12:10] <pitti> shnatsel: you could do a hack and e. g. upload a debhelper version to your PPA which depends on pkg-create-dbgsym
[12:10] <pitti> shnatsel: ah, no, scratch that; I don't think PPAs have support for ddebs
[12:11] <pitti> shnatsel: we have a rather hideous hack to publish them for the normal ubuntu archive, but that's not available for PPAs
[12:11] <infinity> pitti: I thought the PPA ddeb support was added a while back for OEM?
[12:12] <dupondje> ia32-libs-multiarch is uninstallable ?
[12:12] <pitti> is it? so much the better; but they have magic PPAs
[12:12] <infinity> Oh, yeah, it might not be on for all PPAs.
[12:12] <pitti> shnatsel: I guess you could just try it with one package and see what happens
[12:12] <pitti> if LP accepts them, you could at least grab the .ddebs from the LP page
[12:12] <pitti> I doubt they will be published to the PPA archive, though
[12:13] <shnatsel> pitti: thanks, I'll keep that in mind if I ever need -dbgsym. I wrote an automated script that enables -dbg packages in packaging, so we can live without -dbgsym for now :)
[12:13] <pitti> shnatsel: it's mostly adding the -dbg package to debian/control and telling dh_strip about it in debian/rules, so it's indeed not hard
[12:14] <pitti> shnatsel: if it's only for 5 or so packages, that's definitively easier than trying to write something around LP to get a ddeb archive
[12:14] <shnatsel> pitti: yes, exactly. It's very simple: http://bazaar.launchpad.net/~elementary-os/elementaryos/packaging-scripts/view/head:/simple-case-add-dbg-package
[12:15] <pitti> hah
[12:20] <shnatsel> By the way, regarding magic PPAs - I hear there are some PPAs which can build ARM packages; elementary has an ARM strategy, is there any way they could get access to one? Not now, but someday in the future - we'll probably use custom build farm and repos for testing since those PPAs are non-virtualized or something like that...
[12:20] <seb128> shnatsel, pitti: launchpad got dbgsym support in some way for ppas, dx-system mentioned it and didrocks said it got enabled for the unity ppa (though that's a non virtual ppa, not sure if that's specific to those)
[12:23] <infinity> shnatsel: We still only offer ARM PPAs to Canonical employees and specific partners we have contracts with (entirely because they're insecure).  We're working on making them more widely available with virtualized builders, but it's not quite there yet.
[12:24] <shnatsel> infinity: thanks! Hopefully they will be public by the time elementary needs them :)
[12:24] <infinity> shnatsel: No idea is that'll be true.
[12:25] <shnatsel> well, then we'll need a contract with Canonical :)
[12:25] <shnatsel> never mind, and thanks for all the info
[12:26] <jamespage> @pilot out
[13:04] <dobey> Riddell, ScottK: either of you ever hit any instance of bug #334757 before? It's a 3.5 year old bug, and seems to be popping up a lot more with ubuntuone-control-panel and ubuntu-sso-client-qt using pyqt :-/
[13:05] <ScottK> dobey: Not that I recall.  We should move that the python-qt4 in any case then.
[13:07] <dobey> ScottK: there's a bug against ubuntu-sso-client with the same crash, which has enough duplicates it's starting to cause lp to timeout occasionally :(
[13:08] <ScottK> dobey: I see there's a reduced test cae in the bug.
[13:08] <ScottK> case
[13:08] <ScottK> dobey: Are you subscribed to the upstream PyQt mailing list?
[13:09] <dobey> yeah, alecu just posted that after looking into the bug against ubuntu-sso-client
[13:09] <dobey> i am not
[13:21] <mterry> @pilot in
[14:03] <jdstrand> kees, cjwatson: hmm. I just noticied this: /dev/tty[1-6] went from root:root 0600 to root:tty 0660 between oneiric and precise. I think it is because of util-linux commit 3aa6b68f7e19fa3e1c2bba75bee921a98b7b46af
[14:03] <jdstrand> kees, cjwatson: and I'm trying to decide if that is a problem
[14:03] <jdstrand> thoughts?
[14:04] <infinity> jdstrand: They were root:root at some point?
[14:04] <jdstrand> infinity: yes, in oneiric
[14:04] <infinity> And only oneiric?
[14:05] <jdstrand> oneiric and ealier
[14:05] <infinity> That's patently untrue.
[14:05] <jdstrand> well, let me check
[14:05] <infinity> Says the man looking at a bunch of root:tty TTYs on lucid.
[14:05] <jdstrand> it is certainly true on lucid
[14:05] <jdstrand> note I said [1-6]
[14:06] <infinity> Oh, just the VCs.
[14:06] <infinity> Check.
[14:06] <infinity> I'm not sure I see that as a problem.
[14:06] <infinity> But maybe I'm not sure why they didn't have tty access before. :P
[14:07] <jdstrand> yes, it was root:root going all the way back to hardy
[14:08] <jdstrand> I'm not sure it is a problem either, hence the question :)
[14:18] <jdstrand> kees, cjwatson: fyi, I filed bug 980835 so it doesn't get lost
[14:25] <infinity> jdstrand: It goes 600 as soon as you log in anyway.
[14:25] <infinity> jdstrand: So the tty group only has access to unallocated TTYs, which seems reasonable.
[14:28] <jdstrand> re 0600> yes. that is why I wasn't sure I cared. I still find it odd that the change was made
[14:28] <jdstrand> it has something to do with suse wanting to port mingetty stuff to util-linux
[14:29] <jdstrand> but mingetty doesn't do this (at least not on 11.10)
[14:30] <infinity> Also, the bit you hilighted has not much to do with it.
[14:31] <infinity> jdstrand: Note that, until you run a getty, all TTYs are root:tty.  For some reason, agetty used to change them to root:root, and now doesn't.
[14:31] <infinity> And man, launchpad needs better options for pasting code.
[14:31] <jdstrand> infinity: that is a good point
[14:33] <jdstrand> mingetty doesn't do it on precise
[14:33] <infinity> Doesn't change perms?
[14:33] <jdstrand> yes
[14:33] <jdstrand> if I chown and chmod it to root:root 0600 then fire it up, it is unchanged
[14:34] <jdstrand> I think I don't care based on your observation of the other ttys
[14:34] <jdstrand> actually, the other ttys are 0620 (like the udev rule says)
[14:34] <jdstrand> hmm
[14:36] <infinity> Right, the code you hilighted is making them 660.
[14:36] <infinity> The code I hilighted (or the removal) is making them remain root:tty.
[14:37] <infinity> If there's a valid argument for the udev rule being 620, we could make util-linux mirror that.
[14:37] <jdstrand> I would tend to agree
[14:43] <jdstrand> it was changed to 0620 in udev (from 0666) back in 2007
[14:44] <jdstrand> debian bug 244751 discusses this outside of udev (from 2004)
[14:44] <jdstrand> (when they had 0666)
[14:57] <lamont> so after the "zomg something bad happened" poppup steals focus and I hit return and lose it, how do I see why it popped up?
[14:58] <lamont> seb128: I blame you everytime somethinge steals focus at a bad moment.  just sayin'. :D
[14:58] <davmor2> lamont: /var/crash/ maybe?
[14:59] <lamont> davmor2: ta
[14:59] <lamont> /var/crash/_usr_lib_indicator-messages_indicator-messages-service.2501.crash
[15:00] <lamont>  Segfault happened at: 0x6117c0 <dirname>:      add    %al,(%rax)
[15:03] <lamont> turns out that the indicator-messages-service hates passwd entries in nssdb
[15:08] <slangasek> dupondje: hey there
[15:08] <dupondje> hi :)
[15:09] <seb128> lamont, seems like worth reporting ;-)
[15:10] <lamont> yeah - working through that little bit of pain now
[15:10] <lamont> fortunately, it died again for me, so I have a nice user experience
[15:11] <dupondje> was able to upgrade my system manually now, but maby its good to have that bug fixed
[15:16] <slangasek> dupondje: hmm, context?
[15:22] <dupondje> slangasek: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709
[15:28] <mterry> @pilot out
[15:30] <bdmurray> Is there some archive admin who could approve my update-manager in oneiric proposed?
[15:37] <ScottK> Did the SRU team approve it already?
[15:41]  * dholbach hugs mterry
[15:41] <barry> mvo: ping
[15:43] <barry> slangasek: can you approve foundations-q-python-version blueprint?
[15:43] <mterry> :)
[16:04] <pitti> barry: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-version does not exist
[16:05] <barry> pitti: oops, typo: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-versions
[16:05] <barry> (plural at the end)
[16:06] <pitti> barry: for 12.10!
[16:06] <pitti> barry: accepted for sprint and q
[16:06] <barry> pitti: awesome!
[16:07] <pitti> speaking of which, what's Quarreling Quail really going to be called like?
[16:07] <pitti> sabdfl: ^ :-)
[16:07] <sabdfl> qqqqqqqq
[16:07] <sabdfl> well
[16:07] <sabdfl> qu....
[16:07] <pitti> we soon need the name to put it into lintian, vim, and a few other places
[16:07] <barry> pitti: qwazy quahog!
[16:09] <pitti> barry: that makes baby jesus qwy
[16:09] <barry> pitti: :-D :-D
[16:09] <barry> pitti: that is going on my twitterfeed right now
[16:20] <slangasek> dupondje: 946709> how did you do the manual upgrade?
[16:23] <slangasek> dupondje: that's a duplicate of bug #850264
[16:24] <slangasek> dupondje: any chance you'd be interested in preparing an oneiric SRU for that?  It's on my list, but I haven't gotten to it yet
[16:26] <nigelb> pitti: haha, that was awesome :)
[16:31] <cjwatson> slangasek: did mvo manage to come up with a non-ABI-changing version of that?
[16:32] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034694.html
[16:32] <cjwatson> oh, wait, maybe that's a different bug
[16:36] <slangasek> oh phew, I was going to be sad
[16:51] <dupondje> slangasek: I changed the sources.list, then apt-get upgrade, then upgrade of some other packages, and then dist-upgrade untill it was all set :)
[16:52] <slangasek> ok
[16:52] <slangasek> yeah, that would bypass this bug
[16:53] <dupondje> apt-pkg/depcache.cc: prefer native providers over foreigns even if the chain is foreign.
[16:53] <dupondje> only this need backport ?
[17:02] <slangasek> dupondje: I believe so, yes
[17:07] <hyperair> hmm scrolling using a touchpad is broken in gtkmm 3.0
[17:08] <hyperair> case in point gnome-system-monitor
[17:11] <jtaylor> doko: is it still possible to merge numpy -7 for a fix of debian bug 664672?
[17:17] <dupondje> slangasek: http://bazaar.launchpad.net/~donkult/apt/experimental/diff/2193 -> this is the diff containing the change in depcache.cc, so just backport this :)
[17:17] <dupondje> going to check that ou
[17:17] <dupondje> out*
[17:17] <hyperair> hang on, it's not broken in just gtkmm. it's broken in everything suddenly. weird.
[17:21] <slangasek> dupondje: sure - any chance you can cherry pick that into a bzr merge proposal against oneiric and subscribe me?
[17:21] <slangasek> dupondje: (sorry, in the middle of a few other things at the moment so can't pick it up directly without a stack overflow)
[17:22] <dupondje> i'll check that later :) no much experience with bzr :) else I just do a debdiff
[17:23] <hyperair> weird, it all works again. i wonder what that was.
[17:25] <slangasek> dupondje: ok, debdiff is fine too; in that case please just attach it to the bug
[17:52] <slangasek> jibel: 979350> does that really establish that it's specific to amd64, or just that the memory thresholds are different for i386 vs. amd64?
[17:53] <slangasek> I'm not convinced that the memory usage of ubiquity itself is the key here
[17:55] <doko> jtaylor, sure, why not. it's not on any iso image
[18:44] <dobey> hey all. what user do package builds happen as under pbuilder?
[18:45] <tumbleweed> the pbuilder user
[18:45] <cjwatson> file:///usr/share/doc/pbuilder/pbuilder-doc.html#nonrootchroot
[18:45] <cjwatson> (public service announcement: use sbuild instead)
[18:47] <infinity> I was waiting for that.
[18:47] <infinity> cjwatson: You should probably get t-shirts printed for UDS.
[18:48] <cjwatson> "stop unpacking pointless tarballs: use sbuild"
[18:49] <dobey> https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#Packaging
[18:49] <dobey> "sbuild" occurs nowhere on that page :)
[18:50] <cjwatson> I can't help it if people are wrong
[18:50] <cjwatson> to be fair, sbuild was probably less usable outside buildd contexts at the time
[18:50] <dobey> anyway, whatever. the information doesn't help solve my problem :-/
[18:51] <dobey> which is to say, this: https://launchpadlibrarian.net/100003195/buildlog_ubuntu-lucid-i386.ubuntuone-dev-tools_3.1%2Br60-15~lucid1_FAILEDTOBUILD.txt.gz
[18:52]  * cjwatson wonders how pbuilder is even relevant, then
[18:53] <cjwatson> since the buildds don't use it
[18:53] <dobey> ok, well i don't know that
[18:53] <dobey> i don't maintai nthe buildds
[18:53] <cjwatson> I'm telling you now
[18:53] <dobey> i know i'm pretty smart, but there are actually things i don't know :)
[18:53] <dobey> ok
[18:54] <dobey> does sbuild build the packages as root?
[18:54] <cjwatson> no
[18:54] <infinity> dobey: So.  The builds run as 'buildd'.
[18:54] <infinity> dobey: Not that you should hardcode or rely on such a thing.  Your build should just work as any unprivileged user.
[18:54] <dobey> ok, so still likely not the relevant piece of information to the problem
[18:54] <cjwatson> it would be less frustrating if you could tell us what would be relevant
[18:55] <cjwatson> I feel like I'm playing twenty questions here
[18:55] <dobey> infinity: it doesn't. the exact same build works on all the newer versions of ubuntu
[18:55] <cjwatson> where's the .dsc for this?
[18:55] <dobey> i don't know what's relevant. i'm looking at a black hole trying to see what the problem is
[18:55] <Laney> can someone mash this? https://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.4.0-0ubuntu7/+build/3400563
[18:55] <cjwatson> I'll be happy to try it locally
[18:55] <dobey> cjwatson: in the ppa source i guess. it's a lp recipe build
[18:55] <cjwatson> and then explain how you can try it locally
[18:56] <infinity> Laney: Mashed.
[18:56] <cjwatson> dobey: URL please, I have no idea what that build log corresponds to
[18:56] <Laney> infinity: thanks
[18:56] <dobey> https://launchpad.net/~ubuntuone/+archive/nightlies/+files/ubuntuone-dev-tools_3.1%2Br60-15%7Elucid1.dsc
[18:57] <dobey> cjwatson: does sbuild let you specify a ppa to use to satisfy build-deps, for a single build, vs. for all builds as pbuilder requires?
[18:58] <cjwatson> you could do it with --pre-build-command if nothing else
[18:58] <cjwatson> er --pre-build-commands
[19:00] <infinity> dobey: Could it just be that you're doing something incompatible with lucid's squid?
[19:01] <infinity> dobey: Every other release is 3.1.x, lucid's 3.0... Could relate.  Dunno.
[19:01] <dobey> infinity: i guess not, as branch lp:ubuntuone-dev-tools on lucid and running ./run-tests with all the build-deps installed, works just fine. it's clearly an environment difference
[19:01] <cjwatson> hm, maybe not --pre-build-commands, doesn't support shell metacharacters - still, quick to switch back and forward
[19:08] <cjwatson> dobey: hmm; builds fine in a local sbuild
[19:09] <cjwatson> so it's not the building tool that matters, I think
[19:09] <infinity> The lucid chroot could be a bit wonky.
[19:10] <dobey> hrmm
[19:10] <infinity> Or it could be that old versions of squid REALLY want external DNS for some reason, or similar issues.
[19:10] <cjwatson> dobey: you could probably help yourself by having that exception also dump out stdout/stderr from squid
[19:11] <dobey> cjwatson: well, i was only asking about the user as it was a theory presented where squid couldn't access certain directories.
[19:11] <dobey> cjwatson: yeah, am having someone fix that as well
[19:11] <cjwatson> sure - but if squid is failing to start, I expect that it says why on stderr :)
[19:11] <cjwatson> which would save on speculation
[19:12] <dobey> sure. thanks anyway. i didn't mean to have it turn into a discussion about pbuilder vs sbuild or further speculation. :)
[19:13]  * cjwatson nods
[19:21] <SpamapS> did anything ever come of the effort to backport dh_python2 to lucid?
[19:21] <SpamapS> I have an ever-growing list of non-backportable packages that require special effort just to get onto lucid.. :-/
[19:21] <tumbleweed> SpamapS: no
[19:36] <dobey> SpamapS: dealing with dh_python2 vs. lucid in a package is very easy, actually
[19:36] <dobey> SpamapS: one second and i'll show you how :)
[19:37] <dobey> SpamapS: http://bazaar.launchpad.net/~ubuntuone-control-tower/dirspec/packaging-dailies/files
[19:37] <dobey> SpamapS: see rules and a few | deps in control.
[19:38] <dobey> or well, i guess the one | dep :)
[19:38] <dobey>  python-all (>= 2.6.6-3) | python-support (>= 0.6.4),
[19:38] <slangasek> yes, which means you get to build packages for lucid with all the bugs of python-support :/
[19:38] <dobey> yes well
[19:38] <dobey> at least it's not python-central
[19:39] <dobey> the other option of course is "don't build packages for lucid"
[19:39] <dobey> can we just EOL it a year early? :)
[19:39] <dupondje> slangasek: seems like there is more then that patch needed for fixing apt
[19:39] <dupondje> that patch seems to depend on other patches
[19:45] <slangasek> dobey: the option we wanted to take was to backport dh_python2
[19:46] <slangasek> I'm not saying you've done anything wrong, just that the workaround being "easy" doesn't make it a great one
[19:48] <dobey> slangasek: understood, but it's not done, and waiting until EOL for it to get done isn't helpful either. also if it only ends up in backports and not as an SRU, it will still only have very limited value.
[19:49] <slangasek> well, we had agreement to SRU it, but
[19:49] <slangasek> anyway
[19:49] <tumbleweed> given the progress on it, I'm not expecting it to ever happen
[19:49] <slangasek> dupondje: are you following through on the other patches?
[19:50] <dobey> tumbleweed: exactly :)
[20:35] <SpamapS> dobey: thanks.. I knew about that. But having to introduce a bunch of cruft in new packages just so I can get them back to lucid is pretty annoying.
[20:38] <dobey> SpamapS: i don't know if i'd call ~5 lines total "cruft" :)
[20:39] <dobey> but yes, i agree it's not the best thing. but it works quite well
[20:39] <SpamapS> dobey: and server has 3 years left for lucid, not 1 :)
[20:39] <dobey> you can of course also have a separate packaging branch for lucid
[20:39] <dobey> oh, right :(
[20:41] <SpamapS> dobey: the separate branch is what I do now
[20:41] <SpamapS> but every time somebody pokes a new package dep into something I want to support on all releases.. I have to branch the packaging or install the workaround you noted
[20:42] <SpamapS> having precise out will help ease the desire to keep pushing things back to lucid.. but that will take another year really.
[20:42] <dobey> yes well. i'd say maintaining multiple packaging branches is more cruft :)
[20:42] <SpamapS> dobey: its cruft that goes away automatically, which I like.
[20:45] <dobey> *shrug* :)
[21:04] <cjwatson> barry: any luck with bug 848915 yet?
[21:04] <ScottK> barry: Before we can reliably carry both python3.2 and python3.1 as supported versions, dh_python3 probably needs to grow a way to deal with modules with different code for different python versions.
[21:05] <barry> cjwatson: nope.  bdmurray did you have some additional information on that one?
[21:05] <barry> ScottK: yeah, that's what piotr mentioned quite often.
[21:06] <ScottK> barry: OK.  Since you mention you want 3.2/3.3 for "Q", be sure to write down doing that bit of work too.
[21:06] <barry> ScottK: i don't think we'll have to worry about 3.1 and 3.2, but 3.2 and 3.3
[21:06] <ScottK> Agreed.
[21:06] <cjwatson> barry: I thought we'd agreed a plausible hack to help track it down - did that not yield anything?
[21:06] <ScottK> 3.1 was a typo
[21:07] <barry> cjwatson: i've been working on other stuff first.  e.g bug 873468
[21:07] <bdmurray> barry: nope, no info
[21:07] <barry> ScottK: /me nods
[21:07] <barry> bdmurray, cjwatson: i'll take another look at 848915 when i finish with 873468
[21:08] <cjwatson> barry: I'm installing an oneiric desktop now to see if that will help
[21:08] <cjwatson> glad you're working on 873468 :)
[21:08] <barry> cjwatson: cool :)
[21:09] <cjwatson> down to five >=high rls-p-tracking bugs for foundations, counting stuff in -proposed ...
[21:09] <cjwatson> so the mess that is http://people.canonical.com/~rspencer/rls_bugs.svg isn't all our fault ;-)
[21:18] <slangasek> SpamapS: so.... we never got to the lvm2 merge, did we
[21:19] <slangasek> SpamapS: how far did you get with that in practice?  I'm interested to know if the new upstream version fixes bug #874774
[21:20] <SpamapS> slangasek: I tried and failed 3 times to resolve the merge
[21:20] <slangasek> blast
[21:20] <slangasek> ok
[21:20] <SpamapS> slangasek: the problem is, we have patches, debian has patches, and upstream has half of most of them applied
[21:21] <slangasek> yep
[21:21] <slangasek> any relevant notes from the experience, so that when we try the merge next cycle we might get there?
[21:21] <SpamapS> its like trying to separate the linguine from the fettucini in a bowl of spaghetti, blindfolded
[21:21] <cjwatson> see also: why we haven't merged plymouth
[21:21] <SpamapS> slangasek: I think with a strong, focused effort it will be doable
[21:22] <SpamapS> Its just my other 40 plates kept falling off their sticks, so I had to keep them spinning and let this one fall
[21:36] <dupondje> slangasek: we going to get the cryptsetup bugs down :)
[21:37] <slangasek> dupondje: that's the only one of them I'm worried about right now, and it looks like it might be an lvm2 bug ;)
[21:41] <dupondje> i'm already happy we don't have the uber prehistoric version we had a month ago :)
[21:43] <slangasek> yep, just a prehistoric lvm
[21:46] <dupondje> well thats to late to merge now I guess
[21:46] <slangasek> quite
[21:48] <dupondje> we should have ubuntu sid imo :) a rolling release would be cool
[21:49] <cjwatson> which would somehow magically create effort to merge things ...? ;-)
[21:50] <dupondje> if you are in the mood for a merge, and then its just FF :p
[21:50] <slangasek> that's what staging bzr branches are for
[21:52] <slangasek> pitti: hey, on the 'sudo doesn't preserve proxy vars' saga... do you know if there's a good reason sudo doesn't itself invoke pam_env?
[21:53] <slangasek> (su does, for comparison)
[21:53] <xee> Hi, I'd like to as what library gnome uses to display contents of an iphone so well when one is plugged in.
[21:55] <xee> Unity/Gnome I mean, in default Ubuntu setup.
[22:05] <dupondje> When are FFe syncs/merges accepted when they are ACK'ed ?
[22:06] <tumbleweed> dupondje: the ack on the bug just gives you permission to go ahead and sync/upload
[22:07] <dupondje> tumbleweed: I can't sync/upload myself :)
[22:08] <tumbleweed> right, so you subscribe the sponsors
[22:33] <dupondje> slangasek: https://launchpadlibrarian.net/101769525/apt.debdiff
[22:43] <xee> turns out it's gvfs itself
[22:43] <xee> thanks
[23:13] <astraljava> Does anyone have a bit of time to explain to me whether we'd run into problems with adding dssi-host-jack into our seeds, still (we would be Ubuntu Studio). Back in the day it was dropped, and I'm not exactly sure why.Then there was the dssi-vst problem with multiarch ia32-libs, germinate and all that, and since dssi-host-jack builds from the same source, I'm a little unsure whether adding it to the
[23:13] <astraljava> seeds will cause issues with the image spinning or not.
[23:14] <astraljava> Furthermore, would it require a FFe?
[23:14] <astraljava> And yet again, how quick/painless it is to refresh seeds to affect the image spinning?
[23:14] <astraljava> is it*
[23:15] <cjwatson> the problem with dssi-vst was that on amd64 it depended on i386-only packages
[23:16] <cjwatson> I don't see anything like that in dssi-host-jack
[23:16] <astraljava> cjwatson: That's what I started to realize after reading your mail on ubuntu-release in November last year.
[23:17] <cjwatson> so I don't see any issue there and I don't think it requires an FFe as long as you have the time to test it; but the package description suggests that it's only an example, so is it really much use?
[23:17] <astraljava> cjwatson: Ok, so what about the seeds thing, then? I'm asking because one of our apps in the seeds won't run out-of-the-box without any dssi hosts installed. I talked about this with quadrispro, and it seems this would be the sanest solution.
[23:18] <cjwatson> if you want it as a directly-seeded entry rather than as a dependency of something else, it's a matter of committing to the seeds and then refreshing/uploading ubuntustudio-meta
[23:19] <astraljava> cjwatson: I actually already put it in the seeds, but then became uncertain because of the whole ia32-libs thing (many hours before) and reverted it.
[23:19] <cjwatson> you can unrevert it then :)
[23:20] <astraljava> cjwatson: Right, thank you so much. :) I'll just ask here for the refresh/upload of -meta when it's back in the seeds, then?
[23:20] <cjwatson> and I can upload ubuntustudio-meta for you once you've done that, although if I do that then another member of the release team will have to deal with approving it
[23:20] <astraljava> So -release would be a better place to ask, so it's all there for the other member?
[23:21] <cjwatson> *shrug* I expect they're all here anyway
[23:23] <astraljava> cjwatson: Ok, rev. 1322 of ubuntustudio.precise has the unrevert fix. :) If you'd be so kind.
[23:28] <cjwatson> astraljava: running
[23:29] <astraljava> Thanks!
[23:29] <cjwatson> barry: stealing assignment of bug 848915
[23:30] <cjwatson> figured you probably wouldn't mind :)