[06:03] <pitti_> Good morning
[07:06] <mlankhor1t> g'day
[07:07] <didrocks> hey mlankhorst
[07:08] <mlankhorst> heya
[07:16] <pitti> voilà ! les nouveaux langpacks de raring
[07:16] <pitti> (les premiérs langpacks, en effet)
[07:17] <pitti> "è", excusez-moi
[07:18] <didrocks> pitti: super \o/
[07:31] <mlankhorst> oui, quest que cest francais langue pack officiel?
[07:31] <mlankhorst> or something
[07:32] <pitti> français est la langue officielle de bureau d'équipe
[07:32] <mlankhorst> \o/
[07:32] <pitti> mais seb128 n'a pas changé les ISOs
[07:33]  * mlankhorst tssks at seb128
[07:35] <didrocks> hum, seems glib regressed again unity builds :/
[07:36] <pitti> erk, "d'équipe de bureau"
[07:51] <jibel> good morning
[07:53] <didrocks> salut jibel
[07:57] <jibel> bonjour didrocks
[07:59] <RAOF> Aloha didrocks, jibel!
[08:00] <didrocks> good evening RAOF :)
[08:00] <jibel> Hey RAOF
[08:50] <pitti> GunnarHj: hey Gunnar, how are you?
[08:53] <didrocks> argh
[08:53] <didrocks> +/* test that g_app_info_* ignores desktop files with nonexisting executables
[08:53] <didrocks> + */
[08:53] <pitti> Guest41408: I have a question for you in bug 1159290
[08:53] <ubot2> Launchpad bug 1159290 in accountsservice (Ubuntu) "Fails to parse /etc/default/locale" [Medium,In progress] https://launchpad.net/bugs/1159290
[08:53] <didrocks> I guess that's this new feature breaking the tests
[08:53] <pitti> sorry, GunnarHj: I hvae a question for you in ^
[08:53] <pitti> didrocks: ah, you use some dummy names in Exec= ?
[08:54] <chrisccoulson> good morning
[08:54] <didrocks> pitti: well, existing desktop files (like software-center), but only for tests and so embeeded with the tests data
[08:54] <didrocks> pitti: so yeah, software-center isn't installed
[08:54] <chrisccoulson> ooh, so close https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/107/
[08:54]  * didrocks tries to rebuild with latest glib and set to /bin/true
[08:55] <didrocks> pitti: it's your fault on top of that! :-)
[08:55] <pitti> didrocks: oh?
[08:56] <pitti> my MP didn't touch desktop files
[08:56] <didrocks> pitti: no, you wrote the test, I was just kidding :)
[08:56] <didrocks> (the glib one)
[08:58] <pitti> didrocks: I recently fixed the glib test, yes; it started failing due to said bug fix
[08:58] <didrocks> pitti: heh, indeed, that's how I spotted it in the diff (thanks to you) :)
[08:59]  * didrocks just tries to rebuild unity and ensure this is working now
[09:17] <seb128> hey desktopers
[09:18] <didrocks> salut seb128!
[09:18] <seb128> lut didrocks
[09:18] <pitti> bonjour seb128
[09:18] <seb128> didrocks, so glib creating issues?
[09:18] <didrocks> seb128: yeah, I'm fixing the unity tests right now
[09:18] <popey> hmm. updated this morning, suddenly my laptop can't see the screen or keyboard attached to the docking station
[09:18] <didrocks> seb128: found the issue, proposing branches
[09:18] <popey> (morning)
[09:19] <seb128> didrocks, good
[09:19] <pitti> popey: we got a new kernel, maybe that?
[09:20] <popey> usb is broken too
[09:20] <popey> i can attach mice and see them in lsusb, but they dont work
[09:20] <pitti> popey: (FWIW, I have a dock, external screen, external keyboard etc too, WFM -- ThinkPad X201)
[09:20] <popey> same with keyboard - both tested on another computer
[09:20] <popey> hmm, x220 here
[09:20] <popey> it worked this morning before I updated
[09:20] <popey> xrandr can't see the display now
[09:21] <popey> even attaching them to the ports directly on the laptop, not using the dock fails
[09:22] <popey> 3.8.0-14-generic.. is that latest?
[09:24] <seb128> salut pitti, comment tu vas ?
[09:25] <pitti> seb128: je vais bien, merci il fait encore froid ici
[09:25] <seb128> pareil ici, 1°C ce matin :-(
[09:25] <pitti> il a neigé à nouveau
[09:26] <pitti> est-ce que l'hiver va jamais terminer ?
[09:27] <darkxst> seb128, maybe I should move to france, I like the cold ;)
[09:28] <mlankhorst> salut seb128
[09:28] <seb128> darkxst, I'm fine with the cold during winter
[09:28] <seb128> but it's officially spring according to the calendar
[09:28] <seb128> we are due some warmer weather :p
[09:28] <seb128> mlankhorst, hey
[09:29] <darkxst> I hear the snow is still good, so maybe not yet!
[09:29] <mlankhorst> boo, steam keeps bugging me about installing nvidia 310 drivers..
[09:29] <mlankhorst> I'm testing on nouveau!
[09:30] <pitti> seb128: nous avons des nouveaux langpacks
[09:30] <seb128> pitti, \o/ merci !
[09:30] <darkxst> speaking of drivers, apparently my nvidia blob, is open source! account to software properties
[09:30] <darkxst> s/account/according
[09:32] <darkxst> seb128, you can take some of our heat, I am over it!
[09:33] <seb128> if only climate exchange was working :p
[09:33] <pitti> seb128: it is..
[09:33] <popey> bug 1159671 is somewhat annoying..
[09:33] <ubot2> Launchpad bug 1159671 in Auto Upgrade Testing "test_python_import.py must test standard libraries too" [Undecided,New] https://launchpad.net/bugs/1159671
[09:34] <pitti> seb128: colder winters in central Europe are a consequence of the receding north pole ice cap
[09:36] <seb128> pitti, yeah, global warming for the loose, colder winter and warmer summers for us ... at least we don't have storms and other crazyness here
[09:36] <darkxst> pitti, and what do you have to say for our stupidly hot summer? not that we got many 40+ days like normal just everyday was 30-35 ;(
[09:37] <pitti> darkxst: well, what should I say -- I don't like very hot days either (nobody does), but it's a little late to complain now
[09:38] <darkxst> pitti, I will keep complaining until it stops! http://www.bom.gov.au/vic/forecasts/melbourne.shtml
[09:39] <pitti> hehe
[09:40] <seb128> pitti, oh, btw, systemd-services (with libpam-systemd purged) breaks my intel driver
[09:40] <pitti> seb128: you mean /dev/dri/card0 ACLs?
[09:41] <seb128> pitti, I went back to libpam-xdg-runtime on friday and purged libpam-systemd and I was on software rendering saturday
[09:41] <seb128> pitti, could be, I've no clue how to debug that
[09:41] <pitti> seb128: do you have an /etc/init/systemd-logind.conf ?
[09:41] <seb128> but purge systemd-services did the trick
[09:41] <pitti> oh, you wiped the evidence then
[09:41] <pitti> seb128: or perhaps not, the conffile moved already
[09:42] <pitti> maybe there's something wrong with the conffile migratino
[09:42] <pitti> seb128: can you install systemd-services again, reboot, and check that it still works?
[09:42] <seb128> doing that
[09:42] <pitti> seb128: you shouldn't have a /etc/init/systemd-logind.conf now
[09:42] <seb128> pitti, when I had the issue logind was not running and I had no /sys/fs/cgroup/systemd
[09:42] <pitti> (nor after installation)
[09:42] <seb128> pitti, I don't indeed
[09:42] <pitti> right
[09:43] <pitti> it's a problem with the ACLs and udev rules, not with the actual logind
[09:43] <pitti> seb128: if you still see this problem, I'd like to debug it
[09:43] <seb128> pitti, let me apply other updates and reboot
[09:44] <pitti> seb128: I have an idea what could be wrong
[09:46] <seb128> users are very angry about bug #1075923 (or at least active on it)
[09:46] <ubot2> Launchpad bug 1075923 in gvfs (Ubuntu) "nautilus hangs copying large directories from a samba share" [High,Confirmed] https://launchpad.net/bugs/1075923
[09:46] <chrisccoulson> jibel, on each autopkgtest run, are all of the tests in debian/tests executed in the same kvm instance?
[09:46] <pitti> chrisccoulson: yes
[09:46] <pitti> chrisccoulson: without purging deps from previous tests in between
[09:46] <pitti> chrisccoulson: the tests are executed in the order they appear in debian/tests/control, AFAIK
[09:47] <chrisccoulson> pitti, ah, thanks. that was going to be my next question :)
[09:47] <jibel> chrisccoulson, yw :)
[09:47] <chrisccoulson> i want to add an extra script to my test to post-process the result files that the earlier tests write
[09:47] <seb128> brb
[09:48] <chrisccoulson> (to filter out expected failures, rather than patching the upstream source to do the same thing, which is proving to be quite a headache to maintain)
[09:52] <seb128> re
[09:52] <seb128> pitti, back to broken
[09:52] <seb128> I'm yours to debug
[09:52] <pitti> seb128: let's change to /query
[10:06] <darkxst> chrisccoulson, spidermonkey should be released tomorrow, can we still sneak it into raring, or too late now?
[10:07] <jamesh> mvo: as a followup to the discussion on Friday, if I put together a patch for archive-index to include Unity scope files in the index it generates, would there be much problem getting that used for the indexing runs for 13.04?
[10:11] <jamesh> mvo: I'd like to know whether that is something worth pursuing, or whether we're better off looking at other solutions in the short term
[10:12] <darkxst> chrisccoulson, I have been running it since December or so, it fixes all the really bad issues in gnome-shell like GC deadlocks and leaks ;)
[10:13] <pitti> popey: see #u-devel, mystery solved
[10:13] <popey> thanks
[10:13] <pitti> popey: (at least that's very likely)
[10:14] <pitti> popey: that is, if you have systemd-services installed; if not, it's something else
[10:31] <mvo> jamesh: its probably fine, xnox was generated the latest app-install-data extractions, do you have the patch/branch somewhere?
[10:32] <jamesh> mvo: the one you mentioned last week was lp:~mvo/archive-index/app-install-mvo
[10:32] <jamesh> should I start with something else?
[10:34] <mvo> jamesh: thats the right one afaik - aha, sorry, I misread your earlier message. I missed the "if i would" and thought you already have a branch for this
[10:35] <mvo> jamesh: I think it would be no problem to include the scopes in the extraction but best is to double check with xnox just to be sure (given freeze state and all that). but the risk seems very low to include i
[10:56] <GunnarHj> pitti: Hi Martin, posted a comment on bug 1159290; possibly it answers the question you asked. ;-)
[10:56] <ubot2> Launchpad bug 1159290 in accountsservice (Ubuntu) "Fails to parse /etc/default/locale" [Medium,In progress] https://launchpad.net/bugs/1159290
[10:56] <pitti> GunnarHj: ah, so this was introduced in oneiric
[10:56] <GunnarHj> pitti: Yes.
[10:56] <pitti> GunnarHj: thanks, I'll adjust the changelog accordingly to point this out, and upload
[10:56] <GunnarHj> pitti: Ok, thanks!
[10:57] <GunnarHj> pitti: Wait ... it was introduced in Precise, I mean.
[10:57] <pitti> GunnarHj: oh
[10:57] <pitti> GunnarHj: we need that then
[10:57] <pitti> GunnarHj: until after 14.04 LTS
[10:58] <GunnarHj> pitti: No ...
[10:58] <pitti> ah, nevermind me; you mean "in the precise dev cycle"
[10:58] <GunnarHj> pitti: I mean that when people upgraded to Precise they migrated.
[10:59] <GunnarHj> pitti: Yes, in the precise dev. cycle. :)
[11:03] <GunnarHj> seb128: Hi Sebastien, can we talk about that Urdu bug?
[11:04] <seb128> GunnarHj, hey, sure, though I feel like I don't understand a lot about the topic, at least not enough to make a call on what's right either wsay
[11:05] <GunnarHj> seb128: The thing is that there is no decently working setup right now. Fontconfig states a font that is not installed when you install Ubuntu. I don't think it's in the archive at all.
[11:05] <GunnarHj> seb128: So I think it would be reasonable to do something in Raring, even if it's late in the cycle.
[11:06] <GunnarHj> seb128: s/Ubuntu/Urdu/
[11:06] <seb128> oh, I didn't understand that the font was not in Ubuntu, from the bug
[11:06] <GunnarHj> seb128: No, the discussion may well have been a little confused. But I did some research.
[11:08] <GunnarHj> seb128: The bug reporter + somebody else appear to have seriously compared various options.
[11:18] <Laney> someone tell ken that he misses replaces from gwibber to gwibber-service in his super-friends PPA please ;-)
[11:19] <jpds> Laney: Email?
[11:19] <seb128> Laney, will do
[11:20] <seb128> GunnarHj, I will have another look to the bug, would be useful to have some "testcases", like documents/webpages to load that show the missing font and the same situation improved with the patched fontconfig
[11:20] <seb128> GunnarHj, if you want to add the ttf to the package you will need a FFe though
[11:23] <GunnarHj> seb128: Hmm... Guess I'm not the right person to fix a demo of the effect. Isn't it reasonable to trust the Urdu speaking users? But I can apply for an FFE, of course.
[11:25] <seb128> GunnarHj, well, ask them to provide the testcase?
[11:25] <GunnarHj> seb128: Yes, will do that.
[11:25] <seb128> thanks
[11:30] <ricotz> seb128, hi
[11:30] <seb128> ricotz, hey
[11:31] <ricotz> seb128, please don't mark bug related to gnome3 ppa as invalid, afaik pitti even wants to integrate apport support for it
[11:32] <seb128> ricotz, I don't plan to track ppa issues in the middle of Ubuntu bugs, that's not pratical
[11:32] <ricotz> there is a bug about it but i dont recall it right now
[11:33] <ricotz> i think there is some custom target for it or something
[11:33] <seb128> well, launchpad doesn't have that feature
[11:33] <seb128> those bugs are reported against <source>/Ubuntu
[11:33] <seb128> e.g nautilus/ubuntu
[11:34] <ricotz> marking them invalid just buries them currently
[11:34] <seb128> so they show up in https://launchpad.net/distros/ubuntu/+source/nautilus/+bugs
[11:34] <ricotz> yes, i see
[11:34] <Laney> you should register a project and track bugs there
[11:34] <seb128> what Laney says
[11:34] <seb128> they are not Ubuntu bugs
[11:34] <seb128> we don't ship those versions in Ubuntu
[11:34] <ricotz> alright
[11:35] <seb128> ricotz, it's like the shotwell upgrade issues we received because of the version you uploaded to the elementaryos ppa
[11:35] <seb128> ricotz, we can't start collecting bugs from random different sources and version like that
[11:35] <seb128> or we will get lost not knowing what affects the distro
[11:37] <ricotz> seb128, shotwell?
[11:38] <seb128> I guess you didn't even notice that one...?
[11:38] <seb128> ricotz, we started receiving upgrade issue bugs on precise, there is a version (with your name as uploaded in the launchpad ui) which seems a sync from debian, which added a shotwell-common with incorrect replaces
[11:38] <seb128> ricotz, in the elementaryos ppa
[11:39] <ricotz> ah yes, someone copied the yorba package in there which was even more borked
[11:39] <seb128> ok
[11:40] <ricotz> seb128, dont compare gnome3-ppa with eos it is a whole other story
[11:40] <ricotz> but the issue might be similar, so ok
[11:41] <seb128> well, the issue is to be able to track properly bugs that affect the release
[11:41] <seb128> and if we start mixing ppa and archive bugs it's getting harder
[11:42] <seb128> ok, on that note, lunch time, need to get offline, I will be back in ~1h
[12:01] <xnox> mvo: jamesh: i just used lp:archive-index as mvo's patch got merge as far as I could tell. I did the extraction a tiny bit different and committed my changes in app-install-data ubuntu packaging branch.
[12:01] <xnox> mvo: jamesh: I think i got the extraction mostly right =) and people haven't been yelling so far. (still need to "fix" bugs by updating overrides/blacklists/etc)
[12:02] <xnox> mvo: jamesh: if you make a merge proposal on top of lp:archive-index I'm happy to review it, and regenerate the indexes.
[12:51] <pitti> ricotz: yep, new apport with that "gnome 3" hook is in raring now
[12:59] <seb128> re
[12:59] <seb128> (with a working adsl back)
[13:01] <ricotz> pitti, great :)
[13:01] <happyaron> seb128: hi
[13:01] <seb128> happyaron, hey
[13:02] <happyaron> seb128: do you mind add a fcitx developer to the IM topic meeting?
[13:02] <pitti> seb128: wb
[13:02] <happyaron> He lives in the US and have some free time.
[13:02] <seb128> happyaron, we don't have a closed agenda/set of people and some spare slots on the hangout, if somebody wants to join that's fine
[13:02] <seb128> pitti, thanks
[13:03] <pitti> seb128: FYI, I uploaded apport with the "ubuntu-gnome" hook today, which will divert bugs and crashes from the gnome3 PPAs to the ubuntu-gnome LP project
[13:03] <happyaron> seb128: great
[13:03] <seb128> happyaron, I will share the hangout URL on IRC when I start it
[13:03] <happyaron> seb128: thanks
[13:03] <seb128> pitti, \o/
[13:03] <seb128> pitti, does that apply if any depends is from the ppa? or only if the source the bug is reported against is?
[13:04] <pitti> seb128: it only checks Package:, not Depends:
[13:04] <seb128> hum, k
[13:04] <pitti> seb128: we could do that, of course, but it might lead to false positives, too
[13:04] <seb128> it would be nice to tag "use-gnome3-ppa" as well
[13:04] <seb128> without reassigning
[13:19] <pitti> seb128: ah, that can be done easily
[13:21] <pitti> seb128: pushed to the packaging branch
[13:34] <seb128> pitti, danke
[13:34] <seb128> happyaron, you said somebody wanted to join the hangout?
[13:35] <happyaron> seb128: yes
[13:35] <happyaron> seb128: he's not on IRC, but I can give him the link via Google talk.
[13:35] <seb128> happyaron, https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en
[13:36] <happyaron> ok
[13:37] <happyaron> seb128: his name is Yichao Yu, a student at MIT.
[13:37] <seb128> happyaron, he's in the hangout, thanks
[13:37] <happyaron> :)
[13:39] <happyaron> my connection to Google+ server is so poor to handle realtime A/V meetings, so let me watch the video later...
[13:40] <seb128> happyaron, feel free to comment on #ubuntu-mir
[13:40] <happyaron> ok
[13:43] <jhernandez> cd /windows/4
[14:15] <rickspencer3> hey didrocks I'm getting a dist-upgrade with all the new scopey stuff
[14:15] <rickspencer3> anything in particular I can teset for you?
[14:15] <didrocks> rickspencer3: hey, enabling/disabling the scopes in the filter would be appreciated
[14:16] <didrocks> rickspencer3: and accuracy of search (which I guess isn't optimal)
[14:18] <rickspencer3> bschaefer, I'm setting up the ppa on my netbook now
[14:19] <bschaefer> rickspencer3, awesome, thanks! I think what it does is turns off blur for machines that can't do it
[14:20] <seb128> kenvandine, btw
[14:20] <seb128> kenvandine, <Laney>	someone tell ken that he misses replaces from gwibber to gwibber-service in his super-friends PPA please ;-)
[14:21] <kenvandine> whoops
[14:21] <kenvandine> i'll check on that :)
[14:21] <kenvandine> actually i added transitional packages
[14:36] <rickspencer3> didrocks, are the filters in the dash supposed to be persistent?
[14:36] <didrocks> rickspencer3: no, for every search, they reset to reflect the available categories
[14:37] <rickspencer3> didrocks, ok
[14:38] <rickspencer3> didrocks, is there a place where I can permanently enable/disable scopes?
[14:38] <didrocks> rickspencer3: not yet, it's under work
[14:38] <rickspencer3> didrocks, ok
[14:38] <didrocks> rickspencer3: it will be displayed as another master scope
[14:39] <rickspencer3> didrocks, so, if I have the dash open, and search for "Grateful Dead"
[14:39] <rickspencer3> filter the search with the categories and sources I want
[14:39] <rickspencer3> then clear out that search and type in "Phish" ...
[14:39] <rickspencer3> it's a bit annoying that it resets the filters
[14:39] <didrocks> rickspencer3: something to talk JohnLea about I guess ^
[14:40] <rickspencer3> however, I suppose if I can permanently disable scopes, it will be ok
[14:40] <rickspencer3> didrocks, otherwise, except for wikipedia being slow, it seems to be working fine for me
[14:40] <didrocks> rickspencer3: yeah, we still have a lot of slowliness to fix IMHO before shipping it
[14:40] <didrocks> rickspencer3: and weird results sometimes
[14:42] <JohnLea> rickspencer3; the purpose of the Smart Scopes service that the U1 team are building is to automatically select which scopes are relevant to any given search query.  The idea is that when this service goes into wide usage, the user responses we are measuring will go back into this big data 'intelligent content type picker service' and make the results more accurate.  That is the theory...
[14:43] <rickspencer3> JohnLea, I can see that between searches
[14:44] <rickspencer3> like I search, pick some or close the dash, and then come back
[14:44] <rickspencer3> but if I leave the dash open, search, set filters, and then without leaving tweak my search ...
[14:44] <rickspencer3> it's a but inhumane to reset the filters I just painstakenly set up
[14:55] <JohnLea> rickspencer3; yes agreed. The issue is that the only filters available in the dash home in 13.04 are the different Lenses, and when you manually set the lenses that is basically overriding the smart scope service.  Your use case is valid, but so two is the use case of the user not finding what they want with the first search query, they try adjusting the scope filters, and then  the user amend the search. This updated search query
[14:55] <JohnLea> gives the smart scope service more information to improve it's selection of scopes, and with then updated information it finally returns the correct scopes to the user.  The brief for this service was to be able to scale up to a world with potentially thousands of scopes, and at this point asking the user to manually find the right scopes isn't that feasible.  I totally understand your use case and it has already been much discusse
[14:55] <JohnLea> d, but it is difficult to resolve without breaking the use case I have just described.  Remember as well that in 12.10 there were no filters in the Dash, and the next version of the Dash Home in Unity Next might not have these filters in the Dash Home either, again because of the scalability issues.  Oren has now picked up the Dash design mantel going forward, so perhaps ping him to discuss?
[16:09] <dobey> mterry: is bug 1130782 about the control panel, or about the backend bits that use glib/gobject?
[16:09] <ubot2> Launchpad bug 1130782 in ubuntuone-client (Ubuntu) "Port to Qt5" [Undecided,New] https://launchpad.net/bugs/1130782
[16:10] <mterry> dobey, about anything in main ideally
[16:10] <mterry> dobey, oh
[16:10] <mterry> dobey, I meant from Qt4 to Qt5
[16:10] <mterry> dobey, so not the glib/gobject bits
[16:11] <dobey> mterry: so the ubuntuone-control-panel-qt app, not ubuntuone-syncdaemon, right?
[16:12] <mterry> dobey, yeah
[16:12] <mterry> dobey, (we just want to get Qt4 into universe if possible, so we only have one version of Qt we are supporting)
[16:13] <dobey> mterry: yeah, i'm just asking so i can put the bug in the right place (ubuntuone-control-panel vs. ubuntuone-client)
[16:13] <mterry> dobey, oh sorry...
[16:14] <dobey> mterry: no worries
[16:23] <Chipaca> mterry: also, we accept patches
[16:33] <mterry> Chipaca, I assumed you did  :)  Is that your way of saying the U1 team does not have a Qt5 patch on their roadmap
[16:33] <mterry> ?
[16:33] <mterry> s/patch/port/
[16:42] <Chipaca> mterry: that is correct
[16:43] <Chipaca> mterry: i mean, we don't; i'm not sure it's my way of saying it, but just now, that's one of the things i meant when i said it
[16:43] <Chipaca> mterry: the other was, quite literally, that we'd gladly take a patch that worked :)
[17:53] <robru> didrocks, around for much longer?
[17:53] <didrocks> robru: was about to leave in few minutes, why?
[17:53] <robru> didrocks, I just wanted to talk to you about the libhud stuff
[17:53] <didrocks> robru: yeah, what's up?
[17:54] <robru> didrocks, so ted says that libhud makes regressions on the desktop? where does that leave me? I am totally blocked on landing any of those branches I've been assigned to... webbrowser-app and camera-app are blocked on libhud, and the other three are blocked on those two
[17:55] <didrocks> robru: I don't understand, see his answer on my other questions
[17:55] <didrocks> robru: on this one, he told it was ready?
[17:55] <robru> didrocks, ok, so the plan is that it just goes into a PPA until S opens then? so I don't have to worry about landing anything in raring?
[17:56] <robru> didrocks, it's not clear to me what I need to be *doing* at this point.
[17:56] <didrocks> robru: exactly, we will use a ppa for that. I will try to create it and setup a daily release process for it tomorrow. (I'm still 100% focused on this 100scope, but I need to escape from it for 2 hours to not have you blocked too much)
[17:57] <didrocks> robru: then, see with cyphermox about libhud/hud2, not sure he started to look at those
[17:57] <didrocks> robru: we'll have this in the "phablet/next" ppa
[17:57] <robru> didrocks, ok, so just let me know when the PPAs are ready, and I'll continue. until then I will work on friends ;-)
[17:57] <didrocks> robru: can you double check with tedg if his hud2 is or is not desktop compatible? (that would be useful even with the ppa)
[17:58] <didrocks> robru: you have some of the MP where I had comments
[17:58] <robru> ok
[17:58] <didrocks> robru: like lintian issues to fix :)
[17:58] <didrocks> robru: or amd64 not building, talk with upstream about it
[17:58] <didrocks> did I miss an email on that? :)
[17:59] <robru> didrocks, no, they're all blocked because I can't make any of them compile in raring without libhud ;-)
[17:59] <didrocks> robru: but you were using the ppa meanwhile, right?
[17:59] <didrocks> to build
[17:59] <tedg> didrocks, robru, got the legacy search interface to land this morning.
[17:59] <tedg> It's in lp:hud/phablet
[17:59] <robru> didrocks, well for some of them they were building in jenkins ok, but I couldn't get any of them to build locally. maybe only one built locally
[17:59] <didrocks> tedg: so everything is fine? normally no regression at all using that one?
[17:59] <tedg> Works for me on my raring desktop :-)
[18:00] <robru> oh, hey tedg
[18:00] <didrocks> robru: ah ok, that's why you can't see the lintian warnings :)
[18:00] <didrocks> tedg: excellent news!
[18:00] <tedg> didrocks, Well, other than the ones we discussed.  No indicators by default and no highlighting.
[18:00] <didrocks> tedg: highlighting?
[18:00] <tedg> didrocks, The highlighting is TBD, but the indicators require the appstack that we don't want to write in Nux.
[18:00] <tedg> didrocks, Search for "hu" and get "<b>hu</b>d"
[18:01] <didrocks> tedg: ah ok :)
[18:01] <didrocks> tedg: yeah, ok, minor
[18:01] <didrocks> robru: so, tomorrow, let's start getting that in a ppa
[18:01] <robru> didrocks, ok
[18:01] <didrocks> robru: ensure with cyphermox that he's ready on this one :)
[18:01] <robru> cyphermox, ^^ ? ;-)
[18:02] <robru> didrocks, ok, I will let you go for now. I gotta get some breakfast ;-)
[18:02] <didrocks> :)
[18:02] <didrocks> enjoy your breakfast!
[18:08] <cyphermox> robru: just a second, reading backlog
[18:08] <cyphermox> ok, hud2/libhud?
[18:08] <cyphermox> it's BLOCKED
[18:11] <didrocks> cyphermox: blocked on what?
[18:16] <didrocks> cyphermox: see above, tedg has addressed the desktop issue ^ so we can now get it daily landing (in the ppa I would provide tomorrow)
[18:21] <cyphermox> fair enough
[18:22] <cyphermox> didrocks: it was just marked as so in the blueprint
[18:22] <didrocks> cyphermox: see the backlog, we discussed that few lines ago :-)
[18:22] <cyphermox> it's not obvious if I'm not pinged ;)
[18:22] <didrocks> I thought you told "reading backlog" ;)
[18:23] <cyphermox> yeah
[18:23] <cyphermox> I read enough to know *what*
[18:23] <cyphermox> but then the blueprint should be authoritative
[18:23] <cyphermox> tedg: update the blueprint ? :)
[18:23] <didrocks> fair enough
[18:23]  * cyphermox starts on hud2.0/libhud-qt
[18:40] <seb128> desrt,  there?
[18:56] <Sugarat> Can anyone advise how to change the refresh rate that my TV on HDMI is using?  I need to force a specific refresh onto it
[19:02] <tedg> cyphermox, Will do.  It just landed during the meeting and then I went to lunch.  I'll fix it now. :-)
[19:03] <cyphermox> ok :)
[19:15] <desrt> seb128: hi

