Re: Call for mascot! :-)
[EMAIL PROTECTED] (Martin Bialasinski) writes: Hmm, with a strong enough improbability field, you will see dragons in the sky. Dragons and octopi in the sky are Somebody Else's Problem.
Re: Call for mascot! :-)
*- On 28 Jan, Chris Waters wrote about Call for mascot! :-) 2. Octopus (my own suggestion) I like this. It would be great for CD covers were each tentacle could have text overlayed for each architecture: i386, arm, hurd, sparc, alpha, m68k, powerpc. Well that is seven but there may be more later or some other text could go over it. -- Brian -- Eighth arm could be IA64 due out next year. == Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: The Debian Logo-team
On Thu, Jan 28, 1999 at 10:02:18PM +0100, Wichert Akkerman wrote: After getting a few volunteers and asking a few other people I present to you the Debian logo-team, who will select the best logos for your voting pleasure: * Wichert Akkerman [EMAIL PROTECTED] * Teemu Hukkanen [EMAIL PROTECTED] * Nils Lohner [EMAIL PROTECTED] * James Treacy [EMAIL PROTECTED] * M. Vernon [EMAIL PROTECTED] Not to sound put off by this, just wondering on what criteria you selected the team. Considering I offered to help, and the fact that I have a strong background in desktop publishing and web design (strong, as in 8 years working experience) I would have thought my knowledge to have been useful. Ben (who isn't getting an attitude, just wanting clarification) -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Seeking Helmut Geyer Helmut.Geyer@iwr.uni-heidelberg.de
Helmut Geyer is listed as the maintainer for xxgdb and bzip - xxgdb hasn't had a maintainer upload since when bo was frozen, and bzip's last maintainer upload was longer ago than that. Mail sent to his listed address goes unanswered, but maybe that's because I only waited a week. Is he still with us? Helmut, are you out there? This is being CC:'ed to Martin Mitchell in the vague hope that he has contacted Helmut more recently than summer of 1997, as he did the last NMUs of both xxgdb and bzip.
Re: The Debian Logo-team
On Thu, Jan 28, 1999 at 07:40:28PM -0500, Ben Collins wrote: * Nils Lohner [EMAIL PROTECTED] * James Treacy [EMAIL PROTECTED] Well, these guys are obvious... Nils has done a *great* job at getting lots of Debian press releases out there, and James is our webmaster. -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org
experimental new strace
Joel Klecker just reminded me of a strace tarball from Ulrich Drepper with a lot of his changes, and since I aim to make Debian's strace the one-and-only-strace that includes all possible features I had to incorporate it in my sources.. so I just went through a nice 6500-line diff and modified quite a lot of strace in the process (yes folks, it is official now: even Ulrich Drepper can make amazingly silly errors!). I probably broke a lot of stuff, most likely sparc code, but it seems to work for me. I want to urge everyone to try this package, especially on powerpc (I moved a lot of syscalls around that might break there) and sparc (UD handled a couple of sparc things differently, I could have broken something in the merger). Oh, you have to have 2.1.x or 2.2.x kernel sources in /usr/scr/linux to compile this thing, the includes from glibc2 are not good enough. And no, I don't think I'll fix that: I need the include from a recent kernel to get the structures for stat and signal correct.. Finally a note to the guy who made the 3.1.0.1-9.1 NMU: tough luck, I didn't incorporate your changes since you never send them to me. Better luck next time. Oh, the new version is 3.1.0.1-10, it's in Incoming, but you can get it at http://www.wi.leidenuniv.nl/~wichert/debian/testing in the meantime. 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/ pgporIGgD3wLZ.pgp Description: PGP signature
Re: The Debian Logo-team
Previously Ben Collins wrote: Not to sound put off by this, just wondering on what criteria you selected the team. Considering I offered to help, and the fact that I have a strong background in desktop publishing and web design (strong, as in 8 years working experience) I would have thought my knowledge to have been useful. I used a simple selection method: people I asked since I felt they should be in there (Nils and James), and people who volunteered and had a good explanation of why they felt they could contribute. Finally 5 people sounded like a nice number. I indeed asked around on irc a bit if people were interested in this and you said you we were to help out, but you never answered my question why you would make a good choice. So I didn't know about your background in publishing and web design. I'm willing to step out and let you take my place though, since it seems you have much more knowledge about good logos then I do. 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/ pgpyGX0qSBo6J.pgp Description: PGP signature
RE: Call for mascot! :-)
On Thu, 28 Jan 1999, Darren Benham wrote: On 28-Jan-99 Chris Waters wrote: While I'm on the topic of the logo, it occurred to me that it might be nice to choose a mascot for the Debian project. Some sort of beast that we can use in the logo and in other Debian-related images. Much as Linux has its penguin, BSD has its devil, and GNU has its, erm, gnu. Debian should have its own mascot, IMO, separate from any of these. This may be a little to wierd, but what about a turtle swimming in a endless sea (like the old cosmology) and then on its shell riding along are a penguin and a Gnu as if they were friends. Or perhaps some other penguin Gnu combo? just a thought - steve
Re: The Debian Logo-team
On Fri, Jan 29, 1999 at 02:33:11AM +0100, Wichert Akkerman wrote: I indeed asked around on irc a bit if people were interested in this and you said you we were to help out, but you never answered my question why you would make a good choice. So I didn't know about your background in publishing and web design. I'm willing to step out and let you take my place though, since it seems you have much more knowledge about good logos then I do. Actually I did answer, but not in a very serious tone, so I can see how you might think I was not serious about helping. Telling you my background in design was how I volunteered for it on IRC, if you missed that (and considering the noise level in the channel at the time, it is very possible), I appologize. Please, don't step out on my account, I'm sure your reasons for choosing who you did were very well founded, and I'm not about to accept the offer simply because I whined about it, but thanks, and sorry for any misunderstanding. -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
libvdk 0.5.1 ready for testing
Hi, (B (BThis is the latest release of the vdk. I hope to be informed as soon as (Bpossible as being a debian developer and upload it to Incoming. (B (BPlease test it and tell me if something's wrong as this is my first (Battempt to package a library (and seccond to package anything). (B (Bhttp://borco-ei.eng.hokudai.ac.jp/~borco/vdk/download/vdk/unstable/ (B (BThe previous version of vdk 0.4.2 is also packaged in (B (Bhttp://borco-ei.eng.hokudai.ac.jp/~borco/vdk/download/vdk/stable/ (B (Bbut I think I will not upload this. vdk0.5.1 uses the gtk1.1.13 while (Bvdk0.4.2 uses gtk1.0.x. The development is now focused on the gtk1.1.13. (B (BVDK is a nice C++ wrapper arround gtk (I think much nicer than gtk--, (Bbut this is a mater of taste, I agree). (B (BTIA, (B (BIonutz
Gnome-apt debs now available
plug level=blatant Who says package management can't be Sexy? Be the first one on your block to try Gnome-apt, the new GUI front end for the Debian package tool. It slices... it dices... it makes fresh pasta... and it has a groovy search function! /plug debs for gnome-apt are now available at http://www.debian.org/~mblevin/gnome-apt/ Gnome-apt is a gnomeified front-end for apt, written by Havoc Pennington. You can read more about gnome-apt at Havoc's page http://www.debian.org/~hp/gnome-apt.html Gnome-apt requires the latest cvs build of apt_0.3.0, which you can also find at the above site. All other dependencies should be available at your local Debian mirror. You can fetch both gnome-apt and the required cvs version of apt by adding the following line to your /etc/apt/sources.list deb http://www.debian.org/~mblevin/gnome-apt ./ Please do _not_ send bug reports to the BTS. Send bugs directly to Havoc [EMAIL PROTECTED] and copy any packaging bugs to me [EMAIL PROTECTED] Patches and suggestions from gtk/gnome coders are appreciated. **DISCLAIMER** gnome-apt is ALPHA software, and manipulates the package database for your system. Please do not use unless you are willing to get your hands dirty or take risks. -Mitch pgpnABQIRO561.pgp Description: PGP signature
Re: Gnome-apt debs now available
On Thu, 28 Jan 1999, Mitch Blevins wrote: You can fetch both gnome-apt and the required cvs version of apt by adding the following line to your /etc/apt/sources.list deb http://www.debian.org/~mblevin/gnome-apt ./ It is customary to use an entry like deb http://www.debian.org/~mblevin gnome-apt/ That gives nicer displays with APT - to do so you must generate the package file in ~mblevin and put it in gnome-apt. Please do _not_ send bug reports to the BTS. Send bugs directly to Havoc [EMAIL PROTECTED] and copy any packaging bugs to me [EMAIL PROTECTED] Might just say 'send them to [EMAIL PROTECTED]' which is this list that you and havoc are on - it also should be listed as the maintainer field for gnome-apt. **DISCLAIMER** gnome-apt is ALPHA software, and manipulates the package database for your system. Please do not use unless you are willing to get your hands dirty or take risks. Well, it might call dpkg with funny args but manipulates the package database is kinda overkill : Jason
Re: Call for mascot! :-)
Edward John M. Brocklesby [EMAIL PROTECTED] writes: I don't think so - Octopi can't fly! Someone who obviously hasn't read RFC 1925... RFC1925 asserts that under appropriate circumstances, -pigs- can fly. It makes no comment on the aerodynamic properties of cephalopods. -- James Never trust trucks -- Buddha Buck [EMAIL PROTECTED] Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects. -- A.L.A. v. U.S. Dept. of Justice
Re: Gnome-apt debs now available
Jason Gunthorpe wrote: On Thu, 28 Jan 1999, Mitch Blevins wrote: You can fetch both gnome-apt and the required cvs version of apt by adding the following line to your /etc/apt/sources.list deb http://www.debian.org/~mblevin/gnome-apt ./ It is customary to use an entry like deb http://www.debian.org/~mblevin gnome-apt/ That gives nicer displays with APT - to do so you must generate the package file in ~mblevin and put it in gnome-apt. I don't want to put a Packages in my base public_html, but you can also access this thru deb http://www.debian.org/~mblevin/apt gnome-apt/ Please do _not_ send bug reports to the BTS. Send bugs directly to Havoc [EMAIL PROTECTED] and copy any packaging bugs to me [EMAIL PROTECTED] Might just say 'send them to [EMAIL PROTECTED]' which is this list that you and havoc are on - it also should be listed as the maintainer field for gnome-apt. *Retraction* Please send all bug reports/suggestions to [EMAIL PROTECTED] **DISCLAIMER** gnome-apt is ALPHA software, and manipulates the package database for your system. Please do not use unless you are willing to get your hands dirty or take risks. Well, it might call dpkg with funny args but manipulates the package database is kinda overkill : An earlier version of gnome-apt caused the CD-ROM to eject so forcefully that the CD flew across the room and I came _this_ close to spending the rest of my life with a Greatful Dead CD embedded 2 inches into my skull. Please use Caution. ;) -Mitch
Intent to package gbdk.
gbdk is a acronym of Gameboy Developer's Kit. This is a description for it. --- Package: gbdk Priority: optional Section: non-free/devel Installed-Size: 649 Maintainer: Masato Taruishi [EMAIL PROTECTED] Version: 2.0.17-3 Depends: libc6 Suggests: gbdk-examples Description: GameBoy Developer's kit - binary package The GameBoy Developer's Kit (GBDK), is a set of tools that enable to develop programs for the Nintendo GameBoy system, either in C or in assembly. GBDK includes a set of libraries for the most common requirements and generates image files for use with a real GameBoy or with an emulator like VGB or no3gmb. . This package contains compiler, assembler ,linker and documents. - The reason for non-free is this in copyright: Permission to use, copy, modify, and distribute this software for any purpose, subject to the provisions described below, without fee is ^^^ Thanks --- --University of Electro Comunications Junior --- Masato Taruishi E-mail:[EMAIL PROTECTED]
Re: Gnome-apt debs now available
Jason Gunthorpe wrote: On Fri, 29 Jan 1999, Mitch Blevins wrote: That gives nicer displays with APT - to do so you must generate the package file in ~mblevin and put it in gnome-apt. I don't want to put a Packages in my base public_html, but you can also access this thru deb http://www.debian.org/~mblevin/apt gnome-apt/ No you can't, your paths are like this: Filename: ./apt_0.3.0_i386.deb They need to be Filename: gnome-apt/apt_0.3.0_i386.deb Now how you do that is like this: cd ~/public_html dpkg-scanpacakges gnome-apt/ /dev/empty | gzip gnome-apt/Packages.gz Thanks Jason... I was trying to be too clever with symlinks for my own good and make it work also with the original posting. You should be able to access now thru either the original post: deb http://www.debian.org/~mblevin/gnome-apt ./ Or thru the following (which will be used for all future releases): deb http://www.debian.org/~mblevin/apt gnome-apt/ -Mitch
gnuserv/gnuclient problem
Hi, (B (BIs the gnuclient/gnuserv broken in XEmacs ? Using the latest versions (Bfrom potato I am no more able to start a gnuclient :-( Is anybody else (Bexperiencing this ? (B (BIonutz
Intent to package: tkmasqdialer, wxwin2-doc, python-wxwin
Hi, I'm getting ready to package three new packages for potato: tkmasqdialer: This is a Tk client to the masqdialer PPP control daemon I maintain. The code works, but needs beating upon. (potato will certainly do that...) wxwin2-doc: Documentation on the wxWindows class library (currently in potato as wxgtk2). python-wxwin: A Python binding for wxWindows. Referred to as wxPython upstream, but name changed to fit with python package naming pseudo policy. Comments? Suggestions? Brian
Re: Intent to package : xmem
On Thu, Jan 28, 1999 at 02:01:09PM -0600, David Welton wrote: I think it's kind of silly that we no have this more or less 'elementary' X package, so I'm offering to package it. Is it generated from the X sources (in which case, maybe I'll just limit myself to pestering Branden:-), or proc, or is it its own thing? As far as I know, there aren't any X clients in the X sources that I don't ship (with the exception of xdmshell). -- G. Branden Robinson | If you make people think they're Debian GNU/Linux | thinking, they'll love you; [EMAIL PROTECTED] | but if you really make them think, cartoon.ecn.purdue.edu/~branden/ | they'll hate you. pgpkuEFKyHgk0.pgp Description: PGP signature
is gdb broken ?
Hi, (B (BI am unable to debug anything. I'm trying to add a breakpoint and gdb (Bresponds that it can't. Here is what I get: (B (B(gdb) file /home/borco/c++/boltzmann/src/boltzmann (B(gdb) break main.cc:92 (BBreakpoint 1 at 0xbbf8: file main.cc, line 92. (B(gdb) run (BBreakpoint 1 at 0x823adb0: file main.cc, line 92. (BCannot insert breakpoint 1: (BCannot access memory at address 0x823adb0. (B(gdb) step (BSingle stepping until exit from function _dl_debug_state, (Bwhich has no line number information. (BCannot insert breakpoint 1: (BCannot access memory at address 0x823adb0. (B(gdb) (B (BI have used these flags to build my application: (BCFLAGS = -I. -Wall -W -g `gtk-config --cflags` (BLFLAGS = `gtk-config --libs` -lvdk -lf2c -lm (B (Bgdb: 4.17.19981224-3.m68k.objc.threads.hwwp.fpu.gnat (B (BIs there are debuggers for Debian ? (B (BTIA, (B (BIonutz
Re: is gdb broken ?
Hi, (B (BThis seemed to be a wrong example of what I get. Actually the breakpoint (Bwas on a declaration *blush* (B (BHowever, all my breakpoints are ignored and the program run normally as (Bfrom the console: no way to interupt it :( (B (BAny ideas ? (B (BIonutz (BIonutz Borcoman wrote: (B (B Hi, (B (B I am unable to debug anything. I'm trying to add a breakpoint and gdb (B responds that it can't. Here is what I get: (B (B (gdb) file /home/borco/c++/boltzmann/src/boltzmann (B (gdb) break main.cc:92 (B Breakpoint 1 at 0xbbf8: file main.cc, line 92. (B (gdb) run (B Breakpoint 1 at 0x823adb0: file main.cc, line 92. (B Cannot insert breakpoint 1: (B Cannot access memory at address 0x823adb0. (B (gdb) step (B Single stepping until exit from function _dl_debug_state, (B which has no line number information. (B Cannot insert breakpoint 1: (B Cannot access memory at address 0x823adb0. (B (gdb) (B (B I have used these flags to build my application: (B CFLAGS = -I. -Wall -W -g `gtk-config --cflags` (B LFLAGS = `gtk-config --libs` -lvdk -lf2c -lm (B (B gdb: 4.17.19981224-3.m68k.objc.threads.hwwp.fpu.gnat (B (B Is there are debuggers for Debian ? (B (B TIA, (B (B Ionutz
/usr/lib/apt/methods/http - close(-1)
What is a close(-1) supposed to do? The http program does one and I'm curious as to why... FYI: ii apt 0.1.10 Front-End for dpkg -- I am in London and would like to meet any Linux users here. I plan to work in London for 6 months and then I might move to some other place where the pay is good.
Re: dpkg port to HP-UX
Fabrizio Polacco [EMAIL PROTECTED] writes: If I remember well, some time ago someone posted his results on a port of dpkg to HP-UX. Believe it or not, I've ported dpkg to HP-UX, AIX, Solaris, and Cygwin. (That's dpkg, dpkg-split, and dpkg-deb only. I wasn't interested in dselect at the time.) I can email you the diffs. I actually want to get the dpkg CVS tree back up, so I can enter these and other patches. The slew of NMUs was getting a little annoying. Hopefully the few who are familiar with the innards can start making contributions again. Guy
Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Marcus Brinkmann [EMAIL PROTECTED] wrote: On Wed, Jan 27, 1999 at 08:22:09PM -0200, Alexandre Oliva wrote: 3) I don't want to regret having introduced a flag that caused as much or more trouble than -rpath; and I don't understand this comment. Which trouble with --rpath do you mean? The exact problem the Debian developers have been complaining about. The more I think about the problem, the more I see that the problem they're facing is an incomplete hack of ld.so, in that it modifies the library search path under certain circumstances, but not in all circumstances that would need it. I.e., if ld.so would replace /usr/lib with /usr/lib/libc5:/usr/lib whenever it found that the application was linked with libc5, even if /usr/lib had been hard-coded in the program's rpath, everything would be working beautifully. The fact that libtool always hard-codes /usr/lib in a program that is linked with a libtool library that is (going to be) installed in /usr/lib is a side issue, because users may do it on their own, and, IMHO, they're not to be blamed because of doing that. Until now, I only heard from you that rpath is the ideal solution. Maybe you haven't read (or even received) one of my messages in the beginning of this discussion, in which I stated that even rpath is wrong in certain circumstances. For example, if a program is linked with libfoo, that lives in /foo, and libbar, that lives in /bar, but there's a compatible (WRT to version numbers, not necessarily WRT version of libc) version of libbar in /foo, the linker will pick the one in /foo, not the one in libbar. In fact, Thomas Tanner's suggestion of dropping -rpath when it would hard-code a standard library just makes this problem more apparent: if a (l)user installs a library in /usr/local/lib, but there's a library with the same name in /usr/lib, the version in /usr/lib will be used at run-time. This may have very bad consequences, such as the never-ending problem of (l)users installing gcc 2.[78].* in /usr and egcs 1.0.* in /usr/local, each one with its particular (and incompatible) version of libstdc++ (and libg++, for some). The only way to avoid this potential problem is to hard-code the full library path in the soname of the library itself, but then, this is not portable, and it is not desirable because then you can't move a library at all (read it again: I'm not talking about replacing a library with an apparently compatible but actually incompatible version of it :-) No rpath makes it harder for a user to determine exactly which system libraries he links with. (With rpath, though, it only works when the system administrator never changes the library file at this place, too). It is not a problem to move a library, as long as it can be found in other hard-coded rpath, in the default search path or in LD_LIBRARY_PATH. A problem only arises if an apparently compatible but actually incompatible library is found first, which is exactly the problem that the Debian developers are facing. 4) I have already suggested a (dirty and ugly, I admit) hack that is sufficient for your needs of not using -rpath at all in Debian packages. We can find our own hacks (and do so since a long time). Now we are interested in a compatible, portable and general solution. As the libtool maintainer, you should be the ideal person to talk about such a solution. I think we understood by now that a simple disable flag does not satisfy your high ambitions wrt to portability. Let's move on to better solutions. And, in fact, such a flag, that I said I was willing to accept, wouldn't actually help you much, because applications are distributed with their own versions of libtool, and you'd have to modify them all, or use your own hacked version of libtool to build all applications (via make LIBTOOL=/hacked/for/debian/libtool), so there'd not be much point in introducing this change only in libtool 1.3 and newer... :-( I hope you understand my position now. I should also note that I myself have already wanted flags such as -hardcode-libdir for hardcoding the full pathname of a shared library into itself (it's mentioned in libtool/TODO) and -no-implicit-rpath (which is what you happen to be asking for), but I have some trouble deciding who should be responsible for deciding which flags to use for which libraries and programs. Maybe you should not be the one to decide at all? I'm certainly not. Offer flexible solutions, where the last person can override the (possible) default given by others. That's the hard part. Overriding may have to occur in a per-library and/or per-program basis, so I haven't been able to come up with a satisfactory solution. This means, the package can provide a default, which can be overridden at compilation time. Finally, the installer can override both. That's exactly what I'm looking for. But I wouldn't like to install a quick hack now that would later reveal to be a step in the
Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote: 1) it would be hard to make it behave correctly in a portable way (and libtool would be useless if it were not for being portable); Special case-it for linux, if you will. Libtool has plenty of special cases as it is. Not in the interface it presents to its users. Internally, it's obviously full of special cases to support all the crazyness of OS developers and their wonderful dynamic linkers. -- 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: -rpath with libtool and Debian Linux
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote: Therefore, we chose to solve that particular problem (the libc5-6 transition) by moving libraries around, knowing that our linker was up to the job. It is now clear that it is not. :-( rpath is broken. You said as much yourself. rpath is broken because it *overrides* all other sorts of library searching. But isn't overriding library searching exactly what the ld.so hack is doing? Why is one of those blessed for doing that, while the other is crucified for guilt of all the sins of the world? :-) However, our dynamic linker *does* understand the problem. And it *does* have a solution to it. And -rpath turns it off. So we cannot afford to use -rpath. As I have already pointed out, the solution is not complete, otherwise you'd not be observing any problem. What do you mean the solution is not complete? It does not replace /usr/lib with /usr/lib/libc5:/usr/lib in the rpath. That's what is causing you trouble, not the fact that /usr/lib is hard-coded in the program. It works. It works well. If it worked well you wouldn't be complaining about a problem that is caused by its incomplete behavior, but that could be avoided by modifying other pieces of software that are doing their jobs correctly. -- 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: -rpath with libtool and Debian Linux
On Jan 27, 1999, Ulrich Drepper [EMAIL PROTECTED] wrote: Jules Bean [EMAIL PROTECTED] writes: rpath is broken. You said as much yourself. rpath is broken because it *overrides* all other sorts of library searching. I think people here do not know about $ORIGIN. This allows to define relative rpaths. E.g., a package with a program foo and a library libbar.so where foo is installed in $PATH/bin and libbar.so is defined in $PATH/lib should use -rpath \$ORIGIN/../lib The $ORIGIN is defined relative to the location of the object containing the reference. This is a great feature, but I think it is hardly usable by libtool, since, in order to use it, libtool would have to know at program link time where the program is going to be installed (it currently doesn't need this information), and it would have to check whether the libtool libraries that the program is linked with are going to be installed in paths that are easily accessible via \$ORIGIN relative pathnames, and that no soft-linking (say, /bin - /usr/bin but not /lib - /usr/lib) is going to break it, and probably many other potential problems that I can't foresee. But I agree, it's a nice feature, and we may be able to adopt it in the future, on platforms that support 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: -rpath with libtool and Debian Linux
On Jan 27, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote: Actually you want to know why I remember this? I used libtool a while back and I installed a copy of my program in /usr/bin and /usr/lib and wanted to us a new local copy of my libtool program. Of course libtool had used -rpath to make sure that my local binary used /usr/lib (as it was intended to be installed there someday) and then used LD_LIBRARY_PATH in the wrapper script to try to override this. Needless to say it did not work and it took me a bit of figuring to determine why my changes had no effect. Even in an all libtool environment rpath causes pain. This is a known bug in the current libtool, and we're working on a fix. I have already told you one (ugly) way to do it, but I still don't think it is a good idea in the general case. Didn't we decide that all of the available alternatives that you have suggested are not a feasable solution (does this mail help make it clear why)? You may have missed the ugly one I was referring to, that I suggested in the very beginning of this discussion, that would work even for packages that were distributed with older versions of libtool: configure the packages to use a gcc or ld wrapper that removes switches such as -rpath /usr/lib from the command line then call the appropriate program. This will have the extra benefit of fixing other packages that don't use libtool, but happen to specify -rpath on their own. - rpath is good because it allows a binary to have a shared library in a non-standard place without requiring the user to use LD_LIBRARYPATH or the sysadmin to add that place to the search path - rpath is bad because it disables LD_LIBRARYPATH It does not disable it, it just precedes LD_LIBRARY_PATH. AFAIK, the purpose of LD_LIBRARY_PATH is to help a program find a library that was moved, and it does fulfil this purpose as long as you don't install another (in)compatible library in place of the moved library. - rpath is bad because it disables the linkers automatic versioning mechanism Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the library search path in certain circumstances? The hack is incomplete, you just have to fix it. - rpath is bad because it prevents you from moving shared libraries around freely. It does not. It just prevents you from arbitrarily replacing a library with an (in)compatible version of it. Since you shouldn't do that, libtool is not the piece of software to be blamed for using -rpath. -- 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: -rpath with libtool and Debian Linux
On Jan 28, 1999, Bernard Dautrevaux [EMAIL PROTECTED] wrote: You say the contract is I want to find THERE the lib that does THIS.x and THAT.x; I think (and that's at least true for Linux) the contract the compiler and linker has signed was twofold; it says: 1) I will give you the library that makes THIS.x and THAT.x 2) The prefered library I want you to use to obtain THIS and THAT is there and makes THIS.x and THAT.x Now you trick it with -rpath in finding both the .x and THERE and all the problem comes from there... An analogy: When I wand to get hot water in restrooms, I just look at the tap, and turn the red one; I do not INSIST on opening the left one, risking to get cold water... Good analogy. What's happening here is that Debian is placing the red lable on the cold water tap. I.e., they're replacing a library with an incompatible version of it, and getting in trouble because some programs are now getting cold water where they expected hot water. Under Linux at least the incompatibilities we are talking here ARE managed by the dynamic linker, IFF we do not trick it saying him (using -rpath) Do not be smart, just load the library from there. YOU are breaking the Linux contract... ld.so is trying to outsmart everybody, but it is not smart enough to do it. When you moved libc5-compatible libraries from /usr/lib to /usr/lib/libc5, you established a rule that, if any program was linked with libc5, it should look for libraries in /usr/lib/libc5 first, right? Then why doesn't ld.so follow this rule, by replacing /usr/lib with /usr/lib/libc5 when it finds this directory in the rpath too? -- 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:Re: Call for mascot! :-)
On Thu, 28 Jan 1999 13:44:20 -0800, Joey Hess wrote: Objet: Re: [] la date: 28 Jan 99 22:03:11 GMT De: John Travers [EMAIL PROTECTED] A: debian-devel@lists.debian.org On Thu, 28 Jan 1999, Chris Waters wrote: 1. Dragon (well-liked choice on IRC) 2. Octopus (my own suggestion) 3. Monkey 4. Ant 5. Bee Why a dragon and not a Troll ? Bee like beos ? Octopus it is the symbol of mafia, but I dont care. It's a quit intelligent mollusque; What about a big Sponge? Lucile [EMAIL PROTECTED]
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
On Thu 28 Jan 1999, Steve Dunham wrote: BTW, There are two kinds of sparc64 support: usermode and kernel mode. Usermode stuff is a _long_ way off, currently Debian runs 32-bit sparc stuff on a 64-bit kernel. So Alpha patches don't help much there. The biggest issue on the 32-bit sparc is unaligned memory accesses. Alpha also suffers from unaligned accesses on 32-bit entities(*), so perhaps the unaligned accesses to see are also addressed (pun not intended) by the alpha patches? (*) on alpha, you can access 8-bit entities at any 8-bit aligned address (i.e. any byte anywhere). 16-bit entities need to be aligned on even addresses, 32-bit entities on (addr % 4 == 0) addresses, and 64-bit addresses must be aligned on (addr % 8 == 0) addresses. I'm guessing the same holds true for sparc(64). Paul Slootman -- home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
Re: -rpath with libtool and Debian Linux
Alexandre Oliva wrote: ld.so is trying to outsmart everybody, but it is not smart enough to do it. When you moved libc5-compatible libraries from /usr/lib to /usr/lib/libc5, you established a rule that, if any program was linked with libc5, it should look for libraries in /usr/lib/libc5 first, right? Then why doesn't ld.so follow this rule, by replacing /usr/lib with /usr/lib/libc5 when it finds this directory in the rpath too? No, that's not how it works. To the best of my understanding, it works by adding a libc5 or libc6 field to its cache. When it looks for a cached library, and it finds two entries, it picks the one with the correct libc. It always searches all of its directories. It allows -rpath and LD_LIBRARY_PATH to override this behaviour. I think that that is correct -- these _are_ overrides. They're to be used when the default behaviour gets things wrong. I think the dynamic linker could be further changed to always ignore a library that would introduce a mixed libc5/libc6 linkage. That would give the correct behaviour even with these overrides. However, that only solves the _previous_ problem, not any future ones. A general solution would require that soname be split into a library name and a major version, so that the dynamic linker can detect incompatible versions of the same library. That would be a major change. Richard Braakman
Intent to package poc.
Hi, I plan to package the Portable Object Compiler, an Objective-C compiler, for potato. Upstream source: http://sunsite.unc.edu/pub/Linux/devel/lang/objc/ Upstream Author: David Stes [EMAIL PROTECTED] Homepage: http://cage.rug.ac.be/~stes/compiler.html http://www.can.nl/~stes/compiler.html Cheers, -- Marcel Harkema - [EMAIL PROTECTED] Life's disappointments are harder to take when you don't know any swear words. --Calvin and Hobbes
Re: special boot disk
David Stern wrote: Hi, About a month ago a developer posted that he had a special boot disk image in his debian.org home directory to alleviate a hang at install time, but I can't locate the post now. I only know about www.master.debian.org/~doko/ Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists.
Re: Uploaded lilo 21-3.1 (source i386) to master [NMU]
Vincent Renardias wrote: On Mon, 25 Jan 1999, Bernd Eckenfels wrote: thanks for the NMU without asking the maintainer FIRST, AGAIN :-/// No problem, I will mail you next time. Note: the last upload of this package was last month and there is no reason for a quick uplaod since there are no critical warnings pending for FROZEN. 1/ I reported 2 years ago a bug (#7570) that could be fixed in 5 minutes and just got bored to wait. 2/ lilo also had ~10 other bugs that could be easily fixed and since lilo is such a critical part of the Debian system it should be as bugfree as possible. 3/ In march 98, Peter Maydell took the time to write nice manpages for activate(8) and keytable-lilo.pl(8). Not having taken 3 minutes to include them in 9 months is just plainly unjustified and disrespects his work. I considered these 3 points as a good reason to make an upload. In this special case where fixed packages need to be installed into the frozen distribution and time is running out, also given the easyness of fixing these bugs I have difficulties in understanding why the package maintainer got angry about an NMU even without asking him. It was his job to fix the bugs - years ago. Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists.
Re: -rpath with libtool and Debian Linux
On Jan 29, 1999, Richard Braakman [EMAIL PROTECTED] wrote: Alexandre Oliva wrote: ld.so is trying to outsmart everybody, but it is not smart enough to do it. When you moved libc5-compatible libraries from /usr/lib to /usr/lib/libc5, you established a rule that, if any program was linked with libc5, it should look for libraries in /usr/lib/libc5 first, right? Then why doesn't ld.so follow this rule, by replacing /usr/lib with /usr/lib/libc5 when it finds this directory in the rpath too? No, that's not how it works. To the best of my understanding, it works by adding a libc5 or libc6 field to its cache. When it looks for a cached library, and it finds two entries, it picks the one with the correct libc. It always searches all of its directories. It allows -rpath and LD_LIBRARY_PATH to override this behaviour. I think that that is correct -- these _are_ overrides. They're to be used when the default behaviour gets things wrong. Since -rpath is specified at program link time, and libc5 is supposed to be used only by old programs, it would be correct for ld.so to use /usr/lib/libc5 instead of /usr/lib if it finds that the program was linked with libc5. This would make the transition as transparent as possible, even for users that, inadvertently or not, have decided to use -rpath /usr/lib for their programs. -- 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: upload to slink allowed to fix missing dependency?
On 27 Jan 1999, Ardo van Rangelrooij wrote: The version in slink of the debiandoc-sgml package has an undeclared dependency on the libwww-perl package. Is it still allowed to upload a corrected version? This doesn't involve any code changes, just an extra dependency declaration in the debian/control file. If this is the only change, I think it should be allowed. (In doubt, you may contact Brian). -- 39fc57145704e94015816be53837fce5 (a truly random sig)
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
On Thu, 28 Jan 1999, Brandon Mitchell wrote: About the xfonts problem. I haven't been following close enough to pardon my ignorance on the subject. What if we make the pseudo xbase package conflict with xfnt* packages version x (a versioned conflict)? How will dselect handle this, will it upgrade the fonts to the new name? No, this would just make dselect to remove the old package. -- 118f2ff230eb1a5d9e32b19ec242f9a8 (a truly random sig)
intent to package xzx
I wish to take over the orphaned package xzx. I have notified the WNPP maintainer. I am just checking that this is OK with everyone... To dmarion: please send me any relevent files/info if it is ok. More than just email--Get your FREE Netscape WebMail account today at http://home.netscape.com/netcenter/mail
package for X11 or svgalib ??
I have just started to package spectremu, it comes in two versions for X11 and SVGAlib, should I just to X11 or both and in one or seperated packages? Also, how do I make a menu entry start a program in xterm? because spectremu for X11 must be started from xterm. More than just email--Get your FREE Netscape WebMail account today at http://home.netscape.com/netcenter/mail
¿Misuse of Debian name and logo?
I would like to draw your attention towards www.debian-cd.com, it's a vendor that distributes Debian Cd's, also providing some nice logos for use as label. I have no problem with these save... 1.- The domain name includes 'Debian' is this OK for the project? I recall a problem with a teenager registering debian.com, when Bruce was Project Leader... 2.- The redistribution of the logo complies with our own guidelines? (I dare to ask what the current status of our logo license is currently...) Best regards Javi
Re: -rpath with libtool and Debian Linux
On Fri, Jan 29, 1999 at 07:11:54AM -0200, Alexandre Oliva wrote: On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote: Therefore, we chose to solve that particular problem (the libc5-6 transition) by moving libraries around, knowing that our linker was up to the job. It is now clear that it is not. :-( It IS, as long as you don't use rpath. We don't use rpath for vendor-supplied parts of the system. The user is obviously free to use them for locally compiled stuff, and AFAIK it will behave as advertised. Yes, when Debian moves those libraries in the future, those programs will break. The user shouldn't really use rpath. But there are plenty of other ways for a user to hose their system; we really can't stop them doing it. If it worked well you wouldn't be complaining about a problem that is caused by its incomplete behavior, but that could be avoided by modifying other pieces of software that are doing their jobs correctly. Modifying libtool to remove -rpath fixes the problem at our end. The documentation for our package checker (lintian) includes two ways to do this easily. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: -rpath with libtool and Debian Linux
On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote: Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the library search path in certain circumstances? The hack is incomplete, you just have to fix it. Have you checked our ld.so source? The only mentioned of libc5-compat is documentation. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: -rpath with libtool and Debian Linux
Previously Alexandre Oliva wrote: Good analogy. What's happening here is that Debian is placing the red lable on the cold water tap. I.e., they're replacing a library with an incompatible version of it, and getting in trouble because some programs are now getting cold water where they expected hot water. No, what Debian (and RH and probably other distributions) do is exchanging the two taps, there is no messing with labels involved since the dynamic linker needs those to determine which library to use. When you moved libc5-compatible libraries from /usr/lib to /usr/lib/libc5, you established a rule that, if any program was linked with libc5, it should look for libraries in /usr/lib/libc5 first, No, what we did was making libc6 libraries the default since the linker uses stuff in /usr/lib. The dynamic linker doesn't really care about the order, it just uses the first library that it sees for will work with the appplication (ie libc5/libc6 check and soname check). But you override the dynamic linkers' safe choice by using rpath.. 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/ pgpSr9ZJxKJmZ.pgp Description: PGP signature
Re: Intent to package gbdk.
Masato Taruishi [EMAIL PROTECTED] writes: The reason for non-free is this in copyright: Permission to use, copy, modify, and distribute this software for any purpose, subject to the provisions described below, without fee is ^^^ That doesn't make it non-free. It's in the standard BSD license. It means you don't have to pay the author, not that you can't charge a fee.
Re: ¿Misuse of Debian name and logo?
On Fri, Jan 29, 1999 at 02:21:38PM +0100, Javier Fdz-Sanguino Pen~a wrote: I would like to draw your attention towards www.debian-cd.com, it's a vendor that distributes Debian Cd's, also providing some nice logos for use as label. I have no problem with these save... 1.- The domain name includes 'Debian' is this OK for the project? I recall a problem with a teenager registering debian.com, when Bruce was Project Leader... In order to protect our trademark, we'd either have to give this site permission to use the trademark and logo, or tell them to stop using the trademark and logo. I think a polite reminder of the logo guidelines and permission to use the trademark would be best for all parties involved. He's probably got enough business problems without us breathing down his neck about trademarks, licenses, and other legalese. 2.- The redistribution of the logo complies with our own guidelines? (I dare to ask what the current status of our logo license is currently...) Last I heard, it was broken. Fortunately, this doesn't prevent Debian from giving permission on a case-by-case basis. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
Branden Robinson: I don't know yet exactly how the new font and static library packages will be handled. I want to build developer consensus on a solution. I have one possible solution here: deb http://master.debian.org/~sanvila frozen main [ The above is an apt-like line ]. Yes, these are the famous dummy packages. Don't worry, I'm not uploading them to Incoming, I prefer a developer consensus too. I will not claim that this is the only possible solution, but certainly it is a solution. I would like to hear about better solutions than this (not on paper but real code). Thanks. -- e845ea08d62746a96384dad8c6d46e2e (a truly random sig)
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
On Fri, 29 Jan 1999, Santiago Vila wrote: On Thu, 28 Jan 1999, Brandon Mitchell wrote: About the xfonts problem. I haven't been following close enough to pardon my ignorance on the subject. What if we make the pseudo xbase package conflict with xfnt* packages version x (a versioned conflict)? How will dselect handle this, will it upgrade the fonts to the new name? No, this would just make dselect to remove the old package. This doesn't change the current debate, but it occurs to me that a versioned provides would solve the renaming problem. j /+---+-\ | 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: /usr/lib/apt/methods/http - close(-1)
On Fri, 29 Jan 1999, Russell Coker wrote: What is a close(-1) supposed to do? The http program does one and I'm curious as to why... IIRC, close(-1) closes all open file handles. I'm not certain exactly wher this is documented though.
What hack in ld.so?
In the thread on -rpath that is currently taking place on the debian-devel mailing list (quick summary: Debian developers say that -rpath should -not- be the default on Linux systems; libtool developers say that -rpath should be the default on all systems), Alexandre Oliva has repeatedly referred to an incomplete hack on the ld.so, either on linux systems or on Debian systems. I would appreciate it if he would explain in detail what this hack is supposed to be. From what he describes, it sounds like he thinks that the linker was modified to special-case the libc5/libc6 transition, to allow us to move old libraries that depended on libc5 into a special directory, and replace them with libraries that depended on libc6. He thinks the behavior is something like this: program foo depends on libfoo and libc6. ld.so searches /usr/lib for a compatable libfoo, and find it. It then loads /usr/lib/libfoo and /lib/libc6 into memory. program bar, on the otherhand, depends on libfoo and libc5. Instead of searching /usr/lib, ld.so recognises that bar was linked with libc5, and so special-case searches /usr/lib/libc5-compat -first-, before searching /usr/lib. Finding a libfoo in /usr/lib/libc5-compat, it links that in. It does not search /usr/lib at all then, and thus does not link in the libc6 version of libfoo This breaks in the presence of -rpath, because rpath tells it to use /usr/lib/libfoo, and that overrides the hacked special case libc5 for programs. This is not how I understand how the ld.so linker works on Linux systems. My understanding is that it caches the locations of all known versions of the libraries, and makes an intelligent decision as to which version to load. I think that it handles foo and bar above like so: program foo depends on libfoo and libc6. ld.so checks its cache, and finds /usr/lib/libfoo (which in turn depends on libc6), and /usr/lib/libc5-compat/libfoo (which in turn depends on libc5). Faced with both possible libraries, it decides that loading /usr/lib/libfoo is a better choice than /usr/lib/libc5-compat/libfoo. I'm not sure offhand why it decides so -- does it know that libc5 and libc6 are incompatable versions of the same library (different sonames), or does it feel that loading two libraries (libfoo, libc6) is better than loading three (libfoo, libc5, libc6). program bar, on the otherhand, depends on libfoo and libc5. again, ld.so checks its cache, and again finds /usr/lib/libfoo and /usr/lib/libc5-compat/libfoo, Faced with a similar decision as last time, it again chooses, this time feeling /usr/lib/libc5-compat/libfoo is a better choice. This breaks in the presense of -rpath, because with rpath, bar is not dependent on libfoo, but on /usr/lib/libfoo. -- Buddha Buck [EMAIL PROTECTED] Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects. -- A.L.A. v. U.S. Dept. of Justice
Re: Intent to package xfntbase, xfnt75, etc.
On Wed, 27 Jan 1999, Branden Robinson wrote: On Wed, Jan 27, 1999 at 08:01:28PM +0100, Santiago Vila wrote: I intend to package all the dummy packages we have been talking about. They match the packages that changed its name in the great X reorganization. You'll do no such thing or I will take drastic measures. Those packages are MINE. If the dummy packages are going to be created, it's going to be me who does it. It only makes sense, since I am more familiar with the X packages than you are. Branden, please calm down. I hope we will agree at least that I don't have to ask for permission to create packages as long as I don't upload them to Incoming. They are available here: deb http://master.debian.org/~sanvila frozen main For these packages to be created, I did not need any familiarity with the X packages, I just needed to know how did they change its names, and this has been publicised widely. BTW: Since you claim your ownership over these packages (funny: the same packages you first said they should not exist) I have put your name in the Maintainer field. They are effectively yours, *iff* you want to maintain them. [...] * (From Branden Robinson) Ok, don't worry, I think I should be the one to do it, since I'm the X maintainer. Barring a better solution, I will be the one to do this. The xbase dummy package is already implemented in my current build tree and it makes sense for these all to be generated from the same source package. On the contrary, I think that generating the dummy packages from another source package will make the ordinary X packages to be much cleaner. But this is only my opinion, I don't care much about this. * You should not create them because they are useless. Not true, since lot of people expect the old packages to be upgraded by the new ones automatically, these packages are exactly which is needed (with existing tools) so that the upgrade is done automatically. Non sequitur. The packages *are* useless in a purely functional sense, i.e., they are not ends in themselves, nor a means to anything but overcoming limitations in the packaging system. Fine, let's agree that they exist to overcome limitations in the packaging system. So what? Is there something wrong in overcoming limitations in the packaging system? I think there should not be anything wrong with this. * Don't do it, they are ugly. Having an ugly thing does not mean it may not be useful as well. Functionality is more important than aesthetics. The problem is ugly. So is your solution. I will concede that there may not be a pretty solution short of adding a feature to the packaging system. It does not follow that your proposal is the best of all possible solutions. I will not claim that my proposal is the best one, but I hope you will let me to think it is until I see a better one. * There should be some better way. Fine. Which one? Is there a way to have a dpkg --set-selections call lurk in the background until the current dpkg process ends, like update-menus does now? That would be a far cleaner solution. [...] But then you would probably have to execute [I]nstall twice. I don't see this would be cleaner. -- 3d8b182588d86af3b97502c3448fa24f (a truly random sig)
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
On Fri, 29 Jan 1999, Jules Bean wrote: On Fri, 29 Jan 1999, Santiago Vila wrote: On Thu, 28 Jan 1999, Brandon Mitchell wrote: About the xfonts problem. I haven't been following close enough to pardon my ignorance on the subject. What if we make the pseudo xbase package conflict with xfnt* packages version x (a versioned conflict)? How will dselect handle this, will it upgrade the fonts to the new name? No, this would just make dselect to remove the old package. This doesn't change the current debate, but it occurs to me that a versioned provides would solve the renaming problem. AFAIK, there is no such thing as versioned provides. -- 0a263ffbe215ba0de596b742f184c47b (a truly random sig)
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
On Fri, 29 Jan 1999, Santiago Vila wrote: On Fri, 29 Jan 1999, Jules Bean wrote: On Fri, 29 Jan 1999, Santiago Vila wrote: On Thu, 28 Jan 1999, Brandon Mitchell wrote: About the xfonts problem. I haven't been following close enough to pardon my ignorance on the subject. What if we make the pseudo xbase package conflict with xfnt* packages version x (a versioned conflict)? How will dselect handle this, will it upgrade the fonts to the new name? No, this would just make dselect to remove the old package. This doesn't change the current debate, but it occurs to me that a versioned provides would solve the renaming problem. AFAIK, there is no such thing as versioned provides. Dpkg doesn't support them, no. I'm sure you knew what I meant as an abstract concept, though ;) It has been often discussed to implement them. I am merely observing (unhelpfully) that they would solve this problem too. J /+---+-\ | 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. | \--/
2.1.125 source in slink - why?
dists/slink/main/binary-all/kernel-source-2.1.125 why?? and 2.0.33, 2.0.34, 2.0.35 2.0.36 I can understand :-) Cheers Adrian Adrian Bridgett [EMAIL PROTECTED] Internal: 7-245528 External: 01962-815528
Re: /usr/lib/apt/methods/http - close(-1)
On Fri, 29 Jan 1999, Scott K. Ellis wrote: On Fri, 29 Jan 1999, Russell Coker wrote: What is a close(-1) supposed to do? The http program does one and I'm curious as to why... IIRC, close(-1) closes all open file handles. I'm not certain exactly wher this is documented though. It really doesn't seem to be doing so on Linux 2.2.0. Surely if it was closing file descriptors then it would return 0... Here's a grep of my output from the stracing of dselect I did earlier: /tmp/out.24701:close(-1) = -1 EBADF (Bad file descriptor) /tmp/out.24702:close(-1) = -1 EBADF (Bad file descriptor) /tmp/out.24702:close(-1) = -1 EBADF (Bad file descriptor) /tmp/out.24702:close(-1) = -1 EBADF (Bad file descriptor) /tmp/out.24703:close(-1) = -1 EBADF (Bad file descriptor) /tmp/out.24704:close(-1) = -1 EBADF (Bad file descriptor) -- I am in London and would like to meet any Linux users here. I plan to work in London for 6 months and then I might move to some other place where the pay is good.
Re: Intent to package gbdk.
At 29 Jan 1999 08:48:54 -0500, Ben Pfaff [EMAIL PROTECTED] wrote: Permission to use, copy, modify, and distribute this software for any purpose, subject to the provisions described below, without fee is ^^^ That doesn't make it non-free. It's in the standard BSD license. It means you don't have to pay the author, not that you can't charge a fee. That is the wrong quotation to show this is non-free (^^; GBDK is free for non-commercial use: lcc is available free for your personal research and instructional use under the `fair use' provisions of the copyright law. You may, however, redistribute lcc in whole or in part provided you acknowledge its source and include this CPYRIGHT file. You may, for example, include the distribution in a CDROM of free software, provided you charge only for the media, or mirror the distribution files at your site. Masato Taruishi [EMAIL PROTECTED] | University of Electro Comunications [EMAIL PROTECTED] | Department of Computer Science [EMAIL PROTECTED] | Junior http://www.sunicom.co.jp/~taruisma/ | Chofu city Tokyo, JAPAN Key fingerprint = 49 46 74 E1 8D D1 EB 56 8D CA 2A 20 14 9E A9 25
Re: Intent to package gbdk.
The reason for non-free is this in copyright: Permission to use, copy, modify, and distribute this software for any purpose, subject to the provisions described below, without fee is ^^^ Have you contacted the author about this? This can be read as You are forbidden to charge a fee for copies or as I do not require that you pay me a fee for copying. The author may intend the latter. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Packages I am orphaning.
Joel Klecker wrote: pciutils - Utils for listing/tweaking PCI devices in 2.1/2.2 kernels Bug-free, lintian-clean There are some upstream alpha releases that would be nice to have packaged somewhere, but not essential If noone objects, I'll take this (I'm using it quite often my self within the context of an ongoing research project). I'll create packages of the alpha (prerelease) versions too. Kind regards, -Remco
Re: package for X11 or svgalib ??
On Fri, Jan 29, 1999 at 01:01:47PM +, John Travers wrote: I have just started to package spectremu, it comes in two versions for X11 and SVGAlib, should I just to X11 or both and in one or seperated packages? They should be in seperate packages. Also, how do I make a menu entry start a program in xterm? because spectremu for X11 must be started from xterm. Just do it like any other thing xterm -e someprog /--\ |Stephen Crowley [EMAIL PROTECTED], [EMAIL PROTECTED] | |Debian GNU/Linux http://www.debian.org| |GPG Key http://va.debain.org/~crow/public.key| \--- 8A8B 3B82 6EA7 CF4E 01A5 5B21 B378 981D D2E1 0D85 ---/
Re: 2.1.125 source in slink - why?
On Fri, 29 Jan 1999, Adrian Bridgett wrote: dists/slink/main/binary-all/kernel-source-2.1.125 why?? and 2.0.33, 2.0.34, 2.0.35 2.0.36 I can understand :-) 2.1.125 - because we needed it for sparc, so we uploaded the source. 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. | \--/
Debian network consultant desired in MA
Hi folks, I hope this is an appropriate message to send to this list. I'm searching for an consultant to help us configure a mixed environment of Debian, Solaris and NT. The work will involve setting up file sharing, password synchronization, third party package installation, printer configuration, backup configuration, firewall configuration. Many/most of the services are provided by Debian servers. The difficult part is configuring NT to support network installs of packages and cooperation with UNIX. I estimate 2-3 weeks of work on-site in Cambridge MA with possiblity of long-term support. Anyone interested should email me directly. Thanks, -- Jean Pierre LeJacq CTO Quoin Inc 1208 MASSACHUSETTS AVE STE 3 CAMBRIDGE MA 02138 voice: 617.492.6461 fax: 617.492.6861 email: [EMAIL PROTECTED]
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
The patches that I sent you should be completely safe. But the resulting packages have only been tested by me. (As I said, I took out the -pedantic flag on the altdev stuff - the other changes don't touch x86 at all.) Right, at least my sparc patches really only deal with the Xsun server. I guess yours are similar. BTW, There are two kinds of sparc64 support: usermode and kernel mode. Usermode stuff is a _long_ way off, currently Debian runs 32-bit sparc stuff on a 64-bit kernel. So Alpha patches don't help much there. The biggest issue on the 32-bit sparc is unaligned memory accesses. Hmm, the alpha patches clean up many unaligned accesses, and since the alignment requirements for the alpha are the same as for sparc (save 64bit alignment on 32bit sparcs) the alpha patches should fix this too. I've been planning to merge the patch sets (I do the alpha X packages too), just haven't gotten to it yet (and I was sort of waiting to see if the central CVS archive that was suggested was going to happen). Maybe this is a good time... I don't really want to step on any feet here, but it would be nice if we could get the X source for Sparc into slink - and get the UltraSparc support in there. (Eric plans on making the install work, so X support would be an added bonus.) Nontheless, the current sparc binaries are a built by Anders from a seperate tree. (Anders - my tree was made by merging the latest UltraPenguin patches - a superset of the Red Hat patches - into Branden's tree.) I would want some other sparc people to double check my packages, before we actually include binary packages from my code into slink. Can you send me your patches? I suspect that a lot of them are the same (and they aren't really mine, Mike Shuey did most of the original work on them), since they too are based on Red Hat's. That way I can merge them (or I could send you mine and let you do the merging, either is fine by me). Mainly what I want to achieve is that we don't change the way Xsun work (i.e. where it finds screens and such. It has been changing a bit, and I think I have a good method now). If Anders has a tree that matches Branden's recent trees, I'll defer to him (but ask that either he or I merge in the Mach64 and Creator patches), otherwise, I'd like to the goahead from Anders et al to use my stuff in slink (after appropriate testing). My sparc tree is currently too out-of-date to really be considered matching Branden's tree. My only concern with switching entirely is that we may loose fixes that are in my tree but not in yours, thus I'd rather try and merge our patches. It shouldn't matter too much (as long as the binaries work), since I believe Anders is planning on starting from scratch on the 3.3.3.x releases. That's the idea, yes, since much of the code should be in 3.3.3.x already. (I'm 99% sure the binaries work, the only issues would be install script c, and they are mostly copied from the current binary packages. Also, I have to add a hard-coded XF86Config to the Sparc Mach64 package - because XF86Setup doesn't work yet on the sparc machines.) What problems does XF86Setup have on the ultras? I plan on fixing it to work on the alpha (where the problem mainly consists of non-existance of xserver-vga16, xserver-mono works, though probably not on TGA). Regards, /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student | Hem: +46 31 47 69 27 Chalmers University of Technology, G|teborg, Sweden | Mob: +46 707 27 86 87
Re: gnuserv/gnuclient problem
On Fri, January 29 1999, Ionutz Borcoman [EMAIL PROTECTED] wro te: |Hi, | |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions |from potato I am no more able to start a gnuclient :-( Is anybody else |experiencing this ? I've reported this bug with slink months ago with no response. I still can't use gnuclient with xemacs under slink. --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: 2.1.125 source in slink - why?
On Fri, Jan 29, 1999 at 04:28:54PM +, Jules Bean wrote: On Fri, 29 Jan 1999, Adrian Bridgett wrote: dists/slink/main/binary-all/kernel-source-2.1.125 why?? and 2.0.33, 2.0.34, 2.0.35 2.0.36 I can understand :-) 2.1.125 - because we needed it for sparc, so we uploaded the source. powerpc, actually. I take full responsibility. It's going to go away shortly, assuming 2.2.0 powerpc packages work OK. Dan /\ /\ | Daniel Jacobowitz|__| CMU, CS class of 2002 | | Debian GNU/Linux Developer__ Part-Time Systems Programmer | | [EMAIL PROTECTED] | |[EMAIL PROTECTED] | \/ \/
Re: Intent to package gbdk.
Ben Pfaff writes: That doesn't make it non-free. It's in the standard BSD license. The word 'fee' does not occur in the standard BSD license. It does not mention money at all. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: ¿Misuse of Debian name and logo?
On 29-Jan-99 Brian Ristuccia wrote: In order to protect our trademark, we'd either have to give this site permission to use the trademark and logo, or tell them to stop using the trademark and logo. I think a polite reminder of the logo guidelines and permission to use the trademark would be best for all parties involved. He's probably got enough business problems without us breathing down his neck about trademarks, licenses, and other legalese. To make it official, I'd request atleast one link somewhere appropriate for his set up to the (even if it is broken) license. -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = pgppFpfF8uSEu.pgp Description: PGP signature
Re: ¿Misuse of Debian name and logo?
On Fri, Jan 29, 1999 at 09:51:51AM -0800, Darren Benham wrote: On 29-Jan-99 Brian Ristuccia wrote: In order to protect our trademark, we'd either have to give this site permission to use the trademark and logo, or tell them to stop using the trademark and logo. I think a polite reminder of the logo guidelines and permission to use the trademark would be best for all parties involved. He's probably got enough business problems without us breathing down his neck about trademarks, licenses, and other legalese. To make it official, I'd request atleast one link somewhere appropriate for his set up to the (even if it is broken) license. Yeah, after looking at the site, this guy is doing great things. We really don't want to do something as stupid as just saying don't use the logo like that. Ben (who wants one of those retail box set's when they are done ;) -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: ¿Misuse of Debian name and logo?
On 29-Jan-99 Ben Collins wrote: Yeah, after looking at the site, this guy is doing great things. We really don't want to do something as stupid as just saying don't use the logo like that. Ben (who wants one of those retail box set's when they are done ;) -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = pgp6jQOIENV8u.pgp Description: PGP signature
Re: ¿Misuse of Debian name and logo?
We can ask the new project leader to issue the permission and ask for the link when the election is through ;) On 29-Jan-99 Ben Collins wrote: On Fri, Jan 29, 1999 at 09:51:51AM -0800, Darren Benham wrote: On 29-Jan-99 Brian Ristuccia wrote: In order to protect our trademark, we'd either have to give this site permission to use the trademark and logo, or tell them to stop using the trademark and logo. I think a polite reminder of the logo guidelines and permission to use the trademark would be best for all parties involved. He's probably got enough business problems without us breathing down his neck about trademarks, licenses, and other legalese. To make it official, I'd request atleast one link somewhere appropriate for his set up to the (even if it is broken) license. Yeah, after looking at the site, this guy is doing great things. We really don't want to do something as stupid as just saying don't use the logo like that. Ben (who wants one of those retail box set's when they are done ;) -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = pgpnc9y4Nt8Uw.pgp Description: PGP signature
i18n'g the Debian Menu System
Hello all, This is a internationalization proposal for the Debian Menu System. The current 'update-menus' method seek /usr/lib/menu/default, /usr/lib/menu and /etc/menu for the package's menu entries. A first approach may be: 1. Check the LANG or LC_ALL var 2. If it's different than 'C', 'uk' or 'en*' then add the
i18n'g the Debian Menu System
Hello all, This is a internationalization proposal for the Debian Menu System. The current 'update-menus' method seek /usr/lib/menu/default, /usr/lib/menu and /etc/menu for the package's menu entries. A first approach may be: 1. Check the LANG or LC_ALL var 2. If it's different than 'C', 'uk' or 'en*' then add the
i18n'g the Debian Menu System
Hello all, This is a internationalization proposal for the Debian Menu System. The current 'update-menus' method seek /usr/lib/menu/default, /usr/lib/menu and /etc/menu for the package's menu entries. A first approach may be: 1. Check the LANG or LC_ALL var 2. If it's different than 'C', 'uk' or 'en*' then add the
i18n'g the Debian Menu System
Hello all, This is a internationalization proposal for the Debian Menu System. The current 'update-menus' method seek /usr/lib/menu/default, /usr/lib/menu and /etc/menu for the package's menu entries. A first approach may be: 1. Check the LANG or LC_ALL var 2. If it's different than 'C', 'uk' or 'en*' then add the
i18n'g the Debian Menu System
Hello all, This is a internationalization proposal for the Debian Menu System. The current 'update-menus' method seek /usr/lib/menu/default, /usr/lib/menu and /etc/menu for the package's menu entries. A first approach may be: 1. Check the LANG or LC_ALL var 2. If it's different than 'C', 'uk' or 'en*' then add the
i18n-ing the Debian Menu System
Hello all, This is a internationalization proposal for the Debian Menu System. The current 'update-menus' method seek /usr/lib/menu/default, /usr/lib/menu and /etc/menu for the package's menu entries. A first approach may be: 1. Check the LANG or LC_ALL var 2. If it's different than 'C', 'uk' or 'en*' then add the
i18n'g the Debian Menu System
Hello all, This is a internationalization proposal for the Debian Menu System. The current 'update-menus' method seek /usr/lib/menu/default, /usr/lib/menu and /etc/menu for the package's menu entries. A first approach may be: 1. Check the LANG or LC_ALL var 2. If it's different than 'C', 'uk' or 'en*' then add the `/usr/lib/menu/$LANG' path to the seek (if the dir exists). The update-menus program must override the menu files provide in /usr/lib/menu/default and /usr/lib/menu to allow the local menu file be the authorative menu file. Then, we will find in /usr/lib/menu a similar structure as /usr/share/locale has. Later, may be it will be moved to /usr/share/menu (as the update-menus check the packages installed in the machine, there will be no problem sharing /usr/share between machines with diferent packages installed). For the maitainers, this model implies have diferent menu files in theirs packages (just a bit diferent). Something like this: /usr/lib/menu/gimp : ?package(gimp):command=/usr/X11R6/bin/gimp icon=none needs=X11 \ section=Apps/Graphics title=The GIMP /usr/lib/menu/es_ES/gimp : ?package(gimp):command=/usr/X11R6/bin/gimp icon=none needs=X11 \ section=Apliaciones/Gráficos title=El GIMP Well, it's just a simple proposal. Comments are welcome. -- Tinguaro Barreno Delgado [EMAIL PROTECTED]
Re: /usr/lib/apt/methods/http - close(-1)
On Fri, 29 Jan 1999, Russell Coker wrote: What is a close(-1) supposed to do? The http program does one and I'm curious as to why... Absolutely nothing : -1 is defined to be an invalid FD and close(-1) is to return an error code and basically do nothing when given -1 Jason
Re: ¿Misuse of Debian name and logo?
On Fri, Jan 29, 1999 at 09:51:51AM -0800, Darren Benham wrote: To make it official, I'd request atleast one link somewhere appropriate for his set up to the (even if it is broken) license. Ben Collins [EMAIL PROTECTED] wrote: Yeah, after looking at the site, this guy is doing great things. We really don't want to do something as stupid as just saying don't use the logo like that. We should probably also indicate we (or at least some of us) approve of __ [whatever it is he's doing that's great]. A carefully worded statement, which has no warmth, might be taken wrong [I seem to manage to make this mistake a bit too often]. -- Raul
RE: i18n'g the Debian Menu System
Good idea, needs a better solution. Sorry, but I do not speak Spanish, so have no idea what the menu file should be for you. You will also bloat each and every menu package which 20 menus. Better to use the menu systems builtin translation ability and supply i18n support to it. BTW, Tinguaro I recieved about 8 bad copies of this e-mail, please fix your mailer or something.
Re: Intent to package gbdk.
There have been several packages allowed into main with a license like this. Some people don't like it however. Perl's license is even slightly more restricive. Except that now it can be licensed under the GPL as well. From: John Lapeyre [EMAIL PROTECTED] Date: 29 Jan 1999 12:44:51 -0700 In-Reply-To: Masato Taruishi's message of Sat, 30 Jan 1999 00:21:22 +0900 Message-ID: [EMAIL PROTECTED] Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.3 Masato Taruishi [EMAIL PROTECTED] writes: At 29 Jan 1999 08:48:54 -0500, Ben Pfaff [EMAIL PROTECTED] wrote: Permission to use, copy, modify, and distribute this software for any purpose, subject to the provisions described below, without fee is ^^^ That doesn't make it non-free. It's in the standard BSD license. It means you don't have to pay the author, not that you can't charge a fee. That is the wrong quotation to show this is non-free (^^; GBDK is free for non-commercial use: lcc is available free for your personal research and instructional use under the `fair use' provisions of the copyright law. You may, however, redistribute lcc in whole or in part provided you acknowledge its source and include this CPYRIGHT file. You may, for example, include the distribution in a CDROM of free software, provided you charge only for the media, or mirror the distribution files at your site. -- John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: -rpath with libtool and Debian Linux
On 29 Jan 1999, Alexandre Oliva wrote: Didn't we decide that all of the available alternatives that you have suggested are not a feasable solution (does this mail help make it clear why)? You may have missed the ugly one I was referring to, that I suggested in the very beginning of this discussion, that would work even for packages that were distributed with older versions of libtool: configure the packages to use a gcc or ld wrapper that removes switches such as -rpath /usr/lib from the command line then call the appropriate program. So you agree that we should be able to choose to disable rpath but you feel that we should do extra work to advoid it for libtool because it does not fit your beliefs of how shared libraries work? What about other dists that do the same thing? We are not the only linux dist to use this scheme! This will have the extra benefit of fixing other packages that don't use libtool, but happen to specify -rpath on their own. Actually virtually every other package we would just hand edit the makefiles, libtool kinda makes that impossible. - rpath is good because it allows a biary to have a shared library in a non-standard place without requiring the user to use LD_LIBRARYPATH or the sysadmin to add that place to the search path - rpath is bad because it disables LD_LIBRARYPATH It does not disable it, it just precedes LD_LIBRARY_PATH. AFAIK, the purpose of LD_LIBRARY_PATH is to help a program find a library that was moved, and it does fulfil this purpose as long as you don't install another (in)compatible library in place of the moved library. It prevents you from using LD_LIBRARY_PATH to superceed the default location of libraries, which is partially what it does - rpath prevents library searching and thus kills this functionality. - rpath is bad because it disables the linkers automatic versioning mechanism Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the library search path in certain circumstances? The hack is incomplete, you just have to fix it. See the other messages - it is not a hack and it is not horribly incomplete. Jason
Re: /usr/lib/apt/methods/http - close(-1)
Scott == Scott K Ellis [EMAIL PROTECTED] writes: Scott On Fri, 29 Jan 1999, Russell Coker wrote: What is a close(-1) supposed to do? The http program does one and I'm curious as to why... Scott IIRC, close(-1) closes all open file handles. I'm not Scott certain exactly wher this is documented though. Actually, it shouldn't do anything. What's most likely is the source has multiple code paths after the opening of some file descriptor rather than do error checking in each code path, the programmer elected to to close the file descriptor just prior to exiting that block of code. When the open fails for hatever reason, the return code from open/socket/whatever is -1. IOW, close (-1) is an ignorable non-op (unless, of course, you were trying to get to the previous value of errno :)) -- Stephen --- It should be illegal to yell Y2K in a crowded economy. :-) -- Larry Wall
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
Anders Hammarquist [EMAIL PROTECTED] writes: The patches that I sent you should be completely safe. But the resulting packages have only been tested by me. (As I said, I took out the -pedantic flag on the altdev stuff - the other changes don't touch x86 at all.) Right, at least my sparc patches really only deal with the Xsun server. I guess yours are similar. And the stuff in the debian dir. I also found that I had to use a hack to remove the -pedantic line from the configuration files to get the altdev stuff to compile: diff -ruN xfree86-3.3.2.3a-8pre9v1/debian/rules xfree86-3.3.2.3a/debian/rules --- xfree86-3.3.2.3a-8pre9v1/debian/rules Tue Dec 29 15:35:58 1998 +++ xfree86-3.3.2.3a/debian/rules Mon Dec 28 22:09:18 1998 @@ -8,7 +8,7 @@ DEBTREEDIR5:=$(shell pwd)/debian/xtree-libc5 # if your arch needs glibc1 compat support build, add it to this list -COMPAT_ARCHS=i486 m68k +COMPAT_ARCHS=i486 m68k sparc A:=$(shell dpkg --print-gnu-build-architecture) ifneq (,$(findstring $(A), $(COMPAT_ARCHS))) @@ -43,6 +43,7 @@ build-old: $(checkdir) mkdir $(L5) cp -a include config lib Makefile $(L5)/ + perl -pi -e 's/-pedantic//' $(L5)/config/cf/xfree86.cf cp -a debian/Imakefile.l5 $(L5)/Imakefile sed s/@ARCH@/$(A)/ debian/site.def.l5.in $(L5)/config/cf/site.def mkdir -p $(L5)/programs/Xserver If it doesn't compile for you, add this hack. I doesn't hurt anything. (The pedantic compiler doesn't like the sparc altdev header files.) BTW, There are two kinds of sparc64 support: usermode and kernel mode. Usermode stuff is a _long_ way off, currently Debian runs 32-bit sparc stuff on a 64-bit kernel. So Alpha patches don't help much there. The biggest issue on the 32-bit sparc is unaligned memory accesses. Hmm, the alpha patches clean up many unaligned accesses, and since the alignment requirements for the alpha are the same as for sparc (save 64bit alignment on 32bit sparcs) the alpha patches should fix this too. I've been planning to merge the patch sets (I do the alpha X packages too), just haven't gotten to it yet (and I was sort of waiting to see if the central CVS archive that was suggested was going to happen). Maybe this is a good time... I would assume that these patches will conflict then (because Alpha would do #ifdef __alpha__ and sparc would do #ifdef __sparc__), but they should be easy to fix. Can you send me your patches? I suspect that a lot of them are the same (and they aren't really mine, Mike Shuey did most of the original work on them), since they too are based on Red Hat's. That way I can merge them (or I could send you mine and let you do the merging, either is fine by me). Mainly what I want to achieve is that we don't change the way Xsun work (i.e. where it finds screens and such. It has been changing a bit, and I think I have a good method now). A lot of them are the same. My latest patches against Branden's source are at: ftp://www.cse.msu.edu/pub/debian/X/xfree86.sparc.diff.gz There is also a split.pl which splits the patch into many files (one per target file). I don't know how helpful it would be, but it's there if you want it. (You can use cat and shell globbing to put the pieces back together. In particular, you might want to seperate out the patches to the debian directory.) These patches are against the xfree86-3.3.2.3a-8pre9v1 tree with Brandens patches already applied. If Anders has a tree that matches Branden's recent trees, I'll defer to him (but ask that either he or I merge in the Mach64 and Creator patches), otherwise, I'd like to the goahead from Anders et al to use my stuff in slink (after appropriate testing). My sparc tree is currently too out-of-date to really be considered matching Branden's tree. My only concern with switching entirely is that we may loose fixes that are in my tree but not in yours, thus I'd rather try and merge our patches. Ok, the only big issue is that you'll probably have to update your stuff in the Debian directory. Also, to handle my stuff, you will need to add the XF86_Mach64 server to the list of packages generated for the sparc. (There is a XF86_VGA16 server too, but it doesn't seem to work, so I'm not packaging it.) Also, make sure the patch at cfb8line.c:898 gets applied, it's not in RedHat's stuff (my own patch) and fixes a bus error in 16bit mode which is triggered by WindowMaker. It shouldn't matter too much (as long as the binaries work), since I believe Anders is planning on starting from scratch on the 3.3.3.x releases. That's the idea, yes, since much of the code should be in 3.3.3.x already. AFAIK, the sparc stuff hasn't been merged in yet, but it will eventually be merged in. (I'm 99% sure the binaries work, the only issues would be install script c, and they are mostly copied from the current binary packages. Also, I have to add a hard-coded XF86Config to the Sparc Mach64
Re: /usr/lib/apt/methods/http - close(-1)
On 29 Jan 1999, Stephen Zander wrote: Scott == Scott K Ellis [EMAIL PROTECTED] writes: Scott On Fri, 29 Jan 1999, Russell Coker wrote: What is a close(-1) supposed to do? The http program does one and I'm curious as to why... Scott IIRC, close(-1) closes all open file handles. I'm not Scott certain exactly wher this is documented though. Actually, it shouldn't do anything. What's most likely is the source has multiple code paths after the opening of some file descriptor rather than do error checking in each code path, the programmer elected to to close the file descriptor just prior to exiting that block of code. When the open fails for hatever reason, the return code from open/socket/whatever is -1. IOW, close (-1) is an ignorable non-op (unless, of course, you were trying to get to the previous value of errno :)) Okay, so I didn't recall correctly :)
LyX copyright
I just learned that the LyX copyright file was corrected to explicitely state that linking against a non-free library is okay. This however wasn't really needed as 'The law is quite clear that the release of the software by the original authors and copyright holders changed the licenses.' AFAIK the new file was written by a lawyer. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
RE: LyX copyright
On 29-Jan-99 Michael Meskes wrote: I just learned that the LyX copyright file was corrected to explicitely state that linking against a non-free library is okay. This however wasn't really needed as 'The law is quite clear that the release of the software by the original authors and copyright holders changed the licenses.' AFAIK the new file was written by a lawyer. That allows it to live in contrib -- woopie. Until they have a non forms based GUI, it matters little.
Re: Gnome-apt debs now available
*-Mitch Blevins [EMAIL PROTECTED] | | plug level=blatant | | Who says package management can't be Sexy? | Be the first one on your block to try Gnome-apt, the new | GUI front end for the Debian package tool. | | It slices... it dices... it makes fresh pasta... | and it has a groovy search function! | | /plug Ah, it's lovely. No more dselect for this boy. Feature request: Shouldn't it be possible to put a package on hold even if the newest version is installed? -- Eschew obfuscation(go on; look them both up) (Brian White) [EMAIL PROTECTED] [-: .elOle. :-] [EMAIL PROTECTED]
Re: Gnome-apt debs now available
*-Mitch Blevins [EMAIL PROTECTED] | | plug level=blatant | | Who says package management can't be Sexy? | Be the first one on your block to try Gnome-apt, the new | GUI front end for the Debian package tool. | | It slices... it dices... it makes fresh pasta... | and it has a groovy search function! | | /plug Ah, but you forgot to mention the most attractive feature of them all: It even counts the packages downloaded in hex! -- Eschew obfuscation(go on; look them both up) (Brian White) [EMAIL PROTECTED] [-: .elOle. :-] [EMAIL PROTECTED]
Re: -rpath with libtool and Debian Linux
Hi! [Creaaak... Gordon pops out of the grave reserved for former libtool maintainers to make some comments.] Alexandre Oliva writes: I don't understand this comment. Which trouble with --rpath do you mean? AO The exact problem the Debian developers have been complaining AO about. The more I think about the problem, the more I see that AO the problem they're facing is an incomplete hack of ld.so, in AO that it modifies the library search path under certain AO circumstances, but not in all circumstances that would need it. Exactly. This means, the package can provide a default, which can be overridden at compilation time. Finally, the installer can override both. AO That's exactly what I'm looking for. But I wouldn't like to AO install a quick hack now that would later reveal to be a step in AO the wrong direction. That's why I'm being so conservative about AO all this issue. For the record, Alexandre's conservativeness is well-justified. Debian maintainers should feel free to patch individual Debian packages, but fixing this problem upstream is a lot harder than it appears at first glance. The best solution I can come up with is to *always* change a library's soname when its dependencies change. I believe it was Joel Klecker who mentioned something about `libapi' patches for egcs that were supposed to implement this automatically. Joel, can you comment on this (or somebody else who knows the details)? -- 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.]
Re: Gnome-apt debs now available
On 29 Jan 1999, Ole J. Tetlie wrote: Ah, it's lovely. No more dselect for this boy. Feature request: Shouldn't it be possible to put a package on hold even if the newest version is installed? This is causing much confusion - Keep is not Hold. Right now there's no Hold feature at all. (There should be, it just isn't implemented yet.) Here's the difference: Delete/Keep/Install is what will actually be done with the package if you choose Complete Run. Unlike Hold, these flags are not persistent across sessions. So everything is Keep by default. If you Mark Upgrade, many Keep will become install; if Hold is implemented, a held package will remain Kept when you Mark Upgrade. That's what Hold means, essentially. The Delete/Keep/Install relationship is sort of confusing; many people have suggested using radio buttons instead and I'll probably do that. Havoc
Re: cron has gone to UTC time?
On Wed, Jan 27, 1999 at 09:16:23PM -0600, Steve Greenland wrote:
On 27-Jan-99, 16:54 (CST), Douglas Bates [EMAIL PROTECTED] wrote:
On a slink machine I have a crontab entry that should perform an rsync
of a site that I mirror around 22:40 my time (-0600). I have started to
get the reports from the job a little after 16:40 my time which just
happens to be 22:40 UTC.
[...deleted...]
The other interesting thing would be a list of the packages you have
newly installed or upgraded recently -- Jason Gunthorpe thinks there may
be a relationship. Anything you can think of would be a help...
Assuming, of course, that the machine involved can be used in this way.
If it can't be done, no problem, but if you see it again, please do as
much as the above as you can before you restart cron.
debian-devel folks: if any of you see similar behaviour in cron, and if
you have the time, please try the above experiment.
i've noticed this behaviour in the past, when xntp gets upgraded in the
same dselect run as cron or sysklogd.
what usually happens is that cron and/or sysklogd start running in UTC
time. I think (guess) this happens because cron and syslogd are both
restarted before xntp is restarted.
it happened to me yesterday when i upgraded from xntp3 to the new ntp 4
package.
easily fixed with /etc/init.d/{cron,syslogd} stop, followed by start.
craig
--
craig sanders
Re: gnuserv/gnuclient problem
Amos Shapira [EMAIL PROTECTED] writes: On Fri, January 29 1999, Ionutz Borcoman [EMAIL PROTECTED] wro te: |Hi, | |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions |from potato I am no more able to start a gnuclient :-( Is anybody else |experiencing this ? I've reported this bug with slink months ago with no response. I still can't use gnuclient with xemacs under slink. There is definitely something wrong with it. I'm not sure where the exact problem lies, but it is trying to run: /usr/lib/xemacs-20.4/sparc-debian-linux, Mule/gnuserv rather than: /usr/lib/xemacs-20.4/sparc-debian-linux/gnuserv I _think_ the problem lies in the elisp files, but I'm not sure.. Steve [EMAIL PROTECTED]
Re: cron has gone to UTC time?
Craig Sanders wrote: i've noticed this behaviour in the past, when xntp gets upgraded in the same dselect run as cron or sysklogd. I doubt this is it because I've experienced the problem on 2 machines; neither runs xntpd or any other time synchronization program. -- see shy jo
Re: -rpath with libtool and Debian Linux
Hamish Moffatt [EMAIL PROTECTED] writes: On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote: Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the library search path in certain circumstances? The hack is incomplete, you just have to fix it. Have you checked our ld.so source? The only mentioned of libc5-compat is documentation. It's a magic hack. Somehow (according to Alexandre) it magically adds /usr/lib/libc5 to the path, even though libc5 occurs nowhere in the binary. (go figure.) Maybe we should just agree that libtool is broken, that it won't be fixed upstream, and just fix the Debian version? This would mean that we would have to rerun autoconf co when we build packages - but it beats arguing with this guy till the end of time. Steve [EMAIL PROTECTED]
Re: dpkg port to HP-UX
Wonderful. Next question--will there be an attempt to make a standard location for distributing packages for any of this ports? It may not belong as part of Debian, but I can see advantages to Debian being associated with dependable distributions of free software for many operating systems. Guy Maor [EMAIL PROTECTED] writes: Believe it or not, I've ported dpkg to HP-UX, AIX, Solaris, and Cygwin. (That's dpkg, dpkg-split, and dpkg-deb only. I wasn't interested in dselect at the time.) I can email you the diffs. -- Kevin Dalley [EMAIL PROTECTED]
Re: xfree86_3.3.2.3a-9 (source i386 all) uploaded to master
Branden Robinson wrote: xfree86 (3.3.2.3a-9) frozen unstable; urgency=medium . snip 189 line changelog Wow! I wondered if this is the biggest debian changelog ever. It is, here are the other contenders: [EMAIL PROTECTED]:/debian3/lintian/laboratory/binaryfind -name changelog | \ xargs perl ~/changelog-length-parser |sort -n -r +2 |less ./xbase/changelog 3.3.2-4: 143 ... (other binary packages with same 143 line changelog and same source) ./lintian/changelog 0.3.0: 139 ./vm/changelog 6.27-1: 138 ./vm/changelog 6.39-1: 134 ./dist/changelog 3.70-1: 99 ./lintian/changelog 0.3.2: 94 ./lintian/changelog 0.8: 93 Congrats, Overfiend! (changelog-length-parser is atached) -- see shy jo
Re: xfree86_3.3.2.3a-9 (source i386 all) uploaded to master
Joey Hess wrote:
(changelog-length-parser is atached)
Well it is now anyway.
--
see shy jo
#!/usr/bin/perl
# Feed this program a list of debian changelogs. It will parse each, looking
# at the entries, and emit a running count of how long each individual
# changelog entry is. This was written to see if xfree86_3.3.2.3a-9 has
# the longest changelog entry ever. Useful in a linting laboratory directory,
# run as so:
#
# find -name changelog |xargs perl changelog-length-parser |sort -n -r +2
#
# copyright Joey Hess, GPL, 1999
# (RMS will just have to live with a short copyright notice on this one.)
foreach my $f (@ARGV) {
if ($f=~m/\.gz$/) {
open (C,zcat $f |);
}
else {
open (C,$f);
}
my $counter;
while (C) {
if (/^.*?\s+\((.*?)\)\s+.*?;\s+urgency=/) {
$ver=$1;
C; # blank line;
$counter=0;
$inlog=1;
}
elsif (/^ --/) {
if (!$inlog) {
print Parse error near ($ver) $_;
}
$counter=$counter-1;
$inlog=0;
print $f $ver: $counter\n;
}
elsif ($inlog) {
$counter++;
}
}
}
Re: xfree86_3.3.2.3a-9 (source i386 all) uploaded to master
Joey Hess wrote: Branden Robinson wrote: xfree86 (3.3.2.3a-9) frozen unstable; urgency=medium . snip 189 line changelog ./xbase/changelog 3.3.2-4: 143 ... (other binary packages with same 143 line changelog and same source) ./lintian/changelog 0.3.0: 139 I Will Try Harder. :-) Richard Braakman
Re: Packages I am orphaning.
At 17:11 +0100 1999-01-29, Remco van de Meent wrote: Joel Klecker wrote: pciutils - Utils for listing/tweaking PCI devices in 2.1/2.2 kernels Bug-free, lintian-clean There are some upstream alpha releases that would be nice to have packaged somewhere, but not essential If noone objects, I'll take this (I'm using it quite often my self within the context of an ongoing research project). I'll create packages of the alpha (prerelease) versions too. It's yours. -- Joel Klecker (aka Espy) URL:http://web.espy.org/ URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] Debian GNU/Linux PowerPC -- URL:http://www.debian.org/ports/powerpc/
Re: -rpath with libtool and Debian Linux
At 15:41 -0600 1999-01-29, Gordon Matzigkeit wrote: The best solution I can come up with is to *always* change a library's soname when its dependencies change. I believe it was Joel Klecker who mentioned something about `libapi' patches for egcs that were supposed to implement this automatically. Joel, can you comment on this (or somebody else who knows the details)? That patch merely applies to the soname of the libstdc++ library that is part of egcs, it imparts no other functionality. -- Joel Klecker (aka Espy) URL:http://web.espy.org/ URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] Debian GNU/Linux PowerPC -- URL:http://www.debian.org/ports/powerpc/
