Re: dupload question

[Hugo Haas]

On Sun, Jun 21, 1998, Shaleh wrote:
> dupload's man page states that --nomail will cause dupload to NOT send
> an e-mail.  However, this option gives an error and as far as I can see,
> is not in the source.  What has happened?

The "--nomail" option is not implemented (#18512/#18857).

Regards,

Hugo

-- 
Hugo Haas <[EMAIL PROTECTED]>
PGP2 key id 0x8a5af90d, fingerprint 45AB 8D24 B3E4 C9DD E85C 25C8 DB0B BFA3


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

Re: PAM and slink (was Re: packaging PAM modules? anyone?)

[Norbert Veber]

On Sun, Jun 21, 1998 at 07:09:30PM -0400, Adam P. Harris wrote:
> [EMAIL PROTECTED] (Gregory S. Stark) writes:
> 
> > I asked once earlier, but no one responded: 
> > Does anyone know how PAM modules should be packaged?
> 
> Gregory, I'm sorry I cannot provide good technical information.  I do
> know that we had backed out PAM-ifying hamm sometime last year.  I
> think we should re-PAM-ify everything (i.e., pam version of login,
> passwd, etc etc).  I think PAM is stable now and should be embraced
> for slink.
> 
> But I could certainly be wrong.

What sorts of things can pam do?  I only know that for example a long
program that uses PAM works regardless of weather the password file is
shadowed or not, but can it do more advanced authentication, ie. could it be
used to replace radius?


pgpkPIyMDAdT1.pgp
Description: PGP signature

Re: PAM and slink (was Re: packaging PAM modules? anyone?)

[Steve Dunham]

[EMAIL PROTECTED] (Adam P. Harris) writes:

> [EMAIL PROTECTED] (Gregory S. Stark) writes:

> > I asked once earlier, but no one responded: 
> > Does anyone know how PAM modules should be packaged?

> Gregory, I'm sorry I cannot provide good technical information.  I do
> know that we had backed out PAM-ifying hamm sometime last year.  I
> think we should re-PAM-ify everything (i.e., pam version of login,
> passwd, etc etc).  I think PAM is stable now and should be embraced
> for slink.

> But I could certainly be wrong.

I'd like to see PAM in slink.


Steve
[EMAIL PROTECTED]


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

Re: PAM and slink (was Re: packaging PAM modules? anyone?)

[Norbert Veber]

Ugh, this doesnt make sense the way it is.. :)

> What sorts of things can pam do?  I only know that for example a long
  ^login
> program that uses PAM works regardless of weather the password file is
> shadowed or not, but can it do more advanced authentication, ie. could it be
> used to replace radius?




pgpiu7TnCQkrR.pgp
Description: PGP signature

Re: PAM and slink (was Re: packaging PAM modules? anyone?)

[Adam P. Harris]

Norbert Veber <[EMAIL PROTECTED]> writes:
> What sorts of things can pam do?  I only know that for example a long
> program that uses PAM works regardless of weather the password file is
> shadowed or not, but can it do more advanced authentication, ie. could it be
> used to replace radius?

PAM, as I understand it, provides the hooks that enable you to plug in
different authentication/authorization (NIS, NIS+, shadow, passwd,
kerberos, radius, etc).  That way, you have a pam'ified /bin/login,
rather than having a kerbified login, a shadow login, etc etc.

It's used by RedHat and Solaris.

-- 
.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


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

cda from xmcd hassle

[Shaleh]

