Re: beta 2 and beyond

[David Nusinow]

Hi Jeff,

On Thu, Jan 15, 2004 at 09:33:31PM -0500, Jeff Bailey wrote:
> On Thu, 2004-01-15 at 20:23, David Nusinow wrote:
> 
> > And for discover1, there is a patch that apparently works to allow
> > discover1 to work with 2.6. 
> 
> I've been using the "modprobe -n" solution proposed in #223682 for a
> couple weeks now and it's been working well.

Ok, I've applied this patch locally and it works fine with the 2.6.0-2
image from the archive. That's the good news. The bad news is that it's
very slow for some reason. This is in the discover app itself it seems,
not the init script. Have you had this problem as well? I'm going to
commit this change to the discover cvs repo on alioth. If someone
running 2.6 would please download discover and test it to see if the
slowdown is present? Slow support is better than no support, so I'd like
to see this patch present in the d-i release, but I'd like to know if I
need to try and find the source of the slowdown or not.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Stuart Sheldon]

Fabrice Lorrain (home) wrote:
Erich Waelde a écrit :

please add

- raidsupport
the md-modules are already available (used by the lvm-stuff), and
should be useful without further modification I think. So that
would need a raidtools2 udeb or similar and a config dialog to
create /etc/raidtools.
ok, it's one of my favourites, but I know a couple more admins waiting 
for
it. 


I'm one of those admins.

@+,
Fab

Me Three!

Stu

--
Q:  What do you get when you cross the Godfather with an attorney?
A:  An offer you can't understand.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Fabrice Lorrain (home)]

Erich Waelde a écrit :
please add

- raidsupport
the md-modules are already available (used by the lvm-stuff), and
should be useful without further modification I think. So that
would need a raidtools2 udeb or similar and a config dialog to
create /etc/raidtools.
ok, it's one of my favourites, but I know a couple more admins waiting for
it. 
I'm one of those admins.

@+,
Fab
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Steve Langasek]

On Thu, Jan 15, 2004 at 10:21:15AM +0100, Sven Luther wrote:

> > In a sense we're not done with beta2 yet, since we have between 1 and
> > 2.5 architectures that are still in positions to possibly be added to
> > the beta in a week or two. At the same time, I am eager to open unstable
> > back up to continued development especially with so many improvements
> > already waiting to go in. The conflict here is that if a package is
> > destablised in unstable, and then the beta2 "backport" needs to get a
> > minor fix to that package into sarge to make it work on a pending
> > architecture, I won't be able to get that fix into sarge; it will be
> > blocked by the changes in unstable.

> I am dubious about the non-newpmac powerpc architectures. The subarch
> handling that did work in Oldenbourg has been disabled, and there is not
> yet support for different initrd's and kernels for a same arch. Would
> enabling this inside the beta2 branch not create risk of breaking
> something else ?

Surely such changes must be tested on the CVS trunk first?

-- 
Steve Langasek
postmodern programmer


pgp0.pgp
Description: PGP signature

Re: beta 2 and beyond

[Steve Langasek]

On Fri, Jan 16, 2004 at 05:13:11PM +, Colin Watson wrote:
> On Fri, Jan 16, 2004 at 12:01:06PM -0500, Joey Hess wrote:
> > I notice that lots of people here and elsewhere are talking as if
> > sarge's release is fairly imminant. I must have missed a message from aj
> > giving a projected date; what's up?

> If we foster that attitude then it has a much better chance of becoming
> a self-fulfilling prophecy. :)

> (I haven't heard a projected date either, but my strong impression is
> that a lot of things are falling into place, so we should be able to
> work something out "soon" - perhaps once the reaction to d-i beta2 is
> clear.)

Precisely -- the release can only be as imminent as we're willing to
believe it is. :)

The exact release timeline is obviously aj's call, but given the
tremendous effort that Colin, Nathan et al. have put into getting
testing updated, I think we're close to having everything in sarge
that's going to be in sarge, which will leave only the question of
pulling things out of sarge that are RC buggy and *shouldn't* be there.

And the question of the installer.  Hence the studious application of
spurs. ;)

-- 
Steve Langasek
postmodern programmer


pgp0.pgp
Description: PGP signature

Re: beta 2 and beyond

[Bastian Blank]

On Fri, Jan 16, 2004 at 11:57:29AM -0500, Joey Hess wrote:
> I don't know if the Menu-Item-Number stuff can vary by architecture. I
> think it can, with some difficulty.

Not yet.

Bastian

-- 
Beam me up, Scotty!


signature.asc
Description: Digital signature

Re: beta 2 and beyond

[Sven Luther]

On Fri, Jan 16, 2004 at 12:02:23PM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > A new linux-kernel-di upload is needed tomorrow, after my -5 kernels
> > enter the archive, i missed the deadline yesterday. They add support for
> > old world pmac, as tested by Jeremie Koenig, and the pegasos RTC fix.
> 
> I think I'll get this in today.

Cool, i will work on the rest of the stuff tomorrow then.

> > Also, is it ok, if in my next upload, i drop the udeb packages ?
> 
> As far as I can tell powerpc has swtiched over to the -di udebs, so yes,
> that should be fine.

