[05:06] <jibel> Good morning
[05:39] <pitti> Good morning
[05:57] <DanChapman> good morning
[06:00] <pitti> thomi: I finally started to review https://code.launchpad.net/~dpniel/autopilot-gtk/autopilotgtkemulators/+merge/187673
[06:01] <pitti> thomi: what is the usual schema for packaging emulators? would "import autopilot.gtk.emulators" be appropriate here?
[06:02] <pitti> thomi: also, do you think these should go into a new python-autopilot-gtk-emulators package, or land right in python-autopilot?
[06:02] <pitti> DanChapman: ^ (FYI)
[06:05] <DanChapman> pitti, awesome :-) thanks for finding the time to review it, i know you are rather busy atm
[06:07] <pitti> thomi: ah actually, autopilot.gtk.emulators wouldn't work, as two different packages would try to use the same namespace; so maybe autopilot_gtk.emulators ?
[08:27] <jibel> rhuddie, hey, does bug 1230196 exist in other apps or only messaging? it could be an sdk bug
[08:29] <rhuddie> jibel, I only saw it in the messaging app
[08:30] <rhuddie> jibel, it seemed to be to do with scrolling through a long message... it was a weird problem
[08:30] <jibel> rhuddie, okay, I'm moving it there, we'll see what messaging devs say.
[08:41] <slickymaster> morning all o/
[08:44] <DanChapman> morning slickymaster
[08:45] <slickymaster> hi DanChapman. hope everything is fine with you
[08:49] <DanChapman> slickymaster: Everythings great thanks. And yourself?
[08:50] <slickymaster> DanChapman: Also great, thanks. Finishing the editing work on the upcoming 13.10 manual
[09:15] <rhuddie> anyone know if there is a setting for disabling screen power off? I can't find anything in system settings.
[09:17] <slickymaster> rhuddie: see if is this what you're looking for: http://askubuntu.com/questions/348974/how-to-prevent-my-screens-from-turning-off-when-the-screen-is-locked
[09:18] <rhuddie> slickymaster, sorry, I meant on ubuntu touch
[09:19] <slickymaster> rhuddie: np
[09:32] <jibel> rhuddie, run 'powerd-cli display on bright'
[09:32] <jibel> rhuddie, in the bakground if you want to keep it on
[09:32] <jibel> back
[09:35] <jibel> rhuddie, if you meant a UI wait to disable screen power off, I don't know any
[09:39] <john__> Hi! Are Fujitsu-Siemens Lifebooks well supported by Ubuntu? In particular E743 and E753 models.
[09:44] <rhuddie> jibel, thanks
[09:48] <DanChapman> john__: My partner runs Ubuntu on her E753 with no problems at all.
[10:17] <jibel> pitti, there is still a problem with adt-run. For example http://<IP_ADDRESS>:8080/job/saucy-adt-apport/120/ARCH=i386,label=adt/consoleFull
[10:18] <jibel> pitti, test timed out but didn't stop
[10:18] <jibel> pitti, I'll connect to the VM to see if I can gather useful information
[10:21] <davmor2> Morning all
[10:31] <pitti> jibel: hey
[10:32] <pitti> jibel: ah, that's the one I was just looking at too, as I got a failure
[10:32] <pitti> jibel: did you kill that manually?
[10:32] <davmor2> pitti: no he use a computer to kill honest ;)
[11:21] <jibel> pitti, I did.   Image 74 is broken critically, Usermetircs has apparently broken anything it touches, so phone sms and camera don't know about anything else.
[11:35] <pitti> jibel: ok, I'll have a look at this after lunch
[13:42] <smartboyhw> balloons, any cadence weeks this week?
[13:42]  * smartboyhw does not want to see the schedule since it will deteoriate his bandwith
[13:43] <smartboyhw> *bandwidth
[13:43] <balloons> smartboyhw, nope we have the final round next week for testing the rc's and final images :-)
[13:43] <smartboyhw> balloons, nice, let's get fired up?
[13:43] <smartboyhw> :P
[13:43] <smartboyhw> balloons, when will we start Classroom sessions planning?
[13:45] <balloons> smartboyhw, as soon as the release is out :-)
[13:45] <balloons> It'll be classroom time again, which should be fun!
[13:45] <smartboyhw> balloons, next time, we should have such sessions pre-release instead of post-release
[13:45] <smartboyhw> Or maybe overlap
[13:45] <smartboyhw> Like, image sessions pre-release
[13:45] <balloons> smartboyhw, how would you like to see them done?
[13:45] <smartboyhw> autopilot sessions post-release
[13:46] <balloons> we;ve done them at the beginning of the cycle each time, but it is true that you can't use the info right away
[13:46] <smartboyhw> balloons, we need some hype (and some more testers)
[13:46] <smartboyhw> Who can use the knowledge right away
[13:47] <om26er> jibel, re: bug 1227519
[13:47] <om26er> it seems the indicator crashes
[13:48] <balloons> smartboyhw, well we could certainly run something at the beginning of next week so they could put it to immediate use
[13:48] <smartboyhw> balloons, yes, we can
[13:48] <balloons> doing that doesn't preclude anything
[13:48] <smartboyhw> What "something" then?
[13:49] <balloons> what do you feel is needed?
[13:49] <smartboyhw> (Don't mention Google Hangouts, I can't be on Air due to age restrictions:P)
[13:49] <balloons> we have video sessions explaining things already
[13:49] <jibel> om26er, did you collect a crash file?
[13:49] <jibel> or even reproduce
[13:50] <om26er> jibel, well I face the issue daily. I checked that the service was not running, started by hand and it worked
[13:50] <jibel> om26er, hm, and nothing in /var/crash?
[13:50] <smartboyhw> balloons, promotion is not enough I believe
[13:50] <jibel> om26er, do you have the issue after a reboot or only after a fresh flash?
[13:53] <balloons> smartboyhw, probably worth having a quick look over https://wiki.ubuntu.com/Testing/ISO/Walkthrough
[13:53] <smartboyhw> balloons, I don't think there's big issues with it
[13:53]  * balloons reads
[13:54] <smartboyhw> *big issues*
[14:00] <balloons> smartboyhw, hmm, fair enough. We could be more direct in our promotion.. All the tests and overhead my by overwhelming to folks
[14:01] <smartboyhw> balloons, more direct? How?
[14:01] <balloons> instead of watching a video, we could simply ask them to install the image on there machines. Physical machines that is. If possible, upgrade the version of ubuntu they already have, etc
[14:02] <smartboyhw> balloons, +1
[14:02] <balloons> give them a link to the image directly, etc. I wonder about getting the result though
[14:03] <smartboyhw> balloons, getting the result = ISO QA Tracker?
[14:03] <balloons> smartboyhw, yes, I wonder if we could easily link them to one page so avoid confusion
[14:04] <balloons> for folks that are testing this way..
[14:05] <smartboyhw> balloons, a one-stop page? Ask amjjawad, he's good at such things:P
[14:14] <balloons> smartboyhw, we have a one-stop page, I'm thinking even more consolidated than that. I'll run with the idea
[14:14] <jfunk> nuclearbob, just wanted to thank you for your quick work on the QA reports, already coming in handy -  http://reqorts.qa.ubuntu.com/reports/qa/qa-touch-1.html
[14:14] <smartboyhw> balloons, i.e. ?
[14:14] <nuclearbob> jfunk: no problem
[14:17] <balloons> smartboyhw, thinking a little more outside the box. It would be nice to potentially streamline the process to this specific use case, but I'm not sure
[14:18] <smartboyhw> balloons, hmm
[14:18] <smartboyhw> Quite difficult to streamline the result-reporting part
[14:19] <balloons> I'm thinking a tool to get the image (we have those) and report the result, since it would be very specific in this single use scenario
[14:19] <balloons> we can report tracker results via api
[14:20] <smartboyhw> balloons, what we can do, is integrate testdrive.
[14:20] <smartboyhw> With result-reporting functions
[14:20] <smartboyhw> But I'm not sure DanChapman and Noskcaj will want to code that:)
[14:21] <balloons> yes, that is possible, but in that case I'm not sure if makes as much sense
[14:21] <balloons> it's already pretty simple. I'm after real world hardware results
[14:22] <smartboyhw> balloons, they installed it, then they have to report t
[14:22] <balloons> yep.. it's always tempting to think about technology
[14:46] <jfunk> alesage, where are you now?
[14:48] <alesage> jfunk, Chi-town
[14:48] <alesage> and experiencing jetlag of almost kiwi proportions
[14:49] <jfunk> hehe
[14:49] <jfunk> how was your epic journey?
[14:49] <jfunk> alesage, ^
[14:49] <alesage> jfunk, quite epic :) , saw a lot of desert in Mongolia
[14:49] <alesage> camped out quite a bit, it was fun
[14:50] <alesage> jfunk, btw you were right about getting a cab right away, I underestimated the NYC traffic
[14:51] <jfunk> alesage, sounds like it turned out alright
[14:51] <alesage> jfunk, yes I made it thanks :)
[15:00] <balloons> so davmor2 remember my 3g problems? those have never been resolved. If I disconnect wifi 3g flashes a couple times, but never connects
[15:00] <balloons> I've never gotten a mobile data connection on the mako, am I the only one?
[15:01] <davmor2> balloons: in progress, there is a partial fix that should mean you get a connection on startup.  Then cyphermox is working on making NM auto-reconnect when ofono updated aiui
[15:02] <davmor2> balloons: cyphermox and awe_ are the best two people to talk to about it though
[15:03] <balloons> davmor2, I just feel a little crazy as it seems like everyone else uses mobile data and I've never gotten it to work through all the builds. I feel like I'm missing something. It sounds like there are some bugs, but in general people have used it
[15:04]  * balloons turns back on wifi
[15:04] <balloons> thanks for the update davmor2
[15:04] <davmor2> balloons: are you using a standard sim card or one from some random company that needs a config file change?  failing that try adb restart network-manager and you should in theory get a connection
[15:05] <balloons> davmor2, it's a std sim from an att reseller
[15:05] <davmor2> balloons: that might be your issue,  is it one from wallmart by any chance ?
[15:07] <balloons> davmor2, ahh, heh, why yes it is
[15:08] <davmor2> balloons: bingo needs a config change,  that would need you to drop your image into RW mode with /userdata/.writable_image (then reboot)  as for the config you would need to ask around
[15:08] <balloons> davmor2, yep rw mode already on.. cool, well I feel saner, ty
[15:09] <davmor2> balloons: I think people in the USA qa team have the issue and know the config other than that you can try ogra I think there is a bug for it too but I could be wrong
[15:22] <slickymaster> balloons: I am considering taking a stab at https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1172046 but there are a couple of issues on which I have a few doubts, namely what does need to be updated in the existent testcase, besides  what's in the Bug Description?
[15:23] <balloons> slickymaster, lets have a look
[15:24] <balloons> slickymaster, afaik heh, those are my notes. My guess is go through the test, verify it works properly, and clean up anything you see (like the comment listed as an action)
[15:26] <slickymaster> balloons: now that I've finished the editing work on the 13.10 manual, I'll give it a try
[15:26] <balloons> slickymaster, this is probably the highest priority bug atm, https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1225669
[15:27] <slickymaster> balloons: but that is already assign to smartboyhw
[15:27] <elopio> good morning!
[15:28] <balloons> slickymaster, yes, I was just mentioning it is all :-)
[15:28] <slickymaster> balloons: ok
[15:31] <slickymaster> balloons: one last thing, https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1172046 is intended for the 13.04 server version, right?
[15:31] <slickymaster> or is it for the 12.04.3 LTS version?
[15:33] <balloons> slickymaster, yes always current devel
[15:33] <balloons> the old version is archived against the old results, so no worries on updating it
[15:33] <slickymaster> balloons: thanks
[15:34] <slickymaster> I'll prepare a VM to install it and afterwards start to work on the test
[15:35]  * DanChapman wonders why installing autopilot always kills vbox
[15:36] <balloons> slickymaster, wonderful, thank you!
[15:36] <balloons> DanChapman, what do you mean?
[15:37] <slickymaster> balloons: np
[15:38] <DanChapman> balloons: good afternoon :-) When installing autopilot from a live session using vbox it always kills the graphics
[15:38] <alesage> nuclearbob, suggestion from tedg concerning adding a column to your reporting view for "is a merge proposal attached to the bug"
[15:39] <balloons> wow.. that sounds really odd
[15:41] <DanChapman> balloons: yeah its been like it for a while. I try it every now and again it seems to happen around the point its unpacking vis and xlib.
[15:42] <elopio> davmor2: so, the most recent image is broken?
[15:42] <balloons> must be a vbox thing. I kind of remember that, but I don't usually use ap in live sessions anymore.. though I know why you are :-)
[15:42] <davmor2> elopio: yeap 75 should fix it once all the bits land to build the images
[15:43] <balloons> DanChapman, pitti is on the hook to merge your MP this week, so :-)
[15:43] <elopio> davmor2: and 75 will be tomorrow?
[15:44] <davmor2> elopio: asap
[15:44] <elopio> got it, thanks.
[15:45] <DanChapman> balloons, yeah he has already started the review :-) , so waiting on the rest before I make the changes
[15:52] <pitti> balloons: well, at least review; there's quite a lot to be changed, and presumably we need to move the whole thing to autopilot
[15:52] <pitti> will continue as soon as I'm off the hook for the timezone change OMGess and meeting-o-mania
[15:53] <balloons> pitti, DanChapman yes, I shouldn't misspeak on landing.. Review :-)
[16:01] <alesage> can someone instruct on how to make a touch image writeable?  in the past I've touched /userdata/.writable_image
[16:03] <balloons> alesage, https://wiki.ubuntu.com/QATeam/TouchTesting#Switch_from_RO_to_RW
[16:03] <alesage> balloons, seeing that now thanks :)
[16:03] <balloons> ubuntu-qa PSA This page has handy tips -- have a look! https://wiki.ubuntu.com/QATeam/TouchTesting#Tips_and_Tricks
[16:04] <pitti> balloons: ah, thanks for pointing out; I fixed ARM retracing two days ago, I'll update that
[16:04] <pitti> and I'll add a trick how to disable the screen timeout
[16:04] <pitti> ah, which is there already
[16:05] <balloons> ty pitti :-)
[16:05] <alesage> balloons, where do you think I should put the "run a package from souce" wiki, is this linked page the right place?
[16:05] <balloons> alesage, as in run an upstream version of a package on the phone? a writeup could be handy for that
[16:05] <balloons> and yea, I'd say it's a good place
[16:05] <alesage> balloons, ok I'll put it there
[16:08] <slickymaster> balloons, DanChapman, 'til later
[16:09] <davmor2> balloons: you mean you haven't added enabling wallmart sims there yet ;)
[16:09] <balloons> davmor2, I think I will place a note about mvno's in general ;-)
[16:27] <elfy> balloons: "we just say resize drives as appropiate" agreed with that :)
[16:28] <elfy> balloons: you want me to do that?
[16:29] <balloons> elfy, go for it :-)
[16:30] <elfy> balloons: ok - I'll assign myself to it and get to it in short order
[16:30] <balloons> ty
[16:32] <balloons> davmor2, nuclearbob hehe, a new section has appeared: https://wiki.ubuntu.com/QATeam/TouchTesting#Add_APN_Settings
[16:34] <davmor2> balloons: ha nice
[16:37] <elfy> balloons: if you can make some sort of final comment on bug 1193128 you can assign it to me and I'll do that at the same time as I look at the other 2
[16:40] <balloons> elfy, ahh yes, I remember that..
[16:40] <balloons> I'm partly for jackson's approach "boot up the image" and don't say how
[16:41] <elfy> personally I'm of the opinion that if a choice needs to be made like that we should assume that people can make sensible choices or we end up tying ourselves in knots for no good reason
[16:43] <balloons> elfy, so does that put you in the same camp? less is more?
[16:43] <elfy> more or less :)
[16:45] <elfy> balloons: 'Boot the image using your preferred method'
[16:45]  * balloons updated the bug
[16:46] <elfy> balloons: I'll sort that one out soon too
[16:46] <balloons> elfy, lovely thank you
[16:47]  * balloons has so many pending merges open
[16:47] <balloons> it's not funny. I want to close them!
[16:47] <elfy> :)
[16:47] <elfy> I've got a clean desk :p
[16:48] <elfy> van's a bit mucky though ...
[16:50] <pitti> elopio, om26er: do you know how to introspect the items in a QML ListView? getting the count is easy, but I don't see a property with the items in it
[16:50] <balloons> om26er, 3 mins of your time to look at this mp? https://code.launchpad.net/~carla-sella/ubuntu-docviewer-app/Emulator-integration/+merge/188149
[16:51] <balloons> I thought something was wrong with the archive at first, but it still is failing to pull dependencies today.. what gives
[16:51] <balloons> elopio, also ^^. ubuntu-ui-toolkit-autopilot is unstable state?
[16:53] <elopio> balloons: it is. Ah, I missed you on the email yesterday too.
[16:53] <elopio> I'm sorry.
[16:53] <elopio> forwarding...
[16:55] <balloons> elopio, yes I found the tabs issue on another mp that magically stopped working, heh
[16:55] <balloons> is this fallout from that? and when do you think we'll be good to go again?
[16:56] <elopio> balloons: I'm wondering what changed. But my email went with no answer and the sdk is already gone.
[16:57] <balloons> elopio, meaning the sdk changes went out, and you've not heard anything?
[16:57] <elopio> balloons: I told bzoltan to ask the developers tomorrow morning to give me a hand fixing the QML problem. So I hope when I get up my branch will just work.
[18:00] <jfunk> om26er, nuclearbob - you're both on the multimedia testing, do you know which developers to coordinate with?
[18:01] <nuclearbob> jfunk: I've worked with the music-app team already, and the browser team, but I haven't talked to anyone about video yet
[18:01] <jfunk> ping ubuntu-qa - can we get 1 volunteer to work with elopio on click packages?
[18:01] <om26er> jfunk, rsalveti is fixing the codes, mediaplayer developer is nerochiaro and jhodapp works on the backend side
[18:01] <om26er> *codecs
[18:03] <cgoldberg> jfunk, i can help elopio
[18:03] <jfunk> asac, I'd like to try having some of my team testing against trunk where we know there is zero automation coverage - are you able to point out which areas would benefit from this pinpointed testing?  I am keen to avoid manual testing where automation exists
[18:04] <jfunk> but at the same time, if we can run early tests to catch integration issues that would otherwise be missed...
[18:04] <elopio> cgoldberg: \o/
[18:04] <jfunk> fginther, ^^ in lieu of asac
[18:04] <jfunk> cgoldberg, you're a good man
[18:04] <cgoldberg> i try
[18:05] <elopio> cgoldberg: what would be awesome is if you could help checking the test coverage of the click index and developer portal.
[18:05] <jfunk> cgoldberg, you have a device?
[18:05] <cgoldberg> jfunk, just a nexus 7
[18:06] <jfunk> elopio, will that be helpful?
[18:06] <cgoldberg> so no phone calls or anything
[18:06] <jfunk> I think it might suffice for click testing
[18:07] <fginther> jfunk, a little context please, are you referring to just click packages or something more broad?
[18:07] <cgoldberg> elopio, how are you checking coverage.. manually, or running something like coverage.py?
[18:08] <elopio> cgoldberg: I'm currently just reading the code on the client side, to see if they have unit tests, component tests, api tests and GUI tests.
[18:08] <elopio> so I'm not interested in a number. Just the levels of testing we are missing.
[18:09] <cgoldberg> elopio, where can I start? got a link to source/tests?.. I'll start looking too
[18:09] <elopio> cgoldberg: I'm going to share a document with you of the things that the client side consumes.
[18:10] <elopio> that will be enough testing for today, I think, and will give you an idea of what the server provides.
[18:12] <jfunk> fginther, broad
[18:12] <elopio> cgoldberg: sounds good?
[18:12] <cgoldberg> elopio, yup
[18:14] <fginther> jfunk, to my knowledge there is no or very little automated test coverage for indicators, settings, application switching and app install/remove
[18:15] <fginther> jfunk, other good people to talk to are bfiller and Saviq
[18:16] <cgoldberg> elopio, which branch are you looking at?   lp:clickmanager-plugin or lp:click-update-manager ?
[18:16] <elopio> cgoldberg: both.
[18:16] <cgoldberg> elopio, pick one for me so we don't duplicate :)
[18:17] <elopio> cgoldberg: ok, go with the update-manager.
[18:17] <cgoldberg> k
[18:48] <cgoldberg> elopio, i have a good idea of coverage for click-update-manager.  how should I measure or summarize?
[18:49] <cgoldberg> also, I found an unused import in the autopilot test (my brain runs pylint automatically as I read code).. think I should MP a change, or not bother?
[18:53] <elopio> cgoldberg: yes, please fix it.
[18:53] <elopio> it would be great if we can add pep8 and pyflakes to the MPs.
[18:53] <cgoldberg> elopio, ok no prob
[18:53] <elopio> cgoldberg: for now, maybe you just can make some notes of what you found about coverage on that document.
[18:55] <cgoldberg> ok .. good enough.  I'll write notes and MP a fix
[18:55] <elopio> cgoldberg: I'm thinking of an awesome tool that's like python-mock for servers.
[18:55] <cgoldberg> elopio, yea?  what would it do?
[18:55] <elopio> you give it an reply to make and it will listen on a socket and send back that to whoever contacts it.
[18:56] <letozaf> balloons, Hi
[18:56] <balloons> letozaf, hello
[18:56] <cgoldberg> elopio, i built something exactly like that in my last job
[18:56] <elopio> cgoldberg: was it useful?
[18:56] <letozaf> balloons, I just sent you a mail :P
[18:56] <letozaf> balloons, about someone interested in autopilot testing
[18:56] <balloons> letozaf, I saw that thank you
[18:57] <cgoldberg> elopio, yeah totally... it simulated all of our external services and sent back canned responses.  we used it on everything
[18:57] <letozaf> balloons, hope this guy knows english
[18:58] <cgoldberg> elopio, it was in C#, would be much easier in python :)
[18:58] <elopio> cgoldberg: it could be as cool as mock, recording the calls, and replying only when a specific api method is accesed.
[18:59] <cgoldberg> elopio, yea.. i used regexes for routing requests to static replys
[18:59] <balloons> letozaf, I'm sure he does :-)
[18:59] <elopio> cgoldberg: maybe it's already done https://pypi.python.org/pypi/mock-server/0.3.0
[19:02] <cgoldberg> elopio, that looks pretty decent
[19:02] <elopio> I don't like it that you have to write the replies on files. But I think it will have many of the basic things already done.
[19:02] <elopio> I now have a toy for the weekend :)
[19:03] <cgoldberg> elopio, mine also worked for MQSeries servers.. so distributed queuing and also http servers.. this one is less ambitious, but simpler
[19:03] <cgoldberg> elopio, my design read from files also.. it's not a bad idea :)
[19:04] <elopio> cgoldberg: but I would like to prepare the response on the fly, on the set up of the test.
[19:05] <cgoldberg> elopio, ah.. nice
[19:06] <cgoldberg> elopio, that code is Apache licensed... if you wanna do a big change that they probably won't merge, just fork it and start a new project :)  I'll help you work on it.. i think it's a really good idea
[19:06] <letozaf> balloons, can I help with something this evening, or are you guys busy fixing things on  tests ?
[19:07] <balloons> letozaf, sure thing. Heh, there's a lot of in-progress stuff I'm wanting to land
[19:07] <cgoldberg> elopio, it uses tornado :P
[19:08] <balloons> letozaf, that said, try grabbing the updated version of rss reader. I believe the tests are broken (again), and I'm not sure why. There are some sdk bugs they were trying to work around
[19:08] <elopio> cgoldberg: that's great. I think we can use the tests for the click update manager to give it a try.
[19:08] <cgoldberg> cool :)
[19:08] <letozaf> balloons, ok
[19:08] <elopio> what should the server reply to cause an update? prepare the mock, and run the test.
[19:09] <balloons> letozaf, make sense? See what happens when you try and run them, heh. Also, it's likely some of the tests could be expanded as well
[19:10] <elopio> I'm going to have lunch with the family, and then to buy the sata cable.
[19:10] <elopio> I'll be back in a couple of hours.
[19:10] <cgoldberg> elopio, so you'd hit it with an update request.. that gives it a filter and a payload.  it stores it and responds when another request comes in matching the filter?
[19:10] <cgoldberg> elopio, ttyl about it
[19:11] <letozaf> balloons, yes I will branch it now and take a look
[19:13] <letozaf> balloons, ok so the next button is back again :P
[19:13] <letozaf> balloons, I will fix what's broken and see what new tests there are to write or implement
[19:13] <balloons> :-)
[19:13] <balloons> ty!
[19:13] <letozaf> balloons, yw
[19:20] <balloons> letozaf, I responded to Andrea
[19:21] <letozaf> balloons, ok fine hope he will help
[19:21] <letozaf> balloons, but do you know Italian :p
[19:22] <balloons> letozaf, lol, no I wrote in English :-p
[19:22] <letozaf> balloons, I know that, but did you understand his email ?
[19:22] <letozaf> balloons, maybe you used google translator
[19:23] <balloons> letozaf, I saw another note from him and responded to that one. I'm not sure what he wrote to you, as indeed it's in Italian. Google translate gives you a basic gist I suppose, but I didn't translate it
[19:23] <balloons> so please feel free to followup :-)
[19:24] <balloons> technical work in a non-native language can be tough, so I'm sure you'll be able to help him out :-)
[19:25] <letozaf> balloons, ok, well he just asked how to get involved in autopilot testing and how to start
[19:26] <letozaf> balloons, he has been using python for two years
[19:26] <letozaf> balloons, and he's interested in testing
[19:27] <balloons> letozaf, ahh wonderful. He probably knows more python than me already :-)
[19:27] <letozaf> balloons, and me too :p
[19:29] <letozaf> balloons, I mean you know python more than me too
[19:51] <letozaf> balloons, I get an error in open_toolbar()  that's in the emulator :  http://paste.ubuntu.com/6181020/
[19:52] <balloons> letozaf, yes I too got a similar error
[19:52] <letozaf> balloons, the emulator is in the SDK right ? can I do something or do I have to wait ?
[19:53] <balloons> letozaf, run with -vv
[19:53] <letozaf> balloons, I had already run with -vv
[19:53] <balloons> ahh, does it give more output? like say generating drag operations/
[19:53] <letozaf> balloons, what I pasted was the output from -vv
[19:53] <balloons> ohh, :-(
[19:53] <letozaf> balloons, yes
[19:53] <letozaf> balloons, wait
[19:54] <balloons> letozaf, you can see the source for the functions in the docs: http://developer.ubuntu.com/api/devel/ubuntu-13.04/autopilot/_modules/ubuntuuitoolkit/emulators.html#MainView.open_toolbar
[19:54] <letozaf> balloons, well not drag operations but pressing and moving mouse
[19:55] <letozaf> balloons, ok I can try to look at that
[19:55] <balloons> so if there is a bug in the sdk, try proving it by opening the toolbar (or attempting to do so) yourself
[19:55] <balloons> you can just edit the python library code to play with it at first
[19:56] <balloons> /usr/lib/python2.7/dist-packages/ubuntuuitoolkit/emulators.py
[19:56] <letozaf> balloons, ah! ok cool!
[19:57] <balloons> so say for instance, it's not opening because it doesn't like those values, maybe try changing the starting point
[19:57] <balloons> etc.. I'm not sure what the issue is
[19:58] <balloons> so maybe change  start_y = y + self.height - 1 in     def _drag_to_open_toolbar(self):
[19:58] <balloons> and/or         stop_y = y + self.height * 0.95
[19:59] <letozaf> balloons, ok I will try
[20:15] <veebers> thomi: the unity failures, which image is that with? the click image?
[20:31] <letozaf> balloons, it's a timing issue
[20:31] <balloons> letozaf, ohh nice
[20:31] <balloons> did you fix it?
[20:31] <letozaf> balloons, I put in a sleep before opening the toolbar and now it
[20:31] <letozaf> works
[20:32] <letozaf> balloons, putting a sleep that's not the right way
[20:32] <balloons> hmm, so can we check something else besides that?
[20:32] <letozaf> balloons, I was thinking to put some asserts
[20:32] <balloons> right.. sounds like a plan
[20:32] <balloons> excellent work in finding it :-)
[20:33] <letozaf> balloons, thanks :p
[20:36] <letozaf> balloons, yes it works with an assert put before opening the toolbar
[20:39] <balloons> awesome, so the whole suite passes? feel free to merge propose that :-)
[20:40] <veebers> thomi: which commmand are you using to flash your phone?
[20:42] <letozaf> balloons, I also fixed the remove feed
[20:42] <letozaf> balloons, I will merge propose all
[20:43] <balloons> sweet!
[20:44] <knome> hallo balloons
[20:47] <balloons> hallo knome
[20:47] <knome> what's up?
[20:52] <balloons> lost in a sea of merges, how about yourself?
[20:52] <knome> just checked your website, and noticed you've broken it :P
[21:01] <cgoldberg> elopio, ping me when you're back
[21:02] <balloons> knome, ohh
[21:26] <elopio> cgoldberg: I'm back.
[21:26] <cgoldberg> elopio, I was checking tests, and found something weird.. look at this line:  http://bazaar.launchpad.net/~coreygoldberg/click-update-manager/pep8-and-import-fixes/view/head:/tests/autopilot/UpdateManager/__init__.py#L45
[21:27] <cgoldberg> where does MainWindow come from?  is it missing an import or something?  that wont work
[21:28] <elopio> cgoldberg: that looks wrong.
[21:29] <cgoldberg> yea definitely.. makes me wonder if this has ever been run :)
[21:29] <elopio> I haven't tried those tests yet, but I suppose it will fail.
[21:30] <cgoldberg> I pep8'ed the tests and removed some unused imports.. should I just MP that and file this as a bug against the tests?
[21:31] <cgoldberg> elopio, there's only 3 autopilot tests in there.. and 1 of them makes a call to the code in question
[21:33] <elopio> cgoldberg: well, that autopilot code is following the ugly way without emulators. It needs a lot of updating.
[21:34] <balloons> elopio, can you link the bugs you filed today on the sdk and autopilot and emulator issues
[21:35] <balloons> things be broke :-(
[21:39] <elopio> balloons: one second.
[21:39] <elopio> balloons: send me a link to the failed logs, to see if its the same thing I was looking at yesterday.
[21:39] <elopio> bug #1233393
[21:39] <ubot5`> bug 1233393 in Ubuntu UI Toolkit "We shouldn't rely on the order of the buttons on the tab bar" [Undecided,Confirmed] https://launchpad.net/bugs/1233393
[21:40] <elopio> bug #1233402
[21:40] <ubot5`> bug 1233402 in Ubuntu UI Toolkit "The Tab needs a tabIndex property" [Undecided,Confirmed] https://launchpad.net/bugs/1233402
[21:40] <elopio> bug #1233385
[21:40] <ubot5`> bug 1233385 in Autopilot "Not possible to minimize an application" [Undecided,Confirmed] https://launchpad.net/bugs/1233385
[21:40] <elopio> bug #1233384
[21:40] <ubot5`> bug 1233384 in Autopilot "It's not possible to get the Application object of the launched app." [Undecided,Confirmed] https://launchpad.net/bugs/1233384
[21:40] <elopio> bug #1233364
[21:40] <ubot5`> bug 1233364 in Ubuntu UI Toolkit "Before starting the autopilot tests, we check for a condition that's always true" [Undecided,Confirmed] https://launchpad.net/bugs/1233364
[21:40] <elopio> balloons: just 5 bugs to be awesome again ;)
[21:41] <balloons> elopio, wonderful thank you..
[21:41] <balloons> elopio, you don't want to look at the failures anymore than I
[21:41] <balloons> the evil of today has been enough
[21:41] <balloons> it's time to quit
[21:42] <elopio> balloons: I can stand a couple more of failures today.
[21:42] <elopio> if you have a trace at hand, I would like to see if it's something not addressed on these bugs.
[21:43] <balloons> elopio, most everything I'm seeing is showing in merges
[21:44] <balloons> elopio, this is a wild one for instance: https://code.launchpad.net/~carla-sella/ubuntu-docviewer-app/Emulator-integration/+merge/188149
[22:03] <elopio> looking.
[22:06] <knome> pitti, could you look at bug 1231978?
[22:06] <ubot5`> bug 1231978 in gvfs (Ubuntu) "Thunar 1.6.3 locks when browsing Trash with Xubuntu 13.10 Beta 2 and following dailies" [Critical,Confirmed] https://launchpad.net/bugs/1231978


[07:09] <vigneswari> hello all
[07:09] <vigneswari> i have a general question
[07:10] <vigneswari> what is the priimary difference between i386 and lpia packages..
[07:10] <vigneswari> what would the issue when i install i386 package in lpia system


[00:28] <SudoKing> :)
[01:19] <skaet> ubuntu desktop ( amd64, amd64+mac, i386, powerpc) posted - 20110412 image
[01:35] <doko> lamont: still http://people.canonical.com/~doko/tmp/fpc-armel-mav-stage2/ from Sep 2010
[01:43] <skaet>  Riddell, ScottK - kubuntu desktop (amd64, amd64+mac, i386, powerpc) posted - 20110413 image
[02:05] <skaet> ogra_, GrueMaster,  ubuntu netbook pre-installed (omap3, omap4) posted - 20110413 image
[02:33] <skaet> Riddell, ScottK,  kubuntu-mobile daily-live (i386) posted
[02:38] <skaet> slangasek, around?
[02:39] <skaet> looks like there's been some failures with xubuntu, mythbuntu on the desktop images.
[02:40] <skaet> after the dvd's finish, I'll try kicking them off again to see what's happening.   Haven't seen any error messages though.   Is there som log location I can look?
[02:41] <skaet> also,  doesn't look like the alternates have triggered....hmm...
[02:45] <charlie-tca> I got an email earlier about a file lock causing a fail to build
[02:46] <charlie-tca> but I deleted it already
[02:49] <charlie-tca> skaet: I don't know if this helps, but this is where cjwatson has me look when I tell him by images did not build
[02:49] <charlie-tca> http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/natty/daily-live-20110413.log
[02:49] <skaet> thanks charlie-tca
[02:49]  * skaet looking
[02:49] <charlie-tca> There are several things towards the end
[02:52] <skaet> charlie-tca, yeah those failures to fetch files and has sum mismatches look suspicious.
[02:52] <skaet> I suspect this will be a learning exercise for me :-/
[02:52] <charlie-tca> Hoping they didn't. sometimes it just means you have to release a lock and tell it to run aagt
[02:53] <skaet> As soon as the dvd images finish off,  I'll try them individually and see what happens from a command line perspective.
[02:53] <charlie-tca> again, but I am not very good at reading these things, either.
[02:53] <skaet> thanks for pointing me to the logs though... :)
[02:55] <charlie-tca> You are welcome
[02:55] <charlie-tca> I don't get to help you very often
[02:58] <skaet> mythbuntu desktop (amd64, i386) - posted 20110413 image
[03:43] <skaet> ubuntu dvd (i386, amd64) posted
[03:43] <skaet> 20110413 image
[03:44] <stgraber> skaet: any news on alternte ?
[03:44] <stgraber> *alternate
[03:45] <skaet> stgraber,  they don't seem to have been triggered,  am going in and trying them manually now.
[03:45] <skaet> package they were waiting for is in the pool, so, ... fingers crossed.
[03:46] <stgraber> ok. I don't think I'll still be around to test them tonight but will test LTSP first thing tomorrow morning (eastern time)
[04:06] <skaet> kubuntu desktop arm (preinstalled omap, omap4) posted - 20110413
[04:07] <stgraber> seems like alternates are ready too
[04:10] <skaet> ubuntu alternate (i386, amd64, amd64+mac, powerpc) posted - image 20110413
[04:10] <skaet> stgraber,  yup
[04:10] <skaet> just came off the builds
[04:16] <skaet> kubuntu dvd (i386, amd64) posted - 20110413
[04:32] <skaet> kubuntu mobile (omap, omap4) posted 20110413
[05:03] <lamont> doko_: I'll see if that does any better for me.
[05:06] <skaet> ubuntu headless (omap3, omap4) posted - 20110413
[05:06] <skaet> GrueMaster, ogra_ - that should be all the arm images available now.
[05:12] <skaet> ubuntu-server (i386, amd64) posted  - 20110413
[05:29] <lamont> skaet: we're hard-frozen the next couple days, yes?
[05:29] <skaet> lamont, yes
[05:30] <skaet> lamont,  what's pending?
[05:30] <lamont> ok.  on the off chance these bits actually build, I'll wait for the unfreeze before I bounce around the arm chroot tarball to bootstrap fpc
[05:31] <lamont> also, I'll build a fresh tarball tomorrow and then make it the current tarball once we unfreeze
[05:31] <skaet> cool,  thanks.   window may open on Thursday,   depends on how this set of builds looks.
[05:31] <lamont> thereby making the dist-upgrade step a no-op for the first few minutes
[05:31] <lamont> doko_: same error.
[05:31] <lamont> skaet: so I can skip that part :(
[05:34]  * skaet nods
[05:35] <skaet> ubuntu studio (amd64, i386) posted - 20110413
[05:39] <lamont> skaet: so in the unlikely event that the current archive proves to be useless for building packages, let me know,eh?
[05:41] <lamont> (highly unlikely, I warrant)
[05:41] <lamont> anyway, sleep for this one
[05:42] <skaet> lamont,  will do.  (me thinking sleep too is a good idea)
[05:45] <skaet> pitti, cjwatson, jibel,  all images except xubuntu daily live are posted now.   langasek has that building now.
[06:14] <slangasek> xubuntu live posted
[08:06] <pitti> Good yawning
[08:06] <pitti> skaet, slangasek: excellent
[08:08] <pitti> hm, edubutu DVD on cardamon failed to build
[08:16] <ScottK> pitti: I'm about to go to sleep myself, but if you can squeeze that KDE SRU in, I'll be around in a few hours to keep an eye on it and manage any retries due to archive skew.
[08:29] <pitti> ScottK: KDE SRU> right, was planning on looking at that today, now that the urgent uploads are settled
[08:29] <pitti> hmm, mythbuntu uploads in the queue?
[08:29] <ScottK> Great.  Thanks.
[08:33] <pitti> the mythtv upload looks relevant, accepting that (fixing oversizedness)
[08:33] <pitti> I pinged superm1 about the other ones
[08:34] <pitti> skaet: did superm1 happen to talk to you about the mythbuntu related uploads?
[08:57] <mvo> in case someone wonders, main-all in the auto-upgrade-tester looks pretty good, the only failure left is bug #655533 - likewise-open I was not able to reproduce in a clean vm, so its something that is installed along with it
[08:57] <ubot4> Launchpad bug 655533 in likewise-open (Ubuntu Natty) (and 1 other project) "[master] package likewise-open <IP_ADDRESS>111-2ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (affects: 4) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/655533
[09:04] <ev> fix for 759401 incoming
[09:14] <Daviey> mvo: Eucalyptus passed ok?
[09:16] <mvo> Daviey: I don't think its installed on this image, the algorithm is greedy so if euca caused more removals than it added it will be rejected from the image. I can add a profile for this or manually add it, probably a good fit for the server-tasks image
[09:17] <mvo> Daviey: what packages/metapackage should I install? eucalythus-cloud?
[09:17] <Daviey> mvo: Odd... i thought you identified a regression some months ago.
[09:18] <Daviey> mvo: It probably needs two different scenarios tbh.. one being eucalyptus-cloud eucalyptus-cc eucalyptus-walrus eucalyptus-sc
[09:19] <Daviey> the other being eucalyptus-nc
[09:19] <mvo> Daviey: some of euca is installed on the python-all image, but not much afaict
[09:20] <mvo> ok, let me add that, we got a new disk so there is plenty of space to fill with tests :)
[09:20] <Daviey> mvo, w00t
[09:23] <pitti> for the record, I switched two buildds to manual for urgent natty builds, so that I can keep the rest busy with SRUs
[09:25] <mvo> Daviey: the eucalyptus-nc one has just this additional package? and the other 4 euca packages (just to ensure I get the profile right)?
[09:27] <Daviey> mvo, Yeah... the -nc package is the individual nodes - and normally exists on it's own.  The other scenario is all the components on the same machine (minus -nc).
[09:27] <ev> ^ right, so the stitch is that all CDs with ubiquity will exhibit that bug, but it's non-fatal.  The error message will show but the install should complete successfully.
[09:35] <pitti> ev: hm, I wonder why that didn't come up in the testing since Monday
[09:35] <ev> pitti: it broke with a change from yesterday
[09:36] <ev> my fault for testing syntax but not the whole thing in the context of a full install
[09:36] <ev> apols
[09:36] <pitti> jibel: hm, do we have time for a respin/test?
[09:37] <pitti> maybe not the DVDs (we can document that), but at least the desktops?
[09:37] <pitti> ev: on xubuntu etc. as well, I take it?
[09:37] <ev> correct
[09:38] <pitti> ev: kubuntu as well? (since this does some gnome-keyring bits)
[09:38] <ev> anything with ubiquity, though oem-config is unaffected since it exits that function immediately
[09:38] <ev> correct, kubuntu as well
[09:39] <jibel> pitti, which images ? all or only ubiquity based images ?
[09:39] <pitti> I accept it for now to let it buildl
[09:39] <pitti> jibel: yes, all desktop images (not alternate/server/etc.)
[09:39] <pitti> nor the preinstalled armel ones
[09:41] <jibel> pitti, okay, only desktop i386 and powerpc are well covered yet.
[09:41] <pitti> jibel: ok, scheduling a rebuild then
[09:41] <jibel> I'm marking desktop images as rebuilding
[09:41] <pitti> we need a mythbuntu respin anyway, so at least for that it doesn't matter
[09:41] <pitti> jibel: thanks
[09:43] <ev> pitti: thanks
[10:40] <mvo> Daviey: euca-nc just upgraded successfully, euca-cloud is still running, it should show up tomorrow on the regular qa dashboard page
[10:41] <Daviey> mvo, Well that is odd.. i was expecting a failure :P
[10:41] <Daviey> mvo, I appreciate that, thanks.
[10:41] <Daviey> mvo, Is there any way i can get the result as soon as it comes in, instead of waiting for tomorrow?
[10:45] <mvo> Daviey: sure, here is the raw log of euca-nc http://people.canonical.com/~mvo/tmp/euca-nc-mav-natty-upgrade.log
[10:46] <mvo> Daviey: its based on the minimal server image (just ubuntu-minimal,standard plus euca)
[10:49] <Daviey> mvo, That is great - thanks.
[10:49] <mvo> Daviey: it has a FAILED for the debsums_lite test, but that is expected, I disabled this test on the real upgrade tester as the locale bits always fail
[10:49] <Daviey> ah
[10:51] <mvo> Daviey: here is the other one http://people.canonical.com/~mvo/tmp/euca-cloud-mav-natty-upgrade.log
[10:59] <Daviey> thanks mvo, big help.
[10:59] <mvo> yw
[11:33] <pitti> jibel: I'm queueing new desktop and DVD builds now, once ubiquity has published, shoudl start in about 15 minutes
[11:33] <pitti> jibel: I will rebuild DVDs as well; we can then decide whether or not to add them to the tracker
[11:33] <pitti> i. e. whether we have time to test them, or use the current images with the bad error message
[11:35] <jibel> pitti, current DVD builds are untested, when will the new builds be available ?
[11:36] <Riddell> pitti: new kubuntu too?
[11:36] <pitti> jibel: hm, perhaps 4 hours or so?
[11:36] <pitti> Riddell: ev said it affects Kubuntu as well, yes
[11:36] <jibel> pitti, ok.
[12:34] <pitti> jibel_, all: new Ubuntu desktops posted (20110413)
[12:36] <pitti> jibel_: FYI, I marked the DVDs as rebuilding as well, they only got 1 test in total
[12:36] <pitti> (which revealed the very bug that got fixed now)
[13:08] <pitti> Kubuntu images should land in the next ~ 10 minutes; I'm off for lunch and will add them when I get back, unless someone beats me to it
[13:09] <pitti> ah, already trickling in, adding now
[13:10] <pitti> Riddell, all: http://cdimage.ubuntu.com/kubuntu/daily-live/20110413.1/ added to tracker
[13:17] <ogra_> netbook preinstalled omap4 doesnt look good
[13:17]  * ogra_ prays its a bad SD or some such
[13:18] <jibel> what's the ETA for xubuntu desktop images ?
[13:52] <pitti> re
[13:52] <pitti> jibel: should be there now, I'll catch up on adding
[13:52] <jibel> pitti, I added them. thanks
[13:52] <pitti> jibel: http://cdimage.ubuntu.com/xubuntu/daily-live/20110413.2/
[13:52] <pitti> ah
[13:54] <pitti> mythbuntu added
[13:55] <pitti> kubuntu-mobile i386 added
[13:55] <pitti> jibel: ubuntu DVD is building now, FYI
[13:58] <jibel> pitti, why there's no livefs-build log and cd-build log for xubuntu 20110413.2 on http://people.canonical.com/~ubuntu-archive/{cd-build-logs,livefs-build-logs}/xubuntu/natty/ ?
[13:59] <pitti> jibel: hm, I'm not sure, their mirroring might lag a bit?
[14:00] <pitti> jibel: CD build log does exist: http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/natty/daily-live-20110413.2.log
[14:00] <cjwatson> mirroring is hourly
[14:00] <ogra> phew, seems it was a bad dd write
[14:01] <jibel> ah okay, thanks
[14:04] <ogra> hmm, do we have a trigger for update-gconf-defaults ?
[14:05]  * ogra doesnt want to use a postinst if he can solve the issue with one trigger line
[14:05] <highvoltage> like everyone should!
[14:05] <ogra> highvoltage, well, only if the respective trigger exists :)
[14:06] <Daviey> Can we consider the current iso a candidate yet?  Has anyone expressed a need for a respin affecting server?
[14:10] <cjwatson> I've not seen one yet
[14:10] <pitti> neither have I
[14:11] <pitti> Daviey: IOW, with the information currently available, "yes"
[14:11] <Daviey> groovy, thanks.
[14:18] <stgraber> what's the ETA for Edubuntu ?
[14:19] <ogra> all ubuntu armel images look good
[14:20] <ogra> (minor issues that can be fixed before final)
[14:26] <ogra> pitti, hmm,. the tracker is weird, it shows "Ubuntu ARM Preinstalled" as well as "Ubuntu Netbook Preinstalled" for armel, i think there is some duplication
[14:30] <pitti> ogra: right, the ubuntu netbook armel+... should be dropped, right?
[14:30] <pitti> ogra: at least our publishign scripts expects "ubuntu arm preinstalled"
[14:30] <ogra> thats weird
[14:31] <ogra> given we never use the arch name as flavour
[14:31] <pitti> we can also drop ubuntu ARM preinstalled
[14:31] <ogra> flavour should be headless or netbook
[14:31] <pitti> I'm not sure who added it
[14:31] <ogra> let me see where the mail link gets me
[14:31] <cjwatson> apparently it needs care to change at the iso.qa side
[14:32] <pitti> but yes, anything which brings some more consistency into the naming schema is greatly appreciated
[14:32] <cjwatson> the last time I tried it broke some bit of Tobin's workfloww
[14:32] <ogra> Ubuntu ARM Preinstalled omap4
[14:32] <cjwatson> see discussion on this channel before beta-1
[14:32] <cjwatson> and #ubuntu-testing
[14:33] <ogra> well, we definitely shouldnt use the arch in the flavour description
[14:33] <ogra> but "ubuntu arm preinstalled" is what the tracker uses atm
[14:34] <ogra> shoudl be s/arm/headless/ or s/arm/netbook/ imho
[14:34] <ogra> anyway, to report my results at the right place i guess i have to use "Ubuntu ARM Preinstalled" atm
[14:45] <stgraber> pitti: any guess as to when Edubuntu will be done rebuilding ?
[14:45] <jibel> cjwatson, I updated the tracker last week, and moved the iso path matching logic to the database. Now the names of the products are less tightly linked and we can change them without breaking the paths to the isos.
[14:46] <jibel> which means no more hardcoded product name in the tracker code.
[14:46] <stgraber> jibel: yeah !
[14:47] <cjwatson> aha
[14:47] <jibel> and that should work for dot releases too
[14:51] <stgraber> jibel: bug 148944 should have made it easier to watch cdimage and improve the guessing logic. But that's been around for a while and that part of the code was probably the biggest issue of the tracker ;) thnaks for fixing it
[14:51] <ubot4> Launchpad bug 148944 in ubuntu-cdimage "File list on cdimage for the Ubuntu QA Tracker" [Undecided,Confirmed] https://launchpad.net/bugs/148944
[15:03] <pitti> stgraber: it should start in about 15 minutes, ETA 1 h
[15:03] <stgraber> pitti: ok, thanks
[15:20] <pitti> oh oh, do I smell a rebuild there? ^ ogra
[15:21] <pitti> jibel: ubuntu dvd posted
[15:23] <ogra> pitti, nope, only fixes for the bugs i found
[15:23] <ogra> nothing thats serious
[15:23] <skaet> morning all,   just went through the backscroll.    Looks like a bit more rebuilding was needed.... but all seems under control now (arm rebuilds being the question).
[15:23] <ogra> if we get a rebuild i'd love to have them in, but its also fine post beta
[15:24] <pitti> hey skaet
[15:24] <skaet> hey pitti,   busy morning for you looks like.
[15:24] <pitti> ogra: the description fix seems trivial, the sources.list bug a bit harder to fix on upgrade
[15:24] <pitti> skaet: heh, yes :)
[15:25] <ogra> pitti, yes, the fixes both need to be in at image build time
[15:27] <ogra> anyway, all armel images seem good to go as they are atm
[15:40] <jibel> skaet, there's no ec2 on the tracker?
[15:40] <skaet> jibel,  haven't heard from smoser about them yet.
[15:40] <jibel> skaet, k
[15:41] <skaet> thanks for the reminder - will go ping...
[15:41] <smoser> well, uec images dont build right now :-(
[15:41] <smoser> working on that fix
[15:41] <skaet> smoser,  ok,  good luck.
[15:55] <pitti> kubuntu DVDs posted
[15:55] <pitti> Riddell, jibel ^
[15:57] <Riddell> yay
[16:07] <ogra_> stgraber, your python-apt fix doesnt seem to work
[16:08] <stgraber> ogra_: hmm, that seems weird. Worked fine with both commented and non-commented line here. Currently in a meeting, can you pastebin your sources.list before and after your run your script ?
[16:09] <ogra_> thats a bit tricky since its run in initramfs, but i'll try my best
[16:10] <ogra_> in any case the python-apt package is the latest and the sources.list looks exactly like what i filed on the bug
[16:23] <smoser> i need someone from the release team to acl https://launchpad.net/ubuntu/natty/+queue?queue_state=1&queue_text=cloud-init
[16:28] <pitti> (done FTR)
[16:35] <stgraber> ogra_: I'm wondering if that may be a ports vs archive kind of issue. I'm updating my pandaboard now so I'll have a good test environment. Should have more this afternoon.
[16:38] <GrueMaster> In my testing of the source.list, I found that software-properties-gtk seems to work properly as far as commenting or uncommenting the sources.list entries.  There may be something missing in the setup to the function call.
[16:44] <smoser> ok. build of uec images is now polling, waiting for grub-legacy-ec2 at 0.6.1-0ubuntu7 to get into archive and will build 20110413.1 when it arrives.
[17:01] <pitti> stgraber: edubuntu DVDs posted
[17:01] <pitti> http://cdimage.ubuntu.com/edubuntu/dvd/20110413.1/ (still syncing, though)
[17:01] <pitti> rebuilding mythbuntu now to fix oversizedness
[17:01] <pitti> then we are done
[17:02]  * skaet crosses fingers ....;)
[17:32] <stgraber> ogra_: ok, I reproduced the issue on my pandaboard. Looking at python-apt now to fix it. It's very likely a different issue though giving the same result :(
[17:35] <stgraber> highvoltage: ^ (in case you missed it, edubuntu is ready for testing)
[17:36] <stgraber> mvo: so we have another python-apt upload scheduled before final right ?
[17:45] <stgraber> ogra_: ok, the issue is that python-apt is considering these sources.list entries as invalid or non-official (for some reason), so really a completely different bug
[17:50] <ogra_> stgraber, weird, since it considers the deb ones valid
[17:51] <stgraber> ogra_: yeah, I'm currently adding some debug to it so it logs why each line is being skipped
[18:00] <highvoltage> stgraber: I'm rsyncing those images so long, but I might only be able to test them tonight
[18:04] <pitti> mythbuntu posted
[18:07] <pitti> skaet: all images built and posted now, I'm not aware of necessary rebuilds ATM
[18:09] <skaet> pitti, excellent!  thanks.
[18:09] <jibel> Woohoo no more rebuilds, thanks!
[18:09] <jibel> we can start testing then ?
[18:09] <jibel> j/k
[18:10]  * pitti hugs jibel
[18:14] <stgraber> mvo: ping
[18:14] <stgraber> mvo: I'd need someone who's familiar with python-apt's templates ;) I'm pretty sure that's ogra_'s issue
[18:15] <stgraber> mvo: if I read the Ubuntu template correctly it says that for != i386 and != amd64, we must use http://ports.ubuntu.com/ubuntu-ports/ to have it marked as an "official" entry in sources.list
[18:15] <stgraber> mvo: what I can't find is how to update the template to say that it's fine using archive.ubuntu.com on != i386 and != amd64 for deb-src entries
[18:16] <stgraber> ogra_: ^ that's why I didn't get the issue on amd64 btw
[18:16] <ogra_> ah
[18:17] <stgraber> ogra_: if I use "deb-src http://ports.ubuntu.com/ubuntu-ports" instead of archive, then python-apt works properly
[18:18] <ogra_> well, i didnt add a.u.c there its a default coming from somewhere in the image build process
[18:21] <stgraber> I'm not sure if we want whatever adds a.u.c to be changed to use p.u.c or if we want python-apt to be modified to accept a.u.c as a valid deb-src source on ports architectures
[18:22] <ogra_> well, a.u.c is totally valid for sources
[18:26] <stgraber> ogra_: I closed your old bug report again as that issue is fixed and opened a new one: bug 760035
[18:26] <ubot4> Launchpad bug 760035 in python-apt (Ubuntu) "Ubuntu.info template doesn't allow deb-src lines using archive.ubuntu.com on ports architectures (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/760035
[18:27] <stgraber> mvo: ^
[18:30] <mvo> oh, indeed
[18:30] <mvo> thanks for this one
[18:32] <stgraber> mvo: just looking at the template, it's not obvious if there's a non-hackish way of overriding for source entries. I guess "source" could be considered as an architecture but it doesn't look like it's at the moment
[18:33] <mvo> stgraber: yeah, I think that is a valid approach
[18:35] <pitti> skaet: do you need me for anything else? if not, I'd toddle off to Taekwondo
[18:36] <skaet> pitti,  looks like UbuntuStudio is having problems
[18:36] <skaet> build dependencies,  in discussion on u-testing now
[18:36] <skaet> s/build/install/
[18:36] <skaet> sigh
[18:36] <superm1> i was working with pitti to get amd64 mythbuntu cd's down in size, just committed some seed changes to make the on media pool smaller.  can someone queue a rebuild?
[18:37] <skaet> pitti,  you want me to?  or will you?  re:  mythbuntu?
[18:37] <pitti> skaet: if you can?
[18:37] <skaet> pitti,  sure.
[18:38] <pitti> superm1: ah, just "ship"? that shouldn't need publisher runs
[18:39] <pitti> skaet: http://cdimage.ubuntu.com/ubuntustudio/daily/20110413/report.html <- eek
[18:39] <superm1> pitti, well ship-live, but yeah, i wasn't sure if it needed publisher run or not
[18:39] <pitti> I bet it's trying to pull in libavcodec
[18:39] <pitti> superm1: I don't think so, only for live
[18:39] <skaet> superm1, pitti - have kicked it off,  but if its not needed,  will not post.
[18:40] <pitti> skaet: these aren't refelected on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html, so I guess it's due to libavcodec
[18:40] <pitti> skaet: the rebuild is needed, we just don't need a publisher run after the seed change
[18:40] <skaet> pitti,  thanks for the explanation.  :)
[18:41]  * pitti waves good bye then; I'll check in again when I'm back in ~ 3.5 h
[18:50] <cjwatson> debootstrap upload (appearing shortly) isn't needed for beta-2
[18:51]  * skaet thanks cjwatson for that qualification ;)
[18:52] <skaet> ScottL,  around?
[18:52] <jibel> ScottL, ubuntu-studio is broken, bug 760008
[18:52] <ubot4> Launchpad bug 760008 in debian-installer (Ubuntu) "amd_64 studio install fails (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/760008
[18:52] <jibel> there's a dependency of ubuntustudio-desktop on hal which is not satisfied.
[18:53] <cjwatson> the libavcodec stuff might go away once the other is fixed ...
[18:53] <cjwatson> we at least tried to work around that at the seed level
[18:53] <cjwatson> (ubuntustudio.natty r1254)
[18:54] <cjwatson> though, hmm, the metapackages don't look right
[18:54] <cjwatson> I'm going out, will have a look when I get back if nobody else has
[19:03] <scott-work> hi, project lead for ubuntu studio here
[19:03] <scott-work> how much more time do we have to test images for beta 2
[19:03] <scott-work> ?
[19:17] <charlie-tca> scott-work: <jibel> there's a dependency of ubuntustudio-desktop on hal which is not satisfied.
[19:17] <stgraber> skaet: ltsp alternate amd64 is broken due to yesterday's fix (and me assuming that chmod -f would always return 0 ...). I don't think we can/want to fix that for beta2. I have a one line fix that I'm going to push upstream now and once again release a new upstream and upload.
[19:18] <charlie-tca> Trying to get all the tests done today. Beta 2 release is tomorrow
[19:19] <charlie-tca> scott-work: bug 760008
[19:19] <ubot4> Launchpad bug 760008 in debian-installer (Ubuntu Natty) (and 1 other project) "amd_64 studio install fails (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/760008
[19:20] <stgraber> skaet: bug 759965
[19:20] <ubot4> Launchpad bug 759965 in ltsp "ltsp installation fails on Build LTSP chroot step (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/759965
[19:20] <stgraber> patrickmw: ^
[19:21] <skaet> stgraber,  ok,  so I'm clear.  we'll be documenting it, rather than trying for another set of images?
[19:21] <skaet> or are we going for a fresh set of images?
[19:22] <stgraber> skaet: I don't know what else you have pending and how critical it's to have LTSP work on amd64 for beta2
[19:22] <skaet> stgraber,  is it only on amd64?
[19:22] <stgraber> skaet: yep, i386 is fine
[19:24] <stgraber> I fixed the bug manually in my VM and am continuing the install with the fix, just to make sure nothing else breaks with LTSP on 64bit. Should have that done in the next 5 minutes or so
[19:24] <stgraber> if that's fine, I already have a new ltsp release ready to be pushed on my laptop with the one-line fix
[19:24] <skaet> stgraber,  get the fix ready,  and I'll do some asking.   which amd64 images will need respinning.
[19:25] <highvoltage> stgraber: is the workaround big? would be nice to have it in the beta2 release notes along with the problem note
[19:25] <highvoltage> (or at least have it in the bug report it's linked to)
[19:26] <stgraber> highvoltage: workaround is "wait for it to fail in the installer", chroot to /target, modify /usr/sbin/ltsp-update-kernels, look for chmod line, add || true, restart installer step
[19:26] <stgraber> highvoltage: that's really quite hackish :)
[19:26] <stgraber> skaet: AFAIK, only ubuntu alternate amd64 would need respinning. Edubuntu also ships LTSP but shouldn't be affected as we ship i386 LTSP on our amd64 DVD
[19:27] <skaet> superm1,  jibel  mythbuntu (i386, amd64) posted - 20110413.3
[19:28] <highvoltage> stgraber: indeed.
[19:28] <skaet> stgraber,   ok,  will start getting it ubuntu alternate amd64 queued up for when you give the signal.
[19:28] <stgraber> skaet: ok, my ltsp 64bit install just finished and works fine with my fix. I'll have the new package uploaded in the next 5 minutes
[19:29] <stgraber> hehe, first time I release a new upstream LTSP with a diff of just one line ;)
[19:29] <stgraber> well, technically, 6 chars ;)
[19:36] <stgraber> debdiff for ltsp 5.2.7-0ubuntu1 to 5.2.8-0ubuntu1: http://paste.ubuntu.com/593691/
[19:36] <stgraber> (it's uploaded)
[19:45] <scott-work> charlie-tca:   forgive my ignorance, is this just a matter of removing the dependency on hal?
[19:46] <scott-work> charlie-tca: would we be able to delay the beta 2 release for ubuntu studio ?  i don't think the studio team would mind, but i realize it might make it difficult for others
[19:47] <mvo> http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ <- woah, mostly green (white), amazing. main-all also has a amazing runtime
[19:57] <superm1> skaet, yay, finally no longer oversized! :)
[19:57] <superm1> it's still weird that amd64 is 50mb bigger, but not a big deal anymore
[19:58] <skaet> superm1,  yay!
[20:04] <stgraber> pitti, slangasek: Can one of you review that ltsp upload ?
[20:04] <stgraber> or anyone else who has that power :)
[20:10] <skaet> stgraber,  am looking for one of the archive admins to see if they can help... pitti and cjwatson are offline right now.
[20:12] <seb128> skaet, what do you need exactly?
[20:13] <jdstrand> I am here
[20:14] <jdstrand> seb128: ^
[20:14] <seb128> ok, I'm here as well ;-)
[20:14] <jdstrand> seb128: skaet pinged me privately. I've got it. thanks!
[20:14] <seb128> ok
[21:01] <jibel> skaet, ^ scott-work> charlie-tca: would we be able to delay the beta 2 release for ubuntu studio ?  i don't think the studio team would mind, but i realize it might make it difficult for others
[21:01] <charlie-tca> I misseed that
[21:02] <charlie-tca> Sorry, must have been fighting with screen-reader then
[21:02] <charlie-tca> jibel: glad you caught that!
[21:03] <skaet> jibel,  scott-work,  charlie-tca;  depends on degree of holding up.  We have some flex.
[21:03] <skaet> but not a lot
[21:03] <charlie-tca> I seem to be a go-between
[21:03] <skaet> thanks for flagging jibel,  am bouncing between too many windows today.
[21:03] <charlie-tca> He asked when the images needed to be tested by. I tried to answer and told him about the bug
[21:04] <skaet> charlie-tca, what's the outlook on a fix?  and the time for retest?
[21:05] <charlie-tca> I don t know
[21:05] <charlie-tca> I think he just has to remove the dependency on hal from the seed, doesn't he?
[21:06] <charlie-tca> I don't know if anything in -studio actually requires hal, but I don't think so
[21:08] <highvoltage> stgraber: 84% at 68KB/s, 1:57:14 est.
[21:08] <charlie-tca> We don't actually have anyone available that can authorize any changes to the image right now.
[21:09] <scott-work> charlie-tca: sorry, my webchat dropped the connection, if you responded earlier i missed it
[21:09] <charlie-tca> scott-work: As far as I know, yes, it is simply removing the hal dependency
[21:09] <charlie-tca> I don't believe you have anything requiring it, do you?
[21:10] <scott-work> charlie-tca: righty-o, i don't believe so, but i would like to check with luke or persia first to make sure there's nothing i'm missing
[21:10] <charlie-tca> We were just talking ablut you
[21:10] <scott-work> charlie-tca: about me?
[21:10] <stgraber> highvoltage: I started another transfer in the mean time (rsync against ubuntu DVD that I already had around), 37s remaining
[21:10] <charlie-tca> scott-work: yup
[21:10] <charlie-tca> scott-work: <skaet> charlie-tca, what's the outlook on a fix?  and the time for retest?
[21:11] <scott-work> charlie-tca: if luke is amenable we can update the seeds tonight i would expect
[21:11] <charlie-tca> scott-work: hal was moved from main to universe
[21:11] <charlie-tca> skaet: ^ ^
[21:12] <scott-work> but i believe luke is currently asleep, i usually try to catch him aroud five hours from now
[21:12] <jibel> skaet, smoser what's the news about ec2 ? anything ready for testing or is it still building ?
[21:12] <skaet> charlie-tca, scott-work,  how long to retest once the images are biuldt.
[21:13] <jibel> skaet, ~ 40mn for an arch
[21:14] <skaet> jibel, thanks.
[21:14] <charlie-tca> fast connections help; mine are about 45 minutes each test
[21:15] <skaet> jibel, re: smoser should speak for himself, but the impression I've gotten is that the bug fix was found, and they're building.   Should be going up in a few hours, but I haven't seen any further details about an actual ETA.  :(
[21:16] <smoser> probably 7 hours-ish from 17:55:15 +0000
[21:16] <smoser> (that was start time)
[21:16] <smoser> so another 4.5 hours probalby. they're being published.
[21:17] <jibel> smoser, thanks
[21:23] <skaet> scott-work,  as soon as you have a fix ready, ping me or pitti (depending on the time ;) ),  and if we can generate images and you can get them tested in time, we'll include them.  Otherwise they'll need to go out after the announce.
[21:25] <scott-work> skaet: copy that
[21:30] <stgraber> skaet: any ETA on the alternate rebuild (if we're still rebuilding ubuntu alternate amd64) ?
[21:30] <skaet> stgraber,  waiting for the publisher to land the updates into the archive,  then willl kick it off.
[21:31] <stgraber> ok, cool. I probably won't have time to test it before I leave the office but will do so when I get back home (probably 10-11pm EDT). Only takes me ~20 minutes to test LTSP.
[21:31] <cjwatson> charlie-tca: how about I just do it?
[21:31] <cjwatson> would that be dreadful?
[21:32] <charlie-tca> It's up to scott-work, I don't have anything to do with studio
[21:32] <cjwatson> 'bzr blame' says that that seed entry dates from a 2006 commit by mdz
[21:32] <cjwatson> which was just comment removal actually
[21:32] <scott-work> cjwatson: if you want to remove the hal dependency i wouldn't view that as dreadful at all :)
[21:32] <Daviey> Does anyone here have an VMWare-ESX setup?
[21:32] <cjwatson> and before that, back to revision 1 when I imported the Ubuntu seeds from the wiki
[21:33] <cjwatson> so it doesn't look like it was ever explicitly added for ubuntustudio
[21:33] <cjwatson> scott-work: OK, I'm going to go ahead and seek forgiveness rather than permission then
[21:33] <charlie-tca> Teach me to answer questions here, huh?
[21:33] <stgraber> Daviey: that can be arranged. I no longer have access to it but I'm still in a building where we have one ;) (highvoltage has access)
[21:33] <stgraber> Daviey: VMWare ESXi 4.1 enterprise plus IIRC
[21:33] <cjwatson> heh
[21:34] <Daviey> stgraber, Well i wouldn't want to get you in trouble, but would you be able to do the server test case for that?
[21:34] <stgraber> highvoltage: ^ can you start a server install on verdi ?
[21:34] <highvoltage> stgraber: maybe mjeanson would do it :)
[21:34] <highvoltage> well, I wouldn't mind either...
[21:35] <Daviey> highvoltage, \o/
[21:35] <Daviey> highvoltage, http://iso.qa.ubuntu.com/qatracker/result/5442/267
[21:36] <stgraber> highvoltage: rdesktop to cooper.appsrv.sherb.rlnx.com, open VMWare vsphere, connect to verdi.dev.sherb.rlnx.com as root (the vcenter seems to be down)
[21:37] <stgraber> highvoltage: it's access to the same shared directory as chopin, so you'd just need to wget the image to chopin's shared directory first
[21:40] <highvoltage> Daviey: 64bit or 32bit?
[21:40] <Daviey> highvoltage, either|both :)
[21:41] <Daviey> I'm a bad man, because i care more about amd64.
[21:42] <highvoltage> I'll start with amd64 then
[21:44] <cjwatson> so this ubuntustudio-meta change is going to be kind of guesswork; it's hard to test in advance
[21:44] <cjwatson> I can try
[21:45] <cjwatson> (and I'm probably best-placed to fix this particular category of bug, in all honesty)
[21:45] <skaet> cjwatson,  thank you.  (and I agree.... )
[21:47] <cjwatson> I've removed hal, and rejigged the Task-Seeds fields to match the STRUCTURE inheritance - the ffmpeg-common seed was what was supposed to make all those libavcodec dependencies behave consistently
[21:47] <cjwatson> regenerating ubuntustudio-meta based on that now
[21:48] <pitti> charlie-tca, scott-work: why do you think it's the hal dependency?
[21:48] <pitti> are we talking about the ustudio uninstallability here?
[21:49] <pitti> http://cdimage.ubuntu.com/ubuntustudio/daily/20110413/report.html doesn't look like it would be due to hal, as that would reflect on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html as well
[21:49] <charlie-tca> pitti: yes, since the error was hal unavailabl
[21:49] <pitti> my first suspicion would be that it's because something tries to pull in libavcodec?
[21:49] <cjwatson> see above
[21:49] <cjwatson> I suspect it may well be that and that hal is just a casualty
[21:50] <pitti> aah
[21:50] <cjwatson> but if anything in ubuntustudio-desktop needed hal, shouldn't it be an explicit dependency?
[21:50] <charlie-tca> bug 760008
[21:50] <ubot4> Launchpad bug 760008 in ubuntustudio-meta (Ubuntu Natty) (and 1 other project) "amd_64 studio install fails (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/760008
[21:50] <cjwatson> when I went through bzr blame, it looked like it was just left over from ancient Ubuntu seed entries
[21:50] <pitti> cjwatson: ideally yes; a lot of old packages still just assume that it's there unfortuantely
[21:50] <cjwatson> oh
[21:50] <cjwatson> do you think I should put it back then?
[21:50] <pitti> the ones which could need it would  have a libhal1 dependency, though
[21:51] <cjwatson> I can check germinate output for that
[21:51] <pitti> cjwatson: no idea, I'm afraid; I know that e. g. pitivi still can use it for some features, but it's usually not critical
[21:52] <pitti> a good test is to start the main things in u-studio and then check if "hald" is running
[21:52] <pitti> as it's triggered via dbus-activation, this should tell whether anything needs it
[21:52] <cjwatson> is libhal1 a reliable test?
[21:53] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.natty/rdepends/hal/libhal1 says that the only thing pulling it onto images is hal itself
[21:53] <pitti> cjwatson: positively reliable, but not negatively
[21:53] <pitti> i. e. you can also talk to hal directly via dbus
[21:53] <cjwatson> ah
[21:53] <pitti> (which is usually what python programs do)
[21:53] <cjwatson> OK, I'll revert that seed change then
[21:54] <pitti> I certainly hope it's just cruft, but I can't really tell without actually examining the programs
[21:55] <pitti> my preferred fix for this would certainly be to explicitly add hal dependencies
[21:55] <pitti> it's not something that should be seeded; but I realize that it's a little late for that in natty
[21:56] <cjwatson> OK, reverted with a mini-essay in the commit log
[21:56] <cjwatson> and generating ubuntustudio-meta again
[21:57] <stgraber> pitti: "grep -r hal /" then filter out the false positives :)
[21:57] <pitti> stgraber: and org.freedesktop.Hal
[21:58] <pitti> stgraber: actually, that or a dependency to libhal1 should be quite sufficient
[21:58] <pitti> programs either use libhal1 or open a d-bus connection to org.fd.Hal
[21:59]  * pitti wonders how often we need to stab this beast before it's dead for good
[22:01]  * skaet keeps looking to see if ltsp_5.2.8 has landed.... grrr not there yet.
[22:03]  * charlie-tca tried to kill it again
[22:05] <stgraber> pitti: on my laptop (so, mostly standard ubuntu), I get: libnet-dbus-perl, pitivi, pm-utils, python-apport, checkbox, gnome-power-manager and virt-manager
[22:05] <Riddell> skaet: it presumably won't get in until this publisher run has finished
[22:05] <stgraber> pitti: I can easily run the same check on studio to check the difference if that helps
[22:06] <skaet> RIddell, yup, waiting for the publisher run started over an hour ago to finish....
[22:07] <pitti> stgraber: e. g. pm-utils has a fallback if /sys doesn't work (mostly for BSD right now)
[22:07] <pitti> stgraber: python-apport?!?
[22:07] <pitti> stgraber: ah, haha! it's an example stack trace in the test cases :)
[22:07] <pitti> guess when I wrote that code..
[22:08] <pitti> stgraber: I'm just afraid I can't modernize that, because of course udev, udisks, upower etc. never crash!
[22:08] <pitti> *cough*
[22:08] <stgraber> pitti: yeah right :)
[22:09] <pitti> stgraber: but anyway, I doubt that merely having hal installed causes any problems; it won't even start by default
[22:09] <pitti> I don't think we should rip it out that lalte
[22:10] <pitti> "late"
[22:10] <stgraber> yeah, that's the kind of things you usually want done before Feature Freeze, so you have enough time to find and fix whatever breaks
[22:11] <pitti> cjwatson: just to ensure that I understand http://launchpadlibrarian.net/69309093/ubuntustudio-meta_0.83_source.changes, will that install alternative dependencies which lead to not pulling in libavcodec?
[22:12] <scott-work> pitti: blender was uninstallable i believe due to libavcodec
[22:12] <skaet> pitti, cjwatson, stgraber - ARCHES='amd64' for-project ubuntu cron.daily kicked off
[22:13] <ScottK> pitti: Not that it's relevant for Ubuntu Studio, but we do have a problem in KDE where if hal is present, KDE solid will start it and use a mixture of data from it and upower with unfortunate results.  So there are cases where installing it can cause problems.
[22:14] <cjwatson> pitti: so libavcodec is odd
[22:14] <cjwatson> (and friends)
[22:14] <cjwatson> pitti: there are a bunch of libfooN, and then a bunch of libfoo-extra-N
[22:14] <cjwatson> pitti: they conflict - you have to consistently select one set or the other
[22:15] <cjwatson> pitti: normally, we use libfooN; but a few things in ubuntustudio need libfoo-extra-N, so ubuntustudio needs to consistently select that throughout
[22:15] <pitti> and libavcodec-extra-52 is sufficiently patent-free to allow it on media?
[22:15] <cjwatson> pitti: convincing the package management toolchain to do that is most easily done by seeding the lot further down
[22:15] <pitti> or do we basically ignore the libavcodec patent issue on u-studio?
[22:15] <cjwatson> I *think* the latter
[22:16] <pitti> it makes sense as we don't press CDs for that, anyway
[22:16] <cjwatson> because we've shipped libavcodec52 before, and we avoid even that for Ubuntu
[22:16] <pitti> cjwatson: thanks for the heads-up
[22:17] <pitti> I'd like to accept shared-mime-info and xdg-utils (translation updates only), objections?
[22:17] <pitti> erm, xdg-user-dirs
[22:18] <pitti> mostly as an opportunistic improvements for any rebuild we might need to maek
[22:18] <cjwatson> I don't mind
[22:20] <pitti> cjwatson: what is lxc? do we need the debootstrap upload for b2 for anything?
[22:20] <cjwatson> 18:50 <cjwatson> debootstrap upload (appearing shortly) isn't needed for beta-2
[22:20] <pitti> thansk
[22:20] <skaet> jibel, stgraber,  ubuntu alternate amd64 posted  (ltsp fix)
[22:20] <cjwatson> lxc => containers.  the bug in question has been worked around in lxc already, but fixing it properly in debootstrap is IMO the right thing to do
[22:21] <scott-work> pitti, cjwatson, charlie-tca, skaet :  i am going home, if you need me for any ubuntu studio issues you can reach me at ScottL in about 30 minutes
[22:21] <cjwatson> scott-work: ok, it'll need retesting after metapackage lands and CDs rebuild
[22:21] <scott-work> cjwatson: aye
[22:25] <highvoltage> Daviey: this is just creepy :) http://irc.jonathancarter.org/files/dump/esxi-aubergine.png
[22:27] <cjwatson> off for a bit
[22:30] <Daviey> highvoltage, Sorry, i don't follow.
[22:30] <highvoltage> Daviey: it failed :( ubuntu-standard is installed and the virtual kernel not, I'm *quite* sure I chose install minimal server from gfxboot, but I'll double-check now just to be sure
[22:31] <Daviey> highvoltage, oh dear... thanks.
[22:31] <stgraber> skaet: downloading
[22:31] <highvoltage> Daviey: an aubergine debian-installer with a windows task bar? maybe it's just me then
[22:31] <Daviey> highvoltage, OIC :)
[22:36] <highvoltage> this time d-i seems to get confused when I enter my password
[22:37] <highvoltage> I get a blue screen then a red screen telling me my password is blank and when I press enter it doesn't give me a chance to go back
[22:37] <highvoltage> (eventually it worked, weird)
[22:38] <Daviey> highvoltage, yeah, i noticed on error it seems to present traditional blue.
[22:38] <Daviey> I'm not sure we need to fiddle with the colours anymore this cycle :)
[22:39] <pitti> skaet: want me to set up a triggered rebuild for ubuntustudio, or want to kick it off yourself?
[22:39] <pitti> bbiab
[22:41] <skaet> pitti,  i'm fine with kicking it off, once things are ready.   What should I be triggering on?
[22:41]  * skaet likes to be able to see directly when its done.... ;)
[22:49] <highvoltage> Daviey: this time it did ok, but it's oversized (>500M)
[22:50] <Daviey> highvoltage, yeah... someone else found that on KVM... technically it's failed the test case - can you mark it so?
[22:50] <Daviey> I think we are OK with it (i think maverick released with the same)
[22:50] <Daviey> highvoltage, really appreciate your help with this.
[22:51] <Daviey> highvoltage, RoAkSoAx is raising a bug for it as we speak.
[22:53] <highvoltage> Daviey: I just finished filing a bug for it
[22:53] <highvoltage> https://bugs.launchpad.net/ubuntu/+bug/760288
[22:53] <ubot4> Launchpad bug 760288 in ubuntu "JeOS is oversized (affects: 1) (heat: 6)" [Undecided,New]
[22:53] <Daviey> highvoltage, ah perfect, thanks
[23:02] <pitti> skaet: when ubuntustudio-meta 0.83 binaries are available on antimony, i. e. wait-for-package ubuntustudio-desktop_0.83
[23:03] <skaet> pitti,  yup that's what I was looking to know.:)
[23:03] <pitti> skaet: cool; then I think I'll head bedwards :)
[23:04] <pitti> skaet: btw, on TechOverview do you actually like the sections which just say "Shotwell has been updated to 0.9.1."?
[23:04] <pitti> TBH I think we should remove them; version numbers aren't very interesting IMHO
[23:05] <skaet> pitti, well some folks care about versions (kernel folk for instance ;) )
[23:06] <Daviey> skaet, When do you need TechOverview done by?
[23:06] <skaet> pitti,  I'll get the known bugs put into the tech overview tonight,  and if you could take a pass in the morning to sanity (delete the uninteresting ones) that would be great.
[23:06] <skaet> Daviey,  EOD today...
[23:06] <pitti> skaet: sounds great
[23:07] <pitti> beta-2 will be a nice bday present tomorrow \o/
[23:07] <Daviey> skaet, great... now - 5 hours. ;)
[23:07] <pitti> so, good night everyone!
[23:07] <skaet> Daviey,  today being 3/13.
[23:07] <skaet> Daviey,  yup.
[23:07] <skaet> sleep well pitti
[23:07] <Daviey> jolly good.


