[05:07] <bjf> in saucy, where did the "Keyboard Layout Options" dialog go to?
[05:26] <Mirv> bjf: control center -> keyboard -> layout options (link in bottom left corner)
[05:33] <jibel> Mirv, there is no such thing as layout options anymore apparently. That feature that allows the user to change the compose key or the behavior of certain keys
[05:34] <jibel> probably too powerful for us mere mortals
[05:49] <pitti> Good morning
[06:16] <Mirv> jibel: right, those ones.. can't find those, true
[06:27] <pitti> Laney: what do you mean? isn't /etc/timezone writable?
[06:27] <pitti> Laney: i. e. you want to symlink /etc/timezone to some place else, and make logind create the new file in that "else" place instead?
[06:28] <pitti> Laney: we can certainly add a readlink() in between there
[06:28] <pitti> Laney: it just seems weird to make /etc/ not writable; that is the very directory where such modifications should happen, after all?
[08:03] <Laney> morning
[08:03] <Laney> pitti: It wants to do atomic writes, i.e. creating temporary files/symlinks and then moving them into place
[08:03] <pitti> hey Laney, good morning
[08:04] <pitti> Laney: right, but that semantics isn't possible when /etc/timezone points to someplace else
[08:04] <Laney> and it's a problem because (a) you can't make the temporary file
[08:04] <Laney> and (b) you can't unlink the old one because it's a mountpoint
[08:04] <pitti> so if /etc/ isn't writable, we need to introduce a race condition
[08:04] <Laney> seems so
[08:04] <pitti> Laney: mount point?
[08:05] <seb128> good morning desktopers
[08:06] <seb128> hey Laney pitti
[08:06] <Laney> /dev/mmcblk0p23 on /etc/localtime type ext4 (rw,relatime,data=ordered)
[08:06] <Laney> hi seb128!
[08:06] <Laney> how are you? good holidays?
[08:06] <JackYu> morning, seb128.
[08:06] <pitti> bonjour seb128, ça va ? comment sont tes vacances ?
[08:06] <seb128> Laney, I'm good, great holidays thanks
[08:06] <seb128> pitti, elles étaient très bien, merci
[08:06] <pitti> Laney: arf, I didn't know one could put mounts on a file
[08:07] <Laney> not entirely up to speed on how it works technically
[08:07] <Laney> so /etc/timezone (and /etc/adjtime) is a file and /etc/localtime is a symlink
[08:07] <Laney> for the first two you can do the write non-atomically but the symlink is a bit harder
[08:07] <pitti> Laney: I thought you just said it was a mount point, not a symlink?
[08:07] <Laney> sorry, it wants to be a symlink
[08:08] <Laney> timedated wants it to be
[08:08] <Laney> but in the images it's actually a file
[08:08] <Laney> so you get a warning
[08:08] <pitti> Laney: I guess it wouldn't help if timedated would actually put it as a file, as both break with a mount point
[08:09] <pitti> but I don't understand how it can be a mount point in the first place
[08:09] <Laney> atomic writing does
[08:09] <pitti> you can't *ever* update that
[08:09] <Laney> you can write to it
[08:09] <pitti> no, you can't do atomic writes
[08:09] <Laney> right
[08:09] <Laney> that's what we have to break
[08:10] <pitti> an application which tries to read it in the middle of writing would probably just crash
[08:10] <pitti> so that madness with mount points has to go
[08:10] <pitti> it at least needs to be a symlink, and then we can at least atomically update the target
[08:10] <pitti> that still means a race condition for programs, but they at least won't see a half-written one
[08:11] <Laney> so we can make a writeable directory
[08:11] <Laney> and have timedated do its thing in there, with /etc/stuff pointing into it
[08:12] <pitti> partition 23 seems to suggest that we use similar stuff for other files?
[08:12] <Laney> yeah that's how the ro images work
[08:12] <Laney> they have this whitelist of writeable files
[08:12] <pitti> why don't we just have a single writable /data and put symlinks into those?
[08:13] <pitti> umpteen partitions for every single writable file seems like a waste of space, too, aside from the fact that they break rename()
[08:14] <pitti> perhaps an overlayfs on top of /etc might be better, then everythign ought to work without such hacks
[08:14] <Laney> I don't know
[08:14] <Laney> It's Stéphane's baby really
[08:18] <Laney> (you're right that it would make life easier, but I guess that this was considered at the time)
[08:19] <pitti> well, "easier" is one thing, but I don't see how it make even possible with that schema
[08:19] <xnox> pitti: overlayfs is not in  upstream kernel, and as far as I remember we do not have it in all kernels on touch. Plus overlayfs lacks inotify. Hence the scheme of bind-mounting files to be writtable (that type of mounts is supported by android kernels)
[08:19] <pitti> I guess stgraber is well aware of overlayfs/aufs, but ISTR that neither of them works on arm
[08:19] <xnox> (if any)
[08:20] <pitti> xnox: a bind-mounted file supports inotify?
[08:22] <xnox> pitti: sorry, supported as in supported to become writtable across all android kernels. Haven't checked inotify on bind-mounted single files, probably needs additional tests in upstart cause I don't think we ever done that before.
[08:22] <Laney> I mean the whole of /etc/ could be bind mounted in this way
[08:22] <xnox> Laney: i think that would be too much for system-image updates. As we don't have dpkg to resolve conffile changes =/
[08:23] <pitti> xnox: even if inotify would support bind-mounted files, that seems like a horrible race condition
[08:23] <pitti> exactly when these fire, programs would probably run into half-written files
[08:25] <xnox> pitti: well upstart is fine, it checks and parses and ignores incomplete writes. And it only loads up the updated config for the next "start", the config of the running job or restarted one is never modified.
[08:25] <pitti> so a timedated hack would be to not use a symlink, but copy the file contents, AFACS?
[08:25] <pitti> "AFAICS"
[08:25] <Laney> xnox: Already some of the whitelisted files are conffiles
[08:25] <xnox> (among with supporting / catching a few other ways of writting files atomically - e.g. rm & mv, mv, etc.)
[08:26] <pitti> but still, this mount approach isn't a real solution
[08:26] <xnox> =/
[08:26] <xnox> true.
[08:26] <Laney> copy the contents> that's what /etc/localtime ships as currently
[08:27] <Laney> look in dmesg of an ro booted device and you will see the warning from timedated about that
[08:28] <seb128> Laney, do you think you could do me a short summary of what happened in system settings while I was away? I went through email, seems wifi got in, bluetooth is being reviewed (cmake switch as well)
[08:28] <Laney> you could have the symlink if you do the rw-intermediate-directory thing though
[08:28] <seb128> Laney, nice work on the env variable to show the hidden UI bits
[08:28] <Laney> seb128: cmake is still broken but getting there; see my last comment
[08:29] <Laney> wifi got in, hid loads of things (thanks)
[08:29] <Laney> still some more things to hide no doubt
[08:29] <Laney> bluetooth is proposed, sil2100 did some small tweaks to background
[08:30] <Laney> and is going to work on removing the example content / greeter background option (asked m pt to update that design)
[08:31] <Laney> I have a branch for "measure disk usage" up for review
[08:31] <Laney> we got the cpp click package backend in
[08:31] <Laney> that might be it
[08:32] <Laney> yesterday I got the qmenumodel toggling of bluetooth working
[08:32] <Laney> will do location and then mp that in a bit
[08:34] <seb128> Laney, great, I just read through mp and show your disk usage one ... I think it would be nice to update values one by one as the results come
[08:34] <seb128> Laney, as long as we have a spinner on a "calculating..." placeholder until the results come back
[08:34] <Laney> well, then I have two problems
[08:34] <Laney> 1. I don't know how to pass a particular signal to the callback function
[08:34] <Laney> 2. Not sure how to update the graph
[08:35] <Laney> Currently it's grey and then goes coloured when they all come in at once
[08:35] <seb128> ok
[08:35] <Laney> hmm, maybe that second one would be ok though
[08:35] <Laney> not sure
[08:35] <seb128> I though you were trying to get out of your way to "sync" them
[08:35] <seb128> I'm fine with the current approach
[08:35] <Laney> I think the syncing looks nice anyway :P
[08:35] <Laney> and it's what android does ;-)
[08:36] <Laney> if you know how to get around 1. I'm happy to try it
[08:36] <seb128> I don't no, and I'm sure we have enough to do without to poke around to change things that are working
[08:36] <seb128> let's revisit stuff after v1
[08:37] <Laney> k
[08:42] <seb128> Laney, from the backlog I guess you are working on bug #1227520 ?
[08:43] <Laney> come on bot
[08:43] <seb128> sorry, the title made me think it was something else
[08:43] <Laney> seb128: yesterday I checked if the dbus calls work
[08:43] <Laney> and we found out that they do not
[08:43] <Laney> that's what I was discussing with pitti
[08:43] <seb128> because of lightdm/logind?
[08:43] <Laney> no, because of read-only /etc
[08:44] <seb128> that confuses dbus?
[08:44] <Laney> it breaks atomic updates that timedated tries to do
[08:44] <Laney> create temporary file, rename it into place
[08:44] <Laney> you can't do either of those things with the way it's set up now
[08:44] <seb128> oh, I see
[08:44] <seb128> ok, so back to the backlog
[08:45] <seb128> should I assign the bug to you?
[08:46] <Laney> I was hoping pitti would offer to do the timedated change (probably be faster/better than me) :P
[08:46] <Laney> but if not then I can try to do it
[08:46] <seb128> Laney, is the issue as systemd one then?
[08:46] <Laney> we have to hack around it in timedated
[08:47] <Laney> unless we can convince people to fix the ro scheme for /etc
[08:47] <Laney> not sure how likely that is
[08:47] <seb128> Laney, can you drop some comments in the bug report?
[08:47] <seb128> I made it affect systemd as well
[08:47] <Laney> ok
[08:48] <pitti> Laney: well, I can't
[08:48] <Laney> seb128: there's also https://bugs.launchpad.net/ubuntu-system-settings/+bug/1227690 which I don't really understand
[08:48] <pitti> there's no way to make an atomic /etc/localtime change with that mount schema
[08:48] <Laney> pitti: The hack-around is the symlink-into-writable-directory thing
[08:48] <Laney> that should work, right>?
[08:48] <pitti> and I am so much not going to do that for main Ubunut
[08:49] <Laney> like: catch EROFS, do weird stuff in that case
[08:49] <pitti> Laney: yes, but that would be needed on desktop/server Ubuntu as well, and first be changed in the phone images?
[08:49] <seb128> Laney, that but is upstart-app-launcher one I think, let me reassign/Cc ted
[08:49] <pitti> Laney: oh, like in that fallback manner; yes, that would work
[08:50] <Laney> I can't imagine upstream ever wanting to take that though :(
[08:50] <pitti> Laney: eek OMG no
[08:50] <pitti> this is evil, bad, and wrong
[08:50] <Laney> haha
[08:50] <pitti> this is not a patch which you *ever* want to show anyone
[08:50] <Laney> that's when you question our sanity really
[08:51] <pitti> Laney: won't we run into the same issue with hostnamed, programs that change fstab, etc/
[08:51] <pitti> ?
[08:52] <pitti> it seems our time would be much better spent with building aufs/overlayfs for our arm kernels than tryign to find all such issues and introduce wrong and messy patches to work around those
[08:52] <Laney> yeah, when we want to enable everything for convergance
[08:53] <seb128> we should start an ubuntu-phone or ubuntu-devel discussion on the topic
[08:53] <Laney> The problem we have /now/ is the pressure to get this timezone changing working
[09:05] <Laney> seb128: pitti: updated https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1227520
[09:05] <seb128> Laney, thanks
[09:09] <dholbach> hiya
[09:10] <dholbach> did anyone else notice that <super>-<number> does not bring up the app if it's on another work space? since last week's unity+compiz+nux updates?
[09:10] <dholbach> and for some reason everything feels super slow (TB, FF primarily)
[09:10] <pitti> dholbach: confirmed
[09:10] <jibel> dholbach, I reported bug 1229540 this morning
[09:10] <dholbach> thanks a bunch jibel
[09:10] <jibel> dholbach, also notified #u-unity but no response
[09:11] <dholbach> did you notice a general slowness as well?
[09:12] <jibel> no slowness, but I rebooted my machine this morning
[09:12] <dholbach> even after a reboot it's dog-slow :/
[09:13] <jibel> I'm using the driver radeon with an ATI card if that makes a difference
[09:13] <jibel> I'll try on intel
[09:13] <dholbach> I'm on intel
[09:14] <seb128> you should probably ping the compiz/unity guys on #ubuntu-unity
[09:14] <seb128> you are mostly speaking to the wrong people here
[09:14] <jibel> I did twice
[09:14] <seb128> I didn't say you didn't
[09:14] <seb128> but you better have that discussion on #ubuntu-unity
[09:15] <jibel> k
[09:15] <seb128> we are mostly users of compiz here nowadays
[09:15] <dholbach> seb128, will do
[09:15] <dholbach> seb128, and welcome back!
[09:15] <seb128> better to discuss things where the upstream guys can read it
[09:15] <seb128> dholbach, thanks ;-)
[09:15] <dholbach> you're right
[09:16] <dholbach> I just thought I'd 1) hangout with the cool kids in here for a sec and 2) there'd be enough overlap :)
[09:18] <seb128> dholbach, we share your annoyances but can't really be useful there ;-)
[09:19] <seb128> jibel, dholbach: looking at the changelog of compiz, that's probably an issue for twosend, not sure at what time he's around though
[10:04] <bdrung> hi, since today i cannot login to my raring machine. my password gets accepted by lightdm and it takes one second to load, but then falls back to the lightdm screen. are there any pointers how to debug that failure?
[10:10] <seb128> bdrung, trying looking to ~/.xsession-errors and .cache/upstart/gnome-session.log
[10:10] <seb128> bdrung, it's likely gnome-session or something in the session not starting
[10:35] <bdrung> seb128: both files are empty/do not exist
[10:35] <seb128> weird
[10:36] <bdrung> logging in on a VT works without problems
[10:37] <seb128> startx -- :1 works to start your session?
[10:38] <bdrung> it loads the wallpaper and i can move the cursor
[10:38] <bdrung> a popup comes up asking for my keyring password
[10:38] <seb128> seems like the session start but not unity...
[10:38] <bdrung> right click works, but no unity
[10:39] <seb128> still not .xsession-errors or ~/.cache/upstart/*.log with useful infos?
[10:39] <didrocks> still no review on my branch? what are you doing seb128? I'll complain ;)
[10:39]  * didrocks runs…
[10:39] <seb128> you should have a gnome-session.log
[10:39]  * seb128 aims at didrocks
[10:39]  * didrocks runs faster
[10:39] <seb128> ;-)
[10:39] <didrocks> ;)
[10:40]  * ogra_ goes to find another channel ... to much sports in here today 
[10:40] <bdrung> now i have a .xsession-error: http://paste.debian.net/45575/
[10:41] <seb128> bdrung, from that log it seems unity is not in the compiz profiles list :/
[10:42] <bdrung> how can that happen? i haven't touched any compiz configuration for weeks.
[10:42] <seb128> dunno, maybe something touched the config...
[10:43] <seb128> bdrung, try to "gsettings reset org.compiz.core:/org/compiz/profiles/unity/plugins/core/ active-plugins"
[10:43] <bdrung> i have enabled the unity plugin and unity is back.
[10:43] <seb128> ok
[10:44] <czajkowski> aloha
[10:44] <seb128> bdrung, it could be that unity failed to load for another reason (like buggy xorg/driver/config) and compiz disabled it
[10:45] <bdrung> maybe. re-enabling the unity plugin fixed the initial login problem. thanks for your help. i will see if the issue happens again and report a bug in that case.
[11:09] <Laney> jdstrand: did you forward https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1227295 ?
[11:47] <jdstrand> Laney: not yet
[12:05] <Laney> jdstrand: could you, please?
[12:06] <Laney> larsu: Does activating location-detection-enabled (indicator-location) work for you?
[12:07] <Laney> Or is it not supposed to work yet on the device? nexus 4
[12:09] <larsu> Laney: no clue, never tried it
[12:09] <larsu> let me try on my galaxy nexus
[12:10] <Laney> thanks
[12:10] <Laney> sorry for making you my go-to action/indicator guy :P
[12:10] <larsu> heh, that's fine :)
[12:10] <Laney> I'll ask ted later if you don't know
[12:13] <larsu> Laney: doesn't work.
[12:13] <larsu> ugh. The indicator is doing the wrong thing
[12:14] <larsu> it checks the box even though the underlying action didn't report back that it was toggled
[12:14]  * larsu shakes fist at dednick 
[12:14] <Laney> heh
[12:14] <larsu> sounds like you need to talk to ted indeed. I have no clue when/if location detection is supposed to work
[12:15] <larsu> and whether you can fake it
[12:15] <Laney> ok
[12:16] <Laney> I'll leave it hooked up but hidden in this MP
[12:17] <jdstrand> Laney: done
[12:18] <Laney> jdstrand: merci!
[12:58] <dednick> larsu: if it can't change, then it shouldnt be enabled. it's the same as saying that a slider value shouldnt change until the acion changes the value.
[12:59] <dednick> larsu: unfortunately we dont get any feedback on the success of activation/changeState.
[12:59] <larsu> dednick: I agree, but sometimes you don't know in advance
[13:00] <larsu> dednick: yes you do, which is my point...
[13:00] <dednick> larsu: only that the value changes to match though ?
[13:00] <larsu> I wonder why we're seeing this at all. GtkMenuTracker does the right thing here
[13:00] <dednick> larsu: how do we get feedback?
[13:01] <larsu> dednick: you call activate, and later the action changes state
[13:01] <larsu> you only ever update the check mark in response to the action changing state
[13:01] <larsu> (which might happen for other reasons as well)
[13:01] <dednick> yeah, but if it doesnt change, then the action state doesnt get updated, so no feedback
[13:02] <dednick> we only get feedback if it changes, which wont help in some cases.
[13:04] <larsu> dednick: well, the feedback is that it doesn't change
[13:05] <larsu> right now, the location check mark changes, even though the action (and thus the device) didn't get turned on
[13:06] <dednick> larsu: so you are saying that we dont do any visual change for when you select the checkbox until you get the update that it changes. This does not work for a slider.
[13:08] <larsu> dednick: technically it does :P  But yeah, that's a good point.
[13:08] <larsu> desrt: have you thought about this before? ^^ How is shell doing it?
[13:09] <desrt> larsu: this situation happens in a lot of places .. like with pulseaudio or video players
[13:10] <attente> seb128, hey, welcome back
[13:10] <desrt> what are they doing?
[13:10] <dednick> fyi, i dont think there's even a way at the moment to stop the Checknbox/Switch from visually changing it when you press it. other than eating the mousepresses.
[13:10] <desrt> i'd guess that they have some time-based buffer for receiving updates... and if they don't get updated to where they think they should be, they move the slider back
[13:10] <larsu> desrt: I know. Just talking about the concept in general (we started out with a checkbox that doesn't behave correctly)
[13:11] <desrt> ah.  this disease again :)
[13:11] <desrt> gtk had this problem and we had to 'cure' it
[13:11] <seb128> attente, hey, thanks! how are you?
[13:11] <desrt> the toolkit should not have the logic inside of it about what happens when a button is clicked, imho
[13:11] <desrt> it should just tell the app that it was clicked
[13:11] <attente> seb128, i'm good, vacation was good?
[13:12] <seb128> attente, yes, it was great to away from the computer for a while ;-)
[13:12] <seb128> attente, less fun to catch up with all the emails and backlog after that though...
[13:13] <attente> ha.. i guessed.. :)
[13:13] <larsu> seb128: mark all as read!
[13:13] <larsu> desrt: ya, I agree...
[13:13] <desrt> seb128: i didn't send you any mail, so i agree with larsu
[13:14] <larsu> desrt: same reason for me, which is  why I proposed it in the first place ;)
[13:14] <seb128> lol
[13:14] <seb128> desrt, larsu sent me emails
[13:14] <dednick> larsu, desrt: problem still remains with slider...once you release the drag, you have to assume that the value has been updated.
[13:14] <seb128> though that was just travel organization and I replied by then
[13:14] <larsu> seb128: I did? Oh, but you answered them already ;)
[13:14] <desrt> dednick: i think implementing a slider in this situation is difficult but not impossible
[13:14] <seb128> larsu, indeed ;-)
[13:14] <larsu> because obviously you have a filter for marking mails from me as highest prio
[13:15] <desrt> dednick: i've seen places where sliders have a 'real value' in the background behind them that updates independent of the part the user drags, but that seems a bit janky...
[13:15] <dednick> desrt: yeah, well i guess you could do some validation timeout or some such horrible thing
[13:15] <desrt> so instead i'd recommend having a couple of timers and playing with them until you get the right feel
[13:15] <desrt> one timer checks how long it was since the last user interaction and puts you in an 'interactive' mode for, say, 1 second
[13:16] <desrt> the other timer delays application of update signals from the service if they conflict with the last user-provided value
[13:16] <desrt> so if you are in interactive mode and an update from the server comes and it doesn't agree with what the user just entered 200ms ago, you wait an extra 500ms
[13:16] <desrt> if more updates come, discard it
[13:16] <desrt> if that was the last update to come, take it and move the slider to that spot
[13:17] <desrt> that way the slider always correctly reflects the state on the service, but maybe after a delay
[13:17] <desrt> in fact, probably it's enough to just have the one interactivity timer
[13:17] <desrt> and do the sync-up to the last value from the service after 1 second of no interaction
[13:18]  * larsu has been meaning to do something like this for the volume slider
[13:18] <desrt> for the case where the user is manipulating the value the value from the service will always settle on the user's chosen value, so it will always end up ignoring all updates, effectively and the toolkit will have control
[13:18] <larsu> but then, bugs :/
[13:18] <desrt> but for the case where the changes are coming from elsewhere (like if some other app changes the volume level) you really do need to let the service win
[13:19] <larsu> desrt: the same argument can be made for checkboxes
[13:19] <larsu> and I'm fairly close to making it…
[13:19] <desrt> i was thinking about that, but it's not really the same
[13:19] <desrt> the difference with checkboxes is that it's not normal for the user to click them twice in the amount of time before the server responds
[13:19] <larsu> it does give the feedback that dednick was talking about though, in a fairly cool way even
[13:20] <desrt> whereas with sliders it's quite normal to get a flurry of updates during the round-trip time
[13:20] <larsu> well the case we're talking about is when the checkbox cannot be updated, rigfht
[13:20] <larsu> currently (in gtk), nothing happens when you activate
[13:20] <larsu> which ... sucks
[13:20] <desrt> a more interesting question is a switch
[13:20] <desrt> particularly one that the user can drag
[13:20] <seb128> Laney, jdstrand: https://bugzilla.gnome.org/show_bug.cgi?id=708677 ... not sure if you care about the credit, seems like ebassi just copied the patch and added himself as "from" for it ...
[13:20] <ubot2`> Gnome bug 708677 in gio "incorrect object path 'deskop' used in gio/gdbusobjectmanagerclient.c" [Normal,Unconfirmed]
[13:20] <seb128> desrt, ^ if you get to commit that
[13:20] <dednick> larsu, desrt: yes, it would be good if it enabled for a a second then disbaled again.
[13:21] <desrt> because then part of the widget is a piece that the user may have moved themselves....
[13:21] <larsu> desrt: but if you were to check it and then de-check it after a timeout if the service doesn't acknowledge...
[13:21] <larsu> desrt: that distinction is utterly meaningless
[13:21] <desrt> larsu: what if the service is just very very slow today?
[13:21] <desrt> then it _re_checks again?
[13:21] <larsu> desrt: on a user-visible scale? 1 second slow?
[13:21] <larsu> same problem with the slider...
[13:22] <desrt> true
[13:22] <larsu> and a bug in the servuce
[13:22] <larsu> *service
[13:22] <desrt> well, maybe the system is just super heavily loaded
[13:22] <larsu> you'll always have problems then
[13:22] <larsu> like, not being able to open the menu even
[13:22] <larsu> or move the cursor
[13:23] <larsu> I don't know, it just occured to me that this would be a single rule for all widgets
[13:23] <larsu> which is kind of appealing
[13:23] <desrt> seb128: i'll commit it with the correct author
[13:23] <seb128> desrt, thanks
[13:23] <desrt> our first .1 update!
[13:24] <desrt> seb128: actually, it's not clear who the original author is... that's probably why ebassi did what he did
[13:24] <desrt> do you have the LP bug?
[13:25] <seb128> desrt, bug #1227295
[13:25] <desrt> thx
[13:25] <seb128> desrt, jdstrand is the author
[13:25] <desrt> k.
[13:25] <dednick> larsu, desrt: this way we dont have to change the toolkit. We can just add a ValueValidator to the Components we use. Otherwise it would mean some vairly intrusive API changes.
[13:26] <seb128> session restart, brb
[13:26] <dednick> well, maybe not API, but functionality...
[13:26] <desrt> dednick: larsu's extension of my own argument kinda convinces me
[13:26] <desrt> i'm just not crazy about timer-based behaviour
[13:26] <dednick> well, no...
[13:26] <desrt> unless it's absolutely required (as i feel it is for the slider case)
[13:26] <larsu> let's ask a pro. mpt?
[13:28] <larsu> mpt: imagine a check box that turns some hardware thing on. The hardware takes a noticible amount of time before it notifies the check box whether it was successfully turned on
[13:29] <larsu> mpt: should the checkbox stay unchecked while this is happening, or should it be checked and then uncheck after a while (maybe with some animation that communicates an error)
[13:29] <desrt> seb128: k.  done.  thanks for the poke.
[13:30] <seb128> desrt, thanks!
[13:31] <seb128> desrt, you typoed Jamie as James :p
[13:31] <desrt> seb128: that's his name in bugzilla...
[13:32] <seb128> oh, right
[13:32] <seb128> guess he knows what he's doing ;-)
[13:33] <desrt> one would hope :p
[13:33] <desrt> seb128: good to have you back, btw :)
[13:33] <seb128> desrt, thanks ;-)
[13:59] <Laney> tedg: Do you know if the location/gps actions are supposed to work currently?
[14:00] <Laney> the enabled toggles
[14:00] <tedg> Laney, No, I don't.  We put them onto platform API, and they had a mock in when we did it.  I'm not sure if that got replaced.
[14:00] <tedg> Laney, Probably a ricmm or tvoss question.
[14:01] <Laney> tedg: so the indicator uses that to get its state?
[14:01] <tedg> Laney, Correct, and to set it.  It's all through that API.
[14:03] <Laney> ok
[14:05] <mpt> larsu, hah, I just got out of a design workshop about notifications-in-general
[14:06] <larsu> mpt: awesome. I hope you talked about this (most important) issue
[14:07] <mpt> larsu, in that particular case, I would make the checkbox checked+insensitive and put a spinner at its trailing end. When the action completes, restore its sensitivity and remove the spinner. If it failed, put up an error alert.
[14:08] <larsu> dednick, desrt: what do you think? ^^
[14:08] <larsu> mpt: thanks, that sounds reasonable. Even if a bit more elaborate than what we thought about ;)
[14:08] <mpt> larsu, what's the hardware thing?
[14:08] <desrt> hmm
[14:08] <desrt> what if it's not hardware, but rather something more simple
[14:08] <Laney> Interesting, just saw the background redesign
[14:08] <Laney> where's sil2100?
[14:09] <larsu> mpt: the example was hypothetical. Almost every indicator has one of those though (location, bluetooth, wifi)
[14:09] <Laney> kenvandine: https://wiki.ubuntu.com/Appearance#Phone is that all going to be possible with the picker/gallery as it stands?
[14:09] <mpt> larsu, oh, you didn't say this is inside menus
[14:09] <desrt> ie: something that will almost certainly succeed, but will probably take a (very short) amount of time before doing so?
[14:09] <larsu> mpt: well, this was for indictors on the phone, but we're interested in the menu case as well
[14:10] <larsu> but they simply disappear after activating an item, so that seems boring
[14:10] <mpt> larsu, desrt: I specced the inside-menu case in <https://wiki.ubuntu.com/MenuLayout#Horizontal_padding>: "a spinner, for an item that is in the progress of becoming checked "
[14:10] <mpt> larsu, desrt: I should have said "...or unchecked"
[14:10] <desrt> mpt: the problem is, from a technical standpoint, _all_ checkboxes work like this
[14:10] <dednick> mpt: spinner at trailing end. how about for switches/sliders ?
[14:10] <desrt> i assume you agree that it would be ridiculous to have a spinner on all checkboxes
[14:11] <larsu> desrt: you could show the spinner after 50ms or so
[14:11] <desrt> larsu's example of turning on some hardware was slightly misleading
[14:11] <mpt> ^
[14:11] <desrt> larsu: more like 200ms and i'm sold
[14:11] <larsu> desrt: misleading, but easiest to explain without explaining mpt the workings of GActionGroup
[14:11] <larsu> desrt: meh
[14:11] <desrt> 50ms is not long on a heavily-loaded under-powered device
[14:11] <mpt> desrt, most of the time you wouldn't see it, because the thing would finish checking/unchecking before you managed to reopen the menu.
[14:12] <desrt> larsu: the important point here is that this is for _every_ checkbox
[14:12] <larsu> desrt: the problem is that this makes the menu stateful :(
[14:12] <desrt> larsu: transiently so
[14:12] <larsu> ya, but still
[14:13] <larsu> closing and the opening the menu would have to retain the "I recently activated this item" state
[14:13] <larsu> but you could just keep the menu around for the timeout
[14:13] <desrt> ...
[14:13] <desrt> yes.  precisely.
[14:13] <desrt> we do that sort of pinning in all kinds of cases
[14:13] <desrt> we might want to do that just from a normal caching perspective
[14:13] <dednick> mpt: hm. the checkbox needs redesign if it's going to fit into that padding spec.
[14:13] <larsu> fair enough
[14:14] <dednick> assuming that's valid for touch as well.
[14:15] <mpt> dednick, that padding diagram is a PC menu, not a phone one. However, I do think checkmarks and radio items should be to the left of their labels regardless of form factor.
[14:15] <mpt> That's something I need to argue with Marcus and Rosie. :-)
[14:16] <dednick> mpt: sure. check is alreay on left. but not to left of the regular padding. It's currently where the icon is.
[14:16] <mpt> But which side they're on wouldn't affect the behavior of a spinner in their place.
[14:16] <seb128> Laney, no design change at this point (we just received an email about that today), so that background selector redesign is going to be for next cycle
[14:16] <kenvandine> Laney, no...
[14:16] <kenvandine> hey seb128!
[14:16] <seb128> kenvandine, hey! ;-)
[14:16] <dednick> mpt: so we want spinner on the right (trailing) then?
[14:16] <mpt> dednick, GTK used to make that same mistake, which meant that you could never have an item that had an icon and a checkmark simultaneously.
[14:17] <Laney> seb128: well, it needs to change from what it is now
[14:17] <mpt> dednick, not that that's common, but the current wi-fi network is an example of an item that has both an icon and a radio mark.
[14:18] <seb128> Laney, just hide one of the 2 images and drop the selector at the bottom
[14:18] <seb128> Laney, e.g make it one image that call the picker
[14:18] <mpt> dednick, a spinner replacing the checkmark, wherever that happens to be.
[14:18] <seb128> Laney, did sil2100 did the change to hide the welcome screen image (I think I saw that in my emails when going over mrs)
[14:19] <Laney> I don't think so
[14:19] <Laney> but might have missed it
[14:19] <Laney> he did one to show the ui elements
[14:19] <seb128> Laney, ok, maybe I got confused by that one
[14:21] <dednick> mpt: ok. the alignment might be a problem in current touch design. The checkbox (4.25 gu) is wider than the menu item padding (2 gu)
[14:21] <bjf> Mirv, i was referring to the layout options dialog that allowed you to change the caps lock key to a ctrl key.
[14:22] <mpt> desrt, I'm surprised that you say this is for *every* checkbox. I wouldn't have thought it would be asynchronous by default. Conceivably the menu you're reopening might be removed entirely (or have items removed from it) in response to your previous selection.
[14:23] <seb128> Laney, ok, he did one to hide "message on the welcome screen", that's what I was thinking about
[14:23] <Laney> ah
[14:23] <mpt> desrt, imagine just for the sake of argument that a "Private Browsing" checkmark item was inside a browser's "History" menu. One result of checking it is that all the history items disappear from the menu. Why would the menu be reopenable before that completed?
[14:24] <seb128> Laney, well, anyway, no free slot for new design and we got instructions to delay design changes, so let's do the simple case with one image
[14:24] <Laney> I asked for the design change for the one image case
[14:24] <Laney> just never saw this fancy selection stuff before
[14:24] <seb128> right, but that's a whole new design :/
[14:24] <seb128> I guess we have to keep what we have
[14:24] <seb128> e.g hide the welcome image, center the other one
[14:24] <seb128> hide the optionselector
[14:25] <seb128> done
[14:25] <Laney> we should make sure sil2100 knows that then :P
[14:25] <seb128> right
[14:25] <seb128> he's off sick today I think
[14:25] <seb128> didrocks, ^ right?
[14:26] <didrocks> yeah
[14:26] <seb128> didrocks, thanks
[14:26] <mpt> seb128, Laney: Dropping the welcome/home selector screen, by itself, shouldn't involve more work; launching "Background" would just take you directly to the existing "Home screen" screen with a different title. The code for the welcome/home selector could still be there and just never shown.
[14:26] <seb128> Laney, that can wait a few days
[14:26] <Laney> I guess so
[14:26] <seb128> mpt, we never had that screen/the component for that
[14:27] <mpt> seb128, Laney: The "Ubuntu Art"/"Custom" selection screen is new, though, at the request of Oren.
[14:27] <seb128> mpt, the current version is 2 images and clicking on either call the content picker
[14:27] <seb128> we don't have subscreens or anything like that
[14:27] <mpt> Ah, I see
[14:27] <Laney> I don't think u-s-s wants to have any of that logic anyway
[14:27] <seb128> right, that's supposed to be the content picker
[14:28] <seb128> but the current version is too simple to do that sort of thing
[14:28] <seb128> e.g not going to happen this cycle
[14:28] <seb128> kenvandine, ^ right?
[14:28] <mpt> I guess a bare bare bones design would be for the "Background" icon to open the content picker directly. :-)
[14:28] <kenvandine> right
[14:28] <mpt> But then you'd have no access to preinstalled background images.
[14:29] <seb128> we just need to make those listed in the gallery ;-)
[14:29] <seb128> ok, on that note, time for some exercice, be back in 1h for the meeting
[14:29] <Laney> do we even have those atm?
[14:30] <seb128> Laney, not that I know...
[14:30] <Laney> seems ok then ;-)
[14:31] <bjf> in recent saucy update,  i'm no longer able to set my 'caps lock' to 'ctrl' with: dconf write /org/gnome/libgnomekbd/keyboard/options "['ctrl\tctrl:nocaps']"
[14:32] <dednick> mpt, desrt, larsu: i dont think we need to worry about caching transient state for closing/opening menus. I think in the case where something can take a long time, we should be setting a busy flag on the action much the same that is done when connecting to a new network (dont think this is impled in ui properly atm).
[14:33] <mpt> Yeah, I imagined it as a state the app would set. It might not be in response to user action.
[14:35] <tkamppeter> Who is in charge of Cairo in Ubuntu? I have attached a fix for Cairo to bug 968785 and did not get any answer.
[14:47] <Laney> everyone :P
[14:48] <desrt> Laney: ?
[14:48] <desrt> oh.  delayed reply :)
[14:49] <desrt> bjf: attente may know something about this
[14:49] <Laney> yup
[14:49] <desrt> attente: ^?
[14:50] <Laney> didn't g-s-d stop using libgnomekbd?
[14:51] <desrt> afaik, it was still taking the settings out of gsettings, but it changed the way that it synced up with the accountsservice due to the new protocol in use there
[14:51] <desrt> i reckon that this will change during the 3.12 cycle upstream since attente is on the hook for doing this 'properly' before we get our patch into accountsservice
[14:51] <desrt> the old schema may well disappear
[14:52] <bjf> desrt, thanks
[14:53] <Laney> Looks from a 30 second perusal that there's a conversion routine to move settings to org.gnome.desktop.input-sources
[14:53] <Laney> in there there is an xkb-options ke
[14:53] <Laney> y
[14:53] <desrt> in g-s-d, right?
[14:53] <Laney> yep
[14:53] <desrt> is it one-way migration?
[14:54] <Laney> Yeah, AFAICS
[14:54]  * desrt wonders how the settings get into the accountsservice in the first place, then
[14:57] <attente> desrt, which settings do you mean?
[14:58] <desrt> attente: input sources settings
[14:59] <desrt> when i edit them in g-c-c what path does the information take?
[15:01] <attente> they get stored in org.gnome.desktop.input-sources
[15:02] <attente> g-s-d watches this and migrates them over to accountsservice
[15:08] <slomo> Laney: 1.2.0 in debian/unstable for you in a few minutes btw
[15:08] <Laney> slomo: saw, thanks
[15:08] <Laney> rsalveti: Is your stuff ready for that?
[15:08] <Laney> slomo: well, saw the release :P
[15:08] <slomo> Laney: i was just going to ask :P
[15:08] <Laney> I'M WATCHING YOU
[15:09] <desrt> attente: ah.  so the migration is bi-directional?
[15:09] <slomo> Laney: i should probably check if you didn't find a way to log into my laptop :P
[15:09] <rsalveti> Laney: well, just got back, but can check later today
[15:09] <attente> desrt, no, the migration is in only one direction
[15:09] <attente> org.gnome.desktop.input-sources > accountsservice
[15:09] <Laney> rsalveti: ok, please do - will be after beta but want to upload tomorrow ideally
[15:10] <desrt> weird.
[15:10] <desrt> attente: so you didn't modify anything about how the keyboard settings in-session ought to work
[15:11] <rsalveti> Laney: sure
[15:17] <attente> desrt, no
[15:17] <desrt> bjf: tough luck.  sorry :)
[15:19] <bjf> attente, so there is no way now to change caps lock to ctrl? (or did i miss the point)
[15:19] <bjf> desrt, ^
[15:21] <attente> bjf, hi, sorry, i'm not sure off the top of my head
[15:21] <attente> i'll look at this
[15:23] <bjf> attente, thanks. i understand there are some migration of settings
[15:24] <attente> bjf, so the input sources are migrated to accountsservice
[15:24] <attente> but i think your problem is unaffected by this
[15:26] <bjf> attente, ack
[15:27] <attente> bjf, did you try what Laney suggested? writing to org.gnome.desktop.input-sources xkb-options instead?
[15:30] <seb128> hey
[15:30] <seb128> it's meeting time!
[15:31] <seb128> qengho, Laney, mlankhorst, Sweetsha1k_away, desrt, attente, larsu: hey
[15:31] <larsu> seb128: as usual, attente and I are still in the indicator meeting ;)
[15:32] <seb128> k
[15:32] <qengho> yo.
[15:32] <Laney> move me a bit further down please
[15:32] <Laney> need to write an update
[15:32] <seb128> let's get started
[15:32] <Laney> :P
[15:32] <seb128> Laney, ok
[15:32] <seb128> qengho, hey
[15:32] <qengho> * Vacation.
[15:32] <qengho> * To-do: chromium-browser stable update to same as Saucy.
[15:32] <qengho> * To-do: investigate GL/GPU corruption in c-b.
[15:32] <qengho> * To-do: start.ubuntu.com on new-tab-page in c-b.
[15:32] <qengho> EOL
[15:32] <seb128> qengho, I hope you had good holidays!
[15:33] <qengho> I did. Met people. Got a flu.
[15:33] <qengho> Worth it.
[15:34] <seb128> seems like UDS :p
[15:34] <seb128> qengho, thanks
[15:34] <seb128> Sweetsha1k_away, I guess you are not here?
[15:34] <seb128> (he emailed saying he's at  http://blog.documentfoundation.org/2013/09/16/libreoffice-conference-schedule/)
[15:34] <seb128> ok, guess not
[15:34] <seb128> mlankhorst, hey
[15:36] <seb128> not there either?
[15:36] <seb128> desrt, hey
[15:36] <desrt> hihi
[15:36] <desrt> spent some time working on getting the stable releases out the door over the weekend
[15:37] <desrt> had some last-minute troubles with alex committing some potentially regression-causing changes to master the day before the release, so had to come up with a better solution to that (and managed to revert those changes)
[15:37] <mlankhorst> hey
[15:37] <mlankhorst> recovering from plumbers last week, helping debian with transitioning to 1.14
[15:37] <desrt> also managed to get the language support work finished on the desktop file indexd
[15:37] <Sarvatt> attente: that does work, i'll let him know when he logs back in :)
[15:37] <attente> Sarvatt, great, thanks
[15:38] <desrt> probably will spend most of the next week working on the compiler side of that, getting it integrated into the existing desktop file utilities, because we already have hooks for running those are the correct times
[15:38] <desrt> (eof)
[15:38] <seb128> desrt, ok
[15:38] <Laney> ready
[15:39] <seb128> desrt, btw you reviewed Laney's use of your new glib "du" api ... are you happy with the current version?
[15:39] <desrt> seb128: i didn't see a new version after my previous complaints
[15:39] <Laney> I didn't fix what he said
[15:39] <Laney> because I don't know what to do
[15:39] <desrt> Laney: let's chat after the meeting
[15:39] <Laney> k
[15:40] <seb128> desrt, thanks
[15:40] <seb128> Laney, your turn
[15:40] <Laney> (some of this might have been the week before as we skipped the meeting)
[15:40] <Laney> • Many discussions about u-s-s, deferring settings that won't happen for 13.10 and hiding them, trying to make the remaining targetted items work well.
[15:40] <Laney> ∘ Implemented a method to hide panels but make it so that devs and interested users can re-enable them.
[15:40] <Laney> ∘ Hide brightness, flight-mode, messages on greeter screen
[15:40] <Laney> ∘ Fix some bugs like the size of the time/date picker, the brightness slider being unusable due to Flickable scrolling and a weird dead spot that you could click on to get into a blank page.
[15:40] <Laney> ∘ C++ backend for click package info
[15:40] <Laney> ∘ Use GLib's new cool API for disk usage
[15:40] <Laney> ∘ Discussions about ro-/etc breaking timezone updates (and very likely other things we don't know about atm)
[15:40] <Laney> ∘ Using QMenumodel to toggle bluetooth (works) and location/gps (doesn't work yet)
[15:40] <Laney> ∘ Many reviews
[15:40] <Laney> • Update GLib
[15:40] <Laney> • Update GStreamer
[15:40] <Laney> • Lots of FFe reviews
[15:40] <Laney> • release discussions about milestone dates / migration blocks
[15:41] <Laney> • Work on block script to generate package block list for b2 (freeze on currently)
[15:41] <Laney> ∘ Handle unblocks requested by developers
[15:41] <Laney> • Patch pilot
[15:41] <Laney> EOW
[15:41] <seb128> busy week(s) ;-)
[15:42] <seb128> (and nice use of the unicode bullet points btw)
[15:42] <Laney> they look cooler in tomboy :P
[15:42] <Laney> there they get indented
[15:42] <seb128> larsu, Laney: nice to see the qmenumodel stuff used, I didn't look at the code much but saw some merge resquest diff and it seems simple enough ;-)
[15:42] <Laney> yeah it is quite nice
[15:43] <larsu> seb128: I'm a bit unhappy about it, because I didn't have time to make a better API for it
[15:43] <Laney> The API isn't /ideal/ but it works
[15:43] <larsu> so we're still using the one from waybackwhen, which has some problems
[15:43] <larsu> and bugs
[15:43] <seb128> k
[15:43] <Laney> handling the bidirectional stuff was a bit hard
[15:43] <seb128> well, it works and the diff are not crazy
[15:43] <Laney> but I think I got it
[15:43] <seb128> so it's enough for now
[15:43] <larsu> right
[15:43] <Laney> in the first version you got the widget infinitely toggling if you change it from the indicator
[15:43] <Laney> that was fun
[15:44] <seb128> hehe
[15:44] <seb128> can you get review from larsu if you have one pending?
[15:44] <seb128> I would welcome him doing the first reviews for us, since he knows the bindings better
[15:44] <Laney> ok, that one: https://code.launchpad.net/~laney/ubuntu-system-settings/battery-toggle-gps-bluetooth/+merge/187246
[15:44] <seb128> larsu, ^
[15:44] <larsu> yep, I'll have a look after the meeting
[15:44] <seb128> Laney, thanks ;-)
[15:44] <seb128> larsu, thanks
[15:45] <seb128> tkamppeter, hey
[15:45] <tkamppeter> - system-config-printer: Submitted all patches upstream, most are incorporated now, updated our system-config-printer package to a GIT snapshot with included patches
[15:45] <tkamppeter>  - Synced pyppd and HPLIP from Debian to include security fix in Debian
[15:45] <tkamppeter>  - More tests on tablet mode of Thinkpad Twist
[15:45] <tkamppeter>  - Some fixes on our CUPS package
[15:45] <tkamppeter>  - Bugs
[15:45] <tkamppeter>  - GSoC
[15:46] <seb128> tkamppeter, thanks
[15:46] <seb128> attente, hey
[15:46] <attente> hi seb128
[15:46] <attente> language system settings fixes
[15:46] <attente> i-keyboard, ubuntu-themes, gtk bugs
[15:46] <attente> (eof)
[15:47] <seb128> I saw your gtk mr to add back that patch, it's on my todolist, sorry for dropping it, dunno what happened (the vcs was probably missing a revision)
[15:47] <seb128> attente, thanks
[15:47] <attente> seb128, thanks
[15:47] <seb128> larsu, hey
[15:48] <larsu> hey
[15:48] <larsu> [short-ish week for me due to being a bit sick end of last week]
[15:48] <larsu> - made brightness slider in ubuntu-system-settings work (+ qmenumodel fix)
[15:48] <larsu> - spent some (a lot of) time trying to find the unmuting bug in indicator-sound. Tricky, still ongoing
[15:48] <larsu> - fixing indicator-sound scrolling bug (sometimes it takes really long to update the volume)
[15:48] <larsu> and lots of random pings / discussions this week
[15:49] <larsu> oh, eof
[15:49] <seb128> larsu, thanks, I hope you feel better!
[15:49] <larsu> seb128: I do, thanks
[15:49] <seb128> great
[15:50] <seb128> ok, my turn
[15:50] <seb128> - holidays
[15:50] <seb128> - emails catchup
[15:50] <seb128> - looked a bit at what happened in settings world/did some easy reviews
[15:50] <larsu> lol, emails ketchup.
[15:50] <seb128> ;-)
[15:50]  * larsu actually read it as that
[15:50] <seb128> - discussed a bit the new landing rules

[15:51] <mlankhorst> you forgot to start a recursion
[15:51] <mlankhorst> discussing in meeting how I'm discussing my day
[15:52] <seb128> haha
[15:52] <seb128> mlankhorst, thanks for the update
[15:52] <seb128> mlankhorst, btw "help debian to update xorg" is nice but not reality a priority for us at this point of the cycle
[15:53] <seb128> so please put it lower priority that other work
[15:53] <mlankhorst> oh no but it's nice to get debian dev :P
[15:53] <mlankhorst> and I'm feeling a bit sick
[15:53] <mlankhorst> i had some kernel stuff I was working on too, but needed a break from that
[15:53] <seb128> k
[15:53] <seb128> get better!
[15:54] <seb128> ok, I think we are done for our half of the meeting
[15:54] <seb128> any other topic/question?
[15:54] <mlankhorst> I will, probably met too many people :P
[15:56] <tkamppeter> seb128, do you know who is in charge of libcairo?
[15:57] <seb128> tkamppeter, hum, me I guess ... why?
[15:57] <Laney> something in the sponsor queue
[15:57] <tkamppeter> seb128, I have submitted a patch for our package, see bug 968785.
[15:57] <tkamppeter> seb128, and I did not get any answer after 2 weeks.
[15:58] <seb128> tkamppeter, ok, I'm going to have a week
[15:58] <seb128> blame Laney, he mentioned patch piloting in his summary :p
[15:58] <seb128> doh
[15:58] <seb128> tkamppeter, ok, I'm going to have a *look*
[15:58] <Laney> yeah I tried to work on some of the hard red ones
[15:58] <seb128> ok, no complain
[15:59] <seb128> letting me the easy ones, wfm ;-)
[15:59] <tkamppeter> seb128, it is about the problems of evince and other apps with slow printing.
[15:59] <seb128> tkamppeter, https://launchpadlibrarian.net/150389551/cairo_1.12.16-0ubuntu1_1.12.16-0ubuntu2.debdiff ... why do you change the spacing on an old changelog entry?
[15:59] <seb128> tkamppeter, I guess your editor is configured to remove trailing spaces? try to not do that in the changelogs though
[16:00] <seb128> tkamppeter, I can fix before upload so don't worry, just for next time
[16:00] <Laney> missing patch headers, tsk
[16:00] <tkamppeter> seb128, probably because I am using emacs and there was such a read square at the end of the line. Feel free to cut the hunk out of the patch.
[16:00] <seb128> yeah, as well
[16:00] <seb128> tkamppeter, ok
[16:00] <seb128> thanks everyone
[16:00] <seb128> didrocks, your turn
[16:00] <Laney> cheers
[16:00] <didrocks> yeah \o/
[16:00] <Mirv> o/
[16:00]  * Laney looks at updating glib
[16:00] <didrocks> Mirv: cyphermox: kenvandine: robru: how are you guys?
[16:00] <didrocks> sil is sick unfortunately ;)
[16:01] <didrocks> hey Mirv ;)
[16:01] <Mirv> cyphermox: re: #elsewhere yes I decided to upgrade also indicators on device before I ran unity8 autopilot and some other testing, even though it was noted that it wouldn't be needed.
[16:02] <cyphermox> ack
[16:02] <Mirv> didrocks: alive also after final beta freeze :)
[16:02] <robru> didrocks, tired :-/
[16:02] <larsu> Laney: the qmenumodel parts looks good to me, but I don't have time right now to test it. Should I top-approve anyway or do you want someone else to review more thoroughly?
[16:02] <didrocks> ok, let's start maybe
[16:03] <didrocks> I know this new process is giving us headache
[16:03] <didrocks> (me first TBH)
[16:03]  * kenvandine waves
[16:03] <didrocks> but let's live with it ;)
[16:03] <didrocks> how is it going for you guys? maybe let's start alphabetically
[16:03] <Laney> larsu: if seb128 can/wants to test then we can wait for that, otherwise approve away
[16:03] <didrocks> cyphermox: you're first then!
[16:03] <cyphermox> I don't have anything special to report, I've been busy with a NM bug fix for touch
[16:04] <cyphermox> that and MTP, though MTP is fine now
[16:04] <didrocks> ok
[16:04] <seb128> larsu, Laney: let's approve it
[16:04] <didrocks> so your turn kenvandine ;)
[16:04] <kenvandine> hey
[16:05] <kenvandine> i'll be out on vacation for the rest of the week
[16:05] <kenvandine> scrambling today to finish some content-hub before i leave
[16:05] <kenvandine> can someone follow through seeing the wallpapers merge lands?
[16:05] <kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-wallpapers/13_10/+merge/186813
[16:05] <kenvandine> fginther is looking into the failures
[16:06] <didrocks> kenvandine: ah ok, so 3 mens down (cyphermox busy on mtp), kenvandine on holidays and sil sick
[16:06] <didrocks> this is going well ;)
[16:06] <kenvandine> hehe
[16:06] <didrocks> kenvandine: ok, I'll add that to the list
[16:06] <kenvandine> thanks
[16:06] <cyphermox> didrocks: like I said, mtp is done...
[16:06] <didrocks> kenvandine: from your standpoint, everything is done?
[16:06] <kenvandine> no :/
[16:06] <kenvandine> close though
[16:06] <didrocks> cyphermox: are you free for some landings then?
[16:06] <cyphermox> should be today
[16:06] <kenvandine> the content-hub confined apps stuff is merged in trunk and ready to land though :)
[16:07] <didrocks> cyphermox: \o/
[16:07] <didrocks> kenvandine: great!
[16:07] <didrocks> cyphermox: mind looking/following this wallpaper stuff with fginther?
[16:08] <kenvandine> we met today to figure out exactly what else to do before 13.10, and descoped  like crazy :)
[16:08] <didrocks> kenvandine: ahah ;)
[16:08] <didrocks> kenvandine: I can believe you ;)
[16:08] <fginther> cyphermox, fyi. One of the problems blocking wallpaper is fixed, the other one *may* be fixed
[16:08] <didrocks> robru: mind as well giving a look at this with cyphermox and fginther ^?
[16:08] <robru> didrocks, ok
[16:09] <didrocks> thanks robru!
[16:10] <didrocks> while I'm adding this to the list, next in order is Mirv!
[16:10] <didrocks> Mirv still alive, then? ;)
[16:10] <Mirv> yep. aside from the process change related work + head aches, some "final" 13.10 work. after qt 5.1 was decided to be postponed to t (unity8 instability most of all), we got qtwebkit 5.1.1 compiled against 5.0.2 tested and included.
[16:10] <Mirv> which improves browsing performance quite a bit
[16:10] <didrocks> cyphermox: btw, you didn't still marked as DONE the libcolumbus transition, if it's done, please update it :(
[16:10] <Mirv> together with SDK team Qt Creator + plugins are also now quite final (aside from more major PPA updates)
[16:11] <didrocks> Mirv: excellent news!
[16:11] <Mirv> qtmultimedia-fork got in, I helped a bit on packaging of it
[16:12] <Mirv> I think that's about it
[16:12] <didrocks> anything qt-related still flying?
[16:12] <didrocks> apart from appmenu-qt patch
[16:12] <didrocks> that will be soon here
[16:12] <Mirv> well when people have the time there are the bugs to fix so that when t opens we could land 5.1
[16:13] <Mirv> but right now it's mostly the qtmultimedia-fork bits that jhodapp and others are working on and which don't affect the default qtmultimedia packages
[16:13] <didrocks> ok ;)
[16:13] <Mirv> and then Qt Creator 2.8 work, mostly ready but decided also to skip shipping of that to t archives + PPA backports
[16:13] <didrocks> ok, making sense to be at least conservative now ;)
[16:13] <didrocks> so you think you will have time for the new component I added to the spreadsheet?
[16:14] <didrocks> I don't remember if the one I gave to you this morning was  ubuntu-touch-customization-hooks or something else
[16:14] <Mirv> didrocks: hmm, didn't I add it there, if you talk about customization-hooks?-)
[16:14] <didrocks> I don't remember, flacky memory
[16:14] <didrocks> I think lool did a first review
[16:14] <Mirv> :P
[16:14] <didrocks> so we duplicated the effort :p
[16:14] <didrocks> and I had to explain what's the rules are
[16:15] <Mirv> I now saw on other channel that there was apparently some duplicate stuff
[16:15] <didrocks> anyway, ok, can you ensure it's finished?
[16:15] <didrocks> I didn't preNEW yet
[16:15] <Mirv> I added the work item, replied the e-mail and did the forst MP ;)
[16:15] <didrocks> nor deploy the change
[16:15] <Mirv> yes
[16:15] <didrocks> thanks!
[16:15] <didrocks> ok, robru, your turn! ;)
[16:15] <Mirv> didrocks: any idea which stack would be suitable?
[16:15] <robru> * spent most time chasing down numerous webapps build failures
[16:15] <robru> * did a bit of work with mterry and Mirv figuring out qtmultimedia MIR issues
[16:15] <robru> * had an agonizing UIF day trying to last-second build things but it kept ignoring trunk commits less than 4hrs old.
[16:16] <Mirv> robru: oh right the MIRing things were moving last week as well, true
[16:16] <robru> didrocks, I am sorely missing quaternourly releases -/
[16:16] <robru> :-/
[16:16] <Mirv> robru: Friday was quite agonizing, yes :S
[16:16] <didrocks> robru: I would +1 on that one :p
[16:16] <didrocks> Mirv: I think it was added to misc
[16:17] <Mirv> didrocks: ok, I'll find it then there
[16:17] <didrocks> robru: maybe you can investigate on this 4 hours thing
[16:17] <didrocks> Mirv: thanks!
[16:17] <robru> didrocks, well i don't know how... you know more about cu2d ;-)
[16:17] <didrocks> robru: did you see my answer?
[16:17] <didrocks> robru: from your description, this is a launchpad thing
[16:18] <didrocks> not cu2d, right?
[16:18] <robru> didrocks, well I dunno for sure. I thought that cu2d was caching the lp branches and only refreshing them every 4hrs or something
[16:19] <didrocks> robru: no, it's redownloading them from scratch
[16:19] <didrocks> are you talking about the timestamp in launchpad?
[16:19] <didrocks> or ignored tick?
[16:19] <didrocks> there are 2 parts
[16:19] <didrocks> some ticks are ignored if a stack was running at that time
[16:19] <didrocks> (as we build all or nothing)
[16:20] <didrocks> then, you mentionned that the timestamp on launchpad was 4 hours delayed
[16:20] <didrocks> and I guess that one is in launchpad
[16:20] <robru> didrocks, not talking about ignored ticks, I'm talking about all manual builds that I kick off myself. it never includes trunk commits less than 4hrs old.
[16:20] <didrocks> robru: can we try to dive right now on it with a specific case?
[16:20] <didrocks> robru: I'm really interesting on that one
[16:20] <didrocks> or can be an issue with the infra
[16:20] <robru> didrocks, well there's two links on that bug already :-P
[16:21] <didrocks> robru: well, I need to see it live
[16:21] <didrocks> to see the real logs
[16:21] <didrocks> robru: I'm constantly running new build those days
[16:21] <didrocks> and didn't notice that
[16:21] <robru> didrocks, ok, well is there a project you can make a trunk commit on right now? and then build the stack right now?
[16:21] <didrocks> robru: webapps is pretty safe
[16:22] <didrocks> ok, let's look at this together right now
[16:22] <didrocks> no need to keep the other blocked on that
[16:22] <didrocks> good luck with the new landing process, thanks everyone!
[16:23] <robru> didrocks, ok, so what kind of commit are we going to make to test this? something somehow harmless?
[16:23] <didrocks> robru: don't you have necessary cleanup on the packaging?
[16:23] <robru> didrocks, for webapps? no, that all has landed a long time ago.
[16:24] <didrocks> robru: maybe bumping the standards-version if one is not at the latest?
[16:25] <robru> didrocks, nope, they are all latest ;-)
[16:27] <didrocks> robru: maybe something in webcreds or friends? should be Mir-free at that point I guess ;)
[16:28] <robru> didrocks, ok, libfriends has 3.9.3, we can try there.
[16:28] <didrocks> robru: let's do this!
[16:29] <robru> didrocks, ok, I will commit direct to trunk so we don't have to wait for CI
[16:29] <didrocks> robru: +1
[16:29] <didrocks> robru: fwed you an email with a zeigeist request for today btw ;)
[16:30] <robru> didrocks, ok: http://bazaar.launchpad.net/~super-friends/libfriends/trunk/revision/76
[16:30] <robru> so now I will use cu2d-run to start a friends stack build, it will not find that commit.
[16:30] <didrocks> let's see ;)
[16:31] <robru> didrocks, http://10.97.0.1:8080/job/cu2d-friends-saucy/33/
[16:32] <Laney> robru: sorry I forgot to reply to your email
[16:33] <robru> Laney, no worries
[16:33] <Laney> webapps-applications got stuck because of unity-webapps-amazon
[16:33] <Laney> I guess that should be removed
[16:33] <robru> Laney, unity-webapps-amazon should be removed, yeah, it got absorbed into webapps-applications
[16:33] <Laney> maybe didrocks could take care of that ;-)
[16:33]  * Laney cannot
[16:33] <didrocks> robru: how do you run the stack?
[16:34] <robru> didrocks, ./cu2d-run -r saucy -R friends --check-with-whole-ppa
[16:34] <didrocks> robru: cu2d is not even starting
[16:34] <didrocks> robru: ah, but when you check with whole ppa
[16:34] <didrocks> you force a check
[16:34] <didrocks> nothing is rebuilt
[16:34] <didrocks> or consider for rebuilding
[16:34] <didrocks> why are you using check with whole ppa? ;)
[16:34] <robru> didrocks, so what is the point of this command? if I don't have that option it doesn't run
[16:34] <didrocks> robru: it should run
[16:34] <robru> $ ./cu2d-run -r saucy -R friends
[16:34] <robru> 2013-09-24 09:31:16,871 ERROR No project or check-with-whole-ppa parameter specified on the command line. This tool is used for those cases. Aborting!
[16:34] <didrocks> robru: right, to rebuild a whole stack, I disabled that at the time in the code
[16:35] <didrocks> robru: maybe we should bring that back, now it makes sense
[16:35] <robru> didrocks, yeah, I want to build the whole stack 99% of the time
[16:35] <Mirv> robru: yeah, I've launched the whole stack build from GUI, first job and without changing the launch parameters
[16:35] <didrocks> robru: I'm using the GUI for stack, but we can bring that in the CLI if you wish
[16:35] <didrocks> so the 4 hours things make sense
[16:36] <didrocks> then, next tick happens
[16:36] <didrocks> rebuilding the whole stack
[16:36] <didrocks> so you get the latest change
[16:36] <robru> didrocks, well it would be nice to have consistency. i didn't even know you could do it in the web interface until recently.
[16:36] <Mirv> robru: for example http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Friends/job/cu2d-friends-saucy/ -> be logged -> Build now (or whatever it's in English) -> don't change any parameters and launch it
[16:36] <didrocks> robru: yeah, people started to use the GUI because of this new usage, it's as you wish
[16:37] <didrocks> robru: I disabled that first because I thought there was no use case TBH and that it was just someone missing the "projects" parameter
[16:37] <didrocks> if you think it doesn't make sense, we can disable this check as well
[16:37] <robru> didrocks, if you're worried about misuse, maybe add a --really-build-whole-stack option :-P
[16:37] <didrocks> robru: hum, yeah, good idea ;)
[16:37] <didrocks> robru: it's pretty stupid python code, want to do that? ;)
[16:38] <didrocks> for a refreshing 10 minutes hack :p
[16:38] <robru> didrocks, ok
[16:38] <didrocks> thanks robru!
[16:38] <didrocks> happy that we have an explanation ;)
[16:38] <robru> i'll close the bug
[16:38] <didrocks> ok, thanks! ;)
[16:38] <Mirv> didrocks: was it that daily release system expects non-native package, or does it handle also native version numbers?
[16:38] <dupondje> Any idea's why my cursor would keep blinking when something redraws (its very noticable when playing audio in audacious). Any idea's on this? A bug in Saucy?
[16:39] <didrocks> Mirv: it should deal with native version numbers (if in split mode) and will make them non native
[16:39] <Mirv> didrocks: right, ok. well I'll like to see that so I'll not modify the changelog ver number manually.
[16:40] <didrocks> Mirv: yeah, that should be handled, (there is even some tests about it)
[16:40] <robru> didrocks, ^^ can you remove unity-webapps-amazon from the archive
[16:41] <didrocks> just from the archive, it's already removed from dailies?
[16:41] <robru> didrocks, yep, I did that already
[16:41]  * didrocks flushes
[16:42] <robru> didrocks, thanks
[16:42] <didrocks> robru: Laney: https://launchpad.net/ubuntu/+source/unity-webapps-amazon/+publishinghistory
[16:42] <Laney> ta very much
[16:42] <dupondje> Any idea's where I could start looking? Cause i'm quite out of idea's :s
[16:42] <robru> didrocks, great
[16:43] <didrocks> yw ;)
[16:44] <Mirv> didrocks: did we end the meeting btw?-)
[16:45] <didrocks> Mirv: yeah, a long time ago ;)
[16:45] <didrocks> 18:22:08     didrocks | ok, let's look at this together right now
[16:45] <didrocks> 18:22:14     didrocks | no need to keep the other blocked on that
[16:45] <didrocks> 18:22:22     didrocks | good luck with the new landing process, thanks everyone!
[16:46] <Mirv> didrocks: right, I thought that, the discussion just flowed so smoothly onwards with robru :)
[16:46] <Mirv> ok, g'night everyone!
[16:46] <didrocks> Mirv: heh, enjoy your evening!
[16:46] <robru> Mirv, night!