cda does not appear to work.  First I apparently need to set XMCD_LIBDIR
to where the cfg files are (the postinst did not mention this,but the
man page did).  I set this to /etc/xmcd (which is where the cfg file
lives.  However now when cda starts it tries to read
/etc/xmcd/config/common.cfg -- which does not exist.  I wanted to ask
here before I posted a bug report.


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

Re: PAM and slink (was Re: packaging PAM modules? anyone?)

[Steve Dunham]

[EMAIL PROTECTED] (Adam P. Harris) writes:

> Norbert Veber <[EMAIL PROTECTED]> writes:

> > What sorts of things can pam do?  I only know that for example a
> > long program that uses PAM works regardless of weather the
> > password file is shadowed or not, but can it do more advanced
> > authentication, ie. could it be used to replace radius?

There currently is support to log to a RADIUS server, I think
authentication is still being worked on.  The main point of PAM is to
allow the sysadmin to configure his choice of all of the various
authentication methods via text files, without recompiling anything.

It gives the sysadmin the flexibility (choice) that many people
claim Debian strives to provide.

> PAM, as I understand it, provides the hooks that enable you to plug in
> different authentication/authorization (NIS, NIS+, shadow, passwd,
> kerberos, radius, etc).  That way, you have a pam'ified /bin/login,
> rather than having a kerbified login, a shadow login, etc etc.

> It's used by RedHat and Solaris.

Basically, it lets you specify in a file the rules that programs use
for determining whether someone can log in.

Below are some examples of pam configuration files, but first a bit
about what you can do with it:

* Locally, we are writing a module to stack on top of the password
  modules, so that "passwd" will set both NIS passwords and store a
  samba password.  (This is necessary to use encrypted samba
  passwords.)

* There are modules to implement:
securetty, 
anonymous access,  
group access, 
access at particular times of day, 
"wheel" group access, 
print last login time
print a file
"chroot" (automatically chroot a user)
S/Key

  (so you could, by editing text files, restrict xdm, ppp, ftp, rsh,
  to a certain group, to certain times of day, etc.)

* There's a toy "filter" module, along with an example filter that
  transposes upper and lowercase characters (This could be used to
  implement an annoying cybersitter-like functionality.)

* There is a module to authenticate against an NT server.

* I believe there is a module for secureid cards.

* Future directions include authentication against a LDAP server. 

If you don't like /etc/securettys, you can just edit a file to take it
out.  If you don't like .rhost files, you can just as easily disable
that.  If you only want people in the "manager" group to be able to
use rsh, you edit a file, etc.  If you want wheel on su, just edit a
text file.


Some examples of configuration files. Here is "/etc/pam.d/rsh"

auth   required /lib/security/pam_rhosts_auth.so
auth   required /lib/security/pam_nologin.so
accountrequired /lib/security/pam_pwdb.so
sessionrequired /lib/security/pam_pwdb.so


Says that the "pam_rhosts_auth.so" library has to be satisified, that
"pam_nologin.so" has to be satisfied (checks /etc/nologin).  That
"pam_pdwb.so" has to find an account and that "pam_pdwb.so" is used to
set up the session.  Compare to the "rlogin" file:

auth   required /lib/security/pam_securetty.so
auth   sufficient   /lib/security/pam_rhosts_auth.so
auth   required /lib/security/pam_pwdb.so shadow nullok
auth   required /lib/security/pam_nologin.so
accountrequired /lib/security/pam_pwdb.so
password   required /lib/security/pam_cracklib.so
password   required /lib/security/pam_pwdb.so shadow nullok use_authtok
sessionrequired /lib/security/pam_pwdb.so


The first module checks /etc/securetty (the library fails if the
person is trying to login as root and the tty is not listed there - if
you don't like securetty, you just delete the line).  The second says
that an rhost file entry is sufficient.  Otherwise pam_pwdb.so is
consulted (null passwords are allowed because of the option, and the
shadow file is consulted).  The account and session info is gotten
from pam_pwdb.so.  I don't the the password stack is actually used
here  (it is in the file for the passwd program).


Steve
[EMAIL PROTECTED]


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

Re: Intenet To Package: Electric Eyes

[Gregor Hoffleit]

Aaron Van Couwenberghe wrote:
I will shortly post an intent to package OmniORB. It is a more...
lean, shall we say, CORBA ORB implementation than mico. Eventually
(by word from the gnome mailing lists), gnome will be ported to
OmniORB.

Well, most certainly GNOME won't switch back to OmniORB. Instead they are 
developing their own object request broker, ORBit. IIRC, you can see early 
snapshots of ORBit on Jim Pick's gnome snapshot site at ftp.jimpick.com.

Gregor


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

Re: New gnome packages

[Michael Meskes]

B. Bell writes:
> be sure to check out the panel... it's cool.
> -brad

Nice to hear that. But unless I get a description of how to use gnome I
won't even try. I don't have the time to play around with it. That's what I
like with kde. You install it and you use it. I installed gnome, but have no
idea of how to use it.

Michael

-- 
Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10


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

Re: libc6_2.0.7 release notes...

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Lot of people said:
> What's wrong with using epochs?

epochs last forever, and most people consider them an ugly thing.
Moreover, there is a paragraph in the policy saying that epochs are not
for dealing with "pre" version numbers.

If there is something to solve here, "2.0.7r" would be a better solution,
IMHO, because at least it would allow us to get rid of both the epoch and
the "r" thing in "2.0.8".

But I believe that most of our users will agree that 2.0.7-1 is a much
nicer version number than 2.0.7r-1 and would not mind to install a few
packages by hand just *once*.

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

iQCVAgUBNY4k0yqK7IlOjMLFAQFzNAP/Z7SbBcHUvBUNLzdyCbsaqFKw7KfCKHuB
VCSH9RpeXMCKJ3NpjyDzNztVnCpUD9QVsH1FjgITSDXwaNnCCj5BMyo2j1WYzRF4
p/3CUcDKR4IlWrTrbbaRSXieh6nY+DRTL6NMrhkRMzNoCzKPgOUt8EP6VkrhXoU0
MYOLHMD27Io=
=yf/q
-END PGP SIGNATURE-


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

Re: where is sed in slink?

[Carey Evans]

Joey Hess <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED]:/debian/home/ftp/debian/dists/slink>find | grep sed
> ./main/binary-alpha/base/sed_2.05-22.deb
[...]
> Available for all architectures but i386!? A lot of other important stuff is
> missing as well, like shellutils, textutils, mbr, util-linux..

$ locate sed_2.05-22.deb
[...]
/debian2/debian/hamm/hamm/binary-i386/base/sed_2.05-22.deb
[...]

I don't think slink is supposed to have all the links into hamm yet,
is it?  The other packages were presumably uploaded to "frozen unstable".

-- 
 Carey Evans  http://home.clear.net.nz/pages/c.evans/

"[UNIX] appears to have the inside track on being the replacement for
  CP/M on the largest microcomputers (e.g. those based on 68000...)"


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

Re: libc6_2.0.7 release notes...

[Wichert Akkerman]

Previously Santiago Vila wrote:
> But I believe that most of our users will agree that 2.0.7-1 is a much
> nicer version number than 2.0.7r-1 and would not mind to install a few
> packages by hand just *once*.

It's not having to install a few packages by hand, it's breaking all
dependencies on libc6 2.0.7pre* which a lot of packages have. This
would mean that all packages compiled with a pre-version must be
recompiled to fix their dependencies. Clearly this is not good, and
fixing that in the libc6 package is the only good way to solve this.

Wether we do this by using epochs or 2.0.7r as version number is less
important.

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/


pgpYP0ogHAodx.pgp
Description: PGP signature

Re: libc6_2.0.7 release notes...

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Wichert Akkerman wrote:
> Previously Santiago Vila wrote:
> > But I believe that most of our users will agree that 2.0.7-1 is a much
> > nicer version number than 2.0.7r-1 and would not mind to install a few
> > packages by hand just *once*.
> 
> It's not having to install a few packages by hand, it's breaking all
> dependencies on libc6 2.0.7pre* which a lot of packages have.

Well, how many packages have a dependency like that which are not
generated from the glibc package proper?

Could please indentify them? [ I did not found many ].

> This would mean that all packages compiled with a pre-version must be
> recompiled to fix their dependencies.

True, but if there are not many of them, it could be not so bad,
after all.

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

iQCVAgUBNY5CASqK7IlOjMLFAQGlFQQAtCci0bBKxF2m89qux3a6/+DUURpGSnY/
QJZgjCvwRQn0JZjIXxOcLiHVbYWzEG4uh55UXkJVQqij2h3AfvFFntmnxd5+dFxl
G61bVY2Uzg/4+Qwj+2nTc9Eyvz0jaKabtrr+e+Zi/X3raBs++SBOBAfDpG6mcYgm
66oSogrMUQ8=
=RXJ5
-END PGP SIGNATURE-


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

Where has logwrites gone?

[Hannu Koivisto]

Greetings,

I have noticed that a package logwrites hasn't been available
for a long time anymore. Any ideas why it has disappeared and
whether it will come back or not?


Some time ago I hacked up some administration tools that allow
me to keep all (/usr/)local installations under the control of
Debian package manager and they rely on the logwrites. I can,
for example, say something like this with a typical source
package that uses standard configure+make sequence:

./configure
make
su
ldeb-install --package=foo --version=1.0
make install
cp some-extra-files /usr/local/bin/
exit
#  would build a Debian package out of the
   # installation for installing it to other machines
exit

and voi'la, when I say ldpkg -l (ldpkg == dpkg
--adminroot=/usr/local...) I can see that I now have a new
package foo under dpkg's control and when I say ldpkg -L foo, I
can see the list of files that make install and extra cp command 
copied to /usr/local tree.


TIA,
//Hannu


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

premature closing of bugs

[Wichert Akkerman]

I was looking at the list of release-critical bugs and noticed some bugs
were closed. A lot of those closed bugs are for packages that are still
sitting in Incoming. I would like to remind people that you have to wait
with closing a bug until the fixed package is installed. Closing a bug
before that moment creates the illusion that release-critical bugs are
fixed in the distribution. And Incoming is not a part of the distribution..

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/


pgpsmcXdf8vFg.pgp
Description: PGP signature

Constitution, and SPI section s.9

[Ian Jackson - Debian Project Leader]

I've mailed the SPI Board proposing that they agree to the following:

   1. SPI will hold money, trademarks and other tangible and
  intangible property and manage other affairs for purposes
  related to Debian.

   2. Such property will be accounted for separately and held in trust
  for those purposes, decided on by Debian and SPI according to
  this section.

   3. SPI will not dispose of or use property held in trust for
  purposes related to Debian without approval from Debian, which
  may be granted by the Project Leader or by General Resolution of
  the Developers.

   4. SPI will consider using or disposing of property held in trust
  for purposes related to Debian when asked to do so by the
  Project Leader.

   5. SPI will use or dispose of property held in trust for purposes
  related to Debian when asked to do so by a General Resolution of
  the Developers, provided that this is compatible with SPI's
  legal authority.

   6. SPI will notify the Developers by electronic mail to a Debian
  Project mailing list when it uses or disposes of property held
  in trust for purposes related to Debian.