[19:20] <desrt> cyphermox: poke if you need any help
[19:20] <cyphermox> desrt: moo?
[19:21] <mterry> robru, heyo, btw, I have two deja-dup branches I'd like to squeeze into 26.0.  I was hoping to release this week, if you have review tme
[19:21] <desrt> cyphermox: the hud stuff
[19:21] <mterry> time
[19:21] <cyphermox> oh, cool
[19:21] <robru> mterry, can do this week, just not today
[19:21] <cyphermox> desrt: it's just packaging review. so far things look like they build fine, so I think it's going to be good
[19:21] <desrt> ahh
[19:21] <desrt> i thought you were writing it
[19:21] <mterry> robru, OK, thanks!
[19:21] <cyphermox> I'll start pushing everything to my PPA now though
[19:21] <cyphermox> nah
[19:23] <desrt> seb128: i notice that gnome 3.8 gsettings-daemon-schemas has this:
[19:23] <desrt>       <_summary>Use different input sources for each window</_summary>
[19:23] <desrt>       <_description>
[19:23] <desrt>         When enabled, input sources get attached to the currently
[19:23] <desrt>         focused window when activated.
[19:23] <desrt> *desktop-schemas
[19:25] <desrt> attente: https://git.gnome.org/browse/gsettings-desktop-schemas/tree/schemas/org.gnome.desktop.input-sources.gschema.xml.in.in
[19:29] <desrt> attente: also https://git.gnome.org/browse/gnome-shell/tree/js/ui/status/keyboard.js
[19:31] <seb128> desrt, hey