[01:41] <benlake> roaksoax: noted, will add.
[01:44] <benlake> kiko: ThiagoCMC’s situation sounds familiar… but why would an update cause a redisovery of IPs, or is that more likely related to him probably adding subnets or a fabric or something?
[02:11] <xygnal> roaksoax i'll be around if you do come back, i'd like to verify what is needed in my curtin config to ensure it uses them.  Right now my storage blocks are not being used, though its not throwing errors either in the logs.
[08:41] <chrome0> Hi maas maintainers, do you have a timeline when you plan to pronounce 2.2 stable? I believe it's  currently labeled devel as it's in ppa:maas/next right?
[09:03] <chrome0> But maybe I'm confused about that devel label, as maas 2.2 is actually released with Zesty?
[12:51] <jamespage> congrats on the 2.2 release MAAS folks - looks awesome!
[13:07] <benlake> jamespage: where are you seeing 2.2 as released? I ask because I’m actually quite confused as to what package version is current and with what release
[13:08] <jamespage> benlake: https://docs.ubuntu.com/maas/2.2/en/release-notes
[13:08] <benlake> my 16.04.02 box installed 2.1.3 a few days ago, but according to packages.ubuntu.com it should only be 2.0.0-beta3   O.o
[13:08] <jamespage> I think its still +1 week off being in the stable PPA - roaksoax would be able to confirm that
[13:09] <jamespage> benlake:
[13:09] <jamespage>  maas | 2.1.3+bzr5573-0ubuntu1~16.04.1    | xenial-updates   | source, all
[13:09] <jamespage> 2.1.3 is in xenial-updates
[13:09] <benlake> even still I look at https://launchpad.net/maas/+packages and it says xenial should be at 2.1.5, but I don’t show an upgrade path to it via apt
[13:09] <jamespage> I think 2.2.x will end up there once its been through SRU
[13:10] <jamespage> benlake: try "rmadison maas"
[13:10] <jamespage> its a easier view of what is where
[13:10] <jamespage> 2.1.5 is in xenial-proposed ATM
[13:11]  * chrome0 would be eager to know when 2.2 lands in stable too
[13:12] <benlake> oic https://launchpad.net/ubuntu/xenial/+source/maas
[13:12] <benlake> what is rmadison?
[13:29] <roaksoax> benlake: http://www.roaksoax.com/
[13:29] <roaksoax> benlake: http://www.roaksoax.com/2017/05/maas-2-2-0-released
[13:32] <benlake> ah, thanks
[13:40] <chrome0> aluria : ^^ maas 2.2 to be avail in maas/stable next week and in xenial in the following weeks
[13:41] <chrome0> roaksoax : typo alert, you probably meant "has _now_ been released..."
[13:42] <aluria> chrome0: thx for the heads-up
[13:54] <roaksoax> chrome0: thanks!
[13:55] <chrome0> nw at all
[13:56] <xygnal> roaksoax hello :)
[13:56] <roaksoax> xygnal: howdy! i'm otp for the next ~2-3 hours, but share with me whta you have and i can look as meetings go
[13:57] <xygnal> roaksoax: do I need more than a storage block to convince curtin to install on a different disk?  Just setting the disks, partitions, and mounts does not seem to be enough.
[14:02] <roaksoax> xygnal: checking that now.
[14:02] <xygnal>  roaksoax my co-worker says those blocks appeared to work, but only if the boot disk in the servers BIOS was set to boot that disk.
[14:05] <xygnal> roaksoax we also can't use the same hard-coded disk every time for every model.   Can we do some kind of pre-script for storage that grabs that and makes it a variable?
[15:39] <roaksoax> xygnal: what do you mean with the latter ?
[15:40] <xygnal> roaksoax storage section in curtin needs a hard-coded device name
[15:40] <xygnal> roaksoax but we have different models, where the device name woud not be identical
[15:40] <xygnal> roaksoax can we gather that information and pass it into curtin?
[15:40] <xygnal> so that it is no longer a hard coded disk path
[15:43] <roaksoax> xygnal: ok, so in the preseed you have access to the 'node' objects
[15:44] <xygnal> i've never played with tthose.  link me a example?
[15:45] <roaksoax> xygnal: i'll give you in a sec. So If I understand correctly
[15:46] <xygnal> I can set boot and root in the API, they just dont apply.  If I can tell Curtin to use that information, we essentially get around the 'not supported' problem.
[15:48] <ThiagoCMC> Guys, MaaS Next is weird!
[15:48] <ThiagoCMC> It is failing to test a server...
[15:48] <ThiagoCMC> Error, `smartctl --xall /dev/sda -d sat` returned 24! See the smartctl man page for return code meaning
[15:48] <ThiagoCMC> Say what?
[15:48] <ThiagoCMC> =/
[15:49] <ThiagoCMC> blade was just working fine until I tried to re-commision it
[15:51] <kiko> have you tried doing what the message suggests?
[15:51] <ThiagoCMC> yep... researching but, no clue
[15:52] <xygnal> start rescue mode on the node and try to execute that command via ssh
[15:52] <ThiagoCMC> Is there any way to ignore that?
[15:52] <ThiagoCMC> cool!
[15:53] <roaksoax> ThiagoCMC: that could indicate that there's an error with your disk :) but also if you havea a full pastebin we could look would be great
[15:53] <roaksoax> ThiagoCMC: that said, you can decide not to perform hardware testing on commissioning
[15:53] <ThiagoCMC> Hmm...
[15:56] <roaksoax> ThiagoCMC: iy could also mean smart is not supported on your disks
[16:38] <mcuenca> hi everyone! maas region controller and maas rack controller are created under ".maas" dns domain. Is it possible to change that?
[16:59] <roaksoax> mcuenca: https://bugs.launchpad.net/maas/+bug/1686678
[17:01] <mcuenca> roaksoax: thanks! so, it is a bug, no problem. For sure the guys will resolve it. I'll try a workaround using CNAMEs... should work, right?
[17:02] <roaksoax> mcuenca: yes it should work
[17:03] <mcuenca> roaksoax: thanks! :D
[17:03] <mcuenca> roaksoax: I'll try in 30 minutes and I'll let you know
[18:04] <mcuenca> roaksoax: solved :) thanks!
[19:13] <ThiagoCMC> Is there an easy way to move a VLAN / subnet from fabric-1, to another fabric?
[19:55] <pmatulis> ThiagoCMC, did you try via the CLI?
[20:06] <ThiagoCMC> pmatulis, not really, I'm not familiar with CLI... I'll research about it! Tks!
[22:36] <benlake> so, if you toast your network connection to a server after deployment, there isn’t a password for the ubunut user to use via IPMI KVM, is there?
[22:37] <benlake> I get SSH is public key only, but is the expectation if there is a desire to directly access the machine, you should set the password after deployment?
[22:52] <mpontillo> benlake: that is correct
[22:52] <benlake> thanks
[22:54] <mpontillo> benlake: np. with kvm console access you should be able to recover in a normal way, such as init=/bin/bash on the kernel command line or some similar incantatin (haven't had to do that in awhile so I don't remember exactly)
[22:54] <mpontillo> *incantation
[22:54] <mpontillo> of course, that assumes you'd be okay with rebooting
[22:54] <benlake> gotcha
[22:56] <mpontillo> benlake: right, I think something like this still applies, even though the post is pretty old. https://askubuntu.com/questions/24006/how-do-i-reset-a-lost-administrative-password
[22:56] <mpontillo> (heh, init=/bin/bash, that was a trick I used probably 20 years ago.)
[23:15] <benlake> with devices you can define a parent. Is there not a way to assign a machine to machine relationship similarly?
[23:16] <benlake> use case being kvm guests. would be nice to have the metadata as to which machines will die with the base machine
[23:28] <benlake> anyone else being bit by the bridge forwarding delay “out of range” issue? supposedly a fix is in kernel v4.4.8 - that’s a ways off for xenial, no?
[23:42] <catbus1> Hi, a question about the IP mode in https://docs.ubuntu.com/maas/devel/en/installconfig-commission-nodes#post-commission-configuration
[23:44] <catbus1> If it's a managed subnet and if auto assign is selected, the node will get the IP not in the reserved IP range. But if it's dhcp, the node will get the IP from the reserved dynamic IP range?
[23:45] <benlake> Re: forwarding delay. Value must be less than “hello” time; unless STP is off.
[23:45]  * catbus1 finds managed vs unmanaged and reserved IP range confusing.
[23:46] <benlake> catbus1: I do as well.
[23:46] <benlake> so auto assign uses anything not reserved
[23:46] <benlake> dynamic range is for DHCP
[23:46] <catbus1> another question, can I assume the fabric will show up as 1:1 mapping to the physical interfaces on the machine?
[23:46] <benlake> reserved range is unused by MAAS
[23:47] <catbus1> but reserved IP range is used by MAAS and the subnet is in unmanaged mode.
[23:48] <benlake> when you say “is used by maas”, where did you see maas us it?
[23:48] <catbus1> *when* the subnet is in unmanaged mode.
[23:48] <catbus1> "When management is disabled for a subnet, the definition of a reserved IP range differs from the managed mode. Here, a reserved IP range tells MAAS to only allocate addresses from this range (via 'Auto assign'). In addition, DHCP will never lease addresses from an unmanaged subnet." from https://docs.ubuntu.com/maas/devel/en/installconfig-network-subnet-management
[23:48] <benlake> what version of maas are you using?
[23:49] <benlake> I’m 2.1.3 and I have no “mode” for a subnet.
[23:49] <catbus1> I am on 2.2
[23:49] <mup> Bug #1693644 opened: Enlistment does not validate min_hwe_kernel <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1693644>
[23:49] <benlake> oic, then that’s new to me.
[23:50] <benlake> but reading that, it apparently changes the “reserved range” that would otherwise not be used in “managed” mode, to the range that will explicitly be used in “unmanaged” mode.
[23:51] <catbus1> yes.
[23:51] <benlake> that ^^ is the answer to your original question :)
[23:51] <catbus1> but if it's unmanaged, why is maas giving out ip addresses?
[23:51] <benlake> did you reserve a range from this unmanaged subnet?
[23:52] <catbus1> I didn't do anything yet, I am trying to understand first what's the expected behavior.
[23:52] <benlake> if so, then MAAS will use it for any interface using “auto assign” (at least that was the 2.1 term)
[23:53] <benlake> if you don’t want an unmanaged subnet to be used in any way, then just defined it as unmanaged and leave it alone