20070607
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
MeetingLogs/UbuntuDev/20070607 (last edited 2008-08-06 16:26:37 by localhost)