[00:00] <rickspencer3> I haven't noticed those
[00:00] <rickspencer3> popey, I'm not at the 'puter with that PPA installed atm
[00:00] <popey> ok np
[00:00] <rickspencer3> give me 20 minutes or so, and I'll see if I'm hitting those?
[00:00] <popey> thanks, just looking for confirmation that I'm not bonkers
[00:01] <rickspencer3> popey, I'm sure you are not bonkers
[00:01] <rickspencer3> those look like simple logic bugs
[00:01] <rickspencer3> I'll try to confirm for you
[00:01] <popey> ta
[00:51] <bschaefer> rickspencer3, looks like Trevinho ppa is ready to use :)
[00:51] <bschaefer> https://code.launchpad.net/~3v1n0/+recipe/unity-old-blur-test
[00:51] <rickspencer3> hi bschaefer
[00:51] <rickspencer3> oh nice
[00:51]  * rickspencer3 fetches netbook
[00:51] <bschaefer> rickspencer3, hello, and I tested the branch out, and its using the old (faster) blur
[00:55] <rickspencer3> bschaefer, this is the ppa, right?
[00:55] <rickspencer3> ppa:3v1n0/unity-test
[00:55] <bschaefer> rickspencer3, yeah should be
[00:56] <rickspencer3> ok, adding it
[00:57] <bschaefer> yup it is, just found the right page
[00:57] <rickspencer3> hmmm
[00:57] <bschaefer> not finding it?
[00:58] <rickspencer3> bschaefer, so I tried dist-upgrade, but it's not offering to upgrade unity
[00:58] <bschaefer> rickspencer3, did you update before hand?
[00:58] <rickspencer3> yah
[00:58] <rickspencer3> oh
[00:58] <rickspencer3> whoops
[00:58] <rickspencer3> it didn't fetch the upgrade from the ppa :)
[00:59] <bschaefer> oo well that'll cause a problem :)
[00:59] <rickspencer3> bschaefer, yeah, the i386 build isn't due for 2 hours :(
[00:59] <rickspencer3> oh well
[01:00] <rickspencer3> I'll try first thing in the morning
[01:00] <bschaefer> daang, sorry didn't notice that
[01:00] <rickspencer3> bschaefer, oh, no worries at all
[01:00] <bschaefer> rickspencer3, well it'll be testable later on today!
[01:01] <rickspencer3> bschaefer, yeah, I may give it a try later
[01:01] <rickspencer3> but I need to go do my Dad stuff
[01:01] <rickspencer3> :)
[01:01] <bschaefer> rickspencer3, cool, hopefully it'll fix the problem
[01:01] <bschaefer> rickspencer3, have fun! cya later
[01:01] <rickspencer3> bschaefer, well, this will just mean we know where the bug is from, right?
[01:01] <rickspencer3> someone will still need to actually fix it
[01:02]  * rickspencer3 presumes
[01:02] <bschaefer> rickspencer3, well Im not actually sure what Trevinho  was thinking I kind of just stepped in
[01:02] <bschaefer> but it'll be useful for debugging :)
[01:02] <rickspencer3> ah
[01:02] <rickspencer3> yeah, I think he believes he knows the change that broke it
[01:02]  * bschaefer isn't 100% what the overall problem was 
[01:02] <rickspencer3> so this ppa has that change reverted
[01:02] <bschaefer> yup!
[01:03] <bschaefer> oo right, yeah and we can just revert that change or make it use this blur method for netbooks
[01:03] <rickspencer3> something
[01:03] <bschaefer> yeah
[01:03] <rickspencer3> ok, I'll try later probably :)
[01:03] <rickspencer3> laters!
[01:03] <bschaefer> c ya!
[01:19] <cyphermox> kenvandine: still around?
[01:20] <cyphermox> robru: mterry: ^ ?
[01:31] <kenvandine> cyphermox, sort of
[01:32] <kenvandine> cyphermox, what's up?
[01:32] <cyphermox> kenvandine: got bschaefer to help, thanks
[01:32] <cyphermox> trying hard to not delay autopilot-qt more :/
[01:32] <kenvandine> cool
[01:32] <kenvandine> cyphermox, i really need autopilot-qt :)
[01:33] <cyphermox> I know ;)
[01:33] <kenvandine> my next todo item is to spend a couple days knocking out autopilot tests for gwibber :)
[01:33] <cyphermox> cool
[01:33] <cyphermox> as soon as this one commit lands I think we should be good with autopilot-qt
[01:33] <kenvandine> great!
[01:33] <cyphermox> it's getting late though, so perhaps I won't rerun and just wait until it starts
[01:34] <kenvandine> yeah
[01:34] <kenvandine> cyphermox, do you have any examples of qml apps using it?
[01:34] <kenvandine> i've mostly looked at what the phone shell did
[01:34] <kenvandine> but failed miserably at getting anything to run
[01:35] <kenvandine> qtcreator's ubuntu-sdk plugin has a thing for adding autopilot tests to your project
[01:35] <kenvandine> but that failed miserably too
[01:35] <kenvandine> all failed to import stuff in autopilot-qt
[01:36]  * kenvandine hopes when this lands qtcreators magic will just work :)
[02:17] <Crinos512> Greetings!
[02:25] <Crinos512> could some one here help me submit a "papercut" for the OneHundredPapercuts project?
[02:36] <darkxst> this has been sitting in the SRU queue for nearly a month! https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1128804
[02:36] <ubot2> Launchpad bug 1128804 in mutter "Update mutter/gnome-shell to 3.6.3" [Medium,In progress]
[03:23] <RAOF> darkxst: Is that urgent?
[03:24] <darkxst> RAOF, messagetray crash is incredibly annoying
[03:25] <darkxst> brings down the shell whenever people use empathy
[03:25] <RAOF> That sounds bad :)
[03:25] <darkxst> well shell still works, but the tray dies, and so does their conversation, so they restart shell
[03:26] <darkxst> the fact that GNOME even bothered to release a .3, should make it high priority I guess
[03:26] <RAOF> On the other hand, you'll notice that gnome-shell is only about half-way down the list, and there's no obvious priority; if you've got something that you think should be accepted quickly, you can ping the on-call SRU team member.\
[03:28] <RAOF> darkxst: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing - we're generally happy to process urgent things.
[03:33] <darkxst> RAOF, so what is considered urgent?
[03:34] <RAOF> darkxst: The question to ask is “Do you consider it urgent?”. If yes, give a ping. If your sense of urgency is not calibrated the same as ours, I'm sure we'll let you know gently :)
[03:35] <RAOF> darkxst: Also, small things are more easily dealt with than large things. And SRU bugs where we can talk to the uploader are easier to deal with if there are any niggles.
[03:40] <darkxst> sure, but I am hardly going to break out patches from a very small point release, which only fixes a few critical bugs
[03:43] <RAOF> MREs are also generally easy to accept
[03:44] <darkxst> RAOF, that is a MRE, although with one extra back-ported patch
[03:45] <darkxst> anyway will ping bdmurray, whenever thursday starts...
[04:27] <pitti> Good morning
[04:30] <RAOF> Huh. I've let my self drop out of ~ubuntu-sponsors.
[04:39] <darkxst> pitti, so logind not happening for R now?
[04:40] <pitti> darkxst: right
[04:40] <pitti> darkxst: well, it works (and I'll keep it working), but not by default
[04:40] <darkxst> what is blocking it? just unity?
[04:40] <pitti> darkxst: so gnome flavour might want to depend on libpam-systemd
[04:41] <pitti> darkxst: please see the blueprint and http://people.canonical.com/~pitti/tmp/cgroup-sd_booted.txt, there's quite a lot of packages which need migration
[04:41] <pitti> and adjustment of sd_booted(); I'll start on that upstream today
[04:41] <darkxst> pitti, well I havent tested against 3.6, but 3.8 was working very well
[04:42] <pitti> darkxst: I actually got my unity logind branch approved yesterday :)
[04:42] <pitti> so it should go in with the next automatic landing
[04:42] <RAOF> Ah. No colord sync from experimental, then.
[04:43] <darkxst> pitti, so if we were to land logind enabled packages on the ppa, we wouldnt horribly break anything
[04:44] <pitti> darkxst: no, I don't think so; I already have some in https://launchpad.net/~ubuntu-core-dev/+archive/logind, but I didn't continue that as the FFE was declined
[04:44] <pitti> darkxst: dbus and policykit-1 are the crucial ones, the others should work fine with a parallel CK as well
[04:45] <darkxst> yeh I built mine off that
[04:45] <darkxst> gnome-shell dies hard, if the base libs are using CK
[04:45] <darkxst> https://launchpad.net/~darkxst/+archive/logind/
[04:57] <darkxst> pitti, also, you were going to add a special case for gnome3 ppa bug reports to apport?
[04:58] <pitti> darkxst: ah, if you could file a bug against apport with the details of what should happen with those? i. e. which PPA, which project they should be filed against, etc.
[05:00] <darkxst> pitti, sure, we don't actually have a project as such, should set one up ;)
[05:14] <darkxst> pitti, https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1158119
[05:14] <ubot2> Launchpad bug 1158119 in apport "support for reporting bugs against gnome3-team ppa" [Undecided,New]
[05:15] <pitti> darkxst: thanks
[05:15] <pitti> darkxst: you want both crashes and bugs, right?
[05:15] <pitti> (crashes until the release, that is; after that, they'll only go to errors.ubuntu.com)
[05:15] <darkxst> pitti, yes
[05:16] <darkxst> yeh that is fine
[07:37] <didrocks> jibel: salut!
[07:46] <jibel> didrocks, bonjour
[07:46] <didrocks> ça va?
[07:47] <jibel> didrocks, ça va bien et toi ?
[07:47] <didrocks> ça va :)
[07:47] <jibel> didrocks, rien de cassé ce matin ?
[07:47] <didrocks> jibel: si, mais je répare…
[07:47] <didrocks> jibel: par contre, j'ai l'impression qu'il y a un petit truc sur le calc du nombre de régression
[07:47]  * didrocks vérifie sa théorie
[07:48] <jibel> didrocks, argh
[07:48]  * jibel va se chercher du café
[07:48] <didrocks> :)
[07:49] <didrocks> jibel: so, look at https://jenkins.qa.ubuntu.com/job/cu2d-unity-head-2.2check/116/console
[07:49] <jibel> didrocks, what is your theory?
[07:49] <didrocks> delta+0+0+7
[07:49] <didrocks> the thoery is wrong :)
[07:49] <didrocks> Tests for card 'intel' failed!
[07:49] <didrocks> theory*
[07:50] <didrocks> if I check our limits, for unity, it's 16 failures and 6 regressions
[07:51] <didrocks> however, if we look at the intel corresponding run: https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-intel/
[07:51] <didrocks> we have ("just" +2
[07:51] <didrocks> and 13 failures
[07:51] <didrocks> so normally, below the limit
[07:52] <didrocks> knowing that rev 129, the previous one, is indeed the one used in last publication
[07:52] <didrocks> so the jenkins numbers should be what we base on
[07:52] <jibel> didrocks, right and I really need coffee before looking into this
[07:52] <didrocks> go go! :-)
[08:01] <pitti> je ne le crois pas -- il neige à nouveau
[08:02] <pitti> c'est printemps !
[08:02] <jibel> chrisccoulson, hi, the modification of the proxy configuration on the testbed have fixed the multiple_geo_listeners tests
[08:02] <jibel> chrisccoulson, also, I increased the memory and don't see and OOM error this morning
[08:02] <jibel> s/and/any
[08:03] <jibel> pitti, it's spring here too, and guess what ... it's raining
[08:07] <didrocks> pitti: c'est le printemps ici, 8-10°C l'après-midi, grand soleil!
[08:08] <pitti> bah!
[08:08]  * didrocks ran yesterday juts wearing a tee shirt
[08:09]  * pitti mettre la neige à ville de didrocks
[08:09] <didrocks> pitti: roh! j'en ai déjà eu assez cette année :p
[08:09] <didrocks> jibel: things seems to be back to normal looking at the France weather map: http://france.meteofrance.com/france/accueil?xtor=AL-1
[08:09] <didrocks> rainy in your place
[08:09] <didrocks> clouds in Paris
[08:09] <didrocks> and sun for us \o/
[08:12] <jibel> didrocks, hm, I must verify something but I *think* I found what the problem is and we are probably mixing results to calculate the stats
[08:12] <didrocks> jibel: great! I'm excited that we can rerelease unity! :-)
[08:19] <jibel> didrocks, confirmed, we are storing all the history files in the same directory without distinction of the type of graphics card, so the stats are computed against the last results that have been submitted
[08:20] <didrocks> jibel: oh, interesting :)
[08:20] <jibel> didrocks, I'm wondering how we didn't notice that before
[08:21] <jibel> working on a fix
[08:21] <didrocks> jibel: yeah, seems we were just "lucky" to have higher number of failures and approx. the same number of failure per config
[08:21] <didrocks> thanks jibel :)
[08:31] <jibel> didrocks, there is no way to guess the type of system the test ran on from the result file. I'll add a parameter to specify a path to the directory containing history files and create one per configuration. Something like $BASEDIR/archive/$STACK/$SYSTEMID/
[08:31] <jibel> didrocks, where $SYSTEMID is an arbitrary string and the brand/model of the graphics card in our case
[08:34] <seb128> hey desktopers
[08:34] <seb128> lut jibel
[08:34] <didrocks> hey jibel
[08:34] <didrocks> seb128: ;)
[08:34] <jibel> bonjour seb128
[08:34] <didrocks> jibel: ok, sounds good to me
[08:34] <jibel> morning didrocks :)
[08:34] <didrocks> jibel: long time no see!
[08:34] <seb128> lut didrocks ;-)
[08:35] <pitti> bonjour seb128
[08:35] <seb128> pitti, salut, ça va bien ?
[08:35] <didrocks> jibel: ok, also, we need to ensure that when we "force" the publish, we rerun head as well btw
[08:35] <seb128> pitti, ton rhume ?
[08:35] <pitti> seb128: je vais mieux que hier, merci
[08:35] <pitti> (qu'hier ?)
[08:35] <seb128> pitti, ah, tant mieux
[08:35] <didrocks> jibel: because if you have QA in manual publication mode, then publish it (force mode), then run indicators
[08:36] <didrocks> indicators will still pick the old "manual publishing" mode for the QA stack
[08:36] <didrocks> as we didn't run head
[08:36] <seb128> pitti, "que hier" is correct
[08:36] <didrocks> and so the trigger to update the file didn't work
[08:36] <seb128> pitti, "qu'hier" works too
[08:58] <tkamppeter> pitti, hi
[09:01] <jibel> didrocks, about bug 1155510, did you commit the fix ?
[09:01] <ubot2> Launchpad bug 1155510 in Canonical Upstream To Distro "buildsource-chroot failed with lock failure on /etc/group or /etc/passwd" [Undecided,Fix released] https://launchpad.net/bugs/1155510
[09:04] <Laney> hey thar
[09:05] <didrocks> jibel: oh no indeed, feel free to do it :)
[09:05] <jibel> didrocks, k, I'll do it
[09:05] <didrocks> thanks
[09:08] <seb128> Laney, hey, how are you?
[09:09] <Laney> good thank you - patch piloting later ;-)
[09:09] <Laney> how are you?
[09:10] <seb128> I'm good thanks
[09:10] <seb128> I was going to do some NEW review and a bit of sponsoring as well
[09:10] <Laney> cool, I scheduled my slot for this afternoon
[09:20] <BigWhale> Good Morning everyone.
[09:21] <seb128> hey BigWhale
[09:37] <chrisccoulson> jibel, thanks for that. the results are looking much better now :)
[09:38] <jibel> chrisccoulson, indeed, 3 failures over 44,426 tests is not bad :)
[09:39] <chrisccoulson> jibel, although, i'm a bit confused about https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/92/ARCH=amd64,label=adt/testReport/junit/toolkit.components.search.tests/xpcshell/test_nocache_js/. i thought i'd fixed that with http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/1618
[09:39] <chrisccoulson> oh
[09:39] <chrisccoulson> hang on, it's a different test
[09:40] <chrisccoulson> test_json_cache.js vs test_nocache.js
[09:40] <chrisccoulson> heh
[09:40]  * chrisccoulson grabs spectacles
[09:42] <jibel> didrocks, https://code.launchpad.net/~jibel/cupstream2distro/history_per_systemid/+merge/154641
[09:43] <didrocks> jibel: will review in a seconde
[09:44] <jibel> didrocks, I'll split the archive per arch but won't touch the existing result files for the moment
[09:45] <BigWhale> When is the last date for things to get uploaded into Raring?
[09:45] <Laney> depends what kind of thing
[09:46] <BigWhale> bug fixes
[09:46] <BigWhale> no UI changes
[09:46] <Laney> still got a few weeks
[09:46] <Laney> a week or so before release is a hard freeze
[09:47] <BigWhale> ok I'll aim for March 28th - Final Beta Freeze
[09:51] <tkamppeter> pitti, around?
[09:55] <pitti> hello tkamppeter
[10:05] <tkamppeter> pitti, I have a problem with Upstart.
[10:06] <tkamppeter> pitti, on my laptop running Raring there are the three Upstart-controlled services avahi-daemon, cups, and cups-browsed.
[10:08] <tkamppeter> pitti, starting cups requires avahi-daemon being already started and starting cups-browsed also requires avahi-daemon being already started and in addition cups already started OR run level 2, 3, 4, 5.
[10:09] <tkamppeter> pitti, if I start the three services manually, first avahi-daemon and then cups and cups-browsed (in arbitrary order), the ~10 queues from my remote print server get all available locally as expected, but now the problem:
[10:10] <pitti> btw, please discuss upstart problems on #ubuntu-devel; jodh and xnox hang out there, our upstart maintainers
[10:10] <pitti> (well, they hang out here as well)
[10:10] <tkamppeter> pitti, if I boot the machine either no queues at all or some queues (always the ones whose names are in the beginning of the alphabet, are available. To get them all available I have to manually reestart cups-browsed.
[10:11] <pitti> tkamppeter: it sounds like a race condition that cups is trying to talk to avahi before it's really started?
[10:11] <tkamppeter> pitti, was Upstart not your baby in the beginning?
[10:11] <pitti> no, never :)
[10:12] <pitti> I've been promoting systemd for like two years (which incidentally also avoids this kind of race)
[10:12] <seb128> pitti likes upstart so much that's he's pushing for us to replace it for 2 years :p
[10:12] <seb128> heh, got snapped there :p
[10:12] <pitti> tkamppeter: I think what needs to happen there is that either avahi emits some "I am ready" upstart signal which cups waits on, or cups has to repeatedly try and talk to avahi until its ready
[10:13] <pitti> jodh, xnox ^ Please correct me if I'm wrong
[10:13] <tkamppeter> pitti, seb128, I would love to switch to systemd.
[10:14] <pitti> well, it's not that I don't like upstart; I just don't like having three init systems in the Linux world
[10:14] <tkamppeter> pitti, xnox, jodh, another thing is that avahi-discover shows all remote queues.
[10:14] <ogra_> pitti, three ?
[10:14]  * ogra_ thinks there are more like ten
[10:15] <GunnarHj> seb128: Bug 1157188 doesn't sound nice.
[10:15] <ubot2> Launchpad bug 1157188 in gnome-control-center (Ubuntu) "gnome-control-center crashed with SIGSEGV in g_str_hash()" [Medium,New] https://launchpad.net/bugs/1157188
[10:16] <ogra_> (and 9 of them have a sane upstream)
[10:16] <tkamppeter> pitti, as CUPS does not pick up the remote queues by itself, but cups-browsed does and then passes them on to CUPS, it seems that cups-browsed starts too early, probably before avahi-daemon is ready. cups-browsed itself waits for CUPS being ready.
[10:16] <seb128> ogra_, let's not start a troll today, it's not friday :p
[10:16] <didrocks> jibel: how do you deal with previous results then?
[10:16] <tkamppeter> xnox, jodh, ^^
[10:16] <seb128> GunnarHj, hum, is that a side effect of your recent changes?
[10:16] <didrocks> jibel: like the diff will fail a previous one?
[10:16] <pitti> tkamppeter: yeah, or that way around
[10:17] <tkamppeter> xnox, jodh, pitti, for an external daemon/app it is easy to check whether CUPS is ready, but is there a way to check whether avahidaemon is ready?
[10:17] <GunnarHj> seb128: That was my thought as well, but I don't think so. Even if that patch affects the language list in user accounts, it doesn't touch the user account files directly.
[10:18] <pitti> tkamppeter: usually, check if you can connect to its D-BUS interface
[10:18] <seb128> GunnarHj, well, look at the stacktrace
[10:18] <seb128> GunnarHj,   cc_common_language_get_initial_languages () at cc-common-language.c:634
[10:18] <seb128> GunnarHj, is where the error is
[10:18] <ogra_> seb128, i was practicing for tomorrow :)
[10:18] <seb128> GunnarHj, "        name = 0x0"
[10:19] <seb128> GunnarHj, I guess it's not guarded against null values
[10:19] <seb128> GunnarHj, not sure if having name = NULL is valid there...
[10:19] <tkamppeter> xnox, jodh, pitti, strange is also that if I manually start the three services on one command line, via "sudo start avahi-daemon; sudo start cups; sudo start cups-browsed" I always get the queues correctly set up. I can reproduce the problem only by booting.
[10:20] <GunnarHj> seb128: You are far too fast for me. ;-)
[10:20] <pitti> tkamppeter: that one starts them serially; I guess at boot they start in parallel?
[10:20] <seb128> GunnarHj, the XsessionError has
[10:20] <seb128> (gnome-control-center:5411): common-cc-panel-WARNING **: Error calling GetAll() when retrieving properties for /org/freedesktop/Accounts/User999: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.freedesktop.DBus.Properties' on object at path /org/freedesktop/Accounts/User999
[10:20] <tkamppeter> xnox, jodh, pitti, naturally I did "sudo stop cups-browsed; sudo stop cups; sudo stop avahi-daemon" before and waited some seconds.
[10:20] <pitti> tkamppeter: or perhaps the network is not up yet, etc.
[10:20] <seb128> GunnarHj, ^ I guess that's part of the issue
[10:21] <tkamppeter> pitti, how do I assure that?
[10:21] <pitti> tkamppeter: start them in parallel?
[10:22] <pitti> tkamppeter: (sudo start avahi-daemon &); (sudo start cups-browsed &)
[10:22] <pitti> and try a few times
[10:22] <pitti> tkamppeter: but I think you can reproduce the problem better by starting cups first, and then avahi
[10:22] <pitti> err, -browsed
[10:22] <seb128> GunnarHj, let me know if I can help you to debug, those are just my random thoughts from a quick look
[10:22] <pitti> tkamppeter: to check whether cups-browsed picks up avahi signals after avahi starts, but cups-browsed is already running
[10:24] <GunnarHj> seb128: Will do. Thanks.
[10:24] <seb128> GunnarHj, yw, thanks for pointing the bug ;-)
[10:26] <jibel> didrocks, i could identify which result belongs to which system in the history from the path of the test in the junit file. Then copied the previous results in history/$stack/$card
[10:26] <jibel> didrocks, so when we'll deploy the patch it will compare the right results
[10:27] <didrocks> jibel: ok, approving then, feel free to merge
[10:28] <jibel> didrocks, cooll, thanks
[10:29] <tkamppeter> pitti, both "sudo start avahi-daemon & sudo start cups & sudo start cups-browsed &" and "(sudo start avahi-daemon &); (sudo start cups &); (sudo start cups-browsed &)" leads to a correct queue list, even having cups-browsed starting before the two others.
[10:29] <pitti> tkamppeter: so I guess it's somethign else then, like the network not being up yet?
[10:29] <GunnarHj> seb128: /org/freedesktop/Accounts/User999 That path is a concatenation with the user id. Do you know if accountsservice works with four digits also when the user id is < 1000?
[10:30] <pitti> Trevinho: OOI, does https://code.launchpad.net/~pitti/unity/logind/+merge/154029 need to be set to "approved", or is it just waiting for the automatic tests to kick in?
[10:31] <xnox> tkamppeter: please increase upstart logging and send the logs in from "bad" boot ( see http://upstart.ubuntu.com/cookbook/ ). Both cups* jobs do depend on "started avahi-daemon" which should mean "avahi is fully started and operational". Clearly you say that's not the case in practice. The best way to improve things is to add a post-start in avahi-daemon job, which tries to talk to avahi (over dbus?!) and wait until it's really there.
[10:31] <xnox> this will delay the "started avahi-daemon" event until it is appropriate.
[10:32] <Trevinho> pitti: yeah... marking it now
[10:33] <seb128> GunnarHj, the number of digits shouldn't make a difference
[10:34] <seb128> GunnarHj, not sure what's the id range we use, I think we take it from /etc/login.defs
[10:34] <GunnarHj> seb128: Well, it would if the correct path is /org/freedesktop/Accounts/User0999
[10:34] <GunnarHj> seb128: right?
[10:34] <seb128> GunnarHj, you can probably add an user with uid 999 and look over d-feet
[10:35] <GunnarHj> d-feet?
[10:35] <seb128> GunnarHj, my d-feet has a user123
[10:35] <seb128> so I don't think it's 0 padded to 4 digits
[10:35] <seb128> GunnarHj, d-feet is a nice tool to interact with dbus services
[10:35] <pitti> Trevinho: thanks
[10:35] <seb128> GunnarHj, you can see all the services/objects on the bus and trigger their methods, query their properties, etc
[10:36] <seb128> GunnarHj, sudo apt-get install d-fett
[10:36] <seb128> d-feet
[10:36] <GunnarHj> seb128: Ok. It was a first theory. Will check out d-feet.
[10:47] <jodh> tkamppeter: confused - you say that cups-browsed requires cups, yet also that cups requires cups-browsed for remote queues. Circular dependency? The current cups*.conf look overly complex to me too: they don't need to specify 'filesystem' at all as they already get that from 'started avahi-daemon'.
[11:00] <tkamppeter> xnox, in which file do I set the debug loging mode of upstart? I did not find any hint about a central config file for it.
[11:01] <jodh> tkamppeter: add '--debug' to the kernel command line to enable it for the whole boot.
[11:01] <xnox> tkamppeter: just boot with --debug or --verbose kernel cmd line arg.
[11:01] <tkamppeter> jodh, in Upstart terms cups-browsed needs CUPS running. CUPS works without cups-browsed (but then does not have remote queues).
[11:07] <jodh> tkamppeter: so, which do you want to start first?
[11:11] <tkamppeter> xnox, jodh, which are the relevant log files?
[11:11] <jodh> tkamppeter: for --debug, dmesg/syslog output.
[11:11] <tkamppeter> jodh, cups-browsed should be started after cups.
[11:12] <jodh> tkamppeter: so, is there a reason cups-browsed cannot specify 'start on started cups'?
[11:14] <tkamppeter> jodh, there was "(started cups or runlevel [2345])" before and I replaced it by "started cups" but this did not solve the problem.
[11:20] <jodh> tkamppeter: why do you need the 'or runlevel' in cups.conf for the start on at all? If cups-browsed needs cups to be running, the condition should be simply 'start on started cups'. If this doesn't work, there is a problem with cups not being "ready" when it starts. But that is a problem for the cups job to solve.
[11:20] <jodh> tkamppeter: ...and indeed looking at cups.conf shows some sort of hack to "wait" for the daemon to be ready. Maybe that hack is incorrect?
[11:22] <pitti> jodh, tkamppeter: NB that cups.init does wait for cups to be really ready
[11:22] <jodh> tkamppeter: by having *both* cups.conf and cups-browsed.conf specify 'or runlevel', a race is introduced.
[11:23] <jodh> tkamppeter: if cups-browsed specifies 'start on started cups', what problem do you see?
[11:24] <tkamppeter> pitti, jodh, xnox, someone of you know for what the "or runlevel ..." in the scripts for cups and cups-browsed are good for?
[11:25] <tkamppeter> jodh, with "or runlevel ..." removed in the cups-browsed scriptthen I have the same problem.
[11:25] <pitti> tkamppeter: no, I don't
[11:25] <xnox> tkamppeter: server-like installations where there is no dbus available for example? but in that case the pre-start script should check it's events, check if it's starting on runlevel and then it should bail out if dbus is not running yet.
[11:26] <xnox> (first it's should be its)
[11:27] <tkamppeter> xnox, then I assume that "or runlevel ..." in cups-browsed is wrong, as cups-browsed without cups does not make sense.
[11:27] <tkamppeter> xnox, but I already tested cups-browsed without "or runlevel ..." and it still shows the problem.
[11:27] <xnox> tkamppeter: your conclusion is logically correct.
[11:27] <xnox> tkamppeter: how does one check that avahi is really there?
[11:27] <tkamppeter> xnox, I booted with --debug, which logfiles I have to look into now?
[11:28] <xnox> tkamppeter: something with loads of upstart / init events logs. I think it's /var/log/boot/log or syslog or dmesg can't remember.
[11:28] <tkamppeter> xnox, in cups-browsed I have done "start on started avahi-daemon". Is this not correct?
[11:29] <xnox> tkamppeter: so "started avahi-daemon" will be emitted as soon as avahi-daemon forks twice, but by that time it might not yet be ready and doesn't provide "ambient networking services".
[11:29] <xnox> that is, it did start but it ain't ready yet.
[11:29] <jodh> xnox: dbus is installed on the server now I thought?
[11:30] <xnox> tkamppeter:  thus see my recommendation about add a post-start script that waits & checks avahi to be _really_ there e.g. return a default lookup or something like that. You can test with:
[11:30] <xnox> post-start script
[11:30] <xnox>     sleep 10
[11:30] <xnox> end script
[11:31] <xnox> in the /etc/init/avahi-daemon.conf (or put that into avahi-daemon.override to keep .conf pristine)
[11:32] <xnox> that way we know if avahi is the culprit here (double forking before being ready to provide remote printers)
[11:33] <tkamppeter> xnox, I am trying now ...
[11:33] <xnox> jodh: `seeded-in-ubuntu dbus` does tell me it's available everywhere.
[11:34] <xnox> jodh: but dbus is not in ubuntu-core so one can have a working & fully functional system without dbus http://cdimages.ubuntu.com/ubuntu-core/daily/current/raring-core-amd64.manifest
[11:35] <jodh> xnox: ok, that prolly explains the 'or runlevel' in dbus.conf, but not in dbus-browsed.conf.
[11:36] <xnox> jodh: s/dbus/cups/
[11:36] <jodh> xnox: right :
[11:37]  * jodh thinks we should put more comments into such jobs to aid understanding.
[11:54] <tkamppeter> xnox, jodh, pitti, I booted twice now with the "sleep 10" in the post-start of avahi-daemon, and once I got really all queues, a second time I got five queues, before I got between 0 and 3 queues.
[11:54] <tkamppeter> xnox, jodh, pitti, so this gives a slight improvement.
[11:55] <pitti> tkamppeter: well, what does cups-browsed expect from avahi?
[11:55] <pitti> tkamppeter: you can't assume that avahi knows about all broadcast printers right after it started
[11:55] <jodh> and surely devices on the network will come and go anyway?
[11:55] <pitti> tkamppeter: if they send info about themselves after 30 seconds or so, then cups-browsed just has to listen to new printers popping up?
[11:55] <pitti> that too
[11:57] <tkamppeter> pitti, cups-browsed is listening all the time. If I create a new printer on the remote server, cups-browsed picks it up immediately.
[11:58] <pitti> hm, no idea then :(
[11:58] <seb128> pitti, félicitation pour ton premier commit à unity ;-)
[11:58] <tkamppeter> pitti, if I restart cups on the remote server, all queues appear immediately on my Raring laptop.
[11:59] <pitti> seb128: merci beaucoup !
[11:59] <pitti> seb128: actually, my name is in the debian changelog several times, but that was from the old days where we still actually did uploads :)
[11:59] <seb128> hehe
[11:59] <seb128> yeah, first "autocommit/landing" ;-)
[11:59] <pitti> tkamppeter: so perhaps that means that printers don't re-announce themselves often enough? I don't know for sure how that protocol works
[11:59] <pitti> seb128: oui
[12:00] <pitti> thanks to Trevinho for his fast an thorough review
[12:00] <pitti> I must say, this is quite a nice experience
[12:00] <pitti> (with merge proposals, fast reviews, automatic tests, etc.)
[12:00] <Trevinho> pitti: thanks :)
[12:00] <tkamppeter> pitti, do you know who is the avahi expert here?
[12:01] <pitti> tkamppeter: I don't think we have a real "expert" in the Ubuntu community; Sjoerd Simons might have an idea
[12:11] <tkamppeter> pitti, how can I contact Sjoerd Simons?
[12:12] <Laney> try #debian-gnome on irc.oftc.net
[12:13] <pitti> yes, he (sjoerd) is online on oftc
[12:13] <pitti> tkamppeter: sjoerd is also here on freenode, might be easier
[12:13] <Laney> ah, seems so
[12:14] <tkamppeter> pitti, in which channel(s)
[12:15] <pitti> tkamppeter: /whois sjoerd doesn't say; just /query him?
[13:38] <mterry> kenvandine, disabling tests to fix ftbfs! tsk tsk (qml-friends)
[13:45] <kenvandine> mterry, just the one... not because it fails because of a race in starting the tests
[13:45] <kenvandine> i am working on fixing it right now :)
[14:00] <jodh> pitti: is 'Bug' the only apport ProblemType that will have ui set in add_info() and hence is the only interactive ProblemType?
[14:01] <pitti> jodh: no, that shouldn't make a difference
[14:01] <pitti> jodh: however, it is higly discouraged to ask interactive questions for crashes
[14:02] <pitti> up to the point where mpt and ev will come haunt you with big and painful devices if you do it
[14:03] <jodh> pitti: so a hook should only ask interactive questions "if report.get('ProblemType', '') == 'Bug' and ui:" right?
[14:03] <pitti> jodh: preferably, yes; I might even enforce that in the future by not passing ui
[14:04] <pitti> i. e. ui == None for Type == Crash
[14:04] <jodh> pitti: right, thanks.
[14:06] <jodh> pitti: so, are all non-Bug ProblemType bugs private by default, or just crashes?
[14:07] <pitti> just crashes
[14:08] <jodh> pitti: hmm. so the 'ideal' hook would only prompt for 'Bug' and if ui is set, should maybe auto-attach files if ProblemType == 'Crash', but what about attaching files containing potentially sensitive info for the other ProblemTypes? Are there any recommendations written down or a skeleton hook to cover all these scenarios maybe?
[14:09] <mpt> pitti, "I might even..." = fixing bug 1084979?
[14:09] <ubot2> Launchpad bug 1084979 in apport (Ubuntu) "Submitting error report asks confounding questions" [Medium,Triaged] https://launchpad.net/bugs/1084979
[14:09] <mpt> I don't mind asking questions, pre-release. :-)
[14:09] <mpt> (and I guess 'Bug' == pre-release, right?)
[14:11] <rickspencer3> hi Trevinho
[14:11] <rickspencer3> sorry, I went to sleep last night ;)
[14:11] <rickspencer3> Trevinho, I saw your email, but wasn't 100% certain what you wanted me to do
[14:11] <pitti> mpt: well, you can submit bugs post-release too, but at least those are user triggered and don't pop up automatically
[14:12] <rickspencer3> seb128, thanks for getting that UG bug fixed, sorry I commented on the wrong bug report
[14:12] <seb128> rickspencer3, hey, no worry, sorry it took me so long to get back to it
[14:13] <mpt> pitti, sure, I was thinking only of automatically triggered ones
[14:18] <rickspencer3> didrocks, I'm trying to upgrade but apt-get update says the i386 ppa for experimental-prevalidation is not found ... should I assume that it's still building?
[14:18] <seb128> rickspencer3, can you pastebin the exact error?
[14:19] <rickspencer3> W: Failed to fetch https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation/dists/raring/main/binary-amd64/Packages  The requested URL returned error: 404 Not Found
[14:19] <rickspencer3> seb128, ^
[14:22] <seb128> rickspencer3, what do you have in your sources.list?
[14:22] <GunnarHj> seb128: Prepared MP to fix bug 1157188.
[14:22] <ubot2> Launchpad bug 1157188 in gnome-control-center (Ubuntu) "gnome-control-center crashed with SIGSEGV in g_str_hash()" [Medium,In progress] https://launchpad.net/bugs/1157188
[14:23] <seb128> GunnarHj, I will have a look, thanks
[14:23] <seb128> rickspencer3, seems to me that you have a ~ in front of "ubuntu-unity" that you shouldn't have
[14:24] <seb128> rickspencer3, the correct source should be "deb http://ppa.launchpad.net/ubuntu-unity/experimental-prevalidation/ubuntu raring main"
[14:24] <rickspencer3> hey seb128
[14:25] <rickspencer3> ok, checking
[14:25] <rickspencer3> seb128, fwiw, it was working fine for days
[14:25] <seb128> rickspencer3, ok, weird, maybe a network issue then? (works fine for me, but I'm on i386 and not amd64)
[14:26] <rickspencer3> seb128, I'm on i386 as well
[14:26] <rickspencer3> seb128, does this look right?
[14:26] <rickspencer3> https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation
[14:27] <seb128> rickspencer3, the error you copied says "raring/main/binary-amd64/Packages  The requested URL returned error: 404 Not Found"
[14:27] <rickspencer3> oops
[14:27] <seb128> rickspencer3, notice the amd64
[14:27] <rickspencer3> lol
[14:27] <rickspencer3> Err https://launchpad.net raring/main i386 Packages
[14:27] <rickspencer3>   The requested URL returned error: 404 Not Found
[14:27]  * seb128 is really confused
[14:28] <rickspencer3> W: Failed to fetch https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation/dists/raring/main/binary-i386/Packages  The requested URL returned error: 404 Not Found
[14:28] <rickspencer3> seb128, my bad, I pasted the wrong error
[14:29] <seb128> rickspencer3, does browsing http://ppa.launchpad.net/ubuntu-unity/experimental-prevalidation/ubuntu/dists/raring/main/binary-i386/Packages works for you?
[14:30] <rickspencer3> seb128, yeah
[14:30] <seb128> rickspencer3, can you "grep prevalidation /etc/apt/* -r" and copy that?
[14:31] <rickspencer3> seb128, http://paste.ubuntu.com/5634180/
[14:32] <seb128> rickspencer3, seems like you have the entry duplicates, a buggy version in your /etc/apt/sources.list and the correct in /etc/apt/sources.list.d/ubuntu-unity-experimental-prevalidation-raring.lis
[14:33] <seb128> rickspencer3, delete the sources.list one (it has a ~ and lacks "/ubuntu" after the "prevalidation")
[14:33] <seb128> rickspencer3, not sure how/when you got the buggy one, but you still have a correct one next to it so that's why it works
[14:33] <rickspencer3> seb128, gotcha
[14:34] <seb128> maybe you had the W: before and just didn't notice ;-)
[14:34] <rickspencer3> seb128, who knows
[14:34] <rickspencer3> I probably just mistyped it last week or something
[14:35]  * rickspencer3 shrugs
[14:35] <rickspencer3> thanks seb128
[14:35] <seb128> yw ;-)
[14:35]  * rickspencer3 dist-upgrades
[14:40] <kenvandine> mterry, test fixed and uploaded :)
[14:44] <mterry> kenvandine, awesome.  So all three qt packages don't seem to run tests, despite having them.  Do you know what the story is there?
[14:44] <kenvandine> i don't
[14:44] <kenvandine> but i am checking
[14:45] <kenvandine> the other bug you mentioned for qtdeclarative5 has been fixed in the bzr branch of the packaging
[14:45] <kenvandine> but never uploaded
[14:45] <kenvandine> i am testing that now
[14:53] <didrocks> rickspencer3: sorry, was doing some exercice, is everything all right now?
[14:54] <rickspencer3> didrocks, all is well
[14:54] <rickspencer3> I was being a dope
[14:54] <rickspencer3> and seb128 helped me out :)
[14:54] <didrocks> don't be so hard on yourself :)
[14:54] <rickspencer3> didrocks, the dash is working well for me
[14:54] <rickspencer3> jono said he was getting weird resets, though
[14:55] <didrocks> rickspencer3: resets?
[14:55] <rickspencer3> other than that, I hear there is some slowness here and then, but generally seems to be in good shape
[14:55] <rickspencer3> didrocks, yeah, unity was just restarting for him yesterday
[14:55] <rickspencer3> I suspect a configuration problem, personally
[14:55] <didrocks> rickspencer3: oh, right a crash, let's see once he's online if he got a backtrace
[14:55] <rickspencer3> but, what do I know?
[14:55] <didrocks> rickspencer3: well, can be machine/racy thing
[14:55] <didrocks> didn't get a crash
[14:55] <didrocks> but let's see
[14:56] <didrocks> rickspencer3: still some missing feature, will be tight to get it on time though. Let's see how it goes
[14:56] <rickspencer3> didrocks, how come I'm not getting wikipedia results today?
[14:56] <rickspencer3> I loved those
[14:56] <rickspencer3> :)
[14:56] <rickspencer3> I just seem to be getting apps, files/folder, and music
[14:57] <rickspencer3> oh, there they are!
[14:57] <rickspencer3> had to scroll down
[14:57] <rickspencer3> and they took a while to come in
[14:57] <didrocks> rickspencer3: yeah, I think the server is slow to answer
[14:57] <rickspencer3> wow, there is actually a good reason to for me to use full screen mode now!
[14:57] <didrocks> as they are the ones telling "starts those scopes"
[14:57] <didrocks> ahah :)
[14:57] <didrocks> rickspencer3: also, for testing, as we don't have recommendations yet
[14:57] <didrocks> rickspencer3: we recommends all scopes
[14:57] <didrocks> so ~30 python process starting the first time
[14:57] <rickspencer3> uh
[14:57] <didrocks> you can see what happens :)
[14:58] <rickspencer3> full screen button seems to be gone?
[14:58] <didrocks> rickspencer3: top left corner?
[14:58] <didrocks> maximize?
[14:58] <rickspencer3> didrocks, ah, there it is
[14:58] <rickspencer3> nice
[14:58] <jcastro> yeah I noticed that just now too didrocks
[14:58] <jcastro> it does disappear sometimes
[14:58] <jcastro> but I can't figure out why/how
[14:58] <jcastro> and then it's there
[14:58] <didrocks> jcastro: the maximize button?
[14:58] <jcastro> all three buttons
[14:59] <jcastro> sometimes all three just don't show up
[14:59] <didrocks> interesting
[14:59] <rickspencer3> didrocks, so, apps, files/folders, and music run without waiting for the server?
[14:59] <didrocks> rickspencer3: yeah, they are "default scopes"
[14:59] <rickspencer3> ok
[14:59] <didrocks> the default ones are always giving results
[14:59] <rickspencer3> good to know
[14:59] <didrocks> (photos as well)
[14:59] <didrocks> and soon the social one I guess
[15:00] <rickspencer3> I told #ubuntu-news I'd give them a couple of paragraphs about the new dash :)
[15:00] <tkamppeter> xnox, jodh, pitti, I have found the cause of the problem. There was a bug in cups-browsed. I will upload cups-filters 1.0.31 with the fix soon, but I discovered another problem: Upstart does not shut down cups-browsed cleanly. If you correctly shut it down with Ctrl+C or signal 15 all local queues are removed, but on an actual system shutdown this does not take place, either it gets shut down by "kill -9" or between the signal and the
[15:00] <tkamppeter>  complete halt of the system there is not enough time to remove the queues. What should I do then.
[15:01] <rickspencer3> didrocks, I don't seem to be getting photos
[15:01] <rickspencer3> anything I can do to test that before logging a bug?
[15:01] <rickspencer3> oops, call
[15:01] <rickspencer3> bbl
[15:01] <didrocks> rickspencer3: hum, updated to latest I guess, did you apt-get install --fix-policy?
[15:02] <rickspencer3> didrocks, I did not run that
[15:02] <rickspencer3> can I go ahead and do it now, even though I already dist-upgraded today?
[15:02] <didrocks> rickspencer3: yeah, tell me what you see
[15:03] <didrocks> rickspencer3: basically, it's ensuring all the recommends are installed as expected
[15:03] <didrocks> so back to "distro default" in terms of recommends
[15:04] <rickspencer3> didrocks, ok, it has some scopes it wants me to install
[15:04] <rickspencer3> and some qt4 stuff
[15:04] <rickspencer3> I can go ahead and run it after this call if you think it will help
[15:04] <didrocks> rickspencer3: yep :)
[15:04] <didrocks> rickspencer3: then logout/login
[15:04] <rickspencer3> didrocks, ok, will do later
[15:04] <didrocks> rickspencer3: keep me posted :)
[15:09]  * rickspencer3 wonders why he is getting qt4 goo?
[15:09] <didrocks> rickspencer3: because of the ubuntu one app?
[15:09] <didrocks> maybe you uninstalled in the past some of the qt4 recommends
[15:10] <rickspencer3> didrocks, yeah, I think I needed to to make the sdk work
[15:19] <cyphermox> Laney: https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1158354
[15:19] <ubot2> Launchpad bug 1158354 in evolution-data-server "[SRU] [MRE] evolution-data-server 3.6.4" [Undecided,New]
[15:20] <Laney> cyphermox: nice - and evo itself I presume?
[15:21] <cyphermox> Laney: I'll file a separate bug for it
[15:21]  * Laney nod
[15:26] <jodh> tkamppeter: Upstart will send SIGTERM (15) to cups-browsed when it should be stopped. However, if it doesn't react in time (default 5 seconds), Upstart will send SIGKILL (9). You can change this behaviour using 'kill signal' and 'kill timeout'. See init(5) for details.
[15:30] <tkamppeter> jodh, for me it is strange that cups-browsed takes more than 5 sec to shut down. If I start it on the command line and press Ctrl+C it takes less than 1 sec to remove all queues and exit.
[15:31] <jodh> tkamppeter: maybe strace it?
[15:31] <tkamppeter> jodh, is it possible that it does not get sent a signal to shut down and so it keeps running until the kernel kills itself and returns to the BIOS?
[15:31] <jodh> tkamppeter: no.
[15:33] <tkamppeter> jodh, assuming cups-browsed needs 1 sec to shut down. Is it possible that it gets the signal only 0.5 sec before the system shuts down and so cups-browsed's shut down stays incomplete (some queues not removed)?
[15:36] <jodh> tkamppeter: why don't you change cups-browsed.conf's 'stop on' to 'stop on foo' or something and then 'initctl emit foo' and see how long it takes to stop.
[15:40] <tkamppeter> jodh, tried this, less than a sec.
[15:43] <rickspencer3> Trevinho, around?
[15:43] <Trevinho> rickspencer3: yep
[15:43] <rickspencer3> so I installed your ppa last night
[15:43] <rickspencer3> I just dist-upgraded, but it didn't ask if I wanted to install a new unity
[15:43] <Trevinho> rickspencer3: yes, I sent you a mail about it
[15:44] <jodh> tkamppeter: in which case, try putting a sleep in /etc/init.d/sendsigs to rule out any interaction between the SysV side of the world.
[15:44] <rickspencer3> Trevinho, well, I didn't grock what you wanted me to do
[15:44] <Trevinho> rickspencer3: it's because I didn't include the ubuntu version on the package.. :(
[15:44] <Trevinho> rickspencer3: so, you can download manually the packages or just wait for the new ppa rebuild
[15:44] <rickspencer3> Trevinho, yeah, but I thought you said you fixed that and it rebuilt last night
[15:44] <rickspencer3> ah, still rebuilding
[15:45] <rickspencer3> gotcha :)
[15:45] <Trevinho> rickspencer3: no, unfortunately I've not the right to force a rebuild :(
[15:46] <Trevinho> rickspencer3: however it's unlikely to fix your problem, since I see it was introduced before... However I've talked with nic-doffay who was the last touching that code, and he's looking at it right now
[15:46] <rickspencer3> Trevinho, ok, I'll just uninstall the ppa and wait for an update
[15:47] <Trevinho> rickspencer3: fine..
[15:47] <rickspencer3> just let me know if you want me to teset something
[15:47] <Trevinho> rickspencer3: sure
[15:47] <cyphermox> Laney: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1158367
[15:47] <ubot2> Launchpad bug 1158367 in evolution "[SRU] [MRE] evolution 3.6.4" [Undecided,New]
[15:47] <Laney> w00t
[16:00] <kenvandine> mterry, it's silly that the tests in qtdeclarative5 are disabled... enabling them they still don't run :)
[16:01] <tkamppeter> jodh, adding sleep 10 to the beginning of do_stop() in /etc/init.d/sendsigs and rebooting still shows the problem. So it looks like that /etc/init.d/sendsigs is most probably not the culprint.
[16:05] <rickspencer3> hey didrocks
[16:05] <didrocks> hey rickspencer3
[16:05] <rickspencer3> is there a way I can verify that all the default lenses are working?
[16:05] <didrocks> rickspencer3: going in every master scope
[16:06] <didrocks> and make a search in them
[16:06] <rickspencer3> didrocks, ok
[16:06] <rickspencer3> I bet I am confused
[16:06] <rickspencer3> didrocks, so if I search for Screen in the home lens
[16:06] <rickspencer3> I see all the Screenshots*.pngs in files and folders
[16:07] <rickspencer3> is there supposed to be a photo category there too?
[16:07] <didrocks> only if you have photos with "screen" on it
[16:07] <didrocks> but really, you should look at the master scopes you have
[16:07] <didrocks> what was called "lens" before
[16:07] <rickspencer3> didrocks, there is a Photo scope
[16:07] <rickspencer3> but when I click on it is empty
[16:07] <didrocks> you mean, a photo icon at the button?
[16:07] <davidcalle> rickspencer3, I can answer that: Photos currently merges : Shotwell, Flickr, Facebook, Picasa.
[16:08] <rickspencer3> and if I search for Screen, it's empty
[16:08] <rickspencer3> davidcalle, oh
[16:08] <didrocks> rickspencer3: but you don't see your local content?
[16:08] <rickspencer3> so I don't think I have any of those configured ;)
[16:08] <didrocks> like, do you have photos with "screen" in it?
[16:08] <rickspencer3> didrocks, I do not have local contents in Shotwell
[16:08] <jodh> tkamppeter: I would recommend again using strace to see what the daemon is doing. Upstart will send the SIGTERM.
[16:08] <jodh> tkamppeter: ... to the daemons effectively immediately.
[16:09] <rickspencer3> didrocks, yes, I have many photos in my Pictures dir that start with "Screenshot"
[16:09] <didrocks> rickspencer3: it's still looking in ~/Images/ IIRC
[16:09] <didrocks> right davidcalle ? ^
[16:09] <didrocks> as in the previous releases
[16:09] <didrocks> (at least, here it does, but not sure it's because shotwell imported them)
[16:09] <davidcalle> didrocks, it never has.
[16:10] <desrt> sarnold: reviewed your review :)
[16:10] <didrocks> ok, so shotwell was doing the trick for me :)
[16:10] <rickspencer3> didrocks, davidcalle as I say, the photos show up in Files and Folders
[16:10] <rickspencer3> so it seems to be working properly
[16:10] <didrocks> rickspencer3: well, expected (but another source of search, you should have both once shotwell is configured)
[16:11] <desrt> sarnold: some issues you find are just because systemd has to deal with some rather ridiculous aspects of the kernel.... others are on their way to being fixed upstream... and others aren't really serious imho
[16:11] <rickspencer3> davidcalle, if I configure gwibber to use facebook, I should see fb pics?
[16:12] <didrocks> rickspencer3: the social lens is not fully ready yet
[16:12] <davidcalle> rickspencer3, in Online Accounts, yes.
[16:12] <rickspencer3> ok
[16:13] <rickspencer3> sadly ... online accounts does not seem to be working for me, at least for facebook :/
[16:14] <rickspencer3> seb128, kenvandine Online accounts is not letting me configure facebook
[16:14] <rickspencer3> shall a log a bug?
[16:15] <seb128> sure
[16:15] <seb128> what is it doing exactly?
[16:15] <rickspencer3> seb128, nothing
[16:15] <seb128> rickspencer3, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center-signon/+filebug
[16:15] <rickspencer3> it just says "Please authorize Ubuntu to access your Facebook account"
[16:15] <rickspencer3> but nothing appears in the dialog
[16:15] <seb128> I can confirm there
[16:15] <seb128> *here
[16:16] <rickspencer3> ok
[16:16] <rickspencer3> ubuntu-bugging
[16:16] <seb128> "OAuth parameters missing!"
[16:16] <seb128> hum
[16:17] <kenvandine> oh
[16:17] <kenvandine> i uploaded a fix for that this morning
[16:17] <jpds> I can add a Facebook account, as of the latest updates.
[16:17] <rickspencer3> this suggests our testing in this area is not quite up to snuff :/
[16:17] <kenvandine> seb128, rickspencer3: ^^
[16:17] <jpds> kenvandine: And look, there's a LinkedIn plugin. :P
[16:17] <kenvandine> jpds, indeed
[16:17] <rickspencer3> kenvandine, ack
[16:17] <rickspencer3> I'll pick up the update tomorrow
[16:17] <seb128> kenvandine, what package? I updated after lunch
[16:18]  * rickspencer3 cancels bug report
[16:18] <kenvandine> gnome-control-center-signon
[16:18] <jpds> seb128: I just saw 0.1.4-0ubuntu1 come in.
[16:18] <kenvandine> a mix of the version of account-plugins that was uploaded
[16:18] <kenvandine> and g-c-c-s
[16:18] <chrisccoulson> awesome, i've just had a 512GB SSD arrive :)
[16:18] <seb128> is there any way you can avoid those version mismatch?
[16:18] <seb128> chrisccoulson, do you have the laptop to put it in? ;-)
[16:19] <kenvandine> seb128, well testing on a  non mix of -proposed :)
[16:19] <Laney> chrisccoulson: huge!
[16:19] <seb128> kenvandine, hum, I'm not using proposed afaik
[16:19] <Laney> how much was that?
[16:19] <chrisccoulson> seb128, not yet ;)
[16:19] <kenvandine> seb128, another case of -proposed not being a perfect solution
[16:20] <seb128> rickspencer3, the update is available and fixes the issue, no need to restart anything but gnome-control-center
[16:20] <Laney> you can ask for manual blocks
[16:20] <chrisccoulson> Laney, it was £365
[16:20] <Laney> wasn't the issue that it doesn't consider recommends?
[16:20] <seb128> rickspencer3, you can just fire up your update-manager ;-)
[16:20] <Laney> it -> proposed-migration
[16:20] <seb128> kenvandine, right...
[16:20] <kenvandine> seb128, right, but the version of account-plugins that was in raring still worked with the version of g-c-c-s that i uploaded the other day
[16:20] <kenvandine> but when the updated version in -proposed got moved to raring
[16:20] <didrocks> kenvandine: seb128: daily release would help avoiding that, just saying :)
[16:20] <kenvandine> it didn't work with the new g-c-c-s
[16:20] <didrocks> to have the version in sync :p
[16:20] <kenvandine> didrocks, yes... yes...
[16:21] <kenvandine> the fix was already in g-c-c-s trunk waiting to be uploaded
[16:21] <seb128> didrocks, +1
[16:21] <kenvandine> we're getting there
[16:22] <Laney> hum
[16:22] <sil2100> cyphermox: re-ping!
[16:23] <Laney> if I go into yahoo in online-accounts-preferences I get a blank window with "Cancel" and "Done", then clicking cancel segfaults it :-)
[16:25] <Laney> gnome-control-center crashed with SIGSEGV in empathy_account_widget_discard_pending_changes()
[16:27] <cyphermox> nice!
[16:37] <seb128> Laney, that bug is assigned to kenvandine for over a month
[16:37] <seb128> 1120651
[16:37] <seb128> kenvandine, ^ did you ever look at it?
[16:39] <kenvandine> seb128, i guess not
[16:39] <kenvandine> i'll look at it today
[16:39] <seb128> kenvandine, thanks
[16:39] <sarnold> desrt: glad to hear some aren't serious, some are underway, and some are due to kernel sillyness :) I did base my settimeofday(2) qualms entirely on the contents of the manpages...
[16:40] <kenvandine> Laney, i can't reproduce that right now... do you have the updates from today?
[16:40] <Laney> yes, it was immediately after doing them
[16:40] <kenvandine> so, so try adding yahoo then cancel
[16:40] <Laney> right
[16:41] <kenvandine> oh... you said a blank window
[16:41] <Laney> I get no content in the widget where webkit should be
[16:41] <kenvandine> what version of gnome-control-center-signon?
[16:41] <Laney> or whatever it is
[16:41] <Laney> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1158384
[16:41] <ubot2> Laney: Error: launchpad bug 1158384 not found
[16:41] <Laney> oops
[16:41] <Laney> (that will be the bug if/when it get retraced) I meant to paste
[16:41] <Laney>   Installed: 0.1.4-0ubuntu1
[16:42] <desrt> sarnold: TL;DR: RTC in non-UTC is fucked up for more reasons than any of us care to imagine and yet we have to continue to try to support it...
[16:42] <desrt> sigh.
[16:42] <kenvandine> the bug that kept that from loading was fixed in 0.1.4...
[16:43] <Laney> maybe I have to restart something?
[16:43] <kenvandine> shouldn't
[16:43] <kenvandine> unless maybe signon-ui is still running
[16:43] <kenvandine> kill everything with signon in the name
[16:44] <kenvandine> and start g-c-c again
[16:44] <Laney> laney@iota> pgrep signon-ui                                                                                                                ~
[16:44] <Laney> 3019
[16:44] <sarnold> desrt: does windows still expect RTC to be "local time" and update it at daylight savings time changes and all that nonsense?
[16:44] <desrt> sarnold: yup :(
[16:44] <sarnold> idiots.
[16:44] <desrt> and FAT filesystem still stores timestamps in localtime
[16:44] <Laney> kenvandine: still no good, sorry :/
[16:44] <kenvandine> humm
[16:44] <sarnold> desrt: wow.
[16:44] <desrt> just think about what that means for running 'make' near DST transitions...
[16:45] <kenvandine> Laney, do other providers work?
[16:45] <desrt> "oh.  this file that was last rebuilt half an hour ago doesn't need to be rebuilt because it was rebuilt half an hour into the future..."
[16:45] <Laney> let me try to add one
[16:45] <sarnold> desrt: haha
[16:45] <Laney> I get a login screen for Facebook
[16:45] <desrt> and the kernel actually tries to _deal_ with this
[16:45] <desrt> mindblowing
[16:46] <desrt> anyway... it's currently totally bogus because userspace needs to update the kernel on DST transitions
[16:46] <sarnold> definitely. I might have expected XP or Vista to change to UTC like any sane person would have...
[16:46] <desrt> since the kernel only knows the UTC->local minute offset
[16:46] <desrt> and userspace does not currently do that
[16:46] <desrt> systemd plans to start doing that at some point....
[16:46]  * desrt isn't sure anyone should care about such stupidity
[16:46] <sarnold> desrt: I thought userspace was in charge in setting the hwclock on shutdown?
[16:47] <desrt> sarnold: hahah...
[16:47] <desrt> the kernel sets the hwclock itself
[16:47] <desrt> under weird situations
[16:47] <desrt> like if it detects that NTP is enabled
[16:47] <sarnold> gah.
[16:47] <seb128> kenvandine, @empathy: thanks
[16:47] <sarnold> gah*2
[16:47] <desrt> plus... the kernel needs to sample RTC itself and reset the system clock under some situations
[16:47] <seb128> kenvandine, or maybe ping xclaesse about it to see if has an idea, seems to be in the empathy uoa side
[16:47] <desrt> like resuming from suspend...
[16:48] <desrt> can't really expect userspace to deal with that
[16:48] <desrt> (although the more i think about it, maybe for the non-UTC case, we should)
[16:49] <desrt> there's so much history of bad approaches to dealing with this that we need to remain back-compatable with, though :(
[16:49] <sarnold> desrt: so, the "sealing" the kernel's idea of local-rtc-offset-from rtc.... how on earth does that work? are all the 'sealing' comments in the code (and manpages) incorrect? or ...
[16:49] <desrt> sarnold: the 'sealing' refers to the fact the settimeofday() has different semantics the first time it is called from future times
[16:49] <desrt> and by 'first' time i mean.... really really first
[16:50] <desrt> not per-process, but per-system-boot
[16:50] <kenvandine> seb128, what makes you think it is empathy?
[16:50] <desrt> if you specify a timezone during this first call then the system time is warped
[16:50] <sarnold> desrt: yeah -- that's what has me surprised, because it appears to be called in the "sealing" mode over and over again in that code, but .. it's been sealed. right?
[16:50] <desrt> sarnold: i only saw it called once....
[16:50] <seb128> kenvandine, the function name in the title :p
[16:51] <kenvandine> well i think we have 2 bugs here :)
[16:51] <desrt> sarnold: from main() during the setup...
[16:51] <kenvandine> right now i am trying to figure out why the yahoo login doesn't load for Laney
[16:51] <sarnold> desrt: hrm. I _thought_ I saw them being called multiple times. I'd have to have gotten that wrong...
[16:51] <Laney> so, other accounts
[16:51] <desrt> sarnold: except in the case the the RTC is in UTC
[16:51] <desrt> then it gets called twice
[16:51] <desrt> first time with a NULL timezone to disable the warp
[16:51] <Laney> I can add a Facebook account and authorise it seemingly fine but Empathy never connects it
[16:51] <desrt> then again with a non-NULL timezone to setup the system time
[16:52] <Laney> it tells me it requires reauthorisation but the account manager disagrees
[16:52] <kenvandine> Laney, how about windows live?
[16:52] <Laney> I see this in the terminal: (gnome-control-center:30668): credentials-cc-panel-CRITICAL **: cc_credentials_account_application_switch_on_app_account_enabled: assertion `service != NULL' failed
[16:52] <kenvandine> just see if it loads the screen
[16:52] <Laney> that one works
[16:52] <desrt> sarnold: the 'sealing' function is the reset_timezone() one
[16:52] <desrt> there is exactly one call to it, from main()
[16:53] <desrt> timedated calls hwclock_set_time() again, but it ought to
[16:53] <desrt> hwclock_set_timezone() rather
[16:53] <Laney> Salut and identi.ca also made it crash
[16:53] <kenvandine> all of those work for me...
[16:53] <Laney> oh no, not ideanti.ca
[16:53] <Laney> that just prints a critical: (gnome-control-center:32650): account-plugin-CRITICAL **: ap_plugin_emit_finished: assertion `AP_IS_PLUGIN (self)' failed
[16:53] <kenvandine> identi.ca is slow to load
[16:54] <seb128> Laney, I get the service != NULL warnings as well
[16:54] <seb128> but no segfault
[16:54] <rickspencer3> popey, I got your "tooltips show over dash" bug just now
[16:55] <rickspencer3> if you have a link I can "me too" it
[16:55] <popey> ok
[16:55] <Laney> hmm, if I "Cancel" on any of them while it's still loading it segfaults actually
[16:55] <popey> https://launchpad.net/bugs/1158021
[16:55] <ubot2> Launchpad bug 1158021 in unity "Launcher tooltips don't disappear when dash is open" [Low,In progress]
[16:55] <Laney> so click Flickr and immediately cancel → segfault
[16:55] <popey> rickspencer3: ^
[16:55] <kenvandine> Laney, can you get a stacktrace?
[16:55] <Laney> yep, probs
[16:55] <seb128> GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `ApOAuthPlugin'
[16:55] <seb128> segfault
[16:55] <seb128> I can confirm that
[16:56] <kenvandine> ok, i got that too
[16:56] <kenvandine> have to click cancel fast
[16:56] <sarnold> desrt: woo. I had conflated the _time warping_ with the _set the timezone_. The timezone is maleable, the _warping_ is one-shot, and it all works out correctly in the end? :)
[16:56] <kenvandine> so different bug
[16:56] <desrt> yes
[16:56] <kenvandine> i wonder why apport isn't firing for that
[16:56] <sarnold> desrt: thank you. :)
[16:56] <seb128> kenvandine, it does here
[16:56] <kenvandine> great... file it :)
[16:56] <desrt> systemd calls settimeofday() in main so early specifically in order to ensure that future calls to settimeofday() have no warping effects
[16:56] <kenvandine> oh, i have an old crash report in /var/crash
[16:57]  * kenvandine cleans up
[16:57] <Laney> the first bug seems to be the ones that have both Cancel and Done buttons
[16:57] <desrt> when we set the timezone again to something else, we still need to update the kernel about that change for various stupid reasons like FAT....
[16:57] <desrt> it's confusing that this is handled in a file called hwclock
[16:57] <sarnold> desrt: yes :)
[16:57] <desrt> because it actually has nothing to do with the hwclock :(
[16:58] <kenvandine> An error occurred while attempting to process this problem report:
[16:59] <Laney> I'm filing that one too
[16:59] <seb128> Laney, kenvandine: I've the filing it's going to be a dup of https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1157559
[16:59] <ubot2> seb128: Error: launchpad bug 1157559 not found
[16:59] <Laney> ah, cool
[16:59] <Laney> are the retracers working to get these?
[16:59] <sarnold> desrt: thanks for the detailed comments and explanations. much appreciated. :)
[16:59] <seb128> Laney, the one I pointed is retraced with some dups
[17:00] <Laney> the first one had a failed retrace
[17:00] <kenvandine> ok... amigadave is already working on that bug
[17:01] <Laney> and the dup too
[17:01] <ogra_> desrt, on ubuntu ?
[17:02] <Laney> so it would be good if 1158384 could get retraced
[17:02] <kenvandine> bug 1122520
[17:02] <ubot2> Launchpad bug 1122520 in Online Accounts: GNOME Control Center "gnome-control-center crashed with SIGSEGV in finish_with_cleanup()" [High,In progress] https://launchpad.net/bugs/1122520
[17:03] <seb128> Laney, kenvandine: hey, dup of https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1157559
[17:03] <desrt> ogra_: hm?
[17:03] <ubot2> seb128: Error: launchpad bug 1157559 not found
[17:04] <ogra_> desrt, wheer do you find a file called hwclock ? there is only one authoritative setting in an ubuntu/debian system thats /etc/timezone (and requires some debconf magic after changes)
[17:06] <desrt> ogra_: we're discussing the MIR of systemd
[17:06] <desrt> which has a source file called hwclock.c
[17:06] <ogra_> ah
[17:06] <ogra_> heh
[17:06] <ogra_> not that we would use that :)
[17:06] <desrt> well, we are using that
[17:06] <ogra_> ugh, really ?
[17:07] <desrt> which is what why we are discussing it
[17:07] <seb128> Laney, kenvandine: set public and reassigned to gnome-control-center-signon
[17:07] <desrt> yes...
[17:07] <ogra_> in what context ?
[17:07] <ogra_> logind ?
[17:07] <desrt> we're switching to systemd to manage the system time
[17:07] <seb128> ogra_, systemd-services, replacing our python ubuntu-system-services
[17:07] <ogra_> err
[17:07] <desrt> both for setting the timezone and the time itself
[17:07] <desrt> which involves setting the hardware clock
[17:07] <seb128> ogra_, those are small dbus actived C services
[17:07] <ogra_> that will be fun to get right with debconf then
[17:07] <seb128> ogra_, ?
[17:08] <seb128> ogra_, there is no debconf in there
[17:08] <Laney> seb128: thanks
[17:08] <seb128> ogra_, it's not a packaging thing
[17:08] <Laney> retracing failed on mine because I have logind ppa packages installed
[17:08] <seb128> Laney, well, the bug I pointed has a debug/working retracing
[17:08] <ogra_> seb128, the timezone is stored in debconf (and written/read from/to /etc/timezone)
[17:08] <desrt> ogra_: timezone is not stored in debconf
[17:09] <seb128> ogra_, ubuntu-system-services doesn't do anything with debconf, nor does the custom gnome-settings-daemon helper we use atm
[17:09] <desrt> the authorative source for what is the timezone is what's in/pointed-to-by /etc/localtime
[17:09] <ogra_> hmm, did that change ?
[17:09] <Laney> it has a different top frame to mine though
[17:09] <desrt> Debian says 'in', systemd says 'pointed-to-by'
[17:09] <seb128> Laney, what's yours?
[17:09] <desrt> doesn't really matter either way
[17:09] <seb128> Laney, can you pastebin?
[17:09] <Laney> just from the bug title
[17:09] <desrt> everything just open('/etc/localtime') and reads...
[17:09] <Laney> I can't get dbgsyms here because of the PPA
[17:10] <seb128> Laney, the non retraced was https://launchpadlibrarian.net/134695584/Stacktrace.txt
[17:10] <Laney> mine was gnome-control-center crashed with SIGSEGV in empathy_account_widget_discard_pending_changes()
[17:10] <ogra_> desrt, well, as long as /etc/timezone stays autoritative i dont care
[17:10] <seb128> Laney, so title should say in g_simple_async_result_complete ()
[17:10] <desrt> ogra_: /etc/timezone is not authorative
[17:10] <ogra_> it is for the system TZ
[17:10] <desrt> it isn't and never has been
[17:10] <seb128> Laney, hey, that one is 1120651
[17:10] <desrt> everything on the entire system goes by what's in /etc/localtime
[17:10] <Laney> yeah, with the failed retrace
[17:10] <seb128> Laney, sorry we are mixing several issues there
[17:11] <Laney> we are ;-)
[17:11] <ogra_> desrt, well, since i started using debian it was ... when did it change ?
[17:11] <kenvandine> yeah, those are separate bugs
[17:11] <desrt> ogra_: i'm not sure what specifies /etc/localtime... but i think it's POSIX
[17:11] <desrt> and i've never known it to be any different
[17:12] <desrt> ogra_: 'strace date'
[17:12] <desrt> or any other program that does anything with time, really...
[17:13] <sarnold> http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
[17:14] <desrt> i love this document :)
[17:14] <desrt> this syntax particularly: EST+5EDT,M4.1.0/2,M10.5.0/2
[17:14] <desrt> madness
[17:14]  * desrt read a lot of this while writing GTimeZone
[17:15] <seb128> kenvandine, Laney: of course error.ubuntu.com doesn't have a successful retracing either :-(
[17:15] <seb128> Laney, can you locally apport-retrace it?
[17:15] <Laney> i'm building a nostrip version of gcc-signon
[17:15] <seb128> thanks
[17:17] <ogra_> desrt, well, thats only half the thing :) http://wiki.debian.org/TimeZoneChanges
[17:17] <kenvandine> i can't seem to trigger the SIGSEGV in empathy_account_widget_discard_pending_changes
[17:19] <seb128> what are the steps supposed to trigger it?
[17:19] <Laney> Try to add e.g. a Yahoo! account, see the content doesn't load, click cancel or done there
[17:20] <desrt> ogra_: do you know why it changed in etch?
[17:20] <desrt> this seems pretty silly
[17:21] <desrt> in any case, timedated does not maintain this other file...
[17:21] <ogra_> desrt, /etc/timezone defines the symlink , if it differs and some package tool runs dpkg-reconfigure it will be set wrongly ... you need to update /etc/timezone alongside any changes
[17:21] <desrt> we should probably fix the packaging not to do that...
[17:22] <ogra_> i guess then a bunch of server people woould show up at your doorstep :)
[17:22]  * desrt guesses server people are not changing their timezone as often as people with laptops
[17:22] <ogra_> you should fix your service to use dpkg-reconfigure tzdata and use debconf preseeding
[17:22] <desrt> no way :)
[17:22] <seb128> Laney, kenvandine: I get the yahoo's panel content here
[17:22] <desrt> that's not a 'fix'
[17:23] <ogra_> since the value stored in the debconf db is authoritative usually
[17:23] <desrt> the entire point of systemd is to remove distro-specific backend hacks for this sort of simple stuff
[17:23] <Laney> yeah so my bug must be that it doesn't load for some reason
[17:23] <Laney> #0  empathy_account_widget_discard_pending_changes (self=0x0) at empathy-account-widget.c:2204 [Error: empathy-account-widget.c was not found in source tree]
[17:23] <Laney> #1  0x00007fe1985c3086 in response_cb (widget=<optimized out>, response=<optimized out>, self=0x7fe1e4bcc3b0) at empathy-accounts-plugin-widget.c:160
[17:23] <ogra_> and will be applied if you cann dpkg-reconfigure tzdata
[17:23] <kenvandine> seb128, me too..
[17:23] <ogra_> s/cann/call/
[17:23] <Laney> let me try in the guest account
[17:23] <desrt> ya... this is some sort of madness
[17:23] <kenvandine> in wonder if empathy is getting in the way there
[17:24] <kenvandine> like if mission-control knows about the yahoo account
[17:24] <ogra_> well, it is established in debian vased systems since over a decade
[17:24] <kenvandine> but UOA doesn't
[17:24] <ogra_> *based
[17:24] <desrt> if i change the timezone using the real authorative method that the entire world agrees on (ie: setting /etc/localtime) then a distro script sets it back to some other value, i'd say the bug is in the distro script
[17:24] <Laney> it's broken there too
[17:24] <ogra_> and it works reliably across all form actors ... servers, desktops, embedded etc
[17:24] <desrt> unless i explicitly run that distro script, and then i'd say i guess i get what i ask for
[17:24] <kenvandine> ok
[17:24] <desrt> either way i don't see a problem
[17:24] <kenvandine> i need to step out for lunch... bbiab
[17:25] <seb128> kenvandine, enjoy!
[17:27] <ogra_> desrt, well, you are ignoring (and overriding) distro defaults
[17:27] <ogra_> seems pretty messy to me ...
[17:28] <Laney> The second bug got retraced as https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1158401
[17:28] <ubot2> Launchpad bug 1158401 in gnome-control-center "gnome-control-center crashed with SIGSEGV in identity_removed_reply()" [Medium,New]
[17:31] <ogra_> desrt, i guess we should kjust switch to rpms then ...
[17:32] <desrt> ogra_: because of the support for RPM built-in to glibc?
[17:33] <ogra_> no, because the new technology completely ignores what makes up a debian based system ...
[17:33] <ogra_> and debian policy etc
[17:53] <Laney> I did some retracing on https://bugs.launchpad.net/ubuntu/+source/gnome-control-center-signon/+bug/1158384
[17:53] <ubot2> Launchpad bug 1158384 in gnome-control-center-signon "gnome-control-center crashed with SIGSEGV in empathy_account_widget_discard_pending_changes()" [Undecided,Confirmed]
[17:53] <Laney> hopefully it's complete enough
[18:11] <mterry> davidcalle, heyo.  I'm doing some pre-MIR-reviews for the new scopes
[18:13] <mterry> davidcalle, as I'm going, I may see trivial things like Descriptions that could use cleaning up.  Any objection  if I just push those through?
[18:16] <davidcalle> mterry, no objection at all :)
[18:42] <stgraber> is it a known issue that current unity with auto-hide leaves some screen corruption (grey bar) behind where the launchers were?
[18:44] <stgraber> hmm, and compiz is using quite a lot of CPU too (often getting up to 50-60%)
[18:45] <stgraber> oh, found part of the problem at least, compiz isn't using hardware acceleration...
[18:48] <stgraber>  /dev/dri permissions are wrong... /me suspects udev/logind, let's try cleaning up that mess
[19:02]  * didrocks waves good evening
[19:02]  * ogra_ desnds and excusing hug to desrt .... i just learned that i was completely wrong for the last 10 years 
[19:02] <ogra_> s/desnds and/sends an/
[19:28] <achiang> cyphermox: hey, any progress on the nm-applet menu bug? never followed up after you had a reproducer
[20:01] <cyphermox> achiang: I ran into issues with the reproducer, there's some timing involved because I can reproduce at much below 32k runs
[20:18] <kenvandine> cyphermox, how's autopilot-qt looking?
[20:18] <cyphermox> kenvandine: it landed this morning
[20:19] <kenvandine> WOOT!
[20:19] <kenvandine> i will do my best to carve out time tomorrow to use it :)
[20:19] <cyphermox> cool :)
[20:19] <cyphermox> we'll need a MIR for it too, I guess
[20:20] <achiang> cyphermox: dang. well is your reproducer available somewhere? maybe i could take a look too
[20:21] <cyphermox> achiang: sure, I'll just push that to some junk branch
[20:21] <seb128> oh man, mterry will be so drunk at the next rally
[20:21] <seb128> so many MIRs and beers going with those
[20:22]  * achiang assumes mterry is just drunk all the time
[20:22] <cyphermox> achiang: https://code.launchpad.net/~mathieu-tl/+junk/test-indicator-update/
[20:23] <cyphermox> you can play with the timings in timeout_add(), and how many updates to run all in a batch and then slower, etc.
[20:24] <achiang> cyphermox: thanks
[20:25] <cyphermox> achiang: I hope it's understandable, don't hesitate to ask if you don't get what I'm trying to accomplish in that script :)
[20:29] <mterry> achiang, seb128: I always do a MIR with a beer in hand
[20:40] <olli> that makes me wonder what the mir team is doing
[21:15] <cyphermox> mterry: I like your style
[21:57] <desrt> sarnold: just got your review on systemd-shim
[21:57] <desrt> sarnold: i wonder if you know that the code you were reviewing is already in main
[21:57] <desrt> all i did was move it to a new package
[21:57] <sarnold> desrt: ha!
[21:58] <sarnold> desrt: oh man. :)
[21:58] <desrt> particularly the ntp hacks....
[21:58] <desrt> they're already running on your system right now as gsd-datetime-mechanism
[21:58] <desrt> (as root, of course)
[21:58] <sarnold> desrt: I figured part of it had to be conforming to an upstream api of some sort, but .. man.
[21:59] <desrt> nope.  it's conforming to debianisms.
[21:59] <sarnold> well, those parts are _also_ ugly :) but I think there ought to be a clean way to express it all.
[22:01] <desrt> seb128: can i browse gnome-settings-daemon packaging online somewhere?
[22:01] <sarnold> please don't get me wrong, the only thing I really disliked was mv -f ...
[22:01] <desrt> ah... if i add "code." to the URL i find what i need :)
[22:01] <sarnold> each individual bit is pretty decent. but the interaction of all those functions feels like a pain to follow and maintain.
[22:01] <desrt> sarnold: ya.... i actually simplified it a bit
[22:02] <desrt> it was worse before :)
[22:02] <sarnold> desrt: man. someone owes you a lot of beers. :)
[22:02] <desrt> i was trying not to change too much funcitonality tho
[22:02] <desrt> it looks ... uh... a bit brittle :)
[22:03] <sarnold> yeah, not breaking already deployed code is different from designing something from scratch
[22:03] <desrt> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/gnome-settings-daemon/raring/view/head:/debian/patches/revert_git_datetime_dropping.patch#L850
[22:03] <desrt> here's the code we're shipping today
[22:03] <desrt> but you're right... direct-invoking mv is just plain stupid
[22:04] <sarnold> desrt: nice cleanup. :)
[22:06] <desrt> aside: g_strconcat() doesn't fail
[22:06] <desrt> i'll reply in the bug
[22:06] <desrt> i can try to clean up the NTP code a bit more if you like
[22:08] <sarnold> desrt: hrm, I figured anything that allocated memory could fail :) but you're right, in the uses there, it isn't checked, so no FALSE as a result.
[22:08] <desrt> sarnold: if memory allocation fails in glib programs then the entire program aborts
[22:08] <desrt> g_malloc() basically has assert(ret!=NULL);
[22:08] <sarnold> wow :)
[22:08] <desrt> and any function that allocates memory is going via g_malloc()
[22:09] <desrt> ya.... it's a policy decision that makes glib unpopular with a lot of people :)
[22:09]  * desrt personally likes it
[22:09] <sarnold> there's a huge class of applciations that'd be vastly improved with such a policy :) but it feels a bit draconian for system services. hehe.
[22:10] <desrt> checking the return value of malloc() doesn't buy you too much when you have a kernel policy of overcomitting on allocations and OOM-killing apps when it realises that it's out of space
[22:10] <sarnold> desrt: I _would_ like those funcitons cleaned up a bit, but my original enthusiasm for breaking them apart is a bit blunted knowing that it's mimicing tested-and-deployed code that we've already got.
[22:10] <sarnold> desrt: true, true.
[22:18] <desrt> sarnold: ACK on your catch about not checking the return value of the virtualisation detection
[22:19] <desrt> sarnold: also ACK on the NTP stuff being gross, but i think i'd rather leave it alone for now
[22:24] <sarnold> desrt: excellent response on the bug, thanks :)
[22:28] <rickspencer3> anyone here know about in dash payments?
[22:28] <rickspencer3> dobey?
[22:28] <rickspencer3> I'm wondering if it will be available for anything but music purchases when 13.04 comes out
[22:38] <rickspencer3> olli, kgunnAFK, is there a list of scopes that will be installed by default that I can reference?
[22:38] <olli> rickspencer3, 1 sec
[22:39] <rickspencer3> thanks olli