[12:12] since we've sliced up the standard library in some interesting ways [12:12] we should have some way to confirm that the remaining modules actually work [12:12] there is one included, to check for the dependency stuff, which is run after the build. [12:12] (without full python installed) [12:12] Kamion: and it's in hoary{,.buildd}? [12:12] doko: what does it do? just import the modules? [12:13] I was thinking about some simple unit tests [12:13] doesn't python have unit tests? [12:13] Mithrandir: yes [12:13] import the modules and check that all dependencies are fulfilled. [12:13] doko: would it be feasible to adapt the existing unit tests for this purpose? [12:13] so that they use /usr/bin/python and /usr/lib/pythonX.Y rather than the ones in the build tree? [12:14] ok, I'll look to explicitely check the modules in -minimal and let the build fail on regressions. [12:14] lamont_r: not .buildd [12:14] ok [12:14] lamont_r: that's just waiting for your ack though [12:15] please [12:15] ok [12:15] otherwise the buildd installs it and then can't uninstall it afterwards. [12:15] amu: we need to sync up on live CD stuff; I'm going to start doing active development on it very soon [12:15] mdz: and to package the these tests in an own package? [12:15] Essential: yes --> in .buildd [12:15] doko: I don't think it's necessary [12:15] mdz: nice, soon means? [12:15] doko: if you can find a way to run the tests during the build, with an interpreter that can only access the -minimal modules, that would be fine [12:16] mdz: would be nice to have the build process as it currently sits running somewhere, if it's ready, otherwise just available for the rest of us to play too.... [12:16] amu: what time will you go to sleep tonight? ;-) [12:16] ok, I'll look at that. [12:16] mdz: *g* [12:16] lamont_r: ah, never thought of that. uploaded. [12:16] thanks [12:16] lamont_r: in order to get the real process going, we need to finish the debian-installer mods [12:17] amu has sent me some diffs, I looked at them today [12:17] lamont_r: the other piece is to arrange for automated builds of the desktop live image [12:17] lamont_r: I'd be thrilled if you would take responsibility for that piece [12:17] mdz: OK. what I guess I was saying is that I would like to play/fix it as well, although my schedule for the week is pretty busy now... [12:17] they don't seem very ready to integrate though; lots of temporary bits, and cdrom-live seems to be a literal copy of cdrom or close to it [12:17] Kamion: guess now with ubuntu13 they are totally outdated :) === lamont_r will own the automated piece - need to get the unautomated piece to get that set up though. [12:17] amu: try 20041227ubuntu1 ;) [12:17] lamont_r: basically, we need to do an automated nightly debootstrap + install desktop task, make a filesystem out of it, and compress it with the cloop utils [12:18] but no, not particularly, they just won't really be useful until you've uploaded the extra udebs that need to go in your initrd [12:18] that's quite simple... [12:18] lamont_r: that should be doable with no dependencies on anything that amu or I are doing [12:18] mdz: and then upload that .img? [12:18] Kamion: hehe, searched yesterday where ex. contychooset are :) lost in space [12:19] is this the image that doesn't rsync? [12:19] set/ser [12:19] elmo: yeppers [12:19] elmo: yes [12:19] so you guys need to decide where to put that [12:19] so there will be one piece built by d-i and processed in the usual way [12:19] mdz: what if we skipped the cloop utils compression, and did that at buld time. [12:19] as long as it's not releases.u.c, I don't suppose I care [12:19] and a second piece that is the output of lamont's process [12:19] then it could rsync better [12:19] the live CD build process will take as input the d-i bit, and lamont's bit, and put them together into an .iso [12:20] mdz: just to note, I feel relatively strongly that monolithic-live or similar shouldn't be the production thing [12:20] Kamion: meaning what, specifically? [12:20] I wasn't sure from what you guys were doing whether you were assuming you'd be using monolithic-live [12:20] the d-i initrd that includes all your udebs [12:20] rather than just enough to decide what to do and retrieve more udebs [12:20] Kamion: it doesn't much matter to me whether it's monolithic or not, but if there are issues with how we carve up the configs/ stuff, we need to know that now [12:20] i.e., whether we have a separate -live config, and at what point in the tree [12:21] the cdrom-live as I saw in amu's diff is fine IMO [12:21] ok, great [12:21] it just needs some content distinct from cdrom :) [12:21] ok [12:21] automated testing [12:22] we agreed on the scope for that in Mataro, but the notes don't seem to be up yet [12:22] has the INEEDROOTKTHXBYE misfeature been fixed yet? [12:22] [for live builds] [12:22] not in debootstrap, to my knowledge ... [12:22] elmo: will need debootstrap... [12:22] but can at least run in a chroot. [12:22] or xen, or whatever... [12:22] elmo: the CD building part and the d-i building part are both fine in that respect [12:22] elmo: lamont's bit which installs desktop will be tough to do without root [12:22] fakechroot might be worth a shot? === lamont_r makes a note to try fakeroot debootstrap for giggles [12:23] elmo: no more such a big problem, we're knoppix free now [12:23] pitti: are you comfortable with the scope and deadlines for automated testing? [12:23] lamont_r: it doesn't work.. i tried that... [12:23] fabbione: ok [12:23] mdz: I thought we should only do some example packages for Hoary? [12:24] pitti: we agreed to do automated install/remove for every package [12:24] mdz: find an appropriate framework and do a handful of representative examples? [12:24] lamont_r: fake_ch_root. [12:24] pitti: the per-package tests are a nice-to-have for hoary, but not required [12:24] mdz: yes, but that wasn't assigned to me? [12:24] pitti: was that the bit that Kamion accepted? [12:24] mdz: not sure [12:25] yes, it was [12:25] http://www.ubuntulinux.org/wiki/AutomatedTesting, last paragraph [12:25] ah [12:25] but Kamion probably needs some support for that... [12:25] mdz: I just never thought about this so far [12:25] Kamion: given that featurefreeze doesn't restrict automated testing development, do you think you want to take that on after all? [12:27] Kamion: let me know when you return [12:27] smurfix: are you still interested in the keyboard layout selector? [12:27] sure [12:27] Did you look at the stuff I sent you? [12:27] smurfix: I'm concerned about the feature freeze deadline vs. your hand injury; do you think you will be able to meet the schedule? [12:28] smurfix: only very briefly; I've been on holiday [12:28] My hand's mostly working right again [12:28] oh, good to hear [12:28] smurfix: if it is achievable for you, I am more than happy to make a deal [12:28] They took off the iron early. [12:28] I think so [12:29] let's discuss details after the meeting or via email [12:29] mdz: I may be able to help but I'd prefer not to lead it [12:29] mdz: , it's kindos late [12:29] thom: how do you feel about automated testing? [12:29] s/,/email, [12:29] smurfix: ok [12:29] elmo: also, what's your assessment as far as getting xen or whatever set up for this? [12:30] ah,m [12:30] elmo: if you don't think it can be done, we can use a chroot on a dedicated machine and get about 95% of the way [12:30] mdz: interested. [12:30] mdz: what's the deadline for xen? [12:30] and has anyone looked at it at all yet? [12:31] elmo: in order to get reasonable benefits from automated testing, it should be up and running as soon after feature freeze as possible [12:31] xen depends on doogie [12:31] this scares me :p [12:31] Keybuk: like hell it does [12:31] keybuk?! [12:31] isn't that his current shiny toy? [12:31] Keybuk: he's not upstream [12:31] Keybuk: he likes to drool on it; that hardly makes it dependent on him [12:31] I think he's moved on [12:31] ahh, could be, has been a few weeks [12:31] err, public meeting. must. control. cyclone. [12:32] lol [12:32] mdz: err, feature freeze is when? sorry, lost track, the dates keep being changed or talk about changing [12:32] elmo: cyclones fine, just keep the waves to yourself. [12:32] thom: I'm happy for you to own that piece of it (installation/removal testing), and work with pitti on the package-specific test portion [12:32] elmo: 2005-02-09, I think [12:33] yes [12:33] oh, yeah, I can do Xen by then [12:33] that's soo close to my wedding... [12:33] jdub: I don't know why you're worried about going to jail over MP3 players, you're clearly going to hell :p [12:33] Keybuk: weve known that for a long time [12:33] mdz: ack. [12:33] fabbione: most of your feature work is done [12:33] thom: ok, thanks [12:34] mdz: i am more worried of last minute mess [12:34] thom: the bridal party has a CHILDREN'S TABLE. beware. [12:34] fabbione: we save that for the release [12:34] jdub: what's the latest on the gdm/panel bounties? [12:34] mdz: ok :-) thanks ;) [12:35] mdz: see way above for panel, part of gdm is done, but mark extended it somewhat at mataro :) [12:35] jdub: please update the wiki with status info [12:35] mdz: ok [12:35] thom: netapplet? [12:36] hrm, didn't we want resolvconf? [12:36] artwork done, know how to do the appletification, was planning to do it tomorrow am [12:36] thom: i have menu suggestions to send too [12:36] thom, jdub: at what point shall we add it to desktop? [12:36] jdub: context for resolvconf? [12:36] has the meeting ajorned? [12:36] sivang: not hardly === doko_ [doko@dsl-082-082-189-011.arcor-ip.net] has joined #ubuntu-meeting [12:37] thom: also, davyd knows how to do applet replacement foo [12:37] jdub: lay on, macduff [12:37] mdz: k [12:37] jdub: AHR! [12:37] thom: (are we going to replace the wifi applet?) [12:37] jdub: any word on icons? [12:37] thom: i'm a little bit uncomfortable with that, because it's not happening upstream [12:37] mdz: icons way up too [12:38] mdz: context for resolvconf is realising it's not installed on my laptop [12:38] jdub: i think it makes a lot of sense to, but it needs discussion - having two wifi strength indicators is SUCKADELIC [12:38] jdub: icons are on Mark's high priority list; we need to see something relatively soon if it's going to happen [12:38] I don't think this can wait until preview timeframe at all [12:38] it already fell through for Warty [12:39] thom: mmm, and if we replace the wifi applet's guid, it jsut means taht logging in on other systems will give you the old applet [12:39] mdz: not wait until, but it still be updated through then [12:39] can still [12:39] jdub: sure, so long as it's well underway [12:39] yeah [12:39] so hammering that out this and next week [12:39] i.e., we have the guy, and have known good stuff in hand [12:39] thanks [12:40] we still have this handwavy goal of making video playback better [12:40] jdub: um. can we talk more thoroughly about this with davyd, see if he has smart ideas about how we do it? (ie, not right now) [12:40] all gstreamer plugins in main? *duck* :p [12:40] ffmpeg in main ! [12:40] let's put mplayer with codecs in main... === seb128 hides [12:40] it was less handwavy when we decided it should be "totem should be able to handle flumotion streams, vorbis and theora, etc." [12:40] the two concrete things there were the new gstreamer bits from upstream, and getting gst-ffmpeg into multiverse [12:41] thom: yeah, he does [12:41] jdub: totem can already play those, it just doesn't do it as well as we'd like [12:41] mdz: the goal was to do them well [12:41] I thought someone stepped forward to make gst-ffmpeg happen during Mataro [12:41] mdz: ffmpeg was just an additional bonus [12:41] yes, it should be in debian soon [12:41] I'm working with the debian maintainer to get it uploaded [12:41] elmo: ...? :) [12:41] should happen RSN [12:41] rock [12:41] ok, great [12:42] jdub: I constantly forget what this SVG stuff is about [12:42] jdub: but you and Mark have a dialog about it, right? [12:42] mdz: very random handwavy stuff. "make things prettier", basically. hardly anything to do with svg. [12:42] oh, crap! [12:42] mdz: yeah [12:42] jdub: any concrete goals? [12:42] not really [12:42] sweet [12:43] but it's related to the gdm stuff [12:43] so i can pick off a few tasty nibbles and satisfy it [12:43] it was the gdm-not-stretch-and-fuck-up-the-login-screen thingy, wasn't it? [12:43] usplash, sladen and I are working that out [12:43] we need to seed readahead, btw [12:43] Mithrandir: no, that's a gdm goal ;) [12:43] thom: is that all we need to do? [12:43] thom: how does it decide what to read ahead? [12:44] at the moment, the list is generated manually and shipped in the package [12:44] elmo: hmm? [12:44] thom: btw... i have a patch to improve kernel read-ahead... [12:44] fabbione: oh? [12:45] Kamion: just forgot to do some new processing I said I would in mataro [12:45] thom: if you want to get some stats, i can push you the same kernel with the patch and see if it helps [12:45] mdz: automatic updates need a lot more thought at this point [12:45] thom: was it a conscious decision to have it ahead of mountnfs.sh in the boot sequence? it would seem to disable itself for /usr-on-NFS [12:45] thom: kernel does some read_ahead on its own... [12:45] thom: yeah, don't worry about automatic updates for hoary, certainly [12:46] mdz: how much work does usplash need to get a beta uploaded? [12:46] elmo: Pity, I was going to remind you tomorrow. ;-) (Please also do python2.4-docutils so that it may migrate to Ubuntu.) [12:46] we should get usplash in quickly === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-meeting [12:47] mdz: readahead doesn't work with NFS, and hotplug is ahead of it, so it seemed like a pretty harmless win... [12:47] Keybuk: not too much, I don't think; we're going with a fairly conservative goal for hoary. sladen will have specifics [12:47] thom: ok [12:47] any objections to seeding readahead? [12:47] (desktop, presumably) [12:47] none [12:47] desktop, definitely [12:47] go ahead. [12:47] thom: go for it [12:47] ok, added to my list [12:48] kamion already updated us on questions-before-reboot work [12:48] mdz: it'd be nice to see some shiny packaged [12:48] that will score a few score more testers ;) [12:48] Kamion: DVD images? [12:48] mdz: in slightly more detail, the timezone question is (just about) done, password and apt-setup stuff still to go [12:48] no progress on those since Mataro [12:49] mdz: adding what features to make them need a dvd? [12:49] lamont_r: DVD images = producing DVD [12:49] DVD-sized images with supported on them === ogra [~ogra@p508EA1D6.dip.t-dialin.net] has joined #ubuntu-meeting [12:50] Kamion: being server-side, that one has some flexibility as far as the feature freeze as well, but I very much want to see it happen for hoary [12:50] Kamion: is this something that could be handed off to lamont, perhaps? [12:50] yeah, I know, I have no intention of deferring forever [12:52] mmm, bit tricky at the moment, will see [12:52] ok, follow up with him if it makes sense to divide it somehow [12:52] I don't see a need to go over all of the targets of opportunity; if there's anything that folks want to talk about from that section, please raise it [12:52] we should have a webmail thingy in main [12:52] I'd like to hear from someone on the doc team about the documentation goals [12:52] *cough* sorry [12:52] laptopsuspend? [12:52] mdz: Is it worth bringing up the suspend/resume thing briefly? [12:52] oh, there are still pieces of apt authentication to do [12:52] mjg59: sure [12:52] mdz: Now? :) [12:53] mjg59: if you'd prefer to summarize on the list later, that's fine, but here and now is also fine [12:53] Kamion: what exactly? can I help? [12:53] we're nearing the 2 hour mark, and experience shows that we fade fast :-) [12:54] cdimage signing and verification [12:54] I've just sent the cdimage public key to the keyservers [12:54] Concentrating on x86: [12:54] Suspend to disk should work just about everywhere. [12:54] is there anyone (else) from the doc team here? [12:54] So that's a win. [12:54] johnlevin: I am === Keybuk starts weeping during this bit :p (not to mention giving the X40 cabal a target) [12:54] mjg59: what shall we do about default event stuff for hoary? [12:54] now that this stuff works and all, it would be great to actually have some interface to it :-) [12:54] mjg59: and resume? :-) [12:54] Suspend to RAM is going to work on an unknown number of machines - based on personal experience I'd tend towards ~80%, but it's possible the machines I've tested have been better quality than average [12:54] sivang: what do you knwo of the doc goals for hoary? [12:54] mjg59: we should try see why it doesn't work on the inspiron 8200 with nVidia. :-) [12:54] sivang: If you're using nvidia's drivers, you have no chance [12:55] Oh, yeah. StR with binary X drivers = not happening [12:55] the nvidia binary driver is not acpi-aware [12:55] or any pm-aware, iirc [12:55] daniels: is that all that's needed? [12:55] mjg59, jdub, seb128: is it possible to get a 'hibernate' thing into the menu, logout dialog or someplace appropriatae like that? [12:55] Making suspend to disk available by default is reasonable [12:55] johnlevin: hmm, mostly there is now a quick guide (refcard) , the big handbook, man pages reworking, Install manual love and gnome docs love. [12:56] mdz: that would be cool. [12:56] I'd lean towards having StR there, but disabled by default [12:56] mdz: yes, that's trivial to do, just give me the command to run [12:56] The real issue is that we need a configuration layer [12:56] seb128: great, and it will be run as root? [12:56] mjg59: noted. Will test with the free driver in in 30 miins. [12:56] All the code is in shell, so it's easy enough to just source from a config file [12:56] mdz: probably like the reboot/halt stuff, with gdmflexiserver [12:57] seb128: great [12:57] can we pretty please apply the apple patch before release? [12:57] Ah, good point. Yeah, we should apply the PPC suspend to disk patch (along with the G4 iBook suspend to RAM stuff) [12:57] I have no access to PPC hardware, so someone else is going to have to test this stuff [12:57] going through a Bugzilla ACPI patch harvest would be quite handy [12:57] ppc supsed to disk? [12:57] elmo: Yeah [12:58] the suspend to ram patch isn't just for ibooks, it's for any G4 mac laptops [12:58] mjg59: can you send seb128 what he needs in order to add a hibernate action? [12:58] and I think it clashes with suspend to disk patches [12:58] ibooks and albooks, not sure about tibooks [12:58] and I test it every day :) [12:58] mjg59: or is it just echo disk > /sys/power/state ? [12:58] elmo: Ah, rock [12:58] it's working great for me too [12:58] mdz: No, it needs to run a script [12:58] mjg59: hibernate options doesn't need a partiton to hibernate to prior to actually trying that? [12:58] doesn't acpi-support need to go into the archive first? [12:58] sivang: It just needs swap [12:58] sivang: it uses swap === lamont_r wants to get suspend-to-anything working [12:59] Oh, yes [12:59] mjg59: oh, what about getting resume= automagically set up? [12:59] The installer needs to add resume= to the default kernel paramaters [12:59] mjg59: ok, cool, does this automagically? (i.e. detect swap partition) [12:59] elmo: i doubt we will apply it [12:59] sivang: No, it needs a kernel paramater [12:59] elmo: it is big and buggy.. according to benh there is at least one known regression [12:59] mjg59: what happens if there are multiple swap partitions? [12:59] Uh, eter [12:59] mjg59: ok, I'll talk to you after the meeting. [12:59] fabbione: uh, what regression? [12:59] mdz: It'll use whichever one resume= points to [12:59] mjg59: it seems more sensible to have initrd-tools save the necessary info in the initrd [12:59] suspend-to-disk would work for me if X.org wouldn't crap itself and hang the machine [01:00] elmo: ati hangs on resume in some cases [01:00] it's not that buggy dude, I've been using it since version #1 and never had a crash [01:00] mjg59: resume= seems like a very awkward way to do it [01:00] fabbione: dude, how can that possibly be a regression? it didn't resume AT ALL before [01:00] mdz: Hrm. It /could/ be done that way. [01:00] elmo: benh consider it a regression because it touches the ati driver for all arches... [01:00] Need some rewriting. Open a bug on it and we'll discuss it? [01:00] mjg59: does the kernel API already support telling it where to resume from (directly, rather than resume=?) [01:00] meh, conditionally apply it then :P [01:00] mjg59: ok, will do [01:01] mdz: we forget crypto? [01:01] mdz: Yeah, with my patch in there [01:01] that patch is a SERIOUS usability thing for mac laptops [01:01] elmo: i tought about it.. yes... that means a lot of extra work to maintain ppc kernels.... [01:01] that one patch, and you have a suspendable laptop, no fucking around with ACPI, VBE, vm86 or any of that crap, it just works. [01:01] How about we open separate bugs for the right way of dealing with resume=, user configuration, gdm integration and Mac support? [01:01] amu: there are a lot of targets of opportunity, and we are out of time [01:01] amu: if there is something specific you'd like to talk about, please raise it now [01:01] but i guess that there is no otherway around since i will have to do it for hppa too [01:01] otherwise, I'd like to close the meeting soon [01:02] does everyone know what their deliverables are from this meeting? [01:02] mdz: if not, I'll need to take about a 10 minute break... [01:02] mdz: well there was a voice it would be nice if we can crypt our homedir's ... [01:02] mdz: I don't think that's a valid question... [01:02] who's using the xen stuff I'm doing? thom &| lamont ? [01:02] since we _think_ we know them... [01:02] heh [01:02] elmo: thom, pitti, lamont [01:03] here [01:03] k [01:03] elmo: is xen somekind of kernel related module? [01:03] lamont_r: that was a subtle way of saying "you're supposed to write these things down when you agree to do them" :-P [01:03] mdz: I'm not using xen, if you meant that [01:03] pitti: for automated testing [01:03] mdz: right. [01:03] ah, that one [01:03] fabbione: it's like uml and vmware, but on crack. good crack [01:03] um, so with unified x configuration [01:04] it needs some kernel patches, because atm, it's maintained as a sepearate architecture [01:04] fabbione: it is a kernel arch [01:04] elmo: how much confidence do you have on it? [01:04] I'll get to that one next week [01:04] http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ [01:04] fabbione: I don't think we need to merge it into the standard kernel for hoary [01:04] fabbione: none - I've not used it before [01:04] mdz: ssshhuuuuusss! [01:04] fabbione: we decided to use it in mataro, and I only had my ppc laptop, which it doesn't support [01:04] daniels: that's fine; with luck, we'll be ready for it then [01:04] i was trying to give hte kernel to elmo! [01:04] :P [01:04] FWIW, I agree with mdz, it doesn't need merged [01:04] mdz: sweet [01:04] elmo: ok... [01:04] elmo likes to build his own kernels anyway [01:05] fabbione: haha, like that'll ever work [01:05] mdz: it's my constituional right, damn you [01:05] the elmo amendment [01:05] elmo: you may never know.... [01:05] elmo doesn't even use hotplug or udev [01:05] perhaps you love me so much that you will take care of the kernel while i will be in honeymoon... [01:05] i thought he did now [01:05] anything else before I translocate? [01:06] so at this point, everyone should know what their feature goal assignments are [01:06] critical pieces of infrastructure are not maintained via the 'you touched it last' mechanism [01:06] almost all of them have a deadline of FeatureFreeze [01:06] which is 2005-02-09 [01:06] so feature work is the top priority during that time [01:06] mdz: I have one extra point, if you don't kill me [01:06] things on the primary goal list are "must haves" [01:07] so if you encounter any problems which place them in jeopardy, notify me immediately [01:07] likewise for secondary goals, which are not "must haves", but very important [01:07] pitti: go ahead [01:07] mdz: back in warty time we discussed about the drive icons on the desktop/panel; this is still not sorted out AFAIK [01:07]