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