[00:13] <Laney> darkxst: gjs/ppc test failure :(
[00:24] <Laney> lp:~ubuntu-desktop/gnome-control-center/ubuntu-saucy
[00:26] <seb128> Laney, https://code.launchpad.net/~attente/gnome-control-center/lp1218322
[02:11] <Rodge_> hey folks! For those who have (had) the graphics card ATI Mobility Radeon X1600 (e.g. on the elderly laptop HP nx9420), have you succeeded in getting a useful driver for it in Ubuntu 13.10?
[02:13] <Rodge_> I don't want to format my drive just to find out it was worthless... (Having Win7 on it now) .. OR, any advice on some stable, free "Partition Magic"?
[02:13] <sarnold> Rodge_: you may have better luck in #ubuntu, this channel is more for development -of- the desktop..
[02:13] <Rodge_> aaah :) thanks!
[02:13] <sarnold> Rodge_: to that point, I'd hope a livecd / usbstick would be useful?
[02:13] <sarnold> (thogh maybe it'd stickto horrible drivers.. hrm.)
[02:17] <Rodge_> sarnold:  hm.. long time since I've used a liveCD/-stick.. is it possible to upgrade the "live OS" and apply updates after reboot?
[02:18] <sarnold> Rodge_: I think it'll all fall down once you reboot; but you -might- be able to apply the updates while it is running, and then e.g. restart X or something. I've not tried ;)
[06:53] <darkxst> Laney, looks like its been broken for a while, just that tests were non-fatal previously
[06:53] <darkxst> https://launchpadlibrarian.net/148350924/buildlog_ubuntu-saucy-powerpc.gjs_1.37.6-0ubuntu1_UPLOADING.txt.gz
[07:10] <darkxst> Laney, it broke with the js17 transition back late July
[08:55] <mlankhorst> morning
[13:58] <nessita> hello everyeon! quick question: I'm running a fully updated saucy, and since about a week I'm having noticeable delays on accessing my hard drive (I can tell because Firefox hangs when going to the cache, terminal TAB completion is slower than before, bzr st takes for ever, etc). Is there any way of diagnosing what's happening?
[14:09] <ogra_> nessita, did you check with top if there are any stray process (or better install the more userfriendly htop)
[14:11] <nessita> ogra_, I've checking with top regularly, my non-trained eyes did not notice anything unusual
[14:11] <nessita> I've been*
[14:12] <nessita> ogra_, anything particular I should look for in top (or htop)?
[14:12] <ogra_> just the top consumers of CPU and ram ...
[14:13] <ogra_> and if there is something that eats much of either every time you check ... when checking over i.e. a day
[14:13] <nessita> ogra_, usually firefox is the one at the top of top
[14:14] <ogra_> also how much ram does your box have ... slowness can easily be  caused if the system uses swap
[14:14] <nessita> 8G
[14:14] <ogra_> well, the should be sufficialt
[14:14] <ogra_> *sufficient
[14:14] <nessita> swap is not being used every time I checked
[14:14] <ogra_> yeah, with 8G it should be used very rarely if at all
[14:15] <nessita> ogra_, also, the "use case" for my box has not changed (a couple of LXC containers, a couple of browser, a couple of terminals)
[14:15] <ogra_> your disk settings in the mail look all right
[14:15] <ogra_> (seemingly using the most performant settings the drive supports)
[14:16] <ogra_> if you can not pinpoint it to some specific app i would guess it is a kernel or filesystem issue
[14:18] <nessita> ogra_, would you know if this could be tied to an update on firefox (1-2 weeks in the past)?
[14:18] <nessita> I did notice that every time I check top firefox is at the top
[14:18] <ogra_> probably ... if you see firefox in top, how much CPU/RSS does it consume ?
[14:20] <ogra_> also do you have a lot flash based pages open usually ?
[14:20] <ogra_> (flash can be really evil)
[14:20] <nessita> ogra_, I'd say None, but some pages that do lots of ajax (twitter, gmail)
[14:21] <dobey> firefox is easily the largest consumer of RSS on my system
[14:21] <dobey> and i have 16 GB RAM
[14:21] <dobey> i had it at 1.8 GB RSS the other day, when i had to restart it
[14:21] <nessita>  3256 nessita   20   0 1375m 468m  68m S   2.7  5.9  12:53.57 firefox
[14:22] <dobey> firefox 25 supposedly is better at releasing memory, but it's still at ~800M RSS for me right now
[14:22] <nessita> 468m for me
[14:22] <nessita> anyways, *right now* I don't notice any slows down
[14:22] <dobey> mine's been running for a few days, but yeah
[14:22] <dobey> nessita: how big is VIRT in firefox?
[14:23] <nessita> 1447m
[14:23] <ogra_> 800M is nothing on a 8/16G machine
[14:23] <nessita> hum, opening mail.yahoo.com makes firefox spike in CPU usage
[14:23] <dobey> ogra_: no, but firefox also has no reason to actually be using that much
[14:23] <ogra_> well, it should only spike on one CPU core
[14:23] <dobey> ogra_: and it is a lot on my 2GB or 1GB machines
[14:24] <ogra_> so that shouldnt gegrade performance if you have an SMP machine
[14:24] <nessita> ogra_, yes, it does spike only one core (from 30% to 70%)
[14:24] <ogra_> yeah, that wont cause the slowness
[14:24] <nessita> ogra_, right, I have 4 cores with smp
[14:24] <nessita> but I insist the slowness is when accessing the hard drive
[14:25] <nessita> bzr st hangs, for example
[14:25] <ogra_> right, so your system still has enough fuel to be snappy ... talk to the kernel guys in #ubuntu-kernel if they know about any specific disk problems
[14:25] <dobey> disk i/o is typically the cause for slowness, yes
[14:26] <nessita> dobey, any way of checking disk io on htop?
[14:27] <nessita> wow, this is odd:
[14:27] <nessita> 1179 root       20   0  204M 74524 33036 S 62.4  0.9  8:31.63 /usr/bin/X -core :0 -auth /var/run/lightdm/root/:0
[14:27] <nessita> 62.4% of CPU
[14:27] <ogra_> constantly ?
[14:27] <nessita> and it matched the computer hanging
[14:27] <jibel> nessita, there is iotop for IOs
[14:27] <nessita> ogra_, nopes, now it went down, and disk stopped spinning
[14:27] <ogra_> yeah
[14:28] <nessita> jibel, thanks, installing
[14:29] <dobey> nessita: install iotop
[14:29] <nessita> running it right now
[14:37] <nessita> nothing odds pops up right now (but slowness is not noticeable yet)
[14:37] <nessita> will keep looking and trying to gather info
[14:37] <nessita> ogra_, dobey, jibel: thanks!
[14:37] <ogra_> :)
[16:02] <Laney> darkxst: Right, I checked the previous upload and it had the problem too
[16:02] <Laney> it didn't fail the build though as the tests were non-fatal then
[16:09] <Laney>  /sb e
[16:10] <Laney> oops
[16:38] <Mirv> Laney: hi you've done manual uploads of indicator-datetime and libindicator to trusty, which break the prepare jobs in cu2d. could you push to their trunks manually something that syncs the debian/changelog from your uploads without breaking anything otherwise? at least initially I became confused when dgetting from archives and unpacking on top of the bzr.
[16:39] <Laney> I just copied them from saucy.
[16:47] <Mirv> Laney: so can you push your uploads' debian/changelog and needed changes to lp:libindicator and lp:indicator-datetime then? I think they have diverged now, with other 14.04 changes in the branches but the saucy changes not in there.
[16:47] <Laney> They aren't my uploads
[16:47] <Laney> Also cyphermox was handling datetime
[16:48] <Mirv> Laney: ok, can you then ask cyphermox and is it seb128 who did the libindicator to saucy uploads to have both the 13.10 and trunk bzr:s up-to-date?
[16:48] <Mirv> well they were just pinged now obviously :)
[16:49] <cyphermox> the what?
[16:49] <Mirv> cyphermox: indicator-datetime for you, trunk and 13.10 branches vs. what was uploaded to saucy and copied to trusty by Laney
[16:49] <Mirv> to fix cu2d for both head and saucy
[16:50] <cyphermox> it's just a matter of pushing the changelog for indicator-datetime, I'll get to it soonish. all the commits are already in trunk
[16:50] <Mirv> cyphermox: it seemed confusing to me, so I'd rather have you check both 13.10 + trunk vs. the archives
[16:50] <seb128> cyphermox, Mirv: it's stupid to have to do manual copies just because saucy packages are carried/copied to new serie
[16:51] <Mirv> seb128: they were not carried but uploaded manually by Laney. the correct way would have been to forward-port the needed saucy changes to trunk, and have cu2d release it
[16:51] <cyphermox> seb128: no... it's not an upload that happened in daily-release it just needs to get the right changelog
[16:52] <seb128> Mirv, not it's not, it's a pocket copy from saucy-updates
[16:52] <Mirv> seb128: aha, ok, but there are anyway changes in trunk that are not in saucy and vice versa, someone needs to not just do the copies but have the bzr branches updated?
[16:53] <seb128> Mirv, seems like cyphermox is on it
[16:53] <Mirv> seb128: he's on it for indicator-datetime, but libindicator should also be checked - it seemed like the indicator-ng.c change is not in trunk
[16:55] <seb128> Mirv, it is, https://code.launchpad.net/~larsu/libindicator/always-create-widgets/+merge/191698
[16:57] <Mirv> seb128: so that's what the debian/changelog mentions with "backport fix for indicator icons notupdating sometimes"?
[16:58] <Mirv> yeah, it seems to address the same bug
[16:59] <seb128> Mirv, yes, backport is "copy the trunk fix to stable"
[16:59] <Mirv> ok, then I'll just sync the changelog to trunk. I guess saucy cu2d is still broken similarly
[16:59] <Mirv> seb128: could you use a branch merge and cu2d the next time?
[16:59] <Mirv> for saucy
[17:01] <Mirv> the processes don't really work yet, in terms of how people should be instructed to utilize cu2d and ask for SRU:s.
[17:01] <seb128> Mirv, we would have, but we needed the SRU out and the CI team didn't have set up merges for the stable branch yet
[17:02] <seb128> Mirv, next cycle we should ensure that the mergers are working before branching
[17:02] <seb128> Mirv, it sucks to not be able to commit to stable series when you need to get SRU fixes out
[17:04] <Mirv> seb128: ok, that sucks. cu2d would work with a manual merge too, but realistically publishing of saucy SRU:s via cu2d has not had time reserved for it, and as mentioned we do not have a process of even requesting those SRU:s at the moment
[17:05] <Mirv> (unless broadening the amount of people who can 'push the button' in cu2d)
[17:13] <Laney> so the only thing really missing is pushing the branch in the libindicator case?
[17:27]  * Laney looks at bregma 
[17:28] <Mirv> Laney: yes, I pushed to lp:libindicator now. when we get some sort of request SRU process ongoing, the 13.10 branch changelog can also be fixed
[17:28] <Laney> ok
[17:32] <robert_ancell> charles, bug 1246812
[17:32] <ubot2> Launchpad bug 1246812 in indicator-datetime (Ubuntu) "Can open Evolution in greeter mode" [Undecided,New] https://launchpad.net/bugs/1246812
[17:32] <Laney> it's Ke$ha666 now
[17:38] <charles> robert_ancell, ta
[18:22] <robert_ancell> dbarth_, any update on testing remote login with guest fixes?
[18:24] <xclaesse> seb128, we fixed empathy not connecting to facebook upstream
[18:24] <xclaesse> it has been broken for weeks if not months :/
[18:24] <xclaesse> seb128, you really should pick https://git.gnome.org/browse/empathy/commit/?id=8b783df8f293a93405b591522f5289006286f1f4 into all ubuntu versions
[18:24] <seb128> xclaesse, works with uoa for me
[18:25] <xclaesse> seb128, it could still be working for a few people, depends on the facebook server version
[18:25] <seb128> xclaesse, do you know if there is a bug about that in launchpad?
[18:25] <xclaesse> they upgraded a part of the world
[18:26] <xclaesse> seb128, dunno about lp, but upstream is https://bugzilla.gnome.org/show_bug.cgi?id=707747
[18:26] <ubot2> Gnome bug 707747 in Auth client "Can not log into Facebook Chat using X-FACEBOOK-PLATFORM" [Normal,Resolved: fixed]
[18:26] <xclaesse> seb128,  the patch has been pushed to empathy git for gnome-3-4 up to master
[18:26] <seb128> xclaesse, ok, I'm going to do SRUs, thanks
[18:26] <xclaesse> seb128, not that 3.4 is the LTS version, and the commit a sligthly different than in other branches
[18:27] <xclaesse> *note
[18:27] <seb128> xclaesse, ok, I'm just going to take the git diff for each serie
[18:27] <xclaesse> seb128, please check if you can still connect your account without the patch
[18:28] <xclaesse> seb128, if it works it means your account hasn't been upgraded in facebook server, dunno why...
[18:28] <xclaesse> but it would be interesting the test the patched version then
[18:28] <xclaesse> to be sure it works in both cases
[18:28] <xclaesse> even if I don't see why it wouldn't
[18:30] <seb128> xclaesse, should it display an error in the UI if it fails to connect?
[18:31] <xclaesse> in empathy window, yes
[18:31] <xclaesse> you can launch empathy-accounts to check if your account is online
[18:35] <seb128> xclaesse, I've no error in empathy but it's not listing my fb contacts either
[18:35] <seb128> ok, empathy-accounts says that auth failed
[18:37] <xclaesse> seb128, if you re-set your presence to available it will probably retry to connect and the error will appear in the empathy window
[18:37] <seb128> xclaesse, indeed
[18:38] <xclaesse> I think it's broken for everyone now, they deployed their new server
[19:52] <radix> hello, what should I do if I'd like to report a bug in the GNOME3-Next PPA?
[20:03] <darkxst> radix, just use ubuntu-bug as normal
[20:05] <radix> hmm. I don't know which package to specify
[20:06] <darkxst> Laney, either way it is completely broken, there is no way anything would even run if it can't even pass the first test
[20:09] <radix> I guess I'll do gnome-shell...
[20:13] <radix> thanks darkxst
[20:17] <Laney> darkxst: correct, but now it needs to be fixed one way or another
[20:18] <darkxst> Laney, I could look at the failure, but don't have access to a powerpc machine
[20:19] <robru> mterry, https://code.launchpad.net/~robru/libfriends/noppc/+merge/193488
[20:54] <Laney> darkxst: me either (not an Ubuntu one anyway)
[20:54] <Laney> and it passes on Debian :(
[20:57] <darkxst> Laney, debian doesnt have the js17 branch though
[20:57] <darkxst> 1.36 passed on Ubuntu
[20:58] <darkxst> Laney, anyway so not much can do other than make tests non-fatal again
[20:58] <Laney> ah
[20:58] <Laney> let me try the 17 branch on the debian ppc porter
[20:59] <Laney> do a debdiff to make them non-fatal on ppc and I'll sponsor that
[20:59] <mterry> seb128, lp:~mterry/unity8/split
[21:27] <darkxst> Laney, can do, but probably wont be able to get to it until next week
[21:27] <Laney> k
[21:36] <seb128> cyphermox, Mirv, can you SRU ido/13.10: https://bugs.launchpad.net/ubuntu/+source/ido/+bug/1246536
[21:36] <ubot2> Launchpad bug 1246536 in ido (Ubuntu Saucy) "segfault in menu_hidden()" [High,In progress]
[21:36] <seb128> cyphermox, Mirv: today would be good, the new GTK is making that bug easier to trigger
[21:37] <seb128> new GTK has been SRU accepted earlier today
[21:37] <cyphermox> ae
[21:37] <seb128> cyphermox, Mirv: the commit is in 13.10 vcs and I've made the bug report SRU compliant already, it's just kicking an upload
[21:37] <cyphermox> ok
[21:39] <cyphermox> Mirv: I kick it now
[21:39] <Mirv> cyphermox: seb128: ok
[21:39] <Mirv> cyphermox: it seems it worked fine for indicator-appmenu you did earlier, nice to have SRU-cu2d:s ongoing
[21:50] <seb128> cyphermox, thanks
[21:50] <seb128> xclaesse, https://launchpad.net/ubuntu/+source/empathy/3.8.4-1ubuntu2 https://launchpad.net/ubuntu/+source/empathy/3.4.2.3-0ubuntu1.1
[21:53] <cyphermox> seb128: just waiting for it to get done building now...
[22:16] <seb128> cyphermox, Mirv: can you do another hud SRU to saucy to fix https://bugs.launchpad.net/ubuntu/+source/hud/+bug/1244688 ?
[22:16] <ubot2> Launchpad bug 1244688 in hud (Ubuntu Saucy) "/usr/lib/i386-linux-gnu/hud/hud-service:5:name_lost_cb:actually_do_call:do_call:ffi_call_SYSV:ffi_call" [Undecided,New]
[22:16] <seb128> cyphermox, Mirv: infinity just moved the previous one to -updates so we should be good to do another upload
[22:17] <cyphermox> ok
[22:19] <seb128> cyphermox, thanks
[22:24] <Mirv> seb128: it also fixes bug #1243654 it seems
[22:24] <ubot2> Launchpad bug 1243654 in hud (Ubuntu) "window-stack-bridge crashed with SIGSEGV in BamfWindow::windowId()" [High,Fix released] https://launchpad.net/bugs/1243654
[22:53] <seb128> Mirv, that one should be already fixed by the current SRU no?
[22:54] <TheMuso> c/
[23:01] <Mirv> seb128: no, the saucy SRU is 20131024 and seems to miss that, while 20131029 got uploaded to trusty with it
[23:02] <seb128> Mirv, ok, is that an issue?
[23:02] <Mirv> seb128: the bug should be SRUfied, not a problem otherwise
[23:02] <seb128> Mirv, ok, good ... do you guys do that? ;-)
[23:02] <seb128> the SRU is mostly "check that reports stop on e.u.c"
[23:03] <Mirv> seb128: ok, doing the beautifying before cyphermox published it
[23:03] <seb128> Mirv, thanks
[23:04] <cyphermox> what?
[23:06] <Mirv> cyphermox: applying SRU rules to the bug reports of hud you're about to publish
[23:08] <cyphermox> I wasn't about to touch hud
[23:09] <Mirv> cyphermox: done
[23:09] <cyphermox> ok you did?
[23:09] <Mirv> cyphermox: aha, you mentioned "ok" previously so I wasn't sure, but I can publish it now too since everything's ready.
[23:10] <cyphermox> yeah
[23:10] <cyphermox> perfect
[23:10] <Mirv> cyphermox: I did the bug beatifying, publishing next
[23:12] <Mirv> ah, or not, of course it's not in indicators stack so it hasn't had a rebuild. building and seeing how the tests go.
[23:55] <Mirv> seb128: hud now in saucy unapproved queue
[23:56] <seb128> Mirv, great, thanks