[06:30] <DanChapman> good morning
[06:34] <elfy> hi DanChapman
[06:35] <DanChapman> hey elfy :-)
[07:07] <jibel> Good morning
[07:12] <elfy> hi jibel
[07:12] <jibel> morning elfy
[07:16] <DanChapman> gcollura: would you be able to review https://git.reviewboard.kde.org/r/117307/ and https://git.reviewboard.kde.org/r/117212/ if you have time today
[07:16] <DanChapman> oops wrong channel
[07:17] <DanChapman> morning jibel o/
[11:14] <pitti> jibel: I updated jenkins_config.xml.tmpl this morning to also include results/*-packages as artifacts; but apparently this hasn't been enabled for the recent jobs yet
[11:14] <pitti> jibel: I thought each new britney-induced job run would reconfigure the job?
[11:15] <pitti> jibel: at least I don't see *-packages in http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-libproxy/configure (that just ran)
[11:54] <jibel> pitti, it must be pulled on tachash, which I just did.
[12:27] <maclin> hi, pitti, the translation of Chinese has been reviewed and uploaded, could you help to rebuild the language package so that we can do the test on latest image?
[12:33] <maclin> Carlos, wzssyqa, Aron and our translation team of Ubuntu Kylin have been working on this for days. Our quality team want to check that in usage so that we have time to make feedback before final release.
[12:42] <maclin> pitti, hi, I am maclin of Ubuntu Kylin,  the Chinese translation has been reviewed and uploaded, could you help to rebuild the language package so that we can do the test on latest image?
[12:52] <pitti> jibel: ah, merci
[12:52] <pitti> maclin: langpack updates are back on auto since yesterday, so they'll hit trusty soon
[12:58] <maclin> thanks pitti, I am not so familiar with the process of langpack. I wonder that is it able to be merged into trusty in the coming image ISO?
[12:59] <pitti> maclin: actually, the cron job just ran this morning
[13:00] <pitti> maclin: yes, see https://launchpad.net/ubuntu/+source/language-pack-zh-hans/1:14.04+20140401
[13:00] <pitti> maclin: that ought to have the latest data (from LP yesterday)
[13:00] <pitti> maclin: it'll go from -proposed into trusty in a few hours
[13:01] <pitti> it still needs some time until it gets built, there's a new KDE currently taking the buildds
[13:01]  * pitti -> off IRC again, sprint
[13:03] <maclin> pitti, thanks, I get it, it is nice of you:)
[13:58] <Psy_> Hi, anyone willing to help me roport two visual bugs on Trusty Beta. I dont know the packages to file upon.
[13:59] <Psy_> I need an opinion, also :P
[14:35] <elopio> ping rhuddie, I'm not sure why this hasn't run the jenkins tests
[14:35] <elopio> https://code.launchpad.net/~rhuddie/gallery-app/photo_selector/+merge/208761
[14:35] <elopio> can you merge with trunk and push?
[14:36] <rhuddie> elopio, not sure why either... I'll do the merge now
[14:45] <rhuddie> elopio, done
[14:45] <elopio> rhuddie: can you review this one please? https://code.launchpad.net/~elopio/unity8/revert_open_preview/+merge/213771
[14:52] <rhuddie> elopio, I'm a bit confused what this line does: preview_list.x.wait_for(0)
[14:53] <elopio> rhuddie: that's something tsdgeos put. It's his way to check that the preview list is visible.
[14:53] <rhuddie> elopio, ok :)
[14:54] <elopio> I would like it to be clearer, but as things like preview_list.visible are always true, we don't have many options.
[15:45] <jibel> pitti, now that adt-run support *.packages, I think I can completely drop the rsync back from jenkins and collect the results directlry from the job artifacts
[15:45] <jibel> -r
[15:48] <pitti> jibel: oh, I suppose we sohuld also add testpkg-version, so that you don't have to parse this out of the full log?
[15:48] <pitti> jibel: oh nice, we can actually use *-packages? I wasn't aware that we do anything with that
[15:48] <jibel> pitti, yes that'd be great
[15:50] <jibel> pitti, with this, I can pull them into an incoming directory and feed britney to update the list of results
[15:50] <jibel> pitti, so the mechanism will be identical when we'll use queues
[15:51] <pitti> jibel: right, I added all this with the new spec in mind (and debci uses those)
[15:51] <pitti> jibel: so want me to add results/testpkg-version?
[15:51] <jibel> pitti, and I'm updating (slowly though :() the interface with britney with your spec in mind :)
[15:51] <jibel> pitti, yes if you can.
[15:52] <pitti> jibel: committed; how do I roll out to tachash? (or can I?)
[15:52] <jibel> pitti, I didn't find it in your spec, how do you guarantee that the right version are available before starting a test?
[15:52] <jibel> package indices might be out of sync
[15:52] <pitti> jibel: we can't guarantee it
[15:52] <jibel> between the system that request a test and the systems that execute them
[15:53] <pitti> jibel: at the moment we don't specify dependency versions in the request; we can add that if needed
[15:53] <jibel> okay
[15:53] <jibel> pitti, pulled r325
[15:53] <pitti> jibel: otherwise britney has to re-request the test
[15:54] <pitti> jibel: thanks (I rolled it out to wazn & friends, but I guess tachash is the crucial one)
[15:54] <jibel> pitti, for small package that's fine to re-request but for the big babies like libreoffice we cannot afford the cost of a re-request
[15:55] <pitti> jibel: ack; I'll add that to the spec; that would be like a request "trusty gtk+3.0 (3.1.2-1) eglibc (1.2.3-4)
[15:56] <pitti> jibel: and everything you specify needs to be at least that version, otherwise the test doesn't start?
[15:56] <pitti> jibel: that requires some adt-run support, otherwise we'd just have to do that looping on the worker node
[15:59] <jibel> pitti, right, something like this. But the version of the source package doesn't guarantee the binary packages are available yet.
[15:59] <jibel> pitti, could a worker consume a ticket and requeue it if it doesn't match certain criteria?
[15:59] <pitti> jibel: if we can specify binary packages, that's all the better of course
[15:59] <pitti> jibel: it can not ack it, but it will take some time to time out; but I'll think about that
[16:00] <jibel> pitti, if it does, adt-run could fail with specific exit status for unmet deps
[16:00] <pitti> jibel: right, that part is easy
[16:00] <pitti> jibel: I mean actively rejecting/requeueing the request
[16:00] <pitti> jibel: but it's certainly possible
[16:00] <jibel> s/unmet deps/required version are not there
[16:03] <jibel> pitti, I think it is not a problem in Debian yet but it is very frequent in Ubuntu because we trigger the tests as soon as a new version is uploaded. We reduced the impact by using the master archive, but on a fully distributed environment it might not be possible and will quickly become the cause of lot of failures
[16:04] <jibel> especially for *-common package that builds on i386 only
[16:04] <pitti> jibel: right; I mean, can britney request versions on binary package names, or just sources?
[16:04] <jibel> pitti, currently sources
[16:04] <pitti> jibel: or perhaps source of the package to test, but binary versions of the dependencies?
[16:06] <jibel> pitti, ideally it would be request to test a source package because binaries have changed, but currently it is only sources of package to test and source of the dependencies
[16:09] <pitti> jibel: ok, so we need to live with that
[16:09] <pitti> and do some heuristics to map that to binaries (possible, just has some bad edge cases)
[19:02] <Letozaf_> balloons, elopio, hello
[19:09] <elopio> Letozaf_: hola
[19:09] <elopio> Letozaf_: want to talk about your rss tabs?
[19:10] <Letozaf_> elopio, hello, yes thanks
[19:10] <elopio> Letozaf_: do you know how to use the autopilot vis?
[19:10] <Letozaf_> elopio, yes
[19:11] <elopio> Letozaf_: so, on the rss if you fire the vis you will see that inside the pagestack, no item is called Tabs.
[19:11]  * Letozaf_ is looking
[19:12] <elopio> inside the PageWrapper I mean.
[19:12] <Letozaf_> elopio, right there is not item called Tabs
[19:12] <elopio> they are called SavedTab
[19:12] <elopio> ShortsTab
[19:12] <elopio> etc...
[19:13] <Letozaf_> elopio, mmm ... just a second
[19:14] <thomi> Is anyone here a moderator for the ubuntu-quality mailing list? I guess balloons is, but I think he's on holiday
[19:14] <Letozaf_> elopio, under Pagewrapper I have a Tabs and under that I have SaveTab, ShortsTab
[19:14] <elopio> Letozaf_: yes, that's what I'm talking about.
[19:14] <elopio> that's because SavedTab extends the QML class called Tab, and autopilot sees only the new name.
[19:14] <Letozaf_> elopio, oh sorry I misunderstood :P
[19:15] <elopio> on the toolkit emulator we are asuming that every one is called Tab, so that's why you get the error.
[19:16] <Letozaf_> elopio, oh I understand, so I will have to work with the ShortsTab, SavedTab ect., right ? getting those directly
[19:16] <Letozaf_> elopio, and not using the tabs in emulator
[19:16] <Letozaf_> elopio, I will try now thanks
[19:17] <elopio> Letozaf_: in this case we can override the get_current_tab() to do a little more magic
[19:17] <Letozaf_> elopio, how :)
[19:19] <elopio> something like return self.select_single(index=self.selectedTabIndex)
[19:20] <elopio> Letozaf_: but that might be unstable. Instead I'm looking at your test, but I'm haven't fully understood what are you trying to check.
[19:21] <elopio> Letozaf_: so, the shorts tab is always the one you see when you open the app, right?
[19:21] <Letozaf_> elopio, well in the test I open the toolbar and click on the change mode button to change view from shorts to list
[19:22] <Letozaf_> elfy, so I want to verify that the shortsListModePage is visible
[19:22] <elopio> Letozaf_: I would do something like this pseudocode:
[19:22] <Letozaf_> elopio, yes the shorts tab is always the one you see when you open the app
[19:22] <Letozaf_> elopio, at least in a pristine environment
[19:23] <elfy> Letozaf_: I really hope that's a typo :D
[19:23] <Letozaf_> sorry typed elfy instead of elopio
[19:23] <Letozaf_> e1fy yes sorry :(
[19:23] <elfy> thank goodness for that :)
[19:24] <Letozaf_> elopio, if the shortsListModePage is visibile I can assume I changed view mode
[19:24] <Letozaf_> elfy, lol
[19:25] <elopio> self.assertFalse(self.main_view.shorts_tab.isListMode)
[19:25] <elopio> self.main_view.change_to_list_view()
[19:25] <elopio> self.assertTrue(self.main_view.shorts_tab.isListMode)
[19:26] <elopio> Letozaf_: that's how I would write the test ^
[19:26] <Letozaf_> elopio, well it is better than how I did it for sure :P
[19:26] <Letozaf_> elopio, can I copy that ?
[19:27] <elopio> Letozaf_: just a little more encapsualted. You would have to implement the change_to_list_view method and make the shorts_tab available as a property.
[19:28] <elopio> Letozaf_: and that test still has some problems. It might be better to do it with qttest instead of autopilot, because you are not really checking a user story here.
[19:28] <elopio> but as the rss currently has no qttests, it's ok to write it with autopilot. We might want to change it later.
[19:28] <Letozaf_> elopio, ok I will try to do as you say
[19:30] <elopio> Letozaf_: I'm going to have lunch, but if you need a hand leave me a ping or an email and I'll try to help when I get back.
[19:30] <Letozaf_> elopio, ok thanks a lot
[19:30] <elopio> thanks to you.
[19:30] <Letozaf_> elopio, :)
[19:31] <Letozaf_> elopio, buon appetito!
[19:33] <elopio> alesage|afk: I'll leave you just one more pita comment about your visual ordering branch.
[19:33] <elopio> there is already a test that checks that you return a list of applications
[19:33] <elopio> but that test checks the len of the expected and returned list, and then checks that all the items in the expected list are in the returned list.
[19:33] <elopio> that's because we had them in a different order.
[19:34] <elopio> now that the orders are the same, we could remove the test you added and in the existing test change the len and contains check for a single
[19:34] <elopio> self.assertEqual(expected_list, returned_list)
[19:34] <elopio> I might be wrong, because I'm hungry. I'll ping you when I return in ~2 hours.
[20:11] <Psy_> Hi, anyone willing to help me report  a visual bug on Trusty Beta. I dont know the packages to file upon...
[20:17] <elfy> try explaining what you see - what flavour you are using
[20:18] <Psy_> I'm testing Ubuntu i386 beta 2. I have a screenshot
[20:18] <Psy_> https://dl.dropboxusercontent.com/u/188946/Screenshot%20from%202014-01-28%2014_30_16.png
[20:19] <Psy_> Seems to me that both the hightlighted text and the top/bottom arrows need to be white
[20:20] <Psy_> As far as I know, this only happens on dropdowns menues
[20:23] <elfy> counts me out - I've not actually looked at ubuntu at all this cycle for longer than 10 minutes I'm afraid
[20:23] <Psy_> I currently don't have a dedicated Ubuntu machine (for now), and I only tested this on a live session. I want to confirm this happening on a full install
[20:24] <Psy_> elfy: I'm in a similar situation. I can't even peek inside the theme to figure out the problem.
[20:25] <elfy> I'd only look in a vm myself
[20:25] <elfy> Psy_: hang around - someone will have more of an idea than me
[20:27] <elfy> Psy_: actually ...
[20:28] <Psy_> Thanks elfy. I'm pretty sure this is something that got wrong after some GTK3 update
[20:28] <elfy> report it against unity - ubuntu-bug unity
[20:29] <elfy> but it looks similar to bug 1301206
[20:30] <Psy_> Mmmm, maybe, but I'll report anyway. Thanks.
[20:33] <Psy_> Another thing I've found but I think this is by design: there is no visual feedback clicking on the shutdown/restart buttons, that seems odd if the system did not restart immediately.
[20:35] <elfy> I'd have absolutely no idea about that :) I use xubuntu
[20:35] <Psy_> Haha ok!
[21:07] <alesage> elopio, I do see that there's some overlap in those tests, just taking the title of that initial test at its word that it's testing the type of the return :)
[21:08] <alesage> elopio, no objection to just removing so long as we're testing ordering too of course
[21:44] <UBUNTU-FAN> hi
[21:45] <UBUNTU-FAN> hi
[21:45] <UBUNTU-FAN> LOL
[21:45] <UBUNTU-FAN> SPAM
[21:45] <UBUNTU-FAN> FREE DRUGS
[21:45] <UBUNTU-FAN> SIKE
[21:53] <support> hi
[21:54] <Guest70303> um hi I cant upgrade to ubuntu 14.04
[21:56] <elopio> alesage: yes, if we check for the equality of the lists we will be checking the order.
[21:56] <alesage> elopio, ok shall I make that change, then?
[21:57] <elopio> alesage: yes please.
[21:57] <Guest70303> hi
[21:57] <alesage> elopio, ok!
[21:57] <elopio> alesage: also make sure to merge with trunk, that comes with many new things.
[21:57] <alesage> elopio, ok will merge again just to be certain
[21:58] <Guest70303> hi4
[21:59] <Guest70303> So I have heard about the ubuntu release of trusty Seems like I cant upgrade right at stage 2
[22:00] <elopio> alesage: can you please review this small one? https://code.launchpad.net/~elopio/unity8/error_on_missing_url-dispatcher/+merge/213339
[22:00] <alesage> elopio ok
[22:06] <Guest70303> can someone help me
[22:09] <Psy_> hi Guest70303 as far as I know, Ubuntu is still in beta and should be release April 17th https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[22:10] <Psy_> Are you trying to update to the final version or the beta?
[22:10] <Guest70303> beta
[22:10] <Guest70303> I am testing
[22:11] <Psy_> Are you using the pre-released updates? That should do the trick
[22:12] <Guest70303> which ones
[22:12] <Psy_> On software & updates -> updates
[22:12] <Psy_> Let me see I can find a tutorial
[22:13] <Psy_> http://itsfoss.com/upgrade-ubuntu-1404-beta-1310/
[22:15] <Guest70303> Im am doing the steps will be right back thanks for the help ;)
[22:16] <Psy_> Check the "troubleshoot" part, I bet thats the problem
[22:16] <Guest70303> something happend when I was getting the update W: Failed to fetch http://ppa.launchpad.net/merlwiz79/cinnamon-ppa/ubuntu/dists/saucy/main/binary-amd64/Packages  404  Not Found  W: Failed to fetch http://ppa.launchpad.net/merlwiz79/cinnamon-ppa/ubuntu/dists/saucy/main/binary-i386/Packages  404  Not Found  E: Some index files failed to download. They have been ignored, or old ones used instead.
[22:19] <Guest70303> wait looked at the troubleshooting, but It didn't work
[22:19] <Psy_> Yeah, but thats the Cinanamon desktop, is not part of Ubuntu
[22:21] <Psy_> Try removing the ppa: sudo apt-add-repository --remove ppa:merlwiz79/cinnamon-ppa I believe
[22:27] <Guest70303> ok do I have to removee themes too
[22:31] <Psy_> cinnamon themes?
[22:31] <Guest70303> ya
[22:31] <Psy_> I think not, but if don't have CInnamon anymore, why not?
[22:31] <Psy_> But I'm not sure this is the problem
[22:32] <Guest70303> ok let me install updates and see if it works
[22:35] <Guest70303> I still have cinnamon
[22:38] <Guest70303> I cant uninstall I will do it from the gui
[22:40] <Psy_> If you do an app update now, you get any errors?
[22:42] <Guest70303> thx its working I will be back when the upgrades done
[22:46] <Psy_> great!
[22:58] <alesage> elopio, sorry I'm just testing this teensy MP of yours on my device :) , trying to be thorough, y'know
[22:58] <elopio> alesage: no need to apologize for that :)
[23:06] <Guest70303> will daul boot affect ubuntu 14.04
[23:08] <Psy_> If 13.10 was working OK, I doubt it, but I'm not sure if 14.04 updates GRUB.
[23:08] <Psy_> elopio: was GRUB 2.02beta intended to land on 14.04?
[23:09] <elopio> Psy_: I have no idea.
[23:09] <elopio> #ubuntu-devel is a better place for that question.
[23:10] <Psy_> Thanks. I think they'll keep it on proposed until further testing.
[23:11] <Psy_> Guest70303: I think 14.04 will boot more or less identical to 13.10
[23:20] <Guest70303> ok
[23:21] <Guest70303> I will check where elopio said