Re: [gentoo-user] Where are the suspend2 options in suspend2-sources-2.6.14-r1-3
Thank you for your answer. I have ht activated. Does someone know why this behaviour occurs? Uwe Iain Buchanan wrote: On Thu, 2005-11-24 at 09:17 +0100, Uwe Klosa wrote: Hi When I updrade my kernel from suspend2-sources-2.6.14 to -r1 or r3 all options for SUSPEND2 are gone. I have tried with make oldconfig and make menuconfig. Is there a purpose behind that? I'm not sure on the exact version it happened (I don't use suspend2-sources, I patch vanilla-sources) but if you have a HyperThreaded CPU, for some reason suspend to disk is now disabled when you select HT. This wasn't always the case - I used to have suspend2 and HT both working together nicely. Check CONFIG_X86_HT (I think) HTH, begin:vcard fn:Uwe Klosa n:Klosa;Uwe org:Uppsala University;Electronic Publishing Centre adr:;;;Uppsala;;75120;Sweden email;internet:[EMAIL PROTECTED] tel;work:+46 (0)18 471 7658 url:http://publications.uu.se/epcentre version:2.1 end:vcard
Re: [gentoo-user] C compiler cannot create executables [SOLVED]
Michael Sullivan wrote: I downloaded the stage 3 tarball and found the files I need and copied them over. It worked. I'm in the process of emergine --emptytree binutils and gcc atm... That works, but I would have attempted playing with binutils-config first. -- [Name ] :: [Matan I. Peled] [Location ] :: [Israel] [Public Key] :: [0xD6F42CA5] [Keyserver ] :: [keyserver.kjsl.com] encrypted/signed plain text preferred -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] system clock keeps getting reset to weird times
On Thu, Nov 24, 2005 at 11:48:23PM +0100, Benno Schulenberg wrote: Charles Trois wrote: ~ # ls -l /etc/localtime lrwxrwxrwx 1 root root 32 Nov 22 20:39 /etc/localtime - /usr/share/zoneinfo/Europe/Paris and in /etc/conf.d/clock: CLOCK=local Did you maybe change this last one after your last reboot? Because then the system time won't have changed accordingly. Do a 'hwclock -hctosys' to set the system time from the hardware clock. What else can I check? Is the clock initscript run? Check with 'rc-update -s'. If it is, try removing it from the startup sequence, see if that solves it. Is date maybe aliased? Check with 'type date'. Benno -- gentoo-user@gentoo.org mailing list Hi Not ideal but as a workaround should your investigation not go well you could install an NTP type client. I would recommenf chronyd as a simple way of doing this, worked a treat when I had a similar issue a few monthes ago. stu -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Problems with arts
On Fri, 25 Nov 2005 04:53:39 +, Peter Ruskin wrote: http://distfiles.gentoo.org/distfiles/arts-1.5.0.tar.bz2 = `/usr/portage/distfiles/arts-1.5.0.tar.bz2' Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ... Connecting to distfiles.gentoo.org|64.50.238 .52|:80... connected. HTTP request sent, awaiting response... 404 Not Found 07:52:27 ERROR 404: Not Found. That's because none of the KDE-3.5.0 stuff has been released yet. You can download the tarballs directly from the 3.5.0-rc2 directory of the KDE FTP site and put them in $DISTDIR. I did this a couple of days ago and have 3.5.0 (RC2) running well on two machines. -- Neil Bothwick I am Scooby Doo of Borg- Reware roo re arimorated, Raggy! signature.asc Description: PGP signature
[gentoo-user] Home Network Printing
Hi All, I am sure that this is an easy thing to achieve, but for some reason I seem to fail to get it going. Probably because I do not completely understand the logic. The setup is as follows: I have two boxen, hostname1.STUDY and hostname2.STUDY. hostname2 has the printer connected to it via parallel port. The printer's name is Compaq-HP. Hostname2 can print locally without a hitch. I created a new printer on hostname1 and also named it Compaq-HP. I set the ipp address to ipp://hostname2.STUDY/ipp but I kept getting errors telling me it can't resolve the address. So I changed it to the LAN ip address (ipp://192.163.0.3/ipp)and it seems that it can now connect, but it cannot find the printer: = I [21/Nov/2005:21:55:47 +] [Job 44] Connecting to 192.168.0.3 on port 631... I [21/Nov/2005:21:55:47 +] [Job 44] Connected to 192.168.0.3... D [21/Nov/2005:21:55:47 +] [Job 44] Getting supported attributes... E [21/Nov/2005:21:55:47 +] [Job 44] Destination printer does not exist! E [21/Nov/2005:21:55:49 +] PID 15530 stopped with status 1! = lpstats shows both printers (local and remote): = $ lpstat -t scheduler is running system default destination: Compaq-HP device for Compaq-HP: ipp://192.168.0.3/ipp device for DeskJet-930C: parallel:/dev/lp0 Compaq-HP accepting requests since Jan 01 00:00 DeskJet-930C accepting requests since Jan 01 00:00 printer Compaq-HP is idle. enabled since Jan 01 00:00 printer DeskJet-930C disabled since Jan 01 00:00 - Paused = Would you know why it can't resolve hostname2.STUDY? Am I meant to add the printer name on the ipp://192.168.0.3/ipp? Regards, -- Mick -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How serious is revdep-rebuild failure
Harry Putnam wrote: Someone once advised me to run this command after sync and update world. [...] Assigning files to ebuilds... using existing /root/.revdep-rebuild.4_ebuilds. Evaluating package order... using existing /root/.revdep-rebuild.5_order. ^^^using existing^^^ means that you are using the results from an older run of revdep-rebuild. First remove all .revdep* files and the run it again and see if you find the same errors. -- Naga -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] nvidia-kernel does not load in 2.6.14-gentoo-r2 (unknown symbols)
On Thu, 2005-11-24 at 18:14 +, Neil Bothwick wrote: On Thu, 24 Nov 2005 15:41:17 +0100, Jules Colding wrote: But I double-checked anyway and nvidia still has unknown symbols in the latest kernel. I have attached the emerge output from the nvidia build and the emerge info from that session too. You're trying to install an old version of the nVidia drivers. The latest version, which is still over three months old, is 1.0.7676. This one runs perfectly with 2.6.14v on my AMD64 system. OK, that might fix it for me. Why do the nvidia ebuilds take so long to be marked stable? Good question. I am using the latest stable version exactly because I assume that they would have the best chance of working. Finding that the latest version doesn't even load into the newest stable kernel is kind of disappointing. -- jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Home Network Printing
On Friday 25 November 2005 12:14, Michael Kintzios wrote: Hi All, I am sure that this is an easy thing to achieve, but for some reason I seem to fail to get it going. Probably because I do not completely understand the logic. The setup is as follows: I have two boxen, hostname1.STUDY and hostname2.STUDY. hostname2 has the printer connected to it via parallel port. The printer's name is Compaq-HP. Hostname2 can print locally without a hitch. I created a new printer on hostname1 and also named it Compaq-HP. I set the ipp address to ipp://hostname2.STUDY/ipp but I kept getting errors telling me it can't resolve the address. So I changed it to the LAN ip address (ipp://192.163.0.3/ipp)and it seems that it can now connect, but it cannot find the printer: = I [21/Nov/2005:21:55:47 +] [Job 44] Connecting to 192.168.0.3 on port 631... I [21/Nov/2005:21:55:47 +] [Job 44] Connected to 192.168.0.3... D [21/Nov/2005:21:55:47 +] [Job 44] Getting supported attributes... E [21/Nov/2005:21:55:47 +] [Job 44] Destination printer does not exist! E [21/Nov/2005:21:55:49 +] PID 15530 stopped with status 1! = lpstats shows both printers (local and remote): = $ lpstat -t scheduler is running system default destination: Compaq-HP device for Compaq-HP: ipp://192.168.0.3/ipp device for DeskJet-930C: parallel:/dev/lp0 Compaq-HP accepting requests since Jan 01 00:00 DeskJet-930C accepting requests since Jan 01 00:00 printer Compaq-HP is idle. enabled since Jan 01 00:00 printer DeskJet-930C disabled since Jan 01 00:00 - Paused = Would you know why it can't resolve hostname2.STUDY? Am I meant to add the printer name on the ipp://192.168.0.3/ipp? Regards, -- Mick maybe adding 192.168.0.3 hostname2.STUDY to /etc/hosts would help just guessing, planning to put old ibm pentium (200Mhz) to do the firewall, router and printer server job martins -- Linux 2.6.15-rc2 AMD Athlon(tm) 64 Processor 3200+ 12:33:12 up 4:23, 4 users, load average: 0.00, 0.00, 0.00 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Home Network Printing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Kintzios wrote: I created a new printer on hostname1 and also named it Compaq-HP. I set the ipp address to ipp://hostname2.STUDY/ipp but I kept getting errors telling me it can't resolve the address. AFAIR the IPP-Adress has to be: ipp://[Host]/[PrinterName] in your case this would mean: ipp://hostname2.STUDY/Compaq-HP Would you know why it can't resolve hostname2.STUDY? Am I meant to add the printer name on the ipp://192.168.0.3/ipp? So... yes... :-) greets BeowulfOF - -- Oliver Beowulf Friedrich Quote the Raven Nevermore! - - E.A. Poe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDhu5TcZpid1GuHxcRAnISAKDc7s/pA5P/K5knza7WBeDVOxaWbwCfTN4O zCRipnOF5/I2iu9xsTyMM2U= =M0hC -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] Home Network Printing
-Original Message- From: Oliver Friedrich [mailto:[EMAIL PROTECTED] Sent: 25 November 2005 10:58 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Home Network Printing -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Kintzios wrote: I created a new printer on hostname1 and also named it Compaq-HP. I set the ipp address to ipp://hostname2.STUDY/ipp but I kept getting errors telling me it can't resolve the address. AFAIR the IPP-Adress has to be: ipp://[Host]/[PrinterName] in your case this would mean: ipp://hostname2.STUDY/Compaq-HP Would you know why it can't resolve hostname2.STUDY? Am I meant to add the printer name on the ipp://192.168.0.3/ipp? So... yes... :-) greets BeowulfOF Thanks, I'll give it another go when I get home! Regards, -- Mick -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Where are the suspend2 options in suspend2-sources-2.6.14-r1-3
On Fri, 2005-11-25 at 09:09 +0100, Uwe Klosa wrote: Iain Buchanan wrote: On Thu, 2005-11-24 at 09:17 +0100, Uwe Klosa wrote: When I updrade my kernel from suspend2-sources-2.6.14 to -r1 or r3 all options for SUSPEND2 are gone. I have tried with make oldconfig and make menuconfig. Is there a purpose behind that? I'm not sure on the exact version it happened (I don't use suspend2-sources, I patch vanilla-sources) but if you have a HyperThreaded CPU, for some reason suspend to disk is now disabled when you select HT. Thank you for your answer. I have ht activated. Does someone know why this behaviour occurs? Don't know. I hope it's not to do with some comments I made recently on a bug in kernel.org :) I'm curious: Did suspend and HT both work when you enabled them manually in the .config file? thanks, -- Iain Buchanan iaindb at netspace dot net dot au Why is the alphabet in that order? Is it because of that song? -- Steven Wright -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
Willie Wong wrote: On Thu, Nov 24, 2005 at 11:01:43AM -0800, glen martin wrote: Seems a truism, but you're right. apache isn't in my world file. somehow. And adding it to my world file does work around the symptom I describe. This begs the question of why it isn't there, considering it is installed. I must wonder, what else that I've installed has somehow not been added to the world file. Perhaps I'm exposing my ignorance, but is the world file not supposed to have everything that is installed and not in the base system definition? Under what circumstances (other than failed/aborted emerge, which didn't happen) could something fail to go into world? simple. Maybe you installed apache with 'emerge --oneshot' which doesn't modify the world file. Maybe apache was installed as a dependency of something else, and that something else has since got removed. Ok, so ignorance. :) I've tracked down what happened and offer it up as a lesson. I installed apache as a dependency of metadot. Metadot itself is masked by ~x86, so I did that install with ACCEPT_KEYWORDS=~x86 emerge metadot a syntax I picked up from a HOWTO or FAQ or article someplace. metadot was in the world file, but because it has no unmasked version, without ~x86 it has no dependencies. So apache was not required by anything else in the system. Indeed, depclean offered to remove it, despite the fact that it was in use, indeed was currently being used by an active service. On reflection, the right way to install metadot was not to use the syntax above, but probably instead to use /etc/portage/package.keywords to specify the ~x86 keyword for metadot permanently. Certainly post-install, setting this caused --newuse to correspond better to my expectations. Thanks again to those whose suggestions and comments helped in tracking this down. As an aside, I wonder whether it is a good feature idea that ACCEPT_KEYWORDS=keyword emerge foo without --oneshot should automatically add foo keyword to the package.keywords file. glen -- gentoo-user@gentoo.org mailing list
[gentoo-user] bad mouse
hi does anybody know how to fix mouse problem, it goes sometimes random actions. tried various drivers and best results has been with set to auto but today it gone realy wild. couldnt get to normal even killing xserver, just reboot did. there was no change in harware or configs. logs are full with rows like these: Nov 25 15:30:34 mar psmouse.c: bad data from KBC - bad parity Nov 25 15:30:34 mar psmouse.c: bad data from KBC - timeout Nov 25 15:30:35 mar psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. mouse model - A4 Tech SWOP-35 martins -- Linux 2.6.15-rc2 AMD Athlon(tm) 64 Processor 3200+ 16:27:57 up 1:49, 4 users, load average: 0.08, 0.20, 0.48 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
glen martin schreef: As an aside, I wonder whether it is a good feature idea that ACCEPT_KEYWORDS=keyword emerge foo without --oneshot should automatically add foo keyword to the package.keywords file. That's an idea with some merit, but imo not enough (merit) to make it feasible (but it's not my decision; submit a feature request and see what happens). You now know firsthand one of the many reasons that using ACCEPT_KEYWORDS on the command line is *not* recommended. It is a temporary setting, useful only for testing situations. The fact that if you use it, then decide to make the testing situation permanent but do not add a permanent setting (in package.keywords), you will encounter problems of this sort underlines the nature of the setting (temporary, temporary, use for explicit testing only; if you want a permanent setting, make one explicitly). The idea of having the temporary setting invisibly add a permanent setting seems cool, but undermines both the function of the temporary setting (since it's no longer truly temporary), and the function of the permanent setting (since you have not explicitly made the setting, you may or may not want it set), and what about dependencies? You'd have to unmask them explicitly (or else you'll get a lot of thus and so cannot be installed because thus and so is masked errors, and if you have to do that, you've already destroyed any usefulness an automatic addition might have had. So it's not something for me, but I'm weird ;-) ; others might feel differently. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
Holly Bostick wrote: glen martin schreef: As an aside, I wonder whether it is a good feature idea that ACCEPT_KEYWORDS=keyword emerge foo without --oneshot should automatically add foo keyword to the package.keywords file. That's an idea with some merit, but imo not enough (merit) to make it feasible (but it's not my decision; submit a feature request and see what happens). You now know firsthand one of the many reasons that using ACCEPT_KEYWORDS on the command line is *not* recommended. It is a temporary setting, useful only for testing situations. That makes sense. I hadn't encountered that recommendation at the time - I'd seen the ACCEPT_KEYWORDS syntax without such warning. Not in the man page, obviously, which has it right. The idea of having the temporary setting invisibly add a permanent setting seems cool, The trick here is the word 'temporary'. If 'temporary', the keyword --oneshot would (should?) be present. In absence thereof ... It seems analogous to the world file - the world file is the permanent specification, and it written per presence or absence of oneshot. Why not so for /etc/portage/package.*? How are those files different-in-kind from world? I don't know. I am far from an expert at the design philosophy behind these tools. I just note that there seem to be failures of consistency in application (or not) of a flag across different situations. Permanence for one setting is accomplished with a flag (well, absence), permanence for another requires a file change and the flag is ignored. Or there's a failure in my understanding, which I've found to be very well served by saying the wrong things and waiting for stones. So it's not something for me, but I'm weird ;-) I am too. Without the smiley. Or so is frequently said. glen -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
glen martin schreef: Holly Bostick wrote: glen martin schreef: As an aside, I wonder whether it is a good feature idea that ACCEPT_KEYWORDS=keyword emerge foo without --oneshot should automatically add foo keyword to the package.keywords file. That's an idea with some merit, but imo not enough (merit) to make it feasible (but it's not my decision; submit a feature request and see what happens). You now know firsthand one of the many reasons that using ACCEPT_KEYWORDS on the command line is *not* recommended. It is a temporary setting, useful only for testing situations. That makes sense. I hadn't encountered that recommendation at the time - I'd seen the ACCEPT_KEYWORDS syntax without such warning. Not in the man page, obviously, which has it right. The idea of having the temporary setting invisibly add a permanent setting seems cool, The trick here is the word 'temporary'. If 'temporary', the keyword --oneshot would (should?) be present. In absence thereof ... It seems analogous to the world file - the world file is the permanent specification, and it written per presence or absence of oneshot. Why not so for /etc/portage/package.*? How are those files different-in-kind from world? OK, I'm not an expert either, but I *think* that the issue is the fact that ACCEPT_KEYWORDS and emerge are *two separate commands*. Are you familiar with exporting variables? ACCEPT_KEYWORDS is, of course a variable. When you export a variable (DISPLAY, LD_ASSUME_KERNEL, LD_LIBRARY_PATH, LD_PRELOAD, PS1, ACCEPT_KEYWORDS), the variable is changed for the current login shell session, but is not persistent. Period. That has nothing to do with Portage or any program, that's how Linux works. Variables are permanently set in configuration files (in the case of ACCEPT_KEYWORDS, in /etc/make.conf, with modifications allowed from /etc/portage/package.keywords). Most of the time, the temporary nature of this change can be assumed without thinking-- if the startup script for Neverwinter Nights includes an export LD_LIBRARY_PATH=./lib:./miles:$LD_LIBRARY_PATH command, the fact that it's temporary doesn't matter, because it only needs to be in effect while I'm running Neverwinter Nights, which is a temporary condition. This is completely different from the state of the Portage tree and your world file when running emerge. Basically, when you use ACCEPT_KEYWORDS on the command line, you are changing a variable temporarily, which Portage then reads, but because the condition does not persist-- and the state of Portage variables must persist across sessions-- you're essentially confusing Portage, which must rely on you to have a stable list of variable conditions in order for it to know what it's doing. This is not a flaw in Portage, it's just how it's constructed, and it really couldn't be constructed any better than it is-- it already does a lot more than one might have thought possible in terms of being flexible and 'pushing the envelope'. But the conditions of the environment must be respected. There is no way for Portage to become aware that you exported a variable prior to running the emerge command, and so there is no way for Portage to automatically add the --oneshot switch if you had done so, in the same way that --update implies --pretend or whichever switch it is that implies another, so the second switch is automatically added if the first is present. Because (export) ACCEPT_KEYWORDS is not part of the emerge command, and the emerge command can only adjust itself, based on its own settings, not other settings that you have manually adjusted prior to running the command. If you see what I mean. Anyway, I could be totally wrong, but I think it hangs together, and I suspect it is in fact the case. Perhaps it could be better explained to people, though, so that they understood the relationship between the variables that Portage is reading and the commands that one might run to modify them. Of course, a good thorough grounding in shell operations would take care of that, too, I suppose Holly -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Richard Fish [EMAIL PROTECTED] writes: Interesting. All 3 builds currently in portage (1.6.2-r4, 1.8.0, and 1.8.0-r1) use toolchain-funcs already. What is the result of First let me add that (mjpegtools-1.6.2-r3) isn't even installed: root # qpkg -v -I |grep mjpegtools media-video/mjpegtools-1.8.0-r1 * ls /usr/portage/media-video/jpegtools/*.ebuild I'm guessing that is a typo and you meant mjpegtools ls /usr/portage/media-video/mjpegtools/*.ebuild /usr/portage/media-video/mjpegtools/mjpegtools-1.6.2-r4.ebuild /usr/portage/media-video/mjpegtools/mjpegtools-1.8.0-r1.ebuild /usr/portage/media-video/mjpegtools/mjpegtools-1.8.0.ebuild equery depends mjpegtools equery depends mjpegtools [ Searching for packages depending on mjpegtools... ] media-video/transcode-0.6.14-r2 media-video/cinelerra-cvs-20050801 both are installed here: # qpkg -v -I |grep 'transcode\|cinelerra' media-video/transcode-0.6.14-r2 * media-video/cinelerra-cvs-20050801 * -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Richard Fish [EMAIL PROTECTED] writes: [...] Also, do you have anything for mjpegtools in /etc/portage/package.mask? ls /etc/portage/ package.keywords package.use profile/ sets/ -- gentoo-user@gentoo.org mailing list
[gentoo-user] dovecot problem
I'm having a problem with dovecot. I upgraded dovecot yesterday to 0.99.14-r1, although dovecot --version still claims to be 0.99.14 Here's the info: bullet ~ # /etc/init.d/dovecot start * Starting dovecot ... * [ ok ]bullet ~ # /etc/init.d/dovecot status * status: started bullet ~ # ps ax | grep 'dovecot' 10223 pts/1S+ 0:00 grep dovecot bullet ~ # netstat | grep '143' bullet ~ # /etc/init.d/dovecot stop * Stopping dovecot ... * [ !! ] I checked the logs for recent occurrences of dovecot and this is all I found: Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe I don't know how to fix a broken pipe. Any advice? espersunited.com addresses are still receiving mail, but in order to actually read it we have to sshell over to bullet and use mutt, which is somewhat inconvenient as our users are more accustomed to GUI mail clients... -Michael Sullivan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: First let me add that (mjpegtools-1.6.2-r3) isn't even installed: root # qpkg -v -I |grep mjpegtools media-video/mjpegtools-1.8.0-r1 * equery depends mjpegtools [ Searching for packages depending on mjpegtools... ] media-video/transcode-0.6.14-r2 media-video/cinelerra-cvs-20050801 both are installed here: # qpkg -v -I |grep 'transcode\|cinelerra' media-video/transcode-0.6.14-r2 * media-video/cinelerra-cvs-20050801 * This seems odd: Runtime Dependencies transcode-0.6.14-r2 media-libs/libexif media-libs/netpbm | = media-video/ffmpeg - 0.4.9_pre1 a52 = media-libs/a52dec - 0.7.4 avi = media-video/avifile - 0.7.41.20041001 dv = media-libs/libdv - 0.99 dvdread = media-libs/libdvdread - 0.9.0 encode = media-sound/lame - 3.93 fame = media-libs/libfame - 0.9.1 gtk = x11-libs/gtk+ - 1.2* imagemagick = media-gfx/imagemagick - 5.5.6.0 jpeg media-libs/jpeg lzo = dev-libs/lzo - 1.08 mjpeg = media-video/mjpegtools - 1.6.2-r3 mpeg media-libs/libmpeg3 ogg media-libs/libogg pvm = sys-cluster/pvm - 3.4 quicktime = media-libs/libquicktime - 0.9.3 sdl media-libs/libsdl theora media-libs/libtheora truetype = media-libs/freetype - 2 vorbis media-libs/libvorbis xvid = media-libs/xvid - 1.0.2 X virtual/x11 Runtime Dependencies cinelerra-cvs-20050801 media-libs/faad2 media-libs/libdv | = media-libs/libogg - 1.0 media-libs/libpng | = media-libs/libtheora - 1.0_alpha4-r1 | = media-libs/libvorbis - 1.0.1-r2 | = media-libs/openexr - 1.2.1 | = media-sound/esound - 0.2.34 ! media-video/cinelerra - ! media-video/cinelerra - media-video/mjpegtools | = sys-libs/libavc1394 - 0.4.1 |= sys-libs/libraw1394 - 0.9.0 virtual/x11 What seems odd to me is that neither of these two programs depends on that specific version of mpegtools. Transcode will take that version or above, cinelerra doesn't care. And, since you have a greater version installed, there seems to be no reason that revdep-rebuild should be trying to install an older version in this way. The highest likelihood is that-- as previously suggested-- you're running an old output from revdep-rebuild -p (when this version was the installed version of mjpegtools), and did not delete the old output files and re-run revdep-rebuild -p to get a new prospective rebuild list. You might want to check your /root/ folder and see what the dates on those .revdep-rebuild files is. If they aren't from a recent time, remove them, and run revdep-rebuild (-p) again. Alternatively (hacky solution), try re-emerging cinelerra and transcode again (to retrain them in where their dependent files are and what version they are). Even more hackily, remove mjpegtools totaly (unmerge), then do an emerge -uaDtv world, and let it get pulled back in as a dependency of the two packages that need it. That ought to straighten everything out. But probably you're just using old revdep-rebuild output, and the easiest solution would be to delete those files so that revdep-rebuild can update itself with the current state of your system. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] dovecot problem
[EMAIL PROTECTED] schreef: I'm having a problem with dovecot. I upgraded dovecot yesterday to 0.99.14-r1, although dovecot --version still claims to be 0.99.14 I don't know how to fix your problem (sorry); just wanted to mention that the reason that the version is still claimed to be 0.99.14 is because it *is* 0.99.14-- usually revisions (-r#) relate to the *ebuild* being revised, not the program. If the program is itself revised, upstream changes the version number most of the time; for example to 0.99.15, indicating a relatively minor release update. This is a good thing, because if the source has changed, you will then have to download a new tarball due to the new release number, whereas if Gentoo revised an updated tarball with an -r1, you would probably miss the changes, because the old tarball would still be in /distfiles/ and Portage would not think it had to download a new one. Good luck with solving the issue with the program itself. Holly -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Richard Fish [EMAIL PROTECTED] writes: (Including Richard in reply as well) Nagatoro [EMAIL PROTECTED] writes: [...] Assigning files to ebuilds... using existing /root/.revdep-rebuild.4_ebuilds. Evaluating package order... using existing Nagatoro replied: ^^^using existing^^^ means that you are using the results from an older run of revdep-rebuild. First remove all .revdep* files and the run it again and see if you find the same errors. Harry responds: Ack, yes of course and it even warns you about that However having removed them I still get a huge list of stuff listed as BROKEN One of the first involves the same mjpeg package that isn't even installed: broken /usr/bin/cinelerra (requires libmjpegutils-1.6.so.0) == Full output of revdep-rebuild (minus all config make stuff [sorry about control chars I forgot to use -nc but have removed some]): Note it doesn't appear to say what pkg actually failed: Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild.. emerge --oneshot =dev-php/mod_php-4.4.0 =dev-php/php-4.4.0 =media-libs/imlib-1.9.14-r3 =kde-base/kdegraphics-3.4.1-r1 =media-gfx/imagemagick-6.2.5.4 =media-libs/libdv-0.102 =media-video/avifile-0.7.41.20041001-r1 =media-video/cinelerra-cvs-20050801 =media-video/transcode-0.6.14-r2 =net-libs/libwww-5.4.0-r3 ^G.^G.^G.^G.^G.^G.^G.^G.^G.^G. --8 [big snip] you have the following choices: - if emerge failed during the build, fix the problems and re-run revdep-rebuild or - use -X or --package-names as first argument (trys to rebuild package, not exact ebuild) or - set ACCEPT_KEYWORDS=~your platform and/or /etc/portage/package.unmask (and remove /root/.revdep-rebuild.5_order to be evaluated again) or - modify the above emerge command and run it manually or - compile or unmerge unsatisfied packages manually, remove temporary files and try again (you can edit package/ebuild list first) To remove temporary files, please run: rm /root/.revdep-rebuild*.?_* -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Holly Bostick [EMAIL PROTECTED] writes: Harry Putnam schreef: First let me add that (mjpegtools-1.6.2-r3) isn't even installed: root # qpkg -v -I |grep mjpegtools media-video/mjpegtools-1.8.0-r1 * [...] Holly says: But probably you're just using old revdep-rebuild output, and the easiest solution would be to delete those files so that revdep-rebuild can update itself with the current state of your system. Holly, Thanks for the suggestions they are noted, but waiting to hear from other posters too. It turn out that using old revdep output was not the problem. See just posted output in response to Nagatoro. -- gentoo-user@gentoo.org mailing list
[gentoo-user] autoexpect?
Hi, I would like to write a script to log in to a network machine and run halt (for the missus, who doesn't really like logging in via ssh just to turn of the internet connection...), and saw that autoexpect looks like it would fit the bill. It doesn't seem to be in portage and it seems a lot more difficult with expect... Any ideas? Cheers Antoine -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] autoexpect?
Hello, If you create a private-public pair with ssh-keygen you can access to the other machine without a password. Then your script would call ssh and probably sudo /sbin/poweroff as a parameter to halt the remote machine. On 11/25/05, Antoine [EMAIL PROTECTED] wrote: Hi, I would like to write a script to log in to a network machine and run halt (for the missus, who doesn't really like logging in via ssh just to turn of the internet connection...), and saw that autoexpect looks like it would fit the bill. It doesn't seem to be in portage and it seems a lot more difficult with expect... Any ideas? Cheers Antoine -- gentoo-user@gentoo.org mailing list -- Andres Becerra Sandoval -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] autoexpect?
On Fri, 2005-11-25 at 19:44 +0100, Antoine wrote: Hi, I would like to write a script to log in to a network machine and run halt (for the missus, who doesn't really like logging in via ssh just to turn of the internet connection...), and saw that autoexpect looks like it would fit the bill. It doesn't seem to be in portage and it seems a lot more difficult with expect... Any ideas? Cheers Antoine Hi, I haven't used autoexpect but have Expect. Here is a link that you may have seen but will do what you would expect...pardon the pun. Perl with Expect module or Just Expect on its own. http://www.infocopter.com/perl_corner/expect.htm Hope this helps, Rob signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: Richard Fish [EMAIL PROTECTED] writes: (Including Richard in reply as well) Nagatoro [EMAIL PROTECTED] writes: [...] Assigning files to ebuilds... using existing /root/.revdep-rebuild.4_ebuilds. Evaluating package order... using existing Nagatoro replied: ^^^using existing^^^ means that you are using the results from an older run of revdep-rebuild. First remove all .revdep* files and the run it again and see if you find the same errors. Harry responds: Ack, yes of course and it even warns you about that However having removed them I still get a huge list of stuff listed as BROKEN Yes, well, that's what revdep-rebuild does-- finds broken stuff. It's doing its job-- what's the problem with that? One of the first involves the same mjpeg package that isn't even installed: broken /usr/bin/cinelerra (requires libmjpegutils-1.6.so.0) U--- why do you feel that this is the same package that isn't even installed? You said that you have libmjpegutils installed, just not the same version that was attempting to be rebuilt before 1.8.0 installed, rather than the 1.6.2-r3 that was attempting to be rebuilt). eix mjpegtools * media-video/mjpegtools Available versions: 1.6.2-r4 ~1.8.0 ~1.8.0-r1 Installed: 1.6.2-r4 Homepage:http://mjpeg.sourceforge.net/ Description: Tools for MJPEG video equery files media-video/mjpegtools [ Searching for packages matching media-video/mjpegtools... ] * Contents of media-video/mjpegtools-1.6.2-r4: /usr/lib/libmjpegutils-1.6.so.0 - libmjpegutils-1.6.so.0.2.2 Now, obviously this is not the same version of mjpegtools that you have, but what it indicates is that the file libmjpegutils-1.6.so.0 is a symlink to whatever version of the actual library is installed by the package. I rather expect that what would happen if I were to upgrade this package is that the symlink itself would remain, but the target of the symlink would change. If this is in fact the case, two points: 1: your symlink seems to be broken; 2: the error you have listed does not say anything about what version of mjpegtools is installed or broken, so revdep-rebuild is not necessarily talking about the same version as previously, But better to go to the source: == Full output of revdep-rebuild (minus all config make stuff [sorry about control chars I forgot to use -nc but have removed some]): Note it doesn't appear to say what pkg actually failed: Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild.. emerge --oneshot =dev-php/mod_php-4.4.0 =dev-php/php-4.4.0 =media-libs/imlib-1.9.14-r3 =kde-base/kdegraphics-3.4.1-r1 =media-gfx/imagemagick-6.2.5.4 =media-libs/libdv-0.102 =media-video/avifile-0.7.41.20041001-r1 =media-video/cinelerra-cvs-20050801 =media-video/transcode-0.6.14-r2 =net-libs/libwww-5.4.0-r3 ^G.^G.^G.^G.^G.^G.^G.^G.^G.^G. --8 [big snip] you have the following choices: - if emerge failed during the build, fix the problems and re-run revdep-rebuild So apparently the rebuild failed. But first of all, I don't see mjpegtools being rebuilt in this list, so that is not the problem apparently (the problem is not that mjpegtools is not installed, but that the programs that depend on it are not linked against it, which is what revdep-rebuild is trying to fix by re-emerging them); ... and second of all, which package failed to emerge and why? Meaning, what was the error in whichever package failed to emerge? Holly -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam [EMAIL PROTECTED] writes: Richard Fish [EMAIL PROTECTED] writes: (Including Richard in reply as well) Nagatoro [EMAIL PROTECTED] writes: [...] Assigning files to ebuilds... using existing /root/.revdep-rebuild.4_ebuilds. Evaluating package order... using existing Nagatoro replied: ^^^using existing^^^ means that you are using the results from an older run of revdep-rebuild. First remove all .revdep* files and the run it again and see if you find the same errors. Harry responds: Ack, yes of course and it even warns you about that However having removed them I still get a huge list of stuff listed as BROKEN One of the first involves the same mjpeg package that isn't even installed: broken /usr/bin/cinelerra (requires libmjpegutils-1.6.so.0) == Full output of revdep-rebuild (minus all config make stuff [sorry about control chars I forgot to use -nc but have removed some]): Oh crap.. overzealous snippage caused me to leave out the main stuff: or - compile or unmerge unsatisfied packages manually, remove temporary files and try again (you can edit package/ebuild list first) To remove temporary files, please run: rm /root/.revdep-rebuild*.?_* HOST:reader ~ root # ls -al total 1036 drwx-- 13 root root 4096 Nov 25 13:20 . drwxr-xr-x 25 root root 4096 Nov 24 21:38 .. -rw--- 1 root root 0 Sep 14 11:01 .ICEauthority -rw-r--r-- 1 root root175 Apr 8 2005 .NOTES lrwxrwxrwx 1 root root 24 Oct 27 07:06 .PATHS - /cvsb/reader/root/.PATHS -rw-r--r-- 1 root root605 Nov 23 19:13 .PATHS~ -rw--- 1 root root 0 Mar 29 2005 .Xauthority -rw--- 1 root root 116147 Nov 24 21:59 .bash_history lrwxrwxrwx 1 root root 31 Oct 27 07:06 .bash_profile - /cvsb/reader/root/.bash_profile -rw-r--r-- 1 root root426 Nov 16 23:26 .bash_profile~ lrwxrwxrwx 1 root root 25 Oct 27 07:06 .bashrc - /cvsb/reader/root/.bashrc -rw-r--r-- 1 root root 1487 Nov 24 00:04 .bashrc~ drwx-- 2 root root 4096 Mar 29 2005 .cache -rw--- 1 root root 59 Mar 23 2005 .cvspass -rw-r--r-- 1 root root438 Mar 23 2005 .dmemo -rw-r--r-- 1 root root 6591 Mar 28 2005 .emacs-custom -rw-r--r-- 1 root root140 Mar 30 2005 .emacs-places drwxr-xr-x 3 root root 4096 Nov 13 16:59 .emacs.d -rw-r--r-- 1 root root 0 Nov 17 09:09 .fonts.cache-1 drwx-- 2 root root 4096 Nov 23 13:26 .gconf drwxr-xr-x 2 root root 4096 Nov 23 13:26 .gconfd drwx-- 3 root root 4096 Nov 23 13:25 .gnome2 drwx-- 2 root root 4096 Nov 23 13:25 .gnome2_private -rw-r--r-- 1 root root249 Oct 30 20:28 .inputrc -rw-r--r-- 1 root root551 Oct 30 19:02 .inputrc~ -rw-r--r-- 1 root root 0 Aug 27 22:56 .keep -rw--- 1 root root 13171 Mar 31 2005 .lynxrc drwx-- 5 root root 4096 Oct 28 03:13 .maildir -rw--- 1 root root171 Nov 25 11:51 .mysql_history drwxr-xr-x 2 root root 4096 Apr 8 2005 .ncftp drwxr-xr-x 2 root root 4096 Mar 31 2005 .qt -rw-r--r-- 1 root root805 Nov 25 13:16 .revdep-rebuild.0_env -rw-r--r-- 1 root root 233236 Nov 25 13:16 .revdep-rebuild.1_files -rw-r--r-- 1 root root 13666 Nov 25 13:16 .revdep-rebuild.2_ldpath -rw-r--r-- 1 root root 1338 Nov 25 13:19 .revdep-rebuild.3_rebuild -rw-r--r-- 1 root root281 Nov 25 13:19 .revdep-rebuild.4_ebuilds -rw-r--r-- 1 root root281 Nov 25 13:19 .revdep-rebuild.5_order broken /usr/lib/libwwwtrans.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwutils.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwxml.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwzip.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libxmlparse.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libxmltok.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/Image/Magick/Magick.so (requires libMagick.so.6) broken /usr/lib/transcode/export_im.so (requires libMagick.so.6) broken /usr/lib/transcode/filter_compare.so (requires libMagick.so.6) broken /usr/lib/transcode/filter_logo.so (requires libMagick.so.6) broken /usr/lib/transcode/filter_logoaway.so (requires libMagick.so.6) broken /usr/lib/transcode/import_im.so (requires libMagick.so.6) broken /usr/lib/transcode/import_imlist.so (requires libMagick.so.6) done. (/root/.revdep-rebuild.3_rebuild) ^[[32;01mAssigning files to ebuilds...^[[0m done. (/root/.revdep-rebuild.4_ebuilds) ^[[32;01mEvaluating package order...^[[0m done. (/root/.revdep-rebuild.5_order) ^[[32;01mAll prepared. Starting rebuild...^[[0m emerge --oneshot =dev-php/mod_php-4.4.0 =dev-php/php-4.4.0 =media-libs/imlib-1.9.14-r3 =kde-base/kdegraphics-3.4.1-r1 =media-gfx/imagemagick-6.2.5.4 =media-libs/libdv-0.102 =media-video/avifile-0.7.41.20041001-r1 =media-video/cinelerra-cvs-20050801
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote: It turn out that using old revdep output was not the problem. See just posted output in response to Nagatoro. Actually it was. Notice that revdep-rebuild is no longer trying to rebuild mjpegtools, but those things that depend upon mjpegtools (along with other broken packages). So, what package is actually failing to merge, and what is the error message that is being given? -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
On Fri, 25 Nov 2005 06:16:40 -0800, glen martin wrote: As an aside, I wonder whether it is a good feature idea that ACCEPT_KEYWORDS=keyword emerge foo without --oneshot should automatically add foo keyword to the package.keywords file. It's a bad idea. Specifying a setting on the command line is temporary, and is useful when used as such. Making a setting the user intends to be temporary permanent is a recipe for disaster. -- Neil Bothwick I couldn't possibly be wrong. I use an error correcting modem! signature.asc Description: PGP signature
[gentoo-user] CyMotion keyboards
I think somebody on this list was looking for one of those new Cherry CyMotion Linux keyboards. There's a new seller on eBay that has them. http://cgi.ebay.com/Cherry-CyMotion-Master-Linux-Keyboard-Tuxs-Revenge_W0QQitemZ5834892820QQcategoryZ4706QQssPageNameZWDVWQQrdZ1QQcmdZViewItem Just in case whoever that was is still interested...NFI YMMV -Gary R -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] dovecot problem
On Fri, 25 Nov 2005 11:52:53 -0600, [EMAIL PROTECTED] wrote: I'm having a problem with dovecot. I upgraded dovecot yesterday to 0.99.14-r1, although dovecot --version still claims to be 0.99.14 Dovecot is version 0.99.14, the r1 refers to the ebuild revision. Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe What version of dovecot were you running before. There was a config file format change a while ago (on ~x86, I don't know when it affected stable). The source of the error looks familiar, did you update the config file after emerging the new version? -- Neil Bothwick KPLA Klingon Radio : All glory, all the time! signature.asc Description: PGP signature
[gentoo-user] Re: How serious is revdep-rebuild failure
Holly Bostick [EMAIL PROTECTED] writes: [...] Harry responds: Ack, yes of course and it even warns you about that However having removed them I still get a huge list of stuff listed as BROKEN Yes, well, that's what revdep-rebuild does-- finds broken stuff. It's doing its job-- what's the problem with that? I think you may have read into that something I didn't mean. The problem is that there is lots of broken stuff not that revdep finds it. I posted an incomplete output. It needed pruning alright but I pruned the wrong stuff. Just posted a better output. One of the first involves the same mjpeg package that isn't even installed: broken /usr/bin/cinelerra (requires libmjpegutils-1.6.so.0) U--- why do you feel that this is the same package that isn't even installed? You said that you have libmjpegutils installed, just not the same version that was attempting to be rebuilt before 1.8.0 installed, rather than the 1.6.2-r3 that was attempting to be rebuilt). So then isn't that a package that IS NOT installed. I mean a version difference is what makes a package a different package ... right? eix mjpegtools * media-video/mjpegtools Available versions: 1.6.2-r4 ~1.8.0 ~1.8.0-r1 Installed: 1.6.2-r4 Homepage:http://mjpeg.sourceforge.net/ Description: Tools for MJPEG video equery files media-video/mjpegtools [ Searching for packages matching media-video/mjpegtools... ] * Contents of media-video/mjpegtools-1.6.2-r4: /usr/lib/libmjpegutils-1.6.so.0 - libmjpegutils-1.6.so.0.2.2 Now, obviously this is not the same version of mjpegtools that you have, but what it indicates is that the file libmjpegutils-1.6.so.0 is a symlink to whatever version of the actual library is installed by the package. I rather expect that what would happen if I were to upgrade this package is that the symlink itself would remain, but the target of the symlink would change. If this is in fact the case, two points: 1: your symlink seems to be broken; 2: the error you have listed does not say anything about what version of mjpegtools is installed or broken, so revdep-rebuild is not necessarily talking about the same version as previously, But better to go to the source: == Full output of revdep-rebuild (minus all config make stuff [sorry about control chars I forgot to use -nc but have removed some]): Note it doesn't appear to say what pkg actually failed: Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild.. emerge --oneshot =dev-php/mod_php-4.4.0 =dev-php/php-4.4.0 =media-libs/imlib-1.9.14-r3 =kde-base/kdegraphics-3.4.1-r1 =media-gfx/imagemagick-6.2.5.4 =media-libs/libdv-0.102 =media-video/avifile-0.7.41.20041001-r1 =media-video/cinelerra-cvs-20050801 =media-video/transcode-0.6.14-r2 =net-libs/libwww-5.4.0-r3 ^G.^G.^G.^G.^G.^G.^G.^G.^G.^G. --8 [big snip] you have the following choices: - if emerge failed during the build, fix the problems and re-run revdep-rebuild So apparently the rebuild failed. But first of all, I don't see mjpegtools being rebuilt in this list, so that is not the problem apparently (the problem is not that mjpegtools is not installed, but that the programs that depend on it are not linked against it, which is what revdep-rebuild is trying to fix by re-emerging them); ... and second of all, which package failed to emerge and why? Meaning, what was the error in whichever package failed to emerge? I may have lost it or something but I made a cut and paste error on the above and have since posted a better output. I do have the entire output and should perhaps post it online. http://www.jtan.com/~reader/vu_txt/display.shtml Coming up shortly. (5min) -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam [EMAIL PROTECTED] writes: Oh crap.. overzealous snippage caused me to leave out the main stuff: I seem to have taken a moron pill this morning please see full output of revdep-rebuild in a few minutes at: http://www.jtan.com/~reader/vu_txt/display.shtml (in 5 min or so) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --newuse misses package that new USE affects
On 11/25/05, Holly Bostick [EMAIL PROTECTED] wrote: The idea of having the temporary setting invisibly add a permanent setting seems cool, but undermines both the function of the temporary setting (since it's no longer truly temporary), and the function of the permanent setting (since you have not explicitly made the setting, you may or may not want it set), and what about dependencies? Yes, I think the dependancy issue alone makes this an unworkable idea. There is a big difference between ACCEPT_KEYWORDS=~x86 emerge pkg and echo pkg ~x86 /etc/portage/package.keywords emerge pkg This is because the first will allow ~x86 for pkg and all of its dependancies, while the second only allows ~x86 for pkg (you would have to add additional entries for masked dependancies). IMO, the ACCEPT_KEYWORDS environment variable should only be used in combination with --pretend, where it can be used to give a list of the packages that you (might) need to add to package.keywords. Besides, Portage is designed to explicity allow environment variables to override configuration file settings, whether that be /etc/make.conf or /etc/portage/*. Modifying any configuration files based on environment variables would do away with the entire point of supporting the environment variables to begin with. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote: Harry Putnam [EMAIL PROTECTED] writes: Oh crap.. overzealous snippage caused me to leave out the main stuff: I seem to have taken a moron pill this morning please see full output of revdep-rebuild in a few minutes at: http://www.jtan.com/~reader/vu_txt/display.shtml (in 5 min or so) Ok, now we are going to need to see the output of emerge --info, because for some reason your toolchain thinks it is cross-compiling: checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) works... yes checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) is a cross-compiler... yes -Richard -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Holly Bostick [EMAIL PROTECTED] writes: [...] ... and second of all, which package failed to emerge and why? Meaning, what was the error in whichever package failed to emerge? Do I need to get the output of something else to determine that. Looking at the full ouput of revdep on a clean run I don't see what package is failing in the ouput. (now posted online here: http://www.jtan.com/~reader/vu_txt/display.shtml ) But maybe its just that I'm blind. -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam [EMAIL PROTECTED] writes: [...] I may have lost it or something but I made a cut and paste error on the above and have since posted a better output. I do have the entire output and should perhaps post it online. http://www.jtan.com/~reader/vu_txt/display.shtml Coming up shortly. (5min) I still don't see the actual error there and it was the output of: revdep-rebuild -nc 21|tee revdep.log revdep.log is what I posted online. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: I still don't see the actual error there and it was the output of: revdep-rebuild -nc 21|tee revdep.log revdep.log is what I posted online. Richard Fish replied with the specific issue about half an hour ago: Richard Fish schreef: Ok, now we are going to need to see the output of emerge --info, because for some reason your toolchain thinks it is cross-compiling: checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) works... yes checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) is a cross-compiler... yes The problem occurs with the very first compile configure: error: can not run test program while cross compiling ...done! | emerge (1 of 10) dev-php/mod_php-4.4.0 to / ... so the problem is definitely somewhere in your toolchain, rather than anything to do with either revdep-rebuild or the specific programs attempting to be rebuilt. Posting emerge info is a good starting point to troubleshoot this (unless you already happen to know why this is occurring, that's also possible). Holly -- gentoo-user@gentoo.org mailing list
Re: Re: [gentoo-user] Home Network Printing
From:: Oliver Friedrich [EMAIL PROTECTED] To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Home Network Printing Date: Fri, 25 Nov 2005 11:58:27 +0100 Michael Kintzios wrote: I created a new printer on hostname1 and also named it Compaq-HP. I set the ipp address to ipp://hostname2.STUDY/ipp but I kept getting errors telling me it can't resolve the address. AFAIR the IPP-Adress has to be: ipp://[Host]/[PrinterName] in your case this would mean: ipp://hostname2.STUDY/Compaq-HP I'm afraid I had no success. I tried using the address as you suggested above but it says unknown host . . . perhaps I should add it in my hostname file, but my netgear router which acts as the nameserver should know where to go? In any case, when I changed it to the IP address of hostname2 box (192.168.0.3) I got this: I [25/Nov/2005:20:23:13 +] [Job 56] Connecting to 192.168.0.3 on port 631... I [25/Nov/2005:20:23:13 +] [Job 56] Connected to 192.168.0.3... D [25/Nov/2005:20:23:13 +] [Job 56] Getting supported attributes... E [25/Nov/2005:20:23:13 +] [Job 56] Destination printer does not exist! E [25/Nov/2005:20:23:14 +] PID 13299 stopped with status 1! Anything else I should try? -- Regards, Mick Lycos email has now 300 Megabytes of free storage... Get it now at mail.lycos.co.uk
[gentoo-user] Re: How serious is revdep-rebuild failure
Richard Fish [EMAIL PROTECTED] writes: Ok, now we are going to need to see the output of emerge --info, because for some reason your toolchain thinks it is cross-compiling: There appears to be some confusion in that output as to what USE flags are in force. ACCEPT_KEYWORDS=x86 ~x86 I guess the last is what is used? I have in /etc/make.conf ACCEPT_KEYWORDS=~x86 This is because a few -u worls back (2 I think) I foolishly ran ACCEPT_KEYWORDS='~x86' emerges -v -u -D world And it seems more trouble to back out of that now than to just try to see if I (with help) can stay on top of it. Anyway, here is the output: == emerge -n -v --info 21|tee emergeInfo.log Gentoo Base System version 1.6.13 Portage 2.0.53_rc7 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r3, 2.6.14-gentoo-r2 i686) = System uname: 2.6.14-gentoo-r2 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox:1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS=x86 ~x86 AUTOCLEAN=yes CBUILD=i686-pc-linux-gnu CFLAGS=-O2 -march=pentium4 -fomit-frame-pointer CHOST=i686-pc-linux-gnu CONFIG_PROTECT=/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control CONFIG_PROTECT_MASK=/etc/gconf /etc/terminfo /etc/env.d CXXFLAGS=-O2 -march=pentium4 -fomit-frame-pointer DISTDIR=/usr/portage/distfiles FEATURES=autoconfig distlocks sandbox sfperms strict GENTOO_MIRRORS=http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo; MAKEOPTS=-j2 PKGDIR=/mnt/pack/gentoo/pkgiso/All PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage SYNC=rsync://rsync.gentoo.org/gentoo-portage USE=x86 X alsa apm arts audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl eds emboss encode esd exif expat fam ffmpeg foomaticdb fortran gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 idn imagemagick imlib ipv6 jpeg kde lcms ldap libg++ libwww mad mhash mikmod mng motif mozilla mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pcre pdflib perl png python qt quicktime readline samba sdl slang spell ssl symlink tcltk tcpd tiff truetype truetype-fonts type1-fonts vorbis xml2 xmms xv xvid zlib userland_GNU kernel_linux elibc_glibc Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY -- gentoo-user@gentoo.org mailing list
[gentoo-user] x11-base/xorg-x11-6.8.2-r6 emerge fails.
I believe its marked stable for x86... emerge results below. dsotm ~ # emerge -Nva x11 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] x11-base/xorg-x11-6.8.2-r6 [6.8.2-r4] -3dfx -3dnow +bitmap-fonts -cjk -debug -dlloader -dmx -doc -font-server -insecure-drivers -ipv6 -minimal +mmx -nls -nocxx +opengl +pam -sdk +sse -static +truetype-fonts +type1-fonts (-uclibc) -xprint +xv 0 kB Total size of downloads: 0 kB Do you want me to merge these packages? [Yes/No] yes emerge (1 of 1) x11-base/xorg-x11-6.8.2-r6 to / md5 files ;-) xorg-x11-6.8.2-r4.ebuild md5 files ;-) xorg-x11-6.8.2-r6.ebuild md5 files ;-) xorg-x11-7.0.0_rc1.ebuild md5 files ;-) xorg-x11-6.8.99.15-r4.ebuild md5 files ;-) xorg-x11-7.0.0_rc2.ebuild md5 files ;-) files/digest-xorg-x11-7.0.0_rc1 md5 files ;-) files/digest-xorg-x11-7.0.0_rc2 md5 files ;-) files/digest-xorg-x11-6.8.2-r4 md5 files ;-) files/digest-xorg-x11-6.8.2-r6 md5 files ;-) files/digest-xorg-x11-6.8.99.15-r4 md5 src_uri ;-) eurofonts-X11.tar.bz2 md5 src_uri ;-) gentoo-cursors-tad-0.3.1.tar.bz2 md5 src_uri ;-) xorg-x11-6.8.2-files-0.8.tar.bz2 md5 src_uri ;-) xorg-x11-6.8.2-patches-0.1.13.tar.bz2 md5 src_uri ;-) X11R6.8.2-src.tar.bz2 x11-base/xorg-x11-6.8.2-r4 * Previous xorg-x11 installation detected. * Enabling PAM features in xorg-x11. Unpacking source... * Unpacking 6.8.2 source ... [ ok ] * Unpacking Gentoo files and patches ... [ ok ] * Unpacking Gentoo cursors ...[ ok ] * Unpacking fonts ... [ ok ] * Excluding patches... * 9990_x86_6.8.0-nvxbox-20050107.patch ... [ ok ] * 9991_x86_6.8.1.904-xbox-pci-20050207.patch ...[ ok ] * 7500_all_4.0.1-s390-nohardware.patch ... [ ok ] * 5851_all_6.7.99.1-tdfx-dri-fix-low-texmem-hang.patch ... [ ok ]QA Notice: USE Flag 'elibc_FreeBSD' not in IUSE for x11-base/xorg-x11-6.8.2-r6 QA Notice: USE Flag 'elibc_OpenBSD' not in IUSE for x11-base/xorg-x11-6.8.2-r6 * Done excluding patches. * Applying various patches (bugfixes/updates) ... * 0119_all_exports-lib-v2.patch ... [ ok ] * 0124_all_4.3.0-xorgconf-xfs-example.patch ... [ ok ] * 0126_all_4.2.99.3-startx-v2.patch ... [ ok ] * 0127_all_4.3.99-makefile-fastbuild.patch ... [ ok ] * 0128_all_4.2.0-imake-tmpdir-v2.patch ... [ ok ] * 0129_all_startx-nolisten-tcp.patch ...[ ok ] * 0130_all_4.2.1-fix-shared-libXau-link.v2.patch ...[ ok ] * 0131_all_4.2.99.3-Imake-make-icondir-configable-v3.patch ... [ ok ] * 0132_all_4.2.1-libX11-build-order-fix.patch ... [ ok ] * 0160_all_4.2.99.4-IncludeSharedObjectInNormalLib.patch ...[ ok ] * 0165_all_4.2.99.901-dont-install-Xcms.txt.patch ... [ ok ] * 0199_all_4.2.0-die-ugly-pattern-die-die-die-v2.patch ... [ ok ] * 0202_all_4.2.1-gl-matrix-man-fixes.patch ... [ ok ] * 0205_all_6.7.99.1-xman-bzip2-v2.patch ... [ ok ] * 0208_all_4.2.99.901-fix-xfree86-man-version-string.patch ... [ ok ] * 0270_all_4.1.0-s390-cpp.patch ... [ ok ] * 0350_all_4.2.0-vt7.patch ... [ ok ] * 0350_all_4.3.0-xbiff-FHS.patch ...[ ok ] * 0410_all_4.3-keyboard-fixes-and-hp-symbols.patch ... [ ok ] * 0425_all_6.7.0-sun-type6-keyboard.patch ... [ ok ] * 0430_all_6.8.0-sparc-add-mach64-to-devel-dri-drivers.patch ...[ ok ] * 0440_all_6.8.0-support-cymotion-master-and-ibm-space-saver-keyboards.patch ...[ ok ] * 0475_all_4.3.99.13-xterm-resources-home-end-keys.patch ...[ ok ] * 0485_all_6.8.0-afb-cfb-dlloader-fixes.patch ... [ ok ] *
[gentoo-user] Re: How serious is revdep-rebuild failure
Holly Bostick [EMAIL PROTECTED] writes: [...] Posting emerge info is a good starting point to troubleshoot this (unless you already happen to know why this is occurring, that's also possible). I don't have a clue other than Illinformed bungling... maybe being the problem. The requested output is now posted. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote: Richard Fish [EMAIL PROTECTED] writes: Ok, now we are going to need to see the output of emerge --info, because for some reason your toolchain thinks it is cross-compiling: There appears to be some confusion in that output as to what USE flags are in force. ACCEPT_KEYWORDS=x86 ~x86 I guess the last is what is used? I have in /etc/make.conf ACCEPT_KEYWORDS=~x86 This is because a few -u worls back (2 I think) I foolishly ran ACCEPT_KEYWORDS='~x86' emerges -v -u -D world Well, the only way ~x86 could have been added to make.conf was if it was edited directly. Running with ACCEPT_KEYWORDS in the environment would not have changed it. Having --info report both x86 and ~x86 is normal...it means both stable and testing packages are allowed. And it seems more trouble to back out of that now than to just try to see if I (with help) can stay on top of it. Well, it isn't terribly difficult to switch back to stable. Just remove the ~x86 keyword from make.conf and emerge -DNuv world. The worst case is when you have some testing package merged for which there is no stable version, in which case you either have to unmerge the package or add the appropriate entry to /etc/portage/package.keywords. And of course, don't forget etc-update afterwards. Anyway, on the to the problem at hand: emerge -n -v --info 21|tee emergeInfo.log Gentoo Base System version 1.6.13 Hmm, I would have expected something more recent for ~x86. What does emerge -vp sys-apps/baselayout report? Portage 2.0.53_rc7 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r3, 2.6.14-gentoo-r2 i686) Ok, run gcc-config -l. You should see an entry for i686-pc-linux-gnu-3.4.4. If so, run gcc-config i686-pc-linux-gnu-3.4.4 Then try the revdep-rebuld again. Everything else looks sane. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] courier problems
What about interactively logging into mysql with the providedcredentials? Does that work? i can log in just fine with the user and pass i have specified in the conf files.
Re: [gentoo-user] dovecot problem
On Fri, 2005-11-25 at 19:33 +, Neil Bothwick wrote: On Fri, 25 Nov 2005 11:52:53 -0600, [EMAIL PROTECTED] wrote: I'm having a problem with dovecot. I upgraded dovecot yesterday to 0.99.14-r1, although dovecot --version still claims to be 0.99.14 Dovecot is version 0.99.14, the r1 refers to the ebuild revision. Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe Nov 25 11:46:09 bullet pop3-login: fd_send(-1) failed: Broken pipe What version of dovecot were you running before. There was a config file format change a while ago (on ~x86, I don't know when it affected stable). The source of the error looks familiar, did you update the config file after emerging the new version? I guess I was using version 0.99.13 because I emerged that version of dovecot and everything works fine now. When I emerged v0.99.14-r1 and told it to go ahead and replace /etc/dovecot.conf since I hadn't altered the previous version. In what way was I supposed to alter the config file? -- gentoo-user@gentoo.org mailing list
[gentoo-user] rsync over ssh --delete not working
How to make --delete work with rsync over ssh? When I do rsync I want it to delete files on destination if they are not present on source: example: rsync -av ssh --delete source/ [EMAIL PROTECTED]:/home/joseph/destination I get: building file list ... link_stat /home/joseph/ssh failed: No such file or directory -- #Joseph -- gentoo-user@gentoo.org mailing list
[gentoo-user] what package has moc-qt3?
I'm trying to build a qt based application from source and it's looking for a binary called: moc-qt3 Can anyone tell me what package I have to emerge to get that? I've searched, but so far only uncovered that it is in the qt3-dev-tools package on debian. -- Chris Bare [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] rsync over ssh --delete not working
Got it! I was missing e rsync -ave ssh --delete source/.. .. .. -- #Joseph On Fri, 2005-11-25 at 15:44 -0700, Joseph wrote: How to make --delete work with rsync over ssh? When I do rsync I want it to delete files on destination if they are not present on source: example: rsync -av ssh --delete source/ [EMAIL PROTECTED]:/home/joseph/destination I get: building file list ... link_stat /home/joseph/ssh failed: No such file or directory -- #Joseph -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] what package has moc-qt3?
On Fri, 2005-11-25 at 17:50 -0500, Chris Bare wrote: I'm trying to build a qt based application from source and it's looking for a binary called: moc-qt3 Can anyone tell me what package I have to emerge to get that? I've searched, but so far only uncovered that it is in the qt3-dev-tools package on debian. -- Chris Bare [EMAIL PROTECTED] Surely there's some trick with equery. I tried equery belongs moc-qt3, but didn't find anything... -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] rsync over ssh --delete not working
On Friday 25 November 2005 22:44, Joseph wrote: How to make --delete work with rsync over ssh? By telling rsync to delete. When I do rsync I want it to delete files on destination if they are not present on source: example: rsync -av ssh --delete source/ [EMAIL PROTECTED]:/home/joseph/destination I get: building file list ... link_stat /home/joseph/ssh failed: No such file or directory Yep, that's exactly what you should see. You've told rsync to copy ssh and source to [EMAIL PROTECTED]:/home/joseph/destination rsync has defaulted to ssh for ages now, but to force it you have to specify the remote shell. -- Mike Williams -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Richard Fish [EMAIL PROTECTED] writes: ACCEPT_KEYWORDS=~x86 This is because a few -u worls back (2 I think) I foolishly ran ACCEPT_KEYWORDS='~x86' emerges -v -u -D world Well, the only way ~x86 could have been added to make.conf was if it was edited directly. Running with ACCEPT_KEYWORDS in the environment would not have changed it. There is no mystery why or how its in make.conf. I put it there as indicated in my post. I'm saying the reason I did that is: . . . . . . . . . . . . . . . . . . . . . I foolishly ran ACCEPT_KEYWORDS='~x86' emerges -v -u -D world And didn't want to back off of it immediately. Having --info report both x86 and ~x86 is normal...it means both stable and testing packages are allowed. OK, I wasn't sure what it might mean. [...] emerge -n -v --info 21|tee emergeInfo.log Gentoo Base System version 1.6.13 Hmm, I would have expected something more recent for ~x86. What does emerge -vp sys-apps/baselayout report? emerge -vp sys-apps/baselayout [...] Calculating dependencies ...done! [ebuild U ] sys-apps/baselayout-1.12.0_pre11-r1 [1.11.13-r1] -bootstrap -build -static -unicode 204 kB Portage 2.0.53_rc7 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r3, 2.6.14-gentoo-r2 i686) Ok, run gcc-config -l. You should see an entry for i686-pc-linux-gnu-3.4.4. root # gcc-config -l [1] i686-pc-linux-gnu-3.3.5-20050130 * [2] i686-pc-linux-gnu-3.3.5-20050130-hardened [3] i686-pc-linux-gnu-3.3.5-20050130-hardenednopie [4] i686-pc-linux-gnu-3.3.5-20050130-hardenednopiessp [5] i686-pc-linux-gnu-3.3.5-20050130-hardenednossp [6] i686-pc-linux-gnu-3.4.4 [7] i686-pc-linux-gnu-3.4.4-hardened [8] i686-pc-linux-gnu-3.4.4-hardenednopie [9] i686-pc-linux-gnu-3.4.4-hardenednopiessp [10] i686-pc-linux-gnu-3.4.4-hardenednossp If so, run gcc-config i686-pc-linux-gnu-3.4.4 root # gcc-config i686-pc-linux-gnu-3.4.4 * Switching native-compiler to i686-pc-linux-gnu-3.4.4 ... [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * # source /etc/profile . . . . . . . . . . Then try the revdep-rebuld again. Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/bin/cinelerra (requires libmjpegutils-1.6.so.0) broken /usr/bin/php (requires libmysqlclient.so.12) broken /usr/bin/playdv (requires libvga.so.1) broken /usr/bin/tcprobe (requires libMagick.so.6) broken /usr/bin/w3c (requires libmysqlclient.so.12) broken /usr/bin/webbot (requires libmysqlclient.so.12) broken /usr/bin/www (requires libmysqlclient.so.12) broken /usr/kde/3.4/bin/kuickshow (requires libungif.so.4) broken /usr/kde/3.4/lib/kde3/kuickshow.so (requires libungif.so.4) broken /usr/kde/3.4/lib/libkdeinit_kuickshow.so (requires libungif.so.4) broken /usr/lib/apache2-extramodules/libphp4.so (requires libmysqlclient.so.12) broken /usr/lib/libImlib.so.1.9.14 (requires libungif.so.4) broken /usr/lib/libaviplay-0.7.so.0.0.41 (requires libvga.so.1) broken /usr/lib/libimlib-gif.so (requires libungif.so.4) broken /usr/lib/libmd5.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libpics.so.0.0.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwapp.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwcache.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwcore.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwdir.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwfile.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwftp.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwgopher.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwhtml.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwhttp.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwinit.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwmime.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwmux.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwnews.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwsql.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwssl.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwstream.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwtelnet.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwtrans.so.0.1.0 (requires libmysqlclient.so.12) broken /usr/lib/libwwwutils.so.0.1.0 (requires libmysqlclient.so.12) broken
[gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam [EMAIL PROTECTED] writes: [...] checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) is a cross-compiler... yes Still thinks its a cross-compiler... what does that mean anyway? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] rsync over ssh --delete not working
On Fri, 2005-11-25 at 15:51 -0700, Joseph wrote: Got it! I was missing e rsync -ave ssh --delete source/.. .. .. -- #Joseph I have another question related to rsync. If I do rsync over ssh and next do it again but with directory mounted with samba; it starts copying all the files, regardless if the files has change or not Does it has something do to with file permission on samba vs. Linux (Unix type)? -- #Joseph -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] dovecot problem
On Fri, 25 Nov 2005 16:36:13 -0600, Michael Sullivan wrote: What version of dovecot were you running before. There was a config file format change a while ago (on ~x86, I don't know when it affected stable). The source of the error looks familiar, did you update the config file after emerging the new version? I guess I was using version 0.99.13 because I emerged that version of dovecot and everything works fine now. When I emerged v0.99.14-r1 and told it to go ahead and replace /etc/dovecot.conf since I hadn't altered the previous version. In what way was I supposed to alter the config file? Looking at the versions of dovecot available, that may not be the issue. I see that I am running 1.0_alpha2 and have been since September, I had 0.99.14-r1 for the previous six months, so the config change was for 1.0_alpha. Sorry your problem must be elsewhere, but I'd start by looking at the pop3-login section of /etc/dovecot.conf. -- Neil Bothwick Only an idiot actually READS taglines. signature.asc Description: PGP signature
Re: [gentoo-user] rsync over ssh --delete not working
On Fri, 25 Nov 2005 15:51:34 -0700, Joseph wrote: Got it! I was missing e rsync -ave ssh --delete source/.. .. .. You don't need -e or ssh, rsync uses ssh as its remote shell by default. rsync -av --delete source/ ... would do exactly the same. -- Neil Bothwick Resistance is futile, Persistance is MSDOS signature.asc Description: PGP signature
[gentoo-user] A suggestion for bacula
I've installed bacula from portage ( bacula-1.36.3-r2.ebuild) and found virtually no documentation with it other than one thin README and some release notes. Its not as if the documentaion is not available. There is quite a large manual for it. But worse is that the gentoo install has removed things so that even the available manual doesn't work for a gentoo user. For example: In the online manual: http://www.bacula.org/rel-manual/Contents.html In the section on `Running a job' a gentoo user will not get the right results because the bacula developers have expected there to be some of the install of bacula files available for testing. Bacula goes looking for them in /var/tmp/**bacula* and of course they are long gone. So a gentoo user will end up with nothing backed up and wondering what they did wrong. Especially if they don't notice the give away address, and it isn't that obvious because `bconsole' output is pretty primitive and it will not be on the screen long. It also means the restore part is a non starter too since nothing got backed up. Apparently someone maybe me needs to go thru the bacula ebuilds and make them a little more like what bacula devel people expect. Or fix it so it works for us. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] rsync over ssh --delete not working
On Sat, 2005-11-26 at 00:05 +, Neil Bothwick wrote: On Fri, 25 Nov 2005 15:51:34 -0700, Joseph wrote: Got it! I was missing e rsync -ave ssh --delete source/.. .. .. You don't need -e or ssh, rsync uses ssh as its remote shell by default. rsync -av --delete source/ ... would do exactly the same. That was my impression too but when I tried it without e it gave the the error: rsync -av ssh --delete source/ [EMAIL PROTECTED]:/home/joseph/destination building file list ... link_stat /home/joseph/ssh failed: No such file or directory When I added e it deleted the file on destination, and no errors showed up. -- #Joseph -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] rsync over ssh --delete not working
On Fri, 25 Nov 2005 19:27:08 -0700 Joseph [EMAIL PROTECTED] wrote: On Sat, 2005-11-26 at 00:05 +, Neil Bothwick wrote: On Fri, 25 Nov 2005 15:51:34 -0700, Joseph wrote: Got it! I was missing e rsync -ave ssh --delete source/.. .. .. You don't need -e or ssh, rsync uses ssh as its remote shell by default. rsync -av --delete source/ ... would do exactly the same. That was my impression too but when I tried it without e it gave the the error: rsync -av ssh --delete source/ [EMAIL PROTECTED]:/home/joseph/destination building file list ... link_stat /home/joseph/ssh failed: No such file or directory When I added e it deleted the file on destination, and no errors showed up. no, when you did it you specified that it was to copy a file called ssh. just leave ssh out altogether. if you want to specify the remote shell to use, specify it with -e ssh, if you want to rely on the default, leave out -e, and leave out ssh unless you really DO want to copy a file called ssh. -- #Joseph -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
[gentoo-user] beagle corlib conflict
hello, I have just compiled beagle and tried to use it but I got this message from [EMAIL PROTECTED] ~ $ beagle-query something Corlib not in sync with this runtime: expected corlib version 41, found 22. Download a newer corlib or a newer runtime at http://www.go-mono.com/daily. what does this mean? I have checked, mono version is 1.1.10 so probably the latest. does anyone have a clue what to do to make it work? Karsten
Re: [gentoo-user] rsync over ssh --delete not working
[snip] On Sat, 2005-11-26 at 16:03 +1300, Nick Rout wrote: When I added e it deleted the file on destination, and no errors showed up. no, when you did it you specified that it was to copy a file called ssh. just leave ssh out altogether. if you want to specify the remote shell to use, specify it with -e ssh, if you want to rely on the default, leave out -e, and leave out ssh unless you really DO want to copy a file called ssh. Thank you for explanation, works like a charm. -- #Joseph -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote:
Harry Putnam [EMAIL PROTECTED] writes:
[...]
checking whether the C compiler (gcc -O2 -march=pentium4
-fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) is a
cross-compiler... yes
Still thinks its a cross-compiler... what does that mean anyway?
Well, generally, it means that you are compiling for a different
architecture than what you are running. For example, it is possible
to compile for AMD64 CPUs from a P4 host, or vice-versa. However,
since you are not doing that, it means your toolchain is broken in
some way.
The way autoconf (the ./configure script) checks for this is that it
compiles a very simple program. This program is:
#line 1880 configure
#include confdefs.h
main(){return(0);}
It then compiles this program. If the program compiles, configure
decides that gcc works. If the program doesn't run, it decides that
you are cross compiling. So, let's try this manually.
Save the above lines to a file, call it conftest.c. The build it with
gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff
-L/usr/lib -o conftest conftest.c
If the compile complets without error, try running the program with:
conftest echo works
-Richard
--
gentoo-user@gentoo.org mailing list
[gentoo-user] can't run passwd
Hello everybody, On a fresh install got stuck at livecd/#passwd bash: passwd: command not found Sure enough, there's no passwd in /bin nor a link in /usr/bin. This, having just worked through the on-line docs up to setting hostname and domainname w/o incident. When I exit /bin/bash I can run passwd alright but what good is that? Somethings not right. Used the mini-install 2005.1 to download a stage2 tarball and snapshot to a small drive which I then unpacked onto a SATA 120G and so on. Now I hear there's no support for stage2. Is that the problem? But passwd is a pretty basic program. At a loss -mw -mw __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Richard Fish [EMAIL PROTECTED] writes:
#line 1880 configure
#include confdefs.h
main(){return(0);}
It then compiles this program. If the program compiles, configure
decides that gcc works. If the program doesn't run, it decides that
you are cross compiling. So, let's try this manually.
Save the above lines to a file, call it conftest.c. The build it with
gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff
-L/usr/lib -o conftest conftest.c
gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib \
-ltiff -L/usr/lib -o conftest conftest.c
configure:1880:22: confdefs.h: No such file or directory
Just complains about not finding confdefs.h.
I looked for one under /usr/include to point it at but didn't find one
and wasn't at all sure what it should contain.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote:
Richard Fish [EMAIL PROTECTED] writes:
#line 1880 configure
#include confdefs.h
main(){return(0);}
It then compiles this program. If the program compiles, configure
decides that gcc works. If the program doesn't run, it decides that
you are cross compiling. So, let's try this manually.
Save the above lines to a file, call it conftest.c. The build it with
gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff
-L/usr/lib -o conftest conftest.c
gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib \
-ltiff -L/usr/lib -o conftest conftest.c
configure:1880:22: confdefs.h: No such file or directory
Just complains about not finding confdefs.h.
Sorry, my fault. Confdefs.h is generated by the configure script, and
doesn't matter for this case. Just remove the include from the file.
-Richard
--
gentoo-user@gentoo.org mailing list
[gentoo-user] Re: How serious is revdep-rebuild failure
Richard Fish [EMAIL PROTECTED] writes: conftest echo works root # ./conftest echo works works Seems to have worked as expected. -- gentoo-user@gentoo.org mailing list