NB that this has a couple of extra occurrences of `purposes related
to' which I seem to have missed out from the most recent posted
version of the constitution.

Unless anyone objects I plan to have the corrected version voted on
without going through the formal amendment process (which would
involve waiting two weeks, or having voters choose which version they
wanted to accept), as I consider this change not to be substantive.

Ian.


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

Re: Release management - technical

[Ian Jackson]

Enrique Zanardi writes ("Re: Release management - technical"):
> On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
...
> > I think we can only do one of these.  With hamm we're doing the
> > latter; in the future I think we should do the former.
> 
> Fine, as long as we have some "long term goals" that must be achieved,
> better sooner than later (FHS compliance, for example).

NO!  Absolutely not, if you're going to say `must be achieved'.

I read `must be achieved' to mean `we will delay the release if these
are not achieved'.

We are a volunteer organisation, and the last 13 months have shown us
that you can't guilt people into doing things.

We should continue to have `long term goals', and I applaud people who
work towards them, but we must be able to make a release even when
they are not met.  It is better to have a release now and goals later
than no release now and goals later !

David Engel writes ("Re: Release management - technical"):
> On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
> > Q. What are we trying to achieve ?
> > 
> > A. There are two possibilities that I can see
> > - Timely and good-quality releases, or
> > - Releases which meet some predefined set of goals.
> > 
> > I think we can only do one of these.  With hamm we're doing the
> > latter; in the future I think we should do the former.
> 
> I disagree.  "Timely and good-quality releases" is just another goal.
> What we haven't done been able to do in the past is strike a balance
> and have sacrificed timely releases in favor of other goals.

I don't see how timely and good-quality releases work against our
other goals, per se.

What has been happening so far is that we've been saying `Ner! We
_shan't_ have a timely release unless we meet these goals, so you
_must_ go and work on the goals.'  This has FAILED.

In future, we should make releases _without regard to long term
goals_.  Since we have to be incrementally-upgradeable, long term
goals can be achieved just as easily out of step with releases.

Ian.


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

Re: Propersel for standerd configuration system.

[Ian Jackson]

Jules Bean writes ("Re: Propersel for standerd configuration system. "):
> --On Fri, Jun 12, 1998 7:53 am +0100 "Philip Hands" <[EMAIL PROTECTED]> 
> wrote: 
> >> The layout of the registry will be similar to Microsoft's windows
> >> registry however it will be far more powerful.
> > ...
> >> So what do you think of this idea?
> > 
> > IMHO The registry is the main reason that on Windows the solution to every
> > problem is ``re-install from scratch''.
> 
> Search the mailing list archives.
> 
> We have discussed this, in detail, quite recently.

Which mailing list ?

> COAS is a system which has something in common with your suggestions.

I went to a talk at the Linux-Kongress about COAS, and was reasonably
impressed.  I shall be discussing the implications on debian-policy.

> We opted for linuxconf, which also has something in common with our
> suggestions :-)

Who opted for linuxconf in which context ?  Technical policy decisions
are made on debian-policy.

Ian.


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

Re: libc6_2.0.7 release notes...

[Philip Hands]

I presume that there would be no question of this discussion even starting
if libc6 had already got an epoch of 1:

It's epoch would just have been bumped up to 2: and nobody would have noticed
the difference.

Since there is an implicit epoch of 0: on the front of all non-epoch versions,
we are really discussing which is best out of:

  1) Causing a SNAFU in the versions of an important package, one day before
 the beta release of 2.0, which is likely to cause problems for many people
 and work for several maintainers.

  2) Use the Epoch system for the purpose it was intended, and move libc6
 from version ``0:2.0.7pre'' to ``1:2.0.7''.

Please don't allow this package out of Incoming until the version number has 
been fixed.

Cheers, Phil.

P.S.  Perhaps we should change policy, to ask people to explicitly include the 
0: epoch that is currently implicit, to avoid this sort of silliness in future.



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

Re: libc6_2.0.7 release notes...

[Rob Browning]

Santiago Vila <[EMAIL PROTECTED]> writes:

> But I believe that most of our users will agree that 2.0.7-1 is a much
> nicer version number than 2.0.7r-1 and would not mind to install a few
> packages by hand just *once*.

I don't agree.  We have a mechanism to allow clean upgrades.  We
should use it, and we should either change policy to not discourage
this, or we should come up with an alternate (but most likely
identical) mechanism for this purpose.

Which is better for the user, a README somewhere that they have to
read (presuming they actually realize that) and upgrading by hand, or
an epoch number that they'll probably never see, and an automatic
upgrade?

Being aesthetically opposed to epochs to the degree that you're
willing to force the user to upgrade manually seems unsupportable to
me.

-- 
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: More corrupted utmp/wtmp

[peloy]

Brandon Mitchell <[EMAIL PROTECTED]> wrote:

> I'm pretty sure this is the fault of xterm.  After a logout, it does this.
> Do an ldd on ssh before rebuilding.

