[00:45] <robert_ancell> cyphermox, Did the fix for bug 1035431 ever go upstream? It doesn't seem to be in git and I can't find a bz link
[00:45] <robert_ancell> I'm happy to do it, just don't want to duplicate work
[00:48] <robert_ancell> timchen119, ^
[01:02] <blahdeblah> bregma: ping - greyback suggested I talk to you here about narrowing down the component for logging a lockup bug.
[01:05] <blahdeblah> I think it's probably an instance of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1384342, but I'm not sure how to confirm
[01:06] <blahdeblah> Symptoms are that all X applications become unresponsive to mouse, keyboard becomes unresponsive.
[01:06] <blahdeblah> Mouse pointer still works, but is confined to screen 0 (my external monitor doesn't work).
[01:06] <blahdeblah> On trusty, if I just let it sit there, it would come good after about 30-60 seconds.
[01:06] <blahdeblah> On utopic, if I don't manually intervene and switch to a text console and back, it never comes back (at least not in the 12 minutes that I waited last time).
[01:06] <blahdeblah> Switching to a text console and back works extremely slowly, but eventually does the right thing, and everything continues on.
[01:06] <blahdeblah> Other symptoms are: out of order messages in /var/log/syslog (like, 5 minutes out of order), and no kernel oops until I switch VCs.
[01:06] <blahdeblah> Here's the oops that does occur eventually: https://pastebin.canonical.com/121261/
[01:28] <blahdeblah> After reading that bug more, I think it's the same one affecting me.  I've metooed it and added links to another oops & related bug that might be the same one.
[02:24] <cyphermox> robert_ancell: it's backported from upstream git commits
[02:24] <cyphermox> that said, I thought it had been uploaded already
[02:24] <robert_ancell> cyphermox, it's not in upstream git
[02:25] <cyphermox> the SSP code?
[02:25] <robert_ancell> cyphermox, I've opened bugs with patches for our two remaining ubuntu patches
[02:25] <robert_ancell> yes
[02:25] <cyphermox> sure is, though not exactly as-is, since it was bluez5 code
[02:25] <cyphermox> oh wait
[02:25] <cyphermox> yeah ok, gnome-bluetooth
[02:25] <robert_ancell> https://bugzilla.gnome.org/show_bug.cgi?id=740829
[02:25] <cyphermox> these parts might not be
[02:25] <robert_ancell> https://bugzilla.gnome.org/show_bug.cgi?id=740830
[02:28] <cyphermox> ok
[02:28] <cyphermox> well, you're not duplicating work I've been doing
[02:29] <cyphermox> though AIUI there were commits in upstream git that made the PIN for Ultrathin no longer required
[02:30] <cyphermox> ah, I see, I'm mixing things up
[02:31] <cyphermox> there was another thing for Microsoft devices
[02:59] <cyphermox> robert_ancell: from your bug about updating gnome-bluetooth, have you uploaded the package to ppa:ubuntu-desktop/bluez5 too?
[03:00] <robert_ancell> cyphermox, yes but to the transitions PPA as requested by didrocks
[03:00] <cyphermox> err
[03:00] <cyphermox> I thought we were using the one named bluez5
[03:00] <robert_ancell> So I think he plans to do a binary copy into ppa:ubuntu-desktop/bluez5
[03:00] <cyphermox> not that it changes much
[03:00] <cyphermox> ok
[03:01] <robert_ancell> I think there might be a change of plans based on the email discussion I had with didrocks and seb128
[03:01] <cyphermox> I'll test it out in the morning; so I'll put my headset on charge now
[03:03]  * RAOF should probably fire up his Ziks and see if they work there.
[03:03] <cyphermox> let's see if everything landed
[03:04] <TheMuso> The bluez5 PPA is no longer a thing... SO I guess the transitions PPA is what one should use...
[03:04] <cyphermox> robert_ancell: ah, it was removed and everything is in transitions yes
[03:04] <cyphermox> cool
[03:04] <TheMuso> That really should be more widely announced...
[03:05] <cyphermox> I'm not sure either was really announced
[03:05] <cyphermox> at least pulse and bluez5 and gnome-bluetooth are there, so things might be in a good enough shape to be usable
[03:05] <TheMuso> Sure the bluez5 ppa was not announced, but the thread we had going about pulse etc likely has people wondering where things have gone if they update and find a 404.
[03:05] <cyphermox> yeah
[03:05] <TheMuso> At least I was wondering about it.
[03:06] <cyphermox> well, at least all the pieces seem to be in place for testing
[03:07] <cyphermox> except for my headset batteries being charged, that is
[03:14] <TheMuso> heh'
[03:15] <cyphermox> I'm off to bed now, good day!
[03:15] <robert_ancell> cyphermox, bye!
[06:45] <didrocks> good morning
[07:09] <seb128> lut didrocks
[07:09] <didrocks> salut seb128
[07:09] <seb128> Laney, bug #1397135 seems a regression from the upower fix from yesterday
[07:10] <pitti> bonjour seb128 et didrocks
[07:10] <seb128> rsalveti, you miss debug symbols for u-s-d in your bt
[07:10] <seb128> lut pitti, comment ça va aujourd'hui ?
[07:10] <pitti> seb128: yeah, I get this all the time, I needed to downgrade
[07:10] <didrocks> bonjour pitti ! moins fatigué qu'hier ?
[07:10] <pitti> I filed it to errors.u.c., but it didn't turn up there yet
[07:10] <pitti> didrocks: oui, j'ai me levé à 5:30, mais je vais bien :)
[07:11] <didrocks> couché tôt hier soir j'imagine :)
[07:11] <pitti> nous allons à Dresden ce week-end, pour visiter nos familles
[07:11] <pitti> didrocks: oui, 22h comme d'habitude :)
[07:11] <didrocks> pitti: oh, 2 days is enough or you are taking the train and work from there this afternoon ?
[07:12] <pitti> didrocks: the latter; I leave around 11:15 here and work in the train
[07:12] <pitti> I have some systemd debugging to do :)
[07:12] <didrocks> heh :)
[07:12] <didrocks> pitti: I thought about another use case where presets can be an issue btw, going to write on the ML
[07:13] <didrocks> hopefully relaunching the debate of separating distro preferences from /etc/
[07:13] <pitti> didrocks: btw, it seems we may want the generator in jessie after all? so it needs porting to 215
[07:13] <didrocks> would be nice to have Lennart's opinion on this
[07:13] <pitti> *nod*
[07:13] <didrocks> pitti: want me to do that now? should be easy
[07:13] <pitti> didrocks: if you wish; I just uploaded -7, so we have a clear field for new release team requests :)
[07:13] <pitti> didrocks: so please pull master before you rebase
[07:14]  * didrocks does
[07:14] <pitti> we also have 2 RC bugs, so -7 won't be the last one anyway
[07:14] <didrocks> I think the function that was missing was the only one anyway
[07:14] <pitti> *nod*
[07:14]  * pitti hugs didrocks, the new systemd master
[07:14]  * didrocks hugs pitti back, the master of all masters, as usual :)
[07:14] <seb128> pitti, I wonder why e.u.c doesn't pick those u-s-d reports
[07:14] <seb128> pitti, I guess yours is not https://errors.ubuntu.com/problem/fb3c4073786721c0e327ff099ccc1ea7666f6cb7 ?
[07:15] <pitti> seb128: no, that looked different; I have an abort in free()
[07:15] <seb128> what I though
[07:16] <pitti> bug 1397135 is mine
[07:19] <seb128> pitti, do you have a bt that includes the u-s-d symbols?
[07:20] <pitti> ah sorry, no
[07:20] <pitti> I can probably re-upgrade, get a fresh crash, and upload that to LP
[07:20] <pitti> I just saw the above bug wasn't a "proper" apport one
[08:10] <Sweet5hark> moin
[09:03] <dholbach> hiya
[09:03] <willcooke> FJKong, Have you played with gqrx at all?
[09:03] <willcooke> hey dholbach
[09:04] <dholbach> Laney, do you know where http://paste.ubuntu.com/9280386/ could be coming from?
[09:04] <dholbach> hey willcooke
[09:05] <Laney> hello
[09:05] <Laney> oh good
[09:06] <dholbach> it's exploding (and retheming everything in the process of it, like if g-s-d exploded) every minute
[09:08] <Laney> downgrade it
[09:08] <Laney> let me look
[09:11] <seb128> Laney, hey
[09:11] <seb128> Laney, rsalveti and pitti reported similar issues
[09:11] <Laney> yes great, everybody is
[09:11] <seb128> I wonder if that's doing it for everyone, I didn't try to restart my session (or u-s-d) yet
[09:11] <Laney> no
[09:11] <Laney> because I was running it all day
[09:11] <seb128> k
[09:11] <Laney> but get a better trace if you can
[09:12] <Laney> although I wasn't using the archive binaries to be fair
[09:17] <Laney> https://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/power/gsd-power-manager.c?id=6f1a6debd46cdd279bab8692aa7503e1f7ba954b
[09:17] <Laney> well the trace on the bug is in that code
[09:17] <Laney> sooooooo
[09:18] <seb128> did you test on a laptop?
[09:21] <Laney> no
[09:21] <Laney> anyway I have it now, let's just take this code
[09:21] <seb128> that's why
[09:21] <seb128> 0xb387734f in device_perhaps_recall_delay_cb (user_data=0x972d150)
[09:21] <seb128>     at gsd-power-manager.c:960
[09:21] <Laney> yes
[09:21] <Laney> I know, I just said
[09:21] <seb128> is the invalid free
[09:21] <seb128> k
[09:22] <Laney> where's the upstream import for usd?
[09:22] <seb128> upstream "import"?
[09:22] <Laney> "yes"
[09:22] <seb128> lp:unity-settings-daemon is the source
[09:22] <Laney> the bzr branch
[09:22] <seb128> dunno what you mean "import"
[09:23] <Laney> there's one to cherry pick from
[09:23] <seb128> try lp:gnome-settings-daemon
[09:24] <seb128> that seems outdated though
[09:24] <seb128> I don't think we did use proper vcs cherry pick for other changes
[09:24] <dholbach> if you have a branch/patch you want tested locally, let me know
[09:24] <Laney> there was a branch, robert set it up
[09:28] <dholbach> I'm not sure... is rolling back to https://launchpad.net/ubuntu/+source/unity-settings-daemon/15.04.0+15.10.20141030-0ubuntu1 going to fix it?
[09:28] <seb128> Laney, ok, I don't know about that
[09:28] <seb128> dholbach, yes
[09:28] <dholbach> thanks, because this is a bit annoying :)
[09:28] <seb128> it is
[09:29] <Laney> I might just close IRC for a bit
[09:29] <Laney> this is getting distracting
[09:29] <seb128> Laney, checked my IRC log, I don't find reference to robert_ancell's import
[09:29] <seb128> so sorry, can't help on that
[09:29] <dholbach> brb
[09:29] <larsu> morning!
[09:29] <seb128> hey larsu, wie gehts?
[09:29] <dholbach> hey larsu
[09:29] <dholbach> larsu, hippie!
[09:30] <seb128> Laney, feel free to close/ignore IRC any time during the day when trying to get work done, many do it ;-)
[09:30] <larsu> dholbach: selber hippie!
[09:30] <larsu> dholbach: how was the trip?
[09:30] <larsu> seb128: good thanks! And you?
[09:30] <dholbach> ah no, no need to restart - unity-settings-daemon restarted itself ;-)
[09:30] <seb128> larsu, I'm good, thanks
[09:31] <dholbach> larsu, quite nice, although I'm not quite as refreshed as having slept 8h in a non-moving bed :)
[09:31] <dholbach> how about you?
[09:31] <pitti> seb128: mind if I steal your policykit-1 merge?
[09:31] <larsu> dholbach: haha! I'm good as well, thanks :)
[09:32] <seb128> pitti, please do, I didn't intend to merge it anyway, most of the GNOME merges are a waste of efforts
[09:32] <seb128> like they don't bring anything useful
[09:32] <seb128> so I tend to skip them until there is something worth merging
[09:32] <pitti> seb128: this one drops most of our delta, and I want a rebuild anyway
[09:32] <seb128> k
[09:41] <Laney> seb128: https://code.launchpad.net/~laney/unity-settings-daemon/lp1397135/+merge/243127 review please
[09:42] <seb128> Laney, looking
[09:42] <seb128> Laney, did you find the import vcs?
[09:42] <Laney> no, I passed --author to fake it
[09:43] <seb128> Laney, approved
[09:45] <seb128> Laney, robert_ancell had https://code.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/no-submodules
[09:45] <seb128> just found that in some email
[09:46] <seb128> Laney, he wrote that http://paste.ubuntu.com/9280748/
[09:47] <Laney> ah
[09:47] <Laney> you can do bzr branch on a git checkout?
[09:48] <seb128> I never tried
[09:48] <seb128> the email is maybe buggy ;-)
[09:51]  * Laney eyes this job
[09:51] <Laney> https://ci-train.ubuntu.com/job/ubuntu-landing-003-1-build/75/console
[09:51] <Laney> what is "Build source package" doing?
[09:52] <seb128> doing a source build of the deb
[09:52] <seb128> so it can dput that to the ppa
[09:52] <seb128> iirc
[09:52] <seb128> k, log refresh
[09:52] <seb128> it just dputed
[09:52] <Laney> ah there
[09:53] <Laney> just slow
[09:54] <seb128> yeah
[09:54] <seb128> dunno why the log didn't update periodically
[10:14] <FJKong> willcooke: gqrx?
[10:15] <willcooke> FJKong, it's like a simplified gui to Gnu Radio with a few demods already written for you and you just choose
[10:15] <willcooke> quite good
[10:15] <willcooke> the version in the archive has issues, but there is a ppa with newer versions in
[10:15] <FJKong> willcooke: yes, it seems quite good
[10:15] <willcooke> then you just need a cheap DVB-T dongle and you're away
[10:18] <mlankhorst> willcooke: +sa5 seems to be good enough to run a full desktop with Xmir replacing Xorg+mir. But it also shows what mir is still lacking. :P
[10:18] <mlankhorst> 10:51 < duflu> mlankhorst: https://bugs.launchpad.net/xmir/+bug/1216468, https://bugs.launchpad.net/unity-system-compositor/+bug/1204505
[10:22] <willcooke> cool!  Thanks mlankhorst
[10:27] <Laney> dholbach: want to try ppa:ci-train-ppa-service/landing-003 ?
[10:28] <larsu> Laney: the name of the key if org.gnome.desktop.session idle-delay, but gsm-manager.c binds to idle-timeout...
[10:28] <larsu> Laney: was the name changed?
[10:30] <Laney> larsu: isn't idle-timeout the name of the property on the (G)object?
[10:31] <Laney> (from memory)
[10:32] <larsu> Laney: ah, freaking #defines
[10:32] <larsu> Laney: you're right. False alarm
[10:32] <larsu> (sorry)
[10:32] <Laney> np, it's a bit confusing
[10:32] <Laney> can you reproduce this now?
[10:33] <larsu> no, wfm in a test program
[10:35] <Laney> blerg
[10:41] <dholbach> sure, let me try
[10:46] <dholbach> Laney, seems to work fine AFAICT
[10:47] <Laney> cool beans
[10:52] <Laney> dholbach: thanks for checking
[10:52] <Laney> going to release this now
[10:52] <seb128> Laney, the u-s-d from the ppa works fine
[10:53] <dholbach> rock on
[10:53] <Laney> this train is leaving the station
[11:00] <larsu> Laney: got it. FUCK.
[11:00] <larsu> at least I think I do...
[11:00] <Laney> got is reproduced or got is figured out?
[11:00]  * larsu shakes fist in desrt's general direction
[11:00] <larsu> but then ... I reviewed that patch :/
[11:00] <larsu> Laney: both
[11:00] <Laney> neat!
[11:01] <larsu> 1. reproduce
[11:01] <larsu> 2. find the issue
[11:01] <larsu> 3. fix
[11:01] <larsu> status: 2
[11:01] <Laney> why's the gnome-session case different from your minimal one?
[11:01] <Laney> well, fix then explain if you want ;)
[11:02] <larsu> it subscribes to a detailed signal
[11:02] <larsu> if I subscribe to changed::idle-delay, I don't get events at all
[11:02] <larsu> works if I subscribe to changed
[11:02] <Laney> ah
[11:03] <Laney> but you get the initial value yeah?
[11:03] <larsu> yes, this is already in the "correct" case
[11:03] <larsu> g_settings_bind() uses detailed signals...
[11:04] <Laney> ya, makes sense
[11:09] <larsu> great, now my screen turns off after 100ms
[11:09]  * larsu should have chosen another key to test :D
[11:31] <larsu> Laney: I have two possible fixes, but need to ask desrt which he prefers
[11:32] <larsu> the problem is that g_signal_has_handler_pending() only returns TRUE when both the signal and the detail match
[11:32] <larsu> it doesn't special case 0 as "any detail", it must be no detail
[11:32] <larsu> actually now that I write this down, this might be the sane behavior...
[11:35] <willcooke> https://github.com/jefferyto/gedit-control-your-tabs
[11:35] <willcooke> \o/
[11:40] <willcooke> larsu - can you tell me... can I change the colour of the active tab in gedit?>
[11:42] <larsu> willcooke: likely, let me check. Are you running V?
[11:43] <willcooke> larsu, nah - too chicken, Trusty
[11:44] <willcooke> ah, I think I will edit the Cobalt theme, since that's what I like
[11:44] <larsu> willcooke: you could have tried overriding the css in the inspector then
[11:45] <willcooke> ZOMG
[11:45] <willcooke> There's a bleedin "Color (spelt wrong) Scheme Editor"
[11:45] <willcooke> oh, but I don't think tabs are covered there
[11:46] <larsu> no...
[11:46] <larsu> you have to override the gtk theme
[11:46] <larsu> which is a bit of a pain tbh
[11:46] <willcooke> ack
[11:46] <larsu> but doable
[11:46] <willcooke> How do we go about getting changes in there by default?
[11:46] <willcooke> Do we have to get the OK from design?
[11:46] <larsu> this works: '.notebook tab:active { background-color: red; }'
[11:47] <willcooke> Because, IMHO, having the active tab very nearly the same as an inactive tab is wrong
[11:47] <larsu> I agree
[11:47] <willcooke> let's do it then :)
[11:47] <larsu> red active tabs \o/
[11:47] <willcooke> I'll clear it with JohnLea
[11:47] <willcooke> ;)
[11:47] <larsu> haha
[11:53] <willcooke> changing the shade to 0.52 works for me
[11:53] <willcooke> thanks larsu
[11:53] <larsu> np
[11:53] <larsu> Laney: this fixes it http://paste.debian.net/plain/133949
[11:53] <larsu> not sure if we shouldn't change g_signal_has_handler_pending() instead, though
[11:54] <larsu> this is actually a problem in a few other places as well (application, gsimpleaction)
[11:54] <larsu> look at this, all desrt code! :P
[11:57] <Laney> why's it a problem there too?
[11:57] <Laney> or you mean your fix fixes the same issue elsewhere
[12:00] <larsu> because it checks there for subscribed handlers with a 0 detail, too
[12:01] <larsu> if you are subscribed to a detail, the check will fail
[12:01] <larsu> the patch I linked to circumvents this by checking both cases, but this only works because we know which key the user is asking for in g_settings_get
[12:02] <larsu> you can't know that in all cases, and checking _all_ details seems bad
[12:02] <larsu> so, I think passing 0 as detail to has_handler_pending() should mean "no detail or any detail"
[12:02] <larsu> not sure if that's too much of an ABI break though
[12:41] <Sweet5hark1> seb128: did you get my mail about the 4.2.7+/trusty and 4.3.4/utopic updates?
[12:48] <dholbach> is anyone of you running vivid already? do you have some window management / wrong window having focus issues too?
[12:49] <larsu> yes, but this has been a problem for a while, no?
[12:50] <larsu> Trevinho: ^^ ;)
[13:03] <seb128> Sweet5hark1, hey, yes, I was on vac yesterday, I've that in my backlog
[13:03] <seb128> dholbach, larsu: unity/compiz didn't change a lot recently afaik, didn't notice any focus issue here
[13:04] <seb128> in what cases does it happen?
[13:13] <Trevinho> larsu: mh, what specifically? I'm not in vivid, but I didn't see many WM issues before
[13:14] <mlankhorst> willcooke: ok last update for me today, had a stupid bug that broke glxgears when using xmir as replacement for xorg, and i made screen blanking work
[13:14] <mlankhorst> afk a bit
[13:14] <willcooke> mlankhorst, coolio!
[13:49] <larsu> seb128, Trevinho: for example, switching workspace to one with only one window doesn't focus that window
[13:50] <seb128> larsu, wfm, how do you switch workspace? was that one window having focus before you moved out of that workspace?
[13:50] <Trevinho> mh, there has been a community contribution about that
[13:51] <larsu> seb128: yes, it was. in fact, seems that refocussing the last focussed window on a workspace doesn't work reliably
[13:51] <larsu> seb128: it's one of those things that works 80% of the time
[13:51] <seb128> never saw that issue
[13:51] <larsu> the remaining 20% I type gibberish into a wrong window ;)
[13:51] <seb128> I bet it's more complex than that
[13:51] <seb128> like you might have wins overlapping on 2 workspaces or something
[13:52] <seb128> the tricky part is to determine was in different in the case where it gets it wrong
[14:08] <willcooke> seb128, in System Settings -> Security & Privacy -> Diagnostics
[14:08] <willcooke> there is an option "Send occasional system information to Canonical"
[14:08] <willcooke> "This includes things like how many programs are running, how much disk space the computer has........"
[14:08] <seb128> willcooke, phone or desktop?
[14:08] <willcooke> seb128, dednick
[14:09] <willcooke> oops sorry dednick ignore
[14:09] <willcooke> seb128, desktop
[14:09] <willcooke> Do you know what that is?  What runs?  What info it collects?
[14:09] <willcooke> Can't find anything of Google
[14:11] <willcooke> *on
[14:11] <seb128> willcooke, it's whoopsie
[14:11] <willcooke> seb128, thanks!
[14:11] <willcooke> seb128, so what is "Send error reports...." is that apport?
[14:11] <seb128> willcooke, https://wiki.ubuntu.com/ErrorTracker
[14:11] <seb128> willcooke, https://wiki.ubuntu.com/ErrorTracker#Invitation_for_metrics_collection
[14:12] <Laney> is that dialog implemented?
[14:12] <seb128> not that I know
[14:12] <willcooke> no, dont think so
[14:13] <willcooke> just a tick box
[14:13] <seb128> but under the dialog there is the bit about the control center
[14:13] <Laney> ya
[14:13] <desrt> larsu: hello!
[14:13] <Laney> I don't know what metrics whoopsie gathers either
[14:13] <larsu> desrt: so ... maybe we should make g_signal_has_pending_handlers() do the right thing when passing 0?
[14:13] <Laney> willcooke: ev would be one to ask
[14:13] <desrt> larsu: i was thinking about that
[14:13] <desrt> larsu: or at least document it more explicitly
[14:13] <larsu> as in, return TRUE if detailed signals are connected
[14:13] <willcooke> seb128, yeah, that bit of text is pretty vague
[14:13] <willcooke> thx seb128, Laney
[14:13] <seb128> willcooke, Laney, I'm not even sure metrics are implemented/what they are, https://launchpad.net/ubuntu/+source/whoopsie-daisy/0.1.10
[14:13] <desrt> larsu: but truth be told the existing behaviour is logical and consistent
[14:13] <desrt> even if not expected
[14:14] <larsu> desrt: not sure how much of an ABI break that would be...
[14:14] <seb128> willcooke, Laney, that has "  * Remove the metrics preferences, since this does not exist."
[14:14] <seb128> willcooke, can you ask on #ubuntu-devel to ev and bdmurray? or want me to do that?
[14:14] <desrt> larsu: it answers the question "if i emitted a signal wuth these ... uh... details.... would it be handled?"
[14:14] <willcooke> seb128, s'scool - StephaneVerdy wants to know, so I can put him in touch with ev
[14:15] <seb128> willcooke, well I'm interested by the reply, so asking on #ubuntu-devel would be useful
[14:15] <larsu> desrt: right. The problem is that we might want to check for connected handlers when we don't know the detail
[14:15] <willcooke> seb128, kk
[14:15] <larsu> desrt: it works great in the gsettings case, as we do it on a _get(
[14:15] <desrt> larsu: i'd suggest another function for this purpose
[14:15] <seb128> willcooke, it might be that there is no backend behind this control, in which case we should remove it from the UI
[14:15] <seb128> willcooke, and if there is a backend I would still like to know what's the difference between the metrics and the reports
[14:15] <willcooke> seb128, +1
[14:15] <desrt> larsu: i think the behaviour of the existing one does make a good deal of sense -- but we could use a clarifying sentence in the docs
[14:15] <larsu> desrt: ya, proabably better. Then we also don't break anyone
[14:16] <desrt> i'm also not into changing an API in an API-stable library just because the maintainer of that library made a mistake when using it once
[14:16] <willcooke> seb128, waiting for stephane to join #u-d
[14:16] <larsu> desrt: right. Want me to add that function or should we wait until we have a use case?
[14:16] <desrt> let's wait
[14:16] <desrt> i'll add a clarification to the docs
[14:17] <larsu> desrt: ok. thanks for the review
[14:17] <larsu> desrt: reverted?
[14:17] <desrt> how did you find the bug, btw?
[14:17] <desrt> larsu: ya... we're going to fix this the 'proper' way, remember?
[14:17] <larsu> desrt: ah, right.
[14:17] <desrt> once someone reviews my signal connection notify patches.....
[14:17] <larsu> desrt: vfuncs on gobjectclass?
[14:17] <desrt> ya
[14:17] <larsu> nice!
[14:17] <desrt> which i already start to think are slightly odd
[14:17] <larsu> desrt: Laney found it
[14:18] <desrt> since you can connect signals on non-gobjects
[14:18] <desrt> but whatever
[14:18] <Saviq> anyone else's settings daemon crashing in a loop?
[14:18] <Laney> upgrade
[14:18] <larsu> desrt: like people do that
[14:18] <seb128> Saviq, yes, was fixed this morning
[14:18] <Saviq> seb128, ah, was just about to try and upgrade
[14:18] <seb128> :-)
[14:18] <larsu> Laney: do you need this fix pushed on something other than master?
[14:19] <Laney> no
[14:19] <Saviq> it's a bit difficult to focus when stuff's jumping around on me ;)
[14:19] <Laney> can't upload again until ppc64el is fixed, though :)
[14:19] <seb128> yeah...
[14:19] <Laney> morning desrt!
[14:19] <didrocks> at least, we know who is using vivid and who is not ;)
[14:19] <larsu> Laney: okay, pushed to master. Thanks for pointing it out!
[14:20] <desrt> larsu: just feels a bit inconsistent
[14:20] <Laney> thanks for fixing
[14:20] <Saviq> ok let's hope this was the last crash then
[14:20] <seb128> yeah
[14:20]  * Saviq wonders why `restart unity7` results in all windows killed when unity restarts, as opposed to `pkill compiz`
[14:20] <desrt> the entire way gsignal works is 'bolted on the side' so it sort of feels like this ought to be as well
[14:20] <larsu> desrt: fair enough, but let's be practical about this...
[14:20] <desrt> ie: some sort of g_signal_set_notify_callback()
[14:21] <larsu> hm
[14:21] <larsu> now you have me thinking..
[14:21] <desrt> ya.... :)
[14:21] <seb128> Saviq, unity8 question for you, is that know that if you are on crappy 2g and images fail to load in e.g the appstore, and you  switch to wifi and refresh they don't try loading anymore/keep the "x" symbol instead?
[14:21] <larsu> makes sense API wise as well, since everything signals is g_signal_*
[14:21] <seb128> Saviq, even forcing a refresh with pulling down didn't make them load, had to reboot
[14:21] <Saviq> seb128, bug #1357321
[14:22] <desrt> and it would allow installing such handlers for interfaces and creating some mechanism within the interface for handling it
[14:22] <desrt> the fact that interfaces aren't gobjects concerns me wrt. this
[14:22] <seb128> Saviq, are you sure it's the same issue? the title is misleading, mine would be "doesn't try to reload after switching to wifi"
[14:22] <Saviq> seb128, that's the title it had before
[14:22] <desrt> anyway... i'm still in gvariant land
[14:22] <larsu> desrt: this might turn into a yak. Beware.
[14:22] <seb128> Saviq, ok, fair enough, thanks ;-)
[14:23] <Saviq> seb128, we've a fix incoming
[14:23] <desrt> larsu: i don't think so.  the patch is already written and changing it to use a function rather than a vtable would be semi-trivial
[14:23] <seb128> Saviq, when are ota fixes starting to land? ;-)
[14:23]  * desrt made good progress on gvariant serialisation yesterday -- moved from 2nd rewrite to 3rd rewrite
[14:23] <Saviq> seb128, whenever ota opens, didn't get the memo yet
[14:23] <desrt> i really think this is the one this time!
[14:23] <Saviq> seb128, but I imagine next week
[14:23] <seb128> k
[14:25] <seb128> Saviq, btw since you are around, do you know what are the plan for landing desktop mode/wm in unity8? is that going part of regular landings in trunk? or in a branch? is that a different codepath than the phone mode and likely to not create bugs on the phone?
[14:25] <seb128> willcooke, ^ not sure if you figured out those details yet?
[14:25] <Saviq> seb128, we'll land it
[14:25] <Saviq> seb128, will be a gsetting
[14:25] <Saviq> seb128, we'll land it in vivid for sure, next week maybe, even
[14:25] <willcooke> \o/
[14:26] <willcooke> attente_, WM lannding in U8 next week (maybe) ^
[14:27] <seb128> Saviq, great, then work is going to land regularly in trunk? the reason I asked is that we wondered if we should try to pull unity8 from a branch for the desktop-next image or if trunk is good enough
[14:27] <seb128> branch/ppa
[14:27] <Saviq> seb128, we're working on trunk as usual
[14:27] <Saviq> seb128, cherry-picking to rtm
[14:27] <seb128> great
[15:55] <didrocks> my first systemd patches in ubuntu thanks to pitti for uploading ;)
[15:58] <seb128> didrocks, not true, you already had one for ifup0 issue ;-)
[15:58] <didrocks> seb128: oh, forgot about it
[15:59] <didrocks> seb128: ok, well, my first *exciting* patch
[15:59] <seb128> didrocks, congrats in any case!
[15:59] <didrocks> better? :p
[15:59] <didrocks> heh, thanks
[15:59] <seb128> :-)
[15:59] <seb128> it's a bit difficult to read the systemd uploads changes
[16:00] <seb128> they always start by the same big summary of "sync with Debian, here is the remaining changes"
[16:00] <didrocks> yeah, I guess it's the way pitti is doing it as he's always merging back
[16:00] <mlankhorst> join us and maintain it in git :P
[16:00] <seb128> ?
[16:01] <seb128> it's maintained in git afaik
[16:01] <seb128> what do you mean
[16:01] <mlankhorst> ah, not in bzr?
[16:01] <didrocks> not, it's a git branch joined with debian
[16:01] <mlankhorst> ah k
[16:02] <didrocks> which is a little bit annoying as I have upload rights in ubuntu but not commit access there
[16:02] <didrocks> so, I have to git-format patch and find a slave to commit it for me :)
[16:02] <didrocks> (delaying this a little bit)
[16:02] <mlankhorst> hah
[16:10] <Laney> desrt: did you get to look into the ppc64el issue?
[16:10] <Laney> it might be an idea to remove
[16:11] <Laney> stuff is backing up behind it
[16:12] <desrt> ah.  i didn't know it was high priority.
[16:12] <desrt> i've been trying to stay focused on the gvariant work
[16:13] <desrt> can you help me with the correct magic things to type into schroot?
[16:13] <Laney> ah, sorry, communication fail
[16:13] <desrt> nah... i should have taken the hint when cjwatson mentioned that he wanted it fixed too
[16:14] <Laney> screen schroot -c vivid-ppc64el
[16:14] <desrt> nice
[16:14] <Laney> sudo apt-get install should work
[16:14] <desrt> 'screen' to prevent a disconnect from blowing away my world?
[16:15] <Laney> it won't really, this is a persistent environment
[16:15] <Laney> and shared actually, so should have the build-deps I installed the other day already
[16:15] <desrt> handy
[16:16] <desrt> am i behind some sort of firewall that blocks outgoing connections?
[16:19] <seb128> desrt, you might need to define http_proxy
[16:21] <Laney> yeah, not sure what the proxy situation is there
[16:21] <Laney> you can get to the archive though to get glib from there
[16:22] <Laney> or just copy it from my homedir
[17:11] <desrt> Laney: i uploaded it with scp :)
[17:11] <Laney> true hacker
[17:11] <desrt> (was just in a meeting.... starting to look into it now)
[17:29] <desrt> Laney: this is one of those bugs where adding some printf changes the behaviour....
[17:29] <Laney> it is really very sensitive
[17:30] <Laney> like --tap fails but no --tap passes
[17:33] <desrt> so somehow the sorted list of poll fds managed to get itself unsorted
[17:34] <desrt> which caused the merging algorithm to fail
[17:41] <desrt> found the bug
[17:41] <desrt>       if (nextrec->fd > fd)
[17:41] <desrt> tries to make a sorted list ordered by fd
[17:41] <desrt> instead, makes a sorted list ordered by pointer address of the 'fd' struct
[17:41] <desrt> should read if (nextrec->fd->fd > fd->fd)
[17:41] <desrt> yay for tests finding real bugs
[17:44] <desrt> Laney: please vendor pick https://bug11059.bugzilla-attachments.gnome.org/attachment.cgi?id=291741
[17:46] <Laney> thanks
[17:47] <Laney> make is giving me shit so I'll happily change context :)
[17:47] <desrt> sorry for taking so long to finally get to that
[17:47] <desrt> and thanks for the extra poke :)
[17:48] <Laney> no bother
[17:50]  * Laney notes down "continue fighting with make" for after vac
[17:50] <desrt> going away somewhere?
[17:50] <Laney> nein, moving house
[17:50] <desrt> doesn't sound like much of a vacation :)
[17:51] <Laney> hopefully the actual moving is over quickly
[17:51] <Laney> then I can have a "staycation"
[17:51] <desrt> i like those :)
[17:51]  * willcooke -> EOD.
[17:52] <willcooke> Happy weekend all
[17:52] <desrt> willcooke: cheers
[18:14] <mlankhorst> its fridaay
[18:15] <kenvandine> mlankhorst, indeed... it is
[18:16] <kenvandine> :-D
[18:24] <Laney> okay I uploaded glib to debian, if someone sees that it's available to sync please (test build +) sync it
[18:24] <Laney> otherwise I'll pop on at some point and do it
[18:24]  * Laney → moving house, ttyl!
[18:35] <desrt> attente_: thanks for convincing me to rewrite this stuff a 3rd time
[18:35] <desrt> the new code is _so_ clean
[18:40] <attente_> desrt: pretty sure i just sat there while you convinced yourself of that...
[18:42]  * desrt wishes it was possible to have an array of functions in C
[18:45] <sarnold> array of function pointers?
[18:45] <desrt> no.  an array of functions.
[18:45] <sarnold> C won't let you have that :)
[18:45] <desrt> indeed
[18:45] <sarnold> but an array of function pointers, sure...
[18:45]  * desrt wants to do a computed jump using multiplication, not a lookup
[19:11]  * desrt wonders why gcc starts a function with
[19:11] <desrt>    0:	89 f6                	mov    %esi,%esi
[19:12] <desrt> ah.. TIL.
[19:13] <desrt> this masks out the high bits of the 64bit register (ie: only sets the low bits)
[19:19] <desrt> TIL also: there is a cost to using 'int' instead of 'long'
[19:20] <desrt> x86 is nice
[19:20] <desrt> each function in my 'array' is now a single instruction plus 'ret' and the function that does some pointer path and decides which of them to call is 4 instructions plus a computed tailcall
[19:29] <larsu> desrt: switch?
[19:30] <desrt> larsu: in the setup
[19:30] <desrt> this is the code that writes the offsets from a GVariant container (array for example)
[19:31] <desrt> when setting up the container there is a switch over the possible offset sizes
[19:32] <desrt> it stores the function pointer (temporarily) into the space used for the offsets (as a sort of vfunc) and when writing the offsets i call that
[19:33] <larsu> that sounds rather complicated
[19:33] <desrt> the result is dispatch code that looks more trivial than a gobject-style vfunc wrapper and the 'actual function' is 1 instruction
[19:33]  * larsu looks forward to reviewing this, though
[19:33] <desrt> one of these, depending on the offset size:
[19:33] <desrt> 0:	88 14 37             	mov    %dl,(%rdi,%rsi,1)
[19:33] <desrt> 10:	66 89 14 77          	mov    %dx,(%rdi,%rsi,2)
[19:33] <desrt> 20:	89 14 b7             	mov    %edx,(%rdi,%rsi,4)
[19:34] <desrt> 30:	48 89 14 f7          	mov    %rdx,(%rdi,%rsi,8)
[19:34] <desrt> which is why i say that x86 is nice :)
[19:34] <larsu> heh
[19:34] <desrt> the computed-array-index thing is nifty
[19:35] <desrt> these are the functions that i wanted to make an array out of... considering the largest one is 5 bytes in length...
[19:35] <desrt> the function is smaller than the pointer i would have used to refer to it :)
[19:36] <sarnold> an array of function pointers would have been .. silly :)
[19:36] <larsu> :D
[19:36]  * desrt has the thought that x86 misses an 'eval' instruction :)
[19:36] <desrt> ie "take the byte value of this 64bit register and evaluate it as if it were an instruction"
[21:00]  * desrt finishes the 3rd rewrite and is finally happy