| === mfisch is now known as Guest45087 | ||
| didrocks | good morning | 06:46 |
|---|---|---|
| * didrocks is going to look with a fresh eye why this test is failing | 06:50 | |
| pitti | didrocks: bonjour! | 07:04 |
| didrocks | hey pitti :) | 07:07 |
| larsu | good morning! | 07:16 |
| didrocks | hey larsu | 07:25 |
| larsu | hi didrocks! How's it going? | 07:35 |
| didrocks | larsu: it's going, and you, feeling better? :) | 07:36 |
| larsu | didrocks: not really :( | 07:37 |
| seb128 | good morning desktopers | 07:39 |
| seb128 | hey didrocks larsu | 07:39 |
| larsu | hi seb128 :) | 07:41 |
| didrocks | morning seb128 | 07:41 |
| 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:12 |
| larsu | hi willcooke! | 08:14 |
| willcooke | hey larsu | 08:15 |
| seb128 | hey willcooke, what error do you get | 08:16 |
| willcooke | seb128, which log file should I be looking in? | 08:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| willcooke | doesnt seem metacity related, unsurprisingly | 08:21 |
| willcooke | ok U7 working fine, U8 b0rked | 08:21 |
| 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:22 |
| willcooke | I suspect it's a bleeding edge Mir which is the problem, so panic over | 08:24 |
| willcooke | ;) | 08:24 |
| willcooke | Does anyone *want* to go to MWC? | 08:25 |
| willcooke | and work I mean | 08:25 |
| willcooke | not, ya know, look round | 08:25 |
| seb128 | lol | 08:26 |
| seb128 | where/when is it and what can we do that is useful there? | 08:27 |
| seb128 | 24_27 feb in Barcelona? | 08:27 |
| seb128 | larsu, I'm running your updated theme, things are better with it ;-) | 08:28 |
| willcooke | 2->5 March - http://www.mobileworldcongress.com/ | 08:29 |
| * didrocks puts back swim clothes to the closet :p | 08:29 | |
| larsu | seb128: :) | 08:32 |
| === mfisch is now known as Guest3214 | ||
| 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:32 |
| bregma | check /var/log/lighdm/* for errors | 11:33 |
| willcooke | thx bregma | 11:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| bregma | BTW, the Steam client now runs on Unity 8 with the latest PPA build | 11:40 |
| 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:41 | |
| 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:42 |
| willcooke | hrm | 11:45 |
| willcooke | I think libmircommon is still too old | 11:45 |
| willcooke | never mind | 11:46 |
| willcooke | I'll try again later | 11:46 |
| Sweet5hark | protip of the day: do backups. often. | 12:11 |
| willcooke | :D | 12:11 |
| 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:14 |
| * larsu notes to back up his laptop after lunch | 12:16 | |
| 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:17 |
| 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:19 |
| willcooke | meh | 12:20 |
| willcooke | backups are hard and take a long time | 12:20 |
| willcooke | ;) | 12:20 |
| Sweet5hark | willcooke: bullets fear the brave! | 12:21 |
| === alan_g is now known as alan_g|lunch | ||
| desrt | sometimes i feel like i miss out on the best times by not being european | 13:53 |
| 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....... | 13:56 | |
| 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:02 |
| seb128 | hey desrt, happy friday ;-) | 14:03 |
| desrt | seb128: :( | 14:04 |
| 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:05 |
| larsu | tedg: no. ascii. | 14:06 |
| tedg | larsu, DBus needs ascii, but I dont' think we can assume that as input, no? | 14:07 |
| === alan_g|lunch is now known as alan_g | ||
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| desrt | larsu: sorry about the grumpy review. you caught me before coffee. | 14:19 |
| 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:25 |
| larsu | desrt: as I said before, I didn't think anyone but the process that called escape() would call unescape(), hence the critical | 14:26 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| * 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:34 |
| larsu | this is never evaluated... | 14:35 |
| larsu | if p[1] is 0 | 14:35 |
| larsu | and p[0] isn't in the loop | 14:36 |
| desrt | ah. interesting. | 14:36 |
| larsu | so. you want a utf8 check? | 14:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 | |
| 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:50 |
| 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:51 |
| larsu | sorry | 14:52 |
| === Guest3214 is now known as mfisch | ||
| 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:09 |
| 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:10 |
| seb128 | does it do on any toolkit? | 15:11 |
| seb128 | e.g same issue in firefox? | 15:11 |
| larsu | yes | 15:20 |
| larsu | no touch screen | 15:20 |
| larsu | definitely in every app | 15:20 |
| seb128 | k, no idea about that :-/ | 15:24 |
| larsu | me neither. It's annoying | 15:25 |
| larsu | thanks tough | 15:25 |
| larsu | *though | 15:25 |
| seb128 | np | 15:29 |
| seb128 | could be an xorg issue | 15:30 |
| seb128 | though that didn't change much | 15:30 |
| seb128 | but neither did compiz/unity | 15:30 |
| desrt | larsu: new patch looks a lot better | 15:58 |
| desrt | still some nit-picks though :) | 15:58 |
| larsu | desrt: ah very good points. Thanks | 17:00 |
| larsu | desrt: escape() is nullable? | 17:35 |
| larsu | unescape is (and I documented is as such but forgot the (allow-none)) | 17:35 |
| desrt | i would imagine not | 17:36 |
| desrt | maybe i botched the review | 17:36 |
| desrt | nope -- look at the review. the comments are filed inside the docstring for _unscape() | 17:37 |
| larsu | desrt: ah sorry! I misread the escape() in the comment as the header, when it was the explanation | 17:38 |
| larsu | desrt: what's the point of dismissing non-canonical encodings? | 17:42 |
| desrt | "security" | 17:42 |
| desrt | also consistency | 17:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| larsu | desrt: thanks for explainign the non-canonical thing. Makes sense | 17:46 |
| 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:47 |
| 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:48 |
| desrt | because it assumes it to already be valid | 17:49 |
| * desrt engages in some black pointer magic | 17:52 | |
| desrt | let's hope valgrind doesn't get too upset... | 17:52 |
| desrt | (one of those "i technically shouldn't read from this address but it's impossible for it to crash" cases) | 17:53 |
| larsu | desrt: updated | 17:56 |
| larsu | desrt: don't. Or better: Why??? | 17:56 |
| desrt | gvariant alignment requirements | 17:56 |
| desrt | the problem comes with a message like ('a', 'b', 1234) where 'a' is sent as a memfd | 17:57 |
| 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:58 |
| desrt | so we have to cheat a bit when we allocate the buffer for our copy -- shifting it back two bytes | 17:59 |
| 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:00 |
| === alan_g is now known as alan_g|EOW | ||
| desrt | larsu: arghghg. more annotation problems :( | 18:09 |
| larsu | desrt: :( I'll fix those later. gotta run now | 18:22 |
| desrt | larsu: thanks for all the work so far | 18:23 |
| desrt | and apologies for so many roundtrips | 18:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!