Uhhmmm... I don't really know whose fault is this. This weekend I did
a fresh install (using Enrique's 2nd 2.0.7 boot floppies pre-release)
and installed a minimum X system
(xbase+xserver+fonts+xcontrib+fvwm95).

I haven't seen the utmp/wtmp corruption at any time...

I wonder what else it could be...

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: Release management - technical

[Craig Sanders]

On Mon, 22 Jun 1998, Ian Jackson wrote:

> We should continue to have `long term goals', and I applaud people who
> work towards them, but we must be able to make a release even when
> they are not met.  It is better to have a release now and goals later
> than no release now and goals later !

and

> In future, we should make releases _without regard to long term
> goals_.  Since we have to be incrementally-upgradeable, long term
> goals can be achieved just as easily out of step with releases.

i (mostly) agree. debian's upgradeability is one of it's best features,
and it is a feature which isn't matched by any other distribution...at
least, not to the same extent.

i've long believed that debian is a "live" distribution, and the best
way to use it is to regularly (i.e. every week or two) upgrade to the
latest unstablethis has worked for me for the last few years, and
the only time i got "bitten" by a new bug enough to swear about it was
when fmirror got upgraded to a bad alpha version and blew away my debian
mirror (an expensive mistake at $0.19/megabyte).

that's why i think we should have monthly untested snapshot CDs of
unstable as well as regular tested official releasesso that those
who don't have good net connections can benefit from debian's live
nature.


anyway, what i really wanted to say here was that sometimes releases
do have to be delayed to meet some goals. i think that the upgrade to
libc6 was one of them (but i think hamm met that goal around August or
September last year, and could have been released anytime after that).

I suspect that another such goal will be PAMit doesn't do much good
to have half a PAM-enabled system.  For PAM, we need all the typical
login authentication stuff linked against PAM and we also need PAMified
versions of sendmail, smail, etc so that mail can be delivered for users
who only exist in a radius or LDAP directory and not in /etc/passwd.


craig

--
craig sanders


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

Re: libc6_2.0.7 release notes...

[Craig Sanders]

On Mon, 22 Jun 1998, Santiago Vila wrote:

> If there is something to solve here, "2.0.7r" would be a better
> solution, IMHO, because at least it would allow us to get rid of both
> the epoch and the "r" thing in "2.0.8".

this seems like a good compromise solution to the problem. it fixes the
technical problem and doesn't offend those who find epochs uglyand
as santiago says, the minor ugliness of having "r" in the version will
disappear with the next libc6 release.

craig

--
craig sanders


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

Re: Constitution, and SPI section s.9

[Dale Scheetz]

We have yet to see, or even hear about the charter for SPI. Those who have
attempted to get such information from the State of New York, have been
told this document is not available. It is my understanding that such
charters of incorporation are public knowledge and should be freely
available.

Other hearsay indicates that you (Ian) have a copy of this document, and
may even have read it ;-)

I am deeply concerned about making statements in the Debian Constitution
with respect to an "undefined" SPI corporate entity.

SPI, through its appointed spokesperson (also undeclared), has made no
attempt to clear up this lack of information, and so far neither have you,
Ian, in either your position as leader, or that of an SPI boardmember.

I am not in favor of voting on the Constitution until I have heard quite a
bit more about what SPI thinks it is supposed to be about.

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: Release management - technical

[Meskes, Michael]

> Why? We could have both versions of these programs around for some
> time.
> For instance we add a login-pam package so whoever wants can work with
> it. Once all packages have their -pam package we can switch over to
> fully pam support. 
> 
> Or we could put the pam aware packages into experimental.
> 
> Michael
> 
> --
> Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH
> [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
> [EMAIL PROTECTED]  | 52146 Wuerselen
> Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
> Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10
> 
> > -Original Message-
> > From:   Craig Sanders [SMTP:[EMAIL PROTECTED]
> > Sent:   Monday, June 22, 1998 4:17 PM
> > To: Ian Jackson
> > Subject:Re: Release management - technical
> > 
> > anyway, what i really wanted to say here was that sometimes releases
> > do have to be delayed to meet some goals. i think that the upgrade
> to
> > libc6 was one of them (but i think hamm met that goal around August
> or
> > September last year, and could have been released anytime after
> that).
> > 
> > I suspect that another such goal will be PAMit doesn't do much
> > good
> > to have half a PAM-enabled system.  For PAM, we need all the typical
> > login authentication stuff linked against PAM and we also need
> > PAMified
> > versions of sendmail, smail, etc so that mail can be delivered for
> > users
> > who only exist in a radius or LDAP directory and not in /etc/passwd.
> > 
> > 
> > craig
> > 
> > --
> > craig sanders
> > 
> > 
> > --  
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact
> > [EMAIL PROTECTED]


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

Re: Constitution, and SPI section s.9

[Ian Jackson - Debian Project Leader]

Dale Scheetz writes ("Re: Constitution, and SPI section s.9"):
> We have yet to see, or even hear about the charter for SPI. Those who have
> attempted to get such information from the State of New York, have been
> told this document is not available. It is my understanding that such
> charters of incorporation are public knowledge and should be freely
> available.
> 
> Other hearsay indicates that you (Ian) have a copy of this document, and
> may even have read it ;-)

I have a paper copy, and have skimread it.

> I am deeply concerned about making statements in the Debian Constitution
> with respect to an "undefined" SPI corporate entity.

I can quite understand this concern.

> SPI, through its appointed spokesperson (also undeclared), has made no
> attempt to clear up this lack of information, and so far neither have you,
> Ian, in either your position as leader, or that of an SPI boardmember.

I've asked Tim et al for an electronic copy, but they don't have one.
I've now asked if it would be OK for me to scan in my paper copy.

> I am not in favor of voting on the Constitution until I have heard quite a
> bit more about what SPI thinks it is supposed to be about.

I think the articles of incorporation should answer that question for
you.

Ian.


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

Re: Constitution, and SPI section s.9

[Ian Jackson - Debian Project Leader]

Ian Jackson - Debian Project Leader writes ("Re: Constitution, and SPI section 
s.9"):
...
> I've asked Tim et al for an electronic copy, but they don't have one.
> I've now asked if it would be OK for me to scan in my paper copy.

... and he has said he does not object.  So, given that two of the
board agree I shall do this tomorrow.  (I don't have them here with
me.)

Thanks,
Ian.


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

need help from Korean users of Debian

[James A . Treacy]

The contact I have for the Debian web mirror (www.kr.debian.org)
is Lee, Ho-sun <[EMAIL PROTECTED]>. He has not answered
any of the mail I've sent him in the last 6 months and I am hoping
that one of the Korean users of Debian know him or anybody else
that works on www.kr.debian.org (134.75.7.22).

There will be some changes made to the Debian web site in the
near future and they will break this mirror unless they make a
modification to their web server. I would dislike having to
drop the Korean mirror, but this will be my only option unless
I can get this resolved.

Jay Treacy


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

Re: libc6_2.0.7 release notes...

[Dale Scheetz]

On 22 Jun 1998, Rob Browning wrote:

> Santiago Vila <[EMAIL PROTECTED]> writes:
> 
> > But I believe that most of our users will agree that 2.0.7-1 is a much
> > nicer version number than 2.0.7r-1 and would not mind to install a few
> > packages by hand just *once*.
> 
> I don't agree.  We have a mechanism to allow clean upgrades.  We
> should use it, and we should either change policy to not discourage
> this, or we should come up with an alternate (but most likely
> identical) mechanism for this purpose.

I agree in general, but not in this specific case.

> 
> Which is better for the user, a README somewhere that they have to
> read (presuming they actually realize that) and upgrading by hand, or
> an epoch number that they'll probably never see, and an automatic
> upgrade?
> 
Everyone doing an upgrade this go 'round is going to have to be appraised
of the packages to install "by hand" in any case, so this doesn't "add"
another step, it just uses the step we are already being forced to take,
as a way to avoid additional mess.

> Being aesthetically opposed to epochs to the degree that you're
> willing to force the user to upgrade manually seems unsupportable to
> me.

Policy says I should not use epochs to resolve prelease numbering
problems. (So what good is this thing anyway?)

Phil's suggestion that this "uggly" epoch implicitly exists on every
package version. I'm not sure I like the distinctive clutter that that
will impose on a Debian distribution.

There has got to be a better way to deal with this problem (which is
fundamentally a sorting problem).

Santiago's suggestion of 2.0.7r-1 is more satisfying but, if you consider
the situation, doesn't really resolve the long term problem any better.

What we need here is a better way of dealing with this problem. My mind
has no solution at the moment, but my gut says that there is one, so I
will keep looking.

The reason I think this is a continuing problem is that the next round of
glibc development is just a likely to run through several "preX" versions
before a release is made. There is a strong advantage in our participation
in the testing of these pre-releases (just as our users gain benefit from
pre-release testing of packages). I would suggest that we would not have a
2.0.7 to be arguing about if we had not used and reported problems with
the pre-release versions. What we need is a way to use these pre-release
versions without having their version numbering effect the archives.

In the mean time, unless anyone can object within the next several hours,
I will construct and upload a new release of glibc with the version
number: 2.0.7r-1

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: libc6_2.0.7 release notes...

[Vincent Renardias]

On Mon, 22 Jun 1998, Dale Scheetz wrote:

> In the mean time, unless anyone can object within the next several hours,
> I will construct and upload a new release of glibc with the version
> number: 2.0.7r-1

IMHO, it's the best compromise...
In the long term, instead of modifying dpkg, why not simply change the
version number, in case this happens again. ie: if pre-2.0.8 or 2.0.8alpha
appears, why not number the Debian package as 2.0.7.99.0?
Or in case of snapshots numbered with the release date, prepend "0.0." as
prefix. For example, wine-980614 becomes wine-0.0.980614, so even if they
stop the current numbering scheme and start "real release numbering",
epochs will not be necessary...

Cordialement,

-- 
- 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]

Re: libc6_2.0.7 release notes...

[Adam Klein]

On Mon, Jun 22, 1998 at 11:14:54AM -0400, Dale Scheetz wrote:
[snip]
> > Being aesthetically opposed to epochs to the degree that you're
> > willing to force the user to upgrade manually seems unsupportable to
> > me.
> 
> Policy says I should not use epochs to resolve prelease numbering
> problems. (So what good is this thing anyway?)

I've always read that section to mean that you shouldn't use pre-release
numbering to begin with.

Adam Klein


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

Re: libc6_2.0.7 release notes...

[Dale Scheetz]

On Mon, 22 Jun 1998, Vincent Renardias wrote:

> 
> On Mon, 22 Jun 1998, Dale Scheetz wrote:
> 
> > In the mean time, unless anyone can object within the next several hours,
> > I will construct and upload a new release of glibc with the version
> > number: 2.0.7r-1
> 
> IMHO, it's the best compromise...
> In the long term, instead of modifying dpkg, why not simply change the
> version number, in case this happens again. ie: if pre-2.0.8 or 2.0.8alpha
> appears, why not number the Debian package as 2.0.7.99.0?

I like this a lot better, even though it conflicts with the upstream
numbering, it is also pretty obvious what it means.

> Or in case of snapshots numbered with the release date, prepend "0.0." as
> prefix. For example, wine-980614 becomes wine-0.0.980614, so even if they
> stop the current numbering scheme and start "real release numbering",
> epochs will not be necessary...
> 
In both these examples the "cludge" only hangs around for a while, while
the epoch gets stuck on the version forever.

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: RFC: The BTS, "Severity: Fixed", etc. (Was: An idea for the BTS)

[Yann Dirson]

Santiago Vila writes:
 > > As I see it, the `Status' of a bug-report (I suggest at least: clear,
 > > reported, identified, known-workaround, known-fix, fixed) is an issue
 > > that is othogonal to the `Severity' (as used for now: wishlist,
 > > normal, important, grave, critical) - eg. the fact that a bug was
 > > fixed (eg. by a NMR) does not mean it is not important any more.
 > 
 > Hi. I *fully* agree with this.

Great ;)

 > I have not read your proposal in detail, but I think that a simple
 > three state "closed | fixed but not closed | open" would be enough for
 > now.

[I feel my reply to this is of general interest - I forward to the list]

Well, my additional states are mostly aimed at providing users (and
other developpers) documentation about bugs they may suffer from.  I
think we should encourage users to report bugs when the hit one, and
it is IMHO an important issue to let them new quickly about related
reports, without forcing them to get through all the thread when not
needed.

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


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

Re: Release management - technical

[Enrique Zanardi]

On Mon, Jun 22, 1998 at 01:38:21PM +0100, Ian Jackson wrote:
> Enrique Zanardi writes ("Re: Release management - technical"):
> > On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
> ...
> > > I think we can only do one of these.  With hamm we're doing the
> > > latter; in the future I think we should do the former.
> > 
> > Fine, as long as we have some "long term goals" that must be achieved,
> > better sooner than later (FHS compliance, for example).
> 
> NO!  Absolutely not, if you're going to say `must be achieved'.
> 
> I read `must be achieved' to mean `we will delay the release if these
> are not achieved'.

