[00:17] <robert_ancell> desrt, around?
[00:30] <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:31] <robert_ancell> (in the XML)
[00:31] <desrt> dbus doesn't work that way
[00:32] <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:33] <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:34] <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:35] <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:36] <robert_ancell> I think it's unlikely that the more obscure formats will be actively used.
[00:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <robert_ancell> or timestamps like "12:51:32.1234567" in a log, that I know all occurred today
[00:53] <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:54] <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:57] <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:58] <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:59] <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
[01:00] <desrt> it may also be fun to support rfc822 date/time... which, reading the spec, is hilariously US-centric...
[01:01] <robert_ancell> desrt, ok to push "GTimeZone: Support the Unicode minus character"?
[01:02] <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:03] <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:04]  * desrt slowly comes to realise that ISO8601 is completely unreasonable, and wants nothing to do with it
[01:05] <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:06] <desrt> make sure you support " " instead of T
[01:07] <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:08] <robert_ancell> desrt, thanks for the review
[01:13] <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:18] <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:19] <robert_ancell> desrt, I just pointed out how vague the spec was
[01:23] <desrt> robert_ancell: k.
[01:23] <desrt> happy monday, then :)
[04:36] <pitti> Good morning
[04:51] <hikiko> hello!
[07:44] <Sweet5hark1> moin
[07:59] <pitti> hey Sweet5hark1
[08:02] <Sweet5hark1> bonjour pitti!
[08:08] <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:09] <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:10] <seb128> ah ok, assis devant l'ordinateur pour du repos aujourd'hui alors ;-)
[08:11] <pitti> seb128: héhé -- alors que j'ai couru ce matin
[08:11] <seb128> quelle energie !
[08:12] <pitti> it was actually good for relaxing muscles
[08:19] <Trevinho> Morning!
[08:20] <seb128> hey Trevinho, how are you? had a good w.e?
[08:21] <Trevinho> Hey seb128...
[08:21] <Trevinho> Yeah full of things...
[08:22] <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:23] <Trevinho> https://usercontent.irccloud-cdn.com/file/MkD6GqoW/IMG_20160828_234051.jpg
[08:23] <Trevinho> You, seb128?
[08:24] <seb128> Trevinho, nice!
[08:25] <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:26] <Trevinho> Here it has been hot too, but I drove to some hills to get some cool air for free :-)
[08:28] <seb128> :-)
[08:41] <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:58] <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 :)
[09:23] <desrt> morning, peeps
[09:28] <desrt> it's so early that europe hasn't even woken up yet...
[09:28]  * desrt finds herself wondering how timezones work again
[09:30] <pitti> hey desrt!
[09:31] <desrt> guten Morgen
[09:41] <Trevinho> https://i.imgur.com/8FNGSZA.jpg
[09:42] <pitti> Trevinho: oh dear -- it's i*n*dentation styles
[09:42] <pitti> software engineers have also been known to have OCD :)
[09:43] <desrt> this sign is pretty accurate
[09:43] <Trevinho> :-)
[09:44] <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:45] <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:46] <Trevinho> :-D
[10:32] <duflu> Trevinho: Excuse me... or else I risk my current coffee being dinner
[11:25] <mitya57> jbicha, please review http://bazaar.launchpad.net/~ubuntu-desktop/rhythmbox/ubuntu/revision/275 — is that what you really intended to add?
[11:35]  * desrt sees that robert_ancell uploaded another version of the patch and couldn't help himself
[13:07] <desrt> ISO week numbering... my goodness.
[13:08] <seb128> desrt, ?
[13:09] <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:10] <desrt> which introduces a whole bunch of edgecases
[13:10] <seb128> is there different way to number weeks?
[13:11] <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:12] <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:24] <qengho> Oh, that's the one with the Thursday rule?
[13:26] <qengho> ...yep, it is. That is a fun one.
[13:28] <seb128> hey qengho
[13:29] <qengho> seb128: hey! Now's the time to regret not adopting French metric weeks, n'est pas?
[13:29] <seb128> lol, maybe not ;-)
[13:30] <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:37] <jbicha> mitya57: yes, that looks better
[13:50] <jbicha> 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] <Sweet5hark> next up: the buttons themselves (what worked on xenial, doesnt work here).
[14:11] <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:22] <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:23] <Sweet5hark> pitti: I hear you volunteer to do a high performance rewrite of LibreOffice in Python? exciting!
[14:24] <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:25] <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:26] <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:27] <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:28] <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:31] <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:53]  * Sweet5hark is back to cga colors on gtk-3.20
[15:10] <ximion> Laney: I will do an AppStream release probably tomorow or on Wednesday - then, the time of API breaks will be over
[15:11] <ximion> hmm, is snowball in main?
[15:11] <ximion> it isn't, hmm...
[16:19] <Trevinho> tedg: hey, what should I do with the libindicator / unity systemd request?
[17:08] <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:09] <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:10] <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:11] <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:20] <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:24] <jbicha> seb128: thanks, but it pulls the Qt stack in to Ubuntu GNOME
[17:25] <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:26] <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:27] <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:28] <seb128> like kde is also use libaccount iirc, so unsure if evolution would need it there
[17:29] <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:32] <jbicha> no, I don't see a dependency cycle there
[17:36] <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:37] <seb128> it's like if libpeas was depending on gedit-plugins
[17:39] <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:40] <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:41] <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:42] <jbicha> is that maybe an oxide-qt bug?
[17:44] <seb128> yeah, there is a bug with the current gcc/libc
[17:44] <seb128> it errors out
[17:55] <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)
[18:02] <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:06] <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
[19:29] <Sweet5hark> yes! libreoffice toolbar theming fixed for gtk-3.20.
[19:35] <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:37] <Sweet5hark> jbicha: bug 1616673
[19:38] <jbicha> are xid-fullscreen-on-all-monitors and liblosessioninstalllo.so gtk2 specific?
[19:41] <Sweet5hark> jbicha: dunno what xid-fullscreen... even is supposed to do. losessioninstall...: havent tested, but dont think so.
[19:44] <jbicha> hmm, things seem to work without them
[19:45] <Sweet5hark> jbicha: meh, nah indeed. at least liblosessioninstall should move to -gtk3 or -gnome ...
[19:47] <Sweet5hark> jbicha: losessioninstall provides some hocks for packagekit/dbus "you should install $foo for this functionality" ...
[19:50] <jbicha> ok, maybe move it to -gnome since I guess it should work with gtk2 and gtk3
[19:53] <jbicha> robru: are you able to review https://code.launchpad.net/~jbicha/ubuntu-seeds/touch-yakkety-tinyxml2/+merge/304207
[20:12] <robru> jbicha: no, sorry
[20:14] <jbicha> oops, I guess you're not a core dev yet :(
[20:15] <robru> jbicha: nope, hopefully one day
[20:16] <jbicha> maybe I should ask nacc, since I sponsored stuff for him earlier now he can return the favor :)