Ok, i will remove them in my next upload.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Steve Langasek]

On Fri, Jan 16, 2004 at 11:57:29AM -0500, Joey Hess wrote:
> Steve Langasek wrote:
> > A related question, will the partitioner preferences be decided on a
> > per-architecture basis?  There are special considerations on some
> > architectures (e.g., BSD disklabels on alpha, GPT on ia64?) that need to
> > be taken into account before partman can serve as a reasonable default
> > on all ports.

> I don't know if the Menu-Item-Number stuff can vary by architecture. I
> think it can, with some difficulty.

> I hope partman is flexible enough so modules can be added to address the
> things you mentioned..

I hope so too, but it does underscore the need for partman to be tested
on multiple architectures before it can be made a default anywhere
(unless we want to endure the per-architecture menu-item-numbers).

Cheers,
-- 
Steve Langasek
postmodern programmer


pgp0.pgp
Description: PGP signature

Re: beta 2 and beyond

[Colin Watson]

On Fri, Jan 16, 2004 at 12:01:06PM -0500, Joey Hess wrote:
> I notice that lots of people here and elsewhere are talking as if
> sarge's release is fairly imminant. I must have missed a message from aj
> giving a projected date; what's up?

If we foster that attitude then it has a much better chance of becoming
a self-fulfilling prophecy. :)

(I haven't heard a projected date either, but my strong impression is
that a lot of things are falling into place, so we should be able to
work something out "soon" - perhaps once the reaction to d-i beta2 is
clear.)

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Joey Hess]

Sven Luther wrote:
> A new linux-kernel-di upload is needed tomorrow, after my -5 kernels
> enter the archive, i missed the deadline yesterday. They add support for
> old world pmac, as tested by Jeremie Koenig, and the pegasos RTC fix.

I think I'll get this in today.

> Also, is it ok, if in my next upload, i drop the udeb packages ?

As far as I can tell powerpc has swtiched over to the -di udebs, so yes,
that should be fine.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: beta 2 and beyond

[Joey Hess]

David Nusinow wrote:
> Are we really planning to switch over to discover2 for the release!?!
> Switching a mature and well tested package for a brand new one this
> close to release would be bad, and I hope I'm not the only one who
> thinks this.

Part of the reason I posted that long list is because we need to decide
which parts of it we can realistically hope to achieve before the next
release. Which includes of course, deciding when we want to get the next
release out.

I notice that lots of people here and elsewhere are talking as if
sarge's release is fairly imminant. I must have missed a message from aj
giving a projected date; what's up?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: beta 2 and beyond

[Joey Hess]

Steve Langasek wrote:
> A related question, will the partitioner preferences be decided on a
> per-architecture basis?  There are special considerations on some
> architectures (e.g., BSD disklabels on alpha, GPT on ia64?) that need to
> be taken into account before partman can serve as a reasonable default
> on all ports.

I don't know if the Menu-Item-Number stuff can vary by architecture. I
think it can, with some difficulty.

I hope partman is flexible enough so modules can be added to address the
things you mentioned..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: beta 2 and beyond

[Martin Sjögren]

fre 2004-01-16 klockan 07.04 skrev Christian Perrier:
> > See the item about subversion.. ;-)
> 
> 
> Hmmm ? I can't say that I'm in favour of it.I've just started to
> learn the CVS basics so switching to something else fears me a bit
> (old people fear changes, you know..:-)))

I've used CVS for ages myself, and been scared to death by the more
intricate features like branching and merging. I can use tagging
decently, but that's about it. I found Subversion a lot easier to use,
and while it's not perfect, it is at least a lot better than CVS.

"Subversion for CVS Users" is a good text:
http://svnbook.red-bean.com/html-chunk/apa.html


/Martin
-- 
Martin Sjögren
  [EMAIL PROTECTED] -- [EMAIL PROTECTED]
  GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html
  let hello = "hello" : hello in putStr (unlines hello)


signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad	meddelandedel

Re: beta 2 and beyond

[Colin Watson]

On Fri, Jan 16, 2004 at 07:04:08AM +0100, Christian Perrier wrote:
> Quoting Joey Hess ([EMAIL PROTECTED]):
> > Christian Perrier wrote:
> > > However, I find its location in the CVS tree quite strange. Why isn't
> > > it under tools? Seems a pretty minor problem but this needs to be
> > > fixed, imho.
> > 
> > See the item about subversion.. ;-)
> 
> Hmmm ? I can't say that I'm in favour of it.I've just started to
> learn the CVS basics so switching to something else fears me a bit
> (old people fear changes, you know..:-)))

Subversion's designed specifically as a CVS replacement, but better. For
the basic work cycle, you can mostly replace 'cvs' with 'svn' and notice
quite little difference, with the exception that 'svn status' is much
more useful than 'cvs status' and something you use often.

There's a "Subversion for CVS Users" chapter in the Subversion book that
should help you.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Sven Luther]

