=== Lovechild [~dnielsen@82.150.72.35] has left #ubuntu-meeting ["Leaving"] === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === highvoltage [~jonathan@dumbledore.hbd.com] has joined #ubuntu-meeting === skyrider [~skyrider@195.128.178.150] has joined #ubuntu-meeting === bwb [~nate@ip68-5-253-106.oc.oc.cox.net] has joined #ubuntu-meeting === Riddell [jr@muse.19inch.net] has joined #ubuntu-meeting === bwb [~nate@ip68-5-253-106.oc.oc.cox.net] has left #ubuntu-meeting [] === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === bwb [~nate@ip68-5-253-106.oc.oc.cox.net] has joined #ubuntu-meeting === zul [~chuck@zul.developer.gentoo] has joined #ubuntu-meeting === skyrider [~skyrider@195.128.178.150] has joined #ubuntu-meeting === seb128 [~seb128@ANancy-151-1-45-42.w83-196.abo.wanadoo.fr] has joined #ubuntu-meeting === sivang [~sivang@box79162.elkhouse.de] has joined #ubuntu-meeting === lamont_r [~lamont@mesaradio41.customer.frii.net] has joined #ubuntu-meeting === hno73 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting === skyrider [~skyrider@195.128.178.150] has joined #ubuntu-meeting === skyrider [~skyrider@195.128.178.150] has joined #ubuntu-meeting === mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting === Keybuk [scott@descent.netsplit.com] has joined #ubuntu-meeting === hno73 [~Henrik@henrik.gotadsl.co.uk] has left #ubuntu-meeting [] === hno73 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting === bluefoxicy drags ass over from bed with one eye [04:55] its not that early bluefoxicy === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting [04:55] uh [04:55] 11 am? [04:56] still [04:56] morning [04:56] hello mdz [04:56] heh, I have a problem waking up, it takes me several hours [04:56] normally I become concious at something like 8 or 9 am [04:56] and get up at 12 or 1 pm === ..[topic/#ubuntu-meeting:mdz] : Tuesday 4 January 2005 at 1600 UTC: Technical Board -- http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda. Tuesday 11 January 2005: Community Council meeting -- https://www.ubuntulinux.org/wiki/CommunityCouncilAgenda === azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting === lamont_r notes that it's only 1558 utc === elmo [~james@83.216.141.215] has joined #ubuntu-meeting === bluefoxicy tries to get trulux in here === trulux [~lorenzo@67.Red-80-25-56.pooles.rima-tde.net] has joined #ubuntu-meeting [04:58] bluefoxicy: what tz you in? [04:58] do I have time to make a glass of koolaid? [04:58] hi [04:59] lamont_r: EST === haggai [~halls@i-83-67-20-196.freedom2surf.net] has joined #ubuntu-meeting [04:59] bluefoxicy, it still isnt early ;) === lamont_r has no pity. (MST here, and kids in school is really interfering with my night owl schedule) [05:00] ok [05:00] hey pitti [05:00] heh [05:00] Hi trulux [05:00] hey all [05:00] first agenda item is to talk about proactive security [05:01] is JohnMoser here? [05:01] yo [05:01] go ahead [05:01] what is the question which needs to be resolved? [05:01] 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] 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 === amu [~amu@amu.developer.debian] has joined #ubuntu-meeting [05:01] ok, then let me start it [05:02] pitti, ready? [05:02] 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] sure [05:02] bluefoxicy, before they exist not, before they get known or even following a similar pattern [05:02] ;) [05:03] . . . 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] that's because it's called proactive security, which also prevents so-called zero-day exploits [05:03] trulux: well we have selinux compiled in already... it just question of a boot flag to enable it [05:03] yes [05:03] fabbione, i'm working on to get a desktop-ready SELinux system for Ubuntu [05:03] fabbione, also i'm the guy developing the 2.4 backport [05:03] trulux: yeah but the kernel is ready already ;) [05:03] I publically announced the first PaX enabled kernels today [05:04] pitti: sweet. :) [05:04] pitti: great [05:04] fabbione, heh, sure [05:04] pitti, at this point i would like to make some comments [05:04] the kernels work mostly fine already. Still some caveats, but Itry to sort them out soon [05:04] trulux: go ahead [05:04] kay [05:04] so, with fabbione's selinux enabling and pitti's PaX kernel, 2 of 3 assignments from Mataro are complete [05:04] for my part I must say that I would welcome collaboration with hardened-debian [05:05] pitti, me too, and debhard devs would like to [05:05] so, this is what i think: [05:05] mdz: in fact I also digged a bit about what obsd and gentoo do [05:05] mdz: basically they use gcc-ssp, too [05:05] mdz: and obsd has something similar like PaX (W^X) === mako [mako@micha.hampshire.edu] has joined #ubuntu-meeting [05:06] 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] that means: [05:06] having guys with kernel hacking skills, documentation skills, talking skills and *leading* skills [05:06] this is more than protecting buffer overflows [05:07] well, it's about improving general proactive security [05:07] 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] ... and OpenBSD uses SSP for ages now [05:07] yeah [05:07] pitti, the point is that we are not just putting proactive security [05:08] as we already said, the main isseu with SSP is not the technical side, but the supportability over the whole distro lifecycle [05:08] from the oytside, people will know it as the way of having the information leak-proof [05:08] and secured [05:08] and the ssp croud has yet to provide a moduler set of gcc patches, aiui [05:08] as long as SSP is not upstream, it might become hard to support [05:08] so, they will think in moving to Ubuntu [05:08] for example [05:08] pitti, i've talked to Eoth, i would try to move some things to help with that [05:08] Etoh [05:08] and I was told that even Windows XP now has canaries on the stack (SSP-like) [05:09] 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] trulux: if you aren't talking about proactive security, then please explain what you do mean [05:09] because the specific items we have discussed so far all fall under that heading [05:09] trulux: would you like to create SSP packages for universe now? The way we already discussed? [05:09] bluefoxicy: I expect that they requested a _set_ of individual patches vs cvs-head [05:09] mdz, it's proactive security for us, information assurance for the users [05:10] which is basically the same [05:10] pitti, yes, but with different understanding points [05:10] i think i can do the SSP packages [05:10] sure [05:10] they're both jargon to the user [05:10] that'd be great [05:10] better to have a name which is more meaningful to the people who would be involved with it [05:11] mdz, i still like proactive security ;) [05:11] lamont_r: [05:11] for the audience, the plan is to provide completely independent gcc-ssp packages in universe for now [05:11] pitti, but why separating the pkgs in -ssp and non-ssp brands? [05:11] so they can be used to play without interfering with the release process [05:11] pitti: a copy of the source? [05:11] 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] mdz: so far this seems to be necessary [05:11] 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] bluefoxicy: ok [05:12] mdz: unless trulux is able to "wrap" gcc with the protector, but I think that is difficult [05:12] lamont_r: it keeps your data secure, though [05:12] pitti, i will so my wrappers [05:12] show [05:12] 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] lamont_r: I look at security as a user-friendly issue. [05:13] so that we don't interfere with the progress of the standard gcc [05:13] 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] 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' === ogra [~ogra@p508EBC96.dip.t-dialin.net] has joined #ubuntu-meeting [05:13] lamont_r: avoiding DoS is a matter of fixing the package, no way to get around this :-) [05:13] pitti: exactly [05:13] lamont_r: a crash annoys me, but I don't need to worry about it eating my machine. [05:13] likewise for a broad class of vulnerabilities [05:13] lorenzo@estila:~/proyectos/hardened-toolchain-wrappers $ ls [05:13] hardened-gcc-wrapper-1.4.2.c hardened-ld-wrapper-1.4.2.c Makefile suspect.c [05:13] lorenzo@estila:~/proyectos/hardened-toolchain-wrappers $ [05:13] lamont_r: the point is just to confine the impact of holes [05:13] pitti: mind you, I'm all for security blankets, as long as we understand what they are. [05:14] things like SSP are about low-hanging fruit and maybe-good-enough solutions [05:14] yeah, I'm a little concerned about the propaganda I'm hearing to be honest - these things are at best a layer [05:14] mdz: agreed. low hanging fruit are great to grab. But calling the result "secure" is laughable [05:15] certainly [05:15] I did a quick analysis on how well this stuff would protect you. http://www.ubuntulinux.org/wiki/USNAnalysis [05:15] lamont_r: we talk about "improving" proactive security [05:15] this is "a feature which makes your system more difficult to attack" [05:15] SSP for example would carry about 40% of the torch [05:15] lamont_r: not reaching the ultimate goal :-) [05:15] then again, that's because the end users see security as an absolute, while we see it as a range [05:15] wait, can i show what i was meaning? it's just a moment [05:15] bluefoxicy: I have a feeling that figure is based on the assumption that SSP prevents all buffer overflows [05:15] we have both wrappers, one for ld and one for gcc [05:15] which it doesn't [05:16] i will upload the stuff and you could check it [05:16] mdz: It's more based on the assumption that the classes of buffer overflows that SSP doesn't protect are very rare [05:16] mdz: SSP does not prevent buffer overflows, neither does PaX [05:16] mdz: mainly, overflows inside structures with data above buffers [05:16] mdz: it just confines their exploitation [05:16] sorry pitti is right, it catches the attack at the end [05:17] pitti: yes, that's what I should have said [05:17] pitti: doesn't it actually prevents their exploitation? Things like SELinux confine it right? [05:17] s/prevents/addresses/ [05:17] mdz: just to clarify for the audience :-) [05:17] bluefoxicy: yes [05:17] 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] bluefoxicy: let's say, in most cases it prevents it, but there might be loopholes which still allow exploitation [05:18] and if you have active PaX with memory protections + ASLR, you can't really inject code to do that anyway :) [05:18] so it becomes on the whole a 1/4000000 guessing game any route you take [05:18] ^ that's what my kernels are for [05:18] pitti: yes, but in most cases there will be no possible way of guaranteed exploitation. [05:19] btw, PaX prevents executing stuff in writeable pages, so this closes the 1/400000 chance :-) [05:19] bluefoxicy: right [05:19] anyway, I don't think we need to discuss this stuff in the meeting [05:19] just because the code is normally in the stack doesn't mean it needs to be. [05:19] please leave the technical arguments aside here [05:19] yes, do [05:19] we don't need to have an extended debate about these techniques here [05:19] i agree === lamont_r knows of at least one exploit that did not use any code not found in the attacked application [05:19] as I asked before, what is the decision that needs to be made by the board? [05:19] this should be more about cooperation [05:19] go forward to what we are talking about [05:19] lamont_r: ASLR from PaX [05:20] lamont_r: sure, it leaves holes; as I said, nothing is perfect :-) [05:20] trulux: do you really think we need a formal statement right now? [05:20] trulux: so far our inofficial cooperation works quite nice, or not? [05:20] 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] I think we do need an official statement as soon as we officially support it [05:21] bluefoxicy: off topic [05:21] lamont_r: yes, sorry, i'm getting ahead of the conversation. [05:21] if there isn't a decision to be made by the tech board, then we need to move on [05:21] pitti, yes, but i would like an official statement [05:21] so if there is, please speak up [05:21] trulux: okay [05:22] ok, let me package the wrappers and upload them somewhere [05:22] btw, it would be great to maintain a line of only pax+selinux packages [05:22] kernels with non-vanilla selinux/lsm stuff [05:22] trulux, bluefoxicy: what is your idea of an "official" statement? [05:22] for ex. [05:23] trulux, bluefoxicy: as already said, we don't need to discuss the technical details here. Just the strategic ones [05:23] if no-one is going to answer mdz's question, perhaps this discussion could move elsewhere. === fabbione gets some chips [05:23] 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] trulux: pleeeease, no tech here [05:24] ok, sorry [05:24] TRULUX/PITTI/BLUEFOXICY: PLEASE ANSWER MDZ OR MOVE ON, KTHXBYE [05:24] 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] mdz, the decision should be: 1) support or not and collaborate with hardened debian [05:24] 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] if none of those apply to this discussion, then it is not a technical board matter [05:25] mdz, i'm answering [05:25] there seems to already be consensus on the technical aspects of this project [05:25] 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] 2) decide on how to deploy proactive security enhancements === daniels [~daniels@amnesiac.heapspace.net] has joined #ubuntu-meeting [05:25] the packages will go into universe, we won't make this a feature goal for Hoary (far too late) [05:25] 3) stablish a work team [05:25] kay [05:26] what was 1) ? [05:26] 1) support or not and collaborate with hardened debian [05:26] 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] will not be supported for hoary [05:26] ok [05:26] . . . 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] collaboration is not something which needs official approval; go forth and collaborate at will [05:27] mdz: +1 [05:27] we can make an official statement when this stuff is a bit more mature [05:28] 2) what are the deployment requirements? [05:28] i. e. working and tested packages in universe [05:28] alright [05:28] you need to rebuild a whole bunch of packages and do a lot of testing, yes? [05:28] s/rebuild/build with SSP/ [05:28] mdz: a good TB decision would be to provide some resources for that [05:28] i. e. having a part of the archive SSP-rebuilt in a separate archive [05:29] 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] and can pass that on in other capacities [05:29] ok [05:29] it would be nice to have a buildd support for that [05:29] yes [05:29] a main-ssp archive [05:29] wanna build ;) [05:30] a great deal more than a buildd is required for proper testing [05:30] to save resources we should skip universe by now [05:30] 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] mdz, i agree [05:30] unless you only support installation from scratch (and not upgrades from Ubuntu) [05:30] surely this comes under the derived distro umbrella? === doko [doko@dsl-082-082-190-115.arcor-ip.net] has joined #ubuntu-meeting [05:30] elmo: sounds like it could fit there [05:30] elmo: it falls under the derived-distro-with-different-toolchain umbrella, which is much harder [05:30] mdz, we need a good machine for rebuilding packages and maintain chroots [05:30] our derivation goals for Hoary only extend to package selection and branding, and not toolchain divergence [05:31] as testing packages outside jails is crazy [05:31] . . . i do it o.o === bluefoxicy looks at his machine, and the format count, reaching the hundreds now [05:32] . . . trulux is right, testing packages outside jails is crazy. [05:32] bluefoxicy, because you use gentoo and you don't need to maintain something working out the box [05:32] ;P [05:32] please, one of you write up a wiki page describing your resource requirements for doing a proof-of-concept [05:32] mdz, i'm uploading some things, wait please [05:32] yes, good idea [05:32] and defer this discussion [05:32] 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] trulux: ok, so you'll take responsibility for writing that? [05:33] trulux: I can assist you wit that [05:33] mdz: toolchain divergence is only a bootstrapping issue, since the toolchain is just another piece of the archive and chroot. [05:33] mdz it's already wrote at http://wiki.debian-hardened.org [05:33] pitti, i'm putting the new dev layout on the wiki, just a moment [05:33] ok, wonderful. when you've done that, please send me an email [05:34] mdz@canonical.com right? [05:34] correct [05:34] trulux: let's sort that out without hurry [05:34] trulux: apart from the meeting [05:34] yes, take your time [05:35] next topic? [05:35] 3) creation of a team is a community council matter [05:35] so please bring that up at the CC meeting one week from today [05:35] come prepared with someone who is willing to volunteer to lead the team === skyrider [~skyrider@195.128.178.150] has joined #ubuntu-meeting [05:36] 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] we need to move on to the next agenda item [05:36] which has to do with accessibility [05:37] Accessibility at boot: can it be done? [05:37] hno73: here? [05:37] ah, good [05:37] This is a scaled back proposal from previous ones [05:37] please see: http://www.ubuntulinux.org/wiki/AccessibilityAtBoot [05:38] I've skimmed it [05:38] the question seems redundant; either we add a boot option or not [05:38] (d-i question, that is) [05:38] hno73: what sort of guidance do you need from the technical board? [05:39] hno73: additional d-i questions are generally vetoed, I'm afraid [05:39] otherwise is everything you propose packaged and ready for testing? [05:39] they will need Mark's approval [05:39] 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] Kamion: that page discusses the live CD, rather than the installation [05:39] None of this has been developed yet, but it should be fairly basic stuff [05:40] Kamion: a convenient loophole ;-) [05:40] Though I'm not qualified to do it myself ... [05:40] hno73: for the liveCD it should be possible, guess for hoary there isnt any time for it. [05:40] I tend to agree, though beware that we'd need to turn off bootsplash if you want a prompt during boot [05:40] mdz: only in a parenthesis, most of it seems to be about the live CD [05:40] er, the install CD [05:40] also a lot of the features seem GNOME-specific, and there's already an accessibility dialog to configure those ? [05:40] 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] hno73: however, feel free to contact me via email with a bounty proposal [05:41] 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] mdz: ok, will do [05:42] It's just that the Ubuntu web page sais: "Ubuntu includes the very best in translations and accessibility infrastructure" [05:42] that is one of our goals [05:42] and we're quite far from that ATM [05:43] agreed [05:43] the major goals for the Hoary release were established months ago, and need to be nearing completion at this stage [05:44] I think there is time to do an accessible live CD, if there is someone to do the work === seb128 [~seb128@ANancy-151-1-45-42.w83-196.abo.wanadoo.fr] has joined #ubuntu-meeting [05:45] but the existing development resources are pretty much allocated for the Hoary timeframe [05:45] moving on [05:45] fabbione: kernel? [05:45] mdz: perhaps we can postpone the kernel stuff to this evening meeting? [05:45] it sounds like you're proposing a team [05:45] i think it's more appropriate for the other [05:45] well also.. [05:45] in which case it should be the CC meeting [05:46] let's skip the kernel for now [05:46] ok [05:46] sparc? [05:46] yes [05:46] this TB... [05:46] well i have main done since a long while now [05:46] tested sarge -> hoary upgrades [05:46] installed from scratch.... [05:46] only a few glitches here and there [05:47] are you proposing that sparc become an officially supported architecture for hoary? [05:47] mainly because of a few packages that i didn't spot from universe and that should be instead moved to main [05:47] i want to propose at least its inclusion in the archive [05:47] 1) main is up and running [05:48] 2) it will free a bunch of my resources to test installations [05:48] ok, I have no problem with it being part of the archive [05:48] 3) i could start building universe [05:48] and I believe Mark approved it as well [05:48] my original proposal was to have a separate archive for non-official arches... [05:48] and Mark seconded that === Keybuk has no problem either [05:48] oh? [05:49] elmo: thoughts? [05:49] mdz: something like sparc.ubuntu.com [05:49] where you see only sparc binaries [05:49] (and arch: all, presumably) [05:49] to avoid to pollute the mirrors with an arch that might as well disappear if it doesn't takeoff [05:49] what would the idea be? to make it easier to mirror only official architectures? [05:49] Kamion: clearly [05:49] mdz: an arch is still a few GB [05:50] 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] and if for example in 2 months there will be nobody doing sparc... [05:50] elmo: which do you feel makes more sense? [05:50] would we use billie for this? [05:50] we don't want to kill the mirror with it [05:50] billie? [05:50] 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] 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] elmo: yup.. we know :-) i am just taking up again the discussion to reach a full consensum with an updated status [05:51] mdz: the bit of dak Kinni wrote to do second-class-citizen [05:51] mdz: yeah, it's not like it's hppa or something. [05:51] fabbione: I know, you know, mdz didn't tho, and he asked :) [05:51] elmo: your call, as far as I'm concerned [05:52] elmo: i am happy with both the solutions [05:52] 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] i am anal to avoid problems later if something "goes wrong" [05:52] s/e$// [05:52] 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] elmo: do we have a policy that all the builds should happen on the LAN? [05:52] mdz: I'd like to make one, certainly for supported architectures [05:53] before sparc.ubuntu.com merges, i'd like to have it rebuilt on our buildds === trulux [~lorenzo@67.Red-80-25-56.pooles.rima-tde.net] has joined #ubuntu-meeting [05:53] kernel oops [05:53] sorry [05:53] elmo: agreed [05:53] elmo: agreed too. [05:53] ok, but for sparc,ubuntu.com, what will we do about builds? [05:53] even if i trust the work i did, i am not as experienced as lamont_r and you [05:53] mdz: i could ship my sparc to the DC if required... [05:54] 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] it's a U1 [05:54] fabbione: and a full rebuild is always a good thing, unless it's going to be pushed on the mirrors [05:54] elmo: use fabbione's, and have him download sources from the DC and upload binaries there? [05:54] elmo: or ship it over? [05:54] mdz: that's what i already do [05:54] fabbione: you upload binaries already? where do they go? [05:54] mdz: fabbione's remotely makes more sense to me, if he's happy to do it [05:54] I don't see much sense in shipping machines around - AFAICR that'd be reasonably expensive [05:54] mdz: people.u.c/~fabbione/sparc/ [05:55] ok [05:55] sounds like you guys are already in agreement about what to do, and it sounds fine to me [05:55] if we're going to do sparc long term, we'll get machines within a couple of days [05:55] basically moving ~fabbione/sparc/ to sparc.ubuntu.com [05:55] (for the DC) [05:55] elmo: does taht require some tweaks in the signature checking? [05:55] lamont_r: my .changes are all signed [05:55] when sparc.ubuntu.com is up, we can make an announcement about it [05:55] lamont_r: yeah, it' will [05:56] as an alpha test or something [05:56] i only need to tell elmo the key :-) [05:56] elmo: just remember that i don't have a pool over there... [05:56] there are only plain _sparc.deb [05:56] 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] fabbione: as long as you have .changes, I don't care [05:56] fabbione: as long as you promise not to upload other binaries ;-) [05:56] fabbione: so he needs to make your sig ok for sparc binary uploads, but not the others. [05:56] elmo: sure.. i have all the history of stage2 [05:57] ok, it sounds like we're finished with the meeting [05:57] mdz: i am not THAT INS4N3... YOU KNOW, DON'T YOU? :P [05:57] lamont_r: gotcha [05:57] we're finished with the set agenda, anyway [05:57] any last-minute items? [05:57] fabbione: hell - I upload binaries every now and then... I'm glad for the security blanket. [05:57] KERNEL ARFH KERNEL ARFH [05:58] Hoary meeting, is that in here at 2200 UTC? [05:58] lamont_r: i don't... remember.. i am anal.. X.. kernel... hundreds of users knocking on my door.... [05:58] Keybuk: yes [05:58] fabbione: we agreed to defer that to CC (for the team) and the hoary devel meeting (for anything else) === mako_ [mako@micha.hampshire.edu] has joined #ubuntu-meeting [05:58] mdz: i know.. i was just kidding :-) [05:59] so, hearing none, the tech board meeting is adjourned [05:59] thanks, everyone [05:59] thanks mdz [05:59] thanks guys! === ..[topic/#ubuntu-meeting:mdz] : Tuesday 4 January 2005 at 1600 UTC: Technical Board -- http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda. Tuesday 18 January 2005: Community Council meeting -- https://www.ubuntulinux.org/wiki/CommunityCouncilAgenda [05:59] cya in a few hours [05:59] thanks [05:59] did I understand that right? [05:59] we don't have hoary meeting today? [05:59] pitti: nope....wrong :) [05:59] pitti: at 22:00 UTC today === ..[topic/#ubuntu-meeting:Keybuk] : Tuesday 18 January 2005 at 1600 UTC: Technical Board -- http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda. Tuesday 11 January 2005: Community Council meeting -- https://www.ubuntulinux.org/wiki/CommunityCouncilAgenda [06:00] pitti: tonight, 2200 UTC [06:00] fabbione: because of fabbione: we agreed to defer that to CC ... [06:00]