[08:10] <persia> StevenK, https://blueprints.launchpad.net/ubuntu/+spec/mobile-mid-karmic-images should probably reference https://wiki.ubuntu.com/Specs/MobileMidKarmicImages
[08:10] <StevenK> persia: Fixed.
[08:10] <persia> StevenK, Thanks.
[08:14] <persia> https://blueprints.launchpad.net/ubuntu/+spec/mobile-unr-karmic-iso-versus-img
[11:13] <Stskeeps_> comment: we have a goal for 1.0 which is day to day usable on a N8x0, which would be stable enough for use
[11:14] <Stskeeps_> where you don't have to go back to using Maemo
[11:14] <Stskeeps_> we have UI quirks at the moment, a bunch of control panels to be made and such
[11:14] <Stskeeps_> let me just upload a presentation people can glance through that will be presented saturday in copenhagen
[11:15] <Stskeeps_> Mer UI is still hildon
[11:15] <Stskeeps_> just with a new layout and theme :)
[11:15] <Stskeeps_> it's hildon-desktop with lipstick :P
[11:16] <Stskeeps_> we use debootstrap and apt-get really - it's a script that makes the rootfs's dependant on the devices
[11:16] <Stskeeps_> HW and platform is entirely seperate
[11:18] <Stskeeps_> 27 august: maybe :) we hope to put out Mer 1.0 before Fremantle release
[11:18] <Stskeeps_> so people can use it when the new nokia devices come out, as a replacement for N8x0 Disablo
[11:19] <Stskeeps_> not yet
[11:19] <Stskeeps_> beta2 soon though
[11:19] <Stskeeps_> www.daimi.au.dk/~cvm/cphnotes.pdf is a presentation i'll be giving on saturday on a danish developer weekend
[11:19] <Stskeeps_> notes on page 19
[11:20] <Stskeeps_> you can get the raw odp if you want :P
[11:20] <Stskeeps_> not sure about videos.
[11:20] <YokoZar> ok
[11:20] <Stskeeps_> our usual guy in maemo.org isn't there to record, and i haven't presented this presentation yet :)
[11:21] <YokoZar> ahh ok
[11:22] <Stskeeps_> what we hope to work with ubuntu is to clean up packages (we have spent some time making diffs from the maemo packaging) and perhaps work together on GTK quirks :P
[11:22] <Stskeeps_> and to gain a shared set of sane packages
[11:24] <Stskeeps_> we aren't exactly packaging experts so there's a need for expertise in cleaning up some things :P
[11:25]  * lbt (as the "Mer build guy") would be happy to talk to anyone about packaging tasks for Mer
[11:26] <YokoZar> Stskeeps_: lbt: feel free to poke us whenever
[11:26] <Stskeeps_> can you repeat that question? :P
[11:27] <lbt> heh
[11:27] <persia> Is the Mer team happy to have their software delivered as "Ubuntu MID"?
[11:27]  * lbt is
[11:28] <Stskeeps_> yes - as long as we are aware it's not a merge of Mer and Ubuntu MID project wise, MID is a variant / seed of the Mer packaging etc, and we hope to work together on packages
[11:29] <Stskeeps_> so it's just another way to bring the Maemo platform to more devices :)
[11:29] <Stskeeps_> but we'd love to cooperate
[11:29] <lbt> that's how I'd understood it (re comment in room)
[11:29] <Stskeeps_> Mer is just making Maemo sane enough to run outside Maemo ;)
[11:29] <lbt> there should be a lot of overlap
[11:30] <Stskeeps_> Maemo GTK is a big one and should be carefully looked into when adopting Hildon. :P
[11:30] <Stskeeps_> because it's the most troublesome problem with adoption
[11:31] <Stskeeps_> are we speaking automated tests or testcases for people to run through?
[11:32] <Stskeeps_> yes, that should be cooperated upon obviously :)
[11:32] <Stskeeps_> we should inherit a lot of quality from hildon testing as well
[11:33] <Stskeeps_> yes, i think there's automated ones
[11:34]  * lbt would also like to mention the build system for the 'agenda'
[11:34] <Stskeeps_> we should definately talk to Maemo Devices and discuss how we can work on this - i'm sure quim gil would be interested :)
[11:34] <lbt> if we're done on testing?
[11:34] <lbt> we use OBS
[11:34] <lbt> which is the Suse system
[11:34] <Stskeeps_> hehe, we use OpenSUSE build service so just a quick overview of how things are structured at the moment
[11:34] <lbt> correct
[11:35] <Stskeeps_> (it can -also- build on ubuntu standard build!)
[11:35] <lbt> so you shouldn't care
[11:35] <lbt> ;
[11:35] <lbt> )
[11:35] <lbt> no... but we have a process
[11:35] <lbt> build+process
[11:35] <Stskeeps_> we will have a presentation in the weekend on OBS as well
[11:35] <lbt> yes
[11:35] <lbt> build also builds the repo
[11:36] <lbt> :Devel->:Testing->:Stable
[11:36] <lbt> and a make-like rebuild
[11:36] <lbt> yes
[11:36] <lbt> we need to review that
[11:37] <Stskeeps_> we do similar but on a smaller timescale :P
[11:37] <lbt> now we end up with things going into :Devel
[11:38] <lbt> and things going into :Testing
[11:38] <Stskeeps_> mer only moves ahead with contributions so cleanup patches, fixing UI quirks, only help to reach the goal :)
[11:38] <lbt> some are new features, some fixes
[11:38] <Stskeeps_> we're getting there but not yet. there's a page on it in the slides i sent
[11:38] <lbt> my concern is we branch
[11:38] <lbt> and we're not setup for that yet
[11:38] <lbt> I expect that :)
[11:39] <lbt> yes.... I am 'concerned' about making sure improvements get back into :Devel
[11:40] <lbt> ( and help get working on OBS )
[11:40] <lbt> and know that we included your patches... yes
[11:40] <Stskeeps_> we'd probably consider you ubuntu developers as any other mer contributors in terms of getting packages up to fashion or UI etc :)
[11:40] <lbt> meh... OBS is just dpkg-buildpkg
[11:41] <lbt> already on lp
[11:41] <lbt> is there more?
[11:41] <Stskeeps_> lbt: not so much :)
[11:42] <lbt> sure... will review
[11:42] <lbt> you are?
[11:42] <Stskeeps_> you'd probably gain access to mer trees as well to work on it as well :)
[11:42] <persia> So, please do schedule something with me :)
[11:42] <Stskeeps_> since it's a cooperation and we can practically just copy in packages from mer to ubuntu
[11:43] <lbt> we can make Mer_0.14LT  ;)
[11:43] <Stskeeps_> *nod*
[11:43] <lbt> 8 weeks!!!
[11:44] <lbt> sounds good.... document somewhere and review
[11:46] <Stskeeps_> i'll take a talk with quim gil etc about maemo upstream now that we have ubuntu in the view and get a process going there
[11:46] <Stskeeps_> over one or more beers ;)
[11:46] <lbt> we also have hildon Qt in the mix
[11:46] <Stskeeps_> in the weekend
[11:46] <Stskeeps_> we have it :)
[11:46] <lbt> it's there
[11:47] <Stskeeps_> it's a variant of qt that looks like hildon
[11:47] <Stskeeps_> it's just as much a pain as maemo gtk ;)
[11:47] <Stskeeps_> http://qt4.garage.maemo.org/
[11:48] <Stskeeps_> in terms of integrating into ubuntu
[11:48] <Stskeeps_> it makes qt apps fit in hildon nicely
[11:48] <Stskeeps_> matchbox wm atm (version 1)
[11:48] <Stskeeps_> oh, keyboard
[11:49] <Stskeeps_> we use hildon input method at the moment but it's getting to be a headache
[11:49] <lbt> we want good solutions.... the earlier the better
[11:49] <Stskeeps_> none of the cool maemo stuff is OSS ;)
[11:49] <Stskeeps_> and i'm personally not a GTK expert
[11:49] <Stskeeps_> so we have a virtual keyboard example
[11:49] <Stskeeps_> and that's it :)
[11:50] <lbt> we need to work on agreeing API/dev stuff
[11:50] <Stskeeps_> also there's problems with upstream HIM we're working on (only support thumb keyboard)
[11:51] <Stskeeps_> we aren't locked to HIM exclusively at least :)
[11:51] <Stskeeps_> it's just a gtk im
[11:51] <lbt> I don't have a HW keyboard
[11:52] <lbt> N800
[11:52] <lbt> need a virtual keyb... don't care which
[11:52] <Stskeeps_> we need a on screen keyboard, we use Hildon Input Method at the moment
[11:52] <Stskeeps_> the virtual keyboard
[11:53] <Stskeeps_> but it needs improvement to be sane for users in the long term, layouts, etc :)
[11:54] <Stskeeps_> *nod* there is some thought maybe to scrap HIM as the benefit isn't so big at the moment
[11:55]  * lbt is not an expert in the implementation in this area
[11:55] <Stskeeps_> it's just about switching gtk im's so :P
[11:56] <lbt> nope...
[11:56] <lbt> thanks.... look forward to it :)
[11:56] <Stskeeps_> 1pm ;)
[11:56] <lbt> heh... sounds good
[11:57] <Stskeeps_> right - thanks, will this session be stored anywhere?
[11:57] <Stskeeps_> the audio of the session that is :)
[11:58] <Stskeeps_> ah, alright
[11:58] <YokoZar> https://blueprints.launchpad.net/ubuntu/+spec/mobile-mid-karmic-use-mer  https://wiki.ubuntu.com/Specs/MobileMidKarmicUseMer
[11:58] <lbt> IRC has timestamps...
[11:58] <lbt> use TTS ...
[11:58] <Stskeeps_> notes will be good :)
[11:59] <lbt> ?
[11:59] <Stskeeps_> enjoy your lunch!
[11:59] <lbt> do we have a headline?
[11:59] <persia> headline?
[11:59] <lbt> for presentation at CPH
[11:59] <lbt> ie Ubuntu-Mid will be built on Mer
[12:00] <lbt> Stskeeps_: thought you may want a 1-liner
[12:00] <lbt> and agree how to express it :)
[12:00] <persia> We could certainly do that.  I think we have consensus about it, whereas last week it was mostly that Stskeeps_ and I thought it was a good idea.
[12:01] <Stskeeps_> *nod*
[12:01] <lbt> it's breaking news now and I think it's exciting
[12:01] <Stskeeps_> lbt: think i'll mention it in my presentation
[12:01] <lbt> right.... gotta go... Stskeeps_ will catch you in #Mer in a while
[12:01] <lbt> bye all
[12:02] <Stskeeps_> yeah, gotta get back to packing all my equipment for tomorrow
[13:27] <Eric_K> is this chan for ubuntu unr as well ?
[15:37] <persia> Eric_K, Yes.


 The chair is heno.