On Thu, Jan 15, 2004 at 02:02:16PM -0600, Steve Langasek wrote:
> On Thu, Jan 15, 2004 at 07:24:05AM +0100, Christian Perrier wrote:
> > >  - partman
> > >   Likewise, the plan here is to get it into the installer but with
> > >   a menu item that makes it non-default (like autopartkit) until
> > >   we're comfortable with it. Since it meets requirement I., it can
> > >   go in soon.
> 
> > However, I find its location in the CVS tree quite strange. Why isn't
> > it under tools? Seems a pretty minor problem but this needs to be
> > fixed, imho.
> 
> > Will we completely drop out fdisks and partitioner or keep it as an
> > "expert" option?
> 
> A related question, will the partitioner preferences be decided on a
> per-architecture basis?  There are special considerations on some
> architectures (e.g., BSD disklabels on alpha, GPT on ia64?) that need to
> be taken into account before partman can serve as a reasonable default
> on all ports.
> 
> I do think that it should soon be able to replace autopartkit
> altogether, since autopartkit probably also fails on these ports. :)

Also, this is another point were subarch support is needed.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Sven Luther]

On Fri, Jan 16, 2004 at 07:04:08AM +0100, Christian Perrier wrote:
> Quoting Joey Hess ([EMAIL PROTECTED]):
> > Christian Perrier wrote:
> > > >  - partman
> > > > Likewise, the plan here is to get it into the installer but with
> > > > a menu item that makes it non-default (like autopartkit) until
> > > > we're comfortable with it. Since it meets requirement I., it can
> > > > go in soon.
> > > 
> > > However, I find its location in the CVS tree quite strange. Why isn't
> > > it under tools? Seems a pretty minor problem but this needs to be
> > > fixed, imho.
> > 
> > See the item about subversion.. ;-)
> 
> 
> Hmmm ? I can't say that I'm in favour of it.I've just started to
> learn the CVS basics so switching to something else fears me a bit
> (old people fear changes, you know..:-)))

Don't worry, subversion is nice and very easy. You will get used to it
extremely quickly.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Miroslav Kure]

On Thu, Jan 15, 2004 at 02:55:48PM +0100, Steinar H. Gunderson wrote:
> On Wed, Jan 14, 2004 at 10:33:57PM -0500, Joey Hess wrote:
> >  - a manual
> > Seems to be making progress, but needs to make more progress.
> 
> Should "how to customize d-i" be a part of this?

Definitely.

At least how to replace bundled kernel with your own one (what needs
to be compiled in) - see chapter tech-info in the b-f manual. Much can
be copied from debian-installer/doc/docbook/kernel-policy.xml.

If you know any other customization which has positive impact on
installability, go ahead and write about it.

-- 
Miroslav Kure


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Christian Perrier]

Quoting Joey Hess ([EMAIL PROTECTED]):
> Christian Perrier wrote:
> > >  - partman
> > >   Likewise, the plan here is to get it into the installer but with
> > >   a menu item that makes it non-default (like autopartkit) until
> > >   we're comfortable with it. Since it meets requirement I., it can
> > >   go in soon.
> > 
> > However, I find its location in the CVS tree quite strange. Why isn't
> > it under tools? Seems a pretty minor problem but this needs to be
> > fixed, imho.
> 
> See the item about subversion.. ;-)


Hmmm ? I can't say that I'm in favour of it.I've just started to
learn the CVS basics so switching to something else fears me a bit
(old people fear changes, you know..:-)))

But, for sure, being everything but what may seriously be called a
developer, I'm sure you guys real developers have very good reasons
for switching, so I'll follow the movement.

(no kidding or ranting above...just being realistic)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Steve Langasek]

On Thu, Jan 15, 2004 at 07:24:05AM +0100, Christian Perrier wrote:
> >  - partman
> > Likewise, the plan here is to get it into the installer but with
> > a menu item that makes it non-default (like autopartkit) until
> > we're comfortable with it. Since it meets requirement I., it can
> > go in soon.

> However, I find its location in the CVS tree quite strange. Why isn't
> it under tools? Seems a pretty minor problem but this needs to be
> fixed, imho.

> Will we completely drop out fdisks and partitioner or keep it as an
> "expert" option?

A related question, will the partitioner preferences be decided on a
per-architecture basis?  There are special considerations on some
architectures (e.g., BSD disklabels on alpha, GPT on ia64?) that need to
be taken into account before partman can serve as a reasonable default
on all ports.

I do think that it should soon be able to replace autopartkit
altogether, since autopartkit probably also fails on these ports. :)

-- 
Steve Langasek
postmodern programmer


pgp0.pgp
Description: PGP signature

Re: beta 2 and beyond

[Steve Langasek]

On Thu, Jan 15, 2004 at 07:54:08AM +0100, Thorsten Sauter wrote:

> |  - XFS
> | Could happen a number of ways, either as an alternate boot on
> | the CDs, or by XFS finally being added to stock 2.4.25/6, or by
> | d-i getting support for 2.6. I'm sure that Steve will come up
> | with something.

> please do not use a different boot method for this. Just let us include
> it in the same way like all other filesystems. I think XFS is often used
> by people. And I really like to see it in the normal installer.

