#ubuntu-quality 2013-11-25
<jibel> Good morning
<elfy> hi jibel
<jibel> Hey elfy
<jibel> pitti, FYI I fixed jenkins publisher for new jobs. Jenkins has been upgraded from 1.424 to 1.480 during the move to 1SS and configuration of matrix jobs are incompatible
<pitti> jibel: ah, thanks; i. e. new tests didn't appear in jenkins.q.u.c.?
<jibel> pitti, yes
<DanChapman> good morning :-)
<davmor2> Morning all
<DanChapman> jibel, good morning :-) it seems the failing tests where ubiquity closes before the test finishes are failing for the same reason http://paste.ubuntu.com/6473351/.
<pitti> jibel: oops @ http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-autopkgtest/9/ARCH=i386,label=adt/console
<pitti> jibel: I indeed dropped --paths-{host,testbed}, I'll adjust our scripts
<pitti> jibel: whoops, I didn't actually mean to commit yet before your review, but I can always uncommit/overwrite: http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/revision/260
<pitti> jibel: I also renamed --tmp-dir to --output-dir and cleaned up garbage in there; but I kept --tmp-dir as a backwards compat alias
<pitti> jibel: I guess we still want these scripts to run on saucy and older, so let's keep --tmp-dir for a while
<pitti> jibel: if you are happy with this, would you mind rolling this out?
<pitti> jibel: there are other changes in trunk which haven't been rolled out yet, are you happy with them?
<jibel> DanChapman, so ubiquity crashed, this error usually means something went wrong earlier
<jibel> DanChapman, did you try manually?
<jibel> to confirm the crash
<jibel> pitti, looks good. I think we can keep tmp-dir until trusty is out. we'll move all LTS tests to this release then.
<DanChapman> jibel, I'm just running manually now, i had already tried it then realised I was using an older image :-D
<jibel> DanChapman, something crash right before the stack trace /var/local/autopilot//logs//autopilot.log: Segmentation fault (core dumped)
<jibel> argh, the crash file has no useful inforamtion to allow retracing, I'll fix that
<DanChapman> jibel, I can confirm it happens for noneng_encrypt_lvm on ubuntugnome ubiquity just completly dies out.
<jibel> DanChapman, yes python segfaulted
<DanChapman> jibel i presumed the seg fault was autopilot looking for a object memory address which was no longer there :-S
<DanChapman> jibel ahh ok
<jibel> DanChapman, the command that crashes is /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity --autopilot
<jibel> DanChapman, if you can reproduce in a VM, run ubutnu-bug /var/crash/<crash_file>.crash and report it to launchpad where is will be retraced
<jibel> ubuntu-bug
<DanChapman> jibel ok cool will do that
<jibel> DanChapman, might be a bug in autopilot though: Nov 25 08:03:08 ubuntu kernel: [  175.333778] ubiquity[5889]: segfault at 0 ip b713e158 sp bf979240 error 4 in libautopilot.so[b7136000+10000]
<pitti> jibel: thanks; so ok to roll this out?
<jibel> pitti, it's done, forgot to mention it.
<pitti> jibel: ah, merci
 * pitti retries the failed tests then
