== Logs ==
TZ UTC+1
{{{
10:02	cjwatson	now where's mdz
10:02	Keybuk	stuck at the mercy of British Rail I'm afraid
10:02	Keybuk	https://wiki.ubuntu.com/DevelTeamMeeting20070607
10:03	Keybuk	let's get started while mdz is delayed
10:03	Keybuk	everybody here?
=== ogra waves
10:03	Riddell	I am
10:03	Keybuk	I see everyone from my team, Colin and Heno, everyone from yours?
10:03	agoliveira	The ones absent, please raise your hands!
10:03	heno	Keybuk: yep
10:03	cjwatson	Keybuk: yes
10:03	Keybuk	everyone from mdz's looks to be here too?
10:03	shawarma	Think so.
10:04	mathiaz	yop
10:04	Keybuk	so, we have some new people with us today
10:04	bryyce	yay!
10:04	Keybuk	keescook has returned from the IS team, and will be working on security, and filling in his spare time with some server work
10:04	keescook	\o/
10:04	mvo	welcome back!
10:04	asac	keescook: welcome back!
10:04	shawarma	Yay, keescook!
=== dholbach hugs keescook
10:04	keescook	thanks; I missed you guys.  :)
=== pitti hugs keescook, welcome back to distro!
=== agoliveira is sad for not being the "youngish" anymore :(
=== agoliveira just kidding
10:05	Keybuk	and heno has bravely stepped up to lead our QA efforts, and will be reporting to mdz and leading the new QA team; the first member of which is bdmurray
=== fabbione grins at new fresh blood in the team...
10:05	cjwatson	QA> there will be more
10:05	heno	indeed
10:05	bdmurray	that'll be nice
10:05	kylem	more quality? :P
=== keescook hugs heno, "congratz!"
=== dholbach hugs heno and bdmurray :-)
10:05	cjwatson	kylem: maaaaaaaaybe
10:05	pitti	Quality! Quality! Quality!
10:05	heno	I'm assigning bugs to all of you as we speak :)
=== keescook hugs bdmurray too
10:06	keescook	:)
10:06	Mithrandir	Keybuk: spare time?  What's that? :-P
10:06	dholbach	heno: python-launchpad-bugs FTW :)
=== heno looks ...
10:06	Keybuk	if everyone's read the agenda and reports, any further agenda items before we get started?
10:06	cjwatson	I encourage those of you with ideas or problems related to quality, bugs, etc. to make sure heno is aware of them so that he can include them in plans
10:07	heno	yep, tips and suggestions welcome!
10:08	Keybuk	aha, an mdz!
10:08	Keybuk	no longer at the mercy of SouthEastern trains, eh?
10:08	BenC	heno: please ping me when you have ample time :)
10:08	agoliveira	mdz_: hi boss
10:08	cjwatson	so no more agenda items; let's go on with those we have
10:08	mdz_	Keybuk: south west
10:08	cjwatson	Where is the right place to carry kernel /proc/sys settings? (kees)
10:08	cjwatson	historically this has been in procps, but I agree that the conffile merge is a bit nasty
10:08	Keybuk	keescook: so there's obviously /etc/sysctl.conf, but that's not really great
10:08	kylem	cjwatson, why not have an /etc/sysctl.d? :)
10:09	cjwatson	haha donk
10:09	Keybuk	there's the double-not-great there of also it only gets done once
10:09	cjwatson	nightmare ;-)
10:09	keescook	right, I already did the procps change, but I thought I'd double check
10:09	Keybuk	so if the sysctl is for a module, it won't take effect
10:09	heno	BenC: will do, thanks
10:09	cjwatson	Keybuk: interesting point
10:09	kylem	Keybuk, modules can't register sysctls iirc
10:09	keescook	aaah, yeah
10:09	kylem	it's a static kernel table.
10:09	keescook	so, this is (currently) for core kernel features.
10:09	kylem	i'm 99% sure...
10:09	cjwatson	BenC: are you willing to have your team take such patches?
10:09	keescook	I expect more, though
10:09	BenC	sysctl.d sounds like a good idea
10:10	Keybuk	kylem: /proc/sys/net/ipv6 ? :p
10:10	cjwatson	doko: welcome
10:10	mdz_	keescook: what's the use case you're trying to address?
10:10	BenC	cjwatson: which kind of patches?
10:10	BenC	for procps?
10:10	Keybuk	my thoughts in the past was indded an /etc/sysctl.d that would get re-run on each module load
10:10	kylem	Keybuk, good point.
10:10	doko	sorry, a bit late
10:10	keescook	mdz_: the use-case is me getting controversial security features into mainline kernel.
10:10	kylem	Keybuk, apparently maybe things have changed in the intervening 7 years since i cared about a sysctl :P
10:10	mdz_	keescook: which require boot-time initialization of sysctls?
10:10	keescook	I've been allowed to do it as long as I provide a /proc toggle
10:10	Keybuk	keescook: does the sysctl turn them on or off?
10:10	mdz_	ah
10:11	cjwatson	sysctl.d does sound a bit excessive to me though; .d usually means because multiple packages need to ship configuration
10:11	keescook	Keybuk: right.  for example /proc/sys/kernel/maps_protection (now in gutsy)
10:11	pitti	keescook: ah, such as enabling /tmp race protection and such?
10:11	BenC	I have to step out for 15, but maybe udev could handle the modular sysctl stuff?
10:11	cjwatson	BenC: right, things that we're setting in the default distro anyway in /etc/sysctl.conf at the moment
10:11	keescook	pitti: right, symlink races, and I can imagine there may be others
10:11	cjwatson	since we ship them that way by default, it's arguable that our kernel should just default that way
10:11	Keybuk	BenC: udev can set sysctls quite easily, since it knows when modules are added
10:11	BenC	cjwatson: we can do that, yes
10:12	kylem	are you proposing applying these from initramfs?
10:12	iwj	My autopkgtest-xenlvm needs to mess with sysctl.
10:12	BenC	Keybuk: right, my thoughts exactly
10:12	pitti	keescook: hmm, but sysctl.conf is a conffile, so why is that so painful?
10:12	iwj	That is, maybe people will hate it for doing so but it does anyway :-).
10:12	cjwatson	at present, we appear to set kernel.printk, kernel.maps_protect, and some dev.mac_hid stuff on powerpc
10:12	cjwatson	(the latter of which is mostly superseded by mouseemu now)
10:12	keescook	pitti: well, I just worry about people having to do a sysctl.conf merge on each upgrade
10:12	Keybuk	cjwatson: and all of net.ipv4.conf.*
10:12	iwj	I think a .d is the right answer.
10:12	keescook	and I'd hate to see people ignore the update and leave themselves open
10:13	cjwatson	keescook: even worse, it's a conffile with arch-specific contents
10:13	kylem	kees, why would this change more than once a stable release
10:13	mdz_	cjwatson: eewww
10:13	kylem	surely procps isn't going to have /that/ many bugs. :P
10:13	cjwatson	fortunately work in feisty means that can probably go away in the future, but still
10:13	keescook	kylem: it shouldn't, which is why I put it in currently.  I just thought I'd ask here where everyone can give me some ideas.  :)
10:13	pitti	keescook: hm, but in general that's true for every changed conffile; do you really think that so many people will care?
=== kylem thinks sysctl.d is sensible.
10:13	cjwatson	another problem with sysctl.conf or sysctl.d is that if sysctls go away and you don't merge conffile changes you get cryptic warnings on boot which look scary but aren't
10:14	pitti	anyway, I agree that setting those we care about by default in the kernel is a bit cleaner
10:14	cjwatson	what does sysctl.d buy us over sysctl.conf?
10:14	iwj	cjwatson: It lets my package not have to invent an init.d script which doesn't work properly because it runs too early.
10:14	mdz_	if we're changing the default, it should be changed in the kernel
10:14	Keybuk	cjwatson: takes away merge headaches
10:14	keescook	I'd probably like to see two things:  1) sysctl.d (to avoid merge pain)  2) sysctl not die when it tries to set a non-existing file
10:14	mdz_	and so no sysctl.conf modification should be required to stick with the default
10:14	iwj	And keescook's (2) too.
10:15	cjwatson	it sounds like there are a couple of different cases, one set of which (e.g. iwj's) are addressed by sysctl.d and others of which (the stuff procps is shipping by default) should be addressed by kernel patches
10:15	keescook	mdz_: that's was my thinking originally.  it's a 1 line patch to the kernel, and if people don't like it for some reason, they should _disable_ it with procps.
10:15	pitti	keescook: then it should at least cry out very loudly, otherwise you could miss important things
10:15	cjwatson	so I see no reason why we can't do both
10:15	pitti	keescook: I agree to 'disable manually'
10:15	keescook	pitti: right, it already cries loudly, but just bombs out
10:16	iwj	cjwatson: both> Mmm, perhaps.
10:16	mdz_	keescook: that's a bug
10:16	cjwatson	I never knew it bombed out; I thought it was just a warning
10:16	cjwatson	I agree that's a bug
10:16	pitti	keescook: at least initially we probably have to carry the entire patch and not just the 'flip it on' bit, right?
10:16	keescook	mdz_, cjwatson: perhaps I am wrong; I will double check and open a bug if needed
10:17	iwj	We could give it a new flag --don't-mind-unknown-ctls.
10:17	cjwatson	it doesn't currently document that it minds
10:17	cjwatson	oh
10:17	cjwatson	       -e     Use this option to ignore errors about unknown keys.
10:17	mdz_	we could add a --don't-be-stupid
10:17	iwj	I mean, to even suppress the warning.
10:17	keescook	pitti: I have been trying to get stuff into mainline.  the maps protection is in 2.6.22, so we only need to carry the "on by default" patch (1 line)
10:17	iwj	cjwatson: Oh :-).
10:17	Keybuk	sysctl --i-agree-that-this-is-not-a-benchma-oh-wait
10:17	fabbione	ROFL
10:17	shawarma	:)
10:18	mdz_	cjwatson: that should be the default when reading from a file
10:18	Mithrandir	Keybuk: "acknowledge".  Have to weed out the lousy spelers.
10:18	cjwatson	keescook: from the source, I think you are mistaken that it bombs out
10:18	cjwatson	it does exit non-zero, but it keeps going round the loop anyway
10:18	keescook	If I can get enough time, I hope to have ASLR taken upstream, but applied in our kernel (/me begs BenC)
10:18	pitti	keescook: ah, that one, yes; I thought we would finally include the /tmp race protection and so
10:18	keescook	cjwatson: okay, sorry for that bit.  ignore my (2) above.  :)
10:18	iwj	/tmp race protection> What, the thing where creating without O_EXCL in sticky dirs fails ?
10:19	keescook	pitti: yup, I imagine many things
10:19	iwj	Or something else ?
10:19	mdz_	keescook: I think that modifying /etc/sysctl.conf is rare enough, and the consequences of the merge are trivial enough, that we don't need to worry about it
10:19	keescook	iwj: can't follow symlinks not owned by you in a +t dir
10:19	pitti	iwj: following a symlink in world-writable directories fails if it isn't owned by you
10:19	iwj	symlink> Ah, helps a lot.
10:19	keescook	mdz_: meaning these things should stay in procps?
10:19	pitti	simple 10-line patch and very effective
10:19	mdz_	keescook: I don't see a problem
10:20	keescook	mdz_: okay.
10:20	mdz_	keescook: it's not as if something breaks if they miss the merge
10:20	iwj	ln -s /somewhere /tmp/.X11-unix ...
10:20	iwj	Still, we can say "use mount --bind".
10:20	keescook	mdz_: it doesn't break, but it leaves them "open" to this minor issue
10:20	mdz_	keescook: ...which they're already open to and have been for 30 years :-)
10:20	pitti	iwj: lots of daemons and scripts still use things like /tmp/$$ or even static names, right
10:21	keescook	well, it hasn't mattered in 29 of those 30 years because everything was statically located in memory.  :)
10:21	Keybuk	iwj: don't bind-mount anything /ish to /tmp :p
10:21	keescook	so, since stack/heap ASLR, this is an issue.  once text ASLR is done, the maps file becomes very valuable
10:21	Keybuk	the guy who filed *that* bug is still stalking me
10:22	mdz_	keescook: but one is still no worse off than one has been in the paste
10:22	mdz_	past
10:22	mdz_	the worst that happens is that one misses out on a new bit of sticky gooey protective measure
10:22	keescook	anyway, sounds like the norm is to put kernel defaults into procps, which is the answer I was looking for.  :)  right, they're no worse off.
10:22	mdz_	next?
10:23	Keybuk	Where do Ubuntu's non-stock ulimits come from? (kees)
10:23	Keybuk	PAM
10:23	Keybuk	she's an air-hostess who does UNIX security work in her spare time
10:23	keescook	so, pam has compiled defaults?
10:23	Keybuk	yeah
10:23	mdz_	Keybuk: and keeps things from sticking to the skillet
10:23	cjwatson	it does, but they don't match those keescook cites
10:23	Keybuk	I think everything is unlimited
10:23	Keybuk	bar a few things
10:23	cjwatson	nproc is unlimited in pam_limits, for instance
10:23	pitti	right, a longstanding bug
10:23	cjwatson	whereas keescook says it's 2048
10:24	Keybuk	I think kees is advocating a limit, not advocating its removal?
10:24	cjwatson	oh, hang on, you mean it should be 2048
10:24	keescook	well, my list is from what the kernel hands init
10:24	mdz_	there's a very, very old bug about this
10:24	pitti	$ ulimit -u
10:24	pitti	unlimited
10:24	pitti	right, 'provide sane default ulimits' or so
10:24	cjwatson	mdz_: bug#?
10:24	mdz_	looking
10:24	keescook	and I've seen a few places where don't want unlimited signals, locked memory, or user process.  I need to study the POSIX msg queue more
10:24	cjwatson	14505?
10:24	mdz_	it's something like "ZOMG UBUNTU VULNERABLE TO SHELL SCRIPT FORK BOMB"
=== Keybuk checks what limits init gets
10:25	Mithrandir	keescook: locked memory locked to 32kb sounds a bit on the slim side, though
10:25	mdz_	cjwatson: that's the one
10:25	keescook	Mithrandir: according to kernel comments, this is how much gnupg wants.  *shrug*
10:25	Mithrandir	keescook: hm, ok.
10:25	fabbione	we should be careful not to slam them too much down
10:25	keescook	but unlimited is clearly wrong it introduces yet another local DoS
10:25	cjwatson	keescook: feel free to poke pam (note that it uses a debian/patches-applied/ patch scheme)
10:26	mdz_	Mithrandir: it's enough for a password, which is as much as any typical application wants
10:26	keescook	fabbione: are you aware of other things that lock mem?  I've been told that the binary video drivers need it, but I don't understand why/where
10:26	mdz_	would make a good soft limit at least
10:27	Keybuk	core 0, prio 0, sigpending 3072, memlock 32, nofile 1024, msgqueue 819200, rtprio 0, nproc 3072
10:27	Keybuk	(everything else unlimited)
10:27	fabbione	keescook: no, and since we don't have good samples, that's why i suggest to trigger them down slowly to see where we break
10:27	Mithrandir	keescook: binary video drivers run as root anyway, I'd think?  Or do they mean GL memory is locked?
10:27	mdz_	keescook: seems like a good thing to switch early in the release cycle and see what breaks
10:27	kylem	keescook, if you use binary video drivers, security isn't one of your concerns...
10:27	mdz_	keescook: that's the best way to chase out the unexpected cases
10:27	keescook	Mithrandir: yeah, I'm not sure, I go poke at it with nvidia
10:27	mdz_	keescook: though a grep for mlock over the archive sources wouldn't hurt either
10:27	keescook	kylem: very good point.  :)
10:27	pitti	kylem: no, but if we have too restrictive defualt limits, their double-buffering etc. might break
10:28	kylem	pitti, seriously though, nvidia.ko has a "get root" ioctl...
=== BenC is back
10:28	pitti	kylem: yeah, and samsung printer drivers make your openoffice suid root
10:28	keescook	mdz_: so we maintain a set of unpack sources in the DC, or do I need to do a big step/unpack loop?
10:28	pitti	kylem: (no joke)
10:28	Mithrandir	pitti: that's the best thing ever.
10:28	kylem	pitti, ...
10:29	mdz_	keescook: we don't, afaik
=== keescook goes to buy some more drives
=== mdz_ mumbles about how it isn't even possible to get at unpacked sources in a standard way these days
10:29	fabbione	keescook: i have the space to do that here locally
10:29	cjwatson	kylem: bug 110724
10:29	ubotu	Launchpad bug 110724 in openoffice.org "OpenOffice runs as root for all users" [Undecided,Rejected]  https://launchpad.net/bugs/110724
10:29	mdz_	keescook: do yourself a favour and do it on a DC machine
10:29	keescook	and that bug has _duplicates_
10:30	keescook	fabbione: do I have access to "here"?
10:30	fabbione	keescook: i can provide that...
10:30	keescook	okay, cool
10:30	pitti	keescook: I still have some scripts to grep the sources of the entire archive
10:30	fabbione	keescook: or use the DC.. up to you.. just let me know
10:30	keescook	anyway, what do people think of the 2048 user process limit?
10:30	mdz_	pitti: that should go in a package somewhere
10:30	fabbione	keescook: that will break my builds
10:30	iwj__	~~
10:30	mdz_	keescook: I think it's perfectly reasonable
10:30	iwj	Excuse me.
10:31	keescook	yeah, i'll raise it for myself, but for an ubuntu default, it seemed better than unlimited.  :)
10:31	mdz_	fabbione: make -j should fail gracefully; if it doesn't, it should be fixed
10:31	pitti	mdz_: well, it only ever makes sense on the DC, and the scripts currently need hand-editing, but I'll look at generalizing them and maybe put them into devscripts or so
10:31	mdz_	not even fail gracefully. cope, rather
10:31	Keybuk	keescook: the default is 3072, why lower it?
10:31	fabbione	mdz_: ehhehe :)
10:31	keescook	Keybuk: your init values differ from mine a bit.  we'll compare notes later?
10:31	pitti	keescook: fabbione's 'make -j 300' is not what I really call 'reasonable default for normal users' anyway :)
10:32	Keybuk	keescook: I'm just reading from gdb before upstart's main loop <g>
10:32	pitti	Keybuk: default is unlimited for nproc
10:32	keescook	neither is my use of LVM.  :)
10:32	fabbione	pitti: nah.. that's history.. i am at an average of -l 4096
10:32	fabbione	-j even
10:32	keescook	Keybuk: ah, I booted with init=/bin/bash and did "ulimit -a"  :P
10:32	cjwatson	fabbione: I think you can raise your ulimits
10:32	Keybuk	keescook: what's the reason for wanting to apply limits anyway?
10:32	Keybuk	for a single-person machine, surely unlimited *is* the right default?
10:32	fabbione	cjwatson: yeah i guess i will have to
10:33	keescook	mostly local DoSs
10:33	Keybuk	why do we want to place limits on what an Ubuntu user can do
10:33	keescook	Keybuk: ^^
10:33	pitti	Keybuk: making processes which are gone wild not block the entire system
10:33	Keybuk	they'll have the same ffect
10:33	keescook	the aim is slightly more towards safer server installs
10:33	Keybuk	process goes wild => machine can't spawn new process to fix it
10:33	Keybuk	process goes wild and hits limit => still can't spawn new process
10:33	mdz_	Keybuk: bulletproof shoes
10:33	keescook	and these were a few things that stood out when comparing ubuntu defaults to other distros
10:33	pitti	Keybuk: they can, on a new console
10:33	Keybuk	mdz: I prefer paper bullets
10:33	pitti	Keybuk: AFAIK, nproc is per console, isn't it?
10:34	Keybuk	pitti: and how do we explain "new console" to non-server users?
10:34	mdz_	pitti: I don't think so
10:34	Keybuk	pitti: no
10:34	Keybuk	nproc is global
10:34	cjwatson	setrlimit(2) says it's per-uid
10:34	keescook	anyway, sounds like "yes, hunt and fix, culprit is PAM".
10:34	Keybuk	(remember, no root password, guys!)
10:34	pitti	ah, 'k; sorry for misremembering then
10:34	Keybuk	no logging in as root and killing the run-away process
10:34	cjwatson	Keybuk: I think they're screwed either way
10:34	Keybuk	cjwatson: exactly, so why limit users from doing legitimate things with no gain here?
10:34	cjwatson	I'm not sure that we gain a whole lot by taking away the lubricant
10:35	cjwatson	er, I mean I'm not sure that we lose a whole lot
10:35	cjwatson	Keybuk: legitimate users who need that can raise the limit, no?
10:35	keescook	I think it marginally helps multiuser systems.
10:35	Keybuk	does nproc cover processes or processes *and* threads?
10:35	pitti	Keybuk: anyway, right now the bash fork bomb instantly freezes the entire system; it can only get better
10:35	keescook	Keybuk: unsure about threads
10:36	cjwatson	I think there are much fewer of them, and that they're much more knowledgeable, than those who get screwed by accidental or malicious forkbombs
10:36	Keybuk	cjwatson: will we provide a gui to increase the limit?
10:36	pitti	gvim limits.conf (SCNR)
10:36	Keybuk	(I'm firmly a "0, 1 or unlimited" kinda man, sorry)
10:36	cjwatson	do you think that users who need several thousand concurrent processes require a gui?
10:36	bryyce	heh
10:36	Keybuk	cjwatson: I think that nprocs includes threads
10:36	pitti	well, '1' is not that bad either; worked fine in DoS :)
10:36	cjwatson	even so
10:36	pitti	erm, DOS
10:37	cjwatson	(yes, threads too)
10:37	mdz_	we do have the option of setting different defaults for server and desktop
10:37	mdz_	and more restrictive limits do make sense for servers
10:37	fabbione	that would be more sensible
10:37	Keybuk	yeah, I agree that this is right for server
10:37	Keybuk	just not desktop
10:37	Keybuk	desktops are by definition hundreds of processes with lots of threads each
10:37	keescook	Keybuk: you're speaking specifically about nproc?
10:37	pitti	but if we use sysctl.conf, we have to agree to a common limit
10:37	cjwatson	$ ps x | wc -l
10:37	cjwatson	110
10:38	cjwatson	this is a factor of at least 20 or so we're talking about?
10:38	keescook	pitti: I think they'd go in /etc/security/limits.conf in the end
10:38	cjwatson	I'm not convinced, I'm afraid
10:38	Keybuk	cjwatson: i just don't see the gain in changing it
10:38	mdz_	anything less than the maximum pid is an improvement
10:38	Keybuk	you're still screwed by a fork bomb
10:38	Keybuk	so what's the difference?
10:38	mdz_	Keybuk: not on a server
10:38	mdz_	where there are non-admin users
10:38	pitti	for me the gain is that right now you are definitively screwed on a fork bomb; with a limit you at least have a chance to recover
10:39	keescook	pitti: +1
10:39	cjwatson	at least accidental forkbombs may well stop and give you your system back once they hit the limit
10:39	Keybuk	cjwatson: you forgot the "m"
10:39	Keybuk	ps won't show threads by default these days
10:39	mdz_	Keybuk: I don't think nproc applies to threads anyway
10:39	cjwatson	a forkbomb that chews through your pid space will likely cause the OOM killer to kick in and then bits of your desktop start to disappear
10:39	cjwatson	Keybuk: given that most of my processes are non-threaded terminals, that's specious
10:40	Keybuk	cjwatson: more likely the fork bomb will keep pushing against the limit, and you have to reboot
10:40	Lure	mdz_: it does (according to setrlimit(2) manpage)
10:40	mdz_	Lure: is that pre- or post-NPTL?
10:40	Keybuk	nproc is counted for each clone(), no?
10:40	mdz_	date on the man page is 2005
10:41	cjwatson	I have 110 processes and 124 threads
10:41	mdz_	keescook: this is becoming a discussion which needs to be had on the mailing list
10:41	mdz_	we need to move on
10:41	keescook	mdz_: sure thing.  sounds like only nproc is contentious
10:41	mdz_	pitti: release update?
10:42	pitti	mdz_: it's out :)
10:42	mdz_	pitti: wow! way ahead of schedule
10:42	cjwatson	pitti: congratulations on Ubuntu 7.10, then
10:42	pitti	went pretty smooth, although I had to learn and struggle a lot with learning the engineering bits
10:42	mdz_	we were planning on october
10:42	agoliveira	:-D
10:42	mdz_	pitti: you should have a chat with heno about release-relevant bug tracking
10:43	pitti	mdz_: right, that's on the list already
10:43	pitti	so far we have about 5 or 6 for tribe-2
10:43	pitti	and a few for later versions
=== iwj double-checks the network connection.
10:45	Keybuk	fabbione: how is the hardware certification proceeding?
10:45	fabbione	Keybuk: started as scheduled.. no bugs so far but it's a bit early to say
10:46	fabbione	we are going to skip sparc for this round
10:46	fabbione	i found a last minute blocker
10:46	fabbione	and agreed with pitti to not release it
10:46	fabbione	but we have fixes on the way already
10:47	fabbione	that's about it from radio hardware-cert
10:47	fabbione	:)
10:47	mdz_	I think it would be good to publicize the test results from tribe-1 sometime before tribe-2
10:47	mdz_	on -devel or -devel-announce
10:48	cjwatson	merges: we have 30 outstanding, which need to be completed by 21st June
10:48	cjwatson	that's excellent progress for this point in the cycle, but we just need to get through the last few
10:49	heno	we need to add a feature to the USO tracker to make such reporting efficient
10:49	heno	Should be fairly easy to do
10:49	heno	*ISO tracker
10:50	bryyce	cjwatson: should the Updated Merges also be completed by the 21st?
10:50	pitti	bryyce: there will constantly be new ones
10:50	mdz_	bryyce: those are packages which have been updated since they were merged
10:50	pitti	those should be picked with some common sense applied, I think
10:50	bryyce	ok
10:51	mdz_	we can't be exactly up to date at the deadline, but we should be close enough
10:51	cjwatson	bryyce: no
10:51	mdz_	everything must be merged at least once
10:51	Keybuk	ish
10:52	Keybuk	those are packages which have been *uploaded* since the start of the release cycle
10:52	Keybuk	they may have never been merged
10:52	Keybuk	check versions
=== dholbach will try to keep an eye on universe/multiverse merges and make everybody aware of the deadline, although it generally looks quite good already
10:52	cjwatson	right, I know grub is in that camp
10:53	Keybuk	(it parses the changes file and looks at the intended distribution <g>)
10:53	Keybuk	if the last change was for the current release, it goes in updated rather than new
10:53	cjwatson	to clarify, we can still upload merges after the Debian import freeze, up to upstream version freeze; we just won't automatically sync every day or so
10:53	cjwatson	(if that confused you, ask me out of band and I'll be happy to clarify)
10:53	mdz_	speaking of grub, /me mumbles about bug 21412
10:53	ubotu	Launchpad bug 21412 in grub "Default update-grub behaviour is not intuitive with respect to user modifications" [Medium,Confirmed]  https://launchpad.net/bugs/21412
10:54	mdz_	that bug needs to die.  who will speak for the trees?
=== fabbione checks
10:54	Keybuk	(and I tend to turn a switch at DIF to change the word from "Outstanding" to "New" :p)
10:55	mdz_	it's bitten countless users and sysadmins, and now it's bitten Dell as well
10:55	mdz_	heno: let us make gutsy the release where it finally dies
10:55	Keybuk	is that the "you need to edit the comments?" bug
10:55	cjwatson	please check with me about installer implications; it's fiddly :-/
=== iwj waits for the bug to load.
10:55	mdz_	Keybuk: yes
=== heno makes a note
10:56	mdz_	cjwatson: might be a good idea to note that in the bug itself
10:56	cjwatson	it is a bug that requires careful design to make sure the result isn't just as bad
10:56	mdz_	in case the bug fairy comes by to fix it and wasn't in this meeting
10:56	mdz_	speaking of meetings, is there any other business for this one?
10:56	cjwatson	done
10:57	ogra	:)
10:57	mdz_	going once
10:57	mdz_	twice
10:57	mdz_	thrice...gone.  good night and good day and back to the battlefield with ye
}}}