I would love to see it as part of the stock kernel, but I don't want to
risk destabilizing the kernel for non-XFS users.  I'll continue working
on the XFS-flavor images until they're superseded by integrated XFS in
a released 2.4 kernel, or by a viable 2.6 d-i boot method.

> |  - 2.6 kernel
> | For some arches at least, possibly not as the default but
> | available as an alternate boot on the CDs. Blocked by discover 2.

> is anybody working on the 2.6 kernel tree for powerpc machines? Sven? 

If 2.6 support gets good enough, it's possible the alpha port will want
to switch to it completely.  There seem to be lots of hardware-specific
problems with the later 2.4 kernels on alpha, that some say may be fixed
in 2.6.  Unfortunately I haven't used 2.6 at all yet, so there'll be a
learning curve to overcome unless someone else wants to work on this.

Cheers,
-- 
Steve Langasek
postmodern programmer


pgp0.pgp
Description: PGP signature

Re: beta 2 and beyond

[Jeff Bailey]

On Thu, 2004-01-15 at 20:23, David Nusinow wrote:

> And for discover1, there is a patch that apparently works to allow
> discover1 to work with 2.6. 

I've been using the "modprobe -n" solution proposed in #223682 for a
couple weeks now and it's been working well.

Tks,
Jeff Bailey

-- 
I never know what to expect when you respond to my postings. No insult
intended, you are merely a surprise :)
 - Carlos O'Donnell


signature.asc
Description: This is a digitally signed message part

Re: beta 2 and beyond

[David Nusinow]

On Thu, Jan 15, 2004 at 07:35:26PM +0100, Gaudenz Steinlin wrote:
> I request you to make an exception for discover as the next upload
> should have no impact on d-i and fixes quite important bugs in the deb.
> We might delay the next discover-data upload some day as this is more or
> less cosmetic and the really important fixes are in the archive.

I'd also like to see this. The module sorting bugfix is fairly
important, and if it turns out that it causes problems we can simply
back out that change before beta3/release. As for discover-data, I don't
see the point in not having those changes in, since they're very minor
and do fix actual bugs found by our testers.

> >  - discover 2
> > I guess all the hard work has been done. IIRC the plan is to
> > upload it with a different name, so we can test installs using
> > it before swtiching overything away from discover 1. If this
> > does not involve renaming the existing discover udeb, it will
> > meet requirement I., and can be uploaded to unstable soon.
> This is already in the archive. But I jus discovered it did not build on
> the autobuilders due to a problem with the build depends:
> discover2 depends on kernel-headers-2.4.20-386 | kernel-headers which
> yields "E: Couldn't find package kernel-headers-2.4.20-386". How can I
> best solve this? Should I include the relevant kernel headers in the
> package or build-depend on a kernel-headers package for every arch?
> If I can't build-depend on a virtual package this is going to cause
> headaches as these headers change their package name with every new
> kernel released.

Are we really planning to switch over to discover2 for the release!?!
Switching a mature and well tested package for a brand new one this
close to release would be bad, and I hope I'm not the only one who
thinks this.

> >  - 2.6 kernel
> > For some arches at least, possibly not as the default but
> > available as an alternate boot on the CDs. Blocked by discover 2.
> How is this connected to discover2?
> Someone simply has to come up with a discover-data list for 2.6. I think
> we should not put to much energy in 2.6 support as I hope most/all
> hardware will be supported by 2.4 for some time. So changing to a 2.6
> kernel can be done after the installation.

And for discover1, there is a patch that apparently works to allow
discover1 to work with 2.6. This is my only reservation about releasing
discover1 to sarge, since people will undoubtedly be using 2.6 with
sarge, and I want to make sure the discover that we release supports
them. If we're just going to go with discover2 instead, then I'll give
up that idea though.

> >  - switch to subversion
> > It would be good to reorganise the tree, and some things are
> > waiting on that being done. Since this has the potential to
> > disrupt everything else during the transition, we'll have to be
> > very cautious.
> This would be a good idea.

I'd like to move the discover alioth project in to svn as well.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Sven Luther]

On Thu, Jan 15, 2004 at 07:54:08AM +0100, Thorsten Sauter wrote:
> * Joey Hess <[EMAIL PROTECTED]> [2004-01-15 04:33]:
> | I've gone ahead and started the beta 2 release process. CD images are in
> | place and I will send out the release announcement once the web site has
> | updated. (Some install media won't appear in sarge until tomorrow's
> | dinstall.)
> 
> yeah!! :-)
> 
> |  - XFS
> | Could happen a number of ways, either as an alternate boot on
> | the CDs, or by XFS finally being added to stock 2.4.25/6, or by
> | d-i getting support for 2.6. I'm sure that Steve will come up
> | with something.
> 
> please do not use a different boot method for this. Just let us include
> it in the same way like all other filesystems. I think XFS is often used
> by people. And I really like to see it in the normal installer.
> 
> |  - 2.6 kernel
> | For some arches at least, possibly not as the default but
> | available as an alternate boot on the CDs. Blocked by discover 2.
> 
> is anybody working on the 2.6 kernel tree for powerpc machines? Sven? 

Not yet, but it is planed. I only have so much time to devote to this
though, so be patient. 

