13:00 < bubulle> OK, folks, time for the d-i meeting
13:00 < kyllikki> do we have to? ;-)
13:00 < robster> hehe
13:00 -!- svenl is now known as luther
13:00 < bubulle> Topics to be discussed first are at  http://wiki.debian.net/index.cgi?DebianInstallerMeetings
13:01 < bubulle> Let's start with "Release plans :"
13:01 < bubulle> joeyh?
13:01 < joeyh> yo
13:01 < joshk> hullo
13:01 < kmuto> morning
13:02 < jbailey> Woot, d-i meeting. =)
13:02 < bubulle> joeyh: you mentioned " use sarge or old release methods"?
13:02 < pere> evening. :)
13:02 < joshk> hm, i didn't know about that agenda
13:02 < joeyh> right, so I'm rather unsure whether what we have in sarge right now is releasable, or whether the old methods are better
13:03 < bubulle> at least for the line drawing pb I consider this unreleasable
13:03 < cjwatson> the amount of development effort we have concentrated on sarge right now is pretty low relative to sid
13:03 < kyllikki> joeyh: define releasable?
13:03 -!- amck is now known as mckinstry
13:03 < joshk> hey, is someone logging this? i will, if no one is
13:03 < bubulle> I do
13:03 < joshk> k
13:03 < luther> joeyh: i hear that what we have in sarge doesn't support 2.6.
13:03 < bubulle> but log also....
13:03 < cjwatson> luther: powerpc only
13:03 < luther> 2.6 kernels:
13:03 < joeyh> kyllikki: works on all supported arches (except s390) with no problems at the level we'd need errat aofr them
13:03 < kyllikki> joeyh: sorry I mean define what we need to be releasebale and see what fits?
13:04 < luther> Well, 2.6 kernels on powerpc.
13:04 < fjp> I find current scheme confusing as it's unclear which variant should be tested when.
13:04 < luther> Às
13:04 < joshk> joeyh: what are the 'old methods'?
13:04 < joeyh> joshk: what was done for the betas, just finding a snapshot that was reasonably good and calling it a release
13:05  * Md wonders if anybody has ever used ppp-udeb
13:05 < joshk> aha
13:05 < luther> As it is possible that we want to go by 2.6 by default on powerpc for sarge, this is a bit problematic.
13:05 -!- ema [~ema@adsl-81-87.38-151.net24.it] has joined #debian-boot
13:05 < seppy> hi!
13:05 < robster> Md: could that be tested over a null modem link?
13:05 < jbailey> HP folks have mentioned a couple times that they might prefer 2.6 by default on ia64 and hppa.
13:05 < joshk> btw, i have a few status update for sparc64 woes
13:05 -!- dannemare [~konversat@0x5358aaae.abnxx12.adsl-dhcp.tele.dk] has joined #debian-boot
13:05 < Md> robster: it could be tested with just an ethernet card, it's for PPPoE, not for dialup
13:06 < robster> Md: ah, sorry. ;)
13:06 < joshk> 1. busybox in sarge currently has functional biarch support so those problems are all but over
13:06 < cjwatson> jbailey: HP folks had better get moving ... :-) Speaking from experience, it takes a while to do a d-i port to 2.6, and you want both running concurrently for a while
13:06 < Md> robster: "we" concluded that trying to support dialup installing of the first stage is pointless
13:06 -!- piotr [~pedro@DWB-6-112.go.retevision.es] has quit ["leaving"]
13:06 < joeyh> I guess another way to look at the question is whether the d-i in sarge is close to what we'd like to be the final release, and if not, why are we bothering with it
13:06 < joshk> 2. silo support: the problem has been nailed down. it's ugly, related to positioning of memory simms
13:06 < robster> Md: yeh, sounds sensible.
13:06 < bubulle> folks, can you please avoid having two discussions in the same time?
13:06 < joshk> hmm
13:06 < joshk> there's more like 3 going on
13:06 -!- mode/#debian-boot [+o joshk] by ChanServ
13:06 -!- mode/#debian-boot [+o bubulle] by joshk
13:06 -!- mode/#debian-boot [-o joshk] by joshk
13:07 < joshk> joeyh: i frankly think what we upload to sid is always an improvement
13:07 < joshk> especially at thsi point in development
13:08 < cjwatson> joeyh: speaking for myself I think powerpc is well away from what I'd like to see; although conceivably we could fix that with a well-placed busybox-cvs upload backporting just the relevant fix
13:08 -!- jaldhar [~jaldhar@samadhi.braincells.com] has joined #debian-boot
13:08 < tbm> jbailey: 2.6 on ia64 should definitely be added; maybe you want to give it a go.
13:08 < pere> is part of the problem with the udebs in sarge the lack of dependencies?
13:08 < joshk> cjwatson: what is wrong with it?
13:08 < joeyh> joshk: I certianly belive you're right, but at some point you have to stop making improvements and concentrate on making it accessible to the world at large
13:08 -!- RichiH [richih@richih.cloaked] has joined #debian-boot
13:08 < joeyh> cjwatson: you mainly mean 2.6 stuff then?
13:08 < joshk> joeyh: improvements at this point, such as to netcfg, were LARGELY bugfixes and critical missing features
13:08 < joshk> so...
13:09 < joshk> yeah, i realize there's a time to stop, but i think we're already doing that
13:09 < cjwatson> joshk: breaks with cramfs initrds, #244589; it was fixed in busybox-cvs eons ago but the fix got stuck behind netcfg
13:09 < fjp> I guess the main problem is there's still to much development going on. If we want a RC, maybe old method would be best but with freeze: only work on specific, identified issues and put all the rest (new development) in a branch.
13:09 <@bubulle> joshk; but are they tested enough? That's part of joeyh's point.? We suffered in the past from not enough tested stuff
13:09 < cjwatson> joeyh: yeah, but I think that's turning out to be fairly important for us as kernel upstream start disowning 2.4
13:09 < joshk> bubulle: i've tested this release until i turned blue
13:09 -!- piotr [~pedro@DWB-6-112.go.retevision.es] has joined #debian-boot
13:10 < joeyh> cjwatson: what does #244589 currently affect?
13:10 < joshk> the only (aesthetic, imho) problem si that netcfg-dhcp (which no one uses at all) contains a 'Configure network manually' option when DHCP fails
13:10 < joshk> so it's harmless: any 'fix' would be a kludge requiring a new debconf template
13:10 < cjwatson> joeyh: powerpc 2.6 is unbootable; has been since rc1
13:10 < gaudenz> hi, evening.
13:11 < cjwatson> I don't really want to harp on about individual problems, we can discuss that offline
13:11 < joshk> well, unbootable targets are certainly a problem
13:11 <@bubulle> Up to now, there does not seem to be general agreement about sarge_d-i being releasable. Am I wrong?
13:11 < cjwatson> but the point is that if the process means we can't even make certain targets bootable when the fix has been in unstable for over two months, there's a problem in the process.
13:11 < pere> would it help to teach the testing update scripts about udebs, and start documenting the versioned dependencies in the udeb packages?  At the moment the dependencies are mostly ignored as anna don't care.
13:11 < joeyh> joshk: something I feel is that no matter how much testin we do, we really can't know if something is release quality until it's been beat on by the world in a beta release
13:12 < cjwatson> pere: I don't think that's going to be achieveable for sarge
13:12 < joshk> joeyh: that's very true
13:12 < joshk> so until we freeze some stuff
13:12 < joshk> we should keep snapshotting
13:12 -!- fatal_ [~gem@mirkk.celab.se] has quit [Read error: 104 (Connection reset by peer)]
13:12 < joeyh> pere: I feel it's very difficult to get that right
13:13 < luther> win 10
13:13 < joeyh> I can forward you some mail I sent to aj about it before, too much detail for this meeting, probably
13:13 < pere> would it help to just add dependencies to the udebs?
13:13 < pere> then we could do consistency checks offline.
13:13 < joeyh> ATM we find it very hard to not miss dependencies
13:14 < cjwatson> it's not clear to me that that's the usual problem
13:14  * joshk grumbles about netcfg
13:14 < cjwatson> anyway, the situations with unstable in general and d-i are very, very different, and I'm not convinced the testing process is appropriate for the latter
13:14 < cjwatson> unstable gets widely tested very quickly, and if a package is at all interesting then release-critical bugs tend to be found quickly
13:15 -!- eugen [~eugen@news.univ.kiev.ua] has left #debian-boot []
13:15 <@bubulle> I tend to agree on cjwatson comment
13:15 <@bubulle> recent situation on sarge_d-i has proven it....OK-->broken-->OK....
13:15 < cjwatson> while the only people who really test d-i on a daily basis are the limited set of d-i developers, and we just can't spot everything. What you actually want is confirmation of workingness, not absence of brokenness.
13:15 <@bubulle> -->broken currentl(on my i386 default install point of view)
13:15 < cjwatson> And that's really too hard to get into the testing scripts, which is why we've had this manual process recently.
13:15 < joshk> I was tossing around an idea in my head about implementing fully automatic installs
13:16 <@bubulle> a minimum should be default installs working flalessly
13:16 < JHM> Speaking of which, does the change in bash's dependencies in sid (it now depends on passwd for its postinst) cause problems for d-i?
13:16 < joshk> so that we can create a core selection of feature tests to run through
13:16 < waldi> JHM: yes
13:16 < cjwatson> JHM: as I said on #debian-release, I don't see how it could.
13:16 < pere> joshk: I believe it is doable using qemu/bochs and expect.
13:16 < cjwatson> waldi: why?
13:16 < cjwatson> waldi: debootstrap already installs passwd
13:16 < joshk> pere: i'd rather make a real solution
13:17 < joshk> then it has practical application anyway
13:17 < cjwatson> waldi: dpkg --configure will sort out the ordering given the dependency
13:17 -!- ProGuy [~proguy@0x53585ac4.arcnxx16.adsl-dhcp.tele.dk] has quit ["Client exiting"]
13:17 < joshk> pere: it requires changes to cdebconf
13:18 < joshk> for sure..
13:18 < joeyh> one thing I wanted to ask -- and it might be too early since the vote just ended, but what is the release team looking at WRT release timelines now?
13:18 <@bubulle> Can we make a very short break and ask joeyh (who has bring up the release topic) what are his conclusions at this point? joeyh?
13:18  * cjwatson will answer joeyh, but defers to bubulle's question first
13:18 < pere> joshk: I'm talking about regression testing, not automatic installations as such.
13:19 < joeyh> well, I'm seeing a general feeling that current sarge is not in a releasable state
13:19 < kmuto> WRT?
13:19 < joeyh> probably means going back to the old method for at least one beta release
13:19 <@bubulle> for those maybe less used to all this, can you resume what is the old method?
13:20 < joeyh> sure, just a matter of taking a snapshot of the udebs in unstalbe one day, doing some testing, and calling that a release
13:20 < RichiH> bubulle: :)
13:21 <@bubulle> this means calling for a freeze, more or less, then?
13:21 < maks> what went wrong last beta, that made the change to new method?
13:21 < gaudenz> Do we have a list of RC issues in sarge_d-i? Just to know if it's really the right thing to throw this away.
13:21 < joeyh> so far this has always turned out to mean releases with serious problems that we didn't catch
13:21 < fjp> What we need is controlled fixing of issues in that release.
13:21 < joshk> joeyh: i think we should declare a feature freeze
13:21 < joeyh> gaudenz: we haven't had enough testing to know IMHO. One is that pcmcia-cs doesn't work
13:21 < joshk> aha
13:21 < joeyh> (it may work in sid again as of today, unsure)
13:21 < cjwatson> <cynical> unfortunately the new method seems to involve releases with serious problems that we can't fix. :(
13:22 < cjwatson> (due to excessive difficulty of backporting in d-i)
13:22 -!- markos_ [~markos@212.54.223.254] has joined #debian-boot
13:22 < gaudenz> If we go back to the old method we have to freez sid for d-i
13:22 < cjwatson> I think once the skew between sarge_d-i and sid_d-i gets too great it becomes unmanageable.
13:22 < ths> gaudenz: At least the parts d-i needs.
13:22 < joeyh> cjwatson: I agree, and I think we're there or close
13:22 < fjp> I agree with cjwatson
13:22 < joshk> yeah
13:23 <@bubulle> I currently see a kind of agreement
13:23 < gaudenz> ths: That's what I meant to say. Sorry.
13:23 < joshk> i think we should cut beta5/tc2/rc1/whatever RSN
13:23 <@bubulle> 1) abandon sarge_d-i as is
13:23 < joeyh> doing a beta and just fixing the key issues is something we haven't tried
13:23 <@bubulle> 2) freeze sid
13:23 < cjwatson> IIRC, in the previous betas, we had daily pointing to sid_d-i, not sarge_d-i
13:23 < joeyh> bubulle: 1.5: fix sid
13:23 <@bubulle> 3) works on bugs identified as RC
13:23 < joshk> bugfixes and translation updates should directly enter sarge
13:23 <@bubulle> joeyh: right
13:23 < joshk> we should audit those
13:23 < cjwatson> now that we have daily pointing to sarge_d-i I suspect we might get better testing pre-beta
13:23 < joshk> eventually it'll become easier and easier
13:24 < joeyh> cjwatson: actually, daily was pointed to sarge_d-i before past betas, just in the last week or so of preparation
13:24 < cjwatson> ok, I stand corrected
13:24 <@bubulle> 1) "abandon" sarge_d-i 2) fix sid 3) feature freeze sid
13:24 < fjp> Translations should keep current with beta and fixes to beta
13:25 < cjwatson> can we post to -devel-announce pre-beta, perhaps?
13:25 < joeyh> if we go with sid for a release, we will need another string freeze, and all that
13:25 < cjwatson> much as tc1 was supposed to be for rc1
13:25 <@bubulle> I don't think translations are a big problems now. Templates are not likely to change that much
13:25 < ths> Are there any features we don't have yet but want in the release?
13:25 < joeyh> netcfg has changed a lot, for instance
13:25 < joshk> ths: fully automatic install
13:25 < cjwatson> ths: what, in sid you mean?
13:26 < ths> Generally in d-i.
13:26 <@bubulle> joeyh: yeah but netcfg is uptodate now. 22 languages at 100% for whole d-i
13:26 < cjwatson> ths: I meant sid_d-i, but ok
13:26 < joshk> you configure the network, and then it goes off and does its thing
13:26 < cjwatson> is "installable without hacks on s390" a feature? :-)
13:26 < joeyh> cjwatson: I do think my earlier question has bearing on this planning, got a sec to answer?
13:26 < cjwatson> sure
13:26 < joeyh> or aj_ if he's here
13:26 < joshk> more precisely: you'd configure the network yourself, and then debconf priority is raised to some fictitious level above critical
13:26  * joeyh looks for vorlon
13:26 < fjp> IMHO FAI should be post RC1; there is no framework for it yet; likely to be unstable and break things
13:27 < pere> serial line installation on i386 is a missing feature, I believe.
13:27 < joshk> fjp: right
13:27 < cjwatson> I'm hoping aj is, in which case I'll step back, but I might as well go ahead with what I can make out for now
13:27 < joshk> i think we can branch it 
13:27 < cjwatson> the last release plan was http://lists.debian.org/debian-devel-announce/2004/03/msg00026.html, and I think the general structure outlined there for the end of sarge is still good
13:27 -!- kraai_ [~kraai@host-66-81-192-30.rev.o1.com] has joined #debian-boot
13:28 < cjwatson> As I understand it, sid is now in a situation where the installer works well on all release candidate architectures except arguably s390
13:28 < cjwatson> and s390 has had an installation report that really doesn't sound all that bad
13:28 < ths> The "real" FAI isn't going to use d-i any time soon, AFAIK. fjp, joshk, I guess you were talking about the "automate" idea we had on the list.
13:28  * joeyh is sure we'll have more people unable to install i386 than s390 right now :-P
13:28 < cjwatson> (I'm discounting things like "partman is slow" here)
13:28 -!- Oskuro [~jordi@62.174.220.75] has joined #debian-boot
13:28 < fjp> ths:yes
13:29  * pere is working on debian-cd, making it possible to build woody CDs with d-i.  It might give us more testers.
13:29 < waldi> joeyh: nope, there exists a pretty emulator for s390
13:29 <@bubulle> OK....let's have a short break to sammarize and continue on schedule.
13:29 < cjwatson> so, I think we're not far off what the previous plan called beta5: the major issue is debugging the hell out of it
13:29 < joshk> why don't we cut it first, and not announce it?
13:30 < maks> you wont get bug reports ;)
13:30 < joshk> branch it for fixes while we continue more audacious bugfixes or critical feature implementations
13:30 < cjwatson> *If* that can be agreed to be the case, then we just need to sort out a few more issues in the rest of sarge (cupsys transition springs to mind), and then I feel we can go into a test cycle or equivalent
13:30 < joshk> maks: but it'll give us more breathing room to discover bugs
13:30 < cjwatson> There'd then be room for one more round of low-risk tweaking before release.
13:30 < luther> joshk: i like that idea. release beta5, don't announce it, fix it internaly and then announce.
13:30 < cjwatson> </flood>
13:31 <@bubulle> 1st topic of the meeting seems over : we tend to a freeze of sid. If someone strongly disagrees, it's time to speak..:-)
13:31 < cjwatson> (sound sensible?)
13:31 < joeyh> joshk: I think we've seen what happens if we have branched development. The devel branch gets lots of sexy new features and we decide we'd prefer to release it
13:31 < joeyh> cjwatson: any numbers?
13:31 < gaudenz> I think we need to stop creating sexy new features and concentreate on releasing d-i
13:31 < fjp> Solution is to agree to focus on beta.
13:31 < ths> joeyh: That's why we need first an agreement of what features are important for RC.
13:31 < pere> joeyh: d-i was less complete when we tried that the last time.
13:31 < tbm> joeyh: well, that's because we never actually used the rc1 branch
13:32  * bubulle nos at gaudenz
13:32 < cjwatson> the security team needs time to catch up on testing
13:32 <@bubulle> s/nos/nods
13:32 < kmuto> cjwatson: gotom and I are planning and making draft base-freeze, http://kmuto.jp/open.cgi?base-freeze&l=en
13:32 < joshk> joeyh: i think we've made most of the packages sexy enough
13:32 < cjwatson> without having remotely consulted the rest of the release team, I'd say that if "beta5" is well-debugged and doesn't pull enormous numbers of people out of the roadwork saying "it's horribly broken", we could be looking at four weeks or so
13:32 < gaudenz> To do that we probably need to agree on what features we need to implement before sarge release and what's post-sarge.
13:33 < cjwatson> kmuto: let me talk to you separately about that
13:33 < joshk> the only thing that could possibly be sexier that springs to mind:
13:33 < kmuto> cjwatson: sure, we'll send later to debian-release ML
13:33 < cjwatson> If we're doing things this way, then everyone else in the project needs to be hammering on RC bugs NOW
13:33 < joshk> * better kernel installation heuristic (cjwatson?)
13:33 -!- piotr [~pedro@DWB-6-112.go.retevision.es] has quit ["leaving"]
13:33 < joshk> * FAI, of course
13:34 <@bubulle> we probably have bugs which may be considered RC and aren't tagged as such now
13:34 < ths> joshk: Please don't call it FAI.
13:34 < cjwatson> mind you, http://bugs.debian.org/release-critical/ says 317, which scares the hell out of me.
13:34 < gaudenz> joshk: IMHO "FAI" is post-sarge, there is the real FAI for this in sarge
13:34 < joeyh> we have 490 unanalysed installation reports
13:35 < joshk> ths: give me a better acronym
13:35 -!- piotr [~pedro@DWB-6-112.go.retevision.es] has joined #debian-boot
13:35 -!- mherbert [~mherbert@194.2.198.253] has quit [Remote closed the connection]
13:35 < joshk> gaudenz: it's a colosssal pain in the ass to use
13:36 < fjp> joeyh: any idea how many are still relevant?
13:36 < pere> joshk: kickstart. :)
13:36 < mckinstry> At least one RC bug #257667 may break the build ...
13:36 < joeyh> fjp: the oldest ones now are beta2
13:36 < mckinstry> I'm working on a fix to #257667 but it will require all packages depending on sarge (inc. newt, d-i) to be rebuilt.
13:37  * bubulle thinks that beta2 and beta3 install reports are more or less useless now
13:37 -!- eugen [~eugen@news.univ.kiev.ua] has joined #debian-boot
13:38 < joshk> pere: ($*^*#@$!!
13:38 < joshk> gaudenz: yes, let's agree on some features we need and stuff we really need to fix
13:38 <@bubulle> So we should focus on analysing install reports again? Just for finding wht may be considered RC?
13:38 < joshk> gaudenz: until now i was unaware that powerpc 2.6 installs were busted
13:39 < gaudenz> If we want to release with sensible 2.6 suport we need discover2
13:39 < tbm> so what's broken with discover2?
13:39 < gaudenz> cjwatson or luther: What's the status of 2.6 on powerpc
13:39 < joeyh> last I checked, its data was reduced to nothing, and it didn't work
13:39 < ths> tbm: What _will_ it break, rather.
13:40 < cjwatson> gaudenz: working in sid
13:40 < joeyh> that was a while ago, and I worked with jeff liquia at debconf to get them the info they need to properly reduce the data
13:40 < gaudenz> tbm: It's untested with d-i for about 2-3 months. joeyh removed it for 2.6.
13:40 < joshk> yeah
13:40 < cjwatson> gaudenz: unbootable in sarge; an updated busybox-cvs would probably be sufficient but I don't know this for sure
13:40 < joshk> discover1-data is really getting old, too
13:40 < luther> gaudenz: will probably be fine for pegasos and newworld pmac, once the new base-installer i uploaded todaywill be in sid, and thus know how to install kernels.
13:40 < luther> I suppose yaboot using chrp is ok too.
13:41 < gaudenz> cjwatson: Is it included in sid_d-i builds?
13:41 < cjwatson> luther: it's been fine for a while on newworld pmac; it's true there was a bug
13:41 < cjwatson> gaudenz: has been for months
13:41 < luther> Need a new round of testing on prep and a smallish mkvmlinux fix for it.
13:41 < cjwatson> luther: but in practice it was ok nevertheless
13:41 < cjwatson> gaudenz: although I understand some of the problems with discover1, in practice it doesn't seem *that* bad on 2.6
13:41 < luther> oldworld though has not been tested, and need some decisions jens is not ready to take.
13:41 <@bubulle> Can we summarize about ports, one by one?
13:42 < cjwatson> gaudenz: think of it as better than woody's hardware detection. :-)
13:42 < luther> That is reintroduce the powerpc-small kernel, and test it.
13:42 < ths> bubulle: WRT discover2?
13:42 < luther> We don't currently support other powerpc subarches.
13:42 < gaudenz> cjwatson: The policy for discover1-data is to include 2.4 modules where they confilict with 2.6 module names. discover1 does not support kernel versions.
13:43 <@bubulle> ths: no, generally, but you fols may prefer finishing discussing discover2
13:43 < cjwatson> gaudenz: I agree that it's not perfect, but it's far from useless
13:43 <@bubulle> s/fols/folks
13:43 < gaudenz> cjwatson: agreed ;-) :-(
13:43 < cjwatson> I would not mind releasing with discover1, given the lack of recent testing of discover2
13:44 < joeyh> fwiw, my feeling on discover is that without a discover2, 2.6 cannot be the default kernel on at least i386
13:44 -!- Oskuro [~jordi@62.174.220.75] has quit ["gone"]
13:44 < joeyh> of course that's not really in the cards anyway, and I don't know about other arches
13:44 < fjp> cjwatson: that would mean sticking with 2.4
13:44 -!- mode/#debian-boot [+o waldi] by ChanServ
13:44 < gaudenz> joeyh: I agree, if we make 2.6 default we need discover2
13:44 -!- mode/#debian-boot [+m] by waldi
13:44 -!- mode/#debian-boot [-m] by waldi
13:44 < joshk> uh
13:44 <@waldi> bubulle: ?
13:44 < joshk> what was that all about?
13:45 < cjwatson> fjp: we were always going to have both as options, I think; if one doesn't work people can try the other ...
13:45 <@waldi> joshk: bubulle asked for stopping the discussion
13:45 < joshk> oh ok
13:45 -!- piotr [~pedro@DWB-6-112.go.retevision.es] has quit ["leaving"]
13:45 <@bubulle> well....don't see me as dictator, please..:-)
13:45 < fjp> cjwatson: yes, but 2.4 as default; for me 2.6 installs work fine on my i386 laptop
13:45 <@bubulle> Anyway, keeping this pon track is maybe needed
13:45 <@bubulle> So, please, ports status
13:46 <@waldi> lets begin with s390
13:46 <@bubulle> wait a min
13:46 -!- piotr [~pedro@FW-30-241.go.retevision.es] has joined #debian-boot
13:46 <@bubulle> I think it's worth giving : 1) 2.4 status 2) 2.6 status 3) reasonably releasable or not 4) RC stuff
13:46 <@bubulle> So, s390
13:47 <@waldi> - stage 1 have working ssh support
13:47 < tbm> what's the status of ssh?
13:47 <@waldi> only stage 1
13:47 < joshk> yes, i'd like to know if it works for other arches easily too
13:47 <@waldi> but we need stage 2 also
13:47 < cjwatson> waldi: what about libcrypto?
13:47 -!- kraai [~kraai@host-66-81-202-103.rev.o1.com] has quit [Connection timed out]
13:47 <@waldi> cjwatson: not fixed, i will do an nmu
13:48 < cjwatson> ok
13:48 -!- Jonzl [~bla@dfn237118.extern.uni-tuebingen.de] has quit ["und tschüss..."]
13:48 -!- kraai_ is now known as kraai
13:48 <@bubulle> something more for s390?
13:49 <@waldi> not yet
13:49 <@bubulle> OK, so currently target is getting ssh working for stage2
13:49 <@waldi> yes
13:49 < ths> What is missing for release of s390?
13:49 <@bubulle> if achieved...releasable or not?
13:50 <@waldi> ths: some fixes in zipl-installer, uploads of the other s390 specific packages
13:50 <@waldi> bubulle: after ssh is working, releasable
13:50 <@bubulle> OK, powerpc folks, it your turn
13:51 <@bubulle> uh?
13:51 < cjwatson> sex
13:51 < cjwatson> er!
13:51 < cjwatson> sec
13:51 < joeyh> lol
13:51 < dsilvers> cjwatson -- Mr one-track-mind :-P
13:52 < cjwatson> in unstable, 2.4 and 2.6 both work fine on newworld pmac
13:52 < luther> Ok, like said, i think it is reasonable to move for a 2.6 powerpc kernel for sarge, for all currently supported architectures, the support for those is better, and upstream (that is the linuxppc folk) as well as our own kernel powerpc specialist are favoring 2.6 development and bug fix over 2.4.
13:52 < cjwatson> 2.4 oldworld pmac is unbootable, but then again it always has been
13:52 < luther> 2.6 and probably 2.4 work fine on chrp_pegasos.
13:52 < luther> beyond that, we can only conjecture.
13:52 < ths> luther: probably?
13:53 < luther> I will probably get a old world next week so we can actively fix it.
13:53 -!- TonyStark [~chatzilla@nord-8-82-224-154-135.fbx.proxad.net] has quit ["ChatZilla 0.9.52B [Mozilla rv:1.6/20040113]"]
13:53 < luther> hs: Long time i have not tested it.
13:53 < cjwatson> oldworld has a bootloader installer so if you boot it using BootX that should theoretically be OK, but there's been zero testing
13:53 < fjp> Where are the problems? Kernel or d-i?
13:54 < luther> and this is no solution for for debian, since BootX depends on non-free macos 9, which not everyone has.
13:54 < cjwatson> I don't know of any RC issues, apart possibly from Sven's keymap thing
13:54 < cjwatson> luther: it's a solution. it's not a good solution, but it's a solution
13:54 -!- JHM [ray@cl-168.ams-01.nl.sixxs.net] has left #debian-boot ["."]
13:54 <@bubulle> so, is it correct you guys give your preference for default 2.6 on PPC? And no huge RC thing?
13:54 < joshk> huh?
13:54 < joshk> i thought it wouldn't boot
13:55 < cjwatson> I prefer 2.6 in theory, but I'm worried about the relative amounts of testing it's had given that it didn't work in tc1
13:55 < cjwatson> joshk: in *tc1*, not in sid_d-i
13:55 < cjwatson> joshk: sid_d-i has booted for months
13:55 < luther> Also, i suppose we should drop apus from the support, Simon may not like it, but there maybe be something like 3 or so users left, and none of them helped.
13:55 < cjwatson> I agree.
13:55 -!- amck [~alastair@195.218.109.43] has joined #debian-boot
13:55 < ths> 2.4 kernels are .25, should AFAICS be synced up.
13:55 < gaudenz> discover2 probably has an endianness issue
13:55 -!- amck is now known as mckinstr1
13:55 <@bubulle> something more for PPC?
13:55 < luther> We need to get prep support in mkvmlinuz, will do that tomorrow.
13:56 < cjwatson> I think we can move on
13:56 <@bubulle> alpha? We may miss vorlon....
13:56 < luther> ths: i have been working on 2.4.26 all week, together with hch. The disregard of benh for the 2.4 branch makes this a rather difficult thing though.
13:56 -!- frda [~konversat@0x5358aaae.abnxx12.adsl-dhcp.tele.dk] has joined #debian-boot
13:56 <@bubulle> other alpha people around?
13:56 < maks> yup
13:56 < maks> i'll try to catch up
13:56 < ths> luther: This was just for completeness WRT RC issues.
13:57 < maks> sarge d-i has some problems with separate boot
13:57 < maks> partitions
13:57 < jbailey> bubulle: I'm diong the alpha nightlies, but haven't tested an install recently.
13:57 < maks> vorlon fixed them in current sid
13:57 < cjwatson> maks: probably best to focus on sid_d-i status given the earlier discussion?
13:57 <@bubulle> As vorlon is currently less available we may need more people testing?
13:57 < maks> last known problem not in the manual is that aboot needs some space
13:57 < maks> in front of your drive
13:58 < maks> latest install report also missed that
13:58 < cjwatson> [oh, er, yes, can we add the state of the manual to the agenda?]
13:58 < maks> but beside that sid_d-i has better reports than sarge_d-i
13:58 < joeyh> maks: how much of your report #253032 is still relevant?
13:59 -!- eddyp [~eddy@82.77.146.54] has joined #debian-boot
13:59 < joeyh> oh, none I see
13:59 < maks> yeaah you're right
13:59 < maks> vorlon did a very good job in sid_d-i for alpha
13:59 < luther> ths: yep.
13:59 <@bubulle> OK, so the conclusions seems to be "alpha in good shape"
14:00 <@bubulle> next?
14:00 < maks> yeeah i may help next days with further testings.
14:00 < kyllikki> arm?
14:00 <@bubulle> yep
14:00 <@bubulle> arm people around?
14:00 < kyllikki> were gonna be releasing with 2.4 as support for several of our platforms is missing in 2.6 till upstream sorts it
14:01 < dsilvers> bubulle: the arm person is, yes (kyllikki)
14:01 <@bubulle> yeah, I figured out just after...:-)
14:01 < joeyh> does arm have working CDs now?
14:02 < kyllikki> but on all the current sub arches with kernels we have had adequate install reports, except riscpc which is supposed to be worked on by others
14:02 < dsilvers> cjwatson was working on them earlier
14:02 < CIA-2> joeyh * r17573 installer/doc/testers.txt: add maximilian attems to alpha testers
14:02 -!- eugen [~eugen@news.univ.kiev.ua] has left #debian-boot []
14:02 < kyllikki> I doenloaded the cds built earlier and certianly netwinder seems to net install
14:02 < cjwatson> joeyh: they've built fine; AIUI arm bootloading is a matter of "specify location of kernel in CD" so they should now be fine
14:02 <@bubulle> OK? then "arm in good shape for sid_d-i" is right?
14:03 < kyllikki> pretty much, as long as the 2.4 kernels are ok
14:03 <@bubulle> Next: hppa
14:03 < joshk> that requiers bdale or jbailey to be around
14:03 < cjwatson> kyllikki: the only arches with 2.6 yet are i386, powerpc, and amd64 if that counts, so I wouldn't stress about 2.6 too much
14:03 < tbm> kyllikki: are you working on .26 kernels?
14:03 < jbailey> joshk: I'm not dead yet!
14:03 < jbailey> =)
14:03 < luther> cjwatson: what about ia64 ?
14:04 < cjwatson> luther: not in d-i
14:04 < luther> cjwatson: because nobody is working on it, or for more fundamental reasons ?
14:04 <@bubulle> jbailey: so, hppa? Any indication?
14:04 < kyllikki> tbm: not atm
14:05 < cjwatson> luther: no idea, but I suspect the former
14:05 < tbm> the former, yes
14:05 <@bubulle> well, then let's move to ia64 status...
14:06 < jbailey> bubulle: I have an hppa box now (Acquired a week ago) and I haven't done further testing yet.  The hppa folks have told me that 2.6 doesnt' suck for fork+exec, which might solve the partman issues.
14:06 -!- mckinstry [~alastair@194.46.86.94] has quit [No route to host]
14:06 <@bubulle> So, saying that status for hppa is unknown is close to truth?
14:06 < cjwatson> jbailey: if you want help with moving to 2.6, shout
14:06 < jbailey> Aside from that there's been success reports for install.
14:06 < joshk> it might be good to keep ia64 in our scopes for sarge
14:06 -!- piotr [~pedro@FW-30-241.go.retevision.es] has quit ["leaving"]
14:06 < joeyh> and failure reports (hangs) that remain undiagnosed afaik
14:07 -!- piotr [~pedro@FW-30-241.go.retevision.es] has joined #debian-boot
14:07 < jbailey> cjwatson: I will ping you early next week, I'm away this weekend.
14:07 -!- timday [~timday@bottlenose.demon.co.uk] has joined #debian-boot
14:07 <@bubulle> OK, back to ia64......someone around with an idea of the status?
14:07 -!- dannemare [~konversat@0x5358aaae.abnxx12.adsl-dhcp.tele.dk] has quit [Connection timed out]
14:08 -!- frda [~konversat@0x5358aaae.abnxx12.adsl-dhcp.tele.dk] has quit [Remote closed the connection]
14:08 <@bubulle> <deep silence>
14:08 < ths> The EFI partition bug suggests it never booted.
14:08 < dannf> bubulle: looking for ia64/di status?  (sorry just joined, missing backlog)
14:08 <@bubulle> dannf: yep
14:09 < dannf> bubulle: jim lieb has been working on it - w/ his last elilo-installer fix, he said he was it installable
14:09 <@bubulle> sid_d-i images?
14:09 < ths> s/booted/rebooted correctly/ that is.
14:09 < dannf> he's been working on partman to fix up the autopartition stuf
14:09 -!- dannemare [~konversat@0x5358aaae.abnxx12.adsl-dhcp.tele.dk] has joined #debian-boot
14:10 < dannf> bubulle: someone here told me it worked fine on their ia64 box, excluding the autopart stuff
14:10 <@bubulle> OK....we won't have much more I guess...So, les choses qui fachent : m68k.....
14:10 < dannf> bubulle: it won't work on sgi boxes, unless we do a 2.6 flavor
14:10 < dannf> here == here at hp
14:10 < joshk> hmm.. m68k needs.. who?
14:10 < joshk> smarenka
14:10 < cjwatson> smarenka?
14:11 < joshk> looks like that won't work
14:11 < pere> bubulle: did we already cover sparc?
14:11 < joshk> nope
14:11 <@bubulle> pere: no, alpha order, sorry..:-)
14:11 <@bubulle> or near-alpha
14:11 -!- [JEB] [~jeb@jeb-debian.demon.co.uk] has joined #debian-boot
14:11 < joshk> bubulle: alpha was not first though ;)
14:11 < cjwatson> we've missed out i386 :-)
14:11 < dannf> bubulle: we have a contracter working on it, so please let me know of any ia64-specific issues
14:11 < kmuto> lol
14:11 <@bubulle> bubulle order then
14:11 < joeyh> afaik there's still a chance that some m68k image builds will have broken filesystems on them, and we still don't know why
14:12 < joshk> genext2fs broken again?
14:12 < tbm> dannf: can he do 2.6 for d-i?
14:12 < joeyh> and this has had no progress since it was reported a month ago, AFAIK
14:12 <@bubulle> My feeling is that very few people care or work on m68k. Am I damn wrong?
14:13 < tbm> bubulle: smarenka does a great job
14:13 < pere> bubulle: who knows.  The few are very eager and vocal, at least.
14:13 <@bubulle> ok, guys, my feeling was bad, then..:-)
14:13 < dannf> tbm: it depends; his main objective is getting the current stuff working well
14:13 < pere> bubulle: but only 0.07% of the popcon submitters use it. :)
14:13 < joshk>  well i know we have Yoe and smarenka
14:13 < joshk> but that's about it
14:13 < joshk> ..right?
14:14 < dannf> once that's done, i'm sure we can look at it
14:14 < kyllikki> what precisely is the genex2fs issue?
14:14 < joshk> it sucks
14:14 < dannf> tbm: i plan to do a linux-kernel-di-ia64 in preparation
14:14 <@bubulle> So, status for m68k is having them do a status report? :-)
14:14 < joshk> dannf: neato
14:14 < joeyh> sojnds like a good start bubulle
14:14 < kyllikki> joshk: I have fixed lots of issues with it
14:14 <@bubulle> Looks like we won't have more....for m68k
14:14 < joeyh> kyllikki: something about half the images in the tc1 build not being usable
14:14 < kyllikki> joshk: I *was* thinking of being helpful ;-)
14:15 < dannf> (i mean a l-k-di-ia64-2.6)
14:15 < joeyh> kyllikki: I can dig up the mail after the meeting
14:15 < doogie> actually, I don't know if I should use d-i on lully.  dsa would want stable on it
14:15 < kyllikki> joeyh: please
14:15 <@bubulle> Let's continue with port status in bubulle order : mips/mipsel
14:15 < maks> doogie: lully is alpha?
14:16 < joshk> it's the alpha buildd
14:16 <@bubulle> (I keep i386 for the end, just to stay awaken..:-))
14:16 < ths> mips/mipsel is 2.4 kernel only so far.
14:16 <@waldi> i'm away now
14:16 < doogie> make: what he said
14:16 -!- mode/#debian-boot [-o waldi] by waldi
14:16 < doogie> s/make/maks/
14:16 < maks> doogie: if you have time do a test install on a spared partition
14:16  * cjwatson has to go, sorry
14:17 < joeyh> are the 36 mb memory issues not a problem with current sid_d-i?
14:17 <@bubulle> I haven't seen much progress on this
14:17 < doogie> maks: don't really have a spare to work with
14:17 <@bubulle> ths: has time for testing this?
14:17 < ths> joeyh: They shrank the last time i tried.
14:18 < pere> is the memory problem unique for mips, or can it be reproduced on other archs?
14:18 < joeyh> are the mipsel cdroms working now?
14:18 -!- zboob [zboob@d80-170-4-213.cust.tele2.fr] has joined #debian-boot
14:18 < ths> bubulle: No, an elusive toolchain bug ate all my time.
14:18 <@bubulle> so, basically the status is still "low memory situtations need investigation"?
14:18 < ths> joeyh: Yes, this was a quoting error in delo.conf.
14:19 <@bubulle> OK...Let's move ahead again: sparc
14:19 < ths> Either investigation or generally a lowmem limit above 32 MB.
14:20 < joshk> sparc..
14:20 < joshk> ok, so: busybox in sarge is A-Ok
14:21 < dannemare> For the first time I have been able to succesfully install on my Ultra-5 (using http://gluck.debian.org/cdimage/testing/sid_d-i/sparc/20040705/). This closes Bug#254808.
14:21 < joshk> also, SMP kernels seem to have lots of problems
14:21 < joshk> on sparc32
14:21 < joshk> so i might disable these in base-installer
14:21 < timday> I just tried to use a raid device for '/' but on exiting partitioner get a dialog saying 'Debian does not currently support using software raid for the root filesystem...'.  Are there any plans for that to change ?
14:21 < joshk> next.. the initrd + SILO issues
14:22 < joshk> it turns out it is a problem with _physical_ memory alignment
14:22 < joshk> one tester repositioned some SIMMs, and it worked
14:22 < joshk> so, BenC needs to fix that, who knows when. i'm not good enough at sparc internals to fix it myself
14:22 < joeyh> sounds like it should go in the install manual
14:22 < joshk> ok.. i'll TODO that
14:22 <@bubulle> so would saying "sparc is on its way to be releasable" be right?
14:22 < joeyh> floppy builds still need root, right?
14:23 < joshk> yes
14:23 < joshk> jbailey wanted to help me with that but never did :|
14:23 < joshk> understandably so
14:23 < joshk> it's an uggggly situation
14:23 <@bubulle> anything else with sparc?
14:23 < pere> why does it need root?  loopback mounting, or something else?
14:23 < joshk> pere: yes, loopback
14:23 < joshk> bubulle: one more thing
14:24 < joshk> because i have been wrestling with size issues for sparc kernels.. i'm considering transitioning kernel-image-sparc-2.4 to use initrd
14:24 < joshk> but, that is most certainly for sarge + 1
14:24 < joshk> unless anyone thinks otherwise
14:24 <@bubulle> so, out of topic, currently..:-)
14:25 < luther> joshk: what's the 2.6 kernel status on sparc ?
14:25 < joshk> i was soliciting opinions. it is currently installable
14:25 < joshk> luther: BenC keeps saying he is working on packages, but produces absolutely nothing
14:25 < joshk> so I will be collaborating with wli to come up with packages
14:25 < luther> joshk: Ok, welome to the debian-kernel team, there is an irc channel and a mailing list, as well as a subversion repo.
14:26 <@bubulle> OK....unless my tired mind forgets something we're left with i386..:-)
14:26 < joshk> amd64...
14:26 -!- kalahann [~laurent@kinux.net1.nerim.net] has joined #debian-boot
14:26 <@bubulle> I remembered that one also, yep
14:26 <@bubulle> let's say after i386
14:27 < joshk> joeyh: i386?
14:27 <@bubulle> default installs generally run w/o problems
14:27 < joeyh> er, I guess most of us can summarse this one, but yeah..
14:27 < fjp> i386 looks very good in general, but gets most newbies and therefore higher expectations
14:27 < joeyh> I did find some nasty pcmcia problems recently, hopefully fixed now
14:28 < joshk> fjp: hm parse error
14:28 < joshk> ah
14:28 < joshk> i see
14:28 < joeyh> the base-config charset problems seem to keep popping up
14:28 <@bubulle> not in sid_d-i afaik
14:28 < joeyh> we have some upcoming changes to testing that will probably break things
14:28 < joeyh> the 2.6.7 kernel
14:28 < joeyh> new tasksel
14:28 < joshk> btw:someone try dpkg-reconfigure locales
14:29 < joeyh> joshk: bug exists, and is filed against whiptail
14:29 < joshk> ok
14:29 <@bubulle> joeyh: I'm confident the base-config charset problems are solved if we use sid_d-i....and the new lang/countrychoosers
14:30 < gaudenz> bubulle: Is the no-framebuffer problem solved? I had it yesterday
14:30 < joeyh> it'll be fixed in today's image, iirc
14:30 <@bubulle> it is solved, yes. kmuto did the patch
14:30 < joshk> nice
14:31 < Q_> Is that no framebuffer on 2.6?
14:31 < joeyh> I'm unsure of the lowmem status
14:31 < joshk> also, new ethdetect is a lot friendlier on all arches
14:31 < fjp> bubulle: what about the @euro issue?
14:31 < joshk> i invite individual port maintainers to add entries to devnames.txt
14:31 < joshk> i've certainly missed some modules
14:31 <@bubulle> joeyh: I haven't tested it since 20040620
14:31 < joeyh> zboob: what is the status of your anna patches for lowmem?
14:31 <@bubulle> fjp: nothing made
14:33 <@bubulle> ok, so can we conclude that i386 is in quite good shape but needs some care day to day?
14:33 < kmuto> hmm
14:33 < zboob> i have not change my patch until a long time, but i think i will test it again, but i can not go down ~23 MB because of dependencies
14:33 < fjp> Is Anton still working on partman. There's a bug about partman not distinguishing between identical partitions on selerate disks.
14:33 <@bubulle> 1) check 2.6.7 integration
14:33 < kmuto> maybe "no" about 2.6
14:33 < kmuto> maybe I find a problem now
14:33 < joeyh> zboob: is it applyable to current anna now?
14:34 < ths> joeyh, zboob: I tested it a while on mips, works fine.
14:34 < joshk> yeah, partman is scarily idle right now
14:34 < kmuto> bubulle: modprobe -q vesafb || modprobe -q vga16fb won't work with 2.6.7 (or modprobe problem?)
14:34 < joshk> it is so very slow on sparc32 as well
14:34 <@bubulle> joshk: that was one of the topic I wanted to bring up yes
14:34 < joeyh> bubulle: I'll try to ping anton
14:34 <@bubulle> partman does not seem to receive great attention ATM
14:35 < joeyh> he does tend to batch his changes, but it has been 2 months since the last major batch, so
14:35 < zboob> do not know, i will test with the last anna. but i think we have to activate it when we have less than 32MB (on i386)
14:35 < fjp> Partman is generally quite stable though.
14:35 <@bubulle> imho, so bug sorting on partman-* is deeply needed
14:35 <@bubulle> there are lots of wishlist things
14:35 < luther> About partman, i would welcome parted comaintainers with access to the different ports that need special care.
14:35 <@bubulle> and general usability reports
14:36 <@bubulle> imho we need some push like the one joshk and jtdhood gave to netcfg
14:36 -!- kalahann [~laurent@kinux.net1.nerim.net] has quit ["using sirc version 2.211+KSIRC/1.3.8"]
14:37 < joshk> yeah, that package is in a much better situation for sarge now
14:37 < joshk> no regrets if it happens
14:37 < pere> luther: what is the current state of parted?  creating ext3 partitions would be nice.
14:38 < luther> pere: current state is that i don't have realy the time to care about it alone.
14:38 -!- calc [~ccheney@cdm-208-180-235-136.cnro.cox-internet.com] has joined #debian-boot
14:38 <@bubulle> so, currently I think we should all give a few more attention to partman stuff and maybe try to do some bugs triage
14:38 < luther> pere: positive point is that upstream parted now lives in the CVS repo on the alioth parted project.
14:38 < kmuto> (ah,nope this is vmware's problem...)
14:38 <@bubulle> OK....short break..:-)
14:38 <@bubulle> time for a summary
14:38 <@bubulle> release: done
14:38 < luther> pere: ext3 support would need some work though.
14:39 <@bubulle> ports: done
14:39 <@bubulle> priority and line drawing: obsolete concerns is we drop sarge_d-i
14:39 < pere> luther: yes.  ntfs shrinking as well. :/
14:39 -!- eddyp [~eddy@82.77.146.54] has quit ["ChatZilla 0.9.52B [Mozilla rv:1.6/1]"]
14:39 <@bubulle> partman: we just talked about it
14:39 < joshk> what next?
14:39 < joeyh> (priority was never a problem for sarge_d-i anyway, afaik)
14:39 < zboob> for information, i have tested plip with last new netcfg, and it works fine
14:39 < anibal> bubulle: amd64?
14:39 <@bubulle> we have a few "small" things
14:39 <@bubulle> ooooops
14:40 < joshk> calc?
14:40 < joshk> Q_?
14:40 <@bubulle> anibal is right: my mistake
14:40 < calc> i'm here
14:40 < joshk> go
14:40 < luther> pere: i don't think Andrew is upto it, he has been searching for co-maintainers since some time, but i saw some interesting conversation about this in the parted mailing list these past days.
14:40 < joshk> basically, is it installable, what needs fixing, etc
14:40 < calc> last i checked amd64 seemed done, i haven't checked it in a few weeks though
14:40 < calc> it would be useful to have a 2.6 installer with 2.6.7 if thats not already done
14:40 < Q_> The only big issues I know off is that sometimes people have recent hardware that isn't autodetected yet.
14:41 < luther> bubulle: partman, please add making "erase the whole disk" not the default, and passing directly from the format the partition -> choose filesystem -> choose mountpoint.
14:41 < calc> the only problem i had with it was kernel related last i checked
14:41 < Q_> calc: It's using 2.6.7
14:41 <@bubulle> this is very similar to i386 concerns, right?
14:41 <@bubulle> about hardware, I mean
14:41 < calc> bubulle: yea
14:41 < Q_> bubulle: Yes.
14:41 < calc> if the kernel is too old new hardware doesn't work the usual problem, affects woody as well ;)
14:42 < calc> once we release sarge it would be a good idea to keep the d-i images up to date with new kernels if possible
14:42 < joshk> discover1 and 2.6 troubles me
14:42 <@bubulle> could you amd64 guys arrange some testings of sid_d-i images?
14:42 < joshk> because of module renaming
14:42 < calc> the last 8-10 systems i have had couldn't install woody (and i don't get new systems that often...) ;)
14:42 < joshk> espeially usb-ohci etc
14:42 < joshk> (became ohci-hcd
14:42 <@bubulle> targetting default installs (noc omplicate partition schemes) and correct reboot to 2nd stage
14:42 < joshk> so, we might have to come up with a discover workaround for this
14:42 < joeyh> happily usb-discover avoids the issue
14:42 < Q_> bubulle: What kind of images are that exactly?
14:43 < Q_> We have netinst, netboot, cdrom
14:43 < calc> bubulle: i could reinstall amd64 debian on my two amd64 machines (one desktop, one laptop) and fill out reports
14:43 < joeyh> not perfectly, not for second stage for instance
14:43 < fjp> joshk: In my experience hotplug takes over a lot of what discover misses...
14:44 < joeyh> I guess my main question for amd64 is what do we do about it at release if the ftp-master has not put it in the archive?
14:44 -!- anmar [~anmar@d207-6-222-111.bchsia.telus.net] has joined #debian-boot
14:44 <@bubulle> netinst with d-i packages from unstable and the remaining from sarge. Right, joeyh?
14:44 < joeyh> do we mention it? As unofficial?
14:44 < joshk> well...
14:44 < joshk> it's a pretty damn good unofficial job
14:44 -!- doko [~doko@dsl-082-083-147-007.arcor-ip.net] has joined #debian-boot
14:44 < joeyh> bubulle: sure, sid_d-i
14:44 < joshk> i wish it could just get put in
14:44 < joshk> i have been testing sid_d-i (or the equivalent thereof) for amd64
14:44 < joshk> i'm very impressed
14:44 < joshk> complete install takes under 10 minutes
14:44 < Q_> amd64 currently doesn't have testing.
14:44 < joeyh> yes, but since that's not my decision, or the decisoion of anyone here, we have to have plans
14:45  * bubulle breaks for a while
14:46 < anmar> Hello all
14:46 < joshk> joeyh: thanks, i forgot about usb-discover
14:46 < CIA-2> joshk * r17574 packages/usb-discover/ (debian/changelog ohci-pci.lst): add AMD-8111 support
14:47 < joshk> so if that change is in, i could isntall from a USB CD-ROM on a box with ---^ this chipset
14:47 < joshk> ?
14:47 < pere> joshk: remember to submit the same info to discover1-data.
14:47 < joeyh> joshk: be sure to add that to discover-data too..
14:47 < joshk> pere: done
14:47 < joshk> joeyh: bug
14:47 < joshk> er, bug has been filed
14:47 <@bubulle> OK, back
14:47 < joshk> pere: aha, but should i say: ohci-hcd, or usb-ohci?
14:47 < pere> joshk: discover1-data uses 2.4 module names, discover-data can handle both 2.4 and 2.6 module names.
14:48  * bubulle wonders whether there are some other important points (others are on the agenda, I know) that need discussions
14:48 < Q_> We're using discover1-data on 2.6
14:48 < anibal> d-i manual?
14:48 < pere> there is a charset issue in base-config.
14:48 < zboob> do you think, it's possible to have floppies for arch alpha
14:48 < joshk> Q_: which is why i am worried
14:48 < joshk> pere: do you think we should make a source change?
14:48 <@bubulle> pere: in sid_d-i?
14:48 -!- kraai [~kraai@host-66-81-192-30.rev.o1.com] has quit [Read error: 110 (Connection timed out)]
14:48 < joshk> call uname, and replace usb-ohci with ohci-hcd on 2.6?
14:49 < anmar> bubulle, hello. got a question on how to merge arabeyes d-i po files so I can get all the latest updates ? Is there a place to get the doc. I forgot how to do it. sorry
14:49 < ths> bubulle: netinst-image shoulg be renamed to baseinst-image, IMHO.
14:49 < pere> console-tool seem to set the console charset, while base-config assume the default to be ISO-8859-1 (and termwrap reset it after base-config is done).
14:49 < Q_> joshk: i386 uses discover1-data for 2.6 too.
14:49  * calc notes ftpmaster is not forthcoming with why its not being allowed in
14:49 < Q_> I think discover-data was more outdated than discover1-date or something?
14:49 < joshk> Q_: i know
14:49 < calc> tbm mentioned there was some reason he forgot about but hasn't responded to requests to nudge the info out of ftpmaster
14:49 < pere> Q_: discover1-data and discover-data is almost the same at the moment.
14:50 < gaudenz> Q_: Yes we know. But discover1-data only works if 2.4 and 2.6 module names don' differ.
14:50 < ths> calc: Isn't mirror space the main reason?
14:50 -!- alexn [~al@c-ce2571d5.12806-1-64736c12.cust.bredbandsbolaget.se] has joined #debian-boot
14:50 < anibal> bubulle: d-i manual?
14:50 < gaudenz> pere: I intend to make a diff between discover1-data and the pci.lst of discover-data
14:50 < calc> ths: we have no idea... :\
14:50 < pere> ths: that is a reason for not including it, not for being unresponsive.
14:50 <@bubulle> yep, d-i manual. fjp?
14:50 < Q_> pere: Then maybe i386/amd64 with 2.6 should switch back to discover-data?
14:51 < joshk> pere: any comment on making a discover1 source kludge
14:51 < calc> ths: since many mirror admins have offerred to provide space, i think that is not a real reason
14:51 < pere> Q_: perhaps.  it would be good to get more discover v2 testing, yes. :)
14:51 < calc> ths: tbm said there was a different reason other than space which was what he couldn't remember
14:51 < Q_> Why isn't discover-data the default anyway?
14:51 < Q_> For 2.4 that is.
14:52 < fjp> Manual: pretty much stalled.
14:52 < joshk> because we can't reduce the data
14:52 < pere> Q_: discover v2 is fairly untested, and the packages needed more space.
14:52 < ths> calc: Nearly all mirror admins would have to cope with it, or the mirror is lost.
14:52 -!- alexn [~al@c-ce2571d5.12806-1-64736c12.cust.bredbandsbolaget.se] has quit ["Client exiting"]
14:52 < joeyh> gravity had some ambitious plans for rewrite, but I have not heard from him lately
14:52 < fjp> Some people anounced wanting to work on it, but it's easy to get bogged down.
14:52 < pere> joeyh: rewriting what?
14:52 < calc> ths: i just heard there will be an email in the coming weeks about the issue
14:52 < joeyh> my impression is that the manual is not even accurate yet about things like images
14:52 < joeyh> pere: the installation manual
14:53 < gaudenz> joshk: which source kludge?
14:53 < joshk> gaudenz: when you come across usb-ohci as a module name to load, replace it with ohci-hcd if uname returns 2.6
14:53 < joshk> likewise for uhci-hcd
14:53 < ths> joeyh: For mips/mipsel, i skimmed over it, and it is completely out of date.
14:53 <@bubulle> So, manual is in not very good shape....right (need several rewrite)?
14:54 -!- mckinstr1 [~alastair@195.218.109.43] has quit [Remote closed the connection]
14:54 < fjp> Main problem is you need to take all architectures into account when updating the manual.
14:54 < joshk> hm, we should hook CIA-2 into pkg-discover
14:54 < gaudenz> joshk: Oh my good. That would be a hack!
14:54 -!- Marvin-- [~martin@sjogren.ost.sgsnet.se] has quit ["Klienten avslutas"]
14:54 < joshk> gaudenz: how broken does that sound?
14:54 < calc> ths: seems the only real issue is that debian can't communicate between members ;)
14:54 < gaudenz> joshk: to me it sounds very broken.
14:55 < fjp> And it's not easy to identify what's left-over Woody and what's OK for Sarge.
14:55 < joshk> pere: whoa, whoa, whoa, you just uploaded discover1-data?
14:55 <@bubulle> Well, it's about 2 hours we're on this meeting. I'm not sure we will have more very useful general discussions. I hereby propose to officially close it.....but discussions can continue, of course..:-)
14:55 < pere> joshk: just?  no.  Several week ago, I believe.
14:55  * calc bbl
14:56 < joeyh> yeah, meeting burn-out here..
14:56 <@bubulle> we're certainly missing several points, but the major ones were discussed. The rest may continue on list
14:56 < joeyh> will someone log and summarise it?
14:56 < joshk> pere: hmm
14:56 < Q_> pere: Can you do a new upload of it?
14:56 < joshk> you did dch -i, but never uploaded -10
14:56 <@bubulle> I have logged. I may summarize but, well, certainly not now....and tomorrow is huge workday
14:56 < pere> Q_: sure, so can joshk.
14:56 < Q_> (Or someone else.)
14:56 < pere> joshk: ah, it wasn't flagged UNRELEASED.
14:57 -!- mvdr [~max@168-99.241.81.adsl.skynet.be] has joined #debian-boot
14:57 < joshk> pere: my bad
14:57 -!- bubull1 [~bubulle@lns-th2-5f-81-56-227-253.adsl.proxad.net] has left #debian-boot []
14:57 < zboob> just for information, is thersomeone who test install with pppoe ?
14:57 < pere> joshk: I'll fix it.
14:57 < joshk> pere:  nononono
14:57 < joshk> don't C with my changes
14:57 -!- [JEB] [~jeb@jeb-debian.demon.co.uk] has quit ["Leaving"]
14:57 < joshk> i already fixed it here
14:57 < joshk> cause i have changes of my own
14:58 < joshk> pere: what do you think of making this package native as well?
14:58 < pere> joshk: I don't care. :)
14:58 < gaudenz> joshk: discover1-data?
14:58 < joshk> yes
14:58 <@bubulle> hmmm, logs did of course not work, crap
14:58 < fjp> zboob: I'd like to help, but I have ADSL-to-ethernet router and don't need pppoe. Sorry.
14:58 <@bubulle> joshk: did you log?
14:58 < joshk> of course
14:58 < sc> bubulle: I have logged to
14:58 < joshk> i don't really want to summarize, though :)
14:59 <@bubulle> ok, then you're responsible for publishing the log..:-)
14:59 < gaudenz> joshk: ack, and get rid of the silly version numbers
14:59 < fjp> zboob: Most installation reports I've seen seem happy to install from CD and configure pppoe afterwards.
14:59 < gaudenz> perhaps a date based scheme would be best.
14:59 <@bubulle> just put it somehwere and announce in -boot as well as /topic
14:59 < sc> bubulle: it's ok if I put in on my website and post the link?
14:59 < gaudenz> or just count up the version number.
14:59 < zboob> ok, so i continue working on slip
14:59 < sc> bubulle: OK
15:00 < ths> joeyh: netinst-image should be renamed to baseinst-image, IMHO, to reduce user confusion with netboot.
15:00 <@bubulle> anyone publishing the log, please update http://wiki.debian.net/index.cgi?DebianInstallerMeetings
15:00 < joshk> yeah
15:00 < joshk> i got it
15:00 < joshk> $ tail -n 793 \#debian-boot.log
15:00 < joshk> you guys are a talkative buynch
15:00  * bubulle will zzzz..:-)
15:00 < zboob> did you talk about automatic install ?
15:00 < Q_> ths: I always get confused by netboot vs netinst too.
15:00 < kmuto> good night, bubulle
15:01 < pere> gaudenz joshk: a rewrite of discover1-data to do the package reduction the same way as discover-data would be a good idea.
15:01 < joshk> arrgh
15:01 < joshk> !
15:01 -!- mode/#debian-boot [+o joshk] by ChanServ
15:01 -!- mode/#debian-boot [+m] by joshk
15:01 <@joshk> will you guys stop talking while i tail!