[18:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:02] <heno> Agenda: https://wiki.ubuntu.com/QATeam/Meetings
[18:02] <davmor2> hello
[18:02] <bobbo> hey
[18:02] <cody-somerville> hi
[18:02] <schwuk> hi
[18:02] <stgraber> lot of people tonight
[18:02] <heno> I've moved the technical items to the top of the list to make sure we get to them
[18:03] <heno> great to see lots of new people!
[18:03] <heno> [TOPIC]: Alpha 3 testing status
[18:03] <MootBot> New Topic: : Alpha 3 testing status
[18:03] <heno> sbeattie, davmor2, stgraber ^ your views?
[18:04] <heno> I understand ubiquity is a bit broken still
[18:04] <stgraber> Server looks good except a weird conflict between LAMP and Mail server, I pinged #ubuntu-server about it
[18:04] <stgraber> ubiquity is a bit broken and we have a kernel/usplash bug making usplash to display a black screen
[18:04] <davmor2> there aren't that many things to test till the ubiquity issues get fixed and kubuntu has a number of post install issues
[18:04] <davmor2> thank god it's an alpha
[18:04] <Riddell> fixed ubiquity is being uploaded now
[18:05] <Riddell> davmor2: post install issues?
[18:05] <LaserJock> after Alpha2 I wonder if we need like an ISO testing twitter feed :-)
[18:05] <davmor2> kdesudo, printing, adept, etc
[18:05] <Riddell> ah well, details details :)
[18:05] <stgraber> testing in kvm is still more or less broken for Desktop so I won't be able to help much there. I'll work on Edubuntu and Server images testing for today.
[18:06] <davmor2> As I say post install the install on alternative is fine
[18:06] <ara> have anyone tried virtualbox? is still broken as well?
[18:06] <heno> cr3 will be piloting some more automated install testing for this alpha - Ubuntu/Kubuntu i386/amd64
[18:06] <LaserJock> heno: can we get details of that sent to ubuntu-qa?
[18:06] <stgraber> ara: I tried to install virtualbox and it's still not using dkms on Intrepid so I can't get it to build the kernel module
[18:07] <heno> vbox worked for me about two weeks ago but was broken yesterday
[18:07] <davmor2> I test on hw mostly so pass :)
[18:07] <heno> LaserJock: yes, we'll post the test results and an overview of what we are doing
[18:08] <LaserJock> heno: awesome, thanks
[18:08] <heno> basically we are opening up the Canonical certification infrastructure to also be useful to the wider Ubuntu project
[18:08] <heno> stgraber, cr3 and schwuk are working on that
[18:09] <LaserJock> good news
[18:09] <heno> so it looks like testing will continue most of tomorrow
[18:09] <heno> [TOPIC]: Searching for upstream Debian bugs (bdmurray)
[18:09] <MootBot> New Topic: : Searching for upstream Debian bugs (bdmurray)
[18:10] <bdmurray> I found out that the debian bug tracking system has a SOAP interface somewhat recently and I've written a script for searching package bugs for a string with it.
[18:10] <bdmurray> It's called debian-bug-search and I've added it to the ubuntu-qa-tools project
[18:11] <ara> useful, thanks
[18:11] <bdmurray> I've had some success using it and thought it might be handy for the Hug Day tomorrow with apt
[18:11] <heno> that will be excellent!
[18:12] <heno> is there any documentation available?
[18:12] <LaserJock> bdmurray: do you have some other tools that would be helpful for Hug Days or triaging in general?
[18:12] <davmor2> bdmurray: so is the idea behind it to help confirm upstream issues or to tag the ubuntu bug with the upstream bug?
[18:12] <LaserJock> seems like you do
[18:12] <bdmurray> The idea is to link upstream bugs to Ubuntu bugs
[18:13] <LaserJock> especially with a package like apt it's very helpful information
[18:13] <davmor2> Sounds like a plan
[18:13] <bdmurray> heno: I put a wee bit of documentation in the README for the project but its really straight forward
[18:13] <heno> perhaps we need a tools page under the hug day pages - we could move the 5-a-day and editmoin text  there
[18:14] <heno> they currently take up a fair bit of space on each hug day page
[18:14] <LaserJock> heno: I was actually thinking about having a Hug Day .deb
[18:14] <heno> LaserJock: or at least a bugsquad .deb
[18:14] <LaserJock> or more generally a bugsquader .deb
[18:14] <LaserJock> lol
[18:14] <ara> one question, if we find an upstream bug, let's say, for gedit, that it is already filed in debian bug tracking system, which one should we link?
[18:14] <heno> :)
[18:15] <ara> the gnome bug tracker or the debian?
[18:15] <ara> both?
[18:15] <greg-g> LaserJock/ heno: ++
[18:15] <LaserJock> ara:  both seems reasonable to me
[18:15] <heno> So: Try the new debian bugs tool!
[18:15] <bdmurray> I'd definitely link the Launchpad bug to the debian bug
[18:15] <ara> ok, thanks bdmurray
[18:15] <heno> [TOPIC]: Ubuntu testing teams (StéphaneGraber)
[18:15] <MootBot> New Topic: : Ubuntu testing teams (StéphaneGraber)
[18:16] <bdmurray> The other way might be less useful and you have to use an e-mail interface to work with debian bugs
[18:16] <stgraber> ok, so we currently have basically one team of testers for each derivatives
[18:16] <LaserJock> cody-somerville: ping?
[18:16] <cody-somerville> LaserJock, pong
[18:16] <LaserJock> ah, there you are
[18:16] <stgraber> that's over 400 members counting for all testing teams we have
[18:17] <stgraber> unfortunately we only see a very small part of those participating in ISO testing
[18:17] <stgraber> I don't know if that's better with SRU testing but those team doesn't seem very useful to me as they currently are
[18:18] <stgraber> because people join them and forget about them some weeks later, we don't have a way to contact those testers and don't have (AFAIK) any kind of structure in place at the moment
[18:18] <stgraber> if we take ISO testing as an example, I'd say that for Hardy final testing we had only like 15-20 testers most of them testing distributions they don't use usually
[18:18] <LaserJock> not being able to contact people is particularly difficult
[18:18] <heno> so you're suggesting a restricted testing team like bug-control?
[18:19] <heno> that would let us track it better and might instil more commitment
[18:19] <stgraber> no, I don't think having a restricted team is a good idea but we clearly need to document what the team is for and maybe setup a team mailinglist on LP so we can send call for testing a week before an Alpha
[18:20] <persia> Given the nature of testing, and the desire for more testers, it may be best to have clearly inviting language for any such restricted team "Anyone can join, just ask.  Renewals every three months.  Members are expected to participate in x% of testing targets for the team".
[18:20]  * persia retracts the comment, seeing that it won't be a restricted team
[18:20] <LaserJock> stgraber: are there expirations on memebrship?
[18:20] <sbeattie> is there a reason not to encourage subscription to the ubuntu-qa@ list and announce testing there?
[18:20] <LaserJock> sbeattie: yeah :-)
[18:21] <heno> or we could have two levels, modelled on bugsquad/bug-control
[18:21] <stgraber> there is 6 months expiry IIRC
[18:21] <LaserJock> well, what if a  LP team list is created
[18:21] <LaserJock> and that were to be used extensively for testing announcments
[18:22] <LaserJock> not just "heah, Alpha3 is coming up" but "2008XXXX is invalidated, standby"
[18:22] <LaserJock> I'm not particularly eager to see all that on ubuntu-qa, but on a testing team list it'd maybe make sense
[18:23] <heno> I'm wondering how well the current email notification is working
[18:23] <stgraber> what I'd propose as a start is: reduce expiry to 3 months, create a mailing-list
[18:23] <persia> I thought having LP lists for Ubuntu teams was discouraged.
[18:23] <stgraber> heno: not well as it's opt-in and people don't generally enable it
[18:23] <LaserJock> persia: it is, but in this case it might be a good idea
[18:23] <heno> it's not very good at differentiating between alphas and major milestones where we need more testing
[18:24] <heno> stgraber: sounds good
[18:24] <LaserJock> persia: in the sense of using it specifically to contact members of the team
[18:24] <LaserJock> not for general discussion
[18:25] <heno> we should then look at posting tracker updates automatically to that list
[18:25] <stgraber> we currently have 81 users with e-mail notification turned on
[18:25] <heno> and make sure it's easy for people to filter
[18:25] <heno> by having rich header info
[18:25] <LaserJock> stgraber: you can get email notification from iso.qa.ubuntu.com?
[18:25] <stgraber> heno: we just have to create an account on the tracker and subscribe it to all the testcases
[18:25] <stgraber> LaserJock: yep
[18:25] <davmor2> LaserJock: yes
[18:26] <heno> I'm guessing half of them or more ignore mails for alphas
[18:26] <LaserJock> stgraber: didn't know that, interesting :-)
[18:26] <heno> I'm happy for stgraber to reduce expiry to 3 months, create a mailing-list - any objections?
[18:27] <davmor2> go for it :)
[18:27] <LaserJock> I would just add that I think we could also clarify some of the pages
[18:27] <stgraber> heno: btw, can you also make me a team administrator ? pochu wanted to when he left the team but only the owner can do that :)
[18:27] <stgraber> LaserJock: +1
[18:27] <LaserJock> like the team page and perhaps the wiki page
[18:27] <heno> stgraber: will do
[18:27] <heno> ok, next
[18:28] <heno> [TOPIC]: QA liaison to Launchpad (LaserJock)
[18:28] <MootBot> New Topic: : QA liaison to Launchpad (LaserJock)
[18:28] <LaserJock> heno: are we talking about a @lists.ubuntu.com mailing list?
[18:28] <heno> LaserJock: an LP one I think
[18:28] <LaserJock> heno: we may need to discuss that later, lets move on for now
[18:29] <LaserJock> ok, so in #ubuntu-quality the other day we were discussing some possible improvements to Launchpad that would help in QA efforts
[18:29] <heno> ok, I don't have strong feelings about where the list sits
[18:29] <LaserJock> and thekorn, greg-g and some others were talking about having a QA Liaison to Launchpad
[18:29] <LaserJock> similar to what the MOTU have
[18:30] <ara> can anyone give a some background on this, please?
[18:30] <LaserJock> there was also some discussion about possibly teaming the liaisons together to form a "Launchpad Advisory board" or some such
[18:30] <bdmurray> Would a Canonical employee be okay in this role?  We meet with them fairly regularly
[18:30] <LaserJock> bdmurray: I'd really rather not
[18:31] <heno> I think that makes sense - several Canonical folks already have good connections with the LP team, but a community voice would be valuable as well
[18:31] <LaserJock> nothing personal about Canonical employees, but part of the issues that come up is that Launchpad developers communicate with other Canonical employees more often then they do with community people
[18:32] <bdmurray> I thought this was a liason role though
[18:32] <LaserJock> so I think it'd probably be better to get an "outside" person
[18:32] <LaserJock> it is
[18:32] <LaserJock> but it's not a Canonical-Canonical liaison role, if you know what I  mean
[18:32] <greg-g> Canonical-CommunityMemeber-Community, Canonical-Canonical-Community
[18:33] <greg-g> but a "not" between those two
[18:33] <greg-g> s/but/put
[18:33]  * greg-g grrs
[18:33]  * persia suspects that some Canonical people may be able to balance the difference, but that a non-Canonical person may be more approachable
[18:33] <LaserJock> ara: the background is that it's difficult for Launchpad developers to prioritize or even figure out what needs to be done when there are hundreds of voices in their ear
[18:34] <LaserJock> ara: so having a person appointed as a go-between helps Launchpad developers and our team get things we need done
[18:35] <heno> I'm wondering what form the liasing would take - maintaing a wiki page of QA team wishlist items would be good
[18:35] <LaserJock> persia: agreed, very much so
[18:35] <bdmurray> LaserJock: and I think there is a fair bit of overlap between what I want and what the rest of the team wants - subsequently some points may become redudant
[18:35] <greg-g> heno: we kinda have a starting of that now: https://wiki.ubuntu.com/QATeam/IdeaPool
[18:35] <heno> and be in contact with the LP team on IRC and at UDSes
[18:36] <LaserJock> heno: for instance, the MOTU liaison uses a "motu" tag, which is a recognized Launchpad tag to prioritize bugs
[18:36] <bdmurray> LaserJock: there already is an ubuntu-qa tag
[18:36] <LaserJock> heno: they also work with LP people on upcoming specs that are relevant to MOTU
[18:36] <heno> greg-g: thanks, we could tighten that and ask the LP team to look at it
[18:36] <LaserJock> bdmurray: yes, I'm aware of that
[18:37] <greg-g> heno: it is most certainly a work in progress, fyi :)
[18:37] <LaserJock> anyway, this is really part of a larger effort to create a team of people who LP dev/management can go to
[18:38] <LaserJock> and the community can work through
[18:38] <heno> If the LP team is open to an additional contact point, I'd be happy to see someone like thekorn in this role
[18:39] <davmor2> need to go I'll catch up on the rest :)
[18:39] <LaserJock> heno: they are indeed
[18:40] <heno> the person should know LP from a few angles and should ideally have met LP bugs members already at a UDS or so
[18:40] <LaserJock> sure
[18:41] <LaserJock> I was just going to throw out a "who all wants to do it" email to ubuntu-qa and go from there
[18:41] <heno> perhaps we should post a request for applications ...
[18:41] <bdmurray> Somebody already checked with the launchpad team then?
[18:42] <LaserJock> bdmurray: yes, I did
[18:42] <heno> The LP team have some say in the selection of the MOTU liason, is that right?
[18:42] <LaserJock> heno: well, yes, and no
[18:43] <LaserJock> they don't technically but it'd be odd to have somebody do it that the LP people don't want to work with
[18:43] <LaserJock> so generally you want somebody who has a good working relationship with them
[18:44] <LaserJock> I can work up a job description, etc. and post it with my email to ubuntu-qa
[18:44] <heno> I don't remember what the selection process was like
[18:45] <LaserJock> I was the MOTU liaison for a long time (it's now siretart)
[18:45] <persia> For MOTU, we've always accepted volunteers.  If someone was unsuitable (which has yet to happen), MOTU would likely call for replacement.
[18:45] <heno> We should work out how this person collaborates with the Canonical QA team members who already have close connections with the LP team though
[18:45] <LaserJock> heno: well, there is that
[18:46] <bdmurray> I really think there is a risk of a lot of duplication of effort
[18:46] <LaserJock> to a fairly large extent what Canonical QA wants to do is up to them :-)
[18:46] <ara> duplication or overlapping
[18:46] <heno> In reality our requirements are generally the same
[18:46] <ara> communication between this person and Canonical QA is also important
[18:46] <persia> overlapping can be good, if supportive and collaborative
[18:47] <bdmurray> It doesn't seem efficient to me though
[18:47] <heno> the Canonical Ubuntu QA team works in the open, apart from a few support cases
[18:47] <LaserJock> also keep in mind, this is hopefully a part of a larger liaison team
[18:47] <heno> where we have to preserve customer privacy
[18:47] <LaserJock> I would like to see QA representation there
[18:48] <heno> we are building a lot of teams here ;)
[18:48] <LaserJock> heno: hopefully only good and useful ones ;-)
[18:49] <LaserJock> I definatelly see where bdmurray is coming from
[18:49] <heno> We discussed some feature additions to LP bugs at the sprint in London last week - I suggest we flesh out the notes in the ubuntu wiki and discuss it at next weeks meeting
[18:50] <LaserJock> but my guess is that duplication shouldn't be an issue
[18:50] <heno> we can then add requests from this group and see whether there is a need for a new team to represent that list
[18:51] <heno> I think we would be able to agree on the whole list in this meeting format and present that to the LP team as a common list
[18:51] <heno> then we need to follow that up as LP makes their releases
[18:52] <heno> with the items in the open wiki we can all follow along
[18:52] <LaserJock> well, there is a lot more than wiki pages
[18:52] <heno> such as?
[18:52] <LaserJock> filing bugs, following up, getting information on upcoming changes in LP
[18:53] <LaserJock> talking with the LP devs to see what things can be done, etc.
[18:53] <LaserJock> it's not mearly just presenting them with a wishlist
[18:53] <LaserJock> as that will almost certainly be largly ignored
[18:54] <heno> not if we present it as our common feature request list
[18:54] <LaserJock> lol
[18:54] <LaserJock> alright, we can try that then, if you think it will work
[18:55] <heno> let's see how that looks next week, and then reconsider posting the role
[18:55] <LaserJock> ok
[18:55] <heno> [TOPIC]: Intrepid Roadmap (LaserJock)
[18:56] <LaserJock> ok
[18:56] <LaserJock> so there's the great spec list at QATeam/Specs
[18:57] <LaserJock> but as we're building the Ubuntu QA team mid-release I wondered if it would be useful to combine Intrepid specs with community efforts into an Intrepid roadmap page
[18:58] <LaserJock> for Intrepid+1 it should flow much more naturally, but currently there's not a Roadmap for non-spec tasks
[18:58] <LaserJock> so the question is, does that seem like a fruitful thing to do?
[18:59] <heno> Roadmaps are good - should some of these things be written up as specs though?
[18:59] <LaserJock> heno: some yeah
[18:59] <LaserJock> I just didn't want to interfer with the existing material
[19:00] <heno> LaserJock: what are the non-spec items you have in mind?
[19:01] <LaserJock> well, more like bitesized tasks, people can get kind of turned off by "specs" as to large of a process to go through
[19:01] <LaserJock> I'm more interested in track what people in the team are doing
[19:01] <ara> LaserJock: can we get some examples?
[19:01] <LaserJock> ara: simple tools
[19:02] <heno> we already have todo lists for the bugs team
[19:02] <ara> like the ones at ubuntu-qa-tools ??
[19:02] <heno> (and for testing?)
[19:02] <LaserJock> or community projects, or things that are just not "big" enough to warrant a full on spec
[19:03] <heno> https://wiki.ubuntu.com/BugSquad/TODO
[19:03] <LaserJock> heno: yeah, so I'd like to have an roadmap that indicates what we as a group want to accomplish for Intrepid
[19:03] <heno> LaserJock: fine with me - feel free to start a page
[19:03] <LaserJock> heno: yeah, that's good stuff
[19:04] <heno> let's review it next week
[19:04] <persia> It may also be good to use un-spec'd Roadmap items as "future" when completing them within the current release cycle is likely infeasible.
[19:04] <LaserJock> I just don't want people to *not* do work because they think they need a full-on spec to do it
[19:04] <heno> right
[19:04] <LaserJock> if it needs a spec go for it
[19:04] <LaserJock> but I'm more interested in tracking work
[19:05] <heno> we should in fact review such a list every 4 weeks or so
[19:05] <LaserJock> we've collected a pretty significant team in Ubuntu QA, more than I had hoped for
[19:05] <LaserJock> but it needs to be doing stuff ;-)
[19:06] <heno> right, we should wrap up this meeting and do some ISO testing!
[19:06] <stgraber> +1
[19:06] <heno> any further topics?
[19:06] <stgraber> yes, a short one
[19:06] <stgraber> has anyone taken note last week ?
[19:06] <heno> not me unfortunately
[19:07] <heno> #endmeeting
[19:07] <MootBot> Meeting finished at 13:09.
[19:07] <heno> thanks everyone! good meeting :)
[19:07] <schwuk> thanks heno
[19:07] <stgraber> thanks
[19:07] <sbeattie> sorry, I didn't take notes last week, either.
[19:08] <stgraber> if someone did, please update the meeting page on the wiki. It currently only contains the agenda.
[19:08] <ara> well, thanks everybody
[19:08] <ara> bye,
[19:44] <boredandblogging> @now
[23:02] <calc> hi
[23:02]  * slangasek waves
[23:02] <liw> yo
[23:03] <slangasek> evan won't make it today; he called to let me know his ISP is experiencing a massive outage and they can't tell him when they'll be back up
[23:03]  * ArneGoetje yawns
[23:03] <liw> yo
[23:04] <doko> good morning
[23:04] <asac> hi
[23:04] <TheMuso> Hey folks./
[23:04] <TheMuso> Jp[e all your trips home were uneventful.
[23:04] <TheMuso> gah cold fingers.
[23:05] <doko> so who should be here? slangasek, liw, asac, TheMuso, calc, bryce, ArneGoetje, ogra (away), ...
[23:06] <calc> wow netsplit
[23:06] <asac> james_w i guess
[23:08]  * slangasek opens the floor: intrepid alpha-3 tomorrow
[23:08] <liw> doko, from Colin's mail: asac, ArneGoetje, bryce, calc, evand, james_w, liw, TheMuso, doko, ogra, slangasek
[23:08] <slangasek> grab your test cases here: http://iso.qa.ubuntu.com/qatracker/build/all
[23:08] <asac> anyone has anything on agenda?
[23:08] <doko> ohh, james_w as well
[23:09] <liw> slangasek, the ISOs are ready for testing now?
[23:09] <ArneGoetje> rsyncing...
[23:09] <doko> no, just lets go through the list of people about the specs targeted for hardy
[23:09] <doko> s/hardy/intrepid/
[23:09]  * doko upgrades quickly
[23:10] <asac> lol
[23:10] <slangasek> liw: everything except desktop should be viable; the desktop images are rsyncable but not yet worth testing
[23:10] <liw> slangasek, ook, I'll see about helping with that tomorrow (it's past midnight already...)
[23:10] <doko> ArneGoetje: could you start the specs state?
[23:11] <slangasek> liw: worth starting an rsync though, to save time later
[23:11] <liw> slangasek, sure
[23:12] <ArneGoetje> doko: well, I'm basically working on language-selector to finish the language-support package split we have started in Hardy and make it selectable in the UI.
[23:13] <ArneGoetje> doko: good progress in this case
[23:14] <doko> looks like "not delayed"
[23:14] <ArneGoetje> doko: I expect it to be ready for FF
[23:15] <doko> asac: continue?
[23:15] <asac> no :)
[23:15] <asac> j.k
[23:15] <asac> well. for firefox and such the biggest building blocks are flash experience and safe upgrading
[23:16] <asac> flash experience is partly done. the tricky bits still missing though
[23:16] <asac> safe upgrading is probably on track as we have some improvements in bzr
[23:17] <asac> the other thing is NM 0.7, which should enter intrepid after alpha3
[23:18] <doko> is there something workable for armel?
[23:18] <doko> (flash)
[23:18] <asac> doko: how would i know ;) ... i guess gnash builds in debian.
[23:20] <slangasek> asac: is 3g-networking-intrepid covered under "NM 0.7"?
[23:20] <asac> yes
[23:20] <doko> asac: do you think these are on track for ff?
[23:21] <asac> thats basically it. feedback is good so far.
[23:21] <asac> some cards appear to be not recognized as "modem" by hal. the others work out of the box.
[23:22] <asac> doko: hard to say. NM 0.7 certainly wont be much tested until we reach beta
[23:23] <doko> bryce: continue?
[23:23] <liw> hmm: --- [bryce] idle 291:31:02, signon: Sun Jul  6 17:36:01
[23:24] <slangasek> I haven't seen bryce speak up yet; maybe skip him for now and come back if he shows up?
[23:24] <doko> calc, continue?
[23:24] <calc> ok
[23:25] <calc> OOo upload is slightly delayed
[23:25] <calc> Its now scheduled for 3.0rc1 to be uploaded week of Aug 21 after Alpha 4
[23:25] <doko> which one, 2.4.x, or 3.0something?
[23:25] <calc> i made a 2.4.1 upload last week to take care of the a3 oversized cd
[23:25] <doko> could you target just a milestone?
[23:25] <slangasek> (is that related to a spec? I don't see anything on https://blueprints.launchpad.net/ubuntu/intrepid)
[23:25] <doko> this should be as good as rc-something
[23:26] <calc> slangasek: yea, let me see
[23:26] <calc> https://blueprints.launchpad.net/ubuntu/+spec/ooo-intrepid-upload-schedule
[23:27] <calc> i might still be able to get 3.0rc1 in before alpha4 its scheduled for aug 8
[23:27] <doko> calc: what about an earlier snapshot?
[23:27] <calc> but we were wanting to give it a week before, i should be free that weekend due to my wife having a large photoshoot so i can probably get it in on saturday
[23:28] <calc> doko: i am planning on getting earlier snapshot into a PPA, hopefully by the end of this week, i was going to get it in last week but the 2.4.1 upload delayed it a bit
[23:28] <calc> we didn't want to put 3.0 into intrepid directly until rc due to they may slip the schedule too much..
[23:28] <doko> calc: please could you use the group ppa?
[23:28] <calc> ok will do
[23:29] <doko> thanks
[23:29] <doko> ok, that's me then
[23:29] <calc> so assuming no more slippage by OOo we will have 3.0rc in around aug 8 for FF
[23:29] <slangasek> calc: do you mean that we don't want to *count* on putting 3.0 into intrepid directly until RC?
[23:29] <calc> slangasek: yes, it could be that they slip the release past our release
[23:29] <slangasek> 'cause if it's available sooner, surely it's better to have it in
[23:29] <slangasek> right
[23:30] <calc> unless we plan on just shipping a 3.0rc
[23:30] <calc> well unless we are ok with doing that in case they slip i mean
[23:30] <doko> calc: ususally the critical patches are in ooo-build, so I wouldn't bother that much if it's 3.0rc-
[23:30] <calc> ok
[23:31] <slangasek> not sure if we should get into a full discussion about that here, but I would note that hardy's support cycle is well past intrepid's, so security support isn't a concern for sticking with 2.4
[23:31] <doko> +1
[23:32] <doko> calc: please go ahead of debian. we'll have to have it releasable, not them
[23:32]  * calc isn't planning on waiting on debian for this, as they are already frozen (aiui)
[23:33] <liw> calc, Debian freezes next weekend, I think, but that's close enough
[23:33] <calc> ok
[23:34]  * doko doesn't have any specs, but "java in main". getting in shape, although we'll have to use three different jvms together with openjdk. next thing is to default default-jre/-sdk to openjdk. this will be done before ff.
[23:34] <doko> I'm not sure if I will get a working python3 (not just the core package) in intrepid in ff.
[23:35] <asac> doko: will the java applet situation on !i386 improve this cycle?
[23:37] <doko> no, probably not. there is work done by fedora on the icedtea plugin, but it's currently not my focus (and still labeled as experimental)
[23:37] <calc> doko: is openjdk-6 ready enough for me to attempt to switch OOo building to it?
[23:38] <doko> calc: yes, there was never anything wrong with it (except being located in universe)
[23:38] <doko> and you told me you did test it ;)
[23:38] <calc> ok, great :)
[23:38] <calc> yes it worked last year when i tested it
[23:39] <doko> evend is not here; james_w, continue?
[23:40] <doko> ahh, isp problems; liw, continue?
[23:40] <slangasek> james_w is also having isp problems?
[23:40] <liw> cleanup-cruft: progressing nicely (cleaning up prototype code from the sprint)
[23:41] <liw> python-memory-profiling-tool: stalled
[23:41] <liw> get-rid-of-python-central-and-support: slow progress this week, need to finish the doc/spec
[23:41] <liw> gobby-server-persistent-state: code works, waiting for reactions from IS and upstream
[23:41] <liw> fast-lsb-release: not started yet
[23:41] <liw> super-piuparts, lintian-harness-improvements: post feature freeze
[23:41] <liw> no-fsck-at-boot: to be reassigned, but have concluded that it's not doable without new magic