In any case, we need to check the new apple hardware and see if the
current kernel boots on it, if not we are going to need 2.6 kernels.

I will try to upload a 2.6 kernel next week or something.

In the meantime, i want us to move to 2.4.24 as default kernel for post
beta2 debian-installer.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Sven Luther]

On Wed, Jan 14, 2004 at 10:33:57PM -0500, Joey Hess wrote:
> I've gone ahead and started the beta 2 release process. CD images are in
> place and I will send out the release announcement once the web site has
> updated. (Some install media won't appear in sarge until tomorrow's
> dinstall.)
> 
> I have to say that this release took longer to get done than I'd hoped.
> We started out strong, the compromise was unavoidable and was handled as
> well as can be expected, the string freeze went well, the holiday
> slowdown was worse than I expected, and then it felt to me as if things
> trailed off at the end instead of us making a big push to finish the
> release. I'm going to think about this and try to figure out things that
> went wrong and how to avoid them, and I'd appreciate any insights anyone
> might have.

Don't ever make release schedules between christmas and new year :)

Also, the intrusion was a slowing factor which should not happen again
hopefully, and the NEW processing freeze made it even worse.

> Anyway with luck we now have a firm release, available in the sarge
> distribution, for three architectures, which is an important step along
> the way to sarge releasing with d-i.
> 
> In a sense we're not done with beta2 yet, since we have between 1 and
> 2.5 architectures that are still in positions to possibly be added to
> the beta in a week or two. At the same time, I am eager to open unstable
> back up to continued development especially with so many improvements
> already waiting to go in. The conflict here is that if a package is
> destablised in unstable, and then the beta2 "backport" needs to get a
> minor fix to that package into sarge to make it work on a pending
> architecture, I won't be able to get that fix into sarge; it will be
> blocked by the changes in unstable.

I am dubious about the non-newpmac powerpc architectures. The subarch
handling that did work in Oldenbourg has been disabled, and there is not
yet support for different initrd's and kernels for a same arch. Would
enabling this inside the beta2 branch not create risk of breaking
something else ?

Also, i am a bit unhappy about this, we all knew it was needed, so why
was the existing subarch functionality disabled, and why did nobody care
about this ? And this does not only affect powerpc, all other arch with
subarch handling are affected.

> So starting after tomorrow's dinstall (just in case something goes
> wrong), unstable is reopened for uploads of:
> 
>   I.   NEW udebs (partman, etc), that are not present in sarge.
>   II.  Any changes necessary for mips, alpha, and powerpc subarches,
>targeted at beta 2.

A new linux-kernel-di upload is needed tomorrow, after my -5 kernels
enter the archive, i missed the deadline yesterday. They add support for
old world pmac, as tested by Jeremie Koenig, and the pegasos RTC fix.

Also, is it ok, if in my next upload, i drop the udeb packages ?

Also, power3/power4 based boxes would need a new kernel config, but will
be slowed by NEW queue processing if i upload it. Well, this will only
be for 32bit kernel for those, not (yet) for 64bit kernels.

Also, a powerpc kernel upgrade may be needed for newer apple hardware,
maybe based on the -benh tree. Or maybe even an option for 2.6 kernels
for the G5 based pmacs ?

Finally, cdrom initrd is too big for chrp/chrp-rs6k builtin initrd.
netboot works fine tough.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Gaudenz Steinlin]

Am Don, den 15.01.2004 schrieb Joey Hess um 04:33:
> I've gone ahead and started the beta 2 release process. CD images are in
> place and I will send out the release announcement once the web site has
> updated. (Some install media won't appear in sarge until tomorrow's
> dinstall.)
> 
OK, beta2 is out now. So I suppose powermac test are no longer needed.

> I have to say that this release took longer to get done than I'd hoped.
> We started out strong, the compromise was unavoidable and was handled as
> well as can be expected, the string freeze went well, the holiday
> slowdown was worse than I expected, and then it felt to me as if things
> trailed off at the end instead of us making a big push to finish the
> release. I'm going to think about this and try to figure out things that
> went wrong and how to avoid them, and I'd appreciate any insights anyone
> might have.
Sorry I did not have much spare time to spend on d-i since christmas.
Unfortunately this is not going to change soon. I will try to do my
best.
> 

>   I.   NEW udebs (partman, etc), that are not present in sarge.
>   II.  Any changes necessary for mips, alpha, and powerpc subarches,
>targeted at beta 2.
>   III. udebs that are only for architectures that do not plan to
>release with beta 2 (such as boot loader installers for
>unreleased architectures)
>   IV.  udebs that are only for architectures that have already
>released for beta 2
> But is still closed to uploads of:
> 
>   X.   Developmental changes of udebs that are in beta2. (busybox,
>build/, base-installer, main-menu, anna, etc, etc)
I request you to make an exception for discover as the next upload
should have no impact on d-i and fixes quite important bugs in the deb.
We might delay the next discover-data upload some day as this is more or
less cosmetic and the really important fixes are in the archive.
> 

