[02:47] ScottL, holstein: We have two days before we have to have certified some image. If the current image isn't certifiable, we need to sort things, and get an image rebuild, etc. That's the rationale for the two days. [02:55] persia, should we certify an image that might have approximately 20 applications that are not installable? [02:56] ScottL, I don't think so :) [02:56] Better to sort the apps. Is it known what is wrong? [03:03] ScottL, persia, anything I can help with? [03:04] hello paultag :) [03:04] ScottL, Hey there :) [03:05] we got this email from colin watson this morning https://lists.ubuntu.com/archives/ubuntu-studio-devel/2010-September/002634.html [03:05] I see there are some failed builds? Need an extra hand to go through the source packages? [03:05] ScottL, ouch! [03:05] indeed [03:05] there are some big names on there [03:05] to be honest, a lot of times these tend to sort themselves out because it is also effecting ubuntu [03:06] ScottL, jack-rack and agave look like the ones the might be left to ubuntu studio at first glance [03:06] and ubuntustudio-* [03:07] but these all were building correctly until this morning they all most likely share a common cause [03:08] mm [03:08] I'm running a build of agave_0.4.7-1ubuntu1 just to see :) [03:09] Oh shucks, it's also not amd64 [03:09] nevermind :) [03:11] i wish there was an easy way to see if they have a common dependency [03:12] ScottL, they're mostly GTK apps, I'd venture GNOME, Glade or GTK+ [03:12] My money is on a GTK+ package [03:15] persia, you linked something before that showed all the FTBFS packages or similr [03:15] similar [03:15] i remember this http://people.canonical.com/~ubuntu-archive/NBS/ [03:15] but that's not what i'm thinking about [03:16] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/maverick/daily-20100928.log maybe? [03:16] I know there was some significant change to GTK just before the RC freeze. [03:17] no, that's the cd image, there was a list of package builds that failed [03:17] http://qa.ubuntuwire.com/ftbfs/ ? [03:17] persia, although i noticed we seemed to be trying to install busybox in the ubuntustudio cd image :? [03:18] I think it's used by the installer [03:19] the link you gave me before seemed to be on people.canonical.com and seemed to have a person's name in it [03:20] it was a link like the NBS....argh, this is deja vu and i don't like it :P [03:20] ScottL, was it Martin Pitt ( pitti ) ? ( he has a lot on his people.ubuntu ) [03:20] For stuff that failed to build or failed to install? [03:21] persia, i remember looking at this list while we were exploring why packages failed to build installable binaries [03:21] I probably pointed at http://people.canonical.com/~cjwatson/packagesets previously, which provides a list of packages of interest to us. [03:21] paultag, possibly, but i don't think so [03:21] NBS is most likelu [03:22] it's not uber critical though [03:22] The standard check for packages which cannot install is `apt-cache -i unmet` run locally [03:24] Maybe somewhere under http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.maverick/ ? [03:31] no, it was ubuntu studio specific, it had a lot of packages that didn't build, it was probably NBS [03:32] persia, i guess i should start a discussion with someone in #ubuntu-release and mentioned wanting to rebuild the RC image when we get the packages squared away [03:32] Let's make sure everything installs first, and *then* bother Riddell. [03:32] I think it's late for him anyway right now. [03:43] * persia attempts to install all the packages marked as uninstallable in that report [03:44] Note that they are all amd64: the i386 images may be in better shape. [03:44] persia, yeah, I just did a dsc build of agave, built and installed with success [03:44] ( the one that failed ) [03:44] It must be a dependency problem, everything looks OK at first glance [03:45] paultag, Or could have been a dependency problem at the time the report was made, now resolved. [03:46] Because it's all amd64, I suspect it's a timing difference between i386 and amd64 buildds. [03:46] aye, oh -- my build was on an i386, so it's not on the affected platform anyway [03:46] I think so [03:46] erm, effective [03:46] even though affected could be right [03:50] Given that we don't know if it's affected yet, I'm not sure we can be effective in fixing it :) [03:50] :) [03:53] * ScottL 's 3 year old son found the Desitin in his backpack and made a complete mess :( [03:54] heh [05:39] OK. Install completed. We should be fine for both i386 and amd64 images. [05:39] Has anyone tried them yet? [05:54] persia: Not yet, but I zsynced just a while back, will try in an hour or so. [05:54] persia: And amd64 specifically. [05:54] Cool. I also saw that Riddell announced images in #ubuntustudio some 7 hours back. [05:55] * persia is waiting for rsync to complete [05:55] Yeah he did, but weren't they broken at that time, though? [05:56] Don't think so. [05:56] Okay. [05:56] I certainly didn't fix anything: just checked. The notice of uninstallable packages was out-of-date [05:56] Right'o. [06:42] Yeah there were some mismatches that I remember Seb talking about yesterday, packages initially FTBFs on amd64, but have been rebuilt once things settled down. [06:48] Indeed. All looks good now. [08:29] An hour my 4$$. :) Installing now, though. :) [09:11] An awful lot of hash sum mismatches. [09:12] ...and aptitude failed (100) [09:59] Okay, filed LP #650953, and marked test case as failed. [09:59] Launchpad bug 650953 in Ubuntu Studio "Ubuntu Studio rc 20100928.1 fails" [Undecided,New] https://launchpad.net/bugs/650953 [10:03] Could you attach some logs or something? [10:03] persia: How is that done? [10:03] "Add attachment or patch" [10:03] persia: I mean, how do I get the log from the install? [10:04] Uhhhhh.... [10:04] Check /var/log and /target/var/log for stuff: those are the most likely places. [10:04] Try to find something matching your console issues. [10:04] Also, did you verify the checksum of the media? [10:04] Okay. [10:04] Hmm... come to think of it, I didn't. [10:05] They're a match. [10:05] Hrm. I was hoping that was the issue, Hrm. [10:09] Recalled hosltein's instructions on serving the log files on a http server, and boyee what did I find! [10:09] Sep 29 08:10:06 kernel: [ 2393.113074] end_request: I/O error, dev sr0, sector 3817812 [10:09] Sep 29 08:10:06 kernel: [ 2393.113078] Buffer I/O error on device sr0, logical block 954453 [10:09] Sep 29 08:10:06 kernel: [ 2393.113082] Buffer I/O error on device sr0, logical block 954454 [10:09] Sep 29 08:10:06 kernel: [ 2393.113087] Buffer I/O error on device sr0, logical block 954455 [10:09] on and on and on [10:10] Faulty dvd? [10:10] Probably [10:10] Or dirty play heads. [10:10] Hmm... so, try again with a new blank, and what then if it doesn't fix it? [10:11] How do I clean the "play heads"? [10:11] astraljava: Before that try to check the disc (when you start as livedvd). [10:12] abogani: Okay. [10:13] Actually, given that it's a DVD, it's really a lens that gets dirty, rather than "play heads", but same idea. There's a kit you can get that cleans the sensors for optical disks (same kit ought work for CD/DVD/BR/etc. [10:17] Ok, will have to check those out the next time I'm in the city. [10:18] They're generally not needed for the lifetime of the player. Heavy users need them every year or two. [10:18] Yeah, CD-ROM integrity check fails. :( [10:18] (excluding folks who fail to use dust jackets) [10:18] OK. Please mark the bug "Invalid" and try again :) [10:18] Will do. [10:18] Thanks. [10:21] Trying to burn another disc now. [11:21] Nice, the second disc checks out on integrity, and installing now. [11:24] good [12:03] i'm glad to hear that the failed builds seem to be resolved (or not an issue), downloading ISO myself and will test tonight when i get home [12:04] * ScottL is heading to the office [12:04] oh, and is anyone interesting in helping with team reports [12:05] https://wiki.ubuntu.com/TeamReports [12:11] Yup, marked as passed for auto-resize. [13:32] ScottL, In reference to recent discussion in #ubuntustudio: did you ever have luck coordinating with doctormo regarding the state of tablet support? [13:43] for those interested in the team reporting: https://wiki.ubuntu.com/UbuntuStudio/TeamReports [13:43] persia: not really, we talked around it without developing points of action [13:44] although, it's funny you mention it because i was thinking about tasks and workflows and thought about doctormo and the driver [13:44] he needs to get in it included into the repos before we can actually install it, no? [13:44] i was going to follow up with him this week about getting it into the repos [13:44] . [13:45] He's doing work that directly affects the same set of users we target with -graphics: be extra good to convince him to accept "Ubuntu Studio" as "us" internally as an identity :) [13:45] of course this is all based on believing that it will take time to ge the drivers included in the kernel [13:45] They don't need to be in the kernel. DKMS is fine. Just need a clear path to ensure that the work he's doing in his PPA is also present in the distribution by default. [13:45] and therefore to include it with the ISO it would need to be in the repos for a year or so [13:45] Telling every user to add a PPA post-install isn't "Just Works" [13:46] DKMS? [13:46] We can include stuff on the ISO that got pushed to the repos last week. [13:46] Dell Kernel Module System (or something). [13:46] oh yea, i just read something about that in Linux Format (i think, read it somewhere) [13:46] "Dynamic Kernel Module Support Framework" (originally developed inside Dell) [13:47] i'm still fuzzy on how we get it from his PPA into the ISO then [13:48] oh, sorry, i think i misread what you meant [13:48] i believe you meant: [13:48] 1. it doesn't need to be in the kernel because of DKMS [13:48] 2. it DOES need to be in the repos [13:48] 3. we can add it rather late, even stuff that pushed last week [13:49] . [13:49] Right, but it doesn't need to be in the repos for a year or so: should only require a day or two. [13:49] Well, we're constrained by release management. [13:49] oh, no...i mean i would not expect it to get pushed into the kernel for a year or so, that's why we need it in the repos now :) [13:50] so we can provide that functionality by including it on the ISO as a package, then when it's in the kernel we don't need the package included anymore [13:51] either way, i'll follow up with doctormo today about the status of the package [13:51] my feeling was that it wasn't in the repos yet and there didn't see to be a burning fire of desire to get it into the repos at this time [13:52] might not be viable for maverick then, but i would expect it for natty however [13:52] Right. [14:10] So, apparently something in our packageset depends on ia32-libs. Given the nature of this package, we probably want to track down whichever is to blame and make it not do that. [14:10] Installed-size is 143MB: one of the largest packages around. [14:13] ScottL, hi! [14:14] did they update lmms? [14:15] Not according to rmadison, and not going to happen at least until RC is published. [14:36] quadrispro: persia: i also thought we were wating for sevenmachiens to either package 0.4.8 or resolve some dependencies for 0.4.7 [14:37] quadrispro: which brings up something, have you read through the ubuntu bug report ? it mentions debian possible separating the packge to have -vst seperated from lmms to avoid wine and the tts-mscorefonts-installer [14:38] #606533 [14:38] bug 606533 [14:38] Launchpad bug 606533 in lmms (Ubuntu) "Please merge lmms 0.4.7-2 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/606533 [14:40] was comment #9 but it was tobias who actually said he would have 0.4.8 in his PPA [14:41] quadrispro: is this something that we might be able to do in debian as well, which would also help with reducing the delta ? [14:42] well... I don't know, I've re-boot'd my life just today, I took an exame [14:42] exam * [14:43] ah, lmms is not under pkg-multimedia umbrella [14:43] we should get in touch with the maintainer [14:46] how do you feel your exam went? what are you studying? [14:46] quadrispro: ^^^ [14:47] scott-work, I've spent all the summer and the exam has gone bad [14:48] I was studying physics II [15:50] morning /afternoon /evening [15:50] scott-work, persia, astraljava, started now testing the RC on Vbox for i38 [15:50] the manual partition and after the auto resize [15:51] Might be nice to tell the folk in #ubuntu-testing : they sometimes seem to think we don't test. [15:51] i will [15:51] i marked it down on the tracker as started [15:51] but i tell ara [15:53] persia: ;) [16:03] Don't they see it from the reports? :D [16:04] Yeah, I'll do other test cases tomorrow, am a bit tired and the flu is fighting back hard... [16:04] astraljava, Yes, but there's a sense of "everyone working together" that is sometimes missing from the reports. [16:04] astraljava: persia idea is to do a positive reinforcement [16:04] astraljava, Get better! [16:04] they think we dont care, so we should show them otherwise [16:04] persia: Thanks! [16:04] Yeah okay, I was partly joking only. [16:05] lol [16:49] ah, quadrispro has left already :( [16:49] hi rlameiro [16:50] scott-work: how is work? [17:01] i386 is almost finished testing [17:01] is there someone up to AMD64? [17:02] i can [17:02] do i need to? [17:02] are they failing? [17:03] AFAIK no, but at the moment i am testing the auto resize i386 [17:03] cool [17:03] but if I start testing all the ISOS, i dont do nothing more today [17:03] yeah [17:03] rlameiro: holstein: I did auto-resize for amd64 today, will do the others tomorrow if no-one else does before. [17:04] astraljava: COOL [17:04] thanks [17:04] I can try to do the test, but i cant promise nothing [17:05] I rather will save the blank DVDs for the final release :D [17:05] * holstein got some DVD-RW's :) [17:06] yeah, i need to buy some rw tooo [17:06] holstein: i was an alarmists, well meaning, but an alarmist nonetheless :P [17:06] * rlameiro MAJOR FAIL --- ISO tester without RWsss.... [17:06] Heheh. :) [17:06] scott-work: about the iso's? [17:06] or the failing? [17:07] Yeah I learnt that lesson back in the day. [17:07] holstein: the ISO and the failed builds [17:07] hehe [17:07] maybe an alarmed realist :) [17:07] apparently the building installable binaries in the email were before the ISO's were made and was fixed [17:07] that happened to me last time [17:08] i grabbed the builds *right* after i got the message they were ready [17:08] scott-work: you werent the only, me too was kinda alarmed, I even commented it out with persia [17:08] and blew about 3 hours testing with the old iso [17:09] We should probably identify someone to be *the* testing contact, who coordinates closely with the release and testing teams, and helps tell the rest of us when it's safe to pull the ISOs for testing. [17:09] cwatson??? [17:09] lol [17:09] yeah [17:09] a liason [17:09] iso-liason [17:10] I dont see stochastic long time.. [17:10] yeah :/ [17:10] he is the "testers" boss :D [17:11] i was thinking about stotastic a bit ago [17:11] I wonder if he is ok.... [17:16] i agree with persia , but i would rather that it is someone other than me :) [17:16] err, that was suppossed to be a ;) not a :) [17:16] scott-work: I agree with you [17:16] i expect stochastic is just busy [17:16] you cant do everything [17:16] Indeed, so whilst stochastic is away, we need someone to cover. [17:16] and you need to be protected from burning out [17:17] we had a lot of burn outs in the last years, i dont want that to happen with you.... [17:17] I think the best protection against burnout is to have well-defined roles, and switch roles each cycle. [17:17] That said, I think it's best to have consistency in project leadership over longer terms (but to avoid burnout, that requires delegation of all the other roles) [17:18] exactly [17:19] I think tha holstein should be promoted and assigned as Recruiter [17:19] he is ver active on IRC channels, people respect him alot [17:19] holstein, Are you up for that, in addition to being "Chief Master User Support Expert"? [17:19] and he can see who is more time at the channel, and involved [17:19] maybe he can pull out some of them to test stuff [17:19] Right, but he is also busy, for all those reasons. [17:20] yeah [17:20] true... [17:21] well, maybe I should change the name, insted of recruiter, maybe "Ubuntu Studio PR person" :D [17:21] he is a PR already ::D [17:22] if he need to forward he can send to me the nicks of users, and i can explain how to test iso and stuff [17:22] rlameiro, or put it on a wiki ;) [17:22] he can be the "spliter [17:22] paultag: yeap, that is a plan that we should do for natty [17:23] we need to set especial parameters for our testing [17:24] I need to finish my thesis until October end [17:24] I hope ya'll don't mind if I don't find a "role" until the next cycle [17:24] after that I am with more time [17:24] I'm pretty locked up until the next cycle with my Ubuntu work :/ [17:24] +1 rlameiro [17:25] but beeing said that, i think that scott-work could organize some meeting to define what is the top 1 priority [17:25] and then try to implement and assign responsabls people [17:26] and maybe something between the IRC and Mailing list [17:26] All I have to do is offload like 80% of my workload to other people and I can help here, heh :) [17:26] there are a lot of user on the mailing list that doesnt come to the IRC [17:26] persia: sure [17:27] I can assign myself to design testing procedures, if scott-work is ok with that [17:28] seems like this iso-check master thing might be something less technical that i can handle [17:28] but, i will need experienced input on it, i dont feel confident enough for that task alone [17:28] rlameiro: Great! Does that mean you'll be the testing "liaison", then? [17:28] I know very few people working at canonical [17:28] i think that would be someone "inside" the Core devs of canonical [17:28] OH yeah, unless rlameiro wants to do it [17:29] There are lots of core devs who don't work for Canonical, and lots of folks Canonical hires to work on Ubuntu that aren't any sort of Ubuntu Developer. [17:30] holstein: holstein we can work together, designing a test case doesnt seem to be hard, but there are lots of diferent cases we should addres, and 2 heads are better than one :D [17:30] I don't understand, I thought persia suggested someone from _our_ team? [17:30] astraljava, I intended to do so. [17:30] ohh, ok [17:31] There are hardly any core devs here, not to mention Canonical employees. :) [17:31] persia: so, how will it work? [17:31] * persia believes there to be one core dev and two Canonical employees, but may be mistaken. [17:31] the assigned person will receive direct information from the release team? [17:31] Also, I think those folk are busy enough with other things :) [17:31] Well, here, you have it right. But in the team, once Luke quit... [17:32] rlameiro, Basically, someone who hangs out on #ubuntu-testing and #ubuntu-release and follows what is happening, being sure to be aware of how the changes affect testing ISOs. [17:32] humm [17:32] I'm sure charlie-tca or stgraber or someone could provide good insight into what is needed [17:32] * persia has never held that role for any flavour, but sees others do it, with seemingly less confusion [17:34] so the contacts is only to know what changed on the ISOs and warn people to strat testing [17:34] or are there more stuff? [17:34] maybe keeping track of testin schedule [17:35] rlameiro: i think your the guy for the job [17:35] if you want it [17:35] how about you feel free to delegate whatever you need to me [17:35] anytime [17:35] and we talk quite often anyways [17:35] well, i think i can try it [17:35] I can try and help, if you need me [17:36] maybe that was stochastic role IIRC [17:36] paultag: :) [17:36] rlameiro, Right. The role is for someone to keep track of schedule, respins, testing requirements, test coverage, etc. [17:36] YAYYYYYY [17:36] That person would be expected to coordinate the testing *with the help of others*, mostly on #ubuntu-testing. [17:36] i386 testing finished [17:37] And that person would be expected to help advise ScottL on when freeze exceptions would help or hurt the images. [17:37] \o/ [17:38] http://iso.qa.ubuntu.com/qatracker/test/4599 [17:38] ok, I can try to do that [17:39] are there some trainig sessions from the the testing team? [17:39] Dunno. I strongly suggest asking charlie-tca or stgraber for advice. They hold that role for Xubuntu and Edubuntu, respectively. [17:40] If you ask in #ubuntu-testing, others might chime in as well. [17:50] rlameiro: you have my sincere +1 for testing [17:50] ok [17:50] I am talking with ara at the moment [17:54] ok, need help in outline some optional test cases for Natty. [17:54] what do you think about: [17:54] Firewire hardware test [17:54] USB hardware test [17:54] Video camera hardware test [17:54] Jackd test [17:56] rlameiro: w00t [17:56] kernel test would be nice in some capacity for latency [17:56] firewire :) [17:56] if a consistent person with the same hardware could test it [17:56] yes, if there is a realtime kernel, we can also add a kernel test [17:57] not to split hairs mind you (i.e. 10msec vs 11msec) [17:57] but if a usual setting starts getting massive xrun (or a larger percentage) [17:57] just a gut feel test perhaps [17:57] I think the kernel latency testing shouldn't be part of validation. [17:58] But rather something separate, and special, that someone takes one, measuring latency over time, etc. [17:58] persia: not for validation!!! that will kill testing [17:58] optional test cases? [17:58] yes [17:58] That is why I mention it :) [17:58] you think that is the wrong place persia ? [17:59] ara told me that next cycle they will have""" Mandatory - Run Once & Optional (meaning really optional) :)""""" [17:59] maybe we can use that tracker layout either way [17:59] optional at the moment needs to be tested at least once per ISO [17:59] its really clear and easy to see what needs to be done for the test [17:59] well, i will do the QA wiki for the testing cases [18:00] holstein, Either way: I just don't want to block a milestone waiting for the specific person with consistent hardware to verify we don't have a latency regression. [18:00] but i could use some help making the specific procedures [18:00] agreed [18:00] persia: that was one of the things I wanted to be sure with ara [18:00] additional optional test cases only +1 [18:00] this kind of test are for reference [18:01] and mostly for the first release cycles to see if there are regressions [18:01] for instance on FFADO drivers or stuff [18:01] thqat way we can have time to ask for a respin [18:02] Right. [18:03] most of the time, people test if it installs ok and runs [18:03] but there are more stuff to test, the installer is important, but also the rest [18:07] i remeber the network manager problem..... [18:08] The installer isn't that likely to break, and most of it gets fairly well exercised by the server team. [18:08] well, but actually, it is what is beeing tested :D [18:08] I'm reminded: it may be worth chatting with mathiaz about his test automation framework: he has some nifty way of automating the complete run of all the server testing. [18:09] wow... [18:09] like MACROS? [18:10] Um, no. Something involving KVM and preseeding and stuff. [18:10] oh [18:10] that seems overkill for ubuntu studio [18:13] Why? [18:13] If it works, we can set up some number of test cases, and have a few folks run them. [18:13] is that what would get us all the installer questions up front? [18:14] That would exercise the installer, and we could focus human attention on things that require GUI interaction. [18:14] holstein, I believe it not only gets the questions, but answers them in a preprepared manner, and then verifies the results match expectations. [18:14] yeah, i like that direction if only for that reason [18:14] haaaaa [18:14] * persia attended a presentation about it once, but was mostly asleep at the time [18:15] unattended installation [18:15] i get it now [18:15] so, it is like a remote test, automated to run each release [18:15] and then ouputs a log [18:15] seems a good aproach... [18:16] persia: SORRY I DODNT GOT IT AT FIRST [18:16] It only tests the installer, mind you. Won't test the apps. [18:16] rlameiro, No worries :) [18:16] I oops caps [18:17] it only works with the alternate right? [18:17] As far as I know, yeah. [18:19] ok [18:19] well, i need to go for groceries, then time to work on studio things [18:19] video editing and wiki for test cases :D [18:20] * rlameiro AFK [19:18] persia, holstein, rlameiro : i don't mean that we use the latency test to validate each ISO image, just that as a release the kernel should probably be tested to make sure performance is acceptable [19:19] agreed [19:20] Indeed. [20:06] scott-work, persia, holstein http://testcases.qa.ubuntu.com/UbuntuStudio [20:06] paultag: also.. [20:06] Hum? [20:07] Ah, cool. Thanks. [20:07] rlameiro, Nice work. I'd recommend that for natty you align those to match the workflows ScottL has been asking folk to contribute though. [20:07] i was thinking about that [20:07] its a nice idea persia [20:08] i really need input in other areas that not audio.... [20:09] I think there's a huge opportunity for alignment in terms of testcases, documentation, and seed contents if we focus on the workflows. [20:42] persia: yeah, maybe choosing one workflow for each type of test, and make it like to finish a task [20:43] That was my thinking, yeah. [20:43] And if we have to adjust a test because software changes in a cycle, we can adjust the documentation at the same time, and always have it accurate for each release. [20:59] yea [20:59] like jack changes... [21:11] rlameiro: good stuff, i like it :) [22:47] paultag: i neglected to tell you welcome... [22:47] paultag: welcome :) [22:47]