[23:42] <doko> happy to look at the get-rid-of spec ... (we have to few get-rid-of specs overall ;)
[23:42] <slangasek> get-rid-of-computers
[23:43] <doko> liw: all specs in time?
[23:44] <liw> I'm not critically late on anything, yet, if that's what you're asking :)
[23:44] <doko> ok
[23:44] <doko> ogra not here; slangasek, continue?
[23:46] <slangasek> no approved specs assigned; I have the pam configuration magic which I'm working on and believe I can deliver in time for intrepid, but this isn't actually on the schedule anywhere officially at this point
[23:46] <slangasek> (that's https://wiki.ubuntu.com/PAMConfigFrameworkSpec)
[23:47] <slangasek> 'sall for me, unless someone has questions
[23:47] <doko> ok, TheMuso to close the list ...
[23:47] <TheMuso> Desktop Accessibility Review spec: Still reading and understanding code and documentation for python-dbus/policykit interaction and reading docs for python-xlib/python-gtk, but am almost ready to port some code from gnome-session to python, that is used for checking that at-spi-registryd started correctly. This will be used in ubiquity-dm when accessibility is enabled for speech/magnification.
[23:48] <TheMuso> I will certainly have the ubiquity stuff fixed up for FF, but will have to take things one at a time to get software sources/hardware testing ported to policykit/getting the UI accessible to the user.
[23:48] <TheMuso> So certainly some of the spec will be completed by FF.
[23:49] <TheMuso> Dmraid: Spent time with Colin at the sprint getting to understand partman internals, and now reading libparted code to educate it about dmraid/mapper devices for use with dmraid. Need to read vol_id code to link against dmraid shared library for use with providing better integration for vol_id/udev for use at boot.
[23:49] <TheMuso> Confident that this will be complted by FF.
[23:50] <doko> slangasek: did you see any specs not mentioned (besides from people not in the meeting)?
[23:50] <slangasek> nope
[23:50] <asac> TheMuso: how is sound going?
[23:51] <TheMuso> asac: Since Debian is freezing soon, I am not sure whether they will hav e alsa 1.0.17. Once I know for sure, I'll either merge, or upload new upstream versions of the alsa bits. I also intend asking the kernel guys about getting alsa driver 1.0.17 into the kernel, so everything matches.
[23:51] <TheMuso> I am still aware of the pc-speaker issue, and intend debugging that today. With luck, 1.0.17 will help solve it.
[23:52] <slangasek> TheMuso: which alsa is in 2.6.26 upstream kernel, since skew caused problems for us before?
[23:52] <TheMuso> slangasek: Still 1.0.16.
[23:52] <slangasek> but we want to jump to 1.0.17 for some reason?
[23:52] <asac> are all the sound issues we had with pulseaudio/alsa and flash now gone in a default intrepid install?
[23:53] <TheMuso> Support for more hardware, and some more fixes, particularly for use with pulse.
[23:53] <TheMuso> asac: Until we can use a sound card properly, not sure yet.
[23:53] <asac> sure
[23:54] <TheMuso> As for pulse itself, I highly doubt the new version will land for intrepid. Its still highly unstable.
[23:55] <TheMuso> However itf it were to land, and we wanted it, we would have to go to alsa 1.0.17.
[23:55] <slangasek> ah
[23:56] <doko> any other business?
[23:57] <liw> nothing from me
[23:57] <slangasek> none here
[23:57] <doko> 3
[23:57] <doko> 2
[23:57] <doko> 1
[23:57] <doko> meeting ends ;) (I'm tired)
[23:57] <liw> thanks and good night
[23:57] <TheMuso> Thanks.
[23:57] <ArneGoetje> thanks
[23:58] <slangasek> thanks, folks
[23:58] <asac> off
[23:59] <calc> by3
[23:59] <calc> er bye :)