>  - discover 2
>   I guess all the hard work has been done. IIRC the plan is to
>   upload it with a different name, so we can test installs using
>   it before swtiching overything away from discover 1. If this
>   does not involve renaming the existing discover udeb, it will
>   meet requirement I., and can be uploaded to unstable soon.
This is already in the archive. But I jus discovered it did not build on
the autobuilders due to a problem with the build depends:
discover2 depends on kernel-headers-2.4.20-386 | kernel-headers which
yields "E: Couldn't find package kernel-headers-2.4.20-386". How can I
best solve this? Should I include the relevant kernel headers in the
package or build-depend on a kernel-headers package for every arch?
If I can't build-depend on a virtual package this is going to cause
headaches as these headers change their package name with every new
kernel released.

>  - 2.6 kernel
>   For some arches at least, possibly not as the default but
>   available as an alternate boot on the CDs. Blocked by discover 2.
How is this connected to discover2?
Someone simply has to come up with a discover-data list for 2.6. I think
we should not put to much energy in 2.6 support as I hope most/all
hardware will be supported by 2.4 for some time. So changing to a 2.6
kernel can be done after the installation.

>  - udebs and debs with same namea
>   Some key changes in base-config are being blocked because we
>   cannot add debs of choose-mirror, etc to the archive. At the
>   same time, there is some uglyness in the initrd builds that
>   could be avoided if we could have a udeb named libc6. This seems
>   doable, but will require the assistance of the ftp-master and
>   has the potential to cause unanticipated problems.
I'm looking forward to this.
>  - switch to subversion
>   It would be good to reorganise the tree, and some things are
>   waiting on that being done. Since this has the potential to
>   disrupt everything else during the transition, we'll have to be
>   very cautious.
This would be a good idea.
>  - better wireless support
>   I think that a wireless-tools udeb just went in, but a frontend
>   to that is needed.
yes, the wireless-tools udeb is available now. The first step would be
to include it on the netboot images.
wireless-tools-udeb should probably be priority standard so anna pulls
it in by default.

Gaudenz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Joey Hess]

Thorsten Sauter wrote:
> |  - XFS
> | Could happen a number of ways, either as an alternate boot on
> | the CDs, or by XFS finally being added to stock 2.4.25/6, or by
> | d-i getting support for 2.6. I'm sure that Steve will come up
> | with something.
> 
> please do not use a different boot method for this. Just let us include
> it in the same way like all other filesystems. I think XFS is often used
> by people. And I really like to see it in the normal installer.

Well we're kind of limited to what is supported by the stock debian
kernel, which is why I mentioned 2.6 and 2.4.2x as possibilities.

> |  - switch to subversion
> | It would be good to reorganise the tree, and some things are
> | waiting on that being done. Since this has the potential to
> | disrupt everything else during the transition, we'll have to be
> | very cautious.
> 
> hmm. is this really needed _before_ the release?
 
No, but it would be silly to put it off until after the release.
 
-- 
see shy jo


signature.asc
Description: Digital signature

Re: beta 2 and beyond

[Joey Hess]

Christian Perrier wrote:
> >  - partman
> > Likewise, the plan here is to get it into the installer but with
> > a menu item that makes it non-default (like autopartkit) until
> > we're comfortable with it. Since it meets requirement I., it can
> > go in soon.
> 
> However, I find its location in the CVS tree quite strange. Why isn't
> it under tools? Seems a pretty minor problem but this needs to be
> fixed, imho.

See the item about subversion.. ;-)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: beta 2 and beyond

[Erich Waelde]

please add

- raidsupport
the md-modules are already available (used by the lvm-stuff), and
should be useful without further modification I think. So that
would need a raidtools2 udeb or similar and a config dialog to
create /etc/raidtools.

ok, it's one of my favourites, but I know a couple more admins waiting for
it. 

- XFS

I'd also prefer to see xfs in the list of file systems, just as any other.
So this needs to wait until 2.6 is available in the list of kernels.


Cheers,
Erich


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Steinar H. Gunderson]

On Wed, Jan 14, 2004 at 10:33:57PM -0500, Joey Hess wrote:
>  - a manual
>   Seems to be making progress, but needs to make more progress.

Should "how to customize d-i" be a part of this?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Christian Perrier]

Quoting Joey Hess ([EMAIL PROTECTED]):
> I've gone ahead and started the beta 2 release process. CD images are in

Great work, great summary, great everything...As usual..:-)


>  - partman
>   Likewise, the plan here is to get it into the installer but with
>   a menu item that makes it non-default (like autopartkit) until
>   we're comfortable with it. Since it meets requirement I., it can
>   go in soon.

However, I find its location in the CVS tree quite strange. Why isn't
it under tools? Seems a pretty minor problem but this needs to be
fixed, imho.

Will we completely drop out fdisks and partitioner or keep it as an
"expert" option?

>  - improved languagechooser
>   Possibly with country selection split out, but we need to try
>   it that way and see if we like it enough to add the extra
>   question. Christian can upload the new countrychooser when he's
>   happy with it (I.), but will have to wait to change languagechooser
>   in unstable (X.).

I'm OK with this. The new countrychooser is able to work concurrently
with the "old" languagechooser anyway.

I'll post a summary about the design of both and the possible drawbacks


