[04:55] <zul> its not that early bluefoxicy 
[04:55] <bluefoxicy> uh
[04:55] <bluefoxicy> 11 am?
[04:56] <zul> still
[04:56] <mdz> morning
[04:56] <seb128> hello mdz 
[04:56] <bluefoxicy> heh, I have a problem waking up, it takes me several hours
[04:56] <bluefoxicy> normally I become concious at something like 8 or 9 am
[04:56] <bluefoxicy> and get up at 12 or 1 pm
[04:58] <lamont_r> bluefoxicy: what tz you in?
[04:58] <bluefoxicy> do I have time to make a glass of koolaid?
[04:58] <trulux> hi
[04:59] <bluefoxicy> lamont_r:  EST
[04:59] <zul> bluefoxicy, it still isnt early ;)
[05:00] <mdz> ok
[05:00] <trulux> hey pitti
[05:00] <bluefoxicy> heh
[05:00] <pitti> Hi trulux 
[05:00] <sivang> hey all
[05:00] <mdz> first agenda item is to talk about proactive security
[05:01] <mdz> is JohnMoser here?
[05:01] <bluefoxicy> yo
[05:01] <mdz> go ahead
[05:01] <mdz> what is the question which needs to be resolved?
[05:01] <trulux> pitti, umm, dunno if it's right to say it before the talk starts, but, i apologize of creating specific SELinux kernel packages
[05:01] <bluefoxicy> It's actually been trulux and pitti working on it mostly.  I'm not really in a position to talk about . . . whatever they're up to
[05:01] <trulux> ok, then let me start it
[05:02] <trulux> pitti, ready?
[05:02] <bluefoxicy> but with certain things such as Stack Smash Protection and PaX, a compatible or mostly compatible environment can be made in which many security flaws are resolved before they exist, for the most part.
[05:02] <pitti> sure
[05:02] <trulux> bluefoxicy, before they exist not, before they get known or even following a similar pattern
[05:02] <trulux> ;)
[05:03] <bluefoxicy> . . . yeah, let trulux and pitti explain it.  I'm just here because i want to see what happens about it, and I'd like to see an official statement soon, if not a roadmap.
[05:03] <trulux> that's because it's called proactive security, which also prevents so-called zero-day exploits
[05:03] <fabbione> trulux: well we have selinux compiled in already... it just question of a boot flag to enable it
[05:03] <bluefoxicy> yes
[05:03] <trulux> fabbione, i'm working on to get a desktop-ready SELinux system for Ubuntu
[05:03] <trulux> fabbione, also i'm the guy developing the 2.4 backport
[05:03] <fabbione> trulux: yeah but the kernel is ready already ;)
[05:03] <pitti> I publically announced the first PaX enabled kernels today
[05:04] <bluefoxicy> pitti:  sweet.  :)
[05:04] <mdz> pitti: great
[05:04] <trulux> fabbione, heh, sure
[05:04] <trulux> pitti, at this point i would like to make some comments
[05:04] <pitti> the kernels work mostly fine already. Still some caveats, but Itry to sort them out soon
[05:04] <pitti> trulux: go ahead
[05:04] <trulux> kay
[05:04] <mdz> so, with fabbione's selinux enabling and pitti's PaX kernel, 2 of 3 assignments from Mataro are complete
[05:04] <pitti> for my part I must say that I would welcome collaboration with hardened-debian
[05:05] <trulux> pitti, me too, and debhard devs would like to
[05:05] <trulux> so, this is what i think:
[05:05] <pitti> mdz: in fact I also digged a bit about what obsd and gentoo do
[05:05] <pitti> mdz: basically they use gcc-ssp, too
[05:05] <pitti> mdz: and obsd has something similar like PaX (W^X)
[05:06] <trulux> 1) we should try to create a team of people with some skills in open source and free software information assurance related software
[05:06] <trulux> that means:
[05:06] <trulux> having guys with kernel hacking skills, documentation skills, talking skills and *leading* skills
[05:06] <trulux> this is more than protecting buffer overflows
[05:07] <pitti> well, it's about improving general proactive security
[05:07] <bluefoxicy> pitti: yes, Gentoo uses an SSP GCC exclusively, which brings certain protections with it (variable order rearrangement) under all circumstances.  -fstack-protector is needed to activate the other protections; but both cases have fairly thorough testing.
[05:07] <pitti> ... and OpenBSD uses SSP for ages now
[05:07] <bluefoxicy> yeah
[05:07] <trulux> pitti, the point is that we are not just putting proactive security
[05:08] <pitti> as we already said, the main isseu with SSP is not the technical side, but the supportability over the whole distro lifecycle
[05:08] <trulux> from the oytside, people will know it as the way of having the information leak-proof
[05:08] <trulux> and secured
[05:08] <lamont_r> and the ssp croud has yet to provide a moduler set of gcc patches, aiui
[05:08] <pitti> as long as SSP is not upstream, it might become hard to support
[05:08] <trulux> so, they will think in moving to Ubuntu
[05:08] <trulux> for example
[05:08] <trulux> pitti, i've talked to Eoth, i would try to move some things to help with that
[05:08] <trulux> Etoh
[05:08] <pitti> and I was told that even Windows XP now has canaries on the stack (SSP-like)
[05:09] <bluefoxicy> pitti:  Etoh has tried to get SSP upstream, and they requested a current CVS patch, but I don't think it actually went anywhere.
[05:09] <mdz> trulux: if you aren't talking about proactive security, then please explain what you do mean
[05:09] <mdz> because the specific items we have discussed so far all fall under that heading
[05:09] <pitti> trulux: would you like to create SSP packages for universe now? The way we already discussed? 
[05:09] <lamont_r> bluefoxicy: I expect that they requested a _set_ of individual patches vs cvs-head
[05:09] <trulux> mdz, it's proactive security for us, information assurance for the users
[05:10] <pitti> which is basically the same
[05:10] <trulux> pitti, yes, but with different understanding points
[05:10] <trulux> i think i can do the SSP packages
[05:10] <trulux> sure
[05:10] <mdz> they're both jargon to the user
[05:10] <pitti> that'd be great
[05:10] <mdz> better to have a name which is more meaningful to the people who would be involved with it
[05:11] <trulux> mdz, i still like proactive security ;)
[05:11] <bluefoxicy> lamont_r: 
[05:11] <pitti> for the audience, the plan is to provide completely independent gcc-ssp packages in universe for now
[05:11] <trulux> pitti, but why separating the pkgs in -ssp and non-ssp brands?
[05:11] <pitti> so they can be used to play without interfering with the release process
[05:11] <mdz> pitti: a copy of the source?
[05:11] <bluefoxicy> lamont_r: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00348.html  Here's the thread. "It seems that your patch is against GCC 3.4.  Do you have a patch against current GCC CVS?" was never followed up.
[05:11] <pitti> mdz: so far this seems to be necessary
[05:11] <lamont_r> trulux: it's nice to turn the stack-overrun into a DoS instead of a root vul, but the users still don't consider DoS==secure
[05:12] <lamont_r> bluefoxicy: ok
[05:12] <pitti> mdz: unless trulux is able to "wrap" gcc with the protector, but I think that is difficult
[05:12] <pitti> lamont_r: it keeps your data secure, though
[05:12] <trulux> pitti, i will so my wrappers
[05:12] <trulux> show
[05:12] <mdz> if elmo doesn't hate the idea of duplicating the source too much, I think that it's a good idea to keep them as separate as possible
[05:12] <bluefoxicy> lamont_r:  I look at security as a user-friendly issue.
[05:13] <mdz> so that we don't interfere with the progress of the standard gcc
[05:13] <elmo> I don't much care, as long as we only do it once - ideally, we'd coordinate with doko and do toolchain-source sans crack
[05:13] <bluefoxicy> lamont_r:  If someone loads a worm onto my computer via a damaged .png image that then proceeds to get local root via a kernel exploit and then eat my hard disk, this is called 'pissing me off'
[05:13] <pitti> lamont_r: avoiding DoS is a matter of fixing the package, no way to get around this :-)
[05:13] <lamont_r> pitti: exactly
[05:13] <bluefoxicy> lamont_r:  a crash annoys me, but I don't need to worry about it eating my machine.
[05:13] <mdz> likewise for a broad class of vulnerabilities
[05:13] <trulux> lorenzo@estila:~/proyectos/hardened-toolchain-wrappers $ ls
[05:13] <trulux> hardened-gcc-wrapper-1.4.2.c  hardened-ld-wrapper-1.4.2.c  Makefile  suspect.c
[05:13] <trulux> lorenzo@estila:~/proyectos/hardened-toolchain-wrappers $
[05:13] <pitti> lamont_r: the point is just to confine the impact of holes
[05:13] <lamont_r> pitti: mind you, I'm all for security blankets, as long as we understand what they are.
[05:14] <mdz> things like SSP are about low-hanging fruit and maybe-good-enough solutions
[05:14] <elmo> yeah, I'm a little concerned about the propaganda I'm hearing to be honest - these things are at best a layer
[05:14] <lamont_r> mdz: agreed.  low hanging fruit are great to grab.  But calling the result "secure" is laughable
[05:15] <mdz> certainly
[05:15] <bluefoxicy> I did a quick analysis on how well this stuff would protect you.  http://www.ubuntulinux.org/wiki/USNAnalysis 
[05:15] <pitti> lamont_r: we talk about "improving" proactive security
[05:15] <mdz> this is "a feature which makes your system more difficult to attack"
[05:15] <bluefoxicy> SSP for example would carry about 40% of the torch
[05:15] <pitti> lamont_r: not reaching the ultimate goal :-)
[05:15] <lamont_r> then again, that's because the end users see security as an absolute, while we see it as a range
[05:15] <trulux> wait, can i show what i was meaning? it's just a moment
[05:15] <mdz> bluefoxicy: I have a feeling that figure is based on the assumption that SSP prevents all buffer overflows
[05:15] <trulux> we have both wrappers, one for ld and one for gcc
[05:15] <elmo> which it doesn't
[05:16] <trulux> i will upload the stuff and you could check it
[05:16] <bluefoxicy> mdz:  It's more based on the assumption that the classes of buffer overflows that SSP doesn't protect are very rare
[05:16] <pitti> mdz: SSP does not prevent buffer overflows, neither does PaX
[05:16] <bluefoxicy> mdz:  mainly, overflows inside structures with data above buffers
[05:16] <pitti> mdz: it just confines their exploitation
[05:16] <bluefoxicy> sorry pitti is right, it catches the attack at the end
[05:17] <mdz> pitti: yes, that's what I should have said
[05:17] <bluefoxicy> pitti:  doesn't it actually prevents their exploitation?  Things like SELinux confine it right?
[05:17] <mdz> s/prevents/addresses/
[05:17] <pitti> mdz: just to clarify for the audience :-)
[05:17] <pitti> bluefoxicy: yes
[05:17] <bluefoxicy> mdz:  attacks on SSP cannot be guaranteed uness you can find __guard in the GOT with a format string bug, or in the stack.  If you have PaX + ASLR, you need to inject code to read the GOT offset from a register (%efp) as I understand it
[05:17] <pitti> bluefoxicy: let's say, in most cases it prevents it, but there might be loopholes which still allow exploitation
[05:18] <bluefoxicy> and if you have active PaX with memory protections + ASLR, you can't really inject code to do that anyway :)
[05:18] <bluefoxicy> so it becomes on the whole a 1/4000000 guessing game any route you take
[05:18] <pitti> ^ that's what my kernels are for
[05:18] <bluefoxicy> pitti: yes, but in most cases there will be no possible way of guaranteed exploitation.
[05:19] <pitti> btw, PaX prevents executing stuff in writeable pages, so this closes the 1/400000 chance :-)
[05:19] <pitti> bluefoxicy: right
[05:19] <pitti> anyway, I don't think we need to discuss this stuff in the meeting
[05:19] <lamont_r> just because the code is normally in the stack doesn't mean it needs to be.
[05:19] <pitti> please leave the technical arguments aside here
[05:19] <mdz> yes, do
[05:19] <mdz> we don't need to have an extended debate about these techniques here
[05:19] <trulux> i agree
[05:19] <mdz> as I asked before, what is the decision that needs to be made by the board?
[05:19] <pitti> this should be more about cooperation
[05:19] <trulux> go forward to what we are talking about
[05:19] <bluefoxicy> lamont_r:  ASLR from PaX
[05:20] <pitti> lamont_r: sure, it leaves holes; as I said, nothing is perfect :-)
[05:20] <pitti> trulux: do you really think we need a formal statement right now?
[05:20] <pitti> trulux: so far our inofficial cooperation works quite nice, or not?
[05:20] <bluefoxicy> lamont_r:  you'd have to guess where the actual code exists.  You can defeat ASLR by injecting code, which takes us back to PaX' executable/writable separation.
[05:21] <pitti> I think we do need an official statement as soon as we officially support it
[05:21] <lamont_r> bluefoxicy: off topic
[05:21] <bluefoxicy> lamont_r:  yes, sorry, i'm getting ahead of the conversation.
[05:21] <mdz> if there isn't a decision to be made by the tech board, then we need to move on
[05:21] <trulux> pitti, yes, but i would like an official statement
[05:21] <mdz> so if there is, please speak up
[05:21] <pitti> trulux: okay
[05:22] <trulux> ok, let me package the wrappers and upload them somewhere
[05:22] <trulux> btw, it would be great to maintain a line of only pax+selinux packages
[05:22] <trulux> kernels with non-vanilla selinux/lsm stuff
[05:22] <pitti> trulux, bluefoxicy: what is your idea of an "official" statement?
[05:22] <trulux> for ex.
[05:23] <pitti> trulux, bluefoxicy: as already said, we don't need to discuss the technical details here. Just the strategic ones
[05:23] <Kamion> if no-one is going to answer mdz's question, perhaps this discussion could move elsewhere.
[05:23] <trulux> i have finished the development of a TPE subsystem with LSM, so, it can replace grsec's TPE in an only-selinux kernel package
[05:24] <pitti> trulux: pleeeease, no tech here
[05:24] <trulux> ok, sorry
[05:24] <elmo> TRULUX/PITTI/BLUEFOXICY: PLEASE ANSWER MDZ OR MOVE ON, KTHXBYE
[05:24] <mdz> the sort of things which would be under the domain of the tech board would be: including packages in the distribution, technical standards for packages, release feature goals
[05:24] <trulux> mdz, the decision should be: 1) support or not and collaborate with hardened debian
[05:24] <bluefoxicy> pitti:  a page somewhere accessable that notes that Ubuntu is at least "examining the potential for proactive security enhancements that stop attacks before they happen" would be vague enough to not create a sense of immediate commitment, but would give the userbase something to look forward to, I think.
[05:24] <mdz> if none of those apply to this discussion, then it is not a technical board matter
[05:25] <trulux> mdz, i'm answering
[05:25] <mdz> there seems to already be consensus on the technical aspects of this project
[05:25] <bluefoxicy> pitti:  It'd also give somewhere for people to check back at once in a while to see if specific release goals were made wrt that
[05:25] <trulux> 2) decide on how to deploy proactive security enhancements
[05:25] <mdz> the packages will go into universe, we won't make this a feature goal for Hoary (far too late)
[05:25] <trulux> 3) stablish a work team
[05:25] <trulux> kay
[05:26] <mdz> what was 1) ?
[05:26] <ogra>  1) support or not and collaborate with hardened debian
[05:26] <Kamion> teams are a matter for the community council, and in any case should probably just be blessing an existing group of people who're ready to do the work
[05:26] <mdz> will not be supported for hoary
[05:26] <trulux> ok
[05:26] <bluefoxicy> . . . you know what, stop asking me things, I'm dumb.  every time I try to formulate a coherant statement I get too much going on in my head and it comes out gibberish.
[05:26] <mdz> collaboration is not something which needs official approval; go forth and collaborate at will
[05:27] <pitti> mdz: +1
[05:27] <pitti> we can make an official statement when this stuff is a bit more mature
[05:28] <mdz> 2) what are the deployment requirements?
[05:28] <pitti> i. e. working and tested packages in universe
[05:28] <bluefoxicy> alright
[05:28] <mdz> you need to rebuild a whole bunch of packages and do a lot of testing, yes?
[05:28] <mdz> s/rebuild/build with SSP/
[05:28] <pitti> mdz: a good TB decision would be to provide some resources for that
[05:28] <pitti> i. e. having a part of the archive SSP-rebuilt in a separate archive
[05:29] <mdz> TB doesn't control any resources as far as I am aware, but I would like to hear what you guys believe you need
[05:29] <mdz> and can pass that on in other capacities
[05:29] <trulux> ok
[05:29] <pitti> it would be nice to have a buildd support for that
[05:29] <trulux> yes
[05:29] <pitti> a main-ssp archive
[05:29] <trulux> wanna build ;)
[05:30] <mdz> a great deal more than a buildd is required for proper testing
[05:30] <pitti> to save resources we should skip universe by now
[05:30] <bluefoxicy> mdz,pitty,trulux:  deployment of SSP requires rebuilding things with SSP.  As far as I'm concerned, adequate testing would make it ideal to just make all the packages in whichever version is SSP protected SSP protected, unless technical issues cropped up (some packages have bugs and SSP exposes them, so they 'break')
[05:30] <trulux> mdz, i agree
[05:30] <mdz> unless you only support installation from scratch (and not upgrades from Ubuntu)
[05:30] <elmo> surely this comes under the derived distro umbrella?
[05:30] <pitti> elmo: sounds like it could fit there
[05:30] <mdz> elmo: it falls under the derived-distro-with-different-toolchain umbrella, which is much harder
[05:30] <trulux> mdz, we need a good machine for rebuilding packages and maintain chroots
[05:30] <mdz> our derivation goals for Hoary only extend to package selection and branding, and not toolchain divergence
[05:31] <trulux> as testing packages outside jails is crazy
[05:31] <bluefoxicy> . . . i do it  o.o
[05:32] <bluefoxicy> . . . trulux is right, testing packages outside jails is crazy.
[05:32] <trulux> bluefoxicy, because you use gentoo and you don't need to maintain something working out the box
[05:32] <trulux> ;P
[05:32] <mdz> please, one of you write up a wiki page describing your resource requirements for doing a proof-of-concept
[05:32] <trulux> mdz, i'm uploading some things, wait please
[05:32] <pitti> yes, good idea
[05:32] <pitti> and defer this discussion
[05:32] <mdz> e..g, we need a facility to rebuild everything with a different toolchain, put it in a public archive, allow people to install(?), test it
[05:32] <mdz> trulux: ok, so you'll take responsibility for writing that?
[05:33] <pitti> trulux: I can assist you wit that
[05:33] <lamont_r> mdz: toolchain divergence is only a bootstrapping issue, since the toolchain is just another piece of the archive and chroot.
[05:33] <trulux> mdz it's already wrote at http://wiki.debian-hardened.org
[05:33] <trulux> pitti, i'm putting the new dev layout on the wiki, just a moment
[05:33] <mdz> ok, wonderful.  when you've done that, please send me an email
[05:34] <trulux> mdz@canonical.com right?
[05:34] <mdz> correct
[05:34] <pitti> trulux: let's sort that out without hurry
[05:34] <pitti> trulux: apart from the meeting
[05:34] <mdz> yes, take your time
[05:35] <pitti> next topic?
[05:35] <mdz> 3) creation of a team is a community council matter
[05:35] <mdz> so please bring that up at the CC meeting one week from today
[05:35] <mdz> come prepared with someone who is willing to volunteer to lead the team
[05:36] <mdz> That would seem to address the questions about proactive security.  Thanks to everyone who is putting effort into that project, and those who participated in the discussion
[05:36] <mdz> we need to move on to the next agenda item
[05:36] <mdz> which has to do with accessibility
[05:37] <hno73>  Accessibility at boot: can it be done?
[05:37] <mdz> hno73: here?
[05:37] <mdz> ah, good
[05:37] <hno73> This is a scaled back proposal from previous ones
[05:37] <hno73> please see: http://www.ubuntulinux.org/wiki/AccessibilityAtBoot
[05:38] <mdz> I've skimmed it
[05:38] <Keybuk> the question seems redundant; either we add a boot option or not
[05:38] <Keybuk> (d-i question, that is)
[05:38] <mdz> hno73: what sort of guidance do you need from the technical board?
[05:39] <Kamion> hno73: additional d-i questions are generally vetoed, I'm afraid
[05:39] <Keybuk> otherwise is everything you propose packaged and ready for testing?
[05:39] <Kamion> they will need Mark's approval
[05:39] <mdz> if you believe it is achievable to implement this before the FeatureFreeze (4 or 5 weeks?), then I think it would make a fine hoary goal
[05:39] <mdz> Kamion: that page discusses the live CD, rather than the installation
[05:39] <hno73> None of this has been developed yet, but it should be fairly basic stuff
[05:40] <mdz> Kamion: a convenient loophole ;-)
[05:40] <hno73> Though I'm not qualified to do it myself ...
[05:40] <amu> hno73: for the liveCD it should be possible, guess for hoary there isnt any time for it.
[05:40] <Keybuk> I tend to agree, though beware that we'd need to turn off bootsplash if you want a prompt during boot
[05:40] <Kamion> mdz: only in a parenthesis, most of it seems to be about the live CD
[05:40] <Kamion> er, the install CD
[05:40] <Keybuk> also a lot of the features seem GNOME-specific, and there's already an accessibility dialog to configure those ?
[05:40] <mdz> hno73: the technical board doesn't control development resources, so if there isn't anyone to do the work (yet), we don't have much to talk about here
[05:41] <mdz> hno73: however, feel free to contact me via email with a bounty proposal
[05:41] <mdz> hno73: we can post it on the website, and if you know anyone who might be interested in doing the implementation, I can contact them on behalf of Canonical
[05:41] <hno73> mdz: ok, will do
[05:42] <hno73> It's just that the Ubuntu web page sais: "Ubuntu includes the very best in translations and accessibility infrastructure"
[05:42] <mdz> that is one of our goals
[05:42] <hno73> and we're quite far from that ATM
[05:43] <mdz> agreed
[05:43] <mdz> the major goals for the Hoary release were established months ago, and need to be nearing completion at this stage
[05:44] <mdz> I think there is time to do an accessible live CD, if there is someone to do the work
[05:45] <mdz> but the existing development resources are pretty much allocated for the Hoary timeframe
[05:45] <mdz> moving on
[05:45] <mdz> fabbione: kernel?
[05:45] <fabbione> mdz: perhaps we can postpone the kernel stuff to this evening meeting?
[05:45] <mdz> it sounds like you're proposing a team
[05:45] <fabbione> i think it's more appropriate for the other
[05:45] <fabbione> well also..
[05:45] <mdz> in which case it should be the CC meeting
[05:46] <fabbione> let's skip the kernel for now
[05:46] <mdz> ok
[05:46] <mdz> sparc?
[05:46] <fabbione> yes
[05:46] <fabbione> this TB...
[05:46] <fabbione> well i have main done since a long while now
[05:46] <fabbione> tested sarge -> hoary upgrades
[05:46] <fabbione> installed from scratch....
[05:46] <fabbione> only a few glitches here and there
[05:47] <mdz> are you proposing that sparc become an officially supported architecture for hoary?
[05:47] <fabbione> mainly because of a few packages that i didn't spot from universe and that should be instead moved to main
[05:47] <fabbione> i want to propose at least its inclusion in the archive
[05:47] <fabbione> 1) main is up and running
[05:48] <fabbione> 2) it will free a bunch of my resources to test installations
[05:48] <mdz> ok, I have no problem with it being part of the archive
[05:48] <fabbione> 3) i could start building universe
[05:48] <mdz> and I believe Mark approved it as well
[05:48] <fabbione> my original proposal was to have a separate archive for non-official arches...
[05:48] <fabbione> and Mark seconded that
[05:48] <mdz> oh?
[05:49] <mdz> elmo: thoughts?
[05:49] <fabbione> mdz: something like sparc.ubuntu.com
[05:49] <fabbione> where you see only sparc binaries
[05:49] <Kamion> (and arch: all, presumably)
[05:49] <fabbione> to avoid to pollute the mirrors with an arch that might as well disappear if it doesn't takeoff
[05:49] <mdz> what would the idea be?  to make it easier to mirror only official architectures?
[05:49] <fabbione> Kamion: clearly
[05:49] <fabbione> mdz: an arch is still a few GB
[05:50] <elmo> mdz: I'm quite happy to do either, I just didn't have time at Mataro.  doing it separately requires some work, which is why it didn't get done
[05:50] <fabbione> and if for example in 2 months there will be nobody doing sparc...
[05:50] <mdz> elmo: which do you feel makes more sense?
[05:50] <Keybuk> would we use billie for this?
[05:50] <fabbione> we don't want to kill the mirror with it
[05:50] <mdz> billie?
[05:50] <elmo> Keybuk: not for one arch, probably not no, I can just hack up the two mirror masters to ignore sparc and create a separate sparc.ubuntu.com
[05:51] <elmo> mdz: personally, I'd put it straight in.  it's a very stable arch, it's not going to be flushed.  if nothing comes of it, nothing comes of it.  the mirror's already and insane size
[05:51] <fabbione> elmo: yup.. we know :-) i am just taking up again the discussion to reach a full consensum with an updated status
[05:51] <Keybuk> mdz: the bit of dak Kinni wrote to do second-class-citizen
[05:51] <lamont_r> mdz: yeah, it's not like it's hppa or something.
[05:51] <elmo> fabbione: I know, you know, mdz didn't tho, and he asked :)
[05:51] <mdz> elmo: your call, as far as I'm concerned
[05:52] <fabbione> elmo: i am happy with both the solutions
[05:52] <elmo> gar, let's just go with sparc.ubuntu.com - it's what we previously agreed on - I will get it done this weeke
[05:52] <fabbione> i am anal to avoid problems later if something "goes wrong"
[05:52] <elmo> s/e$//
[05:52] <lamont_r> elmo: although for actually populating the real archive, it'd be nice to use fabbione's archive to seed chroots and upload from that.
[05:52] <mdz> elmo: do we have a policy that all the builds should happen on the LAN?
[05:52] <elmo> mdz: I'd like to make one, certainly for supported architectures
[05:53] <elmo> before sparc.ubuntu.com merges, i'd like to have it rebuilt on our buildds
[05:53] <trulux> kernel oops
[05:53] <trulux> sorry
[05:53] <lamont_r> elmo: agreed
[05:53] <fabbione> elmo: agreed too.
[05:53] <mdz> ok, but for sparc,ubuntu.com, what will we do about builds?
[05:53] <fabbione> even if i trust the work i did, i am not as experienced as lamont_r and you
[05:53] <fabbione> mdz: i could ship my sparc to the DC if required...
[05:54] <elmo> mdz: use fabbione's for now, if he's happy to do that?  getting our own buildds is predicated on sparc gaining some momentum
[05:54] <fabbione> it's a U1
[05:54] <lamont_r> fabbione: and a full rebuild is always a good thing, unless it's going to be pushed on the mirrors
[05:54] <mdz> elmo: use fabbione's, and have him download sources from the DC and upload binaries there?
[05:54] <mdz> elmo: or ship it over?
[05:54] <fabbione> mdz: that's what i already do
[05:54] <mdz> fabbione: you upload binaries already? where do they go?
[05:54] <elmo> mdz: fabbione's remotely makes more sense to me, if he's happy to do it
[05:54] <elmo> I don't see much sense in shipping machines around - AFAICR that'd be reasonably expensive
[05:54] <fabbione> mdz: people.u.c/~fabbione/sparc/
[05:55] <mdz> ok
[05:55] <mdz> sounds like you guys are already in agreement about what to do, and it sounds fine to me
[05:55] <elmo> if we're going to do sparc long term, we'll get machines within a couple of days
[05:55] <mdz> basically moving ~fabbione/sparc/ to sparc.ubuntu.com
[05:55] <elmo> (for the DC)
[05:55] <lamont_r> elmo: does taht require some tweaks in the signature checking?
[05:55] <fabbione> lamont_r: my .changes are all signed
[05:55] <mdz> when sparc.ubuntu.com is up, we can make an announcement about it
[05:55] <elmo> lamont_r: yeah, it' will
[05:56] <mdz> as an alpha test or something
[05:56] <fabbione> i only need to tell elmo the key :-)
[05:56] <fabbione> elmo: just remember that i don't have a pool over there...
[05:56] <fabbione> there are only plain _sparc.deb
[05:56] <lamont_r> fabbione: good. (but our signatures are only good for source uploads, and making your sig ok for binary uploads would be a policy issue...)
[05:56] <elmo> fabbione: as long as you have .changes, I don't care
[05:56] <mdz> fabbione: as long as you promise not to upload other binaries ;-)
[05:56] <lamont_r> fabbione: so he needs to make your sig ok for sparc binary uploads, but not the others.
[05:56] <fabbione> elmo: sure.. i have all the history of stage2
[05:57] <mdz> ok, it sounds like we're finished with the meeting
[05:57] <fabbione> mdz: i am not THAT INS4N3... YOU KNOW, DON'T YOU? :P
[05:57] <fabbione> lamont_r: gotcha
[05:57] <mdz> we're finished with the set agenda, anyway
[05:57] <mdz> any last-minute items?
[05:57] <lamont_r> fabbione: hell - I upload binaries every now and then... I'm glad for the security blanket.
[05:57] <fabbione> KERNEL ARFH KERNEL ARFH
[05:58] <Keybuk> Hoary meeting, is that in here at 2200 UTC?
[05:58] <fabbione> lamont_r: i don't... remember.. i am anal.. X.. kernel... hundreds of users knocking on my door....
[05:58] <mdz> Keybuk: yes
[05:58] <mdz> fabbione: we agreed to defer that to CC (for the team) and the hoary devel meeting (for anything else)
[05:58] <fabbione> mdz: i know.. i was just kidding :-)
[05:59] <mdz> so, hearing none, the tech board meeting is adjourned
[05:59] <mdz> thanks, everyone
[05:59] <lamont_r> thanks mdz
[05:59] <fabbione> thanks guys!
[05:59] <fabbione> cya in a few hours
[05:59] <seb128> thanks
[05:59] <pitti> did I understand that right?
[05:59] <pitti> we don't have hoary meeting today?
[05:59] <ogra> pitti: nope....wrong :)
[05:59] <fabbione> pitti: at 22:00 UTC today
[06:00] <seb128> pitti: tonight, 2200 UTC
[06:00] <pitti> fabbione: because of <mdz> fabbione: we agreed to defer that to CC ...
[06:00] <mdz> Keybuk: thanks ;-)
[06:00] <pitti> ah, ok
[06:00] <fabbione> pitti: it was for the KERNEL stuff :-)
[06:00] <pitti> fabbione: sure, sorry
[06:01] <fabbione> no problem
[06:01] <sivang> there's a goal meeting again?
[06:01] <Keybuk> mdz: do you want to propose an alternate time for next week's tech-board meeting?  one more friendly to you?
[06:01] <mdz> Keybuk: yeah, I'll take that to ubuntu-devel
[06:01] <Keybuk> uh, two-weeks even :p
[06:01] <Keybuk> okies
[06:09] <trulux> mdz, http://wiki.debian-hardened.org/Development_layout_organization
[06:09] <trulux> mdz, it's still a draft
[06:09] <trulux> and now i must go
[06:09] <trulux> see you later!
[06:51] <thom> do we have an agenda for this evening?
[07:02] <mdz> thom: I have some notes, yeah
[11:01] <mjg59> mdz: Is there an agenda?
[11:01] <mdz> mjg59: a short one, yes
[11:01] <pitti> agenda = hoary goal list?
[11:01] <mdz> shall we go over the agenda, or just dive in?
[11:01] <Mithrandir> where's the agenda? :)
[11:01] <ogra> + fabionne and the kernel lovestory
[11:01] <Mithrandir> (except for mail, obviously)
[11:02] <mdz> first item is to review the pending seed changes
[11:02] <mdz> seed freeze was some time ago
[11:02] <mdz> but we've been fairly lax in tending to seed changes
[11:02] <mdz> so if there is anything on there which is urgent for hoary, we should discuss it and tend to it now
[11:03] <fabbione> 2.6.10 as deafult kernel?
[11:03] <jdub> the proposals pages need to be farmed for seed updates, i can do that if you want
[11:03] <doko> I need to update the seed for the ISDN stuff, after the meeting
[11:03] <ogra> gaim-dev is gone into experimenal today, could that be included ?
[11:03] <mdz> I'm looking at them now
[11:03] <mdz> http://www.ubuntulinux.org/wiki/BaseSeedProposals http://www.ubuntulinux.org/wiki/DesktopSeedProposals http://www.ubuntulinux.org/wiki/SupportedSeedProposals http://www.ubuntulinux.org/wiki/ShipSeedProposals
[11:03] <mjg59> We need vbetool for ACPI, but I only got that packaged last week
[11:03] <thom> i need to update the seeds from the meeting
[11:03] <jdub> is there much new stuff since going through them at mataro?
[11:04] <thom> will do so after the meeting
[11:04] <mdz> some of them have to do with feature goals, I think
[11:04] <thom> uh, the first meeting there was the BOF in mataro
[11:04] <mdz> oh, those pages don't include the seed updates whihc were already made?
[11:04] <mdz> gah
[11:04] <mdz> ok, we'll defer that, then.  maybe we don't have as much to do as I thought
[11:05] <mdz> next agenda item is getting caught up on Debian merges
[11:05] <mdz> UpstreamVersionFreeze is scheduled for tomorrow
[11:05] <lamont_r> mdz: meaning all the sync's need to be current by tomorrow?
[11:05] <mdz> we should either set a later deadline to allow us to get caught up with merges (which inlcude some new upstream versions), or delay UVF slightly so that we can catch up
[11:05] <mdz> jdub: what's your opinion?
[11:05] <seb128> ogra: that's a binary package of gaim, right ? 
[11:06] <ogra> seb128: nope, i thought it were finally the missing headers...
[11:06] <jdub> mdz: if we delay UVF, won't that mean more merges to catch up with?
[11:06] <seb128> ogra: the headers come from gaim, so that's a binary made from the gaim source package
[11:06] <lamont_r> mdz: I would think allowing the rest of the week for merges of the as-of-UVF package versions to get in would do...
[11:06] <Keybuk> mdz: bear in mind that shit's going to keep falling until we turn off the hose :o)  so we should decide how long we want to "catch up" and turn off lorraine N-<that number> days beforehand
[11:06] <mdz> jdub: yeah, it's mostly a matter of naming I suppose
[11:06] <mdz> jdub: the question is how UVF should apply to merges
[11:06] <mdz> Keybuk: right
[11:07] <mdz> but since  everyone has only just returned from holidays, we don't have N days
[11:07] <jdub> UVF should be the sync-stopper, merges we can handle as bugfixes
[11:07] <mdz> there are 89 open merge bugs
[11:07] <mdz> we should be able to kill them in a day or two
[11:07] <mdz> jdub: ok, but we should have a deadline for them
[11:07] <pitti> so, sync days tomorrow and the day after?
[11:07] <mdz> since they do introduce a lot of new code from upstream
[11:07] <ogra> seb128: http://people.debian.org/~robot101/gaim/dists/experimental/main/source/
[11:07] <Keybuk> elmo: about?
[11:08] <elmo> yeah?
[11:08] <mdz> UVF + 7 days should be more than enough
[11:08] <Mithrandir> ogra: what's in that?  gaim-dev?
[11:08] <mdz> jdub: work for you?
[11:08] <Mithrandir> ogra: if so, I have the patch and we could ubuntu it.
 elmo: about?
