Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
[EMAIL PROTECTED] (Manoj Srivastava) wrote: > Oh yes, pathanmes with .. components would _also_ break the > algorithm. Kai Henningsen <[EMAIL PROTECTED]> writes: >Of course, those break everything. I'd insist of having no tarballs even >in the Debian source archive that contain those. > >A different problem is absolute path names (/X/Y/Z). GNU tar automatically >discards the "/" (which may, in fact, be related to distributions like the >above example) on both tarring and untarring, as far as I remember, unless >you explicitely tell it not to; but other tars don't. I think the ".. pathname component" problem deserves some attention. What does anybody think about these steps? 1) Incoming Debian source packages should be automatically scanned, and offending files flagged. 2) GNU tar should refuse to unpack such a tar file, unless enabled by a switch. 3) GNU tar should refuse to create such a tar file, unless enabled by a switch. - Jim Van Zandt -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9582: suidmanager 0.6 uploaded to master.debian.org
To my knowledge
set -e
is only valid for the currently executing scripts and not a subshell.
On Thu, 15 May 1997, Karl M. Hegbloom wrote:
>> "Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes:
>
> [... in a release announcement ...]
>Christoph> May fix situations leading to something described in
>Christoph> #9435, #9582 (still not clear how such a thing can
>Christoph> happen).
>
> This fixes the bug. With set -e, the grep on line 75 (X=...) causes
>the script to abort if the regex is not found in the configuration
>file, which is what will happen if it was not already there.
>`suidregister` ran fine from a commandline, since 'set -e' is not in
>effect then. But from a postinst, it is.
>
> I think that maybe 'set -e' should have file scope.
>
> Here's the patch:
>8<->8
>*** /usr/sbin/suidregister~Sun Apr 27 12:44:37 1997
>--- /usr/sbin/suidregister Sun May 11 00:01:43 1997
>***
>*** 3,8
>--- 3,15
> # Register a binary
> #
>
>+ if echo $- | grep -q e; then
>+ e=-e
>+ set +e
>+ else
>+ e=+e
>+ fi
>+
> function setperm()
> {
> if [ -e $2 ]; then
>***
>*** 80,82
>--- 87,91
>
> echo "$PACKAGE $1 $2 $3 $4" >>/etc/suid.conf
> setperm $PACKAGE $1 $2 $3 $4
>+
>+ set $e
>8<->8
>
>--
>Karl M. Hegbloom <[EMAIL PROTECTED]>
>http://www.inetarena.com/~karlheg
>Portland, OR USA
>Debian GNU 1.2 Linux 2.1.36 AMD K5 PR-133
>
>
>
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Behaviour of "Conflicts:"
On May 13, Todd Harper wrote > > I'm curious about how dpkg handles the "Conflicts:" line of packages > that are already installed on the machine. If package X conflicts > with package Y, and Y is already installed, I cannot install X. This > is normal. BUT... if X is installed, what happens if I try to install > Y? Y doesn't say that it conflicts with X. Does dpkg somehow scan > thru the installed packages' control files to check for conflict? > I would hope that dpkg would somehow catch this and prevent the > installation of Y. This could be a serious problem otherwise. When starting up, dpkg loads into memory all the details concerning the packages currently installed on the system. This include conflicts, provides, etc. for each installed package. So in this case dpkg will still refuse to install conflicting Y. (Unless, of course, you use --force-conflicts.) Christian pgpe88qzzl8yV.pgp Description: PGP signature
Re: Search engine for bug-track
> Why isn't there a glimpse or dig search on the bugtracker list??? I have had httdig set up to index (parts) of the web site for quite a while. I have chosen to not index the bug tracking yet as there seems to be a problem with Roxen that is causing reindexing to start from scratch every time. Given the size of the bug tracking (something like 80M) I felt it was a waste of resources. A new version of Roxen is supposed to be installed on master soon and I am hoping this will fix the problem. - Sue -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
Brian Mays <[EMAIL PROTECTED]> writes: > rxvt (and rxvt-xpm) always exports the variable "COLORTERM" so that programs > can check for color support. As a side note, when XPM support has been Unfortunately, I know of no programs that make use of this variable. In fact, I believe that ncurses doesn't even use it. > compiled into rxvt (as with rxvt-xpm supplied in Debian's rxvt package), the > value of COLORTERM is set to "rxvt-xpm" instead of "rxvt". Which could be a bug in itself since Debian has no rxvt-xmp terminfo entry. [zap] > I can rebuild rxvt to set TERM=xterm-color (there are not many differences > between the terminfo entries for rxvt and xterm-color). However, if we are > to > do things absolutely the correct way, I suppose that Debian should provide a > "rxvt" terminfo entry and a "rxvt-color" entry (with color support as the > only > difference between the two). Then rxvt would set TERM=rxvt-color when > running > on a display with Xdepth > 2 and TERM=rxvt otherwise. I would suggest that rxvt set TERM to rxvt when on a color display and to xterm when on a non-color display. The rxvt entry in terminfo already has color support; the xterm entry is monochrome. Since rxvt is backwards-compatible with xterm, this would seem to be the proper method. It would cause the least fuss while ensuring proper behavior in all situations. Even if this isn't done, I suggest that the default be set to rxvt. After all, we have the terminfo entry for it, it doesn't make any sense not to use it. I suspect that rxvt would behave properly in this case even if it is on a 1-bit (B&W) display. -- 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: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
On May 15, John Goerzen wrote > Brian Mays <[EMAIL PROTECTED]> writes: > > rxvt (and rxvt-xpm) always exports the variable "COLORTERM" so that > > programs can check for color support. As a side note, when XPM support > > has been > > Unfortunately, I know of no programs that make use of this variable. In > fact, I believe that ncurses doesn't even use it. The S-Lang library support it. For a demonstration: start up rxvt (I've used 2.20-4) and fire up mutt. You'll have colour support, with $TERM == xterm . Now start it up "env -u COLORTERM mutt". It'll be black&white. 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: Bug#9582: suidmanager 0.6 uploaded to master.debian.org
> "Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes: Christoph> To my knowledge set -e Christoph> is only valid for the currently executing scripts and Christoph> not a subshell. Try it and see. It is why `suidregister` is not working when called from postinst scripts. The grep in `suidregister`[1] fails, returning code 1 when it cannot find the regex in the "/etc/suid.conf" file, and since '-o errexit' (aka 'set -e') is on, the `suidregister` script exits. I think that this is counterintuitive, and that '-o errexit' should have file-local (and even function-local) scope. It seems like a bug in BASH to me. `suidregister` works fine from a commandline, since '-o errexit' is not set then.[2] After it's been run once, and the entry that gets `grep`ped for has been written to "/etc/suid.conf", it works fine from inside a postinst too, since then the `grep` doesn't return code 1, as it has something to find this time. Footnotes: [1] In the line that reads "X=..." [2] Or the shell will exit on any error return; I tried it. -- Karl M. Hegbloom <[EMAIL PROTECTED]> http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.2 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
On May 16, J.H.M.Dassen wrote > On May 15, John Goerzen wrote > > Brian Mays <[EMAIL PROTECTED]> writes: > > > rxvt (and rxvt-xpm) always exports the variable "COLORTERM" so that > > > programs can check for color support. As a side note, when XPM support > > > has been > > > > Unfortunately, I know of no programs that make use of this variable. In > > fact, I believe that ncurses doesn't even use it. > > The S-Lang library support it. For a demonstration: start up rxvt (I've used > 2.20-4) and fire up mutt. You'll have colour support, with $TERM == xterm . > Now start it up "env -u COLORTERM mutt". It'll be black&white. Which makes for a very confusing setup, as COLORTERM doesn't get propagated by telnet, ssh, etc. It took us a while to figure out under what circumstances we got color. What problem is COLORTERM trying to solve? It's very non-standard. Also, I'd hope that if xterm now does color as standard, that fact is reflected in its terminfo entry. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9582: suidmanager 0.6 uploaded to master.debian.org
I have tried it and set -e is not propagated into a subprocess. This is the script I ran successfully: #/!bin/sh set -e suidregister /etc/exports clameter clameter 4755 Please investigate what is wrong with your system. On Fri, 16 May 1997, Karl M. Hegbloom wrote: >> "Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes: > >Christoph> To my knowledge set -e > >Christoph> is only valid for the currently executing scripts and >Christoph> not a subshell. > > Try it and see. > > It is why `suidregister` is not working when called from postinst >scripts. The grep in `suidregister`[1] fails, returning code 1 when >it cannot find the regex in the "/etc/suid.conf" file, and since '-o >errexit' (aka 'set -e') is on, the `suidregister` script exits. > > I think that this is counterintuitive, and that '-o errexit' should >have file-local (and even function-local) scope. It seems like a bug >in BASH to me. > > `suidregister` works fine from a commandline, since '-o errexit' is >not set then.[2] After it's been run once, and the entry that gets >`grep`ped for has been written to "/etc/suid.conf", it works fine from >inside a postinst too, since then the `grep` doesn't return code 1, as >it has something to find this time. > > >Footnotes: >[1] In the line that reads "X=..." > >[2] Or the shell will exit on any error return; I tried it. > >-- >Karl M. Hegbloom <[EMAIL PROTECTED]> >http://www.inetarena.com/~karlheg >Portland, OR USA >Debian GNU 1.2 Linux 2.1.36 AMD K5 PR-133 > > > --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
In article <[EMAIL PROTECTED]>, Bart Schuller <[EMAIL PROTECTED]> writes: > Also, I'd hope that if xterm now does color as standard, that fact is > reflected in its terminfo entry. No, because if you do that, programs like slrn will try to use colour, which means they are almost impossible to read and leave you with silly colours like white on black when you quit. (on a vconsole, slrn's colours are easier and white on black is normal so it doesn't matter that that's what you get when you quit) If they (and presumably all slang programs) are fixed to do something sensible with colours, then maybe.
anyone want to package "jade"?
Given that we already have "sp" and a bunch of other sgml tools, it would be nice if someone packaged jade as well -- since it has decent conversion tools, as metioned below... [from http://www.jclark.com/jade/] What is Jade? Jade is an implementation of the DSSSL style language. The current version is 0.7. This should be considered a beta test version. Jade Copyright Jade is licensed under the same terms as SP. This imposes almost no restrictions even for commercial use. Jade includes the following components: [stuff elided, this is the bit I care about:] o A command-line application, jade, that combines the style engine with the spgrove grove interface and four backends: o A backend that generates an SGML representation of the flow object tree. The DTD for the SGML generated is in jade/fot.dtd. o A backend that generates RTF. This has been tested with Microsoft Word 97 and Microsoft's free Word Viewer 97. Previous versions were tested with Word 95 and Word Viewer 7.1. o A backend that generates TeX. Although the C++ part of this is almost complete, much work remains to be done on writing the TeX macros on which the generated TeX code depends. (This backend was contributed by David Megginson.) o A backend that generates SGML. This is used in conjunction with non-standard flow object classes to generate SGML, thus allowing Jade to be used for SGML transformations. The source is in the jade directory. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
Hi, >>"Jim" == Jim Van Zandt <[EMAIL PROTECTED]> writes: Jim> I think the ".. pathname component" problem deserves some Jim> attention. What does anybody think about these steps? Jim> 1) Incoming Debian source packages should be automatically Jim> scanned, and offending files flagged. Jim> 2) GNU tar should refuse to unpack such a tar file, unless Jim> enabled by a switch. Jim> 3) GNU tar should refuse to create such a tar file, unless Jim> enabled by a switch. I hope you mean ask the upstream authors to change GNU tars behaviour, and not that Debian should do a major change in behaviour on it's own. In case we even consider doing such a thing, it should be *off* by default, and turned on (by dpkg and friends) with a special switch. manoj -- "I went to a job interview the other day, the guy asked if I had any questions. I said yes, just one, if you're in a car traveling at the speed of light and you turn your headlights on, does anything happen? He said he couldn't answer that. I told him sorry, but I couldn't work for him then." Steven Wright Manoj Srivastava mailto:[EMAIL PROTECTED]> Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: a "Debian System Method" for dpkg
Request for comments: a "Debian System Method" for dpkg Because of its owner having forgotten the debian-CD in a train, I recently had to install a debian system on a PC. We still had the installation floppies we had used for another machine on the same ethernet, and had access to that machine, which had a dpkg-repack. So I repacked the needed packages, moved repacked netstd to the new system with a floppy :-( and the others with FTP, and installed them by hand. No need to say I forgot some dependencies, and had to repeat these steps several times with missing packages... That left me some time to think about that: * an automated version of what I was doing would have been interested, but here, the situation was an exceptional one... * anyway, for a network of debian machines, we could arrange to have only one machine installing/upgrading by FTP, and the others installing/upgrading from that one without it having to waste disk space with all already installed deb files. * a full repackaging might not be necessary, as it is time-consuming on "slow" machines (I'm speaking here about a P75 !) for large packages (multi-megabytes ones), but it should at least partially be done. * packages descriptions (those from Packages files) should be made available from one machine to another (I don't think they are kept as-is after install, so they would have to be rebuild, at least partially). * I see 2 different solutions: - NFS-mount the source machine, and execute all on the target machine. That's only realistic if NFS maps root on target to root on source, and that might not be always the case. - dialog between the 2 machines: this makes the source machine execute programs (build description, repack), so maybe a daemon process would be interesting, for security reasons. * conffiles would have to be handled correctly: maybe default conffiles should be always kept (*.dpkg-dist), and repack should be able to recognize them (with md5 ?). etc., probably... -- 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] .
RFC: a "debian-daemon" project
Request for comments: a "debian-daemon" project Using FTP for a while to keep my system up-to-date, I see several things that, I think, cannot be done easily: * Data transfer minimization (with rsync-like algorithm) where that could be applied. That does not include, eg, compiled binaries, but would fit well for sources packages in tar format (gzipped version could still be used for full downloads), Packages files (same comment), probably most packages in binary-all (if we can have a non-compressed tarfile inside the deb file); * Getting changes between installed and available versions, to allow users to download a new version only when they have use of it; ...and probably more that I don't remember right now; please be free to add to this list... That could probably be done by extending the FTP protocol (or another one, like FSP, but I don't know much about that one) to support rsync algorithm. Further more, such a daemon could be made to fully monitor the distribution-site: the site-mainainer would just "send" (maybe locally :-) the new files to the daemon, which would automagically ensure site coherence, including keeping Packages (and other) files up-to-date, removing old versions from experimental when a newer has come into unstable (noone told be I was wrong here, so I persist ;-), maybe automatically find out between what versions the rsync algorithm would be profitable, etc. -- 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: RFC: a "Debian System Method" for dpkg
The beginning of support for such a scheme is in the works for the next major release of dpkg-ftp. The user interface part is taking me a bit longer than I had hoped --- expect a release in maybe 5--10 days. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
uploading makedev (glibc2/libc6 release) to unstable (i386)
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Thu, 24 Apr 1997 19:12:58 +0200 Source: makedev Binary: makedev Architecture: source i386 Version: 1.6-5 Distribution: unstable Urgency: low Maintainer: Andreas Jellinghaus <[EMAIL PROTECTED]> Description: makedev- Creates special device files in /dev. Changes: makedev (1.6-5) unstable; urgency=low . * libc6 release * added postinst script to change tty/pty devices to new major numbers (the next time you boot). * changed all serial devices from root.dialout to uucp.dialout * added generic-ARCH batches * changed (u)random permissions from 444 to 644 * corrected mcd/mcdx handling. * small bugfix in manpages. Files: 216e79340f087cd28664529f670d6fc4 617 base required makedev_1.6-5.dsc d7c99d9ffe2e5539af3b10f9c9ca29c3 25918 base required makedev_1.6-5.diff.gz 21a62733fc5968f1d4bce3a4fdc7442f 39114 base required makedev_1.6-5_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAwUBM3y+y0xSSKgO9S5RAQEJCwQApZKdtBzYIUQmJvDa8lUH9cF41mzIRD7L T4SSclTdUMjCJHYh+CYBfZkB8ardrq7XugkyGf/iDmIzB5hSJfHw30TD9AyvsQIA pWDbsqzgF/KzeNJG1YgkVG7bccB+PP9ehSLooKxNZotif5lJNg9sJi6GacMDuJVH Cuw8ZvAiONM= =fV2W -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Bugs in shadow-970502-2
The latest release (shadow-970502-2) has a bug in libmisc/mail.c
that causes login to segfault when checking for new mail. Yes,
I have tested this version before releasing it (really!), but
unfortunately I had MAIL_CHECK_ENAB disabled (by mistake) on my
machine and the bug didn't show up.
Workaround: edit /etc/login.defs and set MAIL_CHECK_ENAB to "no".
Fix: apply this small pseudo-patch to libmisc/mail.c -
- if (!(maildir = getenv("MAILDIR"))) {
+ if ((maildir = getenv("MAILDIR"))) {
This really stupid bug was introduced by me when I added Qmail
support - that's what I get for late night (== early morning)
hacking :).
serek.arch.pwr.wroc.pl has no files, and my account on that machine
doesn't exist anymore. I don't yet know what happened. But
ftp.ists.pwr.wroc.pl is back, and shadow-970502-2 is there -
ftp://ftp.ists.pwr.wroc.pl/pub/linux/shadow/beta/shadow_970502-2.tar.gz
(still with the bug).
Unfortunately, it will be a few more days before I can release
the new, fixed version. Sorry for any inconvenience.
Marek
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
