[00:41] <AskUbuntu> Juju and MAAS: ERROR No matching node is available - with Ready nodes | http://askubuntu.com/q/295992
[01:05] <AskUbuntu> MAAS JUJU still get bad archive mirror | http://askubuntu.com/q/295999
[10:39] <epic_> I made the mistake of installing raring, that means I cannot utilize juju right?
[10:39] <epic_> or is there a repo somewhere with charms for raring?
[10:45] <jamespage> epic_, most charms target precise officially, but will work with raring
[10:46] <jamespage> also you can use juju to manage a precise environment from raring
[10:46] <jamespage> i.e. juju client on raring - deployed environment == precise
[11:17] <epic_> ok
[11:18] <epic_> but I have a maas cluster of two raring machines, and I wanted to use juju to deploy openstack onto them, is there a way ? :)
[12:50] <marcoceppi> epic_: You can "force" juju to deploy the precise version of your charm on to raring machines. set default series in your environments.yaml to raring then use juju deploy cs:precise/<charm-name> There's no guarentee every charm will work with raring but it might be easier than re-provisioning everything :)
[13:33] <sidnei> hazmat: ping
[13:37] <jcastro> ~20 minutes until UDS, first session is on Juju Docs!
[13:37] <jcastro> http://summit.ubuntu.com/uds-1305/meeting/21699/servercloud-s-juju-docs/
[13:38] <jcastro> arosales: we can probaly remove the session for social pages on charms
[13:39] <jcastro> rick has the assets from design, they just need to implement it, there's really nothing to discuss
[13:42] <hazmat> sidnei, pong
[13:42] <sidnei> hazmat: see pvt
[14:12] <jcastro> https://plus.google.com/hangouts/_/10bbba04970621a9233d57c88c7d469acc185e86?authuser=0&hl=en
[14:12] <jcastro> marcoceppi: arosales marcoceppi ^^
[14:12] <marcoceppi> evilnickveitch: ^
[14:12] <arosales> jcastro, the social pages for Juju we still may want to have as there are some additional feedback loops some folks wanted to discuss. May be a quick session though.
[14:13] <jcastro> ok
[14:13] <jcastro> arosales: http://youtu.be/E2peuYklMxw
[14:34] <hazmat> jamespage, vmaas vms vs juju vms group thing starting up if you've got a few.. https://plus.google.com/hangouts/_/90577076c19891cc3206c77d3e16988d1e1f130e?authuser=0&hl=en
[14:35] <jamespage> in a openstack ha then mongodb sessions right now
[14:35] <jamespage> hazmat, ^^
[14:35] <hazmat> ack
[14:41] <sinzui> jcastro, has luca spoken to your team about calling "reviewed" charms "recommended"
[14:41] <sinzui> ?
[14:42] <jcastro> no
[14:42] <jcastro> wait, don't tell me
[14:42] <jcastro> we're renaming them again?
[14:56] <gary_poster> mattyw, fwiw I was on vacation yesterday so could not attend charm helpers session.  Strawman I'd like to discuss with you later is that GUI team tries to merge host.py and our utils stuff to produce merged low-level bits, and we are responsible for getting higher-level charm-support tests to pass with merge.  Requirement is that merged result has a test coverage rating as high or higher than existing host.py, whatever
[14:56] <gary_poster> that is.  Busy now, but can talk later
[14:56] <luca> sinzui: jcastro don't do anything yet!
[14:57] <luca> sinzui: jcastro we are looking into the UX of a better name for it. Recommended was an option but will most probably not be used. We're researching it.
[14:57]  * jcastro nods
[14:58] <mattyw> gary_poster, is that meant for me or matt wedgewood?
[14:58] <gary_poster> mattyw, sorry, matt wedgwood!  bad assumption, apologies
[14:59] <mattyw> gary_poster, no problem (I'm the cloud-green matt w)
[14:59] <gary_poster> oh cool, hi mattyw :-)
[15:00] <wedgwood> gary_poster: I think that's fine. I'm working on hook environment stuff now.
[15:00] <gary_poster> cool wedgwood, thanks, sounds good
[15:23] <dpb1> hazmat: hey, the ppa is updated now, all series?
[15:25] <hazmat> dpb1, yes
[15:26] <hazmat> dpb1, by all series.. that being raring, quantal, precise
[15:26] <dpb1> hazmat: ah, I see.  the lucid build is still old
[15:27] <dpb1> hazmat: is it possible to kick a lucid build too?
[15:28] <hazmat> dpb1, checking
[15:29] <hazmat> dpb1, it looks like its barfing on dh_python2
[15:29] <hazmat> https://launchpadlibrarian.net/139956755/buildlog.txt.gz
[15:30] <jamespage> hazmat, you guys finished now?
[15:31] <hazmat> jamespage, yup
[15:31] <jamespage> bah
[15:31] <jamespage> nm
[15:31] <hazmat> jamespage, more to be discussed, lots of details and directions to be ironed out
[15:32] <dpb1> :(
[15:40] <jamespage> hazmat, dpb1: is that really a lucid build?
[15:41] <hazmat> jamespage, apparently yes.. who knew :-)
[15:41] <jamespage> I don't think lucid has dh_python2
[15:41] <dpb1> jamespage: know of a quick way to fix it?
[15:46] <hazmat> revert back to pycentral/pysupport ..
[15:46] <hazmat> afaik
[15:46] <dpb1> k
[15:49] <jamespage> hazmat, dpb1: openstack packaging used todo this just after lucid
[15:51] <hazmat> jamespage, support lucid with dh_python2 or use pycentral/pysupport?
[15:51] <hazmat> i assume the latter.. cause it still works even throws deprecation warnings
[15:51] <jamespage> it had some hacks to support dh_python2 and pycentral/support
[15:52] <jamespage> upstream activity backported to lucid until precise arrived
[15:53] <hazmat> barry ref'd this bug re lucid/dh_python2 https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/788524https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/788524
[15:53] <_mup_> Bug #788524: backport dh_python2 to lucid (and maverick if appropriate) <pycentral-deprecation> <OpenStack Core Infrastructure:Fix Released by mordred> <python-defaults (Ubuntu):Confirmed for doko> <https://launchpad.net/bugs/788524>
[15:53] <_mup_> Bug #788524: backport dh_python2 to lucid (and maverick if appropriate) <pycentral-deprecation> <OpenStack Core Infrastructure:Fix Released by mordred> <python-defaults (Ubuntu):Confirmed for doko> <https://launchpad.net/bugs/788524>
[15:54] <dpb1> hazmat: best of both worlds: https://pastebin.canonical.com/91141/
[15:54] <hazmat> also refs the openstack usage
[15:54] <dpb1> heh, ya, that is the bug that I was looking at too
[15:55] <m_3> wedgwood: not sure it needs to be resolved right now... it's pretty easy to change
[15:55] <dpb1> that patch (minus the stray .deb file) seems to work on my lucid machine
[15:56] <m_3> wedgwood: oh nm... we wanna get stubs into charms sooner rather than later
[15:56] <m_3> :)
[15:56] <wedgwood> m_3: indeed, but also means changing charms
[15:57] <marcoceppi> wedgwood: So what you're saying is just anything in tests/ gets run regardless of +x ?
[15:57] <wedgwood> suppose windows criteria could be different than unix
[15:57] <m_3> I can see value in ordering
[15:57] <m_3> also having files there that _don't_ get executed
[15:57] <wedgwood> m_3: upon consideration, +1 to ordering
[15:57] <m_3> having multiple scenarios
[15:57] <wedgwood> I like the test manifest idea. "Run these things"
[15:58] <m_3> I was thinking ordering was more about "failing early" on simple tests
[15:58] <marcoceppi> m_3: well I can see the "don't want it executed, don't put it in tests/, put it in tests/lib"
[15:58] <marcoceppi> Or another subdirectory and just not walk trees when testing
[15:58] <m_3> and less about setup/teardown... that (imo) should happen within each scenario
[15:58] <marcoceppi> m_3: +1 for sure
[15:58] <m_3> marcoceppi: yeah, stick to tree level 0 in there
[15:58] <wedgwood> yep, we agree that order is important
[15:58] <marcoceppi> A lot of my use cases have very unique setups with different charms and initial configs
[15:59] <m_3> ok, so then any naming scheme's fine with me
[15:59] <wedgwood> what about a single command that's expected to handle running tests?
[16:00] <marcoceppi> m_3: wedgwood: I can drop the implicit .test and just run things in lexi ordering in the tests folder
[16:00] <marcoceppi> wedgwood: the juju-test command?
[16:00] <m_3> hell, even worth considering tree level 1... i.e., $CHARM_DIR/tests/<scenario-name>/{01.setup.sh,02.run.sh,03.teardown.sh}
[16:00] <wedgwood> m_3: bah!
[16:00] <m_3> wedgwood: what about that single command?
[16:00] <m_3> wedgwood: ack, it's too noisy
[16:00] <wedgwood> marcoceppi: I'm thinking mycharm/tests/run_tests
[16:00] <marcoceppi> m_3: why couldn't that be $CHARM_DIR/tests/scenario.sh ?
[16:01] <m_3> marcoceppi: excellent point
[16:01] <marcoceppi> wedgwood: that would be encompased in the juju-test command though, where it would just run one or more (or all) tests in the tests directory
[16:01] <m_3> wedgwood: single starting point would work... let's you control your scenarios in python
[16:01] <m_3> wedgwood: but I guess I like separate script file per scenario
[16:01] <m_3> either way though really
[16:02] <wedgwood> m_3: scenarios are still possible, but shouldn't juju-test have a single mode?
[16:02] <m_3> so tree-level-0, executable, single file per scenario (that can optionally call as much other stuff as it likes)
[16:02] <marcoceppi> If you wanted control over ordering $CD/tests/00-run-tests then you could mock scenarios you cared about in $CD/tests/scenarios and have the 00-run-tests build an order
[16:02] <wedgwood> s/mode/target/
[16:03] <m_3> wedgwood: if I understand correctly, then yeah, each scenario would be a separate stack of services (include bootstrap and destroy-environment)
[16:03] <m_3> `juju test <charm-name>` should run all of them in order I think
[16:04] <marcoceppi> m_3: right, buy could could also run juju test charm-name <test-name> to run just one test
[16:04] <m_3> with an option of calling `juju test <charm-name>/tests/<scenario-file>` explicitly perhaps?
[16:04] <wedgwood> marcoceppi: good point
[16:04] <m_3> ah, same page
[16:05] <marcoceppi> m_3: yeah, and we can make that an explict path too
[16:05] <marcoceppi> maybe just juju test <charm-name> -f tests/blah
[16:05] <marcoceppi> or something
 would have to match a file in $CHARM_DIR/tests otherwise
