Re: Free ASICs.
Bruce Perens <[EMAIL PROTECTED]> writes: > Hamish Moffatt wrote: > > >Manufacturing an ASIC involves NRE (non-recurring engineering) costs of > >hundreds of thousands to millions per revision. > > > If you haven't looked at OpenCores.org yet, please do so to get an > idea of how far they have been able to carry this so far. > > I have priced this out as far as getting a chip through MOSIS, which > is the step just before you'd go to full-wafer fabrication. Presumably > you'd use the same process in MOSIS that you'd use for > full-wafer. What I don't understand yet is the mask fabrication cost > for full-wafer, These days, about a million bucks per layer for 90 nm technology. > and what it costs to do fabrication runs once you have the mask. This is highly volume dependent. If you're serious about manufacturing small series of chips, you should be looking at laser or electron-beam lithography. This obviates the needs for masks, lowering NRE costs. The downsides is that it is slower to manufacture and more expensive when large series are involved. That's probably what MOSIS is using. Phil.
I'm back !
Fellow debianers,
After a one-month (unexpected) vacation, I'm back, and I cleared a
backlog of 5000+ emails. If you've emailed me and still waiting for a
reply, then your mail has been lost or deleted, and you should send
it again.
I'm very happy than 1.3 is finally released. AFAIK, there will be a
1.3.1 soon with the latest XFree. I'd like to make a fix for diald as
well which breaks when upgrading from some older versions. What's the
deadline for 1.3.1 ?
I'm also still unsure for the library package controversy.
I understood that for packages providing libraries, they should be recompiled
against libc6, and their files should be installed in the regular directories.
Additionaly, an other package should be made for compatibility issues, which
should install under /usr/i486-linuxlibc1/{include,lib}. The name for the
package should be libfooversion-altdev instead of libfooversion.
What /usr/libc5-compat for then ?
Is it mandatory, or recommended to create the altdev packages ?
What's the stability of hamm right now ? Is it usable ?
I've also got the orphans problem pending, I'll coordinate with Vincent
Renardias.
Phil.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6
When will we get libc6 X packages ? Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Adding conffiles to a package
I'm stuck with the diald package, and I've got problems with users
from old versions. The thing is:
the files /etc/diald/diald.ip-{up,down} weren't conffiles, and now
they are.
Installing a new version of diald where the ip-up/down scripts are
conffiles on top of an old version where they weren't results in
overwriting of the files.
I was thinking of the following approach:
In the preinst, check for the version of the old package through the
command line parameters, if the version we're upgrading from is too
old, make backup copies of the files.
Then, in the postinst, offer to the user to either use his old
conffiles, or the new ones which come with diald.
Will that work ???
Phil.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
On Fri, 13 Jun 1997 11:11:18 GMT Guenter Geiger ([EMAIL PROTECTED] ) wrote: > Will there be kernel level thread support for Debian ? Yes ! > The Linuxthreads package from Xavier Leroy is a very good Thread > Library supporting Posix threads. In order to develop threaded > applications there should be some changes in different packages: > > - the libpthread0 packages comes without header files ! They're probably in libpthread0-dev ! > - libraries should be compiled reentrant Most of them are. I'm not sure about the X libraries. Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: attempting to solve copyright problem
On Thu, 19 Jun 1997 00:13:09 EDT Igor Grobman ([EMAIL PROTECTED]) wrote: > I recently (yesterday, in fact) discovered a wonderful Tcl/Tk-based irc client > for X called cIRCus. It is by far the best graphical irc client I've seen. > My first thought was, of course, to package it for Debian, but the copyright > is quite restrictive. There is no source, and it states that "it can only > be distributed as a complete package". Looking through the circus discussion > board on cIRCus's home page, I found that the author isn't quite sure yet what > to do with the program, and that's why he isn't releasing source. I would > like > to convince him to release the source and GPL it, if possible. I've already tried to negociate that with the authors, but they ended up not answering my mail. I wish you better luck :-) Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Maintainer for Work-Needing ... FAQ needed
On 19 Jun 1997 17:47:49 +0200 Sven Rudolph ([EMAIL PROTECTED]) wrote: > Due to limited time I cannot maintain the "Work-Needing and > Prospective Packages for Debian GNU/Linux" anymore. We'll try to be taking this in the QA group (as I told you a looong time ago, without any effect (my fault)). Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
QA/test request
Hi fellow testers, I've just uploaded diald to master, and I plan to have it in Debian 1.3.1: it fixes many many packaging bugs and some diald bugs too. It has also the neat feature of rewriting outbound packets' IP headers stored in its buffer with dynamically allocated IPs. Neat neat. Can you please test it and report problems ? I'm especially interested in upgrades from old diald versions (these are the ones which were problematic). Vanilla rex upgrades should be tested (I've tested it here, but ...). As it might be stuck in master's incoming queue for a little while (because it mentions `stable'), you might want to get it from an alternate site (mine :-): ftp://ftp.fifi.org/pub/debian-local/diald/ Thanks, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz ([EMAIL PROTECTED]) wrote: > Option 3: We ship .texi files and produce HTML and/or info files on > demand (in the postinst script). I like this idea a lot. I *hate* having to fetch the source package to produce a postscript output... Phil -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 2.0.5c has a leak in inet_ntoa
On Wed, 10 Dec 1997 10:05:16 +1100 Craig Sanders ([EMAIL PROTECTED]) wrote: > On Wed, 26 Nov 1997, Philippe Troin wrote: > > > Libc6 2.0.5c has a leak in inet_ntoa. > > > > [...deleted...] > > > > In the meantime, you can link programs which do heavy inet_ntoa with > > libpthread, it will cure the leak (diald 0.16.4-11 does this, as a > > temporary measure while waiting for libc6 2.0.6). > > ok, this is the bug i was looking for. anyone know if there is a fix > for this yet? > > i just ran ldd on a random sample of daemons (sendmail, proftpd, squid, > inetd, rpc.nfsd and apache...all latest versions as of yesterday) - none > of them are linked with libpthread. imo it should be fixed in libc6 not in > the daemonshowever, if a fix isn't going to be out for a while then > these and other programs need to be recompiled asap. > > this bug is critical severity for any moderate-to-heavy use server. > (it's crashed one of my mail servers and one of my gateway boxes already) > > anyone got a fix apart from recompiling everything that uses inet_ntoa? > > i've started a cron job to stop and restart various services every few > hours, but that's a real crappy solutionespecially for squid - squid > can take half an hour or more to restart on a big cache. Libc6 2.0.6 fixes the problem. Temporarily, you can link your programs with -lpthread. *or* you can extract the working inet_ntoa.o from libc.a and link this function statically with: ar x /usr/lib/libc.a inet_ntoa.o ld inet_ntoa.o If Debian wants to have a patched libc6 2.0.5c, I've got the four lines patch. Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Mnemonic? (possible intent to package...)
On Thu, 30 Apr 1998 17:22:12 MDT Bear Giles ([EMAIL PROTECTED]) wrote: > If not, does anyone know where "dlfcn.h" (as I recall) comes from? % dpkg -S dlfcn.h libc6-dev: /usr/include/dlfcn.h It's the header for dlopen(), dlclose(), dlsym(), dladdr(), the dynamic linker functions. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mnemonic? (possible intent to package...)
On Fri, 01 May 1998 08:25:16 MDT Bear Giles ([EMAIL PROTECTED]) wrote: > > On Thu, 30 Apr 1998 17:22:12 MDT Bear Giles ([EMAIL PROTECTED]) > > wrote: > > > If not, does anyone know where "dlfcn.h" (as I recall) comes from? > > > > % dpkg -S dlfcn.h > > libc6-dev: /usr/include/dlfcn.h > > I also found it in libc4-dev, but not libc5-dev (5.4.33-3). > Is this a bug? No it wan't part off libc5 but of ldso: % rsh tantale dpkg -S dlfcn.h ldso: /usr/include/dlfcn.h You also needed libdl1 installed. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On Wed, 03 Jun 1998 11:17:15 BST Philip Hands ([EMAIL PROTECTED]) wrote: > > David> Voting by developers should be limited to the election and > > David> recall of leaders and the ratification of amendments. > > > > Why? Because even though we do all the work, the masses are > > too dumb to do their own masters? We need a all knowing, all > > powerful group of people to tell us how to act? What cventury are we > > in now? > > No, because democracy is inefficient in our case. [snip] > I vote ``No Democracy for Debian!'' ;-) ME TOO. I agree with Philip Hands and David Engel. Though I think there's better things to discuss (like finishing hamm for example)... Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should etch be Debian 4.0 ?
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes: > On Fri, Jul 08, 2005 at 11:57:25AM +1000, Drew Parsons wrote: > > I'm already seeing documentation referring to "Debian 3.2 (etch)". Is > > this really what we want? > > > > I remember some of us belatedly suggested sarge should be Debian 4.0, > > though it was too late (May?) to accept that. > > > > I suppose we should decide now if etch is going to be 3.2 or 4.0. > > > > Given the ABI change with gcc-4.0 and the introduction of X.org, it > > seems to me we have ample justification to introduce Debian 4.0. > > > > I second the motion. I realize that the goal of Debian is not to > appease the unwashed masses. However, it seems logical (and warranted) > to bump the major version number to indicate the dramatic differences > between Sarge and (the to be released) Etch. I think multiarch would warrant a major version bump. Gcc 4 and X.org would not IMHO. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TclX package again
On Tue, 20 Aug 1996 09:51:39 CDT David Engel ([EMAIL PROTECTED]) wrote: > Note: I'm copying this to debian-devel to get feedback on my response > to Philippe's question #3. If you do respond, please include a direct > response to me in addition to the list. I was inadvertantly dropped > from debian-devel three weeks ago and no amount of trying on my or > Bruce's parts has been able to get me back on the list. Can anyone put me on the list too ? In the meantime can you post followups to my address as well as the list, please... > Philippe Troin writes: > > 1) When compiling (make -f debian.rules) Tcl (needed to build tclX, > > what a shame that you need the tcl/tk source tree), I have errors > > in tclPosixStr.c about a case having same value (EDEADLOCK and > > EDEADLK are both defined and have the same value). Fixed by adding > > an #if EDEADLOCK != EDEADLK. > > Did you recompile it lately ? > > I'm aware of the problem, but haven't had time to fix it yet. It's a two lines fix actually. BTW, Tcl 7.4 has the same problem. > > 2) I've tried to 'make test' in both tcl7.5 and tk4.1 source trees, > > both failed. Shouldn't we report this to the Tcl/Tk maintainers > > and/or try to fix it ? This works perfectly on other systems (tried > > Solaris). > > What do you mean by failed? If you mean some individual tests fail, > then that is expected. I believe all of the Tk failures are due to > non-portable tests. I have not had time to look into the Tcl > fileevent failures yet, but I suspect they are either due to > non-portable tests also or libc bugs. Some individual test failed for Tcl 7.5 (one test), Tk 4.1 (3 or 4 tests), TclX 7.5 (4 or 5tests). I'll try to check them out... when I've got time. > > 3) I think I should have tclX be the same (regarding package > > management) and tcl and tk. ie, I will have tclX74 and tclX75, both > > incompatible with tclX. tclX74-dev and tcl75-dev being mutually > > exclusive too... What do you think about it ? > > I agree, for now. One change I'm considering is to give each major > Tcl version it's own include directory (e.g. /usr/include/tcl7.4, > /usr/include/tcl7.5). This would make it easier to have multiple > development packages installed simultaneously. The limitation of only > having one installed at a time is quickly becoming a problem because > of the way Tcl/Tk-based packages are tied to a specific version of > Tcl/Tk. What do you think? I think it's fine. Tcl and Tk will need a little package work, but TclX is already version clean as it's installed in /usr/lib/tclX/. But we'll have to implement /etc/alternatives stuff for the .a and the .so. Do you see any other problem ? > > 4) I plan having a separate tclX7[45]-doc package for the help > > system ( and /usr/bin/tclhelp). What's your > > opinion on that one ? > > I've considered doing something like this with the section 3 manual > pages for Tcl/Tk. The reason I hadn't done it yet is that I didn't > want to create yet another package unless I really needed to or > someone else wanted it. I think keeping the manual pages within the devel package is good. However for TclX, /usr/lib/tclX/7.*/help contains a duplicate of all the man pages formatted differently to be used with tclhelp, hence the new 'doc' package. I must admit I never use this feature myself. But generally, keeping the manpages with the development stuff should be a good thing. Phil.
Bug#4494: Xlib's XForceScreenSaver flashes the display
Package: xserver-svga Version: 3.1.2-5 The attached piece of code makes the whole display to flash. Here is some information: dpkg -Package: xserver-svga Status: install ok installed Priority: optional Section: x11 Maintainer: Stephen Early <[EMAIL PROTECTED]> Source: XFree86 Version: 3.1.2-5 Replaces: xsvga Provides: xserver Depends: libc5 Recommends: xfntbase Suggests: xbase Conflicts: xsvga Description: XFree86 3.1.2 SVGA server This package provides an X server suitable for use with all SVGA video cards. The server also makes use of the accelerator features of Cirrus, Western Digital and Oak chipsets. Package: xlib Status: install ok installed Priority: standard Section: x11 Maintainer: Stephen Early <[EMAIL PROTECTED]> Source: XFree86 Version: 3.1.2-7 Replaces: elf-x11r6lib Provides: xR6shlib, xlibraries, elf-x11r6lib Depends: libc5, ldso (>= 1.7.14-1) Conflicts: elf-x11r6lib Description: XFree86 3.1.2 shared libraries My graphics card is a Trident TVGA9400-Cxi, the XF86Config is available upon request. I suspect a drop in the HSync or VSync pulse to cause this (any mode change causes the same kind of flashing). Phil. binwjuxi8kD4s.bin Description: demo.c
Imagmagick license & various problems
Hi Folks. I've debianized ImageMagick and uploaded it to master, in section non-free for now. However I think I could move it to the 'graphics' section as: 1) The license states it's free (included as attachment) 2) It doesn't include the GIF compression code What do you think about this ? A Debian user would like to change the default cache size (16MB) for the display program to something more suitable for small systems. I don't want to modify the source unnecessarily. This cache size can be controlled through a X resource. I'm considering the following options: 1) Change this to something smaller (making the manpage wrong) in /etc/X11/Xdefaults. 2) Make a postinst script to ask the user about it. (I don't like this solution, if every package asked small details like this, it would be a nightmare). 3) Document the problem in the doc file. Once again, are there any advices on this ? BTW, I've sent a message to debian-changes to inform users about the upload of the package, but the message never came out. What's the procedure to send a message to debian-changes ? Phil. Copyright 1996 E. I. du Pont de Nemours and Company Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of E. I. du Pont de Nemours and Company not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. E. I. du Pont de Nemours and Company makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. E. I. du Pont de Nemours and Company disclaims all warranties with regard to this software, including all implied warranties of merchantability and fitness, in no event shall E. I. du Pont de Nemours and Company be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of this software.
dpkg versions
Sorry if this has already been asked many times... I currently run dpkg 1.2.14. I've read various posts about the new 1.3 version. Do I need to upgrade (I think yes) to make new packages in 1.3 format to be included in Debian 1.2 ? Do I need to change the package debian.* files to the new Debian policy (version 2.1.1.0 (dpkg 1.4.0), 12 September 1996). I've read a post saying that the new Debian policy shouldn't be implemented yet. Is that right ? Thanks, Phil.
Bug#4530: ld cannot find most shared libraries
On Fri, 20 Sep 1996 16:46:52 +1000 Mr Stuart Lamble ([EMAIL PROTECTED]) wrote: > I've recently had problems linking programs non-statically with (e.g.) the > X11 libraries, etc. Static libraries are fine, shared have problems. Upon > investigation, and discussion with a friend, it appears that ld cannot find > files of the form: > > libfoo.so.1 > libfoo.so.1.2.3 > > etc. - there has to be a symlink libfoo.so for libfoo to be found. Upon > creating such symlinks, everything worked fine. (well, once I got rid of > the /lib/libc.so => /lib/libc.so.4 link, that is :-) Oops. :) This is because the development packages aren't installed. Install libfoo-dev to get the symlinks, the include files, etc... Phil.
Re: Hosed potato/main/Packages...
Michael Alan Dorman <[EMAIL PROTECTED]> writes: > the aleph-* packages have Priority: optionnal, which is, well, wrong. Yeah, just uploaded some new packages which fix the typo. Maybe it should be trapped by dinstall instead of hoosing apt/deselect/etc... Dpkg is happy with it however... Phil.
Need help for GPG
I'm trying to use GPG for signing my debian packages...
I've successfully created my new GPG secret key, and when I list my
keys and signatures, I get:
% gpg -v --list-sig [EMAIL PROTECTED]
gpg: Warning: using insecure memory!
pub 1024D/6EAF7F87 1999-10-04 Philippe Troin <[EMAIL PROTECTED]>
sig6EAF7F87 1999-10-04 Philippe Troin <[EMAIL PROTECTED]>
sub 2048g/BBEB26B2 1999-10-04
sig 6EAF7F87 1999-10-04 Philippe Troin <[EMAIL PROTECTED]>
pub 768R/3EE7EDCD 1996-08-26 Philippe Troin <[EMAIL PROTECTED]>
sig82B7D4BD 1998-11-01 Joey Hess <[EMAIL PROTECTED]>
sig 3EE7EDCD 1996-08-26 Philippe Troin <[EMAIL PROTECTED]>
gpg: can't handle public key algorithm 192
The first two keys are the new ones, the last the old (PGP) one.
After much struggle, I manage to sign the 1024 bits DSA key, but not
the 2048 bits El-Gamal key:
% gpg -v --list-sig [EMAIL PROTECTED]
gpg: Warning: using insecure memory!
pub 1024D/6EAF7F87 1999-10-04 Philippe Troin <[EMAIL PROTECTED]>
sig6EAF7F87 1999-10-04 Philippe Troin <[EMAIL PROTECTED]>
sig3EE7EDCD 1999-10-04 Philippe Troin <[EMAIL PROTECTED]>
sub 2048g/BBEB26B2 1999-10-04
sig6EAF7F87 1999-10-04 Philippe Troin <[EMAIL PROTECTED]>
pub 768R/3EE7EDCD 1996-08-26 Philippe Troin <[EMAIL PROTECTED]>
sig82B7D4BD 1998-11-01 Joey Hess <[EMAIL PROTECTED]>
sig3EE7EDCD 1996-08-26 Philippe Troin <[EMAIL PROTECTED]>
gpg: can't handle public key algorithm 192
And why do I get this message about public key algorithm 192 ?
Or am I ok and cannot sign the El-Gamal key ?
And then I should then the new key with 'gpg -a --export' and send it
to [EMAIL PROTECTED] ?
And finally, anyone knows if I can integrate gpg with Gnus ?
Phil.
Potato fresh install
I installed a fresh copy of potato on a box, using the 2.2.7-2000-02-13 boot-disks. The base system install worked perfectly OK here. The first time I tried to run apt (on a NFS archive), the package scanning done by debconf failed because base-perl was missing getopt. => dpkg -i perl*.deb Then I've used dpkg --get-selections from an other box and dpkg --set-selections. It went mostly smoothly except for: - Every package using debconf asked the questions before install, and in the postinst (maybe the upgrade from debconf-tiny to debconf wiped the database ?) - I had a few seemingly inoffensive warnings about a missing /etc/mailcap. - Wdm refused to install since no /etc/X11/window-managers was there (wdm was the only window manager installed). That's all so far. Oh, and I got bitten by the update-alternatives syntax error, but installing the dpkg found in incoming fixed the problem... Phil.
Re: portmap/networking: shutdown script links screwed-up?
Jose Marin <[EMAIL PROTECTED]> writes: > I am running several boxes with unstable(woody), and the sutdown process > on some of them hangs near the end. They are all NFS clients to other > Linux and Solaris machines. The ones that hang do it when trying to > access NFS (I think trying to umount the nfs mounts I have in /etc/fstab) > *after* the portmapper and the networking is gone. They're hung sending > RPC timeout messages (sendmsg error 101, I recall). Yep found that too... There are two bugs open against netbase (#59282, #59286). > Since the other machines that do not hang are almost identical, I traced > the difference to this: the rc6.d/rc0.d *links* to the "portmap" and > "network" scripts in /etc/init.d. The scripts themselves are the same. > > The machines that hang on shutdown/halt have: > >rc0.d/S10portmap -> ../init.d/portmap >rc0.d/S15networking-> ../init.d/networking > > The machines that do not hang have: > > rc0.d/K35portmap -> ../init.d/portmap > (and do not have any link to "networking") > > > I didn't configure this, the difference is due to the fact that I > installed woody on the machines that have the problem some weeks later > than the ones that work. This must have changed in netbase, but I > couldn't find it in the changelog. > > Anyone found this problem/bug? What fix would you suggest? > > Incidentally, why isn't there a script "umount-nfs" separated from > "umountfs"??? That's something I've been pondering about. It's a good idea. Maybe a wishlist bug ? :-) And also, the boxes which have this problem cannnot shutdown to single user mode and come back to multiuser, the portmapper is not restarted... Phil.
Re: X with (g|w|x)dm capable of selecting host at login
John Goerzen <[EMAIL PROTECTED]> writes: > xdm already has this feature, I believe. > > -- John > > esoR ocsirF <[EMAIL PROTECTED]> writes: > > > Hi, > > A while back there was mention of developing a display manageer that > > could select a host to login to. What ever became of this? > > > > I am setting up a small group of machines for our physics/engineering > > depts. and would like to have this available. Is this still just > > ideaware? > > > > My apologies if this is the wrong place to post this to. > > > > -- > > Frisco Rose "By any other name, I would smell the same" > > E.O.U. Stud. [EMAIL PROTECTED] [EMAIL PROTECTED] > > Physics Mathematics Computer Science > > > > If all the ipv6 addresses were distributed evenly across the planets > > surface, there would be roughly 423,354,243,695,259,002,656 per square inch. > > And, no, I don't know what this has to do with anything. > > (Some witty Debian Developer) wdm too, with a little bit of hacking... Install also xdm, or get the "chooser" executable from xdm. In /etc/X11/wdm/wdm-config, add: ! Use our chooser DisplayManager*chooser: Start X with "X -indirect localhost" and voila. Phil.
Re: X with wdm capable of selecting host at login
Brian May <[EMAIL PROTECTED]> writes: > > "Brian" == Brian May <[EMAIL PROTECTED]> writes: > > esoR> # /etc/init.d/wdm stop # X -indirect localhost > > esoR> and I get an X background with a mouse cursor but no wdm > esoR> panel. I, once again, assume that this is the correct > esoR> behavior. So I am now thinking, do I pass these options to X > esoR> via the /etc/X11/wdm/Xservers file? If so the syntax is > esoR> beyond me at the moment. I would like to think that I am not > esoR> as dumb as a bag of hammers but facts tend to implicate me > esoR> as so being :-/ > > Oh, sorry, I must have read that too fast, I though you said that the > above command worked. > > Oh, I see, you have stopped the wdm server... Of course X is not going > to be able to talk to the display manager on localhost if you just > killed the display manager... > > I think you want to reconfigure wdm so it doesn't start the X server > automatically (I use gdm, sorry I can't remember how to do it on wdm, > except I know it is very simple), then the above X command will work > if wdm is running at the time. > > Another command you might find of some use is > > X -query remotehost.com.au Well, actually in addition to what I mentionned in the previous mail (repeated here for convenience): Install also xdm, or get the "chooser" executable from xdm. In /etc/X11/wdm/wdm-config, add: ! Use our chooser DisplayManager*chooser: You need to tell wdm to stop managing the local display (strip the "#0 local /usr/bin/X11" line from /etc/X11/wdm/Xservers). Restart wdm. Run "X -indirect localhost". Eventually, use the mentionned script to do this via the inittab. Phil.
What happened to the alpha potato iso images ?
There used to be some alpha iso images on cdimage.debian.org (& mirrors), but they disappeared later on... How come ? Phil.
WTF does zsh 3.1.9 does in potato-proposed-updates ?
Why a new zsh was introduced in potato-proposed-updates ? It's not compatible with thw previous version... I thought potato-proposed-updates was just about severe bugfixes... Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WTF does zsh 3.1.9 does in potato-proposed-updates ?
Package: zsh Version: 3.1.9.dev6-1 Clint Adams <[EMAIL PROTECTED]> writes: > > Why a new zsh was introduced in potato-proposed-updates ? It's not > > compatible with thw previous version... > > What do you mean, it's not compatible? "zmodload complist" does not work for example (it says it cannot find the module). [EMAIL PROTECTED]:~% zmodload complist zsh: failed to load module: complist zsh: exit 1 [EMAIL PROTECTED]:~% zmodload /usr/lib/zsh/3.1.9-dev-6/zsh/complist.so zsh: invalid module name `/usr/lib/zsh/3.1.9-dev-6/zsh/complist.so' zsh: exit 1 [EMAIL PROTECTED]:~% strings =zsh | grep /usr/lib /usr/lib/zsh/3.1.9-dev-6 [EMAIL PROTECTED]:~% I notice that in the previous zsh version, there were some .so files in both /usr/lib/zsh/3.1.6-dev-21 and /usr/lib/zsh/3.1.6-dev-21/zsh but the new zsh only has .so files in /usr/lib/zsh/3.1.9-dev-6. My point was why was zsh 3.1.9-dev-6 was introduced into potato-proposed-updates while the previous version was 3.1.6-dev-21 ? We freeze potato for 3 months and get a working system, and as soon as it is released we add some packages that break it along with the security fixes (proposed-updates). I've opened a bug against zsh for the aforementioned behavior. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Best way to depend on an xserver but conflict with XF86 v4 ?
I have a package (utah-glx) which needs can be used only on a XF86 3.3.6 server. How can I express this ? Depends: xserver(<<4.0) does not work since xserver is a virtual package. I found: Depends: xserver Conflicts: xfree86-common(<=4.0) to be working. Is it the right way (or a good enough way) ? Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: Partition Image
Sergio Rua <[EMAIL PROTECTED]> writes: > I Intent to Package "Partion Image". 8< snip >8 > NOTE to Philippe Troin: this package require a libbz2 >= 1.0.0 In woody, > now, 0.9.5d-2 I'm working on packaging 1.0.1 right now... Expect it within a couple of days. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fcntl(HANDLE, F_GETLK,&fl) with perl
Bill Allombert <[EMAIL PROTECTED]> writes:
> Hello Debian-devel,
>
> I try to code the following in perl
>
> struct flock fl;
> if (fcntl(fd,F_GETLK,&fl) == -1)
>
> to query the dpkg lock.
>
> I have tried the above
>
> fcntl DPKG_LOCKFILE,F_GETLK, \%fl;
>
> but it does not seems to work. In fact the documentation
> is unclear whether a struct flock can be passed at all
> (some form of fcntl use a long arg instead).
You have to pack the structure by hand. This works for me:
use Config;
my $packspec = $Config{uselargefiles} ? "ssqql" : "sslll";
my $lk = "";
fcntl DPKG_LOCKFILE,F_GETLK,$lk;
my ($l_type, $l_whence, $l_start, $l_len, $l_pid) = unpack($packspec, $lk);
Phil.
Garbled messages received from lists.d.o.
I have been receiving bugs.d.o emails which are unrelated to my package for the last two-three days. And their headers seem quite garbled: they include part of other messages... Included five of them. Is there anything fishy going on? Or is the spam filter going crazy? Phil. --- Begin Message --- Package: flim Version: 1:1.14.4-1 Severity: normal New upstream (flim-1.14.5) was released. http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/flim/flim-1.14/flim-1.14.5.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message --- --- Begin Message --- Your message dated Thu, 26 Jun 2003 23:58:16 +0200 (CEST) with message-id <[EMAIL PROTECTED]> and subject line Bug#198887: emacs21: envvars not being inherited everywhere has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 26 Jun 2003 10:27:26 + >From [EMAIL PROTECTED] Thu Jun 26 05:27:17 2003 Return-path: <[EMAIL PROTECTED]> Received: from serv09.segi.ulg.ac.be [139.165.32.78] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 19VTyH-0002xG-00; Thu, 26 Jun 2003 05:27:17 -0500 Received: (qmail 2113 invoked by uid 504); 26 Jun 2003 12:27:16 +0200 Received: from [EMAIL PROTECTED] by serv09.segi.ulg.ac.be by uid 501 with qmail-scanner-1.16 (spamassassin: 2.55. Clear:. Processed in 0.274768 secs); 26 Jun 2003 10:27:16 - Received: from unknown (HELO localhost) ([139.165.201.72]) (envelope-sender <[EMAIL PROTECTED]>) by serv09.segi.ulg.ac.be (qmail-ldap-1.03) with SMTP for <[EMAIL PROTECTED]>; 26 Jun 2003 12:27:15 +0200 Date: Thu, 26 Jun 2003 12:27:14 +0200 (CEST) Message-Id: <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: emacs21: envvars not being inherited everywhere X-Debbugs-CC: Arnaud Vandyck <[EMAIL PROTECTED]>, [EMAIL PROTECTED], debian-emacsen@lists.debian.org From: Arnaud Vandyck <[EMAIL PROTECTED]> X-Mailer: Mew version 3.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-9.0 required=4.0 tests=BAYES_10,HAS_PACKAGE,X_DEBBUGS_CC version=2.53-bugs.debian.org_2003_06_18 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_06_18 (1.174.2.15-2003-03-30-exp) Package: emacs21 Version: 21.2-6 Severity: normal Describing the problem at [EMAIL PROTECTED], Kai Großjohann and Stefan Monnier suggested me to fill a bug. They also helped me to describe it: I put "export CVS_RSH=ssh" into the file ~/.foo. Then I log in via kdm/gdm/xdm and start a shell. Typing "echo $CVS_RSH" into that shell gives me ssh. Good. I invoke Emacs from that shell. Typing M-: (getenv "CVS_RSH") RET into that Emacs gives me ssh. Good. I invoke Emacs from the menu. Now typing M-: (getenv "CVS_RSH") RET gives me nil. Bad. Best regards, Arnaud. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux debian 2.4.20-powerpc #1 Mon Jun 9 11:05:19 EDT 2003 ppc Locale: LANG=fr_BE, LC_CTYPE=fr_BE Versions of packages emacs21 depends on: ii emacs21-common21.2-6 The GNU Emacs editor's common infr ii libc6 2.3.1-17 GNU C Library: Shared libraries an ii libjpeg62 6b-7 The Independent JPEG Group's JPEG ii libncurses5 5.3.20030510-1 Shared libraries for terminal hand ii libpng12-01.2.5.0-4 PNG library - runtime ii libtiff3g 3.5.7-2Tag Image File Format library ii xaw3dg1.5-23 Xaw3d widget set ii xlibs 4.2.1-6X Window System client libraries ii zlib1g1:1.1.4-12 compression library - runtime -- no debconf information -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. --- Received: (at 198887-done) by bugs.debian.org; 26 Jun 2003 21:58:19 + >From [EMAIL PROTECTED] Thu Jun 26 16:58:19 2003 Return-path: <[EMAIL PROTECTED]> Received: from serv09.segi.ulg.ac.be [139.165.32.78] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 19Vel0-0006d6-00; Thu, 26 Jun 2003 16:58:18 -0500 Received: (qmail 15027 invoked by uid 504); 26 Jun 2003 23:58:1
Re: Please remove RFCs from the documentation in Debian packages
"Marco d'Itri" <[EMAIL PROTECTED]> writes: > On Jul 03, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > >I believe this whole case of RFC standards are not confirming to The > >Debian Free Software Guidelines display a complete lack of > >understanding of the value of standards, and should be rejected. > >Standards are not software, nor software manuals, and should not be > >treated as such. > I fully agree. Banning RFCs from debian is just silly. Wait, we're thinking about banning most of the GNU documentation too, since it's GFDL'ed (the libc, emacs, and gdb manuals for example), or putting it under non-free. I like this DFDG idea (Debian Free Documentation Guidelines) :-)... Phil.
Re: Bits from the release team: the plans for etch
Steve Langasek <[EMAIL PROTECTED]> writes: > On Thu, Oct 27, 2005 at 07:24:28AM -0500, Steve Greenland wrote: > > On 27-Oct-05, 04:39 (CDT), Jonas Meurer <[EMAIL PROTECTED]> wrote: > > > > it produces at least a bloated passwd/group/shadow file. > > > "Bloat"? The /etc/passwd on my development machine, which has seen all > > kinds of random server installs and removes, has grown to a whole 2K. > > So it could double before expanding into a second disk block. "Untidy", > > I'll grant you, but "bloat" seems excessive. > > Nah, the biggest hit isn't disk space, it's NSS lookup times from having to > do a linear search through a flat-file /etc/passwd and /etc/shadow. Well, > thank God no one uses pam_pwdb anymore, at least... An other issue that always annoyed me is that assuming a NIS server and a NIS client which both install say exim. I want to give some users membership in the group Debian-exim. I can't easily. The UID picked by Debian-exim is not going to be the same for the NIS server and all the NIS clients, so I cannot get it propagated by NIS. And I don't want to have to maintain the group membership on all the clients. Currently, the only decent solution is to force the same UID and GID on all the NIS machines. And propagate the membership through NIS. Yet some packages do not deal very well with that solution: some are confused by some user or group that they cannot modify with usermod or groupmod. Others are confused when removing the user or group (userdel and groupdel failing to remove a NIS entry). Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Gabor Gombas <[EMAIL PROTECTED]> writes: > On Sat, Oct 29, 2005 at 10:21:13PM -0700, Philippe Troin wrote: > > > An other issue that always annoyed me is that assuming a NIS server > > and a NIS client which both install say exim. I want to give some > > users membership in the group Debian-exim. I can't easily. > > > > The UID picked by Debian-exim is not going to be the same for the NIS > > server and all the NIS clients, so I cannot get it propagated by NIS. > > And I don't want to have to maintain the group membership on all the > > clients. > > That is a local administration decision. You should have a clear policy > wether you'll be allowing system groups in NIS _before_ creating the NIS > domain. If you do, you should have a plan _before_ creating the NIS > domain about how you will deal with the inevitable conflicts. > > When I last administered a complex distributed environment (we used > first NIS+ then LDAP, but that's not important), we had a policy that > local software should never use user/group IDs coming from NIS+/LDAP, > and software installed on shared filesystems should never use user/group > IDs _not_ coming from NIS+/LDAP. Mixing local and remote IDs in group > membership was forbidden as well. That worked quite well. Although I agree with the above on principle, how do you manage membership to the floppy, audio, video, etc groups? Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Gabor Gombas <[EMAIL PROTECTED]> writes: > On Fri, Nov 04, 2005 at 11:01:20AM -0800, Philippe Troin wrote: > > > Although I agree with the above on principle, how do you manage > > membership to the floppy, audio, video, etc groups? > > pam_group for example. pam_group would work for floppy, audio and video. But it's insecure. And it does not solve the problem for group membership like Debian-exim. > If you want to let some users access the devices > even if they are not logged in at the console, then it is better to use > sudo & some helper scripts (so syslog will contain who did what). Yes, it can be done. But it's also impractical. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use opie on Debian central servers to prevent password sniffing?
Tim Freeman <[EMAIL PROTECTED]> writes:
> At
> http://lists.debian.org/debian-announce/debian-announce-2003/msg3.html
> it says the Debian machines were compromised by password sniffing from
> other compromised machines. If you use one time passwords instead,
> then password sniffing doesn't yield useful information and the damage
> from this sort of failure would be more limited.
>
> As you probably know, the packages for that are opie-server and
> libpam-opie on the server, and opie-client on the client. You'd also
> have to edit /etc/pam.d/{login,ssh} to mention libpam-opie, at least.
> Finding and installing a skey calculator on a personal organizer is
> probably better than using opie-client on a machine that's connected
> to the internet and therefore conceivably compromised. To discourage
> people from typing into a potentially compromised machine, you certainly
> don't want to have opie-client installed on any central server.
>
> I just started using opie on fungible.com, and it seems to work well
> so far.
>
> Is there some issue with opie that would cause problems when using it
> on the Debian servers?
I haven't look at OPIE for ages, but when using it with ssh, doesn't
it force you to turn privilege separation off in /etc/ssh/sshd_config?
Maybe the ssh people fixed this issue since.
Phil.
Unreadable packages in dak queue
Is there any reason why the packages in the dak queue (for example /org/ftp.debian.org/queue/new on ftp-master) are 660 instead of 664 ? Phil.
Re: Unreadable packages in dak queue
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Tue, Aug 27, 2002 at 04:26:15PM -0700, Philippe Troin wrote: > > Is there any reason why the packages in the dak queue (for example > > /org/ftp.debian.org/queue/new on ftp-master) are 660 instead of 664 ? > > Yep. Export notification hasn't been sent for them, etc. That's the > theory, at least. Forgot that stupid detail. Phil.
Re: Problem with resolv.conf and search list
[moving the discussion to [EMAIL PROTECTED] Bruno BEAUFILS <[EMAIL PROTECTED]> writes: > There is something I do not understand about resolving hostnames. It seems the > search primitive of resolv.conf does not work properly in sid, nor in woody. > > Let's see some of my configuration files : > > resolv.conf > search lifl.fr univ-lille1.fr iut-info.univ-lille1.fr > nameserver 134.206.10.18 > nameserver 134.206.1.4 > nameserver 134.206.1.15 > - The parser for resolv.conf is very stupid. Try: search lifl.fr univ-lille1.fr search iut-info.univ-lille1.fr nameserver 134.206.10.18 nameserver 134.206.1.4 nameserver 134.206.1.15 Phil.
Re: /bin/ls is impure!
Norbert Veber <[EMAIL PROTECTED]> writes: > Hi, > > This is probably the weirdest thing I've seen in debian so far. > > I was able to re-produce it on my home and work machines, and a person on > irc also go the same results. > > Try this: > apt-get install purity purity-off # Not sure if the -off package is > # actually necessary > purity list > purity nerd # any test should do from the previous > # list > > Either finish the test, or abort it via ctrl-c or the "q" command. > > --> Now run ls. ??? [EMAIL PROTECTED]:~[2]# apt-get install purity purity-off Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed: purity purity-off 0 packages upgraded, 2 newly installed, 0 to remove and 1 not upgraded. Need to get 54.5kB of archives. After unpacking 215kB will be used. Get:1 http://debian.commerceflow.com woody/main purity 1-9 [25.7kB] Get:2 http://debian.commerceflow.com woody/main purity-off 0-2 [28.8kB] Fetched 54.5kB in 0s (391kB/s) Selecting previously deselected package purity. (Reading database ... 76862 files and directories currently installed.) Unpacking purity (from .../archives/purity_1-9_i386.deb) ... Selecting previously deselected package purity-off. Unpacking purity-off (from .../purity-off_0-2_all.deb) ... Setting up purity (1-9) ... Setting up purity-off (0-2) ... [EMAIL PROTECTED]:~[2]# suspend zsh: 20762 suspended su -m [EMAIL PROTECTED]:~% purity list welcome to the purity test. the current available tests are: mtrek - see how muck of an mtrek geek you are... nerd - tests to see how "nerdy" you are... hacker - a hard core computer hacker purity test. format - an explanation of the data file format (for writing your own tests) sample - prints a generic sample datafile to run each test, use "purity [flags]". bye. [EMAIL PROTECTED]:~% purity nerd The East Campus Nerd Test Posted to talk.bizarre by: [EMAIL PROTECTED] (Kitchen Scott) Score one point for each YES. The score is % nerdity. 1. Have you ever used a computer? If the answer is no, try taking the Baker House Purity Test. your answer? [ynbakdlsrq?] : Maybe 2. Have you ever programmed a computer? your answer? [ynbakdlsrq?] : Maybe 3. Have you ever built a computer? your answer? [ynbakdlsrq?] : quit you answered 0 'no' answers out of 2 questions, which makes your purity score 0.00%. seeya later, alligator. [EMAIL PROTECTED]:~% ls Apache-CodeRed-1.07.tar.gz shlib.c dvpt/ shuse.c priv/ usr/ [EMAIL PROTECTED]:~% > Be prepared to abort it before it consumes all the available memory on your > system. > > If you do this while in X, you will have to close your X terminal to get ls > working agin (doesnt matter if its gnome-terminal, xterm, Eterm. It even > happens in console, though the effect is permanent (ls will not work on that > console anymore). reset, clear, etc dont fix it. > > I did not send this to the BTS yet as I'm not 100% certain what package is > at fault. > > To me it looks like this would be a bug in ls, though I cant figure out what > is causing it, or why it happens after running purity. The environment is > unchanged, the aliases are unchanged, the only difference is that ls no > longer works. It works... Something's wrong with your system. Try strace'ing ls. Phil.
Re: /bin/ls is impure!
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes: > > > > It works... Something's wrong with your system. > > Try strace'ing ls. > > what shell are you playing with? I presume most people are using bash. Zsh. Phil.
Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]
Chris Cheney <[EMAIL PROTECTED]> writes: > I forgot to cc debian-devel on this: > > I think that the best solution to the problem would be for me to upload a > new version of libqt2 2.3.1 compiled against libpng2. Due to the potential > problems with upgrading from stable (potato) to the future new stable > (woody). I will do this tomorrow morning. After I upload the new version of > libqt2 packages will probably need to depend on that version and > libpng2-dev and be rebuilt, at least for the current ones that are built > against libpng3. > > I hope that eventually this sort of problem will not be an issue due to > symbols being overridden. Is there some way to fix this from being an > issue in the future? This is very big and annoying problem that probably > affects other packages, even more than just libqt/imlib. > > If anyone has any further comments please feel free to let me know. Please > direct all flames to Overfiend ;) Sounds good to fix all the current problems... however how are we going to handle the libpng2 -> libpng3 conversion ? Your solution just seems to postpone the problem. Phil. Libpng2/3 maintainer.
Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]
Chris Cheney <[EMAIL PROTECTED]> writes: > On Mon, Jan 07, 2002 at 05:06:27AM -0800, Philippe Troin wrote: > -snip- > > > > Sounds good to fix all the current problems... however how are we > > going to handle the libpng2 -> libpng3 conversion ? Your solution just > > seems to postpone the problem. > > libqt 3.x already uses libpng3 so that looks like a good conversion spot. Sounds good to me. How do you plan to prevent programs that link with libqt2 to also link with libpng3 ? Manual check ? Phil.
Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]
Chris Cheney <[EMAIL PROTECTED]> writes: > On Mon, Jan 07, 2002 at 10:07:23AM -0800, Philippe Troin wrote: > -snip- > > > > Sounds good to me. > > > > How do you plan to prevent programs that link with libqt2 to also link > > with libpng3 ? Manual check ? > > yes manual check Ok. Excellent. Would you mind closing #126829, #126904, #127180, #127185, #127282 with your libqt2 upload? These are all KDE/png related bugs which should be solved by linking (again) libqt2 with libpng2. Actually, closing only one of these ought to be enough (they are all merged). Phil.
Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]
Daniel Stone <[EMAIL PROTECTED]> writes: > On Wed, Jan 09, 2002 at 10:07:13AM +0900, Junichi Uekawa wrote: > > Daniel Stone <[EMAIL PROTECTED]> cum veritate scripsit: > > > > > > It's only the -dev package, which is only required > > > > for the compile time, and I believe it is quite small, only > > > > with the symlinks and the static link files... > > > > > > > > Or better, libqt2-dev depend on libpng2-dev. > > > > > > They generally Build-Depend on libpng2-dev, I believe. > > > > If libqt-dev depends on libpng2-dev, and libpng2-dev > > conflicts with libpng3-dev, whic is the case, > > any package build-depending on libqt-dev AND libpng3-dev > > will not build, which is probably the thing > > we want. Isn't it? > > Right. No it is not the case. Libpng-dev provides libpng2-dev (both are source-compatible). Libqt-dev should depend on libpng2-dev (<<1.2.0). That should work. Phil.
Re: Do not link GNOME apps with libpng3
"Steve M. Robbins" <[EMAIL PROTECTED]> writes: > On Wed, Jan 09, 2002 at 03:23:25PM +0100, Christian Marillat wrote: > > >> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes: > > > > > On Wed, Jan 09, 2002 at 03:09:08PM +0100, Christian Marillat wrote: > > > > [...] > > > > >> I really want to know why recompiling gdk-imlib1 is too hard ? > > > > > Recompiling isn't hard. Managing the transition is hard. Did you > > > read the threads in debian-devel and debian-kde? Do you have a solution > > > to managing the transition? > > > > Yes I've read the thread in -devel. For Gnome we only need to recompile > > your package and dgk-pixbuf. > > You think only two packages need recompiling? I can only conclude > that, while you may have read the thread, you did not understand it. [EMAIL PROTECTED] egrep '^Depends:.*libpng' /var/lib/dpkg/available | wc -l 377 [EMAIL PROTECTED] egrep '^Depends:.*gdk-imlib1' /var/lib/dpkg/available | wc -l 254 [EMAIL PROTECTED] egrep '^Depends:.*gdk-imlib1' /var/lib/dpkg/available |egrep '^Depends:.*libpng' | wc -l 24 It would be at most 24 packages. > The best summary (in my humble opinion) is > > > http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg00243.html > > The main conclusion is this: if imlib1 (and gdk-imlib1) change their linkage > from libpng2 to libpng3, then ANY APPLICATION THAT LINKS WITH ONE OF THOSE > AND ALSO WITH LIBPNG NEEDS TO BE RECOMPILED. That's a whole lot more than > two packages. 24 at most. 8< snip >8 > P.S. Just for the record: what specifically are the benefits to > recompiling everything with libpng3? What are the benefits of recompiling eveything with libc6? ;-) Phil.
Re: Problem compiling module
Jeff McWilliams <[EMAIL PROTECTED]> writes: > Help. I've been trying to compile the lm_sensors source without much > success. lm_sensors was written as a linux module that talks to the > voltage and temperature sensors on a motherboard and lets you query > /proc/sensors to view this information. I haven't found a .deb for > this so I fetched the latest source yesterday and started trying toc > compile it. I'm running debian 2.0, Kernel 2.0.34 and the standard > debian gcc, make, and libc6-dev packages. > > Make works okay, but... > > insmod ./lm_sensors.o > > ... tells me that the module was compiled for kernel 2.0.33 which > doesn't match my running kernel. > > /usr/doc/libc6-dev/FAQ.Debian.gz suggests adding > -I/usr/src/linux/include > > I added that to the CFLAGS of the Makefile. It didn't help. I > noticed that /usr/src/linux/include/linux does not contain a version.h > file. Is that correct? 8< snip You have to use -I/usr/src/linux/include *and* also configure and build a kernel there to have version.h created plus a couple of other symlinks. Be warned that you should run the kernel you've built because of potential binary incompatibilities in the kernel depending which options you've compiled in. Kernel-package is your friend. Phil.
rpc.fakelockd available for Solaris/Linux NFS
I've been struggling with this for a couple of days, so I wanted to share my solution... * The story: If one mounts a NFS directory on a Solaris box, then Solaris just _assumes_ that there's an rpc.lockd sitting on the other side. Linux 2.0 NFS implementation doesn't come with the NLM protocol (lockd) (2.1 has it). Sooo, whenever a Solaris program locks a portion of a file on a Linux-exported NFS share, the program hangs waiting for an answer from a lockd on the Linux side which isn't there. Just for the pleasure of ranting against Sun, this assumes you can get NFS to work reliably between Linux and Solaris. Sun doesn't seem to be able to (or want to) have a proper NFS implementation. Hint: when mounting Linux on Solaris, use -o proto=udp,vers=2. when mounting Solaris on Linux, use -o udp,nfsvers=2,noac. * The solutions: 1) Use kernel 2.1. 2) Don't do this. 3) Kill lockd on Solaris (then you loose Solaris-Solaris locking) 4) Complain to Sun (good luck) 5) Use an old (and very buggy) server-side only lockd (from ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/dontuse/OLD/lockd-0.4a.tar.gz). 6) Have a dummy rpc.lockd on Linux. * The software: Well, on ftp.fifi.org:/pub/phil/rpc.fakelockd.tgz you'll find a dummy lockd daemon that will basically grant any lock on any file. It honors all _synchronous_ NLM requests. It declines all asynchronous requests (and logs them crudely to syslog). It doesn't support NLM v3 requests (and logs them too). It doesn't come with a dummy SM (statd) daemon either (but I don't think it's necessary). That should save you some hair if you have to work with Solaris. Phil.
Re: freetype1 is gone from slink, imagemagick still depends on it
"Scott K. Ellis" <[EMAIL PROTECTED]> writes: > > On Wed, Sep 30, 1998 at 07:14:20PM -0700, Ben Gertzfield wrote: > > I'm a little confused. freetype2-dev conflicts with freetype1 (<= > > 1.0.0.1998-03-22-1) yet freetype1 is nowhere to be found in slink, > > and the latest version in hamm is 1.0.0.1998-03-22-1. > > > > What happened to freetype1? imagemagick depends on it still, but it no > > longer exists in slink. Should imagemagick be recompiled? > > freetype1 is still in hamm. ImageMagick should probably be recompiled, as > well as updated to the latest version. I am however, currently stuck with a > modem connection and a slow computer. If anyone wants to do a NMU (or for > that matter, adopt imagemagick), they are welcome to it. I'll adopt (back) Imagemagick then. I used to be the initial packager and maintainer, but I lacked time to to work on it for a while. Since I've got more free time now, I'll take it back. Will try to do an upload before the freeze. Phil.
