[04:11] <pitti> Good morning
[06:46] <jibel_> Good morning
[06:49] <elfy> morning jibel
[06:50] <jibel> hey elfy
[06:52] <pitti> hey elfy
[06:52] <elfy> hi pitti :)
[07:03] <pitti> jibel: wow, somethign keeps triggering libo and linux.. /me kills
[07:06] <elfy> pitti: not got around to systemd'ing a unicorn install yet - is it as simple as adding the init line to grub?
[07:07] <pitti> elfy: yes, but be aware that you willl run into breakage on every other corner :)
[07:07] <jibel> pitti, linux has been triggered by initramfs and libreoffice by python3.4
[07:07] <pitti> elfy: like, packages fail to install because our update-rc.d doesn't yet know about systemd, etc.
[07:08] <elfy> that's ok - I'll not be using it fulltime :)
[07:08] <pitti> elfy: I will get back to this ASAP, but in the last week or so I kept being busy with autopkgtest fires..
[07:08] <elfy> yea - understand that :)
[07:08] <pitti> elfy: but so far I'm not aware of any permanent breakage -- at worst, you need to reboot back to upstart after a failed dist-upgrade and finish it from there
[07:09] <jibel> pitti, did you create a job that provision utopic VMS ?
[07:09] <pitti> jibel: yes, I told you yesterday -- I updated the adt-setup-testbed job
[07:09] <jibel> pitti, thanks I couldn't find it
[07:10] <pitti> jibel: oh, erk
[07:10] <pitti> jibel: I'm afraid I changed *trusty*-adt-setup-testbed
[07:10] <jibel> pitti, that explains it :)
[07:10] <pitti> jibel: sorry, I guess we shuold restore trusty (I kept the old command commented out)
[07:10] <jibel> pitti, I'll restore trusty and create utopic if you don't mind
[07:10] <pitti> jibel: and maybe only run trusty once every week or so?
[07:10] <jibel> pitti, don't worry, I'll do it
[07:11] <pitti> jibel: please; sorry for messing up
[07:11] <jibel> np
[07:11] <pitti> jibel: I'll go for a round of cleaning up stale processes on the workers
[07:12] <pitti> jibel: I now committed various fixes and a signal handler to autopkgtest to properly clean up on SIGTERM and timeouts
[07:12] <pitti> so, hopefully no more zombie processes and stale QEMUs if we cancel from jenkins
[07:12] <jibel> pitti, nice, thanks.
[07:13] <pitti> jibel: and I also think I found a good enough solution for the performance problem now
[07:13] <pitti> final tests are running locally, then I'll roll this out
[07:13] <jibel> pitti, how did you do?
[07:15] <pitti> jibel: I disabled the usage of the shared downtmp again, reverted some hacks for that (which should be faster), and found the cause of these "tar: unexpected EOF" errors
[07:15] <pitti> jibel: so in effect, it now uses tar in the 9p mount to copy trees, which we found is much faster
[07:16] <pitti> the principal race condition for the "EOF error" isn't fully fixed yet, but I don't have a good idea about that yet; but it shoudl be good enough now; if we still get it, I at least know where to tweak
[07:17] <pitti> jibel: I now added a test case for copying back and forth 1.000 files with 100 MB in total, and limiting that to copy timeout of 5 seconds
[07:20] <jibel> pitti, I also noticed that 9p performance degrades over time, I'll do more tests to know if it's QEMU's fault or really 9p
[07:20] <pitti> jibel: over time> while qemu is running?
[07:21] <jibel> pitti, yes in Qemu, if you copy file back and forth over 9p
[07:21] <jibel> *files
[07:23] <pitti> jibel: so ATM, {trusty,utopic}-setup-testbed run at 5 */4 * * *
[07:23] <pitti> jibel: so apparently that's not like cron?
[07:23] <pitti> jibel: or do you actually want to run setup-testbed every 4 hours?
[07:23] <jibel> pitti, it is like cron, we check if there is a new image every 4 hours
[07:23] <pitti> jibel: I guess for trusty it's enough to run it on e. g. 5 3 * * 0 ?
[07:24] <jibel> pitti, it's just an http ping
[07:24] <pitti> jibel: ah, I see;
[07:24] <jibel> and if md5sums changed it starts the job
[07:24] <pitti> so the adt-buildvm-ubuntu-cloud script won't do that, it will just always build
[07:24] <pitti> ah no, that's the URLTrigger in the job
[07:25] <pitti> nice
[07:25] <jibel> pitti, yes, it's the trigger
[07:25] <jibel> pitti, for example, if trusty image build is disable until a few week before .1 it won't build any new VM
[07:30]  * pitti restarts binutils and chromium and holds breath
[07:34] <jibel> pitti, once it's stable I'll trigger a run of all the packages with autopkgtests that are not in the list yet
[07:36] <pitti> jibel: which list?
[07:36] <jibel> pitti, on jenkins I mean http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/
[07:36] <pitti> jibel: ah, i. e. jobs which haven't got triggered yet
[07:37] <jibel> pitti, yes, packages copied from trusty for example
[07:40] <pitti> hmm, cyclops-node24 seems AWOL
[07:44] <pitti> jibel: chromium/amd64 success!
[07:44] <pitti> i386 is still busy fetching packages
[07:47] <jibel> \o/
[07:48] <pitti> ah, setup-testbed is running
[07:49] <pitti> ok, gave the armhf and ppc64el nodes some upgrade/cleanup/reboot love
[07:50] <jibel> pitti, I started it manually
[07:54] <jibel> pitti, 100 packages are missing from jenkins, I'll trigger them when wazn's queue is empty and setup-testbed is done
[07:54] <pitti> jibel: right, I was about to ask  -- I also started libo and linux now, let's finish all running jobs first
[07:56] <pitti> jibel: I also think I just got a better idea how to handle stdin in the qemu auxverb (the thing that causes the "tar EOF" errors)
[07:57] <pitti> jibel: but I figure I'll switch to your britney branch now
[08:28] <pitti> jibel: libo now failed "properly", looks like missing @builddep@ or build-essential or similar dep
[08:47] <jibel> pitti, it's weird, setup-testbed froze on every hosts
[08:48] <jibel> correction, on albali
[08:48] <pitti> jibel: right, alderamin/aldebaran finished
[08:49] <pitti> and I think wazn stil makes progress
[08:49] <jibel> yes, that's just albali
[08:49] <pitti> jibel: albali also runs adt-linux and another test, though
[08:49] <pitti> maybe it's just IO/CPU stalled?
[08:50] <pitti> jibel: I'd pretend to not have seen it, and check again in 15 mins or so?
[09:16] <pitti> jibel: I submitted my first batch of commentary on https://code.launchpad.net/~jibel/britney/fix_missing_results/+merge/218467, I started with the tests
[09:16] <pitti> in case you already want to work on that while I do the code review
[09:17] <pitti> jibel: oh, wazn finished setup-testbed in the meantime
[09:17] <pitti> jibel: but I have the feeling that albali is still running with the old job configuration
[09:18] <pitti> jibel: http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-setup-testbed/ARCH=i386,label=albali/1/console is lp:auto-package-testing definitively
[09:18] <pitti> jibel: I'll kill those two
[09:22] <jibel> pitti, argh :(
[09:22] <jibel> pitti, I need them for dkms
[09:23] <jibel> it is still using old style VMs
[09:23] <pitti> jibel: yes, but that shell script says "wazn"
[09:23] <pitti> these were running on albali
[09:23] <jibel> pitti, ah, right I added it afterwards, anyway I don't need it on albali
[09:23] <pitti> jibel: but I didn't actually kill any qemu on albali, just the prepare-testbed command; that indeed seemed stuck
[09:24] <pitti> ah, ok
[09:24] <pitti> jibel: so it seems all is well for now wrt. testbeds
[09:24] <pitti> albali did get fresh adt-virt-qemu images (from 20 mins ago)
[09:25] <jibel> pitti, and it succeeded on wazn, so all is good
[09:25] <pitti> jibel: I'd say, kick the other jobs, to give the other nodes something to do :)
[09:28] <jibel> pitti, I'm checking that queuing is fine with abi-compliance-checker then will trigger the rest
[09:30] <jibel> and it it. Queuing new 96 jobs
[09:30] <jibel> *96 new
[09:32] <pitti> \o/
[09:33] <jibel> that'll keep them busy for a while :)
[09:37] <pitti> yay, "unexpected EOF" again; /me bumps the sleep up a notch
[09:37] <pitti> in retrospect we should probably have done that after fixing that race properly :/
[09:40] <jibel> pitti, thanks for the review, I'll fix the MP
[09:48] <pitti> jibel: so in autopkgtest.py: def read() reads the history file? or what?
[09:55] <pitti> jibel: ah no, it's a results file, such as "green 1.1~alpha PASS green 1.1~beta", right?
[09:59] <jibel> pitti, right
[10:03] <pitti> jibel: so for read() the behaviour didn't actually change, AFAICS; you just shuffled the Python code a bit, right?
[10:03] <pitti> oh wait, I was missing the sorted() bits
[10:03]  * pitti looks closer, this is all new code to me
[10:04] <pitti> ah nevermind, all_vers was assigned, but not used anywhere
[10:05] <pitti> jibel: so yes, read() should not have changed, just made easier to read (and maybe more efficient)?
[10:13] <jibel> pitti, read() changed that where the problem was actually
[10:13] <jibel> pitti, it assigned the same status to all the tuple pkg/cause
[10:16] <pitti> jibel: ah; probably all_vers was actually meant to be used instead of being dead code, and the intent was to use the latest result from it?
[10:18] <jibel> pitti, I don't think so, the problem was in the structure of pkglist because it aggregates all the causes for a given package with only 1 status
[10:18] <jibel> pitti, but you can have different statuses for different pkg/cause
[10:18] <pitti> right
[10:18] <pitti> jibel: so the self.pkgcauses was meant for that
[10:19] <jibel> pitti, so basically what I did it to move the status to the same level than the cause
[10:19] <pitti> but even now it puts the same status into all pkgcauses entries, doesn't it?
[10:19] <jibel> pitti, right, but it was built from pkglist which was wrong
[10:19] <pitti> oooh
[10:19] <pitti> yes, and now status is taken from the read line
[10:19] <jibel> yes
[10:19] <pitti> jibel: je le comprends maintenant, merci :)
[11:12] <pitti> jibel: followed up again with the other review parts
[12:07] <jibel> pitti, thank you, I'll fix the MP
[12:57] <jibel> I'll retrigger the same autopkgtest than this morning once the race is properly fixed, instead of re-runnning them 1 by 1
[12:57] <jibel> pitti, ^
[12:57] <pitti> jibel: oh, why?
[12:58] <pitti> jibel: I only retrigger the relatively  few that fail due to the EOF issue
[12:58] <pitti> jibel: most actually fail for "real"
[12:58] <pitti> jibel: I just fixed python-cffi, that now also produced the 2.7 GB log file (not any more with latest upload)
[12:58] <pitti> jibel: I'm looking at all failures and track the ones which are "mine"
[13:00] <pitti> jibel: but it looks like we are through, only dkms bits in the queue now
[13:00] <pitti> only about 5 which are left on my list to retry/fix
[13:03] <jibel> that's fine then
[13:20] <pitti> jibel: hm, did you get a "fixed" mail for python-roman? I think I sometimes don't get state change mails
[13:22] <jibel> pitti, my "notifications" folder is empty, I'll have a look
[13:24] <pitti> jibel: no worries; darn, I interrupted you again from the britney branch
[13:26] <jibel> pitti, d-jenkins seems to be in a bad shape, it's swapping like crazy, OOM killer in action and scary java traces in jenkins' log
[13:26] <pitti> jibel: still the python-cffi 2.7 GB log perhaps?
[13:27] <jibel> pitti, maybe, I don't have access to the admin console to see the status of the publication queue
[13:29] <pitti> jibel: so, retoaded to the rescue?
[13:29] <jibel> pitti, in the testsuite of britney __merge_records simulates how adt-britney order the results in history. So the actual code is in adt-britney, I added it to the testsuite instead of the fake adt-britney for convenience
[13:30] <jibel> pitti, how do you think I should do?
[13:30] <pitti> jibel: ah; I thought the order of the result file shouldn't matter ideally
[13:31] <pitti> jibel: but if it does, the current approach seems fine to me; it would just be nice to have a comment on it what it does
[13:33] <jibel> pitti, it shouldn't matter really but that's how we got the bug where packages are wrongly promoted
[13:33] <pitti> jibel: so leave it as it is with a quick explanation?
[13:34] <jibel> pitti, sure
[13:50] <retoaded> jibel, pitti: it looks like it is the utopic-adt-python-cffi job that is blocking the publication queue
[13:51] <pitti> retoaded: right, that was my guess; I fixed the package now, so that it succeeds and doesn't produce a ginormous log, but the run from ubuntu1 is still there
[13:51] <pitti> retoaded: feel free to kill that entirely if it helps
[13:52] <retoaded> pitti, ack. will see what I can do with it
[14:03] <jibel> pitti, retoaded I don't think we can 'kill' it without restarting jenkins, it's a jenkins thread and there is notthing to kill apart jenkins itself
[14:04] <jibel> retoaded, last time it happened, I stopped jenkins, removed manually from bp.xml and restarted jenkins
[14:05] <retoaded> jibel, yes that is indeed the case and procedure. however, I'm not going to kill the jenkins instance at this time.
[14:11] <jibel> does jenkins needs a plugin to enable horizontal scrollbars :(
[14:44] <jibel> finally, I'm done with dkms views. I want a API in jenkins for that before next release
[14:44] <jibel> ah, Christmas is after the release, that's too bad :(
[14:46] <pitti> jibel: or we manage to move to AMPQ/debci view before that :)
[14:55] <elopio> balloons: can you give a try to my branch?
[14:55] <elopio> https://code.launchpad.net/~elopio/reminders-app/test_with_account/+merge/217171
[14:57] <balloons> elopio, morning. I had a go at it earlier.. is it better now?
[14:57] <elopio> balloons: it's passing on my machine, but on jenkins it times out.
[14:58] <elopio> balloons: what's the result for you?
[14:58] <balloons> elopio, ahh yea nothing has changed
[14:58] <balloons> so I built the binary and try to run it
[14:58] <balloons> I get an error immeadiately. Let me send a log
[14:59] <balloons> http://paste.ubuntu.com/7410848/
[14:59] <balloons> do I have to force py3? I'm also trying on the device in just a sec
[15:26] <elopio> balloons: I'm running it with py3, but I think it's not needed.
[15:27] <elopio> balloons: do you have time to debug? I don't know why the argument is None on your call in credentials.py.
[15:27] <balloons> elopio, py3 didn't change anything.. and yes I have tie
[15:27] <balloons> *time
[15:30] <elopio> balloons: please put a import pdb; pdb.set_trace() in _process_session
[15:48] <elfy> +
[16:03] <senan> balloons, danchapman, hi
[16:03] <balloons> aloha senan
[16:05] <senan> balloons, sorry for being invisible for long :)
[16:07] <senan> balloons, I like to start working again.. can you find something for me
[16:08] <balloons> senan, ohh, well, what are you interested in? Would you like to try working on a core app?
[16:09] <senan> balloons, yea..anything is fine
[16:10] <balloons> senan, this is important and shouldn't be too hard to add :-) https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1188819
[16:11] <balloons> I know Carla has it assigned but she isn't working on it atm, afaik
[16:11] <balloons> senan, this one goes along with it: https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1188818
[16:13] <senan> balloons, let me see
[16:19] <senan> balloons, how do I install core apps
[16:22] <balloons> senan, you can install them using the ppa
[16:23] <balloons> but if you simply branch the calendar app you can just run it manually with qmlscene
[16:23] <balloons> bzr branch lp:ubuntu-calendar-app
[16:23] <senan> balloons, I haven't tried any qt apps with autopilot
[16:24] <balloons> senan, go ahead and branch it and I'll walk you through it :-)
[16:25] <senan> balloons, Its done
[16:25] <elfy> hi balloons
[16:26] <balloons> hi elfy
[16:26] <elfy> balloons: quick note - why is it that ubuntulog bot isn''t in -autopilot - shouldn't it be there so people can look?
[16:27] <elfy> balloons: more importantly - I hope you're well - not seen you for days
[16:27] <balloons> senan, ok, so if you cd into ubuntu-calendar-app you will find a file called calendar.qml
[16:27] <balloons> you can run the app by doing this
[16:27] <balloons> cd ubuntu-calendar-app
[16:27] <balloons> qmlscene calendar.qml
[16:27] <balloons> elfy, interesting there is no bot in there.. hmm
[16:28] <elfy> just thought I'd mention it :)
[16:28] <elfy> I am after all the seeker of the obvious to tell you about :)
[16:28] <senan> balloons, got error
[16:28] <senan> balloons, could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmlscene': No such file or directory
[16:28] <balloons> elfy, I had jury duty, hehe
[16:28] <balloons> I am doing well today :-)
[16:29] <balloons> ty for asking!
[16:29] <elfy> awesome I had that once
[16:29] <elfy> he's not guilty - you can go home :p
[16:29] <balloons> senan, ahh yes.. you need to install the goodies first
[16:29] <balloons> senan, install the meta-package ubuntu-sdk
[16:29] <balloons> sudo apt-get install ubuntu-sdk
[16:29] <balloons> it will be big, but it should get you everything you need
[16:30] <senan> balloons, yea ok..I'm updating my system now.. will do it once it is complete
[16:33] <balloons> senan, ok, so once complete yea, you can run the app then with qmlscene
[16:33] <balloons> the autopilot tests are found in tests/autopilot, you can have a look at them while you are waiting for the download to complete
[16:33] <senan> balloons, Yea I'm looking it to it now :)
[16:33] <balloons> so to run the tests, cd into tests/autopilot, then do the normal autopilot list and autopilot run
[16:35] <balloons> I'll hold off on explaining too much before you dig in a bit, but I think you'll like working on qml apps. It's easier than gtk
[17:00] <elopio> balloons: if account-console list shows you evernote accounts, that could be your problem.
[17:00] <balloons> elopio, it does :-)
[17:01] <elopio> account-console delete ###
[17:08] <balloons> elopio, finally ;-)
[17:08] <balloons> ok so I deleted the account, pdb is set
[17:08] <balloons> it still does not work
[17:19] <balloons> senan, everything installed yet? :-)
[17:20] <senan> balloons, yea.. I am able to launch calender app now
[17:20] <balloons> senan, awesome. Are you able to run the tests as well?
[17:20] <senan> balloons, the new event creation is already there right ?
[17:21] <balloons> senan, yes it is
[17:21] <balloons> there is several tests, new event creation is one of them
[17:22] <senan> balloons, the bug you mentioned is create event and remove event right
[17:22] <balloons> senan, it's to edit an event and remove an event
[17:23] <senan> balloons, ohh ok :)
[17:25] <senan> balloons, autoplilot run calenderapp will run the test ?
[17:26] <balloons> senan, cd to tests/autopilot
[17:26] <senan> balloons, i got an import error
[17:26] <balloons> inside that directory you'll see another directory which is the name of the testsuite
[17:26] <senan> ubuntuitoolkit
[17:26] <balloons> should be calendar_app I believe
[17:26] <balloons> senan, ohh, right, you should install that also :-)
[17:27] <balloons> senan, sudo apt-get install ubuntu-ui-toolkit-autopilot
[17:27] <balloons> the toolkit is a helper that provides useful methods for you to use during test writing
[17:28] <balloons> senan, see http://developer.ubuntu.com/api/devel/ubuntu-14.04/autopilot/emulator/ubuntuuitoolkit.html#module-ubuntuuitoolkit.emulators
[17:29] <senan> balloons, Now  I'm able to run the tests
[17:32] <balloons> senan, excellent
[17:34] <senan> balloons, anything else I need to setup ?
[17:34] <balloons> senan, I think you are good. Now that you are able to run the tests you should be set to add more
[17:35] <senan> balloons, tests are added in separate file or adding to the existing one ?
[17:35] <balloons> senan, if you open calendar.qml in a text editor, I want to show you something
[17:36] <senan> balloons, sure
[17:36] <elopio> balloons: but jenkins is not having your same error, it's a timeout.
[17:36] <balloons> senan, either or. it probably makes sense to add these tests to test_calendar.py
[17:37] <senan> balloons, I've opened the calender.qml
[17:37] <balloons> senan, also open test_calendar.py if you don't have it open
[17:37] <senan> balloons, already open :)
[17:37] <balloons> look at the test_new_event in test_calendar.py.. Do you see         self.main_view.open_toolbar().click_button("todaybutton")?
[17:38] <balloons> I wanted to show you how objectNames work
[17:38] <senan> balloons, yes
[17:38] <balloons> inside the qml file you can assign a unique name to an object. Then we can call it during our test
[17:38] <balloons> so inside calendar.qml, look for objectName: "todaybutton"
[17:39] <balloons> you will see inside the qml a toolbar is defined, and 2 buttons are defined. A neweventbutton and a today button
[17:39] <balloons> we've given them unique objectNames so we can push them in our test
[17:39] <balloons> you can assign an objectName to any object you need
[17:41] <senan> balloons, is this done by the developer or the tester ?
[17:42] <balloons> senan, I cover this stuff in this video, which is quite long, but worth watching if you want a full explanation and walk-through of writing a core app test: https://www.youtube.com/watch?v=qD_e_xqlBbg
[17:42] <balloons> senan, it doesn't use the emulator which makes it easier, but thought I'd mention it
[17:43] <balloons> senan, adding the objectname's would be done by you as the test writer
[17:43] <senan> balloons, ok
[17:43] <balloons> it could also be done by the developer, doesn't matter who sets the name as long as it is set to be unique
[17:43] <balloons> by default, it's given a random name which is not useful to us at runtime
[17:44] <senan> balloons, got some idea now
[17:44] <senan> balloons, do we have any manual test case for this ?
[17:45] <balloons> excellent. So, to write the tests, you will fire up the app and look at the internals with autopilot vis. Figure out what objects you want to interact with, add objectnames to them if needed, then write the action steps and asserts
[17:45] <balloons> senan, no manual test cases for these apps
[17:45] <balloons> nothing written down
[17:45] <senan> balloons, ok..no problem
[17:46] <senan> balloons, I think this time it will not reach 85 revisions :P
[17:47] <balloons> senan, I think you are well prepared this time!
[17:47] <senan> balloons, Don't know actually :)
[17:47] <balloons> do feel free to come and ping with any questions you encounter along the way
[17:47] <balloons> overall I think it will be easier
[17:47] <balloons> good luck and thanks!
[17:48] <senan> balloons, I'm sure I'll be having a hand full of question tomorrow :)
[17:48] <balloons> yep, I
[17:48] <balloons> m sure you will
[18:26] <elfy> balloons: I love how my lot knew about the trackers days ago \o/
[18:27] <balloons> elfy, they've already posted results :-)
[18:27] <elfy> The X in Xubuntu is pronounced Super :D
[18:28] <elfy> balloons: don't know if you saw but I streamlined our packages
[18:30] <elfy> balloons: shame you can't set the order of testsuites in products on the package tracker though
[18:31] <balloons> elfy, mm..
[18:31] <knome> wonder when stgraber will pull my latest fixes to production and updates the visual look with things that have been stuck in his queue for ages...
[18:31]  * balloons gently nudges stgraber
[18:32] <balloons> knome, where is the mp at?
[18:33] <knome> "the mp"? the code is in trunk...
[18:33] <knome> the other things were something i proposed and he said he'd take care, no idea where that code is :)
[18:33] <knome> you remember the visual changes loooong time ago?
[18:33] <balloons> knome, ohh.. so it's merely pushing the updates to the site
[18:34] <knome> yep.
[18:34] <knome> would be easier to get on with new things if we got these landed
[18:34] <balloons> elfy, so afaik you can order everything, so look again
[18:34] <balloons> there is weight given to everything
[18:35] <elfy> nowwhere to weight on the add testuites to products page
[18:35] <elfy> I looked for that ;)
[18:36] <elfy> you can weight testcases within testsuites
[18:37] <balloons> elfy, yep you sure can
[18:37] <balloons> elfy, see http://packages.qa.ubuntu.com/admin/config/services/qatracker/testsuites/374/edit
[18:38] <elfy> balloons: that is weighting a testCASE in a testSUITE
[18:38] <elfy> I want to weight testsuites in a product :)
[18:38] <elfy> http://packages.qa.ubuntu.com/admin/config/services/qatracker/products/335/testsuites
[18:38] <balloons> elfy, ahh I get it now
[18:38] <elfy> all you can do there is add a testsuite to a series :)
[18:38] <balloons> yep
[18:38] <knome> balloons, ergh, http://packages.qa.ubuntu.com/admin/config/services/qatracker/products
[18:39] <knome> balloons, says xubuntu desktop owner is ubuntu touch release
[18:39] <knome> balloons, i edited that and changed it to xubuntu release
[18:39] <knome> balloons, the edit page is ok
[18:39] <balloons> right, but on the main page it's wrong
[18:39] <knome> balloons, but that page still says ubuntu touch release...
[18:39] <knome> maybe some heavy caching?
[18:40] <elfy> ok
[18:40] <balloons> knome, lol, check it out.. it's backwards
[18:40] <balloons> something is wrong in the db
[18:40] <elfy> so whoever did what they did I've not got access to it now :p
[18:40] <knome> lol
[18:40] <balloons> set it to ubuntu-touch release and it shows xubuntu
[18:40] <balloons> so it's clearly a display thing I guess
[18:40] <knome> no, now the edit page says ubuntu touch.
[18:40] <balloons> elfy, I restored it :-)
[18:41] <elfy> :p
[18:41] <knome> oh
[18:41] <knome> crap
[18:41] <balloons> knome, right.. if edit says ubuntu-touch, products page says xubuntu
[18:41] <knome> let me go re-restore
[18:41] <balloons> and vice versa
[18:41] <balloons> it's good now
[18:41]  * knome facepalms
[18:43] <elopio> alesage, popey: for when you have some time, I'd appreaciate a review: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/datepicker-autopilot_helper/+merge/218588
[18:45] <elfy> balloons: bug 1317231
[18:46] <knome> i lost count how many bugs i've filed after trusty release
[18:46] <knome> i know i've filed 16 against one single application
[18:46] <alesage> elopio I'll have a look in a bit
[18:47] <elfy> balloons: I hope I worded that so it makes sense :D
[18:51]  * balloons looks
[18:59] <elfy> too wordy then :p
[20:07] <jpd1> Hello ; I have been lurking in the ubuntu-qa email list ; I am interested in all things related to powerpc ;
[20:08] <balloons> howdy jpd1
[20:08] <jpd1> howdy back .. from texas !
[20:09] <balloons> nice! so you like powerpc eh? you have a powerpc desktop?
[20:13] <jpd1> yes - we have a freescale p4080 -e500mc server  platform ; ppc ;
[20:17] <balloons> interesting.. what do you use it for primarily?
[20:25] <jpd1> we manufacturing them : http://www.servergy.com/ ; I am part of the dev team doing  bring up roll out;
[20:27] <jpd1> You are Nick ; from the email ; what time is in Europe ?
[20:30] <elfy> in this bit of Europe it is 21:30 - other bit's it's an hour or so ahead
[20:32] <balloons> jpd1, ohh.. heh, hence the reason you enjoy ppc ;-)
[20:32] <balloons> cool
[20:32] <balloons> umm, where I am it's 1630
[20:33] <elfy> not Europe ...
[20:33] <balloons> yep, that puts me squarely in not Europe
[20:33] <jpd1> east of NYC
[20:34] <balloons> jpd1, indeed I am Nicholas.
[20:34] <jpd1> 1530 here
[20:37] <elfy> that's definitely the wrong time ... UTC or GMT or BST is the right time :p
[20:37] <balloons> so jpd1 what interests you as far as quality goes?
[20:37] <balloons> apart from all things ppc ;-)
[20:39] <jpd1> missing little pieces all you x86 people enjoy ;-) ; install issues; misc  tools;
[20:43] <balloons> I think we have but one testcase specific for ppc
[20:47] <jpd1> your tool :  hardinfo ; thinks I am on a Intel box l
[20:48] <alesage> elopio where would I find Ubuntu.Components needed for this date picker test?
[20:49] <elopio> alesage: in order to run the tests
[20:49] <elopio> qmake
[20:49] <elopio> make
[20:49] <alesage> elopio o ok got it
[20:50] <elopio> source source export_modules_dir.sh
[20:50] <elopio> cd tests/autopilot
[20:50] <elopio> autopilot3 run ...
[20:50] <alesage> elopio, thx
[20:51] <balloons> jpd1, ohh really? that's actually just a tool used, not something we maintain. https://github.com/lpereira/hardinfo
[20:52] <balloons> what does it report for cpu? is the kernel lying?
[21:10] <jpd1> It certainly doesn't report ppc p4080-e500mc :
[21:10] <jpd1> -CPU Blowfish-
This Machine</b></big>  1500 MHz        45.847
[21:10] <jpd1> Intel(R) Celeron(R) M processor         1.50GHz (null)  26.1876862
[21:10] <jpd1> PowerPC 740/750 (280.00MHz)     (null)  172.816713
[21:21] <jpd1> QEMU suffers all the same dis-information too ;
[21:41] <balloons> jpd1, what does /proc/cpuinfo say?
[21:41] <balloons> I'm curious if it's incorrect or not
[22:17] <jpd1>  processor       : 0
[22:17] <jpd1> cpu             : e500mc
[22:17] <jpd1> clock           : 1200.000000MHz
[22:17] <jpd1> revision        : 2.0 (pvr 8023 0020)
[22:17] <jpd1> bogomips        : 75.00
[22:18] <knome> does the script think [0-9]m means pentium M? :P
[22:19] <jpd1> who would ever run Linux on something  other than i386  ! ;-)
[22:23] <knome> 5 years ago people looked like you were nuts if you ran amd64.
[22:23] <jpd1> my intel white box : processor       : 0
[22:23] <jpd1> vendor_id       : AuthenticAMD
[22:23] <jpd1> cpu family      : 18
[22:23] <jpd1> model           : 1
[22:23] <jpd1> model name      : AMD A6-3500 APU with Radeon(tm) HD Graphics
[22:23] <jpd1> stepping        : 0
[22:23] <jpd1> cpu MHz         : 800.000
[22:24] <jpd1> who would ever need more  that 640k memory and TWO  5.25 floppies ;
[22:25] <jpd1> **than
[22:25] <knome> two? insane...
[22:26] <jpd1> DOUBLE SIDED yet !
[22:26] <knome> huhu
[22:28] <jpd1> I started out WITH PUNCH cards ;;; Fortran ;
[22:28] <knome> heh
[22:28] <knome> i remember us having a 2.88M (!) diskette drive
[22:28] <knome> i can't remember us actually taking advantage of it
[22:29] <knome> the 2.88M diskettes must have cost like 100 finnish marks
[22:29] <knome> and i think 10box of regular ones was somewhere around 50...
[22:29] <knome> but that's completely out of memory
[22:30] <knome> i might be totally wrong
[22:30] <knome> but the prices *were* laughable
[22:30] <knome> then came the CD's