[16:05] <m_3> explict path might be easier to impl
[16:05] <m_3> but really whatever works
[16:06] <marcoceppi> m_3: right so you could do that or possibly just have an additonal option to supply a full file path
[16:06] <wedgwood> to sum up my concern about naming schemes: I'd like to structure my tests in a way that works with my chosen programming language.
[16:06] <marcoceppi> in the event you're cool and want to have tests outside of the charm
[16:06] <m_3> hell, I'm happy with just making bits I'm _not_ interested in testing non-executable temporarily
[16:06] <m_3> (during dev)
[16:07] <marcoceppi> wedgwood: ack on your concern. I'm just going to have it execute whatever the hell you have in tests directory so you can name them as you see fit.
[16:07] <m_3> wedgwood: yeah, understand... I'm fine with picking one set of names
[16:07] <marcoceppi> I'll try to err on the site of flexibility rather than being too opinionated on things like naming and structure
[16:07] <m_3> marcoceppi: +1
[16:07] <wedgwood> marcoceppi: I think that's flexible enough. some sharp edges, but probably safe
[16:08] <marcoceppi> wedgwood: we can dull those edges in the next few weeks, for sure
[16:08] <marcoceppi> I'd like to just get something out that people can use without too many scrapes
[16:08] <m_3> fits along with the "flexible framework" yet opinionated helpers/examples
[16:08] <wedgwood> marcoceppi: and when we tackle windows, we may need a manifest file. there's no way to tell from naming or filesystem bits what is and isn't an executable.
[16:08] <m_3> yup, or rely on tree depth
[16:09] <marcoceppi> wedgwood: yeah, I think we'll need to cross that bridge when we get there, but I'll keep that in mind on these first few cuts
[16:09] <marcoceppi> wedgwood: thanks for the feedback!
[16:10] <m_3> I need to start using that one more in talks... "flex framework, opinionated charms/helpers"
[16:10] <wedgwood> marcoceppi: looking forward to seeing your work!
[16:11] <marcoceppi> m_3: where should we start storing juju plugins? Given juju-test will likely be the first one
[16:11] <m_3> yeah, awesome guys
[16:12] <m_3> marcoceppi: good question man... not really sure... there're pros/cons with each option
[16:12] <m_3> marcoceppi: we can package `juju-plugins` or `juju-contrib`
[16:12] <marcoceppi> I'd probably lean to juju-plugins, contrib sounds too...official :)
[16:12] <m_3> marcoceppi: we can have a juju-plugins project where each plugin has to be pulled separately
[16:13] <m_3> marcoceppi: so we get packages like `juju-plugin-testing`
[16:13] <m_3> makes it explicit to the user that this is something _other_ than juju-core
[16:13] <marcoceppi> m_3: ack
[16:13] <chilicuil> hello there, I'm working on a monitor charm (observium) https://code.launchpad.net/~chilicuil/charms/precise/observium/trunk and currently it deploys the server part, however no enable clients, those machines (the ones who are going to be monitored) needs to install snmpd, I'd like that it could be done via some kind of connection between the charms, I suppose it would require modification in the charms which will be clients, is this correct?
[16:13] <m_3> juju-plugins-<common-subject> for groups of pugins
[16:14] <marcoceppi> m_3: like juju-plugins-charm :)
[16:14] <marcoceppi> get all the charm-tools juju plugins
[16:14] <m_3> marcoceppi: yeah, so I think a plugins project... maybe repo per plugin?... and then we can create package-groups
[16:15] <m_3> chilicuil: this is a perfect use for "subordinate" services
[16:15] <marcoceppi> m_3: just started the plugin project, I'll just createa a repo for juju-test and have it building in a ppa...maybe the juju/pkgs ppa?
[16:15] <m_3> chilicuil: you'd create something like 'observium-emitter' that attaches as subordinate to any service
[16:15] <chilicuil> m_3: I'll look for it at the documentation, thanks!
[16:15] <m_3> chilicuil: then that subordinate charm adds snmpd and friends
[16:16] <marcoceppi> hum. Do plugins need to be the same license as core?
[16:16] <m_3> marcoceppi: yeah, same pa as core imo
[16:16] <m_3> ppa
[16:17] <m_3> chilicuil: np
[16:17] <m_3> marcoceppi: no clue
[16:17] <m_3> marcoceppi: they're more one-off things... so make them as open as possible I'd think
[16:17] <marcoceppi> I wish I was a laywer
[16:17] <m_3> haha
[16:18] <m_3> I wouldn't wish that on you
[16:18] <marcoceppi> haha
[16:18] <m_3> although it might be helpful in a bar in DC :)
[16:19] <m_3> marcoceppi: we can add lp:juju-plugins to the juju project group in lp
[16:19] <marcoceppi> awesome
[16:19] <m_3> I'll set up the mirror for github
[16:20] <marcoceppi> m_3: ta!
[16:22] <m_3> github.com/juju-plugins
[16:22] <m_3> what's the lp project?
[16:22] <marcoceppi> lp:i-am-not-a-lawyer
[16:23] <marcoceppi> jk, lp:juju-plugins
[16:23] <m_3> :)
[16:25] <m_3> marcoceppi: I expect at some point there will also be plugins that're bundled with core, but nothing to do for that really
[16:25] <m_3> should just work
[16:25] <marcoceppi> m_3: so are we creating directories in a single bzr branch, or a branch per plugin?
[16:26] <m_3> just don't know
[16:26] <m_3> how heavyweight is repo per plugin?
[16:26] <m_3> you clone it and simlink the plugin iteself into your ~/bin dir
[16:27] <m_3> or do you wanna just clone a single repo and then symlink selections
[16:27] <m_3> we can do both
[16:27] <marcoceppi> depends on how many plugins you have
[16:27] <marcoceppi> I think it's a good idea, but doesnt' scale quite well in github unless you merge all the branches in to one section
[16:27] <m_3> if they're all in one repo, then it's harder for us to create `juju-plugins-testing` and `juju-plugins-charm` packages
[16:28] <marcoceppi> lets do different repos for now
[16:28] <m_3> well, maybe it isn't though
[16:28] <mattyw> I've got a charm which works under pyju - and fails under juju-core when running the relation_changed hooks. it looks like I get "no relation id specified" when running relation-set, does this make any sense?
[16:29] <m_3> marcoceppi: I'm kinda thinking one repo
[16:29]  * marcoceppi shrugs
[16:29] <marcoceppi> just in different dirs?
[16:29] <m_3> marcoceppi: you know what? it doesn't really matter right now... we can change this pretty easily
[16:30] <m_3> marcoceppi: so maybe one repo... trunk on lp:juju-plugins... file per plugin (no need for subdirs)
[16:30] <m_3> marcoceppi: then we can add a packaging branch at any time to package selected bits
[16:30] <m_3> marcoceppi: with the full expectation that this will probably change
[16:31] <marcoceppi> ack
[16:34] <m_3> marcoceppi: I think it's a good idea to treat this as a big bucket... over time an individual plugin might "grow up" and need its own repo
[16:34] <marcoceppi> m_3: good point
[16:35] <m_3> marcoceppi: I could see Makefiles and other supporting crap associated with installing a single plugin... at the point it's no longer a single file of script, it gets a separate repo
[16:41] <hazmat> mattyw, are you using upload-tools
[16:41] <mattyw> hazmat, no I'm not
[16:41] <hazmat> mattyw, can ic the charm?
[16:41] <hazmat> priv msg if nesc
[17:42] <jcastro> gary_poster: GUI session in about 20 min?
[17:43] <gary_poster> y jcastro thanks.  on call now.  hangout link?
[17:43] <jcastro> I haven't created it yet
[17:43] <jcastro> I will in about 15
[17:43] <jcastro> just wanted to give you a heads up
[17:43] <gary_poster> cool thanks
[18:58] <hazmat> jcastro, is there a separate irc channel then.. #ubuntu-uds-servercloud-2 ?
[18:58] <hazmat> oh.. nm
[18:59] <Huron> alguien habla español
[19:02] <sinzui> arosales, Your user stores for charm testing rock
[19:03] <sinzui> they should be added to author profiles
[19:05] <arosales> sinzui, I can't take credit for that. I think marcoceppi did those in https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-charm-testing
[19:05] <arosales> there are good though :-)
[19:05] <marcoceppi> Holy grammar hell, batman. I should have proof read those after I got off the plane
[19:12] <sinzui> grammar was never a barrier for developers. My fingers don't believe in plurals and tenses.
[19:13] <hazmat> marcoceppi, incidentally new deployer impl support for pyjuju is coming
[19:13] <marcoceppi> hazmat: \o/ thanks for the update
[19:14] <hazmat> marcoceppi, and deployer integrates what amounts to gowatch (available from the jujuclient api impl)
[19:14] <marcoceppi> perfect
[19:15] <hazmat> marcoceppi, what i really want is a way for charm authors/charm farmers to be able to manually kick off a test run on a particular charm or mp, and get notified of results.
[19:15] <hazmat> i mean its icing.. but its delicious
[19:15] <hazmat> ;-)
[19:16] <marcoceppi> hazmat: yeah, you're not the only one asking for this. When local lands it'll be easy enough for charmers (sans ~) to just juju test <charm> <test-name> -e local but I've been mulling over adding a juju-remote-test command for queing a test on jenkins. Not sure how abused that will get though
[19:17] <hazmat> marcoceppi, restricting it to ~charmers initially seems sane.. and helps reviewers
[19:18] <marcoceppi> hazmat: yeah, would be a good starting point, though I'd favor just having automatic testing on merge request over one-off test queing
[19:19] <hazmat> marcoceppi, true
[19:20] <marcoceppi> Once we get people writing test I'd love to start diving in to all that automation deliciousness
[19:23] <hazmat> marcoceppi, so whats missing to me is why jitsu test is not the correct path forward
[19:24] <hazmat> ignoring the implementation but the spec itself
[19:24] <marcoceppi> hazmat: do you have the spec somewhere? I haven't actually read it
[19:24] <marcoceppi> Though, I don't think the juju-test implementation would be too far off what jitsu test was striving to be
[19:27] <marcoceppi> hazmat: this in the docs: https://code.launchpad.net/~clint-fewbar/charm-tools/charm-tests-spec/+merge/90232 ?
[19:33] <hazmat> marcoceppi, its the one in the old docs
[19:33] <hazmat> marcoceppi, http://jujucharms.com/docs/charm-tests.html
[19:34] <marcoceppi> hazmat: yeah, so implementation wise of just listening to signals and shelling out to the test in the tests directory (with better handling of the tests individually) is what juju-test will do
[19:35] <marcoceppi> The test helper I'm working on just give an author of tests a lot easier ways to inspect a deployed environment to build better detailed tests