Oops. That's not what I wanted to express. Long-term goals shouldn't
delay the release. 

> We are a volunteer organisation, and the last 13 months have shown us
> that you can't guilt people into doing things.
> 
> We should continue to have `long term goals', and I applaud people who
> work towards them, but we must be able to make a release even when
> they are not met.  It is better to have a release now and goals later
> than no release now and goals later !

I agree. An example of "long term goal" is "apt". We want to substitute
dselect with apt eventually, and there is a group of volunteers working
towards it, but that goal won't delay hamm's release..
 
--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: Constitution, and SPI section s.9

[Branden Robinson]

On Mon, Jun 22, 1998 at 03:58:53PM +0100, Ian Jackson - Debian Project Leader 
wrote:
> Dale Scheetz writes ("Re: Constitution, and SPI section s.9"):
> > We have yet to see, or even hear about the charter for SPI. Those who have
> > attempted to get such information from the State of New York, have been
> > told this document is not available. It is my understanding that such
> > charters of incorporation are public knowledge and should be freely
> > available.
[...]
> I've asked Tim et al for an electronic copy, but they don't have one.
> I've now asked if it would be OK for me to scan in my paper copy.

Asked?  If what Dale says is correct, and I believe it is, you don't have
to ask.

-- 
G. Branden Robinson |
Purdue University   |  Exercise your freedom of religion.  Set
[EMAIL PROTECTED]  |  fire to a church of your choice.
http://www.ecn.purdue.edu/~branden/ |


pgpTCN6fvFjo9.pgp
Description: PGP signature

Re: Constitution, and SPI section s.9

[Dale Scheetz]

On Mon, 22 Jun 1998, Ian Jackson - Debian Project Leader wrote:

> Ian Jackson - Debian Project Leader writes ("Re: Constitution, and SPI 
> section s.9"):
> ...
> > I've asked Tim et al for an electronic copy, but they don't have one.
> > I've now asked if it would be OK for me to scan in my paper copy.
> 
> ... and he has said he does not object.  So, given that two of the
> board agree I shall do this tomorrow.  (I don't have them here with
> me.)
> 
Great! I believe we are all interested in the content of this document.

Much appreciated,

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: libc6_2.0.7 release notes...

[Rob Browning]

Dale Scheetz <[EMAIL PROTECTED]> writes:

> Everyone doing an upgrade this go 'round is going to have to be appraised
> of the packages to install "by hand" in any case, so this doesn't "add"
> another step, it just uses the step we are already being forced to take,
> as a way to avoid additional mess.

Not if they use autoup.sh or apt, but I suppose that the readme that
tells them about that could also mention the libc6 problem.
Regardless, the 2.0.7r thing seems OK (though it's somewhat a matter
of which bugs you more X:version or 2.0.7r), so much of the rest of
this is just academic.

2.0.7r makes this irrelevant now, but one other consideration would
have been all of those who have been following unstable or frozen and
have already "upgraded" the other set of "by hand" packages.  How
would you make sure they bother to read a README that appears to cover
things they think they already did?

And I'd really rather not have to remember to upgrade libc6 manually
on 7 different machines at 3 different locations when my next dselect
run could have just "remembered" it for me.  I'm sure it's even more
annoying for people with more machines.  "By hand" upgrades are a
failure point we shouldn't create when we know how to avoid it.

> There has got to be a better way to deal with this problem (which is
> fundamentally a sorting problem).

We can't cover all cases without something like epochs if we're going
to allow the upstream authors to choose their version numbers.  Heck,
some loon could choose something like:

  1.0-good
  1.0-better
  1.0-best

For this reason the suggestion that we just make dpkg understand pre,
alpha, beta, etc. is doomed to failure.  And, of course, instead of
alpha and beta some just use a and b.  I've even seen gamma, and I
know one organization that uses GM for (Golden Master) as the final
release candidate.

> What we need here is a better way of dealing with this problem. My mind
> has no solution at the moment, but my gut says that there is one, so I
> will keep looking.

Good luck.  It would be great if you come up with one, but I fear it's
going to be a lot of work for essentially a *really* minor aesthetic
gain.

One way this could almost be handled is with and additional control
file where you could list sort exceptions.  Something like this:

  2.0.7pre1 < 2.0.7
  2.0.8pre7 < 2.0.8

etc.  This file would allow each discontinuity to be specified, and
would be pretty flexible, but it still has the problem (that epoch's
don't) that if the upstream authors do something really weird you're
still out of luck.  The problem is that these rules aren't (time)
context sensitive.

Consider some author releasing:

  2.0
  2.1
  3.0
  1.0
  2.0

This is essentially a version renumbering (perhaps to match some other
package, or whatever).  In this case, the exceptions list wouldn't
help because you'd still think the later 2.0 was equivalent to the
earlier 2.0 if.  Here, something like epochs are needed.

> The reason I think this is a continuing problem is that the next
> round of glibc development is just a likely to run through several
> "preX" versions before a release is made. There is a strong
> advantage in our participation in the testing of these pre-releases
> (just as our users gain benefit from pre-release testing of
> packages). I would suggest that we would not have a 2.0.7 to be
> arguing about if we had not used and reported problems with the
> pre-release versions. What we need is a way to use these pre-release
> versions without having their version numbering effect the archives.

Oh, I don't think anyone's arguing against that, but if it were up to
me, I'd just say we should use epochs and get on to more interesting
problems.

> In the mean time, unless anyone can object within the next several hours,
> I will construct and upload a new release of glibc with the version
> number: 2.0.7r-1

Sounds good.

-- 
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: More corrupted utmp/wtmp

[Brandon Mitchell]

On 22 Jun 1998 [EMAIL PROTECTED] wrote:

> Brandon Mitchell <[EMAIL PROTECTED]> wrote:
> 
> > I'm pretty sure this is the fault of xterm.  After a logout, it does this.
> > Do an ldd on ssh before rebuilding.
[ Note that this was my stupidity since the user said they weren't running
  an xterm, but now on to another thing... ]

> Uhhmmm... I don't really know whose fault is this. This weekend I did
> a fresh install (using Enrique's 2nd 2.0.7 boot floppies pre-release)
> and installed a minimum X system
> (xbase+xserver+fonts+xcontrib+fvwm95).
> 
> I haven't seen the utmp/wtmp corruption at any time...

I've got xbase 3.3.2.1-1.  Try to open an xterm, check the output of last,
all should be ok:
bhmit1   ttypahobbes:11.0  Mon Jun 22 13:21   still logged in

Now, exit the xterm:
p*** [EMAIL PROTECTED],*@  [EMAIL PROTECTED]Mon Jun 22 13:21   
still logged in
bhmit1   ttypahobbes:11.0  Mon Jun 22 13:21   still logged in

This may have been fixed by the latest libc6 (according to the x
maintainers web page), but I'm waiting for the version number debate to
end before up(down)grading.

Can you verify this on a fresh install?
Brandon

--+--
Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status
PGP Key:   finger -l [EMAIL PROTECTED] |  http://bhmit1.home.ml.org/deb/
Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)


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

Re: libc6_2.0.7 release notes...

[Dale Scheetz]

On 22 Jun 1998, Rob Browning wrote:

> Good luck.  It would be great if you come up with one, but I fear it's
> going to be a lot of work for essentially a *really* minor aesthetic
> gain.
> 
> One way this could almost be handled is with and additional control
> file where you could list sort exceptions.  Something like this:
> 
>   2.0.7pre1 < 2.0.7
>   2.0.8pre7 < 2.0.8
> 

I like Santiago's suggestion better:

2.0.8pre1 => 2.0.7.99.1
2.0.8pre2 => 2.0.7.99.2
  :
2.0.8 => 2.0.8

Which scales properly and solves the problem.

> etc.  This file would allow each discontinuity to be specified, and
> would be pretty flexible, but it still has the problem (that epoch's
> don't) that if the upstream authors do something really weird you're
> still out of luck.  The problem is that these rules aren't (time)
> context sensitive.
> 
> Consider some author releasing:
> 
>   2.0
>   2.1
>   3.0
>   1.0
>   2.0
> 
> This is essentially a version renumbering (perhaps to match some other
> package, or whatever).  In this case, the exceptions list wouldn't
> help because you'd still think the later 2.0 was equivalent to the
> earlier 2.0 if.  Here, something like epochs are needed.
> 
Yes! Now I remember! This is what the epochs are for, and the reason that
they MUST exist forever after. Also a reason not to use them in this case.

Thanks for the reminder!

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: New gnome packages

[Jim Pick]

Michael Meskes <[EMAIL PROTECTED]> writes:

> Am I correct that we currently do not have a complete desktop with gnome?
> Since there is no wm yet, it's pretty difficult to judge it.

This is a Gnome FAQ item.

Gnome is not meant to have a single window manager.  In it's final
form, it will work with any window manager.  There is the beginnings
of a specification for what needs to be done to a window manager for
it to be Gnome compliant.  

I suspect that icewm, scwm, and enlightenment will be gnome-compliant
window managers, as their developers are also gnome developers.

> Also it seems some libraries/binaries are compiled with debug flags set. For
> intance I got this when using gnome-terminal:
> 
> ** WARNING **: gnome_message_box_set_modal is deprecated.
> 
> $ [l,1,1]
> [s,1,1]
> ,1,1]
> [e,1,1]
> [x,1,1]
> [i,1,1]
> [t,1,1]
> ,1,1]
> errno = 0, saverrno = 5
> out of data on read

The first part of that is a failed assertion -- basically, it means
the underlying API was changed.  The rest of it looks like a bug.

The Gnome 0.20 release is essentially a snapshot release (alpha
quality at that), and it has not undergone a rigourous testing cycle
upstream.  So I'm expecting lots of bugs like this.

I wouldn't go to great lengths trying to report bugs like this, as
they have probably already been corrected upstream, as Gnome is under
very active development.

I've mentioned that it is alpha-quality code in the README, and it's
definitely not ready for general consumption (ie. the stable Debian
release)

> Finally there is one incorrect dependency. gnome-utils depend on
> libobgtk0 but there is only libobgtk1

Oops.  My mistake.  I'll upload a fixed version right away.  In the
meantime, using dpkg --force-depends should work.

Cheers,

 - Jim



pgpYSmD1vHTiz.pgp
Description: PGP signature

Re: New gnome packages

[B. Bell]

start up X
type "panel &"
if you're impressed, put it in your .xsession

On Mon, 22 Jun 1998, Michael Meskes wrote:

> B. Bell writes:
> > be sure to check out the panel... it's cool.
> > -brad
> 
> Nice to hear that. But unless I get a description of how to use gnome I
> won't even try. I don't have the time to play around with it. That's what I
> like with kde. You install it and you use it. I installed gnome, but have no
> idea of how to use it.
> 
> Michael
> 
> -- 
> Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH
> [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
> [EMAIL PROTECTED]  | 52146 Wuerselen
> Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
> Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10
> 



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

Re: gnome again

[Jim Pick]

"Meskes, Michael" <[EMAIL PROTECTED]> writes:

> Okay, I tried starting icewm and then some gnome applets resp. some of
> the desktop tools. But they all seg fault. And I get a message that
> imlib is lacking the file in /usr/etc. Do I have to set an environment
> variable?
> 
> I think we should add a README explaining how to use gnome to the
> packages.

That doesn't happen to me.

Which version of imlib are you using?  

You shouldn't have to configure anything to use the gnome applications
- it should just work.  If it doesn't, then there are some bugs I need
to fix.

Oh!  One thing I forgot to mention in my announcement was that if you
were using gnome 0.12 -- you really need to remove your ~/.gnome
directory and start off fresh.  I suspect that is where you might be
having some problems.

I should probably add that to the README - and maybe a note to try
running "panel" to get to all the other applications.  Anything else I
should put into the README?

Cheers,

 - Jim



pgpysJiBsjR6M.pgp
Description: PGP signature

Re: libc6_2.0.7 release notes...

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 22 Jun 1998, Dale Scheetz wrote:

> I like Santiago's suggestion better:
> 
>   2.0.8pre1 => 2.0.7.99.1
>   2.0.8pre2 => 2.0.7.99.2
> :
>   2.0.8 => 2.0.8
> 
> Which scales properly and solves the problem.

Mmm, well, this was actually suggested by Vincent Renardias, but yes, I
also like this proposal :-). I used a similar approach for procmail and
smartlist (only similar, because I don't have a "99"), with a
clarification about the version number in the extended description.

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

iQCVAgUBNY6fpyqK7IlOjMLFAQE8YQP/d/fc/BbDnxXjzir/6/3FjHslZSfi7x3K
p+46sPpVFU2+WNhG/vnK5eCiMBInzhqGQI7cYVqVITiw2qadEVdSkLSUhaRBtD2q
TVzMhSMX31+TyJAZbKDN2lqK5200hdB4x4uIE0RMf+MqGHGgSHokn2vC6n3i/GHO
4s2jzm9WSeg=
=Xs48
-END PGP SIGNATURE-


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

Re: libc6_2.0.7 release notes...

[Dale Scheetz]

On Mon, 22 Jun 1998, Santiago Vila wrote:

> -BEGIN PGP SIGNED MESSAGE-
> 
> On Mon, 22 Jun 1998, Dale Scheetz wrote:
> 
> > I like Santiago's suggestion better:
> > 
> > 2.0.8pre1 => 2.0.7.99.1
> > 2.0.8pre2 => 2.0.7.99.2
> >   :
> > 2.0.8 => 2.0.8
> > 
> > Which scales properly and solves the problem.
> 
> Mmm, well, this was actually suggested by Vincent Renardias, but yes, I
> also like this proposal :-). I used a similar approach for procmail and
> smartlist (only similar, because I don't have a "99"), with a
> clarification about the version number in the extended description.
> 
Thank you for the correction. This is a good idea and the right person
should get the blame/credit ;-)

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: libc6_2.0.7 release notes...

[G John Lapeyre]

Let's not add more complication to the installation of the
distribution which is perceived to be difficult to install.  Remember,
doing a few things by hand is a much bigger pain for a busy sysadmin who
is less experienced with Debian than the developers.  I see a lot of
developer-centric opinions on this list. 

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: where is sed in slink?

[Joey Hess]

Carey Evans wrote:
> I don't think slink is supposed to have all the links into hamm yet,
> is it?

I thought I convinced Guy about 2 months ago to make those links. Guess I
was mistaken.

-- 
see shy jo


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

Intent to package: csound & cecillia

[Marco Budde]

Hi!

I would like to package csound and cecillia. Any comments?

cu, Marco

--
Uni: [EMAIL PROTECTED]   Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


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

Re: libc6_2.0.7 release notes...

[Rob Browning]

Santiago Vila <[EMAIL PROTECTED]> writes:

> I used a similar approach for procmail and smartlist (only similar,
> because I don't have a "99"), with a clarification about the version
> number in the extended description.

Having the clarification in the extended description removes my final
(minor and previously unvoiced) objection to this scheme.  It might
even be worth working all this up for potential inclusion in policy
(if we ever get a policy manager again :> )

-- 
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: gnome again

[Rob Browning]

Jim Pick <[EMAIL PROTECTED]> writes:

> I should probably add that to the README - and maybe a note to try
> running "panel" to get to all the other applications.  Anything else I
> should put into the README?

I don't know about the README, but I just noticed that after I
installed libgnome0, the hello programs died with shared lib problems
until I ran ldconfig.

I don't know if policy's been updated, but contrary to what it used to
say you need a call in one of the install scripts (the postinst, I
believe).

-- 
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: libc6_2.0.7 release notes...

[Adam P. Harris]

Dale Scheetz <[EMAIL PROTECTED]> writes:
> On 22 Jun 1998, Rob Browning wrote:
> > Good luck.  It would be great if you come up with one, but I fear it's
> > going to be a lot of work for essentially a *really* minor aesthetic
> > gain.
> > 
> > One way this could almost be handled is with and additional control
> > file where you could list sort exceptions.  Something like this:
> > 
> >   2.0.7pre1 < 2.0.7
> >   2.0.8pre7 < 2.0.8
> > 
> 
> I like Santiago's suggestion better:
> 
>   2.0.8pre1 => 2.0.7.99.1
>   2.0.8pre2 => 2.0.7.99.2
> :
>   2.0.8 => 2.0.8
> 
> Which scales properly and solves the problem.

No, it doesn't solve our *immediate* problem (unless I don't
understand you).

PLEASE PLEASE PLEASE!  Do not cause hell on Debian by asking people to
upgrade libc by hand if they're already running hamm.  A good
percentage of Debian users (not just developers) are already running
hamm.  Why should we have this academic discussion.  Just use epochs,
use 2.0.7r, use *something*.

Again, I really think asking people to upgrade libc by hand in case
they're already using 2.0.7 is unacceptable.

  * It's going to make Debian look bad (i.e., what kinda crappy
pacakging system is that, grumble grumble).

  * I don't care how heavily you advertise, people won't read it and
won't do it and pacakge maintainers are going to have to deal with
people sticking on the old libc6 2.0.7 pre.

  * Installation instructions are going to break, i.e., you can't keep
your machine up-to-date just using apt

  * versioned depends are going to break (if any exist)

Geeze!  You want to have all this pain and suffering just because you
think epoch's or 2.0.7r is "clutter"??  What clutter?  It's just a
number in a changelog; users don't even see it!

BTW, Dale, thanks for the great work getting this out.

-- 
.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


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

Re: RFC: The BTS, "Severity: Fixed", etc. (Was: An idea for the BTS)

[Rob Browning]

Yann Dirson <[EMAIL PROTECTED]> writes:

> [Note: I don't know much about the internals of the BTS; I hope this
> will be accurate enough, though]
> 
> * These fields would be named by the codename of the dist
> (eg. `hamm_status') - can this be achieved easily ?

