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 usin
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
Unresolved Overdue Bugs
-- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Unresolved Critical Bugs
-- 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), e
Unresolved Critical Bugs
9020: e2fsprogs- fsck.ext2: can't load library 'libcom_err.so.2' -- 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-- bu
Unresolved Critical Bugs
9020: e2fsprogs- fsck.ext2: can't load library 'libcom_err.so.2' 9127: seyon- seyon depends on X11R6 instead of xlib6 9256: vrweb- Unresolved dependency report for vrweb 9258: sgml-tools - Unresolved dependency report for sgml-tools 9259: j1 - Unresolved dependency report for j1 -- 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
mime-support 2.03-1 released
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Thu, 24 Sep 1996 12:01:22 +0400 Source: mime-support Binary: mime-support Architecture: source all Version: 2.03-1 Distribution: unstable Urgency: low Maintainer: Brian White <[EMAIL PROTECTED]> Description: mime-support - MIME files 'mime.types' & 'mailcap', and support programs Changes: mime-support (2.03-1) unstable; urgency=low . * added "application/x-httpd-php" type * added defaults to install-mime prompts Files: a0e5cfd6eac6a01ee2333512adebbd5b 521 net standard mime-support_2.03-1.dsc 6f6b4a69bf7e732732d2e9fa7f53fb0c 18487 net standard mime-support_2.03.tar.gz aac01bca992bf2012abdb678ff20018a 21288 net standard mime-support_2.03-1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMkgadrwRa6IPcXgFAQHXAwP/fhUqBKRrNUcZlIsYDxQovVmkWE6Gcymt EJksl4C0yg3bcvzZEWBkbunIHKGLCzAuZ54Q0IEP2HgbeJeB3v/EdGNqLbFalGt6 mtpMHnjpKXc1OvTT4ajUZFrl0BaZ1+HNB5IFOW4TzqX9oL6h4obzvQYCGrIcm8Pj oe3WaXV+eAk= =19L9 -END PGP SIGNATURE-
FTP to Master
I am still unable to FTP to master.debian.org callandor:~/tmp> ftp master.debian.org Connected to master.debian.org. 220 primer FTP server (Version wu-2.4(7) Thu Aug 1 02:34:14 MET DST 1996) ready. Name (master.debian.org:bcwhite): 530 User bcwhite access denied... Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp> Could somebody please fix this? Please don't tell me to telnet to master and then FTP back. That would require someplace to FTP back to. Since I'm behind a firewall, I cannot do that. Brian ( [EMAIL PROTECTED] ) --- Generated by Signify v1.00. For this and more, visit http://www.verisim.com/
Bug#4490: Request for Entry: application/octet-stream exe
> Downloads of .exe (DOS *sigh*) files doesn't work correctly > without it. What does it do otherwise? Brian ( [EMAIL PROTECTED] ) --- Searching for something? Look to us! http://www.verisim.com/ferret/
Changelog Format
Could somebody please point me to the "changelog" file format? I'm trying to build the new 'dftp' package but it keeps dieing on the changelog file. Please respond by email since I _still_ have not been able to subscribe to this list. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
signify 1.00-1 released
-BEGIN PGP SIGNED MESSAGE- Date: 27 Aug 96 22:26 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Brian White <[EMAIL PROTECTED]> Source: signify Version: 1.00-1 Binary: signify Architecture: all source Description: signify: Autamatic semi-random signature generator - Signify is a neat little program that allows a random signature to be - generated from a set of rules. Each section can be one of an unlimited - number of possibilities, each with its own weighting so those really cool - quotes can appear more often than others. Sections can also be placed next - to each other vertically to create columns. Each section can be formatted - independently as left/right/center and top/bottom/vcenter. Changes: - First release of a new product! Files: 4bdd2f64ff7d892a5e66685944e89324 8728 mail - signify_1.00-1.tar.gz 000c7bad00dd13cee55e03b88fe064d0 8094 mail optional signify_1.00-1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMiN2X7wRa6IPcXgFAQFZ9gP+JekIzKSxb05VkJiKGwzS7FuL52pcRMol lXM46918s0Hvr/XhLwhNYORVuq295jsIkthMmZlE1RSueiT9XB0t3AH78As6q11U qixQbrniPqgTFObbx6UqE6UddiVv13yX4HoNIM7g9Fjz/jFRB6VDa6NsIREGhSg3 9oP7a6zLSCo= =h4Rg -END PGP SIGNATURE-
dselect/dpkg & multiple versions
I know that at one point the dselect/dpkg combination had fairly serious problems if the same package name existed with multiple versions. I learned this the hard way when I installed from a mirror that had not run to completion and thus had not deleted the older packages. Dpkg installed _both_ versions of the packages at the same time and really got screwed up. The reason I bring this up is that there are now several package that are _intentionally_ in the distribution multiple times with different versions: Debian-1.1-fixed/binary-i386/text/gs_2.62-2.deb non-free/binary/gs_4.01-2.deb Debian-1.1-fixed/binary-i386/text/gsfonts_2.62-2.deb non-free/binary/gsfonts_3.53-3.deb Debian-1.1-fixed/binary-i386/tex/lyx_0.9.23-1.deb contrib/binary/lyx_0.10.1-1.deb These are already causing a bit of a problem with 'dftp' and I'm wondering if they are/will cause problems with dselect/dpkg. *** Bruce *** What's the "official" word on duplicate packages this way? Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#4325: majordomo -- incorrect quoting of '@'
Package: majordomo Version: 1.93-3 The "request-answer" does not properly quote the "@" character (as required by perl-5) it its outgoing mail. The offending lines are: print MAIL <<"EOM"; To: $reply_to From: $list-request Subject: Your mail to [EMAIL PROTECTED] In-Reply-To: $in_reply_to Reply-To: [EMAIL PROTECTED] This pre-recorded message is being sent in response to your recent email to [EMAIL PROTECTED] These should be changed to: print MAIL <<"EOM"; To: $reply_to From: $list-request Subject: Your mail to [EMAIL PROTECTED] In-Reply-To: $in_reply_to Reply-To: [EMAIL PROTECTED] This pre-recorded message is being sent in response to your recent email to [EMAIL PROTECTED] Brian ( [EMAIL PROTECTED] ) --- Want to get it together? We can help! http://www.verisim.com/coordinator/
Bug#4316: cron -- crontab -l prints excess header
Steve Greenland wrote: > > Would you mind stripping these first three lines from the "crontab -l" > > output? > > Yes, because I think there is useful information there (primarily > the second line, with the file name (usually) and date). Could you write them to STDERR and the rest of the info to STDOUT? > Since it's in a script anyway, why not strip it yourself: > > crontab -l |sed -e '1,/^# (Cron version/ d' > > (actually "sed -e '1,3 d'" would proably be sufficient.) I thought about this, but it requries my script to know about the internals of crontab. If crontab ever changed, then a problem could arise. I prefer to keep related functionality as together as possible. > I'm going to close this one. Hold on just a sec... Let's resolve how this is going to be handled, first. Brian ( [EMAIL PROTECTED] ) --- the difference between theory and practice is less in theory than in practice
Bug#4316: cron -- crontab -l prints excess header
Package: cron Version: 3.0pl1-34 Running "crontab -l" has a bad habit of displaying header information that is not actually part of the crontab. For example: $ crontab -l -u gnats # DO NOT EDIT THIS FILE - edit the master and reinstall. # (- installed on Mon Jul 29 14:07:28 1996) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) 5,15,25,35,45,55 * * * * /usr/lib/gnats/queue-pr --run Those first three lines do not appear when using "crontab -e" and they cause problems if trying to modify the crontab using a script since reading the crontab via "crontab -l", modifying it, and the sending the changed data to "crontab" will end up with a duplicate header stored. The output of "crontab -l" would then be something like: $ crontab -l | | crontab; crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (- installed on Mon Jul 29 14:07:28 1996) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) # DO NOT EDIT THIS FILE - edit the master and reinstall. # (- installed on Mon Jul 29 14:07:28 1996) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) 5,15,25,35,45,55 * * * * /usr/lib/gnats/queue-pr --run Would you mind stripping these first three lines from the "crontab -l" output? Brian ( [EMAIL PROTECTED] ) --- the difference between theory and practice is less in theory than in practice
Re: dpkg & accidental overwrite of /usr/man/man1
> >From what I understand, the directory should not be gone - just renamed. Any idea what to? I can't find it. It's not a big deal as I had a backup I could restore from. Brian ( [EMAIL PROTECTED] ) --- the difference between theory and practice is less in theory than in practice
dpkg & accidental overwrite of /usr/man/man1
Eek! I made a goof in a package I'm putting together and dpkg let me get away with it. The problem was that I saved a man page as "/usr/man/man1" instead of the correct name "/usr/man/man1/manpage.1". Dpkg noticed the conflict, but went ahead and toasted the 'man1' directory anyway. It seems dpkg still has the "--force" option enabled for files found in multiple packages and so went ahead with the overwrite. Can we remove this force? Alternatively, could we make it so entire directories can't be replaced by a single file? Brian ( [EMAIL PROTECTED] ) --- the difference between theory and practice is less in theory than in practice
Bug#4297: msql 1.0.16 cannot connect to remote DBs
Package: msql Version: 1.0.16-2 When I try to run any of the msql programs, it fails to connect to remote databases. Connecting to these from a 1.0.14 client works fine. $ relshow -h gate Connect: Connection refused Error connecting to database : Can't connect to MSQL server on gate Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
msql 1.0.14 packages
Does anybody have or know where I can find the msql 1.0.14 packages? The newer ones don't seem to work (for me at least) at all. Please respond by email or copy me on any reply as I have not been able to resubscribe to the debian-devel list lately. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Bug#4261: Ghostview and virtual package postscript_viewer
> No, that isn't what should be done, or at least not the only thing. > I'm on my way to produce a second posctscript-viewer (front-end to gs) > called gv, that is in some ways much better than ghostview, though there > are too many differences in the user interface to drop ghostview instead. Yes, it _is_ what should be done. "install-mime" handles multiple entries for the same mime-type. Thus, if both "ghostview" and "gv" get installed, the user is given the choice of which is to have priority in the mailcap file. Trust me, this will work. It was designed to handle just this case. Please see the "install-mime" man page for more information. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#4261: Ghostview -- needs MIME entry
Package: ghostview Version: 1.5-8 Ghostview should install itself into the /etc/mailcap entry so mime compatible programs can use it to view postscript documents. I suggest making ghostview "Recommends: mime-support" and adding the following to the install scripts: debian.postinst ~~~ if [ -x /usr/sbin/install-mime ] then install-mime --install --package=ghostview --content=application/postscript \ --description="Postscript Formatted Output" --nametemplate="%s.ps" \ --test='test "$DISPLAY" != ""' \ --view='/usr/bin/X11/ghostview %s' \ --comment="Ghostview is a fairly good front-end for viewing postscript \ and should probably be given a reasonably high priority." fi debian.prerm if [ -x /usr/sbin/install-mime ] then install-mime --remove --package=ghostview fi For more information, please see the "install-mime" man page. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
dftp 2.0-1 released
Date: 24 Aug 96 18:05 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Brian C. White <[EMAIL PROTECTED]> Source: dftp Version: 2.0-1 Binary: dftp Architecture: all source Description: dftp: Linux "Debian Distribution" Packages Maintainer - The purpose of this program is to make it easy to keep your local - installation of Linux consistent with the Debian distribution - available on many FTP sites, NFS mounts, or CD-ROM. It does this by - comparing the list of installed packages with those available by FTP - or at a specified directory. A list of packages, categorized to make - selection easier, is then presented to the user to choose what to - install. All selected packages are then fetched if necessary (using - FTP), verified for correctness, and then installed. - . - Dftp can also be run on a non-Debian machine in the case where the - Debian machine does not have FTP access. For this, stand-alone - versions of dftp, in both "csh" and "perl" source, are available under - /debian/contrib/tools. Changes: - Now written in Perl (thanks to Robert Browning) Files: da02e2da88461013aea6c083d8cebbe8 15951 admin - dftp_2.0-1.tar.gz f9ee9efba75ecdd7a0bfaa574b3f787e 38863 byhand- dftp_1.6.csh 04671c397c049e49bde1f7f406f7aed9 44833 byhand- dftp_2.0.pl 057a4841d27b50ce44831a93b7469de5 14312 admin optional dftp_2.0-1_all.deb Please place the ".csh" and ".pl" files in /debian/contrib/tools. Also, please create the following links within that directory: dftp.csh -> dftp_1.6.csh dftp.pl -> dftp_2.0.pl dftp -> dftp.pl Thanks!
Bug#4254: msql config problems
Package: msqld Version: 1.0.16-2 After upgrading from v1.0.14... The /var/log/msql directory is: drwxr-x--- 2 operator msql 1024 Aug 23 15:11 /var/log/msql/ It should be owned by "root.msql" and have the permissions "775". The /etc/msql.acl file is: -rwx-- 1 operator msql 300 Aug 23 15:08 /etc/msql.acl* It should be owned by "msql.msql" and have the permissions "775". *** The install script removed the existing "msql.acl" file I had made. Good thing I make backups! Fixing these and restarting using "/etc/init.d/msqld start" gives the following error (repeatedly)... >Subject:Minerva Daemon Crash Report > Date:Fri, 23 Aug 96 15:46 EDT > From:msql (Mini SQL Database Manager) > To:root > > >Program : msqld >Time : Fri Aug 23 15:46:58 EDT 1996 >Program Output >-- > > >Can't start server : UNIX Bind : Permission denied > > >mSQL Server 1.0.16 starting ... The unix socket is: srwxrwxrwx 1 root root0 Aug 21 15:52 /dev/msql= This should probably be owned by "root.msql", but shouldn't be the cause of this problem. Trying to stop these repeated message by doing "/etc/init.d/msqld stop" gives the following error: callandor:/etc# /etc/init.d/msqld stop ERROR : Can't connect to local MSQL server rm: /var/run/msqld/shutdown: Permission denied rm: /var/run/msqld/shutdown: Permission denied The shutdown file is: -rw-r- 1 root root5 Aug 23 15:52 /var/run/msqld/shutdown Since I ran the stop command as root, the only thing I can think of here is that something is running as user/group "msql" and could thus not access the shutdown file. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
netscape 3.0-1 (stable) released
-BEGIN PGP SIGNED MESSAGE- Date: 23 Aug 96 20:02 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Brian White <[EMAIL PROTECTED]> Source: netscape Version: 3.0-1 Binary: netscape Architecture: i386 source Description: netscape: Popular World-Wide-Web browser software (installer) - Netscape (pronounced "Mozilla") is a graphical World-Wide-Web browser - with many features. It supports advanced features of HTML and new - technologies such as "Java" from Sun Microsystems. - . - Netscape Communications Corporation does not allow redistribution of - their software. Therefore, this package requires the user to fetch - the netscape archive seperately and place it in the directory pointed - to by the TMPDIR environment variable (or /tmp if TMPDIR not defined) - before attempting to install this package. You can get the linux - packages via anonymous ftp from "ftp[1-9].netscape.com". - . - Do NOT try to install any version of Netscape other than 3.0 with - this package! - . - Netscape Communications Corporation does not support the Linux release - in the slightest, even for paying customers. It has been made available - purely as a courtesy, so please do not send them questions about Linux. - . - This installer package has been placed in the public domain! Changes: - STABLE release of Navigator v3.0 Files: bc8440a0ffec5282a5bcbca379ff0ffd 3843 net-netscape_3.0-1.tar.gz 453d1b7a9d9be1c5065cf999bc1d080c 3472 net extra netscape_3.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMh4OmbwRa6IPcXgFAQHnCgP+LH+kdwCl3BIEPFgM30CTnu6809jxTsVz bzerothxqfViffANzAr1cMkPlf4riJKgM/X/fafs3B1yVptUt+STPIdnZJRuXsUg kDf9SoUYa9sEFbPhENalWqE5Uwj5rOWHL4ieOs2+jsVQvcvCX44knm2ll/z7l1o1 UJQn8TmdORY= =8c8h -END PGP SIGNATURE-
Bug#4194: tar ajusts uid/mtime of symlink destination
Package: tar Version: 1.11.11-1 It seems the newest version of 'tar' sets (during extract) the uid/gid and the mtime of the file a symlink points to instead of the symlink itself. Here is a source directory: -rw-r--r-- 1 bcwhite verisim 5731 Jul 21 16:02 database-gdbm.cc -rw-r--r-- 1 bcwhite verisim 1114 Jul 7 00:27 database-gdbm.h lrwxrwxrwx 1 bcwhite verisim16 Jul 14 13:56 database.cc -> database-gdbm.cc lrwxrwxrwx 1 bcwhite verisim15 Jul 14 13:56 database.h -> database-gdbm.h Here is output of 'tar' during extract: ferret/database-gdbm.h ferret/database.cc tar: ferret/database.cc: Could not change access and modification times: No such file or directory tar: ferret/database.cc: Cannot change mode to 0755: No such file or directory ferret/database.h ferret/database-gdbm.cc The extracted directory has: -rw-r--r-- 1 bcwhite verisim 5731 Jul 21 16:02 database-gdbm.cc -rwxr-xr-x 1 bcwhite verisim 1114 Jul 14 13:56 database-gdbm.h* lrwxrwxrwx 1 bcwhite verisim16 Aug 19 17:45 database.cc -> database-gdbm.cc lrwxrwxrwx 1 bcwhite verisim15 Aug 19 17:45 database.h -> database-gdbm.h* (note the permissions of "database-gdbm.h") Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#2895: gnats passwd entry
I'm starting to package the newest version of 'gnats' (currently in late beta). Could I get this resolved soon? > The entry for the "gnats" userid is currently set to... > gnats:*:21:100:uucp:/var/spool/uucp:/bin/sh > > It should be... > gnats:*:16:65534:Gnats Bug-Reporting System (admin):/var/gnats-db:/bin/sh > > If the userid & group should be changed from what I have, please let me > know. The 'gnats' userid currently logs on with group "nobody" which > should probably be changed -- maybe to "user"? "staff"? "root"? "gnats"? Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#4164: Ferret extended description has blank lines
> Ferret extended description field has four empty lines in it. > The correct form is to have a single space followed by > a single full stop character Oops! Okay, it'll be fixed in the next release (soon, hopefully). By the way, for such tiny things, it's usually considered better to just notify the maintainer instead of adding the overhead of a full bug report. If the maintainer doesn't fix it, then a bug report should be submitted so it gets tracked. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
mime-support 2.02-1 released
-BEGIN PGP SIGNED MESSAGE- Date: 15 Aug 96 17:23 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Brian White <[EMAIL PROTECTED]> Source: mime-support Version: 2.02-1 Binary: mime-support Architecture: all source Description: mime-support: MIME files 'mime.types' & 'mailcap', and support programs - As these files can be used by all MIME compliant programs, they - have been moved into their own package that others can depend upon. - . - Other packages add themselves as viewers/editors/composers/etc by - using the provided "install-mime" program. Changes: - Moved documentation into "mime-support" subdirectory (Bug#4106) - Added new "realaudio" mime-type Files: 15a8e45ee23d542a25105c3b7809ad62 19004 net - mime-support_2.02-1.tar.gz 5e2fcf4343716df91ece7eda0dd8ce54 21040 net standard mime-support_2.02-1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhNdSLwRa6IPcXgFAQFM1QQAgIyYjbbo2ox2m2RkEsKMcs3OtJJCl0xv F2nklyzLIqhib+/8PvZH+1TEkGA6oFOElQr/3+YhJiQQKP+qwMNRbaiMXx4lk/4b k3e5WLSB7cPITkn+H1QpLX6Zasn8V5J5ZB7xAxbCPP/m4yNu7v3EX0UJG3YJdzuC vDKWdctZJO0= =XTXy -END PGP SIGNATURE-
Bug#4122: update-rc.d failed
Package: dpkg Version: 1.2.13elf I'm trying to package "genpower" (a UPS monitoring daemon), but am having trouble with the postinst: #! /bin/sh -e # # postinst file for genpower echo "- Installing 'start' ..." update-rc.d genpowerd start 11 1 2 3 4 5 echo "- Installing 'stop' ..." update-rc.d genpowerd stop 99 0 The results of this are: Selecting previously deselected package genpower. (Reading database ... 14718 files and directories currently installed.) Unpacking genpower (from ../genpower_1.0.1-1_i386.deb) ... Setting up genpower (1.0.1-1) ... - Installing 'start' ... Adding system startup links pointing to /etc/init.d/genpowerd ... rc1.d/S11genpowerd -> ../init.d/genpowerd rc2.d/S11genpowerd -> ../init.d/genpowerd rc3.d/S11genpowerd -> ../init.d/genpowerd rc4.d/S11genpowerd -> ../init.d/genpowerd rc5.d/S11genpowerd -> ../init.d/genpowerd shift: shift count must be <= $# dpkg: error processing genpower (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: genpower I could not find any installed packages on my system that use the "start" and "stop" commands instead of "defaults". Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: search engines
> > I've been thinking about what you said regarding search engines for > > "debiandoc". As I understand it, this is to be a debian package, is it > > not? > > At least Debian. I won't get upset if someone ports it to Red Hat, Slackware, > *BSD*, or a Cray... :-) Cray Linux. I've heard somebody is actually working on that! > > What do you think of this idea? > > Thanks for the offer, but alas, it's not workable -- the index needs to be > rebuilt for each system separately, since the set of documents is different > on each system, and Debiandoc is supposed to support locally installed > documentation as well. > > I will, however, make debiandoc and ferret work together, if it isn't > too much work. From my experiments with glimpse a long time ago, it > can index arbitrary directories or files, and outputs a list of filenames > as the result of the search. If ferret can do that, then I'll add support > for it in debiandoc. It shouldn't be hard. Ferret indexes an arbitrary list of words against an arbitrary text string. (The text string is usually a URL or a path name, but it isn't limited to such.) If you could add ferret to the "suggests" field, I'd appreciate it. Brian ( [EMAIL PROTECTED] ) P.S. I was joking about the Cray Linux thing. :-) --- In theory, theory and practice are the same. In practice, they're not.
Re: Caldera's lawsuit against Microsoft
> The terms of the suit require MS to give _Caldera_ details of APIs. Not > the general public, just Caldera. MS can still keep them under non-disclosure, > and Caldera would have to honor the terms of an NDA approved by the court. I noticed this too. It could just be necessary to make the lawsuit plausible, but I'm not so sure. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: CC's on this mailing list
> > If it is relavent to me specifically (eg. relates to one of my packages), > > then I like being copied because it means I won't miss it in the volume > > of the list. > > Is it because you filter to mail folders depending on the To: field (the > only reason I see that would make the messages appear differently)? In > this case, can't you just use your package names as a selection criterion > for which messages are more important for you? Actually, it's because my address on the list is different that my personal address. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
search engines
[ I sent this to Lars, but then thought perhaps the whole list might be interested. Sorry for the duplicate mail, Lars! ] > Lars Wirzenius <[EMAIL PROTECTED]> writes: > > > I don't think we have free software packaged to do full text searches. > > We have glimpse and ferret, neither of which is free. There's something > > that is part of freeWais, but I haven't looked at it yet. Someone with > > the time should find and package one. It should be usable from the > > command line so that it can easily be integrated into Debiandoc. > > It'd be nice to have something like altavista, that could generate a > page containing a (heirarchical) list of the references found. I've been thinking about what you said regarding search engines for "debiandoc". As I understand it, this is to be a debian package, is it not? Debian has been a great help in my company and we'd like to give something back, so how about this... We'll make a version of Ferret that you can include and redistribute with your package completely freely. It will be, however, a query-only version. We'd then licence to you (free, of course) a full version from which you could generate the index that went in the package. What do you think of this idea? An alternative would be to have your package depend on the evaluation version of ferret that exists in the distribution, but I don't think this is a good idea. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: CC's on this mailing list
> I'm considering adding a paragraph to the policy manual telling people > not to CC each other when replying to messages on debian-devel. > > Is it the consensus of the list that this would be a good idea ? It's a difficult call. Quite often I get copies of mail simply because I posted the msg being replied to, even though it is only relavent to the group and not me specifically. If it is relavent to me specifically (eg. relates to one of my packages), then I like being copied because it means I won't miss it in the volume of the list. The best solution I can think of would be a daemon that monitors the lists and if it sees an outgoing message that was copied to someone else, it sends a very polite email saying that the user should be sure to copy the original author _only_ if it specifically relates to him/her. Making sure that such a notice doesn't get mailed to a user more than once a month would also be a good idea. It's more work, but I think it would have the best results in the end. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Emacs per-package startup files
> Hmm. As for dpkg needing install-elisp, I'm not quite sure I buy that,
> because it would seem to argue that *any* install-* should be included
> in dpkg. Then again, there is only install-info which *is* in dpkg,
> and install-mime which is in mime-support which has it's own
> justification. There aren't any others...
I agree that "install-elisp" should be the responsibility of emacs.
Packages that want to use it should put an
if [ -x /sbin/install-elisp ]
then
[...]
fi
around the install/uninstall code. This will allow packages to take
advantage of it if available, but not actually depend on emacs being
installed. This is the line I've taken with mime-support.
There is a disadvantage that installing emacs after installing a
package ("p") that tries to call "install-elisp" will mean that
"p" is completely unknown to emacs until "p" is either reinstalled
or upgraded. I personally don't see this as a problem as upgrades
happen fairly regularly.
Of course, the above problem only exists if "install-elisp" does some
setup work, as "install-mime" does.
> So, do these files go in /var/lib/emacs, /etc/emacs, or
> /usr/lib/emacs/site-lisp, and why? I can set it up and send changes
> to the emacs package maintainers this weekend if that gets worked
> out...
I'd vote for "/usr/lib/emacs/site-lisp". Why? Because "/var/lib/emacs"
is for files that can't be on a read-only filesystem and "/etc/emacs" is
for user config files and the like.
Brian
( [EMAIL PROTECTED] )
---
In theory, theory and practice are the same. In practice, they're not.
Bug#4089: problems with rc.local
Package: base
Version: 1.1
The file '/etc/rc.local' exists, but is not set up properly.
- It has permissions 644 instead of 744
- It is called only by '/etc/init.d/compat' but this file does not
appear
to be linked into any of the "rc" directories. ("compat" also runs
the
file '/sbin/setup.sh')
Brian
( [EMAIL PROTECTED] )
---
In theory, theory and practice are the same. In practice, they're
not.
mime-support 2.01-1 released
-BEGIN PGP SIGNED MESSAGE- Date: 09 Aug 96 15:33 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Brian White <[EMAIL PROTECTED]> Source: mime-support Version: 2.01-1 Binary: mime-support Architecture: all source Description: mime-support: MIME files 'mime.types' and 'mailcap' - As these files can be used by all MIME compliant programs, they - have been moved into their own package that others can depend upon. - . - Other packages add themselves as viewers/editors/composers/etc. by - using the "install-mime" program. Changes: - Added "--quiet" and "--noparmcheck" options to 'install-mime' Files: 17b27592f936cc33ae0a515854aa4883 18758 net - mime-support_2.01-1.tar.gz 3d4c8092a2e97ce78f6af06e63f4ff92 20744 net standard mime-support_2.01-1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgtauLwRa6IPcXgFAQEAggP/REz4Z9vtjJg1Q8g6/UxLq/uW/2nZe549 h+xGN347RkFXvA3DVBuFDVQlGk+pAJLgk8u+WAbxjkgbFrJHf8TOOSn0bsBEuhYS HD8w2zVeTDz/2er7BfHNjqf9fDeWY6Huy1Vb7/oyJVZmc0w4wLr8radHgUVx+QE5 6QHsReYPaRA= =KhfZ -END PGP SIGNATURE-
Re: xpdf needs an entry in mailcap
> As the priority of mime-support is "standard" and therefore higher than the
> one of xpdf ("extra"), I'll add a "Depends: mime-support". If anybody has a
> problem with that, mail me soon, or file a bug report later ...
If you put the "if" clause around the calls to "install-mime", then you don't
have to actually depend on 'mime-support'.
Brian
( [EMAIL PROTECTED] )
---
In theory, theory and practice are the same. In practice, they're not.
Re: xpdf needs an entry in mailcap
> Brian> If you put the "if" clause around the calls to "install-mime", then > Brian> you don't have to actually depend on 'mime-support'. > > That is correct. But would I want this? Now that we have mime-support, > shouldn't I depend on it? It really is a useful feature. I find it reasonable > to enfore this via Depends. Otherwise it fails silently and we gain nada. I think it should depend on it, yes. I just wanted to make sure you knew it wasn't strictly necessary. In the past, some people have complained about depending upon packages that aren't strictly necessary. > BTW: I currently use what you posted earlier as calls to install-mime, but > added a ">/dev/null" as I don't like the verbosity too much. As the output of > # grep install-info /var/lib/dpkg/info/*.postrm | grep -v quiet > is empty on my machine, I think you should add a switch --quiet. I can add the --quiet option, but you must not redirect the output. "install-mime" can become interactive if it encounters a conflict, and with no stdout this would cause problems. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: xpdf needs an entry in mailcap
[ I goofed on the first message. Use this one instead. :-] The "xpdf" postinst needs to add itself to the mailcap file so it can be spawned by web browsers. I suggest the following in the postinst: if [ -x /usr/sbin/install-mime ] then install-mime --install --package=xpdf --content=application/pdf \ --description='Adobe "Acrobat" File' --nametemplate="%s.pdf" \ --view="/usr/bin/X11/xpdf %s" --test='test "$DISPLAY" != ""' fi And the following in the prerm: if [ -x /usr/sbin/install-mime ] then install-mime --remove --package=xpdf fi The 'if' statements can be removed if you want to add a dependancy on "mime-support (>=2.0)". Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Could we use gunzip -c instead of zcat?
> I'd like to suggest that scripts, debian.rules etc... use gunzip -c instead > of zcat when the intent is to get the contents of a gzipped file on stdout. > This is because if binaries from a BSD compress package (not necessarily > built with compress-package) will make a true zcat available on the system, > which of course cannot handle gzipped files. Calling "gzip -dc" would be an even better solution. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
xpdf needs an entry in mailcap
The "xpdf" postinst needs to add itself to the mailcap file so it can be spawned by web browsers. I'd suggest the following in the postinst: if [ -x /usr/sbin/install-mime ] then install-mime --install --package=xpdf --content=application/pdf \ --view="/usr/bin/X11/xpdf %s" --test='test "$DISPLAY" != ""' \ --comment="A generic PDF viewer for X-Windows" fi And the following in the prerm: if [ -x /usr/sbin/install-mime ] then install-mime --remove --package=xpdf fi Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#4011: simple c++ program segfaults
> > Is this actually a bug? I don't think you are supposed to call a > > destructor directly in this situation. I would assume that the crash > > comes when the destructor is called a second time when the program > > exits main. > > It is legal to explicitly call a destructor but rarely needed. It > certainly makes no sense in this case, as the destructor will be called > twice. It is legal, but highly discouraged! If the dtor is not implemented with this in mind (as most are not), then that could very easily be the cause of the seg fault. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
netscape 3.0-beta6-1 released
-BEGIN PGP SIGNED MESSAGE- Date: 07 Aug 96 00:45 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Brian White <[EMAIL PROTECTED]> Source: netscape Version: 3.0-beta6-1 Binary: netscape Architecture: i386 source Description: netscape: Popular World-Wide-Web browser software (installer) - Netscape (pronounced "Mozilla") is a graphical World-Wide-Web browser - with many features. It supports advanced features of HTML and new - technologies such as "Java" from Sun Microsystems. - . - Netscape Communications Corporation does not allow redistribution of - their software. Therefore, this package requires the user to fetch - the netscape archive seperately and place it in the directory pointed - to by the TMPDIR environment variable (or /tmp if TMPDIR not defined) - before attempting to install this package. You can get the linux - packages via anonymous ftp from "ftp[1-9].netscape.com". - . - Do NOT try to install any version of Netscape other than 3.0-beta6 with - this package! - . - Netscape Communications Corporation does not support the Linux release - in the slightest, even for paying customers. It has been made available - purely as a courtesy, so please do not send them questions about Linux. - . - This installer package has been placed in the public domain! Changes: no changes info provided Files: 61f2cffc426f5cfaa376f150f899421b 3869 net- netscape_3.0-beta6-1.tar.gz 5b7a0dde47679d1f42856f35b7c3717b 3480 net extra netscape_3.0-beta6-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgfnS7wRa6IPcXgFAQEq+gP/ayvs/bBx1qctXsiAXkt+tVR8Dfw+lzJM OayTvyOSAQnWh9SdstzXR1Qff/wEqH0DKDiOx0cgMy2VNL0TRjC6Yug5uYhHI/A3 JkDmDO3UUfLphdCNRowhVRhWTUA3EX3SVffgEca3HHHEzoiFg5HV6FwY/Y9mKlp5 p1rvGkUR4E0= =JeBb -END PGP SIGNATURE-
Re: perlconfig creates unnecessary/unusable files.
> [Side Note: I wonder if I should use Ada, Agol, Assembler, C, CSH,] > [Cobol, Eifel, Fortran, KSH, Lisp, Perl, Pascal, Python, SH, or] > [Smalltalk to do it? :-) :-O :-Q :-)] Prolog, definitely! Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Perl vs Python vs ....
> > I'm sure C and Assembler fit "cryptic" too. Just think how much further > > advanced the computer industry would be if neither of those had ever been > > invented. > > As to assembler, there are lots of _very_ different styles of writing it; > there is no one "Assembler" language. It's quite impossible to say > anything general about it. No it's not. Assembler is low-level crunching. It's unstructured, typeless, and unportable. If you want portable asm, go to C. This wasn't about style. It's about "cryptic". Good and bad style is possible in any language. > As to C, while the language does miss some very crucial features and does > make it relatively easy to write cryptic programs, the language itself is > quite clean and orthogonal. Parsing C code, for example, does not have any > of the quirks that parsing, say, FORTRAN or -surprise!- Perl has. Perl's syntax is quite straightforward for a human. It is, however, a language of side-effects. This is what can make it difficult to follow. It's also what gives it part of its power. > I still have trouble > figuring out how to write _readable_ programs in Perl. Funny, I don't. > Sorry, but I disagree very much. Perl is an powerful and effective > language. It is neither fine nor even clean; it is _very_ ugly. And while > some variants of code are indeed easy to write in a clean way, lots of > others aren't. You can't get rid of dependencies on $_, for example. In > that aspect it's a lot more like assembler than like any high-level > language. There are very, very few places you _must_ use $_. Writing clean code is no more difficult than in any other language. It's just easy in perl to write things poorly. I put this blame on the programmer, though, not the language. > > As for the truth of your comment... Language syntax and symantics have > > little to do with a language's success; it's how easy it is to write > > useful programs with. An operating system's success is due primarily > > to the amount of software available for it. (Don't believe me? Look > > at MS-Dos!) > > It doesn't depend on the "easy" factor, either. Look at MS-DOS, indeed - > for a very long time, all the utilities were completely written in > assembler. (Somehow, this didn't make them small and fast.) This point totally escapes me. Dos, like C and Perl is/was successful because of the amount of software available for it. It doesn't matter what the software was written in. > Like anything else, success of languages is mainly an advertizing thing. > And there can be no doubt that Perl has won that one. (So has C++, which > shouldn't have either, based on any technical merits.) I wouldn't call it avertising, but I think I know what you're saying. These languages were "advertised" by other users because they worked. They did the job better than the other choices. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Perl vs Python vs ....
> > I'm sure C and Assembler fit "cryptic" too. Just think how much further > > advanced the computer industry would be if neither of those had ever been > > invented. > > And how much further would the industry be, if C had been typesafe (or > if some other, typesafe language had been used)? The expertise in > language design existed at the time, but C didn't have it. There were typesafe languages in the time of C: Pascal, Modula, etc. Where did they go? They didn't go anywhere because they aren't useful in real applications. Have you ever tried to write a dynamic skip-list in pascal? > And yet, C was adopted as a major standard - because the people who knew > better, didn't bother to speak up. No. It became a major standard because it does the job. C++ is the same way, and so is Perl. They're not the prettiest, but they do the job in an easy and efficient way. > That's not to say that a lot hasn't been accomplished in C - obviously. > But we could have done a lot more, if such a simple thing hadn't been > put off until ANSI. Also, the code I maintained on my first job, > probably would've been a LOT cleaner - many of you are probably in the > same boat. I really hated roaming around fixing somebody else's stray > pointer references. True, but it's more likely that much of the existing code would not have been written at all or would not be as functional. Maintaing poorly structured code is hard, but not as hard as maintaining code that was kludged to get around limitations in the language. > > As for the truth of your comment... Language syntax and symantics have > > little to do with a language's success; it's how easy it is to write > > useful programs with. An operating system's success is due primarily > > to the amount of software available for it. (Don't believe me? Look > > at MS-Dos!) > > Yes, yes, yes, and No, no, no. > > A language's success is typically 95% who backs it, and 5% how good it > is. With the masses, that is. I disagree here, and MS-Dos is a great example. It's not who backs it, but what. Dos was backed by tonnes of software. That's why it's still here. Dos does the job; or did until fairly recently. > However, for a group that knows what it's doing, it should be 5% who > backs it, and 95% how good it is. So it -should- be for debian. The > debian project is in a more than adequate position, to set a > more-positive direction for the unix industry. Yes! Now define "good". Good is how useful it is, not how how nicely it's designed. Perl _is_ useful. Sure, there are other things, even better things, in many ways. But perl is a standard and following a standard is also "good" in many ways. I provides for a lot, even if it lacks in others. Don't get me wrong here, I abhor doing things because "that's the way they've always been done"! Right now, the pros of perl (good user base, almost standard on all unicies, powerful) outweighs the pros of a better language that fewer people know and isn't as common. The cost of changing must also be weighed and affects the decision even if it alone is not sufficient reason. > One way to do that, is to hang onto /bin/sh until something like guile > is ready. Guile is a neat idea, I'll admit. It's almost like a high-level I-code interpreter, except the I-code is scheme. Done correctly, it could make for a fairly painless conversion and still allow people to write in the language of their choice, changing to better ones at their own pace. It's a while out, though. Still, "good, now" is better than "perfect, later". > Another way to do that, is to move beyond perl to something like python > or ML (metalanguage) - right now. It wouldn't take much at all. But what is the cost of that move? How many people have to be retrained? What are the advantages? Do the advantages outweigh the costs? > Once the inertia's there, it's hard to change it. In fact, many people > will become angry with you if you do. But it's often very worthwhile to > take a step back, and look at the long-term ramifications of a decision. People, in general, hate change. I personally have nothing against changing the supported base language if I thought it would gain something significant. Convince me of that and I'll argue your side without hesitation. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Perl vs Python vs ....
Dan Stromberg wrote: > > For this reason we decided that Perl would be on our base disks, and > > that packages could use it (well, the subset that's on the base disks) > > in their preinst/postrm. Packages which want something else must > > Depend on it and may only use it in their postinst/prerm. > > There's clearly a place for a stronger scripting language, despite the > argument posed above. It's just very sad that it should be perl. perl > really fits into many people's stereotypes of "unix as inherently > cryptic monster", very neatly. I'm sure C and Assembler fit "cryptic" too. Just think how much further advanced the computer industry would be if neither of those had ever been invented. (that's sarcasm, by the way) > > There is no point having a religious war over this; this decision was > > taken a long time ago and can't be changed now, even if we wanted to. > > This is rhetoric. It could be changed and you know it. What I mean to > say is, I really dislike "can't" when what's meant is "won't". Of course it can be changed. Anything can be changed! What he was saying, and this is obvious to anyone not specifically trying to play with words, was that it was NOT WORTH THE TROUBLE to change even if we wanted to. > I daresay that a linux distribution (or the Hurd, or *BSD, or...) that > doesn't fall into the perl trap, should have a brighter future. Oh, give it up! Perl is a fine language. Its powerful and is quite easy to write nice clean code with. It's just not _enforced_ that you write nice clean code. It's also very easy to garbage code, but that isn't enforced, either. As for the truth of your comment... Language syntax and symantics have little to do with a language's success; it's how easy it is to write useful programs with. An operating system's success is due primarily to the amount of software available for it. (Don't believe me? Look at MS-Dos!) Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: use of /usr/share
> Erick Branderhorst writes ("use of /usr/share"):
> > Perhaps this is a very sensitive subject but shouldn't architecture
> > independent things like man pages, info manuals, tex & latex styles
> > and a lot of other things being put under a subdir of /usr/share?
>
> The FSSTND people haven't really settled on this yet, and are now
> diverted.
On our network here, we've had great fun with all this. Basically,
there
are four needs:
- System installed files (i.e. debian packages)
- Machine-local installed files
- Network mounted arch-dependant files
- Network mounted arch-independant files
yet there are only three locations
- / and /usr
- /usr/local
- /usr/share
Our general solution was to create a fourth and allocate them as
follows:
- / and /usr : System installed files
- /usr/local : Machine-local installed files
- /usr/site : Network mounted arch-dependant files
- /usr/share : Network mounted arch-independant files
Brian
( [EMAIL PROTECTED] )
---
In theory, theory and practice are the same. In practice, they're
not.
debian-private
Is debian-private running, or have I just been removed from it? I sent a message to it a couple days ago regarding the "WebPages" directory now in the distribution, but never saw it, nor any other messages to debian-private, appear. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: 1.2 source archive and packaging issues
> Since we're going to be > moving every file in "unstable" anyway, that sounds like a good time to > switch from "unstable" to a symbolic-linked directory (tentatively called > "rex"). I recommend putting "rex" under a subdirectory called "releases" or something, just to reduce clutter and confusion in the root directory. > With ports on the horizon, we should be making sure that an automatic build > of Debian in its entirety is more than a _theoretical_ possibility. Cool! Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Bug#3309: Netscape doesn't provide www-browser
> I've just discovered, when installing xntp-doc-3.5c-1, that netscape > doesn't declare itself as providing a "www-browser", causeing xntp-doc > to be left unconfigured. Thank you! I've made the fix in the source and it will be uploaded shortly. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Organizing "non-free"
> >> > Sorry to bother you again, but I thought non-free was precisely for > >> > packages which may not be sold on CDs. Now I am confused. > >> > >> You're not the only one. For example, shareware programs can be "sold" on > >> CD > >> but require payment for use. I'd be more specific, but I can't get to > >> "master" at the moment. I'd better send Simon a note... > > > >This is one of the things I would like to improve about non-free's > >organization. It would be a "Good Thing" (tm) in my opinion to at least > >differentiate between "non-free to distribute" and "non-free to use". > > Umm, "non-free to distribute" shouldn't be on /any/ ftp site, right? Not always. Just because something isn't "freely distributable" doesn't mean that has not distributable by any specific medium, just that it can't be distributed on all mediums. Many programs can be made available over FTP and yet prohibit distribution on CD-Rom. As a person who writes some shareware applications, I would like to be able to put in the distribution knowing that CD-Rom manufacturers will pick it up. If users choose to use it, then they have to pay for it. In the end, everybody wins. I win because I have a bigger distribution channel. Users win because they have more readily available applications. Debian wins because it will have more users and higher satisfaction. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