[11:08] <fabbione> ops
[11:08] <fabbione> sorry
[11:09] <Keybuk> elmo: how much time do you need to lobotomize lorraine so that syncs stop, but needs-merged.txt still gets updated?
[11:09] <jdub> mdz: was going to suggest that myself :)
[11:09] <mdz> Keybuk, elmo: did you talk about the MOM/lorraine stuff, to provide for ongoing merges after new versions are no longer synched?
[11:09] <mdz> jdub: ok, done.  please add it to the wiki schedule
[11:09] <ogra> Mithrandir: that would be great....that should be the headers and such...needed for lots of little tools tat just come up on gnomefiles.org
[11:09] <mdz> once UVF is executed, I'll assign the merge bugs out
[11:09] <jdub> we need a clayton's elmo for handling archive-related changes when he's away
[11:10] <mdz> another question is what to do about universe merges
[11:10] <elmo> Keybuk: very little
[11:10] <elmo> it's probably commenting out one line [tho I haven't checking] 
[11:10] <seb128> Mithrandir: you say that you're going to update gaim ? (I planned to do this but if you are going to do it no problem with me :p)
[11:10] <fabbione> mdz: i think we can be more flexible with universe...
[11:10] <jdub> mdz: last time around we took version sync requests fairly regularly
[11:10] <Mithrandir> ogra: I've been waiting for it to pass through NEW in Debian, that's why it hasn't been done anything with.
[11:10] <Mithrandir> seb128: I could do it, sure.
[11:10] <mdz> fabbione: agreed, but we need to connect the work-to-be-done with some people to do it
[11:10] <ogra> Mithrandir: as long as it can get in hoary its fine :)
[11:10] <mdz> since we'll be focusing on main
[11:11] <Mithrandir> seb128: I guess this is just the gaim-dev package currently missing?
[11:11] <fabbione> mdz: we don't have master-of-universe, do we?
[11:11] <mdz> this should be MOTU territory, but MOTU is a bit vaporous at the moment
[11:11] <lamont_r> mdz: that's 89 merge-_MAIN_ bugs open?
[11:11] <mdz> that's a next-tuesday discussion, I suppose
[11:11] <Kamion> back, sorry to be late
[11:11] <jdub> mdz: so while we can be less stringent about bug priority and so on, we should have people willing and able to test the stuff they propose for update
[11:11] <mdz> lamont_r: 89 total, maybe 75 main
[11:11] <lamont_r> ok
[11:11] <doko> mdz: I have to catch up on the python version change for universe, currently it's done for main only (and some packages from universe)
[11:12] <mdz> doko: that's something we should farm out to MOTU if possible
[11:12] <doko> sorry, MOTU?
[11:12] <elmo> there are python packages in universe?? how did they escape sabdfl's PYTHONWILLALLBEINMAINKTHXBYE streak?
[11:12] <lamont_r> masters of the universe
[11:12] <thom> master of the universe
[11:12] <mdz> doko: the community-based team formed to maintain universe
[11:12] <mdz> elmo: we talked him out of some of them
[11:13] <mdz> one other quick item before we dive into feature goals
[11:13] <jdub> mdz: are we going to finish the sweep of python in main stuff to sanitise it a bit?
[11:13] <mdz> does anyone here care dearly about mozilla-thunderbird?
[11:13] <jdub> mdz: what's up with it?
[11:13] <Keybuk> mdz: sabdfl, oh, wait, "here" :p
[11:13] <fabbione> <- i do...
[11:13] <thom> i care deeply about it burning in the utmost fires of hell
[11:13] <Mithrandir> mdz: a bit, yes.
[11:13] <jdub> mdz: oh, wanting 1.0?
[11:14] <mdz> jdub: you mean, now that we have some ammunition to show why it's not a very good policy to blindly include python-*? :-)
[11:14] <mdz> thunderbird needs love
[11:14] <mdz> lots of it
[11:14] <fabbione> mdz: i use thunderbird... but i don't love it enough to maintain YA5GSP
[11:14] <elmo> I think thom is the ideal candidate to show it all the love, care and attention it needs
[11:14] <jdub> mdz: well, we started looking at stuff in mataro, would be nice to finish it off
[11:15] <mdz> fabbione: thunderbird is only ~30M ;-P
[11:15] <seb128> yeah, thom !
[11:15] <thom> urgh
[11:15] <thom> i can't take two mozilla packages i don't use. firefox is quite enough :P
[11:15] <doko> what was the criteria for inclusion of python stuff in warty?
[11:15] <mdz> jdub: yes, I think we should; I think we can do it equally well between the two of us after the meeting or so, though
[11:15] <fabbione> mdz: right.. gimme ooo and glibc.. so i can beat the record for the "one man with the biggest (source) package"
[11:15] <jdub> mdz: suggest we ask for help with thunderbird, upgrading to 1.0 as well
[11:15] <mdz> fabbione: if no one will stand behind it, it is going to rot, and I will propose that we remove it from main for hoary
[11:16] <jdub> mdz: sure, didn't want to start a foodfight
[11:16] <fabbione> mdz: fine for me...
[11:16] <fabbione> move to out of main...
[11:16] <fabbione> i use it.. it doesn't mean i want it in main ;)
[11:16] <jdub> mdz: that's a good threat to get someone to help with it :)
[11:16] <jdub> mdz: but it's a worthy thing to have in main
[11:16] <Kamion> hey, mozilla-thunderbird is in ship
[11:17] <mdz> jdub: ok, will you send a call for help to some appropriate places?
[11:17] <elmo> err, there's a lot of user love for thunderbird
[11:17] <lamont_r> mdz: push the big red button
[11:17] <elmo> not saying that should necessarily matter, just unhelpfully pointing it out
[11:17] <Kamion> elmo: true *grump*
[11:17] <jdub> mdz: yes
[11:17] <Mithrandir> how bad is the bug list for m-t?
[11:17] <fabbione> Mithrandir: i think longer than the one for a1.3
[11:17] <lamont_r> the other big question on that front is whether it's 0.9 or 1.0
[11:18] <mdz> only about 15 bugs
[11:18] <mdz> but it needs a new upstream version, review of the bugs, matching them to upstream, working with users to clarify and resolve the bugs, etc.
[11:18] <mdz> i.e., love
[11:18] <mdz> lamont_r: hmm, good point.  if we're going to update it, it should be close to UVF
[11:19] <Mithrandir> mdz: I could give it a shot, I think losing it would a) look bad and b) be a shame.
[11:19] <lamont_r> 1.0 has been out for a bit, but not packaged for debian
[11:19] <mdz> jdub: willing to make an exception for t-bird 1.0 vs. UVF in order to allow time for someone to step up?
[11:19] <mdz> Mithrandir: do you use it?
[11:19] <Mithrandir> mdz: somewhat, yes.
[11:19] <jdub> mdz: relativelys short amount of time, yeah :)
[11:20] <Mithrandir> mdz: it's my local GUI client of choice and I use it for RSS feeds.
[11:20] <jdub> mdz: keep in mind it's been released for some time
[11:20] <mdz> Mithrandir: it's yours if you want it
[11:20] <ogra> lol
[11:20] <mdz> Mithrandir: if you want to look at it, but hand it off to someone else if they step forward, that's fine too
[11:20] <Simira> did I lose something here?
[11:21] <fabbione> Simira: nevermind.. i will tell you later
[11:21] <Mithrandir> mdz: ok
[11:21] <Simira> fabbione: you better.
[11:21] <mdz> great
[11:21] <jdub> Mithrandir: if you look at it, can you give me an idea of how badly broken it is before i announce? :)
[11:21] <Mithrandir> jdub: willdo
[11:21] <Simira> hey, how about sharing your love with firefox as well?
[11:22] <thom> i'm gonna apply love to firefox in the next couple of days
[11:22] <mdz> Simira: firefox gets so much love from thom, it would burst if any more were applied
[11:22] <Simira> ok, nice
[11:22] <thom> i even have patches from upstream for some of the bugs ;P
[11:22] <fabbione> nobody wants to give love to the kernel maintainer?
[11:22] <pitti> thom: please tell me you have a patch for the window injection :-/
[11:22] <mdz> who could fail to love fabio?
[11:23] <ogra> fabbione: we all love you....
[11:23] <thom> pitti: i wish :(
[11:23] <fabbione> :D
[11:23] <Mithrandir> fabbione: you have a gf. :)
[11:23] <mdz> one other project which needs a home:
[11:23] <doko> fabbione: too late you're getting married :-P
[11:23] <fabbione> Mithrandir: a fiance ;)
[11:23] <Simira> fabbione: of course we love you *hugs*
[11:23] <mdz> the LSB init script modifications need some serious review; many of them are buggy in various ways
[11:23] <Mithrandir> fabbione: gf being a subset of fiance.
[11:23] <lamont_r> fabbione: we all love you.
[11:23] <pitti> mdz: buggy in which sense?
[11:23] <lamont_r> as long as the kernels keep coming. :)
[11:23] <thom> mdz: oh dear lord
[11:23] <fabbione> ahha
[11:23] <mdz> they need a thorough review by someone very comfortable with shell scripting
[11:24] <fabbione> thom: like they don't work on serial console...
[11:24] <mdz> pitti: changing the behaviour of the script
[11:24] <lamont_r> pitti: abort in the presence of errors, as opposed to saying 'fail'
[11:24] <Keybuk> mdz: we're going usplurge for hoary still, yes?
[11:24] <Kamion> (why don't they use 'trap', anyway?)
[11:24] <thom> or frame buffer in some circumstances, iirc
[11:24] <mdz> Keybuk: hopefully
[11:24] <Keybuk> so we could kinda accidentally revert the nathaniel infection and nobody would notice?
[11:24] <lamont_r> Kamion: not all failures are that trivial to deal with
[11:24] <mdz> Keybuk: well, for usplash n+1, we'll need to put it back
[11:25] <lamont_r> Keybuk: that would reduce the merge count...
[11:25] <mdz> so that the scripts communicate with usplashd
[11:25] <Kamion> lamont_r: sure, but it would reduce the set +e evil that's been introduced in a number of them
[11:25] <lamont_r> set +e is wrong
[11:25] <Kamion> which is basically only so that it can go on to test $?
[11:25] <lamont_r> mdz: I'll take the script review
[11:25] <mdz> lamont_r: ok
[11:25] <Keybuk> phew, I was about to volunteer, thanks lamont :p
[11:25] <fabbione> ahah
[11:25] <thom> the whole thing really needs to get rethought, there're also about 50 packages that got missed in warty
[11:26] <lamont_r> Keybuk: please modify your patch breaker to sort out init.d patches. kthanksbye
[11:26] <mdz> thom: that too, but first priority is to fix the broken ones
[11:26] <Keybuk> lamont_r: it does
[11:26] <lamont_r> awesome
[11:26] <thom> yeah
[11:26] <Keybuk> http://people.ubuntu.com/~scott/patches/*_lsb-init.patch
[11:26] <mdz> lamont_r: yeah, you'll be reviewing that stuff anyway, so you can look at those along the way
[11:26] <mdz> perfect
[11:26] <lamont_r> mdz: right
[11:27] <mdz> so, feature goals
[11:27] <mdz> we ran down the list in Mataro
[11:27] <mdz> and of course, in the process, received some new must-have feature goals
[11:27] <elmo> Keybuk: is that still branding damaged? :)
[11:28] <Kamion> (if anyone's editing HoaryGoals, I just saved it; reload)
[11:28] <mdz> Mark's list is here: http://www.ubuntulinux.org/wiki/MarksHoaryGoals
[11:28] <Keybuk> elmo: yeah, it's on my TODO list
[11:28] <mdz> I need to finish merging that with HoaryGoals
[11:29] <lamont_r> brb
[11:29] <mdz> but among the things which are being bumped to the top of the list are the hardware database and launchpad integration
[11:30] <pitti> ugh, I should continue to work on hwfu
[11:30] <Kamion> can I request that somebody else take the rest of the UTF-8 task? I've done the glibc generate-UTF-8-locales-on-upgrade bit, but I received two newish hoary goals in Mataro
[11:30] <ogra> me too...
[11:30] <Kamion> or at least two things that weren't previously on the list
[11:30] <mdz> oh, and automated testing
[11:30] <mdz> Kamion: yes, I think that's appropriate
[11:30] <jdub> mdz: i thought automated testing was right off?
[11:31] <lamont_r> mdz: ISTR automated testing landing in my lap
[11:31] <mdz> jdub: that's not what Mark said
[11:31] <mdz> unless he changed his mind
[11:31] <Mithrandir> Kamion: the UTF8MigrationTool and such?
[11:31] <mdz> Mithrandir: yes
[11:31] <jdub> i must have missed that mind change somehow
[11:31] <Mithrandir> Kamion: I've actually considered doing it, me being one of the few people who bitch and complain about the beast.
[11:31] <mdz> Mithrandir: it's bountyable
[11:32] <Mithrandir> money's always welcome
[11:32] <Mithrandir> (:
[11:33] <mdz> ok, Mithrandir, let's discuss details after the meeting
[11:33] <mdz> ogra and pitti have been working on the hardware database stuff
[11:33] <Mithrandir> mdz: ok.
[11:34] <mdz> pitti, you already have a lot on your list, so I would prefer that the work be distributed to others if possible
[11:34] <pitti> ogra: would you be interested in continuing with hwfu? do it together with me?
[11:34] <mdz> pitti: of course, if you're very passionate about it, I don't mind if you want to work on it, but you have some heavy goals already
[11:34] <pitti> mdz: well, I can defer the ssp/grsec stuff a little, it's no hoary goal
[11:34] <pitti> mdz: I would not mind giving away hwfu
[11:34] <pitti> mdz: the basic architecture is there
[11:34] <pitti> and it works pretty well
[11:34] <ogra> pitti: sure, i was planning to....if i finally got the utf8 in the lockscreen win ready....but i think i can drop that in in the state it is
[11:35] <pitti> it's now a matter of writing plugins for various backends
[11:35] <mdz> pitti: you have already signed up for language packs, automated testing and hardware database in addition to ongoing security support etc.
[11:35] <pitti> mdz: right; before christmas I did nothing else apart from security udpates
[11:35] <pitti> mdz: but now it calmed down a little
[11:35] <pitti> mdz: today I talked to carlos about lang packs
[11:35] <pitti> mdz: and I think I need some time to set up the automated building of the debs
[11:36] <mdz> pitti: automated testing has a more flexible schedule because it isn't going into the release
[11:36] <fabbione> brb
[11:36] <pitti> I think lang packs should be my first priority now
[11:36] <mdz> pitti: just remember that security work tends to come in large, unexpected and unwelcome batches :-)
[11:36] <pitti> as soon as rosetta is able to export new stuff, I setup the automated building, I guess
[11:37] <pitti> mdz: I experienced that :-)
[11:37] <mdz> so make sure that you budget time for it, so that it doesn't cause feature goals to slip
[11:37] <pitti> yes
[11:38] <mdz> jdub, mvo: how are the package management tools coming?
[11:38] <ogra> pitti: as long as i can bug you with one or the other question....i'll take over....
[11:38] <pitti> ogra: sure
[11:38] <ogra> :)
[11:38] <pitti> ogra: I mirrored the arch archive, so you can read it
[11:38] <mdz> jdub, mvo: in particular, when can we add them to the default desktop?
[11:38] <mvo_> mdz: I think upgrade-notifier, ubuntu-cd detection and the new sources.list editors is pretty nice
[11:38] <jdub> mdz: we should do immediately
[11:38] <mvo_> agreed
[11:38] <ogra> pitti: great.... i'll check it out
[11:38] <jdub> mdz: there are still things to clean up, but we should add them now
[11:38] <Keybuk> aren't we still integrating them into one super-tool ?
[11:38] <jdub> mvo_: we should meet later and go over the changes
[11:38] <mdz> ok
[11:38] <mvo_> jdub: ok
[11:38] <mdz> so, some seed changes, and adding upgrade-notifier to the default session, right?
[11:38] <jdub> mdz: yeah
[11:38] <mvo_> yes
[11:38] <mdz> oh, and adding gnome-app-installer to the menu
[11:39] <jdub> it's in the menu, but in the wrong place ;)
[11:39] <Keybuk> can we not rename it to update-notifier?
[11:39] <mdz> jdub: what about the infrastructure for providing updated .desktop files to g-a-i?
[11:39] <Keybuk> confusing the terms "update" and "upgrade" is bad, m'kay
[11:39] <jdub> mdz: going to do that when my mirror completes :)
[11:39] <mdz> jdub: or are we going to wimp out on that and do it by hand for hoary?
[11:40] <Mithrandir> Keybuk: people don't know the difference anyhow; apt-get update; apt-get upgrade confuses people, it seems.
[11:40] <jdub> mdz: it'll probably be fairly by-hand, but it'll still be a script to run over the archive
[11:40] <mdz> Keybuk: I agree, the naming could probably use some work
[11:40] <Keybuk> Mithrandir: but right now we're confusing both in the same sets of tools
[11:40] <Keybuk> at least using one term exclusively would be nice
[11:40] <mdz> either update-manager and update-notifier, or upgrade-manager and upgrade-notifier
[11:40] <Mithrandir> Keybuk: I agree
[11:40] <jdub> update, preferably
[11:40] <mdz> which one is less painful to modify?
[11:40] <jdub> upgrade-manager is not exactly optimal for upgrades yet ;)
[11:40] <mdz> Mithrandir: apt-get update will become more or less obsolete with upgrade-notifier ;-)
[11:41] <Mithrandir> mdz: sed -i s,update,upgrade,g $(find -type f) in the source tree of one of them? :)
[11:41] <mdz> jdub: what needs to be done there?
[11:41] <mdz> jdub: is ross burton around?
[11:41] <mvo_> jdub: what's wrong with upgrade-manager?
[11:41] <jdub> mdz: ross did gai, mitario did the update manager
[11:41] <mdz> oh, right
[11:41] <jdub> mvo_: it's not optimal for upgrades (it's fine for updates)
[11:41] <mdz> jdub: s/// then
[11:42] <jdub> mvo_: but i think that's post-hoary
[11:42] <mvo_> jdub: ahh, agreed
[11:42] <jdub> mdz: mvo and i will give status report after discussing it
[11:42] <mdz> jdub: didn't we just finish agreeing that "update" and "upgrade" were easily confused? ;-)
[11:42] <mdz> jdub: ok
[11:42] <mvo_> I'll rename upgrade-notifier to update-notifier then
[11:42] <jdub> mdz: they are, because they mean different things
[11:42] <mdz> there is a new handwavy goal to integrate the desktop with launchpad
[11:42] <mvo_> I hope that makes everyone happy :)
[11:42] <mdz> this is the Help->report a bug, Help->translate this app sort of stuff
[11:43] <jdub> mvo_: don't start that just yet tho ;)
[11:43] <mvo_> jdub: ok :)
[11:43] <mdz> I hope that when we spec it out, it will reduce to adding some standard menu entries which open the browser with certain URLs based on the package name
[11:44] <mdz> but at any rate, we need someone to do the work
[11:44] <mdz> jdub: do you have a bounty candidate for this?
[11:44] <jdub> mdz: yeah, a few come to mind
[11:44] <jdub> mdz: we just want help menu changes, right?
[11:45] <mdz> jdub: it hasn't been formally specified, but yes, I hope it'll boil down to that
[11:45] <jdub> (at this stage, we can do more later)
[11:45] <doko> mdz: if that can be done in February, I'll look at it.
[11:45] <mdz> jdub: let's get with Mark soon and nail down exactly what he expects for Hoary
[11:45] <mdz> doko: this needs to be done by feature freeze, which is 1st week of feb, I think
[11:46] <Keybuk> mdz: heh, I've been trying to get Mark to agree on URLs for HCT for a while now ... :p  let me know how you get on
[11:46] <mdz> and since that date has come up, I'd like to ask if anyone is in trouble with their feature goal assignments
[11:47] <Kamion> I'm a little worried about kickstart, but it should be achievable at least in skeletal form by then
[11:47] <fabbione> mdz, Kamion: i am not 100% sure how much i can dedicate to the kickstart
[11:47] <pitti> mdz: hw database might not be ready by Feb 1
[11:47] <Kamion> I'm unlikely to be able to give any time to autotesting before feature freeze
[11:47] <mdz> a few goals can be flexible with respect to feature freeze
[11:47] <mdz> that date is aimed at stuff which is going in the distribution proper
[11:48] <mdz> automated testing can slip
[11:48] <mdz> (featurefreeze, that is)
[11:48] <fabbione> mdz: i am mostly binded to the 2 things we discussed earlier...
[11:48] <mdz> pitti: the collection part of the hardware database needs to be done by feb 1
[11:48] <mdz> pitti: ogra has said that he can devote time to it, so we'll revisit it after we've talked about that more
[11:48] <mdz> s/feb 1/feature freeze/
[11:48] <sivang> mdz: I would also like to take a look into the launchpad integration menu stuff, I'll see if I can discuss with jdbub after the meeting. 
[11:48] <pitti> mdz, ogra: hmm, then we need to speed that up
[11:49] <mdz> it's actually the 9th or whatever
[11:49] <mdz> sivang: ok, please do
[11:49] <jdub> mdz: i have yet to nail down the panel and icon stuff, but that's mostly been due to christmas / new year, etc. i'm going to hammer on that this and next week -> icon stuff at least can slip slightly past the preview.
[11:49] <Keybuk> mdz: I may have one or two more boot-process changes to speed it up a bit; should be ok by Feb 1 though
[11:49] <mdz> Kamion, fabbione: so about kickstart
[11:49] <pitti> Simira: please finish g-s-t first
[11:49] <ogra> pitti: will be possible....
[11:49] <pitti> Simira: sorry, that wasn't for you
[11:49] <pitti> sivang: please finish g-s-t first, that's critical
[11:50] <sivang> pitti: ofcourse, I just got the idea that the menu thing can wait for feb? 
[11:50] <fabbione> mdz: as i wrote above...
[11:50] <mdz> Kamion: you have taken on a huge load in terms of high-priority goals; is there anything that you can shed to make room for kickstart?
[11:50] <mdz> Kamion: I think you're most qualified to work on it at this point
[11:50] <Kamion> agreed
[11:51] <lamont_r> Kamion: you're welcome to shed some work my way
[11:51] <Kamion> autotesting is really the only primary goal left, I think
[11:51] <thom> mine also
[11:51] <mdz> Kamion: I think it goes without saying that you probably won't have time to work on automated testing, so let's take your name off of that
[11:51] <Kamion> most of the rest I've made sizable inroads on or more or less completed
[11:51] <mdz> Kamion: unless you really want it
[11:51] <Simira> pitti: thanks for your trust, but you won't have me to touch that one ;p
[11:51] <mdz> kickstart is higher priority in terms of the release schedule
[11:51] <pitti> Simira: xchat autocompletion error... :-)
[11:52] <Kamion> nah, I expressed half-hearted interest at the meeting and my name ended up on the list. :)
[11:52] <mdz> that's what I thought :-)
[11:52] <seb128> pitti: I gave you the command to get a nice completion this morning :p
[11:52] <mdz> Kamion: what other major pieces are on your plate for pre-feature-freeze?
[11:52] <Simira> pitti: I reckoned, yes. :)
[11:52] <mdz> Kamion: anything where thom or lamont could give you some support?
[11:52] <Kamion> in general I think it would be a good idea to get more people involved in installer bugs; I'll see if I can find good introductory pieces to hand out
[11:53] <Kamion> there's no single big piece but a lot of little ones
[11:53] <mdz> Kamion: if you need to delay bug work to work on features during the next few weeks, that's entirely appropriate
[11:53] <thom> (note i can also do itanium testing now)
[11:53] <mdz> Kamion: but I understand that you probably want to avoid falling behind
[11:54] <Mithrandir> thom: lucky you.  Fun with noisy beasts at home, or have you remote access to a Bdale Facilities?
[11:54] <lamont_r> thom: d-i currently dies on ia64
[11:54] <fabbione> thom: it would be nice if you can start testing the kernel for ia64....
[11:54] <lamont_r> Mithrandir: he has his very own a500/zx2000 love
[11:54] <Kamion> the other major featurish pieces are the two things Mark brought up in Mataro (first-stage questions, netcfg rf-kill-switch detection) and the low-priority oem stuff
[11:54] <mdz> Kamion: will you think on it a bit, and follow up with me, thom and lamont after the meeting to distribute some of that work?
[11:54] <Kamion> I've been making inroads on the first-stage questions thing and I suspect I'm probably the best person to continue that, but the kill-switch thing could be passed to somebody else
[11:55] <Kamion> yes, will follow up
[11:55] <mdz> thanks
[11:55] <mdz> fabbione: the two things you referred to earlier are the kernel and the other project?
[11:56] <fabbione> mdz: yes
[11:56] <Kamion> the other main reason I've been falling behind a little more than expected is getting engaged, which was sort of not on the project plan. :)
[11:56] <mdz> fabbione: is there any feature work pending for the kernel, or primarily bugs?
[11:56] <Mithrandir> Kamion: congratulations! :)
[11:56] <lamont_r> Kamion: as long as she knows what she's marrying into....
[11:56] <Kamion> oh, she does
[11:56] <daniels> Kamion: surely that came way too late after the appropriate freeze ...
[11:56] <Keybuk> Kamion: congrats!
[11:56] <fabbione> mdz: no features.. only tons and tons of bugs
[11:57] <mdz> Kamion: just don't schedule the date for April, OK? ;-)
[11:57] <thom> Kamion: dude, congrats!
[11:57] <sivang> Keybuk: congrets!
[11:57] <Kamion> it's August currently
[11:57] <sivang> oops
[11:57] <sivang> Keybuk: congrats!
[11:57] <doko> fabbione: what about the powerpc64 kernel?
[11:57] <jdub> Kamion: congrats :-)
[11:57] <daniels> Kamion: congrats, again (so I don't feel left out)
[11:57] <seb128> congrats :)
[11:57] <sivang> erghh irssi completions
[11:57] <ogra> Kamion: congrats !
[11:57] <fabbione> doko: that's low priority
[11:57] <mvo_> congrats!
[11:57] <fabbione> Kamion: i will tell you how it goes after february... you will have time to reconsider :P
[11:57] <smurfix> Kamion: conga rats!  ;-)
[11:58] <sivang> smurfix: hehe
[11:58] <jdub> Kamion: so you won't be needing any high priority bendy goals :)
[11:59] <daniels> jdub: bendy totally needs a GUI installer, I think ;)
[11:59] <elmo> kamions hasn't done the graphical installer yet?????
[12:00] <elmo> \o/
[12:00] <mdz> Kamion: how is the hardware detection stuff going?
[12:00] <fabbione> elmo: *cough*sparc*cough*
[12:00] <jdub> \u/ <- after drainpipe
[12:00] <Kamion> (actually, fwiw: we could call the netcfg rf-kill-switch thing a bug, since it is, I don't know why Mark brought it up during a feature goals meeting)
[12:00] <lamont_r> bendy is after hoary
[12:00] <jdub> sivang: bendy is the release after hoary
[12:00] <mdz> Kamion: daniels has his name down for that one, so please feel free to invite him to own up to it :-)
[12:00] <lamont_r> bendy badger
[12:00] <elmo> bendy is the object lesson on "why trolling sabdfl is bad, mmkay?"
[12:01] <mdz> jdub: please don't send the mail yet; I need time to make my case for a better name
[12:01] <sivang> jdub: wasn't it grumpy? or was it too grumpy for a name? :)
[12:01] <Kamion> mdz: displaying network interface names correctly is the only missing piece I know of
[12:01] <jdub> mdz: better than bendy?
[12:01] <mdz> jdub: yes
[12:01] <Kamion> I worked around the framebuffer problem today, which was release-critical
[12:01] <lamont_r> sivang: grumy was considered too, well, grumpy
[12:01] <jdub> sivang: three dispositive names in a row... grumpy is going to be used for something else.
[12:01] <Keybuk> jdub: that shouldn't be too hard
[12:01] <mdz> Kamion: did you get my mail with the macio hotplug stuff?
[12:01] <jdub> mdz: you're being serious?
[12:01] <Kamion> mdz: yes, haven't had time to do anything serious with it yet :-/
[12:01] <mdz> jdub: you mean you don't think it's the worst one yet?
[12:01] <Kamion> (but will do)
[12:02] <mdz> Kamion: just wondering whether you think it's something we should shoot for for hoary
[12:02] <daniels> mdz: christ, how'd my name get there?
[12:02] <daniels> mdz: (gui installer)
[12:02] <jdub> mdz: ok, deferred, let's chat about it in #u-d after the meeting
[12:02] <mdz> daniels: not gui installer; unified hardware detection
[12:02] <mdz> daniels: and to answer your question, because of the X component
[12:02] <Kamion> mdz: I don't think the mac-io hotplug stuff is urgent, personally, the /etc/modules workaround is adequate
[12:02] <Kamion> and the existing code is easy to deal with
[12:03] <fabbione> daniels: because you own X and it is related to GUY?
[12:03] <mdz> daniels: we'll need your help to get the X autodetection doing the right stuff on the live CD, I assume
[12:03] <amu> mdz: ack
[12:03] <mdz> Kamion: ok.  if you get an itch to try it out, please send feedback to the guy who sent it to me; he's very interested in whether it works out
[12:03] <fabbione> mdz: Mark explicitly requested that...
[12:03] <mdz> fabbione: requested what?
[12:03] <daniels> mdz: oh, UHD; sorry, ECONTEXT
[12:04] <mdz> one short item, since the live CD came up
[12:04] <fabbione> mdz: the sync between X install autodetection and liveCD
[12:04] <mdz> we're going to be developing some significant bits of infrastructure for the live CD
[12:04] <mdz> enough that it needs a name
[12:04] <Kamion> live-* not enough?
[12:04] <mdz> like, a brand name
[12:04] <mdz> a name for the project
[12:04] <Keybuk> Ubuntu LIVE!
[12:05] <mdz> it should not be specific to Ubuntu
[12:05] <lamont_r> frankenbuntu?
[12:05] <ogra> lol
[12:05] <sivang> liveshow? 
[12:05] <fabbione> Ubuntu-resurrected?
[12:05] <Kamion> lively
[12:05] <lamont_r> (it's alive....)
[12:05] <sivang> :)
[12:05] <sivang> or LiveShow
[12:05] <daniels> yeah, X install detection and live CD sync is kind of tricky
[12:05] <mdz> lively is cute
[12:05] <smurfix> lively lizard?
[12:05] <jdub> Lively Leprechaun
[12:06] <mdz> ok, thanks for the suggestions
[12:06] <daniels> but I have a design for it and will move forward after I've fixed my most pressing bugs (xorg module loader plus debian sync, l-r-m 2.6.10, preparing for new fglrx)
[12:06] <mdz> moving ahead with feature goals
[12:06] <mdz> pitti: what's the status of language packs?
[12:06] <Keybuk> Kamion: mind out, floor's a bit slippy
[12:07] <pitti> mdz: carlos will implement time-based po downloads (in a ZIP stream) soon
[12:07] <pitti> mdz: I agreed with him on an interface today
[12:07] <pitti> mdz: I still need to setup the automatic deb building
[12:07] <mdz> pitti: so the glibc changes are in (yes?), the striptranslations tool is written(?)
[12:07] <pitti> mdz: and I need to complete the metapackages (but that's relatively easy)
[12:07] <pitti> mdz: yes and yes
[12:08] <pitti> mdz: pkgstriptranslations
[12:08] <pitti> mdz: I also updated debhelper to use it if it's present
[12:08] <mdz> pitti: we need to tie the strip process into the autobuilders, and create a tool to build packages from the stripped translations
[12:08] <pitti> mdz: it just needs to be enabled in /etc/pkgstriptranslations.conf
[12:08] <mdz> pitti: oh, so we should be ready to start stripping translations during the build?
[12:08] <pitti> mdz: yes
[12:08] <mdz> pitti: please work with lamont to get that going ASAP
[12:08] <pitti> mdz: everything is in place
[12:08] <lamont_r> cool.. pitti I just need instructions
[12:09] <pitti> mdz: I did not yet ask for that because we don't yet have lang pack debs
[12:09] <mdz> lamont: will need one additional package installed in the chroots, and then a mechanism to copy the files off somewhere after the build is complete
[12:09] <pitti> lamont_r: just enable pkgstriptranslations in the conffile
[12:09] <mdz> pitti: we should start collecting translations now, so that we have something to make debs from
[12:09] <pitti> lamont_r: and pkgstriptranslations (the deb) must be included into the buidd chroots
[12:09] <lamont_r> installed and configured.
[12:09] <mdz> lamont_r, pitti: we can discuss the details after the meeting, but please get it going soon
[12:09] <pitti> mdz: no, we don't need to copy the mo files
[12:09] <mdz> pitti: we don't?
[12:10] <pitti> mdz: no, carlos said that the mo files are useless
[12:10] <lamont_r> what happens to the stripped transalations?
[12:10] <pitti> mdz: that's why I just delete them
[12:10] <fabbione> >/dev/null ?
[12:10] <pitti> mdz: carlos said that rosetta needs the original po files
[12:10] <mdz> pitti: if we throw them away, then we can't create language packs until every package is in Rosetta
[12:10] <pitti> mdz: so rosetta needs to extract them from the source package
[12:10] <mdz> and there are only, what, about 10 packages in rosetta so far?
[12:10] <lamont_r> pitti: I'll get with you after the meeting
[12:10] <pitti> mdz: AFAIUI they can do it automatically now
[12:10] <mdz> yes, let's take that discussion elsewhere
[12:11] <pitti> mdz: but I have to ask carlos again
[12:11] <pitti> yes
[12:11] <pitti> mdz: I will care for that in the next days
[12:11] <mdz> doko: python-minimal seems to be in fairly good shape
[12:11] <mdz> doko: what remains to be done before we make it Essential: yes?
[12:11] <doko> tighten the dependency, should be all.
[12:12] <mdz> does anyone else have outstanding concerns about python-minimal?
[12:12] <mdz> we should probably have some sort of test suite
[12:12] <Kamion> seems to debootstrap properly now