[00:00] <aroman> is the ubuntu keyserver not working?
[00:03] <wgrant> aroman: It looks OK to me.
[00:03] <wgrant> aroman: What's the problem you're seeing with it?
[00:03] <aroman> wgrant: hmm, I can't seem to add a PGP key to launchpad
[00:03] <aroman> I created one an hour ago, and published it to the ubuntu keyserver, yet launchpad refuses to add it
[00:03] <wgrant> aroman: What's your fingerprint?
[00:03] <aroman> D262 ACC4 8E1D 0033 7535 A85A D6F0 0BA5 7216 AE15
[00:03] <wgrant> It's possible that it hasn't synced to the internal Launchpad keyserver yet.
[00:04] <aroman> any idea how often that happens?
[00:04] <wgrant> It's meant to only take a couple of minutes. But sometimes it can lag a bit.
[00:04] <aroman> is there some way of manually checking if the ubuntu keyserver has it?
[00:05] <wgrant> It's uploaded successfully, but it hasn't synced across yet.
[00:05] <wgrant> You say you uploaded it around an hour ago?
[00:05] <aroman> ah got it.
[00:05] <aroman> Yeah, about that, I think.
[00:10] <aroman> wgrant: so have you any idea of an ETA for the sync to launchpad?
[00:10] <wgrant> aroman: I'm just checking with a sysadmin.
[00:11] <aroman> wgrant: awesome, thanks :)
[00:35] <aroman> wgrant: woot, just imported successfully
[00:35] <wgrant> aroman: Great! We restarted one of the sync daemons, and it must have just caught up.
[00:36] <wgrant> Thanks for letting us know.
[00:36] <aroman> wgrant: alright. thanks for your help!
[08:32] <magcius> lifeless, you're a cool support dude, can you help a brudda out?
[08:33] <lifeless> magcius: possibly; the help contact, when one is set, is always a good place to start though :)
[08:33] <magcius> Oh, whoops.
[08:33]  * magcius didn't read the topic
[08:33] <lifeless> no worries
[08:33] <lifeless> so whats up?
[08:33] <magcius> wgrant, lifeless, https://bugs.launchpad.net/loggerhead/+bug/569358 landed just a bit ago, and I'm pretty sure it's running right now due to the continuous deployment setup you're using
[08:34] <magcius> But it's not working on the server side.
[08:34] <magcius> Can you look at OOPS up for me?
[08:34] <lifeless> sure
[08:34] <magcius> OOPS-1906CBA6
[08:36] <lifeless> it hasn't synced yet, I'll check in a while
[08:36] <magcius> What do you mean "hasn't synced"?
[08:36] <lifeless> magcius: when an OOPS occurs it is recorded to the local machine
[08:37] <magcius> Ah.
[08:37] <lifeless> magcius: a separate process comes along and rsyncs it to the analysis machine
[08:37] <lifeless> and then another process picks it up and puts it into a DB
[08:37] <lifeless> at the moment this is a high latency process
[08:37] <magcius> Ah.
[08:37] <lifeless> it'll be ~ 15 minutes before I can pull up the oops to look at it
[08:40] <lifeless> magcius: anyhow, I don't know if anyone has updated the loggerhead version we deploy
[08:40] <wgrant> lifeless: Does it matter? c-m doesn't respect sourcedeps.conf, does it?
[08:40] <magcius> lifeless, do you not do that in your continuous deployment system?
[08:41] <magcius> Given how fast the CSS changed from the response to lvh's blog post..
[08:42] <lifeless> magcius: I'm not sure css changes were driven by lvh's blog post : sinzui has been overhauling css every day for weeks - have a look at trunk :)
[08:43] <magcius> lifeless, lvh told me they were :P
[08:43] <lifeless> magcius: we had a loggerhead deployment bug, which gfave us bad loggerhead css (a 404 on a needed file) which we fixed pretty quickly, recently
[08:43] <lifeless> anyhow, things in the main code base are the common-case and easy-path
[08:43] <magcius> OK.
[08:43] <lifeless> things in separate trees - like loggerhead - sometimes require additional effort to go love.
[08:43] <lifeless> *live*
[08:43] <lifeless> I'm not sure if thats the case here.
[08:44] <lifeless> wgrant: we run update-sourcecode as part of the built tree assembly, AFAIK
[08:44] <magcius> OK.
[08:44] <magcius> I was just hoping that fixing the bug, would, uh, fix the bug.
[08:44] <lifeless> wgrant: fwiw, c-m supports ;revno syntax, so I have no idea what update-sourcecode is needed for.
[08:44] <wgrant> lifeless: Then what's the point of all the c-m configs? :/
[08:44] <lifeless> magcius: fair enough too :)
[08:45] <lifeless> wgrant: pqm speaks C-M
[08:46] <magcius> Is the PQM thing just an artifact of the before-bzr days?
[08:47]  * magcius was always suspicious of needing a PQM bot... it screams "usable"
[08:52] <kim0> Hi folks .. My ppa (https://launchpad.net/~kim0/+archive/ppa) is using a non existent key "1024R/51D678E8"
[08:52] <kim0> The ppa is an hour old. Is that normal/ok ?
[08:53] <wgrant> kim0: The keyserver was having some syncing issues earlier. Let me have a look.
[08:54] <kim0> Thanks
[09:01] <wgrant> kim0: There is a syncing issue of some variety. I've asked the sysadmins to have a look.
[09:01] <kim0> cool thanks
[09:12] <mrevell> Hallo
[10:39] <doko> can I setup a new vcs-import for a new branch myself?
[10:39] <doko> e.g. for the gcc 4.6 release branch?
[10:40] <doko> wgrant: ^^^
[10:41] <wgrant> doko: You can great one, but if it's CVS or SVN then someone (eg. me) will have to approve it.
[10:41] <wgrant> Er.
[10:41] <wgrant> *create* one
[10:41] <doko> it's svn
[10:43] <wgrant> doko: https://code.launchpad.net/gcc/+new-import
[10:44] <doko> ahh, ok, had to register first without URL
[10:44] <wgrant> Hm?
[10:45] <doko> wgrant: done: https://code.edge.launchpad.net/~doko/gcc/4.6
[10:45] <lool> LP #4, wow
[10:46] <lool> Hmm ubot5 seems confused
[10:48] <lifeless> doko: edge is deprecated ... and slower
[10:50] <doko> lifeless: have to convince my browser not to complete to edge URL's ...
[10:50] <lifeless> sqlite3 can do that for you :)
[10:54] <wgrant> doko: It looks like jelmer has approved it.
[10:55] <jelmer> wgrant: sorry, I didn't realize your question about ~vcs-imports was related to the discussion here. I didn't mean to steal your thunder...
[10:56] <wgrant> Heh.
[10:59] <doko> wgrant, jelmer: so the new branch will not show up in https://code.launchpad.net/~vcs-imports/gcc ?
[10:59] <jelmer> doko: No, as it's owned by yourself rather than ~vcs-imports
[10:59] <wgrant> doko: As of a couple of years ago, vcs-imports branches are owned by their creator.
[11:00] <wgrant> We can change that, but it's not normally done.
[11:00] <jelmer> wgrant: I don't quite understand that change tbh, as it's still only possible for one person to ever register a particular URL.
[11:01] <wgrant> jelmer: Neither.
[11:01] <lifeless> jelmer: it stops ~registry being subscribed to merge proposals etc
[11:01] <wgrant> lifeless: That is not a good reason.
[11:01] <jelmer> lifeless: Ah, I see
[11:01] <lifeless> wgrant: actually it is, because the person that wanted the import then gets nagged and can decide what to do
[11:02] <lifeless> wgrant: I'm not saying thats a good reason for having the unique constraint
[11:02] <wgrant> There needs to be a "disown" option like project registration has.
[11:08] <lifeless> magcius: https://lp-oops.canonical.com/oops.py/?oopsid=1906CBA6
[11:08] <lifeless>  Module loggerhead.controllers.inventory_ui, line 153, in get_values
[11:08] <lifeless>     filelist = self.get_filelist(rev_tree.inventory, path, sort_type)
[11:08] <lifeless>   Module loggerhead.controllers.inventory_ui, line 63, in get_filelist
[11:08] <lifeless>     for filename, entry in dir_ie.children.iteritems():
[11:08] <lifeless> AttributeError: children
[11:14] <magcius> lifeless, OK, so it's just not updated yet.
[12:07] <doko> wgrant, jelmer: is it possible to change the owner of a svn import, after the import is done?
[12:07] <jelmer> doko: yes, should be
[12:33] <maxb> doko: Yes, but it'll need LOSA intervention unless done by someone who is a member of both source and destination teams (or a member of ~vcs-imports and the destination team)
[13:42] <cnd> I've noticed that lp:ubuntu/bash-completion isn't up to date
[13:42] <cnd> should I file a bug about this, or notify someone?
[13:51] <jcsackett> cnd: how do you mean out of date? is there another source you are comparing to?
[13:51] <cnd> jcsackett, the branch is stuck at version 1.1-<blah>, but natty is up to 1.3-<blah>
[13:52] <cnd> it doesn't represent what's in natty
[13:52]  * jcsackett looks
[13:52] <wgrant> cnd: There's an import failure: http://package-import.ubuntu.com/status/bash-completion.html
[13:53] <cnd> wgrant, yep, looks right
[13:54] <wgrant> Looks like it has some badly encoded path.
[15:22] <researcher123> is it possible to add a new language for translation ?
[15:22] <researcher123> hello friends
[15:24] <henninge> researcher123: it is, see https://answers.launchpad.net/launchpad/+faq/23
[15:24] <researcher123> henninge: thanks a lot
[15:24] <henninge> ignore ubot5 ...
[16:46] <benji> leonardr: hmm, let me look
[16:47] <benji> heh, wrong chan
[22:08] <bjf> sinzui, the staging server has been "Code Update In Progress" for about 6 hours now
[22:08] <lifeless> bjf: it failed to update in the weekend actually, we'll look at it soonish.
[22:09] <lifeless> bjf: you can test things on qastaging.launchpad.net if you like, it is up
[22:09] <sinzui> bjf: I believe it struggling to restore the product db which failed to happen a few days ago