Why not just go with something more heirarchical like:

  Status: (hamm fixed) (bo known-workaround)

etc.  That way we don't have a potentially ever growing number of
fields, just field contents...

-- 
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: gnome again

[Jim Pick]

Rob Browning <[EMAIL PROTECTED]> writes:

> Jim Pick <[EMAIL PROTECTED]> writes:
> 
> > I should probably add that to the README - and maybe a note to try
> > running "panel" to get to all the other applications.  Anything else I
> > should put into the README?
> 
> I don't know about the README, but I just noticed that after I
> installed libgnome0, the hello programs died with shared lib problems
> until I ran ldconfig.
> 
> I don't know if policy's been updated, but contrary to what it used to
> say you need a call in one of the install scripts (the postinst, I
> believe).

Strange.  The released version of libgnome0 has a call to ldconfig in
the postinst.  I put it in there because lintian was nice enough to
complain.

Perhaps you were using the pre-release one I put out a week and a half
ago?  Unfortunately, I didn't increment the version number from the
pre-release to the released ones.

Cheers,

 - Jim




pgpHOWoVIHy4Z.pgp
Description: PGP signature

Re: Intent to package: csound & cecillia

[Ole J. Tetlie]

* [EMAIL PROTECTED] (Marco Budde)
|
| Hi!
| 
| I would like to package csound and cecillia. Any comments?

