Bug#79950: updating to potato from Linux2.0.34( i believe it was hamm)

[Roland Bauerschmidt]

On Wed, Dec 20, 2000 at 06:21:39AM -0500, basic wrote:
> subprocess dpkg-deb --fsys-tarfile returned error exit status 2

Is your RAM ok? How much RAM do you have? Do you have a swap partition?

Roland

-- 
Roland Bauerschmidt <[EMAIL PROTECTED]>

Bug#21464: marked as done (bo -> hamm upgrade problems)

[Debian Bug Tracking System]

Your message dated Sun, 26 Mar 2000 11:48:44 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Closing old bug reports related to bo->hamm transition
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Darren Benham
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 21 Apr 1998 08:38:29 +
Received: (qmail 20818 invoked from network); 21 Apr 1998 08:38:29 -
Received: from tmcs.tm.tno.nl (HELO tmcs) (192.43.212.100)
  by debian.novare.net with SMTP; 21 Apr 1998 08:38:29 -
Received: from suntan.izf.tno.nl by tmcs (SMI-8.6/SMI-SVR4)
id KAA17882; Tue, 21 Apr 1998 10:38:25 +0200
Received: by suntan.izf.tno.nl (SMI-8.6/SMI-SVR4)
id KAA16615; Tue, 21 Apr 1998 10:38:24 +0200
Date: Tue, 21 Apr 1998 10:38:24 +0200
Message-Id: <[EMAIL PROTECTED]>
From: David van Leeuwen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: bo -> hamm upgrade problems

Package: dselect, general upgrading

I get several dependency loop poblems in upgrading from Debian 1.3.1
to hamm/frozen of last night.  First package was slang0.99.34, during 
install process of dselect:

Looking for part 1 of slang0.99.38 ... 
/root/debian/unstable/hamm/binary-i386/libs/slang0.99.38_0.99.38-2.18.deb
Running dpkg -iB for slang0.99.38 ...
dpkg: regarding .../slang0.99.38_0.99.38-2.18.deb containing slang0.99.38:
 slang0.99.38 conflicts with slang0.99.34 (<< 0.99.38-2.3)
  slang0.99.34 (version 0.99.38-2) is installed.
dpkg: error processing 
/root/debian/unstable/hamm/binary-i386/libs/slang0.99.38_0.99.38-2.18.deb 
(--install):
 conflicting packages - not installing slang0.99.38
Errors were encountered while processing:
 /root/debian/unstable/hamm/binary-i386/libs/slang0.99.38_0.99.38-2.18.deb

2nd try:

internal error - no filename at -e line 12,  chunk 21.

Then, i removed slang0.99.34 by hand (after removing dosemu) and
installed slang0.99.38 by hand. 

Now, dselect's install works again, but i get a next problem:

Looking for part 1 of libgdbmg1 ... 
/root/debian/unstable/hamm/binary-i386/base/libgdbmg1_1.7.3-24.deb
Running dpkg -iB for libgdbmg1 ...
dpkg: regarding .../base/libgdbmg1_1.7.3-24.deb containing libgdbmg1:
 libgdbmg1 conflicts with libgdbm1 (<< 1.7.3-20)
  libgdbm1 (version 1.7.3-19) is installed.
dpkg: error processing 
/root/debian/unstable/hamm/binary-i386/base/libgdbmg1_1.7.3-24.deb (--install):
 conflicting packages - not installing libgdbmg1
Errors were encountered while processing:
 /root/debian/unstable/hamm/binary-i386/base/libgdbmg1_1.7.3-24.deb

2nd try:

internal error - no filename at -e line 12,  chunk 19.

And i really can't solve that by hand.  

---david
---
Received: (at 21464-done) by bugs.debian.org; 26 Mar 2000 09:48:47 +
Received: (qmail 1456 invoked from network); 26 Mar 2000 09:48:47 -
Received: from i511.resi.insa-lyon.fr (HELO k6.resI.insa-lyon.fr) 
(134.214.164.9)
  by master.debian.org with SMTP; 26 Mar 2000 09:48:47 -
Received: by k6.resI.insa-lyon.fr (Postfix, from userid 1001)
id 56A604045; Sun, 26 Mar 2000 11:48:44 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 26 Mar 2000 11:48:44 +0200
From: Raphael Hertzog <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Closing old bug reports related to bo->hamm transition
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.93i

Evrything in the subject. Those bugs are no more of actuality.

Cheers,
-- 
Raphaël Hertzog >> 0C4CABF1 >> http://tux.u-strasbg.fr/~raphael/
 CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd
  Formations Linux et logiciels libres : http://www.logidee.com 

Re: pseudo package for upgrades from hamm

[Raphael Hertzog]

Le Thu, Jan 21, 1999 at 04:48:04AM -, Robert Woodcock écrivait:
> So, the gist of that is that dpkg has been left for dead (well, NMU hell
> anyway) for a full year and there hasn't been *that* many complaints.
> Just no new features.

I don't agree. I don't want to blame anybody since i'am not yet able to 
correct C programs, but dpkg need to be worked on. I'm french and
i've set LC_ALL=fr_FR, you can't imagine how many times I had a
dpkg core dump because of this (it's reported many times in the BTS). 

Now every time I do an upgrade, i use :
LC_ALL=C apt-get upgrade

And this is *very* inconvenient.

Cheers,
-- 
Raphaël Hertzog >> 0C4CABF1 >> http://prope.insa-lyon.fr/~rhertzog/

Re: pseudo package for upgrades from hamm

[Robert Woodcock]

Martin A. Soto wrote:
>
>Many, *many* people has proposed this idea before.  So many, that you
>would be tempted to consider it a simple, natural, and straightforward
>idea.  Nonetheless, it seems that this far, it has been impossible to
>make it part of dpkg, or even to start working on the necessary
>modifications for that purpose.

I don't think anyone's filed that particular idea as a wishlist bug against
dpkg yet. I plan to.

If you want to start, there's nothing stopping you, except your own
inability to figure out other people's code (this is actually a serious
problem for most of us mere mortals :)

If you're serious, you'll probably want to join the
debian-dpkg@lists.debian.org mailing list (hmmm, very hypocritical of me -
I'll have to remember to subscribe myself :)

>The list of bugs against dpkg grows almost daily

Hmmm, we're up to 388.

Critical: 1
Grave: 6
Important: 8
Normal: 256
Wishlist: 66
Fixed: 49
Normal done: 1
Fixed done: 1

It seems a few people are actually going through the bug list and closing
bugs that have been fixed or shouldn't be there. I've done that to a few
of the more superfluous dpkg bugs recently myself.

I encourage you to do the same. :)

>while the very few people who are blessed to touch the source code
>continue to be too buzzy to work on it.

>From what I've heard, Klee Dienes has dropped off the face of the earth,
and Ian Jackson has had to put dpkg aside this year to concentrate on
being leader. I think I remember him saying sometime that he plans to
start hacking on dpkg again after his replacement takes office.

So, the gist of that is that dpkg has been left for dead (well, NMU hell
anyway) for a full year and there hasn't been *that* many complaints.
Just no new features.

>Opening the development model for dpkg would be a great way to overcome
>this sad situation, but it seems that us, poor mortal Debian maintainers,
>are not considered good enough for taking care of the central and most
>important tool in our project.

What tangible changes are you suggesting?

Anyone can currently submit dpkg patches to the BTS, and if they want to
handle the flames, any developer can do a NMU of dpkg.

I think the problem is the lack of people that really *really* understand
the dpkg source, and there's no way for Ian to just "fix" that.
-- 
Robert Woodcock - [EMAIL PROTECTED]
"It's like a love-hate relationship, but without the love." -- jwz, on linux

Re: pseudo package for upgrades from hamm

[Martin Alonso Soto]

Robert Woodcock <[EMAIL PROTECTED]> writes:
> We need to add a new field - call it anything you want - I called it
> "Was-Part-Of:" in an earlier post, but I'm sure there's a better name than
> that - "Previously:" maybe.
> 
> Anyway, say slink contains a package 'foobar', version 1.2-3. The
> maintainer decides to split it into 'foo' and 'bar' for potato.
> 
> In the control files for the foo and bar packages, the maintainer slips in
> that aforementioned field:
> 
> Package: foo
> Version: 1.2-4
> Previously: foobar (<< 1.2-3)
> 
> ... and does the same thing for the bar package. dselect and apt check that
> field, check the current version of foobar, and based on that, automagically
> select the new packages.


Many, *many* people has proposed this idea before.  So many, that you
would be tempted to consider it a simple, natural, and straightforward
idea.  Nonetheless, it seems that this far, it has been impossible to
make it part of dpkg, or even to start working on the necessary
modifications for that purpose.

The list of bugs against dpkg grows almost daily, while the very few
people who are blessed to touch the source code continue to be too
buzzy to work on it.  Opening the development model for dpkg would be
a great way to overcome this sad situation, but it seems that us, poor
mortal Debian maintainers, are not considered good enough for taking
care of the central and most important tool in our project.


As a developer who have contributed to the project much less than I
would have wanted, but who appreciates it deeply, I would like to ask
the Debian leadership to seriously reconsider the dpkg development
model.  It is now clear that our lack of capacity as a project to
adequately manage the evolution of dpkg, is causing us serious
problems, and that if things continue to be like this, we will face
much more serious difficulties in the near future.

Hoping for the best,

M. S.

Martin A. Soto J.   Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes  [EMAIL PROTECTED]

Re: pseudo package for upgrades from hamm

[Robert Woodcock]

Adam Heath wrote:
>I see a problem with all this talk about pseudo packages for upgrades from
>hamm.
>
>These 'pkgs' will have to remain in the system forever.  If someone skips
>slink, and goes to potato when that is released, the same problem will occur.
>
>If we ever fix dpkg/dselect/apt to handle a pkg rename, and we can guarantee
>that an old dpkg/dselect/apt will install the new dpkg/dselect/apt, then we
>will be able to remove the pseudo names.  But currently, I don't see how this
>is possible.

[the following is all just talk - I don't feel comfortable hacking dpkg
source yet]

We need to add a new field - call it anything you want - I called it
"Was-Part-Of:" in an earlier post, but I'm sure there's a better name than
that - "Previously:" maybe.

Anyway, say slink contains a package 'foobar', version 1.2-3. The
maintainer decides to split it into 'foo' and 'bar' for potato.

In the control files for the foo and bar packages, the maintainer slips in
that aforementioned field:

Package: foo
Version: 1.2-4
Previously: foobar (<< 1.2-3)

... and does the same thing for the bar package. dselect and apt check that
field, check the current version of foobar, and based on that, automagically
select the new packages.

Chances are, someone has ripped off my idea ;> and submitted it as a
wishlist bug against dpkg already, so I'll look through the list later and
file a wishlist bug if there isn't one already there.

That is, if noone has any better ideas on how to handle this.

>ps: When is Jason Gunthorpe going to rewrite dpkg?  :)

You really want dpkg written in C++? :>
-- 
Robert Woodcock - [EMAIL PROTECTED]
"Unix and C are the ultimate computer viruses" -- Richard Gabriel

pseudo package for upgrades from hamm

[Adam Heath]

I see a problem with all this talk about pseudo packages for upgrades from
hamm.

These 'pkgs' will have to remain in the system forever.  If someone skips
slink, and goes to potato when that is released, the same problem will occur.

If we ever fix dpkg/dselect/apt to handle a pkg rename, and we can guarantee
that an old dpkg/dselect/apt will install the new dpkg/dselect/apt, then we
will be able to remove the pseudo names.  But currently, I don't see how this
is possible.

Adam

ps: When is Jason Gunthorpe going to rewrite dpkg?  :)

Re: netstd split -- pseudo package for upgrades from hamm

[Hamish Moffatt]

On Tue, Jan 19, 1999 at 11:44:14AM -0800, Ben Gertzfield wrote:
> Now if we could only convince the netstd maintainer to make a
> pseudo-package for all his splits.. but he has told me he refuses to
> support upgrades for anything but dselect. :/

That's disappointing.
Why will dselect handle it either?


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: netstd split -- pseudo package for upgrades from hamm

[Santiago Vila]

On 19 Jan 1999, Ben Gertzfield wrote:

> >>>>> "Brandon" == Brandon Mitchell <[EMAIL PROTECTED]> writes:
> 
> Santiago> I think it is absolutely essential for the success of
> Santiago> Debian 2.1 that nobody will automagically lose
> Santiago> functionality in the upgrade process.
> 
> Brandon> Done in experimental changes file: * xbase is now a
> Brandon> pseudo-package used to smooth upgrades from hamm or
> Brandon> earlier systems * what was the new xbase is now
> Brandon> xfree86-common
> 
> Branden has done a great job with the xbase upgrade pseudo-package.

No doubt, but until I see pseudopackages for the font packages, this great
job is still unfinished.

> Now if we could only convince the netstd maintainer to make a
> pseudo-package for all his splits.. but he has told me he refuses to
> support upgrades for anything but dselect. :/

I would consider an acceptable compromise that netstd had at least a
Recommends for *all* the packages that were previously included in it
that have been downgraded to Priority: optional (i.e. the ones that
dselect will not select automatically).

Is this the case?

[ If case it would not, people upgrading netstd would lose functionality
on the upgrade, and we would fail to our promise of smooth upgrades ].

-- 
 "4c6ce55911369b1900e8aef9afdb467c" (a truly random sig)

