[06:46] <didrocks> good morning
[06:50]  * didrocks is going to look with a fresh eye why this test is failing
[07:04] <pitti> didrocks: bonjour!
[07:07] <didrocks> hey pitti :)
[07:16] <larsu> good morning!
[07:25] <didrocks> hey larsu
[07:35] <larsu> hi didrocks! How's it going?
[07:36] <didrocks> larsu: it's going, and you, feeling better? :)
[07:37] <larsu> didrocks: not really :(
[07:39] <seb128> good morning desktopers
[07:39] <seb128> hey didrocks larsu
[07:41] <larsu> hi seb128 :)
[07:41] <didrocks> morning seb128
[08:12] <willcooke> seb128, just upgraded my u8 machine and installed metacity, now u8 session or u7 session will not start :/
[08:12] <willcooke> might just be me though
[08:12] <willcooke> morning btw :D
[08:14] <larsu> hi willcooke!
[08:15] <willcooke> hey larsu
[08:16] <seb128> hey willcooke, what error do you get
[08:17] <willcooke> seb128, which log file should I be looking in?
[08:18] <seb128> .cache/upstart/gnome-session-Unity.log
[08:18] <seb128> that's for unity7
[08:18] <seb128> what happens at login?
[08:18] <willcooke> mlankhorst, I just pulled your latest PPA too, just in case that's involved ^^
[08:18] <didrocks> morning willcooke
[08:18] <willcooke> seb128, @ login -> type password -> nada
[08:19] <seb128> nada like you stay on the greeter?
[08:19] <willcooke> yeah - but
[08:19] <willcooke> :)
[08:19] <seb128> or does the greeter goes away?
[08:19] <willcooke> I removed metacity and now I can log in to U7
[08:19] <willcooke> let me just recheck that
[08:19] <seb128> weird
[08:19] <willcooke> seb128, I might be wasting your time again
[08:19] <willcooke> :)
[08:20] <seb128> lol
[08:20] <seb128> what you describe is weird for sure
[08:20] <seb128> have an extra wm installed shouldn't impact on existing sessions
[08:20] <seb128> but maybe there is something in the daily updates or in the ppa you opted in for
[08:21] <willcooke> doesnt seem metacity related, unsurprisingly
[08:21] <willcooke> ok U7 working fine, U8 b0rked
[08:22] <willcooke> where b0rk = greeter stays on the screen
[08:22] <willcooke> sounds like a Mir issue
[08:22] <willcooke> mlankhorst, is there any new Mir stuff in your ppa?
[08:22] <willcooke> ohhh - mlankhorst is off todayu
[08:22] <willcooke> it's Friday
[08:24] <willcooke> I suspect it's a bleeding edge Mir which is the problem, so panic over
[08:24] <willcooke> ;)
[08:25] <willcooke> Does anyone *want* to go to MWC?
[08:25] <willcooke> and work I mean
[08:25] <willcooke> not, ya know, look round
[08:26] <seb128> lol
[08:27] <seb128> where/when is it and what can we do that is useful there?
[08:27] <seb128> 24_27 feb in Barcelona?
[08:28] <seb128> larsu, I'm running your updated theme, things are better with it ;-)
[08:29] <willcooke> 2->5 March - http://www.mobileworldcongress.com/
[08:29]  * didrocks puts back swim clothes to the closet :p
[08:32] <larsu> seb128: :)
[11:32] <bregma> willcooke, mlankhorst's PPA definitely has the latest Mir, now with dependencies on new protobuf still stuck in -proposed, so will probably munge your system until that's cleared up (which may have happened by now)
[11:33] <bregma> check /var/log/lighdm/* for errors
[11:33] <willcooke> thx bregma
[11:35] <willcooke> yup
[11:35] <willcooke> [+36.81s] DEBUG: Seat seat0: Creating display server of type mir
[11:35] <willcooke> [+36.81s] DEBUG: Using VT 8
[11:35] <willcooke> [+36.81s] DEBUG: DisplayServer: Logging to /var/log/lightdm/unity-system-compositor.log
[11:35] <willcooke> [+36.81s] DEBUG: Launching process 2377: /usr/sbin/unity-system-compositor.sleep --file '/run/lightdm-mir-0' --from-dm-fd 12 --to-dm-fd 21 --vt 8 --enable-hardware-cursor=true
[11:35] <willcooke> [+36.81s] DEBUG: DisplayServer: Waiting for system compositor for 60s
[11:35] <willcooke> [+36.93s] DEBUG: DisplayServer: Compositor closed communication channel
[11:35] <willcooke> [+36.93s] DEBUG: Process 2377 exited with return value 127
[11:35] <willcooke> [+36.93s] DEBUG: DisplayServer: Unity system compositor stopped
[11:35] <willcooke> [+36.93s] DEBUG: Releasing VT 8
[11:36] <willcooke> [+36.93s] DEBUG: Seat seat0: Display server stopped
[11:36] <willcooke> and then in the u-s-c.log:
[11:36] <willcooke> /usr/sbin/unity-system-compositor: relocation error: /usr/lib/x86_64-linux-gnu/libmirplatform.so.4: symbol _ZN3mir7logging3logENS0_8SeverityERKSs, version MIR_COMMON_3 not defined in file libmircommon.so.3 with link time reference
[11:37] <bregma> that nutty Mir and it's totally unstable ABI
[11:37] <willcooke> so I'm assuming that libmirplatform 4 doesnt work with libmircommon 3
[11:37] <bregma> try adding -proposed to your sources and updating
[11:37] <willcooke> oooh
[11:37] <willcooke> plan
[11:37] <willcooke> !
[11:37] <bregma> I take no responsibility for the result
[11:38] <willcooke> ha
[11:38] <willcooke> if it breaks I'll give up on that for today
[11:38] <bregma> (I have -proposed on on my test machine, it was fine yesterday)
[11:39] <willcooke> do I need to add it to everything in /etc/apt/sources.list?
[11:39] <willcooke> maybe just main?
[11:39] <bregma> I think just main is all you really need for this
[11:40] <bregma> BTW, the Steam client now runs on Unity 8 with the latest PPA build
[11:41] <willcooke> O_o
[11:41] <willcooke> whaaa!
[11:41] <willcooke> that's awesome!  thank you!
[11:41] <willcooke> bregma, in Xmir right?
[11:41] <bregma> yes
[11:41]  * willcooke upgrades to proposed and has some qtmir stuff upgrading
[11:42] <bregma> updated qtmir is also i the PPA
[11:42] <willcooke> ahh - and also libmirplatform4 :)
[11:42] <bregma> it's depndencies all the way down
[11:42]  * bregma gos to take the dog for a walk
[11:42] <willcooke> ttfn
[11:45] <willcooke> hrm
[11:45] <willcooke> I think libmircommon is still too old
[11:46] <willcooke> never mind
[11:46] <willcooke> I'll try again later
[12:11] <Sweet5hark> protip of the day: do backups. often.
[12:11] <willcooke> :D
[12:14] <Sweet5hark> for some reason my work notebook did a hard reset and didnt boot through after that. I had all the joy of system recovery and expected some data to be lost, with the last full backup 6 months old.
[12:16]  * larsu notes to back up his laptop after lunch
[12:17] <Sweet5hark> I had to boot from a LiveCD, mount the encrypted drive (crossing my fingers) and then tell fsck, which already screamed at me that my primary superblock is gone, to just "fix(y)?" 2 bazillion things into the blind on the fs ...
[12:19] <willcooke> yikes
[12:19] <Sweet5hark> I could do a a full backup then, and even boot -- though I am not sure about the extend of corruption. My syslog for the event is just graced with a huge set of interesting binary characters ...
[12:20] <willcooke> meh
[12:20] <willcooke> backups are hard and take a long time
[12:20] <willcooke> ;)
[12:21] <Sweet5hark> willcooke: bullets fear the brave!
[13:53] <desrt> sometimes i feel like i miss out on the best times by not being european
[13:56] <larsu> everything's nicer here, not only the time zone
[13:56] <larsu> you shuld consider moving ;)
[13:56]  * larsu knows just the right city for you.......
[14:02] <desrt> i hope it's not berlin
[14:02] <larsu> ts
[14:02] <larsu> tedg: https://bugzilla.gnome.org/show_bug.cgi?id=741156
[14:02] <ubot5`> Gnome bug 741156 in gdbus "gdbus: add g_dbus_object_path_{un,}escape" [Normal,New]
[14:03] <seb128> hey desrt, happy friday ;-)
[14:04] <desrt> seb128: :(
[14:05] <tedg> larsu, Cool, I'd add some 16-bit characters to your tests: http://bazaar.launchpad.net/~indicator-applet-developers/pay-service/trunk.15.04/view/head:/tests/dbus-interface-tests.cpp#L262
[14:05] <tedg> larsu, That screwed me up once already :-)
[14:05] <desrt> i hate it already :D
[14:05] <desrt> double-escaped utf8?  awesome
[14:06] <larsu> tedg: no. ascii.
[14:07] <tedg> larsu, DBus needs ascii, but I dont' think we can assume that as input, no?
[14:08] <tedg> larsu, Ah, also you don't handle the first character can't be a number case.
[14:08] <larsu> tedg: ya systemd does this as well, but the spec says nothing of the sort
[14:09] <larsu> tedg: what do you want to encode?
[14:09] <tedg> larsu, Hmm, I'm pretty sure Lennart linked me to the place. Let me look.
[14:10] <desrt> btw: if we allow non-ascii in these strings then you either need to decide if you're going to enforce valid utf8 (seems a bad idea) or document that the API is not returning a string but rather a guint8[]
[14:10] <larsu> desrt: why is utf8 a bad idea?
[14:11] <larsu> tedg: http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-marshaling-object-path
[14:11] <tedg> larsu, Hmm, okay, I can't find it. I can't imagine that I would have done it for consistency with systemd...
[14:11] <desrt> because if this is encoding filenames for example (which i suspect it is) then enforcing utf8 will cause problems
[14:12] <tedg> larsu, The thing I was encoding where payment item ids, which are UTF8 and configured by the application developer. So they could be "magic-potion-35" or what ever that is in Chinese.
[14:12] <larsu> tedg: ya I was suspecting this as well and I'd argue that this is a bad idea...
[14:12] <tedg> Why not convert to utf8?
[14:13] <larsu> utf8 should work by ignorance, no?
[14:13] <tedg> I'm not as worried about filesystem names. But it seems in that case you should convert to utf8.
[14:13] <larsu> it does byte-wise escaping...
[14:19] <desrt> larsu: sorry about the grumpy review.  you caught me before coffee.
[14:25] <larsu> desrt: no worries. This should indeed be >=, not > (but nul isn't a problem because of lazy evaluation)
[14:25] <larsu> desrt: as for input, I'd argue the string should be utf8 as per glib convention. Doi you think we need to verify it?
[14:26] <larsu> desrt: as I said before, I didn't think anyone but the process that called escape() would call unescape(), hence the critical
[14:29] <desrt> you really need to make that a lot more clear
[14:29] <desrt> because i might think that i can call that on systemd unit file object paths in order to grok them, for example
[14:30] <larsu> what else would you want? Taking an error?
[14:30] <larsu> if you say this is something that people might want to do, ok
[14:30] <desrt> well, there is a conflict here
[14:30] <desrt> we must choose one property that we want more:
[14:31] <desrt> 1) canonical encoding (with non-canonical forms rejected)
[14:31] <desrt> 2) a mapping that always succeeds
[14:31] <desrt> you can't have both
[14:31] <desrt> (right now we have neither...)
[14:31] <desrt> i'd prefer a simple NULL return in the invalid case, though
[14:32] <larsu> (2) can never be correct
[14:32] <larsu> so ya, (1)
[14:32] <desrt> so then return NULL if it's non-canonical
[14:32] <larsu> I'd still accept the ambiguous ones like I do now
[14:32] <larsu> desrt: this is what the code did before and I changed it ...
[14:32] <larsu> but I think you convinced me
[14:33] <desrt> my security spidy-sense is tingling here
[14:33] <desrt> this is the sort of function that somebody somewhere is going to expose to people sending untrusted strings to it
[14:33] <larsu> what bad can happen?
[14:33] <desrt> i can imagine a few things
[14:34]  * larsu listens
[14:34] <desrt> one is that there is a whole class of attacks where non-equal-but-equivalent encodings can be used to attack systems
[14:34] <desrt> which is why non-canonical-encoded utf8 is now rejected
[14:34] <desrt> there have been all sorts of issues there in the past...
[14:34] <desrt> the other is that we can cause crashes in the receiving program.... like with your p[2] issue in the patch
[14:35] <larsu> this is never evaluated...
[14:35] <larsu> if p[1] is 0
[14:36] <larsu> and p[0] isn't in the loop
[14:36] <desrt> ah.  interesting.
[14:36] <larsu> so. you want a utf8 check?
[14:37] <desrt> no
[14:37] <desrt> i think i prefer the 'this is not utf8' annotation on the return value
[14:37] <larsu> I didn't know that that is convention - if you have an untrusted string, check it before giving it to glib functions
[14:37] <desrt> absolutely
[14:37] <desrt> almost everything in glib assumes that it's getting valid utf8
[14:37] <desrt> a/glib/glib world/
[14:38] <larsu> if I return uint8*, won't that break the 99% case?
[14:38] <desrt> you don't actually return guint8
[14:38] <desrt> you just annotate that you do
[14:38] <larsu> I want to put this into another string-processing function but now need to cast
[14:38] <larsu> oh. what?
[14:38] <desrt> * Returns: (transfer full) (array zero-terminated=1 length=length) (element-type guint8):
[14:39] <desrt> something like that
[14:39] <desrt> minus the 'length' crap
[14:39] <larsu> but then I have the problem in bindings
[14:39] <desrt> that will prevent python from assuming that the string is utf8 and trying to transcode it to unicode
[14:39] <larsu> i.e., I get a byte in python, not a string
[14:39] <desrt> you'll get a bytestring in python
[14:39] <desrt> which is what you want....
[14:40] <larsu> and then take a byte string in unescape() and return a string?
[14:40] <desrt> yes
[14:40] <larsu> interesting
[14:40] <larsu> thanks
[14:43] <desrt> i would be nice if we could use the kdbus transition as a time to relax object path rules
[14:43] <larsu> desrt: do I need to annotate that in the same way?
[14:43] <desrt> but i don't think it's really possible :/
[14:43] <desrt> larsu: hm?
[14:43] <larsu> the input parameter to unescape()
[14:43] <desrt> yes
[14:43] <desrt> wait.  no.
[14:43] <desrt> that will always be a ascii string
[14:44] <desrt> you need to annotate the input to escape() though
[14:44] <desrt> in order to allow the wider range of stuff that could be in there
[14:44] <larsu> the input to escape is a utf8 string...
[14:44] <desrt> maybe it's a filename?
[14:44] <larsu> it's docuemnted as must be a utf8 string
[14:44] <larsu> (now)
[14:45] <larsu> hm, I guess I misunderstood you before then
[14:45] <larsu> I thought you meant escape() is utf8 -> bytestring and unescape() the other way around
[14:46] <desrt> escape() is bytestring -> ascii (with heavy restrictions)
[14:46] <desrt> unescape is therefore ascii -> bytestring
[14:46] <larsu> and both of those need annotations on both input and return params?
[14:47] <desrt> the ascii is fine as just a gchar*
[14:47] <desrt> since ascii is a subset of utf8
[14:47] <larsu> makes sense
[14:47] <desrt> of course, if you find any characters out of the range of the object path rules (including non-ascii utf8 content) then it should be rejected...
[14:48] <larsu> you just said I don't have to verify utf8-iness
[14:48] <desrt> on return
[14:48] <desrt> there's no way that an escaped string should have utf8 in it
[14:48] <desrt> but an unescaped string may... or may not...
[14:48] <larsu> why isn't it enough to escape byte-wise?
[14:48] <desrt> it could be anything at all
[14:49] <desrt> you _should_ escape bytewise
[14:49] <larsu> that's what I'm doing..
[14:49] <desrt> there should be absolutely nothing utf8-specific in these functions at all
[14:49] <larsu> right. You just said I should reject non-ascii utf8 content
[14:49] <desrt> i'm just noting that you should reject stuff according to the dbus rules (ie: outside of A-Za-z0-9_ or whatever) and this will automatically exclude non-ascii utf8 content
[14:49]  * larsu is throroughly confused
[14:50] <larsu> yes. That's what my plan was
[14:50] <larsu> (and what the patch does right now)
[14:50] <larsu> all that's missing are the annotations, then
[14:50] <desrt> the patch you posted rejects nothing...
[14:51] <larsu> it prints a critical
[14:51] <desrt> andthing that's not a _ gets copied straight through...
[14:51] <larsu> but ya, we already discussed that I'll change this to returning NULL, like I had before
[14:51] <desrt> okay
[14:51] <larsu> desrt: I changed it because I checked how systemd does it
[14:51] <desrt> i think we're just confusing each other at this point -- i'll wait for the patches :)
[14:51] <larsu> ya, I think so too
[14:52] <larsu> sorry
[15:09] <larsu> seb128: I'm having the "can't click inside windows anymore" problem again
[15:09] <larsu> desrt: patch updated. Thanks for the feedback
[15:09] <seb128> larsu, I don't even understand that bug, what do you mean by "can't click"?
[15:10] <seb128> does it happen to all windows?
[15:10] <larsu> seb128: yes. No mouse input events are forwarded to any windows.
[15:10] <larsu> seb128: mouse input in unity works (panel, dash, ...). Keyboard works everywhere
[15:10] <seb128> do you have a touch screen?
[15:11] <seb128> does it do on any toolkit?
[15:11] <seb128> e.g same issue in firefox?
[15:20] <larsu> yes
[15:20] <larsu> no touch screen
[15:20] <larsu> definitely in every app
[15:24] <seb128> k, no idea about that :-/
[15:25] <larsu> me neither. It's annoying
[15:25] <larsu> thanks tough
[15:25] <larsu> *though
[15:29] <seb128> np
[15:30] <seb128> could be an xorg issue
[15:30] <seb128> though that didn't change much
[15:30] <seb128> but neither did compiz/unity
[15:58] <desrt> larsu: new patch looks a lot better
[15:58] <desrt> still some nit-picks though :)
[17:00] <larsu> desrt: ah very good points. Thanks
[17:35] <larsu> desrt: escape() is nullable?
[17:35] <larsu> unescape is (and I documented is as such but forgot the (allow-none))
[17:36] <desrt> i would imagine not
[17:36] <desrt> maybe i botched the review
[17:37] <desrt> nope -- look at the review.  the comments are filed inside the docstring for _unscape()
[17:38] <larsu> desrt: ah sorry! I misread the escape() in the comment as the header, when it was the explanation
[17:42] <larsu> desrt: what's the point of dismissing non-canonical encodings?
[17:42] <desrt> "security"
[17:42] <desrt> also consistency
[17:43] <desrt> the gist is thus:
[17:43] <desrt> someone might resonably assume that string comparison (or building hashtables, or anything else) on escaped strings is equivalent to doing it with the unescaped version
[17:43] <desrt> and it ought to be
[17:43] <larsu> man, I just cleaned up the loop, now I have two places to return an error from
[17:43] <desrt> but if that assumption is false, someone could exploit it in unexpected ways
[17:43] <larsu> thanks for pointing out the hi = lo = 0 one
[17:43] <desrt> larsu: maybe not
[17:43] <desrt> you could add another && to that already-long else if
[17:44] <desrt> && (hi || lo) && !is_ascii((hi<<4)|lo)
[17:44] <larsu> and do (hi << 4 | lo) three times?
[17:44] <larsu> ya...
[17:44] <desrt> your choice
[17:44] <larsu> and then again in the append_c
[17:44]  * larsu thinks
[17:44] <desrt> btw: _strictly_ << and | are undefined on signed ints :)
[17:45] <desrt> (erm.  maybe that's actually only true for signed ints that contain negative values.  i always forget...)
[17:45] <larsu> I know, but then I thought about it and didn't care
[17:45] <desrt> fair enough :)
[17:45] <larsu> it's true in general, but we know the precise range for those numbers...
[17:46] <larsu> desrt: thanks for explainign the non-canonical thing. Makes sense
[17:47] <desrt> larsu: you used to be able to use utf8 to encode ascii characters like '.' and '/'
[17:47] <desrt> or strings like "../../" for example
[17:47] <desrt> you might imagine that this resulted in quite some fun
[17:47] <larsu> ugh..
[17:48] <desrt> now the rule is that you must take the shorest possible form
[17:48] <desrt> which is ... just sane
[17:48] <desrt> but pretty much everything that handles utf8 in glib-world doesn't do that check
[17:49] <desrt> because it assumes it to already be valid
[17:52]  * desrt engages in some black pointer magic
[17:52] <desrt> let's hope valgrind doesn't get too upset...
[17:53] <desrt> (one of those "i technically shouldn't read from this address but it's impossible for it to crash" cases)
[17:56] <larsu> desrt: updated
[17:56] <larsu> desrt: don't. Or better: Why???
[17:56] <desrt> gvariant alignment requirements
[17:57] <desrt> the problem comes with a message like ('a', 'b', 1234) where 'a' is sent as a memfd
[17:58] <desrt> gvariant would encode that like so: 'a \0 'b \0 \4 \3 \2 \1 \2 \4, noting that the int \4\3\2\1 is at an offset that is a multiple of 4
[17:58] <desrt> but if we take off the "a\0" from the start (because it's a memfd) then the \4\3\2\1 part now comes aligned at an offset of 2 mod 4 inside of the second message part
[17:59] <desrt> so we have to cheat a bit when we allocate the buffer for our copy -- shifting it back two bytes
[18:00] <desrt> the nice bit is that we only ever cheat by 7 bytes maximum and it will always result in a more-aligned pointer (since the kernel does the same thing for us) -- so we cannot possibly crash
[18:00] <desrt> ...unless we're on a system that has a page size of less than 8 bytes
[18:09] <desrt> larsu: arghghg. more annotation problems :(
[18:22] <larsu> desrt: :( I'll fix those later. gotta run now
[18:23] <desrt> larsu: thanks for all the work so far
[18:23] <desrt> and apologies for so many roundtrips