>  - three more ports
>   Bringing the total released architectures to 7 or 8. alpha, 
>   hppa, mipsel, and sparc seem like contenders.
> 
> Please add to this list, though goodness knows, it's long enough
> already.


  - BIDI support
   Adding support for languages needing BiDirectional support
   in newt, which will probably allow Arabic translations to
   be usable (and a possible Hebrew translation, I think)

  - i18n 
   More languages : 24 are currently over 50% in HEAD. Catalan may
   come if I piss off Jordi Mallach enough. Turkish was supposed
   to climb but does not. Other are really anecdotical.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Thorsten Sauter]

* Joey Hess <[EMAIL PROTECTED]> [2004-01-15 04:33]:
| I've gone ahead and started the beta 2 release process. CD images are in
| place and I will send out the release announcement once the web site has
| updated. (Some install media won't appear in sarge until tomorrow's
| dinstall.)

yeah!! :-)

|  - XFS
|   Could happen a number of ways, either as an alternate boot on
|   the CDs, or by XFS finally being added to stock 2.4.25/6, or by
|   d-i getting support for 2.6. I'm sure that Steve will come up
|   with something.

please do not use a different boot method for this. Just let us include
it in the same way like all other filesystems. I think XFS is often used
by people. And I really like to see it in the normal installer.

|  - 2.6 kernel
|   For some arches at least, possibly not as the default but
|   available as an alternate boot on the CDs. Blocked by discover 2.

is anybody working on the 2.6 kernel tree for powerpc machines? Sven? 

|  - switch to subversion
|   It would be good to reorganise the tree, and some things are
|   waiting on that being done. Since this has the potential to
|   disrupt everything else during the transition, we'll have to be
|   very cautious.

hmm. is this really needed _before_ the release?

|  - better wireless support
|   I think that a wireless-tools udeb just went in, but a frontend
|   to that is needed.

yes. I think this is really urgent, because most of the modern laptops
contains a wifi card, and the users dosn't by normal network equiment

|  - three more ports
|   Bringing the total released architectures to 7 or 8. alpha, 
|   hppa, mipsel, and sparc seem like contenders.

hppa is now booting and installing for me (I have the 32MB ram problem
on this machine). Manty try to produce hppa cdrom images.


Bye
Thorsten




signature.asc
Description: Digital signature

Re: beta 2 and beyond

