[04:44] <titus`> hello
[05:29] <dholbach> hai
[05:29] <zul> hey dholbach 
[05:30] <hsprang> hy :)
[05:32] <dholbach> hey you two, how are you? :-)
[05:34] <hsprang> I'm fine, my flu is finally really gone today :)
[05:35] <dholbach> oh good to hear :-)
[05:35] <hsprang> i didn't tell here because there was no danger for anybody  :)
[05:35] <dholbach> hehe
[05:36] <dholbach> i think you told me in #u-m 
[05:37] <hsprang> ok.  but anyway, that was the past :)
[05:38] <hsprang> #u-m is a funny abbreviation when talking here at #u-m :)
[05:38] <dholbach> haha, you're right
[05:52] <zul> hey mdz 
[05:53] <mdz> hi
[05:53] <Kamion> can we have a reminder of the agenda URL?
[05:54] <dholbach> https://www.ubuntulinux.org/wiki/HoaryDevelopmentMeeting20050311
[05:54] <jani> hi all
[05:54] <Nafallo> hi! :-)
[05:57] <Kamion> I removed the CC meeting and the MOTU meeting because they're both some time away, and the topic was full
[05:58] <Mithrandir> can we please do the ooo2 stuff first?  I have to leave in ~1 hour and would like to contribute on that (given that it has "amd64" in the description)
[05:59] <sivang> when is the development meeting?
[05:59] <mdz> Mithrandir: funny you should ask
[05:59] <dholbach> in 45 seconds
[05:59] <mdz> Mithrandir: because doko wants to do it +30 minutes, because he'll be late
[05:59] <sivang> dholbach: ok, thanks
[05:59] <sivang> dholbach: is there a meeting now? (please excuse me)
[05:59] <Mithrandir> mdz: bah, ok, if we can do it in 30 minutes and try to make it quick, that works for me.
[05:59] <mdz> doko: ping?
[06:00] <mdz> ok, let's begin
[06:00] <mdz> is everyone here?
[06:01] <dholbach> ogra not yet
[06:01] <Kamion> here
[06:01] <dholbach> but questions regarding universe are later
[06:01] <Keybuk> here
[06:01] <dholbach> so i hope he turns up before
[06:01] <thom> here
[06:01] <mdz> fabbione: elmo thom daniels amu: jbailey doko
[06:01] <elmo> here
[06:01] <fabbione> here
[06:02] <seb128> hey
[06:02] <mdz> doko said he may be late due to cebit; pinging amu and jbailey
[06:02] <haggai> doko is next to me setting up network
[06:03] <jbailey>  I'm here. =)
[06:03] <mdz> haggai: is his ETA still 1730?
[06:04] <dholbach> hi doko 
[06:04] <mdz> doko_: thanks
[06:04] <lamont> her
[06:04] <lamont> e
[06:04] <mdz> doko_: is amu with you also?
[06:04] <doko_> no
[06:05] <haggai> amu isn't at cebit
[06:05] <pitti> Hi ogra
[06:05] <sivang> hey ogra 
[06:05] <mdz> ok, so let's begin
[06:05] <ogra> hi, pumount just hardlocked my system :(
[06:05] <mdz> we'll skip ahead to oo.o2 since Mithrandir needs to leave
[06:06] <mdz> haggai: would like your confirmation on this stuff as well
[06:06] <pitti> ogra: ibreakify
[06:06] <haggai> righty
[06:06] <mdz> my understanding is that we have three issues to address: Java/Help, amd64 support, and bugs
[06:06] <haggai> doko & I have just been talking about java and ant
[06:06] <mdz> any conclusions?
[06:06] <pitti> mdz: not ia64?
[06:06] <ogra> argh, pitti, youre right, i forgot that i used the 2.6.11 snapshot for testing.... sorry for the noise
[06:06] <mdz> pitti: not for hoary
[06:07] <haggai> we may have a workaround (thanks to rene) using libant instead of ant, which is already possible to get into main
[06:07] <mdz> pitti: if it happens, great, if not, we are still OK
[06:07] <jbailey> Thibaut claims OOo works on ia64 now.
[06:07] <mdz> jbailey: 1.1.x
[06:07] <Kamion> jbailey: right, for OOo1
[06:07] <doko_> libant's build-deps are installable in hoary as well
[06:08] <mdz> libant as in libantX.Y-java?
[06:08] <Kamion> I assume we aren't going for OOo2 by default?
[06:08] <mdz> or is there a libant in C or something?
[06:08] <wasabi_> hi.
[06:08] <haggai> Kamion: sabdfl is keen to get OOo2 in, and Novell are doing it too
[06:08] <mdz> Kamion: sabdfl wants us to make the attempt
[06:08] <Mithrandir> jbailey: OOo1 works on ia64, yes.  I ran it off t-bone's server last night.
[06:08] <doko_> libant's dependency list is a much shorter than the one for ant
[06:08] <wasabi_> doko, did you check out the OTHER libant?
[06:08] <Kamion> ok
[06:08] <wasabi_> yeah.
[06:08] <wasabi_> the one for ant includes non-free pieces.
[06:09] <mdz> haggai: ant is used purely at build-time, right?
[06:09] <doko_> the patched one from fedora?
[06:09] <haggai> mdz: yes
[06:09] <mdz> haggai: to generate the help data?
[06:10] <haggai> mdz: no, for docbook/xml filters and scripting
[06:10] <haggai> mdz: ie not essential
[06:10] <haggai> mdz: but it would still need work to patch those out
[06:10] <mdz> haggai: we have docbook/xml tools in main already
[06:10] <mdz> what would the methodology be for ant?
[06:10] <haggai> mdz: and if we're going to do work it would be imo better to do it on ant rather than patch OOo
[06:10] <mdz> build it and its deps using gcj, or use gij, or what?
[06:10] <wasabi_> What's up with this discussion about ant?
[06:11] <wasabi_> I have packages half made that fix Ant up.
[06:11] <mdz> wasabi_: see agenda
[06:11] <mdz> wasabi_: we've skipped to the end due to scheduling
[06:11] <wasabi_> #Other business?
[06:11] <haggai> mdz: current debian libant builds using jikes & sablevm
[06:11] <thom> wasabi_: OOo2
[06:11] <wasabi_> and does not produce /usr/bin/ant
[06:11] <wasabi_> Ahhhh.
[06:12] <mdz> wasabi_: this is an Ubuntu development meeting, the agenda is at https://www.ubuntulinux.org/wiki/HoaryDevelopmentMeeting20050311
[06:12] <haggai> wasabi_: that's ok I said we have a workaround for /usr/bin/ant
[06:12] <wasabi_> I am a bit afriad about doing Ant wrong. It's not just there for OOo.
[06:12] <mdz> what's the short list of tasks to get it building using the ant approach?
[06:12] <haggai> wasabi_: ? I'm only trying to find a short term soln
[06:13] <wasabi_> k
[06:13] <haggai> mdz: get libant in main and then build OOo with it
[06:14] <wasabi_> http://kyoto.larvalstage.net/ubuntu/hoary/ant_1.6.2-2ubuntu0.dsc
[06:14] <doko_> mdz: libant1.6, not the current  1.5 in hoary
[06:14] <wasabi_> ^ work in progress
[06:14] <mdz> haggai: a bit less short than that.  :-) what's involved in getting libant into main, and how do we use libant in place of ant?
[06:14] <mdz> have you already attempted to use libant in the build?
[06:14] <wasabi_> mdz, http://www.ubuntulinux.org/wiki/JavaPackagingProgress
[06:14] <haggai> getting into main: fix broken build
[06:14] <wasabi_> Look at the first entry.
[06:15] <haggai> *** Semantic Error: You need to modify your classpath, sourcepath, bootclasspath, and/or extdirs setup. Jikes could not find package "java.lang" in:
[06:15] <haggai> etc
[06:15] <wasabi_> Ant has a lot of deps, which need to be in main too.
[06:15] <haggai> rene has got OOo building with a patch he authored for libant
[06:15] <wasabi_> Almost all of Ant's depends dependend on Ant themselves. ;)
[06:15] <mdz> wasabi_: that's just bookkeeping; we need to establish the plan for actually doing the work
[06:15] <haggai> http://cvs.gnome.org/viewcvs/ooo-build/patches/src680/ant-only-main-classes-hack.diff?rev=1.2&view=markup is the hack at the moment.
[06:16] <wasabi_> Well, I mean. All that needs to be done is to start pulling apart all those dependencies one after another.
[06:16] <wasabi_> What is the VM goal?
[06:16] <mdz> there is none
[06:16] <mdz> the goal is getting oo.o2 building
[06:16] <haggai> what isn't yet clear is what to do about the needing gcj >> 3.3
[06:16] <wasabi_> Ooo requires a VM, rigth?
[06:16] <jbailey> There's a status update from yesterday on the Fedora list (provided by Robilad) for building on gcj: http://thread.gmane.org/gmane.linux.redhat.fedora.java/149
[06:17] <wasabi_> And Ant requires one to build. So we need to pick on. Me and jbailey have been planning to use gcj4 (because it works)
[06:17] <mdz> wasabi_: <haggai> mdz: current debian libant builds using jikes & sablevm
[06:17] <mdz> haggai: which part of this needs gcj >> 3.3?
[06:18] <mdz> and we do have gcj-4.0 available if needed
[06:18] <haggai> mdz: there are several bugs that OOo+java triggers in earlier gcjs
[06:18] <haggai> mdz: I know its available, problem is we then may need gcc/++ 3.4 or 4.0 too
[06:19] <mdz> haggai: what about jikes+sablevm?
[06:19] <mdz> this is very much sounding like more work than diking out ant
[06:20] <mdz> as a temporary workaround
[06:20] <wasabi_> uh huh.
[06:20] <jbailey> sablevm will probably need an update to make sure it has all the latest GUI stuff.
[06:20] <haggai> mdz: for OOo?  You really don't want to try new toolchains with OOo at this stage
[06:20] <haggai> mdz: or do you mean for ant?
[06:20] <mdz> haggai: I mean for both
[06:20] <doko_> according to haggai, all C++ libs needed for OO are included in the sources, so C++ ABI problems shouldn't be an issue.
[06:21] <mdz> getting ant, gcj, etc. all into harmony sounds like a better long-term solution, but what we need at this stage is more along the "short term hack" lines
[06:21] <haggai> mdz: ant is built with jikes+sablevm in debian, so I was assuming it wouldn't be a lot to use with ubuntu and was such a short hack.  I didn't mean jikes+sablevm for OOo build
[06:22] <wasabi_> Is anybody aware of the the Javaintegration wiki page and our plans for Java?
[06:22] <wasabi_> Just don't want to duplicate work here.
[06:23] <haggai> wasabi_: we're looking for a short, very quick, hack
[06:23] <mdz> I'm weighing "get libant and its dependency chain working with jikes+sablevm or gcj, may require updating one or both, modify oo.o build to use libant, get gcj/etc. working to the point of being able to drive this part of the oo.o2 build, etc." vs. "replace the libant portion of the build with a shell script"
[06:23] <wasabi_> Okay. I get it.
[06:23] <mdz> wasabi_: we have a very specific, short-term goal here.  If hte JavaIntegration plan can do this within the next couple of days, great, if not, it isn't an option
[06:24] <wasabi_> I would then suggest making a temporary libant just for Ooo and building it with ecj-bootstrap + gcj3.
[06:24] <wasabi_> =)
[06:24] <doko_> mdz: so, recording the gcj/gij calls made from ant, and "replay" them with the shell script?
[06:25] <wasabi_> ecj-bootstrap is in.. universe right now. It is however a very simple package... and can probably be done with gcj3
[06:25] <mdz> haggai: what about pregenerating the docs?
[06:25] <wasabi_> oh wow. that's more hacky than I wanted to get into. ;)
[06:25] <mdz> doko_: I mean using the existing tools to do docbook/xml operations, rather than java
[06:25] <mdz> eliminating the java dep entirely
[06:26] <mdz> feasible?
[06:26] <haggai> mdz: hmm maybe we're not talkiung about the same feature.  This is import/export support for docbook and xml formats from within OOo
[06:26] <mdz> haggai: hmm, apparently we were not
[06:26] <mdz> haggai: I thought you meant docbook/xml transformations for the help system data
[06:26] <haggai> mdz: ah :)
[06:27] <wasabi_> Can somebody tell me what Ant features are required for OOo?
[06:27] <wasabi_> I can check to see if I can whip something up.
[06:27] <haggai> mdz: right, no it's a special tool written in java to transform the help sources
[06:27] <mdz> oh, nice. ooffice2 crashes on startup for me now
[06:27] <haggai> mdz: if all we are interested in is the help docs, we can do this another way without enabling java in OOo itself
[06:28] <mdz> haggai: would this be a regression from 1.1.3?
[06:28] <amu> rehi
[06:28] <haggai> mdz: no
[06:28] <mdz> haggai: forget it, then, let's not enable that feature
[06:28] <mdz> haggai: and only worry about the docs
[06:29] <haggai> mdz: (we went over these things in that thread between sabdfl & I that you were cced on)
[06:29] <mdz> haggai: yes, and now we're back to where I thought we were at the start of this conversation
[06:29] <mdz> which is that we're talking about building the documentation
[06:30] <haggai> in that case I read Java/help wrong..
[06:31] <mdz> haggai: in what part of the source tree does this stuff live?
[06:32] <haggai> mdz: xmlhelp is the tool
[06:32] <haggai> mdz: has rather a lot of dependencies :(
[06:32] <haggai> xmlhelp :       ucbhelper XmlSearch sablot jut unoil berkeleydb
[06:32] <haggai> so that's not going to be trivially easy to split out
[06:33] <mdz> ok, there's more to talk about here than I thought
[06:33] <mdz> we need to split this out into a separate meeting
[06:33] <mdz> haggai, doko: when can we reconvene?
[06:34] <doko_> mdz: one moment ...
[06:34] <mdz> Mithrandir: the amd64-relevant bit is determining whether we can build it natively, or if it needs the oo.o2-amd64 treatment, not much more thana that
[06:34] <Mithrandir> I've begun looking on amd64 and powerpc wrt ooo2, but so far it has had conflicting build-deps.  seb128 has sorted that out and is uploading {now,shortly}.  amd64 ooo2 is rumored to build, but being amazingly brittle (on amd64)
[06:34] <Mithrandir> (build with a few patches)
[06:35] <Mithrandir> mdz: sabdfl has asked me to take a look at it and give him feedback with cc to you.
[06:35] <seb128> Mithrandir: I've uploaded eds 
[06:35] <mdz> ok
[06:35] <Mithrandir> as I haven't actually built it myself yet, I can't say anything about it's brittleness or not.
[06:35] <mdz> doko_, haggai: get back to me with possible meeting times
[06:35] <mdz> we need to move on
[06:35] <Mithrandir> so "maybe"
[06:35] <mdz> fabbione: kernel
[06:35] <haggai> mdz: ok
[06:35] <fabbione> yes
[06:35] <Mithrandir> but I would be conservative and say no for now.
[06:36] <mdz> inotify or dnotify for hoary?
[06:36] <fabbione> default: dnotify
[06:36] <fabbione> inotify optional as bootparameter
[06:36] <fabbione> patches have been cleaned up in -26
[06:36] <fabbione> to be more robust
[06:36] <mdz> seb128: is there some other way to address the bugs which were fixed by inotify?
[06:37] <mdz> iirc, the "volume icons not appearing" stuff was fixed by dnotify->inotify, and has now regressed
[06:37] <seb128> nop
[06:37] <seb128> ?
[06:37] <seb128> that's the other way IIRC, volumes icons should work fine with dnotify
[06:37] <tseng> they do
[06:37] <fabbione> mdz: inotify is a better way to do dnotify
[06:37] <tseng> inotify doesnt break it, gamin does
[06:37] <seb128> inotify with the "busy drives" issue
[06:37] <fabbione> it doesn't fix anything
[06:37] <tseng> gamin fix doesnt work on its inotify backend
[06:37] <fabbione> it is suppose to improve performance
[06:38] <seb128> fabbione: it does
[06:38] <mdz> the "busy drives" issue was worked around in gamin by special-casing /media, yes?
[06:38] <tseng> yes
[06:38] <tseng> but
[06:38] <seb128> fabbione: no need to have a fd on the device to monitor stuff, so no drives locked
[06:38] <tseng> inotify in gamin cant use polling special case
[06:38] <tseng> so we have regression on volume icons showing up
[06:38] <mdz> ok, so in fact it is fixed for dnotify only
[06:38] <tseng> but no locking of the device as with dnotify before fix
[06:38] <Kamion> so in fact we're just better off with dnotify all round?
[06:38] <tseng> Kamion: yep.
[06:38] <tseng> until gamin gets real support anyway
[06:39] <fabbione> so you want me to remove dnotify as well?
[06:39] <seb128> no no, why ?
[06:39] <tseng> erm? I think dnotify should be default atm
[06:39] <fabbione> ah ok
[06:39] <tseng> works well with latest gamin
[06:39] <mdz> http://bugzilla.ubuntu.com/show_bug.cgi?id=4597
[06:39] <fabbione> i misread your sentence Kamion
[06:39] <mdz> that is the bug I was thinking of
[06:40] <mdz> but apparently the user was mistaken
[06:40] <mdz> though I'm not entireyl convinced
[06:40] <tseng> mdz: no
[06:40] <mdz> there are reports of the icons not appearing
[06:40] <tseng> mdz: we still get that with gamin + inotify
[06:40] <seb128> mdz: that's fixed by switching to dnotify
[06:40] <mdz> but the user reported it with -25.2, which has inotify disabled
[06:40] <pitti> mdz: I have heaps of other bugs related to this issue
[06:40] <pitti> mdz: so the current situation is really broken
[06:41] <mdz> pitti: can you group them together somehow?
[06:41] <seb128> mdz: yeah, I've reassigned some of them to pitti
[06:41] <pitti> mdz: I can't close them as duplicates, but I can do a metabug
[06:41] <ogra> mdz: there are also reports of icons not dissapearing after unmount
[06:41] <mdz> pitti: that would be helpful
[06:41] <tseng> ok can I explain breifly again? to avoid any confusion
[06:41] <tseng> about the bug mdz posted
[06:41] <mdz> since inotify is a bust, we need to find some other way to fix those problems, they affect many users
[06:42] <tseng> the bug posted affected all gamin users at one point. it was fixed by falling back to polling /media/*
[06:42] <mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=6088
[06:42] <pitti> so we can use polling?
[06:42] <tseng> gamins inotify backend *doesnt support* polling
[06:42] <tseng> so the bug still exists on inotify kernels
[06:42] <seb128> forget about inotify
[06:42] <pitti> tseng: I mean with dnotify?
[06:42] <seb128> we run dnotify atm
[06:42] <tseng> its fixed for everyone else
[06:42] <tseng> or, fixed for all my systems
[06:44] <mdz> there are still an awful lot of bugs appearing around this area, as pitti says
[06:44] <pitti> mdz: however, they might be from the time when we still had inotify and similar
[06:44] <seb128> yeah, we need to figure what bugs happen with dnotify and gamin 0.0.25
[06:44] <mdz> pitti: when you've collected a list, please work with tseng and seb128 and see which ones are still valid
[06:44] <pitti> mdz: most of them were reassigned to me today /yesterday, I did not yet have time to evaulate
[06:44] <pitti> mdz: I'll do
[06:44] <mdz> and if the remainder are significant, we can decide what to do
[06:45] <mdz> moving on
[06:45] <pitti> mdz: I think we can defer this some days, then I can actually evaluate them
[06:45] <mdz> the other kernel item, we have occasionally discussed adding a kernel to the i386 CD
[06:45] <fabbione> Kamion: what kernel do we ship on cd?
[06:45] <mdz> fabbione: -386
[06:45] <mdz> only
[06:45] <mdz> which means no higmem support, and no SMP support
[06:45] <pitti> we have ~70 MB
[06:46] <mdz> pitti: how much for the remaining langpacks?
[06:46] <pitti> in comparision to ppc and amd64
[06:46] <fabbione> i think that either we add 686 and k7 or none
[06:46] <pitti> mdz: ppc would allow 42 MB for langpacks
[06:46] <mdz> Kamion: can we do per-arch germination of ship?
[06:46] <fabbione> otherwise users will be discriminated
[06:46] <fabbione> but hounestly i really prefer to save space on CD
[06:46] <mdz> fabbione: -686 works on both
[06:46] <elmo> mdz: eh?
[06:46] <fabbione> mdz: nope...
[06:47] <mdz> herbert says otherwise
[06:47] <fabbione> not here at least
[06:47] <Kamion> sorry, catching up, one sec
[06:47] <Kamion> -686 does not work on both as far as I know
[06:47] <mdz> the last time we spoke about it, he said that it was not guaranteed in general, but that it was currently true
[06:47] <fabbione> mdz: that makes it an non option for me
[06:48] <fabbione> we so do NOT want to get bugs because there is the wrong kernel installed
[06:48] <Kamion> mdz: adding a kernel is trivial, and I think a good idea; some minor base-installer improvements are needed to make it work well (i.e. proper fallback ordering)
[06:48] <Kamion> but I already have those in progress
[06:48] <pitti> 70 MB would be enough for 2 additional kernels?
[06:48] <Kamion> I see no reason not to add both 686 and k7, frankly
[06:48] <pitti> SMP?
[06:48] <fabbione> Kamion: space
[06:48] <Kamion> no
[06:48] <mdz> Kamion: I do; they're huge
[06:48] <Kamion> we already have to reserve that space!
[06:48] <Kamion> because powerpc requires three kernels
[06:48] <Kamion> so we have to reserve the space arch-independently anyway
[06:48] <mdz> Kamion: I was asking whether we could use per-arch items in ship
[06:49] <Kamion> mdz: we already do per-arch germination of ship
[06:49] <mdz> because we may NOT be egalitarian about this
[06:49] <pitti> can a SMP kernel run on a non-SMP machine?
[06:49] <mdz> if we have room for more language support on i386, we may do that
[06:49] <ogra> sure
[06:49] <T-Bone> pitti: yes
[06:49] <thom> pitti: yes
[06:49] <fabbione> pitti: not always
[06:49] <jbailey> pitti: Generally.
[06:49] <mdz> pitti: yes, but with a performance penalty
[06:49] <T-Bone> what mdz said
[06:49] <mdz> I have no idea of the numbers
[06:49] <T-Bone> depends on the arch
[06:49] <fabbione> smp kernel on sparc doesn't boot on a  UP box
[06:49] <mdz> fabbione: what about highmem in -386?
[06:50] <pitti> T-Bone: I mean 386
[06:50] <T-Bone> can amount to a few percents in general
[06:50] <mdz> is that possible?
[06:50] <pitti> we don't have additional space on ppc/amd64 anyway
[06:50] <lamont> nonSMP allows you to stub out the mutual-exclusion that you need in SMP.. depending on the architecture, that can be anywhere from 0+ to large
[06:50] <fabbione> mdz: iirc there were several reasons for not doing it
[06:50] <lamont> (large == <10%)
[06:50] <Kamion> pitti: amd64 isn't so bad
[06:50] <Kamion> but mdz's right, we could decide to make language support asymmetric
[06:50] <mdz> pitti: what is the total size of the remaining langpacks which are not already in ship+live?
[06:50] <fabbione> mdz: let me check.. one sec
[06:50] <pitti> Kamion: oh right, mixed that up with ia64
[06:50] <pitti> mdz: 45 MB
[06:50] <Kamion> mdz: note that the live CDs are currently maxed out due to the addition of WinFOSS
[06:51] <pitti> mdz: (not including the support packages)
[06:51] <Kamion> mdz: amd64 is right at the limit; i386 is about 20MB below
[06:51] <pitti> mdz: but we only have about 42 MB left for ppc
[06:51] <pitti> mdz: we miss by a few MB
[06:51] <Kamion> and amd64 tends to grow
[06:51] <mdz> Kamion: that's based on the Warty amount of winfoss, or the full set?
[06:51] <pitti> mdz: however, we could strip a few packages to get them
[06:51] <Kamion> I've asked Henrik to cut it down a little
[06:51] <dholbach> dumb question: are packages on the CD already using bzip2 compression?
[06:51] <Kamion> mdz: that's current, I added WinFOSS this morning
[06:51] <hno73> I'm currently uploading a win-foss pack shrunk by 7mb
[06:51] <mdz> I don't mind shipping the Warty amount at all; that was ~half the size
[06:51] <Kamion> dholbach: some are, but bzip2 has a speed penalty
[06:51] <dholbach> Kamion: shouldnt it be taken into account?
[06:52] <Kamion> dholbach: we have done it for some packages based on what seemed sensible
[06:52] <hno73> I should be able to get out a further 3-4mb wihout removing more apps
[06:52] <Kamion> where it was most effective
[06:52] <Kamion> it's a speed/size tradeoff
[06:52] <ogra> dholbach: unpacking may take ages on some systems
[06:52] <fabbione> mdz: it should be possible to enable it. but we will need to check it very carefully
[06:52] <dholbach> well since we're short on size...
[06:52] <mdz> fabbione: ok, that doesn't sound very good for a post-preview change
[06:52] <Kamion> dholbach: size isn't everything :-)
[06:53] <ogra> heh
[06:53] <fabbione> mdz: but my memory recalls something bad about it
[06:53] <dholbach> Kamion : haha :-)
[06:53] <fabbione> mdz: i just do not remember what
[06:53] <mdz> compressing the -686+ and -k7+ kernels with bzip2 is not a bad option
[06:53] <mdz> they will only be installed on reasonably modern systems
[06:53] <fabbione> mdz: yes it is
[06:53] <Kamion> hno73: what are the app differences between what was on Warty and what's in Hoary?
[06:53] <fabbione> mdz: we did test them and we gain 0
[06:53] <fabbione> mdz: the only package gaining was -doc-
[06:53] <mdz> _0_?
[06:53] <hno73> Upgraded versions and PDFCreator removed
[06:53] <Kamion> dholbach: we compress all the language packs with bzip2; they exhibited a substantial gain
[06:54] <fabbione> mdz: compressing the images with bzip2, we lost around 5/8% on the image
[06:54] <dholbach> Kamion: i can easily imagine
[06:54] <Kamion> hm, so how come Warty's was half the size of Hoary's according to mdz?
[06:54] <fabbione> we did this test when bzip2 was brand new and shiny
[06:55] <mdz> Kamion: I'm not sure what hoary's is at this point
[06:55] <mdz> Kamion: what I do know is that for warty, we removed things
[06:55] <mdz> that astronomy program, e.g.
[06:55] <Kamion> ah; is hno73 up to date with those removals?
[06:55] <dholbach> gtranslator as well
[06:55] <mdz> I was asking earlier whether we are using the same set of stuff for hoary
[06:56] <mdz> mizar:[/space/cache/apt/archives]  dpkg --fsys-tarfile linux-image-2.6.10-4-k7_2.6.10-26_i386.deb | gzip -9v >/dev/null; dpkg --fsys-tarfile linux-image-2.6.10-4-k7_2.6.10-26_i386.deb | bzip2 -9 -v >/dev/null
[06:56] <mdz>  62.9%
[06:56] <mdz>   (stdin):  3.018:1,  2.650 bits/byte, 66.87% saved, 44748800 in, 14825047 out.
[06:56] <mdz> fabbione: 62.9% vs. 66.87%
[06:56] <fabbione> mdz: the images were big and i am sure about it.
[06:56] <fabbione> i can retest it if you want
[06:57] <hno73> We removed Celestia, etc. for Warty, but it hasn't been put back in
[06:57] <doko_> mdz: we have to leave the booth around 6:45 UTC, Chris will be available tomorrow 5pm UTC for an hour or so. That time is ok for me as well (I'm at home tomorrow almost the whole time). Disscussing the help build with haggai, it looks like prebuilding the docs and including these in the package might be a short term solution as well.
[06:57] <fabbione> mdz: and you need to check using make-kpkg because it does a lot of weird magic to build the deb
[06:57] <fabbione> compressing that way is not the same apparently
[06:57] <hno73> I've built the Hoary Win-FOSS from a Warty CD content source, just updating stuff
[06:58] <hno73> Warty size 115MB, current Hoary size 108MB
[06:59] <fabbione> mdz: anyway.. HIGHMEM on i386 for me is a too big risk right now
[06:59] <fabbione> and adding new kernels.. up to you but do not rely on 686 works on k7-smp
[06:59] <fabbione> or stuff like that
[07:01] <Kamion> I don't think changing base-installer to assume 686 works on k7 would be a good idea, certainly
[07:01] <Kamion> that code ought to be safe, or it comes back to bite you
[07:01] <amu> Win-FOSS, we add it also to kubuntu?  
[07:02] <fabbione> Kamion: +1
[07:02] <Kamion> in any case, the improvement appears to be 1.8MB for bzip2 of -k7 at the moment; doesn't really seem like a significant win
[07:02] <Kamion> amu: if you like, but I'm not sure you have room at the moment
[07:02] <pitti> mdz: I'd rather strip some more packages, that will give us ~10 MB
[07:03] <Kamion> amu: you probably just about have room on i386
[07:03] <amu> Kamion: i would like, cause it soo cool, btw. ppc is 610mb atm
[07:03] <pitti> mdz: e. g. dpkg is a hog, and will be rebuilt anyway (hopefully) to fix the Replaces: bug
[07:03] <Kamion> amu: WinFOSS only goes on i386 and maybe amd64
[07:03] <hno73> amu: I can always make a version sans OOo
[07:03] <hno73> that'll work
[07:04] <Kamion> amu: ok, Kubuntu CD changes are pretty much by request of you guys FWIW
[07:04] <T-Bone> fabbione: just my 2cents but I bet that users with machine having enough ram to need HIGHMEM will update their kernel to use one corresponding exactly to their CPU anyway...
[07:04] <amu> Kamion: i386 537, amd64, 557mb
[07:04] <fabbione> T-Bone: that too
[07:04] <Kamion> amu: it won't currently fit on amd64, but I'll add it to your i386 live CD
[07:05] <T-Bone> (it'd be rather silly to run i386 kernel on a Dual Xeon P4... :)
[07:05] <amu> Kamion: hno73: i would like it, let's delay it, till we get an prefinal iso 
[07:05] <Kamion> amu: (better to do these things earlier rather than later in my experience, but whatever you like)
[07:05] <amu> Kamion: ok, that's an better solution, pls do it like this
[07:06] <amu> Kamion: ack
[07:06] <fabbione> brb
[07:06] <dholbach> couldnt there be script checking if bzip2 saves at least x% and then use bzip2? so users with an old box wouldnt have the pain generally?
[07:07] <hno73> amu: email me about the Win-FOSS stuff for Kubuntu and we'll work something out
[07:07] <amu> i would say, i've also some problems with the default kernel, my ltop has 2 gig ram, no prob for me maybe for others 
[07:08] <amu> hno73: cool, phone is already prefered? ;)
[07:09] <mvo> desktop now?
[07:09] <fabbione> re
[07:10] <T-Bone> sivang: that's way enough for irc ;o)
[07:10] <amu> hehe :P
[07:10] <Treenaks> sivang: don't complain, I IRC using GPRS sometimes
[07:10] <sivang> T-Bone: yeah, but just about for that :)
[07:10] <Kamion> ok, I think we're done with kernel
[07:11] <sivang> Treenaks: god, what's the specs from such a connection/
[07:11] <Kamion> g-a-i .desktop database
[07:11] <Kamion> who's responsible for that?
[07:11] <mvo> Kamion: is jdub around?
[07:11] <dholbach> he said he was too tired on the list
[07:11] <mvo> Kamion: ross and jdub, but ross is on vacation
[07:11] <Kamion> no, he's gone to sleep
[07:11] <fabbione> mvo: no
[07:11] <sivang> doesn't seem so
[07:11] <Kamion> mvo: do you know the current status?
[07:11] <mvo> Kamion: I branched ross archive to add i18n updates and small fixes
[07:11] <Kamion> amu: ok, you'll get WinFOSS on the next Kubuntu live-i386 build
[07:12] <dholbach> Kamion: jdub said: 1) g-a-i data drop to be delivered this weekend.
[07:12] <mvo> but I don't know if jdub wants to do the .desktop stuff himself
[07:12] <amu> Kamion: rock
[07:12] <mvo> dholbach: ah, cool
[07:12] <dholbach> reference: http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/005473.html
[07:13] <mvo> ok, I'll contact jdub 
[07:13] <mvo> evince?
[07:13] <Kamion> ok, I guess that satisfies that agenda item
[07:13] <sivang> mvo: what's in it for doing the .desktop files?
[07:13] <mvo> sivang: later please :)
[07:13] <sivang> mvo: oops right 
[07:14] <dholbach> evince rocks, but somebody said it had problems with CUPS integration, but i don't know if it's exactly true
[07:14] <thom> personally, i think we should go for evince 
[07:14] <ogra> is evince matured enough ?
[07:14] <Kamion> seb128: opinion on evince?
[07:14] <seb128> evince is pretty, use gnome printing, is localized
[07:14] <sivang> seb128: misses some fonts no?
[07:14] <Kamion> there was some talk about problems with large PDF files
[07:14] <seb128> sivang: ?
[07:14] <pitti> and sucks for large documents :-)
[07:14] <elmo> "iz pretty".  you sold me ;-)
[07:14] <seb128> elmo: look on xpdf, that's ugly
[07:14] <thom> pitti: only for you
[07:14] <sivang> seb128: I recalled jdub saying something about it
[07:14] <sivang> seb128: I may be wrong
[07:14] <pitti> seb128: would it be possible to sanitize the thumbnail generation?
[07:14] <thom> sivang: that's gpdf
[07:15] <elmo> seb128: does it have gpdf's problem with fonts?
[07:15] <Kamion> oh, I wonder what happened to mdz
[07:15] <seb128> sivang: if you have evidence to point, do it, but don't come now with random idea :p
[07:15] <elmo> and/or only displaying 1/5 of the docs xpdf does
[07:15] <ogra> elmo: it uses xpdf afaik
[07:15] <elmo> ok
[07:15] <seb128> elmo: nop
[07:15] <seb128> it is as good as xpdf
[07:15] <sivang> seb128: ok, sorry 
[07:15] <fabbione> Kamion: when the elder are off... the mice party!
[07:15] <seb128> pitti: probably
[07:16] <seb128> pitti: we can generate them only if the side pane is open
[07:16] <seb128> or add a gconf key
[07:16] <sivang> then what's the issue here? it looks far better and has much better and user freindly ui
[07:16] <pitti> seb128: lower priority thread
[07:16] <seb128> upstream are threading it for that, but that's not for hoary probably
[07:16] <pitti> otherwise thumbs up for evince
[07:16] <seb128> pitti: it's not threaded atm
[07:16] <jani> it doesn't seem to have 'recent documents'
[07:17] <mvo> nor does xpdf?
[07:17] <seb128> jani: xpdf neither
[07:17] <jani> and I think case sensitive search
[07:17] <sivang> pitti++
[07:17] <jani> oh, was comparing to acroread ;)
[07:17] <Kamion> ok, general opinion seems to be in favour of evince, if the thumbnail generation is made faster
[07:17] <jani> otherwise really nioce
[07:17] <seb128> jani: the current default is xpdf
[07:17] <jani> oh better than xpdf by all means
[07:17] <Kamion> but would like to wait to see what mdz says about switching at this late stage
[07:17] <seb128> Kamion: thumbnail is not really an issue imho
[07:17] <mvo> Kamion: ++
[07:17] <Kamion> let's move on
[07:17] <Kamion> gksu
[07:18] <ogra> ugly behavior....
[07:18] <Kamion> mvo: has the gksu issue on the agenda been fixed by your upload today?
[07:18] <seb128> nop
[07:18] <mvo> Kamion: not, not all issues
[07:18] <mvo> some
[07:18] <Kamion> what are the remaining issues?
[07:18] <seb128> do we want to grab the keyboard mouse or not ?
[07:18] <mvo> the big problem is that it can go into the background and then grabs the mouse 
[07:18] <ogra> it would be ok if the pointer wouldnt get stuck ...
[07:19] <pitti> seb128: why should it grab?
[07:19] <seb128> there is some bug open saying that we should not grab them ...
[07:19] <ogra> i often have the angle pointer instead of the arrow locked..... 
[07:19] <Kamion> I think you have to grab
[07:19] <mvo> the user clicks on sth that needs gksu and then starts something else. it may happen that the gksudo window comes up, then the other window comes up (over gksudo) and then gksudo grabs the pointer and users are very confused
[07:19] <Kamion> surely
[07:19] <seb128> pitti: I don't see a real reason to do it, basically kov says that's to not get something getting up and grabing the password
[07:19] <seb128> but with the new metacity ...
[07:19] <mvo> ogra: angle-pointer should be fixed by the upload today
[07:20] <ogra> yay
[07:20] <Kamion> not everyone is using metacity ...
[07:20] <seb128> right
[07:20] <pitti> Kamion: other apps can certainly steal the password even with grabbing
[07:20] <seb128> but is "random app can get the focus" a security issue ?
[07:20] <Nafallo> we should not grab it. shouldn't users became confused and start looking when nothing upons by clicking something?
[07:21] <Nafallo> s/upon/open/
[07:21] <pitti> seb128: why can't the window appear in the foreground, always?
[07:21] <mvo> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=7432
[07:21] <ogra> Nafallo: they will hit the reset button i guess
[07:21] <mvo> it's the focus stealing stuff 
[07:21] <sivang> s/since/until/
[07:22] <seb128> mvo: if you interact on something during the starting time metacity don't steal your focus
[07:22] <Kamion> pitti: it helps a bit, though; certainly ssh-askpass-gnome grabs keyboard and pointer for that reason
[07:22] <Nafallo> ogra: they would if they thinks input devices hung to ;-)
[07:22] <Kamion> mdz sent me an SMS saying that he's involuntarily offline; we'll keep going
[07:22] <pitti> Kamion: okay, I would at least require either grab _and_ foreground, or nothing
[07:22] <ogra> Nafallo: every input is locked
[07:23] <seb128> pitti: right, if we grab we need to fix the foreground
[07:23] <pitti> Kamion: but I don't see why inter-process-communication should be blocked by keyboard/mouse grabbing?
[07:23] <seb128> the question is to know if we want to grab or not
[07:23] <Kamion> IMHO gksu should grab the X server
[07:23] <Kamion>  * There is only two run-time options: if you set the environment variable
[07:23] <Kamion>  * "GNOME_SSH_ASKPASS_GRAB_SERVER=true" then gnome-ssh-askpass will grab
[07:23] <Kamion>  * the X server. If you set "GNOME_SSH_ASKPASS_GRAB_POINTER=true", then the
[07:23] <Kamion>  * pointer will be grabbed too. These may have some benefit to security if
[07:23] <Kamion>  * you don't trust your X server. We grab the keyboard always.
[07:23] <Kamion> Nafallo: there'll be a password window in the foreground waiting for input; it will be obvious
[07:23] <pitti> so the only sane solution is grab+foreground
[07:24] <Nafallo> hmm, me actually likes being able to open synaptic on desk #1 and when done loading change desktop and open other stuff before going back and type in password.
[07:24] <Nafallo> Kamion: yea, I know :-)
[07:24] <Nafallo> btw, the final decision is that it should have borders?
[07:24] <seb128> loading is that long for you ?
[07:25] <Kamion> there seem to be clear security benefits to grabbing the X server and keyboard while requesting a password
[07:25] <seb128> what kind of box do you have ?
[07:25] <lamont> Kamion: definitely
[07:25] <pitti> Kamion: then the only solution seems to be clear
[07:25] <seb128> Nafallo: 
[07:25] <mvo> the problem is to teach gksu to be in the foreground all the time
[07:25] <Nafallo> seb128: nope, I just like to start all tasks I need early as possible to save battery time :-).
[07:25] <sivang> Kamion++
[07:25] <Nafallo> seb128: amd64 1,6GHz, 1GB ram, laptop
[07:25] <seb128> Nafallo: you have a -g option to gksudo to not grab the events
[07:26] <Kamion> how about gtk_window_set_keep_above()?
[07:26] <Nafallo> seb128: ahh, kewl. didn't knew that. not an issue for power-users then :-).
[07:26] <seb128> ok, let's keep the grabing and fix the issue
[07:26] <pitti> next point?
[07:26] <Kamion> Documentation
[07:26] <Nafallo> seb128: ++ in that case :-)
[07:26] <Kamion> Yelp fixes needed for Hoary?
[07:27] <seb128> mvo: I'll ping the metacity guys to know of to force the first plan/focus
[07:27] <Kamion> jdub's mail sort of covered that
[07:27] <sivang> Kamion: we need to make the docs more accessible form yelp toplevel
[07:27] <seb128> Kamion: jdub is working on yelp issues with the yelp author
[07:27] <sivang> Kamion: if jdub already managed with that, it's cool, I have researched about it and find only half of the solution
[07:28] <Kamion> all right, that seems to be what jdub was talking about; he said he'd report this weekend or early next week
[07:28] <ogra> http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/005473.html
[07:28] <Kamion> Help topics organization
[07:28] <ogra> just for the record ^^^^
[07:29] <Kamion> is this just a subset of the previous item, or is there more?
[07:30] <ogra> nope, the previous
[07:30] <seb128> dunno 
[07:30] <Kamion> the new Ubuntu documentation is rather mixed in with stuff like the Fdutils FAQ at the moment
[07:30] <ogra> oh, i thought the mail link
[07:30] <Kamion> or the documentation of the GNU time command
[07:30] <HiddenWolf> is this 'the meeting'? 
[07:30] <sivang> Kamion: that was what I were talking about
[07:30] <ogra> HiddenWolf yup
[07:31] <sivang> Kamion: I thought that was what jdub going to fix
[07:31] <Kamion> all right, then, next item
[07:31] <Kamion> Screenshot updates to reflect artwork changes?
[07:32] <Kamion> as I understand it, the Hoary artwork is not yet final, but somebody does need to take responsibility for updating screenshots
[07:32] <Kamion> I don't see what we can do until the artwork's finalised, but it needs to be on a checklist somewhere
[07:32] <dholbach> sounds good
[07:33] <amu> Kamion: i started once a kind of QS Document .... 
[07:33] <Kamion> by default, probably one for jdub; suggestions for good screenshots would probably be a good idea
[07:33] <Kamion> amu: QS?
[07:33] <amu> err QA
[07:33] <ogra> Kamion QA
[07:34] <dholbach> Kamion: u-users@ will love to send in screenshots ;-)
[07:34] <Kamion> mdz's ISP has lost all of Southern California; there is no ETA for it returning
[07:34] <ogra> dholbach: but you will have to review them a lot (to make sure the right theme is used etc.)
[07:34] <amu> https://www.ubuntulinux.org/wiki/QAtesting
[07:34] <tseng> can we replace the gdm screenshot on the homepage? heh.
[07:35] <thom> davyd's document here: http://www.gnome.org/~davyd/gnome-2-10/ is a good example of introducing new features and how to use screenshots
[07:35] <Kamion> closer to the time, perhaps a -users survey would be appropriate
[07:35] <sivang> Kamion: sounds like it does
[07:35] <ogra> tseng: i think sabdfl wouldnt like that
[07:35] <Kamion> yes, the GNOME 2.10 notes were very good at that
[07:35] <ogra> yup
[07:35] <tseng> you know davyd uses ubuntu, he might be up for the job :)
[07:35] <Kamion> amu: ok, that seems very appropriate for later in the agenda
[07:36] <Kamion> tseng: good idea; can somebody talk to him?
[07:36] <thom> he just went to bed
[07:36] <thom> i'll ping him later
[07:36] <Kamion> there will be more than GNOME to cover
[07:36] <Kamion> Content review
[07:37] <Kamion> again, this is one that jdub said he would do
[07:37] <Kamion> but please can everyone responsible for Hoary features review the release notes and other documentation
[07:37] <seb128> k
[07:37] <seb128> wb mdz
[07:37] <Kamion> and send the documentation team updates for features they were responsible for
[07:38] <Kamion> mdz: hello again, we're up to Content review
[07:38] <jbailey> Is http://people.ubuntulinux.org/~mako/docteam/release-notes/release-notes.html the best source for the release notes?
[07:38] <enrico> jbailey: it is THE resource
[07:38] <Kamion> jbailey: I believe the documentation team have svn too
[07:38] <enrico> well, ok, svn
[07:38] <ogra> mdz wb
[07:38] <enrico> moment
[07:38] <mdz> yay, back
[07:38] <mdz> Kamion: can you paste me a log?
[07:38] <mdz> yes, svn seems like a better source
[07:39] <Kamion> enrico: all developers should be entirely capable of using that :-)
[07:39] <Kamion> mdz: what was the last thing you saw?
[07:39] <mdz> Kamion: --> silbs (~jane@host217-37-231-22.in-addr.btopenworld.com) has joined #ubuntu-meeting
[07:39] <mako> jbailey: it's updated about once a day
[07:39] <mdz> 1755 UTC
[07:39] <jbailey> mako: Cool, thanks.
[07:41] <Kamion> mdz: mail ok? there's a lot of it
[07:41] <enrico> ok, I'm in
[07:41] <mdz> Kamion: yes
[07:42] <enrico> The svn repo is https://docteam.ubuntu.com/repos/trunk
[07:42] <Kamion> mdz: sent
[07:42] <enrico> I assume it's time for the docteam related things
[07:42] <Kamion> enrico: thanks
[07:42] <mako> jbailey: that is autobuilt daily and then updated (semi-automatically) when i wake up
[07:42] <Kamion> enrico: we've been on documentation items for some time here
[07:43] <enrico> that's autobuilt when I see commits and I can run a script, actually
[07:43] <enrico> Kamion: you don't want to know where I was
[07:43] <sivang> enrico: we talked about the positioning of ubuntu docs in yelp
[07:43] <mako> enrico: sorry i missed some of it
[07:43] <enrico> I was phoning my gf at a phone booth because UK trains made her miss the plane
[07:44] <enrico> I could have used a ping
[07:44] <Kamion> enrico: if you have anything to say belatedly about the first three doc items on the agenda, please go ahead
[07:44] <sivang> enrico: jdub us supposed to report back about the yelp stuff, as Kamion noted.
[07:45] <enrico> Yelp fixes needed: it depends on what's needed to put the docs where we want them
[07:45] <enrico> Help topics organization: we all know where we want them, we have no idea how to get them there
[07:46] <Kamion> does jdub have a clear spec from your team of where you want them to go?
[07:46] <enrico> Screenshots updates: I'd put that together with content review
[07:46] <enrico> Kamion: the best place would be right in the toc and not in a subcategory
[07:46] <mdz> right
[07:46] <mdz> the ubuntu-specific docs should be out in front
[07:46] <enrico> froud: [topic: where to show the docs in yelp's TOC] 
[07:46] <mdz> jdub says he has worked with yelp upstream on a solution for this
[07:46] <sivang> enrico: where would that be? a catagory like "Ubuntu documentation" at toplevel doesn't make much sense, 
[07:46] <seb128> jdub is working on that
[07:46] <enrico> Kamion: however, we have no idea if that is possible at all
[07:46] <mdz> but I have no details or ETA
[07:47] <sivang> enrico: since it's an ubuntu system :-)
[07:47] <mdz> enrico: it is possible
[07:47] <enrico> mdz: oh, cool.  In that case, we'll wait for jdub to report what he found, right?
[07:47] <doko_> a mapping between doc-base and yelp would be nice, so you don't have to change every doc package.
[07:48] <doko_> ... to move the docs where you want it
[07:48] <mdz> enrico: no, please don't wait for him, but be proactive
[07:48] <enrico> so, ping him?
[07:48] <mdz> enrico: ask him until you get an answer
[07:48] <seb128> :)
[07:48] <enrico> I hate doing that
[07:48] <mdz> doko_: we already have that
[07:48] <seb128> should do that for the desktop files for g-a-i too 
[07:48] <Kamion> enrico: we don't have a lot of time to spare for waiting
[07:49] <enrico> Yes, but we're talking about jdub, not someone external
[07:49] <mdz> enrico: if you would prefer, you can work directly with yelp upstream
[07:49] <mdz> enrico: that is fine with me
[07:49] <enrico> Oh, well, I'll keep pinging him
[07:49] <Kamion> like many of us, jdub has many things to do, which means some may get forgotten :-)
[07:49] <enrico> mdz: it's fine I keep pinging jdub, thanks
[07:50] <enrico> So, that was the easy part.  
[07:50] <mdz> to jump back briefly
[07:50] <enrico> The screenshots, they are difficult to translate, and there's little we can do as a docteam
[07:50] <mdz> since I was talking to myself for a bit
[07:50] <thom> doko_: that's just a case of changing the scrollkeeper mappings in doc-base and rerunning install-docs
[07:50] <mdz> regarding the kernel stuff
 Kamion: this seems to be the same general problem as with language-support-*
 it would be nice to have some way to queue those packages for later installation, and inform the user
 Mithrandir, mvo: an update-notifier hook?
[07:51] <mdz> such a facility would allow us to queue packages, which are not on the CD, for later installation
[07:51] <enrico> The FAQGuide, it should be reviewed and decided if we want it in Hoary or not, since most of it refers to Warty
[07:51] <mdz> mvo: is it feasible to use the hook facility for this?
[07:51] <enrico> I've contacted Chua Wen-Kiat about it, I wrote him twice, but he didn't answer me
[07:51] <pitti> mdz: maybe for hoary it could be integrated into hte installer?
[07:51] <Kamion> update-notifier hooks are per-user, I thought
[07:51] <enrico> It's also true that Chua just came out of a bad case of *dengue fever*
[07:51] <mdz> Kamion: there are both per-user and per-system hooks
[07:52] <pitti> oh, cool
[07:52] <Kamion> pitti: the installer has to give up at some point; if the network is not available, it needs to queue l-s-*
[07:52] <dholbach> i'm not quite sure... i guess mvo just left for sports... i'll call him
[07:52] <Kamion> it cannot keep running forever
[07:52] <enrico> are we still talking about documentation?
[07:52] <pitti> Kamion: no, I mean just like you currently handle the l-support packages
[07:52] <Kamion> kernel stuff should be handled by base-installer, not by the second stage
[07:53] <pitti> Kamion: if the user has no network, he would be doomed, but at least this would be an improvement that is not too invasive
[07:53] <Kamion> if at all possible
[07:53] <mdz> mvo: are you here?
[07:53] <Kamion> mvo left
[07:53] <pitti> Kamion: but that would rule out u-mgr at all
[07:53] <Kamion> 18:34  * mvo needs to leave now, will read log
[07:53] <mdz> gah
[07:53] <ogra> enrico: this guide is awful and will need a hell of a lot of changes... i would suggest something new based on it for hoary.....(with help from the docteam and technical reviews)
[07:54] <mdz> ok, we'll follow up on that later then
[07:54] <enrico> ogra: what guide are you talking about?
[07:54] <mdz> pitti: the issue is that l-s-* are so big
[07:54] <ogra> enrico: ubuntuguied
[07:54] <ogra> guide even
[07:54] <mdz> too big for a reasonable download time during installation if the user does not have a fast connection
[07:54] <pitti> mdz: issue related to which?
[07:54] <pitti> mdz: ah, I see
[07:54] <pitti> right
[07:54] <enrico> ogra: ok.  It's actually not awful: it's one of the most quited and referenced pieces of documentation ever
[07:54] <mdz> enrico: what is the status of the User Guide for Hoary?
[07:54] <pitti> mdz: but modem-users generally don't install with network, or do they?
[07:54] <enrico> s/quited/quoted/
[07:54] <mdz> are we planning to use it at all?
[07:55] <pitti> mdz: at least all my modem-using friends did install networkless
[07:55] <dholbach> mdz: have him on the phone   he says update-notifier should be fine using synaptic --set-selections
[07:55] <enrico> mdz: user's guide is stalled.  The goal was the release notes, the about ubuntu and the quick Guide
[07:55] <enrico> The user's guide has been put aside, with doubts if we should work on the Gnome User's Guide instead
[07:55] <mdz> pitti: seems like a 30-minute download on ISDN
[07:55] <ogra> enrico: lets talk this over after the meeting, i have a lot objections telling users to edit config files without pointing out the danger
[07:55] <mdz> enrico: I was talking about the gnome user guide
[07:55] <mdz> I wasn't aware there was any other
[07:56] <pitti> mdz: we shouldn't optimize for modem/isdn, they cannot download all this stuff anyway (same for kernel)
[07:56] <enrico> mdz: John Hornbeck started a Ubuntu User's Guide
[07:56] <mdz> seb128: do you know if upstream has updated the guide at all?  the one in yelp says 2.6 still
[07:56] <dholbach> mdz: shall i ask him anything else?
[07:56] <enrico> wrt the Gnome User's Guide, we never sorted out how to interact with upstream and stuff, so we focused on teh QuickGuide, which was an easier target
[07:56] <seb128> mdz: hum, lemme check
[07:56] <mdz> dholbach: ask him to send me email with the details, feasibility for hoary
[07:56] <mdz> dholbach: thanks
[07:56] <enrico> now we have quite some infrastructure in place
[07:56] <mdz> enrico: I think we should probably remove the gnome user's guide if it cannot be brought up to date
[07:57] <enrico> THe best introduction to a Desktop OS I've seen so far
[07:57] <enrico> mdz: doesn't gnome 2.10 have a user's guide?
[07:57] <sivang> enrico: maybe we can replace it with some of our stuff? quick guide?
[07:57] <ogra> enrico: url ?
[07:57] <mdz> enrico: it is unfortunate that nobody can find it :-)
[07:57] <mdz> ogra: help->other documentation
[07:57] <seb128> mdz: shaunm has updated a bunch of user-guide documents on the CVS 2 days ago
[07:57] <mako> http://people.ubuntulinux.org/~mako/docteam/quickguide/
[07:57] <ogra> mdz: thanks
[07:57] <enrico> ogra: http://wiki.ubuntu.com/DocteamProjects
[07:58] <froud> mdz: here is what we have in plan http://www.ubuntulinux.org/wiki/DocteamProjects
[07:58] <dholbach> mdz: done, he thinks its feasible
[07:58] <froud> mdz: currently
[07:58] <enrico> Quick Guide is not a user's guide: it's a "I'll show you your new flat" kind of document
[07:58] <mdz> enrico: that's sor tof what the gnome user's guide is anyway
[07:58] <seb128> mdz: user guide is 2.8 in yelp here
[07:58] <enrico> For the User's Guide, I think the best bet is to take what happens from Gnome's side
[07:59] <mdz> but it is a bit more detailed, it explains how to use the system
[07:59] <seb128> mdz: and I remember updating for warty ... that's only the title beeing wrong and displaying 2.6
[07:59] <enrico> Maybe we can see if they need help, but people in the docteam are used to the workflow we have now, and it'd be quite disrupting to propose a new one now
[07:59] <mdz> seb128: oh
[07:59] <mdz> seb128: can you fix the title? :-)
[07:59] <seb128> "GNOME 2.8 Desktop User Guide"
[07:59] <seb128> on the page
[07:59] <enrico> Especially after the chaos of the last days, which just sorted out after lots of efforts
[07:59] <seb128> I'll update to 2.10 from the CVS
[07:59] <mdz> I didn't look at the content
[07:59] <mdz> seb128: ok, great, thanks
[07:59] <seb128> np
[08:00] <mdz> moving on
[08:00] <mdz> Keybuk is going to help us next week with dpkg bugs
[08:00] <mdz> especially #164595
[08:00] <enrico> mdz: Quick Guide says "this is the toilet", but doesn't tell you how to flush it
[08:00] <mdz> which is needed for the langpack update mechanism
[08:00] <sivang> how compatiable are we the gnome 2.10 manual? don't we have changed menu items and nautilus stuff?
[08:00] <mdz> is there any other dpkg work we need, while we have him?
[08:01] <mdz> enrico, sivang: if there is more docteam material to cover, let's schedule a separate meeting. we have been here 2 hours already and have much more to cover
[08:01] <enrico> mdz: we have a docteam meeting tomorrow, 23:00UTC
[08:01] <mdz> ok
[08:01] <sivang> mdz: right, sorry for creating noise
[08:02] <enrico> mdz: you're welcome to show up there
[08:02] <mdz> ok
[08:02] <mdz> any other dpkg items? no?
[08:02] <mdz> seeds
[08:02] <ogra> enrico: do you have any process in place for dev reviews ? 
[08:02] <mdz> pitti: this is the langpack selection stuff
[08:02] <pitti> yeah
[08:02] <mdz> we want to fit as many as we can on both install and live
[08:02] <pitti> I already said, but again:
[08:02] <mako> ogra: hwat do you mean by review?
[08:03] <mako> ogra: copy edit, proof, tech edit?
[08:03] <pitti> ppc allows us to accomodate some 42 MB until we reach 650
[08:03] <mdz> Kamion: do we have space for winfoss and the remaining 42MB of langpacks?
[08:03] <ogra> mako: to avoid technical mistakes like the ones done in the ubuntuguide.org
[08:03] <mdz> on i386/
[08:03] <mdz> ?
[08:03] <pitti> we currently have about 45 MB of langpacks which are not on the CD already
[08:03] <mako> ogra: tech editing
[08:03] <ogra> ah, thans mako
[08:03] <pitti> mdz: depends on how many kernels we ship in addition
[08:03] <enrico> ogra: you can review on the HTML preview and then post comments
[08:03] <pitti> mdz: on i386 we have an extra 75 mb
[08:04] <ogra> enrico: great, i'll add it to my todo :)
[08:04] <mdz> pitti: I only skimmed the log, but it sounded infeasible to ship more kernels
[08:04] <enrico> ogra: reviewing DocBook would be even better
[08:04] <mdz> pitti: before or after winfoss?
[08:04] <pitti> mdz: it shouldn't be infeasible to ship them, just to integrate their installation
[08:04] <ogra> enrico: k
[08:04] <enrico> ogra: the repo is open read-ponly to everyone and you can post pathces to the list
[08:04] <pitti> mdz: I looked at the size of the preview CDs
[08:04] <mdz> pitti: integrating their installation is done
[08:04] <mdz> pitti: the only problem is shipping them :-)
[08:04] <T-Bone> as fabbione pointed out, they're huge
[08:04] <mdz> base-installer has code to select the best kernel for the system
[08:04] <pitti> mdz: what should be the problem with putting -k7 in ship?
[08:05] <mdz> pitti: the fact that there are far more 686 systems than k7?
[08:05] <pitti> mdz: sure, we have to pick
[08:05] <pitti> mdz: but anyway
[08:05] <Kamion> mdz: no
[08:05] <mdz> we either ship one kernel which works everywhere (as we currently do)
[08:05] <pitti> ppc allows 40 mb, i386 allows 115 mb
[08:06] <mdz> or we ship all of the custom kernels
[08:06] <mdz> because the kernel team says that we cannot reduce it safely for hoary
[08:06] <T-Bone> the first choice seems better to me in the long run
[08:06] <pitti> ia64 allows 45 mb, amd64 allows 90 mb
[08:06] <T-Bone> number of flavours can do only one thing: increase
[08:06] <Kamion> mdz: with WinFOSS, i386 has about 20MB free
[08:07] <mdz> Kamion: eek
[08:07] <thom> Kamion: presumably that means amd64 is right on the limit with winfoss added?
[08:07] <Kamion> mdz: (live CD, obviously)
[08:07] <mdz> pitti: what can we do with 20M of langpacks?
[08:07] <pitti> 20 mb is enough for about 40% of the other langpacks
[08:07] <Kamion> thom: yes, about 1MB short
[08:07] <mdz> oh, live cd
[08:07] <Kamion> we do not have WinFOSS on the install CD at the moment
[08:07] <mdz> live CD compression is ~60% I think
[08:07] <Kamion> is it wanted there?
[08:07] <mdz> lamont: ^^?
[08:07] <lamont> yes
[08:07] <mdz> Kamion: no
[08:08] <Kamion> good
[08:08] <lamont> it's at about 35-40 %
[08:08] <mdz> pitti: so 45M of langpacks should -> ~15M of live CD space
[08:08] <lamont> WinFOSS is outside the cloop, of course.
[08:08] <pitti> mdz: if we optimize a bit, we _could_ squeeze all the stuff onto the ppc cd
[08:08] <crimsun> a lot of new users seem to complain that the installer doesn't select an "optimised" kernel by default, but it doesn't make sense to tie up that much space with custom kernels. It makes more sense to stick with the default base kernel that works everywhere.
[08:08] <pitti> mdz: erm, I'm already talking about .deb sizes#
[08:08] <Kamion> mdz: i386 install CD is at 533 MB
[08:09] <mdz> crimsun: it will choose the best kernel on the DVD; we don't even have room for one more kernel on the install CD
[08:09] <T-Bone> silly idea, but what about picking the correct kernel automagically in stage 2 if the user selected internet download?
[08:09] <mdz> nm, I confused instal and live CD sizes
[08:09] <Kamion> we have room for lots more kernels on the install CD
[08:09] <mdz> Kamion: ok, plenty of room
[08:09] <mdz> the i386 kernel flavours are ~16M apiece
[08:09] <pitti> Kamion: s/lots/2/ ?
[08:09] <mdz> we could put -686, -k7, -686-smp, -k7-smp
[08:09] <Kamion> pitti: easily
[08:09] <T-Bone> (that would delay booting the new kernel to the next reboot, of course)
[08:09] <Kamion> ] 
[08:09] <pitti> Kamion: I mean until we reach the ppc size
[08:09] <Kamion> I think we can live without -smp variants personally
[08:10] <pitti> Kamion: then we have an equal amount of space for langpacks
[08:10] <T-Bone> Kamion: ^^^
[08:10] <sivang> I second crimsun , with the addition that some tool should exist to do the touch finishing of the installation, as provide you with a clickable solution to install optimized drivers for you vid-card, install an optimized kernel etc.
[08:10] <mdz> Kamion: those would be the first to go, certainly
[08:10] <Kamion> T-Bone: prefer to avoid that if at all possible
[08:10] <mdz> Kamion: but for server installs they're awfully handy
[08:10] <T-Bone> k
[08:10] <pitti> mdz: OTOH servers will probably have a good net connection
[08:10] <Kamion> T-Bone: and there is *no* code for that right now; writing new kernel selection code is not the thing I want to be doing right at this moment
[08:10] <T-Bone> pitti: that too
[08:10] <Kamion> mdz: true
[08:10] <mdz> Kamion: I'm not sure I'm entirely comfortable with having base-installer select hte kernel this late in the release cycle, though
[08:11] <T-Bone> Kamion: ah ok, i thought the current code could be used in stage2. sorry
[08:11] <Kamion> erm; it already does select the kernel, on netboot installs
[08:11] <mdz> Kamion: I think I really really like the idea of having the same kernel boot in stage1 and stage2
[08:11] <mdz> but netboot is an extreme corner case for Ubuntu; we don't even document or advertise that it is possible
[08:11] <Kamion> hm, I'm ambivalent
[08:11] <Kamion> we do document it :)
[08:11] <doko_> they throw us out, we have to leave now. I'll read the log back in Berlin
[08:11] <mdz> now :-)
[08:12] <elmo> netboot good
[08:12] <sivang> doko_: c'ya
[08:12] <dholbach> bye doko 
[08:12] <elmo> no netboot bad
[08:12] <lamont> same kernel both stages good
[08:12] <mdz> Kamion: we do have bug reports where the -smp kernels fail, but the -386 kernel works
[08:12] <pitti> elmo spoken
[08:12] <thom> * elmo hit no netboot with big club
[08:12] <lamont> s/club/thagomizer/
[08:12] <mdz> let's pass on the kernels issue for Hoary; reliability is most important at this point
[08:12] <Kamion> mdz: I'm equally uncomfortable with having one kernel in stage2 and another kernel in the first reboot after stage2
[08:13] <Kamion> when that first reboot might be next week
[08:13] <Kamion> failing earlier is better than failing later :)
[08:13] <mdz> the other kernel flavours are only truly important on servers (where the admin will know what to do) and very high-end desktop
[08:13] <fabbione> Kamion: +100
[08:13] <T-Bone> true
[08:13] <thom> Kamion: that sounds worse by far, agreed
[08:13] <mdz> so let's not add kernels to ship
[08:13] <mdz> getting back to langpacks
[08:13] <fabbione> mdz: agreed
[08:13] <Kamion> all right, then
[08:13] <ogra> elmo: that was the documentation ?
[08:13] <fabbione> is there anything more to discuss about kernel?
[08:13] <elmo> can I request we bump anything to do with me up the agenda (i.e. archive I guess) - I have to catch a train at some point this evening, and they only run so late
[08:14] <mdz> we can definitely add all langpacks to ship for i386
[08:14] <pitti> mdz: I will sum up the langpack statistics to u-devel
[08:14] <fabbione> i wouldn't mind to go and have some dinner
[08:14] <mdz> Kamion: how much space left on ppc?
[08:14] <pitti> 42  MB
[08:14] <pitti> (install)
[08:14] <mdz> ok
[08:14] <Kamion> mdz: install or live?
[08:14] <mdz> pitti: go ahead and add the remaining langpacks to i386 ship
[08:14] <T-Bone> fabbione: order a pizza ;)
[08:14] <mdz> Kamion: install
[08:14] <mdz> (42M apparently)
[08:14] <Kamion> yes, what pitti said
[08:14] <pitti> mdz: and to amd64 as well, I suppose
[08:14] <sivang> T-Bone: my pizza is in the fridge downstairs :)
[08:14] <mdz> I  know these meetings are long, believe me my wrists are killing me
[08:15] <mdz> but we don't do this very often, and we have a lot to discuss
[08:15] <pitti> mdz: we probably have to pick a little for ppc
[08:15] <Kamion> ok, numbers:
[08:15] <mdz> so I need for you guys to stick around
[08:15] <Kamion> -rw-rw-r--    1 cjwatson cdimage  583636992 Mar 11 08:24 hoary-install-amd64.iso
[08:15] <Kamion> -rw-rw-r--    1 cjwatson cdimage  558759936 Mar 11 08:33 hoary-install-i386.iso
[08:15] <Kamion> -rw-rw-r--    1 cjwatson cdimage  634318848 Mar 11 08:58 hoary-install-ia64.iso
[08:15] <Kamion> -rw-rw-r--    1 cjwatson cdimage  636979200 Mar 11 09:12 hoary-install-powerpc.iso
[08:15] <Kamion> -rw-rw-r--    1 cjwatson cdimage  680626176 Mar 11 11:50 hoary-live-amd64.iso
[08:15] <Kamion> -rw-rw-r--    1 cjwatson cdimage  661864448 Mar 11 11:51 hoary-live-i386.iso
[08:15] <Kamion> -rw-rw-r--    1 cjwatson cdimage  599754752 Mar 11 11:52 hoary-live-ia64.iso
[08:15] <Kamion> -rw-rw-r--    1 cjwatson cdimage  615639040 Mar 11 11:53 hoary-live-powerpc.iso
[08:15] <Kamion> limit is 681574400
 -rw-rw-r--    1 cjwatson cdimage  680626176 Mar 11 11:50 hoary-live-amd64.iso
[08:15] <lamont> eep!
[08:15] <mdz> 650M hoary-live-amd64.iso
[08:15] <T-Bone> live amd64, gosh
[08:15] <Kamion> lamont: that's with WinFOSS
[08:15] <pitti> Kamion: oh, the http page says "608 MB" for ppc
[08:15] <mdz> what happened there?
[08:16] <lamont> Kamion: ah, ok
[08:16] <mdz> oh, winfoss
[08:16] <Kamion> which can be reduced
[08:16] <mdz> we can kill winfoss from amd64 if necessary
[08:16] <Kamion> pitti: yes, divide by 1024*1024, not 1000*1000 :)
[08:16] <mdz> Kamion: ls -sh :-)
[08:16] <pitti> do we have 650 * 1024^2 or 650 * 1000^2 bytes?
[08:17] <pitti> Kamion: I know, but I'm unsure about the size of a CD
[08:17] <mdz> unknown
[08:17] <lamont> 650*2^20
[08:17] <Kamion> pitti: 650*1024*1024
[08:17] <Kamion> I checked this morning against cdrecord source
[08:17] <Kamion> 333000 sectors, to be exact
[08:17] <lamont> but DVD's are 4.7*10^9
[08:17] <T-Bone> err
[08:17] <T-Bone> can we stop the maths?
[08:18] <pitti> okay, then we do have 42 MB for ppc
[08:18] <Kamion> so in fact 681984000 bytes
[08:18] <lamont> Kamion: warty live was already against the wire
[08:18] <mdz> so 650.4 * 1024^2
[08:18] <pitti> mdz: I do the maths more exactly and report back with the ppc status
[08:18] <jani> no 700Mb CDs?
[08:18] <pitti> mdz: I can find out whether stripping would be enough to fit everything
[08:18] <mdz> pitti: ok, but definitely add the langpacks for i386
[08:18] <mdz> pitti: for the next daily
[08:18] <pitti> mdz: sure (and amd64)
[08:18] <Kamion> jani: that's often asked, but we already get a lot of bug reports due to bad media
[08:18] <Kamion> jani: I am very uncomfortable with raising the bar even higher
[08:19] <jani> Kamion, oh ok didn't know
[08:19] <mdz> jani: remember, we also press proper 650M standard CDs
[08:19] <mdz> not only images for CD-Rs
[08:19] <mdz> moving right along
[08:19] <mdz> elmo: you're up
[08:19] <mdz> and lamont
[08:19] <lamont> woot
[08:19] <mdz> now seems like a good time to start the test rebuild
[08:20] <mdz> and fix the uninstallables
[08:20] <mdz> for supported architectures
[08:20] <mdz> lamont: you said you needed a test archive?
[08:20] <ogra> mdz:does this includeuniverse ?
[08:20] <lamont> yep
[08:20] <lamont> ogra: yes
[08:20] <ogra> ah, great
[08:20] <lamont> full rebuild will be all components
[08:20] <mdz> Kamion: in whata way?
[08:20] <mdz> er
[08:20] <mdz> ogra: in what way?
[08:20] <Kamion> briefly about langpacks> by the way, the slowness with installing lots of them should now be resolved; let me know if it isn't
[08:20] <mdz> the test rebuild?
[08:21] <ogra> mdz: in what way great ? 
[08:21] <mdz> lamont: you're the only one who would notice the time difference (installing langpacks on the live rootfs)
[08:21] <lamont> ogra: I won't generally be _fixing_ things in universe, but we will build them all;
[08:21] <jbailey> Nice.  Are the rebuilt packages what go into the archive, or ar they thrown away?
[08:21] <mdz> ogra: in what way universe?
[08:21] <mdz> jbailey: thrown away
[08:21] <elmo> jbailey: thrown the hell away
[08:21] <dholbach> mdz: i hope we can get a list of packages, not installable/buildable
[08:21] <ogra> mdz: in the way: we need a list of packages that need fixing
[08:21] <mdz> hence "test" rebuild :-)
[08:22] <jbailey> Mmm, too bad.  It's not a big deal for now, but when we bump glibc or gcc major revs we should make sure we do this.
[08:22] <lamont> build logs will go in a sibling to buildLogs on p.u.c
[08:22] <elmo> for the test archive stuff, I have a machine available, but the combination of hoary-test, vancouver and this week's install fest, has meant I haven't installed katie + w-b on it yet
[08:22] <mdz> ogra,dholbach: lamont should be able to give you a list of the failures without much additional work, if any
[08:22] <Kamion> mdz: (it also made a difference for people selecting languages where the langpack was not installed)
[08:22] <mdz> ogra,dholbach: regarding uninstallables, "apt-cache -i unmet"
[08:22] <elmo> jbailey: dude, no we shouldn't
[08:22] <dholbach> mdz: thanks
[08:22] <mdz> ogra,dholbach: Charles Majola is starting to work through them, coordinate with him
[08:22] <mdz> Kamion: oh, true
[08:22] <jbailey> elmo: Tracing unreproducable abi bugs really sucks.
[08:23] <mdz> elmo: ETA?
[08:23] <ogra> mdz: wow, didnt know about "unmet" thanks :)
[08:23] <elmo> mdz: early next week
[08:23] <lamont> jbailey: if you mean do a test rebuild, certainly.  If you mean rebuild the archive and lose all our mirror sites, certainly not.
[08:23] <elmo> jbailey: not having a mirror network and not supporting partial upgrades sucks more
[08:23] <dholbach> ogra: i put it on the wiki
[08:23] <ogra> dholbach: thks wiki master :)
[08:23] <dholbach> ogra: (after a sorting) :-)
[08:24] <jbailey> lamont: Doesn't have to be done in one shot, but over the course of a release every package should be touched at least once after a glibc or gcc bump for sanity.
[08:24] <thom> elmo/lamont: in fairness, this is exactly what fedora are doing currently in rebuilding the world on gcc 4.0, and they don't appear to have caused people to run away screaming
[08:24] <elmo> thom: I run away screaming from fedora all the time
[08:25] <T-Bone> that's a good thing :)
[08:25] <ogra> heh
[08:25] <thom> elmo: pffft, you know what i mean
[08:25] <elmo> thom: and last I checked fedora aren't 60Gb
[08:25] <elmo> sorry, but it's madness
[08:25] <elmo> if gcc/glib require that - they're broken
[08:25] <Kamion> SMS from mdz: "offline again"
[08:26] <ogra> grr
[08:26] <elmo> if fixing is hard, fine, but then we're giving up on supporting partial upgrades
[08:26] <sivang> Kamion: seems like he has a net connection as good as mines
[08:26] <jbailey> It's not required, there are just often subtle changes that require older things to use compatability code.
[08:26] <jbailey> And a rebuild just makes them go away, so as soon as you recompile to get a decent backtrace, no more bug.
[08:27] <lamont> jbailey: so there are bugs
[08:28] <elmo> jbailey: seriously how often does this happen?  maybe I'm being dense, but I can't recally many/examples of that with Debian stuff?
[08:28] <elmo> in any event, it's -ETOPIC, and we can discuss it out-of-band
[08:28] <Kamion> errno?
[08:28] <mdz> elmo: ok, thanks
[08:28] <mdz> elmo: germinate/archive sync is up to date now, right?
[08:28] <mdz> I added that agenda item before we talked about it last
[08:28] <jbailey> Yup.
[08:28] <elmo> mdz: yes
[08:29] <mdz> back
[08:29] <Kamion> mdz: recovered scrollback?
[08:29] <mdz> yes
[08:29] <mdz> ogra,dholbach: quick universe status update?
[08:29] <mdz> _quick_ :-)
[08:29] <pitti> mdz: just added the remaining langpacks to amd64 and i386
[08:30] <ogra> mdz: we plan to do kind of a "softfreeze" 
[08:30] <mdz> pitti: thanks
[08:30] <pitti> mdz: rest -> mail
[08:30] <Kamion> er, we skipped over uninstallables a bit
[08:30] <ogra> mdz: so wecall it a freeze, but everybody will know its not but should be cautions what he uploads
[08:30] <Kamion> I volunteered to try to get britney to output universe uninstallables separately; will try to look at that next week
[08:31] <dholbach> mdz: python transition is nearly complete, howl transition (not that much work) nearly done too
[08:31] <ogra> mdz: we still have a lot to reveiew
[08:31] <dholbach> yes
[08:31] <dholbach> that's what i was anxious to discuss
[08:31] <dholbach> lots of things are already fixed and need review to be uploaded
[08:32] <ogra> mdz: mostly done by dholbach since i was dragged away by my real world probs and hwdb-client, i will take up again next week
[08:32] <dholbach> but we seem to have no capacity
[08:32] <dholbach> so if some of you just picked a random package of the "to review" section of MOTUTodo we'd be really really happy
[08:33] <ogra> dholbach: we should focus on people already having a key up
[08:33] <mdz> dholbach: send an email to ubuntu-devel asking for volunteers
[08:33] <dholbach> i know that we're faster in reviewing than the debian new maintainer crew, but still
[08:33] <mdz> dholbach: most of the people here have a lot of tasks already
[08:33] <ogra> dholbach: lets sort them this way
[08:33] <dholbach> i wont thrash anyone into it
[08:34] <mdz> Kamion: can you exclude ia64 from hoary_probs.html?
[08:34] <elmo> no, but I can
[08:34] <ogra> we got a lot of motivated people out there, but nearly everyone has probs to get a signed key
[08:34] <mdz> pitti: some language-support-* are still uninstallable?
[08:34] <T-Bone> mdz: why?
[08:34] <mdz> Kamion: right, sorry, I keep forgetting :-)
[08:34] <T-Bone> mdz: i track that
[08:34] <mdz> T-Bone: so that we can see what needs to be done for the release
[08:34] <pitti> mdz: oh? I don't have bug reports any more
[08:34] <Kamion> mdz: I don't see the need, since most of that stuff is about to be fixed
[08:34] <dholbach> jani: please don't feel guilty :-)
[08:34] <pitti> mdz: is there an automatic page for this?
[08:34] <T-Bone> mdz: how having ia64 in that list prevents you to do so?
[08:34] <mdz> pitti: http://people.ubuntulinux.org/~cjwatson/testing/hoary_probs.html
[08:35] <mdz> T-Bone: by presenting me with a lot of information that I don't care about
[08:35] <T-Bone> a lot?
[08:35] <pitti> mdz: thanks, will sort this out
[08:35] <mdz> T-Bone: about 1/3 of that stuff is ia64
[08:35] <mdz> T-Bone: let's not argue about this. we can split ia64 into a separate file
[08:35] <mdz> elmo: right?
[08:36] <elmo> err, I can run britney twice, sure
[08:36] <lamont> elmo: what about spilling ia64 errors into another file?
[08:36] <elmo> she's cheap-ish
[08:36] <mdz> ok, solved
[08:36] <Kamion> let me know where to mirror stuff from
[08:36] <mdz> pitti: I think some of it might be thunderbird
[08:36] <mdz> pitti: at this point, if the packages cannot be easily fixed (e.g., sync from Debian), we probably need to remoev the deps
[08:36] <mdz> T-Bone: not for the Hoary release we don't
[08:37] <pitti> mdz: yeah, will do
[08:37] <mdz> we've been over that
[08:37] <T-Bone> that'll teach me trying to fix blockers
[08:37] <Kamion> T-Bone: it's not a release target; please don't have a go at mdz for only caring about release targets, he has a hell of a lot to consider
[08:37] <pitti> mdz: some of it might be OO.o
[08:37] <T-Bone> ok
[08:37] <Kamion> T-Bone: the universe guys are also working on stuff that is not release targets
[08:38] <Kamion> T-Bone: that doesn't mean it's unimportant, just that it should be possible to consider release targets separately from anything else
[08:38] <T-Bone> Kamion: my understanding was that ia64 would be reconsidered if the two big blockers were solved
[08:38] <crimsun> elmo: (thanks for looking after my GPG key)
[08:38] <pitti> mdz: mozilla locales, too
[08:38] <mdz> right.  ia64 and universe will do the best they can for release, but they will not block us
[08:38] <Kamion> we won't be putting universe into hoary_probs.html either
[08:38] <mdz> pitti: same answer there
[08:38] <elmo> crimsun: (np, sorry for delay)
[08:38] <pitti> sure
[08:38] <mdz> moving on
[08:38] <mdz> warty upgrades -> language pack/support install
[08:38] <mdz> that's a documentation issue as far as I'm concerned
[08:38] <mdz> we don't have much else
[08:39] <Kamion> T-Bone: I don't know the status of that; for the moment, it seems entirely fair to split ia64 out of hoary_probs.html, until such time as the status changes
[08:39] <mdz> pitti: can you add that to HoaryUpgradeNotes?
[08:39] <pitti> mdz: I think this could be solved with upgrading hooks
[08:39] <elmo> anything else for me in the agenda?  sorry to be trying to skip out, but it's a long journey back to leeds
[08:39] <pitti> mdz: yes, I can
[08:39] <pitti> mdz: however, maybe we can hook it into the upgrade manager
[08:39] <mdz> elmo: only remaining item would be any further server testing
[08:39] <pitti> mdz: I ask mvo about this
[08:39] <mdz> pitti: ok, please do
[08:39] <elmo> mdz: *cry* you want me to do that AGAIN?
[08:40] <mdz> elmo: not on the same scale
[08:40] <mdz> elmo: let's talk about it later, go
[08:40] <dholbach> pitti: shall i ping mvo about something specific - i make notes for him already
[08:40] <elmo> ok, thanks.  sorry.  etc. 
[08:40] <mdz> next item: security policy review
[08:40] <mdz> pitti: we need to ensure that we haven't regressed from warty
[08:40] <pitti> dholbach: I'll ask him on monday, I already noted this
[08:40] <mdz> pitti: e.g., new setuid programs or ports
[08:40] <dholbach> pitti: alright
[08:41] <pitti> mdz: I will do another warty install, upgrade and compare setuid and process lists
[08:41] <mdz> pitti has a lot to do right now; can someone else do that review?
[08:41] <mdz> lamont: ?
[08:41] <pitti> that'd be fine, too :-)
[08:41] <mdz> lamont: while you're waiting for the infrastructure for the test rebuild, can you do a Warty vs. Hoary setuid diff?
[08:41] <pitti> lamont: this would involve to note all setuid binaries that were added, and all processes which now run as root in addition
[08:41] <lamont> mdz: wouldn't be hard to do, no
[08:41] <mdz> and ntan
[08:41] <mdz> that
[08:41] <mdz> lamont: great, thanks
[08:42] <pitti> mdz: I also need to do a full security review for Hoary packages
[08:42] <mdz> language-support-* mvo said he would investigate
[08:42] <mdz> pitti: what kind of review?
[08:42] <pitti> mdz: my Ubuntu CVE status page already helps a lot, but it does not contain all CANs
[08:42] <mdz> oh, of known vulnerabilities
[08:42] <pitti> mdz: some CANs might have slipped though the cracks
[08:42] <pitti> mdz: like, on syncinc packages or so
[08:42] <mdz> pitti: can you recruit someone to help?  maybe gerardo?
[08:42] <mdz> pitti: we could bounty it
[08:42] <pitti> mdz: gerardo, sivang, lamont?
[08:43] <sivang> mdz: I'm in :)
[08:43] <mdz> ok
[08:43] <pitti> mdz: hmm, I'd rather control this myself, if you don't mind :-)
[08:43] <pitti> mdz: similar to the warty release
[08:43] <pitti> mdz: this worked pretty fine
[08:43] <sivang> pitti: that was for you also :)
[08:43] <mdz> pitti: ok, I'm concerned about you being overloaded though
[08:43] <pitti> mdz: I'll coordinate, not do everything myself :-)
[08:43] <mdz> pitti: so please get some assistance for the research; this is easy to parallelize
[08:43] <ogra> pitti: something else you can drop `
[08:43] <ogra> ?
[08:44] <mdz> Kamion: installer test plan
[08:44] <pitti> ogra: yes, bug fixing :-)
[08:44] <mdz> Kamion: can you put together an outline by, say, RC-7days?
[08:44] <Kamion> on my list; amu posted a link earlier which could be extended
[08:44] <Kamion> although that seems to be more the installed system actually
[08:44] <Kamion> mdz: yes, I'll adapt from the Debian installer test plan
[08:44] <mdz> yes, that's for the live CD
[08:44] <mdz> ok, thanks
[08:44] <Kamion> oh, good point
[08:45] <mdz> the live CD test plan covers much of the desktop, last I looked at it
[08:45] <Kamion> one sec I'll find the link
[08:45] <mdz> amu: do you have that URL?
[08:45] <mdz> it's not in my log
[08:45] <thom> Kamion: if you need help on that one yell
[08:45] <Kamion> https://www.ubuntulinux.org/wiki/QAtesting
[08:46] <mdz> thom: can you work on the server test plan?
[08:46] <thom> sure
[08:46] <mdz> thom: basic functional testing of the common server stuff, apache, php, mysql, whatnot
[08:46] <Kamion> http://svn.debian.org/wsvn/d-i/trunk/installer/doc/devel/release-checklist?op=file&rev=0&sc=0
[08:46] <Kamion> ^- d-i test plan
[08:46] <mdz> all of this should be written up at the level that anyone with reasonable Ubuntu command-line skills can follow it
[08:46] <mdz> so that we can ask all volunteer testers to follow the plan
[08:46] <thom> right
[08:47] <mdz> Kamion: do you want to do server-mode installs as part of the installer test plan, or the server test plan?
[08:48] <Kamion> mdz: both, I think
[08:48] <Kamion> different focus
[08:48] <mdz> Kamion: ok, send thom the relevant info
[08:48] <mdz> that's the end of the agenda
[08:48] <mdz> I have one more item
[08:48] <mdz> BUGS
[08:48] <mdz> I recently made a pass over all >=major bugs
[08:49] <mdz> but there are probably bugs out there with the wrong severity
[08:49] <mdz> each of you, please review your open bugs
[08:49] <mdz> and ensure that anything which should be on my radar for Hoary is set to >=major
[08:49] <pitti> mdz: do you consider warty->hoary upgrading issues as major? (I do)
[08:49] <mdz> please do that by the end of next week
[08:49] <mdz> pitti: yes
[08:50] <pitti> mdz: e. g. fixing console-tools is a bit nontrivial
[08:50] <HiddenWolf> just wondering: there are a lot of bugs posted on the mailing list, are these filed in bugzilla?
[08:50] <pitti> HiddenWolf: not automatically
[08:50] <mdz> send me a note when you've finished your review, so that I know when I can consider the release-relevant bug list to be fairly complete
[08:50] <mdz> HiddenWolf: if you see someone reporting a bug to the mailing list, and you are sure it is a real bug, ask them to file it in bugzilla
[08:51] <mdz> we ask people to report issues to the mailing lists when they are not sure
[08:51] <mdz> any other business?
[08:51] <ogra> HiddenWolf: ....and if you are sure that its not a universe bug 
[08:51] <HiddenWolf> mdz: are all those gamin issues in bugzilla already?
[08:51] <mdz> ogra: :-)
[08:51] <mdz> HiddenWolf: which ones?
[08:51] <tseng> HiddenWolf: there are several different reports
[08:51] <tseng> HiddenWolf: they need to be sorted out in the next week
[08:52] <sivang> ogra:  what happens to unvierse bug ATM? they are awaiting malone?
[08:52] <mdz> HiddenWolf: pitti is going to work on triaging them, can you help him?
[08:52] <ogra> mdz: today and yesterday a thread started on -devel
[08:52] <ogra> (gamin)
[08:52] <tseng> sivang: right now they seem to go to -users.. yes @ waiting for malone
[08:52] <sivang> tseng: ok
[08:52] <ogra> sivang: see tseng
[08:52] <tseng> the gamin thread on devel is pretty useless
[08:52] <ogra> yup
[08:52] <HiddenWolf> mdz: if he needs the help...
[08:52] <pitti> HiddenWolf: most of gamin issues are already assignede to me and filed, yes
[08:52] <tseng> "gamin is teh b0rk"
[08:53] <dholbach> thanks mdz, thanks kamion
[08:53] <pitti> tseng: fam is b0rked, too
[08:53] <tseng> sure is.
[08:53] <mdz> any other business before we close?
[08:53] <Kamion> I added DVD testing to the agenda
[08:53] <pitti> EBANDWIDTH
[08:54] <mdz> oh, I haven't reloaded
[08:54] <mdz> who here has DVD writers?
[08:54] <Kamion> I've ordered a DVD burner and DVD+RWs, but I would like people with bandwidth and DVD burners to have a go, too
[08:54] <jbailey> I do
[08:54] <mdz> (I have one)
[08:54] <dholbach> me
[08:54] <tseng> I have a dvdr
[08:54] <ogra> mdz: me
[08:54] <seb128> do we have DVD isos for the preview ?
[08:54] <sivang> mdz: have bandwidth, no burner :-/
[08:54] <thom> i was planning to acquire such a beast, i can move it up the schedule
[08:54] <Kamion> because the DVDs are almost entirely untested, and, as shown by Linux Magazine, people are going to want to ship them
[08:54] <mdz> seb128: no
[08:54] <Kamion> seb128: we have weekly-dvd builds on cdimage.u.c
[08:54] <mdz> seb128: because we didn't have time/people to test htem :-)
[08:54] <seb128> k
[08:55] <pitti> sivang: burner, no bandwith -> let's move together
[08:55] <seb128> I'll have a try on the current one
[08:55] <seb128> I've a medium bandwith but my server can download during the night :)
[08:55] <mdz> Kamion: looks like we have a reasonable list of people who can test, once we have a plan
[08:55] <jbailey> I may want to look into want my maximum transfer is for the month and get a better package, though. =)
[08:55] <ogra> pitti: going to .il ?
[08:55] <pitti> erm...
[08:56] <sivang> pitti:  :-)
[08:56] <ogra> pitti: the other way around would be no benefit *g*
[08:56] <Kamion> I am aware of an archive-copier bug that causes DVD installations to copy a LOT of data to the hard disk at the moment
[08:56] <Kamion> I'm in the process of fixing that
[08:56] <mdz> Kamion: at what time of the week does the DVD build take place?
[08:57] <Kamion> 17 12 * * 6     /srv/cdimage.no-name-yet.com/bin/cron.weekly-dvd
[08:57] <mdz> pitti: you should be able to jigdo the CD data onto the DVD, at least
[08:57] <Kamion> per colin.watson@canonical.com--2004/cdimage--mainline--0 etc/crontab
[08:57] <pitti> dholbach: could you snailmail me a DVD?
[08:57] <thom> Kamion: all of the packages on the dvd, perchance?
[08:57] <Kamion> thom: everything in Ubuntu supported
[08:57] <dholbach> pitti: query me your adress
[08:57] <thom> ouch indeed
[08:57] <Kamion> thom: plus the live cloop
[08:57] <mdz> dholbach,tseng,ogra,pitti,thom: it would be aa good idea to download the current weekly DVD, so that you can rsync up to the next one
[08:57] <Kamion> it's a combo
[08:58] <mdz> our weekly churn should be fairly reasonable at this point
[08:58] <Kamion> I'll probably make it go more often than weekly
[08:58] <Kamion> maybe Saturdays and Wednesdays, or something
[08:58] <mdz> even better
[08:58] <jbailey> Are DVDs usefully rsync'able?
[08:58] <pitti> mdz: I get one snailmailed and update from it
[08:58] <mdz> what I do for CDs is to set up a nightly rsync job, so that I'm always up to date and don't have to wait for downloads
[08:58] <thom> yeah, i'm gonna kick that off now
[08:58] <mdz> if you don't have transfer limits, I recommend doing the same
[08:58] <ogra> jbailey: isnt it a iso ?
[08:58] <mdz> jbailey: they're as rsyncable as the install+live CDs
[08:58] <jbailey> Cool.
[08:59] <mdz> jbailey: though when they're generated weekly, less so
[08:59] <mdz> Kamion: I think twice weekly is reasonable
[08:59] <Kamion> alright, will do
[08:59] <mdz> ok, is there any other business before we break?
[08:59] <mdz> we're at the 3-hour mark ;-)
[09:00] <mdz> ok, hearing none, meeting adjourned
[09:00] <mdz> thanks, everyone
[09:00] <ogra> i will need some server for hwdb-client, but we can do that in PM
[09:00] <mdz> anything else, mail ubuntu-devel@
[09:00] <ogra> and later
[09:00] <sivang> ogra: PM ?
[09:00] <ogra> sivang: personal message
[09:01] <tseng> thanks mdz 
[09:02] <pitti> thanks mdz, long but great meeting
[09:03] <lamont> pitti++
[09:03] <jbailey> \o/
[09:04] <Kamion> lamont: imagine arms lifted up in a "yay" gesture
[09:04] <thom> i'm not sure if it's "I surrender" or "throws hands up in glee"
[09:05] <zul> its like what the comic bookshop guy said "there is no emoticon for the rage im feeling"
[09:05] <jbailey> lamont: Cheering pitti's statement.
[09:06] <lamont> ah, ok
[09:07] <mgalvin> hi all i just got back and saw that dvd's need testing, the last one is from the 8th, since that one will prolly not work for me, does anyone when the nest one will be rolled
[09:08] <Kamion> mgalvin: why won't that work?
[09:08] <Kamion> mgalvin: but it'll be tomorrow sometime
[09:09] <mgalvin> Kamoin: my machine was affected by the sata bug from the other day that the release was delated for
[09:09] <Kamion> hm, the last weekly-dvd build was kicked off manually by me
[09:09] <Kamion> mgalvin: ah, ok
[09:10] <dholbach> Kamion: so new dvd-isos tomorrow?
[09:11] <Kamion> dholbach: yeah
[09:11] <ogra> dholbach: start the DL immediately, then do a rsync
[09:11] <Kamion> starts at 12:17 UTC
[09:11] <dholbach> alright
[09:11] <Kamion> will take several hours I imagine
[09:11] <mgalvin> I will download the new dvd image when its ready and give it a go, i have an unlimited connection here and get up to 700/kbs :)
[09:12] <thom> Kamion: you need to fix up the HEADER.html for the dvds...
[09:13] <Kamion> thom: hm, yeah, that'll be interesting
[09:14] <Kamion> noted