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