What are they? (I can at least guess csound :-)

-- 
Ole


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

Re: libc6_2.0.7 release notes...

[Rob Browning]

[EMAIL PROTECTED] (Adam P. Harris) writes:

> A good percentage of Debian users (not just developers) are already
> running hamm.  Why should we have this academic discussion.  Just
> use epochs, use 2.0.7r, use *something*.

I believe Dale's already decided to use 2.0.7r.

-- 
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: Release management - technical

[Grant Bowman]

At 5:38 AM -0700 6/22/98, Ian Jackson wrote:
>David Engel writes ("Re: Release management - technical"):
>> On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
>> > Q. What are we trying to achieve ?
>> >
>> > A. There are two possibilities that I can see
>> > - Timely and good-quality releases, or
>> > - Releases which meet some predefined set of goals.
>> >
>In future, we should make releases _without regard to long term
>goals_.  Since we have to be incrementally-upgradeable, long term
>goals can be achieved just as easily out of step with releases.

Timeliness and good-quality are definately seperate goals, as any QA
manager will attest to.

Regards,

--
-- Grant Bowman   <[EMAIL PROTECTED]>



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

Re: gnome again

[Rob Browning]

Jim Pick <[EMAIL PROTECTED]> writes:

> Perhaps you were using the pre-release one I put out a week and a half
> ago?  Unfortunately, I didn't increment the version number from the
> pre-release to the released ones.