[19:31] <seb128> desrt, yeah, we were talking about today, score, they dropped stuff from ibus to put them in gnome-shell/g-s-d
[19:32] <desrt> seb128: i advised attente to base the indicator work off of this schema that i linked
[19:32] <desrt> since the entire indicator is basically just reading a list of layouts from gsettings and updating it when the user makes the change
[19:32] <desrt> (and i guess g-s-d syncs up the X server on the other end)
[19:33] <seb128> desrt, isn't the tracking/logic in gnome-shell though?
[19:34] <desrt> tracking?
[19:34] <seb128> desrt, what's the active win and what should be applied to it
[19:34] <desrt> oh.  i don't know about that.
[19:34] <desrt> maybe :)
[19:34] <seb128> I'm pretty sure it is
[19:34] <desrt> something else to consider
[19:34] <seb128> yeah
[19:35] <seb128> if you say "pidgin is 'zh' layout", "gedit is "en"", you need those infos stored somewhere and to have something saying "pidgin is focused, "en" should be active"
[19:35] <desrt> ya.  that makes sense.
[19:36] <desrt> how did that work before?
[19:36] <desrt> g-s-d?
[19:36] <seb128> ibus
[19:36] <desrt> i mean the per-window layouts
[19:36] <seb128> that got dropped in 1.5
[19:37] <desrt> even without an input method
[19:37] <desrt> something handled that before
[19:37] <seb128> which is one of the reasons we stay on 1.4
[19:37] <seb128> ah
[19:37] <desrt> *3.4
[19:37] <seb128> g-s-d was doing that for layouts
[19:37] <desrt> oh.  ibus 1.4
[19:37] <seb128> and ibus for ims
[19:37] <desrt> right
[19:37] <seb128> desrt, anyway, I've a bug for you :p
[19:38] <desrt> great
[19:38] <desrt> today is release day, though :)
[19:38] <seb128> desrt, you are the new pitti around, you won the right to collect pitti's class of bugs :p
[19:38] <seb128> desrt, no hurry
[19:38] <seb128> desrt, https://bugs.launchpad.net/bugs/922968
[19:38] <ubot2> Launchpad bug 922968 in oem-priority/precise "shouldn't queue a second suspend if the machine is already suspending" [Medium,Confirmed]
[19:38] <desrt> oh christ
[19:38] <seb128> desrt, the bug is basically "if I hit my suspend key and close the lid, my laptop queue a second suspend and suspend again on lid open"
[19:39] <desrt> ya.  i know about this.
[19:39] <seb128> I had a feeling that could be the case :p
[19:39] <seb128> any chance it's fixed by logind? :p
[19:39] <desrt> f18 has the same bug still
[19:39] <desrt> dunno about f19
[19:39] <seb128> k
[19:39] <desrt> fwiw, i plan on suspend going via systemd-shim soon
[19:39] <seb128> can you talk to lennart about it?
[19:39] <desrt> so maybe this is in my area after all
[19:40] <desrt> there is only one way to fix it:
[19:40] <seb128> desrt, it's not really a real user issue but it seems an issue for oem testing
[19:40] <desrt> at the time that we get the instruction to suspend (either by way of keypress or lid close or whatever) we record the system monotonic time
[19:40] <desrt> then when doing the suspend we make sure we didn't already suspend since that time
[19:41] <desrt> this way there is no event 'in the queue' that we will process when we wake up
[19:41] <desrt> because we'll see it, but the timestamp will be too old, so we can ignore it
[19:41] <desrt> i hit the issue from time to time
[19:41] <desrt> i don't trust lid close for suspend because of it not working properly historically
[19:41] <desrt> so i always hit the suspend key then close the lid
[19:41] <seb128> can't you just compare the event time to the suspend time and flush the queue on resume?
[19:41] <desrt> and i often get double-suspend as a result
[19:42] <desrt> well
[19:42] <desrt> 'the queue' is complicated, right?
[19:42] <desrt> like, dbus messages in-flight and stuff
[19:42] <seb128> well, just discard any event that has a timestamp older than the last suspend one?
[19:42] <desrt> the problem is taht the timestamps don't get forwarded
[19:42] <desrt> so we don't have that info
[19:43] <desrt> a relatively easier workaround, though, would be to discard suspend requests that we get within the first 1-2 seconds of wakeup
[19:43] <seb128> that would work for me
[19:43] <desrt> that would be easy
[19:43] <desrt> i'll talk to lennart about the better fix
[19:44] <desrt> it seems that one way or the other we will be handling suspend via systemd in the future
[19:44] <seb128> but that's not really "clean" so I'm not sure others will like it
[19:44] <desrt> so we should agree on the correct way and add it to the interface
[19:44] <seb128> I though logind was handling suspend?
[19:44] <desrt> then he can do it in systemd and i can do it in -shim
[19:44] <seb128> was -> is
[19:44] <seb128> they moved that from upower to logind
[19:44] <seb128> no?
[19:44] <desrt> seb128: logind does handle suspend... but it asks systemd (pid1) to do the actual work of suspending
[19:45] <desrt> pitti has a patch that if systemd is not there then it invokes pm-utils directly
[19:45] <desrt> but i plan to add the support for this to systemd-shim
[19:45] <seb128> I see
[19:45] <desrt> so systemd-shim will be talking to pm-utils
[19:45] <desrt> and i can add some 'smarts' there
[19:45] <seb128> well, eventually we want to drop pm-utils at some point
[19:45] <desrt> then lennart can do the same in the real systemd
[19:45] <seb128> but yeah, meanwhile
[19:46] <seb128> desrt, ok, seems to have an handle on the bug, I will just assign to you for investigation, please talk to lennart and drop your comment about solution/temporary workarounds in the bug ;-)
[19:46] <seb128> desrt, it seems like oems have one of their suspend/resume tests that is likely to hit that issue, that's where the main motivation is coming from
[19:47] <seb128> (it can be annoying for users but it's easy to workaround and not that frequent)
[19:48] <desrt> yup
[19:49] <seb128> chrisccoulson, hey
[21:19] <desrt> larsu: https://git.gnome.org/browse/glib/commit/?id=5fb7a8e127bde6465a5b9e22b299ca2e439e702c
[21:22] <desrt> larsu: sorry, this one: https://git.gnome.org/browse/glib/commit/?id=af24dbc12aa77aac3c82d39872878558cced7add
[21:35] <Sweetshark> seb128: around?
[21:35] <seb128> Sweetshark, yes
[22:21] <attente> seb128, do you know if there's a new ibus going to one of the staging ppas?
[22:27] <seb128> attente, not that I know/can see
[22:28] <seb128> you can find debs from debian on http://ftp.debian.org/debian/pool/main/i/ibus/  (1.5.1)
[22:28] <seb128> they might work on ubuntu
[22:28] <seb128> or check with jbicha or ricotz when they are around, they might have some somewhere
[22:32] <attente> ok, thanks seb128