/srv/irclogs.ubuntu.com/2014/07/08/#ubuntu-quality.txt

=== Ursinha-afk is now known as Ursinha
=== _salem is now known as salem_
=== chihchun is now known as chihchun_afk
=== salem_ is now known as _salem
ePierreHi!04:20
Noskcajhello ePierre04:22
ePierreliving in Asia, I often feel I'm in the bad timezone :D04:37
NoskcajePierre, A bitnorth of me, but probably a similar timezone (I'm AU)04:42
ePierre12:43PM here04:43
ePierreMelbourne?04:44
Noskcajsydney04:53
ePierreNice!05:00
pittiGood morning05:52
=== vrruiz_ is now known as rvr
davmor2Morning all09:32
ePierrehey davmor2  :)09:37
om26erubuntu-qa could anyone please review this https://code.launchpad.net/~om26er/address-book-service/test_dummy_service/+merge/22584612:45
=== _salem is now known as salem_
brendandom26er, looking12:50
brendandom26er, address-book-service has no ui, so you can't use autopilot to test it12:56
brendandom26er, why do you need to have an -autopilot package? is it to distribute the helpers so that other tests can use them?12:57
om26erbrendand, the service provides a dummy backend, it needs to be tested on a real app, so I had to use address-book-app to verify that. But really I am writing those tests to be able to produce reusable helpers for the UX test12:59
om26erbrendand, the important part is in fixture_setup.py13:00
brendandom26er, what's the reason not to have the helper in address-book-app?13:00
om26erbrendand, a bad change in the service can make the dummy backend stop working and we won't know if it did. only when the UX test starts failing13:02
om26erbrendand, I am testing the service, not the app.13:05
brendandom26er, then by all means add a test for the service, but you don't need to package it in an autopilot package13:05
brendandom26er, if you're packaging it then you must intend for other tests to use part of it?13:05
om26erbrendand, the test have dependencies and it needs to run in the CI13:06
om26erbrendand, yes, other tests will use most of the code13:06
om26erre-use.13:06
brendandom26er, i don't think tests have to be in an autopilot package in order to run in CI13:07
om26erbrendand, whats you suggestion ?13:08
brendandom26er, first of all can the test for address-book-service itself, and the helper code that might be used in other places be seperated?13:10
om26erbrendand, the helper code sets a few environment variables and restarts the service so that the dummy backend of the service is started.13:15
om26erbrendand, you mean in two different branches or in two different projects ?13:15
om26erthe helpers can live anywhere but they belong to the service, as the fixture is trying to start the dummy service.13:15
brendandom26er, i think the helpers belong in address-book-app actually13:16
brendandom26er, because they are useful for tests that test the address-book-app13:19
om26erbrendand, how ? address-book-app, messaging-app and the dialer-app all use address-book-service. The service provides contacts, what these helpers are doing is they start the service with a certain vcard so that *any* app that uses these helpers can be fasciliated13:19
brendandom26er, btw have you checked how this helper overlaps with the one that's already there in ubuntu-experience-tests (but about to be moved to address-book-app)?13:21
brendandom26er, that allows the running address-book-service to be interacted with13:22
om26erbrendand, I did look at those helpers in ubuntu-experience-tests. What they are doing is they add/delete contacts live on the service. The developer of address-book-app guided us against that a few months ago and implemented this dummy backend for us13:23
om26erand I thought they were not being used by any UX test ?13:24
brendandom26er, but for experience tests do you think it's a good idea to use dummies/mocks?13:24
brendandom26er, we're supposed to be testing the whole system13:24
brendandom26er, for the address-book-app autopilot tests it's different, since we're only testing the app itself13:25
brendandom26er, the tests that are using it haven't been merged yet - it was specifically merged so that it could be shared between myself and rhuddie's tests13:26
om26erbrendand, I do agree to that but half, adding a contact from an API is not the same as a user would add it from the UI :)13:27
om26erbrendand, I can halt my branch for now, it can probably be used for integration testing in future.13:28
brendandom26er, maybe not, but you need to try and limit the scope of the test somehow13:28
brendandom26er, also using the ui to setup prerequisites makes for large and unmaintainable tests13:29
brendandom26er, i see some people are doing that though13:29
om26erbrendand, the test I am working on has to interact with unity to launch app, messaging-app for sending the messaging and the address-book-service to reveal a contact to send the message to.13:32
brendandom26er, we should definitely have a standard way to launch an app via unity, otherwise it will be a mess13:33
brendandom26er, currently i'm not doing that but i would if there was a straightforward helper to use13:33
om26erbrendand, I created one, you can use it when it gets merged.13:33
om26erits starting app from the launcher13:34
brendandom26er, and unless your test cases is actually about creating a contact, i don't see the problem with doing it via the service13:34
brendandom26er, a test case will nearly always have some prerequisites, and these should be created/configured in the most straightforward way possible13:35
om26erbrendand, so you suggest I use the helpers from ubuntu-experience-tests to add a contact ?13:35
brendandom26er, let me move them to address-book-app (although you can start, because not much will change on using it except the import)13:36
balloonsyou were busy pitti :-)13:48
pittiballoons: hehe, yes; good morning!13:49
balloonsgood morning. I tried to follow along with the emails as you went through things. I agree that my original timeline was the same as yours, I figured we'd move over a slightly longer period ;-)13:50
pittiballoons: yeah, I was a bit paniced by the "by tomorrow" thing :)13:51
balloonsyea, it was EOD for me and thomi started asking about it.. I mentioned that we finally had a solution and I was going to start working towards implementing it13:52
pittiballoons: so I think autopkgtest has the necessary functionality there (maybe a few beautifications)13:52
balloonsyes, I played long enough last night to confirm that.. I think I agree. It's a bit rough still, but definitely seems to work13:53
pittiballoons: so it would be nice if you could update and land your calendar MP13:53
balloonsso, I like the new syntax for depends. much nicer13:53
pittiballoons: and we need someone to fix notes-app13:53
pittiballoons: yeah, and no magic semantics13:54
pittiI mostly added the "autopilot": "foo_tests" to be compatible with existing apps13:54
balloonsso, wow.. you were able to mark everything else invalid, really?13:54
pittiballoons: yes, I ran through them all :)13:54
pittikept my phone busy this morning13:54
balloonsthat's really surprising13:54
pittiwhy?13:54
balloonswell... I suppose not really surprising, heh. We've moved most things into the toolkit13:55
balloonshekoer13:55
balloons*helper13:55
pittiballoons: but NB that these are only the clicks we install by default; the store has many more :)13:55
balloonsofc ofc13:55
pittibut I suppose the default click apps are what matter for image verification etc.13:55
balloonsyep13:55
balloonsso, my other thoughts are to cleanup the debian packaging for the -autopilot packages13:56
pittiballoons: hah, new autopkgtest just got promoted to utopic13:56
balloonsthey are a bit broken too.. but I'll leave it alone13:56
pittiballoons: yeah, we can drop them all once we moved CI over13:56
balloonspitti, ohh, on the subject, are you going to backport to trusty?\13:56
balloonsautopkgtest that is13:56
pittiballoons: I can issue a backport request, yes; until that lands you can just use the deb from utopic13:57
pittiin the lab (for production autopkgtest) I just run straight out of git, which makes deployment of fixes dead easy13:57
balloonspitti, I thought the deb would work straight up.. Many of the developers still use trusty, with a utopic vm13:57
balloonsI told them to install the deb and linked it, but lol, last time I did that I sent them on a goose chase breaking there system so they didn't believe me ;-)13:58
pittioh, really? it's a bit tricky on precise as there's no python3-debian yet; but on trusty it should just work13:58
pitti(I have a locally built precise backport for python3-debian for our friends in CI)13:59
balloonswell.. I'm sure it works fine. I've had them play with newer versions of the toolkit and autopilot before.. those are more connected and what broke things in the past for them13:59
balloonspitti, link to the lp built deb? my local mirror is slow14:01
balloonsautopkgtest - 3.1git1 that is14:01
pittiballoons: http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_3.1git1_all.deb14:01
balloonsty14:01
rvrpitti: ping me when you are free14:01
rvrpitti: (I'm vrruiz :)14:02
pittiah, I just /whois'ed :)14:02
pittirvr: better just ask your question, I'm swamped in things anyway :)14:02
rvrpitti: I asked you yesterday to meet to check the problem I have with a test (dbusmock with callbacks)14:03
pittirvr: ah, anything I can look at for this?14:04
rvrpitti: Hangout? I think it will be faster to introduce you to the problem14:04
pittirvr: sure14:04
rvrOk, let me create it14:04
pittirvr: you aren't logged in14:05
rvrpitti: Details sent14:28
pittirvr: so I wrote http://paste.ubuntu.com/7765896/ now, and it's completely invisible to "gdbus call -e -d com.example.DeepThought -o / -m com.example.DeepThought.Answer"14:31
pittirvr: back in 15 mins, then I'll look at that14:33
rvrpitti: ok14:33
balloonspitti, sent you a mail with a few follow-up responses to my questions. I'll discuss once you've read ;-)14:33
rvrHmm14:37
pittirvr: so, neighbor cat is fed and caressed, continueing :)14:47
rvrlol14:47
rvrpitti: I tested your code here14:47
rvr$ python3 dbus-cb.py14:48
rvrDeepThought: method Answer called, will succeed14:48
pittiballoons: replied15:02
pittirvr: it fails with 1/3 probability and succeeds with 2/315:02
pitti(just to test both the error and success callbacks)15:03
rvrSometimesFlakyDeepTought :)15:04
pittiyeah, much more realistic that way :)15:04
jibelbrendand, about your mtp transfer test, how is the file transferred from the device? via ssh xxxx@xxx "cp /<mtp address>/<filename> <local path>", correct ?15:04
balloonspitti, ok, I just proposed something for notes, but trying to run it with the new click= isn't working15:04
brendandjibel, essentially15:04
pittiballoons: oh, how so?15:05
balloonsalso, can you approve https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/autopkgtest/+merge/225910?15:05
jibelbrendand, okay. so ssh doesn't have any active role in the transfer other than driving the host?15:05
brendandjibel, exactly15:07
brendandjibel, it's ssh not scp :)15:07
jibelbrendand, yeah, just confirming :)15:07
pittiballoons: done15:07
balloonspitti, I can send the log and how I'm running.. one sec I'll paste15:08
balloonshttp://paste.ubuntu.com/7766046/15:08
jibelbrendand, I think the test should just verify that the file is there and not corrupted like same checksum on both sides and that's good enough15:08
brendandjibel, good idea15:09
pittiballoons: ah, hah; it's --click=15:09
jibelmaybe test with different sizes of files too, lot of small, 1 big ...15:09
pittiballoons: or --click com....15:09
* brendand wonders how to hash several files together15:09
pittibrendand: funny, it's trying to interpret this as a source package name, and apt-get source interprets the =... as a  version to download15:10
pittibrendand: cat file1 file2 | sha1sum ?15:10
pittiballoons: but if you fixed the Exec=, don't you need to rebuild the click and test that instead of the preinstalled one?15:11
brendandpitti, cool. i didn't know sha1sum took stdin - i probably should have expected it though :)15:11
pittibrendand: welcome to Unix! :-)15:11
brendandpitti, yeah but you know you can't always assume X tool is going to be compliant. something as fundamental as sha1sum ought to be though i guess15:13
pittiballoons: oh, so that -I doesn't even come from ubuntu-app-launch and that broken Exec= line, but from the test itself?15:13
pittibrendand: regardless of that, I suppose the bogus $@ and the -I should be fixed in CMakeLists as well?15:14
balloonspitti, ohh, haha.. --click :-) Trying again15:14
pittiballoons: yeah, it's a bit nasty to fit all the different use cases into a concise CLI syntax, and bare identifiers are already taken for apt sources :/15:14
balloonspitti, yes, it's coming from the test itself.. The test controls how the app is launched15:14
pittiballoons: and as apt source names can contain '.' there is no solid way to tell apart a click and an apt source name15:15
pittinor are click packages required to contain dots15:15
balloonspitti, right.. completely reasonable15:15
pittiso I iniitally thought about click:foo.bar15:15
pittibut it's not really simpler than --click=foo.bar15:15
balloonsso, tests seem to be running now15:16
pittiballoons: so I like your idea of wrapping it in click-buddy, or phablet-test-run, or whatever15:16
pittiballoons: btw, '--- \ssh '15:17
pittiballoons: that \ is just to escape a line break; apparently the shell gracefully handles/ignores it here :)15:17
balloonspitti, ohh, btw, for the store clicks, I found out it's coming in a few weeks, but you'll have to be logged in to get them15:17
pittiballoons: ok, so I guess for now I'll completely ignore this and demand that you either have it installed or have the .click locally15:18
pittiand let the retrieval be an SEP :)15:18
balloonspitti, yea I assumed the --- \ stuff was to handle some shell weirdness15:19
balloonsI discovered that when I left an additional space and it blew up :-)15:19
pittiballoons: I just put that into the documentation as they span two lines15:19
pittiwhich looks nicer than one long one, and separates the tests from the testbed args15:19
pittiballoons: one thing to make the command line shorter is to implement automatic source retrieval from the vcs-* manifest fields, but I haven't done that yet15:20
balloonsso, since we are calling conventions, there's a couple other things to discuss. Could we give a reference to an lp branch?15:20
pitti(it would also slow down the test run quite a bit, though)15:20
pittiballoons: yeah, not sure about that yet; I'd have to teach it about bzr, git, hg and what not (as this should also work for Debian packages then)15:21
balloonsalso, is it necessary to pull the entire branch, or could we simply just copy in the tests/autopilot directory?15:21
pittiit depends on the test metadata15:22
pittiif it only has one "autopilot" test or only autopilot_module tests, then yes15:22
pitti(and not DEP-8)15:22
balloonspitti, the idea being I could specify a branch and have it do everything; as it stand if I want to run a whole suite of these I need to branch all of them15:22
pittiballoons: right, for that case automatic --click-source retrieval through vcs-* would help indeed15:22
pittiand then something like checkout --lightweight15:22
balloonspitti, right.. so that should handle the image verification case then I'd think15:25
pittiballoons: yes, something like adt-run --click foo --click bar --click baz --- ssh ..15:26
balloonsthe other half is the app developer workflow.. I think being able to re-use the temp directory would be helpful. Ohh that reminds me of what I was going to say15:26
pittiwithout the interspersed --click-source15:26
pittiballoons: apt-get without apt-get.. :)15:27
balloonspitti, yes indeed!15:27
pittiwith a writable image this wouldn't be a problem15:27
pittiand we can't write to anywhere permanent15:27
pittiperhaps $HOME/.cache/15:27
pittibut then this leaks into other test, shadowing that your test misses test deps, so it shoudln't be done by default15:28
balloonspitti, so in theory if you unpacked the depends into /home/phablet/autopilot as is done now, because autopilot is on the image, etc, that would emulate how I test now.. aka, not requiring setup each time15:28
pittiballoons: well, you don't know which package versions you unpacked, whether there are updated versions, etc.15:28
balloonspitti, yes, it would be a non-clean env15:28
pittiI'm not going to rewrite half of apt15:29
pittiif we want apt, let's use apt; developers can use r/w15:29
pittianything permanent without proper version tracking etc. is going to introduce potential bugs15:29
=== salem_ is now known as _salem
balloonsyep, totally. I'm just thinking through how we can adopt a best practice from what's happening now15:30
pittiballoons: btw, a lot of the packages will disappear once libautopilot-qt will stop installing python2.7 and all those python 2 libs15:30
pittiballoons: and I hope in the medium term we'll get a better way of bringing the apt and click worlds together15:30
pittimvo had some nice ideas about that15:30
pittiand it's like the #1 problem for convergence15:31
balloonsthe slowness of the testruns is a small price for the robustness. As it stands, most folks can't easily run tests due to hitting those hidden errors (bad env, missed depends, outdated depends)15:31
pittilike, system image plus a chroot for apt, and then permanently extending $PATH and friends15:31
pittiballoons: so, let's land the python2 sectomy fast, and jdstrand just told me how to shave off that minute for aa-clickhook15:32
balloonspitti, right.. once that's done the setup should be rather minimal15:32
balloonsand nothing ever stops me from just pushing my tests and calling autopilot manually.. I can be my own tool if I wish for some reason :-) This brings sanity to the world15:33
pittiFWIW, "bzr checkout --lightweight" is surprisingly fast15:33
pittiballoons: right, or --shell15:33
pittior -s15:33
pittiballoons: or running your tests in an LXC container, which is so much faster :)15:34
balloonsso I think I'm pretty happy. Really we are left with working on making  invoking the testrun to be easier. Ohh, there is one thing I'm not thinking about..15:34
balloonsHow can I run a single test?15:35
balloonsthis hearkens back to be able to pass -v or other arguments as well Ithink15:35
pittiballoons: right, from autopkgtest's POV, "autopilot" is the one and only single test15:35
pittiballoons: that, or again --shell15:36
balloonsyes, I could in theory change the manifest.. that's no good15:36
pittiballoons: we can invent somethign for passing additional args to the AP command (erk more special cases, but so what)15:36
balloonspitti, how does --shell work? It won't run till after the tests15:36
pittiballoons: for calculator-app I just commented out the tests in teh checkout and ran them then15:36
pittiballoons: right, -s or --shell apply after a test run; from then on you can run individual tests in that shell15:37
pitti(thus -s is usually more useful)15:37
balloonsI think passing args is a bridge we'll need to cross at some point. But yes, it's not crucical..15:37
balloonsyea, I still have to wait for the test run, but you are right. I can then invoke the tests any way I wish15:37
pittiright, let's keep that idea on the backburner15:38
balloons:-) So one final bug for passing args then?15:38
pittiballoons: in other news, of all the tests that I ran today, music-apps' were the most enjoyable15:38
pittiwas nice to listen to some calming music which suddenly started playing :)15:38
balloonspitti, lol..15:38
balloonsthe backstory on music is kind of funny15:38
pittiballoons: final bug> I suppose so; I need to think about how to make this look not horrible15:39
balloonsoriginally the random music playing wasn't so calming shall we say15:39
balloonspitti, yes.. here I am asking to make invoking the tests easier, yet demanding I be able to pass args!15:39
pittiballoons: so of all the packages in http://paste.ubuntu.com/7766218/ only the last two should remain, and they are only 550 kB15:40
pittiballoons: the fun thing is, downloading/unpackgin python2 stuff won't even *do* anything, as autopkgtest's magic will only work for python3 :)15:40
pitti(as there's no separate PYTHON3PATH and PYTHON2PATH, you can't mix the two locally)15:40
balloonspitti, ahhah. how true!15:41
balloonspitti, so I wonder who can review https://code.launchpad.net/~nskaggs/notes-app/ap-setup-update/+merge/22599215:41
pittiballoons: actually, I wonder if my libautopilot-qt bug is correct15:41
pittiit should certainly be fixed, but I just realized that it's already installed by default (without recommends)15:42
pittiso it must be something else15:42
balloonspitti, my guess on the py2 stuff is we're going to end up with it for awhile.. I have a bug or two about making py3 default, etc15:42
balloonsI'm not sure if there's a way they can package it easily to be a pure py3 install, with no py2 bits15:43
pittiballoons: so autopilot-touch is already installed15:43
pittiooh!15:43
pittiit's ubuntu-ui-toolkit-autopilot15:43
pittithat depends on all the py2 stuff15:44
balloonsyes, autopilot could be removed from the images ;-) Ohh, speaking of which, in our depends can we actually specify a version? I assume not, as we're using apt, we're going to get whatever apt gives us15:44
balloonspitti, ohh, well hmm.. that might be a simple packaging fix15:44
pittiballoons: you can specify constraints like >= 1.2.315:44
balloonspitti, ohh marvelous15:45
pittiballoons: you can also specify exact versions, but then your test will fail if apt doesn't have that15:45
balloonspitti, yes ofc.. but the autopilot disasters of breaking tests could be totally avoided this way15:45
pittiballoons: this is exactly why I argued so much about having separate pytho3-foo-autopilot packages, but nobody wanted to believe me back then :(15:45
balloonspitti, it's fine.. we can just blame elopio :-)15:46
pittiballoons: I have a meeting in 10 mins (tech board) and need to clean up a few things; would you mind filing a bug against ubuntu-ui-toolkit to stop depending on py2 stuff in ubuntu-ui-toolkit-autopilot?15:48
pitti(or using alternative deps with py3 first)15:48
balloonspitti, I'll probably file the bug and then do an MP for it15:48
balloonsif the change is simple enough15:48
balloonsthanks for your help on everything.. quick iterations ;-)15:49
elopioI can prove my innocence.15:49
* balloons waves to elopio15:49
balloonsbuenoes dias mae15:50
balloonsso elopio see above.. do you think we can tweak ubuntu-ui-toolkit to depend on py2 or py3, so it doesn't pull py2 stuff?15:50
balloonsI'm branching now to look15:50
elopioballoons: you are getting to the advanced jargon.15:50
elopio¿quihubo?15:50
pittiballoons: thanks; I'll leave the night shift (US time) to you then :)15:51
elopioballoons: that's a question for barry. I suppose it will involve changing all the packages to use python3-ubuntu-ui-toolkit-autopilot, or python-ubuntu-ui-toolkit-autopilot15:51
elopioif we are to touch all the packages, it would be better to touch them to be py3, and then drop py2 from the toolkit.15:52
pittielopio: well, I argued that to death with barry and thomi back then15:52
pittiand they didn't want to split the package15:52
balloonselopio, in french I would say pas mal.. I'm not sure about 'not bad' in spanish.. no mal ;-)15:52
pittiso I suppose we'll just move the deps to py3 and mop up the py2 breakage (I doubt that there's a lot)15:52
balloonselopio, could we drop py2 altogether from the toolkit?15:53
balloonshonestly, why couldn't we at this point?15:53
elopiopitti: there are some. It's not yet a quick task, but one really needed.15:53
elopiootherwise we can't add those heleprs to the UX testing project.15:53
elopioballoons: not yet, we need to port some other projects.15:53
balloonselopio, breaking things always motivates.. there's likely to always be a lingering project15:54
balloonsfair enough.. I'll just file the bug then15:54
pittielopio: apt-cache rdepends ubuntu-ui-toolkit-autopilot doesn't look bad15:55
pittielopio: and hopefully most of those *-autopilot packages are ported to py3 now?15:55
pittirvr: sorry, seems I got sucked into the discussion with balloons for too long, Tech board now; promised, will look tomorrow morning!15:56
balloonsohh lookey what I found: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/124923515:56
ubot5Ubuntu bug 1249235 in Ubuntu UI Toolkit "Need a python3 version of ubuntu-ui-toolkit-autopilot" [Undecided,Confirmed]15:56
rvrpitti: Thanks!15:56
elopioballoons: that's done.15:57
balloonselopio, ahh I misread it.. the title was misleading15:58
elopioballoons: there's one that's driving me crazy15:58
elopiomaybe you can try to find what's going on, that will help.15:58
balloonselopio, sure thing..15:58
elopioballoons: https://code.launchpad.net/~barry/dialer-app/py3autopilot/+merge/22065815:59
balloonselopio, ok, so this is just converting the dialer to py3, and you still get an error right?15:59
elopioballoons: I don't, neither barry. Just jenkins gets the error.16:00
balloonsperfect.. I'll debug :-)16:00
balloonsI love fixing jenkins only erros16:00
balloonsI've done it so much, hah!16:00
pittiballoons: just saw your mail reply -- ^5s!16:02
pittiI thought dialer-app has used py3 for a long time already16:04
pittiso apparently not16:04
=== qwebirc322421 is now known as slickymasterWork
elopiobrendand: I get this with the py3 branch:16:29
elopiohave_phonesim = out.startswith('[ /phonesim ]')16:29
elopioTypeError: startswith first arg must be bytes or a tuple of bytes, not str16:29
=== _salem is now known as salem_
brendandelopio, of what - messaging-app?16:30
elopiobrendand: yes. Running the UX tests with the py3 messaging app branch.16:31
brendandelopio, that's odd because i specifically fixed that issue16:31
elopiobrendand: oh, I'm using the fix action items branch16:33
elopioI thought py3 was a prerequisite for that one. Sorry.16:33
brendandelopio, ok - ignore my response in the other channel :)16:34
elopioI will :)16:35
=== roadmr is now known as roadmr_afk
phillwelfy / balloons The only things noticed in testcase 1483 (Alternate Install - Guided) are.... min does not work (I'm guessing they took it out as it was actually doing max and max was doing min). And the prompt to unmount an already mounted system - which is to be expected on a side by side install. I think it does a merit a mention in the test case, as a new tester may think it is an error and we don't need more bugs :P17:43
balloonsphillw, please add that to the bug report.. Well, add just what needs to be changed in your opinion. That said, you are probably the best person to change it as well if you are willing17:56
balloonsIf nothing else, just pasting a revised copy of the test in the bug would make it possible for someone to do it18:02
phillwballoons: I'm not an editor,18:04
phillwI'll do that.18:04
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
=== DanChapman is now known as DanChapman_afk
elopioballoons: july 10th. You missed the month on your email.19:22
phillwballoons: bug 133566919:38
ubot5bug 1335669 in Ubuntu Manual Tests "Manual test needs updating for Alternate" [Undecided,In progress] https://launchpad.net/bugs/133566919:38
balloonselopio, ty.. man, I need to update that in severla places ;-(19:39
=== xnox is now known as xnox_
=== xnox_ is now known as Eisbrecher
=== Eisbrecher is now known as Eisbrecher_xnox
=== _salem is now known as salem_
phillwballoons: I'm  saddened that nothing has happened for the issue on  https://wiki.ubuntu.com/QATeam/Hardware23:33
phillwballoons: https://bugs.launchpad.net/ubuntu/+source/hardinfo/+bug/130885323:34
ubot5Ubuntu bug 1308853 in hardinfo (Ubuntu) "Battery info returns: sh: 0: -c requires an argument" [Undecided,Confirmed]23:34
knomeu23:40
knomeoh bah23:40
knomethat's not what and where i was supposed to write!23:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!