[00:10] <Flannel> Gah.  Where's my audio.
[01:54] <vorian> anyone familiar with Nuku-Nuku or it's owner?
[02:22] <Flannel> came up... a week ago or so in here
[02:24] <Flannel> 5/20
[02:25] <Flannel> Was muted in -motu, also appears in -women, and we were trying to find out more
[02:28] <vorian> hmm
[02:29] <vorian> i just noticed it by doing one of those fancy ubottu calls
[05:01] <nhandler> There is a user (affdklfsjsdf) in #ubuntu-bugs posting Rick Roll links. I am not sure who this user is or what the intention is behind the links. I am just reporting it here.
[05:02] <genii> I just kicked him out of #ubuntu a short while ago on same issue.
[05:03] <nhandler> I never can understand what people like that hope to accomplish. Are they just trying to get kicked?
[05:03] <genii> nhandler: I'm not an op in #ubuntu-bugs but hopefully someone here may be and see. You can also try something like:  !ops | affdklfsjsdf Spamming links                      or so in that channel
[05:05] <nhandler> genii: I didn't want to do a !ops because I wasn't sure who he was or what the intentions were. I guess I can do it now that he has already been kicked from #ubuntu for the same issue
[05:05] <vorian> drats
[05:05] <nhandler> But he already left
[05:06] <genii> nhandler: Spamming links is already a no-no so don't feel bad about using !ops in that case
[05:06] <genii> nhandler: I'll make a note of it on the kick I did for other ops to see so they know that user is chronic, etc
[05:07] <vorian> especially if they are in multiple channels
[05:08] <nhandler> Thanks a lot genii
[05:08] <genii> nhandler: You're welcome
[05:08] <vorian> you have to admit though, that's the best rickroll you've seen in a while
[05:09] <vorian> or not
[05:10] <genii> The best was the #ubuntu-release /topic url :)
[05:11] <vorian> oh?
[05:11]  * vorian missed that
[05:12] <genii> vorian: Yeah someone set a rick-roll in a link of the topic during last release. And the one previous too if memeory serves. Sort of a tradition
[05:13] <vorian> fantastic
[05:24] <genii> Nice. Didn't know about !dontzap til just now
[05:48]  * genii makes another vat of beer
[10:45] <Myrtti> oh jolly good. He blogged about it
[11:44] <jpds> Hobbsee: You needed something about ubot4?
[14:36] <Myrtti> trollday </3
[17:04] <ziroday> Hi!, shouldn't the !splash factoid be removed as its not used anymore AFAIK
[17:04] <Myrtti> !splash
[17:05] <ziroday> Myrtti: is the gnome splash screen even existant anymore?
[17:05] <Myrtti> ziroday: :-D I wouldn't know, I've not used Gnome since... erm... :-D ;-)
[17:05] <ziroday> heh
[17:06] <popey> heh, reminds me of http://digg.com/linux_unix/Could_the_new_Ubuntu_Splash_get_any_more_phallic?FC=PRCP4
[17:06] <popey> blimey, two years ago, how time flies
[17:06] <Myrtti> damn, I need brain bleach
[17:07] <ziroday> eek is this the part where I leave? (the topic looks scary)
[17:07] <Myrtti> popey: I could imagine your hair swooshing when you said blimey
[17:07] <Myrtti> /o\
[17:08] <popey> my hair rarely swooshes these days
[17:08] <Myrtti> it's the elvis effect
[17:09] <Myrtti> popey: LOL
[17:11] <Seeker`> anyone else think John Belushi in Blues Brothers looks a bit like popey?
[17:12] <popey> speaking of which, on holiday, in the pool at the hotel, a 4 year old girl swims up to me, and in a thick welsh accent says...
[17:12] <popey> "'ere, my sister says you look like Elvis"
[17:13] <popey> and then proceeded to call me Elvis all holiday whenever she saw me
[17:13] <Seeker`> :D
[17:13] <Myrtti> *cackle*
[18:08] <Seeker`> @bansearch monteledwards
[18:08] <Myrtti> @bansearch<EMAIL_ADDRESS>[18:08] <Myrtti> FAIL U STUPID BOT
[18:22] <Augusto> hi ops!
[18:22] <Myrtti> o hai
[18:22] <Myrtti> I wonder what that was about
[18:54] <Mamarok> jussi01: if he continues to behave like this...
[20:41] <Myrtti> here's a quest for all of you players of multiplayer notepad. Find the Magic Cluebat that gives you +5 magic mana per day for giving the troops +10 intelligence
[20:42] <Myrtti> It's like the Holy Grail, you know
[20:42] <Myrtti> get eternal life
[20:42] <Myrtti> or, get eternal wisdom and make Open Source rock the world
[21:06] <Myrtti> http://paste.ubuntu.com/185190/
[21:10] <Myrtti> mjkdejjdjdhfhg: hello
[21:11] <Myrtti> mjkdejjdjdhfhg: how can we help you?
[21:17] <Mamarok> mjkdejjdjdhfhg: do you need help?
[21:18] <Mamarok> right
[21:18] <Myrtti> apparently yes, but nobody knows what
[21:24] <Myrtti> has anyone setup trac before?
[21:45] <jussi01> Myrtti: we have it running on our server, but Lynoure set it up....
[21:46] <Myrtti> I'm giving up on this anyway
[21:46] <Myrtti> not going to get anything worthwhile done today
[21:49]  * jussi01 has a tummy ache... :/
[21:52] <Mamarok> arghs, I'm tired
[21:52] <Mamarok> and sometimes wonder why people ask for support wen they do not intend to listen to your advice...
[22:50] <Pricey> eternaljoy: rings a bell..
[22:58] <vorian> Pricey: are you kidding?
[22:58] <Pricey> vorian: hmm?
[22:59] <vorian> think #ubuntuforums
[22:59] <Pricey> that would be it
[22:59] <Pricey> i didn't say it was a bad bell!
[22:59] <vorian> lol
[22:59] <vorian> i thought you were yankin our chain
[23:00] <Pricey> shh
[23:02] <vorian> it tastes like you grandma, love it
[23:02] <mneptok> *muah*
[23:25] <Slart> can't someone kick pixels and possibly sere84  to some other channel where they can argue about keepass's security?
[23:26] <Slart> thanks


[09:03] <hendryx> hello?
[09:19] <venturhano> question about my first bug report: should a bug with my touchpad be associated with the kernel?
[12:53] <apw> venturhano: all depends on the symptoms, but it as good a place as any
[16:07] <venturhano> ok thanks


[04:23] <mup> Bug #1545645 changed: [1.9] Failed to deploy Ubuntu on IBM x3850 via MAAS v1.9.0 <curtin:Incomplete> <MAAS:Expired> <https://launchpad.net/bugs/1545645>
[04:23] <mup> Bug #1579729 changed: DHCP Snippets: The toggle buttons cannot be deactivated <design> <ui> <MAAS:Expired> <https://launchpad.net/bugs/1579729>
[09:03] <KpuCko> can somebody help me with that? http://askubuntu.com/questions/805564/ubuntu-maas-does-not-recognize-nodes-storage-disks
[10:02] <KpuCko> can somebody help me with that? http://askubuntu.com/questions/805564/ubuntu-maas-does-not-recognize-nodes-storage-disks
[11:30] <asfjsdfmsdf> can somebody help me with that? http://askubuntu.com/questions/805564/ubuntu-maas-does-not-recognize-nodes-storage-disks
[13:30] <siva> roaksoax: Hi. MAAS not able to detect nodes storage devices? I am using MAAS Version 1.9.3+bzr4577-0ubuntu1 (trusty1). can you please help me in this?
[13:41] <roaksoax> siva: 1. what storage devices are you using. 2. do you have logs ?
[13:42] <KpuCko> siva i have same problem
[13:42] <KpuCko> in the lshw log of the node im seeing the hard disks, but the maas dashboard shows 0.0 at the storage column
[13:43] <KpuCko> im using ubuntu 16.04 LTS with maas package shiped with distribution.
[13:45] <roaksoax> maas doesn't get the storage information from lshw
[13:45] <roaksoax> lshw is completely unreliable
[13:45] <roaksoax> did you guys file a bug ?
[13:46] <siva> roaksoax: I am using SATA disks and SAS. I am using Dell machines. Logs : http://paste.openstack.org/show/545127/
[13:47] <siva> kpuCko: I am using ubuntu 14.04. For me also in MAAS UI it shows 0.0 at storage column.
[13:50] <siva> roaksoax: And without listing hard disks the tranaction moved from new to ready. But the power state is On. When I click on "Check now" then also power is in "On" state.
[13:50] <roaksoax> siva: the logs you provide wont give m much. I need cloud-init logs
[13:51] <roaksoax> siva: while it is commissioning, you can ssh into the commissioning environment (enabling the opttion),  and after it finishes
[13:51] <roaksoax> you can grab /var/log/cloud-init*
[13:51] <KpuCko> roaksoax i'm speaking about lshw because it output is shown at the maas dashboard on the node tab
[13:51] <roaksoax> KpuCko: we dont get the storage info from lshw
[13:52] <roaksoax> KpuCko: we collect lshw as part of the process
[13:52] <roaksoax> but storage is not from lshw
[13:52] <KpuCko> also when i start the node i can ssh to the box and see the linux os recognize the disks correctly
[13:52] <KpuCko> so what i have to do to figure out this issue?
[13:57] <siva> roaksoax: cloud-init logs  http://paste.openstack.org/show/545134/
[13:59] <roaksoax> siva: can you attach those to the bug report I'll send your way in a sec
[13:59] <roaksoax> KpuCko: https://bugs.launchpad.net/maas/+bug/1604393/comments/11
[13:59] <roaksoax> siva: https://bugs.launchpad.net/maas/+bug/1604393/comments/11
[13:59] <roaksoax> attach all of those logs
[14:00] <siva> roaksoax: OK. i will attach.
[14:00] <roaksoax> thansk
[14:06] <mup> Bug #1608545 opened: "sudo maas createadmin" instructions need --username <MAAS:New> <https://launchpad.net/bugs/1608545>
[14:09] <KpuCko> another of my problem is that i cannot use wake on lan feature
[14:09] <roaksoax> KpuCko: wake on lan is no longer suipported
[14:09] <KpuCko> does anybody knows why? I can't find it on the power profiles on the node confiug
[14:11] <KpuCko> hmmm, why? you mean i have to wake my boxes only from console? via wakeonlan or etherwake
[14:13] <roaksoax> KpuCko: MAAS no longer supports wake on lan
[14:13] <KpuCko> ok, thanks
[14:13] <roaksoax> in fact, using WoL was really unreliable
[14:44] <siva> roaksoax: Hi. I attached all the logs you mentioned http://paste.openstack.org/show/545140/
[14:50] <KpuCko> roaksoax, i tested with 14.04 LTS - it works.
[14:50] <KpuCko> I can see the nodes storages to the dashboard.
[14:50] <KpuCko> So this is bug in 16.04 LTS version of maas (maas 2.0)
[14:51] <KpuCko> i have to go, thanks for support roaksoax
[14:54] <mup> Bug #1608555 opened: Error when using dhcp range with pre-existing dynamic reservation <kanban-cross-team> <landscape> <MAAS:New> <https://launchpad.net/bugs/1608555>
[15:13] <mup> Bug #1608557 opened: [UI, UX] MAAS doesn't tell the user if a dynamic range was already created when trying to enable DHCP. <MAAS:New> <https://launchpad.net/bugs/1608557>
[15:13] <mup> Bug #1608559 opened: [UI, UX] Bad error message when failing to create a range because another already exists <MAAS:New> <https://launchpad.net/bugs/1608559>
[15:16] <mup> Bug #1608557 changed: [UI, UX] MAAS doesn't tell the user if a dynamic range was already created when trying to enable DHCP. <MAAS:New> <https://launchpad.net/bugs/1608557>
[15:16] <mup> Bug #1608559 changed: [UI, UX] Bad error message when failing to create a range because another already exists <MAAS:New> <https://launchpad.net/bugs/1608559>
[15:25] <mup> Bug #1608557 opened: [UI, UX] MAAS doesn't tell the user if a dynamic range was already created when trying to enable DHCP. <MAAS:New> <https://launchpad.net/bugs/1608557>
[15:25] <mup> Bug #1608559 opened: [UI, UX] Bad error message when failing to create a range because another already exists <MAAS:New> <https://launchpad.net/bugs/1608559>
[15:46] <siva> roaksoax: While commissioning MAAS not able to list hard disks. But with the assigned dhcp IP I can able to login to that machine. And I am able to perform all actions generally what we can perform after installing a OS. After commissioning power state is "On".
[15:47] <roaksoax> siva: , ok, someone will look at it later this week
[15:47] <roaksoax> but the info we needed is ther
[15:55] <siva> roaksoax: OK.  the info we needed means? generally after OS deployed by the OS we can do all actions. Once OS is deployed Power state should be "ON". yesterday I tried . for two OS deployment failed with Curtin failed: configuring storage. For one node it is successful. When I was trying to debug setup went wrong. Then I reinstalled MAAS. And I started again the same process. This time I faced the mentioned issues. From my previous setup
[16:01] <siva> roaksoax: Ok. Thank you for your support.
[17:40] <mup> Bug #1608629 opened: UI does not allow for tag management <docteam> <MAAS:New> <https://launchpad.net/bugs/1608629>
[17:55] <mup> Bug #1608629 changed: UI does not allow for tag management <docteam> <MAAS:Triaged> <https://launchpad.net/bugs/1608629>
[18:01] <mup> Bug #1608629 opened: UI does not allow for tag management <docteam> <MAAS:Triaged> <https://launchpad.net/bugs/1608629>
[18:37] <mup> Bug #1608639 opened: ssl error vmware vcenter 6 connection <maas (Ubuntu):New> <https://launchpad.net/bugs/1608639>
[19:04] <mup> Bug #1608639 changed: [2.0rc3] SSL verification error when connecting to VMware vCenter <MAAS:Won't Fix> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1608639>