=== lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-meeting
=== asubedi [~asubedi@pcp04534808pcs.oakrdg01.tn.comcast.net] has joined #ubuntu-meeting
=== asubedi [~asubedi@pcp04534808pcs.oakrdg01.tn.comcast.net] has left #ubuntu-meeting ["Leaving"]
=== tseng [~tseng@thegrebs.com] has joined #ubuntu-meeting
=== mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting
=== ..[topic/#ubuntu-meeting:mdz] : Hoary kickoff meeting: Monday, 2004-10-25, 1600UTC
=== ficusplanet [~ficusplan@12-216-226-172.client.mchsi.com] has joined #ubuntu-meeting
=== pitti [~martin@195.227.105.180] has joined #ubuntu-meeting
=== Gmail [~Google@gnu-debian.user] has joined #ubuntu-meeting
=== Gmail [~Google@gnu-debian.user] has left #ubuntu-meeting ["Leaving"]
=== Pizbit [~Pizbit@203-79-124-44.adsl.paradise.net.nz] has joined #ubuntu-meeting
=== daniels [daniel@fooishbar.org] has joined #ubuntu-meeting
=== cc [~byte@byte.fedora] has joined #ubuntu-meeting
=== mvo_ [~egon@suprimo-131.ping.de] has joined #ubuntu-meeting
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== Gmail [~Google@gnu-debian.user] has joined #ubuntu-meeting
=== Sensebend [~steve@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-meeting
=== Gmail [~Google@gnu-debian.user] has left #ubuntu-meeting ["Leaving"]
=== HauntedUnix [~hauntedun@HauntedUnix.student.supporter.pdpc] has joined #ubuntu-meeting
03:07	HauntedUnix	Morning
=== Mitario [~michiel@62.58.176.206] has joined #ubuntu-meeting
=== sivang [~dannyh@80.179.93.130.forward.012.net.il] has joined #ubuntu-meeting
=== pitti [~martin@195.227.105.180] has joined #ubuntu-meeting
=== mvo_ [~egon@suprimo-131.ping.de] has joined #ubuntu-meeting
=== ploum [~ploum@21-4.CampusNet.ucl.ac.be] has joined #ubuntu-meeting
04:19	sivang	can someone put the agenda link on the channel's topic?
=== ..[topic/#ubuntu-meeting:bob2] : Hoary kickoff meeting: Monday, 2004-10-25, 1600UTC || Agenda: http://www.ubuntulinux.org/wiki/HoaryKickoffMeeting
=== gruberman [~gruberman@h9n2fls35o294.telia.com] has joined #ubuntu-meeting
=== fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting
=== sivang [~dannyh@80.179.93.130.forward.012.net.il] has joined #ubuntu-meeting
=== vuntz [~vuntz@fennas.vuntz.net] has joined #ubuntu-meeting
=== enrico [~enrico@81-174-12-206.f5.ngi.it] has joined #ubuntu-meeting
=== Pizbit [~Pizbit@203-79-124-44.adsl.paradise.net.nz] has joined #ubuntu-meeting
=== plovs [~plovs@62.84.21.44] has joined #ubuntu-meeting
05:09	ploum	I put already a link about my opinion
05:09	ploum	http://ploum.frimouvy.org/?2004/10/25/6-i-dont-want-people-to-use-gnome-applications-anymore
=== doko [doko@dsl-084-057-024-165.arcor-ip.net] has joined #ubuntu-meeting
=== Keybuk [scott@descent.netsplit.com] has joined #ubuntu-meeting
05:29	doko	I know I am late ... are people already busy working? so quiet ...
05:29	Keybuk	half an hour early
05:30	doko	ahh still summertime in the UK?
05:31	Keybuk	meeting time is UTC, not BST/GMT
05:31	Keybuk	we're UTC+0100 at the moment
=== Mitario [~michiel@sikkes.xs4all.nl] has joined #ubuntu-meeting
05:38	lamont	doko: so you're early. :-)
05:38	doko	lamont: at least that can't be wrong ;)
05:39	lamont	yeah
=== tvon [~tvon@h-66-167-145-240.mclnva23.dynamic.covad.net] has joined #ubuntu-meeting
=== jdub [~jdub@home.waugh.id.au] has joined #ubuntu-meeting
=== johnlevin [~johnl@dsl-80-42-84-143.access.uk.tiscali.com] has joined #ubuntu-meeting
=== minghua [~minghua@danube.mems.rice.edu] has joined #ubuntu-meeting
=== bowes [~bowes@blk-215-69-91.eastlink.ca] has joined #ubuntu-meeting
=== seb128 [~seb128@ANancy-151-1-8-118.w83-194.abo.wanadoo.fr] has joined #ubuntu-meeting
05:55	sivang	doko : early enough :)
05:55	mdz	jdub: are you here for the duration?  thanks for staying up
05:56	jdub	probably
05:56	jdub	i'm hammered
05:56	jdub	got up at 4am
05:56	daniels	ouch
05:56	daniels	you're turning into fabio :\
05:56	fabbione	tsk :P
05:56	sivang	hey lamont
05:56	fabbione	he should be honoured of that ;)
05:57	sivang	fabboine : still insomnic ?
05:57	thom	fabbione: the word in english is "suicidal" ;-)
05:57	daniels	or terrified, either way
05:57	mdz	jdub: had a nap along the way, I hope
05:57	bob2	daniels: think how much fun you'll have over there!
05:58	jdub	mdz: no
05:58	bob2	"little daniel, it's 4am, let's hack x.org!"
=== tioui [~arthur@AReims-151-2-2-234.w83-192.abo.wanadoo.fr] has joined #ubuntu-meeting
=== jdub goes to have a sprite recharge
05:58	mdz	...daniels awakes as a bucket of ice water is emptied over his head
05:59	Keybuk	right, better get tea
=== daniels calls ahead to the hotel and sends instructions that no visitors will be allowed.
05:59	daniels	mdz: 4am is generally when I go to sleep these days
06:00	mdz	ok
06:00	mdz	called to order, etc.
06:00	mdz	is everyone here who ought to be?
06:00	lamont	morning sivang
06:01	sivang	lamont : good evening, it's 18:00pm here ;-)
=== Kamion waves
=== enrico says hi
06:01	mdz	me waits a moment for stragglers to arrive
=== sivang sticks his head up
=== sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting
06:01	sabdfl	hi all
06:01	pitti	Hi fearless sabdfl!
06:02	sivang	Hi fearless leader! :)
06:02	sabdfl	hey all, mdz will be chairing this one
06:02	seb128	evening sabdfl
06:02	mdz	ok, we have a ton of ground to cover, so let's get started
06:02	doko	evening all
06:02	tseng	'lo
06:02	mvo_	hi
06:02	mdz	fisrt agenda item is to review the release schedule, and probably make some adjustments. jdub, are you back with Sprite?
06:03	mdz	I believe the schedule requires updating to reflect changes to the GNOME 2.10 schedule
06:04	mdz	ok, let's skip ahead to the merge process for now
06:04	Kamion	and we need to fiddle the CD milestone dates
06:04	jdub	it does
06:04	mdz	ok, let's not :-)
=== LeeColleton [~lc@dsl231-061-247.sea1.dsl.speakeasy.net] has joined #ubuntu-meeting
06:04	Keybuk	who wants some cute stats about warty?
06:04	mdz	jdub: any changes which we should talk about here?
06:04	jdub	http://www.gnome.org/start/2.9/
06:04	jdub	mdz: not significant enough, no
06:04	jdub	^ that's the gnome schedule, for the record
06:04	jdub	ours just needs tweaking
06:05	daniels	fwiw, the proposed gnome schedule: http://www.gnome.org/start/2.9/
06:05	Keybuk	jdub: by how much?
06:05	jdub	days
06:05	mdz	Kamion: I'm happy for you to tweak the CD milestone dates as you feel is appropriate; you might want to wait for jdub's changes though
06:05	Kamion	mdz: not in a hurry, just flaggint it
06:05	Kamion	flagging
06:05	mdz	ok, nothing major in that department, then; we can move on
06:05	mdz	to THE MERGE
=== rburton [~ross@84.12.22.159] has joined #ubuntu-meeting
=== fabbione runs away screaming
06:05	mdz	elmo: what's the status of the sync infrastructure?
=== Gmail [~Google@gnu-debian.user] has joined #ubuntu-meeting
06:06	mdz	...creepy organ music plays...
06:06	elmo	mdz: mostly ready - I need two things before I can go:
06:06	elmo	a) proper seed lists for hoary
06:06	elmo	b) a decision on what, if anything, we're doing about indices files for hoary?
06:06	Gmail	am i allowed to say a few comments?
06:07	daniels	Gmail: we are talking about the huge merge with sid.  if it is appropriate and on-topic, yes.
06:07	ploum	March 9th: 2.10.0 release! (wow, my birthday :-) )
06:07	mdz	Gmail: yes, this is a public meeting, but please try to stay on topic, we have a great deal to discuss
06:07	Kamion	Gmail: we're on an agenda here, let's stick to it and have any other business at the end.
06:07	mdz	elmo: what sort of indices?
06:07	elmo	mdz: Packages/Sources, etc.  there was talk of pw-protecting and/or hiding them at one stage
06:07	mdz	elmo: until we have the initial merge sorted out?
06:08	jdub	elmo: that was about crack-o-the-day, not hoary
06:08	mdz	there may be something to be said for that
06:08	elmo	jdub: no, it really was  hoary at one stage.
06:08	lamont	elmo: I thought that applied more to grumpy start (at hoary freeze...)
06:08	mdz	we really don't know how bad the breakage will be, though
=== hornbeck [~hornbeck@adsl-69-153-250-222.dsl.okcyok.swbell.net] has joined #ubuntu-meeting
06:08	jdub	elmo: it was about hoary while warty was still in devel
06:09	mdz	the only compelling justification is so that people don't dive into it when it's known to be severely broken
06:09	sabdfl	basic question, do we think people will expect hoary to be sane-if-there?
06:09	mdz	which I think it very well could be at the very beginning
06:09	Kamion	sabdfl: we've been telling people not to, but I'm sure they will
06:09	mdz	sabdfl: perhaps not sane, but installable and not breaking their desktop
06:09	fabbione	sabdfl: mostlikely
06:09	daniels	sabdfl: you can s/warty/hoary/ now, and apt-get update won't error our
06:09	mdz	those who have been warned deserve what they get, but there will be others who have not been warned
06:09	elmo	daniels: eh, you'll screw your system
06:09	sabdfl	but there's nothing in their system telling them to s/warty/hoary/
=== ogra [~ogra@p508EA4D2.dip.t-dialin.net] has joined #ubuntu-meeting
06:10	sabdfl	it will take longer to get through the pain of merging if we try to keep hoary sane at all times
06:10	mdz	elmo: regarding the seed lists, let's use the Warty seed lists; we can update them later
06:10	mdz	elmo: we'll need to have a review of the proposed seed changes, and I expect we won't get to it during this meeting
06:10	elmo	mdz: ok
06:10	Kamion	mdz: are we going to duplicate them in the wiki, or do I not need to change Germinate yet?
06:10	Gmail	ok as i goto sleep here are a few ideas: you know you new usplash thing add to it that alt+flock's F1 == alt+F1 it get really anoying on crappy key baords that have f-lock off by default
06:10	fabbione	elmo, mdz: please kill anything X related in the seeds, we don't want to merge xfree86 from sid
06:11	elmo	fabbione: we won't merge it - it's ubuntu modified
06:11	sabdfl	gmail: msg me oob and i'll raise them at the end
06:11	mdz	Kamion, elmo: let's continue to use germinate pointing to the Warty seeds
=== inklingx [~inklingx@u212-239-167-206.adsl.pi.be] has joined #ubuntu-meeting
06:11	fabbione	elmo: perfect
=== stvn [~steven@82.197.192.33] has joined #ubuntu-meeting
06:11	mdz	so what elmo and I discussed was that his tool would automatically import unmodified packages
06:12	mdz	and for modified packages (those with an ubuntu version number), send out a notification
06:12	mdz	probably a simple email to start
06:12	Keybuk	notification to whom?
06:12	mdz	a mailing list seems appropriate
=== Treenaks [martijn@facecrime.net] has joined #ubuntu-meeting
06:12	doko	notification of what? resync, or keep it?
06:12	mdz	doko: a notification of the fact that it needs review
06:12	lamont	and then we either merge, or sync new-debian
06:12	Keybuk	http://people.ubuntu.com/~scott/patches/warty/
06:12	elmo	mdz and I discussed including the changelog from the debian version, to aid in prioritzation
06:13	mdz	then someone will read the changelog, determine if there are changes which have not been merged upstream, and either request a sync of the Debian version (if none), or do a manual merge (if so)
06:13	fabbione	wouldn't be better to track it in bugzilla?
06:13	Keybuk	^ that's the set of patches made to warty since Debian-freeze
06:13	Keybuk	http://people.ubuntu.com/~scott/patches/debian/
06:13	mdz	elmo: yes, that would be great
06:13	fabbione	so we are sure of what is done or not?
06:13	Keybuk	^ that's the changes to those packages in Debian since the freeze
06:13	lamont	elmo: sweet
06:13	mdz	fabbione: we discussed it briefly, it is a possibility
06:13	Keybuk	http://people.ubuntu.com/~scott/output/
06:13	mdz	I am concerned about generating a huge number of bugs that way
06:13	Keybuk	^ result of merging the two together, with a bunch of rejects to review
06:13	Kamion	fabbione: bugzilla feels extraordinarily heavyweight for this, to me
06:13	mdz	but we have the tools to do it
06:14	fabbione	Kamion: i think it's easier since you go, pickup, kill and so on...
06:14	mdz	bugzilla does have the advantage of making it easy to track assignments, so we know if something is being done or not
06:14	fabbione	Kamion: otherwise we might lose track of the list
06:14	elmo	we're talking about 248 bugs
06:14	elmo	just for main
06:14	pitti	mdz: and we could also sort out the "who does what" easily in bz
06:14	mdz	elmo: let's create bugs automatically for the initial batch at least
06:15	elmo	*shrug* k
06:15	mdz	we'll need to figure out what to do for the ongoing merges, based on that experience
06:15	sabdfl	could equally well be a single wiki page
06:15	pitti	sabdfl: where everybody marks the packages he will merge?
06:15	pitti	would work, too; maybe easier than bz
06:15	elmo	what do we want to do about universe?  the majority of those changes were "make it build" fixes that should be irrelevant - I'm semi-tempted to overwrite, but that may just be me
06:16	daniels	doing X could be really interesting -- personally, I'd really like a lock on the repository for 48h to just do X stuff and deal with the fallout, if any.
06:16	mdz	let's start with bugzilla, and if it becomes cumbersome, we can switch to something else
06:16	mdz	elmo: let's ignore universe for now
=== amu [~amu@195.71.9.198] has joined #ubuntu-meeting
06:16	elmo	mdz: err.. mmk
06:16	elmo	not even sync the unmodified stuff?
06:16	mdz	hmm
06:16	mdz	sure, why not
06:16	fabbione	daniels: no need to. we will use chroots for that
06:16	fabbione	daniels: let's discuss it tomorrow
06:16	mdz	but we don't want bugs or notifications about the rest of it until we've finished with the initial work for main
=== manuel_ [~manuel@deri-wg1.nuigalway.ie] has joined #ubuntu-meeting
=== darkersatanic [~hugo@mina.ecs.soton.ac.uk] has joined #ubuntu-meeting
06:17	elmo	ok
06:17	mdz	elmo: what about accessing the morgue?
=== silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting
=== Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has joined #ubuntu-meeting
06:17	elmo	mdz: what do you think Scott's been doing?
06:17	sabdfl	re universe, are there any changes other than "make it build" changes?
=== manuel_ [~manuel@deri-wg1.nuigalway.ie] has left #ubuntu-meeting ["Verlassend"]
06:17	sabdfl	if not, let's just throw open the doors
06:17	mdz	elmo: no idea
06:17	Keybuk	elmo: I'm convinced he has me on ignore these days <g>
06:17	jdub	sabdfl: some resyncs
06:17	doko	elmo: can you publish a list of changed packages in universe?
06:17	mdz	sabdfl: yes, we've done things like the libtiff transition
06:17	elmo	mdz: anyway, it's on rookery, I can make it via http, if you want
06:17	jdub	sabdfl: libtiff-- yeah
06:18	pitti	sabdfl: I added some RC bug fixes regarding file conflicts
06:18	mdz	elmo: what I expect we want for the merge tool is a Sources.gz
06:18	sabdfl	did the libtiff stuff not get take upstream?
06:18	mdz	elmo: or a bunch of them
06:18	pitti	sabdfl: not all of them are already fixed in sid
06:18	sabdfl	ok
06:18	Keybuk	mdz: what would this merge tool do?
06:18	mdz	Keybuk: :-)
06:18	mdz	Keybuk: a lower form of magic
06:18	elmo	mdz: sure, can create a sources.gz
06:18	mdz	just a simple 3-way merge from 1.0-1, 1.0-1ubuntu3 and 1.0-2
06:18	Kamion	pitti: I thought almost everything did, it was blocking britney for ages and isn't any more
06:18	elmo	might take a day or two, but ;P
06:18	sabdfl	if libtiff was a lamont-automated-patch then we can recreate it quickly enough
06:18	Keybuk	mdz: ah, yes.  you get http://people.ubuntu.com/~scott/output/ when you do that
06:19	mdz	libtiff was
06:19	Keybuk	did that over the weekend because I was bored
06:19	jdub	sabdfl: (yeah)
06:19	mdz	Keybuk: is that from hct?
06:19	Keybuk	mdz: no, just low-level magic
06:19	jdub	i think sync-and-overwrite in universe is fairly sane
06:19	doko	keybuk: hmm, that output is useful for new upstream versions as well?
06:19	Keybuk	tla was taking too long
06:19	mdz	Keybuk: it has lots of lovely rejects
=== wulfy [~lorentz@2.wsvw1.xdsl.nauticom.net] has joined #ubuntu-meeting
06:19	mdz	Keybuk: what are the numbers like?
06:20	Keybuk	mdz: 10,704 "rejects"
06:20	Keybuk	around 7,000 of those with same changes on each side
06:20	Keybuk	3,596 left as different changes to both sides
06:20	mdz	Keybuk: that's number-of-hunks or number-of-files?
06:20	Keybuk	some 2,500 of those in .po files and debian/changelog or debian/control
06:20	Keybuk	mdz: number-of-files
06:20	lamont	Keybuk: sounds like you need to autodetect same-changes case, eh?
06:21	sabdfl	Keybuk: any magic you can bring to the next two weeks will make you friends for life :-)
06:21	Keybuk	warty has some 295,004 hunks
06:21	sabdfl	we can drop po
=== vrln [~vrln@195.10.181.201] has joined #ubuntu-meeting
06:21	Kamion	sabdfl: uh, I think that's a really bad idea for d-i
06:21	sabdfl	Kamion: true
06:21	Keybuk	42,680 patched files ... 1,320 patches in 387 packages
06:21	daniels	Keybuk: (you can safely exclude xfree86 from that list of number of hunks)
06:21	Kamion	sabdfl: we put enormous amounts of effort into the .po branding
06:22	sabdfl	right
06:22	doko	sabdfl: but not for all of the installer packages (s/Debian/Ubuntu).
=== Peltoilves [~peltis@tolu.edu.hel.fi] has joined #ubuntu-meeting
06:22	sabdfl	right again
06:22	Keybuk	yes, I'd like daf to teach us how we merge changes between .po files
06:22	Keybuk	because whoeever designed that file format is getting a beating if I ever meet them
06:22	doko	use Rosetta?
06:22	sabdfl	rosetta gets you faster community translations
06:23	sabdfl	but wn't help maintain an effective long-lived branch
=== helix [~helix@helix.user] has joined #ubuntu-meeting
06:23	Keybuk	Kamion's hunch was right ... it actually is easier to apply the debian changes to warty than try to go back and apply warty's changes to debian
06:23	sabdfl	real solution is to parameterise the branding
=== Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has left #ubuntu-meeting ["Leaving"]
06:23	doko	hmm, I didn't send kamion the script I used for merging the translations ...
06:23	Kamion	sabdfl: I spent quite a lot of thought on it and TBH I'm not very convinced that it's possible
06:23	sabdfl	parameterisation?
06:24	Kamion	at least, not without FAR greater gettext-fu than I possess or have so far seen
06:24	Kamion	right
06:24	sabdfl	i'll knock on daf's door
06:24	daf	Keybuk: what sort of merge? simple join of two PO files, three-way merge between translators or three-way merge with message ID and translator changes or or something else?
06:24	sabdfl	better than def's door
06:24	Keybuk	daf: three-way merge.  you have original .po and two sets of patches to it
06:24	mdz	daf: in  this case it's a 3-way merge with both message ID and translations changed :-)
06:25	Keybuk	Kamion: I actually don't see any po/ failures in debian-installer
06:25	Kamion	there will be a number of cases where we just have to re-brand, there's no choice
06:25	Keybuk	I think it was happy with most of them :o)
06:25	Kamion	Keybuk: debian-installer is just the build system.
06:25	Keybuk	oh :'(
06:25	Kamion	Keybuk: it doesn't HAVE any .po files :-)
06:25	Keybuk	bah
06:25	fabbione	lol
06:25	Keybuk	I broke apart all the patches as well
06:25	mdz	Keybuk: so how much of this can we realistically automate?
06:25	Keybuk	http://people.ubuntu.com/~scott/patches/warty/
=== darkersatanic [~hugo@mina.ecs.soton.ac.uk] has left #ubuntu-meeting ["Client]
06:26	Keybuk	that's each "change" to warty
06:26	mdz	if we can get it down to a level where, for the simple case, we can end up with a source package, complete with changelog entry, read for upload
06:26	Kamion	for .po files I'm happy to do it by steam for now and gradually automate; I think I've got the majority of the changes there
06:26	mdz	that'd be ideal
06:26	fabbione	Keybuk: the list isn't complete, is it?
06:26	Keybuk	fabbione: packages for which there is both a debian and ubuntu verison in the morgue and debian < ubuntu
06:26	Keybuk	(ie stuff we've changed)
06:26	Keybuk	though the gnome stuff we can probably ignore, because we *really* changed that <g>
06:26	Keybuk	http://people.ubuntu.com/~scott/patches/debian/
06:26	daf	Keybuk: what are the two sets of patches?
06:26	Keybuk	that's the debian side of it
06:26	fabbione	Keybuk: ok
06:27	Keybuk	daf: "ubuntu changes" and "debian changes"
06:27	mdz	Keybuk: output/ is the result of applying debian/ to warty-current?
=== nreid [~nreid@host81-139-0-78.in-addr.btopenworld.com] has joined #ubuntu-meeting
06:27	sabdfl	yes, gnome, x, we figure we take the lead
06:27	Keybuk	mdz: yup
06:27	Kamion	daf: Ubuntu changes generally fall into two groups: branding, and minor translation updates from overenthusiastic people who thought we had a good process for translation updates in warty :-)
06:28	mdz	Keybuk: <mdz> if we can get it down to a level where, for the simple case, we can end up with a source package, complete with changelog entry, read for upload
06:28	mdz	Keybuk: doable?
06:28	daf	if you simply have a patch that adds/changes translations, you simply apply the patch, regenerate the .pot file and use msgmerge
06:28	Kamion	daf: Debian changes you know
06:28	mdz	s/read/ready/
06:28	Keybuk	it actually ends up with about 1,000 rej files that need manually checking (3 per package) ... and a lot of those are hopefully simple fixes
06:28	Kamion	daf: the patch typically doesn't apply
06:28	Keybuk	mdz: well, you still need a human to resolve the case where debian and ubuntu have gone in different directions
06:28	mdz	Keybuk: yes, but we have a lot of stuff which should be non-overlapping
06:29	daf	Keybuk: ok, you need to find the file the patch applies to, apply it to that and then do further merging with the patched file
06:29	daf	arg
06:29	daf	s/Keybuk/Kamion/
06:29	mdz	the changelog in particular will always conflict due to diff/patch being how they are, but that's something we should be able to consistently resolve automatically
06:29	Keybuk	mdz: yeah, need to figure out a trick for that one :)
=== MrTom [~thomas@84.97.17.128] has joined #ubuntu-meeting
06:30	Kamion	daf: ah, so we unpack the branchpoint package for that
06:30	daniels	mdz: you could reasonably trivially write a changelog merge tool tho
06:30	daniels	mdz: the only problem is that patch doesn't understand changelog format
06:30	sabdfl	hm... changelog.ubuntu, which points into changelog.debian would be easier
06:30	jdub	separate ubuntu changelog would be really useful
06:30	Kamion	sabdfl: urk, debian/changelog is something understood by all sorts of tools
06:31	sabdfl	i'm not sure what the tools would do with that
06:31	elmo	hoary's been seeded with woody, and sync's running for non-modified stuff now
06:31	daf	in general, I think the method is this: (1) for each patch, apply it to the file it was originally for; (2) call msgcat on all the files to join them all together; (3) regenerate POT; (2) use msgmerge on the results of (2) and (3)
06:31	pitti	can we please resolve these technical details later and go on with the agenda?
06:31	Keybuk	elmo: did you really mean "woody"? :p
06:31	daniels	elmo: woody?
06:31	Kamion	it's more useful to users not to have a separate Ubuntu changelog, I feel
06:31	mdz	pitti: the technical detail of the merge is significant because it will determine how the work progresses
06:31	sabdfl	the changelog problem is one of a general class of problems we'll have to solve for derivatives
06:31	elmo	yeah, I thought it'd give us a special old skool flavour
=== sivang agrees with pitti
06:31	sabdfl	Kamion: think about the general problem, debian->ubuntu->kubuntu
06:31	mdz	if we're going to fix up all of the conflicts by hand, we also need to do it consistently
06:31	sabdfl	and i don't think a single file can convey it
06:31	doko	daf: you need to recode file if the encoding changed
06:32	Keybuk	mdz: so yeah, if we can work out a way of automating a given type of conflict, I can put that logic into hct so it can do it automatically later
06:32	sabdfl	certainly not one in the current format
06:32	Kamion	sabdfl: I know, but I still think it's actively more useful to users to have a single changelog
06:32	mdz	Keybuk: yeah, you'll need to do that anyway
06:32	daf	doko: urgh, good point
06:32	Kamion	sabdfl: I've considered this fairly carefully ...
06:32	sabdfl	Kamion: or a tool which presents it that way
06:32	mdz	Kamion: we'd need a changelog format which could represent branches meaningfully
06:32	jdub	i find it a pain to maintain ubuntu+debian packages
06:32	mdz	which would probably require version numbers which can represent branches meaningfully
06:32	daf	there are disadvantages to using msgcat, though
06:32	mdz	which is a ways off :-)
06:32	Kamion	mdz: nah, I have a suggestion I'll feed you offline
=== enrico agrees with sivang and pitti
06:33	fabbione	sabdfl: changelog is used also to build the package itself. it's not a good idea to fiddle with it too much
06:33	Keybuk	mdz: /debian/changelog.rej and /ChangeLog.rej I'm tempted to just do by stripping the context and applying them at 0,0 -- that usually "works" :o)
06:33	pitti	With my recent merges, I packaged every ubuntu change as a debian/patches/ubuntu- patch, took the pristine Debian package and documented the Ubuntu patches in the changelog
06:33	mdz	Keybuk: apart from being out of order
06:33	Kamion	Keybuk: better to merge changelogs in version order if possible ...
06:33	daf	Keybuk: I'd be interested to hear your thoughts on a file format that would be better than PO (even if they only relate to making diffs work better)
06:33	pitti	This was quite a bunch of work, but it is very clean
06:33	sabdfl	i understand that the toolchain uses it heavily, but part of our hoary goal is to generalise the platform for derivatives, and that will mean touching the toolchain
06:33	Keybuk	mdz, Kamion: I've applied debian to warty, not the other way around
06:33	mdz	pitti: yes, that works when the package is already using dpatch
=== jono [~jono@82-37-194-90.cable.ubr05.wolv.blueyonder.co.uk] has joined #ubuntu-meeting
06:33	Keybuk	it's the debian changelog entries conflicting
06:34	Keybuk	so putting those at the top *does* put them in order
06:34	Keybuk	<hoary> <new debian> <warty> <old debian>
06:34	jono	hi all
06:34	mdz	Keybuk: no, it doesn't
06:34	pitti	mdz: for dpatch/cdbs packages this is actually very nice
06:34	pitti	mdz: so we could do it for packages supporting it
06:34	Keybuk	moving warty to the top actually takes the changelog out of version order
06:34	mdz	Keybuk: the correct order could be something like <old debian> <less old debian> <old ubuntu> <current debian> <current ubuntu>
06:34	Kamion	sabdfl: I don't think separating the changelogs out is the right answer, though; the nCipher changelog format would be better (it documents branches inline), and I'll suggest something like that when we're not in a meeting
06:34	Keybuk	mdz: that's the order we're going to get
06:35	mdz	Keybuk: ah, if you do the merges in version number order, yes
06:35	mdz	wait, no
06:35	Keybuk	mdz: *nods* :)
06:35	mdz	you'd need to do them in date order
06:35	sabdfl	Kamion: ok, sounds good
06:35	daniels	mdz: surely version order is more meaningful?
06:35	Kamion	sabdfl: (this would also have benefits for things like BTS version tracking)
06:35	mdz	daniels: it gets weird
06:36	daniels	mdz: it more accurately represents the branches, though
06:36	pitti	daniels: but you cannot really sort 2.0-0ubuntu1 and 2.0-1
06:36	mdz	version order leaves us with something that makes more sense in and of itself :-)
06:36	pitti	daniels: either one may happened sooner or later
06:36	Keybuk	mdz: tomorrow afternoon UK, I can give you a collection of source packages with changelog and anything else I can obviously do automatically resolved
06:36	daniels	mdz: if you do it in date order, you'll end up with confusion because stuff that got changed in debian, wasn't in ubuntu at that stage
06:36	Keybuk	each one will be accompanied by a "this fell out" patch which will need manual review
=== neuro|laptop [~neuro@neuro.me.uk] has joined #ubuntu-meeting
06:36	mdz	Keybuk: great
06:36	Keybuk	and if we find ways of automatically doing that review, then I want to know about it to write code to do that next
06:36	sabdfl	ok, i think we can take this discussion out of band
06:37	mdz	ok
06:37	Keybuk	the total lines of "this fell out" are pretty tiny, around 3,000 in total
06:37	mdz	initial merge strategy is to let Keybuk lock himself in a room for a day
06:37	mdz	and then create bugs on the remainder
06:37	Keybuk	which given nearly a million lines of changes is pretty good <g>
06:37	Keybuk	(ignoring .po files, which are evil, evil, evil)
06:37	mdz	if the remainder is small enough, we'll just do it by hand
06:37	sabdfl	great
06:37	mdz	eek, we do need to resolve that .po issue
06:37	azeem	this whole problems smells like an application for that conary package thingy, which reportedly handles branches, patches and merges pretty well
06:38	Keybuk	daf: not putting a changing line number right before the bit that changes would be swell
06:38	jdub	azeem: ssshhh, be wery, wery quiet.
06:38	mdz	ok, onward to feature goals
06:39	mdz	let's take it from top to bottom
06:39	mdz	and for each item, determine whether it makes most sense for one of us to do it, or see if someone else listening would like to volunteer
06:40	mdz	first item is UTF-8, which is a bit of amorphous
06:40	mdz	we'll set UTF-8 by default early in the release cycle, and just fix whatever breakage comes up
06:40	mdz	it's really a bunch of unclassified bugs at this point, rather than a feature
06:40	Keybuk	yeah, I've been running utf-8 for a couple of years now; zsh is about the only breakage I notice
06:40	pitti	I have UTF-8 running for very long now, works nice for most parts
06:40	mdz	what will we do about existing Ubuntu installations?
06:41	mdz	leave them at non-UTF8, send out an announcement asking them to change?
06:41	fabbione	mdz: wiki -> utf8 howto ?
06:41	pitti	would make most sense
06:41	doko	changing the default from ISO to UTF8 on upgrade?
06:41	Keybuk	Kamion: what does debconf do in this situation?
06:41	mdz	fabbione: we should supply a script I think
06:41	sivang	add something to ubuntu-desktop to do that? :)
06:41	pitti	changing ~/.profile files on upgrading would be hell
06:41	Keybuk	first install the question was too low a priority to get asked
06:41	mdz	which handles generating locales and setting the default
06:41	Keybuk	what happens if the value is different on the update
06:41	Kamion	Keybuk: which?
06:41	Keybuk	does it keep the old or go with the new?
06:41	jdub	mdz: shouldn't we switch as part of the upgrade, so systems are consistent by default?
06:41	enrico	make an application to handle post-upgrade configuration issues?
06:41	mdz	jdub: changing the locale on the user sounds fairly evil
06:42	mdz	enrico: something more like that, yes
06:42	fabbione	i wouldn't go for automatic changes of that level
06:42	doko	mdz: we don't change the locale, but the encoding
06:42	enrico	Like one runs that and gets a TODO-list of things to check
06:42	Kamion	Keybuk: it's got a value already, it keeps it unless told otherwise
06:42	mdz	doko: that is a locale setting
06:42	elmo	yeah, that's like spitting on the golden rule thing
06:42	Keybuk	Kamion: and a dpkg-reconfigure locales would change to the new value?
06:42	pitti	mdz: we can't change the encoding automatically; this would break _every_ text file the user created
06:42	sabdfl	jdub: golden rule
06:42	Kamion	Keybuk: no
06:42	mdz	pitti: we are in agreement
06:42	Keybuk	or do you have to nuke out config.dat ?
06:42	Kamion	Keybuk: EVIL EVIL EVIL
06:42	seb128	if we change the system locale, what will happen with filename ?
06:43	mdz	we will provide a tool which the user can run which will DTRT
06:43	sivang	pitti is right. why wasn't it set at UTF8 from first place?
06:43	mdz	who will write it?
06:43	jdub	sabdfl: not a user chosen setting :)
06:43	seb128	we need to convert the filesystem ?
06:43	pitti	sivang: because there are still some bugs
06:43	mdz	sivang: bugs
06:43	seb128	filenames even
06:43	sivang	oh
=== enrico was thinking filesystem charset, too
06:43	Kamion	we should make sure that UTF-8 is generated where possible, but I'm very leery of changing the default for existing installations
06:43	sabdfl	i think this falls into the category of things that new installations get by default, upgrades get if they themselves do it
06:43	sabdfl	Kamion: agreed
06:43	jdub	yeah
06:43	pitti	sabdfl: agreed
06:43	Keybuk	enrico: GNOME does UTF-8 filenames whatever charset you're in, I think
06:43	mdz	Kamion: will you write the utf8-enabler tool?
06:44	pitti	Autodetecting the existing encoding of an ASCII file is practically impossible
06:44	sabdfl	we will have a good "release notes" and "upgrade notes" which can document this
06:44	Kamion	mdz: can do, yeah
06:44	enrico	Keybuk: even on things like BIG5 VFATs?  (it would create illegal names)
06:44	mdz	ok, great
06:44	mdz	and the bugs we'll fix as they come
06:44	mdz	next is a big one
06:44	Kamion	pitti: autodetecting the existing encoding of an *ASCII* file is trivial ... :-)
06:44	mdz	unified hardware detection
06:44	ogra	will there be any iso support in the apps left ?
06:44	seb128	Keybuk: nautilus does, but a lot of files are created out of nautilus ...
06:44	pitti	Kamion: okay, but you don't need to change them anyway
06:44	daniels	mdz: i would kill to move off discover1
06:44	sabdfl	ogra: yes, aiui
06:45	mdz	ogra: yes, we won't try to remove support for non-utf8 encodings
06:45	pitti	Kamion: but take a look at my ~, there are thousands of files with different encodings; some already in UTF-8, some in LATIN9, etc.
06:45	sabdfl	by unified we mean:
06:45	sabdfl	- installer
06:45	sabdfl	- installed system
06:45	sabdfl	- live cd
06:45	mdz	right
06:45	Kamion	pitti: (you said ASCII, not text)
06:45	daniels	sorry, my bad.
06:45	mdz	currently those use: discover1, hotplug and knoppix, respectively
06:45	pitti	Kamion: whoops
06:45	mdz	my position is that hotplug is the way forward for all three
06:46	daniels	yes
06:46	Keybuk	I guess hotplug is the target for unification
06:46	sabdfl	in addition there's the layer of intelligence above the detection tools
06:46	daniels	however, currently discover1-data has by far the most accurate hardware list, afaik
06:46	sabdfl	for example, x resolution and refresh
06:46	fabbione	we might still need discover for X
06:46	Kamion	ok, hotplug is one of the post-sarge goals for d-i
06:46	Kamion	we can move forward on that ourselves, given udev-udeb and hotplug-udeb packages
06:46	mdz	fabbione: yes, I consider X a separate issue
06:46	fabbione	mdz: ok
06:46	mdz	this one is purely kernel stuff
06:46	rburton	doesn't discover load a few drivers which hotplug doesn't?
06:46	Kamion	hotplug doesn't do X stuff, so discover is still needed for that, but that's OK
06:47	sabdfl	mdz: but we'll still need to unify the live cd x detection with the installer
06:47	mdz	rburton: installed Ubuntu has been using hotplug exclusively for some time now
06:47	sivang	rburton : this is what I was once told by joeyh
06:47	mdz	sabdfl: yes, I think we should consider that separately as well
06:47	pitti	daniels: does hotplug have hw lists at all? I thought it just uses the modules file from the kernel
06:47	bob2	pitti: purely from the kernel
06:47	rburton	mdz, ah ok
06:47	Kamion	pitti: yes, modules.pcimap
06:47	sabdfl	it's fundamental to the feature goal
06:47	sivang	rburton : experimenting with that backed up his statement.
06:47	bob2	isn't that generated from the kernel?
06:47	sivang	(on sid)
06:48	daf	Keybuk: yeah, that would help
06:48	daniels	sabdfl: tbh I haven't even looked at the live CD's autodetection, but that's one of the things we can look at
06:48	lamont	and then for grumpy eliminate the "separate but equal" (X vs kernel)?
06:48	sabdfl	sound, video, webcam, modem, network
06:48	Kamion	I'm happy to do the hotplug d-i integration, but does anyone know udev and hotplug well enough to produce udebs?
06:48	Keybuk	pitti: if the kernel doesn't know a module can be used with a given id, it's a lost cause trying to load it *anyway*
06:48	sabdfl	i'd like to be using the same codepaths for all of them
06:48	mdz	Kamion: should be easy
06:48	Kamion	(I don't; I looked briefly before warty released, and got lost)
06:48	mdz	hotplug is just a bunch of scripts
06:48	lamont	Kamion: I expect creating udeb's wouldn't be _that_ difficult, no?
06:48	pitti	Keybuk: right; at the time I typed this question I still thought we want to use it for X :-/
06:48	mdz	udev isn't much more
06:48	mdz	Kamion: I'll lend a hand with that
06:48	Kamion	lamont: it's not hard, just a question of knowing the package really
06:49	Kamion	mdz: thanks
06:49	lamont	ah, ok
06:49	mdz	fabbione: I know you have some ideas about the way forward for X autodetection
06:49	Kamion	Keybuk: that's not always true
06:49	mdz	fabbione: what is the right way to unify it between the live CD and the installed system?
06:49	fabbione	mdz: yes
06:49	Kamion	can I just flag up buses that aren't hotplug-enabled, too
06:49	Kamion	the mac-io bus on powermacs is the big one
06:49	mdz	Kamion: I have a patch for that
06:49	Keybuk	isn't that enabled yet?
06:49	Kamion	mdz: what, to the kernel?
06:49	Keybuk	I thought that was floating
06:49	mdz	Kamion: yes
06:49	Kamion	mdz: cool
06:50	sabdfl	very
06:50	fabbione	mdz: i can simply create a script that simulate an installation to detect the hardware as i do in the normal installation and create a live config
06:50	mdz	we can stage it for upstream
06:50	Kamion	we'll still have the installer's register-module facility available for corner cases
06:50	mdz	fabbione: so we would change morphix to invoke something which would trigger the debconf magic, rather than using the knoppix stuff
06:50	fabbione	mdz: correct
06:50	sabdfl	fabbione: can we shift the x scripts to python please?
06:51	amu	i think rewriting live-hwdesting using discover/hotplug is not such diffifult, timeuseage is very high
06:51	fabbione	sabdfl: no
06:51	sabdfl	fabbione: why not?
06:51	mdz	amu: it should just be a matter of calling /etc/init.d/hotplug start, if we do our work correctly
06:51	sabdfl	mdz: plus the config layer
06:51	Kamion	sabdfl: .config scripts can only use Essential: yes packages safely
06:51	mdz	sabdfl: config layer? for hotplug?
06:51	sabdfl	Kamion: see further down the list :-)
06:52	fabbione	sabdfl: because it is too much rework and as i was telling you a couple of days back i understimated the load to switch to x.org
06:52	sabdfl	mdz: for eg sound config
06:52	fabbione	sabdfl: so i much rather keep what we can from Xfree86
06:52	Kamion	sabdfl: diverging from Debian on something as big as the X .config script is busy-work, surely?
06:52	mdz	sabdfl: we should use all of the stock Ubuntu stuff for that
06:52	amu	mdz: with cdbackup it works
06:52	sabdfl	detecting the card is one thing, setting appropriate levels etc
06:52	Kamion	sabdfl: also, upgrades
06:52	sabdfl	Kamion: i'm trying to standardise skill sets, which will pay off for us as a team later
06:52	Kamion	sabdfl: I know, but Essential is a very hairy place
06:53	mdz	the other issue is that python is huge for an essential package
06:53	sabdfl	understood, having python there is not something i'm going to budge on
06:53	Keybuk	sabdfl: the issue comes where Python has to be installed, configured and completed before *any* package using it is installed
06:53	sabdfl	python-base
06:53	Keybuk	so it gets a bit hairy
06:53	mdz	sabdfl: the python guys will scream if we split up the standard library further :-)
06:53	sabdfl	the python guys will be thrilled that python has become Essential
06:53	jdub	ooof, which bits would you choose for python-base, too...
06:54	doko	we had the split once in Debian. there are no clear lines where to split it. but that further down the list.
06:54	sabdfl	as for scchnnnaaakkee...
06:54	fabbione	sabdfl: we are going to deal with a new upstream and that will be already hell of a job. perhaps we can reconsider it for hoary+1, but i am not too crazy to do it now
06:54	Kamion	will they? they weren't so thrilled about distutils not being there ...
06:54	sabdfl	fabbione: no, since we are creating these packages from scratch, i'd like to do it right the first time
=== pollianicus [~lucy@82-68-75-30.dsl.in-addr.zen.co.uk] has joined #ubuntu-meeting
=== pollianicus [~lucy@82-68-75-30.dsl.in-addr.zen.co.uk] has left #ubuntu-meeting []
06:54	Kamion	I don't think they'd be happy unless the standard library's in one piece
06:54	sabdfl	Kamion: it will be, post install
06:54	Kamion	sabdfl: in some configurations ... :)
06:55	Keybuk	sabdfl: but then you can't use any of the Python standard library in Python scripts in packages
06:55	Keybuk	sabdfl: and Python is pretty useless without its standard library :(
06:55	doko	keybuk: depends which modules and extensions you compile in statically
06:55	sabdfl	ok, separate discussion, i dont mind really, just do mind that python is in essential for ubuntu
06:55	sabdfl	and that we use it for all system functions unless there's a bollocking good reason not to
06:55	Keybuk	(personally, I'd like to kick perl out of Essential :p)
=== sivang thought it was going to be for GTK/GNOME wise
06:56	Kamion	sivang: Essential's a technical category
06:56	mdz	ok, the current unresolved item is the unification of hardware detection
06:56	mdz	we can either do this as one task, or break it down
06:56	mdz	Kamion said he would do the hotplugification of d-i
06:56	sabdfl	mdz: i think we're all agreed on hotplug for device detection
06:56	sabdfl	amu: live cd
06:56	mdz	so the remainder is live CD work
06:56	mdz	amu: ?
06:57	jdub	mdz: can we put someone in charge of that goal in general?
06:57	mdz	jdub: I will take responsibility for tracking the sub-tasks
06:57	jdub	that was easy ;)
06:57	mdz	fabbione: what is your opinion about dynamic X reconfiguration at boot, to detect hardware changes?
06:57	amu	hmm good question, therorethically it should work
=== mdz ducks
06:58	fabbione	mdz: i have some ideas already in that direction
06:58	mdz	fabbione: that would bring the live CD and the installed system in line with each other
06:58	fabbione	mdz: and a possible solution
06:58	mdz	nd we will need it for a gui installer asa well
06:58	fabbione	mdz: that will come after X.org is out
06:58	mdz	fabbione: hoary?
06:58	fabbione	mdz: probably
06:58	Kamion	mdz: we don't need that for a GUI installer
06:58	sabdfl	kernelfb?
06:58	Kamion	right
06:58	Kamion	gtk+directfb
06:58	mdz	ok
06:58	daniels	mdz: it's difficult to do that without crapping all over user changes
06:58	fabbione	mdz: i am boiling the idea. i need to see with daniel if it's possible
06:58	mdz	well, in both cases we need _something_ which works at boot
06:58	daniels	yes, X is too heavy for a GUI installer and a bootsplash.
06:59	jdub	daniels: not for the installer
06:59	fabbione	mdz: hold on a sec. we are confusing 2 things here
06:59	mdz	daniels: we could do it only if X fails to start
06:59	jdub	X is a good option for the installer
06:59	daniels	gui installer is directfb domain, imho, and bootsplash is mad phat splash's area
06:59	Kamion	jdub: not convinced
06:59	fabbione	one thing is configuring X at boot time for liveCD
06:59	mdz	ok, let's leave the gui installer discussion for another time
06:59	jdub	Kamion: easier to deal with than gtkfb or directfb
06:59	fabbione	and one is autoconfiguring it for the normal installation
06:59	mdz	we're talking about unifying X config between the live CD and the installed system
07:00	fabbione	mdz: ok. i have already a solution for that. and yes it will be hoary
07:00	mdz	I think there is overlap between that, and dealing with hardware changes in the desktop
07:00	Kamion	jdub: directfb just comes up and just works, no effort whatsoever; I don't see how X could be easier
07:00	fabbione	jdub: Kamion is right
07:00	fabbione	jdub: X will only bring problems
07:00	daniels	(my parting shot: the framebuffer very rarely goes wrong -- like, ever; however, looking at the list, X autodetection is harder)
07:00	sabdfl	mdz: at the very least, it would be possible to store a set of "detected values", and see if that has changed from one boot to the next, and prompt for reconfig
07:00	daniels	anyway, yeah, unifying the config from livecd to ubuntu is hoaryable
07:00	mdz	fabbione: ok, so you will take care of moving the live CD X configuration over to use our config system rather than knoppix
07:01	sabdfl	i agree the gui installer is more directfb territory
07:01	fabbione	mdz: if i get the resources yes.
07:01	jdub	daniels: (using fb doesn't rule out X...)
07:01	ogra	what about kdrive ?
07:01	mdz	sabdfl: let's treat the live CD piece of it as part of the unification goal, and the reconfigure-on-hardware-change as a separate feature?
07:01	sabdfl	fabbione: you will, it's a priority, in python
07:01	fabbione	mdz: when i offered my help for the livecd, my ping was lost
07:01	daniels	ogra: awful hardware support
07:01	sabdfl	mdz: yes, that's what i was suggesting
07:01	ogra	daniles: vesa ?
07:01	daniels	ogra: not an option
07:01	ogra	k
07:01	fabbione	sabdfl: sorry.. i lost the contest...
07:02	sabdfl	have a tool that looks at a store of "what was previously detected" and sees if that has changed
07:02	sabdfl	fabbione: you will get the resources to unify live cd and installer x config in python
07:02	mdz	fabbione: contest?
07:02	fabbione	sabdfl: ok
07:02	fabbione	mdz: typo
07:03	fabbione	sabdfl: but that will kill the plan to configure X at debian-installer time
07:03	fabbione	sabdfl: that is something that we can probably do for hoary
=== maskie [~maskie@196-30-111-250.uudial.uunet.co.za] has joined #ubuntu-meeting
07:04	mjg59	sabdfl: One issue with using directfb for the installer is that someone needs to write an accessibility interface for directfb/atk then
07:04	mdz	fabbione: we don't need to configure X at debian-installer time; the current timing is OK for hoary
07:04	mdz	mjg59: good call
07:04	mjg59	X gives you already working a11y infrastructure
07:04	Kamion	mjg59: text mode + speakup might make more sense for hoary
07:05	sabdfl	mjg59: hmm... can we run x on directfb?
07:05	mdz	however, using X in the installer would seem to be in conflict with Kamion's idea to support floppy installs :-)
07:05	rburton	mailq
07:05	mdz	sabdfl: yes
07:05	mdz	sabdfl: well, on fb
07:05	mjg59	Kamion: Speakup requires extra hardware, doesn't it?
07:05	sabdfl	and we still have fall-back to text mode
07:05	Kamion	mjg59: well, yeah, depends on the kind of a11y
07:05	mdz	at present, GUI installer is not on the hoary list
07:06	mdz	and we have many more items to review which are
07:06	jdub	um
07:06	mdz	so can we table that discussion for now?
07:06	sabdfl	yes
07:06	jdub	gui installer is on the hoary list, but it has sabdfl's question mark
07:06	sabdfl	i won't commit to having a gui installer for hoary
07:06	sabdfl	it will back us into a corner
07:06	mdz	ok
07:06	sabdfl	i've no problem with starting work on it
07:07	mdz	I propose that we not attempt ppc64 for hoary
07:07	mdz	there is currently no real vacuum for it to fill
07:07	sabdfl	mdz: won't attempt any further arch's unless a community team steps up
07:07	mdz	and it is a multiarch-wanting arch too
07:07	sabdfl	if one does, we'll provide h/w
07:07	doko	yes, that would need a toolchain update
07:07	mdz	ok, consider it moved
07:08	mdz	" LSB compliant i386 libraries on amd64"
07:08	mdz	doko: this is 32-bit compatibility?
07:08	doko	yes
07:08	mdz	what does it entail?
07:08	elmo	we'll need to do enough of ppc64 for G5 support, tho, right?
07:08	elmo	[sorry, I'm late]
07:08	mdz	elmo: I expect we'll build a ppc64 kernel for the powerpc arch
07:08	elmo	ok, cool
07:09	mdz	noted in bugzilla and discussed with herbert
07:09	elmo	it'd suck to not support our own buildds ;-)
07:09	mdz	hey, we have our own h4x0red kernel for that
07:09	Kamion	yeah, ppc64 kernel != ppc64 userspace
07:09	mdz	elmo: you love custom kernels :-P
07:09	sabdfl	nonetheless, elmo has a point
07:09	mdz	doko: so what exactly would be involved in implementing this feature?
=== AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has joined #ubuntu-meeting
07:10	mdz	I assume this would only provide basic support for compiling and running 32-bit apps
07:11	mdz	since we are not going to do multiarch in the packaging system for hoary
07:11	sabdfl	do they get a limited set of 32-bit libs to work with?
07:11	sabdfl	is this how we currently do mozilla and oo.o?
07:11	mdz	so that means a bi-arch gcc, and ia32-libs
07:11	mdz	sabdfl: yes, that's ia32-libs
07:11	dieman	heh, ubuntu is on /. again
07:12	doko	hmm, thought that this is Tollef's domain? See #277852 for a current discussion, if/what is needed for proper i386 support. needed: a working biarch toolchain, agreement where to put the ia32 libraries
07:12	mdz	if there is not yet agreement, then this is not something we should push for hoary
07:12	mdz	the mention of LSB seems to imply that there is a standard
07:12	mdz	Mithrandir is not here
07:13	mdz	let's skip this item for now
07:13	doko	wether ia32-libs is a good idea? some libs already have biarch support like ncurses, readline, etc. so maybe just add to these libraries the 32bit things.
07:13	mdz	doko: sabdfl would like an essential python package
07:14	ogra	regarding the support side on amd64 , there should be a home for things like flash......
07:14	mdz	doko: is there anything in the current python2.3 package which could be split in order to simplify it?
07:14	mdz	ogra: I think the only way to support i386 flash is to have an i386 firefox, which we don't want to do
07:14	doko	yes, I looked back at the point where we had split it.
07:14	ogra	mdz: oh..... the peole are crying a lot about flash...
=== Seveas [seveas@213-73-236-154.cable.quicknet.nl] has joined #ubuntu-meeting
07:15	mdz	doko: there seems to be a fundamental conflict between providing the full python standard library, and having it be essential
07:15	doko	codecs maybe make up a bit of code size, standard libraries which you don't need at a point of time... I'd prefer to have some use case for what we want with python at that point and then define the split.
07:15	doko	should this essential python work without /usr?
07:15	mdz	doko: perhaps we could provide all of the pure python stuff
07:16	mdz	doko: good question
07:16	Keybuk	perl-base works without /usr
07:16	Keybuk	uh
07:16	Keybuk	sorry
07:16	mdz	no it doesn't :-)
07:16	Keybuk	perl-base DOESN'T work without /usr
07:17	sabdfl	doko, mdz, let's figure out the implementation separately
07:17	mdz	ok
07:17	doko	why stop at pure, and don't have the zlib module? this line is artificial.
07:17	doko	ok
07:17	mdz	" Raise default dpkg-reconfigure priority, adjust packages as necessary?"
07:17	mdz	we already did that for warty
07:17	sabdfl	:-)
07:17	Keybuk	yeah, isn't that High already?
07:17	Kamion	dpkg-reconfigure != debconf
07:17	Kamion	dpkg-reconfigure's default priority is low
07:17	mdz	ohh, right
07:17	sabdfl	ah
07:17	Kamion	what's the use case for raising it?
07:17	Kamion	dpkg-reconfigure asks all questions by design
07:17	mdz	Kamion: to make it more useful
07:17	sabdfl	yes that causes the "million spurioous questions on reconfigure" experience
07:18	Kamion	mdz: that would make it less useful, actually
07:18	mdz	"all questions" is too many questions
07:18	Kamion	sabdfl: reconfigure is a deliberate choice, though
07:18	sabdfl	Kamion: those who want the full question set can ask for it
07:18	Kamion	people WANT to see all questions :-)
07:18	Kamion	(if they run dpkg-reconfigure)
07:18	sabdfl	if they do, --priority=low
07:18	mdz	Kamion: when we tell an Ubuntu user to run dpkg-reconfigure, they don't want to see all questions
07:18	Keybuk	mdz: why would we tell a user to do that?
07:18	sabdfl	reconfigure says "give me the same set of questions again"
07:18	mdz	Keybuk: because it is often the simplest way to solve their proble
07:18	mdz	m
07:19	sabdfl	Keybuk: i think we will aim to provide a high level UI for that
=== ogra agrees with mdz
07:19	sabdfl	for example, inside aptitude, press a key to reconfigure a package
07:19	Kamion	ok, don't think it should be as high as --priority=high though, medium feels better
07:19	doko	sorry, a bit late: is python2.4 default for hoary?
07:19	sabdfl	and the questions should be the same as the questions on install
07:19	mdz	Kamion: yes, I think medium is appropriate
07:19	mdz	Kamion: the idea is to exclude the "control freak" questions
07:19	mdz	and just give them a basic level of configurability
07:19	Kamion	sabdfl: that just doesn't work with a lot of debconf scripts though
07:19	mdz	which is what medium should be
07:19	Kamion	mdz: right, agreed
07:20	sabdfl	Kamion: because they assume you've answered the question already?
07:20	mdz	reconfigure should ask more questions than at install
07:20	mvo_	sabdfl: synaptic support reconfigure via debconf (through the gnome debconf ui)
07:20	mdz	because install should exclude questions which have a reasonable default
07:20	Kamion	sabdfl: varies; they'll certainly often have different behaviour. debconf's arbitrarily scriptable
07:20	sivang	what's the profile of an average Ubuntu user anyway? what can we expect of them?
07:20	sabdfl	i think we are asking for users to go from b0rked to v87686ked
07:20	mdz	but reconfigure should ask questions which have a reasonable default, and give the user the opportunity to change them
07:20	Kamion	mdz: YES :-)
07:20	Keybuk	sivang: ideally we don't have one; Ubuntu works for all users, not just the average one
07:21	sabdfl	hold on
07:21	sabdfl	how do you tell a user "you answered the wrong way at install, do this, and answer it differently"
07:21	mdz	sabdfl: Kamion and I seem to be in agreement that what we want here is a default dpkg-reconfigure priority of 'medium'
07:21	sabdfl	that's fine, if i can see a list of new questions that introduces :-)
07:21	sivang	wouldn't it be wise to think up one, and then target it, and decide priorites by it (debconf)? surely we cannot target each and every user profile which might arise..
07:21	Kamion	if we made it 'high', it would often end up asking fewer questions, which I think would be worse
07:22	mdz	sabdfl: that is a problem of unsolvable complexity, I fear :-)
07:22	jdub	sivang: (this is slightly more abstract than that)
07:22	Kamion	we can attempt to produce one for base+desktop, probably
07:22	sabdfl	kamion: i'd like to really define the set of questions that a user is ever likely to see
07:22	mdz	it varies depending on arbitrary criteria
07:22	fabbione	mdz: i don't have a very strong opinion on raising to medium, but i think changing it will create some kind of extra debugging work for the users when we have to ask to reconfigure with --priority=low
07:22	sivang	or maybe let them choose the profile, and configure debconf accordingly ? (please excuse me if this is all babble)
07:23	mdz	sabdfl: do you agree that reconfiguration should ask a different set of questions than at initial install, given that our goal for many packages (all of deskop) is that they not ask any questions at initial intsall?
07:23	sabdfl	in fact, i don't mind if we do this, but it means i'm going to have to review every single "medium" question
07:23	Keybuk	to be honest, I think I tend towards defaulting to --default-priority; as that's generally unsurprising
07:23	Kamion	Keybuk: but will generally mean dpkg-reconfigure does absolutely nothing
07:23	mdz	Keybuk: that does nothing in most cases
07:23	Kamion	I don't think taking a useful command and turning it into a no-op is good
=== mdz channels harder
07:24	sivang	why not having it low priority install time, and raise it automatically on reconfigure? (assuming this requests for more control)
07:24	Kamion	sabdfl: maybe we shouldn't be recommending dpkg-reconfigure in general ...
07:24	sabdfl	ok, let's go with medium, but then you guys are going to have to put up with a lot of bugs from me in that regard :-)
07:24	Keybuk	it still does the effect of the settings, as in postinst?
07:24	mdz	this change falls under the heading of stuf that we should change early
07:24	sabdfl	Kamion: need some tool to do it
07:24	mdz	so that we can catch as much of the fallout as possible through routine testing
07:24	sabdfl	yes
07:24	sabdfl	sigh
07:24	Keybuk	mdz: yeah, first thing type change
07:25	Kamion	sabdfl: or, at least, for a very limited set of packages, like xserver-xfree86
07:25	mdz	sabdfl: I think most of those bugs will be trivial ones
07:25	sabdfl	Kamion: could you produce a script to mail me all of the questions in debconf, for main/restricted packages, that would be visible at medium or higher priority
07:25	mdz	sabdfl: things which are medium and should be low
07:25	mdz	sabdfl: the worst of it will be that we need to rewrite some text for the questions
07:25	sabdfl	mdz: yes, we will need to, guaranteed
07:25	Kamion	sabdfl: ok, will try
07:25	sabdfl	Kamion: tvm
07:25	mdz	Kamion: as long as you're taking on work, will you be the one to upload debconf with the default priority change for dpkg-reconfigure?
07:26	Kamion	(sometimes priorities are programmatically determined, so it may be fun)
07:26	Kamion	mdz: yeah, that's easy
07:26	mdz	Kamion: it'll be on the list of things to break early, with your name next to it
07:27	mdz	moving on
07:27	mdz	SE Linux
07:27	jdub	let's dump it
07:27	mdz	this is a highly specialized project
07:27	pitti	I would really like to see some easy support for MAC
07:27	mdz	I don't think we need to do it in-house, but I would love to see a proof of concept from a third party
07:27	Keybuk	if we want SE Linux, we need someone who knows all about it
07:27	pitti	grsecurity/SELInux/RSBAC/Whatever
07:27	sivang	Kamion : any example ?
07:27	mdz	Keybuk: agreed
07:27	jdub	yeah
07:27	Keybuk	from what I can tell with my chats with them, there's an arch-like learning curve to it
07:27	doko	pitti: MAC?
07:27	pitti	Do we really want SELInux support?
07:28	sabdfl	it's going to be a user nightmare if we fiddle with selinux
07:28	pitti	doko: Mandatory Access Control
07:28	thom	doko: mandatory access control
07:28	mdz	sabdfl: it strikes me as something to do as a derivative
07:28	pitti	Apart from the fact that SELInux is in upstream kernel, it is very complicated
07:28	jdub	we just won't have the cycles to do it propery for hoary
07:28	mdz	sabdfl: and then fold in once it is shown to work
07:28	sabdfl	mdz: good call
07:28	jdub	mdz: agree
07:28	jdub	seubuntu
07:28	Keybuk	and there's probably at least 6 months work on dpkg before it can even support it as well
07:28	pitti	We should develop it in Hoary time and publish it in grumpy
07:28	thom	yeah. fedora seem to be having a lot of problems getting it usable
07:28	sabdfl	subuntu :-)
07:28	mdz	next up is fresher and juicier glibc
07:28	mjg59	Did Fedora go with SELinux in the end?
07:29	daniels	sabdfl: is subuntu the distro with a root account per default?
07:29	mdz	apparently, Debian's glibc is ages old
07:29	jdub	mjg59: FC3 has a very very basic default configuration
07:29	Keybuk	mjg59: backed most of it out to a policy just for things like ssh
07:29	pitti	Can't we pick up something easier, like grsecurity or RSBAC?
07:29	Keybuk	mdz: it isn't
07:29	Kamion	mdz: it'll be updated right after sarge
07:29	daniels	mjg59: yes, although far more toned down from fc2's aggressive policies
07:29	azeem	mdz: jbailey was working on updating glibc, AFAIK
07:29	Keybuk	mdz: it's one minor release behind
07:29	Keybuk	unless I'm missing something entirely
07:29	Kamion	mdz: it's only been frozen because we (Debian RMs) are bastards :)
07:29	sabdfl	pitti: any of those things immediately takes us way out on a limb
07:29	mdz	is BenHerrenschmidt here?
07:29	doko	afaik, newer glibc is tightly coupled with newer gcc ... :(
07:29	mdz	he proposed this, and might have some details about what it means
07:29	elmo	mdz: no
07:29	Keybuk	ftp://ftp.gnu.org/gnu/glibc/
07:29	azeem	but he stopped a bit when he noticed sarge wasn't about to get released soonish
07:29	thom	mdz: he's in .au, so most likely asleep
07:29	jdub	mdz: no, but we should get more details from him about it
07:29	Keybuk	^ the latest there is 2.3.3
07:29	Kamion	Keybuk: glibc's stopped making releases, you have to pull CVS
07:29	jdub	mdz: happy to take an action
07:29	mdz	ok, so is this simply a "track Debian" sort of thing, then?
07:30	pitti	sabdfl: why? We shouldn't install it by default, but we could have apt-get install xxx-server-profile or xxx-desktop-profile
07:30	Keybuk	Kamion: oh, I didn't know that
07:30	elmo	mdz: I think so
07:30	Keybuk	that's kinda scary
07:30	doko	kamion: there is 2.3.3
07:30	jdub	mdz: i can clarify it from him
07:30	thom	(new glibc gets us NPTL on powerpc, amongst other things)
07:30	azeem	Keybuk: glibc stopped doing proper releases, 2.3.3 is a sort-of stable snapshot from last year, AFAIK
07:30	pitti	sabdfl: grsec/rsbac/lids only need kernel support and tiny userspace programs
07:30	mdz	if sarge doesn't happen soon enough to get it from Debian, is it worth moving ahead of Debian?
07:30	doko	thom: only with gcc-3.4
07:30	mdz	i.e., what do we get out of newer glibc?
07:30	Kamion	which basically means we need hard-core glibc experts on staff to make it work
07:30	Keybuk	changing libc smells like abandoning binary compatibility with Debian to me
07:30	mdz	1. NPTL on powerpc
07:30	jdub	mdz: can we pass on this and get more feedback from benh?
07:30	mdz	jdub: ok, let's
07:31	daniels	benh was saying that most of the problems with glibc were !(i386|amd64|powerpc), i.e. mostly NOTWARTY
07:31	Kamion	since picking a working glibc out of CVS is generally experts' work
07:31	mdz	jdub: will you get that feedback?
07:31	daniels	(glibc -> CVS glibc)
07:31	jdub	mdz: happy to take the action
07:31	mdz	done
07:31	mdz	next up, usplash
07:31	sabdfl	no releases from glibc? nnaaaiiice
07:31	sabdfl	kernel, glibc, the yellow submarine
=== azeem suggests talking to jbailey for glibc
07:31	mdz	sladen: are you here?
07:31	Keybuk	no npmccallum either?
07:31	jdub	azeem: (benh raised the issue)
07:31	daniels	ah, mad phat startup
07:31	mdz	usplash, for those unfamiliar, is the proposed boot splash implementation
07:32	mdz	which works in userspace using the kernel framebuffer, rather than patching it
07:32	daniels	i don't believe there is any contention over what's on the wiki right now
07:32	sabdfl	ubusplash!
07:32	mdz	it also involves some dbus magic to provide a nice progress indicator
07:32	sabdfl	optional
07:32	jdub	can we bring these items back together?
07:32	mdz	jdub: which items?
07:32	jdub	usplash
07:32	daniels	mdz: not dbus until we can do some upstream hackery (libexpat in initrd, yuk)
07:32	Keybuk	usplash -> have it if it's finished
07:33	sabdfl	npmccallum won't be on the team for hoary
07:33	daniels	most of the bits of usplash are reasonably small
07:33	mdz	Keybuk: what we're here to decide is whether it will be done, and who will do it :-)
07:33	Keybuk	sabdfl: oh?
07:33	sabdfl	so we need to take this on internally or find a bounty candidate
07:33	azeem	jdub: fair enough, but jbailey is a glibc maintainer and was working on it for Debian anyway
07:33	daniels	sabdfl: it's almost certainly doable internally, IMO
07:33	mjg59	Are we sure about being framebuffer based?
07:33	daniels	mjg59: as opposed to ... ?
07:33	mdz	mjg59: no, that's just current thinking
07:33	sabdfl	Keybuk: grep -ir npmccallum ~scott/patches/warty
07:34	mdz	if the implementor wants to do X or aalib, I'll at least listen :-)
07:34	mjg59	I worry that using two different graphical mechanisms could result in weirdness
07:34	mjg59	There'll always be some hardware that'll work with one and not the other
07:34	sabdfl	is fedora using a newer glibc?
07:34	daniels	sabdfl: write small fb blitter; write small co-ordination daemon; write novtswitch (done); make gdm and lsb init lib usplash-aware
07:34	mdz	mjg59: we'll need to get framebuffer stuff into good shape eventually anyway
07:34	sabdfl	daniels: don't trivialise the issues, x-platform for a start
07:34	jdub	can we bountyise this to sladen?
07:34	mdz	jdub: depends on sladen
07:34	daniels	sabdfl: true
07:34	Keybuk	sabdfl: so, uh, can someone update StaffOverview when people leave <g>
07:34	thom	sabdfl: yes, fedora is pretty much running off head of CVS
07:35	mjg59	mdz: This is sort of related to later stuff, but suspend/resume is going to be easier without framebuffer
07:35	mjg59	Probably massively easier
07:35	sabdfl	Keybuk: yes, sorry, i should have
07:35	mjg59	(on x86, at least)
07:35	mdz	mjg59: are the framebuffer issues unsolvable?
07:36	mjg59	mdz: vesafb is never going to work across suspend/resume, because there's no way to reconfigure the mode
07:36	jdub	mdz: can we assign a 'project manager' to the goal, to sort out bounty, delivery, etc?
07:36	mjg59	vesafb-tng might be a better plan, but it's a big divergence from mainstream
07:36	mdz	jdub: we should decide whether one of us will do it, or bounty it out
07:36	mdz	it's looking like a bounty sort of thing so far
07:36	jdub	yes, i think it's a bounty
07:36	mdz	unless someone here has a very strong interest in it
07:36	mdz	ok, bounty
07:36	jdub	not sure it's critical enough to manage internally
07:37	mdz	" Do something smart with SMART?"
07:37	jdub	hold on
07:37	sabdfl	mjg59: give me a quick rundown of the alternative options to fb for ubusplash?
07:37	jdub	can we assign someone to manage the bounty?
07:37	mdz	sabdfl: X
07:37	mdz	jdub: I will
07:37	jdub	ok
07:37	mjg59	sabdfl: Most straightforward is to start X /very/ early
07:37	daniels	fb or x, and i personally think x is a very bad idea; i think what's on the wiki is current best practice
07:37	mjg59	Which is what Fedora do
07:38	mdz	the SMART proposition would involve getting the SMART tools installed by default, and having them do something useful by default
07:38	mdz	ideally the user should get some notification when their disk is failing, etc.
07:38	jdub	mdz: sounds underspecified
07:38	sabdfl	mdz: silbs and i have a PA starting in two weeks who can carry the load  of bounty state tracking
07:38	mdz	jdub: indeed
07:38	daniels	mjg59: yes
07:38	jdub	sabdfl: (that's good news)
07:38	mdz	sabdfl: administrative or technical?
07:38	LeeColleton	SMART tools don't work with SATA drives last time I checked
07:38	daniels	mjg59: but they also start kdrive to track init, which is just bong imo
07:38	sabdfl	mdz: purely admin
07:38	daniels	mjg59: note that the current plans involve starting x very early
07:39	Keybuk	daniels: like, putting X in initrd ?!
07:39	mdz	sabdfl: ok, so I'll expect to continue to track technical progress
07:39	Keybuk	loading ramdisk ......
07:39	sabdfl	daniels: but not THAT early
07:39	mdz	Keybuk: not as crazy as it sounds
07:39	Keybuk	still loading ramdisk .....
07:39	daniels	Keybuk: no
07:39	daniels	sabdfl: right.
07:39	sabdfl	mdz: i think we should have an internal contact for each bounty, clearly, but not always you
07:40	sabdfl	it will be good to develop a little management capacity in the rest of the team too
07:40	daniels	basically, start the system, kick in usplash, get a logo out to framebuffer early and drop in some icons and status text; after network init (the hostname *cannot* change under X in current implementations), start X in the background
07:40	mdz	sabdfl: less work for me is usually acceptable :-)
07:40	daniels	when gdm has a login screen ready for the displaying, switch over to that
07:40	mjg59	If we want framebuffer functionality and we want suspend/resume, we're going to have to modify every single framebuffer driver
07:40	sabdfl	mjg59: can you get rid of framebuffer post-boot?
07:40	daniels	sabdfl: framebuffer 4 lyf, i'm afraid
07:40	mdz	the SMART thing is underspecified; I'll put it on a list of vague stuff, and if someone wants to come along and propose something concrete, we'll revisit it
07:40	mjg59	sabdfl: Not trivially
07:40	sivang	sabdfl : could there be a more thorugh explenation for the bounties on the wary page? IMHO it should have already been moved to Hoary
07:41	jdub	sabdfl, mdz: a number of the goals with my name attached are ones i expect to manage, rather than do
07:41	Kamion	mjg59: that's kind of unavoidable on powerpc, mind ...
07:41	sivang	sabdfl : for example, what is doc-base registeration?
07:41	mdz	sivang: several of the goals assume a thorough working knowledge of Debian packaging
07:41	mdz	which would be necessary to complete them anyway
07:42	thom	sivang: every thing that ships documentation needs to register siad documentation with doc-base
07:42	mjg59	Kamion: PPC is less of a problem - people have already dealt with that
07:42	Kamion	mjg59: oh, the modifications aren't quite portable?
07:42	mdz	let's take the usplash design discussion offline
07:43	mdz	we have much more ground to cover
07:43	mjg59	Kamion: The current suspend/resume code relies on OF doing some reinitialisation
07:43	mdz	next up is the question of whether we should handle NTP differently for Hoary
07:43	mdz	using ntpd rather than just running ntpdate at boot
07:43	Keybuk	aren't we doing ntpdate+ntpd now?
07:43	mdz	no, we currently only do ntpdate
07:43	lamont	Keybuk: "No listening ports"
07:43	Keybuk	ahh, it's in the seed but doesn't do anything?
07:43	doko	that was basically the delay problem, when you don't have a network connection?
07:44	mdz	this proposal came from the fact that gnome-system-tools integrates with ntpd
07:44	mdz	and not ntpdate
07:44	lamont	it would be nice to have an ntpd listening on the port by default.
07:44	mdz	so it has a little checkbox which will install ntpd, and then let you configure which servers to sync with
07:44	lamont	then again, the current ntpd is pretty fat
07:44	ogra	the delay could easy be solved by a poing in the bootscript
07:44	Keybuk	lamont: it'd be nice to have cups listening, http listening, etc.
07:44	mdz	it'd be nice to get rooted
07:44	daniels	i think ntp would be much more doable if we were smart about miitool or iwtool or whatever for link beat
07:44	lamont	Keybuk: heh. yeah
07:44	Keybuk	but then we're security swiss-cheese
07:44	sabdfl	can ntpdate be run in the background?
07:44	mdz	sabdfl: yes, it can
07:44	jdub	daniels: (NetworkManager)
07:44	mdz	in fact, I think it ignores errors currently anyway
07:44	mdz	but the delay is a separate issue
07:45	mdz	ntpdate and ntpd do different things
07:45	sabdfl	let's not do ntpd unless we really have to
07:45	lamont	very different
07:45	Keybuk	you need both
07:45	sabdfl	i'd be much happier with a cron'd ntpdate
07:45	doko	the delay isn't ntp specific. needs a mod to /etc/nsswitch.conf
07:45	Keybuk	ntpd keeps the clock in sync, but will cowardly not sync it if it's too far away
07:45	Keybuk	ntpdate syncs it, and then leaves
07:45	mdz	right
07:45	sabdfl	yes, ntpdate is a one-timerr
07:45	Keybuk	sabdfl: that's what we used to do at Demon to avoid the port
07:45	elmo	the cowardly thing is actually a feature tho
07:45	mdz	we decided way back in london that we wanted ntpdate as a default
07:45	Keybuk	(well, you have the port, but only for a few seconds)
07:45	lamont	sabdfl: anyone relying on filesystem timestamps would be very unhappy with cron'ed ntpdate
07:45	sabdfl	but there's nthing stopping us from doing it regularly
07:46	mdz	so the obvious course would be to change g-s-t to integrate with our ntpdate package
07:46	mdz	rather than with ntpd
07:46	sabdfl	lamont: where would you rely on filesystem timestamps?
07:46	lamont	make
07:46	elmo	oh, btw, orthogonally, can we pretty please de-root ntpd, even if we don't install it by default
07:46	mdz	jdub: is that a reasonable proposition?
07:46	Keybuk	lamont: anyone relying on filesystem timestamps that much would have configured ntpd themselves
07:46	mdz	elmo: good call
07:46	sabdfl	ok
07:46	elmo	the ntpdate-regularly thing also breaks regular cron jobs
07:46	jdub	mdz: 'synchronise now' or 'set up regular cron job'? i'm kinda uncomfortable with the cron job too
07:46	mdz	jdub: 'synchronise now' button, and configure servers
07:46	elmo	as time just, err, doesn't behave like time.. whereas with ntp, it just speeds up or down :)
07:47	sabdfl	seems we have the same problem either way
07:47	mdz	I'm not particularly hot on cron either
07:47	lamont	Keybuk: make users don't particularly care that time is accurate to within hours, they just care that it's monotonically increassing
07:47	jdub	mdz: that'd be great
07:47	mdz	jdub: bounty?
07:47	jdub	mdz: yeah
07:47	Kamion	without regular ntpdate, time is at least approximately monotonic. :-)
07:47	mdz	jdub: someone from gnome?
07:47	pitti	sabdfl: rather than cron, wouldn't /etc/network/ifup.d/ make much more sense? I. e. for dialup users
07:47	jdub	mdz: yes
07:47	sabdfl	can we use ntpdate to nudge the clock syncing algorithms in the right direction?
07:47	Kamion	sabdfl: that's more what ntpd's for really
07:47	Keybuk	sabdfl: ntpd is the clock-syncing algorithms
07:47	jdub	mdz: have a candidate for quite a few of these
07:47	lamont	sabdfl: all ntpdate does is yank time to the current time
07:48	mdz	ok, so that's on the bounty list
07:48	lamont	ntpd slews the local clock to keep it there
07:48	elmo	if the problem is the open port, can't we just bounty someone to fix that?
07:48	mdz	next up is speeding up the boot process
07:48	elmo	or is it inherent to ntp's design?
07:48	Keybuk	elmo: that's because ntpd uses udp, isn't it?
07:48	mdz	Keybuk: yes, but it could still be improved
07:48	Keybuk	mdz: didn't you rewrite hotplug in Perl?
07:48	mjg59	ntpdate can make the clock run backwards and confuse everything
07:48	mdz	Keybuk: yes, and then reverted it because perl needs /usr
07:48	sabdfl	*cough* *splutter*
07:48	Keybuk	mdz: I'd be tempted with a little C parser for that
07:48	mdz	Keybuk: yes
07:49	mjg59	If you're running slow, ntpdate will make your screensaver come on
=== enrico leaves the meeting
07:49	mdz	Keybuk: but ssshh, before sabdfl insists that it be rewritten in python :-)
07:49	enrico	Please reach me in the next days if you need anything
07:49	sabdfl	"faster"
07:49	mdz	mjg59: that seems like a bug in xscreensaver
=== enrico [~enrico@81-174-12-206.f5.ngi.it] has left #ubuntu-meeting []
07:49	mjg59	ntpd just makes your clock go faster or slower until it reaches the right time
07:49	Keybuk	speed is really critical for it, and the last thing you want is to haul Perl or Python into memory ... that's not going to be hugely faster than shell
=== martinald [~hm@martinalderson.plus.com] has joined #ubuntu-meeting
07:49	mdz	Keybuk: hauling perl into memory was a big win
07:49	mjg59	mdz: The results from gettimeofday() suddenly change...
07:50	sabdfl	is hotplug very complex? why not bounty a C implementation?
07:50	Keybuk	sabdfl: *shrug* I could do it in a few hours
07:50	mjg59	I'm off home - back in 15 minutes or so
07:50	mdz	sabdfl: it's not very complex at all
07:50	Keybuk	I'm reasonably sure I wrote one and have it on my disk somewhere
07:50	sabdfl	Keybuk: go for it
07:50	mdz	but it's easier to maintain in shell
07:50	Keybuk	in fact, I *know* I wrote one
07:51	sabdfl	is it the shell that makes it slow?
07:51	mdz	it's the fact that it uses shell *exclusively* that makes it slow
07:51	sabdfl	or is it hardware delays?
07:51	Kamion	sabdfl: parsing in shell tends to be slow, you have to fork lots of processes
07:51	mdz	I suggest that we rewrite certain bits in C
07:51	mdz	and not the whole thing
07:51	sabdfl	i thought they put in a deliberate delay to avoid some race condition in specific kernel versions
07:51	Kamion	it's just the modules.pcimap parser isn't it?
07:51	Keybuk	mdz: I was thinking the pcimap etc. parsers
07:51	mdz	Kamion: that's most of it, yes
07:51	mdz	Keybuk: exactly
07:51	mdz	that's what I rewrote in perl
07:52	doko	we could use ash as /bin/sh to make things a bit faster.
07:52	mdz	and saved about 0.3 seconds per device
07:52	Keybuk	and I know I wrote one for i-d; so I've just got to find it
07:52	mdz	another item under the same heading is starting gdm earlier
07:52	daniels	mdz: as I mentioned before
07:52	mdz	that's a large perceived performance benefit
07:53	mdz	I think we were in agreement that we should just do it
07:53	mdz	early on, and fix whatever breaks
07:53	daniels	you can start gdm as soon as you know the hostname won't change from under you
07:53	Keybuk	mdz: stick the hotplug parser under me, it'll give me something to do during test case runs :p
07:53	daniels	if the hostname changes under X, you're totally screwed
07:53	mdz	Keybuk: ok
07:54	mdz	need someone to take responsibility for gdm
07:54	mdz	since that's on the early breakage list
07:54	Keybuk	do we know how early it *can* be started?
07:54	daniels	might as well take that one
07:54	daniels	Keybuk: i have a very good idea
07:54	mdz	Keybuk: I've started it as the first thing in runlevel 2
07:54	mdz	with on il leffects
07:54	Keybuk	it probably needs all the Utopia stuff for when the user logs in
07:54	mdz	no ill effects
07:54	mdz	daniels: ok, yours
07:55	mdz	next up, we have some kernel stuff
07:55	mdz	which I think is probably bounty-oriented
07:55	pitti	Keybuk: hal must be running, the other stuff is gnome session
07:55	Keybuk	mdz: I have it at 21 ... I needed alsa, dbus and fam loaded first
07:55	mdz	oh, speaking of dbus
07:56	mdz	the other side of the start-gdm-early coin is displaying startup notifications for the things that start after it
07:56	mdz	with a little dbus magic
07:56	daniels	mdz: usplash
07:56	mdz	overlap with usplash
07:56	mdz	yes
07:56	daniels	mdz: (the usplash daemon just either writes out to the fb or X as is appropriate)
07:56	mdz	anyway, the next few items on the agenda are fixing the various warts in how we load kernel modules
07:56	daniels	personally, i think that is wholly subsumed by usplash
07:56	mdz	the fact that IDE stuff doesn't Just Work is the big one
07:57	mdz	also figuring out the right strategy for drivers which are no longer autoloaded with udev
07:57	mdz	unless anyone here has a strong interest and the domain knowledge for it, I suggest it be a bounty
07:57	Kamion	having mount load loop when needed would clean up a lot of user questions
07:57	fabbione	mdz: bounty
07:58	thom	mdz: agree
07:58	Kamion	but yes, bounty
07:58	mdz	Kamion: having it autoloaded somehow, whether it's mount's job or something else's needs to be determined
07:58	seb128	bounty yes
07:58	mdz	" Go back to the LiveSeed? idea to provide a more demonstration-worthy LiveCD?"
07:58	lamont	mdz: that has a pre-req of "make liveCD seeed fit..."
07:59	jdub	that's probably a non-issue given the size of the livecd + winfoss bits
07:59	mdz	this seems to raise the question of whether we want to try to make the live CD snazzier than the default desktop
07:59	Kamion	if LiveSeed is a strict subset or superset of each of the other seeds, that's fine, otherwise tricky in germinate
=== oOpepinOo [~yann@lns-vlq-39f-81-56-131-220.adsl.proxad.net] has joined #ubuntu-meeting
07:59	jdub	i think we do
07:59	jdub	for instance, i'd like to have a package of demo files
07:59	mdz	as you say, I don't think we can add much due to space constraints
07:59	Kamion	desktop-plus-some-stuff-from-supported would work
07:59	daniels	live dvd?
07:59	Kamion	(or desktop-minus-some-stuff)
07:59	mdz	Kamion: yeah, that's what it'd be
07:59	jdub	Kamion: yeah, +/- would be good
08:00	jdub	but all within supported
08:00	lamont	jdub: but not both
08:00	ogra	daniels: wont work in cd roms
08:00	Keybuk	- ttf-baemuk! </lamont>
08:00	Kamion	but if we want to add some bits from supported and take away pieces, the germinate-fu gets complicated
08:00	sabdfl	do we have space?
08:00	lamont	sabdfl: after tossing celestia, I think we're at 650MB or so
08:00	jdub	sabdfl: winfoss makes it hard
08:00	mdz	sabdfl: it's very tight
08:00	sabdfl	then i vote for parity between livecd and installed
08:00	lamont	643MB
08:01	jdub	anyway, this could be a derivative livecd
08:01	jdub	for demos
08:01	sabdfl	yes
08:01	jdub	and stuff
08:01	mdz	I think we should probably leave the package list alone for hoary
08:01	mdz	for the live CD
08:01	mdz	i.e., match desktop
08:01	jdub	sabdfl: parity for the official livecd, yeah
08:01	sabdfl	we could well have derivatives in place for hoary
08:01	lamont	jdub: maybe a demoCD which puts your cool hoary packages in insead of WinFOSS?
08:01	mdz	" Optionally encrypted home directories that work out of the box (MartinPitt?)"
08:01	jdub	lamont: yeah
08:01	mdz	pitti: would you like to say something about this?
08:01	Kamion	partman was designed with support for encrypted filesystems in mind
08:02	pitti	I played around a little today with several implementations
08:02	pitti	I won't discuss them here, I will mail
08:02	Kamion	but it's not been implemented in partman yet
08:02	pitti	I just wnat to ask if there is consensus that we want support for it
08:02	lamont	I would like my USB dongle to automount after asking me for a passphrase...
08:02	mdz	pitti: I'm not sure exactly what it is
08:02	mdz	pitti: would this be cryptoloop stuff?
08:02	pitti	IMHO it would be a great thing for laptops
08:02	mdz	I think it's a lot of complexity for the default install
08:02	fabbione	pitti: i would like it hounestly
08:02	pitti	not necessarily cryptoloop
08:02	pitti	from the user's view nothing changes
08:02	Kamion	pitti: are we talking about having /home be a cryptofs, created in the installer?
08:03	sabdfl	not by default
08:03	pitti	if he logs in, his homedir is transparently decrypted
=== jdub likes the idea of crypto partition gui love, but not convinced about supporting crypto home stuf
=== Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has joined #ubuntu-meeting
08:03	pitti	Kamion: I think it needs installer support to have it from the beginning
08:03	Keybuk	crypto home sounds slow to me
08:03	Kamion	pitti: indeed
08:03	jdub	consider that people will go, "ooh! this smells like security!"
08:03	pitti	it should be optional
=== Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has left #ubuntu-meeting ["Leaving"]
08:03	Kamion	sabdfl: right, I don't think it's a default thing
08:03	pitti	It does not make sense for desktops
08:03	pitti	the user should deliberately choose it
08:03	mdz	I don't see why /home should be special
08:04	jdub	pitti: can we support it sanely?
08:04	pitti	we don't need to encrypt the whole partition
08:04	Kamion	partman may grow this sort of stuff if we just wait for the Anton Zinoviev machine to grind out code :-)
08:04	mdz	if you want encryption, it should be across the board
08:04	pitti	encrypting just some files or directories is actually less hassle
08:04	sabdfl	mdz: you know a user is around when you want to access it
08:04	doko	pitti: why not, but you would have to mount separate ones for /home/*
08:04	pitti	but it does not make sense to encrypt e. g. /us
08:04	pitti	I mean /usr
08:04	pitti	doko: not mount, just encrypt the directories separately
08:04	pitti	cryptoloop is not the only (and not the best) implementation
08:05	mdz	ok, let's discuss this on ubuntu-devel and hash it out
08:05	sabdfl	so to speak
08:05	pitti	so is there general interest?
08:05	mdz	sabdfl: har har
08:05	amu	Kamion: you cannot feeC[Cl the differents between a crypred dev and a normal. Computeres are too fast.
08:05	jdub	pitti: i'm concerned about supportability
08:05	pitti	That was the only question, I will work out details and bring it to the list
08:05	mdz	pitti: it's interesting, yes
08:05	mdz	whether we can and will do it depends on the details
08:05	pitti	jdub: I will work that out
08:05	ogra	waht about repairing a broken FS pitti ?
08:05	sabdfl	pitti: it may be something i prefer a bounty / contractor to do, rather than internal resources
08:06	pitti	ogra: I don't see what's different. e2fsck does not care whether the data looks like garbage
08:06	pitti	sabdfl: your choice :-)
08:06	ogra	pitti im ean dd rescue on a broken disk i.e.
08:06	LeeColleton	WRT encryption.. will there be a GUI key manager for hoary?  The new seahorse goes a long way towards integration with the desktop.
08:06	pitti	If we want to do it inhouse, I would like to deal with it
08:06	pitti	ogra: of course the rescue copy will still be encrypted
08:06	mdz	LeeColleton: doesn't gnome-keyring-manager handle that stuff?
08:06	pitti	ogra: you need the same password to decrypt it
08:06	jdub	LeeColleton: (new seahorse will be considered)
08:06	jdub	mdz: no
=== mvo_ likes the idea of encrypted /home
08:06	ogra	but can i decrypt easily
08:07	jdub	mdz: that's for gnome-keyring (not gpg related)
08:07	bob2	mithrandir was working on some dm-crypt gui stuff, iirc
08:07	pitti	ogra: it is transparent
=== mjg59 is back
08:07	ogra	pitti: k
08:07	Keybuk	my god, we're nearly a quarter of the way though
08:07	pitti	ogra: it could be encrypted with your login password
08:07	pitti	ogra: and we need a PAM module for this, but there are solutions
08:07	ficusplanet	What are you guys thinking in regards to mono for hoary?
08:07	mdz	right, moving on
08:07	jdub	LeeColleton: (can you put it on the HoaryHedgehog/SupportedSeed proposals list please?)
08:07	mdz	if anyone has suggestions that are not already on the list, please discuss them on the ubuntu-devel mailing list after the meeting
08:07	jdub	ficusplanet: (we're working to an agenda, see HH feature goals)
08:07	ogra	pitti: as long as i can repair it with, say knoppix ....if nothing else is handy
08:08	ficusplanet	jdub, thanks
08:08	mdz	we have enough to discuss with what is on the list; the page has been open for suggestions for a long time now
08:08	pitti	ogra: depends on the concrete implementation. Repairing an fs is always possible, though
08:08	mdz	next up, kernel unification
08:08	mdz	this is herbert's domain
08:08	ogra	pitti: :)
08:08	mdz	I think we know exactly what needs to be done
08:08	jdub	mdz: (btw, are you modifying the page as we go?)
08:08	mdz	jdub: I'm making notes and will replace the page wholesale
08:08	LeeColleton	jdub: where is the proposals list?
08:09	jdub	mdz: ok
08:09	mdz	what about inotify?
08:09	jdub	LeeColleton: HoaryHedgehog/SupportedSeed
08:09	jdub	mdz: should definitely go in, something for herbert
08:09	mdz	jdub: has it been submitted upstream?
08:09	jdub	yes
08:09	jdub	not accepted yet
08:09	mdz	ok
08:09	Keybuk	inotify seems to be the way forward
08:09	mdz	framebuffer-based bootsplash is superseded by usplash
08:09	Keybuk	and it makes fam+portmap go away :)
08:10	jdub	(yay!)
08:10	Keybuk	(gamin does too, but it makes the whole problem easier)
08:10	Kamion	mdz: kernel unification> restricted-modules too
08:10	mdz	Kamion: hmm?
08:10	sabdfl	ANNOUNCEMENT: we got our first customer for a tech support contract today END ANNOUNCEMENT :-)
08:10	fabbione	cool!
08:10	lamont	WOOOHOOO!!!!!
08:10	seb128	yeah :)
08:10	ogra	congrats
08:10	mdz	sabdfl: EXCITEMENT wonderful! END EXCITEMENT
08:10	doko	canonical ltd? ;-)
=== mvo_ is happy about that
08:11	sabdfl	keep going :-)
08:11	Kamion	mdz: linux-restricted-modules and the udebs of same
08:11	mdz	Kamion: yes, includes that
08:11	mdz	I'll make an explicit note
08:11	sabdfl	w.r.t. kernel, i've discussed creating a six-month release of 2.6 for broader use than ubuntu
08:11	sabdfl	with herbert
08:12	mdz	which I think is a fantastic idea
08:12	jdub	rocking
08:12	sabdfl	it would be timed to our release schedule, since it's our core funding, but the idea would be to build a small community around it
08:12	sabdfl	for the smaller distros
08:12	doko	sabdfl: what does this mean? two kernel upgrades per year?
08:12	sabdfl	doko: yes, in a predictable release schedule
08:13	sabdfl	because at the moment, we have crack from upstream
08:13	mdz	moving on, we have a bunch of installer stuff
08:13	mdz	tops of which is the controversial gui installer
08:13	doko	nice idea, that would include the binary tools needed for restricted modules?
=== johnlevin [~johnl@dsl-80-42-84-143.access.uk.tiscali.com] has left #ubuntu-meeting ["Leaving"]
08:14	mdz	sabdfl: gui installer decision?
08:14	sabdfl	not for hoary
08:15	mdz	ok, pushing it back
08:15	mdz	kickstart
08:15	sabdfl	no problem starting down the road, balanced against hoary priorities
08:15	Kamion	GUI installer status: boots with much hackery, nothing too fundamentally painful; need debconf protocol extensions to make it be a good UI; will need coordination with #debian-boot folks; recommend starting early even if we don't finish for hoary
08:15	pitti	what's kickstart?
08:15	sabdfl	yes please!
08:15	mdz	pitti: unattended semi-custom installs based on a config file
08:15	Kamion	pitti: Red Hat mass deployment thing
08:15	jdub	kickstart == RH compatible pre-seed format
08:15	pitti	thx
08:15	mjg59	The RH implementation was moderately sucky when I played with it
08:15	sabdfl	does it have to be RH-compatible? would that be the hard part?
08:16	mjg59	Making it similar to RH would ease transition
08:16	Kamion	kickstart's specification looks remarkably similar to d-i preseed when you look at it; it says things like "if you don't answer a question, the installer will ask the user"
08:16	jdub	sabdfl: the format, yes; the data, no
08:16	Kamion	sabdfl: sysadmins of my acquaintance would kill for it
08:16	Kamion	RH-compatibility
08:16	mdz	I think the useful subset of RH-compatibility would not be that hard
08:16	Kamion	however, I believe that it's "just" a format translation job
08:17	jdub	kickstart generation guis already exist, etc.
08:17	Kamion	for the bits that usually vary between distros, sysadmins are already used to having different fragments for RH/SuSE, etc.
08:17	mdz	anyway, kickstart is something we'll do for hoary, but needs spec work
08:17	mjg59	Kickstart would be a very good thing to push back into Debian
08:17	Kamion	mjg59: yep
08:18	mdz	next up, the fancy keyboard selector
08:18	mdz	smells like bounty to me
08:18	Kamion	there's localization-config in Debian
08:18	fabbione	mdz: i will be very glad to get rid of X keyboard management
08:18	mjg59	(Regardless of the reality of things, some people are feeling like http://unstable.buildd.net/index-i386.html - obviously useful chunks of infrastructure make life better)
08:18	Kamion	that's Konstantinos Margaritis' work (Skole)
08:18	mdz	localization-config is like what we do now for X
08:18	mdz	the fancy selector is something much fancier :-)
08:18	Keybuk	fabbione: will X.org still work with the GNOME Keyboard Preferences stuff?
08:18	Kamion	ah, I thought l-c was better, haven't looked in detail yet
08:18	mdz	this is the thing which deduces your layout by having you type things
08:18	daniels	Keybuk: yes
08:18	Kamion	aha
08:18	mdz	and uses that to seed everything which needs keyboard layout info
08:18	fabbione	Keybuk: i don't know yet
08:18	mdz	console and X
08:19	mdz	it requires some fairly broad knowledge about layouts and their differences
08:19	fabbione	mdz: we use the same code for X now and it doens't look that good considering the bugs we got
08:19	mdz	fabbione: this is not the same thing, it is a different project
08:19	fabbione	mdz: we need to involve the console-data maintainer to do the right thing
08:19	daniels	the problem is the zero-question assumption
08:20	daniels	some people in the czech republic have us-layout keyboards
08:20	mdz	we will not guess as we do not
08:20	mdz	now
=== Peltoilves [~peltis@tolu.edu.hel.fi] has left #ubuntu-meeting []
08:20	mdz	we will ask once, and ask very thoroughly
08:20	daniels	right
=== siretart [siretart@meinungsverstaerker.de] has joined #ubuntu-meeting
08:20	mdz	ok, going on the bounty list
08:20	Keybuk	Language, Timezone and Keyboard are sensible questions to ask everybody
08:20	Keybuk	even MS ask them
08:20	mdz	hotplug installer we already covered as part of unifying hardware detection
08:20	Keybuk	though highlighting the most common answer is a win
08:20	fabbione	Keybuk: our problem is sync X and console
08:20	mdz	" support for multiple network devices of same type"
08:20	daniels	mdz: bountying out to someone with very good keyboard knowledge (of which there are very few) is recommended
08:20	mdz	Kamion: ?
08:21	Kamion	mdz: I don't know what that is?
08:21	mdz	neither do I
08:21	Kamion	mdz: maybe it's ISDN bonding or something
08:21	Keybuk	I thought hotplug solved that?
08:21	mdz	I certainly hope not
08:21	Keybuk	assuming he's talking about the 2.4-era of having to tell the module to create eth0 and eth1 type things
08:21	Kamion	mdz: whatever it is, it stinks of bounty or "wait for Debian to do it" to me :-)
08:21	jdub	might be refering to ifrename things
08:21	mdz	marking it as not-enough-info
08:21	mdz	" Option to set up proxy/authentication before attempting first apt-get update"
08:22	mdz	this one would require sabdfl approval to ask another question in every install
08:22	Kamion	the code's there, but it fell to the "fewer questions" axe
08:22	fabbione	mdz: we explicitly killed that question if we could reach archive.u.c
08:22	mdz	right
08:22	Keybuk	what's the loss with the way we do it now?  I thought we tested
08:22	mdz	but there has been user demand for it
08:22	Keybuk	fabbione: indeed, don't we test and then ask if it fails
08:22	Kamion	fabbione: but do we ever ask that question? I've never seen it
08:22	mdz	Keybuk: what we lose is caching proxies
08:22	lamont	just because I can reach a.u.c doesn't mean I want to go that path..
08:22	mdz	which is a big win for mass installs
08:23	mdz	sabdfl: ?
08:23	fabbione	Kamion: yes, we ask if we cannot reach archive
08:23	Keybuk	isn't that what custom is for?
08:23	Kamion	fabbione: I think that code might be buggy, because I would have seen that question.
08:23	fabbione	Kamion: but that happens with choose-mirror
=== ..[topic/#ubuntu-meeting:mdz] : Hoary kickoff meeting
08:23	lamont	fabbione: define "reach"
=== ..[topic/#ubuntu-meeting:mdz] : Hoary kickoff meeting || Agenda: http://www.ubuntulinux.org/wiki/HoaryKickoffMeeting
08:23	fabbione	lamont: wget a Package file or a Release.
08:23	fabbione	lamont: can't remember
08:23	lamont	ok
08:23	doko	tell the user to pull the plug if wants proxy support
08:23	mdz	ok, we'll leave this one as pending a decision, since the code is already there and just needs to be switched on
08:23	Kamion	let's file a bug on that and move on
08:24	mdz	" CD-based upgrade?"
08:24	lamont	doko: sadly, pulling the plug just means you don't get prompted for _any_ network source.
08:24	lamont	or does it....
08:24	mdz	the idea of that one would be to be able to insert a Hoary CD on a Warty machine and have an upgrade happen
08:24	Keybuk	mdz: would be nice if you could put the CD in and it do the right thing
08:24	Keybuk	should be pretty trivial too?
08:24	Kamion	is that apt-cdrom-style, or boot from CD (a.k.a. crack)?
08:24	lamont	as in auto-run?
08:24	mvo_	mdz: with some kind of auto-run?
08:24	mdz	Kamion: autorun type thing
08:24	mdz	Kamion: not boot from CD
08:24	Kamion	mmmkay
08:24	doko	lamont: anyway it would counter intuitive to pull the plug for configuring some network stuff ;)
08:24	mdz	we have no autorun in warty, but that'd be the general idea
08:25	jdub	autorun is off by default
08:25	fabbione	but do we have some sort of autorun in place that can take care of warty -> hoary?
08:25	mdz	double-click and have it run apt-cdrom, change sources.list and go
08:25	Kamion	right-click -> upgrade would be nice
08:25	lamont	mdz: sounds like something we'd add in hoary to take advantage of with grumpy, no?
08:25	fabbione	ok
08:25	mdz	lamont: we can do it for hoary, it's just a double-click rather than autorun
08:25	sabdfl	(re proxy conf, sounds useful in corporate setting, like kickstart, perhaps with a boot-time command)
08:25	Keybuk	lamont: make it an executable on the CD ... you put the CD in and run something on it
08:25	mdz	put something in the root of the CD called "DO THE UPGRADE PLEASE".sh
08:25	mvo_	mdz: I can take it
08:25	Kamion	sabdfl: you could easily preseed it
08:26	Kamion	sabdfl: (modulo tweaks to make sure preseeding works for that)
08:26	sabdfl	kamion: agreed, useful for those who need it, not necessary to ask otherwise
08:26	mvo_	fits with the upgrade-center idea that Mitario proposed
08:26	mdz	sabdfl: I don't think we talked about the CD-based upgrade; what's your opinion?
08:26	sabdfl	i like it
08:27	mdz	ok
08:27	mdz	I'm happy for mvo_ to work on it
08:27	sabdfl	"good to have"
08:27	mdz	it should be a fairly small project
08:27	sabdfl	not sure it has to be automatic
08:27	Keybuk	it should be pretty trivial ... the CD is an APT archive anyway
08:27	mdz	I think it would be very slick for it to be automatic, post-hoary
08:27	mdz	but anyway that's the easy part
08:27	sabdfl	not *too* automatic though :-)
08:27	mdz	as automatic as other autorun stuff, i.e. prompt for confirmation first
08:28	lamont	and sudo password
08:28	Keybuk	mdz: auto-run of binaries signed by a key in a keyring type thing?
=== Kamion mails sabdfl a batch of trojaned CDs, just for fun
=== sabdfl installs everything Kamion sends me, just for fun
08:28	Kamion	:-)
08:28	mdz	" Install libglide3 library when one of the supported 3dfx cards is detected"
08:28	lamont	Kamion: I was just going to burn one to carry around with me.. :-)
08:28	Keybuk	-> desktop seed suggestion
08:28	mdz	this has a question from Kamion next to it which doesn't seem to have been answered
08:28	mdz	daniels: do you know wha tit's about?
08:28	sabdfl	isn't libglide3 toxic^Wproprietary?
08:28	fabbione	mdz: it's not dangerous to install libglide3
08:28	mjg59	sabdfl: Not for years
08:28	fabbione	sabdfl: no
08:28	mjg59	3DFX GPLed it before going under
08:29	mdz	libglide3 is dlopened when using some cards or something?
08:29	mjg59	It's needed for DRI on Voodoo3/4/5/6
08:29	sabdfl	so let's make it part of X
08:29	fabbione	mdz: X uses it if the driver is 3dfx and if there is a compatible board
08:29	mdz	ok
08:29	mdz	so, yes, desktop seed suggestion
08:29	fabbione	mdz: yes, it's dlopened
08:29	mjg59	Yeah, it's utterly harmless
08:29	mdz	" installer bootable from floppy (for older systems that don't boot from CD/network)"
08:29	daniels	libglide3 is fine for desktopseed
08:29	bob2	fabbione: can it emulate GL?
08:29	mjg59	Except for its crackful build system
08:29	mdz	Kamion: ?
08:29	daniels	(sorry, just trying to figure out why my laptop's /home got shut down)
08:30	Kamion	mdz: that's fairly trivial, I only disabled it for warty because we didn't have time to test it
08:30	Kamion	we've had a lot of requests for it
08:30	fabbione	bob2: it is for GL
08:30	bob2	fabbione: ah. thanks.
08:30	mdz	Kamion: ok, added to the list of stuff to switch on early and start testing
08:30	mdz	" installer bootable from USB drive (for laptops without CD drives)"
08:30	mdz	that would be extremely cool
=== fabbione did it once
08:31	pitti	d-i boots nicely from USB
08:31	daniels	should work fine
08:31	Keybuk	another Kamion plaything
08:31	Kamion	pretty much likewise; I propose putting the netboot kernel and initrd in a form conveniently ddable to USB
08:31	fabbione	.. to bad i didn't have any device that could boot from USB
08:31	doko	nice to have it for our shop: memory stick preloaded with warty/hoary :)
08:31	Kamion	Debian supports this, but they do it by telling you to put a businesscard ISO on the USB stick
08:31	Keybuk	doko: you can fit warty on a Laks watch at the moment :)
08:32	Kamion	since we don't have businesscard ISOs and Warty won't fit on most sticks we need to take a slightly different approach, but it won't take long
08:32	sivang	500mb in it?
08:32	sivang	?
08:32	pitti	it works without an image, just the initrd and the kernel (and syslinux)
08:32	mdz	ok, let's take a brief diversion and talk about the laptop goals
08:32	Keybuk	sivang: 512MB
08:32	sabdfl	hmm... think we can keep hoary under 512MB?
08:32	mdz	because mjg59 can't stay much longer
08:32	pitti	My usbstick just needs 4 MB for a network d-i
08:32	mjg59	Sorry - feeling miserably unwell
08:32	jdub	sabdfl: unlikely
08:32	Kamion	(I have to go in about 40 minutes, BTW)
08:32	mdz	the big laptop goal is going to be suspend support
08:32	mjg59	Let's make this quick then
08:32	mdz	mjg59: what's our strategy for that, regarding ACPI vs. swsusp etc.
08:32	sabdfl	software suspend?
08:33	mjg59	Suspend to disk is fairly easy, with the possible exception of nvidia
08:33	mjg59	There's some drivers that could do with fixups, but in most cases that's straightforward (and it's major community love)
08:33	mdz	this is definitely something we should break early
08:33	mdz	what changes do we need to make?
08:33	mjg59	SuSE are shipping with swsusp enabled by default in 9.2, so there's no strong reason not to include it
08:33	mjg59	It's a kernel patch plus some modifications to let it work with initrd
08:34	mdz	mjg59: and also changing acpi-support to enable it by default?
08:34	mjg59	Yeah
08:34	mdz	what about acpi S3? do we care at all?
08:34	jdub	swsusp requires swap >= ram?
08:34	mjg59	S3 is, in almost all cases, preferable to StD
08:34	fabbione	what about all the problems we have with "boot with acpi=off"?
08:34	mjg59	jdub: No
08:34	mjg59	jdub: Except in extremely pathological cases
08:35	mdz	mjg59: so what will the default action be, for sleep button, lid close, etc.?
08:35	daniels	mdz: s3 is nice but really, really hard to get right
08:35	daniels	mdz: needs lots of testing and brute-forcing as to which modules need to get removed
08:35	Keybuk	s4 is too heavy-weight for lid close, I'd say
08:35	mjg59	mdz: S3 has an outside chance of being useful early enough for Hoary
08:35	daniels	mdz: i'm making acpi-support-x40 more generic, so we can just slot in different module lists
08:36	mdz	mjg59: what's the change that we'll make in the next week or so in order to start testing it?
08:36	sabdfl	"outside chance" is not something we should aim for
08:36	mdz	mjg59: swsusp?
08:36	mjg59	mdz: swsusp is in 2.6.9 and works well, but needs patching to work with an initrd rather than a monolithic kernel
08:36	sivang	I couldn't not spot the "excellent documentation" feature. is this going to be discussed here?
08:36	sabdfl	that sounds doable
08:36	sivang	being a hoary feature goal.
08:36	amu	mdz: you need double sawp as ram
08:36	amu	swap
08:36	mdz	amu: ??
08:36	sabdfl	sivang: let mdz set the pace
08:36	mjg59	amu: No
08:36	jdub	sivang: (we're not there yet)
08:37	sivang	ok, sorry.
08:37	amu	mdz: sw susp
08:37	mdz	sivang: we've skipped ahead to accomodate mjg59 having the plague
08:37	mjg59	There are three main issues with S3
08:37	amu	mjg59: no?
08:37	mjg59	1) hardware where it just doesn't work
=== silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting []
08:37	mdz	ok, it sounds like swsusp is what we should start testing for hoary
08:37	sivang	mdz : ok, we can always dicuss this on CC meeting
08:37	mjg59	The VIA craptop is an example of this. I'm working on it, mildly in touch with someone in Intel
08:37	mdz	and if good things happen with s3, maybe we can enable it on a case-by-case basis for some laptops
08:38	mjg59	2) hardware where it works but video doesn't come back
08:38	amu	mjg59: ok
08:38	thom	mdz: this kinda ties into the hardware db
08:38	mdz	" More flexible implementation of TRLS features (hal/dbus, etc.)?"
08:38	bob2	is swsusp the One True suspend-to-disk thing now?
08:38	mjg59	(2) is not easily solvable in the VESA case
08:38	mdz	what is that about?
08:38	bob2	ie will it support !i386 soon/now?
08:38	mjg59	3) individual drivers that don't work
08:38	mjg59	(3) is easily fixed on a case by case basis
08:38	mdz	mjg59: TRLS?
08:38	Kamion	bob2: as I understand it powermac support is RSN
08:38	thom	mdz: it almost certainly is !hoary - moving power management infrastructure to use hal
08:38	mjg59	More hardware for testing would be good. If I can sort the craptop, I'll produce kernel images.
08:39	jdub	trls == Totally Rad Laptop Support
08:39	thom	and then doing all the TRLS stuff over dbus
08:39	mjg59	I think that's post-hoary
08:39	mdz	we really ought to fix that
08:39	mjg59	We need more hal support for platform devices first
08:39	mdz	as rad as it is, it's fairly hacktastic on the inside at the moment :-)
08:39	thom	mdz: yes.
08:39	mdz	what about the configuration side of it?
08:40	mdz	i.e., currently the user needs to hand-edit scripts in /etc to change the timeouts and such
08:40	mjg59	I'm inclined to go for suspend to disk on power or sleep button, and just try to blank the screen on lid close
08:40	mdz	especially that evil-cryptic hard drive timeout value
08:40	thom	mdz: well, that's the flipside - with a dbus/hal implementation, you could have a NetworkManager like implementation - user config frontend that talks to a backend daemon
08:40	mdz	mjg59: blank the screen and leave everything powered up?  that seems to cause lots of user surprises
08:40	amu	mjg59: there are some reports about swsusp.? i guess many brocken drivers, like cetrino wireless ;)
08:41	mjg59	mdz: Suspend to disk on lid close is hard
08:41	mdz	amu: they'll be fixed
08:41	amu	centrino even
08:41	mdz	mjg59: why harder than power button?
08:41	thom	so no need to mod stuff under /etc
08:41	Keybuk	mdz: stand up, shut lid, move to other table, open lid
08:41	mjg59	mdz: It's difficult to get most hardware to autoresume from swsusp on lid open at present
08:41	Keybuk	the time the lid is shut is often less than the time to actually suspend
08:41	mdz	mjg59: ah
08:42	Keybuk	(not to mention the technical reasons)
08:42	mdz	ok
08:42	mjg59	And we're still talking 20 seconds or so for resume
08:42	amu	mdz: something good for the liveCD
08:42	mdz	" Automatic /cpufreq module loading (possibly for desktop systems, too)"
08:42	mjg59	Sladen was working on that
08:42	mdz	I think the path forward for that is hotplug cpu support, is it not?
08:42	mjg59	It's straightforward - just need to map CPU to module, and then fall back to acpi
08:42	sabdfl	can we not do a delayed swsusp?
08:42	sabdfl	so if the lid stays closed for mor ethan 3 minutes, std?
08:42	mjg59	sabdfl: Yes - a timer on closed lid is practical
08:43	mdz	mjg59: what was he working on?  loading the right module based on /proc/cpuinfo?
08:43	mjg59	mdz: Yes
08:43	thom	mdz: yes
08:43	mdz	ok, sounds eminently doable for hoary
08:43	thom	can we bounty hotplug cpu support, and stay with sladen's script short term?
08:43	mdz	yes
08:43	thom	cool
08:43	mdz	" APM support selectable on install for laptops with missing/broken APCI support (BenjaminLong?)"
08:43	mjg59	Firstly, anything that doesn't support ACPI should have APM loaded
08:44	Keybuk	*shrug* that should be automatic
08:44	mjg59	At the moment, loads of people are having to add APM to /etc/modules by hand
08:44	mdz	sounds like early breakage to me
08:44	mjg59	There's no real downside to always trying to load APM
08:44	ogra	mjg59: i have a lap that has acpi but isnt supported
08:44	mdz	so we should start loading apm automatically whenever acpi is not active?
08:44	Keybuk	can't we load acpi, and then apm -- iirc apm will not load if acpi was loaded and worked
08:44	mdz	Keybuk: I think so
08:44	mjg59	mdz: If you try to load APM when acpi /is/ active, it'll just disable itself
08:44	mdz	what's the proper userland place to trigger apm loading?
08:44	mdz	oh, we have apmd in desktop
08:45	mdz	so apmd should start loading apm, it sounds like
08:45	mjg59	The apm init script could check for a /proc/acpi, and load apm if it's not there
08:45	mjg59	That's probably the easiest solution
08:45	mdz	ok
08:45	mdz	who will make the changes?
08:45	mjg59	Passing acpi=off then results in the right thing happening
08:45	mdz	to the apm package?
08:45	Keybuk	mjg59: why do you need the acpi=off ?
08:45	thom	i'll take
08:45	mdz	thom: yours
08:45	mjg59	Keybuk: If you have working APM suspend but no working ACPI suspend, for instance
08:45	mdz	mjg59: that's it for the laptop stuff
08:46	mjg59	mdz: Yup
08:46	mjg59	Rock
08:46	Keybuk	ok, I assume you don't need that for an APM-only laptop
08:46	thom	mdz: NetworkManager
08:46	mjg59	Oh, one thing - I have a limited range of hardware for this. Another test machine would be handy
08:46	mdz	thom: that's under a separate heading
08:46	thom	do we want to talk about this in relation to laptops, or seperately? (mjg59 has been looking at it, as have I)
08:47	jdub	separate, there's a big chunk of bullet points about it
08:47	mdz	only if there's a specific feature goal in it other than "package networkmanager and add it to desktop"
08:47	mjg59	Yeah, it's more useful on laptops than elsewhere but I think it's part of the big network autoconfiguration love thing
08:47	thom	k
08:47	mjg59	mdz: Thanks
08:47	mdz	I'm already thinking that we may need to adjourn and finish tomorrow
08:47	mdz	we have another couple of hours, easily
08:47	mdz	but let's blaze through as much as we can
08:48	mdz	language support
08:48	jdub	oh man, another 2am meeting tomorrow would kill me :)
08:48	daniels	mdz: one hit is good for me and the others at 2am
08:48	jdub	(it's 5am)
08:48	Keybuk	jdub: interfering with breakfast? :p
08:48	fabbione	mdz: i won't be able to be here tomorrow at this time
08:48	jdub	Keybuk: (i got up at 4am yesterday)
08:48	mdz	the big part of this bit is the backend infrastructure to pull things out of packages during the build cycle
08:48	mdz	which is a generic facility we may use for several things
08:49	doko	during build, not install?
08:49	mdz	this is high priority, so someone will be assigned to implement it
08:49	mdz	doko: right, during build
08:49	mdz	for example
08:49	lamont	mdz: 2400UTC?
08:50	jdub	part of it is just pulling stuff out
08:50	mdz	the basic idea is to create language packs
08:50	mdz	by extracting locale-specific data from packages
08:50	jdub	the tricky bit is pulling stuff out entirely, and making new packages based on it
08:50	pitti	even more trickier is that the stuff must not be put into the original packages any more, right?
08:50	mdz	so probably a debhelper component to do the acquisition of the data, a repository of some sort to hold it, and a system to make packages out of it
08:50	ogra	the printing system tied to the locale would be nice
08:50	Keybuk	you'd have to do it somewhere between binary and signing the changes
08:51	doko	detect thing in /usr/share/locale and build new packages from that, add to the control file the new packages and add conflicts to the old package?
08:51	mdz	Keybuk: you'd do it before even creating the .deb
08:51	jdub	mdz: debhelper means lots of patches
08:51	mdz	jdub: why?
08:51	Kamion	jdub: good
08:51	Kamion	:-)
08:51	jdub	hrm, unless it was built in to an existing debhelper module
08:51	mdz	jdub: it would be a separate module
08:51	Kamion	I don't think that something this invasive should be silent as far as the source package is concerned
08:51	fabbione	dh_builddeb could call it
08:51	jdub	mdz: so surely that means lots of patches against modules
08:51	mdz	it wouldn't even necessarily have to be debhelper-compatible, but it would be used in the same way
08:51	lamont	mdz: and many things don't build-dep debhelper...
08:52	Kamion	otherwise users will have a hell of a time building packages
=== Keybuk makes a note to be on holiday at hoary->grumpy merge :p
08:52	mdz	jdub: why does a separate module imply patches to existing modules?
08:52	lamont	Keybuk: trivial to automate, no? :-)
08:52	Keybuk	mdz: to change debian/rules ?
08:52	jdub	mdz: patches to packages
08:52	mdz	lamont: packages which use this facility should probably do so explicitly and build-dep
08:52	mdz	trying to intrusively hook into the process this way sounds rather insane
08:52	jdub	mdz: debian/{rules,control}
08:52	mdz	jdub: yes, right
08:52	lamont	mdz: so you don't mean _all_ packages, just those with locale compoinets?
08:52	mdz	jdub: I was talking debhelper modules
08:52	mdz	dunno
08:53	mdz	I think this needs a real design discussion
08:53	lamont	definitely
08:53	mdz	but it also needs someone to take the lead
08:53	jdub	lamont: it gets pretty close to all, given gnome (locales separation and .desktop extraction)
08:53	pitti	sounds interesting
08:53	Kamion	jdub: there are lots of unlocalised and don't-need-to-be-localised packages below the desktop
08:54	Kamion	libraries instantly spring to mind
08:54	jdub	yeah
08:54	mdz	.desktop extraction is significantly easier
08:54	mdz	beacuse it's a tiny amount of data
=== Keybuk tries to think of an unlocalised library
08:54	mdz	we don't need to exclude it from the .deb at all
08:54	Kamion	wouldn't this be easier with arch-for-everything?
08:54	seb128	Kamion: most of gnome libs are localised
08:54	mdz	Kamion: not for locale data; it's generated at build time, no?
08:54	doko	are desktop extractions worth to put in an extra package?
08:55	jdub	Kamion: lots of this has to be done after build
08:55	Kamion	mdz: you could generate it from the .po files in the same way, I'd've thought
08:55	mdz	ok, I don't want to have the design discussion now
08:55	Keybuk	doko: not for an extra package, for a smart "Add/Remove Programs" app
08:55	pitti	mdz: well, if the stuff is extracted into an extra package, it shouldn't be in the original deb any more
08:55	Keybuk	mdz: it's a must-have from sabdfl isn't it?  so should be punted to design later
08:55	jdub	pitti: (.desktop stuff is a bit different, it'll go elsewhere)
08:55	mdz	the spec as it stands is that we want to have language packs which include the localisation data across the distribution, and exclude that data from the packages
08:55	mdz	the question in the table is who will implement it
08:56	Kamion	has anyone checked if all of these language packs will actually fit on the CD?
08:56	Kamion	they're going to be absolutely enormous
08:56	sabdfl	Kamion: won't ship all of them
08:56	Kamion	sabdfl: even one of them will be enormous :)
08:56	mdz	that, and they won't have any new data to start
08:56	mdz	we'll just be moving things from one package to another
08:56	pitti	mdz: I'd like to look at this
08:56	mdz	pitti: ok, yours
08:56	sabdfl	Kamion: don't we currently ship *all* translations?
08:56	lamont	this is all of french (say) for all desktop apps in one package?
08:56	jdub	mdz: (though it will include all of Supported translations too)
08:56	Kamion	sabdfl: no, see openoffice.org-l10n-*
08:56	Kamion	about 3MB per language
08:56	sabdfl	Kamion: right
08:57	mdz	jdub: I think we can separate supported from desktop
08:57	mdz	anyway, trying not to get into it
08:57	doko	sabfl: only for packages which don't have localization packages as extras
08:57	mdz	" excellent GDMLanguageIntegration? (selection of login language, selection of system languages)"
08:57	sabdfl	we'll only do this for the desktop package
08:57	sabdfl	s
08:57	mdz	we already can select the login language, no?
08:57	jdub	yeah
08:57	mdz	jdub: can you expand?
08:57	jdub	but not guiable
08:57	Kamion	if generated, yeah
08:58	Keybuk	all three of those sound like bounties
08:58	mdz	agreed
08:58	mdz	needs a spec, though
08:58	mdz	moving on
08:58	jdub	there's no way of configuring the GDM language
08:58	Sensebend	what is the target size of the next release?
08:58	Keybuk	Sensebend: single CD
08:58	mdz	Sensebend: one CD
08:58	Sensebend	so 650MB or 700MB?
08:59	Kamion	650, I think
08:59	jdub	but there is a list of languages - if configured - to choose from for your session
08:59	jdub	we need a gui way of choosing available languages
08:59	mdz	next up, documentation
08:59	mdz	any documentation team folks here?
08:59	mdz	hornbeck: hi
08:59	Sensebend	agreed jdub
08:59	jdub	and add gdm language choice to gdmsetup
09:00	jdub	(this should probably be shifted to desktop)
09:00	sivang_away	me also
09:00	mdz	python port of yelp -> bounty
09:00	sivang_away	:)
09:00	ogra	jdub: and disable it if there is only one lang ?
09:00	jdub	mdz: python port of yelp can be dumped for hoary
09:00	mdz	even better
09:00	sivang	jdub : have you talked with shaunm ?
09:00	jdub	yes
09:00	mdz	" Network Administrator's Kick Arse Rollout Guide (Re: kickstart)"
09:00	jdub	extensively
09:01	jdub	mdz: bounty
09:01	mdz	" Devhelp for Python development documentation love"
09:01	jdub	mdz: bounty, have candidate
09:01	mdz	" Ubuntu in a nutshell style booklet (JeffWaugh?)"
09:01	jdub	mdz: bounty
09:01	doko	jdub: what should be done?
09:02	mdz	we should have more documentation goals
09:02	mdz	but we can discuss them later
09:02	doko	for the devhelp thing?
09:02	sivang	mdz : any connection to redhet's kickstart?
09:02	mdz	the doc team can bring that together
09:02	sivang	redhat
09:02	mdz	sivang: yes, scroll back about an hour
09:02	Sensebend	Ubutu in a netshell sounds good
09:02	jdub	doko: just making python docs appear in devhelp
09:02	mdz	moving on
09:02	mdz	X.org
09:02	fabbione	yes
09:02	mdz	you are on it already
09:02	Sensebend	yes! to Xorg!
09:02	fabbione	yes
09:02	Keybuk	Go Team Denmark! etc.
09:02	fabbione	we are progressing slower than expected
09:02	mdz	high priority, get it in as soon as possible, fix what breaks
09:02	daniels	fabio and I are both on it
09:03	doko	jdub: let's talk about it later please
09:03	fabbione	mdz: read above
09:03	mdz	fabbione: what's a reasonable target date?
09:03	fabbione	mdz: we are facing more problems than i expected
09:03	fabbione	mdz: possibly end of novemeber
09:03	sabdfl	that's late
09:03	mdz	yes it is
09:03	fabbione	mdz: i am working 15 hours/day on it but i can't sustain this rithm forever
09:03	mdz	fabbione: it doesn't need to be perfect
09:03	mdz	but it needs to be in
09:04	fabbione	mdz: it doens't even compile
09:04	fabbione	i have bigger issues than having it perfect
09:04	sabdfl	fabbione: can we provide help in any way?
09:04	mdz	what about the work that daniels did back in August?
09:04	mdz	are you working from that, or from scratch?
09:04	fabbione	mdz: we are using all the things we have
09:04	fabbione	sabdfl: i will soon need (root) access to amd64 and ppc to test portability
09:05	mdz	fabbione: you will have it
09:05	sabdfl	fabbione: we have porting boxes available
09:05	fabbione	sabdfl, mdz: perfect
09:05	fabbione	there are bits that goes in very fast
09:05	fabbione	others are a real pain
09:05	mdz	fabbione: can we do it in stages?
09:05	fabbione	there is not much i can do about it
09:05	fabbione	mdz: ?
09:05	mdz	e.g., first transition the X server, and then the libs?
09:05	fabbione	what you mean by stages?
09:05	elmo	fabbione: err, why root?
09:05	fabbione	mdz: no
09:06	fabbione	elmo: i need to be able to install packages i build on the fly
09:06	daniels	elmo: install stuff
09:06	daniels	elmo: no longer a single monolithic package, remember
09:06	fabbione	elmo: otherwise i need you and/or thom available when i am working on it
09:06	fabbione	i/we
09:06	jdub	current xorg isn't split out, is it?
09:06	daniels	mdz: stepping it in will be more work than just crashing the lot in
09:06	daniels	jdub: upstream, no.  packaging, yes.
09:07	jdub	daniels: why?
09:07	mdz	splitting it out is less important than getting it in early
09:07	daniels	jdub: (why ... ?)
09:07	mdz	it is perfectly OK to have a monolithic package
09:07	fabbione	mdz: it's like the python scripts.. either we get from the beginning or we don't
09:07	mdz	that does not make sense to me
09:07	fabbione	mdz: and we will still face the same problems later
09:07	mdz	it is entirely a bulid-time problem
09:07	doko	splitting up a package is much work
09:07	jdub	fabbione: but it can be tested in the mean time
09:07	mdz	moving binary packages between source packages is easy
09:08	jdub	fabbione: or it can be split for grumpy
09:08	mdz	once upstream is properly split, we can split along the same lines
09:08	fabbione	mdz: we need to upgrade from Xfree and it doesn't make it easier
09:08	fabbione	there are hell of dependencies already
09:08	mdz	fabbione: source package layout does not affect upgrades
09:08	jdub	there are two big issues here
09:08	jdub	- managing the upgrade from xfree
09:08	jdub	- testing the software itself
=== MrTom [~thomas@84.97.17.128] has joined #ubuntu-meeting
09:09	fabbione	mdz: till a certain point.
09:09	jdub	splitting the package (for the packaging's sake) doesn't assist either of those
09:09	mdz	trying to split the source packages early is introducing a lot of unnecessarily complexity
09:09	mdz	s/rily/ry/
09:10	fabbione	mdz: we will only postpone the problem
09:10	mdz	we can afford to postpone that problem
09:10	mdz	we cannot afford to postone testing X.org in Hoary
09:10	jdub	fabbione: postponing until upstream does the split sounds great :)
09:10	fabbione	ok
09:10	fabbione	it's your call
09:10	jdub	xorg should be one of the first things to hit hoary
09:11	mdz	ok, let's delay the split
09:11	sabdfl	agreed
09:11	fabbione	jdub: it's not like i haven't been working for it
09:11	mdz	get something which builds the right binary packages so we can get it in and test
09:11	Kamion	OK, I have to go to beat people up^W^W^Wpractice peaceful martial arts now
09:11	mdz	fabbione: I understand, and I really appreciate your work
09:11	Kamion	back in two hours or less, if you're still going
09:12	fabbione	only portion of the patch forwarding costed me 30 hours of work if not more
09:12	daniels	upstream split is april/may
09:12	mdz	fabbione: we just need to make sure that we focus on the right priorities to make the release
09:12	daniels	which will defer our split to grumpy
09:12	jdub	fabbione: i grok - the split is a lot of work, and important for different reasons; thank you
09:12	mdz	split for grumpy sounds fine
09:12	mdz	we have lived with monolithic X for many years
09:12	mdz	another 6 months will not kill us
09:13	mdz	so let's establish a target for getting X.org uploaded
09:13	fabbione	well ok..
09:13	fabbione	monolitich tree will be
09:13	fabbione	i am not happy about this decision
09:14	fabbione	because it will make X drops still complex and slow
09:14	fabbione	but i have to accept the fact that we have deadlines
09:14	fabbione	dates will be asap
09:14	mdz	fabbione: what are the dates of the X sprint?
09:15	fabbione	daniels is coming here the 1st of nov until the 14th
09:15	mdz	ok
09:15	mdz	let's target array CD 3
09:15	mdz	November 15
09:15	fabbione	so we should be able to upload something usable for that time
09:15	mdz	ok
09:15	jdub	awesome!
09:15	mdz	" Enhanced GDM"
09:16	jdub	mdz: bounty, have candidate
09:16	mdz	" Process bugs and feedback from the WartyWarthog? release"
09:16	jdub	impossible
09:16	mdz	not a feature goal :-)
09:16	mdz	" GNOME 2.10"
09:16	mdz	seb128: all you
09:16	seb128	yeah, no problem
09:16	mdz	Easy package install GUI (JeffWaugh?, talking to RossBurton?)
09:16	jdub	mdz: bounty, have candidate, almost finished already :)
09:17	mdz	Security update notification GUI (MichaelVogt?)
09:17	mdz	mvo_: ?
09:17	mvo_	yes
09:17	jdub	mdz: depends on splitting .desktop files
09:17	mvo_	no problem
09:17	jdub	(easy package)
09:17	mdz	jdub: right
09:17	mdz	not worried about the .desktop files
09:17	fabbione	sabdfl, mdz, jdub: if there is nothing more for me i would like to go and get some dinner
09:17	mvo_	with update manager application
09:17	mdz	" Fax support via efax or the new gfax?"
09:18	sabdfl	fabbione: thanks very much!
09:18	jdub	not really worth a 'goal'
09:18	mdz	fabbione: by all means, thank you
09:18	jdub	but george farris is getting gfax ready for inclusion in hoary
09:18	fabbione	sabdfl: no! thanks to you!
09:18	jdub	gtk/mono-based
09:18	jdub	integrates with print system, etc.
09:18	fabbione	cya tomorrow
09:18	mdz	" Bluetooth GUI, with EddDumbill?'s packages"
09:18	doko	jdub: does it support ISDN devices?
09:18	jdub	ends up just being a package inclusion
=== sabdfl thought fabbione was offering to get me some dinner
09:18	fabbione	sabdfl: also!
09:18	jdub	mdz: edd wants to do those, ends up being a seed change
09:18	fabbione	sabdfl: welcome to join
09:19	fabbione	sabdfl: but the new kitchen will be ready in 2 weeks now :-)
09:19	mdz	Replace fam with gamin
09:19	jdub	mdz: seed change
09:19	fabbione	sabdfl: i am on microwave and sandwich
09:19	sabdfl	bluetooth will be important for the trls
09:19	mdz	jdub: does gamin exist?
09:19	jdub	mdz: already in universe
09:19	mdz	jdub: that's something we should get in as early as possible
09:19	mdz	ok
09:19	doko	so all the crowd is invited to cook pasta at your home? ;)
09:19	jdub	i have updated packages beyond warty ready to upload when i can
09:19	sabdfl	jdub: are edd's packages in a state to go in early and get user feedbackl?
09:19	jdub	sabdfl: they're in my repo
09:19	mdz	" Replace esd with polypaudio"
09:20	mdz	another early breakage item
09:20	jdub	mdz: seed change
09:20	mdz	jdub: oh?
09:20	jdub	already in universe
09:20	jdub	i would like you to review polypaudio
09:20	sabdfl	jdub: what's polyaudio's state in the gnome universe?
=== MrTom is now known as MrTom-away
09:20	mdz	hmm, I thought we were going for dmix
09:20	mdz	rather than a replacement sound daemon
09:20	jdub	sabdfl: installable, replaces esound
09:20	jdub	mdz: this gives us a sane option
09:20	sabdfl	g2.10 standard?
09:20	jdub	sabdfl: oh, sorry
09:20	mdz	jdub: esd-compatible or no?
09:20	jdub	i'm hoping that it will replace esound in gnome land
09:21	jdub	mdz: protocol compatible
09:21	jdub	mdz: apps will still use libesd
09:21	mdz	jdub: apps linked with libesd?
09:21	mdz	ok
09:21	mdz	I thought the plan was to get rid of the sound daemon concept entirely
09:21	mdz	and let alsa handle it
09:21	Keybuk	mdz: then what multiplexes the sound card?
09:21	Keybuk	alsa specifically won't handle it, and are going the other way and saying you need a multiplexer
09:21	jdub	mdz: dmix may be rough to configure automagically, has no config tools, and mean syou have to use libalsa for everything
09:22	bob2	Keybuk: dmix handles it
09:22	bob2	Keybuk: for libasound apps, at least
09:22	Keybuk	dmix is a multiplexer daemon though?
09:22	mdz	libalsa for everything is doable for desktop
09:22	jdub	Keybuk: no, part of liba*
09:22	mdz	most of it is there already
09:22	jdub	mdz: that's lots of bugfixing, dude
09:22	jdub	with uuuuugly alsa
09:22	sabdfl	also, alsa api got carrots
09:22	mdz	jdub: why is polypaudioi better than esd?
09:22	Keybuk	sabdfl: and in en?
09:23	jdub	mdz: much, much saner structure, easier to configure, better for sync sound, latency, etc.
09:23	sabdfl	"the alsa api received less-than-glowing reivews from warty team members who looked at it"
09:23	mdz	sabdfl: true
09:23	sabdfl	jdub: as in click, wait, ping!
09:24	jdub	mdz: probably a longer discussion involve dhere
09:24	mdz	yes
09:24	jdub	mdz: but i'd like to start by replacing esound
09:24	mdz	if gnome 2.10 is going with polypaudio , we'll start there
09:24	sabdfl	if it's in universe let's get it in asap
09:24	mdz	and then look into other stuff
09:24	sabdfl	i think we should communicate very strongly that hoary will spend large amounts of time BROKEN
09:24	mdz	polyp is on the early breakage list
09:24	sabdfl	then not fear breaking it
09:24	mdz	we're going to break everything at once :-)
09:24	mdz	dns-sd via howl (JeffWaugh?)
09:24	mdz	jdub: ?
09:24	jdub	mdz: gnome-vfs depends change
09:24	bob2	there's a huge number of basically newbies who want to move to hoary
09:25	jdub	mdz: brings howl into main
09:25	Keybuk	isn't that going to open a port?
09:25	bob2	you need to get that message out very very loud
09:25	Keybuk	deb http://break-my-computer-and-stamp-on-the-pieces.ubuntu.com/... :p
09:25	jdub	mdz: requires security analysis from you for mDNSResponder, and hopefully some configuration thingy to let mDNSResponder default to no-listen and switch to listen
09:25	mdz	this is going to be breakage of a scale never before seen :-)
09:25	mdz	debian has never broken this much at once
09:25	Keybuk	libc5 -> libc6 migration? :p
09:25	mdz	jdub: the listening switch sounds like a bounty sort of thing
09:26	jdub	mdz: (we could just not install mDNSResponder by default to start with)
09:26	mdz	Keybuk: that's one thing
09:26	jdub	mdz: agree
09:26	mdz	just happened to affect lots of pakcages :-)
09:26	jdub	mdz: in which case, have candidate
09:26	sivang	mdz : true, but sid's small , harder to notice breakages also stung :)
09:26	Keybuk	mdz: in sufficiently incompatible ways that it wasn't *bootable* for long periods :p
09:26	sabdfl	jdub, mdz, how are we going to resolve the fundamental difference between "rendevous (howl) is awesome" and "don't listen by default"?
09:26	mdz	jdub: I'll mark it for further discussion, we'll break it down
09:26	mdz	sabdfl: require the user to check a box to turn it on
09:27	Keybuk	sabdfl: put them in a ring and let them fight it out?
09:27	jdub	sabdfl: by taking your clothes, tying you to a chair, and... oh, or providing a configuration item to turn it on
=== sabdfl thinks this sounds just like boarding school
09:27	Keybuk	jdub: can we have a cups configuration next to that?
09:27	jdub	Keybuk: i think this ends up being part of our 'services configuration' thingy
09:27	jdub	Keybuk: bounty ;)
09:27	mdz	the CUPS configuration thing sounds simpler; it should just open up its port when you're looking to add a printer
09:27	jdub	Keybuk: plus discussion ;)
09:27	mdz	no point in sitting around listening all the time
09:28	mdz	improved panel:
09:28	mdz	jdub: ?
09:28	jdub	mdz: bounty, have candidate
09:28	sabdfl	how does cups know when someone else on the network wants to install a printer?
09:28	mdz	accessible by default + include a11y packages? (JeffWaugh?)
09:28	mdz	sabdfl: we're talking about the client end of it
09:28	mdz	the print server will have a port open all the time
09:28	Keybuk	mdz: I was talking about the server end
09:28	jdub	mdz: dump as official goal, leave to community and 'research and development' derivative
09:28	mdz	but the thing we disabled was that the client currently needs a port open all the time in order ot browse
09:28	sabdfl	right
09:28	mdz	Some kind of reasonable video playback support (Fluendo's DVD Player?)
09:29	sabdfl	so "share printer" makes you a print server, and slightly vulnerable, but it's your option
09:29	jdub	mdz: requires further discussion
09:29	mdz	User management (e.g., select whether new users should have local device access or not)
09:29	mdz	pitti: ?
09:29	pitti	mdz: yes :-)
09:29	mdz	this is a patch to g-s-t, right?
09:29	doko	that's a pam thing?
09:29	pitti	mdz: in gnome system tools?
09:30	mdz	pitti: yes
09:30	mdz	a small one, I think
09:30	mdz	pitti: will you do it?
09:30	pitti	mdz: yes
09:30	mdz	Remote desktop and rocking terminal support with  NX? (TollefFogHeen?)
09:30	jdub	(we could bounty the author on that one, too)
09:30	mdz	Mithrandir is not here
09:30	mdz	anyone know what that's about?
09:30	jdub	integrating nomachine nx
09:30	jdub	definitely an attractive goal
09:30	ogra	in vino
09:30	jdub	no, just generally
09:31	jdub	not related to vino
09:31	mdz	which is some sort of vnc-ish thing?
09:31	sabdfl	low-bandwidth x
09:31	bob2	super-low-bandwidth X
09:31	ogra	mdz: way faster
09:31	Keybuk	NX is "make my X go really really fast"
09:31	Keybuk	(over a network)
09:31	sabdfl	combined with ltsp, will rock
09:31	daniels	yes
09:31	jdub	usually used for terminals, rather than sharing current session
09:31	daniels	parts of it are free, parts are non-free
09:31	mdz	X extension?
09:31	daniels	freenx is a 500-line shell script to tie shit together
09:31	daniels	no
09:31	mdz	or separate protocol?
09:31	jdub	special server
09:31	daniels	runs a proxying, caching server
09:31	amu	mdz: ... woorks with a goof compression, working with a modem line is very very fast compared to vnc
09:32	mdz	what's involved in the feature for hoary?
09:32	daniels	separate protocol/server, also interoperates with os x and windows if you buy their product
09:32	mdz	packaging the thing?
09:32	jdub	yeah
09:32	daniels	packaging, yes
09:32	sabdfl	daniels: what parts are non-free, and can it be usefully used as entirely free config?
09:32	jdub	packaging + seed
09:33	mdz	who will do the work?
09:33	jdub	perhaps leave it for tollef to answer
09:33	doko	can do it
09:33	jdub	he has already done bits
09:33	daniels	sabdfl: i believe you can get an entire freenx setup with free licences
09:33	mdz	ok, will check with tollef
09:33	mdz	Attempt to standardise on process elevation method throughout GNOME
09:33	tseng	knoppix already includes bits of freen
09:33	tseng	x
09:33	sabdfl	and the non-free stuff is what? optimised?
09:33	jdub	mdz: not convinced it's a useful goal for hoary
09:33	mdz	punting
09:34	mdz	Thought: Replace Gnome's default palm only sync with  MultiSync? for syncing with many more devices? (BenjaminLong?)
09:34	jdub	mdz: can do as bounty for grumpy, can think of potential candidate
09:34	Keybuk	whoever wrote that is on crack, multisync doesn't work with evo 2.0, only 1.4
09:34	sabdfl	sounds like a gnome job, not a hoary job
09:34	daniels	sabdfl: i think most of their integration is non-free but there are hacks around that
09:34	jdub	multisync isn't ready for integration
09:34	sabdfl	"their"?
09:34	sabdfl	jdub: is it the platform to build on top of though?
09:34	mdz	we had proposed a bounty of getting it into shape
09:34	jdub	especially if intended as a replacement for current palm foo
09:35	jdub	sabdfl: potentially - needs a lot of work
09:35	Keybuk	I looked through multisync briefly and I wasn't impressed
09:35	sabdfl	is it actively maintained?
09:35	mdz	several apparently major bugs on the current palm-fu
09:35	jdub	the general idea is right, but lots of mess gui and implimentation wise
09:35	lamont	Keybuk: I played with evo sync briefly, was so impressed I went back to jpilot
09:35	mdz	if there isn't something there to build on, we can't do this for hoary
09:35	jdub	sabdfl: not in a very strongly directed fashion ;)
09:35	jdub	mdz: i'd say punt
09:35	jdub	mdz: people can love it in universe
09:35	sabdfl	ok, pass
09:35	mdz	" Better sounds: for example new mail sound, preconfigured correctly"
09:36	mdz	sounds like random criticism of the audio theme :-)
09:36	jdub	wouldn't want to commit to supporting it
09:36	sabdfl	pity, because PDA stuff is going to be very important
09:36	sabdfl	erm, that was me
09:36	tseng	evo sync to palm is an "almost works, sortof"
09:36	mdz	sabdfl: something we should do professionally?
09:36	doko	hmm, turning off single sounds in sound themes would be nice
09:36	sabdfl	we need to review every desktop app for sound integration so it all works well together
09:36	mdz	sabdfl: I know people who could do very slick sounds for us
09:37	sabdfl	like, thunderbird's new mail sound was just a beep post-install
09:37	sabdfl	mdz: great, ping me separately/
09:37	elmo	yay, someone do a slick sound that sabdfl can use on his damn jabber client ;-P
09:37	sivang	xchat's too
09:37	Keybuk	and gaim could do with something a little cuter than the fingers-on-blackboard ring
09:37	sabdfl	"hassole"
09:37	Keybuk	and gossip could do with something louder than its shy little peep
09:37	mdz	so this particular item is just about making sound events more integrated and consistent?
09:37	Keybuk	elmo: AWOOGA!
09:37	jdub	DIVE! DIVE!
09:37	thom	elmo: "WOO WOO"
09:38	sabdfl	can we do "sounds froma nudist colony"?
09:38	ogra	lol
09:38	jdub	sabdfl: 'slap!' 'squish!' etc?
09:38	mdz	what's the hoary piece of this?
09:38	thom	sabdfl: the "you can't show tits on the radio" theme
09:38	mdz	review all desktop apps and make them use sound consistently?
09:38	sabdfl	mdz: yes
09:38	jdub	mdz: bounty for sounds, fix badly chosen sound bugs in packages
09:39	mdz	sabdfl: just using a consistent set of sounds, or adding sound stuff where it isn't currently present?
09:39	sabdfl	(a) creating a good sound theme
09:39	mdz	e.g., stuff which just beeps
09:39	sabdfl	(b) making sure all apps which use sound are correctly integrated to the theme
09:39	sabdfl	so gossip and gaim could use the same sounds
09:39	sabdfl	thunderbird and evo
09:39	sabdfl	for new mail, new im, etc
09:39	mdz	ok
09:40	mdz	but if an app only supports the console bell, or no sounds at all, we leave it alone?
09:40	sabdfl	basically, file bugs on packages where there are sound theme inconsistencies or unusabilities
09:40	sabdfl	yes
09:40	mdz	ok
09:40	sabdfl	no bash sound theme needed
09:40	mdz	bounty?
09:40	mdz	(a) I have bounty leads
09:40	Keybuk	sabdfl: Gentoo ... it's only a matter of time
09:40	sabdfl	contract for the overall theme, bugs for apps that don't integrate
09:40	doko	"command not found" sound ...
09:40	mdz	(b) we need someone to do the review and file bugs
09:40	mdz	jdub: ?
09:41	sabdfl	i think once the team knows this is important they will file bugs
09:41	Keybuk	doko: "D'oh!"
09:41	jdub	mdz: hrm?
09:41	azeem	(about multisync, I read the people behind it work on a sane replacement called opensync, which is supposed to by a fd.org standard)
09:41	Keybuk	azeem: what isn't these days?
09:41	daniels	hosted at fd.o, don't know how much movement there's been.
09:41	jdub	azeem: yeah, opensync is pretty far from ready
09:41	daniels	hosted != standard
09:41	mdz	ok, so we won't make this an official goal, and just file bugs
09:41	sabdfl	sync punted -> grumpy
09:42	mdz	Improved network integration?
09:42	mdz	NetworkManager
09:42	Keybuk	thom?
09:42	mdz	thom: you're packaging it?
09:42	azeem	daniels: I asked about multisync for an unrelated matter, and found a post by one of the guys saying a first opensync preview release was imminent
09:42	mdz	assuming thom will take that one
09:42	sabdfl	thom was showing it off here last week
09:42	sabdfl	looking pretty good
09:42	sabdfl	needs to be integrated with the broader picture of ifup ifdown
09:42	thom	sorry
09:42	thom	yes
09:42	jdub	lots of opportunities for NM integration in various programs
09:43	jdub	like evolution, etc.
09:43	mdz	thom: all of the sub-goals under that heading have been moved under networkmanager
09:43	mdz	thom: is that accurate?
09:43	mdz	we don't need anything else?
09:43	jdub	some patches have already been written by RH dudes
09:43	mdz	what about, e.g., not bringing the interface up at boot?
09:43	thom	mdz: checking, but i think so
09:43	mdz	does networkmanager integrate with ifupdow?
09:43	mdz	ifupdown?
09:43	Keybuk	jdub: Colin's crusade against the "Network Error" dialog?
09:43	sivang	jdub : i.e ?
09:43	jdub	Keybuk: yeah (and clark's)
09:43	thom	mdz: not as yet, intend for it to do so soon
09:43	jdub	so beyond packaging, there's integration work to do
09:44	mdz	thom: will you take that on as well?
09:44	thom	not sure about zeroconf
09:44	sivang	mdz : and there's the trashing interfaces file when starting from skreatch no conffiles
09:44	Keybuk	is a good hoary goal
09:44	thom	mdz: yes
09:44	tseng	there is fixing to do in networkmanager itself before its ripe to be a core component
09:44	jdub	TRLS! Yeah!
09:44	mdz	hmm, there's stuff under there that is clearly no tnetworkmanager stuff
09:44	mdz	so, zeroconf -> hoary
09:44	mdz	Kamion: what about the wireless/installer bit?
09:44	mdz	oh, he went away
09:44	mdz	Don't ask for WEP / ESSID details during install if they are not really needed
09:44	mdz	probably just file a bug about that
09:45	thom	yep
09:45	sabdfl	plus, try the various essid's in of signal strength
09:45	mdz	IrDA
09:45	jdub	you're skipping the zeroconf bits?
09:45	mdz	does someone here care about IrDA? :-)
09:45	jdub	that sebastien added?
09:45	sabdfl	pass
09:45	mdz	jdub: I thought zeroconf was ->grumpy
09:46	sabdfl	what's the diff between zeroconf and howl?
09:46	mdz	I thought howl was an implementation of zeroconf
09:46	mdz	but surely there is lots of integration to do
09:46	jdub	sabdfl: howl provides implementations of the two sides of zeroconf
09:46	thom	sabdfl: howl is a zeroconf implementation
09:46	mdz	once we have howl, there are lots of things to hook it into
09:46	jdub	there is a NetworkManager/Howl integration possibility here, for local lan
09:47	sabdfl	is howl out there, and stable?
09:47	thom	you can get network details from zeroconf, which would need to tie into NM
09:47	jdub	plus there is the nss issue for .local
09:47	jdub	sabdfl: i package it
=== lamont gets dragged out the door by his wife, back in ~2 hours or so
09:47	jdub	sabdfl: it is a dependency of gnome-vfs already
09:47	sabdfl	ok
09:47	thom	that's another reason for new glibc, by the way
09:47	jdub	sabdfl: (not in warty)
09:47	thom	useful nameservice reloading stuff
09:47	mdz	ok
09:47	mdz	so what can we reasonable do with howl/zeroconf for hoary?
09:47	jdub	mdz: perhaps we should just talk about zeroconf issues between you, thom and i
09:47	mdz	s/able/ably/
09:47	mdz	-> further discussion
09:48	tseng	gnome-vfs support is as easy as a build
09:48	jdub	tseng: (already covered earlier)
09:48	mdz	Support users who don't want to use the restricted component
09:48	mdz	sounds like a couple of simple d-i changes
09:48	Keybuk	bug for kamion
09:48	mdz	will discuss with colin when he gets back
=== mvo__ [~egon@suprimo-131.ping.de] has joined #ubuntu-meeting
09:48	mdz	ia64
09:48	mdz	T-Bone is not here
09:48	jdub	mdz: there are some items under 'irda' that really shouldn't be there
09:49	mdz	jdub: good point
09:49	mdz	in fact nothing should be under irda
09:49	thom	hp are very kindly sending me an itanium workstation, so i can test d-i
=== mvo__ is back after network problems
09:49	mdz	backing up
09:49	mdz	" More robust mechanism for consistently-named network interfaces"
09:49	sabdfl	thom: ?
09:49	mdz	that would be doing ifrename right
09:49	jdub	i think NM covers that to a certain extent
09:49	mdz	oh?
09:50	jdub	yeah, it unifies a lot of that stuff
09:50	thom	(not, "they're sending me it to test d-i", but "they're sending me one; thus i can test d-i as a side effect")
09:50	mdz	" Unified DNS configuration (resolvconf or similar)"
09:50	sabdfl	thom: aha
09:50	jdub	NM may have an impact on that
09:50	mdz	sabdfl: they sent me one as well, some time ago, so no worries there
=== bob2 is totally on the wrong team
09:50	thom	that should happen through NM ideally
09:51	jdub	bob2: you get free trips to sydney for fish'n'chips!
09:51	mdz	we'll need to have a networkmanager meeting later
09:51	mdz	" Visual traffic indicators on panel network icons (so you can see when NIC or modem is busy)"
09:51	mdz	NetworkManager?
09:51	thom	new glibc can notify apps of nameservice changes AIUI
09:51	jdub	yeah ;)
09:51	Keybuk	and ugh
09:51	bob2	jdub: hah, indeed
09:51	sabdfl	i put that in
09:51	jdub	thom: and TZ! :)
09:51	thom	yeah
09:51	Keybuk	network is always busy, evil, distracting flashy icons
09:51	sabdfl	two things: first, the network stuff (wifi etc) should only be visible when it's meaningful
09:51	mdz	was that a yeah, networkmanager will do the blinkenlights?
09:52	jdub	mdz: yes
09:52	mdz	ok
09:52	sabdfl	and second, it's good to have evil, distracting, flashing icons :-)_
09:52	mdz	not by default, please
09:52	thom	NM will do wifi strength, not sure about traffic but it probably is trivial, will look
09:52	sabdfl	but seriously, often want to know if the network is busy or not, it's a common user perceptual reinforcement
09:52	Keybuk	sabdfl: but if you have a windows machine on the network, the light won't stop flashing
09:52	jdub	sabdfl: and common irritant ;)
09:52	sivang	isn't there already an applet for showing network traffic? I use one.
09:52	Keybuk	because they don't shut up broadcasting shit
09:53	jdub	sivang: there is, but NM centralises the configuration, etc.
09:53	sabdfl	jdub: i know which side i'm going to ask us to err on :-)
09:53	mvo__	siretart: netspeed?
=== Keybuk wonders what that wailing sound is
09:53	jdub	thom: i wouldn't be surprised if some of the gnome applets are fixed up to support NM
09:53	jdub	mvo__: ew, no ;)
09:54	sabdfl	thom: can nm appear as a notifier, rather than an applet?
09:54	mdz	what about sabdfl's network-applets-only-when-meaningful?
09:54	tseng	nm is a notifier
09:54	thom	sabdfl: it is  a notification applet
09:54	sabdfl	perfect
09:54	Keybuk	mdz: requires massive, total, unrelenting overhaul of gnome-panel and gnome-applets
09:54	jdub	mdz: NM does that
09:54	sabdfl	we need the same for battery
09:54	mdz	hahaha
09:54	mdz	conflicting answers
09:54	amu	should we also add support for handicapped people? i got some request for the liveCD some time ago
=== sivang is stunned to see mdz laughing :)
09:54	mdz	jdub: what's the right implementation overall?
09:54	thom	mdz: NM provides an API to find out whether you're connected to the network
09:55	mdz	should the applets run always, and not display anything unless appropriate?
09:55	thom	s/the/a
09:55	tseng	amu: we're followig the outline
09:55	jdub	mdz: can't answer that sanely
09:55	mdz	jdub: how do we implement what sabdfl proposed?
09:55	jdub	mdz: but NM has nicons that appear per-network-interface
09:55	jdub	mdz: NM
09:55	Keybuk	mdz: doesn't work ... the applets hook to the panel via bonobo so if they run they display stuff ... if they don't display stuff they aren't run
09:55	mdz	jdub: battery
09:55	mdz	sound
09:55	mdz	other stuff which is not network
09:55	jdub	mdz: well, there's battfink which did that to start with
09:56	tseng	there is battfink and another notification for batter
09:56	tseng	iirc nat did one
09:56	sabdfl	Keybuk: need to be able to run them, and have them display nothing if there's nothing to tell
09:56	sabdfl	can an applet be converted to a notifier easily?
09:56	Keybuk	sabdfl: have chatted about this upstream with the gnome people
09:56	Keybuk	our general feeling is to convert the entire panel to a notification area
09:56	jdub	mdz: but in this case, using existing battstat code to run a nicon would be a quick fix
09:56	Keybuk	and make all applets nicons instead of silly bonobo controls
09:56	Keybuk	though jdub wailed a bit, iirc :p
09:56	ogra	yay
09:57	jdub	Keybuk: no
09:57	sabdfl	the battstat icon is close to perfect for us at the moment
09:57	sabdfl	except that it shows on computers without a battery :-)
09:57	sabdfl	can we move on?
09:57	jdub	Keybuk: everyone wails at the idea of replacing applets with nicons, because it's the wrong thing to do (however, it is a simple way of moving toward what we want)
09:58	jdub	yes
09:58	sabdfl	i don't want to replace ALL the applets, just network and battery in our case
09:58	jdub	(was referring to upstream discussion)
09:58	sabdfl	mdz? next?
09:58	ogra	you shouldnt make gtik a nicon ;)
=== mdz snuck off to nibble on some food
09:59	sabdfl	busted
09:59	mdz	next up is ia64
09:59	mdz	but T-Bone isn't around
=== MrTom-away is now known as MrTom
09:59	mdz	he's going to run that show, right?
10:00	sabdfl	yes, we're not going to make it an internal problem
10:00	mdz	ok
10:00	mdz	TestingInfrastructure
10:00	sabdfl	beyond buildd's and no doubt some lamont-lovin#
10:00	mdz	huge framework needed here
10:00	mdz	bounty material
10:00	mdz	needs a detailed spec and some candidates
10:00	sabdfl	this one i think is worth doing internally
10:01	sivang	QA ?
10:01	sabdfl	we'll be living with it for a long time
10:01	mdz	true, lots of ongoing maintenance probably
10:01	mdz	QA indeed
10:01	sabdfl	and it is not something we can just drop out if it doesn't show up
10:01	mdz	this could keep someone busy for most of the hoary cycle
10:01	sabdfl	yes
10:01	mdz	ok
10:02	mdz	" APT package authentication (signed releases, apt 0.6)"
10:02	mdz	not a big deal if we do it early
10:02	jdub	wish we had some apt hackers on board
10:02	mdz	needs answers to a few PKI type questions
10:02	mdz	how we'll manage keys, etc.
10:02	sabdfl	mdz: fire away, oo
10:02	sabdfl	b
10:02	mdz	I think sabdfl/elmo/I had it pretty much sorted the last time we talked
10:02	mvo__	mdz: would like to help here
10:03	mdz	I'll put apt 0.6 on the early breakagae list
10:03	mdz	and get it uploaded ASAP
=== gro [~gro@u212-239-167-206.adsl.pi.be] has joined #ubuntu-meeting
10:03	mdz	mvo__: we'll need auth support in synaptic
10:03	mdz	and also in aptitude
10:03	mvo__	yes, I can do this
10:04	mdz	mvo__: aptitude as well?
10:04	mvo__	mdz: I'll contact daniel first, but I can do a patch if needed I think
10:04	mdz	ok
10:04	mdz	Splitting/removing files from binary packages we talked about already
10:04	mdz	bzip2'ed packages
10:04	mdz	Keybuk: ?
10:04	Keybuk	already on dpkg mainline
10:05	Keybuk	binary, anyway
10:05	mdz	Keybuk: early breakage
10:05	sabdfl	is it in warty dpkg?
10:05	mdz	no
10:05	Keybuk	sabdfl: no.
10:05	sabdfl	fuck
10:05	doko	is that decided? installation slowdown?
10:05	sabdfl	doko: not for all pacakges
10:05	mdz	doko: we will have the feature
10:05	Keybuk	bzip2 packages will need to Pre-Depend: dpkg (>= 1.10.24)
10:05	mdz	that much is decided
10:05	sabdfl	just stuff like languagepacks
10:05	mdz	Keybuk: when can you upload bzip2-enabled dpkg?
10:05	jdub	or we could defer bzip packages to grumpy, but get dpkg in
10:06	Keybuk	mdz: when can I upload?
10:06	jdub	(suppose it doesn't matter, really)
10:06	mdz	Keybuk: as soon as you're done with the merge?
10:06	mdz	dpkg seems to have 2 ubuntu revisions
10:06	mdz	afaik hoary is open for uploads now
10:06	Keybuk	mdz: yeah, one of those was amd64; the other hasn't been merged upstream
10:07	jdub	oh?
=== jdub tries
10:07	Keybuk	elmo: is my key in the ring again yet? :p
10:07	mdz	elmo is importing packages anyway; real uploads should not be far behind
10:07	mdz	anyway, that one is Keybuk's
10:07	mdz	" Some facility for installation of meaningful package groups? (tasks)"
10:08	mdz	Kamion suggested that we resurrect tasksel or a similar feature
10:08	mvo__	I would like to take this
10:08	jdub	some of that will be covered by app-install
10:08	mdz	yes, I think it makes sense to integrate the two into one
10:08	Keybuk	yeah, isn't this covered by Ross' gui
10:08	sabdfl	disagree
10:08	sabdfl	the nice slick app installer would likely look something like the win-foss gui
10:08	jdub	mdz: only some of the use cases are covered by app-install, not all
10:08	daniels	0609, good night.
10:09	sabdfl	simple, click here to get this app
10:09	Keybuk	daniels: nite, dude
10:09	mdz	daniels: night
10:09	sabdfl	tasksel is a different thing
10:09	mdz	they wouldn't be presented together
10:09	mdz	but backend-wise, there is a lot of overlap
10:09	jdub	sabdfl: app-install can also install sets of packages, such as "OpenOffice.org" -> implies a bunch of packages
10:09	Keybuk	sabdfl: is it though?  are click here to get "word processor" and "development environment" actually different?
=== sabdfl reconsiders
10:10	jdub	sabdfl: possibly things like "Web Development Environment" -> bunch of things
10:10	mdz	Keybuk: "development environment" has never been a useful task :-P
10:10	sabdfl	i'd like to keep that gui tool very basic and simple
10:10	jdub	it is :)
10:10	jdub	i'll send you sshots
10:10	Keybuk	oh, it should be very basic and simple
10:10	Keybuk	for complex task selection, synaptic should do that
10:10	sabdfl	sorry, aimed at "basic and simple users" and i'm not sure web development environment counts
10:10	mdz	honestly, I think that the app-installer and the security update notifier and the simple upgrader should be one app
10:11	jdub	sabdfl: "File Server"
10:11	mdz	that doesn't mean a complex ui; it could be a few separate UIs
10:11	jdub	mdz: agree
10:11	sabdfl	jdub: nfs, samba, ftp???
10:11	thom	agree with mdz; much simpler for users
10:11	jdub	sabdfl: there are lots of simple aggregate examples like these
10:11	jdub	sabdfl: but the only cover some of the use cases
10:12	sabdfl	hmm... security update notification will put a blinkenlight in the panel
10:12	sabdfl	that's all
10:12	mdz	and when you click on it...
10:12	Keybuk	sabdfl: something needs to happen when you click it :)
10:12	mvo__	it opens the update maanager
10:12	mvo__	:)
10:12	sabdfl	simple app installer is like our win-foss goodie, very simple, focused on end-user apps that are high quality but not general enough to be in the desktop install
10:12	sabdfl	like dia
10:12	Keybuk	this should all be effortless and obvious
10:13	sabdfl	and sodipodi (though i think inkscape might make it for hoary)
=== MrTom is now known as MrTom-away
10:13	ogra	whats wrong with inkscape ?
10:13	sabdfl	what's simple upgrader?
10:14	jdub	sabdfl: app-install does that delightfully, per spec we talked about at oxford
10:14	mdz	sabdfl: one-click system upgrade
10:14	sabdfl	shouldn't that be a simple view on synaptic?
10:14	jdub	no
10:14	mdz	maybe
10:14	sabdfl	jdub why not/
10:14	mvo__	sabdfl: could be, but it's desinged as a python app with synaptic as backend for now
10:15	mdz	mvo__: until synaptic is rewritten in python :-)
10:15	Keybuk	sabdfl: it effectively is as I understand it
10:15	jdub	sabdfl: because it's so much simpler
10:15	jdub	sabdfl: it runs synaptic to do the work
10:15	mvo__	so it only lists updates and gives you "proceed"
10:15	jdub	the frontend is pygtk
10:15	sabdfl	where is this beast?
10:15	mvo__	mdz: we'll do this later :)
10:15	azeem	why not make synaptic simpler?
10:15	jdub	sabdfl: sent by mail
10:15	sabdfl	ok
10:15	sabdfl	next
10:15	mdz	azeem: because package management is complex; synaptic offers a lot of power
10:16	mdz	we should not remove that power, but provide a simpler interface for simpler things
10:16	mdz	lm-sensors in main for hardware monitoring
10:16	mdz	-> seed change
=== MrTom-away is now known as MrTom
10:16	azeem	did you look at the red-carpet stuff from the ximian usability wizards?
10:16	mdz	hmm, and also fixing up the package
10:16	azeem	might be simpler
10:16	elmo	I thought we excluded lm-sensors 'cos the packaging was crackful?
10:16	mdz	to get rid of the 2.4 modules crap
10:16	jdub	azeem: it's about as complex as synaptic
10:17	mdz	I did a bunch of that for warty already
10:17	mdz	the source is in main
10:17	mdz	er
10:17	mdz	and yet it still build-depends on kernel-source-2.4.27
10:18	mdz	oh, wrong version
10:18	mdz	Build-Depends: bison, flex, librrd0-dev, debhelper (>= 4.1.16)
10:18	mdz	elmo: yeah, I fixed lm-sensors in ubuntu already
10:18	mdz	Binary: sensord, libsensors3, lm-sensors, libsensors-dev
10:18	mdz	so it's just a seed change
10:18	mdz	" resolvconf in main for managing resolv.conf with multiple networks"
10:18	mdz	covered under network magic
10:18	mdz	HardwareDatabase
10:18	mdz	(cue ominous music)
10:19	sabdfl	another biggie
10:19	mdz	yes
10:19	mdz	fun though
10:19	thom	cue thom running away and hiding
=== Keybuk is going to drop out now ... been a 14 hour day
10:19	mdz	sabdfl: bounty or no?
10:19	sabdfl	-cheers Keybuk
10:19	mdz	Keybuk: night
10:19	sabdfl	mdz: need to figure out who will use it
10:19	sabdfl	- fabbione
10:19	seb128	later Keybuk
10:19	sabdfl	- mjg59
10:20	mdz	- herbert
10:20	sabdfl	- sound config
10:20	thom	it should be interesting and doable - i've had some thoughts on the matter which i need to write up
10:20	sabdfl	kernel cant really adapt itself
10:20	mdz	that stuff will be very useful for the kernel
10:20	thom	sabdfl: which modules get loaded, acpi v apm, etc
10:20	sabdfl	right
10:20	mdz	which devices are present but unrecognized by hotplug
10:21	pitti	thom: do you think hal could be extended for such things? Or do you write another db?
10:21	thom	which modules to blacklist
10:21	mdz	I think using hal would make a huge project even huger
10:21	thom	pitti: different problem space, i think
10:21	elmo	oh, you mean that kind of DB
10:21	pitti	thom: hal 0.4.0 has a lot of extensions, though
10:21	elmo	I thought you meant ZDHW
10:21	mdz	elmo: ZDHW?
10:22	thom	elmo: it'd tie into zero day hardware, i think
10:22	jdub	ZeroDayHardWarez
10:22	mdz	isn't that the same as the hardware db we're talking about?
10:22	thom	pitti: a web DB?
10:22	elmo	mdz: ZDHW is user-orientated
10:22	elmo	(well it is in MY mind ;-)
=== MrTom is now known as MrTom-away
10:22	elmo	tho, there's certainly overlap
10:22	thom	can we move ZDHW/this to a different meeting? (is it a hoary goal?)
10:23	mdz	I envisioned a client app which would scan the system and ask questions, and upload the information to a central db
10:23	mdz	which would also have a web frontend
10:23	mdz	but mostly we would trawl it for information
10:23	mdz	the web frontend of that = ZDHW?
10:23	thom	mdz: i think so
10:23	sabdfl	could be linked :-)
10:23	mdz	yes, let's treat that separately
10:23	mdz	same database, different app
10:23	sabdfl	so there are several challenges
10:24	bob2	if you're going to ask people to send in info, the db results need to be open
10:24	sabdfl	(a) the design of the database (yay!)
10:24	mdz	I think the collection app is the first step
10:24	pitti	thom: ok, I think I misunderstood the purpose
10:24	sabdfl	(b) the app that collects the data
10:24	sabdfl	(c) figuring out what the data means
10:24	sabdfl	(d) integrating it with the scripts that autoconf the setup
10:24	sabdfl	like x, sound, network, etc
10:25	sabdfl	that's a lot of work
10:25	thom	yes.
10:25	mdz	yes, but we can do it in stages
10:25	mdz	first the db + app
10:26	sivang	wow, and auto bug reproduction system....
10:26	sivang	and=an
10:26	ogra	reproduction ?
10:26	sivang	according to what sabdfl just outline, so it sound like.
10:26	mdz	I think he means the possibility of finding people with similar hardware to try to reporduce bugs
10:26	mdz	which I think is a good application of the system
10:27	mdz	the user could volunteer their contact info so that we could ask them for help in testing
10:27	sabdfl	that's an interesting idea
10:27	ogra	souds good
10:27	thom	eww, that means storing contact info
10:27	sabdfl	make it a two-way flow
10:27	thom	RUN AWAY
10:27	mdz	thom: link to Person :-)
10:27	bob2	hahaha
10:27	jdub	hardware matchmaker!
10:27	sivang	each interested party would list his details on the bugdb, and when the need arise we politely ask him to test
10:27	sabdfl	thom, have you SEEN the database of DOOM recently?
10:27	mdz	jdub: your systems are compatible!
10:27	jdub	"i love matrox too! see you on friday!"
10:28	mdz	this stuff would be very interesting to summarize, too
10:28	sabdfl	"nice cpu's wanna ....'?
10:28	sivang	hahah
10:28	thom	sabdfl: no. but i do need to ask, have you looked into UK regs for personal data storage?
10:28	jdub	a/s/mhz?!?!?!!
10:28	mdz	hah
10:28	sabdfl	thom: hmmm... no
10:28	thom	(the legal stuff, i mean)
10:28	thom	you absolutely utterly need to
10:28	sabdfl	ok
10:29	sabdfl	not sure if we are technically in that part of the uk
10:29	mdz	we're going to store that stuff anyway, so that's not a problem specific to the hardware db
=== jdub attempts to upload to hoary...
10:29	sabdfl	jdub: x.org?
10:29	jdub	pre-emptive strike!
10:29	sabdfl	ok, moving on...
10:30	mdz	so thom, you're going to take on the hardware db?
10:30	mdz	with support from the rest of us, of course
10:30	sabdfl	no, let's have a separate meeting for that
10:30	mdz	ok
10:30	thom	mdz: can we have a sep meeting?
10:30	mdz	done
10:30	thom	*phew*
10:30	mdz	moving on
10:30	mdz	Derivative Distributions
10:30	mdz	what can we do in the hoary timeframe?
10:31	sabdfl	should have a lot of plumbing in place for christmas
10:31	sabdfl	at least for more adventurous / skillful candidates
10:31	mdz	this isn't specifically ubuntu stuff
10:31	mdz	unless you want to do the branding crack
10:31	sabdfl	-yes, exctly
10:31	mdz	it shouldn't require changes to the distribution itself
10:31	mdz	yes to branding crack? or yes to not specifically ubuntu?
10:32	sabdfl	yes to brandability of derivatives
10:32	sabdfl	which touches hoary
10:32	mdz	eek
10:32	mdz	touches?  molests
10:32	sabdfl	easy tiger
10:32	sabdfl	we only deal in mature packages
10:32	mdz	consenting?
10:32	sabdfl	able, certainly
10:32	mdz	ok, that needs a metting and a spec I think
=== MrTom-away is now known as MrTom
10:33	sabdfl	yes
10:33	mdz	meeting, even
10:33	thom	sabdfl: http://www.informationcommissioner.gov.uk/ for DPA stuff
10:33	azeem	compenentized linux made branding possible some time ago, and people seemed to like it
10:33	jdub	i'm thinking of making ubuntu-artwork divert a bunch of other art-related branding things
10:33	jdub	so you can just replace u-a for all of that
10:33	mdz	" Enforce main/universe separation on buildds (LaMontJones?)"
10:33	mdz	lamont: all you
10:34	doko	he's still away
10:34	mdz	ok
10:34	mdz	that's the end of the list!
10:34	jdub	yayayay
10:34	sabdfl	well done
10:34	mdz	thanks for hanging in there
=== jdub dances around like kermit
10:34	mdz	especially those of little sleep
10:34	jdub	26hrs!
10:35	doko	left out the launchpad integration
10:35	mdz	mako: can we get a transcription and summary?
10:35	bob2	jdub: V.
10:35	sivang	26hrs in a row?
10:35	mdz	doko: that's another meeting
10:35	sivang	??
10:35	jdub	bob2: sprite recharge ;)
10:35	bob2	jdub: hah
10:35	seb128	'night jdub :)
10:35	mdz	meeting adjourned, thanks everyone
=== mdz ices his wrists
10:36	sivang	thank you
10:36	bob2	4:35, hard core
10:36	mvo__	thanks mdz
=== jdub goes to pay attention to pipka
10:36	thom	g'night
10:36	seb128	'night thom
10:36	sabdfl	cheers all, thanks mdz
10:36	pitti	night
10:36	doko	thanks for the moderation
10:36	seb128	'night everybody
10:36	mdz	I'll write up my notes for the wiki
10:36	jdub	thanks mdz
10:37	sivang	night thom
10:37	ogra	thanks for enabling us to participate :)
10:37	sivang	mdz : you're gonna do this on the new wiki?
10:37	mdz	sivang: yes
10:37	mdz	a bit later, need a break
10:37	sivang	ah ofcourse
10:37	sivang	:)
10:38	jdub	new wiki hurts my brain :|
10:38	sabdfl	jdub: i'm thinking we should keep moin format as recommended default
10:38	jdub	sabdfl: what about the tables?
10:39	jdub	inline html, or...?
10:39	sabdfl	jdub: we got tables in
10:39	sabdfl	i don't like the moin format but we can handle it now
10:39	sabdfl	(moing table format)
10:39	jdub	oh!
10:39	jdub	cool
10:39	sivang	sabdfl : would it be ok of you to discuss things like wiki integration and other doc related stuff on CC meeting? or do you prefer it to be a seperate one?
10:40	sabdfl	sivang yes please put it in the agenda
10:40	doko	mdz: please put my name to the TestingInfrastructure thing, at least as a co-worker
10:40	sivang	sabdfl : ok np. I've already added to it
10:43	mako	mdz: yes
=== maskie [~maskie@196-30-111-250.uudial.uunet.co.za] has left #ubuntu-meeting ["Leaving"]
10:55	sivang	night all
11:00	Kamion	mdz: restricted/installer is trivial, it's a "file a bug and wait for Kamion to have a spare hour" routine
11:01	Kamion	mdz: TestingInfrastructure> have I already massively pimped joeyh's d-i autoinstall framework at you? it's awesome
11:02	Kamion	mdz: he's been doing full CD tests out of cron lately
11:02	Kamion	works with iLO, which IIRC we have on some of our boxes
=== MrTom [~thomas@84.97.17.128] has left #ubuntu-meeting ["Leaving"]
11:13	mdz	doko: ok
11:13	mdz	mako: thanks
11:13	mdz	Kamion: sounds very interesting, where can we get more info/
11:14	Kamion	mdz: svn://svn.debian.org/d-i/people/joeyh/autoinstall/ is probably the best place for now
=== Sensebend [~steve@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-meeting
=== hornbeck [~hornbeck@adsl-69-153-250-222.dsl.okcyok.swbell.net] has left #ubuntu-meeting ["Leaving"]
11:45	sabdfl	Kamion: we have iLO on the new itaniums, and please go ahead on the restricted-free option
11:47	elmo	nah, we don't, iLO is an x86 server only option
11:47	elmo	the Itaniums have something much less fun, called "MP"
11:48	Kamion	however joeyh also does have something going on ia64, may not be with iLO
11:48	Kamion	I think it's just netboot over serial console
=== tseng [~tseng@thegrebs.com] has left #ubuntu-meeting []

Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!