netstd split -- pseudo package for upgrades from hamm

[Ben Gertzfield]

>>>>> "Brandon" == Brandon Mitchell <[EMAIL PROTECTED]> writes:

Santiago> I think it is absolutely essential for the success of
Santiago> Debian 2.1 that nobody will automagically lose
Santiago> functionality in the upgrade process.

Brandon> Done in experimental changes file: * xbase is now a
Brandon> pseudo-package used to smooth upgrades from hamm or
Brandon> earlier systems * what was the new xbase is now
Brandon> xfree86-common

Branden has done a great job with the xbase upgrade pseudo-package.

Now if we could only convince the netstd maintainer to make a
pseudo-package for all his splits.. but he has told me he refuses to
support upgrades for anything but dselect. :/

-- 
Brought to you by the letters A and E and the number 10.
"Yasashisani tsutsumaretanara, kitto.. meni utsuru.."
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.

Re: XFree86 hamm -> slink upgrade 'dummy' package

[Santiago Vila]

On 15 Jan 1999, Ben Gertzfield wrote:

> > "Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
> 
> Ben> Simply use the 'xbase' package name as the dummy package,
> Ben> renaming what is currently 'xbase' in slink to xfree86-base.
> Ben> 
> Ben> Then, the xbase package will be an Optional package that will
> Ben> not have anything but a copyright in it which will Depend on
> Ben> all the packages xbase has been split up into.
> 
> Santiago> I have just noticed that this will only solve part of
> Santiago> the problem.
> 
> Santiago> In addition to this, additional (also empty and dummy)
> Santiago> packages should be created with the old names (xfntbase,
> Santiago> xfnt75, etc.) which depend on the new ones.
> 
> I believe this is not true.
> 
> If the new dummy xbase Depends: upon the renamed xfnt packages (which
> Provide:, Conflict:, and Replace: the old ones) then the old xfnt75 et
> cetera packages will be removed and replaced with the new ones.

Fine, but the new dummy xbase should not Depend on the renamed xfnt ones.
The upgrade should be done package-wise. If you had three of the old xfnt
packages installed, you should end up having three of the new fnt packages
installed, not all of them.

The only way I can think for this to happen is to have a dummy package for
each of the fnt packages.

If you know some other solution, please let me know.

Thanks.

-- 
 "d7a09dff8edeb7aa9761f9c4aa6db3d4" (a truly random sig)

Re: 1FA: problem still in hamm disks

[Avery Pennarun]

On Sat, Oct 17, 1998 at 09:49:54AM -0400, Michael Stone wrote:

> Quoting Tom Lees ([EMAIL PROTECTED]):
> > While I'm at it, *PLEASE* drop the dependency of lilo on mbr. I don't want
> > a new mbr eg if I want to install LILO to use on a floppy ONLY (I use
> > GRUB on my HD). Change it to Recommends. mbr being a high priority and/or
> > essential (can't remember if it is) should be enough.
> 
> Can someone explain what the point of mbr is? Why not just install lilo
> directly to the mbr? (I always go back and do this for security reasons
> anyway: I've disabled floppy boot in the bios, why do I want an mbr
> that re-enables it?)

Wow!  Maybe I'm an idiot, but I just _now_ (after literally years of
wondering) realized where that silly 1FA: message was coming from.  I had
thought it was some kind of weird debugging feature of some BIOSes!

1FA looks like a hexadecimal number.  I know MBR has to be small, but can we
at least put in some commas, eg. "1,F,A:" ?

Furthermore, I think it should be made abundantly clear, somewhere obvious,
that you have to set the active partition when you install Debian.  I've
always been a pure-LILO user, and LILO ignores the active setting.  Not
understanding mbr, I've always gone through on my Debian systems and changed
lilo to use /dev/hda instead of /dev/hda1, because otherwise my system
wouldn't boot automatically to Linux.  I know it's my own sheer
incompetence, but I would have appreciated a warning message about this
somewhere.

Have fun,

Avery

Re: 1FA: problem still in hamm disks

[Kai Henningsen]

[EMAIL PROTECTED] (Ben Gertzfield)  wrote on 16.10.98 in <[EMAIL PROTECTED]>:

> > "Brent" == Brent Fulgham <[EMAIL PROTECTED]> writes:
>
> Brent> I'd like to chime in -- It's a real annoyance that the base
> Brent> disks don't set up lilo to let you boot into multiple
> Brent> operating systems.  Couldn't it ask if you want to
> Brent> dual-boot with windows, or whatever, and generate an
> Brent> appropriate lilo.conf file?
>
> Sure. How about you write the script to do so?

What happened to the old lilo QuickInst or however it was named? I think I  
used that when installing my first (Slackware) Linux, and I believe saw it  
under /usr/doc/lilo not so long ago. ISTR it doing a decent job of  
implementing this - or maybe my memory is faulty?


MfG Kai

Re: 1FA: problem still in hamm disks

[Hamish Moffatt]