[04:34] <jonathas> Hi, someone tests ubuntu?
[04:35] <jonathas> using virtualbox
[07:08] <jibel> good morning
[08:37] <DanChapman> Good Morning all :-)
[09:50] <DanChapman> Morning jibel, on friday i added a test for eye-of-gnome to the autopilot ubuntu apps production branch. But it hasn't run over the weekend. Does it need to be manually added to the build params or something?
[09:58] <jibel> DanChapman, good morning, I added eog to the list of tests to run and started a new build.
[09:59] <DanChapman> jibel, thats great. Thank you :-)
[12:45] <asac> gema: is there known infrastructure bustage of maguro?
[12:45] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/image/2986/ ?
[12:56] <gema> asac: when you see a job with a image id with a question mark ?
[12:56] <gema> asac: it is normally infrastructure related
[12:57] <gema> asac: it means that jobs run but there was nothing there afterwards, not even to determine what image was run
[12:57] <cking> gema, have we no power consumption results for july? http://reports.qa.ubuntu.com/power/hardware/arch/i386/
[12:57] <gema> asac: so the dashboard takes a guess and adds a question mark
[12:57] <asac> ah so this one has it
[12:57] <asac> kk
[12:57] <asac> thats good info
[12:58] <gema> cking: we've been trying to move stuff to puts and had some disconnected time
[12:58] <asac> let me set up VPN again (lost it a few weeks ago it seems)
[12:59] <cking> gema, any ETA on when it will be back on-line, it's > 3 weeks now w/o data
[12:59] <gema> cking: let me get you one
[13:00] <cking> gema, thanks
[13:10] <WebbyIT> balloons: Hi. I did some autopilot test for clock app during the weekend, but first we have to resolve this issue: https://bugs.launchpad.net/ubuntu-clock-app/+bug/1200699 When you have time, can you check? Thanks :)
[13:11] <jibel> DanChapman, eog tests are good, still 1 failure with firefox https://jenkins.qa.ubuntu.com/job/autopilot-ubuntu-applications/
[13:12] <DanChapman> jibel, awesome! yeah the firefox test is a real pain as we can't introspect it.  It can only be a basic test because it won't introspect
[14:32] <DanChapman> balloons, hello! ok I will get that failing one removed then :-)
[14:33] <balloons> DanChapman, :-)
[14:33] <knome> hello people
[14:33] <knome> balloons, how's the thinkwork re: dropping test case names going? we ready to take action?
[14:34] <balloons> knome, ohh what action did you have in mind? My resolution was to let status quo be the same but only merge new things with them removed
[14:34] <knome> do another big push with them revomed
[14:34] <knome> because people will continue looking for examples
[14:41] <balloons> knome, ahh.. I would accept a commit that did such a thing
[14:42] <knome> ok, i'll get a merge proposal in today
[14:42] <balloons> how's the UI changes going? is stgraber freeing up as expected?
[14:43] <knome> umm, i though he said jul 2*
[14:43] <knome> so you'd have to ask him, i can't see into the future regarding his calendar ;)
[14:43] <balloons> yea, it was the end of july.. just seeing if everything is still on target for that or not :-)
[14:43] <balloons> lol
[14:43] <balloons> kk
[14:43] <knome> so test case names and test case id's
[14:43] <knome> are we on the same page?
[14:44] <balloons> knome, well let's check quickly
[14:44] <balloons> example test incoming
[14:44] <knome> sure :)
[14:44] <balloons> http://packages.qa.ubuntu.com/qatracker/testcases/1422/info
[14:45] <knome> actually, while i'm at it
[14:45] <balloons> what would you change that to?
[14:45] <knome> we should remove "tests" from all the testcase titles/filenames
[14:45] <knome> i would remove the lines beginning with Test-case name: gnometerminal
[14:48] <knome> some of the hardware tests have semi-interesting ID's
[14:48] <knome> Case ID: hwn-001
[14:48] <knome> which i suppose in this case translates to "hardware: wireless networking"
[14:49] <knome> i'm wondering if those id's are actually used instead of the test case titles
[14:51] <balloons> mm the hardware tests? they are less groomed than the others
[14:51] <balloons> it's possible you could find some slightly different and older methods in them
[14:52] <knome> well i went through them when i did the last huge commit
[14:53] <knome> so they shouldn't - except the things outside
's
[14:53] <balloons> right.. I know jackson went through them as well
[14:53] <balloons> but it's *possible* :-)
[14:53] <knome> sure
[14:54] <knome> i mean, the only rationale i can think of *for* any test case name/id is the order of the tests
[14:54] <knome> (think: you must have had test #2 ran before this)
[14:55] <knome> or, in a bug report, or a channel discussion, or test result comment: "bug #123456 appeared when running test #3"
[14:55] <knome> not that!
[14:56] <elfy> LOL
[14:56] <balloons> knome, breaking up the tests as we have, with descriptions works.. and having a way to refer to the individual test inside is helpful
[14:57] <balloons> but I don't want to confuse people with the weird old wiki syntax we used at one time
[14:57] <knome> heh
[14:57] <knome> so do you think test case names should be kept anyway?
[14:57] <balloons> fullname/abbreviation-00#
[14:57] <knome> heh
[14:57] <knome> there is a solution...
[14:57] <balloons> that's just a bit silly.. what's your thought?
[14:58] <knome> we could make all the tests require a header.
[14:58] <knome> like:
This test tests that... blah blah

[14:58] <knome> then, with js, go through all the
-elements and prefix them with numbers 1, 2, 3, 4 ...
[14:59] <knome> if a user had no js enabled browser, or their browser wouldn't support js (which would be weird), they would see the headers without the numbers
[14:59] <knome> but they would still be able to know which test was which number by counting
[14:59] <knome> (if they had to)
[14:59] <balloons> that's reasonably sane.. most should have a basic description before the test
[14:59] <balloons> hmm.. so you auto number them
[14:59] <knome> yup
[14:59] <knome> or
[15:00] <knome> we can just look for all
's in the document and add a new element before them
[15:00] <knome> so we wouldn't be requiring a header
[15:00] <balloons> right right
[15:02] <elfy> I hope this isn't change for changes sake
[15:02] <knome> elfy, you think i would propose something like that?
[15:02] <elfy> not normally no :)
[15:03] <knome> this is a change for the sake of making the markup even easier
[15:03] <knome> and reducing the things people need to remember
[15:03] <elfy> that's good
[15:04] <elfy> though I'm not sure people need to remember much
[15:04] <knome> no.. my problem with the testcase names is that people keep asking what they should insert there, and there's a ton of conventions around
[15:05] <knome> stgraber, hey!
[15:07] <SergioMeneses> hi everybody
[15:07] <SergioMeneses> knome, elfy \o
[15:07] <knome> hello SergioMeneses
[15:08] <SergioMeneses> knome, how's everything?
[15:09] <balloons> hello SergioMeneses :-)
[15:09] <knome> stgraber, do you think you could get to one simple thing ASAP, probably before your sprint... adding the "if all actions..." -paragraph after each test automatically do people doing testcases do not need to maintain that
[15:09] <SergioMeneses> balloons, hey! :)
[15:09]  * SergioMeneses hugs balloons
[15:09] <knome> SergioMeneses, fine! trying to make the lives of testcase contributors easier
[15:10] <SergioMeneses> knome, that sounds pretty nice, and what do yo have on mind?
[15:10] <elfy> SergioMeneses: hi
[15:10] <knome> SergioMeneses, see the backlog ;)
[15:10]  * balloons hugs SergioMeneses back
[15:10] <balloons> It's going quite well. My inlaws have been visiting for over 2 weeks, but they just left this morning
[15:10] <balloons> it's quiet in the house again, but a bit somber
[15:10] <knome> balloons, hehe, congratulations!
[15:11] <elfy> lucky you balloons - it was always party time for me when mine left :)
[15:11] <SergioMeneses> balloons, :O
[15:11] <balloons> DanChapman, have you been able to meet up with vausdevan on the nautilus testcase and others?
[15:11] <balloons> elfy, I have pretty good inlaws tbh :-)
[15:11] <elfy> always good that
[15:11] <knome> balloons, i'm fine with my inlaws as well, but i can't say i'm not relieved when the leave :)
[15:12] <knome> balloons, though i can say the same about my own parents ;)
[15:12] <DanChapman> balloons, I havn't as of yet still waiting on him to ping me about a date/time that's good for him
[15:13] <DanChapman> I did see on the mailing list that he was having troubles with unity & saucy
[15:14] <balloons> knome, yea i'm a little relieved, but also a bit sad..
[15:14] <balloons> they live quite far away.. anyways ;-p
[15:15] <balloons> DanChapman, hmm, I might try emailing him again.. Another question for you DanChapman :-) Have you found it useful to use the search function francis showed us last month @ the hackfest for gtk apps?
[15:15] <balloons> let me find the snippet
[15:16] <balloons> DanChapman, http://paste.ubuntu.com/5711368/
[15:20] <DanChapman> balloons i have found it useful in places but it only finds the first object in the tree. So say you have 2 GtkEntry widgets one in main window and one in dialog both with same name. You wil only ever be able to get the main window widget. But for simple searches yeah it does help
[15:21] <DanChapman> I tend to get_properties() then print them throughout the test. Makes an interesting bit of reading ;_P
[15:21] <DanChapman> :-P
[15:26] <DanChapman> balloons, and cool about emailing him. Be good to get nautilus done :-)
[15:26] <elopio> balloons: ping. Do you know how we can add a pep8 check to the bot that runs the pre-merge tests?
[15:27] <balloons> elopio, the autopilot bot?
[15:28] <balloons> DanChapman, :-)
[15:28] <elopio> balloons: It's called autopilot too?
[15:29] <DanChapman> balloons, i just looked at that link? You've extended the one francis showed :-) ill have to try that one
[15:29] <balloons> elopio, lol.. bad word choice. when you say pre-merge tests, do you mean the tests from here? http://<IP_ADDRESS>:8080/job/generic-mediumtests/
[15:29] <balloons> DanChapman, ohh did I, lol? I remember messing with it a bit yes, but .../
[15:30] <elopio> balloons: yes. It would be great if the MP doesn't land if there are static errors.
[15:31] <balloons> elopio, the man to talk to about that is fginther :-)
[15:31] <elopio> great. Thanks balloons.
[15:31] <balloons> elopio, ty :-p
[15:32] <knome> bbl. balloons, ping me if you have further thoughts, i will need to reconsider the name/id thing myself :)
[15:32] <knome> ->
[15:33] <balloons> knome, ok.. yea, I guess there was more discussion than I thought!
[15:34] <fginther> elopio, we have a pep8/pyflakes checker we can add. Which project needs it?
[15:34] <fginther> elopio, or does it need to only be pep8?
[15:35] <elopio> fginther: it would be great to have it on all the core apps.
[15:36] <elopio> pep8 and pyflakes. But first we need to make them compliant.
[15:37] <elopio> fginther: if I fix the current errors, then can I ping you to enable the checkers?
[15:37] <fginther> elopio, Ok, just let me know how you would like to proceed.
[15:37] <fginther> elopio, yes
[15:37] <elopio> fginther: thanks!
[15:49] <stgraber> knome: sorry, not sure I understand what you mean
[16:41] <SergioMeneses> balloons, did you edit the Audacity testcase?
[16:41] <SergioMeneses> chilicuil, \o
[16:43] <balloons> SergioMeneses, what do you mena edit?>
[16:45] <SergioMeneses> if you made changes before publish it
[16:45] <chilicuil> SergioMeneses: \o! long time to see my friend
[16:46] <balloons> SergioMeneses, ohh I very well may have
[16:46] <balloons> I fix spelling and formatting before merging things
[16:47] <balloons> chilicuil, and SergioMeneses at the same time.. A rare treat :-)
[16:47] <SergioMeneses> chilicuil, I've been too busy with my new job
[16:47] <SergioMeneses> balloons, perfect! I shall check it as soon as possible ;)
[16:48] <chilicuil> balloons: =)!, SergioMeneses yep, I've been busy too lately =/
[16:48] <SergioMeneses> balloons, aaaah... everybody say this is rare now
[16:48] <SergioMeneses> chilicuil, I'm playing with Bacula :)
[16:49] <balloons> SergioMeneses, lol.. well it's just nice to have you both. Summertime is busier time for us here, but of course it's winter for you right SergioMeneses ?
[16:49] <SergioMeneses> balloons, no... we dont have winter here
[16:50]  * SergioMeneses sad
[16:50] <balloons> SergioMeneses, lol.. what do you mean no winter? Aka, it's always warm?
[16:50]  * balloons likes warm!
[16:51] <SergioMeneses> balloons, yes.... only sun and some clouds
[16:51] <SergioMeneses> :S
[16:51] <balloons> I like that kind of "winter"
[16:51]  * SergioMeneses says to balloons winter is coming
[16:51] <elopio> fginther: ping. can you enable the checks for ubuntu-filemanager-app, please?
[16:52] <elopio> but only check the tests/autopilot folder.
[16:52] <SergioMeneses> balloons, =/ I would rather snow
[16:52] <balloons> elopio, I owe him a runthrough of all the core apps that can be turned on..
[16:52] <balloons> heh, if you want to or have time to do it, I'd appreciate it.. it's on the list, but I'm backlogged as usual :-)
[16:52] <balloons> SergioMeneses, yes, I get that. but it's not all it's cracked up to be.. So :-)
[16:52] <elopio> balloons: I'm not sure what you are talking about. I'm talking about the static checks.
[16:53] <balloons> elopio, ohh.. nvm then
[16:53] <elopio> balloons: but I can help, sure. I just need a better explanation of what you have just said.
[16:53] <balloons> elopio, basically we want to gate commits for all the core apps whose autopilot tests pass right now
[16:54] <balloons> when we first turned it on not all of them ran properly, etc, so only a couple are gated
[16:54] <balloons> more should be able to be gated now
[16:55] <elopio> balloons: got it. Where can I see the apps currently enabled?
[17:08] <fginther> elopio, http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/phablet/ubuntu-touch-coreapps.cfg
[17:09] <fginther> elopio, the projects with a "generic-mediumtests listed in the" configuration have the UI tests enabled.
[17:11] <elopio> fginther: cool. What does it mean template: False?
[17:13] <fginther> elopio, It means that the generic-mediumtests is a pre-existing job and not generated from a template. cupstream2distro-config is what we use to auto-generate jenkins jobs. It's a little hard to make real sense of the cfg files without being a familar with the project itself.
[17:14] <elopio> fginther: yes, it's hard to read. For now, I
[17:14] <elopio> 'll just ask you to update them.
[17:14] <fginther> elopio, that's the idea. I maintain that file :-)
[17:15] <elopio> awesome :)
[17:15] <fginther> elopio, but if you want a quick answer as to what projects are enabled, that's where you can look if I'm not around
[17:22] <elopio> fginther: for ubuntu-filemanager-app the autopilot tests are failing. But can we just run the static tests?
[17:35] <WebbyIT> balloons: I wrote also two tests for calculator: https://code.launchpad.net/~rpadovani/ubuntu-calculator-app/1188703 Maybe the delete test has to be rewrite if patch for bug #1198873 is accepted, but now it working
[17:42] <fginther> elopio, the autopilot tests are not enabled for ubuntu-filemanager-app
[17:42] <fginther> elopio, 'not enabled' in jenkins that is
[17:45] <fginther> elopio, are the static tests build as part of package build?
[17:46] <elopio> fginther: currently, they are not part of anything.
[17:46] <elopio> I'm not sure where to add them.
[17:47] <fginther> elopio, most projects add them debian/rules so that they are always executed when the package is built
[17:47] <elopio> fginther: do you know a project I can take as an example for that?
[17:48] <fginther> elopio, I'll look for one
[17:53] <fginther> elopio, do you have a launchpad branch with these tests?
[17:54] <elopio> fginther: no. Currently I'm just running the pep8 command.
[17:55] <DanChapman> balloons, this final test doing manual partitioning for ubiquity is getting really hacky. I am getting 'object does not have any positional attributes' for nearly every object on the partition dialog and its basically boiled down to keyboard nav now and its horrible and fails LOTS!. Is it needed or will the current tests i.e default install, LVM and LVM with encrypt /home be enough?
[17:55] <fginther> elopio, Oh, I miss-understood. I thought you had some unit-tests that you wanted to run.
[17:55] <fginther> I've enabled the pep8/pyflakes check for ubuntu-filemanager-app. It runs as a post-build pbuilder hook.
[17:56] <elopio> fginther: cool. Is that pre-merge or post-merge?
[17:56] <fginther> pre-merge
[17:56] <elopio> :D
[17:56] <elopio> thanks. I'll let you know when the others are compliant.
[17:57] <fginther> elopio, thank you!
[17:57] <balloons> DanChapman, manual partitioning.. it would be REALLY nice to have it. Perhaps xnox can shed light as to why it's not working
[17:57] <balloons> DanChapman, did you speak with jibel at all this morning? I can setup a time for you to meet.. if you make it friendly enough of a time, I can be there too, to talk about running these ubiquity tests
[18:02] <DanChapman> balloons, yeah i thought it would be really good to have. I'll get a list together then and will send it xnox's way see what he can do.
[18:03] <balloons> DanChapman, we find bugs in manual partitioning more than other things, so :-)
[18:03] <balloons> DanChapman, yep.. it's SO nice to have the developer here and handy to answer questions in this case
[18:04] <DanChapman> balloons, I spoke to jibel briefly this morn about eog on jenkins. But yeah if you could arrange a time for us all to meet that would be great :-)
[18:07] <balloons> DanChapman, can - do.. Can you meet between 1300 UTC and say 1500 UTC or so?
[18:07] <balloons> I think that's the easiest time for me and jibel to meet
[18:09] <asac> doanac: can you check that http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130715.2/ is in testing?
[18:09] <DanChapman> balloons, yeah between then is good for me :-)
[18:09] <asac> doanac: e.g. hasw been picked up by utah
[18:10] <asac> was just produced a few minutes ago
[18:10] <asac> in the hope that we get new smoke results
[18:11] <xeranas> hi
[18:11] <balloons> xeranas, hello
[18:11] <xeranas> balloons: I believe https://bugs.launchpad.net/sudoku-app/+bug/1195886 is already covered. At least what I see when I run test
[18:12] <balloons> mm.. xeranas your right!
[18:12] <balloons> I was just going through everything to make sure the status was correct, thanks for pointing this out ;-)
[18:13] <xeranas> no problem, still there are some places where I need learn
[18:14] <balloons> xeranas, I'm always here to help :-)
[18:16] <xeranas> test_sudoku.py have some lines with 'lambda', not sure why we need it. It is better way to calling methods in autopilot?
[18:18] <balloons> xeranas, good question
[18:18] <balloons> so in order to use the eventually keyword in an assert you need to have a function
[18:18] <balloons> so for example, if I want to assert that eventually a label changes, I can't simply assert that the label will equal "blah" eventually
[18:18] <balloons> the label won't change.
[18:19] <balloons> instead I can use lambda to make it a function, which grabs the label value
[18:19] <balloons> so what will happen is the code will continually poll that lambda function (which grabs the value) until it "eventually" make my assert true
[18:20] <xeranas> ah, it defines variable at run time
[18:20] <balloons> :-)
[18:20] <balloons> http://www.secnetix.de/olli/Python/lambda_functions.hawk
[18:20] <balloons> etc, etc
[18:20] <balloons> it's pythonic stuff.. I'm not the best authority on python, but :-)
[18:21] <balloons> so we use those to be able to pass a function for our assert call with eventually in it
[18:31] <xeranas> balloons: I played bit with autopilot vis tool and find it very useful. However in time when I tried find e.g. those cells where user can enter numbers I was unable to. Now I see writen test for new button and it was used object name "blockgrid"
[18:31] <balloons> xeranas, for sudoku touch?
[18:31] <xeranas> yes
[18:31] <balloons> xeranas, gotcha.. they are in the vis tool, you can see me find them in the video. Umm, basically look at the pages themselves
[18:32] <balloons> I'd have to fire up the vis tool but you learn how Qt apps lay out there objects
[18:32] <balloons> I found it using the vis tool, then went a looked at the qml quickly to understand things
[18:33] <balloons> but if you ever get stuck, feel free to ask me, or even the developers themselves as they wrote it so they should know :-)
[18:33] <balloons> xeranas, sometimes it can be confusing though, I certainly understand that
[18:36] <xeranas> Is it normal that objectName value field is blank?
[18:37] <balloons> xeranas, unless you've defined it, yes
[18:43] <doanac> asac: they are in the queue and running
[18:44] <asac> doanac: awesome... what do you think is ETA beforfe i see stuff on dash?
[18:44] <asac> (no need to fastpath, just wonder)
[18:44] <doanac> asac: probably around the top of the next hour.
[18:44] <doanac> we pull from jenkins every 30 minutes
[18:44] <asac> ok so in 1:20
[18:44] <doanac> and most of the smoke touch jobs are done
[18:44] <asac> oh so even in 15
[18:45] <doanac> asac, yeah probably about 20 minutes
[18:45] <asac> doanac: do you have the openvpn host at hand?
[18:46] <doanac> asac: you mean the private jenkins url or the url of the openvpn server?
[18:46] <asac> doanac: gateway for setting up the vpn for now
[18:47] <doanac> batuan.canonical.com :1192
[18:50] <asac> doanac: ok ... can you /msg me an example url so i can test?
[18:51] <doanac> asac: https://wiki.canonical.com/UbuntuEngineering/QA/VPN
[18:51] <asac> nice
[18:51] <asac> works
[18:51] <asac> and still have access to inet
[18:51] <asac> nice pow 2
[18:56] <balloons> buonasera Letozaf_
[18:57] <Letozaf_> buonasera balloons :D
[18:58] <Letozaf_> balloons, what should we do with the rssreader app ? do you think I should try it with Xephyr ?
[18:58] <Letozaf_> balloons, or should I just wait for  fginther  to solve our problems ?
[18:59] <fginther> Letozaf_, :-)
[18:59] <Letozaf_> fginther, :p
[18:59] <Letozaf_> fginther, if I can help someway... but it works on my box
[19:00] <fginther> Letozaf_, I understand, It also works on my box. I have one task I'm trying to wrap up, then I'll start debugging this again. It's still possible that jenkins has some environment issue.
[19:01] <Letozaf_> fginther, oh good, so I will wait :p
[19:01] <fginther> Letozaf_, sorry for this issues here.
[19:01] <Letozaf_> fginther, no worries I have fun, so no matter
[19:02] <Letozaf_> fginther, I like hacking :p
[19:02] <fginther> Letozaf_, that's good! I'm sure there is lots more hacking ahead :-)
[19:03] <Letozaf_> fginther, cool :-)
[19:03] <balloons> Letozaf_, fginther I'm going review another merge proposal then and hang tight on this :-
[19:03] <balloons> I actually have 2 to do :-p
[19:03] <Letozaf_> balloons, ok let us know how the work
[19:04] <Letozaf_> balloons, sorry they work
[19:05] <doanac> asac: maguro results are up. the mako jobs are still queued waiting for another test to complete
[19:07] <asac> doanac: sure?
[19:07] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/image/2999/
[19:08] <asac> grouper looks better
[19:08] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/image/2998/
[19:09] <asac> doanac: whats the easiest way to find my way from https://jenkins.qa.ubuntu.com/job/saucy-touch-grouper-smoke-friends-app-autopilot/5/? to the internal stuff?
[19:09] <doanac> replace jenkins.qa.ubuntu.com with <IP_ADDRESS>:8080
[19:11] <asac> doanac: not correct :)
[19:11] <asac> you also have to replace https: by http:
[19:11] <asac> (for me)
[19:11] <doanac> asac: maguro jobs didn't run because the main smoke job failed: http://<IP_ADDRESS>:8080/job/saucy-touch-maguro-smoke-default/47/console
[19:12] <doanac> looks like networking problems maybe
[19:12] <doanac> should i try running it again?
[19:13] <asac> doanac: quick questionm .. "restarting device" ... does that use the PDU?
[19:13] <asac> or does it try soft?
[19:13] <doanac> no, just a soft
[19:13] <doanac> the phones can't use a PDU right now, because disconnecting power requires you to physically press a button
[19:13] <doanac> we are still working on modding the devices to support that
[19:13] <asac> ok
[19:13] <asac> one sec
[19:14] <asac> so ... can we at least try to pull off something through "normal" adb
[19:14] <asac> at the end?
[19:14] <asac> seems we dont even pull of syslog
[19:14] <asac> in case ssh doesnt work
[19:14] <asac> correct?
[19:14] <asac> we have to pull something off if we can adb, but not ssh
[19:14] <asac> and let people see
[19:14] <asac> then we can KNOW whether its really a network issue :)
[19:15] <doanac> asac: yeah, i can try and mod the job.
[19:15] <asac> and we could even report that as a "very basic smoektest"
[19:15] <doanac> i haven't looked at this job closely before.
[19:15] <asac> so yuou see: yeah, we can log int
[19:15] <asac> and yeah we saw network up there
[19:15] <asac> and yeah, we can ping the device
[19:15] <asac> etc.
[19:15] <asac> maybe the "default" woyuld at best run through normal adb alltogether?
[19:16] <doanac> asac: that's the real fix, is that "default" shouldn't have to do all the SSH stuff.
[19:16] <asac> like for jobs that dont need to scp -r, we can just copy file with adb push
[19:16] <doanac> this is left over from early testing paul did
[19:16] <asac> and then always get results
[19:16] <asac> right :)
[19:16] <asac> so we agree
[19:16] <asac> sounds simple enough to do default if the code is like i can imagine
[19:16] <doanac> they really need to move over to my run_utah_phablet.py script
[19:16] <asac> i assuming merging results with utah.output
[19:16] <asac> woudl be the hardest part
[19:17] <asac> unless there is a utah-config --merge :)
[19:17] <asac> alreawdy
[19:17] <asac> lol
[19:17] <asac> i thknk i get a dejavu
[19:18] <doanac> let me poke around this job and see if there's some simple updates I can add to improve. then when paul gets back we can make this work the right way
[19:18] <asac> yeah. well. at least pulling "raw syslog" at beginning and end
[19:18] <asac> should be trivial'ish
[19:19] <asac> with default landing later as a special job or something
[19:20] <doanac> exactly
[19:21] <asac> and an easy retry bot here
[19:21] <asac> !utah-rekick XXX
[19:23] <xeranas> balloons: It seems that on test_new_game_button (sudoku) there no validating that actually test if new grid with new numbers was generated. However because its random thing there exist chance that it generate same grid so probably better leave it as it is?
[19:58] <knome> stgraber, each testcase has this text at the end:  http://iso.qa.ubuntu.com/qatracker/milestones/270/builds/48777/testcases/1310/results
[19:58] <knome> stgraber, "If all actions..."
[19:58] <knome> stgraber, this is something we need to manually insert to the testcase text
[19:59] <knome> stgraber, can we make it appear automatically at the end of each testcase programmatically, rather than having to maintain that text in the testcaes?
[20:00] <stgraber> yeah, should be easy enough, though that'll have to wait till next week, I'm not touching the tracker this week, I've got all my work for July and most of that for August to do by EOW ;)
[20:04] <knome> sure, and you'll need to cooperate with me or balloons
[20:04] <knome> we don't want the text appear twice..
[20:09] <stgraber> yeah, I'll Cc you on the RT once I'm done with the changes so you'll have a rough estimate (depending on how busy IS is) of when this will land
[20:13] <knome> awesome, thanks
[20:13] <knome> also, did you read the backlog?
[20:14] <knome> we were considering adding a simple JS script to help with the testcase numbering
[20:14] <knome> firstly, we want to remove test case names
[20:15] <knome> but that also means we won't have test numbers (useful when you have many tests inside one testcase)
[20:15] <knome> the js script would go through all
's in the markup and add an additional element that says "this is the test number N in this testcase" or sth
[20:21] <balloons> xeranas_, I'm not sure I get your question
[20:21] <balloons> xeranas_, you mean the test new game doesn't check for a game grid to be created? if it doesn't let's add it :-)
[20:28] <asac> doanac: did you rekick maguro?
[20:28] <asac> (not sure if i distracted you too much :))
[20:34] <doanac> asac: let me re-kick. got distracted by something else
[20:36] <asac> doanac: and maybe double check that mako is still queued/running
[21:22] <phillw> balloons:  ping :)
[21:49] <Noskcaj> balloons, who else needs adding to wiki.ubuntu.com/QATeam/WhoWeAre ?
[21:55] <balloons> phillw, pong!
[21:55] <balloons> Noskcaj, hmm
[21:56] <balloons> Noskcaj, that's a really nice list of the regulars
[21:57] <Noskcaj> It seems to be most of the "voluntary" people covered.
[21:57] <phillw>  balloonssoz, I was AFK. the area for bugs has now been updated (I know you always ignore my emails :P )
[21:59] <phillw> balloons: the https://wiki.ubuntu.com/QATeam/Overview/ page does not seem to be mentioned... where do you think it should be?
[22:00] <balloons> The activities page and the main page perhaps
[22:01] <balloons> Noskcaj, lol, we can't force those who don't want to share to do so
[22:01] <balloons> we could make it part of the signup process though
[22:01] <balloons> we recommend mailing the mailing list to say hello and adding yourself to the page
[22:01] <balloons> Noskcaj, make sense?
[22:01] <balloons> I would support that
[22:01] <Noskcaj> yep. sounds good. and it helps us monitor contributor levels
[22:01] <Noskcaj> i'll work on it thisafternoon
[22:01] <balloons> just make sure we don't sound like it's required to be a part.. :-)
[22:02] <phillw> balloons:  I'd also support that they take the time to file a hardware profile, if they are going to say WHO they are, it does make sense to say WHO their computer(s) is/are.
[22:06] <balloons> sure indeed
[22:07] <phillw> balloons: is https://wiki.ubuntu.com/Testing/Cadence fully up to date?
[22:14] <Noskcaj> balloons, latest from kirkland: He's always going to be too busy to help host a testdrive hackfest but is willing to answer some questions if necessary. He is willing to give someone commit privileges when they earn it.
[22:14] <balloons> Noskcaj, ok, so perhaps you and howard can help do it then..
[22:15] <balloons> I would wait till howard returns from london :-)
[22:15] <balloons> but we could schedule it now
[22:15] <Noskcaj> yes and yes
[22:15] <Noskcaj> I don't have time to schedule it right now (school in 5 minutes) but i'll send an email off when i'm at school
[22:16] <balloons> phillw, umm hmm
[22:17] <balloons> phillw, I updated the page because it had some bad links, but I'm also confused because it was showing cadence week three as this week not next
[22:19] <Noskcaj> phillw, Where is that hardware profiles wiki page you made?
[22:20] <phillw> balloons: I suggest that on the Activities page, we make bugs a bit more prominent
[22:20] <phillw> Noskcaj: https://wiki.ubuntu.com/QATeam/Hardware
[22:20] <Noskcaj> Thanks
[22:21] <balloons> phillw, I think the page is a bit better now: https://wiki.ubuntu.com/QATeam/Cadence/Saucy
[22:21] <phillw> It's still a manual convert until the 'new' system comes available - but at least their profiles will not 'vanish'. That's the best I could come up with when profiles were still vanishing :/
[22:24] <phillw> balloons: we have a section on activities for bugs.... buried in the small print at 4.2 on https://wiki.ubuntu.com/Testing/Activities It already points to the overview page. Maybe it warrants a higher ranking?
[22:26] <balloons> phillw, indeed.. it might be time to refresh that page again
[22:26] <balloons> smaller and more concise is always better
[22:26] <balloons> it always gets so long
[22:27] <balloons> I still would like a section on running the development release.. I'm not sure what happened to that
[22:27] <phillw> it is called mission creep, and something I'm well aware of from the early days of lubuntu :D
[22:30] <phillw> balloons: give me an hour, and I'll have a draft up for you. (It's a "no brainer" for me to do the restructure, but on this occaision, you're the boss :D )
[22:30] <balloons> phillw, feel free to edit away
[22:30] <balloons> we can always revert easy enough, so it's no worries
[22:30] <balloons> I appreciate the look over :-)
[22:37] <fginther> balloons, fyi, the ubuntu-rssreader-app UI has changed and Letozaf_'s tests are completely broken as currently written (I can't figure out how to add and remove feeds with the new interface).
[22:37] <balloons> yea, she fwd'd us that mail from joey
[22:38] <balloons> it's ok, provided we don't issues again when we try and redo them
[22:38] <balloons> the calendar also has some UI work going on that will break things afaik
[22:38] <fginther> balloons, ack
[22:39] <phillw> balloons: that is one seriously messed up page.....  I'm just coming up for air! Wiki will be the death of me.... I forgot just how painful it is to convert a 'long' page back to the approved structure... :/
[23:44] <phillw> balloons: are you busy?


[11:44] <akc42> New here.  Just blown a liveCD of the beta, and its behaving really strangely when I boot - can anyone here help?
[11:45] <MetaMorfoziS> good night all!
[11:47] <akc42> Mmmm - seems a bit quiet.  I'll go try the mailing list.  Bye
[11:55] <uros> can noone help with embedding the real player in konqueror? real player installed, works in firefox, but not in konqueror - could be plugin issue, although it appears to install the plugin
[11:57] <synie> hello
[11:58] <synie> i installed ubuntu on my old system. it has a nForce2 chipset. ubuntu detects it, and lspci lists the nforce-networkinterface and an other card, i plugged in. but there isn't any ethX o,O can some1 help me ? how can i activate the cards
[12:02] <taka> lo ppl