| robert_ancell | desrt, around? | 00:17 |
|---|---|---|
| desrt | robert_ancell: hey | 00:30 |
| desrt | robert_ancell: can you let me know what you want to do? | 00:30 |
| robert_ancell | desrt, hi. I was wondering if you knew if there was a way to mark dbus arguments as optional | 00:30 |
| robert_ancell | (in the XML) | 00:31 |
| desrt | dbus doesn't work that way | 00:31 |
| desrt | it's best to think of methods as having static signatures | 00:32 |
| robert_ancell | So I should make two method? i.e. Login (username, password,) and LoginWithOTP (username, password, otp) | 00:32 |
| desrt | precisely. | 00:33 |
| robert_ancell | desrt, ta | 00:33 |
| desrt | you could also do the usual crap and add an a{sv} everywhere | 00:33 |
| robert_ancell | NOOOOOOO :) | 00:33 |
| desrt | so you can pass {'opt': <'whatever'>} | 00:33 |
| desrt | robert_ancell: since you're here... wanna chat about GDateTime | 00:33 |
| desrt | ? | 00:33 |
| robert_ancell | The other option I was thinking was allowing otp to be "". | 00:34 |
| robert_ancell | desrt, yes please. | 00:34 |
| desrt | so what are you trying to do there? | 00:34 |
| desrt | are you in a situation where you may need to parse an unknown subset of ISO8601? | 00:35 |
| robert_ancell | desrt, I have snapd returning ISO date time strings, so I had to write my own parser (have done this before too) | 00:35 |
| desrt | i agree that it would be useful to have a way to turn those into GDateTime directly | 00:35 |
| desrt | but why all the need for parsing dates without times, or times without dates, etc? | 00:35 |
| robert_ancell | desrt, when I converted it to an upstream patch, I figured if it was going to say ISO8601 it should be compliant. | 00:35 |
| robert_ancell | So I implemented the spec as is. | 00:35 |
| robert_ancell | I think it's unlikely that the more obscure formats will be actively used. | 00:36 |
| robert_ancell | But I could imagine downloading a CSV that I wanted to parse that only had times in it. | 00:37 |
| desrt | sure | 00:37 |
| desrt | which could make sense, if you had a date | 00:37 |
| desrt | but using GDateTime to store only time is really weird | 00:38 |
| desrt | and using it to store only dates is not a lot better | 00:38 |
| robert_ancell | Yeah, which you would either know from context or some other date | 00:38 |
| desrt | i can understand if the microseconds field is missing, we take it to be 0 | 00:38 |
| desrt | but other than that, ... | 00:38 |
| robert_ancell | desrt, it won't store just times - g_date_time_new returns NULL in that case. | 00:38 |
| desrt | It not considered a programmer error for the values to this function to be out of range, but in the case that they are, the function will return NULL. | 00:39 |
| desrt | weird! | 00:39 |
| desrt | i doubt i would do that again today =) | 00:39 |
| robert_ancell | heh | 00:39 |
| desrt | so basically, i'd take a really simplified version that breaks out fully-specified ISO8601 strings | 00:40 |
| desrt | and returns GDateTime | 00:40 |
| robert_ancell | desrt, why not the current code? | 00:40 |
| desrt | because it's complicated, and the flags field is ugly | 00:40 |
| robert_ancell | desrt, if I move the flags to a g_date_time_new_full wouldn't that bypass that issue? | 00:41 |
| robert_ancell | Without the flags you cannot tell the accuracy of the strings, which could be very important. | 00:41 |
| desrt | that's my point: if the string is not fully-specified, fail | 00:42 |
| desrt | i'd make exactly two exceptions: | 00:42 |
| desrt | - missing microseconds field | 00:42 |
| desrt | - missing timezone | 00:42 |
| desrt | in the case of the timezone, i'd allow it to be fed in from outside to be used in case it is missing in the string | 00:43 |
| robert_ancell | desrt, define "full-specified" | 00:43 |
| desrt | yyyy-mm-dd(T)hh:mm:ss(.mmmmmm)( +-TZ) | 00:43 |
| desrt | ie: a precise time, in a specific day | 00:43 |
| robert_ancell | what if you get yymmdd? | 00:44 |
| desrt | it's not enough to construct GDateTime, since it misses the time | 00:44 |
| robert_ancell | I mean yyymmddThhmmss.mmmmm | 00:44 |
| desrt | is that valid ISO8601? | 00:45 |
| robert_ancell | yes | 00:45 |
| desrt | ...wow | 00:45 |
| robert_ancell | That's why the parser is like it is... | 00:45 |
| desrt | so let's change the name of the function | 00:45 |
| desrt | i'm really not super interested in supporting weird and not-commonly-used features of a spec just for the sake of it | 00:45 |
| desrt | particularly if it makes the API suck more | 00:46 |
| desrt | (aside: one weird feature that may actually be worth supporting is ISO week dates... like 2016-W34-7) | 00:46 |
| robert_ancell | But it won't make the API any differntly... | 00:46 |
| desrt | wikipedia says "ISO 8601 prescribes, as a minimum, a four-digit year [YYYY] to avoid the year 2000 problem." | 00:46 |
| desrt | it will allow dropping the flags enum... | 00:46 |
| desrt | since either you will have a GDateTime with all of the things set, or you will get a failure | 00:47 |
| robert_ancell | desrt, if the flags is the issue, then why not change to g_date_time_new_from_iso8601 (text) and g_date_time_new_from_iso8601_full (text, year, month, day, flags) | 00:47 |
| desrt | because then we may end up parsing something that is not a date/time, without knowing it | 00:48 |
| desrt | what would you do? just assume midnight? | 00:48 |
| robert_ancell | desrt, and the current patch gives you a GDateTime with all of the things set or a failure. | 00:48 |
| robert_ancell | desrt, yes, you'd assume midnight | 00:49 |
| desrt | that's precisely what i don't want | 00:49 |
| desrt | consider as well, that midnight is a particularly awful time to choose | 00:49 |
| robert_ancell | desrt, ok, then g_date_time_new_from_iso8601_full (text, year, month, day, hour, minute, second, flags) | 00:49 |
| desrt | since it's very likely to be a different day in a neighbouring timezone, or even with the application of daylight savings time or not | 00:49 |
| robert_ancell | and the simpler case rejects anything without all the fields set | 00:50 |
| desrt | can we just skip the _full? | 00:50 |
| desrt | seriously... what is your usecase here? | 00:50 |
| robert_ancell | I can imagine getting data without seconds or hours set and I wouldn't want to have to write an entire parser in these cases. | 00:51 |
| desrt | other than some imagined file that you want to parse that contains a bunch of ISO8601 tests for edge cases... | 00:51 |
| robert_ancell | e.g. "2016-08-29T12:51" | 00:51 |
| robert_ancell | or timestamps like "12:51:32.1234567" in a log, that I know all occurred today | 00:52 |
| desrt | take a look at rfc3339 for example | 00:53 |
| desrt | it defines a profile of ISO8601 that is pretty close to what i think we'd actually want to support | 00:53 |
| robert_ancell | desrt, ok, so you want g_date_time_new_from_rfc3339 | 00:54 |
| desrt | that would be a lot more reasonable, imho | 00:54 |
| desrt | of course, we can't even really properly support it | 00:57 |
| desrt | since it has support for leap seconds, and we don't | 00:57 |
| robert_ancell | desrt, and would you support 2016-W34? It is in the RFC | 00:58 |
| desrt | i don't consider supporting it to be important | 00:58 |
| desrt | but it would be a cool feature that could be understood unambiguously, and would not complicated the API | 00:59 |
| robert_ancell | I mean that form is only accurate to 7 days | 00:59 |
| robert_ancell | as opposted to 2016-W34-7 | 00:59 |
| desrt | oh. no. of course not. | 00:59 |
| desrt | and indeed, it should only be accepted if a time is given, as well | 00:59 |
| desrt | it may also be fun to support rfc822 date/time... which, reading the spec, is hilariously US-centric... | 01:00 |
| robert_ancell | desrt, ok to push "GTimeZone: Support the Unicode minus character"? | 01:01 |
| desrt | basically, i think it may be interesting to do something more like g_date_time_parse() which is guaranteed to accept rfc3339 and other formats as we see fit | 01:02 |
| desrt | bug link again, sorry? | 01:02 |
| robert_ancell | https://bugzilla.gnome.org/show_bug.cgi?id=753459 | 01:02 |
| ubot5 | Gnome bug 753459 in general "GDateTime: Add conversion functions from/to ISO 8601 strings" [Enhancement,New] | 01:02 |
| desrt | why is this needed? | 01:03 |
| desrt | does anyone use it for anything? | 01:03 |
| robert_ancell | desrt, because ISO8601 strings are allowed to use that character | 01:03 |
| * desrt sighs | 01:03 | |
| * desrt slowly comes to realise that ISO8601 is completely unreasonable, and wants nothing to do with it | 01:04 | |
| robert_ancell | desrt, I guess if you just want RFC 3339 then it's not required | 01:05 |
| robert_ancell | It seems to specify "-" as the minus character | 01:05 |
| desrt | RFC 3339 explicitly requires the hyphen (-) symbol to represent negative offsets and does not allow for use of the minus (−) symbol | 01:05 |
| desrt | +1 | 01:05 |
| robert_ancell | ok, I'll make a simplified parser and document the caveats | 01:05 |
| desrt | make sure you support " " instead of T | 01:06 |
| desrt | the rfc3339 mentions that it ought to be supported, but doesn't do a good job of drawing attention to this fact with the examples, nor the grammar | 01:07 |
| robert_ancell | and lowercase too it seems | 01:07 |
| robert_ancell | the wording is super vague | 01:07 |
| robert_ancell | Applications using this syntax may choose, for the sake of | 01:07 |
| robert_ancell | readability, to specify a full-date and full-time separated by | 01:07 |
| robert_ancell | (say) a space character. | 01:07 |
| robert_ancell | or (say) any other character :) | 01:07 |
| robert_ancell | desrt, thanks for the review | 01:08 |
| desrt | cool. irccloud is having a very bad day, it seems. | 01:13 |
| desrt | last thing i saw was me mentioning to make sure you support spaces instead of 'T's | 01:13 |
| desrt | robert_ancell: in any case, i'm gonna go make some food. got busy working and forgot to eat dinner tonight :) | 01:18 |
| desrt | robert_ancell: sorry for rejecting pretty much everything :( | 01:18 |
| robert_ancell | desrt, I just pointed out how vague the spec was | 01:19 |
| desrt | robert_ancell: k. | 01:23 |
| desrt | happy monday, then :) | 01:23 |
| pitti | Good morning | 04:36 |
| === jbicha_ is now known as jbicha | ||
| hikiko | hello! | 04:51 |
| Sweet5hark1 | moin | 07:44 |
| pitti | hey Sweet5hark1 | 07:59 |
| Sweet5hark1 | bonjour pitti! | 08:02 |
| seb128 | good morning deskopers | 08:08 |
| pitti | bonjour seb128 ! as-tu eu un bon w.e.? | 08:08 |
| seb128 | salut pitti, oui, mais trop chaud ! et toi ? | 08:08 |
| pitti | seb128: je vais bien aussi, merci ! Annett et moi avons aidé un collègue à déménager | 08:09 |
| pitti | donc on a des muscles dolores :) | 08:09 |
| seb128 | ah ok, assis devant l'ordinateur pour du repos aujourd'hui alors ;-) | 08:10 |
| pitti | seb128: héhé -- alors que j'ai couru ce matin | 08:11 |
| seb128 | quelle energie ! | 08:11 |
| pitti | it was actually good for relaxing muscles | 08:12 |
| Trevinho | Morning! | 08:19 |
| seb128 | hey Trevinho, how are you? had a good w.e? | 08:20 |
| Trevinho | Hey seb128... | 08:21 |
| Trevinho | Yeah full of things... | 08:21 |
| Trevinho | Pool on Saturday then some "sagre" (kind of popular fairs where food is made by locals and you eat in big tents) | 08:22 |
| Trevinho | Wine tasting.... And Fireworks! | 08:22 |
| Trevinho | https://usercontent.irccloud-cdn.com/file/MkD6GqoW/IMG_20160828_234051.jpg | 08:23 |
| Trevinho | You, seb128? | 08:23 |
| seb128 | Trevinho, nice! | 08:24 |
| seb128 | Trevinho, here it was less fancy, walked a bit around, bbq on saturday evening otherwise mostly relaxed/didn't do much, it was like 37°C so played some video games inside and read a bit | 08:25 |
| Trevinho | Ah.... Really hot... | 08:25 |
| Trevinho | Here it has been hot too, but I drove to some hills to get some cool air for free :-) | 08:26 |
| seb128 | :-) | 08:28 |
| === JanC is now known as Guest45177 | ||
| === JanC_ is now known as JanC | ||
| duflu | Trevinho: Do we have bugs open for the new visual glitches in Unity7 yet? (grey bars at top and right edges, and transparent panel) | 08:41 |
| Trevinho | duflu: Yes and a fix is there, but waiting for approval | 08:58 |
| Trevinho | Or... Different fix | 08:58 |
| duflu | Trevinho: Cool thanks. I didn't want to be another one who just assumes a fix is coming when it isn't :) | 08:58 |
| desrt | morning, peeps | 09:23 |
| desrt | it's so early that europe hasn't even woken up yet... | 09:28 |
| * desrt finds herself wondering how timezones work again | 09:28 | |
| pitti | hey desrt! | 09:30 |
| desrt | guten Morgen | 09:31 |
| Trevinho | https://i.imgur.com/8FNGSZA.jpg | 09:41 |
| pitti | Trevinho: oh dear -- it's i*n*dentation styles | 09:42 |
| pitti | software engineers have also been known to have OCD :) | 09:42 |
| desrt | this sign is pretty accurate | 09:43 |
| Trevinho | :-) | 09:43 |
| desrt | somewhat shamefully, i have to admit that my dinner choices for last night included ordering a pizza, or consuming a full bag of chips as a meal... both would likely have included caffeinated beverages. | 09:44 |
| desrt | i didn't actually do either of them... but only because pizzapizza's website wasn't working, and i was too lazy to go out and buy the chips. | 09:45 |
| Trevinho | :-D | 09:46 |
| duflu | Trevinho: Excuse me... or else I risk my current coffee being dinner | 10:32 |
| === hikiko is now known as hikiko|ln | ||
| mitya57 | jbicha, please review http://bazaar.launchpad.net/~ubuntu-desktop/rhythmbox/ubuntu/revision/275 — is that what you really intended to add? | 11:25 |
| === hikiko|ln is now known as hikiko | ||
| * desrt sees that robert_ancell uploaded another version of the patch and couldn't help himself | 11:35 | |
| === dpm is now known as dpm-afk | ||
| desrt | ISO week numbering... my goodness. | 13:07 |
| seb128 | desrt, ? | 13:08 |
| desrt | robert_ancell's patch to add ISO8601 support to glib... i suggested that he trim it down to only rfc3339, but he couldn't help himself, and some 8601 features snuck back in | 13:09 |
| desrt | ...like week numbering | 13:09 |
| desrt | which introduces a whole bunch of edgecases | 13:10 |
| seb128 | is there different way to number weeks? | 13:10 |
| desrt | no. there is only one way | 13:11 |
| desrt | but it's complicated and confusing and sometimes produces strange results | 13:11 |
| desrt | like week 1 of 2015 is partially in 2014 | 13:11 |
| desrt | and week 53 is partially in 2016 | 13:11 |
| desrt | so you have dates that are correctly (and canonically) written as 2015-W01-1 and 2015-W53-7 which are actually not in 2015 at all... | 13:12 |
| seb128 | fun | 13:12 |
| desrt | and of course, this is where bugs start coming | 13:12 |
| qengho | Oh, that's the one with the Thursday rule? | 13:24 |
| qengho | ...yep, it is. That is a fun one. | 13:26 |
| seb128 | hey qengho | 13:28 |
| qengho | seb128: hey! Now's the time to regret not adopting French metric weeks, n'est pas? | 13:29 |
| seb128 | lol, maybe not ;-) | 13:29 |
| seb128 | those sound weird | 13:30 |
| seb128 | but I guess it's like everything, if they were in use we would know them and they would sound normal | 13:30 |
| jbicha | mitya57: yes, that looks better | 13:37 |
| === dpm-afk is now known as dpm | ||
| jbicha | seb128: could you try restarting https://people.canonical.com/~platform/desktop/versions.html I broke it this weekend :( | 13:50 |
| * Sweet5hark got the color of the toolbar background right with libreoffice and gtk 3.20, it seems. | 13:58 | |
| Sweet5hark | next up: the buttons themselves (what worked on xenial, doesnt work here). | 13:58 |
| Sweet5hark | Hm, if you do a change in a C++ source file and expect different behaviour w/o doing recompilation how do you call that? asking for a friend. | 14:11 |
| pitti | Sweet5hark: how do you mean? I'd call it "use a scripting language, dude" | 14:22 |
| jbicha | ximion: is there a reason yakkety shouldn't have https://anonscm.debian.org/git/collab-maint/software-properties.git/tree/debian/patches/0004-Implement-PackageKit-support.patch | 14:22 |
| Sweet5hark | pitti: I hear you volunteer to do a high performance rewrite of LibreOffice in Python? exciting! | 14:23 |
| pitti | Sweet5hark: I still don't understand your question, if it was meant seriously | 14:24 |
| pitti | someone who expects a runtime change after changing a C++ source file without recompilation just needs to be taught how compiled languages work.. | 14:24 |
| jbicha | is signon-plugin-password used for anything important? because it's no longer on the yakkety install disk: https://launchpad.net/ubuntu/+source/evolution-data-server/3.21.90-0ubuntu3 | 14:25 |
| ximion | jbicha: only that the driver-install stuff has never been tested, and that you ran't yet abort a refresh operation (which the previous code could) | 14:25 |
| Sweet5hark | pitti: sorry, i was just being sarcastic, I just forgot the recompile ;) | 14:25 |
| ximion | jbicha: but aside from missing testing on Ubuntu and a bit of polish, no, there is no reason why Ubuntu shouldn't have it :) | 14:26 |
| pitti | Sweet5hark: also, calling vim and pandoc from python is *really* performant :) | 14:26 |
| Sweet5hark | trying to fix gtk3 theming for libreoffice is a bit like playing battleships. E3! nope. D5! nope .... | 14:27 |
| Sweet5hark | pitti: ha! | 14:27 |
| qengho | How long between plays for you? | 14:27 |
| pitti | Sweet5hark: did you find a Pikachu yet? | 14:27 |
| jbicha | I don't think aborting refresh of apt sources matters | 14:28 |
| Sweet5hark | pitti: I got the one right at the start. But I also found one in the wild later. | 14:28 |
| Sweet5hark | pitti: I was kinda annoyed that I wasted a few Dratini at the start. They were so abundant at the park nearby in the first weeks I thought Ill soon have enough of them. But alas, they nerfed the parc (it still has a lot of eevees though). | 14:31 |
| * Sweet5hark is back to cga colors on gtk-3.20 | 14:53 | |
| === jcastro_ is now known as jcastro | ||
| ximion | Laney: I will do an AppStream release probably tomorow or on Wednesday - then, the time of API breaks will be over | 15:10 |
| ximion | hmm, is snowball in main? | 15:11 |
| ximion | it isn't, hmm... | 15:11 |
| Trevinho | tedg: hey, what should I do with the libindicator / unity systemd request? | 16:19 |
| seb128 | jbicha, would have been nice to wonder if signon-plugin-password was useful before removing the recommends... | 17:08 |
| seb128 | jbicha, check with mardy he probably knows but I think it's needed yes | 17:08 |
| seb128 | jbicha, I'm going to have a look to the versions update issue | 17:09 |
| jbicha | seb128: well I think the recommends is wrong for ubuntu-gnome, but maybe it needs to be added now to ubuntu-desktop if it's useful? | 17:09 |
| seb128 | jbicha, yeah, maybe, that should have been a question to ask before doing the change, it's a bit rude to bug other flavors and then ask if maybe they should be fixed | 17:10 |
| jbicha | I tested that the Ubuntu SSO integration still works with gnome-software without that | 17:11 |
| seb128 | I doubt gnome-software uses evolution | 17:11 |
| seb128 | that's probably something that should be tested by adding a google account to uoa and see if evolution can access the mail/calednar | 17:11 |
| seb128 | jbicha, https://irclogs.ubuntu.com/2015/12/03/%23ubuntu-desktop.html#t13:30 suggests that adding google accounts doesn't work without it, it was added on purpose to fix those issues, see https://launchpad.net/ubuntu/+source/evolution-data-server/3.18.2-0ubuntu2 | 17:20 |
| jbicha | seb128: thanks, but it pulls the Qt stack in to Ubuntu GNOME | 17:24 |
| jbicha | how about having libaccount-plugin-1.0-0 depend on it? | 17:25 |
| seb128 | jbicha, yeah, i understand you have an issue | 17:25 |
| seb128 | I'm not saying we shouldn't change things | 17:25 |
| seb128 | just that we should think about how to make it work for everyone | 17:26 |
| seb128 | rather than cowboying a change for one flavor and screwing the other ones | 17:26 |
| seb128 | especially that you traded some extra depends for non working features for others | 17:26 |
| jbicha | I think that's what I'm doing now | 17:26 |
| seb128 | I'm unsure what's the right fix because I don't know for what desktops/flavors the signon bits are useful | 17:27 |
| jbicha | reverse-depends libaccount-plugin-1.0-0 | 17:27 |
| seb128 | like kde is also use libaccount iirc, so unsure if evolution would need it there | 17:28 |
| seb128 | having libaccount-plugin depends on it feels wrong, it's a plugin architecture and eds is only one type of account | 17:29 |
| seb128 | it might also create a depends cycle? | 17:29 |
| jbicha | no, I don't see a dependency cycle there | 17:32 |
| seb128 | I missread your reverse-depends libaccount-plugin-1.0-0 comment then | 17:36 |
| seb128 | still it looks wrong for the other reason stated | 17:36 |
| seb128 | the plugin support shouldn't force specific plugins | 17:36 |
| seb128 | it's like if libpeas was depending on gedit-plugins | 17:37 |
| jbicha | we could have libaccount-plugin-google(etc.) depend on it instead if you like that better | 17:39 |
| jbicha | I can't tell which plugins need it though | 17:39 |
| seb128 | yeah, me neither | 17:39 |
| jbicha | if I make all the libaccount-plugin-* depend on it, it ends up having the same affect | 17:39 |
| tedg | Trevinho: It is on my TODO list for today, I have to fix the policykit-unity8 test suite and then that's next. So I hope it'll be done when you wake up in the morning. Sorry to take so long on it. | 17:40 |
| Trevinho | tedg: no worries | 17:40 |
| jbicha | I can't get UOA to work in today's daily image, as soon as I click in the embedded webpage in unity's Online Accounts>Google (or Facebook), the page disappears | 17:41 |
| jbicha | is that maybe an oxide-qt bug? | 17:42 |
| seb128 | yeah, there is a bug with the current gcc/libc | 17:44 |
| seb128 | it errors out | 17:44 |
| jbicha | I think having libaccount-plugin-1.0-0 depend on signon-plugin-password is the easiest solution; otherwise I have to touch the ~30 UOA plugins (except not the ones that already depend on mcp-account-manager-uoa) | 17:55 |
| jbicha | I wouldn't think things like the Google plugin which already depends on signon-plugin-oauth2 would need signon-plugin-password but given that it's impossible to test it today on yakkety | 18:02 |
| seb128 | can you talk to mardy to see what he would suggest? | 18:06 |
| jbicha | oh, I didn't realize mardy wasn't in this channel | 18:06 |
| Sweet5hark | yes! libreoffice toolbar theming fixed for gtk-3.20. | 19:29 |
| jbicha | Sweet5hark: just a nitpick but it seems a little odd that libreoffice-gnome depends on libreoffice-gtk2 (which has a few things not in -gtk3) | 19:35 |
| Sweet5hark | jbicha: bug 1616673 | 19:37 |
| ubot5 | bug 1616673 in libreoffice (Ubuntu) "libreoffice-gtk2 pulled in by default and should not be" [Undecided,Fix committed] https://launchpad.net/bugs/1616673 | 19:37 |
| jbicha | are xid-fullscreen-on-all-monitors and liblosessioninstalllo.so gtk2 specific? | 19:38 |
| Sweet5hark | jbicha: dunno what xid-fullscreen... even is supposed to do. losessioninstall...: havent tested, but dont think so. | 19:41 |
| jbicha | hmm, things seem to work without them | 19:44 |
| Sweet5hark | jbicha: meh, nah indeed. at least liblosessioninstall should move to -gtk3 or -gnome ... | 19:45 |
| Sweet5hark | jbicha: losessioninstall provides some hocks for packagekit/dbus "you should install $foo for this functionality" ... | 19:47 |
| jbicha | ok, maybe move it to -gnome since I guess it should work with gtk2 and gtk3 | 19:50 |
| jbicha | robru: are you able to review https://code.launchpad.net/~jbicha/ubuntu-seeds/touch-yakkety-tinyxml2/+merge/304207 | 19:53 |
| robru | jbicha: no, sorry | 20:12 |
| jbicha | oops, I guess you're not a core dev yet :( | 20:14 |
| robru | jbicha: nope, hopefully one day | 20:15 |
| jbicha | maybe I should ask nacc, since I sponsored stuff for him earlier now he can return the favor :) | 20:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
