[00:42] ping veebers, should we change the debian/control to depend on python3-xlib (>=0.14+20091101-1ubuntu3) ? [00:44] elopio: this is for autopilot? Yeah that's a good idea. It's not like it will affect anything other than vivid (and above) [00:49] elopio: I'll fire up my vm and make sure the fix resolves all issues [00:52] veebers: ok. I've confirmed it installing the package from the ppa, but it would be good to give it another try. [00:52] I have rerun the jenkins job in my branch... [00:55] elopio: has it run yet? I'm not sure if something like this means that there needs to have another otto image respun (or something along those lines) [00:56] Well my check tests work, and the package is available in the archive now which is good [00:59] veebers: it's running. I thought it just needed an update on the archive, but now I'm not sure. [01:05] elopio: I'll double check with ci [03:57] elopio: hey, you around? [03:59] I was banging my head trying to figure out why --testname wasn't doing what I wanted, turns out it if I put it before --unbuilt-tree it works fine. [03:59] perhaps I need to read the fineprint === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === vrruiz_ is now known as rvr [10:29] * kalikiana what might this be? [10:29] RuntimeError: Unable to instantiate any backends [10:29] X11: DisplayConnectionError(':0', b'No protocol specified\n') [10:30] it's a runtime error [10:30] more specifically a display connection error [10:30] and even more specifically, an error where no protocol is specified [10:30] kalikiana, that help? ^ (: [10:30] knome: what would I do without you :-D [10:31] probably live on the streets and beg people to buy you beer [10:32] it's a weird error, though, autopilot just stopped working, I can't see what would have changed [10:32] heh :) [10:32] weird errors, best errors [10:33] I even switched back to upstart just in case, since I know there's an open bug for some of the app launching backends, but same error [10:34] i wish i could help, but i know nothing of autopilot :) [11:02] problem solved… somehow… did a package upgrade, rebooted, something fixed it [11:02] kalikiana, knome that runtime error might be related to this https://bugs.launchpad.net/autopilot/+bug/1432700 [11:02] Ubuntu bug 1432700 in Autopilot "Autopilot3 on vivid desktop fails: "RuntimeError: Unable to instantiate any backends"" [Undecided,New] [11:03] kalikiana, knome it seems that python-xlib has been already updated https://bugs.launchpad.net/ubuntu/+source/python-xlib/+bug/1432889 [11:03] Ubuntu bug 1432889 in python-xlib (Ubuntu) "Creating Display() fails with "Xlib.error.DisplayConnectionError: Can't connect to display ":0": b'No protocol specified\n"" [Undecided,Fix released] [11:04] fgimenez: ah, so it seems I got that python3-xlib upgrade just now [11:05] the versions match [11:05] and I'm having the "faulty" python3-autopilot [11:13] kalikiana, in fact python3-autopilot doesn't impose what version of python3-xlib to install [11:14] kalikiana, if you install python3-autopilot anew it will pick the current version of python3-xlib available [11:32] kalikiana, please remember to ping ubuntu-qa if you hit this kind of problems :) === paulliu1 is now known as paulliu === txspud|ORS is now known as txspud [15:09] elopio, rhuddie, fgimenez - time for a look at https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/create_online_accounts/+merge/253330 [15:09] elopio, rhuddie, fgimenez - apologies for some of the things that look really hacky, most of them are necessary (i think :P) [15:38] ubuntu-qa: when I run an adt test, it seems like it always sets the screen to turn off after the configured amount of time, even if I've used powerd-cli to ask it to stay on. Is there a way using adt-run to leave the screen on after the test completes? [15:43] fgimenez: I know this one. [15:43] fgimenez: nuclearbob: you would have to modify the adb script, because on cleanup it kills power-cli [15:44] http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/ssh-setup/adb#n270 [15:44] elopio: okay, cool. I can work around that for now [15:44] elopio, ok thanks [16:29] fgimenez, good spots on my mp. i'll fix those when i'm back [17:19] barry: I've added check_for_update and download to the dbus upgrade branch [17:19] now I get http://paste.ubuntu.com/10622087/ [17:20] I won't be able to nail this without your help, so please ping me when you have some time to pair on it. [17:20] I'll be working on the reflash in the meantime. [17:20] ubuntu-qa: anyone with a device running rtm stable who can check something for me quickly> [17:20] I promise it will be quick :-) === chihchun is now known as chihchun_afk [17:21] balloons: go on [17:22] davmor2, install the 'help' app from the store and run it. I just want to see a screenshot of what it looks like when it opens [17:23] davmor2, it's called 'help', author is ubuntu core app developers [17:28] balloons: http://people.canonical.com/~davmor2/screenshot20152318_172349829.png [17:28] davmor2, awesome.. looks like the app works just fine [17:28] ty === chihchun_afk is now known as chihchun [17:48] elopio: hi. i'm back from lunch now [17:49] elopio: did you dpkg -i the system-image-common deb? [17:50] that *should* have laid down a /usr/share/system-image/archive-master.tar.xz{,.asc} files [17:50] (that's for si 3.0) [17:58] elopio: as to the test_apply_update_noop failure, i think you'll want to look at this branch: https://code.launchpad.net/~barry/ubuntu-ota-tests/packaging/+merge/253357 [17:58] esp. the changes to hooks.py and reactors.py for si 3.0 [17:59] barry: right, you did it nicely. On my branch I just replaced reboot for apply. [17:59] I'll use yours as a prerequisite. [18:00] barry: and system-image-common is installed from your ppa. [18:00] elopio: cool. ping me when you've pushed an update and i'll try again [18:00] elopio: hmm, that's odd. -common should definitely include those files [18:00] hum, but that's installed in the temp folder. [18:01] let me try making it rw first. [18:03] barry: I'm getting this with adt-run --unbuilt-tree=. --- ssh -s adb on your packaging branch: [18:03] http://paste.ubuntu.com/10622339/ [18:05] elopio: i've seen these locale problems before. tbh, i don't know what causes them or what the fix is, but in the past these haven't actually broken tests or functionality [18:05] barry: I think the perl warning is not the problem. Just fakeroot not found. [18:05] elopio: ouch. yeah, nfc about that one :( [18:05] barry: are you sure we shouldn't use adt-run -B ? [18:07] elopio: with my branch i'm pretty sure (not 100% positive ;) since you want the package-being-tested's version of ubuntu_ota_tests [18:07] so you want to build the package and have that installed on the device, iiuc === chihchun is now known as chihchun_afk [18:12] I don't understand this part. I'm not sure how we got the ubuntu-sanity-test to work with -B and --unbuilt-tree. [18:12] elopio: iiuc, -B just means the dependencies will be resolved from the archive, but right now there is no ubuntu-ota-tests in the archive [18:12] as far as I can tell, both branches are pretty much the same. [18:13] (and it would be the case if the in-dev package were ahead of archive for it's non-debian/tests stuff) [18:13] barry: yes, the sanity is not on the archive. I thought that adt-run was building and installing it from the branch, just getting the rest of deps from the archive. [18:14] elopio: when port this patch from my branch to yours, everything passes: http://paste.ubuntu.com/10622390/ [18:14] elopio: it's entirely possible i do not understand the manpage ;) [18:14] barry: yes, I got a successful run, just the reboot to recovery didn't work. [18:14] so the check, download and apply are working, just the custom ini file is not. Which is progress. [18:15] * barry nods [18:15] I'm trying to get your branch working so I can merge them. [18:16] elopio: hmm. it's weird cause it wfm [18:17] maybe i should try to reflash my device, reinstall the debs and try it again? [18:17] wouldn't hurt :) [18:17] elopio: okay! :) [18:45] barry: I got it. Your branch needs this dif: running-tests.html [18:45] sorry. [18:45] http://paste.ubuntu.com/10622608/ [18:46] that way you can run with -B --unbuilt-tree. I think that's because adt will copy the source to the testbed, and put it in the path. As the python package doesn't need to be built, it will just work. [18:47] I still don't know why without -B it fails for me, but I really don't care. I'm good to merge it now :) [18:48] elopio: sounds good to me ;) [18:48] elopio: i guess i should make that change to my branch? [18:50] barry: yes, please. [18:50] I made a typo, I left an extra "cd". [18:51] elopio: k [19:15] barry: you might need to merge with trunk too. I think that's why I'm seeing a weird diff here. [19:18] elopio: ok. i'll look at that after finishing the test with the -B changes [19:26] elopio, is the UITK helpers story at risk? [19:26] elopio: i'm still not convinced about the -B ;) [19:26] barry: Hey I see the packaging branch :-) [19:27] brendand, elopio: If they depend on the fix in autopilot being released before tomorrow then I would say so [19:27] We could try get an autopilot release before then [19:28] Although we might need to get a FFe for autopilot? [19:28] veebers: yep! [19:28] veebers, i hadn't realised that was what was blocking it [19:28] barry: nice, sorry I wasn't of much help there. Does it currently still build on the device? [19:29] brendand: I don't know if it's blocking it exactly but I know that it needs to get done at any reate [19:29] rate* [19:40] veebers: this might be interesting: https://code.launchpad.net/~canonical/ubuntu-ui-toolkit/autopilot-listview/+merge/252771 [19:40] veebers: agh, wrong paste. Like the third today. [19:40] https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1414122 [19:40] Ubuntu bug 1414122 in autopkgtest (Ubuntu) "adt-run arguments are order dependent" [Undecided,Won't fix] [19:44] elopio: ah right, cheers ^_^ [20:05] elopio, brendand: according to robru in u-ci-eng, bugfixes can land as normal [20:08] elopio: CI failed for this MP: https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/autopilot-nolivedragging/+merge/253398 [20:08] brendand: oh if you're keen to review that branch I'll leave it alone :-) [20:09] veebers: there are some issues with the fake apps, that are unrelated to this branch. [20:09] https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/1623/testReport/ubuntuuitoolkit.tests.custom_proxy_objects.test_qquicklistview/QQuickListViewReorderingTestCase/ [20:09] could be the same that the unity guys are seeing, so it sounds like we'll investigate on that soon. [20:09] veebers, if you could make sure that the re-imaging branches are progressing that would be the best thing i think [20:11] barry: does this sound familiar to you? http://paste.ubuntu.com/10623122/ [20:11] (sorry for throwing at you so many weird errors in such a short amount of time) [20:11] brendand: ack [20:12] elopio: naw, it's cool. but... ! i think someone else saw that once, but i have no idea what's causing that [20:12] dbus seems unhappy [20:12] barry: it scared me, I panicked and reflased :) [20:12] *reflashed. [20:13] elopio: probably a reboot would do the trick, but gah, that's nasty [20:14] elopio: what's the magic "don't lock screen me after a reboot" file? [20:14] I was getting plenty of out of memory errors before, so I think I better start fresh for my own sanity. [20:15] barry: I don't know about that magic file. It was brendand who said it. What I know is that adt-run should unlock your device. [20:15] if that's not happening, we are missing one step. [20:16] elopio: let me try to re-run it [20:16] barry: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/ssh-setup/adb#n234 [20:17] we are calling ubuntu_prepare_for_testing after the reboot, so you shouldn't get the lock screen.. [20:43] barry: are you able to ack packaging changes? this one in autopilot, https://code.launchpad.net/~canonical-platform-qa/autopilot/xlib-version/+merge/253399 [20:43] * barry looks [20:46] veebers: not sure i do, but i approved it anyway :) [20:48] barry: ack, thanks ^_^ [20:50] balloons: so I guess the using -autopilot channel for autopilot talk went walkies [20:51] elfy, this is mostly just the canonical qa team chatting more in here. Today it's autopilot, but tomorrow it'll be something else :-) [20:51] doubt that - unless it's going to be different than the last weeks [20:52] not really anywhere for the rest of us now it seems [20:53] like where could people talk about the non booting images - that'd not get drowned out by autopilot [20:53] for instance [20:59] elopio, so to confirm these failures are all okay? https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/1623/ [21:00] well not 'ok' but known and not related to the change [21:03] elfy, I like life in the channel, but I don't want to make you feel drowned out. You are always free to chat about whatever here; including broken images [21:04] mmm [21:06] elopio, veebers - someone needs to proxy for rhuddie on this MP - https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/create_online_accounts/+merge/253330 [21:06] when you have the time [21:08] brendand: ack, added to the stack :-) [21:14] veebers: can you review the packaging branch? [21:16] barry: can do, added to my stack. should be unwinding it shortly [21:16] veebers: cool, thanks [21:17] balloons: I understand having a channel that doesn't appear dead is good, but if someone was trying to get people to notice that images were fubar 2 hours ago - who'd actually notice amongst all this autopilot talk :) [21:17] I know that unless I'd been pinged that I'd not try and wade through hours of it looking for something [21:18] elfy, if something is seriously that broken you should probably not bank on someone noticing an unaddressed message on IRC [21:19] that's not the point I'm making - but never mind [21:19] but yea, ping in the channel and you can get a realtime response, which is nice. Having more people here makes it more possible someone will respond [21:19] just don't see the point in having 2 autopliot channels [21:20] elfy, we're not strictly speaking talking about autopilot, not always anyway [21:21] elfy, most of the chatter is from the Ubuntu QA team (my team) and we want to be as open as possible about what we're working on [21:21] you appear to be working on autopilot a whole lot :p [21:21] * brendand actually isn't even in #ubuntu-autopilot, heh [21:22] but as I said - not appearing to have a dead channel is always positive [21:22] but after 2 mentions of images being fubar - maybe even a - really? they that bad? comment wouldn't go amiss [21:23] wait, is the something wrong with the images? [21:23] I guess the thing is this is the only channel that flavour QA people are likely to all be in [21:23] d: [21:23] knome: hatez you ... [21:24] :p [21:24] just stirring it up (and rubbing some salt on the wounds at the same time)... [21:24] well after this cycle's images - the wounds are all battle hardened ;) [21:24] it'd take more than salt [21:25] * balloons notes knome shows up right on queue [21:25] you mean cue? [21:25] :P [21:25] elfy, much of the chatter is testing (go figure right!?). This is typically automated or manual, and obviously autopilot plays a role in automated testing. But there are other types, and there has been chatter about them [21:25] balloons, you've been smacked with the grammar baton [21:26] ouch, a well deserved hit! [21:26] but queue is SO much more fun to type than cue [21:26] :P [21:26] cue, ue, ue [21:26] cue.pop() doesn't have the same ring [21:27] balloons: I said my peace, I don't really expect anyone other than a flavour QA person to understand my pov [21:27] waiting for knome ... [21:27] elfy, ack, fair enough [21:28] sadly balloons didn't notice [21:28] elfy, i do understand your point of view. i'm just not sure if the alternative (moving to ubuntu-autopilot and talking in an echo chamber) is better [21:28] yeah, i would prefer if autopilot talk was on its own channel [21:28] that's not what I was waiting for knome :D [21:28] * balloons suddenly fears needles [21:28] nobody's proposing that you only need to talk there, but most of the autopilot development talk isn't of interest for most [21:29] elfy, eh eh ;) [21:29] elfy, knome: Fair enough, autopilot does have its own channel, but I would hate to see communications go down just to silo the different topics [21:29] knome, but that's just it, we're not talking about developing autopilot, which i admit is a niche interest (hi veebers!) [21:29] (communications as in Canonical qa team members being more vocal in channel) [21:29] knome, we're talking about the work we're doing, and autopilot is a tool we use heavily in that [21:29] brendand: lol [21:30] brendand: There are dozens of us, dozens! [21:30] brendand, honestly, with no snarky tones, how useful do you think that is to the broader qa community? [21:31] knome, i know that ubuntu developers care a lot about what we're doing [21:31] and a related question, how much of it could go in a different channel without anybody in this channel "missing" anything? [21:32] i know some of them are here, but this is not *really* the channel were the ubuntu developers hang out [21:32] knome, the question is which channel. i know it's definitely *not* ubuntu-autopilot unfortunately (though it might seem logical to you) [21:32] :) [21:32] perhaps I'd feel differently if *we* could even use any of this automated satuff [21:32] it's mostly a balance thing [21:32] elfy, well you can - whether you'd want to [21:33] knome, really our only alternative atm is to crawl back into our cave :( [21:33] knome, that would make me sad [21:33] don't feel sad [21:33] caves are cold [21:33] and wet [21:33] * knome offers brendand a cookie [21:33] and dark! [21:33] wish I'd just carried on muttering to myself now [21:33] and there are often bears in them :O [21:34] it's a fine discussion. But elfy some of these guys do manual testing too [21:34] could there be some kind of compromise? [21:34] not with today's images they don't balloons ;) [21:34] keep the deepest discussion in the cave, put the lighter here [21:35] balloons: because they're fubar :p [21:35] And I want them to talk about it in here also. Talk about the phone images and the testing they are doing on them. And yes, the desktop images could use more discussion. I don't think chasing them away is going to help though :-( [21:35] I don't want to chase anyone anywhere - that implies effort [21:36] lol [21:36] mmm.. well said [21:36] well i don't want to chase anyone out of here... [21:36] knome, the difficult is how to split it [21:36] all that I am trying to say is that if someone did come in here to try and talk about a *normal* issue [21:37] brendand, suggestion: try to keep the sprint-like stuff in the designed channel? [21:37] brendand, is -autopilot logged? [21:37] elfy, I guess my question is, isn't this 'quality' discussion? [21:37] knome, the division between open/non-open is easy to manage, but after that it becomes difficult [21:37] would the Canonical QA people notice that sufficiently that if someone came in 2 hours later - they could at least say - oh yea that elfy guy was muttering about that [21:37] knome, it is [21:37] has been for a bit [21:38] balloons: ofc it is [21:38] elfy, you can ping them directly now.. use ubuntu ---- qa. <-- I'm trying to avoid pinging, but see topic [21:39] sigh [21:39] you miss my point :D [21:39] look [21:39] so hey elfy, I am the manager for ueqa, and this conversation is the catalyst for me pushing for a qa person on the desktop team, so fwiw, there you go [21:39] elfy, I feel your point is stuff that is important to you will get lost. I totally get that [21:40] I think there needs to be just as much desktop image discussion in here [21:40] there should be someone dedicated to that work [21:40] or am I not getting it elfy ? [21:40] balloons, everybody is welcome, but balance in everything [21:41] if I came into this channel 5 hours ago - trying to see if anyone else was seeing an issue, and that 2 hours later someone else comes in here same thing - would the Canonical QA team - who are in here talking a lot notice that and be able to mention to the person just wandering in? [21:42] it doesn't matter WHAT people are talking about as long as what others say gets noticed [21:42] elfy, if there are people active in the channel across the time period, the likelihood someone would is higher. That said, I'll just agree with the premise and say no they won't. My question then is, how is that better than it is now, with most questions going unanswered at times we aren't here? [21:42] I give up [21:42] the channel is useless to me now [21:43] elfy: That's a little depressing seeing as though the reason the canonical team chat here more often is that we want to be closer to community people [21:44] elfy: the addition of more people chatting doesn't remove the possibility of the previously existing people mentioning past comments (as per your example above) [21:44] Well for what it's worth I do think the point about developing autopilot directly should go into that channel, but I would like the testing talk to stay (actually I'd like to see more of the manual testers chatting in here more even) [21:44] veebers: well if the canonical team don't actually take any notice of things community people might be trying to talk about - what other possible view could I take [21:44] veebers, i appreciate that very much, but otoh, if it means the important community-to-canonical messages will not be noticed because of that increased communication, it's a bit moot [21:45] surely if anything it should mean there is more chance of message pass around [21:45] veebers: I'd have hoped so - but balloons said that you won't [21:45] knome: if the message isn't received because of the amount of people in the channel, something is broken, and I don't think it's the amount of people or chatter [21:46] knome: if those messages are being missed or dropped then the communication channel needs to be improved [21:46] veebers, suggestions on that? [21:46] veebers: I think elfy has a point, but the more successful a channel is the more backlog it is likely to have [21:46] (not irc channel, the way the message is sent) [21:46] conduit would perhaps have been a better works [21:46] so perhaps another mechanism to highlight problems is necessary [21:47] so that they don't get lost in the chatter [21:47] knome: nothing specific at the moment but we're all open to suggestions [21:47] we could build a bot that takes queries [21:47] and folks who find issues can load them on [21:47] jfunk, would you think something like the irc team uses - a factoid that shouts out nicks - would work? [21:47] jfunk, knome: right, this is the conduit that I mentioned. We need to make sure ther is a way to ensure any important messages get to the right people and are visiebl [21:48] visible* [21:48] knome, like the !help !ops bot? [21:48] balloons, yes [21:48] kind of what's tried to be achieved with the ping stuff in the topic - but instead of making people add something to their highlight list, managed the highlighted people manually [21:49] knome: perhaps it could, we need to figure out something that folks like the idea of, and set it up, perhaps put a note in the topic of the channel that it exists [21:49] or the channel-join event [21:49] now the question is - how many of those people are around often enough [21:49] would a bot allay some of the concerns? [21:50] not sure that addresses my point at all tbh [21:50] elfy: to clarify your concern; is that important messages get lost in the crowd of chatter? [21:51] not so much that [21:51] or rather - possibly [21:51] really it's just about that all of you now in here talkign all day - actually notice other people coming in and mentioning something [21:52] then remembering if someone else does [21:52] which is what used to happen a month ago [21:52] obviously if people are away - the situation is the same - it gets lost [21:53] elfy, so before reading the backlog of 10 lines was easy to see if anything relevant happened while you were away? [21:53] balloons: yes ;) [21:53] and now that's not possible :-) [21:54] unless you've only been gone 30 seconds :D [21:54] balloons, another sidetrack... how could we improve the tracker in a way that images that are known to be broken are advertised better? [21:54] elfy: sounds like if we had a way for people to register issues and query those issues asyncronously that could go a ways toward making things better? [21:54] balloons, and how would that status be maintained in the tracker, and could it even send notifications outwards? [21:55] balloons, something ala the rebuild notifications on -release? [21:56] balloons, and could/would it be something that some of the canonical people thought important enough to hack together? [21:56] ^ other canonical people too [21:56] knome, broken in what way? broken in a way that was not detected by the automated tests? [21:56] balloons, yes [21:57] balloons, or if something was detected by the automated tests - how can we advertise that out better in the tracker and elsewhere appropriate? [22:01] jfunk: look at this - search for jfunk and the one elfy line, that's what I'm getting at http://pastebin.ubuntu.com/10623652/ [22:03] knome, good questions. Any thoughts on putting it on the tracker directly? [22:03] that in theory would be the most noticable [22:04] another thing to add to the list :p [22:04] elfy: what I am seeing is that you care about a specific topic and it is drowned out in the noise of channel conversation unrelated to the topic [22:04] elfy: uh I hate to be that guy :-) but I see an autopilot issue mentioned by kalikiana, has that been answered do you know? [22:05] balloons: I used to get RSS pings from jenkins from fails, once thats working perhaps that could link to the tracker? [22:05] kalikiana: at any rate, if you're still seeing that runtime error if you upgrade python3-xlib it'll go away [22:05] so I think we could create a way to get a summary of topics with a simple bot query, the only other alternative I can think of is for the whole QA team to start talking back in our private CAnonical channel [22:05] jfunk: not really the answer [22:05] all it needs is for people in the channel to notice stuff ;) [22:06] well now you're talking about human nature [22:06] which is harder to hack [22:06] of course - not expecting miracles [22:06] some options, none of which really address the human nature thing [22:07] would everyone in ubuntu-qa please raise your hand -- o/ [22:07] o/ [22:07] * veebers feels a little lonely [22:07] * jfunk is underwhelmed [22:08] bad timing I guess, late for brendand, elopio is afk, alesage, ToyKeeper, um who am I missing [22:08] o/ [22:08] * alesage rubs eyes [22:08] oh and nuclearbob too :-) [22:08] its after 6 est [22:09] anyhow, that will get ppl to notice, and the other point of drownng out topics [22:09] veebers: it has been answered, an update on good faith had the fix [22:09] could be partially solved with a logger [22:10] kalikiana: excellent [22:10] kalikiana: hah had I read the log a little further I would have seen that it had been resolved :-P Sorry for the noise [22:11] no worries [22:14] elfy, I guess in the notice box> [22:14] ? [22:14] knome, elfy could we rely on manual reporting for this? [22:14] o/ [22:15] well I could rely on manual reporting for Xubuntu if the information is there to start with [22:15] balloons: lets assume that the jenkins thing works [22:16] and that you can RSS the result [22:16] could that not link to the tracker? [22:16] unfortunately [22:16] oftimes jenkins passes something that fails in real life [22:17] so perhaps some manual mechanism - but then - Xubuntu could fail, everything could work [22:18] gets a bit complicated [22:23] ubuntu-qa - thanks for the discussion anyway, not sure that it's very solvable tbh [22:23] np [22:24] lmk if you have other ideas, we need more hands on this, that much is clear [22:24] jfunk: okey doke [22:24] elfy, well sure, we could do something like that [22:25] elfy, link me to the rss feed and I'll try and quick proof of concept tomorrow [22:25] balloons: that's the current Xubuntu one https://jenkins.qa.ubuntu.com/view/Ubiquity/view/Xubuntu/rssFailed [22:25] December [22:26] nothing newer than then is showing - but I think that's known [22:27] elfy: no worries, as mentioned we want to work on and improve communications, so the discussion helped :-) [22:28] balloons: rather than Notices - below "Vivid Daily" but above "You are currently on:" here would work better http://iso.qa.ubuntu.com/qatracker/milestones/326/builds [22:29] veebers: I hope so - I wouldn't want to have you all about for sure, given I'm on the CC it'd be rather odd for me to want less discussion between community and canonical :p [22:29] s/ I wouldn't want to NOT have you all about for sure [22:30] elfy: lol ^_^ [22:30] been awake too long I think - time to wander up the wooden hill :) [22:32] veebers, https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/thinkingoutloud-wrapper-reflash-script/+merge/253018 looks great, there are a couple of minor comments and a sort of question [22:34] brendand: awesome thanks. I have further work on the branch that I'll push uip [22:35] brendand: nice, will address comments shortly [22:36] brendand: hmm with your branch change (using Tests:) I get this failure: /tmp/adt-run.Lt3qvj/build.3R8/real-tree/debian/tests/test_accounts_after_upgrade: ./create_u1_account: not found [22:37] brendand: alesage: re: static analysis [22:37] might need some more tweaking. But at any rate, to use --testname with adt-run it needs to be a named test (i.e. Tests:) and can't be a Test-Command [22:37] what should we do in the QA team [22:37] jfunk yessir [22:37] sounds like this is dev hygeine [22:37] not qa specific [22:38] jfunk, not so for coverity [22:38] jfunk, I agree, it would take some building to make it into a "system" [22:38] jfunk, if we're interested in Coverity then ppl can sign up--if we want a system for it then it takes some work [22:38] brendand, don't you think? [22:39] alesage: what about the lp integration it had [22:39] alesage, coverity is a bit more complex to deploy isn't it? [22:39] is that still available for folks to leverage? [22:40] jfunk this was a script that ran on a cron to do the bug-syncing--Coverity comes with a web interface and we initiated the covlpsync project to just export all the defects into Launchpad-digestible form instead [22:40] brendand, yes it is [22:40] jfunk, strictly speaking it's not specific to us but i think if it's going to happen someone needs to drive it [22:40] jfunk, which would be us [22:40] jfunk, I don't have a view of what the Coverity output is for their Open-Source program [22:40] got it [22:41] jfunk, so static tools would run on each project and dev teams would be responsible for their own analysis and fixing (obviously) but we would have to drive the initial rollout [22:41] jfunk presumably they get a limited set of the bells and whistles but it's functional and/or enough for them to go on (I think they don't get to decide when the scans happen, etc.) [22:41] jfunk, i smell stories [22:42] jfunk, might even be an epic [22:42] aye [22:42] jfunk, brendand yes it's some stories :) [22:42] alesage: can you email me some proposal stories [22:42] jfunk, let's add an epic right now so we don't forget [22:42] tmw if you need to eod [22:42] jfunk, i can do that [22:42] jfunk, brendand we do have some history for it though, but beware of the price and devoting time to support IMO :) [22:42] kk thx [22:42] yes I remember [22:43] brendand, start a doc, e.g.? [22:43] I don't want to sound pessimistic because I agree it'd be a cool thing, but would press us to keep some servers running, etc. [22:43] alesage, start a doc for? [22:44] alesage, the stories? [22:44] brendand, pls let me contribute to story-telling around Coverity if you please [22:44]