Upcoming Debian Releases
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White [EMAIL PROTECTED]
This document was last modified at Time-stamp: 97/06/20 10:04:42 bcwhite
If you're replying about some of the ideas mentioned in this document, it is
often wise to change the subject to reflect that idea. This helps target
those people who are most likely to partake in discussions about it.
For each upcoming release, the name of the task and the person who has claimed
responsibility for it (or ??? if nobody) is listed. An asterisk (*) in front
means the job has yet to be completed and must be done before that release can
be made stable. A dash (-) in front means it has not yet been completed,
but if not completed in time will just be pushed to the next release. A
space means that the task has been completed.
Footnotes are indicated by [n] and give more information on that item.
If you know of packages that do not conform to any of these tasks, please
report it as a bug against those packages. If that task is marked as critical
(i.e. with an asterisk *), then please let me know and I will mark the bug
as critical.
Critical bugs are those that you would seriously consider delaying the
upcoming release or removing that package from the distribution because
they are not fixed.
Upcoming Dates
~~
June 30, 1997 Bug reports against all non-libc6 packages.
July 1, 1997Bugs older than 9 months will be marked as overdue.
July 15, 1997 All uploaded libraries must depend on libc6.
July 31, 1997 All uploaded packages must depend on libc6.
August 1, 1997 Bugs older than 8 months will be marked as overdue.
August 31, 1997 All packages depending on libc[45] will be moved to contrib.
September 1,'97 Bugs older than 7 months will be marked as overdue.
Thoughts
---
Hamm (Debian 2.0)
~
* All packages are in the new package format.
* All packages in main distribution are compiled with libc6.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs, ...).
* No a.out executables anymore.
* Remove --force-overwrite flag from dpkg defaults
* Much improved dpkg/dselect.
* Use PAM within authentication programs [13]
* Link shared libs against other shared libs instead of static [14]
* Official Debian logo chosen.
- Fix remaining overdue bugs ([EMAIL PROTECTED])
- Appropriate pkgs should call install-mime in postinst ([EMAIL PROTECTED])
- Convert remaining a.out packages (???)
- configuring so non-ASCII characters work (???) [9]
- Make all web servers apply to Web Standard (cf. Policy Manual)
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
- Packages to call update-menu in postinst ([EMAIL PROTECTED]) [11]
- Move config information from install scripts to cfgtool (???)
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
---
Footnotes
~
9 - One of the things that most people outside the US and UK have to deal
with is configuring everything so that non-ASCII characters and other
locale specific stuff works right. For example, bash needs a ~/.inputrc
so that you write åäö on the command line, instead of getting
beeps. Emacs needs some other stuff. -- Lars Wirzenius [EMAIL PROTECTED]
10 - /dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are
only going to be using one set of tty devices, you should be using
/dev/ttySxx.
/dev/cuaXX devices are different from /dev/ttySXX in two ways --- first
of all, they will allow you to open the device even if CLOCAL is not set
and the O_NONBLOCK flag was not given to the open device. This allows
programs that don't use the POSIX-mondated interface for opening
/dev/ttySxx devices to be able to use /dev/cuaXX to make outgoing phone
calls on their modem (cu stands for callout, and is taken from SunOS).
The second way in which /dev/cuaXX differs from /dev/ttySXX is that if
they are used, they will trigger a simplistic kernel-based locking
scheme: If /dev/ttySXX is opened by one or more processes, then an
attempt to open /dev/cuaXX will return EAGAIN. If /dev/cuaXX is opened
by one or more processes, then an attempt to open /dev/ttySXX will result
the open blocking until /dev/cuaXX is closed, and the carrier detect line
goes high.
While this will allow for simple lockouts between a user using a modem
for
Re: cu (was: Upcoming Debian Releases)
Just picking a nit. On Mon, 23 Jun 1997, Brian C. White wrote: [...](cu stands for callout, and is taken from SunOS). [...] -- Theodore Ts'o [EMAIL PROTECTED] Unless I'm mistaken (which has happened on occasion), cu stands for call unix and is taken from the name of a program from the uucp suite which is used to interactively dial out over serial links to other unix systmes. That program has been around for longer than SunOS (or Sun, for that matter). The debian uucp package provides /usr/bin/cu. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Santiago Vila Doncel [EMAIL PROTECTED] wrote: On Mon, 16 Jun 1997, Brian C. White wrote: August 31, 1997 All packages depending on libc4 or libc5 will be removed. This is too much strong. I would suggest to make their associated bug (the one saying it's still libc5) almost-critical instead. How about this: Have the policy dictate that no packages may be compiled against libc4/5, and then move any packages that don't comply with the policy to 'contrib'. I believe that one of the reasons for having 'contrib' is to contain packages that we -could- distribute, but which don't fully comply with Debian policy? Simply to get the package back into the main distribution might be enough incentive to get packages rebuilt against libc6. Any obscure packages that missed getting rebuilt would end up under contrib. In fact, just moving libc4 and 5 to contrib would force any depending packages to go in contrib, too, without having to change policy. --Charles Briscoe-Smith White pages entry, with PGP key: URL:http://alethea.ukc.ac.uk/wp?95cpb4 PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Wed, 18 Jun 1997, Charles Briscoe-Smith wrote: How about this: Have the policy dictate that no packages may be compiled against libc4/5, and then move any packages that don't comply with the policy to 'contrib'. I believe that one of the reasons for having 'contrib' is to contain packages that we -could- distribute, but which don't fully comply with Debian policy? I like this solution the best of all the migration suggestions. This keeps us from removing perfectly good libc5 packages, but makes it clear that they are no longer part of the main distribution. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Upcoming Debian Releases
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White [EMAIL PROTECTED]
This document was last modified at Time-stamp: 97/06/16 22:08:39 bcwhite
If you're replying about some of the ideas mentioned in this document, it is
often wise to change the subject to reflect that idea. This helps target
those people who are most likely to partake in discussions about it.
For each upcoming release, the name of the task and the person who has claimed
responsibility for it (or ??? if nobody) is listed. An asterisk (*) in front
means the job has yet to be completed and must be done before that release can
be made stable. A dash (-) in front means it has not yet been completed,
but if not completed in time will just be pushed to the next release. A
space means that the task has been completed.
Footnotes are indicated by [n] and give more information on that item.
If you know of packages that do not conform to any of these tasks, please
report it as a bug against those packages. If that task is marked as critical
(i.e. with an asterisk *), then please let me know and I will mark the bug
as critical.
Critical bugs are those that you would seriously consider delaying the
upcoming release or removing that package from the distribution because
they are not fixed.
Upcoming Dates
~~
June 30, 1997 Bug reports against all non-libc6 packages.
July 1, 1997Bugs older than 9 months will be marked as overdue.
July 15, 1997 All uploaded libraries must depend on libc6.
July 31, 1997 All uploaded packages must depend on libc6.
August 1, 1997 Bugs older than 8 months will be marked as overdue.
August 31, 1997 All packages depending on libc4 or libc5 will be removed.
September 1,'97 Bugs older than 7 months will be marked as overdue.
Thoughts
---
Hamm (Debian 2.0)
~
* All packages are in the new package format.
* All packages in main distribution are compiled with libc6.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs, ...).
* No a.out executables anymore.
* Remove --force-overwrite flag from dpkg defaults
* Much improved dpkg/dselect.
* Use PAM within authentication programs [13]
* Link shared libs against other shared libs instead of static [14]
* Official Debian logo chosen.
- Fix remaining overdue bugs ([EMAIL PROTECTED])
- Appropriate pkgs should call install-mime in postinst ([EMAIL PROTECTED])
- Convert remaining a.out packages (???)
- configuring so non-ASCII characters work (???) [9]
- Make all web servers apply to /usr/doc/debmake/webstandard-3.0
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
- Packages to call update-menu in postinst ([EMAIL PROTECTED]) [11]
- Move config information from install scripts to cfgtool (???)
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
---
Footnotes
~
9 - One of the things that most people outside the US and UK have to deal
with is configuring everything so that non-ASCII characters and other
locale specific stuff works right. For example, bash needs a ~/.inputrc
so that you write åäö on the command line, instead of getting
beeps. Emacs needs some other stuff. -- Lars Wirzenius [EMAIL PROTECTED]
10 - /dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are
only going to be using one set of tty devices, you should be using
/dev/ttySxx.
/dev/cuaXX devices are different from /dev/ttySXX in two ways --- first
of all, they will allow you to open the device even if CLOCAL is not set
and the O_NONBLOCK flag was not given to the open device. This allows
programs that don't use the POSIX-mondated interface for opening
/dev/ttySxx devices to be able to use /dev/cuaXX to make outgoing phone
calls on their modem (cu stands for callout, and is taken from SunOS).
The second way in which /dev/cuaXX differs from /dev/ttySXX is that if
they are used, they will trigger a simplistic kernel-based locking
scheme: If /dev/ttySXX is opened by one or more processes, then an
attempt to open /dev/cuaXX will return EAGAIN. If /dev/cuaXX is opened
by one or more processes, then an attempt to open /dev/ttySXX will result
the open blocking until /dev/cuaXX is closed, and the carrier detect line
goes high.
While this will allow for simple lockouts between a user using a modem
for callout
Re: Upcoming Debian Releases
-BEGIN PGP SIGNED MESSAGE- On Mon, 16 Jun 1997, Brian C. White wrote: August 31, 1997 All packages depending on libc4 or libc5 will be removed. This is too much strong. I would suggest to make their associated bug (the one saying it's still libc5) almost-critical instead. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBM6Z2hSqK7IlOjMLFAQGX5wP/XScvtXHhm6e55xsNp+eIoxGDKO9EONA2 iJBxJ/2RWhD1tjsdoaYLCbC8VcCtiRDj3HPQF/Xsx4VHGDRv1J/948IBPtMUIsKm 4CBFcUjAytjAaR++ItHyhZmE/SgvsNzcFTT24qWbYeMZ63fDcS/CR9f2nsjgbh3Q rT4NBlmr1PQ= =PUDF -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
[EMAIL PROTECTED] (Tom Lees) wrote on 09.06.97 in [EMAIL PROTECTED]: Well, it looks as we will have to agree to disagree. The file is not modified locally per s.e., just written locally in a Uh, there's no dots in per se. That's latin for by or in itself - per is by, and se is self. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On 7 Jun 1997, Kai Henningsen wrote: Or maybe you have forgotten how conffiles are actually handled: (old=original install, new=this install, current=possibly edited version) If old md5 = new md5, ignore new file (package unchanged) If old md5 = current md5, install new file (conffile was not edited) otherwise, prompt (both changed) Your change would mean that in case 2, dpkg would have to figure out how to put the variables from the old script into the new one. OK. I didn't make this clear. The point of the config-tool is to do this. The file is not modified locally per s.e., just written locally in a different way to the packaged version, because the config db is changed. To clear it up: for a script which holds values which are really housed in the configuration database, each line which is simply a copy of config db information has a special key on it (# nomd5sum or something) which tells dpkg not to include that line in its config-file md5sum. The config db tool has the job of updating the values on demand, from the config database, replacing the values in the script. Therefore, when a file gets upgraded, even if it is replaced with standard defaults from the package, the postinst calls the config tool telling it to copy the appropriate values into the file. We could have something like this in the postinst:- if [ -f /sbin/debian-configtool ]; then debian-configtool --import /default - --update-file /etc/my.script EOF mypkg/some_info=yes EOF fi Then /etc/my.script looks like:- #!/bin/sh SOME_VARIABLE=yes # configtool=yes (See my post to debian-admintool about the significance of /default). The point of making dpkg ignore config-tool lines is that they are not supposed to be modified separately from the config database locally. No, it doesn't. You forget that there are three md5 sums / file versions involved, not two - *even though you quote me explaining it*! Well, I already wrote a simple system that works like this in perl - and a modified version of md5sum which can do this. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
[EMAIL PROTECTED] (Tom Lees) wrote on 02.06.97 in [EMAIL PROTECTED]: On 30 May 1997, Kai Henningsen wrote: [EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in [EMAIL PROTECTED]: There are ways to avoid this. For example, modify dpkg not to include any line with config=yes in it in the md5sum of certain files. This is a troll, right? Wrong. Well, it should be. Or maybe you have forgotten how conffiles are actually handled: (old=original install, new=this install, current=possibly edited version) If old md5 = new md5, ignore new file (package unchanged) If old md5 = current md5, install new file (conffile was not edited) otherwise, prompt (both changed) Your change would mean that in case 2, dpkg would have to figure out how to put the variables from the old script into the new one. But, for a package which adds config info, the new md5 != the old md5. Therefore, it would ask! No. While the new md5 != the old, we still have the old = the current, and so dpkg will NOT ask, but silently upgrade. At least that's how it currently works, and also how it ought to work. I certainly don't want to be asked to upgrade a conffile that I never even looked at. non-cfgtool md5 != cfgtoolized md5: old md5 != new md5. local file not modified: update anyway to use new cfgtool version. local file modified: cfgtool md5 == cfgtool md5: old md5=new md5 local file not modified (enough) - install new THEN, update from cfg database. See, it does work. No, it doesn't. You forget that there are three md5 sums / file versions involved, not two - *even though you quote me explaining it*! MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Upcoming Debian Releases
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White [EMAIL PROTECTED]
This document was last modified at Time-stamp: 97/06/02 21:25:35 bcwhite
*** ***
*** Release of Bo is IMMANENT!!! ***
*** ***
*** Bo has undergone extensive testing and is now ready for release! ***
*** No new packages are being allowed into frozen. Uploads into ***
*** stable must have an extremely good reason to do so and must be ***
*** approved by the testing group before actually being installed. ***
*** ***
If you're replying about some of the ideas mentioned in this document, it is
often wise to change the subject to reflect that idea. This helps target
those people who are most likely to partake in discussions about it.
For each upcoming release, the name of the task and the person who has claimed
responsibility for it (or ??? if nobody) is listed. An asterisk (*) in front
means the job has yet to be completed and must be done before that release can
be made stable. A dash (-) in front means it has not yet been completed,
but if not completed in time will just be pushed to the next release. A
space means that the task has been completed.
Footnotes are indicated by [n] and give more information on that item.
If you know of packages that do not conform to any of these tasks, please
report it as a bug against those packages. If that task is marked as critical
(i.e. with an asterisk *), then please let me know and I will mark the bug
as critical.
Critical bugs are those that you would seriously consider delaying the
upcoming release or removing that package from the distribution because
they are not fixed.
Upcoming Dates
~~
July 1, 1997Bugs older than 9 months will be marked as overdue.
August 1, 1997 Bugs older than 8 months will be marked as overdue.
September 1,'97 Bugs older than 7 months will be marked as overdue.
Thoughts
---
Bo (Debian 1.3)
~~~
Fix all remaining release critical bugs ([EMAIL PROTECTED])
- Fix 63 remaining overdue bugs ([EMAIL PROTECTED])
Shadow password support ([EMAIL PROTECTED])
- Shared libraries should provide .shlibs files ([EMAIL PROTECTED])
- Appropriate pkgs should call install-mime in postinst ([EMAIL PROTECTED])
- Convert remaining a.out packages (???)
Boot disks should contain drivers for more systems/cards (???)
Integration of modules, kernel, boot-floppies, pcmcia (???) [1]
Include the multi-thread support patch for the Objective-C runtime lib (???)
Fix packages that break with new libc5.4
- Fix installed size entries in packages ([EMAIL PROTECTED])
- Improvements to 'dselect' ([EMAIL PROTECTED],[EMAIL PROTECTED]) [2]
Move all shared libraries into libs ([EMAIL PROTECTED]) [4]
Move interpreters out of devel ([EMAIL PROTECTED]) [4]
Add support for resolutions beyond 1280x1024 to X config utility (???) [5]
- Package grouping to simplify install ([EMAIL PROTECTED],[EMAIL PROTECTED])
general threading policy (???) [6]
Fix pkgs referencing /etc/site-start.el([EMAIL PROTECTED])[7]
- configuring so non-ASCII characters work (???) [9]
Base packages to be in new source format
- Make all web servers apply to /usr/doc/debmake/webstandard-3.0
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
- Packages to call update-menu in postinst ([EMAIL PROTECTED]) [11]
Hamm (Debian 2.0)
~
* All packages are in the new package format.
* All packages in main distribution are compiled with libc6.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs, ...).
* No a.out executables anymore.
* Remove --force-overwrite flag from dpkg defaults
* Much improved dpkg/dselect.
* Use PAM within authentication programs [13]
* Link shared libs against other shared libs instead of static [14]
* Official Debian logo chosen.
- Move config information from install scripts to cfgtool (???)
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
---
Footnotes
~
1 - Friday I used the boot floppies in the rex tree and I could load any
modules (NFS being the show stopper). In the Linux Journal review of
Debian (Nov Issue), explictly mentions this problem with 1.1
Re: Upcoming Debian Releases
On May 26, Brian C. White wrote Hamm (Debian 2.0) Some more ideas/goals: * PAM-mify at least the essential authentication programs (passwd, su,...) and preferably all programs that require authentication (POP clients, webservers, ...). URL:http://parc.power.net/morgan/Linux-PAM/. From the FAQ URL:http://parc.power.net/morgan/Linux-PAM/FAQ: Q3: Are there any distributions (of Linux) that come with PAM? YES. Currently, the only distributions that are shipped with PAM installed are Red Hat Linux distributions. [...] Caldera will be supporting PAM. Debian has made a commitment to support PAM in the future, there is a debian package for it but applications have not been made available. Nothing is known of other distributions. * Link shared libraries themselves against other shared libs, instead of including their code static (e.g. as current S-Lang already does); this can reduce memory use. See H.J. Lu's ELF: From The Programmer's Perspective URL:ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz for details. Greetings, Ray -- Obsig: developing a new sig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On 30 May 1997, Kai Henningsen wrote: [EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in [EMAIL PROTECTED]: There are ways to avoid this. For example, modify dpkg not to include any line with config=yes in it in the md5sum of certain files. This is a troll, right? Wrong. Or maybe you have forgotten how conffiles are actually handled: (old=original install, new=this install, current=possibly edited version) If old md5 = new md5, ignore new file (package unchanged) If old md5 = current md5, install new file (conffile was not edited) otherwise, prompt (both changed) Your change would mean that in case 2, dpkg would have to figure out how to put the variables from the old script into the new one. But, for a package which adds config info, the new md5 != the old md5. Therefore, it would ask! And for a package where old includes config lines, the pkgtool would be rerun to update info which was config=yes. Locally modified lines wouldn't be config=yes, so the md5 would be different. Therefore, unless the sysadmin forgets to modify config=yes (put a banner to remind them), it works. So:- non-cfgtool md5 != cfgtoolized md5: old md5 != new md5. local file not modified: update anyway to use new cfgtool version. local file modified: cfgtool md5 == cfgtool md5: old md5=new md5 local file not modified (enough) - install new THEN, update from cfg database. See, it does work. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
According to Yann Dirson: That just go fine, until you try to use 'halt' or 'reboot': as specified in the manpage (yes :), these only call shutdown when in runlevel 1-5. Quite strange IMHO. *BE CAREFUL* trying to reproduce it, it (probably among other unclean things) doesn't unmount cleanly filesystems. I don't know the reason why RLs 7-9 are handled just like 0 and 6. I think it should at least be possible to choose which behaviour they have in this case, if the current behaviour is meaningful (IMHO, it is only meaningful for halt/reboot-like actions). Should this be considered as a bug ? I'll fix it so that it test for (runlevel != 0 runlevel != 6) instead of (runlevel 0 runlevel 6) Mike. -- | Miquel van Smoorenburg | I need more space Well, why not move to Texas | | [EMAIL PROTECTED] | No, on my account, stupid. Stupid? Uh-oh..| | PGP fingerprint: FE 66 52 4F CD 59 A5 36 7F 39 8B 20 F1 D6 74 02 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
[EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in [EMAIL PROTECTED]: There are ways to avoid this. For example, modify dpkg not to include any line with config=yes in it in the md5sum of certain files. This is a troll, right? Or maybe you have forgotten how conffiles are actually handled: (old=original install, new=this install, current=possibly edited version) If old md5 = new md5, ignore new file (package unchanged) If old md5 = current md5, install new file (conffile was not edited) otherwise, prompt (both changed) Your change would mean that in case 2, dpkg would have to figure out how to put the variables from the old script into the new one. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
Yann Dirson writes: * that's not complete either. As already mentionned, the manpage tells about undocumented runlevels 7-9. It also poorly tells about those AaBbCc I never really understood. I just tried those runlevels 7-9, with sysvinit_2.71-2. It just need few modifications to have them work: * add rc[7-9].d, and 'cp -d rc2.d/* rcX.d' to get packages setup * add in inittab: runlevel (l7,l8,l9) entries, 7-9-awareness into getty and ctrl-alt-del entries (entries 1-6 and ca) There would surely be other things to update if they are to be used in debian (eg. update-rc.d). That just go fine, until you try to use 'halt' or 'reboot': as specified in the manpage (yes :), these only call shutdown when in runlevel 1-5. Quite strange IMHO. *BE CAREFUL* trying to reproduce it, it (probably among other unclean things) doesn't unmount cleanly filesystems. I don't know the reason why RLs 7-9 are handled just like 0 and 6. I think it should at least be possible to choose which behaviour they have in this case, if the current behaviour is meaningful (IMHO, it is only meaningful for halt/reboot-like actions). Should this be considered as a bug ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sun, 25 May 1997, Mark Baker wrote: In article [EMAIL PROTECTED], Tom Lees [EMAIL PROTECTED] writes: the other solution is to have a small utility that stores these values, can change them and gives the values to the scripts. The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). And if you're not very careful it does silly things if the scripts have been modified significantly. So you do something like:- BLAH=something # configtool=yes Then, if someone modifies the scripts, they make sure that that particular line is still there, or remove the configtool=yes if they don't want it. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sun, 25 May 1997, Christian Hudon wrote: --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii On May 24, Tom Lees wrote The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). And it changes the conffiles, which means that the user will still get bugged with Conffile changed, overwrite with package's version or keeps yours? questions from dpkg, which is exactly what we want to avoid with cfgtool. There are ways to avoid this. For example, modify dpkg not to include any line with config=yes in it in the md5sum of certain files. So, for example:- #!/bin/sh # the blah script some code BLAH=yes# config=yes If this becomes:- #!/bin/sh # the blah script some code BLAH=no # config=yes It still gets excluded from the md5sum, but if someone changes it, like:- #!/bin/sh # the blah script some code BLAH=no Then dpkg gets a different md5sum, and prompts, because it is included this time. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
David Welton [EMAIL PROTECTED] writes: I suppose it really isn't my place to say this, but would it not be possible to fix a few of the cosmetic bugs while we are waiting? A few that come to mind are the Pacific/Pacific-New conflict in timezone, which is going to chalk up 1 bug in the minds of everyone on the west coast of the US who installs or upgrades Debian. By now, the critical bug has been closed. I am generally against bug fixes this late in the game, but this bug is a particularly ugly bug and is most likely to effect new users (on US west coast). It would be nice to get this fixed soon. -- Kevin Dalley [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
This was incorrect... *** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** Due to some hectic situations going on here, I neglected to update this banner before the mail went out. Bo is currently a release candidate. It will become an official release as soon as the testing group okays it. Package updates are few and far between. Anything that other packages depend on are generally refused outright unless it is extremely important. Leaf packages are only allowed in if the existing package is non-functional for some reason. Brian ( [EMAIL PROTECTED] ) --- Touch passion when it comes your way. It's rare enough as it is; don't walk away when it calls you by name. -- Marcus (Babylon 5) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Bo is currently a release candidate. It will become an official release as soon as the testing group okays it. What about Bug #10165? Is not being able to boot after an upgrade critical? -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
Alexander Koch writes: ~ # init Usage: init 0123456SsQqAaBbCc 1 is already multiuser, no networking (iirc). single-user is S or s (just like using the single as argument for lilo)! 2 is networking (basic, inn comes up etc) 3 is full networking (whatever you desire) 4 and 5 is to be filled with xdm (x) (for those who desire) 6 is reboot Did I get anything wrong? * I think you at least missed something: runlevel 1 is a temporary one, and automatically switches to S. I think you should never ask 'telinit S', but 'telinit 1' * that's not complete either. As already mentionned, the manpage tells about undocumented runlevels 7-9. It also poorly tells about those AaBbCc I never really understood. More about these ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
On May 26, Tom Lees wrote No, we don't need xdm in runlevel 4. A better solution would be this (but it is more difficult, requires multiple inetd.conf files):- 2: multiuser, minimal networking, no networking daemons (including inetd). 3: multiuser, client networking (rpc.ugidd, ident, etc.) 4: multiuser, server networking (ftp, http, finger, etc.) 5: empty for making special local runlevel? whenever i was playing around with runlevels, i had runlevel 2 to do system administration (some more programms than runlevel 1/single user. most important : several getty (doing system work with one getty is a pain IMO (think of reading a manpage for special parameter xyz)). please keep runlevel 2 this way, a lot of people will use it this way, i think. no net, not daemons, a few getty and some utilities (filesystems mounted). i ever used 3,4,5 to alternate some program (most difference was with x / without x, but in low memory times, i also had a runlevel with x, but no other daemons like inn, so netscape wasn't that slow). for most people : the basic is, what programs you want to run, and what not. then you try to group these decissions into runlevels. for 10 programs you would need 2^10=1024 runlevels to have all possible situations. even if you drop the unrealistic, you cannot get all possible situations. the only way to reduce the number of runlevels is a) don't do specifig runlevels or b) force a policy. if we are talking about changing runlevels, we should also discuss (these themes came up at the linux kongress in a init system discussion) : a) dependencies or something like that. most daemons won't work without network. nfsd won't work without portmap. etc... b) link policy. i don't know how update-rc.d is working, but there are different aproches (start or stop script in every runlevel, not both; start and stop script in a runlevel, or none; stoping daemons with a stop script in the old / the new runlevel etc.) i know, update-rc.d manages these things, but whe should have a document, that shows how everything is working, and why we ar edoning it that way. c) some program, that can show : these programs are running / these programs should be running. d) standart for scripts: every script has start and stop. but what about restart or reload or ... ? (that's an example, why i would like to have debian in one big cvs source - you could checkout all init.d scripts, modify them, check them in, and all packages would get fixed with the next release.) currently debian is using numbers to mark when to start / stop a program. we should have a policy what these number mean. think of topics like /var is mounted and rw or /tmp is rw etc. yes, there are systems with read-only filesystems all the time ... more stuff to think about and discuss. comments are welcome. regards, andreas (good night, it's 2 a.m.) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Upcoming Debian Releases
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White [EMAIL PROTECTED]
This document was last modified at Time-stamp: 97/05/23 17:29:19 bcwhite
*** ***
*** Release of Bo is HOLDING for CRITICAL BUGS!***
*** ***
*** There is one remaining critical bug that must be resolved before ***
*** Debian 1.3 can be released. That bug is #9020: ***
*** ***
*** fsck.ext2: can't load library 'libcom_err.so.2' ***
*** ***
If you're replying about some of the ideas mentioned in this document, it is
often wise to change the subject to reflect that idea. This helps target
those people who are most likely to partake in discussions about it.
For each upcoming release, the name of the task and the person who has claimed
responsibility for it (or ??? if nobody) is listed. An asterisk (*) in front
means the job has yet to be completed and must be done before that release can
be made stable. A dash (-) in front means it has not yet been completed,
but if not completed in time will just be pushed to the next release. A
space means that the task has been completed.
Footnotes are indicated by [n] and give more information on that item.
If you know of packages that do not conform to any of these tasks, please
report it as a bug against those packages. If that task is marked as critical
(i.e. with an asterisk *), then please let me know and I will mark the bug
as critical.
Critical bugs are those that you would seriously consider delaying the
upcoming release or removing that package from the distribution because
they are not fixed.
Upcoming Dates
~~
May 12, 1997Bo will be released
July 1, 1997Bugs older than 6 months will be marked as overdue (will be at
least 9 months old by the time Hamm is released).
Thoughts
---
Bo (Debian 1.3)
~~~
* Fix 1 remaining release critical bugs ([EMAIL PROTECTED])
- Fix 63 remaining overdue bugs ([EMAIL PROTECTED])
Shadow password support ([EMAIL PROTECTED])
- Shared libraries should provide .shlibs files ([EMAIL PROTECTED])
- Appropriate pkgs should call install-mime in postinst ([EMAIL PROTECTED])
- Convert remaining a.out packages (???)
Boot disks should contain drivers for more systems/cards (???)
Integration of modules, kernel, boot-floppies, pcmcia (???) [1]
Include the multi-thread support patch for the Objective-C runtime lib (???)
Fix packages that break with new libc5.4
- Fix installed size entries in packages ([EMAIL PROTECTED])
- Improvements to 'dselect' ([EMAIL PROTECTED],[EMAIL PROTECTED]) [2]
Move all shared libraries into libs ([EMAIL PROTECTED]) [4]
Move interpreters out of devel ([EMAIL PROTECTED]) [4]
Add support for resolutions beyond 1280x1024 to X config utility (???) [5]
- Package grouping to simplify install ([EMAIL PROTECTED],[EMAIL PROTECTED])
general threading policy (???) [6]
Fix pkgs referencing /etc/site-start.el([EMAIL PROTECTED])[7]
- configuring so non-ASCII characters work (???) [9]
Base packages to be in new source format
- Make all web servers apply to /usr/doc/debmake/webstandard-3.0
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
- Packages to call update-menu in postinst ([EMAIL PROTECTED]) [11]
Hamm (Debian 2.0)
~
* All packages are in the new package format.
* All packages in main distribution are compiled with libc6.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs, ...).
* No a.out executables anymore.
* Much improved dpkg/dselect.
* Official Debian logo chosen.
- Move config information from install scripts to cfgtool (???)
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
---
Footnotes
~
1 - Friday I used the boot floppies in the rex tree and I could load any
modules (NFS being the show stopper). In the Linux Journal review of
Debian (Nov Issue), explictly mentions this problem with 1.1 and it
hasn't been solved yet :( -- Chris Fearnley [EMAIL PROTECTED]
3 - I.e.: say I just want to install a package for a single library-- but I
also want the developer
Re: Upcoming Debian Releases
On Mon, 26 May 1997, Brian C. White wrote: | *** *** | *** Release of Bo is HOLDING for CRITICAL BUGS!*** | *** *** | *** There is one remaining critical bug that must be resolved before *** | *** Debian 1.3 can be released. That bug is #9020: *** | *** *** | *** fsck.ext2: can't load library 'libcom_err.so.2' *** | *** *** I suppose it really isn't my place to say this, but would it not be possible to fix a few of the cosmetic bugs while we are waiting? A few that come to mind are the Pacific/Pacific-New conflict in timezone, which is going to chalk up 1 bug in the minds of everyone on the west coast of the US who installs or upgrades Debian. Secondly, although a bit less common, is the fact that we have an rxvt that has xpm's by default, instead of the newer rxvt and rxvt-xpm. I could see plenty of users asking themselves why their Debian has slowed down under X with the upgrade to 1.3. These are two I have encountered myself, but I suppose there may be others. Thinking about the idea that 'we can't change anything because it might create new bugs', I ask when these necessary changes will be introduced - 1.3.1? In which case, that should be the release burned onto CD's, as it is stable, *and* has the wrinkles smoothed out. Is this the plan? Once again, pardon my ignorance - I think it's obvious I'm fairly new to all this, but I'm anxious to learn, and to see Debian succeed. Thanks, David Welton [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.efn.org/~davidw Se quest'email e` in Italiano, mi dispiace per gli errori:-) FORZA PANTANI! --Debian GNU/Linux-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
while it would be interesting to perhaps do a 1.3.1 or a 1.4 with other features, there has to be pressure against doing anything to 1.3 other than what qa wants to do to get it out the door. We can't make every release perfect; in fact, we can't make *any* release perfect... but we can try to set some goals and meet them. Debian 1.3 is probably closer to doing that than any previous debian release; I hope I don't see it get derailed now... One added complexity is that building a 1.3.1 or 1.4 will be made somewhat more difficult by the developers migrating to libc6 in order to get working on Debian 2.0; I've certainly started in that direction (though I will probably keep one machine at or near 1.3 as long as is practical.) Certainly the next X release I do, and probably the next Emacs release after that, will require libc6... _Mark_ [EMAIL PROTECTED] The Herd of Kittens A Debian Maintainer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
[EMAIL PROTECTED] (Andreas Jellinghaus) wrote on 27.05.97 in [EMAIL PROTECTED]: On May 26, Kai Henningsen wrote [EMAIL PROTECTED] (Vadim Vygonets) wrote on 26.05.97 in [EMAIL PROTECTED]: BTW, why does runlevel 6 mean reboot? Can't it be runlevel 9? It (6) seems to be the standard in Linux boxen now, but why? It's been standard in runlevel-based Unix for a long time. That's probably because traditionally, 6 is the last available runlevel; so 6 is traditionally reboot, and 0 is halt, on every Unix system that has runlevels. maybe that was some time ago, but runlevels 7,8,9 are also available (sysvinit can do them), and IIRC i also read something about runlevels a,b,c. miquel ? Don't confuse the Linux sysvinit with the real SysV init. I've been talking about the latter. I've never seen runlevels higher than 6 used on those systems. I'm not completely sure, but I suspect there's also near-universal consensus that 1 is more-or-less single user. S is an acronym for Single user, that's runlevel 1. are there more acronyms / short cuts ? btw: s will not work (but IIRC in old init it was working (in my pre debian time)). It ought to work. You tell init to switch runlevels eith either the init or the telinit command, depending on version; it should accept a runlevel number (traditionally 1-6), s or S for single user, and q or Q for re-read inittab. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On 27 May 1997, Mark Eichin wrote: | while it would be interesting to perhaps do a 1.3.1 or a 1.4 with | other features, there has to be pressure against doing anything to 1.3 | other than what qa wants to do to get it out the door. We can't make | every release perfect; in fact, we can't make *any* release | perfect... but we can try to set some goals and meet them. Debian 1.3 | is probably closer to doing that than any previous debian release; I | hope I don't see it get derailed now... I wasn't talking really about 'other features' - just some more cosmetic bug fixes, but you're right, it'll never be perfect, so it's probably best to just get it out the door. | One added complexity is that building a 1.3.1 or 1.4 will be made | somewhat more difficult by the developers migrating to libc6 in order | to get working on Debian 2.0; I've certainly started in that direction | (though I will probably keep one machine at or near 1.3 as long as is | practical.) Certainly the next X release I do, and probably the next | Emacs release after that, will require libc6... There were 1.1.xx, there were 1.2.0-15, there will be a Debian 1.3.1, at least if the precedent holds true. If our current goal is to get 1.3 out the door ASAP notwithstanding the known cosmetic bugs, then, would it not be prudent to hold off on burning CD's untill we catch up with some of these cosmetic bugs in 1.3.1? Once again, I am new to this, and maybe what I am saying doesn't make sense - if so, kindly tell me and I'll be quiet:-) David Welton [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.efn.org/~davidw Se quest'email e` in Italiano, mi dispiace per gli errori:-) FORZA PANTANI! --Debian GNU/Linux-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
On 23 May 1997, Milan Zamazal wrote: I know nothing about runlevel standards, just my opinions: Same here. AK == Alexander Koch [EMAIL PROTECTED] writes: AK: level 1 is without net, 2 is with it all (imo including nfs AK: and the like) and 3 is xdm, 6 was shutdown or halt or AK: whatsoever. at least that i remember from some german AK: distribution. I'm no big sysadmin but I think we can use all 1 to 4 levels. One free runlevel could be enough (in actually, if *I* need some modifications, I make them by modifying existing runlevels not creating new ones). AK: default runlevel is 2 so why should nfs start with 3? I'd like something similar to: 1: single user 2: multiuser with minimal networking, probably without offering services 3: full networking (NFS, xfs, anonymous ftp, ...) 4: xdm? (yes, it is common on Slackware and RedHat to start xdm according to runlevel, but maybe Debian /etc/X11/config concept is better) No, we don't need xdm in runlevel 4. A better solution would be this (but it is more difficult, requires multiple inetd.conf files):- 2: multiuser, minimal networking, no networking daemons (including inetd). 3: multiuser, client networking (rpc.ugidd, ident, etc.) 4: multiuser, server networking (ftp, http, finger, etc.) 5: empty for making special local runlevel? Yes, good idea. So if I want to do something without being too used from outer world, I can switch to level 2 (and I can still telnet or ftp somewhere). AK: if 3 gets xdm, perhaps gpm should be disabled and the like? Remark: gpm should be disabled only when it doesn't work as a repeater. It doesn't need to be disabled, it just saves memory. It will detect when X starts up, and give up its own handling of the mouse. Only PS/2 mouse devices used cause a major problem with this (single-open only), but they don't do that any more IIRC. BTW, I don't like RedHat concept of empty level *4*. When I upgraded HW on some RedHat machine, I lowered default level from 5 to 4 in expection it will disable just xdm. Then I spent an hour looking for explanation, why many services don't start after changing HW. After I explored runlevel 4 was empty, I was far from being polite... Agreed. I think a better way than doing runlevels directly in packages, though, may be to set a package startup script's type - minnet, netclient, netserver, misc, etc. Then, define runlevels to include certain types of script. Just an idea (very difficult to implement with symlinks for /etc/rc?.d), what does anyone else think? -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
On Mon, 26 May 1997, Tom Lees wrote: I'd like something similar to: 1: single user 2: multiuser with minimal networking, probably without offering services 3: full networking (NFS, xfs, anonymous ftp, ...) 4: xdm? (yes, it is common on Slackware and RedHat to start xdm according to runlevel, but maybe Debian /etc/X11/config concept is better) I personally would like: 1: single user 2: multi user, NO networking 3: multi user, minimal networking 4: multi user, full networking 5: xdm 6: reboot 7-9: do whatever the heck you want with. SirDibos, telnet://lambda.moo.mud.org: -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
On Mon, 26 May 1997 [EMAIL PROTECTED] wrote: 6: reboot 7-9: do whatever the heck you want with. BTW, why does runlevel 6 mean reboot? Can't it be runlevel 9? It (6) seems to be the standard in Linux boxen now, but why? Vadik. -- Vadim Vygonets * [EMAIL PROTECTED] * [EMAIL PROTECTED] * Unix admin The fish doesn't think, because the fish knows... everything. -- Arizona Dream -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
BTW, why does runlevel 6 mean reboot? Can't it be runlevel 9? It (6) seems to be the standard in Linux boxen now, but why? AFAIK, it is 6 for reboot since that is what most othe SysV-ish Unixen use (like Irix and Solaris) -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
[EMAIL PROTECTED] (Vadim Vygonets) wrote on 26.05.97 in [EMAIL PROTECTED]: BTW, why does runlevel 6 mean reboot? Can't it be runlevel 9? It (6) seems to be the standard in Linux boxen now, but why? It's been standard in runlevel-based Unix for a long time. That's probably because traditionally, 6 is the last available runlevel; so 6 is traditionally reboot, and 0 is halt, on every Unix system that has runlevels. I'm not completely sure, but I suspect there's also near-universal consensus that 1 is more-or-less single user. There seems to be a somewhat weaker tradition saying that 2 is normal without net, and 3 is normal with net. Again, none of these traditions are Linux-specific; all are quite a bit older than Linux. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
Actually Debian could potentially use all the standard levels 0-6 for itself, and we could define the not so standard levels 7-9 to be totally for users purposes. That would give us much more space. We could then even take one of the 0-6 and reserve it for future use by Debian. And users would have plenty of room to play around themselves with 7-9. -Sam Message from Milan Zamazal ([EMAIL PROTECTED]) on 5-23-97: I know nothing about runlevel standards, just my opinions: AK == Alexander Koch [EMAIL PROTECTED] writes: AK: level 1 is without net, 2 is with it all (imo including nfs AK: and the like) and 3 is xdm, 6 was shutdown or halt or AK: whatsoever. at least that i remember from some german AK: distribution. I'm no big sysadmin but I think we can use all 1 to 4 levels. One free runlevel could be enough (in actually, if *I* need some modifications, I make them by modifying existing runlevels not creating new ones). AK: default runlevel is 2 so why should nfs start with 3? I'd like something similar to: 1: single user 2: multiuser with minimal networking, probably without offering services 3: full networking (NFS, xfs, anonymous ftp, ...) 4: xdm? (yes, it is common on Slackware and RedHat to start xdm according to runlevel, but maybe Debian /etc/X11/config concept is better) 5: empty for making special local runlevel? So if I want to do something without being too used from outer world, I can switch to level 2 (and I can still telnet or ftp somewhere). AK: if 3 gets xdm, perhaps gpm should be disabled and the like? Remark: gpm should be disabled only when it doesn't work as a repeater. BTW, I don't like RedHat concept of empty level *4*. When I upgraded HW on some RedHat machine, I lowered default level from 5 to 4 in expection it will disable just xdm. Then I spent an hour looking for explanation, why many services don't start after changing HW. After I explored runlevel 4 was empty, I was far from being polite... -- VA Research Linux Workstations| The World's Best Linux Workstations | http://www.varesearch.com | Now offering VarStation II Systems Sam Ockman - (415)934-3666, ext. 133 | Based on the Intel Pentium II -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
In article [EMAIL PROTECTED], Tom Lees [EMAIL PROTECTED] writes: the other solution is to have a small utility that stores these values, can change them and gives the values to the scripts. The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). And if you're not very careful it does silly things if the scripts have been modified significantly.
Re: Upcoming Debian Releases
On May 24, Tom Lees wrote The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). And it changes the conffiles, which means that the user will still get bugged with Conffile changed, overwrite with package's version or keeps yours? questions from dpkg, which is exactly what we want to avoid with cfgtool. Christian pgpf4aJbKfp3S.pgp Description: PGP signature
Re: Upcoming Debian Releases
- Move config information from install scripts to cfgtool (???) I'm having a look at ways of doing this. It would be really cool to integrate this into deity. there are three tools : cfgtool (lars wirzenius), nod (winfried truemper), dcfgtool (mine). and someone is working on a _real_ tool (all three have flaws, and if this way we will get a tool with all good features). what they do : currently many scripts in /etc hold config values. this is a bad thing. one solution is to write these variables in other text files, and use the source command in the shell script to read them. this is not a good way IMO. the other solution is to have a small utility that stores these values, can change them and gives the values to the scripts. as you can see, it's a small text database. so it has nothing, absolutly nothing to do with deity - that's a GUI. i will wait till the new tool is released, than we can remove all other tools (at least my will get removed - there is no reason to keep it.) then we should : a) choose _one_ cfgtool (the current one have big flaws. the new one will not have them). b) change policy to _not_ allow config information in /etc scripts c) change policy to _not_ allow additional debian uniq config files to fix b). only the textdb should be used. d) think about getting rid of some config files only used by shell scripts, and use the textdb instead. Footnotes 1, 4, 5, and 7 can be removed AFAIK. what about footnote 10 (cu* devices) ? debian 1.3 has no call out devices ! (*evil grin*) regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
In article [EMAIL PROTECTED], Andreas Jellinghaus [EMAIL PROTECTED] writes: b) change policy to _not_ allow config information in /etc scripts I disagree strongly. A script without config information doesn't belong in /etc at all. Having your database seems like a reasonable idea, but it needs to be plain text which might be slow; a db file would be faster but I want to be able to change it in a text editor.
Re: Upcoming Debian Releases
On Sat, 24 May 1997, Mark Baker wrote: b) change policy to _not_ allow config information in /etc scripts I disagree strongly. A script without config information doesn't belong in /etc at all. Having your database seems like a reasonable idea, but it needs to be plain text which might be slow; a db file would be faster but I want to be able to change it in a text editor. As a compromise it could use the same system than the sendmail aliases: The user make changes in a plain text file (/etc/aliases), but the application 'compiles' this file as a db database (/etc/aliases.db)? -- - ** Linux ** +---+ ** WAW ** - - [EMAIL PROTECTED] | RENARDIAS Vincent | [EMAIL PROTECTED] - - Debian/GNU Linux +---+ http://www.waw.com/ - - http://www.debian.org/ |WAW (33) 4 91 81 21 45 - --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sat, 24 May 1997, Vincent Renardias wrote: As a compromise it could use the same system than the sendmail aliases: The user make changes in a plain text file (/etc/aliases), but the application 'compiles' this file as a db database (/etc/aliases.db)? Can you rely on all applications that use the database doing this? (presumably if they didn't do it themselves but used another tool to get the information for them you could) If so, then that would be acceptable. I don't want a situation where you have to remember to compile it yourself. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sat, 24 May 1997, Andreas Jellinghaus wrote: - Move config information from install scripts to cfgtool (???) I'm having a look at ways of doing this. It would be really cool to integrate this into deity. there are three tools : cfgtool (lars wirzenius), nod (winfried truemper), dcfgtool (mine). and someone is working on a _real_ tool (all three have flaws, and if this way we will get a tool with all good features). I know all this. But when will it be finished? What about beta versions? Is there a mailing list (other than debian-admintool)? what they do : currently many scripts in /etc hold config values. this is a bad thing. one solution is to write these variables in other text files, and use the source command in the shell script to read them. this is not a good way IMO. the other solution is to have a small utility that stores these values, can change them and gives the values to the scripts. The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). as you can see, it's a small text database. so it has nothing, absolutly nothing to do with deity - that's a GUI. OK, I should refrase what I wrote. It would be really cool if we upgraded the packaging system to handle configuration integrally (so we can do configuration _BEFORE_ an installation, etc.). Deity definitely _IS_ the right place for this - a GUI to do the configuration with, at the same time as packaging control! i will wait till the new tool is released, than we can remove all other tools (at least my will get removed - there is no reason to keep it.) I wrote a perl script to do this (mainly as an exercise in perl, which I am learning). If anyone wants it, I could happily package and upload it into experimental. then we should : a) choose _one_ cfgtool (the current one have big flaws. the new one will not have them). b) change policy to _not_ allow config information in /etc scripts c) change policy to _not_ allow additional debian uniq config files to fix b). only the textdb should be used. d) think about getting rid of some config files only used by shell scripts, and use the textdb instead. Footnotes 1, 4, 5, and 7 can be removed AFAIK. what about footnote 10 (cu* devices) ? debian 1.3 has no call out devices ! (*evil grin*) True, this has been done in the package, but not everyone may have removed their /dev/cua* files from previous installations. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sat, 24 May 1997, Tom Lees wrote: as you can see, it's a small text database. so it has nothing, absolutly nothing to do with deity - that's a GUI. OK, I should refrase what I wrote. It would be really cool if we upgraded the packaging system to handle configuration integrally (so we can do configuration _BEFORE_ an installation, etc.). Deity definitely _IS_ the right place for this - a GUI to do the configuration with, at the same time as packaging control! And let me just add, if Remote Installation and Mantinance is ever desired then the ability to configure N machine's packages once from a single machine is important. It would be kind of nasty to force the user to manually enter everything N times during a remote install. This someday will be Deity's problem. Given that, it might be a good idea to have a single config area and not just write something that parses shell scripts. Partly because all the configs related to a single package would have to be transmitted over the network. I suppose shells could do something like COMPORT = `cfgtool diald comport` Please note that for the case above this is not something like simple ini file. To allow a GUI to present a usefull view of the config file information about each field would have to be known. A short description, it's content type, possible range information, etc. Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On May 24, Mark Baker wrote In article [EMAIL PROTECTED], Andreas Jellinghaus [EMAIL PROTECTED] writes: b) change policy to _not_ allow config information in /etc scripts I disagree strongly. A script without config information doesn't belong in /etc at all. sometimes you need to change a script, no matter how good it is. if we move scripts out of /etc and don't mark them as conffiles, we would need a good mechanism to ensure, that a script hasn't changed. till you find a good solution, keep them as configgile in /etc. Having your database seems like a reasonable idea, but it needs to be plain text which might be slow; a db file would be faster but I want to be able to change it in a text editor. there are a lot of required features : - text files (so you can edit them by hand) - path style variables commands (network/interface/eth0) - import and exports commands (textdb --export |rsh hostname textdb --import :-) - implemented in c ( - fast enough, no dependcy on perl/whatever) - list, is, exec function would be great (for A in textdb --list network/interface ; do textdb --exec network/interface/$A; done :-) - maybe even more ... but : don't discuss it now. someone is working on a realy good textdb/cfgtool/however-you-call-it, and i'm sure that he will do the right thing. wait till it is released. regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Having your database seems like a reasonable idea, but it needs to be plain text which might be slow; a db file would be faster but I want to be able to change it in a text editor. As a compromise it could use the same system than the sendmail aliases: The user make changes in a plain text file (/etc/aliases), but the application 'compiles' this file as a db database (/etc/aliases.db)? databases ? hey, we are talking about maybe 100 variables in 5 files, that's 20 variables per file. and the parsing is a) not complex and b) only done during bootup / when starting scripts. the program will be written in c, so it will be fast enough. a database will not help, only make everything huge and slow. regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Apparently this has been fixed: Login as anonymous... Setting transfer mode to binary... Cd to /debian... getting: frozen/binary-i386/mail/smartlist_3.10-16.deb (78216) getting: frozen/binary-i386/mail/procmail_3.10.4-2.deb (112164) getting: frozen/binary-i386/base/modconf_0.2.10.deb (17576) Processing downloaded files...(for corrupt/old/partial) frozen/binary-i386/base/modconf_0.2.10.deb frozen/binary-i386/mail/smartlist_3.10-16.deb frozen/binary-i386/mail/procmail_3.10.4-2.deb Do you want to install the files fetched [y]: Thomas Gebhardt [EMAIL PROTECTED] writes: Hi, please note that the Package.gz file and the actual content of frozen is still inconsistent in at least two points: getting: frozen/binary-i386/admin/boot-floppies_1.2.17.deb (136652) frozen/binary-i386/admin/boot-floppies_1.2.17.deb: No such file OR directory. getting: frozen/binary-i386/base/modconf_0.2.9.deb (17350) frozen/binary-i386/base/modconf_0.2.9.deb: No such file OR directory. (Seen at ftp.debian.org, Thu, 22 May 1997 7:00 UTC) Cheers, Thomas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
I know nothing about runlevel standards, just my opinions: AK == Alexander Koch [EMAIL PROTECTED] writes: AK: level 1 is without net, 2 is with it all (imo including nfs AK: and the like) and 3 is xdm, 6 was shutdown or halt or AK: whatsoever. at least that i remember from some german AK: distribution. I'm no big sysadmin but I think we can use all 1 to 4 levels. One free runlevel could be enough (in actually, if *I* need some modifications, I make them by modifying existing runlevels not creating new ones). AK: default runlevel is 2 so why should nfs start with 3? I'd like something similar to: 1: single user 2: multiuser with minimal networking, probably without offering services 3: full networking (NFS, xfs, anonymous ftp, ...) 4: xdm? (yes, it is common on Slackware and RedHat to start xdm according to runlevel, but maybe Debian /etc/X11/config concept is better) 5: empty for making special local runlevel? So if I want to do something without being too used from outer world, I can switch to level 2 (and I can still telnet or ftp somewhere). AK: if 3 gets xdm, perhaps gpm should be disabled and the like? Remark: gpm should be disabled only when it doesn't work as a repeater. BTW, I don't like RedHat concept of empty level *4*. When I upgraded HW on some RedHat machine, I lowered default level from 5 to 4 in expection it will disable just xdm. Then I spent an hour looking for explanation, why many services don't start after changing HW. After I explored runlevel 4 was empty, I was far from being polite... Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Mon, 19 May 1997, Brian C. White wrote:
Hamm
I think its been agreed that this will be called Debian 2.0, so why not
add this here.
* All packages are in the new package format.
Possibly a new source package format may be created, so we should resolve
this before putting too much effort into converting twice.
* All base packages are compiled with libc6.
Should be all pkgs in the main distrib really.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs,
...).
* No a.out executables anymore.
* Much improved dpkg/dselect.
- Move config information from install scripts to cfgtool (???)
I'm having a look at ways of doing this. It would be really cool to
integrate this into deity.
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
And another one:-
* Official Debian logo to be chosen
Footnotes 1, 4, 5, and 7 can be removed AFAIK.
--
Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger [EMAIL PROTECTED] for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: ObjC runtime (was: Upcoming Debian Releases)
Gregor Hoffleit wrote: Include the multi-thread support patch for the Objective-C runtime lib (???) bo includes gstep-base-0.2.12 and gstep-base-0.2.12 includes a patch file gcc-2.7.2.1-objc.diff, which therefore should be applied to the gcc in bo (the patch applies fine to gcc-2.7.2.2). The bo gcc has had the obj-c runtime patches applied for a long time now. The remaining question the thread model to be enabled in the patched objc runtime. The patched runtime can be compiled for e.g. PCthreads, LinuxThreads or no threads at all. Who is to decide this ? LinuxThreads seems to be the standard Debian way to go, so I used that. --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Christoph Lameter [EMAIL PROTECTED] writes: Have a look at the bug report. I dont know why no one has marked it as done yet. There is a file lists in the but report ending in .dpkg-tmp evidently from a crash. Dont be buerocratic about releasing 1.3. Brian should resist releasing 1.3 if a serious bug is still outstanding. Of the bug is truly fixed, someone will close the bug. Brian is not being bureaucratic, just cautious. We have a reputation to protect/create. -- Kevin Dalley [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Did anyone make sure that this is really a bug? In all my testing I did not encounter this. The upgrade I did yesterday did not show anything. Reputation: We are just confirming our bad reputation in not being able to get things out of the door... There are still nasty bugs in bo that will probably never be fixed (as customary with prior releases...) and so I guess I will be (again) using the unstable distribution to install as soon as fixes are available. That is the irony and the continuing legacy of of the stable Debian releases ... But that is the way things are and the way releases happen even in the commercial world. Some bugs (encountered yesterday on an upgrade Debian 1.2 to 1.3): 1. Timezone configuration does not accept Pacific timezone. Reported a long time ago. 2. netstd does not install on the same run with netbase. Fails on preinst. 3. dpkg-ftp does not download all packages. Needs second run. 4. A couple of installation scripts spit out errormessages during configurationn but continue just fine. I think we better face the issue that there is no perfect software and a release is always a compromise. Get this out. On 21 May 1997, Kevin Dalley wrote: Christoph Lameter [EMAIL PROTECTED] writes: Have a look at the bug report. I dont know why no one has marked it as done yet. There is a file lists in the but report ending in .dpkg-tmp evidently from a crash. Dont be buerocratic about releasing 1.3. Brian should resist releasing 1.3 if a serious bug is still outstanding. Of the bug is truly fixed, someone will close the bug. Brian is not being bureaucratic, just cautious. We have a reputation to protect/create. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
[EMAIL PROTECTED] (Brian C. White) writes: *** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** What the heck? I've seen numerous people post to this list saying that particular thing isn't really a bug in the package. Why are you holding the release? People that are waiting for Debian 1.3 are giving up and going elsewhere (like RedHat). I don't like that. C'mon! Before you take such a drastic step as delaying the release of an operating system, you could at least verify that the bug really exists in the operating system Somebody, just close the bug so Brian will be happy... -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Upcoming Debian Releases
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White [EMAIL PROTECTED]
This document was last modified at Time-stamp: 97/05/12 19:04:03 bcwhite
*** ***
*** Release of Bo is HOLDING for CRITICAL BUGS!***
*** ***
*** There is one remaining critical bug that must be resolved before ***
*** Debian 1.3 can be released. That bug is #9020: ***
*** ***
*** fsck.ext2: can't load library 'libcom_err.so.2' ***
*** ***
If you're replying about some of the ideas mentioned in this document, it is
often wise to change the subject to reflect that idea. This helps target
those people who are most likely to partake in discussions about it.
For each upcoming release, the name of the task and the person who has claimed
responsibility for it (or ??? if nobody) is listed. An asterisk (*) in front
means the job has yet to be completed and must be done before that release can
be made stable. A dash (-) in front means it has not yet been completed,
but if not completed in time will just be pushed to the next release. A
space means that the task has been completed.
Footnotes are indicated by [n] and give more information on that item.
If you know of packages that do not conform to any of these tasks, please
report it as a bug against those packages. If that task is marked as critical
(i.e. with an asterisk *), then please let me know and I will mark the bug
as critical.
Critical bugs are those that you would seriously consider delaying the
upcoming release or removing that package from the distribution because
they are not fixed.
Upcoming Dates
~~
May 12, 1997Bo will be released
July 1, 1997Bugs older than 6 months will be marked as overdue (will be at
least 9 months old by the time Hamm is released).
Thoughts
---
Bo (Debian 1.3)
~~~
* Fix 1 remaining release critical bugs ([EMAIL PROTECTED])
- Fix 63 remaining overdue bugs ([EMAIL PROTECTED])
Shadow password support ([EMAIL PROTECTED])
- Shared libraries should provide .shlibs files ([EMAIL PROTECTED])
- Appropriate pkgs should call install-mime in postinst ([EMAIL PROTECTED])
- Convert remaining a.out packages (???)
Boot disks should contain drivers for more systems/cards (???)
Integration of modules, kernel, boot-floppies, pcmcia (???) [1]
Include the multi-thread support patch for the Objective-C runtime lib (???)
Fix packages that break with new libc5.4
- Fix installed size entries in packages ([EMAIL PROTECTED])
- Improvements to 'dselect' ([EMAIL PROTECTED],[EMAIL PROTECTED]) [2]
Move all shared libraries into libs ([EMAIL PROTECTED]) [4]
Move interpreters out of devel ([EMAIL PROTECTED]) [4]
Add support for resolutions beyond 1280x1024 to X config utility (???) [5]
- Package grouping to simplify install ([EMAIL PROTECTED],[EMAIL PROTECTED])
general threading policy (???) [6]
Fix pkgs referencing /etc/site-start.el([EMAIL PROTECTED])[7]
- configuring so non-ASCII characters work (???) [9]
Base packages to be in new source format
- Make all web servers apply to /usr/doc/debmake/webstandard-3.0
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
- Packages to call update-menu in postinst ([EMAIL PROTECTED]) [11]
Hamm
* All packages are in the new package format.
* All base packages are compiled with libc6.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs, ...).
* No a.out executables anymore.
* Much improved dpkg/dselect.
- Move config information from install scripts to cfgtool (???)
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
---
Footnotes
~
1 - Friday I used the boot floppies in the rex tree and I could load any
modules (NFS being the show stopper). In the Linux Journal review of
Debian (Nov Issue), explictly mentions this problem with 1.1 and it
hasn't been solved yet :( -- Chris Fearnley [EMAIL PROTECTED]
3 - I.e.: say I just want to install a package for a single library-- but I
also want the developer version and the static version... As it stands, I
can either su to
Re: Upcoming Debian Releases
*** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** I have done a couple of upgrades to 1.3 and have never noticed there being a problem exept in one instance where the e2prog package was not configured due to a crash while upgrading (watchdog shutdown ...) And v 1.06 is history anyways get 1.3 released. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
In your email to me, Christoph, you wrote: *** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** I have done a couple of upgrades to 1.3 and have never noticed there being a problem exept in one instance where the e2prog package was not configured due to a crash while upgrading (watchdog shutdown ...) And v 1.06 is history anyways get 1.3 released. FWIW, I agree. I haven't seen anyone on the testing list report this problem, and I never saw it across roughlt 15 upgrades I've done. I think this is a dead issue... Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps The courage to imagine the otherwise is our greatest resource, adding color and suspense to all our life. - Daniel J. Boorstin ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
*** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** I have done a couple of upgrades to 1.3 and have never noticed there being a problem exept in one instance where the e2prog package was not configured due to a crash while upgrading (watchdog shutdown ...) And v 1.06 is history anyways get 1.3 released. The bug is still open. This is a potentially serious problem. Brian ( [EMAIL PROTECTED] ) --- You can never be too good looking or too well equipped. -- Dilbert -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Have a look at the bug report. I dont know why no one has marked it as done yet. There is a file lists in the but report ending in .dpkg-tmp evidently from a crash. Dont be buerocratic about releasing 1.3. On Tue, 20 May 1997, Brian White wrote: *** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** I have done a couple of upgrades to 1.3 and have never noticed there being a problem exept in one instance where the e2prog package was not configured due to a crash while upgrading (watchdog shutdown ...) And v 1.06 is history anyways get 1.3 released. The bug is still open. This is a potentially serious problem. Brian ( [EMAIL PROTECTED] ) --- You can never be too good looking or too well equipped. -- Dilbert --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ObjC runtime (was: Upcoming Debian Releases)
Include the multi-thread support patch for the Objective-C runtime lib (???) According to Scott Christley [EMAIL PROTECTED] (de-facto maintainer of the gcc Objective-C runtime), the Objective-C runtime should be kept in sync with the gstep-base included in the release. bo includes gstep-base-0.2.12 and gstep-base-0.2.12 includes a patch file gcc-2.7.2.1-objc.diff, which therefore should be applied to the gcc in bo (the patch applies fine to gcc-2.7.2.2). The remaining question the thread model to be enabled in the patched objc runtime. The patched runtime can be compiled for e.g. PCthreads, LinuxThreads or no threads at all. Who is to decide this ? Gregor -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ObjC runtime (was: Upcoming Debian Releases)
Gregor Hoffleit [EMAIL PROTECTED] writes: The remaining question the thread model to be enabled in the patched objc runtime. The patched runtime can be compiled for e.g. PCthreads, LinuxThreads or no threads at all. Who is to decide this ? As I understand it, Debian is trying to standardize on LinuxThreads right now, so go with that. Make sure that any libraries (static or shared) provided by the package are compiled with -D_REENTRANT. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
