[08:56] <newman> hi unity is not displaying apps available for download
[09:21] <didrocks> davidcalle: hey, can you have look at https://bugs.launchpad.net/ubuntu/+source/unity-lens-video/+bug/1062037? seems your fix isn't enough
[09:21] <davidcalle> didrocks, hey
[09:21]  * davidcalle is looking
[09:42] <davidcalle> didrocks, ok, reproduced and fixed (Gio returns utf-8 encoded strings, Zeitgeist doesn't, and the lens was trying to encode a string from Gio, like it does for Zg ones). I really need to automate this, especially as we are going to change the logic next cycle. https://code.launchpad.net/~davidc3/unity-lens-videos/fixes-1062037/+merge/128893
[09:45] <didrocks> davidcalle: excellent! sil2100 on it? (can be part of the SRU0 drop)
[09:47] <seb128> didrocks, davidcalle, sil2100: that likely can still go in today
[09:47] <seb128> it's trivial and only on a lens, e.g not likely to break the desktop
[09:47] <seb128> they just accepted a fix from mvo for a frequent e.u.c issue
[09:49]  * sil2100 on it
[09:51] <sil2100> Targetted for SRU-0
[09:51] <sil2100> seb128: you mean even faster?
[09:58] <didrocks> sil2100: if the release team is ok with it, we can push it
[10:01] <sil2100> Oh, ok, I thought its not possible during the cold freeze
[10:01] <sil2100> I'll test it myself as well
[10:06] <sil2100> davidcalle: how can I easily reproduce #1062037 ?
[10:07] <davidcalle> sil2100, the fastest way to test it is to add a video in the Downloads folder (as Zeitgeist will catch it immediately), with the È character in the file name.
[10:07] <sil2100> davidcalle: awesome, thanks
[10:07] <davidcalle> sil2100, np
[10:19] <sil2100> davidcalle: works, approving!
[10:19] <davidcalle> sil2100, great, thanks!
[10:23] <didrocks> sil2100: can you backport it?
[10:23] <didrocks> sil2100: we can upload it because there is the need to rebuild the binary
[10:23] <sil2100> didrocks: yes, was doing it right now :)
[10:23] <didrocks> iso*
[10:23] <didrocks> thanks :)
[10:23] <sil2100> didrocks: cherry-pick is enough, right ;)?
[10:24] <didrocks> sil2100: sure :)
[10:27] <sil2100> didrocks: lp:~sil2100/unity-lens-videos/ubuntu_cp_fix
[10:28] <didrocks> sil2100: looking
[10:29] <didrocks> davidcalle: hum
[10:29] <didrocks> nevermind ;)
[10:30] <didrocks> sil2100: perfect, thanks!
[13:13] <didrocks> sil2100: did you look why unity FTBFS on armhf in staging?
[13:13] <didrocks> sil2100: seems to be a nux dep issue to me
[13:14] <didrocks> mmrazik: can be related to your new numbering scheme ^
[13:30] <sil2100> mmrazik|otp: ^ ?
[13:55] <didrocks> mmrazik: sil2100: anything?
[13:55] <didrocks> still 4 FTBS on armel/armhf
[13:56] <mmrazik> didrocks: srry.. missed this ping
[13:56] <sil2100> Indeed, just arrived another one
[13:56] <mmrazik> didrocks: so it was building before?
[13:57] <didrocks> mmrazik: before the switch, I don't remember having seen FTBFS
[13:57] <didrocks> it seems to pick the wrong nux
[13:57] <sil2100> mmrazik: maybe -proposed needs to be enabled?
[13:57] <sil2100> No, wrong, scratch that
[13:57] <didrocks> nothing in proposed :p
[13:57] <sil2100> Since 3.8.0-0ubuntu1 is in quantal
[13:57] <sil2100> ;)
[13:58] <sil2100> mmrazik: is that some internal mirror that's being used?
[13:59] <mmrazik> sil2100: there should not be any internal mirror. Just the local repo in a similar way unity-merger is using
[13:59] <mmrazik> sil2100: but this is failing in launchpad
[13:59] <mmrazik> well..
[13:59] <mmrazik> truth is we are not building armel in jenkins
[13:59] <mmrazik> we probably should
[13:59] <didrocks> mmrazik: also, another dummy question, but how do we see that all rdepends are rebuilt? the ppa doesn't seem to try rebuilding the rdepends
[14:01] <mmrazik> didrocks: fginther will be a better person to ask. I don't really know. I believe it just dputs a newer version into the ppa and lets it rebuild.
[14:01] <mmrazik> with a jenkins build number in the versioning scheme so the dput is not rejected
[14:01] <didrocks> fginther: ? ^
[14:01] <didrocks> mmrazik: I still tells you that this versionning sheme is doomed to fail :)
[14:02] <didrocks> especially the first time we'll have an xx+bzryyy in ubuntu
[14:02] <mmrazik> didrocks: TBH I didn't quite review what is being done there but isn't the curreent naming scheme pretty much the same what we had before stagingfuture?
[14:04] <didrocks> mmrazik: hum, not really
[14:04] <didrocks> also there are some quantal1 and quantal.1
[14:04] <didrocks> would be nice if there is some doc to explain the difference :)
[14:05] <mmrazik> didrocks: I have no clue what that is
[14:05] <mmrazik> fginther: ^
[14:05] <mmrazik> didrocks: so what is different other than that? the "pkg" thing will break it?
[14:06] <didrocks> mmrazik: I think so, imagine I'm pushing unity 6.8.0+bzr2821 to distro
[14:06] <didrocks> so we'll have 6.8.0+bzr2821-0ubuntu1
[14:06] <didrocks> next upload will create:
[14:07] <didrocks> 6.8.0+bzr2821+bzr2822+pkg794~quantal1
[14:07] <didrocks> which will be < than 6.8.0+bzr2821+pkg793~quantal1
[14:07] <didrocks> (previous upload)
[14:07] <didrocks> so the package will be rejected
[14:07] <mmrazik> right...
[14:07] <mmrazik> fginther: ^^ can we fix it?
[14:07] <mmrazik> I would vote for XXpkg as I don't really like some random numbers
[14:08] <didrocks> right, that's what staging had
[14:08] <didrocks> no + for that
[14:08] <didrocks> as + > [a-z]
[14:08] <didrocks> so:
[14:08] <mmrazik> didrocks: staging had +XX, or no?
[14:08] <didrocks> 6.8.0+bzr2821pkg793~quantal1
[14:08] <didrocks> nope, it had:
[14:08] <didrocks> 6.8.0+bzr2816stagingfutureubuntu0+793
[14:08] <didrocks> for instance
[14:09] <didrocks> no + at the end of bzr2816
[14:09] <didrocks> for that particular reason
[14:09] <didrocks> so that, we can have:
[14:09] <didrocks> 6.8.0+bzr2816 (in distro) -> 6.8.0+bzr2816+bzr2817stagingfutureubuntu0+794
[14:09] <didrocks> which is > to 6.8.0+bzr2816stagingfutureubuntu0+793
[14:10] <didrocks> so with your conventionning scheme, I would say:
[14:10] <didrocks> 6.8.0+bzr2821pkg793~quantal1
[14:10] <mmrazik> didrocks: regarding this stagingfuture stuff... we should talk about that in copenhagen
[14:10] <didrocks> not really sure why ~ though ;)
[14:10] <mmrazik> didrocks: it was in some howto I found somewhere on ubuntu wiki
[14:10] <didrocks> mmrazik: you mean, removing it? :)
[14:10] <mmrazik> I think
[14:10] <didrocks> hum?
[14:10] <mmrazik> didrocks: yes
[14:10] <mmrazik> didrocks: I mean the ~
[14:11] <mmrazik> but it was quite some time ago
[14:11] <mmrazik> so I might be wrong
[14:11] <didrocks> well, as we have random versions
[14:11] <didrocks> 6.8.0+bzr2821pkg793quantal1
[14:11] <didrocks> would do the same :)
[14:11] <didrocks> and you can still backport to 6.8.0+bzr2821pkg793precise1 if needed
[14:11] <mmrazik> fginther: lets go with "6.8.0+bzr2821pkg793quantal1"
[14:11] <mmrazik> I like that
[14:11] <didrocks> ~ means "less than"
[14:11] <didrocks> more used by distro :)
[14:13] <mmrazik> didrocks: I think the '~' comes from here: https://help.launchpad.net/Packaging/PPA/Uploading
[14:13] <didrocks> mmrazik: yeah, it's when we upload something that will go to distro in the end
[14:13] <didrocks> mmrazik: with the exact versionning
[14:13] <didrocks> so let's say, I'm preparing unity 6.8
[14:13] <didrocks> distro will have 6.8-0ubuntu1
[14:14] <didrocks> but I'm not sure about what I'm pushing, so I want that to be in a ppa
[14:14] <didrocks> I generally do:
[14:14] <didrocks> 6.8-0ubuntu1~ppa1
[14:14] <didrocks> then, if I screw up ;) 6.8-0ubuntu1~ppa2…
[14:14] <didrocks> in the end, when I push to distro 6.8-0ubuntu1, it's > than 6.8-0ubuntu1~whatever
[14:14] <didrocks> so people using the ppa will get the distro version
[14:14] <didrocks> this doesn't really apply here as staging have tweaked versionning
[14:15] <mmrazik> understood
[14:15] <mmrazik> I've never anticipated I will know this much about versioning
[14:15] <mmrazik> and I still know just a fraction
[14:16] <mmrazik> didrocks: btw. francis is afk for a while. will be back only later.
[14:16] <didrocks> mmrazik: how to learn versionning without wanting it :)
[14:16] <didrocks> mmrazik: no worry, keep me posted :)
[14:16] <mmrazik> yeah..
[14:30] <mmrazik> didrocks: is the arm* stuff critical (i.e. needs to be resolved today)?
[14:34] <didrocks> mmrazik: no, but it's spamming the email box since yesterday and as nobody reacted…
[14:34] <didrocks> would just be nice to ensure it's tracked and getting fixed :)
[14:34] <mmrazik> didrocks: I've seen it and talked about it with francis but as we were not sure if it is related to the change we decided to wait for a while :)
[14:35] <mmrazik> btw. where do you see these e-mails?
[14:35] <mmrazik> didn't realize its spamming somebody
[14:38] <didrocks> mmrazik: there is no launchpad rationale about it, but anyway, this kind of failure is needed to be tracked
[14:38] <mmrazik> didrocks: I'm watching it. The ps-jenkins user has a mailing list and we are subscribed there. So if the upload or build fails, launchpad will send the mail to the uploader (i.e. our list)
[14:38] <didrocks> mmrazik: I think everyone on the unity-team is receiving it
[14:39] <didrocks> as it's a ppa build failure
[14:39]  * sil2100 is receiving it for sure
[14:40] <mmrazik> ok. srry about that guys :-/
[14:40] <mmrazik> I won't make it today. Will ask francis to have a look. If not him then I'll look at it the first thing tomorrow morning
[14:42] <didrocks> thanks :)
[14:43] <sil2100> Francis should appear pretty soon
[14:56] <fginther> didrocks, sil2100, gentlemen, I'm catching up on the discussion
[14:59] <sil2100> fginther: thanks :)
[15:00] <fginther> didrocks, sil2100, So I have a version name issue to fix and a problem with build failures spamming the list
[15:01] <didrocks> fginther: indeed :)
[15:54] <fginther> didrocks, Would "6.8.0+bzr2821pkg793quantal.0" be acceptable? The trailing .0 should allow us to dput a .1, .2, etc. in the event that we need to force a rebuild in the ppa.
[16:07] <didrocks> fginther: and why not quantal0 instead of quantal.0?
[16:08] <didrocks> seems closer to what distro is using
[16:08] <Daekdroom> Why not quantal and then quantal0 ?
[16:08] <Daekdroom> or whatever distro is using
[16:10] <didrocks> Daekdroom: see above about the rebuild ^
[16:13] <fginther> didrocks, for some reason, I thought that wouldn't work with quantal9, quantal10, quantal11, etc. but I see now that it still works
[16:14] <fginther> didrocks, thanks
[16:14] <didrocks> fginther: yw :)
[16:23] <MCR1> smspillaz: Hi - thanks for commenting on bug 1006434
[16:24] <MCR1> smspillaz: I found a solution for it, simply inform CCSM that unityshell provides the feature showdesktop which fixes this and 2 other bugs.
[16:25] <MCR1> smspillaz: Maybe you remember the discussion we had about this problem and where you explained to me why unityshell got its own third showdesktop code.
[16:28] <MCR1> smspillaz: Please take a look at it: https://code.launchpad.net/~mc-return/unity/unity.merge-fix1006429-fix1006434-fix1063171/+merge/128745
[16:40] <sil2100> fginther: is the build failure for arm resolved?
[16:41] <fginther> sil2100, the builds appear to be failing due to a compile failure in nux (unity then fails to build because there are no nux packages)
[16:41] <sil2100> Ah, ok
[16:42] <sil2100> hm
[16:42] <sil2100> But only arm nux fails building, right?
[16:42] <fginther> sil2100, I've suppressed the rebuilds for a moment while I investigate
[16:42] <fginther> sil2100, nux and unity appear to be failing
[16:42] <fginther> I suspect once nux builds, so will unity
[16:43] <fginther> intel builds are ok
[16:44] <sil2100> Awesome, thanks :)
[16:45] <sil2100> fginther: ah, so merges are frozen now?
[16:47] <sil2100> fginther: since I got a mount: special device /var/cache/pbuilder/quantal-unity-team--sru does not exist error on one merge...
[16:47] <fginther> sil2100, merges are still going through and these will still cause a dput to the ppa
[16:47] <sil2100> https://code.launchpad.net/~mhr3/unity/fix-1061510-6.0/+merge/128973
[16:50] <fginther> sil2100, thanks. I'll add it to the stuff I'm investigating
[16:50] <sil2100> fginther: in the meantime, I'll re-approve it to make sure it's not a singular case :)
[16:51] <sil2100> In the meantime, it's over EOD for me, so see you tomorrow and good luck!
[17:10] <MCR1> bschaefer: Hi :) I've attached 2 screencasts to bug 1006434 showing the bug in action (Show Desktop plug-in with and without Unity)...
[17:11] <bschaefer> MCR1, hello, and awesome
[17:11] <MCR1> bschaefer: Please look at them to better understand the bug ;)
[17:12] <MCR1> bschaefer: It seems my English is very bad, noone understands it ;)
[17:13] <bschaefer> MCR1, hmm, well the videos should help
[17:14] <bschaefer> MCR1, but at the same time you just have give sam and them sometime to go over it :)
[17:14] <bschaefer> as they are very busy
[17:14] <bschaefer> MCR1, it also seems that sam understands the problem
[17:14] <bschaefer> from reading his comment
[17:14] <MCR1> bschaefer: With Kernel 3.6 I am still having many network problems - had to go back to 3.5 to be able to upload to launchpad... :P
[17:15]  * bschaefer hasn't noticed any problems yet
[17:15] <MCR1> Sure, I already talked with him about it quite a qhile ago...
[17:15] <MCR1> *while
[17:15] <bschaefer> o hmm
[17:15] <bschaefer> well since you have added them under the branch to be reviewed they should get to it soon
[17:15] <bschaefer> but they always seems to have to much stuff to do...
[17:16] <MCR1> yes, Compiz could need 10 additional sams and daniels ;)
[17:16] <bschaefer> yes it could
[17:17] <bschaefer> and should
[17:17] <MCR1> Unfortunately my skills are just good for newbie fixes...
[17:17] <bschaefer> ill try to poke them later again, i didn't get a chance last night (got busy on another bug)
[17:18] <bschaefer> well as long as your learning new things you wont be for long :)
[17:18] <bschaefer> plus compiz is a bit...overwhelming at first
[17:19] <MCR1> bschaefer: You do not need to poke them again, but you could comment on my branch that you tested the fix and that it prevents the combining of Show/FadeTo Desktop + Unity if you like...
[17:19] <bschaefer> MCR1, will do
[17:19] <MCR1> thx
[17:19] <MCR1> a lot
[17:20] <bschaefer> np!
[18:50] <dandrader> there's a bug with the latest unity when using an nvidia card (with nouveau or proprietary driver) where there's a colored rectangle being drawn where the launcher normally stands while the launcher is hidden. is that know? it started after I upgraded this morning
[18:50] <dandrader> when I boot my PC with the integrated intel graphics it works normally