On Sat, Oct 17, 1998 at 09:49:54AM -0400, Michael Stone wrote:
> Quoting Tom Lees ([EMAIL PROTECTED]):
> > While I'm at it, *PLEASE* drop the dependency of lilo on mbr. I don't want
> > a new mbr eg if I want to install LILO to use on a floppy ONLY (I use
> > GRUB on my HD). Change it to Recommends. mbr being a high priority and/or
> > essential (can't remember if it is) should be enough.
> 
> Can someone explain what the point of mbr is? Why not just install lilo
> directly to the mbr? (I always go back and do this for security reasons
> anyway: I've disabled floppy boot in the bios, why do I want an mbr
> that re-enables it?)

Well, if you install Windows 95 after installing LILO in the mbr,
LILO is gone and you'll have to get out a floppy to boot Linux. If you put
LILO in the boot sector (superblock?) instead, you just have to change
the active partition again using Windows FDISK.


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: 1FA: problem still in hamm disks

[Michael Stone]

Quoting Tom Lees ([EMAIL PROTECTED]):
> While I'm at it, *PLEASE* drop the dependency of lilo on mbr. I don't want
> a new mbr eg if I want to install LILO to use on a floppy ONLY (I use
> GRUB on my HD). Change it to Recommends. mbr being a high priority and/or
> essential (can't remember if it is) should be enough.

Can someone explain what the point of mbr is? Why not just install lilo
directly to the mbr? (I always go back and do this for security reasons
anyway: I've disabled floppy boot in the bios, why do I want an mbr
that re-enables it?)

Mike Stone

Re: 1FA: problem still in hamm disks

[Tom Lees]

On Fri, Oct 16, 1998 at 12:34:09PM -0700, Ben Gertzfield wrote:
> > "Brent" == Brent Fulgham <[EMAIL PROTECTED]> writes:
> 
> Brent> I'd like to chime in -- It's a real annoyance that the base
> Brent> disks don't set up lilo to let you boot into multiple
> Brent> operating systems.  Couldn't it ask if you want to
> Brent> dual-boot with windows, or whatever, and generate an
> Brent> appropriate lilo.conf file?
> 
> Sure. How about you write the script to do so?

While I'm at it, *PLEASE* drop the dependency of lilo on mbr. I don't want
a new mbr eg if I want to install LILO to use on a floppy ONLY (I use
GRUB on my HD). Change it to Recommends. mbr being a high priority and/or
essential (can't remember if it is) should be enough.

> Brent> This is an area where RedHat has a significant lead over
> Brent> us.  One of the guys I work with is a huge RedHat fan
> Brent> because he can just pop a RH CD into the drive, windows
> Brent> will autorun it, and RedHat install starts.  It sets up
> Brent> almost everything for the user.
> 
> If RH has released this code under the GPL, then why don't we borrow
> it for our use? I know that it's as simple as having an 'autorun'
> directory on the CD image.

IIRC there is an "autorun.cfg" or similar too.

> Brent> I know we support far more configurations, etc. etc. etc.,
> Brent> but for the average Joe New-User this is a large hurdle.
> 
> I'm sure Enrique is always happy to accept code to do so. :)

Just out of interest, how does the autorun bit work? You can't just run
loadlin straight from Windoze.

-- 
Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>  http://www.lpsg.demon.co.uk/
PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.

Re: 1FA: problem still in hamm disks

[Ben Gertzfield]

> "Brent" == Brent Fulgham <[EMAIL PROTECTED]> writes:

Brent> I'd like to chime in -- It's a real annoyance that the base
Brent> disks don't set up lilo to let you boot into multiple
Brent> operating systems.  Couldn't it ask if you want to
Brent> dual-boot with windows, or whatever, and generate an
Brent> appropriate lilo.conf file?

Sure. How about you write the script to do so?

Brent> This is an area where RedHat has a significant lead over
Brent> us.  One of the guys I work with is a huge RedHat fan
Brent> because he can just pop a RH CD into the drive, windows
Brent> will autorun it, and RedHat install starts.  It sets up
Brent> almost everything for the user.

If RH has released this code under the GPL, then why don't we borrow
it for our use? I know that it's as simple as having an 'autorun'
directory on the CD image.

Brent> I know we support far more configurations, etc. etc. etc.,
Brent> but for the average Joe New-User this is a large hurdle.

I'm sure Enrique is always happy to accept code to do so. :)

Ben

-- 
Brought to you by the letters R and V and the number 12.
"Moshimoshi. Kikoemasu ka?" "Kakenaoshimasu kara ne! 1-do kitte kudasai."
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.

Re: 1FA: problem still in hamm disks

[Ben Gertzfield]

> "Enrique" == Enrique Zanardi <[EMAIL PROTECTED]> writes:

Enrique> Currently, that partition is marked as bootable just
Enrique> after installing LILO and "mbr" (first a dialog is
Enrique> displayed asking the user if he wants it so, something
Enrique> like "If you want the Debian system to boot automatically
Enrique> from the hard disk when you turn your system on, answer
Enrique> "yes" to the following question. If you have another
Enrique> operating system that you'd prefer to be the one that
Enrique> boots automatically, answer "no".").

Please, make this warning much, much stronger. If mbr is installed at
all, their system will become unusable if they do not say yes at this
point.

So, if the user does select 'yes' for installing "mbr", please tell
them that if they say "no" at this point, they will be rendering
their system pretty much unbootable (unless they can figure out
the cryptic MBR prompts.)

Either that, or tell the truth at this point:

"At this point, the Debian installer must mark one of your partitions
as 'bootable' so that the MBR tool you selected to install can know
which partition to boot by default."

Ben

-- 
Brought to you by the letters Y and M and the number 3.
"It's cold.. and there are wolves.." -- Grampa Simpson
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.

Re: 1FA: problem still in hamm disks

[Martin Schulze]

Brent Fulgham wrote:
> I'd like to chime in --
> 
> It's a real annoyance that the base disks don't set up lilo to let you
> boot into multiple operating systems.  Couldn't it ask if you want to
> dual-boot with windows, or whatever, and generate an appropriate lilo.conf
> file?

This would be nice.  Brent, could you checkout the boot disks and try to
implement it?

Regards,

Joey

-- 
The MS-DOS filesystem is nice for removable media.  -- H. Peter Anvin

Re: 1FA: problem still in hamm disks

[Brent Fulgham]

I'd like to chime in --

It's a real annoyance that the base disks don't set up lilo to let you
boot into multiple operating systems.  Couldn't it ask if you want to
dual-boot with windows, or whatever, and generate an appropriate lilo.conf
file?

This is an area where RedHat has a significant lead over us.  One of the
guys I work with is a huge RedHat fan because he can just pop a RH CD
into the drive, windows will autorun it, and RedHat install starts.  It sets
up
almost everything for the user.

I know we support far more configurations, etc. etc. etc., but for the
average
Joe New-User this is a large hurdle.

-Brent
-Original Message-
From: Ben Gertzfield <[EMAIL PROTECTED]>
To: Enrique Zanardi <[EMAIL PROTECTED]>
Cc: Duncan Thomson <[EMAIL PROTECTED]>;
debian-devel@lists.debian.org 
Date: Friday, October 16, 1998 10:31 AM
Subject: Re: 1FA: problem still in hamm disks


>Enrique Zanardi <[EMAIL PROTECTED]> writes:
>
>
>> On Fri, Oct 16, 1998 at 09:18:23AM +, Duncan Thomson wrote:
>> > i've seen postings about this before, but as yet no solution (either as
>> > a message or in the boot disks).
>> >
>> > when debian is made bootable from the hard disk on certain systems, the
>> > prompt 1FA: comes up, but the system will not boot off partition 1.
>> > the disk controller is AHA-2940.  any solutions to this problem?
>>
>> Where does it stops? Does it shows the typical "LI" message?
>
>Enrique, the problem is that our special "mbr" tool *REQUIRES* that
>one of the partitions on your drive be marked "Bootable" under cfdisk
>or fdisk.
>
>However, the current boot-floppies do not require this; in fact, they
>don't even check if any partitions are marked Bootable or not.
>
>I suggest you add a test (I'm not sure how you would do it) to see if
>the partition LILO is to go on is marked bootable by cfdisk before you
>let the user leave the partitioning step.
>
>Ben
>
>--
>Brought to you by the letters Y and P and the number 1.
>"Nerd. Loser. Jerk. Moron. Worm. Scum. Idiot. Fool." -- Pkunk, SCII
>Debian GNU/Linux -- where do you want to go tomorrow?
http://www.debian.org/
>I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
>
>
>--
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

Re: 1FA: problem still in hamm disks

[Enrique Zanardi]

On Fri, Oct 16, 1998 at 10:11:05AM -0700, Ben Gertzfield wrote:
> Enrique Zanardi <[EMAIL PROTECTED]> writes:
> 
> 
> > On Fri, Oct 16, 1998 at 09:18:23AM +, Duncan Thomson wrote:
> > > i've seen postings about this before, but as yet no solution (either as
> > > a message or in the boot disks).
> > > 
> > > when debian is made bootable from the hard disk on certain systems, the
> > > prompt 1FA: comes up, but the system will not boot off partition 1.
> > > the disk controller is AHA-2940.  any solutions to this problem?
> > 
> > Where does it stops? Does it shows the typical "LI" message?
> 
> Enrique, the problem is that our special "mbr" tool *REQUIRES* that
> one of the partitions on your drive be marked "Bootable" under cfdisk
> or fdisk.
> 
> However, the current boot-floppies do not require this; in fact, they
> don't even check if any partitions are marked Bootable or not.
> 
> I suggest you add a test (I'm not sure how you would do it) to see if
> the partition LILO is to go on is marked bootable by cfdisk before you
> let the user leave the partitioning step.

Currently, that partition is marked as bootable just after installing
LILO and "mbr" (first a dialog is displayed asking the user if he wants
it so, something like "If you want the Debian system to boot
automatically from the hard disk when you turn your system on, answer
"yes" to the following question. If you have another operating system
that you'd prefer to be the one that boots automatically, answer "no".").

--
Enrique Zanardi[EMAIL PROTECTED]

Re: 1FA: problem still in hamm disks

[Ben Gertzfield]

Enrique Zanardi <[EMAIL PROTECTED]> writes:


> On Fri, Oct 16, 1998 at 09:18:23AM +, Duncan Thomson wrote:
> > i've seen postings about this before, but as yet no solution (either as
> > a message or in the boot disks).
> > 
> > when debian is made bootable from the hard disk on certain systems, the
> > prompt 1FA: comes up, but the system will not boot off partition 1.
> > the disk controller is AHA-2940.  any solutions to this problem?
> 
> Where does it stops? Does it shows the typical "LI" message?

Enrique, the problem is that our special "mbr" tool *REQUIRES* that
one of the partitions on your drive be marked "Bootable" under cfdisk
or fdisk.

However, the current boot-floppies do not require this; in fact, they
don't even check if any partitions are marked Bootable or not.

I suggest you add a test (I'm not sure how you would do it) to see if
the partition LILO is to go on is marked bootable by cfdisk before you
let the user leave the partitioning step.

Ben

-- 
Brought to you by the letters Y and P and the number 1.
"Nerd. Loser. Jerk. Moron. Worm. Scum. Idiot. Fool." -- Pkunk, SCII
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.

Re: 1FA: problem still in hamm disks

[Enrique Zanardi]

On Fri, Oct 16, 1998 at 09:18:23AM +, Duncan Thomson wrote:
> i've seen postings about this before, but as yet no solution (either as
> a message or in the boot disks).
> 
> when debian is made bootable from the hard disk on certain systems, the
> prompt 1FA: comes up, but the system will not boot off partition 1.
> the disk controller is AHA-2940.  any solutions to this problem?

Where does it stops? Does it shows the typical "LI" message?

--
Enrique Zanardi[EMAIL PROTECTED]

1FA: problem still in hamm disks

[Duncan Thomson]

i've seen postings about this before, but as yet no solution (either as a 
message or in the boot disks).

when debian is made bootable from the hard disk on certain systems, the prompt 
1FA: comes up, but the system will not boot off partition 1.  the disk 
controller is AHA-2940.  any solutions to this problem?

 -duncan   

e2fsprogs 1.12 into hamm ? (Was: Bug#27401: fsck.ext2 segfaults)

[Yann Dirson]

I originally meant this mail to deb-dev to get feedback about this
issue, but it seems I did not.

Winfried Truemper writes:
 > Package: e2fsprogs
 > Version: 1.10-17
 > 
 > 
 > The version of fsck.ext2 segfaults in criticial cases (complete garbage on
 > the harddisk, left from a previous crash). It's a showstopper for the
 > whole system (if you care about your data). Please upgrade to 
 > 
 > tsx-11.mit.edu:/pub/linux/packages/ext2fs/e2fsprogs-1.12.tar.gz

1.12 is already available for some time in `unstable'.  1.12 seems to
have proven to be stable enough.  Maybe it can be pushed into updates
to the stable tree now.

Any objection ?

-- 
Yann Dirson | Stop making M$-Bill richer & richer,
   <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check 

Re: Hamm Bug Stamp-Out List for June 25, 1998

[Dale Scheetz]

On 26 Jun 1998, Manoj Srivastava wrote:

> Hi,
> >>"Bdale" == Bdale Garbee <[EMAIL PROTECTED]> writes:
> 
> 
>  Bdale> If you're working in a multi-machine networked environment,
>  Bdale> and are accessing another system using NFS (particularly with
>  Bdale> an automounted host map), an absolute link can easily violate
>  Bdale> "the principle of least astonishment"...  if you are tracking
>  Bdale> down a remote machine's filesystems, and cross an absolute
>  Bdale> symbolic link, you're back on your local system's filesystem!
>  Bdale> That's almost never what you meant, or what you wanted.
> 
>   On the other hand, if you are using automount, or AFS, or DFS,
>  or even, in some environments, NFS, you may keep all mounts
>  under, say, /mnt (eg /usr -> /mnt/i386/usr), in which case, any
>  relative links between top level directories loose. 
> 
>   In this case, a relative symlink also violates the princple of
>  least astonishment, and indeed, does not even work.
> 
>   I think, on balance, the policy works for the most common
>  case. 
> 
>   manoj
> 

Thanks for quoting Policy on this. Upon reading the "actual" text, I don't
think this policy applies to libc6-dev.

> 
> 3.3.5. Symbolic links
> -
> 
>  In general, symbolic links within a toplevel directory should be
>  relative, and symbolic links pointing from one toplevel directory into
>  another should be absolute. (A toplevel directory is a sub-directory
>  of the root directory `/'.)

Note: "from one toplevel directory into another"

The links are from /usr/lib, which is a subdirectory of a top level
directory. Yes, it points to a top level directory, but that only satifies
one half of the above criterion.
 
> 
>  In addition, symbolic links should be specified as short as possible,
>  i.e., link targets like `foo/../bar' are depreciated.

I guess I'm just stupid ;-) but I don't understand what the example is
trying to tell me.

Waiting is, 

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[Andreas Jellinghaus]

>The upstream maintainer (Ulrich D.) insists that the relative links are
>correct and that making /usr a symlink to something else is "evil".

but in some situations they are necessary : when useing nfsroot
with special setup. for improved speed i want a codafs as the basic layer,
so /usr -> /coda/usr, /opt->/coda/opt, ...

but anyone doing such stuff should be able to fix symlinks himself, so this
isn't a big problem.

andreas


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[Manoj Srivastava]

Hi,
>>"Bdale" == Bdale Garbee <[EMAIL PROTECTED]> writes:


 Bdale> If you're working in a multi-machine networked environment,
 Bdale> and are accessing another system using NFS (particularly with
 Bdale> an automounted host map), an absolute link can easily violate
 Bdale> "the principle of least astonishment"...  if you are tracking
 Bdale> down a remote machine's filesystems, and cross an absolute
 Bdale> symbolic link, you're back on your local system's filesystem!
 Bdale> That's almost never what you meant, or what you wanted.

On the other hand, if you are using automount, or AFS, or DFS,
 or even, in some environments, NFS, you may keep all mounts
 under, say, /mnt (eg /usr -> /mnt/i386/usr), in which case, any
 relative links between top level directories loose. 

In this case, a relative symlink also violates the princple of
 least astonishment, and indeed, does not even work.

I think, on balance, the policy works for the most common
 case. 

manoj


3.3.5. Symbolic links
-

 In general, symbolic links within a toplevel directory should be
 relative, and symbolic links pointing from one toplevel directory into
 another should be absolute. (A toplevel directory is a sub-directory
 of the root directory `/'.)

 In addition, symbolic links should be specified as short as possible,
 i.e., link targets like `foo/../bar' are depreciated.

-- 
 "One machine can do the work of fifty ordinary men. No machine can do
 the work of one extraordinary man." Elbert Hubbard ...yet. Karl
 Lehenbauer
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

:>   21884  libc6-dev: relative links between top-level dirs

: The upstream maintainer (Ulrich D.) insists that the relative links are
: correct and that making /usr a symlink to something else is "evil".

I'm not sure I completely understand what the links in libc6-dev look like,
and I don't have time to go look right now.  A few quick words about why
relative links are important in some circumstances seems in order, though.

If you're working in a multi-machine networked environment, and are accessing
another system using NFS (particularly with an automounted host map), an
absolute link can easily violate "the principle of least astonishment"...  if
you are tracking down a remote machine's filesystems, and cross an absolute
symbolic link, you're back on your local system's filesystem!  That's almost
never what you meant, or what you wanted.

For this and related reasons, we have an almost absolute prohibition against
absolute symlinks in my shop, except in cases where it really doesn't matter.
For example, we have lots of symlinks that actually point off to subtrees on
a mount from a central NFS server... since these all point to the same
actual filesystem regardless of which machine you're on, it's ok for them to
be absolute.

In summary, while I don't know the details in this particular case, relative
links are more often a good thing than a bad thing...

Bdale


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

Re: Bug #23877: Include autoup.sh and apt in hamm/hamm

[Craig Sanders]

On 25 Jun 1998, Ben Gertzfield wrote:

> >> Subject: please include apt and autoup in
> >> hamm/hamm/upgrade-i386/ To: [EMAIL PROTECTED] -- Package:
> >> ftp.debian.org,apt,autoup Version: N/A
> 
> Well, let's just do it! I see no problem with making such a directory
> for final hamm.

imo this directory should also be populated with symlinks to all the
packages which autoup.sh needs to do the upgrade.

there should also be a copy of the the bo libc5 dpkg in there, to assist
with upgrades from rex/buzz.

craig

--
craig sanders


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[Mark W. Eichin]

Yeah, there's been enough discussion in this context.  The decision to
ditch the "emacs" name as a package name was in fact made for good
reasons, a while back; just-before-the-release is the wrong time to
revisit it. As emacs and emacs19 maintainer, I'm closing it, with this
message.  Feel free to discuss further on debian-devel, but I'd
recommend either dropping it or taking it to the technical committee.


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

Re: Bug #23877: Include autoup.sh and apt in hamm/hamm

[Ben Gertzfield]

>>>>> "Jens" == Jens Ritter <[EMAIL PROTECTED]> writes:

Jens> Andreas <[EMAIL PROTECTED]> filed this against
Jens> ftp.debian.org:

>> Subject: please include apt and autoup in
>> hamm/hamm/upgrade-i386/ To: [EMAIL PROTECTED] -- Package:
>> ftp.debian.org,apt,autoup Version: N/A
>> 
>> i think this is the right location. if people want to get all
>> files they need to install or burn a cdrom, they should have
>> one source, and not collect the files from several servers
>> (which might be down or unreachable or ...).
>> 
>> this bug should be either "wishlist" and ignored or marked
>> grave IMO.
>> 
>> andreas

Jens> I think this needs a thorough discussion here, too, that´s
Jens> why I forward it here.

Well, let's just do it! I see no problem with making such a directory
for final hamm.

Ben

-- 
Brought to you by the letters J and O and the number 6.
"We are the music makers. And we are the dreamers of dreams." -- Willy Wonka
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[G John Lapeyre]

On Thu, 25 Jun 1998, Dale Scheetz wrote:
> The upstream maintainer (Ulrich D.) insists that the relative links are
> correct and that making /usr a symlink to something else is "evil".

I'm running out of space and wanted to move subdirs of /usr to
another partition.  But because of relative links pointing back up to '/',
this is impossible.  I hope there is a good reason for using relative
links, because as it is , /usr must be on the same partition as '/' , or
else consist of an entire partition.

John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre


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

Re: About the Hamm Freeze (!)

[Stephen Zander]

> "Darren" == Darren/Torin/Who Ever <[EMAIL PROTECTED]> writes:
Darren> Hmm.  You're right.  Any ideas on when this changed or was
Darren> I just on too much sleep-dep when I last looked at this.
Darren> (a while back)

Been that way for quite a while AFAIK.  Till very recently, though,
dbmopen was hard-coded to GDBM_File or NDBM_File (can't remember
which).

-- 
Stephen
---
all coders are created equal; that they are endowed with certain
unalienable rights, of these are beer, net connectivity, and the
pursuit of bugfixes...  - Gregory R Block


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

Bug #23877: Include autoup.sh and apt in hamm/hamm

[Jens Ritter]

Andreas <[EMAIL PROTECTED]> filed this against ftp.debian.org:

>Subject: please include apt and autoup in hamm/hamm/upgrade-i386/
>To: [EMAIL PROTECTED]
>-- Package: ftp.debian.org,apt,autoup
>Version: N/A
>
>i think this is the right location. if people want to get all files they need
>to install or burn a cdrom, they should have one source, and not collect the
>files from several servers (which might be down or unreachable or ...).
>
>this bug should be either "wishlist" and ignored or marked grave IMO.
>
>andreas

I think this needs a thorough discussion here, too, that´s why I
forward it here.

Jens 

---
[EMAIL PROTECTED]   [EMAIL PROTECTED]
Key ID: 2048/E451C639 Jens Ritter
Key fingerprint: 5F 3D 43 1E 24 1E CC 48  1E 05 93 3A A7 10 73 37 

Nothing works better as it is supposed to. (Steven Chu)


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[Rob Browning]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

>   Why is this a release critical bug? emacs19 depends on a whole
>  slew of packages, and it quite differently set up than the old emacs
>  package. Also, there are now a number of packages that vie for the
>  name Emacs, is not unreasonable to have the package renamed.

Yep, Debian no longer has a "one true emacs" :> I think this "bug"
should be closed.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[Manoj Srivastava]

Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:

 Wichert> Package: emacs19  
 Wichert> Maintainer: [EMAIL PROTECTED] (Mark W. Eichin)  
 Wichert>   23742  emacs19 should probably be just "emacs"


Why is this a release critical bug? emacs19 depends on a whole
 slew of packages, and it quite differently set up than the old emacs
 package. Also, there are now a number of packages that vie for the
 name Emacs, is not unreasonable to have the package renamed.

I can understand that the originator may ``wish'' to have the
 old name retained, but is this an important enough objection to hold
 up Hamm or throw emacs19 out? I think no.

Olease downgrade this bug (I would say to a wishlist), and get
 it out of the release critical list.

manoj
-- 
 "Imagination is more important than knowledge." Albert Einstein On
 Knowledge
Manoj Srivastava  <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[David Engel]

On Thu, Jun 25, 1998 at 11:30:45AM -0400, Dale Scheetz wrote:
> On Thu, 25 Jun 1998, Wichert Akkerman wrote:
> > Welcome to the nem Hamm Bugs Stamp-Out List.
> > 
> >   21884  libc6-dev: relative links between top-level dirs
> > 
> I'm not sure what to do abou this one.
> 
> The upstream maintainer (Ulrich D.) insists that the relative links are
> correct and that making /usr a symlink to something else is "evil".

You should ask him why he uses an absolute path to /lib/libc.so.6 in
the /usr/lib/libc.so linker script then.

> Rebuilding the links is at the edge of my shell script skills, and
> certainly outside any time frame I have available at the moment.
> 
> I feel the need for some discussion on the technical consequences of
> changing these links, as well as the consequences of not changing them.

Here is little bash snippet to be added very late in the 'debian/rules
binary' stage that does the job.  It is a liitle specific to the glibc
2.0.7 release, but that shouldn't be a big problem at this time.

v=2.0.7
pv=0.7
cd debian/tmp/usr/lib
for f in *.so ; do
if [ $f != libc.so -a $f != libndbm.so ]; then
rm $f
if [ $f != libpthread.so ]; then
ln -s /lib/$(basename $f .so)-$v.so $f
else
ln -s /lib/$(basename $f .so)-$pv.so $f
fi
fi
done

Dale you should note that this also makes another important change
that should have been noticed by me a long time ago.  It changes the
symlink to point to the actual shared library file instead of the
soname symlink.  For example, this would make /usr/lib/libm.so point
to /lib/libm-2.0.7.so instead of /lib/libm.so.6.  This change makes it
harder for a user to screw up his compilation environment by simply
installing a newer shared library file and running ldconfig manually.

David
-- 
David EngelODS Networks
[EMAIL PROTECTED]   1001 E. Arapaho Road
(972) 234-6400 Richardson, TX  75081


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[David Engel]

On Thu, Jun 25, 1998 at 09:45:43AM -0500, Wichert Akkerman wrote:
> Package: kdebase  (i386 contrib)
> Maintainer: Stephan Kulow <[EMAIL PROTECTED]>   
>   23655  kdebase includes /etc/X11/Xsession

Stephen is probably busy trying to get KDE 1.0 done, so I doubt he has
any plans to work on this.

My suggestion is to either copy the beta4 kde packages from slink
(which includes the fix for this bug) into hamm or drop kde from hamm
altogether.  I prefer the former.  

FWIW, I think the only reason, the beta4 packages weren't put in hamm
in the first place is because Stephen didn't take the time to rebuild
and re-upload them with the proper 'frozen" tag.

David
-- 
David EngelODS Networks
[EMAIL PROTECTED]   1001 E. Arapaho Road
(972) 234-6400 Richardson, TX  75081


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

Re: Hamm Bug Stamp-Out List for June 25, 1998

[Dale Scheetz]

On Thu, 25 Jun 1998, Wichert Akkerman wrote:

> Welcome to the nem Hamm Bugs Stamp-Out List.
> 
>   21884  libc6-dev: relative links between top-level dirs
> 
I'm not sure what to do abou this one.

The upstream maintainer (Ulrich D.) insists that the relative links are
correct and that making /usr a symlink to something else is "evil".

Rebuilding the links is at the edge of my shell script skills, and
certainly outside any time frame I have available at the moment.

I feel the need for some discussion on the technical consequences of
changing these links, as well as the consequences of not changing them.

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: About the Hamm Freeze (!)

[Darren/Torin/Who Ever...]

-BEGIN PGP SIGNED MESSAGE-

Stephen Zander, in an immanent manifestation of deity, wrote:
>Not true Darren: dbmopen does the moral equivalent of the tie under
>the covers.  It's one of my pet peeves that perl links in libraries to
>the main executable that are only required by extensions.

Hmm.  You're right.  Any ideas on when this changed or was I just on too 
much sleep-dep when I last looked at this.  (a while back)

Darren
- -- 
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire.  C/Perl/CGI programmer and tutor. @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNZHNDI4wrq++1Ls5AQGSegP/R/dhVQ32p7WQ11f4vNkNasKhF/Qn3kvz
n6wwl4AJuGYgoRB77VvspgXORoMjtOda0Zr+N3bK0WGO3yIZyS2sMOilmhLuF4rF
J+ztgem+35weBBME/Kd3AMHXzH/5Re/SmI9VfNj/LPoFFiFgPq+OhUPn2C1IKoag
1J0wjwk++e4=
=4IkJ
-END PGP SIGNATURE-


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

Re: About the Hamm Freeze (!)

[Stephen Zander]

Sorry for a late response, been on holidays...

>>>>> "Darren" == Darren/Torin/Who Ever <[EMAIL PROTECTED]> writes:
Darren> This is the case if you use the tie interface in Perl.
Darren> This is not the case if you use dbmopen, at least it
Darren> didn't use to be.  Hamm should just get out the door and
Darren> we'll deal with it in slink.

Not true Darren: dbmopen does the moral equivalent of the tie under
the covers.  It's one of my pet peeves that perl links in libraries to
the main executable that are only required by extensions.

-- 
Stephen
---
all coders are created equal; that they are endowed with certain
unalienable rights, of these are beer, net connectivity, and the
pursuit of bugfixes...  - Gregory R Block


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

Re: Upgrade report from "bo" to "hamm" :-(

[Dirk Eddelbuettel]

[ For the record, I agree with Paul's main points, most of which have long
  been know. This one point bears correction. ]

  Enrique> You won't have wait for hours while a list of "Skipping
  Enrique> foo. Skipping bar." is displayed at the screen.

1. That hasn't been necessary since dpkg-mountable was released around
   February of 1997, ie over 15 months ago.

2. My current favourite for installing just a package foo [1]
$ apg-get install foo

Finally, even if it took 5 hours: I now have the 'pleasure' of spending most
of my time (at work) with an NT4 box. How long do you think will it take to
reconfigure that once I upgrade the OS? If it survives at all. We *are* doing
quite well, actually. There's always room for improvement, of course.


Dirk

[1] My only minor gripe with apt is that it doesn't log as dpkg-mountable.

-- 
mailto:[EMAIL PROTECTED]  According to the latest official figures, 
http://rosebud.ml.org/~edd  43% of all statistics are totally worthless.


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

Re: Upgrade report from "bo" to "hamm" :-(

[Dan Jacobowitz]

On Tue, Jun 23, 1998 at 08:09:51PM +0200, Paul Seelig wrote:
> Actually the true killer was the upgrade of the teTeX packages.  It is
> pretty hard to stand seeing three time in a row "Running initex [...]
> This will take some time" on a 486DX-2/66 at the configuration stage.
> This alone consumed almost half an hour IIRC.
> 
> Would "apt" have made a difference with this?  Like installing and
> configuring all teTeX packages in a row and running "initex"
> afterwards just once?  Or is this simply impossible?

Which reminds me - the same method that we come up with to fix this, if
it can be fixed, might be usable for iamerican/ibritish.  What we need
is something along the line of what update-menus does but interactive. 
Perhaps DPKG:TNG wil include some way of registering a script to run at
the end of the configuration?  Any interactive but non-vital
configurations could then happen at the very end, easing one point.  It
would probably allow one running of inittex and one selection of ispell
dictionaries.

Ideas?

Dan


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

Re: Hamm Beta: Delay #1

[Rob Browning]

Brian White <[EMAIL PROTECTED]> writes:

> Just to be sure I understand...  emacs20 has to be configured before
> cvs-pcl is _installed_ or before cvs-pcl is _configured_?

Actually, now it seems like the problem in this case is that cvs-pcl
currently has a dependency on emacsen-common rather than emacsen.
This means that it's possible to have cvs-pcl installed with
emacsen-common, but without *any* flavor of emacs.  This is not
something I had anticipated when developing the emacs add-on code, so
I'm not surprised it breaks things.

While I don't know exactly what's causing the problem, it seems that
installing cvs-pcl along with (or after) a flavor of emacs works fine.
Given that, changing cvs-pcl's dependency from emacsen-common to
emacsen should fix the problem.  Accordingly I've filed important bugs
against the three packages that had this problem.

> Since you're unfamiliar with pkg-order, it sounds like starting to use
> it could be a source of other problems.  I'd rather avoid that.

Actually, Manoj pointed out that I should probably just use tsort,
though I haven't figured out yet whether you can actually call dpkg
--status or use the perl dpkg modules from within a postinst
(i.e. recursive dpkg entry).

Anyway, I think that the dependency changes will fix our current
problem, and given that, I think that the dependency code should wait
for slink.  I would like to upload a new version of emacsen common for
frozen that makes the add-on package dependency issue explicit.

Thanks

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


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

Re: Hamm Beta: Delay #1

[Brian White]

> Thanks.  From looking at your log, as I expected, the problem occurs
> when you try to install emacs20 and cvs-pcl simultaneously.  This is
> because elib is not being properly "configured" (by the emacsen-common
> script) before cvs-pcl.  This is a bug, but I'm worried about having
> time to fix it before the hamm release.

Just to be sure I understand...  emacs20 has to be configured before
cvs-pcl is _installed_ or before cvs-pcl is _configured_?


> I do know what needs to be done (emacsen-common needs to depend on
> pkg-order and needs to use it to determine the install/remove script
> order).
> 
> Brian, what's your take on this?  It could conceivably affect a number
> of emacsen installs depending on the particular combination of emacsen
> add-on packages selected.  I was of the opinion that this could wait
> for slink, but now that I can see more clearly that this could break a
> *bunch* of installs/upgrades (depending on what the user selects) I'm
> not so sure...

Since you're unfamiliar with pkg-order, it sounds like starting to use
it could be a source of other problems.  I'd rather avoid that.

What is the fix if it breaks?  Can somebody just do

dpkg --configure emacs20 cvs-pcl

once the rest of the install is finished?

  Brian
 ( [EMAIL PROTECTED] )

---
   Only half the people in the world are above average intelligence.



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

Re: Hamm Bug Stamp-Out List for June 22, 1998

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Hi.

Guy Maor said to me a few days ago that he will fix all non-wishlist bugs 
against ftp.debian.org before release.

However, normal bugs against ftp.debian.org are not in the list of
"important or higher" bugs.

So please include all ftp.debian.org normal bugs in the list, or better,
scan the bug list for ftp.debian.org for bugs about hamm and raise
them to "important".

I'm Cc:ing debian-devel and Guy Maor.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNY961yqK7IlOjMLFAQG28AP+MQWiDTNbesUCcCBMJlBh2qGNuPkhDswF
bSVeIsWKPrs/uyW//RUwP89+r6MdQErLypE0YwubjAO5w95JcN9NoCUOkoGZDUJb
RJQwnbJrDDqYdG8JDh3caQvyE5ak3dfN4Dy9rJhdK7oUt66OPcWMxFvHue661aUn
gkotzefwQIo=
=hDPL
-END PGP SIGNATURE-


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

Re: Upgrade report from "bo" to "hamm" :-(

[Enrique Zanardi]

On Tue, Jun 23, 1998 at 05:07:37AM +0200, Paul Seelig wrote:
[...]
> The initial update to libc6 via the autoup.sh went very smooth and
> flawlessly.  I fetched the .deb packages via FTP over a decent
> bandwith and this went pretty fast.  The bad thing afterwards was the
> painfully slo o o o o w w w w unpacking and installation process with
> "dpkg" especially on the slower machine, but believe me, this was no
> fun either on the K6 machine.
> 
> The final killer was the configuration process at the end which asked
> questions i wouldn't really want to bother answering and where i
> mostly simply accepted the default by constantly pressing enter.
> Can't this be automated and the questioning be minimized to a more
> acceptable degree?  I would like to see an upgrade mechanism which
> would allow me to start it and go home, checking all configuration
> issues the next morning.  I see no problem in packages dictating the
> sysadmin a certain default, possibly coming along with a nice script
> for later customization and fine tuning.
[...]

There are a few problems with our current package-installation process:

1) dpkg takes a lot of time to start.
2) dpkg takes a lot of time recursing down the directory tree to install
a few packages only.
3) there's no way to do unattended installations.

but luckily, there are a few answers too:

1) dpkg uses plain text databases. It takes a lot of time to parse them
to build its internal tables. IIRC, "dpkg-next-generation" (the one that
is being actively developed, and probably will be in slink RSN) doesn't
use the text databases directly, it uses hash tables to speed the
process.

2) dselect methods are the ones that call dpkg with the "recursive"
option. If you use one of the "new" methods (dpkg-mountable, apt, ...)
you will find they don't do "recursive" installs anymore. You won't have
wait for hours while a list of "Skipping foo. Skipping bar." is displayed
at the screen.

3) Now that is a big problem. And one that has been discussed frequently.
I can't remember what was the final decision (if any) that came out of
the last thread, but you may find it at debian-dpkg or debian-admintool
maillists archives.

Thanks,
--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: Hamm Beta: Delay #1

[Rob Browning]

Roberto Lumbreras <[EMAIL PROTECTED]> writes:

> Here you have the log.

Thanks.  From looking at your log, as I expected, the problem occurs
when you try to install emacs20 and cvs-pcl simultaneously.  This is
because elib is not being properly "configured" (by the emacsen-common
script) before cvs-pcl.  This is a bug, but I'm worried about having
time to fix it before the hamm release.

I do know what needs to be done (emacsen-common needs to depend on
pkg-order and needs to use it to determine the install/remove script
order).

Brian, what's your take on this?  It could conceivably affect a number
of emacsen installs depending on the particular combination of emacsen
add-on packages selected.  I was of the opinion that this could wait
for slink, but now that I can see more clearly that this could break a
*bunch* of installs/upgrades (depending on what the user selects) I'm
not so sure...

I'm beginning to think that I need to fix this *now*.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


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

Re: FIX FOR HAMM: timezone problem

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
John Goerzen <[EMAIL PROTECTED]> wrote:
>My clock is supposedly set to UTC.  When I originally installed, it
>wasn't, and there was no documentation for changing it, but I figured
>that I needed to add a -u to the appropriate init script.  Here then
>is /etc/init.d/hwclock.sh:

You can set it in /etc/default/rcS, just as all the other variables
for the init startup scripts ..

But that doesn't work with file-rc.

I'm uploading a sysvinit_2.75-3 tomorrow morning to solve the file-rc
problems. Which are release-critical, btw.

Mike.
-- 
 Miquel van Smoorenburg | Our vision is to speed up time,
[EMAIL PROTECTED]  |   eventually eliminating it.


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

Re: FIX FOR HAMM: timezone problem

[John Goerzen]

Nathan E Norman <[EMAIL PROTECTED]> writes:

> : It didn't work here.  I use xntp3 to sync my clock, and it would
> : always get set to Eastern time until I changed to CST6CDT.  After
> : making that change, it now gives results like yours.
> 
> Ok, fair enough.  I'm assuming you have the same program versions
> installed as I do?  Do you have your hardware clock set to UTC or local
> time?  (Someone said this is a red herring, but I'd like to know that
> for certain).
> 

My clock is supposedly set to UTC.  When I originally installed, it
wasn't, and there was no documentation for changing it, but I figured
that I needed to add a -u to the appropriate init script.  Here then
is /etc/init.d/hwclock.sh:

GMT=-u
#
#   Set and adjust the CMOS clock.
#
if [ ! -f /etc/adjtime ]
then
echo "0.0 0 0.0" > /etc/adjtime
fi
if [ -x /sbin/hwclock ]
then
[ "$GMT" = "-u" ] && GMT="--utc"
hwclock --adjust $GMT
hwclock --hctosys $GMT
else
[ "$GMT" = "--utc" ] && GMT="-u"
clock -a $GMT
fi

#
#   Now that /usr/lib/zoneinfo should be available,
#   announce the local time.
#
if [ "$VERBOSE" != no ]
then
echo
echo "Local time: `date`"
echo
fi

> Mine is set to UTC.
> 
> --
> Nathan Norman
> MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD  57104

Cool; my uncle lives just outside Sioux Falls and works there.  He
also is a volunteer chairman for the Minn-Kota sale in the Arena
each year, if you've ever been to it.

-- 
John Goerzen   Linux, Unix consulting & programming   [EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   www.debian.org |
+
Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org


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

Re: FIX FOR HAMM: timezone problem

[John Goerzen]

Dale Scheetz <[EMAIL PROTECTED]> writes:

> This is very strange, as US/Central and CST6CDT are both links to
> Americal/Chicago in the 2.0.7 version that I am building for release
> today.
> 
> The 2.0.7pre3 (which I have currently installed) seems to have these
> as separate files.
> 
> Which version was the report logged against?

My timezones now says 2.0.7pre3-1.  However, the original report could 
very well have been with a previous version -- I don't watch the
upgrades on these things terribly closely.

> 
> > Ok, fair enough.  I'm assuming you have the same program versions
> > installed as I do?  Do you have your hardware clock set to UTC or local
> > time?  (Someone said this is a red herring, but I'd like to know that
> > for certain).
> 
> The important thing is, if the hardware clock is set to UTC, then the init
> script should set the GMT variable to "-u" (Possibly "--utc"?). If the
> hardware clock is set to Local Time, then GMT should be set to "".
> 
> With these two issues properly sync'd things should work properly.
> 
> Luck,
> 
> Dwarf
> --
> _-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-
> 
> aka   Dale Scheetz   Phone:   1 (850) 656-9769
>   Flexible Software  11000 McCrackin Road
>   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308
> 
> _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
> 

-- 
John Goerzen   Linux, Unix consulting & programming   [EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   www.debian.org |
+
Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org


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

Re: FIX FOR HAMM: timezone problem

[Bob Nielsen]

On Sat, 20 Jun 1998, Dale Scheetz wrote:
> > 
> Where did you get a pre4? I don't think I released one...

Oops, I meant pre1-4.  Sorry about that.

Bob


Bob Nielsen Internet: [EMAIL PROTECTED]
Tucson, AZ  AMPRnet:  [EMAIL PROTECTED]
DM42nh  http://www.primenet.com/~nielsen


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

Re: FIX FOR HAMM: timezone problem

[Dale Scheetz]

On Sat, 20 Jun 1998, Bob Nielsen wrote:

> On Sat, 20 Jun 1998, Dale Scheetz wrote:
> 
> > This is very strange, as US/Central and CST6CDT are both links to
> > Americal/Chicago in the 2.0.7 version that I am building for release
> > today.
> > 
> > The 2.0.7pre3 (which I have currently installed) seems to have these
> > as separate files.
> 
> Likewise 2.0.7pre4, however diff shows they are identical.  I'm not sure
> how well diff works with binaries however.  The files have identical
> sizes.
> 
Where did you get a pre4? I don't think I released one...

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: FIX FOR HAMM: timezone problem

[Bob Nielsen]

On Sat, 20 Jun 1998, Dale Scheetz wrote:

> This is very strange, as US/Central and CST6CDT are both links to
> Americal/Chicago in the 2.0.7 version that I am building for release
> today.
> 
> The 2.0.7pre3 (which I have currently installed) seems to have these
> as separate files.

Likewise 2.0.7pre4, however diff shows they are identical.  I'm not sure
how well diff works with binaries however.  The files have identical
sizes.

Bob


Bob Nielsen Internet: [EMAIL PROTECTED]
Tucson, AZ  AMPRnet:  [EMAIL PROTECTED]
DM42nh  http://www.primenet.com/~nielsen


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

Re: FIX FOR HAMM: timezone problem

[Marcus Brinkmann]

On Tue, Jun 16, 1998 at 09:57:22PM -0700, G John Lapeyre wrote:
> 
>   I found the entire kernel/hw clock issue quite confusing. (eg ,
> when to use the uct flag )  The man pages help a little.  A clock howto
> would be quite helpful.

Add useful info to /usr/doc/HOWTO/mini/Clock.gz and sent it to the
maintainer...

Marcus

-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09


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

Re: FIX FOR HAMM: timezone problem

[Dale Scheetz]

On Sat, 20 Jun 1998, Nathan E Norman wrote:

> On 19 Jun 1998, John Goerzen wrote:
> 
> : Nathan E Norman <[EMAIL PROTECTED]> writes:
> : 
> : > What exactly makes you say that the central timezone doesn't deal with
> : > DST?  If you mean "US/Central" I will have to disagree with you. :) It
> : > works fine here.
> : 
> : It didn't work here.  I use xntp3 to sync my clock, and it would
> : always get set to Eastern time until I changed to CST6CDT.  After
> : making that change, it now gives results like yours.
> 
This is very strange, as US/Central and CST6CDT are both links to
Americal/Chicago in the 2.0.7 version that I am building for release
today.

The 2.0.7pre3 (which I have currently installed) seems to have these
as separate files.

Which version was the report logged against?

> Ok, fair enough.  I'm assuming you have the same program versions
> installed as I do?  Do you have your hardware clock set to UTC or local
> time?  (Someone said this is a red herring, but I'd like to know that
> for certain).

The important thing is, if the hardware clock is set to UTC, then the init
script should set the GMT variable to "-u" (Possibly "--utc"?). If the
hardware clock is set to Local Time, then GMT should be set to "".

With these two issues properly sync'd things should work properly.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: FIX FOR HAMM: timezone problem

[Nathan E Norman]

On 19 Jun 1998, John Goerzen wrote:

: Nathan E Norman <[EMAIL PROTECTED]> writes:
: 
: > What exactly makes you say that the central timezone doesn't deal with
: > DST?  If you mean "US/Central" I will have to disagree with you. :) It
: > works fine here.
: 
: It didn't work here.  I use xntp3 to sync my clock, and it would
: always get set to Eastern time until I changed to CST6CDT.  After
: making that change, it now gives results like yours.

Ok, fair enough.  I'm assuming you have the same program versions
installed as I do?  Do you have your hardware clock set to UTC or local
time?  (Someone said this is a red herring, but I'd like to know that
for certain).

Mine is set to UTC.

--
Nathan Norman
MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD  57104
mailto://[EMAIL PROTECTED]   http://www.midco.net
finger [EMAIL PROTECTED] for PGP Key: (0xA33B86E9)



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

Re: selling hamm CD 's ?

[Philip Hands]

> On Sat, Jun 20, 1998 at 02:42:03AM +, Michael Shields wrote:
> : In article <[EMAIL PROTECTED]>,
> : G John Lapeyre <[EMAIL PROTECTED]> wrote:
> : >   Does anyone have hamm CD's to sell yet ?  I have a friend in Paris
> : > who wants to install on a laptop.  I'd hate to see him go RH.  I think he
> : > has a network card.  Maybe apt and a remote archive works pretty well now
> : > for installing ? 
> 
> IMHO the main problem currently the installation procedure with CD-ROM,
> since the distribution doesn't fit on one CD-ROM.
> 
> As far as I know nobody (but me) has made any attempt to solve this.
> I'm currently testing a multi-CD installation.

I'm interested, but have no time to deal with it until after the weekend.  
Could you have a look at what the differences are between what you are 
producing , and what gets produced by:

  http://www.open.com/~phil/debian/debian-hamm-cdrom-0.12-pgh-2.tar.gz

and I'll look at incorporating any improvements you've made after the weekend.

Cheers, Phil.


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

Re: selling hamm CD 's ?

[Heiko Schlittermann]

On Sat, Jun 20, 1998 at 02:42:03AM +, Michael Shields wrote:
: In article <[EMAIL PROTECTED]>,
: G John Lapeyre <[EMAIL PROTECTED]> wrote:
: > Does anyone have hamm CD's to sell yet ?  I have a friend in Paris
: > who wants to install on a laptop.  I'd hate to see him go RH.  I think he
: > has a network card.  Maybe apt and a remote archive works pretty well now
: > for installing ? 

IMHO the main problem currently the installation procedure with CD-ROM,
since the distribution doesn't fit on one CD-ROM.

As far as I know nobody (but me) has made any attempt to solve this.
I'm currently testing a multi-CD installation.

About handling multi-CD with other methods I don't know anything.  No
maintainer of the approbiate packages responded so far.

( Probably since almost all have good net access? )


Heiko
---
datom * internet * support ** Heiko Schlittermann & Partner GbR
mailto:[EMAIL PROTECTED] http://www.datom.de/is voice:+49-351-8029981
Heiko Schlittermann HS12-RIPE finger:[EMAIL PROTECTED] ---


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

Re: FIX FOR HAMM: timezone problem

[John Goerzen]

OK then, just to recap -- US/Central was off by an hour (giving me
Eastern instead of Central time when syncing with xntp3).

Here is my etc/init.d/hwclock.sh:

GMT=-u
#
#   Set and adjust the CMOS clock.
#
if [ ! -f /etc/adjtime ]
then
echo "0.0 0 0.0" > /etc/adjtime
fi
if [ -x /sbin/hwclock ]
then
[ "$GMT" = "-u" ] && GMT="--utc"
hwclock --adjust $GMT
hwclock --hctosys $GMT
else
[ "$GMT" = "--utc" ] && GMT="-u"
clock -a $GMT
fi

#
#   Now that /usr/lib/zoneinfo should be available,
#   announce the local time.
#
if [ "$VERBOSE" != no ]
then
echo
echo "Local time: `date`"
echo
fi



"David Engel" <[EMAIL PROTECTED]> writes:

> On Tue, Jun 16, 1998 at 02:00:41PM -0400, Dale Scheetz wrote:
> > Sorry to have stayed out of this but I have been busy...
> > 
> > Bottom line...tzconfig is broken.
> > 
> > If you look at the list provided under US there is an entry of
> > Indiana-Eastern, and Arizona... as well. These should be linked to their
> > non-DST configuration. The ones that say eastern, and central, and
> > mountain, and pacific, should all understand daylight shaving time. (Bill,
> > I hate daylight shavings time)
> > 
> > The central timezone provided by tzconfig is broken, in that it clearly
> > doesn't deal with DST correctly. I believe I have heard of this problem
> > before. I guess it is time to look at the guts of this and figure out how
> > to fix it.
> 
> I'm pretty sure you are mistaken, Dale.  I seriously doubt that there
> is anything wrong with the timezone files or tzconfig.  I no longer
> have the original problem report on hand, but I suspect the problem
> was caused by either an incorrectly set CMOS clock or incorrect
> use/non-use of the hwclock -u option in /etc/init.d/hwclock.sh.
> 
> FYI, the US/{Eastern,Central,Mountain,Pacific} timezones do use DST
> and the US/{Arizona,East-Indiana,Hawaii} timezones don't.  I'm not
> sure about the others, but I'd bet that they are correct also.
> 
> David
> -- 
> David EngelODS Networks
> [EMAIL PROTECTED]   1001 E. Arapaho Road
> (972) 234-6400 Richardson, TX  75081
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
John Goerzen   Linux, Unix consulting & programming   [EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   www.debian.org |
+
Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org


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

Re: FIX FOR HAMM: timezone problem

[John Goerzen]

Nathan E Norman <[EMAIL PROTECTED]> writes:

> What exactly makes you say that the central timezone doesn't deal with
> DST?  If you mean "US/Central" I will have to disagree with you. :) It
> works fine here.

It didn't work here.  I use xntp3 to sync my clock, and it would
always get set to Eastern time until I changed to CST6CDT.  After
making that change, it now gives results like yours.

> 
> kepler:~ $ cat /etc/timezone 
> US/Central
> kepler:~ $ date
> Tue Jun 16 13:27:25 CDT 1998
> kepler:~ $ date --utc
> Tue Jun 16 18:27:29 UTC 1998
> kepler:~ $ ps awx | grep xntp
>   279  ?  S0:01 /usr/sbin/xntpd 
> 
> Where's the problem?  I'm confused.
> 
> --
> Nathan Norman
> MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD  57104
> mailto://[EMAIL PROTECTED]   http://www.midco.net
> finger [EMAIL PROTECTED] for PGP Key: (0xA33B86E9)
> 
> [ package info ]
> kepler:~ $ dpkg -l timezones
> Desired=Unknown/Install/Remove/Purge
> |
> Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
> uppercase=bad)
> ||/ NameVersionDescription
> +++-===-==-
> ii  timezones   2.0.7pre1-4Time zone data files and utilities.
> 
> kepler:~ $ dpkg -l timezone
> Desired=Unknown/Install/Remove/Purge
> |
> Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
> uppercase=bad)
> ||/ NameVersionDescription
> +++-===-==-
> pn  timezone (no description available)
> 
> 
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
John Goerzen   Linux, Unix consulting & programming   [EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   www.debian.org |
+
Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org


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

Re: selling hamm CD 's ?

[Michael Shields]

In article <[EMAIL PROTECTED]>,
G John Lapeyre <[EMAIL PROTECTED]> wrote:
>   Does anyone have hamm CD's to sell yet ?  I have a friend in Paris
> who wants to install on a laptop.  I'd hate to see him go RH.  I think he
> has a network card.  Maybe apt and a remote archive works pretty well now
> for installing ? 

Yes, it does.
-- 
Shields, CrossLink.


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

Re: About the Hamm Freeze (!)

[Darren/Torin/Who Ever...]

-BEGIN PGP SIGNED MESSAGE-

James Troup, in an immanent manifestation of deity, wrote:
>Of course, I agree, but my point was that gdbm *Shouldn't* be required
>and although it will need to be made so in hamm as a kludge, I tried
>to get this fixed properly back in March.

And the point that I was trying to make was that it was too great of a
change and that I'd do it in the next release.  We WILL break people's
scripts.

Darren
- -- 
<[EMAIL PROTECTED]> <http://www.daft.com/~torin> <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire.  C/Perl/CGI programmer and tutor. @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNYrj+44wrq++1Ls5AQE/PwP/SscliqYy5/gmPSoLwxr0UFY6h0atPsyz
31rXFSPsXNI7TCwBcTbWFFxj5Jo9AuGEd0uMFl2yoga7qsnIVgq/2F+kb0fEV94L
79NCKnYn+Xc0vxvv07Ir0/Z8vkEUPgLWz1gcCUA5+MwI/MYcQoJ83rHrwuqn9HhO
lIRCeo79NmM=
=bVSg
-END PGP SIGNATURE-


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

Re: The Hamm Bugs Stamp-Out List for 1998-06-19

[peloy]

Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Welcome to a nem Hamm Bugs Stamp-Out List.
> 
> Since Richar Braakman is currently on vacation, I will be maintaining
> this for the next two weeks. This is my first post, so please excuse
> any errors/oversights and report them to me.
> 
> Wichert.
> 
> Major changes:
> - Fixes were uploaded for dosemu, dwww, libpaper*, libsocks4, metamail, ssh,
>   tetex-bin
> - Application moved out of main: sniffit, rat, crafty, kbd 
[...]

kbd moved out of main? Is this the same kbd that is in section base?
Isn't this an important package?

E.-

-- 

Eloy A. Paris
Information Technology Department
Rockwell Automation Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645


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

Re: The Hamm Bugs Stamp-Out List for 1998-06-19

[Wichert Akkerman]

Previously Vincent Renardias wrote:
> I hope kbd has not been removed from hamm, it would be pretty bad for all
> the users _not_ having a US keyboard...

I stand corrected. kbd should have been in the list of packages for which
a fixed version was uploaded/installed.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpUiQ1GvNcPS.pgp
Description: PGP signature

Re: The Hamm Bugs Stamp-Out List for 1998-06-19

[Vincent Renardias]

On Fri, 19 Jun 1998, Wichert Akkerman wrote:

> Major changes:
[snip]
> - Application moved out of main: sniffit, rat, crafty, kbd 
 ^^^
I hope kbd has not been removed from hamm, it would be pretty bad for all
the users _not_ having a US keyboard...

[snip]

> Package: kbd  
> Maintainer: Yann Dirson <[EMAIL PROTECTED]> 
>   23639  postinst
> [FIX] Yann Dirson added an additionnal test-and-remove on top of postinst
>   and uploaded 0.95-16 on June 19.



-- 
- Vincent RENARDIAS [EMAIL PROTECTED],pipo.com,debian.org} -
- Debian/GNU Linux:   Pipo:WAW:   -
- http://www.fr.debian.orghttp://www.pipo.com  http://www.waw.com -
---
- "La fonctionnalite Son Visuel vous delivre des avertissements visuels." -
-  [Message durant l'installation de Windows95]:wq 


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

[solved] Re: ^Z doesn't work with latest hamm!

[Roberto Lumbreras]

Sorry to bother all of you with my strange problems, I just
rebooted the machine and it works again. I think it was something
with bash, with other shells (tcsh and csh) it worked ok but within
bash not at all. Anyway, a reboot solved it.

Regards,
-- 
Roberto Lumbreras
[EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] & pgp 143BE391
Lander Internet, Madrid-Spain-UE; http://www.lander.es


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

Re: ^Z doesn't work with latest hamm!

[Roberto Lumbreras]

El jueves 18 de junio de 1998, a las 20:40:35, Herbert Xu escribió:
: In article <[EMAIL PROTECTED]> you wrote:
: > I have a "fresh hamm" and ^Z stopped working in nvi, vim,
: > less, cat (!!!)...
: 
: What does stty say when you're running those applications?

$ stty -a
speed 38400 baud; rows 30; columns 100; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; 
time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany
-imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke

: > root:~# dpkg -l bash csh '*ncurses*' libc6 libreadlineg2|grep -v ^[up]
: > Desired=Unknown/Install/Remove/Purge
: > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
: > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
uppercase=bad)
: > ||/ NameVersionDescription
: > 
+++-===-==-
: > ii  bash2.01.1-3   The GNU Bourne Again SHell
: > ii  csh 5.26-9 Shell with C-like syntax, standard login 
she
: > ii  ncurses-base1.9.9g-8.5 Video terminal manipulation - Minimum 
termin
: > ii  ncurses-bin 1.9.9g-8.5 Video terminal manipulation - associated 
pro
: > ii  ncurses-term1.9.9g-8.5 Video terminal manipulation - additional 
ter
: > ii  ncurses3.0  1.9.9e-2.1 Old libc5 curses - shared libraries
: > ii  ncurses3.4  1.9.9g-8.5 Video terminal manipulation - shared 
librari
: > ii  ncurses3.4-dev  1.9.9g-8.5 Video terminal manipulation - 
Developer's li
: > ii  libc6   2.0.7pre1-4The GNU C library version 2 (run-time 
files)
: > ii  libreadlineg2   2.1-10 GNU readline and history libraries, 
run-time
: 
: All the same here (except ncurses3.0) and no problems.

I hadn't changed anything... and the machines not updated to
latest hamm don't suffer the problem at all.

: -- 
: Debian GNU/Linux 1.3 is out! ( http://www.debian.org/ )
: Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
: Home Page: http://gondor.apana.org.au/~herbert/
: PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Saludos,
-- 
Roberto A. Lumbreras Pastor
[EMAIL PROTECTED] | [EMAIL PROTECTED] & pgp 143BE391
Lander Internet; Po Castellana 121, 28046 Madrid; http://www.lander.es
Teléfono 91-556.28.83 | 902-363.363 - Fax 91-556.30.01

Q: What's the difference between Windows 95 and computer viruses?
A: None, except for the fact that a virus never crashes itself


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

Re: Hamm install disks -- where are they?

[Enrique Zanardi]

On Thu, Jun 18, 1998 at 10:47:40AM -0400, Will Lowe wrote:
> subject says it all...

Version 2.0.6 is in our FTP mirrors ( hamm/hamm/disks-i386/current ).
There's a prerelease for 2.0.7 at
  ftp://molec2.dfis.ull.es/pub/debian-spanish/boot-floppies/release-2.0.7

The final 2.0.7 will be uploaded to master in a few days.

Thanks,
--
Enrique Zanardi[EMAIL PROTECTED]


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

Hamm install disks -- where are they?

[Will Lowe]

subject says it all...
Will


--
| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]   |
|   http://www.cis.udel.edu/~lowe/   |
|PGP Public Key:  http://www.cis.udel.edu/~lowe/index.html#pgpkey|
--
|   You think you're so smart,  but I've seen you naked  |
|  and I'll prob'ly see you naked again ...  |
| --The Barenaked Ladies,  "Blame It On Me"  |
--


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

Re: About the Hamm Freeze (!)

[Brian White]

> > I was told that dselect has problems with hamm being distributed on
> > more than one cd rom.  Ian Jackson suggested that we should take a
> > look at dpkg-mountable.  This means that a) dpkg-mountable might need
> > to be included in the boot floppies and b) we'll need at least one another
> > set of boot floppies - or someone invents a different method for this.

I believe Dale fit the i386 distribution (the largest, I assume) on 1 CD
with about 30k to spare1Dale, please correct me if I misunderstood.


> Erk. dpkg-mountable has at least one problem which might cause problems: it
> currently doesn't support predependencies. If the autoup.sh script takes care
> of all predependencies, that's fine; otherwise, people are going to have to
> export DPKG_MOUNTABLE_PREDEP_SUPPORT=yes before their first upgrade.
> 
> The only reason for this is that I wanted to get the other bugfixes into Hamm
> but I didn't have time to test it well enough. If it is necessary, it'd be
> good if people could test running with this and let me know if it works or not
> (I'm fairly sure, based on later experiments, that it will), and if there's
> time I'll upload a version with predepends support enabled by default.

If it's necessary (i.e. Debian sits on multiple CDs) and passes testing
then changing this to enable predependencies by default is okay.  This
should be the _only_ change, though.


> (I also have another change which installs packages in order of priority,
> which is in my local tree, but unfortunately I coded too long after freeze for
> it to make it in. If people want it I'm happy to upload this too, though.)

I'd rather not.  It worries me.  Let's see if it is neccessary, first.

  Brian
 ( [EMAIL PROTECTED] )

---
   Tired of spam?  See what you can do to fight it at: http://www.cauce.org/


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

Re: Hamm CD layouts

[Heiko Schlittermann]

On Wed, Jun 17, 1998 at 09:58:58PM +0100, Steve McIntyre wrote:
: 
: Has any consensus been reached about the best layout to be used for Hamm
: disks? I've written several 3-CD sets for people so far using a simple
: layout (below), but it would be nice to be able to produce to produce ones
: similar to the official ones...
: 
: Disk 1:  Main binary  (i386, bootable)
: Disk 2:  Contrib, non-free and non-US (binary-i386 and source)
: Disk 3:  Main source (except X11, movesd to disk #2 for space reasons)
: 
: I'd be happy to stay with this if dselect could be persuaded to ask for a
: disk change between sections (particularly main -> contrib).

I've created a similar layout (except for the source).  And I've
hacked the disk methods to run with a distributed distribution ;-) ...
I'm currently testing it.


Heiko
---
datom * internet * support ** Heiko Schlittermann & Partner GbR
mailto:[EMAIL PROTECTED] http://www.datom.de/is voice:+49-351-8029981
Heiko Schlittermann HS12-RIPE finger:[EMAIL PROTECTED] ---


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

Re: Hamm CD layouts

[Steve McIntyre]

On Wed, 17 Jun 1998, Philip Hands wrote:

> > Disk 1:  Main binary  (i386, bootable)
> > Disk 2:  Contrib, non-free and non-US (binary-i386 and source)
> > Disk 3:  Main source (except X11, movesd to disk #2 for space reasons)
> 
> I think we need two layouts, one for the mass-production folks, and one for 
> the small run gold-CD-ers.

Yes, that makes sense.

[snip]

> I would guess that most people that produce gold CD's have a mirror of the 
> parts of the ftp archive that they want to put on the CD's anyway, so they 
> would be best of using the standard scripts to produce their own CD images.
> 
> You can get Andreas's CD building scripts from:
> 
>   http://www.uk.debian.org/~aj/

Ah, that's what I was looking for. Thanks.

> BTW If you have a mirror of the ftp archive, but would like to be burning the 
> Official images once they are produced, you can save some bandwidth by 
> producing CD images locally, and then rsyncing them with the official images.

Hmmm, yes. I wouldn't have thought of that myself. Now if only I can get
the company firewall to let me run rsync :-(

> I'm not sure we really need ``Official'' versions of the layout aimed at the 
> small run gold-CD-ers, because most of them will want to add a few extra 
> packages of their own, or some such.

Exactly. Most of the people I'm supporting with these disks can't live
without some of the non-free packages, for example. And ssh and friends
are a bit useful too.

-- 
Steve McIntyre
[EMAIL PROTECTED]


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

^Z doesn't work with latest hamm!

[Roberto Lumbreras]

Hi all.

I have a "fresh hamm" and ^Z stopped working in nvi, vim,
less, cat (!!!)...

I don't know what package is broking it, maybe ncurses, bash,
libc6...; with csh ^Z works as expected with all programs. I'm
puzled. And not, it is not a hardware/ram problem, it is happening
in all my "fresh hamm"'s.

Ideas??

root:~# dpkg -l bash csh '*ncurses*' libc6 libreadlineg2|grep -v ^[up]
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ NameVersionDescription
+++-===-==-
ii  bash2.01.1-3   The GNU Bourne Again SHell
ii  csh 5.26-9 Shell with C-like syntax, standard login she
ii  ncurses-base1.9.9g-8.5 Video terminal manipulation - Minimum termin
ii  ncurses-bin 1.9.9g-8.5 Video terminal manipulation - associated pro
ii  ncurses-term1.9.9g-8.5 Video terminal manipulation - additional ter
ii  ncurses3.0  1.9.9e-2.1 Old libc5 curses - shared libraries
ii  ncurses3.4  1.9.9g-8.5 Video terminal manipulation - shared librari
ii  ncurses3.4-dev  1.9.9g-8.5 Video terminal manipulation - Developer's li
ii  libc6   2.0.7pre1-4The GNU C library version 2 (run-time files)
ii  libreadlineg2   2.1-10 GNU readline and history libraries, run-time

kernel is 2.0.33

Regards,
-- 
Roberto Lumbreras
[EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] & pgp 143BE391
Lander Internet, Madrid-Spain-UE; http://www.lander.es

Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec


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

Re: About the Hamm Freeze (!)

[Andy Mortimer]

Dear all,

I'm a little late with this, unfortunately, but here goes anyway ...

Martin Schulze <[EMAIL PROTECTED]> writes:

> I was told that dselect has problems with hamm being distributed on
> more than one cd rom.  Ian Jackson suggested that we should take a
> look at dpkg-mountable.  This means that a) dpkg-mountable might need
> to be included in the boot floppies and b) we'll need at least one another
> set of boot floppies - or someone invents a different method for this.

Erk. dpkg-mountable has at least one problem which might cause problems: it
currently doesn't support predependencies. If the autoup.sh script takes care
of all predependencies, that's fine; otherwise, people are going to have to
export DPKG_MOUNTABLE_PREDEP_SUPPORT=yes before their first upgrade.

The only reason for this is that I wanted to get the other bugfixes into Hamm
but I didn't have time to test it well enough. If it is necessary, it'd be
good if people could test running with this and let me know if it works or not
(I'm fairly sure, based on later experiments, that it will), and if there's
time I'll upload a version with predepends support enabled by default.

Happily, this is already copied to the release manager, whose decision it
should probably be what happens here; I just think it's fairly important to
get a decent first install.

> This is based on the idea that only packages up to a certain priority
> are included on the first cdrom and lower priorities are distributed
> through the second one.

(I also have another change which installs packages in order of priority,
which is in my local tree, but unfortunately I coded too long after freeze for
it to make it in. If people want it I'm happy to upload this too, though.)

Thanks,

Andy

-- 
Andy Mortimer, [EMAIL PROTECTED]
http://www.poboxes.com/andy.mortimer
PGP public key available on key servers
--
This is the noise that keeps me awake.


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

Re: Hamm CD layouts

[Philip Hands]

> Has any consensus been reached about the best layout to be used for Hamm
> disks? I've written several 3-CD sets for people so far using a simple
> layout (below), but it would be nice to be able to produce to produce ones
> similar to the official ones...
> 
> Disk 1:  Main binary  (i386, bootable)
> Disk 2:  Contrib, non-free and non-US (binary-i386 and source)
> Disk 3:  Main source (except X11, movesd to disk #2 for space reasons)

I think we need two layouts, one for the mass-production folks, and one for 
the small run gold-CD-ers.

The mass production set should pack as much stuff onto as few CD's as 
possible.  Apparently Andreas came up with a layout that gets the binaries
for the different architectures onto 4 CD's if he mixes architectures.

This would be good for the big run folks, but if you only want to burn a few 
CD's for people that you know only want one architecture, then you would be 
better off with a layout that segregates the architectures.

I would guess that most people that produce gold CD's have a mirror of the 
parts of the ftp archive that they want to put on the CD's anyway, so they 
would be best of using the standard scripts to produce their own CD images.

You can get Andreas's CD building scripts from:

  http://www.uk.debian.org/~aj/

BTW If you have a mirror of the ftp archive, but would like to be burning the 
Official images once they are produced, you can save some bandwidth by 
producing CD images locally, and then rsyncing them with the official images.

I'm not sure we really need ``Official'' versions of the layout aimed at the 
small run gold-CD-ers, because most of them will want to add a few extra 
packages of their own, or some such.

Cheers, Phil.
http://www.uk.debian.org/debian-cd/


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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Raul Miller]

Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> some people don't use dpkg, don't use debian, and still will burn a cdrom for
> a friend. a tar.gz is much better ...

Or a brief note that says use "ar x blah...deb" to extract the tar.gz file.

-- 
Raul


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

Hamm CD layouts

[Steve McIntyre]

Has any consensus been reached about the best layout to be used for Hamm
disks? I've written several 3-CD sets for people so far using a simple
layout (below), but it would be nice to be able to produce to produce ones
similar to the official ones...

Disk 1:  Main binary  (i386, bootable)
Disk 2:  Contrib, non-free and non-US (binary-i386 and source)
Disk 3:  Main source (except X11, movesd to disk #2 for space reasons)

I'd be happy to stay with this if dselect could be persuaded to ask for a
disk change between sections (particularly main -> contrib).

-- 
Steve McIntyre
[EMAIL PROTECTED]


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

selling hamm CD 's ?

[G John Lapeyre]

Does anyone have hamm CD's to sell yet ?  I have a friend in Paris
who wants to install on a laptop.  I'd hate to see him go RH.  I think he
has a network card.  Maybe apt and a remote archive works pretty well now
for installing ? 

John

John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre


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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Enrique Zanardi]

On Wed, Jun 17, 1998 at 06:55:13PM +0200, Andreas Jellinghaus wrote:
> > What's wrong with having both? We already have dpkg*nondebbin.tgz.
> 
> both is ok. do you want to create the package ?

I would like to, but currently I'm busy building and testing
boot-floppies_2.0.7. I may be able to try your scripts/makefile next
week, but I think the packaging should be done by someone with enough
time to maintain the package properly.

(As I wrote the message you quoted, I guess I should answer your
question).

Thanks,
--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Andreas Jellinghaus]

> Please, note that I'm not saying that these scripts should be distributed
> *just* as a .deb package. I'm saying that they should probably be
> distributed as a .deb package *in addition* to any other form of
> distributing them. I don't want to discuss "what is better".

so, feel free to pickup the scripts and do a package !

andreas


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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Andreas Jellinghaus]

> What's wrong with having both? We already have dpkg*nondebbin.tgz.

both is ok. do you want to create the package ?

andreas


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

Re: fonts messed up in emacs after last hamm update

[Jens Ritter]

Thomas Gebhardt <[EMAIL PROTECTED]> writes:

> Hi,
> 
> after the last upgrade from a hamm mirror the X font metrics in
> emacs are completely messed up such that any text becomes
> unreadable and the characters seem to be placed in the
> window randomly.
> 
> Since this problem occurs also when displaying a remote emacs
> on the local X server, it might be a problem with the X11
> server or the fonts.
> 
> Has anybody experienced the same problem and/or knows a solution?

I´m experiencing this after my upgrade from hamm to slink
(in emacs20). I currently choose Mule -> Set Font/Fontset on every
startup of emacs. 

The fonts in xterm are messed up, too (started without options it
displays a non-serif proportional font with broad fixed-width
spacing). 

Are you using KDE?

Jens

---
[EMAIL PROTECTED]   [EMAIL PROTECTED]
Key ID: 2048/E451C639 Jens Ritter
Key fingerprint: 5F 3D 43 1E 24 1E CC 48  1E 05 93 3A A7 10 73 37 


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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Enrique Zanardi]

On Tue, Jun 16, 1998 at 08:31:15PM +0200, Andreas Jellinghaus wrote:
> > Well, but putting them in a hamm package does not prevent people using bo
> > to download that package (it's a "binary-all" package, isn't it?) and use
> > it. Moreover, people can use the bug tracking system to report bugs.
> > I don't think a package is such a wrong place.
> 
> some people don't use dpkg, don't use debian, and still will burn a cdrom for
> a friend. a tar.gz is much better ...

What's wrong with having both? We already have dpkg*nondebbin.tgz.

--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Tue, 16 Jun 1998, Andreas Jellinghaus wrote:

> > Well, but putting them in a hamm package does not prevent people using bo
> > to download that package (it's a "binary-all" package, isn't it?) and use
> > it. Moreover, people can use the bug tracking system to report bugs.
> > I don't think a package is such a wrong place.
> 
> some people don't use dpkg, don't use debian, and still will burn a cdrom for
> a friend. a tar.gz is much better ...

Please, note that I'm not saying that these scripts should be distributed
*just* as a .deb package. I'm saying that they should probably be
distributed as a .deb package *in addition* to any other form of
distributing them. I don't want to discuss "what is better".

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNYeOuiqK7IlOjMLFAQF8SgP+J2DMkcHmKSy6SCFJ9xHKBMf/kLuUXI06
YztJ1EmfvWIF8Uanzj1UgD+95b8DHoKdFqytrsLDkfUKImrmhP6qxW8FRh1gBili
8ia85+6GZ/sO0ZTikKpWp6eybmGMxNA7aVYO+yyXrTvMuqrNjL7Vh1FcdIX2HoqP
jVRUbEhmbuo=
=f+uG
-END PGP SIGNATURE-


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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Philip Hands]

Regarding the idea of doing the cd construction scripts as a .deb
Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> no, a package is not a good idea.

Would the .orig.tar.gz for such a package not be exactly what you intend to 
produce anyway ?

In which case, you can satisfy both camps by just adding a simple debian/
directory to build the package.

I'm not sure what the package would actually install though (presumably it 
would just untar the files into /usr/src/debian-cd or some such), but at least 
debian-ites would have a good idea where to find it (i.e. under slink).

Cheers, Phil.



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

fonts messed up in emacs after last hamm update

[Thomas Gebhardt]

Hi,

after the last upgrade from a hamm mirror the X font metrics in
emacs are completely messed up such that any text becomes
unreadable and the characters seem to be placed in the
window randomly.

Since this problem occurs also when displaying a remote emacs
on the local X server, it might be a problem with the X11
server or the fonts.

Has anybody experienced the same problem and/or knows a solution?

(Sorry if that topic has already been discussed, and I have missed
it)

Thanks, Thomas



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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Andreas Jellinghaus]

>> i don't think that a package is the right place for such stuff :
>> many people want to burn debian cd's before or without installing debian 
>> hamm.
>
>Well, but putting them in a hamm package does not prevent people using bo
>to download that package (it's a "binary-all" package, isn't it?) and use
>it. Moreover, people can use the bug tracking system to report bugs.
>I don't think a package is such a wrong place.

cd vendors might use a different linux, and still want to burn and sell debian
cdroms. or maybe you have a friend running a different linux, but he is
willing to burn a debian cd for you ?

no, a package is not a good idea.

andreas


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

Re: Bug#23599: ftp.debian.org: debian-cd is obsolete in hamm

[Andreas Jellinghaus]

> Well, but putting them in a hamm package does not prevent people using bo
> to download that package (it's a "binary-all" package, isn't it?) and use
> it. Moreover, people can use the bug tracking system to report bugs.
> I don't think a package is such a wrong place.

some people don't use dpkg, don't use debian, and still will burn a cdrom for
a friend. a tar.gz is much better ...

andreas


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

Re: FIX FOR HAMM: timezone problem

[G John Lapeyre]

I found the entire kernel/hw clock issue quite confusing. (eg ,
when to use the uct flag )  The man pages help a little.  A clock howto
would be quite helpful.

John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre


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

Re: FIX FOR HAMM: timezone problem

[Larry 'Daffy' Daffner]

> "DS" == Dale Scheetz <[EMAIL PROTECTED]> writes:

  DS> We are working on a report of failure in US/central WRT Daylight
  DS> Savings Time, right?

  DS> There is one variable we haven't nailed down yet. The hardware
  DS> clock can be set either to local time or GMT (UTC). As I
  DS> remember, the failure only happens when the clock is set to one
  DS> of these two. (Memory says Local Time is the broken one)

Not quite correct. I remember this problem, as I was hit by it :)

The problem was with the SystemV CST6CDT timezone. It has an incorrect 
changeover rule. At the time of the switchover, I had my timezone set
to the SystemV/CST6CDT value, and after the switchover it was still
thinking it was set to CST. ntpdate synched the clock correctly with
UTC, but the displayed time was 1 hour off, since it was displaying
CST, not CDT. Switching the timezone to US/Central caused the date to
be displayed correctly.

I just checked, and now CST6CDT correctly gives CDT, so the problem is 
an incorrect transition rule in the SystemV/CCST6CDT timezone file.

The hardware clock issue is a red herring. I only read my clock at
boot time, and my machine had not been booted for several days. I do
write the time back immediately after setting the kernel clock with
ntpdate, though.

-Larry


-- 
  Larry Daffner|  Linux: Unleash the workstation in your PC!
  [EMAIL PROTECTED] / http://web2.airmail.net/vizzie/
Ray's Rule of Precision:
Measure with a micrometer.  Mark with chalk.  Cut with an axe.


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

Re: FIX FOR HAMM: timezone problem

[Jason Gunthorpe]

On 16 Jun 1998, John Goerzen wrote:

> Enrique Zanardi <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Jun 16, 1998 at 07:54:42AM -0500, John Goerzen wrote:
> > > I'd say something like: "If your time changes for daylight savings
> > > time, use these options.  Otherwise, use these."
> > > 
> > > Something needs to be done on the bootdisks, too.
> > 
> > OK. So, which are the options for DST and which are the others? Does that
> > apply to all US zones or only to US/Central?
> 
> It appears that the ones like CST6CDT, EST5EDT, etc. are the proper
> ones for the majority of US.  Most of Indiana and some spots of Arizona
> apparently use other options, but I don't know what they are at the
> moment.
> 
> This applies to all US (and Canadian and Mexican?) timezones.

I assume you have all looked in the timezone information files in the
glibc package? They explain in detail exactly how each timezone is setup,
when then go to dst and so on.

Jason


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

Re: FIX FOR HAMM: timezone problem

[David Engel]

On Tue, Jun 16, 1998 at 02:00:41PM -0400, Dale Scheetz wrote:
> Sorry to have stayed out of this but I have been busy...
> 
> Bottom line...tzconfig is broken.
> 
> If you look at the list provided under US there is an entry of
> Indiana-Eastern, and Arizona... as well. These should be linked to their
> non-DST configuration. The ones that say eastern, and central, and
> mountain, and pacific, should all understand daylight shaving time. (Bill,
> I hate daylight shavings time)
> 
> The central timezone provided by tzconfig is broken, in that it clearly
> doesn't deal with DST correctly. I believe I have heard of this problem
> before. I guess it is time to look at the guts of this and figure out how
> to fix it.

I'm pretty sure you are mistaken, Dale.  I seriously doubt that there
is anything wrong with the timezone files or tzconfig.  I no longer
have the original problem report on hand, but I suspect the problem
was caused by either an incorrectly set CMOS clock or incorrect
use/non-use of the hwclock -u option in /etc/init.d/hwclock.sh.

FYI, the US/{Eastern,Central,Mountain,Pacific} timezones do use DST
and the US/{Arizona,East-Indiana,Hawaii} timezones don't.  I'm not
sure about the others, but I'd bet that they are correct also.

David
-- 
David EngelODS Networks
[EMAIL PROTECTED]   1001 E. Arapaho Road
(972) 234-6400 Richardson, TX  75081


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

Re: FIX FOR HAMM: timezone problem

[John Goerzen]

Enrique Zanardi <[EMAIL PROTECTED]> writes:

> On Tue, Jun 16, 1998 at 07:54:42AM -0500, John Goerzen wrote:
> > I'd say something like: "If your time changes for daylight savings
> > time, use these options.  Otherwise, use these."
> > 
> > Something needs to be done on the bootdisks, too.
> 
> OK. So, which are the options for DST and which are the others? Does that
> apply to all US zones or only to US/Central?

It appears that the ones like CST6CDT, EST5EDT, etc. are the proper
ones for the majority of US.  Most of Indiana and some spots of Arizona
apparently use other options, but I don't know what they are at the
moment.

This applies to all US (and Canadian and Mexican?) timezones.

John

-- 
John Goerzen   Linux, Unix consulting & programming   [EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   www.debian.org |
+
Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org


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

Re: FIX FOR HAMM: timezone problem

[Nathan E Norman]

On Tue, 16 Jun 1998, Dale Scheetz wrote:

: On Tue, 16 Jun 1998, Nathan E Norman wrote:
: 
: > On Tue, 16 Jun 1998, Dale Scheetz wrote:
: > 
: > : Sorry to have stayed out of this but I have been busy...
: > : 
: > : Bottom line...tzconfig is broken.
: > 
: > That may be :)
: > 
: > : If you look at the list provided under US there is an entry of
: > : Indiana-Eastern, and Arizona... as well. These should be linked to their
: > : non-DST configuration. The ones that say eastern, and central, and
: > : mountain, and pacific, should all understand daylight shaving time. (Bill,
: > : I hate daylight shavings time)
: > : 
: > : The central timezone provided by tzconfig is broken, in that it clearly
: > : doesn't deal with DST correctly. I believe I have heard of this problem
: > : before. I guess it is time to look at the guts of this and figure out how
: > : to fix it.
: > 
: > What exactly makes you say that the central timezone doesn't deal with
: > DST?  If you mean "US/Central" I will have to disagree with you. :) It
: > works fine here.
: > 
: > kepler:~ $ cat /etc/timezone 
: > US/Central
: > kepler:~ $ date
: > Tue Jun 16 13:27:25 CDT 1998
: > kepler:~ $ date --utc
: > Tue Jun 16 18:27:29 UTC 1998
: > kepler:~ $ ps awx | grep xntp
: >   279  ?  S0:01 /usr/sbin/xntpd 
: > 
: > Where's the problem?  I'm confused.
: > 
: Me too ;-)
: 
: We are working on a report of failure in US/central WRT Daylight Savings
: Time, right?

Correct :)

: There is one variable we haven't nailed down yet. The hardware clock can
: be set either to local time or GMT (UTC). As I remember, the failure only
: happens when the clock is set to one of these two. (Memory says Local Time
: is the broken one)

Ah, I'd forgotten about that.  I believe your memory is correct.

: Your output, if I can count right (not guaranteed), indicates a 5 hour
: difference from GMT, which, I think, is correct. Which way is your
: hardware clock set?

Hardware clocks here are set to UTC - I figure they're servers, up
24/7 (no dual booting to Win95 :) so UTC is the "right" decision.  I
will try another machine at home which iirc is set to local time.

CDT is indeed UTC-5, and CST is UTC-6.

So, to recap:  I'm using "US/Central" timezone, with hardware clocks set
to UTC, and all is well here.

--
Nathan Norman
MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD  57104
mailto://[EMAIL PROTECTED]   http://www.midco.net
finger [EMAIL PROTECTED] for PGP Key: (0xA33B86E9)



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

Re: FIX FOR HAMM: timezone problem

[Dale Scheetz]

On Tue, 16 Jun 1998, Nathan E Norman wrote:

> On Tue, 16 Jun 1998, Dale Scheetz wrote:
> 
> : Sorry to have stayed out of this but I have been busy...
> : 
> : Bottom line...tzconfig is broken.
> 
> That may be :)
> 
> : If you look at the list provided under US there is an entry of
> : Indiana-Eastern, and Arizona... as well. These should be linked to their
> : non-DST configuration. The ones that say eastern, and central, and
> : mountain, and pacific, should all understand daylight shaving time. (Bill,
> : I hate daylight shavings time)
> : 
> : The central timezone provided by tzconfig is broken, in that it clearly
> : doesn't deal with DST correctly. I believe I have heard of this problem
> : before. I guess it is time to look at the guts of this and figure out how
> : to fix it.
> 
> What exactly makes you say that the central timezone doesn't deal with
> DST?  If you mean "US/Central" I will have to disagree with you. :) It
> works fine here.
> 
> kepler:~ $ cat /etc/timezone 
> US/Central
> kepler:~ $ date
> Tue Jun 16 13:27:25 CDT 1998
> kepler:~ $ date --utc
> Tue Jun 16 18:27:29 UTC 1998
> kepler:~ $ ps awx | grep xntp
>   279  ?  S0:01 /usr/sbin/xntpd 
> 
> Where's the problem?  I'm confused.
> 
Me too ;-)

We are working on a report of failure in US/central WRT Daylight Savings
Time, right?

There is one variable we haven't nailed down yet. The hardware clock can
be set either to local time or GMT (UTC). As I remember, the failure only
happens when the clock is set to one of these two. (Memory says Local Time
is the broken one)

Your output, if I can count right (not guaranteed), indicates a 5 hour
difference from GMT, which, I think, is correct. Which way is your
hardware clock set?

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: FIX FOR HAMM: timezone problem

[Nathan E Norman]

On Tue, 16 Jun 1998, Dale Scheetz wrote:

: Sorry to have stayed out of this but I have been busy...
: 
: Bottom line...tzconfig is broken.

That may be :)

: If you look at the list provided under US there is an entry of
: Indiana-Eastern, and Arizona... as well. These should be linked to their
: non-DST configuration. The ones that say eastern, and central, and
: mountain, and pacific, should all understand daylight shaving time. (Bill,
: I hate daylight shavings time)
: 
: The central timezone provided by tzconfig is broken, in that it clearly
: doesn't deal with DST correctly. I believe I have heard of this problem
: before. I guess it is time to look at the guts of this and figure out how
: to fix it.

What exactly makes you say that the central timezone doesn't deal with
DST?  If you mean "US/Central" I will have to disagree with you. :) It
works fine here.

kepler:~ $ cat /etc/timezone 
US/Central
kepler:~ $ date
Tue Jun 16 13:27:25 CDT 1998
kepler:~ $ date --utc
Tue Jun 16 18:27:29 UTC 1998
kepler:~ $ ps awx | grep xntp
  279  ?  S0:01 /usr/sbin/xntpd 

Where's the problem?  I'm confused.

--
Nathan Norman
MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD  57104
mailto://[EMAIL PROTECTED]   http://www.midco.net
finger [EMAIL PROTECTED] for PGP Key: (0xA33B86E9)

[ package info ]
kepler:~ $ dpkg -l timezones
Desired=Unknown/Install/Remove/Purge
|
Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ NameVersionDescription
+++-===-==-
ii  timezones   2.0.7pre1-4Time zone data files and utilities.

kepler:~ $ dpkg -l timezone
Desired=Unknown/Install/Remove/Purge
|
Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ NameVersionDescription
+++-===-==-
pn  timezone (no description available)




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

Re: FIX FOR HAMM: timezone problem

[Alexander Kushnirenko]

Hi, Dale!

Sorry to jump in (I have almost no expertise in tzconfig), but I have 
US/Central in timezone and date, xntp work fine for me.  May be it's not 
broken? How should one check?

Sasha.

> Sorry to have stayed out of this but I have been busy...
> 
> Bottom line...tzconfig is broken.
> 
> The central timezone provided by tzconfig is broken, in that it clearly
> doesn't deal with DST correctly. I believe I have heard of this problem
> before. I guess it is time to look at the guts of this and figure out how
> to fix it.
> 




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

Re: About the Hamm Freeze (!)

[James Troup]

"Darren/Torin/Who Ever..." <[EMAIL PROTECTED]> writes:

> > I don't know perl, and am only going on what Ray has been telling
> > me.  It was my understanding that perl could be made to
> > dynamically load it's gdbm part on request and that way perl need
> > only recommend or (better) suggest gdbm.  Is this not the case?
> 
> This is the case if you use the tie interface in Perl.  This is not
> the case if you use dbmopen, at least it didn't use to be.  Hamm
> should just get out the door and we'll deal with it in slink.

Of course, I agree, but my point was that gdbm *Shouldn't* be required
and although it will need to be made so in hamm as a kludge, I tried
to get this fixed properly back in March.

-- 
James
~Yawn And Walk North~  http://yawn.nocrew.org/


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