Ahh, that might be it.

And slap your wrist.  Not incrementing the version number after
*every* change is a *big* no-no :>

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: libc6_2.0.7 release notes...

[Dale Scheetz]

On 22 Jun 1998, Rob Browning wrote:

> [EMAIL PROTECTED] (Adam P. Harris) writes:
> 
> > A good percentage of Debian users (not just developers) are already
> > running hamm.  Why should we have this academic discussion.  Just
> > use epochs, use 2.0.7r, use *something*.
> 
> I believe Dale's already decided to use 2.0.7r.
> 
It is in Incoming now,

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: libc6_2.0.7 release notes...

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

It's too bad upstream developers are so diverse in their attitudes about how
to number things... such that we have to deal with stuff like this.  However,
that's a fact of life.

:   2) Use the Epoch system for the purpose it was intended, and move libc6
:  from version ``0:2.0.7pre'' to ``1:2.0.7''.

I agree completely.  If "the policy" says that using epochs to solve version
numbering problems caused by prerelease versions is wrong, then the policy is
in error, or at least misleading.  

It would be completely appropriate for policy to suggest that using 
pre-release numbering for the upstream version is wrong in a Debian package...
but once a package is numbered that way and out in the hands of users, the 
epoch mechanism is the *least* ugly way of fixing the problem.  We should 
not be afraid to use it when we need it.  I will certainly continue to do so
in packages that I adopt.

I personally think this ".99." stuff is really ugly.  It is much better, I 
think, to do something like

2.0.7   ->  2.0.7-n where ( n >= 1 )
2.0.8pre1   ->  2.0.8-0pre1
2.0.8   ->  2.0.8-n where ( n >= 1 )

So, in the present case, I'd bump the epoch to 1 this time, and then use
something like the above to avoid needing to bump it again if the upstream
version numbering continues to sort out of order.  

But, I'm willing to admit that this is an issue of aesthetics, which means 
we will never all agree on what to do...  as long as *zero* manual package
handling is required to follow the proper sequencing of package versions, any
solution that works is acceptable to me.

Bdale


--  
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

[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: premature closing of bugs

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: I was looking at the list of release-critical bugs and noticed some bugs
: were closed. A lot of those closed bugs are for packages that are still
: sitting in Incoming. I would like to remind people that you have to wait
: with closing a bug until the fixed package is installed. Closing a bug
: before that moment creates the illusion that release-critical bugs are
: fixed in the distribution. And Incoming is not a part of the distribution..

While you are quite correct, I believe that the only reasonable fix for this 
problem is to complete the adoption and implementation of one of the 
mechanisms to cause the tools on master to close bugs indicated in the 
changes as being closed by a given upload.  

As a package maintainer, once I've fixed the bug in my source tree and
uploaded the fix, I really don't want to have to think about that bug again.
In the current system, that means that I almost always close bugs once I've
successfully completed the upload, rightly or wrongly.  Maybe I should be
re-assigning them to ftp.debian.org?  1/2 :-)

Bdale


--  
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: premature closing of bugs

[Wichert Akkerman]

Previously Bdale Garbee wrote:
> While you are quite correct, I believe that the only reasonable fix for this 
> problem is to complete the adoption and implementation of one of the 
> mechanisms to cause the tools on master to close bugs indicated in the 
> changes as being closed by a given upload.  

I seem to remember we decided once to let the script that does the real
installation in the ftp-tree (dinstall) clos the bugs and defined a syntax
to use in the changelog so dinstall can recognize which bugs should be
closed. So now we just have to wait until someone decides to implement
this.

We might want to refine this procedure first though, since it's not
really suited for multiple-distributions.

> As a package maintainer, once I've fixed the bug in my source tree and
> uploaded the fix, I really don't want to have to think about that bug again.

Me too. However I stumble across these premature closed bugs
when I'm updating the Hamm Bug Stamp-Out List: a lot of bugs suddenly
disappear, and the packages are still in Incoming. Luckily these processed
were processed before I got around to sending the list :)

Wichert. (who's really going to sleep now)

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


pgpRPXkFFWD7G.pgp
Description: PGP signature

Re: RFC: The BTS, "Severity: Fixed", etc. (Was: An idea for the BTS)

[Manoj Srivastava]

Hi,

I think that not only should bugs be marked by the
 distributions they exist in, they should also be classified by
 architecture; since it is quite possible for a bug to only exist in a
 specific arch. This opens to dor for arch specific maintainers; which
 is not a bad idea since the original maintainer may not have access
 to all the diffrent architectures supported.

manoj
-- 
 Always look over your shoulder because everyone is watching and
 plotting against you.
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]