Re: Remove bdflush*.deb?
Frank Neumann wrote: > Now that the bdflush package has been replaced by update - shouldn't the > binary-/base/bdflush*.deb files be removed for all architectures? > Or are they still need for reasons I fail to see? Just to put things straight: * update was replaced by bdflush * bdflush is now obsolete because of the kflushd kernel process Dominik -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- The text above represents my personal opinion and does not represent the official position of my employer on the issue(s) discussed. Any official statement made on behalf of my employer by me is marked as such.
Purpose of source packages?
Hi! What's the exact purpose of the .tar.gz source packages and the diff? I'm asking because I want to create a package for the metapost system, that's like metafont but produces postscript output. The currently available distribution is a patch against the latest webc, 6.3 I think, which is a tar.gz (>5MB I think). But the webc distrib contains everything that's needed for a whole TeX/MF systems--much more than I need here. Is it possible that I reduce the source so that everyone can recompile the package (and add a short description of my changes) plus a diff that adds debian specific files? Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://www.informatik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-..- "DIE ENTE BLEIBT DRAUSSEN!"
Re: Imagmagick license & various problems
> I've debianized ImageMagick and uploaded it to master, in section > non-free for now. However I think I could move it to the 'graphics' > section as: > 1) The license states it's free (included as attachment) > 2) It doesn't include the GIF compression code > What do you think about this ? Looks ok to me. > A Debian user would like to change the default cache size (16MB) for > the display program to something more suitable for small systems. > I don't want to modify the source unnecessarily. This cache size can > be controlled through a X resource. I'm considering the following > options: > 1) Change this to something smaller (making the manpage wrong) in > /etc/X11/Xdefaults. No, you should be installing the resource in /usr/X11R6/lib/X11/app-defaults. Change it there and in the manpage if you wish. The user can make changes to /etc/X11/Xresources. > 2) Make a postinst script to ask the user about it. (I don't like > this solution, if every package asked small details like this, it > would be a nightmare). I agree that this option is undesirable. > 3) Document the problem in the doc file. That's a more reasonable option. Either way you should install the resource. Note that it should not be a conffile. > BTW, I've sent a message to debian-changes to inform users about the upload > of the package, but the message never came out. What's the procedure to send > a message to debian-changes ? I just saw the message. Guy
Bug#4506: bad value assigned to XVDestDir in XView.cf (xview-dev package)
Package: xview-dev
Version: 3.2p1.2-1
Maintainer: Sven Rudolph <[EMAIL PROTECTED]>
XVDestDir in /usr/X11R6/lib/X11/config/XView.cf set bad location of xview tree.
At least it should reference /usr/X11R6 instead of
/home/sr1/src/xview/xview-3.2p1.2/debian-tmp/usr/openwin to locate shared
libraries at compile time.
Furthermore, XVDestDir doesn't need to be set if xview applications/libs are
installed in standard X-Window tree (see comments at head of XVDestDir settings
in XView.cf).
I tried that by commenting out these settings but falled in trouble when
I tried to install an application under a temporary directory (say /tmp/top).
Entering:
make install DESTDIR=/tmp/top
doesn't install every files under /tmp/top, just binaries
(in /tmp/top/usr/X11R6/bin exactly).
Other files, like support and help files, are put under / (/usr/X11R6/lib/help
exactly) :-(.
In fact, rules to install help/support files (InstallNonExecList and
InstallSupportList) don't prepend $(DESTDIR) before destination directories,
like any X-Window rule does.
Maybe rules be changed like that:
/*
* InstallNonExecList - rule to install a list of help files
*/
#ifndef InstallNonExecList
#define InstallNonExecList(srcs,dest) @@\
install:: @@\
@case '${MFLAGS}' in *[i]*) set +e;; esac; @@\
for i in srcs ;\@@\
do \@@\
echo "installing $$i"; \@@\
- $(RM) dest/$$i ; \ @@\
- $(INSTALL) -c $(INSTDATFLAGS) $$i dest ; \ @@\
+ $(RM) $(DESTDIR)dest/$$i ; \@@\
+ $(INSTALL) -c $(INSTDATFLAGS) $$i $(DESTDIR)dest ; \@@\
done
#endif /* InstallNonExecList */
Best regards.
--
Eric Delaunay | "La guerre justifie l'existence des militaires.
[EMAIL PROTECTED] | En les supprimant." Henri Jeanson (1900-1970)
Bug#4507: XView.tmpl overrides MKDIRHIER (xview-dev package)
Package: xview-dev Version: 3.2p1.2-1 XView.tmpl sets MKDIRHIER to mkdirhier instead of leaving default value from X-Window config files. Since mkdirdier is buggy under Linux (see my other bug report), mkdir -p should be used instead. Just commenting out this setting may reverts changes back to X-Window defaults. Regards. -- Eric Delaunay | "La guerre justifie l'existence des militaires. [EMAIL PROTECTED] | En les supprimant." Henri Jeanson (1900-1970)
Bug#4509: mkdirhier is buggy
Package: xbase Version: 3.1.2-9 mkdirhier claims that it cannot create an already existent dir when two / are consecutives. bash# /bin/sh mkdirhier /tmp/toto//titi mkdir: cannot make directory `//tmp/toto/': File exists On other Unixes that provide a real "sh" Bourne shell, there is no trouble. It seems that bash isn't 100% compatible with sh :-( Does mkdirhier be patched to accept this syntax ? Thanks in advance. -- Eric Delaunay | "La guerre justifie l'existence des militaires. [EMAIL PROTECTED] | En les supprimant." Henri Jeanson (1900-1970)
Re: Remove bdflush*.deb?
Hi, Dominik Kubla wrote: > Just to put things straight: > * update was replaced by bdflush > * bdflush is now obsolete because of the kflushd kernel process I _was_ wrong in thinking update and bdflush had no source packages of their own (thanks, Guy), but I'm pretty sure I'm not wrong in thinking it's the other way around (update replacing bdflush :-). Why would otherwise the update* files have a much newer stamp date and be uploaded in the new source format? Oh well, what the heck, Frank
cpio
The file ftp://ftp.debian.org/debian/unstable/binary-i386/admin/cpio_2.4.2-7.deb seems to be missing...
Bug#4510: CERT Advisory CA-96.20 - Sendmail Vulnerabilities (fwd)
Package: sendmail Version: 8.7.5-4 sendmail 8.7.6 needs to be packaged ASAP. BTW, CERT also says: >Debian Linux: not vulnerable (uses smail) which is misleading. --- start of forwarded message --- Path: kronos.newsfirst.com!nntp.newsfirst.com!nntp.crosslink.net!news2.cais.net!news.cais.net!mr.net!news-out.microserve.net!news-in.microserve.net!news.sgi.com!www.nntp.primenet.com!nntp.primenet.com!cam-news-hub1.bbnplanet.com!das-news2.harvard.edu!cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.sei.cmu.edu!cert-advisory From: CERT Advisory Newsgroups: comp.security.announce Subject: CERT Advisory CA-96.20 - Sendmail Vulnerabilities Date: 18 Sep 1996 14:44:07 GMT Organization: CERT(sm) Coordination Center - +1 412-268-7090 Lines: 586 Approved: cert-advisory@cert.org Distribution: world Message-ID: <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] NNTP-Posting-Host: why.cert.org Keywords: security CERT Originator: cert-advisory@cert.org Originator: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- = CERT(sm) Advisory CA-96.20 Original issue date: September 18, 1996 Last revised: -- Topic: Sendmail Vulnerabilities - - *** This advisory supersedes CA-95:05 *** The CERT Coordination Center has received reports of two security problems in sendmail that affect all versions up to and including 8.7.5. By exploiting the first of these vulnerabilities, users who have local accounts can gain access to the default user, which is often daemon. By exploiting the second vulnerability, any local user can gain root access. The CERT/CC team recommends installing vendor patches or upgrading to the current version of sendmail (8.7.6). Until you can do so, we urge you to apply the workaround provided in Sec. III.C. In all cases, be sure to take the extra precautions listed in Sec. III.D. For beta testers of sendmail 8.8: The vulnerabilities described in this advisory have been fixed in the beta version. We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site. In addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail to identify the most current version of sendmail. - - I. Description There are two vulnerabilities in all versions of sendmail up to and including sendmail 8.7.5. The first vulnerability is a resource starvation problem and the second is a buffer overflow problem. Resource Starvation --- When email is forwarded to a program using a .forward file or an :include: statement within a .forward or alias file, that program is executed as the owner of the .forward file or the file referenced by the :include: statement. Similarly, if email is forwarded to a file, that file is opened as the owner of the .forward file or the file referenced by the :include: statement. The file owner is called the "controlling user." If the message cannot be delivered immediately, the name of the controlling user is written into the queue file along with the other delivery information so that the appropriate permissions can be acquired when the mail queue is processed. Only the name of the controlling user is written in the queue file. This name is derived by calling the system routine getpwuid(3) on the user id of the file owner. If getpwuid fails, the sendmail default user (defined by the DefaultUser option in 8.7 and by the "u" and "g" options in older releases) is assumed. In some cases, the system can be forced into resource starvation, thus forcing getpwuid(3) to fail even though an entry exists in /etc/passwd corresponding to that uid. Since getpwuid has no way of portably returning an error meaning "resource failure" as distinct from "user id not found," sendmail has no way of distinguishing between these cases; it assumes that the uid is unknown and falls back to the default user. By starving sendmail of specific resources, sendmail will create files owned by the default user. Once created, these files can be used to access other files owned by the default user. In addition, these files owned by the default user can be used to leverage access to other privileged users on the system. Buffer Overflows There are several buffer overflows present in sendmail version 8.7.5 and earlier. Some of the buffer overflows could result in local users gaining unauthorized root access. Significant work has been done on sendmail version 8.8 (now in beta test) to eliminate the problem, and the code changes originally planned for 8.8
Planning to make a povray 3.0 package
I'd just like to know if someone's already doing that. If not, I'll do it. Yves. -- Yves Arrouye Email: [EMAIL PROTECTED] 7, avenue Leon BolleeWeb: http://www.fdn.fr/~yarrouye/ 75013 Paris Work: +33 45 95 64 59 France Home: +33 53 61 09 55
Re: dpkg-buildpackage and joe
On Wed, 18 Sep 1996, Dale Scheetz wrote: > dpkg-source -b joe-2.8 > dpkg-source: building joe using existing joe_2.8.orig.tar.gz > dpkg-source: building joe using existing joe_2.8.orig.tar.gz > dpkg-source: error: tarfile `joe_2.8.orig.tar.gz' contains unexpected > object listed by tar as `-rw-r--r-- root/users0 Jan 22 22:45 1995 > joe-2.8.orig/jmacsrc link to joe-2.8.orig/.jmacsrc', expected > `joe-2.8.orig/jmacsrc' > dpkg-source: building joe using existing joe_2.8.orig.tar.gz > If you figure out what's going on here can you let me know? I've run into the same problem while rebuilding for m68kers and was unable to determine the cause. Thanks, Leland __ Y_ a_ m_ b_ o_ | The leanest, meanest, fightinest sweet tater on Earth! oo o oo o o | o o o | [EMAIL PROTECTED] o ooo o | -- -- -- -- -- -- | http://www.millcomm.com/~llucius (maybe one day)
Bug#4511: nvi out of date
Package: nvi Version: 1.34-13 This version of nvi is quite old. Please can it be updated to 1.76 or later? It can be retrieved from: ftp://ftp.bostic.com/pub/nvi-1.76.tar.gz Thanks, -- Robert Leslie [EMAIL PROTECTED]
Bug#4512: psmerge only writes the prolog back
Package: psutils Version: 1.16-3 The psmerge utility only writes the prolog of files it reads. It is even not able to merge a single file (which should be equivalent to a cat). Looking at the source, it looks like some parts of the PS are gobbled without being printed. Yves (who needs psmerge or an equivalent soon :-(). -- Yves Arrouye Email: [EMAIL PROTECTED] 7, avenue Leon BolleeWeb: http://www.fdn.fr/~yarrouye/ 75013 Paris Work: +33 45 95 64 59 France Home: +33 53 61 09 55
Bug#4505: Perl5.003-2 has wrong getopts.pl
The /usr/lib/perl5/getopts.pl is broken: it won't take more than one option
with an argument. More precisely: for Getopts('abcde:fghij'), only -e will
care
about its argument, not -a, -b, -c or -d. The previous version had not this
problem. Here is the old one:
Jean,
Je crois que c'est l'ancienne qui avait un pb. Il faut sans doute ecrire
Getopts('a:b:c:d:e:fghij');
A ce propos, Getopts::Long est tres bien pour les options longues et
courtes.
Yves.
config scripts on root disk
How hard would it be to move the remaining config scripts (the ones that configure network parameters, lilo, etc) off of the root disk and into a debian package? That debian package could then be part of the base system, so it is there when it is needed, but the config utilities will still be present after booting from the installed system. This has been done with modconf, and timezone and kbd both have their own configure utilities (although I'm not sure if they are used by the root disk or if the root disk has it's own copy). -- Scott Barker Linux Consultant [EMAIL PROTECTED] http://www.cuug.ab.ca:8001/~barkers/ (under construction) [ I try to reply to all e-mail within 3 days. If you don't ] [ get a response by then, I probably didn't get your e-mail. ] [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] "I have a very firm grasp on reality! I can reach out and strangle it any time!" - ???
Re: dpkg-buildpackage and joe
On Wed, 18 Sep 1996, Dale Scheetz wrote: > I am converting the joe package to the new source format and have run into > a strange problem. What version of tar are you using? tar 1.11.11 is a beta that changes tar's behavior in all sorts of terrible ways. GNU accidentally released it and then withdrew it. Use 1.11.8-5. The 1.11.11 is currently in our experimental directory, but I think I'll just remove it considering GNU mirrors show 1.11.8 as the latest version again. Guy
My Packages
Hi, I'm very sorry to say that I don't have the time that I need to continue looking after my packages anymore. So anyone that wants to take on the following packages is welcome to mail me and they can have them. First come first serve basically. samba lynx xtet42 xtron ksmbfs xntp ircii ytalk tcsh tf xinvaders mandelspawn and any others i've forgotten about :) Hopefully I'll have time again eventually to contribute to Debian again. Thanks Andrew -- Of course...lager...the only thing that can kill a vindaloo. -- Lister, fighting the vindaloo monster in Red Dwarf `DNA' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: dpkg-buildpackage and joe
On Wed, 18 Sep 1996, Guy Maor wrote: > On Wed, 18 Sep 1996, Dale Scheetz wrote: > > > I am converting the joe package to the new source format and have run into > > a strange problem. > > What version of tar are you using? tar 1.11.11 is a beta that changes > tar's behavior in all sorts of terrible ways. GNU accidentally > released it and then withdrew it. Use 1.11.8-5. Dpkg -s tar reports I'm using 1.11.8-5 ... Next ;-( Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Bug#4513: libpng
Package: libpng1 Version: 0.89c-1 While building on the m68k arch, I received the following from dpkg: dpkg --build /bld/src/new/libpng-0.89c/debian/tmp .. dpkg-deb: building package `libpng1' in `../libpng1_0.89c-1_m68k.deb'. dpkg-deb: maintainer script `postinst' has bad permissions 644 (must be >=0555 and <=0775) __ Y_ a_ m_ b_ o_ | The leanest, meanest, fightinest sweet tater on Earth! oo o oo o o | o o o | [EMAIL PROTECTED] o ooo o | -- -- -- -- -- -- | http://www.millcomm.com/~llucius (maybe one day)
Bug#4514: sendmail security hole
Package: sendmail Version: 8.7.5-4 See the recent CERT Advisory CA-96.20 for more information. It says that Debian is not vulnerable because it uses smail, but that's not completely true, smail is the default but sendmail is also available, and I'm not convinced that smail has no bugs - it's just that it is not as widely used and reviewed as sendmail... The recommended fix is to upgrade to sendmail 8.7.6. Because I needed it and it is not available yet as a Debian package, I packaged it myself (using the Debian 8.7.5-4 diff; the only change was the new version number in debian.rules). Until the "real" release, the package is temporarily available from ftp://ftp.ists.pwr.wroc.pl/pub/linux/debian-local/ 5e9de8e223c9c4f833697684d97b7b2d sendmail-8.7.6-1.deb 01daf0115f3da981c2ecd25e699bcf94 sendmail-8.7.6-1.diff.gz 0f9ef40205226e7f56a17b9cdd3f87ed sendmail-8.7.6-1.tar.gz Note that I am not the official maintainer, and this package is not supported by me in any way. When the official package is available, I think it should go into the "stable" tree. While we are at it: the CERT advisory recommends using smrsh (sendmail restricted shell) which is part of the sendmail source distribution - it is not part of the binary package, maybe it should? Marek
