| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| pitti | Good morning | 05:27 |
|---|---|---|
| dkessel | good morning | 06:06 |
| === forestpiskie is now known as Guest16550 | ||
| === Guest16550 is now known as forestpiskie | ||
| jibel | Good morning | 08:19 |
| === iahmad is now known as iahmad|afk | ||
| jibel | pitti, I found another case where britney fails. This is when binaries are available for 1 arch only and FTBFS on another arch e.g mongodb | 08:21 |
| jibel | pitti, in this case adt installs the right version of the source package but the wrong version of the binaries | 08:22 |
| jibel | pitti, do you think it's something we should enforce in autopkgtest or at the interface level? | 08:23 |
| DanChapman | good morning | 08:23 |
| pitti | jibel: I believe britney should either not call adt until all arches have built, or at least not call tests on an arch if binaries on that arch are uninstallable | 08:24 |
| jibel | pitti, agreed, but it would introduce lot a delays if it waits for slow architectures and it request a test for a source package not per architecture. But it could at least wait until intel archs are built since that's what we are testing. | 08:27 |
| pitti | jibel: right, that sounds like a good enough compromise (and s/built/published/) | 08:35 |
| jibel | pitti, there is an ADT_ARCHES in britney.conf but it doesn't seem to be used anywhere | 08:36 |
| jibel | pitti, so britney wait until ADT_ARCHES are published | 08:36 |
| jibel | in any case if I introduce a wait, it must have a notion of timeout otherwise it'll wait forever | 08:37 |
| pitti | jibel: doesn't britney run on every publisher cycle anyway? | 08:38 |
| jibel | pitti, it does | 08:38 |
| pitti | jibel: couldn't that trigger the tests based on binary availability, not source availability? | 08:38 |
| pitti | or is that too complicated? | 08:39 |
| jibel | pitti, if we trigger per arch it will introduce other cases, like running a test on amd64 when common packages built with i386 are not yet published. | 08:41 |
| jibel | it would very likely fail but that makes a test cycle for nothing | 08:41 |
| pitti | right | 08:41 |
| pitti | in our initial discussion we actually agreed to run the tests after the installability checks, and don't trigger tests on uninstallable packages (as they are guaranteed to fail) | 08:42 |
| jibel | yes | 08:42 |
| pitti | and right now we don't seem to re-trigger the tests once they become installable | 08:42 |
| pitti | at least I always do that manually | 08:42 |
| pitti | jibel: we certainly shouldn't introduce any fixed "waits" into this | 08:44 |
| pitti | it seems to me, running something like this in every britney run should work: | 08:44 |
| pitti | for every source in -proposed: | 08:44 |
| pitti | - not built on i386 or amd64 -> stop | 08:44 |
| pitti | - any binary uninstallable on any arch -> stop | 08:45 |
| pitti | - adt tests already requested -> stop | 08:45 |
| pitti | - request adt tests on i386/amd64 | 08:45 |
| pitti | and points 2, 3, 4 for all rdedpens | 08:45 |
| pitti | jibel: so where would we need another wait? | 08:46 |
| === iahmad|afk is now known as iahmad | ||
| jibel | pitti, we shouldn't need another wait. But I've seen a recent case where reconciliation of the results for ubiquity fails because the version of cdebconf tested was less than the version requested by britney. | 08:49 |
| jibel | which shouldn't happen because we use ftpmaster in the lab. | 08:49 |
| jibel | for the moment, this case remains a mystery | 08:49 |
| jibel | this is the only case where a wait would help | 08:49 |
| pitti | jibel: ah, so that's only for mirror delays, not build times | 08:50 |
| jibel | pitti, yes, for mirror delays | 08:50 |
| jibel | pitti, but this 'wait' would have the side effect to wait forever if a test is requested and an arch is never published, so let fix that first | 08:51 |
| === vrruiz_ is now known as rvr | ||
| slickymaster | good morning all | 09:59 |
| dkessel | hello slickymaster | 10:33 |
| slickymaster | dkessel: hi there, good morning | 10:34 |
| === iahmad is now known as iahmad|afk | ||
| DanChapman | morning dkessel and slickymaster :-) | 10:57 |
| slickymaster | DanChapman: and a very good morning to you | 10:58 |
| === _salem is now known as salem_ | ||
| davmor2 | Morning all | 11:09 |
| dkessel | morning davmor2 | 11:10 |
| === iahmad|afk is now known as iahmad | ||
| DanChapman | xnox, hey. What would be the best way to test the ubiquity U1 page? Is there dummy accounts that can be used or is there someone else i should speak to about it? Atm its just selecting login later | 14:20 |
| DanChapman | but would like to be able to test this page as well | 14:20 |
| elopio | good morning qa team. | 14:31 |
| DanChapman | morning elopio | 14:31 |
| xnox | DanChapman: i think it's best to leave it at that for now. You can e.g. navigate to new user page, fill out fields and check that "sign up" button gets activates once everything is filled out and check that Terms and conditions & learn more pages open. | 14:41 |
| xnox | DanChapman: there are no dummy / test accounts at all. | 14:42 |
| xnox | DanChapman: one can run that page against staging servers, but I didn't implement a way to do that yet. | 14:42 |
| DanChapman | xnox ok cool, will do that then. Thanks | 14:44 |
| senan | balloons : I've setup my keys..what should I do now | 16:00 |
| balloons | senan, :-) Excellent. is bzr setup too? | 16:00 |
| balloons | if so you should be able to commit your work locally to a bzr branch | 16:00 |
| balloons | bzr commit should work | 16:00 |
| DanChapman | hey there senan | 16:00 |
| balloons | if that all works, then the last step is to push it to launchpad | 16:00 |
| DanChapman | balloons, thanks for your comments on my wiki page :-) | 16:01 |
| senan | balloons, I am not sure how to do that | 16:01 |
| balloons | you can do that with bzr push lp:~yourlpid/ubuntu-autopilot-tests/whatever-you-want-to-call-your-branch | 16:01 |
| senan_ | from where I should do that | 16:04 |
| senan_ | balloons, from which dir i should run that | 16:04 |
| balloons | senan, do that from the directory where your bzr repo is | 16:04 |
| balloons | where your source is | 16:04 |
| balloons | did you setup a repo and commit it? | 16:04 |
| senan_ | ok | 16:04 |
| senan_ | nope | 16:05 |
| DanChapman | senan first off have you branched ubuntu-autopilot-tests? | 16:05 |
| balloons | hmm indeed.. DanChapman is on the right track ;-) | 16:05 |
| senan_ | DanChapman, that I did.. I've all the other tests in my directory | 16:05 |
| balloons | go for it | 16:05 |
| senan_ | DanChapman, like firefox,terminal,eog etc | 16:06 |
| senan_ | DanChapman, in ubuntu-autopilot-tests | 16:06 |
| DanChapman | senan perfect, so in the /ubuntu-autopilot-tests/* directory run 'bzr add' | 16:07 |
| DanChapman | which should add your test to the branch | 16:07 |
| senan_ | DanChapman, Done | 16:07 |
| DanChapman | senan then 'bzr commit' which nano should open | 16:08 |
| senan_ | DanChapman, done.. nano opened | 16:09 |
| DanChapman | first check your test folder/files are in the list in nano then write a message to sya what the tests are | 16:09 |
| === salem_ is now known as _salem | ||
| senan_ | DanChapman, Files are there | 16:12 |
| DanChapman | senan, then once you have saved the message you need to push the branch back to launchpad which balloons showed you before 'bzr push lp:~yourlpid/ubuntu-autopilot-tests/whatever-you-want-to-call-your-branch' | 16:13 |
| senan_ | DanChapan, I didnt understand the part .. write a message | 16:14 |
| DanChapman | senan_, so in nano write a simple message, something like 'Autopilot test for baobab' just something descriptive to say what it is. | 16:15 |
| DanChapman | Then hit Ctrl+o then Enter to save it then Ctrl+x to exit nano | 16:16 |
| senan_ | DanChapman, Done :) | 16:18 |
| senan_ | DanChapman,Balloons, how do I check whether new branch is created or not | 16:21 |
| DanChapman | senan_, https://code.launchpad.net/ubuntu-autopilot-tests its there now | 16:22 |
| senan_ | DanChapman, whats next ? | 16:23 |
| DanChapman | senan_, so now you can propose it for merge so open your branch on launchpad and click 'propose for merge' | 16:25 |
| senan_ | DanChapman, OK | 16:26 |
| senan_ | DanChapman, Now you can review it right ? | 16:27 |
| DanChapman | senan_, then just put a description of the test, what the test covers etc. then click propose | 16:27 |
| senan_ | DanChapman, I didnt put anything :( | 16:27 |
| senan_ | DanChapman, Since it was optional :( | 16:28 |
| DanChapman | senan_ not to worry. :-) | 16:28 |
| DanChapman | yes we can review it now :-) | 16:28 |
| senan_ | DanChapman, Thanks :) | 16:29 |
| === hobgoblin is now known as elfy | ||
| balloons | senan, all of your branches will exist here: https://code.launchpad.net/~senan | 16:35 |
| senan | balloons, ok.. if I change the file, then what should I do | 16:37 |
| balloons | when you make changes, commit them | 16:37 |
| balloons | bzr commit | 16:37 |
| balloons | when you are ready, push all the commits to launchpad again using your push command | 16:37 |
| senan | balloons, using the same command ? | 16:38 |
| balloons | bzr push lp:~senan/ubuntu-autopilot-tests/DiskUsageAnalyser | 16:38 |
| balloons | yep that will put it into the same branch | 16:38 |
| balloons | so say for instance DanChapman suggests a change, make the change, commit it and push it | 16:38 |
| balloons | the merge proposal https://code.launchpad.net/~senan/ubuntu-autopilot-tests/DiskUsageAnalyser/+merge/193087 will update and show the new version and he can review it again | 16:38 |
| balloons | make sense? | 16:39 |
| senan | balloons, yes | 16:39 |
| balloons | senan, :-) | 16:43 |
| balloons | awesome | 16:43 |
| === _salem is now known as salem_ | ||
| elopio | balloons: do you know at what time is letozaf usually around? | 16:54 |
| elopio | I have a problem with the rss tests. | 16:54 |
| balloons | elopio, about 2 hours | 16:54 |
| elopio | ok, thanks. | 16:55 |
| DanChapman | senan_, I have left some comments :-) | 17:20 |
| senan_ | DanChapman, OK, Let me check | 17:21 |
| senan_ | DanChapman, where I can see those comments | 17:22 |
| DanChapman | senan on the merge proposal | 17:26 |
| doug5 | balloons, when you have time https://code.launchpad.net/~acerisara/ubuntu-calendar-app/week-view-autopilot | 17:48 |
| balloons | doug5, got it | 18:03 |
| doug5 | balloons, merci | 18:05 |
| balloons | doug5, ohh, je parle francais? | 18:06 |
| balloons | ha.. vous parlez francais.. je suis stupide | 18:06 |
| doug5 | balloons, ehhhhh, I should learn it, since here they speak French, but I'm too lazy... :-) | 18:06 |
| balloons | ahh.. hehe,laziness indeed | 18:07 |
| doug5 | balloons, yeah :-) and at work I speak English, so I'm not so motivated also... | 18:07 |
| balloons | doug5, is expected_day_start have to be at 00:00:00 | 20:12 |
| balloons | ? | 20:12 |
| balloons | that's my only question for your merge | 20:13 |
| balloons | you do this: expected_day_start = expected_day_start.replace(hour=0, minute=0, second=0, microsecond=0) | 20:13 |
| === salem_ is now known as _salem | ||
| doug5 | it's because the date we get from the component only has year/month/day (which makes sense), so I strip those informations to compare directly the two dates | 20:14 |
| balloons | Noskcaj, ping | 20:34 |
| Noskcaj | hey balloons | 20:35 |
| balloons | Noskcaj, I was hoping you can solve a packaging riddle | 20:35 |
| knome | balloons, packaging Riddell? | 20:35 |
| knome | oh my.. | 20:36 |
| balloons | Noskcaj, mind look looking at lp:~nskaggs/ubuntu-ui-toolkit/emulator-docs-try2 with me? | 20:36 |
| Noskcaj | if my internet will work long enough, sure | 20:37 |
| Noskcaj | knome, lol | 20:37 |
| * balloons <3's knome's oneliners | 20:37 | |
| Noskcaj | balloons, I think that autopilot itself should be a native package too, but the way the integration bot works makes me unsure if that is actually worthwhile | 20:42 |
| doug5 | balloons, thank you for the review | 20:44 |
| Noskcaj | balloons, It's finally downloaded | 20:45 |
| balloons | heh | 20:45 |
| Noskcaj | What did you want me to look at? | 20:49 |
| balloons | Noskcaj, we get some packaging errors it seems when it's built | 20:49 |
| balloons | http://paste.ubuntu.com/6326229/ | 20:49 |
| balloons | Noskcaj, I could remove the ubuntu-ui-toolkit-doc.install file I guess.. I'm just wondering what' up | 20:50 |
| balloons | there's a ubuntu-ui-toolkit-doc packages as part of it.. ideally the new docs I added would get packaged in there too.. I dunno | 20:50 |
| balloons | https://code.launchpad.net/~nskaggs/ubuntu-ui-toolkit/emulator-docs-try2/+merge/193132 | 20:51 |
| Noskcaj | balloons, You really want doc files to be install by a PACKAGE.docs or a doc-base file | 20:51 |
| balloons | Noskcaj, there are 2 sets of docs.. the ubuntu-ui-toolkit docs build by dh_auto_build -- docs | 20:52 |
| balloons | the second is the docs I've added.. in theory I don't need them packaged at all.. I would just like the error to go away so I can land the branch. the docs will be pushed to the web instead | 20:53 |
| balloons | however, since there is a docs package I'm not opposed to including them as well | 20:53 |
| Noskcaj | i have to go feed some sheep. I'll see if i have time to help when i get back | 20:53 |
| balloons | Noskcaj, k | 20:54 |
| Noskcaj | I assume i missed something by going offline | 21:19 |
| balloons | Noskcaj, k, so yea | 21:19 |
| balloons | do I add to the dh_install rules for sphinx too? | 21:19 |
| balloons | and how do I fix the errors from my paste? | 21:20 |
| Noskcaj | I don't know what "sphinx" is, and by changing when the docs are generated, or having the generated versions in the branch | 21:22 |
| Noskcaj | And please make the package native, it makes it easier for us all | 21:22 |
| Noskcaj | balloons, I think override_dh_install is what you are looking for | 21:24 |
| Noskcaj | or override_dh_auto_build, which seems more suitable | 21:24 |
| Noskcaj | I have school now, bye | 21:27 |
| balloons | bye Noskcaj ty | 21:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!