[Kenshi Muto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks summarize, Joey.

At 15 Jan 04 03:33:57 GMT,
Joey Hess wrote:
>  - better i18n in the second stage
>   We need to work out something in base-config that works as well
>   as d-i does for all our supported languages. Kensi has some
>   ideas, but they are not firm.

1. 1st stage still has 'missing glyph' problem (Bug#224227).
   Does anyone have idea? There is full font file at /unifont.bgf, but
   can't force bterm to reload this.

   (One of (suck) idea is to collect all of messages from
   debian-installer and add them into graphics.utf (or another new
   file) and commit. Oops..)

2. I don't certain this is really best way, but support localization
   packages at base-installer and 2nd stage works correctly.

   base-installer/postinst:
People who needs special packages from 2nd stage add routine in
queue_language_debs() function.

At the moment, there is
  ja(Japanese), ko(Korean), el(Greek), zh(Chinese): install
  jfbterm and unifont. Because these languages need special
  console.
  ru(Russian): install console-cyrillic, console-terminus.
  (But this needs some special debconf settings. I have no
  idea...)

If you add packages for your language, modify debian-cd CVS also.

   base-config/termwrap:
People who needs special work needs check routine after #Select
suitable terminal as wrapper.

At the moment, there is
 ISO-8859-1: Nothing to do
 ISO-8859-2: load charset
 ISO-8859-7: Greek. Load framebuffer(fb) and run jfbterm.
 ISO-8859-13: load charset
 ISO-8859-15: load charset
 eucJP: Japanese. Load framebuffer(fb) and run jfbterm.
 eucKR: Korean. Load framebuffer(fb) and run jfbterm.
 GB2312, BIG5: Chinese. Load framebuffer(fb) and run jfbterm.
 KOI8-R: Russian. Nothing to do. (If 1st stage treats nothing, you
 need to add some configuration routine.)
 UTF-8: Nothing to do (Is this really OK? IMHO linux console
doesn't support UTF-8)

 If you need to some wrapper for your console, add them.
 WRAPPER is program file, WRAPPER_OPTION is arg option for it.
 And check fallback routine (# Fallback to C) when wrapper goes
 failed.

Thanks,
- -- 
Kenshi Muto
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iEYEARECAAYFAkAGHSsACgkQQKW+7XLQPLFxSACgxqD/04zOhHmmX0DHhPMB8rfv
uZ4An3nushs18dOmUphG6liNVwJrm3lU
=mPgn
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: beta 2 and beyond

[Joey Hess]

I wrote:
> In a sense we're not done with beta2 yet, since we have between 1 and
> 2.5 architectures that are still in positions to possibly be added to
> the beta in a week or two. At the same time, I am eager to open unstable
> back up to continued development especially with so many improvements
> already waiting to go in. The conflict here is that if a package is
> destablised in unstable, and then the beta2 "backport" needs to get a
> minor fix to that package into sarge to make it work on a pending
> architecture, I won't be able to get that fix into sarge; it will be
> blocked by the changes in unstable.
> 
> So starting after tomorrow's dinstall (just in case something goes
> wrong), unstable is reopened for uploads of:
> 
>   I.   NEW udebs (partman, etc), that are not present in sarge.
>   II.  Any changes necessary for mips, alpha, and powerpc subarches,
>targeted at beta 2.
>   III. udebs that are only for architectures that do not plan to
>release with beta 2 (such as boot loader installers for
>unreleased architectures)
>   IV.  udebs that are only for architectures that have already
>released for beta 2
> 
> But is still closed to uploads of:
> 
>   X.   Developmental changes of udebs that are in beta2. (busybox,
>build/, base-installer, main-menu, anna, etc, etc)

I talked this over with aj, and we may be able to relax this somewhat.
It may be possible to upload udebs directory to testing, and have them
moved in from testing-proposed-updates. I'll investigate further, and if
it works out, we'll be able to make changes to more stuff in unstable.

-- 
see shy jo


signature.asc
Description: Digital signature

beta 2 and beyond

[Joey Hess]

I've gone ahead and started the beta 2 release process. CD images are in
place and I will send out the release announcement once the web site has
updated. (Some install media won't appear in sarge until tomorrow's
dinstall.)

I have to say that this release took longer to get done than I'd hoped.
We started out strong, the compromise was unavoidable and was handled as
well as can be expected, the string freeze went well, the holiday
slowdown was worse than I expected, and then it felt to me as if things
trailed off at the end instead of us making a big push to finish the
release. I'm going to think about this and try to figure out things that
went wrong and how to avoid them, and I'd appreciate any insights anyone
might have.

Anyway with luck we now have a firm release, available in the sarge
distribution, for three architectures, which is an important step along
the way to sarge releasing with d-i.

In a sense we're not done with beta2 yet, since we have between 1 and
2.5 architectures that are still in positions to possibly be added to
the beta in a week or two. At the same time, I am eager to open unstable
back up to continued development especially with so many improvements
already waiting to go in. The conflict here is that if a package is
destablised in unstable, and then the beta2 "backport" needs to get a
minor fix to that package into sarge to make it work on a pending
architecture, I won't be able to get that fix into sarge; it will be
blocked by the changes in unstable.

So starting after tomorrow's dinstall (just in case something goes
wrong), unstable is reopened for uploads of:

I.   NEW udebs (partman, etc), that are not present in sarge.
II.  Any changes necessary for mips, alpha, and powerpc subarches,
 targeted at beta 2.
III. udebs that are only for architectures that do not plan to
 release with beta 2 (such as boot loader installers for
 unreleased architectures)
IV.  udebs that are only for architectures that have already
 released for beta 2

But is still closed to uploads of:

X.   Developmental changes of udebs that are in beta2. (busybox,
 build/, base-installer, main-menu, anna, etc, etc)

Porters who want to keep working on beta2 will need to use the CD images
that don't include unstable udebs for testing, and as they fix problems,
tell me what udebs include the fix so I[1] can push them into sarge.
This may make things a little bit harder for you, which is why I've
added the extra week. We can make another announcement once more ports
are ready for beta2.


There are many things I'm looking forward to seeing in the next release
of d-i. Here is my wishlist:

 - security fixed, 2.4.23 kernel (with SATA support)
This should be relatively easy to roll out, I intend to update
linux-kernel-di for i386 soon, adding the 2.4.23 kernel while
keeping 2.4.22, and transition over to it. This will go into
unstable as it meets requirements I. and III. above.
 - discover 2
I guess all the hard work has been done. IIRC the plan is to
upload it with a different name, so we can test installs using
it before swtiching overything away from discover 1. If this
does not involve renaming the existing discover udeb, it will
meet requirement I., and can be uploaded to unstable soon.
 - partman
Likewise, the plan here is to get it into the installer but with
a menu item that makes it non-default (like autopartkit) until
we're comfortable with it. Since it meets requirement I., it can
go in soon.
 - grub
Fairly early in this cycle we need to swtich to grub as the
default boot loader on i386, so we can be confident it works
before the next release. It might be nice if a few of
grub-installer's worst bugs were fixed first though.
 - XFS
Could happen a number of ways, either as an alternate boot on
the CDs, or by XFS finally being added to stock 2.4.25/6, or by
d-i getting support for 2.6. I'm sure that Steve will come up
with something.
 - 2.6 kernel
For some arches at least, possibly not as the default but
available as an alternate boot on the CDs. Blocked by discover 2.
 - better i18n in the second stage
We need to work out something in base-config that works as well
as d-i does for all our supported languages. Kensi has some
ideas, but they are not firm.
 - improved languagechooser
Possibly with country selection split out, but we need to try
it that way and see if we like it enough to add the extra
question. Christian can upload the new countrychooser when he's
happy with it (I.), but will have to wait to change languagechooser
in unstable (X.).
 - improved image names
The floppy and initrd images need to be renamed using clearer
names and a dee