<pitti> err, if d-jenkins would play along, that is
<pitti> ok, done
<elopio> good morning!
<DanChapman> good morning elopio
<balloons> good morning :-)
<DanChapman> morning balloons o/
<DanChapman> jibel, what logfiles would ubuntu-bug usually send? i'm having issues with ubuntu-bug either the UI is freezing up after the ubiquity error so it won't load, and trying ubuntu-bug from TTY doesn't want to send anything, so looks like manual route
<xnox> DanChapman: if there is a /var/crash/ubiquity*.crash file just copy that & attach to a bug report.
<xnox> DanChapman: plus /var/log/installer/*; /var/log/syslog; /var/log/partman
<DanChapman> xnox, ok thanks :-)
<jibel> xnox, all the artifacts are there https://jenkins.qa.ubuntu.com/job/ubiquity_ap-ubuntu_devel_daily-test_english_default/ARCH=i386,label=rabisu/16/ but crash file is useless if apport has not reprocessed it first
<xnox> jibel: it's python, so it should have a traceback in plain Python.
<xnox> =))))
<xnox> jibel: one can unpack/view the crash file binary with apport-cli.
<jibel> xnox, actually python segfaulted
<jibel> and the crash file only have a core file attached
<xnox> =(((((
<slickymaster> hi all
<balloons> hi slickymaster
<slickymaster> hi, balloons
<slickymaster> hop everything is fine with you
<slickymaster> hope ^^
<balloons> slickymaster, yes, everything is going quite well. Lots of post-uds work to get started on, but it was a good week last week
<balloons> and some turkey and thanksgiving to be had yet this week .. Not bad :-0
<slickymaster> yeah, it's true. Holiday's season is at your front door, that side of the atlantic :)
<elfy> slickymaster: I found you :p
<slickymaster> hi, elfy
<slickymaster> I'm not that hard to find, either here or on #xub-dev
<elfy> you about for a while - want to talk to you about something, but I've just got in from work
<elfy> yea I know :)
<slickymaster> elfy: at your disposal
<elfy> ok :)
<slickymaster> elfy, I'll be around until 17:30 UTC, after that I'll have to take my son to his tennis lesson
<elfy> slickymaster: PM window somewhere
<slickymaster> elfy: I saw it, but I'm unable to write anything in there
<knome> hey slickymaster :)
<slickymaster> hi, knome
<knome> slickymaster, congrats ;)
<slickymaster> knome: thanks
<elfy> hi knome
<slickymaster> it's a pleasure to be of help
<elfy> it's a pleasure to have someone wanting to help ;)
<Ursinha> so, I'm trying to find a way to avoid regression bugs that affect ubuntu touch packages to be missed when evaluating an image
<Ursinha> my idea was to create a team in launchpad and subscribe it to all packages that are seeded for ubuntu touch
<Ursinha> didrocks (that's not here) said it could be useful for you guys as well
<balloons> Ursinha, interesting
<Ursinha> balloons, that would give us a list like this one: https://bugs.launchpad.net/~dx-packages/+packagebugs
<balloons> Ursinha, right. And that would be helpful to see what's happening at a glance. I wonder if there is an existing team you can use/reuse
<Ursinha> balloons, for the other teams I created a team called <team>-packages, because some of them use the subscription to packages to something else
<jibel> Ursinha, that'd be useful for our reporting too. For example during exploratory testing sessions we'd want to create report on the bugs found by the QA team agaisnt Touch packages
<jibel> we tried to figure out that list from the umbrella project ubuntu-touch-preview
<jibel> but with little success
<Ursinha> jibel, good. would it be accurate to include all packages that are seeded in touch image?
<jibel> Ursinha, I think it would be a good start. maybe too much accurate, but we could always exclude some packages if they generate too much noise
<Ursinha> jibel, all right
<balloons> DanChapman, btw, did you see this? http://www.piware.de/2013/11/whats-the-autopilot-widget-that-i-want/
<elfy> hi balloons
<balloons> hi elfy!
<DanChapman> balloons, I did indeed :-) will definately be helpful in places
<elfy> what was the 'bug' mailing list it would be useful to join?
<elfy> hi DanChapman - thanks for the time the other day
<DanChapman> elfy your welcome :-)
<elfy> balloons: was it the bugsquad m/l that wasn't high volume and perhaps useful to watch ?
<balloons> elfy, might have been.
<balloons> ubuntu-bugs
<elfy> that's high volume
<elfy> must have been the other one - really should listen to them properly ...
<dkessel> good evening
<Noskcaj> hey dk
<Noskcaj> dkessel,
<dkessel> hey Noskcaj, thanks for putting me in the lubuntu group
<Noskcaj> no problem
<dkessel> oops I forgot to send the email though... :)
<dkessel> done...
<dkessel> guys... pyside or pyqt for a typical ubuntu application?
<Noskcaj> dkessel, it probably depends on what you want. many still use pygobject and pygi
<dkessel> Noskcaj, but that's only for gnome stuff, right? I am asking for the "standard" framework for qt with python
<Noskcaj> dkessel, yeah. since you want Qt, i'm no help sorry
<Noskcaj> maybe ask ubuntu-devel or ubuntu-app-devel
<dkessel> yeah... waiting for life there
<dkessel> Noskcaj, do you have any idea why testdrive freezes so many times (on trusty) yet?
<dkessel> testdrive-gtk, that is
<Noskcaj> dkessel, no, although there has always been a startup freeze
<Noskcaj> I'd like to do the pygi port first, since that might "magically" fix it
<dkessel> yeah, possible
<balloons> dkessel, ahh python + qt.. honestly I suppose I haven't kept up enough. At one time it was pyqt
<balloons> Letozaf_, how are you?
<Letozaf_> balloons, Hi, I'm fine and you ?
<balloons> good ;-) turkey day is coming soon here
<Letozaf_> balloons, ah! Thanksgiving (hope I wrote it right)
<Letozaf_> balloons, you're gonna eat a lot :)
<balloons> you wrote it correctly. And yes, traditionally it is time to pig out. I'll try not to eat too much
<Letozaf_> balloons, well once every now and them does no harm!
<Letozaf_> sorry then
<balloons> Letozaf_, so what's the status of rssreader atm?
<Letozaf_> balloons, you can pig out without worrying  :D
<balloons> haha, you still feel queasy afterwards!
<Letozaf_> balloons, same as before, I was writing a test for music app now
<balloons> Letozaf_, yes I'm sure it's the same. I just don't remember :-) I'm re-running on the device to jog my memory
<Letozaf_> balloons, I think it still has that tabs problem
<Letozaf_> balloons, we wern't able to switch tabs
<balloons> ahh, right!
<Letozaf_> balloons, I don't think I saw the problem solved yet, or am I wrong ?
<Letozaf_> balloons, and then there was the activity indicator problem too
<balloons> Letozaf_, well I'll see what it looks like in another minute. But yes, thank you for the reminder
<Letozaf_> balloons, by the way what image do you run the tests on on your device ?
<balloons> I figured you would know..
<balloons> Letozaf_, always the latest proposed
<balloons> Letozaf_, 2 failures, both on the toolbar animating, nice memory :-)
<Letozaf_> balloons, ah! went away for a couple of days and forgot everythig :P
<balloons> pretty much. UDS does that to you
<balloons> well that and the weekend
<balloons> I've been really out of my mind recently.. but that's a sidenote
<Letozaf_> balloons, yes suppose so
<Letozaf_> balloons, not the out of the mind, I mean that UDS and week end
<Letozaf_> balloons, does that to you :P
<dkessel> night
<Letozaf_> night I'm going to bed too :D
#ubuntu-quality 2013-11-26
<BullFrog13x4> exit
<jibel> Good morning
<jibel> pitti, unattended-upgrades and ubunut-release-upgrader autopkgtests failed with a permission denied. It could be a change in autopkgtest 2.5, did you have a look?
<pitti> jibel: not yet, but I will
<pitti> still digging through morning IRC/email
<pitti> jibel: oh, just saw that you became a member, congratulations! well deserved
<jibel> pitti, Yay, thanks for your support :)
<pitti> jibel: no immediate idea, I'll reproduce locally and investigate
<jibel> pitti, that's a change in 2.5, -build directory is own by root instead of the test user
<jibel> for exmaple
<jibel> adtlog.2.4.log:143092    8 -rw-r--r--   1 ubuntu   ubuntu       4401 Sep  9 17:39 /tmp/adt-run.N9WStu/ubtree0-build/real-tree/test/.coverage
<ubot5> Ubuntu bug 4401 in wing (Ubuntu) "wing: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/4401
<jibel> adtlog.2.5.log:144002    8 -rw-r--r--   1 root     root         4401 Sep  9 17:39 /tmp/adt-run.qDeeZc/ubtree0-build/real-tree/test/.coverage
<pitti> jibel: right, will track down
<DanChapman> good morning ! :-)
<elfy> morning DanChapman
<DanChapman> howdy elfy o/
<jibel> DanChapman, good morning
<DanChapman> jibel, good morning :-)
<DanChapman> how are you?
<jibel> DanChapman, re. ubiquity crash, I filed bug 1254996 which contains a better crash file but retracing will probably fail
<ubot5> bug 1254996 in autopilot (Ubuntu) "ubiquity crashed with SIGSEGV in GtkNode::MatchStringProperty()" [Critical,Confirmed] https://launchpad.net/bugs/1254996
<jibel> DanChapman, I'm fine, how are you
<jibel> ?
<jibel> DanChapman, I'll generate another crash file with latest updates applied
<DanChapman> jibel, i'm good thanks :-) awesome thanks, I was struggling to get any logs yesterday. So it turns out its an autopilot bug? should autopilot-gtk be linked to that bug aswell?
<jibel> DanChapman, autopilot or a change in gtk, there has been an upload 4 days ago
<jibel> DanChapman, ah it's fine, we have a good trace
<jibel> DanChapman, to generate a crash file on a system from CLI when Desktop is not responding for example, you can run apport-cli <path_to_crash> ;type (V)iew then (K)eep and copy the crash file to another system. Finally from this other system run ubuntu-bug <path to crash>
<pitti> jibel: dbus-test-runner: same problem (before you check)
<pitti> jibel: still investigating; tricky bug, I didn't actually change any chown or copy steps, that must have been another unobvious side effect
<DanChapman> jibel, ahh I see I was trying to (S)end it instead. I'll remember that thanks :-)
<pitti> jibel: ah, got it; the bug was there all the time, just shadowed in the case of how we call adt-run; yay AutoFile magic..
<jibel> pitti, what is it?
<pitti> jibel: it didn't chown the test tree when copying down when using --user
<pitti> jibel: that happens to work with the null runner and AutoFile, as that remembered it already copied down the tree
<pitti> but it would have never worked with schroot/lxc runners
<jibel> pitti, nice catch. Good thing you removed the magic :)
<pitti> jibel: 2.5.1 uploaded to sid and trusty
<pitti> I'll retry the tests once it's published in proposed
<jibel> pitti, thanks
<pitti> (it also has a test now)
<jibel> pitti, do you think you'd have time to look at bug 1254996
<jibel> ?
<ubot5> bug 1254996 in autopilot (Ubuntu) "ubiquity crashed with SIGSEGV in GtkNode::MatchStringProperty()" [Critical,Confirmed] https://launchpad.net/bugs/1254996
<pitti> jibel: will do
<pitti> jibel: oh, run-ubiquity-test does everything necessary to boot the iso in KVM etc.?
<jibel> pitti, it does
<jibel> you just need an iso and it'll run the default english installation
<pitti> jibel: can I run this inside KVM, to be able to test with a fixed libautopilot-gtk?
<jibel> pitti, I didn't try that
<pitti> jibel: ok, let me look at the trace first
<jibel> pitti, but you could hack autopilot/ubiquity-autopilot-runner/custom-installation/iso-override/usr/local/bin/run-autopilot.sh to install it
<jibel> and put deb somewhere in the custom-installation directory
<jibel> custom-installation/iso-override even
<pitti> jibel: is the entire iso-override/ copied to the VM?
<jibel> pitti, yes
<pitti> jibel: then I could just put the .so in the right place
<jibel> pitti, exactly
<pitti> jibel: is that copied after installing autopilot and friends?
<jibel> pitti, ah no, autopilot would be installed afterwards
<jibel> and overwrite it
<pitti> ok, .deb then
<jibel> or copy the .so somewhere in the override and in run-autopilot copy it over the version installed by autopilot
<pitti> (this=0x37e9218, name=..., value=...)
<pitti> thanks gdb for precisely showing me what I actually want to know!
<jibel> heh, I thanked it for tat too :)
<jibel> +h
<pitti> jibel: btw, I started working on an adt-virt-qemu as a side project
<jibel> pitti, did you talked to rbasak, because he intended to work on it too?
<pitti> jibel: with that we can support proper "breaks-testbed" tests, and don't need to install/wait for autopkgtest inside the VM, and simplify run-adt-test
<pitti> jibel: I will; so far it's just initial investigations to learn how to write one
<pitti> rbasak: ^ FYI
<rbasak> pitti: I have a tool that wraps libvirt and simplestreams that is most of it. uvtool, in universe, that provides a command called uvt-kvm.
<pitti> jibel: I'm shamelessly stealing from run-adt-test, of course
<pitti> rbasak: ah, I'm trying to write that in a way to be useful for Debian
<rbasak> pitti: it lets you start a COW instance from a cloud image.
<jibel> pitti, I was wondering if libvirt wouldn't be a better option than pure qemu, because it'd be easier to start VMs with a specific definition
<rbasak> pitti: it only really *requires* libvirt and cloud-init. Debian has both of those, right?
<jibel> and there are python bindings for libvirt to may make things easier to glue with autopkgtest
<pitti> jibel: yeah, probably; so far I really just invested an hour or so in it, to figure out how to build proper auxverb/shstring commands
<rbasak> pitti: you could in theory have an outside script construct a Debian image qcow image that uses cloud-init, and then have uvtool use that.
<jibel> rbasak, they have both, but Debian doesn't have pre-built cloud images, do they?
<jibel> so you'd need to debootstrap a debian image and prepare it to boot with cloud-init
<rbasak> jibel: nope. But you could construct them locally.
<rbasak> jibel: right.
<jibel> rbasak, and that's the bug part of the works :)
<jibel> big
<rbasak> It's not that hard, is it?
<rbasak> deboostrap, chroot and install cloud-init. That should be it I think.
<rbasak> I've not tried, though.
<jibel> it is not hard, but it takes a lot of time because there are always tons of details to fix
<pitti> it seems the minimal assumption so far is that the VM needs sshd running, a specified user, and an ssh key
<pitti> but that shouldn't be different with libvirt
<rbasak> OK. uvtool does require cloud-init.
<jibel> then you must configure cloud-init to use a nocloud provider, configure the bootloader, prepare networking, default user, access policy, keys, ....
<rbasak> I don't intend to change that. cloud-init is useful, which is why we have it, and so I don't want to have to continuously work around that usefulness because I want native compatibility with Debian.
<pitti> adt-virt-qemu (or -libvirt) wouldn't *build* an image, that needs to be a separate script (like prepare-testbed)
<pitti> rbasak: oh, I think it's great for constructing base images
<pitti> I just want to provide an ADT runner which doesn't work in the "inside out" fashion that run-adt-test is these days
<pitti> if adt-run controls the VM from outside, we can revert, track state between tests, and even do reboots
<pitti> (hello jodh :) )
<jibel> rbasak, I'm investigating options to replace vmbuilder for auto-upgrade-testing, is uvtool stable enough in saucy to replace it?
<pitti> and it shouldn't be that hard to write, given that we already figured out all the details with run-adt-test
<pitti> rbasak: so uvtool is a tool for the VM construction side, not for communicating with it, right?
<pitti> rbasak: the latter would be libvirt
<rbasak> pitti: yes, more or less. It helps with construction and destruction, as a wrapper around libvirt, cloud-init userdata and handling volume imports from published Ubuntu images automatically.
<pitti> jibel: anyway, this was mostly triggered by looking at run-ubiquity-test
<pitti> rbasak: cool, thanks for pointing out; I wasn't aware of it
<rbasak> pitti: so you just describe on the CLI what you want (eg. --run-script-once my_startup_script.sh --ssh-public-key-file some/other/id_rsa.pub)
<rbasak> also things like --disk ... and --bridge br0
<rbasak> Some of those options end up in the libvirt domain definition; some get stuffed into cloud-init userdata.
<rbasak> I also want to add things like --enable-proposed and --install-packages
<rbasak> (relatively trivial to do things now with the structure I have; so far I add options on request quite quickly)
<rbasak> pitti: it seems to be mostly bug free. https://bugs.launchpad.net/uvtool/+bug/1251296 is the biggest one right now and I have a fix almost ready for it.
<ubot5> Ubuntu bug 1251296 in uvtool "stat error messages during sync" [High,New]
<rbasak> I meant jibel: it seems to be mostly bug free. https://bugs.launchpad.net/uvtool/+bug/1251296 is the biggest one right now and I have a fix almost ready for it.
<rbasak> jibel: the API seems reasonably stable now, too. I still want to be able to change something without locking myself in to something forever, but I think it'll be easy to change consumers in the archive as required.
<rbasak> One issue is that the postinst expects libvirtd to be running and not be broken. Some people not testing in clean environments have hit that.
<pitti> jibel: ok, test fun finished; it immediately shut down the VM, I didn't see whether or not it finished
<pitti> jibel: /tmp/ubiquity.tests/results/var/crash/ is empty
<pitti> /tmp/ubiquity.tests/results/console == http://paste.ubuntu.com/6478372/
<pitti> jibel: where can I see the crash?
<jibel> pitti, you can use the file config/testrunner.cfg as example and disable shutdown
<jibel> when it crashes there is a crash file in /var/crash
<pitti> jibel: ah, so it doesn't always crash
<pitti> the stack trace is ath the final } of the function
<pitti> so I guess, some automatic C++ deallocation; I'll stare at the code for a bit
<DanChapman> pitti the odd test still passes more are failing than passing on jenkins atm
<jibel> apparently not, for example https://jenkins.qa.ubuntu.com/job/ubiquity_ap-ubuntu_devel_daily-test_english_default/
<jibel> crashed on i386 but pass on amd64
<pitti> ah, I tried on amd64
<pitti> jibel: adt-run happy again, *phew*; sorry for the mess
<jibel> pitti, thanks for fixing it :)
<pitti> jibel: I have a hypothesis what could happen, now I need to be able to reproduce
<pitti> DanChapman, jibel: roughly when do you see the crash? i. e. at which page in ubiquity? or does it happen at different places?
<jibel> pitti, I could reliably reproduce this morning with the image on my machine, if you have a .so I can test it
<DanChapman> pitti it is always on the transition to the slideshow/progress bar page
<pitti> ah, I'm past that in my third run
<DanChapman> Depending on flavor thats either coming from userinfo or U1 page
<DanChapman> ah ok... the worst scenario i tested yesterday was ubuntu-gnome, using the test_nonenglish_encrypt_lvm test
<DanChapman> pitti ^^ it was a guaranteed crash yesterday
 * DanChapman tries today
<jibel> pitti, on Ubuntu Desktop amd64, it crashed when the slideshow started
<pitti> jibel: http://people.canonical.com/~pitti/tmp/libautopilot.so goes into /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libautopilot.so
<pitti> jibel: that's trusty, right? (I tried on current trusty daily)
<pitti> sorry, third run just finished successfully (with unpatched ap-gtk)
<jibel> pitti, Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20131125)
<pitti> I can't claim that I understand the crash, but this change is the only potential hiccup that I can imagine
<pitti> jibel: ah, I have 26 here
<pitti> jibel: let me get 25
 * pitti feeds the rsync hamsters
<jibel> pitti, running with image 25 and your patched lib
<pitti> jibel: runnning 25 unpatched here now
<jibel> slideshow running and installation in progress
<jibel> run #1: pass
<pitti> jibel: can reproduce with 25 indeed
<pitti> weird that it doesn't happen with 26
<pitti> jibel: you installed the library how?
<pitti> jibel: if it's any easier, I can build a .deb with a higher version
<jibel> pitti, http://paste.ubuntu.com/6478537/
<jibel> and put the lib into autopilot/ubiquity-autopilot-runner/custom-installation/iso-override/usr/local/bin/
<pitti> aah, nice
<jibel> it was not really the purpose of the tool :)
<pitti> jibel: ok, running while I grab some lunch
<jibel> pitti, enjoy your lunch
<jibel> there are several unity-gtk updates in 26 maybe that's the difference
<pitti> it's a totally dubious crash anyway
<pitti> I googled for the C++ std:string semantics, and assigning a char* does copy the string
<pitti> there's nothing obviously wrong with the code
<pitti> but I dropped std:string now and replaced it with good old g_strcmp()
<pitti> as the function is half C and half C++, maybe that confuses something
<pitti> jibel: my first run passed, starting a second now
<DanChapman> pitti, \o/
<pitti> DanChapman: jibel also had a successful run with it; I guess we both do three runs each, and if they all succeed we declare it fixed
<DanChapman> pitti ok using image 25??
<pitti> DanChapman: yes, as it doesn't seem to crash with 26
<pitti> (I tried three times0
<pitti> )
<DanChapman> pitti, ack
<jibel> pitti, 3 successful run with 25 and your patch
<pitti> third one almost done
<DanChapman> pitti, first 2 successful 3rd just starting
<pitti> DanChapman: ah, you try image 1125 with my lib, too?
<DanChapman> pitti indeed :-)
<pitti> jibel, DanChapman: 3/3 success on 1125 with my patch
<jibel> pitti, excellent. So I'll guess this is a message to rewrite unity in good old glib style
<jibel> ;)
<pitti> heh
<pitti> https://code.launchpad.net/~pitti/autopilot-gtk/fix-1254996/+merge/196703
 * pitti now submits to the verdict of Jenkins
<pitti> DanChapman: so, I hope we'll land that by tomorrow; but I hope you are unblocked now as it doesn't seem to crash on 26?
<DanChapman> pitti, great thanks, I think the issue is still there with 26 https://jenkins.qa.ubuntu.com/view/All/job/ubiquity_ap-xubuntu_devel_daily-test_nonenglish_default/ which I will test that locally in a min patched and unpatched. But the patch unblocks me locally anyway. Thanks
<pitti> DanChapman: ah, so maybe I was just lucky three times
<DanChapman> pitti, I think you was, I had 5 clear successes in a row with 25 yesterday then not a single one after that :-D
<pitti> Computers are reliable, software is reproducible, and the earth is flat
<jibel> balloons, DanChapman finally https://jenkins.qa.ubuntu.com/view/Ubiquity/
<xnox> pitti: pick any two? =)
<jibel> there are unnecessary jobs that will be removed from the public instance
<pitti> xnox: oh, I pick stracciatella and pistachio then!
<xnox> sprinkles and cream? I guess i was thinking "Software Development - on time, on budget, to spec; pick any two"
<pitti> heh
<pitti> xnox: s/software//
<pitti> it's not like buildings or planes or trains would be any different :)
<xnox> refactoring skillz++
<pitti> although certain Berlin airports managed to violate all three :)
<xnox> well in London, the first crossrail proposal was made in 1941, approved in 2004, reapproved with larger budget and longer timelines in 2005, now they are actually reducing scope, delayed and raising additional funding.
<xnox> so it's best and worst =) of all projects =)
<DanChapman> jibel awesome! that makes checking results easier :-) Just incase you hadn't noticed Lubuntu tests aren't running yet ;-p
<jibel> DanChapman, yes, I just realized that, checking
<jibel> DanChapman, actually they fail because apt cache is locked when it tries to install additional packages
<jibel> E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable) in run.log
<jibel> I'll verify this condition and retry a few times to make it more robust
<jibel> we should probably protect the test against the fatal hash sum mismatch error
<jibel> DanChapman, I think it is because it starts simultaneously with update-notifier which checks if a new release is available
<jodh> pitti: a delayed "hi" :)
<pitti> rbasak, jibel: do you happen to know how to add some files to a qemu image without root?
<pitti> rbasak, jibel: qemu-nbd works as non-root if you have it listen to a port instead of connecting to /dev/nbd*, but are there some clients for that which you know of?
<jibel> pitti, kpartx needs root. Did you try libguestfs?
<jibel> I don't know about nbd clients
<pitti> jibel: kpartx only works with raw images, though, not with qcow?
<jibel> pitti, that's right
<pitti> jibel: I didn't try libguestfs
<elopio> good morning good quality people.
<pitti> hey elopio
<jibel> Hi elopio
<jibel> pitti, nbd-client would be an nbd client? :)
<jibel> I never tried nbd
<pitti> jibel: yes, but debconf/root/etc.
<jibel> ah
<pitti> jibel: it seems to be the only way to access a qemu image
<jibel> other than an hexadecimal editor
<pitti> jibel: I'd prefer planting a shell on /dev/ttyS1 over assuming that the VM always has a running network and ssh (as you may want to fiddle with the latter in tests)
<pitti> also, it would be nice to drop teh requirements of "need to know an user name", "need to have an SSH key", etc.
<pitti> n
<jibel> pitti, agreed, and it also has the benefit to provide greater control over the testing environment
<rbasak> pitti: I like the serial idea.
<pitti> jibel: can you do two overlays?
<pitti> jibel: i. e. <ro base image> <one overlay with the autopkgtest hacks> <the r/w temp overlay>
<jibel> pitti, yes, that's what we do with otto
<rbasak> I don't like libguestfs. It basically uses KVM to start a VM as non-root. Feels like a sledgehammer on a nail. But I don't know of any other solution.
<pitti> ther's qemu-img convert; I can create a raw image as user relatively easily
<pitti> rbasak: yes, and it's rather heavy
<pitti> jibel: cool, I'll try that then
 * pitti is in a hacking mood this afternoon
 * rbasak thinks about adding serial shell support to uvtool
<elopio> cgoldberg: I've sent you the invite to the talks.
<elopio> please check I didn't mess with the timezone again :)
<rbasak> pitti: I'd really like a one command adt-virt-kvm/qemu/uvtool/whatever that a user can use directly using adt-run and supports break-testbed. Is this what you're working on, or will you need support scripts from auto-package-testing?
<pitti> rbasak: once you have any VM, this is what I'm working on
<rbasak> What do you mean by "any VM"?
<pitti> rbasak: unfortunately, for the cloud images you need to specify two drive images (as they always need the seed image)
<rbasak> Well, that's what uvtool wraps :)
<pitti> but that's due to how we build "our" base images
<rbasak> It's cloud-init, which is fast becoming the accepted way of doing things.
<pitti> rbasak: well, if you have any Debian/Ubuntu VM, I'd just like adt-run ... --- adt-virt-kvm /path/to/image
<rbasak> It's not Ubuntu-specific.
<pitti> or, in our case, /path/to/baseimage /path/to/cloudseed
<rbasak> I'd like apt-get install <stuff> && adt-run ... --- adt-virt-uvtool trusty.
<pitti> rbasak: my first prototype uses ssh to communicate, and thus needs to know an username and ssh key
<pitti> but I don't like that
<rbasak> With no other support or set up scripts required.
<pitti> rbasak: yeah, once we have adt-virt-qemu, we can think about auto-creating base images
<rbasak> Well, in the Ubuntu case, we publish official base images.
<pitti> but you don't want to create a new VM each time you run a test, so we need the intermediate -qemu runner, too
<rbasak> From my perspective, Debian not doing so necessitates a workaround, rather than being the primary form.
<pitti> extending that to build the VM (with either a new runner, or a new option) is the next step, and sounds interesting
<pitti> so, instead of /path/to/image we could support an "uvtool:trusty" argument, possibly with a --cache-dir or so
<pitti> s/instead of/in addition to/
<rbasak> Can we use VM snapshots via libvirt? Or do you not want to use libvirt?
<pitti> but still, I really don't want to make strong assumptions about the VM
<rbasak> (for virt reset, for breaks-testbed, to avoid starting a VM)
<rbasak> I think you're getting too low level.
<pitti> if you have an existing Ubuntu or Debian desktop installation, or something else you hacked on yourself, this should still be useful for running tests i
<rbasak> I think it makes sense to use higher pieces in the stack where they support the functionality you need, rather than reinventing it.
<pitti> n
<rbasak> uvtool supports --backing-image-file.
<cgoldberg> elopio, lightning talk is tomorrow?  I thought it was today for some reason, and was ready to go :)
<rbasak> I think that should be the uncommon case, though.
<cgoldberg> elopio, but no prob.. tomorrow is better
<pitti> still, I don't want to bind this to exactly one type of VM, ubuntu specific, and with making a lot of assumptions (network, ssh, cloud-init, etc.)
<elopio> cgoldberg: great :)
<pitti> as these are all pieces which you might actually want to test
<rbasak> Network and ssh I agree with. We could use serial terminal to fix that.
<pitti> we already had a case where NetworkManager tests tore down eth0 and the whole test hung
<rbasak> cloud-init I don't agree with. It is the accepted way of setting up a VM. We should use it.
<pitti> the thing that currently is too hard is to access/modify a VM image
<pitti> once I get an additional init.d script in there, accessing the VM is trivial; there's not much to reinvent there
<rbasak> Are you aware of mount-image-callback? In cloud-image-utils.
<elopio> I'll send more invitations. balloons, now that we have practices with a couple of talks, I think it would be nice to invite all the QA community.
<rbasak> Admittedly it currently needs root.
<pitti> yeah
<pitti> I'd like to avoid that
<pitti> as we want to run it in the data center on machines where we don't have root
<rbasak> I really feel that you're reinventing the wheel, here.
<rbasak> I'd like to implement an adt-virt-uvtool. It's one of the use cases I had in mind when I wrote adt-virt-uvtool.
<rbasak> Now that uvtool exists, it is trivial to implement.
<pitti> rbasak: well, adt-run's assumption is: I have a pipeline to the testbed; with that it can do everything
<rbasak> adt-run also requires the virt driver to have a mechanism to create the testbed, and to roll it back (for breaks-testbed). And destroy, obviously.
<pitti> right
<pitti> that's what we already do in run-adt-test
<rbasak> This should be quick to be useful to developers. It should be one command. It should not require previous setup.
<rbasak> run-adt-test does not meet these requirements.
<pitti> not require, but support
<pitti> I want pre-prepared images, not downloading/building images for each test
<pitti> (yes, I guess you can do that)
<pitti> rbasak: sure, for starting/controlling qemu uvtool sounds nice, I'll look at it
<rbasak> With uvtool you download a pre-prepared image once.
<pitti> rbasak: does that support debian VMs?
<rbasak> It requires cloud-init.
<pitti> hmm
<rbasak> I don't want to be dragged along by Debian not publishing cloud images with cloud-init.
<rbasak> Or not publishing easily consumable metadata for downloads.
<pitti> fair enough :)
<rbasak> I'm not saying that we shouldn't support Debian; we should.
<rbasak> But we (server team) are actively working on this stuff. In my mind, we're the upstream and leading the way for cloud image consumption.
<rbasak> So, to me, supporting Debian not doing cloud-init and not publishing cloud images and not publishing cloud image metadata is a workaround.
<rbasak> We can support that, with --backing-image-file.
<rbasak> And a script to generate a suitable Debian image.
<rbasak> (assuming that cloud-init works OK)
<pitti> well, our ubuntu desktop images aren't cloud-initified either
<rbasak> Perhaps uvtool could have an option to not use cloud-init.
<pitti> (and they are ready-to-work VM images)
<balloons> elopio, yes, and they are archived, so that is useful as well
<rbasak> You'd lose the handy options to do stuff in the VM.
<balloons> would you want to do it in the form of an onair session?
<rbasak> But with serial shell support expected in the VM, you'd still be able to get to it.
<pitti> right
<pitti> which is a much weaker assumption than "has network", "has ssh", and "has cloud-init"
<pitti> and even "has network all the time"
<pitti> we currently cannot do any autopkgtest which touches the network, not even with breaks-testbed
<pitti> rbasak: so I just wanted to tinker around a bit whether it's feasible to do everything through ttyS{1,2}
<pitti> it may well turn out to not work, but let's see :0
<pitti> also, it seems that preparing VM overlays as non-root would be useful in other places too
<rbasak> AIUI, it should work, albeit perhaps slow.
<rbasak> pitti: OK. Can we sync when you're done experimenting? I don't want to duplicate effort here.
<pitti> rbasak: sure
<pitti> rbasak: btw, my init script is essentially
<pitti>     (setsid sh </dev/ttyS1 >/dev/ttyS1 2>/dev/ttyS2) &
<pitti> I put that into the overlay, and can run minicom from outside just fine (and a second netcat for stderr)
<rbasak> Will you need to do some other env setup there?
<rbasak> Perhaps "login -f root"? Though maybe from the host rather than the guest.
<pitti> rbasak: not really; other things (conceivably creating a temporary user for adt-run if you run as user) can be done from adt-virt-qemu through that shell
<pitti> one just needs to get a foot into the door
<rbasak> Yes; that's what I mean by "from the host".
<rbasak> I'm interested in the speed you get there, though. Be sure to use virtio for the serial hardware in the guest. But how long will it take to transfer a gig that way?
<pitti> yeah, that's my primary concern
<pitti> we might possibly do something like adding a second eth and using that for data transfer, and using the serial terminal just for controlling and running commands
<pitti> adt-run doesn't need to transfer much while a test is running; just for coyping in the package, and copying out the results
<rbasak> But then you need a network again.
<rbasak> Oh, I see.
<pitti> and during copying there are no tests interfering
<rbasak> So you assume the network is good before and after a test.
<rbasak> So the test will need to restore the network in the passing case, but that should generally be true for all tests?
<pitti> not assume, we need to set it up that way (and tear down the second eth during the test)
<pitti> rbasak: no, we always need the serial terminal (and possibly the qemu monitor, but that's no problem) to control the network
<pitti> this is all rather difficult, indeed
<pitti> and we certainly need to make some assumptions like "tests don't remove the "ip" binary"
<pitti> perhaps we can live with assuming that the tests don't tear down an "adteth0" interface which the setup creates, and use that as the one and only channel
<pitti> (static IP and netcat0
<cgoldberg> robotfuel, ping ...
<robotfuel> cgoldberg: hi
<cgoldberg> robotfuel, those benchmarks tests you have with a dashboard...
<cgoldberg> robotfuel, do you pull data from jenkins for the dashboard, or does jenkins push the data somewhere to store?
<robotfuel> cgoldberg: it gets pulled from jenkins
<cgoldberg> robotfuel, do any run against a device?
<cgoldberg> rather than a vm/desktop
<robotfuel> cgoldberg: only desktops
<cgoldberg> robotfuel, k thanks
<TheLordOfTime> ;ping
<TheLordOfTime> oops sorry
<TheLordOfTime> balloons, ping, if you're not busy, if you are i'll ask you later.  just trying to figure out who to ask questions to about the ubuntu touch stuff that's drifting around the mailing list
<balloons> TheLordOfTime, howdy
<TheLordOfTime> balloons, are you keeping up with the ML discussions?  There's a -devel -touch and -quality discussion about them not filing bugs against repo packages, is this just people being ignorant of how LP's bug systems work?
<TheLordOfTime> s/touch/phone/
<TheLordOfTime> or are they using a separate tracker system?  (I ask because anything bug related makes me a little interested, but I know nothing about how the phone dev stuff is)
<TheLordOfTime> oh, and good day to you all, too.
<TheLordOfTime> :)
<TheLordOfTime> forgot to be courteous to everyone else today D
<TheLordOfTime> :D
<balloons> TheLordOfTime, Ursinha mentioned it yesterday but I was engrossed in other things. I saw the posts and glanced at them
<TheLordOfTime> so i should probably touch base with Ursinha?
<Ursinha> TheLordOfTime, hey
<balloons> They want to make it clearer to keep track of bugs, etc
<balloons> and yes :-)
<TheLordOfTime> Ursinha, where're your bugs ending up now, Launchpad, upstream trackers, or some other tracker system?
<Ursinha> the thing is that some bugs were overlooked because there wasn't a clear policy about where to file bugs
<Ursinha> TheLordOfTime, all of our bugs are in Launchpad :)
<TheLordOfTime> Ursinha, and the upstream projects are on Launchpad?
<Ursinha> the point is their target, the upstreams projects in Launchpad or the Ubuntu source packages in Launchpad
<TheLordOfTime> Ursinha, if the answer to my last question is yes...
<TheLordOfTime> you can add a bug to an ubuntu package as well as upstream
<Ursinha> TheLordOfTime, I believe all of the upstreams that are part of Touch yes
<Ursinha> they can be found in launchpad
<TheLordOfTime> Ursinha, but i meant are they on Launchpad
<TheLordOfTime> if the upstreams trackers' are all on Launchpad...
<TheLordOfTime> and also all the packages are listed on Launchpad...
<Ursinha> TheLordOfTime, yes, the discussion is that we always need an ubuntu bugtask, if the upstreams prefer we can also add an upstream bugtask
<Ursinha> yes, all packages are on launchpad because they're part of the Ubuntu main archive
<TheLordOfTime> Ursinha, are all your bug filers and testers aware you can add an ubuntu bug task against the package, or against upstream, depending on how they were filed, after the fact?
<TheLordOfTime> not saying they all aren't, but i was purely curious
<Ursinha> TheLordOfTime, that's what we're discussing in that mailing list thread
<Ursinha> :)
 * TheLordOfTime is about 3 messages behind, let me catch up
<Ursinha> we need to be sure the policy is known and documented so whoever wants to file bugs can be pointed to that
<Ursinha> everything is on Launchpad, it's a matter of deciding if we're using upstreams tasks as well or not
<TheLordOfTime> mmm
<TheLordOfTime> Ursinha, okay, i was under the impression half the testers were unaware they could set it against both after the fact
<Ursinha> TheLordOfTime, right
<Ursinha> Launchpad in this sense is really nice so we have one bug and several affected parts
<Ursinha> packages or projects
<Ursinha> like for instance bug 1
<ubot5> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<TheLordOfTime> right
<Ursinha> there's half a million affected parts :P
<TheLordOfTime> heheh
<Ursinha> some upstreams decided to disable reporting bugs directly, deciding to use only the distro package
<TheLordOfTime> Ursinha, typically, my "If in doubt" fallback is to immediately compare what's in the repositories and what's in trunk upstream or at least the latest release of upstream on the same track as whatever's included in the repos by version, and if there's a substantial delta between what you're reporting against and what's upstream, don't file the upstream task, but you can also take the flip of that...
<TheLordOfTime> and just file both anyways, until upstream tells you to stop
<TheLordOfTime> but that usually can cause tension, and of course, I'm not in the ubuntu touch scope, i merely triage bugs under the ubuntu bug guidelines
<Ursinha> TheLordOfTime, well, if you're using ubuntu than first thing would be to report it against the ubuntu package, not upstream
<TheLordOfTime> mhm
<Ursinha> after that if upstream thinks it's relevant they add another bugtask
<TheLordOfTime> Ursinha, indeed, as is typical triage / how to file a bug
<TheLordOfTime> mhm
<Ursinha> but the rule of gold is if you found a bug in the distro, file a bug against the distro package
<TheLordOfTime> Ursinha, as it should be :)
<Ursinha> :)
<TheLordOfTime> Ursinha, so then the only issue you're hung up on then...
<TheLordOfTime> is when to file an upstream bug.
<TheLordOfTime> or rather, add an upstream task
<Ursinha> that's what we're discussing there :) because some people weren't reporting the bug against the ubuntu package at all
<TheLordOfTime> Ursinha, if i may voice a basic opinion, if testers want to test and see if it needs an upstream task, test against upstream
<TheLordOfTime> ahhh
<Ursinha> so first thing is we need to agree on doing that no matter what
<TheLordOfTime> well those people are at fault, tie them down and indoctrinate them :P
<Ursinha> haha
<Ursinha> second thing is to think about the upstreams and if they find value in using the upstream tracking
<TheLordOfTime> you might reach out to the commonly-filed-against upstreams and ask them
<TheLordOfTime> i'm probably not adding anything, but i'm merely trying to figure out where you guys are standing :)
<TheLordOfTime> ... back in a bit, coffee run
<Ursinha> TheLordOfTime, that's what I aimed by sending that email, I added -touch and -devel to the loop, I believe all upstreams were reached that way
<TheLordOfTime> heheh
<TheLordOfTime> Ursinha, i'd say then the ball is in upstream's court, they can either respond, or just drop the ball, and if they do drop the ball on that, then I'd take the view, if it were my call, to say "Only file against the Ubuntu package, and nothing else"
<Ursinha> â
<TheLordOfTime> except where someone's testing against upstream trunk and reproducing it there too
<TheLordOfTime> BTW, 0x0000 is lol
 * TheLordOfTime points at unicode that isn't matched to any characters xD
<Ursinha> lol
<Ursinha> that was supposed to be a hot beverage char
<TheLordOfTime> :P
<TheLordOfTime> Ursinha, emoji?
<Ursinha> TheLordOfTime, http://www.fileformat.info/info/unicode/char/2615/index.htm
<TheLordOfTime> ahhhh, the smell of brewing coffee... awesome.
<TheLordOfTime> (sorry i'm a high-level coffee addict... the smell of coffee is amazing to me)
<elfy> pfft
<TheLordOfTime> elfy, 12 cups yesterday
<TheLordOfTime> that's how much i had
<TheLordOfTime> ... and that was just in 12 hours
<elfy> 2 gallons here
<TheLordOfTime> woah damn elfy
<elfy> of tea
<TheLordOfTime> lol
<Ursinha> haha
<elfy> you should know better :D
<TheLordOfTime> well... I did overdose on coffee a while back...
<TheLordOfTime> it was finals week and i had to be up for four days....
<TheLordOfTime> and i kinda started binge-drinking espresso... the day after that was bad...
<TheLordOfTime> but i digress
<TheLordOfTime> Ursinha, yeah, i think you're on the right track dictating the bug filing policies, i have one question: some of your testers and devs are testing upstream trunk separately from the repos right?
<Ursinha> TheLordOfTime, the idea with continous integration is to have trunk as close as possible of what's in the distro
<TheLordOfTime> Ursinha, true, but i meant constantly testing, always pulling and building and testing from upstream when there's even a minor delta
<TheLordOfTime> because if there are people doing that, then those would be the ones who could say whether something needs an upstream task, if they are able to reproduce there too.
<Ursinha> that happens automatically (for most projects) when a change is being integrated to trunk, and the next step is to be pushed to distro
<TheLordOfTime> ... dear god not again, balloons, the cosmic rays are breaking the mailing list systems again...
<TheLordOfTime> i have four of the same message >.>
<Ursinha> what's up?
<Ursinha> lol wat
<TheLordOfTime> Ursinha, i have four of the same message on the last message on that thread.
<TheLordOfTime> three of the same last message just showed up in my inbox for no reason :/
 * TheLordOfTime blames those pesky cosmic rays interacting poorly with the mailing lists
<TheLordOfTime> Ursinha, it's either cosmic rays or the mailing lists hate me
<Ursinha> haha
<TheLordOfTime> i tried to send something to -bugsquad once, after my emails were registered, and it bounced even though the address was listed as being able to send
<TheLordOfTime> thats happened to me once on the -quality ML too but meh
<TheLordOfTime> meh, i'll just delete the dupes
<TheLordOfTime> Ursinha, thanks for filling me in on the full context of what's with that topic on the ML :)
<Ursinha> TheLordOfTime, no problem :)
<TheLordOfTime> everything bug related in -quality piques my interest, since my primary focus is general bug triage :)
<Ursinha> great :)
<TheLordOfTime> oh that reminds me, balloons, ping
<TheLordOfTime> balloons, where's the bugsquad/QA merge in terms of being completed/processed/approved-by-CC
<TheLordOfTime> Ursinha, you know how i said the mailing lists must hate me?  I lied...
<TheLordOfTime> apparently its my SMTP and IMAP servers that hate me
<TheLordOfTime> because i'm getting multiple messages in duplicate triplicate and quadruplicate :/
<elfy> I get the same now TheLordOfTime
<Ursinha> TheLordOfTime, so it seems you are surrounded by hate
<Ursinha> oh technology
<TheLordOfTime> Ursinha, either that or i've become a source for cosmic ray radiation
 * TheLordOfTime shrugs
<TheLordOfTime> elfy, oh so it's the INTERNET that's broken, not just my stuff?
<TheLordOfTime> Oh good, I thought I broke my servers for a moment xD
<TheLordOfTime> meh, i'm gonna go restart the smtp and imap processes...
<TheLordOfTime> maybe that'll make the thing work
<balloons> TheLordOfTime, I used to filter out my own messages on accident. I've sorted that out, so I know the mailing list pain :-)
 * TheLordOfTime heard a beep, peeks at his system
<TheLordOfTime> balloons, heh.
<TheLordOfTime> brb, i need to dig the car out of the snow...
 * TheLordOfTime grumbles profanities about the snow
<TheLordOfTime> well, at least get some of the snow out of the way so i can get out of the driveway
<dkessel> good evening
<dkessel> balloons, i got a mail from phillw stating that http://packages.qa.ubuntu.com/qatracker/testcases/1613/info can be removed ... the package is not part of the default installation anymore
<elfy> balloons: ^^ THAT might cause the whole thing to fall apart for lubuntu's desktop package tests if it's just removed - remember what happened with our stuff ...
<balloons> dkessel, evening to you
 * dkessel o/
<elfy> hi dkessel :)
<dkessel> hey elfy
<balloons> dkessel, we should document the proceedings a bit.. a bug report perhaps? :-)
<balloons> elfy, I'll make sure not to zonk your stuff
<balloons> just want to be sure there's a trail to follow
 * knome drops small bits of cookies on balloons' floor
<dkessel> hehe knome
<elfy> balloons: that's not what I meant - I'd assume you'd not go and break something I'd have to send knome after :P)
<elfy> was just saying that removing a testcase from a testsuite is what caused us to have archived testsuites in package tracker
<knome> elfy, that bug should've been fixed, and only appropriate if you want that testcase being non-archived in another testsuite
<elfy> well yea - I'm just saying what happened - I didn't follow it for long enough to see if it got fixed or just repaired ;)
<knome> isn't that the same thing? ;)
<elfy> not at all
<knome> heh
<elfy> fixed - doesn't happen again/repaired - fixed this one this time, don't do it again :D
<knome> hah
<knome> well it was fixed by the awesome stgraber
<elfy> :)
<balloons> well hello knome !
<balloons> I should have noticed the cookie crumbs
<DanChapman> elfy https://jenkins.qa.ubuntu.com/view/Ubiquity/view/Xubuntu/ will make viewing results easier for you :-)
<elfy> nice :)
 * elfy sends DanChapman a cookie
<knome> elfy, that the one you picked up from balloons' floor?
<elfy> sssh
 * DanChapman dips it in his cuppa
 * DanChapman just spat all over the desk
<elfy> DanChapman: shake it first ...
<elfy> too late :|
<DanChapman> lol
<elfy> so they are failing then according to jenkins ?
<DanChapman> elfy yeah wee discovered a bug yesterday in autopilot a fix should land hopefully tomorrow so in the next couple of days they 'should' go green
<elfy> right
<elfy> just in time for me to see some green lights to show the xubuntu team at the thursday meetng hopefully
<elfy> and I'll grab lderan before hand to find out if autopilot for us is a but thumbs down again this cycle
<dkessel> hehe knome
<dkessel> so, is there anything to do about the testcase I wrote about above?
<balloons> dkessel, no.. I'll take care out if.. you can confirm it's good in a moment
<dkessel> balloons, ok thanks
<balloons> whew.. the random sentences spewing out today
<dkessel> hehe. big fingers today? :)
<balloons> it means my mind is everywhere I think
<balloons> alright.. I think we are good
<dkessel> yup, gone. fine
<balloons> excellent
<balloons> I don't even think I blew anything up for elfy
<balloons> sadly...
<dkessel> too bad ;)
<balloons> buonsera Letozaf_. come stai?
<Letozaf_> balloons, buonasera :D bene e tu ?
<balloons> bene! Fixed 3 core apps last night :-)
<Letozaf_> balloons, wow! you done a great job :)
<Letozaf_> balloons, witch ones?
<balloons> file manager, rss reader and calendar. Trying to keep everything green
<balloons> we got really close but the work we did before uds didn't quite get us all the way there
<Letozaf_> balloons, rss reader yay! :D
<Letozaf_> balloons, well we will have to keep them green now
<balloons> yes, I'm cutting a hard line
<Letozaf_> balloons, I have a test for music app, it works on the desktop, if it works on the device  I will propose merge, but first I will have to flash the right image to my device for testing
<balloons> Letozaf_, wonderful!
<Letozaf_> balloons, wait, let's see if it works on the device first :P
<Letozaf_> balloons, they always first work on desktop :P
<balloons> dkessel, Letozaf_, knome elfy, other lurkers :-) I was just having a look at this tool, http://reqorts.qa.ubuntu.com/reports/qa/qa-touch.html, and wondered if some custom views for our purposes would be useful to everyone
<elfy> balloons: well I am glad that worked - we're going to be looking at ours shortly - so needed someone to test that :p
<balloons> for instance, have view for entire team so we can see what bugs we have opened. have a view for installer/image bugs. Have a view for bughug days, etc
<elfy> oooh
<balloons> autopilot tests / issues as well
<elfy> that would be excellent if you could have a user defined search term
<balloons> that's off the top. I can think of triage uses as well, but I'm less well versed
<elfy> I could say look for xubuntu trusty iso
<elfy> kind of thing
<elfy> date fields perhaps
<balloons> live search isn't so much an option, as this is a report, not a launchpad replacement :-)
<elfy> even if it was generic - but split flavours up from the general thing - kind of like that does with canonical/cordova etc
<balloons> but filtering is possible, and so, defined filters can work
<balloons> yes, filters for flavors makes sense
<balloons> and would be well defined
<elfy> yep
<elfy> I have to look at iso/package tracker every now and again to see what everyone else is seeing :)
<elfy> balloons: when I want to look atm - I drag the archived test results and manually look at what bugs we've reported - takes ages ...
<balloons> elfy, ugh yea
<knome> it IS a bummer there is no "list all the bugs" mode in the trackers, just "hover over"
<elfy> knome: yep
<elfy> balloons: sooo - Xubuntu would like that :D
<Letozaf_> balloons, what if I wanted to see all the core apps bugs for instance
<Noskcaj> Does anyone think they could help me with transmission-gtk's autopilot test? I've pushed my terrible first attempt to lp:~noskcaj/ubuntu-autopilot-tests/transmission
<dkessel> yay, lubuntu on tv... on a german series i am just watching :)
<Noskcaj> :)
<Noskcaj> I think i saw ubuntu on person of interest, no other shows yet
<dkessel> gotta leave.. good night folks...
<balloons> dkessel, lubuntu even? cool!
<balloons> Noskcaj, sure i'll have a look
<balloons> Dan isn't around, he's the gtk master :-)
<Noskcaj> balloons, I think transmission or gtk is having an issue. Even with my lack of skill and using both self.app and app_proxy, it doesn't really work as i would have expected
<balloons> Noskcaj, it's possible.. not every gtk app is happy to be introspected
<Noskcaj> i think transmission is though. Every xfce app dooesn't though
<Noskcaj> maybe i should try transmission-qt
<balloons> Noskcaj, qt is much saner for instropecting
<balloons> but let's see
<Letozaf_> balloons, must I tell Victor about the music app merge proposal or you ?
<balloons> Letozaf_, when you propose it shows up on the radar for everyone :-)
<Letozaf_> balloons, ok so I won't tell anyone :P
<balloons> Letozaf_, haha, you can mention it, I'm just saying :-)
<Letozaf_> balloons, :P
<balloons> Noskcaj, btw, Gtk-Message: Failed to load module "autopilot"
<balloons> you get the same?
<balloons> Noskcaj, you can see with a simple launch check
<balloons> autopilot launch -i Gtk transmission-gtk
<balloons> Gtk-Message: Failed to load module "autopilot"
<Letozaf_> balloons, failure :(
<balloons> Letozaf_, ? ohh the mp
<balloons> Letozaf_, ohh that's easy
<balloons> it's a pep8 thing
<balloons> + pep8 --repeat --show-source .
<balloons> ./tests/autopilot/music_app/emulators.py:106:29: E712 comparison to True should be 'if cond is True:' or 'if cond:'
<balloons>             if item.enabled == True:
<balloons>                             ^
<balloons> ./debian/music-app-autopilot/usr/lib/python2.7/dist-packages/music_app/emulators.py:106:29: E712 comparison to True should be 'if cond is True:' or 'if cond:'
<balloons>             if item.enabled == True:
<Letozaf_> balloons, ok let me fix that
<Letozaf_> balloons, done, I will push it
<Letozaf_> balloons, done, going to bed now! hope it works otherwise I will fix it tomorrow
#ubuntu-quality 2013-11-27
<pitti> Good morning
<jibel> Good morning
<pitti> jibel: I'm deeply concerned
<jibel> pitti, about?
<pitti> jibel: I'm through my morning email, and I'm missing the usual dozen "jenkins failed" mails
<pitti> I only got a "fixed" one for python2.7
<pitti> OMGwhatiswrong?
<jibel> pitti, do you miss them?
<pitti> muchly! no swearing to do this morning
<jibel> pitti, I can configure the jobs to send you an email on every run if that makes feel you better?
<pitti> oh yes please, more email
<jibel> ah, lubuntu is fixed!
<jibel> DanChapman, Good morning, lubuntu should be running correctly now
<jibel> DanChapman, the problem was that autopilot was running twice because lubuntu now honors etc/xdg/autostart which it didn't few weeks ago
<jibel> I don't know if it was a bug before that I naively worked around or if it is a bug now
<jibel> anyway, I added lock file to ensure run-autopilot starts only once
<jibel> and also retry apt several times if it fails to install additional packages
<DanChapman> jibel, good morning :-) awesome thank you! well that makes more sense as to why it stopped running, but yes it does sound like it might be a bug
<davmor2> Morning all
<elopio> good morning everybody.
<elopio> we will have 30 minutes of QA talks: http://youtu.be/Zhu_4xF5aAw
<elopio> starting in 10.
<DanChapman> good morning elopio o/
<elopio> hello DanChapman
<jibel> pitti, re. secure boot testing, I did an initial test with qemu, a 1GB disk, and automated partitioner failed :/
<pitti> jibel: you mean UEFI?
<pitti> jibel: ah yes, I think I remember
<jibel> pitti, yes
<pitti> jibel: could be that I had to use manual partitioning
<pitti> jibel: so, nice test case :)
<pitti> jibel: oh wait, 1 GB is not nearly enough -- you need 4 or so
<jibel> it allocates half of the drive to the efi partition and there is no room left for the os
<elopio> and, starting now http://youtu.be/Zhu_4xF5aAw
<jibel> yeah, I'll increase it but it's a base server install, it shouldn't require much space
<pitti> jibel: indeed
<pitti> mzanetti: so you can't directly access subobjects? what makes the top level widgets special?
<mzanetti> pitti: every file has it's own context
<pitti> mzanetti: I don't yet understand why creating these intermediate objects to make properties r/o is helpful
<mzanetti> pitti: while the context gets propagated downwards, it is not propagated upwards
<pitti> mzanetti: i. e. if mycat.weight is r/o, why can't I access mycat.internal.weight?
<mzanetti> pitti: you can't do that from the outside of the file
<mzanetti> pitti:  for example:
<pitti> mzanetti: so you only "see" the top level objects?
<mzanetti> if you use the Cat {} in another file, you can access only the top level stuf
<mzanetti> f
<mzanetti> exactly
<pitti> ah, ok; that was missing
<vila> mzanetti: could you make stack.depth an attribute that emits an event when it's updated so that tests can subscribe to that instead of polling ?
<pitti> mzanetti: and the findChild() is basically a workaround for this to make them accessible for tests after all
<mzanetti> vila: yes. that's exactly what's happening
<mzanetti> tryCompare() just waits for that signal and compares if the new value is what you want
<mzanetti> pitti: exactly
<vila> mzanetti: \o/
<pitti> mzanetti: thanks; that wasn't clear to me
<mzanetti> pitti: np
<pitti> mzanetti: I can't say that the "internal object" property wrapper is the utmost elegance, but good to know that you can if you must
<mzanetti> pitti: yeah. usually I try to pack stuff into existing other items
<mzanetti> pitti: but if you don't have that, you can use some new Item. I suggest QtObject {} in that case because it's the most lightweight
<mzanetti> pitti: as in: it doesn't have anything to paint, Item {} and everything derived from that does
<cgoldberg> virtualenv/tox slides:  http://goldb.org/talks/2013/canonical-tox
<pitti> thanks cgoldberg
<elopio> mzanetti: so, when should we use javascript? Is there something that we can't or shouldn't do with the declarative lang?
<mzanetti> elopio: rule of thumb: if you find yourself typing the word function there's a re really good chance you're on the wrong path
<mzanetti> elopio: functions are useful for triggering stuff at components. for example the Cat.feed()
<mzanetti> elopio: but even in there, try to keep the javascript as short as possible
<mzanetti> elopio: try to just set one property and calculate the rest with property bindings
<elopio> mzanetti: got it.
<elopio> an interesting follow-up session would be best practices for combine c++ with qml
<elopio> mzanetti: do you know somebody that can give that presentation?
<mzanetti> elopio: tsdgeos, saviq, or myself I guess
<elopio> mzanetti: ok, I'll ping them to get new people participating, and fall back to you :)
<mzanetti> heh
<elopio> mzanetti: last thing, can you make your slides public please?
<mzanetti> ah, sure
<mzanetti> elopio: done
<elopio> thank you!
<elopio> mzanetti: I'm sorry, what would be the link?
<mzanetti> elopio: https://docs.google.com/a/canonical.com/presentation/d/1O6lLjxgCT-kXwFAszvIN2bwG8ROIVpzm3dBvYZhiY9Y/edit#slide=id.g17ad694ca_038
<pitti> elopio: your dialer-app pep8 fix still fails; apparently there's some longer-time uninstallability of Qt5 in trusty-proposed :/
<elopio> pitti: yes, I've just read the email. :(
<elopio> pitti: thanks for pushing it again. Should I talk with CI about the error? or have you done that already?
<pitti> elopio: well, it's not a CI problem
<pitti> /var/local/autopilot/setup.log:  dialer-app : Depends: qtdeclarative5-ubuntu-telephony0.1 but it is not going to be installed or
<pitti> /var/local/autopilot/setup.log:                        qtdeclarative5-ubuntu-telephony-plugin but it is not installable
<pitti> elopio: that's a problem in the packaging of either dialer-app, or the telephony qt stuff
<elopio> well, I was hoping CI to find the culprint and somebody to fix it. Maybe it's too much to ask from them :D
 * pitti checks http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> ah, so evolution-data-server and folks seem to break it
<elopio> *culprit
<pitti> elopio: see #u-devel
<elopio> thanks pitti.
<barry> cgoldberg: nice talk.  note that the venvs that tox creates can be activated and deactivated too.  very handy
<barry> you can create new environments
<barry> pitti: ^^
<cgoldberg> barry, thanks!  right.. once created you can go to .tox/ , and see your envs and activate/whatever
<barry> i do that all the time :)  .tox/py33/bin/activate etc...
 * barry should really package up detox
<barry> sitepackages=True
<barry> cgoldberg: ^^
<cgoldberg> detox is super cool.  i'm surprised it's not just a switch on tox, instead of another package
<barry> agreed
<barry> re: sitepackages vs pypi.  it's actually a bit problematic for debuntu.  i'm in conversation w/upstream about things that would make tox nicer for distros
<barry> great talks, thanks!
<elopio> barry: +1 in packaging detox :)
<elopio> barry: would you be interested in doing a small talk about python 2 - 3 incompatibilities and how to solve or avoid them?
<barry> elopio: sure
<elopio> barry: :) at what time do you EOD?
<barry> elopio: well, probably not *today* :)  long usa holiday weekend coming up.  but generally eod at 2300utc if my math/dst is correct :)
<elopio> that's perfect.
<elopio> barry: I'll look for the other speaker and get back to you to see a date. Maybe in two or three weeks, at a time close to your eod.
<barry> elopio: sounds good!
<elopio> thank you
<DanChapman> jibel, does xterm need to be open during the test? an assertion error keeps popping up ('The following apps were started during the test and not closed: %r', [<Application 'XTerm'>, <Application 'Install Ubuntu 14.04 LTS'>]) which is strange considering xterm is open long before ubiquity launches
<DanChapman> that error also suggests that xterm is top of the window stack aswell :-/
<TheLordOfTime> Ursinha, i see that the phone bug people are running into the Bug Control Only features that they need to set bugs triaged... xD
<TheLordOfTime> oop i might've mishighlighted IDK.. my logs went away :/
<TheLordOfTime> if i mishighlighted ignore :)
<dkessel> guten abend
<jibel> DanChapman, no you can remove it, it was just a convenient to have a reliable terminal which always works in a VM and is rarely affected by rendering or performance issues
<dkessel_testuser> testing pidgin
<dkessel> ...and that is a pass on the manual test :)
<elfy> balloons: is there going to be a ubuntu cadence schedule or are you just doing the exploratory thing
<balloons> evening :-)
<elfy> and hi ;)
<balloons> just exploratory testing. We've got works items to spruce up the page a bit and to communicate it more
<elfy> ok - thanks - just needed to know if you had a schedule at all - we'll roll our own :)
<balloons> so yea, nothing beyond the milestones.. and for ubuntu there are no milestones before beta
<elfy> actually be doing a bit of both 'cadence' and exploratory
<elfy> yep
<balloons> instead as we spoke about in the call for testing event, I wanted to push letting us collectively schedule testing events
<balloons> so between that and exploratory testing, aka dogfooding, which many already do each cycle, I think we're covered
<balloons> I'd like to just talk about being effective while dogfooding, etc
<elfy> well to be honest I'm afraid I want to get on talking to our team - we've a lot of new stuff planned to land which needs to have some sort of schedule QA wise
<elfy> not got time to wait for others to decide what they're going to collectively do ;)
<Noskcaj> balloons, transmission-gtk launches fine for me, what autopilot and transmission versions do you have?
<balloons> Noskcaj, let me check
<balloons> Autopilot Source Version: 1.4.0 Autopilot Package Version:
<balloons> 1.4+14.04.20131125-0ubuntu1
<Noskcaj> i'm pretty sure that's what i have too
<balloons> autopilot launch -i Gtk transmission-gtk Gtk-Message: Failed to load module "autopilot"
<DanChapman> jibel, lovely thanks mate, I'll just comment it out in the MP i have waiting atm. Easy enough to re-enable if needed that way
<dkessel> Noskcaj, good evening. I have attached a screenshot to bug 1252438. can you have a look if you see the search box on it?
<ubot5> bug 1252438 in Ubuntu Manual Tests "lubuntu software center testcase - no search box" [Undecided,New] https://launchpad.net/bugs/1252438
<balloons> Noskcaj, are you on saucy or trusty? also, what output do you get in running transmission?
<dkessel> btw: is software center crashing for you guys, too?
<dkessel> on trusty?
<balloons> dkessel, crash on start or ?
<dkessel> yup... window shows up, then window becomes unresponsive...
<Noskcaj> balloons, trusty, http://paste.ubuntu.com/6486135/
<balloons> Noskcaj, really? that's wild
<balloons> dkessel, yes, same
<dkessel> balloons, ok
<Noskcaj> dkessel, lsc has the search bar for me, but not for you
<dkessel> Noskcaj, strange...
<dkessel> Noskcaj, could it be... longer translations for some of the stuff on the top? so there is no more space for the search box?
<Noskcaj> dkessel, That would make sense, have you tried fullscreen?
<dkessel> Noskcaj, dang.... there it is...
<dkessel> lol!
<dkessel> still... many users wouldnt try that
<Noskcaj> no, i'll add a mention to try fullscreen and push that now
<dkessel> k thanks
<Noskcaj> Is 1619 in the testcase bzr branch?
<dkessel> don't know... I found it on the package testing tracker
<Noskcaj> It's not, i've just fixed this on the tracker though
 * dkessel browses code
<dkessel> yeah... missing
<dkessel> anybody idling around who has had some contact with me: I plan to apply for ubuntu membership. If you want to help me, leave a nice testimonial on my wiki page: http://wiki.ubuntu.com/dkessel ;)
<Noskcaj> dkessel, Can i suggest you add you launchpad page to the contact info
<Noskcaj> https://wiki.ubuntu.com/phillw is still what i model my wiki page off
<dkessel> Noskcaj, good idea. done
<knome> dkessel, i have seen your nick around this channel - hi! i would suggest you extend that page even further, which i'm sure you've planned to do :)
<dkessel> knome, ok. I see... yes I'd better do that... :)
<knome> basically any link to actual work you have done is good
<Letozaf_> balloons, hi
<balloons> Letozaf_, hello :-)
<Letozaf_> balloons, I fixed yesterday's test, I need to ask something about music-app, must I ask Victor ?
<balloons> Letozaf_, did you push it to see that it would pass?
<Letozaf_> balloons, wow, your question makes we wonder something went wrong, I thought I pushed it, let me check
<Letozaf_> balloons, I will push again now, something didn't work
<balloons> ahh.. did you commit first, hehe
<Letozaf_> balloons, I think I did, let me check
<Letozaf_> balloons, done, now it's pushed I checked
<Letozaf_> balloons, sorry I thought I had it pushed :P
<balloons> Letozaf_, still building
<balloons> Letozaf_, anyways, feel free to send a mail or post in the MP
<balloons> Letozaf_, if you want victor specifically, request him at the top :-)
<Letozaf_> balloons, ok thanks
 * Letozaf_ got fingers crossed
<Letozaf_> balloons, yay, it passed :D
<balloons> good work!
<Letozaf_> balloons, thanks!
<balloons> Letozaf_, there's a few tweaks you can do to the code in looking at it
<balloons> switch_to_tab will return the tab object so you don't have to get it :-)
<balloons> and then you can drop the assert as well
<Letozaf_> balloons, ok fine I will correct the code
<Letozaf_> balloons, I was a bit too used to putting asserts everywhere
<balloons> Letozaf_, yes we can go without in many causes now thanks to the changes in ap 1.4 and by using the emulator :-0
<Letozaf_> balloons, cool, just have to get used to it :P
<balloons> Letozaf_, also I'm not sure eventually makes sense in these: self.assertThat(albumartist.text, Eventually(Equals(artistName)))
<balloons> nothing is being updated as far as I can tell
<balloons> I would drop those 2 asserts as well, and if there is a timing thing, add it into the get functions instead
<balloons> make sense?
<Letozaf_> balloons, thinks so, let me make the changes and push it so you can check
<Letozaf_> balloons, well first I will check it still runs
<balloons> sure.. I mention this little things to make sure it doesn't cause us trouble once we're running on the phone
<balloons> but it's awesome you checked it as well :-)
<Letozaf_> balloons, yes thanks, as I told you I was used to put asserts everywhere, I will have to learn to not do it
<Letozaf_> balloons, but the second self.assertThat(albumartist.text, Eventually(Equals(artistName))) I put it to check the album sheet opened is the correct one
<Letozaf_> balloons, is that wrong, I mean, how do I know I did not open another sheet
<elfy> balloons: was there a chance that the custom views of http://reqorts.qa.ubuntu.com/reports/qa/qa-touch.html is likely to gain any traction?
<balloons> elfy, yes.. It's an idea
<balloons> as with everything, needs someone to do it :-)
<balloons> but i'm going to gather a bit more data
<elfy> yea - I get loads of ideas :(
<elfy> bu then can't do it so forget about it till next time I think of the same thing
<Letozaf_> balloons, the test passed before I could run it on my phone :) looks like it's ok, I left the second assertion for checking I had opened the right album sheet, is that ok ?
<balloons> Letozaf_, looking
<balloons> Letozaf_, looks better.
<balloons> Letozaf_, did you want victor to review or ?
<Letozaf_> balloons, yes
<balloons> so Letozaf_ https://code.launchpad.net/~carla-sella/music-app/show_albums_sheet/+merge/196785/+request-review
<balloons> add him :-)
<Letozaf_> balloons, done!
<dkessel> knome, I guess my wiki page looks better now?
<Letozaf_> balloons, at least I think it's a good idea that Victor reviews the test, right ?
<balloons> Letozaf_, yea.. you should add the bugs you are closing as well
<balloons> victor created the bugs :-)
<knome> dkessel, yep, better already
<Letozaf_> balloons, ok thanks
<balloons> dkessel, I added something to the bottom as well
<dkessel> ty balloons
#ubuntu-quality 2013-11-28
<slickymaster> morning all
<davmor2> Morning all
<jibel> pitti, did you already try -hda fat:<directory> to share data between a qemu guest and the host? Do you know if there is any limitation?
<jibel> (or -hdb, ...)
<jibel> fat:rw:<dir> even
<pitti> jibel: oh nice, I wasn't aware of that
<pitti> jibel: you'd still need to inject some command to copy files from it, or bind-mount it, or run programs on it
<pitti> jibel: but it's a simple (and much faster) way to copy up/down the tests and results
<jibel> pitti, indeed, I was just wondering if it is well supported because it prints some weird warning on mount/umount
#ubuntu-quality 2013-11-29
<DanChapman> good morning :-)
<pitti> Good morning
<DanChapman> morning pitti o/
<pitti> hey DanChapman, how are you?
<jibel> Good morning
<elfy> morning all
<DanChapman> pitti, i'm good thanks, and yourself?
<pitti> DanChapman: quite well, thanks! a bit tired, we went to bowling and some drinks last night, to celebrate my wife's last day at her current company
<DanChapman> pitti, very nice. Hope it was good fun :-)
<pitti> oh yes, it was
<DanChapman> :-)
<pitti> jibel: I'd like to temporarily disable all adt nodes except aldebaran (as that's the node where py3.3 failed), and re-run py3.3 with haveged installed; ok with you?
<pitti> jibel: or perhaps with a /dev/random -> /dev/urandom symlink; it seems to me that the py* tests regularly run out of entropy
<pitti> jibel: or at least, that's my current theory of why the uuid test fails so often
<pitti> jibel: i. e. I'd call prepare-testbed with locally modifying the cloud-init to install haveged
<pitti> or locally modify run-adt-test to do the urandom symlink (and then see whether that suffices)
<jibel> pitti, I confirm I made the same observation. Agreed to try with haveged
<pitti> jibel: I guess I wouldn't actually have to disable the nodes in jenkins, just run-adt-test manually on aldebaran
<DanChapman> jibel, pitti it seems that ubiquity bug is still kicking about :-( All the stacktraces are identical it seems that the killer point is when refresh_state is called. on the progressbar.fraction property. The test  polls on progressbar.fraction waiting for bar to reach 100%. It seems to be a very unique bug
<elfy> DanChapman: woohoo got some green lights for xubuntu :)
<jibel> DanChapman, it has not been merged, I'll ping the CI team
<pitti> DanChapman: yes, autopilot-gtk hasn't autolanded yet; I'll ask didrocks
<pitti> ok, jibel beat me to it
<pitti> jibel: it's in trunk (merged), just not autolanded
<DanChapman> elfy :-) and the custom_install tests are passing aswell they just have non-fatal errors. so Installation wise you have all green UI bug wise you have 1 failing if that makes sense :-)
<DanChapman> jibel, pitti ahh I see I thought it would have landed by now :-) thanks
<pitti> yeah, so did I -- especially now that "daily" is supposed to mean "every 4 hours"
<DanChapman> :-)
<elfy> DanChapman: yep that makes sense
<jibel> pitti, DanChapman, didrocks added it to the "Landing ask spreadsheet". Yay for powerful manual processes :)
<pitti> DanChapman: ok, didrocks is caring about it, should land today
<davmor2> Morning all
<slickymaster> morning all
<DanChapman> pitti, i must say your print_tree() addition is a rather handy little feature :-)
<pitti> DanChapman: glad that you like it
<pitti> DanChapman, jibel: fixed ap-gtk just landed in trusty
<DanChapman> pitti, great! thanks
<jibel> pitti, excellent, more green tomorrow
<jibel> pitti, we'd need something like http://paste.ubuntu.com/6494460/ I guess to run unit tests for qt...-src packages. I tried with qtxmlpatterns and qtsystems but some tests fails because they need a specific setup.
<jibel> (without the hardcoded path of course)
<pitti> jibel: oh, qmake isn't in $PATH? how weird
<pitti> jibel: ah, /usr/bin/qmake is an alias for qtchooser; doesn't that pick the right one?
<jibel> pitti, it does but I've been lazy and copy/pasted the line generated to run make check :) My point was that on 2 packages both testsuite failed and it will require a good amount of time to either fix or identify unit tests that must be skipped.
<jibel> and I haven't tried qtbase or qtwebkit
<pitti> jibel: ah, I understand; thanks
#ubuntu-quality 2013-11-30
<Arla> Hi. I want to test an alpha version of Inskape, because this bug (which affects me) seems to be fixed: https://bugs.launchpad.net/inkscape/+bug/531678 How do I get the latest version?
<ubot5> Ubuntu bug 531678 in Inkscape "Unable to select medium-weight fonts - forced to select bold weight instead" [Medium,Fix committed]
<phillw> Arla: 9.10 reached end of life in april 2011. http://fridge.ubuntu.com/2011/05/26/ubuntu-9-10-karmic-koala-end-of-life-reached-on-april-30-2011/ Any updates that have been applied will be for newer versions?
<Arla> phillw: I'm using saucy.
<phillw> Arla: then, if you still see the issue, please raise a new bug. It may be more helpful to pop onto #ubuntu-bugs and ask on there.
<phillw> Arla: that team are more 'up to speed' on handling bugs, whilst the joining of QA and bugs together is ongoing. When in doubt about a bug, ask those wonderful people :)
<phillw> Arla: they can better advise on a particular bug. It may be that the bug is 'alive' under a current number. If you pop onto that channel I'm happy to assist you in asking questions.
<Arla> phillw: Thank you. It's not clear to me how the bug can be specific to an Ubuntu version.
<phillw> Arla: do you still see the bug in Saucy?
<Arla> phillw: yes
<phillw> okay, it is marked 'fix committed' which means they want to fix it. This is different to 'Fix Released'.
<phillw> Arla: by rights, it should be marked invalid as it is for a release that is no longer supported. If you pop onto #ubuntu-bugs we can ask on there.
<phillw> anyone else awake on here to offer advice?
<phillw> Arla: I've asked... But IMHO without anyone saying otherwise, I'd suggest raising a new bug and refer to the old bug.
<jibel> Arla, Saucy has inkscape 0.48 and inkscape dev says it is fixed in r12698 which is not in Ubuntu. However the dev team has a PPA for Saucy where you can test inkscape trunk
<jibel> Arla, https://launchpad.net/~inkscape.dev/+archive/trunk?field.series_filter=saucy
<jibel> Arla, if you confirm it is fixed there, you can file a bug against Ubuntu and hope someone can cherry pick the upstream fix.
<jibel> phillw, the version of Ubuntu is irrelevant here, because it is an upstream project that uses launchpad as bug tracker.
<jibel> ie not a bug in a specific version of Ubuntu.
<phillw> jibel: I am currently watching a discussion on email about where to report 'upstream' bugs versus ubuntu bugs as per Policy: filing bugs against Ubuntu packages instead ofÂ upstreamÂ projects
<phillw> I await their decision, until then I asked the OP to seek advice from the bug team. If you have better knowledge, then please do share it with me and the OP :)
<Arla> jibel: I added the PPA and do apt-get install inkscape-trunk, but it won't install without removing gnome :s
<phillw> Arla: is that requiring that you delete all of gnome, or just the meta package?
<Arla> phillw: only meta package. is that safe?
<phillw> Arla: if it ends with -desktop, it is quite safe to remove. It can cause complications when up-grading to the next release; but by then you will have learned about making a seperate /home partition :D
<Arla> The following packages will be REMOVED: gnome inkscape
<phillw> Arla: as you wish to install the new one, that makes sense to me?
<Arla> phillw: inkscape being removed, yes. But the package "gnome"?
<phillw> Arla: I'm not a ubuntu user.... jibel is it safe for Arla to follow the remove?
<phillw> Arla: I'm a lubuntu user and we do know of that warning, which can be safely ignored. But, I am asking any other ubuntu user to check that it is safe to remove in ubuntu.
<phillw> I'm 99% sure it would be okay, as it will tell you what it wishes to remove. But there is that 1% doubt.
<Arla> I'm thinking that the worst thing that can happen is that I have to install that package again? That wouldn't be very disastrous.
<phillw> Arla: depending on what it says exactly, as long as you do not see a whole list of files (i.e. your entire system), then the removal of the meta link is not harmful.
<phillw> Arla: as long as you see something like https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveLubuntuDesktop then you will be okay.
<phillw> Arla: if ib any doubt, do ask on #ubuntu, this area is not a support area and the people on there are much more familiar with such things :)
<phillw> s/ib/in/
<Arla> phillw: It seems like the bug persists.
<phillw> Arla: then raise a new bug, but do reference to the old bug number.
<phillw> once you have the new bug raised, ask if someone can confirm it. As it seems to be upstream, then you need to go 'nag' them to get it fixed.... I'm banned from 'nagging', so do be careful how you phrase your 'nag'. :P
<Arla> :)
#ubuntu-quality 2014-11-24
<elopio> ping charles. Can you tell me a little about how the sound indicator knows if there is a headphone plugged in?
<brendand_> elopio, in the clock app autopilot tests, the bottom edge tip is not getting grabbed, even with the same code as address-book-app
<brendand_> elopio, if i put a sleep just before the drag action it works, so i think it's not getting time to reveal the tip
<brendand_> elopio, the address-book-app code waits for action_item.enabled
<balloons> oO.. I believe clock waits for focus
<elfy> hi balloons
<balloons> hai elfy
<balloons> I hit the forums this morning! it's been awhile!
<elfy> I saw
<elfy> :)
<balloons> you renamed the u + 1 subforum, took awhile to find it, haha
<elfy> ha ha ha
<elfy> balloons: we also don't close it post-release, it's been rolling for 3 releases now I think
<balloons> yes, I do remember that. Which is nicer. It was confusing to have threads be cut off as it where
<elfy> yea
<elfy> we do shut them if people turn up post release assuming it's a 'support' thread
<Letozaf_> balloons, hi
<balloons> Letozaf_, hello
<Letozaf_> balloons, do you think it would be ok to  take a look at gallery app and do the same for using the sample zip file I put in the content direcory for filemanager app ?
<Letozaf_> balloons, no matter, I think I found how to do it...
<balloons> Letozaf_, ok, sorry, a bit distracted :-)
<Letozaf_> balloons, no problem :)
<josharenson> What is the command to run a single unity8 qmltest? "$ make ?"
#ubuntu-quality 2014-11-25
<brendand> elopio, hey i have an autopilot test failing because the item it's looking for is off the end of the list - what's the best way to handle that? i remember something like swipe_into_view
<elopio> brendand: yes, that.
<brendand> elopio, but i suppose it relies on autopilot being able to 'see' that list item?
<elopio> brendand: look for the flickables module. It has some useful methods. And if the element is inside a flickable, it will have a method to do it too.
<brendand> elopio, is there an easy way just to say 'flick to the end of the list'?
<elopio> brendand: flickable.swipe_to_bottom
<elopio> brendand: there's some magic to search for the item if it's not already loaded in the QML.
<elopio> that needs an objectName for the item.
<brendand> elopio, swipe to bottom should be sufficient
<elopio> alesage: https://code.launchpad.net/~canonical-platform-qa/ueqa-code-proposals/indicator-sound-control_player/+merge/242805 please
<alesage> elopio cool will look at
<brendand> balloons, what do i need to do to coax ci tests to run here: https://code.launchpad.net/~brendan-donegan/ubuntu-clock-app/wait_for_bottomedgetip_visible/+merge/242792
<brendand> ubuntu-qa - review on https://code.launchpad.net/~brendan-donegan/reminders-app/test_add_notebook_must_append_it_to_list_swipe_to_bottom/+merge/242808 please
<elopio> brendand: um, there should be only one notebook.
<brendand> elopio, ?
<brendand> elopio, there's a ton of them
<elopio> brendand: each test should remove the notebooks it adds.
<elopio> they are left because there's something wrong with the cleanup.
<brendand> elopio, no the cleanup is fine
<brendand> elopio, but there's a whole bunch of notebooks there
<elopio> brendand: if the cleanaup was fine, there would be only one notebook.
<brendand> elopio, it failed in ci though
<brendand> elopio, where the test would only have run once
<elopio> some tests hang or something. Jenkins kills the instance, and the notebooks are not deleted. I suppose.
<elopio> brendand: this uses a real sandbox account. I have just cleaned the notebooks.
<brendand> elopio, ah i see
<elopio> brendand: I'm not sure your approach will work, because I'm not sure if the notebooks are sorted by date or by name.
<brendand> elopio, do you not think it should swipe to the bottom just in case?
<brendand> elopio, well the test is called 'append to list'
<elopio> brendand: as it should be only one, it won't hurt swiping to bottom.
<brendand> elopio, so if it doesn't append it then the test should fail
<elopio> brendand: right, I named that but I don't know if it goes to the tail.
<brendand> elopio, it does. obviously i tested the fix :P
<elopio> ok then. I had written it for only two notebooks.
<elopio> So +1.
<brendand> elopio, i can see now it's not absolutely necessary, but it would prevent failures in the case where the sandbox account has become corrupted
<elopio> brendand: yes. Agree. If you could keep an eye on it maybe we can improve the cleanup somehow.
<brendand> elopio, btw do you know what i need to do to persuade the ci tests to run on my MPs?
<elopio> brendand: I think you need to be part of a team.
<elopio> not sure which one. balloons or cihelp should know.
<brendand> elopio, maybe it's the team thomi just removed us all from :P !
<alesage> elopio I've added "request info" type comments; don't want to torture you but wanted some info :)
<plars> brendand: that's probably a ci help question on #ubuntu-ci-eng
<elopio> alesage: the headset test is here: https://code.launchpad.net/~canonical-platform-qa/ueqa-code-proposals/indicator-sound-high_volume_warning/+merge/242809
<elopio> we listed two during our meeting.
<elopio> the problem with that one is that I'm not yet able to make my prototype work.
<elopio> alesage: answering your questions in the MP...
<balloons> brendand, you need to be on the core apps qa team or the development team for the core app
<brendand> balloons, who can add me?
<brendand> balloons, thomi just removed canonical-platform-qa from it
<balloons> I can and yes, that was the intent
<brendand> balloons, so i guess we need to sign up individually
<balloons> I can add individually sure
<balloons> brendand, you are a core apps drivers now
<brendand> balloons, so i just wait now?
<brendand> elopio, did you see my comment on the location prompt merge?
<balloons> brendand, which mp?
<brendand> elopio, i can make it a fixture but i can't invest the time to put it in location service
<brendand> elopio, since that's the rabbit hole of cmake and packaging
<brendand> elopio, i did that once for url-dispatcher and i'd rather chew off my arm than do it again :)
<balloons> brendand, that said, https://launchpad.net/~ubuntu-touch-coreapps-test-writers/+members shows the platform team is a part
<elopio> brendand: that's the work man. I'm ok with you filing a bug and putting a comment on your code that it needs to be moved.
<elopio> but we need a way to give that bug a high priority.
<brendand> elopio, okay but who's going to address the bug?
<elopio> it's going to be needed by the scopes tests too.
<brendand> elopio, so for now make it a fixture and it can land?
<elopio> the clock, the weather, the rss, the camera, many webapps will be location-aware.
<elopio> brendand: yes, but lets agree that the next time it's needed, we won't copy it around.
<elopio> we'll find a place for it, and the only way for getting managers to assign some time for it is to leave the test failing.
<elopio> brendand: the url dispatcher is a case of success. We simplified the tests in dialer, messaging, unity and UX thanks to that one. Chewing your arm is not as good :)
<brendand> elopio, we don't have to land it right now if you think it will expidite the 'proper' fix
<brendand> elopio, heh - you didn't have to do it !
<elopio> actually, I think the dialer is not yet updated.
<elopio> brendand: no, lets land it. Please file the bug. Then next time we hit it, we will have the code working, and good evidence of why it needs to be moved.
<elopio> brendand: I know! You did it and I appreciate that. It should have been ted. That's the kind of thing we are documenting this week, an in theory all the managers have agreed to implement test helpers in their projects.
<elopio> brendand: in your bug, please mention that when the fixture is moved it will need a test.
<elopio> something like a simple qml app that only requests location, to check when the fixture is enabled and disabled.
<elopio> brendand: oh, and one more detail. Please don't use print. Use the logger.
<brendand> elopio, sure
<balloons> brendand, jenkins is running for your stuff now
<balloons> should be automagic
<elopio> brendand: well, two details. Also please be consistent using the single and double quotes for strings.
<elopio> for consistency with the rest of projects, use '
<alesage> elopio, here's this for you to tinker with slash fix https://code.launchpad.net/~ueqa-projects-team/ueqa-code-proposals/indicator-network/+merge/242826
<alesage> elopio I'm going to try the mac80211_hwsim hack now
<elopio> cool. thanks alesage
<balloons> hallo doug5
<doug5> balloons, hello!
<balloons> doug5, how are you?
<doug5> balloons, great! you?
<doug5> balloons, I'm actually trying to understand an error in calendar app
<doug5> http://paste.ubuntu.com/9237601/
<doug5> ever seen? Otherwise I'll contact mihir
<balloons> I'm doing well
 * balloons looks
<balloons> doug5, ahh yes that's a common error
<balloons> hence the link given :-) http://developer.ubuntu.com/api/devel/ubuntu-14.10/python/autopilot/faq/troubleshooting.html
<balloons> anyways, specific to that error, let's look at the test
<balloons> basically it means the test didn't find the object. That most likely means a timing issue. You tried to get the object before it existed
<doug5> but it's the fresh checked out source code
<doug5> strange
<balloons> doug5, yea, that simply means it probably wasn't accounted for when the test was created
 * balloons blames the original author.. which is of course balloons
<balloons> anyways, let's fix it. Do you understand why the error is happening?
 * balloons runs test to have a look
<balloons> so actually doug5 the first thing I do to troubleshoot if it's a timing thing (which I assumed it was) is to add a sleep before the failure. In this case that did not help. Instead, it's likely the object itself is no longer present, or has been renamed
<doug5> balloons, yes that's my guess to
<balloons> doug5, so if I manually run calendar I can see the UI selector for calendar is indeed missing
<doug5> I think we can remove this check
<doug5> no?
<balloons> I think it's an open question for the devs, but yes for now we can certainly remove it
<balloons> with it removed, everything passes and you should be able to carry on with the other checks
<doug5> I noticed I cannot also add the event
<doug5> file:///home/acerisara/Projects/ubuntu-calendar-app/NewEvent.qml:167: TypeError: Cannot read property 'collectionId' of undefined
<balloons> doug5, you are right.. seems quite odd
<balloons> I know they changed that screen around; I wonder if we are missing a depends or something
<balloons> it seems rather odd it would be broke in trunk like that
 * balloons installs all listed depends
<balloons> doug5, that's the issue, things look correct for me now, including the calendar
<balloons> doug5, I installed qmlscene qtdeclarative5-quicklayouts-plugin qtdeclarative5-ubuntu-ui-toolkit-plugin libqt5organizer5 qtdeclarative5-qtorganizer-plugin qtorganizer5-eds qtdeclarative5-ubuntu-syncmonitor0.1 libqt5contacts5 qtdeclarative5-qtcontacts-plugin qtcontact5-galera
<balloons> that came from the debian/control file
<doug5> let me try
<doug5> balloons, yes...way better indeed :) thx
<balloons> doug5, lol, see trunk wasn't broken after all.. just us :-)
<balloons> at least we still have our sanity!
<doug5> balloons, that's an excellent new actually :D
<doug5> *news
<elopio> veebers: alesage: pushed the changes. Do you want to take a look or should I merge to trunk?
<alesage> elopio, PUSH
<elopio> veebers: alesage: thomi: merged.
<doug5> balloons, ok, changes are done :) tomorrow I will review and create the mr
#ubuntu-quality 2014-11-26
<Saviq> hey all, I've been trying to move our qml tests to adt, wanted to use schroot for local adt runs
<Saviq> but it fails for a somewhat cryptic reason for me: http://pastebin.ubuntu.com/9251865/
<cgoldberg> happy early Turkey-Day to all 'muricans !
<cgoldberg> davmor2, sup dude.. how goes it?
<davmor2> hey dude good thanks how's you
<cgoldberg> davmor2, i'm good thanks.  running Ubuntu on a shiny new MacBook Retina :)
<davmor2> cgoldberg: nice was it an early turkey day present
<cgoldberg> davmor2, nah.. it's my work rig... everyone I work with uses MacOS... but we deploy on Ubuntu servers.. so I paved my MacBook and installed Trusty
<davmor2> nice and shiney
<balloons> Saviq, if you haven't I'd ping pitti on th+e errors. Also, what version of autopkgtest do you have?
<balloons> cgoldberg, happy turkey day to you as well!
<cgoldberg> balloons, thanks.. im gonna eat like a champ tomorrow
<alesage> balloons, speaking of black friday, and shiny hardware, is it true you compute on a chromebook?  considering one for myself
<Saviq> balloons, 3.8, and yeah, I'll try and grab pitti tomorrow
<balloons> alesage, I've used chromebooks for quite some time, but my last purchase was not a chromebook
<balloons> I had the first retail unit and the follow-up one, both samsungs. I like them both. My favorite laptop keyboard is on the one I still have, which the wife uses
#ubuntu-quality 2014-11-27
<Saviq> pitti, hey, does this adt-run(schroot) error mean anything to you http://pastebin.ubuntu.com/9251865/ ?
<pitti> Saviq: I'm afraid not; if you can reproduce it, would you mind filing a bug with reproduction instructions?
<pitti> Saviq: apparently it did copy up teh stderr file from the testbed (line 20 in pastebin)
<pitti> so I'm not sure why it's missing
<Saviq> pitti, another thing is that it didn't drop me to shell, even though I asked for it
<pitti> Saviq: yeah, as it got that unexpected error
<pitti> Saviq: the "drop into shell" happens after displaying stderr
<Saviq> pitti, ah
<Saviq> pitti, any package in particular I could use to verify that it's not my packages' fault?
<pitti> Saviq: my preferred guinea pig is usually d-conf or libpng
<pitti> Saviq: as they are fast
<Saviq> pitti, ok
<pitti> adt-run libpng --- schroot sid
<pitti> Saviq: but it doesn't matter much
<pitti> Saviq: so, this is definitively not the "fault" of your package, it might just trigger something funky
<Saviq> pitti, yup, understand
<pitti> Saviq: have you used the schroot runner before?
<Saviq> pitti, no, I've been setting up proper for adt for the first time, qemu runner seems to have worked better, but I got schroots laying around for sbuild so thought would use those
<pitti> Saviq: yeah; I use them all the time, so I rather suspect that you and I have some slightly different schroot setups
<Saviq> pitti, hmm same happens with libpng
<pitti> and schroot is used in production on ci.debian.net, too
<Saviq> pitti, I wonder, eatmydata or something
<pitti> yeah, I suspected as much (not package specific)
 * Saviq drops the custom commands from schroot
<pitti> Saviq: can you try --- ssh -d <schroot_name> to get debug information from the schroot runner?
<pitti> Saviq: does that happen with other schroots? or just unity8-amd64-shm
<Saviq> pitti, all of them
<Saviq> pitti, you mean schroot -d, no ssh -d?
<pitti> Saviq: err yes -- autofinger
<Saviq> pitti, http://paste.ubuntu.com/9265598/, that's from `adt-run libpng -d --- schroot -d vivid-amd64`
<Saviq> pitti, here's my schroot config, tried without command-prefix, same thing... anything springs to mind http://paste.ubuntu.com/9265616/ ?
<pitti> Saviq: hm, perhaps the eatmydata; it might not flush the stderr file to disk (especially not when it's a 0-byte file) early enough?
<pitti> Saviq: otherwise my sid schroot uses overlayfs and directory, too
<pitti> (most of my other schroots are tarballs)
<Saviq> pitti, yeah, I tried to drop the command-prefix, didn't help
<Saviq> weeird, /me will create a new chroot
<pitti> Saviq: in /usr/share/autopkgtest/python/VirtSubproc.py could you apply http://paste.ubuntu.com/9265758/ and see if that helps?
<pitti> Saviq: i. e. if it's some kind of file system race, or some logic error
<pitti> (this isn't a proper solution of course, just a quick test)
<Saviq> pitti, same thing I'm afraid
<pitti> Saviq: ok, that makes it more likable :)
<pitti> Saviq: ooh! libpng also failed for you, right?
<pitti> Saviq: can you please try this:
<pitti> schroot -c sid -u root -- su -s /bin/bash  -c 'whoami'
<pitti> erk
<pitti> schroot -c vivid-amd64 -u root -- su -s /bin/bash michal -c 'whoami'
<pitti> Saviq: ^ this
<pitti> Saviq: i. e. maybe it's the su itself which fails (can't resolve your user name), this would explain why the -stdout/err files are not created and libpng fails
<Saviq> pitti, it returned my uid
<Saviq> "michal"
<Saviq> s/uid/username/
<pitti> Saviq: ack, so that one works
<pitti> schroot -c vivid-amd64 -u root -- su -s /bin/bash michal -c 'set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  . ~/.profile >/dev/null 2>&1 || true; whoami'
<pitti> Saviq: ^ can you try this?
<Saviq> pitti, retcode 1
<pitti> a-haa!
<Saviq> ;)
<pitti> schroot -c vivid-amd64 -u root -- su -s /bin/bash michal -c 'set -ex; export USER=`id -nu`; . /etc/profile >/dev/null || true;  . ~/.profile || true; whoami'
<pitti> Saviq: ^
<Saviq> pitti, works
<Saviq> pitti, ah
<Saviq> pitti, byobu
<Saviq> daaamit
<Saviq> pitti, yeah, it's byobu
<Saviq> if I disabled byobu in my session, it's all back in order
<pitti> Saviq: ah, interesting; that hooks itself into ~/.profile?
<Saviq> pitti, yeah
<Saviq> _byobu_sourced=1 . /usr/bin/byobu-launch
<Saviq> is what it adds
<pitti> Saviq: ah, I wonder if that should only be done on interactive shells
<pitti> Saviq: so apparently the || true for sourcing doesn't work as it should? what did you see when you ran this command without the stdout/err redirection?
<Saviq> pitti, http://pastebin.ubuntu.com/9266194/
<Saviq> pitti, I'll talk to Dustin on that, thanks for the interactive debugging session
<pitti> Saviq: interesting, thanks; could you still file a bug about it, please? it seems ". file || true" doesn't work
<Saviq> pitti, yup, will do
<pitti> cheers
<Saviq> pitti, bug #1396955
<ubot5> bug 1396955 in autopkgtest (Ubuntu) "adt-run fails in schroot if sourcing ~/.profile fails" [Undecided,New] https://launchpad.net/bugs/1396955
<pitti> Saviq: cheers
<doug5> can someone trigger a build of this? http://91.189.93.70:8080/job/ubuntu-calendar-app-ci/
#ubuntu-quality 2014-11-28
<senan> balloons :hi
<balloons> senan, hello
<senan> balloons : is there anyone working on deja-dup ?
<balloons> senan, too me a second.. How are you ? :-)
<balloons> senan, no, the bug should show if anyone is working on it or not, but to my knowledge no one is
<senan> balloons : I'm doing great.. thanks for asking.. Expecting a work permit in sweden..If eveything goes well will fly january mid
<senan> balloons. How are you :)
<balloons> senan, sweden is lovely, I hope it all works out for you
<balloons> senan, yesterday was thanksgiving, so enjoying leftovers and feeling full ;-)
<senan> balloons : Ohh you are living in US ?
<balloons> senan, yes indeed
<senan> balloons, I thought all the canonical team is in UK
<senan> balloons, have one doubt in that.. the manual test case shows only one scenario . Is that enough ?
#ubuntu-quality 2014-11-29
<doug5> balloons, thanks for comment, I'll fix it soon :)
<doug5> *the
#ubuntu-quality 2015-11-23
<balloons> Good morning!
<flocculant> hi balloons
<balloons> hi flocculant
<balloons> bdmurray, morning. Did you want to go ahead and add some tasks for the quality scripts?
<bdmurray> balloons: yes, when is that due?
<bdmurray> balloons: Can you add me as a mentor so I can add that task?
<balloons> bdmurray, yes, ofc. Sorry, I meant to get back to you on this :-)
<balloons> the contest opens Dec 7th, but tasks can be added even after that. Still, Dev 7th is a good date to have it ready for
<balloons> I've added you as a mentor
<bdmurray> balloons: thanks
#ubuntu-quality 2015-11-24
<hggdh> /join/join #lxcontainer
<brendand> elopio, hi
<elopio> brendand: hello. How are you?
<flocculant> afternoon quality people :)
<flocculant> balloons: bug 1189621 - do we really need that testcase hanging about?
<ubot5> bug 1189621 in Ubuntu Manual Tests "tests 1317 is a stub" [Undecided,New] https://launchpad.net/bugs/1189621
<flocculant> also bug 1519417
<ubot5> bug 1519417 in Ubuntu Manual Tests "Wubi testcases" [Undecided,New] https://launchpad.net/bugs/1519417
<balloons> for 1189621, yes, it's a stub for jenkins tests, and is desired
<balloons> well, some people desire it :-
<balloons> re: wubi, I remember us removing those tests. ?
<flocculant> well they are still there :)
<flocculant> balloons: unless you mean remove from testsuites - I mean remove them from the project
<flocculant> bug 1268942 just needs bluetooth adding to an ubuntu testsuite - or if you don't want it testing marking accordingly :)
<ubot5> bug 1268942 in Ubuntu Manual Tests "bluetooth testcase missing in ubuntu" [Medium,New] https://launchpad.net/bugs/1268942
<balloons> flocculant, I'm happy to do both for wubi
<balloons> remove it from all
<flocculant> ok I'll do that now
<flocculant> balloons: mmm ok - done the code side, I don't appear to be able to delete those 3 tests from http://iso.qa.ubuntu.com/admin/config/services/qatracker/testcases however
<balloons> flocculant, well you can't delete anything, just disabl
<balloons> so i would edit the 2 testsuites and disable them
<balloons> which i've done
<flocculant> ok cheers :)
<flocculant> just had a bit of time today to look at bugs and the code :)
<flocculant> if we can clear bugs a few at a time it'll get cleared by 18.04 :D
<flocculant> balloons: btw studio have a qa guy now, who's trying to get the testcases dealt with https://lists.ubuntu.com/archives/ubuntu-studio-devel/2015-November/007124.html
<balloons> flocculant, 18.04, new goal!
<balloons> dobey, turns out my post to ubuntu-devel-announce was rejected
<flocculant> always have to have goals :p
<dobey> balloons: because you're not one of the cool kids?
<balloons> dobey, clearly
#ubuntu-quality 2015-11-28
<sethj> is there a bug where unity doesn't show recently installed applications without a reboot or is it just me?
<flocculant> sethj: I did read something somewhere like that, but as I Xubuntu and don't Unity - I don't remember much else
<flocculant> but you're not alone :)
<sethj> aha, I found it:
<sethj> https://bugs.launchpad.net/unity/+bug/1516527
<ubot5> Ubuntu bug 1516527 in unity (Ubuntu) "New Programs Not Shown In Start Window Until After A Reboot" [Undecided,Confirmed]
<flocculant> phew - glad it wasn't just my memory playing tricks :p
<sethj> haha. really frustrating bug.
<flocculant> I bet it is :)
<sethj> I edited the title so it would be found better. initial reporter didn't know the proper names for Unity's UI elements.
#ubuntu-quality 2016-11-29
<flocculant> anyone seen the installer changing the size of extended partitions ? bug 1638639
<ubot5`> bug 1638639 in ubiquity (Ubuntu) "Installer trims unallocated space from extended partition" [Undecided,New] https://launchpad.net/bugs/1638639
#ubuntu-quality 2016-11-30
<flocculant> I guess not then :)
<flocculant> cyphermox: you ever seen mention of ^^ ?
<flocculant> not sure if the bug is ubiquity or something else tbh
<cyphermox> flocculant: not just due to alignment?
<flocculant> mmm not sure
<flocculant> all I know is I make the extended the whole drive - the installer changes it
<cyphermox> ok
<cyphermox> I will look, but I need to take care of a shim issue first
<flocculant> yea - that's certainly more important - especially given I've seen no other mention of this at all - anywhere :p
#ubuntu-quality 2017-11-27
<tsimonq2> Does anyone have a UEFI machine that would be willing to do some Lubuntu testing?
<tsimonq2> We're facing a bug and I have 0 UEFI machines
<gQuigs> tsimonq2: you can setup EUFI in virt-manager/qemu pretty easily -  I just updated the docs the other week - https://wiki.ubuntu.com/UEFI/OVMF
<tsimonq2> gQuigs: Oh cool, thanks!
<gQuigs> if it needs to be on physical hardware and doesn't require an install - I can do it after work hours
<tsimonq2> Ok
#ubuntu-quality 2017-11-30
<TarsOn> Can`t get a correct download link from tha QA Tracker
<wxl> explain
<TarsOn> mean package testing
<TarsOn> no link shown after click Zesty or Yakkety Daily
<wxl> i found a PlusOne wiki page that says dch -R, dch -r, dpkg-buildpackage -S
<wxl> oops wrong channel
<wxl> what page are you on?
<wxl> cd /ts
<wxl> i found a PlusOne wiki page that says dch -R, dch -r, dpkg-buildpackage -S
<TarsOn> http://packages.qa.ubuntu.com/qatracker/milestones/361/builds/117788/downloads
<wxl> oh heh
<wxl> i didn't realize you said daily
<wxl> they're not in testing
<wxl> also wait
<wxl> are you supposed to be on the package tracker?
<wxl> cuzzzzzzzzzz i'm not even sure anyone uses that tbh
<TarsOn> I just don`t know ...what to start on
<wxl> iso.qa.ubuntu.com
<wxl> go run some tests on bionic daily
<TarsOn> wanted to do smth useful)
<TarsOn> ok, thx
<wxl> ^^ that would be useful. then report bugs.
<flocculant> package tracker gets used if someone wants to :)
<flocculant> wxl: while you're about - did you think more about the iso stuffs?
<flocculant> to be honest - not sure which iso tests you think are just lubuntu
<wxl> flocculant: yeah, actually, but i stepped back a bit. i think the bug i'm going to propose is how we deal with needing to test both UEFI and non-UEFI boots
<flocculant> ok - that's a different kettle of fish :p
<wxl> yeah
<wxl> i mean UEFI problems were why i wanted to make some changes so i kept asking questions until i had backed myself off enough :)
<flocculant> biggest problem in my opinion is getting people out 'there' to test things more
<wxl> i know
<flocculant> ha
<wxl> that's the thing i was really struggling with
<wxl> because in order to have proper coverage, we nede to double our workload as far as testcases are concerned
<flocculant> that has was to your backing yourself out btw
<flocculant> wxl: how so?
<wxl> well i guess we'll deal wit hthis in the bug but if we have testcase 1, 2, and 3, to ensure they all behave well with both UEFI and legacy booting, we need to have 2 sets of them
<flocculant> mmm maybe - how much difference is there?
<wxl> does anyone actually know? :)
 * flocculant has pc that could obviously do uefi if he wanted - but it's all turned off
<flocculant> I don't - never installed with uefi
<wxl> well more and more people are expecting it
<flocculant> then people who expect it, should put up then
<wxl> XD
<flocculant> which is down to community communication - so I'll leave it with you :D
<flocculant> best I could do (afaik) is kvm emulation
<wxl> yeah vbox does it too
<flocculant> right
<flocculant> mmm ... think I'm missing a package
<flocculant> lol - qemu efi ... 1842kB will be downloaded ... 136MB of extra space will be used
<flocculant> will try again tomorrow - got an error doing that uefi/qemu thing, likely something needs restarting - but I've been up for 18 hours now so time for bed :)
<flocculant> wxl - anyway we can talk again about this if you want - some other time :)
#ubuntu-quality 2017-12-03
<Ravi_> Is Ubuntu using autopilot tests now?
<Ravi_> Can I contribute to the tests?
<tsimonq2> Ravi_: I don't know about autopilot but if you really want to do that specifically, try #ubports.
<tsimonq2> Ravi_: Otherwise we have https://autopkgtest.ubuntu.com/ with some sad stuff.
