Re: What hack in ld.so?
On Jan 30, 1999, Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > On 30 Jan 1999, Alexandre Oliva wrote: >> I agree there is a problem to be fixed, I just think that libtool >> is not the only piece of software that may have to be changed to >> fix it, because it is not the only piece of software that uses >> -rpath. > libtool is however the only piece of software that we cannot easially > change. Huh? You (or someone else, I've (not) been introduced to too many Debian Developers lately to be able to remember who said what :-( mentioned editing Makefiles to adapt packages to Debian's policies, then I said one could just as easily edit the libtool script, and I have even posted a script that would do that for you. If you're talking about introducing a quick hack in libtool to never use rpath, forget about it, it won't work in general. If you're willing to contribute a patch to libtool that selectively drops rpath flags for directories listed in /etc/ld.so.conf, as I have suggested in another message I posted today, that's great. > It doesn't really matter who is to blame Wouldn't the Devian developers complain that libtool isn't not properly arranging that their programs run even in non-Devian distributions? If they were to be as inflexible as you, we'd probably have to support switches like -devian-hardcoding-policies and -debian-hardcoding-policies, and I'd certainly have dropped the maintainership of libtool just after that (or just before) Thanks God I've got only one group of developers almost forcing me to change something that is correct, and whose change wouldn't even help them work around a problem they're facing. > because it -can- be fixed and fixed fairly easially by the > installer, the -rpath situation -cannot- be fixed at all by the > installer, I think that is the key difference to realize. Ulrich Drepper has already mentioned that it's quite easy to modify the hard-coded rpath of a program without recompiling it, and that there's even a tool that will do that. It has just occurred to me that you should hack `ld' so that, whenever it finds a -rpath switch, it prints a warning message like: *** WARNING: YOU HAVE USED THE NEFAST --rpath SWITCH. THIS WILL CAUSE *** YOUR PROGRAM NOT TO WORK ON FUTURE Debian RELEASES BECAUSE WE *** DON'T CARE ABOUT (L)USERS WHO USE --rpath. YOU WERE ADVISED! :-D -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: What hack in ld.so?
On Jan 30, 1999, Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > So you would have /usr/lib/libfoo.2 as rpath, but > really would use /usr/lib/libfoo-libc6.2 or libfoo-libc5.2, you get the > idea. Just a minor nit: rpaths and sonames are independent of one-another. Although it is possible to arrange that sonames contain full pathnames, that's not what happens if you link a program with --rpath /usr/lib -lfoo. The --rpath switch will just add /usr/lib to a hard-coded search path, and -lfoo will just add the soname of libfoo to the list of run-time dependencies of a program. It is possible, though, to create a shared library with `-soname /usr/lib/libfoo.so.2', but then it becomes absolutely impossible to move the library around. There are times when this behavior is desirable, but libtool never does this, and there is no way to tell libtool to do it. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: What hack in ld.so?
On 30 Jan 1999, Alexandre Oliva wrote: > > libtool is however the only piece of software that we cannot easially > > change. > then I said one could just as easily edit the libtool script, and I > have even posted a script that would do that for you. Ah I missed that script, maybe we should just use that for the time being? (Sure we would be saying screw every other linux system, and binaries compiled with libtool on an old libc5 system will still not work, but hey) > Thanks God I've got only one group of developers almost forcing me to > change something that is correct, and whose change wouldn't even help > them work around a problem they're facing. I'm sure you have lots of screwball stuff to support defective and broken systems in libtool, I don't see how doing something 'wrong' to support another broken system like Linux is so bad. You cannot deny that it is necessary, and that it effects more that just Debian and our users but everyone using a libc5/libc6 linux system. It is not a problem we are 'facing' it is one we already faced and arguably made the wrong choice - So now all linux systems have this horrifying defect. Oh Well. That's Life - we can't fix it. > Ulrich Drepper has already mentioned that it's quite easy to modify > the hard-coded rpath of a program without recompiling it, and that > there's even a tool that will do that. I actually think we have a program that does it as well, but somehow adding something to a file in /etc vs 'stripping' every binary you install on your system does not seem comparable. > > It has just occurred to me that you should hack `ld' so that, whenever > it finds a -rpath switch, it prints a warning message like: At the very least the linker man page should have a warning to this effect, and as I said before, this is not a debian specific problem, your program could very will not work on any other linux system, including future releases of ours. Arguably that is what rpath is for, as strange as it seems :< Say, has anyone asked the glibc people if they will change ld.so to have a different rpath behavior? Then we would be different than other systems, but it might be worth it. Jason
Re: What hack in ld.so?
Date: Sat, 30 Jan 1999 16:06:04 -0700 (MST)
From: Jason Gunthorpe <[EMAIL PROTECTED]>
On 30 Jan 1999, Alexandre Oliva wrote:
> Obviously, this would have never been needed if old libraries had not
> been replaced with (in)compatible versions, but the maintainers of
> Debian have already taken this step, despite the fact that this would
Look, it was not us that decided to do this. It was the upstream
maintainers, other dists and a huge combination of factors. It is not in
our power to choose a different direction to solve these problems, we must
have libc6 xlib called libX11.so.6 and we must have libc5 called
libX11.so.6 - that is what all the other dists did, that is the default
and expected compilation behavoir of xlib and it is what all the new glibc
binary-only programs are using (ie netscape)
If you want to say that is a dumb way then fine, but you have not proposed
an alternative to solving the versioning problem and you have not proposed
an alternative way to handle the requirement of identical sonames and
libtool continues to perpetuate this 'bad' behavoir and makes it worse by
providing no way to get around it with the standard linux ld.so
What you are saying, I think, is that you have two programs with
A) DT_NEEDED libc.so.5, DT_NEEDED libX11.so.6
B) DT_NEEDED libc.so.6, DT_NEEDED libX11.so.6
Neither has DT_RPATH. The system has four libraries:
libc.so.5
libc.so.6
libX11.so.6 with DT_NEEDED libc.so.5
libX11.so.6 with DT_NEEDED libc.so.6
You want programs A and B to both work, without modification.
This was done by modifying the search algorithm used by the dynamic
linker so that it chooses the version of libX11.so.6 which matches the
version of libc.so.N used by the program. This was done by recording
in /etc/ld.so.cache the version of libc which the shared library uses.
The dynamic linker was modified to look in /etc/ld.so.cache for
libraries which were not found in DT_RPATH, but to only select
libraries listed in /etc/ld.so.cache which matched the version of the
dynamic linker being used. Programs which are linked against
different versions of libc must then use different dynamic linkers.
There are in fact three different dynamic linkers which understand
this ld.so.cache algorithm: the old a.out dynamic linker, the libc5
dynamic linker, and the glibc dynamic linker.
I just spent some time looking at the ld.so sources. Interestingly,
it seems to me that everything will work correctly in the sources I
was looking at. That is because the libc5 dynamic linker on my system
(RedHat 5.2) was modified to search the library cache before using the
application's DT_RPATH.
I think that is a hack that Debian is missing: it is the final hack to
the libc5 dynamic linker to change the search path to account for the
moved shared libraries even when rpath is used. I have appended the
RedHat patch below. This is to ld.so-1.9.5. Of course, this will
technically break the handling of DT_RPATH. However, we've already
determined that DT_RPATH binaries will not work correctly anyhow,
because the shared libraries were moved. So using this patch should
not make us any worse off.
Indeed libtool causes such a severe problem that if you take a libtool
program, compile it on a libc5 Slackware and try to run it on -any- glibc
system IT WILL NOT WORK.
This is not quite right. As I described above, glibc and libc5
binaries use a different dynamic linker. So the behaviour of your
libc5 binary depends upon the behaviour of your libc5 dynamic linker.
That linker does not come from glibc. Although I can not test this, I
now believe that if you take a libtool program, compile it on a libc5
Slackware and try to run it on a RedHat 5.2 system, it will work.
Ian
--- ld.so-1.9.5/d-link/readelflib1.c.ewtMon Nov 17 10:04:15 1997
+++ ld.so-1.9.5/d-link/readelflib1.cMon Nov 17 10:23:15 1997
@@ -179,38 +179,10 @@
goto goof;
}
- /*
- * The ABI specifies that RPATH is searched before LD_*_PATH or
- * the default path of /usr/lib.
- * Check in rpath directories
- */
- for (tpnt = _dl_loaded_modules; tpnt; tpnt = tpnt->next) {
-if (tpnt->libtype == elf_executable) {
- pnt1 = (char *)tpnt->dynamic_info[DT_RPATH];
- if(pnt1) {
- pnt1 += (unsigned int) tpnt->loadaddr + tpnt->dynamic_info[DT_STRTAB];
- while(*pnt1){
- pnt2 = mylibname;
- while(*pnt1 && *pnt1 != ':') {
- if (pnt2 - mylibname < 1024)
- *pnt2++ = *pnt1++;
- else
- pnt1++;
- }
- if (pnt2 - mylibname >= 1024)
- break;
- if(pnt2[-1] != '/') *pnt2++ = '/';
- pnt = libname;
- while(*pnt) *pnt2++ = *pnt++;
- *pnt2++ = 0;
- tpnt1 = _dl_load_elf_shared_library(mylibname, 0);
- if(tpnt1) return tpnt1;
- if(*pnt1 == ':') pnt1++;
- }
- }
-}
- }
-
+ /* EWT - change thing
Re: What hack in ld.so?
Date: Sat, 30 Jan 1999 16:52:48 -0700 (MST) From: Jason Gunthorpe <[EMAIL PROTECTED]> > That's not what I'd like libtool to do. I agree there is a problem to > be fixed, I just think that libtool is not the only piece of software > that may have to be changed to fix it, because it is not the only > piece of software that uses -rpath. libtool is however the only piece of software that we cannot easially change. I don't understand the reasoning here. The libtool files that a package will use are distributed with that package. If you are willing to modify a package's Makefile to remove -rpath, then it ought to be just as easy or difficult to modify the package's ltconfig file. Ian
Re: What hack in ld.so?
On Jan 30, 1999, Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > On 30 Jan 1999, Alexandre Oliva wrote: >> Thanks God I've got only one group of developers almost forcing me to >> change something that is correct, and whose change wouldn't even help >> them work around a problem they're facing. > I'm sure you have lots of screwball stuff to support defective and > broken systems in libtool, I don't see how doing something 'wrong' to > support another broken system like Linux is so bad. The point is that you've just been asking for libtool not to use -rpath at all, but this would only work for people who create .deb or .rpm binary packages, and not for any user that would be interested in building a package from the sources and installing it in non-standard directories. I have been somewhat hesitant about selectively dropping directories that are searched by default from the hardcoded rpath, but I think we can do it without much damage. There will be some, but whenever such a problem occurs, it is only because there was potential for its occurrence before, so we can live with it. It's just waiting for someone to implement it. > You cannot deny that it is necessary, and that it effects more that just > Debian and our users but everyone using a libc5/libc6 linux system. I can, that that's what I've been doing since the `Debian x Libtool War' started, a few days ago. I've insisted that the problem is not in the fact that libtool uses rpath, it is that libraries have been replaced with incompatible ones, and the code in ld.so that tries to accomodate for this replacement does not work when a program has a hard-coded library path. > It is not a problem we are 'facing' it is one we already faced and > arguably made the wrong choice - So now all linux systems have this > horrifying defect. Oh Well. That's Life - we can't fix it. You can, but the problem cannot be fixed within libtool (which doesn't mean libtool can't help); it can only be fixed in ld.so >> Ulrich Drepper has already mentioned that it's quite easy to modify >> the hard-coded rpath of a program without recompiling it, and that >> there's even a tool that will do that. > I actually think we have a program that does it as well, but somehow > adding something to a file in /etc vs 'stripping' every binary you install > on your system does not seem comparable. You don't have to strip every binary you install, only binaries that stop working after an upgrade. The upgrade program itself might search for programs linked with the old version of libc and with a (now) wrong hard-coded library path and fix them. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: WARNING: Re: debhelper & /usr/bin/passwd
In article <[EMAIL PROTECTED]> you write: >Joey Hess wrote: >> I'd say installing debhelper 1.2.28 with --force-conflicts is a _very_ bad >> idea. > >Unfortunatly, it looks like the current version of dpkg has >--force-overwrite (which is what I meant to say above) enabled by default. >And so anyone who ran dselect in the past 24 hours and upgraded from >unstable has probably beeen bitten by this bad package. My understanding of dpkg/dselect/apt-get isn't extremely good, but anyway: I have noticed this behaviour, too. However, at the time, I assumed the apt-get forced the file to be overwritten because the package I was installing was required/base (ldso from memory, but this problem has already been fixed). Now I am not so sure. Can you be certain that dselect doesn't give dpkg the --force-overwrite option? My versions of dpkg claim that --force-overwrite isn't on be default (otherwise it should have [*] after it): dpkg forcing options - control behaviour when problems found: warn but continue: --force-,,... stop with error:--refuse-,,... | --no-force-,... Forcing things: auto-select [*](De)select packages to install (remove) them dowgrade [*] Replace a package with a lower version configure-any Configure any package which may help this one hold Process incidental packages even when on hold bad-path PATH is missing important programs, problems likely not-root Try to (de)install things even when not root overwrite Overwrite a file from one package with another overwrite-diverted Overwrite a diverted file with an undiverted version depends-version [!]Turn dependency version problems into warnings depends [!]Turn all dependency problems into warnings conflicts [!] Allow installation of conflicting packages architecture [!] Process even packages with wrong architecture overwrite-dir [!] Overwrite one package's directory with another's file remove-reinstreq [!] Remove packages which require installation remove-essential [!] Remove an essential package WARNING - use of options marked [!] can seriously damage your installation. Forcing options marked [*] are enabled by default.
Re: What hack in ld.so?
On 30 Jan 1999, Alexandre Oliva wrote: > > You cannot deny that it is necessary, and that it effects more that just > > Debian and our users but everyone using a libc5/libc6 linux system. > > I can, that that's what I've been doing since the `Debian x Libtool > War' started, a few days ago. I've insisted that the problem is not > in the fact that libtool uses rpath, it is that libraries have been > replaced with incompatible ones, and the code in ld.so that tries to > accomodate for this replacement does not work when a program has a > hard-coded library path. So you think we should be harrassing the ld.so people to change the meaning of rpath instead of you for using it? Jason
Re: Call for mascot! :-) -- flying pigs
Anderson MacKay <[EMAIL PROTECTED]> writes: > On Thu, 28 Jan 1999, Avery Pennarun wrote: > > Octopi and ants may also be good, if they have wings. > > Octopi with wings? Now -that- is a confusing bunch of appendages, if you > ask me. =) Squid is a better choice than octopus. Some of them actually do fly for short distances. Perhaps glide is more accurate. -- Kevin Dalley [EMAIL PROTECTED]
Re: Call for mascot! :-) -- flying pigs
Kevin Dalley <[EMAIL PROTECTED]> writes: Anderson MacKay <[EMAIL PROTECTED]> writes: > On Thu, 28 Jan 1999, Avery Pennarun wrote: > > Octopi and ants may also be good, if they have wings. > > Octopi with wings? Now -that- is a confusing bunch of appendages, if you > ask me. =) Squid is a better choice than octopus. Some of them actually do fly for short distances. Perhaps glide is more accurate. How about a balrog? They have *lots* of eyes; we wouldn't be limited to 8. -- "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." --Daniel Pead
How do you locate non-i386 packages from the web?
Our web site has a nice section http://www.debian.org/distrib/packages which allows anyone to locate a package based upon various criteria. However, the packages are all i386 packages. Do we have anything similar for other platforms? The sane home page, http://www.mostang.com/sane/source.html, has a link to various sane binaries. The Debian web page points to http://www.debian.org/Packages/unstable/graphics/sane.html even though there are other platforms which have sane Debian packages. For consistency, and for further advertising of Debian, it would be nice to have other platforms represented. -- Kevin Dalley [EMAIL PROTECTED]
Re: Call for mascot! :-) -- flying pigs
-BEGIN PGP SIGNED MESSAGE- On 30 Jan 1999, Ben Pfaff wrote: > Kevin Dalley <[EMAIL PROTECTED]> writes: > >Anderson MacKay <[EMAIL PROTECTED]> writes: > >> On Thu, 28 Jan 1999, Avery Pennarun wrote: >> > Octopi and ants may also be good, if they have wings. >> >> Octopi with wings? Now -that- is a confusing bunch of appendages, if you >> ask me. =) >Squid is a better choice than octopus. Some of them actually do fly >for short distances. Perhaps glide is more accurate. > > How about a balrog? They have *lots* of eyes; we wouldn't be limited > to 8. Why not Yog Sothoth? *grin* Seriously, IMO, I don't see any reason not to stick with the Penguin. But if ya gotta have a new mascot, IMHO, I think a Dolphin would be nice. And I'm gonna justify it just to drive you all nuts. ;) Why a dolphin? Well, they're intelligent. Definitely intelligent. They're pretty cute. :) And they're definitely flexible. (I'd like to see *you* burst out of the water, do a backflip or two midair, and make a perfect reentry.;) Anyways, back to getting procmail working. Just my $0.02USD. ;) - -Phillip R. Jaenke ([EMAIL PROTECTED]) "something is not right, but i don't think it's wrong." --anon. -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNrPRBsES8LwwGtVlAQFcVQP/Y4GJnDOjmF+uHOesiBRwuGmn+QerKZGU 0RqbHimqBMBvYn1uHcPZDb0CY0Mgxpvv/4zHeclMNEQxJfhIp39HcbYZvzuMmi0m tNY7J1rJyZtHXmrJ+AouVt1SZ+GY7WHdkE3xiCWYxMUd4nH7UGPdjTJIrVQnr9DD 05QPoL8x8Qg= =ds8J -END PGP SIGNATURE-
[Waaaaay Off-Topic] Re: Call for mascot! :-) -- flying pigs
On Sat, Jan 30, 1999 at 10:30:58PM +0100, Marcus Brinkmann wrote: > On Thu, Jan 28, 1999 at 05:57:47PM -0600, Anderson MacKay wrote: > > > The key here is "cute." People don't want an ugly chicken-like creature > > > that is clearly ready to attack at the slightest provocation. > > > > And furthermore, even if it -was- to attack, it really wouldn't do > > anything. Linus -was- able to give a convincing, -somewhat- alarming > > description of an angry penguin and why you wouldn't want to mess with > > him, but really ... chicken? > > Are you crazy? A mad chicken will pick your eyes out... Or bite your legs off. =) I think someone also recently proposed the Debian Squid. H. I still just don't think that has the necessary "intimidation factor". :) And balrogs? Well, I guess that all depends on your interpretation of balrog ... but that definitely is intimidating. Open up a CD, hey look -- it's the Black Fire-Breathing Debian Beast of Death! ;) -- Anderson MacKay <[EMAIL PROTECTED]>
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
[Huge followup list trimmed] On 31 Jan 1999, Martin Mitchell wrote: > 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs > method. Apt is just not feasible, it wants to copy everything over before > it starts - there simply isn't space on the disk to do this. Also the No, APT has never copied anything except the index files when used with file URIs. With APTv3 you can ask it to copy by using a 'copy' URI, the choice is yours. > runtime cost of starting dpkg on m68k is very high, so dselect is often > much faster, rather than apt's invoking dpkg separately for many packages. > (I am aware apt is more correct, however in practice so many invocations > of dpkg are rarely necessary) APT v3 in CVS supports -o APT::Immediate-Configure=false which disables this behvior, only pre-depends will cause it to run a seperate dpkg which the other methods do as well. > 2) A local mirror, hand constructed. No extra or useless packages in there. > Apt doesn't construct or handle this type of arrangement well by default. > The mounted method deals with this just fine. I'd be interested to know how any other method handles this, how do you inform dselect what packages are in your local mirror so you can select them? If you have an incomplete mirror with a matching package file that has extra entries then APT v3 will be perfectly happy, if not a bit verbose as it has an automatic source fail-over mode, files that are missing or outdated will be fetched from a remote site if you enable that. Jason
Ian's solution [was: What hack in ld.so?]
Hi, all!
There's been so much traffic on this thread, that I suspect most
people have missed the fact that Ian Lance Taylor has analyzed and
*solved* the problems with interaction between libtool and
libc5-compat shared libraries.
I'm quoting and reposting his message so that it doesn't get lost in
the shuffle. Please read and understand this message before posting
more flameage.
> Ian Lance Taylor writes:
ILT> I just spent some time looking at the ld.so sources.
ILT> Interestingly, it seems to me that everything will work
ILT> correctly in the sources I was looking at. That is because the
ILT> libc5 dynamic linker on my system (RedHat 5.2) was modified to
ILT> search the library cache before using the application's
ILT> DT_RPATH.
ILT> I think that is a hack that Debian is missing: it is the final
ILT> hack to the libc5 dynamic linker to change the search path to
ILT> account for the moved shared libraries even when rpath is used.
ILT> I have appended the RedHat patch below. This is to ld.so-1.9.5.
ILT> Of course, this will technically break the handling of DT_RPATH.
ILT> However, we've already determined that DT_RPATH binaries will
ILT> not work correctly anyhow, because the shared libraries were
ILT> moved. So using this patch should not make us any worse off.
[...]
ILT> Although I can not test this, I now believe that if you take a
ILT> libtool program, compile it on a libc5 Slackware and try to run
ILT> it on a RedHat 5.2 system, it will work.
His patch follows...
--
Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/)
Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
[Unfortunately, www.fig.org is broken. Please stay tuned for details.]
--- ld.so-1.9.5/d-link/readelflib1.c.ewtMon Nov 17 10:04:15 1997
+++ ld.so-1.9.5/d-link/readelflib1.cMon Nov 17 10:23:15 1997
@@ -179,38 +179,10 @@
goto goof;
}
- /*
- * The ABI specifies that RPATH is searched before LD_*_PATH or
- * the default path of /usr/lib.
- * Check in rpath directories
- */
- for (tpnt = _dl_loaded_modules; tpnt; tpnt = tpnt->next) {
-if (tpnt->libtype == elf_executable) {
- pnt1 = (char *)tpnt->dynamic_info[DT_RPATH];
- if(pnt1) {
- pnt1 += (unsigned int) tpnt->loadaddr + tpnt->dynamic_info[DT_STRTAB];
- while(*pnt1){
- pnt2 = mylibname;
- while(*pnt1 && *pnt1 != ':') {
- if (pnt2 - mylibname < 1024)
- *pnt2++ = *pnt1++;
- else
- pnt1++;
- }
- if (pnt2 - mylibname >= 1024)
- break;
- if(pnt2[-1] != '/') *pnt2++ = '/';
- pnt = libname;
- while(*pnt) *pnt2++ = *pnt++;
- *pnt2++ = 0;
- tpnt1 = _dl_load_elf_shared_library(mylibname, 0);
- if(tpnt1) return tpnt1;
- if(*pnt1 == ':') pnt1++;
- }
- }
-}
- }
-
+ /* EWT - change things around a bit... The RPATH is almost definitely
+ wrong for libc 5 apps as things got moved around so much. Rather
+ then checking it first, we'll check it last. While this could
+ cause major breakages, it probably won't. */
/* Check in LD_{ELF_}LIBRARY_PATH, if specified and allowed */
pnt1 = _dl_library_path;
@@ -259,6 +231,38 @@
}
}
#endif
+
+ /*
+ * The ABI specifies that RPATH is searched before LD_*_PATH or
+ * the default path of /usr/lib.
+ * Check in rpath directories
+ */
+ for (tpnt = _dl_loaded_modules; tpnt; tpnt = tpnt->next) {
+if (tpnt->libtype == elf_executable) {
+ pnt1 = (char *)tpnt->dynamic_info[DT_RPATH];
+ if(pnt1) {
+ pnt1 += (unsigned int) tpnt->loadaddr + tpnt->dynamic_info[DT_STRTAB];
+ while(*pnt1){
+ pnt2 = mylibname;
+ while(*pnt1 && *pnt1 != ':') {
+ if (pnt2 - mylibname < 1024)
+ *pnt2++ = *pnt1++;
+ else
+ pnt1++;
+ }
+ if (pnt2 - mylibname >= 1024)
+ break;
+ if(pnt2[-1] != '/') *pnt2++ = '/';
+ pnt = libname;
+ while(*pnt) *pnt2++ = *pnt++;
+ *pnt2++ = 0;
+ tpnt1 = _dl_load_elf_shared_library(mylibname, 0);
+ if(tpnt1) return tpnt1;
+ if(*pnt1 == ':') pnt1++;
+ }
+ }
+}
+ }
/* Check in /usr/lib */
#ifdef IBCS_COMPATIBLE
Debian Security Issues
Hello, I am taking a graduate class in computer security. I have been asked to research some security questions for the class. I saw your FAQ, but one question remains. The professor asked me to find out : "What is distinctive about Debian Linux development that affects its assurance? " Thought I'd go to the source for this one. Any help would be much appreciated. Regards , Larry Wilson [EMAIL PROTECTED]
Regarding FAT32 Support
Hello, Where can I find the kernel to support FAT32 disk in linux? And also the driver to view EXT2 in MSDOS? Thank you <>
Re: Ian's solution [was: What hack in ld.so?]
Gordon Matzigkeit wrote: > There's been so much traffic on this thread, that I suspect most > people have missed the fact that Ian Lance Taylor has analyzed and > *solved* the problems with interaction between libtool and > libc5-compat shared libraries. I don't think this adresses the core problem. Yes, it fixes the libc5/6 problem, but consider this situation: * Program xfoo is linked with libXaw.so * -rpath is used so it's hard coded to look for this library in /usr/X11R6/lib/ * The user of program xfoo wants to use the xaw3d widget set with it instead of the default libXaw.so. They expect to be able to set LD_PRELOAD to point to /usr/X11R6/lib/xaw95/ and for the linker to pick up and use the libXaw.so in that directory, which is the xaw95 version of the library. * Since -rpath was used, this will not work. -- see shy jo
Re: Ian's solution [was: What hack in ld.so?]
Joey Hess wrote: > * Program xfoo is linked with libXaw.so > * -rpath is used so it's hard coded to look for this library in > /usr/X11R6/lib/ > * The user of program xfoo wants to use the xaw3d widget set with it instead > of the default libXaw.so. They expect to be able to set LD_PRELOAD to ^^ Actually, I meant to say LD_LIBRARY_PATH, not LD_PRELOAD. Or just edit /etc/ld.so.conf. Neither of these changes would make xfoo use /usr/X11R6/lib/xaw95/ and both should. > point to /usr/X11R6/lib/xaw95/ and for the linker to pick up and use the > libXaw.so in that directory, which is the xaw95 version of the library. > * Since -rpath was used, this will not work. -- see shy jo
Re: gnuserv/gnuclient problem
Amos Shapira wrote: (B> (B> It's the same version I have as well (latest Slink). Do you have (B> gnuserv installed as well? With gnuserv 2.1alpha-4 installed it (B> doesn't work. I tried purging gnuserv and then run gnuclient.xemacs20 (B> but I still get an error like: (B> (B> (1) (error/warning) Error in process filter: (void-function (B> gnuserv-edit-files) (B> (B> Maybe the previous installation of gnuserv broke it? As far as I (B> remember, I tried to install gnuserv *because* gnuclient didn't work (B> without it. (B> (B> Thanks, (B> (B> --Amos (B> (BHi, (B (BThanks for the replies. The problem seems to be in the gnuserv package. (BUninstall it and run gnuclient.xemacs20. It worked for me with latest (Bpackages from potato. I am running the mule xemacs. Do we fill a bug (Breport against gnuserv ? (B (BMy packages are: (Bii xemacs20-bin20.4-13Editor and kitchen sink -- support (Bbinaries (Bpn xemacs20-mule(no description available) (Bii xemacs20-mule-c 20.4-13Editor and kitchen sink -- Mule (Bbinary compi (Bpn xemacs20-nomule (no description available) (Bii xemacs20-suppor 20.4-13Editor and kitchen sink -- (Barchitecture inde (Bii xemacs20-suppor 20.4-13Editor and kitchen sink -- (Bnon-required libr (B (BThe only problem with gnuclient is that it fails when there is no (Bgnuserv started. Is there any workarround ? (B (Bbash-2.01$ gnuclient.xemacs20 (Bgnuclient.xemacs20: Connection refused (Bgnuclient.xemacs20: unable to connect to local (B (BTIA, (B (BIonutz
Re: List of bugs that *must* be fixed before releasing Slink
Well, let's see what's holding up slink. :) > apache32204 user directories allow symlinks to other files [0] > (Johnie Ingram <[EMAIL PROTECTED]>) There's a suggested fix in the bug report. Is it problematic? > autoconf 32391 Autoconf patches for slink [0] (Ben Pfaff <[EMAIL > PROTECTED]>) This is supposedly fixed and uploaded. > automake 32390 Automake patches for proper Alpha detection [0] > (Kevin Dalley <[EMAIL PROTECTED]>) Maintainer says upload is coming. > automake 32404 automake upgrade is not backwards compatible [0] > (Kevin Dalley <[EMAIL PROTECTED]>) This bug is against the version in potato, not slink? > boot-floppies 32269 partion harddisk fails if WIN95_EXTENDED present [0] > (Enrique Zanardi ) The report log is a little unclear. It looks like there is a version of cfdisk that works...are we just waiting for an upload? > chameleon 32522 chameleon in slink depends on too-new libs [0] > ([EMAIL PROTECTED] (Sean E. Perry)) Looks like it just needs a recompile against the right libs; or does it not work against the older glib? > dpkg 17624 dpkg: installs regular dir when .deb contains > symlink ! [364] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg 21182 dpkg: dpkg can go into an infinite loop with > --force-configure-any [288] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg 28519 dpkg: dpkg creates circular symlinks [93] (Ian > Jackson and others <[EMAIL PROTECTED]>) > dpkg 28817 dpkg takes no care over libdpkg [87] (Ian Jackson > and others <[EMAIL PROTECTED]>) > dpkg 30090 weirdass dpkg coredumps and xbase upgrade insanity > [62] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg 30891 dpkg: Patch for update-alternatives to fix jdk > problems [40] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg 32283 xbase postinst refers to nonexistent README.Debian > [0] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg-dev 31508 parsechangelog broken? [22] (Ian Jackson and others > <[EMAIL PROTECTED]>) No one ever wants to touch dpkg... > fileutils 31717 fileutils: 'mv regularfile symlink' problems [17] > (Galen Hazelwood <[EMAIL PROTECTED]>) There's a patch in the log, waiting on an upload? > ftp.debian.org31282 upgrade-1386 directory in Incoming [30] (Guy Maor > <[EMAIL PROTECTED]>) > ftp.debian.org32364 ftp.debian.org: please remove filters from > stable/frozen [0] (Guy Maor <[EMAIL PROTECTED]>) ? > general 28850 gettext: security problem when used in setuid > programs [0] (debian-devel@lists.debian.org) What needs to be done here? > jdk1.132548 Java doesn't work at all for me on slink [0] > (Stephen Zander <[EMAIL PROTECTED]>) There isn't much info here. > libtool 32384 libtool: Correct detection of 'alphapca56' patch [0] > (Frederic Lepied <[EMAIL PROTECTED]>) Just waiting for installation of provided patch? > lyx 32299 LyX Copyright problems [0] (Stuart Lamble <[EMAIL > PROTECTED]>) Fixed? > modutils 32539 Kernel 2.2 errors if no module support [0] (Wichert > Akkerman <[EMAIL PROTECTED]>) Fixed? > nonus.debian.org 23780 nonus.debian.org: libssl-dev is obsolete [220] > (Heiko Schlittermann <[EMAIL PROTECTED]>) > nonus.debian.org 26443 nonus.debian.org: apache-common_1.3.0+1.19 is > obsolete [144] (Heiko Schlittermann <[EMAIL PROTECTED]>) > nonus.debian.org 29246 nonus.debian.org: remove > fortify-unix-ppc_1.2.8-1.deb [79] (Heiko Schlittermann <[EMAIL PROTECTED]>) > nonus.debian.org 31326 Broken symlinks on nonus.debian.org [29] (Heiko > Schlittermann <[EMAIL PROTECTED]>) > nonus.debian.org 32171 umet dependency for mutt-i [8] (Heiko Schlittermann > <[EMAIL PROTECTED]>) Will non-us ever be fixed? > perl-suid 31904 [EMAIL PROTECTED]: Secuity hole with perl (suidperl) > and nosuid mounts on Linux] [13] (Darren Stalder <[EMAIL PROTECTED]>) I'm not sure there's much we can do about this one--it's a library (kernel?) problem. Perhaps a note in the postinst that the 'nosuid' mount option won't work, and a suggestion that care be taken with user-mountable media? > sendmail-wide 32475 sendmail-wide: different db file is used [0] > (Fumitoshi UKAI <[EMAIL PROTECTED]>) This is supposedly fixed...is it? > smb2www 32131 smb2www: smb2www in slink incompatible with samba in > slink [9] (Craig Small <[EMAIL PROTECTED]>) Is the potato version going to be installed, or is there another fix? > sysutils 29392 oldversion procinfo in sysutils is broken [76] > (Michael Alan Dorman <[EMAIL PROTECTED]>) Is there a reason not to put the new version in? > tcsh 28959 meta keys in tcsh don't work anymore! [85] (Luis > Francisco Gonzalez <[EMAIL PROTECTED]>) A fix was suggested; is there a reason not to use it? >
Re: List of bugs that *must* be fixed before releasing Slink
Michael Stone wrote: > > chameleon 32522 chameleon in slink depends on too-new libs [0] > > ([EMAIL PROTECTED] (Sean E. Perry)) > > Looks like it just needs a recompile against the right libs; or does it not > work against the older glib? The (former) maintainer just did a new upload that fixes this (according to the changelog.) > > lyx 32299 LyX Copyright problems [0] (Stuart Lamble <[EMAIL > > PROTECTED]>) > > Fixed? No. The maintainer needs to get the new license (or clarification of the old, depending on how you split your hairs) from the LyX website and change the copyright file. Being more or less error-proof, it seems to call for a simple NMU. -- David Starner - [EMAIL PROTECTED] Dullard: someone who, wanting a piece of information, takes down the appropriate volume of the encyclopedia, looks up the item they need, and then puts the volume away without reading anything else. - Peter Dell'Orto, paraphrased from Philip Jose Farmer
Re: WARNING: Re: debhelper & /usr/bin/passwd
> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> My versions of dpkg claim that --force-overwrite isn't on Brian> be default (otherwise it should have [*] after it): As does mine: and it lies! I've been testing package upgrades & dpkg itself is very definately using --force-overwite $ dpkg -l dpkg ii dpkg 1.4.1 Package maintenance system for Debian Linux -- Stephen --- It should be illegal to yell "Y2K" in a crowded economy. :-) -- Larry Wall
Re: Installation Profiles [was: Re: Reality check!]
> Might it be possible to include fewer packages in each profile and then > present the user with a list of additional packages that might be of > interest to them given that they have chosen this particular profile? > Something like "You have installed the Scientific Workstation profile. The > following additional packages may be of interest ..." a possibility i considered: divide user-space (i use the term loosely here. things that wouldn't be considered user-space by some, such as the interpreters section, count) packages into heirarchical groups (structure identical or similar to the debian menus, possibly?). have a level wherein the user selects any of these he wants; it will be easy to skip those things he obviously doesn't want (i can safely skip Applications/Ham-Radio and such things). this would save a *lot* of time, especially for anal people like me who actually read all two to three thousand package descriptions (really. initially installing hamm took me all weekend). any dependencies are autoselected, so i don't have to spend hours looking through libweird-2.3, libweird-2.3-dev, libweird2.3-dbg, libweird2.3-doc, libweird4.2, libweird4.2-dev, libweird4.2-dbg, libweird4.2-doc, ad infinitum (or at least ad nauseam). according to policy i should be able to just install all the optional things and then look at extra iff i want something really specialized, but that really doesn't scale too well. --phouchg
Mail Being Lost Again
Hello, At the beginning of January, I reported that mutt was losing mail. This behavior *appeared* to disappear with a certain kernel upgrade, but again it persists. Losing mail is a very serious system failure. I do not know what may have changed to cause the failure again, but it is here. I am using mutt 0.95.1 as the client, and sendmail 8.9.2 is the server. /var/spool/mail is NFS-mounted from the server. Also, whenever I shut down the client (an Alpha box), it displays: lockd_down: no lockd running but I cannot find any lockd or even any mention of it anywhere under /etc. I have tried both with and without libnfslock. I have been stymied in my search for a solution by manpages such as nfs(5) that date back to: Linux 0.99 20 November 1993 4 I have tried enabling mandatory locking even though it is irrelevant. Please, can someone shed light on this? It is a very serious problem. -- John Goerzen Linux, Unix consulting & programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Re: Intent-to-package: XGGI
On Tue, Jan 26, 1999 at 09:22:28PM -0800, Joey Hess wrote: > Aaron Van Couwenberghe wrote: > > XGGI is an X server based on XF86 code that will run under any supported > > libGGI target. > > Currently, other than a few XF 3.3.3.1 compliance points, XGGI > > works fine; it's been tested with the X target, the fb target, the emu > > target. shall I go on? I don't think anyone's tried AA yet. > > Please hurry. :-) I've been dying to use this for a while, with the AA target. > > -- > see shy jo I've got it compiled and working, but I'm having trouble with it (with regards to input devices, mode configuration, and vt switches). It'll be a *bit* longer, but I'm getting plenty of help from the GGI folks. Hopefully within a week. -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org Nullum magnum ingenium sine mixtura dementiae fuit. -- Seneca
Re: WARNING: Re: debhelper & /usr/bin/passwd
Stephen Zander wrote: >> "Brian" == Brian May <[EMAIL PROTECTED]> writes: >Brian> My versions of dpkg claim that --force-overwrite isn't on >Brian> be default (otherwise it should have [*] after it): > >As does mine: and it lies! I've been testing package upgrades & dpkg >itself is very definately using --force-overwite > > $ dpkg -l dpkg > ii dpkg 1.4.1 Package maintenance system for Debian Linux Version 1.4.0.27 seems OK here. I created two dummy test packages both containing the same file, and installed them. I will check the latest version tommorrow. I suggest that you should file a bug report against dpkg... Brian May <[EMAIL PROTECTED]>
Re: WARNING: Re: debhelper & /usr/bin/passwd
Brian May wrote: > >Unfortunatly, it looks like the current version of dpkg has > >--force-overwrite (which is what I meant to say above) enabled by default. > >And so anyone who ran dselect in the past 24 hours and upgraded from > >unstable has probably beeen bitten by this bad package. > > Can you be certain that dselect doesn't give dpkg the --force-overwrite > option? IIRC, I wrote the above after running dpkg on the broken debhelper package by hand and watching it overwrite the files. > My versions of dpkg claim that --force-overwrite isn't on be default > (otherwise it should have [*] after it): That means nothing, you can turn off options in dpkg without editing that output. (Bad design, IMHO.) -- see shy jo
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Sat, Jan 30, 1999 at 07:14:04PM +, Alan Cox wrote: > I'd like to propose that for now the FHS is changed to read > > "The mail spool area location is undefined. It is guaranteed that both > /var/mail and /var/spool/mail point to this mail spool area if the system > has a mail spool. The preferred reference name is /var/mail. > > [Rationale: /var/mail is the only name available on some other modern Unix > platforms. /var/spool/mail is the older Linux tradition and needed for > compatibility] > > [Rationale2: The physical location of the mail spool is not relevant to > an application and is administrator policy. It is thus left open.] > > > Can everyone live with that and bury the thread I'd live with that, but I'd prefer just /var/mail be used and if vendors want to create a symlink for backward compatibility or even from /var/mail to /var/spool for easy upgrades, let them.. (creating a symlink from /var/mail to /var/spool/mail if /var/mail does not exist is likely how Debian would handle such a change without surprises for the user..) -- "I'm working in the dark here." "Yeah well rumor has it you do your best work in the dark." -- Earth: Final Conflict
bug? with file-rc
dpkg -l file-rc ii file-rc 0.4.3 Alternative one-configfile boot mechanism i don't know if this is supposed to be the case or not, but contrary to file-rc's documentation, scripts are not run in reverse order for shutting down. is this a debian-specific thing or merely a bug? are the etc/rcN.d/Kmm* scripts run in descending order when file-rc is not used? i find it rather strange, especially since not reversing shutdown scripts makes it necessary to double the number of lines in /etc/runlevel.conf (and have the numbers of start/stop links in /etc/rcN.d differ) in those cases where order does matter. --phouchg
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
> > I'd live with that, but I'd prefer just /var/mail be used and if vendors > want to create a symlink for backward compatibility or even from > /var/mail to /var/spool for easy upgrades, let them.. (creating a > symlink from /var/mail to /var/spool/mail if /var/mail does not exist is > likely how Debian would handle such a change without surprises for the > user..) > I would prefer it as well, but I agree with Alan Cox that it is probably not appropriate for standardization. Make the standard say /var/mail and /var/spool/mail both have to work. -hpa
Re: gnuserv/gnuclient problem
On Sun, January 31 1999, Ionutz Borcoman <[EMAIL PROTECTED]> wro te: |packages from potato. I am running the mule xemacs. Do we fill a bug |report against gnuserv ? I've already filed a bug report against gnuserv on October 19th: http://www.debian.org/Bugs/db/28/28175.html That's error #28175 Thanks. --Amos --Amos Shapira| "Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England." ISRAEL[EMAIL PROTECTED] | -- Anonymous
Re: WARNING: Re: debhelper & /usr/bin/passwd
On Sat, Jan 30, 1999 at 10:06:30PM -0800, Stephen Zander wrote: > > "Brian" == Brian May <[EMAIL PROTECTED]> writes: > Brian> My versions of dpkg claim that --force-overwrite isn't on > Brian> be default (otherwise it should have [*] after it): > > As does mine: and it lies! I've been testing package upgrades & dpkg > itself is very definately using --force-overwite which is a damn good thing. please, nobody suggest changing the default behaviour until dpkg has a config file in /etc allowing each system admin to choose what the default should be. i get really sick of apt/dselect upgrades not working in unstable because some people have the mistaken belief that --force-overwrite should default to off. yes, you can override it on the dpkg command linebut there is no way to override it if you use dselect or apt. this is evil. craig -- craig sanders
Toner Supplies
BENCHMARK PRINT SUPPLY 1091 REDSTONE LANE ATLANTA GA 30338 CALL> 770-399-0953 FOR TONER SUPPLIES ORDERS/PRICING ONLY CALL> 770-399-5505 CUSTOMER SERVICE/SUPPORT ISSUES CALL> 770-399-5614E-MAIL REMOVAL COMPLAINTS LINE OUR LASER PRINTER/FAX/COPIER TONER CARTRIDGE PRICES NOW AS LOW AS $39 & UP. SPECIALS WEEKLY ON ALL LASER PRINTER SUPPLIES. WE CARRY MOST ALL LASER PRINTER CARTRIDGES, FAX SUPPLIES AND COPIER TONERS AT WAREHOUSE PRICES INCLUDING: HEWLETT PACKARD SERIES 2/3/4/2P/4P/5P/4L/5L/3SI/4SI/5SI IBM/LEXMARK OPTRA SERIES 4019/4029/4039/4049/4059 EPSON SERIES 2/1100/1500/6000/7000/8000 NEC SERIES 90/95 CANON COPIER PC SERIES INCLUDING 3/6RE/7/11/320/720/10/20/25 ETC... HP FAX SERIES 700/720/5000/7000/FX1/FX2/FX3/FX4/FX5 CANON FAX ALL MODELS PRICES CHANGE WEEKLY PLEASE CALL TO GET THE MOST RECENT PRICING/AVAILABILTY AND SPECIALS OF THE WEEK PLEASE PLEASE PLEASE MAKE NOTE OF THE FOLLOWING BEFORE YOU CALL: -> WE DO NOT HAVE CATALOGS OR PRICE LISTS BECAUSE OUR PRICES CHANGE WEEKLY!! -> WE DO NOT FAX QUOTES OR PRICES BECAUSE OUR ORDER LINE IS NOT SET UP TO DO THAT -> WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS -> WE DO NOT CARRY : BROTHER -MINOLTA-KYOSERA- PANASONIC - XEROX - FUJITSU - OKIDATA - SHARP!! -> WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES! -> WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES WE ACCEPT ALL MAJOR CREDIT CARDS OR COD ORDERS CORPORATE ACCOUNTS AVAILABLE WITH APPROVED CREDIT ALL PACKAGES SHIPPED UPS GROUND UNLESS SPECIFIED OTHERWISE
Re: What hack in ld.so?
Alexandre Oliva wrote: >The point is that you've just been asking for libtool not to use >-rpath at all, Yes, I think this is the correct solution. >but this would only work for people who create .deb or .rpm binary >packages, You fill this house with lies. It works for anyone putting libraries in standard places, "standard" being defined by the admin, who has write access to /etc/ld.so.cache. Users can work around this by, at worst, creating a wrapper script to set LD_LIBRARY_PATH. For example: frantica:~/apt/build/bin$ ./apt-get ./apt-get: error in loading shared libraries libapt-pkg.so.2.0: cannot open shared object file: No such file or directory frantica:~/apt/build/bin$ cat apt-get-wrapper #!/bin/sh LD_LIBRARY_PATH=/home/rcw/apt/build/bin exec /home/rcw/apt/build/bin/apt-get "$@" frantica:~/apt/build/bin$ ls -l apt-get-wrapper -rwxr-xr-x 1 rcw rcw87 Jan 31 02:11 apt-get-wrapper* frantica:~/apt/build/bin$ ./apt-get-wrapper apt 0.3.0 for i386 [...] This is what our ld.so has done for years, this is what our users expect, and this is what has determined Linux's library placement for every other transition it has had to make. It's safe to say that will not change. Hardcoded pathnames to libraries are evil, you can't blame people for trying to get rid of them, especially when they start breaking left and right the minute things move around. -- Robert Woodcock - [EMAIL PROTECTED] "It's like a love-hate relationship, but without the love." -- jwz, on linux
Re: List of bugs that *must* be fixed before releasing Slink
>> "MS" == Michael Stone <[EMAIL PROTECTED]> writes: >> dpkg-dev 31508 parsechangelog broken? [22] (Ian Jackson and >> others <[EMAIL PROTECTED]>) MS> No one ever wants to touch dpkg... There is a patch provided with this bug report. >> xxgdb 32206 xxgdb: Can't rebuild xxgdb from source [7] (Helmut >> Geyer <[EMAIL PROTECTED]>) MS> Needs some work... Daniel Martin fixed this. But he had to change fairly much. He did a upload for frozen and unstable (see <[EMAIL PROTECTED]> in debian-devel-changes), but it has been formaly rejected because of "md5sum: MD5 check failed for 'xxgdb_1.12-9.2.dsc'". Ciao, Martin
Re: WARNING: Re: debhelper & /usr/bin/passwd
Craig Sanders wrote: >> As does mine: and it lies! I've been testing package upgrades & dpkg >> itself is very definately using --force-overwite > >which is a damn good thing. > >please, nobody suggest changing the default behaviour until dpkg has >a config file in /etc allowing each system admin to choose what the >default should be. > >i get really sick of apt/dselect upgrades not working in unstable >because some people have the mistaken belief that --force-overwrite >should default to off. > >yes, you can override it on the dpkg command linebut there is no way >to override it if you use dselect or apt. this is evil. Just my 2 cents: The dpkg online help should reflect the default setting. It should not give the impression that the default is off when it is in actual fact on. Any duplicate files in packages is a bug in the package, and users may not even be aware of the problem (ie it can scroll of the screen) unless the default is off. If a user installs package X and it overwrites a file with an older, buggy and/or incompatable version of file F, then IMHO it is going to be very difficult to diagnose why package Y stops working, especially if that user files a bug report against Y. If you want to use --force-overwrite, perhaps these problems should be logged somewhere. Also, bug could be made to report any potential problems when submitting a bug report. As an extreme example is when installing a new, buggy, package breaks your system because it overwrites (and potentially breaks) critical system files, for instance, this thread was started because a package overwrite: /usr/bin/passwd /usr/bin/chsh /usr/bin/chfn I think the default in dpkg should be off, but it should be possible to override it by environment variable, for those who know what they are doing. In fact, I am very surprised that this isn't already supported... Brian May <[EMAIL PROTECTED]>
Re: Toner Supplies
Have our anti-spam policy been enforced before ? If so how succes was it ? We really need to make the spammers pay.
Re: bug? with file-rc
Jonathan P Tomer <[EMAIL PROTECTED]> wrote: > ii file-rc 0.4.3 Alternative one-configfile boot mechanism This version has many errors, some of them are fixed in the actual 0.4.7. > i don't know if this is supposed to be the case or not, but contrary > to file-rc's documentation, scripts are not run in reverse order for > shutting down. is this a debian-specific thing or merely a bug? file-rc is based on a program (nowadays called r2d2) written by Winfried Trümper. This program run the "stop" scripts in reverse order. But this isn't the way, rc from sysvinit works and file-rc should be fully compatible to sysvinit-rc. Because of this someone patched file-rc not to stop the scripts in reverse order but to insert two lines (using update-rc.d) into runlevel.conf, one that starts the process and another one that stops it. The file is always read from top to bottom. It seems that /usr/doc/file-rc/README.gz is simply copied from Winfrieds original program and the person who patched it for debian didn't change this README. > are the etc/rcN.d/Kmm* scripts run in descending order when file-rc > is not used? No, they are run in ascending order as well as the runlevel.conf is always run top down. > i find it rather strange, especially since not reversing shutdown > scripts makes it necessary to double the number of lines in > /etc/runlevel.conf (and have the numbers of start/stop links in > /etc/rcN.d differ) in those cases where order does matter. I fully agree with you! I asked what other people think about this some weeks ago, but the only answer I got was a cry for "compatibility" and the variant with stopping in reverse order is not 100% compatible to sysvinit-rc... So at the moment (0.4.7) we have a file-rc which isn't as elegant as the original file-rc/r2d2 but which should be compatible to sysvinit-rc. If someone (like you and me) wants a more elegant, but incompatible variant, it may be a good idea to create another package (for example with the name r2d2) which has status "eXtra" and presents a big warning on install that update-rc.d will behave not exactly like the one of sysvinit and as it is described in the policy (see section 3.3). Tscho Roland -- * [EMAIL PROTECTED] * http://www.rhein.de/~roland/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
non-us.debian.org OK?
Hi, Ever since I installed the new apt (0.3.0) on a hamm system it can't access the non-us archives. Trying to access them via ftp or netwcape fails as well. I tried both the default config given in the sample sources.list file and some lines which used to work before the last upgrade. Can anyone send me a working configuration for non-us? Thanks, --Amos --Amos Shapira| "Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England." ISRAEL [EMAIL PROTECTED] | -- Anonymous
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > > 2) A local mirror, hand constructed. No extra or useless packages in there. > > Apt doesn't construct or handle this type of arrangement well by default. > > The mounted method deals with this just fine. > > I'd be interested to know how any other method handles this, how do you > inform dselect what packages are in your local mirror so you can select > them? dpkg-mountable handles it thusly: 1. If there's a Packages.gz file in the directory, use that. If files from that are missing then -- like your comment about Apt -- it will be a little verbose if you try to install any of them, but will carry on and do the rest. (Because of the way it's written, it won't look for older versions anywhere else right now). 2. For mirrors it thinks of as "local", it will use dpkg-scanpackages to construct a Packages file if none already exists, and will keep it up-to-date automatically based on what files are there. (This is a bit bad because it really needs the override file from Master too). Local directory is used to override a "source" directory, basically like two lines in sources.list; the intention is that the main directory is a Debian mirror, and the local directory can be used for some upgraded pacakges if (for example) the mirror is on a CD-ROM or NFS. Andy -- Andy Mortimer [EMAIL PROTECTED] -- Andy walking, Andy tired, Andy take a little snooze -- "Andy Warhol," David Bowie
Re: Call for mascot! :-) -- flying pigs
On 30 Jan 1999, Ben Pfaff wrote: > Kevin Dalley <[EMAIL PROTECTED]> writes: > >Anderson MacKay <[EMAIL PROTECTED]> writes: > >> On Thu, 28 Jan 1999, Avery Pennarun wrote: >> > Octopi and ants may also be good, if they have wings. >> >> Octopi with wings? Now -that- is a confusing bunch of appendages, if you >> ask me. =) >Squid is a better choice than octopus. Some of them actually do fly >for short distances. Perhaps glide is more accurate. > > How about a balrog? They have *lots* of eyes; we wouldn't be limited > to 8. Eh? WTF did you get that from? Matthew -- Elen sila lumenn' omentielvo [EMAIL PROTECTED], Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: non-us.debian.org OK?
Amos Shapira wrote: >Can anyone send me a working configuration for non-us? This worked yesterday: deb ftp://sunsite.doc.ic.ac.uk/packages/Linux/debian-non-US hamm/binary-$(ARCH)/ deb ftp://sunsite.doc.ic.ac.uk/packages/Linux/debian-non-US slink/non-US/binary-$(ARCH)/ deb ftp://sunsite.doc.ic.ac.uk/packages/Linux/debian-non-US potato/non-US/binary-$(ARCH)/ -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 "Jesus saith unto him, I am the way, the truth, and the life; no man cometh unto the Father, but by me." John 14:6
Re: bug? with file-rc
Jonathan P Tomer wrote: >dpkg -l file-rc >ii file-rc 0.4.3 Alternative one-configfile boot mechanism > >i don't know if this is supposed to be the case or not, but contrary to >file-rc's documentation, scripts are not run in reverse order for shutting >down. is this a debian-specific thing or merely a bug? are the etc/rcN.d/Kmm >* >scripts run in descending order when file-rc is not used? This is from the Policy manual: The names of the links all have the form Smm/script or Kmm/script where mm is a two-digit number and script is the name of the script (this should be the same as the name of the actual script in /etc/init.d. When init changes runlevel first the targets of the links whose names starting with a K are executed, each with the single argument stop, followed by the scripts responsible for killing services and the S link for starting services upon entering the runlevel. For example, if we are changing from runlevel 2 to runlevel 3, init will first execute all of the K prefixed scripts it finds in /etc/rc3.d, and then all of the S prefixed scripts. The links starting with K will cause the referred-to file to be executed with an argument of stop, and the S links with an argument of start. The two-digit number mm is used to decide which order to start and stop things in -- low-numbered links have their scripts run first. For example, the K20 scripts will be executed before the K30 scripts. So the way it should work is: init sends SIGTERM to everything not listed in /etc/inittab for the new runlevel, and init runs `/etc/init.d/rc new_run_level' this runs the K script for everything in the new runlevel then it runs the S script for everything in the new runlevel So the rationale of the K scripts is not to kill things from the previous runlevel but from the new one. The results of this policy are seen in the layout of /etc/rc?.d: the K scripts are in runlevels 0, 1 and 6, whereas the S levels are in 2, 3, 4 and 5. Therefore the file-rc documentation is wrong, but its behaviour is right. It seems rather clumsy, though. Why was this scheme chosen, instead of one where the K scripts are run for the previous runlevel? The current scheme works fine for shutting down and going to single user mode, but is very clumsy for an administrator who wants to assign meanings to run-levels 2 to 5 (which Debian does not currently do). -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 "Jesus saith unto him, I am the way, the truth, and the life; no man cometh unto the Father, but by me." John 14:6
Re: Last call for bugs
-BEGIN PGP SIGNED MESSAGE-
Due to the latest patches, the following entries in the libnessus result
in undefined symbols on the nessus client (with a picky linker):
plugutils.c:311: log_write("Error: Missing scan ID.\n");
plugutils.c:316: log_write("debug: --proto_post_hole: Scan ID %d.\n", );
plugutils.c:424: log_write("Error: Missing scan ID.\n");
plugutils.c:429: log_write("debug: --proto_post_info: Scan ID %d.\n", );
So I add a patch-function to the nessus.c so that I can link it.
jordan
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNrRdq2MDGxdz+LVBAQHTpwQAmHOoV1MBsv6PSCFA9OV3Lj0ZV7mb47xM
SY0G2vBYHPwlJ7jpdhd9c0fbJztN8oCiypnTfN+w8eiUJ3FF8SKPjRY13eDHoY23
TkpUj3EGHjmqN7gY8lxecwSgo2Zin1oWq+e6c+aN1ItZTtC4h9rClf1H9XrADhAq
Jp45Nw3RAKA=
=o3jC
-END PGP SIGNATURE-
Re: Mail Being Lost Again
Previously John Goerzen wrote: > Also, whenever I shut down the client (an Alpha box), it displays: > lockd_down: no lockd running What kind of NFS server are you using? Linux? User or kernel nfsd? Are you running rpc.lockd? Mounting with nolock? You really need to tell us a bit more.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpb4vz25t2bm.pgp Description: PGP signature
Re: List of bugs that *must* be fixed before releasing Slink
Here we go again :) Previously Brian White wrote: > apache32204 user directories allow symlinks to other files [0] > (Johnie Ingram <[EMAIL PROTECTED]>) We should just force SymLinksIfOwnerMatch for /home to solve this. > autoconf 32391 Autoconf patches for slink [0] (Ben Pfaff <[EMAIL > PROTECTED]>) Fix is already installed. > automake 32390 Automake patches for proper Alpha detection [0] > (Kevin Dalley <[EMAIL PROTECTED]>) > automake 32404 automake upgrade is not backwards compatible [0] > (Kevin Dalley <[EMAIL PROTECTED]>) In Incoming (version 1.3-2) > boot-floppies 32269 partion harddisk fails if WIN95_EXTENDED present [0] > (Enrique Zanardi ) In Incoming (version 2.1.6) > chameleon 32522 chameleon in slink depends on too-new libs [0] > ([EMAIL PROTECTED] (Sean E. Perry)) In Incoming (version 1.0-3) > dpkg 17624 dpkg: installs regular dir when .deb contains > symlink ! [364] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg 21182 dpkg: dpkg can go into an infinite loop with > --force-configure-any [288] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg 28519 dpkg: dpkg creates circular symlinks [93] (Ian > Jackson and others <[EMAIL PROTECTED]>) > dpkg 30090 weirdass dpkg coredumps and xbase upgrade insanity > [62] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg 32283 xbase postinst refers to nonexistent README.Debian > [0] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg 28817 dpkg takes no care over libdpkg [87] (Ian Jackson > and others <[EMAIL PROTECTED]>) It's important but I wouldn't call this one release-critical. > dpkg 30891 dpkg: Patch for update-alternatives to fix jdk > problems [40] (Ian Jackson and others <[EMAIL PROTECTED]>) > dpkg-dev 31508 parsechangelog broken? [22] (Ian Jackson and others > <[EMAIL PROTECTED]>) I fixed these two in 1.4.0.33. I didn't close the bugs because I still need to fix them for the dpkg in potato. > fileutils 31717 fileutils: 'mv regularfile symlink' problems [17] > (Galen Hazelwood <[EMAIL PROTECTED]>) Only in potato; looks like Brian forgot to add this one to his exclusion-list again > ftp.debian.org31282 upgrade-1386 directory in Incoming [30] (Guy Maor > <[EMAIL PROTECTED]>) > ftp.debian.org32364 ftp.debian.org: please remove filters from > stable/frozen [0] (Guy Maor <[EMAIL PROTECTED]>) filters is no longer in frozen, so this can be excluded as well. > general 28850 gettext: security problem when used in setuid > programs [0] (debian-devel@lists.debian.org) Everyone who has a package with a setuid program or something that runs as root should check if it uses gettext, and if so recompile it with the latest gettext installed. Please not that this is not necessary for programs that use the gettext from libc6. > jdk1.132548 Java doesn't work at all for me on slink [0] > (Stephen Zander <[EMAIL PROTECTED]>) > libtool 32384 libtool: Correct detection of 'alphapca56' patch [0] > (Frederic Lepied <[EMAIL PROTECTED]>) In incoming (version 1.3-2) > lyx 32299 LyX Copyright problems [0] (Stuart Lamble <[EMAIL > PROTECTED]>) We have the new license now; it should be packaged though > modutils 32539 Kernel 2.2 errors if no module support [0] (Wichert > Akkerman <[EMAIL PROTECTED]>) In incoming (2.1.121-18) > nonus.debian.org 23780 nonus.debian.org: libssl-dev is obsolete [220] > (Heiko Schlittermann <[EMAIL PROTECTED]>) > nonus.debian.org 26443 nonus.debian.org: apache-common_1.3.0+1.19 is > obsolete [144] (Heiko Schlittermann <[EMAIL PROTECTED]>) > nonus.debian.org 29246 nonus.debian.org: remove > fortify-unix-ppc_1.2.8-1.deb [79] (Heiko Schlittermann <[EMAIL PROTECTED]>) > nonus.debian.org 31326 Broken symlinks on nonus.debian.org [29] (Heiko > Schlittermann <[EMAIL PROTECTED]>) > nonus.debian.org 32171 umet dependency for mutt-i [8] (Heiko Schlittermann > <[EMAIL PROTECTED]>) Somebody *PLEASE* do something about non-US, this is getting increasingly silly. > perl-suid 31904 [EMAIL PROTECTED]: Secuity hole with perl (suidperl) > and nosuid mounts on Linux] [13] (Darren Stalder <[EMAIL PROTECTED]>) > sendmail-wide 32475 sendmail-wide: different db file is used [0] > (Fumitoshi UKAI <[EMAIL PROTECTED]>) In Incoming (version 8.9.2+3.1W-3.1) > smb2www 32131 smb2www: smb2www in slink incompatible with samba in > slink [9] (Craig Small <[EMAIL PROTECTED]>) > sysutils 29392 oldversion procinfo in sysutils is broken [76] > (Michael Alan Dorman <[EMAIL PROTECTED]>) In Incoming (version 1.3.3.1) > tcsh 28959 meta keys in tcsh don't work anymore! [85] (Luis > Francisco Gonzalez <[EMAIL PROTECTED]>) In Incoming (version 6.08.01-3) > transfig 32520 transfig
Re: WARNING: Re: debhelper & /usr/bin/passwd
Previously Stephen Zander wrote: > As does mine: and it lies! I've been testing package upgrades & dpkg > itself is very definately using --force-overwite The [*] marks are hardcoded in dpkg, and Daniel Jacobowitz forgot to change that when he made NMU 1.4.0.31 which turned --force-overwrite on by default. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpwD78HURI5b.pgp Description: PGP signature
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Previously Adam Di Carlo wrote: > In fact, using 'dpkg -iGROEB' is much worse: You forgot another important one: it's *horribly* slow. I actually used the ftp method and mounting a cdrom where ftpd could get it for a while to speed things up. > I submit that they *must* be removed from the boot-floppies and the > *must* be taken out of harms way. Therefore, they must be removed > from dpkg. If someone wants to split the pacakge, great. I have to say we are very far in the deep-freeze to consider breaking the dpkg-packge apart.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpwdEfV64isI.pgp Description: PGP signature
Re: [Waaaaay Off-Topic] Re: Call for mascot! :-) -- flying pigs
Previously Anderson MacKay wrote: > Or bite your legs off. =) Nah, that was a cute little bunny rabbit :) We could then have conversations like this with our users: CART DRIVER: Bring out your dead! LARGE MAN: Here's one! CART DRIVER: Ninepence. BODY:I'm not dead! Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpCDJ1e8QWVL.pgp Description: PGP signature
Re: WARNING: Re: debhelper & /usr/bin/passwd
Previously Remco Blaakmeer wrote: > Is there any way of changing that default behaviour (e.g. some config > file) apart from recompiling dpkg? I'd like to leave it disabled at all > times no matter what the default is in the current dpkg package. No. Are there other things that would be useful in a dpkg configuration file? I can't think of anything at the moment. Wichert -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpdIuSwjrO65.pgp Description: PGP signature
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Previously Enrique Zanardi wrote: > [ Please, don't CC: me. I'm subscribed to -devel, -boot and -testing. > Three copies of the same message are enough. ;-) ] Put this in your .procmailrc: :0 Whc: msgid.lock | formail -D 16384 .msgid.cache > Two (dpkg and dpkg-defaults) are not a bunch, are they? > I proposed just _one_ new package (dpkg-defaults) that provides all those > methods. We could probably do that at the same time dselect gets its own package. Hmm, I wonder if IWJ would complain if I actually did that :) Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpbUHj0MHyo2.pgp Description: PGP signature
Re: Debian Security Issues
Previously Larry Wilson wrote: > The professor asked me to find out : > "What is distinctive about Debian Linux development that affects its > assurance? " Mostly the fact that we have an amazing numbers of developers who can respond to security issues. Usually when a security issues comes up it is handled by the security team and the package maintainer, but other developers can also help out, which means that we can respond very fast. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpr41UPi3Dgt.pgp Description: PGP signature
Re: List of bugs that *must* be fixed before releasing Slink
Previously Michael Stone wrote: > > perl-suid 31904 [EMAIL PROTECTED]: Secuity hole with perl > > (suidperl) and nosuid mounts on Linux] [13] (Darren Stalder <[EMAIL > > PROTECTED]>) > > I'm not sure there's much we can do about this one--it's a library (kernel?) > problem. Perhaps a note in the postinst that the 'nosuid' mount option won't > work, and a suggestion that care be taken with user-mountable media? What perl-suid should do is check the mountoptions for the filesystem on which the script resides and abort if that was mounted with nosuid. Should be quite simple actually.. > Ok. So what we have are various packages that need to have (apparantly) simple > changes uploaded (e.g., dependencies changed or provided patch added.) There's > dpkg, which is probably never going to be done. :( And there's ftp.debian and > nonus, which are dependent on their respective administrators. > Then there are some things that actually need to be looked at: 28850 says that > any suid static-linked gettext program needs to be checked. We need a way to > address 31904. 32485 needs someone to write a patch. > Someone needs to figure out whats wrong with java (32548.) Somebody already figured that out IIRC, but a fix should be uploaded. > And xxgdb is toasted (32206.) Am I missing anything? I think somebody said xxgdb works for him.. > (I.e., what's holding up slink beyond these few items?) Nothing I hope :) > Is a postinst message sufficient to downgrade 31904 (and can someone > take care of that?) I'll complain loudly if someone downgrades that. > I'll look at 32485 unless someone has a patch ready. I fail to see why 32485 is release-critical.. there are probably lots of other programs that also don't work with MD5 passwords. Do I hear somebody saying PAM? Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpHHY2oZf0OA.pgp Description: PGP signature
Re: List of bugs that *must* be fixed before releasing Slink
On Sun, 31 Jan, 1999, Michael Stone wrote: > > transfig 32520 transfig: puts files in /usr/lib/X11, should use > > /usr/X11R6/lib/X11 instead [0] (Edward Betts <[EMAIL PROTECTED]>) > > This seems fairly simple, right? Sitting in incoming -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto
dinstall can now announce packages & close bugs for you
dinstall, the software which installs packages into the hierarchy, can now announce packages and close bugs for you. If you'd like to use this feature, upgrade to the dpkg-dev in my home directory on master. The changes are checked in to va's dpkg cvs tree. dinstall will look for a Format field of 1.6 and a new Closes field. Closes is a space separated list of bugs closed by the upload. In your changelog, the perl regular expression /closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/i is used to build the Closes field. Here is an example: acme-cannon (3.1415) unstable; urgency=low * Added safety to prevent operator dismemberment, closes: bug #98765, bug #98713, #98714. * Added manpage. closes: #98725. -- Wile E. Coyote <[EMAIL PROTECTED]> Sun, 31 Jan 1999 07:49:57 -0600 dinstall will announce to debian-changes and/or debian-devel-changes as appropriate. It will compare the name part of the Maintainer in the .dsc and the .changes. If they match, it will close the bugs, and if not, it will assume it's an NMU and set their severity to fixed. Bugs are only processed for source uploads. You can test your upload with the -n flag to dinstall: $ ~maor/dinstall/dinstall -n debianutils*changes debianutils_1.11_i386.changes INSTALL debianutils_1.11.tar.gz to dists/potato/main/source/base/debianutils_1.11.tar.gz replacing debianutils_1.10.tar.gz debianutils_1.11.dsc to dists/potato/main/source/base/debianutils_1.11.dsc replacing debianutils_1.10.dsc debianutils_1.11_i386.deb to dists/potato/main/binary-i386/base/debianutils_1.11.deb replacing debianutils_1.10.deb Announcing to debian-devel-changes@lists.debian.org Closing bugs: 27428 29879 31780 (NMUs have "Setting bugs to severity fixed:" instead of "Closing bugs:" above.) Please help me test this new feature, and tell me about any problems. Guy
Re: stupid stats (was Re: xfree86_3.3.2.3a-9 (source i386 all) uploaded to master)
On Fri, Jan 29, 1999 at 04:41:27PM -0800, Joey Hess wrote: > I actually did the other way first, it wasn't siginificantly different > except Brandon Robinson was in 3rd place (X). Spell m' damn name right, boy!!! -- G. Branden Robinson | Debian GNU/Linux | If encryption is outlawed, only outlaws [EMAIL PROTECTED] | will @goH7OjBd7*dnfk= pgpg3kd2DT50o.pgp Description: PGP signature
Re: gnuserv/gnuclient problem
In article <[EMAIL PROTECTED]>, Amos Shapira <[EMAIL PROTECTED]> wrote: >It's the same version I have as well (latest Slink). Do you have >gnuserv installed as well? With gnuserv 2.1alpha-4 installed it >doesn't work. I tried purging gnuserv and then run gnuclient.xemacs20 >but I still get an error like: > >(1) (error/warning) Error in process filter: (void-function gnuserv-edit-files) > >Maybe the previous installation of gnuserv broke it? As far as I >remember, I tried to install gnuserv *because* gnuclient didn't work >without it. This probably meant that you were loading the lisp from the gnuserv package, not from the XEmacs install. The gnuserv.el supplied with the gnuserv packages doesn't define "gnuserv-edit-files", it defines "server-edit-files"... SRH -- I will protect you from your visions to save you from illusions I will protect you from ideals to save you from defeat[covenant]
Re: gnuserv/gnuclient problem
In article <[EMAIL PROTECTED]>, Ionutz Borcoman <[EMAIL PROTECTED]> wrote: >The only problem with gnuclient is that it fails when there is no >gnuserv started. Is there any workarround ? > >bash-2.01$ gnuclient.xemacs20 >gnuclient.xemacs20: Connection refused >gnuclient.xemacs20: unable to connect to local Write a wrapper around gnuclient to check for the presence of an emacs process, and launch one if not found. afaik, that's all you can do. SRH -- I will protect you from your visions to save you from illusions I will protect you from ideals to save you from defeat[covenant]
Re: bug? with file-rc
"Oliver Elphick" writes: > It seems rather clumsy, though. Why was this scheme chosen, instead of > one where the K scripts are run for the previous runlevel? K scripts are not supposed to shut down everything that was started from that runlevel. They are supposed to shut down everything that should not be running in that runlevel. But if K scripts from the previous runlevel were run, each runlevel would have to contain a K script for each S script. Daemons would then get restarted whenever you moved between two runlevels that should both contain them. > The current > scheme works fine for shutting down and going to single user mode, but > is very clumsy for an administrator who wants to assign meanings to > run-levels 2 to 5 (which Debian does not currently do). It works very well for higher run levels. For example, if you want to run xdm in level 3, you place only S in 3, and only K everywhere else. Guy
Re: List of bugs that *must* be fixed before releasing Slink
Quoting Wichert Akkerman ([EMAIL PROTECTED]): > Previously Michael Stone wrote: > > > perl-suid 31904 [EMAIL PROTECTED]: Secuity hole with perl > > > (suidperl) and nosuid mounts on Linux] [13] (Darren Stalder <[EMAIL > > > PROTECTED]>) > > > > I'm not sure there's much we can do about this one--it's a library (kernel?) > > problem. Perhaps a note in the postinst that the 'nosuid' mount option won't > > work, and a suggestion that care be taken with user-mountable media? > > What perl-suid should do is check the mountoptions for the filesystem on > which the script resides and abort if that was mounted with nosuid. > Should be quite simple actually.. But that's still not general enough. For example, you just missed the case of noexec... The solution should be done at a higher level, IMHO, so we don't have to hack up every program that might try something like this (suid-python or suid-tcl or somesuch) and then rehack it when we come up with another failure case. But if we decide a quick hack is necessary, it needs to be thought out. [Snip updates on things that are fixed--great!] > > I'll look at 32485 unless someone has a patch ready. > > I fail to see why 32485 is release-critical.. there are probably lots of > other programs that also don't work with MD5 passwords. Do I hear > somebody saying PAM? Well, I think that this program is odd enough to be worth fixing (specifically, where did it come up with 20-something as the max password length?) And I haven't found much else that breaks with long passwords. (E.g., login's fine, xdm's fine, ssh works, ftp's ok.) Besides, this is something that will have to be fixed eventually for pam, but it's seperate from the pam-specific mods that need to be done. Mike Stone pgpn4x4MbhSW5.pgp Description: PGP signature
Re: List of bugs that *must* be fixed before releasing Slink
Quoting David Starner ([EMAIL PROTECTED]): > No. The maintainer needs to get the new license (or clarification of the > old, depending on how you split your hairs) from the LyX website and > change the copyright file. Being more or less error-proof, it seems to > call for a simple NMU. I thought I saw a message on -devel that someone had gotten this? Mike Stone
Re: seeking new maintainer: lilo
On Sat, Jan 30, 1999 at 12:27:15AM -0800, Joseph Carter wrote: > I wouldn't mind taking lilo Ok, looks like Vincent Renardi took the package over and has uploaded an -4 already. Thanks. Bernd
Re: List of bugs that *must* be fixed before releasing Slink
All right, here's the revised list (removing anything that someone confirmed as almost done.) Quoting Michael Stone ([EMAIL PROTECTED]): > > apache32204 user directories allow symlinks to other files [0] > > (Johnie Ingram <[EMAIL PROTECTED]>) > > There's a suggested fix in the bug report. Is it problematic? > > > boot-floppies 32269 partion harddisk fails if WIN95_EXTENDED present > > [0] (Enrique Zanardi ) > > The report log is a little unclear. It looks like there is a version of cfdisk > that works...are we just waiting for an upload? > > > dpkg 17624 dpkg: installs regular dir when .deb contains > > symlink ! [364] (Ian Jackson and others <[EMAIL PROTECTED]>) > > dpkg 21182 dpkg: dpkg can go into an infinite loop with > > --force-configure-any [288] (Ian Jackson and others <[EMAIL PROTECTED]>) > > dpkg 28519 dpkg: dpkg creates circular symlinks [93] (Ian > > Jackson and others <[EMAIL PROTECTED]>) > > dpkg 30090 weirdass dpkg coredumps and xbase upgrade insanity > > [62] (Ian Jackson and others <[EMAIL PROTECTED]>) > > dpkg 30891 dpkg: Patch for update-alternatives to fix jdk > > problems [40] (Ian Jackson and others <[EMAIL PROTECTED]>) > > dpkg 32283 xbase postinst refers to nonexistent README.Debian > > [0] (Ian Jackson and others <[EMAIL PROTECTED]>) > > No one ever wants to touch dpkg... > > dpkg-dev 31508 parsechangelog broken? [22] (Ian Jackson and > > others <[EMAIL PROTECTED]>) This is supposed to have an attached fix. > > dpkg 28817 dpkg takes no care over libdpkg [87] (Ian Jackson > > and others <[EMAIL PROTECTED]>) Wichert argues whether this one's really release critical. > > ftp.debian.org31282 upgrade-1386 directory in Incoming [30] (Guy Maor > > <[EMAIL PROTECTED]>) > > ? > > > general 28850 gettext: security problem when used in setuid > > programs [0] (debian-devel@lists.debian.org) > > What needs to be done here? This needs maintainers of setuid/root-run programs to check their stuff. Is there a way for non-maintainers to help with this, or do we just hope it gets done? Is there a way for maintainers to indicate they've already checked their packages? > > jdk1.132548 Java doesn't work at all for me on slink [0] > > (Stephen Zander <[EMAIL PROTECTED]>) Someone might be working on this? > > lyx 32299 LyX Copyright problems [0] (Stuart Lamble <[EMAIL > > PROTECTED]>) There should be a new license waiting to be packaged. > > nonus.debian.org 23780 nonus.debian.org: libssl-dev is obsolete [220] > > (Heiko Schlittermann <[EMAIL PROTECTED]>) > > nonus.debian.org 26443 nonus.debian.org: apache-common_1.3.0+1.19 is > > obsolete [144] (Heiko Schlittermann <[EMAIL PROTECTED]>) > > nonus.debian.org 29246 nonus.debian.org: remove > > fortify-unix-ppc_1.2.8-1.deb [79] (Heiko Schlittermann <[EMAIL PROTECTED]>) > > nonus.debian.org 31326 Broken symlinks on nonus.debian.org [29] (Heiko > > Schlittermann <[EMAIL PROTECTED]>) > > nonus.debian.org 32171 umet dependency for mutt-i [8] (Heiko > > Schlittermann <[EMAIL PROTECTED]>) mutt-i just need to disappear, right? Or should we do another virtual package to get mutt to install in its place? > Will non-us ever be fixed? All I've heard is agreement that this situation is non-optimal. (Or words to that effect :) > > perl-suid 31904 [EMAIL PROTECTED]: Secuity hole with perl > > (suidperl) and nosuid mounts on Linux] [13] (Darren Stalder <[EMAIL > > PROTECTED]>) This still needs a good solution. > > smb2www 32131 smb2www: smb2www in slink incompatible with samba > > in slink [9] (Craig Small <[EMAIL PROTECTED]>) > > Is the potato version going to be installed, or is there another fix? > > > wdm 32485 wdm: Doesn't let people log on when using MD5 > > passwords [0] ([EMAIL PROTECTED] (Marcelo E. Magallon)) > > Looks like this needs a patch. > > > wdm 32529 Typo in Xsession [0] ([EMAIL PROTECTED] (Marcelo > > E. Magallon)) > > Log's unclear again; is this really an xbase problem? Is it fixed? > > > xbase 30852 X packages do not upgrade automatically due to > > name change. [41] (Branden Robinson <[EMAIL PROTECTED]>) > > xdm 29360 xdm: Stopped X without warning/asking [77] > > (Branden Robinson <[EMAIL PROTECTED]>) > > xlib6 31610 xlib6: requires gcc but declares no dependency > > (dpkg --print-gnu-build-architecture?) [20] (Branden Robinson <[EMAIL > > PROTECTED]>) > > xserver-common29166 xserver-common: should depend or at least > > recommend properly ver'd xlib6g [81] (Branden Robinson <[EMAIL PROTECTED]>) There's supposed to be a new version of the X stuff; does it fix all of these? (Someone want to summarize the changelog? :) So, what's left? Looks like fairly simple fixes for apache, boot-fl
Re: Mail Being Lost Again
Quoting John Goerzen ([EMAIL PROTECTED]): > At the beginning of January, I reported that mutt was losing mail. This > behavior *appeared* to disappear with a certain kernel upgrade, but again it > persists. Losing mail is a very serious system failure. IIRC, you were using a mix of kernel versions, and it was suggested that you use the nolock mount option. Did you try this? Perhaps if you said what kernel & nfs version is on each machine, what you're using as mount options, etc., we would have some idea of what's happening. Mike Stone
Re: List of bugs that *must* be fixed before releasing Slink
On Sun, Jan 31, 1999 at 10:54:20AM -0500, Michael Stone wrote: > > > xbase 30852 X packages do not upgrade automatically due to > > > name change. [41] (Branden Robinson <[EMAIL PROTECTED]>) > > > xdm 29360 xdm: Stopped X without warning/asking [77] > > > (Branden Robinson <[EMAIL PROTECTED]>) > > > xlib6 31610 xlib6: requires gcc but declares no dependency > > > (dpkg --print-gnu-build-architecture?) [20] (Branden Robinson <[EMAIL > > > PROTECTED]>) > > > xserver-common29166 xserver-common: should depend or at least > > > recommend properly ver'd xlib6g [81] (Branden Robinson <[EMAIL > > > PROTECTED]>) > > There's supposed to be a new version of the X stuff; does it fix all of these? Yes. 30852: xbase is now a pseudo-package that depends on the packages that have bits of the old xbase 29360: point 1) is an issue for the release notes; I can't retroactively patch an old prerm; 2) seems to be fixed thanks to Marcelo's xdm patch (but I'd like more testing); 3) I am not having xdm depend on any xfonts packages or xfs (contrary to my last bug mail), because there's really no way to put Depends: "xfonts-base | font-path-in-your-XF86Config-file-that-points-to-a-working-font-server- which-has-the-fonts-you-want" xdm depends on fonts no more or less than any other X client, so there is no reason to give it special treatment. 31610: long story short, this is fixed in -9 29166: this is fixed too. The stuff that depends on xlib6g has been moved into xbase-clients; xserver-common is not supposed to have anything to do with the X libraries (so as to support X-server-only installations) -- G. Branden Robinson | Any man who does not realize that he is Debian GNU/Linux | half an animal is only half a man. [EMAIL PROTECTED] | -- Thornton Wilder cartoon.ecn.purdue.edu/~branden/ | pgpsF9uqt62L5.pgp Description: PGP signature
Re: Mail Being Lost Again
On Sun, Jan 31, 1999 at 02:15:07PM +0100, Wichert Akkerman wrote: > Previously John Goerzen wrote: > > Also, whenever I shut down the client (an Alpha box), it displays: > > lockd_down: no lockd running > > What kind of NFS server are you using? Linux? User or kernel nfsd? I believe (I thought I said anyway) that the server is nfs-server running on 2.0.35. > Are you running rpc.lockd? Mounting with nolock? You really need to As far as I can tell, no rpc.lockd is available for Debian. In any case, I don't appear to be running it. I am not using nolock. > tell us a bit more.. > > Wichert. > > -- > == > This combination of bytes forms a message written to you by Wichert Akkerman. > E-Mail: [EMAIL PROTECTED] > WWW: http://www.wi.leidenuniv.nl/~wichert/
Re: dinstall can now announce packages & close bugs for you
On Sun, Jan 31, 1999 at 06:10:11AM -0800, Guy Maor wrote: > dinstall will look for a Format field of 1.6 and a new Closes field. > Closes is a space separated list of bugs closed by the upload. In > your changelog, the perl regular expression > /closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/i is used to build the Closes > field. Here is an example: Is this Format field supposed to be in the local-var block at the bottom of the changelog? Also, does it check that the bug it's closing actually is related to one of the packages in the upload to avoid the eminent typos? -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]> Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: dinstall can now announce packages & close bugs for you
Also, would somebody please document this in the Packaging manual? Otherwise, it won't be terribly useful as anybody that didn't see the message won't know about it. On Sun, Jan 31, 1999 at 12:19:33PM -0500, Ben Collins wrote: > On Sun, Jan 31, 1999 at 06:10:11AM -0800, Guy Maor wrote: > > dinstall will look for a Format field of 1.6 and a new Closes field. > > Closes is a space separated list of bugs closed by the upload. In > > your changelog, the perl regular expression > > /closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/i is used to build the Closes > > field. Here is an example: > > Is this Format field supposed to be in the local-var block at the > bottom of the changelog? > > Also, does it check that the bug it's closing actually is related to > one of the packages in the upload to avoid the eminent typos? > > -- > --- - - --- - - - --- > Ben Collins <[EMAIL PROTECTED]> Debian GNU/Linux > UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] > -- -- - - - --- --- -- The Choice of the GNU Generation > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for mascot! :-) -- flying pigs
hi Ship's Log, Lt. Phillip R. Jaenke, Stardate 300199.2241: > > Why a dolphin? Well, they're intelligent. Definitely intelligent. They're > pretty cute. :) And they're definitely flexible. (I'd like to see *you* > burst out of the water, do a backflip or two midair, and make a perfect > reentry.;) ok .. beat me for this .. but it does not realy meen 'good bye and thankyou for the fish' ! Dolphins are not more intelligent then paes or other animals. Intelligence referes also to somewhat of abstract thinking which no animal has. Greetings -- Alexander N. Benner And Jesus answered him, The first of all the commandments is, Hear, O Israel; The Lord our God is one Lord: And thou shalt love the Lord thy God with all thy heart, and with all thy soul, and with all thy mind, and with all thy strength: this is the first commandment. -*- The Bible (Mark 12:29-30)
Re: WARNING: Re: debhelper & /usr/bin/passwd
hi Ship's Log, Lt. Brian May, Stardate 310199.1320: > I have noticed this behaviour, too. However, at the time, I assumed > the apt-get forced the file to be overwritten because the package > I was installing was required/base (ldso from memory, but this > problem has already been fixed). Now I am not so sure. > > Can you be certain that dselect doesn't give dpkg the --force-overwrite > option? I experienced this beheaviour too with ssh/cfs which are both in non-US This is a very bad thing as the ssh of cfs is something compleatly diferent and should be renamed. Greetings -- Alexander N. Benner - Christen im Internet - http://www.christen.net/ pgp : E7BCBEBD 53 5F 48 0A 0D 3E 4A 38 A8 11 B1 AF BE 08 C8 B0 You can't be american if you don't have children. I need a wife soon. MegaHAL
Re: List of bugs that *must* be fixed before releasing Slink
Michael Stone <[EMAIL PROTECTED]> writes: > > sysutils 29392 oldversion procinfo in sysutils is broken [76] > > (Michael Alan Dorman <[EMAIL PROTECTED]>) > > Is there a reason not to put the new version in? I need someone to confirm for me that the new sysutils that I put in potato will work with 2.0.X kernels. I don't have one to test with---my only non-production system can't do 2.0.X because of driver issues. Other than that, moving the 1.3.3 from potato to slink should take care of this. Mike.
Re: dinstall can now announce packages & close bugs for you
On Sun, Jan 31, 1999 at 06:10:11AM -0800, Guy Maor wrote: > dinstall, the software which installs packages into the hierarchy, can > now announce packages and close bugs for you. Hmm, is it really a good thing to have dinstall announce the uploads? I often depend on the announcements to alert me to new versions in Incoming. In the new setup, the announcements won't come until the package is installed, which in some cases can be several weeks. Adam
Re: Ian's solution [was: What hack in ld.so?]
Gordon Matzigkeit writes: > Hi, all! > There's been so much traffic on this thread, that I suspect most > people have missed the fact that Ian Lance Taylor has analyzed and > *solved* the problems with interaction between libtool and > libc5-compat shared libraries. By, as far as I can tell, breaking the ABI. I suppose that an alternative hack would be not to take the DT_RPATH as cast is stone, but subject it to some kind of rewriting if the binary is found to use libc5. For example, you could try to quietly append "/libc5-compat" to every component, on the assumption that on a libc6-based system, all libc5 binaries will be moved to such locations. Another good point that was raised is that some systems, like IRIX, have environment variables that are used by rld (the run-time loader on IRIX) to select a whole different root (_RLD_ROOT), or just to have some directories searched before even DT_RPATH is checked (_RLD_PATH? I'll have to check). (Use of _RLD_ROOT, combined with the ability to extract a package under an alternate root is precisely what is required to get several incompatible packages to live together on a single system.) That having been said, I do believe that to use -rpath to specify system directories is a bad idea, if for no other reason than that it prevents users from using LD_LIBRARY_PATH to customize their environment. Instead they have to rely on non-standard extensions. I do realise that on Linux, thanks to the ldconfig mechanism, the set of system directories is rather fungible. On IRIX for example, the system directories for o32 binaries are /lib and /usr/lib, period. The case for using -rpath is a lot more clear-cut on some systems than on others. -- Olaf Weber
Anyone have a slink box I could use?
I need to make a new frozen release of wmakerconf, but my system is potato all the way. Does anyone have a computer I could compile this on? Adam
Re: List of bugs that *must* be fixed before releasing Slink
>> "MD" == Michael Alan Dorman <[EMAIL PROTECTED]> writes: MD> I need someone to confirm for me that the new sysutils that I put MD> in potato will work with 2.0.X kernels. I don't have one to test MD> with---my only non-production system can't do 2.0.X because of MD> driver issues. It does for me. No segfaults. Kernel 2.0.34, sysutils 1.3.3.1 Ciao, Martin
Re: Call for mascot! :-)
On Sat, Jan 30, 1999 at 12:53:28PM -0500, Zephaniah E. Hull wrote: > On Thu, Jan 28, 1999 at 10:14:15AM -0800, Chris Waters wrote: > > > I brought this up on IRC, and got the following suggestions: > > > > 1. Dragon (well-liked choice on IRC) > > 2. Octopus (my own suggestion) > > 3. Monkey > > 4. Ant > > 5. Bee > > > > Yes, that you are.. > > I say we should go for a nice feline, perhaps a tiger cub? > > Then again, I'm quite insane.. <=:] > > Zephaniah E. Hull. OK. I was thinking of this a lot the night after my exam (a nice way to forget I have one ;) .. and I think Debian "mascot" should in some way try to capture some of its essence. I feel some of the "essence" in keywords of Debian might be: volunteers, open source, collaborative work, freedom. I choose freedom, it's one that summarises it all, and trying to find an animal that, universally, would give the impression of freedom, I limited the choice to two bird species: - eagles, - hawks I like the dragon idea but I feel the "dragon" symbol is not all that universal, and many cultures tend to associate dragons with evil, as a matter of fact when culture talks about dragons (in a non-D&D world ;) there's always a hero that goes out to kill it for its evil deeds. Even though I'm a Dragonlance/D&D/Ars Magica fan, I would not choose the dragon because it's symbolism is somewhat limited... I *would* choose any of the above because I feel they capture Debian's spirit better. Picture a soaring royal eagle, for example, flying wild in a blue sky, there's nothing which gives a bigger sensation of freedom. And an eagle is menacing, and powerful, which Debian also is. So that's my proposal, sorry for being so "mystical", I'm in exam days you know >:) Javi
Intent to package ippl - obsolescence of iplogger
Hi all. I have been working with Etienne Bernard <[EMAIL PROTECTED]> on a replacement for iplogger for a few months. We have come up with a program called ippl (IP Protocols Logger) which has the following characteristics: * it logs ICMP messages. * it logs TCP connections. * it logs UDP messages. * it is configurable, with Apache-like rules (ex. "ignore icmp from *.debian.org"). However it does not do any ident query (yet?). Although it is still under development, it seems to work fine, so I would like to upload it in potato. For those of you who would like to try it out, it can be found in http://master.debian.org/~hugo/ippl/packages/. Any objections? It means that I will soon consider iplogger as obsolete. It means that I may still maintain it (unless anybody wants this package) but I will only do security fixes. All the enhancement queries will be forwarded to ippl (I have not heard from the new author for ages). Regards, Hugo -- Hugo Haas (http://www.via.ecp.fr/~hugo/)
Re: Call for mascot! :-) -- flying pigs
On Sun, 31 Jan 1999, M.C. Vernon wrote: > On 30 Jan 1999, Ben Pfaff wrote: > > > Kevin Dalley <[EMAIL PROTECTED]> writes: > > > >Anderson MacKay <[EMAIL PROTECTED]> writes: > > > >> On Thu, 28 Jan 1999, Avery Pennarun wrote: > >> > Octopi and ants may also be good, if they have wings. > >> > >> Octopi with wings? Now -that- is a confusing bunch of appendages, if > > you > >> ask me. =) > >Squid is a better choice than octopus. Some of them actually do fly > >for short distances. Perhaps glide is more accurate. What about a hybrid. An octupus/squid with a penguins head. OR a penguin with octupus tentacles. Same thing. -steve
Re: Anyone have a slink box I could use?
On Sun, Jan 31, 1999 at 10:17:59AM -0800, Adam Klein wrote: > I need to make a new frozen release of wmakerconf, but my system is potato > all the way. Does anyone have a computer I could compile this on? Sure. I just fresh reinstalled slink last night. Contact me privately for more information. Brian
Re: Ian's solution [was: What hack in ld.so?]
On Sat, Jan 30, 1999 at 10:40:33PM -0600, Gordon Matzigkeit wrote: > There's been so much traffic on this thread, that I suspect most > people have missed the fact that Ian Lance Taylor has analyzed and > *solved* the problems with interaction between libtool and > libc5-compat shared libraries. > > I'm quoting and reposting his message so that it doesn't get lost in > the shuffle. Please read and understand this message before posting > more flameage. I am the Debian and upstream maintainer of the libc5 ld.so. Ian's patch will not be going in. IMO, -rpath should not be used for any libraries installed in standard, system locations (i.e. any place listed in /etc/ld.so.conf). -rpath should only be used when libraries are installed in nonstandard locations. FWIW, I cringed the first time I saw what RedHat had done. They did not foresee the evils of -rpath and the problems it would cause in the libc5/libc6 transition. David > > Ian Lance Taylor writes: > > ILT> I just spent some time looking at the ld.so sources. > ILT> Interestingly, it seems to me that everything will work > ILT> correctly in the sources I was looking at. That is because the > ILT> libc5 dynamic linker on my system (RedHat 5.2) was modified to > ILT> search the library cache before using the application's > ILT> DT_RPATH. > > ILT> I think that is a hack that Debian is missing: it is the final > ILT> hack to the libc5 dynamic linker to change the search path to > ILT> account for the moved shared libraries even when rpath is used. > ILT> I have appended the RedHat patch below. This is to ld.so-1.9.5. > ILT> Of course, this will technically break the handling of DT_RPATH. > ILT> However, we've already determined that DT_RPATH binaries will > ILT> not work correctly anyhow, because the shared libraries were > ILT> moved. So using this patch should not make us any worse off. > > [...] > > ILT> Although I can not test this, I now believe that if you take a > ILT> libtool program, compile it on a libc5 Slackware and try to run > ILT> it on a RedHat 5.2 system, it will work. > > His patch follows... -- David Engel [EMAIL PROTECTED]
Re: List of bugs that *must* be fixed before releasing Slink
> Previously Brian White wrote: > > apache32204 user directories allow symlinks to other files [0] > > (Johnie Ingram <[EMAIL PROTECTED]>) > > We should just force SymLinksIfOwnerMatch for /home to solve this. You know, I don't see this as "grave". It means that a user can effectively "export to the world" any file readable by www-data. In general, this means only things that can be read by public. So, the user can't intentionally export anything that he/she couldn't already do by other means. The problem comes with unintentional exports... Well, it's a bug. I don't see it as being a security hole. Thoughts? > > dpkg 28817 dpkg takes no care over libdpkg [87] (Ian Jackson > > and others <[EMAIL PROTECTED]>) > > It's important but I wouldn't call this one release-critical. I looked at that one time, but I wasn't sure. Is it possible that during an upgrade to "stable" we get dpkg and dpkglib to be out-of-step? > > dpkg 30891 dpkg: Patch for update-alternatives to fix jdk > > problems [40] (Ian Jackson and others <[EMAIL PROTECTED]>) > > dpkg-dev 31508 parsechangelog broken? [22] (Ian Jackson and > > others <[EMAIL PROTECTED]>) > > I fixed these two in 1.4.0.33. I didn't close the bugs because I still > need to fix them for the dpkg in potato. You can downgrade them if you wish. > > fileutils 31717 fileutils: 'mv regularfile symlink' problems [17] > > (Galen Hazelwood <[EMAIL PROTECTED]>) > > Only in potato; looks like Brian forgot to add this one to his > exclusion-list again Oops. Done. > > ftp.debian.org32364 ftp.debian.org: please remove filters from > > stable/frozen [0] (Guy Maor <[EMAIL PROTECTED]>) > > filters is no longer in frozen, so this can be excluded as well. Done. Excludes list is now: 1797,20401,25405,25537,27381,27604,27738,27641,30087, 30184,31717,31806,32092,32364 > > general 28850 gettext: security problem when used in setuid > > programs [0] (debian-devel@lists.debian.org) > > Everyone who has a package with a setuid program or something that runs > as root should check if it uses gettext, and if so recompile it with > the latest gettext installed. Please not that this is not necessary for > programs that use the gettext from libc6. That needs to be re-filed against all those packages, then. Brian ( [EMAIL PROTECTED] ) --- You can't talk yourself out of problems you behave yourself into.
GTK oops?
Dear overworked gtk maintainer... Did you deliberately upload a version 1.1.14 of gtk1.1.13? Looks confused to me.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Installation Profiles
Jonathan P Tomer <[EMAIL PROTECTED]> writes: >a possibility i considered: divide user-space...packages into >heirarchical groups (structure identical or similar to the debian >menus, possibly?). have a level wherein the user selects any of these >he wants; it will be easy to skip those things he obviously doesn't >want (i can safely skip Applications/Ham-Radio and such things). The difficulty with this is coming up with groups that can be easily *excluded*. Sure, you can dispense with "hamradio". However, you can't exclude something like "text". If you are installing a business system, you might think you could eliminate "games". However, you would be missing fortune. Also typist. For some systems, you could eliminate "devel". In general, I expect that you couldn't eliminate more than 10 or 20 percent of any complete list of subjects. I suggest that we should offer several orthogonal ways to eliminate packages, such as: - subject, as above. - things that require X. - non-free. - language. The user should be able to specify a primary and secondary language, so everything else gets skipped. There are probably some more. Even if each one only eliminates 10 percent, they start to add up. However, the package selection tool has to let you specify all the criteria up front. Otherwise, you wind up reviewing the 90 percent that with possibly interesting subjects *plus* the 90 percent that are main+contrib *plus* the 90 percent that are not foreign language... which means you see most of the packages several times. >any dependencies are autoselected, so i don't have to spend hours >looking through libweird-2.3, libweird-2.3-dev, libweird2.3-dbg, >libweird2.3-doc, libweird4.2, libweird4.2-dev, libweird4.2-dbg, >libweird4.2-doc, ad infinitum (or at least ad nauseam). Yes! - Jim Van Zandt
Re: GTK oops?
On Sun, 31 Jan 1999, Jules Bean wrote: > Dear overworked gtk maintainer... > > Did you deliberately upload a version 1.1.14 of gtk1.1.13? Looks confused > to me.. Doh! I'll shut up now. Lesson - read the changelog.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Call for mascot! :-) -- flying pigs
"Alexander N. Benner" wrote: > > hi > > Ship's Log, Lt. Phillip R. Jaenke, Stardate 300199.2241: > > > > Why a dolphin? Well, they're intelligent. Definitely intelligent. They're > > pretty cute. :) And they're definitely flexible. (I'd like to see *you* > > burst out of the water, do a backflip or two midair, and make a perfect > > reentry.;) > > ok .. beat me for this .. but it does not realy meen 'good bye and thankyou > for the fish' ! Dolphins are not more intelligent then paes or other animals. > Intelligence referes also to somewhat of abstract thinking which no animal > has. Intelligence does not refer to "abstract thinking which no animal has". Intelligence refers to the capacity for thought, which even animals such as ants or fleas have to some minor extent. I've never heard it referred to as "abstract thought" only. Also why don't they have abstract thinking? I'm not up on cetacean biology, so let me discuss primates and analogize back. Primates have enough abstract thinking to speak and assemble objects in search of a future goal. Not much, but not non-existent. Cetaceans are a bit harder to study, as primates think alike, and in different ways from cetaceans. If they have enough intellegence to say "good bye and thanks for all the fish", then it wouldn't be at all suprising we missed the intellegence before. > > Greetings > -- > Alexander N. Benner > > And Jesus answered him, The first of all the commandments is, Hear, O Israel; > The Lord our God is one Lord: And thou shalt love the Lord thy God with all > thy heart, and with all thy soul, and with all thy mind, and with all thy > strength: this is the first commandment. -*- The Bible (Mark 12:29-30) But here's the real crux of the matter - we appear to be starting from two different ideological standpoints that each hold part of the answer as postulate. (Atheism over here, which holds that we are merely an evolutionary step from the primates, and are soulless animals oursleves.) As further argument would be fruitless and off topic, I will respond no further on list. -- David Starner - [EMAIL PROTECTED] Dullard: someone who, wanting a piece of information, takes down the appropriate volume of the encyclopedia, looks up the item they need, and then puts the volume away without reading anything else. - Peter Dell'Orto, paraphrased from Philip Jose Farmer
Re: GTK oops?
On Sun, 31 Jan 1999, Jules Bean wrote: > On Sun, 31 Jan 1999, Jules Bean wrote: > > > Dear overworked gtk maintainer... > > > > Did you deliberately upload a version 1.1.14 of gtk1.1.13? Looks confused > > to me.. > > Doh! > > I'll shut up now. > > Lesson - read the changelog.. Going for the record in self-sustaining threads.. There *is* a problem here: [EMAIL PROTECTED] zcat /usr/doc/libgtk1.1.13/changelog.Debian.gz | head -8 7:43PM gtk+1.1.13 (1.1.14-1) unstable; urgency=low * New upstream version. Note source name did not change, as the soname is still .13, because .14 and .13 are binary compatible. * Make absolutely sure the postinst for libgtk1.1.13 only calls ldconfig on 'configure' calls -- Ben Gertzfield <[EMAIL PROTECTED]> Fri, 29 Jan 1999 21:11:44 -0800 [EMAIL PROTECTED] dpkg -L libgtk1.1.13 | grep /usr/lib 7:44PM /usr/lib /usr/lib/libgdk-1.1.so.14.0.0 /usr/lib/libgdk-1.1.so.14 /usr/lib/libgtk-1.1.so.14.0.0 /usr/lib/libgtk-1.1.so.14 So it does in fact provide a library with soname .14. This breaks programs linked against .13.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: GTK oops?
Jules Bean wrote: > > On Sun, 31 Jan 1999, Jules Bean wrote: > > > On Sun, 31 Jan 1999, Jules Bean wrote: > > > > > Dear overworked gtk maintainer... > > > > > > Did you deliberately upload a version 1.1.14 of gtk1.1.13? Looks confused > > > to me.. > > > > Doh! > > > > I'll shut up now. > > > > Lesson - read the changelog.. > > Going for the record in self-sustaining threads.. > > There *is* a problem here: > > [EMAIL PROTECTED] zcat /usr/doc/libgtk1.1.13/changelog.Debian.gz | head -8 > 7:43PM > gtk+1.1.13 (1.1.14-1) unstable; urgency=low > > * New upstream version. Note source name did not change, as the > soname is still .13, because .14 and .13 are binary compatible. > * Make absolutely sure the postinst for libgtk1.1.13 only calls > ldconfig on 'configure' calls > > -- Ben Gertzfield <[EMAIL PROTECTED]> Fri, 29 Jan 1999 21:11:44 -0800 > > [EMAIL PROTECTED] dpkg -L libgtk1.1.13 | grep /usr/lib > 7:44PM > /usr/lib > /usr/lib/libgdk-1.1.so.14.0.0 > /usr/lib/libgdk-1.1.so.14 > /usr/lib/libgtk-1.1.so.14.0.0 > /usr/lib/libgtk-1.1.so.14 > > So it does in fact provide a library with soname .14. This breaks > programs linked against .13.. > > Jules According to the newest changelog (off debian-devel-changes) the maintainer realized this after he uploaded and uploaded a new and correct .13. -- David Starner - [EMAIL PROTECTED] Dullard: someone who, wanting a piece of information, takes down the appropriate volume of the encyclopedia, looks up the item they need, and then puts the volume away without reading anything else. - Peter Dell'Orto, paraphrased from Philip Jose Farmer
Re: GTK oops?
> "Jules" == Jules Bean <[EMAIL PROTECTED]> writes: Jules> Dear overworked gtk maintainer... Did you deliberately Jules> upload a version 1.1.14 of gtk1.1.13? Looks confused to Jules> me.. It was deliberate, but it was a mistake. The GTK+ maintainers told me 1.1.14 was binary compatible with 1.1.13 (because GLib 1.1.14 is binary compatible with 1.1.13) but it was not. It's been fixed; libgtk1.1.13_1:1.1.13-1 is in the archives now, and libgtk1.1.14_1.1.14-1 is awaiting approval. Ben -- Brought to you by the letters I and O and the number 8. "It is sad. *Campers* cannot *dance*. Not even a *party*." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
RE: Anyone have a slink box I could use?
On 31-Jan-99 Adam Klein wrote: > I need to make a new frozen release of wmakerconf, but my system is potato > all the way. Does anyone have a computer I could compile this on? > > Adam Adam, remember my VAIO laptop -- it is PURE slink. You or any other developer is welcome to contact me for help.
Proposal for new architecture support/distribution
-BEGIN PGP SIGNED MESSAGE- Hi there. Most of you probably don't know me. Don't worry about that; we can save introductions for a more appropriate place (read; off the list, private email.) Anyways, here I am, and I've got a proposal/idea that I'd like to run by all you happy overtaxed developers. A bit of history first, as it is somewhat important. For those of you who don't know; Linux runs on PowerPC's. Yes. It does. Now, what big names do we know that have PowerPC based systems? Let's see. Apple. Amiga. UMax. IBM RS/6000 (RISC System series-6000 for the unacquainted ones). Now, which one doesn't fit the semi-standard mold? That's right; the IBM RS/6000. There's also a great deal of diversity among the RS/6000 line. Processors used in the RS/6000 line are the Power2, PowerPC 603, PowerPC 603e, PowerPC 604, PowerPC 604e, PowerPC RS64 II, and the PowerPC with X5. Currently, only the PowerPC 603e, 604, and 604e's are supported by Linux. Another unique feature that the RS/6000 line has is SMP. The vast majority of RS/6000's are SMP in the base configuration. There are *very* few Macs with SMP. Almost none. Anyways, getting down to business. The diversity and other differences in the RS/6000 line directly results in some rather nasty incompatibilities. All of which can be dealt with, without too much trouble. So, I propose Debian/RS/6000. A distribution built specifically around and for RS/6000's. Anyone who's dealt with AIX knows that it can be more trouble than it's worth at times. Currently, to the best of my knowledge, Oracle, Sybase, IBM, Star Division, etc, have not put out PPC binaries of their respective products that they have ported to Linux. An 'official' port of Linux to the RS/6000 line would likely convince them to do so. The RS/6000 line is a highly respected line of servers and workstations. Mostly servers. Ranging from single-processor F40 3D Workstations to the monstrous HS, with the capability for over 32 processors. (*drool* Imagine Linux on that!;) Personally, I have had Linux running on two different RS/6000's; an F40 PowerPC Server with a lot of PC hardware[1], and a semi-stock Model 150[2]. I had almost no difficulty getting these systems booting Linux, and doing other handy tasks, such as apache, samba, and even CD writing. The goal of my plan? Little more than another piece of the key to Linux taking market dominance. *grin* Seriously; just to port Linux to yet another architecture, one that I personally have a great deal of respect for, and know that many share the same sentiment for. And to give RS/6000 users and administrators worldwide a choice. For those of you who don't know; RS/6000's only run AIX. There is no other 'official' OS for them. I'm not saying that this won't be a lot of work. Believe me; it will be. Many things will port very easily, but there are many things that will not. And there will have to be a lot of work to get the larger RS/6000's (ie; the S70 Advanced Server, which has 12 PowerPC RS64 II's) running Linux, but I believe that it is a worthwhile task. I started working on getting Linux on an RS/6000 about a year ago. Just as a sort-of joke. With the developments over the last year, I've realized that it could be a major thing. Unfortunately, I no longer have access to any RS/6000's. So what is needed for this project? Most importantly; hardware. RS/6000's. To be a success, we would at the least need access to several different RS/6000's. Preferrably an F40, an S70 Advanced Server, and a 397-series. PowerPC 604e, PowerPC RS64 II, and Power2 processors, respectively. We would also need manpower. One man does not a distribution make, afterall. It is my personal belief that with a small group of dedicated people, and a minimal amount of hardware to test on, we could have a working distribution for 603e, 604, and 604e processors inside of 9 months. PowerPC RS64 II based RS/6000's within 18 months to 24 months. Power2-based RS/6000's within 18 to 24 months as well. This could give Linux some *serious* market leverage, as well as major support. With IBM joining Linux International, I do not believe it would be hard to get support from them. Linux has already made headway into the x86 server market; I see no reason why it couldn't oust IBM's RS/6000 OS monopoly. Feedback, ideas, input, etcetera are quite welcome. Personally, I would like to get this project started as quickly as possible, but I do realize that it would most likely require a vote. And I have no problems with this. Thank you all very much for your time and thought, and thank you in advance for your input. :) [1] RS/6000 F40 PowerPC Server configuration: Dual PowerPC 604e's @ 225MHz Tekram DC390F PCI SCSI-UW controller (onboard SCSI not used) Intel EtherExpress/Pro 10/100 PCI Ethernet SoundBlaster 16ASP (Jumpered) Diamond FireGL 1000 Pro PCI Video card 512MB ECC memory [2] RS/6000 Model 150 Workgroup Server configuration: Single PowerPC 604e @ 375MHz Mylex BT-958 PCI
Re: Announce (and question): Masquerading PPP server based on Debian
On Fri, 8 Jan 1999 09:05:34 -0500 (EST), [EMAIL PROTECTED] (Ben Pfaff) said: > * Heavily modified the boot floppies to make them simpler and > less flexible; i.e., you aren't given choices about partitioning, it > does it for you. Thus the install is idiot-proofed enough that even > the guys in the local computer shop can do it. It also asks a few > pertinent questions, like would you like to run a DHCP server, and > it writes a configuration file for the administration tool (see > below). > Question: Would this system be useful to others? If so, how do you > suggest that I release it? I have a certain amount of ftp space > available to me, enough that I could put up a full binary and source > release. You've already had a number of suggestions on how to release this, Ben. I also suggest you work with the boot floppies team (). I think Enrique's number-one priority for potato boot-floppies is to let it be utterly scriptable (perhaps from an installation script file loaded from rescue floppy or the network). Maybe you could help Enrique design this system? I think it would be possible to specify even disk partitioning steps from some installation script, although I've no clue how you managed to do it on your system and am most curious. The more you can merge your changes into mainstream Debian, the more likely it is that your nice system will be merged in with other stuff, and actively maintained and extended. Thus, even your client will benefit (i.e., ask to get paid for the time!). -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/>
Re: Ian's solution [was: What hack in ld.so?]
Date: Sun, 31 Jan 1999 13:08:51 -0600 From: David Engel <[EMAIL PROTECTED]> I am the Debian and upstream maintainer of the libc5 ld.so. Ian's patch will not be going in. I think most people understand this, but I should make clear that it's not my patch. I assume it's from Eric Troan. I found it in the RedHat distribution. FWIW, I cringed the first time I saw what RedHat had done. They did not foresee the evils of -rpath and the problems it would cause in the libc5/libc6 transition. I can sympathize. I cringed the first time I saw how the dynamic linker had been hacked to no longer do a straight path search. There is some very ugly code in the binutils linker to deal with that. I guess it's something of a standoff. Somebody made what I consider to be an unfortunate decision a while back, with an incomplete hack to the dynamic linker. Now that decision is repercussing out to other software packages. I accepted the repurcussions into the binutils, overriding my personal judgement. Alexandre doesn't want to accept them into libtool, and I personally don't blame him. Alexandre has said that he's willing to accept a patch to not generate a -rpath argument for any directory listed in /etc/ld.so.conf. It's possible to construct cases for which this will fail--because of the dynamic linker hack, /etc/ld.so.conf is not synonymous with the list of directories the dynamic linker will search--but there will probably be fewer failure cases than the current situation. I encourage the people who can't abide the current situation to write such a patch. Let's not forget that this is only a temporary problem. Programs built using the current libtool on a current Linux system will work on all foreseeable future Linux systems, because nobody will ever have to make this type of unfortunate decision again. Ian
Re: Ian's solution [was: What hack in ld.so?]
From: Olaf Weber <[EMAIL PROTECTED]> Date: 31 Jan 1999 11:39:23 +0100 > Hi, all! > There's been so much traffic on this thread, that I suspect most > people have missed the fact that Ian Lance Taylor has analyzed and > *solved* the problems with interaction between libtool and > libc5-compat shared libraries. By, as far as I can tell, breaking the ABI. The ABI was broken a long time ago. That patch breaks it further. Ian
Re: [Suggestion] Dvipdfm, a DVI to PDF translator
On Sat, 9 Jan 1999 13:33:56 -0500 (EST), Dirk Eddelbuettel <[EMAIL PROTECTED]>
said:
> Someone might want to package this. From
> http://odo.kettering.edu/dvipdfm/:
FWIW, pdf{tex,latex,jadetex} already do a pretty nice job, too, if
you're just looking for hyperlinking from TeX-based systems.
--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>
Re: dinstall can now announce packages & close bugs for you
Adam Klein <[EMAIL PROTECTED]> writes: > Hmm, is it really a good thing to have dinstall announce the uploads? I > often depend on the announcements to alert me to new versions in Incoming. > In the new setup, the announcements won't come until the package is > installed, which in some cases can be several weeks. Um, hopefully it isn't several weeks any more now that Richard and James are helping with day-to-day work. I'll consider pre-announcing new packages. Guy
Re: dinstall can now announce packages & close bugs for you
John Goerzen <[EMAIL PROTECTED]> writes: > Also, would somebody please document this in the Packaging manual? > Otherwise, it won't be terribly useful as anybody that didn't see the > message won't know about it. I'll document as soon as I'm convinced that the bugs are out. > On Sun, Jan 31, 1999 at 12:19:33PM -0500, Ben Collins wrote: > > Is this Format field supposed to be in the local-var block at the > > bottom of the changelog? That field is already present in the .changes file; I've just upped the version. > > Also, does it check that the bug it's closing actually is related to > > one of the packages in the upload to avoid the eminent typos? No, but it's not as if I've increased the danger of typos. Before you might have sent email to the wrong address. Guy
Re: List of bugs that *must* be fixed before releasing Slink
Michael Stone <[EMAIL PROTECTED]> writes: > Well, let's see what's holding up slink. :) > > automake 32390 Automake patches for proper Alpha detection [0] > > (Kevin Dalley <[EMAIL PROTECTED]>) > > Maintainer says upload is coming. The fix has been uploaded and is waiting for installation. > > automake 32404 automake upgrade is not backwards compatible [0] > > (Kevin Dalley <[EMAIL PROTECTED]>) > > This bug is against the version in potato, not slink? Yes, this is a potato bug. It shouldn't stop slink. -- Kevin Dalley [EMAIL PROTECTED]
Re: Call for mascot! :-)
Javier Fdz-Sanguino Pen~a wrote: > OK. I was thinking of this a lot the night after my exam (a nice way >to forget I have one ;) .. and I think Debian "mascot" should in some way >try to capture some of its essence. > I feel some of the "essence" in keywords of Debian might be: >volunteers, open source, collaborative work, freedom. > I choose freedom, it's one that summarises it all, and trying to >find an animal that, universally, would give the impression of freedom, I >limited the choice to two bird species: > > - eagles Yes; I like this idea. How about a line drawing of an eagle in flight? We could have a bigger version somewhere with Evil Emperor Bill in its talons... -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 "Jesus saith unto him, I am the way, the truth, and the life; no man cometh unto the Father, but by me." John 14:6
Re: suid-perl
According to Michael Stone: > Quoting Wichert Akkerman ([EMAIL PROTECTED]): > > What perl-suid should do is check the mountoptions for the filesystem on > > which the script resides and abort if that was mounted with nosuid. > > Should be quite simple actually.. > > But that's still not general enough. For example, you just missed the > case of noexec... The solution should be done at a higher level, IMHO... Every OS has a different set of mount options that may or may not be relevant to setuid security. I don't see what 'higher level' would be useful. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "When do you work?" "Whenever I'm not busy."
